ZFS yazı dizisi vol. 1: Veri depolamaya ZFS yaklaşımı

Daha önce ZFS’den bahsetmiştim ama kullandıkça bunun bir yazı dizisini hakettiğine karar verdim. Türkçe kaynak miktarı sıkıntılı malum. Bu yazı dizisinde akademik mevzulardan mümkün olduğunca kaçınmaya çalışıp, daha çok kullanıma yönelik bilgiler vereceğim. Hedefim, sadece bu yazı dizisini okuyup sistemlerinizde ZFS kullanmaya başlayabilmeniz.

Yazı dizisinde yeni yazılar yayınladıkça burada bunlara bağlantı vereceğim. Eğer ZFS yazı dizimi takip etmek istiyorsanız bu sayfaya arada bir uğrayın. İşim bittiğinde ise yine bu sayfadan gerekli her yere bağlantılarla ulaşabileceksiniz.

Bana ZFS’i anlat

Çok basitçe; kurumsal tip pahalı disklere ihtiyaç olmadan, teknoloji dükkanlarından alabileceğiniz son kullanıcı tipi disklerle çok büyük depolama alanlarını yüksek güvenlikle oluşturabildiğiniz ve bunu kapsamlı şekilde yönetebildiğiniz bir dosya sistemi-depolama yönetisi. Kolaylık olsun diye dosya sistemi diyeceğim.

Yukarıda gördüğünüz depolama sistemini sunucu odasına alabilir ve veri kaybı endişesi taşımazsınız. Depolama disk maliyeti TB başına $40 civarında.

Bazı özelliklerini sıralayarak başlayalım.

  • Veri güvenliği: Veri kaybına karşı RAID’le sağlayamayacağınız kadar güvenirlik
  • Kendi kendine iyileşme: Bozulmuş veriyi bulup doğru hale getirebilir
  • Çok büyük depolama alanı: 340.000.000.000.000.000.000.000.000 Terabayt gibi (üç-beş sıfır unuttuysam da lafını etmeyelim lütfen 😀 )
  • Tümleşik depolama alan yönetimi
    • Dataset ve ZVOL’ler ile alt bölüm yönetimi
    • Alt bölümler için ayrı ayrı snapshot, sıkıştırma, deduplication vb. özellikleri ayarlayabilme
    • Performans kaybı yaşamadan neredeyse sınırsız sayıda snapshot’ı anında alabilme
  • Tüm veriyi sıkıştırarak yazabilme
  • Blok seviyesi deduplication: Farklı dosyalara ait de olsa, birbiriyle aynı blokları sadece birer kere kaydederek disk alanı tasarrufu sağlama
  • Sadece yakın zamanda kullanılan veriyi değil, aynı zamanda sık kullanılan veriyi de önbellekleme
  • Önbellek olarak ayrı diskleri (örn. hızlı SSD’leri) kullanabilme
  • Basit kullanım

Veri güvenliği

Baştan söyleyeyim, “Efenim biz RAID binbeşyüz kullanıyoruz veri kaybı olmaz zaten” diyenlere bakmayın. 🙂 Ucuz disklerle depolama için herhangi bir RAID modunda ZFS veri güvenliğine ulaşamazsınız.

Burada kurumsal depolama açısından birinci anahtar söz grubu veri kaybına karşı güvenlik. Şurada anlatmıştım, tüm sabit diskler okumada düzeltemedikleri bir hata yaparlar. Bilgi işlem biriminizin sipariş ettiği diskin yüksek fiyat etiketinin nedeni bu hatayı yapana kadarki sürenin normal bir diskin 100 katı kadar olmasıdır. Bir başka deyişle kurumsal veri kaybı yaşamamak için eşlenik “normal” diske göre bu aralar 2-4 kattan başlayan fiyatları kabulleniyorsunuz.

ZFS buna, yazdığı tüm veriyi kontrol için bir kontrol kodunu da tutarak çözüm getiriyor. Okunan verinin bozuk olup olmadığını anlamak için tek yapması gereken, bu verinin kontrol kodunu tekrar hesaplayıp daha önce kaydettiğiyle karşılaştırmak. Pratikte bunu ikili (veya daha fazla diskli) aynalanmış (mirrored) disk gruplarıyla kullanıyoruz.

