Bereitstellung in der Cloud (Deployment in the Cloud)

Es stehen mehrere Cloud-Bereitstellungsoptionen für Unternehmen zur Verfügung, um Ihre Orchestrator-Instanz zu hosten, z. B. Amazon Web Services (AWS), Microsoft Azure oder Google Cloud Platform (GCP). Hier erläutern wir eine große, skalierbare Bereitstellung unter Verwendung der Azure IaaS-Angebote (Infrastructure as a Service). Die folgenden Dienste sind erforderlich:

• VM-Verfügbarkeitsgruppe für den Orchestrator
• VM-Verfügbarkeitsgruppe für Elasticsearch
• Azure SQL Server
• Azure Load Balancer
• Azure Redis Cache für Bereitstellungen mit mehreren Knoten
• 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.

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)
1-2	8	16
5	16	32
10	16	64

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

Software	Version
Betriebssystem	Windows-Server 2016
Datenbanken	SQL Server 2017
Protokollierung	Elasticsearch 6.4.0

Die oben aufgeführten Versionen sind diejenigen, die für die beschriebenen Bereitstellungen und leistungsgetesteten Lasten verwendet werden. Alle mit Orchestrator kompatiblen Versionen finden Sie hier.

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.

Azure Redis Cache

Wichtig:

Orchestrator-Bereitstellungen mit mehreren Knoten verwenden das RESP (REdis Serialization Protocol) für die Kommunikation und können daher mit jeder Lösung konfiguriert werden, die dieses Protokoll implementiert, wie Azure Redis Cache in diesem Beispiel.

Hochverfügbarkeitsbereitstellungen von Orchestrator werden von UiPath nur unterstützt, wenn das UiPath High Availability Add-on verwendet wird.

Für Bereitstellungen mit mehreren Knoten wird empfohlen, zwei separate Redis-Instanzen zu verwenden:

• Azure Redis Cache Premium mit einem 6-GB-Cache – der primären Knoten, der für Sitzungsstatus- und Benutzerentitätszuordnungen verwendet wird;
• Azure Redis Cache Basic – wird zum Skalieren des SignalR-Diensts verwendet.

Konfiguration

Einstellungen für UiPath.Orchestrator.dll.config

1. Legen Sie alle Orchestrator-Knoten so fest, dass sie an Elasticsearch statt an ihr jeweiliges Windows-Ereignisprotokoll berichten, indem Sie den Parameter writeTo im Index serverdiagnostics wie folgt festlegen:

   <logger name="*" minlevel="Warn" writeTo="serverElasticBuffer"/>

2. Aktivieren Sie Quartz-Auftragsclustering wie folgt:

   <add key="quartz.jobStore.clustered" value="true" />

3. Konfigurieren Sie im Abschnitt „Bereitstellung“ das NuGet-Repository wie folgt:

   <add key="NuGet.Repository.Type" value="Composite" />
   <add key="Deployment.Libraries.AllowTenantPublish" value="true" />
   <add key="Processes.AllowUpdateWithRunningJobs" value="true" />

4. Im Abschnitt „Lastenausgleich“ konfigurieren Sie die Redis-Instanzen wie folgt, wobei Sie darauf achten müssen, die Verbindungszeichenfolge und das Kennwort durch Ihre jeweiligen Werte zu ersetzen:

   <add key="LoadBalancer.UseSqlServer" value="false"/>
   <add key="LoadBalancer.UseRedis" value="true"/>
   <add key="LoadBalancer.Redis.ConnectionString" value="<your.redis.cache.windows.net>:6379,password=****"/>
   <add key="LoadBalancer.SignalR.UseRedisScaleout" value="true"/>
   <add key="LoadBalancer.SignalR.RedisScaleout.ConnectionString" value="<your.second.Redis.Server>:6379,password=********"/>

5. Legen Sie Max Pool Size in der Datenbankverbindungszeichenfolge wie folgt fest:

   <add connectionString="Data Source=172.16.100.12;Initial Catalog=UiPath;User ID=admin;Password=*******;Max Pool Size=700" name="Default" providerName="System.Data.SqlClient" />

   Hinweis: Ersetzen Sie die Parameter Data Source, Initial Catalog, User ID und Password durch die entsprechenden Werte Ihres Orchestrator-Azure-Diensts. Weitere Details finden Sie hier.
6. Legen Sie die Elasticsearch-Puffergröße wie folgt fest:

   <target name="robotElasticBuffer" xsi:type="BufferingWrapper" bufferSize="1000" flushTimeout="5000">

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 4.000
2	bis zu 8.000
5	bis zu 24.000
10	bis zu 48.000

Diese Bereitstellungen wurden unter Verwendung der oben genannten Hardware- und Softwarekonfigurationen getestet, damit bei der unten angegebenen Belastung kein Leistungsverlust auftritt.

Leistungstests

Statische Daten

Statische Daten beziehen sich auf die anfänglich vorhandene Orchestrator-Last.

Entität	Ein Knoten	Zwei Knoten	Fünf Knoten	Zehn Knoten
Mandanten	40	80	240	480
Umgebungen	2.000	4.000	12.000	24.000
Roboter Attended Floating Unbeaufsichtigt	4.000 1,600 1,600 800	8.000 3,200 3,200 1,600	24.000 9.600 9.600 4.800	48.000 19.200 19.200 9.600
Pakete	8.000	16.000	48.000	96.000
Prozesse	4.000	8.000	24.000	48.000
Warteschlangen	200	420	1.200	2.400
Warteschlangenobjekte	1.120.000	1.500.000	3.000.000	5.000.000
Assets	40.000	80.000	240.000	480.000
Zeitpläne	400	800	2.400	4.800

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
Warteschlangenelemente (pro Tag)	112.000	175,000	672.000	1.250.000
Aufträge (pro Minute)	2.000	4.000	12.000	24.000
Protokolle (pro Minute)	20,000	20,000	20,000	25,000
Nuget-Downloads (Maximum pro Minute)	2.000	4.000	12.000	24.000
Verbundene Roboter (Maximum)	4.000	8.000	24.000	48.000
Heartbeat (pro Minute)	10,000	20,000	60,000	120,000
SignalR-Benachrichtigungen (pro Minute)	2.000	4.000	12.000	24.000
Beschäftigte Roboter	2.000	4.000	12.000	24.000
Verfügbare Roboter	2.000	4.000	12.000	24.000