Configuration des contrôles d’intégrité Keepalived pour AEM TarMK Cold Standby
Cet article explique comment configurer Keepalived dans un environnement Adobe Experience Manager (AEM) TarMK Cold Standby pour s’assurer que seule l’instance de création principale reçoit le trafic utilisateur, ce qui empêche le nœud de secours de répondre aux requêtes avant la promotion manuelle.
Description description
Dans les déploiements d’instances de création AEM à l’aide de TarMK Cold Standby, l’option Maintenir en vie est souvent utilisée pour gérer une adresse IP virtuelle (VIP) qui dirige le trafic vers le nœud actif. Par défaut, de nombreuses configurations utilisent une simple vérification de port (par exemple, vérifier si le port 8443 écoute) comme contrôle d’intégrité pour l’affectation de VIP. Cependant, cette approche peut entraîner le fait que le nœud de secours soit considéré comme sain et éligible pour recevoir du trafic, même s’il n’est pas promu en nœud principal. Cela peut entraîner le routage du trafic des utilisateurs ou des API vers le nœud secondaire, qui n’est pas pris en charge tant qu’il n’a pas été explicitement promu.
Environnement
- Création de Adobe Experience Manager (AEM) avec TarMK Cold Standby
- Une instance d’auteur principale et une instance de secours (secours différé)
- Gestion continue d’une adresse IP virtuelle (VIP) pour l’équilibrage de charge
Symptômes
- On observe que le trafic d’API ou d’utilisateur atteint le nœud secondaire avant d’être promu en principal
- Aucun message d’erreur spécifique n’est consigné, mais le trafic est acheminé vers le nœud de secours de manière inattendue
Cause
Un contrôle de l’intégrité basé uniquement sur la disponibilité du port (tel que le port 8443) ne fait pas la distinction entre les rôles principal et de secours. Cela permet au nœud secondaire d’être éligible pour le VIP et de recevoir le trafic, ce qui n’est pas pris en charge dans les topologies TarMK Cold Standby.
Résolution resolution
Suivez les étapes ci-dessous pour résoudre le problème :
-
Passez en revue la configuration actuelle du contrôle d’intégrité Keepalived. S’il vérifie uniquement le port 8443 (par exemple : à l’aide d’une commande comme
/usr/bin/nc -w 3 -zv localhost 8443), il ne suffit pas de déterminer le rôle du nœud. -
Remplacez le contrôle de port par un script de contrôle d’intégrité personnalisé qui vérifie si le nœud est en cours d’exécution en tant qu’instance d’auteur principale. Par exemple, vous pouvez utiliser un fichier de marquage ou un autre indicateur fiable présent uniquement sur le nœud principal.
-
Exemple de script personnalisé de contrôle de l’intégrité (à l’aide d’un fichier de marquage) :
bash #!/bin/bash if [ -f /opt/aem/is_primary ] ; then exit 0 else exit 1 fiAssurez-vous que le fichier de marquage (par exemple :
/opt/aem/is_primary) existe uniquement sur le nœud principal. Supprimez ou créez ce fichier dans le cadre de votre processus de promotion manuel. -
Mettez à jour votre configuration Keepalived pour utiliser ce script personnalisé comme contrôle d’intégrité pour l’éligibilité VIP.
-
Lors d’un fonctionnement normal, assurez-vous que le script de contrôle de l’intégrité renvoie un succès uniquement sur le nœud principal. Le nœud secondaire ne doit pas réussir le contrôle d’intégrité tant qu’il n’a pas été promu.
-
Pour la promotion manuelle :
- Lorsque le basculement est nécessaire, arrêtez AEM sur le nœud principal actuel.
- Convertissez le nœud secondaire en nœud principal en mettant à jour sa configuration et en créant le fichier de marquage (par exemple :
touch /opt/aem/is_primary). - Démarrez AEM sur le nouveau nœud principal.
- Le script de contrôle de l’intégrité réussit désormais, ce qui permet à Keepalived d’annoncer le VIP sur la nouvelle instance principale.
- Recréez ou reconfigurez le nœud de secours selon les besoins pour maintenir une haute disponibilité.
- Vérifiez que seul le nœud principal publie le VIP et reçoit le trafic utilisateur en testant l’accès via le VIP après la promotion.