¿Cómo se diseña la arquitectura de alta disponibilidad "multiactivo en diferentes lugares"?

0. Prólogo

Los servicios en segundo plano se pueden dividir en dos categorías, con estado y sin estado. La alta disponibilidad es relativamente simple para las aplicaciones sin estado Las aplicaciones sin estado pueden resolverse bien solo a través de F5 o cualquier proxy. La siguiente descripción es principalmente para el análisis de servicios con estado.

El mantenimiento del estado del servidor se guarda principalmente a través del disco o la memoria, como la base de datos MySQL, redis y otras bases de datos de memoria. Además de estos dos tipos de métodos de mantenimiento, también existe el mantenimiento del estado de la memoria jvm, pero el ciclo de vida del estado de jvm suele ser muy corto.

1. Algunas soluciones para alta disponibilidad

La alta disponibilidad, desde el punto de vista del desarrollo, ha pasado aproximadamente por los siguientes procesos:

• modo de espera en frío

• Espera activa

• Doble vive en la misma ciudad

• remoto activo

• Vive más en diferentes lugares

Cuando hablemos de vivir en diferentes lugares, veamos primero algunas otras soluciones, que nos ayudarán a comprender las razones de muchos diseños.

1.1 Espera en frío

Espera en frío, al detener la capacidad de la base de datos para servir externamente, el método de operación de realizar copias de seguridad y archivar datos rápidamente mediante la copia de archivos. En resumen, el modo de espera en frío es copiar y pegar, que se puede completar rápidamente mediante el comando cp en Linux. Se puede hacer manualmente o mediante scripts programados. Existen los siguientes beneficios:

• Simple

• Copia de seguridad rápida (en comparación con otros métodos de copia de seguridad)

• Rápida recuperación. Solo necesita volver a copiar el archivo de copia de seguridad en el directorio de trabajo para completar el proceso de recuperación (o modificar la configuración de la base de datos, modificar directamente el directorio de copia de seguridad en el directorio de trabajo de la base de datos). Además, la recuperación se puede completar instantáneamente con dos comandos mv.

• Se puede restaurar según el momento. Por ejemplo, se sacó una gran cantidad de dinero de la escapatoria del cupón de Pinduoduo que ocurrió hace unos días, y se puede restaurar de acuerdo con el punto anterior en el tiempo para "recuperar la pérdida".

Los beneficios anteriores son una buena manera para el software anterior. Pero para muchos escenarios hoy en día, ya no es fácil de usar, porque:

• El servicio debe estar inactivo. N nueves definitivamente no se puede hacer. Luego, en el pasado, nuestra copia de seguridad en frío del tiempo de inactividad se realizaba cuando nadie la estaba usando temprano en la mañana, pero ahora muchas aplicaciones de Internet ya son globales, por lo que la gente las está usando en cualquier momento.

• datos perdidos. Si no se toman medidas, los datos desde el momento de la copia de seguridad hasta el momento de la restauración se perderán después de que se complete la recuperación de datos. El método tradicional consiste en restaurar manualmente los datos a través de los registros de la base de datos después de la restauración en modo de espera en frío. Por ejemplo, a través de los registros de rehacer, además, he usado registros comerciales para reproducir manualmente las solicitudes de restauración de datos. La recuperación es un gran esfuerzo físico con una alta tasa de error y un largo tiempo de recuperación.

• La copia de seguridad en frío es una copia de seguridad completa. La copia de seguridad completa provocará una pérdida de espacio en disco y una capacidad insuficiente, que solo se puede solucionar copiando la copia de seguridad en otros dispositivos móviles. Por lo tanto, todo el proceso de copia de seguridad lleva más tiempo.

• Imagine la cantidad de disco duro móvil y el tiempo que se necesita para copiar varios terabytes de datos al disco duro móvil todos los días. Además, la copia de seguridad completa no se puede personalizar, por ejemplo, solo ciertas tablas no se pueden respaldar.

Cómo sopesar los pros y los contras de la copia de seguridad en frío es algo que toda empresa debe tener en cuenta.

1.2 Espera activa

En comparación con la copia de seguridad en frío, la principal diferencia entre la copia de seguridad en caliente y la copia de seguridad en frío es que no necesita apagarse y proporciona servicios mientras se realiza la copia de seguridad. Pero aún debe apagarse al restaurar. Dado que lo que estamos discutiendo está relacionado con el almacenamiento, el método de compartir discos no se considera una copia de seguridad en caliente de dos máquinas.

1.2.1 Modo activo/en espera

