Häufig gestellte Fragen zu Automation Anywhere Enterprise Knowledge On-Premises

Siehe diese FAQ für häufig gestellte Fragen und ausführliche Antworten bezüglich der On-Premises-Bereitstellung der Automation Anywhere Enterprise Knowledge-Plattform, von der Definition und Architektur von On-Premises bis hin zu Infrastrukturanforderungen, Bereitstellungsprozessen, Sicherheitsaspekten und mehr.

Bereitstellung

Wird die Enterprise Knowledge On-Premises-Installation die Installation auf AWS, GCP, Azure oder Bare Metal und virtuellen Maschinen wie VMWare unterstützen?

Ja, wir haben die notwendigen Spezifikationen für sowohl Produktions- als auch Entwicklungsumgebungen auf diesen Plattformen.

Muss ich Automation 360 Cloud trotzdem verwenden, obwohl ich lieber Automation Anywhere Enterprise Knowledge On-Premises benutze? Oder kann ich meine nativeAutomation 360 Cloud entsprechende Umgebung in vollständig geschlossenen Premises aufbauen?

Es gibt keine On-Premises-Bereitstellung der Automation 360-Cloud mit Kubernetes, Pod-Diensten und API-Diensten. Enterprise Knowledge kann entweder On-Premises oder in der Cloud als SaaS bereitgestellt werden. Das Produkt selbst ist das gleiche und kann sowohl in Verbindung mit einer Automation 360 Cloud-Umgebung als auch mit einer Automation 360 On-Premises-Umgebung verwendet werden.

Wer stellt die On-Premises-Umgebung bereit?

Die Erstinstallation erfolgt in Zusammenarbeit zwischen den Enterprise Knowledge-SMEs und Ihnen. Sie müssen SSH- und Netzwerkzugriff auf die vorgesehenen Bereitstellungsmaschine(n) bereitstellen. Wenn kein direkter Zugriff gewährt werden kann, müssen Sie Fachpersonal mit den erforderlichen Zugriffsrechten beauftragen. Die Enterprise Knowledge SMEs können dieses Fachpersonal dann aus der Ferne über Bildschirmfreigabe anleiten. Sie sind verantwortlich für die Bereitstellung der notwendigen Geräte. Die anfängliche Installation und nachfolgende Updates werden durch eine Reihe von Sitzungen abgeschlossen, die das Herunterladen, Bereitstellen und Konfigurieren der Software umfassen. Das Installationsskript wird CI/CD-Verbindungen einbinden, um Assets abzurufen, die Installation durchzuführen, das System zu konfigurieren, die Komponenten bereitzustellen und zukünftige Updates zu ermöglichen. Bitte beachten Sie, dass Sie die Installation und Updates nicht direkt verwalten können.

Haben Sie eine ungefähre Vorstellung davon, wie lange es dauert, bis ein funktionierendes System bereitgestellt werden kann?

Die Bereitstellung kann je nach Ihrer spezifischen Umgebung und Ihren Anforderungen zwischen etwa vier Stunden und zwei Wochen variieren. Gelegentlich stoßen wir auf Hindernisse wie SSL-Zertifikate oder eingeschränkte Netzwerkzugriffsrechte, die uns daran hindern, Änderungen vorzunehmen. Im Idealfall jedoch etwa vier Stunden für die Fertigstellung und das Testen.

Welcher Knoten akzeptiert die SSL-Zertifikate für eingehende Verbindungen?

Die meisten Bereitstellungen werden SSL erfordern, aber es könnte während der anfänglichen Bereitstellung nicht implementiert werden. Der Server kann ohne SSL bereitgestellt und später konfiguriert werden. Die spezifischen Bereitstellungsports, die im Architekturdiagramm dargestellt sind, zeigen an, wo SSL-Zertifikate angewendet werden müssen.

Werden Skripte zur Installation verwendet?

Ja, Terraform-Skripte werden derzeit verwendet, um alle Komponenten zu installieren. Diese Skripte vereinfachen den Installationsprozess und gewährleisten konsistente, reproduzierbare Ergebnisse.

Gibt es Anforderungen an die gemeinsame Speicherung?

Nein, gemeinsamer Dateispeicher ist nicht erforderlich. Die Docker-Container und andere Dienste verwenden die lokale Scratch-Disk und die PostgreSQL-Datenbank für alle Speicheranforderungen.

Ist SSD-Disk erforderlich?

