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

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

მოცემული: არის ლოკალური S3 საცავი, არის Veritas NetBackup, რომელმაც შეიძინა ახალი გაფართოებული ფუნქციონალობა ობიექტების საცავში მონაცემების გადასატანად, ახლა დედუპლიკაციის მხარდაჭერით და ამ ლოკალურ საცავში არის თავისუფალი სივრცის პრობლემა.

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

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

სურათზე ჩანს, რა მივედით:

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

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

სარეზერვო ჟურნალი მათთვის, ვინც მზად არის წაიკითხოს ნაგავსაყრელის ნახევარი გვერდისავსეა ხელახალი სკანირებით
Dec 18, 2018 12:09:43 PM — ინფორმაცია bpbkar (pid=4452) ამაჩქარებელმა სერვერზე გაგზავნა 14883996160 ბაიტი 14883994624 ბაიტიდან, ოპტიმიზაცია 0.0%
18 დეკემბერი, 2018 12:10:07 PM - ინფორმაცია NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; ანგარიში=PDDO სტატისტიკა (გამოყენებული მრავალ ნაკადის ნაკადი) (NBCC): დასკანირებული: 14570817 კბ, CR გაგზავნილი: 1760761 კბ, CR გაგზავნილი FC: 0 კბაიტი, წაშლა: 87.9%, ქეში გამორთულია

სრული
Dec 18, 2018 12:13:18 PM — ინფორმაცია bpbkar (pid=2864) ამაჩქარებელმა სერვერზე გაგზავნა 181675008 ბაიტი 14884060160 ბაიტიდან, ოპტიმიზაცია 98.8%
18 დეკ, 2018 12:13:40 PM - ინფორმაცია NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; ანგარიში=PDDO სტატისტიკა (NBCC): დასკანირებული: 14569706 KB, CR გაგზავნილი: 45145 KB, CR გაგზავნილი FC: 0 KB, ამოღება: 99.7%, ქეში გამორთულია

ზრდადი
2018 წლის 18 დეკემბერი, 12:15:32 PM — ინფო bpbkar (pid=792) ამაჩქარებელმა სერვერზე გაგზავნა 14726108160 ბაიტიდან 9970688 ბაიტი, ოპტიმიზაცია 99.9%
2018 წლის 18 დეკემბერი, 12:15:53 ​​​​PM - ინფორმაცია NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; ანგარიში=PDDO სტატისტიკა (NBCC): სკანირებული: 14383788 კბ, გაგზავნილი CR: 15700 კბ, FC-ზე გაგზავნილი CR: 0 კბ, dedup: 99.9%, ქეში გამორთულია

სრული
Dec 18, 2018 12:18:02 PM — ინფორმაცია bpbkar (pid=3496) ამაჩქარებელმა სერვერზე გაგზავნა 171746816 ბაიტი 14884093952 ბაიტიდან, ოპტიმიზაცია 98.8%
18 დეკ, 2018 12:18:24 PM - ინფორმაცია NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; ანგარიში=PDDO სტატისტიკა (NBCC): დასკანირებული: 14569739 KB, CR გაგზავნილი: 34120 KB, CR გაგზავნილი FC: 0 KB, ამოღება: 99.8%, ქეში გამორთულია

Რა არის პრობლემა

მომხმარებლებს სურთ რაც შეიძლება ხშირად შექმნან სარეზერვო ასლები და შეინახონ ისინი რაც შეიძლება იაფად. უმჯობესია შეინახოთ ისინი იაფად ობიექტების საცავებში, როგორიცაა S3, რადგან ისინი ყველაზე იაფია თითო მეგაბაიტზე მომსახურების საფასურად, საიდანაც შეგიძლიათ გონივრულ დროში დააბრუნოთ სარეზერვო ასლი. როდესაც ბევრი სარეზერვო საშუალებაა, ის არც თუ ისე იაფი ხდება, რადგან მეხსიერების უმეტესი ნაწილი დაკავებულია იმავე მონაცემების ასლებით. თურქი კოლეგების HaaS-ის შემთხვევაში, შენახვა შეიძლება გამკვრივდეს დაახლოებით 80-90%-ით. გასაგებია, რომ ეს კონკრეტულად მათ სპეციფიკას ეხება, მაგრამ მე აუცილებლად 50% მაინც ბაბუას ვითვლიდი.

