100% de tiempo de actividad para una aplicación web

312

Hoy recibimos un "requisito" interesante de un cliente.

Quieren un 100% de tiempo de actividad con conmutación por error fuera del sitio en una aplicación web. Desde el punto de vista de nuestra aplicación web, esto no es un problema. Fue diseñado para poder escalar en varios servidores de bases de datos, etc.

Sin embargo, debido a un problema de red, parece que no puedo entender cómo hacerlo funcionar.

En pocas palabras, la aplicación vivirá en servidores dentro de la red del cliente. Se accede tanto por personas internas como externas. Quieren que mantengamos una copia del sistema fuera del sitio que, en caso de una falla grave en sus instalaciones, inmediatamente se recuperaría y se haría cargo.

Ahora sabemos que no hay absolutamente ninguna manera de resolverlo para las personas internas (¿paloma mensajera?), Pero quieren que los usuarios externos ni siquiera lo noten.

Francamente, no tengo la menor idea de cómo esto podría ser posible. Parece que si pierden la conectividad a Internet, entonces tendríamos que hacer un cambio de DNS para reenviar el tráfico a las máquinas externas ... Lo que, por supuesto, lleva tiempo.

Ideas?

ACTUALIZAR

Tuve una discusión con el cliente hoy y aclararon sobre el tema.

Se quedaron atrapados en el número 100%, diciendo que la aplicación debería permanecer activa incluso en caso de inundación. Sin embargo, ese requisito solo entra en vigor si lo alojamos para ellos. Dijeron que manejarían el requisito de tiempo de actividad si la aplicación vive completamente en sus servidores. Puedes adivinar mi respuesta.

Yo no
fuente
49
No subestimes el gran tiempo de inactividad causado por la piratería, mira a Sony y a la red PlayStation. puede garantizar que tuvieron la misma idea de tiempo de actividad del 100% y el dinero / hardware para respaldarla. deje en claro con el cliente que el 100% de tiempo de actividad es una expectativa inviable, incluso los técnicos de Google dudarían en murmurar "100% de tiempo de actividad". una sugerencia por cierto es considerar el uso de DNS dinámico, solo almacenan en caché durante 60 segundos, esto debe incluir el sistema operativo y los servidores DNS locales.
Silverfire
182
Yo personalmente RUN desde este cliente lo más rápido posible. Sospecho que esta no será la última idea loca que puedan tener (desde un punto de vista tecnológico).
GregD
137
Desearía poder desestimar a tu cliente.
joeqwerty
81
Si descubres un tiempo de actividad del 100%, házmelo saber. Crearé un negocio con él y lo venderé a Google. Es imposible garantizar el 100%. Incluso las empresas como Microsoft, Amazon o Google no subirán tanto porque saben que es imposible. Lo mejor que he visto es 99.999% e incluso eso es un estiramiento (5 minutos en un año). Lo mejor que probablemente podría hacer es 99.99% confiable.
Matt
39
Simplemente invente un precio increíblemente alto para poner en su solicitud de locos. Eso probablemente los devolverá a sus sentidos. O bien, o los enviará a buscar a alguien dispuesto a mentirles.
Nate CK

Respuestas:

368

Aquí está el útil cuadro de Wikipedia sobre la búsqueda de nueves:

ingrese la descripción de la imagen aquí

Curiosamente, solo 3 de los 20 principales sitios web pudieron alcanzar los míticos 5 nueves o 99.999% de tiempo de actividad en 2007. Eran Yahoo, AOL y Comcast. En los primeros 4 meses de 2008, algunas de las redes sociales más populares , ni siquiera se acercaron a eso.

De la tabla, debería ser evidente cuán ridícula es la búsqueda del 100% de tiempo de actividad ...

GregD
fuente
62
Pingdom tampoco está comprobando cada segundo. Además de eso, los que cumplieron cinco nueves probablemente todavía tenían interrupciones localizadas que Pingdom podría no haber detectado, o fallas que hicieron que algunos servicios no estuvieran disponibles mientras respondían a pings.
ceejayoz
8
Lo que en sí mismo hace
dudar a
55
Precisamente. ¡Y tienen $ miles de millones para trabajar!
ceejayoz
43
Lamento interrumpir el chat, pero la pregunta del OP fue cómo esforzarse por alcanzar el objetivo del 100% de tiempo de actividad en un nivel técnico, no conceptual, estoy seguro de que él sabe que no siempre es posible debido a eventos naturales que suceden al hardware y el medio ambiente ¿Podríamos ayudarlo con eso?
David d C e Freitas
55
Para el OP: He visto SLA que garantizaban el tiempo de actividad en el contexto de "fuera del mantenimiento normal". El mantenimiento normal, por supuesto, es el tiempo de inactividad programado por mes para actualizaciones, parches, etc., que generalmente ocurre en el día menos ocupado del mes durante los momentos menos ocupados del mes (generalmente a mitad de la noche). Deben tener algún tipo de métrica para su negocio con respecto al negocio. Usted podría ofrecer un mejor tiempo de actividad (4 nueves) para ellos solamente en esos momentos.
GregD
186

