KVM guest root FreeNAS-ról redundánsan

Virtualizáció

KVM host-ok (Ubuntu + Libvirt) alá szeretnék redundáns SAN-t építeni - egyelőre - FreeNAS-ból. (később szeretném céleszközre cserélni - ami egyébként néhány felvetődő problémát oob megold - de egyelőre kénytelen vagyok felpattanni a szopórollerre)

Ezért konstruktív véleményeket, ötleteket várnék a lenti felvetéseimre - első sorban a vázolt "low budget" lehetőségek között

Amit - jelen eszközökkel - a legtisztább megoldásnak látnék:
- FreeNAS-ról zvol iSCSI LUN-ként kiajánlva
- KVM guest disk-nek iSCSI LUN közvetlen behúzva

DE ebben nincs semmi redundancia, mert:
- FreeNAS önmagában nem tud HA-t
- Libvirt-scsi nem tud multipath I/O-t

Lehetőségek:
1., iSCSI LUN-t a KVM host-ra csatolom fel dm-mpio-val, majd ezt a raw device-t adom a guest-nek
- DE, mennyi a teljesítmény overhead?
- Egy újraindítás vagy migrálás után a megfelelő device-ok a megfelelő helyre kerülnek-e?
2., Egy nagy iSCSI LUN-t csatolok be dm-mpio-val, arra húzok LVM-et és LV-kat osztok ki guest diskeknek
- Szintén overhead kérdés?
- Nem migrálhatóak a VM-ok, hacsak nem cLVM-et használok
1+2+, Mindkét esetben RAID1-ben tükrözném a disk-et 2 NAS között, vagy a KVM guest-en mdadm-al, vagy a KVM host-on LVM mirror-al

Mennyire eszement őrültség mindez? Mennyire feleslegesen duplán terhelem az amúgy is szűkös hálózati kapacitást? Mi lehetne jobb megoldás? (Mi az élet értelme, a világmindenség, meg minden?)

  • 3793 megtekintés

( blackluck v | 2015. 10. 20., k – 23:59 )

A kerdes leginkabb attol fugg szerintem hogy mennyi virtual host geped van vagy lesz varhatoan a 2 storage-hoz, illetve mennyire fix-ek a vm-ek avagy mekkora a valtozas , hogy kell uj, modositani kell meglevo alatt tarhelyet stb.

Mert nagyob geppark, gyakran valtozo vm-ek eseten erdemes ugy kezelni a kerdest hogy van iscsi storage-od es arrol lun-okkal ajanlasz ki vm-eknek tarhelyet siman. Aminel vm-et ha kell at lehet at lehet migralni masik host gepre, olyan vm-eknel ahol meg kell a fokozottabb redundancia ott tehetsz 2 (vagy tobb) vm-et a feladatra es vm-eken belul csinalsz clustert.

Ha kevesebb geprol van szo, ritkan valtozik akkor lehet ertelme esetleg szenvedni multipath-al, plusz raid-el vm-ekbol vagy hasonlokkal.

Amugy a 2 otletedet nezve:
1, multipath-nak minimalis overhead-je van, igazabol meg nyerhetsz is vele teljesitmenyt ha tobb gigabites link kozott el akarod osztani az iscsi forgalmat, de ezt ha jol tudom ahogy irtad is nem kezeli libvirt (bar lehet ujabban mar igen, voltak ra tervek). Ha viszont azt nem konfigbol veszi hanem te takolod ala kezzel akkor azzal csak szenvedni fogsz migracio, host elinditas/leallitas es hasonloknal. En azt mondom ha tamogatja libvirt teljes ertekuen akkor ok, egyebkent inkabb ne hasznalj multipath-t a host gepen.
2, ha migralgatast akarsz akkor felejtsd el inkabb az ilyet, hogy 1 nagy tarhelyen clvm alol vm tarhelyek.

A host/guest aloli raid1 iscsi folottnek se vagyok hive, tobbszorosen terheled a halozatot es a gepeket.
Akkor mar inkabb 2 storage koze direkt link drbd-vel es cluster ip-vel, kozos ip-n keresztul csatolod fel iscsi lun-okat, link redundanciaert meg inkabb valami bondingot host es storage gepekre.

