Über Bereitstellung

Eine einzelne Orchestrator-Instanz kann gleichzeitig bis zu 1.000 Unattended-Roboter oder bis zu 10.000 Attended-Roboter ausführen. Die empfohlene Bereitstellung für 10.000 Roboter finden Sie in den hier dargestellten Informationen.

Orchestrator unterstützt auch das Multi-Tenancy-Konzept. Der Ansatz wird als „Gemeinsames Schema“ bezeichnet, was bedeutet, dass mehrere Mandanten dieselbe Datenbank und dasselbe Datenbankschema gemeinsam nutzen können. Alle mandantenbezogenen Daten werden in jeder Tabelle eindeutig durch eine eigene TenantId definiert.

Logische Aufteilung

Die UiPath-Server-Plattform hat die folgenden logischen Komponenten, gruppiert in drei Schichten:

Präsentationsschicht
- Webanwendung
- OData-REST-API-Endpunkte
- Benachrichtigungs-API
Webserviceebene
- REST-API-Implementierung
Persistenzebene
- SQL-Server
- Elasticsearch

Die Webanwendung ist die visuelle Ebene der Serverplattform. Der Benutzer interagiert mit den Webseiten, um verschiedene Aktionen durchzuführen: Erstellung von Robotergruppen, Zuweisung von Paketen zu ihnen, Analyse der Protokolle pro Roboter oder Prozess, die die Roboter startet und anhält.

Neben den Webseiten enthält der Orchestrator auch eine Dienstebene, die eine REST-API verfügbar macht, die hauptsächlich aus OData-Endpunkten besteht. REST-API wird sowohl von der Webanwendung als auch von den Agenten verbraucht. Der Agent ist der Supervisor von einem oder mehreren Robotern auf dem Client-Computer.

Orchestrator-Funktionalitäten, abgedeckt von REST-API:

Konfiguration - REST-Endpunkte, die verwendet werden, um Anwendungsbenutzer, Berechtigungen, Roboter, Objekte, Freigaben und Umgebungen zu definieren und zu konfigurieren.
Überwachung und Benachrichtigung - REST-Endpunkte, die zur Registrierung der Agenten verwendet wurden, Lieferung der Konfigurationseinstellungen an die Agenten und zum Senden/Empfangen von Benachrichtigungen vom Server und dem Agenten. Die Benachrichtigungs-API verwendet auch eine WebSocket-Kommunikation. Die Benachrichtigungs-API verwendet auch WebSocket-Kommunikation.
Protokollierung - REST-Endpunkte, die zur Protokollierung verschiedener Informationen wie Fehler, ausdrückliche Meldungen, die von den Robotern gesendet wurden, und andere Umgebungs-spezifische Informationen.
Bereitstellung - REST-Endpunkte, die von den Robotern verwendet wurden, um die Paketversion anzufragen, die ausgeführt werden muss, wenn Sie den Befehl Job starten in Orchestrator verwendet.
Warteschlangen - REST-Endpunkte, die für Warteschlangen und Verwaltung des Warteschlangenobjekts (Queue Item Management) verantwortlich sind, nämlich Hinzufügen der Daten zur Warteschlange, Erhalt einer Transaktion von der Warteschlange, Einstellung des Status einer Transaktion etc.

Komponenten der Persistenzebene:

SQL-Server
- speichert die Konfiguration von Robotern, Robotergruppen und verbundenen Prozessen, Benutzern, Rollen, Zeitplänen – Informationen, die durch die Webanwendungs-Komponente verwaltet werden.
- verwaltet Warteschlangen und Warteschlangenobjekte.
- speichert optionalerweise die Meldungen, die von den Robotern protokolliert wurden (statt oder zusätzlich zu Elasticsearch).
Indexer-Server (Elasticsearch), dessen Rolle ist, die Informationen, die von Robotern protokolliert wurden, zu speichern und zu indizieren. Er kann durch Konfigurationeinstellungen deaktiviert werden.