Equivalente a 1 maestro y 1 esclavo, el nodo maestro proporciona servicios externos y el nodo esclavo actúa como respaldo. De alguna manera, los datos se sincronizan desde el nodo maestro al nodo esclavo, y cuando ocurre una falla, el nodo esclavo se establece como un nodo de trabajo. El método de sincronización de datos puede ser a nivel de software oa nivel de hardware. A nivel de software, como el método maestro/esclavo de mysql, a través del método de sincronización binlog; el método de replicación de suscripción de sqlserver. A nivel de hardware, los datos se copian en otro disco a través de tecnologías de duplicación, como la intercepción de sectores y discos. El enfoque orientado al hardware también se denomina recuperación ante desastres a nivel de datos; el enfoque orientado al software se denomina recuperación ante desastres a nivel de aplicación. El siguiente artículo hablará más sobre la recuperación ante desastres a nivel de aplicación.

1.2.2 Copia de seguridad mutua de dos máquinas

En esencia, sigue siendo Activo/En espera, pero solo se dominan mutuamente. La copia de seguridad mutua de dos máquinas no funciona para la misma empresa, pero desde la perspectiva del servidor, aprieta mejor los recursos disponibles. Por ejemplo, dos empresas tienen bibliotecas A y B respectivamente y se implementan a través de dos máquinas P y Q. Entonces, para el negocio A, P es maestro y Q es esclavo, y para el negocio B, Q es maestro y P es esclavo. En general, parece que las dos máquinas están activas y en espera la una de la otra. Bajo esta arquitectura, la separación de lectura y escritura es muy buena, la escritura única y la lectura múltiple reducen los conflictos y mejoran la eficiencia.

Otras soluciones de alta disponibilidad también pueden referirse a varios modos de implementación de varias bases de datos, como mysql master-slave, dual-master multi-slave, MHA; redis master-slave, sentinel, cluster, etc.

1.3 Vida activa dentro de la ciudad

Los diversos esquemas mencionados anteriormente se llevan a cabo básicamente en una red de área local. Después de que el negocio se desarrolla, hay un plan para vivir más en la misma ciudad. En comparación con el anterior, la granularidad de la desconfianza ha cambiado de la máquina a la sala de ordenadores. Esta solución puede solucionar la situación de que una sala de ordenadores IDC se cuelgue en su conjunto (corte de luz, desconexión de red, etc.).

De hecho, no existe una diferencia esencial entre el activo dual en la misma ciudad y el respaldo en caliente de máquina dual mencionado anteriormente, pero la "distancia" es mayor y es básicamente la misma (la velocidad de red de la línea privada en la misma ciudad sigue siendo muy rápida). La copia de seguridad en caliente de dos máquinas proporciona capacidades de recuperación ante desastres, y la copia de seguridad mutua de dos máquinas evita el desperdicio excesivo de recursos.

Con la ayuda de los códigos de programa, algunas empresas también pueden lograr verdadero activo-activo, es decir, el mismo negocio, maestros duales, proporcionando lectura y escritura al mismo tiempo, siempre que los conflictos se manejen bien. Cabe señalar que no todas las empresas pueden hacer esto.

La industria adopta más a menudo la práctica de tres centros en dos lugares. La sala de computadoras de respaldo remoto puede proporcionar mayores capacidades de recuperación ante desastres y resistir mejor terremotos, ataques terroristas y otras situaciones. Las máquinas activo-activo deben implementarse en la misma ciudad, y las ciudades más lejanas sirven como salas de computadoras de recuperación ante desastres. La sala de cómputo de recuperación ante desastres no proporciona servicios externos, solo se usa como respaldo y el tráfico se cambia a la sala de cómputo de recuperación ante desastres cuando ocurre una falla, o solo se usa como respaldo de datos. La razón principal es que la distancia es demasiado grande y el retraso de la red es demasiado grande.

Figura 1 Tres Centros en Dos Lugares

Como se muestra en la figura anterior, la carga del tráfico del usuario se equilibra y el tráfico del servicio A se envía al IDC1 y al conjunto de servidores A; el tráfico del servicio B se envía al IDC2 y al servidor B; al mismo tiempo, el servidor configura un yb realizar líneas arrendadas dentro de la ciudad desde A y B respectivamente. Los datos se sincronizan y se sincronizan con IDC3 a través de una línea dedicada fuera del sitio de larga distancia. Cuando cualquier IDC falla, cambie todo el tráfico a otra sala de computadoras de IDC en la misma ciudad para completar la conmutación por error.

