OpenStack meetup Budapesten

Címkék

Október 21-én ismét OpenStack meetup Budapesten. Ebben a hónapban az OpenStack leginkább kihívást jelentő része, a hálozatkezelés kerül fókuszba. Alexander Gabert a MidoNet nyílt forráskódú hálózat virtualizációs réteg elosztott programozását mutatja be, míg Halász Imre a Zorp és az OpenStack integrációjáról fog beszélni. Az előadások után természetesen lesz kötetlen beszélgetési lehetőség a résztvevőkkel.

Regisztráció: ITT
Helyszín: Bonnie Restro, Budapest (Ferenciek teréhez közel)
Időpont: Október 21, 18:30

Hozzászólások

Kifejezetten jó hangulatú meetup szokott lenni, érdemes egyszer elnézni.

Néha az az érzésem, Budapesten sűrűbben van OpenStack meetup mint Zürichben. És ez jó! Menjetek, okosodjatok! :-)

Sajnos tényleg csak össze van tákolva. Nem is olyan rég néztem csodálkozva, hogy az egyik trove agent belesedel az /etc/init-ben levő egyik upstart fájlba...tele van ilyen szar hekkel az egész, nincs hozzá egy normális installer (egy SuSE-s előadó mondta egyszer nagy büszkén, hogy az övék 2 óra alatt feltelepíti), hibaüzeneteket sokszor csak logfileból tudod kibányászni.

packstack nevu `demo` installer olyan 10-20 perc alatt vegez ssh + `puppet -apply`,
nekem volt egy scriptem (devstack atheckelve, hogy rpm et hasznalajon git helyett, meg nehany parhuzmositasi trukk) ami all-in-one -t csinalt 3 perc alatt (rpm letoltosi idovel egyutt).

BTW: #define normalis installer.

A mostni modi-nak az lataszik, hogy system image-ket crealunk es fellojuk a vasakra (pxe), aztan nemi puppet apply heat -en es os-collect-config -on keresztul..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

#define normalis installer.

Ami végez emberi idő alatt, lehet használni run-time is (a végén kiderül, hogy elítad az NTP-t, ne kelljen már újrarakni az egészet), és ne tartalmazza az összes új trendi technológiát, amit az elmúlt 3 évben kitaláltak. (Pl. telepítsünk OpenStacket OpenStackkel, ehhez indjulunk el egy deploy imidzzsel, ami telepít egy Overcloudot, ami majd telepít egy Undercloudot).
A legígéretesebb talán az openstack-ansible projekt, csak azt meg elbaszták azzal, hogy minden openstack szervízt külön konténerbe tesz. Jó lassú is emiatt, pedig a konténerek nélkül végezhetne max. fél óra alatt.

Devstack meg egy vicc inkább.

Devstack nem egy vicc, hanem egy DEV environment, ahol ki tudsz próbálni egy-egy komponenst, de leginkább fejleszteni tudod.

Az OpenStack-Ansible hivatalos OpenStack project; Nem a kipróbálgatásra-playgroundra van kihegyezve, hanem arra, hogy HA-ban deployolj magadnak nem pici infrastruktúrát. A minden szerviz külön konténerben/hoszton pedig azért 2015-ben már alap. Anélkül hogy a fenébe csinálsz HA setupot?

Az OpenStacknek, ahogy semmilyen infrastruktúrának nem a háromperces, vagy éppen nagyonkönnyű install a lényege, hanem az, hogy utána minél strapabíróbb infrastruktúrát adjon neked. Ehhez viszont nem elég egy phppistike tutorialból összeszedett tudása. Igenis switchet kell konfigolni, SPOF-okat keresni a shared power outlettől kezdve a shared hosztokig, monitoringot beizzítani, és a céges ldaphoz hozzálőni a keystone-t. És közben még vagy harminc lépés a storage-től a DNS-en át a céges policykig. Ha mindezeket összeveszed, ezek mellett az OpenStack akár 5-10 órás "feltelepítése" eltörpül.

