Von Ryan Weldon, Dell Virtualization Solutions Engineering

Um einige Funktionen von Microsoft® Windows Server® 2008 R2 Hyper-V™ zu veranschaulichen, wurde im Labor von Dell Virtualization Solutions Engineering eine Konfiguration eingerichtet, in der unsere Best Practice-Empfehlungen für Netzwerke in einer Hyper-V R2-Umgebung implementiert wurde. Diese Best Practices sind das Ergebnis einer internen Prüfung sowie der direkten Interaktion mit Microsoft und wurden direkt in Hyper-V R1 integriert. Unsere Best Practices beruhen auf den folgenden grundlegenden Prioritäten:

  • Redundante Hardware zur Vermeidung zentraler Fehler
  • Lastausgleich und Failover für Internet SCSI (iSCSI) und Datenverkehr virtueller Rechner
  • Redundante Pfade für Cluster, Cluster Shared Volume (CSV) und Datenverkehr durch Live-Migration
  • Trennung jedes Datenübertragungstyps für Sicherheit und Verfügbarkeit
  • Einfache Handhabung und Implementierung

Die in dieser Konfiguration verwendete Hardware basiert so nah wie möglich auf einer Kundenkonfiguration, die während einer TechCenter-Chat-Sitzung ermittelt wurde. Der Kunde hat folgende Module erworben:

  • Dell™ PowerEdge™ M1000e mit drei PowerEdge M710 Servern
  • Vier Dell PowerConnect™ M6220 Switches
  • Ein Dell EqualLogic™ PS6000 iSCSI Speichernetzwerk-(SAN, Storage Area Network-)Array

Der Kunde teilte uns mit, das für die Zukunft zwei offene E/A-Modulsteckplätze für ein Netzwerk mit 10 GB Ethernet (GbE) vorgesehen sind.

Die einzige Ausnahme für unsere Best Practice-Empfehlung in diesem Design besteht in der Verwendung einer logischen Trennung des iSCSI-Datenverkehrs anstelle einer physischen Trennung. Wir empfehlen, dass Kunden eine physische Trennung für den iSCSI-Datenverkehr verwenden. Es ist uns jedoch bewusst, dass es Umgebungen gibt, in denen diese Trennung nicht möglich ist. In solchen Fällen kann die logische Trennung durch virtuelle LANs (VLANs) implementiert werden. Um alle zuvor mit der definierten Hardware ermittelten Entwurfsprinzipien zu unterstützen, war eine logische Trennung erforderlich.

Dieses Design konnte leicht geändert werden, indem Zusatzkarten und Switches zur nicht verwendeten Struktur hinzugefügt werden und diese Hardware für iSCSI reserviert wird. In diesem Fall konnten die in diesem Design identifizierten Adapter für den iSCSI-Datenverkehr für andere Datenverkehrstypen verwendet werden (virtuelles Gerät empfohlen). Die Konfiguration des Switches und des Hyper-V Servers muss selbstverständlich entsprechend aktualisiert werden.

Hinweis: Diese Konfiguration berücksichtigt nicht die Best Practices für SCVMM R2.

Hyper-VR2-Netzwerkübersicht

Die Datenübertragungstypen in einer Hyper-V R2 Implementation (mit Failover-Clustering) werden in der folgenden Tabelle aufgelistet.




Für das Failover-Clustering ist es außerdem erforderlich, ein gemeinsam genutztes Speichergerät anzuschließen (normalerweise iSCSI, Fibre-Channel oder Serial Attached SCSI [SAS]). In einer iSCSI-Umgebung muss der Failover-Cluster für das Verwalten des iCSCI-Netzwerks deaktiviert werden. Die Redundanz für das Speichernetzwerk wird normalerweise vom MPIO-Framework von Microsoft bereitgestellt.

 

Demo-Hardware


PowerEdge M1000e Blade-Gehäuse

 

PowerEdge M1000e enthält drei separate Strukturen (fabrics): A, B und C. Jede Struktur enthält zwei zugeordnete E/A-Steckplätze, an die unterstützte E/A-Module angeschlossen werden können. Diese Steckplätze werden folgendermaßen bezeichnet: A1, A2, B1, B2, C1, C2. Die Struktur A ist für die integrierten Netzwerkadapter für jedes Blade reserveviert. Strukturen B und C können für alle unterstützten Zusatzkarten in Servern und entsprechende E/A-Module (Ethernet, Fibre-Channel, Infiniband usw.) verwendet werden.

 

Einzelheiten zu den Komponenten:

