ერთი ღრუბელი - მონაცემთა ცენტრის დონის OS ოდნოკლასნიკში

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

რა გამოვიდა?

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

მომხმარებლის მოთხოვნები მიიღება როგორც მთავარი პორტალის ფრონტზე www.ok.ruდა სხვებზე, მაგალითად მუსიკის API ფრონტებზე. ბიზნეს ლოგიკის დასამუშავებლად ურეკავენ აპლიკაციის სერვერს, რომელიც მოთხოვნის დამუშავებისას იძახებს საჭირო სპეციალიზებულ მიკროსერვისებს - ერთ გრაფიკს (სოციალური კავშირების გრაფიკი), მომხმარებლის ქეში (მომხმარებლის პროფილების ქეში) და ა.შ.

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

Რატომ არის, რომ? ამ მიდგომას რამდენიმე უპირატესობა ჰქონდა:

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

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

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

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

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

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

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

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

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

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

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

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

კონტეინერების ხელით განაწილება არ არის ვარიანტი, როდესაც გაქვთ 8 ათასი სერვერი და 8-16 ათასი კონტეინერი.

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

ცხადია, ჩვენ გვჭირდება საკონტროლო ფენა, რომელიც ამას ავტომატურად გააკეთებს.

ასე რომ, ჩვენ მივედით მარტივ და გასაგებ სურათამდე, რომელსაც ყველა არქიტექტორი უყვარს: სამი კვადრატი.

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

რესურსების განაწილება

ახლა მოდით შევხედოთ ბევრი მინიონების უფრო რთული რესურსების განაწილების პრობლემას.

გამოთვლითი რესურსი ერთ ღრუბელში არის:

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

შემდეგ ზოგიერთი სერვისისთვის, მაგალითად მომხმარებლის ქეშისთვის, ჩვენ შეგვიძლია ჩავწეროთ მოხმარებული რესურსები ამ გზით: 400 პროცესორის ბირთვი, 2,5 ტბ მეხსიერება, 50 გბიტ/წმ მოძრაობა ორივე მიმართულებით, 6 ტბ HDD სივრცე განთავსებული 100 spindles-ზე. ან უფრო ნაცნობი ფორმით, როგორიცაა:

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

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

მოდით დავუბრუნდეთ კომპონენტების ურთიერთქმედების ჩვენს ძალიან გამარტივებულ დიაგრამას და გადავახაზოთ იგი უფრო დეტალურად - ასე:

რა გიპყრობს თვალს:

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

მოდი ისევ გადავხატოთ სურათი:

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

დამატებითი ხაზების ამოღებით, ჩვენ შეგვიძლია დავწეროთ ჩვენი სურათის თითოეული კვანძი უფრო ბრტყელი ფორმით: group1.web.front, api.music.front, user-cache.cache.

ასე მივდივართ „იერარქიული რიგის“ კონცეფციამდე. მას აქვს სახელი, როგორიცაა "group1.web.front". მას ენიჭება რესურსებისა და მომხმარებლის უფლებების კვოტა. ჩვენ მივცემთ DevOps-ის პირს უფლებას გამოაგზავნოს სერვისი რიგში, და ასეთ თანამშრომელს შეუძლია რაღაც გაუშვას რიგში, ხოლო OpsDev-ის პირს ექნება ადმინისტრატორის უფლებები და ახლა მას შეუძლია მართოს რიგი, დანიშნოს ხალხი იქ, მიეცით ამ ადამიანებს უფლებები და ა.შ. ამ რიგში გაშვებული სერვისები იმუშავებს რიგის კვოტის ფარგლებში. თუ რიგის გამოთვლითი კვოტა საკმარისი არ არის ყველა სერვისის ერთდროულად შესასრულებლად, მაშინ ისინი შესრულდება თანმიმდევრობით, რითაც იქმნება რიგი თავად.

