როგორ გავაფართოვოთ მონაცემთა ცენტრები. Yandex ანგარიში

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

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

- Საღამო მშვიდობისა, ყველას! მე მქვია დიმიტრი აფანასიევი, მე ვარ ქსელის არქიტექტორი Yandex-ში და ძირითადად ვგეგმავ მონაცემთა ცენტრის ქსელებს.



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

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

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

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

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

მონაცემთა ცენტრის ქსელის დიზაინის ბოლო რამდენიმე გამეორებამ გამოიყენა მრავალშრიანი Clos ტოპოლოგიები და არის მხოლოდ L3. ცოტა ხნის წინ ლ2 დავტოვეთ და შვებით ამოვისუნთქეთ. და ბოლოს, ჩვენი ინფრასტრუქტურა მოიცავს ასობით ათასი გამოთვლითი (სერვერის) ინსტანციას. კლასტერის მაქსიმალური ზომა რამდენიმე ხნის წინ იყო დაახლოებით 10 ათასი სერვერი. ეს დიდწილად განპირობებულია იმით, თუ როგორ მუშაობს იგივე კლასტერის დონის ოპერაციული სისტემები, გრაფიკები, რესურსების განაწილება და ა.შ. მას შემდეგ, რაც პროგრესი მოხდა ინფრასტრუქტურული პროგრამული უზრუნველყოფის მხრივ, სამიზნე ზომა ახლა არის დაახლოებით 100 ათასი სერვერი ერთ გამოთვლით კლასტერში და ჩვენ გვაქვს დავალება - შევძლოთ ავაშენოთ ქსელური ქარხნები, რომლებიც საშუალებას იძლევა რესურსების ეფექტური გაერთიანება ასეთ კლასტერში.

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

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

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

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

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

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

მაშ, რა არის ის, რაც არ გვჭირდება, რისი დათმობა შევძელით, არა ყოველთვის სიხარულით, როცა ეს მოხდა, არამედ დიდი შვებით, როცა პროცესი დასრულებულია?

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

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

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

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

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

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

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

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

რა თქმა უნდა, ჩნდება კითხვა: Clos-ის ქსელები უკვე დიდი ხანია აშენდა; თავად იდეა, ზოგადად, კლასიკური ტელეფონის, TDM ქსელების დროიდან მოდის. იქნებ რაღაც უკეთესი გამოჩნდა, იქნებ რამე უკეთესად გაკეთდეს? Კი და არა. თეორიულად კი, პრაქტიკაში უახლოეს მომავალში ნამდვილად არა. იმის გამო, რომ არსებობს არაერთი საინტერესო ტოპოლოგია, ზოგიერთი მათგანი წარმოებაშიც კი გამოიყენება, მაგალითად, Dragonfly გამოიყენება HPC აპლიკაციებში; ასევე არის ისეთი საინტერესო ტოპოლოგიები, როგორიცაა Xpander, FatClique, Jellyfish. თუ ბოლო დროს გადახედავთ ანგარიშებს კონფერენციებზე, როგორიცაა SIGCOMM ან NSDI, შეგიძლიათ იპოვოთ საკმაოდ დიდი რაოდენობის სამუშაოები ალტერნატიულ ტოპოლოგიებზე, რომლებსაც აქვთ უკეთესი თვისებები (ერთი ან მეორე), ვიდრე Clos.

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

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

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

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

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

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

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

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

თუ გადახედავთ Clos ქსელის გაფართოებულ ვერსიას (ქვედა მარჯვენა კუთხეში) და დაუბრუნდებით ამ სურათს ქვემოთ Clos ქსელით...

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

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

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

