Netzwerkkonfiguration

[Joern Henrichs]

Hallo NG.

Ich habe eine Frage zur Netzwerk-Konzeption eines HyperV - Clusters.

Vorh. Umgebung:
- 2 Bladecenter, r�umlich getrennt
- darin zun�chst je ein Blade f�r den HyperV-Cluster
- jedes Bladecenter hat 2 redundante Ethernet - Switche
- jedes Blade hat 6 NICs, davon jeweils 3 NICs auf je einen der Ethernet
Switche
- HyperV-Host und Guests laufen im selben Netz

Geplant hatte ich einen Port f�r die Hosts als Heartbeat.
Diesen nicht redundant, da die Clusterkommunikation alternativ �ber Public-LAN
laufen k�nnte.

Ein Teaming mit 2 Ports (je 1 x auf Switch 1 und 2) f�r die Hosts als Public-LAN.

F�r die VM's dann 2 Trunks (je 1 x auf Switch 1 und 2) mit 4 x 1 GBit direkt
an den Router.
Aus den Trunks k�nnte man dann von jedem Switch den VM's je eine virtuelle
Netzwerkkarte konfigurieren,
die man in der VM wiederum teamen k�nnte (oder nicht?).

Dann w�rde der Host aber "seine" Netzwerkkarten und die der Guests aus den
gleichen Netzwerksegmenten sehen.
Damit w�re er ja multihomed ...
(Die Einrichtung eines eigene Netzes f�r die VM's ist nicht geplant)

Sollte das Public-LAN f�r die Hosts geteamt werden ?
Gibt es ein White-Paper oder Best-Practice ?

Ich hoffe die Beschreibung war verst�ndlich !?

Viele Gr��e,

J�rn

[RCan]

Hi J�rn,

das sollte alle deine Fragen direkt beantworten k�nnen ;-)

Hyper-V: Live Migration Network Configuration Guide
http://technet.microsoft.com/en-us/library/ff428137(WS.10).aspx

Bei Fragen bitte einfach nochmal melden.

Danke und Gru�
Ramazan

"Joern Henrichs" <joern.h...@bog.de> wrote in message
news:7622c9c199bc8...@msnews.microsoft.com...

[Joern Henrichs]

Hi RCan,

also die Empfehlung aus dem Dokument ist 4 Netze: VM Access, Management,
CSV und Live Migration.
Wenn iSCSI zum Einsatz kommt sind es 5.

Meine Blades haben 6 NIC's, also erst einmal ausreichend.

Folgendes scheint mir nicht eindeutig erl�rt oder ich habe es nicht verstanden:
- M�ssen alle Netzwerke in einem eigenen Netzwerk-Segment liegen (vermutl.
ja, denn sonst haben wir Multihoming)

- Wie funktioniert es mit der Ausfallsicherheit der LAN's ?
a) VM Access: merkt der Cluster den Ausfall des Netzwerkes und leitet
den Traffic intern um ?
Im Dokument steht in der ersten Tabelle, zweite Zeile: "Public Access
could be teamed".
Einen auf dem Host geteamten Adapter kann ich aber nicht als virtuellen
Switch den VM's zur Verf�gung stellen.
Wie ist das gemeint, bzw. wie ist die Verf�gbarkeit der VM's aus dem
Public LAN sicher gestellt ?
L��t sich ein teaming im Guest einrichten ?

b) Management: ist f�r die Funktion des Cluster nicht zwingend erforderlich
und ein Ausfall w�rde die Ressourcen nicht beeinflussen.
Also ist keine hochverf�gbare Leitung n�tig.

c) CSV und Cluster: ein Netzwerk f�r das Shared Volume und die interne
Clusterkommunikation (oder was ist mit Cluster gemeint) ?
Die interne Clusterkommunikation l�uft alternativ automatisch �ber
das Public-LAN. Wie ist es mit dem CSV-Traffic ?

d) LiveMigration: ohne dieses Netz keine LiveMigration. Muss also f�r
die Verf�gbarkeit der Ressourcen (sofern nicht migriert wird) nicht vorhanden
sein, also auch nicht gedoppelt werden ?

e) iSCSI: W�rde ich auf Host-Ebene teamen (AdaptiveLoadBalancing)

Es w�re nett wenn Du mich aufkl�ren k�nntest.
Vielen Dank im voraus !

Viele Grue�e,

Joern

[RCan]

Hi J�rn,

siehe unten....

