რა საერთო აქვთ LVM-ს და მატრიოშკას?

კარგი დღე.
მსურს საზოგადოებას გავუზიარო ჩემი პრაქტიკული გამოცდილება KVM-სთვის მონაცემთა შენახვის სისტემის შექმნის შესახებ md RAID + LVM გამოყენებით.

პროგრამა მოიცავს:

• Build md RAID 1 NVMe SSD-დან.
• md RAID 6-ის აწყობა SATA SSD-დან და ჩვეულებრივი დისკებიდან.
• TRIM/DISCARD ოპერაციის მახასიათებლები SSD RAID 1/6-ზე.
• ჩამტვირთავი md RAID 1/6 მასივის შექმნა დისკების საერთო კომპლექტზე.
• სისტემის ინსტალაცია NVMe RAID 1-ზე, როდესაც BIOS-ში არ არის NVMe მხარდაჭერა.
• LVM ქეშის გამოყენება და LVM თხელი.
• გამოიყენეთ BTRFS სნეპშოტები და გაგზავნეთ/მიიღეთ სარეზერვო ასლისთვის.
• LVM თხელი სნეპშოტების და thin_delta-ს გამოყენება BTRFS სტილის სარეზერვო ასლისთვის.

თუ გაინტერესებთ, ნახეთ კატა.

განცხადება

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

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

რკინის

ხელმისაწვდომი იყო:

დედაპლატა დაახლოებით 2013 წლიდან Z87 ჩიპსეტით, დასრულებულია Intel Core i7 / Haswell-ით.

• პროცესორი 4 ბირთვი, 8 ძაფი
• 32 GB DDR3 ოპერატიული მეხსიერება
• 1 x 16 ან 2 x 8 PCIe 3.0
• 1 x 4 + 1 x 1 PCIe 2.0
• 6 x 6 GBps SATA 3 კონექტორები

SAS ადაპტერი LSI SAS9211-8I მოციმციმე IT / HBA რეჟიმში. RAID-ზე ჩართული პროგრამული უზრუნველყოფა განზრახ შეიცვალა HBA პროგრამული უზრუნველყოფით, რათა:

1. თქვენ შეგიძლიათ ნებისმიერ დროს გადააგდოთ ეს ადაპტერი და შეცვალოთ იგი ნებისმიერი სხვა ადაპტერით, რომელიც შეგხვდებათ.
2. TRIM/Discard ჩვეულებრივ მუშაობდა დისკებზე, რადგან... RAID firmware-ში ეს ბრძანებები საერთოდ არ არის მხარდაჭერილი და HBA-ს, ზოგადად, არ აინტერესებს რა ბრძანებები გადაეცემა ავტობუსს.

მყარი დისკები - 8 ცალი HGST Travelstar 7K1000 1 ტბ ტევადობით 2.5 ფორმატში, რაც შეეხება ლეპტოპებს. ეს დისკები ადრე იყო RAID 6 მასივში. მათ ასევე ექნებათ გამოყენება ახალ სისტემაში. ადგილობრივი სარეზერვო ასლების შესანახად.

დამატებით დამატებულია:

6 ცალი SATA SSD მოდელი Samsung 860 QVO 2TB. ეს SSD-ები მოითხოვდნენ დიდ მოცულობას, სასურველი იყო SLC ქეშის არსებობა, საიმედოობა და დაბალი ფასი. საჭირო იყო გაუქმების/ნულის მხარდაჭერა, რომელიც მოწმდება dmesg-ის ხაზით:

kernel: ata1.00: Enabling discard_zeroes_data

2 ცალი NVMe SSD მოდელი Samsung SSD 970 EVO 500GB.

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

StarTech PEX8M2E2 ადაპტერი 2 x NVMe SSD-სთვის დაინსტალირებული PCIe 3.0 8x სლოტში. ეს, ისევ და ისევ, არის მხოლოდ HBA, მაგრამ NVMe-სთვის. ის განსხვავდება იაფი ადაპტერებისგან იმით, რომ არ საჭიროებს PCIe ბიფურკაციის მხარდაჭერას დედაპლატისგან, ჩაშენებული PCIe გადამრთველის არსებობის გამო. ის იმუშავებს უძველეს სისტემაშიც კი PCIe-ით, თუნდაც ის იყოს x1 PCIe 1.0 სლოტი. ბუნებრივია, შესაბამისი სიჩქარით. იქ არ არის RAID-ები. ბორტზე არ არის ჩაშენებული BIOS. ასე რომ, თქვენი სისტემა ჯადოსნურად არ ისწავლის NVMe-ით ჩატვირთვას, მით უმეტეს, რომ NVMe RAID ამ მოწყობილობის წყალობით.

ეს კომპონენტი განპირობებული იყო მხოლოდ ერთი უფასო 8x PCIe 3.0 სისტემაში არსებობით და, თუ არის 2 უფასო სლოტი, მისი მარტივად შეცვლა შესაძლებელია ორი პენი PEX4M2E1-ით ან ანალოგებით, რომელთა ყიდვა შესაძლებელია სადმე 600 ფასით. რუბლი.

ყველა სახის ტექნიკის ან ჩაშენებული ჩიპსეტის/BIOS RAID-ის უარყოფა განზრახ გაკეთდა, რათა შესაძლებელი ყოფილიყო მთელი სისტემის მთლიანად ჩანაცვლება, გარდა თავად SSD/HDD-ისა, ყველა მონაცემის შენარჩუნებით. იდეალურ შემთხვევაში, რათა დაინსტალირებული ოპერაციული სისტემაც კი შეინახოთ სრულიად ახალ/განსხვავებულ აპარატზე გადასვლისას. მთავარი ის არის, რომ არსებობს SATA და PCIe პორტები. ეს არის ცოცხალი CD ან ჩამტვირთავი ფლეშ დრაივი, მხოლოდ ძალიან სწრაფი და ცოტა მოცულობითი.

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

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

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

პროგრამული უზრუნველყოფა

ადრე, Debian 8 Jessie დაინსტალირებული იყო აპარატურაზე, რომელიც ახლოსაა EOL-თან. RAID 6 აწყობილი იყო ზემოთ აღნიშნული HDD-ებიდან, დაწყვილებული LVM-ით. ის მუშაობდა ვირტუალურ მანქანებზე kvm/libvirt-ში.

იმიტომ რომ ავტორს აქვს შესაბამისი გამოცდილება პორტატული ჩამტვირთავი SATA/NVMe ფლეშ დრაივების შექმნის საქმეში და ასევე, იმისათვის, რომ არ დაირღვეს ჩვეული შესაფერისი შაბლონი, სამიზნე სისტემად აირჩიეს Ubuntu 18.04, რომელიც უკვე საკმარისად სტაბილიზირებულია, მაგრამ ჯერ კიდევ აქვს 3 წელი. მხარდაჭერა მომავალში.

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

ინსტალაციისთვის ემზადება

სისტემის დასაყენებლად გვჭირდება Ubuntu Desktop Image. სერვერის სისტემას აქვს ერთგვარი ენერგიული ინსტალერი, რომელიც აჩვენებს ზედმეტ დამოუკიდებლობას, რომლის გამორთვა შეუძლებელია UEFI სისტემის დანაყოფის ერთ-ერთ დისკზე გადატანით, რაც აფუჭებს მთელ სილამაზეს. შესაბამისად, ის დაინსტალირებულია მხოლოდ UEFI რეჟიმში. არ გვთავაზობს რაიმე ვარიანტს.

ჩვენ არ ვართ კმაყოფილი ამით.

რატომ?სამწუხაროდ, UEFI ჩატვირთვა უკიდურესად ცუდად თავსებადია ჩატვირთვის პროგრამულ RAID-თან, რადგან... არავინ გვთავაზობს დაჯავშნას UEFI ESP დანაყოფისთვის. ინტერნეტში არის რეცეპტები, რომლებიც გვთავაზობენ ESP დანაყოფის ფლეშ დრაივზე USB პორტის განთავსებას, მაგრამ ეს არის წარუმატებლობის წერტილი. არსებობს რეცეპტები პროგრამული უზრუნველყოფის mdadm RAID 1-ის გამოყენებით მეტამონაცემების 0.9 ვერსიით, რომლებიც ხელს არ უშლის UEFI BIOS-ს ამ დანაყოფის ნახვაში, მაგრამ ეს გრძელდება იმ ბედნიერ მომენტამდე, როდესაც BIOS ან სხვა აპარატურის OS წერს რაღაცას ESP-ზე და ავიწყდება მის სინქრონიზაციას სხვასთან. სარკეები.

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

ასე რომ, ჩვენ არ გამოვიგონებთ ახალ ბორბალს. ჩვენ უკვე გვაქვს მზა, დროში გამოცდილი ბაბუის ველოსიპედი, რომელსაც ახლა Legacy/BIOS-ის ჩექმა ჰქვია, რომელსაც UEFI-თან თავსებადი სისტემებზე CSM ამაყი სახელი აქვს. ჩვენ უბრალოდ ამოვიღებთ თაროდან, შეზეთვას, საბურავებს ამოტუმბვით და ნესტიანი ქსოვილით გავწმენდთ.

Ubuntu-ს დესკტოპის ვერსია ასევე არ შეიძლება სწორად დაინსტალირდეს Legacy bootloader-ით, მაგრამ აქ, როგორც ამბობენ, მაინც არის ვარიანტები.

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

ჩვენ შევდივართ Desktop გარემოში, გავუშვით ტერმინალის ემულატორი და მივდივართ:

#sudo bash

