🥇Bir bulud - Odnoklassniki-də məlumat mərkəzi səviyyəli ƏS

Aloha, insanlar! Mənim adım Oleq Anastasyev, mən Odnoklassniki-də Platform komandasında işləyirəm. Məndən başqa Odnoklassniki-də çoxlu aparat işləyir. 500 mindən çox serveri olan 8-ə yaxın rək olan dörd məlumat mərkəzimiz var. Müəyyən bir məqamda biz başa düşdük ki, yeni idarəetmə sisteminin tətbiqi avadanlıqları daha səmərəli yükləməyə, girişin idarə edilməsini asanlaşdırmağa, hesablama resurslarının (yenidən) bölüşdürülməsini avtomatlaşdırmağa, yeni xidmətlərin işə salınmasını sürətləndirməyə və cavab tədbirlərini sürətləndirməyə imkan verəcək. irimiqyaslı qəzalara.

Bundan nə gəldi?

Məndən və bir dəstə aparatdan başqa, bu aparatla işləyən insanlar da var: bilavasitə məlumat mərkəzlərində yerləşən mühəndislər; şəbəkə proqram təminatı quran şəbəkəçilər; infrastrukturun davamlılığını təmin edən idarəçilər və ya SRE-lər; və inkişaf qrupları, onların hər biri portalın funksiyalarının bir hissəsinə cavabdehdir. Yaratdıqları proqram bu kimi işləyir:

İstifadəçi sorğuları həm əsas portalın ön hissəsində qəbul edilir www.ok.ru, və digərlərində, məsələn, musiqi API cəbhələrində. Biznes məntiqini emal etmək üçün onlar sorğunu emal edərkən lazımi ixtisaslaşmış mikroxidmətləri - bir qrafiki (sosial əlaqələrin qrafiki), istifadəçi önbelleğini (istifadəçi profillərinin keşini) çağıran proqram serverini çağırırlar.

Bu xidmətlərin hər biri bir çox maşınlarda yerləşdirilib və onların hər birində modulların işləməsinə, onların istismarına və texnoloji inkişafına cavabdeh olan məsul tərtibatçılar var. Bütün bu xidmətlər hardware serverlərində işləyir və son vaxtlara qədər biz hər serverə tam olaraq bir tapşırığı işə salmışdıq, yəni o, konkret tapşırıq üçün ixtisaslaşdırılmışdı.

Niyə belədir? Bu yanaşmanın bir sıra üstünlükləri var idi:

rahatladı kütləvi idarəetmə. Tutaq ki, bir tapşırıq bəzi kitabxanalar, bəzi parametrlər tələb edir. Və sonra server dəqiq bir xüsusi qrupa təyin edilir, bu qrup üçün cfengine siyasəti təsvir olunur (və ya artıq təsvir edilmişdir) və bu konfiqurasiya mərkəzləşdirilmiş şəkildə və avtomatik olaraq bu qrupdakı bütün serverlərə yayılır.
Sadələşdirilmiş diaqnostika. Deyək ki, siz mərkəzi prosessorun artan yüklənməsinə baxırsınız və bu yükün yalnız bu aparat prosessorunda işləyən tapşırıq tərəfindən yaradıla biləcəyini başa düşürsünüz. Günahkar kiminsə axtarışı çox tez bitir.
Sadələşdirilmiş monitorinqi. Əgər serverdə nəsə səhv olarsa, monitor bu barədə məlumat verir və siz kimin günahkar olduğunu dəqiq bilirsiniz.

Bir neçə replikadan ibarət xidmətə bir neçə server ayrılır - hər biri üçün bir. Sonra xidmət üçün hesablama resursu çox sadə şəkildə ayrılır: xidmətin malik olduğu serverlərin sayı, onun istehlak edə biləcəyi resursların maksimum miqdarı. Burada “asan” istifadənin asan olması demək deyil, o mənada ki, resurs bölgüsü əl ilə edilir.

Bu yanaşma bizə də imkan verdi xüsusi dəmir konfiqurasiyaları bu serverdə işləyən tapşırıq üçün. Tapşırıq böyük miqdarda məlumat saxlayırsa, onda biz 4 diskli şassi ilə 38U serverindən istifadə edirik. Əgər tapşırıq sırf hesablama xarakterlidirsə, biz daha ucuz 1U server ala bilərik. Bu hesablama baxımından səmərəlidir. Digər şeylər arasında, bu yanaşma bizə bir dost sosial şəbəkə ilə müqayisə edilə bilən yüklə dörd dəfə az maşın istifadə etməyə imkan verir.

Hesablama resurslarından istifadədə bu cür səmərəlilik, ən bahalı şeyin serverlər olması fikrindən çıxış etsək, iqtisadi səmərəliliyi də təmin etməlidir. Uzun müddətdir ki, aparat ən bahalı idi və biz aparatın etibarlılığı tələblərini azaltmaq üçün nasazlığa dözümlülük alqoritmləri hazırlayaraq, avadanlıqların qiymətini azaltmaq üçün çox səy göstərdik. Və bu gün biz serverin qiymətinin həlledici olmasını dayandırdığı mərhələyə çatdıq. Ən son ekzotikləri nəzərə almırsınızsa, o zaman rafdakı serverlərin xüsusi konfiqurasiyasının əhəmiyyəti yoxdur. İndi başqa bir problemimiz var - verilənlər mərkəzində serverin tutduğu yerin qiyməti, yəni rəfdəki yer.

Bunun belə olduğunu başa düşərək, raflardan nə qədər səmərəli istifadə etdiyimizi hesablamağa qərar verdik.
İqtisadi cəhətdən əsaslandırılmış serverlərdən ən güclü serverin qiymətini götürdük, rəflərə neçə belə server yerləşdirə biləcəyimizi, köhnə model “bir server = bir tapşırıq” əsasında onlar üzərində neçə tapşırıq yerinə yetirəcəyimizi və nə qədər belə olduğunu hesabladıq. tapşırıqlar avadanlıqdan istifadə edə bilər. Saydılar və göz yaşı tökdülər. Məlum oldu ki, rəflərdən istifadədə səmərəliliyimiz təxminən 11% təşkil edir. Nəticə göz qabağındadır: məlumat mərkəzlərindən istifadənin səmərəliliyini artırmalıyıq. Görünür ki, həll yolu açıqdır: bir serverdə eyni anda bir neçə tapşırığı yerinə yetirməlisiniz. Ancaq çətinliklər buradan başlayır.

Kütləvi konfiqurasiya kəskin şəkildə mürəkkəbləşir - indi serverə hər hansı bir qrupu təyin etmək mümkün deyil. Axı, indi bir serverdə müxtəlif əmrlərin bir neçə tapşırığı işə salına bilər. Bundan əlavə, konfiqurasiya müxtəlif proqramlar üçün ziddiyyətli ola bilər. Diaqnoz da çətinləşir: serverdə artan CPU və ya disk istehlakını görsəniz, hansı tapşırığın problem yaratdığını bilmirsiniz.

