Qrator ფილტრაციის ქსელის კონფიგურაციის მართვის სისტემა

TL; DR: ჩვენი შიდა ქსელის კონფიგურაციის მართვის სისტემის კლიენტ-სერვერის არქიტექტურის აღწერა, QControl. იგი ეფუძნება ორ ფენის სატრანსპორტო პროტოკოლს, რომელიც მუშაობს gzip-ით შეფუთული შეტყობინებებით ბოლო წერტილებს შორის დეკომპრესიის გარეშე. განაწილებული მარშრუტიზატორები და ბოლო წერტილები იღებენ კონფიგურაციის განახლებებს და თავად პროტოკოლი იძლევა ლოკალიზებული შუალედური რელეების დაყენების საშუალებას. სისტემა აგებულია პრინციპზე დიფერენციალური სარეზერვო („უკანასკნელ-სტაბილური“, ახსნილი ქვემოთ) და იყენებს JMESpath შეკითხვის ენას Jinja შაბლონის ძრავასთან ერთად კონფიგურაციის ფაილების გასაფორმებლად.

Qrator Labs ახორციელებს გლობალურად განაწილებულ თავდასხმის შერბილების ქსელს. ჩვენი ქსელი მუშაობს anycast პრინციპით და ქვექსელების რეკლამირება ხდება BGP-ის საშუალებით. როგორც BGP anycast ქსელი, რომელიც ფიზიკურად მდებარეობს დედამიწის რამდენიმე რეგიონში, ჩვენ შეგვიძლია დავამუშავოთ და გავფილტროთ არალეგიტიმური ტრაფიკი უფრო ახლოს ინტერნეტის ბირთვთან - Tier-1 ოპერატორებთან.

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

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

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

შედეგად, ჩვენ მივიღეთ შემდეგი სქემა:

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

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

MTR პრაღიდან სინგაპურამდე

იგივე ეხება ჰონგ კონგს

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

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

ბოლო სტაბილური დიზაინი

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

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

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

ორდონიანი ტრანსპორტის არქიტექტურა

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

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

ჩვენ ავირჩიეთ Thrift Framework RPC-ის და მრავალი ენის მხარდაჭერის გამო. როგორც ყოველთვის, მარტივი ნაწილები იყო კლიენტი და სერვერი. თუმცა, როუტერი ხისტი თხილი აღმოჩნდა, ნაწილობრივ ჩვენი განვითარების დროს მზა ხსნარის არარსებობის გამო.

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

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

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

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

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

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

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

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

მაგალითად:

---
selector: "[@][[email protected]._meta.version == `42`] | items([0].fft_config || `{}`)"
destination_filename: "fft/{{ match[0] }}.json"
file_mode: 0644
reload_daemons: [fft] ...
{{ dict(match[1]) | json(indent=2, sort_keys=True) }}


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

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

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

მადლობა მასალის დაწერაში დახმარებისთვის. ვოლანდამროდი, სერენჰაიტი, NoN.

ინგლისური ვერსია პოსტი.

წყარო: www.habr.com