Та мэдээллийн технологийн чиглэлээр ажиллаж байхдаа системүүд өөрийн гэсэн шинж чанартай байдаг гэдгийг анзаарч эхэлдэг. Тэд уян хатан, чимээгүй, хазгай, хатуу байж болно. Тэд татах эсвэл няцаах чадвартай. Ямар нэгэн байдлаар та тэдэнтэй "хэлэлцээр" хийж, "нүдний" хооронд маневр хийж, тэдний харилцан үйлчлэлийн хэлхээг бий болгох хэрэгтэй.
Тиймээс бид үүлэн платформ байгуулах нэр төрийн хэрэг байсан бөгөөд үүний тулд бид хэд хэдэн дэд системийг бидэнтэй хамтран ажиллахыг "ятгах" хэрэгтэй болсон. Аз болоход бид "API хэл", шууд гар, маш их урам зоригтой болсон.
Энэ нийтлэл нь техникийн хувьд хатуу биш боловч үүл бүтээх явцад тулгарч байсан асуудлуудыг тайлбарлах болно. Бид системтэй нийтлэг хэлийг хэрхэн хайж байсан, үүнээс юу гарч ирсэн тухай хөнгөн техникийн уран зөгнөлийн хэлбэрээр бидний замналыг тайлбарлахаар шийдсэн.
Муурт тавтай морил.
Аялалын эхлэл
Хэсэг хугацааны өмнө манай баг үйлчлүүлэгчдэдээ зориулж үүлэн платформыг нэвтрүүлэх үүрэг хүлээсэн. Бид удирдлагын дэмжлэг, нөөц, техник хангамжийн стек, үйлчилгээний програм хангамжийн хэсгийг хэрэгжүүлэх технологийг сонгох эрх чөлөөтэй байсан.
Мөн хэд хэдэн шаардлага тавьсан:
- үйлчилгээнд тохиромжтой хувийн данс хэрэгтэй;
- платформ нь одоо байгаа тооцооны системд нэгдсэн байх ёстой;
- програм хангамж, техник хангамж: Манай инженерүүд нэлээд сайн "хоол хийж" сурсан OpenStack + Гянт болд даавуу (Open Contrail).
Хэрвээ Хабра нийгэмлэг сонирхож байгаа бол багийг хэрхэн цуглуулж, хувийн дансны интерфейсийг боловсруулж, дизайны шийдвэр гаргасан талаар бид өөр нэг удаа танд хэлэх болно.
Бидний ашиглахаар шийдсэн хэрэгслүүд:
- Python + Flask + Swagger + SQLAlchemy - бүрэн стандарт Python багц;
- Frontend-д зориулсан Vue.js;
- Бид AMQP дээр Celery ашиглан бүрэлдэхүүн хэсгүүд болон үйлчилгээний хоорондын харилцан үйлчлэлийг хийхээр шийдсэн.
Python-ийг сонгох тухай асуултуудыг би тайлбарлах болно. Хэл нь манай компанид байр сууриа олж, түүний эргэн тойронд жижиг боловч соёл иргэншил бий болсон. Тиймээс түүн дээр үйлчилгээгээ барьж эхлэхээр болсон. Түүнээс гадна ийм асуудлын хөгжлийн хурд нь ихэвчлэн шийдвэрлэх үүрэг гүйцэтгэдэг.
Ингээд танилцалаа эхэлцгээе.
Чимээгүй Билл - тооцоо
Бид энэ залууг эртнээс мэддэг болсон. Тэр үргэлж миний хажууд суугаад чимээгүйхэн нэг зүйлийг тоолдог байсан. Заримдаа тэр хэрэглэгчийн хүсэлтийг бидэнд дамжуулж, үйлчлүүлэгчийн нэхэмжлэхийг гаргаж, үйлчилгээг удирддаг. Жирийн ажилсаг залуу. Үнэн, бэрхшээлүүд байсан. Тэр чимээгүй, заримдаа бодолтой байдаг бөгөөд ихэнхдээ өөрийнхөөрөө байдаг.
Тооцоолол бол бидний нөхөрлөхийг оролдсон анхны систем юм. Бидэнд тулгарсан хамгийн эхний бэрхшээл бол үйлчилгээг боловсруулах үед байсан.
Жишээлбэл, үүсгэх эсвэл устгах үед даалгавар нь дотоод төлбөрийн дараалалд ордог. Тиймээс үйлчилгээтэй асинхрон ажиллах тогтолцоо хэрэгжиж байна. Үйлчилгээнийхээ төрлүүдийг боловсруулахын тулд бид даалгавраа энэ дараалалд оруулах шаардлагатай болсон. Энд бид асуудалтай тулгарлаа: бичиг баримт дутмаг.
Програм хангамжийн API-ийн тайлбараас харахад энэ асуудлыг шийдэх боломжтой хэвээр байгаа ч бид урвуу инженерчлэл хийж амжаагүй тул логикийг гадаа авч, RabbitMQ дээр ажлын дараалал зохион байгууллаа. Үйлчилгээний үйлдлийг үйлчлүүлэгч өөрийн хувийн данснаас эхлүүлж, арын хэсэгт Celery "даалгавар" болж хувирч, тооцооны болон OpenStack тал дээр хийгддэг. Селөдерей нь даалгавруудыг удирдах, давталтуудыг зохион байгуулах, статусыг хянахад маш тохиромжтой. Та "селөдерей" тухай илүү ихийг уншиж болно, жишээлбэл, .
Мөн мөнгөгүй болсон төслийг төлбөр тооцоо зогсоосонгүй. Хөгжүүлэгчидтэй харилцахдаа бид статистикийг тооцоолохдоо (мөн бид яг ийм логикийг хэрэгжүүлэх хэрэгтэй) зогсоох дүрмийн нарийн төвөгтэй харилцан хамаарал байгааг олж мэдсэн. Гэвч эдгээр загварууд бидний бодит байдалд тохирохгүй байна. Мөн бид үүнийг Celery дээрх даалгавруудаар дамжуулан үйлчилгээний удирдлагын логикийг арын хэсэгт авч хэрэгжүүлсэн.
Дээрх асуудлуудын аль аль нь кодыг бага зэрэг бүдгэрүүлэхэд хүргэсэн бөгөөд ирээдүйд бид даалгавартай ажиллах логикийг тусдаа үйлчилгээ болгон шилжүүлэхийн тулд дахин засварлах шаардлагатай болно. Мөн бид энэ логикийг дэмжихийн тулд хэрэглэгчид болон тэдний үйлчилгээний талаарх зарим мэдээллийг хүснэгтэндээ хадгалах хэрэгтэй.
Өөр нэг асуудал бол чимээгүй байдал юм.
Билли зарим API хүсэлтэд чимээгүйхэн "За" гэж хариулдаг. Жишээлбэл, бид туршилтын үеэр амласан төлбөрийн төлбөрийг хийх үед ийм тохиолдол байсан (энэ талаар дараа нь). Хүсэлтийг зөв гүйцэтгэсэн бөгөөд бид ямар ч алдаа хараагүй.
Би UI-ээр дамжуулан системтэй ажиллахдаа логуудыг судлах шаардлагатай болсон. Төлбөр тооцоо нь өөрөө ижил төстэй хүсэлтийг гүйцэтгэж, хамрах хүрээг тодорхой хэрэглэгч, жишээлбэл админ болгон өөрчилж, su параметрээр дамжуулдаг болох нь тогтоогдсон.
Ерөнхийдөө баримт бичгийн цоорхой, API-ийн бага зэргийн дутагдалтай байсан ч бүх зүйл маш сайн болсон. Бүртгэлүүд хэрхэн бүтэцтэй, юуг анхаарах ёстойг ойлговол их ачаалалтай байсан ч уншиж болно. Мэдээллийн сангийн бүтэц нь гоёмсог, гэхдээ нэлээд логиктой, зарим талаараа сэтгэл татам юм.
Дүгнэж хэлэхэд, харилцан үйлчлэлийн үе шатанд бидний тулгарч буй гол бэрхшээлүүд нь тодорхой системийг хэрэгжүүлэх онцлогтой холбоотой юм.
- бидэнд ямар нэг байдлаар нөлөөлсөн баримтжуулаагүй "онцлогууд";
- хаалттай эх сурвалж (тооцоог C++ хэл дээр бичсэн), үр дүнд нь 1-р асуудлыг "туршилт, алдаа"-аас өөр аргаар шийдвэрлэх боломжгүй юм.
Аз болоход, бүтээгдэхүүн нь нэлээд өргөн API-тэй бөгөөд бид дараах дэд системүүдийг хувийн дансандаа нэгтгэсэн.
- техникийн дэмжлэг үзүүлэх модуль - таны хувийн данснаас ирсэн хүсэлтүүд нь үйлчилгээний үйлчлүүлэгчдэд ил тод төлбөр тооцоо хийх "прокси" болно;
- санхүүгийн модуль - одоогийн үйлчлүүлэгчдэд нэхэмжлэх гаргах, хасалт хийх, төлбөрийн баримт бүрдүүлэх боломжийг олгодог;
- үйлчилгээний хяналтын модуль - үүний тулд бид өөрсдийн зохицуулагчийг хэрэгжүүлэх шаардлагатай болсон. Системийн өргөтгөх чадвар бидний гарт нөлөөлж, бид Биллигийн шинэ төрлийн үйлчилгээг "заасан".
Энэ нь жаахан төвөгтэй байсан, гэхдээ ямар нэг байдлаар Билли бид хоёр эвлэнэ гэж бодож байна.
Гянт болдын талбайн дундуур алхах нь - Вольфрамын даавуу
Гянт болдын талбайнууд нь хэдэн зуун утсаар тасархай, олон мянган бит мэдээллийг дамжуулдаг. Мэдээллийг "пакет" болгон цуглуулж, задлан шинжилж, нарийн төвөгтэй маршрутуудыг ид шидээр хийдэг.
Энэ бол бидний найзууд болох хоёр дахь системийн домэйн юм - Гянт болдын даавуу (TF), өмнө нь OpenContrail. Үүний үүрэг бол сүлжээний тоног төхөөрөмжийг удирдах, хэрэглэгчдэд програм хангамжийн хийсвэр ойлголт өгөх явдал юм. TF - SDN, сүлжээний төхөөрөмжтэй ажиллах нарийн төвөгтэй логикийг багтаасан. Технологийн тухай сайн нийтлэл байна, жишээ нь, .
Систем нь Neutron залгаасаар дамжуулан OpenStack-тай (доор авч үзэх болно) нэгдсэн.
OpenStack үйлчилгээний харилцан үйлчлэл.
Үйл ажиллагааны хэлтсийн залуус бидэнд энэ системийг нэвтрүүлсэн. Бид үйлчилгээнийхээ сүлжээний стекийг удирдахын тулд системийн API-г ашигладаг. Энэ нь бидэнд ямар ч ноцтой асуудал, төвөг учруулаагүй (би OE-ийн залуусын өмнөөс ярьж чадахгүй), гэхдээ харилцан үйлчлэлийн явцад зарим нэг хачирхалтай зүйл байсан.
Эхнийх нь иймэрхүү харагдаж байв: SSH-ээр холбогдох үед консол руу их хэмжээний өгөгдөл гаргах шаардлагатай командууд нь холболтыг зүгээр л "тасалж" байхад VNC-ээр бүх зүйл зөв ажиллаж байсан.
Асуудлыг сайн мэдэхгүй хүмүүст энэ нь нэлээд инээдтэй харагдаж байна: ls /root зөв ажилладаг бол, жишээлбэл, дээд тал нь бүрэн "царцдаг". Аз болоход бид өмнө нь үүнтэй төстэй асуудалтай тулгарч байсан. Тооцооллын зангилаанаас чиглүүлэгч рүү шилжих зам дээр MTU-г тохируулах замаар шийдсэн. Дашрамд хэлэхэд энэ нь TF-ийн асуудал биш юм.
Дараагийн асуудал яг л булан тойронд байсан. Ганцхан "сайхан" агшинд чиглүүлэлтийн ид шид яг үүн шиг алга болсон. TF нь тоног төхөөрөмж дээрх чиглүүлэлтийн удирдлагыг зогсоосон.
Бид админ түвшнээс Openstack-тай ажиллаж, дараа нь шаардлагатай хэрэглэгчийн түвшинд шилжсэн. SDN нь тухайн үйлдлийг гүйцэтгэж буй хэрэглэгчийн хамрах хүрээг "булаан авч" байгаа бололтой. Баримт нь TF болон OpenStack-ийг холбоход ижил админ данс ашигладаг. Хэрэглэгч рүү шилжих алхамд "ид шид" алга болсон. Системтэй ажиллахын тулд тусдаа данс үүсгэхээр шийдсэн. Энэ нь интеграцийн функцийг зөрчихгүйгээр ажиллах боломжийг бидэнд олгосон.
Silicon Lifeforms - OpenStack
Хачирхалтай хэлбэртэй силикон амьтан вольфрамын талбайн ойролцоо амьдардаг. Хамгийн гол нь биднийг нэг савлуураар дарчихаар том болсон хүүхэд шиг харагдавч түүнээс илт түрэмгийлэл гарахгүй. Энэ нь айдас төрүүлдэггүй, харин хэмжээ нь айдас төрүүлдэг. Эргэн тойронд болж буй үйл явдлын нарийн төвөгтэй байдал ч мөн адил.
OpenStack бол манай платформын цөм юм.
OpenStack нь хэд хэдэн дэд системтэй бөгөөд эдгээрээс бид Nova, Glance, Cinder нарыг хамгийн идэвхтэй ашигладаг. Тэд тус бүр өөрийн API-тай. Нова нь тооцооллын нөөц, жишээ үүсгэх, Cinder нь эзлэхүүний хэмжээ болон тэдгээрийн агшин зуурын зургийг удирдах үүрэгтэй, Glance нь үйлдлийн системийн загварууд болон тэдгээрийн метамэдээллийг удирддаг зургийн үйлчилгээ юм.
Үйлчилгээ бүр нь саванд ажилладаг бөгөөд мессежийн брокер нь "цагаан туулай" - RabbitMQ юм.
Энэ систем нь бидэнд хамгийн гэнэтийн бэрхшээлийг өгсөн.
Бид серверт нэмэлт эзлэхүүнийг холбох гэж оролдох үед эхний асуудал гараагүй. Cinder API энэ ажлыг гүйцэтгэхээс эрс татгалзсан. Илүү нарийвчлалтай хэлэхэд, хэрэв та OpenStack-д итгэдэг бол холболт хийгдсэн боловч виртуал сервер дотор дискний төхөөрөмж байхгүй байна.
Бид тойруу замаар явахаар шийдэж, Нова API-аас ижил арга хэмжээ авахыг хүссэн. Үүний үр дүнд төхөөрөмж зөв холбогдож, сервер дотор хандах боломжтой болно. Блок хадгалах нь Cinder-д хариу өгөхгүй байх үед асуудал гардаг бололтой.
Дисктэй ажиллахад өөр нэг бэрхшээл биднийг хүлээж байв. Системийн эзлэхүүнийг серверээс салгаж чадсангүй.
Дахин хэлэхэд OpenStack өөрөө холболтыг устгасан гэж "тангараглаж" байгаа бөгөөд одоо та эзлэхүүнтэй тус тусад нь зөв ажиллах боломжтой боллоо. Гэхдээ API нь дискэн дээр үйлдэл хийхийг огтхон ч хүсээгүй.
Энд бид ялангуяа тулалдах биш, харин үйлчилгээний логикийн талаархи үзэл бодлоо өөрчлөхөөр шийдсэн. Хэрэв жишээ байгаа бол системийн хэмжээ бас байх ёстой. Тиймээс хэрэглэгч "сервер" -ийг устгахгүйгээр системийн "диск" -ийг устгах эсвэл идэвхгүй болгох боломжгүй.
OpenStack бол өөрийн харилцан үйлчлэлийн логик, гоёмсог API бүхий нэлээд төвөгтэй систем юм. Бидэнд нэлээд нарийвчилсан баримт бичиг, мэдээжийн хэрэг туршилт, алдаа (үүнгүйгээр бид хаана байх байсан бэ) тусалдаг.
Туршилтын гүйлт
Бид өнгөрсөн оны арванхоёрдугаар сард туршилтын нээлт хийсэн. Гол ажил бол манай төслийг техникийн болон UX талаас байлдааны горимд турших явдал байв. Үзэгчдийг сонгон урьж, шалгалтыг хаасан. Гэсэн хэдий ч бид вэбсайт дээрээ тест хийх хүсэлт гаргах сонголтыг орхисон.
Туршилт нь мэдээжийн хэрэг хөгжилтэй мөчүүдтэй байсангүй, учир нь эндээс бидний адал явдал дөнгөж эхэлж байна.
Нэгдүгээрт, бид төслийн сонирхлыг зарим талаар буруу үнэлж, туршилтын явцад тооцоолох цэгүүдийг хурдан нэмэх шаардлагатай болсон. Кластерын хувьд нийтлэг тохиолдол боловч энд бас зарим нэг нюансууд байсан. TF-ийн тодорхой хувилбарын баримт бичиг нь vRouter-тэй ажиллахыг туршсан цөмийн тодорхой хувилбарыг заадаг. Бид илүү сүүлийн үеийн цөмтэй зангилаануудыг ажиллуулахаар шийдсэн. Үүний үр дүнд ТФ зангилаанаас маршрут хүлээн аваагүй. Би цөмийг яаралтай эргүүлэх хэрэгтэй болсон.
Өөр нэг сониуч зүйл бол таны хувийн дансны "нууц үг солих" товчлуурын ажиллагаатай холбоотой юм.
Бид сесстэй ажиллахгүйн тулд JWT ашиглан хувийн данс руугаа нэвтрэхээр шийдсэн. Системүүд нь олон янзын бөгөөд өргөн тархсан байдаг тул бид өөрсдийн токеныг удирдаж, төлбөр тооцооноос сесс болон OpenStack-аас токеныг "боож" авдаг. Нууц үг солигдох үед токен нь мэдээжийн хэрэг "муу" болно, учир нь хэрэглэгчийн өгөгдөл хүчингүй болсон тул дахин гаргах шаардлагатай болно.
Бид энэ цэгийг мартсан бөгөөд энэ хэсгийг хурдан дуусгахад хангалттай нөөц байхгүй байсан. Туршилтыг эхлүүлэхийн өмнөхөн бид функцийг хасах хэрэгтэй болсон.
Одоогоор бид нууц үгээ өөрчилсөн бол хэрэглэгчээс гарна.
Эдгээр нюансуудыг үл харгалзан туршилт амжилттай болсон. Хэдэн долоо хоногийн дотор 300 орчим хүн зогсов. Бид бүтээгдэхүүнийг хэрэглэгчдийн нүдээр харж, үйл ажиллагаандаа туршиж, өндөр чанартай санал хүсэлтийг цуглуулж чадсан.
Үргэлжлүүлэх
Бидний олонхын хувьд энэ бол ийм хэмжээний анхны төсөл юм. Бид хэрхэн багаар ажиллах, архитектур, дизайны шийдвэр гаргах талаар хэд хэдэн үнэ цэнэтэй сургамж авсан. Бага нөөцтэй нарийн төвөгтэй системийг хэрхэн нэгтгэж, үйлдвэрлэлд нэвтрүүлэх вэ.
Мэдээжийн хэрэг, кодын хувьд болон системийн интеграцчлалын интерфейсийн аль алинд нь ажиллах зүйл бий. Төсөл нь нэлээд залуу боловч бид үүнийг найдвартай, тохиромжтой үйлчилгээ болгон хөгжүүлэх хүсэл эрмэлзэлээр дүүрэн байна.
Бид аль хэдийн системүүдийг ятгаж чадсан. Билл шүүгээндээ тоолох, тооцоо хийх, хэрэглэгчийн хүсэлтийг хариуцлагатай хариуцдаг. Гянтболдын талбайн "ид шид" нь биднийг тогтвортой харилцаа холбоогоор хангадаг. Зөвхөн OpenStack л заримдаа "'WSREP програмын хэрэглээнд зангилаа бэлдээгүй байна" гэх мэтээр хашгирдаг. Гэхдээ энэ бол огт өөр түүх ...
Бид саяхан уг үйлчилгээг нэвтрүүлсэн.
Та манай сайтаас бүх нарийн ширийн зүйлийг авах боломжтой .
CLO Хөгжлийн баг
Ашигтай холбоосууд
OpenStack програм
Гянт болд даавуу
Эх сурвалж: www.habr.com