შესავალი

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

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

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

კლასტერები განლაგებულია ვირტუალურ მანქანებზე VirtualBox. განლაგდება სულ 12 ვირტუალური მანქანა (სულ 36 გიბაიტი), რომლებიც ქმნიან 4 შეცდომის ტოლერანტ კლასტერს (სხვადასხვა ვარიანტები). პირველი ორი კლასტერი შედგება ორი PostgreSQL სერვერისგან, რომლებიც განლაგებულია სხვადასხვა მონაცემთა ცენტრში და საერთო სერვერისგან. მოწმენი c კვორუმის მოწყობილობა (მასპინძლობს იაფ ვირტუალურ მანქანაზე მესამე მონაცემთა ცენტრში), რომელიც აგვარებს გაურკვევლობას 50% / 50%თქვენს ხმას ერთ-ერთ მხარეს აძლევთ. მესამე კლასტერი სამ მონაცემთა ცენტრში: ერთი ოსტატი, ორი მონა, არა კვორუმის მოწყობილობა. მეოთხე კლასტერი შედგება ოთხი PostgreSQL სერვერისგან, ორი თითო მონაცემთა ცენტრში: ერთი მასტერი, დანარჩენი რეპლიკა და ასევე იყენებს მოწმენი c კვორუმის მოწყობილობა. მეოთხეს შეუძლია გაუძლოს ორი სერვერის ან ერთი მონაცემთა ცენტრის წარუმატებლობას. საჭიროების შემთხვევაში, ეს გამოსავალი შეიძლება გაიზარდოს ასლების დიდ რაოდენობაზე.

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

ვერსიები

v0. მუშაობს CentOS 7-თან და PostgreSQL 11-თან VirtualBox 6.1-ზე.

კასეტური სტრუქტურა

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

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

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

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

Tuchanka1 (ჩართვა დატკეპნით)

სტრუქტურა

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

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

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

მოწმის წარუმატებლობა

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

თუჩანკა1 უარი

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

თუჩანკა2 (კლასიკური)

სტრუქტურა

ორი კვანძის კლასიკური სქემა. ერთზე ბატონი მუშაობს, მეორეზე მონა. ორივეს შეუძლია შეასრულოს მოთხოვნები (მონა იკითხება მხოლოდ), ამიტომ ორივეზე მითითებულია float IP-ით: krogan2 არის მთავარი, krogan2s1 არის მონა. ბატონსაც და მონასაც ექნება შეცდომის შემწყნარებლობა.

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

თუჩანკა2 უარი

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

თუჩანკა4 (ბევრი მონა)

სტრუქტურა

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

ამ სქემის კიდევ ერთი მახასიათებელია ის, რომ უკვე შესაძლებელია ერთი სინქრონული რეპლიკაციის ორგანიზება. ის კონფიგურირებულია იმისთვის, რომ განმეორდეს, თუ ეს შესაძლებელია, სხვა მონაცემთა ცენტრში, ვიდრე ასლისთვის იმავე მონაცემთა ცენტრში, როგორც მასტერი. მასტერსა და თითოეულ მონაზე მითითებულია float IP-ით. საბედნიეროდ, მონებს შორის საჭირო იქნება მოთხოვნების როგორმე დაბალანსება sql პროქსიმაგალითად, კლიენტის მხარეს. სხვადასხვა ტიპის კლიენტებს შეიძლება დასჭირდეთ სხვადასხვა ტიპები sql პროქსიდა მხოლოდ კლიენტის დეველოპერებმა იციან ვის რა სჭირდება. ეს ფუნქცია შეიძლება განხორციელდეს როგორც გარე დემონით, ასევე კლიენტის ბიბლიოთეკით (დაკავშირების აუზი) და ა.შ. ეს ყველაფერი სცილდება მონაცემთა ბაზის კლასტერის (failover) თემას SQL პროქსი შეიძლება განხორციელდეს დამოუკიდებლად, კლიენტის შეცდომის ტოლერანტობასთან ერთად).

თუჩანკა4 უარი

