Miközben az informatikában dolgozik, kezdi észrevenni, hogy a rendszereknek megvan a maguk karaktere. Lehetnek rugalmasak, csendesek, különcek és szigorúak. Vonzhatják vagy taszíthatják. Így vagy úgy, „tárgyalni” kell velük, lavírozni a „csapdák” között, és láncokat kell építeni interakciójukból.
Így ért bennünket az a megtiszteltetés, hogy felépítettünk egy felhőplatformot, ehhez pedig „meg kellett győznünk” pár alrendszert, hogy működjenek együtt velünk. Szerencsére van egy „API nyelvünk”, közvetlen kezeink és nagy a lelkesedésünk.
Ez a cikk technikailag nem lesz kemény, de leírja azokat a problémákat, amelyekkel a felhő építése során találkoztunk. Elhatároztam, hogy egy könnyed technikai fantázia formájában leírom az utunkat arról, hogyan kerestük a közös nyelvet a rendszerekkel, és mi sült ki belőle.
Üdvözöljük a macskában.
Elején az utazás
Néhány évvel ezelőtt csapatunk azt a feladatot kapta, hogy egy felhőplatformot indítson el ügyfeleink számára. Vezetési támogatásunk, erőforrásaink, hardververemünk és szabadságunk volt a technológia kiválasztásában a szolgáltatás szoftveres részének megvalósításához.
Számos követelmény is volt:
- a szolgáltatásnak kényelmes személyes fiókra van szüksége;
- a platformot integrálni kell a meglévő számlázási rendszerbe;
- szoftver és hardver: OpenStack + Tungsten Fabric (Open Contrail), amelyet mérnökeink elég jól megtanultak „főzni”.
A csapat összeállításáról, a személyes fiók felületének kialakításáról és a tervezési döntések meghozataláról egy másik alkalommal beszámolunk, ha a Habra közösség érdekli.
Az általunk használt eszközök:
- Python + Flask + Swagger + SQLAlchemy - egy teljesen szabványos Python készlet;
- Vue.js a frontend számára;
- Úgy döntöttünk, hogy az összetevők és szolgáltatások közötti interakciót a Celery használatával végezzük az AMQP-n keresztül.
A Python kiválasztásával kapcsolatos kérdésekre várva elmagyarázom. A nyelv megtalálta a rést cégünkben, és egy kicsi, de mégis kultúra alakult ki körülötte. Ezért úgy döntöttek, hogy elkezdik rá építeni a szolgáltatást. Sőt, az ilyen problémákban gyakran a fejlődés sebessége a döntő.
Tehát kezdjük az ismerkedést.
Néma Bill – számlázás
Régóta ismerjük ezt a srácot. Mindig mellettem ült és némán számolt valamit. Előfordult, hogy felhasználói kéréseket továbbított nekünk, ügyfélszámlákat állított ki, és szolgáltatásokat menedzselt. Közönséges szorgalmas srác. Igaz, voltak nehézségek. Csendes, néha megfontolt és gyakran a saját gondolataira gondol.
A számlázás az első rendszer, amellyel megpróbáltunk barátkozni. És az első nehézség, amellyel a szolgáltatások feldolgozásakor találkoztunk.
Például egy feladat létrehozásakor vagy törlésekor a belső számlázási sorba kerül. Így a szolgáltatásokkal való aszinkron munka rendszere valósul meg. A szolgáltatástípusaink feldolgozásához ebbe a sorba kellett „helyeznünk” a feladatainkat. És itt beleütköztünk egy problémába: a dokumentáció hiányába.
A szoftver API leírásából ítélve ezt a problémát még meg lehet oldani, de nem volt időnk visszafejteni, ezért kivettük a logikát és a RabbitMQ tetejére feladatsort szerveztünk. Egy szolgáltatás műveletét az ügyfél kezdeményezi a személyes fiókjából, amely Celery „feladattá” alakul a háttérben, és a számlázási és az OpenStack oldalon történik. A Zeller kényelmessé teszi a feladatok kezelését, az ismétlések szervezését és az állapot figyelését. A „zellerről” többet olvashat, pl. .
Ezenkívül a számlázás nem állított meg egy projektet, amely kifogyott a pénzből. A fejlesztőkkel kommunikálva rájöttünk, hogy a statisztika számításánál (és pontosan ezt a logikát kell megvalósítanunk) a leállítási szabályok bonyolult kölcsönhatása áll fenn. De ezek a modellek nem illenek jól a valóságunkhoz. A Celery-n lévő feladatokon keresztül is megvalósítottuk, a szolgáltatáskezelési logikát a háttéroldalra vittük.
Mindkét fenti probléma miatt a kód kissé felduzzadt, és a jövőben át kell alakítanunk, hogy a feladatokkal való munka logikáját egy külön szolgáltatásba helyezzük át. Ezen logika támogatása érdekében táblázatainkban tárolnunk kell néhány információt a felhasználókról és szolgáltatásaikról.
A másik probléma a csend.
Billy némán „OK”-val válaszol néhány API-kérésre. Ilyen volt például, amikor a teszt során teljesítettük az ígért kifizetéseket (erről később). A kéréseket megfelelően teljesítették, és nem láttunk hibát.
A naplókat kellett tanulmányoznom, miközben a rendszerrel dolgoztam a felhasználói felületen keresztül. Kiderült, hogy a számlázás maga hajt végre hasonló kéréseket, megváltoztatva a hatókört egy adott felhasználóra, például adminra, átadva azt a su paraméterben.
Általánosságban elmondható, hogy a dokumentáció hiányosságai és a kisebb API-hibák ellenére minden jól ment. A naplók még nagy terhelés mellett is olvashatók, ha tisztában van a felépítésükkel és mire kell figyelni. Az adatbázis felépítése díszes, de meglehetősen logikus és bizonyos szempontból vonzó is.
Összefoglalva tehát, a fő problémák, amelyekkel az interakciós szakaszban találkoztunk, egy adott rendszer megvalósítási jellemzőihez kapcsolódnak:
- dokumentálatlan „tulajdonságok”, amelyek így vagy úgy hatással voltak ránk;
- zárt forráskódú (a számlázás C++-ban van írva), ennek következtében az 1. feladatot nem lehet más módon megoldani, mint a „próbálkozás és hiba” módszerét.
Szerencsére a termék meglehetősen kiterjedt API-val rendelkezik, és a következő alrendszereket integráltuk személyes fiókunkba:
- technikai támogatási modul – a személyes fiókjából érkező kérések „meghatalmazottan” kerülnek a számlázásra a szolgáltatási ügyfelek számára átláthatóan;
- pénzügyi modul - lehetővé teszi számlák kiállítását a jelenlegi ügyfelek számára, leírásokat és fizetési dokumentumok generálását;
- szervizvezérlő modul - ehhez saját kezelőt kellett megvalósítanunk. A rendszer bővíthetősége a kezünkre játszott, és Billyt „megtanítottuk” egy új típusú szolgáltatásra.
Kicsit gond volt, de így vagy úgy, azt hiszem, Billyvel ki fogunk jönni.
Séta volfrámmezőkön – Tungsten Fabric
Huzalok százaival tarkított volfrámmezők, amelyek több ezer bitnyi információt adnak át rajtuk. Az információkat „csomagokba” gyűjtik, elemzik, összetett útvonalakat építenek, mintegy varázsütésre.
Ez a második rendszer tartománya, amellyel meg kellett barátkoznunk - a Tungsten Fabric (TF), korábban OpenContrail. Feladata a hálózati eszközök menedzselése, szoftver absztrakciót biztosítva nekünk, felhasználóknak. TF – SDN, magába foglalja a hálózati berendezésekkel végzett munka összetett logikáját. Magáról a technológiáról van egy jó cikk, pl. .
A rendszer integrálva van az OpenStack-kel (lásd alább) a Neutron bővítményen keresztül.
Az OpenStack szolgáltatások interakciója.
Az üzemeltetési osztály srácai ismertettek meg minket ezzel a rendszerrel. A rendszer API-ját használjuk szolgáltatásaink hálózati kötegének kezelésére. Ez még nem okozott nekünk komoly problémát vagy kellemetlenséget (az OE-s srácok nevében nem tudok beszélni), de voltak furcsaságok az interakcióban.
Az első így nézett ki: azok a parancsok, amelyek SSH-n keresztül történő csatlakozáskor nagy mennyiségű adat kiadását követelték meg a példánykonzolon, egyszerűen „leakasztották” a kapcsolatot, míg VNC-n keresztül minden megfelelően működött.
Aki nem ismeri a problémát, annak elég viccesnek tűnik: az ls /root megfelelően működik, míg például a top teljesen „lefagy”. Szerencsére korábban is találkoztunk hasonló problémákkal. Úgy döntöttek, hogy hangolták az MTU-t a számítási csomópontoktól a routerekig vezető útvonalon. Egyébként ez nem TF probléma.
A következő probléma a sarkon volt. Egy „szép” pillanatban eltűnt az útválasztás varázsa, csak úgy. A TF leállította az útválasztás kezelését a berendezésen.
Az Openstack-kel az adminisztrátori szintről dolgoztunk, majd átléptünk a szükséges felhasználói szintre. Úgy tűnik, hogy az SDN „eltéríti” annak a felhasználónak a hatókörét, aki a műveleteket végrehajtja. A tény az, hogy ugyanazt a rendszergazdai fiókot használják a TF és az OpenStack összekapcsolására. A felhasználóra váltás lépésénél a „varázslat” eltűnt. Úgy döntöttek, hogy külön fiókot hoznak létre a rendszerrel való együttműködéshez. Ez lehetővé tette számunkra, hogy az integrációs funkcionalitás megszakítása nélkül dolgozhassunk.
Silicon Lifeforms – OpenStack
Volfrámmezők közelében él egy furcsa alakú szilikonlény. Leginkább egy kinőtt gyereknek tűnik, aki egy lendítéssel össze tud törni minket, de nyilvánvaló agresszió nem jön belőle. Nem kelt félelmet, de mérete félelmet kelt. Ahogy a körülötte zajló események összetettsége is.
Az OpenStack platformunk magja.
Az OpenStack számos alrendszerrel rendelkezik, amelyek közül jelenleg a Novát, a Glance-t és a Cindert használjuk a legaktívabban. Mindegyiknek saját API-ja van. A Nova a számítási erőforrásokért és a példányok létrehozásáért, a Cinder a kötetek és pillanatképek kezeléséért, a Glance egy képszolgáltatás, amely az operációs rendszer sablonjait és a rajtuk lévő metainformációkat kezeli.
Minden szolgáltatás egy konténerben fut, és az üzenetközvetítő a „fehér nyúl” - RabbitMQ.
Ez a rendszer okozta nekünk a legváratlanabb bajt.
És az első probléma nem váratott sokáig magára, amikor megpróbáltunk egy további kötetet csatlakoztatni a szerverhez. A Cinder API határozottan megtagadta ennek a feladatnak a végrehajtását. Pontosabban, ha magának az OpenStack-nek hisz, a kapcsolat létrejön, de nincs lemezeszköz a virtuális szerveren belül.
Úgy döntöttünk, hogy kitérőt teszünk, és ugyanezt a műveletet kértük a Nova API-tól. Az eredmény az, hogy az eszköz megfelelően csatlakozik, és elérhető a szerveren belül. Úgy tűnik, hogy a probléma akkor jelentkezik, ha a blokktárolás nem reagál a Cinderre.
Egy másik nehézség várt ránk a lemezekkel való munka során. A rendszerkötetet nem lehetett leválasztani a szerverről.
Ismét maga az OpenStack „esküszik”, hogy tönkretette a kapcsolatot, és most már külön-külön is megfelelően dolgozhat a kötettel. De az API kategorikusan nem akart műveleteket végrehajtani a lemezen.
Itt úgy döntöttünk, hogy nem harcolunk különösebben, hanem megváltoztatjuk a szolgáltatás logikájával kapcsolatos nézetünket. Ha van példány, akkor rendszerkötetnek is kell lennie. Ezért a felhasználó még nem tudja eltávolítani vagy letiltani a rendszer „lemezét” a „kiszolgáló” törlése nélkül.
Az OpenStack egy meglehetősen összetett rendszerkészlet, saját interakciós logikával és díszes API-val. Segítségünkre van a meglehetősen részletes dokumentáció és természetesen a próba- és hibázás (hol lennénk nélküle).
Tesztfutás
Tavaly decemberben tesztindítást végeztünk. A fő feladat az volt, hogy a projektünket harci módban teszteljük technikai oldalról és UX oldalról. A közönséget szelektíven hívták meg, és a tesztelést lezárták. Meghagytuk azonban azt a lehetőséget is, hogy weboldalunkon kérjünk hozzáférést a teszteléshez.
Maga a teszt persze nem nélkülözte a vicces pillanatokat, hiszen itt még csak most kezdődnek a kalandjaink.
Először is, kissé helytelenül mértük fel a projekt iránti érdeklődést, és gyorsan számítási csomópontokat kellett hozzáadnunk közvetlenül a teszt során. Gyakori eset a klasztereknél, de itt is volt néhány árnyalat. A TF egy adott verziójának dokumentációja jelzi a kernel azon verzióját, amelyen a vRouterrel való együttműködést tesztelték. Úgy döntöttünk, hogy a csomópontokat újabb kernelekkel indítjuk el. Ennek eredményeként a TF nem kapott útvonalakat a csomópontoktól. Sürgősen vissza kellett tekernem a magokat.
Egy másik érdekesség a személyes fiókjában található „jelszó módosítása” gomb funkciójával kapcsolatos.
Úgy döntöttünk, hogy a JWT-t használjuk a személyes fiókunkhoz való hozzáférés megszervezésére, hogy ne dolgozzunk munkamenetekkel. Mivel a rendszerek sokfélék és széles körben szétszórtak, saját tokenünket kezeljük, amelybe a számlázásból „csomagoljuk” a munkameneteket, illetve az OpenStack tokent. A jelszó megváltoztatásakor a token természetesen „elromlik”, hiszen a felhasználói adatok már nem érvényesek és újra ki kell adni.
Ezt a pontot szem elől tévesztettük, és egyszerűen nem volt elég erőforrás a darab gyors befejezéséhez. Közvetlenül a teszt elindítása előtt ki kellett vágnunk a funkcionalitást.
Jelenleg kijelentkezünk a felhasználóból, ha a jelszó megváltozott.
Ezen árnyalatok ellenére a tesztelés jól sikerült. Néhány hét alatt körülbelül 300 ember állt be. Meg tudtuk nézni a terméket a felhasználók szemével, tesztelni tudtuk működés közben, és jó minőségű visszajelzéseket gyűjtöttünk.
Ahhoz, hogy továbbra is
Sokunk számára ez az első ilyen léptékű projekt. Számos értékes leckét tanultunk a csapatmunkáról, valamint az építészeti és tervezési döntések meghozataláról. Hogyan lehet komplex rendszereket integrálni kevés erőforrással és bevezetni a termelésbe.
Természetesen van min dolgozni mind a kód, mind a rendszerintegráció felületein. A projekt meglehetősen fiatal, de tele vagyunk ambíciókkal, hogy megbízható és kényelmes szolgáltatássá tegyük.
A rendszereket már sikerült meggyőznünk. Bill kötelességtudóan kezeli a számlálást, a számlázást és a felhasználói kéréseket a szekrényében. A volfrámmezők „varázslata” stabil kommunikációt biztosít számunkra. És csak az OpenStack válik néha szeszélyessé, olyasmit kiabálva, hogy „A WSREP még nem készítette fel a csomópontot az alkalmazás használatára”. De ez egy teljesen más történet...
Nemrég indítottuk el a szolgáltatást.
Minden részletet megtudhat nálunk .
CLO Fejlesztési Csapat
Hasznos Linkek
OpenStack
Volfrám szövet
Forrás: will.com