Inleiding
Organisaties vereisen vaak een bepaald niveau van systeembeschikbaarheid voor hun ArcGIS Enterprise implementaties, zoals 99 procent van de tijd of hoger. Voor deze organisaties is het cruciaal om een strategie te implementeren die hoge beschikbaarheid garandeert.
Hoge Beschikbaarheid (HA), hoewel gerelateerd aan Disaster Recovery (DR), is een apart concept. Over het algemeen richt HA zich op het vermijden van uitvaltijd voor servicelevering, terwijl DR zich richt op het behouden van de data en middelen die nodig zijn om een systeem na een ramp terug te brengen naar een eerder acceptabele staat.
Deze post zal zich richten op best practices voor het configureren van een lokale load balancer (Local Traffic Manager, LTM) op één locatie voor hoge beschikbaarheid, en zal geen overwegingen bevatten voor het configureren van Global Traffic Manager (GTM) voor automatische failover tussen verschillende locaties.
Om hoge beschikbaarheid te bereiken, moet u single points of failure verminderen door duplicatie en load balancing.
Load balancers fungeren als een reverse proxy en verdelen het verkeer naar back-end servers. Een load balancer van derden is vereist in een hoog beschikbare ArcGIS Enterprise implementatie om de capaciteit en betrouwbaarheid van de software te verbeteren. Ze verwerken clientverkeer naar uw portal en server sites, evenals intern verkeer tussen de softwarecomponenten.
ArcGIS Web Adaptor
Hoewel ArcGIS Web Adaptor wordt beschouwd als een load balancer, is het onvoldoende om als enige load balancer te dienen in een hoog beschikbare implementatie, omdat ArcGIS Web Adaptor ook redundantie vereist om hoge beschikbaarheid te bereiken.
ArcGIS Web Adaptor is een optionele component, aangezien load balancers verzoeken rechtstreeks kunnen doorsturen naar uw portal en server sites, maar het is wel een aanbevolen component. De voordelen van het gebruik van web adaptors zijn:
- Het biedt een gemakkelijke manier om één enkele URL voor het systeem te configureren
- Het stelt u in staat contextnamen te kiezen voor de verschillende systeemcomponenten, bijvoorbeeld portal, server, mapping, enz.
- Het is native geïntegreerd met andere ArcGIS Enterprise softwarecomponenten, de portal en server sites, en zal automatisch health checks en configuratietaken afhandelen, bijvoorbeeld het toevoegen van een nieuwe machine aan een server site
Web Context URL
De web context URL is de publieke URL voor de portal. Aangezien elk item in de portal een URL heeft - bestand, laag, kaart en app - helpt de WebContextURL eigenschap van de portal bij het construeren van de correcte URLs voor alle resources die aan de eindgebruiker worden verzonden.
Externe Toegang en DNS
De ArcGIS Enterprise portal ondersteunt slechts één DNS voor de publieke portal URL (de web context URL), en momenteel is er geen ondersteunde manier om de web context URL te wijzigen zonder administratieve taken opnieuw uit te voeren, bijvoorbeeld het federeren van server sites met uw portal. Als uw ArcGIS Enterprise externe toegang vereist, bijvoorbeeld om toegang toe te staan voor mobiele gebruikers, aannemers, partners of agentschappen zonder VPN, of als u verwacht dat u in de toekomst externe toegang moet toestaan, moet u een extern oplosbare DNS naam gebruiken voor de web context URL van de portal, bijvoorbeeld https://gis.company.com/portal.
Om externe toegang tot ArcGIS Enterprise te beveiligen, is het gebruikelijk om een load balancer te hosten in een DMZ, en een Split Domain Name System (Split DNS) te implementeren, dat wil zeggen interne toegang tot ArcGIS Enterprise DNS (bijv. gis.company.com) wordt opgelost naar een intern load balancer IP-adres, zodat interne gebruikers achter de firewall blijven, en externe toegang tot ArcGIS Enterprise DNS wordt opgelost naar een extern (DMZ) load balancer IP-adres.
URLs gebruikt in federatie
Verschillende URLs worden gebruikt in een hoog beschikbare ArcGIS Enterprise implementatie.
Services URL
Dit is de URL die door gebruikers en clientapplicaties wordt gebruikt om toegang te krijgen tot ArcGIS Server sites. Het is de URL voor de load balancer die ArcGIS Server verkeer afhandelt en verzoeken doorstuurt naar ofwel de Web Adaptor van de server site of direct naar de server machines.
Administratieve URL
Deze URL wordt gebruikt door beheerders en intern door de portal om toegang te krijgen tot een ArcGIS Server site bij het uitvoeren van administratieve handelingen. Deze URL wordt ook gebruikt voor het publiceren van GIS-diensten met verwijzing naar een geregistreerde datastore, bijvoorbeeld SQL Server enterprise geodatabase, naar een gefedereerde server site. Dit moet wijzen naar een load balancer; als de administratieve URL wijst naar één enkele machine in de server site en die machine offline is, werkt federatie niet. Dit kan dezelfde URL zijn als de services URL of kan een tweede load balancer (VIP) zijn voor elke gefedereerde server site admin URL via poort 6443. Het configureren van een dedicated VIP voor elke gefedereerde server site admin URL via poort 6443 vereist dat deze poort openstaat voor beheerders en uitgevers, en u kunt administratieve toegang via de web adaptor uitschakelen, waardoor extra beveiligingscontroles voor de organisatie worden geboden.
Ik raad aan dezelfde URL te gebruiken als de services URL omdat dit configuratie vereenvoudigt. Administratieve toegang tot ArcGIS Server wordt gecontroleerd door ArcGIS Enterprise authenticatie en gebruikersrollen, vergelijkbaar met administratieve toegang tot portal, bijvoorbeeld ArcGIS Portal Directory (portaladmin) en Organisatie-instellingen. Om web adaptor URL te gebruiken als administratieve URL moet u administratieve toegang inschakelen in de server web adaptor.
Privé portal URL
Dit is een interne URL die door uw server sites wordt gebruikt om met de portal te communiceren. Dit moet ook wijzen naar een load balancer en moet worden gedefinieerd voordat federatie plaatsvindt. Als u uw server sites federateert voordat u privatePortalURL instelt, volg dan stap 8 en 9 in het onderwerp Configure an existing deployment for hoge beschikbaarheid om de URL binnen uw implementatie bij te werken. Net als bij de administratieve URL kan dit dezelfde zijn als de openbare URL voor het portal (de webcontext-URL van het portal), of het kan een tweede load balancer (VIP) zijn via poort 7443.
Voor eenvoudige configuratie raad ik aan om de openbare URL voor het portal te gebruiken als de privé portal URL. Als u ervoor kiest om een toegewijde load balancer VIP via poort 7443 te gebruiken voor de privé portal URL, moet u de load balancer configureren om de gezondheid van de portalmachines te controleren.
Load Balancer Configuratie
Health Check-instellingen
De belangrijkste functionaliteit om te gebruiken is een Health Check. Zoals beschreven in de documentatie over de health check van het portal:
"De health check rapporteert of de reagerende Portal for ArcGIS-machine in staat is om verzoeken te ontvangen en te verwerken. Bijvoorbeeld, voordat het portal is gemaakt, meldt de health check URL dat de site niet beschikbaar is omdat deze op dat moment geen verzoeken kan verwerken."
ArcGIS Enterprise portal en server hebben health checks.
Wanneer u ArcGIS Web Adaptors gebruikt, zorgen de web adaptors voor het uitvoeren van health checks tegen het portal en de servers. In dit geval kunt u de load balancer configureren met een basis TCP/443 health check of een statische pagina health check, met standaard instellingen voor timeout, failure trigger, polling interval en healthy threshold.
Als u de load balancer configureert om rechtstreeks toegang te krijgen tot het portal en/of de servers, bijvoorbeeld als u geen web adaptors in uw architectuur opneemt, of als u een toegewijde load balancer URL gebruikt voor privé portal URL (poort 7443) of gefedereerde server administratieve URL (poort 6443), moet u de load balancer configureren om de gezondheid van de portal- en servermachines te controleren.
Er zijn enkele belangrijke overwegingen over health check-instellingen op de load balancer. De meeste organisaties die een load balancer gebruiken, gebruiken een statische pagina als hun health check (bijv. index.html) om te bepalen of de webserver gezond is. Dit is een statisch bestand dat alleen een schijfopvraging vereist. Ook hebben de meeste webservers eerder een bottleneck bij I/O dan bij CPU.
Echter, Esri's ArcGIS Server is anders omdat onze health check een zeer kleine hoeveelheid CPU vereist omdat onze controle meer is dan alleen een schijfopvraging, aangezien de software moet bepalen of bepaalde processen functioneel zijn.
Bij health checks is er een timeoutwaarde voor het pollen. De meeste load balancer-beheerders stellen deze timeoutwaarde erg laag in omdat schijfopvragingen meestal erg snel zijn (hoewel ze vaak wat buffer laten voor slechte netwerkvertraging).
Wanneer u een lage timeoutwaarde gebruikt met ArcGIS Server en bij gebruik van een multi-machine setup, bestaat er een kans dat één van de machines deze lage timeoutwaarde overschrijdt en een gezonde machine wordt verwijderd.
Esri raadt een hogere timeoutwaarde aan, idealiter minstens 5 seconden. Afhankelijk van het systeem moet u deze waarde mogelijk nog verder verhogen. U moet uw omgeving monitoren en deze waarde dienovereenkomstig aanpassen. Dit lijkt misschien een hoge waarde voor netwerkbeheerders aangezien een health check op een eenvoudige pagina normaal gesproken minder dan 10 ms duurt (plus netwerkvertraging).
Het is echter cruciaal voor load balancers om onderscheid te maken tussen wanneer een machine gewoon traag is versus wanneer een machine echt dood en niet-responsief is. Als het portal of server echt uitvalt en helemaal niet luistert op een poort, zullen de meeste load balancers dit zelfs sneller dan 5 seconden detecteren, dus deze timeout heeft geen invloed op "normale" storingen waarbij een machine wegvalt.
De tweede overweging is de failure trigger - hoe vaak moet het pollen mislukken voordat de machine uit de load balancer wordt verwijderd.
Als vuistregel stellen netwerkbeheerders de failure trigger in op meer dan 1 mislukking omdat ze niet willen dat één enkele netwerkstoring het systeem platlegt. Zoals hierboven vermeld kan een kleine piek in CPU-gebruik (wat vaak voorkomt bij ArcGIS Server-systemen) leiden tot een timeout, en het is niet wenselijk om een machine uit te schakelen vanwege één enkele CPU-piek op één machine.
Esri heeft uitgebreide interne tests uitgevoerd met load balancers en vastgesteld dat een instelling van 5 mislukkingen het aantal false positives drastisch vermindert terwijl echte uitval nog steeds wordt gedetecteerd. We hebben vastgesteld dat een waarde van 3 nog steeds sterk vatbaar was voor false positives.
De derde overweging is het polling interval. Esri heeft vastgesteld dat polling intervallen van 30 seconden, gecombineerd met 5 mislukkingen, een goede balans vormen tussen het detecteren van echte storingen en het negeren van false positives.
Met deze combinatie is de verwachte waarde (in statistische termen) of gemiddelde detectietijd 1 minuut en 15 seconden downtime voordat detectie plaatsvindt, met in het slechtste geval 2 minuten en 30 seconden. Het is mogelijk om te streven naar een lagere gemiddelde detectietijd, maar dit gaat ten koste van meer false positives.
Als een lagere gemiddelde detectietijd gewenst is, kan het nodig zijn om capaciteit te vergroten zodat er voldoende middelen zijn om zowel echte storingen als false positives op te vangen zonder overbelasting van resterende machines.
De laatste instelling met betrekking tot health checks is de healthy threshold waarna de load balancer weer verzoeken gaat sturen. Esri heeft hiervoor geen specifieke aanbeveling en we hebben weinig verschillen waargenomen in deze waarde, maar doorgaans zien we 3 opeenvolgende gezonde polls voordat opnieuw wordt aangesloten.
Beperking (Throttling)
Beperkingsinstellingen verdienen aandacht. ArcGIS Server is CPU-bound wat betekent dat het grootste deel van de verwerkingstijd wordt besteed aan CPU-gebruik in plaats van wachten op I/O.
Dit betekent dat als er 8 cores zijn, ArcGIS Server praktisch iets meer dan 8 gelijktijdige verzoeken aankan. Als ArcGIS Server druk bezig is, begint het verzoeken in wachtrij te plaatsen totdat er honderden verzoeken in lijn staan, waarna verbindingen worden geweigerd. Bij lange wachtrijen resulteert dit in lange wachttijden, maar uiteindelijk wordt elk verzoek verwerkt.
ArcGIS Server heeft instellingen om dit gedrag te beheersen zodat er minder verlaten verzoeken worden verwerkt, maar het is ook best practice om dit op load balancer-niveau te regelen via throttling-mogelijkheden.
Esri heeft geen numerieke aanbeveling omdat dit sterk afhangt van specifieke architectuur en type binnenkomende verzoeken, maar typisch wordt throttling ingesteld op aanzienlijk lagere waarden dan netwerkbeheerders normaal zouden doen voor een webserver.
Dit valt buiten controle van netwerkbeheerders, maar clientapplicaties moeten zo worden geschreven dat ze throttling-events kunnen afhandelen en herhaalde pogingen doen met toenemende tijdsintervallen (bijv. eerste keer direct opnieuw proberen, tweede keer wachten 1 seconde, derde keer wachten 5 seconden enz.).
Sticky Sessions
Esri raadt sticky sessions niet aan behalve in zeer zeldzame gevallen. Sticky sessions kunnen theoretisch leiden tot overbelasting van één machine. Esri heeft loadtests uitgevoerd met sticky sessions om te zien of dit zou leiden tot overbelasting van onze GIS Server, wat niet gebeurde. We hebben ook geen klachten van klanten ontvangen. Omdat onze software stateless is zien we echter weinig voordeel in het gebruik van sticky sessions.
Laag 4 versus Laag 7
De laatste instelling die genoemd moet worden is of de load balancer werkt volgens "laag 7" of "laag 4" benadering. Dit kan onderwerp zijn van discussie onder netwerkbeheerders, hieronder volgt een beknopte samenvatting die verschillen en voordelen beschrijft.
Een laag 7 load balancer begrijpt http en https, hij ontsleutelt daarom https-inhoud en versleutelt deze opnieuw. Omdat hij http en https begrijpt kan hij inhoud cachen en verzoeken naar backend servers verminderen.
Een laag 4 load balancer ziet al het verkeer als TCP-pakketten zonder betekenis ervan te begrijpen; ze kunnen ftp-, https-, smtp-verkeer zijn maar dat maakt niet uit voor laag 4 load balancers. Hierdoor hoeft hij geen http-payload te begrijpen en kan hij sneller zijn.
ArcGIS Server werkt met beide benaderingen en er is geen specifieke aanbeveling voor netwerkbeheerders over deze instelling, maar er zijn wel enkele punten waar beheerders zich bewust van moeten zijn.
ArcGIS Server payloads kunnen veel groter zijn dan HTML-pagina's, CSS- en JS-inhoud (de daadwerkelijke grootte hangt vaak af van data die klanten gebruiken). Dit betekent meer CPU-belasting op laag 7 load balancers door ontsleuteling en versleuteling per verzoek.
Aangezien veel ArcGIS Server-data dynamisch en frequent veranderend is, verbieden cache headers standaard caching op client en load balancer. Als data weinig verandert en klanten toch laag 7 willen gebruiken kunnen zij deze cache-instellingen aanpassen en beheren.
Samenvatting Aanbevelingen
Health Check
.png)