Ja, ein SSD (Solid State Drive) ist eine Voraussetzung. Datenbanken, insbesondere Vektordatenbanken aufgrund ihrer Größe, reagieren sehr empfindlich auf Festplattenlatenz. Jegliche Verzögerung beim Festplattenzugriff wird die Leistung negativ beeinflussen.

Ist NAS möglich?
Nein, Network Attached Storage (NAS) ist nicht geeignet. NAS umfasst gemeinsam genutzte Festplatten, die über ein Netzwerk zugegriffen werden. Selbst wenn sie über iSCSI partitioniert und bereitgestellt werden, sind herkömmliche Festplatten aufgrund ihrer inhärenten Netzwerklatenz und Rotationslatenz (in der Regel 2,5- bis 5-mal langsamerer Zugriff als SSD) für die Leistungsanforderungen ungeeignet.
Gibt es Einschränkungen bei den Funktionen für On-Premises?
Für die On-Premises-Bereitstellung gibt es keine grundlegenden Funktionsbeschränkungen. Funktionen wie Crawling und Single-Sign-On-Anmeldung (SSO) werden vollständig unterstützt. Der Zugriff auf interne Ressourcen kann das Whitelisting bestimmter IP-Adressen oder Domains innerhalb Ihres Netzwerks erfordern. Das Aktivieren des Dokumenteditors und das Unterstützungsprotokollierung sind optionale Konfigurationen. Die Funktionalität „Aktionen“ kann auch selektiv aktiviert oder deaktiviert werden. Es ist zu beachten, dass stark eingeschränkte, isolierte Umgebungen ohne Internetzugang über die lokalen Netzwerkfunktionen hinausgehende Einschränkungen in ihrer Nutzbarkeit aufweisen können.
Es gibt mehrere optionale Elemente. Reduziert der Nichtgebrauch den Gerätebedarf?
Nein, die Einbeziehung oder der Ausschluss optionaler Funktionen hat keinen Einfluss auf die erforderliche Anzahl von Geräten.
Das Sentry-Signalisierungsmodul ist als optional gekennzeichnet, was macht es?
Das Sentry-Signalisierungsmodul liefert, sofern aktiviert, detaillierte Debugging-Informationen über Protokollierung, die für Supportzwecke von großem Wert sind. Bei Verwendung wird es in der Regel zusammen mit anderen Komponenten eingesetzt.
Der Dokumenteditor ist optional. Welche Funktionen bietet er und ist er integriert?
Ja, der Dokumenteneditor ist eine optionale Funktion und in die Konsole integriert. Es bietet WebSocket-Funktionalität für die Echtzeit-Dokumentbearbeitung. Der Websocket-Server unterstützt diese Funktion und kann für zukünftige Websocket-basierte Aktionen genutzt werden. Der Editor wird zwar vielleicht nicht häufig verwendet, erlaubt es einem Nutzer mit entsprechenden Rechten jedoch, Dokumente direkt im System zu verfassen und zu bearbeiten, um sie der Wissensdatenbank (KB) hinzuzufügen. Wenn die primäre Wissensquelle hochgeladene oder gecrawlte Daten sind, ist der Dokumenteneditor weitgehend überflüssig. Der Docker-Container, der den Editor hostet, kann mit anderen Komponenten zusammengelegt werden. Eine bewährte Methode für das Hinzufügen von Wissen besteht jedoch darin, die Dokumentdatei an einem standardmäßigen Speicherort für gemeinsam genutzte Inhalte abzulegen und sie dann von diesem bekannten Ort aus entweder durch Web-Crawling oder einen automatisierten Prozess in die Wissensdatenbank hochzuladen.
Werden LLMs bereitgestellt?
Nein, Large Language Models (LLMs) werden mit der On-Premises-Bereitstellung nicht direkt bereitgestellt. Allerdings sind integrierte Verbindungen enthalten, die die Nutzung von Credits ermöglichen (ähnlich dem Cloud-Angebot). In den meisten On-Premises-Bereitstellungen wird erwartet, dass Sie benutzerdefinierte LLM-Verbindungen verwenden und Ihre eigenen Bring Your Own Key (BYOK)-Vereinbarungen nutzen.
Wie wirkt sich die On-Premises-Bereitstellung auf die Nutzung von Credit oder BYOK GenAI-Verbrauch aus?
Sie haben die Möglichkeit, integrierte Credits für den Zugriff auf LLMs zu verwenden. Für eine kosteneffiziente und skalierbare Nutzung von LLMs und um Ihre bestehenden Beziehungen zu Hyperscalern oder anderen GenAI-LLM-Anbietern zu nutzen, werden die meisten jedoch wahrscheinlich ein Bring Your Own Key (BYOK)-Modell für das Hosting von LLMs einsetzen. In solchen Fällen wird es notwendig sein, ausgehende Verbindungen zu den jeweiligen LLM-Dienstanbietern innerhalb Ihres Netzwerks auf die Whitelist zu setzen.
Wie wird das Skalieren über die große vollständig verteilte Bereitstellung hinaus gehandhabt?
Vollständig verteilte und skalierte Bereitstellungen gelten derzeit nur für das Cloud-Angebot, nicht für On-Premises. Während eine größere Cloud-Bereitstellung das Skalieren von Pod-Servern und das Iterieren von Docker-Containern beinhalten würde, gelten die folgenden Überlegungen für On-Premises:
  • In den meisten Fällen ist eine On-Premises-Bereitstellung für Sie ein einzelnes Gerät.
  • Die detaillierten architektonischen Komponenten dienen hauptsächlich dem Verständnis der Gesamtstruktur, und die meisten werden nach der anfänglichen Bereitstellung nicht direkt verwendet.
  • Das Skalieren über das große vollständig verteilte Niveau hinaus wird für On-Premises-Bereitstellungen derzeit nicht unterstützt.
  • Hochverfügbarkeit (HA) und Notfallwiederherstellung (DR) werden für On-Premises nicht standardmäßig unterstützt.

