KVM közös storage io probléma

Virtualizáció

sziasztok

Hoszting cégnél bérlünk viszonylag erős konfigurációt (32 core, sok ram), amire egy külső storage van kötve, 8x3TB 7200 rpm merevlemezekkel RAID 6-ba szervezve. A host gépen egy Debian Squeeze van KVM-el szerelve. Öt VM-et hoztunk létre, négy Debian, egy Windows 2012 Server. Nincs is velük probléma (az io teljesítmény VM-en belül teljesen jó, VM-ek között is), egész addig, amíg valamelyik VM-en nem hajtjuk ki a diszkeket.Példa: ftp kapcsolat, nagy (~100 GB) fájl másolása LAN-on lévő másik szerverről - ez ugye 40+ Mbyte / s-t jelent. Ezt szépen tartja is, csak épp néhány perc elteltével a többi VM teljesen leül, használhatatlanokká válnak. Leállítva a processt, a helyzet azonnal normalizálódik.

Próbálkoztunk VM szinten nice, ionice parancsokkal, de egyrészt nem oldották meg a problémát, másrészt nem gondoljuk hogy itt kellene ezt szabályozni.

A kérdésem az lenne, hogy a KVM szintjén milyen lehetőségek vannak az i/o sáv korlátozására? Egyáltalán megoldható-e? Deadline ütemező használata megoldást jelenthet-e erre a problémára? Azt sajnos még nem sikerült kideríteni, pontosan milyen összeköttetés van a szerver és a storage között, de ez számít-e vajon? Vagy a raid 6 lehet a ludas?

Minden linuxon Virtio drivereket használunk, Windows Serveren sima IDE-t, mert Virtio-val használva az Eszközkezelőben egy frissítésre kattintva fixen le lehetett fagyasztani az oprendszert (USB-s eszközként látta az SCSI drivert - gondolom ezért). De mint írtam, a diszkek teljesítménye VM-en belül jó, csak épp (ezt feltételezzük) a közös storage miatt elveszik egymástól a sávot.

előre is köszi,
aboy

  • 10294 megtekintés

( secretx v | 2013. 07. 04., cs – 14:11 )

lehet limitálni: http://wiki.qemu.org/Features/DiskIOLimits/Requirements
De érdemes azért kideríteni, mi a gyenge láncszem a történetben..
Milyen technológián van kiadva a storage a hostnak (issci, nfs, stb)?

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

nos, közben kiderült (nem én intéztem a dolgot), hogy nem is külső storage-ben vannak a diszkek, hanem ez egy Supermicro CSE-826E16-R500LPB 2U magas szerver és ebbe vannak rakva, tehát ez közvetlen SATA (pci) csatlakozást jelent. Ilyen esetben mit lehet tenni? Nem kellene ennek azért jobban bírnia a terhelést? A qemu linket megnézzük, köszi!

szia igen, top és htop

A képen látható pillanatban a db0 nevű vm-re sftp-ztem egy lan-on lévő (de fizikailag különálló) gépről egy nagy fájlt, kb 35-40 mbyte/s-el). Kb 10 percig 10 alatt marad a load, majd felugrik 20 fölé. 15-ös load-ig még egész jól bírja a többi vm, de 20 felett megnyekkennek. Sftp leállítása után egy percen belül normalizálódik a helyzet.

Közben még valami eszembe jutott: számít-e hogy milyen raid controller van a szerverben? (amúgy lspci szerint LSI Megaraid, nehéz infót kicsikarni a hoszting cégtől)

Hello,

na, mondom a tutit :)
Szóval:
- probléma 1.: SATA vinyók...
- probléma 2.: nem megállapítható RAID vezérlő: sajnos az LSI megaraidnek is van olyan verziója, ami fake raid, gyanítom itt van a probléma gyökere, illetve ez és a nem SAS, vagy legalább NL-SAS vinyók (full SCSI command set, párhuzamos kommunikációs csatorna, többek között)
- probléma 3.: raid 6.: RAID10-ben jobb lenne, gyanítom a tárterület maximalizálása volt a cél
- probléma 4.: még, ha gyenge is a "raid" vezérlő, lehetséges, hogy letiltja a szokásoknak megfelelően a merevlemezek saját cachét. Raid kártya Cache és BBU nélkül persze nagy gond lehet, ha összeomlik a rendszer.