თუ ერთი მონაცემთა ცენტრი (ანუ ორი სერვერი) ვერ ხერხდება, მოწმე ხმას აძლევს მეორეს. შედეგად, მეორე მონაცემთა ცენტრში მუშაობს ორი სერვერი: ერთი გაშვებულია master-ზე და მასტერზე float IP მიუთითებს (წაკითხვა-ჩაწერის მოთხოვნების მისაღებად); ხოლო მეორე სერვერზე არის slave გაშვებული სინქრონული რეპლიკაციით და ერთ-ერთი slave float IP მიუთითებს მასზე (მხოლოდ წაკითხვის მოთხოვნისთვის).

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

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

Tuchanka3 (3 მონაცემთა ცენტრი)

სტრუქტურა

ეს არის კლასტერი იმ სიტუაციისთვის, სადაც არის სამი სრულად მოქმედი მონაცემთა ცენტრი, რომელთაგან თითოეულს აქვს სრულად მოქმედი მონაცემთა ბაზის სერვერი. Ამ შემთხვევაში კვორუმის მოწყობილობა არაა საჭირო. ერთი მონაცემთა ცენტრი დაკომპლექტებულია ოსტატით, დანარჩენი ორი დაკომპლექტებულია სლავებით. რეპლიკაცია სინქრონულია, ტიპი ANY (slave1, slave2), ანუ კლიენტი მიიღებს დადასტურებას, როდესაც რომელიმე სლავი პირველი უპასუხებს, რომ მან მიიღო ვალდებულება. რესურსები მითითებულია ერთი float IP-ით ოსტატისთვის და ორი სლავებისთვის. Tuchanka4-ისგან განსხვავებით, სამივე float IP არის შეცდომის ტოლერანტული. მხოლოდ წაკითხვადი SQL მოთხოვნების დასაბალანსებლად შეგიძლიათ გამოიყენოთ sql პროქსი (ცალკე შეცდომის შემწყნარებლობით), ან მიანიჭეთ ერთი slave float IP კლიენტების ნახევარს, ხოლო მეორე ნახევარს მეორეს.

თუჩანკა3 უარი

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

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

ავტომატური ტესტირების სისტემა

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

test/failure 2 3

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

ტერმინალი იყოფა სვეტებად შესამოწმებელი კლასტერების რაოდენობის მიხედვით; ნაგულისხმევად (სკრინშოტში) არის ოთხი. სვეტების შინაარსს თუჩანკას2 მაგალითით აღვწერ. ეკრანის სურათზე პანელები დანომრილია:

1. ტესტის სტატისტიკა ნაჩვენებია აქ. Სვეტები:
   • მარცხი - ტესტის დასახელება (ფუნქცია სკრიპტში), რომელიც ასახავს შეცდომას.
   • რეაქცია — საშუალო არითმეტიკული დრო წამებში, რომლის დროსაც კლასტერმა აღადგინა ფუნქციონირება. იგი იზომება სკრიპტის დაწყებიდან შეცდომის ემულაციამდე იმ მომენტამდე, როდესაც კლასტერი აღადგენს თავის ფუნქციონირებას და შეძლებს სერვისების მიწოდების გაგრძელებას. თუ დრო ძალიან მოკლეა, მაგალითად, ექვსი წამი (ეს ხდება კლასტერებში რამდენიმე სლავით (Tuchanka3 და Tuchanka4)), ეს ნიშნავს, რომ ხარვეზი იყო ასინქრონულ მონაზე და არანაირად არ იმოქმედა შესრულებაზე; არ იყო კასეტური მდგომარეობის გადამრთველები.
   • გადახრა — აჩვენებს ღირებულების გავრცელებას (სიზუსტეს). რეაქცია სტანდარტული გადახრის მეთოდის გამოყენებით.
   • იმედი - რამდენჯერ ჩატარდა ეს ტესტი.
