Das Forum wurde aktualisiert. Wurde höchste Zeit. Wenn etwas nicht funktioniert, bitte gerne hier jederzeit melden.

Heartbeat IO und Atomic Test and Set (ATS) mit IBM Storage

Alles zum Thema vSphere 6, ESXi 6.0 und vCenter Server.

Moderatoren: Dayworker, continuum, Tschoergez, irix

Member
Beiträge: 475
Registriert: 08.08.2008, 10:45

Heartbeat IO und Atomic Test and Set (ATS) mit IBM Storage

Beitragvon pirx » 29.08.2015, 10:57

Hallo,

nach dem wir gestern sehr unsanft von http://www-01.ibm.com/support/docview.w ... g1S1005201 getroffen wurden und dadurch 350 VMs down waren, die Host auf nichts mehr reagiert haben (kein DCUI/ssh Login, nix mehr), möchte ich allen die IBM Storage mit vSphere >5.5U1 einsetzen den KB Artikel ans Herz legen.

So eine Downtime hatten wir im Virtualisierungsumfeld noch nie, ich bin mir nicht sicher ob ich mich bei VMware oder IBM dafür bedanken soll. Oder bei mir, weil es mir durch die Lappen gegangen ist.

Profi
Beiträge: 991
Registriert: 31.03.2008, 17:26
Wohnort: Einzugsbereich des FC Schalke 04
Kontaktdaten:

Beitragvon kastlr » 29.08.2015, 12:37

Hallo,

das Problem habe ich auch schon mit EMC Storage (VMAX, VNX und VPLEX) beobachten können.
Meiner persönlichen Einschätzung nach handelt es sich offenbar um ein Last abhängiges Problem.

Jedenfalls hat in bisher allen Fällen die Deaktivierung von ATS HB das Problem ohne weitere Nebenwirkungen behoben.
Enabling or disabling VAAI ATS heartbeat (2113956)
Einen Benefit gegenüber der klassischen Methode habe ich bisher auch nicht erkennen können.

Gruß,
Ralf

Member
Beiträge: 475
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 29.08.2015, 14:11

Nach dem was ich jetzt gelesen habe, war die Änderung von VMware wohl nicht so ganz überlegt und es sind unterschiedliche Hersteller davon betroffen. Schade das VMware die Änderung bei der möglichen Auswirkung nicht in einem Patch wieder rückgängig gemacht hat.

http://timsvirtualworld.com/2015/04/ats ... -emc-vmax/

http://www.vmdude.fr/en/news-en/solidfi ... heartbeat/

Member
Beiträge: 87
Registriert: 23.05.2013, 22:14

Re: Heartbeat IO und Atomic Test and Set (ATS) mit IBM Stora

Beitragvon vl13 » 31.08.2015, 12:03

pirx hat geschrieben:So eine Downtime hatten wir im Virtualisierungsumfeld noch nie, ich bin mir nicht sicher ob ich mich bei VMware oder IBM dafür bedanken soll. Oder bei mir, weil es mir durch die Lappen gegangen ist.


Da ich mich and die mail von IBM noch erinnern kann habe ich mal in meinem archiv nachgeschaut.

Der folgende IBM Flash alert ist bei mir am 2015-04-13 eingegeangen, ich muss aber gestehen das ich wirklich glueck hatte da ich mich erst ein paar tage zuvor fuer diese alerts angemeldet hatte

FLASH: Host Disconnects Using VMware vSphere 5.5.0 Update 2 and vSphere 6.0 (2015.04.13)

My notifications for Storage - 13 Apr 2015
...
------------------------------------------------------------------------------
1. IBM Storwize

- TITLE: Host Disconnects Using VMware vSphere 5.5.0 Update 2 and vSphere 6.0
- URL: http://www.ibm.com/support/docview.wss? ... CHW206-_-E
- ABSTRACT: VMware vSphere 5.5.0 Update 2 and vSphere 6.0 hosts may experience multiple repeated disconnects leading to application outages in response to delays in completing heartbeat I/O.

Member
Beiträge: 475
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 31.08.2015, 12:56

Die Warnung habe ich inzwischen auch gefunden. Da das von VMware geänderte Verhalten aber mit unterschiedlichen Storage Herstellern auftritt, habe ich das Gefühl das VMware hier daneben gelangt hat und sich nicht traut den Zustand von pre 5.5 wieder herzustellen.

Wenn eine Wartungsarbeit wie das Rebooten eines redundaten Storage Controller zu solchen Effekten führt und VMware seit 5.5U2 darüber Bescheid weiß, dann ist das für mich grob fahrlässig (ich bin etwas geladen gerade...).

Profi
Beiträge: 991
Registriert: 31.03.2008, 17:26
Wohnort: Einzugsbereich des FC Schalke 04
Kontaktdaten:

Beitragvon kastlr » 31.08.2015, 13:15

