ქსელი, რომელიც კურნავს თავის თავს: Flow Label-ის მაგია და დეტექტივი Linux-ის ბირთვის გარშემო. Yandex ანგარიში

თანამედროვე მონაცემთა ცენტრებს აქვთ ასობით აქტიური მოწყობილობა, რომლებიც დაფარულია სხვადასხვა ტიპის მონიტორინგით. მაგრამ სრულყოფილი ინჟინერიც კი, რომელსაც აქვს სრულყოფილი მონიტორინგი, შეძლებს სწორად უპასუხოს ქსელის უკმარისობას რამდენიმე წუთში. Next Hop 2020-ის კონფერენციაზე მოხსენებაში მე წარმოვადგინე მონაცემთა ცენტრის ქსელის დიზაინის მეთოდოლოგია, რომელსაც აქვს უნიკალური თვისება - მონაცემთა ცენტრი იკურნება თავის თავს მილიწამებში. უფრო სწორედ, ინჟინერი პრობლემას მშვიდად აგვარებს, სამსახურები კი ამას უბრალოდ ვერ ამჩნევენ.

- დასაწყისისთვის, საკმაოდ დეტალურ შესავალს გავაკეთებ მათთვის, ვინც, შესაძლოა, არ იცის თანამედროვე DC-ის სტრუქტურა.


ბევრი ქსელის ინჟინრისთვის, მონაცემთა ცენტრის ქსელი იწყება, რა თქმა უნდა, ToR-ით, თაროში ჩამრთველით. ToR ჩვეულებრივ აქვს ორი ტიპის ბმული. პატარები მიდიან სერვერებზე, სხვები - N-ჯერ მეტია - მიდიან პირველი დონის ხერხემლისკენ, ანუ მისი ამაღლებისკენ. ზედა ბმულები, როგორც წესი, განიხილება თანაბარი და ტრაფიკი ზედა ბმულებს შორის დაბალანსებულია ჰეშის საფუძველზე 5-tuple-დან, რომელიც მოიცავს proto, src_ip, dst_ip, src_port, dst_port. აქ სიურპრიზები არ არის.


შემდეგი, როგორ გამოიყურება თვითმფრინავების არქიტექტურა? პირველი დონის ხერხემლები არ არის დაკავშირებული ერთმანეთთან, არამედ ერთმანეთთან არის დაკავშირებული სუპერსპინების საშუალებით. ასო X იქნება პასუხისმგებელი სუპერსპინებზე, ის თითქმის ჯვარედინი კავშირის მსგავსია.


და გასაგებია, რომ მეორეს მხრივ, ტორი დაკავშირებულია პირველი დონის ყველა ხერხემალთან. რა არის მნიშვნელოვანი ამ სურათზე? თუ ჩვენ გვაქვს ურთიერთქმედება თაროს შიგნით, მაშინ ურთიერთქმედება, რა თქმა უნდა, გადის ToR-ში. თუ ურთიერთქმედება მოდულის შიგნით მიდის, მაშინ ურთიერთქმედება გადის პირველი დონის ხერხემალებში. თუ ურთიერთქმედება ინტერმოდულურია - როგორც აქ, ToR 1 და ToR 2 - მაშინ ურთიერთქმედება გაივლის როგორც პირველი, ისე მეორე დონის ხერხემლებს.


თეორიულად, ასეთი არქიტექტურა ადვილად მასშტაბირებადია. თუ გვაქვს პორტის სიმძლავრე, მონაცემთა ცენტრში სივრცის რეზერვი და წინასწარ დაყენებული ბოჭკო, მაშინ თვითმფრინავების რაოდენობა ყოველთვის შეიძლება გაიზარდოს, რითაც გაიზრდება სისტემის საერთო სიმძლავრე. ქაღალდზე, ამის გაკეთება ძალიან მარტივია. რეალურ ცხოვრებაშიც ასე იქნებოდა. მაგრამ დღევანდელი ამბავი ამაზე არ არის.


მინდა სწორი დასკვნების გაკეთება. ჩვენ გვაქვს მრავალი გზა მონაცემთა ცენტრის შიგნით. ისინი პირობითად დამოუკიდებლები არიან. მონაცემთა ცენტრის შიგნით ერთი გზა შესაძლებელია მხოლოდ ToR-ში. მოდულის შიგნით გვაქვს ბილიკების იგივე რაოდენობა, როგორც თვითმფრინავების რაოდენობა. მოდულებს შორის ბილიკების რაოდენობა უდრის სიბრტყეების რაოდენობის ნამრავლს და თითოეულ სიბრტყეში სუპერსპინების რაოდენობას. უფრო გასაგებად, მასშტაბის შესაგრძნობად, მე მივცემ ციფრებს, რომლებიც მოქმედებს Yandex მონაცემთა ერთ-ერთი ცენტრისთვის.


