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

ჰოდა, დღეს საუკეთესო დღეა ZFS-ის, ცნობისმოყვარე მკითხველების გასაცნობად. უბრალოდ იცოდეთ, რომ OpenZFS-ის დეველოპერი მეტ არენსის თავმდაბალი შეფასებით, „ეს მართლაც რთულია“.

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

Zpool, vdev და მოწყობილობა

ეს სრული აუზის დიაგრამა მოიცავს სამ დამხმარე vdev-ს, თითო კლასიდან ერთს და ოთხს RAIDz2-ისთვის

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

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

ზული

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

ZFS სიჭარბე არის ვირტუალური მოწყობილობის დონეზე და არა აუზის დონეზე. აუზის დონეზე აბსოლუტურად არ არის ზედმეტი - თუ vdev ან გამოყოფილი vdev დაიკარგება, მასთან ერთად იკარგება მთელი აუზი.

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

არსებობს გავრცელებული მცდარი მოსაზრება, რომ ZFS „მონაცემთა ზოლები“ ​​იწერება მთელ აუზზე. Ეს არ არის სიმართლე. Zpool არ არის სასაცილო RAID0, ის უფრო სასაცილოა JBOD რთული ცვლადი განაწილების მექანიზმით.

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

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

ვდევ

თითოეული საცავის აუზი შედგება ერთი ან მეტი ვირტუალური მოწყობილობისგან (vdev). თავის მხრივ, თითოეული vdev მოიცავს ერთ ან მეტ რეალურ მოწყობილობას. ვირტუალური მოწყობილობების უმეტესობა გამოიყენება მარტივი მონაცემთა შესანახად, მაგრამ არსებობს vdev დამხმარე კლასი, მათ შორის CACHE, LOG და SPECIAL. თითოეულ ამ vdev ტიპს შეიძლება ჰქონდეს ხუთიდან ერთ-ერთი ტოპოლოგია: ერთი მოწყობილობა, RAIDz1, RAIDz2, RAIDz3 ან სარკე.

RAIDz1, RAIDz2 და RAIDz3 არის სპეციალური ჯიშები, რასაც ძველი ხალხი ორმაგ (დიაგონალურ) პარიტეტულ RAID-ს უწოდებდა. 1, 2 და 3 მიუთითებს იმაზე, თუ რამდენი პარიტეტული ბლოკია გამოყოფილი მონაცემთა თითოეულ ზოლზე. იმის ნაცვლად, რომ ჰქონდეს ცალკეული დისკები პარიტეტის უზრუნველსაყოფად, ვირტუალური RAIDz მოწყობილობები ანაწილებენ პარიტეტს ნახევრად თანაბრად დისკებზე. RAIDz მასივმა შეიძლება დაკარგოს იმდენი დისკი, რამდენიც აქვს პარიტეტული ბლოკები; თუ ის დაკარგავს მეორეს, ის გაფუჭდება და თან წაიღებს საცავის აუზს.

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

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

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

მოწყობილობა

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

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

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

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

ვთქვათ, გსურთ რვადისკიანი სერვერი და გეგმავთ 10 ტბ (~ 9300 გიბ) დისკის გამოყენებას - მაგრამ დარწმუნებული არ ხართ, რომელი ტოპოლოგია საუკეთესოდ შეესაბამება თქვენს საჭიროებებს. ზემოთ მოყვანილ მაგალითში, ჩვენ ვქმნით სატესტო აუზს იშვიათი ფაილებიდან რამდენიმე წამში - და ახლა ჩვენ ვიცით, რომ RAIDz2 vdev რვა 10 TB დისკისგან უზრუნველყოფს 50 TiB გამოსაყენებელ მოცულობას.