Hinweis: Meldungen, die von den Robotern protokolliert wurden, können im SQL-Server, im Indexer-Server, in beiden oder in keinem gespeichert werden.

Der Indexer-Server verwendet die Elasticsearch (ein Open Source-Projekt) Volltext-Suchmaschine. Alle Meldungen, die von Robotern protokolliert wurden (unter Verwendung von Aktivitäten wie Protokollmeldung (Log Message) oder Zeile schreiben (Write Line)) werden durch die Protokollierung vom REST-Endpunkt an den Indexer-Server gesendet, wo sie für die zukünftige Auslastung indiziert werden.

Hinweis: Für eine bessere Verteilung der Ressourcen wird empfohlen, den Indexer-Server auf einer separaten Maschine zu installieren, als die, auf der SQL Server installiert ist.

Auf dem Client-Computer wird ein laufender Prozess im oben stehenden Diagramm als Executor darstellt. Es kann mehrere Geschäftsprojekte geben, die gleichzeitig ausgeführt werden, von denen jedes einen entsprechenden Executor hat. Der UiPath-Agent (ein Windows-Dienst) ist der einzelne Kontaktpunkt für alle Executors, durch die alle Meldungen im Orchestrator-Dienst angemeldet werden, der sie weiter verarbeitet (Indexer-Server oder SQL-Server-Datenbank oder beide).

Ein Roboter stellt eine Zuordnung zwischen einem Computernamen und einem Benutzernamen dar. Er kann mehrere Executors gleichzeitig verwalten. Auf Systemen, die mehrere interaktive Sitzungen unterstützen, die gleichzeitig ausgeführt werden (z. B. Windows Server 2012) können mehrere Roboter gleichzeitig ausgeführt werden, wobei jeder in einer separaten Windows-Sitzung einen eindeutigen Benutzernamen verwendet. Wir nennen diese Funktion „High-Density Robots“.

Der UiPath-Agent ist auch für das Versenden des Status des Roboters (z. B. SubmitHeartBeat-Endpunkt) und zum Herunterladen der erforderlichen Version des auszuführenden Pakets verantwortlich.

Die Kommunikation zwischen dem Agenten und Orchestrator wird immer vom Agenten initiiert. Im Benachrichtigungsszenario öffnet der Agent einen WebSocket-Kanal, der später von Orchestrator verwendet wird, um Befehle an den Roboter zu senden (Starten, Anhalten etc.).

Empfehlungen zum Lastausgleich

Wir haben Orchestrator-Bereitstellungen mit hoher Verfügbarkeit und Notfallwiederherstellung mit mehreren Netzwerklastausgleichen getestet, etwa BIG-IP F5, Citrix NetScaler ADC, HAProxy. Da sich die detaillierte Konfiguration eines Netzwerklastausgleichs erheblich von Anbieter zu Anbieter unterscheidet, haben wir die folgenden Empfehlungen:

Empfehlung
	Verwenden eines Lastenausgleichsalgorithmus wie Round Robin oder eines Vorhersage-Round Robin-Derivats
	Verwenden Sie keine persistenten Sitzungen, auch Sticky Sessions genannt
	Verwenden Sie Ihren bevorzugten Netzwerklastausgleich im Layer-7-Modus, da er mit dem Orchestrator API-Zustandsüberprüfungsendpunkt interagieren kann. Dieser API-Endpunkt ist bei `https://your-orchestrator.com/api/status` und gibt `200 OK` zurück, wenn die Orchestrator Web-App in Betrieb ist, und `500`, wenn sie nicht funktioniert. Weitere Informationen finden Sie unter Endpunkte zur Zustandsprüfung im Handbuch zum Orchestrator. Der Netzwerk-Lastausgleich sollte alle 3 bis 5 Sekunden den Endpunkt der API-Zustandsprüfung eines jeden Orchestrator-Servers abfragen.