PowerEdge M710

  • Prozessor und Speicher für diese Konfiguration waren nicht wichtig, weil die Anzahl der verwendeten virtuellen Rechner sehr klein war und die Leistung nicht berücksichtigt wurde. Zum Zeitpunkt der Veröffentlichung dieses Artikels unterstützt PowerEdge M710 den Prozessor Intel® Xeon® X5570, 2,93 Ghz (2 Stück) und maximal 192 GB Speicher.
  • Jeder PowerEdge M710 enthält zwei 5709 Dual-Port-LAN on Motherboards (LOMs).
  • Jedes Blade wurde mit zwei Broadcom 5709 Dual-Port-Zusatzkarten mit 1 GB für Blade der M-Serie ausgestattet.

Interne Ansicht eines PowerEdge M710 Servers

PowerConnect M6220

  • E/A-Steckplätze A1, A2, B1 und B2 wurden für die PowerConnect M6220 Switches verwendet.
  • Jeder Switch enthält ein Stack-Modul (Stacking Module), und die Switches wurden zu einem einzelnen virtuellen Switch kombiniert.
  • Switches im E/A-Modulsteckplatz A1 und B1 enthalten auch ein 10-GB-CX4-Uplink-Modul, das an unsere Nicht-iSCSI-Testinfrastruktur angeschlossen werden kann.

Back-End eines PowerEdge M1000e Gehäuses mit PowerConnect M6220 Switches

 

Array der EqualLogic PS5000 Serie


Obwohl der Kunde über Arrays der Dell EqualLogic PS6000 Serie verfügt, bleiben die Entwurfsprinzipien unverändert. Dieses Design ermöglicht den direkten Anschluss von maximal zwei Arrays der EqualLogic PS6000 Serie an die Switches. Andere Szenarien mit externen Switches werden mit dieser Hardware unterstützt, liegen jedoch außerhalb des Umfangs dieses Designs. Die Arrays beider EqualLogic PS5000 und EqualLogic PS6000 Serien enthalten redundante Controller zur Verarbeitung von Massenspeicher-Controller-Fehlern. Außerdem unterstützten sie RAID-Konfigurationen, die Laufwerksfehler tolerieren und als Hotspares erkannte Laufwerke enthalten, um die Wiederherstellung automatisch zu starten, falls ein Laufwerksfehler auftritt.

Vorhandene Testinfrastruktur

Folgende Komponenten wurden in der vorhandenen Testinfrastruktur verwendet:

  • Active Directory-, DHCP- und DNS-Server
  • PowerConnect 6248 Switches für die Verbindung der zuvor erwähnten Server mit dem Blade-Gehäuse

Netzwerkkonfiguration ermitteln

Um unsere Best Practices zu implementieren, benötigen Sie mindestens fünf Adapter pro Blade für eine Nicht-iSCSI-Umgebung und sieben Adapter für eine iSCSI-Umgebung:

  • 1 öffentlicher für den öffentlichen Cluster
  • 2 private: 1 für den privaten/primären CSV-basierten Cluster, 1 für die primäre Live-Migration
  • 2 für virtuelle Rechner
  • 2 für iSCSI

Mit acht verfügbaren Netzwerk-Ports pro Blade mit unserer Hardware haben wir drei verschiedene Möglichkeiten für den zusätzlichen Anschluss berücksichtigt:

Für unsere Konfiguration haben wir die erste Möglichkeit gewählt und den Port für den Datenverkehr virtueller Rechner reserviert.

PowerConnect M6220 Konfiguration

Stacking

Alle vier Dell PowerConnect M6220 Switches wurden zu einem einzelnen logischen Switch kombiniert, der den Datenverkehr zwischen den vier physischen Switches mit einer Bandbreite von 12 GB auf jeder Stack-Verbindung ermöglicht. Außerdem muss für das Implementieren eines Switch-übergreifendes LACP-Teams ein logischer Switch erstellt werden.


10-GB-Uplinks

Die 10-GB-Uplink-Ports sind via Uplink über eine einzelne logische PowerConnect Struktur verbunden. Diese Ports gehören zu einem LACP-Team, und die Upstream-Ports weisen eine entsprechende LACP-Konfiguration auf. Diese Ports wurden so konfiguriert, dass nur der Datenverkehr zulässig ist, der mit den VLANs getaggt ist, die für die öffentlichen/Verwaltungs-Cluster und virtuellen Rechner ermittelt wurden.


1-GB-Uplinks