OK, akkor az árnyoldalakban kb. egyet értünk.

Hogy magának a multipath-nak pici az overhead-je, sőt a dupla link miatt nyereség van, ez egyértelmű. Én a problémát inkább abban láttam (mint szerintem te is), hogy guest-re csatolt LUN helyett a host-ra csatolok és egy sdX-et adok át a guest-nek (ami nem biztos, hogy mindig ugyanaz az sdX lesz)

A libvirt-nek kellene kezelni a 4 path-t (2 NAS x 2 path), a 2 NAS-nak meg a syncronous replication-t - ez lenne a szép.

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

"ami nem biztos, hogy mindig ugyanaz az sdX lesz"
Ez onmagaban nem gond, meg lehet oldani hogy ugyanazt a tarhelyet alias-al is lassa el multipath, csak ezt neked kell letrehozni kezzel a host gepen, pontosabban mindegyik host gepen amelyikre migralni akarod ha ilyet is akarsz. Ami mar korulmenyes es jobban figyelni kell ra vm migralas vagy uj letrehozas eseten, nem eri meg ezt a veszodseget.

A 2 nas-ra csatlakozasnak is pedig inkabb csak failover modban van ertelme ami storage oldalon van vezerelve (vagy van egy rendes kozponti managemented virt host gepekre es azon), mert sokszor nem trivialis es komoly gondok lehetnek ha ugyanabba az adathalmazba 2 storage-on irogatsz bele (akar ugyanabbol a rendszerbol, akar 2 kulon host geprol mert migralaskor egyik ide masik meg oda van felcsatlakozva). Sokkal tisztabb egy egyszerubb ha storage csak fail-over es iscsi-n csak az aktivhoz csatlakozol mindig.

( Szenti v | 2015. 10. 21., sze – 00:03 )

A ZFS-t nem javasolják VM-ekhez, bár zvollal én is kipróbálnám.

( secretx v | 2015. 10. 21., sze – 08:52 )

Nem értem egészen, hogy miért így próbálod csinálni. :)
Én inkább ahogy mások is írták, kiajánlanám a tárhelyet a nodeoknak, akik innen futtatják a kis vhd, qcow2, stb imageket...
Az sem világos teljesen, a multipath-el mit szeretnél?
Ha kiesik az egyik node, a másikról menjen a cuccos?
Mindezek mellett szerintem inkább használj egy kiforrott megoldást a virtualizációnál ott kevesebb szívás lehet a dologgal (xenserver, proxmox akár..)
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

"Nem értem egészen, hogy miért így próbálod csinálni. :)"
Szerintem elégé összefoglaltam a fennálló korlátaimat és kényszerűségeimet :)

"Én inkább ahogy mások is írták, kiajánlanám a tárhelyet a nodeoknak, akik innen futtatják a kis vhd, qcow2, stb imageket..."
Ezt ki más írta, hol? Min ajánljam ki, NFS-en? Egy SAN megoldásnál én menekülnék attól, hogy még 2 réteget behúzva file-okban tároljam a virt. disk image-eket.

"Az sem világos teljesen, a multipath-el mit szeretnél?"
Teljesítmény növelést és redundanciát. A duplázott rendszer 2 fele 2 külön szerverszobában lakik. Ha bárhol bármi kiesik, rendes multipath-al a rendszer meg sem érzi.

"Mindezek mellett szerintem inkább használj egy kiforrott megoldást a virtualizációnál ott kevesebb szívás lehet a dologgal (xenserver, proxmox akár..)"
A Proxmox is KVM alapú (amennyire tudom), de az oob HA és a management miatt tervben van az Ubuntu-s Libvirt-ek leváltása rá, de ez a következő lépés. A storage redundanciát az nem oldja meg.

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Ha jól értelmeztem (javíts ki ha nem kérlek), te a multipathinget arra használnád hogy 2 külön storagera szinkronba tartsd az adatot, majd ha az egyik lehal, üzemelsz a másikról.

