chris - Fotolia
Wie ein robuster Hyper-V-Failover-Cluster aussehen muss
Vor dem Deployment eines Hyper-V-Failover-Clusters sollten Sie unsere grundlegenden Hinweise beachten. Sonst könnte durch eine falsche Konfiguration die VM-Performance leiden.
Windows-Server-Admins müssen sich mit genug Problemen herumschlagen. Eine Möglichkeit für ein stressfreieres Arbeiten ist das Deployment eines Hyper-V-Failover-Clusters.
Failover Cluster stellen sicher, dass virtuelle Maschinen (VM) in Hyper-V auch dann weiterlaufen, wenn ein Problem einen Host außer Betrieb setzt. Doch Administratoren müssen den Cluster richtig einrichten – und dabei insbesondere die Netzwerkkonfiguration berücksichtigen –, um zu gewährleisten, dass der Hyper-V-Cluster und Apps in der VM im Betrieb eine optimale Leistung bringen.
Die verschiedenen Traffic-Typen von Hyper-V-Clustern
Um die Performance von Hyper-V-Failover-Clustern zu optimieren, müssen Admins sich mit den unterschiedlichen Traffic-Typen von Hyper-V auseinandersetzen und das Hyper-V-Networking entsprechend den Anforderungen konfigurieren. Hyper-V nutzt einen physischen Netzwerkadapter für die jeweiligen Typen von Netzwerk-Traffic, zum Beispiel Cluster-, Live-Migration-, VM-Kommunikations-, Storage-, Hyper-V-Replica- und Hyper-V-Management-Traffic.
Der Cluster-Service überwacht die Verfügbarkeit aller Knoten im Cluster, wenn er ein Paket über den physischen Netzwerkadapter sendet. Ein Knoten, der nicht mit einem Health Check (als Cluster Heartbeat bezeichnet) antwortet, wird aus dem Cluster entfernt.
Die Live-Migration-Funktion von Hyper-V verschiebt eine VM zu einem anderen Hyper-V-Knoten im Cluster, falls es zu einer Störung oder einem Ausfall kommt. Zu diesem Zweck verwendet Hyper-V den physischen Netzwerkadapter, der von den anderen Hyper-V-Traffic-Typen genutzt wird. Wenn ein Scale-Out-File-Server (SOFS) oder iSCSI-Target-Server bereitgestellt wird, nutzt Hyper-V den gleichen physischen Netzwerkadapter, um mit dem SOFS-Cluster oder dem iSCSI-Target-Server zu kommunizieren. Auf ähnliche Weise verwenden die Hyper-V-Replica- und Management-Netzwerk-Traffic-Typen den gleichen physischen Netzwerkadapter.
Obwohl es möglich ist, alle Typen von Hyper-V-Netzwerk-Traffic über einen einzigen Netzwerkadapter laufen zu lassen, empfiehlt sich diese Konfiguration nicht für Produktionsumgebungen. Einige Netzwerkanwendungen, die innerhalb der VMs ausgeführt werden, verlangen eine dedizierte Netzwerk-Queue, um Kommunikationsverzögerungen zu vermeiden. Mehrere physische Netzwerkadapter helfen auch bei der schnellen Live-Migration von VMs und verhindern Störungen. Einige IT-Abteilungen bevorzugen einen separaten physischen Netzwerkadapter, der eigens für den Management-Traffic reserviert ist.
Um den Hyper-V-Netzwerk-Traffic zu isolieren, installieren Sie die entsprechende Zahl von physischen Netzwerkadaptern auf dem Hyper-V-Host, weisen jeden davon einem virtuellen Switch in Hyper-V zu und teilen dann jedem virtuellen Netzwerkadapter ein eindeutiges Subnetz zu. Um die Einrichtung abzuschließen, konfigurieren Sie mit dem Failover-Cluster-Manager oder dem Hyper-V-Manager die Netzwerkeinstellungen so, dass der Netzwerk-Traffic isoliert wird.
Um zum Beispiel den Live-Migration-Traffic zu isolieren, öffnen Sie den Failover-Cluster-Manager, klicken im linken Navigationsbereich mit der rechten Maustaste auf Netzwerke, klicken dann auf Einstellungen für die Live-Migration und wählen einen Netzwerkadapter aus. Auf ähnliche Weise können Admins den Failover-Cluster-Manager nutzen, um Cluster-Traffic zu isolieren. Wechseln Sie zu Netzwerke, klicken mit der rechten Maustaste auf ein Netzwerk und klicken dann auf Eigenschaften. Auf der Eigenschaftenseite wählen Sie Netzwerkkommunikation für Cluster in diesem Netzwerk zulassen und deaktivieren die Option Clients das Herstellen einer Verbindung über dieses Netzwerk gestatten. Dadurch wird ein Netzwerk für die Cluster-spezifische Kommunikation reserviert.
NIC-Teaming bietet Resilienz
Microsoft hat das Teaming von Netzwerkkarten (Network Interface Card, NIC) mit Windows Server 2012 eingeführt, damit Administratoren mehrere virtuelle NICs über unterschiedliche physische NICs hinweg gruppieren können, um Redundanz hinzuzufügen.
Das NIC-Teaming in Windows Server 2012 ermöglicht Port Load Balancing in Hyper-V, um den VM-Netzwerk-Traffic auf Basis der MAC-Adresse der VM zu verteilen. Das Port Load Balancing von Hyper-V nutzt ein Round-Robin-Verfahren, um VMs über das NIC-Team zu verteilen. Ein aktiver Netzwerkadapter im Team kümmert sich um den ausgehenden Traffic der VMs.
NIC-Teaming unterstützt zwei Modi: Switch-abhängig und Switch-unabhängig. Der Switch-abhängige Modus erfordert, dass ein virtueller Switch im Team vorhanden ist. Admins können den Switch-unabhängigen Modus nutzen, falls die Netzwerkadapter sich mit einem anderen virtuellen Switch verbinden, jeder davon ohne Funktion oder Teamteilnahme. Für Hyper-V-Cluster empfiehlt es sich, den Switch-unabhängigen Modus mit Port Load Balancing in Hyper-V zu verwenden.
VMQ verhindert unnötige Überlastung
Wenn der Hyper-V-Host über Netzwerkadapter mit VMQ-Funktion (Virtual Machine Queue, Warteschlange für virtuelle Computer) verfügt, sollten Admins dieses Feature aktivieren.
VMQ richtet eine dedizierte Warteschlange auf dem physischen Netzwerkadapter ein, um Daten direkt zu virtuellen Netzwerkadaptern zu übertragen – anstatt sie zuerst zum Management-OS zu routen –, und verhindert Verzögerungen bei der Kommunikation.
Hochverfügbarkeit durch einen Hyper-V-Failover-Cluster bietet eine gewisse Sicherheit, aber Admins sollten sich mit den zur Verfügung stehenden Einstellungen und Optionen vertraut machen, damit die Performance von Anwendungen in VMs im Cluster auf dem erwarteten Niveau bleibt.
Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!
