Go-Global-Einsätze
Groß angelegte GO-Global-Implementierungen gehen oft weit über Farm-Hosts und Farm-Manager hinaus. In Unternehmensumgebungen werden sie in der Regel zusammen mit zahlreichen unterstützenden Systemen betrieben, die die Leistung, Zuverlässigkeit und Sicherheit verbessern sollen. Diese Systeme - einschließlich Firewalls, Load Balancers, Web Application Firewalls (WAFs), Reverse Proxies und Überwachungstools - stellen sicher, dass GO-Global-Anwendungen zugänglich, stabil und konform mit den Unternehmensstandards bleiben.
Dieser Artikel enthält eine detaillierte Anleitung zur Konfiguration von GO-Global für den effektiven Einsatz in komplexen IT-Infrastrukturen, die solche Komponenten enthalten. Es wird erläutert, wie GO-Global mit den einzelnen Systemen interagiert, es werden bewährte Konfigurationsverfahren vorgestellt und es wird auf wichtige Überlegungen für Administratoren hingewiesen, die große oder Cloud-basierte Implementierungen verwalten.
Perimeter-Firewall
Wenn eine GO-Global-Installation über das Internet zugänglich ist, ist eine Perimeter-Firewall in der Regel die erste Verteidigungslinie gegen Eindringlinge. Perimeter-Firewalls sind in der Regel so konfiguriert, dass sie eingehende Verbindungen über den TCP-Port 443 zulassen, der der Standardport für sicheren HTTPS/TLS-Verkehr ist.
Da Port 443 der Standardport für sicheren Datenverkehr ist und dieser Port bei den meisten Unternehmensfirewalls (Client-Firewalls) offen ist, werden GO-Global-Clients, die sich über das Internet verbinden, in der Regel so konfiguriert, dass sie sich mit Port 443 statt mit GO-Globals Standardport 491 verbinden. Dies geschieht entweder durch Hinzufügen des Ports in der URL (z. B. &port=443) oder durch Angabe des Ports auf der Seite logon.html von GO-Global.
Web-Anwendungs-Firewall (WAF)
Eine Web Application Firewall (WAF) analysiert eingehende HTTP-Anfragen, um bösartige Anfragen zu erkennen und zu blockieren. WAFs können auch den Datenverkehr auf der Grundlage von Informationen in HTTP-Anfragen an verschiedene Backend-Server weiterleiten, aber das ist nicht ihre Hauptfunktion. Ihre Hauptfunktion besteht darin, Sicherheit zu bieten und vor Angriffen wie verteilten Denial-of-Service-Angriffen (DDoS) zu schützen.
Beispiele für WAFs sind Cloudflare WAF, AWS WAF (Amazon Web Services), Azure Web Application Firewall, F5 Advanced WAF, Imperva WAF, Akamai Kona Site Defender, Fortinet FortiWeb, Barracuda WAF und Radware WAF.
Um den HTTPS-Verkehr zu analysieren, müssen WAFs TLS beenden, damit sie die Anfragen entschlüsseln können. Wenn TLS von einer WAF beendet wird, muss der tls-Parameter von GO-Global zur URL des Clients hinzugefügt oder in der Seite logon.html von GO-Global angegeben werden.
Eine weitere Überlegung für GO-Global-Datenverkehr ist, dass WAFs das proprietäre RXP-Protokoll von GO-Global nicht analysieren können. Wenn also die Kommunikation zwischen einem GO-Global-Client und einem Host eine WAF durchläuft, muss sie entweder in HTTP-Anfragen verpackt werden, indem GO-Global für die Verwendung eines Websockets konfiguriert wird, oder die Datenanalysefunktionen der WAF müssen für den GO-Global-Datenverkehr deaktiviert werden.
Alle GO-Global-Clients der Version 6.3.3 und höher unterstützen WebSockets. In den GO-Global-Versionen 6.3.2 und früher unterstützt jedoch nur die GO-Global Web App WebSockets. AppController, der native Client von GO-Global, unterstützt in Version 6.3.2 und früher keine WebSockets.
Wenn AppController Version 6.3.2 oder früher mit einer WAF verwendet wird, muss die Umgebung so konfiguriert werden, dass die WAF den Verkehr von AppController nicht überprüft. Dies kann z. B. durch die Bereitstellung eines anderen Endpunkts (öffentliche Adresse) für AppController-Verbindungen, die die WAF nicht verwenden, oder durch die Konfiguration von AppController für eine Verbindung an einem anderen Port und die Konfiguration der WAF für die Weiterleitung des Datenverkehrs an diesem Port ohne Inspektion geschehen.
Umgekehrter Proxy
Wie WAFs analysieren Reverse-Proxys eingehende HTTP-Anfragen. Reverse-Proxys haben einige Sicherheitsfunktionen, aber im Gegensatz zu WAFs ist die Hauptfunktion von Reverse-Proxys die Verwaltung des Datenverkehrs und nicht die Sicherheit. Reverse-Proxys werden zum Beispiel häufig eingesetzt, wenn mehrere Webanwendungen und -dienste von demselben öffentlichen Endpunkt aus bereitgestellt werden. Sie leiten eingehende Anfragen für verschiedene Anwendungen an ihre jeweiligen Anwendungsserver weiter. Sie können auch als Load Balancer für GO-Global Farm Hosts eingesetzt werden.
Beispiele für Reverse-Proxys sind Nginx, Apache HTTP Server, HAProxy, Traefik und Cloudflare. Der AWS Application Load Balancer und das Azure Application Gateway haben verschiedene Funktionen, von denen eine die Funktion eines Reverse-Proxys beinhaltet.
Wie WAFs müssen Reverse-Proxys TLS beenden, damit sie eingehende HTTP-Anfragen analysieren können. Wie bei WAFs muss auch bei der Beendigung von TLS durch einen Reverse-Proxy der tls-Parameter von GO-Global zur URL des Clients hinzugefügt oder in der Seite logon.html von GO-Global angegeben werden.
Wie WAFs können auch Reverse Proxies das proprietäre RapidX-Protokoll (RXP) von GO-Global nicht analysieren. Wenn die Kommunikation zwischen einem GO-Global-Client und einem Host über einen Reverse-Proxy läuft, muss sie daher - wie bei einer WAF - entweder in HTTP-Anfragen verpackt werden, indem GO-Global für die Verwendung eines WebSockets konfiguriert wird, oder die Datenanalysefunktionen des Reverse-Proxys müssen für den GO-Global-Datenverkehr deaktiviert werden.
Und wie bei einer WAF muss, wenn AppController Version 6.3.2 oder früher mit einem Reverse-Proxy verwendet wird, die Umgebung so konfiguriert werden, dass die WAF den Verkehr von AppController nicht überprüft. Dies kann beispielsweise durch die Bereitstellung eines anderen Endpunkts (öffentliche Adresse) für AppController-Verbindungen geschehen, die den Reverse-Proxy nicht verwenden, oder durch die Konfiguration von AppController für eine Verbindung an einem anderen Port und die Konfiguration des Reverse-Proxys, um den Datenverkehr an diesem Port weiterzuleiten, ohne ihn zu prüfen.
Web-Server
GO-Global Hosts verfügen über einen integrierten Webserver, der die GO-Global Web App und die zugehörigen HTML- und JavaScript-Dateien hosten kann. Wenn der integrierte Webserver von GO-Global verwendet wird, werden HTTP-Anfragen für GO-Globals Webdateien an GO-Global Farm Hosts im internen Netzwerk weitergeleitet.
Bei Internet-Implementierungen bietet es jedoch Sicherheitsvorteile, die Webdateien von GO-Global auf einem Webserver eines Drittanbieters zu hosten, der sich in der DMZ befindet. Beispiele für Webserver von Drittanbietern sind Apache HTTP Server, Nginx und Microsoft IIS (Internet Information Services).
Wenn ein Webserver eines Drittanbieters verwendet wird, müssen die GO-Global Web App und die zugehörigen Dateien auf dem Webserver installiert werden, entweder über das Host-Installationsprogramm oder durch Kopieren des Inhalts von GO-Globals Web-Verzeichnis auf den Webserver.
Während die meisten Webserver von Drittanbietern über Funktionen zur Verarbeitung von WebSocket-Verbindungen verfügen, werden WebSocket-Verbindungen im Allgemeinen von einem dedizierten Load Balancer oder Reverse Proxy verarbeitet. Administratoren können WAFs und Reverse Proxies so konfigurieren, dass sie die HTTP-Anfragen von GO-Global an einen Webserver und die WebSocket-Verbindungen an GO-Global Farm Hosts oder an einen Load Balancer weiterleiten.
Wenn keine WAF oder kein Reverse Proxy verwendet wird, können Administratoren alternativ einen anderen Endpunkt (Adresse oder Port) für die WebSocket-Verbindungen von GO-Global erstellen und diesen Endpunkt über die Host- und/oder Port-Parameter in der URL des Clients oder in der Seite logon.html von GO-Global angeben.
Netzwerk Load Balancer
Wenn mehr als ein Farm Host benötigt wird, ist ein Load Balancer erforderlich, um die Benutzerverbindungen zwischen den Hosts zu verteilen. Der Load Balancer kann ein Reverse Proxy oder ein Netzwerk Load Balancer sein.
In Umgebungen, in denen über einen einzigen Internet-Endpunkt auf mehrere Anwendungen zugegriffen wird, leitet die Perimeter-Firewall Verbindungen in der Regel an einen Reverse-Proxy weiter (optional über eine WAF). Der Reverse-Proxy kann die Verbindungen dann entweder direkt an die Farm-Hosts weiterleiten (um die Last auszugleichen), oder er kann die Verbindungen indirekt über einen Netzwerklastausgleich an die Hosts weiterleiten.
Alternativ kann in Umgebungen, in denen GO-Global die einzige Anwendung ist, auf die über den Internet-Endpunkt zugegriffen wird, die Perimeter-Firewall Verbindungen auf Port 443 direkt an einen Netzwerk-Load-Balancer weiterleiten. Von dort aus wählt der Load Balancer einen Farm Host aus und leitet die Verbindung an den Farm Host auf dem in der Admin Console angegebenen Port weiter.
Im Gegensatz zu Reverse Proxies untersuchen Netzwerk-Load-Balancer den Datenverkehr nicht und leiten ihn nicht nach dem Inhalt der Daten weiter. Sie leiten den Datenverkehr im Allgemeinen auf der Grundlage von Variablen wie Zielport und Quell-IP-Adresse weiter. Beispiele für Load Balancer, die auf Schicht 4 arbeiten und TCP-Verbindungen weiterleiten können (TLS wird auf GO-Global-Hosts beendet), sind HAProxy, Azure Load Balancer und AWS Network Load Balancer.
Einige Netzwerk-Load-Balancer können TLS am Load-Balancer terminieren. Wenn der Load Balancer so konfiguriert ist, dass TLS beendet wird, muss der tls-Parameter von GO-Global zur URL des Clients hinzugefügt oder in der Seite logon.html von GO-Global angegeben werden.
Wenn ein Load Balancer TLS beendet, kann er optional die Daten neu verschlüsseln, die er an Farm Hosts überträgt. Wenn die Farm-Hosts für die Verwendung des TLS-Protokolls konfiguriert sind, muss der Load Balancer so konfiguriert werden, dass er die Daten, die er an die Farm-Hosts sendet, erneut verschlüsselt. Umgekehrt, wenn der Load Balancer die Daten nicht neu verschlüsselt, muss GO-Global's Protocol auf TCP und Encryption auf None gesetzt werden.
Wenn ein Netzwerk-Load-Balancer TLS nicht beendet, leitet er die Daten an die Farm-Hosts weiter, ohne sie zu entschlüsseln und erneut zu verschlüsseln. In dieser Konfiguration muss das TLS-Protokoll auf den Farm-Hosts aktiviert sein, und der tls-Parameter darf nicht in der Client-URL oder der Seite logon.html angegeben werden.
Back-End-Firewall
Eine Backend-Firewall kann verwendet werden, um den Zugriff auf Farm Hosts auf bestimmte Front-End-Systeme zu beschränken. Wenn beispielsweise Reverse-Proxys verwendet werden, um Verbindungen zu Farm-Hosts zu leiten, kann eine Back-End-Firewall so konfiguriert werden, dass nur die Reverse-Proxys eine Verbindung zu den Farm-Hosts herstellen können. In diesem Beispiel muss die Back-End-Firewall so konfiguriert werden, dass die Reverse-Proxys eine Verbindung zu den Farm-Hosts über den in der Verwaltungskonsole unter Extras | Hostoptionen | Sicherheit | Port (standardmäßig 491) angegebenen Port herstellen können, und der Datenverkehr muss in beide Richtungen zugelassen werden.
Wenn die auf den Farm-Hosts ausgeführten Anwendungen auf das Internet zugreifen müssen, muss die Back-End-Firewall so konfiguriert werden, dass sie diesen Zugriff zulässt.
GO-Global Farm Hosts benötigen keinen Zugang zum Internet. Wenn GO-Global jedoch mit einer Cloud-Lizenz aktiviert wird, müssen die APS auf den Farm Managern in der Lage sein, sich mit portal.graphon.com und cloud.graphon.com auf Port 443 zu verbinden.
Domänencontroller
In den meisten Fällen sind die Farm Hosts Mitglieder einer Microsoft Active Directory (AD) Domäne. In dieser Umgebung ist es für Farm Hosts unerlässlich, die Kommunikation mit ihren Domänencontrollern aufrechtzuerhalten. Diese Konnektivität ermöglicht es ihnen, Konten zu authentifizieren, Benutzerinformationen und -einstellungen abzurufen, Roaming-Profile zu laden und Gruppenrichtlinien durchzusetzen. In OpenID Connect-Bereitstellungen müssen Kunden häufig eine eingeschränkte Delegation für die AD-Computerobjekte der Farm Hosts konfigurieren.
Verwaltung Firewall
Eine Administrations-Firewall kann verwendet werden, um die Fähigkeit von Benutzern einzuschränken, von Farm-Hosts aus auf Verwaltungssysteme wie Domänencontroller und Farm-Manager zuzugreifen. Eine Administrations-Firewall kann beispielsweise verhindern, dass Benutzer, die Anwendungen auf Farm-Hosts ausführen, versuchen, über Remote Desktop eine Verbindung zu Domänencontrollern und Farm-Managern herzustellen.
Wenn zwischen Farm-Hosts und Farm-Managern eine Administrations-Firewall besteht, muss die Firewall den Farm-Hosts erlauben, sich mit den Farm-Managern über den in der Verwaltungskonsole unter Extras | Host-Optionen | Sicherheit | Port angegebenen Port (standardmäßig 491) zu verbinden, und der Datenverkehr muss in beide Richtungen erlaubt sein.
Wenn eine Administrationsfirewall zwischen Farm Hosts und Domänencontrollern besteht, muss die Firewall so konfiguriert werden, dass sie die gesamte Kommunikation über die Ports zulässt, die Windows für die Kommunikation zwischen Domänencontrollern und Domänenmitgliedern verwendet. Diese Informationen finden Sie in der Dokumentation von Microsoft.
Identitätsanbieter
Wenn die OpenID Connect-Authentifizierung verwendet wird, müssen Farm-Hosts in der Lage sein, Verbindungen zum Identitätsanbieter über die Token-URL zu öffnen, die in der Verwaltungskonsole unter Extras | Hostoptionen | Authentifizierung | OpenID Connect-Einstellungen konfigurieren | Token-URL angegeben ist.
Auto-Scaling-Infrastruktur
Cloud Service Provider (CSPs) wie Amazon Web Services (AWS), Microsoft Azure, Oracle Cloud und Google Cloud (GCP) bieten Funktionen, mit denen Farm Hosts automatisch gestartet und gestoppt werden können, wenn die Last steigt oder fällt. Bei der Nutzung dieser Funktionen erstellen Administratoren in der Regel ein Basis-Image ("Gold") eines Farm Hosts, das bei Bedarf repliziert werden kann, um die Benutzer zu unterstützen, die sich mit dem System verbinden.
Auf den Images der Farm-Hosts ist GO-Global installiert und konfiguriert, ebenso wie alle Anwendungen, die Benutzer auf den Farm-Hosts ausführen werden. Administratoren automatisieren die Erstellung dieser Images in der Regel mit einer Kombination aus PowerShell-Skripten und Infrastrukturcode, der mit einem Infrastructure as Code (IaC) Tool wie Terraform entwickelt wurde.
Unter Automatisierte Konfiguration von GO-Global erfahren Sie, wie GO-Global programmatisch installiert und konfiguriert werden kann.
Bei Farm-Host-Images sind normalerweise die Adressen des Farm-Managers und des Failover-Farm-Managers im Image gespeichert. Dies macht das Skalieren (Hinzufügen von Hosts zu einer Farm) einfach. Wenn neue Host-Instanzen gestartet werden, stellen sie automatisch eine Verbindung zum Farm-Manager her, und die automatische Skalierungsfunktion des CSP kümmert sich in der Regel um das Hinzufügen der neuen Instanz zur Zielgruppe des Load Balancer.
Farm-Hosts erhalten Lizenzen von ihren Farm-Managern, so dass beim Start einer neuen Farm-Host-Instanz keine Lizenzierungskonfiguration erforderlich ist. Wenn Sitzungen auf einem Farm Host beginnen, checkt der Host Lizenzplätze vom Farm Manager aus. Im Allgemeinen wird ein Platz für jede gleichzeitige Sitzung verbraucht.
Das Einskalieren (Entfernen von Hosts aus einer Farm) ist im Allgemeinen etwas komplizierter als das Ausskalieren. Dies liegt daran, dass es in der Regel wünschenswert ist, mit dem Herunterfahren einer Farm-Host-Instanz zu warten, bis alle auf ihr laufenden Sitzungen geschlossen wurden. Wie Sie einen Farm-Host offline schalten, wird in diesem Abschnitt beschrieben.
Wenn ein Farm-Host angehalten wird, wird die Verbindung des Hosts mit dem Farm-Manager unterbrochen. Wenn dies geschieht, gibt der Farm-Manager automatisch alle Sitze frei, die auf dem Host verwendet wurden. Es besteht also keine Gefahr, dass Sitze von nicht mehr existierenden Hosts verbraucht werden. Es muss nichts unternommen werden, um stillgelegte Hosts zu löschen; dies geschieht automatisch.
Bei GO-Global ist die beste Metrik zur Steuerung der automatischen Skalierung im Allgemeinen die Anzahl der laufenden Sitzungen. Die Anzahl der Sitzungen, die auf einem Host oder einer Farm laufen, kann von einem Farm-Host oder Farm-Manager über GO-Globals Leistungszähler oder über GO-Globals PowerShell-Funktion Get-GGSessions ermittelt werden.
Verfügbarkeitszonen und -regionen
Um eine hohe Verfügbarkeit zu gewährleisten, unterstützen Cloud-Service-Anbieter (CSPs) Implementierungen mit mehreren Rechenzentren über Verfügbarkeitszonen und Regionen. Verfügbarkeitszonen sind ein oder mehrere Rechenzentren, die sich in derselben geografischen Region befinden. CSP-Regionen sind geografische Gebiete, die eine oder mehrere Verfügbarkeitszonen enthalten. CSP Fault Domains, auch als Verfügbarkeitsgruppen bekannt, sind fehlertolerante Ressourcen, die sich in physisch getrennten Teilen eines einzelnen Rechenzentrums befinden.
GO-Global unterstützt Einsätze in mehreren Verfügbarkeitszonen. Die Verfügbarkeitszonen, in denen GO-Global eingesetzt wird, können sich in derselben CSP-Region oder in verschiedenen CSP-Regionen befinden.
Innerhalb einer CSP-Region wird GO-Global im Allgemeinen in mindestens zwei Verfügbarkeitszonen eingesetzt, wobei der primäre Farm Manager in einer Verfügbarkeitszone und der Failover Farm Manager in einer anderen Verfügbarkeitszone läuft. Die Farm-Hosts können in einer beliebigen Anzahl von Verfügbarkeitszonen innerhalb der Region betrieben werden, müssen aber in der Lage sein, sich sowohl mit dem primären Farm-Manager als auch mit dem Failover-Farm-Manager zu verbinden.
Wenn eine hohe Verfügbarkeit über CSP-Regionen hinweg erforderlich ist oder wenn sich Benutzer auf der ganzen Welt befinden, kann GO-Global in mehreren CSP-Regionen mit einem DNS-Load-Balancer wie Route 53 von AWS bereitgestellt werden, der Client-Verbindungen über die Regionen hinweg leitet. Der DNS-Load-Balancer kann dann so konfiguriert werden, dass er je nach Bedarf ein aktiv-aktives oder aktiv-passives Failover unterstützt.
Überwachungs- und Beobachtungstools
Überwachungs- und Beobachtungstools werden verwendet, um den Zustand von GO-Global-Einsätzen zu überwachen und bei Problemen Alarm zu schlagen. GO-Global bietet mehrere Funktionen, die diese Tools zur Überwachung von GO-Global nutzen können.
Die meisten Beobachtungstools verfügen über Funktionen zum Einlesen von Protokolldateien. Die Protokolldateien von GO-Global liegen standardmäßig im HTML-Format vor, das von den meisten Beobachtungstools nicht unterstützt wird. Daher muss GO-Global im Allgemeinen so konfiguriert werden, dass seine Protokolldateien im Textformat aufgezeichnet werden, wenn die Protokolle von einem Beobachtungstool eingelesen werden sollen.
Zusätzlich zu seinen Protokolldateien zeichnet GO-Global Ereignisse im Windows-Anwendungsprotokoll auf. Zu den Ereignissen, die GO-Global im Windows-Anwendungsprotokoll aufzeichnet, gehören Sitzungsstarts und -stopps, Benutzeranmeldungen und Anwendungsstarts und -stopps.
Um die Überwachung von Farm-Hosts und Farm-Managern zu unterstützen, bietet GO-Global eine healthCheck-Anfrage. Die healthCheck-Anfrage kann verwendet werden, um festzustellen, ob der Application Publishing Service auf einem Farm-Host oder Farm-Manager läuft und, optional, ob das System in der Lage ist, eine Sitzung zu erstellen. Load Balancer können beispielsweise die healthCheck-Anfrage verwenden, um den Zustand von Farm Hosts in ihrer Zielgruppe zu überprüfen.
Systeme, die HealthCheck-Anfragen senden, müssen bei jedem Ziel-Farm-Host oder Farm-Manager registriert sein. Insbesondere muss die IP-Adresse des Systems, das die Anforderung sendet, im CIDR-Format in der Eigenschaft APIWhiteList in der Datei "HostProperties.xml" des Zielsystems aufgeführt sein.
Zusätzlich zu diesen Tools kann die PowerShell-API von GO-Global verwendet werden, um detaillierte Laufzeitinformationen von Farm-Hosts und Farm-Managern zu erhalten. Die Funktion Get-GGSessions gibt beispielsweise Informationen über die auf einem Farm-Host oder Farm-Manager laufenden Sitzungen zurück.
Schlussfolgerung
Der Einsatz von GO-Global in einer groß angelegten oder Cloud-integrierten Umgebung erfordert eine sorgfältige Koordination zwischen mehreren Infrastrukturkomponenten. Durch die korrekte Konfiguration von Elementen wie Firewalls, Load Balancern, Reverse Proxies und Überwachungssystemen können Administratoren eine sichere, skalierbare und hochleistungsfähige GO-Global-Umgebung schaffen, die eine nahtlose Benutzererfahrung bietet.
Ob vor Ort, in der Cloud oder in hybriden Architekturen implementiert, die in diesem Artikel beschriebenen Prinzipien stellen sicher, dass GO-Global in modernen Unternehmensnetzwerken effizient arbeitet und auf jeder Implementierungsebene Zuverlässigkeit, Flexibilität und Kontrolle bietet.
Sind Sie ein ISV, der sich mit der Bereitstellung von Cloud-basierten Anwendungen beschäftigt? Setzen Sie sich mit uns in Verbindung, um zu erfahren, wie GO-Global Ihnen helfen kann, den Software-Zugang für Ihre Endbenutzer zu optimieren. Oder laden Sie eine kostenlose Testversion herunter, um es selbst zu testen.