A multipathingnek elsősorban az a szerepe, hogy a kapcsolati hibákat oldja meg (meghal az egyik kapcsolat, a másikon keresztül eléred a storageot.
Ezt pl ez a doksi is világosan leírja: https://support.citrix.com/servlet/KbServlet/download/27027-102-666389/…

Nem írtam az NFS-t, lehet simán iscsi-ként kiajánlani a területet, de nem diskenként - vm-ként, hanem egy nagy területet amire rárakod a virtuális imageket.

A kiváltást ahogy érzed, ezt neked kell tudni.
Én tuti nem szivatnám magam ilyen dolgokkal.

Egyébként mennyi VM van most a rendszerben hány node-on?

Természetesen én csak jót akarok, úgy csinálja mindenki ahogy szeretné, ő szív majd vele.. :)
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

"...a multipathinget arra használnád hogy 2 külön storagera szinkronba tartsd az adatot..."
Nem, a multipathing 1 storage felé kell(ene) a kapcsolati problémák redundanciája miatt (más kérdés, hogy mindez 2x, 2 storage felé külön-külön). A szinkront sajnos nem oldja meg, ehhez muszáj lenne valami raid/mirror a 2 storage-ról függetlenül behúzott 2 LUN között.
Persze szép lenne 4 utas MPIO-t csinálni (2-2 út mind2 stirage felé), ha a storage-ok elintéznék a sznkronizációt és a párhuzamos kiszolgálást, de sajnos ez az, ami nem megy (szerintem még brand storage-al sem)

iSCSI-n kiajánlani 1 block device-t, amin filerendszeren tárolom a disk image-eket - ha jól tudom - nem használható párhuzamosan több client node-ról (csak cluster fs-el, ami megint egy lehetséges plusz szívás, afelé nem szívesen mennék, bár ötlet szinten OK)

Jelenleg 2 node-on 18-20 VM fut, ebben jelentős változás nem is várható. Nem annyira a skálázhatóság, inkább a rendselkezésre állás a célom a mindenben 2x redundanciával.

(én sem kötekedni akarok, inkább másoknak gondolatébresztőként, vagy későbbieknek jó tanácsként részletezem ennyire "szájbarágósan" a válaszaimat)

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Értem, így világos már a dolog :)

Itt a 2 storage között szinkronban tartani a dolgokat lesz szép feladat ahogy olvasom inkább.., mire gondoltál itt?
Adott hozzá normális sávszélesség?

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

