Load Balancing Openstack-ში (ნაწილი 2)

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

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

ზოგიერთი ტერმინოლოგია

კომპანია VmWare-მა შემოიტანა DRS (Distributed Resource Scheduler) პროგრამა, რათა დააბალანსოს მათ მიერ შემუშავებული და შემოთავაზებული ვირტუალიზაციის გარემოს დატვირთვა.

მიხედვით searchvmware.techtarget.com/definition/VMware-DRS
„VMware DRS (Distributed Resource Scheduler) არის პროგრამა, რომელიც აბალანსებს გამოთვლით დატვირთვას არსებულ რესურსებთან ვირტუალურ გარემოში. პროგრამა არის ვირტუალიზაციის კომპლექტის ნაწილი, სახელწოდებით VMware Infrastructure.

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

რატომ არის საჭირო დაბალანსება?

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

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

პირადი ღრუბლები / დიდი საწარმოს კლიენტები
საჯარო ღრუბლები / საშუალო და მცირე ბიზნესი, ხალხი

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

მომსახურების მოთხოვნები
საიმედოობა ყველა დონეზე და სისტემის ყველა ელემენტში

გარანტირებული შესრულება

ვირტუალური მანქანების პრიორიტეტი რამდენიმე კატეგორიად 

ინფორმაციისა და ფიზიკური მონაცემების უსაფრთხოება

SLA და XNUMX/XNUMX მხარდაჭერა
სერვისის მიღების მაქსიმალური სიმარტივე

შედარებით მარტივი მომსახურება

ინფორმაციაზე პასუხისმგებლობა ეკისრება კლიენტს

VM პრიორიტეტიზაცია არ არის საჭირო

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

შეიძლება იყოს ხარვეზები

არა SLA, ხარისხი არ არის გარანტირებული

ელ.ფოსტის მხარდაჭერა

სარეზერვო არ არის საჭირო

კლიენტის მახასიათებლები
აპლიკაციების ძალიან ფართო სპექტრი.

კომპანიაში მემკვიდრეობით მიღებული აპლიკაციები.

კომპლექსური საბაჟო არქიტექტურები თითოეული კლიენტისთვის.

ნათესაობის წესები.

პროგრამა მუშაობს 7x24 რეჟიმში გაჩერების გარეშე. 

ფრენის სარეზერვო ინსტრუმენტები.

პროგნოზირებადი ციკლური მომხმარებლის დატვირთვა.
ტიპიური აპლიკაციები – ქსელის დაბალანსება, Apache, WEB, VPN, SQL

განაცხადი შეიძლება შეჩერდეს გარკვეული ხნით

საშუალებას აძლევს VM-ების თვითნებურ განაწილებას ღრუბელში

კლიენტის სარეზერვო

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

გავლენა არქიტექტურაზე
გეოკლასტერირება

ცენტრალიზებული ან განაწილებული საცავი

დაცულია IBS
ლოკალური მონაცემების შენახვა გამოთვლით კვანძებზე

მიზნების დაბალანსება
დატვირთვის თანაბარი განაწილება

განაცხადის მაქსიმალური რეაგირება 

დაბალანსების შეფერხების მინიმალური დრო

დაბალანსება მხოლოდ მაშინ, როცა აშკარად საჭიროა

გარკვეული აღჭურვილობის გამოტანა პრევენციული მოვლისთვის
მომსახურების და ოპერატორის ხარჯების შემცირება 

ზოგიერთი რესურსის გამორთვა დაბალი დატვირთვის შემთხვევაში

Ენერგიის დაზოგვა

პერსონალის ხარჯების შემცირება

ჩვენ თვითონ ვაკეთებთ შემდეგ დასკვნებს:

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

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

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

• ინფორმაციული უსაფრთხოების შეზღუდვებისა და ნათესაობის წესების არარსებობა;
• ღრუბლის შიგნით დაბალანსება;
• დაბალანსება ნებისმიერ გონივრულ დროს;
• ნებისმიერი VM-ის დაბალანსება;
• "ხმაურიანი" ვირტუალური მანქანების დაბალანსება (ისე, რომ არ შეაწუხოთ სხვები);
• ვირტუალური მანქანის მონაცემები ხშირად მდებარეობს ადგილობრივ დისკებზე;
• შენახვის სისტემებისა და ქსელების საშუალო შესრულების გათვალისწინებით (ღრუბლოვანი არქიტექტურა ერთიანია);
• დაბალანსება ზოგადი წესებისა და მონაცემთა ცენტრის ქცევის სტატისტიკის მიხედვით.

პრობლემის სირთულე

დაბალანსების სირთულე ის არის, რომ DRS უნდა მუშაობდეს გაურკვეველი ფაქტორების დიდ რაოდენობასთან:

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

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

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

ჩვენი განვითარების ისტორია

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

სცენა 1

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

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

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

ამავდროულად, საკმაოდ სერიოზული შეზღუდვები გვქონდა:

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

სცენა 2

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

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

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

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

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

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

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

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

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

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

სცენა 3

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

1. სტატისტიკა, მაგალითად, აქ и აქ გვიჩვენებს, რომ ორი და ოთხპროცესორიანი სისტემები მნიშვნელოვნად დაბალია შესრულებაში, ვიდრე ერთპროცესორიანი სისტემები. ეს ნიშნავს, რომ ყველა მომხმარებელი იღებს მნიშვნელოვნად ნაკლებ გამომავალს CPU, RAM, SSD, LAN, FC-დან, რომლებიც შეძენილია მრავალპროცესორულ სისტემებში, ერთპროცესორულ სისტემებთან შედარებით.
2. თავად რესურსების დაგეგმარებს შეიძლება ჰქონდეთ სერიოზული შეცდომები, აქ არის ერთ-ერთი სტატია ამ თემაზე.
3. Intel-ისა და AMD-ის მიერ შემოთავაზებული ტექნოლოგიები RAM-ისა და ქეშის მონიტორინგისთვის შესაძლებელს ხდის ვირტუალური მანქანების ქცევის შესწავლას და მათ განთავსებას ისე, რომ "ხმაურიანი" მეზობლები არ ჩაერიონ "მშვიდ" ვირტუალურ მანქანებში.
4. პარამეტრების ნაკრების გაფართოება (ქსელი, შენახვის სისტემა, ვირტუალური მანქანის პრიორიტეტი, მიგრაციის ღირებულება, მისი მზადყოფნა მიგრაციისთვის).

საერთო ჯამში

დაბალანსების ალგორითმების გაუმჯობესებაზე ჩვენი მუშაობის შედეგი იყო ნათელი დასკვნა, რომ თანამედროვე ალგორითმების გამოყენებით შესაძლებელია მონაცემთა ცენტრის რესურსების მნიშვნელოვანი ოპტიმიზაცია (25-30%) და ამავდროულად გააუმჯობესოს მომხმარებელთა მომსახურების ხარისხი.

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

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

წყარო: www.habr.com