Nə isə, tarixən İT sənayesi hər hansı səbəbdən iki şərti düşərgəyə bölünür: “lehinə” olanlar və “əleyhinə” olanlar. Üstəlik, mübahisələrin mövzusu tamamilə özbaşına ola bilər. Hansı əməliyyat sistemi daha yaxşıdır: Win və ya Linux? Android və ya iOS smartfonunda? Hər şeyi buludlarda saxlamalı və ya soyuq RAID anbarına qoymalı və vintləri seyfə qoymalısınız? PHP adamlarının proqramçı adlandırılmaq hüququ varmı? Bu mübahisələr bəzən yalnız ekzistensial xarakter daşıyır və idman maraqlarından başqa heç bir əsası yoxdur.
Elə oldu ki, konteynerlərin və bütün bu sevimli mətbəxin docker və şərti k8-lərin meydana çıxması ilə arxa planın müxtəlif sahələrində yeni imkanlardan istifadənin “lehinə” və “əleyhinə” mübahisələr başladı. (Qabaqcadan qeyd edək ki, Kubernetes bu müzakirədə ən çox orkestr kimi göstərilsə də, bu xüsusi alətin seçilməsi əsas əhəmiyyət kəsb etmir. Bunun əvəzinə sizə ən əlverişli və tanış görünən hər hansı digərini əvəz edə bilərsiniz. .)
Və görünür, bu, eyni sikkənin iki tərəfi arasında sadə bir mübahisə olardı. Ortada adekvat insanların mövcud olduğu Win və Linux arasındakı əbədi qarşıdurma qədər mənasız və amansız. Ancaq konteynerləşdirmə vəziyyətində hər şey o qədər də sadə deyil. Adətən bu cür mübahisələrdə sağ tərəf yoxdur, lakin verilənlər bazasını saxlamaq üçün konteynerlərdən “istifadə” və ya “istifadə etməmək” vəziyyətində hər şey alt-üst olur. Çünki müəyyən mənada bu yanaşmanın tərəfdarları da, əleyhdarları da haqlıdır.
Parlaq tərəf
İşıq tərəfinin arqumentini qısaca bir cümlə ilə təsvir etmək olar: “Salam, 2k19 pəncərədən kənardadır!” Bu, əlbəttə ki, populizm kimi səslənir, amma vəziyyəti ətraflı araşdırsanız, bunun öz üstünlükləri var. İndi onları sıralayaq.
Tutaq ki, sizin böyük bir veb layihəniz var. O, ilkin olaraq mikroservis yanaşması əsasında qurula bilərdi və ya nə vaxtsa ona təkamül yolu ilə gəlib - bu, əslində çox da vacib deyil. Siz layihəmizi ayrı-ayrı mikroservislərə səpələdiniz, orkestrləşdirmə, yük balansını və miqyasını qurdunuz. İndi, təmiz bir vicdanla, düşmüş serverləri qaldırmaq əvəzinə, habra effektləri zamanı hamakda bir mojito qurtumlayırsınız. Ancaq bütün hərəkətlərdə ardıcıl olmalısınız. Çox vaxt yalnız proqramın özü-kod konteynerləşdirilir. Koddan başqa nələrimiz var?
Doğrudur, data. İstənilən layihənin ürəyi onun məlumatlarıdır: bu ya tipik DBMS ola bilər - MySQL, Postgre, MongoDB, ya da axtarış üçün istifadə olunan yaddaş (ElasticSearch), keşləmə üçün açar-dəyər yaddaşı - məsələn, redis və s. Hal-hazırda biz deyilik. zəif yazılmış sorğular səbəbindən verilənlər bazası qəzaya uğradıqda əyri arxa uçun tətbiqi variantlarından danışacağıq və bunun əvəzinə müştəri yükü altında bu verilənlər bazasının nasazlıqlara dözümlülüyünün təmin edilməsindən danışacağıq. Axı, biz tətbiqimizi konteynerləşdirdikdə və istənilən sayda daxil olan sorğuları emal etmək üçün sərbəst şəkildə miqyasına icazə verdikdə, bu, təbii olaraq verilənlər bazasına yükü artırır.
Əslində, verilənlər bazasına daxil olmaq üçün kanal və onun işlədiyi server gözəl konteynerləşdirilmiş backendimizdə iynənin gözünə çevrilir. Eyni zamanda, konteynerlərin virtuallaşdırılmasının əsas motivi strukturun hərəkətliliyi və çevikliyidir ki, bu da bizə mövcud olan bütün infrastruktur üzrə pik yüklərin paylanmasını mümkün qədər səmərəli təşkil etməyə imkan verir. Yəni, sistemin bütün mövcud elementlərini klaster üzrə konteynerləşdirib yaymasaq, çox ciddi səhv etmiş olarıq.
Yalnız proqramın özünü deyil, həm də məlumatların saxlanmasına cavabdeh olan xidmətlərin qruplaşdırılması daha məntiqlidir. Müstəqil işləyən və k8-lərdə yükü öz aralarında bölüşdürən veb serverləri qruplaşdırmaq və yerləşdirməklə biz artıq verilənlərin sinxronizasiyası problemini həll etmiş oluruq - bəzi media və ya blog platformasını nümunə götürsək, yazılara eyni şərhlər. İstənilən halda, verilənlər bazasının Xarici Xidmət kimi çoxluqdaxili, hətta virtual təqdimatına sahibik. Sual ondan ibarətdir ki, verilənlər bazası özü hələ qruplaşdırılmayıb - kubda yerləşdirilən veb serverlər ayrıca fırlanan statik döyüş verilənlər bazamızdan dəyişikliklər haqqında məlumat alırlar.
Bir tutma hiss edirsiniz? Biz k8s və ya Swarm-dan yükü paylamaq və əsas veb serverin qəzaya uğramasının qarşısını almaq üçün istifadə edirik, lakin bunu verilənlər bazası üçün etmirik. Lakin verilənlər bazası qəzaya uğrayarsa, onda bizim bütün klaster infrastrukturumuzun heç bir mənası yoxdur - verilənlər bazasına giriş xətası qaytaran boş veb səhifələrin nə faydası var?
Buna görə də adətən olduğu kimi yalnız veb serverləri deyil, həm də verilənlər bazası infrastrukturunu klaster etmək lazımdır. Yalnız bu şəkildə bir komandada tam işləyən, eyni zamanda bir-birindən müstəqil bir struktur təmin edə bilərik. Üstəlik, backendimizin yarısı yük altında “yıxılsa” belə, qalanları sağ qalacaq və klaster daxilində verilənlər bazalarının bir-biri ilə sinxronizasiya sistemi və yeni klasterləri sonsuz şəkildə miqyaslaşdırmaq və yerləşdirmək imkanı tələb olunan tutuma tez çatmağa kömək edəcək. - məlumat mərkəzində rəflər olsaydı.
Bundan əlavə, klasterlərdə paylanmış verilənlər bazası modeli sizə məhz bu verilənlər bazasını lazım olan yerə aparmağa imkan verir; Qlobal bir xidmətdən danışırıqsa, o zaman San-Fransisko ərazisində bir yerdə veb klaster fırlatmaq və eyni zamanda Moskva bölgəsindəki verilənlər bazasına daxil olarkən və geriyə paketlər göndərmək tamamilə məntiqsizdir.
Həmçinin verilənlər bazasının konteynerləşdirilməsi sistemin bütün elementlərini eyni abstraksiya səviyyəsində qurmağa imkan verir. Bu da öz növbəsində administratorların fəal iştirakı olmadan məhz bu sistemi birbaşa koddan, tərtibatçılar tərəfindən idarə etməyə imkan verir. Tərtibatçılar yeni alt layihə üçün ayrıca DBMS lazım olduğunu düşünürdülər - asan! yaml faylı yazdı, onu klasterə yüklədiniz və işiniz bitdi.
Və əlbəttə ki, daxili əməliyyat çox sadələşdirilmişdir. Mənə deyin, komandanın yeni üzvü iş üçün əllərini döyüş bazasına qoyanda neçə dəfə gözlərinizi yummusunuz? Sizdə olan və hazırda fırlanan yeganə hansıdır? Əlbəttə ki, biz hamımız burada böyüklərik və haradasa təzə ehtiyat nüsxəmiz var və daha da uzaqda - nənənin xiyarları və köhnə xizəkləri olan rəfin arxasında - başqa bir ehtiyat, bəlkə də hətta soyuducu anbarda, çünki ofisiniz artıq bir dəfə yanmışdı. Bununla belə, döyüş infrastrukturuna və əlbəttə ki, döyüş məlumat bazasına çıxışı olan yeni bir komanda üzvünün hər təqdimatı ətrafdakı hər kəs üçün validol kovasıdır. Yaxşı, onu kim tanıyır, yeni başlayan, bəlkə əli çarpazdır? Dəhşətdir, razılaşarsınız.
Konteynerləşdirmə və əslində, layihənizin verilənlər bazasının paylanmış fiziki topologiyası belə doğrulama anlarının qarşısını almağa kömək edir. Yeni başlayana etibar etmirsiniz? TAMAM! Gəlin ona işləmək və verilənlər bazasını digər klasterlərdən ayırmaq üçün öz klasterini verək - sinxronizasiya yalnız əl ilə təkan və iki düymənin sinxron fırlanması (biri komanda rəhbəri, digəri admin üçün). Və hamı xoşbəxtdir.
İndi verilənlər bazası qruplaşmasının əleyhdarlarına çevrilməyin vaxtıdır.
Qaranlıq tərəf
Verilənlər bazasını konteynerləşdirməyə və onu bir mərkəzi serverdə işlətməyə niyə dəyməz olduğunu mübahisə edərək, biz pravoslavlıq ritorikasına və “babalar verilənlər bazalarını aparat üzərində işlədiblər, biz də edəcəyik!” kimi ifadələrə boyun əyməyəcəyik. Bunun əvəzinə, konteynerləşdirmənin həqiqətən maddi dividendlər ödəyəcəyi bir vəziyyət yaratmağa çalışaq.
Razılaşın, həqiqətən bir konteynerdə bazaya ehtiyacı olan layihələri ən yaxşı freze maşını operatoru deyil, bir əlin barmağı ilə saya bilər. Əksər hallarda, hətta k8s və ya Docker Swarm-dan istifadə etmək lazımsızdır - tez-tez bu vasitələrə texnologiyaların ümumi şırıngası və cinslərin simasında "qüdrətlilərin" hər şeyi itələmək üçün münasibəti səbəbindən istifadə olunur. buludlar və konteynerlər. Yaxşı, çünki indi dəbdədir və hamı bunu edir.
İşlərin ən azı yarısında bir layihədə Kubernetis və ya sadəcə Docker istifadə etmək lazımsızdır. Məsələ ondadır ki, müştərinin infrastrukturunu saxlamaq üçün işə götürülən bütün komandalar və ya autsorsing şirkətləri bundan xəbərdar deyillər. Konteynerlər qoyulduqda daha pisdir, çünki müştəriyə müəyyən miqdarda sikkə başa gəlir.
Ümumiyyətlə, docker/cube mafiyasının bu infrastruktur məsələlərini autsorsing edən müştəriləri axmaqcasına əzdiyinə dair bir fikir var. Axı, klasterlərlə işləmək üçün bizə bunu bacaran və ümumiyyətlə həyata keçirilən həllin arxitekturasını başa düşən mühəndislər lazımdır. Biz bir dəfə Respublika nəşri ilə işimizi təsvir etmişdik - orada müştəri komandasına Kubernetisin reallıqlarında işləmək üçün öyrətdik və hamı razı qaldı. Və layiqli idi. Çox vaxt k8s "tətbiqçiləri" müştərinin infrastrukturunu girov götürürlər - çünki indi orada hər şeyin necə işlədiyini yalnız onlar başa düşürlər; müştəri tərəfində heç bir mütəxəssis yoxdur.
İndi təsəvvür edin ki, bu yolla biz təkcə veb-server hissəsini deyil, həm də verilənlər bazasına texniki xidmət göstəririk. Dedik ki, BD ürəkdir və ürəyin itirilməsi hər bir canlı orqanizm üçün ölümcüldür. Bir sözlə, perspektivlər yaxşı deyil. Beləliklə, şırınga Kubernetis əvəzinə, bir çox layihə AWS üçün normal tariflə narahat olmamalıdır ki, bu da onların saytında/layihəsindəki yüklə bağlı bütün problemləri həll edəcək. Lakin AWS artıq dəbdə deyil və nümayişlər puldan daha dəyərlidir - təəssüf ki, İT mühitində də.
TAMAM. Ola bilsin ki, layihə həqiqətən klasterləşdirməyə ehtiyac duyur, lakin vətəndaşlığı olmayan proqramlarla hər şey aydındırsa, onda biz klaster verilənlər bazası üçün layiqli şəbəkə bağlantısını necə təşkil edə bilərik?
Əgər biz k8s-ə keçidin nədən ibarət olduğu problemsiz mühəndislik həllindən danışırıqsa, onda bizim əsas baş ağrımız çoxlu verilənlər bazasında məlumatların təkrarlanmasıdır. Bəzi DBMS-lər əvvəlcə fərdi nümunələri arasında məlumatların paylanmasına kifayət qədər sadiqdirlər. Bir çoxları o qədər də xoş qarşılanmır. Və çox vaxt layihəmiz üçün DBMS seçimində əsas arqument minimal resurs və mühəndislik xərcləri ilə təkrarlamaq qabiliyyəti deyil. Xüsusilə layihə əvvəlcə mikroservis kimi planlaşdırılmayıbsa, sadəcə olaraq bu istiqamətdə inkişaf edibsə.
Düşünürük ki, şəbəkə sürücülərinin sürəti haqqında danışmağa ehtiyac yoxdur - onlar yavaşdır. Bunlar. Bir şey olarsa, daha çox, məsələn, prosessor gücü və ya pulsuz RAM olan bir yerdə DBMS nümunəsini yenidən başlatmaq üçün hələ də real imkanımız yoxdur. Biz çox tez virtuallaşdırılmış disk alt sisteminin performansına daxil olacağıq. Müvafiq olaraq, DBMS yaxınlıqda yerləşən öz şəxsi maşın dəstinə yapışdırılmalıdır. Və ya ehtimal olunan ehtiyatlar üçün kifayət qədər sürətli məlumat sinxronizasiyasını ayrı-ayrılıqda soyutmaq lazımdır.
Virtual fayl sistemləri mövzusunun davamı: Docker Volumes, təəssüf ki, problemsiz deyil. Ümumiyyətlə, uzunmüddətli etibarlı məlumatların saxlanması kimi bir məsələdə texniki cəhətdən ən sadə sxemlərlə kifayətlənmək istərdim. Konteynerin FS-dən ana hostun FS-ə yeni bir abstraksiya qatının əlavə edilməsi özlüyündə bir riskdir. Lakin konteynerləşdirməyə dəstək sisteminin işləməsi də bu təbəqələr arasında məlumatların ötürülməsində çətinliklərlə qarşılaşdıqda, bu, həqiqətən bir fəlakətdir. Hazırda mütərəqqi bəşəriyyətə məlum olan problemlərin əksəriyyətinin kökü kəsilmiş kimi görünür. Ancaq başa düşürsən, mexanizm nə qədər mürəkkəb olsa, bir o qədər asan qırılır.
Bütün bu "sərgüzəştlər" işığında verilənlər bazasını bir yerdə saxlamaq daha sərfəlidir və daha asandır və tətbiqi konteynerə yerləşdirmək lazım olsa belə, onun öz-özünə işləməsinə icazə verin və paylama şlüzü ilə eyni vaxtda əlaqə alsın. yalnız bir dəfə və bir yerdə oxunacaq və yazılacaq verilənlər bazası. Bu yanaşma səhvlər və sinxronizasiya ehtimalını minimuma endirir.
Nəyə aparırıq? Üstəlik, verilənlər bazası konteynerləşdirilməsi real ehtiyac olduğu yerlərdə uyğundur. Tam proqram verilənlər bazasını doldura və sanki iki onlarla mikroservisiniz varmış kimi fırlada bilməzsiniz - bu belə işləmir. Və bu aydın başa düşülməlidir.
Çıxış yerinə
Əgər “bazanın virtuallaşdırılması və ya edilməməsi” aydın bir nəticə gözləyirsinizsə, biz sizi məyus edəcəyik: burada olmayacaq. Çünki hər hansı infrastruktur həllini yaradanda dəb və tərəqqi yox, ilk növbədə sağlam düşüncə rəhbər tutulmalıdır.
Kubernetis ilə gələn prinsiplər və alətlərin mükəmməl uyğunlaşdığı layihələr var və bu cür layihələrdə ən azı arxa hissədə sülh var. Və elə layihələr var ki, konteynerləşdirməyə yox, normal server infrastrukturuna ehtiyacı var, çünki onlar mikroservis klaster modelinə köklü şəkildə miqyasını dəyişə bilmirlər, çünki onlar düşəcəklər.
Mənbə: www.habr.com