Na update problemen met VSAN cluster

[OsiriS.nl]

Ik weet niet of ik hier aan het goede adres ben maar ik heb wat probleempjes met mijn VSAN cluster.

Ik heb dinsdag geupdate van 6.0 naar 6.0update1 eerst vcenter en toen de hosts. Alles verliep perfect geen problemen. Tot ik gister erachter kwam dat Veeam niet meer kan backuppen. Even gezocht en bleek dat met update1 er iets met SSLv3 gebeurde waardoor Veeam niet meer kon connecten. Vandaar dat ik wat config-files heb aangepast en bijbehorende service restart en Veeam werkte weer en geen problemen. Echter is vannacht iets mis gegaan waardoor de VSAN nu dood is.

De hosts zijn up en kan ik naar connecten maar de Vcenter niet (die zit op de VSAN). De hosts geven ook maar VSAN capaciteit aan van 1 host. Het lijkt dus alsof de VSAN niet opgebouwd wordt over de 3 hosts.
Het probleem is nu dat mijn vcenter ook niet meer werkt. Ik heb de hosts al gereboot maar dit brengt geen verbetering.

Mijn vraag is nu, weet iemand hiet wat ik nu het beste kan doen?
Ik zelf denk dat het door de update komt aangezien ik sinds de release van 6.0 nooit problemen heb gehad. Of zou het door het aanpassen van die config-files komen met SSLv3 (welke ik inmiddels terug naar standaard heb gemaakt, wat ook niet helpt).
Persoonlijk denk ik er goed aan te doen om op een localstorage een vcenter 6.0u1 uit te rollen en hiermee te proberen om de VSAN weer terug in de lucht te krijgen.

BTW, ik heb backups van mijn VM's op een externe NAS en mijn belangrijkste files uiteraard ook. Ik ben geen data kwijt maar zou liever mijn VSAN herstellen dan alle VM's te restoren.

edit: Ik zie nu net een handleiding om VSAN te bootstrappen zonder Vcenter. Wellicht is het verstandiger om eerst eens met van VSAN commands te kijken wat aan de hand is. Hopelijk kan ik de VSAN ook op die manier herstellen...?!

[ Voor 6% gewijzigd door OsiriS.nl op 08-10-2015 10:05 . Reden: Meer info gevonden ]

[FireDrunk]

Kan je niet fysiek op de host inloggen die nog wel storage heeft, en de vCenter VM booten?
Of via de GUI, Register Virtual Machine -> Browse naar VSAN

[ Voor 25% gewijzigd door FireDrunk op 08-10-2015 10:06 ]

[OsiriS.nl]

Bedankt voor je reactie!

De Vcenter staat op de VSAN en de VSAN is kapot. Elke host ziet alleen de storage capacity van zichzelf waardoor de VSANdatastore leeg lijkt. Alle VM's op de VSAN staan nu ook uitgegrijst in de inventory.
Daardoor kan ik de Vcenter niet booten en zal ik eerst de VSAN moeten herstellen, denk ik

[ Voor 4% gewijzigd door OsiriS.nl op 08-10-2015 10:20 ]

[FireDrunk]

Ok, kan je op de node(s) zelf de vsan status opvragen?

https://pubs.vmware.com/v...ef.doc%2Fesxcli_vsan.html

Iets als:

esxcli vsan cluster get
esxcli vsan network get

(gokje)

[OsiriS.nl]

Ik ben momenteel niet thuis dus ik kan nu niet kijken. Maar ik ga vanmiddag als ik thuis ben meteen proberen! Thanks!

[OsiriS.nl]

esxcli vsan cluster get geeft alles goed aan volgens mij:

Cluster Information
Enabled: true
Current Local Time: 2015-10-08T15:28:53Z
Local Node UUID: 536047ee-7f22-fd68-c9f1-6805ca2318eb
Local Node Type: NORMAL
Local Node State: MASTER
Local Node Health State: HEALTHY
Sub-Cluster Master UUID: 536047ee-7f22-fd68-c9f1-6805ca2318eb
Sub-Cluster Backup UUID: 53dd3a8d-74d4-7ebe-5f88-001517ee0946
Sub-Cluster UUID: 52828a7c-cfad-e2e9-3a84-187593396b0c
Sub-Cluster Membership Entry Revision: 6
Sub-Cluster Member Count: 4
Sub-Cluster Member UUIDs: 536047ee-7f22-fd68-c9f1-6805ca2318eb, 53dd3a8d-74d4-7ebe-5f88-001517ee0946, 53df9839-9d63-f6a6-d5b5-001517157820, 55de0c54-5e93-6baa-bd7a-001517e01e82
Sub-Cluster Membership UUID: 04091656-c8c1-4716-5e67-00151715771a