nem véletlen, hogy a VMWare például nem támogat szoftver raidet, illetve a minőségi hw raidet támogatja. A RAID6 miatt ugyanakkor sokkal több művelet van, mint akár egy RAID1-nél.
Az a rossz hírem, hogy ez sokkal jobb nem lehet, csak HW cserével.

üdv,
Ago

Ez konkrétan egy elég jó kártya. Firmware verzió? Néha szokott segíteni. Meg a kernel modul, vagy ezek kombója tud érdekes jelenségeket produkálni. Van egy olyan érzésem, hogy a kártya teljes sávszélessége eloszlik az összes vinyó között + a mechanika ördöge is benne van.

( cstamas | 2013. 07. 04., cs – 14:21 )

Itt a baj:

8x3TB 7200 rpm merevlemezekkel RAID 6

igazából ha elfogy az a kevés IO teljesítmény, ami rendelkezésre áll, akkor nincs mit tenni.

12x2T 7200RPM (sima desktop HDD-k, HW RAID6): linearis atvitelnel a 3G-s backplane korlatoz (4x3G, 1-1.1GBps siman megvan a tomb elejen), onmagara gond nelkul masol 300-500MBps sebesseggel, itt meg -- igaz kevesebb vinyoval, de hasonlo kornyezetben -- 40MBps-ekrol beszelunk... (es szinten kb. linearis atvitelrol (100GB meretu file masolasa))
Nem hinnem, hogy az IO teljesitmennyel van a gond.

+1. RAID6 esetén rohadt drága művelet az írás (ha perverz módon szoftveres raid, akkor pláne), elsősorban i/o-ban. Ráadásul nagyon nagyok a diszkek, tehát kevéssé van a terhelés szétszórva a lemezek között. Ekkora diszkeknél persze a raid10 eléggé lutri - de legalább gyors tud lenni... (Azért lutri, mert ha 1+1 diszk hal meg egy raid10 tömbből, akkor Murphy szerint párban teszik...)

( _ventura_ v | 2013. 07. 04., cs – 15:18 )

A régebbi KVM-ek I/O teljesítménye elég gyatra volt, állítólag 1.x től jobb lett, viszont Squeeze ben régi van. Alapban 0.12-es verzió. Próbáld meg felrakni backportsból az 1.1 est.

Fedora 19, Thinkpad x61s

( STP | 2013. 07. 06., szo – 18:05 )

RAID6 gond. RAID10 jobb lenne.
Raid vezérlőn RAM? BCC? Policy?
Host szinten mit nyom a cucc diszk random read/write-ban?
Win-es VirtIO driver verzió száma?

nyilván nem a kattintással történő leválasztás aggasztó (bár..), mi inkább attól tartottunk, hogy ha az Eszközkezelőben a sima Refresh BSOD-t okoz, akkor ezt később már éles üzemben akár egy nyomtató vagy más driver telepítése is előidézheti, ki tudja mi történik a háttérben..

( dblaci | 2013. 07. 07., v – 10:31 )

Ha már fölmerült, én kiváncsi lennék, hogy a deadline schedulerrel más e a helyzet, én azt szoktam váalsztani mindig, és elvileg a párhuzamos ionál ott igazságosabban van elosztva, mint a cfqnál.

( aboy v | 2013. 07. 08., h – 09:17 )

köszönöm mindenkinek az eddigi hozzászólásokat!

( aboy v | 2013. 08. 07., sze – 08:37 )

Csak hogy részemről valami lezárás féle is legyen ezen a szálon, úgy néz ki sikerült megoldani, vagy legalábbis nagyot javítani a helyzeten azzal, hogy a rendszergazdánk noop schedulert állított be a kvm hoston (valahol olvastuk hogy hardver raid esetén jó választás lehet) illetve hogy a vm-eken default helyett writeback cache módot és native io módot választott (gyanítom ez utóbbi volt a fontosabb). Azóta szinte egyáltalán nem tapasztaltunk io miatti lassulást. Köszi a segítséget mégegyszer.