Anbindung eines ISCSI SANs an Hyper-V Cluster

[Confuse 0]

Guten Tag zusammen,

 

Ich lese gerade das Buch Hyper-V und System Center um mich in die Thematik des Clusteraufbaus unter Server 2012 zu fuchsen. Hintergrund ist, dass ich eine Testumgebung aufbauen möchte, für die ich die folgende Hardware zur Verfügung habe:
 

1 Domain Controller für die Clusternodes mit Server 2012R2
2 Cluster Nodes beide mit Server 2012R2
2 Netgear Switches GS724TP (Nicht stackable)
1 QNAP TS-879U-RP das als ISCSI Ziel genutzt werden soll
 

Die Clusternodes haben jeweils 6 NICs bzw. Ports (2 onboard und jeweils eine Intel Quadport I340-T4) und das QNAP hat 2 NICs.

 

Die Clusterknoten sollen jeweils einen NIC Port für ISCSI bekommen, und dann auf beide Switches verteilt werden.

 

Nun zu meiner Frage: Da im Buch öfter die Rede von der redundanten Anbindung der Knoten an das ISCSI Ziel ist, und dies halt nicht per Teaming sondern per MPIO vorgenommen werden soll, frage ich mich ob dies in meinem Szenario überhaupt greift. Ich habe ja pro Knoten nur einen NIC Port für ISCSI, ist MPIO in diesem Fall notwendig? Wenn ja muss das Feature auf meinen Clusterknoten und im ISCSI Ziel aktiv sein?

 

Gruß Confuse

 

http://files.qnap.com/news/pressresource/product/How_to_connect_to_iSCSI_targets_on_QNAP_NAS_using_MPIO_on_Windows_2008.pdf

 

Diese Anleitung von QNAP beschreibt das Szenario mit einem Server der 2 NICs hat, aber wie läuft es mit der Cluster Konfiguration? Lege ich die 2 benötigten IP Adressen einfach auf die NICs der beiden Knoten, oder wäre das eine Fehlkonfiguration?

[Necron 71]

Hi,

schau dir folgendes HowTo an. Das sollte deine Fragen beantworten. :)

-> http://www.hyper-v-server.de/management/aufbau-und-einrichtung-eines-failovercluster-unter-windows-server-2012/

[alexabexi 0]

Hallo

 

Ist es Absicht, dass in der Grafik Management-Netz und VM-Netz denselben IP-Bereich haben, aber darunter steht "

Management-Netz: Dieses Netzwerk ist für die Kommunikation des Cluster-Knoten mit der Domäne zuständig. Auf diesem Interface wird keine VM-Kommunikation betrieben, der Adapter steht exklusiv dem Knoten zur Verfügung. VM-Netz: Bei diesem Netzwerk ist es genau anders herum,"

 

Das verstehe ich nicht.?

 

Tschüß

[Confuse 0]

Hallo Necron,

 

vielen Dank für die schnelle Rückmeldung. Leider kenne ich den Artikel bereits und werde trotzdem nicht ganz schlau daraus.

Bei 2 Netzwerkkarten pro Clusterknoten arbeitet man ja laut dem Artikel mit 2 Subnetzen für ISCSI 1 und ISCSI 2 (192.168.212.0 und 192.168.213.0), was ja zur Folge hätte das ich dem QNAP auf seinen NICs auch ebenfalls eine Adresse aus jedem IP Adressbereich geben müsste. Allerdings ist auf dem QNAP "Port Trunking" aktiv bzw. steht es so in der Anleitung des Herstellers für die Nutzung von MPIO und in diesem Fall stellen ja beide NICs zusammen eine IP Adresse dar.

 

Eigentlich kann ich die Frage auch vereinfachen: Ist es möglich MPIO zu nutzen wenn ich pro Server nur eine Karte zur Verbindungsherstellung des SANs habe? Also quasi die Multipfad Verbindung auf 2 Server aufteile?

 

Gruß Confuse 

[Necron 71]

Port-Trunking auf der QNAP mit iSCSI ist von der Performance schlechter als wenn man bei beiden NICs unterschiedliche Subnetze nutzt und MPIO verwendet. Ich kann da bei meinem Lab aus Erfahrung sprechen.

 

MPIO kann man nicht auf zwei Server aufteilen. In gewissen Konfigurationen ist MPIO in einem Subnetz möglich, aber hier braucht man immer noch zwei NICs pro Server. Besser ist aber mit zwei unterschiedlichen Subnetzen.

