freshidea - Fotolia

Tipps zur Vermeidung häufiger Fehler in VMware-Umgebungen

Das Management virtueller Umgebungen ist eine komplexe Angelegenheit. Diese häufigen Fehler gilt es in VMware-Umgebungen zu vermeiden.

Die meisten Ratschläge für VMware-Administratoren beinhalten Empfehlungen, wie man mit seiner virtuellen Umgebung umgehen sollte. Daher wird es vielleicht einfach auch einmal Zeit zu zeigen, was VMware-Admins lieber nicht tun sollten. Manche dieser typischen VMware-Fehler lassen sich leicht reparieren – andere können schwere, jobgefährdende Konsequenzen haben!

Die folgenden Tipps beanspruchen natürlich keine Vollständigkeit, es handelt sich eher um häufige Fehler, die System-Administratoren in VMware-Umgebungen immer wieder unterlaufen, und die zu kennen daher nicht schaden kann.

Grundlegende VMware-Fehler

Einer der einfachsten Tipps bezieht sich auf das Herunterfahren eines Hosts. Dies sollte immer über Desktop oder Web Client erfolgen, man sollte aber nie den Fehler machen und über die SSH-Konsole einen Reboot anstoßen. Klar, das ist möglich, und solange sich der Host im Wartungsmodus befindet, dürfte es hierbei auch keine Probleme geben. Schwierig wird es erst, wenn man per SSH-Konsole aus Versehen den falschen Host neu startet – und sich dieser nicht im Wartungsmodus befindet. Auch wenn es etwas mehr Zeit in Anspruch nimmt, der Weg über Web und Desktop Client ist doch der sicherere.

Ein ebenfalls häufig wenig beachteter Bereich ist die Cluster Admission Policy, obwohl das richtige Verständnis hiervon eigentlich für jeden VMware-Admin unabdingbar ist. Wenn die Cluster Admission Policy abgeschaltet werden soll, dann muss unbedingt das Vorhandensein von ausreichend Storage-Kapazität sichergestellt werden, um bei einem Ausfall auch die Last der größten Hosts übernehmen zu können. In vielen Fällen gehen Probleme hierbei auf ein ungeplantes Befüllen der Server-Racks zurück, ohne dass Gedanken an den späteren Support der Infrastruktur verschwendet werden. Es ist ganz einfach keine gute Idee, zu viele virtuelle Maschinen auf zu wenige Hosts zu verteilen.

In vielen Unternehmen kommen Highend-Server zum Einsatz, die mit mehr als 100 virtuellen Maschinen pro Host bestückt werden. Das funktioniert dann solange, wie der Host nicht in den Wartungsmodus geschaltet werden muss oder aus irgendwelchen Gründen abstürzt. 100 virtuelle Maschinen auf anderen Servern im Cluster neu zu starten wird eine große Lastspitze verursachen und dabei ziemlich sicher auch I/O-Spitzen verursachen. Zudem gibt es eine Begrenzung von lediglich acht virtuellen Maschinen, die gleichzeitig neu gestartet werden können. Dadurch werden manche Server zunächst in einer Warteschlange festhängen, was die Ausfallzeit zusätzlich erhöht.

In ähnlicher Weise ist es keine gute Handlungsempfehlung, Storage lokal nur an einem Host zur Verfügung zu stellen. Damit wäre eine virtuelle Maschine schlicht an einen bestimmten Host gebunden. Im Fall eines Host-Ausfalls könnte diese virtuelle Maschine schließlich nicht auf einem anderen Host neu gestartet werden, weil ihr Speicher dann nicht mehr vorhanden ist.

In manchen VMware-Umgebungen finden sich auch „künstliche“ Cluster, die auf einem geteilten SCSI-Bus basieren und daher alle virtuellen Nodes auf dem gleichen physischen Host konzentrieren. Es sollte mehr als offensichtlich sein, dass dieses Vorgehen jede Design-Richtlinie von Hochverfügbarkeits-Clustern bricht.

Der Ausfall eines einzigen Hosts bedeutet in dieser Situation den Ausfall des gesamten Clusters. Das mag für eine Entwicklungsumgebung noch akzeptabel sein, für Produktivsysteme ist diese Konfiguration aber viel zu riskant. Auch VMware Fault Tolerance (VMware FT) ist kein Allheilmittel zur Vermeidung von Cluster-Problemen. Die Einschränkung auf nur eine CPU ist immer noch ein großes Hindernis für die weitere Verbreitung von VMware FT.

Fehlerrisiko Versions-Update

Bei den komplexeren Problemen in VMware-Umgebungen stehen große Versions-Updates wohl an erster Stelle. Ein Fehler während eines Upgrade-Prozesses kann leicht zu einem Ausfall von Gast-VMs führen, vor allem wenn externe Datenbank-Hosts involviert sind. Ohne zentrales Management wird es für Admins in dieser Situation sehr schwierig.

Auch Snapshots helfen in dieser Situation nicht weiter. Bei einem Upgrade wird normalerweise auch das Datenbankschema aktualisiert. Nach diesem Punkt zu einem früheren Snapshot zurückzukehren, setzt die Datenbank einem großen Risiko aus, in den meisten Fällen wird dann die vCenter-Datenbank unbrauchbar. Spätestens an diesem Punkt führt dann kein Weg mehr an einer Wiederherstellung von vCenter und der Datenbank vom Backup vorbei – wenn man die Möglichkeit hierzu hat. Es hat schon seinen Grund, warum VMware keine In-Place-Upgrades empfiehlt. Nebenbei bemerkt ist das Aktualisieren einer vCenter Appliance wesentlich einfacher und geradliniger.

Wenn in einer Infrastruktur Thin Provisioning eingesetzt wird, dann sollte dies entweder für das Storage Array oder auf der VMware-Seite durchgeführt werden, auf keinem Fall für beide Komponenten. Andernfalls erfolgt das Thin Provisioning doppelt, was zu enormen Problemen führen kann. Daher sollten Storage-Einstellungen Cluster-weit eingesetzt werden.

Der letzte Tipp wird vor allem von unerfahrenen Administratoren gerne übersehen und bezieht sich auf die Hardware-Kompatibilitätsliste (HCL) für von VMware unterstützte Hardwarekonfigurationen. Obwohl man zugeben muss, dass eigentlich fast jegliche Hardware ganz gut mit VMware funktioniert, kann es im Support-Fall durchaus Probleme geben, wenn nicht offiziell unterstützte Hardware eingesetzt wird. Das sind genau die Dinge, die man nicht hören will, wenn man gerade einen Serverausfall hat. Dieses Risiko sollte man daher gar nicht erst eingehen und von vorneherein nur offiziell unterstützte Hardware einsetzen.

Es gibt sehr viele Dinge, die man in VMware-Umgebung lieber lassen sollte, und die hier angeführten Beispiele kratzen sicherlich nur an der Oberfläche. Der gesunde Menschenverstand ist meist das beste Admin-Tool, dicht gefolgt von einer gewissen Vorsicht bei der Implementierung neuer IT-Ressourcen. Abgesehen davon ist natürlich auch die IT-Administration Erfahrungssache – und da sind gewisse Fehler wohl unvermeidlich.

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

Artikel wurde zuletzt im November 2015 aktualisiert

Erfahren Sie mehr über Containervirtualisierung

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close