პრობლემის გადასაჭრელად, მთავარმა გამყიდველებმა დიდი ხანია შექმნეს კარიბჭეები Amazon S3-ზე. მათი ყველა მეთოდი თავსებადია ადგილობრივ S3-თან, რამდენადაც ისინი მხარს უჭერენ Amazon API-ს. თურქეთის მონაცემთა ცენტრში სარეზერვო ასლი მზადდება ჩვენს S3-ზე, ისევე როგორც რუსეთში T-III "კომპრესორში", რადგან ამ სამუშაო სქემამ კარგად იმუშავა ჩვენთან.

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

Veritas NetBackup-მა დაამატა CloudCatalyst ფუნქცია:

ანუ, სარეზერვო ასლის შექმნის საჭირო მანქანებსა და კარიბჭეს შორის შუალედური განთავსდა. Linux- სერვერი, რომელიც ამუშავებს SRK აგენტებიდან მიღებულ სარეზერვო ტრაფიკს და ახდენს მის დედუპლიკაციას S3-ზე გადატანამდე. ადრე არსებობდა 30 20 GB შეკუმშული სარეზერვო ასლი, მაგრამ ახლა (მანქანების მსგავსების გამო) მათი მოცულობა 90%-ით შემცირდა. გამოიყენება იგივე დედუპლიკაციის ძრავა, რაც ჩვეულებრივ დისკებზე Netbackup-ის გამოყენებით შენახვისთვის.

აი, რა ხდება შუალედურ სერვერამდე:

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

ჟურნალები228 ვაკანსია (0 რიგში 0 აქტიური 0 ელოდება ხელახლა ცდას 0 შეჩერებულია 0 არასრული 228 შესრულებულია — 13 არჩეულია)
(ფილტრი გამოყენებულია [13])

