Hyper-V SAN Replizierung / KEIN Hyper-V Replica

[StefanWe 14]

Hallo,

 

ich habe mir gerade StarWind Native SAN für Hyper-V angesehen. Ich finds allerdings etwas teuer.

 

Kennt ihr alternativen die erheblich günstiger sind? Mir wurde jetzt nen Preis für 4 TB von ca. 4000 Euro genannt.

 

Ich möchte den lokalen Storage von 2 Hyper-V Hosts synchron replizieren und als iSCSI Shared Storage den Nodes zur Verfügung zu stellen. Auf dem Hyper-V Cluster werden anschließend ca. 10 VM's laufen. 

 

VMware bietet hier ja sein Essentials Plus Paket inkl. der Storage Appliance für ca. 3000 Euro an. Daher suche ich eben für Hyper-V eine entsprechende Alternative.

 

Hyper-V Replica reicht mir nicht.

[Necron 71]

Hi,

 

Mir ist derzeit nur das Starwind Native SAN for Hyper-V bekannt, welches solch eine Funktionalität bietet. Wobei ich bei einem Hyper-V Failover Cluster zu einem richtigen Shared Storage (iSCSI SAN, FC SAN oder SMB 3.0 Scale-Out File Server) greifen würde.

[Dukel 439]

Repliziert der SMB 3.0 Scale-Out-Fileserver auch Daten?

Evtl. gibts von Datacore ne Lösung. Da weiß ich aber auch nicht wie teuer die sind.

[StefanWe 14]

Ok, DataCore haben wir hier auch. Aber auch da sind wir Preislich leider in Bereichen wo es sich nicht lohnt.

Grundsätzlich bin ich auch immer ein Fan von Shared Storage. Doch müsste dieses dann auch redundant ausgelegt werden und da sind wir in Bereichen die sich bei der kleinen Umgebung nicht lohnt.

Ja ich weiß, Hochverfügbarkeit kostet nunmal :)

 

Alternativ wäre sicherlich noch LeftHand interessant, wobei ich nicht weiß obs eine Hyper-V Appliance gibt. Aber nichtsdesto trotz bist du mit dem VMWare Essentials Plus Paket erheblich günstiger.

[Dukel 439]

Je nach Applikationen (AD; Exchange; SQL) kann man auch Applikationen beibringen zu replizieren. Dann benötigt man keine Shared bzw. wenigstens keine Replizierte Storge.

[Necron 71]

Repliziert der SMB 3.0 Scale-Out-Fileserver auch Daten?

Evtl. gibts von Datacore ne Lösung. Da weiß ich aber auch nicht wie teuer die sind.

Wenn an dem Scale-Out File Server zwei SAS JBODs angeschlossen sind und darüber dann ein Storage Pool mit Mirrored Disks gefahren wird, hätte man zwar nicht eine Replizierung, aber die Daten lägen auf beiden SAS JBODs.

Doch müsste dieses dann auch redundant ausgelegt werden und da sind wir in Bereichen die sich bei der kleinen Umgebung nicht lohnt.

Lohnt sich denn bei kleinen Umgebungen überhaupt ein redundanten Storage? Brauchen kleine Umgebungen eine solche Hochverfügbarkeit? Hier würde ich entweder auf einen Hyper-V Failover Cluster ohne redundanten Storage setzen oder zwei Hyper-V Standalone Hosts mit Hyper-V Replica, wenn das Budget für einen redundanten Storage nicht ausreicht.

[StefanWe 14]

Wie ist es denn mit der Replizierung mit dem Storage Pool? Wie kommen die Daten vom FileServer1 auf FileServer2 ? Habt ihr dort schon Erfahrung gesammelt ? ist das überhaupt für Hyper-V Supported?

Aktuell kenn ich die Scale Out Services nur in Verbindung mit CSV Datenträgern welche im SAN liegen.

bearbeitet 13. Juni 2013 von StefanWe

[Necron 71]

Wie ist es denn mit der Replizierung mit dem Storage Pool? Wie kommen die Daten vom FileServer1 auf FileServer2 ? Habt ihr dort schon Erfahrung gesammelt ? ist das überhaupt für Hyper-V Supported?

Aktuell kenn ich die Scale Out Services nur in Verbindung mit CSV Datenträgern welche im SAN liegen.

Scale-Out File Server funktionieren auch mit SAS JBODs, die jeweils an die File Server per SAS angeschlossen sind. Mittels der File Server wird ein Failover Cluster gebildet und per Storage Pools und Mirrored Disks gewährleistet, dass die Daten auf beiden SAS JBODs liegen. Die Mirrored Disks, nichts anderes als eine virtuelle Festplatte, werden dann als CSV im Cluster eingebunden. Das kurz und knapp dazu sowie Hyper-V supported.

[Dukel 439]

Geht das dann aber nicht nur, wenn man nur 2 Disks (je eine Disk pro Storage) in einen Pool legt?

Dann fehlt einem aber der Vorteil des dynamischen Wachsen mit einfachem hinzufügen von Disks.

