Ettevõte «URUS» proovib Kubernetes'i erinevates vormides: iseseisev juurutamine bare metal, Google Cloudis, seejärel viidi oma platvorm Mail.ru Cloud Solutions (MCS) pilve. Kuidas valiti uus pilveteenuse pakkuja ja kuidas õnnestus migratsioon rekordilise kahe tunni jooksul, räägib Igor Shishkin (), vanem süsteemiadministraator «URUS».
Millega tegeleb «URUS»
On palju viise, kuidas parandada linna keskkonna kvaliteeti, ja üks neist on muuta see ökoloogiliselt ohutuks. Just selle nimel töötab ettevõte «URUS – Nutikad digiteenused». Siin rakendatakse lahendusi, mis aitavad ettevõtetel jälgida olulisi keskkonnaalaseid näitajaid ja vähendada negatiivset mõju keskkonnale. Andurid koguvad andmeid õhukoostise, müra taseme ja teiste parameetrite kohta, seejärel saadavad need analüüsimiseks ja soovituste koostamiseks ühte platvormi «URUS – Ekomon».
Kuidas töötab «URUS» seestpoolt
Tüüpiline «URUS» klient on ettevõte, mis asub elamupiirkonnas või selle lähedal. See võib olla tehas, sadam, raudteede depoo või mõni muu objekt. Kui meie klient on juba saanud hoiatuse, saanud trahvi keskkonna saastamise eest või soovib ise tekitada vähem müra, vähendada kahjulikke heitkoguseid, pöördub ta meie poole ja me pakume talle valmis lahendust keskkonna jälgimiseks.
H2S kontsentratsiooni järelevalve graafik näitab regulaarseid öiseid heitmeid naaberettevõttest
Seadmed, mida me «URUS» kasutame, sisaldavad mitmeid andureid, mis koguvad teavet teatud gaaside, müra taseme ja teiste andmete kohta, et hinnata ökoloogilist olukorda. Andurite täpne arv määratakse alati konkreetse ülesande järgi.
Sõltuvalt mõõtmise spetsiifikast võivad andurit sisaldavad seadmed asuda hoonete seintel, postidel ja muudes juhuslikes kohtades. Iga selline seade kogub teavet, koondab selle ja saadab andmete vastuvõtugate. Seal salvestame andmed pikaajaliseks säilitamiseks ja töötleme need edasiseks analüüsiks. Lihtsaim näide, mida me analüüsi tulemusena saame, on õhukvaliteedi indeks, tuntud ka kui AQI.
Samas töötavad meie platvormil palju teisi teenuseid, kuid enamik neist on tugiteenused. Näiteks saadab teavitusteenus klientidele teateid, kui mõni jälgitav parameeter (näiteks süsinikdioksiidi sisaldus) ületab lubatud väärtuse.
Kuidas me andmeid salvestame. Lugu Kubernetesest bare metal'il
Ekomonitoringu projektis «URUS» on mitu andmesalvestuskohta. Ühes hoidame «tooreid» andmeid – seda, mida oleme otseselt seadmetelt saanud. See salvestuskoht on nagu «magneetlint», justkui vanadel kassettidel, kõigi näitajate ajalooga. Teist tüüpi salvestuskohta kasutatakse eeltöödeldud andmete jaoks – seadmetelt saadud andmed, milles on rikastatud metaandmed sensorite seoste, seadmete enda näitajate, organisatsioonide ja asukohtade kohta jne. See teave võimaldab dünaamiliselt hinnata, kuidas on teatud näitaja teatud aja jooksul muutunud. «Toorete» andmete salvestuskohta kasutame ka varukoopiana ja eeltöödeldud andmete taastamiseks, kui selline vajadus peaks tekkima.
Kui me paar aastat tagasi otsisime, kuidas lahendada salvestamise probleem, oli meil kaks võimalust platvormi valimiseks: Kubernetes ja OpenStack. Kuid kuna viimane näeb välja üsna kohmakas (vaadake lihtsalt selle arhitektuuri, et selles veenduda), jäime valima Kubernetes’e. Veel üks argument selle kasuks oli suhteliselt lihtne programmeerimise juhtimine, võimalus ressursse isegi füüsilistes nodides paindlikumalt jaotada.
Kuna õppisime Kubernetes’e enda kasutamist, uurisime ka andmete salvestamise viise. Kui kõik meie salvestuskohtad olid Kubernetes’es meie riistvara peal, saime suurepärase ekspertiisi. Kõik, mis meil siis oli, eksisteeris just Kubernetes’es: stateful-salvestus, jälgimissüsteem, CI/CD. Kubernetes oli meie jaoks all-in-one platvorm.
Kuid me soovisime töötada Kubernetes'ega teenusena, mitte tegeleda selle hooldamise ja arendamisega. Pluss, me ei olnud rahul, kui palju maksis tema hoidmine bare metal'il, samal ajal kui arendustöö oli pidevalt vajalik! Näiteks üks esimesi ülesandeid oli Kubernetes'i Ingress-kontrollerite integreerimine meie organisatsiooni võrgu infrastruktuuri. See on mahukas ülesanne, eriti kui arvestada, et sel hetkel ei olnud mitte midagi valmis ressursside, näiteks DNS-kirjete või jagamise, tarkvara juhtimiseks. IP-aadresse. Hiljem hakkasime katsetama välise andmehoidla kasutamist. PVC-kontrolleri rakendamiseni me ei jõudnud, kuid juba siis oli selge, et see on suur töömaht, mille jaoks on vaja eraldi spetsialiste.
Üleminek Google Cloud Platformile — ajutine lahendus.
Me mõistsime, et nii ei saa edasi minna, ja viisin meie andmed bare metal'ilt Google Cloud Platformile. Tegelikult ei olnud toona Venemaa ettevõtte jaoks palju huvitavaid variante: Google Cloud Platformist pakkus sarnast teenust vaid Amazon, kuid otsustasime siiski Google'i lahenduse kasuks. See tundus meile majanduslikult tulusam, lähemal Upstream'ile, rääkimata sellest, et Google ise on iseenesest nagu PoC Kubernetes tootmises.
Esimene tõsine probleem ilmus silmapiirile koos meie klientide arvu kasvamisega. Kui meil tekkis vajadus isikuandmete hoidmise järele, seisisime valiku ees: kas töötame Google'iga ja rikume Vene seadusi või otsime alternatiivi Venemaalt. Valik oli üldiselt ette ennustatav. 🙂
Milline me nägime ideaalset pilveteenust
Otsingute alguseks teadisime juba, mida tahame tulevaselt pilveteenuse pakkujalt. Millist teenust me otsisime:
- Kiire ja paindlik. Nii et me saaksime igal hetkel kiiresti lisada uue sõlme või midagi üles seada.
- Odav. Meid muretses väga rahaküsimus, kuna olime ressurssides piiratud. Olime juba teadnud, et soovime töötada Kubernetes'ega, ja nüüd oli eesmärk minimeerida selle kulusid, et suurendada või vähemalt säilitada selle lahenduse tõhusus.
- Automatiseeritud. Me planeerisime töötada teenusega API kaudu, ilma haldurite ja telefonikõnede või olukordadeta, kus tuleb käsitsi aktiveerida mitu tosinat sõlme kriitilises olukorras. Kuna enamus protsessidest on meil automatiseeritud, ootasime sama ka pilveteenuses.
- Serveritega Venemaal. Loomulikult soovisime järgida Venemaa seadusandlust ja seda sama 152-FZ.
Sel ajal oli Venemaal vähe Kubernetes'i teenuseid aaS mudeliga, kuid pakkujat valides oli meie jaoks oluline mitte jätta kõrvale meie prioriteete. Mail.ru Cloud Solutionsi meeskond, kellega alustasime koostööd ja kellega me siiani koos töötame, pakkus meile täielikult automatiseeritud teenust koos API toe ja mugava juhtpaneeliga, kus on Horizon — selle abil suutisime kiiresti aktiveerida sooja sõlmede arvu.
Kuidas me suutsime kahe tunni jooksul MCS-i migreerida
Sellistes üleminekutes seisavad paljud ettevõtted silmitsi raskuste ja ebaõnnestumistega, kuid meie puhul ei olnud neid. Meil vedas: kuna enne migreerimist töötasime juba Kuberneteses, muudatasime lihtsalt kolme faili ja käivitasime oma teenused uuel pilveteenusel, MCS-is. Pean meeles, et sel ajal olime me täielikult bare metal'ilt lahkunud ja elasime Google Cloud Platformis. Seega ei võtnud üleminek kaua aega, maksimaalselt kaks tundi, pluss veel natuke aega (umbes tund) läks meie seadmetelt andmete kopeerimiseks. Sel ajal kasutasime juba Spinnakerit (mitme pilve CD-teenus pideva kohaletoimetamise tagamiseks). Selle lisasime samuti kiiresti uude klastrisse ja jätkasime tavapärast tööd.
Aitame meie arendamis- ja CI/CD protsesside automatiseerimisest Kuberneteses «УРУС»-es hoolitseb üks spetsialist (ja see olen mina). Teatud hetkel töötas minuga koos veel üks süsteemihaldur, kuid hiljem selgus, et oleme kogu põhitegevuse juba automatiseerinud ja meie põhitoote ülesandeid on üha rohkem, seega on mõtet suunata ressursse sellele.
Saime pilveteenuse pakkujalt seda, mida ootasime, kuna alustasime koostööd ilma illusioonideta. Kui mõni intsident leidis aset, siis peamiselt tehnilised ja sellised, mida on lihtne seletada teenuse suhtelise uudsuse tõttu. Peamine on, et MCS meeskond lahendab kiiresti puudusi ja reageerib kiirelt küsimustele messengereis.
Kui võrrelda töökogemust Google Cloud Platformiga, siis nende puhul ei teadnud ma isegi, kus asub tagasiside nupp, kuna seda polnud lihtsalt vaja. Kui aga mingi probleem tekkis, saatis Google ise ühepoolsed teavitused. MCS-i puhul pean ma suureks eeliseks seda, et nad asuvad venna lähedal — nii geograafiliselt kui ka vaimselt.
Kuidas näeme tulevikus pilveteenuste kasutamist
Praegu on meie töö tihedalt seotud Kubernetesega ja see rahuldab meid täiesti infrastrukturiliste probleemide osas. Seetõttu ei planeeri me sealt kuhugi migreerimist, kuigi pidevalt rakendame uusi praktikaid ja teenuseid rutiinsete ülesannete lihtsustamiseks ning uute automatiseerimiseks, teenuste stabiilsuse ja usaldusväärsuse tõstmiseks… Hetkel käivitame teenuse Chaos Monkey (konkreetsemalt kasutame chaoskube'i, aga kontseptsioon ei muutu :), mis loodi algselt Netflixis. Chaos Monkey teeb ühe lihtsa asja: see eemaldab suvalisel ajal suvalise pod'i Kuberneteses. See on vajalik, et meie teenus suudaks hästi toimida instantside arvuga n–1, nii harjutame end valmis olema igasuguste riketega toimetulemiseks.
Praegu näen kolmandate osapoolte lahendusi — sama pilveteenuseid — noorte ettevõtete jaoks ainus õige valik. Tavaliselt on nende ressursid, nii inim- kui ka rahalised, alguses piiratud ning oma pilve või andmekeskuse loomine ja hoidmine on liiga kulukas ja ajakulukas. Pilveteenuse pakkujad võimaldavad neid kulusid minimeerida, neid on võimalik kiiresti hankida teenuste jaoks, mida on tarvis siin ja praegu, ja nende eest maksab alles siis, kui neid kasutatakse. Mis puutub ettevõttesse "URUS", siis loodame praegu jääda truuks Kubernetes'ele pilves. Aga kes teab, võib-olla peame geograafiliselt laienema või rakendama lahendusi mingil spetsiifilisel varustusel. Või võib-olla õigustab tarbitud ressursside arv oma Kubernetes'ega bare-metal, nagu vanadel headel aegadel. 🙂
Mida oleme õppinud pilveteenuste kasutamise kogemusest
Me oleme hakanud kasutama Kubernetes'i bare metal'is ja isegi seal oli see omal moel hea. Kuid selle tugevused said tõeliselt avalikuks just aaS-komponendina pilves. Kui seada eesmärk ja kõik maksimaalselt automatiseerida, suudame vältida vendor lock-in'i ja liikumine pilveteenuse pakkujate vahel võtab vaid paar tundi, samas kui meie närvirakud jäävad alles. Teistele ettevõtetele soovitame: kui soovite käivitada oma (pilve) teenust piiratud ressurssidega ja võimalikult kiire arendusega — alustage kohe pilveteenuste rentimisega ja oma andmekeskust ehitage alles pärast seda, kui Forbes teist kirjutab.
Allikas: habr.com