En ook esxcli vsan network list:
Interface
VmkNic Name: vmk1
IP Protocol: IPv4
Interface UUID: 162cdf53-d814-82d7-53f0-00151715771a
Agent Group Multicast Address: 224.2.3.4
Agent Group Multicast Port: 23451
Master Group Multicast Address: 224.1.2.3
Master Group Multicast Port: 12345
Host Unicast Channel Bound Port: 12321
Multicast TTL: 5


edit: pingen gaat ook naar de andere hosts...weird
Ik ga eens alles shutdown doen i.p.v. reboot en de switch herstarten.

[ Voor 5% gewijzigd door OsiriS.nl op 08-10-2015 17:35 ]

[FireDrunk]

Kan je het vsan volume niet los online brengen?

[OsiriS.nl]

Hoe bedoel je los online brengen?

Alles lijkt in orde maar de vsan datastore blijft leeg een geeft een verkeerde capacity aan.
Heb al geprobeerd om vsan cluster te leaven en joinen maar geen verbetering.

Dan maar proberen een nieuwe vcenter uit te rollen en daar de vsan weer werkend te krijgen..


edit: vsan storage list geeft aan dat er een diskgroup is met de SSD en HDD erin echter de vi client geeft aan dat het mogelijk is een datastore aan te maken op de SSD en HDD. Terwijl hij deze normaal echt claimed voor VSAN.

[ Voor 27% gewijzigd door OsiriS.nl op 08-10-2015 18:30 ]

[FireDrunk]

Hmm, vsan zou ook zonder vCenter moeten werken... Zal er eens over nadenken...

[OsiriS.nl]

Ja dat lees ik ook, maar op de een of andere manier is er iets niet goed waardoor het niet werkt

Ik weet niet welke commandos ik veilig kan geven om het te herstellen. Daarom doe ik het liever via een nieuwe vcenter..

Shit kom nu niet bij mn iso's en de website van vmware is in maintenance, geweldig!
Onder water lijkt alles goed te functioneren en geen rare dingen, maar in de vi client en datastore zeggen iets anders. Geen idee wat nu het probleem is. Ik hoop het op te lossen d.m.v. een nieuwe vcenter maar misschien ligt het probleem bij 6.0u1 i.c.m. mijn hardware ofzo...

Update: ik heb inmiddels mijn vsan datastore terug d.m.v. het opnieuw claimen van disks. Echter is deze helemaal leeg! Ben nu nieuwe vcenter aan het deployen, dus ben beniewd wat dat brengt.
Mooi klote dat ik nu alles moet gaan restoren...de oorzaak heb ik nog steeds niet gevonden...

Update2: Jup waarschijnlijk door het opnieuw claimen van de disks wat nodig was op 2 van de 3 hosts zijn die dskgroepen leeggemaakt waardoor mijn hele vsan nu leeg is. Op de Disk die niet opnieuw geclaimed is staat nog data maar daar kom ik niet bij. Dus beschouw ik alle data van de vsandatastore als verloren.
Wat nu? Ik weet nog steeds niet wat dit veroorzaakt heeft. Ik kan wel alles gaan restoren maar als het dadelijk weer crasht ben ik er klaar mee. Ligt het aan 6.0u1 of hardwarematig iets niet goed? Moet ik downgraden en restoren of nu gewoon restoren? Moet ik defecte hardware vervangen?
Wie kan mij een zetje in de goede richting geven want ik weet me even geen raad meer..

[ Voor 92% gewijzigd door OsiriS.nl op 08-10-2015 21:13 ]

[thedon46]

OsiriS.nl schreef op donderdag 08 oktober 2015 @ 18:33:
Wie kan mij een zetje in de goede richting geven want ik weet me even geen raad meer..

Wat ik zelf zou doen is de schijven eruit halen, en kijken of je met een soort disk resque de data eraf kan lurken.
Dan heb je in ieder geval je data nog.

Dan eerst weer alle disk checken op fouten. Misschien is er wel een disk stuk?

Dan opnieuw beginnen en je data terug zetten. Dan weet je zeker dat alles weer werkt.

Tenzij iemand een beter idee heeft?

[OsiriS.nl]

Naja data ben ik niet verloren dankzij een goede backup strategie maar de tijd en energie die erin gaat zitten om alles weer up en running te krijgen.....

Inmiddels denk ik achter de oorzaak de zijn gekomen...6.0update1!
Of VSAN met update 1 strikter is geworden ofzo. Hij unmount op een bepaald moment gewoon een hele diskgroup. Die betreffende nacht heeft ie 2 diskgroupen verdeeld over 2 hosts unmount waardoor alles in de soep liep. Nu terug op 6.0 en geen enkel probleem meer.
Leer voor de volgende keer: ik zet geen vcenter meer op de VSAN. Omdat de vcenter gecrasht was was ik niet in staat te zien wat er nu aan de hand was. Achteraf had ik mijn data kunnen behouden als ik had geweten dat mijn diskgroups unmount waren. Je kunt ze namelijk makkelijk weer mounten met esxcli vsan storage diskgroup mount...

[FireDrunk]

Mja, dat disk reclaimen je data zou wipen is natuurlijk wel enigzins logisch.
Je kan (als het moet) zelfs een single node vsan storage pool in de lucht brengen.
(William Lam heeft er zelfs een tutorial van, om zo direct vCenter in te spoelen op vsan).
EDIT: linkje: http://www.virtuallyghett...-vcenter-server-onto.html

Ik heb het nu ook thuis (weer) draaien. Zal binnenkort eens upgraden naar 6.0u1.

_{Moet eerst mijn keys weer vinden... geen idee waar ik die dingen gelaten heb...}

[ Voor 9% gewijzigd door FireDrunk op 12-10-2015 21:27 ]

[OsiriS.nl]

Ja maar als die host voor 1/3 van de vms de witness is valt al een groot deel van de vms weg hoor!
En als die net van de vcenter witness is heb je pech.

Ik zag het mount commando te laat, die stond in de nieuwe lijst met commandos van 6.0.
Ik heb dit weekend nog geen dag gedraaid met 6.0u1 en ik had al 1 host met unmounted diskgroup.
Achteraf inderdaad logisch dat na het claimen de data weg is maar zonder vcenter kon ik niet zien wat echt aan de hand was!

Omdat ik binnen 24u weer een unmounted diskgroup had ben ik terug naar 6.0 en dat draait nu 2 dagen. Voor de upgrade draaide het cluster al 6 maanden probleemloos. Dus voor mij voorlopig geen upgrade meer. Ik ben benieuwd naar jou bevindingen met update 1.
Ons lab op kantoor draait 6.0u1 met VSAN zonder problemen dus gok dat het aan mijn non-server hardware ligt..

[hans_lenze]

Oh ja, automatisch unmount van vertragende disks. Das nieuw, gaaf hé.

http://cormachogan.com/20...roblematic-disk-handling/

[OsiriS.nl]

hans_lenze schreef op woensdag 14 oktober 2015 @ 18:02:
Oh ja, automatisch unmount van vertragende disks. Das nieuw, gaaf hé.

http://cormachogan.com/20...roblematic-disk-handling/

Dat is een heel mooie feature alleen niet voor thuis

Er staat wel een work-around bij, uitproberen of toch maar op 6.0 zonder update1 blijven?

[ Voor 12% gewijzigd door OsiriS.nl op 16-10-2015 09:01 ]

[br00ky]

OsiriS.nl schreef op donderdag 08 oktober 2015 @ 09:50:
Ik weet niet of ik hier aan het goede adres ben maar ik heb wat probleempjes met mijn VSAN cluster.

Reacties afgesplitst, want je probleem werd wel heel uitgebreid

[FireDrunk]

De kans is wel heel groot dat het inderdaad aan die auto unmount ligt.
Kan je in de logs kijken naar die latency meldingen?

[OsiriS.nl]

br00ky schreef op zaterdag 17 oktober 2015 @ 07:36:
[...]

[Mbr]Reacties afgesplitst, want je probleem werd wel heel uitgebreid :)[/]

Thanks! Wellicht beter inderdaad.

FireDrunk schreef op zaterdag 17 oktober 2015 @ 08:23:
De kans is wel heel groot dat het inderdaad aan die auto unmount ligt.
Kan je in de logs kijken naar die latency meldingen?

Ik zag in de logs van 1 host inderdaad iets voorbij komen mbt error meldingen van een van de ssd's.
Na de restore met 6.0u1 liep het binnen 24uur weer vast en zag in de vcenter dat de diskgroup unmount was inderdaad.
Nu draai ik wederom probleemloos 6.0... Ik denk dat ik nog even wacht met update 1 en dan die "feature" disablen.

[hans_lenze]

Ik plak nog even het laatste stuk tekst uit de blogpost zodat de oplossing hier ook bij staat:

To avoid this situation, there are two advanced parameters that will prevent the disk group from unmounting:

Disable VSAN Device Monitoring (and subsequent unmounting of diskgroup):
# esxcli system settings advanced set -o /LSOM/VSANDeviceMonitoring -i 0 <— default is “1″

-or-

Disable VSAN Slow Device Unmounting (continues monitoring):
# esxcli system settings advanced set -o /LSOM/lsomSlowDeviceUnmount -i 0 <— default is “1″

It might be a good idea to turn off these features immediately on home labs, before starting any virtual machines, or maintenance mode type operations where data is being migrated between hosts. This is also true for readers planning to upgrade their home labs to VSAN 6.1 (vSphere 6.0u1).

bron: http://cormachogan.com/20...roblematic-disk-handling/

[FireDrunk]

Ik heb nu ook VSAN draaien, en moet ook nog upgraden. Even om denken dus.

Ik ben wel beniewd naar de verschillen in latency die vmware verwacht en wat homemade dus mist. Ik heb zelf redelijk vlotte ssds, dus ik wacht geen problemen, maar het is wel leerzaam om te zien wat het limiet is.

[hans_lenze]

What we look for is a significant period of high latency on the SSD or the magnetic disk drives. If this sustained period of high latency is observed, then VSAN will unmount the disk group on which the disk resides.

De exacte waarde staat in de blogpost. 50ms is de grens voor unmounten. Hoe vaak je deze grens over moet staat er dan weer niet in. Een SSD haalt dat wel maar de laptop schijfjes die ik er ook in heb hangen zitten regelmatig rond de 200ms als ik een tweetal deployments naast elkaar draai. Zelfs met een goeie 7200rpm SATA schijf is het niet moeilijk om boven die 50ms uit te komen.

[OsiriS.nl]

Ja die 50ms haal ik wel denk ik, zeker als Veeam en andere backups lopen het 's nachts.
Ben inderdaad wel benieuwd wat het verschil is tussen een homelab en een productie omgeving.
Ik zal deze week eens kijken wat voor latency wij hebben op onze productie VSAN op het werk.

[hans_lenze]

Vergeet dan niet dat het om disk latency gaat. Die kun je bekijken in de VSAN Observer.

[OsiriS.nl]

Heeft iemand hier zijn thuis-lab geupdate naar update 1 i.c.m. VSAN en nog verder nog geen settings m.b.t. auto unmount gewijzigd? Ik ben namelijk benieuwd of ik de enige ben met Thuis-lab bij wie de auto unmount alles in de soep laat lopen...

[FireDrunk]

Ik vind het een *iets* te groot risico om zomaar te updaten
Dan moet ik eerst even al mijn VM's er af migreren. Misschien dit weekend.

[OsiriS.nl]

Hahaha, begrijpelijk. Ben namelijk benieuwd of het misschien toch aan mijn hardware ligt. Alhoewel ik met 6.0 nog steeds geen problemen heb.
Zonder load zul je sowieso niet tegen problemen aan lopen denk ik.

[Bigs]

Staan al je componenten op de VSAN HCL of niet?

[FireDrunk]

Heb momenteel 6 VM's draaien ofzo. Maar ik werk ook met templates. Dus ik kan vrij simpel VSAN op zijn staart trappen door gewoon 2-3 templates tegelijk uit te rollen

[OsiriS.nl]

Bigs schreef op donderdag 22 oktober 2015 @ 14:06:
Staan al je componenten op de VSAN HCL of niet?

Tuurlijk niet, als je weet hoeveel een VSAN ready node kost en dat maal 3 dan snap je waarom. (voor een thuis-lab althans)

Een windows templates uitrollen ofzo zorgt wel voor lekker wat load inderdaad!

[Bigs]

OsiriS.nl schreef op vrijdag 23 oktober 2015 @ 11:30:
[...]

Tuurlijk niet, als je weet hoeveel een VSAN ready node kost en dat maal 3 dan snap je waarom. (voor een thuis-lab althans)

Een windows templates uitrollen ofzo zorgt wel voor lekker wat load inderdaad!

Snap ik, maar heb je op z'n minst een geschikte HBA bijvoorbeeld (en dus zonder gemodificeerde AHCI driver)?

[FireDrunk]

AHCI is überhaupt niet supported.

[OsiriS.nl]

Om aan HCL te voldoen voor VSAN voor een home-lab vind ik een paar duizend euro per node iets te prijzig.
Voor een home-lab kom je mijn inziens altijd uit bij een unsupported setup. Maar dat kun je ook teruglezen in de gedeelde link hierboven. Daar zijn ze zich bij VMWare wel van bewust. Het werkt verder gewoon perfect hoor!