Pídales que definan el 100% y cómo se medirá durante qué período de tiempo. Probablemente significan tan cerca del 100% como pueden pagar. Dales los costos.

Elaborar. He estado en conversaciones con clientes a lo largo de los años con requisitos supuestamente ridículos. En todos los casos, en realidad solo usaban un lenguaje no lo suficientemente preciso.

Muy a menudo enmarcan las cosas en formas que parecen absolutas, como el 100%, pero en realidad, en una investigación más profunda, son lo suficientemente razonables para hacer los análisis de costo / beneficio que se requieren cuando se presentan los costos para mitigar los datos de riesgo. Preguntarles cómo medirán la disponibilidad es una pregunta crucial. Si no saben esto, entonces usted está en condiciones de sugerirles que esto debe definirse primero.

Le pediría al cliente que defina qué sucedería en términos de impacto / costos comerciales si el sitio se cayera en las siguientes circunstancias:

  • En sus horas de mayor actividad por x horas
  • En sus horas menos ocupadas por x horas

Y también cómo medirán esto.

De esta forma, puede trabajar con ellos para determinar el nivel correcto de '100%'. Sospecho que al hacer este tipo de preguntas podrán determinar mejor las prioridades de sus otros requisitos. Por ejemplo, pueden querer pagar ciertos niveles de SLA y comprometer otras funcionalidades para lograr esto.

Sangha Preet
fuente
21
Convenido. Pueden significar un tiempo de actividad "muy alto" (¿los 90 superiores?) Con una estrategia de conmutación por error bastante sólida. Si no, entonces una explicación de la escala de costos involucrada los convencería ...
Martin Dow
32
+1 por no sacar conclusiones precipitadas, y simplemente pedirle al cliente que explique lo que tiene en mente.
sleske
44
Me hago eco de la declaración de "no saltar a conclusiones" ... si el cliente quiere decir un tiempo de actividad del 100% (menos el mantenimiento programado), entonces puede ser un requisito más razonable.
Tim Reddy
1
Con respecto al impacto comercial, en realidad conocemos y entendemos su negocio por completo y los costos involucrados en la caída del sitio no son financieros. Más en la línea de los nativos que aparecen con horcas, posibles ahorcamientos, etc.;) Imagínese 40,000 personas que aparecen en su puerta gritando. Eso es lo que quieren evitar con pasión.
NotMe
77
@ChrisLively Una razón más para tener una comprensión madura del riesgo entonces. El paradigma dominante para la ingeniería de seguridad es la evaluación probabilística de riesgos . Hay sistemas que podrían matar (no solo molestar) a miles de personas y todavía tienen una probabilidad de falla baja, con suerte bien entendida, pero no nula.
Poolie
140

Tus clientes están locos. El 100% de tiempo de actividad es imposible sin importar cuánto dinero gaste en él. Llano y simple, imposible. Mire Google, Amazon, etc. Tienen una cantidad casi infinita de dinero para invertir en su infraestructura y aún así logran tener tiempo de inactividad. Debe entregarles ese mensaje, y si continúan insistiendo en que ofrezcan demandas razonables. Si no reconocen que una cierta cantidad de tiempo de inactividad es inevitable, entonces deséchelos.

Dicho esto, parece tener la mecánica de escalar / distribuir la aplicación en sí. La parte de la red necesitará involucrar enlaces ascendentes redundantes a diferentes ISP, obtener una asignación de ASN e IP, y profundizar en BGP y equipo de enrutamiento real para que el espacio de direcciones IP pueda moverse entre ISP si es necesario.

Esta es, obviamente, una respuesta muy concisa. No ha tenido experiencia con aplicaciones que requieren este grado de tiempo de actividad, por lo que realmente necesita involucrar a un profesional si desea acercarse al mítico tiempo de actividad del 100%.

EEAA
fuente
77
Convenido. Totalmente. Loca.
jdw
2
ellos solían ??
Sirex
2
@Sirex Refiriéndose al reciente experimento @ CERN donde se ha encontrado que los neutrinos viajan más rápido que la luz. Sin embargo, los resultados aún no han sido confirmados por científicos independientes.
TC1
99
@ TC1 Te apuesto 200 dólares que no funcionan.
dpatchery
44
@ErikA Una solicitud de tiempo de actividad del 100% indica que se ignoran las características técnicas de los sistemas. Eso está bien, porque el trabajo del cliente es hacer lo que sea que hagan. Su trabajo es diseñar sistemas de TI. Los clientes difíciles como este pueden ser pesadillas, pero también pueden convertirse en sus mejores clientes.
duffbeer703
54

Bueno, eso definitivamente es interesante. No estoy seguro de querer comprometerme contractualmente al 100% del tiempo de actividad, pero si tuviera que hacerlo, creo que se vería así:

Comience con la IP pública en un equilibrador de carga completamente fuera de la red y cree al menos dos de ellas para que una pueda conmutar por error a la otra. Un programa como Heatbeart puede ayudar con la conmutación por error automática de esos.

