Sa anumang paraan, ayon sa kasaysayan, ang industriya ng IT ay nahahati sa dalawang kondisyon na kampo para sa anumang kadahilanan: ang mga "para sa" at ang mga "laban". Bukod dito, ang paksa ng mga hindi pagkakaunawaan ay maaaring ganap na arbitraryo. Aling OS ang mas mahusay: Manalo o Linux? Sa isang Android o iOS smartphone? Dapat mo bang itabi ang lahat sa cloud o ilagay ito sa malamig na RAID storage at ilagay ang mga turnilyo sa isang safe? May karapatan ba ang mga taong PHP na tawaging programmer? Ang mga pagtatalo na ito ay, kung minsan, ay eksklusibong eksistensyal sa kalikasan at walang batayan maliban sa interes sa palakasan.
Nagkataon lang na sa pagdating ng mga lalagyan at lahat ng minamahal na lutuing ito na may docker at conditional k8s, nagsimula ang mga debate "para sa" at "laban" sa paggamit ng mga bagong kakayahan sa iba't ibang lugar ng backend. (Magpareserba tayo nang maaga na bagama't madalas na ipahiwatig ang Kubernetes bilang isang orkestra sa talakayang ito, ang pagpili sa partikular na tool na ito ay hindi napakahalaga. .)
At, tila, ito ay isang simpleng pagtatalo sa pagitan ng dalawang panig ng parehong barya. Kasing walang saysay at walang awa gaya ng walang hanggang paghaharap sa pagitan ng Win vs Linux, kung saan mayroong sapat na mga tao sa isang lugar sa gitna. Ngunit sa kaso ng containerization, hindi lahat ay napakasimple. Karaniwan sa gayong mga pagtatalo ay walang kanang bahagi, ngunit sa kaso ng "gamitin" o "hindi gamitin" na mga lalagyan para sa pag-iimbak ng mga database, ang lahat ay bumabaligtad. Dahil sa isang tiyak na kahulugan, ang parehong mga tagasuporta at mga kalaban ng diskarte na ito ay tama.
Maliwanag na bahagi
Ang argumento ng The Light Side ay madaling ilarawan sa isang parirala: "Kumusta, nasa labas ng bintana ang 2k19!" Ito ay parang populismo, siyempre, ngunit kung susuriin mo ang sitwasyon nang detalyado, mayroon itong mga pakinabang. Ayusin natin sila ngayon.
Sabihin nating mayroon kang malaking proyekto sa web. Ito ay maaaring una na binuo batay sa isang microservice na diskarte, o sa ilang mga punto ay dumating ito sa pamamagitan ng isang evolutionary path - ito ay hindi masyadong mahalaga, sa katunayan. Ikinalat mo ang aming proyekto sa magkakahiwalay na microservice, nag-set up ng orkestrasyon, pag-load ng pagbabalanse, at pag-scale. At ngayon, nang may malinis na budhi, humihigop ka ng mojito sa duyan sa panahon ng mga epekto ng habra sa halip na itaas ang mga bumagsak na server. Pero sa lahat ng kilos dapat consistent ka. Kadalasan, ang application lang mismoβang codeβang nakalagay sa container. Ano pa ang mayroon tayo bukod sa code?
Tama, data. Ang puso ng anumang proyekto ay ang data nito: ito ay maaaring isang tipikal na DBMS - MySQL, Postgre, MongoDB, o storage na ginagamit para sa paghahanap (ElasticSearch), key-value storage para sa caching - halimbawa, redis, atbp. Sa kasalukuyan, hindi kami pag-uusapan natin ang tungkol sa mga baluktot na opsyon sa pagpapatupad ng backend kapag nag-crash ang database dahil sa hindi magandang nakasulat na mga query, at sa halip ay pag-uusapan natin ang tungkol sa pagtitiyak ng fault tolerance ng mismong database na ito sa ilalim ng load ng kliyente. Pagkatapos ng lahat, kapag na-container namin ang aming aplikasyon at pinahintulutan itong malayang i-scale upang maproseso ang anumang bilang ng mga papasok na kahilingan, natural nitong pinapataas ang pag-load sa database.
Sa katunayan, ang channel para sa pag-access sa database at ang server kung saan ito tumatakbo ay naging mata ng karayom ββsa aming magandang containerized na backend. Kasabay nito, ang pangunahing motibo ng container virtualization ay ang mobility at flexibility ng structure, na nagbibigay-daan sa amin na ayusin ang pamamahagi ng mga peak load sa buong imprastraktura na available sa amin nang mahusay hangga't maaari. Ibig sabihin, kung hindi namin ilalagay at ilalabas ang lahat ng umiiral na elemento ng system sa buong cluster, nakakagawa kami ng isang napakaseryosong pagkakamali.
Ito ay mas lohikal na kumpol hindi lamang ang application mismo, kundi pati na rin ang mga serbisyo na responsable para sa pag-iimbak ng data. Sa pamamagitan ng pag-cluster at pag-deploy ng mga web server na gumagana nang nakapag-iisa at namamahagi ng load sa kanilang mga sarili sa k8s, nilulutas na namin ang problema sa pag-synchronize ng data - ang parehong mga komento sa mga post, kung kukuha kami ng ilang platform ng media o blog bilang isang halimbawa. Sa anumang kaso, mayroon kaming intra-cluster, kahit virtual, na representasyon ng database bilang ExternalService. Ang tanong ay hindi pa naka-cluster ang database mismo - ang mga web server na naka-deploy sa cube ay kumukuha ng impormasyon tungkol sa mga pagbabago mula sa aming static combat database, na hiwalay na umiikot.
Nakaramdam ka ba ng catch? Gumagamit kami ng k8s o Swarm upang ipamahagi ang load at maiwasan ang pag-crash sa pangunahing web server, ngunit hindi namin ito ginagawa para sa database. Ngunit kung ang database ay nag-crash, kung gayon ang aming buong clustered na imprastraktura ay walang kahulugan - ano ang silbi ng mga walang laman na web page na nagbabalik ng error sa pag-access sa database?
Iyon ang dahilan kung bakit kinakailangan na i-cluster hindi lamang ang mga web server, gaya ng karaniwang ginagawa, kundi pati na rin ang imprastraktura ng database. Sa ganitong paraan lamang natin masisiguro ang isang istraktura na ganap na gumagana sa isang koponan, ngunit sa parehong oras ay independyente sa bawat isa. Bukod dito, kahit na ang kalahati ng aming backend ay "mag-collapse" sa ilalim ng pagkarga, ang natitira ay mabubuhay, at ang sistema ng pag-synchronize ng mga database sa isa't isa sa loob ng cluster at ang kakayahang walang katapusang pag-scale at pag-deploy ng mga bagong cluster ay makakatulong na mabilis na maabot ang kinakailangang kapasidad - kung may racks lang sa data center .
Bilang karagdagan, ang modelo ng database na ibinahagi sa mga kumpol ay nagpapahintulot sa iyo na dalhin ang mismong database na ito sa kung saan ito kinakailangan; Kung pinag-uusapan natin ang tungkol sa isang pandaigdigang serbisyo, kung gayon medyo hindi makatwiran na paikutin ang isang web cluster sa isang lugar sa lugar ng San Francisco at sabay na magpadala ng mga packet kapag nag-access ng isang database sa rehiyon ng Moscow at pabalik.
Gayundin, ang containerization ng database ay nagpapahintulot sa iyo na bumuo ng lahat ng mga elemento ng system sa parehong antas ng abstraction. Na, sa turn, ay ginagawang posible na pamahalaan ang mismong sistemang ito nang direkta mula sa code, ng mga developer, nang walang aktibong paglahok ng mga administrator. Naisip ng mga developer na kailangan ng hiwalay na DBMS para sa bagong subproject - madali! nagsulat ng yaml file, na-upload ito sa cluster at tapos ka na.
At siyempre, ang panloob na operasyon ay lubos na pinasimple. Sabihin mo sa akin, ilang beses mo bang ipinikit ang iyong mga mata nang ang isang bagong miyembro ng koponan ay naglagay ng kanyang mga kamay sa database ng labanan para sa trabaho? Alin, sa katunayan, ang tanging mayroon ka at umiikot ngayon? Siyempre, lahat tayo ay may sapat na gulang dito, at sa isang lugar mayroon tayong bagong backup, at mas malayo pa - sa likod ng istante na may mga pipino at lumang skis ng lola - isa pang backup, marahil kahit na sa malamig na imbakan, dahil ang iyong opisina ay nasunog na minsan. Ngunit pareho, ang bawat pagpapakilala ng isang bagong miyembro ng koponan na may access sa imprastraktura ng labanan at, siyempre, sa database ng labanan ay isang balde ng validol para sa lahat sa paligid. Well, sino ang nakakakilala sa kanya, isang baguhan, marahil siya ay naka-cross-handed? Nakakatakot, papayag ka.
Containerization at, sa katunayan, ang ibinahagi na pisikal na topology ng database ng iyong proyekto ay nakakatulong upang maiwasan ang mga naturang sandali ng pagpapatunay. Huwag magtiwala sa isang baguhan? OK! Bigyan natin siya ng sarili niyang cluster para magtrabaho at idiskonekta ang database mula sa iba pang mga cluster - pag-synchronize lang sa pamamagitan ng manual push at synchronous rotation ng dalawang key (isa para sa team lead, ang isa para sa admin). At lahat ay masaya.
At ngayon ay oras na upang maging mga kalaban ng database clustering.
Madilim na bahagi
Sa pagtatalo kung bakit hindi sulit na i-container ang database at patuloy na patakbuhin ito sa isang sentral na server, hindi kami susuko sa retorika ng mga orthodoxies at mga pahayag tulad ng "ang mga lolo ay nagpatakbo ng mga database sa hardware, at gayon din tayo!" Sa halip, subukan nating makabuo ng isang sitwasyon kung saan ang containerization ay talagang magbabayad ng mga nasasalat na dibidendo.
Sumang-ayon, ang mga proyekto na talagang nangangailangan ng base sa isang lalagyan ay mabibilang sa isang kamay ng hindi ang pinakamahusay na operator ng milling machine. Para sa karamihan, kahit na ang paggamit ng k8s o Docker Swarm mismo ay kalabisan - kadalasan ang mga tool na ito ay ginagamit dahil sa pangkalahatang hype ng mga teknolohiya at ang mga saloobin ng "makapangyarihan" sa tao ng mga kasarian upang itulak ang lahat sa ulap at lalagyan. Well, dahil uso na ngayon at ginagawa na ng lahat.
Sa hindi bababa sa kalahati ng mga kaso, ang paggamit ng Kubernetis o Docker lamang sa isang proyekto ay kalabisan. Ang isyu ay hindi lahat ng mga koponan o outsourcing na kumpanya na tinanggap upang mapanatili ang imprastraktura ng kliyente ay alam ito. Mas malala kapag ang mga lalagyan ay ipinataw, dahil nagkakahalaga ito ng isang tiyak na halaga ng mga barya sa kliyente.
Sa pangkalahatan, may opinyon na ang docker/cube mafia ay katangahang dinudurog ang mga kliyenteng nag-outsource sa mga isyung ito sa imprastraktura. Pagkatapos ng lahat, upang gumana sa mga kumpol, kailangan namin ng mga inhinyero na may kakayahang ito at sa pangkalahatan ay nauunawaan ang arkitektura ng ipinatupad na solusyon. Minsan na naming inilarawan ang aming kaso sa publikasyon ng Republika - doon namin sinanay ang pangkat ng kliyente na magtrabaho sa mga katotohanan ng Kubernetis, at nasiyahan ang lahat. At ito ay disente. Kadalasan, kinukuha ng mga "implementer" ng k8 ang imprastraktura ng kliyente - dahil ngayon lang naiintindihan nila kung paano gumagana ang lahat doon; walang mga espesyalista sa panig ng kliyente.
Ngayon isipin na sa ganitong paraan kami ay nag-outsource hindi lamang sa bahagi ng web server, kundi pati na rin sa pagpapanatili ng database. Sinabi namin na ang BD ay ang puso, at ang pagkawala ng puso ay nakamamatay para sa anumang buhay na organismo. Sa madaling salita, ang mga prospect ay hindi ang pinakamahusay. Kaya, sa halip na hype Kubernetis, maraming mga proyekto ang hindi dapat mag-abala sa normal na taripa para sa AWS, na lulutasin ang lahat ng mga problema sa pag-load sa kanilang site/proyekto. Ngunit hindi na uso ang AWS, at ang pagpapakitang-tao ay higit pa sa pera - sa kasamaang-palad, sa kapaligiran ng IT din.
OK. Marahil ang proyekto ay talagang nangangailangan ng clustering, ngunit kung ang lahat ay malinaw sa stateless na mga aplikasyon, kung gayon paano natin maaayos ang disenteng koneksyon sa network para sa isang clustered database?
Kung pinag-uusapan natin ang isang tuluy-tuloy na solusyon sa engineering, na kung ano ang paglipat sa k8s, kung gayon ang aming pangunahing sakit sa ulo ay ang pagtitiklop ng data sa isang clustered database. Ang ilang mga DBMS sa una ay medyo tapat sa pamamahagi ng data sa pagitan ng kanilang mga indibidwal na pagkakataon. Marami pang iba ang hindi masyadong malugod. At madalas na ang pangunahing argumento sa pagpili ng DBMS para sa aming proyekto ay hindi ang kakayahang magtiklop na may kaunting gastos sa mapagkukunan at engineering. Lalo na kung ang proyekto ay hindi unang binalak bilang isang microservice, ngunit umunlad lamang sa direksyong ito.
Sa tingin namin ay hindi na kailangang pag-usapan ang bilis ng mga network drive - mabagal ang mga ito. Yung. Wala pa rin kaming tunay na pagkakataon, kung may mangyari, na i-restart ang isang DBMS instance sa isang lugar kung saan may higit pa, halimbawa, processor power o libreng RAM. Mabilis kaming tatakbo sa pagganap ng virtualized disk subsystem. Alinsunod dito, ang DBMS ay dapat na ipinako sa sarili nitong personal na hanay ng mga makina na matatagpuan sa malapit. O kinakailangan na kahit papaano ay hiwalay na magpalamig ng sapat na mabilis na pag-synchronize ng data para sa mga dapat na reserba.
Ang pagpapatuloy ng paksa ng mga virtual file system: Ang Docker Volumes, sa kasamaang-palad, ay hindi walang problema. Sa pangkalahatan, sa bagay na tulad ng pang-matagalang maaasahang pag-iimbak ng data, gusto kong gawin ang mga pinaka-technical na simpleng mga scheme. At ang pagdaragdag ng bagong abstraction layer mula sa FS ng container sa FS ng parent host ay isang panganib mismo. Ngunit kapag ang pagpapatakbo ng containerization support system ay nakakaranas din ng mga kahirapan sa pagpapadala ng data sa pagitan ng mga layer na ito, ito ay talagang isang kalamidad. Sa ngayon, ang karamihan sa mga problemang kilala ng progresibong sangkatauhan ay tila naalis na. Ngunit naiintindihan mo, kung mas kumplikado ang mekanismo, mas madali itong masira.
Sa liwanag ng lahat ng mga "pakikipagsapalaran" na ito, mas kumikita at mas madaling panatilihin ang database sa isang lugar, at kahit na kailangan mong ilagay sa lalagyan ang application, hayaan itong tumakbo nang mag-isa at sa pamamagitan ng gateway ng pamamahagi ay tumanggap ng sabay-sabay na komunikasyon sa database, na babasahin at isusulat nang isang beses lamang at Sa isang lugar. Binabawasan ng diskarteng ito ang posibilidad ng mga error at desynchronization sa pinakamababa.
Ano ang aming pinangungunahan? Dagdag pa rito, angkop ang containerization ng database kung saan may tunay na pangangailangan para dito. Hindi mo maaaring ilagay ang isang full-app na database at paikutin ito na parang mayroon kang dalawang dosenang microservice - hindi ito gagana sa ganoong paraan. At ito ay dapat na malinaw na maunawaan.
Sa halip na output
Kung naghihintay ka para sa isang malinaw na konklusyon "upang i-virtualize ang database o hindi," pagkatapos ay bibiguin ka namin: wala ito dito. Dahil kapag lumilikha ng anumang solusyon sa imprastraktura, ang isa ay dapat na magabayan hindi ng fashion at pag-unlad, ngunit, una sa lahat, sa pamamagitan ng sentido komun.
May mga proyekto kung saan ang mga prinsipyo at tool na kasama ng Kubernetis ay akmang-akma, at sa mga naturang proyekto ay may kapayapaan man lang sa backend area. At may mga proyekto na hindi nangangailangan ng containerization, ngunit isang normal na imprastraktura ng server, dahil sa panimula ay hindi sila makakapag-rescale sa modelo ng microservice cluster, dahil babagsak sila.
Pinagmulan: www.habr.com