Როგორ…?ზემოთ მოცემული სტრიქონი არის კანონიკური გამომწვევი ჰოლივარებისთვის სუდოს შესახებ. C ბоუფრო დიდი შესაძლებლობები მოდის დაоუფრო დიდი პასუხისმგებლობა. საკითხავია, შეგიძლია თუ არა საკუთარ თავზე აღება. ბევრი ფიქრობს, რომ სუდოს ამ გზით გამოყენება მაინც არ არის ფრთხილად. თუმცა:

#apt-get install mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc

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

ამ თვალსაზრისით, ZFS არის Ferrari, ხოლო mdadm+lvm უფრო ველოსიპედს ჰგავს.

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

რატომ მაშინ BTRFS...?ოპერაციული სისტემის ჩატვირთვისთვის, ჩვენ გვჭირდება ფაილური სისტემა, რომელიც მხარდაჭერილია Legacy/BIOS GRUB-ში და ამავდროულად მხარს უჭერს ცოცხალ სნეპშოტებს. ჩვენ მას გამოვიყენებთ /boot დანაყოფისთვის. გარდა ამისა, ავტორს ურჩევნია გამოიყენოს ეს FS / (root), არ უნდა დაგვავიწყდეს აღინიშნოს, რომ ნებისმიერი სხვა პროგრამისთვის შეგიძლიათ შექმნათ ცალკეული ტიხრები LVM-ზე და დააინსტალიროთ ისინი საჭირო დირექტორიაში.

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

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

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

თუ უფრო მეტად ენდობით ZFS-ს, მაშინ, პრინციპში, მითითებული აპლიკაციისთვის ისინი ურთიერთშემცვლელნი არიან.

თუმცა, ავტორი განზრახ უგულებელყოფს ჩაშენებულ სარკისებურ/RAID და ჭარბი ფუნქციებს, რომლებიც გააჩნიათ ZFS, BRTFS და LVM.

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

მოდით ხელახლა გადავხედოთ ყველა მოწყობილობას:

#udevadm control --reload-rules && udevadm trigger

მოდით, მიმოვიხედოთ გარშემო:

