Data Domain, Sıkıştırma SSS

AŞAĞIDAKİLER İÇİN GEÇERLİDİR

• Tüm DDR'ler
• Tüm Sürümler

Sıkıştırma: Sık Sorulan Sorular:

İdeal olarak, bu doğru olacaktır. Pratikte, aşağıdaki nedenlerden dolayı tam yedekleme artımlı yedeklemeden biraz daha fazla alan kullanır. Bu nedenler, verilerde herhangi bir değişiklik yapılmadıktan sonra tam yedeklemenin neden hâlâ pozitif miktarda alan tüketeceğini de açıklar.

• Meta veriler, yedeklemenin mantıksal boyutunun yaklaşık %0,5'ini kaplar. Tam boyutun mantıksal boyutunun 100 GB ve artımlı boyutun 2 GB olduğunu varsayalım. Artımlı sıkıştırmanın 1 GB'ye sıkıştırıldığını varsayalım. O zaman tam yedekleme en az 1,5 GB kaplar.
• DD sıkıştırma motoru, performans için bazı yinelenen veri segmentlerini yeniden yazar. Değişikliklerin veri yerelliği ne kadar zayıfsa yinelenenler o kadar fazla yazılır. Yinelenenler daha sonra "filesys cleaning" tarafından geri alınır. Mantıksal boyutun yaklaşık %2'sinin yineleme olarak yeniden yazıldığını gördüm. Bu düzeyde yineleme olduğunu varsayarsak tam yedekleme 1 GB (sıkıştırılmış) + 0,5 GB (meta veri) + 2 GB (yinelenenler) = 3,5 GB kaplayabilir. Yazılan yinelenenlerin miktarı bir sistem parametresi aracılığıyla kontrol edilebilir ancak, genellikle bu parametreyi sahada ayarlamıyoruz.
• Veri segmentasyonu, NFS istemcisinin verileri gönderme sırasına bağlı olarak yedeklemeden yedeklemeye farklılık gösterebilir. Bu sıra belirleyici değildir. Genel olarak, segmentasyon algoritması kaymaları ve yeniden sıralamayı tolere eder. Bununla birlikte, kaymaya ve yeniden sıralamaya eğilimli bazı "zorunlu" segmentler de oluşturur. Genellikle segmentlerin yaklaşık %0,2'si zorlanır, bu nedenle çok daha fazla alan kullanılması beklenebilir.

"filesys show space", depolanan verilerin mantıksal boyutuna ve komutun çalıştırıldığı sırada kullanılan disk alanına bağlı olarak sıkıştırma oranını sağlar.

"filesys show compression", her dosyanın oluşturulduğu sırada nasıl sıkıştırıldığına bağlı olarak sıkıştırma oranını sağlar.

"filesys show compression", çoğunlukla destek ve hata ayıklama için kullanılır. Dosya silme işlemlerinde "filesys show compression", sıkıştırma oranını olduğundan yüksek tahmin eder.

Örneğin, ilk tam yedeklemenin 2 katı sıkıştırma aldığı varsayılır. Herhangi bir veri değişikliği olmadan yapılan sonraki bir tam yedekleme, 200 katı sıkıştırma alır. İlk tam yedekleme silinir. "filesys show space", 2 katı sıkıştırma oranı gösterir. Şu anda mevcut olan tek dosya 200 katı sıkıştırmaya sahip olduğundan "filesys show compression" artık 200 katı sıkıştırma oranı gösterir.

Yukarıda bahsedilen örnekte, ikinci yedeklemeden sonra "filesys show space" yaklaşık 4 katı kümülatif oranı gösterir. Silme işleminden daha fazla yedekleme yapmaya devam ederseniz kümülatif oran asimptotik olarak 200 katına doğru iyileşir.

Başka küçük farklılıklar da bulunmaktadır:

•  "filesys show compression", kapsayıcı düzeyinde fireyi hesaba katmaz, bu nedenle sıkıştırma oranını olduğundan yüksek tahmin eder
•  "filesys show compression", genel sıkıştırma ile yinelenen elemeyi hesaba katmaz, bu nedenle sıkıştırma oranını olduğundan düşük tahmin eder
•  "filesys show compression", dosya başına veya dizin başına bilgi sağlayabilirken, "filesys show space" tüm sistemle sınırlıdır
•  "filesys show compression", genel ve yerel sıkıştırma arasındaki dökümü sağlarken, "filesys show space" bunu sağlamaz

REFERANSLAR

• "filesys show space" ve "vtl tape show summary" için sıkıştırma oranları neden farklı?

"vtl tape show summary" içinde gösterilen sıkıştırma oranının "filesys show compression /backup/vtc" ile eşleşmesi amaçlanmıştır.

Daha genel olarak, bu VTL komutuna, bant kartuşlarının bir alt kümesini seçmek için isteğe bağlı bir filtre verilebilir ve sıkıştırmanın, kartuşların bu alt kümesindeki "filesys show compression" ile eşleşmesi beklenir.

Ancak, VTL UI kodundaki bir hata nedeniyle "vtl tape show summary" içinde gösterilen sıkıştırma hatalıdır. Bu, 4.5.0.0 sürümünde çözülmüş, bilinen bir sorundur.
 

• "filesys show compression last 24 hours" neden VTL beklentisiyle eşleşmiyor?

VTL için "filesys show compression last 24 hours" gibi komutların çıktısı genellikle "system show performance" gibi diğer kaynaklara dayalı olarak beklentiyi karşılamaz.

Sorun, "filesys show compression" (fsc) içindeki bir özellik nedeniyle ortaya çıkıyor. Genel olarak, "filesys show compression" seçilen dosyalardaki kümülatif istatistikleri gösterir. "last 24 hours" niteleyicisi, son 24 saat içinde güncellenen dosyaları seçer. Dosya oluşturulduğundan veya en son sıfır boyutuna kesildiğinden istatistikler hâlâ kümülatiftir. Bu nedenle, son 24 saat içinde bir dosya eklenmişse "filesys show compression last 24 hours", son 24 saatten önceki kümülatif istatistiklerini gösterir.

VTL olmayan ortamlarda yedekleme dosyaları yalnızca bir kez yazılır, bu nedenle güncelleştirilen dosyalar ve oluşturulan dosyalar arasında çok fazla tutarsızlık olmaz. VTL ile, yedekler mevcut bant dosyalarına eklenebilir. Örneğin, 50 GB'ye kadar doldurulmuş 100 GB kapasiteli bir bant düşünün. Bu banda son 24 saat içinde 10 GB veri eklenirse "filesys show compression last 24 hours", dosyanın 60 GB olarak yazılmış "Original bytes" değerini gösterir.
 

• Kümülatif sıkıştırma oranı nasıl hesaplanır?

Bireysel sıkıştırma oranları doğrusal olarak toplanmaz.

İlk tam yedeklemedeki sıkıştırmanın 2 kat, ikinci tam yedeklemedeki sıkıştırmanın ise 20 kat olduğunu varsayalım. Kümülatif sıkıştırma (2+20)/2 veya 11 katı değil, 2/(1/2+1/20) veya 3,64 katıdır.

Genel olarak, daha düşük sıkıştırma oranları, kümülatif sıkıştırma oranı üzerinde yüksek olanlardan daha fazla etkiye sahiptir.

ith yedeklemenin mantıksal boyutunun si ve sıkıştırma oranının ci olduğunu varsayalım. Ardından, k yedeklemeleri için kümülatif sıkıştırma oranı aşağıdaki gibi hesaplanabilir:

C = (toplam mantıksal boyut)/(kullanılan toplam alan)
toplam mantıksal boyut = s1 + s2 + .. + sk
kullanılan toplam alan = s1/c1 + s2/c2 + ... + sk/ck

Mantıksal boyutlar genellikle aşağı yukarı aynıdır. Bu durumda, yukarıdaki hesaplama aşağıdaki şekilde basitleştirilir:

Örneğin, ilk tam yedekleme 3 kat sıkıştırma alırken, sonraki her tam yedekleme 30 kat sıkıştırma alırsa ve saklama süresi 30 günse kullanıcı 30/(1/3+29/30) veya 23 kat kümülatif sıkıştırma görür.
 