Ancaq əsas odur ki, eyni maşında işləyən tapşırıqlar arasında heç bir təcrid yoxdur. Burada, məsələn, eyni serverdə başqa bir hesablama proqramı işə salınmadan əvvəl və sonra server tapşırığının orta cavab vaxtının qrafiki verilmişdir, heç bir şəkildə birincisi ilə əlaqəli deyil - əsas tapşırığın cavab müddəti əhəmiyyətli dərəcədə artmışdır.

Aydındır ki, ya konteynerlərdə, ya da virtual maşınlarda tapşırıqları yerinə yetirməlisiniz. Demək olar ki, bütün tapşırıqlarımız bir OS (Linux) altında işlədiyindən və ya ona uyğunlaşdırıldığı üçün çoxlu müxtəlif əməliyyat sistemlərini dəstəkləməyə ehtiyacımız yoxdur. Müvafiq olaraq, virtuallaşdırmaya ehtiyac yoxdur, əlavə yükə görə konteynerləşdirmədən daha az səmərəli olacaq.

Birbaşa serverlərdə tapşırıqları yerinə yetirmək üçün konteynerlərin tətbiqi olaraq, Docker yaxşı namizəddir: fayl sistemi şəkilləri ziddiyyətli konfiqurasiyalarla problemləri yaxşı həll edir. Şəkillərin bir neçə təbəqədən ibarət ola bilməsi, ümumi hissələri ayrı-ayrı əsas təbəqələrə ayıraraq, onları infrastrukturda yerləşdirmək üçün tələb olunan məlumatların miqdarını əhəmiyyətli dərəcədə azaltmağa imkan verir. Sonra əsas (və ən həcmli) təbəqələr bütün infrastrukturda kifayət qədər tez yaddaşda saxlanılacaq və bir çox müxtəlif növ proqram və versiyaları çatdırmaq üçün yalnız kiçik təbəqələrin köçürülməsi lazımdır.

Üstəlik, Docker-də hazır reyestr və təsvirin etiketlənməsi bizə versiyaların yaradılması və kodu istehsala çatdırmaq üçün hazır primitivlər verir.

Docker, hər hansı digər oxşar texnologiya kimi, qutudan kənarda müəyyən səviyyəli konteyner izolyasiyasını təmin edir. Məsələn, yaddaşın izolyasiyası - hər bir konteynerə maşın yaddaşından istifadə üçün məhdudiyyət verilir, ondan kənarda istehlak etməyəcəkdir. Siz həmçinin CPU istifadəsinə əsasən konteynerləri təcrid edə bilərsiniz. Bizim üçün standart izolyasiya kifayət deyildi. Ancaq aşağıda bu barədə daha çox.

Konteynerlərin serverlərdə birbaşa işlədilməsi problemin yalnız bir hissəsidir. Digər hissə isə serverlərdə konteynerlərin yerləşdirilməsi ilə bağlıdır. Hansı konteynerin hansı serverə yerləşdirilə biləcəyini başa düşməlisiniz. Bu o qədər də asan məsələ deyil, çünki konteynerlər sürətini azaltmadan serverlərə mümkün qədər sıx yerləşdirilməlidir. Bu cür yerləşdirmə də nasazlığa dözümlülük baxımından çətin ola bilər. Çox vaxt biz eyni xidmətin replikalarını müxtəlif raflarda və ya hətta məlumat mərkəzinin müxtəlif otaqlarında yerləşdirmək istəyirik ki, raf və ya otaq uğursuz olarsa, bütün xidmət replikalarını dərhal itirməyək.

8 min serveriniz və 8-16 min konteyneriniz olduqda konteynerlərin əl ilə paylanması seçim deyil.

Bundan əlavə, biz tərtibatçılara resurs bölgüsündə daha çox müstəqillik vermək istədik ki, onlar administratorun köməyi olmadan öz xidmətlərini istehsalda yerləşdirə bilsinlər. Eyni zamanda, bəzi kiçik xidmətlər məlumat mərkəzlərimizin bütün resurslarını istehlak etməsin deyə nəzarəti saxlamaq istədik.

Aydındır ki, bizə bunu avtomatik edəcək bir nəzarət təbəqəsi lazımdır.

Beləliklə, bütün memarların pərəstiş etdiyi sadə və başa düşülən bir mənzərəyə gəldik: üç kvadrat.

bir bulud ustası bulud orkestrinə cavabdeh olan uğursuzluq klasteridir. Tərtibatçı ustaya xidmətin yerləşdirilməsi üçün lazım olan bütün məlumatları ehtiva edən bir manifest göndərir. Buna əsaslanaraq, usta seçilmiş minionlara (konteynerləri idarə etmək üçün nəzərdə tutulmuş maşınlar) əmrlər verir. Əmrləri qəbul edən agentimiz var, Docker-ə əmrlər verir və Docker müvafiq konteyneri işə salmaq üçün linux nüvəsini konfiqurasiya edir. Əmrləri yerinə yetirməklə yanaşı, agent davamlı olaraq həm minion maşınının, həm də onun üzərində işləyən konteynerlərin vəziyyətindəki dəyişikliklər haqqında ustaya hesabat verir.

Resurs bölgüsü

İndi bir çox minionlar üçün daha mürəkkəb resursların ayrılması probleminə baxaq.

Bir buludda hesablama resursu:

Müəyyən bir tapşırıq üçün istehlak edilən prosessor gücünün miqdarı.
Tapşırıq üçün mövcud yaddaşın miqdarı.
Şəbəkə trafiki. Minionların hər biri məhdud bant genişliyi olan xüsusi şəbəkə interfeysinə malikdir, ona görə də onların şəbəkə üzərindən ötürdükləri məlumatların miqdarını nəzərə almadan tapşırıqları paylamaq mümkün deyil.
Disklər. Bundan əlavə, açıq-aydın, bu tapşırıqlar üçün yerə biz də disk növünü ayırırıq: HDD və ya SSD. Disklər saniyədə məhdud sayda sorğuya xidmət edə bilər - IOPS. Buna görə də, bir diskin öhdəsindən gələ biləcəyindən daha çox IOPS yaradan vəzifələr üçün biz həmçinin "millər" ayırırıq - yəni yalnız tapşırıq üçün ayrılmış disk cihazlarını.

Sonra bəzi xidmətlər üçün, məsələn, istifadəçi keşi üçün, istehlak edilmiş resursları bu şəkildə qeyd edə bilərik: 400 prosessor nüvəsi, 2,5 TB yaddaş, hər iki istiqamətdə 50 Gbit/s trafik, 6 mil üzərində yerləşən 100 TB HDD sahəsi. Və ya bu kimi daha tanış formada:

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