Architektur

Wie sieht die Architektur für On-Premises aus?
Die On-Premises-Architektur basiert auf Dockers und einer Datenbank. Sie verwendet keine vorgefertigten statischen Docker-Images, sondern nutzt Docker und docker-compose für die Orchestrierung.
Welche Datenbank wird verwendet?

Die verwendete Datenbank ist PostgreSQL, die so modifiziert wurde, dass sie als Vektorindexspeicher fungiert, bekannt als Supabase. Diese angepasste Datenbank wird gemäß den angegebenen Anforderungen unter Verwendung des bereitgestellten Installationsskripts erstellt.

Ist die Datenbank ein eigenständiger Server, oder kann sie RDS, Azure oder anderweitig cloudbereitgestellt sein?

Die Datenbank muss ein eigenständiger Server sein und muss als Virtuelle Maschine (VM) initiiert werden. Es kann nicht durch verwaltete Cloud-Datenbankdienste wie AWS RDS Aurora, Azure Database for PostgreSQL oder ähnliche cloudbereitgestellte Angebote ersetzt werden. Der Datenbankserver ist eine Kernkomponente der gesamten Bereitstellung und erfordert eine praktische Konfiguration, um ein voll funktionsfähiger Supabase-Knoten zu werden.

Wie können wir Postgres in Supabase umwandeln? Wir haben nichts von Supabase gehört

Ja, die Datenbank muss sich auf einem eigenen dedizierten Server innerhalb der Architektur befinden. Supabase kann als PostgreSQL mit erweiterten Fähigkeiten verstanden werden. Daher können Sie eine vorhandene verwaltete PostgreSQL-Instanz oder eine andere Art von Datenbank nicht direkt in Supabase konvertieren. Jedoch ist die Migration von Daten von einem zum anderen möglich. Die Supabase-Instanz erfordert vollständige praktische Verwaltung.

Sind von Hyperscalern bereitgestellte PostgreSQL-Datenbanken ein guter Ausgangspunkt?

Nein. Die Datenbank erfordert spezifische Änderungen, die direkten Zugriff und Kontrolle notwendig machen. Verwaltete Dienste wie AWS RDS bieten eine abstraktere, aufgeteilte Nutzung der PostgreSQL-Bereitstellung und bieten nicht das Maß an Anpassung, das erforderlich ist, um es in Supabase zu transformieren. Supabase muss auf einer VM bereitgestellt werden, egal ob auf einer Hyperscaler-Plattform gehostet oder auf lokaler Infrastruktur.

Welche Access-Ports werden verwendet?