> Folgendes scheint mir nicht eindeutig erl�rt oder ich habe es nicht
> verstanden:
> - M�ssen alle Netzwerke in einem eigenen Netzwerk-Segment liegen (vermutl.
> ja, denn sonst haben wir Multihoming)

korrekt - alle adapter die du im cluster verwenden willst, m�ssen in einem
seperaten netzwerk (subnet) sein. ansonsten werden diese netze von failover
cluster ignoriert. Die ISCSI NICs k�nnten/sollten im selben netz liegen, bis
auf 1 ISCSI NIC (=> Cluster Netzwerk) werden sie dann aber nicht zum cluster
hinzugef�gt werden.

> - Wie funktioniert es mit der Ausfallsicherheit der LAN's ?
> a) VM Access: merkt der Cluster den Ausfall des Netzwerkes und leitet
> den Traffic intern um ?
> Im Dokument steht in der ersten Tabelle, zweite Zeile: "Public
> Access could be teamed".

das ist nicht korrekt - generell ist NIC teaming mit failover cluster +
hyper-v (virtuellen switch) unterst�tzt, aber es muss auch von dem
hersteller deiner NICs supported werden. Ich pers�nlich habe bisher gute
erfahrungen mit Intel (HP) oder auch broadcom NICs serverclass NICs.

> Einen auf dem Host geteamten Adapter kann ich aber nicht als
> virtuellen Switch den VM's zur Verf�gung stellen.

Warum nicht, sobald du den virtuellen Switch auf den teamed adapter bindest,
kannst du die VMs darauf verbinden. Seit R2 kannst du auch die NIC
"exclusiv" f�r Hyper-V VM traffic verwenden ("do no share this adapter
...").

> Wie ist das gemeint, bzw. wie ist die Verf�gbarkeit der VM's aus dem
> Public LAN sicher gestellt ?
> L��t sich ein teaming im Guest einrichten ?

Nein - das ist aktuell (noch) nicht supported. NLB innerhalb der VMs wird
allerdings unterst�tzt, muss aber auch von deiner App supported werden !
Wie gesagt, die L�sung hier ist -> NIC Teaming.

> b) Management: ist f�r die Funktion des Cluster nicht zwingend
> erforderlich und ein Ausfall w�rde die Ressourcen nicht beeinflussen.
> Also ist keine hochverf�gbare Leitung n�tig.

Nein - Management steht f�r das administrative netzwerk, wor�ber
normalerweise die administration oder auch der Backup traffic l�uft.

> c) CSV und Cluster: ein Netzwerk f�r das Shared Volume und die interne
> Clusterkommunikation (oder was ist mit Cluster gemeint) ?

Cluster = heartbeat communication zwischen dem cluster, welches aber nicht
mehr so zwingend notwendig ist, wie unter NT/2000/2003 zeiten. Ein seperates
netzwerk (bestfall 10GBit) f�r den CSV traffic macht allerdings Sinn, weil
dar�ber die live migration oder auch der redirected mode (SAN zugriff l�uft
�ber ethernet) gefahren wird ;-)

> Die interne Clusterkommunikation l�uft alternativ automatisch �ber
> das Public-LAN. Wie ist es mit dem CSV-Traffic ?

Dies kann im failover cluster manager oder via powershell konfiguriert
werden, welches netzwerk aus der cluster perspective f�r den CSV/live
migration traffic verwendet werden soll.
Weitere Informationen hierzu findest du hier ->

"....Network adapters. For each node of the failover cluster, use more than
one network adapter and configure at least one network adapter for the
private virtual network. We recommend that you configure a dedicated private
network with Gigabit speed for live migration traffic, and this network
should be separate from the network for private communication between the
cluster nodes, from the network for the virtual machine, and from the
network for storage. For information about the network traffic that can
occur on a network used for Cluster Shared Volumes, see "Understanding
redirected I/O mode in CSV communciation" in Requirements for Using Cluster
Shared Volumes in a Failover Cluster in Windows Server 2008 R2
(http://go.microsoft.com/fwlink/?LinkId=182153)....."
http://technet.microsoft.com/en-us/library/dd446679(WS.10).aspx

> d) LiveMigration: ohne dieses Netz keine LiveMigration. Muss also f�r
> die Verf�gbarkeit der Ressourcen (sofern nicht migriert wird) nicht
> vorhanden sein, also auch nicht gedoppelt werden ?