2. მოკლე ჟურნალი საშუალებას გაძლევთ შეაფასოთ რას აკეთებს კლასტერი ამჟამად. ნაჩვენებია განმეორების (ტესტის) ნომერი, ოპერაციის დრო და სახელი. ძალიან დიდი ხნის სირბილი (> 5 წუთი) მიუთითებს პრობლემაზე.
3. გული (გული) - მიმდინარე დრო. შესრულების ვიზუალური შეფასებისთვის ოსტატები მიმდინარე დრო მუდმივად იწერება მის მაგიდაზე float IP master-ის გამოყენებით. წარმატების შემთხვევაში, შედეგი გამოჩნდება ამ პანელში.
4. სცემეს (პულსი) - "მიმდინარე დრო", რომელიც ადრე იყო ჩაწერილი სცენარის მიერ გული დაეუფლონ, ახლა წაიკითხეთ მონა მისი float IP მეშვეობით. საშუალებას გაძლევთ ვიზუალურად შეაფასოთ მონისა და რეპლიკაციის შესრულება. Tuchanka1-ში არ არის სლავები float IP-ით (მონები არ უზრუნველყოფენ მომსახურებას), მაგრამ არის ორი ინსტანცია (DB), ამიტომ აქ არ იქნება ნაჩვენები სცემესხოლო გული მეორე ინსტანცია.
5. კლასტერის ჯანმრთელობის მონიტორინგი უტილიტის გამოყენებით pcs mon. აჩვენებს სტრუქტურას, რესურსების განაწილებას კვანძებში და სხვა სასარგებლო ინფორმაციას.
6. აქ ნაჩვენებია სისტემის მონიტორინგი კლასტერში თითოეული ვირტუალური მანქანიდან. შეიძლება მეტი ასეთი პანელი იყოს იმის მიხედვით, თუ რამდენი ვირტუალური მანქანა აქვს კლასტერს. ორი გრაფიკი CPU დატვირთვა (ვირტუალურ მანქანებს აქვთ ორი პროცესორი), ვირტუალური მანქანის სახელი, სისტემის დატვირთვა (დასახელებულია Load Average, რადგან ის საშუალოდ არის 5, 10 და 15 წუთზე), დაამუშავეთ მონაცემები და მეხსიერების განაწილება.
7. ტესტირების შესრულების სკრიპტის კვალი. გაუმართაობის შემთხვევაში - მუშაობის უეცარი შეწყვეტა ან გაუთავებელი ლოდინის ციკლი - აქ შეგიძლიათ ნახოთ ამ ქცევის მიზეზი.

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

თითოეული ტესტი შედგება შემდეგი ოპერაციებისგან:

1. გაუშვით ფუნქცია, რომელიც ასახავს შეცდომას.
2. მზად? — ელოდება კლასტერის აღდგენას (როცა ყველა სერვისი იქნება უზრუნველყოფილი).
3. აჩვენებს კლასტერის აღდგენის დროის ამოწურვას (რეაქცია).
4. ფიქსის - კლასტერი "რემონტდება". რის შემდეგაც ის უნდა დაბრუნდეს სრულ ოპერატიულ მდგომარეობაში და მზად იყოს შემდეგი გაუმართაობისთვის.

აქ მოცემულია ტესტების სია, სადაც აღწერილია რას აკეთებენ ისინი:

• ფორკბომბი: ქმნის "მეხსიერების ამოწურვას" ჩანგლის ბომბის გამოყენებით.
• OutOfSpace: მყარი დისკი სავსეა. მაგრამ ტესტი საკმაოდ სიმბოლურია; იმ უმნიშვნელო დატვირთვით, რომელიც იქმნება ტესტირების დროს, PostgreSQL ჩვეულებრივ არ იშლება, როდესაც მყარი დისკი სავსეა.
• Postgres-KILL: კლავს PostgreSQL ბრძანებით killall -KILL postgres.
• Postgres-STOP: კიდია PostgreSQL ბრძანება killall -STOP postgres.
• Გამორთვა: ბრძანებით ვირტუალურ მანქანას „გაუქმებს ენერგიას“. VBoxManage controlvm "виртуалка" poweroff.
• აღდგენა: გადატვირთავს ვირტუალურ მანქანას ბრძანებით VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: აჩერებს SBD დემონს ბრძანებით killall -STOP sbd.
• Გათიშვა: აგზავნის ბრძანებას ვირტუალურ მანქანაზე SSH-ის საშუალებით systemctl poweroff, სისტემა მოხდენილად ითიშება.
• გაუქმება: ქსელის იზოლაცია, ბრძანება VBoxManage controlvm "виртуалка" setlinkstate1 off.

