VMware-Patches wie Firmware-Updates behandeln

Zentrales Management schafft einen größeren Wirkungsbereich

Allein die Möglichkeit, vMotion und andere Live-Migrations-Tools zu nutzen, um Gäste und Daten ohne Unterbrechung von einem Host zum anderen zu verschieben, sollte jede Debatte überflüssig machen. Aber das ist nur ein kleiner Teil des Puzzles.

Patches und andere Upgrades können in virtualisierten Umgebungen Elemente beeinflussen, die sich über eine große Anzahl von Hosts erstrecken. Selbst einfache Upgrades können sich gravierend auswirken, wenn sie vCenter oder ein anderes zentrales Management-Hypervisor-Tool einbeziehen. Es ist hoch problematisch, wenn Upgrades nicht reibungslos ablaufen, weil die Virtualisierung aufgrund ihres umfassenden Fußabdrucks das Ausmaß des Schadens erheblich vergrößern kann. Das macht VMware-Patches eher zu Firmware- als zu Software-Updates.

Die Komplexität der VMware-Verbindungen

Um die Dinge noch ein wenig herausfordernder zu machen: Normalerweise können Sie Änderungen an einer gastorientierten Software oder einer einzelnen Anwendungssoftware rückgängig machen, wenn sich die Änderungen als Fehlgriff erwiesen haben. Das Gleiche gilt allerdings nicht für Virtualisierungs-Software. Das hat nichts damit zu tun, dass VMware-Patches in der Regel größer sind als herkömmliche Updates. Es hat vielmehr mit der Komplexität und der Verknüpfung der Software mit anderen Aspekten des Systems zu tun.

Im Gegensatz zu anderen Softwareplattformen beinhaltet der Software-Stack von VMware viele bewegliche Teile. Jedes dieser Teile hat einen eigenen Namen und eine eigene Build-Nummer. Das bedeutet, dass es sich bei allen Produkten, aus denen sich eine Softwareinfrastruktur zusammensetzt, zum Beispiel NSX, vRealize und vSAN, um die richtige Version handeln muss, bevor ein größeres Update gemacht werden kann.

Diese Abhängigkeit ist für Administratoren eine große Herausforderung, da sie mehrere kleinere Upgrades benötigen. Solche zerstückelten Upgrades können schwieriger zu verwalten und eine Genehmigung dafür kann schwerer zu bekommen sein – im Gegensatz zu nicht virtualisierten Systemen, bei denen man alles auf einmal erledigen kann.

Sollen Updates konsolidiert oder einzeln bearbeitet werden?

Obwohl ein Patching in mehreren Schritten nicht ideal für kritische Infrastrukturen ist, ist es eine gefährliche Option, auf das Patching zu verzichten. Es würde die gesamte Infrastruktur anfällig für Sicherheitsrisiken und Instabilität machen. Während der monolithische Ansatz für VMware-Patches Zeit sparen und das Testen konsolidieren kann, kann der Wiederherstellungsprozess schwierig, wenn nicht unmöglich sein, falls etwas nicht funktioniert.

Der gestückelte Ansatz erfordert hingegen mehr Schritte, mehr Papierkram und kürzere, aber häufigere Stillstandszeiten. Dieser Ansatz lässt sich aber besser kontrollieren, und da man sich ohnehin mit dem gestückelten Ansatz des VMware-Stacks auseinandersetzen muss, ist es auch die natürlichere Lösung.

Wie sollte man vorgehen? Sie können mit Schlüsselkomponenten wie Hosts oder unterstützenden Produkten beginnen und sichere Upgrades machen, bevor Sie zu den größeren und komplexeren Produkten wie vCenter oder NSX übergehen. Dies hilft auch innerhalb des VMware-Produkt-Stacks.

Es ist wichtig zu wissen, dass ein schrittweiser Ansatz Sie nicht schützt, wenn ein größeres Produkt, wie zum Beispiel ein vCenter oder NSX, nicht aktualisiert werden kann und Ihre Umgebung beschädigt. Es beseitigt jedoch einige der Zweifel und Risiken, die bis zu diesem Zeitpunkt bestehen.

Komplexe Upgrades erfordern eine sorgfältige Abstimmung

Wie immer im Leben kommt es auf die Mitte an: Am besten finden Sie einen Mittelweg zwischen zu seltenem und zu häufigem Patchen. Die Firmware Ihres Rechenzentrums beispielsweise wird häufig auf Basis eines vierteljährlichen oder halbjährlichen Zeitplans aktualisiert.

Dies sollte auch für VMware-Patches funktionieren – es sei denn, es handelt sich um ein sofort zu lösendes Problem oder um ein kritisches Sicherheitsproblem. Wenn es Ihnen möglich ist, fangen Sie immer klein an, und erledigen Sie zuerst die weniger kritischen Aspekte. Oder noch besser: beginnen Sie wenn möglich mit den Test- und Entwicklungsumgebungen.

Verwenden Sie die Migrations-Tools nach Bedarf, aber denken Sie daran, dass es sich bei diesen Tools nicht um echte Backup- oder Disaster-Recovery-Produkte handelt. Wenn Sie also eine zentrale Systemkomponente upgraden und Ihre gesamte Infrastruktur zerstört wird, müssen Sie auf andere Weise eine Wiederherstellung erreichen.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!