როგორ მიაღწია Badoo-მ წამში 200 ათასი ფოტოს გაგზავნის შესაძლებლობას

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

— დავიწყოთ მცირე შესავალით, თუ როგორ ვინახავთ და ქეშით ფოტოებს. ჩვენ გვაქვს ფენა, სადაც მათ ვინახავთ, და ფენა, სადაც ფოტოებს ქეშს ვაკეთებთ. ამავდროულად, თუ გვსურს მივაღწიოთ ტრიუკის მაღალ სიჩქარეს და შევამციროთ საცავზე დატვირთვა, ჩვენთვის მნიშვნელოვანია, რომ ინდივიდუალური მომხმარებლის თითოეული ფოტო იყოს ერთ ქეშირების სერვერზე. წინააღმდეგ შემთხვევაში, იმდენჯერ მეტი დისკის დაყენება მოგვიწევდა, რამდენი სერვერი გვაქვს. ჩვენი ტრიუკების მაჩვენებელი დაახლოებით 99%-ია, ანუ ჩვენ ვამცირებთ დატვირთვას ჩვენს საცავზე 100-ჯერ და ამისათვის 10 წლის წინ, როცა ეს ყველაფერი შენდებოდა, გვქონდა 50 სერვერი. შესაბამისად, ამ ფოტოების მოსამსახურებლად დაგვჭირდა არსებითად 50 გარე დომენი, რომელსაც ეს სერვერები ემსახურებიან.

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

რას აკეთებს აპარატურის ეს ნაწილი (LTM): ეს არის რკინის როუტერი, რომელიც აჭარბებს მის გარე პორტებს და საშუალებას გაძლევთ მარშრუტით ტრაფიკი ქსელის ტოპოლოგიაზე, ზოგიერთ პარამეტრზე და აკეთებს ჯანმრთელობის შემოწმებას. ჩვენთვის მნიშვნელოვანი იყო, რომ ამ ტექნიკის დაპროგრამება შეიძლებოდა. შესაბამისად, ჩვენ შეგვიძლია აღვწეროთ ლოგიკა იმისა, თუ როგორ ემსახურებოდა კონკრეტული მომხმარებლის ფოტოებს კონკრეტული ქეშიდან. Რას გავს? არის ტექნიკის ნაწილი, რომელიც უყურებს ინტერნეტს ერთ დომენზე, ერთ IP-ზე, აკეთებს ssl-ის გადმოტვირთვას, აანალიზებს http მოთხოვნებს, ირჩევს ქეშის ნომერს IRule-დან, სად უნდა წავიდეს და აძლევს ტრაფიკს იქ წასვლას. ამავდროულად, ის აკეთებს ჯანმრთელობის შემოწმებებს და იმ შემთხვევაში, თუ რომელიმე მანქანა მიუწვდომელია, ამ დროს ჩვენ გავაკეთეთ ისე, რომ ტრაფიკი წავიდა ერთ სარეზერვო სერვერზე. კონფიგურაციის თვალსაზრისით, რა თქმა უნდა, არის რამდენიმე ნიუანსი, მაგრამ ზოგადად ყველაფერი საკმაოდ მარტივია: ჩვენ ვაწერთ ბარათს, გარკვეული ნომრის მიმოწერას ჩვენს IP-ზე ქსელში, ჩვენ ვამბობთ, რომ მოვუსმენთ 80-ე პორტებს. და 443, ჩვენ ვამბობთ, რომ თუ სერვერი მიუწვდომელია, მაშინ თქვენ უნდა გააგზავნოთ ტრაფიკი სარეზერვო ერთზე, ამ შემთხვევაში 35-ეზე, და ჩვენ აღვწერთ ლოგიკას, თუ როგორ უნდა დაიშალა ეს არქიტექტურა. ერთადერთი პრობლემა ის იყო, რომ ენა, რომელზეც აპარატურა იყო დაპროგრამებული, იყო Tcl. თუ ვინმეს ახსოვს ეს საერთოდ... ეს ენა უფრო წერია, ვიდრე პროგრამირებისთვის მოსახერხებელი ენა:

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

თუმცა

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

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

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

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

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

იმის გამო, რომ დავალება ჟღერდა, როგორც „რაღაცის გაკეთება რაც შეიძლება სწრაფად და იმ ტექნიკის გამოყენებით, რაც გვაქვს“, პირველი, რაც ჩვენ ვიფიქრეთ, იყო უბრალოდ წინა მხრიდან რამდენიმე არც თუ ისე მძლავრი აპარატის ამოღება, იქ დაყენება Nginx, რომლითაც ჩვენ ვიცით, როგორ გავაკეთოთ. იმუშავეთ და შეეცადეთ განახორციელოთ იგივე ლოგიკა, რასაც აპარატურა აკეთებდა. ანუ, ფაქტობრივად, დავტოვეთ ჩვენი აპარატურა, დავაინსტალირეთ კიდევ 4 სერვერი, რომელთა კონფიგურაციაც მოგვიწია, შევქმენით მათთვის გარე დომენები, როგორც ეს იყო 10 წლის წინ... ცოტა დავკარგეთ ხელმისაწვდომობა, თუ ეს მანქანები დაეცა, მაგრამ მათ მაინც მოაგვარეს ჩვენი მომხმარებლების პრობლემა ადგილობრივად.

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

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

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

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

ამის თავიდან ასაცილებლად, ჩვენ გავაკეთეთ ორი რამ:

ა) მათ აუკრძალეს Nginx-ს ამის ხელით გაკეთება - და სამწუხაროდ, ამის გაკეთების ერთადერთი გზა არის უბრალოდ მაქსიმალური წარუმატებლობის პარამეტრების დაყენება.

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

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

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

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

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

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

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

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

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

ამრიგად, ჩვენ უზრუნველვყავით გარე IP მისამართის შეცდომის ტოლერანტობა. შემდეგი ნაწილი არის როგორმე დაბალანსება ტრაფიკი გარე IP მისამართიდან ფოტო მარშრუტიზატორებამდე, რომლებიც უკვე წყვეტენ მას. დაბალანსების პროტოკოლებით ყველაფერი საკმაოდ ნათელია. ეს არის ან მარტივი მრგვალი, ან ოდნავ უფრო რთული რამ, wrr, სიის კავშირი და ა.შ. ეს ძირითადად აღწერილია დოკუმენტაციაში, განსაკუთრებული არაფერია. მაგრამ მიწოდების მეთოდი... აქ ჩვენ უფრო დეტალურად განვიხილავთ, რატომ ავირჩიეთ ერთი მათგანი. ეს არის NAT, პირდაპირი მარშრუტიზაცია და TUN. ფაქტია, რომ ჩვენ დაუყოვნებლივ დავგეგმეთ საიტებიდან 100 გიგაბიტი ტრაფიკის მიწოდება. თუ შეაფასებთ, გჭირდებათ 10 გიგაბიტიანი ბარათი, არა? 10 გიგაბიტიანი ბარათი ერთ სერვერზე უკვე სცილდება, ყოველ შემთხვევაში, ჩვენი „სტანდარტული აღჭურვილობის“ კონცეფციის ფარგლებს. შემდეგ კი ჩვენ გავიხსენეთ, რომ ჩვენ უბრალოდ არ ვაძლევთ ტრაფიკს, ჩვენ ვაჩუქებთ ფოტოებს.

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

თუ ამ გრაფიკებს დააკვირდებით, ხედავთ, რომ ამ მომენტში რეჟისორი იღებს დაახლოებით 200 მბ წამში, ეს ძალიან ჩვეულებრივი დღეა. ჩვენ ვუბრუნებთ 4,500 მბ წამში, ჩვენი თანაფარდობა არის დაახლოებით 1/22. უკვე ნათელია, რომ 22 მუშა სერვერზე გამავალი ტრაფიკის სრულად უზრუნველსაყოფად, ჩვენ გვჭირდება მხოლოდ ერთი, რომელიც მიიღებს ამ კავშირს. სწორედ აქ გვეხმარება პირდაპირი მარშრუტის ალგორითმი.

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

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

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

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

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

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

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

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

რა დავამთავრეთ? პრობლემა გვქონდა 2018 წლის იანვრის არდადეგებზე. პირველ ექვს თვეში, სანამ ეს სქემა ამოქმედდა, გავაფართოვეთ იგი მთელ ტრაფიკზე, რათა ამოგვეშალა ყველა ტრაფიკი LTM-დან, ჩვენ გავზარდეთ ტრაფიკი მხოლოდ ერთ მონაცემთა ცენტრში 40 გიგაბიტიდან 60 გიგაბიტამდე, და ამავე დროს მთელი 2018 წელი შეძლეს წამში თითქმის სამჯერ მეტი ფოტოს გაგზავნა.

წყარო: www.habr.com