İstifadəçi-keş xidmət resursları istehsal infrastrukturunda mövcud olan bütün resursların yalnız bir hissəsini istehlak edir. Buna görə də əmin olmaq istəyirəm ki, birdən-birə operator xətası olub-olmaması səbəbindən istifadəçi önbelleği ona ayrılandan daha çox resurs sərf etmir. Yəni biz resursları məhdudlaşdırmalıyıq. Bəs biz kvotanı nəyə bağlaya bilərdik?

Komponentlərin qarşılıqlı əlaqəsinin çox sadələşdirilmiş diaqramına qayıdaq və onu daha ətraflı şəkildə yenidən çəkək - bu kimi:

Gözünüzü nə cəlb edir:

Veb cəbhəsi və musiqi eyni proqram serverinin təcrid olunmuş qruplarından istifadə edir.
Bu klasterlərin aid olduğu məntiqi təbəqələri ayırd edə bilərik: cəbhələr, keşlər, məlumatların saxlanması və idarəetmə səviyyəsi.
Frontend heterojendir, müxtəlif funksional alt sistemlərdən ibarətdir.
Keşlər həmçinin məlumatlarını keşlədikləri alt sistemə səpələnə bilər.

Şəkli yenidən çəkək:

Bəh! Bəli, biz bir iyerarxiya görürük! Bu o deməkdir ki, siz resursları daha böyük hissələrə bölə bilərsiniz: funksional alt sistemə uyğun gələn bu iyerarxiyanın qovşağına məsul tərtibatçı təyin edin (şəkildəki “musiqi” kimi) və iyerarxiyanın eyni səviyyəsinə kvota əlavə edin. Bu iyerarxiya həm də idarəetmənin asanlığı üçün xidmətləri daha çevik təşkil etməyə imkan verir. Məsələn, biz bütün interneti bölürük, çünki bu, çox böyük serverlər qrupudur, şəkildə qrup1, qrup2 kimi göstərilən bir neçə kiçik qrupa bölünür.

Əlavə sətirləri silməklə şəklimizin hər bir düyününü daha düz formada yaza bilərik: group1.web.front, api.music.front, user-cache.cache.

Biz “ierarxik növbə” anlayışına belə gəlirik. Onun "group1.web.front" kimi bir adı var. Ona resurslar və istifadəçi hüquqları üçün kvota təyin edilir. Biz DevOps-dan olan şəxsə növbəyə xidmət göndərmək hüququnu verəcəyik və belə bir işçi növbədə nəsə işə sala bilər, OpsDev-dən olan şəxs isə admin hüquqlarına sahib olacaq və indi o növbəni idarə edə, orada insanları təyin edə bilər, bu insanlara hüquqlar verin və s. Bu növbədə işləyən xidmətlər növbənin kvotası daxilində işləyəcək. Əgər növbənin hesablama kvotası bütün xidmətləri bir anda yerinə yetirmək üçün kifayət etmirsə, o zaman onlar ardıcıllıqla yerinə yetiriləcək və beləliklə növbənin özü formalaşacaq.

Xidmətlərə daha yaxından nəzər salaq. Xidmətin hər zaman növbənin adını ehtiva edən tam uyğun adı var. Sonra ön veb xidmətinin adı olacaq ok-web.group1.web.front. Və onun daxil olduğu proqram serveri xidməti çağırılacaq ok-app.group1.web.front. Hər bir xidmətin xüsusi maşınlarda yerləşdirilməsi üçün bütün lazımi məlumatları göstərən bir manifest var: bu tapşırıq nə qədər resurs istehlak edir, bunun üçün hansı konfiqurasiya lazımdır, neçə replika olmalıdır, bu xidmətin uğursuzluqlarını idarə etmək üçün xüsusiyyətlər. Xidmət birbaşa maşınlara yerləşdirildikdən sonra onun nümunələri görünür. Onlar həmçinin birmənalı olaraq adlandırılır - nümunə nömrəsi və xidmət adı kimi: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

Bu, çox rahatdır: yalnız işləyən konteynerin adına baxaraq, biz dərhal çox şey öyrənə bilərik.

İndi bu nümunələrin əslində nə yerinə yetirdiyinə daha yaxından nəzər salaq: tapşırıqlar.

Tapşırıqların İzolyasiya Dərsləri

OK-dəki bütün tapşırıqları (və yəqin ki, hər yerdə) qruplara bölmək olar:

Qısa Gecikmə Tapşırıqları - məhsul. Bu cür tapşırıqlar və xidmətlər üçün cavab gecikməsi (gecikmə), sorğuların hər birinin sistem tərəfindən nə qədər tez işlənəcəyi çox vacibdir. Tapşırıqların nümunələri: veb cəbhələri, keşlər, proqram serverləri, OLTP yaddaşı və s.
Hesablama problemləri - toplu. Burada hər bir xüsusi sorğunun emal sürəti vacib deyil. Onlar üçün bu tapşırığın müəyyən (uzun) müddətdə (verim gücündə) neçə hesablama aparacağı vacibdir. Bunlar MapReduce, Hadoop, maşın öyrənməsi, statistikanın istənilən tapşırıqları olacaq.
Fon vəzifələri - boş. Bu cür tapşırıqlar üçün nə gecikmə, nə də ötürmə çox vacib deyil. Buraya müxtəlif testlər, köçürmələr, yenidən hesablamalar və məlumatların bir formatdan digərinə çevrilməsi daxildir. Bir tərəfdən, onlar hesablanmışlara bənzəyir, digər tərəfdən, onların nə qədər tez tamamlanmasının bizim üçün heç bir əhəmiyyəti yoxdur.

Gəlin görək bu cür tapşırıqlar resursları, məsələn, mərkəzi prosessoru necə istehlak edir.

Qısa gecikmə vəzifələri. Belə bir tapşırıqda buna bənzər bir CPU istehlak nümunəsi olacaq:

İstifadəçidən sorğu emal üçün qəbul edilir, tapşırıq bütün mövcud CPU nüvələrindən istifadə etməyə başlayır, onu emal edir, cavab qaytarır, növbəti sorğunu gözləyir və dayanır. Növbəti sorğu gəldi - yenə orada olan hər şeyi seçdik, hesabladıq və növbətisini gözləyirik.

Belə bir tapşırıq üçün minimum gecikmə müddətini təmin etmək üçün onun istehlak etdiyi maksimum resursları götürməli və minionda (tapşırığı yerinə yetirəcək maşın) lazımi sayda nüvəni saxlamalıyıq. Onda problemimiz üçün rezervasiya düsturu aşağıdakı kimi olacaq:

alloc: cpu = 4 (max)