არის რვა თვითმფრინავი, თითოეულ თვითმფრინავს აქვს 32 სუპერსპინა. შედეგად, ირკვევა, რომ მოდულის შიგნით არის რვა ბილიკი და ინტერმოდულური ურთიერთქმედებით უკვე 256 მათგანია.

ანუ, თუ ჩვენ ვავითარებთ კულინარიულ წიგნს, ვცდილობთ ვისწავლოთ თუ როგორ უნდა ავაშენოთ შეცდომისადმი ტოლერანტული მონაცემთა ცენტრები, რომლებიც თავად განიკურნებიან, მაშინ პლანშეტური არქიტექტურა სწორი არჩევანია. ეს საშუალებას გაძლევთ გადაჭრას სკალირების პრობლემა და თეორიულად ეს მარტივია. ბევრი დამოუკიდებელი გზა არსებობს. რჩება კითხვა: როგორ გადარჩება ასეთი არქიტექტურა წარუმატებლობებს? არის სხვადასხვა ავარია. და ჩვენ ახლა განვიხილავთ ამას.


დაე, ჩვენი ერთ-ერთი სუპერსპინი დაავადდეს. აქ დავუბრუნდი ორი თვითმფრინავის არქიტექტურას. ჩვენ მათ მაგალითს მივყვებით, რადგან უფრო ადვილი იქნება იმის დანახვა, თუ რა ხდება აქ ნაკლები მოძრავი ნაწილებით. დაე X11 დაავადდეს. როგორ იმოქმედებს ეს სერვისებზე, რომლებიც ცხოვრობენ მონაცემთა ცენტრებში? ბევრი რამ არის დამოკიდებული იმაზე, თუ როგორ გამოიყურება მარცხი სინამდვილეში.


თუ მარცხი კარგია, ის დაჭერილია იმავე BFD-ის ავტომატიზაციის დონეზე, ავტომატიზაცია სიხარულით აყენებს პრობლემურ სახსრებს და იზოლირებს პრობლემას, მაშინ ყველაფერი კარგადაა. ბევრი ბილიკი გვაქვს, მოძრაობა მყისიერად გადადის ალტერნატიულ მარშრუტებზე და სერვისები ვერაფერს შეამჩნევენ. ეს კარგი სცენარია.


ცუდი სცენარია, თუ ჩვენ გვაქვს მუდმივი დანაკარგები და ავტომატიზაცია ვერ ამჩნევს პრობლემას. იმის გასაგებად, თუ როგორ იმოქმედებს ეს აპლიკაციაზე, ცოტა დრო მოგვიწევს იმის განხილვაზე, თუ როგორ მუშაობს TCP პროტოკოლი.


იმედი მაქვს, რომ არავის შოკში არ ჩავაყენებ ამ ინფორმაციით: TCP არის ხელის ჩამორთმევის პროტოკოლი. ანუ, უმარტივეს შემთხვევაში, გამომგზავნი აგზავნის ორ პაკეტს და იღებს მათზე კუმულატიურ ცნობას: "მე მივიღე ორი პაკეტი".


ამის შემდეგ ის კიდევ ორ პაკეტს გაუგზავნის და სიტუაცია განმეორდება. წინასწარ ბოდიშს ვიხდი გარკვეული გამარტივებისთვის. ეს სცენარი სწორია, თუ ფანჯარა (ფრენის პაკეტების რაოდენობა) არის ორი. რა თქმა უნდა, ზოგად შემთხვევაში ეს სულაც არ არის ასე. მაგრამ ფანჯრის ზომა გავლენას არ ახდენს პაკეტის გადაგზავნის კონტექსტზე.


რა მოხდება, თუ დავკარგავთ მე-3 პაკეტს? ამ შემთხვევაში, მიმღები მიიღებს პაკეტებს 1, 2 და 4. და ის პირდაპირ ეტყვის გამგზავნს SACK ოფციის გამოყენებით: „იცით, სამი მოვიდა, მაგრამ შუა დაიკარგა“. ის ამბობს: "Ack 2, SACK 4".


გამგზავნი ამ მომენტში იმეორებს ზუსტად იმ პაკეტს, რომელიც უპრობლემოდ დაიკარგა.


მაგრამ თუ ფანჯარაში ბოლო პაკეტი დაიკარგება, სიტუაცია ძალიან განსხვავებულად გამოიყურება.

