Storage im Blick: Hypervisor-Vergleich zwischen ESXi, Hyper-V und KVM

Ein reiner Funktionsvergleich greift bei der Wahl zwischen ESXi, Hyper-V und KVM zu kurz. Entscheidend ist, wie die Hypervisoren mit Storage umgehen.

Auch wenn VMware bei Hypervisoren der Enterprise-Klasse schon lange als Klassenprimus gilt gibt es natürlich auch...

noch andere Anbieter auf dem Markt. Microsofts mit Hyper-V zum Beispiel oder Red Hat mit KVM (Kernel-based Virtual Machine Hypervisor).

Jeder dieser Hypervisoren bietet interessante Funktionen, aber wenn Sie vor der Wahl für einen der drei stehen, dann ist ein reiner Funktionsvergleich nicht immer die beste Strategie. Umsichtige Administratoren sehen sich zunächst genau an, welche Storage-Arten der jeweilige Hypervisor in welcher Weise unterstützt. In diesem Beitrag wollen wir Ihnen daher einen Überblick über die verschiedenen Herangehensweisen dieser drei Hypervisor-Anbieter in Sachen Storage geben.

Red Hat KVM: Beachten Sie den Faktor Migration

Bei jedem Hypervisor gibt es bei Storage zwei Hauptpunkte zu beachten. Zunächst einmal sollten sich Administratoren schlau machen, welche Storage-Arten der Hypervisor für den Einsatz virtueller Maschinen (VM) direkt unterstützt. Behalten Sie dabei im Hinterkopf, dass sich nicht jeder unterstützte Storage-Typ automatisch für den Einsatz in einer produktiven Umgebung eignet. Zum Beispiel kann KVM mit Direct Attached Storage (DAS) für VM-Storage umgehen. Ist DAS im Einsatz, sind aber zum Beispiel keine Migrationen möglich.

Zweitens sollten Sie darauf achten, auf welche Arten von Storage von einer virtuellen Maschine aus zugegriffen werden kann. Anders gesagt: Mit welchem Storage kann die VM direkt umgehen? Das ist wichtig, weil sich virtuelle Maschinen oftmals mit externen LUNs (Logical Unit Number) via iSCSI oder virtuellem Fibre Channel verbinden. Deswegen sollten Sie sicherstellen, dass der Hypervisor externe Storage-Verbindungen für virtuelle Maschinen unterstützt.

Für Red Hats Open-Source-Plattform KVM ist es wenig überraschend, dass eine große Bandbreite an Optionen für VM-Storage unterstützt wird. Allerdings ist die Möglichkeit der VM-Migration für viele Storage-Profis ein unabdingbares Muss. Die Storage-Optionen von Red Hat sind in dieser Hinsicht limitiert.

Um von einer VM-Migration profitieren zu können, muss sich die virtuelle Maschine auf einem Shared Storage befinden. Der KVM-Server muss mit dem gemeinsam genutzten Storage unter Zuhilfenahme eines der nachfolgenden Protokolle kommunizieren können:

  • Fibre Channel,
  • iSCSI,
  • Fibre Channel via Ethernet,
  • Network File System (NFS),
  • Global File System 2 (GFS2),
  • SCSI Remote Direct Memory Access Protocol (SRP): Es handelt sich hier um ein Protokoll für den Block-Export, der in den Ethernet-Karten InfiniBand und Zehn GBit iWARP benutzt wird.

Wie bei VMware und Hyper-V basiert auch Red Hats VM-Migration auf dem Konzept, dass Memory-Pages von einem Host-Server auf einen anderen kopiert werden. Allerdings funktioniert Red Hats VM-Migration nicht, wenn Speicher-Updates häufiger auftreten, als es die Kopier-Rate zulässt. In solchen Situationen wird die VM-Migration also fehlschlagen. Für diese Fälle bietet VMware eine Funktion an, die die virtuellen Maschinen so weit verlangsamt, bis der Kopier-Prozess abgeschlossen ist. Damit ist eine erfolgreiche Migration garantiert.

Wie bei vSphere und Hyper-V gewährt auch KVM den virtuellen Maschinen Zugriff auf Remote-Storage durch verschiedene Protokolle. Die nachfolgenden Geräte und Protokolle werden unterstützt, um KVM-Gäste mit Remote-Storage zu verbinden:

  • Lokale Festplatten-Partitionen,
  • Logische Festplatten (Logical Volumes),
  • Host-Level Fibre Channel oder Verbindung via iSCSI,
  • Datei-Container mit einem sich darin befindlichen Dateisystem auf dem Host,
  • Ein NFS-Dateisystem, das direkt über das Host-Betriebssystem eingebunden ist,
  • iSCSI-Storage, das vom Gast-Betriebssystem initiiert wurde,
  • Cluster File System.

Red Hat bietet mit Red Hat Storage Server ein eigenes Software-definiertes Storage-Produkt an, das auch die empfohlene Storage-Option für KVM-Umgebungen ist. Es basiert auf dem Prinzip, dass sich herkömmliche Storage-Hardware in Storage-Pools virtualisieren lässt. Auf Anfrage wird dann den einzelnen VMs Storage zugewiesen. Die generelle Herangehensweise ähnelt Microsofts Funktion der Windows Server Storage Spaces, die Sie in Windows Server 2012 und Windows Server 2012 R2 finden.

VMwares Profil-basiertes (Profile-Driven) Storage bietet viele Vorteile

Wie auch KVM und Hyper-V unterstützt VMware die Migration laufender virtueller Maschinen von einem Host auf einen anderen. VMware bezeichnet diese Funktion als vMotion, die im Standard-Hypervisor nicht enthalten ist. VMware-Hosts müssen für den Einsatz von vMotion speziell lizenziert sein.

Vor ESXi 5.1 war gemeinsam genutztes Storage Voraussetzung für vMotion und wird auch heute noch empfohlen. Wird gemeinsam Shared Storage genutzt, muss der VMware-Host an dieses Shared Storage angebunden sein, damit jeder Host Zugriff darauf hat. VMware empfiehlt Fibre Channel Storage Area Network (SAN) für das Shared Storage. Der Einsatz von iSCSI und Network Attached Storage (NAS) ist aber ebenfalls möglich.

Bei ESXi 5.1 und späteren Versionen können Sie laufende virtuelle Maschinen auch ohne Shared Storage migrieren, dann muss sich die VM-Festplatte allerdings in einem persistenten Modus befinden. Auch der Einsatz von Raw Device Mappings (RDMs) ist möglich, dann muss der Ziel-Host allerdings Zugriff auf das RDM-LUN haben. Alternativ können Sie das Raw Device Mapping auch in eine Festplatten-Datei für virtuelle Maschinen konvertieren.

VMware und Microsoft unterstützen die Migration virtueller Maschinen von einem Storage-Ort zu einem anderen. VMware nennt diese Funktion Storage vMotion, Microsoft dagegen Storage Live Migration. Vor VMware 5.0 ließ sich Storage vMotion nur dann verwenden, wenn die entsprechenden virtuellen Maschinen keine Snapshots vorhielten. Ab VMware Version 5.0 können Sie auch virtuelle Maschinen mit Snapshots migrieren. Dennoch gilt, dass die VM-Festplatte persistent sein oder Unterstützung für RDM bieten muss.

Eine der einzigartigen Funktionen von vSphere 5.0 und höher ist das sogenannte Profile-Driven Storage. In VMware-Umgebungen werden die virtuellen Maschinen in Datastores eingesetzt, die wiederum als Abstraktion für das physische Storage dienen. Administratoren wählen einen Datastore in der Regel anhand der darunterliegenden Hardware aus. Zum Beispiel würde man eine virtuelle Maschine mit einer unternehmenskritischen Datenbank-Applikation wohl eher auf einen Datastore legen, der auf sehr leistungsstarkem Storage liegt.

Das Problem ist allerdings, dass virtuelle Maschinen natürlich alles andere als statische Gebilde sind. Profile-Driven Storage gibt Administratoren dabei Antwort auf die Frage, ob das unter einer VM liegende Storage noch mit der Anforderung im Einklang steht, die ursprünglich definiert wurde.

