Storage: Hyper-V mit iSCSI auf Server 2012

[j.c.v. 10]

Hallo zusammen,

ich hoffe, mein Post ist hier richtig.

 

Es geht um ein Gedankenspiel zu einer (etwas) ausfallsicheren und komfortablen Hyper-V Lösung mit Windows Server 2012.

 

Kurze Beschreibung der Eckdaten:

In einer Testumgebung habe ich im Moment zwei W2K8R2-Server mit Hyper-V Rolle (hardware-unterschiedlich)

sowie eine NAS-Box (QNAP 419 II Plus, 4 Enterprise HDD als RAID10), auf der nur der iSCSI-Dienst mit zwei Targets läuft.

Auf jedem Target liegen die VMs für je einen Server.

Für die Verbindung zwischen den Servern und der NAS (bzw. eher SAN in dieser Einstellung) besteht ein eigenes VLAN, zusätzlich zum regulären LAN.

In diesem VLAN haben die Server jeweils eine Intel DualPort Server-NIC (1000TX), die NAS nutzt ihre beiden onboard NIC (ist also nur mit dem VLAN verbunden).

Die NAS "teamt" ihre beiden NICs zum Switch (LAG).

Jeder Server vebindet sich mit jeweils einem der iSCSI-Targets und nutzt dabei MCS im iSCSI-Initiator um über zwei Verbindungen zum Target (NIC1+2) die beste Leistung herauszuholen. 

(Performance ist also eine relevante Frage, daher auch iSCSI, eigenes VLAN und jeweils zwei NICs)

Failovercluster o.ä. ist NICHT konfiguriert.

Soweit zu den Eckdaten.

 

Problematisch an dieser Lösung sind zwei Dinge:

1.) Da ja nur ein Initiator exklusiv auf ein Target zugreifen kann, ist das iSCSI-Storage nicht für beide Server verfügbar.

Sprich: möchte man eine Maschine zwischen den beiden Hyper-V Hosts verschieben, muss man auf einem Server alle Maschinen beenden, das iSCSI trennen, auf dem anderen neu verbinden, die Maschine kopieren und den ganzen weg wieder zurück... Gleiches gilt bei Ausfall eine Maschine: iSCSI manuell umlegen, Maschinen einbinden uns starten, etc...

2.) Die Verwaltung ist nicht zentralisiert, schnelle Migration, etc. ist auch von daher nicht möglich

 

Mit dem Server 2012 wurde ja angekündigt, dass sich im Bereich Hyper-V und shared-Storage Einiges getan hat.

Ich muss zugeben, mich hier noch nicht 1000%ig eingearbeitet zu haben, erste Versuche mit StorageSpace und ClusterSharedVolumes waren aber leider nicht positiv, daher hier die Frage an die Community.

 

Ich plane also, diese Umgebung zu aktualisieren.

Hierfür stehen zunächst zwei neue, baugleiche Server mit Windows 2012 Standard und je drei NICs (1x LAN, 2x iSCSI-VLAN) bereit.

Falls benötigt, steht Systems Centre 2012 ebenfalls zur Verfügung.

Das iSCSI- Subsystem (NAS, VLAN, etc.) soll weiter genutzt werden.

 

Zielsetzung ist es, eine Hyper-V-Konfiguration umzusetzen, in der auf den beiden Servern mehrere VMs ausgeführt werden.

Die VMs sollen auf dem iSCSI-Target liegen und von beiden Servern zugriffsfähig sein.

Die VMs sollen zentral verwaltet und einfach von einem Server auf den anderen verschoben weren können (ja nach Ressourcenbedarf).

Ein automatisches Failover wäre gut, ist aber kein KO-Kriterium.

 

Meine Fragen sind daher:

- Hat hier jemand bereits Erfahrungen mit der Materie und kann mir sagen, ob dies überhaupt so möglich ist?

- Wenn ja - freue ich mich über jeden Hinweis der für die korrekte Einrichtung hilfreich ist (insbesondere auch zum System Centre)...

 

Abschließend noch ein Hinweis:

Die Server sollen nicht nur die Hyper-V Rolle ausführen.

Zusätzlich werden beide Server Domaincontroller sein (ich weiß - ist niocht empfohlen, wird in dieser Umgebung aber tolleriert).

Weiterhin wird noch ein Fileserver fürs LAN benötigt, dessen Daten aber auch auf dem iSCSI liegen sollen.

Wenn diese Freigaben ebenfalls ausfallsicher (gegen Ausfall eines Servers) wären, so wäre das ein nettes Addon.

 

Danke für eure Hilfe und schöne Grüße,

Jan

 

 

[Dukel 455]

Du benötigt für das ganze einen Failovercluster. Dann kannst du (wie auch bei den vorherigen Hyper-V / Windows Versionen) per Quick Migration oder (besser, aber bedingt noch ein CSV) per Life Migration.

 

Außerdem solltest du (wenn ich es richtig weiß) die iSCSI Verbindung nicht teamen sondern per MPIO Konfigurieren.

 

 

Weiterhin wird noch ein Fileserver fürs LAN benötigt, dessen Daten aber auch auf dem iSCSI liegen sollen.

Wenn diese Freigaben ebenfalls ausfallsicher (gegen Ausfall eines Servers) wären, so wäre das ein nettes Addon.

 

Dann lass doch das NAS die Fileserverfunktion übernehmen. Dann wäre diese funktion zwar auch betroffen, wenn das NAS ausfällt, aber bei einer Fileserver VM, das selbe.

 

Wieso willst du die DC's nicht als VM laufen lassen?

bearbeitet 7. März 2013 von Dukel

[j.c.v. 10]

Hallo Dukel,

wie konfiguriere ich denn in einem Failover-Cluster das iSCSI als shared Storage?
(bei meinen Tests war dies (mit einem iSCSI-Target) NICHT möglich)....

 

Die iSCSI-Verbindungen seitens der Server habe ich NICHT geteamt (s.o.) sondern per MCS eingerichtet.
MPIO bringt mir doch keinen Vorteil beim Zugriff EINES Servers auf ein Target (dafür ist doch MCS da) - oder?

 

Zum Fileserver:

Wie beschrieben ist das NAS/SAN NICHT (!) aus dem LAN erreichbar.

Die Freigabe muss daher durch einen Server oder durch einen ADS-zentralen Freigabepunkt erfolgen.

 

Zum DC:

Laut MS-WP muss zumindest ein DC physikalisch sein. Zumindest dies möchte ich (aus dem Bauchgefühl) so umsetzen....

 

Schöne Grüße,

Jan 

[NilsK 2.958]

Moin,

 

wie konfiguriere ich denn in einem Failover-Cluster das iSCSI als shared Storage?

 

indem du auf das Target zwei Initiatoren berechtigst (bzw. eben alle Clusterknoten).

 

(bei meinen Tests war dies (mit einem iSCSI-Target) NICHT möglich)....

 

Sollte aber gehen. Wenn dein SAN das nicht kann, ist es einfach ein zu simples SAN für einen "ausfallsicheren" Betrieb. Das iSCSI-Target von Windows 2012 kann sowas (natürlich).

 

MPIO bringt mir doch keinen Vorteil beim Zugriff EINES Servers auf ein Target (dafür ist doch MCS da) - oder?

 

In einem Cluster-Szenario wirst du aber nicht nur einen Weg zum Storage haben wollen, und dann brauchst du MPIO.

 

Allgemein gehen Ausfallsicherheit und Sparsamkeit nur sehr selten zusammen.

 

Gruß, Nils

[Necron 71]

Zum DC:

Laut MS-WP muss zumindest ein DC physikalisch sein. Zumindest dies möchte ich (aus dem Bauchgefühl) so umsetzen....

Hi,

 

Korrekt bei einem Hyper-V Failover Cluster mittels Windows Server 2008 R2. Unter Windows Server 2012 nicht mehr relevant.

 

Das QNAP kann iSCSI als Shared Storage bereitstellen! Nils hat es schon beschrieben, wie es geht.

 

Zum Thema wie man ein Failover Cluster einrichtet finden sich viele gute Artikel im Netz, z.B. unter www.hyper-v-server.de. Wenn du Windows Server 2012 einsetzen möchtest, dann dürfte für dich das Thema Converged Fabric interessant werden. ;)

[Dunkelmann 96]

wie konfiguriere ich denn in einem Failover-Cluster das iSCSI als shared Storage?

(bei meinen Tests war dies (mit einem iSCSI-Target) NICHT möglich)....

Bei vielen Storage Systemen müssen alle Initiotors in die ACL des Targets eingetragen werden und der gleichzeitige Zugriff mehrere Initiators muss zusätzlich explizit erlaubt werden.

 

Die iSCSI-Verbindungen seitens der Server habe ich NICHT geteamt (s.o.) sondern per MCS eingerichtet.

MPIO bringt mir doch keinen Vorteil beim Zugriff EINES Servers auf ein Target (dafür ist doch MCS da) - oder?

MPIO ist für einen Cluster erforderlich.

MPIO stellt redundante Pfade zum Speicher bereit. Das kann ein iSCSI oder FC Backend sein.

MCS ist nur eine Funktions des iSCSI Protokolls und somit nicht für alle Clusterszenarien anwendbar

 

Zum DC:

Laut MS-WP muss zumindest ein DC physikalisch sein. Zumindest dies möchte ich (aus dem Bauchgefühl) so umsetzen....

Ein pysischer DC ist bei einem WS 2012 Hyper-V Cluster nicht zwingend erforderlich.

Wie man es umsetzt, bleibt einem selbst überlassen. Die paar Euro für einen physischen DC sollte man aber überhaben, wenn man schon über Hyper-V Clustering nachdenkt.

bearbeitet 8. März 2013 von Dunkelmann

[NilsK 2.958]

Moin,

 

Korrekt bei einem Hyper-V Failover Cluster mittels Windows Server 2008 R2. Unter Windows Server 2012 nicht mehr relevant.

 

(zum Thema "ein DC muss physisch laufen)

 

das ist so etwas zu stark verkürzt. Daniels Aussage bezieht sich auf die Authentisierung der Clusterknoten gegen das AD. Dort ist nicht mehr zwingend ein separater DC nötig.

 

Die Empfehlung, einen DC pro Domäne physisch zu halten, hat aber noch weitere Hintergründe.

 

[faq-o-matic.net » Darf man einen Domänencontroller virtualisieren?]
http://www.faq-o-matic.net/2011/02/28/darf-man-einen-domnencontroller-virtualisieren/

 

 

Wenn du Windows Server 2012 einsetzen möchtest, dann dürfte für dich das Thema Converged Fabric interessant werden. ;)

 

Auch da möchte ich noch mal einhaken. Zum einen ist das, was für Hyper-V als "Converged Fabric" bezeichnet wird, etwas anderes als das, was in anderen Teilen der IT darunter verstanden wird (außerhalb von Hyper-V meint man damit meist den Parallelbetrieb von IP und FCoE auf demselben Ethernet). Zum anderen ist das Thema vor allem dann interessant, wenn man 10GE (10-Gigabit-Ethernet) im Netzwerk betreibt.

 

Gruß, Nils

[Necron 71]

Auch da möchte ich noch mal einhaken. Zum einen ist das, was für Hyper-V als "Converged Fabric" bezeichnet wird, etwas anderes als das, was in anderen Teilen der IT darunter verstanden wird (außerhalb von Hyper-V meint man damit meist den Parallelbetrieb von IP und FCoE auf demselben Ethernet). Zum anderen ist das Thema vor allem dann interessant, wenn man 10GE (10-Gigabit-Ethernet) im Netzwerk betreibt.

Völlig korrekt und danke für die Ergänzung! In einer Testumgebung mittels einer Dual 1 Gbit NIC macht es auch dort Sinn, um sich mit der Thematik vertraut zu machen. In produktiven Umgebungen, wie Nils schon sagte, erst mit 10 Gbit.

[j.c.v. 10]

Erst einmal vielen Dank für eure Antworten!

Ich werde mich bei hyper-v-server.de nochmal durchwühlen.

 

Ich vermute aber (@NECRON), meine QNAP (419er) unterstützt eben keine mehreren Initiatoren pro Target.

Zumindest steht bei QNAP in den allgemeinen iSCSI How-Tos: "Nicht mit mehreren Clients verbinden".

Ich habe mal aus Spaß ein Target von zwei PCs aus angesprochen, hat direkt zu Datenverlust geführt...

Wenn bei einem CSV die Nodes die Verbindung aufbauen ist das ja letzten Endes nichts anderes (?!)...

 

Schöne Grüße,

Jan 

[Dukel 455]

Es sollen ja nicht beiden Knoten die Targets gleichzeitig nutzen können sondern der Cluster Manager kümmert sich um das ganze.

Informiere dich wie man einen Windows Failover Cluster richtig installiert.

 

Wichtig ist, dass das NAS "SCSI-3 persistent reservations" unterstützt.

[j.c.v. 10]

Jupp - und genau das hat es nicht :-).

Ich habe mir jetzt für den Test eine 459 Pro Plus organisieren können (Intel Modell MIT SPC-3).

Dann wollen wir mal sehen :-)...

 

Nur´noch zur Sicherheit:

Die beiden Server sollen bei diesem Test (trotz allem) DCs werden.

Ich installiere die beiden Server also soweit fertig (als DC), auf der NAS ist ein Target bereit und leer.

Dann installiere ich die Hyper-V Rolle auf den Servern, dann den Failovercluster und richte dort das Target dann als CSV ein - korrekt?

 

Schöne Grüße,

Jan

bearbeitet 8. März 2013 von j.c.v.

[NeMiX 76]

http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/4ff14bec-a815-473b-8d2a-33e91e17197b/

 

Nur so als Anmerkung zum Thema die DCs als Hyper-V Host zu nehmen. Dort wird relativ klar davon abgeraten und ich würde das auch nicht umsetzen. Warum nimmst du nicht den kostenlosen 2012 Hyper-V und lässt die DCs dann auch als VM laufen?

[j.c.v. 10]

Ja, für Profuktionsumgebungen wird davon abgeraten, aus diversen Gründen solls in diesem Test trotzdem so sein...

Die in dem Link erwähnten Leistungsapsekte sind kein Thema, die Server sind schnell genug, RAM ist reichlich da und die Hyper-V Sachen liegen ja auf ganz anderen Laufwerken, kommen mit der Mini-ADS also nicht ins Gerangel.

Der eventuelle Sicherheritsapsekt bleibt natürlich, ist aber Stöhnen auf hohem Niveau (ich denke, jeder, der schonmal einen SBS produktiv genutzt hat, kommt nichtmal auf diese Gedanken :-) ) 

Alle DCs zu virtualisieren ist ja auch keine empfohlene Vorgehensweise (wie oben auch von NilsK nochmal erwähnt/verlinkt).

 

Da kein dritter physikalischer Server als reiner DC arbeiten soll, kann man jetzt entweder die ADS-Rolle mitlaufen lassen oder alle DCs virtualisieren.

Wie von beiden Seiten beschrieben ist beides keine Lehrbuch-Lösung, ich habe mich letzten Endes für die zusätzliche Rolle auf der Hardware entschieden :-) ....