მიმღები იღებს პირველ სამ პაკეტს და პირველ რიგში იწყებს ლოდინს. Linux-ის ბირთვის TCP სტეკში გარკვეული ოპტიმიზაციის წყალობით, ის დაელოდება დაწყვილებულ პაკეტს, თუ დროშებში არ არის აშკარა მითითება, რომ ეს არის ბოლო პაკეტი ან მსგავსი რამ. ის დაელოდება გადადებული ACK-ის ვადის ამოწურვას და შემდეგ გაგზავნის დადასტურებას პირველი სამი პაკეტისთვის. მაგრამ ახლა გამგზავნი დაელოდება. მან არ იცის, მეოთხე პაკეტი დაიკარგა თუ მისვლას აპირებს. და იმისათვის, რომ არ გადაიტვირთოს ქსელი, ის შეეცდება დაელოდოს მკაფიო მითითებას, რომ პაკეტი დაიკარგა, ან RTO ვადის ამოწურვა.


რა არის RTO დროის ამოწურვა? ეს არის მაქსიმუმი RTT-დან, რომელიც გამოითვლება TCP სტეკით და გარკვეული მუდმივი. რა არის ეს მუდმივი, ახლა განვიხილავთ.


მაგრამ მნიშვნელოვანია, რომ თუ ისევ გაგვიმართლა და მეოთხე პაკეტი ისევ დაიკარგა, მაშინ RTO გაორმაგდება. ანუ ყოველი წარუმატებელი მცდელობა არის ტაიმაუტის გაორმაგება.


ახლა ვნახოთ, რას უდრის ეს ბაზა. ნაგულისხმევად, მინიმალური RTO არის 200 ms. ეს არის მინიმალური RTO მონაცემთა პაკეტებისთვის. SYN პაკეტებისთვის ეს განსხვავებულია, 1 წამი. როგორც ხედავთ, პაკეტების ხელახლა გაგზავნის პირველ მცდელობასაც კი 100-ჯერ მეტი დრო დასჭირდება, ვიდრე RTT მონაცემთა ცენტრის შიგნით.


ახლა დავუბრუნდეთ ჩვენს სცენარს. რა ხდება სერვისზე? სერვისი იწყებს პაკეტების დაკარგვას. დაე, სერვისს თავდაპირველად გაუმართლოს და დაკარგოს რაღაც ფანჯრის შუაში, შემდეგ ის იღებს SACK-ს, ხელახლა აგზავნის დაკარგული პაკეტებს.


მაგრამ თუ ცუდი იღბალი მეორდება, მაშინ ჩვენ გვაქვს RTO. რა არის აქ მნიშვნელოვანი? დიახ, ჩვენს ქსელში ბევრი გზა გვაქვს. მაგრამ ერთი კონკრეტული TCP კავშირის TCP ტრაფიკი გაგრძელდება იმავე გატეხილი სტეკის გავლით. პაკეტის დანაკარგები, იმ პირობით, რომ ჩვენი ჯადოსნური X11 არ გაქრება თავისით, არ იწვევს ტრაფიკის გადინებას არაპრობლემურ ადგილებში. ჩვენ ვცდილობთ პაკეტის მიწოდებას იმავე გატეხილი სტეკის მეშვეობით. ეს იწვევს კასკადურ წარუმატებლობას: მონაცემთა ცენტრი არის ურთიერთდაკავშირებული აპლიკაციების ნაკრები და ყველა ამ აპლიკაციის ზოგიერთი TCP კავშირი იწყებს დეგრადაციას - რადგან superspine გავლენას ახდენს ყველა აპლიკაციაზე, რომელიც არსებობს მონაცემთა ცენტრში. როგორც ნათქვამია: თუ ცხენს არ აყოლებდი, ცხენი კოჭლობდა; ცხენი კოჭლობდა - მოხსენება არ მიუტანეს; ანგარიში არ მოგვაწოდა - ომი წავაგეთ. მხოლოდ აქ დათვლა ხდება წამებში პრობლემის წარმოქმნის მომენტიდან დეგრადაციის ეტაპამდე, რომლის განცდასაც იწყებენ სერვისები. ეს ნიშნავს, რომ მომხმარებლებმა შეიძლება გამოტოვონ რაღაც სადღაც.


არსებობს ორი კლასიკური გადაწყვეტა, რომლებიც ავსებენ ერთმანეთს. პირველი არის სერვისები, რომლებიც ცდილობენ ჩალაგონ და მოაგვარონ პრობლემა ასე: „მოდით, რამე შევცვალოთ TCP სტეკში. და მოდით გავაკეთოთ განაცხადის დონის ვადები ან ხანგრძლივი TCP სესიები ჯანმრთელობის შიდა შემოწმებით. პრობლემა ის არის, რომ ასეთი გადაწყვეტილებები: ა) საერთოდ არ მასშტაბირებს; ბ) ძალიან ცუდად შემოწმებული. ანუ, მაშინაც კი, თუ სერვისი შემთხვევით დააკონფიგურირებს TCP დასტას ისე, რომ ის უკეთესი გახდეს, ჯერ ერთი, ეს ნაკლებად სავარაუდოა, რომ გამოყენებული იყოს ყველა აპლიკაციასა და მონაცემთა ცენტრზე და მეორეც, სავარაუდოდ, ის ვერ გაიგებს რა გაკეთდა სწორად და რა. არა. ანუ მუშაობს, მაგრამ ცუდად მუშაობს და არ მასშტაბებს. და თუ არის ქსელის პრობლემა, ვინ არის დამნაშავე? რა თქმა უნდა NOC. რას აკეთებს NOC?

