Überblick

Architektur und Konfiguration für Aktiv/Passiv- und Aktiv/Aktiv-Bereitstellungen an mehreren Sites in der Automation Suite auf EKS/AKS.

Diagramme

Das folgende Diagramm zeigt eine reguläre Aktiv-/Passiv-Bereitstellung der Automation Suite:

Anforderungen

Die folgenden Hardware- und Infrastrukturkomponenten sind für eine Bereitstellung an mehreren Sites erforderlich.

Global Traffic Manager (GTM)

Der GTM verteilt den Datenverkehr über Ihre Automation Suite-Bereitstellung mit mehreren Sites. Sie muss hochverfügbar und immun gegen Fehler an einer einzelnen Bereitstellungssite sein. Der GTM muss auch Zustandsprüfungen unterstützen, die eine fehlerhafte Site schnell isolieren. Der GTM ist nicht obligatorisch, wird aber für einen schnellen Wechsel empfohlen.

Verwenden Sie beim Konfigurieren des GTM für Aktiv-/Passiv-Bereitstellungen /orchestrator_/api/status als Integritätsendpunkt. Dies ist für ein effektives Disaster Recovery-Management von entscheidender Bedeutung.

Load balancer

Jede Site benötigt einen lokalen Lastausgleich, der Datenverkehr auf jedem Knoten ausgleichen kann, der in derselben Site konfiguriert ist.

Knoten

Beide Sites müssen eine identische Anzahl von Knoten haben. Für jede Site müssen Sie den Cluster und die Knoten mithilfe der Dokumentation in Kubernetes-Cluster und -Knoten konfigurieren. Weitere Informationen finden Sie unter Installationsgrößenrechner für Automation Suite.

SQL-Datenbank

Zum Speichern der Daten ist ein externer SQL-Server erforderlich. Für die Disaster Recovery benötigen Sie Always On-Verfügbarkeitsgruppen (oder MSSQL von Amazon RDS mit ReadReplica) mit einem primären SQL-Server an Site 1 und mindestens einem sekundären SQL-Server (ReadReplica), der sich physisch an Site 2 befindet, mit aktivierter Datensynchronisierung. Ein SQL-Listener wird über dem SQL-Server bereitgestellt und beide Cluster sind so konfiguriert, dass sie die Adresse desselben Listeners verwenden.

Sowohl die aktiven (primären) als auch passiven (sekundären) Sites und Cluster müssen den primären Datenbankendpunkt für die Datenbankkommunikation verwenden. Im Falle einer Katastrophe muss das Lesereplikat nach der Heraufstufen an die primäre Stelle an beiden Sites aktualisiert werden, um als neue Datenbankverbindungszeichenfolge zu dienen.

Um die Failover-Verwaltung zu vereinfachen, können Sie Amazon Route 53 verwenden, um einen DNS-Datensatz für die Datenbank zu erstellen. Zunächst muss er auf den Endpunkt der primären Datenbank (oder den Listener) verweisen. Aktualisieren Sie im Falle eines Failover den Route 53-Datensatz, um auf die neu heraufgestufte primäre Datenbank (früher das Lesenreplikat) zu verweisen.

PostgreSQL-Datenbank

Process Mining, Autopilot for Developers und Temporal as a Service (TaaS) erfordern einen externen PostgreSQL-Server. Für die Disaster Recovery muss nur die Datenbank von Autopilot for Developers auf die sekundäre Site repliziert werden. Die Process Mining/Airflow-Datenbank erfordert keine standortübergreifende Replikation, aber eine PostgreSQL-Instanz ist weiterhin an jedem Standort erforderlich. TaaS wird im sekundären Cluster nicht unterstützt; Sie wird nur am primären Site in einer Aktiv-/Passiv-Bereitstellung unterstützt.

Konfigurieren Sie einen primären PostgreSQL-Server an Site 1 mit physischer Streaming-Replikation zu mindestens einem schreibgeschützten Replikat an Site 2, oder verwenden Sie die Replikationsfunktion des verwalteten Anbieters, z. B. Amazon RDS Read Replikate, Amazon Amazon PostgreSQL Global Database oder Azure Database für PostgreSQL Flexible Server-Geo-Replikate.

PostgreSQL unterstützt jeweils nur eine beschreibbare primäre Datenbank, daher müssen sowohl der aktive als auch der passive Cluster den aktuellen primären Datenbankendpunkt verwenden. Aktualisieren Sie während der Disaster Recovery den Datenbankendpunkt an beiden Sites, sobald das Replikat von Site 2 zum primären heraufgestuft wurde, um auf den neu heraufgestuften primären zu verweisen. Um das Failover zu vereinfachen, verwenden Sie einen DNS-Datensatz für den Datenbankendpunkt und aktualisieren Sie ihn während des Failover.

Objektspeicher

Alle Dateien oder Pakete, die in Produkte hochgeladen wurden, werden im Objektspeicher gespeichert. Für eine höhere Ausfallsicherheit benötigen Automation Suite-Bereitstellungen einen externen Objektspeicher.