Jeder PowerConnect M6220 enthält 1-GB-Ports, die so konfiguriert wurden, dass sie direkt mit entweder einer physischen, separaten iSCSI-Infrastruktur oder direkt mit den EqualLogic Arrays verbunden werden. Der iSCSI-Datenverkehr wurde so konfiguriert, dass er beim Eingang getaggt (innerhalb des Switches zum Trennen) und beim Ausgang die Tags entfernt werden (außerhalb des Switches). Allerdings können außerhalb dieses Designs 10-GB-Uplink-Module zur Konfiguration hinzugefügt und für den iSCSI-Datenverkehr eingerichtet werden.


Interne Ports

Jeder PowerConnect M6220 Switch enthält 16 interne Ports. Im Falle von Blades mit voller Höhe, wie der PowerEdge M710, werden jedem Blade-Server zwei Ports von jedem Switch zugewiesen. Die Zuweisung dieser Ports zu den physischen Netzwerkadaptern ist für das Design wichtig, weil somit sichergestellt wird, dass der Verlust eines Switches oder eines Netzwerkadapters/LOMs keinen Dienstausfall verursacht. Beispielsweise wird LOM 1 des Blade-Servers in Steckplatz 1 einem Port auf dem Switch-Port 1 auf A1 und ein Port dem Switch-Port 2 auf A2 zugewiesen.


Adapter-zu-Switch-Port-Zuweisungen

Die in dieser Abbildung gezeigte Konfiguration basiert auf unserem Netzwerkdesign und den Kenntnissen über die Adapter-zu-Switch-Port-Zuweisungen. Beachten Sie jeden einzelnen Datenverkehrstyp und wie die Redundanz über mehrere physische Adapter bereitgestellt wird (z. B. Live-Migration/privater Cluster).




Datenverkehr-zu-Switch-Port-Zuweisungen

VLAN- und Switch-Implementierung verstehen

Jeder Datenverkehrstyp wurde auf einen eigenen VLAN gelegt. Außerdem mussten wir unsere bestehende VLAN-Implementierung für den Datenverkehr berücksichtigen, der außerhalb des Gehäuses fließen sollte. Unsere aktuelle Testinfrastruktur wurde mit den folgenden VLANs eingerichtet:



Unter Berücksichtigen dieser Einzelheiten wurde die folgende VLAN-Konfiguration implementiert:



*Weil unser Failover-Cluster vollständig im Gehäuse enthalten ist, muss die Live-Migration oder der öffentliche Cluster-Datenvekehr nicht extern geroutet werden. Daher lassen die Uplink-Ports auf dem Switch diese VLANs nicht zu.

**Weil unser EqualLogic-Array direkt an den Switch angeschlossen ist, musste der aus dem Switch fließende Datenverkehr nicht getaggt werden.


Für einige Kunden ist es wünschenswert, die virtuellen Rechner mit Zugriff auf das Verwaltungsnetzwerk (in unserem Fall VLAN 52) bereitzustellen. In diesem Fall darf ein virtueller Switch nicht auf den für den öffentlichen Cluster reservierten Netzwerk-Port platziert werden. Fügen Sie stattdessen einen zusätzlichen virtuellen Adapter auf dem Verwaltungs-VLAN hinzu, platzieren Sie ihn auf den vorhandenen virtuellen Hyper-V Switch, und aktualisieren Sie die Einstellungen des physischen Switches entsprechend.

Wer führt das Tagging aus?

Datenverkehr, der in den Switch von außerhalb des Gehäuses (VLANs 52, 152 und 153) fließt, wird vom Sender entweder an jedem Switch oder vom Server/Hypervisor getaggt. Für den von unseren Blades fließenden Datenverkehr haben wir die folgenden Einstellungen vorgenommen:

 

 *Tagging für virtuelle Geräte findet für jeden virtuellen Adapter statt. Deshalb kann jeder individuelle virtuelle Rechner einen Adapter auf VLAN 152, einen Adapter auf VLAN 153 oder zwei Adapter enthalten, um den Zugriff auf beide VLANs zu ermöglichen.

Wir haben uns für das Tagging am Switch für alle Datenverkehrstypen entschieden, die diese Methode unterstützen, weil dies einen einzelnen Standort für die Verwaltung der VLANs ermöglicht. Alternativ kann jeder physische Adapter getaggt werden, indem die VLAN-Software entsprechend eingestellt wird. Diese Methode ist jedoch mühsamer und fehleranfällig. Wenn Sie nur ein VLAN für den Datenverkehr von virtuellen Rechnern zur Verfügung haben, können Sie auch das Tagging auf Switch-Basis verwenden.

Einzelheiten zur Switch-Konfiguration

