¿Cuándo es el momento adecuado para introducir alta disponibilidad para el sitio web?

16

Hay muchos artículos sobre opciones de alta disponibilidad. Sin embargo, no es tan obvio CUANDO es el momento adecuado para cambiar de un solo servidor a una configuración de alta disponibilidad.

Tenga en cuenta mi situación:
http://www.postjobfree.com es un sitio web 24/7 con tráfico significativo:
http://www.similarweb.com/website/postjobfree.com

Actualmente lo ejecuto en un único servidor: tanto el servidor web IIS 7.0 como SQL Server 2008 se ejecutan en la misma caja de hardware.

Hay un tiempo de inactividad ocasional (~ uno por mes) ~ 5 minutos, generalmente causado por el reinicio requerido por alguna actualización de Windows Server. Por lo general, el tiempo de inactividad está programado y ocurre por la noche. Aún así es desagradable, porque Google Bot y algunos usuarios siguen activos durante la noche.

Los ingresos actuales del sitio web son de ~ $ 8K / mes.

Considero cambiar a la configuración de dos servidores (granja web de 2 servidores web y clúster de 2 servidores SQL alojados en dos servidores de hardware).

Pros:
1) Alta disponibilidad (teóricamente no hay tiempo de inactividad). Incluso si uno de los servidores se cae, otro servidor se haría cargo.
2) Sin pérdida de datos: sin el clúster SQL, se puede perder hasta un día de datos en caso de falla del hardware (hacemos copias de seguridad diarias).

Contras:
1) Más esfuerzo para configurar y mantener dicha configuración.
2) Mayor costo de alojamiento. En lugar de ~ $ 600 / mes sería alrededor de $ 1200 / mes.

¿Cuál sería tu recomendación?

— Dennis Gorelik
fuente

La respuesta a mi pregunta podría afectar el desarrollo. Por ejemplo, puedo considerar dividir la base de datos en partes y mantener los datos que requieren una alta confiabilidad (entrada del usuario) por separado de los datos que requieren un alto rendimiento (cálculos).

2

Hola Dennis, esto no es realmente una recomendación, así que lo pegué como un comentario, pero ¿sus costos de alojamiento parecen bastante altos para un solo servidor de Windows? Supongo que es un servidor totalmente dedicado (no una VM), pero incluso entonces debería considerar quizás la mitad de ese costo para un servidor de especificación decente con 8 GB de RAM, una buena cantidad de espacio en disco, etc. Podría valer la pena hablar con su empresa de hosting para obtener un mejor precio.

— Ewan Leith

66

Creo que la alta disponibilidad debe planificarse desde el primer momento de la concepción del proyecto.

— Tom O'Connor

Ewan, quiero que mi sitio web funcione rápido, así que tengo un procesador Quad con 8 GB de memoria y una unidad SDD. Tenga en cuenta el costo de las licencias de software (Windows, SQL Server), SSL y soporte técnico. ¿Tienes una buena solución con bajo precio para eso? Actualmente uso Server Intellect (respaldado por SoftLayer) para el alojamiento. ¿Recomendarías algo mejor?

— Dennis Gorelik

2

Las actualizaciones de Windows vienen con actualizaciones de seguridad. Si no parcho mi servidor, podría ser vulnerable a los ataques. ¿Qué frecuencia de actualización recomendaría para el servidor de producción de Windows?

— Dennis Gorelik

15

Respuesta corta: cuando el tiempo de inactividad o el riesgo de que le cueste le cuesta más de lo que le costaría tener alta disponibilidad.

Es fundamentalmente una decisión económica. Como ejemplo. $ 8k / mes implica que un corte de 2 horas le costará $ 22. Si puede configurar su sistema de manera que pueda pasar de cero a un sitio completamente funcional en 2 horas, la alta disponibilidad solo le otorgará $ 22 de funcionalidad por encima de eso.

Dicho de otra manera, puede ahorrar dinero a menos que tenga hasta 54 horas de tiempo de inactividad no evitable en un mes determinado.

— Slartibartfast
fuente

16

También debe considerar el riesgo para la reputación