De azért vannak a Meetupok, hogy minél többet tanulhas jó társaságban erről az egész ökoszisztémáról, a célokról, a hogyanokról. Ajánlom, ha időd engedi, látogass el a mostanira.

Devstack nem egy vicc, hanem egy DEV environment

Aminek a valósághoz sajnos nem mindig van köze. Ráadásul ha felteszed egy normálisan karbantartott gépre, össze-vissza másol, installál, gyakorlatilag szétkúrja a gépet. Ajánlott VM-be telepíteni (szerintem). Valamelyik OpenStack előadó mondta, hogy standard válasz egy bugreporta: devstacken működik :)


A minden szerviz külön konténerben/hoszton pedig azért 2015-ben már alap. Anélkül hogy a fenébe csinálsz HA setupot?

Ez az őrült minden process egy docker világban alap, miért ne lehetne HA setupot csinálni konténerek nélkül? Képzeld, ezek a mai nem elég trendi oprendeszerek azért tudnak futtatni egy novat, neutront, keystonet egy gépen, egy filerendszeren. Csomagkezelés, konfig management, és még átlátható is lesz. Vagy több gépen is akár HA-ban, konténerek nélkül.

Az 5-10 óra meg azért elég idegesítő tud lenni, amikor a 4. órában jössz rá, hogy kezdheted elölről.

Na mindegy, nem akarok ezen vitatkozni, előbb-utóbb kiforrja ez magát.

> > A minden szerviz külön konténerben/hoszton
> lehetne HA setupot csinálni konténerek nélkül?

Lehet, mint ahogyan írtam, pl. külön hosztra is teheted

> Képzeld, ezek a mai nem elég trendi oprendeszerek azért tudnak futtatni egy novat, neutront, keystonet egy gépen, egy filerendszeren
Képzeld, ha tudnád értelmezni a fent leírtakat, nem kéne ez a "képzeld" stílus.

> Vagy több gépen is akár HA-ban, konténerek nélkül.
Wow. Mik vannak.

Sajnos én nem tudom értelmezni azt, hogy egy gépen két ugyanolyan konténer mitől lesz HA. Számomra csak úgy van értelme, ha eleve külön hosztra teszed. És mit egyszerűbb üzemeltetni/újratelepíteni/stb., 1 hoszton 10 szolgáltatást, vagy 1 hoszton 10 konténerben 10 szolgáltást? Nekem az előbbit. De lehet, hogy másnak nem.

Ahogy NagyZ is írta, a konténerbe, vagy vm-be telepített komponens nagyjából 30mp alatt rendelkezésre áll, ha kiesett a régi. Ha kézzel akarod megjavítani, az több óra lehet. Ha kézzel akarod feltelepíteni, az is. Ha valami konfigmenedzsmenttel, az több, akár 10 perc. Ehelyett egy heattel, vagy kubernetessel újrahúzva 30 MÁSODperc. Vagy annál is kevesebb. E fölött nehezen lehetne HA-nak nevezni.

Te már megint azon lovagolsz, hogy hogyu EGYSZERŰBB valamit telepíteni. Senkit nem érdekel, hogy egyszerű-e telepíteni, az érdekel, hogy baj esetén egy perc alatt áll-e automatán az egész rendszer újra. Ezt az egyszerű telepítést el kell felejtened végre. Nem azért adnak 160k+-os fizetéseket, mert találsz egy egyszerű telepítési módszert.

30 sec nagy ido egy process inditasara, megy az gyorsabban is ha akarja az ember.

De nova-api HA -hoz nem ez kell, es teljesen irrelevans mennyi ido alatt indul egy nova-api process,
ami kell 2+ peldanyban futo n-api LB mogott, ha egy kiesett rengeteg idod van masikat hozni.

