Openstack kornyezet

Virtualizáció

Sziasztok,

A cegnel ugy dontottunk, hogy osszerakunk magunknak egy privat felhot Openstack-kel, amibe kesobb at tudunk koltozni (most Proxmox-ot hasznalunk).
Abba az iranyba, hogy miert openstack, most nem nagyon szeretnek elmenni. Tomoren annyi, hogy tapasztalatot kell gyujtenem Openstack-et illetoen.

A koltsegvetes viszonylag korlatozott, de arra eleg, hogy vegyunk 2 olyan szervert, amibol egy is eleg lenne, figyelembe veve az eddigi igenyeket, a redundancian kivul.
A terv az, hogy egyenlore egy vason fut minden Openstack szerviz. A Compute node komponensek direktbe telepitve a host OS-en, a Control meg Network node komponensek egy-egy manualisan (ertsd: Openstack-en kivul) menedzselt KVM virtualis gepen futnanak, hogy ha koltoztetni kell oket, akkor konnyeden megtehessuk.

Amiert irok, az az, hogy nem igazan tudom eldonteni, hogy milyen modszerrel tegyem redundansa a rendszert. Mint emlitettem, 2 egyforma fizikai szerver all rendelkezesre. A jelenlegi tervem az, hogy drbd, corosync es pacemaker-rel letrehozok egy aktiv/passziv cluster-t. Egy harmadik gepet is berakok csak hogy legyen rendes quorum, de azon semmi egyeb nem fog futni. Amiben nem vagyok biztos, az a fajlrendszer illetve a replikacio. DRBD 8 csak Aktiv/Passziv modot tud, igy ha a jovoben ujabb szerverre lenne szukseg, csak kettesevel lehetne boviteni. DRBD helyett Ceph jott meg szoba, de azt elvetettem mivel joval lassabb az adott korulmenyek kozott, mint a DRBD. DRBD folott LVM-et akarok hasznalni a virtualis gepekhez.
A gepekben vegyesen lesznek SSD-k es SAS vinyok, illetve 10 Gigabites halokartyakkal lesznek szerelve.
Konkret kerdesem az, hogy a helyemben ti hogy replikalnatok az egyik szerver tartalmat a masikra ugy, hogy az irasi sebesseg ne essen a beka feneke ala?

Udv:
zb

  • 3010 megtekintés

( bazso | 2019. 04. 04., cs – 07:11 )

Hacsak nem tanulni akarsz, neked nem openstack kell. Nézd meg a referencia architektúrát, ennyi fizikai node-on nem lehet rendesen megcsinálni.
Ha a 3 szerver közt a doksiban talált módon kezded szétszórni a funkciókat, akkor valamennyire működő, még mindig nem ideálisan szeparált, de legalább valóban redundáns környezetet kapsz.
A többi említett technológia segítségével egylábas, csak és kizárólag fejlesztői/teszt célokra való kialakítást szigszalagozol, hogy hátha 2 játék már nem játék

>Hacsak nem tanulni akarsz, neked nem openstack kell.
Ezt mire alapozod?

>Nézd meg a referencia architektúrát [..] Ha a 3 szerver közt a doksiban talált módon kezded szétszórni a funkciókat, akkor valamennyire működő, még mindig nem ideálisan szeparált, de legalább valóban redundáns környezetet kapsz.
Melyik doksira gondolsz pontosan? Az "OpenStack Architecture Design Guide" https://docs.openstack.org/arch-design/ nem targyalja a kulonbozo szervizek szeparaciojat es a redundanciaval kapcsolatban is csak annyit emlit, hogy ha HA-t akarsz, akkor 3 fizikai szerverre lesz szukseg (a quorum miatt).
A HA guide https://docs.openstack.org/ha-guide/ ugyanugy Pacemaker-rel "szigszalagoz", ahogy en is tervezem es szinten nem targyalja szeparaciot.

Az egyetlen hely ahol latvanyosan szeparaljak a szervizeket fizikai node-ok kozott, az az install guide example architecture-je https://docs.openstack.org/install-guide/overview.html#example-architec…, de itt meg nincs szo redundanciarol.

A mukodokepessegnek egyaltalan nem feltetele, hogy kulon gepen fusson minden. Az example architecture meg nem valosit meg semmilyen redundanciat. Szoval ha be tudnad linkelni, hogy melyik doksira hivatkozol, az nagy segitseg lenne.

Semmi gond nincs a proxmox-al, nagyon jol vegzi a dolgat.
Az az egy baja, hogy nem openstack. Tobb projectunk is van, ahol olyan szoftvert fejlesztunk, ami openstack-kel kommunikal es alapvetoen openstack kornyezetben fut. Van mar hazon belul ket openstack peldanyunk fejleszteshez es teszteleshez, azonban, azt az openstack peldanyt ahol elesben futnak a szoftvereink nem mi tartjuk karban. Szeretnenk tapasztalatot gyujteni uzemeltetes teren is, ezert valtunk opnestack-ra hazon belul.