მოწყობილობების კიდევ ერთი სპეციალური კლასი არის SPARE. Hot-swap მოწყობილობები, ჩვეულებრივი მოწყობილობებისგან განსხვავებით, ეკუთვნის მთელ აუზს და არა ერთ ვირტუალურ მოწყობილობას. თუ აუზში რომელიმე vdev მარცხდება და სათადარიგო მოწყობილობა დაკავშირებულია აუზთან და ხელმისაწვდომია, მაშინ ის ავტომატურად შეუერთდება დაზარალებულ vdev-ს.

დაზიანებულ vdev-თან დაკავშირების შემდეგ, შემცვლელი მოწყობილობა იწყებს იმ მონაცემების ასლების ან რეკონსტრუქციის მიღებას, რომლებიც უნდა იყოს დაკარგული მოწყობილობაზე. ტრადიციულ RAID-ში ამას უწოდებენ "აღდგენას", ხოლო ZFS-ში მას "ხელახალი ამუშავება".

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

მონაცემთა ნაკრები, ბლოკები და სექტორები

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

მონაცემთა ნაკრები

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

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

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

უპირველეს ყოვლისა, მონაცემთა ბაზას შეიძლება ჰქონდეს მინიჭებული კვოტა. თუ დააინსტალირეთ zfs set quota=100G poolname/datasetname, მაშინ ვერ შეძლებთ დამონტაჟებულ საქაღალდეში ჩაწერას /poolname/datasetname 100 გიბაიტზე მეტი.

შეამჩნიეთ ხაზების არსებობა და არარსებობა თითოეული ხაზის დასაწყისში? მონაცემთა თითოეულ კომპლექტს თავისი ადგილი აქვს როგორც ZFS იერარქიაში, ასევე სისტემის სამონტაჟო იერარქიაში. ZFS იერარქიაში არ არის წამყვანი ხაზგასმა - თქვენ იწყებთ აუზის სახელით და შემდეგ გეზით ერთი მონაცემთა ნაკრებიდან მეორეზე. Მაგალითად, pool/parent/child დასახელებული მონაცემთა ნაკრებისთვის child მშობლის მონაცემთა ბაზის ქვეშ parent შემოქმედებითი სახელის მქონე აუზში pool.

ნაგულისხმევად, მონაცემთა ნაკრების დამაგრების წერტილი იქნება მისი სახელის ექვივალენტი ZFS იერარქიაში, წამყვანი ხაზებით - აუზი დასახელებული pool დამონტაჟებული როგორც /pool, მონაცემთა ნაკრები parent დამონტაჟებული /pool/parentდა ბავშვის მონაცემების ნაკრები child დამონტაჟებული /pool/parent/child. თუმცა, მონაცემთა ნაკრების სისტემის დამაგრების წერტილი შეიძლება შეიცვალოს.

თუ მივუთითებთ zfs set mountpoint=/lol pool/parent/child, შემდეგ მონაცემთა ნაკრები pool/parent/child სისტემაში დამონტაჟებული როგორც /lol.

მონაცემთა ნაკრების გარდა, უნდა აღვნიშნოთ ტომები (zvols). მოცულობა დაახლოებით იგივეა, რაც მონაცემთა ნაკრები, გარდა იმისა, რომ მას რეალურად არ აქვს ფაილური სისტემა — ეს მხოლოდ ბლოკის მოწყობილობაა. მაგალითად შეგიძლიათ შექმნათ zvol სახელით mypool/myzvol, შემდეგ დააფორმატეთ იგი ext4 ფაილური სისტემით და შემდეგ დააინსტალირეთ ეს ფაილური სისტემა - ახლა თქვენ გაქვთ ext4 ფაილური სისტემა, მაგრამ ZFS-ის უსაფრთხოების ყველა მახასიათებლით! ეს შეიძლება სულელურად მოგეჩვენოთ ერთ კომპიუტერზე, მაგრამ ბევრად უფრო ლოგიკურია, როგორც backend, iSCSI მოწყობილობის ექსპორტის დროს.

ბლოკები

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

ჩვენ ნამდვილად ნამდვილად ჩვენ არ ვხუმრობთ შესრულების უზარმაზარ ჯარიმაზე, თუ ცვლას ძალიან დაბლა დააყენებთ

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

