Unterstützung von SMB 3.0 in Hyper-V: Storage-Kosten senken und Komplexität verringern

Die Überarbeitung von Hyper-V umfasst die Speicherung von virtuellen Maschinen. Möglich ist das durch die Unterstützung von Server Message Block 3.0.

Mit der Veröffentlichung von Windows Server 2012 hat Microsoft auch Hyper-V grundlegend überarbeitet. Zu den neuen Funktionen zählt beispielsweise die Speicherung von Komponenten virtueller Maschinen wie Festplatten, Konfigurationsdateien und Snapshots in SMB File Shares. Dies wurde durch die Unterstützung von Server Message Block 3.0 möglich und bedeutet einen radikalen Kurswechsel gegenüber älteren Versionen von Hyper-V – die nur eine lokale Speicherung, Fibre Channel SAN oder iSCSI-SAN zuließen. Das Speichern virtueller Maschinen in SMB File Shares bietet den Vorteil niedrigerer Storage-Kosten. Zudem entfällt dadurch auch die Anforderung an Administratoren, über spezielle Storage-Kenntnisse verfügen zu müssen.

Trotz dieser Vorteile darf ein Punkt nicht außer Acht gelassen werden: Hyper-V unterstützt neben SMB 3.0 File Shares auch noch weitere Storage-Typen. Microsoft bevorzugt immer noch Cluster Shared Volumes als Storage-Typ für Hyper-V Cluster. Eine Verwendung von SMB File Shares für Hyper-V bietet sich im Allgemeinen eigentlich nur für kleine und mittlere Unternehmen an. Grund hierfür sind limitierende Faktoren wie die verfügbare Bandbreite (wird durch die Geschwindigkeit der Netzwerk-Karte des Servers bestimmt) und Disk I/O-Beschränkungen. Somit ist pro Freigabe nur eine bestimmte Anzahl virtueller Maschinen möglich.

Wenn Sie über eine Speicherung von Komponenten virtueller Maschinen auf Server Message Block File Shares nachdenken, sollten Sie eine Reihe von Voraussetzungen und Best Practices kennen.

Als erstes muss der Dateiserver SMB Version 3.0 unterstützen – Microsoft sprach bei der Preview Release von Windows Server 2012 davon, dass SMB Version 2.2 für die Verwendung mit Hyper-V unterstützt wird; Version 2.2 wurde dann später in 3.0 umbenannt. In den meisten Fällen erfordert dies die Ausführung von Windows Server 2012 auf dem Datei-Server. Andere Betriebssysteme werden ebenfalls unterstützt, solange sie den Standards von SMB 3.0 entsprechen. Falls Sie sich diese Frage schon gestellt haben: Sie können auch weiterhin mit Hyper-V die Komponenten virtueller Maschinen auf einem Datei-Server mit SMB-Protokoll speichern. Allerdings wird dies nicht unterstützt, und der Best Practices Analyzer für Hyper-V wird bei Erkennung des vorhandenen File Share eine Warnmeldung ausgeben. 

Ein weiterer wichtiger Punkt: Die Verwendung von SMB File Shares mit Hyper-V wird nur in Active Directory-Umgebungen unterstützt. Allerdings werden auch bereits vorhandene Active Directory-Domains unterstützt. Die Domain-Controller müssen dabei nicht unbedingt Windows Server 2012 ausführen.

Wenn Sie diese relativ simplen Grundlagen kennen, müssen Sie als Nächstes Ihre Storage-Architektur planen. Dies mag Ihnen vielleicht seltsam vorkommen, da die Verwendung eines SMB File Shares eigentlich doch die Storage-Anforderungen vereinfachen soll. Dies trifft zwar zu, andererseits dürfen Sie den Faktor Zuverlässigkeit nicht außer Acht lassen.

