everythingpossible - Fotolia

Neue Funktionen von vSphere 5 erfordern vorsichtiges Vorgehen

Manche Funktionen der Version 5 von VMware vSphere sollten mit Bedacht eingesetzt werden. Der Artikel zeigt, wie.

Viele IT-Anwender wechseln im Rahmen ihrer üblichen Upgrade-Zyklen auch zur neuesten Version der Virtualisierungs-Software vSphere von VMware. Doch in vSphere 5 gibt es einige neue oder erweiterte Storage-Möglichkeiten, die manche dazu bringen, aufzuhorchen.

Zu den besonderen Möglichkeiten für Storage bei vSphere 5 zählen der Storage Distributed Resource Scheduler (DRS), das aktualisierte Virtual Machine File System und Profile-Driven Storage. Mehrere Kunden, die diese Funktionen ausprobiert haben, bezeichnen sie als wertvoll – raten aber auch dazu, vorsichtig damit umzugehen.

Storage DRS

Mit Storage DRS können Nutzer die Ressourcen mehrerer Storage-Volumes zu einem einheitlichen Pool vereinen und darin die Lasten so verteilen, dass die einzelnen Volumes nicht zu voll und/oder zu I/O-Nadelöhren werden. Die neue Funktion hat Ähnlichkeit mit dem Server-seitigen DRS, das VMware bereits vorher angeboten hatte; in dieser Form diente es der automatischen Verschiebung von virtuellen Maschinen (VMs) zwecks Load-Balancing für CPUs und Arbeitsspeicher.

„Nach meinen Erfahrungen funktioniert das Kapazitäts-Balancing gut“, sagt Ed Czerwin, leitender Systemingenieur und Virtualisierungs-Experte bei einem großen Hersteller von Medizintechnik in der Schweiz. Vorher habe er den Mitarbeitern sagen müssen, dass sie eine VM auf eine bestimmte LUN legen sollen. Heute dagegen reiche es aus, den Cluster anzugeben, und der übernehme dann das Balancing. „Ich muss nicht mehr so sehr Platz hinterher jagen.“

Laut Czerwin kann er einem Cluster für Storage-DRS jetzt einfach einen Plattenspindel-Typ zuweisen und angeben, auf welchem Cluster Betriebssystem sowie Log- und Datenbank-Dateien der Virtual Machine Disk (VMDK) liegen. Sein Unternehmen hat mehr als 95 Prozent seiner Server virtualisiert, unter anderem die für das ERP-System von SAP und den Exchange-Server; als wichtigste Storage-Stufen (Tier) kommen Symmetrix von EMC und VNX zum Einsatz.

Storage DRS hat auch das Interesse von Bob Plankers geweckt, der als Virtualisierungs-Architekt bei einer großen US-Universität arbeitet. Plankers wollte für die VMs der Hochschule Storage nach dem Prinzip Thin Provisioning einrichten, so dass die IT-Abteilung statt nach zugewiesenem nach tatsächlich genutztem Storage abrechnen kann. Nach seinen Worten lässt sich mit Storage DRS vermeiden, dass einer VM der Speicherplatz ausgeht; dies geschieht über das Starten von Storage vMotion, bei dem VMDK-Dateien ohne Betriebsunterbrechung auf unterschiedliche Storage-Arrays verschoben werden können.

Dazu richtet Plankers, wie er berichtet, VMFS-Datastores mit einer Standardgröße von 2 Terabyte ein und ordnet sie einem Storage-DRS-Cluster zu. In der Konfiguration stellt er dann ein, dass der noch zur Verfügung stehende Speicherplatz niemals unter 200 Gigabyte fallen darf. „Das löst drängende Probleme“, sagt er.

Allerdings bezeichnet Plankers Storage DRS als „im Prinzip noch ein 1.0-Produkt“ mit Problemen bei der Bedienoberfläche und Fehlern. So habe er das Format einer VM-Disk nicht auf Thin Provisioning umstellen können, während er die VM mit Hilfe von Storage vMotion auf einen bestimmten Datastore-Cluster verschob. „Es gibt einen Workaround dafür: Man muss Storage DRS für die VM vorübergehend deaktivieren, sie auf einen der Cluster-Datastores migrieren und anschließend Storage DRS wieder aktivieren“, erklärt Plankers. Das sei zwar keine große Sache, aber doch etwas lästig, wenn man es wie er selbst mit 600 VMs machen müsse.

Cormac Hogan, leitender Architekt für technisches Marketing bei VMware, räumt ein, dass ein manueller Prozess mit zusätzlichen Schritten nötig ist. Allerdings lasse sich das Problem mit dem einfachen Befehl SCSI Unmap aus den vStorage APIs for Array Integration (VAAI) abmildern. Jedoch können diesen nicht alle Storage-Arrays verarbeiten.

Mehrere Kunden, die diese Funktionen ausprobiert haben, bezeichnen sie als wertvoll – raten aber auch dazu, vorsichtig damit umzugehen.

