AERODISK ძრავა: კატასტროფების წინააღმდეგობა. Ნაწილი 1

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

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

ცოტა თეორია

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

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

ამ მეთოდის უპირატესობები:

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

Cons:

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

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

ასინქრონული რეპლიკაციის დადებითი მხარეები:

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

Cons:

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

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

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

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

აქ არ არის ნათელი პასუხი, ასე რომ, აქ არის არგუმენტები FOR და Cons:

არგუმენტები შენახვის რეპლიკაციისთვის:

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

არგუმენტები შენახვის რეპლიკაციის წინააღმდეგ:

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

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

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

დასრულდა თეორია, ახლა პრაქტიკა

ჩვენ დავაკონფიგურირებთ რეპლიკას ჩვენს ლაბორატორიაში. ლაბორატორიულ პირობებში ჩვენ მივბაძეთ ორ მონაცემთა ცენტრს (ფაქტობრივად, ორი მიმდებარე თაროები, რომლებიც თითქოს სხვადასხვა შენობაში იყო). სტენდი შედგება ორი Engine N2 შენახვის სისტემისგან, რომლებიც ერთმანეთთან დაკავშირებულია ოპტიკური კაბელებით. ფიზიკური სერვერი, რომელიც მუშაობს Windows Server 2016-ზე, დაკავშირებულია ორივე საცავ სისტემასთან 10 გბ Ethernet-ის გამოყენებით. სტენდი საკმაოდ მარტივია, მაგრამ ეს არ ცვლის არსს.

სქემატურად ასე გამოიყურება:

ლოგიკურად, რეპლიკაცია ორგანიზებულია შემდეგნაირად:

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

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

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

ამჟამად, AERODISK ENGINE შენახვის სისტემა მხარს უჭერს რეპლიკაციას ბლოკის მოწყობილობებისთვის (LUNs) Ethernet პროტოკოლის მეშვეობით (სპილენძის ან ოპტიკური). პროექტებისთვის, სადაც საჭიროა რეპლიკაცია SAN ქსოვილის მეშვეობით Fiber Channel-ზე, ჩვენ ამჟამად ვამატებთ შესაბამის გადაწყვეტას, მაგრამ ის ჯერ არ არის მზად, ასე რომ, ჩვენს შემთხვევაში, მხოლოდ Ethernet.

რეპლიკაცია შეიძლება იმუშაოს ENGINE სერიის შენახვის სისტემებს შორის (N1, N2, N4) უმცროსი სისტემებიდან უფროსამდე და პირიქით.

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

• რეპლიკაცია "ერთი ერთზე" ან "ერთი ერთზე", ანუ კლასიკური ვერსია ორი მონაცემთა ცენტრით, მთავარი და სარეზერვო.
• რეპლიკაცია არის „ერთი ბევრს“ ან „ერთი ბევრს“, ე.ი. ერთი LUN შეიძლება განმეორდეს რამდენიმე შენახვის სისტემაზე ერთდროულად
• რეპლიკაციის გააქტიურება, გამორთვა და „უკუ“ გამეორება, შესაბამისად, ჩართვის, გამორთვის ან რეპლიკაციის მიმართულების შესაცვლელად
• რეპლიკაცია ხელმისაწვდომია როგორც RDG (Raid Distributed Group) და DDP (Dynamic Disk Pool) აუზებისთვის. თუმცა, RDG აუზის LUN-ების გამეორება შესაძლებელია მხოლოდ სხვა RDG-ზე. იგივე DDP.

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

რეპლიკაციის დაყენება

დაყენების პროცესი საკმაოდ მარტივია და შედგება სამი ეტაპისგან.

1. ქსელის კონფიგურაცია
2. მეხსიერების დაყენება
3. წესების (კავშირების) დაყენება და რუკების შედგენა

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

ქსელის რესურსების დაყენება

პირველი ნაბიჯი არის ქსელის პორტების კონფიგურაცია, რომლის მეშვეობითაც გადაიცემა რეპლიკაციის ტრაფიკი. ამისათვის თქვენ უნდა ჩართოთ პორტები და დააყენოთ მათი IP მისამართები Front-end ადაპტერების განყოფილებაში.

ამის შემდეგ, ჩვენ უნდა შევქმნათ აუზი (ჩვენს შემთხვევაში RDG) და ვირტუალური IP რეპლიკაციისთვის (VIP). VIP არის მცურავი IP მისამართი, რომელიც დაკავშირებულია შენახვის კონტროლერების ორ „ფიზიკურ“ მისამართთან (პორტები, რომლებიც ჩვენ ახლახან დავაკონფიგურირეთ). ეს იქნება რეპლიკაციის მთავარი ინტერფეისი. თქვენ ასევე შეგიძლიათ იმუშაოთ არა VIP-ით, არამედ VLAN-ით, თუ დაგჭირდებათ მონიშნული ტრაფიკით მუშაობა.

