Ü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 ist. 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.
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 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.

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 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 FQDN der Hauptanwendung benötigt jeder Cluster einen eigenen FQDN für Verwaltungs- und Überwachungstools. Dieser Wert wird unter dem Feld cluster_fqdn in der Datei input.json jedes Clusters definiert. Weitere Informationen finden Sie unter Aktiv-/Passiv-Konfigurationen.
• Unterdomänen: Für einen 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> – Von Apps verwendet.
    • insights.<domain> – Wird von 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> – Für Beobachten 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 denselben Lastausgleich 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 Systemstatus an den entsprechenden Lastausgleich weitergeleitet wird – entweder während des normalen Betriebs oder der Disaster Recovery.

• Normaler Betrieb (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 Disaster Recovery-Modus. In diesem Status wird das DNS angepasst, um die Kontinuität des Dienstes sicherzustellen:

  FQDN-Typ	Weiterleitungsziel
  FQDN	Sekundärer Cluster-Lastausgleich
  Primärer Cluster-FQDN	Primärer Cluster-Lastausgleich(unverändert)
  Sekundärer Cluster-FQDN	Sekundärer Cluster-Lastausgleich(unverändert)