Avamar: Bir çoğaltma çifti farklı kapasite kullanım düzeyleri gösteriyor. Bu durumun sebepleri nasıl araştırılır?

"Sunucu kullanımı" değerleri arasındaki farkların nedenleri ve olası gerekçeler:

Izgaralar arasındaki Mantıksal veya Fiziksel farklar:

• Kaynak ve hedef ızgaralarda farklı sayılarda veri düğümü bulunuyordur.
• Her bir ızgaranın veri düğümleri farklı disk yapılandırmalarına sahiptir.
• Şeritlerin her bir sistemdeki veri düğümleri arasında dağılımı yeterince dengelidir (%2'lik oran dahilinde).
• Depolama ve eşlik gereksinimleri Avamar sürümleri arasında farklılık gösterir. Kaynak ile hedef yazılım sürümleri farklıysa kullanımda farklılık gözlemlenebilir.
• Avamar Server Disk salt okunur düzeyi, iki ayrı ızgara arasında farklılık gösterebilir.   
• Izgaralardan biri RAIN eşliği için yapılandırılmış, diğeri ise yapılandırılmamış olabilir.

Çoğaltma yapılandırması:

• Hedef sisteme çoğaltılan yedeklemeler, kaynağa kıyasla farklı bir saklama politikasına sahip olabilir. Daha fazla bilgi için expiredelta bayrağını inceleyin. Alternatif olarak, çoğaltılmış yedeklemeler yalnızca belirli bir zaman aralığını da kapsayabilir. Örneğin, kaynaktaki son 4 haftalık döneme ait yedeklemeleri içerebilir.
• Çoğaltma, kaynak sistemden hedef sisteme yalnızca belirli istemcileri çoğaltacak şekilde yapılandırılabilir. "Dahil etme" veya "hariç tutma" ayarlarının kullanılıp kullanılmadığını kontrol edin.
• İstemciler ve ilişkili yedekleri kaynak sistemden silinmiş olabilir. Kaynak sistemdeki bir istemcinin veya yedeklerin silinmesi, aynı yedekleri hedef sistemden de kaldırmaz. Yedekler, ilgili saklama ayarlarına göre süreleri dolana kadar hedefte durmaya devam eder.
• Kaynak sistemdeki yedekler veya istemciler için saklama politikaları değiştirilebilir. Saklama politikalarındaki değişiklik yalnızca yeni yedekleri etkiler. Yeni yedekler hedefe çoğaltılır ve güncelleştirilmiş saklama politikasına uyar. Hedefte halihazırda mevcut olan yedekler, çoğaltıldıklarında kendilerine uygulanan saklama politikasını korur.

Önceki kapasite yönetimi etkinliği:

• Müşteriler bazen, Avamar çoğaltma çifti sistemlerinden birinin toplam kapasiteye yaklaştığını fark edebilir ve bu durumda kapasiteyi azaltmak üzere harekete geçebilir. Avamar çoğaltma çiftinin birbirinden bağımsız olarak yönetilen iki sistemden oluştuğu unutulmamalıdır. Bir sistemde eylemde bulunulduğunda aynı eylem diğer sistemde de gerçekleştirilmelidir. 
• Kaynak sistemde yedekler silinir veya saklama süreleri düşürülürse hedefte de aynı değişikliklerin yapılması gerekir. Kapasiteyi bu şekilde yönetmenin en iyi yolu modify-snapups komut dosyasını kullanmaktır. Bu komut dosyası, yedekleme değiştirme veya silmeye ilişkin aynı seçeneklerle her iki Avamar Server'da da çalıştırılabilir.  

Farklı şerit yapısı (örneğin, bir sistemde daha fazla eşlik şeridi bulunması):

• Herhangi iki Avamar sistemi bağımsız olduğundan farklı şerit yapılarına sahip olabilir. Çok düğümlü sistemler, verileri korumak için eşlik şeritleri kullanmaları nedeniyle bazı farklılıklar gösterebilir. Çok düğümlü iki sistem, kapasite geçmişlerine bağlı olarak aynı yedeklemeleri içerir ancak biri diğerinden daha fazla sayıda eşlik şeridine sahip olabilir.
• Normal şeritler gibi eşlik şeritleri de oluşturulduktan sonra daima sistemde kalır. Ancak normal şeritlerin aksine bunlar, Avamar Server'da her zaman sabit miktarda alan kullanır. Eşlik grubu güvenli şeritleri veri içermese bile bu durum geçerlidir. Çöp toplama işleminin bu davranış üzerinde hiçbir etkisi yoktur.
• Çoğaltma hedef sistemi, çoğaltma kaynağındaki önemli kapasite sorunlarından dolaylı olarak korunur. Ancak makinelerden biri kapasite açısından kötü yönetilirse iki makinede de bu sorun ortaya çıkabilir.
• İlgili makale: Avamar, tüm yedeklemeler silindikten ve çöpler toplandıktan sonra bile ~%30'a kadar kullanım gösteriyor

Yedekler hâlâ MC_DELETED klasöründe:

• Dikkat edilmesi gereken nadir senaryolardan biri, bir istemcinin kaynakta silindiği ancak yedeklerinin tutulduğu durumdur. Bu durum kaynağın, yedeklerin geçerlilik süresinin dolmasının beklendiği hedef sisteme kıyasla daha yüksek kullanıma sahip olmasına neden olabilir. dump_root_hashes.rb komut dosyasını backupcompare seçeneğiyle birlikte kullanmak bu senaryonun söz konusu olup olmadığını kontrol etmenize yardımcı olur.

Hedef sistemdeki çoğaltılmamış yedeklemelere ait veriler:

• Sistem *yalnızca tek yönde* çoğaltma yapıyorsa hedefte /REPLICATE ve MC_SYSTEM dışında istemci olmadığından emin olun.

Diğer davranışlar:

• Çoğaltma işleri güvenilir bir şekilde tamamlanamayabilir. Hedefe gönderilen veriler, kaynağın birkaç gün "gerisinde kalabilir."
• Her iki sistem de aynı miktarda tekilleştirilmiş veri içerir ancak sistemlerden her birindeki eşlik ek yükü miktarı farklıdır. Bu durum aşağıdaki senaryoda ortaya çıkar: 
  • Avamar kaynak sistemi neredeyse doludur. 
  • Kapasite düzeyini düşürmek için kaynak sistemden çok sayıda yedek silinir. 
  • Ardından, tekilleştirilmiş veriler kaynaktan hedefe çoğaltılır. 
  • Tekilleştirilen veri miktarı her iki sistemde de aynıdır.
  • Kaynak sistem başlangıçta hedeften daha fazla eşlik ek yükü depolar.
• Çoğaltma, fiziksel şeritleri kaynaktan hedef ızgaraya kopyalamaz. Bunun yerine hedef ızgaranın, veri şeritlerinin ve parçalarının nerede depolandığını belirlemesine izin verilir.
• Bazı durumlarda hedef Avamar sistemleri, verilerin orijinal olarak yedeklendiği kaynak ızgaradan daha verimli bir şekilde veri depolayabilir.

Çoğaltma ortamını anlama:

• Kaynak Avamar ızgarasının tam ana bilgisayar adını not edin.
• Hangi sistemlerin hangi verileri nereye çoğalttığını anlamak için etkilenen sistemlerin çoğaltma yapılandırmasını inceleyin. 
  • Ortam, bir Avamar Server'dan diğerine çoğaltmaktan daha karmaşıksa ortamın şemasını çizmek yardımcı olabilir.
• Kaynak, Data Domain (DD) ile entegre oluyorsa müşterinin endişesinin DD aygıtları arasında çoğaltılan yedeklemelerle ilgili olup olmadığını öğrenin.
• Hedef Avamar ızgarasının tam ana bilgisayar adını ve çoğaltılmış yedeklemeleri alan ilişkili DD aygıtlarını not edin.

Izgaranın genel sağlığını ve durumunu kontrol edin:

• Her iki ızgarada da proaktif denetim komut dosyasını çalıştırın, hc_results.txt dosyasının bir kopyasını alın ve sistemdeki genel durumu anlamak için bu dosyayı gözden geçirin. 

Kapasite farkı ne kadar ciddi?

• Müşteri, kaynak ile hedef arasında kapasite tüketim farkı olduğunu düşünmesine neden olan durumun ekran görüntüsünü sağlamalıdır.
• Kapasite farkı %5'ten azsa endişe edilecek bir durum olmadığı sonucuna varırız.
• Avamar Server kapasitesi ve (Data Domain entegre ise) meta veri kapasitesi düzeylerini anlamak için Avamar Administrator kullanıcı arayüzünü kontrol edin.
• Kullanıcı arayüzü kapasite ekranının nasıl çalıştığını öğrenin (şu makalede açıklanır: v7.2 ve sonraki sürümlerdeki Avamar UI panosunda Avamar Kullanımı yerine Meta Veri Kullanımı gösterilmektedir).
• Her iki sistemde de aşağıdaki komutu çalıştırın. Sunucu kullanım değeri, Avamar Server'ın (Data Domain'in değil) kapasite düzeylerinin toplam değerini verir:

