Überblick

Diagramme

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

Anforderungen

Hardware	Anforderungen
Global Traffic Manager (GTM)	Verteilt den Datenverkehr an Ihre Automation Suite-Bereitstellung mit mehreren Sites. Der Dienst muss hochverfügbar und immun gegen Bereitstellungssites sein. Darüber hinaus muss der GTM in der Lage sein, die Systemdiagnose zu konfigurieren, um die fehlerhafte Site schnell zu isolieren. Der GTM ist nicht obligatorisch, wird aber für einen schnellen Wechsel empfohlen. Stellen Sie beim Konfigurieren des Global Traffic Manager (GTM) für Aktiv-/Passiv-Bereitstellungen sicher, dass Sie /orchestrator_/api/status als Integritätsendpunkt verwenden. Dies ist entscheidend für ein effektives Disaster Recovery-Management.
Load balancer	Jede Site benötigt einen lokalen Lastausgleich, der den Datenverkehr mit jedem Knoten ausgleichen kann, der auf 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 konfigurieren, die auf der Seite Kubernetes-Cluster und -Knoten bereitgestellt wird. Weitere Informationen finden Sie unter Rechner der Automation Suite zur Installationsskalierung.
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 physischen SQL-Server (ReadReplica) an Site 2 mit aktivierter Datensynchronisierung. Darüber hinaus wird ein SQL-Listener über dem SQL-Server bereitgestellt. Beide Cluster sind so konfiguriert, dass sie die Adresse desselben Listeners verwenden. Sowohl die aktiven (primären) als auch die passiven (sekundären) Sites/Cluster müssen den primären Datenbankendpunkt für die Datenbankkommunikation verwenden. Im Falle einer Katastrophe muss der Endpunkt des gelesenen Replikats, das zum primären Element heraufgestuft wurde, sowohl an den aktiven als auch an den passiven Sites aktualisiert werden, um als neue Datenbankverbindungszeichenfolge zu dienen. Um das Failover-Management zu vereinfachen, kann Amazon Route 53 verwendet werden, um einen DNS-Datensatz für die Datenbank zu erstellen. Zunächst muss sie auf den primären Datenbankendpunkt (oder Listener) verweisen. Im Falle eines Failovers kann der Datensatz Route 53 so aktualisiert werden, dass er auf die neu heraufgestufte primäre Datenbank (früher das Lesereplikat) verweist.
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. In jedem Rechenzentrum muss sich eine Instanz befinden. Es darf immer nur eine Objektspeicherinstanz von beiden Clustern aktiv zum Lesen und Schreiben verwendet werden. Dieser Prozess muss durch eine asynchrone Replikation zur sekundären Instanz ergänzt werden.

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 FQDN der Anwendung ist die primäre Domäne, die von Endbenutzern für den Zugriff auf die Anwendungsoberfläche verwendet wird. Dieser Wert entspricht dem Feld fqdn in input.json. Weitere Informationen finden Sie unter Aktiv-/Passiv-Konfigurationen.
• Clusterspezifische FQDNs: Zusätzlich zum FQDN der Hauptanwendung benötigt jeder Cluster einen eigenen FQDN für Verwaltungs- und Überwachungstools. Dieser Wert wird unter dem Feld cluster_fqdn in input.json Cluster 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)*