Hyper-V im Multi-Site Cluster

[jochen35 10]

Hallo,

 

wir wollen unter Windows Server 2012 R2 einen Hyper-V Failovercluster aufbauen, der wegen der Redundanz zu gleichen Teilen auf zwei Standorte (40 GB/s Dark Fiber Backbone) aufgeteilt werden soll. Als zentraler Storage soll pro Standort ein NetApp E2724 per iSCSI-Anbindung zum Einsatz kommen (Dual-Active Failover) und pro Standort sind 8 Hyper-V Nodes vorgesehen. Vom beauftragten Systemhaus wurde uns empfohlen, einen zusätzlichen Hyper-V Node als "Quorum" an einem dritten Standort einzusetzen, um mögliches Split Brain zu verhindern.

 

Von Microsoft habe ich bisher noch keine derartige Empfehlung gefunden. Zudem bin ich bisher immer davon ausgegangen, dass das Quorum eine Fileressource auf dem zentralen Storage ist. Habt Ihr Erfahrungen mit Hyper-V im Multi-Site-Cluster, wie habt Ihr ihn implementiert?

 

Gruß

Jochen

[Dunkelmann 96]

Moin,

 

von MS wird in so einem Szenario ein File Share Witness an einem dritten Standort (Witness Site) empfohlen.

 

Quorum Best Practices:

+ Use Node & File Share Witness (FSW) Quorum especially for even number of Cluster Nodes.

+ Host FSW in 3^rd Site that has direct connection with both Cluster sites.

+ Avoid hosting FSW in a Cluster node or Virtual Machines in the same Cluster.

http://blogs.technet.com/b/meamcs/archive/2013/11/09/microsoft-windows-multi-site-failover-cluster-best-practices.aspx

 

http://blogs.msdn.com/b/clustering/archive/2011/05/27/10169261.aspx

 

Es ginge auch mit einer weiteren Hyper-V Node am dritten Standort. Letztlich ist die Anzahl der Stimmen entscheidend. Ob die entscheidende Stimme von einem Witness Share oder einer Cluster Node kommt spielt technisch zunächst keine Rolle. Der Aufwand für eine weitere Hyper-V Node ist allerdings deutlich höher, als der Aufwand für ein Witness Share.

 

Das Witness Share sollte nicht auf dem zentralen Storage liegen, sonst ist es kein unabhängiger Zeuge. Ob für das FSW ein kleiner File Cluster notwendig bzw. sinnvoll ist, könnte noch überlegt werden. Eventuell sollen einige VMs auch Clusterservices bereitstellen und ein FSW nutzen.

bearbeitet 18. Dezember 2014 von Dunkelmann

[Necron 71]

Hi,

 

ob man eine 3rd Site bei Dynamic Witness (mit Dynamic Voting), Tie breaker und force quorum resiliency noch braucht, bleibt jedem selber überlassen. Wenn keine 3rd Site zum Einsatz kommen soll, dann bitte vom Tie breaker gebrauch machen. Zumindestens in diesem Szenario, da die Anzahl der Node pro Site gleich ist.

 

-> http://technet.microsoft.com/en-us/library/dn265972.aspx#BKMK_Witness

-> http://technet.microsoft.com/en-us/library/dn265972.aspx#BKMK_TieBreak

-> http://technet.microsoft.com/en-us/library/dn265972.aspx#BKMK_FQ

 

Spätestens mit Windows Server vNext und der Cloud Witness dürfte sich das Thema dann erledigt haben. ;)

 

Eine Empfehlung noch bezüglich der Storageanbindung: Bitte kein iSCSI wenn möglich.

[v-rtc 81]

Wieso kein iSCSI?

[GuentherH 61]

Weil die Effizienz um 10 - 20% schlechter ist als eine FC Anbindung. Ist einfach protokollbedingt.

Zudem muss man sehr sorgfältig bei der Auswahl der Switche sein, da es ansonsten zu einer

weitere Verschlechterung der Effizienz und zu hohen Latenzzeiten kommt.

 

LG Günther

[v-rtc 81]

Danke Günther

[Doso 77]

Dafür ist es bei ordentlicher Wahl der Komponenten einen ganzes Stück günstiger und man muss sich nicht ganz so viel neues Wissen aneignen. Hat alles seine Vor und Nachteile.

[v-rtc 81]

Je nachdem was man hatte. Wir haben seit vielen Jahren FC.

[Doso 77]

Wir hatten schon ein kleines iSCSI SAN, keine Ahnung von FC und noch übrige Switches und Netzwerkkarten. Daher iSCSI.

[Necron 71]

Wieso kein iSCSI?

Bisher im produktiven Betrieb nur schlechte Erfahrungen damit gemacht und die Gründe die Günther genannt hat. Für kleine Testumgebungen halte ich iSCSI durchaus valide, aber solange ich keine produktive Umgebung gesehen habe, wo iSCSI wirklich sorgenlos läuft, bleibt es bei mir auf der Blacklist.

[zahni 521]

Netapp empfiehlt auch eher FCoE :

 

http://www.netapp.com/de/communities/tech-ontap/tot-fcoe-iscsi-0906-de.aspx

[DocData 85]

Ach Gott... iSCSI funktioniert nur in kleinen Umgebungen mit wenig IO. FCoE ist nett, aber auch eher nur eine Brückentechnologie. Es geht nichts über Fibre Channel.

[NilsK 2.785]

Moin,

 

ääääähhh ... dann werfe ich jetzt mal eine große Zahl völlig problemlos funktionierender iSCSI-Umgebungen in den Ring. Eine Zahl kann ich nicht nennen, aber bei weitem genug, um von einer ausgereiften Technik auszugehen und pauschale Vorbehalte als unbegründet zurückweisen zu können. Einige dieser Umgebungen haben schon mit der Technik angefangen, bevor iSCSI überhaupt standardisiert war. Wirklich ernsthafte Probleme gab es in keiner. Höchstens abgesehen von mangelnder Performance in einzelnen Fällen, wo man besser von vornherein auf FC gesetzt hätte - aber in Zeiten von 10 GbE ist das auch kaum noch ein Thema.

 

Probleme mit iSCSI gibt es dann, wenn man es nicht richtig macht - vor allem, wenn man die Netze nicht separiert. Solche Fehler tauchen mit FC schlicht nicht auf, weil man da dann eher Spezialisten ranlässt (und eine fehlende Trennung praktisch ausgeschlossen ist). Aber das ist dann genauso, wie wenn man die Fehler, die ein unbedarfter Windows-Admin macht, dem Betriebssystem anlasten würde mit dem Hinweis, unter Linux könne sowas nicht vorkommen.

 

Mangelnde Reife aufgrund mangelnder Marktdurchdringung sehe ich dann schon eher bei FCoE, das längst nicht so durchgestartet ist, wie die Hersteller das vor fünf, sechs Jahren vorhatten. Da ist es bei mir schon eher so, dass von den wenigen Kunden in meinem Bereich, die auf FCoE gesetzt haben, fast keiner glücklich damit ist. Hier liegt das aber auch weniger an der Technik selbst als an der Produktpolitik der Hersteller, die ganz offenkundig auch enttäuscht sind und die Produkte nur noch sehr stiefmütterlich behandeln.

 

Gruß, Nils

[DocData 85]

Nichts Anderes habe ich geschrieben. Ich habe viele iSCSI Umgebungen aufgebaut (viele mit HP P4000, NetApp oder DataCore SANmelody/ SANsymphony/ SANsymphony-V). Diverse sind über die Jahre soweit gewachsen, dass sinnlos war mit iSCSI weiterzumachen. Diese Kunden sind zum größten Teil auf FC gewechselt, wenige in Richtung NFS (alle mit NetApp). Dedizierte Switches und ordentliche Switches sind das Wichtigste. Deswegen ist der Schritt auf 10 GbE iSCSI auch oft nicht sinnvoll. Bei den Kosten kann man direkt in FC investieren und hat dann eine deutlich bessere Effizienz. Jumbo-Frames sind nice to have. Heute würde ich eher darauf verzichten.

 

Ab einer gewissen Größe kommt man einfach nicht um FC herum. Ich sitze derzeit bei einem Kunden mit einer mittleren, dreistelligen Anzahl Hosts und einigen tausend VMs. Mit iSCSI undenkbar. FCoE wird an einigen Stellen verwendet, aber der Vorteil einer konvergenten Infrastruktur lässt sich nur sehr schwer heben. Der Kunde setzt primär auf FC, teilweise auf NFS. Insbesondere NFS würde ich, ähnlich wie SMB3, den Vorzug gegenüber iSCSI geben.

[NilsK 2.785]

Moin,

 

dann sind wir uns ja einig. :)

 

Gruß, Nils