Failover: პერფექციონიზმი და... სიზარმაცე გვანადგურებს

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

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

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

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

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

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

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

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

მაგალითი ნომერი პირველი

წარმოიდგინეთ სავიზიტო ბარათის ვებსაიტი მილების მოძრავი ქარხნის No1 ქალაქ ნ-ში, სადაც უზარმაზარი ასოებით წერია - PIPE ROLLING PLANT No1. ზუსტად ქვემოთ არის სლოგანი: „ჩვენი მილები ყველაზე მრგვალი მილებია N-ში“. და ქვემოთ არის აღმასრულებელი დირექტორის ტელეფონის ნომერი და მისი სახელი. ჩვენ გვესმის, რომ თქვენ უნდა გააკეთოთ დაჯავშნა - ეს ძალიან მნიშვნელოვანია! დავიწყოთ იმის გარკვევა, რისგან შედგება. Html-statics - ეს არის რამდენიმე სურათი, სადაც გენერალური მენეჯერი, ფაქტობრივად, განიხილავს რაიმე სახის მომავალ გარიგებას აბაზანაში მაგიდაზე თავის პარტნიორთან ერთად. ჩვენ ვიწყებთ ფიქრს დასვენების დროზე. მახსენდება: იქ უნდა იწვა ხუთი წუთი, მეტი არა. და მაშინ ჩნდება კითხვა: რამდენი გაყიდვები იყო ზოგადად ჩვენი საიტიდან? რამდენი-რამდენი? რას ნიშნავს "ნულოვანი"? და ეს ნიშნავს: იმიტომ, რომ გენერალმა ოთხივე გარიგება გასულ წელს ერთ მაგიდასთან გააკეთა, იმავე ადამიანებთან ერთად, რომლებთანაც ისინი მიდიან აბაზანაში და სხედან მაგიდასთან. და ჩვენ გვესმის, რომ თუნდაც საიტი იჯდეს ერთი დღე, არაფერი საშინელი მოხდება.

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

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

კომპანიის ბლოგი: სპეციალურად მომზადებული ადამიანები წერენ იქ ახალ ამბებს, მივიღეთ მონაწილეობა ამა თუ იმ გამოფენაში, მაგრამ გამოვუშვით კიდევ ერთი ახალი პროდუქტი და ა.შ. ვთქვათ, ეს არის სტანდარტული PHP WordPress-ით, მცირე მონაცემთა ბაზა და ცოტა სტატიკური. რა თქმა უნდა, ისევ მახსენდება, რომ არავითარ შემთხვევაში არ უნდა დაწექი - "არაუმეტეს ხუთი წუთისა!" ეს ყველაფერია. მაგრამ მოდით ვიფიქროთ უფრო შორს. რას აკეთებს ეს ბლოგი? ხალხი ჩამოდის იქ Yandex-დან, Google-იდან ზოგიერთი შეკითხვის საფუძველზე, ორგანულად. დიდი. გაყიდვებს აქვს რამე საერთო? ნათლისღება: ნამდვილად არა. სარეკლამო ტრაფიკი მიდის მთავარ საიტზე, რომელიც სხვა აპარატზეა. დავიწყოთ დაჯავშნის სქემაზე ფიქრი. კარგი კუთხით, რამდენიმე საათში უნდა ამაღლდეს და კარგი იქნებოდა ამისთვის მოემზადოთ. გონივრული იქნება, აიღოთ მანქანა სხვა მონაცემთა ცენტრიდან, შემოახვიოთ მასზე გარემო, ანუ ვებ სერვერი, PHP, WordPress, MySQL და იქ დატოვოთ. იმ მომენტში, როცა გვესმის, რომ ყველაფერი გაფუჭებულია, ჩვენ უნდა გავაკეთოთ ორი რამ - გავაბრტყელოთ mysql dump 50 მეტრზე, ის ერთ წუთში იქ გაფრინდება და იქ სარეზერვოდან გარკვეული რაოდენობის სურათები გავაფართოვოთ. ეს ასევე არ არის, ღმერთმა იცის როდემდე. ასე რომ, ნახევარ საათში ყველაფერი ადგება. არავითარი განმეორება, ან ღმერთმა მაპატიოს, ავტომატური მარცხი. დასკვნა: ის, რაც შეგვიძლია სწრაფად გამოვაქვეყნოთ სარეზერვო ასლიდან, არ საჭიროებს სარეზერვო ასლს.

