- Überblick
- Anforderungen
- Installation
- Fragen und Antworten: Bereitstellungsvorlagen
- Konfigurieren der Maschinen
- Konfigurieren des externen Objektspeichers
- Konfigurieren einer externen Docker-Registrierung
- Konfigurieren des DNS
- Konfigurieren von Microsoft SQL-Servern
- Konfigurieren der Zertifikate
- Online-Auswertungsinstallation mit einem Knoten
- Offline-Auswertungsinstallation mit einem Knoten
- Konfigurieren der Maschinen
- Konfigurieren des externen Objektspeichers
- Konfigurieren einer externen Docker-Registrierung
- Konfigurieren des Lastausgleichs
- Konfigurieren des DNS
- Konfigurieren von Microsoft SQL-Servern
- Konfigurieren der Zertifikate
- HA-fähige Online-Produktionsinstallation mit mehreren Knoten
- HA-fähige Offline-Produktionsinstallation mit mehreren Knoten
- Disaster Recovery – Installieren des sekundären Clusters
- Herunterladen der Installationspakete
- install-uipath.sh-Parameter
- Aktivieren eines High Availability Add-ons für den Cluster
- Document Understanding-Konfigurationsdatei
- Hinzufügen eines dedizierten Agent-Knotens mit GPU-Unterstützung
- Hinzufügen eines dedizierten Agent-Knotens für Task Mining
- Verbinden einer Task Mining-Anwendung
- Hinzufügen eines dedizierten Agentenknotens für Automation Suite-Roboter
- Nach der Installation
- Clusterverwaltung
- Verwalten von Produkten
- Erste Schritte mit dem Clusterverwaltungsportal
- Migrieren von Objectstore von persistentem Volume zu Raw-Festplatten
- Migrieren von Daten zwischen Objectstores
- Clusterinterner Objectstore zu einem externen Objectstore migrieren
- Wechsel zum sekundären Cluster
- 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
- Überwachung und Warnungen
- Migration und Upgrade
- Migrationsoptionen
- Schritt 1: Verschieben der Identitätsorganisationsdaten von einer eigenständigen in die Automation Suite
- Schritt 2: Wiederherstellen der eigenständigen Produktdatenbank
- Schritt 3: Sichern der Plattformdatenbank in der Automation Suite
- Schritt 4: Zusammenführen von Organisationen in der Automation Suite
- Schritt 5: Aktualisieren der migrierten Produktverbindungszeichenfolgen
- Step 6: Migrating standalone Insights
- Schritt 7: Löschen des Standardmandanten
- B) Migration von einzelnen Mandanten
- Produktspezifische Konfiguration
- Best Practices und Wartung
- Fehlersuche und ‑behebung
- Fehlerbehebung bei Diensten während der Installation
- Deinstallieren des Clusters
- Löschen von Offline-Artefakten für mehr Speicherplatz
- So löschen Sie Redis-Daten
- So können Sie die Istio-Protokollierung aktivieren
- So werden Protokolle manuell bereinigt
- So löschen Sie alte Protokolle, die im sf-logs-Paket gespeichert sind
- So deaktivieren Sie Streaming-Protokolle für das AI Center
- Fehlerbehebung bei fehlgeschlagenen Automation Suite-Installationen
- So löschen Sie Bilder aus dem alten Installationsprogramm nach dem Upgrade
- Automatisches Bereinigen von Longhorn-Snapshots
- Deaktivieren von NIC-Prüfsummen-Offloading
- So legen Sie die ArgoCD-Protokollebene manuell auf Info fest
- Es kann keine Offlineinstallation auf RHEL 8.4 OS ausgeführt werden.
- Fehler beim Herunterladen des Pakets
- Die Offlineinstallation schlägt aufgrund fehlender binärer Dateien fehl
- Zertifikatproblem bei der Offlineinstallation
- Die erste Installation schlägt während des Longhorn-Setups fehl
- Validierungsfehler bei der SQL-Verbindungszeichenfolge
- Voraussetzungsprüfung für das Selinux-iscsid-Modul schlägt fehl
- Azure-Datenträger nicht als SSD markiert
- Fehler nach der Zertifikatsaktualisierung
- Virenschutz verursacht Probleme bei der Installation
- Automation Suite funktioniert nach Betriebssystem-Upgrade nicht
- Bei der Automation Suite muss „backlog_wait_time“ auf 0 gesetzt werden.
- GPU-Knoten von Nichtverfügbarkeit von Ressourcen betroffen
- Volume nicht bereitstellbar, da es nicht für Workloads bereit ist
- Fehler beim Hoch- oder Herunterladen von Daten im Objektspeicher
- Die Größenänderung eines PVC bewirkt keine Korrektur von Ceph
- Fehler beim Ändern der PVC-Größe
- Fehler beim Ändern der Größe von objectstore PVC
- Rook Ceph oder Looker-Pod hängen im Init-Status fest
- Fehler beim Anhängen eines StatefulSet-Volumes
- Fehler beim Erstellen persistenter Volumes
- Patch zur Rückgewinnung von Speicherplatz
- Sicherung aufgrund des Fehlers „TooManySnapshots“ fehlgeschlagen
- Alle Longhorn-Replikate sind fehlerhaft
- Festlegen eines Timeout-Intervalls für die Verwaltungsportale
- Aktualisieren Sie die zugrunde liegenden Verzeichnisverbindungen
- Die Authentifizierung funktioniert nach der Migration nicht
- Kinit: KDC kann für Realm <AD Domain> beim Abrufen der ersten Anmeldeinformationen nicht gefunden werden.
- Kinit: Keytab enthält keine geeigneten Schlüssel für *** beim Abrufen der ersten Anmeldeinformationen
- GSSAPI-Vorgang aufgrund eines ungültigen Statuscodes fehlgeschlagen
- Alarm für fehlgeschlagenen Kerberos-tgt-update-Auftrag erhalten
- SSPI-Anbieter: Server in Kerberos-Datenbank nicht gefunden
- Anmeldung eines AD-Benutzers aufgrund eines deaktivierten Kontos fehlgeschlagen
- ArgoCD-Anmeldung fehlgeschlagen
- Fehler beim Abrufen des Sandbox-Abbilds
- Pods werden nicht in der ArgoCD-Benutzeroberfläche angezeigt
- Redis-Testfehler
- RKE2-Server kann nicht gestartet werden
- Secret nicht im UiPath-Namespace gefunden
- ArgoCD wechselt nach der ersten Installation in den Status „In Bearbeitung“.
- Probleme beim Zugriff auf das schreibgeschützte ArgoCD-Konto
- MongoDB-Pods in „CrashLoopBackOff“ oder ausstehende PVC-Bereitstellung nach Löschung
- Fehlerhafte Dienste nach Clusterwiederherstellung oder Rollback
- Pods stecken in Init:0/X
- Prometheus im Zustand „CrashloopBackoff“ mit OOM-Fehler (Out-of-Memory)
- Fehlende Ceph-rook-Metriken in Überwachungs-Dashboards
- Document Understanding erscheint nicht auf der linken Leiste der Automation Suite
- Fehlerstatus beim Erstellen einer Datenbeschriftungssitzung
- Fehlerstatus beim Versuch, eine ML-Fähigkeit bereitzustellen
- Migrationsauftrag schlägt in ArgoCD fehl
- Die Handschrifterkennung mit dem Intelligent Form Extractor funktioniert nicht oder arbeitet zu langsam
- Verwenden des Automation Suite-Diagnosetools
- Verwenden des Automation Suite Support Bundle-Tools
- Erkunden von Protokollen
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 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.
Sie können die Wiederherstellungszeit reduzieren, indem Sie den Traffic Manager so konfigurieren, dass der Datenverkehr immer an den primären Cluster weitergeleitet wird, wenn verfügbar. Die Umleitung zum sekundären Cluster darf nur dann erfolgen, wenn der primäre Cluster ausgefallen ist. Dies gewährleistet, dass die Verkehrsumschaltung automatisch erfolgt und die Zeit für eine manuelle Umschaltung verkürzt wird. Sie können dazu die Integritätsendpunkte der beiden Cluster verwenden.
Wenn alle Knoten des sekundären Clusters ausgeführt werden, können Sie die Knoten zeitsparend einschalten und warten, bis der Cluster aktiv ist. Dadurch können sich jedoch die Kosten Ihrer Infrastruktur fast verdoppeln.
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 Sites 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.