შენახვა Kubernetes-ში: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

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

მართალი გითხრათ, დავნებდი და დავნებდი კუბერნეტები (ყოველ შემთხვევაში, ჯერჯერობით). გამოვიყენებ Heroku. რატომ? შენახვის გამო! ვინ იფიქრებდა, რომ მე უფრო მეტს ვიზამდი შენახვაზე, ვიდრე თავად კუბერნეტესთან. მე ვიყენებ ჰეცნერის ღრუბელირადგან ეს იაფია და შესრულება კარგია და თავიდანვე ვაყენებდი კლასტერებს Rancher. მე არ მიცდია მართული Kubernetes სერვისები Google/Amazon/Microsoft/DigitalOcean და ა.შ. და ა.შ., რადგან მინდოდა ყველაფერი მესწავლა მე თვითონ. მეც ეკონომიური ვარ.

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

მე გამოვცადე 6-7 შენახვის გადაწყვეტა:

OpenEBS

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

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

როქი

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

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

Rancher Longhorn

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

StorageOS

StorageOS არის პირველი ფასიანი პროდუქტი სიაში. მას აქვს დეველოპერის ვერსია 500 GB შეზღუდული მართული მეხსიერების ზომით, მაგრამ არა მგონია, რომ კვანძების რაოდენობაზე შეზღუდვა იყოს. გაყიდვების განყოფილებაში მითხრეს, რომ 125 ტბ-ის ღირებულება თვეში 1 დოლარიდან იწყება, თუ სწორად მახსოვს. არის ძირითადი დაფა და მოსახერხებელი CLI, მაგრამ რაღაც უცნაური ხდება შესრულებასთან დაკავშირებით: ზოგიერთ კრიტერიუმში ის საკმაოდ წესიერია, მაგრამ მოცულობის სტრესის ტესტში სიჩქარე საერთოდ არ მომეწონა. ზოგადად, არ ვიცი რა ვთქვა. ასე რომ, მე ნამდვილად ვერ გავიგე ბევრი. აქ არ არის გარე სარეზერვო ასლები და თქვენ ასევე მოგიწევთ გამოიყენოთ Velero Restic-თან ერთად ტომების სარეზერვო ასლისთვის. უცნაურია, რადგან პროდუქტი ფასიანია. და დეველოპერებს არ სურდათ Slack-ზე კომუნიკაცია.

რობინ

რობინის შესახებ Reddit-ზე გავიგე მათი ტექნიკური დირექტორისგან. აქამდე მის შესახებ არასოდეს მსმენია. შეიძლება იმიტომ, რომ ვეძებდი უფასო გადაწყვეტილებებს, მაგრამ რობინს ფასიანია. მათ აქვთ საკმაოდ დიდსულოვანი უფასო ვერსია 10 ტბ მეხსიერებით და სამი კვანძით. მთლიანობაში, პროდუქტი საკმაოდ წესიერია და აქვს კარგი მახასიათებლები. არის შესანიშნავი CLI, მაგრამ ყველაზე მაგარი ის არის, რომ თქვენ შეგიძლიათ გადაიღოთ მთელი აპლიკაცია და შექმნათ სარეზერვო ასლი (რესურსების ამომრჩეველში ამას ჰქვია Helm releases ან “flex apps”), ტომების და სხვა რესურსების ჩათვლით, ასე რომ თქვენ შეგიძლიათ გააკეთოთ Velero-ს გარეშე. და ყველაფერი მშვენიერი იქნებოდა, რომ არა ერთი პატარა დეტალი: თუ აღადგენთ (ან „იმპორტს“, როგორც ამას რობინში უწოდებენ) აპლიკაციას ახალ კლასტერზე - მაგალითად, კატასტროფისგან გამოჯანმრთელების შემთხვევაში - აღდგენა, რა თქმა უნდა, მუშაობს, მაგრამ განაგრძეთ აპლიკაციის სარეზერვო ასლის შექმნა აკრძალულია. ეს უბრალოდ შეუძლებელია ამ გამოშვებაში, როგორც დეველოპერებმა დაადასტურეს. ეს, რბილად რომ ვთქვათ, უცნაურია, განსაკუთრებით სხვა უპირატესობების გათვალისწინებით (მაგალითად, წარმოუდგენლად სწრაფი სარეზერვო ასლები და აღდგენა). დეველოპერები გპირდებიან, რომ ყველაფერს მოაგვარებენ მომდევნო გამოშვებისთვის. შესრულება ზოგადად კარგია, მაგრამ მე შევამჩნიე უცნაურობა: თუ ბენჩმარკს პირდაპირ ჰოსტზე მიმაგრებულ ტომზე გავუშვი, წაკითხვის სიჩქარე ბევრად უფრო სწრაფია, ვიდრე იგივე ხმის გაშვება პოდიდან. ყველა სხვა შედეგი იდენტურია, მაგრამ თეორიულად განსხვავება არ უნდა იყოს. მიუხედავად იმისა, რომ ამაზე მუშაობენ, მე აღშფოთებული ვიყავი აღდგენისა და სარეზერვო ასლის პრობლემაზე - მეგონა, საბოლოოდ ვიპოვე შესაფერისი გამოსავალი და მზად ვიყავი გადამეხადა ის, როცა მეტი სივრცე ან მეტი სერვერი დამჭირდებოდა.

პორტვორქსი

აქ ბევრი არაფერი მაქვს სათქმელი. ეს ფასიანი პროდუქტია, თანაბრად მაგარი და ძვირი. შესრულება უბრალოდ გასაოცარია. ეს ჯერჯერობით საუკეთესო მაჩვენებელია. Slack-მა მითხრა, რომ ფასი იწყება თვეში $205-დან თითო კვანძზე, როგორც ეს მითითებულია Google-ის GKE Marketplace-ში. არ ვიცი იაფი იქნება თუ პირდაპირ იყიდი. მე არ შემიძლია ამის საშუალება მაინც, ამიტომ ძალიან, ძალიან იმედგაცრუებული ვიყავი, რომ დეველოპერის ლიცენზია (1 TB-მდე და 3 კვანძამდე) პრაქტიკულად გამოუსადეგარია Kubernetes-თან, თუ თქვენ არ ხართ კმაყოფილი სტატიკური უზრუნველყოფით. იმედი მქონდა, რომ მოცულობის ლიცენზია ავტომატურად დაქვეითდებოდა დეველოპერამდე საცდელი პერიოდის ბოლოს, მაგრამ ეს ასე არ მოხდა. დეველოპერის ლიცენზიის გამოყენება შესაძლებელია მხოლოდ Docker-თან უშუალოდ, ხოლო Kubernetes-ში კონფიგურაცია ძალიან რთული და შეზღუდულია. რა თქმა უნდა, ღია წყაროს მირჩევნია, მაგრამ ფული რომ მქონდეს, აუცილებლად ავირჩევდი პორტვორქსს. ჯერჯერობით, მისი შესრულება უბრალოდ არ შეედრება სხვა ვარიანტებს.

ლინსტორი

ეს განყოფილება პოსტის გამოქვეყნების შემდეგ დავამატე, როდესაც მკითხველმა Linstor-ის გამოცდა შემომთავაზა. ვცადე და მომეწონა! თუმცა, კიდევ უფრო უნდა ჩავუღრმავდე. ახლა შემიძლია ვთქვა, რომ შესრულება საკმაოდ კარგია (ქვემოთ დავამატე ბენჩმარკინგის შედეგები). სინამდვილეში, იგივე შესრულება მივიღე, რაც პირდაპირი დისკის ბენჩმარკინგის შემთხვევაში, ყოველგვარი დამატებითი ხარჯების გარეშე. (ნუ მკითხავთ, რატომ არის Portworx-ის ციფრები უკეთესი პირდაპირი დისკის ბენჩმარკთან შედარებით. წარმოდგენა არ მაქვს. ალბათ, ჯადოსნურია.) ასე რომ, Linstor ჯერჯერობით ძალიან ეფექტური ჩანს. მისი დაყენება არც ისე რთულია, მაგრამ არც ისე ადვილია, როგორც სხვა ვარიანტები. პირველ რიგში, მომიწია Linstor-ის (ბირთვული მოდული და ინსტრუმენტები/სერვისები) ინსტალაცია და LVM-ის დაყენება თხელი რესურსებისა და სნეპშოტის მხარდაჭერისთვის Kubernetes-ის გარეთ, პირდაპირ ჰოსტზე, შემდეგ კი Kubernetes-დან საცავის გამოსაყენებლად საჭირო რესურსების შექმნა. არ ვიყავი კმაყოფილი, რომ ის არ მუშაობდა. CentOS და გამოყენება მოუწია Ubuntuრა თქმა უნდა, ეს დიდი პრობლემა არ არის, მაგრამ ცოტა შემაწუხებელია, რადგან დოკუმენტაციაში (სხვათა შორის, რომელიც შესანიშნავია) ნახსენებია რამდენიმე პაკეტი, რომლებიც არ არის ხელმისაწვდომი მითითებულ Epel-ის საცავებში. Linstor-ს აქვს სნეპშოტები, მაგრამ არა საიტის გარეთ სარეზერვო ასლები, ამიტომ მოცულობის სარეზერვო ასლებისთვის კვლავ მომიწია Velero-ს გამოყენება Restic-თან ერთად. ფაილის დონის სარეზერვო ასლებს სნეპშოტები ვამჯობინებდი, მაგრამ ეს ასატანია, თუ გადაწყვეტა ეფექტური და საიმედოა. Linstor ღია კოდის პროგრამაა, მაგრამ აქვს ფასიანი მხარდაჭერა. თუ სწორად გავიგე, შეგიძლიათ გამოიყენოთ იგი შეზღუდვების გარეშე, მაშინაც კი, თუ არ გაქვთ მხარდაჭერის კონტრაქტი, მაგრამ ეს უნდა გადავამოწმო. არ ვიცი, რამდენად არის Linstor გამოცდილი Kubernetes-ისთვის, მაგრამ თავად შენახვის ფენა Kubernetes-ის გარეთაა და როგორც ჩანს, ის უკვე დიდი ხანია არსებობს, ამიტომ ის ალბათ უკვე გამოცდილია რეალურ პირობებში. არის აქ გამოსავალი, რომელიც მაიძულებს გადავწყვიტო აზრი და დავუბრუნდე Kubernetes-ს? არ ვიცი. ცოტა მეტი უნდა გამოვიძიო და რეპლიკაციის შესახებ ვისწავლო. ვნახოთ. თუმცა პირველი შთაბეჭდილება კარგია. მეტი თავისუფლებისა და ახალი რაღაცეების შესასწავლად, ნამდვილად მირჩევნია Heroku-ს ნაცვლად ჩემივე Kubernetes კლასტერები გამოვიყენო. რადგან Linstor-ის ინსტალაცია სხვებისგან განსხვავებით მარტივი არ არის, ამაზე მალე პოსტს დავწერ.

ნიშნული

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

მოცულობის საორიენტაციოდ მე გამოვიყენე ეს მანიფესტი:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: dbench
spec:
  storageClassName: ...
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
  name: dbench
spec:
  template:
    spec:
      containers:
      - name: dbench
        image: sotoaster/dbench:latest
        imagePullPolicy: IfNotPresent
        env:
          - name: DBENCH_MOUNTPOINT
            value: /data
          - name: FIO_SIZE
            value: 1G
        volumeMounts:
        - name: dbench-pv
          mountPath: /data
      restartPolicy: Never
      volumes:
      - name: dbench-pv
        persistentVolumeClaim:
          claimName: dbench
  backoffLimit: 4

ჯერ შევქმენი ტომი შესაბამისი შესანახი კლასით და შემდეგ დავასრულე ფიო კულისებში. 1 GB დამჭირდა შესრულების შესაფასებლად და დიდხანს არ დაველოდე. აქ არის შედეგები:

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

დასკვნა

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

წყარო: www.habr.com