El barniz se conoce principalmente como una solución de almacenamiento en caché, pero también hace un equilibrio de carga muy decente. Quizás esa sería una buena opción para manejar el equilibrio de carga. Se puede configurar para tener 1 a n backends opcionalmente agrupados en directores que equilibrarán la carga de forma aleatoria o por turnos. El barniz se puede hacer lo suficientemente inteligente como para verificar el estado de cada back-end y eliminar los back-insals no saludables hasta que vuelva a estar en línea. Los backends no tienen que estar en la misma red.

Estoy un poco enamorado de las IP elásticas en Amazon EC2 en estos días, por lo que probablemente construiría mis equilibradores de carga en EC2 en diferentes regiones o al menos en diferentes zonas de disponibilidad en la misma región. Eso le daría la opción de girar manualmente (nuevo) un nuevo equilibrador de carga si fuera necesario y mover la IP de registro A existente a la nueva caja.

Sin embargo, Varnish no puede terminar SSL, por lo que si eso es una preocupación, es posible que desee ver algo como Nginx en su lugar.

Podría tener la mayoría de sus backends en la red de sus clientes y uno o más fuera de su red. Creo, pero no estoy 100% seguro, que puede priorizar los backends para que las máquinas de sus clientes reciban prioridad hasta el momento en que todos se vuelvan insalubres.

Ahí es donde comenzaría si tuviera esta tarea y, sin duda, la refinaría a medida que avance.

Sin embargo, como dice @ErikA, es Internet y siempre habrá partes de la red que están fuera de su control. Querrá asegurarse de que su legal solo lo vincule con cosas que están bajo su control.

jdw
fuente
2
Durante un tiempo estuve pensando en Amazon y MS para una implementación en la nube, pero ambos han tenido interrupciones importantes en los últimos meses. SSL es crítico.
NotMe
3
Si fuera a usar Amazon, definitivamente desearía distribuir sus máquinas alrededor de las 5 zonas de disponibilidad. Es bastante improbable que todas sus zonas se apaguen al mismo tiempo.
jdw
11
+1 para abordar realmente la pregunta principal del OP.
Phil
siempre tendrá un punto de falla, jdw, siempre que haya algo no distribuido en la cadena (en su caso, latido, a menos que, por supuesto, tenga varias instancias de eso ejecutándose en máquinas remotas, todas monitoreándose entre sí, así como su servidores, que cualquiera de ellos puede ver o no debido a problemas de red a lo largo del enrutamiento). Lo que nos lleva al "tiempo de inactividad". Los servidores pueden estar en funcionamiento y aún no estar disponibles para el cliente sin que los latidos lo detecten si la falla no está en la ruta de enrutamiento.
Jwenting
Convenido. Como todo el mundo ha señalado, no existe el 100% de tiempo de actividad. Todo lo que puede hacer es intentarlo y lo que describí es cómo comenzaría a intentarlo.
jdw
30

No hay problema, aunque la redacción del contrato ligeramente revisada:

... garantiza un tiempo de actividad del 100% (redondeado a cero decimales).

Nick Pierpoint
fuente
2
+1 por notar que 100% no es 100,0% o 100,000%, etc. Los dígitos decimales importan, indican precisión;)
Danubian Sailor
44
Según algunas convenciones, "100%" tiene solo una cifra significativa, de modo que todos los números entre la mitad y uno se redondearían a "100%"; 50% se redondearía al 100%.
Thomas Levine
1
Dependiendo del estándar para contar, algunos dirán que el 50% tiene dos números meeningfull donde el 100% tiene tres números meeningfull. 50,5 y 100 son, por lo tanto, igual de precisos. Otros contarán dígitos después del punto decimal. Entonces 50,5 y 100,4 serán igual de precisos. Si no se indica nada más, asumiría que 100% es 99,5% y más. 100,0% es 99.95% y más, etc.
Tillebeck
26

Si Facebook y Amazon no pueden hacerlo, entonces tú no puedes. Es tan simple como eso.

Miguel
fuente
17
él podría ser más inteligente que toda su gente combinada, quién sabe: p
Matt
3
El 100% de tiempo de actividad no tiene que ser personas tan literales, significa: 100% disponible durante el tiempo que se necesita. Por ejemplo, los sistemas bancarios siempre deben estar disponibles, y funcionan bastante bien. El hecho de que no estén en mantenimiento por 1 segundo una vez al año no significa que hayan fallado en su objetivo de tiempo de actividad del 100%.
David d C e Freitas
13
@DavidFreitas - Creo que en los contratos suele ser bastante literal ...
UpTheCreek
2
@Matt solo porque Facebook / Amazon no puede hacerlo no significa que un sitio más pequeño no pueda hacerlo. Muchos sitios web grandes enfrentan problemas mucho más difíciles de superar que un sitio más pequeño.
Xorlev
1
así que lo que está diciendo es que no tenía un tiempo de actividad del 100% ya que tenía algunos clientes que tenían errores ... más dns no es un cambio instantáneo ya que tiene ISP que ignoran los TTL cortos
Mike
25

Para agregar la respuesta de oconnore de Hacker News