Sajnos a szinkronra ebben a felállásban nincs jobb ötletem, mint hogy az iSCSI kliens képez mirror-t a 2 storage-ból, ami sajnos dupla adatforgalmat jelent a hálózaton, ami nem annyira tetszik :(

A későbbre kinézett brand storage-ok elvileg megoldják a szinkront egymás közt, de szintén ugyanazt a storage hálózatot használják erre, max. a kliensek felé lesz csak szimpla terhelés.

A sávszélesség (jelenleg még egy jó darabig) Gigabit ethernetből áll össze, kezdetnek 2 port/host.

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Igen, ilyesmire gondoltam, de nem tartom jó ötletnek.

a., egészen a VM guest OS-is elviszek 2 disk-et és azon mdadm
b., csak a host OS-ig viszek 2 disk-et, azon cLVM mirror és LV-k kiosztva guest disk-nek

Mindkettővel az a baj, hogy ha bármilyen átmeneti kiesés miatt leszakad az egyik storage (iSCSI disk), utána teljes rebuild következik, ami felesleges erőforrás gyilkolás + ez idő alatt SPOF :(

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

( dzsambo | 2015. 10. 21., sze – 17:44 )

A 2 nas hogy helyezkedik el egymástól, mert ha tudsz tegyél még beléjük ethenet kártyát és kösd őket össze azokon keszesztül.

Glusterfs nem játszik, ubuntura telepíthető szinkront megoldják egymás között. Ha később proxmox lesz az tud egyszerre két téglához kapcsolódni.

2 nas-ba + hálókártya, direkt kapcsolat nem gond, de mi csinálja meg azon keresztül a szinkront? FreeNAS sajna épp erre nem képes, pedig szép lenne! (illetve de, offline replikációt tud így)

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Sajnos a "storage" egyelőre "Made in Taiwan" (Gigabyte, AMD AM3, 32GB, 2x1G Realtek) :/
A KVM node-oknál már jobb a helyzet (Dell R710, 12 core XEON, 96GB)

Mondjuk, a guest-ekből max. 4-5, ami I/O intenzív, a többi nagyrészt elvan RAM-ból, vagy csak "pihen"

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

FreeNAS-ról iSCSI-n 1xGB path-on:

Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
debian-base 3G 1006 96 106085 8 54170 4 5234 99 137686 6 14099 100
Latency 7996us 171ms 327ms 3295us 6838us 43381us
Version 1.97 ------Sequential Create------ --------Random Create--------
debian-base -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
Latency 2146us 398us 361us 106us 58us 146us

Ehhez képest az R710-en a 2x15k rpm SAS disk HW Raid1-ben:

Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
kvmhost02 3G 798 98 98257 7 101466 5 4825 98 5498293 99 4103 32
Latency 10744us 113us 127us 1781us 113us 36us
Version 1.97 ------Sequential Create------ --------Random Create--------
kvmhost02 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
Latency 11056us 328us 369us 121us 112us 58us

Hétfőn majd nézek VM-et a Ceph-ről is

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Gluster-el még nagyon nem foglalkoztam, de tudtommal az csak egy FS, az alá még kell valami block device szinkron (mondjuk drbd). Ez mehet(ne) a Proxmox host-ok között - ez esetben tulajdonképpen mindegy, hogy local storage vagy SAN van alatta/mögötte - vagy mehet a NAS host-ok között - ez esetben viszont min és mit adsz ki a Proxmox-oknak?

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Hát nem egészen.
A storage-okon létrehozol egy mappát ahova szeretnéd tenni a virtuális gépeid. A storage-on lévő mappát úgy kezeled mintha egy hdd lenne, ezeket a virtuális hdd-ket használva tudsz létrehozni különböző raid szintű kötetet és ezt ajánlod ki a proxmoxnak.
Nem vagyok nagy fogalmazó, talán majd jön valaki aki érthetőbben elmondja mint én.

Nálam 4 db 500GB-os hdd-kből álló raid 6-ös tömb van egy egy storage-on, ennek nagy része felcsatolva a /srv-re és erre van létrehozva a proxmoxnak kiajánlott kötet.

Itt egy jó leírás a telepítésről: https://www.digitalocean.com/community/tutorials/how-to-create-a-redund…

( Zs | 2015. 10. 21., sze – 19:23 )

FreeNAS mennyire van kőbe vésve? Háttértár esetén a CEPH elég sok mindent meg tudna oldani, a későbbi bővítés pedig könnyű. Mondjuk az is tény, hogy innen kezdve RDB eszközeid lesznek. (Ne tévesszük össze a drbd-vel!)
A kvm jó - kérdés, hogy a korábban már mások által emlegetett ProxMox mint frontend, mennyire szimpatikus? A CEPH-fel nagyon jól összelőtt kis valami.

-1 a CEPH-re :( Beletrafáltatok, sajnos épp azt váltanám le teszt jelleggel ezzel a felállással, aztán, ha bejön, akkor brand NAS-okkal.

1+ éve reszeljük a CEPH-et, de iszonyat gyenge teljesítményt hoz. Bármilyen kis változtatás, hangolás, bővítés a rendszeren és egy rebuild/rebalance 1 hétre megbénítja az egés clustert (hiába van az összes configban behangolva, hogy ezekkel háttérben foglalkozzon, első a kiszolgálás)

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Teszt jelleggel:

A két NAS-on hozz létre a VM számára egy volume-ot, amit drbd-vel szinkronizálsz közöttük (Primary-Primary módban), majd
a drbd volume-okat a NAS-okról iSCSI-vel kiadod a VM-nek.
A VM-en pedig használhatsz multipath konfigot, de szigorúan Active-Backup módban.
Így ugyan nem lesz dupla sebességed a NAS irányban, de a storage-ot redundánsan tudod használni.

ui.: a hálózati link-ek monitorozásáról nem szabad megfeletkezni, sem a NAS <-> Node, sem a NAS <-> NAS linkről.