Cerebro dividido es un término informático, basado en una analogía con el síndrome médico del cerebro dividido . Indica inconsistencias de datos o disponibilidad que se originan por el mantenimiento de dos conjuntos de datos separados con alcance superpuesto, ya sea debido a servidores en un diseño de red o una condición de falla basada en servidores que no se comunican y sincronizan sus datos entre sí. Este último caso también se conoce comúnmente como partición de red .
Aunque el término cerebro dividido generalmente se refiere a un estado de error, el DNS de cerebro dividido (o DNS de horizonte dividido ) a veces se usa para describir una situación deliberada en la que los servicios DNS internos y externos para una red corporativa no se comunican, de modo que el DNS separado los espacios de nombres se administrarán para computadoras externas e internas. Esto requiere una doble administración, y si hay una superposición de dominio en los nombres de las computadoras, existe el riesgo de que el mismo nombre de dominio completo (FQDN) pueda aparecer de manera ambigua en ambos espacios de nombres haciendo referencia a diferentes direcciones IP de las computadoras. [1]
Los clústeres de alta disponibilidad suelen utilizar una conexión de red privada de latido que se utiliza para supervisar la salud y el estado de cada nodo del clúster. Por ejemplo, el síndrome del cerebro dividido puede ocurrir cuando todos los enlaces privados caen simultáneamente, pero los nodos del clúster aún se están ejecutando, y cada uno cree que son los únicos que se ejecutan. Los conjuntos de datos de cada grupo pueden entonces servir a los clientes de forma aleatoria mediante sus propias actualizaciones de conjuntos de datos "idiosincrásicos", sin ninguna coordinación con los otros conjuntos de datos. Esto puede provocar daños en los datos u otras inconsistencias de datos que podrían requerir la intervención y limpieza del operador.
Enfoques para lidiar con el cerebro dividido
Davidson et al., [2] después de examinar varios enfoques para manejar el problema, los clasifica como optimistas o pesimistas.
Los enfoques optimistas simplemente permiten que los nodos particionados funcionen como de costumbre; esto proporciona un mayor nivel de disponibilidad, a costa de sacrificar la corrección. Una vez que el problema ha terminado, es posible que se requiera una conciliación automática o manual para tener el clúster en un estado consistente. Una implementación actual de este enfoque es Hazelcast , que realiza una conciliación automática de su almacén de valor clave. [3]
Los enfoques pesimistas sacrifican la disponibilidad a cambio de coherencia. Una vez que se ha detectado una partición de red, el acceso a las subparticiones está limitado para garantizar la coherencia. Un enfoque típico, como lo describen Coulouris et al., [4] es utilizar un enfoque de consenso de quórum . Esto permite que la sub-partición con la mayoría de los votos permanezca disponible, mientras que las sub-particiones restantes deberían caer en un modo de auto- cercado . Una implementación actual de este enfoque es la que utilizan los conjuntos de réplicas de MongoDB . [5] Y otra implementación similar es la replicación de Galera para MariaDB y MySQL . [6]
Los clústeres de alta disponibilidad comerciales modernos de uso general suelen utilizar una combinación de conexiones de red de latido entre hosts de clúster y almacenamiento testigo de quórum . El desafío con los clústeres de dos nodos es que agregar un dispositivo testigo agrega costo y complejidad (incluso si se implementa en la nube), pero sin él, si falla el latido, los miembros del clúster no pueden determinar cuál debería estar activo. En tales clústeres (sin quórum), si un miembro falla, incluso si los miembros normalmente asignan estados primarios y secundarios a los hosts, existe al menos un 50% de probabilidad de que un clúster HA de 2 nodos falle por completo hasta que se proporcione la intervención humana. , para evitar que varios miembros se activen de forma independiente y que entren directamente en conflicto o corrompan los datos.
Referencias
- ^ Windows Server 2008 Active Directory, configuración (2da edición), Holme, Ruest, Ruest, Kellington, ISBN 978-0-7356-5193-7
- ^ Davidson, Susan; García-Molina, Héctor; Skeen, Dale (1985). "Coherencia en una red particionada: una encuesta". Encuestas de computación ACM . 17 (3): 341–370. doi : 10.1145 / 5505.5508 . hdl : 1813/6456 .
- ^ "Documentación Hazelcast" . Consultado el 16 de febrero de 2015 .
- ^ Coulouris, George; Dollimore, Jean; Kindberg, Tim (2001). Sistemas distribuidos: conceptos y diseño (3. ed., 1ª, 2ª y 3ª impresión. Ed.). Harlow [ua]: Addison-Wesley. ISBN 0201-61918-0.
- ^ "Fundamentos de la replicación de MongoDB" . Consultado el 12 de diciembre de 2012 .
- ^ "Quórum ponderado en Cluster Galera" . Consultado el 17 de diciembre de 2015 .