wyx blogja

A helyzet az, hogy eme téma megfogta a fantáziánk...ugyan miért ne tegyünk a jókis Ceph klaszterünk "fölé" egy felhő megoldást.
Gondoltuk Cloudstack, egy próba, jól hangzó név.
Egyetlen gép, ezen van minden, még a primary NFS szerver is, 4.2.x felmegy, elkezd konfigurálni. El is indulgat a dolog,
bár az elejéna pod/cluster/stb. dolgot túlerőltetettnek érzem. Persze az alatt lévő rendszer libvirt + KVM.
Már ott kezd gyanús lenni a dolog, hogy Tomcat van a rendszerben :) Ejha, mondom, java. Biza a saját gépes primary NFS szerver,
mint a VM instance-ok tárolóhelye biza nehezen húzható be hibátlanul, ha sikerül rájönni a nyitjára, akkor szerencsés az ember.
Az sem egyértelmű, mit tegyünk bele az újraindító szkriptekbe, ha esetleg a Cloudstack szerverke reboot-ot igényel. Nosjó,
nagynehezen tényleg elindulnak a SystemVM-ek, van hálózata is virtuális gépnek, amit sikerül NFS szerverre rakni.
A külső hoszt felvétel muxik, cloudstack-agent barátunk legalább működött.
Aztán amikor a Ceph pool integrálásra kerülne, biza látja a pool méretét a Cloudstack, de biza a java folyamat elszáll, amikor
létre akarunk hozni egy instance-ot. Hiba, hiba.
Frissítsünk 4.4-re, hátha. Ez annyira sikerült, hogy biza frissítés után még futottak a systemVM-ek, de egy reboot megadta a
kegyelemdöfést a rendszernek, soha többet VM futás. Java hibák dögivel. Pedig a virsh szépen látja a virtuális gépeket, de a
felület már elveszítette őket. Lehet hack-elni az adatbázisban, törölgetni, stb, de nekünk nem ezzel kéne foglalkozni.
Mivel sajna Ubuntu közvetlen 4.4 telepítési lehetőség akkor nem volt, így dobtuk a témát.

Nos, a helyzet az, hogy azt látom, kezd terjedni a cucc (ceph), több helyről látok próbálkozásokat.

A jelenlegi felállásban csinálunk egy KVM/libvirt alapú virtualizációt, amely jelenleg kernel RBD modul alatt importálja be az OSD-ket (rbd pool), majd ezeken futnak a virtuális gépek.

Szívás volt az IDE emulációval, ugye szereti a libvirt a virtio megoldásokat, amelyhez azoban pl. Windows VM alatt drivert kellett telepíteni.
Jobban szeretjük a sima "drive" (azaz IDE) diszk emulációt, teszteink alapján a performancia nem rossz.
Eme két típusnál próbálgatjuk a VM save funkciót, amely érdekes módon jól működik, de csak offline.

A "Ceph teszt #1" blogomban leírtam, mik voltak az előkészületek a telepítéshez.

Most nézzük magát a klaszter elvi működését röviden. A ceph klaszter lényege az, hogy az ún. osd-k, mint objektumtárolók fogják tárolni az adatainkat, eme tárolók pedig "szét vannak terítve" a node-ok között. Speciális csíkozási technológiát használ alapban a ceph, azaz minden osd-re fog kerülni az adatainkból redundánsan. Ennek a részleteibe ne menjünk bele, sok beállítási lehetőség van, maradjunk az alapbeállításoknál egyelőre. Aztán vannak úgynevezett monitor démonok, amelyek azért felelősek, hogy egymást figyelve megállapítsák, lehalt e a node, vagy valamelyik szolgáltatása. Léteznek még mds-es is, amik viszont a metadata tárolásáért felelnek, itt a rendszer névterére gondolok és a adathozzáférési koordinációra. Eme három démon alapesetben, egy egyszerű klaszternél fusson minden node-on.
A node-ok között szinkronizáció folyik folyamatosan, erre keyring file-okat hoz létre a rendszer, amelyek segítségével titkosított megoldás is működhet. Mind a metadata démon, mind az osd démon kommunikál a többiekkel.

Nos jónapot. Küzdünk a storage oldali SPOF problémájával, kicsit közelebbről megnéztem a Ceph-et, mint esélyes versenyzőt eme probléma kiküszöbölésére.
Utánaolvasgattam a dolognak és lassan megértettem az elvi alapjait. Mint ismeretes, az Openstack alapját képező klaszterezett (disztributált) filerendszerről van szó, amelybe a Canonical 1 millió dollárt rakott, fejlesztésre.
Node mi is kellett nekem: hát az, hogy a reverse proxy mögötti webszervereinken legyen egy olyan filerendszer, amely nagyjából POSIX kompatibilis, konkurensen írható és ha lehet, még redundáns is. Persze az NFS-en feljnödögélt társadalom aszt mondja, erre ott van ő, mégha azt nehéz is kezelni, ha elszáll az NFS kiszolgáló, akkor a webszervereinkről hova tűnik az adat...Persze itt is van tükrözéses megoldás, meg pl. aktív-aktív DRBD, meg esetlegesen failover dolgok, de ezek nálam mindig valahol elhaláloztak gyakorlati megvalósításnál. Meg aztán nézegettem másokat is, úgymint glusterfs meg xtreemfs meg lustre, de a ceph-nél maradtam, mert biza a feature listája jónak tűnik.