Desde que usamos CentOS 7, cambiamos de una configuración de latido normal a pacemker.
Principalmente tenemos recursos IP que están activos en un nodo y cambian a un segundo nodo si ocurre una conmutación por error. También ejecutamos algunos scripts en caso de conmutación por error. Nada especial.
Para que los recursos comiencen siempre en el nodo principal, utilizo
pcs constraint location Cluster_IP prefers server1=master-server
yo también uso
pcs resource defaults resource-stickiness=INFINITY
para evitar que los recursos regresen después de la conmutación por error.
Esto funciona bien para mí, si el maestro falla (fallo de hardware, por ejemplo).
Dado que no es un problema para mí si la conmutación por error lleva algún tiempo, me gustaría implementar algún tipo de retraso en caso de una breve división del cerebro.
Antes de hacer cualquier cosa, el esclavo debe esperar ~2 minutos, antes de tomar el control, en caso de que se pueda acceder al maestro nuevamente en estos ~2 minutos.
Me preguntaba, ¿cuál sería la mejor manera de hacerlo?
Respuesta1
Nunca he configurado un tiempo de espera de token en Corosync a más de 10 segundos, pero puedes intentar aumentar/establecer el tokenvalor en corosync.conf( 120000120 segundos en milisegundos). tokendebe estar definido en la totem{}sección de su corosync.conf; man corosync.confpara más detalles.
Eso debería evitar que Corosync declare un nodo muerto durante 120 segundos cuando la red falla.
Respuesta2
Puede cambiar el intervalo de monitoreo del recurso op monitor interval=Nsdonde Nestá el número de segundos y luego configurar el migration-thresholdrecurso en 2. Tenga en cuenta que con una configuración 120spodría ver un retraso total de 120 a 240 s dependiendo de cuándo ocurre la falla inicial en el intervalo de monitoreo.
Hay otras advertencias al respecto, ya que el contador de fallas aplicado migration-thresholdno se reinicia en caso de éxito. Para hacer eso, también necesitarás configurar failure-timeouto intervenir manualmente.
Con op monitor interval=120s, y su configuración, deberá realizar pruebas para asegurarse de que proporcione la funcionalidad que espera y cómo se comportan los contadores de fallas cuando se recupera el maestro original migration-threshold=2. Podría requerir intervención manual pero no estoy 100% seguro de eso.failure-timeout=121sresource-stickiness