ჩანს, რომ მთელ ამ დიზაინში ორნახევარი ვარიანტია საინტერესო. არის ვარიანტი ორ ფენიანი წვეთებით და 64-პორტიანი გადამრთველებით, რაც ცოტათი ჩამორჩება. შემდეგ არის იდეალურად მორგებული ვარიანტები 128-პორტიანი (რადიქსი 128) ხერხემლის გადამრთველებისთვის ორი დონის, ან გადამრთველებისთვის რადიქსი 32 სამი დონის მქონე. და ყველა შემთხვევაში, სადაც მეტი რადიქსი და მეტი ფენაა, შეგიძლიათ გააკეთოთ ძალიან დიდი ქსელი, მაგრამ თუ გადახედავთ მოსალოდნელ მოხმარებას, როგორც წესი, არის გიგავატი. შესაძლებელია კაბელის გაყვანა, მაგრამ ნაკლებად სავარაუდოა, რომ ამდენი ელექტროენერგია ერთ ადგილზე მივიღოთ. თუ გადახედავთ სტატისტიკას და მონაცემთა ცენტრების საჯარო მონაცემებს, შეგიძლიათ იპოვოთ ძალიან ცოტა მონაცემთა ცენტრები, რომელთა სავარაუდო სიმძლავრე 150 მეგავატზე მეტია. უფრო დიდი, როგორც წესი, არის მონაცემთა ცენტრის კამპუსები, რამდენიმე დიდი მონაცემთა ცენტრი, რომლებიც მდებარეობს ერთმანეთთან საკმაოდ ახლოს.

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

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

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

ამ სურათიდან გამომდინარე, ნათელია, რომ ჩვენ ნამდვილად გვსურს დავამყაროთ რაღაც გადამრთველები 128-ის რადიქსით.

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

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

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

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

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

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

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

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

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

რა მოუვა ფიზიკას? ძალიან მარტივი გამოთვლები. თუ ჩვენ გვაქვს ორი დონის სპინები, მაშინ ჩვენ გვაქვს მხოლოდ სამი დონის გადამრთველი და ჩვენ ველით, რომ იქნება სამი საკაბელო სეგმენტი ქსელში: სერვერებიდან ფოთლის გადამრთველებამდე, ხერხემლის 1-მდე, ხერხემლის 2-მდე. ვარიანტები, რომლებიც შეგვიძლია გამოყენება არის - ეს არის twinax, multimode, single mode. და აქ ჩვენ უნდა გავითვალისწინოთ, რა ზოლებია ხელმისაწვდომი, რა ეღირება, როგორია ფიზიკური ზომები, რა ფართები შეგვიძლია დავფაროთ და როგორ გავაუმჯობესებთ.

ღირებულების თვალსაზრისით, ყველაფერი შეიძლება დალაგდეს. Twinaxes მნიშვნელოვნად იაფია, ვიდრე აქტიური ოპტიკა, უფრო იაფი ვიდრე მულტიმოდური გადამცემები, თუ მას აიღებთ თითო ფრენაზე ბოლოდან, გარკვეულწილად იაფია, ვიდრე 100 გიგაბიტიანი გადამრთველი პორტი. და, გთხოვთ, გაითვალისწინოთ, რომ ის უფრო იაფი ღირს, ვიდრე ერთი რეჟიმის ოპტიკა, რადგან ფრენებზე, სადაც საჭიროა ერთი რეჟიმი, მონაცემთა ცენტრებში მრავალი მიზეზის გამო აზრი აქვს CWDM-ის გამოყენებას, ხოლო პარალელური ერთჯერადი რეჟიმი (PSM) არ არის ძალიან მოსახერხებელი სამუშაოდ. ძალიან დიდი შეფუთვით მიიღება ბოჭკოები და თუ ამ ტექნოლოგიებზე გავამახვილებთ ყურადღებას, მივიღებთ დაახლოებით შემდეგ ფასების იერარქიას.

კიდევ ერთი შენიშვნა: სამწუხაროდ, არ არის შესაძლებელი დაშლილი 100-დან 4x25 მულტიმოდური პორტების გამოყენება. SFP28 გადამცემების დიზაინის მახასიათებლების გამო, ის არ არის ბევრად იაფი ვიდრე 28 Gbit QSFP100. და მულტიმოდისთვის ეს დაშლა არც ისე კარგად მუშაობს.

კიდევ ერთი შეზღუდვა არის ის, რომ გამოთვლითი კლასტერების ზომისა და სერვერების რაოდენობის გამო, ჩვენი მონაცემთა ცენტრები ფიზიკურად დიდი აღმოჩნდება. ეს ნიშნავს, რომ მინიმუმ ერთი ფრენა უნდა შესრულდეს სინგლიმოდთან ერთად. ისევ და ისევ, Pods-ის ფიზიკური ზომის გამო, შეუძლებელი იქნება twinax-ის (სპილენძის კაბელის) ორი ღერძის გაშვება.

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