Bu iki disk birbirinin kopyası. RAID1 gibi düşünün. Her ikisinde de kayıtlı verinin birer kontrol bilgisi var. Belli aralıklarla bu diskler taranıyor, kontrol bilgisi tekrar hesaplanıp kayıtlı olanla karşılaştırılıyor. Eğer herhangi birinde hata saptanırsa basitçe diğer diskten doğru olan veri parçası kopyalanıp düzeltiliyor. ZFS’in “kendi kendini iyileştirme” (self-healing) dedikleri özelliği bu.

Ben bu kontrolü evdeki sunucumda ayda bir, ayın son Cuma gecesi yaptırıyorum. Kurumsal ortamlarda haftada bir, mesainin olmadığı bir gün/saat aralığında yapılması makul.

Bu “sessiz hata”lar dışında bir diğer veri kaybı olasılığı tüm diskin bozulmasıyla geliyor. Bu durumda geleneksel RAID sistemlerinde bozuk diski bulup değiştiriyorsunuz, RAID sistemi de bozuk diskin en başından başlayarak en sonuna kadar tamamını diğer diskten/disklerden okuyor ve yeni diske kaydederek eşzamanlıyor. Yani 3TB diskinizde sadece 1TB veri tutuyor olmanız önemli değil. 3TB alanın tamamı okunup kopyalanacak.

Bu yöntem 3TB ve üzerinde sığa sunan güncel disklerde elbette uzun sürüyor. Saniyede 150MB yazabilen 3TB bir disk için günler sürebilir. Disk eşzamanlaması boyunca depolama sisteminizde oluşacak bir başka hataya karşı korumanız azalıyor, üstelik bu süre boyunca diğer disklere de aşırı yük biniyor ve onların da hata yapma riski artıyor. Hele ki tek disk hatasına karşı dirençli bir RAID kurulumu yaptıysanız bu süreyi… Eh, neyse, makalede argo kullanmayayım. 🙂

ZFS ise, zaten disklerde hangi kısımlarda veri olduğunu bildiği için, sadece bu kısımları kopyalıyor. Çok şanssız değilseniz yukarıdaki sorunlar da önemini kaybediyor.

Depolama alanı yönetimi

ZFS’in sadece bir dosya sistemi değil, aynı zamanda bir depolama alanı yöneticisi olduğunu söylemiştim. ZFS’e geçtiğinizde bir “havuz” yaratıyorsunuz. Okuyacağınız örneklerde hep tank diye gördüğünüz şey bu havuzun ismi.

Bu havuz Linux için kök dizin altında kendi adıyla bir yere bağlanıyor. Artık bunun içini istediğiniz gibi doldurup bölümlendirebilirsiniz.

Yukarıdaki örnekte birkaç tane dataset oluşturdum. En çok kullanacağınız bölümlendirme şekli bu. Dataset’leri normal dizinler gibi kullanabilirsiniz, ama esasında ZFS’in özelliklerini her dataset için ayrı belirleyebiliyorsunuz. Örneğin bir dataset’te sadece sıkıştırmayı açabilir, bir diğerinde buna deduplication’ı ekleyebilirsiniz. Daha da iyisi, bir dataset’te günlük yedekler alırken bir diğerinde 15’er dakikada bir yedek alabilirsiniz.

Bir de ZVOL’ler var. Bunları herhangi bir disk bölümüymüş gibi kullanabilir, üstlerine istediğiniz dosya sistemini koyabilirsiniz. Yani burada ZFS’in dosya sistemi özelliğini değil, depolama yönetimi özelliklerini kullanıyorsunuz. Ayrıca bazı uygulamalar ZFS’te çalışmıyor -örneğin MS SQL Server kurmak istediğiniz zaman bir ZVOL oluşturup, burada MS SQL Server’ın üzerinde çalışabildiği bir dosya sistemi yaratmanız (yani formatlamanız) gerek.

RAID seviyeleri

ZFS’te havuz “VDEV”lerden oluşur. İsterseniz 4 tane diski 4 ayrı VDEV olarak ZFS’e gösterebilirsiniz. Bu durumda ZFS bu VDEV’lere veriyi kendiliğinden dağıtarak yazar -RAID0 tipi yapılanma standart gelir.

ZFS’in kendi kendini iyileştirmesi için ise RAID1 türü aynalamalı bir yapılandırma veya RAIDZ tercih ederiz. İlkinde, her bir VDEV’i birbirinin ayna görüntüsü ikişer diskten oluşturuyorsunuz. Böylece bir önceki paragrafta verdiğim 4 disk, herbiri ikişer diskten oluşan 2 tane VDEV olarak görülüyor. Toplam kapasite yarıya iniyor ama veri kaybı riskiniz neredeyse sıfırlanıyor.

