KVM (Proxmox) - Win2008R2 VirtIO magas IOWait, alacsony performancia

 ( quash | 2019. május 8., szerda - 11:37 )

Sziasztok,

Adott egy Proxmox Cluster, Dell PE520, PE720 gépekkel vegyesen.
A clusteren Windows és Linux VM-ek futnak, mindenki KVM alatt.

Adott egy Windows 2011 SBS szerver, örökölt, jelenleg nem lecserélhető, hogy miért SBS ebbe ne menjünk bele, ez van ezzel fözünk ....
kb. 2 hete migráltuk vmware alól, a migráció után ~1 héttel jöttek a felhasználói panaszok hogy lassú az outlook, szakadozik etc ...

SBS alatt fizikailag egy PE520 van, 2xE5645-el (24 szál), 64 Gb RAM-al, és 12x1Tb NLSAS HDD-vel RaidZ2-ben.
Ebből SBS meg is kap 32Gb RAM-ot, és 16 szálat.
Windows Virtio-n keresztül kapja meg a diszket, Write Back cache-el, próbáltuk már +IO thread-el is.

A fenti konfiggal SBS-nek brutálisan rossz az IO-ja, konkrétan lagzik az egész, Event Log tele van viostor eseményekkel.
A host gépen futó más OS-ok ilyet nem produkálnak, de windows 2008R2-ből másik gép nincsen HDD-s gépen.
Ugyan ilyen hardveren, ugyan ez a konfig, csak másik gépen fut 2012R2 Terminál szerverként, másik VM SQL szerverként, semmi gond nincsen velük.
SSD-s hardveren KVM alatt fut 2008 R2-n Terminál Szerver 2008 R2 alapon, ~25 felhasználóval, ott sincsen IO gond. (oké 5x500gb SSD, de ekkora különbség nincsen azért).

ZFS-en semmilyen extra dolog nincsen bepacsolva, compress, dedup, minden off, zfs_arc_max minden gépen 8Gb-ra van korlátozva hogy ne egye meg VM-ek elől a memóriát.
A gépekben H700 és H710-es RAID kártya van, H700 még nem tud JBOD-ot gyári Dell firmware-el, ezért minden HDD RAID0-ban van.

SBS alatt már próbáltunk több virtio verziót is, érdemi különbség nem volt.

Egyetleg furcsaság amit kiemelnék:

SBS HDD 500Gb, ehhez képest ZFS-en:
NAME USED AVAIL REFER MOUNTPOINT
rpool/data/vm-111-disk-1 1.11T 6.83T 1.11T -

1.11 Tb-ot foglal el!, ez vmware migráció után már így jött át.

Találkozott már valaki hasonló problémával, bármilyen 5let ?

Ha lehet ne menjünk el abba az irányba hogy miért nem vmware, etc ...!

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Jól értem, hogy RAID0 van a ZFS mögött? Ha igen, akkor az nem túl szerencsés.

Nekem egyszer volt olyan tapasztalatom hogy a Raid kártya BBU aksija meghibásodott és átkapcsolt WB-ről WT-re és az IO lesett használhatatlanra -elsősorban Windows-ok haldokoltak, de érezhető volt Linux-okon is.

dstat -ban látszik valami cpu wait a host-on?

egyesével van kamu raid0-ban, az nem gond.
--
Gábriel Ákos

Igen, ahogy írtam is RAID kártya nem tud JBOD-ot, innentől csak úgy tudsz nativ ZFS-t használni, ha minden lemezből egy RAID0 tömböt készítesz.
Tehát 12db 1 lemezesRAID0-ról beszélünk.

Persze az sem igaz hogy RAID kártya nem tud JBOD-ot, mert ha Dell Perc firmware helyett, LSI firmware-t kapna, akkor tudna, de ez unofficial megoldás.

zfs list -t snapshot? Nem úgy hoztátok át és nem az eszi a helyet?
zfs-el volt egy már lassú topic itt:
https://hup.hu/node/160073
A lényeg a BIOSban átrakni ezt:
SATA mode - Legacy
Ezt rakjuk át AHCI-re!

Nézd meg ki írta a linkelt topic-ot ! :)

RAID kártyán nincsen legacy, AHCI mód!

Snapshot nincsen jelenleg a VM-en, migráció előtt a vmdk-ek is fragmentálva lettek, hogy csak a ténylegesen használt adatok kerüljenek át.

Ex has tipp: szerintem a diszk alrendszered IOPS tudása gyatra, és ezt az Exchange nagyon nem tolerálja.

5x500gb SSD, de ekkora különbség nincsen azért

