Globale distribusjoner
Storskala GO-Global-distribusjoner strekker seg ofte langt utover farmverter og farmadministratorer. I bedriftsmiljøer opererer de vanligvis sammen med en rekke støttesystemer som er utviklet for å forbedre ytelse, pålitelighet og sikkerhet. Disse systemene – inkludert brannmurer, lastbalansere, webapplikasjonsbrannmurer (WAF-er), omvendte proxyer og overvåkingsverktøy – sikrer at GO-Global-applikasjoner forblir tilgjengelige, robuste og i samsvar med organisasjonsstandarder.
Denne artikkelen gir detaljert veiledning om hvordan du konfigurerer GO-Global til å fungere effektivt i komplekse IT-infrastrukturer som inkluderer slike komponenter. Den forklarer hvordan GO-Global samhandler med hvert system, skisserer beste praksis for konfigurasjon og fremhever viktige hensyn for administratorer som administrerer storskala eller skybaserte distribusjoner.
Perimeterbrannmur
Når en GO-Global-distribusjon er tilgjengelig fra internett, er en perimeterbrannmur vanligvis den første forsvarslinjen mot inntrenging. Perimeterbrannmurer er vanligvis konfigurert til å tillate innkommende tilkoblinger på TCP-port 443, som er standardporten for sikker HTTPS/TLS-trafikk.
Siden port 443 er standardporten for sikker trafikk, og siden det er porten som er åpen på de fleste bedrifts- (klient-) brannmurer, er GO-Global-klienter som kobler seg til over internett vanligvis konfigurert til å koble til port 443 i stedet for GO-Globals standardport, 491. Dette gjøres enten ved å legge til porten i URL-en (f.eks. &port=443) eller ved å spesifisere porten på GO-Globals logon.html-side .
Brannmur for nettapplikasjoner (WAF)
En Web Application Firewall (WAF) analyserer innkommende HTTP-forespørsler for å identifisere og blokkere ondsinnede forespørsler. WAF-er kan også rute trafikk til forskjellige backend-servere basert på informasjon i HTTP-forespørsler, men dette er ikke deres primære funksjon. Deres primære funksjon er å gi sikkerhet og beskytte mot angrep som distribuert denial of service (DDoS)-angrep.
Eksempler på WAF-er inkluderer 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 å analysere HTTPS-trafikk må WAF-er avslutte TLS slik at de kan dekryptere forespørslene. Når TLS avsluttes av en WAF, må GO-Globals tls- parameter legges til klientens URL, eller den må spesifiseres på GO-Globals logon.html-side .
En annen faktor å ta hensyn til GO-Global-trafikk er at WAF-er ikke kan analysere GO-Globals proprietære RXP-protokoll. Derfor, når kommunikasjon mellom en GO-Global-klient og vert går gjennom en WAF, må den enten pakkes inn i HTTP-forespørsler ved å konfigurere GO-Global til å bruke en Websocket , eller WAF-ens dataanalysefunksjoner må deaktiveres for GO-Global-trafikken.
Alle GO-Global-klienter med versjon 6.3.3 og nyere støtter WebSockets. I GO-Global versjon 6.3.2 og tidligere støtter imidlertid bare GO-Global Web App WebSockets. AppController, GO-Globals innebygde klient, støtter ikke WebSockets i versjon 6.3.2 og tidligere.
Hvis AppController versjon 6.3.2 eller tidligere brukes med en WAF, må miljøet konfigureres slik at WAF ikke inspiserer AppControllers trafikk. Dette kan for eksempel gjøres ved å oppgi et annet endepunkt (offentlig adresse) for AppController-tilkoblinger som ikke bruker WAF, eller ved å konfigurere AppController til å koble til på en annen port og konfigurere WAF til å sende trafikk på denne porten uten å inspisere den.
Omvendt proxy
I likhet med WAF-er analyserer omvendte proxyer innkommende HTTP-forespørsler. Omvendte proxyer har noen sikkerhetsfunksjoner, men i motsetning til WAF-er er hovedfunksjonen til omvendte proxyer trafikkstyring, ikke sikkerhet. For eksempel brukes omvendte proxyer ofte når flere webapplikasjoner og tjenester leveres fra samme offentlige endepunkt. De ruter innkommende forespørsler for forskjellige applikasjoner til sine respektive applikasjonsservere. De kan også brukes som en lastbalanserer for GO-Global Farm Hosts.
Eksempler på reverse proxyer inkluderer Nginx, Apache HTTP Server, HAProxy, Traefik og Cloudflare. AWS Application Load Balancer og Azure Application Gateway har forskjellige funksjoner, hvorav én inkluderer å fungere som en reverse proxy.
I likhet med WAF-er må reverse proxyer avslutte TLS slik at de kan analysere innkommende HTTP-forespørsler. Som med WAF-er, må GO-Globals tls- parameter legges til klientens URL, eller den må spesifiseres på GO-Globals logon.html-side når TLS avsluttes av en reverse proxy.
I likhet med WAF-er kan ikke reverse proxyer analysere GO-Globals proprietære RapidX Protocol (RXP) . Derfor, som med en WAF, må kommunikasjon mellom en GO-Global-klient og vert gå gjennom en reverse proxy enten pakkes inn i HTTP-forespørsler ved å konfigurere GO-Global til å bruke en WebSocket , eller så må den reverse proxyens dataanalysefunksjoner deaktiveres for GO-Global-trafikken.
Og som med en WAF, hvis AppController versjon 6.3.2 eller tidligere brukes med en omvendt proxy, må miljøet konfigureres slik at WAF ikke inspiserer AppControllers trafikk. Dette kan for eksempel gjøres ved å oppgi et annet endepunkt (offentlig adresse) for AppController-tilkoblinger som ikke bruker omvendt proxy, eller ved å konfigurere AppController til å koble til på en annen port og konfigurere den omvendte proxyen til å sende trafikk på denne porten uten å inspisere den.
Webserver
GO-Global Hosts har en integrert webserver som kan være vert for GO-Global Web App og dens støttende HTML- og JavaScript-filer. Når GO-Globals integrerte webserver brukes, videresendes HTTP-forespørsler for GO-Globals webfiler til GO-Global Farm Hosts på det interne nettverket.
Ved internettdistribusjoner er det imidlertid sikkerhetsfordeler ved å være vert for GO-Globals webfiler på en tredjeparts webserver som ligger i DMZ. Eksempler på tredjeparts webservere inkluderer Apache HTTP Server, Nginx og Microsoft IIS (Internet Information Services).
Når en tredjeparts webserver brukes, må GO-Globals webapp og tilhørende filer installeres på webserveren , enten via Host-installasjonsprogrammet eller ved å kopiere innholdet i GO-Globals webkatalog til webserveren.
Selv om de fleste tredjeparts webservere har funksjonalitet for å håndtere WebSocket-tilkoblinger, håndteres WebSocket-tilkoblinger vanligvis av en dedikert lastbalanserer eller omvendt proxy. Administratorer kan konfigurere WAF-er og omvendte proxyer til å rute GO-Globals HTTP-forespørsler til en webserver og til å rute WebSocket-tilkoblinger til GO-Global Farm Hosts eller til en lastbalanserer.
Alternativt, når en WAF eller omvendt proxy ikke brukes, kan administratorer opprette et annet endepunkt (adresse eller port) for GO-Globals WebSocket-tilkoblinger og spesifisere dette endepunktet via verts- og/eller portparameterne i klientens URL eller GO-Globals logon.html-side .
Nettverksbelastningsfordeler
Når det er behov for mer enn én Farm Host, kreves det en lastfordeler for å fordele brukertilkoblinger mellom vertene. Lastfordeleren kan være en omvendt proxy eller en nettverkslastfordeler.
I miljøer der flere applikasjoner nås via et enkelt internett-endepunkt, vil perimeterbrannmuren vanligvis videresende tilkoblinger til en omvendt proxy (valgfritt via en WAF). Den omvendte proxyen kan deretter enten videresende tilkoblingene direkte til Farm Hosts (balansere belastningen), eller den kan videresende tilkoblingene indirekte til vertene via en nettverksbelastningsfordeler.
Alternativt, i miljøer der GO-Global er det eneste programmet som nås via internett-endepunktet, kan perimeterbrannmuren videresende tilkoblinger på port 443 direkte til en nettverksbelastningsfordeler. Derfra velger belastningsfordeleren en farmvert og videresender tilkoblingen til farmverten på porten som er angitt i administrasjonskonsollen.
I motsetning til omvendte proxyer, inspiserer ikke nettverkslastbalansører trafikk og ruter den basert på datainnholdet. De ruter vanligvis trafikk basert på variabler som destinasjonsport og kilde-IP-adresse. Eksempler på lastbalansører som kan operere på lag 4 og rute TCP-tilkoblinger (TLS avsluttes hos GO-Global-verter) er HAProxy, Azure load balancer og AWS Network Load Balancer.
Noen nettverkslastfordelere kan avslutte TLS hos lastfordeleren. Hvis lastfordeleren er konfigurert til å avslutte TLS, må GO-Globals tls- parameter legges til klientens URL, eller den må spesifiseres på GO-Globals logon.html-side .
Når en lastbalanserer avslutter TLS, kan den eventuelt kryptere dataene den sender til Farm Hosts på nytt. Hvis Farm Hosts er konfigurert til å bruke TLS-protokollen , må lastbalansereren konfigureres til å kryptere dataene den sender til Farm Hosts på nytt. Hvis lastbalansereren derimot ikke krypterer dataene på nytt, må GO-Globals protokoll settes til TCP og kryptering må settes til None .
Når en nettverksbelastningsfordeler ikke avslutter TLS, sender den dataene videre til Farm Hosts uten å dekryptere og kryptere dem på nytt. I denne konfigurasjonen må TLS-protokollen være aktivert på Farm Hosts, og tls- parameteren må ikke spesifiseres i klient-URL-en eller logon.html-siden.
Backend-brannmur
En backend-brannmur kan brukes til å begrense tilgangen til Farm Hosts til bestemte frontend-systemer. Hvis for eksempel omvendte proxyer brukes til å rute tilkoblinger til Farm Hosts, kan en backend-brannmur konfigureres til å bare tillate omvendte proxyer å koble til Farm Hosts. I dette eksemplet må backend-brannmuren konfigureres til å tillate omvendte proxyer å koble til Farm Hosts på porten som er angitt i administrasjonskonsollen under Verktøy | Vertsalternativer | Sikkerhet | Port (491, som standard), og trafikk må tillates i begge retninger.
Hvis applikasjonene som kjører på Farm Hosts må ha tilgang til internett, må bakre brannmur konfigureres til å tillate denne tilgangen.
GO-Global Farm Hosts krever ikke internettilgang. Hvis GO-Global derimot aktiveres med en skylisens, må APS-en på Farm Managers kunne koble til portal.graphon.com og cloud.graphon.com på port 443.
Domenekontroller
I de fleste distribusjoner er Farm Hosts medlemmer av et Microsoft Active Directory (AD)-domene. I dette miljøet er det viktig for Farm Hosts å opprettholde kommunikasjon med domenekontrollerne sine. Denne tilkoblingen lar dem autentisere kontoer, hente brukerinformasjon og innstillinger, laste inn Roaming-profiler og håndheve gruppepolicyer. I OpenID Connect-distribusjoner må kunder ofte konfigurere begrenset delegering på AD-datamaskinobjektene til Farm Hosts.
Administrasjonsbrannmur
En administrasjonsbrannmur kan brukes til å begrense brukernes mulighet til å få tilgang til administrasjonssystemer som domenekontrollere og farmadministratorer fra farmverter. For eksempel kan en administrasjonsbrannmur brukes til å forhindre at brukere som kjører applikasjoner på farmverter prøver å koble til domenekontrollere og farmadministratorer ved hjelp av eksternt skrivebord.
Hvis det finnes en administrasjonsbrannmur mellom farmverter og farmadministratorer, må brannmuren tillate farmverter å koble til farmadministratorene på porten som er angitt i administrasjonskonsollen under Verktøy | Vertsalternativer | Sikkerhet | Port (491, som standard), og trafikk må tillates i begge retninger.
Hvis det finnes en administrasjonsbrannmur mellom farmverter og domenekontrollere, må brannmuren konfigureres til all kommunikasjon på portene som Windows bruker til å kommunisere mellom domenekontrollere og domenemedlemmer. Se Microsofts dokumentasjon for denne informasjonen.
Identitetsleverandør
Når OpenID Connect-autentisering brukes, må farmverter kunne åpne tilkoblinger til identitetsleverandøren via token-URL-en som er angitt i administrasjonskonsollen under Verktøy | Vertsalternativer | Autentisering | Konfigurer OpenID Connect-innstillinger | Token-URL.
Autoskalerende infrastruktur
Skytjenesteleverandører (CSP-er) som Amazon Web Services (AWS), Microsoft Azure, Oracle Cloud og Google Cloud (GCP) tilbyr funksjoner som kan brukes til å automatisk starte og stoppe Farm Hosts når belastningen øker og synker. Når administratorer bruker disse funksjonene, oppretter de vanligvis et basisbilde ("gull") av en Farm Host som kan replikeres etter behov for å støtte brukerne som kobler seg til systemet.
Farm Host-avbildninger har GO-Global installert og konfigurert, i tillegg til alle applikasjoner som brukere kjører på Farm Hosts. Administratorer automatiserer vanligvis byggingen av disse avbildningene ved hjelp av en kombinasjon av PowerShell-skript og infrastrukturkode utviklet med et Infrastructure as Code (IaC)-verktøy som Terraform.
Se Automatisering av konfigurasjonen av GO-Global for informasjon om hvordan GO-Global kan installeres og konfigureres programmatisk.
Farm Host-avbildninger har vanligvis adressene til Farm Manager og Failover Farm Manager lagret i avbildningen. Dette gjør det enkelt å skalere ut (legge til verter i en farm). Når nye vertinstanser startes, kobler de seg automatisk til Farm Manager, og CSP-ens automatiske skaleringsfunksjon tar seg vanligvis av å legge til den nye instansen i lastfordelerens målgruppe.
Farmverter får lisenser fra sine farmadministratorer, så ingen lisenskonfigurasjon er nødvendig når en ny farmvert-instans starter. Når økter starter på en farmvert, sjekker verten ut lisensplasser fra farmadministratoren. Vanligvis brukes ett sete for hver samtidige økt.
Innskalering (fjerning av verter fra en farm) er vanligvis litt mer komplisert enn utskalering. Dette er fordi det vanligvis er ønskelig å vente med å slå av en Farm Host-instans til alle økter som kjører på den, er lukket. Å koble en Farm Host fra beskriver hvordan du gjør dette.
Når en Farm Host stopper, brytes vertens forbindelse til Farm Manager. Når dette skjer, frigir Farm Manager automatisk alle plasser som var i bruk på verten. Dermed er det ingen risiko for at plasser blir brukt av verter som ikke lenger eksisterer. Ingenting trenger å gjøres for å tømme verter som har blitt stengt; dette gjøres automatisk.
Med GO-Global er den beste målingen for å kontrollere automatisk skalering vanligvis antall kjørende økter. Antall økter som kjører på en vert eller en farm kan hentes fra henholdsvis en farmvert eller farmadministrator via GO-Globals ytelsestellere eller via GO-Globals PowerShell-funksjon Get-GGSessions .
Tilgjengelighetssoner og -regioner
For å gi høy tilgjengelighet støtter skytjenesteleverandører (CSP-er) distribusjon av flere datasentre via tilgjengelighetssoner og regioner. Tilgjengelighetssoner er ett eller flere datasentre som ligger innenfor samme geografiske region. CSP-regioner er geografiske områder som inneholder én eller flere tilgjengelighetssoner. CSP-feildomener, også kjent som tilgjengelighetsgrupper, er feiltolerante ressurser som ligger i fysisk separate deler av et enkelt datasenter.
GO-Global støtter distribusjoner på tvers av flere tilgjengelighetssoner. Tilgjengelighetssonene der GO-Global distribueres kan befinne seg innenfor samme CSP-region eller i forskjellige CSP-regioner.
Innenfor en CSP-region distribueres GO-Global vanligvis på tvers av minst to tilgjengelighetssoner, der den primære Farm Manager kjører i én tilgjengelighetssone, og failover Farm Manager kjører i en annen tilgjengelighetssone. Farm Hosts kan kjøre i et hvilket som helst antall tilgjengelighetssoner i regionen, men de må kunne koble til både den primære Farm Manager og failover Farm Manager.
Når det er behov for høy tilgjengelighet på tvers av CSP-regioner, eller når brukere befinner seg rundt om i verden, kan GO-Global distribueres i flere CSP-regioner med en DNS-lastfordeler, for eksempel AWS' Route 53, som ruter klientforbindelser på tvers av regionene. DNS-lastfordeleren kan deretter konfigureres til å støtte aktiv-aktiv eller aktiv-passiv failover, etter behov.
Overvåkings- og observasjonsverktøy
Overvåkings- og observasjonsverktøy brukes til å overvåke tilstanden til GO-Global-implementeringer og varsle når problemer oppstår. GO-Global tilbyr flere funksjoner som disse verktøyene kan bruke til å overvåke GO-Global.
De fleste observasjonsverktøy har funksjoner for inntak av loggfiler. GO-Globals loggfiler er som standard i HTML-format, noe de fleste observasjonsverktøy ikke støtter. Derfor må GO-Global generelt konfigureres til å registrere loggfilene sine i tekstformat når loggene skal inntas av et observasjonsverktøy.
I tillegg til loggfilene sine registrerer GO-Global hendelser i Windows-programloggen. Hendelsene som GO-Global registrerer i Windows-programloggen inkluderer oppstart og stopp av økter, brukerpålogginger og oppstart og stopp av applikasjoner.
For å støtte overvåking av farmverter og farmadministratorer, tilbyr GO-Global en healthCheck-forespørsel . HealthCheck-forespørselen kan brukes til å avgjøre om Application Publishing Service kjører på en farmvert eller farmadministrator, og eventuelt om systemet er i stand til å opprette en økt. Lastfordelere kan for eksempel bruke healthCheck-forespørselen til å sjekke tilstanden til farmverter i målgruppen sin.
Systemer som sender healthCheck-forespørsler må registreres hos hver målfarmvert eller farmadministrator. Mer spesifikt må IP-adressen til systemet som sender forespørselen være oppført i CIDR-format i APIWhiteList-egenskapen i målsystemets HostProperties.xml-fil.
I tillegg til disse verktøyene kan GO-Globals PowerShell API brukes til å hente detaljert kjøretidsinformasjon fra farmverter og farmadministratorer. For eksempel returnerer Get-GGSessions- funksjonen informasjon om øktene som kjører på en farmvert eller farmadministrator.
Konklusjon
Implementering av GO-Global i et storskala eller skyintegrert miljø krever nøye koordinering mellom flere infrastrukturkomponenter. Ved å konfigurere elementer som brannmurer, lastbalansere, omvendte proxyer og overvåkingssystemer riktig, kan administratorer oppnå et sikkert, skalerbart og høytytende GO-Global-miljø som gir en sømløs brukeropplevelse.
Enten implementert lokalt, i skyen eller på tvers av hybridarkitekturer, sikrer prinsippene beskrevet i denne artikkelen at GO-Global opererer effektivt i moderne bedriftsnettverk – og opprettholder pålitelighet, fleksibilitet og kontroll på alle lag av distribusjonen.
Er du en uavhengig leverandør av programvare (ISV) som utforsker levering av skybaserte applikasjoner? Kontakt oss for å finne ut hvordan GO-Global kan hjelpe deg med å effektivisere programvaretilgang for sluttbrukerne dine. Eller last ned en gratis prøveperiode for å teste det selv.