No entiendo cuál es el problema. El cliente quiere que planifiques para el desastre, y no están orientados a las matemáticas, por lo que pedir una probabilidad del 100% parece razonable. El ingeniero, como los ingenieros son propensos a hacer, recordó su primer día de prob & stat 101, sin considerar que el cliente podría no hacerlo. Cuando dicen esto, no están pensando en el invierno nuclear, están pensando en Fred arrojando su café en el servidor de la oficina, un disco que falla, o un ISP cayendo. Además, puedes lograr esto. Con servidores geográficamente distintos, independientes y de autocontrol, básicamente no tendrá tiempo de inactividad. Con 3 servidores que funcionan con una fiabilidad independiente (1) tres 9, con buenos modos de conmutación por error, su tiempo de inactividad esperado es inferior a un segundo por año (2). Incluso si esto sucede de una vez, todavía está dentro de un SLA razonable para conexiones web y, por lo tanto, el tiempo de inactividad prácticamente no existe. El cliente todavía tiene que lidiar con los escenarios del fin del mundo, pero Godzilla excluido, tendrá un servicio que está "siempre" activo.

(1) Un servidor en Los Ángeles es razonablemente independiente del servidor en Boston, pero sí, entiendo que hay una intersección que involucra una guerra nuclear, piratas informáticos chinos que rompen la red eléctrica, etc. No creo que su cliente esté molesto por esta.

(2) La conmutación por error de DNS puede agregar algunos segundos. Todavía se encuentra en un escenario en el que el cliente tiene que volver a intentar una solicitud una vez al año, lo cual, nuevamente, se encuentra dentro de un SLA razonable y, por lo general, no se considera en la misma línea que el "tiempo de inactividad". Con una aplicación que se redirige automáticamente a un nodo disponible en caso de falla, esto puede pasar desapercibido.

Cazador de la selva
fuente
66
El problema es que lo dicen en contract-ese. Lo que significa que si un desastre no se producen y se necesita más de diez segundos para tomar el lugar de nuevo en línea a través de las copias de seguridad que tendrían legitimación activa.
Shadur
@Shadur: Si realmente lo quieren, entonces realmente debes cobrarles. Extienda los servidores geográficamente a lo largo y ancho, con suerte no habrá desastres en todas partes.
Jungle Hunter
3
He visto un sitio que ofrece garantías de tiempo de actividad del 100% o le devolvemos su dinero. El truco fue que cargaron un bote cargado y se dividieron en meses. Entonces, algunos meses no se pagan y usted programa todo alrededor de eso, y cubre la pérdida con los meses que funcionan bien.
jldugger
17

Se te pide algo imposible.

Revise las otras respuestas aquí, siéntese con su cliente y explique POR QUÉ es imposible, y calcule su respuesta.

Si aún insisten en un tiempo de actividad del 100%, infórmeles cortésmente que no se puede hacer y rechace el contrato. Nunca satisfarás su demanda, y si el contrato no apesta totalmente, te castigarán con multas.

voretaq7
fuente
2
Se debe definir el 100%, es decir, el 100% disponible, excepto cuando se realizan tareas de mantenimiento o actualizaciones y ese tiempo se limitará a horas de silencio durante algunas horas al mes como máximo. Todo depende de cuál sea el propósito y el uso de la aplicación web en este caso ...
David d C e Freitas
1
y definir "tiempo de inactividad". En teoría, ni siquiera puedo garantizar que puedan acceder a un servidor en Omaha desde sus oficinas en Fairbanks a menos que usted controle toda la red intermedia (aunque podría garantizar que el servidor esté funcionando).
Jwenting
Las definiciones son, en mi humilde opinión, irrelevantes si solicitan un "100% de tiempo de actividad": incluso si negocia el mantenimiento programado y crea redundancia N + N si una falla menor causa un reinicio no programado o un parpadeo de servicio que ha arruinado su SLA. DEFINITIVAMENTE relevante si está negociando un SLA de 3, 4 o 5 nueves.
voretaq7
Sin embargo, depende de los términos del SLA, ¿no? Si le pagan $ 100K por mes y cada minuto de tiempo de inactividad conlleva una multa de $ 1K, eso podría ser completamente factible (si tiene otros contratos para amortizar el costo de los administradores de sistemas in situ 24/7).
Michael Borgwardt
@MichaelBorgwardt definitivamente hay formas de "hacerlo funcionar" desde el punto de vista de los números puros, pero aún así rechazaría debido al potencial de malas relaciones públicas ($ _CLIENT entra en Twitter y le dice al mundo 'estamos caídos porque $ _PROVIDER es incompetente y no puedo cumplir con su SLA! '). Personalmente prefiero que 10 clientes más pequeños y más razonables me paguen $ 10ka al mes :-)
voretaq7
13

Precio en consecuencia, y luego estipula en el contrato que cualquier tiempo de inactividad pasado el SLA será reembolsado a la tasa que están pagando.

El ISP en mi último trabajo hizo eso. Tuvimos la opción de una línea DSL "regular" con un tiempo de actividad del 99.9% por $ 40 / mes, o un trío de T1s con un tiempo de actividad del 99.99% por $ 1100 / mes. Hubo interrupciones frecuentes de más de 10 horas por mes, lo que redujo su tiempo de actividad muy por debajo del DSL de $ 40 / mes, sin embargo, solo nos reembolsaron alrededor de $ 15 más o menos, porque esa fue la tasa por hora * horas que terminó. Salieron como bandidos del trato.