Chris Hansen, System-Manager am Gordon College im US-Bundesstaat Massachusetts, zögert aus einem anderen Grund mit dem Einsatz von Storage DRS: Er fürchtet, dass es zu Problemen mit der automatischen Tiering-Funktion der an der Hochschule eingesetzten Arrays des Typs Dell Compellent führen würde. „Ich glaube, beides würde sich einfach bekämpfen“, sagt Hansen.

Dazu äußert sich in einem Blog-Beitrag Frank Dennemann, ein leitender Architekt im Marketing-Team von VMware: Storage DRS lasse sich durchaus in Kombination mit Array-basiertem Auto-Tiering verwenden. Dies gelte allerdings nur für die anfängliche Einrichtung und die Funktionen zur Vermeidung von Kapazitätsüberschreitung. Die Aktivierung der Funktion I/O-Metrik, allgemein eher bekannt unter Load-Balancing für I/O, dagegen sei nicht zu empfehlen.

Neuerungen bei VMFS-5

Für Hansen gab es zwei Hauptgründe für den Umstieg auf vSphere 5: die Erweiterungen in VMFS-5, durch die Nutzer jetzt VMFS-Datastores/Volumes mit bis zu 64 Terabyte Kapazität auf einem Single Extent (also einer einzigen Partition auf dem Storage-Gerät oder der LUN mit dem VMFS-Volume) anlegen können, und die Möglichkeit, für VMDK-Dateien eine einheitliche Block-Größe von 1 MByte festzulegen.

Kunden hätten schon längere Zeit nach dieser Änderungen beim Datastore gefragt, sagt dazu Mike Adams, Group Manager für Produkt-Marketing bei vSphere. Auch mit VMFS-3 hätten sich schon Datastores mit bis zu 64 TB anlegen lassen, doch dafür waren mehrere Extents nötig – die Maximalgröße eines Extents unter VMFS-3 lag bei 2 TB.

Diese Beschränkung sei für ihn „so etwas wie ein Alptraum für die Wartung“ bei besonders großen Dateien mit VMDK-Daten und Servern mit großem Kapazitätsbedarf gewesen, sagt Hansen. So habe das Cordon College einem einzelnen Backup-Server für die Endnutzer acht Datastores zuweisen müssen.

Manchmal behalf sich das IT-Team des College laut Hansen damit, die virtuelle Maschine mittels Raw Device Mapping (RDM) direkt an das SAN anzubinden. So geht es noch heute bei Servern vor, deren VMDK-Dateien größer als 2 TB sind – für VMDK gilt diese Grenze weiterhin. Der Hauptnachteil bei diesem RDM-Ansatz liegt darin, dass mit SAN-Replikation gearbeitet werden muss. Außerdem ist es notwendig, das System während der Verlagerung eines Servers von einem Rechenzentrum in ein anderes Data Center heruntergefahren. Andernfalls wäre es möglich, die Migration mit Hilfe von Storage vMotion von VMware ohne Unterbrechung vorzunehmen.

Mit schlank provisionierten VMDK-Dateien musste die Hochschule dabei eine unangenehme Erfahrung machen. Zwei Dateien, die anfangs nur rund 100 GB groß gewesen waren, wuchsen auf jeweils etwa 1 TB an. Dadurch war der Datastore voll ausgefüllt, und der Anwendungsserver stürzte ab. Mithilfe von Storage vMotion, so Hansen, habe er dann eine der großen VMDK-Dateien auf einen anderen Datastore verlagert. Trotzdem sei der Server eineinhalb Tag lang ausgefallen, weil er sich nicht wieder in Betrieb nehmen ließ, bevor es genügend Platz auf seinem Datastore gab.

„Zu unserem Glück handelte es sich dabei um einen redundanten Backup-Server – die Kopie einer Kopie. Deshalb waren die Nutzer davon nicht betroffen“, berichtet Hansen, „aber wenn wir heute dasselbe Problem hätten, wäre es nur noch eine Sache von Minuten, den Datastore zu vergrößern und dann wieder online zu gehen“.

Die zweite für Hansen nützliche Funktion ist die Möglichkeit, für Dateien zu einer einheitlichen Block-Größe von 1 MB zu kommen. Vor VMFS-5 mussten Nutzer abhängig von der Größe der Virtual Machine Disk-Datei eine Block-Größe von 1 MB, 2 MB, 4 MB oder 8 MB wählen. Eine VMDK-Datei mit einem Maximalvolumen von 256 GB erforderte 1-MB-Blocks, VMDK-Dateien bis 512 GB 2-MB-Blocks, Dateien bis 1 TB brauchten 4-MB-Blocks, bei VMDKs mit 2 TB musste die Block-Größe 8 MB betragen. „Man musste sich entscheiden, wie groß die VMDK-Datei sein soll“, erklärt Hansen.

Im Unternehmen von Czerwin kam es in diesem Zusammenhang zu Problemen: Beim Verschieben einer VMDK-Datei von einer Block-Größe auf eine andere mit Storage vMotion habe die Performance nachgelassen. Ebenfalls hätten Snapshots, die zwei Datastores umfassten, nicht funktioniert, wenn ihre VMDK-Dateien unterschiedliche Block-Größen hatten. „Es gab nur eine Möglichkeit, das zu reparieren: mit Storage vMotion die LUNs, die auf den Datastores mit der anderen Block-Größe liefen, auf einen passenden zu verschieben“, berichtet Czerwin.

