Cluster fájlrendszerek helyzete 2016-ban (ocfs2 gfs)

Ubuntu Linux

Sziasztok!

Egy 2 node-os kvm cluster-t szeretnénk építeni live vm migrációval. Ehhez vagy gfs vagy ocfs2 fájlrendszert használnánk, de nincs vele tapasztalatunk. Az interneten mindenféle véleményt lehet találni, de főleg régebbieket. Több helyen olvastam, hogy a történet vége az lett, hogy átálltak nfs-re. Az operációs rendszer valószínűleg Ubuntu 16.04 lesz.
Mi most 2016-ban a helyzet a cluster fájlrendszerekkel? Mennyire stabilak?

  • 3194 megtekintés

( uid_6201 v | 2016. 10. 22., szo – 15:58 )

Ha már OCFS, a tempójával kapcsolatban nekem is van kérdésem.
Konfig: 2 darab szerver, 1 switchen keresztül gigaethernettel összekötve.
Bennük KVM felett futó Debian-7, köztük DRBD + ocfs2.

Jó tartalékolás ad kiszolgálásra, olvasásra elfogadható, de fájl létrehozásra és főként törlésre nem vagyok vele elégedett.

Példaként alább a http://kernel.org -ról lerántott kernel forráskóddal mérhető idők ext4 és 2 node-os OCFS esetén:

ext4 tesztek a KVM felett futó szerveren:

PC1-ext4~$ time (tar xf linux-4.8.4.tar.xz; sync)
real 0m15.340s
user 0m8.361s
sys 0m2.364s

PC1-ext4~$ time ls -lR linux-4.8.4 | wc -l
70341
real 0m0.557s
user 0m0.204s
sys 0m0.352s

PC1-ext4~$ time du -sh linux-4.8.4
753M linux-4.8.4
real 0m0.190s
user 0m0.024s
sys 0m0.092s

PC1-ext4~$ time (rm -rf linux-4.8.4; sync)
real 0m1.174s
user 0m0.028s
sys 0m0.908s

OCFS2 tesztek a KVM felett futó szerveren:

1-es node-on kicsomagoljuk,
2-es node-on kétszer kilistázzuk
1-es node-on töröljük.

PC1-ocfs~$ time (tar xf ~/linux-4.8.4.tar.xz; sync)
real 1m55.108s
user 0m12.569s
sys 0m23.029s

pc2-ocfs~$ time ls -lR linux-4.8.4 | wc -l
70341
real 2m43.385s
user 0m1.108s
sys 0m12.161s

pc2-ocfs~$ time ls -lR linux-4.8.4 | wc -l
70341
real 0m1.143s
user 0m0.192s
sys 0m0.948s

PC1-ocfs~$ time (rm -rf linux-4.8.4; sync)
real 20m27.176s
user 0m0.272s
sys 1m27.361s

Kérdés: lehet-e rajta gyorsítani, vagy a lock-olások miatt tényleg ennyire lassú az inode bejegyzés illetve törlés OCFS2 esetén?

( Mcsiv v | 2016. 10. 22., szo – 17:39 )

Nálunk a ceph-drbd bevált ;)

// Happy debugging, suckers
#define true (rand() > 10)

Mukodik ket nodeal 1+1 replicationnel (a default 1+2 emlekeim szerint), de 2 nodenal tuti trukkozni kell a monokkal szerintem (ha valaki csinalt ilyet es nem, fixme :))
De ertelemszeruen a ceph nem erre van kitalalva, hanem minimum 3-ra(es altalaban meg az is keves :))
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( freeoli v | 2016. 10. 22., szo – 20:43 )

A vmfs és a csv elég stabilak, nem volt vele sose gondom.

Közös storage lesz alatta vagy local store csak?

Nem vagyok ilyen megoldásokhoz szokva, mert általában ráfizetés.

clvm lesz a jó mivel ugyanaz a block eszköz már ott van mindkét oldalon

iscsi target mindkét hostra amit felveszel a lemezhez mindkét hoston, a többi már doksi mert ua, ott van már minden mindkét hoston

esetleg gluseter de rég nem tapasztaltam, de ez teljesen fs lesz drdb helyett is

Ha egyszerű és mások által használt megoldást is szeretnél használj proxmox-ot

Hyper-V Server 2012 óta van Shared Nothing Live Migration. Ehhez nem kell semmi közös, storage oldalon sem: a két független tároló közt az élő VM alatt át tudja helyezni a virtuális diszkeket, a memóriát, majd élesíteni az új hoston a VM-et, miközben lekapcsolja a régit.

Üdv,
Marci

Még egy plusz oka van amiért a hyper-v legyen a választott, vannak hozzá ingyenes backup eszközök amik könnyen használhatóak, pl veeam, 5nine.

Ha nem akarsz a drdb, clvm, kvm, libvirt világban elmélyülni egy éles rendszeren amiért felelős vagy akkor használj konzervet, ez úgyis a láthatatlan réteg lesz.

Tudnátok róla 2 node-os elrendezésben az előző hozzászólásomhoz hasonló performancia mérést végezni?

- https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.8.4.tar.xz kicsomagolása 1. gépen
- rekurzív listázás ideje a 2. gépen
- ezek után a törlés ideje az 1. gépen

