Qué es Split Brain
¿Qué es Split-Brain y como evitarlo?
Se conoce que Split Brain, puede ser considerado un error, o una falla de seguridad, actualmente el Split Brain no se usa a menudo en las organizaciones, sin embargo, es importante conocer un poco acerca de este fenómeno, en un entorno de clúster, normalmente la aplicación se ejecuta en el nodo primario del clúster. Si una aplicación falla en el nodo primario, el software del clúster mueve las operaciones de la aplicación a un nodo secundario o remoto que asume la función primario. Solo hay un nodo maestro en un momento dado.
El split-brain es lo que sucede cuando los miembros del clúster no pueden comunicarse entre sí, pero operan y toman el control de los recursos compartidos al mismo tiempo. De hecho, tienes a dos conductores de autobús peleando por el volante. Debido a su naturaleza destructiva, el split-brain puede causar la pérdida o corrupción de datos y es mejor evitarlo mediante el uso de una función de vallado, quórum, o quórum de clúster. En la mayoría de los administradores de clústeres, se mantiene el quórum si:
Todos los servidores pueden ver el mismo estado para todos los pares y s en el clúster Todos los servidores pueden ver el mismo estado para todos los pares en el clúster, pero el servidor no puede. Todos los servidores pueden ver los recursos , pero no entre sí, lo que evita situaciones de split-brain. Para la mayoría de los administradores de clústeres, el quórum se pierde si:
El servidor no puede ver todos los pares y s en el clúster Los servidores no pueden ver la mayoría de los pares en el clúster, aunque pueden ver el servidor El servidor no pudo acceder o mantener el acceso al recurso de quórum para determinar correctamente la membresía del quórum y el acceso a los recursos
En un entorno de clúster de alta disponibilidad, hay un nodo activo y uno o más nodos en espera, y si el nodo activo falla o deja de responder, el nodo en espera asume el control.
Esto suena como una suposición razonable hasta que considera las capas de red entre los nodos. ¿Qué sucede si falla la ruta de red entre los nodos?
Ninguno de los nodos puede ahora comunicarse con el otro, en cuyo caso el servidor en espera puede anunciarse como el servidor activo sobre la base de que cree que el nodo activo ha fallado. Esto hace que ambos nodos estén "vivos", ya que cada nodo considerará al otro como muerto. Como resultado, la integridad y la consistencia de los datos se ven comprometidas cuando los datos cambian en ambos nodos. Esto se llama "split-brain".
Los nodos de quórum deben instalarse en el clúster para evitar una situación de split-brain. Agregar un nodo de quórum (para un clúster con un número par de nodos)
Crea un número impar de nodos (3, 5, 7, etc.) y los nodos votan qué nodo debe actuar como el nodo activo del clúster.
En el siguiente ejemplo, el bastidor del servidor que aloja el nodo B ha perdido la conectividad LAN. En este caso, cuando agrega un tercer nodo al entorno del clúster, el sistema aún puede determinar qué nodo debe ser el nodo activo.
En una instalación de quórum, se elige un quórum en todos los nodos (no solo en el nodo de quórum) y se definen rutas de comunicación entre todos los nodos, incluido el nodo de quórum. Los nodos de quórum no alojan ningún servicio activo. Su única función es participar en la comunicación de los nodos para determinar qué nodos están activos y proporcionar "votación de interrupción" en caso de una interrupción de la comunicación. SIOS también es compatible con almacenamiento y cercado de ES como dispositivos de quórum, y estas configuraciones no requieren un nodo de quórum adicional.
¿Qué es un recurso (o servidor)? Los s son servidores, terminales de red o dispositivos que se utilizan para lograr y mantener el quórum cuando el clúster tiene un número par de miembros. Un clúster con un número impar de miembros utilizado por el clúster mayoritario no necesita usar el recurso como todos los miembros del servidor del clúster para determinar la membresía mayoritaria. ¿Qué es el quórum y los recursos del quórum? Los recursos de quórum pueden ser cualquiera de estos recursos (dispositivos, sistemas, almacenamiento en bloque, almacenamiento de archivos, recursos compartidos de archivos, etc.) que se utilizan como medio para determinar la membresía y el estado del clúster. Para algunos administradores de clústeres, un quórum es un recurso en un clúster que ayuda o es necesario para tomar decisiones sobre el estado del clúster y la membresía del clúster. En otros líderes de grupos, el quórum actúa como un dispositivo de resolución para evitar un split-brain. Hay más de una manera de llegar a un quórum, dada la naturaleza crítica del quórum, las arquitecturas HA deben implementar correctamente los recursos de quórum, afortunadamente (o desafortunadamente) no existe una mejor manera de implementar el quórum. Varios factores pueden influir en el comportamiento de los s y los recursos del quórum. Estos factores incluyen:
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