və əgər 16 nüvəli minion maşınımız varsa, onda tam olaraq dörd belə tapşırıq qoyula bilər. Xüsusilə qeyd edirik ki, bu cür tapşırıqların orta prosessor istehlakı çox vaxt çox aşağıdır - bu, açıqdır, çünki tapşırıq vaxtın əhəmiyyətli bir hissəsi sorğu gözləyir və heç bir şey etmir.

Hesablama tapşırıqları. Onların nümunəsi bir az fərqli olacaq:

Bu cür tapşırıqlar üçün orta CPU resurs istehlakı olduqca yüksəkdir. Çox vaxt biz hesablama tapşırığının müəyyən vaxt ərzində yerinə yetirilməsini istəyirik, ona görə də bütün hesablamanın məqbul vaxt ərzində başa çatdırılması üçün ona lazım olan minimum prosessor sayını ehtiyatda saxlamalıyıq. Onun rezervasiya formulu belə görünəcək:

alloc: cpu = [1,*)

"Lütfən, onu ən azı bir boş nüvənin olduğu bir minionun üzərinə qoyun, sonra nə qədər varsa, hər şeyi yeyəcək."

Burada istifadənin səmərəliliyi qısa bir gecikmə ilə tapşırıqlardan daha yaxşıdır. Ancaq hər iki növ tapşırığı bir minion maşınında birləşdirsəniz və onun resurslarını yolda paylasanız, qazanc daha çox olacaq. Qısa gecikmə ilə bir tapşırıq bir prosessor tələb etdikdə, onu dərhal qəbul edir və resurslara ehtiyac qalmadıqda, onlar hesablama tapşırığına köçürülür, yəni belə bir şey:

Bəs bunu necə etmək olar?

Əvvəlcə məhsula və onun bölgüsünə baxaq: cpu = 4. Biz dörd nüvəni ehtiyatda saxlamalıyıq. Docker run-da bu iki yolla edilə bilər:

Seçimdən istifadə etməklə --cpuset=1-4, yəni tapşırıq üçün maşında dörd xüsusi nüvəni ayırın.
Istifadə --cpuquota=400_000 --cpuperiod=100_000, prosessor vaxtı üçün kvota təyin edin, yəni hər 100 ms real vaxtda tapşırığın prosessorun 400 ms-dən çox vaxt sərf etmədiyini göstərin. Eyni dörd nüvə əldə edilir.

Bəs bu üsullardan hansı uyğun gəlir?

cpuset olduqca cəlbedici görünür. Tapşırığın dörd xüsusi nüvəsi var, yəni prosessor keşləri mümkün qədər səmərəli işləyəcək. Bunun da mənfi tərəfi var: biz OS əvəzinə maşının boşaldılmış nüvələri üzrə hesablamaları paylamaq tapşırığını öz öhdəmizə götürməli olacaqdıq və bu, olduqca qeyri-ciddi bir işdir, xüsusən də belə bir sistemə toplu tapşırıqlar qoymağa çalışsaq. maşın. Testlər göstərdi ki, kvota ilə seçim burada daha uyğundur: bu yolla əməliyyat sistemi cari anda tapşırığı yerinə yetirmək üçün nüvəni seçməkdə daha çox sərbəstliyə malikdir və prosessor vaxtı daha səmərəli paylanır.

Minimum nüvə sayına əsaslanaraq Docker-də rezervasiyaların necə ediləcəyini anlayaq. Toplu tapşırıqlar üçün kvota artıq tətbiq edilmir, çünki maksimumu məhdudlaşdırmağa ehtiyac yoxdur, sadəcə minimuma zəmanət vermək kifayətdir. Və burada seçim yaxşı uyğun gəlir docker run --cpushares.

Razılaşdıq ki, əgər partiya ən azı bir nüvə üçün zəmanət tələb edirsə, o zaman qeyd edirik --cpushares=1024, və ən azı iki nüvə varsa, biz göstəririk --cpushares=2048. CPU payları kifayət qədər olduğu müddətcə prosessor vaxtının paylanmasına heç bir şəkildə müdaxilə etmir. Beləliklə, əgər məhsul hazırda dörd nüvənin hamısından istifadə etmirsə, toplu tapşırıqları məhdudlaşdıran heç bir şey yoxdur və onlar əlavə prosessor vaxtından istifadə edə bilərlər. Lakin prosessor çatışmazlığı olan bir vəziyyətdə, əgər məhsul dörd nüvənin hamısını istehlak edibsə və öz kvotasına çatıbsa, qalan prosessor vaxtı cpushares-ə mütənasib olaraq bölünəcək, yəni üç boş nüvəli vəziyyətdə, biri olacaq. 1024 cpushare olan bir tapşırığa, qalan ikisi isə 2048 cpushare olan bir vəzifəyə veriləcək.

Amma kvota və paylardan istifadə kifayət deyil. Qısa gecikmə ilə bir tapşırığın prosessor vaxtını ayırarkən toplu tapşırığa üstünlük verdiyinə əmin olmalıyıq. Bu cür prioritetləşdirmə olmadan, toplu tapşırığın məhsula ehtiyac duyduğu anda prosessorun bütün vaxtını alacaq. Docker-də konteyner prioritetləşdirmə variantları yoxdur, lakin Linux CPU planlaşdırıcı siyasətləri faydalıdır. Onlar haqqında ətraflı oxuya bilərsiniz burada, və bu məqalə çərçivəsində biz onları qısaca nəzərdən keçirəcəyik:

SCHED_OTHER
Varsayılan olaraq, Linux maşınındakı bütün normal istifadəçi prosesləri qəbul edilir.
SCHED_BATCH
Resurs tutumlu proseslər üçün nəzərdə tutulmuşdur. Prosessora tapşırığı yerləşdirərkən, aktivləşdirmə cəzası tətbiq edilir: belə bir tapşırıq SCHED_OTHER ilə tapşırıq tərəfindən hazırda istifadə olunursa, prosessor resurslarını qəbul etmək ehtimalı azdır.
SCHED_IDLE
Çox aşağı prioritetli fon prosesi, hətta gözəl -19-dan da aşağıdır. Biz açıq mənbə kitabxanamızdan istifadə edirik bir-nio, zəng edərək konteyneri işə salarkən lazımi siyasəti təyin etmək üçün

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

Java-da proqramlaşdırmasanız belə, eyni şeyi chrt əmrindən istifadə etməklə etmək olar:

chrt -i 0 $pid

Aydınlıq üçün bütün izolyasiya səviyyələrimizi bir cədvəldə ümumiləşdirək:

İzolyasiya sinfi
Ayırma nümunəsi
Docker run variantları
sched_setscheduler chrt*

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

Dəstə
CPU = [1, *)
--cpushares=1024
SCHED_BATCH

boş
CPU= [2, *)
--cpushares=2048
SCHED_IDLE

*Bir konteynerin içindən chrt edirsinizsə, sys_nice qabiliyyətinə ehtiyacınız ola bilər, çünki defolt olaraq Docker konteyneri işə salarkən bu qabiliyyəti aradan qaldırır.