De. Egy SSD meg egy HDD között nagyságrendi különbség van IOPS terén. Simán lehet akár 100-szor gyorsabb az SSD...

Azt hiszem kihagytam egy fontos információt vmware->proxmox migráció után a hardware nem változott.
A migrált gépről lemásoltuk a vmdk-kat, újratelepít, import, windows driverek, és ennyi.

12db 1TB NLSAS lemez kvázi RAID6-ban azért elég kell hogy legyen egy kb. 50 useres exchange-nek, ami egy komplett SBS-el együtt elfér 500Gb-os partición.
Ahogy írtam, csak ezzel az SBS-el van performancia probléma, ezen a gépen fut 2012R2, másik úgyan ilyen hardveren 2012R2 ami terminálszerver, tehát ott is van azért IO, 2016, azokkal semmi gond nincsen.
SSD viszonyitást jobb lett volna ha nem írom, félrevezető.

compress-t szerintem kapcsold be. attól csak kevesebb lesz a diszkművelet.
zil-t (slog-ot) kapcsoltál? az kéne, baromi sokat segít.
akár pár tengelyre rátenném mirrorozva akár egy plusz ssd-vel sokat tud dobni a dolgon nagyon.

--
Gábriel Ákos

Az első hasznos tanács! :)

Az migráció elején minden VM-et compress=lzj4-el hoztunk át, kis CPU használat, helymegtakarítás.
Amikor SBS problémák jelentkeztek, 4-5 kisérlet volt compress kikapcsolása (VM export -> import-al!).
A két állapot között nincsen mérhető/érezhető különbség.

ZIL nincsen, sajnos PE520 2U és LFF HDD-ket fogad, 12 db HDD-vel full tele van, nem tudunk bele cache-t rakni.
1 SSD azért lutri lenne, legalább kettő kellene mirrorban.
A héten rakunk még a gépbe 16Gb RAM-ot, és annyival növeljük zfs_arc_max méretét, lehet hogy a 8Gb kevés ekkora ZFS tömbnek.

HHHL card? bar 2 belole kozeliteni fogja a szervered erteket.

Egy M2->PCIE átalakító is tud hasonlót, abból kettőt simán be lehet tenni a gépbe, M2-vel együtt 2x14e ft kb.

De most várunk, elvileg most jó.

Ah, tényleg. Abba meg beleraktok Samsung 970Pro-ból kettőt és kánaán fillérekből.
Vagy persze vannak az Intel SSD-k ha már enterprise.

--
Gábriel Ákos

tudja a pocs, en DC500-at raknek bele.... (most szopok vele hogy a HBA nem birja kiolvasni az enterprise attirbutumokat a 960pro -bol mert consumer, igy vonyit az omsa ra - holott minden gyonyoru zold.... (H730/H330 hegyeim vannak, dell szopjonlovat - 2 tele rack r740 )

Ez sajnos az összes újabb dell RAID kártyával igy van.
A régi Perc5, Perc6 még simán ment bármilyen lemezzel.

Az újabb Hxxx kártyák is mennek kb. mindennel, de nehéz őket lebeszélni hogy nemtetszésűket kifejezzék.
Nagios + check_openmanage azért megoldja.

az omsa -t le lehet beszelni hogy szoljon erte, viszont az snmp check visszabillenti warn allapota.... (hovewer minden zold...)

Tegnap éjjel annyit még megpróbáltunk hogy Virtio drivereket a legujabb 2019.03 havira cseréltük, ez nem stable ág, de próba szerencse.
Ma még nem volt SBS event logban virtiohoz köthető hiba, illetve lassú irás bejegyzés sem.

Az userek azt jelezték vissza délután hogy ma teljesen rendben volt Exchange.

Ebben az az érdekes hogy az összes többi VM-en stable ágban lévő 2017-es driver van, és ott még sincsen gond.

virtio scsi? egy próbát megér

ha van lehetőség valami recovery linux és disk perf tesztre, hátha valami elvetemült config probléma (mármint a vps-ben)

nekem is van egy olyan tapasztalatom (bár Linux esetén), hogy a virtio disk nem tudja az fstrim-et, így ha backupolod akkor a szemetet (törölt fájlok) is backuppolod...

Proxmox forumon azt javasolták, hogy virtio scsi adapter legyen (options-ban a scsi adapter) és a disk pedig simán scsi. Feltétele, hogy a Guest oprendszer támogassa a Virtio SCSI adapter-t.

Azt nem tudom hogy milyen performancia különbség van, de nekem mintha gyorsabb lenne így érzésre. Arra kell figyelni, hogy ilyenkor nem /dev/vdX hanem /dev/sdX a disk neve és megy az fstrim is :-). Közben ugyan úgy virtio képességgel bír

