URUS enpresak Kubernetes probatu zuen hainbat eratan: inplementazio independentea metal hutsean, Google Cloud-en, eta gero bere plataforma Mail.ru Cloud Solutions (MCS) hodeira transferitu zuen. Igor Shishkinek kontatzen du nola aukeratu zuten hodeiko hornitzaile berri bat eta nola lortu zuten hara migratzea bi orduko erregistroan (), URUSeko sistema-administratzaile seniorra.
Zer egiten du URUSek?
Modu asko daude hiri-ingurunearen kalitatea hobetzeko, eta horietako bat da ingurumena errespetatzen duena. Hain zuzen, horretan ari da URUS - Smart Digital Services konpainia. Bertan, enpresei ingurumen-adierazle garrantzitsuak kontrolatzen eta ingurumenean duten eragin negatiboa murrizten laguntzen dieten irtenbideak ezartzen dituzte. Sentsoreek airearen konposizioari, zarata-mailari eta beste parametro batzuei buruzko datuak biltzen dituzte, eta, ondoren, URUS-Ekomon plataforma bateratura bidaltzen dituzte aztertzeko eta gomendioak egiteko.
URUSek nola funtzionatzen duen barrutik
URUSen ohiko bezero bat egoitza-gune batean edo gertu dagoen enpresa bat da. Hau fabrika, portua, tren-biltegia edo beste edozein instalazio izan daiteke. Gure bezeroak dagoeneko abisua jaso badu, ingurumenaren kutsaduragatik isuna jaso badu, edo zarata gutxiago egin, isuri kaltegarrien kopurua murriztu nahi badu, guregana etortzen da, eta dagoeneko prest dagoen irtenbide bat eskaintzen diogu ingurumena zaintzeko.
H2S kontzentrazioa kontrolatzeko grafikoak inguruko zentral bateko gaueko isuri erregularrak erakusten ditu
URUSen erabiltzen ditugun gailuek zenbait sentsore dituzte, eta ingurumen-egoera ebaluatzeko zenbait gasen edukiari, zarata-mailari eta bestelako datuei buruzko informazioa biltzen dute. Sentsore kopuru zehatza zeregin zehatzaren arabera zehazten da beti.
Neurketen berezitasunen arabera, sentsoreak dituzten gailuak eraikin, zutoin eta beste leku arbitrarioetako hormetan kokatu daitezke. Horrelako gailu bakoitzak informazioa bildu, batu eta datuak jasotzeko atebidera bidaltzen du. Bertan datuak gorde egiten ditugu epe luzerako biltegiratzeko eta aldez aurretik prozesatzen ditugu ondoren aztertzeko. Azterketaren ondorioz lortzen dugunaren adibiderik errazena airearen kalitatearen indizea da, AQI izenez ere ezaguna.
Aldi berean, beste hainbat zerbitzuk funtzionatzen dute gure plataforman, baina batez ere zerbitzu izaera dute. Adibidez, jakinarazpen-zerbitzuak jakinarazpenak bidaltzen dizkie bezeroei, kontrolatutako parametroren batek (adibidez, CO2 edukia) baimendutako balioa gainditzen badu.
Nola gordetzen ditugun datuak. Kubernetesen istorioa bare metalean
URUS ingurumena zaintzeko proiektuak hainbat datu biltegi ditu. Batean datu "gordinak" gordetzen ditugu, gailuetatik zuzenean jasotakoa. Biltegiratze hau zinta "magnetikoa" da, kasete zinta zaharretan bezala, adierazle guztien historia duena. Bigarren biltegiratze mota aurreprozesatutako datuetarako erabiltzen da: gailuetako datuak, sentsoreen arteko konexioei eta gailuen beraren irakurketei buruzko metadatuekin aberastuta, erakundeekiko afiliazioa, kokapenak, etab. Informazio honek adierazle jakin batek nola izan duen modu dinamikoan ebaluatzeko aukera ematen du. denbora tarte jakin batean aldatu da. Datu βgordinakβ biltegiratzea erabiltzen dugu, besteak beste, babeskopia gisa eta aurrez prozesatutako datuak leheneratzeko, halako beharrik balego.
Duela urte batzuk gure biltegiratze-arazoa konpondu nahi genuenean, bi plataforma aukera izan genituen: Kubernetes eta OpenStack. Baina azken honek nahiko munstroa dirudienez (bere arkitektura begiratu besterik ez dago honetaz konbentzitzeko), Kubernetesen jarri ginen. Haren aldeko beste argumentu bat softwarearen kontrol sinple samarra izan zen, baliabideen arabera hardware-nodoak ere malgutasun handiagoz mozteko gaitasuna.
Kubernetes bera menperatzearekin batera, datuak gordetzeko moduak ere aztertu genituen, Kubernetes-en biltegiratze guztia gure hardwarean gordetzen genuen bitartean, esperientzia bikaina jaso genuen. Orduan Kubernetesen bizi genuen guztia: biltegiratze egoera osoa, monitorizazio sistema, CI/CD. Kubernetes bat-bateko plataforma bihurtu da guretzat.
Baina Kubernetes zerbitzu gisa lan egin nahi genuen, eta ez haren laguntza eta garapenean parte hartu. Gainera, ez zitzaigun gustatu zenbat kostatu zitzaigun bare metalean mantentzea, eta etengabeko garapena behar genuen! Esaterako, lehen lanetako bat Kubernetes Ingress kontrolagailuak gure erakundearen sare-azpiegituran integratzea izan zen. Lan astuna da, batez ere, garai hartan ez zegoela ezer prest baliabide programatikoen kudeaketarako, hala nola DNS erregistroak edo IP helbideak esleitzeko. Geroago, kanpoko datuen biltegiratzearekin esperimentatzen hasi ginen. Inoiz ez ginen PVC kontrolagailua ezartzera iritsi, baina orduan ere argi geratu zen espezialista dedikatuak behar zituen lan-eremu handia zela.
Google Cloud Platform-era aldatzea aldi baterako irtenbide bat da
Honek ezin zuela jarraitu konturatu ginen eta gure datuak bare metaletik Google Cloud Platformera eraman genituen. Izan ere, garai hartan ez zegoen Errusiako enpresa baterako aukera interesgarri askorik: Google Cloud Platform-en gain, Amazonek bakarrik eskaintzen zuen antzeko zerbitzu bat, baina hala ere Google-ren konponbidea finkatu genuen. Orduan ekonomikoki errentagarriagoa iruditu zitzaigun, Upstreametik gertuago, Google bera Produkzioan PoC Kubernetes moduko bat dela aipatu gabe.
Lehen arazo nagusia zeruertzean agertu zen gure bezero-basea hazi ahala. Datu pertsonalak gordetzeko beharra izan genuenean, aukera baten aurrean geunden: edo Googlerekin lan egiten dugu eta Errusiako legeak urratzen ditugu, edo Errusiar Federazioan alternatiba baten bila gabiltza. Aukera, oro har, aurreikusgarria zen. π
Nola ikusi genuen hodeiko zerbitzu ideala
Bilaketa hasi zenerako, bagenekien zer lortu nahi genuen etorkizuneko hodei hornitzailetik. Zer zerbitzu bilatzen genuen:
- Azkarra eta malgua. Hala nola, nodo berri bat azkar gehi dezakegu edo edozein unetan zerbait zabaldu.
- Merkea. Asko kezkatzen gintuen finantza gaiak, baliabideak mugatuak baitziren. Lehendik ere bagenekien Kubernetesekin lan egin nahi genuela, eta orain bere kostua gutxitzea zen zeregina, irtenbide hau erabiltzearen eraginkortasuna handitzeko edo gutxienez mantentzeko.
- automatizatu. Zerbitzuarekin APIaren bidez lan egitea aurreikusi genuen, kudeatzailerik eta telefono deirik gabe edo larrialdi moduan hainbat dozena nodo eskuz igo behar ditugun egoerarik gabe. Gure prozesu gehienak automatizatuak direnez, hodeiko zerbitzutik gauza bera espero genuen.
- Errusiako Federazioko zerbitzariekin. Noski, Errusiako legedia eta 152-FZ bera betetzea aurreikusi genuen.
Garai hartan, Errusian Kubernetes aaS hornitzaile gutxi zeuden, eta hornitzaile bat aukeratzerakoan garrantzitsua zen gure lehentasunak ez arriskuan jartzea. Mail.ru Cloud Solutions taldeak, harekin lanean hasi ginen eta kolaboratzen jarraitzen dugu, zerbitzu guztiz automatizatu bat eskaini zigun, API laguntzarekin eta Horizon barne hartzen duen kontrol-panel erosoa - horrekin nodo kopuru arbitrario bat azkar igo genezake.
Nola lortu genuen bi ordutan MCSra migratzea
Horrelako mugimenduetan, enpresa askok zailtasunak eta atzerapausoak izaten dituzte, baina gure kasuan ez zegoen halakorik. Zortea izan dugu: migrazioa hasi baino lehen Kubernetes-en lanean ari ginenez, hiru fitxategi zuzendu besterik ez dugu egin eta gure zerbitzuak hodeiko plataforma berrian abiarazi ditugu, MCS. Gogorarazten dizut ordurako azkenean metal hutsa utzi eta Google Cloud Platform-en bizi ginela. Hori dela eta, mugimenduak berak ez zuen bi ordu baino gehiago behar izan, eta denbora pixka bat gehiago (ordu bat inguru) eman zen gure gailuetako datuak kopiatzen. Orduan jada Spinnaker erabiltzen genuen (Hodei anitzeko CD-zerbitzua, Entrega Etengabea emateko). Era berean, azkar gehitu genuen kluster berrian eta lanean jarraitu genuen ohi bezala.
Garapen prozesuen eta CI/CD automatizazioari esker, URUSeko Kubernetes espezialista batek (eta ni naiz) kudeatzen du. Noizbait, beste sistema-administratzaile batek lan egin zuen nirekin, baina orduan konturatu zen jada errutina nagusi guztiak automatizatuta genituela eta gure produktu nagusiaren aldetik gero eta zeregin gehiago zeudela eta zentzuzkoa zela baliabideak horretara bideratzea.
Hodeiko hornitzailearengandik espero genuena jaso genuen, ilusiorik gabe lankidetzan hasi ginenetik. Gorabeherak egonez gero, gehienbat teknikoak ziren eta zerbitzuaren freskotasun erlatiboaz erraz azal daitezkeenak. Gauza nagusia da MCS taldeak gabeziak azkar kentzen dituela eta mezularietako galderei azkar erantzuten diela.
Google Cloud Platform-ekin dudan esperientzia alderatzen badut, haien kasuan ez nekien feedback botoia non zegoen ere, ez baitzegoen horren beharrik. Eta arazoren bat gertatuz gero, Google-k berak bidaltzen zituen jakinarazpenak aldebakarrean. Baina MCS-ren kasuan, abantaila handia dela uste dut Errusiako bezeroengandik ahalik eta gertuen daudela, bai geografikoki eta baita mentalki ere.
Nola ikusten dugun etorkizunean hodeiekin lan egitea
Orain gure lana Kubernetesekin estu lotuta dago, eta guztiz egokitzen zaigu azpiegituren zereginen ikuspuntutik. Hori dela eta, ez dugu bertatik inon migratzeko asmorik, nahiz eta etengabe ari garen praktika eta zerbitzu berriak sartzen ohiko zereginak errazteko eta berriak automatizatzeko, zerbitzuen egonkortasuna eta fidagarritasuna areagotzeko... Orain Chaos Monkey zerbitzua abiarazten ari gara (zehazki. , chaoskube erabiltzen dugu, baina horrek ez du kontzeptua aldatzen: ), jatorriz Netflixek sortu zuena. Chaos Monkey-k gauza sinple bat egiten du: ausazko Kubernetes pod bat ausazko unean ezabatzen du. Hau beharrezkoa da gure zerbitzuak nβ1 instantzia-kopuruarekin normal bizitzeko, beraz, edozein arazotarako prestatuta egoteko entrenatzen gara.
Orain hirugarrenen soluzioen erabilera -hodeiko plataforma berberak- enpresa gazteentzako gauza bakarra dela ikusten dut. Normalean, bidaiaren hasieran, baliabideak mugatuta daude, bai giza zein finantza, eta hodeia edo datu-zentro propioa eraiki eta mantentzea garestiegia eta lan-eskaintza handia da. Hodeiko hornitzaileek kostu horiek minimizatzeko aukera ematen dute; haiengandik azkar lor ditzakezu hemen eta orain zerbitzuen funtzionamendurako beharrezkoak diren baliabideak, eta baliabide horiek ordaindu ondoren. URUS enpresari dagokionez, Kubernetes hodeian fidel jarraituko dugu oraingoz. Baina nork daki, baliteke geografikoki zabaldu behar izatea, edo ekipamendu zehatz batzuetan oinarritutako irtenbideak ezarri. Edo agian kontsumitutako baliabideen kopuruak Kubernetes propioa justifikatuko du bare-metal-ean, garai onetan bezala. π
Hodeiko zerbitzuekin lan eginez ikasi genuena
Kubernetes bare metalean erabiltzen hasi ginen, eta han ere ona zen bere erara. Baina bere indarguneak hodeian aaS osagai gisa agertu ziren hain zuzen. Helburu bat ezarri eta dena ahalik eta gehien automatizatzen baduzu, saltzaileen blokeoa saihestu ahal izango duzu eta hodeiko hornitzaileen artean mugitzeak pare bat ordu beharko ditu eta nerbio-zelulak gurekin geratuko dira. Beste enpresa batzuei aholkua eman diezaiekegu: zure (hodeiko) zerbitzua abiarazi nahi baduzu, baliabide mugatuak eta garapenerako abiadura maximoa izanez gero, hasi oraintxe hodeiko baliabideak alokatuz eta eraiki zure datu-zentroa Forbesek zutaz idatzi ondoren.
Iturria: www.habr.com