Lakin tapşırıqlar təkcə prosessoru deyil, həm də trafiki istehlak edir ki, bu da şəbəkə tapşırığının gecikməsinə prosessor resurslarının səhv yerləşdirilməsindən daha çox təsir edir. Buna görə də biz təbii olaraq trafik üçün eyni mənzərəni əldə etmək istəyirik. Yəni, istehsal tapşırığı bəzi paketləri şəbəkəyə göndərdikdə, biz maksimum sürəti məhdudlaşdırırıq (formula ayırma: lan=[*,500mbps) ), hansı məhsul bunu edə bilər. Partiya üçün yalnız minimum ötürmə qabiliyyətinə zəmanət veririk, lakin maksimumu məhdudlaşdırmırıq (formula ayırma: lan=[10Mbps,*) ) Bu halda məhsul trafiki toplu tapşırıqlar üzərində prioritet almalıdır.
Burada Docker-də istifadə edə biləcəyimiz primitivlər yoxdur. Amma bizim köməyimizə gəlir Linux Trafik Nəzarəti. Biz nizam-intizamla istədiyimiz nəticəni əldə edə bildik İerarxik Ədalətli Xidmət Əyrisi. Onun köməyi ilə biz trafikin iki sinfini ayırırıq: yüksək prioritetli məhsul və aşağı prioritetli partiya/boş. Nəticədə, gedən trafik üçün konfiqurasiya belədir:

burada 1:0 hsfc intizamının “kök qdisc”idir; 1:1 - bütün konteynerlərin uşaq siniflərinin yerləşdirildiyi ümumi ötürmə qabiliyyəti həddi 8 Gbit/s olan hsfc uşaq sinfi; 1:2 - hsfc uşaq sinfi aşağıda müzakirə olunan “dinamik” limiti olan bütün toplu və boş tapşırıqlar üçün ümumidir. Qalan hsfc uşaq sinifləri, onların manifestlərinə uyğun limitlərlə - 450 və 400 Mbit/s-ə malik, hazırda işləyən istehsal konteynerləri üçün ayrılmış siniflərdir. Hər bir hsfc sinifinə trafik partlayışları zamanı paket itkisinin qarşısını almaq üçün Linux nüvəsi versiyasından asılı olaraq qdisc növbəsi fq və ya fq_codel təyin edilir.

Tipik olaraq, tc intizamları yalnız gedən trafikə üstünlük verməyə xidmət edir. Amma biz daxil olan trafikə də üstünlük vermək istəyirik - axı, bəzi toplu tapşırıq asanlıqla bütün daxil olan kanalı seçə bilər, məsələn, xəritə və azaldılması üçün daxil edilmiş məlumatların böyük partiyasını qəbul edir. Bunun üçün moduldan istifadə edirik ifb, hər bir şəbəkə interfeysi üçün ifbX virtual interfeysi yaradır və daxil olan trafiki interfeysdən ifbX-də gedən trafikə yönləndirir. Bundan əlavə, ifbX üçün, hsfc konfiqurasiyası çox oxşar olacaq gedən trafikə nəzarət etmək üçün bütün eyni fənlər işləyir:

Təcrübələr zamanı biz hsfc-nin 1:2 sinifli qeyri-prioritet toplu/boş trafikin minion maşınlarında müəyyən bir sərbəst zolaqdan çox olmamaqla məhdudlaşdırıldığı zaman ən yaxşı nəticələri göstərdiyini öyrəndik. Əks halda, prioritet olmayan trafik məhsul tapşırıqlarının gecikməsinə çox təsir edir. miniond, verilən minionun bütün məhsul tapşırıqlarının orta trafik istehlakını ölçərək, hər saniyədə cari pulsuz bant genişliyini müəyyən edir. və onu şəbəkə interfeysinin bant genişliyindən çıxmaq kiçik bir marja ilə, yəni.

Qruplar daxil olan və gedən trafik üçün müstəqil olaraq müəyyən edilir. Və yeni dəyərlərə görə, miniond prioritet olmayan sinif limitini 1:2 olaraq yenidən konfiqurasiya edir.

Beləliklə, biz hər üç izolyasiya sinfini həyata keçirdik: istehsal, toplu və boş. Bu siniflər tapşırıqların icra xüsusiyyətlərinə böyük təsir göstərir. Buna görə də, biz bu atributu iyerarxiyanın yuxarısına yerləşdirmək qərarına gəldik ki, iyerarxik növbənin adına baxarkən nə ilə məşğul olduğumuz dərhal aydın olsun:

Bütün dostlarımız web и musiqi cəbhələr daha sonra prod altında iyerarxiyada yerləşdirilir. Məsələn, toplu altında, xidməti yerləşdirək musiqi kataloqu, Odnoklassniki-yə yüklənmiş mp3 faylları toplusundan vaxtaşırı treklər kataloqu tərtib edir. Boş vəziyyətdə olan bir xidmətə misal ola bilər musiqi transformatoru, musiqinin səs səviyyəsini normallaşdırır.

Əlavə sətirlər yenidən silindikdə, tam xidmət adının sonuna tapşırıq izolyasiya sinfini əlavə etməklə xidmət adlarımızı daha yaltaq yaza bilərik: web.front.prod, kataloq.musiqi.top, transformator.musiqi.boş.

İndi isə xidmətin adına baxaraq, onun nəinki hansı funksiyanı yerinə yetirdiyini, həm də onun kritikliyini ifadə edən izolyasiya sinfini və s.

Hər şey əladır, amma bir acı həqiqət var. Bir maşında işləyən vəzifələri tamamilə təcrid etmək mümkün deyil.

Nəyə nail ola bildik: əgər partiya intensiv şəkildə istehlak edərsə yalnız CPU resursları, sonra daxili Linux CPU planlaşdırıcısı öz işini çox yaxşı yerinə yetirir və məhsul tapşırığına praktiki olaraq heç bir təsir yoxdur. Ancaq bu toplu tapşırıq yaddaşla aktiv şəkildə işləməyə başlayırsa, qarşılıqlı təsir artıq görünür. Bu, məhsul tapşırığının prosessorun yaddaş yaddaşından “yuyulması” ilə baş verir - nəticədə, keş buraxılışları artır və prosessor məhsul tapşırığını daha yavaş emal edir. Belə bir toplu tapşırıq tipik məhsul konteynerimizin gecikmə müddətini 10% artıra bilər.

Müasir şəbəkə kartlarında paketlərin daxili növbəsi olması səbəbindən trafiki təcrid etmək daha da çətindir. Əgər toplu tapşırığın paketi əvvəlcə oraya çatarsa, o zaman kabel vasitəsilə ilk ötürülən olacaq və bununla bağlı heç nə etmək olmaz.

