Kompania URUS provoi Kubernetes në forma të ndryshme: vendosje të pavarur në metal të zhveshur, në Google Cloud, dhe më pas transferoi platformën e saj në renë kompjuterike Mail.ru Cloud Solutions (MCS). Igor Shishkin tregon se si ata zgjodhën një ofrues të ri cloud dhe si arritën të migrojnë në të në një rekord dy orë (), administrator i lartë i sistemit në URUS.
Çfarë bën URUS?
Ka shumë mënyra për të përmirësuar cilësinë e mjedisit urban dhe njëra prej tyre është ta bëjmë atë miqësor me mjedisin. Kjo është pikërisht ajo për të cilën po punon kompania URUS - Smart Digital Services. Këtu ata zbatojnë zgjidhje që ndihmojnë ndërmarrjet të monitorojnë tregues të rëndësishëm mjedisor dhe të zvogëlojnë ndikimin e tyre negativ në mjedis. Sensorët mbledhin të dhëna për përbërjen e ajrit, nivelin e zhurmës dhe parametrat e tjerë, dhe më pas i dërgojnë ato në platformën e unifikuar URUS-Ekomon për analiza dhe dhënie rekomandimesh.
Si funksionon URUS nga brenda
Një klient tipik i URUS është një kompani e vendosur në ose pranë një zone banimi. Kjo mund të jetë një fabrikë, port, depo hekurudhore ose ndonjë objekt tjetër. Nëse klienti ynë ka marrë tashmë një paralajmërim, është gjobitur për ndotjen e mjedisit, ose dëshiron të bëjë më pak zhurmë, të zvogëlojë sasinë e shkarkimeve të dëmshme, ai vjen tek ne dhe ne i ofrojmë tashmë një zgjidhje të gatshme për monitorimin e mjedisit.
Grafiku i monitorimit të përqendrimit të H2S tregon emetimet e rregullta gjatë natës nga një impiant aty pranë
Pajisjet që përdorim në URUS përmbajnë disa sensorë që mbledhin informacion në lidhje me përmbajtjen e gazeve të caktuara, nivelet e zhurmës dhe të dhëna të tjera për të vlerësuar situatën mjedisore. Numri i saktë i sensorëve përcaktohet gjithmonë nga detyra specifike.
Në varësi të specifikave të matjeve, pajisjet me sensorë mund të vendosen në muret e ndërtesave, shtyllave dhe vendeve të tjera arbitrare. Çdo pajisje e tillë mbledh informacion, e grumbullon atë dhe e dërgon në portën e marrjes së të dhënave. Aty i ruajmë të dhënat për ruajtje afatgjatë dhe i përpunojmë paraprakisht për analiza të mëvonshme. Shembulli më i thjeshtë i asaj që marrim si rezultat i analizës është indeksi i cilësisë së ajrit, i njohur edhe si AQI.
Paralelisht, në platformën tonë funksionojnë edhe shumë shërbime të tjera, por ato janë kryesisht të karakterit shërbyes. Për shembull, shërbimi i njoftimeve dërgon njoftime te klientët nëse ndonjë nga parametrat e monitoruar (për shembull, përmbajtja e CO2) tejkalon vlerën e lejuar.
Si i ruajmë të dhënat. Historia e Kubernetes në metal të zhveshur
Projekti i monitorimit mjedisor URUS ka disa depo të dhënash. Në një ne mbajmë të dhëna "të papërpunuara" - ato që morëm drejtpërdrejt nga vetë pajisjet. Ky ruajtje është një kasetë "magnetike", si në kasetat e vjetra, me një histori të të gjithë treguesve. Lloji i dytë i ruajtjes përdoret për të dhëna të parapërpunuara - të dhëna nga pajisjet, të pasuruara me meta të dhëna për lidhjet ndërmjet sensorëve dhe leximet e vetë pajisjeve, lidhjet me organizatat, vendndodhjet, etj. Ky informacion ju lejon të vlerësoni në mënyrë dinamike se si ka një tregues të caktuar. ndryshuar gjatë një periudhe të caktuar kohore. Ne përdorim ruajtjen e të dhënave "të papërpunuara", ndër të tjera, si një kopje rezervë dhe për të rivendosur të dhënat e parapërpunuara, nëse lind një nevojë e tillë.
Kur po kërkonim të zgjidhnim problemin tonë të ruajtjes disa vite më parë, kishim dy zgjedhje platformash: Kubernetes dhe OpenStack. Por duke qenë se kjo e fundit duket mjaft monstruoze (mjafton të shikoni arkitekturën e saj për t'u bindur për këtë), ne u vendosëm në Kubernetes. Një argument tjetër në favor të tij ishte kontrolli relativisht i thjeshtë i softuerit, aftësia për të prerë në mënyrë më fleksibël edhe nyjet e harduerit sipas burimeve.
Paralelisht me zotërimin e vetë Kubernetes, ne studiuam gjithashtu mënyrat për të ruajtur të dhënat, ndërkohë që e mbajtëm të gjithë ruajtjen tonë në Kubernetes në harduerin tonë, morëm ekspertizë të shkëlqyer. Gjithçka që kishim jetuar atëherë në Kubernetes: ruajtja e plotë, sistemi i monitorimit, CI/CD. Kubernetes është bërë një platformë gjithëpërfshirëse për ne.
Por ne donim të punonim me Kubernetes si një shërbim, dhe të mos angazhoheshim në mbështetjen dhe zhvillimin e tij. Plus, nuk na pëlqente se sa na kushtoi për ta mirëmbajtur atë në metal të zhveshur, dhe kishim nevojë për zhvillim vazhdimisht! Për shembull, një nga detyrat e para ishte integrimi i kontrollorëve të Kubernetes Ingress në infrastrukturën e rrjetit të organizatës sonë. Kjo është një detyrë e rëndë, veçanërisht duke pasur parasysh se në atë kohë asgjë nuk ishte gati për menaxhimin programatik të burimeve, siç janë regjistrimet DNS ose ndarja e adresave IP. Më vonë filluam të eksperimentonim me ruajtjen e të dhënave të jashtme. Asnjëherë nuk arritëm të zbatonim kontrolluesin PVC, por edhe atëherë u bë e qartë se kjo ishte një fushë e madhe pune që kërkonte specialistë të përkushtuar.
Kalimi në Google Cloud Platform është një zgjidhje e përkohshme
Ne e kuptuam se kjo nuk mund të vazhdonte dhe i zhvendosëm të dhënat tona nga metali i zhveshur në platformën e resë kompjuterike të Google. Në fakt, në atë kohë nuk kishte shumë opsione interesante për një kompani ruse: përveç Google Cloud Platform, vetëm Amazon ofroi një shërbim të ngjashëm, por ne ende u vendosëm për zgjidhjen nga Google. Atëherë na dukej më fitimprurëse ekonomikisht, më afër Upstream, për të mos përmendur faktin që vetë Google është një lloj PoC Kubernetes në Prodhim.
Problemi i parë i madh u shfaq në horizont ndërsa baza jonë e klientëve u rrit. Kur kishim nevojë për të ruajtur të dhënat personale, ne u përballëm me një zgjedhje: ose të punojmë me Google dhe të shkelim ligjet ruse, ose të kërkojmë një alternativë në Federatën Ruse. Zgjedhja, në përgjithësi, ishte e parashikueshme. 🙂
Si e pamë shërbimin ideal të cloud
Nga fillimi i kërkimit, ne e dinim tashmë se çfarë donim të merrnim nga ofruesi i ardhshëm i cloud. Çfarë shërbimi po kërkonim:
- I shpejtë dhe fleksibël. E tillë që ne mund të shtojmë shpejt një nyje të re ose të vendosim diçka në çdo kohë.
- Të lira. Ne ishim shumë të shqetësuar për çështjen financiare, pasi ishim të kufizuar në burime. Ne e dinim tashmë që donim të punonim me Kubernetes, dhe tani detyra ishte të minimizonim koston e tij në mënyrë që të rrisnim ose të paktën të ruanim efikasitetin e përdorimit të kësaj zgjidhje.
- I automatizuar. Planifikuam të punonim me shërbimin përmes API-së, pa menaxherë dhe telefonata ose situata ku duhet të ngremë manualisht disa dhjetëra nyje në modalitetin e urgjencës. Meqenëse shumica e proceseve tona janë të automatizuara, ne prisnim të njëjtën gjë nga shërbimi cloud.
- Me serverë në Federatën Ruse. Sigurisht, ne kemi planifikuar të respektojmë legjislacionin rus dhe të njëjtin 152-FZ.
Në atë kohë, kishte pak ofrues të Kubernetes aaS në Rusi, dhe kur zgjidhnim një ofrues, ishte e rëndësishme që ne të mos kompromentonim prioritetet tona. Ekipi i Mail.ru Cloud Solutions, me të cilin filluam të punojmë dhe vazhdojmë të bashkëpunojmë, na ofroi një shërbim plotësisht të automatizuar, me mbështetje API dhe një panel kontrolli të përshtatshëm që përfshin Horizon - me të ne mund të ngrinim shpejt një numër arbitrar nyjesh.
Si arritëm të migronim në MCS në dy orë
Në lëvizje të tilla, shumë kompani përballen me vështirësi dhe pengesa, por në rastin tonë nuk kishte asnjë. Ne ishim me fat: duke qenë se po punonim tashmë në Kubernetes përpara se të fillonte migrimi, thjesht korrigjuam tre skedarë dhe nisëm shërbimet tona në platformën e re cloud, MCS. Më lejoni t'ju kujtoj se deri në atë kohë ne më në fund e kishim lënë metalin e zhveshur dhe jetonim në Platformën Cloud Google. Prandaj, vetë lëvizja zgjati jo më shumë se dy orë, plus pak më shumë kohë (rreth një orë) u shpenzua për kopjimin e të dhënave nga pajisjet tona. Në atë kohë ne po përdornim tashmë Spinnaker (një shërbim CD me shumë re për të ofruar shpërndarje të vazhdueshme). Ne gjithashtu e shtuam shpejt atë në grupin e ri dhe vazhduam të punojmë si zakonisht.
Falë automatizimit të proceseve të zhvillimit dhe CI/CD, Kubernetes në URUS trajtohet nga një specialist (dhe ky jam unë). Në një fazë, një administrator tjetër i sistemit punoi me mua, por më pas doli që ne kishim automatizuar tashmë të gjithë rutinën kryesore dhe kishte gjithnjë e më shumë detyra nga ana e produktit tonë kryesor dhe kishte kuptim të drejtonim burimet për këtë.
Ne morëm atë që prisnim nga ofruesi i cloud, pasi filluam bashkëpunimin pa iluzione. Nëse ka pasur ndonjë incident, ato kanë qenë kryesisht teknike dhe ato që mund të shpjegohen lehtësisht me freskinë relative të shërbimit. Gjëja kryesore është që ekipi MCS të eliminojë shpejt mangësitë dhe t'i përgjigjet shpejt pyetjeve në të dërguarit.
Nëse krahasoj përvojën time me Google Cloud Platform, në rastin e tyre as që e dija se ku ishte butoni i reagimit, pasi thjesht nuk kishte nevojë për të. Dhe nëse ndodhi ndonjë problem, vetë Google dërgoi njoftime në mënyrë të njëanshme. Por në rastin e MCS, unë mendoj se avantazhi i madh është se ata janë sa më afër klientëve rusë - si gjeografikisht ashtu edhe mendërisht.
Si e shohim punën me retë në të ardhmen
Tani puna jonë është e lidhur ngushtë me Kubernetes dhe na përshtatet plotësisht nga pikëpamja e detyrave të infrastrukturës. Prandaj, ne nuk planifikojmë të migrojmë prej saj askund, megjithëse po prezantojmë vazhdimisht praktika dhe shërbime të reja për të thjeshtuar detyrat rutinë dhe automatizuar të reja, për të rritur stabilitetin dhe besueshmërinë e shërbimeve... Tani po lançojmë shërbimin Chaos Monkey (konkretisht , ne përdorim chaoskube, por kjo nuk e ndryshon konceptin: ), i cili fillimisht u krijua nga Netflix. Chaos Monkey bën një gjë të thjeshtë: fshin një pod të rastësishme Kubernetes në një kohë të rastësishme. Kjo është e nevojshme që shërbimi ynë të jetojë normalisht me numrin e rasteve n–1, kështu që ne stërvitemi që të jemi të përgatitur për çdo problem.
Tani e shoh përdorimin e zgjidhjeve të palëve të treta - të njëjtat platforma cloud - si të vetmen gjë të duhur për kompanitë e reja. Zakonisht, në fillim të udhëtimit të tyre, ata janë të kufizuar në burime, si njerëzore ashtu edhe financiare, dhe ndërtimi dhe mirëmbajtja e qendrës së tyre cloud ose të të dhënave është shumë e shtrenjtë dhe kërkon punë intensive. Ofruesit e cloud ju lejojnë të minimizoni këto kosto; ju mund të merrni shpejt prej tyre burimet e nevojshme për funksionimin e shërbimeve këtu dhe tani, dhe të paguani për këto burime pas faktit. Sa i përket kompanisë URUS, ne do t'i qëndrojmë besnikë Kubernetes në cloud për momentin. Por kush e di, mund të na duhet të zgjerohemi gjeografikisht, ose të zbatojmë zgjidhje të bazuara në disa pajisje specifike. Ose mbase sasia e burimeve të konsumuara do të justifikojë Kubernetes-in e vet në metal të zhveshur, si në ditët e mira të vjetra. 🙂
Çfarë mësuam nga puna me shërbimet cloud
Ne filluam të përdorim Kubernetes në metal të zhveshur, dhe edhe atje ishte i mirë në mënyrën e vet. Por pikat e forta të tij u zbuluan pikërisht si një komponent aaS në re. Nëse vendosni një objektiv dhe automatizoni gjithçka sa më shumë që të jetë e mundur, do të jeni në gjendje të shmangni bllokimin e shitësve dhe lëvizja midis ofruesve të cloud do të zgjasë disa orë dhe qelizat nervore do të mbeten me ne. Ne mund t'i këshillojmë kompanitë e tjera: nëse dëshironi të lançoni shërbimin tuaj (cloud), duke pasur burime të kufizuara dhe shpejtësi maksimale për zhvillim, filloni që tani duke marrë me qira burimet e cloud dhe ndërtoni qendrën tuaj të të dhënave pasi Forbes të shkruajë për ju.
Burimi: www.habr.com