DRS-Cluster Server/Speicher unterschiedliche Standorte

[mathschut]

Hi,

hat jemand schon was mit DRS für Server und Speicher an unterschiedlichen Standorten gemacht? Wir haben einen neuen Stretch Metro Cluster von Netapp der seine Daten 1zu1 spiegelt. Auf beiden Seiten haben wir ESXi Server stehen. Ich habe mir jetzt überlegt, einen großen Server DRS Cluster über beide Standorte zu bauen. Im Notfall, soll Vmware HA die VM`s am anderen Standort wieder hochfahren. Kann ich einstellen, dass wen VM`s sich auf einem Host an Standort A befinden, sie ihre Daten auch von Netapp von Standort A holen? Ich wollte dann auch einen Speicher DRS-Pool über beide Netapp-Knoten bauen. Sie werden ja eh...1zu1 gespiegelt.

Mfg

[bla!zilla]

Wie groß ist die Entfernung zwischen den Sites und was für eine Verbindung habt ihr dazwischen?

[mathschut]

Hi,

die Entfernung ist 250m. Als Netzwerk haben wir Cisco 7000 und 5596 Switche mit 40Gb. Als FC haben wir Brocade Switche mit 2 ISL`s mit je 16GB je Fabric. Die Netapp wird mit NFS vom ESXi Host angesprochen. Jeder Netapp Kopf ist mit 40GB angeschlossen. Die ESXi Hosts mit je 20Gb.

[irix]

NetApp Metro Cluster ist eine der wenigen von VMware zertfizierten Loesungen fuer einen Streched Cluster. VMware hat dafuer den Term vMSC. Gibt zu vMSC+Netapp einen nettten KB sowie eine gute VMware Session von der VMworld 2013 vom Duncan Epping und einem anderen netten Menschen (Name vergessen hab)

Um einen "LocalRead" zu realisieren kannst du im DRS die Host und VM Gruppen verwenden und dann eine Host "Should" Regel definieren.

Gruss
Joerg

[mathschut]

Danke schon mal für deine Antworten. Kannst du mir das ein bisschen genauer erklären:

>Um einen "LocalRead" zu realisieren kannst du im DRS die Host und VM Gruppen verwenden und dann eine Host "Should" Regel definieren. <

Wie kann ich in einem Storage DRS Cluster einstellen oder in Host DRS Clustern, dass sich VM`s auf bestimmen Hosts auch ihre Daten auf einem bestimmten Storage ablegen?

[bla!zilla]

Irix war mal wieder schneller... Es ist exakt so wie von ihm beschrieben.

Du musst Host-DRS Gruppen und Regeln nutzen, damit VMs nicht auf den ESXi Hosts ausgeführt werden, die auf der "entfernten" Seite stehen. Wenn VM_A in Datastore_A liegt, und Datastore_A aktiv von dem Filer in Standort_A betrieben wird, dann wäre es doof, wenn die VM_A auf Host_B in Standort_B läuft. Mittels streched Fabric wird das laufen, aber der Verkehr müsste immer über den ISL.

[mathschut]

Das müsste ich dann immer händisch bei jeder VM machen oder?
Also VM auf Host A legen und auf Speicher A speichern. Danach in DRS Gruppe A speichern oder? Wie sieht es aus, wenn ich einen Datastore Cluster aus beiden Netapp-Köpfen bauen würde. Macht das überhaupt Sinn?

Danke Jungs

[bla!zilla]

Nein, du baust VM Gruppen und Host Gruppen im DRS und sagst dann, welche VM Gruppe auf welcher Host Gruppe laufen soll.

[mathschut]

Aber auf welchen Speicher sie sich befinden sollen, muss ich manuell zuweisen oder? Wie sieht es mit DRS Speicher-Cluster aus?

[bla!zilla]

SDRS wäre in dem Konstrukt in der Tat sehr hinderlich. Zum einen würden deine VM Gruppen zwar unverändert bleiben, aber die VM würde in einem anderen Datastore landen. Dann müsstest du per Hand die Gruppe anpassen. Zweites Problem: Thin Provisioning und SDRS muss man verstehen. Das Verschieben von VMs hat durchaus Auswirkung auf den Füllstand von Volumes/ Aggregaten.

[irix]

@Mathias,

wir meinen nicht "Storage Cluster" sondern nur das normale DRS.