Nein, du brauchst dich darum nicht zu k�mmern. Der cluster �bernimmt das
komplett. Im hintergrund wird ein sogenanntes VM "skelett" auf dem
zielsystem angelegt und dann der RAM komplett auf dem neuen Hyper-V
�bertragen. Sobald du die VM als "highly available" im failover cluster
manager definierst, kannst du quick/live migration durchf�hren. Auch CSV
ist kein muss, f�r live migration ! Mehr Infos zum Thema live migration ->
http://download.microsoft.com/download/5/B/D/5BD5C253-4259-428B-A3E4-1F9C3D803074/LiveMigrationWhitepaper_Final.docx

> e) iSCSI: W�rde ich auf Host-Ebene teamen (AdaptiveLoadBalancing)

Nicht supported - ISCSI kannst du nur mittels MPIO oder MCS (multiple
connection service) hoch verf�gbar gestalten. Siehe hierzu ->
http://download.microsoft.com/download/a/e/9/ae91dea1-66d9-417c-ade4-92d824b871af/uguide.doc

Bei Fragen einfach nochmal melden....

Gru�
Ramazan

"Joern Henrichs" <joern.h...@bog.de> wrote in message

news:7622c9c199ef8...@msnews.microsoft.com...

[Joern Henrichs]

Hallo RCan,

zun�chst vielen, vielen Dank f�r Deine Antworten und Bem�hungen und damit
der Hilfe, die Du mir und allen anderen Forenmitgliedern zu Teil werden l��t
!

OK, das Teaming f�r die VM's l��t sich nachtr�glich in einem virt. Switch
konfigurieren.
Wenn das Teaming bereits vorhanden ist, wenn die HyperV-Rolle installiert
wird, kommt es zu einer Fehlermeldung, das dies nicht unterst�zt wird (bei
mir zumindest).

Zum Management schreibst Du, das dar�ber administrative Tasks oder Backup
l�uft.
Ben�tigt das Management soviel Bandbreite, das das ein eigenes Netz erforderlich
ist ?
Best Practice daf�r ist ok, aber es kann auch �ber das Public LAN laufen,
zumindest dann, wenn aus Infrastrukturgr�nden keine eigenes Netz daf�r m�glich
ist.

Da ich sechs NIC in den Blades habe, komme ich auf folgende Konfig:

Nic 1 + 2 : Public f�r VM (Teaming Fehlertoleranz, 2 x 1 GBit)
Nic 3 + 4 : iSCSI (MPIO 2 x 1 GBit)
Nic 5 : Heartbeat und Livemigration (1 GBit)
Nic 6 : Management (1 GBit)

Zum Teaming h�tten die "Netzwerker" lieber Fehlertoleranz (ein Adapter ist
Standby),
als LoadBalancing (beide NICs aktiv, mehr Bandbreite) konfiguriert.
Auf den Switchen entsteht durch die gleichzeitige Aktivierung von zwei NICs
beim Loadbalancing-Modus eine erh�hte CPU-Last
(virtuelle MAC-Adresse schaltet st�ndig zwischen Switchports hin und her
?), die nat�rlich nicht gew�nscht ist ....
Es sind sind Intel 82575EB GBit -Chips verbaut.
Kennst Du das Ph�nomen oder ist es vermutlich eher ein Treiber-Fehler ?

Viele Gr��e, J�rn

>

[Tobias Redelberger [MVP - SBS]]

Hi Joern,

> zun�chst vielen, vielen Dank f�r Deine Antworten und Bem�hungen und damit
> der Hilfe, die Du mir und allen anderen Forenmitgliedern zu Teil werden
> l��t !
>
> OK, das Teaming f�r die VM's l��t sich nachtr�glich in einem virt. Switch
> konfigurieren.
> Wenn das Teaming bereits vorhanden ist, wenn die HyperV-Rolle installiert
> wird, kommt es zu einer Fehlermeldung, das dies nicht unterst�zt wird (bei
> mir zumindest).
>
> Zum Management schreibst Du, das dar�ber administrative Tasks oder Backup
> l�uft.
> Ben�tigt das Management soviel Bandbreite, das das ein eigenes Netz
> erforderlich ist ?
> Best Practice daf�r ist ok, aber es kann auch �ber das Public LAN laufen,
> zumindest dann, wenn aus Infrastrukturgr�nden keine eigenes Netz daf�r
> m�glich ist.
>
> Da ich sechs NIC in den Blades habe, komme ich auf folgende Konfig:
>
> Nic 1 + 2 : Public f�r VM (Teaming Fehlertoleranz, 2 x 1 GBit)
> Nic 3 + 4 : iSCSI (MPIO 2 x 1 GBit)
> Nic 5 : Heartbeat und Livemigration (1 GBit)
> Nic 6 : Management (1 GBit)

