Qandaydir tarzda, tarixan, IT sanoati har qanday sababga ko'ra ikkita shartli lagerga bo'lingan: "tarafdor" va "qarshi" bo'lganlar. Bundan tashqari, nizolar mavzusi butunlay o'zboshimchalik bilan bo'lishi mumkin. Qaysi operatsion tizim yaxshiroq: Win yoki Linux? Android yoki iOS smartfonidami? Hamma narsani bulutlarda saqlash kerakmi yoki sovuq RAID omboriga qo'yish va vintlarni seyfga qo'yish kerakmi? PHP foydalanuvchilari dasturchi deb atalishga haqlimi? Bu bahslar, ba'zida, faqat ekzistensial xususiyatga ega va sport qiziqishlaridan boshqa hech qanday asosga ega emas.
Shunday bo'ldiki, konteynerlar va doker va shartli k8-lar bilan sevimli oshxonaning paydo bo'lishi bilan, backendning turli sohalarida yangi imkoniyatlardan foydalanishga "ma'qul" va "qarshi" bahslar boshlandi. (Keling, oldindan band qilaylik, garchi Kubernetes ushbu munozarada ko'pincha orkestr sifatida ko'rsatilsa-da, bu alohida vositani tanlash muhim ahamiyatga ega emas. Buning o'rniga, sizga eng qulay va tanish bo'lgan boshqasini almashtirishingiz mumkin. .)
Va bu bitta tanganing ikki tomoni o'rtasidagi oddiy tortishuv bo'lib tuyuladi. Win va Linux o'rtasidagi abadiy qarama-qarshilik kabi bema'ni va shafqatsiz, unda etarli odamlar o'rtada mavjud. Ammo konteynerlashda hamma narsa juda oddiy emas. Odatda bunday nizolarda o'ng tomon yo'q, lekin ma'lumotlar bazalarini saqlash uchun konteynerlardan "foydalanish" yoki "foydalanmaslik" holatida hamma narsa teskari tomonga aylanadi. Chunki ma’lum ma’noda bu yondashuv tarafdorlari ham, muxoliflari ham haq.
Yorug 'tomoni
Light Side argumentini bir iborada qisqacha ta'riflash mumkin: "Salom, 2k19 derazadan tashqarida!" Bu, albatta, populizmga o'xshaydi, lekin vaziyatni batafsil ko'rib chiqsangiz, uning afzalliklari bor. Keling, ularni tartibga keltiraylik.
Aytaylik, sizda katta veb-loyiha bor. U dastlab mikroservis yondashuvi asosida qurilgan bo'lishi mumkin edi yoki qaysidir nuqtada unga evolyutsion yo'l orqali kelgan - bu juda muhim emas, aslida. Siz bizning loyihamizni alohida mikroservislarga tarqatdingiz, orkestratsiya, yuk balansi va masshtabni o'rnatdingiz. Va endi, toza vijdon bilan, siz yiqilgan serverlarni ko'tarish o'rniga, habra effektlari paytida hamakda mojito ichasiz. Ammo barcha harakatlarda siz izchil bo'lishingiz kerak. Ko'pincha, faqat dasturning o'zi - kod - konteynerlangan. Bizda koddan tashqari yana nima bor?
To'g'ri, ma'lumotlar. Har qanday loyihaning yuragi uning ma'lumotlaridir: bu odatiy DBMS - MySQL, Postgre, MongoDB yoki qidirish uchun ishlatiladigan xotira (ElasticSearch), keshlash uchun kalit-qiymatli xotira - masalan, redis va boshqalar bo'lishi mumkin. Hozirda biz bunday emasmiz. noto'g'ri yozilgan so'rovlar tufayli ma'lumotlar bazasi ishlamay qolganda, biz egri backend amalga oshirish variantlari haqida gapiramiz va buning o'rniga mijoz yuki ostida ushbu ma'lumotlar bazasining xatolarga chidamliligini ta'minlash haqida gapiramiz. Oxir oqibat, biz ilovamizni konteynerga joylashtirganimizda va unga istalgan miqdordagi kiruvchi so'rovlarni qayta ishlash uchun erkin miqyoslash imkonini berganimizda, bu tabiiy ravishda ma'lumotlar bazasiga yukni oshiradi.
Darhaqiqat, ma'lumotlar bazasiga kirish kanali va u ishlaydigan server bizning go'zal konteynerli backendimizda igna ko'ziga aylanadi. Shu bilan birga, konteyner virtualizatsiyasining asosiy motivi strukturaning harakatchanligi va moslashuvchanligi bo'lib, biz uchun mavjud bo'lgan barcha infratuzilma bo'ylab maksimal yuklarni taqsimlashni imkon qadar samarali tashkil qilish imkonini beradi. Ya'ni, agar biz tizimning barcha mavjud elementlarini konteynerga joylashtirmasak va klaster bo'ylab tarqatmasak, biz juda jiddiy xatoga yo'l qo'yamiz.
Nafaqat dasturning o'zi, balki ma'lumotlarni saqlash uchun mas'ul bo'lgan xizmatlarni ham klasterlash ancha mantiqiyroq. Mustaqil ravishda ishlaydigan va yukni k8-larda o'zaro taqsimlaydigan veb-serverlarni klasterlash va joylashtirish orqali biz allaqachon ma'lumotlarni sinxronlashtirish muammosini hal qilmoqdamiz - agar biz ba'zi bir media yoki blog platformasini misol qilib olsak, postlardagi bir xil sharhlar. Har holda, bizda klaster ichidagi, hatto virtual, ma'lumotlar bazasining ExternalService sifatida taqdimoti mavjud. Savol shundaki, ma'lumotlar bazasining o'zi hali klasterlangan emas - kubda joylashtirilgan veb-serverlar alohida aylanadigan statik jangovar ma'lumotlar bazasidan o'zgarishlar haqida ma'lumot oladi.
Qo'lga tushganini sezyapsizmi? Biz yukni taqsimlash va asosiy veb-serverning ishdan chiqishiga yo'l qo'ymaslik uchun k8s yoki Swarm-dan foydalanamiz, lekin biz buni ma'lumotlar bazasi uchun qilmaymiz. Ammo ma'lumotlar bazasi ishlamay qolsa, bizning butun klasterli infratuzilmamiz hech qanday ma'noga ega emas - ma'lumotlar bazasiga kirish xatosini qaytaradigan bo'sh veb-sahifalardan nima foyda?
Shuning uchun odatdagidek nafaqat veb-serverlarni, balki ma'lumotlar bazasi infratuzilmasini ham klasterlash kerak. Faqat shu tarzda biz bir jamoada to'liq ishlaydigan, lekin ayni paytda bir-biridan mustaqil bo'lgan tuzilmani ta'minlashimiz mumkin. Bundan tashqari, agar bizning orqa qismimizning yarmi yuk ostida "yiqilib tushsa" ham, qolganlari omon qoladi va klaster ichidagi ma'lumotlar bazalarini bir-biri bilan sinxronlashtirish tizimi va yangi klasterlarni cheksiz miqyoslash va joylashtirish qobiliyati kerakli quvvatga tezda erishishga yordam beradi - ma'lumotlar markazida faqat raflar bo'lsa.
Bundan tashqari, klasterlarda taqsimlangan ma'lumotlar bazasi modeli sizga aynan shu ma'lumotlar bazasini kerakli joyga olib borish imkonini beradi; Agar biz global xizmat haqida gapiradigan bo'lsak, unda San-Fransisko hududidagi biron bir joyda veb-klasterni aylantirish va shu bilan birga Moskva viloyatidagi ma'lumotlar bazasiga kirishda va orqaga paketlarni yuborish mantiqqa to'g'ri kelmaydi.
Shuningdek, ma'lumotlar bazasini konteynerlashtirish tizimning barcha elementlarini bir xil darajada abstraktsiya qilish imkonini beradi. Bu esa, o'z navbatida, ma'murlarning faol ishtirokisiz ushbu tizimni to'g'ridan-to'g'ri koddan, ishlab chiquvchilar tomonidan boshqarish imkonini beradi. Ishlab chiquvchilar yangi kichik loyiha uchun alohida DBMS kerak deb o'ylashdi - oson! yaml faylini yozdi, uni klasterga yukladi va ish tugadi.
Va, albatta, ichki operatsiya juda soddalashtirilgan. Ayting-chi, yangi jamoa a'zosi ish uchun jangovar ma'lumotlar bazasiga qo'llarini qo'yganida, ko'zingizni necha marta yumdingiz? Qaysi biri sizda bor va hozir aylanayotgan yagona? Albatta, bu erda biz hammamiz kattalarmiz va qayerdadir bizda yangi zaxiramiz bor, hatto undan uzoqroqda - buvisining bodringlari va eski chang'ilari solingan tokchaning orqasida - yana bir zaxira, ehtimol hatto muzlatgichda ham, chunki sizning ofisingiz bir marta yonib ketgan edi. Ammo baribir, jangovar infratuzilmaga va, albatta, jangovar ma'lumotlar bazasiga kirish imkoniga ega bo'lgan yangi jamoa a'zosining har bir kiritilishi atrofdagilar uchun validol chelakidir. Xo'sh, uni kim taniydi, yangi boshlovchi, balki u qo'lini kesib o'tgandir? Bu qo'rqinchli, siz rozi bo'lasiz.
Konteynerlashtirish va, aslida, loyihangiz ma'lumotlar bazasining taqsimlangan jismoniy topologiyasi bunday tasdiqlovchi daqiqalardan qochishga yordam beradi. Yangi boshlanuvchiga ishonmaysizmi? KELISHDIKMI! Keling, unga ishlash uchun o'z klasterini beraylik va ma'lumotlar bazasini boshqa klasterlardan ajratamiz - sinxronlash faqat qo'lda surish va ikkita tugmachani sinxron aylantirish (biri jamoa rahbari, ikkinchisi administrator uchun). Va hamma baxtli.
Va endi ma'lumotlar bazasini klasterlashning muxoliflariga aylanish vaqti keldi.
Qorong'u tomoni
Nega ma'lumotlar bazasini saqlash va uni bitta markaziy serverda ishlashni davom ettirish kerak emasligi haqida bahslashar ekanmiz, biz pravoslavlarning ritorikasiga va "bobolarimiz ma'lumotlar bazalarini apparatda boshqargan, biz ham shunday qilamiz!" Buning o'rniga, konteynerlashtirish haqiqatan ham sezilarli dividendlar to'laydigan vaziyatni o'ylab ko'raylik.
Qabul qiling, chindan ham konteynerda poydevorga muhtoj bo'lgan loyihalarni eng yaxshi frezalashtiruvchi operator emas, balki bir qo'lning barmoqlari bilan sanash mumkin. Ko'pincha, hatto k8s yoki Docker Swarm-dan foydalanishning o'zi ham ortiqcha - bu vositalar ko'pincha texnologiyalarning umumiy shov-shuvi va "qudratli" jinslar shaxsidagi munosabatlari tufayli hamma narsani o'z ichiga oladi. bulutlar va konteynerlar. Xo'sh, chunki endi bu moda va hamma buni qiladi.
Hech bo'lmaganda yarmida loyihada Kubernetis yoki shunchaki Docker-dan foydalanish ortiqcha. Muammo shundaki, mijozning infratuzilmasini saqlash uchun yollangan barcha jamoalar yoki autsorsing kompaniyalari buni bilishmaydi. Konteynerlar qo'yilganda yomonroq, chunki u mijozga ma'lum miqdordagi tangalarni oladi.
Umuman olganda, doker/kub mafiyasi ushbu infratuzilma muammolarini autsorsing qilgan mijozlarni ahmoqona ravishda ezadi, degan fikr bor. Axir, klasterlar bilan ishlash uchun bizga bunga qodir bo'lgan va umuman amalga oshirilgan yechim arxitekturasini tushunadigan muhandislar kerak. Biz bir marta Respublika nashri bilan ishimizni tasvirlab bergan edik - u erda biz mijoz jamoasini Kubernetis haqiqatlarida ishlashga o'rgatgan edik va hamma mamnun edi. Va bu munosib edi. Ko'pincha, k8s "tatbiq etuvchilari" mijozning infratuzilmasini garovga olishadi - chunki endi u erda hamma narsa qanday ishlashini faqat ular tushunishadi, mijoz tomonida mutaxassislar yo'q.
Endi tasavvur qiling-a, biz shu tarzda nafaqat veb-server qismini, balki ma'lumotlar bazasiga texnik xizmat ko'rsatishni ham autsorsing qilamiz. Biz BD yurak ekanligini va yurakning yo'qolishi har qanday tirik organizm uchun halokatli ekanligini aytdik. Muxtasar qilib aytganda, istiqbollar eng yaxshi emas. Shunday qilib, Kubernetis shov-shuvi o'rniga, ko'plab loyihalar AWS uchun oddiy tarif bilan bezovtalanmasligi kerak, bu ularning saytida/loyihalarida yuklanish bilan bog'liq barcha muammolarni hal qiladi. Ammo AWS endi moda emas va ko'rgazmalar puldan qimmatroq - afsuski, IT muhitida ham.
KELISHDIKMI. Ehtimol, loyiha haqiqatan ham klasterlashni talab qiladi, lekin agar fuqaroligi bo'lmagan ilovalar bilan hamma narsa aniq bo'lsa, unda klasterli ma'lumotlar bazasi uchun munosib tarmoq ulanishini qanday tashkil qilishimiz mumkin?
Agar biz uzluksiz muhandislik yechimi haqida gapiradigan bo'lsak, ya'ni k8s ga o'tish nima bo'lsa, unda bizning asosiy bosh og'rig'imiz klasterlangan ma'lumotlar bazasida ma'lumotlarni replikatsiya qilishdir. Ba'zi DBMSlar dastlab o'zlarining individual nusxalari o'rtasida ma'lumotlarni taqsimlashga sodiqdirlar. Ko'pchilik boshqalarni unchalik xush ko'rmaydi. Va ko'pincha bizning loyihamiz uchun ma'lumotlar bazasini tanlashda asosiy dalil minimal resurs va muhandislik xarajatlari bilan takrorlash qobiliyati emas. Ayniqsa, agar loyiha dastlab mikroservis sifatida rejalashtirilmagan bo'lsa, lekin shunchaki shu yo'nalishda rivojlangan bo'lsa.
Tarmoq drayverlarining tezligi haqida gapirishning hojati yo'q deb o'ylaymiz - ular sekin. Bular. Agar biror narsa yuz bersa, bizda hali ko'proq, masalan, protsessor kuchi yoki bo'sh RAM mavjud bo'lgan joyda DBMS nusxasini qayta ishga tushirish uchun haqiqiy imkoniyat yo'q. Biz juda tez virtuallashtirilgan disk quyi tizimining ishlashi bilan shug'ullanamiz. Shunga ko'ra, DBMS yaqin joyda joylashgan shaxsiy shaxsiy mashinalar to'plamiga mixlangan bo'lishi kerak. Yoki taxmin qilingan zaxiralar uchun ma'lumotlarning etarlicha tez sinxronizatsiyasini qandaydir tarzda alohida sovutish kerak.
Virtual fayl tizimlari mavzusini davom ettirish: Docker hajmlari, afsuski, muammosiz emas. Umuman olganda, uzoq muddatli ishonchli ma'lumotlarni saqlash kabi masalada men texnik jihatdan eng oddiy sxemalar bilan shug'ullanmoqchiman. Va konteynerning FS-dan ota-xost FS-ga yangi abstraksiya qatlamini qo'shish o'z-o'zidan xavf tug'diradi. Ammo konteynerlashtirishni qo'llab-quvvatlash tizimining ishlashi ushbu qatlamlar o'rtasida ma'lumotlarni uzatishda qiyinchiliklarga duch kelganda, bu haqiqatan ham falokat. Ayni damda ilg‘or insoniyatga ma’lum bo‘lgan muammolarning aksariyati bartaraf etilgandek. Ammo tushunasizki, mexanizm qanchalik murakkab bo'lsa, uni buzish osonroq bo'ladi.
Ushbu "sarguzashtlar" ni hisobga olgan holda, ma'lumotlar bazasini bir joyda saqlash ancha foydali va osonroq bo'ladi va agar siz ilovani konteynerga joylashtirishingiz kerak bo'lsa ham, uni o'z-o'zidan ishga tushirishga ruxsat bering va tarqatish shlyuzi orqali bir vaqtning o'zida aloqani qabul qiling. ma'lumotlar bazasi, u faqat bir marta va bir joyda o'qiladi va yoziladi. Ushbu yondashuv xatolar va desinxronizatsiya ehtimolini minimal darajaga tushiradi.
Biz nimaga olib kelyapmiz? Bundan tashqari, ma'lumotlar bazasini konteynerizatsiya qilish haqiqatan ham zarurat tug'ilganda mos keladi. Siz to'liq ilova ma'lumotlar bazasini to'ldirib, uni yigirmalab mikroservislaringiz bordek aylantira olmaysiz - bu shunday ishlamaydi. Va buni aniq tushunish kerak.
Chiqish o'rniga
Agar siz "ma'lumotlar bazasini virtualizatsiya qilish yoki yo'q" degan aniq xulosani kutayotgan bo'lsangiz, biz sizni xafa qilamiz: bu erda bo'lmaydi. Chunki har qanday infratuzilma yechimini yaratishda moda va taraqqiyotga emas, eng avvalo, sog‘lom fikrga asoslanish kerak.
Kubernetis bilan birga keladigan printsiplar va vositalar juda mos keladigan loyihalar mavjud va bunday loyihalarda hech bo'lmaganda orqa tomonda tinchlik bo'ladi. Va shunday loyihalar mavjudki, ular konteynerlashtirishni emas, balki oddiy server infratuzilmasini talab qiladi, chunki ular tubdan mikroservis klaster modeliga o'zgartira olmaydi, chunki ular tushib ketadi.
Manba: www.habr.com