Ceph és privát felhő

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, akkor Openstack + Ceph. Próbáljuk itt is az egygépes verziót, Devstack néven. (először az Ubuntus Cloud megoldást nézegettük,
Juju-val meg Landscappel, hát sajna dobtuk is pár nap múlva a telepítéskor előjövő rengeteg hiba miatt)
A Devstack azonban felment és láss csodát, el is indult a webes felület és a szolgáltatások. Alapjában véve a Devstack egy nagyon
jól használható "egygépes felhő", sok funkcióval, a hálózati rész azonban le van egyszerűsítve, igazából nincs is Neutron futó
szolgáltatás. Ettől függetlenül egy IP tartományból szépen kapnak IP-t a gépek, ezzel nincs gond.
Nincs nagy csoda, itt is libvirt + KVM/QEMU cucc van a háttérben, illetve librbd a Ceph oldaláról.
Már jobban éreztem magam, amikor python alapú dolgokat láttam a process listában. Az Openstack felület gyors, jól működik,
kevés hibát dob. Ötletes megoldás, hogy screen alapokon az összes regisztrált Openstack szolgáltatás log-ja látszik, egyesével
újra tudjuk őket indítani és leállítani a screen-ből. Az unstack és rejoin funkciók ugyan hellyel közzel hibáznak, de hamar
rájön az ember, hogy mit kell törölni ahhoz, hogy clean installból újrahúzzuk a Devstack-et.
Ceph felkészítés. Kicsit féltünk tőle, ugyanis több szolgáltatást is érdemes felkészíteni az RBD kezelésére. Kezdve a Glance-szel,
ami az image-eket tárolja, folytatva a Cinder-rel, amely a volume kezelését intézi, illetve hát a Nova is hozzászól a témához,
amely meg futtatja őket.
Voltak itt is kitalálandó dolgok, például egy a sok közül, ha nincs cephx, akkor biza a konfig file-okban el is kell távolítani
az egyes ehhez kötődő paramétereket, persze ezt egyik netes leírás sem erőltette:( A másik az lvmdriver-1 témakör, ami ugye
a Cinder alatt kellene, mást azonban nehézkesen tudunk felvenni. Emiatt ide tettük be a Ceph kezelő részt, mondván, nekünk
úgysem kell most LVM. Működött is alatta, ez volt a megleleptés. A virtuális instance-ok végre megjelentek az egyik Ceph-es
pool-unkban, UUID alapján. Öröm.
Cselezhetünk úgy is, hogy nem a szokványos config fileos RBD felvétellel manipulálunk, hanem megkeressük a Devstack instance
könyvtárát, aztán bemountoljuk alá a korábban kernel RBD modullal "áthozott" Ceph RBD pool logikai kötetet, miután leformáztuk.
Ekkor az Openstack semit sem tud arról, hogy alatta Ceph van, és mégis. Eme megoldás is jó volt, de ha ezt az utat választjuk, akkor
már az elején készítsük így fel a rendszerünket, nekünk az instance-ok visszamásolása hibákat okozott. Az új instance-ok felvétele
azonban nem!
Mivel egygépes rendszerről van szó, emiatt természetesen van SPOF, a jövőben az egyes fontos szolgáltatások klaszteresítése
a cél, mint Nova, Cinder, stb. Ezt tudja a Devstack is multinode-ban, de ez már egy másik történet.....

( kmARC v | 2015. 03. 10., k – 11:02 )

Szerintem még időben szakadj el a devstacktől. Mint a neve is sugallja, ez nem egy egygépes OpenStack, hanem egy dev env.

Épp múlt pénteken csináltunk végig kézzel egy egygépes OpenStack installt hogy bemutassuk az új kollégának, _csak_ a doksi alapján, és elsőre működött. (A harmadiknak indított vm-en már volt hálózattól kezdve minden, előtte egy-két dolgot elkonfigoltam). Azért is hasznos lehet ez, mert látod a konfigfájlokat, lesz elképzelésed arról, hogy hova nyúlj, ha valami meghal.

A cephx-es problémán nem csodálkozom, mivel _MINDENKI_ cephx-szel használja. Azt sem nagy ördöngősség telepíteni.

Ma már mind az OpenStack, mind a ceph hivatalos doksija olyan, hogy végigcsinálod, és működik, szóval minden más úttal ellentétben ezt javasolnám.

A Devstack arra jó, hogy egy "kezdő" is el tud vele indulni és kap - aránylag hamar - egy Openstack felületet. A célom is ez volt a bloggal.
Természetesen ez nem professzionális megoldás, bár hozzáteszem, sok Openstack/Ceph szakértő (pl. Sebastien Han) is foglalkozott sokat vele.
Mi nem használunk cephx-et, a jelenlegi összeállításunkban nincs rá szükség.
Azért annyira a hivatlalos dosikat sem magasztalnám, sajna mindig vannak meglepetések.