რეპლიკისთვის VIP-ის შექმნის პროცესი დიდად არ განსხვავდება I/O-სთვის VIP-ის შექმნისგან (NFS, SMB, iSCSI). ამ შემთხვევაში ჩვენ ვქმნით რეგულარულ VIP-ს (VLAN-ის გარეშე), მაგრამ აუცილებლად მივუთითებთ, რომ ის რეპლიკაციისთვისაა (ამ მაჩვენებლის გარეშე შემდეგ ეტაპზე VIP წესს ვერ დავამატებთ).

VIP უნდა იყოს იმავე ქვექსელში, როგორც IP პორტები, რომელთა შორისაც ის ცურავს.

ჩვენ ვიმეორებთ ამ პარამეტრებს დისტანციური შენახვის სისტემაზე, რა თქმა უნდა, განსხვავებული IP-ით.
სხვადასხვა საცავის სისტემის VIP-ები შეიძლება იყვნენ სხვადასხვა ქვექსელში, მთავარია მათ შორის მარშრუტიზაცია იყოს. ჩვენს შემთხვევაში, ეს მაგალითი ზუსტად არის ნაჩვენები (192.168.3.XX და 192.168.2.XX)

ეს ასრულებს ქსელის ნაწილის მომზადებას.

მეხსიერების დაყენება

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

ადრე შექმნილ აუზში R02, თქვენ უნდა შექმნათ LUN. მოდით შევქმნათ და ვუწოდოთ მას LUN1.

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

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

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

რეპლიკაციის წესების ან რეპლიკაციის ბმულების დაყენება

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

პარამეტრი შესრულებულია მენიუში "დისტანციური რეპლიკაცია".

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

„დისტანციური სისტემების“ ველში ვამატებთ ჩვენს შენახვის სისტემას2. დასამატებლად, თქვენ უნდა გამოიყენოთ მართვის IP შენახვის სისტემები (MGR) და დისტანციური LUN-ის სახელი, რომელშიც ჩვენ განვახორციელებთ რეპლიკაციას (ჩვენს შემთხვევაში, LUN1R). საკონტროლო IP-ები საჭიროა მხოლოდ კავშირის დამატების ეტაპზე; რეპლიკაციის ტრაფიკი არ გადაიცემა მათი მეშვეობით; ამისათვის გამოყენებული იქნება ადრე კონფიგურირებული VIP.

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

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

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

შენახვის სისტემა 1. შექმნისთანავე დაიწყო სინქრონიზაცია.

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

LUN1 შენახვის სისტემა 1-ზე არის ძირითადი როლი, ანუ აქტიურია. მეხსიერების სისტემა 1-ზე LUN2R არის მეორადი როლში, ანუ ის ლოდინის რეჟიმშია შენახვის სისტემის 1 გაუმართაობის შემთხვევაში.
ახლა ჩვენ შეგვიძლია დავუკავშიროთ ჩვენი LUN მასპინძელს.

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

ერთადერთი განსხვავება ისაა, რომ ჩვენ ვქმნით რუკებს მენიუში "Replication Mapping".

ჩვენ დავაყენეთ რუქები და LUN მივეცით მასპინძელს. მასპინძელმა ლუნი ნახა.

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

ესე იგი, დაყენება დასრულებულია. ტესტები შემდეგი იქნება.

ტესტირება

ჩვენ შევამოწმებთ სამ მთავარ სცენარს.

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

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

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

ყოველი შემთხვევისთვის, მოდით გადავხედოთ ერთ-ერთი ფაილის ჰეშის ჯამებს და ჩავწეროთ ისინი.

როლების რეგულარული შეცვლა

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

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

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

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

რამდენიმე წამის შემდეგ, LUN1R (სარეზერვო შენახვის სისტემა) ხდება ძირითადი.

ჩვენ ვასახავთ LUN1R-ს შენახვის სისტემით2.

ამის შემდეგ ჩვენი E: დისკი ავტომატურად მიმაგრებულია ჰოსტზე, მხოლოდ ამჯერად ის „ჩამოვიდა“ LUN1R-დან.

ყოველი შემთხვევისთვის, ჩვენ ვადარებთ ჰეშის ჯამებს.

იდენტურად. ტესტი ჩააბარა.

Failover. მონაცემთა ცენტრის უკმარისობა

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

ვნახოთ, რა ხდება მეხსიერების სისტემა 1-ზე (ამჟამად სარეზერვო სისტემა).

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

შეცვალეთ LUN1-ის როლი Primary-ზე.

მე ვაკეთებ რუკებს მასპინძელთან.

დარწმუნდით, რომ დისკი E გამოჩნდება ჰოსტზე.

ჩვენ ვამოწმებთ ჰეშს.

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

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

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

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

მონაცემთა ცენტრებს შორის საკომუნიკაციო არხების გაუმართაობა

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

Primary-ზე ვხედავთ, რომ მეორადთან კავშირი არ არის.

მეორადზე ვხედავთ, რომ პირველადთან კავშირი არ არის.

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

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

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

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

დასკვნები

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

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

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

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

მომავალ ჯერამდე.

წყარო: www.habr.com