Pecahkan masalah kesalahan replikasi Azure ke Azure VM

Perhatian

Artikel ini mereferensikan CentOS, distribusi Linux yang mendekati status End Of Life (EOL). Harap pertimbangkan penggunaan dan rencanakan yang sesuai. Untuk informasi selengkapnya, lihat panduan Akhir Masa Pakai CentOS.

Artikel ini menjelaskan cara memecahkan masalah kesalahan umum di Azure Site Recovery selama replikasi dan pemulihan mesin virtual Azure (VM) dari satu wilayah ke wilayah lainnya. Untuk informasi selengkapnya tentang konfigurasi yang didukung, lihat matriks dukungan untuk mereplikasi Azure VM.

Masalah kuota sumber daya Azure (kode kesalahan 150097)

Pastikan langganan Anda diaktifkan untuk membuat Azure VM di wilayah target yang Anda rencanakan untuk digunakan sebagai wilayah pemulihan bencana (DR). Langganan Anda memerlukan kuota yang cukup untuk membuat VM dengan ukuran yang diperlukan. Secara default, Site Recovery memilih ukuran VM target yang sama dengan ukuran VM sumber. Jika ukuran pencocokan tidak tersedia, Site Recovery secara otomatis memilih ukuran terdekat yang tersedia.

Jika tidak ada ukuran yang mendukung konfigurasi VM sumber, pesan berikut ditampilkan:

Replication couldn't be enabled for the virtual machine <VmName>.

Kemungkinan penyebab

• ID langganan Anda tidak diaktifkan untuk membuat VM apa pun di lokasi wilayah target.
• ID langganan Anda tidak diaktifkan, atau tidak memiliki kuota yang memadai, untuk membuat ukuran VM tertentu di lokasi wilayah target.
• Tidak ditemukan ukuran VM target yang sesuai untuk mencocokkan jumlah kartu antarmuka jaringan (NIC) sumber VM (2), untuk ID langganan di lokasi wilayah target.

Perbaiki masalah

Hubungi dukungan tagihan Azure untuk memungkinkan langganan Anda membuat VM dengan ukuran yang diperlukan di lokasi target. Kemudian, coba lagi operasi yang gagal.

Jika lokasi target memiliki batasan kapasitas, nonaktifkan replikasi ke lokasi tersebut. Kemudian, aktifkan replikasi ke lokasi yang berbeda di mana langganan Anda memiliki kuota yang cukup untuk membuat VM dengan ukuran yang diperlukan.

Sertifikat akar tepercaya (kode kesalahan 151066)

Jika tidak semua sertifikat akar tepercaya ada di VM, tugas Anda untuk mengaktifkan replikasi untuk Site Recovery mungkin gagal. Autentikasi dan otorisasi panggilan layanan Site Recovery dari VM gagal tanpa sertifikat ini.

Jika pekerjaan replikasi diaktifkan gagal, pesan berikut ditampilkan:

Site Recovery configuration failed.

Kemungkinan penyebab

Sertifikat akar tepercaya yang diperlukan yang digunakan untuk otorisasi dan autentikasi tidak ada di mesin.

Perbaiki masalah

Windows

Untuk VM yang menjalankan sistem operasi Windows, pasang pembaruan Windows terbaru sehingga semua sertifikat akar tepercaya ada pada VM. Ikuti manajemen pembaruan Windows umum atau proses manajemen pembaruan sertifikat di organisasi Anda untuk mendapatkan sertifikat akar terbaru dan daftar pencabutan sertifikat yang diperbarui pada VM.

• Di lingkungan yang sambungannya terputus, ikuti proses pembaruan Windows dan pembaruan sertifikat standar untuk organisasi Anda.
• Jika sertifikat yang diperlukan tidak ada di VM, panggilan ke layanan Site Recovery gagal karena alasan keamanan.

Untuk memverifikasi bahwa masalah telah diatasi, buka login.microsoftonline.com dari browser di VM Anda.

Untuk informasi selengkapnya, lihat Mengonfigurasi akar tepercaya dan sertifikat yang tidak diizinkan.

Linux