IT-Anwender haben die Wahl: Sie können ohne Änderung der Block-Größe für Dateien von VMFS-3 auf VMFS-5 aktualisieren oder ganz neue VMFS-5-Volumes anlegen und die VMDK-Dateien mit Hilfe von Storage vMotion von den alten Volumes auf die neuen migrieren. „Wir empfehlen unseren Kunden, wenn möglich mit 1 MB Block-Größe neu anzufangen und dann die VMDK-Dateien von VMFS-3 zum neuen VMFS-5 zu verschieben“, sagt Hogan von VMware. So ließen sich die Vorteile der einheitlichen Block-Größe am besten nutzen.

Allerdings kann es viel Zeit kosten, VMDK-Dateien mit 2 MB, 4 MB oder 8 MB auf 1 MB zu migrieren – wie aufwendig das ist, hängt von der Umgebung und der Größe der Dateien ab. So erledigte das Gordon College die Aktualisierung von VMFS-3 auf VMFS-5 innerhalb eines Tages. Allerdings hatte das Team schon Monate zuvor damit begonnen, Dateien auf die bis dahin nur bei einer Handvoll Servern vorhandene Block-Größe von 1 MB zu migrieren.

„Alles Herüberzuholen ist ein Langfrist-Projekt“, sagt Hansen, „man startet den Prozess in Storage vMotion und lässt ihn ein paar Tage lang laufen. Dann ist er fertig, und man startet den nächsten. Es ist nicht so, dass man die ganze Zeit dasitzen und zugucken müsste, im Auge behalten sollte man es aber schon“.

Hinzu kommt beim Gordon College die Vorgabe, alle SAN-Daten 30 Tage lang repliziert aufzubewahren. Wenn das IT-Personal Migrationen vom alten in den neuen Datastore vornimmt, darf der alte Datastore also 30 Tage lang nicht gelöscht werden. „Selbst wenn man das außer Acht lässt, dauert schon das Verschieben eines Volume mit 2 TB mehrere Tage. Und natürlich lässt währenddessen auch die Performance der betroffenen Server nach“, sagt Hansen.

Letztlich allerdings rechtfertige das Endergebnis die Mühen durchaus, so Hansen – durch die geringere Block-Größe verbrauche die Hochschule jetzt pro Datastore weniger Storage-Platz. Zudem sei VMFS-5 „wirklich eine Erleichterung, weil man sich nicht mehr darum kümmern muss, welche Datastores welche Block-Größen haben“.

Profile-Driven Storage

Eine weitere Funktion in vSphere 5, die manche Kunden erfreulich finden, ist Profile-Driven Storage. Über diese können Administratoren für Storage oder Virtualisierung Service-Level für hohe, mittlere oder geringe Performance auf den Backend-Ressourcen für Storage abbilden, wie Adams von VMware erklärt.

Mit Hilfe der vStorage APIs for Storage Awareness (VASA) lässt sich diese Funktion laut Adams sogar noch weiter treiben und ein „Mechanismus zum intelligenteren Umgang mit der Erstellung von Storage-Profilen“ schaffen. Dabei kann der Array Informationen an vSphere liefern und so bei der Entscheidung darüber helfen, welches Storage verwendet wird. „In der Vergangenheit konnte es definitiv vorkommen, dass für eine neue virtuelle Maschine das falsche Storage verwendet wurde“, so Adams. Ebenso sei es nicht immer gelungen, die Ressourcen zu bekommen, die für das Erreichen eines bestimmten Service-Niveaus oder die Erfüllung einer Serviceniveau-Vereinbarung nötig waren.

Plankers allerdings sieht die Kombination aus Profile-Driven Storage und VASA derzeit noch als 1.0-Release an. Bislang hätten nur wenige Anbieter VASA auf ihren Arrays implementiert, so dass das Storage-System die für Entscheidungen der Administratoren nötigen Informationen liefert. „Die Idee dahinter ist, dass man einen Report bekommen und darin zum Beispiel sehen kann, was nicht dort ist, wo es sein sollte. Darüber hinaus gibt es aber bislang keine Automatisierung“, erklärt der Virtualisierungs-Architekt. Er hoffe darauf, dass die nächste Version bessere Möglichkeiten zur Problem-Behebung mitbringen werde.

VMware hat mittlerweile zwei weitere vSphere-Versionen auf den Markt gebracht: vSphere 5.5 und vSphere 6. Diese verfügen über essentielle Neuerungen für ESXi, vSAN und vCenter Server. Natürlich haben die neuen Versionen auch Auswirkungen auf das Storage. Darüber hinaus verfügt vSphere 6 über neue Instant-Cloning-Funktionen und optimierte Performance. Administratoren sollten hier über die Grundlagen, die Storage-Administration und die Änderungen für Single Sign-On, High Availability und Web Client Bescheid wissen.

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

Artikel wurde zuletzt im Mai 2016 aktualisiert

Pro+

Premium-Inhalte

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

Erfahren Sie mehr über Datenspeicherlösungen für virtuelle Server

0 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

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close