მაგალითი ნომერი სამი, უფრო რთული

Ონლაინ მაღაზია. PhP ღია გულით არის ოდნავ შეცვლილი, mysql მყარი ბაზით. საკმაოდ ბევრი სტატიკური (ბოლოს და ბოლოს, ონლაინ მაღაზიას აქვს ლამაზი HD სურათები და ეს ყველაფერი), Redis სესიისთვის და Elasticsearch საძიებლად. ჩვენ ვიწყებთ ფიქრს დასვენების დროზე. და აქ, რა თქმა უნდა, აშკარაა, რომ ონლაინ მაღაზია ერთ დღეს უმტკივნეულოდ ვერ იწვება. ბოლოს და ბოლოს, რაც უფრო დიდხანს იტყუება, მით მეტ ფულს ვკარგავთ. ღირს დაჩქარება. Რამდენი? მგონი ერთი საათი რომ დავწექით არავინ გაგიჟდება. დიახ, რაღაცას დავკარგავთ, მაგრამ თუ შრომას დავიწყებთ, ეს მხოლოდ გაუარესდება. ჩვენ განვსაზღვრავთ საათში დასაშვები შეფერხების სქემას.

როგორ შეიძლება ამ ყველაფრის დაჯავშნა? მანქანა ნებისმიერ შემთხვევაში გჭირდებათ: ერთი საათი საკმაოდ ცოტაა. Mysql: აქ ჩვენ უკვე გვჭირდება რეპლიკაცია, ცოცხალი რეპლიკაცია, რადგან ერთ საათში 100 GB დიდი ალბათობით არ დაემატება ნაგავსაყრელს. სტატიკა, სურათები: კიდევ ერთხელ, ერთ საათში 500 GB შეიძლება არ ჰქონდეს დრო დასამატებლად. ამიტომ სჯობს სურათების დაუყონებლივ კოპირება. რედისი: სწორედ აქ ხდება ყველაფერი საინტერესო. Redis-ში სესიები ინახება - ჩვენ არ შეგვიძლია უბრალოდ ავიღოთ და დავმარხოთ. რადგან ეს არც ისე კარგი იქნება: ყველა მომხმარებელი გამოვა, მათი კალათები დაიცლება და ა.შ. ადამიანები იძულებულნი იქნებიან ხელახლა შეიყვანონ მომხმარებლის სახელი და პაროლი და ბევრმა შეიძლება დაშორდეს და არ დაასრულოს შესყიდვა. ისევ შემცირდება კონვერტაციები. მეორეს მხრივ, Redis არის პირდაპირ განახლებული, ბოლო შესული მომხმარებლებიც, ალბათ, არც სჭირდებათ. და კარგი კომპრომისია არის Redis-ის აღება და მისი აღდგენა გუშინდელი სარეზერვოდან, ან, თუ ამას აკეთებთ ყოველ საათში, ერთი საათის წინ. საბედნიეროდ, მისი აღდგენა სარეზერვოდან ნიშნავს ერთი ფაილის კოპირებას. და ყველაზე საინტერესო ამბავი არის Elasticsearch. ვინ აიღო ოდესმე MySQL რეპლიკაცია? ვინ აიღო ოდესმე Elasticsearch რეპლიკაცია? და ვისთვის იმუშავა შემდეგ ჩვეულებრივად? მე ვგულისხმობ არის ის, რომ ჩვენ ვხედავთ გარკვეულ ერთეულს ჩვენს სისტემაში. როგორც ჩანს, ეს სასარგებლოა - მაგრამ რთულია.
კომპლექსური იმ გაგებით, რომ ჩვენს კოლეგა ინჟინრებს არ აქვთ მასთან მუშაობის გამოცდილება. ან არის უარყოფითი გამოცდილება. ან ჩვენ გვესმის, რომ ეს ჯერ კიდევ საკმაოდ ახალი ტექნოლოგიაა ნიუანსებით ან ნედლეულით. ვფიქრობთ... ჯანდაბა, ელასტიკიც ჯანსაღია, სარეზერვოდან აღდგენასაც დიდი დრო სჭირდება, რა ვქნა? ჩვენ გვესმის, რომ ელასტიური ჩვენს შემთხვევაში გამოიყენება საძიებლად. როგორ იყიდება ჩვენი ონლაინ მაღაზია? მივდივართ მარკეტოლოგებთან და ვეკითხებით, საიდან მოდის ხალხი. ისინი პასუხობენ: "90% Yandex Market-დან პირდაპირ მოდის პროდუქტის ბარათზე." და ან ყიდულობენ ან არა. ამიტომ, ძებნა სჭირდება მომხმარებელთა 10%-ს. და ელასტიური რეპლიკაციის შენარჩუნებას, განსაკუთრებით სხვადასხვა ზონაში მონაცემთა სხვადასხვა ცენტრებს შორის, მართლაც ბევრი ნიუანსია. რომელი გასასვლელი? რეზერვირებული საიტიდან ვიღებთ ელასტიკას და არაფერს ვაკეთებთ. თუ საქმე გაჭიანურდება, ალბათ ოდესმე დავაყენებთ, მაგრამ ეს გარკვეული არ არის. სინამდვილეში, დასკვნა იგივეა, პლუს-მინუს: ჩვენ, კიდევ ერთხელ, არ ვიტოვებთ სერვისებს, რომლებიც არ იმოქმედებს ფულზე. იმისათვის, რომ დიაგრამა უფრო მარტივი იყოს.

