CentOS KVM virtual guest diszk IO para

Virtualizáció

Sziasztok!

Van egy KVM clusterem SAN-ra kötve, csodás 500 000 disk IO-t tudnak, a rajtuk lévő egymásról klónozott mysql clusternél pedig van amelyik folyamatosan tud 200 000 körül, és van kettő, amelyik 3-4000-nél 98%-os utilization mellett csak processzor IOwaitet produkál, ahelyett, hogy szépen tenné a dolgát.

A diszkek LVM alapúak cache='none' beállítással. Az összes KVM hoston tuned be van állítva, csakúgy minnt a guesteken virtual-host illetve virtual-guest profillal.

Próbáltam már másik kvm hostra tenni őket, cserélgetni, áttenni másik LUN-ra semmi sem változik az egyik megy, ahogy a nagy könyvben meg van írva, de a másik kettő nem.

Ötletek?

  • 8869 megtekintés

( egeresz | 2013. 01. 24., cs – 23:46 )

diszk blokkhatar igazitas.

diszk - raid - lun - hypervisor particios tabla - lvm - guest particios tabla - guest filesystem

csak egy helyutt is van olyan, hogy az egyik layer 4k blockja a masik layer 4k blokjatol 0.5k blockkal elter, a fenti jelenseget produkalja.

google: kvm block alignment

Azt hiszem, az osszes igazitast befolyasolo layert felsoroltam fentebb.
Az igazitasok lekerdezese nem zavarja az eles mukodest, ezek lekerdezo parancsok.
Alalaban es szinte kizarolagosan a particios tablak szurjak el az igazitast.

Esetleg az LVM 4M blockhatara, ha egy alatta levo layerhez nem illezkedik, pl
raid rendszereknel (nem kettohatvany adatdiszk eseten) a stripesize (adatdiszk szama * chunksize) nem kettohatvany, de ez ritkan okoz ennyire latvanyos lassulast.

Oh, eszembe jutott meg egy tipp. Az LVM snapshot eleg vacak teljesitmenyre. Ne legyen az LVM-en snapshot.

Úgy tűnik, hogy így tényleg gyorsabb lett sokkal, köszi. Amit próbálgatok még, hogy 4096-ra, vagy 512-re állítsam

pvcreate -M2 --dataalignment 512KB /dev/mapper/mpathf
vgcreate -M2 --dataalignment 512KB lvmstore01 /dev/mapper/mpathf

és formázásnál a guesten mindig átállítom az fdisket szektorra méret helyett.

Ilyenkor a scan nem dob errort és valóban legalább 5x gyorsabb, pedig kevesebb diszk van.

A klónozást sem javaslod, vagy csak a snapshotot?

nem tudom, hogy nalad a kvm clone mit takar. ha lvm snapshot alapu, akkor kotelezoen lassu lesz. Ha copy/dd/dump/restore/tar/cpio alapu, akkor az eredmeny fuggetlen lesz az eredetitol, tehat emiatt nem lehet lassu.

az lvm snapshot tipikusan a masodik snapshotnal dobja el a teljesitmenyt, de akkor nagyon.

Nem a kerdesedre valaszolva: mivel az lvm layer nem barrier-proof, emiatt a snapshot nem feltetlen konzisztens. Kifejezetten eros terheles alatt keszitett snapshotban tud lenni metadata serules.
A valamennyire helyes sorrend:
- remount sync
- (xfs_freeze, ha olyan)
- snapshot
- remount async
- snapshot backup
- snapshot drop

A kerdesedre:
az LVM snapshot ket iranyu irhato dolgot keszit. Ezt ugy eri el, hogy az alap irasnal a modosiott block eredetijet atmasolja minden snapshot teruletre. Vagyis n snapshot eseten egy irasi muveletbol 1 olvasas, es n+1 random iras lesz. Ezt megfejelve egy raid1 vagy raid3/4/5/6 rendszerrel, ahol a random iras teljesitmenye rosszabb, mint egyetlen diszke, szoval az eredmeny eleg gaz. A gyakorlatban ez ugy nez ki, hogy egynel tobb snapshot eseten meghal az erosen terhelt szerver. Nyilvanvaloan csak az irasi muveletek szenvednek lassulast, de tapasztalat szerint olyan mindig van. Viszont elvileg lehetseges memoriaba rakni a snapshot teruletet, ekkor felgyorsulhatnak az esemenyek. (nem probalva)

Altalaban nem kifejezetten eros terhelesrol van szo, illetve ahol erre szukseg van, ott ahol iras zajlik, az ignoralva van a mentesbol.

Konkretan arrol van szo, hogy egy xen szerver ala terveznek backupot. Mivel egy elo szerver gyoker diskjet nem illik a hostrol felmountolni, amig a gep maga fut, ezert csinalnek egy lvm snaphotot, lementenem, lemountolnam. Ahova a gyokeren effektiv iras tortenik (/var/run, /var/log, /tmp, /var/cache, stb) azok amugy is ki vannak zarva a mentesbol.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

a PE merete es a felette levo particio eltolasa kozott kell valami kapcsolat? pl a PE size 4M, de a particio kezdodhez 1M-nal? vagy itt mar a PE hatarra kell esnie?
(nalunk egy lv-t lat egy vm mint disk, es arra rakja ra a sajat root +swap particiojat)

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

A PE merete nem befolyasol sokat, mert az LVM nem PE meretben ir. Ebbol a szempontbol az LVM mintha ott se lenne, a filesystem lerak egy random 4k blockot, az atesik az LVM -en, mint 4k irasi keres.

lehet eltolas a raid-nal, hogy a filesystemtol leeseo 4k block az valahogy egyszerre 2 chunkot is modosit.

Lehet eltolas a particional, hogy az underlying layer 4k blockja a prticioonalas miatt nem esik egybe a filesystem 4k blockjaval.

lehet eltolas a particionalas miatt a raid rendszer chunkja tekinteteben is, hogy az nem esik egybe a diszk 4k blockjaval.

Meg ha ezek kello szamu virtualizacioval sokszor egymasra vannak pakolva, akkor sok helyen lehet gond ;)

( blackluck v | 2013. 01. 24., cs – 23:49 )

Elso korben szukiteni kellene a kort, hogy ez storage, kvm, guest-en beluli vagy egyeb problema.
Guest-ek egymasbol klonozottak, de azota sem valtozott rajtuk a konfig, ugyanazokat a feladatokat hajtjak vegre vagy pl egyik slave masik master?
Ki tudod probalni esetleg hogy ugyanazt a tarhelyet ami egyik guest-ben problemas masik rendszerbol elerd (akar jol mukodo guest akar host gep vagy masik gep is akar) es ugy tesztelj rajta, avagy a hibasan mukodo guest-nek adni egy uj szuz tarhelyet pluszba es azon is produkalja-e a jelenseget?

--
Don't Panic if you see me laughing,
that's not a bug, just a feature.

( lorinc | 2013. 01. 24., cs – 23:54 )

Most újra klónoztam 530 000 IO/secen lefutott a klónozás, úgyhogy a storage/KVM host/LUN para kilőve. A guesten belül lehet valami. A klónozott viszont még rosszabb eredményeket produkál, mint az eddigiek.