besser bei 6 NICs:

Nic 1 + 2 : Public f�r VM (Teaming LoadBalancing/Fehlertoleranz, 2 x 1 GBit)

Nic 3 + 4 : iSCSI (MPIO 2 x 1 GBit)

Nic 5 + 6: Management, Heartbeat und Livemigration (Teaming
LoadBalancing/Fehlertoleranz, 2 x 1 GBit)

Vgl. auch den allg. g�ltig Ansatz aus VMware-Welt:

The Great vSwitch Debate - Part 7
http://kensvirtualreality.wordpress.com/2009/05/01/the-great-vswitch-debate-part-7/

> Zum Teaming h�tten die "Netzwerker" lieber Fehlertoleranz (ein Adapter ist
> Standby),
> als LoadBalancing (beide NICs aktiv, mehr Bandbreite) konfiguriert.
> Auf den Switchen entsteht durch die gleichzeitige Aktivierung von zwei
> NICs beim Loadbalancing-Modus eine erh�hte CPU-Last
> (virtuelle MAC-Adresse schaltet st�ndig zwischen Switchports hin und her
> ?), die nat�rlich nicht gew�nscht ist ....
> Es sind sind Intel 82575EB GBit -Chips verbaut.
> Kennst Du das Ph�nomen oder ist es vermutlich eher ein Treiber-Fehler ?

LoadBalancing sollte ein moderner Switch k�nnen.

S. hier auch die allg. g�ltigen Informationen aus der VMware-Welt:

The Great vSwitch Debate - Part 3
http://kensvirtualreality.wordpress.com/2009/04/05/the-great-vswitch-debate%E2%80%93part-3/

--
Tobias Redelberger
StarNET Services (HomeOffice)
Frankfurter Allee 193
D-10365 Berlin
Tel: +49 (30) 86 87 02 678
Mobil: +49 (163) 84 74 421
Email: T.Rede...@starnet-services.net
Web: http://www.starnet-services.net

[RCan]

Hi Joern,

generell sieht die Aufteilung ganz gut aus, den Live Migration ein separates
Netzwerk zu geben, macht auf jedenfall Sinn.
Somit hast du FT im VM traffic und ISCSI bereich :-) Ideal w�re nat�rlich
auch das LM netzwerk zu teamen, aber.... :-(

> Zum Teaming h�tten die "Netzwerker" lieber Fehlertoleranz (ein Adapter ist
> Standby),
> als LoadBalancing (beide NICs aktiv, mehr Bandbreite) konfiguriert.
> Auf den Switchen entsteht durch die gleichzeitige Aktivierung von zwei
> NICs beim Loadbalancing-Modus eine erh�hte CPU-Last
> (virtuelle MAC-Adresse schaltet st�ndig zwischen Switchports hin und her
> ?), die nat�rlich nicht gew�nscht ist ....

Generell kann ich die Kollegen gut verstehen, da Sie bei "Failover only
(AFT, SFT)" keine Switchkonfiguration anpassen m�ssen. CPU-Last .... das
sollte ein "normaler" business class network switch ohne weiteres wegstecken
;-)
Bei einem "echten" teaming (802.3ad) wird ein port-channel/trunk
configuriert, dies ist wiederrum auch abh�ngig vom hersteller deiner NICs.
Jeder hersteller hat da seine eigenen teaming modes. Sofern m�glich solltest
du den 802.3ad standard verwenden ->
http://www.ieee802.org/3/hssg/public/apr07/frazier_01_0407.pdf

> Es sind sind Intel 82575EB GBit -Chips verbaut.
> Kennst Du das Ph�nomen oder ist es vermutlich eher ein Treiber-Fehler ?

Achtung, hier ist es wirklich stark abh�ngig vom hersteller seiner teaming
implementation, in welcher Reihenfolge die Teaming Software und Hyper-V
installiert sein m�ssen! Bsp: bei HP (Broadcom/Intel) NICs muss erst Hyper-V
installiert werden und dann erst die NIC Teaming software ->
http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01663264/c01663264.pdf .
Welches teaming modus f�hrst du gerade (AFT, SFT, ALB...) ?

Ich w�rde wie folgt vorgehen um Teaming mit Hyper-V zu verwenden:
1. OS + Hyper-V installieren
2. Teaming Software installieren
3. Teaming configurieren
4. Hyper-V virtuelle Netzwerke configurieren

Gru�
Ramazan

"Joern Henrichs" <joern.h...@bog.de> wrote in message

news:7622c9c19a978...@msnews.microsoft.com...