Azure’dan şirket içine yapılan yeniden çalışma işleminde sorun giderme

Bu makalede, Azure Site Recovery kullanarak Azure'a yük devretme sonrasında Azure VM'lerini şirket içi VMware altyapınızda yeniden çalıştırırken karşılaşabileceğiniz sorunları giderme işlemi açıklanır.

Yeniden çalışma temelde iki ana adımı içerir. yük devretmeden sonraki ilk adımda, çoğaltmaya başlayabilmeleri için Azure VM'lerini şirket içinde yeniden korumanız gerekir. İkinci adım, şirket içi sitenize geri dönmek için Azure'dan yük devretme çalıştırmaktır.

Genel sorunlar

• Salt okunur bir kullanıcı vCenter bulma işlemi gerçekleştirir ve sanal makineleri korursanız koruma başarılı olur ve yük devretme çalışır. Yeniden koruma sırasında, veri depoları bulunamadığından yük devretme başarısız olur. Veri depolarının yeniden koruma sırasında listelenmemesi bir belirtidir. Bu sorunu çözmek için vCenter kimlik bilgilerini izinleri olan uygun bir hesapla güncelleştirebilir ve sonra işi yeniden deneyebilirsiniz.
• Bir Linux sanal makinesini yeniden çalıştırıp şirket içinde çalıştırdığınızda, Ağ Yöneticisi paketinin makineden kaldırıldığını görebilirsiniz. Bu kaldırma işleminin nedeni, sanal makine Azure'da kurtarıldığında Network Manager paketinin kaldırılmasıdır.
• Linux sanal makinesi statik IP adresiyle yapılandırıldığında ve Azure'a yük devredildiğinde, IP adresi DHCP'den alınır. Şirket içinde yük devreddiğinizde, sanal makine IP adresini almak için DHCP kullanmaya devam eder. Makinede el ile oturum açın ve gerekirse IP adresini yeniden statik bir adrese ayarlayın. Windows sanal makinesi statik IP adresini yeniden alabilir.
• ESXi 5.5 ücretsiz sürümünü veya vSphere 6 Hypervisor ücretsiz sürümünü kullanıyorsanız yük devretme başarılı olur, ancak yeniden çalışma başarılı olmaz. Yeniden çalışma özelliğini etkinleştirmek için herhangi bir programın değerlendirme lisansına yükseltin.
• yapılandırma sunucusuna işlem sunucusundan ulaşamıyorsanız, 443 numaralı bağlantı noktasındaki yapılandırma sunucusuna bağlantıyı denetlemek için Telnet'i kullanın. Yapılandırma sunucusuna işlem sunucusundan ping göndermeyi de deneyebilirsiniz. Yapılandırma sunucusuna bağlı olduğunda işlem sunucusunun da sinyali olmalıdır.
• Fiziksel şirket içi sunucu olarak korunan bir Windows Server 2008 R2 SP1 sunucusu Azure'dan şirket içi siteye geri yüklenemez.
• Aşağıdaki durumlarda yeniden başlatamazsınız:
  • Makineleri Azure'a geçirdiyseniz.
  • Vm'yi başka bir kaynak grubuna taşıdınız.
  • Azure VM'yi sildiyseniz.
  • VM korumasını devre dışı bırakmışsınız.
  • VM'yi Azure'da el ile oluşturdunuz. Makinenin başlangıçta şirket içinde korumalı olması ve yeniden korumadan önce Azure'a yük devredilmiş olması gerekir.
  • Yalnızca bir ESXi ana bilgisayarında başarısız olabilirsiniz. VMware VM'lerini veya fiziksel sunucuları Hyper-V konaklarına, fiziksel makinelere veya VMware iş istasyonlarına yeniden yükleyemezsiniz.

Yeniden koruma hatalarını giderme

Bu bölümde, sık karşılaşılan yeniden koruma hataları ve bunların nasıl düzeltilmesi gerektiği ayrıntılı olarak anlatılıyor.

