როგორ გეხმარებათ GitLab დიდი NextCloud მეხსიერების სარეზერვო ასლის შექმნაში

ჰეი ჰაბრ!

დღეს მსურს ვისაუბრო ჩვენს გამოცდილებაზე დიდი მონაცემების სარეზერვო ასლის ავტომატიზაციის შესახებ Nextcloud საცავებიდან სხვადასხვა კონფიგურაციებში. მე ვმუშაობ სერვის სადგურად Molniya AK-ში, სადაც ვაკეთებთ IT სისტემების კონფიგურაციის მენეჯმენტს; Nextcloud გამოიყენება მონაცემთა შესანახად. მათ შორის, განაწილებული სტრუქტურით, სიჭარბით.

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

წინაისტორია

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

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

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

პირველ რიგში, მოდით შევხედოთ შეყვანის მონაცემებს. Გვჭირდება:

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

სარეზერვო ასლების მართვის პრობლემის გადასაჭრელად, ჩვენ დავაყენეთ GitLab. დამატებითი დეტალები დაძლევის მიხედვით.

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

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

სარეზერვო ინსტრუმენტები

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

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

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

სარეზერვო ასლების მართვა

Borg და Restic კარგია, მაგრამ არც ერთ პროდუქტს არ აქვს ცენტრალიზებული კონტროლის მექანიზმი. მენეჯმენტისა და კონტროლის მიზნით შევარჩიეთ უკვე დანერგილი ინსტრუმენტი, რომლის გარეშეც ვერ წარმოგვიდგენია ჩვენი სამუშაო, მათ შორის ავტომატიზაცია - ეს არის ცნობილი CI/CD - GitLab.

იდეა შემდეგია: gitlab-runner დამონტაჟებულია თითოეულ კვანძზე, რომელიც ინახავს Nextcloud მონაცემებს. მორბენალი აწარმოებს სკრიპტს გრაფიკით, რომელიც აკონტროლებს სარეზერვო პროცესს და ის იწყებს Borg-ს ან Restic-ს.

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

აქ აქ GitHub-ზე ჩვენ გამოვაქვეყნეთ სკრიპტის მაგალითები სხვადასხვა ამოცანებისთვის და საბოლოოდ მივამაგრეთ ის არა მხოლოდ Nextcloud-ის, არამედ მრავალი სხვა სერვისის სარეზერვო ასლს. ასევე არის გრაფიკი, თუ არ გსურთ მისი ხელით კონფიგურაცია (და ჩვენ არ გვინდა) და .gitlab-ci.yml

Gitlab API-ში CI/CD დროის ამოწურვის შეცვლის საშუალება ჯერ არ არის, მაგრამ ის მცირეა. უნდა გაიზარდოს, თქვით 1d.

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

ახლა შეფუთვის სკრიპტის შესახებ.

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

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

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

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

როგორ აკეთებს ამას მუშაობა

სარეზერვო კვანძზე გაშვებულია მორბენალი Bash-ის შემსრულებელით. გრაფიკის მიხედვით, სამუშაო CI/CD იხსნება სპეციალურ ტურში. მორბენალი უშვებს უნივერსალურ wrapper სკრიპტს ასეთი ამოცანებისთვის, ის ამოწმებს სარეზერვო საცავის ვალიდობას, სამონტაჟო წერტილებს და ყველაფერს, რაც ჩვენ გვინდა, შემდეგ ქმნის სარეზერვო ასლს და ასუფთავებს ძველს. თავად მზა სარეზერვო ასლი იგზავნება S3-ზე.

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

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

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

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

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

წაიკითხე რუსულად

ძირითადი ფუნქციები

• prepare სასწავლო
• testcheck მზადყოფნის შემოწმება
• maincommand ძირითადი გუნდი
• forcepostscript ფუნქცია, რომელიც შესრულებულია ბოლოს ან შეცდომით. ჩვენ ვიყენებთ მას დანაყოფის მოსახსნელად.

სერვისის ფუნქციები

• cleanup ჩვენ ვაწერთ შეცდომებს ან ვშლით ჟურნალის ფაილს.
• checklog გაანალიზეთ ჟურნალი შეცდომით ხაზის დადგომისთვის.
• ret გასასვლელი დამმუშავებელი.
• checktimeout შეამოწმეთ ტაიმაუტი.

გარემოს

• VERBOSE=1 ჩვენ დაუყოვნებლივ ვაჩვენებთ შეცდომებს ეკრანზე (stdout).
• SAVELOGSONSUCCES=1 შეინახეთ ჟურნალი წარმატების შემთხვევაში.
• INIT_REPO_IF_NOT_EXIST=1 შექმენით საცავი, თუ ის არ არსებობს. ნაგულისხმევად გამორთულია.
• TIMEOUT მაქსიმალური დრო ძირითადი ოპერაციისთვის. თქვენ შეგიძლიათ დააყენოთ ის როგორც "m", "h" ან "d" ბოლოს.

ძველი ასლების შენახვის რეჟიმი. ნაგულისხმევი:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

ცვლადები სკრიპტის შიგნით

• ERROR_STRING — სტრიქონი შეცდომის შემოწმების ჟურნალისთვის.
• EXTRACT_ERROR_STRING - გამოთქმა საჩვენებელი სტრიქონის შეცდომის შემთხვევაში.
• KILL_TIMEOUT_SIGNAL - სიგნალი მკვლელობის შესახებ, თუ დრო ამოიწურა.
• TAIL - რამდენი სტრიქონი შეცდომით ეკრანზე.
• COLORMSG - შეტყობინების ფერი (ნაგულისხმევი ყვითელი).

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

რესტიჩი ბორგის წინააღმდეგ

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

