Anbindung eines ISCSI SANs an Hyper-V Cluster

[IT-Shrek 13]

Hallo Confuse,

 

wenn du ein großes Team über alle Netzwerkadapter bildest kannst du per Quality of Service am vSwitch sicher stellen, dass jedes Netz ausreichend Ressourcen erhält - zu jedem Zeitpunkt. In meinen Augen bietet dies die größte Flexibilität, daher ist es mein Favorit, allerdings eben auch die größte Komplexität.

 

Beste Grüße,

Shrek

[Confuse 0]

Hallo zusammen,

 

Ich bin gerade dabei meine Netzwerkkonfiguration zu dokumentieren und treffe dabei auf ein paar Ungereimtheiten:

 

1. Welche Protokolle ich an die NICs binde wird im Hyper-V und Systemcenter Buch gut beschrieben, bei einem Punkt bin ich mir allerdings nicht sicher: Für die Netzwerke CSV, Heartbeat und Live Migration wird angegeben dass diese eigentlich keine Protokolle außer die beiden IP Versionen benötigen. Allerdings steht dort dass die Netze in der Praxis meist eine gegenseiteige Redundanz bilden und dann die Protokolle "Micrsosoft Client" und "Datei- und Druckerfreigabe" auf allen Adaptern aktiviert sein sollte.

Im Beitrag von Carsten Rachfahl http://www.hyper-v-server.de/management/hyper-v-cluster-und-netzwerkkarten-bindungen/ habe ich allerdings eine Tabelle gefunden in der diese Protokolle nur bei Live Migration aktiviert sind. Wenn ich das Ganze richtig verstanden habe geht bei der Rudundanz um die Funktion der Live Migration.

 

2. Außerdem habe diesen Artikel http://www.hyper-v-server.de/management/netzwerkkonfiguration-im-hyper-v-cluster/ gelesen und verstehe nicht warum im Failoverclustermanager unter "Netzwerke" das VM Netzwerk nicht vorhanden ist. Kann mich da evtl. jemand aufklären?

 

Gruß Confuse

bearbeitet 31. Januar 2014 von Confuse

[Dunkelmann 96]

Hallo,

 

zu 1: Im Prinzip hast Du das richtig verstanden

LiveMigration braucht SMB und damit den MS Client und Datei und Druckerfreigabe. Damit es Redundanz für LM gibt, werden die Protokolle auch auf dem Cluster-Netz aktiviert. Ansonsten würde es durch das LAN gehen müssen und das ist i.d.R. unerwünscht.

 

zu 2:

Das VM-Netz hat für den Hostcluster keine relevante Funktion, da im Host OS keine Protokolle an dieses Netz gebunden sind.

[Confuse 0]

Ok! Vielen Dank für die Infos:

 

Inzwischen sind beide Nodes mit Hyper-V 2012R2 installiert, beide Quadport-Nics verbaut, alle Treiber installiert und alle Updates installiert.

 

Die Netzwerkkarten sind umbenannt, wie im Hyper-V und Systemcenter Buch beschrieben und alle Protokolle für die Netzwerkadapter wurden konfiguriert. Ich habe jetzt die Protokolle "Microsoft Client" und "Datei- und Druckerfreigabe" für die NICs LiveMigration, CSV und Cluster aktiviert, damit später eine Redundanz für die LiveMigration möglich ist. Das NIC-Teaming lasse ich vorerst weg, da ich denke dass es mit QoS Geschichten am Anfang zu komplex für mich wird.

 

Meine weitere Vorgehensweise ist jetzt:
1. Konfiguration der VLANs auf den Switches (Für jedes Netzwerk ein eigenes VLAN)
2. MPIO Feature auf den Hyper-V Hosts aktivieren
3. NICs auf dem QNAP konfigurieren (Jeder NIC eine Adresse aus einem eigenen IP Adressbereich)
4. RAID konfigurieren (6 Platten S-ATA und 2 SSD)
5. ISCSI Target und LUNs konfigurieren
6. ISCSI Targets mit den Initiatoren verbinden und MPIO konfigurieren

 

Jetzt habe ich wieder Fragezeichen im Kopf :confused:

Zu 1. Die VLAN Konfiguration sollte nicht das Problem sein.

 

