Op onze servers gebruiken wij CloudLinux, een Linux-distributie speciaal ontworpen voor hostingproviders. Deze zomer hebben we voor dit besturingssysteem een flinke update doorgevoerd. Maar hoe doe je dat, zonder dat de tienduizenden websites die erop draaien daar hinder van ondervinden? Dit artikel is misschien een goed begin… Graag vertel ik je over waarom we dit wilden en de bijkomende uitdagingen!
Deel 2: van theorie naar praktijk!
Het tweede deel is nu ook beschikbaar. Daarin vertel ik meer over hoe het plan tot uitvoer kwam en welke uitdagingen er werden overwonnen.
‘Nieuwer is altijd beter’ hoor je weleens. Doe je wat met software, dan weet je dat de realiteit soms anders is. Onbekende bugs kunnen je zonnige humeur omzetten naar een dag vol zorgen. Dit verhaal begint daarom niet bij de upgrade zelf, maar bij de vraag waarom. Is het wel echt nodig om dit te doen? Wat zijn de voor- en nadelen? En wat is dan de beste manier? Veel vragen… De antwoorden vind je hieronder.
De verschillende versies van CloudLinux
Er zijn van CloudLinux inmiddels drie versies uitgekomen. Ze worden allemaal nog onderhouden, hoewel de mate waarin verschilt. Om te beginnnen heb je CloudLinux 6. Die kwam uit op 1 februari 2011 en is ondertussen dus meer dan tien jaar oud. Er is nog tot 30 juni 2024 ondersteuning voor deze versie, maar alleen in de vorm van extended support. Dit houdt in dat bugs en kritieke beveiligingsproblemen worden opgelost, maar er geen nieuwe features meer bijkomen.
Daarna is op 1 april 2015 CloudLinux 7 uitgekomen. Deze versie wordt nog ondersteund tot 30 juni 2024. Of er daarna net als met versie 6 extended support komt, is nog niet bekend. Als laatste is er CloudLinux 8. Die is uitgekomen op 17 maart 2020 en wordt ondersteund tot 31 mei 2029.
Bij CloudLinux 6 en 7 kun je ook nog kiezen voor een zogenaamde hybrid kernel. Voor CloudLinux 6 betekent dit dat je de kernel van CloudLinux 7 gebruikt en de rest van je besturingssysteem gelijk blijft. Voor CloudLinux 7 geldt hetzelfde, maar dan met de kernel van CloudLinux 8. Wij gebruikten CloudLinux 6 met hybrid kernel en hadden dus grofweg drie opties.
- Niet upgraden
- Upgraden naar CloudLinux 7
- Upgraden naar CloudLinux 8
De juiste afweging maken
Om een goede afweging te maken, spelen er een aantal zaken mee. Denk aan de leeftijd en verwachte levensduur van de servers die in gebruik zijn, maar ook de verwachte aanschaf van nieuwe servers. In ons geval zat dit laatste eraan te komen. Nieuwe servers betekent eveneens nieuwe hardware. Hardware die ten tijde van het ontstaan van CloudLinux 6 en 7 nog niet bestond. Als gevolg daarvan was er op de nieuwe hardware geen ondersteuning voor onze kernel. CloudLinux 8 werd zo een vereiste.
Goed, op de nieuwe servers CloudLinux 8 dus! Je wilt in dat geval ook alle huidige servers updaten. Zo heb je als bijkomend voordeel dat je binnen het platform geen verschillen hebt. Gezien die hardware alsnog zeer capabel is en niet binnen een jaar moet worden uitgefaseerd, heeft dit ook daadwerkelijk nut. Updaten naar CloudLinux 7 was op dit punt ook een optie, maar vonden we minder aantrekkelijk. Die heeft nog maar drie jaar ondersteuning te gaan en dan draai je binnen het platform alsnog twee verschillende versies.
Mogelijke upgrade-paden
Nu we besloten hadden dat we wilden upgraden, was het tijd om te kijken naar de volgende vraag: hoe dan? Om dit te onderzoeken, doken we in de documentatie. Het antwoord daar was vrij snel duidelijk. Het kan niet. Het kan al niet als je één versie omhoog wil, laat staan als het er gelijk twee zijn…
Het zou zonde zijn om dit blog tot een vroegtijdig einde te laten komen. We doen daarom gewoon net of we de documentatie niet hebben gelezen en vervolgen onze weg. Na wat rek- en strekoefeningen voor het brein kwamen tot de volgende mogelijkheden.
- Alle hostingpakketten verplaatsen
- Data-disks overzetten naar nieuwe installatie
- Nieuwe systeem-root ernaast, kiesbaar in grub
- Yum update met scripting eromheen
- Tarball uitpakken over de oude installatie
Laten we ze eens stuk voor stuk bekijken.
#1. Alle hostingpakketten verplaatsen
Het idee hier was dat je zorgt voor een lege server met CloudLinux 8. Daar verplaats je dan alle pakketten van één server stuk voor stuk naartoe. Daarna zet je CloudLinux 8 op die nu lege server en verplaats je er alle pakketten van een volgende server naartoe. Hiermee ga je door, totdat alle servers voorzien zijn van CloudLinux 8.
Voordelen
- De snelheid is goed te regelen. Mochten er problemen spelen die alleen op CloudLinux 8 aanwezig zijn, dan zijn er maar een zeer beperkt aantal klanten die er last van hebben.
Nadelen
- Er is nieuwe of alternatieve hardware nodig.
- Vanwege externe nameservers zijn niet alle pakketten over te zetten en dat vereist extra werk.
- Als een klein percentage van de overzettingen problemen geeft, dan zijn dat er op tienduizenden accounts alsnog veel.
#2. Data-disks overzetten naar nieuwe installatie
Hier was het plan dat je een server hebt met daarop een CloudLinux-8-installatie. Vervolgens zet je de oude server uit, verplaats je de data-disks naar de nieuwe server en start je deze.
Voordelen
- Redelijk snel te doen.
Nadelen
- Moet vanuit het datacenter en betekent dus veel nachten op pad.
- Er is momenteel geen 100% scheiding tussen system en data, dus lastig met omzetten.
- Er zijn een klein aantal configuratiezaken die op de OS-disken staan en dus op een andere manier moeten worden overgezet.
#3. Nieuwe system-root ernaast, kiesbaar in grub
Hier maak je op de bestaande servers een extra partitie aan, waarop je CloudLinux 8 installeert. Je zet dan de kernel en een initial ramdisk in de bootpartie, past de bootlader aan en reboot naar de nieuwe versie.
Voordelen
- Goede rollback mogelijk (weer booten naar CL6 kan mogelijk zijn).
- Zeer snelle upgrade.
Nadelen
- Lastig te bouwen.
#4. Tarball uitpakken over de oude installatie
Hier zorg je voor een verse installatie van CloudLinux 8, maak je een tarball (soort zip-bestand) van en pak je deze uit over de oude CloudLinux-6-installatie. Dit uitpakken kan vanuit een draaiend CloudLinux-6-systeem of met een speciale boot image.
Voordelen
- Het is redelijk snel te doen.
- Vermoedelijk enigzins gemakkelijk te bouwen.
Nadelen
- Tijdens het uitpakken is er een inconsistente state. Gaat er dan iets mis, dan heb je waarschijnlijk een systeem wat niet kan opstarten. Dat is wel afhankelijk van de methode. Gebruiken we een bootable image om het uitpakken te doen dan is dat probleem minder, maar wel als we dit vanuit de oude install doen.
- Er kunnen restanten van CloudLinux 6 achterblijven.
#5. Yum-update met scripting eromheen
Je gebruikt yum (de package manager op CloudLinux) om alle packages te updaten naar CloudLinux 8.
Voordelen
- Geen overblijfselen van oude RPM’s. In tegenstelling tot de tarball-methode, ruimt yum dit netjes op.
Nadelen
- Waarschijnlijk lange downtime.
- Onzeker of het kan (misschien alleen van versie 6 naar 7 en 7 naar 8).
- Tijdens de update inconsistente state, net als bij de tarball-methode.
En de winnaar is…
Nummero 3! Nieuwe system-root ernaast, kiesbaar in grub. Zeker niet de makkelijkste optie voor ons, wel hetgeen wat de minste downtime opleverde voor jou. Ook was hier de mogelijkheid voor een rollback het best. Op dit punt hadden we dus helder waarom en hoe we wilden updaten. Op naar de uitvoer! Want hoe ging dat? Voor nu wordt het iets te bont om ook dit te bespreken. Binnenkort volgt daarom deel twee. Hopelijk vond je dit kijkje in de keuken interessant en tot dan!
Heel fijn dat jullie hier zo open over zijn. Dit maakt dus het verschil en is een voorbeeld van een van de redenen dat ik bij Antagonist zit. Jullie kiezen heir voor de methode met de grootste tijdsinvestering om downtime te voorkomen. Lekker doorgaan zo!!!1!
De sysadmins hebben niet stilgezeten :).
Zeer benieuwd naar deel 2! Zag in de status een flinke tijd iets ‘mis’ was met cloudlinux8. Verder was er nog dagelijks een backup probleem met installatron WordPress. Ben benieuwd als dit samen loopt/liep cl8 of weer echt DA dingetje was.
Bedankt voor je reactie, Robby! Rondom de update speelde er inderdaad een (toen nog onbekende) bug op met gevolgen voor het geheugengebruik. Deel 2 volgt binnenkort en gaat ook daar meer op in. Hetgeen wat met Installatron gaande was, staat hier verder los van 🙂
Ga zo voort, ga zo voort….