A problema LB HA -va tetele lesz, annok josaga meg azon mulik milyen hamar kepes eszre venni az egyik LB, hogy masik meghalt. 30 sec elfogadhatonak szamithat, de lehet sokkal alabb is menni. Rendszerint egy masik node atveszi a LB VIP-t es kuld egy ARP -ot, a masik node mar letezett az elso halala elott teljesen bekonfigolva.

See Also.: keepalived vagy pacemaker

Aztan jonek a kerdesek, mi van akkor ha hibasan detektaltuk a halal esetet,
mindketo megoldasnal van ra forgatokonyv.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Eléggé fölé lőttem a 30mp-cel, remélhetőleg tíz alatt is megvan az mondjuk lxc-vel.

Természetesen LB mögött van minden, ezt nem vitatom. De azért ha lehal valami miatt egy szerviz, akkor hiába a keepalived, pacemaker, haproxy, akármi, izzadva akarsz telepitgetni új node-ot, vagy két paranccsal felhúzni a konténert/vm-et? Én az utóbbit mondanám.

Nem latom miert nehezebb egy uj nodot csinalni, mint egy vm -et vagy egy containert.

Mindegyik elofeltetel egy build recept meglete,
aminek minden normalis uzemeltetesi tervben leteznie kell.

Ha van egy letezo container infra-d az openstack meglete elott (tobb mint 3 fizikalis nodeal), de nem vagy kepes fizikai nodokat elokapni, akkor lehet egyszerubb containerezned.

Ha nincs tobb fizikai nodod n-api futatasara, akkor a garancialis alkatreszre kell varnod container ide vagy oda.

Ha nem hardware hiba volt, akkor reboot/restart/reinstall megoldja.

PS.: Remelem arra figyelsz, hogy n-api szervicek tobb fizikai nodon fussanak container ill. vm ide vagy oda.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

+1 a konténer sem a /dev/null-ból születik.
Ha elkészülnek backupolod őket? Aztán ha módosítasz bennük, akkor újra? És mivel módosítasz? Jó esetben config managementtel. Ha kézzel hekkelt konténereket használsz, már rég megette a fene.
Ha jó az installer, akkor nem izzadsz a node felhúzásánál, hanem elindítod, és megvárod, míg végez. Ha csak egy konténered van, akkor meg remeghetsz, hogy ez az volt-e, ami legutoljára még futott.
Meg itt nem 1 konténer van, hanem a jó kis microservices felfogással vagy 10. 10x10 másodperc? Annyira nem indulnak el azok sem gyorsan.

"Ha elkészülnek backupolod őket?"
Nem szukseges, eldobhato kontenerek.

"Aztán ha módosítasz bennük, akkor újra? És mivel módosítasz? Jó esetben config managementtel."
A template-n modositasz. A kontenerek ujrahuzasat meg azzal manageled, amivel jol esik.

"Ha csak egy konténered van, akkor meg remeghetsz, hogy ez az volt-e, ami legutoljára még futott."
Nem ertem. Ezeknel pont a jo skalazashatosag a szempont. Egy kontener eletciklusa lehet csak percekben merheto, szoval eleg hamar kiderulne, ha szar a template.

"Meg itt nem 1 konténer van, hanem a jó kis microservices felfogással vagy 10. 10x10 másodperc?"
Es mind egyszerre halt meg? Amugy jo esellyes nem csak egy kontener futtat egy adott szolgaltatast, szoval ha kiesik egy, akkor kiszolgalja egy masik a kerest.

"Annyira nem indulnak el azok sem gyorsan."
Miert nem? Tobbnyire csak konfiguracio tortenik, nem telepit semmit (egy app server is el tud indulni viszonylag rovid ido alatt). Ahogy mar fentebb is irtak, ez csak par masodperc. De ha jol van osszerakva a service, akkor ez sem kritikus dolog, kiszolgalja addig mas.


A template-n modositasz. A kontenerek ujrahuzasat meg azzal manageled, amivel jol esik.

Tehát az OpenStack üzemeltetéséhez felhúzol valamit, ami konténereket deployol. De azt is HA-ba kell ám, nem? És ezt a deployoló rendszert mivel húzod fel? :)


Es mind egyszerre halt meg? Amugy jo esellyes nem csak egy kontener futtat egy adott szolgaltatast, szoval ha kiesik egy, akkor kiszolgalja egy masik a kerest.

Igen egyszerre, mert egy gépen fut az összes szervíz, de persze egy szolgáltatást 3 konténer futtat 3 különböző gépen. Tehát van kb. 10 konténered, 3 gépen, azaz 3x10.


Egy kontener eletciklusa lehet csak percekben merheto

Szép is lenne, ha a MySQL, meg a nova csak percekig futna :) Ezt elindítod, aztán addig fut, amíg ki nem kapcsolod alóla vasat (vagy meg nem döglik).

Itt most nem a Túró Rudi honlapjáról beszélünk, ami, ha nyereményjáték van, akkor el kell indítani 20 szerveren, máskor megy 1 is elég neki. Infrakstruktúra vezérlésről van szó, adatbázissal, message queue-val, és jópár REST szervízzel.

abbol, amit itt valaszolsz az embereknek, ket dologra tudok kovetkeztetni:
- vagy egyaltalan nem erted ezeket a technologiakat olyan szinten, amilyenen kene ahhoz, hogy megertsd a kommenteket (stateless, tobbszorosen redundans szolgaltatas konteneret minek backupolni?)
- vagy csak annyira bekovesedett munkahelyen dolgozol, hogy beledegettek a hulyeseget, es mar keptelen vagy valtozni (virtualizaltok ti? biztos? :))

a harmadik lehetoseg mondjuk hogy direkt trollkodsz, de ANNYIRA nem vagy jo, hogy elhigyjem, igy marad az elso ketto valamelyike. mas nem tudja megmagyarazni azt a szintu felremagyarazast es nemertest, ami itt megy.

Inkább én vagyok begyöpösödött, és sosem fogom felfogni, hogy magát az OpenStack infrát mi az istennek konténerizáljam? Meg azt sem, hogy a benne levő MySQL meg RabbitMQ az mitől lesz stateless? De én már tényleg kiszállok ebből, már eddig sem volt kedvem elmenni a vitában.

> én vagyok begyöpösödött,
Jó, hát ezen mi nem tudunk segíteni.

> mi az istennek konténerizáljam? Meg azt sem, hogy a benne levő MySQL meg RabbitMQ az mitől lesz stateless?
/o\ Az a gond, hogy amikor próbáljuk elmagyarázni, akkor sem próbálod megérteni, csak a magad butaságát hajtogatod. Az ÖSSZES OpenStack service stateless (mint ahogy bármely microservice architektúrában), hiszen nem tárol adatot, hanem feldolgoz. A datastore-od, ami viszont tárol (aka: source of truth, tehát nem stateless) nem kell konténerizálni, mivel nagy valószínűséggel eleve valamilyen HA/cluster setupban van - ettől függetlenül persze megteheted.

Olvass utána ezeknek, mert úgy látszik a legnagyobb zavart a hiányos tudásod okozza. Egész jó blogok-könyvek születtek már scalability/HA témában. Emellett a meetupon pedig hús-vér emberektől is érdeklődhetsz, ki, hogy, és mit csinál.

Szerintem sose fog egyezni a véleményünk. Ha egyszerű telepíteni, javítani is egyszerű. Ne azért kapjak már kib. nagy fizetést, mert valami obscure szarral dolgozom. Heattel, Kubernetessel managelni magát az Openstack infrát (ami mondjuk jó esetben 3 kontroller) meg agyrém. Amúgy a tripleo sem 30 sec alatt telepít openstackket, akárhogy is nézzük (pedig az Heat-tel csinálja).
Az én ideális világom: kiesett egy kontroller, a többi a HA miatt átveszi a szerepét, hardver csere után meg 20 perces újratelepítés (csak ami kiesett), és újra döcög.

