O'tgan yilning oxirida Rossiya PostgreSQL hamjamiyatining navbatdagi jonli efiri bo'lib o'tdi , uning asoschisi Nikolay Samoxvalov Flant texnik direktori Dmitriy Stolyarov bilan Kubernetes kontekstida ushbu DBMS haqida suhbatlashdi.
Biz ushbu muhokamaning asosiy qismining stenogrammasini e'lon qilamiz va at Toʻliq video eʼlon qilindi:
Ma'lumotlar bazalari va Kubernetes
НС: Bugun biz VAKUUM va CHECKPOINTlar haqida gapirmaymiz. Biz Kubernetes haqida gaplashmoqchimiz. Ko'p yillik tajribangiz borligini bilaman. Men sizning videolaringizni tomosha qildim va hatto ba'zilarini qayta ko'rdim... Keling, to'g'ridan-to'g'ri mavzuga o'taylik: nima uchun umuman K8-larda Postgres yoki MySQL?
DS: Bu savolga aniq javob yo'q va bo'lishi ham mumkin emas. Ammo umuman olganda, bu oddiylik va qulaylik ... salohiyat. Hamma boshqariladigan xizmatlarni xohlaydi.
НС: Qanday qilib , faqat uydami?
DS: Ha: RDS kabi, hamma joyda.
НС: "Hamma joyda" yaxshi nuqta. Katta kompaniyalarda hamma narsa turli joylarda joylashgan. Nima uchun u yirik kompaniya bo'lsa, tayyor echimni qabul qilmaysizmi? Misol uchun, Nutanix o'z ishlanmalariga ega, boshqa kompaniyalar (VMware...) bir xil "RDS, faqat uyda".
DS: Lekin biz faqat ma'lum sharoitlarda ishlaydigan alohida amalga oshirish haqida gapiramiz. Va agar biz Kubernetes haqida gapiradigan bo'lsak, unda juda ko'p turli xil infratuzilma mavjud (bu K8-larda bo'lishi mumkin). Aslida, bu bulutga API uchun standartdir...
НС: Bu ham bepul!
DS: Bu unchalik muhim emas. Bozorning unchalik katta bo'lmagan segmenti uchun erkinlik muhim ahamiyatga ega. Yana bir narsa muhim... Hisobotni eslagandirsiz”"?"
НС: Ha.
DS: Men buni juda noaniq qabul qilganini angladim. Ba'zilar meni: "Yigitlar, keling, barcha ma'lumotlar bazalarini Kubernetesga kiritaylik!" Deyapman deb o'ylashdi, boshqalari bularning barchasi dahshatli velosipedlar deb qaror qilishdi. Lekin men butunlay boshqacha narsani aytmoqchi edim: “Qarang, nima bo'lyapti, qanday muammolar bor va ularni qanday hal qilish mumkin. Endi Kubernetes ma'lumotlar bazalaridan foydalanishimiz kerakmi? Ishlab chiqarish? Xo'sh, faqat sizga yoqsa ... ba'zi narsalarni qilish. Ammo dev uchun men buni tavsiya qilaman deb ayta olaman. Ishlab chiquvchi uchun muhitlarni yaratish/o‘chirish dinamikasi juda muhim.”
NS: Dev deganda siz ishlab chiqarilmaydigan barcha muhitlarni nazarda tutyapsizmi? Sahnalashtirish, QA…
DS: Agar biz perf stendlari haqida gapiradigan bo'lsak, unda ehtimol yo'q, chunki u erda talablar o'ziga xosdir. Agar biz sahnalashtirish uchun juda katta ma'lumotlar bazasi kerak bo'lgan maxsus holatlar haqida gapiradigan bo'lsak, unda ehtimol yo'q ... Agar bu statik, uzoq umr ko'radigan muhit bo'lsa, unda ma'lumotlar bazasi K8larda joylashgan bo'lishidan qanday foyda bor?
НС: Yo'q. Ammo biz statik muhitni qayerda ko'ramiz? Statik muhit ertaga eskiradi.
DS: Sahnalashtirish statik bo'lishi mumkin. Bizning mijozlarimiz bor ...
НС: Ha, menda ham bor. Agar sizda 10 TB ma'lumotlar bazasi va 200 GB staging bo'lsa, bu katta muammo...
DS: Menda juda ajoyib ish bor! Sahnada o'zgartirishlar kiritilgan mahsulot ma'lumotlar bazasi mavjud. Va tugma mavjud: "ishlab chiqarishga o'tish". Ushbu o'zgarishlar - deltalar ishlab chiqarishda qo'shiladi (ular oddiygina API orqali sinxronlanganga o'xshaydi). Bu juda ekzotik variant.
НС: Men vodiyda RDS yoki hatto Gerokuda o'tirgan startaplarni ko'rdim - bu 2-3 yil oldingi voqealar - va ular chiqindini noutbuklariga yuklab olishadi. Chunki ma'lumotlar bazasi hali ham atigi 80 GB va noutbukda bo'sh joy mavjud. Keyin ular har bir kishi uchun qo'shimcha disklarni sotib olishadi, shunda ular turli xil ishlanmalarni amalga oshirish uchun 3 ta ma'lumotlar bazasiga ega bo'lishadi. Bu ham shunday bo'ladi. Shuningdek, men ular prodni sahnalashtirishga nusxalashdan qo'rqmasliklarini ko'rdim - bu ko'p narsa kompaniyaga bog'liq. Lekin men ularning juda qo'rqishlarini va ko'pincha vaqtlari va qo'llari etarli emasligini ham ko'rdim. Ammo bu mavzuga o'tishdan oldin, men Kubernetes haqida eshitmoqchiman. Men hali hech kim ishlab chiqmaganini to'g'ri tushundimmi?
DS: Bizda ishlab chiqarishda kichik ma'lumotlar bazalari mavjud. Gap o'nlab gigabayt hajmlar va biz replikatsiya qilish uchun dangasa bo'lgan muhim bo'lmagan xizmatlar haqida bormoqda (va bunday ehtiyoj yo'q). Va agar Kubernetes ostida normal saqlash mavjud bo'lsa. Ushbu ma'lumotlar bazasi virtual mashinada - shartli ravishda VMware-da, saqlash tizimining tepasida ishlagan. Biz uni joylashtirdik va endi biz uni mashinadan mashinaga o'tkazishimiz mumkin.
НС: 100 Gb gacha bo'lgan bu hajmdagi ma'lumotlar bazalarini bir necha daqiqada yaxshi disklar va yaxshi tarmoqqa chiqarish mumkin, to'g'rimi? Bir soniyada 1 GB tezlik endi ekzotik emas.
DS: Ha, chiziqli ishlash uchun bu muammo emas.
НС: Yaxshi, biz faqat mahsulot haqida o'ylashimiz kerak. Va agar biz ishlab chiqarilmaydigan muhitlar uchun Kubernetesni ko'rib chiqsak, nima qilishimiz kerak? Men buni Zalandoda ko'raman , Crunchy ichida , ba'zi boshqa variantlar mavjud. Va bor - bu ispaniyalik yaxshi do'stimiz Alvaro: ular qilayotgan ishi aslida shunchaki emas , va butun taqsimot (), ular Postgres-dan tashqari, Elchi proksi-serverini ham zaxiralashga qaror qilishdi...
DS: Nima uchun elchi? Ayniqsa, Postgres trafigini muvozanatlash?
НС: Ha. Ya'ni, ular buni shunday ko'rishadi: agar siz Linux distributivini va yadrosini olsangiz, oddiy PostgreSQL yadro bo'lib, ular bulutga mos keladigan va Kubernetes-da ishlaydigan tarqatishni qilishni xohlashadi. Ular komponentlarni (zaxira nusxalarini va boshqalarni) birlashtiradi va yaxshi ishlashi uchun ularni disk raskadrovka qiladi.
DS: Juda zo'r! Aslida, bu o'zingizning boshqariladigan Postgres-ni yaratish uchun dastur.
НС: Linux distributivlarida abadiy muammolar mavjud: drayverlarni qanday qilib barcha apparatlar qo'llab-quvvatlanishi uchun qilish kerak. Va ular Kubernetesda ishlashlari haqida fikrga ega. Bilaman, Zalando operatorida biz yaqinda AWS-ga ulanishni ko'rdik va bu endi unchalik yaxshi emas. Muayyan infratuzilma bilan bog'liq bo'lmasligi kerak - buning nima keragi bor?
DS: Zalando qanday vaziyatga tushib qolganini aniq bilmayman, lekin Kubernetes-da saqlash hozir shunday qilinganki, umumiy usul yordamida diskning zahira nusxasini olishning iloji yo'q. Yaqinda standartda - so'nggi versiyada — biz suratga olish imkoniyatini yaratdik, lekin u qayerda amalga oshirilmoqda? Rostini aytsam, hamma narsa hali ham juda xom... Biz AWS, GCE, Azure, vSphere ustida CSI-ni sinab ko'rmoqdamiz, lekin uni ishlatishni boshlashingiz bilanoq, u hali tayyor emasligini ko'rishingiz mumkin.
НС: Shuning uchun biz ba'zan infratuzilmaga tayanishimiz kerak. Menimcha, bu hali erta bosqich - o'sib borayotgan og'riqlar. Savol: K8-da PgSQL-ni sinab ko'rmoqchi bo'lgan yangi boshlanuvchilarga qanday maslahat berasiz? Qaysi operator?
DS: Muammo shundaki, Postgres biz uchun 3%. Shuningdek, bizda Kubernetes-da turli xil dasturlarning juda katta ro'yxati bor, men hamma narsani sanab o'tmayman. Masalan, Elasticsearch. Operatorlar juda ko'p: ba'zilari faol rivojlanmoqda, boshqalari esa yo'q. Biz o'zimizga jiddiy munosabatda bo'lishimiz uchun operator nimaga ega bo'lishi kerakligi haqidagi talablarni ishlab chiqdik. Kubernetes uchun maxsus operatorda - "Amazon sharoitida biror narsa qilish uchun operator"da emas ... Aslida, biz juda keng tarqalgan (= deyarli barcha mijozlar) bitta operatordan foydalanamiz - (tez orada u haqida maqola e'lon qilamiz).
НС: MySQL uchun ham emasmi? Men bilamanki, Percona... hozir MySQL, MongoDB va Postgres ustida ishlayotgani uchun ular qandaydir universal yechim yaratishlari kerak bo‘ladi: barcha ma’lumotlar bazalari, barcha bulutli provayderlar uchun.
DS: MySQL uchun operatorlarni ko'rib chiqishga vaqtimiz yo'q edi. Bu hozir bizning asosiy e'tiborimiz emas. MySQL mustaqil rejimda yaxshi ishlaydi. Agar siz shunchaki ma'lumotlar bazasini ishga tushirishingiz mumkin bo'lsa, nima uchun operatordan foydalanish kerak ... Siz Postrges bilan Docker konteynerini ishga tushirishingiz mumkin yoki uni oddiy usulda ishga tushirishingiz mumkin.
НС: Bu haqda ham savol bor edi. Operator yo'qmi?
DS: Ha, bizda 100% PostgreSQL operatorsiz ishlaydi. Hozirgacha. Biz Prometey va Redis uchun operatordan faol foydalanamiz. Bizda Elasticsearch operatorini topish rejalarimiz bor - bu eng ko'p "yong'in" bo'lgan operator, chunki biz uni Kubernetes-ga 100% hollarda o'rnatmoqchimiz. Xuddi biz MongoDB har doim Kubernetes-da o'rnatilishini ta'minlashni xohlaymiz. Bu erda ma'lum istaklar paydo bo'ladi - bu holatlarda biror narsa qilish mumkin degan tuyg'u bor. Va biz Postgresga ham qaramadik. Albatta, biz turli xil variantlar mavjudligini bilamiz, lekin aslida bizda mustaqil bor.
Kubernetes-da sinov uchun JB
НС: Keling, test mavzusiga o'tamiz. Ma'lumotlar bazasiga o'zgarishlarni qanday kiritish mumkin - DevOps nuqtai nazaridan. Mikroservislar, ko'plab ma'lumotlar bazalari mavjud, har doim biror narsa o'zgarib turadi. DBMS nuqtai nazaridan hamma narsa tartibda bo'lishi uchun oddiy CI/CDni qanday ta'minlash kerak. Sizning yondashuvingiz qanday?
DS: Bitta javob bo'lishi mumkin emas. Bir nechta variant mavjud. Birinchisi, biz chiqarmoqchi bo'lgan bazaning o'lchami. Siz o'zingiz aytgandingizki, kompaniyalar ishlab chiqarish va sahnada ishlab chiqarish ma'lumotlar bazasi nusxasiga ega bo'lishga turlicha munosabatda bo'lishadi.
НС: Va GDPR shartlariga ko'ra, ular ko'proq va ehtiyotkor bo'lishmoqda, deb o'ylayman... Aytishim mumkinki, Evropada ular allaqachon jarima solishni boshladilar.
DS: Lekin ko'pincha siz ishlab chiqarishdan axlatni olib tashlaydigan va uni xiralashtiradigan dasturiy ta'minotni yozishingiz mumkin. Ishlab chiqarish ma'lumotlari olinadi (snapshot, dump, ikkilik nusxa ...), lekin u anonimlashtiriladi. Buning o'rniga, avlod skriptlari bo'lishi mumkin: bu armatura yoki shunchaki katta ma'lumotlar bazasini yaratadigan skript bo'lishi mumkin. Muammo shundaki: asosiy tasvirni yaratish uchun qancha vaqt ketadi? Va uni kerakli muhitda joylashtirish uchun qancha vaqt ketadi?
Biz sxemaga keldik: agar mijozda qattiq ma'lumotlar to'plami (ma'lumotlar bazasining minimal versiyasi) bo'lsa, biz ularni sukut bo'yicha ishlatamiz. Agar biz ko'rib chiqish muhiti haqida gapiradigan bo'lsak, biz filialni yaratganimizda, biz ilovaning namunasini joylashtirdik - biz u erda kichik ma'lumotlar bazasini chiqaramiz. Lekin bu yaxshi chiqdi , biz kuniga bir marta ishlab chiqarishdan chiqindini olib (kechasi) va unga asoslangan ushbu yuklangan ma'lumotlar bilan PostgreSQL va MySQL bilan Docker konteynerini qurganimizda. Agar siz ushbu rasmdan ma'lumotlar bazasini 50 marta kengaytirishingiz kerak bo'lsa, bu juda oddiy va tez amalga oshiriladi.
НС: Oddiy nusxa ko'chirish orqalimi?
DS: Ma'lumotlar to'g'ridan-to'g'ri Docker tasvirida saqlanadi. Bular. Bizda 100 GB bo'lsa-da, tayyor rasm mavjud. Docker-dagi qatlamlar tufayli biz ushbu tasvirni kerakli darajada tez o'rnatishimiz mumkin. Usul ahmoqona, lekin u yaxshi ishlaydi.
НС: Keyin, sinovdan o'tganingizda, u Docker ichida o'zgaradi, shunday emasmi? Docker ichida nusxa ko'chirish - uni tashlang va yana boring, hammasi yaxshi. Sinf! Va siz allaqachon undan to'liq foydalanyapsizmi?
DS: Uzoq vaqt davomida; anchadan beri.
НС: Biz juda o'xshash narsalarni qilamiz. Faqat biz Docker-ning yozma nusxasini ishlatmaymiz, lekin boshqasini ishlatamiz.
DS: Bu umumiy emas. Va Docker hamma joyda ishlaydi.
НС: Nazariy jihatdan, ha. Ammo bizda modullar ham bor, siz turli xil modullarni yaratishingiz va turli fayl tizimlari bilan ishlashingiz mumkin. Bu erda qanday daqiqa. Postgres tomondan biz bularning barchasiga boshqacha qaraymiz. Endi men Docker tomondan qaradim va hamma narsa siz uchun ishlayotganini ko'rdim. Ammo agar ma'lumotlar bazasi juda katta bo'lsa, masalan, 1 TB bo'lsa, unda bularning barchasi ko'p vaqt talab etadi: tunda operatsiyalar va hamma narsani Docker-ga to'ldirish ... Va agar Docker-ga 5 TB to'ldirilgan bo'lsa ... Yoki hammasi yaxshimi?
DS: Farqi nimada: bular bloblar, shunchaki bitlar va baytlar.
НС: Farqi shundaki: siz buni dump va tiklash orqali qilasizmi?
DS: Aslo kerak emas. Ushbu tasvirni yaratish usullari boshqacha bo'lishi mumkin.
НС: Ba'zi mijozlar uchun biz buni shunday qildikki, biz muntazam ravishda asosiy tasvirni yaratish o'rniga, uni doimiy ravishda yangilab turamiz. Bu mohiyatan replika, lekin u ma'lumotlarni ustadan to'g'ridan-to'g'ri emas, balki arxiv orqali oladi. WALlar har kuni yuklab olinadigan, zaxira nusxalari olinadigan ikkilik arxiv... Keyin bu WALlar bir oz kechikish bilan (so'zma-so'z 1-2 soniya) asosiy tasvirga yetib boradi. Biz undan istalgan tarzda klonlashtiramiz - endi bizda sukut bo'yicha ZFS mavjud.
DS: Ammo ZFS bilan siz bitta tugun bilan cheklanasiz.
НС: Ha. Ammo ZFS ham sehrga ega : u bilan siz suratni yuborishingiz mumkin va hatto (men buni hali sinab ko'rmadim, lekin ...) ikkita o'rtasida delta yuborishingiz mumkin PGDATA. Darhaqiqat, bizda bunday vazifalarni hal qilish uchun ko'rib chiqmagan yana bir vositamiz bor. PostgreSQL mavjud , "aqlli" rsync kabi ishlaydi, ko'rish kerak bo'lmagan ko'p narsalarni o'tkazib yuboradi, chunki u erda hech narsa o'zgarmadi. Biz ikkita server o'rtasida tez sinxronizatsiya qilishimiz va xuddi shu tarzda orqaga qaytarishimiz mumkin.
Shunday qilib, ko'proq DBA tomondan, biz siz aytgan narsani qilishimizga imkon beradigan vositani yaratishga harakat qilmoqdamiz: bizda bitta ma'lumotlar bazasi bor, lekin biz bir narsani deyarli bir vaqtning o'zida 50 marta sinab ko'rmoqchimiz.
DS: 50 marta 50 ta Spot nusxasiga buyurtma berishingiz kerakligini anglatadi.
НС: Yo'q, biz hamma narsani bitta mashinada qilamiz.
DS: Agar bu bitta ma'lumotlar bazasi, aytaylik, terabayt bo'lsa, qanday qilib 50 marta kengaytirasiz. Ehtimol, unga shartli 256 GB operativ xotira kerakmi?
НС: Ha, ba'zan sizga ko'p xotira kerak bo'ladi - bu normal holat. Lekin bu hayotdan misol. Ishlab chiqarish mashinasida 96 yadro va 600 GB mavjud. Shu bilan birga, ma'lumotlar bazasi uchun 32 yadro (hozir hatto 16 yadro ham) va 100-120 Gb xotira ishlatiladi.
DS: Va u erda 50 nusxa mos keladimi?
НС: Shunday qilib, faqat bitta nusxa bor, keyin nusxa ko'chirish (ZFS) ishlaydi ... Men sizga batafsilroq aytib beraman.
Misol uchun, bizda 10 TB ma'lumotlar bazasi mavjud. Ular buning uchun disk yasadilar, ZFS ham uning hajmini 30-40 foizga siqdi. Biz yuk testini o'tkazmaganimiz sababli, aniq javob vaqti biz uchun muhim emas: u 2 baravar sekinroq bo'lsin - bu yaxshi.
Biz dasturchilar, QA, DBA va boshqalarga imkoniyat beramiz. 1-2 ipda sinovni o'tkazing. Masalan, ular qandaydir migratsiyani amalga oshirishi mumkin. Bu bir vaqtning o'zida 10 ta yadroni talab qilmaydi - unga 1 ta Postgres backend, 1 yadro kerak. Migratsiya boshlanadi - ehtimol hali ham boshlanadi, keyin ikkinchi yadro ishlatiladi. Bizda 16-32 yadro ajratilgan, shuning uchun 10 kishi bir vaqtning o'zida ishlashi mumkin, muammo yo'q.
Chunki jismonan PGDATA xuddi shunday, biz aslida Postgresni aldayapmiz. Bu hiyla: masalan, 10 ta Postgres bir vaqtning o'zida ishga tushiriladi. Odatda muammo nimada? Ular qo'yishdi , deylik 25%. Shunga ko'ra, bu 200 GB. Siz ulardan uchtadan ko'pini ishga tushira olmaysiz, chunki xotira tugaydi.
Ammo bir nuqtada biz bu kerak emasligini angladik: biz shared_buffers-ni 2 GB ga o'rnatdik. PostgreSQL mavjud , va aslida u ta'sir qiladigan yagona narsa . Biz uni 0,5 TB ga o'rnatdik. Va ular aslida mavjud emasligi ham muhim emas: u rejalarni xuddi mavjud bo'lgandek tuzadi.
Shunga ko'ra, biz qandaydir migratsiyani sinab ko'rganimizda, biz barcha rejalarni to'plashimiz mumkin - ishlab chiqarishda qanday sodir bo'lishini ko'ramiz. U erda soniyalar har xil bo'ladi (sekinroq), lekin biz o'qigan ma'lumotlar va rejalarning o'zlari (qanday JOINlar bor va hokazo) ishlab chiqarishdagi kabi bo'ladi. Va bir mashinada parallel ravishda ko'plab bunday tekshiruvlarni o'tkazishingiz mumkin.
DS: Bu erda bir nechta muammolar bor deb o'ylamaysizmi? Birinchisi, faqat PostgreSQL da ishlaydigan yechim. Bu yondashuv juda shaxsiy, u umumiy emas. Ikkinchisi, Kubernetes (va hozirda bulutli texnologiyalar bo'ladigan barcha narsalar) ko'plab tugunlarni o'z ichiga oladi va bu tugunlar vaqtinchalikdir. Va sizning holatingizda bu statistik, doimiy tugun. Bu narsalar meni ziddiyatga olib keladi.
НС: Birinchidan, men roziman, bu sof Postgres hikoyasi. O'ylaymanki, agar bizda deyarli barcha xotiralar uchun qandaydir to'g'ridan-to'g'ri IO va bufer hovuz bo'lsa, bu yondashuv ishlamaydi - rejalar boshqacha bo'ladi. Ammo hozircha biz faqat Postgres bilan ishlaymiz, boshqalar haqida o'ylamaymiz.
Kubernetes haqida. Siz o'zingiz hamma joyda bizga doimiy ma'lumotlar bazasi borligini aytasiz. Agar misol muvaffaqiyatsiz bo'lsa, asosiy narsa diskni saqlashdir. Bu erda bizda Kubernetes-da butun platforma mavjud va Postgres bilan komponent alohida (garchi u bir kun bo'lsa ham). Shuning uchun hamma narsa shunday: instansiya tushib ketdi, lekin biz uning PV-ni saqlab qoldik va uni boshqa (yangi) misolga uladik, go'yo hech narsa bo'lmagandek.
DS: Mening fikrimcha, biz Kubernetes-da podlarni yaratamiz. K8s - elastik: kerak bo'lganda tugunlar buyurtma qilinadi. Vazifa shunchaki podkast yaratish va unga X miqdordagi resurslar kerakligini aytish, keyin K8s buni o'zi aniqlaydi. Ammo Kubernetes-da saqlashni qo'llab-quvvatlash hali ham beqaror: , in (Ushbu nashr chiqarildi haftaning oldin) bu xususiyatlar faqat beta versiyasiga aylanadi.
Olti oydan bir yilgacha o'tadi - u ko'proq yoki kamroq barqaror bo'ladi yoki hech bo'lmaganda shunday deb e'lon qilinadi. Keyin suratga olish va o'lchamini o'zgartirish imkoniyati muammoingizni to'liq hal qiladi. Chunki sizda baza bor. Ha, bu unchalik tez bo'lmasligi mumkin, lekin tezlik "qopqoq ostidagi" narsaga bog'liq, chunki ba'zi ilovalar disk quyi tizimi darajasida nusxa ko'chirish va yozishni amalga oshirishi mumkin.
НС: Bundan tashqari, barcha dvigatellar (Amazon, Google...) ushbu versiyani qo'llab-quvvatlashni boshlashlari kerak - bu ham biroz vaqt oladi.
DS: Biz ulardan hali foydalanmayapmiz. Biz o'zimiznikini ishlatamiz.
Kubernetes uchun mahalliy rivojlanish
НС: Siz bitta mashinaga barcha podkastlarni o'rnatishingiz va shunday kichik sinovni o'tkazishingiz kerak bo'lganda bunday istak bilan duch kelganmisiz. Kontseptsiyaning isbotini tezda olish uchun dastur Kubernetes-da, buning uchun bir nechta mashinalarni ajratmasdan ishlashiga qarang. Minikube bor, to'g'rimi?
DS: Menimcha, bu ish - bitta tugunga joylashtirilgan - faqat mahalliy rivojlanish bilan bog'liq. Yoki bunday naqshning ba'zi ko'rinishlari. Yemoq , bor , . Biz Kubernetes IN Docker-dan foydalanishga harakat qilmoqdamiz. Endi biz u bilan testlar uchun ishlay boshladik.
НС: Men buni barcha podkastlarni bitta Docker tasviriga o'rashga urinish deb o'ylardim. Ammo bu butunlay boshqa narsa haqida ekanligi ma'lum bo'ldi. Baribir, alohida konteynerlar, alohida podlar bor - faqat Docker-da.
DS: Ha. Va juda kulgili taqlid qilingan, ammo ma'nosi shu ... Bizda joylashtirish uchun yordamchi dastur bor - . Biz uni shartli rejimga aylantirmoqchimiz werf up: "Menga mahalliy Kubernetesni oling." Va keyin u erda shartni bajaring werf follow. Keyin ishlab chiquvchi IDE-ni tahrirlashi mumkin bo'ladi va tizimda o'zgarishlarni ko'radigan va tasvirlarni qayta tiklaydigan, ularni mahalliy K8-larga qayta joylashtiradigan jarayon ishga tushiriladi. Biz mahalliy rivojlanish muammosini ana shunday hal qilishga harakat qilmoqchimiz.
K8s haqiqatida suratlar va ma'lumotlar bazasini klonlash
НС: Agar biz nusxa ko'chirishga qaytsak. Bulutlarda ham suratlar borligini payqadim. Ular boshqacha ishlaydi. Masalan, GCP-da: sizda Amerika Qo'shma Shtatlarining sharqiy qirg'og'ida ko'p terabaytlik nusxangiz bor. Siz vaqti-vaqti bilan suratga olasiz. Siz g'arbiy qirg'oqdagi diskning nusxasini suratga olasiz - bir necha daqiqada hamma narsa tayyor, u juda tez ishlaydi, faqat kesh xotirada to'ldirilishi kerak. Ammo bu klonlar (snapshotlar) yangi hajmni ta'minlash uchun mo'ljallangan. Bu juda ko'p misollar yaratishingiz kerak bo'lganda ajoyib.
Ammo testlar uchun menimcha, siz Docker-da yoki men ZFS-da, btrfs va hatto LVM-da gapiradigan oniy tasvirlar ... - ular bitta mashinada haqiqatan ham yangi ma'lumotlarni yaratmaslikka imkon beradi. Bulutda siz hali ham har safar ular uchun to'laysiz va soniyalar emas, balki daqiqalar (va bu holatda , ehtimol soat).
Buning o'rniga, siz ushbu ma'lumotlarni bir yoki ikki soniya ichida olishingiz, testni o'tkazishingiz va uni tashlashingiz mumkin. Ushbu suratlar turli muammolarni hal qiladi. Birinchi holda - kattalashtirish va yangi nusxalarni olish, ikkinchisida - testlar uchun.
DS: Men rozi emasman. Ovozni klonlashni to'g'ri ishlashi bulutning vazifasidir. Men ularning amalga oshirilishini ko'rib chiqmadim, lekin men buni apparatda qanday qilishimizni bilaman. Bizda Ceph bor, u har qanday jismoniy hajmga imkon beradi () demoq klon va o'nlab millisekundlarda bir xil xususiyatlarga ega ikkinchi jildni oling, 'ami va boshqalar. Ichkarida hiyla-nayrang nusxasi borligini tushunishingiz kerak. Nega bulut ham xuddi shunday qilmasligi kerak? Ishonchim komilki, ular buni u yoki bu tarzda qilishga harakat qilmoqdalar.
НС: Ammo misolni ko'tarish, Dockerni u erga olib kelish va hokazolar uchun ularga soniyalar, o'nlab soniyalar kerak bo'ladi.
DS: Nima uchun butun bir misolni ko'tarish kerak? Bizda 32 yadroli misol bor, 16... va u unga sig'ishi mumkin - masalan, to'rtta. Beshinchisiga buyurtma berganimizda, misol allaqachon ko'tariladi va keyin u o'chiriladi.
НС: Ha, qiziq, Kubernetes boshqacha hikoya bo'lib chiqadi. Bizning ma'lumotlar bazasi K8-da emas va bizda bitta misol bor. Ammo ko'p terabaytli ma'lumotlar bazasini klonlash ikki soniyadan ko'proq vaqtni oladi.
DS: Bu ajoyib. Lekin mening dastlabki fikrim shundaki, bu umumiy yechim emas. Ha, bu ajoyib, lekin u faqat Postgres uchun va faqat bitta tugun uchun mos keladi.
НС: Bu nafaqat Postgres uchun mos: bu rejalar, men ta'riflaganimdek, faqat unda ishlaydi. Ammo agar biz rejalar haqida tashvishlanmasak va biz funktsional test uchun barcha ma'lumotlarga muhtoj bo'lsak, unda bu har qanday DBMS uchun mos keladi.
DS: Ko'p yillar oldin biz LVM snapshotlarida shunga o'xshash narsani qilganmiz. Bu klassik. Ushbu yondashuv juda faol ishlatilgan. Davlat tugunlari shunchaki og'riqdir. Chunki siz ularni tashlab ketmasligingiz kerak, ularni doimo yodda tutishingiz kerak ...
НС: Bu yerda gibrid bo'lish ehtimoli bormi? Aytaylik, davlat ko'rsatkichi qandaydir pod, u bir nechta odamlar uchun ishlaydi (ko'p testerlar). Bizda bitta jild bor, lekin fayl tizimi tufayli klonlar mahalliy. Agar pod yiqilsa-yu, lekin disk qolsa, pod ko'tariladi, barcha klonlar haqidagi ma'lumotlarni hisoblaydi, yana hamma narsani yig'adi va ayt: "Mana, sizning klonlaringiz ushbu portlarda ishlaydi, ular bilan ishlashni davom eting".
DS: Texnik jihatdan bu shuni anglatadiki, Kubernetes ichida biz ko'plab Postgreslarni boshqaradigan bitta pod.
НС: Ha. Uning chegarasi bor: aytaylik, u bilan bir vaqtning o'zida 10 dan ortiq odam ishlamaydi. Agar sizga 20 ta kerak bo'lsa, biz ikkinchi bunday podani ishga tushiramiz. Biz uni to'liq klonlaymiz, ikkinchi to'liq hajmni olganimizdan so'ng, u bir xil 10 ta "nozik" klonga ega bo'ladi. Bu imkoniyatni ko'rmayapsizmi?
DS: Bu yerga xavfsizlik masalalarini qo'shishimiz kerak. Tashkilotning bunday turi ushbu podkastning yuqori imtiyozlarga (imkoniyatlarga) ega ekanligini anglatadi, chunki u fayl tizimida nostandart operatsiyalarni amalga oshirishi mumkin ... Lekin takrorlayman: o'rta muddatda ular Kubernetesda saqlashni tuzatadi, deb ishonaman va bulutlar ular butun voqeani jildlar bilan tuzatadilar - hamma narsa "shunchaki ishlaydi". O‘lchamni o‘zgartirish, klonlash bo‘ladi... Bir jild bor – biz: “Uning asosida yangisini yarating” deymiz va bir yarim soniyadan so‘ng biz kerakli narsani olamiz.
НС: Ko'p terabaytlar uchun bir yarim soniyaga ishonmayman. Cefda siz buni o'zingiz qilasiz, lekin siz bulutlar haqida gapirasiz. Bulutga o'ting, EC2-da ko'p terabaytli EBS hajmining klonini yarating va ishlash qanday bo'lishini ko'ring. Bu bir necha soniya davom etmaydi. Ularning qachon bu darajaga yetishi meni juda qiziqtiradi. Men nima deyotganingizni tushunaman, lekin men boshqacha bo'lishni iltimos qilaman.
DS: Yaxshi, lekin men qisqa muddatda emas, o'rta muddatda aytdim. Bir necha yil davomida.
Zalandodan PostgreSQL uchun operator haqida
Ushbu uchrashuv o'rtasida Zalandodan sobiq dasturchi Aleksey Klyukin ham qo'shildi va PostgreSQL operatorining tarixi haqida gapirdi:
Umuman olganda, bu mavzuga to'xtalib o'tgani juda yaxshi: Postgres ham, Kubernetes ham. Biz buni 2017 yilda Zalandoda qilishni boshlaganimizda, bu hamma qilishni istagan mavzu edi, lekin hech kim qilolmadi. Hamma allaqachon Kubernetesga ega edi, lekin ular ma'lumotlar bazalari bilan nima qilishni so'rashganda, hatto odamlar ham yoqadi , K8larni va'z qilgan, shunday dedi:
“Boshqariladigan xizmatlarga oʻting va ulardan foydalaning, Kubernetes-da maʼlumotlar bazasini ishga tushirmang. Aks holda, sizning K8-laringiz, masalan, yangilanishni amalga oshirishga qaror qiladi, barcha tugunlarni o'chiradi va sizning ma'lumotlaringiz juda uzoqqa uchib ketadi.
Biz ushbu maslahatga zid ravishda Kubernetesda Postgres ma'lumotlar bazasini ishga tushiradigan operatorni yaratishga qaror qildik. Va bizda yaxshi sabab bor edi - . Bu PostgreSQL uchun avtomatik yuklama, to'g'ri bajarilgan, ya'ni. etcd, konsul yoki ZooKeeper-dan klaster haqidagi ma'lumotlarni saqlash sifatida foydalanish. Bunday ombor, masalan, hozirgi rahbar nima, deb so'ragan har bir kishiga bir xil ma'lumotni beradi - bizda hamma narsa taqsimlangan bo'lishiga qaramay - miya bo'linmasligi uchun. Bundan tashqari, bizda bor edi uning uchun.
Umuman olganda, kompaniyaning avtomatik uzilishga bo'lgan ehtiyoji ichki apparat ma'lumotlar markazidan bulutga o'tgandan keyin paydo bo'ldi. Bulut xususiy PaaS (Platform-as-a-Service) yechimiga asoslangan edi. Bu ochiq manba, lekin uni ishga tushirish uchun ko'p mehnat talab qilindi. Bu chaqirildi .
Dastlab, Kubernetes yo'q edi. Aniqrog'i, bizning o'z yechimimiz ishga tushirilganda, K8s allaqachon mavjud edi, lekin u shunchalik xom ediki, u ishlab chiqarish uchun mos emas edi. Menimcha, bu 2015 yoki 2016 yil edi. 2017 yilga kelib Kubernetes ozmi-koʻpmi etuk boʻlib qoldi — u yerga koʻchib oʻtish zarurati tugʻildi.
Va bizda allaqachon Docker konteyneri bor edi. Docker ishlatadigan PaaS mavjud edi. Nega K8-larni sinab ko'rmaysiz? Nega o'z operatoringizni yozmaysiz? Avitodan bizga kelgan Murat Qobilov buni o'z tashabbusi bilan "o'ynash" loyihasi sifatida boshladi va loyiha "boshlandi".
Ammo umuman olganda, men AWS haqida gapirmoqchi edim. Nima uchun tarixiy AWS bilan bog'liq kod bor edi ...
Kubernetes-da biror narsani ishga tushirganingizda, K8s shunday davom etayotgan ish ekanligini tushunishingiz kerak. U doimo rivojlanib, takomillashib, hatto vaqti-vaqti bilan buzilib turadi. Siz Kubernetesdagi barcha o'zgarishlarni diqqat bilan kuzatib borishingiz kerak, agar biror narsa yuz bersa, unga sho'ng'ishga tayyor bo'lishingiz va uning qanday ishlashini batafsil o'rganishingiz kerak - ehtimol siz xohlaganingizdan ham ko'proq. Bu, qoida tariqasida, siz ma'lumotlar bazalarini ishga tushiradigan har qanday platformaga tegishlidir...
Shunday qilib, biz bayonot qilganimizda, bizda Postgres tashqi jildda ishladi (bu holda EBS, chunki biz AWS ustida ishlaganmiz). Ma'lumotlar bazasi o'sdi, bir vaqtning o'zida uning hajmini o'zgartirish kerak edi: masalan, EBS ning dastlabki hajmi 100 TB edi, ma'lumotlar bazasi unga o'sdi, endi biz EBS ni 200 TB qilmoqchimiz. Qanaqasiga? Aytaylik, siz yangi nusxada dump/qayta tiklashni amalga oshirishingiz mumkin, ammo bu uzoq vaqt talab etadi va ishlamay qolish vaqtini o'z ichiga oladi.
Shuning uchun, men EBS bo'limini oshiradigan va keyin fayl tizimiga yangi bo'sh joydan foydalanishni aytadigan o'lchamni o'zgartirishni xohladim. Va biz buni qildik, lekin o'sha paytda Kubernetes o'lchamini o'zgartirish uchun APIga ega emas edi. Biz AWS da ishlaganimiz uchun uning API uchun kod yozdik.
Hech kim sizni boshqa platformalar uchun xuddi shunday qilishingizga to'sqinlik qilmaydi. Bayonotda uni faqat AWS-da ishga tushirish mumkinligi haqida hech qanday ishora yo'q va u hamma narsada ishlamaydi. Umuman olganda, bu Open Source loyihasidir: agar kimdir yangi API-dan foydalanishni tezlashtirishni xohlasa, marhamat. Yemoq , so'rovlarni tortib oling - Zalando jamoasi ularga tezda javob berishga va operatorni targ'ib qilishga harakat qiladi. Bilishimcha, loyiha Google Summer of Code va boshqa shunga o'xshash tashabbuslarda. Zalando bu borada juda faol ishlamoqda.
P.S. Bonus!
Agar siz PostgreSQL va Kubernetes mavzusiga qiziqsangiz, iltimos, keyingi Postgres seshanba kuni o'tgan hafta bo'lib o'tganini, men Nikolay bilan gaplashganimni unutmang. Zalandolik Aleksandr Kukushkin. Undan video mavjud .
PPS
Shuningdek, bizning blogimizda o'qing:
- «";
- «";
- «";
- «".
Manba: www.habr.com