ბევრი სერვისი თვლის, რომ NOC-ში მუშაობა ასე მიდის. მაგრამ მართალი გითხრათ, არა მხოლოდ.


NOC კლასიკურ სქემაში ჩართულია მრავალი მონიტორინგის შემუშავებით. ეს არის როგორც შავი ყუთის მონიტორინგი, ასევე თეთრი ყუთის მონიტორინგი. შავი ყუთის მაგალითზე - ხერხემლის მონიტორინგი განუცხადა ალექსანდრე კლიმენკო ბოლო Next Hop-ზე. სხვათა შორის, ეს მონიტორინგი მუშაობს. მაგრამ იდეალურ მონიტორინგსაც კი ექნება დროის შეფერხება. როგორც წესი, ეს რამდენიმე წუთია. მისი გამორთვის შემდეგ, მორიგე ინჟინერებს დრო სჭირდებათ, რომ გადაამოწმონ მისი მოქმედება, მოახდინოს პრობლემის ლოკალიზება და შემდეგ პრობლემური ზონის ჩაქრობა. ანუ, საუკეთესო შემთხვევაში, პრობლემის მკურნალობას სჭირდება 5 წუთი, უარეს შემთხვევაში, 20 წუთი, თუ დაუყოვნებლივ არ არის აშკარა, სად ხდება დანაკარგები. გასაგებია, რომ მთელი ამ დროის განმავლობაში - 5 თუ 20 წუთი - ჩვენი სერვისები კვლავაც იტანჯება, რაც ალბათ არ არის კარგი.


რის მიღებას ისურვებდით? ამდენი გზა გვაქვს. და პრობლემები წარმოიქმნება ზუსტად იმის გამო, რომ TCP ნაკადები, რომლებსაც არ გაუმართლა, აგრძელებენ იმავე მარშრუტის გამოყენებას. ჩვენ გვჭირდება რაღაც, რაც საშუალებას მოგვცემს გამოვიყენოთ მრავალი მარშრუტი ერთი TCP კავშირის ფარგლებში. როგორც ჩანს, გამოსავალი გვაქვს. არის TCP, რომელსაც ეძახიან - multipath TCP, ანუ TCP მრავალი ბილიკისთვის. მართალია, ის შეიქმნა სრულიად განსხვავებული ამოცანისთვის - სმარტფონებისთვის, რომლებსაც აქვთ რამდენიმე ქსელური მოწყობილობა. გადაცემის მაქსიმალურად გაზრდის ან პირველადი / სარეზერვო რეჟიმის შესაქმნელად, შეიქმნა მექანიზმი, რომელიც გამჭვირვალედ ქმნის რამდენიმე თემას (სესიას) აპლიკაციისთვის და საშუალებას გაძლევთ გადახვიდეთ მათ შორის წარუმატებლობის შემთხვევაში. ან, როგორც ვთქვი, მაქსიმალურად გაზარდეთ გამტარობა.

მაგრამ აქ არის ნიუანსი. იმის გასაგებად, თუ რა არის ეს, ჩვენ უნდა გადავხედოთ, თუ როგორ არის ჩამოყალიბებული ძაფები.


ძაფები დაყენებულია თანმიმდევრობით. პირველი ნაკადი დაყენებულია ჯერ. შემდგომი ნაკადები დაყენებულია ქუქიის გამოყენებით, რომელიც უკვე შეთანხმებულია ამ თემაში. და აქ არის პრობლემა.


პრობლემა ის არის, რომ თუ პირველი თემა არ დაინსტალირდება, მეორე და მესამე თემა არასოდეს გამოვა. ანუ, multipath TCP არ წყვეტს SYN პაკეტის დაკარგვას პირველ ნაკადში. და თუ SYN დაიკარგება, მრავალმხრივი TCP ხდება ნორმალური TCP. ასე რომ, მონაცემთა ცენტრის გარემოში, ეს არ დაგვეხმარება ქარხნის დანაკარგების პრობლემის გადაჭრაში და ვისწავლოთ თუ როგორ გამოვიყენოთ მრავალი ბილიკი წარუმატებლობის შემთხვევაში.


