Arquitectura de aprendizaje desde cero: arquitectura de almacenamiento de alta disponibilidad

Arquitectura de dos máquinas

La esencia de las soluciones de almacenamiento de alta disponibilidad es replicar datos en múltiples dispositivos de almacenamiento y lograr una alta disponibilidad a través de la redundancia de datos. La complejidad se refleja principalmente en cómo lidiar con la inconsistencia de datos causada por demoras e interrupciones en la replicación. Por lo tanto, para cualquier solución de almacenamiento de alta disponibilidad, debemos pensar y analizar desde los siguientes aspectos: ¿
Cómo replicar datos?
¿Cuáles son las responsabilidades de cada nodo?
¿Cómo lidiar con el retraso en la replicación?
¿Cómo lidiar con las interrupciones de la replicación?
Las arquitecturas comunes de almacenamiento de alta disponibilidad incluyen maestro-esclavo, maestro-esclavo, maestro-maestro, clúster y partición.

Replicación maestra/en espera

La replicación de copia de seguridad maestra es la solución de almacenamiento de alta disponibilidad más común y sencilla. Casi todos los sistemas de almacenamiento proporcionan la función de replicación de copia de seguridad maestra, como MySQL, Redis y MongoDB.

1. Implementación básica

El siguiente es un diagrama de estructura estándar del esquema maestro-respaldo:

2. Análisis de ventajas y desventajas.

• Ventajas:
  1. No hay necesidad de percibir la existencia de la máquina de respaldo
  2. Para el maestro y la copia de seguridad, ambas partes solo necesitan copiar datos, y no hay necesidad de realizar juicios de estado y operaciones de conmutación maestro-espera;

• Desventajas:
  1. La máquina en espera es solo para respaldo y no proporciona operaciones de lectura y escritura
  2. Se requiere intervención manual después de una falla y no se puede restaurar automáticamente;

• Escenario de uso:
  el sistema de gestión back-end interno a menudo utiliza la arquitectura de replicación maestro-esclavo, como el sistema de gestión de estudiantes, el sistema de gestión de empleados, el sistema de gestión de vacaciones, etc., porque la frecuencia de los cambios de datos en dichos sistemas es baja, incluso si se pierde en algunos escenarios Los datos también se pueden completar manualmente

replicación maestro-esclavo

El maestro es responsable de las operaciones de lectura y escritura, y el esclavo solo es responsable de las operaciones de lectura, no de las operaciones de escritura.

1. Implementación básica

La siguiente es la arquitectura estándar de replicación maestro-esclavo:

2. Análisis de ventajas y desventajas.

• Ventajas:
  1. Cuando la replicación maestro-esclavo falla en el host, el negocio relacionado con la operación de lectura puede continuar ejecutándose
  2. El esclavo de la arquitectura de replicación maestro-esclavo proporciona operaciones de lectura, lo que aprovecha al máximo el rendimiento de el hardware;

• Desventajas:
  1. El cliente necesita percibir la relación maestro-esclavo y enviar diferentes operaciones a diferentes máquinas para su procesamiento
  2. Si el retraso de la replicación maestro-esclavo es relativamente grande, se producirán problemas comerciales debido a la inconsistencia de los datos 3.
  Intervención manual se requiere en caso de falla;

• Escenarios de uso:
  los escenarios comerciales con menos escrituras y más lecturas usan más arquitecturas de replicación maestro-esclavo. Por ejemplo, en foros, BBS, sitios web de noticias, etc., la cantidad de operaciones de lectura es 10 veces o incluso 100 veces mayor que la cantidad de operaciones de escritura.

pasar a otra cosa

Hay dos problemas comunes en la replicación maestro-esclavo y en los esquemas de replicación maestro-esclavo:

• 1. Después de que falla el host, no se puede realizar la operación de escritura;
• 2. Si no se puede restaurar el host, se debe asignar manualmente una nueva función de host;

El cambio de máquina dual se creó para resolver estos dos problemas, incluidos los esquemas de cambio maestro-esclavo y maestro-esclavo. En pocas palabras, estas dos soluciones consisten en agregar la función de "cambio" sobre la base de la solución original, es decir, el sistema determina automáticamente el rol del host y completa el cambio de rol.

