Go-globala utrullningar
Storskaliga GO-Global-implementeringar sträcker sig ofta långt bortom Farm Hosts och Farm Managers. I företagsmiljöer fungerar de vanligtvis tillsammans med många stödsystem som är utformade för att förbättra prestanda, tillförlitlighet och säkerhet. Dessa system - inklusive brandväggar, lastutjämnare, brandväggar för webbapplikationer (WAF), omvända proxyer och övervakningsverktyg - säkerställer att GO-Global-applikationer förblir tillgängliga, motståndskraftiga och uppfyller organisationens standarder.
Den här artikeln ger detaljerad vägledning om hur du konfigurerar GO-Global för att fungera effektivt inom komplexa IT-infrastrukturer som innehåller sådana komponenter. Den förklarar hur GO-Global samverkar med varje system, beskriver bästa praxis för konfiguration och belyser viktiga överväganden för administratörer som hanterar storskaliga eller molnbaserade implementeringar.
Perimeter-brandvägg
När en GO-Global-distribution är tillgänglig från internet är en perimeterbrandvägg i allmänhet den första försvarslinjen mot intrång. Perimeterbrandväggar är vanligtvis konfigurerade för att tillåta inkommande anslutningar på TCP-port 443, som är standardporten för säker HTTPS/TLS-trafik.
Eftersom port 443 är standardporten för säker trafik och eftersom det är den port som är öppen i de flesta företags (klienters) brandväggar, konfigureras GO-Global-klienter som ansluter via internet vanligtvis att ansluta till port 443 istället för GO-Globals standardport, 491. Detta görs antingen genom att lägga till porten i URL:en (t.ex. &port=443) eller genom att ange porten på GO-Globals logon.html-sida.
Brandvägg för webbapplikationer (WAF)
En WAF (Web Application Firewall) analyserar inkommande HTTP-förfrågningar för att identifiera och blockera skadliga förfrågningar. WAF:er kan också dirigera trafik till olika backend-servrar baserat på information i HTTP-förfrågningar, men detta är inte deras primära funktion. Deras primära funktion är att tillhandahålla säkerhet och skydda mot attacker som t.ex. DDoS-attacker (distributed denial of service).
Exempel på WAF:s är Cloudflare WAF, AWS WAF (Amazon Web Services), Azure Web Application Firewall, F5 Advanced WAF, Imperva WAF, Akamai Kona Site Defender, Fortinet FortiWeb, Barracuda WAF och Radware WAF.
För att analysera HTTPS-trafik måste WAF:er avsluta TLS så att de kan dekryptera förfrågningarna. När TLS avslutas av en WAF måste GO-Globals tls-parameter läggas till i klientens URL eller anges på GO-Globals logon.html-sida.
En annan faktor att ta hänsyn till när det gäller GO-Global-trafik är att WAF inte kan analysera GO-Globals egenutvecklade RXP-protokoll. När kommunikationen mellan en GO-Global-klient och -värd passerar genom en WAF måste den därför antingen paketeras i HTTP-förfrågningar genom att GO-Global konfigureras att använda en Websocket, eller så måste WAF:s dataanalysfunktioner inaktiveras för GO-Global-trafiken.
Alla GO-Global-klienter i version 6.3.3 och senare har stöd för WebSockets. I GO-Global-versionerna 6.3.2 och tidigare är det dock bara GO-Global Web App som stöder WebSockets. AppController, GO-Globals inbyggda klient, har inte stöd för WebSockets i version 6.3.2 och tidigare.
Om AppController version 6.3.2 eller tidigare används med ett WAF måste miljön konfigureras så att WAF inte inspekterar AppControllers trafik. Detta kan t.ex. göras genom att tillhandahålla en annan slutpunkt (offentlig adress) för AppController-anslutningar som inte använder WAF, eller genom att konfigurera AppController att ansluta på en annan port och konfigurera WAF att skicka trafik på denna port utan att inspektera den.
Omvänd proxy
Liksom WAF:er analyserar omvända proxyer inkommande HTTP-förfrågningar. Omvända proxyer har vissa säkerhetsfunktioner, men till skillnad från WAF är den primära funktionen för omvända proxyer trafikhantering, inte säkerhet. Omvända proxyservrar används t.ex. ofta när flera webbapplikationer och tjänster tillhandahålls från samma offentliga slutpunkt. De dirigerar inkommande förfrågningar för olika applikationer till deras respektive applikationsservrar. De kan också användas som lastbalanserare för GO-Global Farm Hosts.
Exempel på omvända proxyer är Nginx, Apache HTTP Server, HAProxy, Traefik och Cloudflare. AWS Application Load Balancer och Azure Application Gateway har olika funktioner, varav en inkluderar att fungera som en omvänd proxy.
Precis som WAF:er måste omvända proxyservrar avsluta TLS så att de kan analysera inkommande HTTP-förfrågningar. När TLS avslutas av en omvänd proxy måste GO-Globals tls-parameter läggas till i klientens URL eller anges på GO-Globals logon.html-sida, precis som med WAF.
Liksom WAF:er kan omvända proxyservrar inte analysera GO-Globals egenutvecklade RapidX Protocol (RXP). När kommunikationen mellan en GO-Global-klient och -värd går via en omvänd proxy måste den därför, precis som med en WAF, antingen paketeras i HTTP-förfrågningar genom att GO-Global konfigureras att använda en WebSocket, eller så måste den omvända proxyns dataanalysfunktioner inaktiveras för GO-Global-trafiken.
Och som med ett WAF, om AppController version 6.3.2 eller tidigare används med en omvänd proxy, måste miljön konfigureras så att WAF inte inspekterar AppControllers trafik. Detta kan till exempel göras genom att tillhandahålla en annan slutpunkt (offentlig adress) för AppController-anslutningar som inte använder den omvända proxyn, eller genom att konfigurera AppController för att ansluta på en annan port och konfigurera den omvända proxyn för att skicka trafik på den här porten utan att inspektera den.
Webbserver
GO-Global-värdar har en integrerad webbserver som kan vara värd för GO-Globals webbapp och dess stödjande HTML- och JavaScript-filer. När GO-Globals integrerade webbserver används vidarebefordras HTTP-förfrågningar om GO-Globals webbfiler till GO-Global Farm Hosts i det interna nätverket.
I internetdistributioner finns det dock säkerhetsfördelar med att hosta GO-Globals webbfiler på en webbserver från tredje part som ligger i DMZ. Exempel på webbservrar från tredje part är Apache HTTP Server, Nginx och Microsoft IIS (Internet Information Services).
När en webbserver från tredje part används måste GO-Globals webbapp och tillhörande filer installeras på webbservern, antingen via Host Installer eller genom att kopiera innehållet i GO-Globals webbkatalog till webbservern.
Även om de flesta webbservrar från tredje part har funktioner för att hantera WebSocket-anslutningar, hanteras WebSocket-anslutningar i allmänhet av en dedikerad lastbalanserare eller omvänd proxy. Administratörer kan konfigurera WAF:er och omvända proxyer för att dirigera GO-Globals HTTP-förfrågningar till en webbserver och för att dirigera WebSocket-anslutningar till GO-Global Farm Hosts eller till en lastbalanserare.
Alternativt, när en WAF eller omvänd proxy inte används, kan administratörer skapa en annan slutpunkt (adress eller port) för GO-Globals WebSocket-anslutningar och ange denna slutpunkt via värd- och/eller portparametrarna i klientens URL eller GO-Globals logon.html-sida.
Lastbalanserare för nätverk
När det behövs mer än en Farm Host krävs en lastbalanserare för att distribuera användaranslutningar mellan värdarna. Lastbalanseraren kan vara en omvänd proxy eller en nätverkslastbalanserare.
I miljöer där flera applikationer nås via en enda Internet-endpoint vidarebefordrar den perimeterbaserade brandväggen vanligtvis anslutningar till en omvänd proxy (eventuellt via en WAF). Den omvända proxyn kan sedan antingen vidarebefordra anslutningarna direkt till Farm Hosts (balansera belastningen) eller vidarebefordra anslutningarna indirekt till Hosts via en lastbalanserare för nätverket.
Alternativt, i miljöer där GO-Global är den enda applikation som nås via Internet-ändpunkten, kan den yttre brandväggen vidarebefordra anslutningar på port 443 direkt till en nätverkslastbalanserare. Därifrån väljer lastbalanseraren en Farm Host och vidarebefordrar anslutningen till Farm Host på den port som anges i Admin Console.
Till skillnad från omvända proxyer inspekterar inte nätverkslastbalanserare trafiken och dirigerar den baserat på datainnehållet. De dirigerar i allmänhet trafiken baserat på variabler som destinationsport och källans IP-adress. Exempel på lastbalanserare som kan arbeta i lager 4 och dirigera TCP-anslutningar (TLS avslutas på GO-Global-värdar) är HAProxy, Azure Load Balancer och AWS Network Load Balancer.
Vissa nätverkslastutjämnare kan avsluta TLS vid lastutjämnaren. Om lastbalanseraren är konfigurerad att avsluta TLS måste GO-Globals tls-parameter läggas till i klientens URL, eller så måste den anges på GO-Globals sida logon.html.
När en lastbalanserare avslutar TLS kan den eventuellt återkryptera de data som den överför till Farmvärdar. Om gårdsvärdarna är konfigurerade att använda TLS-protokollet måste lastbalanseraren vara konfigurerad att kryptera om de data som den skickar till gårdsvärdarna. Om lastbalanseraren däremot inte krypterar data måste GO-Globals protokoll ställas in på TCP och kryptering ställas in på None.
När en nätverkslastutjämnare inte avslutar TLS skickas data vidare till Värdland på gården utan att dekrypteras och krypteras på nytt. I den här konfigurationen måste TLS-protokollet vara aktiverat på Värdlandsfarm och parameterntls får inte anges i klientens URL eller på sidan logon.html.
Brandvägg för back-end
En back-end-brandvägg kan användas för att begränsa åtkomsten till Värdgårdar för specifika front-end-system. Om t.ex. omvända proxyservrar används för att dirigera anslutningar till värdfarmar kan en backend-brandvägg konfigureras så att den endast tillåter omvända proxyservrar att ansluta till värdfarmarna. I det här exemplet måste backend-brandväggen konfigureras så att de omvända proxyservrarna kan ansluta till Värdgårdar på den port som anges i adminkonsolen under Verktyg | Värdalternativ | Säkerhet | Port (491, som standard), och trafik måste tillåtas i båda riktningarna.
Om de program som körs på Farm Hosts måste ha åtkomst till Internet måste backend-brandväggen konfigureras så att den tillåter denna åtkomst.
GO-Global Farm Hosts kräver inte tillgång till internet. Om GO-Global däremot aktiveras med en molnlicens måste APS:en på Farm Managers kunna ansluta till portal.graphon.com och cloud.graphon. com på port 443.
Domänkontrollant
I de flesta installationer är Farm Hosts medlemmar i en Microsoft Active Directory (AD)-domän. I den här miljön är det viktigt att värddatorfarmarna upprätthåller kommunikation med sina domänkontrollanter. Denna anslutning gör det möjligt för dem att autentisera konton, hämta användarinformation och inställningar, ladda roamingprofiler och tillämpa grupprinciper. I OpenID Connect-distributioner krävs ofta att kunderna konfigurerar begränsad delegering på gårdsvärdarnas AD-datorobjekt.
Administration Brandvägg
En administrationsbrandvägg kan användas för att begränsa användarnas möjlighet att komma åt administrationssystem som domänkontrollanter och gårdshanterare från gårdsvärdar. En administrationsbrandvägg kan t.ex. användas för att förhindra att användare som kör program på Värdlandsfarm försöker ansluta till domänkontrollanter och Farm Managers med hjälp av Fjärrskrivbord.
Om det finns en administrationsbrandvägg mellan Farm Hosts och Farm Managers måste brandväggen tillåta Farm Hosts att ansluta till Farm Managers på den port som anges i Admin Console under Tools | Host Options | Security | Port (491, som standard), och trafik måste tillåtas i båda riktningarna.
Om det finns en administrationsbrandvägg mellan Farmvärdar och domänkontrollanter måste brandväggen konfigureras för all kommunikation på de portar som Windows använder för att kommunicera mellan domänkontrollanter och domänmedlemmar. Se Microsofts dokumentation för den här informationen.
Identitetsleverantör
När OpenID Connect Authentication används måste Farm Hosts kunna öppna anslutningar till identitetsleverantören via den Token URL som anges i Admin Console under Tools | Host Options | Authentication | Configure OpenID Connect Settings | Token URL.
Infrastruktur för automatisk skalning
Cloud Service Providers (CSP) som Amazon Web Services (AWS), Microsoft Azure, Oracle Cloud och Google Cloud (GCP) tillhandahåller funktioner som kan användas för att automatiskt starta och stoppa Farm Hosts när belastningen ökar och minskar. När dessa funktioner används skapar administratörer i allmänhet en basavbildning ("guldavbildning") av en värddatorfarm som kan replikeras efter behov för att stödja de användare som ansluter till systemet.
Farm Host-avbildningar har GO-Global installerat och konfigurerat, liksom alla applikationer som användare kommer att köra på Farm Hosts. Administratörer automatiserar vanligtvis byggandet av dessa avbildningar med hjälp av en kombination av PowerShell-skript och infrastrukturkod som utvecklats med ett IaC-verktyg (Infrastructure as Code) som Terraform.
Se Automatisera konfigurationen av GO-Global för information om hur GO-Global kan installeras och konfigureras programmatiskt.
Farmvärdsavbildningar har vanligtvis adresserna till sin Farm Manager och Failover Farm Manager lagrade i avbildningen. Detta gör det enkelt att skala ut (lägga till värddatorer i en farm). När nya värddatorinstanser startas ansluter de automatiskt till Farm Manager, och CSP:ns funktion för automatisk skalning tar i allmänhet hand om att lägga till den nya instansen i lastbalanserarens målgrupp.
Farm Hosts får licenser från sina Farm Managers, så ingen licenskonfiguration krävs när en ny Farm Host-instans startar. När sessioner startar på en Farm Host checkar värden ut licensplatser från Farm Manager. I allmänhet förbrukas en plats för varje samtidig session.
Att skala in (ta bort värdar från en farm) är i allmänhet lite mer komplicerat än att skala ut. Detta beror på att det vanligtvis är önskvärt att vänta med att stänga av en Farm Host-instans tills alla sessioner som körs på den har stängts. Att ta en Farm Host offline beskriver hur man gör detta.
När en Farm Host stoppas bryts hostens anslutning till Farm Manager. När detta sker frigör Farm Manager automatiskt alla platser som användes på värddatorn. Det finns alltså ingen risk för att platser förbrukas av värdar som inte längre finns. Inget behöver göras för att rensa bort värddatorer som har stängts av; detta görs automatiskt.
Med GO-Global är det bästa måttet för att kontrollera automatisk skalning i allmänhet antalet sessioner som körs. Antalet sessioner som körs på en värd eller en farm kan erhållas från en farmvärd respektive farmhanterare via GO-Globals prestandaräknare eller via GO-Globals PowerShell-funktion Get-GGSessions.
Tillgänglighetszoner och regioner
För att tillhandahålla hög tillgänglighet stöder molntjänstleverantörer (CSP) distributioner med flera datacenter via tillgänglighetszoner och regioner. Tillgänglighetszoner är ett eller flera datacenter som ligger inom samma geografiska region. CSP-regioner är geografiska områden som innehåller en eller flera tillgänglighetszoner. CSP Fault Domains, även kända som tillgänglighetsgrupper, är feltoleranta resurser som finns i fysiskt separata delar av ett enda datacenter.
GO-Global stöder driftsättningar över flera tillgänglighetszoner. De tillgänglighetszoner där GO-Global distribueras kan vara belägna inom samma CSP-region eller i olika CSP-regioner.
Inom en CSP-region distribueras GO-Global i allmänhet över minst två tillgänglighetszoner, där den primära Farm Manager körs i en tillgänglighetszon och den reservdriftsansvariga Farm Manager körs i en annan tillgänglighetszon. Farmvärdarna kan köras i ett valfritt antal tillgänglighetszoner inom regionen, men de måste kunna ansluta till både den primära Farm Manager och den reservdriftsansvariga Farm Manager.
När det krävs hög tillgänglighet mellan CSP-regioner, eller när användare finns runt om i världen, kan GO-Global distribueras i flera CSP-regioner med en DNS-lastfördelare, t.ex. AWS Route 53, som dirigerar klientanslutningar mellan regionerna. DNS-lastbalanseraren kan sedan konfigureras för att stödja aktiv-aktiv eller aktiv-passiv failover, efter behov.
Verktyg för övervakning och observerbarhet
Övervaknings- och observerbarhetsverktyg används för att övervaka GO-Global-distributionernas hälsa och utfärda varningar när problem uppstår. GO-Global tillhandahåller flera funktioner som dessa verktyg kan använda för att övervaka GO-Global.
De flesta observerbarhetsverktyg har funktioner för att ta in loggfiler. GO-Globals loggfiler är som standard i HTML-format, vilket de flesta observabilitetsverktyg inte stöder. Därför måste GO-Global i allmänhet konfigureras för att registrera sina loggfiler i textformat när loggarna ska läsas in av ett observationsverktyg.
Förutom sina loggfiler registrerar GO-Global händelser i Windows Application-loggen. De händelser som GO-Global registrerar i Windows Application-loggen inkluderar sessionsstarter och -stopp, användarinloggningar och programstarter och -stopp.
För att stödja övervakning av Farm Hosts och Farm Managers tillhandahåller GO-Global en healthCheck-begäran. HealthCheck-begäran kan användas för att avgöra om Application Publishing Service körs på en Farm Host eller Farm Manager och, som tillval, om systemet kan skapa en session. Lastbalanserare kan t.ex. använda healthCheck-begäran för att kontrollera hälsan hos Farm Hosts i sin målgrupp.
System som skickar healthCheck-begäranden måste vara registrerade hos varje mål-Farmvärd eller Farmhanterare. Specifikt måste IP-adressen för det system som skickar begäran listas i CIDR-format i APIWhiteList-egenskapen i målsystemets HostProperties.xml-fil.
Utöver dessa verktyg kan GO-Globals PowerShell API användas för att få detaljerad körtidsinformation från Farm Hosts och Farm Managers. Funktionen Get-GGSessions returnerar till exempel information om de sessioner som körs på en Farm Host eller Farm Manager.
Slutsats
Att distribuera GO-Global i en storskalig eller molnintegrerad miljö kräver noggrann samordning mellan flera infrastrukturkomponenter. Genom att korrekt konfigurera element som brandväggar, lastbalanserare, omvända proxyer och övervakningssystem kan administratörer uppnå en säker, skalbar och högpresterande GO-Global-miljö som ger en sömlös användarupplevelse.
Oavsett om GO-Global implementeras lokalt, i molnet eller i hybridarkitekturer, säkerställer de principer som beskrivs i den här artikeln att GO-Global fungerar effektivt i moderna företagsnätverk - med bibehållen tillförlitlighet, flexibilitet och kontroll i varje lager av distributionen.
Är du en ISV som utforskar molnbaserad applikationsleverans? Kontakta oss för att få veta hur GO-Global kan hjälpa dig att effektivisera programvarutillgången för dina slutanvändare. Eller ladda ner en gratis testversion för att testa själv.
