NetWorker: Veri Etki Alanları arasındaki Kapasite Modu vProxy klon iş performansı sorunları

• vProxy klonlama hızı, GB/sn'den daha geleneksel ve gerçekçi hızlara düştü.
• Ağ bant genişliği, tıkanıklık nedeni olarak elenmiş ve klonlama sırasında eşiğin çok altında kaldı.
• Mesajlar ddf'lerde bulunur.etkilenen VM'nin diskleri için bir veya daha fazla *-flat.vmdk dosyasını içeren bilgi günlükleri:
  • synthesized_vbytes 0 ile biten ve recipe_repl YANLIŞ
  • srepl_filecopy_recipe_validate_bf: srepl_get_replica_attr dosya için yeniden oluşturma ve dosya kolunun eski hatasıyla biten durum.
• Etkilenen VM'nin diskleri için bir veya daha fazla *-flat.vmdk dosyasını içeren klon eylem günlüklerinde (klon hata ayıklama düzeyi 3 veya daha yüksek olduğunda) bulunan mesajlar:
  • Dosya için yapay replikasyon kullanılamaz... path.../vm-vmnumber-disk-key-disknumber-flat.vmdk (yol.../vm-vmnumber-disk-anahtar-disknumber-flat.vmdk)

vProxy, VMware'in değiştirilen blok izleme API'sini kullanmak için sanal sentetikler kullanır ve hem yedekleme hem de klonlama işlemleri için devasa kazançlar sağlar. Bu, ilgili her Bir Data Domain'de VM dosya kümesi her iki ilişkilendirmesinin etkin bir şekilde bakımı gerektirir. Sanal klonlar kullanılarak klonlama işlemi sırasında sorunlar ortaya çıkarsa NetWorker ve Data Domain bunun yerine varsayılan çoğaltma iş akışına geri yük biner. Bu işlem, yalnızca VMware API tarafından sağlanan değiştirilen bloklar yerine yalnızca değiştirilen bloklar yerine sanal disk dosyalarının tamamının işlemesini gerektirir. Tekilleştirme nedeniyle çok az veri gönderilse bile klonlama işinin süresi birden çok kez artebilir.
 
Sanal suni takipte hataya neden olabilecek nedenler şunlardır:

• İşler arasında kaynak veya hedef Data Domain aygıtları için NetWorker tarafından çözülen farklı IP adresleri: Bunlar, sanal sentetiklerin dahili izlemesi için tutarlı kalmalıdır
• vProxy yedeklemeleri veya klonları için kaynak veya hedef Data Domain'i değiştirme
• vProxy yedeklemeleri veya klonları için birden çok kaynak veya hedef birim, zincirde birden fazla tasarruf setini eşzamanlı olarak klonlamaya neden olabilir
• Belirli bir VM için klonlama gerektiren birden fazla vProxy saveset, zincirde kaydetme kümelerini klonlamada sorun gidermeye neden olabilir
• Herhangi bir değişiklik olmadan uzun süre boyunca geçen VM diskleri (özellikle, saklamanın 30 gün olduğu durumlarda değişiklik olmadan 35 gün gibi kaydetme kümesi saklama sürelerini aşan dönemler)
• NetWorker 19.6 ve üstü kullanılırsa, Kronolojik Sipariş Eylemi özelliğinin kullanımma durumu

Çok sayıda olası neden olduğundan Data Domain ve NetWorker yapılandırmalarını gözden geçirin ve şunlardan emin olun:

• ifgroups are setup correctly for both source (backup) and destination (clone target) Data Domains (kaynak (yedekleme) ve destination (clone target) Data Domains (kaynak (yedekleme) ve hedef (klon hedef) Veri Etki Alanları için gruplar doğru şekilde yapılandırıldığında
• NetWorker sunucusu, depolama düğümleri ve Veri Etki Alanlarının hepsinde, Data Domain başına uygun ifgroup IP'lerini kullanan ana bilgisayar dosya girişleri ve istemciler için güvenilir DNS bulunur (netWorker istemci ana bilgisayar dosyaları kullanılarak ihtiyaç vardır).
• Her bir yedekleme ve klon havuzu için tek Data Domain.

NetWorker 19.5 veya daha yeni bir sürüm kullanırken:

• Klon işlerinin seri olarak ve yedekleme sırasına göre gerçekleştirilmelerini sağlamak; Belirli bir VM için birden fazla klon aynı iş listesinde olduğunda (klon Eylemi veya nsrclone saveset dosya listesi) bu işlemin kontrol edilemey olduğunu unutmayın.
• Kaynak için birden fazla birim kullanılabilir olduğunda eş zamanlı klonlamayı önlemek için havuz başına tek bir yedekleme ve klon birimi olduğundan emin olun.

NetWorker 19.6 sürümünden itibaren, vProxy saveset klon eylemleri için her zaman Kronolojik Sıra özelliğini etkinleştirmeniz gerekir. Bu özellik kullanıcı arayüzünde gizlenmiş olabilir:

• nsrclone komutu kullanıyorsanız belirli bir istemci zincirinde birden fazla kaydetme kümesi içeren bir saveset listesi kullanırken bu yeni özelliği uygulamak için -O anahtarını kullanın
• İlkeyi etkinleştirmek için aşağıdaki iki komutdan birini kullanın:

  • nsrpolicy action update clone -p policyname -w workflowname -A actionname [--chronological_order | -l] 

  • nsradmin isteminde:

    • . type nsr protection policy action; policy name: policy; workflow: workflow: name: action

    • update Chronological order: Yes

      
       
• Bu işlem tamamlandıktan sonra, tek kaynak ve hedef birimlerde daha önce bahsedilen kısıtlamalar ve VM istemcisi başına birden çok örnekli artımlar kaldırılmış olur ve doğru şekilde işlenebilir.

ÖNEMLİ: NetWorker ve Data Domain'in kurtarılmasının bazı koşulların mümkün olduğu durumlarda, kaydedenler kopyalanmış olabilir. Bu, bazı bileşenlerin çoğaltma için VSR'yi kullanmama neden olur ancak zincirin tamamı geri yüklendikten sonra VSR klonlama işlemi sorun olmadan devam edebilir. Genellikle, sipariş dışı klonlama, çok birimli ve çok kaydetmeli küme klonlama, normal işlemi yakalar ve normal çalışma durumuna geri döner.
 
Ancak halihazırda birden fazla Data Domain IP adresinin zaten kullanılıyor olması veya Data Domain kaynağının veya hedefin tamamen değiştirilmesi durumunda normal ve tutarlı VSR optimizasyonuna geri dönmek için tek yol, değiştirilen blok izlemeyi sıfırlamak ve VSR optimizasyonuna geri dönmek için etkilenen VM'lerin yeni bir Tam yedeklemesini zorlamaktır. Bu, önceki adımlar tamamlandığında dikkate alınmalıdır ancak Data Domain ve/veya NetWorker günlüğe kaydetmenin yanı sıra klonlama hızları performans sorunlarının devam ettiğini gösterir.