- Erste Schritte
- Anforderungen
- Hardwareanforderungen
- Softwareanforderungen
- Best Practices
- Installation
- Wird aktualisiert
- Identity Server
- Fehlerbehebung bei Startfehlern
Hardwareanforderungen
Es stehen mehrere Cloudbereitstellungsoptionen für Unternehmen zur Verfügung, um Ihren Orchestrator zu hosten, z. B. Amazon Web Services (AWS), Microsoft Azure oder Google Cloud Platform (GCP). Je nach Bereitstellungsoption und Größe der Umgebung, die Sie erstellen möchten, müssen Sie unterschiedliche Hardwareanforderungen beachten.
Dieses Kapitel bietet einen Einblick in die Hardwareanforderungen für einige dieser Szenarien.
Die Hardwareanforderungen unterscheiden sich von Ihrer Entwicklungsumgebung zur Produktionsumgebung. Während die gleichen Hardwareanforderungen wie in Ihrer Produktionsumgebung für Test- und Entwicklungszwecke verwendet werden könnten, bedeutet dies höhere und unnötige Kosten, insbesondere bei umfangreichen Bereitstellungen.
Diese Anforderungen gehen von maximal 100 gleichzeitig laufenden Unattended-Robotern aus. Es können zwei Maschinen verwendet werden, eine für Orchestrator und (optional) Elasticsearch und eine für SQL Server, die wie folgt konfiguriert sind:
Webanwendungsserver
|
CPU Cores (>2GHz) |
RAM (GB) |
HDD (GB) |
|---|---|---|
|
4 |
4 |
150 |
SQL-Server
|
CPU Cores (>2GHz) |
RAM (GB) |
HDD (GB) |
|---|---|---|
|
4 |
8 |
300 |
Für Produktionsumgebungen wird dringend empfohlen, einen dedizierten Server für jede Rolle bereitzustellen:
- Orchestrator-Webanwendung.
- SQL-Server-Datenbank-Engine.
- Elasticsearch und Kibana.
Bei einer Mehrknoteninstallation muss, außer den obigen Anforderungen, folgende Voraussetzung erfüllt sein:
- für den Orchestrator (mindestens 3 HAA-Knoten sind für echte Hochverfügbarkeit und mindestens 6 HAA-Knoten für Georedundanz erforderlich).
Hinweis:
Orchestrator-Bereitstellungen mit mehreren Knoten verwenden das RESP (REdis Serialization Protocol) für die Kommunikation und können daher mithilfe jeder Lösung konfiguriert werden, die auf diesem Protokoll basiert.
HAA ist die einzige Lösung dieser Art, die von UiPath unterstützt wird.
Die Hardwarekonfiguration für jeden erforderlichen Server hängt von der Größe der Bereitstellung ab, wie unten beschrieben. Die hier vorgestellten Hardwareanforderungen wurden auf der Grundlage von Tests durchgeführt, bei denen ein Roboter wie folgt definiert wurde:
- Nachrichten werden mit einer Frequenz von 1 Nachricht pro Sekunde vom Roboter zum Orchestrator gesendet.
- Innerhalb von 60 Sekunden sendet der Roboter:
- 15 Nachrichtenprotokolle
- 2 Heartbeats
- 6 Anfragen zum Abholen von Objekten
- 6 Anfragen zum Hinzufügen von Warteschlangenobjekten
- 6 Anfragen zum Abholen von Warteschlangenobjekten
Unterstützung von bis zu 250 unbeaufsichtigten Robotern (Unattended Robots)
Webanwendungsserver
|
Anzahl an Robotern |
CPU Cores (min. 2 GHz) |
RAM (GB) |
HDD (GB) |
|---|---|---|---|
|
<20 |
4 |
4 |
100 |
|
<50 |
4 |
4 |
100 |
|
<100 |
4 |
4 |
150 |
|
<200 |
4 |
4 |
200 |
|
<250 |
4 |
4 |
200 |
UiPath.Orchestrator.dll.config-Datei zulässig sind, auf 500. Fügen Sie dazu den Parameter Max Pool Size=500 zur Verbindungszeichenfolge hinzu, damit sie diesem Beispiel ähnlich sieht:
<add name="Default" providerName="System.Data.SqlClient" connectionString="Server=SQL4142;Integrated Security=True;Database=UiPath;Max
Pool Size=500;" />
SQL-Server
|
Anzahl an Robotern |
CPU Cores (min. 2 GHz) |
RAM (GB) |
HDD (GB) |
|---|---|---|---|
|
<20 |
4 |
8 |
100 |
|
<50 |
4 |
8 |
200 |
|
<100 |
4 |
8 |
300 |
|
<200 |
8 |
8 |
SSD 400 |
|
<250 |
8 |
16 |
SSD 400 |
Speicherplatzanforderungen hängen stark ab von:
- Ob Warteschlangen verwendet werden oder nicht. Wenn Warteschlangen verwendet werden, hängt es von der durchschnittlichen Anzahl an täglich/wöchentlich hinzugefügten Transaktionen und der Größe (Anzahl von Feldern, Größe der einzelnen Felder) der einzelnen Transaktionen ab.
- Der Rückhaltezeitraum für erfolgreich verarbeitete Warteschlangenobjekte (der Kunde sollte seine eigene Rückhalterichtlinie implementieren).
- Ob Meldungen, die von den Robotern protokolliert werden, in der Datenbank gespeichert werden oder nicht; wenn sie gespeichert werden, kann ein Filter angewendet werden, um nur die DB-spezifischen Meldungen zu speichern (z. B. Speicherung der Meldungen in der DB mit Meldungen der Protokollstufe Fehler (Error) und Kritisch (Critical) und Speicherung in Elasticsearch-Meldungen mit Protokollstufe Informationen (Info), Warnen (Warn) und Rückverfolgung (Trace)).
- Die Häufigkeit der Protokollmeldungen - der Roboterentwickler verwendet die Aktivität Protokollmeldung (Log Message) nach Bedarf, immer wenn er meint, dass eine Meldung es wert ist, protokolliert zu werden.
- Der Aufbewahrungszeitraum für alte protokollierte Meldungen (der Kunde sollte seine eigene Aufbewahrungsrichtlinie implementieren).
- Im Roboter eingestellter Wert für die Protokollstufe. Wenn zum Beispiel die Protokollierungsstufe im Roboter auf Informationen (Info) festgelegt ist, werden nur Meldungen mit den Stufen Informationen (Info), Warnen (Warn), Fehler (Error) und Kritisch (Critical) an Orchestrator gesendet; Meldungen mit den Stufen Fehler beseitigen (Debug), Rückverfolgung (Trace) und Ausführlich (Verbose) werden ignoriert und erreichen Orchestrator nicht.
Elasticsearch-Server
|
Anzahl an Robotern |
CPU Cores (min. 2 GHz) |
RAM (GB) |
HDD (GB) |
|---|---|---|---|
|
<20 |
4 |
4 |
100 |
|
<50 |
4 |
4 |
100 |
|
<100 |
4 |
8 |
150 |
|
<200 |
4 |
12 |
200 |
|
<250 |
4 |
12 |
300 |
Anforderungen an den Festplattenplatz hängen von Folgendem ab:
- Der Aufbewahrungszeitraum (der Kunde sollte seine eigene Aufbewahrungsrichtlinie implementieren).
- Die Häufigkeit der Protokollmeldungen - der Roboterentwickler verwendet die Aktivität Protokollmeldung (Log Message) nach Bedarf, immer wenn er meint, dass eine Meldung es wert ist, protokolliert zu werden.
- Im Roboter eingestellter Wert für die Protokollstufe. Wenn zum Beispiel die Protokollierungsstufe im Roboter auf Informationen (Info) festgelegt ist, werden nur Meldungen mit den Stufen Informationen (Info), Warnen (Warn), „Fehler“ (Error) und „Kritisch“ (Critical) an Orchestrator gesendet; Meldungen mit den Stufen „Fehler beseitigen“ (Debug), „Rückverfolgung“ (Trace) und „Verbose“ (Ausführlich) werden ignoriert und erreichen Orchestrator nicht.
Hinweis: Sie müssen für mehr als 50 Roboter die Java Virtual Machine anweisen, die von Elasticsearch verwendet wird, um 50 % des verfügbaren RAM zu verwenden, indem sowohl das Argument
-Xmsals auch-Xmxauf die Hälfte der Gesamtmenge des Speichers eingestellt wird. Dies wird entweder durch die UmgebungsvariableES_JAVA_OPTSoder durch Bearbeitung der Dateijvm.optionsgemacht.
Unterstützung von zwischen 250 und 500 unbeaufsichtigten Robotern (Unattended Robots)
Webanwendungsserver
|
Anzahl an Robotern |
CPU Cores (min. 2 GHz) |
RAM (GB) |
HDD (GB) |
|---|---|---|---|
|
<300 |
8 |
8 |
200 |
|
<400 |
8 |
8 |
220 |
|
<500 |
16 |
16 |
250 |
SQL-Server
|
Anzahl an Robotern |
CPU Cores (min. 2 GHz) |
RAM (GB) |
HDD (GB) |
|---|---|---|---|
|
<300 |
16 |
32 |
SSD 400 |
|
<400 |
16 |
32 |
SSD 500 |
|
<500 |
16 |
32 |
SSD 600 |
Für mehr als 300 Roboter berücksichtigen Sie bitte, dass Sie nicht alle protokollierten Meldungen in der SQL-Server-Datenbank speichern. Speichern Sie in der DB nur die Meldungen mit Protokollierungsebene Fehler (Error) und Kritisch (Critical). Speichern Sie alle Meldungen (einschließlich Fehler (Error) und Kritisch (Critical)) in Elasticsearch.
Elasticsearch-Server
|
Anzahl an Robotern |
CPU Cores (min. 2 GHz) |
RAM (GB) |
HDD (GB) |
|---|---|---|---|
|
<300 |
4 |
12 |
300 |
|
<400 |
4 |
16 |
500 |
|
<500 |
4 |
16 |
600 |
Der folgende Abschnitt ist ein Beispiel für eine große, skalierbare Bereitstellung unter Verwendung von Azure Infrastructure as a Service (IaaS). Diese Konfiguration wurde verwendet:
- VM-Verfügbarkeitsgruppe für den Orchestrator
- VM-Verfügbarkeitsgruppe für Elasticsearch
- Windows Server SQL-VM
- Azure Load Balancer
- Verteilter DNS-Dienst (z. B. Cloudflare)
Architektur
Die folgenden Architekturbeispiele enthalten optionale und/oder abweichende Komponenten (z. B. CyberArk, UiPath High Availability Add-on).
Die abgebildete Jumpbox ist nicht erforderlich, stellt jedoch eine empfohlene bewährte Methode für Ihre Produktionsumgebungen dar und bietet Isolierung und Sicherheit.
Architektur mit einzelnem Knoten
Architektur mit mehreren Knoten
Hardwareanforderungen
Dieser Abschnitt beschreibt die Hardware-Konfigurationen, die für die Leistungstests verwendet werden, die unten unter Skalierung Ihrer Bereitstellung aufgeführt sind.
Orchestrator-Knoten
Jeder Orchestrator-Knoten muss wie folgt konfiguriert werden:
|
VCPUs |
RAM (GB) |
SSD (GB) |
|---|---|---|
|
16 |
32 |
128 |
SQL-Server
Die SQL Server-Spezifikationen für virtuelle Maschinen müssen entsprechend der Anzahl der Orchestrator-Knoten skaliert werden:
|
Orchestrator-Knoten |
VCPUs |
RAM (GB) |
Festplatte |
|---|---|---|---|
|
1-2 |
8 |
16 |
1TB – Ultra-SSD-Laufwerk für Datenbank, tempDB und Transaktionsprotokoll |
|
5 |
16 |
32 |
1TB – Ultra-SSD-Laufwerk für Datenbank 1TB – Ultra-SSD-Laufwerk für tempDB 1TB – Ultra-SSD-Laufwerk für Transaktionsprotokoll |
|
10 |
32 |
64 |
1TB – Ultra-SSD-Laufwerk für Datenbank 1TB – Ultra-SSD-Laufwerk für tempDB 1TB – Ultra-SSD-Laufwerk für Transaktionsprotokoll |
|
15 |
40 |
96 |
1TB – Ultra-SSD-Laufwerk für Datenbank 1TB – Ultra-SSD-Laufwerk für tempDB 1TB – Ultra-SSD-Laufwerk für Transaktionsprotokoll |
Elasticsearch-Verfügbarkeitsgruppe
Die Elasticsearch-Verfügbarkeitsgruppe besteht aus 3 Masterknoten und 6 Datenknoten, also insgesamt 9 Knoten mit jeweils den folgenden Spezifikationen:
|
VCPUs |
RAM (GB) |
OS SSD (GB) |
Data SSD (TB) |
|---|---|---|---|
|
8 |
16 |
128 (mit 5.000 IOPS und 100 MB/s Durchsatz) |
1 (mit 5000 IOPS und 200 MB/s Durchsatz) |
Softwareanforderungen
Die oben aufgeführten Versionen werden für die beschriebenen Bereitstellungen und leistungsgetesteten Lasten verwendet.
Lastausgleich
Für Bereitstellungen mit mehreren Knoten wird empfohlen, zwei Azure Standard-Lastenausgleiche zu verwenden:
- Einen für die Orchestrator-Server;
- Einen für die Elasticsearch-Server.
High Availability Add-on
-
für den Orchestrator (mindestens 3 HAA-Knoten sind für echte Hochverfügbarkeit und mindestens 6 HAA-Knoten für Georedundanz erforderlich).
Wichtig:Orchestrator-Bereitstellungen mit mehreren Knoten verwenden das RESP (Redis Serialization Protocol) für die Kommunikation und können daher mithilfe jeder Lösung konfiguriert werden, die dieses Protokoll implementiert.
Hochverfügbarkeitsbereitstellungen von Orchestrator werden von UiPath nur unterstützt, wenn das UiPath High Availability Add-on verwendet wird.
Skalieren Ihrer Bereitstellung
Die Anzahl der in Ihrer Orchestrator-Skalierungsgruppe benötigten Knoten hängt von der Anzahl der bereitgestellten Roboter ab:
|
Knoten der Orchestrator-Skalierungsgruppe |
Anzahl der Roboter |
|---|---|
|
1 |
bis zu 6.000 |
|
2 |
bis zu 14.000 |
|
5 |
bis zu 80.000 |
|
10 |
bis zu 200.000 |
|
15 |
bis zu 300.000 |
Diese Bereitstellungen wurden unter Verwendung der oben genannten Hardware- und Softwarekonfigurationen getestet, damit bei der unten angegebenen Belastung kein Leistungsverlust auftritt.
Leistungstests
Die in den folgenden 2 Tabellen angezeigten Daten sind repräsentativ für eine Attended-Bereitstellung.
Statische Daten
Statische Daten beziehen sich auf die anfängliche Orchestrator-Last.
|
Entität |
Ein Knoten |
Zwei Knoten |
Fünf Knoten |
Zehn Knoten |
Fünfzehn Knoten |
|---|---|---|---|---|---|
|
Mandanten |
1 |
1 |
1 |
1 |
1 |
|
Ordner |
1 |
2 |
4 |
4 |
6 |
|
Roboter |
6.000 |
14.000 |
80.000 |
200.000 |
300.000 |
|
Pakete |
8.000 |
16.000 |
48.000 |
48.000 |
48.000 |
|
Prozesse |
4.000 |
8.000 |
24.000 |
24.000 |
24.000 |
|
Warteschlangen |
600 |
1.200 |
1.800 |
2.400 |
3.000 |
|
Warteschlangenobjekte |
1.120.000 |
1.500.000 |
3.000.000 |
5.000.000 |
7.000.000 |
|
Assets |
500 |
1.000 |
1.500 |
3.000 |
4.500 |
Dynamische Daten
Dynamische Daten beziehen sich auf die Daten, die in Orchestrator während der Ausführung von Prozessen hinzugefügt oder geändert werden.
|
Entität |
Ein Knoten |
Zwei Knoten |
Fünf Knoten |
Zehn Knoten |
Fünfzehn Knoten |
|---|---|---|---|---|---|
|
Warteschlangenelemente (pro Tag) |
300.000 |
600.000 |
4.000.000 |
9.000.000 |
10.500.000 |
|
Aufträge (pro Minute) |
700 |
1.500 |
3.000 |
6.000 |
7.500 |
|
Protokolle (pro Minute) |
20,000 |
50.000 |
300.000 |
600.000 |
800.000 |
|
Nuget-Downloads (Maximum pro Minute) |
1.000 |
3.000 |
10,000 |
14.000 |
18.000 |
|
Verbundene Roboter (Maximum) |
6.000 |
14.000 |
80.000 |
200.000 |
300.000 |
|
Heartbeat (pro Minute) |
12.000 |
28.000 |
160.000 |
400.000 |
600.000 |
|
Beschäftigte Roboter |
3.000 |
7.000 |
40.000 |
100.000 |
150.000 |
|
Verfügbare Roboter |
3.000 |
7.000 |
40.000 |
100.000 |
150.000 |
Die folgenden Abschnitte geben einen Einblick in die Leistungsmöglichkeiten einer PaaS-Bereitstellung.
Architektur
Folgende Voraussetzungen sind erforderlich:
-
Orchestrator:
- Orchestrator App Service Plan: 20 P3V2-Instanzen
- Azure SQL Server: Premium P15: 4.000 DTUs
- Azure Redis Cache P2 Premium 13 GB
-
Identity Server:
- Identity Server App Service Plan: 2 Instanzen P3V2
- Azure SQL Server: Standard S7: 800 DTU
-
Elasticsearch:
Leistungstests
Die in den folgenden Tabellen angezeigten Daten sind repräsentativ für eine Attended-Bereitstellung.
Statische Daten
Statische Daten beziehen sich auf die anfängliche Orchestrator-Last.
|
Entität |
Ein Knoten |
|---|---|
|
Mandanten |
1 |
|
Ordner |
8.000 |
|
Roboter |
80.000 |
|
Pakete |
8.000 |
|
Prozesse |
8.000 |
|
Warteschlangen |
8.000 |
|
Warteschlangenobjekte |
2.000.000 |
|
Assets |
8.000 |
Dynamische Daten
Dynamische Daten beziehen sich auf die Daten, die in Orchestrator während der Ausführung von Prozessen hinzugefügt oder geändert werden.
|
Entität |
Ein Knoten |
|---|---|
|
Warteschlangenelemente (pro Tag) |
5.000.000 |
|
Aufträge (pro Minute) |
2.600 |
|
Protokolle (pro Minute) |
240.000 |
|
Nuget-Downloads (Maximum pro Minute) |
2.000 |
|
Verbundene Roboter (Maximum) |
80.000 |
|
Heartbeat (pro Minute) |
160.000 |
|
Beschäftigte Roboter |
40.000 |
|
Verfügbare Roboter |
40.000 |
|
Port |
Beschreibung |
|---|---|
|
443 | Standardport für die Kommunikation zwischen Benutzern und Orchestrator mit den verbundenen Robotern. |
|
1433 | Standardport für die Kommunikation zwischen Orchestrator und der SQL Server-Maschine. |
|
9200 | Kommunikation zwischen Orchestrator und Elasticsearch. |
|
9300 | Kommunikation zwischen Elasticsearch-Knoten, falls zutreffend. |
|
5601 | Standardport, der vom Kibana-Plugin verwendet wird, falls zutreffend. |
|
3389 | Erforderlich für die RDP-Automatisierung, die für High-Density-Roboter benötigt wird. |
