Avamar: Yedekleme performansı davranışı ve teorisi

Bu makalenin amacı, okuyucunun yedekleme performansı davranışını anlamasına yardımcı olmaya odaklanarak Avamar yedeklemesi sırasında neler olduğunu açıklamaktır.

Bu makale, aşağıdaki makalelere eşlik eder:

• Avamar: Yavaş yedekleme performansı sorununu giderme
• Avamar: Hızlı bir şekilde tamamlamak için yedeklemeler ayarlanıyor

Avamar yedeklemesi sırasında ne olur?

Avtar yedekleme işlemi:

1) Dosya ve hash önbellek dosyalarını belleğe yükler

2017-06-09 23:00:25 avtar Info <5586>: Loading cache files from C:\Program Files\avs\var
2017-06-09 23:00:25 avtar Info <8650>: Opening filename cache file 'C:\Program Files\avs\var\f_cache2.dat'
2017-06-09 23:00:25 avtar Info <5573>: - Loaded filename cache file (6,532,792 bytes)
2017-06-09 23:00:26 avtar Info <8650>: Opening hash cache file 'C:\Program Files\avs\var\p_cache.dat'
2017-06-09 23:00:28 avtar Info <5573>: - Loaded hash cache file (402,653,728 bytes)
2017-06-09 23:01:01 avtar Info <6426>: Done loading cache files

2) VSS anlık görüntüleri oluşturur (Windows'ta):

2017-06-09 23:04:32 avtar Info <19008>: Obtaining available VSS providers
2017-06-09 23:04:32 avtar Info <8776>: Freezing volumes now...
2017-06-09 23:04:32 avtar Info <8780>: Creating the shadow copy set (DoSnapshotSet) ... 
2017-06-09 23:14:33 avtar Info <8781>: Shadow copy set successfully created.
2017-06-09 23:14:34 avtar Info <6074>: VSS snapshot set creation successful

3) Veri kümesi
tarafından tanımlanan tüm dosyaları gezdirir Kaynak veri kümesindeki tüm dosyalar için avtar tam yolu alır ve dosyayı benzersiz bir şekilde tanımlamak için bir karma hesaplamak üzere bunu istatistik benzeri meta verilerle birleştirir.

Daha fazla ayrıntı için bkz. Avamar: Dosya tarama aşamasında avtar bir dosyayı okursa ne olur?

4) Hesaplanan karmaları yerel istemci önbelleklerindekilerle

karşılaştırın Avtar, dosya önbelleğinde dosyanın karmasını arar. Yeni olup olmadığını veya önceki yedeklemeden bu yana değiştirilip değiştirilmediğini kontrol eder.

Dosya önbelleği araması başarılı olursa dosya mevcuttur ve değişmez.

Arama başarısız olursa dosya yenidir veya değişmiştir. Okunmalı ve işlenmelidir.

Daha fazla ayrıntı için Avamar istemcisi - avtar bir dosyanın değiştirilmiş olduğunu düşünmeden önce nelerin değişmesi gerekir? bölümüne bakın.

5) Yeni ve değiştirilmiş dosyaları

işleyin Herhangi bir yeni veya değiştirilmiş dosya için avtar şunları yapmalıdır:

• Dosyanın tamamını okuma
• Değişken boyutlu parçalara ayırın
• Her bir öbeği sıkıştır
• Her öbek için bir karma hesaplayın

6) Avamar sunucusunda eksik karmalar olup olmadığını kontrol edin.

Avtar , zaten var olup olmadıklarını kontrol etmek için ağ üzerindeki eksik karmalara ait verileri Avamar sunucusuna gönderir. Bunlar 'mevcut' istekler olarak bilinir.

7) Veriler Avamar Server'a (ve uygunsa Data Domain'e) yazılır. 

Daha ayrıntılı iş akışı için ekteki Avtarprocess.pdf bakın.


Performans açısından Avamar yedeklemesine genel bakış:

Yukarıdaki aşamaları alarak, bunları yedekleme performansı üzerinde en büyük etkiye sahip olan 'aşamalara' ayırdık:

Aşama 0. VSS anlık görüntüleri oluşturun.

Birim Gölge Kopyası Hizmeti (VSS), kaynak veri kümesinde belirtilen birimlerin anlık görüntülerini oluşturur. Yedekleme çalışırken uygulamalar disk bölümüne yazmaya devam edebilir.
Avamar, yazılabilir disk bölümü yerine disk bölümünün salt okunur "dondurulmuş" anlık görüntüsünü yedekler. Bu, yedeklenecek tutarlı bir veri kümesine sahip olmasını sağlar.

VSS anlık görüntülerinin tamamlanması saniyeler sürer. Bir istemci VSS sorunları yaşıyorsa bu gecikme, yedeklemenin devam etmesini engeller.

Aşama 1. Dosya tarama aşaması. Avtar işlemi, hedef veri kümesindeki

tüm dosyaların istatistiklerini alırMilyonlarca dosyası olan istemciler için bu aşama en çok zaman alan aşama olabilir.
Veritabanı verileri az sayıda büyük dosya içerir, bu nedenle dosya tarama aşaması çok az zaman alır. Veritabanı istemcileri genellikle zamanlarını aşama #2 sırasında tüketir.

RAID 5 yapılandırmasında dönen disklere sahip bir istemci için, saatte ~1 milyon dosyalık dosya tarama performansı tipiktir. Bu, saatte 300.000 ila 3 milyon arasında değişir. Bu , istemci ortamına ve yedeklenen verilerin özelliklerine bağlıdır.

v7.3 sürümünden Data Domain'e yedekleme yapan Linux istemcileri, Linux Fast Incremental (LFI) işlevinden yararlanabilir. Bu, yedekleme her çalıştırıldığında tüm veri kümesinin taranmasını önler.

