Proxmox Two-Node High Availability Cluster magas IO

Virtualizáció

Sziasztok,

építettem egy két gépből álló proxmoxos clustert ezen leírás alapján, működik is rendesen, viszont az a problémám, hogy ha létrehozok egy virtuális gépet rajta és arra másolok monjuk, akkor iszonyatosan megnő az iowait azon a virtuális gépen, kb használhatatlan, amíg a másolás be nem fejeződik.

Mindkét szerver Intel(R) Xeon(R) CPU E3-1231 v3 @ 3.40GHz procis 32GB-rammal és 4tb hdd-vel, a két gépet pedig összekötöttük közvetlenül kábellel. Van valakinek ötlete, hogy milyen irányban induljak el, hogy a magas iowait-n csökkentsek?

Azoknak akik szerint gyenge a hdd:

rpool 3,48T 88,7G 96K /rpool
rpool/ROOT 25,3G 88,7G 96K /rpool/ROOT
rpool/ROOT/pve-1 25,3G 88,7G 25,3G /
rpool/data 3,42T 3,38T 134G -
rpool/swap 33,0G 122G 64K -

Így épül fel a rendszer. A data-n van a drbd. Ha nem a data-ra csinálom a vm-t, hanem a localra, ami a root-n helyezkedik el, akkor nincs io probléma. Szóval a rendszeren belül ugyan arra a vinyóra írva az adatot jelentkezik vagy nem a hiba. Ha lassú is a vinyó sokak szerint, az io problémát nem az okozza, mert akkor a local storage-re való íráskor is jelentkezne.

UPDATE:

Újrahúztam a rendszert és leteszteltem két módon. Leállítottam a sync-t a két gép között és először ext4-t raktam a drbd-re, így 25% volt a maximális iowait másolásnál. Ez elég jó úgy gondolom. Utána megcsináltam a tesztet lvm-el is, ekkor 45% volt az iowait. Így is használható marad a vm, viszont a 25% szimpibb, de ha lehet inkább lvm-t használnék. Szóval a kérdésem az, hogy mitől lehet ennyivel nagyobb az io lvm esetén? Vagy reménytelen gyorsítani rajta és maradjak ext4-nél?

  • 3196 megtekintés

Pedig gyenge lesz, foleg ha 1 esetleg 2 disk van raid1 ben.

Nem eleg, hogy folyamatosan irsz rá (VPS), még a hypervisornak is syncelnie kell másik géppel. Szóval csodát ne várjál.

Persze nem tudom milyen I/O policy van esetleg milyen cache mechanizmus, talán ezekkel lehet valamit segiteni rajta.

Fedora 22, Thinkpad x220

másolsz a virtuális gépre. nézzük a jobbik esetet: netről másolsz (letöltesz)
minden letöltött byte akkor lesz kiírva, ha raid1-ben (md) mindkét lemez kiírja.
ha drbd-t is használsz (mindkét gépen md-n) akkor a virtuális géped akkor tekinti kiírtnak a blokkot, ha az
kiírásra került mind a 4 lemezre.

A DRBD működését ilyen mélységben nem ismerem, de szerintem sync esetén a pri-t olvassa és írja a sec-re,
nem pedig úgy történik, hogy egyszerre történik az írás pri és sec gépre is.
Ez ugye eleve duplázza az IO felhasználást.

Akkor szerintem mielőbb megpróbáljuk kitalálni, hogy mi a helyzet nálad, az alábbi dolgokat írd meg:
- A VM-en belül másolsz? (a forrás és a cél azonos block device?)
- IOstat VM-en belül
- IOstat VM-en kívűl
- lemezek száma és típusa a gépben
- raid megvalósítás (md v hwraid, ha igen, milyen)
- külön NIC van-e a DRBD sync-re

A 2db 4TB-os vinyó kevés lesz IO-ban. Ezt végig játszottam korábban. Még a neten is vannak kalkulátorok, amik jó közelítést adnak a géped teljesítményére. Az eredmény több kisebb kapacitásút célszerű összerakni a jobb teljesítmény érdekében. Ha látványos gyorsulást akarsz,akkor pedig egyértelműen SSD.

ZFS - Inkább a stabilitásáról híres, itt inkább sebesség kéne. (+Backup)
Elsőre talán sikerült a legrosszabb kombót összeraknod. :S

a vinyó típusát még mindíg nem adtad meg - bízok benne, hogy inkább WD black, mint green vagy red...
az meg egyértelműen meg fogja adni neked a probléma helyét, ha csinálsz egy másik DRBD volume-t, mount-olod, és
1) írsz rá (dd if=/dev/zero of=testfile bs=1M count=8192)
2) másolsz rajta (dd if=testfile1 of=testfile2 bs=1M count=8192)

