Onderwerp: VM's instabiel na migratie

Als het aan de migratie zou liggen verwacht ik dat je het eerder zou merken.

zet vm.dirty_background_ratio eens op 5 en vm.dirty_ratio op 10. Misschien zelfs de vm.dirty_expire_centisecs op 1000 (als dat lager is wat je nu hebt).
Dat betekent dat het vm zijn dirty pages eerder naar de storage schrijft, maar in kleinere blokken.

Dat voorkomt dat er een situatie komt waarbij het vm 'opeens' de default 30% cache ram naar zijn storage moet duwen.

Omdat ik natuurlijk niet weet welk vm, welk soort load heeft, zul je iets moeten spelen met die waarden.

Zo zou je vm.dirty_background_ratio op 5 kunnen laten om te zorgen dat de cache asynchroon geflushed wordt als 5% van het ram gebruikt is, maar de vm.dirty_ratio op 70-80 zetten. (dan wordt de cache pas synchroon geforceerd naar cache als 80% in gebruik is.

Oorspronkelijk geplaatst door systemdeveloper

zet vm.dirty_background_ratio eens op 5 en vm.dirty_ratio op 10. Misschien zelfs de vm.dirty_expire_centisecs op 1000 (als dat lager is wat je nu hebt).
Dat betekent dat het vm zijn dirty pages eerder naar de storage schrijft, maar in kleinere blokken.

Dat voorkomt dat er een situatie komt waarbij het vm 'opeens' de default 30% cache ram naar zijn storage moet duwen.

Omdat ik natuurlijk niet weet welk vm, welk soort load heeft, zul je iets moeten spelen met die waarden.

Zo zou je vm.dirty_background_ratio op 5 kunnen laten om te zorgen dat de cache asynchroon geflushed wordt als 5% van het ram gebruikt is, maar de vm.dirty_ratio op 70-80 zetten. (dan wordt de cache pas synchroon geforceerd naar cache als 80% in gebruik is.

Ik heb het getest, heb net de vm.dirty_background_ratio op 5 gezet en de vm.dirty_ratio op 10.
Toen ben ik gaan testen met het migreren van VM's.
In het begin leek dit verassend goed te gaan.
Heb enkele VM's live op en neer gemigreerd tussen verschillende nodes.
Dit ging perfect en alles bleef online.

Echter daarna een andere VM een beetje druk gemaakt door alle custombuild updates te installeren, daarna direct afgesloten. Toen gemigreerd naar een andere node en daar opgestart.
Hij startte tot het inlogscherm en daarna sloeg ie vast.
Toen begonnen de meldingen weer binnen te stromen, diverse VPS'en onbereikbaar.

Toen weer aan het testen op de nodes via SSH.
ls uitvoeren op de nfs share van de SAN.
Dit ging echt mega traag.

Ik heb ondertussen ook een NFS share aangemaakt op het 1gbit netwerk van de san ipv het 10gbit netwerk.
Dit om uit te sluiten dat het netwerkproblemen zijn. Via de 1gbit ging alles net zo traag.

Zodra ik de VPS waar het probleem mee begonnen is stopte herstelde alles zich weer.
Daarna startte ik deze VM weer en alles ging weer klapperen.
Heb de VM nu terug gemigreerd naar de node waar hij vandaan kwam, opgestart en alles draait tot nu toe perfect.

Ik hoop echt dat iemand met een gouden idee komt waar dit door kan komen...

Ja, ok, als 1 vps hangt omdat ie niet genoeg io kan doen, dan hangen de andere die IO willen op dat moment natuurlijk ook.

Wat voor hardware gebruikt je? Voor zfs heb je namelijk behoorlijk wat nodig om goed te draaien. Ook niks wazigs im je dmsg logs?

Oorspronkelijk geplaatst door systemdeveloper

Ja, ok, als 1 vps hangt omdat ie niet genoeg io kan doen, dan hangen de andere die IO willen op dat moment natuurlijk ook.

Wat voor hardware gebruikt je? Voor zfs heb je namelijk behoorlijk wat nodig om goed te draaien. Ook niks wazigs im je dmsg logs?

In de dmesg van de San komt niks terug, in die van de nodes niets anders dan wat ik al eerder had geplaatst.

SAN Specs:

Xeon E5630
64GB Ram
Perc H200 geflashed naar LSI IT mode

8x SM863 480GB SSD Pool 1
5x SM863 960GB SSD Pool 2
14x 2TB HDD + DC3700 Zil + Samsung L2arc

Intel 10GBIT NIC

Een PERC H200 is wel een redelijk basic adapter voor deze setup. Met die disks zou ik kijken of je een H7x0 kunt vinden voor de servers. Niet dat ik natuurlijk met zekerheid kan zeggen dat het daar aan ligt overigens.

Het vreemde van de situatie die je beschrijft is dat alles traag is tot je de VM terug zet naar de host waar deze vandaag kwam. Dat is niet logisch als het zou komen door veel IO in de VM, dan zou dat meeverhuizen.
Zie je veel MB/s gaan op je storage netwerk via de oorspronkelijke node misschien?

H200 is inderdaad geen geweldige adapter. Wel vaker issues mee gezien. Wij hebben destijds alles vervangen door H710 controllers en het draaide veel smoother en stabieler.

Oorspronkelijk geplaatst door virtuality

Een PERC H200 is wel een redelijk basic adapter voor deze setup. Met die disks zou ik kijken of je een H7x0 kunt vinden voor de servers. Niet dat ik natuurlijk met zekerheid kan zeggen dat het daar aan ligt overigens.

Voor ZFS doet die adapter toch verder niets?
Alles staat in JBOD.
De H7xx kunnen toch geen JBOD?
Dus een snellere kaart heeft met JBOD toch geen zin?

Oorspronkelijk geplaatst door virtuality

Het vreemde van de situatie die je beschrijft is dat alles traag is tot je de VM terug zet naar de host waar deze vandaag kwam. Dat is niet logisch als het zou komen door veel IO in de VM, dan zou dat meeverhuizen.
Zie je veel MB/s gaan op je storage netwerk via de oorspronkelijke node misschien?

Zie het nu ik ga kijken weer en bedenk het me ook net.

Op het moment dat alles instabiel wordt stopt proxmox met logs en grafieken.
Dus op het moment dat het onderuit ligt zit er een wit stuk in de proxmox grafieken...


In sommige gevallen staat er ook bij alle nodes een rood kruisje.
Dat was vandaag echter niet het geval.

Cluster netwerk is overigens een ander netwerk dan het storage netwerk.
Cluster switch is al ooit vervangen en heeft het probleem niet gefixt.

geen grafieken = te hoge IO delay

Zou het kunnen dat je switches / routers / servers het MAC adres vasthouden bij een migratie? Dan krijg je hele rare dingen en aangezien je storage over ethernet loopt, zit dat in dezelfde hoek. Wat zegt "arp"?

Oorspronkelijk geplaatst door t.bloo

geen grafieken = te hoge IO delay

Zou het kunnen dat je switches / routers / servers het MAC adres vasthouden bij een migratie? Dan krijg je hele rare dingen en aangezien je storage over ethernet loopt, zit dat in dezelfde hoek. Wat zegt "arp"?

Dan zou de vm geen netwerk krijgen maar dat maakt de boel niet instabiel..

@tvdh
De grafiek die je laat zien, is dat het verkeer van de Vm of van de host? Je geeft aan dat de hosts een rood kruis laten zien, dat is in de management software? Draait die op een eigen server of op een VM?
Heb je in de monitoring ook Pings naar de nodes en de VMs? Gaan die ook down tijdens dat dit optreed?

Misschien iets dufs... aangezien je dat probleem al zo lang hebt... is het geen structurele configfout ergens die je overal meesleept? Ik zou denken aan een secundair netwerk (voor backups oid) dat een overlappend subnet heeft met je storage of ergens een 'vergeten' dubbel ip. Dan kun je vaak wazige problemen krijgen die pas optreden als ergens een lease/ip/arp vernieuwd wordt. En dan kan dan net zo goed een vm/service/hardware aan de andere kant van het cluster zijn.

Een bond verkeerd en waar 1 lijn van dood is, een setje vm's met een 2de nic verkeerd geconfigureerd, multipaths die minder multi zijn... noem maar op.

Oorspronkelijk geplaatst door systemdeveloper

Misschien iets dufs... aangezien je dat probleem al zo lang hebt... is het geen structurele configfout ergens die je overal meesleept? Ik zou denken aan een secundair netwerk (voor backups oid) dat een overlappend subnet heeft met je storage of ergens een 'vergeten' dubbel ip. Dan kun je vaak wazige problemen krijgen die pas optreden als ergens een lease/ip/arp vernieuwd wordt. En dan kan dan net zo goed een vm/service/hardware aan de andere kant van het cluster zijn.

Een bond verkeerd en waar 1 lijn van dood is, een setje vm's met een 2de nic verkeerd geconfigureerd, multipaths die minder multi zijn... noem maar op.

Zover ik kan zien is dit niet het geval.
We hebben met een paar mensen de hele omgeving doorgelopen en niks geks gezien.
Daarnaast heb ik alles een keer uitgebreid getekend in Visio zodat we een goed beeld hebben. Hierbij ben ik ook niets raars tegen gekomen.

Ik zal wat achtergrond informatie geven, misschien gaat er bij iemand een lampje branden.

- We zijn gestart met een Proxmox 3 cluster. Hierbij een SAN met omnios en napp-it. Bij het migreren van drukkere VM's kon heel het cluster gaan hangen zoals in dit topic beschreven.
We hadden destijds nog een TP-Link 1GBIT storage switch. Dit destijds vervangen door een Cisco omdat we dachten dat het dat misschien was. Maakte geen verschil helaas.

- Hierna een extra cluster opgezet, Proxmox 4 met een nieuwe Omnios napp-it san, over 10GBIT.
Enkele belangrijke VM's zoals drukke webservers hier naar toe over gezet.
In eerste instantie probeerden we dit te doen door het maken van een backup van de VM binnen proxmox en deze terug zetten in de nieuwe omgeving naar de SAN.
Naar lokale storage kunnen we backups zonder problemen terug zetten.
Als we echter een backup terug zetten naar de SAN kakt ook alles in, zelfde probleem als bij een migratie. Is dit misschien een aanwijzing voor wat er mis kan zijn?

We hebben het nu opgelost door nieuwe VM's te maken en het VHD bestand van de oude VM direct op de SAN te kopiëren.
Het komt met name bij deze VM's voor dat het migreren mis gaat (drukke webservers).

Zouden misschien meerdere nodes hetzelfde bestand proberen te benaderen via NFS dat hier iets mis gaat?