Capítulo 27. Configuración de clusters multisitio con Pacemaker
Cuando un clúster abarca más de un sitio, los problemas de conectividad de red entre los sitios pueden llevar a situaciones de cerebro dividido. Cuando la conectividad se cae, no hay manera de que un nodo en un sitio determine si un nodo en otro sitio ha fallado o sigue funcionando con un interlink de sitio fallado. Además, puede ser problemático proporcionar servicios de alta disponibilidad en dos sitios que están demasiado alejados para mantener la sincronización.
Para solucionar estos problemas, Pacemaker ofrece una compatibilidad total con la capacidad de configurar clústeres de alta disponibilidad que abarcan varios sitios mediante el uso de un gestor de tickets de clústeres de Booth.
27.1. Visión general del gestor de tickets del clúster Booth
El Booth ticket manager es un servicio distribuido que está pensado para ejecutarse en una red física diferente a las redes que conectan los nodos del clúster en sitios concretos. Produce otro clúster suelto, un Booth formation, que se sitúa encima de los clústeres regulares de los sitios. Esta capa de comunicación agregada facilita los procesos de decisión basados en el consenso para las entradas individuales de Booth.
Una cabina ticket es un singleton en la formación de la cabina y representa una unidad de autorización temporal y móvil. Los recursos pueden configurarse para que requieran un determinado ticket para ejecutarse. Esto puede garantizar que los recursos se ejecuten sólo en un sitio a la vez, para el que se ha concedido un ticket o tickets.
Se puede pensar en una formación Booth como un clúster superpuesto que consiste en clústeres que se ejecutan en diferentes sitios, donde todos los clústeres originales son independientes entre sí. Es el servicio Booth el que comunica a los clusters si se les ha concedido un ticket, y es Pacemaker el que determina si se ejecutan recursos en un cluster basándose en una restricción de ticket de Pacemaker. Esto significa que cuando se utiliza el gestor de tickets, cada uno de los clusters puede ejecutar sus propios recursos, así como los recursos compartidos. Por ejemplo, puede haber recursos A, B y C que se ejecuten sólo en un clúster, recursos D, E y F que se ejecuten sólo en el otro clúster, y recursos G y H que se ejecuten en cualquiera de los dos clústeres según lo determine un ticket. También es posible tener un recurso adicional J que podría ejecutarse en cualquiera de los dos clústeres según lo determinado por un ticket separado.