Hata kodu 95226

Azure sanal makinesi şirket içi yapılandırma sunucusuna ulaşamadığından yeniden koruma başarısız oldu.

Bu hata şu durumlarda oluşur:

• Azure sanal makinesi, şirket içi yapılandırma sunucusuna erişemiyor. Sanal makine bulunamıyor ve yapılandırma sunucusuna kaydedilemiyor.
• Yük devretme sonrasında Azure sanal makinesinde InMage Scout uygulama hizmeti çalışmıyor. Bu hizmet, şirket içi yapılandırma sunucusuyla iletişim kurmak için gereklidir.

Bu sorunu çözmek için:

• Azure sanal makine ağının, Azure sanal makinesinin şirket içi yapılandırma sunucusuyla iletişim kurmasına izin verdiğinden emin olun. Şirket içi veri merkezinize siteden siteye VPN oluşturabilir veya Azure sanal makinesinin sanal ağında özel eşleme ile bir Azure ExpressRoute bağlantısı yapılandırabilirsiniz.
• Sanal makine şirket içi yapılandırma sunucusuyla iletişim kurabiliyorsa sanal makinede oturum açın. Ardından InMage Scout uygulama hizmetini denetleyin. Çalışmadığını görürseniz hizmeti el ile başlatın. Hizmet başlangıç türünün Otomatik olarak ayarlandığını denetleyin.

Hata kodu 78052

Sanal makine için koruma tamamlanamadı.

Bu sorun, geri yükleme yeniden çalıştırdığınız ana hedef sunucuda aynı ada sahip bir sanal makine olduğunda ortaya çıkabilir.

Bu sorunu çözmek için:

• Yeniden korumanın makineyi adların çakışmadığı farklı bir konakta oluşturması için farklı bir konakta farklı bir ana hedef sunucu seçin.
• Ayrıca VMotion kullanarak ana hedefi ad çakışmasının gerçekleşmeyeceği farklı bir konağa taşıyabilirsiniz. Mevcut sanal makine boş bir makineyse, yeni sanal makinenin aynı ESXi konağından oluşturulabilmesi için sanal makineyi yeniden adlandırın.

Hata kodu 78093

VM çalışmıyor, yanıt vermiyor veya erişilebilir değil.

Bu sorunu çözmek için:

Yük devredilen bir sanal makineyi yeniden koruma amacıyla Mobility Hizmetinin şirket içi yapılandırma sunucusuna kaydolması ve işlem sunucusuyla iletişim kurarak çoğaltmaya başlayabilmesi için Azure sanal makinesinin çalışıyor olması gerekir. Makine yanlış bir ağdaysa veya çalışmıyorsa (yanıt vermiyor veya kapatılmıyorsa), yapılandırma sunucusu yeniden korumayı başlatmak için sanal makinede Mobility Hizmetine ulaşamaz.

• Şirket içi ortamla iletişim kurmaya başlayabilmesi için sanal makineyi yeniden başlatın.
• Azure sanal makinesini başlattıktan sonra yeniden koruma işini yeniden başlatın.

Hata kodu 8061

Veri deposuna ESXi konağından erişilemiyor.

Yeniden çalışma için ana hedef önkoşullarını ve desteklenen veri depolarını denetleyin.

Yeniden çalışma hatalarını giderme

Bu bölümde, yeniden çalışma sırasında karşılaşabileceğiniz yaygın hatalar açıklanmaktadır.

Hata kodu 8038

Hata nedeniyle şirket içi sanal makine getirilemedi.

Bu sorun, şirket içi VM yeterli bellek sağlanmamış bir konağa getirildiğinde oluşur.

Bu sorunu çözmek için:

• ESXi ana bilgisayarında daha fazla bellek sağlayın.
• Buna ek olarak, VMotion kullanarak VM'yi vm'yi önyüklemek için yeterli belleğe sahip başka bir ESXi konağına taşıyabilirsiniz.