მაგალითი ნომერი ოთხი, კიდევ უფრო რთული

ინტეგრატორი: ყვავილების გაყიდვა, ტაქსის გამოძახება, საქონლის გაყიდვა, ზოგადად, ყველაფერი. სერიოზული რამ, რომელიც მუშაობს 24/7 მომხმარებელთა დიდი რაოდენობით. სრულფასოვანი საინტერესო სტეკით, სადაც არის საინტერესო ბაზები, გადაწყვეტილებები, მაღალი დატვირთვა და რაც მთავარია, მტკივა 5 წუთზე მეტი წოლა. არა მხოლოდ და არა იმიტომ, რომ ხალხი არ იყიდის, არამედ იმიტომ, რომ ხალხი დაინახავს, ​​რომ ეს არ მუშაობს, გაბრაზდებიან და შეიძლება საერთოდ აღარ დაბრუნდნენ.

ᲙᲐᲠᲒᲘ. Ხუთი წუთი. რას ვაპირებთ ამის გაკეთებას? ამ შემთხვევაში, ჩვენ, როგორც უფროსები, ვიყენებთ მთელ ფულს რეალური სარეზერვო საიტის ასაშენებლად, ყველაფრის გამეორებით და შესაძლოა ამ საიტზე გადართვის მაქსიმალურად ავტომატიზირებაც კი. გარდა ამისა, თქვენ უნდა გახსოვდეთ ერთი მნიშვნელოვანი რამის გაკეთება: რეალურად დაწერეთ გადართვის წესები. რეგულაციები, მაშინაც კი, თუ ყველაფერი ავტომატიზირებული გაქვთ, შეიძლება იყოს ძალიან მარტივი. სერიიდან „გაუშვით ასეთი და ასეთი სკრიპტი“, „დააწკაპუნეთ ამა თუ იმ ჩამრთველზე 53 მარშრუტზე“ და ასე შემდეგ - მაგრამ ეს უნდა იყოს მოქმედებების ერთგვარი ზუსტი სია.

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

მაგალითი ნომერი ხუთი, სრული ჰარდკორი

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

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

ალბათ სულ ესაა. არ დაიზაროთ და არ გადააჭარბოთ. და შეიძლება დრო იყოს თქვენთან ერთად!

წყარო: www.habr.com