Para lograr una solución de conmutación completa, se deben considerar varios puntos clave de diseño:

Juzgar el estado de las salas principal y de respaldo

• Canales para la transferencia de estado: ¿están conectados entre sí o el arbitraje de terceros?
• El contenido de la detección de estado: como si la máquina está apagada, si existe el proceso, si la respuesta es lenta, etc.

decisión de cambio

• Tiempo de cambio: ¿Bajo qué circunstancias se debe actualizar la máquina de reserva a la máquina principal? La máquina de respaldo se actualiza después de la falla de energía de la máquina o el proceso en el host no existe.
• Estrategia de cambio: después de que el host original se recupere de la falla, debe cambiarse nuevamente para garantizar que el host original continúe siendo el maestro, o el host original se convertirá automáticamente en la nueva máquina de respaldo después de que se recupere la falla.
• Grado de automatización: ¿El interruptor es completamente automático o semiautomático?

Resolución de conflictos de datos
Cuando se restaura el host fallido original, puede haber conflictos de datos entre los hosts antiguo y nuevo. Por ejemplo, el usuario agrega una pieza de datos con una ID de 100 en el antiguo host, pero estos datos no se han copiado en el antiguo servidor en espera.Después de recuperar el antiguo host defectuoso, cómo tratar los datos con ID duplicadas.

De acuerdo con los diferentes canales de transferencia de estado, existen tres formas comunes de arquitectura de conmutación activa-espera: interconexión, intermediación y simulación.

interconectado

La interconexión significa que las máquinas maestra y de reserva establecen directamente un canal para la transferencia de estado. Existe un problema de falla del canal de transferencia de estado. Puede ser

que la maestra envíe el estado a la copia de seguridad, o que la copia de seguridad llegue a la maestra para obtener información de estado. .
Puede compartirse con el canal de replicación de datos o puede ser un canal independiente. Para aprovechar al máximo la ventaja de que el esquema de conmutación puede determinar automáticamente el host, el cliente también
tendrá algunos cambios correspondientes.
Por ejemplo, IP virtual, el host debe vincular esta IP virtual.
2. El cliente registra las direcciones de las máquinas maestra y en espera al mismo tiempo;
3. Aunque la máquina en espera puede recibir la solicitud de operación del cliente, la rechazará directamente. El motivo del rechazo es "la máquina en espera no no prestar servicios externos”;

Desventajas de la interconexión:
1. Cuando falla el canal de transferencia de estado, la máquina de reserva también puede pensar que el maestro está defectuoso y actualizarse al maestro, lo que da como resultado dos maestros 2.
Si se agregan más canales para mejorar la confiabilidad de la transferencia de estado, solo reducirá La probabilidad de falla del canal no puede resolver fundamentalmente esta deficiencia, y cuantos más canales haya, más compleja será la toma de decisiones del estado.

Intermediario

El tipo de intermediario se refiere a la introducción de un intermediario externo además de las máquinas principal y de reserva. Las máquinas principal y de reserva no están conectadas directamente, pero están conectadas al intermediario, y la información de estado se transmite a través del intermediario.

Aunque el método del intermediario es más simple en términos de transferencia estatal y toma de decisiones estatal, existe el problema de cómo garantizar la alta disponibilidad del intermediario mismo. Si el intermediario deja de funcionar, todo el sistema entra en un estado de espera dual y los servicios relacionados con las operaciones de escritura no están disponibles.

El conjunto de réplicas de MongoDB adopta el método intermediario y el diagrama de arquitectura es el siguiente:

• MongoDB(M), nodo maestro: almacenar datos
• MongoDB(S): nodo en espera: almacenar datos
• MongoDB (A): Nodo Quorum: no almacena datos,
  el cliente se conecta a los nodos activo y standby.