Egyszerű lehet, de sosem lesz meg 30mp alatt. Ha te az egyszerűségre gyúrsz, nem pedig a gyors respawnra, sose fog kelleni senkinek a tudásod. Vagy amikor épp ég a ház, és folynak ki a kemény pénzek a cégtől mert nem állnak szolgáltatások, akkor épp a főnökségnek mutogatod, milyen EGYSZERŰen feltelepül fél-egy óra alatt a csilivili whatever? Nem hiszem.

Ha eleve HA, akkor nincs szükség 30sec-es respawnra. És mint ahogy mondtam, a tripleO sem oldja meg 30 sec alatt az újarindítást. Meg az ansible-openstack sem. Ha behal egy vas, akkor az OS-t úgyis újra kell rajta húzni (vagy egy másikon). Ha meg már ott állna készenlétben egy OS controllernek, akkor miért ne működhetne eleve a clusterben? Itt most nem arról beszélünk, hogy egy fingós webapp azonnal induljon újra, mindegy hogy hol, csak fusson, hanem az alapinfrastruktúráról, ami mindenképp fizikai vashoz fog kötődni.

> a fejlesztői környezet egy spagetti shell script
A fejlesztői környezet felpakol neked minden csomagot és gitből behúzza a projekteket. A shell szkriptek pontosan erre valók, hogy automatizálják a sok git parancsot és elindítsák az egyes szoftvereket. Ha te írnád meg, miben írnád?

Szerinted mennyivel lenne lassabb ansible -el ?

Talan en vagyok az egyetlen aki szerint az ansible sem eleg gyors/hatekony komplex feladatra ? :)
De arra altalaben eleg jo hogy atmasolj egy nagy shell scriptet (vagy mashogy beszerezed) es futatasd a megfelelo parameterekel.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

devstack valoban nem idempotents modon van megirva, ez nem a shell hibaja. Egyeszeruen nem volt tervzesi cel, megha nahany resz idempontens is.

Ha az ./unstack.sh nem takarit eleg jol egy kovetkezo futatashoz az bug.

Mit hianyolsz az elesre hasonlitasbol ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Pl. egy installer alkalmas lehetne dev környezet és éles felhúzására is. Miért kell egy shell script dev-nek, meg valami más élesre? Max. annyi a különbség, hogy honnan jönnek a csomagok, meg hogy HA vagy nem HA. De ha tudsz HA-t tesztelni mondjuk a dev-en, az meg pláne nem baj.

Elvileg most is tudnal HA-t,

Lehetseges az adatbazist es messaging szervicet ugy felinstallani ahogy te akkarod HA -ban,
es csak elmondani devstacknek, hogy hol vannak.

LB VIP -et megadhatod service hostnak, es betolhatod a devstack nodjaidat moge.

Tobbet csinalni ezokbol a servicekebol amik magukat registraljak AMQP-n (pl. n-cpu), eleg egyszeru...

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Szóval a devstack script ebben sem segít. Akkor csinálsz egy installert, ami felhúz HA-ban vagy anélkül rabbitot, galerát, memcachet. És megvan a devstack egy része. Én inkább úgy érzem, azért van devstack, mert nem volt más, és fejleszteni meg kellett valahol. Aztán mivel egyik installer sem sikerült elég "könnyűre", maradt ez.

devstack -et valoban nem ajanlott siman felteni a notebookodra, test gepekre, vm -ekere van kihegyezve,
lehetnek destructive bugok a devstackben. En reges regen rendszeresen hasznaltam VM-em nelkul a notebookomon, csak egyszer okozott kellemetlen meglepetest, de hamar helyre hoztam.

