Go-globale udrulninger
Store GO-Global-implementeringer strækker sig ofte langt ud over Farm Hosts og Farm Managers. I virksomhedsmiljøer opererer de typisk sammen med adskillige støttesystemer, der er designet til at forbedre ydeevne, pålidelighed og sikkerhed. Disse systemer - herunder firewalls, load balancers, web application firewalls (WAFs), reverse proxies og overvågningsværktøjer - sikrer, at GO-Global-applikationer forbliver tilgængelige, modstandsdygtige og i overensstemmelse med organisationens standarder.
Denne artikel giver detaljeret vejledning i at konfigurere GO-Global til at fungere effektivt i komplekse IT-infrastrukturer, der omfatter sådanne komponenter. Den forklarer, hvordan GO-Global interagerer med hvert system, skitserer bedste praksis for konfiguration og fremhæver vigtige overvejelser for administratorer, der administrerer store eller skybaserede implementeringer.
Perimeter-firewall
Når en GO-Global-implementering er tilgængelig fra internettet, er en perimeter-firewall generelt den første forsvarslinje mod indtrængen. Perimeter-firewalls er typisk konfigureret til at tillade indgående forbindelser på TCP-port 443, som er standardporten for sikker HTTPS/TLS-trafik.
Da port 443 er standardporten for sikker trafik, og da det er den port, der er åben på de fleste virksomheders (klienters) firewalls, er GO-Global-klienter, der opretter forbindelse over internettet, typisk konfigureret til at oprette forbindelse til port 443 i stedet for GO-Globals standardport, 491. Dette gøres enten ved at tilføje porten i URL'en (f.eks. &port=443) eller ved at angive porten på GO-Globals logon.html-side.
Firewall til webapplikationer (WAF)
En webapplikations-firewall (WAF) analyserer indgående HTTP-anmodninger for at identificere og blokere ondsindede anmodninger. WAF'er kan også dirigere trafik til forskellige backend-servere baseret på oplysninger i HTTP-anmodninger, men det er ikke deres primære funktion. Deres primære funktion er at give sikkerhed og beskytte mod angreb som f.eks. DDoS-angreb (distributed denial of service).
Eksempler på WAF'er er Cloudflare WAF, AWS WAF (Amazon Web Services), Azure Web Application Firewall, F5 Advanced WAF, Imperva WAF, Akamai Kona Site Defender, Fortinet FortiWeb, Barracuda WAF og Radware WAF.
For at analysere HTTPS-trafik skal WAF'er afslutte TLS, så de kan dekryptere anmodningerne. Når TLS afsluttes af en WAF, skal GO-Globals tls-parameter tilføjes til klientens URL, eller den skal angives på GO-Globals logon.html-side.
En anden overvejelse for GO-Global-trafik er, at WAF'er ikke kan analysere GO-Globals proprietære RXP-protokol. Når kommunikationen mellem en GO-Global-klient og -vært passerer gennem en WAF, skal den derfor enten pakkes ind i HTTP-anmodninger ved at konfigurere GO-Global til at bruge en websocket, eller WAF'ens dataanalysefunktioner skal deaktiveres for GO-Global-trafikken.
Alle GO-Global-klienter i version 6.3.3 og senere understøtter WebSockets. I GO-Global version 6.3.2 og tidligere er det dog kun GO-Global Web App, der understøtter WebSockets. AppController, GO-Globals oprindelige klient, understøtter ikke WebSockets i version 6.3.2 og tidligere.
Hvis AppController version 6.3.2 eller tidligere bruges sammen med en WAF, skal miljøet konfigureres, så WAF'en ikke inspicerer AppControllers trafik. Det kan f.eks. gøres ved at give et andet slutpunkt (offentlig adresse) til AppController-forbindelser, der ikke bruger WAF, eller ved at konfigurere AppController til at forbinde på en anden port og konfigurere WAF til at passere trafik på denne port uden at inspicere den.
Omvendt proxy
Ligesom WAF'er analyserer reverse proxyer indgående HTTP-anmodninger. Omvendte proxyer har nogle sikkerhedsfunktioner, men i modsætning til WAF'er er den primære funktion af omvendte proxyer trafikstyring, ikke sikkerhed. Omvendte proxyer bruges f.eks. ofte, når flere webapplikationer og -tjenester leveres fra det samme offentlige slutpunkt. De dirigerer indgående anmodninger om forskellige applikationer til deres respektive applikationsservere. De kan også bruges som load balancer for GO-Global Farm Hosts.
Eksempler på reverse proxyer er Nginx, Apache HTTP Server, HAProxy, Traefik og Cloudflare. AWS Application Load Balancer og Azure Application Gateway har forskellige funktioner, og en af dem er at fungere som reverse proxy.
Ligesom WAF'er skal reverse proxyer afslutte TLS, så de kan analysere indgående HTTP-anmodninger. Som med WAF'er skal GO-Globals tls-parameter tilføjes til klientens URL, når TLS afsluttes af en omvendt proxy, eller den skal specificeres på GO-Globals logon.html-side.
Ligesom WAF'er kan reverse proxyer ikke analysere GO-Globals proprietære RapidX-protokol (RXP). Når kommunikationen mellem en GO-Global-klient og -vært går gennem en omvendt proxy, skal den derfor, ligesom med en WAF, enten pakkes ind i HTTP-anmodninger ved at konfigurere GO-Global til at bruge en WebSocket, eller den omvendte proxys dataanalysefunktioner skal deaktiveres for GO-Global-trafikken.
Og som med en WAF, hvis AppController version 6.3.2 eller tidligere bruges med en reverse proxy, skal miljøet konfigureres, så WAF'en ikke inspicerer AppControllers trafik. Det kan f.eks. gøres ved at give et andet slutpunkt (offentlig adresse) til AppController-forbindelser, der ikke bruger den omvendte proxy, eller ved at konfigurere AppController til at forbinde på en anden port og konfigurere den omvendte proxy til at sende trafik på denne port uden at inspicere den.
Webserver
GO-Global-værter har en integreret webserver, der kan være vært for GO-Global-webappen og dens understøttende HTML- og JavaScript-filer. Når GO-Globals integrerede webserver bruges, videresendes HTTP-anmodninger om GO-Globals webfiler til GO-Global Farm Hosts på det interne netværk.
I internetinstallationer er der dog sikkerhedsmæssige fordele ved at hoste GO-Globals webfiler på en tredjepartswebserver, der er placeret i DMZ. Eksempler på tredjepartswebservere omfatter Apache HTTP Server, Nginx og Microsoft IIS (Internet Information Services).
Når der bruges en tredjepartswebserver, skal GO-Globals webapp og tilhørende filer installeres på webserveren, enten via Host-installationsprogrammet eller ved at kopiere indholdet af GO-Globals webmappe til webserveren.
Mens de fleste tredjepartswebservere har funktionalitet til at håndtere WebSocket-forbindelser, håndteres WebSocket-forbindelser generelt af en dedikeret load balancer eller reverse proxy. Administratorer kan konfigurere WAF'er og reverse proxyer til at dirigere GO-Globals HTTP-anmodninger til en webserver og til at dirigere WebSocket-forbindelser til GO-Global Farm Hosts eller til en belastningsudligner.
Alternativt, når der ikke bruges en WAF eller reverse proxy, kan administratorer oprette et andet slutpunkt (adresse eller port) til GO-Globals WebSocket-forbindelser og angive dette slutpunkt via host- og/eller portparametrene i klientens URL eller GO-Globals logon.html-side.
Load Balancer til netværk
Når der er brug for mere end én Farm Host, er der brug for en load balancer til at fordele brugerforbindelserne mellem hostene. Load balanceren kan være en reverse proxy eller en network load balancer.
I miljøer, hvor der er adgang til flere applikationer via et enkelt internet-endepunkt, vil perimeter-firewallen typisk videresende forbindelser til en reverse proxy (eventuelt via en WAF). Den omvendte proxy kan derefter enten videresende forbindelserne direkte til Farm Hosts (balancere belastningen), eller den kan videresende forbindelserne indirekte til hosts via en netværksbelastningsbalancer.
I miljøer, hvor GO-Global er det eneste program, der er adgang til via internetslutpunktet, kan perimeterfirewallen alternativt videresende forbindelser på port 443 direkte til en netværksbelastningsbalancer. Derfra vælger load balanceren en Farm Host og videresender forbindelsen til Farm Host på den port, der er angivet i Admin Console.
I modsætning til reverse proxies inspicerer network load balancers ikke trafikken og dirigerer den baseret på dataindholdet. De router generelt trafik baseret på variabler som destinationsporten og kildens IP-adresse. Eksempler på load balancere, der kan fungere på lag 4 og route TCP-forbindelser (TLS afsluttes på GO-Global-værter), er HAProxy, Azure load balancer og AWS Network Load Balancer.
Nogle netværksbelastningsbalancere kan afslutte TLS ved belastningsbalanceren. Hvis load balanceren er konfigureret til at afslutte TLS, skal GO-Globals tls-parameter tilføjes til klientens URL, eller den skal angives på GO-Globals logon.html-side.
Når en load balancer afslutter TLS, kan den eventuelt genkryptere de data, den sender til Farm Hosts. Hvis Farm Hosts er konfigureret til at bruge TLS-protokollen, skal load balanceren være konfigureret til at genkryptere de data, den sender til Farm Hosts. Omvendt, hvis load balanceren ikke genkrypterer dataene, skal GO-Globals protokol indstilles til TCP, og kryptering skal indstilles til Ingen.
Når en netværksloadbalancer ikke afslutter TLS, sender den dataene videre til Farm Hosts uden at dekryptere og genkryptere dem. I denne konfiguration skal TLS-protokollen være aktiveret på Farm Hosts, og tls-parameteren må ikke være angivet i klientens URL eller på logon.html-siden.
Back-end firewall
En back-end-firewall kan bruges til at begrænse adgangen til Farm Hosts til specifikke front-end-systemer. Hvis der f.eks. bruges reverse proxies til at route forbindelser til Farm Hosts, kan en back-end-firewall konfigureres til kun at tillade reverse proxies at oprette forbindelse til Farm Hosts. I dette eksempel skal back-end-firewallen konfigureres til at tillade reverse proxyer at oprette forbindelse til Farm Hosts på den port, der er angivet i administratorpanelet under Værktøjer | Værtsindstillinger | Sikkerhed | Port (491, som standard), og trafik skal tillades i begge retninger.
Hvis de programmer, der kører på Farm Hosts, skal have adgang til internettet, skal back-end-firewallen konfigureres til at tillade denne adgang.
GO-Global Farm Hosts kræver ikke adgang til internettet. Men hvis GO-Global er aktiveret med en cloud-licens, skal APS'en på Farm Managers kunne oprette forbindelse til portal.graphon.com og cloud.graphon. com på port 443.
Domænecontroller
I de fleste implementeringer er Farm Hosts medlemmer af et Microsoft Active Directory (AD)-domæne. I dette miljø er det vigtigt for Farm Hosts at opretholde kommunikation med deres domænecontrollere. Denne forbindelse gør det muligt for dem at godkende konti, hente brugeroplysninger og -indstillinger, indlæse roamingprofiler og håndhæve gruppepolitikker. I OpenID Connect-implementeringer er kunderne ofte nødt til at konfigurere begrænset delegering på Farm Hosts' AD-computerobjekter.
Administration Firewall
En administrationsfirewall kan bruges til at begrænse brugernes mulighed for at få adgang til administrationssystemer som f.eks. domænecontrollere og Farm Managers fra Farm Hosts. En administrationsfirewall kan f.eks. bruges til at forhindre brugere, der kører programmer på Farm Hosts, i at forsøge at oprette forbindelse til domænecontrollere og Farm Managers ved hjælp af Fjernskrivebord.
Hvis der findes en administrationsfirewall mellem Farm Hosts og Farm Managers, skal firewallen tillade Farm Hosts at oprette forbindelse til Farm Managers på den port, der er angivet i Admin Console under Tools | Host Options | Security | Port (491, som standard), og trafikken skal være tilladt i begge retninger.
Hvis der findes en administrationsfirewall mellem Farm Hosts og domænecontrollere, skal firewallen konfigureres til al kommunikation på de porte, som Windows bruger til at kommunikere mellem domænecontrollere og domænemedlemmer. Se Microsofts dokumentation for disse oplysninger.
Identitetsudbyder
Når OpenID Connect-godkendelse bruges, skal Farm Hosts kunne åbne forbindelser til identitetsudbyderen via den Token-URL, der er angivet i administratorpanelet under Værktøjer | Værtsindstillinger | Godkendelse | Konfigurer OpenID Connect-indstillinger | Token-URL.
Infrastruktur til automatisk skalering
Cloud Service Providers (CSP'er) som Amazon Web Services (AWS), Microsoft Azure, Oracle Cloud og Google Cloud (GCP) tilbyder funktioner, der kan bruges til automatisk at starte og stoppe Farm Hosts, når belastningen stiger og falder. Når man bruger disse funktioner, opretter administratorer generelt et basisbillede ("guld") af en Farm Host, som kan replikeres efter behov for at understøtte de brugere, der opretter forbindelse til systemet.
Farm Host-billeder har GO-Global installeret og konfigureret samt alle applikationer, som brugerne vil køre på Farm Hosts. Administratorer automatiserer typisk opbygningen af disse images ved hjælp af en kombination af PowerShell-scripts og infrastrukturkode udviklet ved hjælp af et IaC-værktøj (Infrastructure as Code) som Terraform.
Se Automatisering af konfigurationen af GO-Global om, hvordan GO-Global kan installeres og konfigureres programmatisk.
Farm Host-images har typisk adresserne på deres Farm Manager og Failover Farm Manager gemt i imaget. Det gør det nemt at skalere ud (tilføje hosts til en farm). Når nye host-instanser startes, opretter de automatisk forbindelse til Farm Manager, og CSP'ens automatiske skaleringsfunktion sørger normalt for at tilføje den nye instans til load balancerens målgruppe.
Farm Hosts får licenser fra deres Farm Managers, så der kræves ingen licenskonfiguration, når en ny Farm Host-instans starter. Når sessioner starter på en Farm Host, tjekker værten licenspladser ud fra Farm Manageren. Generelt bruges der en plads til hver samtidig session.
At skalere ind (fjerne hosts fra en farm) er generelt lidt mere kompliceret end at skalere ud. Det skyldes, at det normalt er ønskeligt at vente med at lukke en Farm Host-instans ned, indtil alle sessioner, der kører på den, er blevet lukket. At tage en Farm Host offline beskriver, hvordan man gør dette.
Når en Farm Host stopper, afbrydes hostens forbindelse til Farm Manager. Når det sker, frigiver Farm Manager automatisk alle pladser, der var i brug på værten. Der er derfor ingen risiko for, at pladser bliver brugt af værter, der ikke længere eksisterer. Der skal ikke gøres noget for at rydde værter, der er blevet lukket ned; det sker automatisk.
Med GO-Global er den bedste metrik til at kontrollere automatisk skalering generelt antallet af kørende sessioner. Antallet af sessioner, der kører på en host eller en farm, kan fås fra henholdsvis en Farm Host eller Farm Manager via GO-Globals Performance Counters eller via GO-Globals Get-GGSessions PowerShell-funktion.
Tilgængelighedszoner og regioner
For at sikre høj tilgængelighed understøtter Cloud Service Providers (CSP'er) implementeringer med flere datacentre via tilgængelighedszoner og regioner. Tilgængelighedszoner er et eller flere datacentre, der ligger inden for samme geografiske region. CSP-regioner er geografiske områder, der indeholder en eller flere tilgængelighedszoner. CSP Fault Domains, også kendt som tilgængelighedsgrupper, er fejltolerante ressourcer, der er placeret i fysisk adskilte dele af et enkelt datacenter.
GO-Global understøtter implementeringer på tværs af flere tilgængelighedszoner. De tilgængelighedszoner, hvor GO-Global er implementeret, kan være placeret inden for samme CSP-region eller i forskellige CSP-regioner.
Inden for en CSP-region implementeres GO-Global normalt på tværs af mindst to tilgængelighedszoner, hvor den primære Farm Manager kører i én tilgængelighedszone, og failover-Farm Manageren kører i en anden tilgængelighedszone. Farm Hosts kan køre i et vilkårligt antal tilgængelighedszoner inden for regionen, men de skal kunne oprette forbindelse til både den primære Farm Manager og failover-Farm Manageren.
Når der er behov for høj tilgængelighed på tværs af CSP-regioner, eller når brugerne befinder sig rundt omkring i verden, kan GO-Global implementeres i flere CSP-regioner med en DNS-load-balancer som AWS' Route 53, der router klientforbindelser på tværs af regionerne. DNS-loadbalanceren kan derefter konfigureres til at understøtte aktiv-aktiv eller aktiv-passiv failover efter behov.
Værktøjer til overvågning og observerbarhed
Overvågnings- og observerbarhedsværktøjer bruges til at overvåge GO-Global-implementeringernes tilstand og udsende advarsler, når der opstår problemer. GO-Global har flere funktioner, som disse værktøjer kan bruge til at overvåge GO-Global.
De fleste observationsværktøjer har funktioner til indlæsning af logfiler. GO-Globals logfiler er som standard i HTML-format, hvilket de fleste observationsværktøjer ikke understøtter. Derfor skal GO-Global generelt konfigureres til at registrere sine logfiler i tekstformat, når logfilerne skal indtastes af et observerbarhedsværktøj.
Ud over logfilerne registrerer GO-Global hændelser i Windows-programloggen. De hændelser, som GO-Global registrerer i Windows-programloggen, omfatter sessionsstart og -stop, brugertilmeldinger og programstart og -stop.
For at understøtte overvågning af Farm Hosts og Farm Managers leverer GO-Global en healthCheck-anmodning. HealthCheck-anmodningen kan bruges til at afgøre, om Application Publishing Service kører på en Farm Host eller Farm Manager, og eventuelt om systemet er i stand til at oprette en session. Load balancere kan f.eks. bruge healthCheck-anmodningen til at kontrollere tilstanden af Farm Hosts i deres målgruppe.
Systemer, der sender healthCheck-anmodninger, skal være registreret hos hver target Farm Host eller Farm Manager. Specifikt skal IP-adressen på det system, der sender anmodningen, være angivet i CIDR-format i egenskaben APIWhiteList i målsystemets HostProperties.xml-fil.
Ud over disse værktøjer kan GO-Globals PowerShell API bruges til at få detaljerede oplysninger om køretid fra Farm Hosts og Farm Managers. For eksempel returnerer funktionen Get-GGSessions oplysninger om de sessioner, der kører på en Farm Host eller Farm Manager.
Konklusion
Implementering af GO-Global i et stort eller cloud-integreret miljø kræver omhyggelig koordinering mellem flere infrastrukturkomponenter. Ved at konfigurere elementer som firewalls, load balancers, reverse proxies og overvågningssystemer korrekt kan administratorer opnå et sikkert, skalerbart og højtydende GO-Global-miljø, der giver en problemfri brugeroplevelse.
Uanset om GO-Global implementeres lokalt, i skyen eller på tværs af hybridarkitekturer, sikrer de principper, der beskrives i denne artikel, at GO-Global fungerer effektivt i moderne virksomhedsnetværk - og opretholder pålidelighed, fleksibilitet og kontrol i alle implementeringslag.
Er du en ISV, der udforsker cloud-baseret applikationslevering? Kontakt os for at høre, hvordan GO-Global kan hjælpe dig med at strømline adgangen til software for dine slutbrugere. Eller download en gratis prøveversion for at teste det selv.
