orchestrator
2023.4
false
Wichtig :
Bitte beachten Sie, dass dieser Inhalt teilweise mithilfe von maschineller Übersetzung lokalisiert wurde.
Installationsanleitung für den Orchestrator
Automation CloudAutomation Cloud Public SectorAutomation SuiteStandalone
Last updated 3. Okt. 2024

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

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 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 -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: Bei der SQL Server Standard Edition nutzt die Standardversion maximal 16 CPU-Kerne. Stellen Sie bei einer virtuellen Maschine sicher, dass sich diese Anzahl von Kernen durch 4 virtuelle Sockets mit jeweils 4 Kernen ergibt (und nicht durch 2 Sockets mit 8 Kernen oder 8 Sockets mit 2 Kernen). Für die Enterprise Edition ist es egal, durch welche Kombination Sie auf 16 Kerne kommen.

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:

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


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

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.

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.

War diese Seite hilfreich?

Hilfe erhalten
RPA lernen – Automatisierungskurse
UiPath Community-Forum
Uipath Logo White
Vertrauen und Sicherheit
© 2005–2024 UiPath. Alle Rechte vorbehalten