[Confuse 0]

Hallo Necron,

 

Vielen Dank! Das ist die Information die ich gebraucht habe. Jetzt kann ich meine Planung anpassen, eigentlich hätte ich gerne 2 NICs für mein VM Netzwerk gehabt und diese Adapter dann im Team betrieben, aber da es sich zuerst um eine Testumgebung handelt, und ich leider von der Hardware auf 6 NICs pro Server angewiesen bin, muss vorerst eine NIC für das VM Netzwerk reichen. Ich meine gelesen zu haben dass eine 1:5 Regel gilt, das heißt ich kann ja 5 vNics per vSwitch an einen physikalischen Adapter koppeln, mehr VMs sollten es auch nicht werden.

 

Eine kleine Frage hätte ich aber noch :) : Wie sieht es mit der VLAN Konfiguration bei MPIO aus? Müssen die Switches Port Aggregation können um die beiden Karten als gemeinsame Verbindung (LAG) zu erkennen, oder muss für beide ISCSI Subnetze ein VLAN erstellt werden?

 

Gruß Confuse

Kurze Rückmeldung:

 

Ich lese immer wieder das Link Aggregation (LACP, 802.3ad bzw. LACP 802.1ax-2008), als dynamisches Teaming, also eigentlich nur im Zusammenhang mit NIC-Teaming eingesetzt wird. Außerdem wird im Hyper-V und Systemcenter Buch beschrieben, dass für die ISCSI Anbindung kein Teaming unterstützt wird bzw. diese mit MPIO stattfinden soll.

 

Richtet man für MPIO also grundsätzlich keine LAGs ein? Leider ist die Konfiguration von VLANs auf physischen Switchen nur sehr rudimentär beschrieben. Wahrscheinlich bin ich einfach noch zu grün hinter den Ohren um das zu verstehen :confused:

[Dunkelmann 96]

Moin,

 

wenn Du 6 NICs je Server hast, reicht es doch:

2x iSCSI per MPIO

2x Host OS, Cluster und Live Migration als Team

2x VM als Team

 

Wenn Du iSCSI MPIO mit zwei Subnetzen verwendest, solltest Du auch 2 VLANs dafür auf den Switches einrichten. iSCSI wird serverseitig grundsätzlich ohne Link Aggregation betrieben - dafür gibt es Multipathing.

Es gibt zwar auch Setups, die LACP-Teaming und Subinterfaces oder vNICs für iSCSI ermöglichen. Für Deine Umgebung dürfte das jedoch nicht relevant sein.

[Confuse 0]

Vielen Dank für die Infos!

 

Ich poste morgen mal was ich Netzwerkkonfigurationstechnisch vorhabe. Vielleicht könnt Ihr dann ja kurz eure Meinung dazu äußern.

 

Ich wollte mich so nah wie möglich an den Microsoft Best Practize Empfehlungen orientieren bzw. am Buch Hyper-V und System Center, da ich halt noch nicht sehr viel Erfahrung in dem Bereich habe. Deswegen wundert mich die Empfehlung das Management OS Cluster/CSV und Live Migration an ein Team zu koppeln, aber wie gesagt bin ich noch nicht sehr erfahren mit der Cluster Geschichte und freue mich immer wenn ich etwas dazulernen kann.

 

Morgen mehr...

 

Schönen Abend noch! 

[Dunkelmann 96]

Schau Dir mal den Blog von Keith Mayer an:

http://blogs.technet.com/b/keithmayer/archive/2013/04/01/build-your-private-cloud-in-a-month-new-article-series.aspx

 

Da wird im Abschnitt 'Networking' auch das Thema mit dem Host/Cluster/LM Team behandelt.

[IT-Shrek 13]

Hallo,

 

das ist immer eine Geschmacksfrage. Ich erstelle in dieser Situation ein großes Team für Host/Cluster/VM-Traffic und trenne logisch via QoS, aber wie schon gesagt wurde, hier gibt es kein richtig oder falsch.

 

Beste Grüße,

Shrek

[Confuse 0]

Guten Abend zusammen,

 

Ich habe jetzt für mein Projekt noch 2 Switches (Netgear GS724TS) zur Verfügung, was sich wohl positiv auf die VLAN Konfiguration auswirken dürfte, da diese im Gegensatz zu den Vorgängern stackable sind.

 

Zur Netzwerkkonfiguration habe ich mir jetzt folgendes überlegt:

 