Beim Einrichten von MPIO komme ich allerdings ins Schleudern. Im diesem Artikel http://www.hyper-v-server.de/management/aufbau-und-einrichtung-eines-failovercluster-unter-windows-server-2012/ sind ja 2 ISCSI Targets auf dem SAN eingerichtet, ist dies für MPIO zwingend notwendig? Wenn ja, müssen die Targets dann identische LUNs enthalten?

 

Wozu ich auch keine wirklich eindeutige Aussage im Netz finde ist wie viele LUNs im Target angelegt werden sollten. Eine für das Quorum ist klar, aber wie viele LUNs sind für CSV empfohlen? Je nach Anforderung? Also zum Beispiel: CSV\Volume1 (LUN1) für System Partition und Daten die hohe I/O Anforderungen  haben, und CSV\Volume2 (LUN2 bzw. 3 rechnet man das Quorum mit) für Daten die keine hohen I/O Anforderungen haben?

 

Quelle: http://www.mcseboard.de/topic/190933-was-geh%C3%B6rt-ins-cluster-shared-volume-wo-liegen-die-nutzdaten/

 

Was für ein Dschungel...

 

Gruß Confuse...

 

Kleiner Nachtrag:

 

Number an Size of LUNs and Volumes

 

When you plan the storage configuration for a failover cluster that uses CSV, consider the following recommendations:

• To decide how many LUNs to configure, consult your storage vendor. For example, your storage vendor may recommend that you configure each LUN with one partition and place one CSV volume on it.
   
• There are no limitations for the number of virtual machines that can be supported on a single CSV volume. However, you should consider the number of virtual machines that you plan to have in the cluster and the workload (I/O operations per second) for each virtual machine. Consider the following examples:
  • One organization is deploying virtual machines that will support a virtual desktop infrastructure (VDI), which is a relatively light workload. The cluster uses high-performance storage. The cluster administrator, after consulting with the storage vendor, decides to place a relatively large number of virtual machines per CSV volume.
     
  • Another organization is deploying a large number of virtual machines that will support a heavily used database application, which is a heavier workload. The cluster uses lower-performing storage. The cluster administrator, after consulting with the storage vendor, decides to place a relatively small number of virtual machines per CSV volume.
     
• When you plan the storage configuration for a particular virtual machine, consider the disk requirements of the service, application, or role that the virtual machine will support. Understanding these requirements helps you avoid disk contention that can result in poor performance. The storage configuration for the virtual machine should closely resemble the storage configuration that you would use for a physical server that is running the same service, application, or role. For more information, see Arrangement of LUNs, volumes, and VHD files earlier in this topic.
  
  You can also mitigate disk contention by having storage with a large number of independent physical hard disks. Choose your storage hardware accordingly, and consult with your vendor to optimize the performance of your storage.
   
• Depending on your cluster workloads and their need for I/O operations, you can consider configuring only a percentage of the virtual machines to access each LUN, while other virtual machines do not have connectivity and are instead dedicated to compute operations.

Dem entnehme ich dass Microsoft auf die Empfehlung des jeweiligen Storage Herstellers verweist, aber ein CSV (Also ein LUN) theoretisch keine Größenbeschränkung hat??

 

 

bearbeitet 31. Januar 2014 von Confuse

[Dunkelmann 96]

Moin,

 

wie die iSCSI Ziele aufgeteilt werden hängt grundsätzlich von Storage und Workload ab.

 

Ich tendiere dazu mehrer 'kleine' Ziele anstelle eines großen zu verwenden. Die 'kleineren' können dabei mehrere TB groß sein.

 

Zum Hintergrund:

Eine einzelne LUN/Volume ist wieder ein Single Point of Failure - genau das soll in einer HA Umgebung vermieden werden.

Ich habe mehr Steuerungsmöglichkeiten bei der Lastverteilung.

 

Es gibt eine theoretische Größenbeschränkung durch das Format der Partionstabelle und des Dateisystems. Wenn ich mich richtig erinnere liegt das NTFS Limit bei 256TB.

[Confuse 0]

Moin, Moin,

 

OK! Dann werde ich wohl mehrere LUNs erstellen. Was ich aber immer noch nicht recht verstanden habe, ist wie bei MPIO 2 Targets verwendet werden. Binde ich in jeden Knoten beide Targets ein? Normalerweise habe ich ja pro Target eine beliebige Anzahl von LUNs, oder ist es auch möglich dass die selben LUNs von mehreren Targets bereitgestellt werden?

 

Was würde passieren wenn ein Switch ausfällt? Dann ist die Verbindung zu einem Target ja definitiv getrennt, d.h. von der Logik könnte ich doch die LUNs unterhalb des Targets nicht mehr erreichen. Hoffe die Frage ist nicht zu doof, aber ich kann mir das nicht recht vorstellen...

[Dukel 436]

 

Was würde passieren wenn ein Switch ausfällt? Dann ist die Verbindung zu einem Target ja definitiv getrennt, d.h. von der Logik könnte ich doch die LUNs unterhalb des Targets nicht mehr erreichen. Hoffe die Frage ist nicht zu doof, aber ich kann mir das nicht recht vorstellen...

 

Wenn du alles Redundant auslegst hast du 2 Switche. D.h. Vom Server gehen 2 Leitungen zu beiden Switchen und dort 2 Leitungen zur Storage.

Wenn alles richtig konfiguriert ist kann sowohl an der Storage und am Server eine Netzwerkverbindung ausfallen, ein Switch kann ausfallen oder jeweils eine Leitung kann ausfallen.

[Dunkelmann 96]

Bei MPIO werden mehrere Pfade zu einem Target aufgebaut. Bricht ein Pfad weg, läuft die Kommunikation über die verbleibenden Pfade weiter.

 

Wie es genau zu konfigurieren ist, kann ich nicht sagen. Ich habe kein Qnap zur Hand

Das Qnap bietet vermutlich keine Integrationstools oder ein DSM an, also musst Du MPIO von Hand einrichten. Im Absatz 'Script Example ...' sollte alles relevante stehen

http://blogs.msdn.com/b/san/archive/2012/07/20/managing-mpio-with-windows-powershell-on-windows-server-2012.aspx

 

Wenn MPIO für iSCSI konfiguriert und aktiviert ist, sollte jeder Target nur noch ein mal auftauchen.

[Confuse 0]

Hallo zusammen,

 

Ich wollte heute anfangen meine VLANs zu konfigurieren und habe dabei festgestellt dass mir wieder viele Dinge nicht ganz klar werden.

 

Ich habe jetzt noch einen dritten Server der als Cluster Node eingesetzt werden soll.

 

Die NICs in den Servern sind alle konfiguriert, umbenannt und die Protokollbindungen konfiguriert:

NIC1 Management
NIC2 VM
NIC3 ISCSI1
NIC4 ISCSI2

NIC5 Cluster/CSV
NIC6 LiveMigration

 

Die beiden Netgear Switches sind jetzt als Stack konfiguriert.

Ich wollte jetzt die folgende Konfiguration vornehmen.

 

VLAN1 (ISCSI1) 4 Ports (QNAP NIC1 und jeweils ISCSI1 von den Nodes)

VLAN2 (ISCSI2) 4 Ports (QNAP NIC2 und jeweils ISCSI2 von den Nodes)
VLAN3 (Cluster/CSV) 3 Ports (1 für jeden Cluster Node)
VLAN4 (LiveMigration) 3 Ports (1 für jeden Cluster Node)
VLAN5 (Management) 5 Ports (1 für den DC auf dem auch der Failovercluster Manager laufen soll, 3 für die Nodes und 1 für Routing)

PVLAN (VM) Alle Restlichen Ports (Für die Anbindung von Clients an die virtuellen Maschinen)

 

Jetzt habe ich erst einmal folgende Frage: Ist es Notwendig den DC (Also den Failoverclustermanager) mit an die LiveMiagration und Cluster/CSV VLANs anzubinden, oder läuft die Kommunikation dieser Netze nur zwischen den Nodes und nur die Konfiguration erfolgt über das Management Netz?

 

Die zweite Frage: Bei ungleicher Anzahl an Nodes und 2 Switches, kann ich die VLANs zwar über die 2 Switches verteilen, habe dann aber immer einen Switch auf dem nur ein Node gesteckt ist. Was ist wenn der Switch ausfällt, an dem 2 der Nodes hängen?

ISCSI ist per MPIO angebunden, heißt ich hätte immer noch von allen Nodes Kontakt zum SAN, aber was ist mit der Kommunikation der Cluster Nodes untereinander? Bei Ausfall des Switches auf dem 2 NICs der Cluster Nodes stecken, wäre die Kommunikation zwischen den Clustern ja komplett getrennt? Kann man das irgendwie intelligenter lösen?

 

Was würde das Resultat davon sein? Ein Failover der Maschinen kann ja so nicht mehr stattfinden, würden also nur die Maschinen noch erreichbar sein die auf dem Knoten hängen der am noch funktionierenden Switch hängt?

 

