Abonnieren

UiPath Installation and Upgrade

Die UiPath-Installations- und Upgrade-Anleitung

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)
44150

SQL-Server

CPU Cores (>2GHz)RAM (GB)HDD (GB)
48300

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:

📘

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

Number of RobotsCPU Cores (min 2 GHz)RAM (GB)HDD (GB)
<2044100
<5044100
<10044150
<20044200
<25044200

📘

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

Number of RobotsCPU Cores (min 2 GHz)RAM (GB)HDD (GB)
<2048100
<5048200
<10048300
<20088SSD 400
<250816SSD 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

Number of RobotsCPU Cores (min 2 GHz)RAM (GB)HDD (GB)
<2044100
<5044100
<10048150
<200412200
<250412300

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

Number of RobotsCPU Cores (min 2 GHz)RAM (GB)HDD (GB)
<30088200
<40088220
<5001616250

SQL-Server

Number of RobotsCPU Cores (min 2 GHz)RAM (GB)HDD (GB)
<3001632SSD 400
<4001632SSD 500
<5001632SSD 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

Number of RobotsCPU Cores (min 2 GHz)RAM (GB)HDD (GB)
<300412300
<400416500
<500416600

Große Bereitstellungen

IaaS-Attended-Bereitstellungen

Im folgenden Abschnitt werden die Anforderungen einer großen, skalierbaren Bereitstellung mithilfe von Azure Infrastructure as a Service (IaaS) beschrieben. Die folgenden Dienste sind erforderlich:

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.

Architektur mit einzelnem Knoten

18551855

Architektur mit mehreren Knoten

18431843

Hardwareanforderungen

This section describes the hardware configurations used for the performance testing listed in Scaling Your Deployment, below.

Orchestrator-Knoten

Jeder Orchestrator-Knoten muss wie folgt konfiguriert werden:

VCPUsRAM (GB)SSD (GB)
1632128

SQL-Server

Die SQL Server-Spezifikationen für virtuelle Maschinen müssen entsprechend der Anzahl der Orchestrator-Knoten skaliert werden:

Orchestrator NodesVCPUsRAM (GB)Disk
1 - 28161TB - ultra SSD disk for database, tempDB, and transactional log
516321TB - ultra SSD disk for database
1TB - ultra SSD disk for tempDB
1TB - ultra SSD disk for transactional log
1032641TB - ultra SSD disk for database
1TB - ultra SSD disk for tempDB
1TB - ultra SSD disk for transactional log
1540961TB - ultra SSD disk for database
1TB - ultra SSD disk for tempDB
1TB - ultra SSD disk for transactional log

Elasticsearch-Verfügbarkeitsgruppe

Die Elasticsearch-Verfügbarkeitsgruppe besteht aus 3 Masterknoten und 6 Datenknoten, also insgesamt 9 Knoten mit jeweils den folgenden Spezifikationen:

VCPUsRAM (GB)OS SSD (GB)Data SSD (TB)
816128 (with 5000 IOPS and 100 MB/s Throughput)1 (with 5000 IOPS and 200 MB/s Throughput)

Softwareanforderungen

SoftwareVersion
Operating SystemWindows Server 2016
DatabasesSQL Server 2019
LoggingElasticsearch 7.2.0

The versions listed above are those used for the deployments and performance tested loads described.

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

🚧

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:

Orchestrator Scale Set NodesNo. of Robots
1up to 6,000
2up to 14,000
5up to 80,000
10up to 200,000
15up to 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.

EntityOne NodeTwo NodesFive NodesTen NodesFifteen Nodes
Tenants11111
Folders12446
Robots6,00014,00080,000200,000300,000
Packages8,00016,00048,00048,00048,000
Processes4,0008,00024,00024,00024,000
Queues6001,2001,8002,4003,000
Queue Items1,120,0001,500,0003,000,0005,000,0007,000,000
Assets5001,0001,5003,0004,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.

EntityOne NodeTwo NodesFive NodesTen NodesFifteen Nodes
Queue Items (per day)300,000600,0004,000,0009,000,00010,500,000
Jobs (per minute)7001,5003,0006,0007,500
Logs (per minute)20,00050,000300,000600,000800,000
Nuget Downloads (Maximum per minute)1,0003,00010,00014,00018,000
Robots Connected (Maximum)6,00014,00080,000200,000300,000
Heartbeat (per minute)12,00028,000160,000400,000600,000
Busy Robots3,0007,00040,000100,000150,000
Available Robots3,0007,00040,000100,000150,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:

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.

EntityOne Node
Tenants1
Folders8,000
Robots80,000
Packages8,000
Processes8,000
Queues8,000
Queue Items2,000,000
Assets8,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.

EntityOne Node
Queue Items (per day)5,000,000
Jobs (per minute)2,600
Logs (per minute)240,000
Nuget Downloads (Maximum per minute)2,000
Robots Connected (Maximum)80,000
Heartbeat (per minute)160,000
Busy Robots40,000
Available Robots40,000

TCP-Ports

PortDescription
443Default port for communication between Users and Orchestrator with the connected Robots.
1433Default port for communication between Orchestrator and the SQL Server machine.
9200Communication between Orchestrator and Elasticsearch.
9300Communication between Elasticsearch nodes, if applicable.
5601Default port used by the Kibana plugin, if applicable.
3389Required for RDP automation, needed for High-Density Robots.

You can also check out hardware requirements for Studio and Robot.

Aktualisiert vor 8 Monaten


Hardwareanforderungen


Auf API-Referenzseiten sind Änderungsvorschläge beschränkt

Sie können nur Änderungen an dem Textkörperinhalt von Markdown, aber nicht an der API-Spezifikation vorschlagen.