Én kérek elnézést.
"In our first workload with a 100% random 4K transfers, we measured 229 IOPS read from the Seagate Constellation ES.3 and 192 IOPS write. This was a steady improvement over both previous-generation models."

bár a ZFS raid-jét nem ismerem, feltételezem hasonló mint az "md", azaz bizonyos mértékig tud (olvasás esetén) IO sharing-et biztosítani, de nem lesz sem az IO sem a thruput kétszer annyi, mint egy lemez esetében. (ellenben egy tisztességes raid vezérlővel, ahol az olvasási sebesség és az IO összeadódik)

Azoknak akik szerint gyenge a hdd:

rpool 3,48T 88,7G 96K /rpool
rpool/ROOT 25,3G 88,7G 96K /rpool/ROOT
rpool/ROOT/pve-1 25,3G 88,7G 25,3G /
rpool/data 3,42T 3,38T 134G -
rpool/swap 33,0G 122G 64K -

Így épül fel a rendszer. A data-n van a drbd. Ha nem a data-ra csinálom a vm-t, hanem a localra, amit a root-n helyezkedik el, akkor nincs io probléma. Szóval a rendszeren belül ugyan arra a vinyóra írva az adatot jelentkezik vagy nem a hiba. Ha lassú is a vinyó sokak szerint, az io problémát nem az okozza, mert akkor a local storage-re való íráskor is jelentkezne.

( gax_colos | 2015. 07. 16., cs – 17:55 )

DRBD -t használod? Ha igen; hogy állítottad be? Azon a rate mennyi?

Külön dedikált kábellel van összekötve a drbd.

global_common.conf:

global { usage-count no; }

common {

syncer { rate 30M; verify-alg md5; }

handlers { out-of-sync "/usr/lib/drbd/notify-out-of-sync.sh root"; }

}

rc0.res
resource r0 {

protocol C;

startup {

wfc-timeout 0;
degr-wfc-timeout 60;
become-primary-on both;

}

handlers {
split-brain "/usr/lib/drbd/notify-split-brain.sh root";

}

net {

cram-hmac-alg sha1;
shared-secret "password";
allow-two-primaries;
after-sb-0pri discard-least-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;

}

on proxmox1rf {

device /dev/drbd0;
disk /dev/rpool/data;
address 192.168.0.1:7788;
meta-disk internal;

}

on proxmox2rf {

device /dev/drbd0;
disk /dev/rpool/data;
address 192.168.0.2:7788;
meta-disk internal;

}

}

cat /proc/drbd

version: 8.3.13 (api:88/proto:86-96)
GIT-hash: xxxxxxxxxxxxxxxx build by root@sighted, 2012-10-09 12:47:51
0: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r-----
ns:80864660 nr:6565544 dw:86389820 dr:9634689 al:21691 bm:112 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

ha raid vezerlon van cache+battery akkor bedobhatsz egy ilyet:
disk {
max-bio-bvecs 1;
no-disk-barrier;
no-disk-flushes;
no-md-flushes;
}

a netet tuningolhatod igy:
net {
sndbuf-size 2M;
no-tcp-cork;
max-buffers 16000;
max-epoch-size 16000;
unplug-watermark 16000;
}

a syncert meg igy:
syncer {
rate 1G;
verify-alg md5;
csums-alg md5;
c-max-rate 1G;
}

es olvasd el a drbd doksiban mi mire jo! es tuningold sajat belatasod szerint.

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

Mindegy mennyi volt, volt nagyobb is, akkor is lassú volt. A hdd lassúságáról meg annyit, hogy ha nem a drbd-n hozom létre a virtuális gépet, hanem a local storage-n, ami egyébként ugyan azon a hdd-n van, mint a drbd-s zfs pool, akkor nem áll fenn ez a probléma. Szóval lépjünk túl a hdd lassúságon, ha lehetséges.

( secretx v | 2015. 07. 16., cs – 18:22 )

Iostat-ot nezted mar?
Ott mit latsz?

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

( wpeople v | 2015. 07. 20., h – 18:28 )

Az update-re írva:
Nem teljesen értem. A DRBD kötetre húznál LVM-et és azon lenne a VM?
Miért nem eleve a DRBD-re teszed a VM-et?

drbd-vel kell shared storaget csinalni, igy mukodni fog a live migracio.
ez felett kell lvm kotet, ezzel tudja a vm-ek ala berakni a disket. (1 lv = 1 disk adott vmnek). drbd pri-pri modban fut, igy mindket node-on lehetnek futo vm-ek. a proxmox sajat cucca gondoskodik arrol hogy adott lv csak az egyik node-on legyen aktiv.

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

( secretx v | 2015. 07. 20., h – 21:58 )

Csendben azert hozzatennem, hogy alaposan teszteld le a ha-t...
Fencing mukodik normalisan 10/10 esetben?
Halozat is ha? (Switch)

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