#lsscsi && nvme list
[0:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sda
[1:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdb
[2:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdc
[3:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdd
[4:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sde
[5:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdf
[6:0:0:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdg
[6:0:1:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdh
[6:0:2:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdi
[6:0:3:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdj
[6:0:4:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdk
[6:0:5:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdl
[6:0:6:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdm
[6:0:7:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdn
Node SN Model Namespace Usage Format FW Rev
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1 S466NXXXXXXX15L Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7
/dev/nvme1n1 S5H7NXXXXXXX48N Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7


დისკის განლაგება

NVMe SSD

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

SATA მყარი დისკი

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

#cat >hdd.part << EOF
label: dos
label-id: 0x00000000
device: /dev/sdg
unit: sectors

/dev/sdg1 : start= 2048, size= 1953523120, type=fd, bootable
EOF
#sfdisk /dev/sdg < hdd.part
#sfdisk /dev/sdh < hdd.part
#sfdisk /dev/sdi < hdd.part
#sfdisk /dev/sdj < hdd.part
#sfdisk /dev/sdk < hdd.part
#sfdisk /dev/sdl < hdd.part
#sfdisk /dev/sdm < hdd.part
#sfdisk /dev/sdn < hdd.part


SATA SSD

სწორედ აქ ხდება ჩვენთვის საინტერესო რამ.

ჯერ ერთი, ჩვენი დისკები არის 2 ტბ ზომის. ეს არის MBR-სთვის მისაღები დიაპაზონის ფარგლებში, რასაც ჩვენ გამოვიყენებთ. საჭიროების შემთხვევაში, შეიძლება შეიცვალოს GPT-ით. GPT დისკებს აქვთ თავსებადობის შრე, რომელიც საშუალებას აძლევს MBR-თან თავსებად სისტემებს ნახონ პირველი 4 დანაყოფი, თუ ისინი განლაგებულია პირველ 2 ტერაბაიტში. მთავარია, რომ ამ დისკებზე boot partition და bios_grub დანაყოფები უნდა იყოს დასაწყისში. ეს საშუალებას გაძლევთ ჩატვირთოთ GPT Legacy/BIOS დისკებიდან.

მაგრამ ეს არ არის ჩვენი საქმე.

აქ ჩვენ შევქმნით ორ განყოფილებას. პირველი იქნება 1 GB ზომის და გამოყენებული იქნება RAID 1/boot-ისთვის.

მეორე გამოყენებული იქნება RAID 6-ისთვის და დაიკავებს მთელ დარჩენილ თავისუფალ ადგილს, გარდა დისკის ბოლოს მცირე გამოუყენებელი ადგილისა.

რა არის ეს დაუსახელებელი ტერიტორია?ქსელში არსებული წყაროების თანახმად, ჩვენს SATA SSD-ებს აქვთ დინამიურად გაფართოებადი SLC ქეში, რომლის ზომებია 6-დან 78 გიგაბაიტამდე. ჩვენ ვიღებთ 6 გიგაბაიტს "უფასოდ" დისკის მონაცემთა ფურცელში "გიგაბაიტსა" და "გიბიბაიტს" შორის სხვაობის გამო. დარჩენილი 72 გიგაბაიტი გამოუყენებელი სივრციდან არის გამოყოფილი.

აქვე უნდა აღინიშნოს, რომ გვაქვს SLC ქეში, ხოლო სივრცე 4 ბიტიანი MLC რეჟიმშია დაკავებული. რაც ჩვენთვის ეფექტურად ნიშნავს, რომ ყოველი 4 გიგაბაიტი თავისუფალ სივრცეში ჩვენ მივიღებთ მხოლოდ 1 გიგაბაიტ SLC ქეშს.

გაამრავლეთ 72 გიგაბაიტი 4-ზე და მიიღეთ 288 გიგაბაიტი. ეს არის თავისუფალი ადგილი, რომელსაც ჩვენ არ გამოვყოფთ, რათა დისკებს მივცეთ საშუალება სრულად გამოიყენონ SLC ქეში.

ამრიგად, ჩვენ ეფექტურად მივიღებთ 312 გიგაბაიტამდე SLC ქეშს სულ ექვსი დისკიდან. ყველა დისკიდან 2 გამოყენებული იქნება RAID-ში ზედმეტობისთვის.

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

#cat >ssd.part << EOF
label: dos
label-id: 0x00000000
device: /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size= 2097152, type=fd, bootable
/dev/sda2 : start= 2099200, size= 3300950016, type=fd
EOF
#sfdisk /dev/sda < ssd.part
#sfdisk /dev/sdb < ssd.part
#sfdisk /dev/sdc < ssd.part
#sfdisk /dev/sdd < ssd.part
#sfdisk /dev/sde < ssd.part
#sfdisk /dev/sdf < ssd.part


მასივების შექმნა

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

#mcedit /etc/hostname
#mcedit /etc/hosts
#hostname
vdesk0


NVMe SSD

#mdadm --create --verbose --assume-clean /dev/md0 --level=1 --raid-devices=2 /dev/nvme[0-1]n1

რატომ - ვივარაუდოთ - სუფთა...?მასივების ინიციალიზაციის თავიდან ასაცილებლად. ორივე RAID 1 და 6 დონისთვის ეს მოქმედებს. ყველაფერი შეიძლება იმუშაოს ინიციალიზაციის გარეშე, თუ ეს არის ახალი მასივი. უფრო მეტიც, SSD მასივის ინიციალიზაცია შექმნისთანავე არის TBW რესურსის დაკარგვა. ჩვენ ვიყენებთ TRIM/DISCARD-ს, სადაც ეს შესაძლებელია, აწყობილ SSD მასივებზე მათი „ინიციალიზაციისთვის“.

SSD მასივებისთვის, RAID 1 DISCARD მხარდაჭერილია გარედან.

SSD RAID 6 DISCARD მასივებისთვის, თქვენ უნდა ჩართოთ ის ბირთვის მოდულის პარამეტრებში.

ეს უნდა გაკეთდეს მხოლოდ იმ შემთხვევაში, თუ ამ სისტემაში 4/5/6 დონის მასივებში გამოყენებული ყველა SSD-ს აქვს discard_zeroes_data სამუშაო მხარდაჭერა. ზოგჯერ შეხვდებით უცნაურ დისკებს, რომლებიც ეუბნებიან ბირთვს, რომ ეს ფუნქცია მხარდაჭერილია, მაგრამ სინამდვილეში ის არ არის, ან ფუნქცია ყოველთვის არ მუშაობს. ამ დროისთვის მხარდაჭერა ხელმისაწვდომია თითქმის ყველგან, თუმცა არის ძველი დისკები და პროგრამული უზრუნველყოფა შეცდომებით. ამ მიზეზით, DISCARD მხარდაჭერა ნაგულისხმევად გამორთულია RAID 6-ისთვის.

ყურადღება, შემდეგი ბრძანება გაანადგურებს ყველა მონაცემს NVMe დისკებზე მასივის „ინიციალიზებით“ „ნულებით“.

#blkdiscard /dev/md0

თუ რამე არასწორედ წარიმართება, შეეცადეთ მიუთითოთ ნაბიჯი.

#blkdiscard --step 65536 /dev/md0

SATA SSD

#mdadm --create --verbose --assume-clean /dev/md1 --level=1 --raid-devices=6 /dev/sd[a-f]1
#blkdiscard /dev/md1
#mdadm --create --verbose --assume-clean /dev/md2 --chunk-size=512 --level=6 --raid-devices=6 /dev/sd[a-f]2

რატომ ასე დიდი...?მოცულობის ზომის გაზრდა დადებითად აისახება შემთხვევითი წაკითხვის სიჩქარეზე ბლოკებში ნაჭრის ზომის ჩათვლით. ეს იმიტომ ხდება, რომ შესაბამისი ზომის ან უფრო მცირე ზომის ერთი ოპერაცია შეიძლება დასრულდეს მთლიანად ერთ მოწყობილობაზე. ამრიგად, შეჯამებულია IOPS ყველა მოწყობილობიდან. სტატისტიკის მიხედვით, IO-ს 99% არ აღემატება 512K.

RAID 6 IOPS თითო ჩაწერაზე ყოველთვის ერთი დისკის IOPS-ზე ნაკლები ან ტოლი. როდესაც, შემთხვევითი წაკითხვისას, IOPS შეიძლება იყოს რამდენჯერმე მეტი ვიდრე ერთი დისკი, და აქ ბლოკის ზომას მთავარი მნიშვნელობა აქვს.
ავტორი ვერ ხედავს აზრს იმ პარამეტრის ოპტიმიზაციის მცდელობაში, რომელიც ცუდია RAID 6-ის დიზაინში და ამის ნაცვლად ოპტიმიზაციას უკეთებს RAID 6-ს.
ჩვენ შევანაზღაურებთ RAID 6-ის ცუდ შემთხვევით ჩაწერას NVMe ქეშით და წვრილ-პროვიაჟირების ხრიკებით.

ჩვენ ჯერ არ ჩავრთავთ DISCARD RAID 6-ისთვის. ამიტომ ამ მასივის „ინიციალიზაციას“ ამ დროისთვის არ გავაკეთებთ. ჩვენ ამას გავაკეთებთ მოგვიანებით, OS-ის დაყენების შემდეგ.

SATA მყარი დისკი

#mdadm --create --verbose --assume-clean /dev/md3 --chunk-size=512 --level=6 --raid-devices=8 /dev/sd[g-n]1

LVM NVMe RAID-ზე

სიჩქარისთვის, ჩვენ გვინდა განვათავსოთ root ფაილური სისტემა NVMe RAID 1-ზე, რომელიც არის /dev/md0.
თუმცა, ჩვენ მაინც დაგვჭირდება ეს სწრაფი მასივი სხვა საჭიროებებისთვის, როგორიცაა swap, მეტამონაცემები და LVM-cache და LVM-thin მეტამონაცემები, ამიტომ ჩვენ შევქმნით LVM VG-ს ამ მასივზე.

#pvcreate /dev/md0
#vgcreate root /dev/md0

მოდით შევქმნათ დანაყოფი root ფაილური სისტემისთვის.

#lvcreate -L 128G --name root root

მოდით შევქმნათ დანაყოფი RAM-ის ზომის მიხედვით გადასაცვლელად.

#lvcreate -L 32G --name swap root

OS ინსტალაცია

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

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

• /dev/md1, - დამაგრების წერტილი /ჩატვირთვა, FS - BTRFS
• /dev/root/root (a.k.a /dev/mapper/root-root), - დამაგრების წერტილი / (root), FS - BTRFS
• /dev/root/swap (a.k.a /dev/mapper/root-swap), - გამოყენება როგორც swap დანაყოფი
• დააინსტალირეთ ჩამტვირთავი /dev/sda-ზე

როდესაც ირჩევთ BTRFS, როგორც root ფაილურ სისტემას, ინსტალერი ავტომატურად შექმნის BTRFS ორ ტომს სახელად "@" for / (root) და "@home" for /home.

დავიწყოთ ინსტალაცია...

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

#sudo bash

შექმენით chroot გარემო ინსტალაციის გასაგრძელებლად:

#mkdir /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@ /dev/mapper/root-root /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@home /dev/mapper/root-root /mnt/chroot/home
#mount -o defaults,space_cache,noatime,nodiratime,discard /dev/md1 /mnt/chroot/boot
#mount --bind /proc /mnt/chroot/proc
#mount --bind /sys /mnt/chroot/sys
#mount --bind /dev /mnt/chroot/dev

მოდით დავაკონფიგურიროთ ქსელი და ჰოსტის სახელი chroot-ში:

#cat /etc/hostname >/mnt/chroot/etc/hostname
#cat /etc/hosts >/mnt/chroot/etc/hosts
#cat /etc/resolv.conf >/mnt/chroot/etc/resolv.conf

მოდით გადავიდეთ chroot გარემოში:

#chroot /mnt/chroot

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

apt-get install --reinstall mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc debsums hdparm

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

#CORRUPTED_PACKAGES=$(debsums -s 2>&1 | awk '{print $6}' | uniq)
#apt-get install --reinstall $CORRUPTED_PACKAGES

თუ რამე არ გამოდის, შეიძლება დაგჭირდეთ ჯერ /etc/apt/sources.list-ის რედაქტირება

მოდით დაარეგულიროთ RAID 6 მოდულის პარამეტრები, რათა ჩართოთ TRIM/DISCARD:

#cat >/etc/modprobe.d/raid456.conf << EOF
options raid456 devices_handle_discard_safely=1
EOF

მოდით ცოტათი შევასწოროთ ჩვენი მასივები:

#cat >/etc/udev/rules.d/60-md.rules << EOF
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/stripe_cache_size", ATTR{md/stripe_cache_size}="32768"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_min", ATTR{md/sync_speed_min}="48000"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_max", ATTR{md/sync_speed_max}="300000"
EOF
#cat >/etc/udev/rules.d/62-hdparm.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/hdparm -B 254 /dev/%k"
EOF
#cat >/etc/udev/rules.d/63-blockdev.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/blockdev --setra 1024 /dev/%k"
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="md*", RUN+="/sbin/blockdev --setra 0 /dev/%k"
EOF

Რა იყო ეს..?ჩვენ შევქმენით udev წესების ნაკრები, რომელიც გააკეთებს შემდეგს:

• დააყენეთ ბლოკის ქეშის ზომა RAID 2020-ისთვის ადეკვატური 6 წლისთვის. ნაგულისხმევი მნიშვნელობა, როგორც ჩანს, არ შეცვლილა Linux-ის შექმნის შემდეგ და არ იყო ადეკვატური დიდი ხნის განმავლობაში.
• დაჯავშნეთ მინიმუმ IO მასივის შემოწმების/სინქრონიზაციის ხანგრძლივობისთვის. ეს არის იმისათვის, რომ არ დაუშვას თქვენი მასივები დატვირთვის ქვეშ მარადიული სინქრონიზაციის მდგომარეობაში.
• შეზღუდეთ მაქსიმალური IO მასივების შემოწმების/სინქრონიზაციის დროს. ეს აუცილებელია იმისათვის, რომ SSD RAID-ების სინქრონიზაცია/შემოწმება არ დააბრკოლოს თქვენი დისკები. ეს განსაკუთრებით ეხება NVMe-ს. (გახსოვს რადიატორი? არ ვხუმრობდი.)
• აკრძალეთ დისკების შეჩერება spindle rotation (HDD) APM-ის საშუალებით და დააყენეთ ძილის დრო დისკის კონტროლერებისთვის 7 საათამდე. თქვენ შეგიძლიათ მთლიანად გამორთოთ APM, თუ თქვენს დისკებს შეუძლიათ ამის გაკეთება (-B 255). ნაგულისხმევი მნიშვნელობით, დისკები გაჩერდება ხუთი წამის შემდეგ. შემდეგ OS-ს სურს დისკის ქეშის გადატვირთვა, დისკები ისევ დატრიალდება და ყველაფერი თავიდან დაიწყება. დისკებს აქვთ შტრიხების ბრუნვის შეზღუდული მაქსიმალური რაოდენობა. ასეთი მარტივი ნაგულისხმევი ციკლი ადვილად კლავს თქვენს დისკებს რამდენიმე წელიწადში. ყველა დისკი არ განიცდის ამას, მაგრამ ჩვენი არის "ლეპტოპი", შესაბამისი ნაგულისხმევი პარამეტრებით, რაც RAID-ს მინი-MAID-ს ჰგავს.
• Readahead-ის დაყენება დისკებზე (მბრუნავი) 1 მეგაბაიტი - ორი ზედიზედ ბლოკი/ნაწილი RAID 6
• გამორთეთ წინასწარ წაკითხვა თავად მასივებზე.

მოდით დაარედაქტიროთ /etc/fstab:

#cat >/etc/fstab << EOF
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# file-system mount-point type options dump pass
/dev/mapper/root-root / btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@ 0 1
UUID=$(blkid -o value -s UUID /dev/md1) /boot btrfs defaults,space_cache,noatime,nodiratime,discard 0 2
/dev/mapper/root-root /home btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@home 0 2
/dev/mapper/root-swap none swap sw 0 0
EOF
Რატომ არის, რომ..?ჩვენ მოვძებნით /boot დანაყოფი UUID-ით. მასივის დასახელება თეორიულად შეიძლება შეიცვალოს.

ჩვენ მოვძებნით დარჩენილ სექციებს LVM სახელების მიხედვით /dev/mapper/vg-lv ნოტაციაში, რადგან ისინი იდენტიფიცირებენ დანაყოფებს საკმაოდ ცალსახად.

ჩვენ არ ვიყენებთ UUID-ს LVM-ისთვის, რადგან LVM ტომების UUID და მათი სნეპშოტები შეიძლება იყოს იგივე.დაამონტაჟე /dev/mapper/root-root.. ორჯერ?დიახ. ზუსტად. BTRFS-ის თვისება. ეს ფაილური სისტემა შეიძლება რამდენჯერმე დამონტაჟდეს სხვადასხვა ქვევოლებით.

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

მოდით აღვადგინოთ mdadm კონფიგურაცია:

#/usr/share/mdadm/mkconf | sed 's/#DEVICE/DEVICE/g' >/etc/mdadm/mdadm.conf

მოდით დავარეგულიროთ LVM პარამეტრები:

#cat >>/etc/lvm/lvmlocal.conf << EOF

activation {
thin_pool_autoextend_threshold=90
thin_pool_autoextend_percent=5
}
allocation {
cache_pool_max_chunks=2097152
}
devices {
global_filter=["r|^/dev/.*_corig$|","r|^/dev/.*_cdata$|","r|^/dev/.*_cmeta$|","r|^/dev/.*gpv$|","r|^/dev/images/.*$|","r|^/dev/mapper/images.*$|","r|^/dev/backup/.*$|","r|^/dev/mapper/backup.*$|"] issue_discards=1
}
EOF

Რა იყო ეს..?ჩვენ გავააქტიურეთ LVM თხელი აუზების ავტომატური გაფართოება დაკავებული სივრცის 90%-მდე მოცულობის 5%-ით.

ჩვენ გავზარდეთ ქეში ბლოკების მაქსიმალური რაოდენობა LVM ქეშისთვის.

ჩვენ შევუშალეთ ხელი LVM-ს LVM ტომების (PV) მოძიებაში:

• მოწყობილობები, რომლებიც შეიცავს LVM ქეშს (cdata)
• მოწყობილობები ქეშირებული LVM ქეშის გამოყენებით ქეშის გვერდის ავლით (_corig). ამ შემთხვევაში, თავად ქეშირებული მოწყობილობა კვლავ სკანირებული იქნება ქეშის მეშვეობით (უბრალოდ ).
• მოწყობილობები, რომლებიც შეიცავს LVM ქეში მეტამონაცემებს (cmeta)
• ყველა მოწყობილობა VG-ში სახელის სურათებით. აქ გვექნება ვირტუალური მანქანების დისკის გამოსახულებები და არ გვინდა, რომ ჰოსტზე LVM-მა გაააქტიუროს სტუმრის OS-ის კუთვნილი ტომები.
• ყველა მოწყობილობა VG-ში სახელის სარეზერვო ასლით. აქ გვექნება ვირტუალური მანქანის სურათების სარეზერვო ასლები.
• ყველა მოწყობილობა, რომლის სახელი მთავრდება „gpv“-ით (სტუმრების ფიზიკური მოცულობა)

ჩვენ გავააქტიურეთ DISCARD მხარდაჭერა LVM VG-ზე თავისუფალი სივრცის გათავისუფლებისას. Ფრთხილად იყავი. ეს საკმაოდ შრომატევადს გახდის SSD-ზე LV-ების წაშლას. ეს განსაკუთრებით ეხება SSD RAID 6-ს. თუმცა გეგმის მიხედვით გამოვიყენებთ თხელ დებულებას, ასე რომ ეს სულაც არ შეგვიშლის ხელს.

მოდით განვაახლოთ initramfs სურათი:

#update-initramfs -u -k all

დააინსტალირეთ და დააკონფიგურირეთ grub:

#apt-get install grub-pc
#apt-get purge os-prober
#dpkg-reconfigure grub-pc

რომელი დისკები აირჩიოს?ყველა ვინც არის სდ*. სისტემას უნდა შეეძლოს ჩატვირთვა ნებისმიერი სამუშაო SATA დისკიდან ან SSD-დან.

რატომ დაამატეს os-prober..?ზედმეტი დამოუკიდებლობისა და სათამაშო ხელებისთვის.

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

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

ამით ჩვენ დავასრულეთ საწყისი ინსტალაცია. დროა გადატვირთოთ ახლად დაყენებულ OS-ში. არ დაგავიწყდეთ ჩამტვირთავი Live CD/USB ამოღება.

#exit
#reboot

აირჩიეთ ნებისმიერი SATA SSD, როგორც ჩატვირთვის მოწყობილობა.

LVM SATA SSD-ზე

ამ ეტაპზე, ჩვენ უკვე ჩავტვირთეთ ახალ OS-ში, დავაკონფიგურირეთ ქსელი, გავხსენით ტერმინალის ემულატორი და გავუშვით:

#sudo bash

Გავაგრძელოთ.

მასივის „ინიციალიზაცია“ SATA SSD-დან:

#blkdiscard /dev/md2

თუ ეს არ მუშაობს, მაშინ სცადეთ:

#blkdiscard --step 65536 /dev/md2
შექმენით LVM VG SATA SSD-ზე:

#pvcreate /dev/md2
#vgcreate data /dev/md2

რატომ სხვა VG..?სინამდვილეში, ჩვენ უკვე გვაქვს VG სახელად root. რატომ არ დაამატეთ ყველაფერი ერთ VG-ში?

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

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

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

მეცნიერულად რომ ვთქვათ, სხვადასხვა RAID მასივი ეკუთვნის სხვადასხვა "სანდოობის დომენებს". თქვენ არ უნდა შექმნათ დამატებითი საერთო მარცხის წერტილი მათთვის ერთ VG-ში ჩაყრით.

LVM-ის არსებობა „ტექნიკის“ დონეზე საშუალებას მოგვცემს თვითნებურად დავჭრათ სხვადასხვა RAID მასივების ნაწილები მათი სხვადასხვა გზით კომბინაციით. მაგალითად - გაუშვით ერთდროულად bcache + LVM thin, bcache + BTRFS, LVM cache + LVM thin, რთული ZFS კონფიგურაცია ქეშებით, ან ნებისმიერი სხვა ჯოჯოხეთური ნარევი, რომ სცადოთ და შევადაროთ ეს ყველაფერი.

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

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

LVM SATA HDD-ზე

#pvcreate /dev/md3
#vgcreate backup /dev/md3

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

LVM ქეშის დაყენება

მოდით შევქმნათ LV NVMe RAID 1-ზე, რომ გამოვიყენოთ როგორც ქეშირების მოწყობილობა.

#lvcreate -L 70871154688B --name cache root

რატომ არის ასე ცოტა...ფაქტია, რომ ჩვენს NVMe SSD-ებს ასევე აქვთ SLC ქეში. 4 გიგაბაიტი "თავისუფალი" და 18 გიგაბაიტი დინამიური 3-ბიტიანი MLC-ში დაკავებული თავისუფალი სივრცის გამო. ამ ქეშის ამოწურვის შემდეგ, NVMe SSD-ები არ იქნება ბევრად უფრო სწრაფი ვიდრე ჩვენი SATA SSD ქეშით. სინამდვილეში, ამ მიზეზით, ჩვენთვის აზრი არ აქვს, რომ LVM ქეში დანაყოფი გავხადოთ ბევრად უფრო დიდი ვიდრე NVMe დისკის SLC ქეშის ზომაზე ორჯერ მეტი. გამოყენებული NVMe დისკებისთვის ავტორი გონივრულად მიიჩნევს 32-64 გიგაბაიტიანი ქეშის დამზადებას.

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

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

მოდით შევქმნათ LV SATA RAID 6-ზე, რომ გამოვიყენოთ როგორც ქეშირებული მოწყობილობა.

#lvcreate -L 3298543271936B --name cache data

რატომ მხოლოდ სამი ტერაბაიტი..?ასე რომ, საჭიროების შემთხვევაში, შეგიძლიათ გამოიყენოთ SATA SSD RAID 6 სხვა საჭიროებისთვის. ქეშირებული სივრცის ზომა შეიძლება გაიზარდოს დინამიურად, ფრენის დროს, სისტემის შეჩერების გარეშე. ამისათვის საჭიროა დროებით შეაჩეროთ და ხელახლა ჩართოთ ქეში, მაგრამ LVM-ქეშის გამორჩეული უპირატესობა, მაგალითად, bcache-სთან შედარებით არის ის, რომ ეს შეიძლება გაკეთდეს ფრენის დროს.

მოდით შევქმნათ ახალი VG ქეშირებისთვის.

#pvcreate /dev/root/cache
#pvcreate /dev/data/cache
#vgcreate cache /dev/root/cache /dev/data/cache

მოდით შევქმნათ LV ქეშირებულ მოწყობილობაზე.

#lvcreate -L 3298539077632B --name cachedata cache /dev/data/cache

აქ ჩვენ მაშინვე დავიკავეთ ყველა თავისუფალი ადგილი /dev/data/cache-ზე ისე, რომ ყველა სხვა საჭირო დანაყოფი დაუყოვნებლივ შეიქმნას /dev/root/cache-ზე. თუ რამე არასწორ ადგილას შექმენით, შეგიძლიათ გადაიტანოთ pvmove-ის გამოყენებით.

მოდით შევქმნათ და გავააქტიუროთ ქეში:

#lvcreate -y -L 64G -n cache cache /dev/root/cache
#lvcreate -y -L 1G -n cachemeta cache /dev/root/cache
#lvconvert -y --type cache-pool --cachemode writeback --chunksize 64k --poolmetadata cache/cachemeta cache/cache
#lvconvert -y --type cache --cachepool cache/cache cache/cachedata

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

64k არის მინიმალური ბლოკის ზომა დაშვებული LVM thin-ისთვის.

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

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

მოდით შევამოწმოთ რა მივიღეთ:

#lvs -a -o lv_name,lv_size,devices --units B cache
LV LSize Devices
[cache] 68719476736B cache_cdata(0)
[cache_cdata] 68719476736B /dev/root/cache(0)
[cache_cmeta] 1073741824B /dev/root/cache(16384)
cachedata 3298539077632B cachedata_corig(0)
[cachedata_corig] 3298539077632B /dev/data/cache(0)
[lvol0_pmspare] 1073741824B /dev/root/cache(16640)

მხოლოდ [cachedata_corig] უნდა იყოს განთავსებული /dev/data/cache-ზე. თუ რამე არასწორია, გამოიყენეთ pvmove.

საჭიროების შემთხვევაში შეგიძლიათ გამორთოთ ქეში ერთი ბრძანებით:

#lvconvert -y --uncache cache/cachedata

ეს კეთდება ონლაინ. LVM უბრალოდ სინქრონიზებს ქეშს დისკზე, წაშლის მას და დაარქმევს cachedata_corig-ს უკან cachedata-ად.

LVM თხელი დაყენება

მოდით უხეშად შევაფასოთ რამდენი სივრცე გვჭირდება LVM თხელი მეტამონაცემებისთვის:

#thin_metadata_size --block-size=64k --pool-size=6terabytes --max-thins=100000 -u bytes
thin_metadata_size - 3385794560 bytes estimated metadata area size for "--block-size=64kibibytes --pool-size=6terabytes --max-thins=100000"

დამრგვალეთ 4 გიგაბაიტამდე: 4294967296B

გაამრავლეთ ორზე და დაამატეთ 4194304B LVM PV მეტამონაცემებისთვის: 8594128896B
მოდით შევქმნათ ცალკე დანაყოფი NVMe RAID 1-ზე, რათა მასზე მოვათავსოთ LVM თხელი მეტამონაცემები და მათი სარეზერვო ასლი:

#lvcreate -L 8594128896B --name images root

Რისთვის..?აქ შეიძლება გაჩნდეს კითხვა: რატომ განვათავსოთ LVM თხელი მეტამონაცემები ცალკე, თუ ის მაინც იქნება ქეშირებული NVMe-ზე და სწრაფად იმუშავებს.

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

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

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

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

#pvcreate /dev/root/images
#pvcreate /dev/cache/cachedata
#vgcreate images /dev/root/images /dev/cache/cachedata
მოდით შევქმნათ აუზი:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T images/thin-pool
რატომ -Z yგარდა იმისა, რისთვისაც რეალურად არის განკუთვნილი ეს რეჟიმი - ერთი ვირტუალური მანქანიდან მონაცემების სხვა ვირტუალურ მანქანაზე გაჟონვის თავიდან ასაცილებლად, სივრცის გადანაწილებისას - ნულოვანი დამატებით გამოიყენება შემთხვევითი ჩაწერის სიჩქარის გასაზრდელად 64კ-ზე მცირე ბლოკებში. 64K-ზე ნაკლები ნებისმიერი ჩანაწერი თხელი მოცულობის ადრე გამოუყენებელ ზონაში გახდება 64K კიდეზე გასწორებული ქეში. ეს საშუალებას მისცემს ოპერაცია შესრულდეს მთლიანად ქეშის მეშვეობით, ქეშირებული მოწყობილობის გვერდის ავლით.

გადავიტანოთ LV-ები შესაბამის PV-ებზე:

#pvmove -n images/thin-pool_tdata /dev/root/images /dev/cache/cachedata
#pvmove -n images/lvol0_pmspare /dev/cache/cachedata /dev/root/images
#pvmove -n images/thin-pool_tmeta /dev/cache/cachedata /dev/root/images

მოდით შევამოწმოთ:

#lvs -a -o lv_name,lv_size,devices --units B images
LV LSize Devices
[lvol0_pmspare] 4294967296B /dev/root/images(0)
thin-pool 274877906944B thin-pool_tdata(0)
[thin-pool_tdata] 274877906944B /dev/cache/cachedata(0)
[thin-pool_tmeta] 4294967296B /dev/root/images(1024)

მოდით შევქმნათ თხელი მოცულობა ტესტებისთვის:

#lvcreate -V 64G --thin-pool thin-pool --name test images

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

#apt-get install sysstat fio

აი, როგორ შეგიძლიათ დააკვირდეთ ჩვენი შენახვის კონფიგურაციის ქცევას რეალურ დროში:

#watch 'lvs --rows --reportformat basic --quiet -ocache_dirty_blocks,cache_settings cache/cachedata && (lvdisplay cache/cachedata | grep Cache) && (sar -p -d 2 1 | grep -E "sd|nvme|DEV|md1|md2|md3|md0" | grep -v Average | sort)'

აი, როგორ შეგვიძლია შევამოწმოთ ჩვენი კონფიგურაცია:

#fio --loops=1 --size=64G --runtime=4 --filename=/dev/images/test --stonewall --ioengine=libaio --direct=1
--name=4kQD32read --bs=4k --iodepth=32 --rw=randread
--name=8kQD32read --bs=8k --iodepth=32 --rw=randread
--name=16kQD32read --bs=16k --iodepth=32 --rw=randread
--name=32KQD32read --bs=32k --iodepth=32 --rw=randread
--name=64KQD32read --bs=64k --iodepth=32 --rw=randread
--name=128KQD32read --bs=128k --iodepth=32 --rw=randread
--name=256KQD32read --bs=256k --iodepth=32 --rw=randread
--name=512KQD32read --bs=512k --iodepth=32 --rw=randread
--name=4Kread --bs=4k --rw=read
--name=8Kread --bs=8k --rw=read
--name=16Kread --bs=16k --rw=read
--name=32Kread --bs=32k --rw=read
--name=64Kread --bs=64k --rw=read
--name=128Kread --bs=128k --rw=read
--name=256Kread --bs=256k --rw=read
--name=512Kread --bs=512k --rw=read
--name=Seqread --bs=1m --rw=read
--name=Longread --bs=8m --rw=read
--name=Longwrite --bs=8m --rw=write
--name=Seqwrite --bs=1m --rw=write
--name=512Kwrite --bs=512k --rw=write
--name=256write --bs=256k --rw=write
--name=128write --bs=128k --rw=write
--name=64write --bs=64k --rw=write
--name=32write --bs=32k --rw=write
--name=16write --bs=16k --rw=write
--name=8write --bs=8k --rw=write
--name=4write --bs=4k --rw=write
--name=512KQD32write --bs=512k --iodepth=32 --rw=randwrite
--name=256KQD32write --bs=256k --iodepth=32 --rw=randwrite
--name=128KQD32write --bs=128k --iodepth=32 --rw=randwrite
--name=64KQD32write --bs=64k --iodepth=32 --rw=randwrite
--name=32KQD32write --bs=32k --iodepth=32 --rw=randwrite
--name=16KQD32write --bs=16k --iodepth=32 --rw=randwrite
--name=8KQD32write --bs=8k --iodepth=32 --rw=randwrite
--name=4kQD32write --bs=4k --iodepth=32 --rw=randwrite
| grep -E 'read|write|test' | grep -v ioengine

ფრთხილად! რესურსი!ეს კოდი ჩაატარებს 36 სხვადასხვა ტესტს, თითოეული მუშაობს 4 წამის განმავლობაში. ტესტების ნახევარი ჩასაწერია. NVMe-ზე ბევრის ჩაწერა შეგიძლიათ 4 წამში. 3 გიგაბაიტამდე წამში. ასე რომ, წერის ტესტების ყოველი გაშვება შეუძლია თქვენგან 216 გიგაბაიტამდე SSD რესურსის ჭამა.

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

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

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

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

ქეში „თანმიმდევრული“ კადრები

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

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

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

1. თითოეული თხელი ტომისთვის სახელწოდებით შექმენით სნეპშოტი სახელით .cached
2. მოდით დავაყენოთ მიგრაციის ბარიერი გონივრულ მაღალ მნიშვნელობაზე: #lvchange --quiet --cachesettings "migration_threshold=16384" cache/cachedata
3. მარყუჟში ჩვენ ვამოწმებთ ქეშში ბინძური ბლოკების რაოდენობას: #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' სანამ ნულს მივიღებთ. თუ ნული ძალიან დიდი ხნის განმავლობაში აკლია, ის შეიძლება შეიქმნას ქეშის ჩაწერის რეჟიმში დროებით გადართვით. თუმცა, ჩვენი SATA და NVMe SSD მასივების სიჩქარის მახასიათებლების, ასევე მათი TBW რესურსის გათვალისწინებით, თქვენ შეძლებთ სწრაფად დაიჭიროთ მომენტი ქეშის რეჟიმის შეცვლის გარეშე, ან თქვენი აპარატურა მთლიანად შეჭამს მის მთელ რესურსს. რამდენიმე დღის. რესურსების შეზღუდვის გამო, სისტემა, პრინციპში, ვერ იქნება 100% ჩაწერის დატვირთვის ქვეშ. ჩვენი NVMe SSD 100% ჩაწერის დატვირთვის ქვეშ მთლიანად ამოწურავს რესურსს 3-4 დღე. SATA SSD-ები მხოლოდ ორჯერ მეტხანს იმუშავებენ. მაშასადამე, ჩვენ ვივარაუდებთ, რომ დატვირთვის უმეტესი ნაწილი წადის კითხვაზე და გვაქვს უკიდურესად მაღალი აქტივობის შედარებით მოკლევადიანი აფეთქებები, კომბინირებული საშუალოდ დაბალ დატვირთვასთან წერისთვის.
4. როგორც კი დავიჭერთ (ან გავაკეთებთ) ნულს, ჩვენ ვარქმევს .cached to .committed. ძველი .committed წაშლილია.
5. სურვილისამებრ, თუ ქეში 100%-ით სავსეა, ის შეიძლება ხელახლა შეიქმნას სკრიპტით, რითაც გასუფთავდება. ნახევრად ცარიელი ქეშით, სისტემა ბევრად უფრო სწრაფად მუშაობს წერისას.
6. დააყენეთ მიგრაციის ბარიერი ნულზე: #lvchange --quiet --cachesettings "migration_threshold=0" cache/cachedata ეს დროებით ხელს შეუშლის ქეშის მთავარ მედიასთან სინქრონიზაციას.
7. ველოდებით სანამ ქეშში საკმაოდ ბევრი ცვლილება დაგროვდება #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' ან ტაიმერი გაითიშება.
8. ისევ ვიმეორებთ.

რატომ არის სირთულეები მიგრაციის ზღურბლთან დაკავშირებით...?საქმე ისაა, რომ რეალურ პრაქტიკაში „შემთხვევითი“ ჩანაწერი ფაქტობრივად არ არის სრულიად შემთხვევითი. თუ ჩვენ დავწერთ რაღაც 4 კილობაიტის ზომის სექტორს, დიდი ალბათობაა, რომ მომდევნო რამდენიმე წუთში ჩანაწერი განხორციელდება იმავე ან ერთ-ერთ მეზობელ (+- 32K) სექტორზე.

მიგრაციის ზღურბლის ნულზე დაყენებით, ჩვენ გადავადებთ ჩაწერის სინქრონიზაციას SATA SSD-ზე და ვაგროვებთ რამდენიმე ცვლილებას ერთ 64K ბლოკში ქეშში. ეს მნიშვნელოვნად დაზოგავს SATA SSD-ის რესურსს.

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

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

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

TRIM/DISCARD libvirt/KVM-ში

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

ეს კეთდება ვირტუალურ დისკებზე TRIM/DISCARD მხარდაჭერის ემულაციით. ამისათვის თქვენ უნდა შეცვალოთ კონტროლერის ტიპი virtio-scsi და შეცვალოთ xml.

#virsh edit vmname
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='writethrough' io='threads' discard='unmap'/>
<source dev='/dev/images/vmname'/>
<backingStore/>
<target dev='sda' bus='scsi'/>
<alias name='scsi0-0-0-0'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>

<controller type='scsi' index='0' model='virtio-scsi'>
<alias name='scsi0'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</controller>

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

BTRFS სარეზერვო

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

მოდით შევქმნათ ტომი სარეზერვო მოწყობილობაზე:

#lvcreate -L 256G --name backup backup

მოდით დავაფორმოთ ის BTRFS-ში:

#mkfs.btrfs /dev/backup/backup

მოდით შევქმნათ სამონტაჟო წერტილები და დავამაგროთ ფაილური სისტემის ძირეული ქვესექციები:

#mkdir /backup
#mkdir /backup/btrfs
#mkdir /backup/btrfs/root
#mkdir /backup/btrfs/back
#ln -s /boot /backup/btrfs
# cat >>/etc/fstab << EOF

/dev/mapper/root-root /backup/btrfs/root btrfs defaults,space_cache,noatime,nodiratime 0 2
/dev/mapper/backup-backup /backup/btrfs/back btrfs defaults,space_cache,noatime,nodiratime 0 2
EOF
#mount -a
#update-initramfs -u
#update-grub

მოდით შევქმნათ დირექტორიები სარეზერვო ასლისთვის:

#mkdir /backup/btrfs/back/remote
#mkdir /backup/btrfs/back/remote/root
#mkdir /backup/btrfs/back/remote/boot

მოდით შევქმნათ დირექტორია სარეზერვო სკრიპტებისთვის:

#mkdir /root/btrfs-backup

მოდით დავაკოპიროთ სკრიპტი:

ბევრი საშინელი bash კოდი. გამოიყენეთ საკუთარი რისკის ქვეშ. არ დაწერო გაბრაზებული წერილები ავტორს...#cat >/root/btrfs-backup/btrfs-backup.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

LOCK_FILE="/dev/shm/$SCRIPT_NAME.lock"
DATE_PREFIX='%Y-%m-%d'
DATE_FORMAT=$DATE_PREFIX'-%H-%M-%S'
DATE_REGEX='[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]'
BASE_SUFFIX=".@base"
PEND_SUFFIX=".@pend"
SNAP_SUFFIX=".@snap"
MOUNTS="/backup/btrfs/"
BACKUPS="/backup/btrfs/back/remote/"

function terminate ()
{
echo "$1" >&2
exit 1
}

function wait_lock()
{
flock 98
}

function wait_lock_or_terminate()
{
echo "Wating for lock..."
wait_lock || terminate "Failed to get lock. Exiting..."
echo "Got lock..."
}

function suffix()
{
FORMATTED_DATE=$(date +"$DATE_FORMAT")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function filter()
{
FORMATTED_DATE=$(date --date="$1" +"$DATE_PREFIX")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function backup()
{
SOURCE_PATH="$MOUNTS$1"
TARGET_PATH="$BACKUPS$1"
SOURCE_BASE_PATH="$MOUNTS$1$BASE_SUFFIX"
TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
TARGET_BASE_DIR="$(dirname $TARGET_BASE_PATH)"
SOURCE_PEND_PATH="$MOUNTS$1$PEND_SUFFIX"
TARGET_PEND_PATH="$BACKUPS$1$PEND_SUFFIX"
if [ -d "$SOURCE_BASE_PATH" ] then
echo "$SOURCE_BASE_PATH found"
else
echo "$SOURCE_BASE_PATH File not found creating snapshot of $SOURCE_PATH to $SOURCE_BASE_PATH"
btrfs subvolume snapshot -r $SOURCE_PATH $SOURCE_BASE_PATH
sync
if [ -d "$TARGET_BASE_PATH" ] then
echo "$TARGET_BASE_PATH found out of sync with source... removing..."
btrfs subvolume delete -c $TARGET_BASE_PATH
sync
fi
fi
if [ -d "$TARGET_BASE_PATH" ] then
echo "$TARGET_BASE_PATH found"
else
echo "$TARGET_BASE_PATH not found. Synching to $TARGET_BASE_DIR"
btrfs send $SOURCE_BASE_PATH | btrfs receive $TARGET_BASE_DIR
sync
fi
if [ -d "$SOURCE_PEND_PATH" ] then
echo "$SOURCE_PEND_PATH found removing..."
btrfs subvolume delete -c $SOURCE_PEND_PATH
sync
fi
btrfs subvolume snapshot -r $SOURCE_PATH $SOURCE_PEND_PATH
sync
if [ -d "$TARGET_PEND_PATH" ] then
echo "$TARGET_PEND_PATH found removing..."
btrfs subvolume delete -c $TARGET_PEND_PATH
sync
fi
echo "Sending $SOURCE_PEND_PATH to $TARGET_PEND_PATH"
btrfs send -p $SOURCE_BASE_PATH $SOURCE_PEND_PATH | btrfs receive $TARGET_BASE_DIR
sync
TARGET_DATE_SUFFIX=$(suffix)
btrfs subvolume snapshot -r $TARGET_PEND_PATH "$TARGET_PATH$TARGET_DATE_SUFFIX"
sync
btrfs subvolume delete -c $SOURCE_BASE_PATH
sync
btrfs subvolume delete -c $TARGET_BASE_PATH
sync
mv $SOURCE_PEND_PATH $SOURCE_BASE_PATH
mv $TARGET_PEND_PATH $TARGET_BASE_PATH
sync
}

function list()
{
LIST_TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
LIST_TARGET_BASE_DIR="$(dirname $LIST_TARGET_BASE_PATH)"
LIST_TARGET_BASE_NAME="$(basename -s .$BASE_SUFFIX $LIST_TARGET_BASE_PATH)"
find "$LIST_TARGET_BASE_DIR" -maxdepth 1 -mindepth 1 -type d -printf "%fn" | grep "${LIST_TARGET_BASE_NAME/$BASE_SUFFIX/$SNAP_SUFFIX}.$DATE_REGEX"
}

function remove()
{
REMOVE_TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
REMOVE_TARGET_BASE_DIR="$(dirname $REMOVE_TARGET_BASE_PATH)"
btrfs subvolume delete -c $REMOVE_TARGET_BASE_DIR/$2
sync
}

function removeall()
{
DATE_OFFSET="$2"
FILTER="$(filter "$DATE_OFFSET")"
while read -r SNAPSHOT ; do
remove "$1" "$SNAPSHOT"
done < <(list "$1" | grep "$FILTER")

}

(
COMMAND="$1"
shift

case "$COMMAND" in
"--help")
echo "Help"
;;
"suffix")
suffix
;;
"filter")
filter "$1"
;;
"backup")
wait_lock_or_terminate
backup "$1"
;;
"list")
list "$1"
;;
"remove")
wait_lock_or_terminate
remove "$1" "$2"
;;
"removeall")
wait_lock_or_terminate
removeall "$1" "$2"
;;
*)
echo "None.."
;;
esac
) 98>$LOCK_FILE

EOF


საერთოდ რას აკეთებს..?შეიცავს მარტივი ბრძანებების კომპლექტს BTRFS სნეპშოტების შესაქმნელად და სხვა FS-ზე კოპირებისთვის BTRFS გაგზავნის/მიღების გამოყენებით.

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

კიდევ ერთი სკრიპტი, რომელსაც ჩვენ ჩავდებთ კრონში:

კიდევ რამდენიმე bash კოდი#cat >/root/btrfs-backup/cron-daily.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

BACKUP_SCRIPT="$SCRIPT_DIR/btrfs-backup.sh"
RETENTION="-60 day"
$BACKUP_SCRIPT backup root/@
$BACKUP_SCRIPT removeall root/@ "$RETENTION"
$BACKUP_SCRIPT backup root/@home
$BACKUP_SCRIPT removeall root/@home "$RETENTION"
$BACKUP_SCRIPT backup boot/
$BACKUP_SCRIPT removeall boot/ "$RETENTION"
EOF


რას აკეთებს..?ქმნის და სინქრონიზაციას უწევს ჩამოთვლილი BTRFS ტომების ეტაპობრივ სურათებს სარეზერვო FS-ზე. ამის შემდეგ ის შლის 60 დღის წინ შექმნილ ყველა სურათს. გაშვების შემდეგ, ჩამოთვლილი ტომების დათარიღებული სნეპშოტები გამოჩნდება /backup/btrfs/back/remote/ ქვედირექტორიებში.

მოდით მივცეთ კოდის შესრულების უფლებები:

#chmod +x /root/btrfs-backup/cron-daily.sh
#chmod +x /root/btrfs-backup/btrfs-backup.sh

მოდით შევამოწმოთ და ჩავდოთ კრონში:

#/usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/btrfs-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t btrfs-backup
#cat /var/log/syslog | grep btrfs-backup
#crontab -e
0 2 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/btrfs-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t btrfs-backup


LVM თხელი სარეზერვო

მოდით შევქმნათ თხელი აუზი სარეზერვო მოწყობილობაზე:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T backup/thin-pool

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

#apt-get install gddrescue

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

#mkdir /root/lvm-thin-backup

მოდით დავაკოპიროთ სკრიპტები:

ბევრი შიგნეული...#cat >/root/lvm-thin-backup/lvm-thin-backup.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

LOCK_FILE="/dev/shm/$SCRIPT_NAME.lock"
DATE_PREFIX='%Y-%m-%d'
DATE_FORMAT=$DATE_PREFIX'-%H-%M-%S'
DATE_REGEX='[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]'
BASE_SUFFIX=".base"
PEND_SUFFIX=".pend"
SNAP_SUFFIX=".snap"
BACKUPS="backup"
BACKUPS_POOL="thin-pool"

export LVM_SUPPRESS_FD_WARNINGS=1

function terminate ()
{
echo "$1" >&2
exit 1
}

function wait_lock()
{
flock 98
}

function wait_lock_or_terminate()
{
echo "Wating for lock..."
wait_lock || terminate "Failed to get lock. Exiting..."
echo "Got lock..."
}

function suffix()
{
FORMATTED_DATE=$(date +"$DATE_FORMAT")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function filter()
{
FORMATTED_DATE=$(date --date="$1" +"$DATE_PREFIX")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function read_thin_id {
lvs --rows --reportformat basic --quiet -othin_id "$1/$2" | awk '{print $2}'
}

function read_pool_lv {
lvs --rows --reportformat basic --quiet -opool_lv "$1/$2" | awk '{print $2}'
}

function read_lv_dm_path {
lvs --rows --reportformat basic --quiet -olv_dm_path "$1/$2" | awk '{print $2}'
}

function read_lv_active {
lvs --rows --reportformat basic --quiet -olv_active "$1/$2" | awk '{print $2}'
}

function read_lv_chunk_size {
lvs --rows --reportformat basic --quiet --units b --nosuffix -ochunk_size "$1/$2" | awk '{print $2}'
}

function read_lv_size {
lvs --rows --reportformat basic --quiet --units b --nosuffix -olv_size "$1/$2" | awk '{print $2}'
}

function activate_volume {
lvchange -ay -Ky "$1/$2"
}

function deactivate_volume {
lvchange -an "$1/$2"
}

function read_thin_metadata_snap {
dmsetup status "$1" | awk '{print $7}'
}

function thindiff()
{
DIFF_VG="$1"
DIFF_SOURCE="$2"
DIFF_TARGET="$3"
DIFF_SOURCE_POOL=$(read_pool_lv $DIFF_VG $DIFF_SOURCE)
DIFF_TARGET_POOL=$(read_pool_lv $DIFF_VG $DIFF_TARGET)

if [ "$DIFF_SOURCE_POOL" == "" ] then
(>&2 echo "Source LV is not thin.")
exit 1
fi

if [ "$DIFF_TARGET_POOL" == "" ] then
(>&2 echo "Target LV is not thin.")
exit 1
fi

if [ "$DIFF_SOURCE_POOL" != "$DIFF_TARGET_POOL" ] then
(>&2 echo "Source and target LVs belong to different thin pools.")
exit 1
fi

DIFF_POOL_PATH=$(read_lv_dm_path $DIFF_VG $DIFF_SOURCE_POOL)
DIFF_SOURCE_ID=$(read_thin_id $DIFF_VG $DIFF_SOURCE)
DIFF_TARGET_ID=$(read_thin_id $DIFF_VG $DIFF_TARGET)
DIFF_POOL_PATH_TPOOL="$DIFF_POOL_PATH-tpool"
DIFF_POOL_PATH_TMETA="$DIFF_POOL_PATH"_tmeta
DIFF_POOL_METADATA_SNAP=$(read_thin_metadata_snap $DIFF_POOL_PATH_TPOOL)

if [ "$DIFF_POOL_METADATA_SNAP" != "-" ] then
(>&2 echo "Thin pool metadata snapshot already exist. Assuming stale one. Will release metadata snapshot in 5 seconds.")
sleep 5
dmsetup message $DIFF_POOL_PATH_TPOOL 0 release_metadata_snap
fi

dmsetup message $DIFF_POOL_PATH_TPOOL 0 reserve_metadata_snap
DIFF_POOL_METADATA_SNAP=$(read_thin_metadata_snap $DIFF_POOL_PATH_TPOOL)

if [ "$DIFF_POOL_METADATA_SNAP" == "-" ] then
(>&2 echo "Failed to create thin pool metadata snapshot.")
exit 1
fi

#We keep output in variable because metadata snapshot need to be released early.
DIFF_DATA=$(thin_delta -m$DIFF_POOL_METADATA_SNAP --snap1 $DIFF_SOURCE_ID --snap2 $DIFF_TARGET_ID $DIFF_POOL_PATH_TMETA)

dmsetup message $DIFF_POOL_PATH_TPOOL 0 release_metadata_snap

echo $"$DIFF_DATA" | grep -E 'different|left_only|right_only' | sed 's/</"/g' | sed 's/ /"/g' | awk -F'"' '{print $6 "t" $8 "t" $11}' | sed 's/different/copy/g' | sed 's/left_only/copy/g' | sed 's/right_only/discard/g'

}

function thinsync()
{
SYNC_VG="$1"
SYNC_PEND="$2"
SYNC_BASE="$3"
SYNC_TARGET="$4"
SYNC_PEND_POOL=$(read_pool_lv $SYNC_VG $SYNC_PEND)
SYNC_BLOCK_SIZE=$(read_lv_chunk_size $SYNC_VG $SYNC_PEND_POOL)
SYNC_PEND_PATH=$(read_lv_dm_path $SYNC_VG $SYNC_PEND)

activate_volume $SYNC_VG $SYNC_PEND

while read -r SYNC_ACTION SYNC_OFFSET SYNC_LENGTH ; do
SYNC_OFFSET_BYTES=$((SYNC_OFFSET * SYNC_BLOCK_SIZE))
SYNC_LENGTH_BYTES=$((SYNC_LENGTH * SYNC_BLOCK_SIZE))
if [ "$SYNC_ACTION" == "copy" ] then
ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SYNC_PEND_PATH" "$SYNC_TARGET"
fi

if [ "$SYNC_ACTION" == "discard" ] then
blkdiscard -o $SYNC_OFFSET_BYTES -l $SYNC_LENGTH_BYTES "$SYNC_TARGET"
fi
done < <(thindiff "$SYNC_VG" "$SYNC_PEND" "$SYNC_BASE")
}

function discard_volume()
{
DISCARD_VG="$1"
DISCARD_LV="$2"
DISCARD_LV_PATH=$(read_lv_dm_path "$DISCARD_VG" "$DISCARD_LV")
if [ "$DISCARD_LV_PATH" != "" ] then
echo "$DISCARD_LV_PATH found"
else
echo "$DISCARD_LV not found in $DISCARD_VG"
exit 1
fi
DISCARD_LV_POOL=$(read_pool_lv $DISCARD_VG $DISCARD_LV)
DISCARD_LV_SIZE=$(read_lv_size "$DISCARD_VG" "$DISCARD_LV")
lvremove -y --quiet "$DISCARD_LV_PATH" || exit 1
lvcreate --thin-pool "$DISCARD_LV_POOL" -V "$DISCARD_LV_SIZE"B --name "$DISCARD_LV" "$DISCARD_VG" || exit 1
}

function backup()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
SOURCE_PEND_LV="$SOURCE_LV$PEND_SUFFIX"
TARGET_PEND_LV="$TARGET_LV$PEND_SUFFIX"
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")
SOURCE_PEND_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_PEND_LV")
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
TARGET_PEND_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_PEND_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "Source base not found creating snapshot of $SOURCE_VG/$SOURCE_LV to $SOURCE_VG/$SOURCE_BASE_LV"
lvcreate --quiet --snapshot --name "$SOURCE_BASE_LV" "$SOURCE_VG/$SOURCE_LV" || exit 1
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
echo "Discarding $SOURCE_BASE_LV_PATH as we need to bootstrap."
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SOURCE_BASE_CHUNK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)
discard_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
sync
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found out of sync with source... removing..."
lvremove -y --quiet $TARGET_BASE_LV_PATH || exit 1
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
sync
fi
fi
SOURCE_BASE_SIZE=$(read_lv_size "$SOURCE_VG" "$SOURCE_BASE_LV")
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_VG/$TARGET_LV not found. Creating empty volume."
lvcreate --thin-pool "$BACKUPS_POOL" -V "$SOURCE_BASE_SIZE"B --name "$TARGET_BASE_LV" "$TARGET_VG" || exit 1
echo "Have to rebootstrap. Discarding source at $SOURCE_BASE_LV_PATH"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SOURCE_BASE_CHUNK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)
discard_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
TARGET_BASE_POOL=$(read_pool_lv $TARGET_VG $TARGET_BASE_LV)
TARGET_BASE_CHUNK_SIZE=$(read_lv_chunk_size $TARGET_VG $TARGET_BASE_POOL)
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
echo "Discarding target at $TARGET_BASE_LV_PATH"
discard_volume "$TARGET_VG" "$TARGET_BASE_LV"
sync
fi
if [ "$SOURCE_PEND_LV_PATH" != "" ] then
echo "$SOURCE_PEND_LV_PATH found removing..."
lvremove -y --quiet "$SOURCE_PEND_LV_PATH" || exit 1
sync
fi
lvcreate --quiet --snapshot --name "$SOURCE_PEND_LV" "$SOURCE_VG/$SOURCE_LV" || exit 1
SOURCE_PEND_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_PEND_LV")
sync
if [ "$TARGET_PEND_LV_PATH" != "" ] then
echo "$TARGET_PEND_LV_PATH found removing..."
lvremove -y --quiet $TARGET_PEND_LV_PATH
sync
fi
lvcreate --quiet --snapshot --name "$TARGET_PEND_LV" "$TARGET_VG/$TARGET_BASE_LV" || exit 1
TARGET_PEND_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_PEND_LV")
SOURCE_PEND_LV_SIZE=$(read_lv_size "$SOURCE_VG" "$SOURCE_PEND_LV")
lvresize -L "$SOURCE_PEND_LV_SIZE"B "$TARGET_PEND_LV_PATH"
activate_volume "$TARGET_VG" "$TARGET_PEND_LV"
echo "Synching $SOURCE_PEND_LV_PATH to $TARGET_PEND_LV_PATH"
thinsync "$SOURCE_VG" "$SOURCE_PEND_LV" "$SOURCE_BASE_LV" "$TARGET_PEND_LV_PATH" || exit 1
sync

TARGET_DATE_SUFFIX=$(suffix)
lvcreate --quiet --snapshot --name "$TARGET_LV$TARGET_DATE_SUFFIX" "$TARGET_VG/$TARGET_PEND_LV" || exit 1
sync
lvremove --quiet -y "$SOURCE_BASE_LV_PATH" || exit 1
sync
lvremove --quiet -y "$TARGET_BASE_LV_PATH" || exit 1
sync
lvrename -y "$SOURCE_VG/$SOURCE_PEND_LV" "$SOURCE_BASE_LV" || exit 1
lvrename -y "$TARGET_VG/$TARGET_PEND_LV" "$TARGET_BASE_LV" || exit 1
sync
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function verify()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "$SOURCE_BASE_LV_PATH not found"
exit 1
fi
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_BASE_LV_PATH not found"
exit 1
fi
activate_volume "$TARGET_VG" "$TARGET_BASE_LV"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
echo Comparing "$SOURCE_BASE_LV_PATH" with "$TARGET_BASE_LV_PATH"
cmp "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH"
echo Done...
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function resync()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "$SOURCE_BASE_LV_PATH not found"
exit 1
fi
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_BASE_LV_PATH not found"
exit 1
fi
activate_volume "$TARGET_VG" "$TARGET_BASE_LV"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SYNC_BLOCK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)

echo Syncronizing "$SOURCE_BASE_LV_PATH" to "$TARGET_BASE_LV_PATH"

CMP_OFFSET=0
while [[ "$CMP_OFFSET" != "" ]] ; do
CMP_MISMATCH=$(cmp -i "$CMP_OFFSET" "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH" | grep differ | awk '{print $5}' | sed 's/,//g' )
if [[ "$CMP_MISMATCH" != "" ]] ; then
CMP_OFFSET=$(( CMP_MISMATCH + CMP_OFFSET ))
SYNC_OFFSET_BYTES=$(( ( CMP_OFFSET / SYNC_BLOCK_SIZE ) * SYNC_BLOCK_SIZE ))
SYNC_LENGTH_BYTES=$(( SYNC_BLOCK_SIZE ))
echo "Synching $SYNC_LENGTH_BYTES bytes at $SYNC_OFFSET_BYTES from $SOURCE_BASE_LV_PATH to $TARGET_BASE_LV_PATH"
ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH"
else
CMP_OFFSET=""
fi
done
echo Done...
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function list()
{
LIST_SOURCE_VG="$1"
LIST_SOURCE_LV="$2"
LIST_TARGET_VG="$BACKUPS"
LIST_TARGET_LV="$LIST_SOURCE_VG-$LIST_SOURCE_LV"
LIST_TARGET_BASE_LV="$LIST_TARGET_LV$SNAP_SUFFIX"
lvs -olv_name | grep "$LIST_TARGET_BASE_LV.$DATE_REGEX"
}

function remove()
{
REMOVE_TARGET_VG="$BACKUPS"
REMOVE_TARGET_LV="$1"
lvremove -y "$REMOVE_TARGET_VG/$REMOVE_TARGET_LV"
sync
}

function removeall()
{
DATE_OFFSET="$3"
FILTER="$(filter "$DATE_OFFSET")"
while read -r SNAPSHOT ; do
remove "$SNAPSHOT"
done < <(list "$1" "$2" | grep "$FILTER")

}

(
COMMAND="$1"
shift

case "$COMMAND" in
"--help")
echo "Help"
;;
"suffix")
suffix
;;
"filter")
filter "$1"
;;
"backup")
wait_lock_or_terminate
backup "$1" "$2"
;;
"list")
list "$1" "$2"
;;
"thindiff")
thindiff "$1" "$2" "$3"
;;
"thinsync")
thinsync "$1" "$2" "$3" "$4"
;;
"verify")
wait_lock_or_terminate
verify "$1" "$2"
;;
"resync")
wait_lock_or_terminate
resync "$1" "$2"
;;
"remove")
wait_lock_or_terminate
remove "$1"
;;
"removeall")
wait_lock_or_terminate
removeall "$1" "$2" "$3"
;;
*)
echo "None.."
;;
esac
) 98>$LOCK_FILE

EOF


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

კიდევ ერთი სკრიპტი, რომელსაც ჩვენ დავდებთ კრონში:

ცოტა მეტი ბაშ#cat >/root/lvm-thin-backup/cron-daily.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

BACKUP_SCRIPT="$SCRIPT_DIR/lvm-thin-backup.sh"
RETENTION="-60 days"

$BACKUP_SCRIPT backup images linux-dev
$BACKUP_SCRIPT backup images win8
$BACKUP_SCRIPT backup images win8-data
#etc

$BACKUP_SCRIPT removeall images linux-dev "$RETENTION"
$BACKUP_SCRIPT removeall images win8 "$RETENTION"
$BACKUP_SCRIPT removeall images win8-data "$RETENTION"
#etc

EOF


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

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

მოდით მივცეთ უფლებები:

#chmod +x /root/lvm-thin-backup/cron-daily.sh
#chmod +x /root/lvm-thin-backup/lvm-thin-backup.sh

მოდით შევამოწმოთ და ჩავდოთ კრონში:

#/usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/lvm-thin-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t lvm-thin-backup
#cat /var/log/syslog | grep lvm-thin-backup
#crontab -e
0 3 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/lvm-thin-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t lvm-thin-backup

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

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

ვნახოთ რა მოხდა:

#time /root/btrfs-backup/cron-daily.sh
real 0m2,967s
user 0m0,225s
sys 0m0,353s

#time /root/lvm-thin-backup/cron-daily.sh
real 1m2,710s
user 0m12,721s
sys 0m6,671s

#ls -al /backup/btrfs/back/remote/*
/backup/btrfs/back/remote/boot:
total 0
drwxr-xr-x 1 root root 1260 мар 26 09:11 .
drwxr-xr-x 1 root root 16 мар 6 09:30 ..
drwxr-xr-x 1 root root 322 мар 26 02:00 .@base
drwxr-xr-x 1 root root 516 мар 6 09:39 [email protected]
drwxr-xr-x 1 root root 516 мар 6 09:39 [email protected]
...
/backup/btrfs/back/remote/root:
total 0
drwxr-xr-x 1 root root 2820 мар 26 09:11 .
drwxr-xr-x 1 root root 16 мар 6 09:30 ..
drwxr-xr-x 1 root root 240 мар 26 09:11 @.@base
drwxr-xr-x 1 root root 22 мар 26 09:11 @home.@base
drwxr-xr-x 1 root root 22 мар 6 09:39 @[email protected]
drwxr-xr-x 1 root root 22 мар 6 09:39 @[email protected]
...
drwxr-xr-x 1 root root 240 мар 6 09:39 @[email protected]
drwxr-xr-x 1 root root 240 мар 6 09:39 @[email protected]
...

#lvs -olv_name,lv_size images && lvs -olv_name,lv_size backup
LV LSize
linux-dev 128,00g
linux-dev.base 128,00g
thin-pool 1,38t
win8 128,00g
win8-data 2,00t
win8-data.base 2,00t
win8.base 128,00g
LV LSize
backup 256,00g
images-linux-dev.base 128,00g
images-linux-dev.snap.2020-03-08-10-09-11 128,00g
images-linux-dev.snap.2020-03-08-10-09-25 128,00g
...
images-win8-data.base 2,00t
images-win8-data.snap.2020-03-16-14-11-55 2,00t
images-win8-data.snap.2020-03-16-14-19-50 2,00t
...
images-win8.base 128,00g
images-win8.snap.2020-03-17-04-51-46 128,00g
images-win8.snap.2020-03-18-03-02-49 128,00g
...
thin-pool <2,09t


რა კავშირშია ეს მობუდულ თოჯინებს?

სავარაუდოდ, იმის გათვალისწინებით, რომ LVM LV ლოგიკური მოცულობები შეიძლება იყოს LVM PV ფიზიკური მოცულობები სხვა VG-ებისთვის. LVM შეიძლება იყოს რეკურსიული, მობუდარი თოჯინების მსგავსად. ეს აძლევს LVM-ს უკიდურეს მოქნილობას.

PS

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

წყარო: www.habr.com