Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Active/active AWS IoT Greengrass V2 component
In diesem Setup verwalten Sie eine AWS IoT Greengrass V2 Komponente mit Pacemaker mithilfe eines benutzerdefinierten OCF (Open Cluster Framework) -Ressourcenagenten. Auf diese Weise kann Pacemaker den Zustand einer AWS IoT Greengrass V2 Komponente überwachen und Wiederherstellungsaktionen auslösen, wenn die Komponente in einen defekten Zustand übergeht.
Wichtig
Führen Sie alle Schritte unter aus, Voraussetzungen und Cluster-Setup bevor Sie fortfahren, mit Ausnahme der DRBD-Setup-Schritte. Dieses Setup verwendet DRBD nicht. Installieren AWS IoT Greengrass V2 Sie stattdessen auf jeder Instanz in einem lokalen Pfad. AWS IoT Greengrass V2 muss auf allen Instanzen bereitgestellt und ausgeführt werden. In diesem Tutorial AWS IoT Greengrass V2 wird davon ausgegangen, dass es unter /greengrass/v2 installiert ist. Wenn Sie einen anderen Pfad gewählt haben, aktualisieren Sie die GG_CLI Variable im OCF-Skript entsprechend.
Erstellen Sie einen benutzerdefinierten OCF-Agent
Erstellen Sie das benutzerdefinierte Resource Agent-Verzeichnis und das Skript auf allen Instanzen. In diesem Beispiel wird eine Komponente mit dem Namen verwaltetPythonWebServer.
sudo mkdir -p /usr/lib/ocf/resource.d/custom
Erstellen Sie das Resource Agent-Skript unter /usr/lib/ocf/resource.d/custom/gg-webserver mit dem folgenden Inhalt.
#!/bin/bash # OCF Resource Agent for Greengrass Web Server component . /usr/lib/ocf/lib/heartbeat/ocf-shellfuncs GG_CLI="/greengrass/v2/bin/greengrass-cli" COMPONENT="PythonWebServer" STATE_FILE="/run/gg-webserver.ocf-state" case "$1" in meta-data) cat <<EOF <?xml version="1.0"?> <resource-agent name="gg-webserver"> <version>1.0</version> <longdesc lang="en">Greengrass webserver component agent</longdesc> <shortdesc lang="en">GG Webserver</shortdesc> <parameters> </parameters> <actions> <action name="start" timeout="60"/> <action name="stop" timeout="10"/> <action name="monitor" timeout="5" interval="10"/> <action name="meta-data" timeout="5"/> </actions> </resource-agent> EOF ;; start) touch "$STATE_FILE" systemctl restart greengrass if [ $? -eq 0 ]; then exit $OCF_SUCCESS else rm -f "$STATE_FILE" exit $OCF_ERR_GENERIC fi ;; stop) rm -f "$STATE_FILE" exit $OCF_SUCCESS ;; monitor) # Check state file first — if absent, resource is stopped [ ! -f "$STATE_FILE" ] && exit $OCF_NOT_RUNNING # Check if the Greengrass service is running if ! systemctl is-active --quiet greengrass; then exit $OCF_NOT_RUNNING fi STATE=$($GG_CLI component details -n=$COMPONENT 2>/dev/null | grep '^[[:space:]]*State:' | awk '{print $2}') if [[ -z "$STATE" ]]; then ocf_log warn "Component $COMPONENT state is empty — component may not be deployed" exit $OCF_SUCCESS elif [[ "$STATE" == "BROKEN" ]]; then exit $OCF_ERR_GENERIC else exit $OCF_SUCCESS fi ;; *) echo "Usage: $0 {start|stop|monitor|meta-data}" exit $OCF_ERR_UNIMPLEMENTED ;; esac
Machen Sie das Skript ausführbar.
sudo chmod +x /usr/lib/ocf/resource.d/custom/gg-webserver
Anmerkung
Die start Aktion startet den gesamten AWS IoT Greengrass V2 Dienst neu, wodurch nicht nur alle Komponenten auf der Instanz neu gestartet werden. PythonWebServer Dies ist der einzig praktikable Wiederherstellungspfad, da der Neustart einzelner Komponenten AWS IoT Greengrass V2 nicht unterstützt wird. Bei dieser stop Aktion handelt es sich bewusst um ein No-Op, da es sich bei diesem Agenten um einen Monitoring-Wrapper handelt — der AWS IoT Greengrass V2 Service-Lebenszyklus wird von Systemd verwaltet, nicht von diesem Agenten. Bleibt eine Komponente dauerhaft bestehen BROKEN (z. B. aufgrund einer fehlerhaften Bereitstellung), versucht Pacemaker es bis zu migration-threshold mehrmals erneut und sperrt dann die Ressource auf diesem Knoten, bis sie abläuft. failure-timeout Sie müssen die Ursache beheben (z. B. eine gültige Komponentenversion erneut bereitstellen), um den Wiederholungszyklus zu beenden.
Hängen Sie die Ressource an
Erstellen Sie die Pacemaker-Ressource mithilfe des benutzerdefinierten OCF-Agenten.
sudo pcs property set stonith-enabled=false
Warnung
STONITH ist hier deaktiviert, um dieses Tutorial zu vereinfachen. In einer Produktionsumgebung müssen Sie STONITH aktivieren und einen Fencing-Agenten konfigurieren (z. B. fence_aws für Amazon EC2 EC2-Instances), um Split-Brain und Datenbeschädigung zu verhindern.
sudo pcs resource create gg-webserver ocf:custom:gg-webserver \ op monitor interval=30s \ op start timeout=60s \ meta migration-threshold=3 failure-timeout=60s \ clone
Überprüfen Sie die Wiederherstellung
-
Überprüfen Sie den Ausgangszustand. Stellen Sie sicher, dass die AWS IoT Greengrass V2 Komponente auf allen Instanzen läuft und fehlerfrei ist.
sudo pcs status -
Simulieren Sie den Ausfall einer Komponente. Beenden Sie den Prozess der Komponente, um einen vorübergehenden Ausfall zu simulieren. AWS IoT Greengrass V2 könnte zuerst versuchen, eine interne Wiederherstellung durchzuführen. Wenn die Komponente in einen
BROKENZustand übergeht, erkennt Pacemaker dies und löst einen Neustart des Dienstes aus. Wenn die Komponente intern AWS IoT Greengrass V2 wiederhergestellt wird, ergreift Pacemaker keine Maßnahmen.sudo pkill -f "PythonWebServer" # Wait 30-60 seconds, then check the component state sudo /greengrass/v2/bin/greengrass-cli component details -n=PythonWebServer -
Überprüfen Sie die Wiederherstellung. Pacemaker erkennt, dass die Komponente fehlerhaft ist, und führt die im benutzerdefinierten OCF-Skript definierten Wiederherstellungsschritte durch. Es ist kein Failover erforderlich — Pacemaker startet den Dienst auf derselben Instanz neu.
Andere Dienste wie HAProxy funktionieren AWS IoT Greengrass V2 weiterhin normal auf allen Instanzen. Die Anwendung auf den Standby-Instanzen nimmt weiterhin Anfragen ohne Unterbrechung entgegen.
sudo pcs statusWenn die wiederhergestellte Instance wieder verfügbar ist, identifiziert der Load Balancer sie und verteilt die Client-Anfragen nach Bedarf.