Dass sich aus dem Verlust von virtuellen Maschinen ein reales Problem ergeben kann ist mir völlig neu....

;-)
Ralf

Member
Beiträge: 87
Registriert: 23.05.2013, 22:14

Beitragvon vl13 » 31.08.2015, 13:25

pirx hat geschrieben:Wenn eine Wartungsarbeit wie das Rebooten eines redundaten Storage Controller zu solchen Effekten führt und VMware seit 5.5U2 darüber Bescheid weiß, dann ist das für mich grob fahrlässig (ich bin etwas geladen gerade...).


Kann ich sehr gut nachvollziehen, noch mehr fuer alle anderen die es getroffen hat und die keine IBM storages verwenden, da sich http://kb.vmware.com/kb/2113956 nur auf Storwize bezieht.

Profi
Beiträge: 991
Registriert: 31.03.2008, 17:26
Wohnort: Einzugsbereich des FC Schalke 04
Kontaktdaten:

Beitragvon kastlr » 31.08.2015, 16:54

Hallo zusammen,

bin gerade in einer Diskussion mit dem VMware Support zu diesem Thema.
Dieser hat empfohlen, die VMFS Datastores vom Modus ATS-Only auf Public zu wechseln.

Ist euch das vielleicht auch vorgeschlagen worden bzw. habt Ihr diese Änderung vorgenommen?

Gruß,
Ralf

Member
Beiträge: 87
Registriert: 23.05.2013, 22:14

Beitragvon vl13 » 31.08.2015, 18:58

kastlr hat geschrieben:Hallo zusammen,

bin gerade in einer Diskussion mit dem VMware Support zu diesem Thema.
Dieser hat empfohlen, die VMFS Datastores vom Modus ATS-Only auf Public zu wechseln.


Wenn ich das richtig verstehe (nur ueberflogen) muss das fuer jedes volume vorgenommen werden das frisch mit VMFS5 formatiert wurde [1].
Der vorteil ist wohl das dies im VMFS5 gespeichert wird und nicht pro host gesetzt werden muss.
Hat der support evtl. etwas gefunden das in diese richtung geht? [2]

1) kb 2006858 , kb 1033665
2) ats-only-vmfs-volume-vmfs5-not-mounted-host-does-not-support-ats-or-ats-initialization-has-failed

Profi
Beiträge: 991
Registriert: 31.03.2008, 17:26
Wohnort: Einzugsbereich des FC Schalke 04
Kontaktdaten:

Beitragvon kastlr » 31.08.2015, 20:53

Na ja,

auf meine gezielte Nachfrage, weshalb man die Funktion deaktivieren und zusätzlich die VMFS Datastores umkonfigurieren soll, habe ich folgende Antwort erhalten.
VMware Support hat geschrieben:Hallo Herr xxxxx,

Dieses Problem ist uns nun mit doch schon sehr vielen Storages bekannt.
Teilweise mussten wir hier beides deaktivieren um ueberhaupt eine Aenderung sehen zu koennen.
Daher schlage ich meinen Kunden seit her immer vor beides abzustellen und danach die Flage wieder zu setzen sobald wir sehen das es besser geworden ist.
In diesem Fall wuerde der Fehler dann nur einen Datastore treffen und nicht weiter hin alle, welches ein umgehen das Fehlers einfacher und schneller macht.

Wenn Sie dieses so nicht machen moechten, reicht es vorerst auch wenn Sie nur das ATS fuer Heartbeats abstellen.

Tiefer in das Problem kann ich leider nicht eingehen, da es ab dann immer von der Entwicklung uebernommen worden ist.

Eine klare Aussage sieht meiner Meinung nach anders aus, zumal wir bei unseren Kunden mit dem Deaktivieren der ATS Heartbeat Funktionalität alle Probleme dauerhaft lösen konnten.
Und das Umsetzen der VMFS Datastores ist ja ohne Downtime gar nicht möglich, somit erwarte ich schon eine bessere Begründung, warum dies in unserem speziellem Fall erforderlich sein soll (oder eben nicht).

Gruß,
Ralf

Member
Beiträge: 475
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 01.09.2015, 13:46

Ich wäre ja schon froh, wenn ich eine Rückmeldung vom Support bekommen würde. Bis auf den Rückruf gestern, dass man mind. 1 Tag braucht um die Logs zu analysieren, weiß ich noch nix.

Profi
Beiträge: 991
Registriert: 31.03.2008, 17:26
Wohnort: Einzugsbereich des FC Schalke 04
Kontaktdaten:

Beitragvon kastlr » 01.09.2015, 14:05

Hallo,

das kannst du selber schneller erledigen.

Nach dem Deaktivieren der ATS HB Funktionalität solltest du keinerlei Meldungen des folgenden Typs in den vmkernel.logs finden.

Code: Alles auswählen

ATS Miscompare detected between test and set HB images at offset

