Az IT területén eltöltött idő növekedésével kezdesz észrevenni, hogy a rendszereknek megvan a maguk jellegük. Lehetnek engedékenyek, hallgatagok, zabolátlanok, vagy éppen ellenkezőleg, szigorúak. Vonzaniuk kell, vagy éppen ellenkezőleg, eltaszítaniuk. Így vagy úgy, „meg kell állapodni” velük, lavírozni kell a „vizeken” és építeni kell az interakcióik láncolatát.
Nos, nekünk is megadatott, hogy felépítsük a felhőplatformot, ehhez pedig „meg kellett győznünk” néhány alrendszert, hogy együttműködjenek velünk. Szerencsére van „API nyelvünk”, ügyes kezünk és egy csomó lelkesedésünk.
A cikkben nem lesz technikai hardcore, de beszámolok azokról a problémákról, amelyekkel szembesültünk a felhő felépítése során. Úgy döntöttem, hogy utunkat könnyed technikai fantáziaként írom le, arról, hogyan kerestük a közös nyelvet a rendszerekkel, és hogy mi sült ki belőle.
Üdvözöljük a folytatásban.
Az út kezdete
Néhány idővel ezelőtt csapatunk számára az volt a feladat, hogy elindítson egy felhőplatformot az ügyfeleink számára. Támogatást kaptunk a vezetőségtől, voltak forrásaink, hardverünk és szabadságunk a technológiák kiválasztására a szolgáltatás szoftveres megvalósításához.
Ezen kívül volt néhány követelmény:
- a szolgáltatásnak kényelmes felhasználói fiókra van szüksége;
- a platformnak integrálva kell lennie a meglévő számlázórendszerbe;
- szoftveres és hardveres rész: OpenStack + Tungsten Fabric (Open Contrail), amelyeket mérnökeink már elég jól megtanultak „megfőzni”.
Arról, hogyan jött össze a csapat, hogyan alakították ki a felhasználói fiók felületét, és hogyan születtek a tervezési döntések, egy másik alkalommal mesélünk, ha a Habr közösséget érdekli.
Az eszközök, amelyeket használni akartunk:
- Python + Flask + Swagger + SQLAlchemy — teljesen standard Python csomag;
- Vue.js a frontendhez;
- a komponensek és szolgáltatások közötti interakciót Celery segítségével oldottuk meg az AMQP felett.
A Python választásával kapcsolatos kérdések előtt előre bocsátom, hogy a nyelv megtalálta a maga helyét a cégünknél, és köré kis kultúra alakult ki. Ezért döntöttünk úgy, hogy a szolgáltatást éppen ezen a nyelven kezdjük el építeni. Főleg, hogy az ilyen feladatokban a fejlesztési sebesség sokszor meghatározó.
Így hát kezdjük megismerkedésünket.
Néma Bill — számlázás
Ezzel a srácsal régóta ismerjük egymást. Mindig mellettünk ült, és csendben számolt valamit. Néha felterjesztette nekünk a felhasználói igényeket, kiállította a ügyfélszámlákat, kezelte a szolgáltatásokat. Egy átlagos, szorgalmas fickó. Igaz, voltak nehézségek. Csendes, néha mélabús és gyakran – a saját gondolataiban jár.
A billing az első rendszer, amellyel megpróbáltunk barátkozni. És az első nehézség már azonnal jelentkezett a szolgáltatások feldolgozásakor.
Például, amikor létrehozunk vagy törlünk, a feladat bekerül a billing belső várólistájába. Így van megvalósítva a szolgáltatásokkal való aszinkron munka rendszere. A saját típusú szolgáltatásaink feldolgozásához a feladatainkat a várólistára kellett „raknunk”. Itt találkoztunk a problémával: a dokumentáció hiánya.
A programozási API leírása alapján ezt a feladatot mégis meg lehet oldani, de nem volt időnk a fordított mérnöki munkára, ezért a logikát külsőre vittük, és feladatlistát szerveztünk a RabbitMQ fölé. A szolgáltatás végrehajtását egy ügyfél indítja a felhasználói fiókjából, ezt a „feladatot” a backend-en Celery-be csomagoljuk, és a billing és az OpenStack oldalán hajtják végre. A Celery viszonylag kényelmesen lehetővé teszi a feladatok kezelését, az újraindításokat és az állapot figyelését. A „celery”-ről bővebben lehet olvasni például, .
A billing a projekt leállítását sem gátolta, amikor a pénz elfogyott. A fejlesztőkkel kommunikálva kiderült, hogy a statisztika alapján (ami nekünk éppen ennek a logikának a megvalósításához szükséges) összetett szabályok vannak a leállításra vonatkozóan. De ezek a modellek nem illeszkednek jól a realitásainkhoz. A logikai kezelését a backendre elvittük, szintén Celery feladatokon keresztül megvalósítva.
A fent említett két probléma miatt a kód egy kicsit megnövekedett, és a jövőben foglalkoznunk kell a refaktorálással, hogy a feladatok kezelésének logikáját külön szolgáltatásba helyezzük. Emellett részeket kell tárolnunk a felhasználókról és azok szolgáltatásairól a saját tábláinkban, hogy ezt a logikát támogathassuk.
Még egy probléma – a csend.
A billing API egyes kérdéseire csendesen válaszol „Ok”-kal. Például így volt, amikor az ígért kifizetések bejegyzését végeztük a tesztidőszak alatt (erről később). A kérések helyesen teljesültek, és nem láttunk hibákat.
Meg kellett tanulmányozni a naplókat, miközben a rendszert az UI-n keresztül használtam. Kiderült, hogy a számlázó rendszer a kéréseket a konkrét felhasználóra, például az adminisztrátorra vonatkozó scope megváltoztatásával hajtja végre, átadva azt az su paraméterben.
Összességében, annak ellenére, hogy a dokumentációban vannak hiányosságok és az API-nak apróbb hibái, az egész folyamat elég zökkenőmentesen zajlott. A naplókat akkor is jól lehet olvasni, ha nagy terhelés alatt állnak, ha tudjuk, hogyan vannak megszervezve és mit kell keresni. Az adatbázis struktúrája bonyolult, de logikus, sőt, bizonyos értelemben még vonzó is.
Tehát, összefoglalva, a legnagyobb problémák, amelyek a kapcsolatunk során felmerültek, a konkrét rendszer megvalósításának sajátosságaival kapcsolatosak:
- nem dokumentált „funkciók”, amelyek valamilyen módon érintettek minket;
- zárt forráskód (a számlázás C++ nyelven íródott), ennek következményeként — a probléma 1 megoldásának lehetetlensége a „próbák és hibák” módszerén kívül.
Szerencsére a terméknek van egy elég részletes API-ja, így az alábbi alrendszereket integráltuk a saját ügyfélkapunkba:
- technikai támogatás modul — a személyes fiókból érkező kérések a kliensek számára átlátható módon „prokiszálódnak” a számlázó rendszerbe;
- pénzügyi modul — lehetővé teszi a számlák kiállítását meglévő ügyfelek számára, levonásokat végezni és fizetési dokumentumokat generálni;
- szolgáltatáskezelő modul — ehhez saját kezelőt kellett megvalósítanunk. A rendszer bővíthetősége a javunkra vált, és „megtanítottuk” a Billit egy új szolgáltatási típusra.
Meg kellett dolgozni rajta, de úgy gondolom, hogy a Billivel meg fogjuk találni a közös nyelvet.
Séta a wolfram mezőkön — Tungsten Fabric
A wolfram mezők, amelyeket száz vezeték borít, amelyek ezernyi bit információt áramoltatnak át. Az információ „csomagokba” gyűlik össze, felbontódik, bonyolult útvonalakat alakítva ki, mintha varázslat lenne.
Ez a második rendszer doménje, amellyel barátkoznunk kellett — Tungsten Fabric (TF), régi nevén OpenContrail. A feladata, hogy kezelje a hálózati berendezéseket, programozott absztrakciót nyújtva nekünk, mint felhasználóknak. A TF — SDN, bonyolult logikát tartalmaz a hálózati berendezésekkel való munkához. Magáról a technológiáról van egy jó cikk, például, .
A rendszer integrálva van az OpenStackkel (erről később lesz szó) a Neutron pluginon keresztül.
Az OpenStack szolgáltatások közötti interakció.
Ezt a rendszert az üzemeltetési osztály srácai mutatták be nekünk. Az API-ját használjuk szolgáltatásaink hálózati stackjének kezelésére. Komoly problémáink vagy kényelmetlenségeink eddig nem voltak (az üzemeltetési srácokról nem nyilatkoznék), de voltak vicces összefonódások is a kapcsolatunk során.
Az első úgy nézett ki: a parancsok, amelyek nagy mennyiségű adatot igényeltek a SSH-n keresztül való kapcsolódáskor, egyszerűen „leakasztották” a kapcsolatot, míg a VNC-n minden zökkenőmentesen működött.
Aki nem ismeri a problémát, annak ez elég viccesen néz ki: a ls /root helyesen működik, míg például a top „teljesen lefagy”. Szerencsére már találkoztunk hasonló problémákkal. Az MTU optimalizálásával a compute-nódoktól a routerekig sikerült megoldanunk. Kétségtelen, hogy ez nem TF probléma.
A következő probléma egy kanyar mögött várt. Egy „gyönyörű” pillanatban a routing varázslata egyszerűen eltűnt. A TF leállt a routerek kezelésével.
Az OpenStackkel adminisztrátori szinten dolgoztunk, majd átváltottunk a kívánt felhasználói szintre. Úgy tűnik, hogy az SDN „lefogja” a felhasználó scópját, amelyben tevékenykedünk. A baj az, hogy ugyanezt az adminisztrátori fiókot használjuk a TF és az OpenStack közötti kapcsolatra. Amikor a felhasználóra való váltás történt, a „varázslat” eltűnt. Az a döntés született, hogy külön fiókot hozunk létre a rendszer használatához. Ez lehetővé tette, hogy dolgozzunk, anélkül hogy megszüntettük volna az integrációs funkciót.
Szilikon életformák — OpenStack
A szilikon lény furcsa formájú, a wolfram mezők közelében él. Legjobban egy nagyra nőtt gyermekhez hasonlít, aki egy mozdulattal összezúzhat minket, de nyilvánvaló agressziót nem mutat. Nem kelt félelmet, de mérete riasztó. Akárcsak a körülötte zajló cselekvés bonyolultsága.
Az OpenStack a platformunk szívét képezi.
Az OpenStacknek több alrendszere van, amelyek közül a legaktívebben eddig a Nova, Glance és Cinder használatban. Mindegyiknek megvan a saját API-ja. A Nova a compute-erőforrásokért és példányok létrehozásáért felelős, a Cinder a volumek és azok fényképeinek kezelésével foglalkozik, a Glance pedig egy image szolgáltatás, amely kezeli az operációs rendszerek sablonjait és a hozzájuk tartozó metaadatokat.
Minden szolgáltatás konténerben fut, a message broker pedig a „fehér nyúl” — RabbitMQ.
Ez a rendszer okozta a legnagyobb meglepetéseket számunkra.
Az első probléma nem váratott magára, mikor megpróbáltuk csatlakoztatni a kiegészítő tárolót a szerverhez. A Cinder API határozottan megtagadta ezt a feladatot. Pontosabban, ha magára az OpenStack-re hallgatunk, a kapcsolat létrejön, de a virtuális szerveren a lemez eszköz hiányzik.
Úgy döntöttünk, hogy "térjünk ki" és ugyanazt a műveletet kérjük a Nova API-tól. Az eredmény — az eszköz megfelelően csatlakozik és elérhető a szerveren belül. Úgy tűnik, hogy a probléma akkor merül fel, amikor a block-storage nem válaszol a Cinder-nek.
Újabb nehézség várt ránk a lemezek kezelésénél. A rendszeres tárolót nem tudtuk leválasztani a szerverről.
Ismét, magának az OpenStack-nek "garantálja", hogy a kapcsolatot megszüntette, és most már helyesen dolgozhatunk a tárolóval külön. De az API kategorikusan megtagadta a műveletek végrehajtását a lemezen.
Itt úgy döntöttünk, hogy nem harcolunk különösebben, hanem megváltoztatjuk a szolgáltatás működésének logikáját. Ha van példány, akkor kell lennie rendszeres tárolónak is. Ezért a felhasználó egyelőre nem törölheti vagy kapcsolhatja ki a rendszer "lemezt", amíg a "szervert" el nem távolítja.
Az OpenStack egy elég összetett rendszerkomplexum saját interakciós logikával és csavaros API-val. Segít nekünk a meglehetősen részletes dokumentáció, és természetesen a próbák és tévedések módszere (hova máshová?).
Tesztelési indítás
A tesztelést tavaly decemberben végeztük. A fő célunk az volt, hogy technikai szempontból és UX szempontból ellenőrizni tudjuk projektünket éles környezetben. A közönséget válogatottan hívtuk meg, és a tesztelés zárt volt. Ugyanakkor lehetőséget hagytunk a tesztelés iránti hozzáférés kérésére a weboldalunkon.
Magát a tesztet természetesen nem kerülték el a különös pillanatok, hiszen itt kezdődnek a kalandjaink.
Először is, kissé helytelenül ítéltük meg a projekt iránti érdeklődést, és gyorsan hozzá kellett adnunk compute-nodokat a teszt során. Ez általában egy szokásos eset a klasztereknél, de itt is voltak finomságok. A dokumentáció a konkrét TF verzióra megjelöli a pontos kernel verziót, amelyen a vRouter használatát tesztelték. Mi frissebb kernellel indítottuk a nodokat. Az eredmény — a TF nem kapott útvonalakat a nodoktól. Sürgősen vissza kellett állítanunk a kernelt.
Egy másik különös eset a "jelszó megváltoztatása" funkcióval kapcsolatos a felhasználói fiókban.
Úgy döntöttünk, hogy JWT-t használunk a felhasználói fiókhoz való hozzáférés megszervezésére, hogy ne kelljen munkával foglalkozni az ülésekkel. Mivel a rendszerek különbözőek és széles spektrumot fednek le, saját tokenünket kezeljük, amelybe „csomagoljuk” a billing rendszer és az OpenStack tokenjeit. A jelszó megváltoztatásakor a token természetesen „lejár”, mivel a felhasználó adatai már érvénytelenek, így azt újra kell kibocsátani.
Ezt a pillanatot elkerültük, és nem volt elegendő erőforrásunk ahhoz, hogy gyorsan hozzáadjunk ezt a részt. Az utolsó pillanatban ki kellett vágnunk egy funkciót a tesztelés megkezdése előtt.
Jelenleg logout-ot hajtunk végre a felhasználó számára, ha a jelszót megváltoztatták.
Ezeket a nüanszokat figyelembe véve a tesztelés jól zajlott. Pár hét alatt körülbelül 300 ember kereste fel minket. Meg tudtuk nézni a terméket a felhasználók szemszögéből, teszteltük a gyakorlatban, és összegyűjtöttük a minőségi visszajelzéseket.
Folytatás következik
Sokunk számára ez az első projekt ilyen méretben. Számos értékes leckét tanultunk meg arról, hogyan dolgozzunk csapatban, hogyan hozzunk meg építészeti és tervezési döntéseket. Hogyan integráljunk bonyolult rendszereket korlátozott erőforrásokkal és hogyan vezessük be őket a termelésbe.
Természetesen van még mit dolgozni a kód és a rendszerek integrációjának határvonalain. A projekt eléggé fiatal, de tele vagyunk ambíciókkal, hogy megbízható és kényelmes szolgáltatást építsünk belőle.
Már sikerült megnyugtatnunk a rendszereket. Bill engedelmesen számolja, kiállítja a számlákat és kéri a felhasználók kérdéseit a saját kis szobájában. A wolfrámmezők „varázsa” biztosít minket stabil kapcsolattal. És csak az OpenStack időnként problémázik, valami olyasmit kiáltva, mint „’WSREP még nem készítette fel a csomópontot az alkalmazás használatra”. De ez már egy másik történet...
Nemrégiben elindítottuk a szolgáltatást.
Minden részletet megtudhat a .
CLO fejlesztői csapata
Hasznos linkek
OpenStack
Tungsten Fabric
Forrás: habr.com