"devstacken működik :)", van polo ilyesmi felirattal :)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Sziasztok!
Úgy látom vannak itt olyan hozzászólók, akik nem igazán ismerik az OpenStacket és mondják, hogy ez milyen gáz. Először én is ezt gondoltam. Engedjétek meg, hogy meséljek a saját sztorimról.
Úgy kerültem kapcsolatba az Openstackkel, hogy egy korábbi munkahelyem főnöke előállt, hogy neki OpenStack kell. Gondoltam remek, azt sem tudom mi az (előtte magával a virtualizációval sem igazán foglalkoztam). Szóval fogtam magam és egy barátom javaslatára elmentem pár meetupra. Az első pár meetupon úgy ültem ott, mint a kuka, nem sokat értettem az egészből. Aztán rájöttem,hogy meg kell barátkozni a virtualizációs dolgokkal, mint az openvswitch és a többiek. Továbbá szükséges egy szemlélet váltás ahhoz, hogy a jól megszokott világból bele tudjak szokni ebbe a nagy virtualizációs őrületbe. Szóval nekiültem és ismerkedtem a rendszerrel. Sokakkal ellentétben, nekem nem jött át a devstack, így mindjárt durr bele a közepébe. Elkezdtem virtualboxban építeni a rendszert. Először csak a Mirantis féle deploy eszközzel építettem rendszereket. Akinek a next-next-finish megoldás kell azoknak ez a legközelebbi megoldás az Openstack tanulásához. Utána elkezdtem utánaolvasni a kapcsolódó technológiáknak, miközben elmerültem az Openstack rejtelmeiben és konfigurációs lehetőségeiben is. Majd elkészült az első rendszer még Icehouse-on. Ami még pikánsabbá tette a dolgot, hogy a compute-ok docker konténereket futtattak, mert ez volt az elvárás. Később kerültem a mostani helyemre, ahol egy komplett OpenStack cloudot kell építeni. Itt még jobban elmerültem főleg a hálózati és a CEPH backend dolgokban és ott tartok,hogy Ansible-ben megírtam egy saját OpenStack HA rendszert. Már meg is van következő hely, ahova megyek cloudot építeni,mert megkerestek olyan fizut ajánlottak, amit nem tudtam visszautasítani. Sajnos a meetup-ok mostanában háttérbe szorultak ,de a legközelebbire megpróbálok elmenni. A történetem tanulsága, hogy ez is egy új dolog bele kell tanulni és utána lehet használni. Akinek nem szimpatikus vagy nem akar időt beleölni, az keressen másik megoldást. Nem vagyunk egyformák, nekem bejött:)

Update: Most látom 21-én lesz, sajnos nem érek rá, de egy másik alkalommal akár mesélhetek is a sztorimról részletesen, ha lesz rá igény.

Nem az enyém nem konténerekbe deployol :)
Azért nem, mert a fizikai vasakra telepítjük vele az OpenStacket. A játszótértől kezdve a production rendszerig.

"akik nem igazán ismerik az OpenStacket és mondják, hogy ez milyen gáz
Ezt magamra vettem :)"

Én is ebből a mondatból indultam annó kb. szóval még van esélyed jó openstack guruvá kinőni magad :)

Végülis, igaza is lett annak a bohócnak..

Na de tényleg. Nem a legjobb-szebb-okosabb openszósz projekt ez, viszont tényleg tökingyen van, és ha rászánod az időt (igen, kevesebb ez a rászánt idő pénzben, mint amennyibe a vmware licensz kerül, és akkor még self provisioning sincsen), akkor igenis lehet benne alkotni. Az meg egy plusz, hogy ha valami hiányzik, implementálhatod magadnak (ilyet vmwarenél bajosabb), és még ingyenjegyet is kapsz a világkörüli summit turnék egyikére.

Szóval sírás helyett contributolj, vagy fizess, és akkor kiszolgálnak. Nincs ingyen ebéd.

Szerintem teljesen használható. Az tény, hogy ha kihagyod a tanulási folyamatot, akkor érhetnek meglepetések, és okozhat frusztrációt. Egyébként meg szerencsére teljesen open-source, szóval ha valamiről úgy érzed, jobban is lehetne csinálni, lehetőség van visszacontribolni bármit, ha gondolod, szívesen segítünk benne.