ასე გამოიყურება ბოლო დროს, სად მივდივართ და რა არის შესაძლებელი. გასაგებია, ყოველ შემთხვევაში, როგორ გადავიდეთ 50 გიგაბიტიან SerDes-ზე როგორც მულტიმოდისთვის, ასევე ერთმოდისთვის. უფრო მეტიც, თუ გადავხედავთ რა არის ერთრეჟიმიან გადამცემებში ახლა და მომავალში 400 გ-ისთვის, ხშირად მაშინაც კი, როდესაც 50 გ SerDes მოდის ელექტრო მხრიდან, 100 გბიტი/წმ თითო ზოლზე უკვე შეიძლება გადავიდეს ოპტიკაზე. აქედან გამომდინარე, სავსებით შესაძლებელია, რომ 50-ზე გადასვლის ნაცვლად, მოხდეს გადასვლა 100 გიგაბიტი SerDes-ზე და 100 Gbps თითო ზოლზე, რადგან ბევრი მოვაჭრეების დაპირებების მიხედვით, მათი ხელმისაწვდომობა მოსალოდნელია საკმაოდ მალე. პერიოდი, როდესაც 50G SerDes იყო ყველაზე სწრაფი, როგორც ჩანს, არც თუ ისე გრძელი იქნება, რადგან 100G SerDes-ის პირველი ასლები თითქმის მომავალ წელს გამოვა. და ამის შემდეგ გარკვეული პერიოდის შემდეგ ისინი ალბათ გონივრული ფულის ღირსნი იქნებიან.

კიდევ ერთი ნიუანსი ფიზიკის არჩევის შესახებ. პრინციპში, ჩვენ უკვე შეგვიძლია გამოვიყენოთ 400 ან 200 გიგაბიტიანი პორტები 50G SerDes-ის გამოყენებით. მაგრამ გამოდის, რომ ამას დიდი აზრი არ აქვს, რადგან, როგორც ადრე ვთქვი, ჩვენ გვინდა საკმაოდ დიდი რადიქსი კონცენტრატორების, რა თქმა უნდა, გონივრულ ფარგლებში. ჩვენ გვინდა 128. და თუ გვაქვს შეზღუდული ჩიპის ტევადობა და გავზრდით ლინკის სიჩქარეს, მაშინ რადიქსი ბუნებრივად იკლებს, სასწაულები არ არის.

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

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

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

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

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

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

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

არჩევანი არის BGP-ის გამოყენება. როგორ მოვამზადოთ ის სწორად, აღწერილია RFC 7938-ში BGP-ის გამოყენების შესახებ დიდ მონაცემთა ცენტრებში. ძირითადი იდეები მარტივია: პრეფიქსების მინიმალური რაოდენობა ერთ მასპინძელზე და ზოგადად პრეფიქსების მინიმალური რაოდენობა ქსელში, შეძლებისდაგვარად გამოიყენეთ აგრეგაცია და ჩაახშო ბილიკზე ნადირობა. ჩვენ გვინდა ძალიან ფრთხილად, ძალიან კონტროლირებადი გავრცელება განახლებები, რასაც უწოდებენ valley free. ჩვენ გვინდა, რომ განახლებები განთავსდეს ზუსტად ერთხელ, როდესაც ისინი გადის ქსელში. თუ ისინი წარმოიქმნება ბოლოში, ისინი ადიან მაღლა, იშლება არა უმეტეს ერთხელ. არ უნდა იყოს ზიგზაგები. ზიგზაგები ძალიან ცუდია.

ამისათვის ჩვენ ვიყენებთ დიზაინს, რომელიც საკმარისად მარტივია, რათა გამოვიყენოთ ძირითადი BGP მექანიზმები. ანუ, ჩვენ ვიყენებთ eBGP-ს, რომელიც მუშაობს ლოკალურ ბმულზე და ავტონომიური სისტემები ენიჭება შემდეგნაირად: ავტონომიური სისტემა ToR-ზე, ავტონომიური სისტემა ხერხემლის-1 გადამრთველების მთელ ბლოკზე ერთი Pod-ზე და ზოგადი ავტონომიური სისტემა მთელ ტოპზე. ქსოვილის. ძნელი არ არის იმის დანახვა და იმის დანახვა, რომ BGP-ის ნორმალური ქცევაც კი გვაძლევს ჩვენთვის სასურველი განახლებების განაწილებას.

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

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

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

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

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