ich hoffe ich habe das einigermaßen verständlich beschrieben.

 

Gruß Confuse..

[Dunkelmann 96]

Moin,
 

 Jetzt habe ich erst einmal folgende Frage: Ist es Notwendig den DC (Also den Failoverclustermanager) mit an die LiveMiagration und Cluster/CSV VLANs anzubinden, oder läuft die Kommunikation dieser Netze nur zwischen den Nodes und nur die Konfiguration erfolgt über das Management Netz?

 Live Migration und Cluster/CSV werden nur von den Cluster Nodes benötigt. Andere Systeme sollen keinen Zugriff auf die Netze bekommen.
 

 Die zweite Frage: Bei ungleicher Anzahl an Nodes und 2 Switches, kann ich die VLANs zwar über die 2 Switches verteilen, habe dann aber immer einen Switch auf dem nur ein Node gesteckt ist. Was ist wenn der Switch ausfällt, an dem 2 der Nodes hängen?
ISCSI ist per MPIO angebunden, heißt ich hätte immer noch von allen Nodes Kontakt zum SAN, aber was ist mit der Kommunikation der Cluster Nodes untereinander? Bei Ausfall des Switches auf dem 2 NICs der Cluster Nodes stecken, wäre die Kommunikation zwischen den Clustern ja komplett getrennt? Kann man das irgendwie intelligenter lösen?
 
Was würde das Resultat davon sein? Ein Failover der Maschinen kann ja so nicht mehr stattfinden, würden also nur die Maschinen noch erreichbar sein die auf dem Knoten hängen der am noch funktionierenden Switch hängt?

Da Du auf's Teaming verzichtet hast, wird der Switch zum Single Point of Failure.

 

Im iSCSI hast Du zwar Redundanz durch MPIO, das nützt jedoch nichts, wenn die LAN Konnektivität getrennt wird.

Ob der Cluster überhaupt noch lebensfähig ist, hängt davon welche Node gerade welche Ressourcen hält. Wenn Du Pech hast, geht der komplette Cluster beim Ausfall eines Switches down.

[Confuse 0]

Vielen Dank für die Info.

 

Ich werde mit das Konzept noch einmal überlegen, so gefällt mir das nicht.

 

 
 

[Confuse 0]

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.

 

Moin Dunkelmann,

 

Du hattest anfangs diese Kombination empfohlen. Ich denke dass diese Kombi aus Redundanzgründen sinnvoller ist, da ich ungerne von Anfang an SPoFs einbauen möchte.

 

Eigentlich ist es auch sehr einleuchtend, dass ich mit einer NIC im Server unmöglich Redundanz für 2 Switches schaffen kann.

 

Wie würde man dabei die VLAN Konfiguration vornehmen? Ein VLAN pro NIC-Team (Außer bei ISCSI hier soll es ja pro Subnetz ein VLAN sein, und es ist ja auch kein Teaming)?

 

Würde das auch bedeuten dass man Host OS, Cluster und Live Migration im gleichen IP Adressbereich hat?

 

Gruß Confuse..

[Dunkelmann 96]

Moin,

 

iSCSI sollte soweit geklärt sein, ein VLAN je Subnetz/Pfad.

 

Bei den Cluster und VM Netzwerken habe ich mich an diesem Artikeln orientiert:

http://blogs.technet.com/b/keithmayer/archive/2013/04/04/build-a-private-cloud-foundation-networking.aspx

http://technet.microsoft.com/en-us/library/hh831738.aspx

Da ich iSCSI über dedizierte NICs verwende, habe ich kein Sub- /Teaminterface für's Storage konfiguriert.

Als Team Modus verwende ich LACP.

 

Auf dem DataCenter-Team habe ich 3 VLANs; jedes VLAN entspricht dabei einem Subnetz

- ein native VLAN für das Host OS (Domänen-Netz, routed)

- ein taged VLAN für Cluster (isoliertes Subnetz)

- ein taged VLAN für Live Migration (isoliertes Subnetz)

Zur Steuerung der Bandbreiten nutze ich QoS

 

Für das VM-/Tenant-Team nutze ich einen Trunk ohne native VLAN

Bevor jemand fragt, warum kein native VLAN für VMs? -> 'VLAN hopping' und 'tagging the native VLAN' sind die Suchbegriffe ;)