Kā divu stundu laikā migrēt uz mākoni, pateicoties Kubernetes un automatizācijai

Kā divu stundu laikā migrēt uz mākoni, pateicoties Kubernetes un automatizācijai

Uzņēmums URUS izmēģināja Kubernetes dažādos veidos: neatkarÄ«ga izvietoÅ”ana uz tukÅ”a metāla, Google Cloud, un pēc tam pārsÅ«tÄ«ja savu platformu uz Mail.ru Cloud Solutions (MCS) mākoni. Igors Å iÅ”kins stāsta, kā viņi izvēlējās jaunu mākoņpakalpojumu sniedzēju un kā viņiem izdevās migrēt uz to rekordÄ«sās divās stundās (t3ran), vecākais sistēmas administrators uzņēmumā URUS.

Ko dara URUS?

Ir daudz veidu, kā uzlabot pilsētvides kvalitāti, un viens no tiem ir padarÄ«t to videi draudzÄ«gu. TieÅ”i pie tā strādā uzņēmums URUS ā€” Smart Digital Services. Å eit viņi ievieÅ” risinājumus, kas palÄ«dz uzņēmumiem uzraudzÄ«t svarÄ«gus vides rādÄ«tājus un samazināt to negatÄ«vo ietekmi uz vidi. Sensori apkopo datus par gaisa sastāvu, trokŔņa lÄ«meni un citiem parametriem un pēc tam nosÅ«ta tos uz vienoto URUS-Ekomon platformu analÄ«zei un ieteikumu sniegÅ”anai.

Kā URUS darbojas no iekŔpuses

Tipisks URUS klients ir uzņēmums, kas atrodas dzÄ«vojamā rajonā vai tā tuvumā. Tā varētu bÅ«t rÅ«pnÄ«ca, osta, dzelzceļa depo vai jebkura cita iekārta. Ja mÅ«su klients jau ir saņēmis brÄ«dinājumu, sodÄ«ts par vides piesārņojumu vai vēlas mazāk trokŔņot, samazināt kaitÄ«go izmeÅ”u daudzumu, viņŔ nāk pie mums, un mēs viņam jau piedāvājam gatavu risinājumu vides monitoringam.

Kā divu stundu laikā migrēt uz mākoni, pateicoties Kubernetes un automatizācijai
H2S koncentrācijas monitoringa grafiks parāda regulāras nakts emisijas no tuvējās rūpnīcas

IerÄ«cēs, kuras izmantojam URUS, ir vairāki sensori, kas apkopo informāciju par noteiktu gāzu saturu, trokŔņu lÄ«meni un citus datus, lai novērtētu vides situāciju. PrecÄ«zu sensoru skaitu vienmēr nosaka konkrētais uzdevums.

Kā divu stundu laikā migrēt uz mākoni, pateicoties Kubernetes un automatizācijai
AtkarÄ«bā no mērÄ«jumu specifikas ierÄ«ces ar sensoriem var atrasties uz ēku sienām, stabiem un citās patvaļīgās vietās. Katra Ŕāda ierÄ«ce apkopo informāciju, apkopo to un nosÅ«ta uz datu saņemÅ”anas vārteju. Tur mēs saglabājam datus ilgstoÅ”ai glabāŔanai un iepriekÅ” apstrādājam tos turpmākai analÄ«zei. VienkārŔākais piemērs tam, ko mēs iegÅ«stam analÄ«zes rezultātā, ir gaisa kvalitātes indekss, kas pazÄ«stams arÄ« kā AQI.

Paralēli mūsu platformā darbojas daudzi citi pakalpojumi, taču tie galvenokārt ir pakalpojumu rakstura. Piemēram, paziņojumu dienests nosūta paziņojumus klientiem, ja kāds no uzraudzītajiem parametriem (piemēram, CO2 saturs) pārsniedz pieļaujamo vērtību.

Kā mēs glabājam datus. Stāsts par Kubernetes uz plika metāla