Si factura $ 450,000 al mes por un tiempo de actividad del 100%, y solo alcanza el 99.999%, deberá reembolsarles $ 324. Estoy dispuesto a apostar que los costos de infraestructura para alcanzar el 99.999% están en el vecindario de $ 45,000 al mes, suponiendo colos completamente distribuidos, múltiples enlaces ascendentes de nivel 1, hardware de fantasía, etc.

Bryan Boettcher
fuente
3
Si ve a alguien que promete un tiempo de actividad del 100%, esto es exactamente lo que está haciendo. Hay una diferencia entre prometer un tiempo de actividad del 100% y entregarlo. Sería una buena idea explicar esto al cliente si intentan cotizarle un SLA de la competencia.
sjbotha
10

Si los profesionales se preguntan si el 99.999 por ciento de disponibilidad [es] alguna vez una posibilidad práctica o financieramente viable , entonces el 99.9999 por ciento de disponibilidad es aún menos posible o práctico. Y mucho menos al 100%.

No alcanzará el objetivo de disponibilidad del 100% durante un período prolongado de tiempo. Puede salirse con la suya durante una semana o un año, pero luego sucederá algo y usted será responsable. El emisario puede ir desde la reputación dañada (lo prometiste, no cumpliste) hasta la bancarrota por multas contractuales.

Paweł Brodacki
fuente
10

Hay dos tipos de personas que solicitan un tiempo de actividad del 100%:

  1. Personas que no tienen absolutamente ningún conocimiento sobre computadoras, sistemas informáticos o Internet. *
  2. Aquellos que intencionalmente se están burlando de sí mismos, ya sea para probar su capacidad de decir No (Google "la Prueba del Jugo de Naranja"), o para tratar de obtener algún tipo de apalancamiento de SLA de contrato para evitar pagarle más tarde.

Mi consejo, después de haber sufrido estos dos tipos de clientes en muchas ocasiones, es no tomar este cliente. Deja que vuelvan loco a alguien más.

* Es posible que esta misma persona no se avergüence de preguntar sobre viajes más rápidos que la luz, movimiento perpetuo, fusión fría, etc.

Irving
fuente
2
+1 para la prueba de zumo de naranja ... me gusta y no lo sabía :)
Oliver M Grech
8

Me comunicaría con el cliente para establecer con ellos qué significa exactamente el 100% de tiempo de actividad. Es posible que realmente no vean una distinción entre 99% de tiempo de actividad y 100% de tiempo de actividad. Para la mayoría de las personas (es decir, no para los administradores del servidor) esos dos números son iguales.

jhocking
fuente
6

100% de tiempo de actividad?

Esto es lo que necesitas:

Múltiples servidores DNS (y redundantes), que apuntan a múltiples sitios en todo el mundo, con SLA adecuados con cada ISP.

Asegúrese de que los servidores DNS estén configurados correctamente, con TTL reconocido de manera efectiva.

A
fuente
1
Sí, DNS es un buen comienzo, por ejemplo, nslookup google.comdevuelve 6 IP diferentes para redundancia en caso de que algunas de ellas no funcionen. Visite también RobTex.com, un excelente sitio para ver las configuraciones de ciertos dominios, por ejemplo, robtex.com/dns/google.com.html#records
David d C e Freitas
6

Esto es facil. El SLA de Amazon EC2 establece claramente:

El "porcentaje de tiempo de actividad anual" se calcula restando del 100% el porcentaje de períodos de 5 minutos durante el año de servicio en el que Amazon EC2 estaba en el estado de "región no disponible".

http://aws.amazon.com/ec2-sla/

Simplemente defina 'tiempo de actividad' para que sea relativo a todo el paquete de servicios; de hecho, puede mantenerse operativo el 100% del tiempo y no debería tener problemas.

Además, vale la pena señalar que el objetivo de un SLA es definir cuáles son sus obligaciones y qué sucede si no puede cumplirlas. No importa si el cliente pide 3 nueves o 5 nueves o un millón de nueves; la pregunta es qué obtienen cuando / si no puede entregar. La respuesta obvia es proporcionar una línea de pedido con un tiempo de actividad del 100% a 5 veces el precio que desea cobrar, y luego obtienen un reembolso de 4 veces si no cumple ese objetivo. ¡Podrías anotar!

campos
fuente
5

Los cambios de DNS solo toman tiempo si están configurados para tomar tiempo. Puede establecer el TTL en un registro en un segundo: su único problema sería asegurarse de proporcionar una respuesta oportuna a las consultas DNS y que los servidores DNS puedan hacer frente a ese nivel de consultas.

Así es exactamente cómo funciona GTM en F5 Big IP: el TTL de DNS está configurado de forma predeterminada en 30 segundos y si un miembro del clúster necesita hacerse cargo, el DNS se actualiza y se toma una nueva IP casi de inmediato. Máximo de 30 segundos de interrupción, pero ese es el caso límite, el promedio sería de 15 segundos.