რა შეიძლება დაგვეხმაროს? ზოგიერთმა თქვენგანმა უკვე გამოიცანით სახელიდან, რომ IPv6 ნაკადის ლეიბლის სათაურის ველი მნიშვნელოვანი ველი იქნება ჩვენს შემდგომ ისტორიაში. მართლაც, ეს არის ველი, რომელიც ჩანს v6-ში, ის არ არის v4-ში, სჭირდება 20 ბიტი და დიდი ხანია არსებობს კამათი მის გამოყენებასთან დაკავშირებით. ეს ძალიან საინტერესოა - იყო დავები, რაღაც დაფიქსირდა RFC-ის ფარგლებში და ამავდროულად, Linux-ის ბირთვში გაჩნდა იმპლემენტაცია, რომელიც არასოდეს ყოფილა არსად დოკუმენტირებული.


გირჩევთ შემომიერთდეთ პატარა გამოძიებაში. მოდით შევხედოთ რა ხდებოდა Linux-ის ბირთვში ბოლო რამდენიმე წლის განმავლობაში.

2014 წელი. დიდი და რეპუტაციის მქონე კომპანიის ინჟინერი ლინუქსის ბირთვის ფუნქციონალურობას ამატებს ნაკადის ეტიკეტის მნიშვნელობის დამოკიდებულებას სოკეტის ჰეშზე. რის გამოსწორებას ცდილობენ აქ? ეს დაკავშირებულია RFC 6438-თან, რომელიც განიხილავდა შემდეგ საკითხს. მონაცემთა ცენტრის შიგნით, IPv4 ხშირად არის ჩასმული IPv6 პაკეტებში, რადგან თავად ქარხანა არის IPv6, მაგრამ IPv4 როგორმე უნდა იყოს გაცემული. დიდი ხნის განმავლობაში იყო პრობლემები გადამრთველებთან, რომლებიც ვერ ხედავდნენ ორი IP სათაურის ქვეშ TCP ან UDP-ზე მისასვლელად და იქ src_ports, dst_ports-ის პოვნა. აღმოჩნდა, რომ ჰეში, თუ გადავხედავთ პირველ ორ IP სათაურს, თითქმის დაფიქსირებული აღმოჩნდა. ამის თავიდან აცილების მიზნით, რომ დაბალანსება ამ ენკაფსულირებული ტრაფიკის სწორად იმუშაოს, შემოთავაზებული იყო ჰეშის დამატება 5-ჯერადი კაფსულირებული პაკეტიდან ნაკადის ეტიკეტის ველის მნიშვნელობაზე. დაახლოებით იგივე გაკეთდა სხვა ინკაფსულაციის სქემებისთვის, UDP-სთვის, GRE-სთვის, ამ უკანასკნელში გამოყენებული იყო GRE Key ველი. ასეა თუ ისე, აქ მიზნები ნათელია. და ყოველ შემთხვევაში, დროის იმ მომენტში ისინი სასარგებლო იყვნენ.

2015 წელს, ახალი პატჩი მოდის იმავე პატივცემული ინჟინრისგან. ის ძალიან საინტერესოა. მასში ნათქვამია შემდეგი - ჩვენ რანდომიზირებთ ჰეშს უარყოფითი მარშრუტიზაციის მოვლენის შემთხვევაში. რა არის უარყოფითი მარშრუტის მოვლენა? ეს არის RTO, რომელიც ადრე განვიხილეთ, ანუ ფანჯრის კუდის დაკარგვა არის მოვლენა, რომელიც ნამდვილად უარყოფითია. მართალია, შედარებით ძნელი მისახვედრია, რომ ეს არის.

2016, კიდევ ერთი პატივცემული კომპანია, ასევე დიდი. ის აანალიზებს ბოლო ხელჯოხებს და აკეთებს ისე, რომ ჰეში, რომელიც ადრე რანდომიზებულია, ახლა იცვლება ყოველ SYN გადაცემაზე და ყოველი RTO დროის ამოწურვის შემდეგ. და ამ წერილში, პირველად და უკანასკნელად, ჟღერს საბოლოო მიზანი - დარწმუნდეთ, რომ ტრაფიკს არხების დაკარგვის ან გადატვირთვის შემთხვევაში აქვს რბილი გადამისამართების შესაძლებლობა, მრავალი ბილიკის გამოყენებით. რა თქმა უნდა, ამის შემდეგ ბევრი პუბლიკაცია იყო, მათ ადვილად იპოვით.

თუმცა არა, თქვენ არ შეგიძლიათ, რადგან ამ თემაზე არც ერთი პუბლიკაცია არ ყოფილა. მაგრამ ჩვენ ვიცით!

და თუ ბოლომდე ვერ გაიგე რა გაკეთდა, ახლავე გეტყვი.


