Hyper-V 2.0 Failover: Fragen zum Netzwerkdesign

[dron 10]

Hallo zusammen,

 

momentan bauen wir ein Hyper-V 2.0 Failover Netzwerk auf. Wir fragen uns, ob wir den richtigen Weg bzgl. des Netzwerkdesigns gewählt haben. Vielleicht kann uns jmd. einen kleinen Tipp liefern.

 

Unsere Systeme sehen wie folgt aus:

 

2x Nodes Windows Server 2008 R2 (Hyper-V 2.0 und FailoverclusterManager)

1x DC Windows Server 2008 R2

1x SAN (iSCSI)

 

Auf jedem Nodes sollen später 4 virt. Server gehostet werden.

 

Jeder Nodes-Server verfügt insgesamt über 6 Netzwerkkarten. Wir haben folgende Aufteilung vorgesehen:

 

2x iSCSI, 1x Heartbeat / LiveMig, 3x ProduktivLan

 

Somit haben wir jeweils im Hyper V Manager die 3 ProduktivLan-NIC's als extern definiert und den Haken für die gemeinsame Verwendung aktiviert. Bei den virtuellen Gastsystemen haben wir dann unterschiedliche virtuelle Netzwerke definiert. Dadurch wollten wir eine Lastverteilung erreichen.

 

Daraus ergibt sich folgende Netzwerkkonfiguration:

 

SAN:

Crtl0Port0: 100.168.2.64

Crtl0Port1: 100.168.2.65

Crtl1Port0: 100.168.3.66

Crtl1Port1: 100.168.3.67

 

VM-Node-Server 1:

Heartbeat (Cross): 100.168.1.20

iSCSI_1: 100.168.2.20

iSCSI_2: 100.168.3.20

LAN_1: virt_Switch_01

LAN_2: virt_Switch_02

LAN_3: virt_Switch_03

virt_Switch_01: 100.143.37.21 (SM: 255.255.255.0) (GW: .1)

virt_Switch_02: 100.143.37.22 (SM: 255.255.255.0) (GW: .1)

virt_Switch_03: 100.143.37.23 (SM: 255.255.255.0) (GW: .1)

 

VM-Node-Server 2:

Heartbeat (Cross): 100.168.1.21

iSCSI_1: 100.168.2.21

iSCSI_2: 100.168.3.21

LAN_1: virt_Switch_11

LAN_2: virt_Switch_12

LAN_3: virt_Switch_13

virt_Switch_11: 100.143.37.24 (255.255.255.0) (GW: .1)

virt_Switch_12: 100.143.37.25 (255.255.255.0) (GW: .1)

virt_Switch_13: 100.143.37.26 (255.255.255.0) (GW: .1)

 

Das SAN wurde über den iSCSI-Initiator angebunden.

 

Nach erfolgreicher Installation der virtuellen Gastsysteme haben wir dann den Failover Manager installiert. Nach der Konfiguration der CSV stehen uns nun 2 Knoten zur Verfügung. Unter den Netzwerken werden uns nun 4 Clusternetzwerke angezeigt:

 

Clusternetzwerk_1: (Nodes_1 - virt_Switch01) / (Nodes_2 - virt_Switch12)

aktiviert (Netzwerkkommunikation zulassen - Clients die Verbindung gestatten)

 

Clusternetzwerk_2: (Nodes_1 - iSCSI-1) / (Nodes_2 - iSCSI-1)

intern (Netzwerkkommunikation zulassen)

 

Clusternetzwerk_3: (Nodes_1 - Heartbeat) / (Nodes_2 - Heartbeat)

intern (Netzwerkkommunikation zulassen)

 

Clusternetzwerk_4: (Nodes_1 - iSCSI-2) / (Nodes_2 - ISCSI-2)

intern (Netzwerkkommunikation zulassen)

 

Nun stellen sich uns doch einige Fragen:

 

