Een motor van een vliegend vliegtuig vervangen

Groei

SURFconext heeft in de 4 jaar van haar bestaan een onstuimige groei meegemaakt. Waar begin 2013 het platform ongeveer 100.000 logins per week afhandelde, is dat het afgelopen jaar gegroeid naar meer dan 2 miljoen logins per week. Op drukke momenten gaat het om 900 logins per minuut. De 100.000 logins per week waren destijds verdeeld over ruim 150 Service Providers, dat is inmiddels gestegen naar ruim 600. Door deze groei en de toenemende afhankelijkheid van clouddiensten voor onze instellingen is uptime van het platform dat de logins faciliteert van groot belang. Daarom is begin 2016 begonnen met werkzaamheden om de betrouwbaarheid en beschikbaarheid nog verder te verhogen. Die verhoging van de betrouwbaarheid van het platform vindt plaats op een drietal niveaus:

1) Refactoring van Engineblock, het hart van onze software

Engineblock is de software die verantwoordelijk is voor afhandeling van de SAML-logins. Aangezien de code van deze software alweer een paar jaar oud was, zijn we begin 2016 begonnen met het herschrijven van gedeeltes van deze software. Dit heeft uiteindelijk geleid tot versie 5.0, die in augustus in gebruik is genomen. Naast het optimaliseren van de code zijn er specifieke aanpassingen gedaan die de betrouwbaarheid moeten verhogen, zoals het mogelijk maken om LDAP als backend uit te faseren (waarover later meer), aanpassingen om de database kleiner te maken en het aantal benodigde writes te verminderen. Alle aanpassingen zijn ook onderdeel geworden van OpenConext, de open source software waarop SURFconext gebaseerd is. Verder hebben we extra aandacht geschonken aan automatische tests zodat de correcte werking al in veel testscenario’s automatisch geverifieerd kan worden. Elke keer als we functionaliteit aanpassen of toevoegen worden daar gelijk nieuwe automatische tests van die functie aan toegevoegd. Dit wordt dan met Travis automatisch getest.  Gezien de enorme hoeveelheid configuraties bij zowel IdP’s als SP’s is dat geen overbodige luxe.

2) Geografische scheiding

De servers van SURFconext werden gehost in de datacenters van Nikhef en Vancis in Amsterdam. Afgelopen jaar is dat uitgebreid met een locatie in Utrecht. Logisch gezien vormen de twee locaties (Amsterdam en Utrecht) twee los van elkaar opererende SURFconext-instanties. Alle locaties kunnen los van elkaar opereren, en bij uitval van een locatie kan de tweede het automatisch overnemen. Om dit mogelijk te kunnen maken hebben we de database gemigreerd naar een MySQL-Galeracluster. Alle verbindingen tussen de twee locaties worden geëncrypt om eventueel afluisteren te voorkomen.

3) Automatisering van deployments en beheer met Ansible

Ansible is een tool die het mogelijk maakt het beheer van je servers te automatiseren. De configuratie wordt opgeslagen in YAML-bestanden (een formaat dat voor zowel computers als mensen leesbaar is) en door deze automatisering is het uitrollen van software of aanpassingen aan de infrastructuur veel voorspelbaarder geworden. Het wijzigen van een configuratiebestand, of het upgraden van onze software kunnen we zo uitvoerig testen, en pas als alles op rolletjes verloopt wordt het tijdens een onderhoudswindow op de productieomgeving gezet. Zo worden op dit moment 4 loadbalancers, 12 applicatieservers en 5 databaseservers automatisch van nieuwe software en configuratie voorzien.

De migratie

Aanpassingen aan een platform dat 24/7 moet blijven draaien is te vergelijken met het vervangen van de motor van een vliegtuig, terwijl het nog vliegt. De eerste aanpassingen die we gedaan hebben was het vervangen van alle servers door nieuwe (virtuele) servers met CentOS 7. De configuratie en inrichting van deze machines is volledig met Ansible gedaan. Onderdeel van deze upgrade was het in productie nemen van nieuwe loadbalancers (augustus) met daarop haproxy en de migratie naar een databasecluster (november). De nieuwe servers en de nieuwe software werden daarbij in een keer in gebruik genomen, zodat het mogelijk was om terug te gaan naar de oude situatie. Deze wijzigingen hebben we zonder downtime weten te realiseren.

Het laatste onderdeel van het project betrof het uitfaseren van LDAP als backend. Een LDAP-server is lastig om hoog beschikbaar over meerdere locaties te verspreiden en in het huidige platform volstaat het opslaan van de gegevens, over bijvoorbeeld consent en gegenereerde identifiers van gebruikers, in een database. Daarmee wordt de complexiteit van het gehele platform verminderd en daarmee de betrouwbaarheid verhoogd. Er hebben drie pogingen om deze backend uit te faseren, moeten plaatsvinden voordat deze ook succesvol was. Een onverwachte outage van de LDAP-server, en een aanpassing aan de software die ervoor zorgde dat een aantal van onze instellingen niet meer in staat waren om correct in te loggen heeft geleid tot downtime buiten het onderhoudswindow. Het onverwachte karakter van de outage toonde aan dat uitfasering van deze backend een goede keuze was. Op 5 januari is de LDAP-backend uiteindelijk succesvol uitgezet. Op dit moment fungeert de locatie Utrecht als stand-by locatie. In de komende paar weken zal deze locatie ook actief meedraaien, en zal bij een calamiteit op een van beide locaties de tweede locatie automatisch uitval de taken van de andere locatie overnemen.

Als je vragen hebt, kun je altijd contact opnemen met Bart Geesink.