Ikuti panduan yang disediakan oleh distributor versi sistem operasi Linux Anda untuk mendapatkan sertifikat akar tepercaya terbaru dan daftar pencabutan sertifikat terbaru di VM.

Karena SUSE Linux menggunakan tautan simbolik, atau symlink, untuk mempertahankan daftar sertifikat, ikuti langkah-langkah berikut:

1. Masuk sebagai pengguna akar. Simbol hash (#) adalah prompt perintah default.

2. Untuk mengubah direktori, jalankan perintah ini:

   cd /etc/ssl/certs

3. Periksa apakah sertifikat CA akar Symantec ada:

   ls VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

   • Jika sertifikat CA root Symantec tidak ditemukan, jalankan perintah berikut untuk mengunduh file. Periksa kesalahan apa pun dan ikuti tindakan yang direkomendasikan untuk kegagalan jaringan.

     wget https://docs.broadcom.com/docs-and-downloads/content/dam/symantec/docs/other-resources/verisign-class-3-public-primary-certification-authority-g5-en.pem -O VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem

4. Periksa apakah sertifikat CA akar Baltimore ada:

   ls Baltimore_CyberTrust_Root.pem

   • Jika sertifikat CA akar Baltimore tidak ditemukan, jalankan perintah ini untuk mengunduh sertifikat:

     wget https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem -O Baltimore_CyberTrust_Root.pem

5. Periksa apakah DigiCert_Global_Root_CA anda ada:

   ls DigiCert_Global_Root_CA.pem

   • Jika DigiCert_Global_Root_CA tidak ditemukan, jalankan perintah berikut untuk mengunduh sertifikat:

     wget http://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt
     
     openssl x509 -in DigiCertGlobalRootCA.crt -inform der -outform pem -out DigiCert_Global_Root_CA.pem
     

6. Untuk memperbarui hash subjek sertifikat untuk sertifikat yang baru diunduh, jalankan skrip rehash:

   c_rehash

7. Untuk memeriksa apakah subjek hashes sebagai symlink dibuat untuk sertifikat, jalankan perintah ini:

   ls -l | grep Baltimore
   

   lrwxrwxrwx 1 root root   29 Jan  8 09:48 3ad48a91.0 -> Baltimore_CyberTrust_Root.pem
   
   -rw-r--r-- 1 root root 1303 Jun  5  2014 Baltimore_CyberTrust_Root.pem
   

   ls -l | grep VeriSign_Class_3_Public_Primary_Certification_Authority_G5
   

   -rw-r--r-- 1 root root 1774 Jun  5  2014 VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
   
   lrwxrwxrwx 1 root root   62 Jan  8 09:48 facacbc6.0 -> VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem
   

   ls -l | grep DigiCert_Global_Root
   

   lrwxrwxrwx 1 root root   27 Jan  8 09:48 399e7759.0 -> DigiCert_Global_Root_CA.pem
   
   -rw-r--r-- 1 root root 1380 Jun  5  2014 DigiCert_Global_Root_CA.pem
   

8. Buat salinan file VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem dengan nama file b204d74a.0:

   cp VeriSign_Class_3_Public_Primary_Certification_Authority_G5.pem b204d74a.0

9. Buat salinan file Baltimore_CyberTrust_Root.pem dengan nama file 653b494a.0:

   cp Baltimore_CyberTrust_Root.pem 653b494a.0

10. Buat salinan file dengan DigiCert_Global_Root_CA.pemdengan nama file 3513523f.0:

    cp DigiCert_Global_Root_CA.pem 3513523f.0

11. Periksa apakah file ada:

    ls -l 653b494a.0 b204d74a.0 3513523f.0
    

    -rw-r--r-- 1 root root 1774 Jan  8 09:52 3513523f.0
    
    -rw-r--r-- 1 root root 1303 Jan  8 09:52 653b494a.0
    
    -rw-r--r-- 1 root root 1774 Jan  8 09:52 b204d74a.0
    

URL atau rentang IP keluar (kode kesalahan 151037 atau 151072)

Agar replikasi Site Recovery berfungsi, konektivitas keluar ke URL atau rentang IP khusus diperlukan dari VM. Jika VM Anda berada di belakang firewall atau menggunakan aturan NSG untuk mengontrol konektivitas keluar, Anda mungkin menghadapi salah satu masalah ini. Meskipun kami terus mendukung akses keluar melalui URL, menggunakan daftar rentang IP yang diizinkan tidak lagi didukung.

Kemungkinan penyebab

• Koneksi tidak dapat dibuat dengan titik akhir Site Recovery karena kegagalan resolusi DNS.
• Masalah ini lebih umum terjadi selama perlindungan ulang ketika Anda telah melakukan kegagalan pada VM tetapi server DNS tidak dapat dijangkau dari wilayah DR.

Perbaiki masalah

Jika Anda menggunakan DNS kustom, pastikan server DNS dapat diakses dari wilayah pemulihan bencana.

Untuk memeriksa apakah VM menggunakan pengaturan DNS kustom:

1. Buka Mesin Virtual dan pilih VM.
2. Navigasi ke Pengaturan dan pilih Jaringan.
3. Di Virtual network/subnet, pilih tautan untuk membuka halaman sumber daya virtual network.
4. Masuk ke Pengaturan dan pilih Server DNS.

Cobalah mengakses server DNS dari mesin virtual. Jika server DNS tidak dapat diakses, lakukan failover pada server DNS atau buat garis target di antara jaringan DR dan DNS agar server dapat diakses.

Catatan

Jika Anda menggunakan titik akhir privat, pastikan VM bisa mengatasi catatan DNS pribadi.

Masalah 2: Konfigurasi Site Recovery gagal (151196)

Kemungkinan penyebab

Koneksi tidak dapat dibuat ke autentikasi Microsoft 365 dan titik akhir identitas IP4.

Perbaiki masalah

Azure Site Recovery memerlukan akses ke rentang IP Microsoft 365 untuk autentikasi. Jika Anda menggunakan aturan Azure Network Security Group (NSG) /proksi firewall untuk mengontrol konektivitas jaringan keluar pada VM, pastikan Anda menggunakan aturan NSG berbasis tag layanan Microsoft Entra untuk mengizinkan akses ke ID Microsoft Entra. Kami tidak lagi mendukung aturan NSG berbasis alamat IP.

Masalah 3:Konfigurasi Site Recovery gagal (151197)

Kemungkinan penyebab

Koneksi tidak dapat dibuat ke titik akhir layanan Azure Site Recovery.

Perbaiki masalah

Jika Anda menggunakan aturan/ proksi firewall Azure Network Security Group (NSG) untuk mengontrol konektivitas jaringan keluar pada VM, pastikan Anda menggunakan tags layanan. Kami tidak lagi mendukung penggunaan daftar alamat IP yang diizinkan melalui NSGs untuk Azure Site Recovery.

Masalah 4: Replikasi gagal ketika lalu lintas jaringan menggunakan server proksi lokal (151072)

Kemungkinan penyebab

Pengaturan proksi kustom tidak valid dan agen layanan Mobilitas tidak otomatis mendeteksi pengaturan proksi dari Internet Explorer (IE).

Perbaiki masalah

1. Agen layanan Mobilitas mendeteksi pengaturan proksi dari IE di Windows dan /etc/environment Linux.

2. Jika Anda lebih memilih untuk menyetel proksi hanya untuk layanan Mobilitas, Anda dapat memberikan detail proksi di ProxyInfo.conf yang berlokasi di:

   • Linux: /usr/local/InMage/config/
   • Windows: C:\ProgramData\Microsoft Azure Site Recovery\Config

3. ProxyInfo.conf harus memiliki pengaturan proksi dalam format INI berikut.

   [proxy]
   Address=http://1.2.3.4
   Port=567
   

Catatan

Agen servis Mobility hanya mendukung proksi yang tidak diautentikasi.

Informasi selengkapnya

Untuk menentukan URL yang diperlukan atau rentang IP yang diperlukan,ikuti panduan Tentang jaringan di replikasi Azure ke Azure.

Disk tidak ditemukan di VM (kode kesalahan 150039)

Disk baru yang terpasang pada VM harus diinisialisasi. Jika disk tidak ditemukan, pesan berikut ditampilkan:

Azure data disk <DiskName> <DiskURI> with logical unit number <LUN> <LUNValue> was not mapped to a corresponding disk being reported from within the VM that has the same LUN value.

Kemungkinan penyebab

• Disk data baru dilampirkan ke VM tetapi tidak diinisialisasi.
• Disk data di dalam VM tidak melaporkan nilai nomor unit logis (LUN) dengan benar saat disk dilampirkan ke VM.

Perbaiki masalah

Pastikan bahwa disk data diinisialisasi, lalu coba operasikan lagi.

• Windows: Pasang dan inisialisasi disk baru.
• Linux: Mengawali disk data baru di Linux.

Jika masalah masih berlangsung, hubungi dukungan.

Beberapa disk tersedia untuk perlindungan (kode kesalahan 153039)

Kemungkinan penyebab

• Satu atau beberapa diska baru-baru ini ditambahkan ke mesin virtual setelah perlindungan.
• Satu atau beberapa disk diinisialisasi setelah perlindungan mesin virtual.

Perbaiki masalah

Untuk membuat status replikasi VM sehat kembali, Anda dapat memilih untuk melindungi disk atau untuk menghilangkan peringatan.

Untuk melindungi disk

1. Pergi ke Item Direplikasi >VM>nama Disk.

2. Pilih disk yang tidak terlindungi, lalu pilih Aktifkan replikasi:

   

Untuk menghilangkan peringatan

1. Pergi ke Item Direplikasi >VM nama.

2. Pilih peringatan di bagian Gambaran Umum, lalu pilih OK.

   

VM dihapus dari vault yang dilengkapi dengan informasi (kode kesalahan 150225)

Ketika Site Recovery melindungi mesin virtual, tercipta tautan pada mesin virtual sumber. Ketika Anda menghapus proteksi atau menonaktifkan replikasi, Site Recovery menghapus tautan ini sebagai bagian dari pekerjaan pembersihan. Jika mesin virtual memiliki kunci sumber daya, pekerjaan pembersihan akan dilengkapi dengan informasi. Informasi mengatakan bahwa mesin virtual telah dihapus dari brankas Layanan Recovery, tetapi bahwa beberapa tautan basi tidak dapat dibersihkan pada mesin sumber.

Anda dapat mengabaikan peringatan ini jika Anda tidak pernah berniat untuk melindungi mesin virtual ini lagi. Tetapi jika Anda harus melindungi mesin virtual ini nanti, ikuti langkah-langkah di bagian ini untuk membersihkan tautan.

Peringatan

Jika Anda tidak melakukan pembersihan:

• Saat Anda mengaktifkan replikasi melalui vault Layanan Recovery, mesin virtual tidak akan dicantumkan.
• Jika Anda mencoba melindungi VM dengan menggunakan mesin Virtual>Settings>Disaster Recovery,operasi akan gagal dengan pesan Replikasi tidak dapat diaktifkan karena tautan sumber daya basi yang ada pada VM.

Perbaiki masalah

Catatan

Site Recovery tidak menghapus mesin virtual sumber atau mempengaruhinya dengan cara apa pun saat Anda melakukan langkah-langkah ini.

1. Menghapus kunci dari VM atau Grup sumber daya VM. Misalnya, dalam gambar berikut, kunci sumber daya pada VM bernama MoveDemo harus dihapus:

   

2. Unduh skrip untuk menghapus konfigurasi Site Recovery kedaluwarsa.

3. Jalankan skrip, Cleanup-stale-asr-config-Azure-VM.ps1. Berikan ID Langganan, Grup Sumber Daya VM, dan nama VM sebagai parameter.

4. Jika Anda dimintai kredensial Azure, berikan kredensial tersebut. Kemudian verifikasi bahwa skrip berjalan tanpa kegagalan.

Replikasi tidak diaktifkan pada VM dengan sumber daya kedaluwarsa (kode kesalahan 150226)

Kemungkinan penyebab

Mesin virtual memiliki konfigurasi kedaluwarsa dari perlindungan Site Recovery sebelumnya.

Konfigurasi kedaluwarsa dapat terjadi pada Azure VM jika Anda mengaktifkan replikasi untuk Azure VM dengan menggunakan Site Recovery, lalu:

• Anda menonaktifkan replikasi, tetapi sumber VM memiliki kunci sumber daya.
• Anda menghapus vault Site Recovery tanpa secara eksplisit menonaktifkan replikasi pada VM.
• Anda menghapus grup sumber daya yang mangandung Site Recovery tanpa secara eksplisit menonaktifkan replikasi pada VM.

Perbaiki masalah

Catatan

Site Recovery tidak menghapus mesin virtual sumber atau mempengaruhinya dengan cara apa pun saat Anda melakukan langkah-langkah ini.

1. Menghapus kunci dari VM atau Grup sumber daya VM. Misalnya, dalam gambar berikut, kunci sumber daya pada VM bernama MoveDemo harus dihapus:

   

2. Unduh skrip untuk menghapus konfigurasi Site Recovery kedaluwarsa.

3. Jalankan skrip, Cleanup-stale-asr-config-Azure-VM.ps1. Berikan ID Langganan, Grup Sumber Daya VM, dan nama VM sebagai parameter.

4. Jika Anda dimintai kredensial Azure, berikan kredensial tersebut. Kemudian verifikasi bahwa skrip berjalan tanpa kegagalan.

Tidak dapat memilih VM atau grup sumber daya dalam mengaktifkan pekerjaan replikasi

Masalah 1: Grup sumber daya dan sumber VM berada di lokasi yang berbeda

Site Recovery saat ini mengharuskan grup sumber daya wilayah sumber dan mesin virtual berada di lokasi yang sama. Jika tidak, Anda tidak akan dapat menemukan mesin virtual atau grup sumber daya saat Anda mencoba menerapkan perlindungan.

Sebagai solusinya, Anda dapat mengaktifkan replikasi dari VM, bukan vault Layanan Recovery. Buka Sumber VM>Properties>Disaster Recovery dan aktifkan replikasi.

Masalah 2: Grup sumber daya bukan bagian dari langganan yang dipilih

Anda mungkin tidak dapat menemukan grup sumber daya pada saat perlindungan jika grup sumber daya bukan bagian dari langganan yang dipilih. Pastikan bahwa grup sumber daya milik langganan yang Anda gunakan.

Masalah 3: Konfigurasi kedaluwarsa

Anda mungkin tidak melihat VM yang ingin Anda aktifkan untuk replikasi jika konfigurasi Site Recovery kedaluwarsa ada di Azure VM. Kondisi ini dapat terjadi jika Anda mengaktifkan replikasi untuk Azure VM dengan menggunakan Site Recovery, lalu:

• Anda menghapus vault Site Recovery tanpa secara eksplisit menonaktifkan replikasi pada VM.
• Anda menghapus grup sumber daya yang mangandung Site Recovery tanpa secara eksplisit menonaktifkan replikasi pada VM.
• Anda menonaktifkan replikasi, tetapi sumber VM memiliki kunci sumber daya.

Perbaiki masalah

Catatan

Pastikan untuk memperbarui AzureRM.Resources modul sebelum menggunakan skrip yang disebutkan di bagian ini. Site Recovery tidak menghapus mesin virtual sumber atau mempengaruhinya dengan cara apa pun saat Anda melakukan langkah-langkah ini.

1. Menghapus kunci, jika ada, dari VM atau Grup sumber daya VM. Misalnya, dalam gambar berikut, kunci sumber daya pada VM bernama MoveDemo harus dihapus:

   

2. Unduh skrip untuk menghapus konfigurasi Site Recovery kedaluwarsa.

3. Jalankan skrip, Cleanup-stale-asr-config-Azure-VM.ps1. Berikan ID Langganan, Grup Sumber Daya VM, dan nama VM sebagai parameter.

4. Jika Anda dimintai kredensial Azure, berikan kredensial tersebut. Kemudian verifikasi bahwa skrip berjalan tanpa kegagalan.

Tidak bisa memilih VM untuk perlindungan

Kemungkinan penyebab

Mesin virtual memiliki ekstensi yang terpasang dalam keadaan gagal atau tidak responsif

Perbaiki masalah

Buka Ekstensi>Pengaturan>Mesin Virtual dan periksa ekstensi apa pun dalam keadaan gagal. Bongkar ekstensi yang gagal, lalu coba kembali untuk melindungi mesin maya.

Status penyediaan VM tidak valid (kode kesalahan 150019)

Untuk mengaktifkan replikasi pada VM, status penyediaannya harus Berhasil. Lakukan langkah-langkah berikut untuk memeriksa status provisi:

1. Di portal Azure, pilih Penjelajah Sumber Daya dari Semua Layanan.
2. Perluas daftar Langganan dan pilih langganan Anda.
3. Perluas daftar Grup Sumber Daya dan pilih grup sumber daya VM.
4. Perluas daftar Sumber Daya dan pilih VM Anda.
5. Periksa bidang provisioningState dalam tampilan instans di sisi kanan.

Perbaiki masalah

• Jika provisioningState,ternyatagagal, hubungi dukungan dengan detail untuk memecahkan masalah.
• Jika provisioningState sedang memperbarui,ekstensi lain mungkin sedang digunakan. Periksa apakah ada operasi yang sedang berlangsung pada VM, tunggu mereka selesai, lalu coba lagi Site Recovery yang gagal untuk mengaktifkan replikasi.

Tidak dapat memilih VM target

Masalah 1: VM dilampirkan ke jaringan yang sudah dipetakan ke jaringan target

Selama konfigurasi pemulihan bencana, jika VM sumber adalah bagian dari jaringan virtual, dan VM lain dari jaringan virtual yang sama sudah dipetakan dengan jaringan di grup sumber daya target, kotak daftar drop-down pemilihan jaringan tidak tersedia (tampak redup) secara default.

Masalah 2: Anda sebelumnya melindungi VM dan kemudian Anda menonaktifkan replikasi

Menonaktifkan replikasi VM tidak menghapus pemetaan jaringan. Pemetaan harus dihapus dari vault Layanan Recovery di mana VM dilindungi. Pilih vault Layanan Recovery dan buka Mengelola >Infrastruktur Site Recovery>Untuk Pemetaan Jaringan mesin virtual >Azure.

Jaringan target yang dikonfigurasi selama pengaturan pemulihan bencana dapat diubah setelah pengaturan awal, dan setelah VM dilindungi. Untuk Mengubah pemetaan jaringan pilih nama jaringan:

COM+ atau VSS (kode kesalahan 151025)

Ketika kesalahan COM+ atau Layanan Menyalin Bayangan Volume (VSS) terjadi, pesan berikut ditampilkan:

Site Recovery extension failed to install.

Kemungkinan penyebab

• Layanan Aplikasi Sistem COM+ dinonaktifkan.
• Layanan Menyalin Bayangan Volume dinonaktifkan.

Perbaiki masalah

Atur layanan COM+ System Application dan Layanan Menyalin Bayangan Volume ke mode mulai otomatis atau manual.

1. Buka konsol Layanan di Windows.

2. Pastikan Com+ System Application dan Layanan Menyalin Bayangan Volume tidak diatur ke Dinonaktifkan sebagai Jenis Startup mereka.

   

Ukuran disk terkelola yang tidak didukung (kode kesalahan 150172)

Ketika kesalahan ini terjadi, pesan berikut ditampilkan:

Protection couldn't be enabled for the virtual machine as it has <DiskName> with size <DiskSize> that is lesser than the minimum supported size 1024 MB.

Kemungkinan penyebab

Disk ini lebih kecil dari ukuran yang didukung sebesar 1024 MB.

Perbaiki masalah

Pastikan ukuran disk berada dalam rentang yang didukung, lalu coba operasikan lagi.

Perlindungan tidak diaktifkan ketika GRUB menggunakan nama perangkat (kode kesalahan 151126)

Kemungkinan penyebab

File konfigurasi Linux Grand Unified Bootloader (GRUB)(/boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg, atau /etc/default/grub)mungkin menentukan nama perangkat yang sebenarnya alih-alih nilai pengidentifikasi unik universal (UUID) untuk root dan resume parameter. Site Recovery memerlukan UUID karena nama perangkat bisa berubah. Setelah restart, VM mungkin tidak muncul dengan nama yang sama pada failover, sehingga mengakibatkan masalah.

Contoh berikut adalah baris dari file GRUB di mana nama perangkat muncul alih-alih UUID yang diperlukan:

• File /boot/grub2/grub.cfg:

  linux /boot/vmlinuz-3.12.49-11-default root=/dev/sda2 ${extra_cmdline} resume=/dev/sda1 splash=silent quiet showopts

• File: /boot/grub/menu.lst

  kernel /boot/vmlinuz-3.0.101-63-default root=/dev/sda2 resume=/dev/sda1 splash=silent crashkernel=256M-:128M showopts vga=0x314

Perbaiki masalah

Ganti setiap nama perangkat dengan UUID yang sesuai:

1. Temukan UUID perangkat dengan menjalankan perintahblkid <device name>. Contohnya:

   blkid /dev/sda1
   /dev/sda1: UUID="6f614b44-433b-431b-9ca1-4dd2f6f74f6b" TYPE="swap"
   blkid /dev/sda2
   /dev/sda2: UUID="62927e85-f7ba-40bc-9993-cc1feeb191e4" TYPE="ext3"
   

2. Ganti nama perangkat dengan UUID-nya, dalam format root=UUID=<UUID> dan resume=UUID=<UUID>. Misalnya, setelah penggantian, garis dari /boot/grub/menu.lst akan terlihat seperti baris berikut:

   kernel /boot/vmlinuz-3.0.101-63-default root=UUID=62927e85-f7ba-40bc-9993-cc1feeb191e4 resume=UUID=6f614b44-433b-431b-9ca1-4dd2f6f74f6b splash=silent crashkernel=256M-:128M showopts vga=0x314

3. Coba lagi perlindungannya.

Perlindungan gagal karena perangkat GRUB tidak ada (kode kesalahan 151124)

Kemungkinan penyebab

File konfigurasi GRUB(/boot/grub/menu.lst, /boot/grub/grub.cfg, /boot/grub2/grub.cfg, atau /etc/default/grub)mungkin mengandung parameter rd.lvm.lv atau rd_LVM_LV. Parameter ini mengidentifikasi perangkat Logical Volume Manager (LVM) yang akan ditemukan pada waktu boot. Jika perangkat LVM ini tidak ada, sistem yang dilindungi itu sendiri tidak akan boot dan akan terjebak dalam proses boot. Masalah yang sama juga akan terlihat dengan VM failover. Berikut beberapa contohnya:

• File: /boot/grub2/grub.cfg di RHEL7:

  linux16 /vmlinuz-3.10.0-957.el7.x86_64 root=/dev/mapper/rhel_mup--rhel7u6-root ro crashkernel=128M\@64M rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rhgb quiet LANG=en_US.UTF-8

• File: /etc/default/grub di RHEL7:

  GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=rootvg/root rd.lvm.lv=rootvg/swap rhgb quiet

• File: /boot/grub/menu.lst di RHEL6:

  kernel /vmlinuz-2.6.32-754.el6.x86_64 ro root=UUID=36dd8b45-e90d-40d6-81ac-ad0d0725d69e rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=rootvg/lv_root KEYBOARDTYPE=pc KEYTABLE=us rd_LVM_LV=rootvg/lv_swap rd_NO_DM rhgb quiet

Dalam setiap contoh, GRUB harus mendeteksi dua perangkat LVM dengan nama root dan swapdari grup volume rootvg.

Perbaiki masalah

Jika perangkat LVM tidak ada, buat atau hapus parameter yang sesuai dari file konfigurasi GRUB. Kemudian, coba lagi untuk mengaktifkan perlindungan.

Pembaruan layanan mobilitas selesai dengan peringatan (kode kesalahan 151083)

Layanan Site Recovery Mobility memiliki banyak komponen, salah satunya disebut driver filter. Pengandar filter dimuat ke dalam memori sistem hanya selama mulai ulang sistem. Setiap kali pembaruan layanan Mobilitas mencakup perubahan pengandar filter, mesin diperbarui tetapi Anda masih melihat peringatan bahwa beberapa perbaikan memerlukan pemulaian ulang. Peringatan muncul karena perbaikan pengandar filter hanya dapat berlaku ketika pengandar filter baru dimuat, yang terjadi hanya selama pemulaian ulang.

Catatan

Ini hanya peringatan. Replikasi yang ada terus bekerja bahkan setelah pembaruan agen baru. Anda dapat memilih untuk memulai ulang kapan pun Anda menginginkan manfaat driver filter baru, tetapi driver filter lama tetap berfungsi jika Anda tidak memulai ulang.

Terlepas dari driver filter, manfaat dari peningkatan dan perbaikan lain dalam pembaruan layanan Mobilitas berlaku tanpa memerlukan pemulaian ulang.

Proteksi tidak diaktifkan jika ada disk terkelola replika

Kegagalan ini terjadi ketika replika disk yang dikelola sudah ada, tanpa tag yang diharapkan, dalam grup sumber daya target.

Kemungkinan penyebab

Masalah ini dapat terjadi jika komputer virtual sebelumnya dilindungi, dan disk replika tidak diaktifkan, disk tidak dihapus.

Perbaiki masalah

Hapus disk replika yang diidentifikasi dalam pesan kesalahan dan coba lagi tugas perlindungan yang gagal.

Aktifkan perlindungan gagal karena penginstal tidak dapat menemukan disk akar (kode kesalahan 151137)

Kesalahan ini terjadi untuk mesin Linux di mana disk OS dienkripsi menggunakan Azure Disk Encryption (ADE). Ini adalah masalah yang hanya valid di Agen versi 9.35.

Kemungkinan Penyebabnya

Penginstal tak bisa menemukan disk akar yang menghosting sistem-berkas akar.

Perbaiki masalah

Lakukan langkah-langkah berikut untuk memperbaiki masalah ini.

1. Temukan bit agen di bawah direktori /var/lib/waagent pada mesin RHEL dan CentOS menggunakan perintah di bawah ini:
   

   # find /var/lib/ -name Micro\*.gz

   Output yang diharapkan:

   /var/lib/waagent/Microsoft.Azure.RecoveryServices.SiteRecovery.LinuxRHEL7-1.0.0.9139/UnifiedAgent/Microsoft-ASR_UA_9.35.0.0_RHEL7-64_GA_30Jun2020_release.tar.gz

2. Buat direktori baru dan ubah direktori ke direktori baru ini.

3. Ekstrak file Agen yang ditemukan pada langkah pertama di sini, menggunakan perintah di bawah ini:

   tar -xf <Tar Ball File>

4. Buka file prereq_check_installer.jsdan hapus baris berikut. Simpan file setelah itu.

      {
         "CheckName": "SystemDiskAvailable",
         "CheckType": "MobilityService"
      },
   

5. Panggil alat penginstal menggunakan perintah :
   

   ./install -d /usr/local/ASR -r MS -q -v Azure

6. Jika penginstal berhasil, coba lagi pekerjaan pengaktifan replikasi.

Memecahkan masalah dan menangani perubahan waktu pada server yang direplikasi

Kesalahan ini terjadi ketika waktu mesin sumber bergerak maju dan kemudian bergerak mundur dalam waktu singkat, untuk memperbaiki perubahan. Anda mungkin tidak melihat perubahan karena waktu dikoreksi dengan sangat cepat.

Cara memperbaiki: Untuk mengatasi masalah ini, tunggu hingga waktu sistem melewati waktu miring di masa mendatang. Opsi lainnya adalah menonaktifkan dan mengaktifkan replikasi sekali lagi, yang hanya layak untuk replikasi maju (data direplikasi dari wilayah primer ke sekunder) dan tidak berlaku untuk replikasi terbalik (data direplikasi dari wilayah sekunder ke primer).

Langkah berikutnya

Replikasi Azure VM ke wilayah Azure lain.