Bu bahar, bazı giriş konularını zaten tartıştık, örneğin, и . Hatta ikincisinde, ZFS'deki çeşitli çoklu disk topolojilerinin performansını incelemeye devam edeceğimize söz bile verdik. Bu, şu anda her yerde uygulanmakta olan yeni nesil dosya sistemidir: karşı .
Pekala, bugün meraklı okuyucular olan ZFS ile tanışmak için en iyi gün. OpenZFS geliştiricisi Matt Ahrens'in mütevazi görüşüne göre "gerçekten zor" olduğunu bilin.
Ancak sayılara ulaşmadan önce - ve söz veriyorum, sekiz diskli bir ZFS yapılandırması için tüm seçenekler hakkında konuşmamız gerekiyor. gibi Genel olarak, ZFS verileri diskte depolar.
Zpool, vdev ve cihaz
Bu tam havuz diyagramı, her sınıftan bir tane olmak üzere üç yardımcı vdev ve RAIDz2 için dört tane içerir
Uyumsuz vdev türleri ve boyutlarından oluşan bir havuz oluşturmak için genellikle hiçbir neden yoktur - ancak isterseniz bunu yapmanıza hiçbir engel yoktur.
ZFS dosya sistemini gerçekten anlamak için gerçek yapısına yakından bakmanız gerekir. Birincisi, ZFS, geleneksel birim ve dosya sistemi yönetimi düzeylerini birleştirir. İkincisi, işlemsel bir yazma üzerine kopyalama mekanizması kullanır. Bu özellikler, sistemin yapısal olarak geleneksel dosya sistemlerinden ve RAID dizilerinden çok farklı olduğu anlamına gelir. Anlaşılması gereken ilk temel yapı taşları seti, depolama havuzu (zpool), sanal cihaz (vdev) ve gerçek cihazdır (cihaz).
zpool
Zpool depolama havuzu, en üstteki ZFS yapısıdır. Her havuz bir veya daha fazla sanal cihaz içerir. Buna karşılık, her biri bir veya daha fazla gerçek cihaz (cihaz) içerir. Sanal havuzlar bağımsız bloklardır. Bir fiziksel bilgisayar iki veya daha fazla ayrı havuz içerebilir, ancak her biri diğerlerinden tamamen bağımsızdır. Havuzlar sanal cihazları paylaşamaz.
ZFS'nin yedekliliği, havuz düzeyinde değil, sanal aygıt düzeyindedir. Havuz düzeyinde kesinlikle fazlalık yoktur - herhangi bir sürücü vdev'si veya özel vdev'si kaybolursa, havuzun tamamı da onunla birlikte kaybolur.
Modern depolama havuzları, bir önbellek veya sanal cihaz günlüğü kaybından kurtulabilir - ancak bir elektrik kesintisi veya sistem çökmesi sırasında vdev günlüğünü kaybederlerse az miktarda kirli veri kaybedebilirler.
ZFS "veri şeritlerinin" tüm havuza yazıldığına dair yaygın bir yanılgı vardır. Bu doğru değil. Zpool hiç komik değil RAID0, oldukça komik karmaşık bir değişken dağıtım mekanizması ile.
Çoğunlukla, girişler mevcut boş alana göre mevcut sanal cihazlar arasında dağıtılır, bu nedenle teorik olarak hepsi aynı anda doldurulacaktır. ZFS'nin sonraki sürümlerinde, geçerli vdev kullanımı (kullanım) dikkate alınır - bir sanal aygıt diğerinden önemli ölçüde daha yoğunsa (örneğin, okuma yükü nedeniyle), en yüksek boşluğa sahip olmasına rağmen geçici olarak yazma için atlanır. boşluk oranı.
Modern ZFS yazma ayırma yöntemlerinde yerleşik olarak bulunan kullanım algılama mekanizması, olağandışı yüksek yük dönemlerinde gecikmeyi azaltabilir ve verimi artırabilir - ancak bunu yapmaz tam yetki yavaş HDD'lerin ve hızlı SSD'lerin bir havuzda istem dışı karıştırılmasıyla ilgili. Böyle eşitsiz bir havuz, yine en yavaş cihazın hızında, yani tamamen bu tür cihazlardan oluşuyormuş gibi çalışacaktır.
vdev
Her depolama havuzu, bir veya daha fazla sanal cihazdan (sanal cihaz, vdev) oluşur. Buna karşılık, her vdev bir veya daha fazla gerçek cihaz içerir. Çoğu sanal aygıt, basit veri depolama için kullanılır, ancak CACHE, LOG ve SPECIAL dahil olmak üzere birkaç vdev yardımcı sınıfı vardır. Bu vdev türlerinin her biri beş topolojiden birine sahip olabilir: tek cihaz (tek cihaz), RAIDz1, RAIDz2, RAIDz3 veya ayna (ayna).
RAIDz1, RAIDz2 ve RAIDz3, eski zamanların çift (çapraz) eşlikli RAID olarak adlandırdığı şeyin özel türleridir. 1, 2 ve 3, her bir veri şeridi için kaç parite bloğunun tahsis edildiğini gösterir. Eşlik için ayrı diskler yerine, RAIDz sanal aygıtları bu eşliği diskler arasında yarı eşit olarak dağıtır. Bir RAIDz dizisi, sahip olduğu eşlik blokları kadar disk kaybedebilir; başka birini kaybederse çökecek ve depolama havuzunu da beraberinde götürecek.
Yansıtılmış sanal cihazlarda (mirror vdev), her blok vdev'deki her cihazda depolanır. İki geniş aynalar en yaygın olmasına rağmen, herhangi bir sayıda cihaz bir aynada olabilir - üçlüler genellikle büyük kurulumlarda gelişmiş okuma performansı ve hata toleransı için kullanılır. Bir vdev aynası, vdev'deki en az bir cihaz çalışmaya devam ettiği sürece herhangi bir arızadan kurtulabilir.
Tek vdev'ler doğası gereği tehlikelidir. Böyle bir sanal cihaz, tek bir arızadan sağ çıkamaz - ve depolama veya özel bir vdev olarak kullanılırsa, arızası tüm havuzun yok olmasına yol açacaktır. Burada çok ama çok dikkatli olun.
CACHE, LOG ve ÖZEL VA'lar yukarıdaki topolojilerden herhangi biri kullanılarak oluşturulabilir - ancak ÖZEL VA'nın kaybının havuzun kaybı anlamına geldiğini unutmayın, bu nedenle yedekli bir topoloji şiddetle tavsiye edilir.
cihaz
Bu muhtemelen ZFS'de anlaşılması en kolay terimdir - kelimenin tam anlamıyla bir blok rasgele erişim cihazıdır. Sanal cihazların bireysel cihazlardan oluştuğunu, havuzun ise sanal cihazlardan oluştuğunu unutmayın.
Diskler - manyetik veya katı hal - vdev'nin yapı taşları olarak kullanılan en yaygın blok aygıtlardır. Ancak, tanımlayıcısı /dev olan herhangi bir aygıt iş görecektir, böylece tüm donanımsal RAID dizileri ayrı aygıtlar olarak kullanılabilir.
Basit bir ham dosya, bir vdev'nin oluşturulabileceği en önemli alternatif blok cihazlarından biridir. Test havuzları havuz komutlarını kontrol etmenin ve bir havuzda veya belirli bir topolojinin sanal cihazında ne kadar alan olduğunu görmenin çok kullanışlı bir yoludur.
Seyrek dosyalardan sadece birkaç saniye içinde bir test havuzu oluşturabilirsiniz - ancak daha sonra tüm havuzu ve bileşenlerini silmeyi unutmayın
Diyelim ki sekiz diske bir sunucu yerleştirmek istiyorsunuz ve 10 TB disk (~9300 GiB) kullanmayı planlıyorsunuz - ancak hangi topolojinin ihtiyaçlarınıza en uygun olduğundan emin değilsiniz. Yukarıdaki örnekte, seyrek dosyalardan saniyeler içinde bir test havuzu oluşturuyoruz - ve artık sekiz adet 2 TB diskten oluşan bir RAIDz10 vdev'in 50 TiB kullanılabilir kapasite sağladığını biliyoruz.
Bir başka özel cihaz sınıfı da SPARE'dir (yedek). Çalışırken değiştirilebilir cihazlar, normal cihazlardan farklı olarak tek bir sanal cihaza değil tüm havuza aittir. Havuzdaki bir vdev arızalanırsa ve havuza bağlı ve kullanılabilir bir yedek cihaz varsa, etkilenen vdev'e otomatik olarak katılır.
Etkilenen vdev'e bağlandıktan sonra yedek cihaz, eksik cihazda olması gereken verilerin kopyalarını veya yeniden yapılandırmalarını almaya başlar. Geleneksel RAID'de buna yeniden oluşturma, ZFS'de ise yeniden gümüşleme denir.
Yedek cihazların kalıcı olarak arızalı cihazların yerini almadığına dikkat etmek önemlidir. Bu, vdev'in bozulduğu süreyi azaltmak için yalnızca geçici bir değiştirmedir. Yönetici başarısız olan vdev'yi değiştirdikten sonra, bu kalıcı cihaza yedeklilik geri yüklenir ve SPARE'in vdev ile bağlantısı kesilir ve tüm havuz için yedek olarak çalışmaya geri döner.
Veri kümeleri, bloklar ve sektörler
ZFS yolculuğumuzda anlaşılması gereken bir sonraki yapı taşı seti, donanımdan çok verilerin kendisinin nasıl organize edildiği ve depolandığı hakkındadır. Genel yapıyı anlamayı sürdürürken ayrıntıları karıştırmamak için burada metaslab gibi birkaç seviyeyi atlıyoruz.
Veri seti (veri seti)
Bir veri kümesini ilk oluşturduğumuzda, tüm kullanılabilir havuz alanını gösterir. Sonra kotayı belirleriz - ve bağlama noktasını değiştiririz. Büyü!
Zvol çoğunlukla dosya sistemi katmanından arındırılmış bir veri kümesidir ve burada onu tamamen normal bir ext4 dosya sistemiyle değiştiriyoruz.
Bir ZFS veri kümesi, kabaca standart bir bağlı dosya sistemiyle aynıdır. Normal bir dosya sistemi gibi, ilk bakışta "başka bir klasör" gibi görünür. Ancak, normal takılabilir dosya sistemlerinde olduğu gibi, her ZFS veri kümesinin kendi temel özellikleri vardır.
Her şeyden önce, bir veri kümesinin atanmış bir kotası olabilir. ayarlanmışsa zfs set quota=100G poolname/datasetname, o zaman bağlı klasöre yazamayacaksınız /poolname/datasetname 100 GiB'den fazla.
Her satırın başında eğik çizgilerin varlığına - ve yokluğuna - dikkat ettiniz mi? Her veri kümesinin hem ZFS hiyerarşisinde hem de sistem bağlama hiyerarşisinde kendi yeri vardır. ZFS hiyerarşisinde başta eğik çizgi yoktur - havuz adıyla başlarsınız ve ardından bir veri kümesinden diğerine giden yolla başlarsınız. Örneğin, pool/parent/child adlı bir veri kümesi için child üst veri kümesi altında parent yaratıcı bir ada sahip bir havuzda pool.
Varsayılan olarak, veri kümesinin bağlama noktası, ZFS hiyerarşisindeki ismine eşdeğer olacaktır ve başında bir eğik çizgi vardır - havuzun adı pool olarak monte edilmiş /pool, veri seti parent monte edilmiş /pool/parentve alt veri kümesi child monte edilmiş /pool/parent/child. Ancak, veri kümesinin sistem bağlama noktası değiştirilebilir.
belirtirsek zfs set mountpoint=/lol pool/parent/child, ardından veri kümesi pool/parent/child olarak sisteme monte edilir /lol.
Veri kümelerine ek olarak, hacimlerden (zvols) bahsetmeliyiz. Bir birim kabaca bir veri kümesiyle aynıdır, tek fark aslında bir dosya sistemine sahip olmamasıdır; yalnızca bir blok aygıtıdır. Örneğin, oluşturabilirsiniz zvol Adı ile mypool/myzvol, ardından onu bir ext4 dosya sistemiyle biçimlendirin ve ardından bu dosya sistemini bağlayın - artık bir ext4 dosya sisteminiz var, ancak ZFS'nin tüm güvenlik özelliklerine sahipsiniz! Bu, tek bir makinede aptalca görünebilir, ancak bir iSCSI cihazını dışa aktarırken arka uç olarak çok daha anlamlıdır.
bloklar
Dosya bir veya daha fazla blokla temsil edilir. Her blok bir sanal cihazda saklanır. Blok boyutu genellikle parametreye eşittir. kayıt boyutu, ancak azaltılabilir 2^ kaydırmameta veri veya küçük bir dosya içeriyorsa.
Biz gerçekten gerçekten çok küçük vites değiştirirseniz büyük performans cezası hakkında şaka yapmıyorum
Bir ZFS havuzunda, meta veriler dahil tüm veriler bloklarda saklanır. Her veri seti için maksimum blok boyutu, özellikte tanımlanır recordsize (kayıt boyutu). Kayıt boyutu değiştirilebilir, ancak bu, halihazırda veri kümesine yazılmış herhangi bir bloğun boyutunu veya konumunu değiştirmez - yalnızca yeni blokları yazılırken etkiler.
Aksi belirtilmedikçe, geçerli varsayılan kayıt boyutu 128 KiB'dir. Performansın mükemmel olmadığı bir tür zor takas, ancak çoğu durumda da korkunç değil. Recordsize 4K ile 1M arasında herhangi bir değere ayarlanabilir (gelişmiş ayarlarla) recordsize daha fazlasını da kurabilirsiniz, ancak bu nadiren iyi bir fikirdir).
Herhangi bir blok, yalnızca bir dosyanın verilerini ifade eder - iki farklı dosyayı bir bloğa sıkıştıramazsınız. Her dosya, boyutuna bağlı olarak bir veya daha fazla bloktan oluşur. Dosya boyutu kayıt boyutundan küçükse, daha küçük bir blok boyutunda depolanır - örneğin, 2 KiB dosyasına sahip bir blok, diskte yalnızca bir 4 KiB sektörü kaplar.
Dosya yeterince büyükse ve birkaç blok gerektiriyorsa, bu dosyaya sahip tüm kayıtlar aynı boyutta olacaktır. recordsize - ana kısmı olabilecek son giriş dahil .
zvols'un bir özelliği yok recordsize — bunun yerine eşdeğer bir özelliği var volblocksize.
sektörler
Son ve en temel yapı taşı sektördür. Altta yatan cihaza yazılabilen veya cihazdan okunabilen en küçük fiziksel birimdir. Birkaç on yıl boyunca çoğu disk 512 baytlık sektörler kullandı. Son zamanlarda, çoğu disk 4 KiB sektörü için yapılandırılmıştır ve bazılarında - özellikle SSD'lerde - 8 veya daha fazla KiB sektörü vardır.
ZFS sistemi, sektör boyutunu manuel olarak ayarlamanıza izin veren bir özelliğe sahiptir. Bu mülk ashift. Biraz kafa karıştırıcı bir şekilde, vites değiştirme ikinin gücüdür. Örneğin, ashift=9 2^9 veya 512 bayt sektör boyutu anlamına gelir.
ZFS, yeni bir vdev'e eklendiğinde her bir blok cihaz hakkında ayrıntılı bilgi için işletim sistemini sorgular ve teorik olarak bu bilgiye göre ashift'i otomatik olarak kurar. Ne yazık ki, birçok sürücü Windows XP ile uyumluluğu korumak için sektör boyutları hakkında yalan söylüyor (diğer sektör boyutlarına sahip sürücüleri anlayamıyordu).
Bu, bir ZFS yöneticisine cihazlarının gerçek sektör boyutunu bilmesi ve manuel olarak ayarlaması gerektiği anlamına gelir. ashift. Ashift çok düşük ayarlanırsa, okuma / yazma işlemlerinin sayısı astronomik olarak artar. Bu nedenle, 512 baytlık "sektörleri" gerçek bir 4 KiB sektöre yazmak, ilk "sektörü" yazmak, ardından 4 KiB sektörü okumak, onu ikinci bir 512 baytlık "sektör" ile değiştirmek, yeni sektöre geri yazmak anlamına gelir. Her giriş için 4 KiB sektörü vb.
Gerçek dünyada, böyle bir ceza, Samsung EVO SSD'leri vurur; ashift=13, ancak bu SSD'ler sektör boyutları hakkında yalan söyler ve bu nedenle varsayılan değer olarak ayarlanmıştır. ashift=9. Deneyimli bir sistem yöneticisi bu ayarı değiştirmezse bu SSD çalışır. yavaş geleneksel manyetik HDD.
Karşılaştırma için, çok büyük boyut için ashift pratikte hiçbir cezası yoktur. Gerçek bir performans kaybı yoktur ve kullanılmayan alandaki artış çok küçüktür (veya sıkıştırma etkinken sıfırdır). Bu nedenle, 512 baytlık sektörler kullanan sürücülerin bile yüklemesini şiddetle tavsiye ederiz. ashift=12 veya ashift=13geleceğe güvenle bakmak.
özellik ashift her vdev sanal aygıtı için ayarlanır ve havuz için değil, birçok kişinin yanlışlıkla düşündüğü gibi - ve kurulumdan sonra değişmez. Yanlışlıkla vurursanız ashift Bir havuza yeni bir vdev eklediğinizde, o havuzu düşük performanslı bir cihazla geri dönüşü olmayan bir şekilde kirletmiş olursunuz ve genellikle havuzu yok edip baştan başlamaktan başka çareniz kalmaz. Vdev'i kaldırmak bile sizi bozuk bir yapılandırmadan kurtarmaz ashift!
Yazma sırasında kopyalama mekanizması
Normal bir dosya sisteminin verilerin üzerine yazması gerekiyorsa, bulunduğu her bloğu değiştirir.
Yazma üzerine kopyalama dosya sistemi, yeni bir blok sürümü yazar ve ardından eski sürümün kilidini açar
Özetle, blokların gerçek fiziksel konumlarını göz ardı edersek, o zaman "veri kuyruklu yıldızımız", kullanılabilir alan haritası boyunca soldan sağa hareket eden bir "veri solucanı" olarak basitleştirilir.
Artık yazarken kopyalanan anlık görüntülerin nasıl çalıştığına dair iyi bir fikir edinebiliriz - her blok birden fazla anlık görüntüye ait olabilir ve ilişkili tüm anlık görüntüler yok edilene kadar devam eder.
Copy on Write (CoW) mekanizması, ZFS'yi bu kadar harika bir sistem yapan şeyin temel temelidir. Temel konsept basittir - geleneksel bir dosya sisteminden bir dosyayı değiştirmesini isterseniz, tam olarak istediğiniz şeyi yapacaktır. Bir kopya üzerine yazma dosya sisteminden aynısını yapmasını isterseniz, "tamam" diyecek ama size yalan söyleyecektir.
Bunun yerine, bir yazma üzerine kopya dosya sistemi, değiştirilen bloğun yeni bir sürümünü yazar ve ardından dosyanın meta verilerini güncelleyerek eski bloğun bağlantısını kaldırır ve az önce yazdığınız yeni bloğu ilişkilendirir.
Eski bloğun ayrılması ve yenisinin bağlanması tek bir işlemde yapılır, bu nedenle kesintiye uğramaz - bu olaydan sonra gücü kapatırsanız, dosyanın yeni bir sürümüne sahip olursunuz ve erken kapatırsanız eski sürüme sahip olursunuz. . Her durumda, dosya sisteminde herhangi bir çakışma olmayacaktır.
ZFS'de yazma sırasında kopyalama yalnızca dosya sistemi düzeyinde değil, aynı zamanda disk yönetimi düzeyinde de gerçekleşir. Bu, ZFS'nin beyaz boşluktan etkilenmediği anlamına gelir () - sistem çökmeden önce şeridin yalnızca kısmen kayıt yapmak için zamanı olduğu ve yeniden başlatmanın ardından dizinin zarar gördüğü bir fenomen. Burada şerit atomik olarak yazılır, vdev her zaman sıralıdır ve .
ZIL: ZFS amaç günlüğü
ZFS sistemi, senkronize yazmaları özel bir şekilde ele alır - geçici olarak ancak hemen ZIL'de depolar ve daha sonra asenkron yazmalarla birlikte kalıcı olarak yazmadan önce.
Tipik olarak, bir ZIL'e yazılan veriler bir daha asla okunmaz. Ancak bir sistem çökmesinden sonra mümkündür.
SLOG veya ikincil LOG cihazı, ZIL'in ana depolamadan ayrı olarak depolanabildiği özel ve tercihen çok hızlı bir vdev'dir.
Bir kilitlenmeden sonra, ZIL'deki tüm kirli veriler yeniden oynatılır - bu durumda ZIL, SLOG'tadır, dolayısıyla oradan yeniden oynatılır
Yazma işlemlerinin iki ana kategorisi vardır - eşzamanlı (eşzamanlı) ve eşzamansız (eşzamansız). Çoğu iş yükü için, yazma işlemlerinin büyük çoğunluğu zaman uyumsuzdur - dosya sistemi bunların toplu halde toplanmasına ve yayınlanmasına izin vererek parçalanmayı azaltır ve verimi büyük ölçüde artırır.
Senkronize kayıtlar tamamen farklı bir konudur. Bir uygulama senkronize yazma isteğinde bulunduğunda, dosya sistemine şunu söyler: "Bunu geçici olmayan belleğe kaydetmeniz gerekir. hemen şimdio zamana kadar yapabileceğim başka bir şey yok." Bu nedenle, eşzamanlı yazma işlemleri diske hemen kaydedilmelidir ve bu, parçalanmayı artırıyor veya verimi düşürüyorsa, öyle olsun.
ZFS, senkronize yazmaları normal dosya sistemlerinden farklı şekilde işler; bunları hemen normal depolamaya işlemek yerine, ZFS Amaç Günlüğü veya ZIL adı verilen özel bir depolama alanına kaydeder. İşin püf noktası, bu kayıtların ayrıca normal eşzamansız yazma istekleriyle birlikte toplanarak bellekte kalır ve daha sonra tamamen normal TXG'ler (İşlem Grupları) olarak depolamaya aktarılır.
Normal çalışmada, ZIL'e yazılır ve bir daha asla okunmaz. Birkaç dakika sonra, ZIL'den gelen kayıtlar, RAM'den sıradan TXG'lerde ana depolamaya işlendiğinde, ZIL'den ayrılırlar. ZIL'den bir şeyin okunduğu tek zaman havuzun içe aktarıldığı zamandır.
ZIL'de veri varken ZFS başarısız olursa - bir işletim sistemi çökmesi veya elektrik kesintisi - bu veriler bir sonraki havuz içe aktarımı sırasında (örneğin, acil durum sistemi yeniden başlatıldığında) okunacaktır. ZIL'deki her şey okunacak, TXG'ler halinde gruplanacak, ana depolamaya işlenecek ve ardından içe aktarma işlemi sırasında ZIL'den ayrılacaktır.
Vdev yardımcı sınıflarından biri, LOG'un ikincil aygıtı olan LOG veya SLOG olarak adlandırılır. Tek bir amacı vardır - ZIL'i ana vdev deposunda depolamak yerine, havuza ZIL'i depolamak için ayrı ve tercihen çok daha hızlı, çok yazmaya dayanıklı bir vdev sağlamak. ZIL'in kendisi, nerede depolanırsa saklansın aynı şekilde davranır, ancak LOG vdev çok yüksek yazma performansına sahipse, senkronize yazma işlemleri daha hızlı olacaktır.
Havuza LOG ile bir vdev eklemek çalışmıyor Yapamam ile tüm yazmaları ZIL'e zorlasanız bile eşzamansız yazma performansını iyileştirin zfs set sync=alwaysTXG'deki ana depolamaya günlük olmadan da aynı şekilde ve aynı hızda bağlanacaklar. Tek doğrudan performans iyileştirmesi, eşzamanlı yazmaların gecikmesidir (çünkü daha hızlı günlük, işlemleri hızlandırır). sync).
Ancak, zaten çok sayıda eşzamanlı yazma gerektiren bir ortamda, vdev LOG dolaylı olarak eşzamansız yazmaları ve önbelleğe alınmamış okumaları hızlandırabilir. ZIL girişlerini ayrı bir vdev LOG'a boşaltmak, birincil depolamada IOPS için daha az çekişme anlamına gelir, bu da tüm okuma ve yazmaların performansını bir dereceye kadar artırır.
anlık görüntüler
Yazma üzerine kopyalama mekanizması ayrıca ZFS atomik anlık görüntüleri ve artımlı eşzamansız çoğaltma için gerekli bir temeldir. Etkin dosya sistemi, mevcut verilerle tüm kayıtları işaretleyen bir işaretçi ağacına sahiptir - bir anlık görüntü aldığınızda, bu işaretçi ağacının bir kopyasını oluşturmanız yeterlidir.
Etkin dosya sistemindeki bir kaydın üzerine yazıldığında, ZFS önce yeni blok sürümünü kullanılmayan alana yazar. Ardından, bloğun eski sürümünü mevcut dosya sisteminden ayırır. Ancak bazı anlık görüntüler eski bloğa atıfta bulunuyorsa, yine de değişmeden kalır. Bu bloğa atıfta bulunan tüm anlık görüntüler yok edilene kadar eski blok aslında boş alan olarak geri yüklenmeyecek!
çoğaltma
2015'teki Steam kütüphanem 158 GiB'di ve 126 dosya içeriyordu. Bu, rsync için en uygun duruma oldukça yakındır - ağ üzerinden ZFS çoğaltması "yalnızca" %927 daha hızlıydı.
Aynı ağ üzerinde, tek bir 40 GB Windows 7 sanal makine görüntü dosyasını çoğaltmak tamamen farklı bir hikaye. ZFS çoğaltması, rsync'ten 289 kat daha hızlıdır veya rsync'i --inplace ile çağıracak kadar bilgiliyseniz "yalnızca" 161 kat daha hızlıdır.
Bir VM görüntüsü ölçeklendiğinde, rsync sorunları onunla birlikte ölçeklenir. 1,9 TiB, modern bir VM görüntüsü için o kadar büyük değil - ancak rsync'in --inplace bağımsız değişkeniyle bile ZFS çoğaltmasının rsync'ten 1148 kat daha hızlı olmasına yetecek kadar büyük
Anlık görüntülerin nasıl çalıştığını anladığınızda, çoğaltmanın özünü kavramak kolay olacaktır. Anlık görüntü, yalnızca kayıtlara yönelik bir işaretçiler ağacı olduğundan, zfs send anlık görüntü, ardından hem bu ağacı hem de onunla ilişkili tüm kayıtları göndeririz. Bunu gönderdiğimizde zfs send в zfs receive hedefte, hem bloğun gerçek içeriğini hem de blokları hedef veri kümesine yönlendiren işaretçiler ağacını yazar.
Saniyede işler daha da ilginçleşiyor zfs send. Artık her biri aşağıdakileri içeren iki sistemimiz var: poolname/datasetname@1ve yeni bir anlık görüntü alırsınız poolname/datasetname@2. Bu nedenle, orijinal havuzda sahip olduğunuz datasetname@1 и datasetname@2ve şimdiye kadar hedef havuzda yalnızca ilk anlık görüntü datasetname@1.
Kaynak ve hedef arasında ortak bir anlık görüntüye sahip olduğumuz için datasetname@1, yapabiliriz artımlı zfs send üzerinde. Sisteme söylediğimizde zfs send -i poolname/datasetname@1 poolname/datasetname@2, iki işaretçi ağacını karşılaştırır. Yalnızca içinde bulunan tüm işaretçiler @2, açıkça yeni bloklara atıfta bulunur - bu nedenle bu blokların içeriğine ihtiyacımız var.
Uzak bir sistemde, artımlı bir send kadar basit. İlk önce akışa dahil olan tüm yeni girişleri yazıyoruz sendve ardından bu bloklara işaretçiler ekleyin. işte bizde var @2 yeni sistemde!
ZFS eşzamansız artımlı çoğaltma, rsync gibi daha önceki anlık görüntü tabanlı olmayan yöntemlere göre çok büyük bir gelişmedir. Her iki durumda da, yalnızca değiştirilen veriler aktarılır - ancak önce rsync gerekir okumak toplamı kontrol etmek ve karşılaştırmak için her iki taraftaki tüm verileri diskten alın. Buna karşılık, ZFS çoğaltması, işaretçi ağaçlarından ve paylaşılan anlık görüntüde bulunmayan tüm bloklardan başka bir şey okumaz.
Dahili sıkıştırma
Yazma sırasında kopyalama mekanizması, satır içi sıkıştırma sistemini de basitleştirir. Geleneksel bir dosya sisteminde sıkıştırma sorunludur - değiştirilen verilerin hem eski sürümü hem de yeni sürümü aynı alanda bulunur.
0x00000000 ve benzeri sıfırlardan oluşan bir megabayt olarak hayata başlayan bir dosyanın ortasındaki bir veri parçasını düşünürsek, onu diskte bir sektöre sıkıştırmak çok kolaydır. Ancak bu megabaytlık sıfırları JPEG veya sözde rastgele gürültü gibi bir megabaytlık sıkıştırılamaz veriyle değiştirirsek ne olur? Beklenmedik bir şekilde, bu megabayt veri bir değil, 256 4 KiB sektör gerektirecek ve diskteki bu yerde yalnızca bir sektör ayrılmıştır.
Değiştirilen kayıtlar her zaman kullanılmayan alana yazıldığı için ZFS'de bu sorun yoktur - orijinal blok yalnızca bir 4 KiB sektörü kaplar ve yeni kayıt 256'yı kaplar, ancak bu bir sorun değildir - yakın zamanda değiştirilmiş bir parça " orta", boyutu değişse de değişmese de kullanılmayan alana yazılacaktır, bu nedenle ZFS için bu oldukça normal bir durumdur.
Yerel ZFS sıkıştırması varsayılan olarak devre dışıdır ve sistem şu anda LZ4, gzip (1-9), LZJB ve ZLE olmak üzere takılabilir algoritmalar sunar.
- LZ4 oldukça yavaş CPU'larda bile çoğu kullanım durumu için son derece hızlı sıkıştırma ve açma ve performans avantajları sunan bir akış algoritmasıdır.
- GZIP tüm Unix kullanıcılarının bildiği ve sevdiği saygıdeğer bir algoritmadır. 1-9 arası sıkıştırma seviyeleriyle uygulanabilir, 9. seviyeye yaklaştıkça sıkıştırma oranı ve CPU kullanımı artar. Algoritma, tüm metin (veya diğer yüksek oranda sıkıştırılabilir) kullanım durumları için çok uygundur, ancak bunun dışında genellikle CPU sorunlarına neden olur - kullanın özellikle daha yüksek seviyelerde dikkatle.
- LZJB ZFS'deki orijinal algoritmadır. Kullanımdan kaldırılmıştır ve artık kullanılmamalıdır, LZ4 onu her yönden geride bırakmaktadır.
- ZLE - sıfır seviyeli kodlama, Sıfır Seviyeli Kodlama. Normal verilere hiç dokunmaz, ancak büyük sıfır dizilerini sıkıştırır. Tamamen sıkıştırılamaz veri kümeleri (JPEG, MP4 veya diğer zaten sıkıştırılmış biçimler gibi) için kullanışlıdır çünkü sıkıştırılamaz verileri yok sayar ancak sonuçta ortaya çıkan kayıtlarda kullanılmayan alanı sıkıştırır.
Neredeyse tüm kullanım durumları için LZ4 sıkıştırmasını öneriyoruz; sıkıştırılamaz verilerle karşılaşıldığında ortaya çıkan performans cezası çok küçüktür ve büyüme tipik veriler için performans önemlidir. Windows işletim sisteminin (yeni yüklenmiş işletim sistemi, henüz içinde veri yok) yeni kurulumu için bir sanal makine görüntüsünün kopyalanması compression=lz4 ile olduğundan %27 daha hızlı geçti compression=noneIçinde .
ARC - uyarlanabilir değiştirme önbelleği
ZFS, son okunan blokların kopyalarını RAM'de depolamak için işletim sisteminin sayfa önbelleğine güvenmek yerine kendi okuma önbelleğe alma mekanizmasını kullanan bildiğimiz tek modern dosya sistemidir.
Yerel önbellek sorunsuz olmasa da - ZFS, yeni bellek ayırma isteklerine çekirdek kadar hızlı yanıt veremez, bu nedenle yeni zorluk malloc() şu anda ARC tarafından kullanılan RAM'e ihtiyacı varsa, bellek ayırma işlemi başarısız olabilir. Ancak en azından şimdilik kendi önbelleğinizi kullanmak için iyi nedenler var.
MacOS, Windows, Linux ve BSD dahil bilinen tüm modern işletim sistemleri, sayfa önbelleğini uygulamak için LRU (En Son Kullanılan) algoritmasını kullanır. Bu, her okumadan sonra önbelleğe alınmış bloğu "sıranın yukarısına" iten ve yeni önbellek kayıplarını (önbellekten değil, diskten okunması gereken bloklar) eklemek için gerektiğinde blokları "sıranın aşağısına" iten ilkel bir algoritmadır. yukarı.
Algoritma genellikle iyi çalışır, ancak büyük çalışan veri kümelerine sahip sistemlerde LRU, önbellekten bir daha asla okunmayacak olan bloklara yer açmak için sık ihtiyaç duyulan blokları kaldırarak kolayca atmaya yol açar.
"ağırlıklı" bir önbellek olarak düşünülebilecek çok daha az saf bir algoritmadır. Önbelleğe alınmış bir blok her okunduğunda, biraz "ağır" hale gelir ve çıkarılması zorlaşır - ve hatta bir bloğu çıkardıktan sonra bile izlenen belirli bir süre içinde. Tahliye edilen ancak daha sonra önbelleğe geri okunması gereken bir blok da "ağır" hale gelecektir.
Tüm bunların nihai sonucu, çok daha yüksek isabet oranına sahip bir önbellek, önbellek isabetleri (önbellekten gerçekleştirilen okumalar) ve önbellek kaçırmaları (diskten okumalar) arasındaki orandır. Bu son derece önemli bir istatistiktir - yalnızca önbellek isabetlerinin kendileri büyüklük sıralarında daha hızlı hizmet vermekle kalmaz, aynı zamanda önbellek isabetleri daha hızlı sunulabilir, çünkü önbellek isabetleri ne kadar fazla olursa, eşzamanlı disk istekleri o kadar az olur ve geri kalan kayıplar için gecikme süresi o kadar düşük olur. disk ile servis edilecektir.
Sonuç
ZFS'nin temel anlamını (yazma üzerine kopyalamanın yanı sıra depolama havuzları, sanal aygıtlar, bloklar, sektörler ve dosyalar arasındaki ilişkilerin) nasıl çalıştığını öğrendikten sonra, gerçek dünya performansını gerçek sayılarla tartışmaya hazırız.
Bir sonraki bölümde, ikizlenmiş vdev'ler ve RAIDz içeren havuzların gerçek performansına, birbirlerine ve ayrıca incelediğimiz geleneksel Linux çekirdeği RAID topolojilerine karşı bir göz atacağız. .
İlk başta, yalnızca temel bilgileri - ZFS topolojilerinin kendilerini - ele almak istedik, ancak daha sonra bu L2ARC, SLOG ve Özel Tahsis gibi yardımcı vdev türlerinin kullanımı da dahil olmak üzere ZFS'nin daha gelişmiş kurulumu ve ayarlanması hakkında konuşmaya hazırlanalım.
Kaynak: habr.com