NetWorker: Data Domain'ler arasında Kapasite Modu vProxy klonu 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, performans sorununun nedeni olarak elenir ve klonlama sırasında eşiğin oldukça altında kalır.
• İletiler ddfs'de bulunur.Bir veya daha fazlasına atıfta bulunan bilgi günlükleri *-flat.vmdk Etkilenen sanal makine (VM) diskleri için aşağıdakileri içeren dosyalar:
  • synthesized_vbytes 0 ve ile biten recipe_repl FALSE
  • srepl_filecopy_recipe_validate_bf: Temel dosya için srepl_get_replica_attr ve şu hatayla bitiyor: Dosya tanıtıcısı eski.
• Etkilenen VM'nin diskleri için bir veya daha fazla *-flat.vmdk dosyasına atıfta bulunan ve aşağıdakileri içeren kopyalama eylem günlüklerinde bulunan mesajlar (klon hata ayıklama düzeyi 3 veya daha yüksek olduğunda):
  • Dosya için sentetik çoğaltma kullanılamaz... path.../vm-vmnumber-disk-key-disknumber-flat.vmdk

vProxy, VMware'in değiştirilen blok izleme API'sinden yararlanmak için sanal sentetikler kullanır ve hem yedekleme hem de klonlama işlemleri için muazzam kazançlar sağlar. Bunun için ilgili her Data Domain üzerinde VM dosya seti kalıtımının dahili ilişkilendirmelerinin aktif olarak sürdürülmesi gerekir. Sanal sentetik kullanarak klonlamaya hazırlanırken sorunlar ortaya çıkarsa NetWorker ve Data Domain bunun yerine varsayılan çoğaltma iş akışını kullanmaya geri döner. Bunun için VMware API tarafından sağlanan yalnızca değiştirilen blokların aksine yalnızca değiştirilen blokların değil, sanal disk dosyalarının tamamının işlenmesi gerekir. Tekilleştirme nedeniyle çok az veri gönderilse bile klonlama işinin süresi kat kat artabilir.
 
Sanal sentetik izlemenin başarısız olmasına yol açabilecek nedenler şunlardır:

• İşler arasında kaynak veya hedef Data Domain aygıtları için NetWorker'da çözümlenen farklı IP adresleri. Bunlar, sanal sentetiklerin dahili takibi 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 fazla kaynak veya hedef disk bölümü, zincirdeki birden fazla kayıt setinin aynı anda klonlanmasına neden olabilir
• Belirli bir sanal makine için klonlama gerektiren birden fazla vProxy kayıt kümesi, zincirdeki kayıt kümelerinin düzensiz klonlanmasına neden olabilir
• Herhangi bir değişiklik yapılmadan uzun süreler boyunca giden VM diskleri (özellikle, saklamanın 30 gün olduğu değişikliksiz 35 gün gibi kaydetme kümesini aşan süreler)
• ChronologicalOrder Action özelliğinin kullanılamaması

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

• ifgroups hem kaynak (yedekleme) hem de hedef (klon hedefi) Veri Etki Alanları için doğru şekilde ayarlanır
• NetWorker sunucusu, depolama düğümleri ve Data Domain'lerin hepsi, uygun ana bilgisayar dosya girişlerine sahiptir ifgroup Data Domain başına IP'ler ve istemciler için güvenilir DNS (NetWorker istemcisi dosyaları ihtiyaç duyduğunda barındırır).
• Her yedekleme ve klon havuzu için tek Data Domain.

Kullanıcı arayüzünde gizlenmiş olabilecek vProxy kaydetme kümesi klonlama eylemleri için ChronologicalOrder özelliğini etkinleştirin:

• Kullanılıyorsa nsrclone komutunu, -O Belirli bir istemcinin zincirinde birden fazla kayıt kümesi içeren bir kaydetme kümesi listesi kullanırken bu yeni özelliği uygulamak için geçiş yapın
• Politikada etkinleştirmek için aşağıdaki iki komuttan birini kullanın:

nsrpolicy action update clone -p policyname -w workflowname -A actionname [--chronological_order | -l] <yes|no>

• nsradmin isteminde:

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

update Chronological order: Yes

• Bu tamamlandıktan sonra, tek kaynak ve hedef disk bölümlerinde daha önce bahsedilen kısıtlamaların yanı sıra VM istemcisi başına çok örnekli artımlar kaldırılır ve düzgün bir şekilde işlenebilir.

ÖNEMLİ: NetWorker ve Data Domain'in, kaydetme kümelerinin sıra dışı klonlandığı bazı koşullardan kurtarılması mümkün olabilir. Bu, bazılarının çoğaltma için VSR'yi kullanamamasına neden olur ancak tüm zincir geri yüklendikten sonra VSR klonlama işlemi sorunsuz bir şekilde devam edebilir. Genel olarak, sıra dışı klonlama, çoklu birim ve çoklu kaydetme kümesi klonlaması, arayı yakalayabilir ve normal çalışmaya geri dönebilir.
 
Birden fazla Data Domain IP adresinin kullanılmış olması veya Data Domain kaynağının veya hedefinin tamamen değiştirilmesi durumunda düzenli ve tutarlı VSR optimizasyonuna geri dönmenin tek yolu, etkilenen sanal makinelerin yeni bir Tam yedeklemesini, değiştirilen blok takibini sıfırlamaya ve VSR optimizasyonunu geri yüklemeye zorlamaktır. Önceki adımlar tamamlandığında ancak Data Domain ve/veya NetWorker günlüğe kaydetme ve klonlama hızları, performans sorunlarının devam ettiğini gösterdiğinde bu durum göz önünde bulundurulmalıdır.