მოდით, უფრო ახლოს მივხედოთ სერვისებს. სერვისს აქვს სრულად კვალიფიციური სახელი, რომელიც ყოველთვის შეიცავს რიგის სახელს. შემდეგ წინა ვებ სერვისს ექნება სახელი ok-web.group1.web.front. და გამოიძახება აპლიკაციის სერვერის სერვისი, რომელსაც მას აქვს წვდომა ok-app.group1.web.front. თითოეულ სერვისს აქვს მანიფესტი, რომელიც განსაზღვრავს ყველა საჭირო ინფორმაციას კონკრეტულ მანქანებზე განთავსებისთვის: რამდენ რესურსს მოიხმარს ეს ამოცანა, რა კონფიგურაციაა საჭირო მისთვის, რამდენი ასლი უნდა იყოს, თვისებები ამ სერვისის წარუმატებლობის მოსაგვარებლად. და მას შემდეგ, რაც სერვისი პირდაპირ მანქანებზე განთავსდება, ჩნდება მისი ინსტანციები. ისინი ასევე დასახელებულია ცალსახად - როგორც ინსტანციის ნომერი და სერვისის სახელი: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front,…

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

ახლა მოდით უფრო ახლოს მივხედოთ რას ასრულებენ ეს შემთხვევები სინამდვილეში: ამოცანები.

დავალების იზოლაციის კლასები

ყველა დავალება OK-ში (და, ალბათ, ყველგან) შეიძლება დაიყოს ჯგუფებად:

• მოკლე ლატენტური ამოცანები - პროდ. ასეთი ამოცანებისა და სერვისებისთვის პასუხის დაყოვნება (დაყოვნება) ძალიან მნიშვნელოვანია, რამდენად სწრაფად დამუშავდება თითოეული მოთხოვნა სისტემის მიერ. ამოცანების მაგალითები: ვებ ფრონტები, ქეშები, აპლიკაციის სერვერები, OLTP საცავი და ა.შ.
• გაანგარიშების პრობლემები - პარტიული. აქ, თითოეული კონკრეტული მოთხოვნის დამუშავების სიჩქარე არ არის მნიშვნელოვანი. მათთვის მნიშვნელოვანია რამდენ გამოთვლას გააკეთებს ეს ამოცანა დროის გარკვეულ (ხანგრძლივ) პერიოდში (გამტარუნარიანობა). ეს იქნება MapReduce-ის, Hadoop-ის, მანქანათმცოდნეობის, სტატისტიკის ნებისმიერი დავალება.
• ფონის ამოცანები - უმოქმედო. ასეთი ამოცანებისთვის არც შეყოვნება და არც გამტარუნარიანობა არ არის ძალიან მნიშვნელოვანი. ეს მოიცავს სხვადასხვა ტესტებს, მიგრაციას, ხელახალი გამოთვლებს და მონაცემთა ერთი ფორმატიდან მეორეში გადაქცევას. ერთის მხრივ, ისინი ჰგავს გაანგარიშებულებს, მეორე მხრივ, ჩვენთვის არ აქვს მნიშვნელობა რამდენად სწრაფად სრულდება ისინი.

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

მოკლე დაგვიანებით ამოცანები. ასეთ ამოცანას ექნება CPU მოხმარების ნიმუში მსგავსი:

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

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

alloc: cpu = 4 (max)

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

გაანგარიშების ამოცანები. მათი ნიმუში ოდნავ განსხვავებული იქნება:

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

alloc: cpu = [1,*)

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

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

მაგრამ როგორ უნდა გავაკეთოთ ეს?

პირველ რიგში, მოდით შევხედოთ prod-ს და მის გამოყოფას: cpu = 4. ჩვენ უნდა დავტოვოთ ოთხი ბირთვი. Docker run-ში ეს შეიძლება გაკეთდეს ორი გზით:

• ვარიანტის გამოყენება --cpuset=1-4, ანუ გამოყოს ოთხი კონკრეტული ბირთვი მანქანაზე დავალებაზე.
• გამოიყენეთ --cpuquota=400_000 --cpuperiod=100_000, მიანიჭეთ კვოტა პროცესორის დროს, ანუ მიუთითეთ, რომ ყოველ 100 ms რეალურ დროში ამოცანა მოიხმარს არაუმეტეს 400 ms პროცესორის დროს. მიიღება იგივე ოთხი ბირთვი.

მაგრამ ამ მეთოდებიდან რომელია შესაფერისი?

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

მოდით გაერკვნენ, თუ როგორ უნდა გააკეთოთ დაჯავშნა Docker-ში ბირთვების მინიმალური რაოდენობის მიხედვით. პარტიული ამოცანების კვოტა აღარ გამოიყენება, რადგან არ არის საჭირო მაქსიმუმის შეზღუდვა, საკმარისია მხოლოდ მინიმუმის გარანტია. და აქ ვარიანტი კარგად ჯდება docker run --cpushares.

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

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

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

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

მაგრამ მაშინაც კი, თუ არ დაპროგრამებთ Java-ში, იგივე შეიძლება გაკეთდეს chrt ბრძანების გამოყენებით:

chrt -i 0 $pid

მოდით შევაჯამოთ ჩვენი იზოლაციის ყველა დონე ერთ ცხრილში სიცხადისთვის:

საიზოლაციო კლასი
მაგალითის გამოყოფა
დოკერის გაშვების პარამეტრები
sched_setscheduler chrt*

გამოშვების
CPU = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

სურათების
Cpu = [1, *)
--cpushares=1024
SCHED_BATCH

Idle
CPU = [2, *)
--cpushares=2048
SCHED_IDLE

*თუ თქვენ აკეთებთ chrt-ს კონტეინერის შიგნიდან, შეიძლება დაგჭირდეთ sys_nice ფუნქცია, რადგან ნაგულისხმევად Docker ხსნის ამ შესაძლებლობას კონტეინერის გაშვებისას.

მაგრამ ამოცანები მოიხმარს არა მხოლოდ პროცესორს, არამედ ტრაფიკს, რაც გავლენას ახდენს ქსელური ამოცანის შეყოვნებაზე, ვიდრე პროცესორის რესურსების არასწორად განაწილება. ამიტომ, ბუნებრივია, გვინდა ზუსტად იგივე სურათი მივიღოთ ტრაფიკისთვის. ანუ, როდესაც პროდ ამოცანა აგზავნის რამდენიმე პაკეტს ქსელში, ჩვენ ვზღუდავთ მაქსიმალურ სიჩქარეს (ფორმულა განაწილება: lan=[*,500mbps) ), რომლითაც პროდს შეუძლია ამის გაკეთება. ხოლო პარტიისთვის ჩვენ გარანტიას ვაძლევთ მხოლოდ მინიმალურ გამტარუნარიანობას, მაგრამ არ ვზღუდავთ მაქსიმუმს (ფორმულა განაწილება: LAN=[10 Mbps,*) ) ამ შემთხვევაში, პროდუქტის ტრაფიკს უნდა ჰქონდეს პრიორიტეტი ჯგუფური ამოცანების მიმართ.
აქ დოკერს არ აქვს რაიმე პრიმიტივი, რომელიც შეგვიძლია გამოვიყენოთ. მაგრამ ეს ჩვენს დასახმარებლად მოდის Linux ტრაფიკის კონტროლი. ჩვენ შევძელით სასურველი შედეგის მიღწევა დისციპლინის დახმარებით იერარქიული სამართლიანი მომსახურების მრუდი. მისი დახმარებით გამოვყოფთ ტრაფიკის ორ კლასს: მაღალი პრიორიტეტის პროდუქტს და დაბალი პრიორიტეტის პარტიას/უსაქმურს. შედეგად, გამავალი ტრაფიკის კონფიგურაცია ასეთია:

აქ 1:0 არის hsfc დისციპლინის „root qdisc“; 1:1 - hsfc ბავშვის კლასი 8 გბიტ/წმ სიჩქარის ჯამური ლიმიტით, რომლის ქვეშ მოთავსებულია ყველა კონტეინერის საბავშვო კლასები; 1:2 - hsfc საბავშვო კლასი საერთოა ყველა ჯგუფური და უმოქმედო ამოცანისთვის „დინამიური“ ლიმიტით, რაც ქვემოთ იქნება განხილული. დარჩენილი hsfc ბავშვების კლასები არის გამოყოფილი კლასები ამჟამად გაშვებული პროდუქციის კონტეინერებისთვის მათი მანიფესტების შესაბამისი ლიმიტებით - 450 და 400 მბიტ/წმ. თითოეულ hsfc კლასს ენიჭება qdisc queue fq ან fq_codel, Linux-ის ბირთვის ვერსიის მიხედვით, რათა თავიდან იქნას აცილებული პაკეტების დაკარგვა ტრაფიკის ადიდების დროს.

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

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

ზოლები განისაზღვრება დამოუკიდებლად შემომავალი და გამავალი ტრაფიკისთვის. და ახალი მნიშვნელობების მიხედვით, miniond ხელახლა აკონფიგურირებს არაპრიორიტეტული კლასის ლიმიტს 1:2.

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

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

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

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

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

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

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

გარდა ამისა, ჩვენ ჯერჯერობით მხოლოდ TCP ტრაფიკის პრიორიტეტიზაციის პრობლემის მოგვარება მოვახერხეთ: hsfc მიდგომა არ მუშაობს UDP-სთვის. და TCP ტრაფიკის შემთხვევაშიც კი, თუ ჯგუფური დავალება წარმოქმნის უამრავ ტრაფიკს, ეს ასევე იძლევა დაახლოებით 10%-ით გაზრდის დაყოვნებას prod დავალების დროს.

შეცდომის ტოლერანტობა

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

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

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

რა შეგიძლიათ გააკეთოთ, თუ მთელი მინიონი მიუწვდომელია?

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

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

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

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

ერთ ღრუბელში, IP მიჰყვება კონტეინერს, ანუ თითოეული დავალების ინსტანციას აქვს საკუთარი IP მისამართი. ეს მისამართი არის „სტატიკური“: ის ენიჭება თითოეულ შემთხვევას, როდესაც სერვისი პირველად იგზავნება ღრუბელში. თუ სერვისს ჰქონდა სხვადასხვა რაოდენობის ინსტანცია თავისი ცხოვრების განმავლობაში, მაშინ საბოლოოდ მას მიენიჭება იმდენი IP მისამართი, რამდენიც იყო მაქსიმალური ინსტანცია.

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

ამრიგად, სერვისის სახელის დახატვა მის IP მისამართების სიაში ძალიან იშვიათად იცვლება. თუ კიდევ ერთხელ გადახედავთ იმ სერვისების სახელებს, რომლებიც სტატიის დასაწყისში ვახსენეთ (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod,…), ჩვენ შევამჩნევთ, რომ ისინი წააგავს DNS-ში გამოყენებულ FQDN-ებს. ეს მართალია, სერვისის ინსტანციების სახელების მისამართებზე მისამართებლად, ჩვენ ვიყენებთ DNS პროტოკოლს. უფრო მეტიც, ეს DNS აბრუნებს ყველა კონტეინერის ყველა რეზერვირებულ IP მისამართს - როგორც გაშვებული, ასევე გაჩერებული (ვთქვათ, რომ გამოყენებულია სამი რეპლიკა და ჩვენ გვაქვს ხუთი მისამართი დაცულია იქ - ხუთივე დაბრუნდება). კლიენტები, რომლებმაც მიიღეს ეს ინფორმაცია, შეეცდებიან დაამყარონ კავშირი ხუთივე რეპლიკასთან - და ამით დაადგინონ ის, ვინც მუშაობს. ხელმისაწვდომობის განსაზღვრის ეს ვარიანტი ბევრად უფრო საიმედოა; ის არ მოიცავს არც DNS-ს და არც სერვისის აღმოჩენას, რაც ნიშნავს, რომ არ არის რთული გადასაჭრელი პრობლემები ამ სისტემების ინფორმაციის შესაბამისობისა და შეცდომების ტოლერანტობის უზრუნველსაყოფად. უფრო მეტიც, კრიტიკულ სერვისებში, რომლებზეც დამოკიდებულია მთელი პორტალის ფუნქციონირება, ჩვენ საერთოდ არ შეგვიძლია გამოვიყენოთ DNS, არამედ უბრალოდ შევიტანოთ IP მისამართები კონფიგურაციაში.

