Konfigurieren von Keepalived-Konsistenzprüfungen für TarMK-Cold-Standby in AEM
In diesem Artikel wird erläutert, wie Keepalived in einer TarMK-Cold-Standby-Umgebung von Adobe Experience Manager (AEM) konfiguriert wird, um sicherzustellen, dass nur die primäre Autoreninstanz Benutzerdatenverkehr erhält, sodass der Standby-Knoten keine Anfragen vor der manuellen Hochstufung bearbeiten kann.
Beschreibung description
In AEM-Autorenbereitstellungen mit TarMK-Cold-Standby wird Keepalived oft verwendet, um eine Virtual IP (VIP) zu verwalten, die Traffic an den aktiven Knoten leitet. Standardmäßig verwenden viele -Konfigurationen eine einfache Port-Prüfung (z. B. die Überprüfung, ob der Port 8443 wartet) als Konsistenzprüfung für die VIP-Zuweisung. Dieser Ansatz kann jedoch dazu führen, dass der Standby-Knoten als gesund und zum Empfang von Traffic berechtigt gilt, auch wenn er nicht auf die primäre Instanz hochgestuft wird. Dies kann dazu führen, dass Benutzer- oder API-Traffic an den Standby-Knoten weitergeleitet wird, der erst unterstützt wird, wenn er explizit beworben wird.
Umgebung
- Adobe Experience Manager (AEM) Author mit TarMK-Cold-Standby
- Eine primäre und eine Standby-Autoreninstanz (Cold Standby)
- Verbleibt die Verwaltung einer Virtual IP (VIP) für den Lastausgleich
Symptome
- Es wird beobachtet, wie der API- oder Benutzer-Traffic den Standby-Knoten erreicht, bevor er zum primären Knoten hochgestuft wird
- Es werden keine spezifischen Fehlermeldungen protokolliert, der Traffic wird jedoch unerwartet an den Standby-Knoten weitergeleitet
Ursache
Eine Konsistenzprüfung, die nur auf der Verfügbarkeit des Ports basiert (z. B. Port 8443), unterscheidet nicht zwischen der Primär- und der Standby-Rolle. Dadurch kann der Standby-Knoten VIP nutzen und Traffic empfangen, der in TarMK-Cold-Standby-Topologien nicht unterstützt wird.
Lösung resolution
Gehen Sie wie folgt vor, um das Problem zu beheben:
-
Überprüfen Sie die aktuelle Konfiguration der Konsistenzprüfung für Keepalived . Wenn nur nach Port 8443 gesucht wird (z. B. mit einem Befehl wie
/usr/bin/nc -w 3 -zv localhost 8443), reicht es nicht aus, die Knotenrolle zu bestimmen. -
Ersetzen Sie die Port-Prüfung durch ein benutzerdefiniertes Konsistenzprüfungs-Skript, das überprüft, ob der Knoten als primäre Autoreninstanz ausgeführt wird. Sie können beispielsweise eine Markierungsdatei oder einen anderen zuverlässigen Indikator verwenden, der nur auf dem primären Knoten vorhanden ist.
-
Beispiel für ein benutzerdefiniertes Konsistenzprüfungs-Skript (unter Verwendung einer Markierungsdatei):
bash #!/bin/bash if [ -f /opt/aem/is_primary ] ; then exit 0 else exit 1 fiStellen Sie sicher, dass die Markierungsdatei (zum Beispiel:
/opt/aem/is_primary) nur auf dem primären Knoten vorhanden ist. Entfernen oder erstellen Sie diese Datei im Rahmen Ihrer manuellen Promotion. -
Aktualisieren Sie Ihre Keepalived-Konfiguration, um dieses benutzerdefinierte Skript als Konsistenzprüfung für die Berechtigung für VIP zu verwenden.
-
Stellen Sie während des normalen Betriebs sicher, dass das Konsistenzprüfungs-Skript nur auf dem primären Knoten Erfolg zurückgibt. Der Standby-Knoten sollte die Konsistenzprüfung erst bestehen, wenn er höher gestuft wird.
-
Für manuelle Promotion:
- Wenn ein Failover erforderlich ist, halten Sie AEM auf dem aktuellen Primärknoten an.
- Leiten Sie den Standby-Knoten auf den primären Knoten hoch, indem Sie seine Konfiguration aktualisieren und die Markierungsdatei erstellen (zum Beispiel:
touch /opt/aem/is_primary). - Starten Sie AEM auf dem neuen Primärknoten.
- Das Konsistenzprüfungs-Skript ist jetzt erfolgreich, sodass Keepalived die VIP auf der neuen Primärinstanz bekannt geben kann.
- Erstellen oder konfigurieren Sie den Standby-Knoten neu, wie es für eine kontinuierliche hohe Verfügbarkeit erforderlich ist.
- Vergewissern Sie sich, dass nur der aktive primäre Knoten die VIP anzeigt und Benutzer-Traffic empfängt, indem Sie den Zugriff nach der Promotion über die VIP testen.