URUS vides monitoringa projektā ir vairākas datu noliktavas. Vienā mēs glabājam ā€œneapstrādātusā€ datus - tos, ko saņēmām tieÅ”i no paŔām ierÄ«cēm. Å Ä« krātuve ir ā€œmagnētiskaā€ lente, tāpat kā vecās kaseÅ”u lentēs, ar visu indikatoru vēsturi. Otrs uzglabāŔanas veids tiek izmantots iepriekÅ” apstrādātiem datiem - datiem no ierÄ«cēm, kas bagātināti ar metadatiem par savienojumiem starp sensoriem un paÅ”u ierīču rādÄ«jumiem, piederÄ«bu organizācijām, atraÅ”anās vietām utt. Å Ä« informācija ļauj dinamiski novērtēt, kā konkrētajam rādÄ«tājam ir izdevies mainÄ«ts noteiktā laika periodā. Mēs izmantojam ā€œneapstrādātoā€ datu krātuvi, cita starpā, kā rezerves kopiju un iepriekÅ” apstrādātu datu atjaunoÅ”anai, ja rodas tāda nepiecieÅ”amÄ«ba.

Kad pirms vairākiem gadiem meklējām mÅ«su krātuves problēmu, mums bija divas platformas izvēles: Kubernetes un OpenStack. Bet, tā kā pēdējais izskatās diezgan briesmÄ«gs (lai par to pārliecinātos, vienkārÅ”i apskatiet tā arhitektÅ«ru), mēs apmetāmies uz Kubernetes. Vēl viens arguments par labu bija salÄ«dzinoÅ”i vienkārŔā programmatÅ«ras vadÄ«ba, iespēja elastÄ«gāk sagriezt pat aparatÅ«ras mezglus atbilstoÅ”i resursiem.

Paralēli paÅ”as Kubernetes apgÅ«Å”anai mēs pētÄ«jām arÄ« datu glabāŔanas veidus, kamēr visu Kubernetes krātuvi saglabājām savā aparatÅ«rā, saņēmām izcilas zināŔanas. Viss, ko mēs toreiz dzÄ«vojām Kubernetes: pilnÄ«ga krātuve, uzraudzÄ«bas sistēma, CI/CD. Kubernetes mums ir kļuvusi par platformu viss vienā.

Bet mēs gribējām strādāt ar Kubernetes kā pakalpojumu, nevis iesaistÄ«ties tā atbalstÄ«Å”anā un attÄ«stÄ«bā. Turklāt mums nepatika, cik mums izmaksāja tā uzturÄ“Å”ana uz tukÅ”a metāla, un mums bija nepiecieÅ”ama nepārtraukta attÄ«stÄ«ba! Piemēram, viens no pirmajiem uzdevumiem bija Kubernetes Ingress kontrolleru integrÄ“Å”ana mÅ«su organizācijas tÄ«kla infrastruktÅ«rā. Tas ir apgrÅ«tinoÅ”s uzdevums, Ä«paÅ”i ņemot vērā to, ka tajā laikā nekas nebija gatavs programmatiskai resursu pārvaldÄ«bai, piemēram, DNS ierakstiem vai IP adreÅ”u pieŔķirÅ”anai. Vēlāk mēs sākām eksperimentēt ar ārējo datu glabāŔanu. Mēs nekad nesaņēmām PVC kontroliera ievieÅ”anu, taču jau tad kļuva skaidrs, ka Ŕī ir liela darba joma, kurā nepiecieÅ”ami Ä«paÅ”i speciālisti.

PārslēgÅ”anās uz Google Cloud Platform ir pagaidu risinājums

Mēs sapratām, ka tā nevar turpināties, un pārvietojām savus datus no tukÅ”a metāla uz Google Cloud Platform. Faktiski tajā laikā Krievijas uzņēmumam nebija daudz interesantu iespēju: bez Google Cloud Platform lÄ«dzÄ«gu pakalpojumu piedāvāja tikai Amazon, taču mēs joprojām izvēlējāmies Google risinājumu. Tad mums tas likās ekonomiski izdevÄ«gāk, tuvāk Upstream, nemaz nerunājot par to, ka pats Google ir sava veida PoC Kubernetes in Production.

Pirmā lielākā problēma parādÄ«jās pie apvārŔņa, kad mÅ«su klientu bāze pieauga. Kad mums radās nepiecieÅ”amÄ«ba uzglabāt personas datus, mēs bijām izvēles priekŔā: vai nu sadarbojamies ar Google un pārkāpjam Krievijas likumus, vai arÄ« meklējam alternatÄ«vu Krievijas Federācijā. Izvēle kopumā bija paredzama. šŸ™‚

