NetApp E2824 Cluster per iSCSI an VMWare-Hosts - Disaster Recovery

[Eye-Q]

Mahlzeit,

wir haben einen Neukunden, dessen VMWare- und Storage-Umgebung nicht von uns eingerichtet und leider nur unzureichend (sprich gar nicht) dokumentiert wurde. Leider habe ich mit NetApp keine Erfahrung, sondern versuche mir das Wissen über die NetApp-Dokumentation anzulesen. Im Moment läuft auch alles, so dass diese Frage (zum Glück) ein "was-wäre-wenn" darstellt.

 

Wie im Titel geschrieben hat der Kunde zwei NetApp E2824 (jeweils Dual-Controller), die in unterschiedlichen Brandabschnitten laufen und per iSCSI in die VMWare-Hosts eingebunden wurden. Die VMWare-Hosts haben als iSCSI-Ziele nur die beiden iSCSI IP-Adressen der primären E2824 (192.168.40.100 und 192.168.40.101) eingerichtet, die beiden iSCSI IP-Adressen der sekundären E2824 (192.168.40.200 und 192.168.40.201) sind jedoch nirgendwo in den VMWare-Hosts zu finden. Im SANtricity ist Asynchrones Mirroring eingerichtet, so dass die Volumes auf die zweite E2824 gespiegelt werden. Synchrones Mirroring ist soweit ich das gelesen habe nur mit FC möglich, deswegen wurde eben asynchrones Mirroring eingerichtet.

 

Nun zu meiner eigentlichen Frage: wie können die VMWare-Hosts per iSCSI auf die sekundäre E2824 zugreifen, falls die primäre E2824 mal ausfallen sollte? In der Doku steht unter "Role change of a mirror consistency group" folgendes:

You can force the mirror consistency group on the secondary side to transition to the primary role. Then the recovery host is able to access the newly promoted member volumes within that mirror consistency group, and business operations can continue.

So wie ich das verstanden habe ist das ein erzwungener Rollentausch im Prinzip gleichbedeutend mit dem Ausfall der primären E2824, da auf der selben Seite folgendes steht:

When the primary mirror consistency group is demoted to the secondary role, hosts that have been assigned to the member volumes within that group no longer have write access to them.

Ich frage mich nun, wie die VMWare-Hosts, die als iSCSI-Ziel-IP-Adressen die iSCSI-IP-Adressen der primären E2824 eingetragen haben, auf die iSCSI-Ziele der sekundären E2824 zugreifen können, wenn die VMWare-Hosts nicht von den iSCSI-IP-Adressen der sekundären E2824 wissen?

[cortez]

vor 1 Stunde schrieb Eye-Q:

 wie können die VMWare-Hosts per iSCSI auf die sekundäre E2824 zugreifen, falls die primäre E2824 mal ausfallen sollte? 

Ich bin jetzt kein Experte, aber das liest sich stark danach das dort ein Snapmirror oder wie die Lösung von der NetApp heißt eingerichtet wurde.

Mehr oder weniger eine Auto Replikation von NetApp. Schau mal, ob sowas eingerichtet ist.

 

[Gast frfr]

es geht nicht ums Spiegeln, sondern um Umschalten @cortez wenn ich das richtig verstehe?

Es ist da was im VCENTER installiert, oder war es vor einer (unvollständigen) Migration auf neue VMware-Version?

[Eye-Q]

Richtig, soweit ich das beurteilen kann funktioniert das Spiegeln, allerdings wissen weder der Kunden-Admin noch ich, wie es geregelt ist, falls das primäre System mal ausfallen sollte.

Ob da etwas im vCenter installiert war, kann ich nicht sagen. Aktuell sind vCenter und ESXi 6.7 installiert, es gibt definitiv keine VM, die da in irgendeiner Form reinfunkt. Wie geschrieben sind den ESXi-Hosts nur die iSCSI IP-Adressen des primären Systems bekannt, die sind im iSCSI Software-Adapter als statische Ziele eingetragen.

[Gast frfr]

Und der Kunde hat in beiden Rechenzentren nicht nur Storage, sondern auch VMware-Server? Oder wie soll nach Meteoriteneinschlag die Rechenlast ausgeführt werden?

Schon mal geguckt, ob der Kunde überhaupt das "automatisch umschalten"-Feature gekauft hat bei NetApp?

Ist eventuell Veeam im Einsatz?

Warum kein NFS sondern ISCSI?

[Eye-Q]

vor 8 Stunden schrieb frfr:

Und der Kunde hat in beiden Rechenzentren nicht nur Storage, sondern auch VMware-Server? Oder wie soll nach Meteoriteneinschlag die Rechenlast ausgeführt werden?

Ja, die Hosts sind auf die Serverräume aufgeteilt.

vor 8 Stunden schrieb frfr:

Schon mal geguckt, ob der Kunde überhaupt das "automatisch umschalten"-Feature gekauft hat bei NetApp?

