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-Knoten werden manchmal als Worker-Knoten bezeichnet. Der Zweck dieser Knoten ist das Hosten von UiPath®-Diensten und anderen gemeinsamen Suite-Funktionen. Da kein Datenträger mit diesen Knoten verbunden ist, können sie die Komponenten nicht hosten, die Datenträgerspeicher erfordern.

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

Das sind die speziellen Agent-Knoten, die für spezielle Aufgaben bestimmt sind, z. B. der Task Mining-Knoten für die Analyse, der Automation Suite Robots-Knoten für die Roboterausführung und der GPU-Knoten für das Document Understanding-Modell. Sie können auf diesen Knoten keine anderen UiPath®-Dienste hosten.

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.