Bu yaz biz artıq bəzi giriş mövzularını müzakirə etdik, məsələn. и . Bunlardan ikincisində biz hətta ZFS-də müxtəlif çox diskli topologiyaların performansını öyrənməyə davam edəcəyimizə söz verdik. Bu, indi hər yerdə yerləşdirilən növbəti nəsil fayl sistemidir üzrə .
Bu gün ZFS ilə tanış olmaq üçün ən yaxşı gündür, maraqlı oxucular. Sadəcə bilin ki, OpenZFS tərtibatçısı Matt Ahrensin təvazökar qiymətləndirməsində "bu, həqiqətən çətindir".
Ancaq rəqəmlərə çatmazdan əvvəl - və söz verirəm ki, olacaq - bütün səkkiz diskli ZFS konfiqurasiya variantları üçün biz danışmalıyıq. kimi Ümumiyyətlə, ZFS məlumatları diskdə saxlayır.
Zpool, vdev və cihaz
Bu tam hovuz diaqramına üç köməkçi vdev daxildir, hər sinifdən biri və RAIDz2 üçün dördü
Uyğun olmayan vdev növləri və ölçüləri hovuzu yaratmaq üçün adətən heç bir səbəb yoxdur - lakin istəsəniz, bunu etməyə heç nə mane olmur.
ZFS fayl sistemini həqiqətən başa düşmək üçün onun faktiki strukturuna yaxından baxmaq lazımdır. Birincisi, ZFS ənənəvi həcm və fayl sistemi idarəetmə təbəqələrini birləşdirir. İkincisi, o, tranzaksiya nüsxəsi-on-yazma mexanizmindən istifadə edir. Bu xüsusiyyətlər sistemin struktur olaraq adi fayl sistemlərindən və RAID massivlərindən çox fərqli olduğunu bildirir. Anlamaq üçün əsas tikinti bloklarının ilk dəsti yaddaş hovuzu (zpool), virtual cihaz (vdev) və real cihazdır (cihaz).
zpool
Zpool saxlama hovuzu ən yüksək ZFS strukturudur. Hər hovuzda bir və ya daha çox virtual cihaz var. Öz növbəsində, onların hər birində bir və ya bir neçə real cihaz (cihaz) var. Virtual hovuzlar müstəqil vahidlərdir. Bir fiziki kompüterdə iki və ya daha çox ayrı hovuz ola bilər, lakin hər biri digərlərindən tamamilə müstəqildir. Hovuzlar virtual cihazları paylaşa bilməz.
ZFS artıqlığı hovuz səviyyəsində deyil, virtual cihaz səviyyəsindədir. Hovuz səviyyəsində heç bir artıqlıq yoxdur - əgər vdev və ya xüsusi vdev itərsə, onunla birlikdə bütün hovuz da itirilir.
Müasir yaddaş hovuzları virtual cihazın keş və ya jurnalının itirilməsindən sağ çıxa bilər - baxmayaraq ki, elektrik kəsilməsi və ya sistem qəzası zamanı vdev jurnalını itirdikdə, az miqdarda çirkli məlumatı itirə bilərlər.
ZFS "məlumat zolaqlarının" bütün hovuzda yazıldığına dair ümumi bir yanlış fikir var. Bu doğru deyil. Zpool gülməli RAID0 deyil, daha çox gülməli bir proqramdır mürəkkəb dəyişən paylama mexanizmi ilə.
Əksər hallarda qeydlər mövcud virtual cihazlar arasında mövcud boş yerə görə paylanır, buna görə də nəzəri olaraq onların hamısı eyni vaxtda doldurulacaq. ZFS-in daha yeni versiyaları cari vdev istifadəsini (istifadəsini) nəzərə alır - əgər bir virtual cihaz digərindən əhəmiyyətli dərəcədə sıxdırsa (məsələn, oxu yükü səbəbindən), ən yüksək boş yer nisbətinə baxmayaraq, o, müvəqqəti olaraq yazılar üçün buraxılacaq.
Müasir ZFS yazma ayırma üsullarına daxil edilmiş təkrar emal aşkarlama mexanizmi qeyri-adi yüksək yük dövrlərində gecikməni azalda və ötürmə qabiliyyətini artıra bilər, lakin bu, belə deyil. kart blanş yavaş HDD-lərin və sürətli SSD-lərin bir hovuzda qeyri-iradi qarışdırılmasına. Belə qeyri-bərabər hovuz hələ də ən yavaş cihazın sürəti ilə işləyəcək, yəni sanki tamamilə belə cihazlardan ibarətdir.
vdev
Hər bir yaddaş hovuzu bir və ya bir neçə virtual cihazdan (vdev) ibarətdir. Öz növbəsində, hər bir vdev bir və ya bir neçə real cihazı ehtiva edir. Virtual cihazların əksəriyyəti sadə məlumatların saxlanması üçün istifadə olunur, lakin CACHE, LOG və SPECIAL daxil olmaqla bir neçə vdev köməkçi sinifləri var. Bu vdev növlərinin hər biri beş topologiyadan birinə malik ola bilər: tək cihaz, RAIDz1, RAIDz2, RAIDz3 və ya güzgü.
RAIDz1, RAIDz2 və RAIDz3 köhnə insanların ikiqat (diaqonal) paritet RAID adlandırdıqlarının xüsusi növləridir. 1, 2 və 3 hər bir məlumat zolağına neçə paritet blokunun ayrıldığını göstərir. Paritet təmin etmək üçün ayrıca disklərə sahib olmaq əvəzinə, virtual RAIDz cihazları pariteti disklər arasında yarı bərabər paylayır. RAIDz massivi paritet bloklarına malik olduğu qədər diski itirə bilər; başqa birini itirsə, uğursuz olacaq və saxlama hovuzunu özü ilə aparacaq.
Güzgü virtual cihazlarda (mirror vdev) hər blok vdev-də hər bir cihazda saxlanılır. Baxmayaraq ki, iki geniş güzgülər ən çox yayılmışdır, güzgüdə istənilən ixtiyari sayda cihaz ola bilər - daha böyük qurğularda oxu performansını və nasazlığa dözümlülüyünü yaxşılaşdırmaq üçün çox vaxt üçlük istifadə olunur. vdev güzgüsü, vdev-də ən azı bir cihaz işlək qaldığı müddətcə istənilən nasazlıqdan sağ çıxa bilər.
Tək vdevlər təbii olaraq təhlükəlidir. Belə bir virtual cihaz bir uğursuzluqdan sağ çıxmayacaq - və saxlama və ya xüsusi vdev kimi istifadə edilərsə, onun uğursuzluğu bütün hovuzun məhvinə səbəb olacaqdır. Burada çox, çox diqqətli olun.
CACHE, LOG və XÜSUSİ virtual cihazlar yuxarıda göstərilən topologiyaların hər hansı birində yaradıla bilər - lakin unutmayın ki, XÜSUSİ virtual cihazı itirmək hovuzu itirmək deməkdir, ona görə də lazımsız topologiya yüksək tövsiyə olunur.
cihaz
Bu, yəqin ki, ZFS-də başa düşmək üçün ən asan termindir - bu, sözün əsl mənasında blok təsadüfi giriş cihazıdır. Unutmayın ki, virtual qurğular fərdi cihazlardan, hovuz isə virtual cihazlardan ibarətdir.
Maqnit və ya bərk vəziyyətdə olan disklər vdev-in tikinti blokları kimi istifadə olunan ən çox yayılmış blok cihazlarıdır. Bununla belə, /dev-də deskriptoru olan istənilən cihaz bunu edəcək - beləliklə, bütün aparat RAID massivləri fərdi cihazlar kimi istifadə edilə bilər.
Sadə xam fayl vdev-in qurula biləcəyi ən vacib alternativ blok cihazlarından biridir. Test hovuzları hovuz əmrlərini yoxlamaq və hovuzda və ya verilmiş topologiyanın virtual cihazında nə qədər yer olduğunu görmək üçün çox rahat bir yoldur.
Siz bir neçə saniyə ərzində seyrək fayllardan test hovuzu yarada bilərsiniz, lakin bundan sonra bütün hovuzu və onun komponentlərini silməyi unutmayın.
Tutaq ki, siz səkkiz diskli server istəyirsiniz və 10TB (~9300 GiB) disklərdən istifadə etməyi planlaşdırırsınız, lakin hansı topologiyanın ehtiyaclarınıza ən uyğun olduğuna əmin deyilsiniz. Yuxarıdakı misalda biz saniyələr ərzində seyrək fayllardan ibarət sınaq hovuzunu qururuq və indi bilirik ki, səkkiz 2TB diskdən ibarət RAIDz10 vdev 50TiB istifadəyə yararlı tutum təmin edir.
Cihazların başqa bir xüsusi sinfi SPARE-dir. İsti dəyişdirmə cihazları, adi cihazlardan fərqli olaraq, bir virtual cihaza deyil, bütün hovuza aiddir. Hovuzdakı hər hansı vdev uğursuz olarsa və ehtiyat cihaz hovuza qoşulub əlçatandırsa, o, avtomatik olaraq təsirlənmiş vdev-ə qoşulacaq.
Təsirə məruz qalan vdev-ə qoşulduqdan sonra əvəzedici cihaz itkin cihazda olması lazım olan məlumatların surətlərini və ya yenidən qurulmasını almağa başlayır. Ənənəvi RAID-də buna "yenidənqurma" deyilir, ZFS-də isə "yenidən gümüşləşmə".
Əvəzedici cihazların uğursuz cihazları daimi olaraq əvəz etmədiyini qeyd etmək vacibdir. Bu, vdev-in deqradasiyası üçün lazım olan vaxtı azaltmaq üçün yalnız müvəqqəti əvəzdir. Administrator uğursuz vdev cihazını əvəz etdikdən sonra artıqlıq həmin daimi cihazda bərpa olunur və SPARE vdev-dən ayrılır və bütün hovuz üçün ehtiyata qayıdır.
Məlumat dəstləri, bloklar və sektorlar
ZFS səyahətimizdə başa düşülməli olan növbəti tikinti blokları daha az aparatla, daha çox məlumatların necə təşkil olunduğu və saxlandığı ilə bağlıdır. Ümumi strukturu başa düşməyimizlə təfərrüatları qarışdırmamaq üçün burada bir neçə təbəqəni - məsələn, metaslabı - atlayırıq.
Dataset
İlk dəfə məlumat dəsti yaratdıqda, o, bütün mövcud hovuz sahəsini göstərir. Sonra kvota təyin etdik - və montaj nöqtəsini dəyişdirin. Sehrli!
Zvol əsasən fayl sistemi qatından təmizlənmiş verilənlər toplusudur və biz onu burada tamamilə normal ext4 fayl sistemi ilə əvəz edirik.
ZFS məlumat dəsti standart quraşdırılmış fayl sistemi ilə təxminən eynidir. Adi bir fayl sistemi kimi, ilk baxışdan “sadəcə başqa bir qovluq” kimi görünür. Lakin adi quraşdırılmış fayl sistemləri kimi, hər bir ZFS məlumat dəsti də öz əsas xüsusiyyətlərinə malikdir.
Əvvəla, verilənlər bazası təyin edilmiş kvotaya malik ola bilər. Quraşdırsanız zfs set quota=100G poolname/datasetname, onda siz quraşdırılmış qovluğa yaza bilməyəcəksiniz /poolname/datasetname 100 GiB-dən çox.
Hər sətrin əvvəlində tire işarələrinin olub-olmamasına diqqət yetirin? Hər bir məlumat dəstinin həm ZFS iyerarxiyasında, həm də sistem montaj iyerarxiyasında öz yeri var. ZFS iyerarxiyasında heç bir ön xətt yoxdur - siz hovuzun adı ilə başlayırsınız və sonra bir məlumat dəstindən digərinə gedən yoldan başlayırsınız. Misal üçün, pool/parent/child adlı məlumat dəsti üçün child ana verilənlər bazası altında parent yaradıcı adı olan hovuzda pool.
Varsayılan olaraq, verilənlər dəstinin bağlama nöqtəsi onun ZFS iyerarxiyasındakı adına bərabər olacaq, ön xətt işarəsi - adlı hovuz pool kimi quraşdırılmışdır /pool, məlumat dəsti parent içərisinə quraşdırılmışdır /pool/parent, və uşaq məlumat dəsti child içərisinə quraşdırılmışdır /pool/parent/child. Bununla belə, məlumat dəstinin sistem quraşdırma nöqtəsi dəyişdirilə bilər.
Göstərsək zfs set mountpoint=/lol pool/parent/child, sonra məlumat dəsti pool/parent/child kimi sistemə quraşdırılmışdır /lol.
Məlumat dəstlərinə əlavə olaraq həcmləri (zvol) qeyd etməliyik. Həcm məlumat dəsti ilə təxminən eynidir, ancaq onun əslində fayl sistemi yoxdur - bu, sadəcə blok cihazıdır. Məsələn, yarada bilərsiniz zvol Adla mypool/myzvol, sonra onu ext4 fayl sistemi ilə formatlaşdırın və sonra həmin fayl sistemini quraşdırın - indi ext4 fayl sisteminiz var, lakin ZFS-in bütün təhlükəsizlik xüsusiyyətləri ilə! Bu, bir kompüterdə axmaq görünə bilər, lakin iSCSI cihazını ixrac edərkən arxa plan kimi daha məna kəsb edir.
Bloklar
Fayl bir və ya bir neçə blokla təmsil olunur. Hər blok bir virtual cihazda saxlanılır. Blokun ölçüsü adətən parametrə bərabərdir rekord ölçüsü, lakin azaldıla bilər 2^aşift, metadata və ya kiçik fayl ehtiva edərsə.
Biz həqiqətən həqiqətən Aşifti çox aşağı təyin etsəniz, böyük performans cəzası ilə zarafat etmirik
ZFS hovuzunda metadata daxil olmaqla bütün məlumatlar bloklarda saxlanılır. Hər bir məlumat dəsti üçün maksimum blok ölçüsü mülkiyyətdə müəyyən edilir recordsize (rekord ölçüsü). Qeydin ölçüsü dəyişə bilər, lakin bu, artıq məlumat dəstinə yazılmış blokların ölçüsünü və ya yerini dəyişməyəcək - bu, yalnız yeni bloklara yazıldıqları kimi təsir edir.
Başqa cür göstərilməyibsə, cari standart giriş ölçüsü 128 KiB-dir. Performans mükəmməl olmayacaq, lakin əksər hallarda dəhşətli olmayacaq. Recordsize 4K-dan 1M-ə qədər istənilən dəyərə təyin edilə bilər (əlavə parametrlərlə recordsize daha çox quraşdıra bilərsiniz, lakin bu nadir hallarda yaxşı bir fikirdir).
İstənilən blok yalnız bir faylın məlumatlarına aiddir - iki fərqli faylı bir bloka sıxışdıra bilməzsiniz. Hər bir fayl ölçüsündən asılı olaraq bir və ya bir neçə blokdan ibarətdir. Faylın ölçüsü qeyd ölçüsündən kiçikdirsə, o, daha kiçik blokda saxlanılacaq - məsələn, 2KiB faylı olan blok diskdə yalnız bir 4KiB sektorunu tutacaq.
Əgər fayl bir neçə blok tələb edəcək qədər böyükdürsə, o zaman həmin fayla daxil olan bütün girişlər ölçüdə olacaq recordsize - əsas hissəsi ola biləcək son giriş daxil olmaqla .
zvol həcmlərinin mülkü yoxdur recordsize - əvəzinə onlar ekvivalent mülkiyyətə malikdirlər volblocksize.
sektorlar
Sonuncu, ən əsas tikinti bloku sektordur. Bu, ana cihaza yazıla və ya ondan oxuna bilən ən kiçik fiziki vahiddir. Bir neçə onilliklər ərzində əksər disklər 512 baytlıq sektorlardan istifadə edirdi. Bu günlərdə əksər sürücülər 4KiB sektorları üçün konfiqurasiya edilir və bəziləri, xüsusən də SSD-lər 8KiB sektorları və ya daha böyük sektorlar üçün konfiqurasiya edilir.
ZFS sektor ölçüsünü əl ilə təyin etməyə imkan verən xüsusiyyətə malikdir. Bu əmlak ashift. Bir qədər çaşdırıcı olsa da, ashift ikinin gücüdür. Misal üçün, ashift=9 sektor ölçüsü 2^9 və ya 512 bayt deməkdir.
ZFS, yeni vdev-ə əlavə edildikdə, hər bir blok cihazı haqqında ətraflı məlumat üçün əməliyyat sistemindən xahiş edir və nəzəri olaraq bu məlumat əsasında müvafiq olaraq ashift təyin edir. Təəssüf ki, bir çox disklər Windows XP ilə uyğunluğu qorumaq üçün sektor ölçüsü haqqında yalan danışırlar (digər sektor ölçüləri olan sürücüləri başa düşə bilmirdi).
Bu o deməkdir ki, ZFS administratoruna öz cihazlarının faktiki sektor ölçüsünü bilməsi və əl ilə təyin etməsi tövsiyə olunur. ashift. Ashift çox kiçik təyin edilərsə, oxu/yazma əməliyyatlarının sayı astronomik şəkildə artır. Beləliklə, real 512KiB sektoruna 4 baytlıq "sektorlar" yazmaq, birinci "sektoru" yazmaq, sonra 4KiB sektorunu oxumaq, ikinci 512 baytlıq "sektorla dəyişdirmək, onu yenidən yeni 4KiB sektoruna yazmaq deməkdir" və s. hər giriş üçün.
Real dünyada belə bir cəza tətbiq edilməli olduğu Samsung EVO SSD-lərə təsir edir ashift=13, lakin bu SSD-lər sektor ölçüsü haqqında yalan danışır və buna görə də defolt olaraq təyin olunub ashift=9. Təcrübəli sistem administratoru bu parametri dəyişməsə, bu SSD işləyir yavaş müntəzəm maqnit HDD.
Müqayisə üçün, çox böyük olduğuna görə ashift praktiki olaraq heç bir cəza yoxdur. Həqiqi performans göstəricisi yoxdur və istifadə olunmamış məkanda artım sonsuz kiçikdir (və ya sıxılma aktiv olduqda sıfırdır). Buna görə də, hətta 512 baytlıq sektorlardan istifadə edən sürücülərin quraşdırılmasını şiddətlə tövsiyə edirik ashift=12 ya da hətta ashift=13gələcəyə inamla baxmaq.
Əmlak ashift hər bir virtual cihaz vdev üçün quraşdırılır və hovuz üçün deyil, bir çox insanın səhv düşündüyü kimi və quraşdırıldıqdan sonra dəyişmir. Təsadüfən vursan ashift Hovuza yeni vdev əlavə etdikdə, siz o hovuzu geri dönməz şəkildə aşağı performanslı cihazla çirkləndirmisiniz və bir qayda olaraq, hovuzu məhv edib yenidən başlamaqdan başqa variant yoxdur. Hətta vdev-i silmək də sizi pozulmuş parametrdən xilas etməyəcək ashift!
Kopyalama-yazma mexanizmi
Əgər adi fayl sistemi məlumatı yenidən yazmalıdırsa, o, yerləşdiyi hər bir bloku dəyişdirir
Kopyala-on-yazma fayl sistemi blokun yeni versiyasını yazır və sonra köhnə versiyanın kilidini açır
Mücərrəd olaraq, əgər blokların faktiki fiziki düzülüşünə məhəl qoymasaq, “məlumat kometası” mövcud məkanın xəritəsində soldan sağa hərəkət edən “məlumat qurduna” sadələşir.
İndi biz yazmaq üzrə surətlərin necə işlədiyi barədə yaxşı fikir əldə edə bilərik - hər bir blok birdən çox şəkilə aid ola bilər və bütün əlaqəli snapşotlar məhv edilənə qədər davam edəcək.
Copy on Write (CoW) mexanizmi ZFS-ni belə heyrətamiz bir sistem edən əsas əsasdır. Əsas konsepsiya sadədir - ənənəvi fayl sistemindən faylı dəyişdirməyi xahiş etsəniz, o, tam olaraq sizin xahiş etdiyinizi edəcək. Əgər siz kopyala-yazma fayl sistemindən eyni şeyi etməyi xahiş etsəniz, o, “yaxşı” deyəcək, lakin o, sizə yalan danışacaq.
Əvəzində, kopyala-yazma fayl sistemi dəyişdirilmiş blokun yeni versiyasını yazır və sonra köhnə blokla əlaqəni kəsmək və onu indicə yazdığınız yeni blokla əlaqələndirmək üçün faylın metadatasını yeniləyir.
Köhnə blokun bağlanması və yenisinin əlaqələndirilməsi bir əməliyyatda həyata keçirilir, buna görə də onu kəsmək olmaz - bu baş verəndən sonra gücü sıfırlasanız, faylın yeni versiyası var və daha əvvəl gücü sıfırlasanız, onda siz var. köhnə versiya. Hər halda, fayl sistemində heç bir ziddiyyət olmayacaq.
ZFS-də kopyalama-yazma yalnız fayl sistemi səviyyəsində deyil, həm də disk idarəetmə səviyyəsində baş verir. Bu o deməkdir ki, ZFS qeyddəki boşluğa həssas deyil () - sistemin qəzaya uğramasından əvvəl zolağın yalnız qismən qeydə alındığı bir fenomen, yenidən başladıqdan sonra massivin zədələnməsi. Burada zolaq atomik şəkildə yazılır, vdev həmişə ardıcıldır və .
ZIL: ZFS niyyət jurnalı
ZFS sinxron yazıları xüsusi üsulla idarə edir - onları müvəqqəti olaraq, lakin sonradan asinxron yazılarla birlikdə daimi olaraq yazmadan əvvəl dərhal ZIL-də saxlayır.
Bir qayda olaraq, ZIL-ə yazılan məlumatlar bir daha oxunmur. Ancaq bu, sistem nasazlığından sonra mümkündür
SLOG və ya ikinci dərəcəli LOG cihazı, sadəcə olaraq, ZIL-in əsas yaddaşdan ayrı saxlanıla biləcəyi xüsusi və üstünlük verilən çox sürətli vdevdir.
Qəzadan sonra ZIL-dəki bütün çirkli məlumatlar təkrar oynatılır - bu halda, ZIL SLOG-dadır, ona görə də təkrar oynatılır.
Yazıların iki əsas kateqoriyası var - sinxron (sinxron) və asinxron (async). Əksər iş yükləri üçün yazıların böyük əksəriyyəti asinxrondur - fayl sistemi onları cəmləşdirməyə və partiyalar şəklində buraxmağa imkan verir, parçalanmanı azaldır və ötürmə qabiliyyətini əhəmiyyətli dərəcədə artırır.
Sinxron yazılar tamam başqa məsələdir. Tətbiq sinxron yazmağı tələb etdikdə, fayl sisteminə deyir: "Bunu qeyri-sabit yaddaşa köçürməlisiniz. hazırda, və o vaxta qədər edə biləcəyim başqa bir şey yoxdur." Buna görə də, sinxron yazılar dərhal diskə bağlanmalıdır - və bu, parçalanmağı artırır və ya ötürmə qabiliyyətini azaldırsa, elə də olsun.
ZFS sinxron yazıları adi fayl sistemlərindən fərqli şəkildə idarə edir - onları dərhal adi yaddaşa köçürmək əvəzinə, ZFS onları ZFS Intent Log və ya ZIL adlı xüsusi saxlama sahəsinə yerləşdirir. Hiylə bu qeydlərdir həmçinin daha sonra tamamilə normal TXG-lər (Transaction Groups) kimi yaddaşa daşınmaq üçün normal asinxron yazma sorğuları ilə birlikdə toplanaraq yaddaşda qalır.
Normal işləmə zamanı ZIL yazılır və bir daha oxunmur. Bir neçə dəqiqədən sonra ZIL-dən olan qeydlər RAM-dan adi TXG-lərdə əsas yaddaşa yerləşdirildikdə, onlar ZIL-dən ayrılır. ZIL-dən bir şey oxunan yeganə vaxt hovuz idxal edərkən olur.
ZIL-də məlumat olduğu halda ZFS qəzası baş verərsə - əməliyyat sistemi qəzası və ya elektrik kəsilməsi - bu məlumatlar növbəti hovuz idxalı zamanı oxunacaq (məsələn, qəza sistemi yenidən işə salındıqda). ZIL-də nə varsa, oxunacaq, TXG-lərə qruplaşdırılacaq, əsas mağazaya təhvil veriləcək və idxal prosesi zamanı ZIL-dən ayrılacaq.
Vdev köməkçi siniflərindən biri ikinci dərəcəli LOG cihazı olan LOG və ya SLOG adlanır. Onun bir məqsədi var - ZIL-ni əsas vdev anbarında saxlamaq əvəzinə, ZIL-nin saxlanması üçün ayrıca və üstünlük verilən daha sürətli, çox yazmağa davamlı vdev cihazı ilə hovuzu təmin etmək. ZIL özü saxlama yerindən asılı olmayaraq eyni davranır, lakin LOG ilə vdev çox yüksək yazma performansına malikdirsə, sinxron yazmalar daha sürətli olacaq.
Hovuza LOG ilə vdev əlavə etmək işləmir edə bilməz asinxron yazma performansını yaxşılaşdırın - bütün yazıları ZIL-ə məcbur etsəniz belə zfs set sync=always, onlar yenə də log olmadan eyni şəkildə və eyni sürətlə TXG-də əsas yaddaşa qoşulacaqlar. Yeganə birbaşa performans təkmilləşməsi sinxron yazma gecikməsidir (çünki daha yüksək log sürətləri əməliyyatları daha sürətli edir sync).
Bununla belə, artıq çoxlu sinxron yazma tələb edən mühitdə vdev LOG dolayı yolla asinxron yazıları və keşsiz oxunuşları sürətləndirə bilər. ZIL qeydlərinin ayrıca vdev LOG-ə yüklənməsi əsas yaddaşda IOPS üçün daha az mübahisə deməkdir ki, bu da bütün oxunuşların və yazıların işini müəyyən dərəcədə yaxşılaşdırır.
Ani görüntülər
Kopyalama-yazma mexanizmi ZFS atom snapshotları və artımlı asinxron replikasiya üçün də zəruri təməldir. Aktiv fayl sistemində bütün qeydləri cari məlumatlarla qeyd edən göstərici ağacı var – siz bir şəkil çəkdiyiniz zaman sadəcə həmin göstərici ağacının surətini çıxarırsınız.
Aktiv fayl sistemində qeydin üzərinə yazıldıqda, ZFS əvvəlcə blokun yeni versiyasını istifadə olunmamış yerə yazır. Sonra blokun köhnə versiyasını cari fayl sistemindən ayırır. Ancaq bəzi snapshot köhnə bloka istinad edirsə, o, hələ də dəyişməz qalır. Həmin bloka istinad edən bütün snapshotlar məhv edilənə qədər köhnə blok əslində boş yer kimi bərpa olunmayacaq!
replikasiya
2015-ci ildə Steam kitabxanam 158 GiB idi və 126 faylı əhatə etdi. Bu, rsync üçün optimal vəziyyətə olduqca yaxındır - şəbəkə üzərində ZFS replikasiyası "yalnız" 927% daha sürətli idi.
Eyni şəbəkədə 40 GB-lıq tək Windows 7 virtual maşın təsvir faylının təkrarlanması tamamilə fərqli bir hekayədir. ZFS replikasiyası rsync-dən 289 dəfə sürətlidir və ya --inplace keçidi ilə rsync-ə zəng etmək üçün kifayət qədər biliklisinizsə, "yalnız" 161 dəfə daha sürətlidir.
VM təsviri ölçüləndə, rsync onunla miqyas verir. 1,9 TiB ölçüsü müasir VM təsviri üçün o qədər də böyük deyil - lakin o qədər böyükdür ki, ZFS replikasiyası rsync --inplace arqumenti ilə belə rsync-dən 1148 dəfə sürətlidir.
Snapshotların necə işlədiyini başa düşdükdən sonra replikasiyanın mahiyyətini dərk etmək asan olacaq. Snapshot sadəcə rekord göstəricilər ağacı olduğundan, bunu etsək belə çıxır zfs send snapshot, sonra bu ağacı və onunla əlaqəli bütün qeydləri göndəririk. Bunu keçəndə zfs send в zfs receive hədəf obyektdə o, həm blokun faktiki məzmununu, həm də blokları hədəf məlumat dəstinə istinad edən göstəricilər ağacını yazır.
İkincisi isə daha da maraqlı olur zfs send. İndi hər birində iki sistem var poolname/datasetname@1, və siz yeni bir şəkil çəkirsiniz poolname/datasetname@2. Buna görə də, mənbə hovuzunuzda var datasetname@1 и datasetname@2, və hədəf hovuzunda yalnız ilk snapshot var datasetname@1.
Çünki mənbə ilə hədəf arasında ortaq bir görüntü var datasetname@1, Biz bunu edə bilərik artımlı zfs send bunun üstündə. Sistemə deyəndə zfs send -i poolname/datasetname@1 poolname/datasetname@2, iki göstərici ağacını müqayisə edir. Yalnız mövcud olan hər hansı göstəricilər @2, açıq-aydın yeni bloklara istinad edin - buna görə də bu blokların məzmununa ehtiyacımız olacaq.
Uzaq bir sistemdə artımlı emal send eynilə sadə. Əvvəlcə axına daxil olan bütün yeni girişləri yazırıq send, və sonra bu bloklara göstəricilər əlavə edin. Voila, bizdə var @2 yeni sistemdə!
ZFS asinxron artımlı təkrarlama, rsync kimi əvvəlki qeyri-snapshot əsaslı metodlar üzərində böyük təkmilləşdirmədir. Hər iki halda, yalnız dəyişdirilmiş məlumatlar ötürülür - lakin ilk növbədə rsync olmalıdır oxumaq cəmini yoxlamaq və müqayisə etmək üçün hər iki tərəfdəki bütün məlumatları diskdən. Bunun əksinə olaraq, ZFS replikasiyası göstərici ağaclarından və ümumi görüntüdə göstərilməyən bloklardan başqa heç nə oxumur.
Quraşdırılmış sıxılma
Kopyala-on-yazma mexanizmi daxili sıxılma sistemini də sadələşdirir. Ənənəvi fayl sistemində sıxılma problemlidir - həm köhnə versiya, həm də dəyişdirilmiş məlumatların yeni versiyası eyni məkanda yerləşir.
Ömrünü 0x00000000 və s.-dən sıfırlardan ibarət meqabayt kimi başlayan faylın ortasındakı verilənləri nəzərə alsanız, onu diskin tək sektoruna sıxışdırmaq çox asandır. Bəs biz bu meqabayt sıfırları JPEG və ya psevdo-təsadüfi səs-küy kimi sıxıla bilməyən bir meqabayt məlumatla əvəz etsək nə olar? Birdən həmin meqabayt məlumat üçün bir yox, 256 4KiB sektor tələb olunacaq və həmin disk sahəsində yalnız bir sektor qorunub saxlanıldı.
ZFS-də bu problem yoxdur, çünki dəyişdirilmiş yazılar həmişə istifadə olunmamış yerə yazılır - orijinal blok yalnız bir 4 KiB sektoru tutur, lakin yeni yazma 256 yer tutacaq, lakin bu, problem deyil - bu yaxınlarda dəyişdirilmiş " orta" faylı ölçüsünün dəyişib-dəyişməməsindən asılı olmayaraq istifadə olunmamış yerə yazılacaqdı, ona görə də bu ZFS üçün tamamilə normal bir vəziyyətdir.
ZFS-in daxili sıxılma funksiyası defolt olaraq qeyri-aktivdir və sistem qoşula bilən alqoritmlər təklif edir - hazırda LZ4, gzip (1-9), LZJB və ZLE.
- LZ4 bir çox istifadə halları üçün, hətta kifayət qədər yavaş CPU-larda da olduqca sürətli sıxılma və dekompressiya və performans üstünlükləri təklif edən axın alqoritmidir.
- GZIP bütün Unix istifadəçilərinin bildiyi və sevdiyi hörmətli alqoritmdir. O, 1-cu səviyyəyə yaxınlaşdıqca artan sıxılma nisbəti və CPU istifadəsi ilə 9-9 sıxılma səviyyələri ilə həyata keçirilə bilər. Alqoritm bütün mətn (və ya digər yüksək sıxılan) istifadə halları üçün uyğundur, lakin əksər hallarda CPU problemlərinə səbəb olur. ehtiyatla, xüsusən daha yüksək səviyyələrdə.
- LZJB - ZFS-də orijinal alqoritm. Köhnəlmişdir və artıq istifadə edilməməlidir, LZ4 hər cəhətdən üstündür.
- PİS — sıfır səviyyəli kodlaşdırma, sıfır səviyyəli kodlaşdırma. Normal məlumatlara ümumiyyətlə toxunmur, lakin sıfırların böyük ardıcıllığını sıxır. Tam sıxıla bilməyən məlumat dəstləri (JPEG, MP4 və ya digər artıq sıxılmış formatlar kimi) üçün faydalıdır, çünki o, sıxıla bilməyən məlumatları nəzərə almır, lakin nəticədə yaranan qeydlərdə istifadə olunmamış yeri sıxır.
Demək olar ki, bütün istifadə halları üçün LZ4 sıxılmasını tövsiyə edirik; Sıxılmayan məlumatlarla işləyərkən performans cəzası çox kiçikdir və artım tipik məlumatlar üçün performans əhəmiyyətlidir. Windows əməliyyat sisteminin yeni quraşdırılması üçün virtual maşın şəklinin kopyalanması (təzə quraşdırılmış ƏS, hələ daxilində məlumat yoxdur) compression=lz4 ilə müqayisədə 27% daha sürətli keçdi compression=none, in .
ARC - Adaptive Replacement Cache
ZFS, bildiyimiz yeganə müasir fayl sistemidir ki, bu yaxınlarda oxunmuş blokların nüsxələrini RAM-da saxlamaq üçün əməliyyat sisteminin səhifə keşinə güvənmək əvəzinə, öz oxu keşləmə mexanizmindən istifadə edir.
Doğma keş problemsiz olmasa da - ZFS yeni yaddaş ayrılması sorğularına kernel qədər tez cavab verə bilməz, ona görə də yeni zəng malloc() ARC tərəfindən hazırda tutulan RAM tələb olunarsa, yaddaşın ayrılması uğursuz ola bilər. Ancaq ən azı indiyə qədər öz önbelleğinizi istifadə etmək üçün yaxşı səbəblər var.
MacOS, Windows, Linux və BSD daxil olmaqla bütün tanınmış müasir əməliyyat sistemləri səhifə keşini həyata keçirmək üçün LRU (Ən az istifadə olunan) alqoritmindən istifadə edir. Bu, hər oxuduqdan sonra keşlənmiş bloku "növbənin yuxarısına" itələyən və yeni keş buraxılışları (diskdən oxunmalı olan bloklar) əlavə etmək üçün lazım olduqda blokları "növbənin aşağısına" itələyən primitiv alqoritmdir. keşdən) yuxarıya.
Adətən alqoritm yaxşı işləyir, lakin böyük işləyən məlumat dəstləri olan sistemlərdə LRU asanlıqla tıxaclara gətirib çıxarır - tez-tez lazım olan blokları keşdən bir daha oxunmayacaq bloklara yer açmaq üçün çıxarır.
daha az sadəlövh bir alqoritmdir, onu "çəkili" keş hesab etmək olar. Keşlənmiş blok hər dəfə oxunduqda, bir az "ağır" olur və onu çıxarmaq çətinləşir - hətta blok çıxarıldıqdan sonra belə izlənmişdir müəyyən bir müddət ərzində. Çıxarılan, lakin sonra yenidən önbelleğe oxunması lazım olan blok da ağırlaşacaq.
Bütün bunların son nəticəsi daha yüksək vuruş nisbətinə malik bir keşdir - keş vuruşları (keşdən oxunur) və buraxılmışlar (diskdən oxunur) arasındakı nisbət. Bu son dərəcə vacib statistik göstəricidir – nəinki keş vurmaların özlərinə daha sürətli xidmət göstərilir, həm də keş buraxılışlarına daha sürətli xidmət göstərilə bilər, çünki nə qədər çox keş vurularsa, diskə paralel sorğular bir o qədər az olur və qalan buraxılışlar üçün gecikmə də bir o qədər az olur. disklə xidmət edilməlidir.
Nəticə
İndi biz ZFS-in əsas semantikasını – yazmaq üzrə kopyalamanın necə işlədiyini, həmçinin yaddaş hovuzları, virtual qurğular, bloklar, sektorlar və fayllar arasındakı əlaqələri əhatə etdikdən sonra biz real dünya performansını müzakirə etməyə hazırıq. real ədədlər.
Növbəti hissədə biz güzgülənmiş vdev və RAIDz hovuzlarının faktiki performansını bir-biri ilə müqayisə edəcəyik, həmçinin araşdırdığımız ənənəvi Linux nüvəsi RAID topologiyaları ilə müqayisə edəcəyik. .
Əvvəlcə biz yalnız əsasları - ZFS topologiyalarını əhatə etmək istədik, lakin sonra belə bir L2ARC, SLOG və Xüsusi Ayrılma kimi köməkçi vdev növlərinin istifadəsi də daxil olmaqla, ZFS-nin daha təkmil konfiqurasiyası və sazlanması haqqında danışmağa hazır olacağıq.
Mənbə: www.habr.com