ასეთი IP გადაცემის განხორციელება კონტეინერების უკან შეიძლება იყოს არა ტრივიალური - და ჩვენ შევხედავთ, თუ როგორ მუშაობს იგი შემდეგი მაგალითით:

ვთქვათ, ერთი ღრუბლის მასტერი აძლევს ბრძანებას minion M1-ს, რომ გაუშვას 1.ok-web.group1.web.front.prod მისამართით 1.1.1.1. მუშაობს მინიონზე BIRD, რომელიც ამ მისამართს რეკლამირებს სპეციალურ სერვერებზე მარშრუტის რეფლექტორი. ამ უკანასკნელებს აქვთ BGP სესია ქსელის აპარატურასთან, რომელშიც ითარგმნება 1.1.1.1 მისამართის მარშრუტი M1-ზე. M1 მარშრუტებს პაკეტებს კონტეინერის შიგნით Linux-ის გამოყენებით. არსებობს სამი მარშრუტის რეფლექტორი სერვერი, რადგან ეს არის ერთ ღრუბლიანი ინფრასტრუქტურის ძალიან მნიშვნელოვანი ნაწილი - მათ გარეშე, ქსელი ერთ ღრუბელში არ იმუშავებს. ჩვენ ვათავსებთ მათ სხვადასხვა თაროებში, თუ შესაძლებელია განლაგებულია მონაცემთა ცენტრის სხვადასხვა ოთახში, რათა შევამციროთ სამივე მარცხის ალბათობა ერთდროულად.

ახლა დავუშვათ, რომ კავშირი ერთ ღრუბლიან ოსტატსა და M1 მინიონს შორის დაკარგულია. ერთი ღრუბლის ოსტატი ახლა იმოქმედებს იმ ვარაუდით, რომ M1 მთლიანად ჩავარდა. ანუ ის მისცემს ბრძანებას M2 minion-ს გაშვებისთვის web.group1.web.front.prod ამავე მისამართით 1.1.1.1. ახლა ჩვენ გვაქვს ორი კონფლიქტური მარშრუტი ქსელში 1.1.1.1: M1-ზე და M2-ზე. ასეთი კონფლიქტების გადასაჭრელად ვიყენებთ Multi Exit Discriminator-ს, რომელიც მითითებულია BGP განცხადებაში. ეს არის რიცხვი, რომელიც აჩვენებს რეკლამირებული მარშრუტის წონას. კონფლიქტურ მარშრუტებს შორის შეირჩევა მარშრუტი ქვედა MED მნიშვნელობით. ერთი ღრუბლოვანი მასტერი მხარს უჭერს MED-ს, როგორც კონტეინერის IP მისამართების განუყოფელ ნაწილს. პირველად მისამართი იწერება საკმარისად დიდი MED = 1. ასეთი გადაუდებელი კონტეინერის გადაცემის შემთხვევაში, ოსტატი ამცირებს MED-ს და M000 უკვე მიიღებს ბრძანებას 000 მისამართის რეკლამირების შესახებ MED =-ით. 2. M1.1.1.1-ზე გაშვებული ინსტანცია დარჩება ამ შემთხვევაში კავშირი არ არის და მისი შემდგომი ბედი ნაკლებად გვაინტერესებს მანამ, სანამ მასტერთან კავშირი არ აღდგება, როცა ის ძველებურად შეჩერდება.

