Bir bulutli - Odnoklassniki-dagi ma'lumotlar markazi darajasidagi OS

Assalomu alaykum, odamlar! Mening ismim Oleg Anastasyev, men Odnoklassniki-da Platforma jamoasida ishlayman. Mendan tashqari, Odnoklassnikida juda ko'p apparat ishlaydi. Bizda 500 mingdan ortiq serverga ega 8 ga yaqin stendga ega to'rtta ma'lumot markazlari mavjud. Muayyan nuqtada biz yangi boshqaruv tizimini joriy etish uskunani yanada samaraliroq yuklash, kirishni boshqarishni osonlashtirish, hisoblash resurslarini (qayta) taqsimlashni avtomatlashtirish, yangi xizmatlarni ishga tushirishni tezlashtirish va javoblarni tezlashtirish imkonini berishini angladik. katta miqyosdagi baxtsiz hodisalarga.

Undan nima keldi?

Men va bir qator apparat vositalaridan tashqari, ushbu uskuna bilan ishlaydigan odamlar ham bor: to'g'ridan-to'g'ri ma'lumotlar markazlarida joylashgan muhandislar; tarmoq dasturiy ta'minotini o'rnatgan tarmoqchilar; infratuzilmaning barqarorligini ta'minlovchi ma'murlar yoki SRElar; va ishlab chiqish guruhlari, ularning har biri portal funktsiyalarining bir qismi uchun javobgardir. Ular yaratgan dasturiy ta'minot quyidagicha ishlaydi:

Foydalanuvchilarning so'rovlari asosiy portalning ikkala tomonida ham qabul qilinadi www.ok.ru, va boshqalarda, masalan, musiqa API jabhalarida. Biznes mantig'ini qayta ishlash uchun ular dastur serverini chaqirishadi, ular so'rovni qayta ishlashda kerakli ixtisoslashgan mikroservislarni chaqiradi - bitta grafik (ijtimoiy ulanishlar grafigi), foydalanuvchi keshi (foydalanuvchi profillari keshi) va boshqalar.

Ushbu xizmatlarning har biri ko'plab mashinalarda joylashtirilgan va ularning har birida modullarning ishlashi, ularning ishlashi va texnologik rivojlanishi uchun mas'ul ishlab chiquvchilar mavjud. Ushbu xizmatlarning barchasi apparat serverlarida ishlaydi va yaqin vaqtgacha biz har bir serverga bitta vazifani ishga tushirdik, ya'ni u ma'lum bir vazifa uchun ixtisoslashgan edi.

Nega bunday? Ushbu yondashuv bir qator afzalliklarga ega edi:

• Yengillashgan ommaviy boshqaruv. Aytaylik, vazifa ba'zi kutubxonalar, ba'zi sozlamalarni talab qiladi. Va keyin server aniq bitta guruhga tayinlanadi, ushbu guruh uchun cfengine siyosati tavsiflanadi (yoki u allaqachon tasvirlangan) va bu konfiguratsiya markaziy va avtomatik ravishda ushbu guruhdagi barcha serverlarga tarqatiladi.
• Soddalashtirilgan diagnostikasi. Aytaylik, siz markaziy protsessorda ortib borayotgan yukni ko'rib chiqasiz va bu yuk faqat ushbu apparat protsessorida ishlaydigan vazifa tomonidan yaratilishi mumkinligini tushunasiz. Kimnidir ayblash uchun qidiruv juda tez tugaydi.
• Soddalashtirilgan monitoring. Agar serverda biror narsa noto'g'ri bo'lsa, monitor bu haqda xabar beradi va siz kim aybdorligini aniq bilasiz.

Bir nechta replikalardan iborat xizmatga bir nechta serverlar ajratilgan - har biri uchun bittadan. Keyin xizmat uchun hisoblash resursi juda sodda tarzda taqsimlanadi: xizmatda mavjud bo'lgan serverlar soni, u iste'mol qilishi mumkin bo'lgan maksimal resurslar miqdori. Bu erda "oson" foydalanish oson degani emas, balki resurslarni taqsimlash qo'lda amalga oshiriladi degan ma'noda.

Bu yondashuv bizga ham imkon berdi maxsus temir konfiguratsiyalar ushbu serverda ishlaydigan vazifa uchun. Agar vazifa katta hajmdagi ma'lumotlarni saqlasa, u holda biz 4 diskli shassili 38U serverdan foydalanamiz. Agar vazifa faqat hisoblash bo'lsa, biz arzonroq 1U server sotib olamiz. Bu hisoblash jihatidan samarali. Boshqa narsalar qatorida, bu yondashuv bizga bitta do'stona ijtimoiy tarmoq bilan taqqoslanadigan yuk bilan to'rt baravar kamroq mashinalardan foydalanishga imkon beradi.

Hisoblash resurslaridan foydalanishda bunday samaradorlik iqtisodiy samaradorlikni ham ta'minlashi kerak, agar eng qimmat narsa bu serverlar degan fikrdan kelib chiqadigan bo'lsak. Uzoq vaqt davomida apparat eng qimmat bo'lgan va biz uskunaning ishonchliligi talablarini kamaytirish uchun xatolarga chidamlilik algoritmlarini ishlab chiqib, uskunaning narxini pasaytirish uchun ko'p kuch sarfladik. Va bugun biz server narxi hal qiluvchi bo'lishni to'xtatgan bosqichga yetdik. Agar siz eng so'nggi ekzotiklarni hisobga olmasangiz, u holda rafdagi serverlarning o'ziga xos konfiguratsiyasi muhim emas. Endi bizda yana bir muammo bor - ma'lumotlar markazidagi server egallagan joyning narxi, ya'ni rafdagi joy.

Bu shunday ekanligini tushunib, biz raflardan qanchalik samarali foydalanayotganimizni hisoblashga qaror qildik.
Biz iqtisodiy jihatdan asosli serverlardan eng kuchli serverning narxini oldik, qancha serverlarni stendlarga joylashtirishimiz mumkinligini, eski "bitta server = bitta vazifa" modeli asosida ularda qancha vazifalarni bajarishimiz mumkinligini va qancha ekanligini hisobladik. vazifalar uskunadan foydalanishi mumkin. Ular sanab, ko'z yoshlarini to'kishdi. Ma'lum bo'lishicha, raflardan foydalanish samaradorligimiz taxminan 11% ni tashkil qiladi. Xulosa aniq: biz ma'lumotlar markazlaridan foydalanish samaradorligini oshirishimiz kerak. Yechim aniq ko'rinadi: siz bir vaqtning o'zida bir serverda bir nechta vazifalarni bajarishingiz kerak. Ammo bu erda qiyinchiliklar boshlanadi.

Ommaviy konfiguratsiya keskin murakkablashadi - endi serverga biron bir guruhni tayinlash mumkin emas. Axir, endi bitta serverda turli xil buyruqlarning bir nechta vazifalari ishga tushirilishi mumkin. Bundan tashqari, konfiguratsiya turli ilovalar uchun ziddiyatli bo'lishi mumkin. Tashxis ham murakkablashadi: agar serverda protsessor yoki disk iste'moli ortib borayotganini ko'rsangiz, qaysi vazifa muammo tug'dirayotganini bilmaysiz.

Lekin asosiysi, bitta mashinada ishlaydigan vazifalar o'rtasida hech qanday izolyatsiya yo'q. Bu erda, masalan, bitta serverda boshqa hisoblash ilovasi ishga tushirilgunga qadar va keyin server topshirig'ining o'rtacha javob vaqtining grafigi, birinchisiga hech qanday aloqasi yo'q - asosiy vazifaning javob vaqti sezilarli darajada oshdi.

Shubhasiz, siz vazifalarni konteynerlarda yoki virtual mashinalarda bajarishingiz kerak. Bizning deyarli barcha vazifalarimiz bitta OS (Linux) ostida ishlaganligi yoki unga moslashtirilganligi sababli, biz ko'plab turli xil operatsion tizimlarni qo'llab-quvvatlashimiz shart emas. Shunga ko'ra, virtualizatsiya kerak emas, qo'shimcha xarajatlar tufayli u konteynerlashtirishdan kamroq samarali bo'ladi.

To'g'ridan-to'g'ri serverlarda vazifalarni bajarish uchun konteynerlarni amalga oshirish sifatida Docker yaxshi nomzod: fayl tizimi tasvirlari ziddiyatli konfiguratsiyalar bilan bog'liq muammolarni yaxshi hal qiladi. Tasvirlarning bir nechta qatlamlardan iborat bo'lishi bizga umumiy qismlarni alohida asosiy qatlamlarga ajratib, ularni infratuzilmada joylashtirish uchun zarur bo'lgan ma'lumotlar miqdorini sezilarli darajada kamaytirish imkonini beradi. Keyin asosiy (va eng katta) qatlamlar butun infratuzilma bo'ylab juda tez keshlanadi va ko'plab turdagi ilovalar va versiyalarni etkazib berish uchun faqat kichik qatlamlarni o'tkazish kerak bo'ladi.

Bundan tashqari, Docker-da tayyor ro'yxatga olish kitobi va tasvirlarni belgilash bizga kodni ishlab chiqarishga versiyalashtirish va etkazib berish uchun tayyor primitivlarni beradi.

Docker, boshqa shunga o'xshash texnologiyalar singari, bizni qutidan tashqarida konteyner izolyatsiyasining bir darajasini ta'minlaydi. Masalan, xotira izolyatsiyasi - har bir konteynerga mashina xotirasidan foydalanish chegarasi beriladi, undan tashqarida u iste'mol qilmaydi. Bundan tashqari, protsessordan foydalanish asosida konteynerlarni ajratishingiz mumkin. Biroq, biz uchun standart izolyatsiya etarli emas edi. Ammo quyida bu haqda ko'proq.

Serverlarda to'g'ridan-to'g'ri ishlaydigan konteynerlar muammoning faqat bir qismidir. Boshqa qismi serverlarda konteynerlarni joylashtirish bilan bog'liq. Qaysi konteynerni qaysi serverga joylashtirish mumkinligini tushunishingiz kerak. Bu unchalik oson ish emas, chunki konteynerlar tezligini kamaytirmasdan serverlarga iloji boricha zichroq joylashtirilishi kerak. Bunday joylashtirish xatolarga chidamlilik nuqtai nazaridan ham qiyin bo'lishi mumkin. Ko'pincha biz bir xil xizmatning nusxalarini turli tokchalarga yoki hatto ma'lumotlar markazining turli xonalariga joylashtirishni xohlaymiz, shunda raf yoki xona ishlamay qolsa, biz barcha xizmat nusxalarini darhol yo'qotmasligimiz kerak.

8 ming server va 8-16 ming konteyner bo'lsa, konteynerlarni qo'lda tarqatish mumkin emas.

Bundan tashqari, biz ishlab chiquvchilarga resurslarni taqsimlashda ko'proq mustaqillik berishni xohladik, shunda ular o'z xizmatlarini ishlab chiqarishda administrator yordamisiz joylashtirishlari mumkin edi. Shu bilan birga, ba'zi bir kichik xizmatlar bizning ma'lumotlar markazlarimiz resurslarini iste'mol qilmasligi uchun biz nazoratni saqlab qolmoqchi edik.

Shubhasiz, bizga buni avtomatik ravishda bajaradigan boshqaruv qatlami kerak.

Shunday qilib, biz barcha me'morlar sevadigan oddiy va tushunarli rasmga keldik: uchta kvadrat.