Ha valaki át akarja állítani egy már telepített rendszeren akkor azzal kell számolni, hogy előtte győződjön meg, hogy UUID-vel/megfeleő disknévvel bootol a grub, mert könnyen meglepetés lehet :-)

Annyi kell az átállításhoz, hogy optino-nál virtio scsi, majd törölni kell a Hardware / Hard disk(ek)et (az adatot nem törli ilyenkor, csak leválasztja), majd utána újra hozzáadni az unused disket immáron SCSI-ként ugyan abban a sorrendben.

Valamit nagyon félrenézel, az fstrim arra szolgál, hogy a törölt fájlok szektorai a disken is üresnek legyenek jelölve, nem backuplsz semmilyen szemetet.

Thin provisioning, vagy SSD-nél kell ilyen, hogy az alatta lévő eszköz tudja,hogy ezekeket a szektorokat fel lehet szabaditani.

szerintem egyről beszélünk... pont azért kell az fstrim, hogy 0-ra állítsa a már törölt állományok szektor foglalását, hogy a backupnál a tömörítés során kisebb helyfoglalása legyen.

miert, te block deviceot backupolz?

Szia!

1., KVM/Proxmox:

Windows-hoz ezek a beállítások kellenek:

Proxmox GUI/VM/Hardware:
sata0: /disk/helye/vmxxx-1.qcow2
sata1: /disk/helye/vmxxx-2.qcow2
Network Device(net0) e1000=...
Network Device(net1) e1000=...

Proxmox GUI/VM/OPTIONS:
OS Type: Other OS types(other)
Use local time for RTC:yes
SCSI Controller Type: Default(LSI53C895A)

AMIT NE:
Virtio eszköz típust ne használj Windows alatt semmihez sem! ( pl.: DISK és NIC).
Semmilyen Virtio/Qemu drivert ne rakjál fel:
"https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio"

Mivel teljesen bugos és használhatatlan lesz tőle a Windows, pl.: eldobja a diszket majd felugrál a buborék hogy új hardver - és ezt végtelen ciklusban - egyéb rejtett hibák.

A fenti beálításokkal "stabilan" fog működni, tapasztalat.

2., ZFS

O_DIRECT támogatás nincsen ZFS alatt, ezért rossz a DISK_IO.
Nem tudom,hogy a backup miatt akartok-e ZFS-t használni, de EXT4 -re kellene rakni a VM-ek qcow2 fájlokat, akkor nem lesz lassú.

(ext4 defaults,acl,barrier=0,nodiscard,errors=remount-ro 0 1)

3., EGYÉB:
Egy kis trükkel megoldható a ZFS és az O_DIRECT:

topológia:
#mdadm
#lvm
EXT4
sparse-file
loopdev
zpool
zfs-dataset
EXT4
mount
VM.image

1., storage formázása EXT4-re
2., mountolod pl.: /zfsdisks/disk1
3., sparse-file
dd if=/dev/zero of=/zfsdisks/disk1/disk1-1600G.zfs bs=1 count=0 seek=1600G
3., loopdev
losetup -f (/dev/loop0)
losetup /dev/loop0 /zfsdisks/disk1/disk1-1600G.zfs
4., ZPOOL
5., zpool create -f -o ashift=12 zfspool1 /dev/loop0
zfs set mountpoint=none zfspool1
zfs set compression=lz4 zfspool1
zfs set dedup=off zfspool1
6., ZFS Dataset
zfs create -s -V 1500G zfspool1/data
zfs set compression=lz4 zfspool1/data
zfs set dedup=off zfspool1/data
7., EXT4 létrehozása
parted -s /dev/zvol/zfspool1/data mklabel gpt
parted -s /dev/zvol/zfspool1/data mkpart primary 0% 100%
mkfs.ext4 /dev/zvol/zfspool1/data-part1 -L zfsdata1 -E lazy_itable_init=0,lazy_journal_init=0
8., MOUNT
mount -t ext4 /dev/zvol/zfspool1/data /zfsmounts/zfsdisk1 -o defaults,acl,barrier=0,nodiscard,errors=remount-ro

9., Arra figyelni kell, hogy ne legyen "over provisioned" azaz több diszket addsz ki mint amennyi helyed van, mert ez teleírja a diszk-et, hiába törölsz fizikailag nem fog csökkeni a sparse file mérete ami a VM image-ket tartalmazza.

10., Irsz egy scriptet ami felmountolja a sparse-file-t a ZFS-nek, amiről bemontolod az EXT4-et, majd azon vannak qcow2 fájlok, így lesz O_DIRECT és lesz ZFS is (snapshot). :)