Vollständige Einzelheiten zu den Switch-Einstellungen erhalten Sie, wenn Sie die Switch-Konfiguration (www.delltechcenter.com/page/Sample+Switch+Configuration) anzeigen, die auf dem Stack geladen ist. Diese Einstellungen enthalten Unterstützung von Jumbo Frames auf den Ports mit iSCSI-Datenverkehr, LACP-Teamkonfiguration für die Uplink-Ports und virtuellen Netzwerk-Ports, Switch-Stacking und VLANs. Verwenden Sie die Konfiguration als Beispiel, und aktualisieren Sie die Konfiguration entsprechend Ihrer Umgebung.

Netzwerkkonfiguration für Hyper-V Verwaltungspartition

Zu diesem Zeitpunkt verfügen wir über alle Informationen, die für das Einrichten des Adapters auf jedem Blade wichtig sind. Wir kennen die Funktion, die für jeden Adapter reserviert ist, sowie die entsprechende VLAN-Implementierung.

Adapter zu Switch-Ports zuweisen

Zuerst müssen die Netzwerkgeräte in der Verwaltungspartition den entsprechenden Switch-Ports zugewiesen werden. „LAN-Verbindung X“ ist nicht wirklich aussagekräftig. Um die Zuweisungen auszuführen, verwenden wir die MAC-Adressen für jeden Adapter.

Die MAC-Adressen und ihre Beziehung zu den Switch-Ports können auf der Internet-basierten CMC-Benutzeroberfläche angezeigt werden. In einer FlexAdress-Umgebung können die MAC-Adressen für jeden Server und Port angezeigt werden. Die in dieser Abbildung gezeigten iSCSI MAC-Adressen sind gültig, wenn ein iSCSI-Offload-Adapter verwendet wird.

Mit den aktuell vorliegenden Informationen müssen wir nur die MAC-Adressen der Geräte in der Verwaltungspartition ermitteln, die unter „Network Connections“ angezeigt werden. Für diese Aufgabe haben wir ein PowerShell-Skript geschrieben, das alle Adapter, die mit „Local Area Connection“ beginnen, in die entsprechenden MAC-Adressen umbenennt. Zur zukünftigen Erleichterung der Verwaltung haben wir unsere Adapter entsprechend ihrer Funktion umbenannt.

Die folgende Abbildung zeigt ein Bespiel, wie die vollständigen End-to-End-Zuweisungen durchgeführt werden.



Netzwerkkonfiguration fertigstellen

Die letzten Schritte für die Implementierung unseres Netzwerkdesigns lauten wie folgt:

  • Ermitteln Sie das LACP-Netzwerkkteam in Broadcom Advanced Control Suite (BACS) auf den drei Schnittstellen, die für virtuelle Rechner verwendet werden, und erstellen Sie einen virtuellen Hyper-V Switch auf dem entsprechenden Team-Adapter.
  • Weisen Sie den Netzwerkschnittstellen die IP-Adressen zu.
  • Aktivieren Sie Jumbo Frames auf den beiden Schnittstellen für iSCSI.
  • Konfigurieren Sie den EqualLogic Remote-Installationsassistenten von Dell, und schließen Sie das Array über die Microsoft iSCSI-Initiator-Schnittstelle an.
  • Nachdem der Failover-Cluster ermittelt wurde:
    • Konfigurieren Sie den Cluster, um die verschiedenen Netzwerke zu verwalten/nicht zu verwalten.
    • Legen Sie die Priorität der Live-Migration-Netzwerke fest.
    • Stellen Sie sicher, dass das für den privaten Cluster ermittelte Netzwerk die niedrigste Netzwerkmessgröße für private Cluster und die Live-Migration eine höhere private Messgröße erhält.

Um die Messgrößeneinstellungen des Cluster-Netzwerks anzuzeigen, führen Sie den folgenden PowerShell-Befehl aus:

Import-Module FailoverClusters
Get-ClusterNetwork | ft Name, Metric, AutoMetric


Wenn die automatisch zugewiesenen Messgrößen nicht die gewünschten Werte enthalten, können Sie die folgenden PowerShell-Befehle ausführen, um die Messgrößen manuell einzustellen:

Get-ClusterNetwork | ft Name, Metric, AutoMetric

Notieren Sie den Namen der Netzwerke, für die Sie die Werte einstellen möchten (für den nächsten Befehl erforderlich)

$cn = Get-ClusterNetwork "<Clusternetzwerkname>"
$cn.Metric = <Wert>

Privater Cluster/CSV muss einen Wert von 1000 aufweisen