Außer man erweitert die Storage und diese gibt nur eine Disk an den Server weiter.

[StefanWe 14]

 Die Mirrored Disks, nichts anderes als eine virtuelle Festplatte, werden dann als CSV im Cluster eingebunden. 

 

Und wie kommen die Daten vom FileServer 1 auf den Fileserver2 welcher im zweiten Brandabschnitt stehen? Welche Technik kümmert sich um die Replizierung?

[Necron 71]

Und wie kommen die Daten vom FileServer 1 auf den Fileserver2 welcher im zweiten Brandabschnitt stehen? Welche Technik kümmert sich um die Replizierung?

Habe ich doch oben beschrieben!?

Geht das dann aber nicht nur, wenn man nur 2 Disks (je eine Disk pro Storage) in einen Pool legt?

Dann fehlt einem aber der Vorteil des dynamischen Wachsen mit einfachem hinzufügen von Disks.

Außer man erweitert die Storage und diese gibt nur eine Disk an den Server weiter.

Ich habe es in der Kombination leider noch nicht im Betrieb gesehen. Nach der Logik, die dahinter steckt, sollten dann aber immer die gleiche Anzahl von Disks aus beiden JBODs dem Storage Pool zugeordnet sein, damit es funktioniert

[StefanWe 14]

Habe ich doch oben beschrieben!?

 

 

Mh daraus werde ich nicht schlau. Du schreibst, das man keine Replizierung hat, die Daten aber auf beiden JBOD's liegen.

Oder habe ich es so zu verstehen, dass ich das IO auf eine "virtuelle Disk" geschrieben wird und dieses IO dann physikalisch auf beide jeweils lokal angeschlossenen SAS JBOD's gleichzeitig geschrieben werden? Was ja dann quasi ein Synchroner Spiegel ist?

[Necron 71]

Oder habe ich es so zu verstehen, dass ich das IO auf eine "virtuelle Disk" geschrieben wird und dieses IO dann physikalisch auf beide jeweils lokal angeschlossenen SAS JBOD's gleichzeitig geschrieben werden? Was ja dann quasi ein Synchroner Spiegel ist?

Genau! Das ist eines der Prinzipien welches hinter den Storage Pools und Storage Spaces steckt. Wie aber oben schon geschrieben, habe ich eine derartige Konfiguration noch nicht im Betrieb gesehen, um die Funktionalität zu 100% bestätigen zu können. Alleine anhand der Logik, die dahinter steckt, sollte es aber möglich sein.

[Dukel 439]

Angenommen du hast 4 Disks in einem Storage Pool. Die Daten werden in kleine Teile aufgeteilt und dann auf Disks in einem Pool verteilt bzw. gespielt. Bei 2-Way Mirror auf 2 Disks, bei 3-Way Mirror auf 3 Disks.

Da kann es sein, dass ein Block auf Disk 1 und 2 liegt oder aber auf Disk 1 und 3 oder auf 3 und 4,...

Da das nicht beeinflussbar ist kann es sein, dass Daten auf 2 Disks von einer Storage liegen und keine Kopie auf der anderen Storage.

[StefanWe 14]

Genau! Das ist eines der Prinzipien welches hinter den Storage Pools und Storage Spaces steckt. Wie aber oben schon geschrieben, habe ich eine derartige Konfiguration noch nicht im Betrieb gesehen, um die Funktionalität zu 100% bestätigen zu können. Alleine anhand der Logik, die dahinter steckt, sollte es aber möglich sein.

 

Mh so hab ich das bis jetzt gar nicht gesehen in der Feature Matrix. Aber wenn das so wäre, wäre das ja ein ziemlich geiles Feature. Womit ich mein Storage in in zwei Brand Abschnitten synchron hätte. Würde ein Abschnitt ausfällen, wird eben die virtuelle Festplatte nur von einer Seite aus "versorgt". Da ja auch die iSCSI Rolle nun Clusterfähig ist, könnte man damit auch ein iSCSI Target bereitstellen. 

 

Das würde ja dann auch bedeuten, dass ich keine 2 Shared Storage Systeme benötige, wo allein die synchrone Replizierungs Lizenz ein haufen Kohle kostet. Sondern es lässt sich alles mit Boardmitteln verarbeiten.

 

 

Angenommen du hast 4 Disks in einem Storage Pool. Die Daten werden in kleine Teile aufgeteilt und dann auf Disks in einem Pool verteilt bzw. gespielt. Bei 2-Way Mirror auf 2 Disks, bei 3-Way Mirror auf 3 Disks.

Da kann es sein, dass ein Block auf Disk 1 und 2 liegt oder aber auf Disk 1 und 3 oder auf 3 und 4,...

Da das nicht beeinflussbar ist kann es sein, dass Daten auf 2 Disks von einer Storage liegen und keine Kopie auf der anderen Storage.

 

Das wäre dann aber nicht wirklich ein synchroner Spiegel so wie es necron schreibt.