Cloister → მარტივი OTP კლასტერის მართვა

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

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

სხვადასხვა კვანძების პროცესებს შორის, ასევე ბმულებსა და მონიტორებს შორის გადაცემული შეტყობინება გამჭვირვალეა […]

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

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

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

მოთხოვნები

რაც მე პირადად მჭირდებოდა იყო ბიბლიოთეკა, რომელიც აიღებდა კლასტერის მართვას და ექნებოდა შემდეგი თვისებები:

• გამჭვირვალე მუშაობა როგორც კვანძების მყარი კოდირებული სიით, ასევე სერვისების მეშვეობით დინამიური აღმოჩენებით ერლანგი;
• სრულად ფუნქციონალური გამოძახება ტოპოლოგიის ყოველი ცვლილებისთვის (კვანძი იქ, კვანძი აქ, ქსელის არასტაბილურობა, გაყოფა);
• გამჭვირვალე ინტერფეისი კლასტერის გასაშვებად გრძელი და მოკლე სახელებით, ისევე როგორც :nonode@nohost;
• Docker მხარდაჭერა out of box, ინფრასტრუქტურის კოდის დაწერის გარეშე.

ეს უკანასკნელი ნიშნავს, რომ მას შემდეგ, რაც მე გამოვცადე აპლიკაცია ადგილობრივად :nonode@nohost, ან ხელოვნურად განაწილებულ გარემოში გამოყენებით test_cluster_task, უბრალოდ გაქცევა მინდა docker-compose up --scale my_app=3 და ნახეთ, როგორ ახორციელებს ის სამ ინსტანციას დოკერში ყოველგვარი კოდის ცვლილების გარეშე. ასევე მინდა დამოკიდებული აპლიკაციები, როგორიცაა mnesia - როდესაც ტოპოლოგია იცვლება, კულისებში ისინი აღადგენენ კლასტერს პირდაპირ ეთერში, აპლიკაციის დამატებითი დარტყმის გარეშე.

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

არჩეული მიდგომა

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

აპლიკაციის სახით გაშვებისას, ბიბლიოთეკა ეყრდნობა config, საიდანაც ის კითხულობს შემდეგ ძირითად მნიშვნელობებს:

config :cloister,
  otp_app: :my_app,
  sentry: :"cloister.local", # or ~w|n1@foo n2@bar|a
  consensus: 3,              # number of nodes to consider
                             #    the cluster is up
  listener: MyApp.Listener   # listener to be called when
                             #    the ring has changed

ზემოთ მოცემული პარამეტრები სიტყვასიტყვით ნიშნავს შემდეგს: სამყურა გამოიყენება OTP აპლიკაციისთვის :my_app, იყენებს erlang სერვისის აღმოჩენა კვანძების დასაკავშირებლად მინიმუმ სამი და MyApp.Listener მოდული (განხორციელების @behaviour Cloister.Listener) კონფიგურირებულია ტოპოლოგიის ცვლილებების შესახებ შეტყობინებების მისაღებად. სრული კონფიგურაციის დეტალური აღწერა შეგიძლიათ იხილოთ აქ დოკუმენტაცია.

ამ კონფიგურაციით, აპლიკაცია სამყურა ნება გაშვება ეტაპობრივად, ძირითადი აპლიკაციის დაწყების პროცესის შეფერხება კონსენსუსის მიღწევამდე (სამი კვანძი დაკავშირებულია და დაკავშირებულია, როგორც ზემოთ მოცემულ მაგალითში.) ეს აძლევს მთავარ აპლიკაციას შესაძლებლობას ივარაუდოს, რომ როდესაც ის დაიწყება, კლასტერი უკვე ხელმისაწვდომია. როდესაც ტოპოლოგია იცვლება (ისინი ბევრი იქნება, რადგან კვანძები არ იწყება მთლიანად სინქრონულად), გამოიძახება დამმუშავებელი. MyApp.Listener.on_state_change/2. ყველაზე ხშირად ჩვენ ვასრულებთ მოქმედებას, როდესაც ვიღებთ სტატუსის შეტყობინებას %Cloister.Monitor{status: :up}, რაც ნიშნავს: „გამარჯობა, კლასტერი აწყობილია“.

უმეტეს შემთხვევაში, ინსტალაცია consensus: 3 ოპტიმალურია, რადგან მაშინაც კი, თუ ჩვენ ველით მეტი კვანძის დაკავშირებას, გამოძახება განხორციელდება status: :rehashing → status: :up ნებისმიერ ახლად დამატებულ ან ამოღებულ კვანძზე.

განვითარების რეჟიმში დაწყებისას თქვენ უბრალოდ უნდა დააყენოთ consensus: 1 и სამყურა სიამოვნებით გამოტოვებს კლასტერის შეკრების მოლოდინს, როცა დაინახავს :nonode@nohostან :node@hostან :[email protected] - დამოკიდებულია იმაზე, თუ როგორ იყო კონფიგურირებული კვანძი (:none | :shortnames | :longnames).

განაწილებული აპლიკაციის მენეჯმენტი

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

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

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

შენიშვნა: ამ მომენტში ორიგინალში იყო ფრაზა "Happy Clustering!" და Yandex-მა, რომლითაც მე ვთარგმნი (მე თვითონ არ მჭირდება ლექსიკონების გავლა), შემომთავაზა ვარიანტი "Happy Clustering!" უკეთესი თარგმანის წარმოდგენა ალბათ შეუძლებელია, მით უმეტეს, არსებული გეოპოლიტიკური სიტუაციის გათვალისწინებით.

წყარო: www.habr.com