ჩვენი შერჩევის კრიტერიუმები, გარდა უკვე აღნიშნულისა (გადაწერა, სწრაფი აღდგენა და ა.შ.):

• წინააღმდეგობა დაუმთავრებელი სამუშაოს მიმართ. შეამოწმეთ მოკვლა -9.
• ზომა დისკზე.
• რესურსების მოთხოვნა (CPU, მეხსიერება).
• შენახული ბლომების ზომა.
• მუშაობა S3-თან.
• მთლიანობის შემოწმება.

ტესტირებისთვის ავიღეთ ერთი კლიენტი რეალური მონაცემებით და საერთო ზომით 1,6 ტბ.
პირობები

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

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

ქსელის გავლენის შესამცირებლად, ჩვენ გამოვიყენეთ ადგილობრივი პროვაიდერი - Yandex Cloud.

შედარების ტესტის შედეგები.

• Kill -9 შემდგომი გადატვირთვით ორივე წარმატებული იყო.
• ზომა დისკზე. ბორგს შეუძლია შეკუმშოს, ასე რომ, შედეგები მოსალოდნელია.

სარეზერვო
Размер

ბორგე
562Gb

დასვენებული
628Gb

• CPU-ით
  თავად Borg მოიხმარს ცოტას, ნაგულისხმევი შეკუმშვით, მაგრამ ის უნდა შეფასდეს გუფის პროცესთან ერთად. საერთო ჯამში, ისინი შედარებულია და იყენებენ დაახლოებით 1,2 ბირთვს იმავე სატესტო ვირტუალურ მანქანაზე.
• მეხსიერება. Restic არის დაახლოებით 0,5GB, Borg არის დაახლოებით 200MB. მაგრამ ეს ყველაფერი უმნიშვნელოა სისტემის ფაილების ქეშთან შედარებით. ამიტომ მიზანშეწონილია მეტი მეხსიერების გამოყოფა.
• ბლომების ზომაში განსხვავება გასაოცარი იყო.

სარეზერვო
Размер

ბორგე
დაახლოებით 500 მბ

დასვენებული
დაახლოებით 5 მბ

• Restic-ის S3-ის გამოცდილება შესანიშნავია. ბორგთან მუშაობა Goofys-ის საშუალებით არ აჩენს კითხვებს, მაგრამ აღინიშნა, რომ მიზანშეწონილია გააკეთოთ umount სარეზერვო ასლის დასრულების შემდეგ, რათა ქეში მთლიანად აღადგინოთ. S3-ის თავისებურება ის არის, რომ არასაკმარისად ამოტუმბული ნაწილაკები არასოდეს იგზავნება თაიგულში, რაც ნიშნავს, რომ არასრულად შევსებული მონაცემები იწვევს დიდ ზიანს.
• მთლიანობის შემოწმება ორივე შემთხვევაში კარგად მუშაობს, მაგრამ სიჩქარე მნიშვნელოვნად განსხვავდება.
  რესტიკი 3,5 საათი.
  Borg, 100 GB SSD ფაილის ქეშით – 5 საათი.დაახლოებით იგივე სიჩქარის შედეგია, თუ მონაცემები ლოკალურ დისკზეა.
  Borg კითხულობს პირდაპირ S3-დან ქეშის გარეშე 33 საათი. ამაზრზენად გრძელი.

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

ბოლო, მაგრამ არანაკლებ მნიშვნელოვანი არჩევანი იყო საზოგადოების ზომა.

და ჩვენ ავირჩიეთ ბორგი.

რამდენიმე სიტყვა შეკუმშვის შესახებ

ბორგს აქვს შეკუმშვის შესანიშნავი ალგორითმი თავის არსენალში - zstd. შეკუმშვის ხარისხი არ არის უარესი, ვიდრე gzip, მაგრამ ბევრად უფრო სწრაფი. და სიჩქარით შედარებით ნაგულისხმევი lz4.

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

Borg-ს აქვს საკმაოდ ბონუსური შეკუმშვის რეჟიმი - თუ ფაილს აქვს მაღალი ენტროპია, მაშინ შეკუმშვა საერთოდ არ გამოიყენება, რაც ზრდის სიჩქარეს. ჩართულია ოფციით შექმნისას
-C auto,zstd
zstd ალგორითმისთვის
ასე რომ, ამ პარამეტრით, ნაგულისხმევი შეკუმშვის შედარებით, მივიღეთ
560 გბ და 562 გბ შესაბამისად. ზემოთ მოყვანილი მაგალითის მონაცემები შეგახსენებთ, შეკუმშვის გარეშე შედეგი არის 628 გბ. 2 GB სხვაობის შედეგმა გარკვეულწილად გაგვაოცა, მაგრამ ჩვენ ვიფიქრეთ, რომ მას ავირჩევდით. auto,zstd.

სარეზერვო გადამოწმების მეთოდი

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

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

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

მასშტაბურობა მიიღწევა მორბენალთა გაშვებით სხვადასხვა კვანძზე სხვადასხვა ტეგებით.
ჩვენი მონიტორინგი აგროვებს სარეზერვო სტატუსებს GitLab API-ის მეშვეობით ერთ ფანჯარაში; საჭიროების შემთხვევაში, პრობლემები ადვილად შესამჩნევი და ლოკალიზებულია.

დასკვნა

შედეგად, ჩვენ ზუსტად ვიცით, რომ ვაკეთებთ სარეზერვო ასლებს, რომ ჩვენი სარეზერვო ასლები მოქმედებს, მათთან წარმოქმნილი პრობლემები ცოტა დრო სჭირდება და მოგვარებულია მოვალეობის შემსრულებელი ადმინისტრატორის დონეზე. სარეზერვო ასლები ძალიან ცოტა ადგილს იკავებს tar.gz-თან ან Bacula-სთან შედარებით.

წყარო: www.habr.com