Actualmente tenemos una aplicación clásica de n niveles: DB / servicio web / front-end. Tiene otros componentes, pero es el diseño básico.

Queremos mejorar la disponibilidad de la aplicación por 3 razones principales:

1. Nuestro host a veces experimenta interrupciones (como todos lo hacen), y queremos minimizar el impacto en nuestros clientes, por lo que, por ejemplo, encenderían el centro de datos B si el centro de datos A no funciona.
2. Cuando actualizamos la versión, cerramos el sitio para realizar tareas de mantenimiento, y generalmente demora unas horas (secuencias de comandos de migración, etc.). Nos gustaría que los usuarios tengan una transición más fluida, con el mínimo tiempo de inactividad posible (usan el servidor B mientras se actualiza el servidor A).
3. Opcionalmente, nuestros clientes se encuentran en todo el mundo y queremos que tengan la mejor experiencia posible a pesar de sus posibles conexiones (cualquier persona que trabajó con desarrolladores indios debería saber a qué me refiero). Idealmente, nos gustaría poder conectar un servidor en su oficina (o usar un centro de datos cerca de su ciudad), y se integraría perfectamente en nuestra arquitectura.

No necesitamos remotamente el 99% de disponibilidad, ni siquiera el 95%. Es una aplicación de gestión de documentos. A nadie le importa. Pero como las migraciones pueden llevar un tiempo y hay clientes en todo el mundo, a veces evitamos que un cliente trabaje la mayor parte del día.

Para la parte de SQL, a pesar de que no hay DBA "adecuados", conocemos las posibilidades de SQL : replicación, duplicación, etc. En el lado de la base de datos, es bastante fácil encontrar recursos para esto. Lo que es más difícil es todo lo demás: almacenar sesiones, el código, etc. Si mi servidor de servicio web se cae, ¿cómo sabe mi IU que debe cambiar? ¿Cómo persisten mis sesiones en los servidores?

Desafortunadamente, ninguno de nosotros tiene experiencia en esta área, y ni siquiera sabemos por dónde empezar a buscar. ¿Hay mejores prácticas para esto? ¿Patrones de diseño? ¿Bibliotecas (que deberían ser gratuitas porque no tenemos dinero)?

Estamos usando ASP.Net y SQL Server, con un servicio web WCF en el medio. Tenemos un montón de servicios de Windows, pero no son de misión crítica, y supongo que los métodos para tratar con el sitio web serán aplicables a los servicios.

Entiendo que la mayoría de las plataformas en la nube proporcionan un sistema integrado para esto, pero el alojamiento en la nube es una opción imposible debido a nuestro administrador de sistemas, que quiere administrar todo por sí mismo y no depender de nadie.

Debe aclarar qué tipo de alta disponibilidad está buscando. Hay aplicaciones altamente disponibles que ejecuto que necesitan estar activas el 95% del tiempo. Hay otros que necesitan correr al 99%. Puedo pensar en escenarios de vida o muerte que requieren un tiempo de actividad del 100%. Solo esos tres tienen enfoques y costos drásticamente diferentes.

Solo adivinando en función de sus necesidades y un SLA de tiempo de actividad del 95-99%:

• Las migraciones de la base de datos deberían poder realizarse en tiempo real para la mayoría de los cambios. Practica el diseño de bases de datos evolutivas . Para los cambios que requieren un comportamiento más invasivo, tiene algunas opciones. Una es tomar el tiempo de inactividad. Si es posible, ejecutar su servicio en modo de solo lectura podría funcionar. Para una funcionalidad completa, he querido probar ScaleArc por un tiempo. Parece una herramienta realmente ingeniosa para el escalamiento y la resistencia en el mundo de SQL Server.
• Poner servidores dentro de los sitios de sus clientes es una receta para un desastre inmanejable a menos que tenga estrategias de implementación de clase mundial (que, según su descripción de sus migraciones, aún no las tiene). No promocione los servicios en la nube in situ porque tiene problemas de rendimiento. Resuelva los problemas de rendimiento de vez en cuando no tendrá que lidiar con los más costosos realizados en el camino.
• Su servidor de estado debe ser una base de datos de algún tipo. Siga sus pautas de HA. Puede usar SQL Server para esto, ya que ya lo tiene disponible.
• Hablando de bases de datos, la replicación no habilita HA. De hecho, la replicación SQL le causará dolores de cabeza en cada paso (hablando de la experiencia con escenarios de replicación de múltiples nodos). La duplicación puede funcionar, pero lo último que recuerdo es que la agrupación en clúster de SQL demora de 1 a 5 minutos en pasar al nuevo servidor. He escuchado cosas buenas sobre AlwaysOn, pero aún sospecho dada la trayectoria de Microsoft. Algo como ScaleArc podría ser más útil aquí.
• Su servidor web no debería tener estado. Gire tres o cuatro y colóquelos detrás de un equilibrador de carga. Eso resuelve sus preocupaciones de tiempo de actividad allí. Como Frederik mencionó anteriormente, también puede hacer implementaciones continuas de esta manera.
• Su servicio web probablemente debería ser apátrida. Si no, vea si puede dividirlo en bits sin estado y con estado. Poner varias instancias detrás del mismo equilibrador de carga nuevamente resuelve las preocupaciones de tiempo de actividad y permite escenarios de implementación más interesados ​​(por ejemplo, implementaciones azules / verdes).

A diferencia de Frederik, no llamaré a tu nube paranoia injustificada. Depende de sus requisitos de tiempo de actividad. Es concebible que un servicio tenga que ejecutarse en múltiples centros de datos operados por diferentes proveedores en diferentes países por motivos de redundancia. Sin embargo, dado su estado actual, estoy de acuerdo en que AWS, Azure o similares son probablemente apuestas seguras para su empresa.

Obtener un cierto nivel de HA en su nivel web y de aplicación:

1. Idealmente, factorice cualquier estado, incluido el estado de sesión en sistemas de estado compartido como una base de datos o un servidor de estado de sesión en memoria. Dependiendo del diseño de su aplicación, esto puede causar problemas de rendimiento debido a que la latencia adicional obtiene una gran cantidad de estado.

2. Su sitio web y nivel de aplicación deben tener un equilibrador de carga independiente frente a ellos. NGINX hará el truco, pero IIS también puede hacer esto (ARR).

3. Si una sola base de datos no puede manejar la carga, aproveche el particionamiento del estado de la sesión (o fragmentación o hashing coherente) para enrutar la solicitud particular a un cuadro de base de datos particular.

Si el estado de factorización es demasiado difícil, puede utilizar la afinidad del servidor para el equilibrio de carga (es decir, los usuarios se enrutan constantemente al mismo cuadro, a menudo basado en cookies). No está tan disponible como un enfoque de round robin sin estado, porque una interrupción de la caja afectará a todos los usuarios y estados en esa casilla, pero supera una interrupción completa (depende del caso de uso).

En el lado de la actualización:

1. Diseñe los scripts de su base de datos de tal manera que las actualizaciones de la base de datos se puedan realizar mientras el sistema se está ejecutando, en otras palabras, mantenga la compatibilidad con versiones anteriores. Un patrón que funciona bien para eso es "expandir, luego contraer" -> hacer solo cambios aditivos, compatibles con versiones anteriores, pero eliminando dependencias de los campos (etc.) de los que desea deshacerse; luego actualice todos los clientes de la base de datos a v-latest; luego haga otra actualización de db para deshacerse de los campos antiguos (etc.) en la base de datos. Este puede ser un proceso lento si tiene una base de datos grande y debe tener cuidado de no estropear el rendimiento de su sistema.

2. Actualización de su nivel de aplicación: dado que no está utilizando un entorno en la nube, le recomiendo que siga el patrón de implementación canario: realice una actualización continua de sus cuadros de nivel web y medio. Si la implementación falla, retire la caja del balanceador de carga, tal como lo haría como si hubiera fallado.

Palabra de advertencia: la evolución de un sistema que no ha sido diseñado para HA en uno que sí puede ser un proceso largo y costoso. Tendrá que hacer compensaciones en el camino (costo versus esfuerzo para alcanzar un nivel particular de disponibilidad)

Su paranoia en la nube no está justificada: los proveedores como AWS junto con las buenas prácticas de su parte pueden controlar / mitigar la mayoría de los riesgos, eche un vistazo a su página de cumplimiento para tener una idea de qué regulaciones cumplen: https: // aws .amazon.com / compliance /

TL; DR: Construir redundante, modular; prueba de disponibilidad; vigilar de cerca.

Después de darme cuenta de que tratar de exprimir cualquier explicación puede llevar mucho tiempo, escribiré todas las observaciones que he hecho.

Cuestionando la premisa

El sistema en la nube es la panacea

Incluso si tuviera que ir completamente a la nube, con un proveedor de nube superior, aún necesitará diseñar su aplicación para la resistencia, desde cero. AWS podría reemplazar su VM, pero su aplicación debería ser capaz de reiniciarse si se deja en el medio de la computación.

No queremos usar el sistema en la nube, debido a x / y / z

A menos que sea una organización ultra grande, es mejor que use sistemas en la nube. Los sistemas de nube Top-3 (AWS, MSFT, Google) emplean a miles de ingenieros para brindarle los SLA prometidos y el tablero fácil de administrar. En realidad, es una buena ganga usarlos en lugar de gastar un centavo en esta casa.

Problemas en el alcance y diseño

Definir, cuantificar y luego medir continuamente la disponibilidad de un servicio es un desafío mayor que escribir una solución para problemas de disponibilidad.

Definir y medir la "disponibilidad" es más difícil de lo esperado

Múltiples partes interesadas tienen una visión diferente de la disponibilidad, y lo que puede suceder es que la definición preferida por una persona con el salario más alto prevalezca sobre otra definición. Esta es a veces una definición correcta, pero a menudo el ecosistema no se basa en medir lo mismo porque esa definición ideal es mucho más difícil de medir, y mucho menos monitorear en tiempo real. Si tiene una definición de disponibilidad que no se puede monitorear en tiempo real, encontrará su proyecto similar que se hace a sí mismo una y otra vez con misteriosas similitudes. Quédese con algo que tenga sentido y algo que pueda ser monitoreado fácilmente.

La gente subestima las complejidades del sistema siempre disponible.

Para dirigirme al elefante en la habitación, permítanme decir esto: "No hay un sistema multi-computadora disponible al 100%, puede que en el futuro pero no con la tecnología actual". Aquí, por la tecnología actual, me refiero a nuestra incapacidad de enviar señales más rápido que la velocidad de la luz y esas cosas. Todos los ingenieros de comp-sci que valen la pena conocen las limitaciones informáticas distribuidas , y la mayoría de ellos no lo mencionarán en las reuniones, por temor a que parezcan novatos. Para compensar a todos aquellos que no mencionan las limitaciones de la computación distribuida , diré que es complicado pero no siempre confía en las computadoras .

Las personas sobreestiman las capacidades de sus ingenieros

Desafortunadamente, la disponibilidad cae en la categoría, donde no sabes lo que quieres pero sabes lo que no quieres. Es un poco más complicado que la categoría 'conocer los deseos', como la interfaz de usuario. Se requiere un poco de experiencia y mucha lectura para aprender de la experiencia de otros y algo más.

Construir un sistema disponible desde cero

Asegúrese de evangelizar a cada equipo de arquitectura y diseño sobre la prioridad correcta de la disponibilidad como un requisito del sistema.

Atributos del sistema que ayudan a la disponibilidad

Las siguientes características del sistema han demostrado haber contribuido a la disponibilidad del sistema:

Redundancia

Algunos ejemplos de esto son nunca tener una sola VM detrás de un VIP o nunca almacenar solo una copia de sus datos. Estas son las preguntas que un buen IAAS le facilitará resolver, pero aún tendrá que tomar estas decisiones.

Modularidad

Un REST modular es mejor que el SOA monolítico. Incluso hay un microservicio modular más disponible que el HATEOS REST habitual . El razonamiento se puede encontrar en la discusión relacionada con el rendimiento en la siguiente sección. Si está realizando un procesamiento por lotes, es mejor procesarlo en un lote razonable de 10 segundos en comparación con un lote de 1,000,000.

Resistencia