Kritik kaynaklar: Yedekleme verilerinin depolandığı diskin rastgele arama performansı.

Aşama 2. Avtar değiştirilen dosyaları okur ve ardından verileri parçalar, sıkıştırır ve karma hale getirir.

Bu aşamada çok fazla hesaplama gerçekleşir. Değiştirilen veya yeni her dosya için, avtar dosyayı küçük parçalara böler. Her bir parçayı sıkıştırır ve parçayı tanımlamak için bir hash'i 'parmak izi' olarak hesaplar.

Veritabanı yedeklerindeki dosyalar genellikle büyüktür ve günlük olarak değişme eğilimindedir. Avtar zamanının çoğunu bu aşamada geçiriyor. Veritabanının artımlı yedekleme işlevinden, işlem günlüklerinden vb. yararlanarak verimli bir şekilde işlenmesini sağlamak için resmi Avamar veritabanı eklentilerini kullanmak en iyisidir.

Tipik dosya işleme performansı saatte yaklaşık 100 GB'tır, ancak saatte 300 GB'a kadar değişebilir. Bu, ortama bağlıdır.

Kritik kaynaklar: İstemci diski ve CPU

Avamar sunucusuna veri gönderirken performans sorunu yaşanmayan LAN yedeklemeleri için aşama #1 ve #2 en çok zaman alır.

Aşağıdaki grafikte, grafiğin çubuklarındaki alan miktarının yedeklemenin ne kadar sürdüğüne karşılık geldiğini göz önünde bulundurun. Değiştirilen dosyalar, özellikle bu dosyalar büyükse, gereken süreyi önemli ölçüde artırabilir.

Dosya sistemi veri kümeleri için dosyaların ~%0-3'ünün günlük olarak değişmesini bekleyebilirsiniz.

Avtar , biri dosya özniteliklerini, diğeri güvenlik özniteliklerini kontrol etmek için olmak üzere iki G/Ç işlemi gerçekleştirerek değişen her dosyayı 'stat()' yapmalıdır.

Dosya sistemi yedeklemeleri için ~1 milyon dosya/saat kıyaslama tarama hızı performansını elde etmek için avtar saatte yaklaşık iki milyon arama işlemi veya saniyede 600 arama işlemi gerektirir.

Örneğin: Bir yedeklemenin değişim oranı %3'se 100 dosyadan 97'sinin değişip değişmediğini belirlemek için iki disk arama işlemi gerekir. Değişen kalan üçü taranmalı, parçalara ayrılmalı, sıkıştırılmalı ve karma hale getirilmelidir.

Bu işlem, yalnızca dosya tarama aşamasını dikkate alır ve değiştirilen dosyaların işlenmesi için gereken G/Ç kaynaklarını hesaba katmaz.
Değiştirilen dosyalarda ne kadar çok veri varsa, yedeklemeyi tamamlamak için o kadar fazla çalışma gerekir.

Aşama 3. Avamar sunucusunda

karmaların varlığını kontrol etmeAşama #1 ve #2, yedeklemenin öğelerine işaret eden karmalar üretir. Bu öğeler benzersiz dosya parçaları, dosya sistemleri veya tüm yedeklemeler olabilir.

Karmalar istemci önbellek dosyalarına yazılır ve yeni verilerin eklenmesi gerekip gerekmediğini kontrol etmek için Avamar sunucusunda bulunan karmalarla karşılaştırılır. Bu durum, bir Avamar sunucusunun veya Data Domain'in hedef depolama alanı olup olmadığı fark etmeksizin geçerlidir.

Avamar istemcisi ve sunucusu arasındaki karma karşılaştırmaları genellikle hızlıdır. Avamar sunucusu aşağıdaki durumlarda yedeklemeyi darboğaz haline getirmemelidir:

• Sağlıklı
• Normal yük seviyeleri altında
• İstemci ile aynı LAN segmentinde bulunur

Karmalar yalnızca 20 bayt boyutunda olduğundan, bu aşama ağ bant genişliğinden ziyade ağ gecikmesinden daha fazla etkilenir. Karma Avamar sunucusuna ulaştığında, veri düğümlerinin disk alt sisteminin genel yükü ve rastgele arama performansı, karmanın ne kadar hızlı alınacağını belirler ve istemci tarafından gönderilenle karşılaştırılır.

Kritik kaynaklar: Ağ yanıt süresi ve Avamar veri düğümü rastgele arama performansı.

Veri düğümlerinin sayısı ve boyutuyla fiziksel bir Avamar ölçeğinin rastgele arama performansı. AVE sistemleri, tek düğümlü bir sistemle karşılaştırıldığında daha az iyi performans gösterir.

Aşama 4. Yeni öbeği ağ üzerinden Avamar sunucusuna veya Data Domain'e

göndermeBir istemci sunucuya yeni ve benzersiz bir öbek (boyutu 64 KB'ye kadar) gönderdiğinde, performans öncelikle ağ bant genişliğine bağlıdır. Bu, esas olarak, her gün büyük miktarda değişen veri üreten WAN tabanlı istemcileri etkiler. Sıkışık ağ bağlantıları üzerinden çalışanları da etkileyebilir. 

Aşağıda, bir istemcinin bir Avamar sistemine ve bir Avamar - Data Domain entegre sistemine veri gönderdiği veri akışını gösteren şemalar verilmiştir.






Kritik kaynaklar: İstemci ve sunucu

arasındaki ağ bant genişliğiAşama 5. Avamar sunucusuna veya Data Domain'e

yazılan verilerYedekleme verileri Avamar sunucusuna veya Data Domain sistemine yazılmalıdır.

Kritik kaynaklar: Avamar sunucusu disk yazma performansı ve genel yükleme.