Ötən ilin sonunda Rusiyanın PostgreSQL icmasının növbəti canlı yayımı baş tutdu , bu müddət ərzində onun həmtəsisçisi Nikolay Samoxvalov Flant-ın texniki direktoru Dmitri Stolyarov ilə Kubernetes kontekstində bu DBMS haqqında danışdı.
Bu müzakirənin əsas hissəsinin stenoqramını dərc edirik və at Tam video yerləşdirilib:
Verilənlər bazaları və Kubernetes
NS: Bu gün VAKUUM və YOXLAMA NÖQTƏLƏRİ haqqında danışmayacağıq. Kubernetes haqqında danışmaq istəyirik. Bilirəm ki, sizin çoxillik təcrübəniz var. Videolarınıza baxdım, hətta bəzilərinə yenidən baxdım... Gəlin birbaşa mətləbə keçək: niyə ümumiyyətlə K8-lərdə Postgres və ya MySQL?
DS: Bu sualın qəti cavabı yoxdur və ola da bilməz. Amma ümumilikdə bu, sadəlik və rahatlıqdır... potensialdır. Hər kəs idarə olunan xidmətlər istəyir.
NS: Necə , yalnız evdə?
DS: Bəli: RDS kimi, hər yerdə.
NS: "Hər yerdə" yaxşı bir nöqtədir. Böyük şirkətlərdə hər şey müxtəlif yerlərdə yerləşir. Nə üçün böyük bir şirkətdirsə, hazır həlli götürmürsən? Məsələn, Nutanix-in öz inkişafları var, digər şirkətlərdə (VMware...) eyni “RDS, yalnız evdə” var.
DS: Ancaq biz yalnız müəyyən şərtlər altında işləyəcək ayrıca bir tətbiqdən danışırıq. Əgər biz Kubernetes-dən danışırıqsa, onda çox sayda infrastruktur var (bu, K8-lərdə ola bilər). Əslində bu, bulud üçün API üçün standartdır...
NS: Bu da pulsuzdur!
DS: O qədər də vacib deyil. Sərbəstlik bazarın çox da böyük olmayan seqmenti üçün vacibdir. Başqa bir şey vacibdir... Yəqin ki, hesabatı xatırlayırsınız”"?
NS: Bəli.
DS: Mən başa düşdüm ki, çox birmənalı qarşılanmayıb. Bəzi insanlar mənim dediyimi düşünürdülər: "Uşaqlar, gəlin bütün verilənlər bazalarını Kubernetesə daxil edək!", bəziləri isə bunların hamısının dəhşətli velosipedlər olduğuna qərar verdi. Amma mən tamam başqa şey demək istədim: “Görün nə baş verir, hansı problemlər var və onları necə həll etmək olar. İndi Kubernetes verilənlər bazalarından istifadə etməliyikmi? İstehsal? Yaxşı, yalnız xoşunuza gəlsə ... müəyyən şeylərlə məşğul olun. Ancaq bir dev üçün deyə bilərəm ki, bunu tövsiyə edirəm. Bir inkişaf etdirici üçün mühitlərin yaradılması/silinməsinin dinamizmi çox vacibdir.”
NS: Dev dedikdə, istehsal olunmayan bütün mühitləri nəzərdə tutursunuz? Səhnələşdirmə, QA…
DS: Əgər biz mükəmməl stendlərdən danışırıqsa, yəqin ki, yox, çünki oradakı tələblər konkretdir. Əgər səhnələşdirmə üçün çox böyük verilənlər bazasına ehtiyac duyulan xüsusi hallardan danışırıqsa, yəqin ki, yox... Əgər bu, statik, uzunömürlü mühitdirsə, onda verilənlər bazasının K8-lərdə yerləşməsinin nə faydası var?
NS: Yoxdur. Bəs biz statik mühitləri harada görürük? Statik mühit sabah köhnələcək.
DS: Səhnələşdirmə statik ola bilər. Müştərilərimiz var...
NS: Bəli, məndə də var. 10 TB məlumat bazanız və 200 GB səhnələşdirməniz varsa, bu böyük problemdir...
DS: Çox gözəl bir işim var! Səhnədə dəyişikliklərin edildiyi bir məhsul bazası var. Və bir düymə var: "istehsalata keçin". Bu dəyişikliklər - deltalar - istehsalda əlavə olunur (görünür, onlar sadəcə API vasitəsilə sinxronlaşdırılıb). Bu çox ekzotik bir seçimdir.
NS: Mən Vadidə RDS-də və ya hətta Herokuda oturan startapları görmüşəm - bunlar 2-3 il əvvəlin hekayələridir - və onlar zibil qutusunu noutbuklarına yükləyirlər. Çünki verilənlər bazası hələ də cəmi 80 GB-dır və noutbukda yer var. Sonra hər kəs üçün əlavə disklər alırlar ki, müxtəlif inkişafları həyata keçirmək üçün 3 verilənlər bazası olsun. Bu da belə olur. Mən də gördüm ki, onlar məhsulu səhnəyə köçürməkdən qorxmurlar - bu, şirkətdən çox asılıdır. Amma çox qorxduqlarını, çox vaxt vaxtlarının və əllərinin çatmadığını gördüm. Ancaq bu mövzuya keçməzdən əvvəl Kubernetes haqqında eşitmək istərdim. Mən düzgün başa düşürəm ki, hələ heç kim istehsalda deyil?
DS: İstehsalda kiçik məlumat bazalarımız var. Söhbət onlarla giqabaytlıq həcmlərdən və replika etmək üçün çox tənbəl olduğumuz qeyri-kritik xidmətlərdən gedir (və belə ehtiyac yoxdur). Və Kubernetes altında normal saxlama olması şərti ilə. Bu verilənlər bazası virtual maşında - şərti olaraq VMware-də, saxlama sisteminin üstündə işləyirdi. Biz onu yerləşdirdik və indi biz onu maşından maşına köçürə bilərik.
NS: Bu ölçüdə, 100 GB-a qədər verilənlər bazası yaxşı disklərdə və yaxşı şəbəkədə bir neçə dəqiqə ərzində yayıla bilər, elə deyilmi? Saniyədə 1 GB sürət artıq ekzotik deyil.
DS: Bəli, xətti əməliyyat üçün bu problem deyil.
NS: Yaxşı, biz sadəcə məhsul haqqında düşünməliyik. İstehsal olmayan mühitlər üçün Kubernetes-i nəzərdən keçiririksə, nə etməliyik? Mən bunu Zalandoda görürəm , Crunchy-də , bəzi başqa variantlar var. Və var - bu, ispaniyalı yaxşı dostumuz Alvarodur: onların etdikləri əslində sadəcə deyil , və bütün paylama (), Postgresin özündən əlavə, onlar da bir ehtiyat nüsxə, Elçi proxy-ni doldurmağa qərar verdilər...
DS: Nə üçün elçi? Xüsusilə Postgres trafikini balanslaşdırmaq?
NS: Bəli. Yəni onlar bunu belə görürlər: Linux paylanması və nüvəsini götürsəniz, adi PostgreSQL nüvədir və onlar buludla uyğunlaşacaq və Kubernetes-də işləyəcək bir paylama etmək istəyirlər. Onlar komponentləri (ehtiyat nüsxələri və s.) birləşdirir və yaxşı işləməsi üçün onları düzəldirlər.
DS: Cox sərin! Əslində bu, öz idarə olunan Postgres yaratmaq üçün proqramdır.
NS: Linux paylamalarında əbədi problemlər var: sürücüləri necə etmək olar ki, bütün avadanlıqlar dəstəklənsin. Və onların Kubernetesdə işləyəcəkləri fikri var. Bilirəm ki, Zalando operatorunda bu yaxınlarda AWS ilə əlaqə gördük və bu, artıq yaxşı deyil. Konkret bir infrastruktura bağlılıq olmamalıdır - onda nə mənası var?
DS: Zalandonun hansı vəziyyətə düşdüyünü dəqiq bilmirəm, amma Kubernetes yaddaşında indi elə qurulub ki, ümumi metoddan istifadə edərək diskin ehtiyat nüsxəsini çıxarmaq mümkün deyil. Bu yaxınlarda standart - son versiyada — biz anlıq görüntüləri mümkün etdik, bəs bu, harada həyata keçirilir? Düzünü desəm, hər şey hələ də o qədər xamdır ki... AWS, GCE, Azure, vSphere üzərində CSI-ni sınayırıq, amma istifadə etməyə başlayan kimi onun hələ hazır olmadığını görə bilərsiniz.
NS: Buna görə bəzən infrastruktura etibar etməli oluruq. Düşünürəm ki, bu hələ erkən mərhələdir - artan ağrılar. Sual: K8-lərdə PgSQL-i sınamaq istəyən yeni başlayanlara nə məsləhət görərdiniz? Hansı operator ola bilər?
DS: Problem ondadır ki, Postgres bizim üçün 3% təşkil edir. Kubernetes-də müxtəlif proqramların çox böyük bir siyahısı var, hər şeyi sadalamayacağam. Məsələn, Elasticsearch. Bir çox operator var: bəziləri fəal şəkildə inkişaf edir, digərləri isə yox. Biz özümüz üçün tələblər hazırlamışıq ki, operatorun nəyə sahib olması lazımdır ki, biz bunu ciddi qəbul edək. Xüsusi olaraq Kubernetes üçün bir operatorda - “Amazon şərtlərində bir şey etmək üçün operatorda” deyil... Əslində, biz kifayət qədər geniş şəkildə (= demək olar ki, bütün müştərilər) bir operatordan istifadə edirik - (tezliklə onun haqqında məqalə dərc edəcəyik).
NS: MySQL üçün də yox? Mən bilirəm ki, Percona... indi MySQL, MongoDB və Postgres üzərində işlədikləri üçün onlar bir növ universal həll yaratmalı olacaqlar: bütün verilənlər bazaları, bütün bulud provayderləri üçün.
DS: MySQL üçün operatorlara baxmağa vaxtımız yox idi. Hazırda əsas diqqətimiz bu deyil. MySQL müstəqil olaraq yaxşı işləyir. Əgər sadəcə verilənlər bazasını işə sala bilirsinizsə, niyə operatordan istifadə etməlisiniz... Siz Postrges ilə Docker konteynerini işə sala bilərsiniz və ya onu sadə şəkildə işə sala bilərsiniz.
NS: Bununla bağlı bir sual da var idi. Operator yoxdur?
DS: Bəli, 100% bizim PostgreSQL operatorsuz işləyir. İndiyə qədər. Prometheus və Redis üçün operatordan fəal istifadə edirik. Elasticsearch üçün operator tapmaq planlarımız var - o, ən çox "yandıran" operatordur, çünki biz onu 100% hallarda Kubernetes-də quraşdırmaq istəyirik. MongoDB-nin də həmişə Kubernetes-də quraşdırılmasını təmin etmək istədiyimiz kimi. Burada müəyyən istəklər görünür - bu hallarda bir şey edilə biləcəyi hissi var. Biz Postgresə də baxmadıq. Təbii ki, biz bilirik ki, müxtəlif variantlar var, amma əslində müstəqilimiz var.
Kubernetes-də sınaq üçün DB
NS: Keçək test mövzusuna. Verilənlər bazasında dəyişiklikləri necə yaymaq olar - DevOps perspektivindən. Mikroservislər, çoxlu verilənlər bazası var, nəsə hər zaman haradasa dəyişir. Normal CI/CD-ni necə təmin etmək olar ki, DBMS baxımından hər şey qaydasında olsun. Sizin yanaşmanız necədir?
DS: Bir cavab ola bilməz. Bir neçə variant var. Birincisi, yaymaq istədiyimiz bazanın ölçüsüdür. Siz özünüz qeyd etdiniz ki, şirkətlər inkişaf və səhnədə istehsal məlumat bazasının surətinə sahib olmaq üçün fərqli münasibət göstərirlər.
NS: Və GDPR şərtlərinə görə, düşünürəm ki, onlar getdikcə daha diqqətli olurlar... Deyə bilərəm ki, Avropada artıq cərimələr tətbiq etməyə başlayıblar.
DS: Ancaq tez-tez istehsaldan bir zibil götürən və onu qarışdıran proqram təminatı yaza bilərsiniz. Məhsul məlumatları əldə edilir (snapshot, dump, binar surəti...), lakin anonimləşdirilir. Bunun əvəzinə nəsil skriptləri ola bilər: bunlar qurğular və ya sadəcə böyük verilənlər bazası yaradan skript ola bilər. Problem ondadır: əsas təsviri yaratmaq üçün nə qədər vaxt lazımdır? Və onu istədiyiniz mühitdə yerləşdirmək nə qədər vaxt aparır?
Biz bir sxemə gəldik: əgər müştərinin sabit məlumat dəsti varsa (verilənlər bazasının minimal versiyası), onda biz onları standart olaraq istifadə edirik. Baxış mühitlərindən danışırıqsa, filial yaratdıqda biz tətbiqin bir nümunəsini yerləşdirdik - orada kiçik bir verilənlər bazası yayırıq. Amma yaxşı çıxdı , biz gündə bir dəfə (gecə) istehsaldan zibil götürdükdə və onun əsasında bu yüklənmiş məlumatlarla PostgreSQL və MySQL ilə Docker konteyneri qurduqda. Bu şəkildən verilənlər bazasını 50 dəfə genişləndirmək lazımdırsa, bu olduqca sadə və tez edilir.
NS: Sadə surət çıxarmaqla?
DS: Məlumat birbaşa Docker təsvirində saxlanılır. Bunlar. 100 GB olsa da, hazır şəkilimiz var. Docker-dəki təbəqələr sayəsində biz bu təsviri lazım olan qədər tez yerləşdirə bilərik. Metod axmaqdır, amma yaxşı işləyir.
NS: Sonra test etdiyiniz zaman o, Dockerin daxilində dəyişir, elə deyilmi? Docker daxilində kopyala-yazma - onu atın və yenidən gedin, hər şey qaydasındadır. Sinif! Və siz artıq ondan tam istifadə edirsiniz?
DS: Uzun müddətə.
NS: Biz çox oxşar şeylər edirik. Yalnız biz Docker-in surəti-on-write funksiyasından istifadə etmirik, başqa birindən istifadə edirik.
DS: Bu ümumi deyil. Və Docker hər yerdə işləyir.
NS: Teorik olaraq, bəli. Amma bizim orada modullarımız da var, müxtəlif modullar düzəldə və müxtəlif fayl sistemləri ilə işləyə bilərsiniz. Burda nə an. Postgres tərəfdən, biz bütün bunlara fərqli baxırıq. İndi Docker tərəfdən baxdım və hər şeyin sizin üçün işlədiyini gördüm. Amma verilənlər bazası böyükdürsə, məsələn, 1 TB, onda bütün bunlar çox vaxt aparır: gecə əməliyyatları və hər şeyi Docker-ə doldurmaq... Və əgər Docker-ə 5 TB doldurulubsa... Yoxsa hər şey yaxşıdır?
DS: Fərq nədir: bunlar bloblardır, sadəcə bitlər və baytlar.
NS: Fərq budur: siz bunu dump və bərpa vasitəsilə edirsiniz?
DS: Heç lazım deyil. Bu görüntünün yaradılması üsulları fərqli ola bilər.
NS: Bəzi müştərilər üçün biz bunu elə etdik ki, müntəzəm olaraq əsas təsvir yaratmaq əvəzinə, onu daima yeniləyirik. Bu, mahiyyətcə bir replikadır, lakin məlumatları birbaşa masterdən deyil, arxiv vasitəsilə alır. WAL-ların hər gün yükləndiyi, ehtiyat nüsxələrinin götürüldüyü binar arxiv... Bu WAL-lar daha sonra bir qədər gecikmə ilə (hərfi mənada 1-2 saniyə) əsas təsvirə çatır. Ondan istənilən şəkildə klonlayırıq - indi standart olaraq ZFS var.
DS: Lakin ZFS ilə siz bir node ilə məhdudlaşırsınız.
NS: Bəli. Ancaq ZFS-nin də bir sehri var : bununla siz snapshot göndərə bilərsiniz və hətta (mən bunu hələ sınamamışam, amma...) ikisi arasında delta göndərə bilərsiniz PGDATA. Əslində, bu cür tapşırıqlar üçün həqiqətən nəzərdən keçirmədiyimiz başqa bir alətimiz var. PostgreSQL var , “ağıllı” rsync kimi işləyir, izləmək lazım olmayan bir çox şeyi atlayır, çünki orada heç nə dəyişməyib. İki server arasında sürətli sinxronizasiya edə və eyni şəkildə geri çəkə bilərik.
Beləliklə, daha çox DBA tərəfdən, biz dediyiniz şeyi etməyə imkan verən bir alət yaratmağa çalışırıq: bir verilənlər bazamız var, lakin demək olar ki, eyni vaxtda bir şeyi 50 dəfə sınaqdan keçirmək istəyirik.
DS: 50 dəfə 50 Spot nümunəsi sifariş etməli olduğunuz deməkdir.
NS: Xeyr, biz hər şeyi bir maşında edirik.
DS: Bəs bu verilənlər bazası, məsələn, terabaytdırsa, necə 50 dəfə genişləndirəcəksiniz. Çox güman ki, ona şərti 256 GB RAM lazımdır?
NS: Bəli, bəzən sizə çoxlu yaddaş lazımdır - bu normaldır. Amma bu həyatdan bir nümunədir. İstehsal maşını 96 nüvəyə və 600 GB-a malikdir. Eyni zamanda, verilənlər bazası üçün 32 nüvə (hətta bəzən 16 nüvə) və 100-120 GB yaddaş istifadə olunur.
DS: Və 50 nüsxə oraya sığar?
NS: Deməli, yalnız bir nüsxə var, sonra copy-on-write (ZFS) işləyir... Mən sizə daha ətraflı məlumat verəcəyəm.
Məsələn, bizdə 10 TB məlumat bazası var. Bunun üçün disk düzəltdilər, ZFS də onun ölçüsünü 30-40 faiz sıxışdırdı. Yük testi etmədiyimiz üçün dəqiq cavab müddəti bizim üçün vacib deyil: 2 dəfəyə qədər yavaş olsun - bu, yaxşıdır.
Biz proqramçılara imkan veririk, QA, DBA və s. 1-2 iplikdə test edin. Məsələn, onlar bir növ miqrasiya həyata keçirə bilərlər. Bir anda 10 nüvə tələb etmir - ona 1 Postgres backend, 1 nüvə lazımdır. Miqrasiya başlayacaq - bəlkə də hələ də başlayacaq, sonra ikinci nüvədən istifadə ediləcək. Bizdə 16-32 nüvə ayrılıb, ona görə də 10 nəfər eyni anda işləyə bilər, heç bir problem yoxdur.
Çünki fiziki olaraq PGDATA eyni, belə çıxır ki, biz əslində Postgresi aldadırıq. Hiylə belədir: məsələn, eyni vaxtda 10 Postgre işə salınır. Adətən problem nədir? Onlar qoydular , tutaq ki, 25%. Müvafiq olaraq, bu 200 GB-dır. Bunlardan üçündən çoxunu işə sala bilməyəcəksiniz, çünki yaddaş tükənəcək.
Ancaq bir anda bunun lazım olmadığını başa düşdük: paylaşılan_buferləri 2 GB-a təyin etdik. PostgreSQL var , və əslində təsir edən yeganədir . Biz onu 0,5 TB-a təyin etdik. Onların əslində mövcud olmamasının da əhəmiyyəti yoxdur: o, sanki varmış kimi planlar qurur.
Müvafiq olaraq, bir növ miqrasiyanı sınaqdan keçirdikdə, bütün planları toplaya bilərik - istehsalda bunun necə olacağını görəcəyik. Oradakı saniyələr fərqli (daha yavaş) olacaq, amma əslində oxuduğumuz məlumatlar və planların özləri (orada nə QOŞULUŞLAR var və s.) istehsalda olduğu kimi tam olaraq eynidir. Və bir maşında paralel olaraq bir çox belə yoxlama apara bilərsiniz.
DS: Sizə elə gəlmir ki, burada bir neçə problem var? Birincisi, yalnız PostgreSQL-də işləyən bir həlldir. Bu yanaşma çox özəldir, ümumi deyil. İkincisi, Kubernetes (və bulud texnologiyalarının indi gedəcəyi hər şey) bir çox qovşaqları əhatə edir və bu qovşaqlar efemerdir. Və sizin vəziyyətinizdə bu, vəziyyətə uyğun, davamlı bir düyündür. Bu şeylər məndə ziddiyyət yaradır.
NS: Birincisi, razıyam, bu sırf Postgres hekayəsidir. Düşünürəm ki, bir növ birbaşa IO və demək olar ki, bütün yaddaş üçün bufer hovuzumuz varsa, bu yanaşma işləməyəcək - planlar fərqli olacaq. Ancaq hələlik biz yalnız Postgres ilə işləyirik, başqaları haqqında düşünmürük.
Kubernetes haqqında. Siz özünüz hər yerdə bizə deyirsiniz ki, bizim davamlı məlumat bazamız var. Nümunə uğursuz olarsa, əsas şey diski saxlamaqdır. Burada Kubernetes-də bütün platformamız var və Postgres ilə komponent ayrıdır (baxmayaraq ki, bir gün orada olacaq). Buna görə də hər şey belədir: instansiya düşdü, lakin biz onun PV-ni saxladıq və heç nə olmamış kimi sadəcə onu başqa (yeni) instansiyaya bağladıq.
DS: Məncə, biz Kubernetes-də podlar yaradırıq. K8s - elastik: lazım olduqda düyünlər sifariş edilir. Tapşırıq sadəcə bir pod yaratmaq və onun X miqdarda resursa ehtiyacı olduğunu söyləməkdir, sonra K8-lər bunu öz-özünə anlayacaq. Lakin Kubernetes-də saxlama dəstəyi hələ də qeyri-sabitdir: , in (bu buraxılış buraxıldı недели əvvəl) bu xüsusiyyətlər yalnız beta olur.
Altı aydan bir ilə qədər keçəcək - o, az-çox sabitləşəcək və ya heç olmasa belə elan ediləcək. Sonra snapshots və ölçüsünü dəyişmək imkanı probleminizi tamamilə həll edir. Çünki sizin bazanız var. Bəli, bu, çox sürətli olmaya bilər, lakin sürət “qapaq altında” nə olduğundan asılıdır, çünki bəzi tətbiqlər disk alt sistemi səviyyəsində kopyalaya və yaza bilər.
NS: Bütün mühərriklərin (Amazon, Google...) bu versiyanı dəstəkləməyə başlaması da lazımdır - bu da bir qədər vaxt aparır.
DS: Biz hələ onlardan istifadə etmirik. Biz özümüzdən istifadə edirik.
Kubernetes üçün yerli inkişaf
NS: Bütün podları bir maşına quraşdırmaq və belə kiçik bir test etmək lazım olanda belə bir arzu ilə qarşılaşmısınızmı? Tez bir konsepsiya sübutu əldə etmək üçün tətbiqin bir dəstə maşın ayırmadan Kubernetes-də işlədiyinə baxın. Minikube var, elə deyilmi?
DS: Mənə elə gəlir ki, bu iş - bir qovşaqda yerləşdirilmiş - yalnız yerli inkişafla bağlıdır. Və ya belə bir nümunənin bəzi təzahürləri. Yemək , var , . Kubernetes IN Docker-dən istifadə etməyə doğru irəliləyirik. İndi testlər üçün onunla işləməyə başladıq.
NS: Əvvəllər düşünürdüm ki, bu, bütün podları bir Docker şəklinə yığmaq cəhdidir. Amma məlum oldu ki, söhbət tamam başqa şeydən gedir. Hər halda, ayrı qablar, ayrı podlar var - yalnız Docker-də.
DS: Bəli. Olduqca gülməli imitasiya da var, amma mənası budur... Bizdə yerləşdirmə üçün bir yardım proqramı var - . Biz onu şərti rejimə çevirmək istəyirik werf up: "Mənə yerli Kubernetes alın." Və sonra orada şərti işə salın werf follow. Sonra tərtibatçı IDE-ni redaktə edə biləcək və sistemdə dəyişiklikləri görən və şəkilləri yenidən quran, onları yerli K8-lərə yerləşdirən proses işə salınacaq. Biz yerli inkişaf problemini belə həll etməyə çalışmaq istəyirik.
K8s reallığında anlıq görüntülər və verilənlər bazası klonlaması
NS: Kopiya-on-yazıya qayıtsaq. Diqqət etdim ki, buludların da anlıq görüntüləri var. Onlar fərqli işləyirlər. Məsələn, GCP-də: ABŞ-ın şərq sahilində çox terabaytlıq nümunəniz var. Siz vaxtaşırı şəkillər çəkirsiniz. Siz qərb sahilində diskin bir nüsxəsini bir şəkildən götürürsünüz - bir neçə dəqiqədən sonra hər şey hazırdır, çox tez işləyir, yalnız yaddaş yaddaşını doldurmaq lazımdır. Lakin bu klonlar (snapshotlar) yeni bir həcm təmin etmək üçündür. Çoxlu instansiya yaratmağınız lazım olanda bu, əladır.
Amma testlər üçün mənə elə gəlir ki, sizin Docker-də danışdığınız və ya mənim ZFS-də, btrfs-də və hətta LVM-də danışdığım snapshotlar... - onlar sizə bir maşında həqiqətən yeni məlumatlar yaratmamağa imkan verir. Buludda siz yenə də hər dəfə onlar üçün ödəyəcəksiniz və saniyələr deyil, dəqiqələr gözləyəcəksiniz (və halda , bəlkə də saat).
Bunun əvəzinə, bu məlumatları bir və ya iki saniyəyə əldə edə, sınaqdan keçirə və tullaya bilərsiniz. Bu snapshotlar müxtəlif problemləri həll edir. Birinci halda - genişləndirmək və yeni replikalar əldə etmək, ikincisi - testlər üçün.
DS: Razı deyiləm. Həcmi klonlaşdırmanın düzgün işləməsini təmin etmək buludun vəzifəsidir. Mən onların həyata keçirilməsinə baxmamışam, amma bunu aparatda necə etdiyimizi bilirəm. Bizdə Ceph var, istənilən fiziki həcmə imkan verir () deyin Clone və onlarla millisaniyə ərzində eyni xüsusiyyətlərə malik ikinci həcmi əldə edin, 'ami və s. Siz başa düşməlisiniz ki, içəridə çətin bir surət yazısı var. Niyə bulud eyni şeyi etməməlidir? Əminəm ki, onlar bu və ya digər şəkildə bunu etməyə çalışırlar.
NS: Ancaq bir nümunə qaldırmaq, Docker-i ora gətirmək və s. üçün onlara saniyələr, onlarla saniyə lazım olacaq.
DS: Niyə bütöv bir nümunəni qaldırmaq lazımdır? 32 nüvəli bir nümunəmiz var, 16... və o, ona sığa bilər - məsələn, dörd. Beşincisini sifariş etdikdə, nümunə artıq qaldırılacaq və sonra silinəcək.
NS: Bəli, maraqlıdır, Kubernetes fərqli bir hekayədir. Bizim verilənlər bazamız K8-lərdə deyil və bir nümunəmiz var. Lakin çox terabaytlıq verilənlər bazasını klonlaşdırmaq iki saniyədən çox çəkmir.
DS: Bu əladı. Ancaq ilkin fikrim budur ki, bu ümumi bir həll deyil. Bəli, əladır, lakin yalnız Postgres üçün uyğundur və yalnız bir node üçün.
NS: Yalnız Postgres üçün uyğun deyil: bu planlar, təsvir etdiyim kimi, yalnız onda işləyəcək. Ancaq planlar haqqında narahat deyiliksə və yalnız funksional test üçün bütün məlumatlara ehtiyacımız varsa, bu, istənilən DBMS üçün uyğundur.
DS: Uzun illər əvvəl biz LVM snapshotlarında oxşar bir şey etdik. Bu klassikdir. Bu üsuldan çox fəal istifadə olunurdu. Vəziyyətli düyünlər sadəcə ağrıdır. Çünki onları atmamalısan, onları həmişə xatırlamalısan...
NS: Burada hibrid olma ehtimalını görürsünüzmü? Deyək ki, statuslu bir növ poddur, bir neçə nəfər üçün işləyir (bir çox sınaqçı). Bizdə bir cild var, lakin fayl sistemi sayəsində klonlar yerlidir. Pod düşsə, lakin disk qalsa, pod qalxacaq, bütün klonlar haqqında məlumatları sayacaq, hər şeyi yenidən götürüb deyin: "Budur, bu portlarda işləyən klonlarınız, onlarla işləməyə davam edin."
DS: Texniki olaraq bu o deməkdir ki, Kubernetes daxilində bir çox Postgres işlədiyimiz bir poddur.
NS: Bəli. Onun bir limiti var: tutaq ki, onunla eyni vaxtda 10-dan çox adam işləmir. Əgər sizə 20 ədəd lazımdırsa, biz ikinci belə podu işə salacağıq. Biz onu tam klonlayacağıq, ikinci tam cildi aldıqdan sonra eyni 10 "nazik" klon olacaq. Bu fürsəti görmürsən?
DS: Biz buraya təhlükəsizlik məsələləri əlavə etməliyik. Bu tip təşkilat, bu podun yüksək imtiyazlara (bacarıqlara) malik olduğunu nəzərdə tutur, çünki o, fayl sistemində qeyri-standart əməliyyatlar həyata keçirə bilər... Amma təkrar edirəm: inanıram ki, orta müddətdə Kubernetes-də yaddaşı düzəldəcəklər və buludlar bütün hekayəni cildlərlə düzəldəcəklər - hər şey "sadəcə işləyəcək". Ölçüsü dəyişdiriləcək, klonlaşdırılacaq... Həcmi var - deyirik: “Bunun əsasında yenisini yaradın” və saniyə yarımdan sonra lazım olanı alırıq.
NS: Çox terabayt üçün bir yarım saniyəyə inanmıram. Ceph-də bunu özünüz edirsiniz, ancaq buludlardan danışırsınız. Buluda gedin, EC2-də çox terabaytlıq EBS həcminin klonunu yaradın və performansın necə olacağına baxın. Bir neçə saniyə çəkməyəcək. Mənə çox maraqlıdır ki, onlar nə vaxt bu səviyyəyə çatacaqlar. Nə dediyinizi başa düşürəm, amma fərqli olmağa yalvarıram.
DS: Yaxşı, amma qısa müddətdə deyil, orta müddətli dedim. Bir neçə ildir.
Zalandodan PostgreSQL üçün operator haqqında
Bu görüşün ortasında Zalandodan olan keçmiş tərtibatçı Aleksey Klyukin də qoşuldu və PostgreSQL operatorunun tarixindən danışdı:
Bu mövzuya ümumiyyətlə toxunulması əladır: həm Postgres, həm də Kubernetes. 2017-ci ildə Zalandoda bunu etməyə başlayanda bu, hər kəsin etmək istədiyi, lakin heç kimin etmədiyi bir mövzu idi. Artıq hər kəsin Kubernetləri var idi, lakin verilənlər bazası ilə nə edəcəyini soruşduqda, hətta insanlar da bəyənir K8-ləri təbliğ edən , belə bir şey söylədi:
“İdarə olunan xidmətlərə gedin və onlardan istifadə edin, verilənlər bazasını Kubernetes-də işlətməyin. Əks halda, K8-ləriniz, məsələn, təkmilləşdirməyə qərar verəcək, bütün qovşaqları söndürəcək və məlumatlarınız çox uzaqlara uçacaq”.
Bu tövsiyənin əksinə olaraq Kubernetes-də Postgres verilənlər bazasını işə salacaq bir operator etmək qərarına gəldik. Və yaxşı bir səbəbimiz var idi - . Bu, düzgün yerinə yetirilən PostgreSQL üçün avtomatik uğursuzluqdur, yəni. etcd, consul və ya ZooKeeper-dan çoxluq haqqında məlumatın saxlanması kimi istifadə. Belə bir anbar ki, məsələn, indiki liderin nə olduğunu soruşan hər kəsə eyni məlumatı verəcək - hər şeyin paylanmasına baxmayaraq, beyin parçalanmasın. Üstəlik bizdə də var idi onun üçün.
Ümumiyyətlə, şirkətin avtomatik işləməyə ehtiyacı daxili aparat məlumat mərkəzindən bulud sisteminə köçdükdən sonra ortaya çıxdı. Bulud mülkiyyətçi PaaS (Platform-as-a-Service) həllinə əsaslanırdı. Açıq mənbədir, lakin onu işə salmaq üçün çox iş tələb olunurdu. Bu adlanırdı .
Əvvəlcə Kubernetes yox idi. Daha doğrusu, öz həllimiz tətbiq olunanda, K8-lər artıq mövcud idi, lakin o qədər xam idi ki, istehsal üçün uyğun deyildi. Məncə, 2015 və ya 2016-cı il idi. 2017-ci ilə qədər Kubernetes az-çox yetkinləşdi - ora köçməyə ehtiyac var idi.
Artıq Docker konteynerimiz var idi. Docker-dən istifadə edən bir PaaS var idi. Niyə K8-ləri sınamırsınız? Niyə öz operatorunuzu yazmırsınız? Avitodan bizə gələn Murat Kabilov buna öz təşəbbüsü ilə “oynamaq” layihəsi kimi başladı və layihə “başladı”.
Amma ümumilikdə AWS haqqında danışmaq istədim. Niyə tarixi AWS ilə əlaqəli kod var idi?
Kubernetes-də bir şey işlətdiyiniz zaman K8-lərin belə davam edən bir iş olduğunu başa düşməlisiniz. Daim inkişaf edir, təkmilləşir və hətta zaman-zaman dağılır. Siz Kubernetes-dəki bütün dəyişiklikləri diqqətlə izləməlisiniz, bir şey baş verərsə, onun içinə girməyə hazır olmalı və bunun necə işlədiyini təfərrüatlı öyrənməlisiniz - bəlkə də istədiyinizdən daha çox. Bu, prinsipcə, verilənlər bazalarınızı işlətdiyiniz istənilən platformaya aiddir...
Beləliklə, biz bəyanat verəndə Postgres xarici həcmdə işləyirdi (bu halda EBS, AWS üzərində işlədiyimiz üçün). Verilənlər bazası böyüdü, bir anda onun ölçüsünü dəyişmək lazım oldu: məsələn, EBS-nin ilkin ölçüsü 100 TB idi, verilənlər bazası ona qədər böyüdü, indi biz EBS 200 TB etmək istəyirik. Necə? Tutaq ki, siz yeni instansiyada boşaltma/bərpa edə bilərsiniz, lakin bu, uzun vaxt aparacaq və fasilələrlə bağlı olacaq.
Buna görə də, mən EBS bölməsini artıracaq və sonra fayl sisteminə yeni boşluqdan istifadə etməyi bildirəcək bir ölçü dəyişdirmək istədim. Və biz bunu etdik, lakin o zaman Kubernetes-in ölçüsünü dəyişmə əməliyyatı üçün heç bir API yox idi. AWS üzərində işlədiyimiz üçün onun API üçün kod yazdıq.
Heç kim sizə digər platformalar üçün də eyni şeyi etməyə mane olmur. Bəyanatda onun yalnız AWS-də işlədilə biləcəyinə dair heç bir işarə yoxdur və başqa hər şeydə işləməyəcək. Ümumiyyətlə, bu, Açıq Mənbə layihəsidir: hər kəs yeni API-nin istifadəsini sürətləndirmək istəyirsə, xoş gəlmisiniz. Yemək , çəkmə sorğuları - Zalando komandası onlara kifayət qədər tez cavab verməyə və operatoru tanıtmağa çalışır. Bildiyimə görə layihə Google Summer of Code və bəzi digər oxşar təşəbbüslərdə. Zalando bunun üzərində çox fəal işləyir.
P.S. Bonus!
PostgreSQL və Kubernetes mövzusu ilə maraqlanırsınızsa, zəhmət olmasa qeyd edin ki, növbəti Postgres çərşənbə axşamı keçən həftə Nikolay ilə danışdığım yerdə baş tutdu. Zalandodan olan Aleksandr Kukuşkin. Oradan video mövcuddur .
PPS
Bloqumuzda da oxuyun:
- «";
- «";
- «";
- «.
Mənbə: www.habr.com