Bundan əlavə, biz indiyə qədər yalnız TCP trafikinin prioritetləşdirilməsi problemini həll edə bilmişik: hsfc yanaşması UDP üçün işləmir. Və hətta TCP trafiki vəziyyətində, toplu tapşırıq çoxlu trafik yaradırsa, bu da məhsul tapşırığının gecikməsində təxminən 10% artım verir.

xətaya dözümlülük

Bir bulud inkişaf etdirərkən məqsədlərdən biri Odnoklassniki-nin səhvlərə dözümlülüyünü artırmaq idi. Buna görə də, növbəti uğursuzluqların və qəzaların mümkün ssenarilərini daha ətraflı nəzərdən keçirmək istərdim. Sadə bir ssenari ilə başlayaq - konteyner çatışmazlığı.

Konteynerin özü bir neçə yolla uğursuz ola bilər. Bu, manifestdəki bir növ təcrübə, səhv və ya səhv ola bilər, buna görə məhsul tapşırığı manifestdə göstəriləndən daha çox resurs istehlak etməyə başlayır. Bir işimiz var idi: bir tərtibatçı bir mürəkkəb alqoritmi tətbiq etdi, onu dəfələrlə yenidən işlədi, özünü çox düşündü və o qədər çaşqın oldu ki, nəticədə problem çox qeyri-ciddi şəkildə həll olundu. Və istehsal tapşırığı eyni minionlardakı bütün digərlərindən daha yüksək prioritetə malik olduğundan, o, bütün mövcud prosessor resurslarını istehlak etməyə başladı. Bu vəziyyətdə, izolyasiya, daha doğrusu CPU vaxt kvotası günü xilas etdi. Əgər tapşırığa kvota ayrılıbsa, tapşırıq daha çox istehlak etməyəcək. Buna görə də, eyni maşında işləyən toplu və digər məhsul tapşırıqları heç bir şey hiss etmədi.

İkinci mümkün problem konteynerin düşməsidir. Və burada yenidən başladın siyasətlər bizi xilas edir, hamı onları bilir, Docker özü əla iş görür. Demək olar ki, bütün istehsal tapşırıqları həmişə yenidən başladın siyasətə malikdir. Bəzən biz toplu tapşırıqlar üçün və ya məhsul konteynerlərini sazlamaq üçün on_failure istifadə edirik.

Bütün minion əlçatan deyilsə, nə edə bilərsiniz?

Aydındır ki, konteyneri başqa bir maşında işlədin. Burada maraqlı hissə konteynerə təyin edilmiş IP ünvan(lar) ilə nə baş verməsidir.

Biz konteynerlərə bu konteynerlərin işlədiyi minion maşınları ilə eyni IP ünvanlarını təyin edə bilərik. Sonra konteyner başqa maşında işə salındıqda onun İP ünvanı dəyişir və bütün müştərilər konteynerin yerdəyişdiyini başa düşməlidirlər və indi onlar ayrı bir Service Discovery xidmətini tələb edən başqa ünvana getməlidirlər.

Xidmət kəşfi rahatdır. Bazarda xidmət reyestrinin təşkili üçün müxtəlif dərəcələrdə nasazlıqlara qarşı dözümlülüyün bir çox həlli var. Çox vaxt bu cür həllər yük balanslaşdırıcı məntiqi həyata keçirir, əlavə konfiqurasiyanı KV saxlama şəklində saxlayır və s.
Bununla belə, ayrıca reyestrin tətbiqinə ehtiyacdan qaçmaq istərdik, çünki bu, istehsalda bütün xidmətlər tərəfindən istifadə olunan kritik sistemin tətbiqi demək olardı. Bu o deməkdir ki, bu, potensial uğursuzluq nöqtəsidir və siz çox qüsurlara dözümlü bir həll seçməli və ya inkişaf etdirməlisiniz, bu açıq-aydın çox çətin, vaxt aparan və bahalıdır.

Və daha bir böyük çatışmazlıq: köhnə infrastrukturumuzun yenisi ilə işləməsi üçün bir növ Service Discovery sistemindən istifadə etmək üçün bütün tapşırıqları yenidən yazmalıyıq. Çox iş var və bəzi yerlərdə OS nüvəsi səviyyəsində və ya birbaşa aparatla işləyən aşağı səviyyəli cihazlara gəldikdə demək olar ki, mümkün deyil. kimi müəyyən edilmiş həll nümunələrindən istifadə edərək bu funksionallığın həyata keçirilməsi yan avtomobil bəzi yerlərdə əlavə yük, digərlərində - əməliyyatın mürəkkəbliyi və əlavə uğursuzluq ssenariləri deməkdir. İşləri çətinləşdirmək istəmədik, ona görə də Xidmət Kəşfindən istifadəni isteğe bağlı etmək qərarına gəldik.

Bir buludda IP konteyneri izləyir, yəni hər tapşırıq nümunəsinin öz IP ünvanı var. Bu ünvan “statikdir”: xidmət ilk dəfə buluda göndərildikdə o, hər bir instansiyaya təyin edilir. Əgər xidmət ömrü boyu fərqli sayda nümunələrə malik idisə, sonda ona maksimum nümunələrin sayı qədər IP ünvanı təyin ediləcək.

Sonradan bu ünvanlar dəyişmir: onlar bir dəfə təyin olunur və istehsalda xidmətin bütün ömrü boyu mövcud olmağa davam edir. IP ünvanları şəbəkə boyunca konteynerləri izləyir. Konteyner başqa miniona ötürülürsə, o zaman ünvan onu izləyəcək.

Beləliklə, xidmət adının onun IP ünvanları siyahısına uyğunlaşdırılması çox nadir hallarda dəyişir. Məqalənin əvvəlində qeyd etdiyimiz xidmət instansiyalarının adlarına yenidən baxsanız (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), onların DNS-də istifadə olunan FQDN-lərə bənzədiyini görəcəyik. Düzdür, xidmət nümunələrinin adlarını onların IP ünvanlarına uyğunlaşdırmaq üçün DNS protokolundan istifadə edirik. Üstəlik, bu DNS bütün konteynerlərin bütün qorunan IP ünvanlarını qaytarır - həm işləyən, həm də dayandırılmışdır (tutaq ki, üç replikadan istifadə olunur və orada beş ünvan qorunub saxlanılır - beşinin hamısı qaytarılacaq). Müştərilər bu məlumatı əldə edərək, bütün beş replika ilə əlaqə yaratmağa çalışacaqlar və bununla da işləyənləri müəyyənləşdirəcəklər. Mövcudluğu müəyyən etmək üçün bu seçim daha etibarlıdır, o, nə DNS, nə də Service Discovery-ni əhatə etmir, yəni məlumatın aktuallığını və bu sistemlərin nasazlıqlara dözümlülüyünü təmin etmək üçün həll edilməsi çətin problemlər yoxdur. Üstəlik, bütün portalın fəaliyyətinin asılı olduğu kritik xidmətlərdə biz DNS-dən ümumiyyətlə istifadə edə bilmirik, sadəcə olaraq konfiqurasiyaya IP ünvanlarını daxil edirik.

