Arsitektur pemulihan bencana VMware ke Azure - Klasik
Artikel ini menjelaskan arsitektur dan proses yang digunakan saat Anda menyebarkan replikasi pemulihan bencana, failover, dan pemulihan mesin virtual VMware antara situs VMware lokal dan Azure dengan menggunakan layanan Azure Site Recovery - Klasik.
Untuk detail tentang arsitektur yang dimodernisasi, lihat artikel ini
Komponen arsitektur
Tabel dan grafik berikut ini menyediakan tampilan tingkat tinggi dari komponen yang digunakan untuk pemulihan bencana mesin virtual VMware/mesin fisik ke Azure.
| Komponen | Persyaratan | Detail |
|---|---|---|
| Azure | Langganan Azure, akun Azure Storage untuk cache, Disk Terkelola, dan jaringan Azure. | Data yang direplikasi dari komputer virtual lokal disimpan di penyimpanan Azure. Azure VM dibuat dengan data yang direplikasi saat Anda menjalankan failover dari lokal ke Azure. Azure VM tersambung ke jaringan virtual Azure saat dibuat. |
| Komputer server konfigurasi | Komputer lokal tunggal. Kami sarankan Anda menjalankannya sebagai komputer virtual VMware yang dapat disebarkan dari templat OVF yang diunduh. Komputer server konfigurasi menjalankan semua komponen Site Recovery lokal, yang mencakup server konfigurasi, server proses, dan server target master. |
Server konfigurasi: Mengoordinasikan komunikasi antara server lokal dan Azure, dan mengelola replikasi data. Server proses: Diinstal secara default di server konfigurasi. Server ini menerima data replikasi, mengoptimalkannya dengan penembolokan, pemadatan, dan enkripsi, lalu mengirimkannya ke Azure Storage. Server proses juga menginstal Layanan Mobilitas Azure Site Recovery pada komputer virtual yang ingin Anda replikasi, dan melakukan penemuan otomatis komputer lokal. Seiring dengan bertambahnya penyebaran, Anda dapat menambahkan server proses tambahan yang terpisah untuk menangani lalu lintas replikasi dalam volume yang lebih besar. Server target master: Diinstal secara default di server konfigurasi. Server ini menangani data replikasi selama failback dari Azure. Untuk penyebaran besar, Anda dapat menambahkan server target master tambahan yang terpisah untuk failback. |
| Server VMware | Komputer virtual VMware di-hosting di server vSphere ESXi lokal. Kami sarankan Anda menggunakan server vCenter untuk mengelola host. | Selama penyebaran Site Recovery, Anda menambahkan server VMware ke brankas Layanan Pemulihan. |
| Komputer yang direplikasi | Layanan Mobilitas diinstal pada setiap komputer virtual VMware yang Anda replikasi. | Kami sarankan Anda mengizinkan penginstalan otomatis dari server proses. Atau, Anda dapat menginstal layanan secara manual atau menggunakan metode penyebaran otomatis, seperti Configuration Manager. |
Siapkan konektivitas jaringan keluar
Agar Site Recovery berfungsi seperti yang diharapkan, Anda perlu mengubah konektivitas jaringan keluar untuk memungkinkan replikasi lingkungan Anda.
Catatan
Site Recovery dari Komputer fisik/VMware yang menggunakan arsitektur Klasik tidak mendukung penggunaan proksi autentikasi untuk mengontrol konektivitas jaringan. Hal yang sama didukung saat menggunakan arsitektur yang dimodernisasi.
Konektivitas keluar untuk URL
Jika Anda menggunakan proksi firewall berbasis URL untuk mengontrol konektivitas keluar, izinkan akses ke URL ini:
| Nama | Komersial | Pemerintah | Keterangan |
|---|---|---|---|
| Penyimpanan | *.blob.core.windows.net |
*.blob.core.usgovcloudapi.net |
Memungkinkan data ditulis dari VM ke akun penyimpanan cache di wilayah sumber data. |
| Microsoft Entra ID | login.microsoftonline.com |
login.microsoftonline.us |
Menyediakan otorisasi dan autentikasi ke URL layanan Site Recovery. |
| Replikasi | *.hypervrecoverymanager.windowsazure.com |
*.hypervrecoverymanager.windowsazure.us |
Memungkinkan VM untuk berkomunikasi dengan layanan Site Recovery. |
| Service Bus | *.servicebus.windows.net |
*.servicebus.usgovcloudapi.net |
Memungkinkan komputer virtual untuk menulis data pemantauan dan diagnostik Azure Site Recovery. |
Untuk daftar URL lengkap yang akan difilter untuk komunikasi antara infrastruktur Azure Site Recovery lokal dan layanan Azure, lihat bagian persyaratan jaringan di artikel prasyarat.
Proses replikasi
Saat Anda mengaktifkan replikasi untuk komputer virtual, replikasi awal ke penyimpanan Azure dimulai, menggunakan kebijakan replikasi yang ditentukan. Berikut hal-hal yang perlu diketahui:
- Untuk komputer virtual VMware, replikasi dilakukan di tingkat blok, hampir berkelanjutan, menggunakan agen servis Mobilitas yang berjalan pada komputer virtual.
- Pengaturan kebijakan replikasi apa pun diterapkan:
- Ambang RPO. Pengaturan ini tidak memengaruhi replikasi. Pengaturan ini membantu dengan pemantauan. Peristiwa dimunculkan, dan email dikirim secara opsional, jika RPO saat ini melebihi batas ambang yang Anda tentukan.
- Retensi titik pemulihan. Pengaturan ini menentukan seberapa jauh waktu yang Anda inginkan ketika terjadi gangguan. Retensi maksimum adalah 15 hari pada Disk terkelola.
- Rekam jepret yang konsisten dengan aplikasi. Rekam jepret yang konsisten dengan aplikasi dapat diambil setiap 1 hingga 12 jam, tergantung pada kebutuhan aplikasi Anda. Rekam jepret adalah rekam jepret blob Azure standar. Agen Mobilitas yang berjalan pada komputer virtual meminta rekam jepret VSS sesuai dengan pengaturan ini, dan memberi marka buku pada titik waktu itu sebagai titik konsisten aplikasi dalam aliran replikasi.
Catatan
Periode retensi titik pemulihan yang tinggi mungkin berimplikasi pada biaya penyimpanan karena lebih banyak titik pemulihan yang mungkin perlu disimpan.
Lalu lintas mereplikasi ke titik akhir umum penyimpanan Azure melalui internet. Atau, Anda dapat menggunakan Azure ExpressRoute dengan serekan Microsoft. Mereplikasi lalu lintas melalui jaringan privat maya (VPN) situs-ke-situs dari situs lokal ke Azure tidak didukung.
Operasi replikasi awal memastikan bahwa seluruh data pada komputer pada saat replikasi diaktifkan dikirim ke Azure. Setelah replikasi awal selesai, replikasi perubahan delta ke Azure dimulai. Perubahan terlacak untuk komputer dikirim ke server proses.
Komunikasi terjadi sebagai berikut:
- Komputer virtual berkomunikasi dengan server konfigurasi lokal pada port HTTPS 443 inbound, untuk pengelolaan replikasi.
- Server konfigurasi mengatur replikasi dengan Azure melalui port HTTPS 443 outbound.
- Komputer virtual mengirim data replikasi ke server proses (berjalan pada komputer server konfigurasi) pada port HTTPS 9443 masuk. Port ini bisa diubah.
- Server proses menerima data replikasi, mengoptimalkan, dan mengenkripsinya, dan mengirimkannya ke penyimpanan Azure melalui port 443 keluar.
Log data replikasi masuk terlebih dahulu di akun penyimpanan cache di Azure. Log ini diproses dan datanya disimpan di Azure Managed Disk (disebut sebagai disk nilai awal Azure Site Recovery). Titik pemulihan dibuat pada disk ini.
Proses sinkronisasi ulang
- Kadang-kadang, selama replikasi awal atau saat mentransfer perubahan delta, masalah konektivitas jaringan antara komputer sumber ke server proses atau antara server proses ke Azure bisa terjadi. Salah satu dari kemungkinan tersebut dapat menyebabkan kegagalan dalam transfer data ke Azure sesaat.
- Untuk menghindari masalah integritas data, dan meminimalkan biaya transfer data, Site Recovery menandai komputer untuk sinkronisasi ulang.
- Komputer juga dapat ditandai untuk sinkronisasi ulang dalam situasi seperti berikut ini untuk mempertahankan konsistensi antara komputer sumber dan data yang disimpan di Azure
- Jika komputer mengalami mati paksa
- Jika komputer mengalami perubahan konfigurasi seperti pengubahan ukuran disk (mengubah ukuran disk dari 2 TB menjadi 4 TB)
- Sinkronisasi ulang hanya mengirim data delta ke Azure. Transfer data antara server lokal dan Azure dilakukan dengan diminimalkan dengan menghitung checksum antara komputer sumber dan data yang disimpan di Azure.
- Secara default, sinkronisasi ulang dijadwalkan untuk berjalan secara otomatis di luar jam kantor. Jika Anda tidak ingin menunggu sinkronisasi ulang default di luar jam kerja, Anda dapat menjalankan sinkronisasi ulang komputer virtual secara manual. Untuk melakukan hal ini, masuk ke portal Microsoft Azure, pilih mesin virtual >Sinkronisasi ulang.
- Jika sinkronisasi ulang default gagal di luar jam kantor dan intervensi manual diperlukan, kesalahan akan dihasilkan pada komputer tertentu di portal Microsoft Azure. Anda dapat mengatasi kesalahan itu dan memicu sinkronisasi ulang secara manual.
- Setelah menyelesaikan sinkronisasi ulang, replikasi perubahan delta akan dilanjutkan.
Mengelola kebijakan replikasi
- Anda bisa menyesuaikan pengaturan kebijakan replikasi saat Anda mengaktifkan replikasi.
- Anda dapat membuat kebijakan replikasi kapan saja, lalu menerapkannya saat Anda mengaktifkan replikasi.
Konsistensi multi-VM
Jika Anda ingin komputer virtual direplikasi bersama-sama, dan telah berbagi titik pemulihan yang konsisten dengan crash dan konsisten dengan aplikasi pada failover, Anda dapat mengumpulkannya bersama-sama ke dalam sebuah grup replikasi. Konsistensi multi-komputer virtual memengaruhi performa beban kerja, dan hanya boleh digunakan untuk komputer virtual yang menjalankan beban kerja yang membutuhkan konsistensi di semua komputer.
Rekam jepret dan titik pemulihan
Titik pemulihan dibuat dari rekam jepret disk komputer virtual yang diambil pada titik waktu tertentu. Ketika Anda menjalankan failover pada komputer virtual, Anda menggunakan titik pemulihan untuk memulihkan komputer virtual di lokasi target.
Ketika menjalankan failover, secara umum kami ingin memastikan bahwa komputer virtual dimulai tanpa kerusakan atau kehilangan data, dan data komputer virtual konsisten untuk sistem operasi, dan untuk aplikasi yang berjalan di komputer virtual. Ini tergantung pada jenis rekam jepret yang diambil.
Azure Site Recovery mengambil rekam jepret sebagai berikut:
- Azure Site Recovery mengambil rekam jepret data yang konsisten dengan crash secara default, dan rekam jepret yang konsisten dengan aplikasi jika Anda menentukan frekuensi untuknya.
- Titik pemulihan dibuat dari rekam jepret, dan disimpan sesuai dengan pengaturan retensi dalam kebijakan replikasi.
Konsistensi
Tabel berikut ini menjelaskan berbagai jenis konsistensi.
Konsisten dengan crash
| Keterangan | Detail | Rekomendasi |
|---|---|---|
| Rekam jepret yang konsisten dengan crash menangkap data yang ada di disk saat rekam jepret diambil. Rekam jepret ini tidak termasuk apa pun dalam memori. Rekam jepret ini berisi data yang setara dengan data pada disk yang akan ada jika komputer virtual mengalami crash atau kabel daya ditarik dari server pada saat rekam jepret diambil. Konsisten dengan crash tidak menjamin konsistensi data untuk sistem operasi, atau untuk aplikasi di komputer virtual. |
Azure Site Recovery membuat titik pemulihan yang konsisten dengan crash setiap lima menit secara default. Pengaturan ini tidak bisa diubah. |
Saat ini, sebagian besar aplikasi dapat pulih dengan baik dari titik yang konsisten dengan crash. Titik pemulihan yang konsisten dengan crash biasanya cukup untuk replikasi sistem operasi, dan aplikasi seperti server DHCP dan server cetak. |
Konsisten dengan aplikasi
| Keterangan | Detail | Rekomendasi |
|---|---|---|
| Titik pemulihan yang konsisten dengan aplikasi dibuat dari rekam jepret yang konsisten dengan aplikasi. Rekam jepret yang konsisten dengan aplikasi berisi semua informasi dalam rekam jepret yang konsisten dengan crash, ditambah semua data dalam memori dan transaksi yang sedang berlangsung. |
Rekam jepret yang konsisten dengan aplikasi menggunakan Layanan Menyalin Bayangan Volume (VSS): 1) Azure Site Recovery menggunakan metode cadangan Salin Saja (VSS_BT_COPY) yang tidak mengubah waktu cadangan log dan nomor urutan 2 Microsoft SQL) Saat salinan bayangan dimulai, VSS melakukan operasi salin-saat-tulis (COW) pada volume. 3) Sebelum melakukan COW, VSS memberi tahu setiap aplikasi pada komputer bahwa perlu melakukan flush data residen RAM ke disk. 4) VSS kemudian mengizinkan aplikasi cadangan/pemulihan bencana (dalam kasus ini Site Recovery) untuk membaca data rekam jepret dan melanjutkan proses berikutnya. |
Rekam jepret yang konsisten dengan aplikasi diambil sesuai dengan frekuensi yang Anda tentukan. Frekuensi ini harus selalu kurang dari yang Anda tetapkan untuk mempertahankan titik pemulihan. Misalnya, jika Anda mempertahankan titik pemulihan menggunakan pengaturan default 24 jam, Anda harus mengatur frekuensi kurang dari 24 jam. Rekam jepret yang konsisten dengan aplikasi lebih kompleks dan membutuhkan waktu lebih lama untuk diselesaikan daripada rekam jepret yang konsisten dengan crash. Rekam jepret ini memengaruhi performa aplikasi yang berjalan pada komputer virtual yang diaktifkan untuk replikasi. |
Proses failover dan failback
Setelah replikasi disiapkan dan Anda menjalankan latihan pemulihan bencana (uji failover) untuk memeriksa bahwa semuanya berfungsi seperti yang diharapkan, Anda dapat menjalankan failover dan failback sesuai kebutuhan Anda.
Anda menjalankan failover untuk satu komputer, atau membuat rencana pemulihan untuk menjalankan failover pada beberapa komputer virtual secara bersamaan. Keuntungan dari rencana pemulihan daripada failover komputer tunggal termasuk:
- Anda dapat membuat model ketergantungan aplikasi dengan menyertakan semua komputer virtual di seluruh aplikasi dalam satu rencana pemulihan.
- Anda dapat menambahkan skrip, runbook Azure, dan menjeda tindakan manual.
Setelah memicu failover awal, Anda menerapkannya untuk mulai mengakses beban kerja dari komputer virtual Azure.
Ketika situs primer lokal Anda tersedia lagi, Anda dapat bersiap untuk menjalankan failback. Untuk menjalankan failback, Anda perlu menyiapkan infrastruktur failback, termasuk:
- Server proses sementara di Azure: Untuk melakukan failback dari Azure, Anda menyiapkan komputer virtual Azure untuk bertindak sebagai server proses untuk menangani replikasi dari Azure. Anda dapat menghapus komputer virtual ini setelah failback selesai.
- Koneksi VPN: Untuk menjalankan failback, Anda memerlukan koneksi VPN (atau ExpressRoute) dari jaringan Azure ke situs lokal.
- Server target master terpisah: Secara default, server target master yang diinstal dengan server konfigurasi pada komputer virtual VMware lokal menangani failback. Jika Anda perlu menjalankan failback lalu lintas dalam volume besar, siapkan server target master lokal terpisah untuk tujuan ini.
- Kebijakan failback: Untuk mereplikasi kembali ke situs lokal, Anda memerlukan kebijakan failback. Kebijakan ini secara otomatis dibuat saat Anda membuat kebijakan replikasi dari lokal ke Azure.
Setelah komponen berada di tempatnya, failback terjadi dalam tiga tindakan:
- Tahap 1: Proteksi ulang Azure VM sehingga mereka mereplikasi dari Azure kembali ke VMware VM lokal.
- Tahap 2: Jalankan failover ke situs lokal.
- Tahap 3: Setelah melakukan failback pada beban kerja, Anda dapat mengaktifkan kembali replikasi untuk komputer virtual lokal.
Langkah berikutnya
Ikuti tutorial ini untuk mengaktifkan replikasi VMware ke Azure.