- Überblick
- Anforderungen
- Vor der Installation
- Vorbereiten der Installation
- Installieren und Konfigurieren des Dienstgeflechts
- Herunterladen der Installationspakete
- Konfigurieren der OCI-konformen Registrierung
- Erteilen von Installationsberechtigungen
- Installieren und Konfigurieren des GitOps-Tools
- Anwenden verschiedener Konfigurationen
- Ausführen von uipathctl
- Installation
- Nach der Installation
- Migration und Upgrade
- Aktualisieren der Automation Suite
- Migrieren von eigenständigen Produkten zur Automation Suite
- Schritt 1: Wiederherstellen der eigenständigen Produktdatenbank
- Schritt 2: Aktualisieren des Schemas der wiederhergestellten Produktdatenbank
- Schritt 3: Verschieben der Identitätsorganisationsdaten von der eigenständigen Bereitstellung in die Automation Suite
- Schritt 4: Sichern der Plattformdatenbank in der Automation Suite
- Schritt 5: Zusammenführen von Organisationen in der Automation Suite
- Schritt 6: Aktualisieren der migrierten Produktverbindungszeichenfolgen
- Schritt 7: Migrieren des eigenständigen Orchestrator
- Schritt 8: Migrieren von eigenständigen Insights
- Schritt 9: Löschen des Standardmandanten
- Durchführen der Migration eines einzelnen Mandanten
- Migrieren zwischen Automation Suite-Clustern
- Migrieren von der Automation Suite auf EKS/AKS zur Automation Suite auf OpenShift
- Überwachung und Warnungen
- Clusterverwaltung
- Durchführen einer Datenbankwartung
- Konfigurieren des FQDN nach der Installation
- Weiterleiten von Protokollen an externe Tools
- Manueller Wechsel zum sekundären Cluster in einem Aktiv-/Passiv-Setup
- Disaster Recovery: Durchführen von Vorgängen nach der Installation
- Umwandlung einer bestehenden Installation in eine Multi-Site-Einrichtung
- Richtlinien zum Upgrade einer Aktiv-/Passiv-Bereitstellung
- Leitlinien zum Sichern und Wiederherstellen einer Aktiv-/Passiv-Bereitstellung
- Produktspezifische Konfiguration
- Konfigurieren von Orchestrator-Parametern
- Konfigurieren von AppSettings
- Konfigurieren der maximalen Anforderungsgröße
- Überschreiben der Speicherkonfiguration auf Clusterebene
- Konfigurieren von NLog
- Speichern von Roboterprotokollen in Elasticsearch
- Konfigurieren von Anmeldeinformationsspeichern
- Konfigurieren der Verwendung von einem Verschlüsselungsschlüssel pro Mandant
- Bereinigen der Orchestrator-Datenbank
- Fehlersuche und ‑behebung
- Zugriff auf Automation Hub nach Upgrade auf Automation Suite 2024.10.0 nicht mehr möglich
- AI Center-Bereitstellungsfehler nach Upgrade auf 2023.10 oder höher
- Insights-Volumes, die nach der Migration in zwei verschiedenen Zonen erstellt wurden
- Upgrade schlägt aufgrund überschriebener Insights-PVC-Größen fehl
- Das Sicherungssetup funktioniert nicht, da die Verbindung mit Azure Government fehlgeschlagen ist
- Hängende Pods im uipath-Namespace bei Aktivierung von benutzerdefinierten Knoten-Markierungen
- Automation Hub und Apps können mit Proxy-Setup nicht gestartet werden
- Der Roboter kann keine Verbindung mit einer Automation Suite-Orchestrator-Instanz herstellen

Automation Suite in der EKS/AKS-Installationsanleitung
Grundlegende Architekturüberlegungen
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.
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.
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.
Der Objektspeicher bildet in Kombination mit der SQL-Datenbank den Status eines installierten Produkts in der Automation Suite.
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.
MultiSubnetFailover=True
in der Verbindungszeichenfolge festzulegen, wenn der SQL-Server/die Datenbanken über mehrere Subnetze verteilt sind.
Weitere Informationen finden Sie unter Arbeiten mit gelesenen 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.
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.
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.
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.
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.
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.
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.
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.
Die Richtlinie Ihrer Organisation rund um das Ziel des Wiederherstellungspunkts (Recovery Point Objective, RPO) 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.
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.
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.