Du fragst Fragen - ich gehe davon aus, dass das in der Verwaltungsoberfläche irgendwo angezeigt werden kann, was lizenziert ist, oder? Wie geschrieben, mit NetApp kenne ich mich (noch) nicht aus.

vor 8 Stunden schrieb frfr:

Ist eventuell Veeam im Einsatz?

Ja, Veeam ist im Einsatz, wieso?

vor 8 Stunden schrieb frfr:

Warum kein NFS sondern ISCSI?

Wie oben geschrieben - Du fragst Fragen... xD Es wurde halt so eingerichtet und nicht dokumentiert, deswegen kenne ich diese Hintergründe leider nicht.

[Gast frfr]

Ich arbeite nicht für NetApp, übrigens.

[Eye-Q]

Das musst Du ja auch gar nicht, es reicht ja, wenn Du mir auf die Sprünge helfen kannst, wie die VMWare-Hosts im Fall eines Ausfalls der primären Storage auf die iSCSI-Targets der sekundären Storage zugreifen können.  Ich arbeite auch nicht für Microsoft, VMWare, Veeam, HP, Dell etc. und habe trotzdem Ahnung von den Produkten und wie die eingerichtet und administriert werden.

[Eta_Carinae]

Im Falle des Falles musst du die Volumes auf der Secondary online bringen und den ESXi Hosts die Secondary als neue iSCSI Targets hinzufügen. Nach einem Rescan sind die Datastores wieder da.

Ist das vCenter eine VM? Wenn ja, dann wird der Failover etwas aufwändiger, weil dir dann zu dem Zeitpunkt das vCenter fehlt. Dann musst du das vCenter auf einem Host erstmal im Inventory registrieren, einschalten und danach kannst du die anderen Hosts anpassen. Ach ka, DC wäre dann auch praktisch - sonst tut‘s das vCenter auch nicht.

[Gast frfr]

spannend wirds auch wenn man DV-Switches hat, das ist nochmal ne Kurve.

geht bei 6.7 überhaupt noch "VCENTER auf Blech"?

Bearbeitet 7. August 2020 von frfr

[Eye-Q]

Am 8/7/2020 um 6:24 PM schrieb Eta_Carinae:

Im Falle des Falles musst du die Volumes auf der Secondary online bringen und den ESXi Hosts die Secondary als neue iSCSI Targets hinzufügen. Nach einem Rescan sind die Datastores wieder da.

Ich hatte gehofft, dass das irgendwie automatisch gehen könnte...

OK, da hätte ich präziser fragen müssen, um nicht so eine Antwort zu erhalten...

Am 8/7/2020 um 6:24 PM schrieb Eta_Carinae:

Ist das vCenter eine VM? Wenn ja, dann wird der Failover etwas aufwändiger, weil dir dann zu dem Zeitpunkt das vCenter fehlt. Dann musst du das vCenter auf einem Host erstmal im Inventory registrieren, einschalten und danach kannst du die anderen Hosts anpassen.

Ja, das vCenter ist eine VM, daran hatte ich gar nicht gedacht, dass das dann auch down ist... 😐

 

Am 8/7/2020 um 7:30 PM schrieb frfr:

spannend wirds auch wenn man DV-Switches hat, das ist nochmal ne Kurve.

Zum Glück gibt's da nur Standard-vSwitches.

Am 8/7/2020 um 7:30 PM schrieb frfr:

geht bei 6.7 überhaupt noch "VCENTER auf Blech"?

Ja, prinzipiell schon, das läuft aber in diesem Falle als vCSA.

[Eta_Carinae]

Am 7.8.2020 um 19:30 schrieb frfr:

spannend wirds auch wenn man DV-Switches hat, das ist nochmal ne Kurve.

geht bei 6.7 überhaupt noch "VCENTER auf Blech"?

Nö, warum sollte ein DVS ein Problem sein?

vCentet will man eh nicht auf Blech haben.

[Gast frfr]

zu 5.5-Zeiten fand ich vcenter auf Blech praktisch, da waren die Stadtwerke mal da und wollten das Trafohäuschen putzen, d.h. alles ausschalten incl. SAN und allem, da war das elegant zu handhaben.

Und die Klimatisierung war auch nicht die allerbeste, da war es (theoretisch) praktisch einfach ein Gebäude weiter zu ziehen, 26.000m2 Grundfläche mit ca. 1 Dutzend Gebäuden.

War auch neben Flugplatz (einmotorige Maschinen). 🙂

Jetzt wird hier VXRAIL 6.7 gefahren, mit DV-Switchen (Nach VCenter-Recovery läuft das gern mal in einer "Netzwerkinsel"), ohne DC auf Blech, sogar ohne USV. No Risk no fun.

Bearbeitet 13. August 2020 von frfr

[Eta_Carinae]

Viel Spaß mit VxRail... Ich habe für einen Kunden in EMEA 20 Deployments gemacht - was ein Pile of Shit....