Müasir məlumat mərkəzlərində müxtəlif monitorinq növləri ilə əhatə olunmuş yüzlərlə aktiv cihaz quraşdırılmışdır. Ancaq əlində mükəmməl monitorinqi olan ideal mühəndis belə bir neçə dəqiqə ərzində şəbəkənin nasazlığına düzgün cavab verə biləcək. Next Hop 2020 konfransındakı hesabatda mən DC şəbəkəsinin dizayn metodologiyasını təqdim etdim, onun unikal xüsusiyyəti var - məlumat mərkəzi millisaniyələrdə özünü sağaldır. Daha doğrusu, mühəndis problemi sakitcə həll edir, xidmətlər isə sadəcə olaraq bunu hiss etmir.
Bir çox şəbəkə mühəndisləri üçün məlumat mərkəzi şəbəkəsi, əlbəttə ki, ToR ilə, rəfdəki açarla başlayır. ToR adətən iki növ bağlantıya malikdir. Kiçiklər serverlərə gedir, digərləri - onlardan N dəfə çoxdur - birinci səviyyənin onurğalarına, yəni onun yuxarı keçidlərinə doğru gedirlər. Uplinks adətən bərabər hesab olunur və uplinks arasında trafik proto, src_ip, dst_ip, src_port, dst_port daxil olmaqla, 5-tuple hash əsasında balanslaşdırılmışdır. Burada sürpriz yoxdur.
Sonra, plan memarlığı nə kimi görünür? Birinci səviyyəli onurğalar bir-birinə bağlı deyil, superspines vasitəsilə bağlanır. X hərfi superspines üçün cavabdeh olacaq; demək olar ki, çarpaz əlaqə kimidir.
Və aydındır ki, digər tərəfdən, tori birinci səviyyənin bütün onurğalarına bağlıdır. Bu şəkildəki vacib nədir? Əgər rack daxilində qarşılıqlı əlaqəmiz varsa, o zaman qarşılıqlı əlaqə, əlbəttə ki, ToR-dən keçir. Əgər qarşılıqlı əlaqə modulun daxilində baş verirsə, onda qarşılıqlı əlaqə birinci səviyyəli dirəklər vasitəsilə baş verir. Qarşılıqlı əlaqə modullararası olarsa - burada olduğu kimi, ToR 1 və ToR 2 - onda qarşılıqlı əlaqə həm birinci, həm də ikinci səviyyələrin onurğalarından keçəcəkdir.
Teorik olaraq, belə bir arxitektura asanlıqla miqyaslana bilər. Port tutumumuz, məlumat mərkəzində ehtiyat yerimiz və əvvəlcədən çəkilmiş lifimiz varsa, o zaman zolaqların sayı həmişə artırıla bilər və bununla da sistemin ümumi tutumu artır. Bunu kağız üzərində etmək çox asandır. Həyatda belə olardı. Ancaq bugünkü hekayə bununla bağlı deyil.
Mən düzgün nəticənin çıxarılmasını istəyirəm. Məlumat mərkəzinin içərisində çoxlu yollarımız var. Onlar şərti olaraq müstəqildirlər. Məlumat mərkəzi daxilində bir yol yalnız ToR daxilində mümkündür. Modulun içərisində biz zolaqların sayına bərabər yolların sayına sahibik. Modullar arasındakı yolların sayı təyyarələrin sayının və hər bir müstəvidəki superspinlərin sayının hasilinə bərabərdir. Daha aydın olmaq üçün, miqyas hissini əldə etmək üçün Yandex məlumat mərkəzlərindən biri üçün etibarlı olan nömrələri verəcəyəm.
Səkkiz təyyarə var, hər təyyarədə 32 superspin var. Nəticədə məlum olur ki, modulun daxilində səkkiz yol var və modullararası qarşılıqlı əlaqə ilə artıq onlardan 256-sı var.
Yəni biz Cookbook-u inkişaf etdiririksə, özünü sağaldan xətaya dözümlü məlumat mərkəzləri qurmağı öyrənməyə çalışırıqsa, planar arxitektura düzgün seçimdir. Bu, miqyas problemini həll edir və nəzəri cəhətdən asandır. Bir çox müstəqil yollar var. Sual qalır: belə bir memarlıq uğursuzluqlara necə dözür? Müxtəlif uğursuzluqlar var. Və indi bunu müzakirə edəcəyik.
Qoy bizim superspinlərdən biri “xəstələnsin”. Burada iki müstəvili arxitekturaya qayıtdım. Bunlara nümunə olaraq sadiq qalacağıq, çünki daha az hərəkət edən hissə ilə nə baş verdiyini görmək daha asan olacaq. Qoy X11 xəstələnsin. Bu məlumat mərkəzlərində yaşayan xidmətlərə necə təsir edəcək? Çox şey uğursuzluğun əslində necə göründüyündən asılıdır.
Əgər uğursuzluq yaxşıdırsa, eyni BFD-nin avtomatlaşdırma səviyyəsində tutulur, avtomatlaşdırma xoşbəxtliklə problemli birləşmələri qoyur və problemi təcrid edir, onda hər şey yaxşıdır. Çoxlu yollarımız var, nəqliyyat dərhal alternativ marşrutlara yönləndirilir və xidmətlər heç nə görməyəcək. Bu yaxşı skriptdir.
Pis ssenari odur ki, daimi itkilərimiz olur və avtomatlaşdırma problemi görmür. Bunun tətbiqə necə təsir etdiyini başa düşmək üçün TCP-nin necə işlədiyini müzakirə etmək üçün bir az vaxt sərf etməliyik.
Ümid edirəm ki, bu məlumatla heç kəsi şoka salmayacağam: TCP ötürmə təsdiqləmə protokoludur. Yəni, ən sadə halda, göndərən iki paket göndərir və onlar haqqında kumulyativ ak alır: "Mən iki paket aldım."
Bundan sonra o, daha iki paket göndərəcək və vəziyyət təkrarlanacaq. Bəzi sadələşdirmələrə görə əvvəlcədən üzr istəyirəm. Pəncərə (uçuşda olan paketlərin sayı) ikidirsə, bu ssenari düzgündür. Təbii ki, ümumi halda bu, mütləq belə deyil. Lakin pəncərə ölçüsü paket yönləndirmə kontekstinə təsir etmir.
3-cü paketi itirsək nə olar? Bu halda, alıcı 1, 2 və 4-cü paketləri alacaq. O, SACK seçimindən istifadə edərək göndərənə açıq şəkildə deyəcək: “Bilirsiniz, üç nəfər gəldi, amma orta itirildi”. Deyir: “Ack 2, SACK 4”.
Bu anda göndərən heç bir problem olmadan itirilmiş paketi təkrarlayır.
Ancaq pəncərədəki sonuncu paket itirilsə, vəziyyət tamamilə fərqli görünəcək.
Alıcı ilk üç paketi alır və ilk növbədə gözləməyə başlayır. Linux nüvəsinin TCP yığınındakı bəzi optimallaşdırmalar sayəsində, bayraqlar onun sonuncu paket və ya buna bənzər bir şey olduğunu açıq şəkildə göstərməsə, o, qoşalaşmış paketi gözləyəcək. O, Gecikmiş ACK vaxt aşımı bitənə qədər gözləyəcək və sonra ilk üç paket üçün təsdiq göndərəcək. Amma indi göndərən gözləyəcək. Dördüncü bağlamanın itdiyini və ya gəlmək üzrə olduğunu bilmir. Şəbəkəni həddən artıq yükləməmək üçün o, paketin itirildiyini və ya RTO müddətinin bitməsini açıq şəkildə gözləməyə çalışacaq.
RTO vaxt aşımı nədir? Bu, TCP yığını və bəzi sabitlər tərəfindən hesablanmış RTT-nin maksimumudur. Bu nə cür sabitdir, indi müzakirə edəcəyik.
Amma vacib olan odur ki, əgər yenə bəxtimiz gətirməsə və dördüncü paket yenidən itirilsə, RTO ikiqat artır. Yəni, hər bir uğursuz cəhd vaxt aşımını ikiqat artırmaq deməkdir.
İndi görək bu baza nəyə bərabərdir. Varsayılan olaraq, minimum RTO 200 ms-dir. Bu, məlumat paketləri üçün minimum RTO-dur. SYN paketləri üçün fərqlidir, 1 saniyə. Gördüyünüz kimi, paketləri yenidən göndərmək üçün ilk cəhd belə məlumat mərkəzindəki RTT-dən 100 dəfə uzun çəkəcək.
İndi isə ssenarimizə qayıdaq. Xidmətlə nə baş verir? Xidmət paketləri itirməyə başlayır. Xidmət əvvəlcə şərti olaraq şanslı olsun və pəncərənin ortasında bir şey itirsin, sonra SACK alır və itirilmiş paketləri yenidən göndərir.
Ancaq bədbəxtlik təkrarlanırsa, deməli bizim RTO-muz var. Burada vacib olan nədir? Bəli, şəbəkəmizdə çoxlu yollar var. Lakin müəyyən bir TCP bağlantısının TCP trafiki eyni pozulmuş yığından keçməyə davam edəcək. Paket itkiləri, bir şərtlə ki, bu sehrli X11-imiz öz-özünə sönməsin, trafikin problemli olmayan ərazilərə axmasına səbəb olmasın. Biz paketi eyni qırıq yığın vasitəsilə çatdırmağa çalışırıq. Bu, kaskadlı uğursuzluğa gətirib çıxarır: məlumat mərkəzi qarşılıqlı əlaqədə olan proqramlar toplusudur və bütün bu proqramların bəzi TCP əlaqələri pisləşməyə başlayır - çünki superspin data mərkəzinin daxilində mövcud olan bütün proqramlara təsir göstərir. Necə deyərlər: atı çəkmədin, at topaldı; at axsaq getdi - hesabat verilmədi; hesabat verilmədi - biz müharibəni uduzduq. Yalnız burada hesab problemin yarandığı andan xidmətlərin hiss etməyə başladığı deqradasiya mərhələsinə qədər saniyələrdir. Bu o deməkdir ki, istifadəçilər haradasa nəyisə əldən verə bilərlər.
Bir-birini tamamlayan iki klassik həll yolu var. Birincisi, samanları yerləşdirməyə və problemi belə həll etməyə çalışan xidmətlərdir: “Gəlin TCP yığınında nəyisə düzəldək. Gəlin tətbiq səviyyəsində fasilələr və ya daxili sağlamlıq yoxlamaları ilə uzunmüddətli TCP seansları edək." Problem ondadır ki, belə həllər: a) ümumiyyətlə miqyaslı deyil; b) çox zəif yoxlanılır. Yəni, xidmət təsadüfən TCP yığınını onu daha da yaxşılaşdıracaq şəkildə konfiqurasiya etsə də, birincisi, onun bütün proqramlar və bütün məlumat mərkəzləri üçün tətbiq oluna bilməsi ehtimalı azdır, ikincisi, çox güman ki, bunun edildiyini başa düşməyəcək. düzgün və nə yox. Yəni işləyir, amma zəif işləyir və miqyas almır. Və şəbəkə problemi varsa, kim günahkardır? Təbii ki, MOK. NOC nə edir?
Bir çox xidmətlər hesab edir ki, MOK-da belə bir iş baş verir. Amma düzünü desəm, təkcə bu deyil.
Klassik sxemdə MOK bir çox monitorinq sistemlərinin inkişafı ilə məşğul olur. Bunlar həm qara qutu, həm də ağ qutu monitorinqidir. Qara qutu onurğa monitorinqi nümunəsi haqqında Alexander Klimenko son Next Hop-da. Yeri gəlmişkən, bu monitorinq işləyir. Ancaq hətta ideal monitorinqdə də vaxt gecikməsi olacaq. Adətən bu bir neçə dəqiqədir. Sönəndən sonra növbətçi mühəndislərə onun işini iki dəfə yoxlamaq, problemi lokallaşdırmaq və problem sahəsini söndürmək üçün vaxt lazımdır. Yəni, ən yaxşı halda problemin müalicəsi 5 dəqiqə, ən pis halda itkilərin harada baş verdiyi dərhal bəlli deyilsə, 20 dəqiqə çəkir. Aydındır ki, bütün bu müddət ərzində - 5 və ya 20 dəqiqə - xidmətlərimiz əziyyət çəkməyə davam edəcək, bu, yəqin ki, yaxşı deyil.
Həqiqətən nə almaq istərdiniz? Çox yollarımız var. Problemlər məhz ona görə yaranır ki, uğursuz TCP axınları eyni marşrutdan istifadə etməyə davam edir. Bizə bir TCP bağlantısı daxilində birdən çox marşrutdan istifadə etməyə imkan verəcək bir şey lazımdır. Deyəsən, bir həllimiz var. TCP var, çox yollu TCP adlanır, yəni çoxlu yollar üçün TCP. Doğrudur, o, tamamilə fərqli bir vəzifə üçün hazırlanmışdır - bir neçə şəbəkə qurğusu olan smartfonlar üçün. Köçürməni maksimum dərəcədə artırmaq və ya əsas/ehtiyat rejimi etmək üçün proqrama şəffaf şəkildə birdən çox mövzu (sessiya) yaradan və uğursuzluq halında onlar arasında keçid etməyə imkan verən mexanizm hazırlanmışdır. Və ya dediyim kimi, zolağı maksimuma çatdırın.
Ancaq burada bir nüans var. Bunun nə olduğunu başa düşmək üçün iplərin necə qurulduğuna baxmaq lazımdır.
Mövzular ardıcıl olaraq quraşdırılır. İlk ip əvvəlcə quraşdırılır. Sonrakı mövzular daha sonra həmin mövzuda artıq razılaşdırılmış kukidən istifadə etməklə qurulur. Və burada problem var.
Məsələ burasındadır ki, əgər birinci ip özünü qurmasa, ikinci və üçüncü iplər heç vaxt yaranmayacaq. Yəni, çox yollu TCP ilk axında SYN paketinin itkisini həll etmir. SYN itirilərsə, çox yollu TCP adi TCP-yə çevrilir. Bu o deməkdir ki, məlumat mərkəzi mühitində o, fabrikdəki itki problemini həll etməyə və nasazlıq halında bir çox yollardan istifadə etməyi öyrənməyə kömək etməyəcək.
Bizə nə kömək edə bilər? Bəziləriniz artıq başlıqdan təxmin etmisiniz ki, gələcək hekayəmizdə mühüm sahə IPv6 axını etiketinin başlıq sahəsi olacaq. Həqiqətən, bu, v6-da görünən bir sahədir, v4-də deyil, 20 bit tutur və uzun müddətdir ki, istifadəsi ilə bağlı mübahisələr var. Bu çox maraqlıdır - mübahisələr var idi, RFC daxilində bir şey düzəldildi və eyni zamanda Linux nüvəsində heç bir yerdə sənədləşdirilməmiş bir tətbiq meydana çıxdı.
Sizi mənimlə kiçik bir araşdırmaya getməyə dəvət edirəm. Son bir neçə il ərzində Linux nüvəsində baş verənlərə nəzər salaq.
2014-cü il. Böyük və hörmətli bir şirkətdən olan mühəndis Linux nüvəsinin funksionallığına axın etiketinin dəyərinin yuva hashından asılılığını əlavə edir. Burada nəyi düzəltməyə çalışırdılar? Bu, aşağıdakı məsələni müzakirə edən RFC 6438 ilə bağlıdır. Məlumat mərkəzinin içərisində IPv4 tez-tez IPv6 paketlərində əhatə olunur, çünki zavodun özü IPv6-dır, lakin IPv4 birtəhər kənarda verilməlidir. Uzun müddətdir ki, TCP və ya UDP-yə daxil olmaq və orada src_ports, dst_ports tapmaq üçün iki IP başlığının altına baxa bilməyən açarlarla bağlı problemlər var idi. Məlum oldu ki, hash, ilk iki IP başlığına baxsanız, demək olar ki, sabitləşdi. Bunun qarşısını almaq üçün bu kapsullaşdırılmış trafikin balansının düzgün işləməsi üçün axın etiketi sahəsinin dəyərinə 5 dəstli kapsullaşdırılmış paketin hashını əlavə etmək təklif edilmişdir. Təxminən eyni şey digər enkapsulyasiya sxemləri üçün edildi, UDP üçün, GRE üçün, sonuncu GRE Açar sahəsindən istifadə etdi. Bu və ya digər şəkildə burada məqsədlər aydındır. Və ən azı o zamanlar faydalı idilər.
2015-ci ildə eyni hörmətli mühəndisdən yeni yamaq gəlir. O, çox maraqlıdır. Aşağıdakıları deyir - mənfi marşrutlaşdırma hadisəsi halında hashı təsadüfiləşdirəcəyik. Mənfi marşrutlaşdırma hadisəsi nədir? Bu, əvvəllər müzakirə etdiyimiz RTO-dur, yəni pəncərənin quyruğunun itirilməsi həqiqətən mənfi bir hadisədir. Düzdür, bunun belə olduğunu təxmin etmək nisbətən çətindir.
2016, başqa bir nüfuzlu şirkət, həm də böyük. O, son qoltuqağacı sökür və onu elə edir ki, əvvəllər təsadüfi etdiyimiz hash indi hər SYN təkrar ötürülməsi üçün və hər RTO fasiləsindən sonra dəyişir. Və bu məktubda ilk və sonuncu dəfə son məqsəd bəyan edilir - itkilər və ya kanal tıxacları zamanı nəqliyyatın yumşaq şəkildə marşrutunu dəyişmək və çoxlu yollardan istifadə etmək imkanına malik olmasını təmin etmək. Təbii ki, bundan sonra çoxlu nəşrlər oldu, onları asanlıqla tapa bilərsiniz.
Yox olsa da, edə bilməzsiniz, çünki bu mövzuda bir dənə də olsun nəşr olmayıb. Amma biz bilirik!
Nə edildiyini tam başa düşmürsənsə, indi sizə deyəcəyəm.
Nə edildi, Linux nüvəsinə hansı funksionallıq əlavə edildi? txhash hər RTO hadisəsindən sonra təsadüfi dəyərə dəyişir. Bu, marşrutlaşdırmanın çox mənfi nəticəsidir. Haş bu txhash-dan, axın etiketi isə skb hash-dən asılıdır. Burada funksiyalar üzrə bəzi hesablamalar var, bütün detalları bir slaydda yerləşdirmək olmaz. Kimsə maraqlanırsa, nüvə kodundan keçib yoxlaya bilərsiniz.
Burada vacib olan nədir? Axın etiketi sahəsinin dəyəri hər RTO-dan sonra təsadüfi nömrəyə dəyişir. Bu, uğursuz TCP axınımıza necə təsir edir?
SACK baş verərsə, heç nə dəyişmir, çünki biz məlum itirilmiş paketi yenidən göndərməyə çalışırıq. İndiyə qədər yaxşı.
Ancaq RTO vəziyyətində, ToR-də hash funksiyasına axın etiketi əlavə etmək şərti ilə, trafik fərqli bir marşrut tuta bilər. Və nə qədər çox zolaq varsa, onun müəyyən bir cihazda nasazlıqdan təsirlənməyən yolu tapmaq şansı bir o qədər yüksəkdir.
Bir problem qalır - RTO. Təbii ki, başqa marşrut da var, amma buna çox vaxt sərf olunur. 200 ms çox şeydir. Bir saniyə tamamilə vəhşidir. Əvvəllər xidmətlərin konfiqurasiya edildiyi vaxtaşımları haqqında danışdım. Beləliklə, bir saniyə, adətən tətbiq səviyyəsində xidmət tərəfindən konfiqurasiya edilən bir fasilədir və bu vəziyyətdə xidmət hətta nisbətən düzgün olacaqdır. Üstəlik, təkrar edirəm, müasir məlumat mərkəzinin daxilində real RTT təxminən 1 millisaniyədir.
RTO fasilələri ilə nə edə bilərsiniz? Məlumat paketlərinin itirilməsi halında RTO-ya cavabdeh olan zaman aşımı istifadəçi sahəsindən nisbətən asanlıqla konfiqurasiya edilə bilər: bir IP yardım proqramı var və onun parametrlərindən birində eyni rto_min var. Nəzərə alsaq ki, RTO, əlbəttə ki, qlobal səviyyədə deyil, lakin verilmiş prefikslər üçün tənzimlənməlidir, belə bir mexanizm olduqca işlək görünür.
Düzdür, SYN_RTO ilə hər şey bir qədər pisdir. Təbii olaraq dırnaqlanır. Nüvənin 1 saniyə sabit dəyəri var və bu da budur. İstifadəçi məkanından ora çata bilməzsiniz. Yalnız bir yol var.
eBPF köməyə gəlir. Sadə dillə desək, bunlar kiçik C proqramlarıdır.Onlar kernel stekinin və TCP stekinin icrasında müxtəlif yerlərdə qarmaqlara daxil edilə bilər, onların köməyi ilə çox sayda parametrləri dəyişdirmək olar. Ümumiyyətlə, eBPF uzunmüddətli tendensiyadır. Onlarla yeni sysctl parametrlərini kəsmək və IP yardım proqramını genişləndirmək əvəzinə, hərəkət eBPF-ə doğru irəliləyir və funksionallığını genişləndirir. eBPF-dən istifadə edərək siz tıxac nəzarətlərini və müxtəlif digər TCP parametrlərini dinamik şəkildə dəyişə bilərsiniz.
Lakin bizim üçün vacibdir ki, ondan SYN_RTO dəyərlərini dəyişdirmək üçün istifadə edilə bilər. Bundan əlavə, açıq şəkildə dərc edilmiş bir nümunə var: . Burada nə iş görülüb? Nümunə işləyir, amma özlüyündə çox kobuddur. Burada məlumat mərkəzinin daxilində ilk 44 biti müqayisə etdiyimiz güman edilir; əgər onlar uyğun gəlirsə, onda biz məlumat mərkəzinin içindəyik. Və bu halda biz SYN_RTO vaxt aşımı dəyərini 4ms-ə dəyişirik. Eyni vəzifə daha zərif şəkildə edilə bilər. Amma bu sadə misal göstərir ki, bu a) mümkündür; b) nisbətən sadə.
Biz artıq nə bilirik? Təyyarə arxitekturasının miqyasa imkan verməsi faktı, ToR-də axın etiketini aktivləşdirdiyimiz zaman və problemli sahələr ətrafında hərəkət etmək imkanı əldə etdiyimiz zaman bizim üçün son dərəcə faydalı olur. RTO və SYN-RTO dəyərlərini azaltmağın ən yaxşı yolu eBPF proqramlarından istifadə etməkdir. Sual qalır: balanslaşdırma üçün axın etiketindən istifadə etmək təhlükəsizdirmi? Və burada bir nüans var.
Tutaq ki, şəbəkənizdə istənilən yayımda yaşayan bir xidmətiniz var. Təəssüf ki, mənim anycast-ın nə olduğu haqqında təfərrüatlara girməyə vaxtım yoxdur, lakin bu, eyni IP ünvanı vasitəsilə əldə edilə bilən müxtəlif fiziki serverlərə malik paylanmış xidmətdir. Və burada mümkün bir problem var: RTO hadisəsi təkcə trafik parçadan keçəndə baş verə bilməz. Bu, ToR bufer səviyyəsində də baş verə bilər: bir incast hadisə baş verdikdə, hətta host nəyisə tökəndə də baş verə bilər. RTO hadisəsi baş verdikdə və axın etiketini dəyişdirdikdə. Bu halda, trafik başqa istənilən yayım nümunəsinə gedə bilər. Fərz edək ki, bu, statuslu hər hansı bir yayımdır, o, əlaqə vəziyyətini ehtiva edir - bu, L3 Balancer və ya başqa xidmət ola bilər. Sonra problem yaranır, çünki RTO-dan sonra bu TCP bağlantısı haqqında heç nə bilməyən serverə TCP bağlantısı gəlir. İstənilən yayım serverləri arasında dövlət paylaşımımız olmasa, bu cür trafik kəsiləcək və TCP bağlantısı pozulacaq.
Burada nə edə bilərsən? Nəzarət olunan mühitinizdə, axın etiketinin balanslaşdırılmasını aktiv etdiyiniz yerdə, istənilən yayım serverlərinə daxil olarkən axın etiketinin dəyərini qeyd etməlisiniz. Ən asan yol bunu eyni eBPF proqramı vasitəsilə etməkdir. Ancaq burada çox vacib bir məqam var - məlumat mərkəzi şəbəkəsini idarə etmirsinizsə, lakin telekommunikasiya operatorusunuzsa nə etməli? Bu da sizin probleminizdir: Juniper və Arista-nın müəyyən versiyalarından başlayaraq, onlar öz hash funksiyalarına defolt olaraq axın etiketini daxil edirlər - açığını desəm, mənə aydın olmayan səbəbə görə. Bu, şəbəkənizdən keçən istifadəçilərin TCP bağlantılarını kəsməyinizə səbəb ola bilər. Buna görə də burada marşrutlaşdırıcıların parametrlərini yoxlamağı tövsiyə edirəm.
Bu və ya digər şəkildə, mənə elə gəlir ki, biz təcrübələrə keçməyə hazırıq.
ToR-da axın etiketini işə saldıqda, indi hostlarda yaşayan eBPF agentini hazırladıqda, növbəti böyük uğursuzluğu gözləməyə deyil, idarə olunan partlayışlar həyata keçirməyə qərar verdik. Dörd yuxarı keçidi olan ToR-u götürdük və onlardan birinə damcılar quraşdırdıq. Bir qayda çəkdilər və dedilər - indi bütün paketləri itirirsən. Solda gördüyünüz kimi, bizdə paket başına monitorinq var ki, bu da 75%-ə düşüb, yəni paketlərin 25%-i itib. Sağda bu ToR arxasında yaşayan xidmətlərin qrafikləri var. Əsasən, bunlar rafın içərisindəki serverlərlə interfeyslərin trafik qrafikləridir. Gördüyünüz kimi, daha da aşağı batdılar. Niyə aşağı düşdülər - 25% yox, bəzi hallarda 3-4 dəfə? TCP bağlantısı uğursuz olarsa, o, pozulmuş qovşaqdan keçməyə çalışmağa davam edir. Bu, DC daxilində xidmətin tipik davranışı ilə ağırlaşır - bir istifadəçi sorğusu üçün daxili xidmətlərə N sorğu yaradılır və cavab ya bütün məlumat mənbələri cavab verəndə, ya da tətbiqdə fasilə yarandıqda istifadəçiyə gedəcək. hələ də konfiqurasiya edilməli olan səviyyə. Yəni hər şey çox, çox pisdir.
İndi eyni sınaq, lakin axın etiketi dəyəri aktivdir. Gördüyünüz kimi, solda partiya monitorinqimiz eyni 25% azalıb. Bu, tamamilə düzgündür, çünki retranslyasiya haqqında heç nə bilmir, paketlər göndərir və sadəcə olaraq çatdırılan və itirilmiş paketlərin sayının nisbətini hesablayır.
Sağda isə xidmət cədvəli var. Problemli birləşmənin təsirini burada tapa bilməzsiniz. Eyni millisaniyələrdə trafik problemli ərazidən problemdən təsirlənməmiş qalan üç yuxarı keçidə axır. Özünü sağaldan bir şəbəkəmiz var.
Bu mənim son slaydımdır, ümumiləşdirmə vaxtıdır. İndi ümid edirəm ki, siz özünü sağaldan məlumat mərkəzi şəbəkəsini necə quracağınızı bilirsiniz. Linux nüvə arxivindən keçməyinizə və orada xüsusi yamaqlar axtarmağa ehtiyacınız olmayacaq; bilirsiniz ki, bu halda Flow etiketi problemi həll edir, lakin bu mexanizmə diqqətlə yanaşmaq lazımdır. Və bir daha vurğulayıram ki, əgər siz telekommunikasiya operatorusunuzsa, axın etiketindən hash funksiyası kimi istifadə etməməlisiniz, əks halda istifadəçilərinizin seanslarını pozacaqsınız.
Şəbəkə mühəndisləri konseptual dəyişiklikdən keçməlidirlər: şəbəkə ToR ilə deyil, şəbəkə cihazı ilə deyil, ev sahibi ilə başlayır. Kifayət qədər parlaq bir nümunə, həm RTO-nu dəyişdirmək, həm də hər hansı bir yayım xidmətlərinə axın etiketini düzəltmək üçün eBPF-dən necə istifadə etdiyimizdir.
Axın etiketi mexanikası, şübhəsiz ki, idarə olunan inzibati seqment daxilində digər tətbiqlər üçün uyğundur. Bu, məlumat mərkəzləri arasında trafik ola bilər və ya gedən trafiki idarə etmək üçün bu cür mexanikadan xüsusi şəkildə istifadə edə bilərsiniz. Ancaq bu barədə sizə, inşallah, gələn dəfə deyəcəyəm. Diqqətiniz üçün təşəkkürlər.
Mənbə: www.habr.com