Konteynerlərin arxasında belə IP ötürülməsini həyata keçirmək qeyri-ciddi ola bilər - və biz bunun necə işlədiyinə aşağıdakı nümunə ilə baxacağıq:

Tutaq ki, bir buludlu usta minion M1-ə qaçmaq əmrini verir 1.ok-web.group1.web.front.prod 1.1.1.1 ünvanı ilə. Minion üzərində işləyir Quş, bu ünvanı xüsusi serverlərə reklam edən marşrut reflektoru. Sonuncular, M1.1.1.1-də 1 ünvanının marşrutunun tərcümə olunduğu şəbəkə avadanlığı ilə BGP sessiyasına malikdirlər. M1 Linux istifadə edərək paketləri konteynerin içərisinə yönləndirir. Üç marşrut reflektor serveri var, çünki bu, bir bulud infrastrukturunun çox vacib hissəsidir - onlarsız bir buludda şəbəkə işləməyəcəkdir. Hər üçünün eyni anda sıradan çıxma ehtimalını azaltmaq üçün onları məlumat mərkəzinin müxtəlif otaqlarında, mümkünsə, müxtəlif raflara yerləşdiririk.

İndi fərz edək ki, bir bulud ustası ilə M1 minionu arasında əlaqə itib. Bir bulud ustası indi M1-in tamamilə uğursuz olduğu fərziyyəsi ilə hərəkət edəcək. Yəni, M2 minionuna atmaq əmrini verəcək web.group1.web.front.prod eyni ünvanla 1.1.1.1. İndi 1.1.1.1 üçün şəbəkədə iki ziddiyyətli marşrutumuz var: M1 və M2-də. Bu cür münaqişələri həll etmək üçün biz BGP elanında göstərilən Çox Çıxış Diskriminatorundan istifadə edirik. Bu, reklam edilən marşrutun ağırlığını göstərən rəqəmdir. Ziddiyyətli marşrutlar arasında daha aşağı MED dəyəri olan marşrut seçiləcək. Bir buludlu master konteyner IP ünvanlarının tərkib hissəsi kimi MED-i dəstəkləyir. İlk dəfə ünvan kifayət qədər böyük MED = 1 ilə yazılır.Belə bir təcili konteyner köçürmə vəziyyətində, master MED-i azaldır və M000 artıq MED = ilə 000 ünvanını reklam etmək əmrini alacaq. 2. M1.1.1.1-də işləyən instansiya bu halda qalacaq, bu halda heç bir əlaqə yoxdur və usta ilə əlaqə bərpa olunana qədər, köhnə çəkiliş kimi dayandırılıncaya qədər onun sonrakı taleyi bizi az maraqlandırır.

Qəzalar

Bütün məlumat mərkəzi idarəetmə sistemləri həmişə kiçik uğursuzluqları məqbul şəkildə idarə edir. Konteynerin daşması demək olar ki, hər yerdə normadır.

Məlumat mərkəzinin bir və ya bir neçə otağında elektrik kəsilməsi kimi fövqəladə vəziyyətlə necə məşğul olduğumuza baxaq.

Məlumat mərkəzi idarəetmə sistemi üçün qəza nə deməkdir? Əvvəla, bu, bir çox maşının kütləvi birdəfəlik nasazlığıdır və idarəetmə sistemi eyni zamanda çoxlu konteynerləri köçürməlidir. Ancaq fəlakət çox geniş miqyaslıdırsa, o zaman bütün tapşırıqların digər minionlara yenidən bölünə bilməyəcəyi baş verə bilər, çünki məlumat mərkəzinin resurs tutumu yükün 100% -dən aşağı düşür.

Çox vaxt qəzalar idarəetmə təbəqəsinin nasazlığı ilə müşayiət olunur. Bu, onun avadanlıqlarının nasazlığı səbəbindən baş verə bilər, lakin daha tez-tez qəzaların sınaqdan keçirilməməsi və artan yük səbəbindən idarəetmə təbəqəsinin özü düşür.

Bütün bunlara qarşı nə edə bilərsiniz?

Kütləvi miqrasiya o deməkdir ki, infrastrukturda çoxlu sayda fəaliyyət, miqrasiya və yerləşdirmə baş verir. Miqrasiyaların hər biri konteyner şəkillərini minionlara çatdırmaq və qablaşdırmadan açmaq, konteynerləri işə salmaq və işə salmaq və s. üçün bir qədər vaxt tələb oluna bilər. Buna görə də, daha vacib tapşırıqların daha az vacib olanlardan əvvəl başlaması arzu edilir.

Gəlin tanış olduğumuz xidmətlərin iyerarxiyasına yenidən baxaq və ilk olaraq hansı tapşırıqları yerinə yetirmək istədiyimizə qərar verməyə çalışaq.

Əlbəttə ki, bunlar birbaşa istifadəçi sorğularının işlənməsi ilə məşğul olan proseslərdir, yəni prod. ilə bunu göstəririk yerləşdirmə prioriteti — növbəyə təyin edilə bilən nömrə. Əgər növbə daha yüksək prioritetə malikdirsə, onun xidmətləri birinci yerə qoyulur.

Məhsulda biz daha yüksək prioritetlər təyin edirik, 0; partiyada - bir az aşağı, 100; boşda - daha da aşağı, 200. Prioritetlər iyerarxik olaraq tətbiq edilir. İyerarxiyada daha aşağı olan bütün tapşırıqlar müvafiq prioritetlərə malik olacaq. Əgər biz prod daxilindəki keşlərin frontendlərdən əvvəl işə salınmasını istəyiriksə, o zaman biz prioritetləri keş = 0 və ön alt növbələrə = 1 təyin edirik. Məsələn, biz əsas portalın əvvəlcə cəbhələrdən, yalnız musiqi ön hissəsindən işə salınmasını istəyirik. onda biz sonuncuya daha aşağı prioritet təyin edə bilərik - 10.

Növbəti problem resursların çatışmazlığıdır. Beləliklə, böyük miqdarda avadanlıq, məlumat mərkəzinin bütün salonları uğursuz oldu və biz o qədər çox xidmətləri yenidən işə saldıq ki, indi hər kəs üçün kifayət qədər resurs yoxdur. Əsas kritik xidmətlərin davam etməsi üçün hansı vəzifələri qurban verəcəyinizə qərar verməlisiniz.