Pablo
fuente
10
Según mi experiencia, algunos servidores DNS ignorarán un TTL que consideran desagradablemente bajo (a pesar del RFC). Cualquier cosa menos de 5 minutos se vuelve poco confiable en la escala global.
jdw
13
@Paul ignorar la realidad no es una práctica aceptable, no importa cuánto moleste a todos.
MDMarra
55
Estoy con JDW en esto. He visto que numerosos servidores DNS ignoran por completo TTL, incluso una configuración de 1 hora y el valor predeterminado es algo así como 24 horas más o menos.
NotMe
66
@Paul: el OP no tiene control sobre los solucionadores de DNS de cada ISP en el planeta. Ergo, no tienen la opción de decir "si vas a usar nuestro sitio web, no uses Comcast / Roadrunner / quien sea como tu ISP porque ignorarán nuestra configuración TTL". Es algo que simplemente está fuera de su control y, por lo tanto, es demasiado frágil para ser considerado una solución para este problema en mi humilde opinión. La solución tiene que incluir alguna forma de poder forzar internamente las IP sin depender de otros bits de la red que pueden no ser cooperativos.
jdw
3
Eso es como no tener un UPS porque la energía "debería funcionar". No es una forma innovadora de diseñar un sistema. Si sabe que hay una parte frágil del sistema, por cualquier motivo, debe intentar dar cuenta de ello.
jdw
5

Sabes que esto es imposible.

Sin duda, el cliente está enfocado en ver "100%", por lo que lo mejor que puede hacer es prometer 100%, a excepción de [todas las causas razonables que no son su culpa].

Marcin
fuente
Sin duda el cliente no quiere ninguna solución. Quieren un declive. Para que puedan decir, lo intentaron al menos.
mbx
Bien quizás. Estás asumiendo un alto nivel de pista.
Marcin
4

Si bien dudo que sea posible al 100%, es posible que desee considerar Azure (o algo con un SLA similar) como una posibilidad. Lo que pasa:

Sus servidores son máquinas virtuales. Si alguna vez hay un problema de hardware en un servidor, su máquina virtual se traslada a una nueva máquina. El equilibrador de carga se encarga de la redirección para que el cliente no vea ningún tiempo de inactividad (aunque no estoy seguro de cómo se vería afectado el estado de sus sesiones).

Dicho esto, incluso con este error, la diferencia entre 99.999 y 100 limita con la locura.

Tendrá que tener control total sobre los siguientes factores.
- Factores humanos, tanto internos como externos, tanto malicia como impotencia. Un ejemplo de esto es alguien empujando algo al código de producción que derriba un servidor. Peor aún, ¿qué pasa con el sabotaje?
- Problemas comerciales. ¿Qué sucede si su proveedor se queda sin trabajo u olvida pagar sus facturas de electricidad, o simplemente decide dejar de respaldar su infraestructura sin suficiente advertencia?
- naturaleza. ¿Qué sucede si los tornados no relacionados golpean simultáneamente suficientes centros de datos para sobrecargar la capacidad de respaldo?
- Un entorno completamente libre de errores. ¿Está seguro de que no hay un caso límite con algún control de un sistema de terceros o núcleo que no se haya manifestado pero que aún pueda hacerlo en el futuro?
- Incluso si tiene control total sobre los factores anteriores, ¿está seguro de que el software / persona que lo supervisa no le presentará falsos negativos al verificar si su sistema está funcionando?

JSWork
fuente
2
Azure y EC2 han tenido recientemente fallas casi completas y totales. Creo que Azure fue retirado recientemente simplemente debido a una entrada de configuración incorrecta en un servidor DNS. De cualquier manera, gracias por la información.
NotMe
y si su balanceador de carga (que realiza la conmutación) pasa desapercibido (su monitor también podría pasar desapercibido, hasta el infinito) cuando el nodo se cae, todavía está atornillado.
Jwenting
1
Creo que querías decir 'incompetencia'. La 'impotencia' no debería tener un gran impacto en la capacidad del personal de TI para hacer su trabajo.
mfinni
4

Honestamente, el 100% es completamente loco sin al menos una vacilación en los términos de un ataque de piratería. Su mejor opción es hacer lo que hacen Google y Amazon en que tiene una solución de alojamiento geo-distribuido donde tiene su sitio y base de datos replicados en múltiples servidores en múltiples ubicaciones geográficas. Esto lo garantizará en cualquier cosa que no sea un desastre importante, como la columna vertebral de Internet que se corta a una región (que sucede de vez en cuando) o algo casi apocalíptico.

Pondría una cláusula para tales casos (DDOS, corte de la red troncal de Internet, ataque terrorista apocalíptico o una gran guerra, etc.).

Aparte de eso, mire los servicios en la nube de Amazon S3 o Rackspace. Esencialmente, la configuración de la nube no solo ofrecerá la redundancia en cada ubicación, sino también la escalabilidad y la distribución geográfica del tráfico junto con la capacidad de redirigir alrededor de las áreas geográficas fallidas. Aunque entiendo que la distribución geográfica cuesta más dinero.

Patricio
fuente
3

Solo quería agregar otra voz a la fiesta "se puede hacer (en teoría)".