----------------------------------
#!/bin/bash

VM_LOOPDEV=$(losetup -f)
VM_ZFSDISK="/dev/zvol/zfsdisk1/data-part1"
VM_ZFSMOUNT="/zfsmounts/zfsdisk1"
VM_ZFSMOUNT_OPT="ext4 defaults,acl,barrier=0,nodiscard,errors=remount-ro"
VM_ZFSFILE="/var/lib/vz/zfsdisks/zfsdisk1-1600G.zfs"
VM_COMMAND=""

VM_COMMAND=$(losetup ${VM_LOOPDEV} ${VM_ZFSFILE})
VM_COMMAND=$(rmmode zfs)
VM_COMMAND=$(modprobe zfs)
VM_COMMAND=$(zfs import)
VM_COMMAND=$(mount -t ext4 ${VM_ZFSDISK} ${VM_ZFSMOUNT} ${VM_ZFSMOUNT_OPT})

exit 0
----------------------------------

Soha semmi problémánk nem volt virtIO eszközzel sem 2008R2 sem 2012 alatt, de a Win 7 és 10 is hiba nélkül megy, ha kell :)

Szia!

Én belefutottam egy igen kemény bug-ba annakidején:

Windows 2012 R2,virtio driverek,virtio disk: NTFS
-VSS snapshot (Volume Shadow Copy).
Snapshot közben eltűnik a diszk, majd megjelenik a buborék hogy új hardver, és ezt minden alkalommal, amikor ment a vssadmin.

+1

Már nem emléxem pontosan de mintha LV-ken futtattam volna vm-eket (és nem qcow-ban).

--
Gábriel Ákos

Köszi a részletes leírást.
Egyetlen fontos információt figyelmen kívül hagysz.
Csak SBS alatt van/volt performancia probléma!, ez egy 5 gépes proxmox cluster, amiből 3 gép tök egyforma (2xE5645, 64 v. 128Gb RAM, 12x1Tb NLSAS HDD, H700).
Az összes többi windows VM 2012 v. magasabb verzió. Ezekkel semmi gond nincsen!
Tehát ez miatt ZFS-t azért olyan gyorsan nem írnám le!

Pont ZFS adta lehetőségek miatt állunk át nagyon sok helyen Proxmox-ra.
Linux + LXC kontérben futattot gépek kezelhetőségét, könyedségét máshol nem kapod meg.
Windows VM-ek folyamatos replikációja, és mentési lehetőségeit sem. Naponta, hetente 1x leállítod a VM-et (ez amúgy is kell windowsnak), a leállításkor tolsz egy snapshotot, a VM-et elindítod, a snapshotot meg ütemezetten backupolod. És egy full-os offline backupod van. VM-enként max 10 perces leállással.
A VM replikáció is jól működik, persze SQL, DC, és hasonlóknál nem erre építesz, de nagyon jó.

És mindez ingyen, vagy ha megveszed, akkor is nevetséges áron.
Nem kell hozzá mindenféle vmware-es licenc, külön szoftver, etc, nativan, magában tudja.

Ahogy már tegnap írtam, a legújabb virtio telepítse úgy néz ki megoldott a problémát, az userek már nem panaszkodnak.
Mérni nem mértük, majd 7végén ha nem használják, de valószínűleg ez volt a gond.

Amit továbbra sem értünk az importált vmdk 2x helyfoglalása.

valami nagyon nemjol van ott. win7, "Statisztika 2019.03.27. 22:29:56 óta" fut a gep, tok hibatlanul megy virtioval (belul lsi raid1+lvm van)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Igen, valami nem jól van, erre keressük a megoldást! :)

De már többször is írtam, egyetlen VM-el van(volt) probléma!

Az egyetlen windows 7-en kívül futtatok még más windows-t is KVM alatt ?

a kolleganak irtam aki szerint windows alatt semmilyen virtiot ne hasznaljunk mert szerinte szar. nemszar. en csak egy win7-et futtatok sok mas vm mellett (egyszer volt parszor win2k8, de azt se ereztek lassunak virtioval), ssd ofc. ha nalad csak egy vm csinalja akkor ott a vmmel van gond, nem hiszem hogy a zfs lenne a hiba. en megprobalnam clean installal (hatha valami megzavarodott az adott windows lelkivilagaban), vagy ha frisebb win serverrel jo, akkor migralnek arra (gozom nincs lehet-e siman lecserelni a meglevot)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Én SSD-t raktam alá és megszűntek a gondok, de jó tudni hogy ZFS/O_DIRECT miatt nem volt jó, erről nem találtam semmit proxmox fórumon se. (+subscribe)