admin@utility:~/>: mccli server show-prop | grep "utilization"

Server utilization               3.7%

Donanımın her iki ızgarada da aynı olup olmadığını kontrol edin:

• Sadece "benzer" sistemler için kapasite farklılıklarını karşılaştırmak mantıklıdır. 
• Proaktif kontrol çıktısını kullanarak sistemde bulunan düğüm türlerini not edin.
• Aşağıdaki komut, fiziksel düğümlerin toplam sayısını, boyutunu ve alan tüketimini gösterir:

admin@utility:~/>: mccli server show-prop | grep "Capacity\|capacity\|nodes"

Total capacity                   23.3 TB
Capacity used                    858.5 GB
Number of nodes                  3

• Bu çıktı, sistemdeki düğümlerin sayısını ve boyutunu belirlemeyi kolaylaştırır. Düğümlerin boyutu: (23,3 / 3 = ~7,8 TB). 
• Her bir düğümdeki sabit sürücü bölümlerinin sayısı ve boyutu bu bilgileri desteklemelidir.

admin@utility:~/>: mapall 'df -h' | grep data

(0.0) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.2 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   54G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   53G  1.8T   3% /data04
/dev/sde1       1.9T   52G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06
(0.1) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.3 'df -h'
/dev/sda3       1.8T   56G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   52G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   53G  1.8T   3% /data06
(0.2) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.4 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06

