Split-Brain

Split-Brain

Split-Brain es un término informático, basado en una analogía con el síndrome de Split-brain médico. Indica inconsistencias de datos o disponibilidad procedentes del mantenimiento de dos conjuntos de datos separados con superposición en el alcance, ya sea debido a servidores en un diseño de red, o a una condición de falla basada en servidores que no comunican y sincronizan sus datos entre sí.

Aunque el término "cerebro dividido" generalmente se refiere a un estado de error, el DNS de cerebro dividido (o DNS de cerebro dividido) a veces se usa para describir una situación que intencionalmente causa que los servicios DNS internos y externos de la red de una empresa no puedan comunicarse. por lo tanto, se requiere el uso de DNS separados para los espacios de nombres de administración de computadoras internos y externos. Esto requiere una administración dual y, si hay una superposición de dominios en el nombre de la computadora, existe el riesgo de que el mismo nombre de dominio completo (FQDN) pueda aparecer ambiguo en dos espacios de nombres que hacen referencia a diferentes direcciones IP de la computadora. Los clústeres de alta disponibilidad suelen utilizar una conexión de red de latido dedicada para monitorear el estado de cada nodo del clúster.

Cuando ocurre un split brain, cada nodo del sistema continuará operando con su propia copia de los datos. Esto puede provocar inconsistencias de datos, ya que los nodos pueden actualizar los datos de manera diferente. También puede provocar problemas de disponibilidad, ya que los usuarios pueden no poder acceder a los datos o servicios que dependen del sistema.

Para evitar los problemas asociados con el split brain, los sistemas distribuidos suelen utilizar algoritmos de detección de fallos y recuperación. Estos algoritmos detectan cuando se ha producido un split brain y toman medidas para resolverlo. Las medidas comunes para resolver un split brain incluyen:

• Eliminación de un nodo del sistema. Esto puede hacerse desconectando el nodo de la red o forzando un reinicio del nodo.
• Reconexión de los nodos. Esto puede hacerse reparando la falla de red o restableciendo la energía.
• Sincronización de los datos. Esto puede hacerse forzando a los nodos a sincronizar sus copias de los datos.

Ventajas de split brain

• Una ventaja es que puede procesar información de forma paralela. Esto significa que puede realizar múltiples tareas al mismo tiempo. Esto es útil para aplicaciones que requieren un procesamiento intensivo de datos.
• Puede ser más robusta a los fallos. Esto se debe a que cada mitad del cerebro puede realizar tareas por sí sola. Esto puede ser importante para aplicaciones críticas, como los sistemas de seguridad.

Hay varios factores pueden influir en el comportamiento de los s y los recursos del quórum. Estos factores incluyen:

• Ya sea que su implementación sea local, en la nube o híbrida

La implementación en un centro de datos local con dispositivos de almacenamiento adicionales, como almacenamiento de canal de fibra, dispositivos de administración de capacidad o interconexiones, o dispositivos stonith tradicionales brindará a los clientes capacidades adicionales de quórum y que pueden no tener en la nube. Además, los entornos de nube e híbridos difieren en lo que se puede implementar y qué casos de uso se implementan para eliminar el arbitraje. Además, los requisitos de latencia y las diferencias pueden limitar los tipos de dispositivos y recursos disponibles para una configuración de quórum.

• Los objetivos de recuperación

Al diseñar y crear recursos de quórum, también es importante considerar los objetivos de recuperación. En el ejemplo de un clúster de dos nodos (nodo A y nodo B), cuando el nodo A pierde conectividad con el nodo B, ¿cuál es la prioridad de recuperación más alta? Si el recurso quórum está en la misma red que el nodo A, el nodo A puede permanecer en línea pero desconectado de los clientes, mientras que el nodo B no puede evaluar el quórum y asumir el control. De manera similar, si un dispositivo de quórum existe por separado en una región, un centro de datos o una red con el nodo B, su pérdida puede provocar que el recurso se conmute a una red o concentrador fallido o que se aleje del nodo.

• Redundancia de centros de datos disponibles (o regiones) en la infraestructura

La redundancia del centro de datos o de la zona también es un factor importante en una topología HA de quórum. Si su centro de datos solo tiene dos niveles de redundancia, comprenda el equilibrio entre colocar el quórum en el mismo centro de datos que los nodos de clúster primario o en espera. Si el centro de datos tiene más de dos niveles de redundancia, como una tercera zona de disponibilidad o acceso a la segunda zona, esta opción proporcionará al clúster un mayor nivel de redundancia.

• Requisitos para la recuperación ante desastres

Comprender las necesidades reales en caso de desastre también es un factor importante en su diseño. Si su software de administración de clústeres requiere acceso de quórum token para recuperarse de una interrupción completa del centro de datos (o falla de la región), debe tener en cuenta este impacto en su diseño. Muchos paquetes de alta disponibilidad tienen herramientas o técnicas para esto, pero si no las tiene, es posible que su diseño y ubicación de quórum deban adaptarse a esto.

• El número de participantes en el clúster y sus posiciones.

Si el clúster tiene una cantidad impar de nodos, generalmente no se requiere un servidor de quórum adicional. Sin embargo, si usa solo dos nodos en su clúster o implementa un nodo DR que no siempre está disponible, puede cambiar su arquitectura. Como vicepresidente de experiencia del cliente, trabajé con clientes que implementaron una arquitectura de tres nodos, pero periódicamente apagaron automáticamente el tercer servidor para ahorrar costos.

• Sistema Operativo y Administrador de Clústeres

El factor final de quórum es el administrador de clústeres y el sistema operativo. No todo el software HA y los administradores de clústeres son iguales cuando se trata de implementar quórum o quórum de estado de quórum. Algunos software de clúster requieren discos compartidos para proporcionar quórum, otros son más flexibles y permiten compartir recursos (NFS, SMB, EFS, Azure Files y S3). Saber qué necesita su administrador de clústeres y los modos que admite en términos de quórum (mayoría simple, , uso compartido de archivos, etc.) afectará no solo lo que implemente, sino también cómo lo implemente. La mejor manera de implementar un servidor de quórum es comprender la definición de quórum de su proveedor y las opciones disponibles para usted, comprender sus requisitos, comprender las limitaciones o capacidades que ofrece su centro de datos (o entorno de nube) y desarrollar una solución. Es importante proporcionar el nivel más alto de protección para sus sistemas críticos contra interrupciones cerebrales, errores espurios y tiempo de inactividad.