Kā mēs redzējām ideālo mākoņpakalpojumu

MeklÄ“Å”anas sākumā mēs jau zinājām, ko vēlamies iegÅ«t no topoŔā mākoņpakalpojuma sniedzēja. Kādu pakalpojumu mēs meklējām:

  • Ātri un elastÄ«gi. Tāds, lai mēs jebkurā laikā varētu ātri pievienot jaunu mezglu vai kaut ko izvietot.
  • Lēti. Mēs bijām ļoti noraizējuÅ”ies par finanÅ”u jautājumu, jo mums bija ierobežoti resursi. Jau iepriekÅ” zinājām, ka vēlamies strādāt ar Kubernetes, un tagad uzdevums bija minimizēt tā izmaksas, lai palielinātu vai vismaz saglabātu Ŕī risinājuma lietoÅ”anas efektivitāti.
  • Automatizēta. Mēs plānojām strādāt ar pakalpojumu caur API, bez vadÄ«tājiem un telefona zvaniem vai situācijām, kad ārkārtas režīmā manuāli jāpaceļ vairāki desmiti mezglu. Tā kā lielākā daļa mÅ«su procesu ir automatizēti, to paÅ”u gaidÄ«jām arÄ« no mākoņpakalpojuma.
  • Ar serveriem Krievijas Federācijā. Protams, mēs plānojām ievērot Krievijas tiesÄ«bu aktus un to paÅ”u 152-FZ.

Tolaik Krievijā bija maz Kubernetes aaS nodroÅ”inātāju, un, izvēloties pakalpojumu sniedzēju, mums bija svarÄ«gi neapdraudēt savas prioritātes. Mail.ru Cloud Solutions komanda, ar kuru mēs sākām strādāt un joprojām sadarbojamies, nodroÅ”ināja mums pilnÄ«bā automatizētu pakalpojumu, API atbalstu un ērtu vadÄ«bas paneli, kas ietver Horizon - ar to mēs varētu ātri palielināt patvaļīgu skaitu mezglu.

Kā mums izdevās migrēt uz MCS divās stundās

Šādos gājienos daudzi uzņēmumi saskaras ar grÅ«tÄ«bām un neveiksmēm, bet mÅ«su gadÄ«jumā tādu nebija. Mums paveicās: tā kā mēs jau strādājām pie Kubernetes pirms migrācijas sākuma, mēs vienkārÅ”i izlabojām trÄ«s failus un palaidām savus pakalpojumus jaunajā mākoņa platformā MCS. AtgādināŔu, ka lÄ«dz tam laikam mēs beidzot bijām pametuÅ”i pliko metālu un dzÄ«vojām Google mākoņu platformā. Tāpēc pati pārvietoÅ”ana aizņēma ne vairāk kā divas stundas, kā arÄ« nedaudz vairāk laika (apmēram stunda) pagāja datu kopÄ“Å”anai no mÅ«su ierÄ«cēm. Toreiz mēs jau izmantojām Spinnaker (vairāku mākoņu CD pakalpojumu, lai nodroÅ”inātu nepārtrauktu piegādi). Mēs to arÄ« ātri pievienojām jaunajam klasterim un turpinājām strādāt kā parasti.

Pateicoties izstrādes procesu un CI/CD automatizācijai, Kubernetes URUS pārvalda viens speciālists (un tas esmu es). Kādā posmā ar mani strādāja cits sistēmas administrators, bet tad izrādÄ«jās, ka mēs jau esam automatizējuÅ”i visu galveno rutÄ«nu un mÅ«su galvenā produkta uzdevumi bija arvien vairāk un bija jēga novirzÄ«t resursus tam.

Mēs saņēmām to, ko gaidÄ«jām no mākoņa pakalpojumu sniedzēja, jo sākām sadarbÄ«bu bez ilÅ«zijām. Ja arÄ« bija kādi negadÄ«jumi, tie galvenokārt bija tehniski un tādi, kurus varētu viegli izskaidrot ar pakalpojuma relatÄ«vo svaigumu. Galvenais, lai MCS komanda ātri novērÅ” trÅ«kumus un ātri atbild uz jautājumiem kurjeros.