• Bu bilgilerle aşağıdakileri kontrol edin:

Yazılım sürümünü ve yapılandırmasını kontrol edin:

• status.dpn komut çıktısını kullanarak her bir sistemde çalışmakta olan Avamar sürümlerini karşılaştırın.
• Çok düğümlü sistemlerde, şu makale uyarınca her iki düğümün de RAIN eşliğiyle yapılandırıldığını doğrulayın: Avamar - Bir sunucunun RAIN Olup Olmadığını Belirleme
• İki sistemin kapasiteyle ilgili Avamar sunucu yapılandırma parametrelerini kontrol edin ve karşılaştırın. Örneğin:

admin@utility:~/>: avmaint config --ava | grep -i "capacity\|disk"

  disknocreate="90"
  disknocp="96"
  disknogc="85"
  disknoflush="94"
  diskwarning="50"
  diskreadonly="65"
  disknormaldelta="2"
  freespaceunbalancedisk0="20"
  diskfull="30"
  diskfulldelta="5"
  balancelocaldisks="false"

Şerit dengelemesini kontrol edin:

• status.dpn çıktısını kontrol edin ve her veri düğümündeki toplam şerit sayısını not edin. Şerit sayısı parantez içinde belirtilir (örneğin, onl:xxx). 
• Her bir veri düğümündeki toplam şerit sayısı arasında %2'den az fark olmalıdır.  

Atık toplamanın her iki sistemde de düzgün şekilde çalışıp çalışmadığını kontrol edin:

• Atık toplama tutarlı ve etkili bir şekilde çalışmıyorsa süresi dolan veriler kaldırılmaz. Sistem, beklenenden daha yüksek kapasite kullanımı bildirir. 
  • Bilgi için kısıtlı notlardaki Atık Toplama Çözüm Yolu makalesine bakın.  

Çoğaltmanın başarıyla tamamlandığından emin olun:

• Kaynaktan hedefe tüm çoğaltma görevlerinin başarıyla tamamlandığından emin olun. Tüm görevler başarıyla tamamlanmamışsa hâlâ kaynaktan hedefe çoğaltılması gereken veriler olabilir.  

Çoğaltma yapılandırmasını kontrol edin:

• Şu bayraklardan herhangi biri için çoğaltma yapılandırmasını (kullanıcı arayüzünde, CLI'da veya günlüklerde) kontrol edin:  

--before
--after
--include
--exclude

--expiredelta

--retention-types

--retention-types=none,daily,weekly,monthly,yearly

Her iki sistemin veri alma ve veri kaldırma hızlarını kontrol edin:

• Her iki sistemde proactive_check.pl --capacity komutunu çalıştırın ve hem kaynak hem de hedef sistemlerin alma hızlarını karşılaştırın.
• Hedef tamamen hedef bir sistemse ve TÜM yedeklemeleri kaynaktan alıyorsa alma hızı, kaynağın alma hızını yakından takip etmelidir.
• Avamar NEW veya DDR NEW sütunları, bu sistemlere ne kadar yeni veri eklendiğini gösterir.
• Ayrıca, her iki sistemdeki atık toplama davranışını anlamak için "removed", "mins" ve "pass" sütunlarına da çok dikkat edin.
• Bu bilgi, her iki sistemde de neler olup bittiğine dair net bir görüş sağlar.
• Çıktıyı yorumlama hakkında daha fazla bilgi için bkz. Avamar: capacity.sh komut dosyasıyla kapasiteyi yönetme  

Her sistemde mevcut olan yedeklerin listesinin dökümünü alın:

• dump_root_hashes.rb komut dosyası, Avamar kaynağında depolanan yedekler ile hedef sistemde depolanan yedekleri karşılaştırmaya yardımcı olan bir yardımcı programdır. Yedekler Data Domain depolamasında barındırılıyor olsa bile bu komut dosyasından yararlanılabilir.   
• Avamar: Avamar: İstemcilerin ve Yedeklerin Listesini Oluşturmak için dump_root_hashes.rb Komut Dosyasını Kullanma makalesinden iki Avamar sisteminin içeriğinin karşılaştırılması da dahil olmak üzere yardımcı programı indirme ve kullanım durumları hakkında bilgi edinebilirsiniz.
  • Aracı çalıştırın. Tüm istemcilerdeki yedeklemelerin sayısında tutarsızlık olup olmadığını kontrol edin. "+/-2" farklarına dikkat edin.  
• Nedenler bölümünde açıklandığı gibi, asimetrik kapasite yönetimi iki sistem arasında farklılıklara neden olur. Böyle bir senaryoyla karşı karşıya olup olmadığınızı belirlemek için çıktıyı inceleyin.
• Ayrıca şunları da yapın:
  • Hedef sistemde, çoğaltılmamış yedeklere ait veriler olup olmadığını kontrol edin.
  • Kaynakta, hedefe çoğaltılmamış veriler olup olmadığını kontrol edin.  

Farklı şerit yapılarının söz konusu olup olmadığını kontrol edin (örneğin, bir sistemde daha fazla eşlik şeridi bulunması):

• Herhangi iki Avamar sistemi, bağımsız olduğundan, farklı şerit yapılarına sahip olabilir. Çok düğümlü sistemler, verileri korumak için eşlik şeritleri kullanmaları nedeniyle bazı farklılıklar gösterebilir. Çok düğümlü iki sistem, kapasite geçmişlerine bağlı olarak aynı yedeklemeleri içerir ancak biri diğerinden daha fazla sayıda eşlik şeridine sahip olabilir.  
• Normal şeritler gibi eşlik şeritleri de oluşturulduktan sonra sistemde kalır. Ancak normal şeritlerin aksine bunlar, eşlik grubu güvenli şeritleri veri içermese bile Avamar'da her zaman sabit miktarda alan kullanır. Çöp toplama işleminin bu davranış üzerinde hiçbir etkisi yoktur.
• Çoğaltma hedef sistemi, çoğaltma kaynağındaki önemli kapasite sorunlarından dolaylı olarak korunur. Ancak makinelerden biri kapasite açısından kötü yönetilirse iki makinede de bu sorun ortaya çıkabilir.
• İlgili makale:  Avamar, tüm yedeklemeler silindikten ve çöpler toplandıktan sonra bile ~%30'a kadar kullanım gösteriyor  

Yedekler hâlâ MC_DELETED klasöründe:

• Dikkat edilmesi gereken nadir senaryolardan biri, bir istemcinin kaynakta silinmiş olmasına rağmen yedeklerinin tutulduğu durumdur. Bu durum kaynağın, yedeklerin geçerlilik süresinin dolmasının beklendiği hedef sisteme kıyasla daha yüksek kullanıma sahip olmasına neden olur. dump_root_hashes.rb komut dosyasını backupcompare seçeneğiyle birlikte kullanmak bu senaryonun söz konusu olup olmadığını kontrol etmenize yardımcı olacaktır.