LCM op overjarige omgevingen

Zoals beschreven in mijn vorige blog is het verstandig om het Lifecycle Management (LCM) te managen voor complete omgevingen. Dus niet alleen regelmatig de (beveiliging)updates installeren op het besturingssysteem, maar ook kijken naar de levensloop van de complete omgeving, inclusief de onderliggende hardware.

In deze blog wil ik graag ingaan op de mogelijkheden die er zijn als er sprake is van een echt overjarige omgeving. Hoe kom je van de vaak torenhoge kosten af die een dergelijke omgeving met zich meebrengt? Of soms nog erger: er is nergens meer support te krijgen en reserve-onderdelen van de onderliggende hardware zijn niet meer verkrijgbaar. Is er dan nog licht aan het eind van de tunnel?

Oud of ouder

Op het moment dat je van een verouderde Linux versie komt, je hebt bijvoorbeeld een versie ouder dan de vorige versie van Red Hat Enterprise Linux in gebruik, dan kan het soms al best lastig zijn. Er zijn dan al best wel flinke verschillen tussen de versies. Zo is er in de loop der jaren overgestapt naar een nieuw, parallel werkend init-systeem, maar ook de meegeleverde libraries en tooling kunnen aangepast zijn, denk bijvoorbeeld aan de Java-versies op een systeem. Over het algemeen zijn dergelijke migraties wel iets lastiger dan "van de vorige versie naar de huidige" maar toch nog wel goed te doen.

Van links naar rechts of van rechts naar links

Het wordt pas echt vervelend als er andere complexe factoren meespelen, bijvoorbeeld bij een migratie van een ander platform. Denk hierbij aan applicaties die draaien op HP-UX of Sun Solaris, maar bijvoorbeeld ook IBM AIX. Kenmerkend hierbij is dat we niet alleen te maken hebben met een andere UNIX smaak (nb: Linux zelf is ook een UNIX-variant!), maar ook nog een verschil in processor architectuur. Hedendaagse processors zoals uitgebracht door AMD en Intel zijn van het zogenaamde Little-Endian type, waar de processor architecturen van de hardware onder de genoemde UNIX-smaken van het Big-Endian type zijn. In Jip-en-Janneke taal: de volgorde van de bits intern zijn precies tegengesteld. Je kunt dit vergelijken met het verschil tussen westerse talen, die van links naar rechts schrijven, en het Arabisch, wat van rechts naar links geschreven wordt. Het begin en het einde van de zin zijn precies van plaats verwisselt!

Waar kan ik het vinden? 

Naast dit soort technisch complexere factoren spelen er vaak ook nog niet-technische zaken mee, veelal praktisch van aard. Zo hoor ik vaak over omgevingen die dusdanig lang draaien dat de medewerkers die ze destijds hebben ingericht niet meer werkzaam zijn op de afdeling, ze zijn overgestapt naar een andere werkgever of met pensioen. Of er is geen documentatie (meer) beschikbaar. Soms omdat het simpelweg nooit is geschreven (zie mijn blog: "Documentatie van de IT-specialist: Welke documentatie?"), maar vaak ook omdat de documentatie die er al was verloren is gegaan met verhuizingen. In het geval van papieren documentatie is het bijvoorbeeld (deels) weggegooid tijdens een verhuizing naar een nieuw pand, als er sprake was van elektronische documentatie is het vaak misgegaan bij migraties van het documentatie-platform. Dan stond het ooit op een fileserver, die is gemigreerd naar een nieuwere fileserver en vervolgens is er een SharePoint neergezet waar alle documentatie op terecht moest komen. Kortom: niet alle kennis en informatie over een systeem is (meer) beschikbaar, wat een migratie naar een courante Linux-oplossing bemoeilijkt.

Er is hoop (en hulp)

Gelukkig kan er hulp ingeroepen worden om een dergelijke migratie toch succesvol te laten verlopen. Indien mogelijk kan er dan meteen gebruik gemaakt worden van recente technieken zoals infrastructure-as-a-code (IAAC). Dan wordt de inrichting van het nieuwe Linux platform bijvoorbeeld geschreven in de vorm van een Ansible Playbook, zodat de inrichting van de omgeving daar niet alleen mee gedaan kan worden, maar een en ander ook meteen gedocumenteerd is.

Zo heeft Proxy onlangs een migratie gedaan bij een klant die een verouderd HP-UX systeem op RHEL8 wilde laten landen. Hierbij zijn ook Ansible Playbooks toegepast. Verder kon de migratie van de data opgelost worden door de database-software de migratie te laten uitvoeren, door middel van het toepassen van clustering technieken. Je hebt dan ook geen last meer van Big- vs. Little-endiannes. 

Kennis is key

Kortom, zelfs als het er op het eerste oog uitziet als een onmogelijke opgave om een overjarig systeem te migreren, dan is er met de juiste hulp van senior IT-specialisten toch wel uit te komen. Er is dus eigenlijk altijd wel licht aan het einde van de tunnel!

Twijfel jij hoe het er met jouw omgeving voor staat? Neem dan contact met ons op. We kijken graag met je mee!