Az URUS cég különböző formákban próbálta ki a Kuberneteset: független telepítést csupasz fémen, Google Cloudban, majd platformját áthelyezte a Mail.ru Cloud Solutions (MCS) felhőbe. Igor Shishkin elmondja, hogyan választottak új felhőszolgáltatót, és hogyan sikerült rekord két óra alatt áttérniük rá (), vezető rendszergazda az URUS-nál.
Mit csinál az URUS?
A városi környezet minőségének javítására számos módszer létezik, ezek egyike a környezetbaráttá tétel. Az URUS – Smart Digital Services vállalat pontosan ezen dolgozik. Itt olyan megoldásokat valósítanak meg, amelyek segítik a vállalkozásokat a fontos környezeti mutatók nyomon követésében és a környezetre gyakorolt negatív hatások csökkentésében. Az érzékelők adatokat gyűjtenek a levegő összetételéről, zajszintjéről és egyéb paramétereiről, majd elküldik az egységes URUS-Ekomon platformra elemzés és ajánlások megfogalmazása céljából.
Hogyan működik az URUS belülről
Az URUS tipikus ügyfele egy lakóövezetben vagy annak közelében található cég. Ez lehet gyár, kikötő, vasúti raktár vagy bármilyen más létesítmény. Ha ügyfelünk már kapott figyelmeztetést, bírságot szabtak ki környezetszennyezés miatt, vagy kevesebb zajt, károsanyag-kibocsátást szeretne, akkor hozzánk fordul, és máris kész megoldást kínálunk a környezeti monitoringra.
A H2S-koncentráció-ellenőrzési grafikon egy közeli üzem rendszeres éjszakai kibocsátását mutatja
Az URUS-nál használt eszközök számos érzékelőt tartalmaznak, amelyek információkat gyűjtenek bizonyos gázok tartalmáról, zajszintekről és egyéb adatokról a környezeti helyzet felméréséhez. Az érzékelők pontos számát mindig az adott feladat határozza meg.
A mérések sajátosságaitól függően az érzékelőkkel ellátott eszközök épületek falán, oszlopokon és más tetszőleges helyeken helyezkedhetnek el. Minden ilyen eszköz információkat gyűjt, összesíti és elküldi az adatfogadó átjárónak. Ott elmentjük az adatokat hosszú távú tárolásra, és előfeldolgozzuk a későbbi elemzéshez. A legegyszerűbb példa arra, amit az elemzés eredményeként kapunk, a levegőminőségi index, más néven AQI.
Ezzel párhuzamosan számos más szolgáltatás is működik platformunkon, de ezek elsősorban szolgáltatás jellegűek. Például az értesítési szolgáltatás értesítést küld az ügyfeleknek, ha valamelyik megfigyelt paraméter (például CO2-tartalom) meghaladja a megengedett értéket.
Hogyan tároljuk az adatokat. Kubernetes története csupasz fémen
Az URUS környezeti monitoring projekt több adattárral rendelkezik. Az egyikben „nyers” adatokat tárolunk – azokat, amelyeket közvetlenül maguktól az eszközöktől kaptunk. Ez a tároló egy „mágneses” szalag, mint a régi kazettás szalagokon, minden jelző előzményével. A második típusú tárolót előfeldolgozott adatokhoz használják – az eszközökről származó adatokhoz, metaadatokkal gazdagítva az érzékelők közötti kapcsolatokról és maguknak az eszközöknek a leolvasásáról, a szervezetekkel való kapcsolatról, a helyekről stb. Ez az információ lehetővé teszi, hogy dinamikusan felmérje, hogyan működik egy adott mutató megváltozott egy bizonyos idő alatt. A „nyers” adattárolót egyebek mellett biztonsági mentésre és az előfeldolgozott adatok visszaállítására használjuk, ha erre szükség van.
Amikor néhány évvel ezelőtt a tárolási problémánkat kerestük, két platform közül választhattunk: a Kubernetes és az OpenStack. De mivel ez utóbbi elég szörnyen néz ki (erről csak nézze meg az architektúráját), ezért a Kubernetesre telepedtünk. Egy másik érv mellette szólt a viszonylag egyszerű szoftveres vezérlés, az a lehetőség, hogy még a hardveres csomópontokat is rugalmasabban le lehet vágni az erőforrásoknak megfelelően.
A Kubernetes elsajátításával párhuzamosan az adatok tárolásának módjait is tanulmányoztuk, miközben minden tárhelyünket Kubernetesben tartottuk a saját hardverünkön, kiváló szaktudást kaptunk. Minden, ami akkor a Kubernetesen élt: állapotteljes tárhely, felügyeleti rendszer, CI/CD. A Kubernetes egy mindent az egyben platformmá vált számunkra.
De mi a Kubernetes szolgáltatással akartunk dolgozni, nem pedig annak támogatásában és fejlesztésében. Ráadásul nem tetszett, hogy mennyibe került a karbantartása csupasz fémen, és folyamatosan fejlesztésre volt szükségünk! Például az egyik első feladat a Kubernetes Ingress vezérlők integrálása volt szervezetünk hálózati infrastruktúrájába. Ez nehézkes feladat, különösen, ha figyelembe vesszük, hogy akkoriban semmi sem állt készen a programozott erőforrás-kezelésre, mint például a DNS-rekordok vagy az IP-címek kiosztása. Később elkezdtünk kísérletezni a külső adattárolással. Soha nem jutottunk el a PVC vezérlő megvalósításáig, de már akkor világossá vált, hogy ez egy nagy munkaterület, amelyhez elhivatott szakemberekre van szükség.
A Google Cloud Platformra való váltás ideiglenes megoldás
Rájöttünk, hogy ez nem mehet tovább, és áthelyeztük adatainkat a puszta fémről a Google Cloud Platformra. Valójában akkoriban nem sok érdekes lehetőség volt egy orosz cég számára: a Google Cloud Platform mellett csak az Amazon kínált hasonló szolgáltatást, de mi mégis a Google megoldására telepedtünk le. Akkor számunkra gazdaságilag jövedelmezőbbnek tűnt, közelebb áll az Upstream-hez, nem beszélve arról, hogy a Google maga is egyfajta PoC Kubernetes in Production.
Az első nagyobb probléma az ügyfélkörünk növekedésével jelent meg a láthatáron. Amikor személyes adatok tárolására volt szükségünk, választás elé néztünk: vagy a Google-lal dolgozunk és megsértjük az orosz törvényeket, vagy alternatívát keresünk az Orosz Föderációban. A választás összességében kiszámítható volt. 🙂
Hogyan láttuk az ideális felhőszolgáltatást
A keresés kezdetére már tudtuk, mit szeretnénk kapni a leendő felhőszolgáltatótól. Milyen szolgáltatást kerestünk:
- Gyors és rugalmas. Olyan, hogy bármikor gyorsan hozzáadhatunk új csomópontot vagy telepíthetünk valamit.
- Olcsó. Nagyon aggódtunk a pénzügyi kérdés miatt, mivel korlátozottak voltak a forrásaink. Már korábban is tudtuk, hogy a Kubernetes-szel szeretnénk együttműködni, és most az volt a feladat, hogy minimalizáljuk a költségeit, hogy növeljük vagy legalább megőrizzük a megoldás használatának hatékonyságát.
- automatizált. Úgy terveztük, hogy az API-n keresztül dolgozunk a szolgáltatással, menedzserek és telefonhívások nélkül, vagy olyan helyzetek nélkül, amikor több tucat csomópontot kell manuálisan emelnünk vészhelyzetben. Mivel folyamataink többsége automatizált, a felhőszolgáltatástól is ezt vártuk.
- Szerverekkel az Orosz Föderációban. Természetesen azt terveztük, hogy megfelelünk az orosz jogszabályoknak és ugyanazon 152-FZ.
Akkoriban még kevés Kubernetes aaS szolgáltató működött Oroszországban, és a szolgáltató kiválasztásánál fontos volt számunkra, hogy ne kockáztassuk prioritásainkat. A Mail.ru Cloud Solutions csapata, akikkel megkezdtük a munkát, és jelenleg is együttműködünk, teljesen automatizált szolgáltatást, API-támogatással és kényelmes vezérlőpanellel biztosított számunkra, amely magában foglalja a Horizont is – ezzel gyorsan tetszőleges számú csomópontot tudtunk emelni.
Hogyan sikerült két óra alatt migrálni az MCS-re
Az ilyen lépések során sok cég szembesül nehézségekkel és kudarcokkal, a mi esetünkben azonban nem volt ilyen. Szerencsénk volt: mivel már a migráció megkezdése előtt dolgoztunk a Kubernetesen, egyszerűen kijavítottunk három fájlt, és elindítottuk szolgáltatásainkat az új felhőplatformon, az MCS-n. Hadd emlékeztesselek arra, hogy addigra végre elhagytuk a fémet, és a Google Cloud Platformon éltünk. Ezért maga a költözés nem tartott tovább két óránál, ráadásul kicsivel több időt (kb. egy órát) fordítottunk az adatok másolására a készülékeinkről. Akkoriban már a Spinnaker-t használtuk (multi-cloud CD szolgáltatás a folyamatos kézbesítéshez). Gyorsan hozzáadtuk az új klaszterhez, és a megszokott módon folytattuk a munkát.
A fejlesztési folyamatok automatizálásának és a CI/CD-nek köszönhetően az URUS-nál a Kubernetest egyetlen szakember kezeli (és ez vagyok én). Valamikor egy másik rendszergazda dolgozott velem, de aztán kiderült, hogy már minden fő rutint automatizáltunk, és egyre több a feladat a főtermékünk részéről, és volt értelme erőforrásokat erre irányítani.
Azt kaptuk, amit vártunk a felhőszolgáltatótól, hiszen illúziók nélkül kezdtük meg az együttműködést. Ha voltak is incidensek, azok többnyire technikai jellegűek voltak, és könnyen magyarázhatók a szolgáltatás viszonylagos frissességével. A lényeg az, hogy az MCS csapata gyorsan kiküszöböli a hiányosságokat és gyorsan válaszol a hírnökökben feltett kérdésekre.
Ha összevetem a Google Cloud Platformmal szerzett tapasztalataimat, az ő esetükben azt sem tudtam, hol van a visszajelzés gomb, hiszen egyszerűen nem volt rá szükség. És ha bármilyen probléma merült fel, a Google maga küldött ki egyoldalú értesítéseket. De az MCS esetében szerintem az a nagy előny, hogy a lehető legközelebb vannak az orosz ügyfelekhez - földrajzilag és mentálisan is.
Hogyan látjuk a felhőkkel való munkát a jövőben
Most már szorosan a Kuberneteshez kötődik a munkánk, és az infrastrukturális feladatok szempontjából teljesen megfelel nekünk. Emiatt nem tervezünk sehova sem migrálni róla, pedig folyamatosan új gyakorlatokat, szolgáltatásokat vezetünk be a rutinfeladatok egyszerűsítésére és az újak automatizálására, a szolgáltatások stabilitásának és megbízhatóságának növelésére... Most indítjuk el a Chaos Monkey szolgáltatást (konkrétan , chaoskube-ot használunk, de ez nem változtat a koncepción: ), amelyet eredetileg a Netflix készített. A Chaos Monkey egy egyszerű dolgot tesz: véletlenszerű időpontban törli a véletlenszerű Kubernetes pod. Ez szükséges ahhoz, hogy szolgáltatásunk az n–1 példányszám mellett is normálisan működjön, így képezzük magunkat, hogy felkészüljünk az esetleges problémákra.
Most a harmadik féltől származó megoldások – ugyanazok a felhőplatformok – használatát látom az egyetlen helyes dolognak a fiatal cégek számára. Útjuk kezdetén általában korlátozottak az erőforrásaik, mind emberi, mind pénzügyileg, saját felhő vagy adatközpont felépítése és fenntartása pedig túl drága és munkaigényes. A felhőszolgáltatók lehetővé teszik ezen költségek minimalizálását, tőlük gyorsan beszerezheti a szolgáltatások működéséhez itt és most szükséges erőforrásokat, és utólag fizetheti ezeket az erőforrásokat. Ami az URUS céget illeti, egyelőre hűek maradunk a felhőben lévő Kuberneteshez. De ki tudja, lehet, hogy földrajzilag kell terjeszkednünk, vagy valamilyen konkrét berendezésen alapuló megoldásokat kell megvalósítanunk. Vagy talán az elhasznált erőforrások mennyisége indokolja a saját Kubernetes-et csupasz fémen, mint a régi szép időkben. 🙂
Amit a felhőszolgáltatásokkal való együttműködésből tanultunk
Elkezdtük a Kubernetes használatát csupasz fémen, és még ott is jó volt a maga módján. Erősségei azonban pontosan a felhőben lévő aaS komponensként tárultak fel. Ha kitűzünk egy célt, és mindent automatizálunk, amennyire csak lehet, akkor elkerülhetjük a szállítói bezárkózást, és a felhőszolgáltatók közötti mozgás pár órát vesz igénybe, az idegsejtek pedig nálunk maradnak. Más cégeknek is tanácsot adhatunk: ha saját (felhő) szolgáltatást szeretne elindítani, korlátozott erőforrásokkal és maximális fejlesztési sebességgel, kezdje el azonnal felhő erőforrások bérlésével, és építse fel adatközpontját, miután a Forbes ír rólad.
Forrás: will.com