Las soluciones de código abierto ya cuentan con soluciones intermedias relativamente maduras, como ZooKeeper y Keepalived. El propio ZooKeeper ha implementado una arquitectura de clúster de alta disponibilidad, por lo que nos ha ayudado a resolver el problema de confiabilidad del propio intermediario. En la práctica de la ingeniería, se recomienda construir una arquitectura de conmutación intermedia basada en ZooKeeper.

Cosa análoga

El modo de simulación significa que las máquinas maestra y de reserva no transmiten ningún dato de estado, pero la máquina de reserva simula como un cliente, inicia operaciones simuladas de lectura y escritura en la maestra y juzga el estado de la maestra de acuerdo con la respuesta de la lectura. y operaciones de escritura.

En comparación con la conmutación interconectada, la conmutación analógica tiene la ventaja de una implementación más sencilla, porque se omiten el establecimiento y la gestión de los canales de transferencia de estado.

La simplicidad es tanto una ventaja como una desventaja. Debido a que la información de estado obtenida por las operaciones de lectura y escritura analógicas es solo información de respuesta (por ejemplo, HTTP 404, tiempo de espera, tiempo de respuesta superior a 3 segundos, etc.), no es tan diversa como el tipo interconectado (además de la información de respuesta, también puede incluir carga de CPU, carga de E/S, rendimiento, tiempo de respuesta, etc.), tomando decisiones de estado basadas en estados finitos, puede haber desviaciones.

replicación maestro-maestro

La replicación maestro-maestro significa que ambas máquinas son hosts y copian datos entre sí, y el cliente puede seleccionar arbitrariamente una de las máquinas para operaciones de lectura y escritura.

La replicación maestro-maestro es generalmente mucho más simple. No requiere transmisión de información de estado, toma de decisiones de estado y cambio de estado, pero tiene restricciones en los escenarios de uso. Si se adopta la arquitectura de replicación maestro-maestro, los datos deben replicarse bidireccionalmente y muchos datos no se pueden copiar en ambas direcciones. Por ejemplo:

• 1. Si la ID de usuario generada después del registro del usuario aumenta de acuerdo con el número, no se puede copiar en ambas direcciones, de lo contrario, aparecerán varios hosts con la misma ID;
• 2. El inventario no se puede copiar en ambas direcciones.Si se reduce un host, el otro host también se reduce y se sobrescribirá después de la copia;

Por lo tanto, la arquitectura de replicación maestro-maestro tiene requisitos estrictos en el diseño de datos y, en general, es adecuada para esos escenarios de datos temporales, que se pueden perder y sobrescribir. Por ejemplo, los datos de la sesión generados por el inicio de sesión del usuario (se pueden generar al volver a iniciar sesión), los datos del registro de comportamiento del usuario (se pueden perder), los datos del borrador del foro (se pueden perder), etc.

Clusters y Particiones

grupo de datos

Las arquitecturas maestro-esclavo, maestro-esclavo y maestro-maestro tienen una suposición implícita en esencia: el host puede almacenar todos los datos, y las capacidades de almacenamiento y procesamiento del propio host son limitadas. Un solo servidor definitivamente no puede almacenar y procesar, debemos usar múltiples servidores para almacenar datos, esta es la arquitectura de clúster de datos.

Un clúster es una combinación de múltiples máquinas para formar un sistema unificado. Las "múltiples máquinas" aquí son al menos 3 en número; en comparación, hay 2 máquinas para el maestro y el esclavo, y el maestro y el esclavo. De acuerdo con los diferentes roles asumidos por las máquinas en el clúster, los clústeres se pueden dividir en dos tipos: clústeres centralizados de datos y clústeres descentralizados de datos.

agrupación de datos

1 maestro con múltiples copias de seguridad o 1 maestro con múltiples esclavos. Ya sea 1 maestro y 1 esclavo, 1 maestro y 1 copia de seguridad, o 1 maestro y varias copias de seguridad, y 1 maestro y varios esclavos, los datos solo se pueden escribir en el host y la operación de lectura puede ser flexible y modificable consultando a la arquitectura maestro-esclavo y maestro-esclavo. La siguiente figura muestra una arquitectura que lee y escribe todos los datos en el host:

Aunque la arquitectura es similar, debido a la gran cantidad de servidores en el clúster, la complejidad general es mayor, lo que se refleja específicamente en:

• 1. ¿Cómo copia el host los datos a la máquina en espera?

En las arquitecturas maestro-esclavo y maestro-esclavo, solo hay un canal de replicación, mientras que en la arquitectura de clúster de conjunto de datos, hay múltiples canales de replicación. Múltiples canales de replicación primero aumentarán la presión de la replicación del host. En algunos escenarios, debemos considerar cómo reducir la presión de la replicación del host o reducir la presión de la replicación del host en lectura y escritura normales.

En segundo lugar, múltiples canales de replicación pueden causar inconsistencia de datos entre múltiples máquinas de respaldo.En algunos escenarios, necesitamos verificar y corregir la consistencia de datos entre las máquinas de respaldo.

• 2. ¿Cómo detecta la máquina de reserva el estado de la máquina principal?

En la arquitectura maestro-esclavo y maestro-esclavo, solo una máquina en espera necesita juzgar el estado del maestro. En la arquitectura de clúster de concentración de datos, varias máquinas de copia de seguridad deben juzgar el estado del host, y los resultados de juicio de diferentes máquinas de copia de seguridad pueden ser diferentes. problema complicado?

• 3. Después de que falla el host, cómo determinar un nuevo host

En la arquitectura maestro-esclavo, si el maestro falla, la máquina de respaldo puede actualizarse al maestro; mientras que en la arquitectura de clúster centralizado de datos, varias máquinas de respaldo pueden actualizarse al maestro, pero de hecho solo se permite que una máquina de respaldo actualizarse al maestro, entonces, ¿qué máquina de respaldo elegir como el nuevo maestro y cómo coordinar entre las máquinas de respaldo?

El clúster de conjuntos de datos de código abierto actual suele ser ZooKeeper. ZooKeeper resuelve los problemas mencionados anteriormente a través del algoritmo ZAB, pero la complejidad del algoritmo ZAB es muy alta.

Clúster disperso de datos

El clúster de datos dispersos se refiere a múltiples servidores que forman un clúster, y cada servidor es responsable de almacenar parte de los datos; al mismo tiempo, para mejorar la utilización del hardware, cada servidor realiza una copia de seguridad de parte de los datos.

La complejidad de los clústeres descentralizados de datos radica en cómo distribuir los datos a diferentes servidores. El algoritmo debe considerar estos puntos de diseño:

• Equilibrio
  El algoritmo debe asegurarse de que las particiones de datos en el servidor estén básicamente equilibradas, y la cantidad de particiones en un servidor no puede ser varias veces mayor que la de otro servidor.

• Tolerancia a fallas
  Cuando ocurre una falla parcial del servidor, el algoritmo necesita asignar la partición de datos asignada originalmente al servidor fallido a otros servidores.

• Escalabilidad
  Cuando la capacidad del clúster es insuficiente y se expanden nuevos servidores, el algoritmo puede migrar automáticamente algunas particiones de datos a los nuevos servidores y garantizar el equilibrio de todos los servidores después de la expansión.

La diferencia entre un clúster disperso de datos y un clúster centralizado de datos es que cada servidor en un clúster disperso de datos puede manejar solicitudes de lectura y escritura, por lo que no existe un rol como el de un host responsable de escribir en un clúster centralizado de datos. Sin embargo, en un clúster de datos distribuidos, debe haber un rol responsable de ejecutar el algoritmo de asignación de datos, este rol puede ser un servidor independiente o un servidor elegido por el propio clúster. Si el servidor del clúster elige una máquina para asumir la responsabilidad de la asignación de particiones de datos, este servidor generalmente también se denomina host, pero necesitamos conocer el "host" aquí y el "host" en el clúster de datos.

La implementación de Hadoop es que un servidor independiente se encarga de la asignación de particiones de datos, y este servidor se llama Namenode. La arquitectura de gestión de particiones de datos de Hadoop es la siguiente:

Sitio web oficial de Hadoop: arquitectura HDFS

La siguiente es la explicación oficial de Hadoop, que puede explicar la forma básica de gestión centralizada de particiones de datos.

