Mūsdienu infrastruktūra: problēmas un perspektīvas

Mūsdienu infrastruktūra: problēmas un perspektīvas

Maija beigās mēs sarÄ«koja tieÅ”saistes sanāksmi par Å”o tēmu ā€œMÅ«sdienÄ«ga infrastruktÅ«ra un konteineri: problēmas un perspektÄ«vasā€. Runājām par konteineriem, Kubernetes un orÄ·estrÄ“Å”anu principā, infrastruktÅ«ras izvēles kritērijiem un daudz ko citu. DalÄ«bnieki dalÄ«jās ar gadÄ«jumiem no savas prakses.

Dalībnieki:

  • Jevgeņijs Potapovs, ITSumma izpilddirektors. Vairāk nekā puse tās klientu jau pārceļas vai vēlas pāriet uz Kubernetes.
  • Dmitrijs Stoļarovs, CTO "Flant". Ir 10+ gadu pieredze darbā ar konteineru sistēmām.
  • Deniss Remčukovs (pazÄ«stams arÄ« kā Ēriks Oldmans), argotech.io COO, bijuÅ”ais RAO UES. ViņŔ solÄ«ja runāt par gadÄ«jumiem ā€œasiņainajāā€ uzņēmumā.
  • Andrejs Fedorovskis, ā€œNews360.comā€ tehnoloÄ£iju vadÄ«tājsPēc tam, kad cits spēlētājs ir iegādājies uzņēmumu, viņŔ ir atbildÄ«gs par vairākiem ML un AI projektiem un infrastruktÅ«ru.
  • Ivans Kruglovs, sistēmu inženieris, bijuÅ”ais Booking.com.Tas pats, kurÅ” ar Kubernetes ar savām rokām daudz darÄ«ja.

Tēmas:

  • DalÄ«bnieku atziņas par konteineriem un orÄ·estrāciju (Docker, Kubernetes u.c.); kas tika izmēģināts praksē vai analizēts.
  • GadÄ«jums: Uzņēmums gadiem ilgi veido infrastruktÅ«ras attÄ«stÄ«bas plānu. Kā tiek pieņemts lēmums, vai bÅ«vēt (vai migrēt paÅ”reizējo) infrastruktÅ«ru uz konteineriem un Kuber vai nē?
  • Problēmas mākoņu dzimtajā pasaulē, kas trÅ«kst, iedomāsimies, kas notiks rÄ«t.

Izvērsās interesanta diskusija, dalībnieku viedokļi bija tik dažādi un izraisīja tik daudz komentāru, ka vēlos padalīties ar jums. Ēst trīs stundu video, un zemāk ir diskusijas kopsavilkums.

Vai Kubernetes jau ir standarts vai lielisks mārketings?

ā€œMēs nonācām pie tā (Kubernetes. - Red.), kad neviens par to vēl nezināja. Mēs nācām pie viņa pat tad, kad viņa nebija. Mēs to gribējām agrāk" - Dmitrijs Stoļarovs

Mūsdienu infrastruktūra: problēmas un perspektīvas
Foto no Reddit.com

Pirms 5-10 gadiem bija milzÄ«gs skaits instrumentu, un nebija vienota standarta. Ik pēc seÅ”iem mēneÅ”iem parādÄ«jās jauns produkts vai pat vairāk nekā viens. Vispirms Vagrant, tad Sāls, Å efpavārs, Lelle,... un jÅ«s atjaunojat savu infrastruktÅ«ru ik pēc seÅ”iem mēneÅ”iem. Jums ir pieci administratori, kuri pastāvÄ«gi ir aizņemti ar konfigurāciju pārrakstÄ«Å”anu,ā€ atceras Andrejs Fedorovskis. ViņŔ uzskata, ka Dokers un Kubernetes ir ā€œizspieduÅ”iā€ pārējos. Docker ir kļuvis par standartu pēdējo piecu gadu laikā, Kubernetes - pēdējos divos gados. Un tas nāk par labu nozarei..

Dmitrijs Stoļarovs un viņa komanda mÄ«l Kuberu. Viņi gribēja Ŕādu rÄ«ku, pirms tas parādÄ«jās, un nonāca pie tā, kad neviens par to nezināja. Å obrÄ«d ērtÄ«bas labad viņi neuzņemas klientu, ja saprot, ka ar viņu Kubernetes neieviesÄ«s. Tajā paŔā laikā, pēc Dmitrija teiktā, uzņēmumam ir "daudzi gigantiski veiksmes stāsti par briesmÄ«gā mantojuma pārveidoÅ”anu".

Kubernetes ir ne tikai konteineru orÄ·estrÄ“Å”ana, tā ir konfigurācijas pārvaldÄ«bas sistēma ar izstrādātu API, tÄ«kla komponentu, L3 balansÄ“Å”anas un ieejas kontrolleriem, kas ļauj salÄ«dzinoÅ”i viegli pārvaldÄ«t resursus, mērogot un abstrakti no infrastruktÅ«ras apakŔējiem slāņiem.

Diemžēl mÅ«su dzÄ«vē mums par visu ir jāmaksā. Un Å”is nodoklis ir liels, it Ä«paÅ”i, ja runājam par uzņēmuma ar attÄ«stÄ«tu infrastruktÅ«ru pāreju uz Kubernetes, kā uzskata Ivans Kruglovs. ViņŔ varēja brÄ«vi strādāt gan uzņēmumā ar tradicionālu infrastruktÅ«ru, gan ar Kuber. Galvenais ir izprast uzņēmuma un tirgus Ä«paŔības. Bet, piemēram, Jevgeņijam Potapovam, kurÅ” Kubernetes vispārinātu uz jebkuru konteineru orÄ·estrÄ“Å”anas rÄ«ku, Ŕāds jautājums nerodas.

Jevgeņijs radÄ«ja analoÄ£iju ar situāciju 1990. gados, kad objektorientētā programmÄ“Å”ana parādÄ«jās kā sarežģītu lietojumprogrammu programmÄ“Å”anas veids. Tajā laikā debates turpinājās, un parādÄ«jās jauni rÄ«ki OOP atbalstam. Tad mikropakalpojumi parādÄ«jās kā veids, kā attālināties no monolÄ«ta koncepcijas. Tas savukārt izraisÄ«ja konteineru un konteineru pārvaldÄ«bas rÄ«ku raÅ”anos. "Domāju, ka drÄ«z pienāks brÄ«dis, kad vairs nebÅ«s jautājumu par to, vai ir vērts rakstÄ«t mazo mikropakalpojuma aplikāciju, tā pēc noklusējuma tiks rakstÄ«ta kā mikropakalpojums," viņŔ uzskata. Tāpat Docker un Kubernetes galu galā kļūs par standarta risinājumu bez nepiecieÅ”amÄ«bas izvēlēties.

Datu bāzu problēma bezvalstnieku režīmā

Mūsdienu infrastruktūra: problēmas un perspektīvas
Foto Twitter: @jankolario vietnē Unsplash

MÅ«sdienās ir daudz recepÅ”u datu bāzu darbināŔanai Kubernetes. Pat kā atdalÄ«t daļu, kas strādā ar I/O disku no, nosacÄ«ti, datu bāzes lietojumprogrammu daļas. Vai ir iespējams, ka nākotnē datubāzes mainÄ«sies tik ļoti, ka tās tiks piegādātas kastē, kur viena daļa tiks orÄ·estrēta caur Docker un Kubernetes, bet citā infrastruktÅ«ras daļā caur atseviŔķu programmatÅ«ru tiks nodroÅ”ināta uzglabāŔanas daļa ? Vai bāzes mainÄ«sies kā produkts?

Å is apraksts ir lÄ«dzÄ«gs rindu pārvaldÄ«bai, taču prasÄ«bas attiecÄ«bā uz uzticamÄ«bu un informācijas sinhronizāciju tradicionālajās datubāzēs ir daudz augstākas, uzskata Andrejs. KeÅ”atmiņas trāpÄ«jumu attiecÄ«ba parastajās datubāzēs saglabājas 99%. Ja darbinieks pazÅ«d, tiek palaists jauns, un keÅ”atmiņa ā€œuzsilstā€ no nulles. Kamēr keÅ”atmiņa nav iesildÄ«ta, darbinieks strādā lēni, kas nozÄ«mē, ka to nevar ielādēt ar lietotāja slodzi. Kamēr nav lietotāja slodzes, keÅ”atmiņa nesasilst. Tas ir apburtais loks.

Dmitrijs bÅ«tÄ«bā nepiekrÄ«t - kvorumi un sadalÄ«Å”ana atrisina problēmu. Taču Andrejs uzstāj, ka risinājums nav piemērots visiem. Dažās situācijās kvorums ir piemērots, taču tas rada papildu slodzi tÄ«klam. NoSQL datu bāze nav piemērota visos gadÄ«jumos.

TikÅ”anās dalÄ«bnieki tika sadalÄ«ti divās nometnēs.

Deniss un Andrejs strÄ«das, ka viss, kas tiek ierakstÄ«ts diskā ā€“ datubāzes un tā tālāk ā€“ paÅ”reizējā Kuber ekosistēmā nav izdarāms. Kubernetes nav iespējams saglabāt ražoÅ”anas datu integritāti un konsekvenci. Tā ir fundamentāla iezÄ«me. Risinājums: hibrÄ«da infrastruktÅ«ra.

Pat modernām mākoņdatām, piemēram, MongoDB un Cassandra, vai ziņojumu rindām, piemēram, Kafka vai RabbitMQ, ir nepiecieÅ”ami pastāvÄ«gi datu krātuvi ārpus Kubernetes.

Jevgeņijs iebilst: "Bāzes Kuberā ir gandrÄ«z Krievijai vai gandrÄ«z uzņēmumam radusies trauma, kas saistÄ«ta ar faktu, ka Krievijā nav mākoņa adopcijas." Mazie vai vidējie uzņēmumi Rietumos ir Cloud. Amazon RDS datu bāzes ir vieglāk lietojamas nekā paÅ”am Ä·erties pie Kubernetes. Krievijā viņi izmanto Kuber ā€œon-premiseā€ un nodod tai bāzes, kad viņi cenÅ”as atbrÄ«voties no zoodārza.

Dmitrijs arÄ« nepiekrita apgalvojumam, ka Kubernetes nevar uzturēt nekādas datubāzes: ā€œBāze atŔķiras no bāzes. Un, ja jÅ«s nospiežat milzÄ«gu relāciju datu bāzi, tad nekādā gadÄ«jumā. Ja tu spiedÄ«si kaut ko mazu un mākoņainu dzimto, kas ir garÄ«gi sagatavots daļēji Ä«slaicÄ«gai dzÄ«vei, viss bÅ«s kārtÄ«bā. Dmitrijs arÄ« minēja, ka datu bāzes pārvaldÄ«bas rÄ«ki nav gatavi ne Docker, ne Kuber, tāpēc rodas lielas grÅ«tÄ«bas.

Savukārt Ivans ir pārliecināts, ka pat abstrahējoties no jēdzieniem ā€œstacionārsā€ un ā€œbezvalstnieksā€, uzņēmumu risinājumu ekosistēma Kubernetes vēl nav gatava. Izmantojot Kuber, ir grÅ«ti ievērot likumdoÅ”anas un regulējoŔās prasÄ«bas. Piemēram, nav iespējams izveidot identitātes nodroÅ”ināŔanas risinājumu, kurā ir nepiecieÅ”amas stingras servera identifikācijas garantijas, lÄ«dz pat aparatÅ«rai, kas tiek ievietota serveros. Å Ä« joma attÄ«stās, bet risinājuma vēl nav.
DalÄ«bnieki nespēja vienoties, tāpēc Å”ajā daļā nekādi secinājumi netiks izdarÄ«ti. Sniegsim pāris praktiskus piemērus.

1. gadÄ«jums. ā€œMegaregulatoraā€ kiberdroŔība ar bāzēm ārpus Kuberas

Izstrādātas kiberdroŔības sistēmas gadÄ«jumā konteineru un orÄ·estrācijas izmantoÅ”ana ļauj cÄ«nÄ«ties pret uzbrukumiem un ielauÅ”anos. Piemēram, vienā megaregulatorā Deniss un viņa komanda ieviesa orÄ·estra kombināciju ar apmācÄ«tu SIEM pakalpojumu, kas reāllaikā analizē žurnālus un nosaka uzbrukuma, uzlauÅ”anas vai kļūmes procesu. Uzbrukuma, mēģinājuma kaut ko ievietot vai ransomware vÄ«rusa invāzijas gadÄ«jumā tas ar orÄ·estra starpniecÄ«bu paņem konteinerus ar lietojumprogrammām ātrāk, nekā tie tiek inficēti, vai ātrāk, nekā uzbrucējs tām uzbrÅ«k.

2. gadÄ«jums. Booking.com datu bāzu daļēja migrÄ“Å”ana uz Kubernetes

Vietnē Booking.com galvenā datu bāze ir MySQL ar asinhrono replikāciju ā€“ ir galvenais un vesela vergu hierarhija. LÄ«dz brÄ«dim, kad Ivans pameta uzņēmumu, tika uzsākts projekts, lai pārvietotu vergus, kurus varēja ā€œnoÅ”autā€ ar noteiktiem bojājumiem.

Papildus galvenajai bāzei ir arÄ« Cassandra instalācija ar paÅ”rakstÄ«tu orÄ·estrāciju, kas tika uzrakstÄ«ta vēl pirms Kuber ieieÅ”anas mainstream. Å ajā sakarā nav problēmu, taču tas ir noturÄ«gs vietējos SSD. Attālā krātuve, pat tajā paŔā datu centrā, netiek izmantota lielā latentuma problēmas dēļ.

TreŔā datu bāzu klase ir Booking.com meklÄ“Å”anas pakalpojums, kur katrs pakalpojuma mezgls ir datu bāze. Mēģinājumi pārsÅ«tÄ«t meklÄ“Å”anas pakalpojumu uz Kuber neizdevās, jo katram mezglam ir 60ā€“80 GB vietējās krātuves, kuru ir grÅ«ti ā€œpaceltā€ un ā€œuzsildÄ«tā€.

Rezultātā meklētājs uz Kubernetes netika nodots, un Ivans nedomā, ka tuvākajā laikā bÅ«s jauni mēģinājumi. MySQL datu bāze tika pārsÅ«tÄ«ta uz pusēm: tikai vergi, kuri nebaidās tikt ā€œnoÅ”autiā€. Kasandra ir lieliski iejutusies.

Infrastruktūras izvēle kā uzdevums bez vispārēja risinājuma

Mūsdienu infrastruktūra: problēmas un perspektīvas
Foto Manuels Geisingers no Pexels

Pieņemsim, ka mums ir jauns uzņēmums vai uzņēmums, kurā daļa infrastruktūras ir izbūvēta vecajā veidā. Tā veido infrastruktūras attīstības plānu gadiem. Kā tiek pieņemts lēmums, būvēt infrastruktūru uz konteineriem un Kuber vai nē?

Uzņēmumi, kas cīnās par nanosekundēm, tiek izslēgti no diskusijas. Veselīgs konservatīvisms atmaksājas uzticamības ziņā, taču joprojām ir uzņēmumi, kuriem būtu jāapsver jaunas pieejas.

Ivans: ā€œEs noteikti tagad dibinātu uzņēmumu mākoņpakalpojumā, jo tas ir ātrāks,ā€ lai gan ne vienmēr lētāk. AttÄ«stoties riska kapitālismam, startup uzņēmumiem nav lielu problēmu ar naudu, un galvenais uzdevums ir iekarot tirgu.

Ivans uzskata, ka paÅ”reizējās infrastruktÅ«ras attÄ«stÄ«ba ir atlases kritērijs. Ja agrāk bija nopietns ieguldÄ«jums, un tas darbojas, tad nav jēgas to darÄ«t no jauna. Ja infrastruktÅ«ra nav attÄ«stÄ«ta un ir problēmas ar rÄ«kiem, droŔību un uzraudzÄ«bu, tad ir jēga skatÄ«ties uz izkliedētu infrastruktÅ«ru.

Nodoklis bÅ«s jāmaksā jebkurā gadÄ«jumā, un Ivans maksātu to, kas ļāva turpmāk maksāt mazāk. "Jo vienkārÅ”i pateicoties tam, ka braucu vilcienā, kurā brauc citi, es braukÅ”u daudz tālāk nekā tad, ja sēdos citā vilcienā, kurā man paÅ”am jālej degviela."saka Ivans. Kad uzņēmums ir jauns un latentuma prasÄ«bas ir desmitiem milisekundes, tad Ivans skatÄ«tos uz ā€œoperatoriemā€, kuros mÅ«sdienās ā€œietÄ«tasā€ klasiskās datu bāzes. Tie rada replikācijas ķēdi, kas pati pārslēdzas kļūmjpārlēces gadÄ«jumā utt.