რა გაკეთდა, რა ფუნქციონირება დაემატა Linux-ის ბირთვს? txhash იცვლება შემთხვევით მნიშვნელობაზე ყოველი RTO მოვლენის შემდეგ. ეს არის იგივე უარყოფითი მარშრუტის შედეგი. ჰეში დამოკიდებულია ამ txhash-ზე და flow label დამოკიდებულია skb ჰეშზე. აქ არის გარკვეული გამოთვლები ფუნქციებზე, ყველა დეტალი ერთ სლაიდზე ვერ განთავსდება. თუ ვინმეს აინტერესებს, შეგიძლიათ გაიაროთ ბირთვის კოდი და შეამოწმოთ.

რა არის აქ მნიშვნელოვანი? ნაკადის ეტიკეტის ველის მნიშვნელობა იცვლება შემთხვევით რიცხვში ყოველი RTO-ს შემდეგ. როგორ მოქმედებს ეს ჩვენს უიღბლო TCP ნაკადზე?


SACK-ის შემთხვევაში არაფერი შეცვლილა, რადგან ჩვენ ვცდილობთ ხელახლა გავაგზავნოთ ცნობილი დაკარგული პაკეტი. ჯერჯერობით კარგია.


მაგრამ RTO-ს შემთხვევაში, იმ პირობით, რომ ჩვენ დავამატეთ ნაკადის ლეიბლი ჰეშის ფუნქციას ToR-ზე, ტრაფიკს შეუძლია სხვა მარშრუტი მიიღოს. და რაც უფრო მეტი თვითმფრინავია, მით მეტია ალბათობა იმისა, რომ იპოვონ გზა, რომელზეც გავლენას არ მოახდენს ავარია კონკრეტულ მოწყობილობაზე.


რჩება ერთი პრობლემა - RTO. სხვა მარშრუტი, რა თქმა უნდა, არის ნაპოვნი, მაგრამ მასზე დიდი დრო იხარჯება. 200 ms ბევრია. მეორე არის ზოგადად ველურობა. ადრე მე ვისაუბრე სერვისების კონფიგურაციის ვადებზე. ასე რომ, მეორე არის დრო, რომელიც ჩვეულებრივ აყენებს სერვისს აპლიკაციის დონეზე და ამაში სერვისი შედარებით სწორიც კი იქნება. უფრო მეტიც, ვიმეორებ, თანამედროვე მონაცემთა ცენტრის შიგნით რეალური RTT არის დაახლოებით 1 მილიწამი.


რა შეიძლება გაკეთდეს RTO დროის ამოწურვის შესახებ? დროის ამოწურვა, რომელიც პასუხისმგებელია RTO-ზე მონაცემთა პაკეტების დაკარგვის შემთხვევაში, შეიძლება შედარებით მარტივად იყოს კონფიგურირებული მომხმარებლის სივრციდან: არის IP უტილიტა და მისი ერთ-ერთი პარამეტრი შეიცავს იგივე rto_min. იმის გათვალისწინებით, რომ, რა თქმა უნდა, თქვენ უნდა გადააქციოთ RTO არა გლობალურად, მაგრამ მოცემული პრეფიქსებისთვის, ასეთი მექანიზმი საკმაოდ მუშაობს.


მართალია, SYN_RTO-სთან ერთად ყველაფერი გარკვეულწილად უარესია. ის ბუნებრივად არის დაფქული. ბირთვს აქვს ფიქსირებული მნიშვნელობა 1 წამი და ეს არის ის. თქვენ ვერ შეხვალთ იქ მომხმარებლის სივრციდან. მხოლოდ ერთი გზაა.


eBPF მოდის სამაშველოში. მარტივად რომ ვთქვათ, ეს არის პატარა C პროგრამები. მათი ჩასმა შესაძლებელია კერნელის სტეკისა და TCP სტეკის შესრულების სხვადასხვა ადგილას, რომლითაც შეგიძლიათ შეცვალოთ ძალიან დიდი რაოდენობის პარამეტრები. ზოგადად, eBPF არის გრძელვადიანი ტენდენცია. იმის ნაცვლად, რომ დაინახათ ათობით ახალი sysctl პარამეტრი და გააფართოვოთ IP უტილიტა, მოძრაობა არის eBPF-ის მიმართულებით და გააფართოოს მისი ფუნქციონირება. eBPF-ით შეგიძლიათ დინამიურად შეცვალოთ გადატვირთულობის კონტროლი და სხვა TCP პარამეტრები.