1. Ist die Aufteilung der Netzwerkkarten sinnvoll, bzw. ist die Konfiguration soweit in Ordnung?
   
2. Ist in dieser Konstellation eine Lastverteilung und ein Failover bei einem NIC-Ausfall gegeben?
   

 

Jedenfalls bedanke ich mich schon mal vorab und wünsche euch ein schönes Weihnachtsfest.

 

Viele Grüße

Björn

bearbeitet 22. Dezember 2010 von dron

[NilsK 2.934]

Moin,

 

ein echtes Failover auf NIC-Ebene bekommt ihr nur über Teams hin. Die habt ihr allerdings nicht eingerichtet - und um das nachzuholen, müsstet ihr Hyper-V komplett wieder deinstallieren.

 

Sind die iSCSI-Verbindungen über MPIO eingerichtet?

 

Ansonsten soweit okay, aber die IP-Adressen sind seltsam. Was ist das für ein Adress-Segment?

 

Dies hier ist evtl. interessant für euch:

faq-o-matic.net Hyper-V, Cluster und VMM: Ein paar Detailhinweise zur Installation

 

Und allgemein:

faq-o-matic.net Virtualisierung

 

Ist das ein Produktionsnetz? Dann ist 1 DC zu wenig. Wenigstens einen VM-DC sollte es dazu noch geben.

 

Gruß, Nils

[dron 10]

Vielen Dank für deine rasche Antwort. Nur zum besseren Verständnis:

 

 

1) IP-Adressen:

verschrieben (100 --> 10)

 

2) Netzwerk-Redundanz

Ok, das mit dem Teaming lassen wir dann mal sein :) D.h., dass wir im Falle eines NIC-Defektes nur den virt. Netzwerkadapter der VM manuell ändern müssten, oder?

 

3) Netzwerk Hyper-V Manager

Es gibt ja im Hyper-V Netzwerk-Manager den Haken "Gemeinsames Verwenden dieses Netzwerkadapters für das Verwaltungsbetriebssystem". Muss diese Option bei allen 3 Produktiv-NICS gesetzt werden oder reicht es, wenn dieser Haken nur bei einem Adapter aktiviert wird? Was ist denn ratsam? Mir ist nicht ganz klar, was sich genau dahinter verbirgt. Wenn diese Option nicht gesetzt ist, dann erscheint kein virt Windowsadapter.

 

4) Netzwerk Failover Manager

Im Failover-Manager werden ja die 4 o.g. Clusternetzwerke angezeigt. Der Konfigurationsassistent hat eine Warnung geworfen, dass mehrere Netzwerkkarten ins selbe Subnetz verweisen. Daher wird unter Clusternetzwerk_1 nur die Adapter virt_Switch01 und virt_Switch_12 angezeigt.

 

Hat es einen bestimmten Grund warum nur diese beiden dargestellt werden?

Was läuft denn überhaupt über das Clusternetzwerk, bei welchem die Option "Clients Verbindungen gestatten" aktiviert ist?

 

5) Produktivbetrieb

Es handelt sich in unserem Fall um einen Prod-Betrieb. Ein virt. Server läuft noch zusätzlich als redundanter DC.

 

6) SAN

Im iSCSI-Initiator habe ich lediglich die 4 SAN-IP's unter den Zielen eingetragen. Anschließend über Volumens habe ich die LUN's automatisch konfiguriert. MPIO ist nicht aktiviert. Benötige ich das zwingend?

 

 

Besten Dank vorab & viele Grüße

Björn

bearbeitet 22. Dezember 2010 von dron

[NilsK 2.934]

Moin,

 

wenn du redundant auf das SAN zugreifst, verhindert MPIO, dass der Server den Storage im Normalbetrieb doppelt sieht. Denn das soll er natürlich nicht.

 

Gruß, Nils

[dron 10]

Hi Nils,

 

