Grundlegende Architekturüberlegungen

Überlegungen zu Infrastruktur, Latenz, Datenquelle, Verwaltung, RTO und RPO für die Automation Suite mit mehreren Sites auf EKS/AKS.

Wie bei jeder standortübergreifenden Bereitstellung sollten auch bei der Automation Suite in erster Linie die Infrastruktur, die Datenquelle, die Verwaltung, das Ziel für die Wiederherstellungszeit, das Ziel für den Wiederherstellungspunkt usw. in Bezug auf die Architektur berücksichtigt werden.

Infrastruktur

Es wird empfohlen, für beide Cluster dieselbe Hardware zu verwenden. Der Automation Suite-Cluster funktioniert jedoch wahrscheinlich mit ähnlichen Hardwarekonfigurationen mit geringen Unterschieden. Heterogene Hardware kann die Komplexität erhöhen und die Fehlerbehebung verlangsamen.

Verwaltung

Die beiden Automation Suite-Cluster sind unabhängig und haben keine gemeinsame Konfiguration. Daher muss jede Verwaltungs- oder Wartungsaktivität für diese Cluster einzeln durchgeführt werden. Sie müssen beispielsweise die SQL-Verbindungszeichenfolgen auf beiden Clustern aktualisieren, Zertifikate getrennt konfigurieren usw. Zudem müssen Sie die beiden Cluster unabhängig voneinander überwachen, sie einzeln aktualisieren usw.

Datenquelle

Der Objektspeicher bildet in Kombination mit der SQL-Datenbank den Status eines installierten Produkts in der Automation Suite.

SQL-Server-Konfiguration

Die SQL Server-Konfiguration spielt eine wichtige Rolle in einer Bereitstellung mit mehreren Standorten. Obwohl der SQL-Server eine externe Komponente der Automation Suite ist, sind ein paar zusätzliche Schritte erforderlich, um eine echte HA bei der Arbeit mit der gesamten Automation Suite zu gewährleisten.

Der SQL-Server sollte entweder in der Always On-Verfügbarkeitsgruppe oder in einer Failure Over-Gruppe konfiguriert werden. Er muss auf beide Sites verteilt werden, um eine genaue Hochverfügbarkeit sicherzustellen, wenn eine Site ausfällt. Beide Cluster sollten denselben SQL Listener-Endpunkt in der Verbindungszeichenfolge verwenden. Darüber hinaus wird empfohlen, die Eigenschaft MultiSubnetFailover=True in der Verbindungszeichenfolge festzulegen, wenn der SQL-Server/die Datenbanken über mehrere Subnetze verteilt sind.

Weitere Informationen finden Sie unter Arbeiten mit Lesen-Replikaten für Microsoft SQL Server in Amazon RDS, Always On-Verfügbarkeitsgruppen und Voraussetzungen, Einschränkungen und Empfehlungen für Always On-Verfügbarkeitsgruppen.

PostgreSQL-Serverkonfiguration

Wie SQL Server befindet sich PostgreSQL außerhalb der Automation Suite, aber für eine echte HA in einer Bereitstellung mit mehreren Sites sind ein paar zusätzliche Schritte erforderlich. PostgreSQL wird von Process Mining, Autopilot for Developers und Temporal as a Service verwendet. Für die Disaster Recovery muss der Autopilot for Developers auf die sekundäre Site repliziert werden. Die Process Mining-Datenbank erfordert keine standortübergreifende Replikation. TaaS wird im sekundären Cluster nicht unterstützt; Sie wird nur am primären Site in einer A/P-Bereitstellung unterstützt.

Konfigurieren Sie einen primären PostgreSQL-Server an Site 1 mit physischer Replikation zu mindestens einem schreibgeschützten Standby-Server an Site 2 und verweisen Sie beide Cluster über einen einzigen Endpunkt auf den aktuellen primären Server. Im Falle einer Katastrophe stufen Sie den Site 2-Standby-Start zum primären und aktualisieren Sie den Endpunkt so, dass er auf Site 2 verweist.

• Verwalteter Dienst: Verwenden Sie die regionsübergreifende Replikation des Anbieters und seine Endpunktaktualisierung während eines Failover, z. B. Amazon RDS für PostgreSQL, Amazon Azure PostgreSQL Global Database oder Azure Database für PostgreSQL.
• Selbstverwaltet: Stellen Sie den primären mit einem DNS-Datensatz bereit (z. B. Amazon Route 53), damit beide Cluster dieselbe Adresse verwenden. Aktualisieren Sie den DNS-Datensatz, um während des Failover auf den sekundären Datensatz zu verweisen.

Externe Objectstore-Konfiguration

Der externe Objektspeicher ist immun gegen eine mögliche Beeinträchtigung durch einen Knotenausfall. Datenreplikation und Disaster Recovery können unabhängig von der Automation Suite durchgeführt werden. Wie SQL-Server muss der externe Objektspeicher in einem High Availability Disaster Recovery-Setup konfiguriert werden.

