Hallo,
aktuell werden bei uns alle Datastores über den IBM SVC gespiegelt (stretch cluster über 2 RZs). Nun gibt es einige wenige neue große Datastores (>10TB) mit VMDKs, bei denen die VM/Applikation selber asynchron die Daten zwischen den RZs von VMDK1 nach VMDK2 spiegeln soll. Diese Volumes sollen daher nicht noch zusätzlich über den SVC gespiegelt werden.
Ich frage mich gerade, ob ich damit beim Ausfall eines RZs in eine APD/PDL Situation laufe, von der alle Hosts betroffen sind und der ganze Cluster heruntergerissen wird. Es werden 4-5 DS auf jeder Seite sein, die restlichen 50 DS sind alle gespiegelt.
Sprich... sorgen diese ungespiegelten Volumes beim Ausfall einer Seite dazu, dass die Host alle durch APD/PDL herunter gerissen werden?
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
APD/PDL - (not) mirrored datastores
Hm, nach Studium von http://www.yellow-bricks.com/2012/09/10 ... ancements/ und http://www.jasongaudreau.com/2015/04/al ... evice.html sollte ich bei einem APD nicht mehr in das Problem mit den Host/Cluster down laufen. toi toi toi.
-
irix
- King of the Hill
- Beiträge: 12950
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Mein Verstaendnis von APD/PDL das dies pro LUN und Host ist. Die Situation wird fuer jeden Host bewertet weil es waere ja nun Fatal wenn nur ein Host ein Storage Problem hat das die LUN dann von allen Hosts im Cluster "entfernt".
Ich hatte nun schon den einen oder anderen APD/PDL und da waren nur immer einzelne Hosts aus dem Cluster betroffen und nicht alle. Das lag aber auch mit daran das auf dem Datastore weniger VMs lagen als es Hosts gab und somit nicht jeder Host eigentlich gleich gemerkt hatte das es Probleme gab.
Wir haben die gleiche Situation das Exchange (DAG) auf ungespiegelten LUNs liegt. Allerdings ist es hier noch so das ich keinen Stretched Cluster haben sondern 2 und die nichtgespiegelten LUNs auch nur an Hosts in dem RZ gemappt sind (Ich bekomme hier ein VIEW nicht so schnell weg. Ziel ist aber ein Stretched Cluster).
Gruss
Joerg
Ich hatte nun schon den einen oder anderen APD/PDL und da waren nur immer einzelne Hosts aus dem Cluster betroffen und nicht alle. Das lag aber auch mit daran das auf dem Datastore weniger VMs lagen als es Hosts gab und somit nicht jeder Host eigentlich gleich gemerkt hatte das es Probleme gab.
Wir haben die gleiche Situation das Exchange (DAG) auf ungespiegelten LUNs liegt. Allerdings ist es hier noch so das ich keinen Stretched Cluster haben sondern 2 und die nichtgespiegelten LUNs auch nur an Hosts in dem RZ gemappt sind (Ich bekomme hier ein VIEW nicht so schnell weg. Ziel ist aber ein Stretched Cluster).
Gruss
Joerg
-
irix
- King of the Hill
- Beiträge: 12950
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Hier 5.5u2.
Mit 6.x ist ja das HA um die Option der Component Protection erweitert worden. Muss man dann halt auch mal aktivieren und konfigurieren. Hier kann man sehen das APD/PDL pro Host ist weil Sinn der Sache nun ist das die VM auf einem anderen Host neugestartet wird sofern diese Zugriff auf die LUN hat.
Gruss
Joerg
Mit 6.x ist ja das HA um die Option der Component Protection erweitert worden. Muss man dann halt auch mal aktivieren und konfigurieren. Hier kann man sehen das APD/PDL pro Host ist weil Sinn der Sache nun ist das die VM auf einem anderen Host neugestartet wird sofern diese Zugriff auf die LUN hat.
Gruss
Joerg
Wir sind zum größten Teil auf 6.0. Wenn alle Hosts in einem Cluster die betroffenen LUNs sehen und die LUNs offline gehen würden (Standort weg), dann wären wegen des Host I/Os aber auch alle Hosts betroffen. Wenn ich die Artikel richtig verstehe, sollte das ab 5.1 aber kein Problem mehr sein. Component Protection habe ich aktiviert.
Ich finde die ganze Thematik Storage wird immer undurchsichtiger. z.B.
http://www.yellow-bricks.com/2016/03/21 ... -x-higher/
Immer mit der Einschränkung man sollte die passende Einstellung mit dem Storage Hersteller abklären. Die blicken da aber teilweise selber nicht durch um was es geht. Im Endeffekt kann man es nur noch falsch machen.
Ich finde die ganze Thematik Storage wird immer undurchsichtiger. z.B.
http://www.yellow-bricks.com/2016/03/21 ... -x-higher/
Immer mit der Einschränkung man sollte die passende Einstellung mit dem Storage Hersteller abklären. Die blicken da aber teilweise selber nicht durch um was es geht. Im Endeffekt kann man es nur noch falsch machen.
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo zusammen,
aus meiner Sicht ist das sowohl ein VMware als auch ein Storage Thema, und VMware macht es sich da meiner Meinung nach ziemlich leicht.
Denn VMware reagiert ausschließlich auf bestimmte Fehler Codes um einen PDL festzustellen.
Zumindest ich habe nun in mehreren Jahren im VMware/Storage Support nicht einen einzigen Fall erlebt, in dem ein Array bei einem Problem einen zu PDL passenden FehlerCode zurück gegeben hat.
Wenn also Probleme mit dem Storage auftreten wird daraus meistens ein APD mit offenem Ausgang, wie VMware ja auch im folgendem KB Artikel beschreibt.
Permanent Device Loss (PDL) and All-Paths-Down (APD) in vSphere 5.x and 6.x (2004684)
Also wird im Problemfall auf Seiten von VMware nichts unternommen, die IO's werden weiterhin Richtung Storage abgesetzt.
Bei einem Problem sind die meisten Arrays aber ohnehin schon ziemlich mit sich selbst beschäftigt, so dass die Antwortzeiten schnell auf unerträgliche Werte ansteigen.
Wer will, kann ja mal in den vobd.log eines ESXi Servers schauen, dort lassen sich oft auch Meldungen über das Antwortzeitverhalten von Storage Devices finden.
VMware verschlimmert die Situation dann häufig auch noch, weil dann wie wild mit SCSI Resets gearbeitet wird, die jede Kommunikation mit dem Device abwürgen.
Bei shared LUN's (VMFS Datastores) haben dann alle Server eines Clusters was davon, weil auch deren IO's damit kurzfristig unterbunden werden.
Kommt dann noch das "tolle" neue Feature ATS Heartbeat zum Einsatz (Default ist on) verlieren die Hosts immer mal wieder den Zugriff auf Ihre Datastores.
Ich kann zwar nicht mit einem Vorschlag dienen, wie man die Situation am besten löst, aber der aktuelle Ansatz, das alles Richtung Storage zu schieben ist mir etwas zu simpel.
Gruß,
Ralf
aus meiner Sicht ist das sowohl ein VMware als auch ein Storage Thema, und VMware macht es sich da meiner Meinung nach ziemlich leicht.
Denn VMware reagiert ausschließlich auf bestimmte Fehler Codes um einen PDL festzustellen.
Zumindest ich habe nun in mehreren Jahren im VMware/Storage Support nicht einen einzigen Fall erlebt, in dem ein Array bei einem Problem einen zu PDL passenden FehlerCode zurück gegeben hat.
Wenn also Probleme mit dem Storage auftreten wird daraus meistens ein APD mit offenem Ausgang, wie VMware ja auch im folgendem KB Artikel beschreibt.
Permanent Device Loss (PDL) and All-Paths-Down (APD) in vSphere 5.x and 6.x (2004684)
Also wird im Problemfall auf Seiten von VMware nichts unternommen, die IO's werden weiterhin Richtung Storage abgesetzt.
Bei einem Problem sind die meisten Arrays aber ohnehin schon ziemlich mit sich selbst beschäftigt, so dass die Antwortzeiten schnell auf unerträgliche Werte ansteigen.
Wer will, kann ja mal in den vobd.log eines ESXi Servers schauen, dort lassen sich oft auch Meldungen über das Antwortzeitverhalten von Storage Devices finden.
VMware verschlimmert die Situation dann häufig auch noch, weil dann wie wild mit SCSI Resets gearbeitet wird, die jede Kommunikation mit dem Device abwürgen.
Bei shared LUN's (VMFS Datastores) haben dann alle Server eines Clusters was davon, weil auch deren IO's damit kurzfristig unterbunden werden.
Kommt dann noch das "tolle" neue Feature ATS Heartbeat zum Einsatz (Default ist on) verlieren die Hosts immer mal wieder den Zugriff auf Ihre Datastores.
Ich kann zwar nicht mit einem Vorschlag dienen, wie man die Situation am besten löst, aber der aktuelle Ansatz, das alles Richtung Storage zu schieben ist mir etwas zu simpel.
Gruß,
Ralf
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 5 Gäste