orchestrator
2020.10
false
Wichtig :
Bitte beachten Sie, dass dieser Inhalt teilweise mithilfe von maschineller Übersetzung lokalisiert wurde.
UiPath logo, featuring letters U and I in white
Kein Support
Installationsanleitung für den Orchestrator
Automation CloudAutomation Cloud Public SectorAutomation SuiteStandalone
Last updated 12. Dez. 2023

Hardwareanforderungen

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:

  • High Availability Add-on (HAA) für 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:
    • 40 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 200. Fügen Sie dazu den Parameter Max Pool Size=200 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=200;" />

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

8

250

Hinweis: Für mehr als 400 Roboter wird empfohlen, die Anzahl der CPU-Cores auf 16 zu erhöhen.
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

Unterstützung von über 500 unbeaufsichtigten Robotern (Unattended Robots)

Wenn Orchestrator mehr als 500 Roboter gleichzeitig unterstützen muss, müssen Sie 2 oder mehr Orchestrator-Knoten und 1 oder mehr HAA-Knoten in einer Farm unter einem Netzwerk-Lastausgleich (Network Load Balancer) bereitstellen. Jeder Knoten sollte die Hardwareanforderungen entsprechend der bedienten Roboteranzahl gemäß der Lastausgleichsanforderungen erfüllen. Bedenken Sie jedoch, dass der SQL Server ein einzelner Computer ist (auch mit Immer-ein-Verfügbarkeitsgruppen (Always On Availability Groups) ist der Primary Replica derjenige, der für die Abwicklung aller I/O-Anfragen zuständig ist). Daher müssen Sie:

  • Die RAM auf dem SQL Server auf 64 GB erhöhen.
  • NUR die Protokollebenen Fehler (Error) und Kritisch (Critical) vom Roboter in der DB speichern.
SQL-Server

Anzahl an Robotern

CPU Cores (min. 2 GHz)

RAM (GB)

HDD (GB)

500

16

64

SSD 800

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.

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.

  • Kleine bis mittlere Bereitstellungen
  • Entwicklungsumgebungen
  • Produktionsumgebungen
  • TCP-Ports

War diese Seite hilfreich?

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