Die primäre Objektspeicherinstanz befindet sich physisch im primären Rechenzentrum und mindestens eine sekundäre Instanz befindet sich in dem sekundären Rechenzentrum mit aktivierter Datensynchronisierung. Sie können einen Lastausgleich auf dem Objektspeicher konfigurieren, um sicherzustellen, dass beide Automation Suite-Cluster auf dieselben Endpunkte verweisen. Somit ist die Bereitstellung von der internen Konfiguration des Objektspeichers unabhängig.

Wichtig:

Bei AWS S3 unterstützt der Zugriffspunkt mit mehreren Regionen nicht alle s3-APIs, die von allen Produkten benötigt werden, die in der Automation Suite ausgeführt werden. Weitere Informationen zur Liste der unterstützten APIs finden Sie unter Verwenden von Zugriffspunkten für mehrere Regionen mit unterstützten API-Vorgängen.

Sie können zwei Buckets pro Produkt/Suite in beiden Regionen erstellen und die Synchronisierung aktivieren. Der Automation Suite-Cluster, der in derselben Region ausgeführt wird, verweist auf die Buckets in derselben Region.

Ziel der Wiederherstellungszeit

Die RTO-Richtlinie Ihres Unternehmens ist für die Konzeption Ihres Automation Suite-Clusters mit mehreren Sites entscheidend. Berücksichtigen Sie die folgenden Aspekte, um das gewünschte RTO zu erreichen:

• Design des Traffic Managers;
• Verfügbarkeit der Knoten im sekundären/passiven Cluster;
• Dynamische Workload-Verfügbarkeit auf dem sekundären Cluster; Beispiel: MLFähigkeit;
• Konfigurationsverwaltung.

Traffic Manager

Um das volle Potenzial beider Cluster auszuschöpfen, ist es wichtig, den Traffic Manager entsprechend zu konfigurieren. Die Einrichtung sollte idealerweise die Verteilung des Datenverkehrs auf beide Cluster erleichtern. Diese Strategie gewährleistet nicht nur eine ausgewogene Lastverteilung, sondern gewährleistet auch die Geschäftskontinuität, indem sie mögliche Unterbrechungen im Falle eines vollständigen Ausfalls eines der beiden Standorte reduziert.

Knotenverfügbarkeit

Sollte eine Katastrophe dazu führen, dass ein Standort vollständig ausfällt, so muss der andere Standort über ausreichende Kapazitäten verfügen, um die Geschäftsautomatisierung nicht zu beeinträchtigen. Eine unzureichende Kapazität am funktionierenden Standort kann sich negativ auf den Geschäftsbetrieb auswirken und möglicherweise zu erheblichen betrieblichen Problemen führen.

Dynamische Workload-Verfügbarkeit

Einige Produkte, z. B. das AI Center, stellen die ML-Fähigkeiten dynamisch zur Laufzeit bereit. Die Bereitstellung der Fähigkeiten in einem anderen Cluster ist immer asynchron. Dadurch kann ihre Verfügbarkeit nicht garantiert werden. Um sicherzustellen, dass Ihre Automatisierungslösung innerhalb der gewünschten Zeit wieder online ist, können Sie die Fähigkeiten in einem anderen Cluster regelmäßig synchronisieren.

Konfigurationsverwaltung

Da Automation Suite-Bereitstellungen mit mehreren Standorten aus zwei verschiedenen Clustern bestehen, muss jeder Vorgang, der auf einem beliebigen Cluster ausgeführt wird, rechtzeitig auf dem anderen Cluster ausgeführt werden, um die Abweichung zu verringern. Dadurch wird sichergestellt, dass beide Cluster über ähnliche Konfigurationen verfügen und während der Wiederherstellungsphase kein zusätzlicher Aufwand erforderlich ist.

Ziel des Wiederherstellungspunkts

Die Richtlinie Ihrer Organisation rund um das Ziel des Wiederherstellungspunkts ist von entscheidender Bedeutung für den Entwurf eines Automation Suite-Clusters mit mehreren Sites. Um das gewünschte RPO zu erreichen, müssen Sie die folgenden Aspekte berücksichtigen:

• Datensynchronisierung;
• Geplante Sicherung.

Datensynchronisierung

Wenn Daten in die primäre Datenquelle geschrieben werden, müssen sie auch mit dem sekundären Cluster synchronisiert werden. Es besteht jedoch das Risiko von Datenverlusten, wenn das Rechenzentrum ausgefallen ist und die Daten nicht synchronisiert werden. Beispielhafte Netzwerkkonfigurationen, z. B. hohe Bandbreite und geringe Latenz zwischen den beiden Rechenzentren, können die Synchronisierung beschleunigen.

Geplante Sicherung

Nicht jede Disaster Recovery bietet vollständige Immunität gegen Datenverlust. Sie können jedoch eine regelmäßige und periodische Sicherungsstrategie anwenden, um die negativen Auswirkungen auf die Datenwiederherstellung zu minimieren. Weitere Informationen finden Sie unter Sichern und Wiederherstellen des Clusters.