Egy ilyen meres azert sok mindentol fugg, io, network, cpu pl, nem mindegy 1g van a 2 node osszekotve, vagy 10g-n pl...
Lehet naluk tok patent lesz a sebesseg ssdvel meg 10g-n. :)
"---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Erről akkor tudnánk beszélni, ha tudnánk, hogy mi is a topiknyitó célja a clusterezéssel és mik az elvárások az üzemeltetett rendszerekkel szemben. Ugyanis műszakilag különböző paraméterű megoldások is megfelelhetnek az üzleti elvárásoknak.

Érdemes megnézni: milyen eseményekkor, milyen különbséget jelent, ha
-5 perces késleltetésű replikád van a gépről egy másik különálló host-on és storage-on vagy
-egy osztott storage-on található a virtuális diszk, melyet mindkét host elér
Szerintem messze nem jelenthető ki általános érvényűen, hogy egyik vagy a másik a jobb -- pedig mintha Te erre utalnál.

Ha pedig valóban kiderül, hogy az általam ajánlott kiépítéssel az elvárt szint nem biztosítható: akkor lehet Hyper-V Server-ből is Failover Cluster-t építeni, sőt a 2016-os verzióban itt a Stretch Cluster. Ennek segítségével shared storage nélkül is építhető cluster, a Storage Replica használatával.

Üdv,
Marci

"Szerintem messze nem jelenthető ki általános érvényűen, hogy egyik vagy a másik a jobb -- pedig mintha Te erre utalnál."

Nem utaltam erre :) Arra utaltam, hogy almát a körtével ne hasonlítsuk össze. Mindkettő gyümölcs, de más az íze.
Abban igazad van, hogy a topikgazda csak azt írta, ő gyümölcsöt akar. Csak ezen a portálon gyümölcs alatt mindenki rögtön almát akar ajánlani. Jómagam amúgy inkább körtés vagyok. :) Nem is értem, ki és miért eszik még almát.... Jó tudom, az akinek konténeres linux virt kell.
Amúgy kösz, erről a Stretch cuccosról még nem hallottam de elég izgalmasnak tűnik, neki is állok megcsinálni a laborban.

( Zs | 2016. 10. 23., v – 16:32 )

kvm cluster esetén nem shared filesystem szükséges, hanem shared storage. A shared storage ugyan megoldható shared filesystem fölött is, de minek? Plusz egy réteg, ami egy hiba lehetőséggel több és további munka a CPU-nak.
Ha nagyon szegény a büdzse és a két node bővítése tuti nem tervezett, akkor a legtakarékosabb megoldás, ha a helyi gépen egy szép nagy partíciót megkap a drbd, amely Primary/Primary felállásban egyszerre mindkét node-on elérhető. Erre akasztotok egy clvm-et, majd innen szakítgattok lvm köteteket a guesteknek.
Ha több pénz van rá, akkor mehet külön a shared storage - Ceph, Nexenta, stb. Hosszabb távon esélyesen ez az irány a nyerő, érdemes lenne ebbe az irányba evezni.

1, kell valami ami kezeli clvm-et, pl pacemaker es 1db drbd-d van, ha azzal tortenik valami akkor mindet erinti.
Cserebe drbd-t egyszer bekonfiguralod es lvm-eket kell csak letrehoznod egyszeruen, igy kenyelmesebb ha beallitottad az alapokat, bar ha gond van vele akkor macerasabb lehet.

2, mindig letre kell hoznod drbd-t azzal a merettel amire szukseged van a vm-nek, de nem kell hozza pacemaker stb lock kezeles miatt, fuggetlenek a drbd-k, ha egyikkel tortenik valami akkor tobbi meg meguszhatja mukodokepesen. Szoval alapokat kevesebb melo osszerakni, meg hibajavitas egyszerubb lehet, de egyebkent macerasabb mindig egy drbd-t letrehozni, amit ha at kell meretezni esetleg szinten macerasabb.

proxmox regen drbd over lvm-et hasznalt: egy syncelt drbd felett lvm-mel kiosztot akkora lv-t amekkorat kertel disknek, ilyenkor ugye drbd primary-primary modban futott ami, es a proxmox daemonnak kellett gondoskodnia hogy egy vm diskjet csak egyik helyen lehessen irni. ez persze nem mindig sikerult, ha lett egy splitbrain, meg kethelyen modosult disk, halal volt rendberakni a dolgokat. (ciki van ha pl ket vm diskje "serult" egyik vm a node1-en van masik vm cucca a node2-on, igy nem lehet siman csak egy discard-my-data-t nyomni drbd-nek)
az ujban lvm felett van drbd egyenkent, itt ugye nincs gond, mindig ott lesz primary ahol a vm fut, ha megis felbootol ketszer ugyanaz a vm, akkor csak eldontod melyik oldalon legyen az ervenyes data, es azzal a labbal fejbevered a secondary-t. a tobbieket nem erinti a synceles. a rendrakas igy konnyebb.

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

( fraque | 2016. 10. 24., h – 13:09 )

kollegam az intezmenyi ubuntu csomagszerver ala 2 node-os Ceph clustert rakott. epp most van valami kernelnyug, ami miatt idonkent lerohad, de amugy jol megy, csak el kell fogadni, hogy minden tervezesi szabalyt felrugsz vele:)