Müasir interneti media məzmunu olmadan demək olar ki, təsəvvür etmək mümkün deyil: demək olar ki, hər bir nənənin smartfonu var, hamı sosial şəbəkələrdədir və xidmətin dayandırılması şirkətlər üçün baha başa gəlir. Diqqətiniz üçün şirkətin hekayəsinin stenoqramı hardware həllindən istifadə edərək fotoşəkillərin çatdırılmasını necə təşkil etdiyi, prosesdə hansı performans problemləri ilə qarşılaşdığı, onlara nə səbəb olduğu və bu problemlərin Nginx-ə əsaslanan proqram həlli ilə necə həll edildiyi, eyni zamanda bütün səviyyələrdə nasazlığa dözümlülük təmin edildiyi (). Hekayənin müəlliflərinə Oleq təşəkkür edirik Konfransda öz təcrübələrini bölüşən Efimova və Alexandra Dymova .
Fotoşəkilləri necə saxladığımız və keşlədiyimiz haqqında kiçik bir girişlə başlayaq. Onları saxladığımız bir təbəqə və fotoşəkilləri önbelleğe aldığımız bir təbəqə var. Eyni zamanda, böyük bir hiylə əldə etmək və yaddaşa yükü azaltmaq istəyiriksə, fərdi istifadəçinin hər bir fotoşəkilinin bir keş serverində olması bizim üçün vacibdir. Əks təqdirdə, daha çox serverimiz olduğu kimi, dəfələrlə çox disk quraşdırmalı olardıq. Hit nisbətimiz 99% civarındadır, yəni anbarımızdakı yükü 100 dəfə azaldırıq və bunu etmək üçün 10 il əvvəl, bütün bunlar qurularkən 50 serverimiz var idi. Müvafiq olaraq, bu fotoşəkilləri vermək üçün bizə, əslində, bu serverlərin xidmət etdiyi 50 xarici domen lazım idi.
Təbii ki, dərhal sual yarandı: serverlərimizdən biri sıradan çıxarsa və əlçatmaz olarsa, trafikin hansı hissəsini itiririk? Bazarda olanlara baxdıq və bir dəmir parçası almağa qərar verdik ki, bütün problemlərimizi həll etsin. Seçim F5-şəbəkə şirkətinin (yeri gəlmişkən, NGINX, Inc-i çoxdan satın alan) həllinə düşdü: BIG-IP Local Traffic Manager.
Bu dəmir parçası (LTM) nə edir: bu, xarici portlarının dəmir ehtiyatını təmin edən və şəbəkə topologiyası, bəzi parametrlər əsasında trafiki yönləndirməyə imkan verən və sağlamlıq yoxlamaları aparan dəmir marşrutlaşdırıcıdır. Bu dəmir parçasının proqramlaşdırıla bilməsi bizim üçün vacib idi. Müvafiq olaraq, müəyyən bir istifadəçinin fotoşəkillərinin müəyyən bir keşdən necə qaytarılmasının məntiqini təsvir edə bilərik. Nə kimi görünür? Bir domen, bir ip üçün İnternetə baxan, ssl yüklənməsini həyata keçirən, http sorğularını təhlil edən, IRule-dən keş nömrəsini, hara getmək lazım olduğunu seçən və trafikin oraya getməsinə imkan verən bir cihaz var. Eyni zamanda, o, sağlamlıq yoxlanışı edir və bir maşın olmadıqda, biz bunu elə etdik ki, trafik həmin vaxt bir ehtiyat serverə getsin. Konfiqurasiya nöqteyi-nəzərindən, əlbəttə ki, bəzi nüanslar var, amma ümumiyyətlə hər şey olduqca sadədir: bir xəritə təyin edirik, müəyyən bir nömrə şəbəkədəki IP-mizə uyğun gəlir, 80 portlarını dinləyəcəyimizi söyləyirik. və 443, biz deyirik ki, əgər server mövcud deyilsə, trafikin ehtiyat nüsxəyə, bu halda 35-ə getməsinə icazə verməlisiniz və bu arxitekturanın necə sökülməsi lazım olduğunu bir sıra məntiqi təsvir edirik. Yeganə problem dəmir parçasının proqramlaşdırıldığı dilin Tcl dili olması idi. Əgər kimsə bunu ümumiyyətlə xatırlayırsa ... bu dil proqramlaşdırma üçün əlverişli dildən daha çox yalnız yazı üçün istifadə olunur:
Nə əldə etdik? İnfrastrukturumuzun yüksək əlçatanlığını təmin edən, bütün trafikimizi istiqamətləndirən, sağlamlıq yoxlamalarını təmin edən və sadəcə işləyən bir avadanlıq parçası əldə etdik. Üstəlik, kifayət qədər uzun müddətdir işləyir: son 10 il ərzində bununla bağlı heç bir şikayət olmayıb. 2018-ci ilin əvvəlində biz artıq saniyədə 80 min fotoşəkil göstərirdik. Bu, hər iki məlumat mərkəzimizdən təxminən 80 gigabit trafikdir.
Lakin…
2018-ci ilin əvvəlində biz qrafiklərdə çirkin bir şəkil gördük: fotoşəkilləri geri qaytarma vaxtı açıq şəkildə artdı. Və bu, bizə yaraşmağı dayandırdı. Problem ondadır ki, bu davranış yalnız trafikin ən zirvəsində göründü - şirkətimiz üçün bu, bazar günündən bazar ertəsinə keçən gecədir. Amma qalan vaxtlarda sistem hər zamanki kimi davrandı, heç bir qırılma əlaməti yox idi.
Bununla belə, problem həll edilməli idi. Mümkün darboğazları müəyyənləşdirdik və onları aradan qaldırmağa başladıq. İlk növbədə, əlbəttə ki, biz xarici yuxarı bağlantıları genişləndirdik, daxili yuxarı bağlantılara tam yenidən baxdıq və bütün mümkün maneələri tapdıq. Amma bütün bunlar aşkar nəticə vermədi, problem aradan qalxmadı.
Başqa bir mümkün darboğaz, fotoşəkil önbelleğinin performansı idi. Və qərara gəldik ki, bəlkə də problem onların üzərindədir. Yaxşı, biz performansı genişləndirdik - əsasən, foto önbelleklərindəki şəbəkə portları. Ancaq yenə də heç bir aydın yaxşılaşma müşahidə edilmədi. Sonda biz LTM-nin özünün işinə çox diqqət yetirdik və burada qrafiklərdə kədərli bir mənzərə gördük: bütün CPU-ların yüklənməsi rəvan getməyə başlayır, lakin sonra kəskin şəkildə rəfdə dayanır. Eyni zamanda, LTM sağlamlıq yoxlamalarına və yuxarı bağlantılara adekvat cavab verməyi dayandırır və onları təsadüfi şəkildə söndürməyə başlayır ki, bu da performansın ciddi şəkildə pisləşməsinə səbəb olur.
Yəni problemin mənbəyini müəyyən etdik, darboğazı müəyyən etdik. Nə edəcəyimizə qərar vermək qalır.
Edə biləcəyimiz ilk açıq şey LTM-nin özünü bir növ modernləşdirməkdir. Ancaq burada bəzi nüanslar var, çünki bu dəmir olduqca unikaldır, ən yaxın supermarketə gedib onu almayacaqsınız. Bu, ayrıca müqavilədir, ayrıca lisenziya müqaviləsidir və bu, çox vaxt aparacaq. İkinci seçim, özünüz üçün düşünməyə başlamaq, öz komponentlərinizlə bağlı öz həllinizi tapmaqdır, tercihen açıq mənbə proqramından istifadə etməklə. Bunun üçün dəqiq nəyi seçəcəyimizə və bu problemin həllinə nə qədər vaxt sərf edəcəyimizə qərar vermək qalır, çünki istifadəçilər fotoşəkilləri almadılar. Buna görə də, bütün bunları çox, çox tez etmək lazımdır, deyə bilərsiniz - dünən.
Tapşırıq "mümkün qədər tez bir şey etmək və əlimizdə olan avadanlıqdan istifadə etmək" kimi səsləndiyi üçün düşündüyümüz ilk şey, ən güclü olmayan bəzi maşınları öndən çıxarmaq, Nginx-i oraya qoymaq idi. işləmək və dəmir parçasının əvvəllər etdiyi eyni məntiqi həyata keçirməyə çalışmaq. Yəni, əslində biz aparat parçamızı tərk etdik, konfiqurasiya etməli olduğumuz daha 4 server quraşdırdıq, 10 il əvvəlki vəziyyətə bənzətməklə onlar üçün xarici domenlər yaratdıq... Bu maşınlar yıxıldıqda əlçatanlığı bir az itirdik. , lakin buna baxmayaraq, yerli olaraq istifadəçilərimizin problemini həll etdi.
Müvafiq olaraq, məntiq eyni qalır: biz Nginx quraşdırırıq, o, SSL-boşaltma edə bilir, biz birtəhər marşrutlaşdırma məntiqini proqramlaşdıra bilərik, konfiqurasiyalarda sağlamlıq yoxlanışı apara bilərik və sadəcə olaraq əvvəlki məntiqi təkrarlaya bilərik.
Konfiqurasiyaları yazmaq üçün otururuq. Əvvəlcə hər şeyin çox sadə olduğu görünürdü, lakin təəssüf ki, hər bir tapşırıq üçün təlimat tapmaq çox çətindir. Buna görə də, sadəcə olaraq "şəkillər üçün Nginx-i necə konfiqurasiya etmək olar" google-a müraciət etməyi məsləhət görmürük: hansı parametrlərə toxunulacağını göstərən rəsmi sənədlərə müraciət etmək daha yaxşıdır. Ancaq müəyyən bir parametri özünüz seçmək daha yaxşıdır. Yaxşı, onda hər şey sadədir: bizdə olan serverləri təsvir edirik, sertifikatları təsvir edirik ... Amma ən maraqlısı, əslində, marşrutlaşdırma məntiqinin özüdür.
Əvvəlcə bizə elə gəldi ki, biz sadəcə yerimizi təsvir edirik, içindəki foto keş nömrəsini uyğunlaşdırırıq, əllərimizlə və ya generatorla bizə nə qədər yuxarı axın lazım olduğunu təsvir edirik, hər bir yuxarı axında trafikin getməli olduğu serveri göstəririk və ehtiyat server - əsas server mövcud olmadıqda:
Amma yəqin ki, hər şey bu qədər sadə olsaydı, evə gedib heç nə deməzdik. Təəssüf ki, Nginx-in defolt parametrləri ilə, ümumiyyətlə, uzun illər ərzində hazırlanmış və bu vəziyyət üçün deyil ... konfiqurasiya belə görünür: bəzi yuxarı axın serverində sorğu xətası və ya vaxt aşımı olarsa, Nginx həmişə trafiki növbəti birinə çevirir. Eyni zamanda, ilk uğursuzluqdan sonra server həm səhvən, həm də fasilə ilə 10 saniyə ərzində söndürüləcək - bu, hətta heç bir şəkildə konfiqurasiya edilə bilməz. Yəni, yuxarı axın direktivində vaxt aşımı seçimini silsək və ya sıfırlasaq, o zaman Nginx bu sorğunu emal etməyəcək və o qədər də yaxşı olmayan xəta ilə cavab versə də, server sönəcək.
Bunun qarşısını almaq üçün iki şeyi etdik:
a) onlar Nginx-ə bunu əl ilə etməyi qadağan etdilər - və təəssüf ki, bunun yeganə yolu sadəcə olaraq maksimum uğursuzluq parametrlərini təyin etməkdir.
b) xatırladıq ki, digər layihələrdə sizə arxa planda sağlamlıq yoxlaması etməyə imkan verən moduldan istifadə edirik - müvafiq olaraq, qəza zamanı minimum dayanma vaxtımız olması üçün kifayət qədər tez-tez sağlamlıq yoxlamaları etdik.
Təəssüf ki, bu da hamısı deyil, çünki sözün həqiqi mənasında bu sxemin işləməsinin ilk iki həftəsi göstərdi ki, TCP sağlamlıq yoxlaması da etibarsız bir şeydir: Nginx deyil, ya da D vəziyyətindəki Nginx yuxarı serverdə işə salına bilər və bu halda kernel əlaqəni qəbul edəcək, sağlamlıq yoxlanışı keçəcək, lakin işləməyəcək. Buna görə də, biz dərhal onu http-nin sağlamlıq yoxlaması ilə əvəz etdik, xüsusi bir düzəltdik, əgər o, artıq 200 verirsə, hər şey bu skriptdə işləyir. Əlavə məntiq edə bilərsiniz - məsələn, serverləri keşləmə vəziyyətində, fayl sisteminin düzgün quraşdırıldığını yoxlayın:
Və bu, bizə uyğun olardı, ancaq hal-hazırda dövrə dəmir parçasının etdiklərini tamamilə təkrarlayırdı. Amma biz daha yaxşısını etmək istəyirdik. Əvvəllər bir ehtiyat serverimiz var idi və bu, yəqin ki, o qədər də yaxşı deyil, çünki yüz serveriniz varsa, birdən bir neçəsi düşəndə bir ehtiyat server çətin ki, yükün öhdəsindən gələ bilsin. Buna görə də, rezervasiyanı bütün serverlər arasında bölüşdürmək qərarına gəldik: biz sadəcə başqa bir ayrıca yuxarı axın etdik, oradakı bütün serverləri hansı yükə xidmət edə biləcəklərinə uyğun olaraq müəyyən parametrlərlə qeyd etdik, əvvəllər etdiyimiz sağlamlıq yoxlamalarını əlavə etdik:
Bir yuxarı axının içərisində başqa bir yuxarı axına gedə bilməyəcəyiniz üçün əmin olmaq lazım idi ki, əgər sadəcə düzgün, lazımi foto keşini yazdığımız əsas yuxarı axın mövcud deyilsə, biz sadəcə olaraq error_page vasitəsilə ehtiyata keçdik. biz ehtiyat nüsxəyə yuxarıya getdik:
Və sözün həqiqi mənasında dörd server əlavə edərək, biz bunu əldə etdik: biz yükün bir hissəsini əvəz etdik - LTM-dən bu serverlərə çıxarıldıq, standart aparat və proqram təminatından istifadə edərək orada eyni məntiqi həyata keçirdik, dərhal bu serverlərin miqyaslana biləcəyi üçün bonus aldıq, çünki onlar ola bilər. sadəcə ehtiyacınız olan qədər qoyun. Yeganə mənfi cəhət odur ki, biz xarici istifadəçilər üçün yüksək əlçatanlığı itirmişik. Amma o zaman bunu qurban verməli oldum, çünki problemi dərhal həll etmək lazım idi. Beləliklə, yükün bir hissəsini çıxardıq, o vaxt təxminən 40% idi, LTM yaxşılaşdı və problem başlayandan iki həftə sonra saniyədə 45k yox, 55k sorğu verməyə başladıq. Əslində, biz 20% böyüdük - bu, istifadəçiyə vermədiyimiz trafikdir. Və bundan sonra, qalan problemi necə həll etmək barədə düşünməyə başladılar - yüksək xarici mövcudluğu təmin etmək.
Bunun üçün hansı həll yolu istifadə edəcəyimizi müzakirə etdiyimiz bir müddət fasilə verdik. Bəzi öz-özünə yazılmış skriptlərin, dinamik marşrutlaşdırma protokollarının köməyi ilə DNS-dən istifadə edərək etibarlılığı təmin etmək üçün təkliflər var idi ... bir çox variant var idi, lakin artıq aydın oldu ki, fotoşəkillərin həqiqətən etibarlı şəkildə qaytarılması üçün başqa bir təbəqə tətbiq etməlisiniz. buna nəzarət edəcək. Biz bu maşınları fotorejissor adlandırdıq. Etibar etdiyimiz proqram Keepalived idi:
Başlamaq üçün, Keepalived nədən ibarətdir. Birincisi, şəbəkə istifadəçilərinə geniş şəkildə məlum olan, müştərilərin qoşulduğu xarici IP ünvanı üçün nasazlığa dözümlülük təmin edən şəbəkə avadanlıqlarında yerləşən VRRP protokoludur. İkinci hissə, foto yönləndiricilər arasında tarazlıq yaratmaq və bu səviyyədə nasazlığa dözümlülüyü təmin etmək üçün IPVS, IP virtual serverdir. Üçüncüsü isə sağlamlıq yoxlamalarıdır.
Birinci hissədən başlayaq: VRRP - bu nə kimi görünür? Müştərilərin qoşulduğu dns badoocdn.com-da girişi olan müəyyən bir virtual IP var. Nə vaxtsa bir serverdə bir IP ünvanımız var. Saxlanılan paketlər VRRP protokolundan istifadə edərək serverlər arasında işləyir və əgər master radardan itərsə - server yenidən işə salınıb və ya başqa bir şeydirsə, ehtiyat server avtomatik olaraq bu IP ünvanını qaldırır - heç bir əl hərəkətinə ehtiyac yoxdur. Əsas və ehtiyat nüsxə fərqlənir, əsasən prioritetdir: nə qədər yüksəkdirsə, maşının master olmaq ehtimalı bir o qədər yüksəkdir. Çox böyük bir üstünlük ondan ibarətdir ki, serverin özündə IP ünvanlarını konfiqurasiya etməyə ehtiyac yoxdur, onları konfiqurasiyada təsvir etmək kifayətdir və IP ünvanlarına bəzi xüsusi marşrutlaşdırma qaydaları lazımdırsa, bu birbaşa konfiqurasiyada təsvir edilmişdir. VRRP paketində təsvir edilən eyni sintaksis. Heç bir tanımadığı şeylərlə qarşılaşmayacaqsınız.
Praktikada nə kimi görünür? Serverlərdən biri sıradan çıxsa nə olar? Usta yoxa çıxan kimi ehtiyat nüsxəmiz promosyonlar almağı dayandırır və avtomatik olaraq master olur. Bir müddət sonra biz masterı təmir etdik, yenidən başladıq, Keepalived-i qaldırdıq - ehtiyat nüsxədən daha yüksək prioritetli reklamlar gəlir və ehtiyat nüsxə avtomatik olaraq geri qayıdır, IP ünvanlarını özündən çıxarır, heç bir əl hərəkətinə ehtiyac yoxdur.
Beləliklə, biz xarici IP ünvanının nasazlığa dözümlülüyünü təmin etdik. Növbəti hissə, xarici IP ünvanından artıq onu dayandıran fotoşəkil marşrutlaşdırıcılarına trafiki bir şəkildə balanslaşdırmaqdır. Balanslaşdırma protokolları ilə hər şey kifayət qədər aydındır. Bu ya sadə round-robin, ya da bir az daha mürəkkəb şeylər, wrr, siyahı bağlantısı və s. Bu, əsasən sənədlərdə təsvir edilmişdir, bu barədə xüsusi bir şey yoxdur. Ancaq çatdırılma üsulu ... Burada daha ətraflı dayanacağıq - niyə onlardan birini seçdik. Bunlar NAT, Direct Routing və TUN-dur. Fakt budur ki, saytlardan 100 gigabit trafikin qaytarılmasını dərhal qoyduq. Bunu başa düşsəniz, sizə 10 gigabit kart lazımdır, elə deyilmi? Bir serverdə 10 gigabit kart - bu, ən azı, "standart avadanlıq" anlayışımızdan artıqdır. Və sonra xatırladıq ki, biz sadəcə bir az trafik vermirik, fotoşəkillər də veririk.
xüsusiyyət nədir? - Gələn və gedən trafik arasında böyük fərq. Gələn trafik çox azdır, gedən trafik çox böyükdür:
Bu qrafiklərə baxsanız görə bilərsiniz ki, hazırda direktora saniyədə təxminən 200 Mb göndərilir, bu, ən tipik gündür. Biz saniyədə 4,500 MB geri veririk, nisbət təxminən 1/22-dir. Artıq aydındır ki, 22 işləyən serverə gedən trafiki tam təmin etmək üçün bu əlaqəni qəbul edən biri kifayətdir. Burada birbaşa marşrutlaşdırma alqoritmi, marşrutlaşdırma alqoritmi köməyimizə gəlir.
Nə kimi görünür? Fotorejissorumuz öz cədvəlinə uyğun olaraq əlaqələri foto yönləndiricilərə ötürür. Ancaq foto marşrutlaşdırıcılar tərs trafiki birbaşa İnternetə göndərir, müştəriyə göndərir, o, foto rejissordan geri dönmür, beləliklə, minimum sayda maşınla, biz bütün trafikin tam nasazlığa dözümlülüyünü və nasosunu təmin edirik. Konfiqurasiyalarda belə görünür: alqoritmi müəyyənləşdiririk, bizim vəziyyətimizdə bu sadə rr-dir, biz birbaşa marşrutlaşdırma metodunu təqdim edirik və sonra bütün real serverləri siyahıya salmağa başlayırıq, onlardan neçəsi var. Hansı bu trafiki müəyyən edəcək. Bir və ya iki daha, bir neçə serverimiz görünsə, belə bir ehtiyac yaranır - sadəcə olaraq bu bölməni konfiqurasiyaya əlavə edirik və çox narahat olmayın. Həqiqi serverlər tərəfdən, foto-router tərəfdən bu üsul ən minimal konfiqurasiya tələb edir, sənədlərdə mükəmməl təsvir edilmişdir və orada heç bir tələ yoxdur.
Xüsusilə sevindirici hal odur ki, belə bir həll yerli şəbəkənin köklü şəkildə dəyişdirilməsini nəzərdə tutmur, bu, bizim üçün vacib idi, biz bunu minimal xərclə həll etməli idik. Baxsanız sonra bunun necə göründüyünü görəcəyik. Burada müəyyən bir virtual serverimiz var, 443-cü portda, dinləyir, əlaqəni qəbul edir, bütün işləyən serverlər sadalanır və əlaqənin artı və ya mənfi, eyni olduğunu görmək olar. Eyni virtual serverdə statistikaya baxsaq, daxil olan paketlərimiz, daxil olan əlaqələrimiz var, ancaq gedənlər tamamilə yoxdur. Çıxan bağlantılar birbaşa müştəriyə gedir. Yaxşı, balansı poza bildik. İndi, foto marşrutlaşdırıcılarımızdan biri uğursuz olarsa nə olar? Axı dəmir dəmirdir. O, nüvə panikasına düşə bilər, qırıla bilər, enerji təchizatı sönə bilər. Hər şey. Sağlamlıq yoxlamaları bunun üçündür. Onlar portun bizimlə necə açıq olduğunu yoxlamaq qədər sadə və ya daha mürəkkəb, hətta biznes məntiqini yoxlayacaq bəzi öz-özünə yazılmış skriptlərə qədər ola bilər.
Ortada bir yerdə dayandıq: müəyyən bir yer üçün https sorğumuz var, skript 200-cü cavabla cavab verərsə çağırılır, inanırıq ki, bu serverdə hər şey yaxşıdır, canlıdır və olduqca asanlıqla yandırıla bilər. .
Bu, yenidən praktikada necə görünür. Baxım üçün icazə verilən server söndürüldü - məsələn, BIOS-un yanıb-sönməsi. Qeydlərdə dərhal fasiləmiz var, ilk sətri görürük, sonra üç cəhddən sonra "uğursuz" kimi qeyd olunur və sadəcə siyahıdan çıxarılır.
Sadəcə VS sıfıra təyin edildikdə ikinci bir davranış da mümkündür, lakin fotoşəkilin qaytarılması halında bu yaxşı işləmir. Server yüksəlir, Nginx orada işə başlayır, dərhal sağlamlıq yoxlamaları əlaqənin keçdiyini, hər şeyin qaydasında olduğunu başa düşür və server siyahımızda görünür və yük dərhal ona avtomatik olaraq tətbiq olunmağa başlayır. Növbətçi administratordan heç bir əl hərəkəti tələb olunmur. Gecə, server yenidən başladı - monitorinq şöbəsi gecə bu barədə bizə zəng etmir. Nə baş verdiyini sizə xəbər verirlər, hər şey qaydasındadır.
Beləliklə, kifayət qədər sadə bir şəkildə, az sayda serverin köməyi ilə biz xarici nasazlıqlara qarşı dözümlülük problemini həll etdik.
Qaldı ki, bütün bunlara, təbii ki, nəzarət etmək lazımdır. Ayrı-ayrılıqda qeyd etmək lazımdır ki, Keepalivede, çox uzun müddət əvvəl yazılmış bir proqram olaraq, həm DBus, SMTP, SNMP, həm də standart Zabbix vasitəsilə yoxlamalardan istifadə edərək onu izləmək üçün bir çox yollara malikdir. Üstəlik, o, demək olar ki, hər asqırmağa necə məktub yazmağı bilir və düzünü desəm, bir anda onu söndürməyi də düşündük, çünki o, hər hansı bir trafik açarı, daxilolma, hər bir IP-shnik üçün çoxlu məktublar yazır. s. Əlbəttə ki, bir çox server varsa, o zaman özünüzü bu məktublarla doldura bilərsiniz. Standart metodlardan istifadə edərək, biz foto marşrutlaşdırıcılarda nginx-ə nəzarət edirik və aparat monitorinqi getmədi. Əlbəttə ki, biz daha iki şeyi məsləhət görərdik: birincisi, xarici sağlamlıq yoxlamaları və əlçatanlıq, çünki hər şey işləsə də, əslində istifadəçilərin xarici provayderlərlə bağlı problemlər və ya daha mürəkkəb bir şey səbəbindən fotoşəkilləri almaması mümkündür. Həmişə başqa bir şəbəkədə, Amazonda və ya başqa bir yerdə, serverlərinizə kənardan ping ata bilən ayrıca bir maşın saxlamağa dəyər və həm də çətin maşın öyrənməsində yaxşı olanlar üçün anomaliya aşkarlanmasından istifadə etməyə dəyər. monitorinq, heç olmasa sorğuların kəskin şəkildə azaldığını və ya əksinə artdığını izləmək üçün. Həm də faydalıdır.
Xülasə etmək üçün: biz əslində bir anda bizə uyğun gəlməyi dayandıran dəmir həllini hər şeyi eyni edən kifayət qədər sadə bir sistemlə əvəz etdik, yəni HTTPS trafikinin dayandırılmasını və lazımi sağlamlıq ilə daha ağıllı marşrutlaşdırmanı təmin edir -yoxlayır. Biz bu sistemin sabitliyini artırdıq, yəni hər bir təbəqə üçün hələ də yüksək əlçatanlığımız var, üstəlik biz bonus aldıq ki, hər bir təbəqədə hamısını miqyaslaşdırmaq olduqca asandır, çünki bu, standart proqram təminatı ilə standart aparatdır, yəni. , bununla biz mümkün problemlərin diaqnostikasını sadələşdirmişik.
Axırımız nə oldu? 2018-ci ilin yanvar bayramlarında problem yaşadıq. İlk altı ay ərzində bu sxemi istifadəyə verərkən, onu bütün trafikə genişləndirərkən, LTM-dən bütün trafiki çıxarmaq üçün biz yalnız bir məlumat mərkəzində trafiki 40 giqabitdən 60 giqabitə qədər artırdıq və eyni zamanda bütün 2018-ci il üçün vaxt saniyədə demək olar ki, üç dəfə çox fotoşəkil verə bildi.
Mənbə: www.habr.com