Alternativas en una situación de split-brain en vPostgres para vRealize Automation 6.x

Hace unos meses me encontré con un problema cuya solución se veía elusiva y que rápidamente escaló para convertirse en un aspecto bloqueante para el avance de un proyecto de amplio alcance en el que estaba trabajando. Después de intercambios y esperas con VMware GSS tuve que llegar a ese momento de poner en marcha una alternativa de solución que no parecía lo más predecible, pero que era una de las últimas opciones disponibles.

El escenario

Un clúster de vRealize Automation Appliance 6.x actuando como instancias de vFabric vPostgres externas para otro clúster de instancias de vRealize Automation (actuando ahora si como vRealize Automation). Algo así:

vpostgres01

Este es un esquema soportado que se implementa con el fin de proveerle alta disponibilidad a la base de datos de vRA 6.x que aloja información muy importante, como por ejemplo el inventario de tenants.

En ésta ocasión, encontramos que el personal a cargo de las pruebas de failover/failback había fallado en en seguir estrictamente el procedimiento de la base de conocimientos KB # 2108923 de VMware y al llevar a cabo las pruebas del clúster Activo/Pasivo de vPostgres llegamos a nuestra situación.

El problema

Siempre que se configura la réplica nativa de vPostgres (mejor conocida como WAL Archiving) aunque el destino (Replica) se especifique por dirección IP, vPostgres buscará el PTR para resolverla por FQDN. Hasta ahí, no hay problemas; después de todo hay que usar FQDNs siempre que sea posible en éstos tiempos.

Sin embargo, en nuestro caso lo que se hizo en vez de crear una entrada DNS tipo alias (algo así como vpostgres.domain.local) y hacerla apuntar al nodo maestro actual, se llevó a cabo el failover y se modificó la entrada DNS del nodo 01 para que apuntara a la IP del nodo 02. Es decir, dos entradas DNS apuntando a la misma IP.

Esto funcionaba pues el nodo 01 estaba apagado. Sin embargo al encenderlo y tratar de configurar la réplica en el sentido contrario (Nodo 02 a Nodo 01) lo que se obtenía eran los siguientes mensajes:

waiting for server to shut down…. done

server stopped

WARNING: The base backup operation will replace the current contents of the data directory. Please confirm by typing yes: yes

602439/602439 kB (100%), 1/1 tablespace

NOTICE: pg_stop_backup cleanup done, waiting for required WAL segments to be archived

WARNING: pg_stop_backup still waiting for all required WAL segments to be archived (60 seconds elapsed)

Y allí permanecía indefinidamente sin completar la reprotección de la base de datos.

El atajo (solución)

Uno de los síntomas que empecé a notar, es que el repositorio de los Write-Ahead Logs (algo como los Transact Logs de SQL Server) no contenía archivos nuevos: todos correspondían al momento en que empezó a fallar:

image

Cuando daba el comando ps –ef | grep wal lo que se observaba es que, precisamente, permanecía tratando de replicar el archivo 00000002.history

Por lo tanto, pensé que tomando las precauciones necesarias, podría intentar dejar que vPostgres re-generara éste archivo que después de todo, solo parecía ser un histórico de la replicación de los logs:

image

Fue así como, después de tomar snapshot de los dos nodos así como de los vRA Appliance que hacen uso de ésta base de datos, procedí a renombrar el archivo e iniciar el servicio de vPostgres (porque además el servicio no iniciaba correctamente):

image

Después de ello, no sólo se generaron nuevos archivos WAL sino que la replicación se pudo completar satisfactoriamente.

Conclusión

El clúster de vPostgres para vRA 6.x es de tipo Activo/Pasivo y soporta dos métodos para ser consumido: a través de un Load Balancer (asegurándose de tener sólamente un nodo activo en el pool) o con un DNS alias que apunte al nodo maestro actual. Fallar en la configuración del método que se elija, puede llevar a una situación como la aquí descrita en un evento de failover/failback.

Saludos!

Advertisements