• HDFS adopta una arquitectura maestro/esclavo. Un clúster HDFS consta de un Namenode y una cierta cantidad de Datanodes.
• Namenode es un servidor central responsable de administrar el espacio de nombres del sistema de archivos y el acceso de los clientes a los archivos.
• El Datanode en el clúster es generalmente un nodo, que es responsable de administrar el almacenamiento en el nodo donde se encuentra. HDFS expone el espacio de nombres del sistema de archivos y los usuarios pueden almacenar datos en forma de archivos. Internamente, un archivo en realidad se divide en uno o más bloques de datos, y estos bloques se almacenan en un conjunto de Datanodes.
• Namenode realiza operaciones de espacio de nombres del sistema de archivos, como abrir, cerrar y cambiar el nombre de archivos o directorios. También es responsable de determinar la asignación de bloques de datos a nodos Datanode específicos.
• Los nodos de datos son responsables de manejar las solicitudes de lectura y escritura de los clientes del sistema de archivos. Cree, elimine y copie bloques de datos bajo la programación unificada de Namenode.

A diferencia de Hadoop, el clúster de Elasticsearch asigna particiones de datos eligiendo un servidor, que se denomina nodo maestro. Su arquitectura de administración de particiones de datos es la siguiente: Las responsabilidades

del nodo maestro son las siguientes:

El nodo maestro es responsable de acciones ligeras en todo el clúster, como crear o eliminar un índice, rastrear qué nodos forman parte del clúster y decidir qué fragmentos asignar a qué nodos. Es importante para la salud del clúster tener un nodo maestro estable.
elasticsearch官方文档——modules-node

En la arquitectura de clúster de datos centralizados, el cliente solo puede escribir datos en el host; en la arquitectura de clúster de datos dispersos, el cliente puede leer y escribir datos en cualquier servidor. Es precisamente por esta diferencia clave que los escenarios de aplicación de los dos clústeres son diferentes. En términos generales, los clústeres de datos centralizados son adecuados para escenarios en los que la cantidad de datos es pequeña y la cantidad de máquinas del clúster es pequeña. Por ejemplo, un clúster de ZooKeeper generalmente recomienda alrededor de 5 máquinas, y la cantidad de datos puede ser compatible con un solo servidor; y un clúster de datos distribuidos, debido a su buena escalabilidad, es adecuado para escenarios comerciales con una gran cantidad de datos comerciales y una gran cantidad de máquinas de clúster. Por ejemplo, los clústeres de Hadoop, los clústeres de HBase y los clústeres a gran escala pueden llegar a cientos o incluso a miles de servidores.

partición de datos

Las arquitecturas de almacenamiento de alta disponibilidad que discutimos anteriormente se consideran y diseñan en función de escenarios de falla de hardware. La consideración principal es cómo debe manejar el sistema cuando algún hardware puede dañarse. Sin embargo, para algunos desastres o accidentes con gran impacto, posiblemente todo el hardware falla. Por ejemplo, desastres extremos o accidentes como inundaciones en Nueva Orleans, apagones en Estados Unidos y Canadá, y el terremoto de Los Ángeles pueden paralizar toda la infraestructura de una ciudad o incluso de un área. la arquitectura diseñada en base a fallas de hardware ya no es aplicable. , necesitamos diseñar una arquitectura de alta disponibilidad basada en fallas a nivel geográfico, que es el trasfondo de la arquitectura de partición de datos.

Las diferentes particiones están distribuidas en diferentes ubicaciones geográficas, y cada partición almacena una parte de los datos, de esta manera, se puede evitar el gran impacto que causan las fallas a nivel geográfico.

la cantidad de datos

El tamaño del volumen de datos determina directamente la complejidad de las reglas de partición. Por ejemplo, si se usa MySQL para almacenar datos, asumiendo que la capacidad de almacenamiento de MySQL es de 500 GB, entonces 2 TB de datos requieren al menos 4 servidores MySQL; y si los datos son 200 TB, no es tan simple como aumentar a 800 servidores MySQL. Si se gestionan 800 servidores en paralelo de la misma manera que 4 servidores, la complejidad cambiará sustancialmente, de la siguiente manera:

Entre los servidores 800, puede haber una o dos fallas de servidor cada semana.Localizar dos fallas de servidor de los servidores 800 no es una tarea fácil en muchos casos, y la complejidad de operación y mantenimiento es alta.

Es necesario modificar la adición de nuevos servidores, las configuraciones relacionadas con las particiones e incluso las reglas, y cada modificación teóricamente puede afectar el funcionamiento de los servidores 800 existentes, y en la práctica es demasiado común cambiar accidentalmente la configuración incorrecta.

Si una cantidad tan grande de datos se concentra geográficamente en una determinada ciudad, el riesgo es muy alto. En caso de fallas catastróficas, como inundaciones y apagones, todos los datos pueden perderse. Por lo tanto, las reglas de partición deben considerar la recuperación geográfica ante desastres. .

Reglas de zonificación

Las particiones intercontinentales se utilizan principalmente para brindar servicios a diferentes continentes. Dado que el retraso de la red de comunicación intercontinental es demasiado grande para brindar servicios en línea, es posible que los centros de datos intercontinentales no se comuniquen entre sí o solo sirvan como copias de seguridad; las particiones de países se utilizan principalmente para diferentes países Los diferentes países tienen diferentes idiomas, leyes, servicios, etc., y las particiones entre países generalmente solo se usan como respaldo, debido a que las particiones de la ciudad están todas en el mismo país o región, el retraso de la red es bajo y el negocio es similar. , y las particiones se proporcionan al mismo tiempo.Servicios, que pueden satisfacer las necesidades de los negocios en diferentes lugares y vivir más.

regla de copia

Los datos están dispersos en varias regiones y la arquitectura de partición también debe tener en cuenta el esquema de replicación.

Hay tres tipos de reglas de replicación: centralizadas, en espera mutua e independientes.

1. centralizado

Copia de seguridad centralizada significa que hay un centro de copia de seguridad general, y todas las particiones copian los datos en el centro de copia de seguridad. Su estructura básica es la siguiente: las ventajas y desventajas son

:

El diseño es simple y no hay conexión directa entre las particiones, por lo que no se afectan entre sí.

Es fácil de expandir.Si desea agregar una cuarta partición (por ejemplo, la partición de Wuhan), solo necesita copiar los datos de la partición de Wuhan en el centro de respaldo de Xi'an, y otras particiones no se verán afectadas.

El costo es alto y es necesario construir un centro de respaldo independiente.

2. Espera mutua

La copia de seguridad mutua significa que cada partición realiza una copia de seguridad de los datos de otra partición. Su estructura básica es la siguiente,

las ventajas y desventajas son:

El diseño es relativamente complicado Además de realizar el almacenamiento de datos comerciales, cada partición también debe realizar funciones de respaldo, y están relacionadas y se ven afectadas entre sí.

La expansión es problemática Si agrega una partición de Wuhan, debe modificar la replicación de la partición de Guangzhou para que apunte a la partición de Wuhan y luego apunte la replicación de la partición de Wuhan a la partición de Beijing. Sin embargo, también es un problema cómo manejar los datos de la partición de Guangzhou que se ha respaldado en la partición original de Beijing, ya sea que se trate de una migración de datos o de que los datos históricos de la partición de Guangzhou se mantengan en la partición de Beijing, y el los nuevos datos se respaldan en la partición de Wuhan, de cualquier manera es muy problemático.

Bajo costo, uso directo del equipo existente.

3. Separado

Copia de seguridad independiente significa que cada partición tiene su propio centro de copia de seguridad independiente y su estructura básica es la siguiente:

Las ventajas y desventajas de una arquitectura de respaldo independiente son:

El diseño es simple y cada partición no se afecta entre sí.

Fácil de expandir, las particiones recién agregadas solo necesitan construir su propio centro de respaldo.

El costo es alto, cada partición necesita un centro de respaldo independiente y el costo del sitio del centro de respaldo es el costo principal, por lo que el costo del tipo independiente es mucho mayor que el del tipo centralizado.