Hoe om te gaan met servermigraties met minimale downtime

Onlangs hebben we bij Kaliber een grote migratie uitgevoerd, waarbij we een fysiek datacentrum hebben opgeheven en de daar draaiende applicaties in een private cloud hebben ondergebracht. Dit was een grote klus waarbij we ongeveer 50 virtuele machines en een stuk of 10 fysieke servers verplaatst hebben zonder dat er noemenswaardige downtime optrad voor de betrokken sites en diensten. Hoe pak je zo’n klus aan?

Inventariseren van gebruikte technieken en applicaties

Het belangrijkste is een goede inventarisatie van de gebruikte technieken en de onderverdeling van applicaties. Veel sites en applicaties bestaan uit een test-, acceptatie- en productie-omgeving, die op verschillende virtuele machines geïmplementeerd zijn en anders behandeld kunnen worden.

Verder konden we een beperkt aantal manieren identificeren waarop applicaties werkten. Zo waren er bijvoorbeeld Coldfusion applicaties, op WordPress gebaseerde applicaties, Play/Scala applicaties, etcetera. De gebruikte technieken in de applicaties bepalen in grote lijnen hoe de hosting eruit komt te zien.

Ook waren we niet in alle gevallen beheerder voor de relevante DNS-records. Kort gezegd: we moesten hier en daar collega-beheerders inschakelen die aanpassingen moesten doorvoeren om een domein van de oude naar de nieuwe omgeving te laten verwijzen.

Door een goed overzicht te maken van welke omgevingen en technieken er gebruikt worden bij applicaties, is het mogelijk om een plan te maken waarbij de virtuele resources voor hosting zo efficiënt mogelijk worden ingezet. Een beetje extra onderzoek doen en goed puzzelen betaalt zich meestal uit doordat je later bij het inrichten voor een stuk minder vervelende verrassingen komt te staan.

Hoe configuratiemanagementsoftware ons hielp

Wat hierbij enorm hielp is dat we een paar jaar geleden configuratiemanagementsoftware zijn gaan gebruiken in plaats van ‘ambachtelijk’ met het handje op servers steeds dezelfde configuraties typen. Een voorbeeld: als je tien webservers moet inrichten kun je natuurlijk tien keer op een server inloggen, modules activeren en met de hand zaken instellen. Het is daarbij haast onvermijdelijk dat je dit niet helemaal identiek doet. Je maakt foutjes. Of je hebt een iets andere stijl van zaken oplossen dan je collega. Het gevolg: voor eenzelfde soort applicatiehosting krijg je toch verschillende oplossingen die net iets anders werken en allemaal los van elkaar getest moeten worden. Dat is onhandig, onvoorspelbaar en kost veel tijd.

Wat veel efficiënter werkt, is met behulp van software templates opstellen voor een bepaald soort configuratie en de details dan invullen met slimme software.

Zo eindig je met een gelijksoortige configuratie voor gelijksoortige applicaties en de instellingen zijn allemaal vastgelegd in de software die dit beheert. Verder is deze code een stuk betrouwbaarder als documentatie dan oude, missende of niet meer actuele documentatie van (oud-)beheerders die misschien ooit opgesteld is toen een project werd opgeleverd.

Doordat we op de fysieke locatie en de cloud-locatie dezelfde generieke flow konden aanhouden (firewall -> loadbalancers -> applicatieservers -> backend/data servers), konden we in veel gevallen onze bestaande configuratiemanagement-templates één op één overnemen, waarbij we zeker wisten dat het resultaat identiek zou zijn. Je kunt als het ware een kopie maken van de belangrijke instellingen van een server. Hoe tof is dat!

Nauwelijks downtime!

Doordat we in dit geval niet de fysieke servers uit een datacentrum hoefden op te halen en in een andere locatie weer moesten hergebruiken, konden we naast de draaiende bestaande omgeving de nieuwe virtuele omgeving opbouwen en rustig alle data die nodig was overzetten om te proefdraaien.

Dit zonder dat onze opdrachtgevers of eindgebruikers daar last van hadden: de bestaande omgeving draaide immers nog gewoon door voor de rest van de wereld.

In overleg met onze SLA-manager werd dan per applicatie besloten of het nodig was dat de applicatie werd stopgezet tijdens de feitelijke migratie. Als mensen reserveringen kunnen maken of dingen kunnen aanschaffen is korte downtime eigenlijk altijd nodig terwijl de achterliggende data stores gemigreerd worden, omdat anders de datasets van de ‘oude’ en ‘nieuwe’ omgeving kunnen verschillen.

In de praktijk konden we ongeveer 90 procent van onze applicaties zonder downtime migreren en heeft niemand hier iets van gemerkt. Waar downtime nodig was is deze veelal beperkt gebleven tot een periode van 5 – 15 minuten waarbij we dit ook buiten de reguliere kantoortijden konden uitvoeren.

Wat zijn de belangrijkste lessen die we in dit traject hebben geleerd?

• Het toepassen van configuratiemanagement betaalt zich dubbel en dwars uit bij dit soort werkzaamheden.
• Een ogenschijnlijk onoverzichtelijk grote klus (het migreren van een heel datacentrum), laat zich prima opdelen in kleinere subtaken.
• Het zelf in beheer hebben van DNS voor websites maakt dat je een stuk sneller kunt schakelen. Vooral tijdens zomervakanties als collega-beheerders bij andere partijen niet bereikbaar zijn.

*) Dit artikel is tevens gepubliceerd op de website van Kaliber Interactive.