Ein virtualisierter Host-Server führt in der Regel mehrere virtualisierte Workloads aus. Bei einem Ausfall des Host-Servers werden also auch die virtualisierten Workloads versagen, was zu einem umfassenderen Systemausfall führt. Ihr einziger Schutz gegen solche Systemausfälle ist Redundanz. Nur weil Sie in Bezug auf Ihr Storage für virtuelle Maschinen einen wirtschaftlicheren Ansatz verfolgen, dürfen Sie diesen Aspekt nicht vernachlässigen.

Technisch gesehen können Sie natürlich eine virtuelle Maschine auf einem für sich stehenden Hyper-V-Server ausführen und die virtuellen Maschinen-Komponenten auf einem Standalone-Dateiserver speichern. Das Problem hierbei ist die fehlende Redundanz dieser Konstellation. Der Hyper-V-Server, der Datei-Server und die Verbindung zwischen diesen – all das sind Einzelkomponenten, die zu einem Ausfall des Gesamtsystems führen können, also mögliche Single Points of Failure.

Manche IT-Administratoren versuchen dieses Problem zu umgehen, indem sie statt eines Cluster Shared Volume einen Hyper-V Failover Cluster mithilfe eines SMB 3.0 File Shares installieren. Für diesen Ansatz ist allerdings eine sorgfältige Planung erforderlich. Die Konfiguration ermöglicht bei Ausfall eines Hyper-V-Servers ein Failover virtualisierter Workloads auf einen anderen Cluster-Knoten, der Datei-Server selbst bietet Storage-Redundanz über ein fehlertolerantes Storage-Array. Dabei ist allerdings zu berücksichtigen, dass der Datei-Server an sich wieder eine Einzelkomponente darstellt, die zu einem Ausfall des Gesamtsystems führen kann: Fällt er aus, sind die Hyper-V-Server ohne Verbindung zum Storage.

Die Verwendung eines Dual-Node- oder besser noch eines Multinode-Dateiservers ist den beiden oben genannten Varianten deshalb vorzuziehen. Dual-Node- oder Multinode-Dateiserver abstrahieren normalerweise den Server vom zugrundeliegenden Storage. Statt mit lokalen Storage-Arrays ist jeder Datei-Server über Fibre Channel oder iSCSI mit einem geteilten Storage-Device verbunden.

Dies wirft natürlich die Frage auf, warum ein Unternehmen überhaupt den Anschluss von Hyper-V an Datei-Server mit Shared Storage in Erwägung ziehen sollte, wenn eine Provisionierung von Hyper-V mit einem dedizierten Gerät für geteiltes Storage die kostengünstigere Variante darstellt (da hier kein Datei-Server erforderlich ist).

Baut ein Unternehmen die Hyper-V-Installation völlig neu auf, ist es effizienter und kostengünstiger, Hyper-V Cluster-Knoten direkt mit einem Shared Storage Pool zu verbinden, anstatt Hyper-V mit Datei-Servern zu verknüpfen und diese wiederum mit einem Storage-Pool. Es gibt nur eine Situation, in der die Verwendung von Datei-Servern mit Cluster Shared Volumes sinnvoll ist: bei einem knappen Budget und hinreichend geringer Gesamt-Workload, die dem Datei-Server eine problemlose Verarbeitung des I/O-Datenverkehrs von Hyper-V und des von Nutzern generierten Storage-Datenverkehrs ermöglicht.

Mit SMB-Storage können kleine Unternehmen ihre Storage-Kosten niedrig halten und die Komplexität ihrer Hyper-V-Umgebungen verringern. Dennoch sollten Sie sich auch Gedanken über Performance und Zuverlässigkeit machen, bevor Sie sich auf SMB File Shares festlegen.

Brien Posey ist freiberuflicher technischer Autor und wurde sechs Mal mit dem Microsoft MVP Award ausgezeichnet. Er war als CIO für eine US-weite Krankenhaus-Kette und für Gesundheitsdienstleister tätig sowie als Netzwerk-Administrator für das US-Verteidigungsministerium in Fort Knox.

Artikel wurde zuletzt im Januar 2013 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

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

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close