ტესტირების დასრულება ან სტანდარტული tmux ბრძანების "kill-window" გამოყენებით Ctrl-b &, ან "detch-client" ბრძანება Ctrl-b d: ამ ეტაპზე ტესტირება მთავრდება, tmux იხურება, ვირტუალური მანქანები გამორთულია.

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

• Ახლა მცველი დემონი sbd მუშაობს დაკვირვებული დემონების შეჩერებაზე, მაგრამ არა მათ გაყინვაზე. და, შედეგად, ხარვეზები, რომლებიც იწვევს მხოლოდ გაყინვას Corosync и კარდიოსტიმულატორი, მაგრამ არა ჩამოკიდებული sbd... შემოწმებისთვის Corosync უკვე PR#83 (GitHub-ზე ზე sbd), მიღებულია თემაში სამაგისტრო. ისინი დაპირდნენ (PR#83-ში), რომ იქნებოდა მსგავსი რამ პეისმეიკერისთვის, იმედი მაქვს, რომ წითური ქუდი 8 გავაკეთებ. მაგრამ ასეთი „გაუმართაობა“ სპეკულაციურია და მათი სიმულაცია შესაძლებელია ხელოვნურად, მაგალითად, killall -STOP corosync, მაგრამ არასოდეს შეხვდეთ რეალურ ცხოვრებაში.

• У კარდიოსტიმულატორი ამისთვის ვერსიაში CentOS 7 არასწორად დაყენებული sync_timeout у კვორუმის მოწყობილობა, როგორც შედეგი თუ ერთი კვანძი ვერ მოხერხდა, გარკვეული ალბათობით მეორე კვანძიც გადაიტვირთება, რომელზეც ოსტატი უნდა გადასულიყო. კურნავს გაფართოებით sync_timeout у კვორუმის მოწყობილობა განლაგების დროს (სკრიპტში setup/setup1). ეს ცვლილება არ იქნა მიღებული დეველოპერების მიერ კარდიოსტიმულატორი, სამაგიეროდ დაჰპირდნენ ინფრასტრუქტურის გადამუშავებას ისე (რაღაც გაურკვეველ მომავალში), რომ ეს ტაიმი ავტომატურად გამოითვლებოდა.

• თუ მონაცემთა ბაზის კონფიგურაცია განსაზღვრავს ამას LC_MESSAGES (ტექსტური შეტყობინებები) უნიკოდის გამოყენება შესაძლებელია, მაგ. ru_RU.UTF-8, შემდეგ გაშვებისას პოსტგრამა გარემოში, სადაც ლოკალი არ არის UTF-8, ვთქვათ ცარიელ გარემოში (აქ კარდიოსტიმულატორი+pgsqlms(პაფ) ეშვება პოსტგრამა) შემდეგ ჟურნალი შეიცავს კითხვის ნიშანს UTF-8 ასოების ნაცვლად. PostgreSQL დეველოპერები არ შეთანხმდნენ რა უნდა გააკეთონ ამ შემთხვევაში. ღირს, თქვენ უნდა დააინსტალიროთ LC_MESSAGES=en_US.UTF-8 მონაცემთა ბაზის ინსტანციის კონფიგურაციის (შექმნის) დროს.

• თუ დაყენებულია wal_receiver_timeout (ნაგულისხმევად ეს არის 60 წმ), მაშინ მასტერზე PostgreSQL-STOP ტესტის დროს tuchanka3 და tuchanka4 კლასტერებში რეპლიკაცია არ უკავშირდება ახალ მთავარს. იქ რეპლიკაცია სინქრონულია, ამიტომ არა მხოლოდ მონა ჩერდება, არამედ ახალი ოსტატიც. მუშაობს wal_receiver_timeout=0-ის დაყენებით PostgreSQL-ის კონფიგურაციისას.

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

კროგანის სურათი გადაღებულია deviant Art ავტორის ნებართვით:

წყარო: www.habr.com