Configuración de las comprobaciones de estado de Keepalived para AEM TarMK Cold Standby
En este artículo se explica cómo configurar Keepalived en un entorno de espera en frío de TarMK de Adobe Experience Manager (AEM) para garantizar que solo la instancia de autor principal reciba el tráfico de usuario, lo que evita que el nodo de espera sirva solicitudes antes de la promoción manual.
Descripción description
En implementaciones de AEM Author que utilizan el modo de espera pasiva TarMK, Keepalived se utiliza a menudo para administrar una IP virtual (VIP) que dirige el tráfico al nodo activo. De forma predeterminada, muchas configuraciones utilizan una simple comprobación de puerto (como verificar si el puerto 8443 está escuchando) como comprobación de estado para la asignación de VIP. Sin embargo, este método puede hacer que el nodo de espera se considere saludable y apto para recibir tráfico, aunque no se haya promocionado a principal. Esto puede hacer que el tráfico de usuario o API se enrute al nodo de espera, que no se admite hasta que se promociona explícitamente.
Entorno
- Adobe Experience Manager (AEM) Author with TarMK Cold Standby
- Una instancia de autor principal y otra en espera (modo de espera pasiva)
- Mantener activada la administración de una IP virtual (VIP) para el equilibrio de carga
Síntomas
- Se observa que el tráfico de API o de usuario llega al nodo de espera antes de promocionarse al principal
- No se registra ningún mensaje de error específico, pero el tráfico se enruta al nodo de espera de forma inesperada
Causa
Una comprobación de estado basada únicamente en la disponibilidad del puerto (como el puerto 8443) no distingue entre las funciones principal y en espera. Esto permite que el nodo de espera sea apto para la VIP y reciba tráfico, lo que no se admite en topologías de espera en frío de TarMK.
Resolución resolution
Siga los pasos a continuación para resolver el problema:
-
Revise la configuración actual de la comprobación de estado de Keepalived. Si solo comprueba el puerto 8443 (por ejemplo: usando un comando como
/usr/bin/nc -w 3 -zv localhost 8443), no es suficiente para determinar la función del nodo. -
Reemplace la comprobación de puerto por una secuencia de comandos de comprobación de estado personalizada que valide si el nodo se está ejecutando como instancia de autor principal. Por ejemplo, puede utilizar un archivo de marcador u otro indicador confiable que esté presente únicamente en el nodo principal.
-
Ejemplo de script de comprobación de estado personalizado (con un archivo de marcador):
bash #!/bin/bash if [ -f /opt/aem/is_primary ] ; then exit 0 else exit 1 fiAsegúrese de que el archivo de marcador (por ejemplo:
/opt/aem/is_primary) solo existe en el nodo principal. Elimina o crea este archivo como parte de tu proceso de promoción manual. -
Actualice la configuración de Keepalived para utilizar este script personalizado como comprobación de estado para la elegibilidad de VIP.
-
Durante la operación normal, asegúrese de que la secuencia de comandos de comprobación de estado devuelve el resultado correcto solo en el nodo principal. El nodo de espera no debe pasar la comprobación de estado hasta que se promocione.
-
Para la promoción manual:
- Cuando se requiera la conmutación por error, detenga AEM en el nodo principal actual.
- Promocione el nodo de espera al nodo principal actualizando su configuración y creando el archivo de marcador (por ejemplo:
touch /opt/aem/is_primary). - Inicie AEM en el nuevo nodo principal.
- La secuencia de comandos de comprobación de estado ahora se ejecutará correctamente, lo que permitirá a Keepalived anunciar VIP en la nueva versión principal.
- Vuelva a crear o a configurar el nodo en espera según sea necesario para mantener la alta disponibilidad.
- Compruebe que solo el nodo principal activo anuncia VIP y recibe tráfico de usuarios probando el acceso a través de VIP después de la promoción.