— gbn

77

El costo por hora de tiempo de inactividad dependerá casi con certeza de cuándo se cae el servidor. Es muy poco probable que las transacciones se distribuyan uniformemente en un período de 24 horas. Es más normal que ocurra durante unas pocas horas pico, momento en el cual la pérdida sería mucho mayor.

— John Gardeniers

Slartibartfast, entiendo su respuesta de esa manera: asegúrese de que el tiempo de recuperación después de una falla catastrófica sea razonable (pocas horas), la pérdida de datos sea razonable (pocas horas) y permítame tener cortos tiempos de inactividad programados de vez en cuando (al menos por ahora) . Eso significaría tener copias de seguridad diarias, copias de seguridad parciales incrementales y un servidor disponible para restaurar toda esa configuración. ¿Suena bien?

— Dennis Gorelik

Respuestas: gbn: de acuerdo; Estaba buscando una explicación simple, pero la reputación podría ser un factor significativo. John Gardeniers: Claro, pero si el sitio solo se usa los domingos entre las 11:00 a.m. y la 1:00 p.m., el tiempo de inactividad programado no es realmente un problema, mientras que el precio de $ 2k por una interrupción no planificada de 2 horas ahora sí lo es. En ese momento, debe determinar qué tan probable es esa interrupción prematura (a un costo de $ 2k en ingresos) contra el cierto cargo de $ 600 / mes para el servidor adicional. Sugerencia: a menos que fallas aleatorias durante el período crítico sucedan con más frecuencia que 4 / año, no vale la pena.

— Slartibartfast

Dennis Gorelik: decida los riesgos contra los que desea protegerse (por ejemplo, pérdida de negocios durante el mantenimiento, pérdida del servidor, pérdida del centro de datos, cuenta / seguridad / violación de la base de datos) y actúe para protegerse contra ellos. En este caso, está protegiendo contra el tiempo de inactividad debido a mantenimiento y fallas impredecibles (por lo que puedo decir). Lo que describas debería hacer el truco, pero ten en cuenta que no tienes que ser el propietario del servidor siempre y cuando puedas estar seguro de que puedes conseguirlo y configurarlo en el período de restauración.

— Slartibartfast

11

Sus partes interesadas / gente de negocios (¡que podría ser usted!) Tienen que decidir

pérdida aceptable de ingresos
consecuencias pérdida de reputación, respetabilidad, etc.
pérdida de datos aceptable ( objetivo del punto de recuperación )
tiempo de inactividad aceptable ( objetivo de tiempo de recuperación )

La pérdida de ingresos es fácil de cuantificar: el resto no se puede responder aquí, lo siento ...

— gbn
fuente

2

Creo que la mayoría de los usuarios pueden manejar un poco de tiempo de inactividad programado. Tenga en cuenta que eBay tiene actualizaciones semanales los viernes por la noche, y las ofertas a veces no funcionan. La banca en línea de mi (principal banco australiano) ha programado interrupciones durante horas cada semana. Twitter se desconecta todo el tiempo. Heroku / EC2 estuvo inactivo durante días recientemente.

Lo mantendría en esa perspectiva, si realmente solo estás hablando 5 minutos al mes, estás haciendo un buen trabajo como administrador de sistemas.

— Chris
fuente

1

Ya mencionó a Google como un factor en términos de indexación, pero también puede valer la pena considerar el impacto que la latencia / capacidad de respuesta del sitio puede tener en el SEO. Es una caja negra y todo eso, tan difícil de cuantificar, aunque por lo que vale, Matt Cutts reconoce que es un uno por ciento . Me preocuparía más la reputación, como han dicho otros.

1

Tenga en cuenta que HA, como la seguridad, no es un producto, sino un proceso.

Por ejemplo, la replicación de la base de datos solo lo llevará al punto donde cada espejo de la base de datos podrá continuar por sí solo, pero también necesitará una estrategia para la resincronización después de que se hayan reemplazado los componentes fallidos.