Veri güvenliğini sağlayan ikinci yapılandırma, yani RAIDZ ise RAID5 benzeri bir yapı. Bu yapıda veri ve paritenin yazılması sağlanıyor. RAID5’e göre daha hızlı çalışıyor. Kaç tane diskin arıza yapmasına dirençli olduğuna bağlı olarak, ve en az 3 diskten oluşmak kaydıyla, RAIDZ1, RAIDZ2, RAIDZ3 gibi artan seviyeleri var. RAIDZ1’de tek disk arızalanırsa veriniz güvende, RAIDZ2’de aynı anda 2 disk arızalanabilir başınız ağrımaz gibi… RAIDZ’nin RAID5’e göre yazma deliği adı verilen hatadan etkilenmemesi ve tüm diski tekrar oluşturmasının daha kısa sürmesi gibi avantajları da bulunuyor. Aynalamalı yapılandırmaya göre ise daha fazla disk alanı sağlıyor; 3TB sığalı 4 tane diski, ikişerli olarak birbirinin kopyası olacak şekilde düzenlediğinizde toplam 6TB kullanabiliyorsunuz. Bu diskleri RAIDZ-1 yaparsanız 9TB alanınız olur. Matematiği kabaca RAID5’e benzer.

Önbellekleme

ZFS önbelleklemesi en son kullanılan dışında en sık kullanılana göre de yapılır demiştim. Önbellek dediğimiz genel olarak düşük alana sahip ama çok hızlı ortamlar. Haliyle bunlar doluyor. 🙂 Geleneksel önbellekler en son kullanılan verinin tekrar isteneceğini varsayarlar ve önbellek dolduğu zaman en eski kayıttan başlayarak çöpe atarlar.

ZFS’te ise önbellekleme algoritmaları yakın zamanda kullanılan kayıtlar dışında, sık kullanılanların da takibini yapar. Böylece sık kullanılan 5GB’lı veri, sırf ondan sonra birileri alakasız ve tek kullanımlık veri aktardı diye önbellekten çıkmaz.

Önbellek normalde RAM’de tutulur. ZFS için verilen büyük miktarda RAM önerileri de biraz buradan gelir. Okuma önbelleğine ARC denir; Adaptive Replacement Cache (veya bazı kaynaklarda Adjustable Replacement Cache).  RAM daha kısıtlı (okunuşu: Pahalı!) bir ortam olduğundan, ZFS’e bir SSD’yi gösterip al canım bunu önbellek olarak kullan diyebilirsiniz. SSD üzerindeki bu önbelleğe de Level 2 ARC (L2ARC) denir. RAM’de önbelleğe ayrılan alan bittiğinde veriniz bu L2ARC’ye taşmaya başlar. Yine ARC ile aynı şekilde en sık kullanılan veriyi önbellekleme yoluna gittiği için hızınız geleneksel önbelleklerden yüksek olur. L2ARC’yi sistemi durdurmadan istediğiniz gibi ekleyip çıkarabilirsiniz. Zaten sistemi durdurursanız önbelleğin tekrar oluşturulması gerekir.

Yukarıda  şu anda yazmakta olduğum sistemin ZFS havuz istatistiklerini görüyorsunuz. Önbellekleri LVM’den yapmamın sebebini ne siz sorun ne ben söyleyeyim ama siz böyle yapmayın. 🙂

Bunlar işin okuma tarafıydı, bir de yazma tarafı var. ZFS veri yazma önbelleği yazılacak veriyi mümkün olduğu kadar biriktirerek “transaction group”lar halinde, belirli periyodlarla diske yazar. Bu süre standart kurulumlarda genellikle 5 veya 10 saniyedir. Böylece hem yazma isteğinde bulunan uygulamaya “hocam ben yazdım sen devam et” diye haber vererek hızı artırır, hem de mekanik sabit disklerin zayıf karnı olan rastgele ve çok sayıda küçük yazma isteğinden kurtarır. Ayrıca yazma işlemini optimize etme şansı da elde eder.

