Netzwerkkonfiguration im Hyper-V Cluster

Ein Hyper-V Cluster soll möglichst viele Netzwerkkarten besitzen. Das ist vielen bekannt. Wie konfiguriert man aber jetzt die Netze, wenn man, wie in unserem Beispiel, sechs davon hat? Nachdem ich bereits in unserem Artikel “Hyper-V Cluster und Netzwerkkarten Bindungen” auf die einzelnen Protokolle und Bindungen der Netzwerkkarten eingegangen bin, beschreibe ich in diesem Artikel unsere momentane “Best Practice” zur Hyper-V Cluster Netzkonfiguration. Diese basieren neben unseren Erfahrungen auch auf Empfehlungen und Support Richtlinien von Microsoft.

Bevor wir aber mit den “Best Practice” loslegen, möchte ich erst mal, anhand der Grafik rechts, unseren Testaufbau verdeutlichen. In der Mitte sieht man unsere zwei HP Proliant DL160 G6 Server Systeme, aus denen später der Hyper-V Cluster gebaut wird. Ganz unten haben wir einen SAN Storage, eine NetApp FSA2050, die wir per iSCSI redundant anbinden. Jeder der blauen Balken stellt dabei ein Netzwerk dar. Diesen sind von oben nach unten:

  • imageManagement – Über dieses Netz wird der Cluster verwaltet (Remote Administration, Updates, SystemCenter Agenten, Host und VM Backup)
  • VM – Netzwerk über das die virtuellen Maschinen mit der “Außenwelt” kommunizieren
  • CSV – Heartbeat und (Privates) Cluster Netzwerk über das der Cluster Informationen austauscht und auch der „Redirect Access“ der Cluster Shared Volumes abgewickelt wird
  • Livemigration – Netz über das der Speicher einer VM, die auf einem anderen Host migriert, übermittelt wird
  • iSCSI – SAN Netzwerk für die Kommunikation der Hyper-V Hosts mit dem Storage (Redundant per MPIO)
  • iSCSI2 – SAN Netzwerk für die Kommunikation der Hyper-V Server mit dem Storage (Redundant per MPIO)

In der Grafik sieht man auch die Beispiel IPv4 Konfiguration. Es sind insgesamt fünf private Netze involviert. Das Management und VM Netzwerk sind in dem allgemeinen Kommunikationsnetz, in dem sich auch andere Server und Clients befinden (hier 192.168.210.0/23). Es kann geroutet werden und mit dem Internet über einen Firewall kommunizieren. Allen anderen vier Netze zwischen den Hosts und dem Storage ist gemeinsam, dass sie nicht geroutet werden. Die Aufgabe dieser Netze habe ich oben schon angerissen. Im Verlauf des Artikels werden wir nochmal bei der Bindung und Priorisierung der Adapter etwas genauer darauf eingehen.

Anmerkung: Auch wenn einem sechs Netzwerkadapter viel vorkommen, so ist diese Konfiguration, zumindest wenn man iSCSI einsetzt, noch nicht optimal. Im Idealfall benötigt man noch ein bis zwei Adapter mehr. Wieso? Zum einen sollte das Private Cluster Netzwerk, bei uns kurz CSV genannt, in zwei Netze aufgeteilt werden: das Heartbeat Netz und das eigentliche Cluster Shared Volume Netzwerk. Dann kann man die Cluster Kommunikation (der Cluster Heardbeat) und den Redirected Access von einander trennen (Empfehlung Microsoft). Genauso wird man auch das VM Netz oft mit mehr als einem Adapter betreiben und dazu auf Teaming zurückgreifen (Einen guten Artikel hierzu findet man bei Michel Lüscher auf dem Blog: How-To: Netzwerkkarten Teaming mit Hyper-V). Unsere gezeigte Konfiguration ist allerdings ein guter Kompromiss und ist auch so in unserem Lab aufgebaut.

Netz Überlegungen

Nun aber zur eigentlichen Konfiguration. Nach der Installation des Betriebssystems Windows Server 2008 R2 SP1, wurden alle sechs Netzwerkkarten erkannt. Wichtig ist, dass man nun die neusten Netzwerkkartentreiber installiert.

Wenn man jetzt die Netzwerkkonfiguration öffnet, geht man aus Gründen der Übersicht zuerst hin und deaktiviert alle Netzwerkkarten, bis auf das Management Interface. Als Nächstes macht man sich Gedanken, wie die Netzwerk Adapter am besten verteilt werden, damit auch die Redundanz richtig gewährleistet ist. Dabei soll verhindert werden, dass z.B. iSCSI und iSCSI2 auf dem gleichen Netzwerk Adapter konfiguriert sind. Wenn man unterschiedliche Netzwerkkarten in dem Hyper-V Host verbaut hat, dann spielen bei der Verteilung auch die Fähigkeiten der Adapter eine Rolle. Was heißt das in unserem Fall? Die beiden HP Proliant DL160 G6 haben jeweils eine onboard Intel Dualport und eine zusätzliche Intel Quadport Netzwerkkarte I340-T4 verbaut. Die I340-T4 besitzt verschiedene Optimierungen für iSCSI und Virtualisierung (z.B. TCP Segmentation and Checksum Offload, RSS und VMDq hier sind die Specs). Benamung_und_BindungenNach Abwägen der Optionen haben wir die Funktionen der Netzwerke wie folgt verteilt:

onboard Dualport Adapter: Management und iSCSI

Quadport Adapter: VM, Livemigration, CSV und iSCSI2

Danach sieht das Ganze wie im Screenshot rechts aus.

Jetzt vergeben wir für alle Netzwerk Ports, bis auf das VM Netz, eine feste IP Adresse aus den jeweiligen Netzen. Wir haben uns dabei angewöhnt, dass das letzte Oktett der IP-Adressen der Hyper-V Hosts in allen Netzen gleich ist. Ein Beispiel: Wenn, wie in unserer Konfiguration, HyperV6 in unserem Management-Netz die IP-Adresse 192.168.210.26 hat, dann bekommt er auch in allen anderen Netzen die Endadresse “x.x.x.26”. Unten sehen Sie exemplarisch die IP-Konfiguration des Livemigration Netzes.

Livemigration_Netzwerk_mit_DNS_NetBIOS

Bei der IP-Konfiguration wird, außer beim Management Netzerk, nirgendswo ein Gateway oder ein DNS Server eingetragen. Zusätzlich wird bei diesen privaten Netzwerken unter DNS die Checkbox “Adresse dieser Verbindung im DNS registrieren” entfernt. Das ist wichtig, damit sich der Hyper-V Host nicht unter den IP-Adressen der Netze Livemigraton, CSV, iSCSI und iSCSI2 beim DNS registriert. Weiterhin sollte man unter dem Reiter WINS die Option “NetBIOS über TCP/IP deaktivieren” aktivieren (siehe Screenshot oben).

Anmerkung: Weitere Optimierungen, welche früher für einen Cluster vorgenommen wurden, sollten bei einem Hyper-V Cluster nicht durchgeführt werden (Siehe Michels Artikel: Error “Cluster Shared Volume is no longer available” mit Hyper-V Failover Cluster)

Nochmals, all das geschriebenen gilt nicht für das Management Netzwerk. Dieses wird wie gehabt mit Gateway und DNS Server konfiguriert. Auch wird die DNS und NetBIOS Konfiguration mit den Standardwerten belassen.

Hyper-V Rolle installieren

Bevor wird die Hyper-V Rolle installieren, achten wir darauf, dass auf dem VM Netzwerkinterface DHCP eingeschaltet ist. Dann starten wir die Hyper-V Rolleninstallation und wählen im Dialog “Virtuelle Netzwerke erstellen”, das VM Netz aus (siehe Screenshot).Virtuelle_Netzwerke_erstellen

Nach der Installation des Hypervisors gehen wir in die Konfiguration der Hyper-V Manager und wählen auf der rechten Seite den Punkt “Manager für virtuelle Netzwerke” aus. In dem daraufhin erscheinenden Dialog wählen wir das virtuelle Netzwerk “VM – virtuelles Netzwerk” aus. Jetzt entfernen wir die Checkbox “Gemeinsames Verwenden dieses Netzwerkadapters für das Verwaltungsbetriebssystem zulassen” (siehe Screenshot). Manager_fuer_Virtuelle_Netzwerke

Hyper-V Cluster konfigurieren

Um die Netzwerkkonfiguration für den Cluster fortzusetzen, müssen wir nun einen Cluster einrichten. Nachdem das erfolgt ist, finden wir im Failovercluster-Manager, unter dem Punkt “Netzwerke”, die Netze “Clusternetzwerk 1” bis “Clusternetzwerk 5” (Screenshot unten links). Diese werden automatisch anhand der Subnetze angelegt. In deren Detail Ansicht findet man dann auch die Netzwerk Adapter der jeweiligen Cluster Nodes / Hyper-V Hosts. Da die Bezeichnung “Clusternetzwerk x” nicht wirklich sprechend ist, ändern wir die Netze in unsere Netzbezeichnungen um (Screenshot unten rechts).

Clusternetzwerk_1_bis_5Clusternetzwerk_neue_Benahmung

 

 

 

 

 

 

 

 

Bis jetzt haben wir erreicht, dass unsere Netzwerke für uns einen logischen Sinn ergeben. Jetzt müssen wir auch dem Cluster beibringen, welcher Adapter er für welche Funktion benutzen soll. Das geschieht an mehreren Stellen in der Konfiguration, auf die wir jetzt für jedes der Netze eingehen.

CSV Netz

Clusternetzwerk_EigenschaftenÜber diesen Adapter laufen zwei Funktionen: die Clusterkommunikation (oder Cluster Heartbeat) und die Cluster Shared Volumes. Wie oben schön erwähnt, würden wir diese Funktionen auf getrennte Netzwerkkarten legen, wenn weitere zur Verfügung ständen.

Welche Netze der Cluster Heartbeat benutzen darf, wird im Failovercluster-Manager eingestellt. Hier wählt man unter dem Punkt Netzwerke das Netz aus, welches für die Clusterkommunikation benutzt werden soll. Als nächstes rechtsklickt man und wählt Eigenschaften aus (Screenshot rechts). Im erscheinenden Dialog clickt man den Punkt “Netzwerkkommunikation für Cluster in diesem Netzwerk zulassen” an. Im Screenshot sieht man links die Bindungen der Netzwerkkarte und rechts die Einstellungen des Clusters für diese Netzwerkschnittstelle.

 

CSV_Bindungen2

Wie zuvor bereits erwähnt und bei Michel gebloggt, dürfen hier die Protokolle „Client für Microsoft Netzwerke“ und „Datei für Druckerfreigabe“ nicht deaktiviert werden. Dies wird für den Redirected Access vom CSV benötigt.

Die Einstellung der Funktion Cluster Shared Volumes und damit des Redirected Access, definiert man in der PowerShell. Jede Netzwerkschnittstelle im Cluster hat eine Metrik zugeordnet. Diese Metrik bestimmt der Cluster anhand der Netzwerkeigenschaften, wie z.B. die Geschwindigkeit des Interfaces, das Vorhandensein eines Gateways und die DNS Einträge. Der Cluster nutzt nun für die CSV Kommunikation die Karte mit der tiefsten Metrik. Wenn Sie selber bestimmen wollen, welche Karte da ist, so müssen sie die automatisch vergebenen Metriken modifizieren. Und eben hierzu benötigt man die PowerShell.

Zuerst laden wir in der PowerShell die FailoverCluster CmdLets:

Import-Module FailoverClusters

Dann lassen wir uns die Metrik der einzelnen Schnittstellen mit dem Befehl:

Get-ClusterNetwork | ft Name, Metric, AutoMetric

anzeigen. Das Ergebnis sieht so aus:

PowerShell1

Momentan wird der CSV Adapter automatisch für die Clusterkommunikation benutzt. Wir möchten aber, dass die Auswahl nicht zufällig passiert, weswegen wir diese fest mit dem Wert 900 zuordnen. Weiterhin möchten wir, dass die Livemigration auf 1100 gesetzt wird. Dazu benutzen wir folgende PowerShell Befehle:

(Get-ClusterNetwork “CSV”).Metric=900
(Get-ClusterNetwork “Livemigration”).Metric=1100

Danach lassen wir uns wieder die Metriken der einzelnen Netzwerke anzeigen:

PowerShell2

Damit haben wir die Interfaces nach unseren Vorstellungen “geordnet”.

Management Netz

Das Management Netzwerk ist Mitglied im normalen Clientnetzwerk und für die Kommunikation des Clusters mit der “Außenwelt” zuständig. Über dieses kann z.B. per Remote Desktop auf die Konsole zugegriffen werden und die System Center Agenten kommunizieren mit ihren Management Servern. Wie bereits weiter oben beschrieben, hat dieses Netz in der Regel ein Gateway und DNS konfiguriert. Die Konfiguration der Netzwerkkarte sieht man im Screenshot unten links und die der Clusternetzwerks im Screenshot unten rechts.

Managment_Bindungen

Im rechten Screenshot sehen wir, dass der Cluster auch eine IPv6 Netz für die Kommunikation benutzt. Das ist vollkommen in Ordnung und bei unserer Umgebung sogar gewünscht! (siehe Kapitel IPv6). Zusätzlich wird dieses Netz als Backup für die Cluster Heartbeat Kommunikation genutzt. Deshalb ist hier, wie beim CSV und Livemigration Netz, der Radiobutton ”Netzwerkkommunikation für Cluster in diesem Netzwerk zulassen” ausgewählt.

iSCSI und iSCSI2 Netze

Die Konfiguration ist für beide Adapter im Wesentlichen gleich, weswegen wir nur eine besprechen. Über dieses Netzwerk wird das SAN System, auf dem unsere VMs liegen, angesprochen. Wenn, wie in unserem Fall, für die Kommunikation mehrere Netzwerke (iSCSI und iSCSI2) benutzt werden, dann sollte das Feature MPIO korrekt konfiguriert sein. Die eigentliche Netzwerkkonfiguration der iSCSI Interface ist relativ simpel. Auf der Netzwerkschnittstelle wird nur IP gebunden (Screenshot unten links) und in der Clusternetzwerkkonfiguration wird die Netzwerkkonfiguration für den Cluster unterbunden (Screenshot unten rechts).

iSCSI_Bindungen

 

Livemigration Netz

Das Livemigration Netzwerk hat die Aufgabe, bei dem Vorgang einer Livemigration, den Hauptspeicher einer VM von Host A (auf dem die VM noch läuft) auf Host B (auf den die VM migriert wird) zu übertragen. Damit das funktioniert, ist ein möglichst schnelles Netz notwendig (mindestens 1Gbit). In unserer Konfiguration dient der Livemigration Adapter auch noch als Backup für die Clusterkommunikation (Cluster Heartbeat). Deswegen schalten wir in der Cluster Netzwerkkonfiguration auch die Clusterkommunikation ein (siehe Screenshot rechts).

Livemigration_Bindungen

Das eigentliche Konfigurieren, welches Netzwerk für die Livemigration benutzt wird, geschieht aber auf der VM. Dazu rechtsklickt man auf eine VM und wählt “Eigenschaften” aus (Screenshot unten links). Dann wechselt man in den Reiter “Netzwerk für Livemigration” und wählt die Netze “Livemigration” und “Management aus (Screenshot rechts). Das Netz Management soll dabei als Backup dienen, wenn das Netz Livemigration nicht zur Verfügung steht. Wenn Livemigration unterhalb von Management steht, dann müssen wir die Reihenfolge der Netze noch durch “Drücken” des Buttons “Nach Oben” verändern, da sonst die Livemigration über das Management Netz erfolgen würde.

Priorisierung_Livemigation1

Priorisierung_Livemigation2

Wie bereits beim Heartbeat beschrieben, dürfen auch hier die Protokolle „Client für Microsoft Netzwerke“ und „Datei für Druckerfreigabe“ nicht deaktiviert werden.

Wichtig: Die Konfiguration auf der VM lässt den Anschein erwecken, dass man bei jeder VM das Netz für die Livemigration auswählen kann/muss. Das ist nicht so. Was man auf einer VM konfiguriert gilt auch für alle anderen.

Reihenfolge der Netzwerkkarten

Zuletzt wollen wir noch sicherstellen, dass das System zuerst über das Management Netzwerk versucht, mit anderen Systemen zu kommunizieren (z.B: Active Directory oder DNS Auflösung). Deswegen müssen wir gegebenenfalls die Reihenfolge der Netzwerkschnittstellen umsetzen. Dazu öffnen wir das “Netzwerk- und Freigabecenter” und klicken auf “Adaptereinstellungen ändern”. Im Fenster “Netzwerkverbindungen” drücken wir die die ALT-Taste und können in dem erscheinenden Menü (Screenshot unten links) über “Erweitert” den Dialog ”Erweiterte Einstellungen” aufrufen. Hier sorgen wir durch umordnen der Netzwerkschnittstellen dafür, dass das Management als Erstes in der Auflistung erscheint (Screenshot unten rechts).

Bindungsreihenfolge1Bindungsreihenfolge2

 

IPv6

Noch ein paar Wort zu IPv6. Microsoft empfielt mittlerweile IPv6 auf den Schnittstellen eingeschaltet zu lassen. Es ist sogar wichtig zu wissen, dass Microsoft inzwischen nur noch mit aktiviertem IPv6 testet. Warum haben wir es dann in dieser Beispielkonfiguration mit einer Ausnahme ausgeschaltet? Ein einfacher Grund: Wir wollten die Konfiguration nicht weiter verkomplizieren. In unserer Umgebung haben wir wegen DirectAccess einen IPv6 DHCP Server laufen (siehe auch How to: Einrichtung von DirectAccess). Dieser versorgt alle Adapter, wenn IPv6 eingeschaltet ist, mit IPv6 Adressen. Damit wären alle Adapter über IPv6 in einem Netz und könnten miteinander kommunizieren. Um das zu verhindern, müssten wir VLANs einfügen, was dann die Komplexität dieses Artikels stark erhöhen würde. Aber bitte nicht falsch verstehen, VLANs machen im Hyper-V Cluster durchaus Sinn und wir empfehlen Sie auch (zumindest bei etwas größeren Umgebungen).

Schlussbemerkung

Damit ist unser Netzwerk für das Hyper-V Cluster korrekt konfiguriert. Da diese Konfiguration den Anspruch erhebt sich innerhalb der Microsoft Empfehlungen und Supportrichtlinien zu bewegen, habe ich gerne Michel Lüschers Angebot den Artikel zu prüfen wahrgenommen. Danke Michel für die Zeit und deine sehr hilfereichen Kommentare. Wer Michel nicht kennt, er ist für Microsoft in der Schweiz tätig und betreibt den sehr guten Blog Server-Talk.eu (findet ihr übrigens auch in unserer Blogroll).

Links

Wer noch mehr zu dem Thema erfahren möchte, dem habe ich noch ein paar Links zusammengetragen:

TechNet Modify Network Settings for a Failover Cluster

Alessandro Cardoso : Hyper-V : Network Design, Configuration and Prioritization : Guidance

TechNet Configuring Network Prioritization on a Failover Cluster

Michel Lüscher: How-To: Verwaltung eines Cluster Shared Volume (CSV)

Teilen:

Carsten Rachfahl

Dipl. Ing. Carsten Rachfahl ist seit mehr als 20 Jahren in der IT-Branche tätig. Er ist einer der geschäftsführenden Gesellschafter der Rachfahl IT-Solutions GmbH & Co. KG und für den technischen Bereich verantwortlich.

16 Comments:

  1. Hallo Carsten,

    ein wirklich toller Artikel, sehr gut geschrieben!
    Ich habe noch eine Frage: Sind die einzelnen Netze (ausgenommen das MGMT und das VM Netz) jeweils über Punkt-zu-Punkt Verbindungen also Crosslinkkabel an den Hosts angeschlossen, oder hast du die an einzelne Switche angeschlossen?

    LG

  2. Hallo Oliver,

    in unserem Szeanrio sind alle Netze an einer Switch. Du kannst aber, vorausgesetzt du hast nicht mehr wie zwei Hosts, auch das CSV und Livemigration Netz von Server zu Server verbinden. Es kann aber wohl zu Problemen kommen, wenn ein Server bootet, weil dann der Link auf dem anderen auch weg ist (habe ich gehört).

    Gruß Carsten

  3. Hi Carsten,

    Danke für die Antwort.
    Macht dies nicht auch Probleme, wenn alle Netze an einem Switch sind, oder ist das unproblematisch?

    Grüße

  4. Hi

    Punkt-zu-Punkt funktioniert ganz gut, aber bei einem Neustart eines Nodes wird dies durch den Failover Cluster als „Error“ geloggt, da der Network Adapter kurzzeitig nicht verfügbar ist.

    Weiter ist es natürlich zu empfehlen dies über mehrere Network Switches aufzubauen – je nach Anforderung des Kunden.

    Gruss
    Michel

  5. Hallo,

    also die Dokumentation ist echt super, aber aus technischer Sicht wundert es mich das hier alles mit Desktop Oberfläche beschrieben wird. Wer ein Hyper-V Cluster aufbaut nutzt doch eigentlich nur die Core Installation (z.B. die des Hyper-V Server 2008 R2).

    Wie konfiguriert man dann die ganzen Netzwerke. Vorallem würde mich mal interessieren wie man die Netzwerke entsprechend benennen kann (z.B. aus „Lan 2“ in „CSV“ umbennenn) oder wie man die Eigenschaften der Netzwerkkarte aufruft um z.B. den „Client für Microsoft Netzwerke“ für die iSCSI Verbindung zu deaktivieren.

    Gruß Jan

  6. Danke Jan für das Lob. Ja du hast recht es währe noch schöner wenn ich das ganze auf einer Hyper-V Server 2008 R2 Installation beschrieben hätte. Ich habe das auch überlegt, aber die Konfiguration ist auch mit GUI schon komplex genug. Der Artikel mit der Core Netzwerkkonfiguration kommt bestimmt irgendwann auch noch.

  7. Auf den Artikel mit der Core Installation freue ich mich persönlich auch!
    PS. sollte es wohl eine NetApp FAS2050 sein.
    Ich würde noch ein separates Netzwerk für die Sicherung einrichten.
    Ist wohl dann Geschmackssache und/oder vom Traffic abhängig. Zwei getrennte Switche im Cluster sind schon Pflicht, wenn es redundant bleiben soll ist aber wie gesagt immer vom Netzwerk und Kunden (Budget) abhängig.

    Gruß

  8. Hallo Carsten,

    danke für den tollen Artikel. Hat mir schon weiter geholfen bei der Planung meiner Hyper-V Cluster Netzwerke. Was ich derzeit noch nicht ganz verstehe is dieses ganze Gerede von Management und VM Netz.. wozu soll ich das trennen? Klar, das VM Netz braucht Performance..aber das Management Netz sicher nicht, oder? Ich würde gerne sowohl VM als auch Management Netz auf zwei „geteamte“ Netzwerkkarten in einem Netzwerksegment legen.. Was ist deine Meinung dazu?

    Danke & Gruß
    Sebastian

  9. Hallo Sebastian,

    dargestellt ist die „kleinste“ optimale Konfiguration. Du kannst sicherlich etwas ändern. Teaming ist so eine Sachen da Teaming bei Windows 2008 R2 reinen „Aufgabe“ der Netwerkkartenhersteller ist (das ändert sich zum Glück in Windows Server „8“). Wir haben VM-Netz und Management-Netz getrennt, da über das Management-Netz doch einige Aufgaben laufen:
    – Clusterkommunikation
    – alle Agenten wenn du SystemCenter einsetzt
    – Backup
    – es dient als Falback für die Livemigration

    Gruß Carsten

  10. Hallo Carsten und danke für die schnelle Antwort!

    Mein grundlegendes Problem ist das ich nicht wirklich weiss, wie ich die mir zur verfügung stehenden 8 NICs der Server verteilen soll. Der derzeitige unfertige Plan ist: 2x iSCSI MPIO, 2x Livemigration, 1x CSV+Heartbeat.. bleiben 3 NICs übrig. Wir haben ein dediziertes Server Segment im RZ, dort sollen auch die Hyper-V Maschinen erreichbar sein, das wäre dann quasi das Management Netz… Alle VMs die auf dem Cluster laufen, sollen entweder auch in dieses Server Segment oder in ein Testnetz gehängt werden.. Brauch ich dann überhaupt eine Aufteilung zw. Management und VM Netz wenn die am Ende sowieso im gleichen L3 Segment enden?

    Vielen Dank für deine Unterstützung!

    Sebastian

  11. Hallo Sebastian,

    ich würde 2x VM machen und 1x Management. Hast du mit dem Teaming schon Erfahrungen? Meist ist das einen nicht so tolle uns stabile Lösung. Wichtig sind die richtigen Treiber Versionen. Oft haben die Server NICs unterschiedliche Hardwarehersteller. Dann kannst du fast immer nicht zwischen den verschiedenen Herstellern teamen. Aber am Ende des Tages geben wir auch nur Ratschläge und du mußt für dich entscheiden wie du es umsetzt.

    Gruß Carsten

  12. Danke für deine Antwort!

    Ja hab schon einige Systeme mit Teaming laufen, bisher keine Probleme gehabt. Server-seitig setzen wir ausschließlich auf HP, Netzwerk ist nur Cisco im Einsatz. Wir nutzen ausschließlich LACP Channels, funktioniert gut!

    Ich versteh das mit der Trennung des Mgmt und VM Netzes immernoch nicht so ganz, sorry. Warum trennen wenn es am Ende im gleichen IP Segement und auf den selben Switches endet?

    Grüße
    Sebastian

  13. Hallo Sebastian,

    wie gesagt es ist eine Bestpractice die du überall referenziert findest. Für mich gibt es meherere Gründe:

    – viele Implementationen arbeiten nicht mit Teaming (zu komplex, zu instabiel,…)

    – nicht alle VM Netze sind automatisch in dem Gleichen IP Bereich wie das Management Netz. Oft möchte man sogar einen physikalische Trennung

    – Ob die die Effekte mit Teaming erreichst du man sich wünscht hängt von der Art des Teamings ab. Bei manchen Varianten müßen sowohl Switch wie auch Host konfiguriert werden

    – Das Management Interface ist für Traffic vom Host. Das VM Interface rein für Traffic von der VMs. Es gibt einen klare logische Trennung.

    Wie gesagt du mußt entscheiden ob du die Netze zusammen legst oder nicht ich kann nur Bestpractices aus unseren Erfahrungen geben.

    Gruß Carsten

    e

  14. Markus Burggraf

    Hallo,

    vielen Dank für den Artikel.
    Ich hab eine Frage zu MPIO von Hyper-V zur Netapp.
    Mein Verständnis ist, daß dafür Adapter aus unterschiedlichen Subnetzen erforderlich sind, wie Du es auch beschrieben hast, sowohl auf Netapp, wie auch auf Hyper-V Seite.

    Ich hab aber jetzt schon mehrfach gelesen, daß für so was nur 1 Subnetz genutzt wird.
    Nach meinem Verständnis wird dann die ISCSI Verbindung immer nur von 1 NIC des Servers aufgebaut, nicht von mehreren, und damit wäre MPIO kein großer Gewinn in Sachen Performance, höchstens in Sachen Verfügbarkeit. Stimmt das so?

    Grüße

    Markus

  15. Pingback: faq-o-matic.net » Hyper-V: Best Practice zur Netzwerk-Konfiguration

  16. Michael Matauschek

    Hallo,

    ich habe ein Frage zu den Netzwerkkarten. Ich benutzer hier HP Server mit Flexfabric Adaptern 10G. Kann also Pro Server mit mit 8 Logischen Netzwerkkarten arbeiten. Storage läuft über eine Separate FC-Karte.
    Wie würdet ihr die Netze verteilen. Und wie würdet ihr die Bandbreite von 10G pro 4 Ports verteilen. Welche Netze brauchen wie viel?
    Also Port 1 Server 1 10G
    Link 1
    Link 2
    Link 3
    Link 4
    Also Port 2 Server 2 10G
    Link 1
    Link 2
    Link 3
    Link 4

    VG Micha

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.