სამუშაოს ID ტიპი სახელმწიფო მდგომარეობის დეტალები სტატუსი სამუშაო პოლიტიკა სამუშაო განრიგი კლიენტი მედია სერვერი დაწყების დრო გასული დრო დასრულების დრო შენახვის ერთეული მცდელობა ოპერაცია Kilobytes ფაილების სახელი % დასრულებული (სავარაუდო) ვაკანსიის PID მფლობელის კოპირება მშობლის სამუშაო ID KB/წმ აქტიური დაწყება აქტიური გასული Sebot Robot Vault პროფილი ID მედიის ამოსაღებად მონაცემთა გადაადგილების გარეშე ჰოსტის ტიპი ძირითადი პრიორიტეტი დუბლირების სიჩქარე ტრანსპორტის ამაჩქარებლის ოპტიმიზაციის მაგალითი ან მონაცემთა ბაზის გაზიარების ჰოსტი
— 1358 Snapshot Done 0 VMware — NGNCloudADC NBCC 18 დეკ., 2018 12:16:19 PM 00:02:18 18 დეკ. :2018:12 PM 18:37:3 მყისიერი აღდგენის დისკი სტანდარტული WIN-*********** 1
1360 სარეზერვო ასლი შესრულებულია 0 VMware სრული NGNCloudADC NBCC 18 დეკ., 2018 12:16:48 PM 00:01:39 18 დეკ. 2018 12 18 დეკ , 27 3:1:14,535,248 PM 149654:100:23858 მყისიერი აღდგენის დისკი სტანდარტული WIN-*********** 1358 335,098% 18%
1352 სნეპშოტი შესრულებულია 0 VMware - NGNCloudADC NBCC 18 დეკ, 2018 12:14:04 PM 00:02:01 18 დეკ, 2018 12:16:05 PM STU_DP_S3_**** სარეზერვო ასლი 1 100 Dec 1352%c 18:2018 PM 12:14:14 მყისიერი აღდგენის დისკი სტანდარტული WIN-*********** 00
1354 სარეზერვო ასლის შექმნა დასრულდა 0 VMware Incremental NGNCloudADC NBCC 2018 წლის 18 დეკემბერი, 12:14:34 PM 00:01:21 2018 წლის 18 დეკემბერი, 12:15:55 PM STU_DP_S3_****სარეზერვო ასლი 1 14,380,965 147 100% 23617 root 1352 500,817 2018 წლის 18 დეკემბერი, 12:14:34 PM 00:01:21 მყისიერი აღდგენის დისკი სტანდარტული WIN-************ 0 99.9% 100%
1347 სნეპშოტი შესრულებულია 0 VMware - NGNCloudADC NBCC 18 დეკ, 2018 12:11:45 PM 00:02:08 18 დეკ, 2018 12:13:53 PM STU_DP_S3_**** სარეზერვო ასლი 1 100 Dec 1347%c 18:2018 PM 12:11:45 მყისიერი აღდგენის დისკი სტანდარტული WIN-*********** 00
1349 სარეზერვო ასლი შესრულებულია 0 VMware სრული NGNCloudADC NBCC 18 დეკ., 2018 12:12:02 PM 00:01:41 18 დეკ. 2018 12 13 დეკ , 43 3:1:14,535,215 PM 149653:100:23508 მყისიერი აღდგენის დისკი სტანდარტული WIN-*********** 1347 316,319% 18%
1341 სნეპშოტი შესრულებულია 0 VMware - NGNCloudADC NBCC 18 დეკ, 2018 12:05:28 PM 00:04:53 18 დეკ, 2018 12:10:21 PM STU_DP_S3_**** სარეზერვო ასლი 1 100 Dec 1341%c 18:2018 PM 12:05:28 მყისიერი აღდგენის დისკი სტანდარტული WIN-*********** 00
1342 სარეზერვო ასლი შესრულებულია 0 VMware Full_Rescan NGNCloudADC NBCC 18 დეკ., 2018 12:05:47 PM 00:04:24 18 დეკ, 2018 12:10:11 PM STU_DP_S3_**** 1% 14,535,151% 149653:100:22999 1341 root 70,380 18 2018 დეკ 12, 05 47:00:04 PM 24:0:87.9 მყისიერი აღდგენის დისკი სტანდარტული WIN-*********** 0 XNUMX% XNUMX%

1339 Snapshot შესრულებულია 150 VMware - NGNCloudADC NBCC 18 დეკ., 2018 11:05:46 AM 00:00:53 18 დეკ. 2018:11 AM 06:39:3 მყისიერი აღდგენის დისკი სტანდარტული WIN-*********** 1
1327 Snapshot Done 0 VMware - *******.********.cloud NBCC 17 დეკ, 2018 12:54:42 PM 05:51:38 17 დეკ, 2018 6:46:20 PM STU_DP_S3_****სარეზერვო 1 100% root 1327 17 დეკ, 2018 12:54:42 PM 05:51:38 მყისიერი აღდგენის დისკი სტანდარტული WIN-*********** 0
1328 სარეზერვო ასლი შესრულებულია 0 VMware სრული ******************.cloud NBCC 17 დეკ, 2018 12:55:10 PM 05:29:21 17 დეკ, 2018 6:24:31 PM STU_DP_S3_****სარეზერვო 1 222,602,719 258932 100% 12856 root 1327 11,326 Dec 17, 2018 12:55:10 PM 05:29:21 მყისიერი აღდგენა 0 87.9 სტანდარტი ****0% დისკი. XNUMX%
1136 Snapshot Done 0 VMware - *******.********.cloud NBCC 14 დეკ, 2018 4:48:22 PM 04:05:16 14 დეკ, 2018 8:53:38 PM STU_DP_S3_****სარეზერვო 1 100% root 1136 14 დეკ, 2018 4:48:22 PM 04:05:16 მყისიერი აღდგენის დისკი სტანდარტული WIN-*********** 0
1140 სარეზერვო ასლი შესრულებულია 0 VMware Full_Scan *******.********.cloud NBCC 14 დეკ, 2018 4:49:14 PM 03:49:58 14 დეკ, 2018 8:39:12 PM STU_DP_S3_****სარეზერვო 1 217,631,332 255465 100% 26438 root 1136 15,963 14 დეკ, 2018 4:49:14 PM 03:49:58 მყისიერი აღდგენა *** სტანდარტული აღდგენის დისკი *** 0 სტანდარტი 45.2 0%

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

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

სრული არქიტექტურა ასე გამოიყურება:

1. მასტერ სერვერი მართავს კონფიგურაციას, განახლებებს და ა.შ. და მდებარეობს ღრუბელში.
2. მედია სერვერი (შუალედური *nix მანქანა) უნდა განთავსდეს ყველაზე ახლოს ზედმეტ სისტემებთან ქსელის ხელმისაწვდომობის თვალსაზრისით. აქ კეთდება სარეზერვო ასლების დედუბლირება ყველა რეზერვირებული აპარატიდან.
3. სარეზერვო მოწყობილობებზე არის აგენტები, რომლებიც ზოგადად აგზავნიან მედია სერვერზე მხოლოდ იმას, რაც არ არის მის საცავში.

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

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

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

აი, როგორ გამოიყურება:

და აი კიდევ ერთი მორების ნაჭერი169 ვაკანსია (0 რიგში 0 აქტიური 0 ელოდება ხელახლა ცდას 0 შეჩერებულია 0 არასრული 169 შესრულებულია — 1 არჩეულია)

სამუშაოს ID ტიპი სახელმწიფო მდგომარეობის დეტალები სტატუსი სამუშაო პოლიტიკა სამუშაო განრიგი კლიენტი მედია სერვერი დაწყების დრო გასული დრო დასრულების დრო შენახვის ერთეული მცდელობა ოპერაცია Kilobytes ფაილების სახელი % დასრულებული (სავარაუდო) ვაკანსიის PID მფლობელის კოპირება მშობლის სამუშაო ID KB/წმ აქტიური დაწყება აქტიური გასული Sebot Robot Vault პროფილი ID მედიის ამოსაღებად მონაცემთა გადაადგილების გარეშე ჰოსტის ტიპი ძირითადი პრიორიტეტი დუბლირების სიჩქარე ტრანსპორტის ამაჩქარებლის ოპტიმიზაციის მაგალითი ან მონაცემთა ბაზის გაზიარების ჰოსტი
- 1372 აღდგენა შესრულებულია 0 NBPR01 NBCC 19 დეკემბერი, 2018 1:05:58 PM 00:04:32 დეკ 19, 2018 1:10:30 PM 1 14,380,577 1 100% OT 8548c 1372:70,567 :19 PM 2018:1:06 WIN-************ 00

მონაცემთა მთლიანობა უზრუნველყოფილია თავად S3-ის დაცვით - იქ არის კარგი სიჭარბე, რათა დავიცვათ ტექნიკის გაუმართაობისგან, როგორიცაა მკვდარი მყარი დისკის spindle.

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

სულ

როდესაც პარტნიორმა ჩააგდო 3 GB ჩვენს S20-ში, ჩვენ ვინახავდით 60 GB, რადგან ჩვენ ვუზრუნველყოფთ მონაცემთა სამმაგ გეო-რეზერვაციას. ახლა გაცილებით ნაკლები ტრეფიკია, რაც კარგია როგორც არხისთვის, ასევე შენახვის ტარიფებისთვის.

ამ შემთხვევაში, მარშრუტები „დიდი ინტერნეტის“ გავლით იკეტება, მაგრამ შესაძლებელია ტრაფიკის გადატანა VPN L2 ინტერნეტით, მაგრამ უმჯობესია მედია სერვერის ინსტალაცია პროვაიდერის შეყვანამდე.

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

წყარო: www.habr.com