( mrmartin v | 2019. 04. 05., p – 11:06 )

Szerintem ne csináld. 12 node alatt nem telepítünk OpenStack-et nem véletlenül.

Nem tudsz rendes failovert csinálni.
3 node-dal szerintem lehet rendes failovert csinalni, de javitsatok ki.

Nem lesz elég a teljesítménye.
Mire? Se szerver specifikaciot nem emlitettem, sem use case-t.

nehéz / gazdaságtalan lesz üzemeltetni
Nem hiszem, hogy sokkal nehezebb lenne, mint 12 node-ot.
Gazdasagtalannak valoszinuleg gazdasagtalan lesz, azt alairom. De ez jelen esetben nem szempont.

Meg egyszer, a cel az, hogy tapasztalatot gyujtsunk eles openstack uzemeltetes teren, de ezt mar leirtam a temaindito postban is. Ez egy folyamat, amit valahol el kell kezdeni. Van ra x millionk, meg egy terv, ami vagy jo vagy nem. Legrosszabb esetben megy vissza a proxmox. Lehet, hogy masok be tudnak aldozni 20-50 milliot egy fel szekrennyi szerverre csak mert valaki azt mondta, hogy allitolag minimum annyi kell egy rendes cloud-hoz. Mi sajnos nem.

Nincs meg kello tapasztalatom ezen a teren, nyitott vagyok a kritikara a tervet illetoen. Ezert nyitottam a temat es irtam le tagabb kontextust. De ad-hoc szamokkal, mint ket szekrennyi szerver, vagy 12 node egyszeruen nem tudok mit kezdeni.

Az openstack oldalan is csak nagyon homalyos utalasok vannak ebben a tekintetben. A legkonkretabb specifikacio az volt, hogy egy rack-nyi compute node-hoz a controller node-nak kb 8 CPU core-ra es 16GB RAM-ra van szuksege. De ez is kb nesze semmi fogd meg jol. Egy rack-nyi compute node nagyon sok mindent jelenthet. Mekkora szerverek? 1U vagy 4U? Mennyi procival? 8 Core vagy 56?

"A koltsegvetes viszonylag korlatozott, de arra eleg, hogy vegyunk 2 olyan szervert". Ebből arra következtetek, hogy még nincs megvéve semmi. Ha ez amúgy is csak egy kipróbálása az Openstack-nek, akkor nem lehet-e jobb az a megoldás, hogy dedikált hardvert béreltek? Tehát ahelyett, hogy veszel 2 szervert, bérelsz mondjuk többet néhány hónapra?

Értem, ez ilyen kísérletezési szakaszban van, jó játék lesz. Általában ezeknek a storyknak az a vége, hogy szar az OpenStack :) Pedig nagyon alap kérdések, milyen vas, mennyi CPU, storage hogyan van alatta (DRBD-s telepítést nem láttam az elmúlt pár évben, nem is értem hogyan működne és lenne skálázható, de aztán lehet hogy senki se ért hozzá), hálózatról nem is beszélve. Itt azért van egy arany középút, ha alálősz akkor borzalmas lesz a teljesítménye, ha meg fölé akkor meg kidobsz egy csomó pénzt az ablakon.

"3 node-dal szerintem lehet rendes failovert csinalni, de javitsatok ki." nem tudom a kollega mire gondolt, de abbol amit leirt nekem ez jon le. Papiron megcsinalod a HA-t, lesz failover. Aztany nyilvan kihasznaltsag fuggo, de ilyen keves node altalaban meg van jaratva, de elhalalozik az egyik node, es annak a nodenak a 80%-os terheleset kell atteni ket masik szinten 80%-on uzemelo node-ra. Nem beszelve, hogy valamelyik nyilvan haztaji munkat is vegez. Szoval meretezni kell a failovert is, es keves nodeszam eseten nehez. Mi van ha ket node is kiesik, kez a katasztrofa. En nem allitom, hogy a 12 gep kell, csak azt, hogy a 3 node az az elmeleti minimum, de semmikepp nem egy optimalis, foleg ha olyan kornyezetrol beszelunk (kube, openstack), ahol nehez kallkulalni a kihasznaltsagot, mert a userek szabadon inditgatnak rajta dolgokat.

-
First impressions of the new Cloud Native programming language Ballerina

( kallaics | 2019. 04. 06., szo – 07:48 )

Ne dőlj be a marketingnek. Az Openstack jó, tényleg csak a nagyoknak éri meg!
Volt szerencsém Openstack-et üzemeltetni és bátran mondhatom, hogy nagyon komoly tudás kell hozzá! Ezt addig nem érzed át még működik, de amint elromlik valami, akkor ahhoz elég komoly tudás jön képbe, hogy meg tudj oldani egy komplex issue-t! Olyan szintű tudást kell felvenned, ami bőven meghaladja egy ember képességeit! Legyél guru a virtuizációban, storageban, networkben, python-ban, adatbázisban, ha-ban stb.
Ezzel nem elijeszteni akarlak, csak szeretném, hogy lásd mennyire nem könnyű egy rendszer üzemeltetése. A tervezés még szóba sem került! Olvasd el a többiek által linkelt doksikat es látni fogod már a tervezés is komoly dolog! Nem beszélve az upgrade-ek tervezéséről és végrehajtásáról úgy, hogy a rendszer nem állhat meg.
A cloud üzemeltetés azoknak a cégeknek jött be igazán, akik szinte csak ezzel foglalkoznak. Dedikáltan minden egyes területére az Openstack komponensekhez vesznek fel szakembereket! Storage, Network, Virtualizáció, Security területekre. Sok nálatok nagyobb cég bukott már ebbe bele, ezért veszik a nagyoktól inkább, ha akartak cloud-ot.

Ha tanulni akarsz, akkor javaslom olvasd el az architektúrákat, a telepítési leírásokat, illetve van angol nyelvű könyv is, dobj fel egy AIO (All In One) gépet és azon kezdj el tanulni.

Könyvek:

Apress: Certified Openstack Administrator Study Guide
Vyas: Applied Openstack Design Patterns
Openstack for Architects

Hajrá!

pilotavizsgasnak pilotavizsgas, ezt szerintem senki nem tagadja aki latott mar kozelebbrol ilyet, de nem hiszem, hogy meghaladja ez egy ember kepessegeit, en ismerek tobb embert (magamat is ideertve, illetve a mostani csapatomat a cegnel) aki nullarol fel tud huzni egy OpenStack-et, ugy, hogy erti is mi tortenik, es debuggolni is tudja... na jo, a halozaton elvereznek az emberek, de addig! :P

a tobbi resszel sem ertek egyet, 2-3 gepen is tokeletesen lehet hasznalni.

szerintem hibas elkepzeles ez, hogy kene piszkalnia egyaltalan. erre vannak a standard megoldasok, mint pl a BGP EVPN VXLAN-nal, ha kell igazi multitenancy. aztan mar teljesen mindegy, hogy Cisco, Arista, vagy akarmi fut.

persze ehhez pont nincs jo tamogatas upstream jelenleg, mi megirtuk volna szivesen, de nem fogadtak el a talkot a summitra, igy nem fogok idot beleolni, hogy upstream-kepesse tegyek BARMI kodot, a belso gitben lesz jelenleg.

mi BGP-n hirdetjuk be a VMek /32-jet, a halozat Cumulus - ez az uj felallas. a regiben siman provider network volt, no fuss.

2-3 gépen max- játszani lehet, de egy full HA deploymenthez édes kevés. Ezért is írtam,hogy kicsiben nem éri meg játszani.

Nem tudom ti mekkora méretben és mennyi komponenssel játszotok, hányféle compute node-dal pl, de én egy 5000-6000 gépes, több site-os rendszerben szereztem a tapasztalatokat, ami közel AWS funkcionalitást takart. Ott már nem csak az alap komponensek vannak :)
A hálózat se piskóta, pláne ha openvswitch is van az implementációban.

nem letezik. en osszeraktam egy daemont ami berakja a VMek IPjet a table 10-be a kernelbe (https://github.com/zoltan/neutron-l3-distributor) majd azt tovabbhirdetem BGP-vel. minden hypervisoron van anycast gw, igy a hypervisort mar nem hagyja el L2 csomag.

a VMekben /32-es netmaskot hasznalunk.

( NagyZ v | 2019. 04. 06., szo – 11:42 )

a konkret kerdesre a valasz: a drbd/corosync/pacemaker halalnak hangzik, persze ha birod a szado mazot es nem gaz ha lehal az egesz a francba, akkor hajra! a rendes megoldas 2 gepnel az, hogy veszel kulso storage-dzset ;), de mivel nem irtal semmit arrol, hogy mit jelent az "irasi sebesseg" (qd? bs? mi az elvart p95, p99?), igy semmit nem lehet mondani ra.

SAS halott termek igy 2019-ben, NVMet kell mindenhova rakni, olcso, a 10 giga meg szinten halott, 25 gigas kartyak/eszkozok (/port) kb ugyanolyan arban vannak mar

ja es meg egy ingyen tanacs: vegyel 3 v 4 gepet 2 helyett, ne szivasd magad.

( Zsugabubus | 2019. 04. 06., szo – 14:52 )

2 géppel maradj DRBD+KVM-nél, ha nem akarod magad túlságosan szívatni. Persze ha mazochista vagy, akár 1 gépen is lehet OpenStacket használni.

( kallaics | 2019. 04. 07., v – 08:47 )

Ha OpenStack-et akarsz tanulni, akkor keress rá a FuelWeb megoldásra. Nem tudom, hogy halad projekt jelenleg, de tanuláshoz jó lehet.

( uid_21239 | 2019. 04. 16., k – 20:05 )

Koszi mindenkinek a hozzaszolast.
Be kellett latnom, hogy 2+1 geppel tenyleg csak maszatolni lehet. A projectet felfuggesztjuk amig nem engedhetunk meg magunknak tobbet.