Bekijk Volledige Versie : Proxmox - High load bij move
Misschien dat iemand hier al eens een gelijkaardig probleem heeft gehad...
Momenteel zijn wij bezig met het migreren van onze proxmox omgeving naar nieuwe nodes.. Daarbij moeten er wat disken van links naar rechts verschoven worden maar hier loopt het fout..
Momenteel staat de disk op ISCSI storage en deze moet naar nieuwe ZFS pools gemoved worden, omdat de nieuwe ZFS pools niet beschikbaar zijn op de oude nodes en de ISCSIs niet op de nieuwe hebben we een temp storage geimplementeerd in de vorm van een NFS share.
Migratie verloopt als volgt:
1. Migrate disk van ISCSi > NFS
2. Migrate vm van oude naar nieuwe omgeving en start daar op vanaf NFS share
3. Migrate disk van NFS > ZFS
Het probleem ontstaat bij stap 3, vanaf het moment we de disk terug willen migreren vanaf de NFS share naar de ZFS pool dan loopt het mis, dan loopt de load op de VM instant op van 0 naar oneindig, wordt het systeem unresponsive en shieten de pings ook meteen naar 4-5000 ms..
Initieel dachtten we dat het aan de ZFS setup lag dus hebben we in plaats van ZFS datzelfde ook eens geprobeerd met LVM-thin , maar ook daar ontstaat hetzelfde probleem..
Heb al geprobeerd om te switchen tussen thin/tick , op zfs niveau de block size al eens verzet van de default 8k naar 4k en 32k maar allemaal zonder veel resultaat..
Het probleem is hier wat identiek beschreven en dat lijkt een 'bug' te zijn al een paar jaar..
https://forum.proxmox.com/threads/kvm-guests-freeze-hung-tasks-during-backup-restore-migrate.34362/
Iemand enig idee ? We moeten zo een hele boel vms moven en het zou online moeten gebeuren (machines met meer dan 2TB aan storage etc..)
Thanks !
cyberbootje
07/12/18, 00:20
Zelf ook soortgelijke issue gehad, niet met proxmox maar wel met zfs als zvol.
In je proxmox topic las ik vluchtig dat je dat gebruikt. Issue is als volgt, als je KVM op zfs gebruikt (ZVOL, dus niet raw als bestand) dan is de load en cpu erg hoog op de host node wanneer er wat IO gedaan wordt. Dat effect is een heel stuk minder als je een raw bestand gebruikt op een mounted ZFS volume maar het is NIET weg. In mijn optiek is ZOL nog steeds niet productie waardig voor echte flinke performance als je een grote setup hebt.
Ow en mocht je qcow op zfs willen doen, NIET DOEN, de meest gekke dingen ga je tegen komen in die combinatie.
Maargoed, probleem is er ook met lvm etc... Loopt dit via een (intern)netwerk ?
Specs van dit netwerk? Netwerk al benchmarked en tresstest gedaan?
Zelf ook soortgelijke issue gehad, niet met proxmox maar wel met zfs als zvol.
In je proxmox topic las ik vluchtig dat je dat gebruikt. Issue is als volgt, als je KVM op zfs gebruikt (ZVOL, dus niet raw als bestand) dan is de load en cpu erg hoog op de host node wanneer er wat IO gedaan wordt. Dat effect is een heel stuk minder als je een raw bestand gebruikt op een mounted ZFS volume maar het is NIET weg. In mijn optiek is ZOL nog steeds niet productie waardig voor echte flinke performance als je een grote setup hebt.
Ow en mocht je qcow op zfs willen doen, NIET DOEN, de meest gekke dingen ga je tegen komen in die combinatie.
Maargoed, probleem is er ook met lvm etc... Loopt dit via een (intern)netwerk ?
Specs van dit netwerk? Netwerk al benchmarked en tresstest gedaan?
Het probleem doet zich ook voor op een standaard lvm. Lijkt me eerder iets kernel achtig te zijn .
Yourwebhoster
07/12/18, 10:25
Ik weet niet of het een vergelijkbare situatie is, maar in een testopstelling heb ik wel vaker meegemaakt dat Proxmox zichzelf vast zette als er meerdere disk migraties werden uitgevoerd (maakt niet uit of het gelijktijdig of achter elkaar gebeurde). Dit was van ceph -> NFS -> ceph. Daarbij viel op dat de verbinding met de NFS server niet altijd stabiel was. Hierbij moet ik wel opmerken dat een Synology hier voor was ingezet en deze apparaten zijn een afrader voor storage van virtualisatie doeleinden: ze klappen er wel eens uit met iSCSI en NFS. Je zou verwachten dat met specifieke virtualisatie ondersteuning dat iSCSI ook stabiel zou werken; maar niet dus (https://www.synology.com/en-global/dsm/feature/storage_virtualization). Ik zou dus niet NFS als oorzaak uitsluiten. Daarbij is het ook goed om netwerk even goed te doortesten (vooral ook langdurig).
Wat ik je verder kan aanraden (maar lijkt mij voor zichzelf sprekend) is om niet meer dan één migratie gelijktijdig uit te voeren.
cyberbootje
07/12/18, 10:32
Het probleem doet zich ook voor op een standaard lvm. Lijkt me eerder iets kernel achtig te zijn .
Zie 2e stukje, check je netwerk.
Wat voor switches gebruik je? 10G? Glas? Merk?
Is het niet mogelijk dat het te maken heeft met performance van NFS? Dat stap 3 zwaarder voor je NFS is omdat je nieuwe ZFS beter performed en dat je IO Delay voor je VM enorm verhoogt?
Je kunt tegenwoordig in Proxmox op sommige plekken de bandbreedte van de disk actie limiteren. Als het goed is ingesteld dan kan ZFS / ZOL een goede performance halen, en dan zie je de volgende bottle neck die hier wel eens je netwerk zou kunnen zijn. Dus probeer de through put wat lager te houden en je zou "lucht" op het systeem voor andere zaken over moeten houden. Proxmox doet ook nog vanalles met je cluster ondertussen ook als het "niks" staat te doen.
mgielissen
07/12/18, 12:50
Je kunt tegenwoordig in Proxmox op sommige plekken de bandbreedte van de disk actie limiteren. Als het goed is ingesteld dan kan ZFS / ZOL een goede performance halen, en dan zie je de volgende bottle neck die hier wel eens je netwerk zou kunnen zijn. Dus probeer de through put wat lager te houden en je zou "lucht" op het systeem voor andere zaken over moeten houden. Proxmox doet ook nog vanalles met je cluster ondertussen ook als het "niks" staat te doen.
Disk limieten gelden alleen voor de KVM guests, move gebruikt de volle bandbreedte zeg maar. Een backup/restore kun je met de nieuwe proxmox versie wel limiteren kwa bandbreedte.
Wij hebben soortgelijke problemen ook gehad met Proxmox. Echter na jaren nooit definitief op kunnen lossen. In datacenter.cfg kun je het e.e.a. limiteren kwa snelheid voor migraties etc. Wellicht helpt dit.
Frijswijk01
10/12/18, 13:41
Niet dat je hier verder me komt maar ik lees NFS en ik krijg de rillingen over mijn rug. Daarover zoveel data pompen is nooit echt stabiel geweest dus het zo zou maar kunnen dat daar de bottleneck zit. Ik kan me ook voorstellen dat je denkt dat niet het geval is.
Niet dat je hier verder me komt maar ik lees NFS en ik krijg de rillingen over mijn rug. Daarover zoveel data pompen is nooit echt stabiel geweest dus het zo zou maar kunnen dat daar de bottleneck zit. Ik kan me ook voorstellen dat je denkt dat niet het geval is.
Ik "pomp" continue 10 Gbps data over NFS en dat is super stabiel. Over de snelheid van NFS t.o.v. bijvoorbeeld iSCSI valt te discussiëren, maar dat hangt er vooral vanaf of je veel kleine files hebt of niet.
Frijswijk01
10/12/18, 14:38
Ik "pomp" continue 10 Gbps data over NFS en dat is super stabiel. Over de snelheid van NFS t.o.v. bijvoorbeeld iSCSI valt te discussiëren, maar dat hangt er vooral vanaf of je veel kleine files hebt of niet.
Ja maar daar gaat het dus om. In de ene configuratie werkt het goed maar in de andere... Ik zou het iig niet uitsluiten als probleem in dit verhaal.
CharlieRoot
12/12/18, 09:02
Ik zie te weinig informatie over je setup (netwerk, switches, etc) maar ik zou eens kijken naar je statistieken op de poorten. Het kan zo zijn dat je de NFS bak omver trekt door de leesacties. Ik heb wel vaker gezien dat met een move de hele 10g poort vol zat en de boel daardoor omviel. Als het glas is, check ook je SFP's op (CRC/Drop) errors na en je MTU settings.