Du bist nun einen Schritt weiter bzw. faengst an der falschen Stelle an. Ich wuerde 2 getrennte Storage Cluster machen aber der Einsatz dieser sind keine Pflicht bzw. ja auch nur fuer Enterprise Plus Kunden einsetzbar.

Gruss
Joerg

[mathschut]

Hi,

ok. Also einen Server-Cluster über 2 Standorte bauen und dann 2 DRS Gruppen für Hosts an Standort A und Standort B. danach dann immer die VM`s den Gruppen zuordnen, an welchen Standort sie sich befinden.

[stahly]

Wir setzen zwar den IBM SVC ein, aber ebenfalls ein Stretched Cluster. Entfernung ca. 5 km. Beide RZs sind aktiv.

RZ1: SVC - XIV / V7000
RZ2: SVC - XIV / V7000

Die Switche (FC und Ethernet) sind per Dark-Fibre angeschlossen.

Sowohl DRS als auch sDRS sind im Einsatz und es funktioniert super. sDRS ist eigentlich nur für den Füllgrad der LUNs zuständig (manueller Modus). Die eingestellten 10ms Latenz werden fast nie erreicht.

Bei uns ist im SVC eingestellt, dass die VMs sich die Daten vom nächstgelegen Storage abholen und nicht über die "lange Leitung" holen.

HIlft Dir jetzt nicht wirklich für Dein Netapp-Konstrukt weiter, aber die Situation ist zumindest ähnlich

[stahly]

...
Also einen Server-Cluster über 2 Standorte bauen und dann 2 DRS Gruppen für Hosts an Standort A und Standort B. danach dann immer die VM`s den Gruppen zuordnen, an welchen Standort sie sich befinden.

Dann nutzt man aber die gesamte Server-Hardware nicht optimal bzw. man muss Hand anlegen. Wenn die Hosts an Standort A viel zu tun haben und an Standort B wenig, gleicht DRS nicht aus...

[kastlr]

Hallo zusammen,

ich kenne die NetApp Lösung nicht.
Entscheidend ist, das die verwendete NMP Policy sauber aufgesetzt ist und wie das Array bei Writes die Konsistenz beider Seiten gewährleistet.
Wenn IO's mehrfach über den ISL geschaufelt werden müssen, sollten die natürlich ausreichend dimensioniert sein.

Ansonsten spricht bei dieser geringen Distanz nicht wirklich viel gegen einen DRS Cluster ohne die angesprochenen Regeln.

@stahly,
meiner persönlichen Meinung nach sollte eine Firma, die so eine Lösung betreibt, ohnehin ausreichend Resourcen einplanen.
Sonst kann ich mir diesen Ansatz eigentlich gleich sparen.

Gruß,
Ralf

[stahly]

...
@stahly,
meiner persönlichen Meinung nach sollte eine Firma, die so eine Lösung betreibt, ohnehin ausreichend Resourcen einplanen.
Sonst kann ich mir diesen Ansatz eigentlich gleich sparen.
...

[bla!zilla]

Ansonsten spricht bei dieser geringen Distanz nicht wirklich viel gegen einen DRS Cluster ohne die angesprochenen Regeln.

Sehe ich ähnlich. Der Vollständigkeithalber weise ich aber immer darauf hin. In der Realität wird i.d.R. auf DRS Regel verzichetet wenn die ISL dick genug sind und die Leitung ein paar Hundert Meter nicht überschreitet.

[PeterDA]

Hi,
ich werf hier mal was ein! Bei einer NetApp ist ein NFS Export immer nur über einen Kopf erreichbar. Nämlich den Kopf dem die Platten gehören. bei einem Metro Cluster Gehören Kopf A Ein Teil der Platten an Stack im 1. RZ und einen Teil der der Platten am Stack im 2. RZ. Die Platten bilden eine RAID 1. Beim Ausfall von 1. RZ, schwenkt der Kopf auf den Kopf im 2. RZ und hat dort auch alle Daten.

Daraus folgt, dass du im Normalfall zwei DRS Gruppen baust. Alle VMs die auf den Kopf in RZ1 laufen sollten auch auf den ESXen in RZ1 laufen. Das gleiche gilt dann für RZ2. Fällt das ganze RZ aus wird alles im restlichen RZ hochgefahren.

Gruß Peter

P.S. Das gilt vor allem für 7-Mode Metro Cluster bei CDOT ..... NDA .......