Wenn du diese Einträge weiterhin hast, kannst du ja zusätzlich deine VMFS Datastores von ATS-Only auf Public umstellen.

Weiterhin kannst du ja noch prüfen, ob du SCSI Fehler in den vmkernel.logs findest .
Zusätzlich empfehle ich dir, den vobd.log auszuwerten.

Gruß,
Ralf

Member
Beiträge: 475
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 01.09.2015, 16:02

ATS HB Funktionalität habe ich schon am Mo. für alle Hosts deaktiviert. Aber wir haben immer noch ein DS mit einem VMFS lock auf das nur noch wenige Hosts zugreifen können.

Member
Beiträge: 475
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 02.09.2015, 09:26

So, heute Nacht hat es wieder gekracht. Irgendwas mit dem SVC (das scheint nicht die stabilste Lösung zu sein). ATS Miscompare Meldungen gab es nicht, es hat trotzdem zu den gleichen Auswirkungen geführt wie am Freitag. In dem Cluster mit den meisten Hosts (24) und LUNs (>40) sind die Host in den Status disconnect gegangen und VMs waren down. Die anderen Cluster mit weniger Hosts haben zwar auch Fehler in Richtung Storage gezeigt, aber sind daraus ohne größeren Schaden wieder raus gekommen. Das verstehe ich nicht, eigentlich sollten sich die Cluster doch identisch verhalten wenn sie auf den gleichen fauligen Storage gehen.

Extrem unschön.

Profi
Beiträge: 991
Registriert: 31.03.2008, 17:26
Wohnort: Einzugsbereich des FC Schalke 04
Kontaktdaten:

Beitragvon kastlr » 02.09.2015, 12:11

Was sagen den die vobd.logs der Server, ich vermute mal dass du dort extreme schlechte Antwortzeiten finden wirst.
Und schau mal nach ob due SCSI resets in den vmkernel.logs findest.

Das wird dir bei der Lösung deines Problems zwar nicht wirklich weiterhelfen, könnte aber die Ursache deiner Probleme sein.

Halte durch, es kommen auch bessere Zeiten (selbst mit SVC ;-) )

Gruß,
Ralf

Member
Beiträge: 475
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 07.09.2015, 10:46

So, jetzt erhalten wir vom VMware Support auch den "Rat" alle Datastores auf public umzustellen. Was bei > 100 Datastores und den benötigen umounts ein mittlerer Gau ist.

Ein Grund mehr sich besser nicht mit VSAN usw zu beschäftigen.

Profi
Beiträge: 991
Registriert: 31.03.2008, 17:26
Wohnort: Einzugsbereich des FC Schalke 04
Kontaktdaten:

Beitragvon kastlr » 08.09.2015, 12:31

Hallo,

dann seid Ihr jetzt ja gut beschäftigt.

Spaß beiseite, mich persönlich wundert diese Vorgehensweise schon.
Wenn ich mich recht erinnere, wurde "ATS-Only" doch bereits deutlich vor 5.5U2 eingeführt.
Somit war es doch bereits vor der Einführung von ATS Heartbeat möglich, ATS-Only Datastores anzulegen.
Mit dem Deaktivieren von ATS Heartbeat wird nach meinem Kenntnisstand ATS ja auch nicht komplett deaktiviert, sondern nur diese eine spezielle neue Funktion.

Wenn nun ATS Heartbeat deaktiviert worden ist, was ist denn dann bitte schön der Grund dafür, nun auch noch Änderungen an bereits seit Monaten/Jahren problemlos verwendeten VMFS Datastores vorzunehmen?

Auf diese Frage hätte ich liebend gerne eine Antwort.
Zumal sich aus Sicht des verwendeten Arrays ja auch so nichts ändern wird, es wird immer noch ATS Kommandos unterstützen und der Host könnte sie immer noch verwenden, da dieses Feature ja nicht deaktiviert worden ist.

Alles ziemlich verwirrend, wie gut dass das alles bloß virtuell und nicht real ist.

Gruß,
Ralf

Member
Beiträge: 475
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 02.10.2015, 12:41

So, die Datastores auf public umzustellen ist unnötig und würde laut VMware Support nichts bringen (gut das wir den ersten Rat vom Support damals nicht gleich umgesetzt haben).

Code: Alles auswählen

.... hat mich auf einen Fehler in der Dokumentation hingewiesen. Das ATS-only sollte/wird wohl mal so funktionieren wie ich es dem Herrn xxxx ueber mehrere Emails und Telefonate erklaert habe. Dieses ist momentan aber nicht der Fall!


Wir sollen aber trotzdem auf allen Hosts ATS Locking deaktivieren (nicht nur ATS Heartbeats). Eine genaue Begründung gab es dazu nicht.

Insgesamt fühle ich mich in meiner VMware Haut immer unwohler.


Zurück zu „vSphere 6.0“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast