მონაცემთა შენახვის ნიმუშები Kubernetes-ში

ჰეი ჰაბრ!

შეგახსენებთ, რომ გამოვაქვეყნეთ კიდევ ერთი უაღრესად საინტერესო და სასარგებლო книга კუბერნეტის ნიმუშების შესახებ. ეს ყველაფერი დაიწყო "შაბლონები„ბრენდან ბერნსი და, სხვათა შორის, ამ სეგმენტში გვაქვს სამუშაო ადუღებს. დღეს გეპატიჟებით წაიკითხოთ სტატია MinIO ბლოგიდან, რომელიც მოკლედ ასახავს Kubernetes-ში მონაცემთა შენახვის შაბლონების ტენდენციებსა და სპეციფიკას.

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

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

როგორც Kubernetes-ის გამოყენება იზრდება, ასევე იზრდება დაბნეულობა მისი შენახვის ნიმუშების შესახებ..

როდესაც ყველა კონკურენციას უწევს Kubernetes-ის ტორტის (ანუ მონაცემთა შენახვის) ნაჭერს, როცა საქმე მონაცემთა შენახვას ეხება, სიგნალი იხრჩობა დიდ ხმაურში.
Kubernetes განასახიერებს თანამედროვე მოდელს აპლიკაციის განვითარების, განლაგებისა და მართვისთვის. ეს თანამედროვე მოდელი აშორებს მონაცემთა შენახვას გამოთვლებისგან. Kubernetes-ის კონტექსტში განცალკევების სრულად გასაგებად, თქვენ ასევე უნდა გესმოდეთ რა არის სახელმწიფო და მოქალაქეობის არმქონე აპლიკაციები და როგორ ჯდება მონაცემთა შენახვა ამაში. ეს არის სადაც S3-ის მიერ გამოყენებული REST API მიდგომას აქვს აშკარა უპირატესობები სხვა გადაწყვეტილებების POSIX/CSI მიდგომებთან შედარებით.

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

მოქალაქეობის არმქონე კონტეინერები

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

სახელმწიფო კონტეინერები

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

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

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

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

ღრუბლოვანი აპლიკაციის დიზაინი

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

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

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

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

ამ სიტუაციის უფრო დეტალურად დათვალიერებისას აღმოვაჩენთ, რომ მონაცემთა მაღაზიის არჩევისას კვლავ და ისევ ვდგებით POSIX vs. REST API დილემის წინაშე, მაგრამ POSIX პრობლემების დამატებითი გამწვავება Kubernetes-ის გარემოს განაწილებული ბუნების გამო. Კერძოდ,

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

კონტეინერის მონაცემთა შენახვის ინტერფეისი

მიუხედავად იმისა, რომ კონტეინერის შენახვის ინტერფეისი (CSI) დიდ დახმარებას უწევდა Kubernetes მოცულობის ფენის გავრცელებას, ნაწილობრივ აუთსორსსს უწევდა მას მესამე მხარის საცავის მოვაჭრეებს, მან ასევე უნებლიედ ხელი შეუწყო რწმენას, რომ კონტეინერის სტატუსის მიდგომა არის რეკომენდებული მეთოდი. მონაცემების შენახვა Kubernetes-ში.

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

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

უკეთესი მიდგომა

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

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

• ჟურნალის მონაცემები
• დროის ანაბეჭდის მონაცემები
• ტრანზაქციის მონაცემები
• მეტამონაცემები
• კონტეინერის სურათები
• Blob (ორობითი დიდი ობიექტი) მონაცემები

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

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

სახელმწიფო განაცხადის შენახვა

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

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

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

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

ძლიერი მოძრაობა გამოთვლებიდან მონაცემების გამოყოფისკენ

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

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

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

წყარო: www.habr.com