Die folgenden Ports müssen für Ihre Nutzer und Automatisierungen, die auf den Enterprise Knowledge-Server zugreifen, auf die Whitelist gesetzt werden: 80 (HTTP), 443 (HTTPS), 8000 (HTTP/HTTPS web sockets), 8443 (HTTP/HTTPS web sockets) und 1234 (web sockets). Es ist äußerst wichtig, dass keine Firewalls auf Anwendungsebene (Layer 7) den Zugriff für Nutzer oder Bots in Ihrem Netzwerk blockieren. Bitte beachten Sie, dass bei Bereitstellungen auf einem einzelnen Gerät eine vollständige Kommunikation zwischen der Supabase-VM und den Docker-Containern gewährleistet sein muss. Ebenso müssen in größeren, verteilten Bereitstellungen alle Geräte über uneingeschränkte interne Kommunikationsmöglichkeiten verfügen.

Wird SSL unterstützt?

Ja, SSL (Secure Sockets Layer) wird unterstützt. Dies erfordert ein SSL-Zertifikat, das mit dem Host oder Domainnamen verknüpft ist. Hier sind die allgemeinen Schritte für die SSL-Konfiguration in Ihrer Umgebung:

  • Fügen Sie einen Eintrag in Ihrem DNS hinzu, der den Fully Qualified Domain Name (FQDN) Hostnamen auf die zugewiesene IP-Adresse auflöst.
  • Sie können ein temporäres, selbstsigniertes SSL-Zertifikat mit Tools wie certbot für erste Tests erstellen. Für Produktionsumgebungen empfehlen wir jedoch nachdrücklich, ein gültiges SSL-Zertifikat und einen privaten Schlüssel für den FQDN-Hostnamen bereitzustellen.
  • Legen Sie das SSL-Zertifikat und die Schlüssel-Dateien auf diesem Gerät im Ordner /nginx-proxy/ssl/ ab.
  • Sobald diese Schritte abgeschlossen sind, benachrichtigen Sie das Enterprise Knowledge SME-Team, damit es die notwendigen Konfigurationen auf dem Nginx-Proxy abschließen kann, um auf die richtigen SSL-Dateien zu verweisen.
  • Wenn der Front-End-Docker-Container getrennt von der Supabase-VM bereitgestellt wird, sollte ein separater Satz von Zertifikat- und Schlüsseldateien für das Front-End erstellt werden.
Welche Ports werden innerhalb der Lösungskomponenten verwendet?
Tabelle 1.
Zweck Pfad Parameter Intern* Extern HTTP HTTPS WSS/WS
Frontend /app FRONTEND_SUFFIX 3000 X X
Nginx 80, 443 X X
Backend /api BACKEND_SUFFIX 8001 X x
Automator /automator AUTOMATOR_SUFFIX 8002 x X
Redis 6379 x X
RabbitMQ 5672, 15672 x x
Document Editor /ws WEBSOCKET_SUFFIX 1234 1234 x x x
Supabase Kong API Gateway /supabase SUPABASE_SUFFIX 8000, 8443 8000**, 8443** x x
Supabase Postgres 6543 x x
PostgreSQL (Automator) 5433 x x
Redis (automator) 6380 x x
Ollama 11434 x x ****

* Alle internen Geräte müssen frei miteinander kommunizieren können

** nur Admin

*** Wir empfehlen die Verwendung von SSL (https)-Verbindungen, aber wir können http-Verbindungen für PoCs unterstützen.

**** Gilt nur, wenn Ollama lokal bereitgestellt wird

Welche Ports verwenden Clients (Mensch, Bots, API)?

Clients verwenden nur 80/443. Andere Ports dienen der internen Kommunikation, Verwaltung und Bereitstellung. Nginx leitet den gesamten eingehenden und ausgehenden Datenverkehr weiter.

Welche erlaubten Methoden müssen innerhalb meines Netzwerks aktiviert werden?
Einige Netzwerke aktivieren die APP-Filterung mit Schicht 7 App-Layer über Firewalls, App-Beschleuniger und einige Switches. Es ist wichtig, die folgenden Methoden für die Lösung innerhalb Ihres Netzwerks zuzulassen:
  • GET
  • POST
  • PUT
  • DELETE
  • OPTIONEN
Wenn das System SSO, Automator oder Crawling verwendet, von welchem Knoten wird der Call initiiert?
SSO, wie der Clientzugriff, ist ein Front-End-Dienst. Mit SSO wird dieser Vorgang mit dem Authentifizierungsdienst fortgesetzt. Wenn die Authentifizierungsanforderung erfolgreich ist, wird über einen Webhook eine Verbindung hergestellt, die Authentifizierung abgeschlossen und ein Token für die weitere Verwendung generiert.
Das Crawling ist ein Back-End-Dienst, und der gesamte eingehende/ausgehende Datenverkehr wird vom Back-End-End-Server abgewickelt.
Automator ist ein Back-End-Dienst, und der gesamte eingehende/ausgehende Datenverkehr wird vom Front-End-Server abgewickelt.
Kann Enterprise Knowledge Forward Proxies verwenden?