Hyper-V punktet mit Flexibilität

Microsoft Hyper-V feierte sein Debüt mit Windows Server 2008. Damals haben allerdings viele Funktionen gefehlt, die ein Enterprise-Hypervisor mit sich bringen sollte. Erst mit Windows Server 2012 hat Hyper-V diese Reife erreicht und wurde mit Windows Server 2012 R2 weiter verbessert. Meine Betrachtungsweise hier dreht sich entsprechend um die Hyper-V-Version in Windows  Server 2012 R2.

Was Storage betrifft, zeigt sich Hyper-V sehr flexibel. Laut Microsoft-Dokumentation kann Hyper-V mit nachfolgenden Komponenten umgehen:

Wie auch VMware unterstützt Hyper-V die Live-Migrationen mit und ohne Benutzung von Shared Storage. Trotzdem rät Microsoft zu Shared Storage, wann immer das auch möglich ist. Davon unabhängig muss die virtuelle Maschine so konfiguriert sein, dass sie entweder virtuelle Festplatten oder Fibre-Channel-Massenspeicher benutzt.

Die Benutzung physischer (Pass-Through-) Festplatten ist lediglich unter sehr spezifischen Umständen möglich. Um solche Festplatten-Typen live migrieren zu können, muss die virtuelle Maschine in einem Failover-Cluster laufen und sich die VM-Konfiguration gleichzeitig auf einem Cluster Shared Volume befinden. Zudem muss die physische Festplatte als Storage-Disk-Ressource unter der Kontrolle des Clusters konfiguriert sein.

Für Shared Storage unterstützt Hyper-V Fibre Channel, iSCSI und SMB 3.0. SMB-Storage war dabei noch bis zu Windows Server 2012 nicht möglich.

Mit Hyper-V virtualisierte VMs können sich mit sehr vielen Storage-Typen verbinden. Der limitierende Faktor in diesem Zusammenhang ist allerdings der Backup-Prozess. Online genutzte Backups von Hyper-V auf Host-Ebene verwenden den VSS Writer. Der VSS Writer unterstützt VM-Backups, wenn die virtuellen Maschinen über folgende Anbindungen verfügen:

  • Direct-Attached Storage,
  • iSCSI-Storage, das an das Host-Betriebssystem angebunden ist. Der Hyper-V VSS Writer kann kein iSCSI-Storage sichern, dass von innerhalb der virtuellen Maschine initiiert wurde;
  • Fibre-Channel-Storage, das durch das Host-Betriebssystem eingebunden ist,
  • virtuelles Fibre Channel.

Backups auf Gast-Ebene wiederum funktionieren mit jeder Storage-Ressource, die für die virtuelle Maschine sichtbar ist. Hier kommt es nicht auf den Storage-Typ an.

Zusätzlich zur Live-Migrationen bietet Hyper-V eine weitere Migrations-Option, die sich mit VMware vMotion vergleichen lässt. Microsoft nennt das Ganze Storage Live Migration. Microsoft hat aber auch für VHDX-basierte virtuelle Festplatten einige neue Funktionen einfließen lassen. Sie können zum Beispiel nun die Größe einer virtuellen Festplatte ändern, während die entsprechende virtuelle Maschine in Betrieb ist.

Auch wenn Red Hat, VMware und Microsoft teilweise sehr ähnliche Funktionen bezüglich des Hypervisors anbieten, gibt es bei der Unterstützung für physischen Speicher doch grundlegende Unterschiede. Bevor Sie in einen Hypervisor investieren, sollten Sie sicherstellen, dass eine reibungslose Zusammenarbeit mit dem von Ihnen gewünschten Storage auch wirklich möglich ist. Zudem sollten Sie sich über die zum Storage gehörenden Funktionen der jeweiligen Produkte vollständig im Klaren sein.

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

Artikel wurde zuletzt im Juli 2014 aktualisiert

Pro+

Premium-Inhalte

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

Erfahren Sie mehr über Virtualisierung: Kapazitätsplanung

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

Close