Architektur und Design mit mehreren Knoten

Das folgende Architekturdiagramm zeigt eine Bereitstellung von Automation Suite unter Linux mit Kubernetes, das auf sechs Maschinen installiert ist, einem Lastausgleich und Datenspeicher. Es gibt mehrere Maschinentypen: drei Serverknoten, zwei Agent-Knoten und einen spezialisierten Agent-Knoten.

Serverknoten

Serverknoten hosten die Kubernetes-Steuerebene, die den gesamten Kubernetes-Cluster steuert. Bei einer typischen Bereitstellung mit mehreren Knoten ist eine ungerade Anzahl von Serverknoten erforderlich, wobei mindestens drei Server erforderlich sind. Diese Einschränkung ist auf die Komponente etcd zurückzuführen, die Teil der Kubernetes-Steuerebene ist. Weitere Informationen finden Sie in der etcd-Dokumentation. Aus dem gleichen Grund muss der Großteil der Serverknoten jederzeit verfügbar sein, um den Cluster fehlerfrei zu halten.

Diese Knoten hosten auch die Komponenten, die Datenspeicher auf den Knoten erfordern, z. B. Prometheus, der clusterinterne Objektspeicher Ceph, UiPath Insights und die clusterinterne Docker-Registrierung.

Agent-Knoten

Agent nodes are sometimes called worker nodes. The purpose of these nodes is to host UiPath® services and other shared suite capabilities. Since there is no data disk attached to these nodes, they cannot host the components that require disk storage.

Agent-Knoten erzwingen keine Beschränkung für die Anzahl der Knoten, die zu einem bestimmten Zeitpunkt verfügbar sein müssen. Solange der resultierende Cluster über genügend Kapazität verfügt, um alle Pods der verlorenen Knoten zu hosten, funktioniert der Cluster wie erwartet ohne Unterbrechung.

Spezialisierte Agent-Knoten

These nodes are the special agent nodes dedicated to special tasks, such as the Task Mining node for analysis, Automation Suite Robots node for robots execution, and the GPU node for the Document Understanding model. You cannot host other UiPath® services on these nodes.

Load balancer

Der Lastausgleich, der außerhalb der Automation Suite installiert wird, fungiert als Einstiegspunkt für den Zugriff auf Anwendungen, die im Automation Suite-Cluster gehostet werden. Der Lastausgleich ist erforderlich, um die Fehlertoleranz der Knoten sicherzustellen. Alle Serverknoten müssen auf dem Lastausgleich konfiguriert werden, aber Agent-Knoten können auch optional konfiguriert werden. Spezialisierte Agent-Knoten sind jedoch nicht erforderlich.

Wenn Roboter versuchen, auf den Orchestrator zuzugreifen, trifft der Aufruf auf den Lastausgleich und wird dann einem der verfügbaren Knoten übergeben. Jeder Knoten hostet auch die Netzwerkkomponente namens Istio, ein Service Mesh, das auch wie ein Lastausgleich fungiert. Wenn der Aufruf von Istio empfangen wird, das auf dem Knoten ausgeführt wird, versucht es, die Orchestrator-Instanz auf dem gesamten Cluster zu lokalisieren. Sobald sie gefunden wurde, wird der Aufruf an diese Instanz umgeleitet.

Design Ihrer Bereitstellung

Mehrere kleinere Maschinen oder wenige größere Maschinen?

Es liegt ganz bei Ihnen, ob Sie sich für mehrere kleinere Maschinen oder wenige größere Maschinen entscheiden, wobei beide Optionen ihre Vor- und Nachteile haben. Eine größere Anzahl kleinerer Maschinen bietet eine bessere Resilienz gegenüber Knotenfehlern als eine kleinere Anzahl größerer Maschinen. Doch sie ist auch mit einem größeren Verwaltungsaufwand verbunden.

Wenn Ihr Automation Suite-Cluster beispielsweise 96 vCPU erfordert, können Sie sich für eine der folgenden Optionen entscheiden:

• Option 1: 6 Maschinen mit jeweils 16 vCPU.

  • Auswirkungen: Wenn eine Maschine ausfällt, wird die Kapazität des Clusters nur um 16 vCPU reduziert, sodass sich dies nur auf Dienste auswirkt, wenn der resultierende Cluster nicht über die erforderliche Kapazität zum Hosten aller Pods verfügt. Die Verwaltung von 6 Maschinen ist jedoch mit einem größeren Aufwand verbunden.

• Option 2: 3 Maschinen mit jeweils 32 vCPU

  • Auswirkungen: Wenn eine Maschine ausfällt, wird die Kapazität des Clusters um 32 vCPU reduziert, was große Auswirkungen auf die Automation Suite hat. Die Verwaltung von 3 Maschinen ist jedoch mit einem geringeren Aufwand verbunden.

Letztendlich hängt das Bereitstellungsdesign vom Ziel ab. Wenn das Ziel eine bessere Fehlertoleranz ist, sind mehrere kleinere Maschinen die richtige Wahl. Wenn jedoch ein geringerer Verwaltungsaufwand gewünscht wird, sollte eine kleine Anzahl größerer Maschinen gewählt werden.

Nur Serverknoten anstelle von Agent-Knoten?

Ob Sie sich ausschließlich für Serverknoten anstelle von Agent-Knoten entscheiden, hängt von Ihrem RTO oder RPO ab.

Angenommen, Ihre Automation Suite erfordert 80 vCPU. Dies können Sie folgendermaßen erreichen:

• Option 1: 5 Servermaschinen mit jeweils 16 vCPU. Hier können höchstens 2 Serverknoten ausfallen.

  • Empfohlen, wenn das Ziel hohe Resilienz gegenüber Datenverlusten ist. Auch wenn 2 Serverknoten ausfallen, sind die Daten intakt und können aus den verbleibenden Replikaten wiederhergestellt werden.

• Option 2: 3 Serverknoten und 2 Agent-Knoten mit jeweils 16 vCPU. Hier können 1 Serverknoten und beide Agent-Knoten ausfallen, also insgesamt 3 Maschinen.

  • Empfohlen, wenn das Ziel die Resilienz der Knotenverfügbarkeit ist. Auch ohne 3 Maschinen ist der Cluster mit begrenzter Kapazität weiterhin verfügbar. Sobald die Knoten wieder funktionieren, wird der gesamte Cluster wiederhergestellt. Dieses Setup ist jedoch anfälliger für Datenverluste, da der Speicher mit den Serverknoten verbunden ist. Wenn 2 Serverknoten vollständig ausfallen, kann es schwierig sein, die Daten wiederherzustellen, ohne sie aus dem Backup abzurufen.