We willen de systemen die wij beheren graag up-to-date houden. Toch heb ik regelmatig discussies met klanten: Is dat updaten wel nodig? Er moet toch weer downtime geregeld worden. En het kan issues opleveren. In uitzonderlijke gevallen gaat het zelfs weleens mis.
Is een patch wel nodig?
Het antwoord op die vraag hangt af van de strategie die bedacht is. Ik kan wel vinden dat het nodig is, maar uiteindelijk is de eindklant de baas. We hebben klanten die zelden hun systemen bijwerken. De strategie daar is om regelmatig nieuwe hardware aan te schaffen. Bij aanschaf worden de systemen helemaal up-to-date gebracht en vervolgens kunnen ze weer een paar jaar vooruit. Dat lijkt een prima strategie. Zeker in snelgroeiende bedrijven, deze bedrijven gaan vaak al na 2 jaar een vervangingstraject in.
Updaten of gewoon vervangen?
Bij de klanten die vervangen in plaats van updaten zien we helaas toch regelmatig compatibiliteit issues. Het nieuwe systeem moet toch op het oude aangesloten worden. Dat levert weleens problemen op. Ook issues die pas na lange tijd ontstaan worden op deze manier niet aangepakt. De business met deze strategie is niet gewend om te patchen. Daarom is het vaak lastig om downtime te regelen. Het noodzakelijk patchen om een issue te fixen wordt dan vaak uitgesteld tot het echt niet meer kan. En dan is het vaak te laat.
Toch maar updaten dan?
Je hoeft niet altijd voorop te lopen met de nieuwste patches. Ook nieuwe patches kunnen weer issues introduceren die weer gepatched moeten worden. Nieuwe installaties zijn een mooi moment om de nieuwste software te installeren. Bij Rhodix streven we ernaar om systemen 2x per jaar te patchen. Tenzij er op basis van security een reden is om dat vaker te doen. 2x per jaar betekent dan vaak wel dat er patches op meerdere vlakken tegelijk uitgevoerd worden (firmware, OS update, Storage update etc.), hetgeen ook weer risco’s met zich meebrengt.
Al die risico’s, toch maar niet doen?
Waarom willen we eigenlijk patchen? Wat heeft het voor voordelen? Soms lijken er alleen maar nadelen aan te zitten en lijkt het een noodzakelijk kwaad. Waarom denken we bij Rhodix dat regelmatig updaten toch een goede strategie is?
Updates en patches zijn oplossingen voor bekende problemen. Soms brengen ze nieuwe features en daardoor misschien mogelijkheden die eerder niet mogelijk waren. Als we issues aanmelden bij een vendor komt het vaak voor dat de oplossing al in een update zit. De vendor zal meestal vragen om het systeem up-to-date te brengen. En vervolgens te beoordelen of het probleem nog steeds aanwezig is. We willen bij Rhodix die stap voor zijn door een probleem op een up-to-date systeem aan te melden. Dat voorkomt kostbare tijd die verloren gaat wanneer een systeem alsnog gepatcht moet worden. Belangrijker nog: Je moet ongepland en op korte termijn downtime regelen om het systeem alsnog te patchen. Daarbij blijft de onzekerheid of je probleem is opgelost.
Ok, maar zitten er nog meer voordelen aan?
Niemand brengt graag systemen down voor onderhoud. Waarom niet? Je weet nooit of ze weer normaal opstarten. Er kan altijd wat defect gaan (vaak is het al defect, maar dat is weer een andere blog waard). Daarnaast kost het tijd en levert het druk op vanuit de business. Zijn de systemen wel weer op tijd in de lucht?
Toch zitten er voordelen aan regelmatig down brengen van je systeem. Je raakt bekend met de stop/start procedures. Je raakt vertrouwd dat je het systeem weer in de lucht krijgt in panieksituaties. En als er dan toch wat defect gaat, dan gebeurt het tenminste gepland. Elke patchronde levert betere procedures op. Het updaten zal elke ronde beter en vloeiender gaan. Loop je toch een keer tegen issues aan dan zijn ze vaak sneller opgelost, omdat je de rest van de procedure kent. Je weet wat “normaal is” en je ziet snel afwijkingen (dus als iets niet gaat zoals verwacht).
Kan het ook zonder downtime?
De meeste high-end systemen die wij beheren kunnen zonder (of met weinig) overlast bijgewerkt worden. Bij virtualisatie bijvoorbeeld, kunnen de VM’s online verplaatst worden. De hypervisor en het fysieke systeem kan dan gepatched worden. Vaak zelfs tijdens kantooruren. Vergeet dan niet dat ook de VM’s af-en-toe updates nodig hebben. Maar dat kan dan een-voor-een gepland worden. Niet alles hoeft dan tegelijk down.
Bij echt grote systemen kan vaak een 2e omgeving aangemaakt worden. De updates worden dan op de 2e omgeving aangebracht. Of in een active-standby situatie kan eerst de standby bijgewerkt worden. Na een herstart of een failover wordt dan de andere omgeving geactiveerd en ben je up-to-date. In geval van problemen kun je dan makkelijk terug: Start simpelweg de originele omgeving weer op.
Wat is nu het beste?
Elke strategie is goed. Helemaal geen strategie is niet goed. Ik ken klanten die graag vooroplopen. Altijd het nieuwste, want dat voorkomt problemen! Ik ken ook klanten die de .0 releases links laten liggen en wachten op een .1 release (bijvoorbeeld 7.0 niet, maar 7.1 wel). De meeste issues zijn er dan wel uit. Sommige klanten hebben een uitwijksysteem dat ze in kunnen zetten als productie. Dat kan tijdelijk, dus gedurende de update ronde. We hebben ook klanten die de ene helft van het jaar op de “linker” hardware draaien en de andere helft van het jaar op de “rechter” hardware. Een onbedoeld voordeel van deze methode is dat de uitwijk ook meteen getest is. Ook daarvoor geldt dat we dat graag 2x per jaar testen.
Kortom, alles staat of valt met wel of geen strategie en daar je business op aan te passen. Onze keuze: regelmatig patchen want dan heb je de meeste controle op je omgeving.
Erwin Willems – System Manager Rhodix