თუ სხვა რამ არ არის მითითებული, ჩანაწერის მიმდინარე ნაგულისხმევი ზომა არის 128 KiB. ეს არის ერთგვარი მკაცრი გარიგება, სადაც შესრულება არ იქნება სრულყოფილი, მაგრამ ეს არ იქნება საშინელი უმეტეს შემთხვევაში. Recordsize შეიძლება დაყენდეს ნებისმიერ მნიშვნელობაზე 4K-დან 1M-მდე (დამატებითი პარამეტრებით recordsize თქვენ შეგიძლიათ დააინსტალიროთ კიდევ უფრო მეტი, მაგრამ ეს იშვიათად არის კარგი იდეა).

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

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

zvol ტომებს არ აქვთ ქონება recordsize - სამაგიეროდ მათ აქვთ ეკვივალენტური ქონება volblocksize.

სექტორები

ბოლო, ყველაზე ძირითადი სამშენებლო ბლოკი არის სექტორი. ეს არის ყველაზე პატარა ფიზიკური ერთეული, რომლის ჩაწერა ან წაკითხვა შესაძლებელია მასპინძელ მოწყობილობიდან. რამდენიმე ათწლეულის განმავლობაში დისკების უმეტესობა იყენებდა 512 ბაიტიან სექტორებს. დღესდღეობით, დისკების უმეტესობა კონფიგურირებულია 4 KiB სექტორისთვის, ზოგი კი - განსაკუთრებით SSD - კონფიგურირებულია 8 KiB სექტორისთვის ან უფრო დიდი.

ZFS-ს აქვს ფუნქცია, რომელიც საშუალებას გაძლევთ ხელით დააყენოთ სექტორის ზომა. ეს ქონება ashift. გარკვეულწილად დამაბნეველია, ცვლა არის ორი ძალა. Მაგალითად, ashift=9 ნიშნავს სექტორის ზომას 2^9, ან 512 ბაიტს.

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

ეს ნიშნავს, რომ რეკომენდირებულია ZFS ადმინისტრატორმა იცოდეს მათი მოწყობილობების რეალური სექტორის ზომა და ხელით დააყენოს ashift. თუ ცვლა დაყენებულია ძალიან მცირე, წაკითხვის/ჩაწერის ოპერაციების რაოდენობა ასტრონომიულად იზრდება. ასე რომ, 512-ბაიტიანი "სექტორების" ჩაწერა რეალურ 4 KiB სექტორში ნიშნავს, რომ უნდა დაწეროთ პირველი "სექტორი", შემდეგ წაიკითხოთ 4 KiB სექტორი, შეცვალოთ იგი მეორე 512-ბაიტიანი "სექტორით", დაბრუნდეთ ახალში. 4 KiB სექტორი და ასე შემდეგ თითოეული ჩანაწერისთვის.

რეალურ სამყაროში, ასეთი ჯარიმა გავლენას ახდენს Samsung EVO SSD-ებზე, რაზეც ის უნდა იყოს გამოყენებული ashift=13, მაგრამ ეს SSD ცრუობს მათი სექტორის ზომაზე და, შესაბამისად, ნაგულისხმევად არის დაყენებული ashift=9. თუ გამოცდილი სისტემის ადმინისტრატორი არ შეცვლის ამ პარამეტრს, ეს SSD მუშაობს უფრო ნელა ჩვეულებრივი მაგნიტური HDD.

შედარებისთვის, ძალიან დიდი ashift პრაქტიკულად არ არის ჯარიმა. არ არსებობს რეალური შესრულების დარტყმა და გამოუყენებელი სივრცის ზრდა უსასრულოდ მცირეა (ან ნულოვანია, თუ შეკუმშვა ჩართულია). ამიტომ, ჩვენ დაჟინებით გირჩევთ, დააინსტალიროთ ის დისკებიც კი, რომლებიც იყენებენ 512 ბაიტიან სექტორებს ashift=12 или даже ashift=13რომ თავდაჯერებულად შეხედონ მომავალს.

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

