DrHitch - Fotolia

vSphere-Katastrophen mit einfachen Architekturdesigns vermeiden

Bei der Planung von vSphere-Umgebungen sollten komplexe Architekturen vermieden werden. Je komplexer das Design, umso fehleranfälliger wird es.

Eine der größten Herausforderungen beim Design der vSphere-Architektur sind kundenspezifische Anpassungen. Wenn eine Bereitstellung geplant wird, sollten sich Administratoren daher immer fragen, inwieweit die Standardeinstellungen von ESXi und Co. wirklich angepasst werden müssen und wie sehr sich entsprechende Änderungen auf andere Designentscheidungen für die vSphere-Umgebung auswirken.

Bei der Auswahl der einzelnen Komponenten für die vSphere-Umgebung gibt es einige untypische Optionen, die so manches häufige Problem beseitigen helfen können. Dabei haben diese Lösungen aber meist den Nachteil, dass sie von kleineren Unternehmen nicht anwendbar sind, die keine eigene IT-Abteilung haben.

Diese Unternehmen müssen stattdessen auf externes Fachwissen zurückgreifen, wenn es um Design, Implementierung und Betrieb der vSphere-Infrastruktur geht.

Vorsicht beim Design der vSphere-Umgebung

Vor kurzem wurde ich bei einem Problem mit dem iSCSI-Array einer VMware-Umgebung zurate gezogen, dem die Festplattenkapazität ausgegangen war. Um dieses Problem zu lösen, wurden Design, Implementierung und Management der virtuellen Umgebung an einen externen Dienstleister ausgelagert. Um die Kosten gering zu halten, nutzte der Dienstleister Thin Provisioning sowohl bei Array als auch bei den virtuellen Maschinen – aber offenbar hatte keine der beiden Parteien die freie Festplattenkapazität im Blick.

Die Folge war ein mehrtägiger, vollständiger Ausfall der virtuellen Maschinen. Auch wenn die unmittelbare Ursache sicher im fehlenden Monitoring zu suchen ist, deutete das gesamte Verhalten des Arrays auf ein viel tiefersitzendes Problem hin. Letztendlich war das Architekturdesign viel zu komplex für so eine kleine Umgebung. Thin Provisioning für virtuelle Maschinen und Storage mag eine schnelle Lösung für große Unternehmen sein, die sowohl die virtuellen Maschinen als auch den VM-Storage und das Array überwachen können. Für kleine Unternehmen mit nur einem IT-Generalisten ist diese Strategie aber äußerst riskant.

Thin Provisioning sowohl für VMs als auch für Storage ist aber nicht die einzige riskante Designentscheidung für vSphere. In einem anderen Unternehmen wurden zum Beispiel verteilte Switches für Netzwerk und virtuellen Speicher von einem Remote-Office aus bereitgestellt. Das Problem dabei: Sie waren so konfiguriert, dass jede einzelne Wartungsaufgabe für ESXi-Hosts oder Storage-VMs in einer ganz bestimmten Reihenfolge durchgeführt werden mussten. Wurde diese Reihenfolge nicht eingehalten, dann wäre der virtuelle Speicher nicht mehr erreichbar gewesen, genauso wie jede virtuelle Maschine inklusive vCenter.

Bei einem sorgfältigen Umgang mit der Umgebung hätte man einen Systemausfall vielleicht vermeiden können, aber wie das meistens so ist traf auch dieses Unternehmen ein großflächiger Serverausfall. Das Unternehmen hatte zwar ein recht großes IT-Team im Einsatz, dessen Mitarbeiter waren aber mit den Designentscheidungen nicht vertraut und wohl auch mit der Komplexität überfordert, was letztlich zu noch größeren Problemen führte.

Ausfälle durch reduzierte Komplexität vermeiden  

Die beste Möglichkeit, diese Art Fehler zu verhindern, ist eine möglichst geringe Komplexität beim Design der vSphere-Umgebung. Der erste Schritt hierzu wäre zum Beispiel, die Konfiguration von ESXi- und Storage-Systemen so weit wie möglich an die Minimalanforderungen des Kunden anzupassen. Anstatt komplexe Designelemente einzuplanen, sollte bei jeder Entscheidung die einfachste Wahl für das jeweilige Problem getroffen werden. Eine Erhöhung der Komplexität sollte wirklich nur dann erfolgen, wenn sich daraus klare Vorteile für den Kunden ergeben.

Darüber hinaus gibt es beim vSphere-Design für kleinere Unternehmen einige Punkte, die generell beachtet werden sollten. Hier sollte man zum Beispiel bedenken, dass die IT-Systeme, die für einen Kunden geplant werden, wohl eher selten zur Kern-IT des Unternehmens gehören werden. Das dürfte die Aufmerksamkeitsspanne, was technische Details für Management und Betrieb der Umgebung bei der Übergabe an den Kunden betrifft, deutlich schmälern.

Gerade kleinere Unternehmen haben typischerweise keine gute Dokumentation ihrer Systeme, und wenn sie doch existiert, dann ist es oft schwer und zeitraubend, im Notfall die richtigen Punkte zu finden. Die Pflichten des Kunden sollten also überdeutlich kommuniziert werden.

Zudem sollte man beachten, dass man bei einem Problem in der Umgebung des Kunden manchmal nicht direkt erreichbar ist. In dieser Situation wird ein Kollege einspringen, der dann das Troubleshooting mit dem Kunden durchführen muss. Um hier Verwirrung zwischen Kollegen und Kunden vorzubeugen, sollte man sich von Anfang an Standardverfahren bei der Problemlösung angewöhnen und unternehmensweit ausrollen.

Komplexität sollte von Haus aus nur dann akzeptiert werden, wenn daraus keine zusätzlichen Management-Aufgaben entstehen. Ein Beispiel hierfür wären hyperkonvergente Systeme, bei denen der Anwender die Komplexität des Storage-Managements nicht mehr bemerkt. Natürlich gibt es auch bei hyperkonvergenten Lösungen noch viel Management-Bedarf, dessen Komplexität wird aber durch den Softwarestack abgefangen, wodurch Anwender einem einfach zu verwaltendem System gegenüberstehen.

Gerade für kleine Unternehmen ist eine einfache und leicht zu verstehende Infrastruktur ein absolutes Muss. Umso einfacher das vSphere-Design aufgebaut ist, umso geringer ist auch das Risiko von unnötigen Problemen. Wenn man trotzdem unbedingt Komplexität hinzufügen will, dann sollte darauf geachtet werden, dass sie ähnlich wie bei hyperkonvergenten Produkten soweit wie möglich vor dem Anwender verborgen bleibt.

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

Artikel wurde zuletzt im April 2016 aktualisiert

Erfahren Sie mehr über Containervirtualisierung

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close