Home
Holen Sie sich die Community Edition – KOSTENLOS
ANMELDEN
Lesen und beachten Sie die Automation Anywhere-Dokumentation

Automation Anywhere Automation 360

Inhalt schließen

Inhalte

Inhalt öffnen

Voraussetzungen für den Lastenausgleich

  • Aktualisiert: 6/10/2021
    • Automation 360 v.x
    • Installieren
    • RPA Workspace

Voraussetzungen für den Lastenausgleich

Zeigen Sie die Voraussetzungen für den Lastenausgleich für eine Automation Anywhere-Installation an. Dies umfasst die Mindestanforderungen für den Lastenausgleich sowie die Anforderungen für den Lastenausgleich auf TCP- und HTTPS-Ebene.

Mindestvoraussetzungen für den Lastenausgleich

Für optimale Ergebnisse mit Automation Anywhere muss der Lastenausgleich:
  • das WebSocket-Protokoll (RFC 6455) unterstützen (erforderlich),
  • den Host nach dem Round-Robin-Prinzip auswählen und darf nicht für die Verwendung persistenter Sitzungen konfiguriert sein (bevorzugt)
  • eine angemessene TLS-Sicherheitsschicht verwenden (bevorzugt):
    • Lastenausgleich für TCP (Layer 4)
    • HTTPS-(Layer 7)-Load-Balancing

      Stellen Sie für einen Nginx-Load-Balancer die HTTPS-Terminierung an Knoten ein, indem Sie http://Backend durch https://Backend ersetzen.

  • ein Leerlaufzeitlimit von 120 Sekunden aufweisen (bevorzugt).

    Der Wert für das Zeitlimit hängt von der Verarbeitungszeit verschiedener Aktionen im Control Room ab, z. B. der Zeit, die zum Ein- und Auschecken von Bots, Importieren von Bots und Herunterladen von Bot-Abhängigkeiten benötigt wird.

    Wenn das Leerlaufzeitlimit kleiner als die Verarbeitungszeit im Control Room ist, kann eine Zeitüberschreitung für die Browser-Anforderung auftreten. Wenn beispielsweise das konfigurierte Leerlaufzeitlimit nicht ausreicht, um eine Bot-Eincheckaktion abzuschließen, müssen Sie Ihren Browser aktualisieren, um zu überprüfen, ob die Bot-Eincheckaktion erfolgreich war.

Parameter für die Zustandsüberprüfung des Lastenausgleichs

Die Parameter für die Zustandsüberprüfung des Lastenausgleich hängen von verschiedenen Faktoren ab, wie dem verwendeten Lastenausgleichstyp, der Netzwerklatenz und der Reaktionsfähigkeit der Nutzeroberfläche innerhalb und außerhalb des Lastenausgleichs.

TCP-(Layer 4)-Load-Balancing

Wenn TCP auf Layer 4 mit dem Lastenausgleich angewendet wird, wird das Zertifikat entsprechend der Lastenausgleichs-URL auf jedem Control Room installiert.

Lastenausgleich für TCP auf Layer 4, Zertifikat im Control Room.

In der Abbildung sind die Control Room-Komponenten orange und andere Komponenten blau dargestellt.

Vorteile
End-to-End-Verschlüsselung ohne Möglichkeiten zum Abfangen des Lastenausgleichs
Nur ein Zertifikat erforderlich
Nachteile
Wird eine Auditprotokollierung benötigt, kann der Lastenausgleich keine Anforderungen von Clients berichten
Keine Nutzung von TLS-Hardware-Offloading, auch dann nicht, wenn der Lastenausgleich dies unterstützt

Lastenausgleich für HTTPS (Layer 7)

Wenn HTTPS auf Layer 7 mit dem Lastenausgleich angewendet wird, wird das Zertifikat entsprechend der Lastenausgleichs-URL über den Lastenausgleich angewendet. Control Room vertraut den vom Lastenausgleich erhaltenen Zertifikaten.

Lastenausgleich für HTTPS, Layer 7, Zertifikat über den Lastenausgleich

Vorteile
Ermöglicht die Protokollierung von Anforderungen (sofern vom Lastenausgleich unterstützt)
Reduziert den Aufwand für TLS-Handshaking dank Hardware-Offloading (sofern vom Lastenausgleich unterstützt)
Nachteile
Zertifikate müssen sowohl für den Lastenausgleich als auch für die Control Room-Knoten verwaltet werden
Mögliches Abfangen der Daten auf Lastenausgleich-Hardwareebene, da die TLS-Sitzung keine End-to-End-Verschlüsselung aufweist
Feedback senden