"I am always angry"
                    - Hulk

Un sistema resistente siempre está listo para recuperarse. Esta resistencia se aplica a instancias como el reconocimiento de ACK para una escritura solo después de escribir en el disco RAID, y posiblemente en al menos dos centros de datos. Otra tendencia reciente es utilizar estructuras de datos libres de conflictos , donde la estructura de datos asume la responsabilidad de resolver conflictos cuando se presentan dos versiones diferentes. Un sistema no puede ser resistente como una ocurrencia tardía, tiene que ser predicho e incorporado. Una falla está garantizada a largo plazo, por lo que siempre debemos estar preparados con un plan de recuperación.

Camino de registro

Este es técnicamente un subtipo de Resiliencia, pero muy especial debido a que atrapa todas las capacidades. A pesar del mejor esfuerzo, es posible que no podamos predecir el patrón de indisponibilidad. Si es posible, mantenga suficiente registro de las actividades del sistema para poder reproducir eventos del sistema. Esto, a un gran costo manual, le permitirá recuperarse de situaciones imprevistas.

Atributos de disponibilidad

La lista no exhaustiva de atributos de prioridad de la mente de 'disponibilidad': por el bien de la discusión, supongamos que la pregunta que hace el usuario es: "¿Cuántos artículos tengo en mi carrito de compras?"

Exactitud

¿ Debe producir la respuesta más precisa posible o está bien cometer errores? Solo como referencia, cuando retira dinero del cajero automático, no se garantiza que sea correcto. Si el banco descubre que cometió un error, podría revertir las transacciones. Si su sistema está produciendo números primos, entonces supongo que es posible que desee respuestas correctas todo el tiempo.

rendimiento

Omita este punto, si respondió siempre correcto para la pregunta del tema anterior. A veces la respuesta a las preguntas no tiene que ser precisa, por ejemplo, ¿cuántos amigos tengo en Facebook en este momento? Pero se espera que la respuesta esté en el estadio de béisbol +/- 1 todo el tiempo. Cuando está produciendo el resultado esperado, su rendimiento es de 100.

Consistencia

Su respuesta puede ser correcta en algún momento, pero para cuando la luz salga de la pantalla y entre en la retina del observador, las cosas podrían haber cambiado. ¿Hace que tu respuesta sea incorrecta? No, solo lo hace inconsistente. La mayoría de las aplicaciones son eventualmente consistentes, pero el truco es definir qué tipo de modelo de consistencia proporcionará su aplicación. Por casualidad, su aplicación puede ejecutarse en una sola computadora, puede omitir esta hermosa lectura sobre el teorema CAP .

Costo

Mucho depende del impacto total de los efectos a corto plazo (pérdida de ingresos) y los efectos a largo plazo (mala reputación, retención de clientes). Dependiendo del tipo de cliente (pago / gratuito, repetición / único, cautivo) y disponibilidad de recursos, se deben incorporar diferentes niveles de garantías de disponibilidad.

Hacia la mejora de la disponibilidad de un sistema existente

La gestión operativa de máquinas individuales y una red es tan compleja que supongo que se la ha dejado al proveedor de la nube o que ya es lo suficientemente experto como para saber lo que está haciendo. Tocaré otros temas bajo disponibilidad. Para la estrategia a largo plazo, Definir-Medir-Analizar-Control es una combinación celestial, algo que yo mismo he visto.

1. Defina qué es 'disponibilidad' para sus partes interesadas
2. ¿Cómo medirás lo que has definido?
3. Análisis de causa raíz para identificar cuellos de botella
4. Tareas para mejoras
5. Monitoreo ( control ) continuo del sistema.

Causas de falta de disponibilidad

Dado que acordamos que la gestión operativa que cubriría cualquier gestión de infraestructura física, debe ser realizada por profesionales, abordaré otras causas de indisponibilidad por razones de integridad. La disponibilidad de IMO también debe incluir la falta de comportamiento esperado, lo que significa que si al usuario no se le muestra la experiencia esperada, entonces algo no está disponible. Con esa definición amplia en mente, lo siguiente podría causar indisponibilidad: - Errores de código - Incidencias de seguridad - Problemas de rendimiento