კოპირება ჩაწერის მექანიზმი

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

კოპირება-ჩაწერის ფაილური სისტემა წერს ბლოკის ახალ ვერსიას და შემდეგ განბლოკავს ძველ ვერსიას

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

ახლა ჩვენ შეგვიძლია მივიღოთ კარგი წარმოდგენა იმის შესახებ, თუ როგორ მუშაობს კოპირება-ჩაწერის სნეპშოტები - თითოეული ბლოკი შეიძლება მიეკუთვნებოდეს რამდენიმე სნეპშოტს და გაგრძელდება მანამ, სანამ ყველა დაკავშირებული სნეპშოტი არ განადგურდება

Copy on Write (CoW) მექანიზმი არის ფუნდამენტური საფუძველი იმისა, რაც ZFS-ს ასეთ გასაოცარ სისტემად აქცევს. ძირითადი კონცეფცია მარტივია - თუ თქვენ სთხოვთ ტრადიციულ ფაილურ სისტემას ფაილის შეცვლას, ის ზუსტად გააკეთებს იმას, რაც თქვენ სთხოვეთ. თუ თქვენ სთხოვთ ასლის ჩაწერის ფაილურ სისტემას იგივეს გაკეთებას, ის იტყვის "კარგი" - მაგრამ მოგატყუებთ.

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

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

Copy-on-Write in ZFS ხდება არა მხოლოდ ფაილური სისტემის დონეზე, არამედ დისკის მართვის დონეზე. ეს ნიშნავს, რომ ZFS არ არის მგრძნობიარე ჩანაწერში ცარიელი სივრცის მიმართ (ხვრელი RAID-ში) - ფენომენი, როდესაც ზოლი მხოლოდ ნაწილობრივ იყო ჩაწერილი სისტემის ავარიამდე, მასივის დაზიანებით გადატვირთვის შემდეგ. აქ ზოლი იწერება ატომურად, vdev ყოველთვის თანმიმდევრულია და ბობი შენი ბიძაა.

ZIL: ZFS განზრახვის ჟურნალი

ZFS ამუშავებს სინქრონულ ჩაწერას სპეციალური გზით - ის ინახავს მათ დროებით, მაგრამ დაუყოვნებლივ ZIL-ში, სანამ მოგვიანებით მუდმივად დაწერს მათ ასინქრონულ ჩაწერასთან ერთად.

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

SLOG, ან მეორადი LOG მოწყობილობა, უბრალოდ არის სპეციალური - და სასურველია ძალიან სწრაფი - vdev, სადაც ZIL შეიძლება შეინახოს ძირითადი მეხსიერებისგან განცალკევებით.

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

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

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

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

ნორმალური მუშაობის დროს ZIL იწერება და აღარასოდეს იკითხება. როდესაც, რამდენიმე წამის შემდეგ, ჩანაწერები ZIL-დან მოთავსებულია ძირითად საცავში ჩვეულებრივ TXG-ებში RAM-დან, ისინი იშლება ZIL-დან. ZIL-დან მხოლოდ რაღაცის წაკითხვა ხდება აუზის იმპორტის დროს.

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

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

vdev-ის დამატება LOG-ით აუზში არ მუშაობს არ შეიძლება გააუმჯობესეთ ასინქრონული ჩაწერის შესრულება - მაშინაც კი, თუ თქვენ აიძულებთ ყველა ჩაწერას ZIL-ში zfs set sync=always, ისინი კვლავ იქნება დაკავშირებული TXG-ის მთავარ საცავთან იმავე გზით და იმავე ტემპით, როგორც ჟურნალის გარეშე. მუშაობის ერთადერთი პირდაპირი გაუმჯობესება არის სინქრონული ჩაწერის შეყოვნება (რადგან ჟურნალის მაღალი სიჩქარე ოპერაციებს უფრო აჩქარებს sync).

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

კადრები

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

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

რეპლიკაცია

ჩემი Steam ბიბლიოთეკა 2015 წელს იყო 158 გიბაიტი და მოიცავდა 126 ფაილს. ეს საკმაოდ ახლოსაა rsync-ისთვის ოპტიმალურ სიტუაციასთან - ZFS-ის რეპლიკაცია ქსელში იყო "მხოლოდ" 927%-ით უფრო სწრაფი.

იმავე ქსელში, Windows 40 ვირტუალური მანქანის ერთი 7 გბ-იანი გამოსახულების ფაილის გამეორება სრულიად განსხვავებული ამბავია. ZFS-ის რეპლიკაცია 289-ჯერ უფრო სწრაფია, ვიდრე rsync - ან "მხოლოდ" 161-ჯერ უფრო სწრაფი, თუ საკმარისად საზრიანი ხართ, რომ გამოიძახოთ rsync --inplace გადამრთველით.

როდესაც VM სურათი მასშტაბებს, rsync საკითხები მასშტაბის მას. 1,9 TiB ზომა არც თუ ისე დიდია თანამედროვე VM გამოსახულებისთვის - მაგრამ საკმარისად დიდია, რომ ZFS რეპლიკაცია 1148-ჯერ უფრო სწრაფია ვიდრე rsync, თუნდაც rsync --inplace არგუმენტით.

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

მეორეზე საქმე კიდევ უფრო საინტერესო ხდება zfs send. ჩვენ ახლა გვაქვს ორი სისტემა, თითოეული შეიცავს poolname/datasetname@1და თქვენ გადაიღებთ ახალ კადრს poolname/datasetname@2. ამიტომ, წყაროს აუზში გაქვთ datasetname@1 и datasetname@2, და სამიზნე აუზში არის მხოლოდ პირველი სნეფშოტი datasetname@1.

რადგან წყაროსა და სამიზნეს შორის გვაქვს საერთო სნეპშოტი datasetname@1, ჩვენ შეგვიძლია ამის გაკეთება დამატებითი zfs send მის თავზე. როცა სისტემას ვეუბნებით zfs send -i poolname/datasetname@1 poolname/datasetname@2, ის ადარებს ორ მაჩვენებლის ხეს. ნებისმიერი მითითება, რომელიც არსებობს მხოლოდ @2, აშკარად ეხება ახალ ბლოკებს - ასე რომ, ჩვენ დაგვჭირდება ამ ბლოკების შინაარსი.

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

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

ჩამონტაჟებული შეკუმშვა

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

თუ განიხილავთ მონაცემთა ნაჭერს ფაილის შუაში, რომელიც თავის სიცოცხლეს იწყებს, როგორც ნულების მეგაბაიტი 0x00000000-დან და ასე შემდეგ - ძალიან ადვილია მისი შეკუმშვა დისკზე ერთ სექტორში. მაგრამ რა მოხდება, თუ ნულების ამ მეგაბაიტს შევცვლით მეგაბაიტი შეუკუმშველი მონაცემებით, როგორიცაა JPEG ან ფსევდო შემთხვევითი ხმაური? მოულოდნელად, ამ მეგაბაიტი მონაცემს დასჭირდება არა ერთი, არამედ 256 4 KiB სექტორი და მხოლოდ ერთი სექტორი იყო დაცული ამ დისკზე.

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

ჩაშენებული ZFS შეკუმშვა ნაგულისხმევად გამორთულია და სისტემა გთავაზობთ ჩართვის ალგორითმებს - ამჟამად მოიცავს LZ4, gzip (1-9), LZJB და ZLE.

• LZ4 არის სტრიმინგის ალგორითმი, რომელიც გთავაზობთ უკიდურესად სწრაფ შეკუმშვას და დეკომპრესიას და შესრულების უპირატესობებს გამოყენების შემთხვევების უმეტესობისთვის - თუნდაც საკმაოდ ნელ CPU-ებზე.
• GZIP არის პატივცემული ალგორითმი, რომელიც Unix-ის ყველა მომხმარებელმა იცის და უყვარს. ის შეიძლება განხორციელდეს შეკუმშვის დონეებით 1-9, შეკუმშვის კოეფიციენტისა და პროცესორის მოხმარების გაზრდით, როგორც კი უახლოვდებით მე-9 დონეს. ალგორითმი კარგად შეეფერება ტექსტის (ან სხვა მაღალ შეკუმშვადი) გამოყენების შემთხვევებს, მაგრამ ხშირად იწვევს CPU-ს პრობლემებს, წინააღმდეგ შემთხვევაში - გამოიყენეთ იგი. სიფრთხილით, განსაკუთრებით მაღალ დონეზე.
• LZJB - ორიგინალური ალგორითმი ZFS-ში. მოძველებულია და აღარ უნდა გამოიყენო, LZ4 ყველანაირად სჯობს.
• ცუდად - ნულოვანი დონის კოდირება, ნულოვანი დონის კოდირება. ის საერთოდ არ ეხება ნორმალურ მონაცემებს, მაგრამ შეკუმშავს ნულების დიდ თანმიმდევრობას. სასარგებლოა სრულად შეკუმშვადი მონაცემთა ნაკრებისთვის (როგორიცაა JPEG, MP4 ან სხვა უკვე შეკუმშული ფორმატები), რადგან ის უგულებელყოფს შეკუმშვადი მონაცემებს, მაგრამ შეკუმშავს გამოუყენებელ ადგილს მიღებულ ჩანაწერებში.

ჩვენ გირჩევთ LZ4 შეკუმშვას თითქმის ყველა გამოყენების შემთხვევაში; შესრულების ჯარიმა შეუკუმშველ მონაცემებთან მუშაობისას ძალიან მცირეა და ზრდა ტიპიური მონაცემების შესრულება მნიშვნელოვანია. ვირტუალური მანქანის სურათის კოპირება Windows ოპერაციული სისტემის ახალი ინსტალაციისთვის (ახლად დაინსტალირებული OS, ჯერ არ არის მონაცემები შიგნით) compression=lz4 გავიდა 27%-ით უფრო სწრაფად, ვიდრე ერთად compression=noneIn ეს ტესტი 2015 წლიდან.

ARC - ადაპტური ჩანაცვლების ქეში

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

მიუხედავად იმისა, რომ მშობლიური ქეში არ არის უპრობლემოდ - ZFS ვერ პასუხობს მეხსიერების განაწილების ახალ მოთხოვნებს ისე სწრაფად, როგორც ბირთვი, ამიტომ ახალი ზარი malloc() მეხსიერების განაწილება შეიძლება ვერ მოხერხდეს, თუ საჭიროებს RAM-ს, რომელიც ამჟამად დაკავებულია ARC-ის მიერ. მაგრამ არსებობს კარგი მიზეზები, რომ გამოიყენოთ საკუთარი ქეში, ყოველ შემთხვევაში, ახლა.

ყველა ცნობილი თანამედროვე ოპერაციული სისტემა, მათ შორის MacOS, Windows, Linux და BSD, იყენებს LRU (სულ ცოტა ხნის წინ გამოყენებული) ალგორითმს გვერდის ქეშის დასანერგად. ეს არის პრიმიტიული ალგორითმი, რომელიც ყოველი წაკითხვის შემდეგ უბიძგებს ქეშირებულ ბლოკს „რიდის ზედა ნაწილამდე“ და უბიძგებს ბლოკებს „რიდის ბოლოში“, საჭიროებისამებრ, ახალი გამოტოვებული ქეშის დასამატებლად (ბლოკები, რომლებიც წაკითხული უნდა ყოფილიყო დისკიდან და არა ქეშიდან) ზევით.

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

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

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

დასკვნა

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

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

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

წყარო: www.habr.com