Közös storage libvirt alá

Virtualizáció

A téma adott.
Megoldást keresek a tárgyban említettre, szeretnék csinálni egy libvirtes (kvm-es) virtualizáló fürtöt, amiben összesen négy node lakik.
Nézegetem a közös tárhelyre a megoldásokat, és eddig a következőket találtam:
- Közös NFS storage (ez lehet failver két node között) ; ez annyira nem tetszik a plusz hw miatt
- Valami iSCSI-n kiosztott diszk, amin valami cluster filerendszer lakik, mondjuk GFS; ez nem tudom tetszik-e, nekem nem annyira
- GlusterFS, de ezt nem tudom mennyire alkalmas blockdevice-ok megosztására (nem-e egész file-t, akar syncelni, de akkor ez annyira nem menő 20 - 40 Gb-s image fájlok esetén.)

Szóval? Mi itt a legjobb tipp?

  • 5053 megtekintés

( _ventura_ v | 2012. 03. 19., h – 21:54 )

Minek FS?

iscsi + LVM partíció a VPS-eknek.

Fedora 16, Thinkpad x61s

( egeresz | 2012. 03. 19., h – 22:02 )

ez olyan altalanossag.

hat akkor altalanossagban.

Kell neked kozos (shared) storage, ami kulon hardver.

Lehet jatszani azzal, hogy mindegyik node drbd-vel tukrozott diszkekbol egy peldanyt ad ki iscsi-n/NFS-en a tobbinek, es sajat maganak is, mikozben futnak rajta a VM-ek, es ha meghal, akkor a masik node szepen mindent atvesz. Lehet ezzel jatszani, jattsz el vele, stabil szolgaltatasod nem lesz (*)

Ezzel szemben az altalanossag az, hogy a bekerulesi HW koltseg 60%-at diszkre (storage alrendszerre) kell kolteni, es ez legyen kulon vas, es ne kelljen vele torodni.

(*) ha ilyen felallasban stabil szolgaltatast tudsz nyujtani 5 evig (3 debian stable, 10 uj kernel, 3000 uj sec.bug), akkor a beleolt tudas piaci erteke meghaladja a megsporolt entry-level storage piaci erteket. Mondjuk 5-szorosen haladja meg.

Jatszani lehet vele :-)

( lepenyet | 2012. 03. 20., k – 08:03 )

Szeretnél működés közben virtuális gépet mozgatni, de nem szeretnél közös storage-ot?

Üdv:
Lepenye Tamás

A kérdés provokatív volt, viszont jogos. Ha gépeket akarsz mozgatni, vagy HA módon üzemeltetni nem tudod kikerülni a közös storage témát. Az hogy a KVM-es node-ok csak akkor tudják a virtuális gépet(VM) futtatni ha a VM számára biztosított háttértárat(vhd) valamien formában elérik. Ha nincs egy közös tár a vhd-k számára akkor az egyes KVM-es node-ok nemtudják majd a VM-et boot-olni.
Azt megteheted hogy minden egyes node-on futtatsz VM-et és ha mozgatni kell akkor kézzel a libvirt xml-jét átmozgatod a másik gépre, majd a VM-hez tartozó vhd-t szintén át másolod, libvirtbe megcsinálod a VM-et az uj node-on is, és indítod.
Ekkor nem kell közös storage, de nem is egy ember barát ezekkel foglalkozni :).

Kivéve ez alól, ha esetleg létezik egy olyan filerendszer, ami szépen megcsinálja azt, hogy a lokális diszkeket összefésüli, mint pl. a gluster, csak nem file szinten, hanem blokkszinten.
Csináltam tesztet GlusterFS-sel, és tulajdonképpen működik is, csak nem tudom mennyire megbízható / gyors. Legalábbis élesben.

Értelek mire gondolsz (azt hiszem :)). Abban a felállásban amit elképzeltél az a C betűs szó jön elő, hogy clusterfs. Egy elosztott FS esetében az egyes node-oknak kell össze fütyűlniük, hogy éppen ki mit ír/felül_ír/olvas/töröl...
Ehhez jó sebességű "network" kellhet, nem elsősorba gigabit_per_sec számra hanem a válaszképességre gondolok. Mostanában cseréljük le a GFS alapú megoldásunkat, sajnos akadnak gondok a tempóval, rezes kábelen keresztül van hajtva 5 gépnek kell a lock-okért küzdeni, a RH pedig FC-t szeretne a GFS alatt látni, ami lényegesen jobb válaszidőkkel dolgozik, és egyes lock megszerzése sokkal kevesebb idő. Nekünk a GFS nem jött be.

Glustre nekem ismeretlen, így csak bele ugatok, de ha sok gépnek kell megbeszélni, hogy ki éppen mint csinál a file rendszeren az sanszos hogy teljesítmény rovására megy.

Neked egy drbd master-master (2+ node) felállás kellene. Ilyenről még nem hallotam, de a tévedés/tudatlanság jogát fentartom

Neked komoly problemaid vannak a magyar nyelven irassal:)

A drbd master-master-re ugyanugy egy cluster fs kell, pl. gfs vagy ocfs.

A glusterfs-t sokan hasznaljak, mukodik, sebessegben is jo, de en meg nem biznek benne replikacio szintjen. Fejlodik, de a QA teren meg van mit csiszolni.

Hasonlo megoldas, csak metaserveres a moosefs. Azt direkt ilyenre fejlesztettek ki, erdemes megnezni.

Szereny velemenyem szerint ha vki uzembiztonsagot akar viszonylag nagy teljesitmeny mellett storage nelkul, az ne akarjon live migration-t. Vagy az elso kettobol adjon fel vmit.

tompos

Szereny velemenyem szerint ha vki uzembiztonsagot akar viszonylag nagy teljesitmeny mellett storage nelkul, az ne akarjon live migration-t. Vagy az elso kettobol adjon fel vmit.

Ezzel nem értek egyet. Egy fürtözött rendszer (közös tárolóval) kétféle leállás ellen védhet: tervezett és nem tervezett. A live migration a tervezett leállások elkerülését segíti. Ha nincs fürt (mert nincs storage), de van (lenne) live migration, azzal a tervezett leállásokat lehetne csökkenteni.
Abban igazad van, hogy az üzembiztonságot fürtözéssel, és ezért blokk-, vagy file alapú közös tárolóval lehet növelni. A rendelkezésre állást azonban nem csak a váratlan, hanem tervezett leállások is ronthatják. Ez lenne megspórolható live migration-nel.

Üdv:
Lepenye Tamás

Hello,

akkor elmesélem röviden. Tamás egy Hyper-V Server beta és egy Windows Server 2012 beta között mozgatott egy virtuális gépet Shared Nothing Live Migration segítségével. A gép storage-a helyi diszkről helyi diszkre mozgott, köztük csak hálózati kapcsolat volt. Utána megmutatta ugyanezt egyszerre hét gépen egy egysoros PowerShell paranccsal.

Üdv,
Marci
A Microsoftnál dolgozok.

Ez egy jó dolognak tűnik, nem ismertem eddig, sajnos az oldalukon ilyet találni :

You should not consider Sheepdog if you are looking for:

High bandwidth/low latency storage (‘scale-up’)

Ezt majd banyek okosan eldönti hogy neki mennyire kell a teljesítmény, ha a VM-ekbe nem olyan szolgáltatás fut akkor lehet hogy pont ezt lesz neki a "szent grál"