Prevención de condiciones de "separación de redes"

Un modo de fallo común en los sistemas en clusters es el que se conoce como separación de redes (split-brain), donde cada uno de los nodos principales en clusters cree que su par ha fallado e intenta tomar el control. Sin lógica adicional, esta condición puede causar una amplia gama de comportamientos inesperados y destructivos cuyo diagnóstico o corrección pueden ser difíciles. El disparador canónico de esta condición es el fallo del medio de comunicación compartido entre los nodos principales; en el caso de Oracle ZFS Storage Appliance, esto ocurriría si se produjera un fallo en los enlaces de E/S del cluster. Además de la redundancia incorporada de enlace triple (se necesita sólo un enlace para evitar que se active la toma de control), el software del dispositivo también realiza un procedimiento de arbitraje para determinar cuál es el nodo que debe continuar con la toma de control.

Hay una serie de mecanismos de arbitraje que son utilizados por productos similares; normalmente requieren el uso de discos de quórum (que usan reservas SCSI) o servidores de quórum. Para que sea posible utilizar discos ATA sin necesidad de hardware adicional, Oracle ZFS Storage Appliance utiliza un enfoque diferente que recurre al tejido del almacenamiento en sí para proporcionar la exclusividad mutua requerida. El proceso de arbitraje consiste en intentar ejecutar un comando SAS ZONE LOCK en cada uno de los expansores SAS visibles en el tejido de almacenamiento, en un orden predefinido. El dispositivo que logre obtener correctamente todos los bloqueos tomará el control, mientras que el otro se restablecerá de manera automática. Como un dispositivo en clusters que se inicia y detecta que no se puede comunicar con su par intenta tomar el control y llevar a cabo el mismo proceso de arbitraje, se restablecerá continuamente hasta que se restaure al menos uno de los enlaces de E/S del cluster. Esto garantiza que un fallo subsiguiente del otro nodo no ocasione una interrupción prolongada. Estos bloqueos de la zona SAS se liberan cuando se realiza la operación de failback o aproximadamente 10 segundos desde que el nodo cuyo estado es AKCS_OWNER renueva su propio acceso al tejido de almacenamiento.

Este mecanismo de arbitraje es simple, económico y no requiere hardware adicional, pero requiere que los dos dispositivos en clusters tengan acceso al menos a un expansor SAS común en el tejido de almacenamiento. En condiciones normales, cada dispositivo tiene acceso a todos los expansores, de manera que el arbitraje consistirá en la toma de al menos dos bloqueos de zona SAS. Sin embargo, es posible concebir situaciones de fallos múltiples en las que los dispositivos no tienen acceso a ningún expansor común. Por ejemplo, si se extraen dos de los cables SAS o si se apaga un disco JBOD, cada dispositivo tendrá acceso a subconjuntos separados de expansores. En este caso, cada dispositivo podrá bloquear correctamente todos los expansores a los que tiene acceso, concluirá que el par ha fallado e intentará proceder con la toma de control. Esto puede generar bloqueos irrecuperables debido a conflictos de afiliación de discos y/o daño grave de los datos.

Tenga en cuenta que si bien las consecuencias de esta condición son graves, se puede producir solamente si hay varios fallos (con frecuencia sólo en el caso de 4 fallos o más). La solución de agrupación en clusters incrustada en Oracle ZFS Storage Appliance está diseñada para garantizar que no haya un único punto de fallo y proteger tanto los datos como la disponibilidad contra todo fallo posible sin agregar costos ni complejidad innecesarios en el sistema. Sigue siendo posible que se produzcan varios fallos masivos que ocasionen la pérdida de servicio o datos, de la misma manera en la que ningún diseño RAID puede proteger contra una cantidad ilimitada de fallos de discos.

Figura 10-8  Prevención de separación de redes

Afortunadamente, la mayoría de estas situaciones de fallo se producen a causa de errores humanos y son completamente prevenibles con la instalación correcta del hardware y la capacitación del personal en relación con las mejores prácticas para la configuración y la gestión de clusters. Los administradores deben asegurarse siempre que los tres enlaces de E/S del cluster estén conectados y funcionen (como se muestra en la ilustración) y que todos los cables del almacenamiento estén conectados como se muestra en el diagrama de configuración que se incluye con los dispositivos. Es particularmente importante que se detecten dos rutas a cada JBOD (como se muestra en la ilustración) antes de pasar el cluster a producción y que esas rutas estén disponibles en todo momento de allí en más, con la excepción evidente de cambios transitorios de cables para aumentar la capacidad o reemplazar componentes con fallos. Los administradores deben utilizar alertas para supervisar el estado de los enlaces de interconexión del cluster y las rutas JBOD y corregir con rapidez los fallos que puedan producirse. Garantizando la conectividad adecuada, se protege tanto la disponibilidad como la integridad de los datos si falla algún componente de hardware o software.

Figura 10-9  Dos rutas en un cluster