Ja. Nginx leitet den gesamten eingehenden und ausgehenden Datenverkehr weiter. Es ist Ihr Netzwerk, also konfigurieren Sie es so, dass der Datenverkehr von Ende zu Ende zugelassen und erlaubt wird, damit dies funktioniert.

Was ist mit SSH-Management?
Für die Installation, Aktualisierungen und erforderliche Fehlerbehebung benötigen unser Fachpersonal SSH-Zugriff auf die Bereitstellungsbox (Hauptdatenbankrechner).
So wird der Zugang ermöglicht:
  • Sie müssen die erforderlichen SSH-Schlüssel und den Netzwerkzugriff für unser spezifisches Fachpersonal auf den Basisrechnern konfigurieren.
  • Wenn Ihr Team keinen direkten Zugriff gewähren kann, benötigen wir zugewiesenes Fachpersonal von Ihrem Team. Dieses Fachpersonal muss den notwendigen Zugriff haben. Es muss verfügbar sein, wenn es für die Installation, Updates und Fehlerbehebung benötigt wird.
  • Unsere Enterprise Knowledge SME-Personal und Ihr Fachpersonal werden eng zusammenarbeiten. Sie werden die erforderlichen Schritte koordinieren. Diese Koordination können Sie durch gemeinsamen IT-Zugriff, beispielsweise durch eine Besprechung mit geteiltem Bildschirm, erreichen.
  • Koordinierte Techniksitzungen können zeitaufwändig sein. Das Herunterladen und Ausführen längerer Bereitstellungsskripte kann einige Zeit in Anspruch nehmen. Unterstützung von unseren Enterprise Knowledge SMEs wird wahrscheinlich mehrere Sitzungen umfassen. Daher sollte das zugewiesene Personal darauf vorbereitet sein, bei Bedarf mit der Arbeit zu beginnen, sie zu unterbrechen, fortzusetzen oder einzustellen.
Werden Daten im Ruhezustand und während der Übertragung verschlüsselt?
Ja, SSL und TLS 1.2 werden für Daten während der Übertragung verwendet.
Ja, AES 256 wird für Daten im Ruhezustand verwendet. Darüber hinaus ist es möglich, im Rahmen des Skripts für die Ersteinrichtung einen Verschlüsselungsschlüssel für OnPrem-Installationen zu generieren und festzulegen.
Wie kann SSO angewendet werden?
SSO wird über Protokolle wie Okta, Azure AD und SAML 2.0 unterstützt.
Was gewährleistet Hochverfügbarkeit (High Availability oder kurz HA)?
Ein wichtiger Aspekt bei OnPrem-Bereitstellungen ist, dass Ihr IT-Team für die Verwaltung von Netzwerkausfällen und die Gewährleistung einer Hochverfügbarkeit (HA) verantwortlich ist. Die Installation von Enterprise Knowledge, insbesondere bei Konfigurationen mit mehr als einem Server, schließt keine integrierte Fehlertoleranz ein. Daher ist für die Entwicklung einer geeigneten Architektur, die skalierbar ist und Ihre HA-Anforderungen erfüllt, eine Dimensionierung unerlässlich.
Was muss gesichert werden?
Alles – die Konfiguration und die Parameter – wird in der Datenbank gespeichert. Ein geplanter Sicherungsvorgang der Datenbank wird sowohl Sicherungs- als auch Wiederherstellungsoperationen durchführen.
Werden Docker-Images derzeit verwendet?
Docker-Images werden derzeit nicht direkt verwendet. Allerdings können Docker-Images zusammengestellt werden, da die docker-compose Dateien verfügbar sind.
Was ermöglicht die automatische Skalierung von Docker?
Docker-Container werden für Bereitstellungen verwendet und erfordern Docker v27.1.1 oder höher. Die Dimensionierung in Zusammenarbeit mit dem KMU-Team wird ergeben, ob die Lösung eine automatische Skalierung für die API und die Worker sowie eine Verteilung der Server im Hinblick auf eine vollständig verteilte Bereitstellung erfordert.
Brauchen Kunden eine Docker-Registry?
Nein.