No aceptaría un contrato que tuviera esto especificado, sin importar cuánto me pagaran, pero como problema de investigación, tiene algunas soluciones bastante interesantes. No estoy lo suficientemente familiarizado con las redes para delinear los pasos, pero imagino que una combinación de configuraciones relacionadas con la red + failovers de cableado eléctrico / hardware + failovers de software, posiblemente, en alguna configuración u otro trabajo realmente lo logre.

Casi siempre hay un solo punto de falla en algún lugar de cualquier configuración, pero si trabajas lo suficiente, puedes impulsar ese punto de falla para que sea algo que pueda repararse "en vivo" (es decir, el dns raíz baja, pero los valores aún se almacenan en caché en todas partes para que tengas tiempo de arreglarlo).

Una vez más, no digo que sea factible. Simplemente no me gustó cómo ni una sola respuesta abordó el hecho de que no es "muy fácil", simplemente no es algo que realmente quieran si lo piensan bien.

Mahmoud Al-Qudsi
fuente
3

Vuelva a pensar su metodología de medición de disponibilidad y luego trabaje con su cliente para establecer objetivos significativos .

Si está ejecutando un sitio web grande, el tiempo de actividad no es útil en absoluto. Si abandona las consultas durante 10 minutos cuando sus clientes más las necesitan (pico de tráfico), podría ser más perjudicial para el negocio que una interrupción de una hora a las 3 AM de un domingo.

A veces, las grandes empresas web miden la disponibilidad o la confiabilidad, utilizando las siguientes métricas:

  1. porcentaje de consultas que se responden con éxito, sin un error del lado del servidor (HTTP 500s).
  2. porcentaje de consultas que se responden por debajo de una cierta latencia objetivo .
  3. las consultas descartadas deben contar para sus estadísticas (ver más abajo).

La disponibilidad no debe medirse utilizando sondas de muestra, que es lo que puede informar una entidad externa como pingdom y pingability. No confíes únicamente en eso. Si desea hacerlo bien, cada consulta debe contar . Mida su disponibilidad observando su éxito real percibido.

La forma más eficiente es recopilar registros o estadísticas de su equilibrador de carga y calcular la disponibilidad en función de las métricas anteriores.

El porcentaje de consultas descartadas también debe contar para sus estadísticas. Se puede contabilizar en el mismo depósito que los errores del lado del servidor. Si hay problemas con la red o con otra infraestructura como DNS o los equilibradores de carga, puede usar las matemáticas simples para estimar cuántas consultas perdió . Si esperaba consultas X para ese día de la semana, pero obtuvo X-1000, probablemente eliminó 1000 consultas. Grafica tu tráfico en gráficos de consultas por minuto (o segundo). Si aparecen vacíos, eliminó las consultas. Use geometría básica para medir el área de esos espacios, lo que le da el número total de consultas descartadas.

Discuta esta metodología con su cliente y explique sus beneficios. Establezca una línea base midiendo su disponibilidad actual. Les quedará claro que el 100% es un objetivo imposible.

Luego puede firmar un contrato basado en mejoras en la línea de base. Digamos, si actualmente están experimentando el 95% de disponibilidad, podría prometer mejorar la situación diez veces al llegar al 98.5%.

Nota: existen desventajas en esta forma de medir la disponibilidad. Primero, recopilar registros, procesar y generar los informes usted mismo puede no ser trivial, a menos que use las herramientas existentes para hacerlo. En segundo lugar, los errores de la aplicación pueden dañar su disponibilidad. Si la aplicación es de baja calidad, servirá más errores. La solución a esto es considerar solo los 500 creados por el equilibrador de carga en lugar de los que provienen de la aplicación.

Las cosas pueden complicarse un poco de esta manera, pero es un paso más allá de medir solo el tiempo de actividad de su servidor .

Yves Junqueira
fuente
3

Si bien algunas personas notaron aquí, que el 100% es una locura o imposible , de alguna manera perdieron el punto real. Argumentaron que la razón de esto es el hecho de que incluso las mejores empresas / servicios no pueden lograrlo.

Bueno, es mucho más simple que eso. Es matemáticamente imposible .

Todo tiene una probabilidad. Podría haber un terremoto simultáneo en todos los lugares donde almacena sus servidores, destruyéndolos a todos. De acuerdo, es una probabilidad ridículamente pequeña, pero no es 0. Todos los proveedores de Internet podrían enfrentar un ataque terrorista / cibernético simultáneo. De nuevo, no es muy probable, pero tampoco cero. Independientemente de lo que proporcione, puede obtener un escenario de probabilidad que no sea cero, lo que reduce el servicio completo. Debido a esto, su tiempo de actividad tampoco puede ser del 100%.

Karoly Horvath
fuente
En realidad, me volvería loco o imposible y lo llamaría estúpido. Nada que los humanos sepan es 100%.
quadruplebucky
2

Ve a buscar un libro sobre control de calidad de fabricación usando muestreo estadístico. Una discusión general en este libro, cuyos conceptos a los que cualquier gerente habría estado expuesto en un curso de estadística general en la universidad, dicta los costos para pasar de 1 excisión en mil, a 1 en diez mil a 1 en un millón a 1 de cada mil millones aumenta exponencialmente. Esencialmente, la capacidad de alcanzar el 100% de tiempo de actividad costaría una cantidad casi ilimitada de fondos, algo así como la cantidad de combustible requerida para empujar un objeto a la velocidad de la luz.

