ობიექტების შენახვა უკანა ოთახში, ან როგორ გახდეთ თქვენი საკუთარი სერვისის პროვაიდერი

1996 წელს მსოფლიომ იხილა ობიექტების შენახვის პირველი პროტოტიპი. 10 წელიწადში Amazon Web Services გამოუშვებს Amazon S3-ს და მსოფლიო სისტემატურად დაიწყებს გიჟობას ბრტყელი მისამართის სივრცით. მეტამონაცემებთან მუშაობისა და დატვირთვის ქვეშ შემცირების გარეშე მასშტაბირების წყალობით, ობიექტების შენახვა სწრაფად გახდა სტანდარტი ღრუბლოვანი მონაცემთა შენახვის სერვისების უმეტესობისთვის და არა მხოლოდ. კიდევ ერთი მნიშვნელოვანი თვისება ის არის, რომ ის კარგად არის შესაფერისი არქივების და მსგავსი იშვიათად გამოყენებული ფაილების შესანახად. ყველა, ვინც ჩართული იყო მონაცემთა შენახვაში, გაიხარა და ხელში ეცვა ახალი ტექნოლოგია.

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

ამიტომ, დღეს ჩვენ გავარკვევთ, თუ რა ვარიანტები არსებობს "ისე რომ ეს იყოს როგორც მოზრდილები, არა CEPH და უფრო დიდი ფაილი", ჩვენ განვათავსებთ ერთ-ერთ მათგანს და შევამოწმებთ, რომ ყველაფერი მუშაობს Veeam Backup & Replication-ის გამოყენებით. ის აცხადებს, რომ მხარს უჭერს მუშაობას S3-თან თავსებად საცავებთან და ჩვენ შევამოწმებთ ამ პრეტენზიას.

რაც შეეხება სხვებს?

მე გთავაზობთ დავიწყოთ ბაზრისა და ობიექტების შენახვის ვარიანტების მცირე მიმოხილვით. ზოგადად აღიარებული ლიდერი და სტანდარტი არის Amazon S3. ორი უახლოესი მდევნელია Microsoft Azure Blob Storage და IBM Cloud Object Storage.

Სულ ეს არის? მართლა არ არსებობს სხვა კონკურენტები? რა თქმა უნდა, არსებობენ კონკურენტები, მაგრამ ზოგიერთი მიდის თავის გზაზე, როგორიცაა Google Cloud ან Oracle Cloud Object Storage, S3 API-ს არასრული მხარდაჭერით. ზოგი იყენებს API-ს უფრო ძველ ვერსიებს, როგორიცაა Baidu Cloud. ზოგი კი, Hitachi Cloud-ის მსგავსად, განსაკუთრებულ ლოგიკას მოითხოვს, რაც აუცილებლად გამოიწვევს საკუთარ სირთულეებს. ნებისმიერ შემთხვევაში, ყველას ადარებენ ამაზონს, რომელიც შეიძლება ჩაითვალოს ინდუსტრიის სტანდარტად.

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

ბევრი გამოსავალი შეესაბამება ამ მარტივ პირობებს. მაგალითად, კლასიკური კორპორატიული მძიმე წონა:

• DellEMC ECS
• NetApp S3 StorageGrid
• Nutanix თაიგულები
• სუფთა შენახვის FlashBlade და StorReduce
• Huawei FusionStorage

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

• წითელი ქუდი ცეფი
• SUSE Enterprise Storage
• ღრუბლიანი

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

• CEPH მისი სუფთა სახით
• Minio (Linux ვერსია, რადგან ბევრი კითხვაა Windows-ის ვერსიასთან დაკავშირებით)

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

ჩვენი სტენდის აწყობა

საცდელი საგნის არჩევაზე მინდა ცოტა ვისაუბრო.

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

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

ყოველივე ზემოთქმულიდან გამომდინარე, ჩემი არჩევანი დაეცა Dell EMC ECS Community Edition. ეს ძალიან საინტერესო პროექტია და საჭიროდ მიმაჩნია მოგიყვეთ ამის შესახებ.

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

გახსოვდეთ:

!!!Community Edition არის ცალკე პროექტი, შექმნილი ტესტირებისთვის და Dell-ის ტექნიკური მხარდაჭერის გარეშე!!
და ის არ შეიძლება გადაიქცეს სრულფასოვან ECS-ად, თუნდაც ძალიან გინდოდეს.

გავიგოთ

ბევრს მიაჩნია, რომ Dell EMC ECS თითქმის საუკეთესო გამოსავალია, თუ თქვენ გჭირდებათ ობიექტების შენახვის საჭიროება. ყველა პროექტი ECS ბრენდის ქვეშ, მათ შორის კომერციული და კორპორატიული, ეფუძნება github. ერთგვარი კეთილი ნების ჟესტი Dell-ისგან. და პროგრამული უზრუნველყოფის გარდა, რომელიც მუშაობს მათ ბრენდირებულ აპარატურაზე, არის ღია კოდის ვერსია, რომელიც შეიძლება განთავსდეს ღრუბელში, ვირტუალურ მანქანაზე, კონტეინერში ან თქვენს ნებისმიერ მოწყობილობაზე. წინსვლისას, არსებობს OVA ვერსიაც კი, რომელსაც ჩვენ გამოვიყენებთ.
თავად DELL ECS Community Edition არის სრულფასოვანი პროგრამული უზრუნველყოფის მინი ვერსია, რომელიც მუშაობს ბრენდირებულ Dell EMC ECS სერვერებზე.

მე გამოვყავი ოთხი ძირითადი განსხვავება:

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

რა არის დიდ ვერსიაში?

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

მე არ დავადასტურებ ან უარვყოფ განცხადებას, რომ DELL ECS არის საუკეთესო პრემ ობიექტების შესანახი, მაგრამ თუ რაიმე გაქვთ სათქმელი ამ თემაზე, სიამოვნებით წავიკითხავ კომენტარებში. ყოველ შემთხვევაში ვერსიის მიხედვით IDC MarketScape 2018 Dell EMC თავდაჯერებულად შედის OBS ბაზრის ლიდერთა ხუთეულში. მიუხედავად იმისა, რომ ღრუბელზე დაფუძნებული გადაწყვეტილებები იქ არ არის გათვალისწინებული, ეს ცალკე საუბარია.

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

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

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

კითხვა უფრო ადვილია:

• კლიენტი ითხოვს მონაცემებს.
• ინდექსი ეძებს სად ინახება მონაცემები.
• მონაცემები იკითხება ერთი კვანძიდან და ეგზავნება კლიენტს.

თავად საკმაოდ ბევრი სერვერია, ასე რომ, მოდით გადავხედოთ ყველაზე პატარა Dell EMC ECS EX300. ის იწყება 60 ტბ-დან, 1,5 PB-მდე გაზრდის შესაძლებლობით. და მისი უფროსი ძმა, Dell EMC ECS EX3000, საშუალებას გაძლევთ შეინახოთ 8,6 PB თითო თაროზე.

განლაგება

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

• 8 vCPU
• 64GB RAM
• 16 GB OS-სთვის
• პირდაპირი საცავი 1 ტბ
• CentOS minimal-ის უახლესი გამოშვება

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

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

თუმცა, ECS CE დეველოპერები ცხოვრობენ რეალურ სამყაროში და ინსტალაცია წარმატებულია თუნდაც ერთი კვანძით და მინიმალური მოთხოვნებია:

• 4 vCPU
• 16 GB RAM
• 16 GB OS-სთვის
• თავად 104 GB საცავი

ეს არის რესურსები, რომლებიც საჭიროა OVA გამოსახულების განსათავსებლად. უკვე ბევრად უფრო ჰუმანური და რეალისტური.

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

• შესვლა: admin
• პაროლი: ChangeMe

შემდეგ ვაწარმოებთ sudo nmtui-ს და ვაკონფიგურირებთ ქსელის ინტერფეისს - IP/mask, DNS და gate. იმის გათვალისწინებით, რომ CentOS minimal-ს არ აქვს net-tools, ჩვენ ვამოწმებთ პარამეტრებს ip addr-ის საშუალებით.

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

ახლა დროა ინსტალაციის სკრიპტის რედაქტირება. არ არის თქვენთვის ლამაზი ფანჯრები ან ფსევდო UI - ყველაფერი კეთდება თქვენი საყვარელი ტექსტური რედაქტორის საშუალებით. ტექნიკურად, არსებობს ორი გზა: თქვენ შეგიძლიათ გაუშვათ თითოეული ბრძანება ხელით ან დაუყოვნებლივ გაუშვათ videoploy კონფიგურატორი. ის უბრალოდ გახსნის კონფიგურაციას vim-ში და გასვლისთანავე დაიწყებს მის შემოწმებას. მაგრამ არ არის საინტერესო თქვენი ცხოვრების განზრახ გამარტივება, ასე რომ, მოდით შევასრულოთ კიდევ ორი ​​ბრძანება. თუმცა ამას აზრი არ აქვს, მე გაგაფრთხილე =)

ასე რომ, მოდით, შევქმნათ vim ECS-CommunityEdition/deploy.xml და გავაკეთოთ ოპტიმალური მინიმალური ცვლილებები, რათა ECS ამოქმედდეს და ამოქმედდეს. პარამეტრების სია შეიძლება შემცირდეს, მაგრამ მე ასე გავაკეთე:

• Licensed_accepted: true თქვენ არ გჭირდებათ მისი შეცვლა, შემდეგ განლაგებისას თქვენ პირდაპირ მოგეთხოვებათ მისი მიღება და ნაჩვენები იქნება ლამაზი ფრაზა. შესაძლოა ეს სააღდგომო კვერცხიც კი იყოს.
  
• გააუქმეთ ხაზების autonames: და custom: შეიყვანეთ მინიმუმ ერთი სასურველი სახელი კვანძისთვის - ჰოსტის სახელი შეიცვლება მისით ინსტალაციის პროცესში.
• install_node: 192.168.1.1 მიუთითეთ კვანძის რეალური IP. ჩვენს შემთხვევაში, ჩვენ მივუთითებთ იგივე, რაც nmtui-ში
• dns_domain: შეიყვანეთ თქვენი დომენი.
• dns_servers: შეიყვანეთ თქვენი dns.
• ntp_servers: შეგიძლიათ მიუთითოთ ნებისმიერი. პირველი, რაც შემხვდა აუზიდან ავიღე 0.pool.ntp.org (ის გახდა 91.216.168.42)
• ავტონომირება: საბაჟო თუ კომენტარებს არ გააუქმებთ, მთვარეს ლუნა დაერქმევა.
• ecs_block_devices:
  / dev / sdb
  გაურკვეველი მიზეზის გამო, შესაძლოა არსებობდეს არარსებული ბლოკის შესანახი მოწყობილობა /dev/vda
• storage_pools:
  წევრები:
  192.168.1.1 აქ კვლავ მივუთითებთ კვანძის რეალურ IP-ს
• ecs_block_devices:
  /dev/sdb ჩვენ ვიმეორებთ არარსებული მოწყობილობების ამოჭრის ოპერაციას.

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

რედაქტორიდან გასვლის შემდეგ, თქვენ უნდა გაუშვათ update_deploy /home/admin/ECS-CommunityEdition/deploy.yml და თუ ყველაფერი სწორად გაკეთდა, ამის შესახებ ცალსახად იქნება მოხსენებული.

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

ახლა ჩვენ საბოლოოდ შეგვიძლია გავხსნათ WebUI მართვის პანელი ჩვენთვის ცნობილი IP-ის გამოყენებით. თუ კონფიგურაცია არ შეცვლილა ეტაპზე, ნაგულისხმევი ანგარიში იქნება root/ChangeMe. თქვენ შეგიძლიათ დაუყოვნებლივ გამოიყენოთ ჩვენი S3-თან თავსებადი საცავი. ის ხელმისაწვდომია 9020 პორტებზე HTTP-სთვის და 9021 HTTPS-ისთვის. ისევ, თუ არაფერი შეცვლილა, მაშინ access_key: object_admin1 და secret_key: ChangeMeChangeMeChangeMeChangeMeChangeMe.

ოღონდ ძალიან ნუ გავუსწრებთ თავს და წესრიგში დავიწყებთ.

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

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

შესაბამისად, ჩვენ ვირჩევთ ჩვენთვის საჭირო ფუნქციებს და ვქმნით მომხმარებლის გასაღებებს. S3/Atmos საკმარისი იქნება ჩემთვის. და არ დაგავიწყდეთ გასაღების შენახვა 😉

მომხმარებელი შეიქმნა, ახლა დროა გამოვყოთ მას ვედრო. გადადით Manage > Bucket და შეავსეთ საჭირო ველები. აქ ყველაფერი მარტივია.

ახლა ყველაფერი მზად გვაქვს ჩვენი S3 საცავის საკმაოდ საბრძოლო გამოყენებისთვის.

Veeam-ის დაყენება

ასე რომ, როგორც გვახსოვს, ობიექტების შენახვის ერთ-ერთი მთავარი გამოყენება არის ინფორმაციის გრძელვადიანი შენახვა, რომელიც იშვიათად არის ხელმისაწვდომი. იდეალური მაგალითია სარეზერვო ასლების შენახვის აუცილებლობა დისტანციურ საიტზე. Veeam Backup & Replication-ში ამ ფუნქციას ეწოდება Capacity Tier.

დავიწყოთ დაყენება Veeam ინტერფეისში ჩვენი Dell ECS CE-ის დამატებით. სარეზერვო ინფრასტრუქტურის ჩანართზე გაუშვით ახალი საცავის ოსტატის დამატება და აირჩიეთ ობიექტის შენახვა.

მოდით ავირჩიოთ რისთვის დაიწყო ყველაფერი - S3 თავსებადი.

ფანჯარაში, რომელიც გამოჩნდება, ჩაწერეთ სასურველი სახელი და გადადით ანგარიშის საფეხურზე. აქ თქვენ უნდა მიუთითოთ სერვისის წერტილი ფორმაში https://your_IP:9021, რეგიონი შეიძლება დარჩეს ისე, როგორც არის და დაემატოს შექმნილი მომხმარებელი. კარიბჭის სერვერი აუცილებელია, თუ თქვენი საცავი მდებარეობს დისტანციურ საიტზე, მაგრამ ეს უკვე არის ინფრასტრუქტურის ოპტიმიზაციის თემა და ცალკე სტატია, ასე რომ თქვენ შეგიძლიათ უსაფრთხოდ გამოტოვოთ აქ.

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

ჩვენ ბოლომდე გავდივართ ოსტატი და ვტკბებით შედეგით.

შემდეგი ნაბიჯი არის ან შექმნათ ახალი Scale-out Backup Repository, ან დაამატოთ ჩვენი S3 არსებულს - ის გამოყენებული იქნება როგორც Capacity Tier საარქივო შენახვისთვის. არ არსებობს ფუნქცია S3-თან თავსებადი მეხსიერების უშუალოდ გამოყენებისთვის, როგორც ჩვეულებრივი საცავი, მიმდინარე გამოშვებაში. ძალიან ბევრი საკმაოდ არააშკარა პრობლემის გადაჭრაა საჭირო, რომ ეს მოხდეს, მაგრამ ყველაფერი შესაძლებელია.
გადადით საცავის პარამეტრებში და ჩართეთ Capacity Tier. იქ ყველაფერი გამჭვირვალეა, მაგრამ არის საინტერესო ნიუანსი: თუ გსურთ, რომ ყველა მონაცემი რაც შეიძლება მალე გაიგზავნოს ობიექტის შესანახად, უბრალოდ დააყენეთ ის 0 დღეზე.

ოსტატის გავლის შემდეგ, თუ არ გსურთ ლოდინი, შეგიძლიათ დააჭიროთ ctrl+RMB საცავზე, ძალით გაუშვათ Tiering სამუშაო და უყუროთ გრაფიკების ცოცვას.

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

წყარო: www.habr.com