Ein virtueller vCenter-Server ist gefährlich: Realität oder virtuelle Ketzerei?

Administratoren müssen sich fragen, wie verlässlich ein virtueller vCenter Server ist. Funktionen wie HA und Heartbeat sichern die Komponente ab.

Wir setzen VMwares vSphere ein, um damit einige der wichtigsten Server und Applikationen für unser Unternehmen zu schützen. Wäre es somit nicht sinnvoll, auch vCenter diesen Schutz zu spendieren? VMwares Entscheidung, eine virtuelle vCenter-Appliance auszugeben, animiert Administratoren, einen ausschließlich virtuellen Ansatz zu fahren. Mit VMware High Availability, vCenter Server Heartbeat und Distributed Resource Scheduler hat VMware diesen Umstand sehr gut geplant. All diese Funktionen wurden geschaffen, um einen virtuellen vCenter-Server ausreichend im Problemfall abzusichern. Können wir uns darauf aber wirklich verlassen?

Man wird mich möglicherweise für die nachfolgende Aussage als Ketzer bezeichnen, aber ich persönlich bevorzuge ein physisches vCenter, das sich außerhalb der VMware-Infrastruktur befindet. Bevor Sie nun die Augen verdrehen, sehen wir uns gemeinsam ein Beispiel an. Verlasse ich das Haus, schließe ich die Tür, nehme aber nicht immer meinen Haustürschlüssel mit. Stattdessen verlasse ich mich auf den Garagentüröffner. Somit ist mein Haus sicher und der Schlüssel darin auch. Das funktioniert alles hervorragend, solange es zu keinem Problem mit der Elektrizität kommt und sich mein Garagentor nicht mehr länger öffnet. Das vCenter in die gleiche virtuelle Umgebung zu stecken, die Sie damit managen, ist in Ordnung. Allerdings darf es dann niemals zu einem Problem kommen, mit dem VMware High Availabilty (HA), vCenter Heartbeat oder Distributed Resource Scheduler nicht fertig werden. Wie wahrscheinlich ist das?

All diese Funktionen wurden entwickelt, um vCenter im Falle eines Problems zu schützen. Aber können wir ihnen trauen?

Vor ein paar Jahren habe ich für ein sehr großes Unternehmen gearbeitet, dem das komplette Data Center ausgefallen ist. Es waren alle Geräte betroffen. Dazu gehörten Switches, SANs (Storage Area Networks), Server und Klimaanlagen. Der Ausfall wurde durch eine Person verursacht, die aus Versehen den Notausschalter für den Strom gedrückt hatte. Sobald der Strom wieder da war, haben sich unsere ESX-Hosts gestartet und entsprechend die virtuellen Maschinen (VM) nach und nach wieder hochgefahren. Allerdings waren die Storage-Komponenten noch nicht wieder online. Aus diesem Grund funktionierte VMware HA nicht richtig und befand sich in einem instabilen Zustand, weil die Hosts ohne verfügbares Storage online waren. Wir brauchten ein funktionierendes vCenter, um den instabilen Zustand zu korrigieren. Nachdem das Storage wieder verfügbar war, haben wir dann die Hosts und virtuellen Maschinen hochgefahren.

In diesem Beispiel war vCenter auf einem physischen Server installiert, der sich außerhalb der virtualisierten Umgebung befindet. Da wir Zugriff auf diese entscheidende Ressource des Data Centers hatten, konnten wir der virtuellen Infrastruktur binnen einer Stunde wieder Leben einhauchen. Wäre vCenter virtualisiert gewesen, hätten wir es zunächst auf dem korrekten Storage-LUN lokalisieren müssen. Danach wäre ein einzelner Host notwendig gewesen und wir hätte vCenter manuell hinzufügen müssen. Nur so hätten wir Zugriff auf unsere zentrale Management-Konsole erhalten. Erst danach hätten wir VMware HA reparieren und somit den Rest der Infrastruktur wieder lauffähig machen können. Das Ereignis involvierte vSphere 4.1. Natürlich hat es in der Zwischenzeit Verbesserungen gegeben, die nun solche Arten an Problemen möglicherweise verhindern. Ich habe aber niemanden gefunden, der mir sein Data Center geliehen hätte, um die Geschichte mit vSphere 5.5 auszuprobieren.

Möglicherweise können Verbesserungen in vSphere 5.5 und HA diese Management-Katastrophe verhindern. Dennoch müssen wir uns damit beschäftigen, wie ein virtueller vCenter-Server wieder startet. Im Falle einer Wiederherstellung würde HA vCenter starten. Allerdings würden auch alle virtuellen Maschinen gestartet, die mit Priorität „high“ markiert sind. In einer großen Umgebung sind das möglicherweise Hunderte an VMs. In diesem Fall können Sie lediglich warten, bis vCenter reagiert und antwortet. Sie haben keine Einblicke bezüglich des Fortschritts oder ob es ein Problem gibt, da Sie keinen Zugriff auf die zentrale Administrations-Komponente haben. Status-Updates an Kunden oder die Geschäftsleitung geben zu wollen oder müssen, wenn Sie keine Informationen über den Fortschritt haben, ist eine sehr unbequeme Situation.

VMware drängt auf die virtuelle vCenter-Appliance. Kommende Versionen setzen möglicherweise voraus, dass wir ein virtuelles vCenter in der gleichen Umgebung haben, die wir damit managen. Allerdings sollten wir über den Tellerrand sehen. VMware ESXi ist kostenlos und es gibt keine Speicher-Einschränkungen. Somit könnten wir vCenter auf einem einzelnen Host mit lokalem Storage und Backup installieren. Auch der Einsatz von vCenter Heartbeat ist denkbar, damit wir Ausfallsicherheit in Bezug auf die Hardware haben. Ohne Cluster oder HA wissen wir genau, wo sich vCenter befindet. Somit besitzen wir einen definierten Anfangspunkt, um das virtuelle Data Center wiederherstellen zu können. Im Falle eines Desasters ist ein klarer Ausgangspunkt einer der wichtigsten Faktoren für die Wiederherstellung.

Artikel wurde zuletzt im Mai 2014 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über VMware

3 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

Close