Desde el punto de vista de la ingeniería de rendimiento, rechazaría el requisito tanto como no comprobable como irracional, de que esta expresión es más un deseo que un requisito verdadero. Con las dependencias de la aplicación que existen fuera de cualquier aplicación para redes, resolución de nombres, enrutamiento, defectos propagados a partir de componentes arquitectónicos subyacentes o herramientas de desarrollo, se convierte en una imposibilidad práctica que alguien garantice el 100% de tiempo de actividad.

James Pulley
fuente
1

No creo que el cliente realmente solicite un tiempo de actividad del 100%, o incluso un tiempo de actividad del 99.999%. Si miras lo que están describiendo, están hablando de retomar donde lo dejaron si un meteorito saca su centro de datos en el sitio.

Si el requisito es que las personas externas ni siquiera se dan cuenta, ¿qué tan drástico tiene que ser? ¿Sería aceptable volver a intentar una solicitud de Ajax y mostrar una ruleta durante 30 segundos al usuario final?

Ese es el tipo de cosas que le importan al cliente. Si el cliente realmente estaba pensando en SLA precisos, entonces sabrían lo suficiente como para expresarlo como 99.99 o 99.999.

Kevin Peterson
fuente
Si el cliente cree que quiere un "100% de tiempo de actividad" y es cuando termina en la palabrería del contrato, es posible que lo retengan si termina en la corte. Lo mejor es hablar y ayudar al cliente a comprender lo que realmente quiere en lugar de asumir que sabe lo que está pensando.
Chris S
Oh, estoy de acuerdo en que esto debe aclararse antes de entrar en un contrato. Solo digo que esto debe abordarse ya que el cliente no está comunicando lo que realmente quiere, en lugar de que el cliente esté pidiendo algo ridículo.
Kevin Peterson
1

mis 2 centavos Fui responsable de un sitio web muy popular para una compañía de Fortune-5 que publicaba anuncios para el Super Bowl. Tuve que lidiar con grandes picos en el tráfico y la forma en que lo resolví fue usar un servicio como Akamai. No trabajo para Akamai pero su servicio me pareció extremadamente bueno. Tienen su propio sistema DNS más inteligente que sabe que un nodo / host en particular está bajo una gran carga o está inactivo y puede enrutar el tráfico en consecuencia.

Lo bueno de su servicio era que realmente no tenía que hacer nada muy complicado para replicar el contenido de los servidores de mi propio centro de datos a su centro de datos. Además, sé que al trabajar con ellos, hicieron un uso intensivo de los servidores HTTP Apache.

Si bien no es 100% de tiempo de actividad, puede considerar tales opciones para dispersar contenido en todo el mundo. Según entendí las cosas, Akamai también tenía la capacidad de localizar el significado del tráfico si estaba en Michigan, obtenía contenido de un servidor de Michigan / Chicago y si estaba en California, supuestamente obtenía el contenido de un servidor con sede en California.

Kilo
fuente
-1 porque esta es una respuesta práctica pero no es útil en absoluto. Todas las preguntas en este sitio podrían responderse con "contratar a alguien más para que lo haga", pero no es por eso que estamos aquí.
Yves Junqueira
Siento disentir. "¿No es útil en absoluto?" Sin duda fue útil para mí y, al contrario de su comentario de "contratar a alguien más para que lo haga", ¿supongo que con su razonamiento el tipo debería zanjar su propio cable de fibra óptica y diseñar sus propios interruptores en lugar de comprarlos también? ¿Hablas en serio, Yves? Suena como alguien que no ha pasado mucho tiempo en el campo de TI.
Kilo
0

En lugar de una conmutación por error fuera del sitio, simplemente ejecute la aplicación desde dos ubicaciones simultáneamente, interna y externa. Y sincronice las dos bases de datos ... Luego, si el interno se cae, las personas internas aún podrán trabajar y las personas externas podrán usar la aplicación. Cuando lo interno vuelva a estar en línea, sincronice los cambios. Puede tener dos entradas DNS para un nombre de dominio o incluso un enrutador de red con round robin.

cristiano
fuente
0

Para los sitios alojados externamente, lo más cercano al 100% de tiempo de actividad es alojar su sitio en el motor de aplicaciones de Google y usar su almacén de datos de alta replicación (HRD) , que replica automáticamente sus datos en al menos tres centros de datos en tiempo real. Del mismo modo, los servidores front-end de App Engine se escalan / replican automáticamente.

Sin embargo, incluso con todos los recursos de Google y la plataforma más sofisticada del mundo, la garantía de tiempo de actividad de App Engine SLA es solo "99.95% del tiempo en cualquier mes calendario".

espeed
fuente
0

Simple y directo: Anycast

http://en.wikipedia.org/wiki/Anycast

Esto es lo que utiliza Cloudflare, Google y cualquier otra gran empresa para hacer redundancia, baja latencia, conmutación por error / equilibrio continental.

Pero también tenga en cuenta que es imposible tener un tiempo de actividad del 100%, y que los costos para pasar del 99.999% al 99.9999% son MUCHO mayores.

Leon Waldman
fuente