Bron foto: Port of Antwerp-Bruges

Auteur: Philippe Van De Vreken

Downtime van het GIS is onaanvaardbaar

De haven is een ecosysteem dat 24/7 in beweging is. In zo’n context is het GIS een kritische component. Kaarten met de exacte ligging van assets zoals kabels of (pijp)leidingen of kaarten die de maximale dieptes in de dokken aangeven moeten op elk moment beschikbaar zijn.

Port of Antwerp-Bruges maakt al jaren gebruik van het ArcGIS-platform, met ArcGIS Enterprise als ruggengraat van het webGIS. Een standaard upgrade van ArcGIS Enterprise neemt echter al snel zes uur of meer in beslag. Daarbij moeten de verschillende componenten sequentieel worden bijgewerkt, zoals Portal for ArcGIS, de verschillende machines in de ArcGIS Server site, één of meerdere types ArcGIS Datastore en bijhorende patches voor al deze componenten.

Zulke lange downtime is onaanvaardbaar wanneer het GIS wordt ingezet in kritische applicaties of processen. Ook buiten de kantooruren en in het weekend draait de haven verder, waardoor een downtime van meerdere uren geen optie is. Daarom kreeg GeoSquare van Port of Antwerp-Bruges de vraag hoe we deze downtime konden beperken.

Kubernetes als alternatief?

In een eerdere blog schreven we over ArcGIS Enterprise op Kubernetes als alternatief voor deployments op Windows of Linux. In dat model blijft het platform tijdens upgrades beschikbaar in read-only modus. Bovendien verloopt de upgrade van een Kubernetes deployment sneller dan een upgrade van een traditioneel deployment op Windows of Linux.

Toch zijn er belangrijke kanttekeningen:

• Organisaties die vandaag ArcGIS Enterprise op Windows/Linux gebruiken en willen overstappen naar Kubernetes moeten een volledig migratietraject doorlopen. Er bestaan immers geen kant-en-klare tools om bestaande deployments te verhuizen naar Kubernetes.
• ArcGIS Enterprise op Kubernetes werkt met architectuurprofielen. Tot en met versie 12.0 waren er drie profielen (Development, Standard en Enhanced), die verschillen in de mate van gegarandeerde beschikbaarheid door redundantie. Vanaf versie 12.1 spreekt men van beschikbaarheidsprofielen en zijn er daarnaast performantieprofielen (Standard en Enhanced) die de initiële CPU- en geheugenbehoefte bepalen. De totale systeemvereisten hangen af van de combinatie van beide profielen en kunnen, vooral in productieomgevingen, aanzienlijk zijn (zie Esri System Requirements).
• Upgrades op Kubernetes kunnen, net als op Windows/Linux, mislopen. In dat geval is een eenvoudige rollback niet mogelijk en moet een back-up van de vorige versie worden teruggezet.

Voor Port of Antwerp-Bruges bleek de Kubernetes-piste op dit moment minder aangewezen.

Blue-green deployment als oplossing

In plaats daarvan werd gekozen voor een blue-green deployment van ArcGIS Enterprise binnen een Windows-omgeving.

Een blue-green deployment betekent dat er naast de bestaande actieve omgeving (of blauwe omgeving) een volledig gespiegelde stand-by omgeving (of groene omgeving) wordt opgezet. Via een load balancer worden eindgebruikers naar één van de twee omgevingen gestuurd. Beide omgevingen zijn identiek (zelfde users, services, kaarten en applicaties).

Het principe werkt als volgt:

1. Er wordt een back-up genomen van ArcGIS Enterprise op de actieve (blauwe) omgeving met de beschikbare ArcGIS backup-tools.
2. Deze back-up wordt geïmporteerd in de stand-by (groene) omgeving.
3. Bij een major upgrade wordt eerst de groene omgeving geüpgraded. Tijdens dit proces blijft de load balancer naar de blauwe omgeving verwijzen, zodat gebruikers geen hinder ondervinden.
4. Na de upgrade worden smoke-testen uitgevoerd op de groene omgeving. Als alles in orde is, wordt de load balancer omgeschakeld naar de groene omgeving met de hogere versie van ArcGIS Enterprise. Binnen een fractie van een seconde wordt alle webverkeer herleid naar de standby-omgeving die nu de nieuwe actieve omgeving wordt.
5. Vervolgens wordt ook de voormalige actieve omgeving geüpgraded.
6. Tenslotte doen we omschakeling van de load balancer in omgekeerde richting.

Eindgebruikers ondervinden geen hinder want de URL’s veranderen niet en er is geen merkbare onderbreking. Het resultaat is een zero-downtime deployment van ArcGIS Enterprise. Waar het GIS vroeger meerdere uren onbeschikbaar was bij een upgrade, blijft het nu continu operationeel. Ook bij calamiteiten op de actieve omgeving kan snel worden overgeschakeld naar de stand-by omgeving.

Kosten versus baten

Omdat er een tweede parallelle omgeving nodig is, zijn er extra kosten voor bijkomende serverinfrastructuur. Ook is er extra onderhoud nodig om beide systemen up-to-date te houden (zowel Windows- als ArcGIS-patches).

Daar staat tegenover dat er geen extra ArcGIS-licenties nodig zijn, aangezien er op elk moment slechts één omgeving actief is. De licenties van de actieve omgeving mogen daarom hergebruikt worden voor de stand-by omgeving.

De meerkost wordt ruimschoots gecompenseerd door een GIS-systeem dat voortaan, net als de haven zelf, 24/7 beschikbaar is, ook tijdens grote onderhoudswerken. Hierdoor kan het GIS worden geïntegreerd in kritische applicaties en draagt het bij aan een veerkrachtige Haven.

Conclusie

Met een blue-green deployment transformeert ArcGIS Enterprise van een systeem met geplande onderbrekingen naar een platform dat continu beschikbaar is. Voor organisaties waar elke minuut telt, maakt dat een fundamenteel verschil.

Wil je deze aanpak toepassen binnen jouw organisatie of verder verkennen hoe je downtime van het GIS kan elimineren? Neem gerust contact op.