Considere un sistema de pedidos como ejemplo: el cliente envía un pedido y, durante el procesamiento, el sistema físico con el que estaba hablando falla después de almacenar la información del pedido en su copia local de la base de datos. Impaciente, el cliente presiona "enviar" nuevamente y es dirigido a otro servidor, que acepta el pedido. Si sus bases de datos se vuelven a sincronizar simplemente repitiendo las instrucciones INSERT que faltan en el otro lado, entonces el orden se duplicará, lo que puede no ser lo que desea.

Como sugirió @Slartibartfast, todo se reduce a una decisión económica, sin embargo, le recomiendo que también planee algunos años en el futuro aquí. Si espera necesitar una configuración de HA adecuada entonces, ahora sería un buen momento para reservar recursos para el trabajo preparatorio.

— Simon Richter
fuente

1

Mientras piensas en esto, creo que consideras configurar una página de "ballena falsa".

Hay muchas maneras de hacer esto, pero el combo aws de route53 y s3 funciona bien en mis sitios pequeños.

Configuré el dominio con comprobaciones de estado para que, en caso de error, el DNS envíe a los usuarios a los usuarios a una página html estática en s3; Cuesta casi nada.

En mi experiencia, hacer que su sitio diga "lo siento, las cosas están rotas pero estamos trabajando en ello" hace una gran diferencia para los usuarios. Una cuenta de Twitter donde puede comunicarse con los usuarios, incluso es aún mejor.

Esto lleva mucho tiempo para mitigar la "pérdida de reputación" que puede ser el impacto más significativo de una interrupción.

consulte: https://aws.amazon.com/blogs/aws/create-a-backup-website-using-route-53-dns-failover-and-s3-website-hosting/ para obtener una guía sobre cómo configurarlo.

La conmutación por error social de DynDns http://dyn.com/managed-dns/social-failover/ es un tipo de cosa similar .

Puede rodar el suyo y hacer sus comprobaciones de estado y luego escribir los cambios de DNS, siempre que sus registros DNS tengan un TTL bajo y tenga alguna forma de manipularlos mediante programación.

— Nath
fuente

¿Estas verificaciones de salud deben ejecutarse desde el mismo servidor que aloja DNS? No puedo imaginar cómo hacer una actualización de DNS condicional.

— Dennis Gorelik

@DennisGorelik no es necesario, pero sus registros DNS necesitan un TTL corto y lo que sea que esté haciendo su comprobación de salud debe poder cambiar los registros rápidamente. Se actualizó la respuesta con más información sobre cómo lograr esto.

— Nath

El TTL corto para DNS en combinación con la dependencia del control de estado puede hacer que el sistema general sea un poco menos estable (puede cambiar incluso si el servidor principal funciona bien). En realidad, puede empeorar la situación para los usuarios finales, no mejorarla.

— Dennis Gorelik

El TTL corto por sí solo no debería ser un problema con ningún proveedor de DNS decente y si establece una barra bastante baja en sus comprobaciones de salud (es decir, conmutación por error si no hay http 200s durante 10 minutos), entonces la estabilidad no es un problema. Alternativamente, puede omitir la parte de control de salud y realizar un corte manual. Esto significará un período de tiempo más largo cuando los usuarios obtengan un "tiempo de espera de conexión" y otros errores desagradables, pero sin posibilidad de falsos positivos.

— Nath

0

¿Ha considerado usar algo como EC2 que le permitirá escalar de manera flexible y también negar sus desventajas? En última instancia, es una decisión económica si vale la pena usar EC2 o no, pero al menos es una opción a considerar.

— manku
fuente

-2

Para evitar la pérdida de datos, debe buscar configuraciones de Raid antes de los clústeres. También debe configurar una IP de conmutación por error que pueda cambiar de un servidor a otro en caso de desastre sin tener que esperar la propagación del DNS.

— yqt
fuente

¿De donde viene esto? ¿Qué te hace pensar que el póster ya no está usando RAID?

— Chopper3

Picador 3. Todo lo que dije es que Raid resolvería su problema de pérdida de datos.

— yqt

2

¿Cómo? si un disco murió seguro, pero ¿qué pasa si su controlador salió mal

— Chopper3