როგორ გამოიყურება მონაცემთა სიბრტყის მასშტაბირება თანამედროვე მოწყობილობებზე? თუ ჩვენ გავაკეთებთ LPM (ყველაზე გრძელი პრეფიქსის მატჩი), ყველაფერი საკმაოდ კარგია, 100 ათასზე მეტი პრეფიქსი. თუ ვსაუბრობთ Next Hop ჯგუფებზე, მაშინ ყველაფერი უარესია, 2-4 ათასი. თუ ვსაუბრობთ ცხრილზე, რომელიც შეიცავს შემდეგი ჰოპების (ან მიმდებარე ტერიტორიების) აღწერას, მაშინ ეს არის სადღაც 16k-დან 64k-მდე. და ეს შეიძლება გახდეს პრობლემა. და აქ მივედით საინტერესო დიგრესამდე: რა დაემართა MPLS-ს მონაცემთა ცენტრებში? პრინციპში გვინდოდა ამის გაკეთება.

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

ასე გამოიყურება ECMP გადამისამართების სტრუქტურა IP-სთვის. პრეფიქსების დიდ რაოდენობას შეუძლია გამოიყენოს ერთი და იგივე ჯგუფი და იგივე Next Hops ბლოკი (ან მიმდებარედ, ამას შეიძლება სხვაგვარად ეწოდოს სხვადასხვა დოკუმენტაციაში სხვადასხვა მოწყობილობისთვის). საქმე იმაშია, რომ ეს აღწერილია, როგორც გამავალი პორტი და რაზე უნდა გადავიწეროთ MAC მისამართი, რათა მივიდეთ სწორ Next Hop-ზე. IP-სთვის ყველაფერი მარტივად გამოიყურება, შეგიძლიათ გამოიყენოთ პრეფიქსების ძალიან დიდი რაოდენობა იმავე ჯგუფისთვის, იგივე Next Hops ბლოკისთვის.

კლასიკური MPLS არქიტექტურა გულისხმობს, რომ გამავალი ინტერფეისიდან გამომდინარე, ლეიბლი შეიძლება გადაიწეროს სხვადასხვა მნიშვნელობებზე. ამიტომ, ჩვენ უნდა შევინარჩუნოთ ჯგუფი და Next Hops ბლოკი თითოეული შეყვანის ლეიბლისთვის. და ეს, სამწუხაროდ, არ მასშტაბებს.

ადვილი მისახვედრია, რომ ჩვენს დიზაინში დაგვჭირდა დაახლოებით 4000 ToR ჩამრთველი, მაქსიმალური სიგანე იყო 64 ECMP ბილიკი, თუ ჩვენ გადავინაცვლებთ spine-1-დან spine-2-ისკენ. ჩვენ ძლივს ვხვდებით ECMP ჯგუფების ერთ ცხრილში, თუ მხოლოდ ერთი პრეფიქსი გაქრება ToR-ით და ჩვენ საერთოდ არ ვხვდებით Next Hops ცხრილში.

ეს ყველაფერი უიმედო არ არის, რადგან არქიტექტურები, როგორიცაა Segment Routing, მოიცავს გლობალურ ეტიკეტებს. ფორმალურად, შესაძლებელი იქნება ყველა ამ Next Hops ბლოკის ხელახლა ჩამოშლა. ამისათვის თქვენ გჭირდებათ wild card ტიპის ოპერაცია: აიღეთ ეტიკეტი და გადაწერეთ იგი იმავეზე კონკრეტული მნიშვნელობის გარეშე. მაგრამ, სამწუხაროდ, ეს არც თუ ისე წარმოდგენილია არსებულ განხორციელებებში.

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

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

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

განვითარების რა შესაძლებლობებს ვხედავთ? უპირველეს ყოვლისა, CI/CD მილსადენის მხარდაჭერის გაუმჯობესება. ჩვენ გვინდა ვიფრინოთ ისე, როგორც ჩვენ ვცდით და გამოვცადოთ როგორ ვფრინავთ. ეს არც ისე კარგად გამომდის, რადგან ინფრასტრუქტურა დიდია და ტესტებისთვის მისი დუბლირება შეუძლებელია. თქვენ უნდა გესმოდეთ, თუ როგორ უნდა შემოიტანოთ ტესტირების ელემენტები წარმოების ინფრასტრუქტურაში მისი ჩამოგდების გარეშე.

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

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

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

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

წყარო: www.habr.com