Cloud Services
Classified Cloud
Managed Services
Kubernetes
Öffentliche Verwaltung
Verteidigung & Raumfahrt
Sicherheitsbehörden
Gesundheitswesen
Regulierte Industrien
Kritische Infrastrukturen
Enterprise IT-Modernisierung
SaaS & digitale Plattformen
Cloud Services
Classified Cloud
Managed Services
Kubernetes
Auf unserer Managed Hosting Plattform setzen wir bei der Virtualisierung der Betriebssysteme auf Virtuozzo. Die Software ist quasi die Enterprise-Edition der bekannten Open-Source-Lösung OpenVZ. Als klar wurde, dass Virtuozzo 4.7 im September 2018 keine Sicherheitsupdates mehr bekommen würde und damit für uns end of life gehen würde, haben wir uns im April mit Hochdruck an die Arbeit gemacht. Zu diesem Zeitpunkt lief Virtuozzo 4.7 bei uns „lediglich“ auf 80 Bare-Metal-Servern, vollgepackt mit Kunden-VEs. Die Aufgabe war klar: Wie schaffen wir es in der verbleibenden Zeit, die 80 Server auf das neue Betriebssystem zu ziehen, ohne unseren Biorhythmus komplett auf „nachtaktiv“ umzustellen?
Die erste gute Nachricht war schnell gefunden: Das Containerformat hatte sich zwischen 4.6 und PCS6 nicht geändert, so dass Container weiter migriert werden konnten. Mit dieser Information im Rücken setzte sich eine Kollegin an die Evaluation der Möglichkeiten. Die erste Option wurde unter der bisherigen Annahme entwickelt, dass nur leere Server mit dem neuen Betriebssystem bespielt werden können, um die Container anschließend zu migrieren: Wir installieren Schritt für Schritt. Schließlich hatten wir nicht mal eben 80 weitere, ungenutzte Server im Bestand. Diese Option hätte viel händische Arbeit und Zeit bedeutet, weshalb sie direkt verworfen wurde und wir uns für die folgende Variante entschieden haben.
Die neue Lösung: das Inplace-Upgrade von Virtuozzo nehmen und besser machen
Virtuozzo bot von Haus aus die Option eines Inplace-Upgrades an. Dafür gibt es im Virtuozzo-Betriebssystem eine Partition mit dem Namen „/vz“, in der alle Containerdaten gespeichert werden. Der Ansatz des Inplace-Upgrades sieht vor, ein neues Betriebssystem zu installieren und dem Installer gleichzeitig mitzugeben, die /vz-Partition unangetastet zu lassen. Dieses Prinzip kennen viele aus der Neuinstallation einer Linux-Distribution, bei der das Homeverzeichnis mit sämtlichen Daten erhalten bleiben soll.
Wir wollten den Vorschlag von Virtuozzo nutzen, mussten aber feststellen, dass wir dafür bei jeder Neuinstallation das Boot-Menü hätten durchklicken müssen. Das bereitgestellte Tooling war nicht automatisiert verfügbar. Da unser Team wenig von Toil hält, haben wir nach einem Weg zur Automatisierung gesucht. Weil wir ohnehin bereits Kickstart zur Automatisierung unserer Installationen verwenden, fiel die Wahl leicht. Mit Kickstart lassen sich grundlegende Konfigurationen wie Partitionierung oder die Auswahl von Softwarepaketen bereits während der Installation automatisieren.
Schlussendlich haben wir den Ansatz des Inplace-Upgrades in unsere Kickstart-Konfiguration aufgenommen, so dass während der automatisierten Installation das alte Partitionierungsschema des PVC-4.7-Servers beibehalten wird und vor allem die Partition „/vz“ unangetastet bleibt. Alle anderen für uns wichtigen Installationskonfigurationen für das neue PCS6 konnten wie gewohnt per Kickstart ausgerollt werden, um den Server danach wieder hochzufahren und die dort liegenden Container zu starten.
Abbildung 1 zeigt die Kickstart-Anpassung bezüglich der Partition „/vz“.
#we dont want to repartition, only format /dev/sda[1-3]
#leave /dev/sda4 alone and mount it as /vz
clearpart --none
part /vz --fstype ext4 --grow --noformat --onpart sda4
Jetzt geht es ans Eingemachte: 80 Server mit Live-VEs auf selbst entwickelte Art upgraden
Ein neuer Weg macht stolz, nachdem er erfolgreich beschritten worden ist. Davor macht er Stirnfalten. Vor allem bei der Frage: Mit wie viel Downtime müssen unsere Kunden rechnen? Für die größtmögliche Sicherheit folgten zunächst ausführliche Tests mit nicht produktiven Servern. Dank der Prozessparallelisierung durch die Kickstart-Automatisierung der Reinstallationen und einigem Feilen am Prozess benötigten wir vom Herunterfahren der Container bis zu ihrem Neustart auf dem neuen Betriebssystem etwa 45 Minuten.
Damit waren wir sicher, dass der Weg funktioniert, und ein Team aus sechs Kolleginnen und Kollegen machte sich in vier Nachtaktionen an die Arbeit. Wie sich das damals angefühlt hat, wurde von Golem dokumentiert. So viel sei verraten: Größere Probleme oder Ausfälle sind nicht entstanden.
Unser Fazit: Mit diesem Weg haben wir viel Zeit und Arbeit gespart, verglichen mit dem Aufwand, alle Container einzeln zu migrieren. Zugleich hat das Projekt gezeigt, dass wir bereit sind, neue und gelegentlich ungewöhnliche Wege zu gehen. Dafür gab es sogar anerkennende Worte der Virtuozzo-Entwickler.
