Összegzés, vélemény

Összegzés

A megvalósított rendszer működött. Kipróbáltam, hogy mennyire tűri, ha a gluster egyik fele kiesik. Természetesen tovább működött a rendszer és mivel a HA is aktív volt (trial license), ezért automatikusan elindította az ESXi-vel együtt kilőtt VM-et is a rendszer egy másik masinán. Miután elindítottam a lekapcsolt ESXi-t a gluster egy heal után ismét rendben futott tovább. Ez a nagy méretű virtuális lemez miatt eltartott pár óráig, de ez természetes 2 TB-nál.

A virtualizált gép kicsit lassabb, mintha a fizikai vasat direktben használnánk, de ez nem meglepő és elfogadható ár azért, hogy a vasat jobban kihasználjuk, több gépet futtassunk rajta egyszerre. A gluster viszont nem 10-15 százalékkal, hanem akár aredeti felére is visszavetheti a sebességet. A sebesség veszteség oka a hálózat teljesítménye. A tesztnél egyértelműen limitálta a GlusterFS-t a gigabites ethernet.

Az elméleti maximális sebesség 125MB/sec, amit néhányszor egészen jól sikerült megközelíteni. Írásnál a gluster kiírja az összes brickre ugyanazt az információt. Ezért még akkor is, ha az egyik brick ugyanazon a gépen van, akkor is várni kell a hálózatra. Olvasásnál a brickekről párhuzamosan olvas, úgy néz ki, hogy nem elég intelligens, hogy a helyben lévő bricket használja csak, ezért ismét a hálózat a szűk keresztmetszet. Még az LACP (etherchannel) sem segít ebben az esetben, mert két gép között mindig ugyanazt az interface-t használja az ESXi.

Mint láthatjátok, az NFS jó választás volt, nem jelentett limitációt. De ilyenkor felmerül a kérdés, hogy mit lehet, mit lenne érdemes változtatni. Én nagyjából a következőket szedtem össze:

- Gyorsabb hálózat: 10Gigabites hálózattal eltűnne a limit nagy része, persze jó kérdés, hogy ez mennyibe kerülne, illetve hogy megérné-e a beruházás.
- Központi storage használata: mivel van storage a cégnél, ezért logikus lenne azt használni a VM-ek alá. Csak ismét előjönne a hálózati limit (iSCSI vagy NFS jöhet szóba) és a tároló kapacitás ára, ami kb. 3-4x nagyobb, mint a local diskek esetében elérhető
- Raid10 helyett raid5: Mivel a hálózat limitál, ezért megfelel a lassabb raid is, cserébe kapnánk kb. 1.2TB plusz kapacitást.
- RDM a storage VM alá: Raid tömböt direktben odaadni a storage VM-nek. Pár százalék gyorsulással, CPU terhelés csökkenéssel hálálná meg ezt a lépést.
- További optimalizáció: Egyértelműen lehetne még gyorsítani, optimalizálni a gluster-t, például kicsit több cache-t hozzáadva.

Vélemény

A kitűzött célt sikerült teljesíteni, de a háttértároló sebessége így lassabb. Mint látható, a kritériumokat teljesítő egyetlen alternatíva (SAN, NAS) sem lenne gyorsabb a hálózati limit miatt, tehát nincs igazán jobb megoldás hasonló összegért. A GlusterFS már elég jól dokumentált és megbízható, hogy egy teszt rendszer alatt üzemeljen. Sima mirrorokban limitált méretben éles rendszer alá is bevállalnám. A legjobb tulajdonsága az, hogy a brick-en sima mirror esetén egy az egyben megtalálhatóak az állományok, így némi másolgatás után még egy olyan storage is feléleszthető, ami valamiért nem hajlandó elindulni.

Ha az lenne a kérdés, hogy mit változtatnék az itt leírt és a végleges teszt rendszer között, akkor azok a következőek:

- A raid1 tömb 3 brickből, így ha egy gép működőképes, akkor az adatok nem vesznek el. Ráadásul a quorum is megoldott
- 2-3 volume-ot hoznék létre, így egy volume kevesebb állományt tartalmazna. Talán kicsit gyorsítaná a heal-t, lehetne az egyik volume nagyobb kapacitású, de lassabb SATA lemezeken.
- Minden ESXi-n lenne local storage. Ide kerülhetnek azok a gépek, amiket nem kell védeni, vagy kritikus számukra a HDD sebessége. Ezeket mondjuk naponta lehet snapshotolni és backupolni.

Menet közben felmerültek kérdések, hogy miért nem mást választottam. Pár alternatívát úgy gondolom, itt is érdemes megemlíteni:

- DRBD: Linbit által fejlesztett, block device replikáció. Gyakorlatilag raid tömb hálózaton keresztül. A hálózat itt is kemény limitáció és kell ráadásul egy elosztott fájl rendszer, tehát semmivel nem lennék vele előrébb. Talán csak annyival, hogy kicsit több tapasztalatunk van vele, de ezek között van rossz és jó is.
- Ceph: [link] Nem látom előnyét a gluster-hez képest, nem lenne egyszerűbb, bár talán többet tud, mint a gluster, de azokat nem használnák ki.
- Snapshot és időszakos backup: Az ESXi datastore-okról tényleg készíthetnénk másolatot. Mondjuk napi 2-4 alkalommal menthetnénk a vmdk-kat. Ez jól működne például Veeam Backuppal.
- oVirt, Proxmox...: Igen, egyértelműen megoldható mással is a feladat, de azokkal sokkal kevesebb tapasztalata van a csoportnak, így azt is meg kellene tanulni üzemeltetni, kezelni... Ez időbe, tehát pénzbe kerül. Nem vetettem el az alternatívákat, főként mert azokból is sokat tanulhatunk.

Remélem legalább pár embert érdekelt az írásom, még akkor is, ha nem mentem bele mélyen az eredményekbe, illetve a telepítésbe.

A cikk még nem ért véget, kérlek, lapozz!