Cuando ocurre una falla a gran escala en la ciudad 1, por ejemplo, un terremoto hace que IDC1 y 2 dejen de funcionar al mismo tiempo, los datos se conservarán en IDC3. Al mismo tiempo, si el equilibrio de carga sigue siendo válido, todo el tráfico se puede reenviar a IDC3. Sin embargo, en este momento, la sala de computadoras IDC3 está muy lejos y la demora en la red se vuelve muy grave, por lo general, la experiencia del usuario se verá seriamente afectada.

Figura 2 Modo maestro-esclavo de dos lugares y tres centros

La imagen de arriba es un diagrama esquemático de dos lugares y tres centros basados ​​en el modelo Maestro-Esclavo. Las dos salas de computadoras en la ciudad 1 actúan como maestra y una esclava, y la sala de computadoras remota actúa como esclava. También puede utilizar el método de maestros duales en la misma ciudad + keepalived + vip, o el método de MHA para realizar la conmutación por error. Pero la ciudad 2 no puede (preferiblemente no) ser seleccionada como Maestra.

1.4 Remoto Activo-Activo

Activo-activo en la misma ciudad puede manejar la mayoría de las situaciones de recuperación de desastres, pero los servicios aún se interrumpirán en caso de un corte de energía a gran escala o un desastre natural. Renueve los tres centros anteriores en dos lugares, implemente aplicaciones y nodos de entrada front-end en diferentes lugares, y cambie el tráfico a la ciudad 2 después de que la ciudad 1 deje de prestar servicio, lo que se puede degradar y reducir la experiencia del usuario. Sin embargo, la experiencia del usuario ha disminuido significativamente.

Por lo tanto, la mayoría de las empresas de Internet han adoptado la solución activa-activa remota.

Figura 3 Diagrama esquemático simple de remoto activo-activo

La figura anterior es un diagrama esquemático de un simple remoto activo-activo. El tráfico se distribuye a los clústeres de servidores en las dos ciudades después de pasar por el LB. Los clústeres de servidores solo están conectados a los clústeres de bases de datos locales. Solo cuando no se puede acceder a todos los clústeres de bases de datos locales, se conmutarán por error a los clústeres de bases de datos remotas.

De esta forma, la sincronización bidireccional lleva más tiempo debido a problemas de red remota. Los tiempos de sincronización más prolongados darán como resultado una degradación más severa del rendimiento o colisiones de datos. El rendimiento y la contención son dos cuestiones opuestas, y es necesario hacer un compromiso entre ellas. Por ejemplo, para resolver conflictos, introduzca bloqueos distribuidos/transacciones distribuidas; para lograr un mayor rendimiento, use estados intermedios, reintentos de error, etc. para lograr la consistencia final; es posible completar la transacción completa en un nodo.

Para algunas empresas que no pueden aceptar la consistencia eventual, Ele.me adopta el método que se muestra en la figura a continuación:

Para aplicaciones individuales con requisitos de alta consistencia, proporcionamos una solución sólida y consistente (Zona global). La Zona global es un mecanismo de separación de lectura y escritura entre salas. Todas las operaciones de escritura se dirigen a una sala de computadoras principal para Para garantizar la consistencia, las operaciones de lectura pueden puede realizarse en la biblioteca Slave de cada sala de cómputo, o puede vincularse a la sala de cómputo Master. Todo esto se hace en base a nuestra capa de acceso a la base de datos (DAL), y el negocio es básicamente inconsciente.

—— "Introducción general a la implementación remota de tecnología multi-live de Ele.me (1)"

En otras palabras, no se puede realizar activo-activo en esta área. Adoptar el maestro en lugar de la doble escritura resuelve naturalmente el problema de los conflictos.

De hecho, el activo-activo remoto y el multiactivo remoto ya son muy similares, y la estructura de activo-activo es más simple, por lo que no es necesario pensar demasiado en la arquitectura del programa, y ​​​​solo es necesario limitar la corriente tradicional, conmutación por error y otras operaciones. Pero, de hecho, activo-activo es solo un paso temporal, y el objetivo final es cambiar a multiactivo. Debido a que HyperMetro tiene problemas con los conflictos de datos, no puede escalar horizontalmente.

1.5 Vive más en diferentes lugares

Figura 4 Diagrama esquemático de múltiples actividades en diferentes lugares

De acuerdo con la idea de vivir-activo en diferentes lugares, podemos dibujar un diagrama esquemático de multi-activo en diferentes lugares. El grado de entrada y salida de cada nodo es 4. En este caso, cualquier nodo que se desconecte no afectará el negocio. Sin embargo, teniendo en cuenta la distancia, una operación de escritura generará una mayor sobrecarga de tiempo. Además de afectar la experiencia del usuario, la sobrecarga de tiempo también genera más conflictos de datos. En conflictos de datos severos, el costo de usar bloqueos distribuidos también es mayor. Esto aumentará la complejidad del sistema y disminuirá el rendimiento. Por lo tanto, la solución que se muestra arriba no se puede utilizar.

¿Recuerda cómo optimizamos al resolver la topología de la red de malla? Introducir nodos intermedios y cambiar la malla a estrella:

Figura 5 Multiactivo externo en forma de estrella

Después de transformarse a la imagen de arriba, la desconexión de cada ciudad no afectará los datos. Para el tráfico de la ciudad solicitada original, será re-LoadBalanced al nuevo nodo (preferiblemente LB a la ciudad más cercana). Para resolver el problema de la seguridad de los datos, solo necesitamos tratar con el nodo central. Pero de esta manera, los requisitos para la ciudad central serán más altos que otras ciudades. Por ejemplo, la velocidad de recuperación, la integridad de la copia de seguridad, etc., no se ampliarán aquí por el momento. Primero supongamos que el concentrador es completamente seguro.

Si hemos implementado el negocio multiactivo remoto como la estructura que se muestra en la figura anterior, el problema de la sincronización de datos en todas partes se ha resuelto en gran medida, pero aún habrá una gran cantidad de conflictos, que pueden considerarse simplemente como similares a activo dual. Entonces, ¿hay una mejor manera?

Aquí podemos relacionar la solución GlobalZone de Ele.me, la idea general es "des-distribuir", es decir, poner el negocio escrito en una máquina nodo (misma ciudad). Ali piensa de esta manera:

La arquitectura multiactiva remota ideal de Ali

De hecho, supongo que muchos negocios también se realizan de acuerdo con la imagen de arriba, como el negocio de taxis Didi, todos los negocios están divididos por ciudad. La latitud y longitud de los usuarios, propietarios de automóviles y destinos suelen estar en la misma ciudad. Un solo centro de datos no necesita interactuar con otros centros de datos, solo es necesario cuando se generan informes, pero los informes no prestan mucha atención al rendimiento en tiempo real. Bueno, en este caso, el negocio nacional se puede fragmentar muy bien.

Sin embargo, para escenarios complejos y negocios como el comercio electrónico, la fragmentación de la manera mencionada anteriormente ya no puede satisfacer las necesidades. Debido a que la línea de negocios es muy compleja y las dependencias de datos también son muy complejas, es inevitable que cada centro de datos sincronice los datos entre sí. La solución de Taobao es algo similar a cómo dividimos los microservicios:

La arquitectura multiactiva remota de Taobao dividida por unidad

Preste atención a las flechas de sincronización de datos en la figura. Tomando como ejemplo la unidad de transacción, los datos comerciales que pertenecen a la unidad de transacción se sincronizarán con la unidad central en dos direcciones; los datos comerciales que no pertenecen a la unidad de transacción se sincronizarán desde la unidad central en una dirección. La unidad central se encarga de los escenarios de negocio más complejos y la unidad de negocio se encarga de escenarios relativamente únicos. Para las unidades de negocio, se puede realizar escalado elástico y recuperación ante desastres; para las unidades centrales, la escalabilidad es pobre y los requisitos de estabilidad son más altos. Se puede observar que la mayoría de las fallas ocurrirán en la unidad central.

La segmentación de unidades según el negocio ya requiere una transformación completa del código y la arquitectura (tal vez por eso Ali cambió de activo-activo a multiactivo, lo que tomó 3 años). Por ejemplo, división de negocios, división de dependencias, malla a estrella, transacciones distribuidas, invalidación de caché, etc. Además de los altos requisitos para la codificación, también existen grandes desafíos para las pruebas, la operación y el mantenimiento.

En una situación tan complicada, cómo automatizar la cobertura, cómo realizar simulacros y cómo transformar la tubería. Este nivel de recuperación ante desastres no es algo que las empresas ordinarias se atrevan a hacer, y la entrada y la salida no son directamente proporcionales. Sin embargo, todavía podemos usar este escenario como nuestro "enemigo imaginario" para pensar en nuestro propio negocio, cómo se desarrollará en el futuro y qué nivel de preparación para desastres necesitamos. En términos relativos, la solución multiactiva de Ele.me puede ser más adecuada para la mayoría de las empresas.

Este artículo solo ofrece una breve descripción mediante dibujos. De hecho, la vida múltiple en diferentes lugares requiere muchas capacidades básicas muy fuertes. Por ejemplo, transmisión de datos, verificación de datos, capa de operación de datos (simplifica el proceso de escritura y sincronización del control del cliente), etc.