Hyper-V Cluster mit SMB 3.0 File-Cluster

[zauggs 0]

hallo zusammen

 

Ist es möglich, einen ortsgetrennten hyper-V Cluster zu bauen, der die virtuellen Maschinen auf einem File-Cluster via SMB 3.0 speichert auf Basis Server 2012?

Das Ziel: Ein vollständig ausfallsicheres System, das auf zwei Standorten aufgeteilt wird ohne separates synchronisiertes teuers Hardware-SAN.

Wahrscheinlich brauche ich dazu 4 Hardware-Server? Je zwei Server pro Standort für die Rollen File-Cluster und Hyper-V Cluster?

Ist das möglich? Die Netzwerke wären natürlich auch redundant ausgelegt und verbunden.

Schlussendlich muss eine virtuelle Maschine hochverfügbar laufen, auch wenn ein IT Raum unerreichbar wäre, da diese eine grose 24/7 Stunden Produktionsanlage steuert.

 

Vielen Dank für Feedbacks.

 

[NeMiX 76]

Wenn deine Anforderung 24/7 ist, warum dann nicht bei den großen SAN Herstellern anfragen. NetApp und EMC z.b. können dir da tolle Sachen anbieten, auch HP kann das mit LeftHand oder EVA Storage.

[Necron 71]

Hi,

 

ganz kurz. Ohne SAN Replizierung wird dein Vorhaben so wie du es dir vorstellst nicht machbar sein. Aber definiere bitte deine Anforderungen dann können wir besser eine Empfehlung/Vorschlag abgeben.

[zauggs 0]

Hallo

Das geht ja super schnell!

 

Die Anforderung wäre eine virtuelle Instanz so hochverfügbar zu machen, dass sie im Ausfall des einen Hyper-V automatisch weiter läuft auf dem anderen Hyper-V Server.

Ein repliziertes SAN ist mir klar, dass dies die Wahl bis anhin war, aber neu soll ja ein Hyper-V Server 2012 auch auf einen SMB 3.0 Share die VHD Files ablegen können und dieses SMB 3.0 Share wiederum sollte ja mit einem 2012 Filecluster angeboten werden können. Dies wäre doch ein toller kostengünstiger Ersatz für ein teures NetApp usw.

Da aber die Rolle des Hyper-V Clusters und des File Clusters gemäss MS nicht auf demselben Server laufen kann, müsste man ja sicher mindestens 4 Server haben (2 pro Standort).

Die Frage wäre hier jetzt noch, ob die Filecluster zum hosten der VHD-Files der Ziel-Instanz auch als virtuelle Server auf dem Hyper-V laufen könnte.

Die Zielinstanz dürfte dann aber erst gestartet werden, wenn die virtuellen Filecluster oben sind, damit die VHD des Zielsystems zur Verfügung steht.

 

Was denkt ihr?

[Necron 71]

Hier hast du aber auch das Problem, dass du den Storage hochverfügbar machen musst. Ansonsten wird das mit dem Failover zwischen den Hyper-V Hosts nicht möglich sein. Denn wenn dir die eine Seite wegbricht, dann hast du auch keinen Zugriff mehr auf die VMs dort, wenn der Storage nicht hochverfügbar ist und zur anderen Seite gespiegelt wird.

 

Von dem Konstrukt mit virtuellen File Server Cluster für die VMs rate ich absolut ab. Das ist maximal für eine Demoumgebung etwas, um sich mit der Materie vertraut zu machen. Für den produktiven Betrieb ist das ein absolutes No Go.

 

Hochverfügbarkeit kostet Geld. Wenn man es günstiger haben möchte, muss man Abstriche machen.

[zauggs 0]

OK, hatte auch die Befürchtung, aber wenn man den Storage hochverfügbar machen könnte (halt auch unter Einsatz eines zweiten pysikalischen Servers pro Standort mit Hyper-V Filecluster) könnte man ja wirklich gewaltig Kosten sparen.

[Necron 71]

Wie willst du die Spiegelung zwischen den physischen Servern realisieren, die den File Server Cluster bilden? Was für Storage sollen diese nutzen? DAS, SAS, iSCSI, etc.?

[zauggs 0]

Alles klar, ich dachte es sei native mit Windows nun möglich, aber werde indem Fall Starwinds iSCSI SAN verwenden.

 

Vielen Dank nochmals.

[Weingeist 159]

Je nach Definiton von finanziell vernünftig, gibts da verschiedenen Varianten und einige auch günstiger als mit gespiegelten SAN's machbar. Ein Klassiker sind zbsp. Zugangssystem-Anbieter, die sind dauernd mit solchen 'Spässen' konfrontiert.

 

Je nach Aufgabe, benötigtem Speicherplatz, Rechenleistung etc. würden evtl. zwei synchron laufende Maschinen bereits ausreichen. Wenn Ein Ausfall der Maschine und Neustart ausreichen würde, wäre evtl. auch ein Replikatlösung möglich. HyperV kann das oder DoubleTake

 

Varianten:

- Xen und der Marathon-Erweiterung für MultiCPU-VM's im Lockstep (braucht nur zwei Standardserver mit eigenem lokalen Storage, sehr clever gemacht, Primäre Maschine wird nur im Totalausfall gewechselt), einigermassen preiswert

- Physisches Lockstep mit Stratus-Server, Nachteil: Beide Maschinen selber Standort bzw. ein Gehäuse, theoretisch HyperVisor direkt installierbar, ziemlich teuer

- VmWare mit FaultTolerance, Beschränkung auf eine vCPU sowie einem gespiegelten Storage mit transparentem Failover (Datacore,  HP LeftHand usw.), sehr teuer