Resumen de la tecnología de marcapasos

Openstack&Pacemaker

Estructura interna de Pacemaker

Protocolo Corosync/totem

Características principales de Pacemaker

Estándar de proxy de recursos

Restricciones de recursos

Tipos de recursos avanzados

Monitoreo de excepciones de servicio

Función de IP virtual

Función de equilibrio de carga

p>

Muchos servicios componentes de Openstack pueden integrarse y ejecutarse en un solo nodo o distribuirse en un clúster. Sin embargo, para lograr un clúster de alta disponibilidad que aloje sistemas comerciales, los servicios de Openstack deben implementarse en un clúster de alta disponibilidad y realizar la transferencia automática de fallas y la autorreparación sin lograr ningún punto único de falla para el servicio Openstack. la mayoría de Openstack. Lo que el servicio en sí no tiene. Por lo tanto, al implementar clústeres de alta disponibilidad de OpenStack en un entorno de producción, se debe introducir un software de administración de recursos de clústeres de terceros para que sea responsable del monitoreo, la programación y la administración de alta disponibilidad de los recursos del clúster de Openstack.

Pacemaker es el administrador de recursos de clúster de código abierto más utilizado en el entorno Linux. Utiliza las funciones de mensajería y administración de miembros del clúster proporcionadas por la infraestructura del clúster (como Corosync) para implementar la detección de fallas a nivel de nodos y recursos. gestión de recursos y recuperación, asegurando así en la mayor medida la alta disponibilidad de los servicios del cluster. En términos de funciones lógicas, pacemaker es responsable de la gestión del ciclo de vida completo de los servicios de software en el clúster, impulsado por reglas de recursos definidas por el administrador del clúster. Pacemaker puede gestionar clústeres de casi cualquier tamaño en aplicaciones prácticas. Debido a su potente modelo de dependencia de recursos, los administradores de clústeres pueden describir y expresar con precisión las relaciones entre los recursos del clúster (incluido el orden y la ubicación de los recursos). Al mismo tiempo, Pacemaker puede administrar casi cualquier forma de recursos de software como objetos de recursos personalizando los scripts de inicio y administración de recursos (agentes de recursos). Además, cabe señalar que Pacemaker es solo un administrador de recursos y no proporciona información de latidos del grupo. El mecanismo de latidos del corazón de Pacemaker se implementa principalmente en base a Corosync (o Heartbeat).

En un clúster compuesto por varios nodos, el tótem permite que un nodo envíe mensajes y todos los demás nodos pueden recibirlos y enviarlos a la aplicación superior de manera ordenada.

Los nodos tótem tienen cuatro estados, que son también las cuatro etapas de formación de los clústeres.

Fase de recopilación:

?Esta fase se utiliza para que cada nodo transmita su existencia al mundo exterior y recopile la existencia de otros nodos

Fase de confirmación:

?Esta fase generará un nodo representativo, que recopila información de todos los demás nodos y pasa la información recopilada a todos los demás nodos para las fases posteriores.

Fase de recuperación:

?Esta etapa se utiliza cuando los grupos antiguos y nuevos se alternan. Los miembros del grupo antiguo utilizan el nuevo grupo para transmitir los mensajes del grupo antiguo, de modo que los miembros del grupo antiguo llegan a todos los mensajes de los nodos y los envían a la capa superior de forma ordenada. manera

Etapa operativa:

?Esta etapa es el estado en el que el clúster ha completado su trabajo normal. En este estado, se enviarán todos los mensajes enviados por un nodo y otros nodos. la capa superior de manera ordenada.

El protocolo es así en su estado de funcionamiento. El token circula en cada nodo y el nodo solo puede enviar mensajes después de recibir el token. obtener el token:

(1) Cancelar el temporizador de retransmisión del token

(2) Verificar si el token rtr tiene registros de mensajes. Si el nodo tiene esos mensajes, transmítalos y elimínelos. estos mensajes de rtr

(3) Compare la secuencia de my_aru y el token para ver si hay El mensaje no ha sido recibido por este nodo. Si es así, configure aru, rtr y aru_id en el token<. /p>

(4) Si new_message_queue tiene un mensaje, transmita el mensaje y modifique la secuencia en el token

(5) Si el valor de aru en el token dos veces es mayor que un cierto valor m, envíe el mensaje con el número de secuencia mayor que m hacia arriba

(6) Envíe el token al siguiente nodo

(7) Inicie el temporizador de retransmisión del token y cancélelo cuando finalice Se vuelve a recibir el token o el mensaje normal

El token tiene un mecanismo de retransmisión para evitar la pérdida de mensajes y descubrir problemas de red para reorganizar el clúster, local. Los aru y seq en las variables my_aru y token se utilizan para confirmar que todos Los nodos han recibido el mensaje y aru_id y rtr se utilizan para retransmitir el mensaje a un determinado nodo.

Referencia: /red_hat_enterprise_linux/7/html-single/high_availability_add-on_reference/index#s1-configfileoverview-HAAR