dann werden wir wohl MPIO für das Gerät aktivieren. Komischerweise haben ohne MPIO null Probleme gehabt. Die Volumes konnten wir sauber anbinden... Die LUN's sind auch nur 1x erschienen.

 

Kannst du uns evtl. auch bei den anderen Punkten 2-5 weiterhelfen????

 

Gruß

Björn

[TheDonMiguel 11]

Hi

 

Hast ja einige Fragen ;)

 

2) Netzwerk-Redundanz

Ok, das mit dem Teaming lassen wir dann mal sein :) D.h., dass wir im Falle eines NIC-Defektes nur den virt. Netzwerkadapter der VM manuell ändern müssten, oder?

Bist dir sicher, dass du solch ein Design produktiv nehmen willst? Ich würde die Zeit investieren um eine saubere Basis zu schaffen...

 

3) Netzwerk Hyper-V Manager

Es gibt ja im Hyper-V Netzwerk-Manager den Haken "Gemeinsames Verwenden dieses Netzwerkadapters für das Verwaltungsbetriebssystem". Muss diese Option bei allen 3 Produktiv-NICS gesetzt werden oder reicht es, wenn dieser Haken nur bei einem Adapter aktiviert wird? Was ist denn ratsam? Mir ist nicht ganz klar, was sich genau dahinter verbirgt. Wenn diese Option nicht gesetzt ist, dann erscheint kein virt Windowsadapter.

Empfohlen wäre, dass du zwei der drei "LAN-NICs" in einem Teaming konfigurierst, und dann einen Virtual Network Switch (external) auf die Teamed NIC konfigurierst. Sharing (Gemeinsame Verwendung) musst / solltest du dann nicht aktivieren.

 

4) Netzwerk Failover Manager

Im Failover-Manager werden ja die 4 o.g. Clusternetzwerke angezeigt. Der Konfigurationsassistent hat eine Warnung geworfen, dass mehrere Netzwerkkarten ins selbe Subnetz verweisen. Daher wird unter Clusternetzwerk_1 nur die Adapter virt_Switch01 und virt_Switch_12 angezeigt.

 

Hat es einen bestimmten Grund warum nur diese beiden dargestellt werden?

Was läuft denn überhaupt über das Clusternetzwerk, bei welchem die Option "Clients Verbindungen gestatten" aktiviert ist?

Wenn du die bei Punkt 3 beschriebene Konfiguration umsetzt, werden diese NIC's nicht mehr angezeigt und im FC Manager auch nicht mehr verwendet. Lass die Validierung dann aber nochmals laufen. Es sollte dann nur noch eine Warnung zu den iSCSI Adapter kommen, was OK ist.

 

5) Produktivbetrieb

Es handelt sich in unserem Fall um einen Prod-Betrieb. Ein virt. Server läuft noch zusätzlich als redundanter DC.

Ev. ein Review durch einen Partner machen lassen?!

 

6) SAN

Im iSCSI-Initiator habe ich lediglich die 4 SAN-IP's unter den Zielen eingetragen. Anschließend über Volumens habe ich die LUN's automatisch konfiguriert. MPIO ist nicht aktiviert. Benötige ich das zwingend?

Wenn du mehrere iSCSI Initiator hast, dann ja. MPIO regelt dann den Zugriff auf das iSCSI Target. Prüfe ob dein Storage Anbieter noch eigene DSM anbietet.

 

Viele Grüsse

Michel

[dron 10]

Hi Michel,

 

danke, dass du dir die Zeit genommen hast auf diese tausend Fragen zu antworten :)

 

Im Nachhinein wird einiges klarer. NIC-Teaming scheint doch elegantere Variante zu sein. Damit sind meine o.g. Fragen zu dem Netzwerkdesign wahrscheinlich hinfällig. Mich plagen aber immer noch zwei Verständnisfragen:

 