• Data Domain Sıkıştırma nasıl çalışır?

Bu soru, "Data Domain Sıkıştırma İşlemini Anlama" adlı ayrı bir KB makalesinde ayrıntılı olarak yanıtlanmıştır Data Domain: Data Domain Sıkıştırma İşlemini Anlama
 

• Data Domain çoğullamayı destekliyor mu? ​​​​​​​

Yedekleme uygulamasından gelen çoğullanmış veriler, çok zayıf global tekilleştirmeye neden olur. Daha fazla bilgi için Yedekleme Yazılımında Çoğullama Desteklenmiyor adlı KB makalesine bakın: Data Domain: Yedekleme Yazılımında Çoğullama. 
 

• 1-1 dizin çoğaltmada, replika neden daha iyi genel sıkıştırma gösteriyor?​​​​​​​

Bunun nedeni genellikle sistemde yazılan yinelenen segmentlerin düzeyindeki farklılıklardır:

• Kaynakta depolanan veriler, kaynakta depolanan önceki verilerle karşılaştırıldığında bir kez tekilleştirilmiştir.
• Kablo üzerinden gönderilen veriler, replikada depolanan verilerle karşılaştırıldığında bir kez tekilleştirilmiştir.
• Replikada depolanan veriler; kablo üzerinden veri gönderildiğinde bir kez ve alınan veriler replikaya yazıldığında bir kez daha olmak üzere iki kez tekilleştirilmiştir.

Tekilleştirme işlemi bazı yinelemeler bıraktığından, birden çok kez tekilleştirilen veriler daha az yinelemeye sahiptir. Kaynakta depolanan ve kablo üzerinden gönderilen veriler bir kez tekilleştirilir, bu nedenle kaynakta depolanan verilerin ve replikanın benzer olduğu varsayıldığında bunlar kabaca aynıdır. Replikada depolanan veriler iki kez tekilleştirilir, bu nedenle daha iyi sıkıştırılır.

Dosya sistemi temizleme işlemi, yinelenenlerin kopyaların çoğunu kaldırır. Bu nedenle, kaynakta ve replikada temizleme işlemi çalıştırıldıktan sonra, orada depolanan veri miktarı yaklaşık olarak aynı olmalıdır.

• lz, gzfast ve gz local sıkıştırma ayarları kullanılırken sıkıştırmadaki değişiklik nedir?

filesys option set compression {none | lz | gzfast | gz}
 

Uyarı: Yerel sıkıştırma türünü değiştirmeden önce dosya sistemi kapatılmalıdır. Ardından, sıkıştırma seçeneği ayarlandıktan hemen sonra yeniden başlatılabilir.

Genel olarak, sıkıştırma sırası aşağıdaki gibidir:

Kabaca fark şudur:

• lz - gzfast ~%15 daha iyi sıkıştırma sağlar ve 2 kat CPU tüketir
• lz - gz ~%30 daha iyi sıkıştırma sağlar ve 5 kat CPU tüketir
• gzfast - gz ~%10-15 daha iyi sıkıştırma sağlar

Yerel sıkıştırmayı değiştirmenin, değişiklik yapıldıktan sonra ilk olarak DataDomain Restorer'a yazılan yeni verileri etkilediğini unutmayın. Eski veriler bir sonraki temizleme döngüsüne kadar önceki sıkıştırma biçimini korur. Bir sonraki temizleme döngüsü, tüm eski verileri yeni sıkıştırma biçimine kopyalar. Bu, temizleme işleminin çok daha uzun sürmesine ve daha fazla CPU kullanmasına neden olur.

Müşteri sisteminin CPU'su zaten düşükse özellikle de müşteri aynı anda yedekleme ve çoğaltma yapıyorsa bu durum müşterinin yedekleme ve/veya çoğaltma işlemini yavaşlatabilir. Müşteri, bu dönüşümü gerçekleştirmek için açıkça bir zaman planlamak isteyebilir.

Bilgi Referansları:

• Geçiş Sorunlarını Çözme
• Data Domain: Data Domain Sıkıştırma İşlemini Anlama