Yerləşdirmə prioritetindən fərqli olaraq, biz bütün toplu tapşırıqları fərq etmədən qurban verə bilmərik; onlardan bəziləri portalın fəaliyyəti üçün vacibdir. Buna görə də ayrıca vurğuladıq üstünlük prioriteti tapşırıqlar. Yerləşdirildikdə, daha yüksək prioritet vəzifəni qabaqlaya bilər, yəni daha pulsuz minionlar yoxdursa, daha aşağı prioritet tapşırığı dayandıra bilər. Bu halda, aşağı prioritet olan bir tapşırıq, ehtimal ki, yersiz qalacaq, yəni kifayət qədər pulsuz resursu olan uyğun bir minion artıq olmayacaq.

Bizim iyerarxiyamızda boş vaxt üçün prioritet 200-ə bərabər olmaqla, bir-birini deyil, istehsal və toplu tapşırıqların boş tapşırıqların qarşısını alması və ya dayandırması üçün üstünlük prioritetini müəyyən etmək çox sadədir. Yerləşdirmə prioritetində olduğu kimi, biz də daha mürəkkəb qaydaları təsvir etmək üçün iyerarxiyamızdan istifadə edə bilər. Məsələn, əsas veb portal üçün kifayət qədər resursumuz yoxdursa, müvafiq qovşaqlar üçün prioriteti aşağı salaraq, musiqi funksiyasını qurban verdiyimizi bildirək: 10.

Bütün DC qəzaları

Bütün məlumat mərkəzi niyə uğursuz ola bilər? Element. Yaxşı post idi qasırğa məlumat mərkəzinin işinə təsir göstərib. Elementlər bir vaxtlar manifoldda optikanı yandıran evsiz insanlar hesab edilə bilər və məlumat mərkəzi digər saytlarla əlaqəni tamamilə itirdi. Uğursuzluğun səbəbi insan faktoru da ola bilər: operator elə bir əmr verəcək ki, bütün məlumat mərkəzi düşəcək. Bu, böyük bir səhv səbəbindən baş verə bilər. Ümumiyyətlə, məlumat mərkəzlərinin dağılması qeyri-adi deyil. Bu, bir neçə ayda bir başımıza gəlir.

Və bu, hər kəsin #canlı tvit atmasının qarşısını almaq üçün etdiyimiz şeydir.

Birinci strategiya təcriddir. Hər bir bulud nümunəsi təcrid olunub və maşınları yalnız bir məlumat mərkəzində idarə edə bilər. Yəni, səhvlər və ya səhv operator əmrləri səbəbindən bir buludun itirilməsi yalnız bir məlumat mərkəzinin itirilməsidir. Biz buna hazırıq: tətbiqin və məlumatların replikalarının bütün məlumat mərkəzlərində yerləşdiyi ehtiyat siyasətimiz var. Biz xətaya dözümlü verilənlər bazalarından istifadə edirik və vaxtaşırı uğursuzluqları yoxlayırıq.
Bu gündən etibarən dörd məlumat mərkəzimiz var, bu, bir buludun dörd ayrı, tamamilə təcrid olunmuş nümunəsi deməkdir.

Bu yanaşma təkcə fiziki nasazlıqdan qorunmur, həm də operator səhvindən qoruya bilər.

İnsan amili ilə başqa nə etmək olar? Operator buluda qəribə və ya potensial təhlükəli əmr verdikdə, nə qədər yaxşı düşündüyünü görmək üçün birdən ondan kiçik bir problemi həll etməsi xahiş oluna bilər. Məsələn, bu, bir çox replikaların kütləvi dayandırılması və ya sadəcə qəribə bir əmrdirsə - replikaların sayını azaltmaq və ya təsvirin adını dəyişdirmək, nəinki yeni manifestdəki versiya nömrəsi.

Nəticələri

Bir buludun fərqli xüsusiyyətləri:

Xidmətlər və konteynerlər üçün iyerarxik və vizual adlandırma sxemitapşırığın nə olduğunu, nə ilə əlaqəli olduğunu və necə işlədiyini və bunun üçün kimin məsuliyyət daşıdığını çox tez öyrənməyə imkan verir.
Biz tətbiq edirik məhsul və partiyanın birləşdirilməsi texnikasımaşın mübadiləsinin səmərəliliyini artırmaq üçün minionlar üzərində tapşırıqlar. Cpuset əvəzinə biz CPU kvotalarından, səhmlərdən, CPU planlaşdırıcı siyasətlərindən və Linux QoS-dən istifadə edirik.
Eyni maşında işləyən konteynerləri tamamilə təcrid etmək mümkün olmadı, lakin onların qarşılıqlı təsiri 20% daxilində qalır.
Xidmətlərin iyerarxiyaya uyğun təşkili istifadə edərək avtomatik fəlakətin bərpasına kömək edir yerləşdirmə və üstünlük prioritetləri.

Suallar

Niyə biz hazır həll yolu götürmədik?

Fərqli sinif izolyasiyası minionlara yerləşdirildikdə fərqli məntiq tələb edir. Əgər istehsal tapşırıqları sadəcə ehtiyat ehtiyatı yaratmaqla yerləşdirilə bilərsə, o zaman minion maşınlarında resursların faktiki istifadəsini izləyərək toplu və boş tapşırıqlar yerləşdirilməlidir.
Tapşırıqlar tərəfindən istehlak olunan resursların nəzərə alınması ehtiyacı, məsələn:
- şəbəkə bant genişliyi;
- disklərin növləri və "milləri".
Fövqəladə hallara reaksiya zamanı xidmətlərin prioritetlərini, bir buludda iyerarxik növbələrdən istifadə etməklə həll olunan resurslar üçün əmrlərin hüquqlarını və kvotalarını göstərmək ehtiyacı.
Qəza və insidentlərə cavab müddətini azaltmaq üçün konteynerlərin insan adlandırılmasına ehtiyac
Service Discovery-nin birdəfəlik geniş tətbiqinin mümkünsüzlüyü; hardware hostlarında yerləşdirilən tapşırıqlarla uzun müddət birlikdə yaşamaq ehtiyacı - konteynerlərdən sonra "statik" IP ünvanları ilə həll olunan bir şey və nəticədə böyük şəbəkə infrastrukturu ilə unikal inteqrasiya ehtiyacı.

Bütün bu funksiyalar mövcud həllərin bizə uyğun olan əhəmiyyətli dəyişikliklərini tələb edəcək və işin həcmini qiymətləndirərək, təxminən eyni əmək xərcləri ilə öz həllimizi inkişaf etdirə biləcəyimizi başa düşdük. Ancaq həllinizi idarə etmək və inkişaf etdirmək daha asan olacaq - o, bizə lazım olmayan funksionallığı dəstəkləyən lazımsız abstraksiyaları ehtiva etmir.

Son sətirləri oxuyanlara, səbrinizə və diqqətinizə görə təşəkkür edirəm!

Mənbə: www.habr.com

Bir bulud - Odnoklassniki-də məlumat mərkəzi səviyyəli OS