bir bulutli ustalar bulutli orkestratsiya uchun mas'ul bo'lgan muvaffaqiyatsiz klasterdir. Ishlab chiquvchi ustaga manifest yuboradi, unda xizmatni joylashtirish uchun zarur bo'lgan barcha ma'lumotlar mavjud. Unga asoslanib, usta tanlangan minionlarga (konteynerlarni ishlatish uchun mo'ljallangan mashinalar) buyruqlar beradi. Minionlarda bizning agentimiz bor, u buyruqni oladi, Docker-ga buyruqlar beradi va Docker tegishli konteynerni ishga tushirish uchun Linux yadrosini sozlaydi. Buyruqlarni bajarishdan tashqari, agent doimiy ravishda minion mashinasi va unda ishlaydigan konteynerlar holatidagi o'zgarishlar haqida ustaga hisobot beradi.

Raspredelenie resurs

Keling, ko'plab minionlar uchun yanada murakkabroq resurslarni taqsimlash muammosini ko'rib chiqaylik.

Bitta bulutdagi hisoblash resursi:

• Muayyan vazifa uchun iste'mol qilinadigan protsessor quvvati miqdori.
• Vazifa uchun mavjud xotira miqdori.
• Tarmoq trafigi. Minionlarning har biri cheklangan tarmoqli kengligi bilan o'ziga xos tarmoq interfeysiga ega, shuning uchun ular tarmoq orqali uzatadigan ma'lumotlar miqdorini hisobga olmasdan vazifalarni tarqatish mumkin emas.
• Disklar. Bundan tashqari, shubhasiz, ushbu vazifalar uchun bo'sh joyga biz disk turini ham ajratamiz: HDD yoki SSD. Disklar soniyada cheklangan miqdordagi so'rovlarga xizmat qilishi mumkin - IOPS. Shuning uchun, bitta diskdan ko'ra ko'proq IOPS ishlab chiqaradigan vazifalar uchun biz "shpindellar" ni ham ajratamiz, ya'ni faqat vazifa uchun ajratilishi kerak bo'lgan disk qurilmalari.

Keyin ba'zi bir xizmat uchun, masalan, foydalanuvchi keshi uchun biz iste'mol qilingan resurslarni shu tarzda qayd etishimiz mumkin: 400 protsessor yadrosi, 2,5 TB xotira, har ikki yo'nalishda 50 Gbit/s trafik, 6 shpindelda joylashgan 100 TB HDD maydoni. Yoki shunga o'xshash tanish shaklda:

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

Foydalanuvchi kesh xizmati resurslari ishlab chiqarish infratuzilmasidagi barcha mavjud resurslarning faqat bir qismini iste'mol qiladi. Shuning uchun, men to'satdan, operator xatosi yoki yo'qligi sababli, foydalanuvchi keshi unga ajratilganidan ko'proq resurslarni iste'mol qilmasligiga ishonch hosil qilmoqchiman. Ya'ni resurslarni cheklashimiz kerak. Lekin biz kvotani nimaga bog'lashimiz mumkin?

Keling, komponentlarning o'zaro ta'sirining juda soddalashtirilgan diagrammasiga qaytaylik va uni batafsilroq tafsilotlar bilan qayta chizamiz - shunga o'xshash:

Sizning e'tiboringizni nima tortadi:

• Veb frontend va musiqa bir xil dastur serverining ajratilgan klasterlaridan foydalanadi.
• Biz ushbu klasterlar tegishli bo'lgan mantiqiy qatlamlarni ajrata olamiz: frontlar, keshlar, ma'lumotlarni saqlash va boshqarish darajasi.
• Frontend heterojen bo'lib, u turli funktsional quyi tizimlardan iborat.
• Keshlar, shuningdek, ma'lumotlar keshlangan quyi tizim bo'ylab tarqalishi mumkin.

Keling, rasmni qayta chizamiz:

Bah! Ha, biz ierarxiyani ko'ramiz! Bu siz resurslarni kattaroq qismlarga taqsimlashingiz mumkin degan ma'noni anglatadi: ushbu ierarxiyaning funktsional quyi tizimga mos keladigan tuguniga mas'ul ishlab chiquvchini tayinlang (rasmdagi "musiqa" kabi) va ierarxiyaning bir xil darajasiga kvota qo'shing. Ushbu ierarxiya, shuningdek, boshqaruv qulayligi uchun xizmatlarni yanada moslashuvchan tashkil qilish imkonini beradi. Misol uchun, biz butun vebni ajratamiz, chunki bu juda katta serverlar guruhi, rasmda group1, group2 sifatida ko'rsatilgan bir nechta kichikroq guruhlarga bo'linadi.

Qo'shimcha chiziqlarni olib tashlash orqali biz rasmimizning har bir tugunini tekisroq shaklda yozishimiz mumkin: group1.web.front, api.music.front, user-cache.cache.

Shunday qilib, biz "ierarxik navbat" tushunchasiga kelamiz. U "group1.web.front" kabi nomga ega. Unga resurslar va foydalanuvchi huquqlari uchun kvota tayinlangan. Biz DevOps-dan kelgan odamga navbatga xizmat yuborish huquqini beramiz va bunday xodim navbatda biror narsani ishga tushirishi mumkin va OpsDev-dan kelgan odam administrator huquqlariga ega bo'ladi va endi u navbatni boshqarishi, u erda odamlarni tayinlashi mumkin, bu odamlarga huquqlar berish va hokazo. Bu navbatda ishlaydigan xizmatlar navbat kvotasi doirasida ishlaydi. Agar navbatning hisoblash kvotasi barcha xizmatlarni bir vaqtning o'zida bajarish uchun etarli bo'lmasa, u holda ular ketma-ket bajariladi va shu bilan navbatning o'zini tashkil qiladi.

Keling, xizmatlarni batafsil ko'rib chiqaylik. Xizmat har doim navbat nomini o'z ichiga olgan to'liq nomga ega. Keyin oldingi veb-xizmat nomiga ega bo'ladi ok-web.group1.web.front. Va u kiradigan dastur serveri xizmati chaqiriladi ok-app.group1.web.front. Har bir xizmat ma'lum bir mashinaga joylashtirish uchun barcha kerakli ma'lumotlarni ko'rsatadigan manifestga ega: bu vazifa qancha resurslarni sarflaydi, buning uchun qanday konfiguratsiya kerak, qancha replika bo'lishi kerak, ushbu xizmatning nosozliklarini hal qilish xususiyatlari. Va xizmat to'g'ridan-to'g'ri mashinalarga joylashtirilgandan so'ng, uning namunalari paydo bo'ladi. Ular, shuningdek, aniq nomlanadi - misol raqami va xizmat nomi sifatida: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

Bu juda qulay: faqat ishlaydigan konteyner nomiga qarab, biz darhol ko'p narsalarni bilib olamiz.

Keling, ushbu misollar aslida nimani amalga oshirishini batafsil ko'rib chiqaylik: vazifalar.

Vazifalarni ajratish sinflari

OKdagi barcha vazifalarni (va, ehtimol, hamma joyda) guruhlarga bo'lish mumkin:

• Qisqa kechikish vazifalari - ishlab chiqarish. Bunday vazifalar va xizmatlar uchun javobning kechikishi (kechikish) juda muhim, har bir so'rov tizim tomonidan qanchalik tez qayta ishlanadi. Vazifalarga misollar: veb-jabhalar, keshlar, dastur serverlari, OLTP xotirasi va boshqalar.
• Hisoblash muammolari - partiya. Bu erda har bir aniq so'rovni qayta ishlash tezligi muhim emas. Ular uchun bu vazifa ma'lum (uzoq) vaqt (o'tkazuvchanlik) ichida qancha hisob-kitoblarni bajarishi muhim. Bu MapReduce, Hadoop, mashinani o'rganish, statistikaning har qanday vazifalari bo'ladi.
• Fon vazifalari - bo'sh. Bunday vazifalar uchun kechikish yoki o'tkazish qobiliyati juda muhim emas. Bunga turli xil testlar, migratsiyalar, qayta hisoblashlar va ma'lumotlarni bir formatdan boshqasiga o'tkazish kiradi. Bir tomondan, ular hisoblanganlarga o'xshaydi, boshqa tomondan, ular qanchalik tez bajarilishi biz uchun muhim emas.

Keling, bunday vazifalar resurslarni, masalan, markaziy protsessorni qanday iste'mol qilishini ko'rib chiqaylik.

Qisqa kechikish vazifalari. Bunday vazifada shunga o'xshash CPU iste'moli modeli bo'ladi:

Foydalanuvchidan so'rov qayta ishlash uchun qabul qilinadi, vazifa barcha mavjud protsessor yadrolaridan foydalanishni boshlaydi, uni qayta ishlaydi, javob qaytaradi, keyingi so'rovni kutadi va to'xtaydi. Keyingi so'rov keldi - yana biz u erda bo'lgan hamma narsani tanladik, hisoblab chiqdik va keyingisini kutmoqdamiz.

Bunday vazifani bajarish uchun minimal kechikishni kafolatlash uchun biz u iste'mol qiladigan maksimal resurslarni olishimiz va minionda (topshiriqni bajaradigan mashina) kerakli miqdordagi yadrolarni zaxiralashimiz kerak. Keyin bizning muammomiz uchun rezervlash formulasi quyidagicha bo'ladi:

alloc: cpu = 4 (max)

va agar bizda 16 yadroli minion mashinasi bo'lsa, unda to'rtta shunday vazifani qo'yish mumkin. Biz, ayniqsa, shuni ta'kidlaymizki, bunday vazifalarni protsessorning o'rtacha iste'moli ko'pincha juda past - bu aniq, chunki vazifa vaqtning muhim qismi so'rovni kutadi va hech narsa qilmaydi.

Hisoblash vazifalari. Ularning naqshlari biroz boshqacha bo'ladi:

Bunday vazifalar uchun protsessor resurslarining o'rtacha iste'moli ancha yuqori. Ko'pincha biz hisoblash vazifasini ma'lum vaqt ichida bajarishni xohlaymiz, shuning uchun biz butun hisob-kitob maqbul vaqt ichida bajarilishi uchun unga kerak bo'lgan minimal protsessorlar sonini zaxiralashimiz kerak. Uning bron qilish formulasi quyidagicha ko'rinadi:

alloc: cpu = [1,*)

"Iltimos, uni kamida bitta bo'sh yadro bo'lgan minionga qo'ying, shunda qancha bo'lsa, u hamma narsani yutib yuboradi."

Bu erda foydalanish samaradorligi qisqa muddatli vazifalarga qaraganda ancha yaxshi. Ammo agar siz ikkala turdagi vazifalarni bitta minion mashinasida birlashtirsangiz va uning resurslarini yo'lda taqsimlasangiz, daromad ancha katta bo'ladi. Qisqa kechikishli vazifa protsessorni talab qilganda, u uni darhol qabul qiladi va resurslar endi kerak bo'lmaganda, ular hisoblash vazifasiga o'tkaziladi, ya'ni:

Ammo buni qanday qilish kerak?

Birinchidan, mahsulot va uning taqsimotini ko'rib chiqaylik: cpu = 4. Biz to'rtta yadroni zaxiralashimiz kerak. Docker ishga tushirishda buni ikki usulda bajarish mumkin:

• Variantdan foydalanish --cpuset=1-4, ya'ni vazifaga mashinada to'rtta maxsus yadro ajrating.
• Foydalanish --cpuquota=400_000 --cpuperiod=100_000, protsessor vaqti uchun kvota tayinlang, ya'ni har 100 ms real vaqtda vazifa 400 ms dan ortiq protsessor vaqtini iste'mol qilmasligini ko'rsating. Xuddi shu to'rtta yadro olinadi.

Ammo bu usullardan qaysi biri mos keladi?

cpuset juda jozibali ko'rinadi. Vazifada to'rtta ajratilgan yadro mavjud, ya'ni protsessor keshlari iloji boricha samarali ishlaydi. Buning ham salbiy tomoni bor: biz operatsion tizim o'rniga mashinaning yuklanmagan yadrolari bo'ylab hisob-kitoblarni taqsimlash vazifasini o'z zimmamizga olishimiz kerak edi va bu juda ahamiyatsiz bo'lmagan vazifa, ayniqsa, agar biz bunday tizimga paketli vazifalarni joylashtirishga harakat qilsak. mashina. Sinovlar shuni ko'rsatdiki, kvota bilan variant bu erda yaxshiroq mos keladi: shu tarzda operatsion tizim hozirgi vaqtda vazifani bajarish uchun yadro tanlashda ko'proq erkinlikka ega va protsessor vaqti yanada samarali taqsimlanadi.

Keling, yadrolarning minimal soniga asoslanib, Docker-da qanday bron qilishni aniqlaylik. To'plamli vazifalar uchun kvota endi qo'llanilmaydi, chunki maksimalni cheklashning hojati yo'q, faqat minimalni kafolatlash kifoya. Va bu erda variant juda mos keladi docker run --cpushares.

Biz kelishib oldik, agar partiya kamida bitta yadro uchun kafolatni talab qilsa, biz ko'rsatamiz --cpushares=1024, va agar kamida ikkita yadro bo'lsa, biz ko'rsatamiz --cpushares=2048. Protsessor aktsiyalari protsessor vaqtini taqsimlashga hech qanday tarzda xalaqit bermaydi, agar u etarli bo'lsa. Shunday qilib, agar prod hozirda to'rtta yadrodan foydalanmasa, paketli vazifalarni cheklovchi hech narsa yo'q va ular qo'shimcha protsessor vaqtini ishlatishlari mumkin. Ammo protsessorlar tanqisligi mavjud bo'lgan vaziyatda, agar mahsulot to'rtta yadroning hammasini iste'mol qilgan bo'lsa va o'z kvotasiga erishgan bo'lsa, qolgan protsessor vaqti proportsional ravishda protsessorlarga bo'linadi, ya'ni uchta bo'sh yadroli vaziyatda bittasi bo'ladi. 1024 ta cpushareli vazifaga, qolgan ikkitasi esa 2048 ta cpusharega ega bo'lgan vazifaga beriladi.

Ammo kvota va aktsiyalardan foydalanish etarli emas. Protsessor vaqtini taqsimlashda qisqa kechikish bo'lgan vazifa ommaviy topshiriqdan ustun bo'lishiga ishonch hosil qilishimiz kerak. Bunday ustuvorliksiz, paketli vazifa ishlab chiqaruvchiga kerak bo'lganda protsessorning barcha vaqtini oladi. Docker ishida konteyner ustuvorligi variantlari yo'q, lekin Linux CPU rejalashtirish siyosati foydali bo'ladi. Siz ular haqida batafsil o'qishingiz mumkin shu yerda, va ushbu maqola doirasida biz ularni qisqacha ko'rib chiqamiz:

• SCHED_OTHER
  Odatiy bo'lib, Linux mashinasidagi barcha oddiy foydalanuvchi jarayonlari qabul qilinadi.
• SCHED_BATCH
  Resurs talab qiladigan jarayonlar uchun mo'ljallangan. Protsessorga vazifa qo'yishda faollashtirish jazosi joriy etiladi: agar SCHED_OTHER bilan vazifa ishlatilayotgan bo'lsa, bunday vazifa protsessor resurslarini olish ehtimoli kamroq.
• SCHED_IDLE
  Juda past ustuvorlikka ega fon jarayoni, hatto yoqimli -19 dan ham pastroq. Biz ochiq manba kutubxonamizdan foydalanamiz bir-nio, qo'ng'iroq qilish orqali konteynerni ishga tushirishda kerakli siyosatni o'rnatish uchun

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

Ammo Java-da dasturlashmagan bo'lsangiz ham, xuddi shu narsani chrt buyrug'i yordamida bajarish mumkin:

chrt -i 0 $pid

Aniqlik uchun barcha izolyatsiya darajalarimizni bitta jadvalga jamlaymiz:

Izolyatsiya klassi
Ajratish misoli
Docker ishga tushirish variantlari
sched_setscheduler chrt*

Prod
CPU = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

Partiya
CPU = [1, *)
--cpushares=1024
SCHED_BATCH

Bo'ston
CPU= [2, *)
--cpushares=2048
SCHED_IDLE

*Agar siz konteyner ichidan chrt ishlayotgan bo'lsangiz, sizga sys_nice qobiliyati kerak bo'lishi mumkin, chunki sukut bo'yicha Docker konteynerni ishga tushirganda bu imkoniyatni o'chiradi.

Ammo vazifalar nafaqat protsessorni, balki protsessor resurslarini noto'g'ri taqsimlashdan ham ko'proq tarmoq vazifasining kechikishiga ta'sir qiladigan trafikni ham iste'mol qiladi. Shuning uchun, biz tabiiy ravishda trafik uchun aynan bir xil rasmni olishni xohlaymiz. Ya'ni, ishlab chiqarish vazifasi tarmoqqa ba'zi paketlarni yuborganda, biz maksimal tezlikni cheklaymiz (formula ajratish: lan=[*,500mbps) ), qaysi prod buni amalga oshirishi mumkin. Va partiya uchun biz faqat minimal o'tkazuvchanlikni kafolatlaymiz, lekin maksimalni cheklamaymiz (formula ajratish: lan=[10Mbps,*) ) Bunday holda, mahsulot trafigiga ommaviy topshiriqlardan ustunlik berish kerak.
Bu erda Dockerda biz foydalanishimiz mumkin bo'lgan ibtidoiylar yo'q. Ammo bu bizning yordamimizga keladi Linux Traffic Control. Biz intizom yordamida kerakli natijaga erisha oldik Ierarxik adolatli xizmat ko'rsatish egri chizig'i. Uning yordami bilan biz trafikning ikki sinfini ajratamiz: yuqori ustuvor mahsulot va past ustuvor partiya/bo'sh. Natijada, chiquvchi trafik konfiguratsiyasi quyidagicha:

bu yerda 1:0 - hsfc intizomining "ildiz qdisc"; 1:1 - umumiy o'tkazish qobiliyati chegarasi 8 Gbit/s bo'lgan hsfc bolalar klassi, uning ostida barcha konteynerlarning bolalar sinflari joylashtirilgan; 1:2 - hsfc bolalar klassi "dinamik" chegaraga ega bo'lgan barcha ommaviy va bo'sh vazifalar uchun umumiy bo'lib, quyida muhokama qilinadi. Qolgan hsfc bolalar sinflari hozirda ishlayotgan ishlab chiqarish konteynerlari uchun ajratilgan sinflar bo'lib, ularning manifestlariga mos keladigan chegaralar - 450 va 400 Mbit/s. Har bir hsfc klassiga Linux yadrosi versiyasiga qarab qdisc navbati fq yoki fq_codel tayinlanadi, bu trafik portlashlari paytida paketlar yo'qolishining oldini oladi.

Odatda, tc intizomi faqat chiquvchi trafikni birinchi o'ringa qo'yishga xizmat qiladi. Ammo biz kiruvchi trafikni ham birinchi o'ringa qo'ymoqchimiz - axir, ba'zi bir paketli vazifa, masalan, xarita va qisqartirish uchun kirish ma'lumotlarining katta partiyasini qabul qilib, butun kiruvchi kanalni osongina tanlashi mumkin. Buning uchun biz moduldan foydalanamiz agarb, bu har bir tarmoq interfeysi uchun ifbX virtual interfeysini yaratadi va kiruvchi trafikni interfeysdan ifbX da chiquvchi trafikga yo'naltiradi. Bundan tashqari, ifbX uchun barcha bir xil fanlar chiquvchi trafikni boshqarish uchun ishlaydi, ular uchun hsfc konfiguratsiyasi juda o'xshash bo'ladi:

Tajribalar davomida biz hsfc eng yaxshi natijalarni ko'rsatayotganini aniqladik, qachonki 1:2 toifadagi ustuvor bo'lmagan paketli/bo'sh harakatlanish minion mashinalarida ma'lum bir bo'sh chiziqdan oshmasligi kerak. Aks holda, ustuvor bo'lmagan trafik ishlab chiqarish vazifalarining kechikishiga juda ko'p ta'sir qiladi. miniond ma'lum bir minionning barcha ishlab chiqarish vazifalari uchun o'rtacha trafik sarfini o'lchab, har soniyada joriy bo'sh tarmoqli kengligi miqdorini aniqlaydi. va uni tarmoq interfeysi tarmoqli kengligidan ayirish kichik chegara bilan, ya'ni.

Bantlar kiruvchi va chiquvchi trafik uchun mustaqil ravishda belgilanadi. Va yangi qiymatlarga ko'ra, miniond ustuvor bo'lmagan sinf chegarasini 1: 2 ga qayta sozlaydi.

Shunday qilib, biz uchta izolyatsiya sinfini amalga oshirdik: ishlab chiqarish, ommaviy va bo'sh. Bu sinflar vazifalarning ishlash xususiyatlariga katta ta'sir ko'rsatadi. Shuning uchun, biz ushbu atributni ierarxiyaning yuqori qismiga joylashtirishga qaror qildik, shunda ierarxik navbat nomiga qaraganimizda, biz nima bilan shug'ullanayotganimiz darhol aniq bo'ladi:

Barcha do'stlarimiz veb- и musiqa keyin jabhalar prod ostida ierarxiyaga joylashtiriladi. Masalan, paket ostida, xizmatni joylashtiramiz musiqa katalogi, u vaqti-vaqti bilan Odnoklassniki-ga yuklangan mp3 fayllar to'plamidan treklar katalogini tuzadi. Bo'sh turgan xizmatga misol bo'ladi musiqa transformator, bu musiqa tovush darajasini normallashtiradi.

Qo'shimcha qatorlar yana olib tashlangan bo'lsa, biz to'liq xizmat nomining oxiriga vazifa izolyatsiyasi sinfini qo'shish orqali xizmat nomlarimizni tekisroq yozishimiz mumkin: web.front.prod, katalog.music.batch, transformator.music.bo'sh.

Va endi, xizmat nomiga qarab, biz nafaqat u qanday funktsiyani bajarishini, balki uning izolyatsiya sinfini ham tushunamiz, bu uning tanqidiyligini va hokazo.

Hammasi ajoyib, lekin bitta achchiq haqiqat bor. Bitta mashinada ishlaydigan vazifalarni butunlay ajratib bo'lmaydi.

Biz nimaga erishdik: agar partiya intensiv ravishda iste'mol qilsa faqatgina CPU resurslari, keyin o'rnatilgan Linux CPU rejalashtiruvchisi o'z ishini juda yaxshi bajaradi va mahsulot vazifasiga deyarli ta'sir qilmaydi. Ammo agar bu ommaviy vazifa xotira bilan faol ishlay boshlasa, o'zaro ta'sir allaqachon paydo bo'ladi. Buning sababi, protsessorning protsessor xotira keshlaridan ishlab chiqarish vazifasi "yuvilgan" - natijada kesh o'tkazib yuborilishi ko'payadi va protsessor mahsulot vazifasini sekinroq qayta ishlaydi. Bunday ommaviy topshiriq bizning odatiy mahsulot konteynerimizning kechikish vaqtini 10% ga oshirishi mumkin.

Zamonaviy tarmoq kartalari paketlarning ichki navbatiga ega bo'lganligi sababli trafikni izolyatsiya qilish yanada qiyinroq. Agar ommaviy topshiriqning paketi birinchi bo'lib u erga etib borsa, u kabel orqali birinchi bo'lib uzatiladi va bu haqda hech narsa qilish mumkin emas.

Bundan tashqari, biz hozirgacha faqat TCP trafigiga ustuvorlik berish muammosini hal qilishga muvaffaq bo'ldik: hsfc yondashuvi UDP uchun ishlamaydi. Va hatto TCP trafigida ham, agar ommaviy topshiriq juda ko'p trafik hosil qilsa, bu ishlab chiqarish topshirig'ining kechikishini taxminan 10% ga oshiradi.

xatolarga chidamlilik

Bir bulutni ishlab chiqishdagi maqsadlardan biri Odnoklassniki-ning xatolarga chidamliligini oshirish edi. Shuning uchun, men muvaffaqiyatsizliklar va baxtsiz hodisalarning mumkin bo'lgan stsenariylarini batafsilroq ko'rib chiqmoqchiman. Keling, oddiy stsenariydan boshlaylik - konteyner ishdan chiqishi.

Idishning o'zi bir necha usulda muvaffaqiyatsiz bo'lishi mumkin. Bu manifestdagi tajriba, xato yoki xato bo'lishi mumkin, buning natijasida ishlab chiqarish vazifasi manifestda ko'rsatilganidan ko'ra ko'proq resurslarni iste'mol qila boshlaydi. Bizda shunday holat bor edi: ishlab chiquvchi bitta murakkab algoritmni amalga oshirdi, uni ko'p marta qayta ishladi, o'zini o'zi o'ylab topdi va shu qadar sarosimaga tushdiki, oxir-oqibat muammo juda ahamiyatsiz tarzda hal qilindi. Va ishlab chiqarish vazifasi bir xil minionlardagi barcha boshqalarga qaraganda ustuvor ahamiyatga ega bo'lganligi sababli, u barcha mavjud protsessor resurslarini iste'mol qila boshladi. Bunday vaziyatda izolyatsiya, aniqrog'i CPU vaqt kvotasi kunni saqlab qoldi. Agar vazifaga kvota ajratilgan bo'lsa, vazifa ko'proq iste'mol qilmaydi. Shu sababli, bitta mashinada ishlaydigan ommaviy va boshqa ishlab chiqarish vazifalari hech narsani sezmadi.

Ikkinchi mumkin bo'lgan muammo - konteynerning tushishi. Va bu erda qayta ishga tushirish siyosatlari bizni qutqaradi, hamma ularni biladi, Dockerning o'zi ajoyib ish qiladi. Deyarli barcha ishlab chiqarish vazifalari har doim qayta ishga tushirish siyosatiga ega. Ba'zan biz on_failure dan ommaviy topshiriqlar yoki ishlab chiqarilgan konteynerlarni tuzatish uchun foydalanamiz.

Agar butun minion mavjud bo'lmasa, nima qilishingiz mumkin?

Shubhasiz, konteynerni boshqa mashinada boshqaring. Qizig'i shundaki, konteynerga tayinlangan IP-manzil(lar) bilan nima sodir bo'ladi.

Biz konteynerlarga ushbu konteynerlar ishlaydigan minion mashinalari bilan bir xil IP manzillarni belgilashimiz mumkin. Keyin, konteyner boshqa mashinada ishga tushirilganda, uning IP-manzili o'zgaradi va barcha mijozlar konteyner ko'chib ketganini tushunishlari kerak va endi ular boshqa manzilga o'tishlari kerak, bu esa alohida Service Discovery xizmatini talab qiladi.

Xizmatni ochish qulay. Bozorda xizmat reestrini tashkil qilish uchun turli darajadagi xatolarga chidamlilik ko'plab echimlar mavjud. Ko'pincha bunday echimlar yuk balansi mantig'ini amalga oshiradi, qo'shimcha konfiguratsiyani KV saqlash shaklida saqlaydi va hokazo.
Biroq, biz alohida reestrni joriy qilish zaruratidan qochmoqchimiz, chunki bu ishlab chiqarishda barcha xizmatlar tomonidan qo'llaniladigan muhim tizimni joriy etishni anglatadi. Bu shuni anglatadiki, bu potentsial muvaffaqiyatsizlik nuqtasidir va siz xatoga chidamli yechimni tanlashingiz yoki ishlab chiqishingiz kerak, bu juda qiyin, ko'p vaqt talab qiladigan va qimmat.

Va yana bir katta kamchilik: bizning eski infratuzilmamiz yangisi bilan ishlashi uchun qandaydir Service Discovery tizimidan foydalanish uchun barcha vazifalarni mutlaqo qayta yozishimiz kerak edi. Ko'p ish bor va ba'zi joylarda OS yadrosi darajasida yoki to'g'ridan-to'g'ri apparat bilan ishlaydigan past darajadagi qurilmalar haqida gap ketganda, bu deyarli mumkin emas. O'rnatilgan yechim naqshlari yordamida ushbu funksionallikni amalga oshirish, masalan yon mashina ba'zi joylarda qo'shimcha yukni, boshqalarida - operatsiyaning murakkabligini va qo'shimcha nosozlik stsenariylarini anglatadi. Biz narsalarni murakkablashtirishni xohlamadik, shuning uchun biz Service Discovery-dan foydalanishni ixtiyoriy qilishga qaror qildik.

Bitta bulutda IP konteynerni kuzatib boradi, ya'ni har bir topshiriq namunasi o'z IP manziliga ega. Ushbu manzil "statik": u bulutga birinchi marta xizmat yuborilgan har bir misol uchun tayinlanadi. Agar xizmat muddati davomida turli xil nusxalarga ega bo'lsa, oxir-oqibat unga maksimal misollar bo'lganidek ko'p IP-manzillar tayinlanadi.

Keyinchalik, bu manzillar o'zgarmaydi: ular bir marta tayinlanadi va ishlab chiqarishda xizmat ko'rsatish muddati davomida mavjud bo'lib qoladi. IP manzillar tarmoq bo'ylab konteynerlarni kuzatib boradi. Agar konteyner boshqa minionga o'tkazilsa, manzil unga ergashadi.

Shunday qilib, xizmat nomini uning IP manzillari ro'yxatiga solishtirish juda kamdan-kam hollarda o'zgaradi. Agar siz maqolaning boshida aytib o'tgan xizmat ko'rsatish misollarining nomlariga yana bir bor qarasangiz (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), biz ular DNS-da ishlatiladigan FQDN-larga o'xshashligini sezamiz. To'g'ri, xizmat ko'rsatish misollarining nomlarini ularning IP manzillari bilan taqqoslash uchun biz DNS protokolidan foydalanamiz. Bundan tashqari, ushbu DNS barcha konteynerlarning barcha zahiralangan IP manzillarini qaytaradi - ishlayotgan va to'xtatilgan (aytaylik, uchta replika ishlatilgan va bizda beshta manzil rezervlangan - barcha beshtasi qaytariladi). Ushbu ma'lumotni olgan mijozlar barcha beshta nusxalar bilan aloqa o'rnatishga harakat qiladilar va shu bilan ishlayotganlarini aniqlaydilar. Mavjudligini aniqlashning ushbu varianti ancha ishonchli bo'lib, u DNS yoki Service Discovery-ni o'z ichiga olmaydi, ya'ni ma'lumotlarning dolzarbligini va ushbu tizimlarning nosozliklarga chidamliligini ta'minlashda hal qilish qiyin muammolar yo'q. Bundan tashqari, butun portalning ishlashi bog'liq bo'lgan muhim xizmatlarda biz DNS-dan umuman foydalana olmaymiz, faqat IP-manzillarni konfiguratsiyaga kiritamiz.

Konteynerlar orqasida bunday IP uzatishni amalga oshirish ahamiyatsiz bo'lishi mumkin - va biz uning qanday ishlashini quyidagi misolda ko'rib chiqamiz:

Aytaylik, bitta bulutli usta M1 minioniga yugurish buyrug'ini beradi 1.ok-web.group1.web.front.prod 1.1.1.1 manzili bilan. Minionda ishlaydi BIRD, bu manzilni maxsus serverlarga reklama qiladi marshrut reflektori. Ikkinchisi tarmoq uskunasi bilan BGP seansiga ega bo'lib, unga M1.1.1.1 dagi 1 manzilining marshruti tarjima qilinadi. M1 Linux yordamida paketlarni konteyner ichiga yo'naltiradi. Uchta marshrut reflektor serverlari mavjud, chunki bu bitta bulutli infratuzilmaning juda muhim qismidir - ularsiz bitta bulutli tarmoq ishlamaydi. Biz ularni bir vaqtning o'zida uchta ishlamay qolish ehtimolini kamaytirish uchun, agar iloji bo'lsa, ma'lumotlar markazining turli xonalarida joylashgan turli xil tokchalarga joylashtiramiz.

Keling, bitta bulutli usta va M1 minioni o'rtasidagi aloqa yo'qolgan deb faraz qilaylik. Bir bulutli usta endi M1 to'liq muvaffaqiyatsizlikka uchragan degan taxminga asoslanadi. Ya'ni, u M2 minioniga ishga tushirish buyrug'ini beradi web.group1.web.front.prod bir xil manzil bilan 1.1.1.1. Endi bizda 1.1.1.1 uchun tarmoqda ikkita qarama-qarshi marshrut mavjud: M1 va M2 da. Bunday nizolarni hal qilish uchun biz BGP e'lonida ko'rsatilgan Multi Exit Diskriminatordan foydalanamiz. Bu e'lon qilingan marshrutning og'irligini ko'rsatadigan raqam. Qarama-qarshi marshrutlar orasida MED qiymati pastroq marshrut tanlanadi. Bir bulutli master MEDni konteyner IP manzillarining ajralmas qismi sifatida qo'llab-quvvatlaydi. Birinchi marta manzil etarli darajada katta MED = 1 000 000 bilan yozilgan. Bunday favqulodda konteyner o'tkazish vaziyatda, master MED kamaytiradi va M2 allaqachon MED bilan 1.1.1.1 manzilini reklama qilish buyrug'ini oladi = 999 999. M1 da ishlayotgan instantsiya shu holatda qoladi, bu holda hech qanday aloqa yo'q va uning keyingi taqdiri bizni usta bilan aloqa tiklanmaguncha, u eski suratga o'xshab to'xtatilgunga qadar qiziqtirmaydi.

baxtsiz hodisalar

Barcha ma'lumotlar markazi boshqaruv tizimlari har doim kichik nosozliklarni maqbul tarzda hal qiladi. Konteynerning to'lib ketishi deyarli hamma joyda odatiy holdir.

Keling, ma'lumot markazining bir yoki bir nechta xonasida elektr uzilishi kabi favqulodda vaziyatlarni qanday hal qilishimizni ko'rib chiqaylik.

Ma'lumotlar markazini boshqarish tizimi uchun baxtsiz hodisa nimani anglatadi? Birinchidan, bu ko'plab mashinalarning bir martalik katta ishdan chiqishi va boshqaruv tizimi bir vaqtning o'zida ko'plab konteynerlarni ko'chirishi kerak. Ammo agar falokat juda keng ko'lamli bo'lsa, unda barcha vazifalarni boshqa minionlarga qayta taqsimlab bo'lmaydi, chunki ma'lumotlar markazining resurs sig'imi yukning 100% dan pastga tushadi.

Ko'pincha baxtsiz hodisalar nazorat qatlamining ishdan chiqishi bilan birga keladi. Bu uning uskunasining ishdan chiqishi tufayli sodir bo'lishi mumkin, lekin ko'pincha baxtsiz hodisalar sinovdan o'tkazilmaganligi va nazorat qatlamining o'zi yuk ko'tarilishi tufayli tushadi.

Bularning barchasi haqida nima qila olasiz?

Ommaviy migratsiya infratuzilmada ko'p sonli faoliyat, migratsiya va joylashtirishlar mavjudligini anglatadi. Har bir migratsiya konteyner tasvirlarini minionlarga yetkazib berish va ochish, konteynerlarni ishga tushirish va ishga tushirish va hokazolar uchun biroz vaqt talab qilishi mumkin. Shuning uchun muhimroq vazifalarni kamroq muhimlaridan oldin boshlash tavsiya etiladi.

Keling, bizga tanish bo'lgan xizmatlar ierarxiyasini yana bir bor ko'rib chiqaylik va qaysi vazifalarni birinchi bo'lib bajarishni xohlashimizni hal qilishga harakat qilaylik.

Albatta, bu foydalanuvchi so'rovlarini qayta ishlashda bevosita ishtirok etadigan jarayonlar, ya'ni prod. Buni bilan ishora qilamiz joylashtirish ustuvorligi — navbatga tayinlanishi mumkin bo'lgan raqam. Agar navbat ustuvorroq bo'lsa, uning xizmatlari birinchi o'rinda turadi.

Mahsulotda biz yuqoriroq ustuvorliklarni belgilaymiz, 0; partiyada - biroz pastroq, 100; bo'sh turganda - undan ham pastroq, 200. Ustuvorliklar ierarxik tarzda qo'llaniladi. Ierarxiyadan pastroq bo'lgan barcha vazifalar tegishli ustuvorlikka ega bo'ladi. Agar biz prod ichidagi keshlarni frontendlardan oldin ishga tushirishni istasak, u holda biz ustuvorliklarni kesh = 0 va old pastki navbatlarga = 1 belgilaymiz. Agar, masalan, asosiy portalni birinchi navbatda old tomondan, faqat musiqa old qismidan ishga tushirishni xohlasak. keyin, keyin biz ikkinchisiga pastroq ustuvorlikni belgilashimiz mumkin - 10.

Keyingi muammo - resurslarning etishmasligi. Shunday qilib, katta hajmdagi uskunalar, ma'lumotlar markazining butun zallari ishlamay qoldi va biz shunchalik ko'p xizmatlarni qayta ishga tushirdikki, hozir hamma uchun resurslar etarli emas. Asosiy muhim xizmatlarning ishlashini ta'minlash uchun qaysi vazifalarni qurbon qilishni hal qilishingiz kerak.

Joylashtirish ustuvorligidan farqli o'laroq, biz barcha paketli vazifalarni beg'araz qurbon qila olmaymiz; ularning ba'zilari portalning ishlashi uchun muhimdir. Shuning uchun biz alohida ta'kidladik ustunlik ustuvorligi vazifalar. Joylashtirilganda, yuqoriroq ustuvor vazifa, agar boshqa bo'sh minionlar bo'lmasa, pastroq vazifani to'xtatishi mumkin. Bunday holda, ustuvorligi past bo'lgan vazifa, ehtimol, o'rnatilmagan bo'lib qolishi mumkin, ya'ni endi etarli bepul resurslarga ega bo'lgan mos minion bo'lmaydi.

Bizning ierarxiyamizda 200 ga teng bo'sh turish uchun ustuvorlikni belgilash orqali ishlab chiqarish va to'plam vazifalari bo'sh turgan vazifalarni oldini olish yoki to'xtatish uchun bir-birini emas, balki bir-birini to'xtatib qo'yadigan ustuvorlikni belgilash juda oddiy. Xuddi joylashtirish ustuvorligida bo'lgani kabi, biz ham murakkabroq qoidalarni tasvirlash uchun bizning ierarxiyamizdan foydalanishi mumkin. Masalan, asosiy veb-portal uchun resurslarimiz etarli bo'lmasa, mos keladigan tugunlar uchun ustuvorlikni pastroq qilib qo'ysak, biz musiqa funktsiyasini qurbon qilishimizni ko'rsatamiz: 10.

To'liq DC avariyalari

Nima uchun butun ma'lumotlar markazi ishlamay qolishi mumkin? Element. Yaxshi post bo'ldi bo'ron ma'lumotlar markazi ishiga ta'sir qildi. Elementlarni bir vaqtlar manifoldda optikani yoqib yuborgan uysiz odamlar deb hisoblash mumkin va ma'lumotlar markazi boshqa saytlar bilan aloqani butunlay yo'qotdi. Muvaffaqiyatsizlik sababi ham inson omili bo'lishi mumkin: operator shunday buyruq beradiki, butun ma'lumotlar markazi tushadi. Bu katta xato tufayli sodir bo'lishi mumkin. Umuman olganda, ma'lumotlar markazlarining qulashi odatiy hol emas. Bu biz bilan bir necha oyda bir marta sodir bo'ladi.

Va bu biz hech kimning #alive tvitini oldini olish uchun qilamiz.

Birinchi strategiya - bu izolyatsiya. Har bir bulutli misol izolyatsiya qilingan va mashinalarni faqat bitta ma'lumot markazida boshqarishi mumkin. Ya'ni, xatolar yoki noto'g'ri operator buyruqlari tufayli bulutning yo'qolishi faqat bitta ma'lumot markazining yo'qolishidir. Biz bunga tayyormiz: bizda ortiqcha siyosat mavjud bo'lib, unda ilova va ma'lumotlarning nusxalari barcha ma'lumotlar markazlarida joylashgan. Biz xatolarga chidamli ma'lumotlar bazalaridan foydalanamiz va vaqti-vaqti bilan nosozliklarni tekshiramiz.
Bugundan boshlab bizda to'rtta ma'lumot markazlari mavjud, ya'ni bitta bulutning to'rtta alohida, butunlay izolyatsiya qilingan misollari.

Ushbu yondashuv nafaqat jismoniy nosozlikdan himoya qiladi, balki operator xatosidan ham himoya qilishi mumkin.

Inson omili bilan yana nima qilish mumkin? Operator bulutga qandaydir g'alati yoki potentsial xavfli buyruq berganida, to'satdan u qanchalik yaxshi o'ylaganini ko'rish uchun kichik muammoni hal qilishni so'rashi mumkin. Misol uchun, agar bu ko'plab replikalarni ommaviy to'xtatish yoki shunchaki g'alati buyruq bo'lsa - yangi manifestdagi versiya raqamini emas, balki nusxalar sonini kamaytirish yoki tasvir nomini o'zgartirish.

natijalar

Bir bulutning o'ziga xos xususiyatlari:

• Xizmatlar va konteynerlar uchun ierarxik va vizual nomlash sxemasi, bu sizga vazifa nima ekanligini, nima bilan bog'liqligini va qanday ishlashini va buning uchun kim mas'ul ekanligini tezda aniqlash imkonini beradi.
• Biz o'zimizni qo'llaymiz mahsulot va partiyani birlashtirish texnikasimashina almashish samaradorligini oshirish uchun minionlar ustida vazifalar. Cpuset o'rniga biz CPU kvotalari, aktsiyalari, CPU rejalashtirish siyosati va Linux QoS dan foydalanamiz.
• Xuddi shu mashinada ishlaydigan konteynerlarni to'liq izolyatsiya qilishning iloji bo'lmadi, ammo ularning o'zaro ta'siri 20% ichida qolmoqda.
• Xizmatlarni ierarxiya bo'yicha tashkil qilish fojialarni avtomatik tiklashga yordam beradi joylashtirish va ustunlik qilish.

Tss

Nega biz tayyor yechim qabul qilmadik?

• Vazifalarni izolyatsiya qilishning turli sinflari minionlarga o'rnatilganda har xil mantiqni talab qiladi. Agar ishlab chiqarish vazifalarini oddiygina resurslarni zaxiralash orqali joylashtirish mumkin bo'lsa, u holda minion mashinalarida resurslardan haqiqiy foydalanishni kuzatib, paketli va bo'sh vazifalar joylashtirilishi kerak.
• Vazifalar tomonidan iste'mol qilinadigan resurslarni hisobga olish zarurati, masalan:
  • tarmoq o'tkazish qobiliyati;
  • disklarning turlari va "shpindellari".
• Favqulodda vaziyatlarni bartaraf etishda xizmatlarning ustuvor yo'nalishlarini, bir bulutda ierarxik navbatlar yordamida hal qilinadigan resurslar uchun buyruqlar kvotalarini va huquqlarini ko'rsatish zarurati.
• Baxtsiz hodisalar va hodisalarga javob berish vaqtini qisqartirish uchun konteynerlarga odamlar tomonidan nom berish zarurati
• Service Discovery-ni bir martalik keng joriy etishning mumkin emasligi; apparat xostlarida joylashgan vazifalar bilan uzoq vaqt birga yashash zarurati - bu konteynerlardan keyingi "statik" IP-manzillar tomonidan hal qilinadigan narsa va natijada katta tarmoq infratuzilmasi bilan noyob integratsiya zarurati.

Bu funktsiyalarning barchasi bizga mos keladigan mavjud echimlarni sezilarli darajada o'zgartirishni talab qiladi va ish hajmini baholab, biz taxminan bir xil mehnat xarajatlari bilan o'z yechimimizni ishlab chiqishimiz mumkinligini angladik. Ammo sizning yechimingiz ishlashi va rivojlanishi ancha oson bo'ladi - unda bizga kerak bo'lmagan funksionallikni qo'llab-quvvatlaydigan keraksiz abstraktsiyalar mavjud emas.

Oxirgi satrlarni o'qiganlarga sabr-toqatingiz va e'tiboringiz uchun rahmat!

Manba: www.habr.com