Bahsetmek istediğim üçüncü önbellek mekanizması ise ZFS Intent Log; yani ZIL. RAM’de önbelleklenmiş şekilde yazılmayı bekleyen veriyi, elektrik kesintisi gibi bir durumda diske aktarmak için mümkün olduğu kadar çabuk kalıcı bir yerlere yazmak gerek. Burada ZIL ve onun SSD’ye koyduğumuz arkadaşı Separate Log (SLOG) devreye giriyor. ZIL her zaman vardır, hiçbir yer yoksa altyapıdaki disklere yazılır. Veri kaybı ihtimallerini azaltmak için ise hızlı bir SSD’yle bir SLOG alanı eklenebilir.

Her halükarda, ZFS’te güç kesilmesi gibi bir durumda en kötü ihtimalle az önce bahsettiğim 5-10 saniyelik veriyi kaybedersiniz. Onu da genelde kaybetmezsiniz.

Sıkıştırma ve Deduplication

Sıkıştırma tüm dataset’lerde ayrı ayrı açılabilir, kapatılabilir veya algoritması değiştirilebilir. Şu anda varsayılan algoritma lz4; sıkıştırma olup olmadığını anlayamayacağınız kadar hızlı ve gayet de yeterli sıkıştırma sağlıyor.

Yukarıda bu makaleyi yazmakta olduğum 2011 model Lenovo Thinkpad X220’de sıkıştırma oranlarımı görüyorsunuz. Bir yerlere bol miktarda sıkıştırılmış dosya yazmışım, o yüzden ev dizinimin sıkıştırma oranı biraz düşük. Ama toplam sıkıştırma oranım 1.7’lerde. Bu makinadaki kurulumu pek uzun süredir kullanmıyorum, ancak benim kullanımımda sıkıştırma oranlarım genelde 1.6 katlarda geldi.

Bir de deduplication var. Türkçesini henüz bulamadım. 🙂 Kabaca örneğim şu: Bilirsiniz, bazı filmlerin satışa sunulan DVD (veya artık Blu Ray) kopyalarında birden fazla son olur. Bu “alternatif son”lar dışında filmin tamamı aynıdır, ama sonları farklı olabilir.

İşte elinizde en sevdiğiniz filmin farklı sonlara sahip 3 kopyası olduğunu varsayın. Tanesi 10GB olsun. Bunun da 9 GB’lık kısmı üçünde de aynı, 1GB’lık kısmı farklı sonlar nedeniyle üçünde de farklı olsun. Normalde toplam alan 30GB. Deduplication özelliğiyle diskte kapladığı toplam alan 12GB.

Deduplication özellği iştah açmakla beraber düzgün çalışmak için çok miktarda RAM gerektirmesi nedeniyle pek tavsiye edilmiyor; ben de kendi testlerim dışında açmadım ve aktif kullanmıyorum. RAM’e vereceğiniz paraya disk almak daha avantajlı. Sadece belli senaryolarda işe yarayabilir. Gerketiği yerde de ZFS’te hazır.

Dosya sistemini yedekleme

ZFS basit birkaç komutla artan yedek alma ve bunu iki ZFS sistemi arasında göndermeyi sağlar. Bunun için ekstra araçlara ihtiyacınız yoktur. Yedeklenecek sistemin basitçe bir snapshot’ını alırsınız; yaptığınız şey aslında dosya sisteminin o anki fotoğrafını çekmek ve saklamaktır. ZFS’te bu ekstra alan kaplamaz ve hemen hemen anında gerçekleşir. Yani ekstra bir araca ihtiyaç duymadan her saat başı yedek alabilirsiniz.

zfs send komutu gayet “normal” bir veri akışı yaratır. Bu akışı isterseniz bir dosyaya yönlendirebilirsiniz. Ama ZFS’te esas fantastik olan, bu akışı (mümkünse farklı bir fiziksel lokasyondaki) başka bir ZFS’li makinaya yönlendirmektir.

Böylece temelde ZFS dışında hiçbir şeye ihtiyaç duymadan, tek satırlık bir komutla, doğrulaması yapılmış ve sağlamlığı garanti altına alınmış veriyi bir yerden diğerine yedeklersiniz. Yedekleme işlemini hızlandırmak veya şifrelemek isterseniz Linux’larda (daha doğrusu Unix-türü işletim sistemlerinde) sıkıştırma ve şifreleme araçları o tek satırlık komutunuzun arasına giriverir.

Benim gözümde sırf bu bile pahalı yedekleme yazılımlarının satın alınması gerekliliğini ortadan kaldıran bir çözüm.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir