Elasticsearch კლასტერი 200 TB+

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

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

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

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

მოთხოვნები

სისტემის მოთხოვნები ჩამოყალიბდა შემდეგნაირად:

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

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

ოთხშაბათი

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

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

მნიშვნელოვანი თვისება: კლასტერი იწყება კონტეინერებში პოდმანი არა ფიზიკურ მანქანებზე, არამედ საკუთარი ღრუბლოვანი პროდუქტი ერთი ღრუბელი. კონტეინერებს გარანტირებული აქვს 2 ბირთვი, მსგავსი 2.0Ghz v4, დარჩენილი ბირთვების გადამუშავების შესაძლებლობით, თუ ისინი უმოქმედოა.

Სხვა სიტყვებით:

ტოპოლოგია

მე თავიდან დავინახე ხსნარის ზოგადი ფორმა შემდეგნაირად:

• Graylog დომენის A- ჩანაწერის უკან 3-4 VIP დგას, ეს არის მისამართი, რომელზეც იგზავნება ჟურნალები.
• თითოეული VIP არის LVS ბალანსერი.
• ამის შემდეგ, ჟურნალები გადადის Graylog-ის ბატარეაზე, ზოგიერთი მონაცემი არის GELF ფორმატში, ზოგიც syslog ფორმატში.
• შემდეგ ეს ყველაფერი დიდი პარტიებით იწერება Elasticsearch კოორდინატორების ბატარეაზე.
• და ისინი, თავის მხრივ, უგზავნიან ჩაწერის და წაკითხვის მოთხოვნებს შესაბამის მონაცემთა კვანძებში.

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

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

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

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

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

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

გრაილოგი
ეს არის Kibana-ს შერწყმა Logstash-თან ELK სტეკში. Graylog აერთიანებს როგორც UI-ს, ასევე ჟურნალის დამუშავების მილსადენს. ქუდის ქვეშ, Graylog გადის Kafka და Zookeeper, რომლებიც უზრუნველყოფენ გრეილოგთან დაკავშირებას, როგორც კლასტერს. Graylog-ს შეუძლია ქეშის ჩანაწერები (Kafka) იმ შემთხვევაში, თუ Elasticsearch მიუწვდომელია და გაიმეოროს წარუმატებელი წაკითხვისა და ჩაწერის მოთხოვნები, დააჯგუფოს და მონიშნოს ჟურნალები მითითებული წესების მიხედვით. Logstash-ის მსგავსად, Graylog-ს აქვს ფუნქციების შეცვლა რიგების Elasticsearch-ში ჩაწერამდე.

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

ვიზუალურად ასე გამოიყურება:

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

ინდექსები

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

ზემოთ მოცემულ დიაგრამაში ეს არის ყველაზე დაბალი დონე: Elasticsearch მონაცემთა კვანძები.

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

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

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

ჩვენ პირველად განვსაზღვრეთ შენახვის დრო 30 დღე.

ნამსხვრევების განაწილება გრაფიკულად შეიძლება წარმოდგენილი იყოს შემდეგნაირად:

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

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

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

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

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

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

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

შედეგად, ჩვენ აღმოვაჩინეთ, რომ საშუალოდ ერთი ნატეხი იწონის დაახლოებით 20 გიგაბაიტს, ხოლო თითო ინდექსზე არის 1 ნატეხი. შესაბამისად, თუ მათ 360 საათში ერთხელ ვატრიალებთ, მაშინ გვექნება 48. თითოეული ინდექსი შეიცავს მონაცემებს 15 დღის განმავლობაში.

მონაცემთა ჩაწერისა და კითხვის სქემები

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

ვთქვათ, გრეილოგიდან კოორდინატორთან რაღაც მოთხოვნა მოდის. მაგალითად, გვინდა 2-3 ათასი მწკრივის ინდექსირება.

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

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

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

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

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

მთელი ეს სისტემა საშუალოდ ამუშავებს საძიებო მოთხოვნებს ბოლო 48 საათის განმავლობაში 300-400 ms-ში, იმ მოთხოვნების გამოკლებით, რომლებსაც აქვთ წამყვანი ველური ბარათი.

ყვავილები Elasticsearch-ით: ჯავის დაყენება

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

აღმოჩენილი პრობლემების პირველი ნაწილი დაკავშირებული იყო Java-ს წინასწარ კონფიგურაციასთან Elasticsearch-ში ნაგულისხმევად.

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

აღმოჩნდა, რომ ლუცენის ინდექსის შერწყმა ხდება ბარძაყის გარეთ. და კონტეინერები საკმაოდ მკაცრად შეზღუდულია მოხმარებული რესურსების თვალსაზრისით. ამ რესურსებში მხოლოდ გროვა შეიძლება მოთავსდეს (heap.size მნიშვნელობა დაახლოებით RAM-ის ტოლი იყო) და ზოგიერთი off-heap ოპერაციები ჩაიშალა მეხსიერების განაწილების შეცდომით, თუ რაიმე მიზეზით არ ჯდებოდა ~500 მბ-ში, რომელიც ლიმიტამდე დარჩა.

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

პრობლემა მეორე
კლასტერის გაშვებიდან 4-5 დღის შემდეგ, ჩვენ შევამჩნიეთ, რომ მონაცემთა კვანძები პერიოდულად იწყებენ ცვენას კლასტერიდან და შედიან მასში 10-20 წამის შემდეგ.

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

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

გამოსავალი იყო შემდეგი: ჩვენ შევზღუდეთ ჯავას შესაძლებლობა გამოიყენოს მეხსიერების დიდი ნაწილი გროვის გარეთ ამ ოპერაციებისთვის. ჩვენ შევზღუდეთ ის 16 გიგაბაიტით (-XX:MaxDirectMemorySize=16g), რაც დავრწმუნდით, რომ აშკარა GC გამოიძახებოდა უფრო ხშირად და დამუშავებული იყო ბევრად უფრო სწრაფად, რითაც აღარ მოხდება კლასტერის დესტაბილიზაცია.

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

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

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

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

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

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

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

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

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

აქ დასრულდა ჯავის პრობლემები და დაიწყო გამტარუნარიანობის პრობლემები.

"კენკრა" Elasticsearch-ით: გამტარუნარიანობა

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

პირველი სიმპტომი, რომელიც გამოვლინდა: წარმოების ზოგიერთი „აფეთქების“ დროს, როდესაც მოულოდნელად წარმოიქმნება ჟურნალების ძალიან დიდი რაოდენობა, ინდექსირების შეცდომა es_rejected_execution იწყებს ხშირად ციმციმებს Graylog-ში.

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

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

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

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

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

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

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

კითხვის სურათი იწყება ასე:

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

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

რა გვინდოდა კლასტერისგან ერთ DC-თან კავშირის დაკარგვისთანავე:

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

როგორც იქნა, გვინდოდა მსგავსი რამ:

და მივიღეთ შემდეგი:

Როგორ მოხდა ეს?

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

რატომ?

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

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

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

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

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

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

6.4.0 ვერსიის შემდეგ, სადაც ეს საშინელი შეცდომა გამოსწორდა, მონაცემთა კვანძებმა შეწყვიტეს ოსტატის მოკვლა. მაგრამ ამან არ გახადა ის "ჭკვიანი". კერძოდ: როდესაც ჩვენ გამოვაქვთ 2, 3 ან 10 (ნებისმიერი რიცხვი ერთის გარდა) მონაცემთა კვანძი, მასტერი იღებს პირველ შეტყობინებას, რომელიც ამბობს, რომ A კვანძი დატოვა და ცდილობს აცნობოს B კვანძს, C კვანძს ამის შესახებ, კვანძს D.

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

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

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

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

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

შედეგად მივედით შემდეგ გადაწყვეტილებამდე:

• ჩვენ გვაქვს 360 მონაცემთა კვანძი 700 გიგაბაიტიანი დისკებით.
• 60 კოორდინატორი ტრაფიკის მარშრუტირებისთვის იმავე მონაცემთა კვანძების მეშვეობით.
• 40 ოსტატი, რომელიც ჩვენ დავტოვეთ, როგორც ერთგვარი მემკვიდრეობა 6.4.0-მდე ვერსიებიდან - იმისათვის, რომ გადავრჩენილიყავით მონაცემთა ცენტრის გაყვანის შემდეგ, გონებრივად მზად ვიყავით დავკარგოთ რამდენიმე მანქანა, რათა გარანტირებული გვქონდეს ოსტატების კვორუმიც კი ყველაზე უარესი სცენარი
• ერთ კონტეინერზე როლების გაერთიანების ნებისმიერ მცდელობას შეხვდა ის ფაქტი, რომ ადრე თუ გვიან კვანძი იშლება დატვირთვის ქვეშ.
• მთელი კლასტერი იყენებს heap.size 31 გიგაბაიტს: ზომის შემცირების ყველა მცდელობამ გამოიწვია ან მოკვლა ზოგიერთი კვანძი მძიმე საძიებო კითხვებზე წამყვანი wildcard-ით ან ამომრთველის მიღება თავად Elasticsearch-ში.
• გარდა ამისა, ძიების შესრულების უზრუნველსაყოფად, ჩვენ ვცდილობდით შეგვენარჩუნებინა ობიექტების რაოდენობა კლასტერში რაც შეიძლება მცირე, რათა დამუშავდეს რაც შეიძლება ნაკლები მოვლენა იმ ბოთლში, რომელიც მივიღეთ მასტერში.

ბოლოს რაც შეეხება მონიტორინგს

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

• თითოეული მონაცემთა კვანძი აცნობებს ჩვენს ღრუბელს, რომ ის არსებობს და მასზე არის ასეთი და ასეთი ფრაგმენტები. როცა სადმე რაღაცას ვაქრობთ, კლასტერი 2-3 წამის შემდეგ იტყობინება, რომ A ცენტრში ჩვენ ჩავაქროთ კვანძები 2, 3 და 4 - ეს ნიშნავს, რომ სხვა მონაცემთა ცენტრებში ჩვენ არავითარ შემთხვევაში არ შეგვიძლია ჩავაქროთ ის კვანძები, რომლებზეც მხოლოდ ერთი ნატეხია. დატოვა.
• ვიცოდეთ ოსტატის ქცევის ხასიათი, ჩვენ ძალიან ყურადღებით ვუყურებთ მომლოდინე დავალებების რაოდენობას. იმის გამო, რომ თუნდაც ერთი ჩარჩენილი დავალება, თუ ის დროულად არ ამოიწურება, თეორიულად ზოგიერთ საგანგებო სიტუაციაში შეიძლება გახდეს მიზეზი იმისა, რომ, მაგალითად, რეპლიკა ფრაგმენტის პოპულარიზაცია პირველადში არ მუშაობს, რის გამოც ინდექსირება შეწყვეტს მუშაობას.
• ჩვენ ასევე ძალიან კარგად ვუყურებთ ნაგვის შემგროვებლის შეფერხებებს, რადგან ოპტიმიზაციის დროს ამაში უკვე დიდი სირთულეები გვქონდა.
• უარყოფს ძაფით, რათა წინასწარ გაიგოს სად არის ბოთლი.
• ისე, სტანდარტული მეტრიკა, როგორიცაა heap, RAM და I/O.

მონიტორინგის მშენებლობისას, თქვენ უნდა გაითვალისწინოთ Thread Pool-ის მახასიათებლები Elasticsearch-ში. Elasticsearch დოკუმენტაცია აღწერს კონფიგურაციის ვარიანტებს და ნაგულისხმევ მნიშვნელობებს ძიებისა და ინდექსაციისთვის, მაგრამ სრულიად დუმს thread_pool.management-ის შესახებ. ეს ძაფები ამუშავებს, კერძოდ, კითხვებს, როგორიცაა _cat/shards და სხვა მსგავსი, რომლებიც მოსახერხებელია მონიტორინგის წერისას. რაც უფრო დიდია კლასტერი, მით მეტი ასეთი მოთხოვნა შესრულდება დროის ერთეულზე და ზემოაღნიშნული thread_pool.management არა მხოლოდ არ არის წარმოდგენილი ოფიციალურ დოკუმენტაციაში, არამედ ნაგულისხმევად შემოიფარგლება 5 ძაფით, რომელიც ძალიან სწრაფად განადგურდება, შემდეგ რომელი მონიტორინგი წყვეტს სწორ მუშაობას.

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

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

წყარო: www.habr.com