მაგრამ ჩვენთვის მნიშვნელოვანია, რომ მისი დახმარებით შეძლოთ SYN_RTO-ს მნიშვნელობების გადახვევა. და არის საჯაროდ გამოქვეყნებული მაგალითი: https://elixir.bootlin.com/linux/latest/source/samples/bpf/tcp_synrto_kern.c. რა კეთდება აქ? მაგალითი მუშაობს, მაგრამ თავისთავად ძალიან უხეშია. აქ ვარაუდობენ, რომ მონაცემთა ცენტრის შიგნით ვადარებთ პირველ 44 ბიტს, თუ ისინი ემთხვევა, მაშინ აღმოვჩნდებით DC-ში. და ამ შემთხვევაში, ჩვენ ვცვლით SYN_RTO დროის ამოწურვის მნიშვნელობას 4ms. იგივე დავალების შესრულება ბევრად უფრო მოხდენილად შეიძლება. მაგრამ ეს მარტივი მაგალითი გვიჩვენებს რა არის ა) შესაძლებელი; ბ) შედარებით მარტივი.

რა ვიცით უკვე? ის, რომ პლანტური არქიტექტურა სკალირების საშუალებას იძლევა, ჩვენთვის ძალიან სასარგებლო აღმოჩნდება, როდესაც ჩართავთ ნაკადის ეტიკეტს ToR-ზე და ვიღებთ შესაძლებლობას შემოვა პრობლემურ ზონებში. საუკეთესო გზა RTO და SYN-RTO მნიშვნელობების შესამცირებლად არის eBPF პროგრამების გამოყენება. რჩება კითხვა: უსაფრთხოა თუ არა ნაკადის ეტიკეტის გამოყენება დაბალანსებისთვის? და აქ არის ნიუანსი.


დავუშვათ, რომ თქვენ გაქვთ სერვისი ქსელში, რომელიც ცხოვრობს anycast-ში. სამწუხაროდ, მე არ მაქვს დრო, რომ დეტალურად შევისწავლო anycast-ის შესახებ, მაგრამ ეს არის განაწილებული სერვისი, სადაც სხვადასხვა ფიზიკური სერვერები ხელმისაწვდომია იმავე IP მისამართით. და აქ არის შესაძლო პრობლემა: RTO მოვლენა შეიძლება მოხდეს არა მხოლოდ მაშინ, როდესაც ტრაფიკი გადის ქარხანაში. ის ასევე შეიძლება მოხდეს ToR ბუფერულ დონეზე: როდესაც ხდება incast მოვლენა, ის შეიძლება მოხდეს ჰოსტზეც კი, როდესაც მასპინძელი რაღაცას დაღვრის. როდესაც ხდება RTO მოვლენა და ის ცვლის ნაკადის ეტიკეტს. ამ შემთხვევაში, ტრაფიკი შეიძლება გადავიდეს სხვა ნებისმიერ ინსტანციაზე. დავუშვათ, რომ ეს არის ნებისმიერი კასტი სახელმწიფო, შეიცავს კავშირის მდგომარეობას - ეს შეიძლება იყოს L3 Balancer ან სხვა სერვისი. შემდეგ ჩნდება პრობლემა, რადგან RTO-ს შემდეგ TCP კავშირი შემოდის სერვერზე, რომელმაც არაფერი იცის ამ TCP კავშირის შესახებ. და თუ ჩვენ არ გვაქვს სახელმწიფო გაზიარება anycast სერვერებს შორის, მაშინ ასეთი ტრაფიკი დაიკარგება და TCP კავშირი გაწყდება.


რა შეიძლება გაკეთდეს აქ? თქვენს კონტროლირებად გარემოში, სადაც ჩართავთ ნაკადის ლეიბლის ბალანსირებას, თქვენ უნდა დააფიქსიროთ ნაკადის ლეიბლის მნიშვნელობა anycast სერვერებზე წვდომისას. უმარტივესი გზაა ამის გაკეთება იგივე eBPF პროგრამის საშუალებით. მაგრამ აქ არის ძალიან მნიშვნელოვანი მომენტი - რა უნდა გააკეთოთ, თუ არ მართავთ მონაცემთა ცენტრის ქსელს, მაგრამ ხართ ტელეკომის ოპერატორი? ესეც თქვენი პრობლემაა: Juniper-ისა და Arista-ს გარკვეული ვერსიებიდან დაწყებული, ისინი ნაგულისხმევად შეიცავენ ნაკადის ეტიკეტს ჰეშის ფუნქციაში - მართალი გითხრათ, უმიზეზოდ მე მესმის. ამან შეიძლება გამოიწვიოს თქვენი ქსელის მეშვეობით გამავალი მომხმარებლებისგან TCP კავშირების გაუქმება. ამიტომ, გირჩევთ შეამოწმოთ თქვენი როუტერის პარამეტრები ამ ადგილას.

ასეა თუ ისე, მეჩვენება, რომ მზად ვართ ექსპერიმენტებზე გადავიდეთ.