Für eine effektive Disaster Recovery sind zwei Objektspeicherinstanzen erforderlich, eine in jedem Rechenzentrum. Es darf immer nur eine Objektspeicherinstanz von beiden Clustern aktiv zum Lesen und Schreiben verwendet werden, ergänzt durch eine asynchrone Replikation zur sekundären Instanz.

Temporal as a Service (TaaS)

Wenn Maestro aktiviert ist, kann jeweils nur ein Cluster TaaS aktiv ausführen. Skalieren Sie auf dem passiven Cluster alle TaaS-Bereitstellungen auf null Replikate. Wenn beide Cluster gleichzeitig eine Verbindung mit demselben PostgreSQL-Persistenzspeicher herstellen, kommt es zu Sperrkonflikten, die die Leistung beeinträchtigen. Weitere Informationen dazu finden Sie unter Fehlerbehebung bei Temporal as a Service.

Lastausgleich und DNS-Konfiguration

In diesem Abschnitt werden die Infrastruktureinrichtung, die DNS-Architektur und die Routing-Logik für ein System beschrieben, das sowohl für den Betrieb in normalen als auch in Disaster-Recovery-Szenarien entwickelt wurde.

Übersicht über die Infrastruktur

Um die hohe Verfügbarkeit und die Notfallwiederherstellung zu unterstützen, erfordert das System ein Setup mit zwei Lastausgleichen:

• Primärer Lastausgleich: Wird dem aktiven (primären) Cluster zur Abwicklung von Standardanwendungsdatenverkehr zugewiesen.
• Sekundärer Lastausgleich: Dem passiven (sekundären) Cluster zugewiesen und bereit, im Falle eines Fehlers im primären Cluster zu übernehmen.

Jedem Lastausgleich wird eine eindeutige Elastic IP (EIP) zugewiesen, die als Endpunkt für die DNS-Auflösung dient.

DNS-Architektur

Um die Datenverkehrsverwaltung und die Zugänglichkeit zu clusterspezifischen Diensten zu erleichtern, werden zwei Ebenen der DNS-Konfiguration verwendet.

• FQDN: Der Anwendungs-FQDN ist die primäre Domäne, die von Endbenutzern für den Zugriff auf die Anwendungsschnittstelle verwendet wird. Dieser Wert entspricht dem Feld fqdn in input.json. Weitere Informationen finden Sie unter Aktiv-/Passiv-Konfigurationen.
• Clusterspezifische FQDNs: Zusätzlich zum Hauptanwendungs-FQDN benötigt jeder Cluster einen eigenen FQDN für Verwaltungs- und Überwachungstools. Dieser Wert wird unter dem Feld cluster_fqdn im input.json jedes Clusters definiert. Weitere Informationen finden Sie unter Aktiv-/Passiv-Konfigurationen.
• Unterdomänen: Für den umfassenden Dienstzugriff wird eine Reihe von Unterdomänen sowohl für den Anwendungs-FQDN als auch für jeden clusterspezifischen FQDN konfiguriert. Dazu gehören:

  • FQDN:

    • apps.<domain> – wird von Apps verwendet.
    • insights.<domain> – wird von für Insights verwendet.

  • Clusterspezifischer FQDN:

    • alm.<domain> – Wird von ArgoCD und für die Bereitstellungsverwaltung verwendet. Dies ist sowohl für Aktive (primäre) als auch für passive (sekundäre) Cluster erforderlich.
    • monitoring.<domain> – Wird für Beobachtbarkeit und Warnungen verwendet. Dies ist sowohl für Aktive (primäre) als auch für passive (sekundäre) Cluster erforderlich.

    Alle Unterdomänen werden an dieselbe Elastic IP (EIP) wie ihre jeweilige Stammdomäne weitergeleitet, um Konsistenz und Einfachheit des Routings aufrechtzuerhalten.

DNS-Routing-Logik

Die DNS-Routing-Logik stellt sicher, dass der Benutzerdatenverkehr je nach Systemzustand entweder während des normalen Betriebs oder der Disaster Recovery an den entsprechenden Lastausgleich weitergeleitet wird.

• Normale Vorgänge (primärer Cluster ist aktiv) Im Standardbetriebsmodus leitet DNS den Datenverkehr wie in der folgenden Tabelle beschrieben weiter:

  FQDN-Typ	Weiterleitungsziel
  FQDN	Primärer Cluster-Lastausgleich
  Primärer Cluster-FQDN	Primärer Cluster-Lastausgleich
  Sekundärer Cluster-FQDN	Sekundärer Cluster-Lastausgleich

• Notfallwiederherstellung (sekundärer Cluster ist aktiv) Wenn der primäre Cluster ausfällt, wechselt das System in den Notfallwiederherstellungsmodus. In diesem Zustand wird das DNS angepasst, um die Dienstkontinuität zu gewährleisten:

  FQDN-Typ	Weiterleitungsziel
  FQDN	Sekundärer Cluster-Lastausgleich
  Primärer Cluster-FQDN	Primärer Cluster-Lastausgleich*(unändert)*
  Sekundärer Cluster-FQDN	Lastausgleich für sekundären Cluster*(unändert)*