Ja salÄ«dzinu savu pieredzi ar Google Cloud Platform, viņu gadÄ«jumā es pat nezināju, kur atrodas atsauksmju poga, jo tā vienkārÅ”i nebija vajadzÄ«ga. Un, ja radās kādas problēmas, Google pati vienpusēji izsÅ«tÄ«ja paziņojumus. Bet MCS gadÄ«jumā, manuprāt, liela priekÅ”rocÄ«ba ir tā, ka viņi ir maksimāli tuvu Krievijas klientiem - gan Ä£eogrāfiski, gan mentāli.

Kā mēs redzam darbu ar mākoņiem nākotnē

Tagad mÅ«su darbs ir cieÅ”i saistÄ«ts ar Kubernetes, un tas mums pilnÄ«bā atbilst no infrastruktÅ«ras uzdevumu viedokļa. Tāpēc mēs neplānojam no tā nekur migrēt, lai gan mēs pastāvÄ«gi ievieÅ”am jaunas prakses un pakalpojumus, lai vienkārÅ”otu rutÄ«nas uzdevumus un automatizētu jaunus, palielinātu pakalpojumu stabilitāti un uzticamÄ«bu... Tagad mēs ievieÅ”am pakalpojumu Chaos Monkey (konkrēti , mēs izmantojam chaoskube, taču tas nemaina koncepciju: ), kuru sākotnēji izveidoja Netflix. Chaos Monkey veic vienu vienkārÅ”u darbÄ«bu: tas nejauŔā laikā izdzÄ“Å” nejauÅ”u Kubernetes aplikumu. Tas ir nepiecieÅ”ams, lai mÅ«su pakalpojums varētu normāli darboties ar gadÄ«jumu skaitu nā€“1, tāpēc mēs apmācām sevi bÅ«t gataviem jebkurām problēmām.

Tagad es redzu treÅ”o puÅ”u risinājumu izmantoÅ”anu - tās paÅ”as mākoņu platformas - kā vienÄ«go pareizo lietu jauniem uzņēmumiem. Parasti ceļojuma sākumā viņiem ir ierobežoti resursi ā€“ gan cilvēkresursi, gan finansiāli, un sava mākoņa vai datu centra izveide un uzturÄ“Å”ana ir pārāk dārga un darbietilpÄ«ga. Mākoņpakalpojumu sniedzēji ļauj minimizēt Ŕīs izmaksas, no tiem var ātri iegÅ«t pakalpojumu darbÄ«bai nepiecieÅ”amos resursus Å”eit un tagad un pēc tam par Å”iem resursiem samaksāt. Kas attiecas uz uzņēmumu URUS, tad pagaidām paliksim uzticÄ«gi Kubernetes mākonÄ«. Bet kas zina, mums var nākties paplaÅ”ināties Ä£eogrāfiski vai ieviest risinājumus, pamatojoties uz kādu konkrētu aprÄ«kojumu. Vai varbÅ«t patērēto resursu daudzums attaisnos paÅ”u Kubernetes uz pliko metālu, kā vecajos labajos laikos. šŸ™‚

Ko mēs iemācījāmies, strādājot ar mākoņpakalpojumiem

Mēs sākām lietot Kubernetes uz plika metāla, un pat tur tas bija labs savā veidā. Bet tā stiprās puses tika atklātas tieÅ”i kā aaS komponents mākonÄ«. Izvirzot mērÄ·i un maksimāli visu automatizējot, varēsiet izvairÄ«ties no pārdevēju bloÄ·Ä“Å”anās un pārvietoÅ”anās starp mākoņpakalpojumu sniedzējiem prasÄ«s pāris stundas, un nervu Ŕūnas paliks pie mums. Mēs varam ieteikt citiem uzņēmumiem: ja vēlaties uzsākt savu (mākoņa) pakalpojumu ar ierobežotiem resursiem un maksimālo attÄ«stÄ«bas ātrumu, sāciet tÅ«lÄ«t ar mākoņa resursu nomu un izveidojiet savu datu centru pēc tam, kad Forbes par jums rakstÄ«s.

Avots: www.habr.com

Pievieno komentāru