Wereldwijde implementaties
Grootschalige GO-Global implementaties gaan vaak veel verder dan Farm Hosts en Farm Managers. In bedrijfsomgevingen werken ze meestal naast tal van ondersteunende systemen die zijn ontworpen om de prestaties, betrouwbaarheid en beveiliging te verbeteren. Deze systemen - waaronder firewalls, load balancers, web application firewalls (WAF's), reverse proxies en monitoring tools - zorgen ervoor dat GO-Global applicaties toegankelijk en veerkrachtig blijven en voldoen aan de normen van de organisatie.
Dit artikel biedt gedetailleerde richtlijnen voor het configureren van GO-Global om effectief te functioneren binnen complexe IT-infrastructuren die dergelijke componenten bevatten. Er wordt uitgelegd hoe GO-Global communiceert met elk systeem, wat de beste configuratiepraktijken zijn en wat de belangrijkste overwegingen zijn voor beheerders die grootschalige of cloudgebaseerde implementaties beheren.
Firewall
Wanneer een GO-Global implementatie toegankelijk is vanaf het internet, is een firewall op de buitenrand meestal de eerste verdedigingslinie tegen inbraken. Firewalls worden meestal geconfigureerd om inkomende verbindingen toe te staan op TCP-poort 443, de standaardpoort voor beveiligd HTTPS/TLS-verkeer.
Omdat poort 443 de standaardpoort is voor beveiligd verkeer en omdat dit de poort is die open staat op de meeste firewalls van bedrijven (klanten), worden GO-Global klanten die verbinding maken via internet meestal geconfigureerd om verbinding te maken met poort 443 in plaats van de standaardpoort van GO-Global, 491. Dit wordt gedaan door de poort toe te voegen in de URL (bijvoorbeeld &port=443) of door de poort op te geven in de aanmeldpagina van GO-Global. Dit wordt gedaan door de poort toe te voegen in de URL (bijvoorbeeld &port=443) of door de poort op te geven in de aanmeldpagina.html van GO-Global.
Webtoepassingsfirewall (WAF)
Een Web Application Firewall (WAF) analyseert inkomende HTTP verzoeken om kwaadaardige verzoeken te identificeren en te blokkeren. WAFs kunnen ook verkeer routeren naar verschillende backend servers op basis van informatie in HTTP-verzoeken, maar dit is niet hun primaire functie. Hun primaire functie is het bieden van beveiliging en bescherming tegen aanvallen zoals DDoS-aanvallen (Distributed Denial of Service).
Voorbeelden van WAF's zijn Cloudflare WAF, AWS WAF (Amazon Web Services), Azure Web Application Firewall, F5 Advanced WAF, Imperva WAF, Akamai Kona Site Defender, Fortinet FortiWeb, Barracuda WAF en Radware WAF.
Om HTTPS-verkeer te analyseren, moeten WAF's TLS beëindigen zodat ze de verzoeken kunnen decoderen. Wanneer TLS wordt beëindigd door een WAF, moet de tls-parameter van GO-Global worden toegevoegd aan de URL van de client of moet deze worden opgegeven in de aanmeldpagina.html van GO-Global.
Een andere overweging voor GO-Global verkeer is dat WAF's het eigen RXP-protocol van GO-Global niet kunnen analyseren. Daarom, wanneer communicatie tussen een GO-Global client en host door een WAF gaat, moet het worden verpakt in HTTP verzoeken door GO-Global te configureren om een Websocket te gebruiken, of de gegevensanalyse functies van de WAF moeten worden uitgeschakeld voor het GO-Global verkeer.
Alle GO-Global clients van versie 6.3.3 en later ondersteunen WebSockets. In GO-Global versie 6.3.2 en eerder ondersteunt echter alleen de GO-Global Web App WebSockets. AppController, de native client van GO-Global, ondersteunt WebSockets niet in versie 6.3.2 en eerder.
Als AppController versie 6.3.2 of ouder wordt gebruikt met een WAF, moet de omgeving zo worden geconfigureerd dat de WAF het verkeer van AppController niet inspecteert. Dit kan bijvoorbeeld door een ander eindpunt (publiek adres) te voorzien voor AppController verbindingen die de WAF niet gebruiken, of door AppController te configureren om verbinding te maken op een andere poort en de WAF te configureren om verkeer door te laten op deze poort zonder het te inspecteren.
Omgekeerde proxy
Net als WAF's analyseren reverse proxies inkomende HTTP verzoeken. Reverse proxies hebben enkele beveiligingsfuncties, maar in tegenstelling tot WAF's is de primaire functie van reverse proxies verkeersbeheer, geen beveiliging. Reverse proxies worden bijvoorbeeld vaak gebruikt wanneer meerdere webapplicaties en diensten worden aangeboden vanaf hetzelfde publieke eindpunt. Ze routeren inkomende aanvragen voor verschillende applicaties naar hun respectievelijke applicatieservers. Ze kunnen ook worden gebruikt als load balancer voor GO-Global Farm Hosts.
Voorbeelden van reverse proxies zijn Nginx, Apache HTTP Server, HAProxy, Traefik en Cloudflare. De AWS Application Load Balancer en Azure Application Gateway hebben verschillende functies, waaronder het dienen als een reverse proxy.
Net als WAF's moeten reverse proxy's TLS beëindigen zodat ze inkomende HTTP-verzoeken kunnen analyseren. Net als bij WAF's moet, wanneer TLS wordt beëindigd door een reverse proxy, de tls-parameter van GO-Global worden toegevoegd aan de URL van de client of moet deze worden opgegeven in de aanmeldpagina.html van GO-Global.
Net als WAF's kunnen reverse proxies het eigen RapidX Protocol (RXP) van GO-Global niet analyseren. Daarom moet, net als bij een WAF, wanneer communicatie tussen een GO-Global client en host via een reverse proxy verloopt, deze worden verpakt in HTTP-verzoeken door GO-Global te configureren voor het gebruik van een WebSocket, of de functies voor gegevensanalyse van de reverse proxy moeten worden uitgeschakeld voor het GO-Global verkeer.
En net zoals bij een WAF, als AppController versie 6.3.2 of ouder gebruikt wordt met een reverse proxy, moet de omgeving geconfigureerd worden zodat de WAF het verkeer van AppController niet inspecteert. Dit kan bijvoorbeeld door een ander eindpunt (publiek adres) te voorzien voor AppController verbindingen die geen gebruik maken van de reverse proxy, of door AppController te configureren om verbinding te maken op een andere poort en de reverse proxy te configureren om verkeer door te laten op deze poort zonder het te inspecteren.
Webserver
GO-Global hosts hebben een geïntegreerde webserver die de GO-Global webapp en de ondersteunende HTML- en JavaScript-bestanden kan hosten. Wanneer de geïntegreerde webserver van GO-Global wordt gebruikt, worden HTTP-verzoeken voor GO-Global webbestanden doorgestuurd naar GO-Global Farm Hosts op het interne netwerk.
In internetimplementaties zijn er echter beveiligingsvoordelen verbonden aan het hosten van de webbestanden van GO-Global op een webserver van derden in de DMZ. Voorbeelden van webservers van derden zijn Apache HTTP Server, Nginx en Microsoft IIS (Internet Information Services).
Wanneer een webserver van derden wordt gebruikt, moeten de GO-Global webapp en bijbehorende bestanden worden geïnstalleerd op de webserver, hetzij via het Host installatieprogramma of door de inhoud van de GO-Global webdirectory te kopiëren naar de webserver.
Hoewel de meeste webservers van derden functionaliteit hebben om WebSocket-verbindingen te verwerken, worden WebSocket-verbindingen meestal verwerkt door een speciale loadbalancer of reverse proxy. Beheerders kunnen WAF's en reverse proxy's configureren om HTTP-verzoeken van GO-Global naar een webserver te routeren en WebSocket-verbindingen te routeren naar GO-Global Farm Hosts of naar een loadbalancer.
Als een WAF of reverse proxy niet wordt gebruikt, kunnen beheerders ook een ander eindpunt (adres of poort) maken voor de WebSocket-verbindingen van GO-Global en dit eindpunt opgeven via de host- en/of poortparameters in de URL van de client of de aanmeldpagina GO-Global .html.
Netwerk Load Balancer
Als er meer dan één Farm Host nodig is, is er een load balancer nodig om gebruikersverbindingen tussen de hosts te verdelen. De load balancer kan een reverse proxy of een netwerk load balancer zijn.
In omgevingen waar meerdere applicaties toegankelijk zijn via een enkel internet eindpunt, zal de perimeter firewall meestal verbindingen doorsturen naar een reverse proxy (optioneel via een WAF). De reverse proxy kan dan ofwel de verbindingen direct doorsturen naar Farm Hosts (de belasting balanceren), of het kan de verbindingen indirect doorsturen naar de hosts via een netwerk load balancer.
In omgevingen waar GO-Global de enige applicatie is die via het interneteindpunt wordt benaderd, kan de firewall verbindingen op poort 443 rechtstreeks doorsturen naar een netwerkloadbalancer. Vanaf daar selecteert de loadbalancer een Farm Host en stuurt de verbinding door naar de Farm Host op de poort die is opgegeven in de beheerconsole.
In tegenstelling tot reverse proxies inspecteren netwerk load balancers het verkeer niet en routeren ze het op basis van de inhoud van de gegevens. Ze routeren het verkeer over het algemeen op basis van variabelen zoals de bestemmingspoort en het bron IP-adres. Voorbeelden van loadbalancers die op laag 4 kunnen werken en TCP-verbindingen kunnen routeren (TLS wordt afgesloten bij GO-Global hosts) zijn HAProxy, Azure loadbalancer en AWS Network Load Balancer.
Sommige netwerklaadbalancers kunnen TLS beëindigen bij de loadbalancer. Als de loadbalancer is geconfigureerd om TLS te beëindigen, moet de tls-parameter van GO-Global worden toegevoegd aan de URL van de client of moet deze worden opgegeven in de pagina aanmelden.html van GO-Global.
Wanneer een loadbalancer TLS beëindigt, kan hij optioneel de gegevens die hij naar Farm Hosts verzendt, opnieuw versleutelen. Als de Farm Hosts zijn geconfigureerd om het TLS-protocol te gebruiken, moet de loadbalancer worden geconfigureerd om de gegevens die hij naar Farm Hosts verzendt opnieuw te versleutelen. Als de loadbalancer de gegevens daarentegen niet opnieuw codeert, moet GO-Global's Protocol worden ingesteld op TCP en Encryption op None.
Als een netwerk load balancer TLS niet afsluit, geeft het de data door aan Farm Hosts zonder het te ontsleutelen en opnieuw te versleutelen. In deze configuratie moet het TLS protocol ingeschakeld zijn op Farm Hosts en mag de tls parameter niet gespecificeerd zijn in de client URL of logon.html pagina.
Back-end firewall
Een back-end firewall kan worden gebruikt om de toegang tot Farm Hosts te beperken tot specifieke front-end systemen. Bijvoorbeeld, als reverse proxies worden gebruikt om verbindingen naar Farm Hosts te routeren, kan een back-end firewall zo worden geconfigureerd dat alleen de reverse proxies verbinding mogen maken met de Farm Hosts. In dit voorbeeld moet de back-end firewall geconfigureerd worden om de reverse proxies verbinding te laten maken met de Farm Hosts op de poort die in de beheerconsole is gespecificeerd onder Tools | Host Options | Security | Port (standaard 491), en verkeer moet in beide richtingen worden toegestaan.
Als de applicaties die op Farm Hosts draaien toegang moeten hebben tot het internet, dan moet de back-end firewall geconfigureerd worden om deze toegang toe te staan.
GO-Global Farm Hosts hebben geen toegang tot internet nodig. Als GO-Global echter wordt geactiveerd met een cloudlicentie, moet het APS op Farm Managers verbinding kunnen maken met portal.graphon.com en cloud.graphon.com op poort 443.
Domeincontroller
In de meeste implementaties zijn Farm Hosts lid van een Microsoft Active Directory (AD) domein. In deze omgeving is het essentieel dat Farm Hosts communicatie onderhouden met hun domeincontrollers. Deze connectiviteit stelt ze in staat om accounts te verifiëren, gebruikersinformatie en instellingen op te halen, roaming profielen te laden en Groepsbeleid af te dwingen. In OpenID Connect implementaties moeten klanten vaak beperkte delegatie configureren op de AD computerobjecten van Farm Hosts.
Beheer Firewall
Een administratie firewall kan worden gebruikt om de toegang van gebruikers tot administratieve systemen zoals domeincontrollers en Farm Managers vanaf Farm Hosts te beperken. Een administratie firewall kan bijvoorbeeld worden gebruikt om te voorkomen dat gebruikers die applicaties op Farm Hosts draaien, verbinding proberen te maken met domeincontrollers en Farm Managers door middel van Remote Desktop.
Als er een administratieve firewall bestaat tussen Farm Hosts en Farm Managers, moet de firewall Farm Hosts toestaan om verbinding te maken met de Farm Managers op de poort die in de beheerconsole is gespecificeerd onder Tools | Host Options | Security | Port (standaard 491), en verkeer moet in beide richtingen zijn toegestaan.
Als er een administratieve firewall bestaat tussen Farm Hosts en domeincontrollers, moet de firewall worden geconfigureerd voor alle communicatie op de poorten die Windows gebruikt om te communiceren tussen domeincontrollers en domeinleden. Raadpleeg de documentatie van Microsoft voor deze informatie.
Identiteitsprovider
Wanneer OpenID Connect Authenticatie wordt gebruikt, moeten Farm Hosts verbindingen met de Identity Provider kunnen openen via de Token URL die in de beheerconsole is gespecificeerd onder Tools | Host Options | Authentication | Configure OpenID Connect Settings | Token URL.
Infrastructuur voor automatisch schalen
Cloud Service Providers (CSP's) zoals Amazon Web Services (AWS), Microsoft Azure, Oracle Cloud en Google Cloud (GCP) bieden functies die kunnen worden gebruikt om Farm Hosts automatisch te starten en te stoppen als de belasting toeneemt en afneemt. Als ze deze functies gebruiken, maken beheerders over het algemeen een basis image ("gold image") van een Farm Host dat naar behoefte kan worden gerepliceerd om de gebruikers die verbinding maken met het systeem te ondersteunen.
Op Farm Host images is GO-Global geïnstalleerd en geconfigureerd, net als alle applicaties die gebruikers op de Farm Hosts draaien. Beheerders automatiseren meestal het bouwen van deze images met behulp van een combinatie van PowerShell scripts en infrastructuurcode ontwikkeld met behulp van een Infrastructure as Code (IaC) tool zoals Terraform.
Zie De configuratie van GO-Global automatiseren over hoe GO-Global programmatisch kan worden geïnstalleerd en geconfigureerd.
Farm host images hebben meestal de adressen van hun Farm Manager en Failover Farm Manager opgeslagen in de image. Dit maakt uitschalen (hosts toevoegen aan een farm) eenvoudig. Als er nieuwe hostinstanties worden gestart, maken ze automatisch verbinding met de Farm Manager en de auto-scaling functie van de CSP zorgt er over het algemeen voor dat de nieuwe instantie wordt toegevoegd aan de doelgroep van de loadbalancer.
Farm Hosts krijgen licenties van hun Farm Managers, dus er is geen licentie configuratie nodig wanneer een nieuwe Farm Host instance start. Wanneer sessies op een Farm Host starten, checkt de host licentie seats van de Farm Manager. Over het algemeen wordt voor elke gelijktijdige sessie één licentie gebruikt.
Inschalen (hosts uit een farm verwijderen) is over het algemeen iets gecompliceerder dan uitschalen. Dit komt omdat het meestal wenselijk is om te wachten met het afsluiten van een Farm Host instantie totdat alle sessies die erop draaien zijn afgesloten. Een Farm Host offline halen beschrijft hoe je dit doet.
Wanneer een Farm Host stopt, wordt de verbinding van de host met de Farm Manager verbroken. Wanneer dit gebeurt, geeft de Farm Manager automatisch alle seats vrij die op de host in gebruik waren. Er is dus geen risico dat er seats worden gebruikt door hosts die niet meer bestaan. Er hoeft niets te worden gedaan om hosts die zijn afgesloten vrij te geven; dit gebeurt automatisch.
Met GO-Global is over het algemeen het aantal lopende sessies de beste maatstaf om auto-scaling te controleren. Het aantal sessies dat draait op een host of een farm kan respectievelijk worden verkregen van een Farm Host of Farm Manager via GO-Global's Performance Counters of via GO-Global's Get-GGSessions PowerShell functie.
Beschikbaarheidszones en -regio's
Om een hoge beschikbaarheid te bieden, ondersteunen Cloud Service Providers (CSP's) multi-datacenter implementaties via beschikbaarheidszones en regio's. Beschikbaarheidzones zijn één of meer datacenters die zich binnen dezelfde geografische regio bevinden. Beschikbaarheidszones zijn een of meer datacenters binnen dezelfde geografische regio. CSP-regio's zijn geografische gebieden die een of meer beschikbaarheidszones bevatten. CSP-foutdomeinen, ook bekend als beschikbaarheidsgroepen, zijn fouttolerante bronnen die zich in fysiek gescheiden delen van één datacenter bevinden.
GO-Global ondersteunt inzet in meerdere beschikbaarheidszones. De beschikbaarheidszones waarin GO-Global wordt ingezet, kunnen zich binnen dezelfde CSP-regio of in verschillende CSP-regio's bevinden.
Binnen een CSP-regio wordt GO-Global over het algemeen ingezet in ten minste twee beschikbaarheidszones, waarbij de primaire Farm Manager in één beschikbaarheidszone draait en de failover Farm Manager in een andere beschikbaarheidszone. De Farm Hosts kunnen in een willekeurig aantal beschikbaarheidszones binnen de regio draaien, maar ze moeten verbinding kunnen maken met zowel de primaire Farm Manager als de failover Farm Manager.
Als een hoge beschikbaarheid tussen CSP-regio's nodig is, of als gebruikers zich over de hele wereld bevinden, kan GO-Global worden ingezet in meerdere CSP-regio's met een DNS-laadbalancer zoals Route 53 van AWS die clientverbindingen over de regio's routeert. De DNS-loadbalancer kan dan worden geconfigureerd om actieve-actieve of actieve-passieve failover te ondersteunen, afhankelijk van wat nodig is.
Hulpmiddelen voor bewaking en waarneembaarheid
Tools voor bewaking en observeerbaarheid worden gebruikt om de gezondheid van GO-Global implementaties te bewaken en waarschuwingen te geven wanneer er problemen optreden. GO-Global biedt verschillende functies die deze tools kunnen gebruiken om GO-Global te bewaken.
De meeste observatiehulpmiddelen hebben functies om logbestanden op te nemen. De logbestanden van GO-Global zijn standaard in HTML-indeling, wat de meeste observatiehulpmiddelen niet ondersteunen. Daarom moet GO-Global worden geconfigureerd om haar logbestanden in tekstformaat op te slaan wanneer de logbestanden worden opgenomen door een waarneembaarheidshulpmiddel.
Naast de logboekbestanden registreert GO-Global gebeurtenissen in het Windows-toepassingslogboek. De gebeurtenissen die GO-Global vastlegt in het Windows-toepassingslogboek zijn sessiestart en -stop, gebruikersaanmeldingen en applicatiestart en -stop.
Om het monitoren van Farm Hosts en Farm Managers te ondersteunen, levert GO-Global een healthCheck verzoek. Het healthCheck verzoek kan worden gebruikt om te bepalen of de Application Publishing Service draait op een Farm Host of Farm Manager en, optioneel, of het systeem in staat is om een sessie aan te maken. Load balancers kunnen bijvoorbeeld het healthCheck verzoek gebruiken om de gezondheid van Farm Hosts in hun doelgroep te controleren.
Systemen die healthCheck verzoeken versturen moeten bij elke Farm Host of Farm Manager geregistreerd zijn. Het IP adres van het systeem dat het verzoek verstuurt moet in CIDR formaat in de APIWhiteList eigenschap in het HostProperties.xml bestand van het doelsysteem staan.
Naast deze tools kan GO-Global's PowerShell API worden gebruikt om gedetailleerde runtime informatie van Farm Hosts en Farm Managers te verkrijgen. De functie Get-GGSessions geeft bijvoorbeeld informatie over de sessies die worden uitgevoerd op een Farm Host of Farm Manager.
Conclusie
De implementatie van GO-Global in een grootschalige of cloud-geïntegreerde omgeving vereist zorgvuldige coördinatie tussen meerdere infrastructuurcomponenten. Door elementen zoals firewalls, load balancers, reverse proxies en monitoringsystemen correct te configureren, kunnen beheerders een veilige, schaalbare en goed presterende GO-Global omgeving realiseren die een naadloze gebruikerservaring biedt.
Of GO-Global nu op locatie, in de cloud of in hybride architecturen wordt geïmplementeerd, de principes die in dit artikel worden beschreven zorgen ervoor dat GO-Global efficiënt werkt binnen moderne bedrijfsnetwerken, met behoud van betrouwbaarheid, flexibiliteit en controle in elke implementatielaag.
Bent u een ISV die de levering van toepassingen in de cloud onderzoekt? Neem contact met ons op om te ontdekken hoe GO-Global u kan helpen de toegang tot software voor uw eindgebruikers te stroomlijnen. Of download een gratis proefversie om het zelf te testen.