1) Angenommen ich setze diese drei Prod-LAN-NIC's als virtuelle NIC's ein. Was bewirkt denn das Sharing? Heisst das, das die zugehörige VM über diese NIC, also über das Gateway hinweg kommunizieren kann? Laufen dann die nicht-geshareten NIC's über die gemeinsame NIC in andere Netze? I-wie ist mir das noch nicht ganz so klar.

 

2) Was bedeutet denn im Failover-Manager ein Clusternetz, welches Clients den Zugriff erlaubt? Auf den virt. Maschinen kann ich ja das Failover-Netz für die Live-Migration definieren. Was machen dann die Clusternetze?

 

Wahrscheinlich klingen die Fragen für euch sehr trivial. Allerdings komme ich trotz I-net Recherche (auch in eurem Forum) momentan nicht weiter.

 

Besten Dank & viele Grüße

Björn

[TheDonMiguel 11]

Hallo Björn

 

zu 1) wenn du "sharing" aktiviert hast, kann die Parent Partition diese NIC ebenfalls verwenden. Sprich, dort ist das TCP/IP Protokoll aktiv. Ist der Hacken nicht aktiviert, werden sämtliche Protokolle "entfernt" und diese NIC(s) stehen nur noch den VMs via Virtual Network Switch zur verfügung. Am einfachsten, testen und den unterschied anschauen (einfach Properties öffnen)

 

zu 2) für Hyper-V konfiguriert als Failover Cluster brauchst du folgende Netze:

- Management: Dieses Netzwerk dient primär der Administration. Zudem nutzen sämtliche Management Agents dieses Netztwerk (ev. auch Backup). Clients können hier connecten.

 

- Heartbeat: Das klassische Cluster Netztwer dient dem Check, ob sämtliche Cluster "online / alive" sind. Bei Hyper-V wird per Default hier auch der CSV Traffic (änderungen der Metadaten) darüber geleitet. Daher muss dies auch GBit sein. Dies steht nur dem Cluster zur Verfügung. Bei grossen Umgebungen gibt es ein eigenes CSV Netzwerk...

 

- Live Migration: Wie du schon gesagt hast, genutzt um VMs zu verschieben. GBit ist hier ebenfalls ein muss. Dies steht nur dem Cluster zur Verfügung.

 

- VM's: Dieses Netztwerk sieht du im FC-Manager nicht, da nur das Virtua Network Switch Protocol aktiviert ist. Der Cluster hat darüber keine Kontrolle / keinen Einfluss.

 

Dies hier schon mal angeschaut? How-To: Verwaltung eines Cluster Shared Volume (CSV) | Server Talk

 

Gruss

Michel

[NilsK 2.934]

Moin,

 

mir stellt sich gerade die Frage, wie man einen Cluster für die Produktion einrichten kann, ohne sich vorher mit den nötigen Grundlagen befasst zu haben ...

 

Nimm's mir nicht übel, aber die Reihenfolge ist nicht gut. Einen Cluster baut man, weil man sich darauf verlassen können muss. Das könnt ihr aber nicht, wenn ihr das System nicht mit ausreichender Handlungssicherheit aufbaut. Hinterher ist das Geschrei dann groß (und gerne "Microsoft" Schuld), wenn das System die Erwartungen nicht erfüllt.

 

Gruß, Nils

... der solche Diskussionen (leider) recht häufig führt

[TheDonMiguel 11]

moin,

 

mir stellt sich gerade die frage, wie man einen cluster für die produktion einrichten kann, ohne sich vorher mit den nötigen grundlagen befasst zu haben ...

 

Nimm's mir nicht übel, aber die reihenfolge ist nicht gut. Einen cluster baut man, weil man sich darauf verlassen können muss. Das könnt ihr aber nicht, wenn ihr das system nicht mit ausreichender handlungssicherheit aufbaut. Hinterher ist das geschrei dann groß (und gerne "microsoft" schuld), wenn das system die erwartungen nicht erfüllt.

 

Gruß, nils

... Der solche diskussionen (leider) recht häufig führt

 

full ack :(