როდესაც ჩვენ ჩავრთეთ ნაკადის ეტიკეტი ToR-ზე, მოვამზადეთ აგენტის eBPF, რომელიც ახლა ცხოვრობს მასპინძლებზე, გადავწყვიტეთ არ დაველოდოთ შემდეგ დიდ წარუმატებლობას, არამედ განვახორციელოთ კონტროლირებადი აფეთქებები. ჩვენ ავიღეთ ToR, რომელსაც აქვს ოთხი აღმავალი ბმული, და ჩავუშვით ერთ-ერთ მათგანზე. დახაზეს წესი, თქვეს - ახლა ყველა პაკეტს კარგავო. როგორც ხედავთ მარცხნივ, გვაქვს თითო პაკეტზე მონიტორინგი, რომელიც დაეცა 75%-მდე, ანუ დაკარგულია პაკეტების 25%. მარჯვნივ არის ამ ToR-ის მიღმა მცხოვრები სერვისების გრაფიკები. სინამდვილეში, ეს არის სახსრების ტრაფიკის გრაფიკები სერვერებთან თაროს შიგნით. როგორც ხედავთ, ისინი კიდევ უფრო დაბლა ჩაიძირნენ. რატომ ჩაიძირნენ დაბლა - არა 25%-ით, არამედ ზოგ შემთხვევაში 3-4-ჯერ? თუ TCP კავშირს არ გაუმართლა, ის აგრძელებს გატეხილი ინტერფეისის მეშვეობით დაკავშირების მცდელობას. ამას ამძაფრებს სერვისის ტიპიური ქცევა DC-ში - მომხმარებლის ერთი მოთხოვნისთვის, N მოთხოვნა შიდა სერვისებზე გენერირებულია და პასუხი მიდის მომხმარებელზე, როდესაც პასუხობს მონაცემთა ყველა წყარო, ან როდესაც დროთა განმავლობაში ამოიწურება განაცხადის დონე, რომელიც ჯერ კიდევ საჭიროებს კონფიგურაციას. ანუ ყველაფერი ძალიან, ძალიან ცუდია.


ახლა იგივე ექსპერიმენტი, მაგრამ ნაკადის ლეიბლი ჩართულია. როგორც ხედავთ, მარცხნივ, ჩვენი პარტიული მონიტორინგი იგივე 25%-ით ჩაიძირა. ეს აბსოლუტურად სწორია, რადგან მან არაფერი იცის ხელახალი გადაცემის შესახებ, აგზავნის პაკეტებს და უბრალოდ ითვლის მიწოდებული და დაკარგული პაკეტების რაოდენობის თანაფარდობას.

და მარჯვნივ არის მომსახურების გრაფიკი. აქ ვერ იპოვით პრობლემური სახსრის ეფექტს. ტრაფიკი იმავე მილიწამებში მიედინებოდა პრობლემური ზონიდან სამ დანარჩენ ბმულზე, რომლებსაც პრობლემა არ შეეხო. ჩვენ მივიღეთ ქსელი, რომელიც თავისთავად იკურნება.

ეს ჩემი ბოლო სლაიდია, დროა გავაანალიზო. ახლა, იმედი მაქვს, თქვენ იცით, როგორ ააწყოთ თვითგანკურნების მონაცემთა ცენტრის ქსელი. თქვენ არ დაგჭირდებათ Linux-ის ბირთვის არქივის გავლა და იქ სპეციალური პაჩების ძებნა, თქვენ იცით, რომ Flow label ამ შემთხვევაში პრობლემას აგვარებს, მაგრამ ამ მექანიზმს ფრთხილად უნდა მიუდგეთ. და კიდევ ერთხელ ხაზს ვუსვამ, რომ თუ თქვენ ხართ გადამზიდავი, არ უნდა გამოიყენოთ flow label, როგორც ჰეშის ფუნქცია, წინააღმდეგ შემთხვევაში თქვენ დაარღვიებთ თქვენი მომხმარებლების სესიებს.

ქსელის ინჟინრებისთვის კონცეპტუალური ცვლილება უნდა მოხდეს: ქსელი არ იწყება ToR-ით, არა ქსელური მოწყობილობით, არამედ ჰოსტთან. საკმაოდ თვალსაჩინო მაგალითია, თუ როგორ ვიყენებთ eBPF-ს, როგორც RTO-ს შესაცვლელად, ასევე ნაკადის ეტიკეტის დასაფიქსირებლად anycast სერვისების მიმართ.

ნაკადის ეტიკეტის მექანიკა, რა თქმა უნდა, შესაფერისია კონტროლირებადი ადმინისტრაციული სეგმენტის სხვა გამოყენებისთვის. ეს შეიძლება იყოს ტრაფიკი მონაცემთა ცენტრებს შორის, ან შეგიძლიათ გამოიყენოთ ასეთი მექანიკა სპეციალური გზით გამავალი ტრაფიკის გასაკონტროლებლად. მაგრამ ამაზე ვისაუბრებ, იმედია შემდეგ ჯერზე. Დიდი მადლობა ყურადღებისთვის.

წყარო: www.habr.com