2 NICs pro Node für ISCSI (Unterschiedliche IP Adressbereiche) für die Multipfad Anbindung an das QNAP über 2 VLANs

 

1 NIC für das Management OS

 

1 NIC für das VM Netzwerk

1 NIC für CSV und Heartbeat 

1 NIC für Live Migration

 

Ich hätte jetzt noch ein paar Fragen zu den virtuellen Switches auf den Servern. Nach meinem Verständnis benötige ich doch nur einen virtuellen Switch der an die NIC des VM Netzwerks gekoppelt wird (Gemeinsames Verwenden mit dem Hostsystem ist nicht gesetzt, mein Hostsystem soll ja keine Verbindung zu den VMs haben sondern eine IP Adresse aus dem Bereich der Domäne die die Cluster verwaltet), um den Uplink über die physikalische Netzwerkkarte in LAN herzustellen, oder muss ich noch weitere virtuelle Switches für die NICs erstellen?

 

Gruß Confuse

 

[Dukel 455]

Wozu gerade die Storage Redundant aufbauen und den Rest nicht?

Braucht es in der Testumgebung einen Redundanten Aufbau? Und wenn ja, wieso nicht alles wichtige Redundant, wie Dunkelman in #7 vorgeschlagen hat?

[Dunkelmann 96]

 

Ich hätte jetzt noch ein paar Fragen zu den virtuellen Switches auf den Servern. Nach meinem Verständnis benötige ich doch nur einen virtuellen Switch der an die NIC des VM Netzwerks gekoppelt wird (Gemeinsames Verwenden mit dem Hostsystem ist nicht gesetzt, mein Hostsystem soll ja keine Verbindung zu den VMs haben sondern eine IP Adresse aus dem Bereich der Domäne die die Cluster verwaltet), um den Uplink über die physikalische Netzwerkkarte in LAN herzustellen, oder muss ich noch weitere virtuelle Switches für die NICs erstellen?

Hallo,

 

so kannst Du es - erstmal - auch aufbauen. Bei dem Setup brauchst Du nur einen virtuellen Switch für die VMs, das Host OS ist ja direkt mit den anderen 5 NICs verbunden.

 

Wenn Du dann später mal Lust auf Teaming hast, versuch' es mal ohne Downtime von Host-Cluster oder VMs umzustellen :D  Es geht.

[Confuse 0]

@ Dukel: Es ist zwar im ersten Schritt eine Testumgebung, diese dient aber dazu, Erfahrungen zu sammeln um später auch produktive VMs darauf zu betreiben.

 

Meinst du mit der Redundanz der anderen Netzwerke, alle anderen NICs  als Team zu konfigurieren?

 

Wie gesagt habe ich noch keinerlei Erfahrungen mit dem Aufbau und orientiere mich am Hyper-V und System Center Buch, dort steht beschrieben dass man möglichst pro Netzwerk eine eigene NIC bzw. für das VM Netzwerk ein Team einsetzen sollte. Gerade die NIC für das Management OS wird angepriesen.

 

Habe ich keine Nachteile wenn ich zum Beispiel alle Cluster relevanten Netze (CSV, Heartbeat und Live Migration bzw. sogar noch das Management Netz) auf einen Adapter bzw. ein Adapter-Team konfiguriere?

 

Wie verhält sich das mit den virtuellen Switches bei dieser Konfiguration?

 

Gruß Confuse..

[Dunkelmann 96]

Moin,

 

wie Shrek oben schon geschrieben hat, vieles ist Geschmackssache oder hängt von konkreten Vorgaben für die Umgebung ab.

 

Es spricht absolut nichts dagegen, zum Üben und Kennenlernen einen simplen Cluster ohne Teaming und sonstige Extras aufzubauen. Das Gute an einer Testumgebung ist ja, dass Du Dein individuelles Tempo und Deine Präferenzen umsetzen kannst. Wenn es Dir dann nicht mehr gefällt, kannst Du es plattmachen und neu anfangen. In einer Produktivumgebung ist das etwas schwieriger.

 

Ohne Teaming hast Du keine Netzwerkredundanz. Der Switch oder die Netzwerkkarte wird zum Single Point of Failure; und genau das ist in einer hochverfügbaren Umgebung nicht gewünscht.

Natürlich hat Teaming auch Nachteile: Es muss richtig konfiguriert werden und verursacht etwas Overhead im Host OS. Mit vernünftiger Hardware und PowerShell ist das aber kein Problem :cool: