IT sohasida ishlaganingizda, tizimlarning o'ziga xos xususiyati borligini seza boshlaysiz. Ular moslashuvchan, jim, eksantrik va qattiq bo'lishi mumkin. Ular jalb qilishlari yoki qaytarishlari mumkin. Qanday bo'lmasin, siz ular bilan "muzokaralar olib borishingiz", "tuzoqlar" o'rtasida manevr qilishingiz va ularning o'zaro ta'siri zanjirlarini yaratishingiz kerak.
Shunday qilib, biz bulut platformasini yaratish sharafiga muyassar bo'ldik va buning uchun biz bir nechta quyi tizimlarni biz bilan ishlashga "ko'ndirishimiz" kerak edi. Yaxshiyamki, bizda "API tili", to'g'ridan-to'g'ri qo'llar va juda ko'p ishtiyoq bor.
Ushbu maqola texnik jihatdan qiyin bo'lmaydi, lekin bulutni yaratishda biz duch kelgan muammolarni tasvirlab beradi. Men tizimlar bilan umumiy tilni qanday izlaganimiz va undan nima chiqqani haqida engil texnik fantaziya ko'rinishida yo'limizni tasvirlashga qaror qildim.
Mushukga xush kelibsiz.
Safarning boshlanishi
Bir muncha vaqt oldin bizning jamoamizga mijozlarimiz uchun bulutli platformani ishga tushirish vazifasi qo'yildi. Xizmatning dasturiy qismini amalga oshirish uchun texnologiyalarni tanlashda bizda boshqaruv yordami, resurslar, apparat stack va erkinlik bor edi.
Bundan tashqari, bir qator talablar mavjud edi:
- xizmatga qulay shaxsiy hisob kerak;
- platforma mavjud billing tizimiga integratsiyalangan bo'lishi kerak;
- dasturiy ta'minot va apparat: OpenStack + volfram mato (Open Contrail), bizning muhandislarimiz "pishirish" ni juda yaxshi o'rgandilar.
Agar Habra hamjamiyatini qiziqtirsa, jamoa qanday yig'ilgani, shaxsiy hisob interfeysi ishlab chiqilgani va dizayn qarorlari qabul qilingani haqida yana bir bor aytib beramiz.
Biz foydalanishga qaror qilgan vositalar:
- Python + Flask + Swagger + SQLAlchemy - butunlay standart Python to'plami;
- Frontend uchun Vue.js;
- Biz komponentlar va xizmatlar o'rtasidagi o'zaro aloqani AMQP orqali Selderiya yordamida amalga oshirishga qaror qildik.
Python-ni tanlash bo'yicha savollarni oldindan aytib beraman. Til bizning kompaniyamizda o'z o'rnini topdi va uning atrofida kichik, ammo baribir madaniyat rivojlandi. Shu sababli, unga xizmat ko'rsatishni boshlashga qaror qilindi. Bundan tashqari, bunday muammolarda rivojlanish tezligi ko'pincha hal qiluvchi ahamiyatga ega.
Shunday ekan, tanishuvimizni boshlaylik.
Silent Bill - hisob-kitob
Biz bu yigitni anchadan beri bilamiz. U doim yonimda o'tirar va indamay nimanidir sanab yurardi. Ba'zan u bizga foydalanuvchi so'rovlarini yo'naltirdi, mijozlar hisob-fakturalarini berdi va xizmatlarni boshqardi. Oddiy mehnatkash yigit. To'g'ri, qiyinchiliklar bor edi. U jim, ba'zan o'ychan va ko'pincha o'z xayolida.
Billing - bu biz do'stlashishga harakat qilgan birinchi tizim. Va biz duch kelgan birinchi qiyinchilik xizmatlarni qayta ishlashda bo'ldi.
Misol uchun, yaratilgan yoki o'chirilganda, vazifa ichki hisob-kitob navbatiga o'tadi. Shunday qilib, xizmatlar bilan asinxron ishlash tizimi amalga oshiriladi. Xizmat turlarini qayta ishlash uchun biz o'z vazifalarimizni ushbu navbatga "qo'yishimiz" kerak edi. Va bu erda biz muammoga duch keldik: hujjatlarning etishmasligi.
API dasturiy ta'minotining tavsifiga ko'ra, bu muammoni hal qilish hali ham mumkin, ammo bizda teskari muhandislik qilish uchun vaqtimiz yo'q edi, shuning uchun biz mantiqni tashqariga olib chiqdik va RabbitMQ tepasida vazifalar navbatini tashkil qildik. Xizmat bo'yicha operatsiya mijoz tomonidan o'zining shaxsiy kabinetidan boshlanadi, orqa tarafdagi Selderey "topshirigi" ga aylanadi va billing va OpenStack tomonida amalga oshiriladi. Selderey vazifalarni boshqarish, takrorlashni tashkil qilish va holatni kuzatish uchun juda qulay qiladi. Siz "selderey" haqida ko'proq o'qishingiz mumkin, masalan, .
Bundan tashqari, hisob-kitob pulsiz qolgan loyihani to'xtatmadi. Ishlab chiquvchilar bilan muloqot qilib, biz statistikani hisoblashda (va biz aynan shunday mantiqni amalga oshirishimiz kerak) to'xtash qoidalarining murakkab o'zaro bog'liqligi borligini aniqladik. Ammo bu modellar bizning voqeliklarimizga mos kelmaydi. Shuningdek, biz uni Selderey-dagi vazifalar orqali amalga oshirdik, xizmatni boshqarish mantig'ini backend tomoniga o'tkazdik.
Yuqoridagi ikkala muammo kodning biroz shishishiga olib keldi va kelajakda biz vazifalar bilan ishlash mantig'ini alohida xizmatga o'tkazish uchun qayta ishlashga majbur bo'lamiz. Bundan tashqari, ushbu mantiqni qo'llab-quvvatlash uchun jadvallarimizda foydalanuvchilar va ularning xizmatlari haqida ba'zi ma'lumotlarni saqlashimiz kerak.
Yana bir muammo - sukunat.
Billi ba'zi API so'rovlariga jimgina "OK" deb javob beradi. Bu, masalan, test paytida va'da qilingan to'lovlarni amalga oshirganimizda (bu haqda keyinroq). So'rovlar to'g'ri bajarildi va biz hech qanday xato ko'rmadik.
UI orqali tizim bilan ishlashda jurnallarni o'rganishim kerak edi. Ma'lum bo'lishicha, hisob-kitobning o'zi shunga o'xshash so'rovlarni bajaradi, qamrovni ma'lum bir foydalanuvchiga o'zgartiradi, masalan, administrator, uni su parametriga o'tkazadi.
Umuman olganda, hujjatlardagi bo'shliqlar va kichik API kamchiliklariga qaramay, hamma narsa yaxshi o'tdi. Jurnallar qanday tuzilganligini va nimaga e'tibor berish kerakligini tushunsangiz, hatto og'ir yuk ostida ham o'qilishi mumkin. Ma'lumotlar bazasining tuzilishi bezakli, ammo juda mantiqiy va qaysidir ma'noda jozibali.
Xulosa qilib aytganda, o'zaro ta'sir bosqichida biz duch kelgan asosiy muammolar ma'lum bir tizimni amalga oshirish xususiyatlari bilan bog'liq:
- bizga u yoki bu tarzda ta'sir qilgan hujjatsiz "xususiyatlar";
- yopiq manba (hisob-kitob C++ da yozilgan), natijada - 1-muammoni “sinov va xatolik”dan boshqa usul bilan hal qilish mumkin emas.
Yaxshiyamki, mahsulot juda keng API-ga ega va biz quyidagi quyi tizimlarni shaxsiy hisobimizga birlashtirdik:
- texnik qo'llab-quvvatlash moduli - shaxsiy hisobingizdan so'rovlar xizmat ko'rsatuvchi mijozlar uchun shaffof tarzda hisob-kitob qilish uchun "proksi" qilinadi;
- moliyaviy modul - joriy mijozlarga hisob-fakturalar berish, hisobdan chiqarish va to'lov hujjatlarini yaratish imkonini beradi;
- xizmatni boshqarish moduli - buning uchun biz o'z ishlovchimizni amalga oshirishimiz kerak edi. Tizimning kengayishi bizning qo'limizga tushdi va biz Billiga yangi xizmat turini "o'rgatganmiz".
Bu biroz qiyinchilik edi, lekin qandaydir tarzda, menimcha, Billi va men til topishamiz.
Volfram maydonlari bo'ylab yurish - Tungsten mato
Volfram maydonlari yuzlab simlar bilan qoplangan va ular orqali minglab bit ma'lumotlarni o'tkazgan. Ma'lumotlar "paketlarga" to'planadi, tahlil qilinadi, murakkab marshrutlar quriladi, go'yo sehr bilan.
Bu biz do'stlashishimiz kerak bo'lgan ikkinchi tizimning domeni - ilgari OpenContrail bo'lgan Tungsten Fabric (TF). Uning vazifasi foydalanuvchilar sifatida bizga dasturiy mavhumlikni ta'minlab, tarmoq uskunalarini boshqarishdir. TF - SDN, tarmoq uskunalari bilan ishlashning murakkab mantiqini qamrab oladi. Texnologiyaning o'zi haqida yaxshi maqola bor, masalan, .
Tizim Neytron plagini orqali OpenStack (quyida muhokama qilinadi) bilan birlashtirilgan.
OpenStack xizmatlarining o'zaro ta'siri.
Operatsiya bo'limining yigitlari bizni ushbu tizim bilan tanishtirishdi. Biz xizmatlarimizning tarmoq stekini boshqarish uchun tizim API sidan foydalanamiz. Bu bizga hali hech qanday jiddiy muammo yoki noqulaylik tug'dirmadi (men OE yigitlari uchun gapira olmayman), lekin o'zaro munosabatlarda ba'zi g'alatiliklar bor edi.
Birinchisi quyidagicha ko'rindi: SSH orqali ulanishda namuna konsoliga katta hajmdagi ma'lumotlarni chiqarishni talab qiladigan buyruqlar ulanishni shunchaki "to'xtatdi", VNC orqali esa hamma narsa to'g'ri ishladi.
Muammo bilan tanish bo'lmaganlar uchun bu juda kulgili ko'rinadi: ls /root to'g'ri ishlaydi, masalan, tepa butunlay "muzlaydi". Yaxshiyamki, biz ilgari ham shunga o'xshash muammolarga duch kelganmiz. Hisoblash tugunlaridan marshrutizatorlargacha bo'lgan marshrutda MTUni sozlash orqali qaror qabul qilindi. Aytgancha, bu TF muammosi emas.
Keyingi muammo burchakda edi. Bir "chiroyli" lahzada marshrut sehri xuddi shunday yo'qoldi. TF uskunada marshrutlashni boshqarishni to'xtatdi.
Biz Openstack bilan administrator darajasidan ishladik va shundan so'ng kerakli foydalanuvchi darajasiga o'tdik. SDN amallar bajariladigan foydalanuvchi doirasini "o'g'irlash" kabi ko'rinadi. Gap shundaki, TF va OpenStack-ni ulash uchun bir xil administrator hisobi ishlatiladi. Foydalanuvchiga o'tish bosqichida "sehr" g'oyib bo'ldi. Tizim bilan ishlash uchun alohida hisob yaratishga qaror qilindi. Bu bizga integratsiya funksiyasini buzmasdan ishlash imkonini berdi.
Silicon Lifeforms - OpenStack
G'alati shakldagi silikon mavjudot volfram maydonlari yaqinida yashaydi. Eng muhimi, bizni bir tebranish bilan ezib tashlashi mumkin bo'lgan o'sib chiqqan bolaga o'xshaydi, lekin undan hech qanday aniq tajovuz yo'q. Bu qo'rquvni keltirib chiqarmaydi, lekin uning kattaligi qo'rquvni uyg'otadi. Atrofda sodir bo'layotgan voqealarning murakkabligi kabi.
OpenStack bizning platformamizning asosidir.
OpenStack-da bir nechta quyi tizimlar mavjud bo'lib, biz hozirda Nova, Glance va Cinder-dan faol foydalanamiz. Ularning har birida o'z API mavjud. Nova hisoblash resurslari va misollarni yaratish uchun javobgardir, Cinder hajmlar va ularning suratlarini boshqarish uchun mas'uldir, Glance - OS shablonlari va ulardagi metama'lumotni boshqaradigan tasvir xizmati.
Har bir xizmat konteynerda ishlaydi va xabar brokeri "oq quyon" - RabbitMQ.
Bu tizim bizga eng kutilmagan muammolarni keltirdi.
Va biz serverga qo'shimcha hajmni ulashga harakat qilganimizda, birinchi muammo uzoq davom etmadi. Cinder API bu vazifani bajarishdan qat'iyan rad etdi. Aniqrog'i, agar siz OpenStackning o'ziga ishonsangiz, ulanish o'rnatildi, lekin virtual server ichida disk qurilmasi yo'q.
Biz aylanma yo‘ldan borishga qaror qildik va Nova API’dan xuddi shu harakatni talab qildik. Natijada, qurilma to'g'ri ulanadi va server ichida foydalanish mumkin. Muammo blok-saqlash Cinder-ga javob bermasa paydo bo'ladi.
Disklar bilan ishlashda bizni yana bir qiyinchilik kutardi. Tizim tovushini serverdan uzib bo'lmadi.
Yana OpenStack-ning o'zi ulanishni buzganiga "qasam ichadi" va endi siz ovoz balandligi bilan alohida ishlashingiz mumkin. Ammo API diskda operatsiyalarni bajarishni mutlaqo istamadi.
Bu erda biz alohida kurashishga emas, balki xizmat mantig'iga bo'lgan nuqtai nazarimizni o'zgartirishga qaror qildik. Agar misol mavjud bo'lsa, tizim hajmi ham bo'lishi kerak. Shuning uchun, foydalanuvchi hali "server" ni o'chirmasdan tizim "diskini" o'chira olmaydi yoki o'chira olmaydi.
OpenStack - bu o'ziga xos o'zaro ta'sir mantig'i va ajoyib API bilan juda murakkab tizimlar to'plami. Bizga juda batafsil hujjatlar va, albatta, sinov va xatolik yordam beradi (unsiz qaerda bo'lardik).
Sinov jarayoni
O'tgan yilning dekabr oyida biz sinovni o'tkazdik. Asosiy vazifa bizning loyihamizni jangovar rejimda texnik tomondan va UX tomondan sinab ko'rish edi. Tomoshabinlar tanlab taklif qilindi va test yopildi. Biroq, biz veb-saytimizda testga kirishni so'rash imkoniyatini ham qoldirdik.
Sinovning o'zi, albatta, kulgili daqiqalardan xoli emas edi, chunki bu erda bizning sarguzashtlarimiz endi boshlanmoqda.
Birinchidan, biz loyihaga bo'lgan qiziqishni biroz noto'g'ri baholadik va sinov paytida tezda hisoblash tugunlarini qo'shishimiz kerak edi. Klaster uchun odatiy hol, lekin bu erda ham ba'zi nuances bor edi. TF ning ma'lum bir versiyasi uchun hujjatlar vRouter bilan ishlash sinovdan o'tgan yadroning o'ziga xos versiyasini ko'rsatadi. Biz yangi yadrolari bilan tugunlarni ishga tushirishga qaror qildik. Natijada, TF tugunlardan marshrutlarni olmagan. Men yadrolarni zudlik bilan orqaga qaytarishim kerak edi.
Yana bir qiziq narsa shaxsiy hisobingizdagi "parolni o'zgartirish" tugmachasining funksionalligi bilan bog'liq.
Seanslar bilan ishlamaslik uchun shaxsiy hisobimizga kirishni tashkil qilish uchun JWT dan foydalanishga qaror qildik. Tizimlar xilma-xil va keng tarqalganligi sababli, biz o'z tokenimizni boshqaramiz, unda biz hisob-kitoblardan seanslarni va OpenStack tokenidan "o'ramiz". Parol o'zgartirilganda, token, albatta, "yomon bo'ladi", chunki foydalanuvchi ma'lumotlari endi haqiqiy emas va uni qayta chiqarish kerak.
Biz bu nuqtani yo'qotdik va bu qismni tezda tugatish uchun etarli resurslar yo'q edi. Sinovni boshlashdan oldin biz funksionallikni kesib tashlashimiz kerak edi.
Agar parol o'zgartirilgan bo'lsa, biz hozirda foydalanuvchidan chiqamiz.
Ushbu nuanslarga qaramay, sinov yaxshi o'tdi. Bir necha hafta ichida 300 ga yaqin odam to'xtadi. Biz mahsulotga foydalanuvchilar nigohi bilan qarashga, uni amalda sinab ko'rishga va yuqori sifatli fikr-mulohazalarni to'plashga muvaffaq bo'ldik.
Davomi bor
Ko'pchiligimiz uchun bu shunday miqyosdagi birinchi loyiha. Biz qanday qilib jamoa bo'lib ishlash va arxitektura va dizayn qarorlarini qabul qilish haqida bir qancha qimmatli saboqlarni oldik. Kam resurslarga ega bo'lgan murakkab tizimlarni qanday qilib birlashtirish va ularni ishlab chiqarishga yo'naltirish.
Albatta, kod jihatidan ham, tizim integratsiyasi interfeyslarida ham ishlash kerak bo'lgan narsa bor. Loyiha ancha yosh, ammo biz uni ishonchli va qulay xizmatga aylantirish niyatidamiz.
Biz allaqachon tizimlarni ishontira oldik. Bill o'z shkafida hisoblash, hisob-kitob qilish va foydalanuvchi so'rovlarini ehtiyotkorlik bilan bajaradi. Volfram maydonlarining "sehrli" bizni barqaror aloqa bilan ta'minlaydi. Va faqat OpenStack ba'zida injiq bo'lib, "'WSREP hali dasturdan foydalanish uchun tugunni tayyorlamagan" kabi baqiradi. Ammo bu butunlay boshqacha hikoya ...
Biz yaqinda xizmatni ishga tushirdik.
Barcha tafsilotlarni bizning sahifamizda bilib olishingiz mumkin .
CLO ishlab chiqish guruhi
Foydali havolalar
OpenStack
Volfram mato
Manba: www.habr.com