Mazam uzņēmumam ar pāris serveriem Kubera nav jēgas,ā€ saka Andrejs. Bet, ja tas plāno izaugt lÄ«dz simtiem vai vairāk serveru, tam ir nepiecieÅ”ama automatizācija un resursu pārvaldÄ«bas sistēma. 90% gadÄ«jumu ir izmaksu vērti. Turklāt neatkarÄ«gi no slodzes un resursu lÄ«meņa. Ikvienam, sākot no jaunizveidotiem uzņēmumiem lÄ«dz lieliem uzņēmumiem ar miljonu auditoriju, ir lietderÄ«gi pakāpeniski pievērsties konteineru orÄ·estrÄ“Å”anas produktiem. "Jā, tā patieŔām ir nākotne," pārliecināts Andrejs.

Deniss ieskicēja divus galvenos kritērijus - mērogojamÄ«ba un darbÄ«bas stabilitāte. ViņŔ izvēlēsies uzdevumam vispiemērotākos rÄ«kus. ā€œTas varētu bÅ«t noname, kas salikts uz ceļiem, un uz tā ir Nutanix Community Edition. Å Ä« varētu bÅ«t otrā rinda lietojumprogrammas formā Kuber ar datubāzi aizmugursistēmā, kas ir replicēta un kurā ir norādÄ«ti RTO un RPO parametri" (atkopÅ”anas laika/punkta mērÄ·i - apm.).

Jevgeņijs identificēja iespējamu problēmu ar personālu. Å obrÄ«d tirgÅ« nav daudz augsti kvalificētu speciālistu, kas izprastu ā€œiekÅ”asā€. PatieŔām, ja izvēlētā tehnoloÄ£ija ir veca, tad ir grÅ«ti pieņemt darbā nevienu citu, izņemot pusmūža cilvēkus, kuri ir garlaicÄ«gi un noguruÅ”i no dzÄ«ves. Lai gan citi dalÄ«bnieki uzskata, ka tas ir personāla apmācÄ«bas jautājums.
Ja uzdodam izvēles jautājumu: atvērt nelielu uzņēmumu Publiskajā mākonÄ« ar datu bāzēm Amazon RDS vai ā€œuz vietasā€ ar datu bāzēm Kubernetes, tad, neskatoties uz dažiem trÅ«kumiem, Amazon RDS kļuva par dalÄ«bnieku izvēli.

Tā kā lielākā daļa tikÅ”anās klausÄ«tāju nav no ā€œasiņaināā€ uzņēmuma, tad IzplatÄ«ti risinājumi ir tas, uz ko mums jātiecas. Datu uzglabāŔanas sistēmām jābÅ«t izplatÄ«tām, uzticamām un jārada latentums, ko mēra milisekundēs, ne vairāk kā desmitos.", Andrejs rezumēja.

Kubernetes lietojuma novērtÄ“Å”ana

KlausÄ«tājs Antons Žbankovs Kubernetes apoloģētiem uzdeva lamatas jautājumu: kā jÅ«s atlasÄ«jāt un veicat priekÅ”izpēti? Kāpēc Kubernetes, kāpēc ne virtuālās maŔīnas, piemēram?

Mūsdienu infrastruktūra: problēmas un perspektīvas
Foto Tatjana Eremina vietnē Unsplash

Dmitrijs un Ivans uz to atbildēja. Abos gadÄ«jumos izmēģinājumu un kļūdu ceļā tika pieņemta virkne lēmumu, kā rezultātā abi dalÄ«bnieki ieradās Kubernetes. Tagad uzņēmumi sāk patstāvÄ«gi izstrādāt programmatÅ«ru, kuru ir jēga pārsÅ«tÄ«t uz Kuber. Mēs nerunājam par klasiskām treÅ”o puÅ”u sistēmām, piemēram, 1C. Kubernetes palÄ«dz, ja izstrādātājiem ir ātri jāizlaiž laidieni, izmantojot nepārtrauktu nepārtrauktu uzlaboÅ”anu.

Andreja komanda mēģināja izveidot mērogojamu klasteru, pamatojoties uz virtuālajām maŔīnām. Mezgli krita kā domino kauliņi, kas dažkārt noveda pie kopas sabrukÅ”anas. "Teorētiski jÅ«s varat to pabeigt un atbalstÄ«t ar rokām, bet tas ir nogurdinoÅ”i. Un, ja tirgÅ« ir kāds risinājums, kas ļauj strādāt ārpus kastes, mēs esam priecÄ«gi to izmantot. Un rezultātā mēs mainÄ«jāmies,ā€ stāsta Andrejs.

Šādai analīzei un aprēķiniem ir standarti, taču neviens nevar pateikt, cik precīzi tie ir reālai aparatūrai, kas darbojas. Aprēķiniem ir svarīgi arī izprast katru rīku un ekosistēmu, taču tas nav iespējams.

Kas mūs sagaida

Mūsdienu infrastruktūra: problēmas un perspektīvas
Foto Drū Bīmers uz Unsplash

AttÄ«stoties tehnoloÄ£ijai, parādās arvien vairāk atŔķirÄ«gu gabalu, un tad notiek fāzes pāreja, parādās pārdevējs, kurÅ” ir nogalinājis pietiekami daudz mÄ«klas, lai viss apvienotos vienā rÄ«kā.

Vai jÅ«s domājat, ka pienāks laiks, kad Linux pasaulei bÅ«s tāds rÄ«ks kā Ubuntu? Iespējams, ka viens konteinerizācijas un orÄ·estrÄ“Å”anas rÄ«ks ietvers Kuber. Tas atvieglos uz vietas esoÅ”o mākoņu izveidi.

Atbildi sniedza Ivans: "Google tagad veido Anthos ā€” Å”is ir viņu komplektētais piedāvājums, kas izvieto mākoni un ietver Kuber, Service Mesh, uzraudzÄ«bu ā€” visu aparatÅ«ru, kas nepiecieÅ”ama lokālajiem mikropakalpojumiem." Mēs esam gandrÄ«z nākotnē."

Deniss pieminēja arÄ« Nutanix un VMWare ar vRealize Suite produktu, kas var tikt galā ar lÄ«dzÄ«gu uzdevumu bez konteineru ievietoÅ”anas.

Dmitrijs dalÄ«jās savās domās, ka ā€œsāpjuā€ samazināŔana un nodokļu samazināŔana ir divas jomas, kurās varam sagaidÄ«t uzlabojumus.

Apkopojot diskusiju, mēs izceļam Ŕādas mÅ«sdienu infrastruktÅ«ras problēmas:

  • TrÄ«s dalÄ«bnieki nekavējoties identificēja problēmu ar statusful.
  • Dažādas droŔības atbalsta problēmas, tostarp iespēja, ka Docker beigsies ar vairākām Python versijām, lietojumprogrammu serveriem un komponentiem.
    PārtēriņŔ, ko labāk apspriest atseviŔķā sanāksmē.
    MācÄ«Å”anās izaicinājums, jo orÄ·estrÄ“Å”ana ir sarežģīta ekosistēma.
    Nozarē izplatÄ«ta problēma ir instrumentu nepareiza izmantoÅ”ana.

    Pārējie secinājumi ir jÅ«su ziņā. Joprojām ir sajÅ«ta, ka Docker+Kubernetes kombinācijai nav viegli kļūt par sistēmas ā€œcentrāloā€ daļu. Piemēram, operētājsistēmas vispirms tiek instalētas aparatÅ«rā, ko nevar teikt par konteineriem un orÄ·estrÄ“Å”anu. Iespējams, nākotnē operētājsistēmas un konteineri apvienosies ar mākoņa pārvaldÄ«bas programmatÅ«ru.

    Mūsdienu infrastruktūra: problēmas un perspektīvas
    Foto Gabriela Santosa fotogrāfija no Pexels

    Vēlos izmantot izdevību, lai pasveicinātu savu mammu un atgādinātu, ka mums ir Facebook grupa "Lielu IT projektu vadība un attīstība", kanāls @feedmeto ar interesantām publikācijām no dažādiem tehnoloģiju emuāriem. Un mans kanāls @rybakalexey, kur es runāju par attīstības vadību produktu uzņēmumos.

Avots: www.habr.com

Pievieno komentāru