Tupperware ilə istənilən miqyasda effektiv və etibarlı klaster idarəetməsi
Bu gün biz demək olar ki, bütün xidmətlərimizi idarə edən milyonlarla serverdə konteynerləri idarə edən klaster idarəetmə sistemimiz olan Tupperware-i təqdim etdik. Biz Tupperware-i ilk dəfə 2011-ci ildə yerləşdirdik və o vaxtdan bəri infrastrukturumuz daha da böyüdü. bütövlükdə . Bütün bu müddət ərzində Tupperware dayanmadı və bizimlə birlikdə inkişaf etdi. Biz sizə Tupperware-in birinci dərəcəli klaster idarəçiliyini, o cümlədən statistik xidmətlər üçün rahat dəstəyi, bütün məlumat mərkəzləri üçün vahid idarəetmə panelini və real vaxt rejimində xidmətlər arasında gücü bölüşdürmə qabiliyyətini göstərəcəyik. İnfrastrukturumuz inkişaf etdikcə öyrəndiyimiz dərsləri də paylaşacağıq.
Tupperware müxtəlif vəzifələri yerinə yetirir. Proqram tərtibatçıları proqramları çatdırmaq və idarə etmək üçün ondan istifadə edirlər. O, tətbiqin kodunu və asılılıqlarını şəkilə yığır və onu konteynerlər kimi serverlərə çatdırır. Konteynerlər eyni serverdəki proqramlar arasında izolyasiya təmin edir ki, tərtibatçılar proqram məntiqi ilə məşğul olsunlar və serverləri necə tapmaq və ya yeniləmələri idarə etmək barədə narahat olmasınlar. Tupperware həmçinin serverin sağlamlığına nəzarət edir və nasazlıq aşkar edərsə, konteynerləri problemli serverdən köçürür.
Tutumu planlaşdırma mühəndisləri Tupperware proqramından büdcə və məhdudiyyətlər əsasında komandalara server tutumunu ayırmaq üçün istifadə edirlər. Onlar həmçinin serverdən istifadəni yaxşılaşdırmaq üçün istifadə edirlər. Datacenter operatorları konteynerləri məlumat mərkəzləri arasında düzgün şəkildə paylamaq və təmir üçün konteynerləri dayandırmaq və ya köçürmək üçün Tupperware-ə müraciət edirlər. Bu səbəbdən serverlərə, şəbəkələrə və avadanlıqlara texniki qulluq minimal insan müdaxiləsini tələb edir.
Tupperware arxitekturası
Tupperware PRN arxitekturası bizim məlumat mərkəzi bölgələrimizdən biridir. Region yan-yana yerləşən bir neçə məlumat mərkəzi binasından (PRN1 və PRN2) ibarətdir. Biz bir bölgədəki bütün serverləri idarə edəcək bir idarəetmə paneli yaratmağı planlaşdırırıq.
Proqram tərtibatçıları xidmətləri Tupperware işləri kimi təqdim edirlər. İş bir neçə konteynerdən ibarətdir və onların hamısı adətən eyni proqram kodunu işlədir.
Tupperware konteynerlərin ayrılması və onların həyat dövrünün idarə edilməsi üçün məsuliyyət daşıyır. Bir neçə komponentdən ibarətdir:
- Tupperware cəbhəsi istifadəçi interfeysi, CLI və Tupperware ilə qarşılıqlı əlaqə qura biləcəyiniz digər avtomatlaşdırma vasitələri üçün API təmin edir. Onlar bütün daxili strukturu Tupperware iş sahiblərindən gizlədirlər.
- Tupperware Scheduler konteynerin və iş dövrünün idarə edilməsinə cavabdeh olan idarəetmə panelidir. O, regional və qlobal səviyyədə yerləşdirilir, burada regional planlaşdırıcı bir bölgədəki serverləri idarə edir və qlobal planlaşdırıcı müxtəlif bölgələrdən serverləri idarə edir. Planlayıcı parçalara bölünür və hər bir parça bir sıra işləri idarə edir.
- Tupperware planlaşdırıcı proksi daxili parçalanmanı gizlədir və Tupperware istifadəçiləri üçün rahat tək idarəetmə panelini təmin edir.
- Tupperware ayırıcısı serverlərə konteynerlər təyin edir. Planlaşdırıcı konteynerlərin dayandırılması, işə salınması, yenilənməsi və uğursuzluğuna görə məsuliyyət daşıyır. Hal-hazırda, bir distribyutor parçalanmadan bütün bölgəni idarə edə bilər. (Terminologiyadakı fərqə diqqət yetirin. Məsələn, Tupperware-də planlaşdırıcı idarəetmə panelinə uyğundur , və Tupperware ayırıcısı Kubernetesdə planlaşdırıcı adlanır.)
- Resurs brokeri server və xidmət hadisələri üçün həqiqət mənbəyini saxlayır. Biz hər bir məlumat mərkəzi üçün bir resurs brokeri işlədirik və o, həmin məlumat mərkəzindəki serverlər haqqında bütün məlumatları saxlayır. Resurs brokeri və potensialın idarə edilməsi sistemi və ya resurs bölgüsü sistemi, hansı planlaşdırıcı təchizatının hansı serveri idarə etdiyinə dinamik şəkildə qərar verir. Sağlamlıq yoxlaması xidməti serverlərə nəzarət edir və onların sağlamlıq məlumatlarını resurs brokerində saxlayır. Əgər serverdə problemlər varsa və ya texniki xidmətə ehtiyacı varsa, resurs brokeri ayırıcıya və planlaşdırıcıya konteynerləri dayandırmağı və ya onları başqa serverlərə köçürməyi bildirir.
- Tupperware agenti konteynerlərin hazırlanması və çıxarılması ilə məşğul olan hər bir serverdə işləyən bir demondur. Tətbiqlər konteynerin içərisində işləyir, bu da onlara daha çox izolyasiya və təkrar istehsal imkanı verir. Aktiv biz artıq təsvirlər, btrfs, cgroupv2 və systemd istifadə edərək fərdi Tupperware konteynerlərinin necə yaradıldığını təsvir etdik.
Tupperware-in fərqli xüsusiyyətləri
Tupperware bir çox cəhətdən Kubernetes və kimi digər klaster idarəetmə sistemlərinə bənzəyir , lakin bəzi fərqlər var:
- Dövlət xidmətləri üçün daxili dəstək.
- Niyyətə əsaslanan konteyner çatdırılmasını, klasterin istismardan çıxarılmasını və texniki xidməti avtomatlaşdırmaq üçün verilənlər mərkəzləri arasında serverlər üçün vahid idarəetmə paneli.
- Böyütmək üçün idarəetmə panelinin bölməsini silin.
- Elastik hesablama real vaxt rejimində xidmətlər arasında gücü bölüşdürməyə imkan verir.
Biz bu gözəl xüsusiyyətləri nəhəng qlobal paylaşılan server parkında müxtəlif vətəndaşlığı olmayan və statuslu proqramları dəstəkləmək üçün inkişaf etdirdik.
Dövlət xidmətləri üçün daxili dəstək.
Tupperware Facebook, Instagram, Messenger və WhatsApp üçün davamlı məhsul məlumatlarını saxlayan bir çox mühüm dövlət xidmətlərini idarə edir. Bunlar açar-dəyər cütlərinin böyük anbarları ola bilər (məsələn, ) və məlumat anbarlarının monitorinqi (məsələn, и ). Vəziyyəti bildirən xidmətlərin saxlanması asan deyil, çünki sistem konteyner daşımalarının şəbəkə kəsilməsi və ya elektrik kəsilməsi də daxil olmaqla geniş miqyaslı fasilələrdən sağ çıxmasını təmin etməlidir. Konteynerlərin xəta domenləri arasında paylanması kimi ənənəvi üsullar vətəndaşlığı olmayan xidmətlər üçün yaxşı uyğun olsa da, dövlət xidmətlərinin əlavə dəstəyə ehtiyacı var.
Məsələn, server nasazlığı bir verilənlər bazası replikasının əlçatmaz olmasına səbəb olarsa, 50 hovuzdakı 10 serverdəki nüvələri yeniləmək üçün avtomatik texniki xidmət aktivləşdirilməlidirmi? Vəziyyətdən asılıdır. Əgər həmin 50 serverdən birində eyni verilənlər bazasının başqa nüsxəsi varsa, ən yaxşısı gözləmək və eyni anda 2 replikanı itirməməkdir. Sistemin saxlanması və sağlamlığı ilə bağlı dinamik qərarlar qəbul etmək üçün sizə daxili məlumatların təkrarlanması və hər bir dövlət xidmətinin yerləşdirilməsi məntiqi haqqında məlumat lazımdır.
TaskControl interfeysi statuslu xidmətlərə məlumatların mövcudluğuna təsir edən qərarlara təsir etməyə imkan verir. Bu interfeysdən istifadə edərək, planlaşdırıcı konteyner əməliyyatları (yenidən başladın, təkmilləşdirmə, köçürmə, texniki xidmət) haqqında xarici proqramları xəbərdar edir. Vəziyyəti bildirən xidmət Tupperware-ə hər bir əməliyyatı yerinə yetirməyin təhlükəsiz olduğunu bildirən nəzarətçi həyata keçirir və bu əməliyyatlar dəyişdirilə və ya müvəqqəti olaraq təxirə salına bilər. Yuxarıdakı misalda verilənlər bazası nəzarətçisi Tupperware-ə 49 serverdən 50-nu təkmilləşdirməyi söyləyə bilər, lakin hələ konkret serverə (X) toxunmaya bilər. Nəticə olaraq, nüvənin yenilənməsi müddəti keçərsə və verilənlər bazası hələ də problemli replikanı bərpa edə bilmirsə, Tupperware hər halda X serverini təkmilləşdirəcək.
Tupperware-dəki bir çox dövlət xidmətləri birbaşa TaskControl-dan deyil, Facebook-da statuslu xidmətlərin yaradılması üçün ümumi platforma olan ShardManager vasitəsilə istifadə edir. Tupperware ilə tərtibatçılar konteynerlərin məlumat mərkəzləri arasında tam olaraq necə paylanacağı ilə bağlı niyyətlərini müəyyən edə bilərlər. ShardManager ilə tərtibatçılar məlumat parçalarının konteynerlər arasında necə paylanmasına dair niyyətlərini müəyyənləşdirirlər. ShardManager məlumatların yerləşdirilməsi və tətbiqlərinin təkrarlanmasından xəbərdardır və proqramların birbaşa iştirakı olmadan konteyner əməliyyatlarını planlaşdırmaq üçün TaskControl interfeysi vasitəsilə Tupperware ilə qarşılıqlı əlaqə qurur. Bu inteqrasiya dövlət xidmətlərinin idarə edilməsini xeyli asanlaşdırır, lakin TaskControl daha çox şeyə qadirdir. Məsələn, zəngin veb səviyyəmiz vətəndaşsızdır və konteynerlərə yeniləmələrin sürətini dinamik şəkildə tənzimləmək üçün TaskControl istifadə edir. Nəhayət əlçatanlığı pozmadan gündə.
Məlumat mərkəzlərində serverin idarə edilməsi
Tupperware ilk dəfə 2011-ci ildə ortaya çıxanda hər bir server klasteri ayrıca planlaşdırıcı tərəfindən idarə olunurdu. Sonra Facebook klasteri bir şəbəkə keçidinə qoşulmuş bir qrup server rafları idi və məlumat mərkəzində bir neçə klaster var idi. Planlayıcı yalnız bir klasterdə serverləri idarə edə bilər, yəni bir iş birdən çox klaster arasında yayıla bilməz. İnfrastrukturumuz böyüdü, biz klasterləri getdikcə sıradan çıxardıq. Tupperware işi ləğv edilmiş klasterdən başqa klasterlərə dəyişiklik etmədən köçürə bilmədiyi üçün proqram tərtibatçıları və məlumat mərkəzi operatorları arasında çoxlu səy və diqqətli koordinasiya tələb olunurdu. Bu proses resurs itkisi ilə nəticələndi, serverlər istismardan çıxarılma prosesi səbəbindən aylarla işləmirdi.
Biz klasterlərin istismardan çıxarılması problemini həll etmək və digər növ texniki xidmət tapşırıqlarını əlaqələndirmək üçün resurs brokeri yaratdıq. Resurs brokeri serverlə əlaqəli bütün fiziki məlumatları izləyir və hər bir serveri hansı planlaşdırıcının idarə etdiyinə dinamik olaraq qərar verir. Serverlərin planlaşdırıcılara dinamik şəkildə bağlanması planlaşdırıcıya müxtəlif məlumat mərkəzlərindəki serverləri idarə etməyə imkan verir. Tupperware işi artıq tək klasterlə məhdudlaşmadığından, Tupperware istifadəçiləri konteynerlərin nasaz domenlər arasında necə paylanacağını təyin edə bilərlər. Məsələn, bir tərtibatçı xüsusi əlçatanlıq zonalarını göstərmədən öz niyyətini bəyan edə bilər (məsələn, "PRN bölgəsindəki 2 səhv domenində işimi idarə et"). Tupperware bu niyyəti həyata keçirmək üçün düzgün serverləri tapacaq, hətta klaster istismardan çıxarılsa və ya xidmət göstərilsə belə.
Bütün qlobal sistemi dəstəkləmək üçün miqyaslayın
Tarixən infrastrukturumuz fərdi komandalar üçün yüzlərlə xüsusi server hovuzlarına bölünüb. Parçalanma və standartların olmaması səbəbindən yüksək əməliyyat xərclərimiz var idi və boş serverlərdən təkrar istifadə etmək daha çətin idi. Keçən ilki konfransda təqdim etdik , bu bizim infrastrukturumuzu böyük vahid serverlər parkında birləşdirməlidir. Ancaq tək bir server donanmasının öz çətinlikləri var. O, müəyyən tələblərə cavab verməlidir:
- Ölçeklenebilirlik. Hər bir bölgəyə məlumat mərkəzləri əlavə etdikcə infrastrukturumuz böyüdü. Serverlər daha kiçik və enerjiyə qənaət edən hala gəldi, buna görə də hər bölgədə daha çox var. Nəticə etibarı ilə, hər bir bölgə üçün bir planlaşdırıcı hər bölgədə yüz minlərlə serverdə işlədilə bilən konteynerlərin sayına çata bilmir.
- Etibarlılıq. Planlayıcı bu qədər genişləndirilə bilsə belə, planlaşdırıcının geniş əhatə dairəsi səhv riskini artıracaq və bütün konteyner bölgəsi idarəolunmaz hala gələ bilər.
- Səhv tolerantlığı. Böyük infrastruktur nasazlığı halında (məsələn, şəbəkənin kəsilməsi və ya elektrik enerjisinin kəsilməsi səbəbindən planlayıcı ilə işləyən serverlər sıradan çıxacaq) mənfi nəticələr regionun serverlərinin yalnız bir hissəsinə təsir etməlidir.
- Istifadə rahatlığı. Görünə bilər ki, hər bölgə üçün bir neçə müstəqil planlaşdırıcı işlətməlisiniz. Lakin rahatlıq nöqteyi-nəzərindən, region üzrə ortaq hovuza vahid giriş nöqtəsinə malik olmaq potensialı və işin idarə edilməsini asanlaşdırır.
Böyük paylaşılan hovuzun saxlanması ilə bağlı problemləri həll etmək üçün planlaşdırıcını parçalara ayırdıq. Hər bir planlaşdırıcı parçası regionda öz iş dəstini idarə edir və bu, planlaşdırıcı ilə bağlı riski azaldır. Ümumi hovuz böyüdükcə, biz daha çox planlaşdırıcı parça əlavə edə bilərik. Tupperware istifadəçiləri üçün qırıqlar və planlaşdırıcı proksilər bir idarəetmə paneli kimi görünür. Tapşırıqları yerinə yetirən bir dəstə parça ilə işləmək məcburiyyətində deyillər. Planlaşdırıcı parçaları şəbəkə topologiyası ilə ümumi server hovuzunu statik olaraq ayırmadan idarəetmə panelini bölməkdən əvvəl istifadə etdiyimiz klaster planlaşdırıcılarından əsaslı şəkildə fərqlənir.
Elastik Hesablama ilə İstifadə Effektivliyinin Təkmilləşdirilməsi
İnfrastrukturumuz nə qədər böyükdürsə, infrastruktur xərclərini optimallaşdırmaq və yükü azaltmaq üçün serverlərimizdən səmərəli istifadə etmək bir o qədər vacibdir. Serverdən istifadənin səmərəliliyini artırmağın iki yolu var:
- Elastik Hesablama - Məşğul saatlarda onlayn xidmətlərin ölçüsünü azaldın və maşın öyrənməsi və MapReduce işləri kimi oflayn iş yükləri üçün pulsuz serverlərdən istifadə edin.
- Həddindən artıq yükləmə - Onlayn xidmətləri və toplu iş yüklərini eyni serverlərdə yerləşdirin ki, toplu yüklər aşağı prioritetlə işləsin.
Məlumat mərkəzlərimizdəki darboğaz budur . Buna görə də biz birlikdə daha çox emal gücü təmin edən kiçik, enerjiyə qənaət edən serverlərə üstünlük veririk. Təəssüf ki, CPU və yaddaşı az olan kiçik serverlərdə həddindən artıq yükləmə daha az təsirli olur. Əlbəttə ki, bir kiçik enerjiyə qənaət edən serverdə az CPU və yaddaş istehlak edən bir neçə kiçik xidmət konteynerini yerləşdirə bilərik, lakin bu vəziyyətdə böyük xidmətlərin performansı zəif olacaq. Buna görə də, biz böyük xidmətlərimizin tərtibatçılarına bütün serverlərdən istifadə etmələri üçün onları optimallaşdırmağı məsləhət görürük.
Əsasən, biz elastik hesablama ilə istifadə səmərəliliyini artırırıq. Xəbər lentləri, mesajlaşma funksionallığı və ön veb səviyyəsi kimi bir çox əsas xidmətlərimizdən istifadə intensivliyi günün vaxtından asılıdır. Biz sakit saatlarda onlayn xidmətləri bilərəkdən kiçildirik və maşın öyrənməsi və MapReduce işləri kimi oflayn iş yükləri üçün pulsuz serverlərdən istifadə edirik.
Təcrübəmizdən bilirik ki, bütün serverləri elastik tutum vahidləri kimi təqdim etmək ən yaxşısıdır, çünki böyük xidmətlər həm əsas töhfə verənlər, həm də elastik tutumun əsas istehlakçılarıdır və onlar bütün serverlərdən istifadə üçün optimallaşdırılıb. Sakit saatlarda server onlayn xidmətdən azad edildikdə, resurs brokeri serverə oflayn yükləri idarə etmək üçün planlaşdırıcıya borc verir. Onlayn xidmət pik yüklə qarşılaşarsa, resurs brokeri tez bir zamanda borc götürülmüş serveri geri çağırır və planlaşdırıcı ilə birlikdə onu onlayn xidmətə qaytarır.
Öyrənilən dərslər və gələcək üçün planlar
Son 8 ildə biz Facebook-un sürətli inkişafı ilə ayaqlaşmaq üçün Tupperware-i təkmilləşdirdik. Öyrəndiklərimizi bölüşürük və ümid edirik ki, bu, başqalarına sürətlə böyüyən infrastrukturları idarə etməyə kömək edəcək:
- İdarəetmə paneli ilə onun idarə etdiyi serverlər arasında çevik əlaqə qurun. Bu çeviklik idarəetmə panelinə verilənlər mərkəzləri arasında serverləri idarə etməyə imkan verir, klasterin istismardan çıxarılmasını və texniki xidmətini avtomatlaşdırmağa kömək edir və elastik hesablama vasitəsilə dinamik tutum bölgüsünə imkan verir.
- Bölgədə vahid idarəetmə paneli ilə tapşırıqlarla işləmək daha rahat olur və geniş ümumi server parkını idarə etmək daha asan olur. Nəzərə alın ki, idarəetmə paneli daxili strukturu miqyaslı və ya nasazlığa dözümlülük səbəbindən bölünsə belə, vahid giriş nöqtəsini saxlayır.
- Plugin modelindən istifadə edərək, idarəetmə paneli qarşıdan gələn konteyner əməliyyatları haqqında xarici tətbiqləri xəbərdar edə bilər. Üstəlik, dövlət xidmətləri konteyner idarəçiliyini fərdiləşdirmək üçün plagin interfeysindən istifadə edə bilər. Bu plagin modeli ilə tablosuna bir çox müxtəlif dövlət xidmətlərini səmərəli şəkildə təqdim edərkən sadəlik təmin edilir.
- İnanırıq ki, toplu işlər, maşın öyrənməsi və digər təcili olmayan xidmətlər üçün donor xidmətlərindən bütün serverləri götürdüyümüz elastik hesablama kiçik və enerjiyə qənaət edən serverlərdən istifadənin səmərəliliyini artırmaq üçün ən yaxşı yoldur.
Biz yenicə başlayırıq . Hazırda serverlərimizin təxminən 20%-i paylaşılan hovuzdadır. 100%-ə nail olmaq üçün ortaq saxlama hovuzunun dəstəyi, texniki xidmətin avtomatlaşdırılması, çoxlu icarəçi tələbinin idarə edilməsi, təkmilləşdirilmiş server istifadəsi və maşın öyrənmə iş yükləri üçün təkmilləşdirilmiş dəstək daxil olmaqla bir çox məsələlərin həlli tələb olunur. Biz bu çətinliklərin öhdəsindən gəlmək və uğurlarımızı bölüşmək üçün səbirsizlənirik.
Mənbə: www.habr.com