უბედური შემთხვევები

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

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

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

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

რა შეგიძლიათ გააკეთოთ ამ ყველაფერთან დაკავშირებით?

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

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

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

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

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

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

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

მთელი DC ავარიები

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

და ეს არის ის, რასაც ჩვენ ვაკეთებთ იმისათვის, რომ ვინმემ არ დაწეროს #ცოცხალი.

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

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

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

შედეგები

ერთი ღრუბლის გამორჩეული თვისებები:

• სერვისებისა და კონტეინერების იერარქიული და ვიზუალური დასახელების სქემა, რომელიც საშუალებას გაძლევთ ძალიან სწრაფად გაარკვიოთ რა არის ამოცანა, რას უკავშირდება და როგორ მუშაობს და ვინ არის პასუხისმგებელი მასზე.
• ჩვენ ვიყენებთ ჩვენს პროდუქტის და სერიის შერწყმის ტექნიკაამოცანები მინიონებზე მანქანების გაზიარების ეფექტურობის გასაუმჯობესებლად. Cpuset-ის ნაცვლად, ჩვენ ვიყენებთ CPU-ს კვოტას, აქციებს, CPU განრიგის პოლიტიკას და Linux QoS-ს.
• შეუძლებელი იყო იმავე მანქანაზე მომუშავე კონტეინერების სრული იზოლირება, მაგრამ მათი ურთიერთგავლენა 20%-ის ფარგლებში რჩება.
• სერვისების იერარქიაში ორგანიზება ხელს უწყობს კატასტროფის ავტომატური აღდგენის გამოყენებას განლაგებისა და პრევენციის პრიორიტეტები.

FAQ

რატომ არ მივიღეთ მზა ხსნარი?

• დავალების იზოლაციის სხვადასხვა კლასი მოითხოვს განსხვავებულ ლოგიკას მინონებზე მოთავსებისას. თუ პროდ ამოცანების განთავსება შესაძლებელია რესურსების უბრალოდ დაჯავშნით, მაშინ უნდა განთავსდეს ჯგუფური და უმოქმედო ამოცანები, რათა თვალყური ადევნოთ რესურსების რეალურ გამოყენებას მინიონის მანქანებზე.
• ამოცანების მიერ მოხმარებული რესურსების გათვალისწინების აუცილებლობა, როგორიცაა:
  • ქსელის გამტარუნარიანობა;
  • დისკების ტიპები და "spindles".
• საგანგებო სიტუაციებზე რეაგირების დროს სერვისების პრიორიტეტების მითითების აუცილებლობა, რესურსების ბრძანებების უფლებები და კვოტები, რაც წყდება ერთ ღრუბელში იერარქიული რიგების გამოყენებით.
• კონტეინერების ადამიანური დასახელების აუცილებლობა ავარიებსა და ინციდენტებზე რეაგირების დროის შესამცირებლად
• Service Discovery-ის ერთჯერადი ფართოდ განხორციელების შეუძლებლობა; დიდი ხნის განმავლობაში თანაარსებობის აუცილებლობა დავალებებს, რომლებიც მასპინძლობს აპარატურულ ჰოსტებზე - ის, რაც წყდება კონტეინერების შემდეგ "სტატიკური" IP მისამართებით და, შედეგად, უნიკალური ინტეგრაციის საჭიროება დიდ ქსელურ ინფრასტრუქტურასთან.

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

მათ, ვინც კითხულობს ბოლო სტრიქონებს, მადლობას გიხდით მოთმინებისთვის და ყურადღებისთვის!

წყარო: www.habr.com