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.

Kleine bis mittlere Bereitstellungen

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.

Entwicklungsumgebungen

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

Produktionsumgebungen

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

Hinweis:

Erhöhen Sie bei mehr als 200 Robotern die Anzahl der Verbindungen, die im Pool der SQL-Verbindungszeichenfolge aus der 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 fr 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 -Xms als auch -Xmx auf die Hälfte der Gesamtmenge des Speichers eingestellt wird. Dies wird entweder durch die Umgebungsvariable ES_JAVA_OPTS oder durch Bearbeitung der Datei jvm.options gemacht.

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

Hinweis:

Für eine SQL-Server-Standardversion sind 16 CPU-Cores das Maximum, was die Standardversion verwenden wird. Stellen Sie für eine virtuelle Maschine bitte sicher, dass die Anzahl der Cores als 4 virtuelle Sockets mit jeweils 4 Cores erhalten wird (und nicht als 2 Sockets mit 8 Cores oder 8 Sockets mit 2 Cores). Für die Enterprise-Version ist es egal, welche die Kombination ist, um 16 Cores zu erhalten.

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

Große Bereitstellungen

IaaS-Attended-Bereitstellungen

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

Hinweis:

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.

Abbildung 1. Architektur mit einzelnem Knoten

Abbildung 2. 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	1 TB – Ultra-SSD-Laufwerk für Datenbank 1 TB – Ultra-SSD-Laufwerk für tempDB 1 TB – Ultra-SSD-Laufwerk für Transaktionsprotokoll
10	32	64	1 TB – Ultra-SSD-Laufwerk für Datenbank 1 TB – Ultra-SSD-Laufwerk für tempDB 1 TB – Ultra-SSD-Laufwerk für Transaktionsprotokoll
15	40	96	1 TB – Ultra-SSD-Laufwerk für Datenbank 1 TB – Ultra-SSD-Laufwerk für tempDB 1 TB – 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

• Betriebssystem
• Datenbanken
• Protokollierung

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

PaaS-Attended-Bereitstellungen

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:
  • VM-Verfügbarkeitsgruppe

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

TCP-Ports

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.

Sie können auch die Hardwareanforderungen für Studio und Robot überprüfen.