Arsitektur pemulihan bencana server fisik ke Azure – Dimodernisasi
Artikel ini menjelaskan arsitektur dan proses modern yang digunakan saat Anda mereplikasi, failover, dan memulihkan server Windows dan Linux fisik antara situs lokal dan Azure, menggunakan layanan Azure Site Recovery .
Untuk informasi tentang persyaratan server konfigurasi dalam rilis Klasik, lihat Arsitektur pemulihan bencana Server fisik ke Azure.
Catatan
Pastikan Anda membuat vault Layanan Pemulihan baru untuk menyiapkan appliance replikasi ASR. Jangan gunakan vault yang sudah ada.
Komponen arsitektur
Tabel dan grafik berikut memberikan tampilan tingkat tinggi dari komponen yang digunakan untuk pemulihan bencana komputer fisik ke Azure.
| Komponen | Persyaratan | Rincian |
|---|---|---|
| Azure | Langganan Azure, akun Azure Storage untuk cache, Disk Terkelola, dan jaringan Azure. | Data yang direplikasi dari komputer 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. |
| Appliance replikasi Azure Site Recovery | Ini adalah blok bangunan dasar dari seluruh infrastruktur lokal Azure Site Recovery. Semua komponen dalam appliance berkoordinasi dengan appliance replikasi. Layanan ini mengawasi semua kegiatan Site Recovery end-to-end termasuk memantau kesehatan mesin yang dilindungi, replikasi data, pembaruan otomatis, dll. |
Appliance ini menghosting berbagai komponen penting seperti: Server proksi: Komponen ini bertindak sebagai saluran proksi antara agen mobilitas dan layanan Site Recovery di cloud. Ini memastikan tidak ada konektivitas internet tambahan yang diperlukan dari beban kerja produksi untuk menghasilkan titik pemulihan. Item yang ditemukan: Komponen ini mengumpulkan informasi vCenter Server dan berkoordinasi dengan layanan manajemen Azure Site Recovery di cloud. Server perlindungan ulang: Komponen ini berkoordinasi antara Azure dan mesin lokal selama operasi reprotect dan failback. Server proses: Komponen ini digunakan untuk penembolokan, pemadatan data sebelum dikirim ke Azure. Pelajari selengkapnya tentang appliance replikasi dan cara menggunakan beberapa appliance replikasi. Agen Layanan Pemulihan: Komponen ini digunakan untuk mengonfigurasi/mendaftar dengan layanan Site Recovery, dan untuk memantau kesehatan semua komponen. Penyedia Pemulihan Situs: Komponen ini digunakan untuk memfasilitasi perlindungan kembali. Ini mengidentifikasi antara lokasi alternatif yang dilindungi ulang dan lokasi asli yang dilindungi kembali untuk mesin sumber. Layanan replikasi: Komponen ini digunakan untuk mereplikasi data dari lokasi sumber ke Azure. |
| Komputer yang direplikasi | Layanan Mobilitas diinstal pada setiap server fisik yang Anda replikasi. | Kami menyarankan Anda mengizinkan instalasi otomatis Layanan Mobilitas. Atau, Anda dapat menginstal layanan secara manual. |
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 tidak mendukung penggunaan autentikasi proksi untuk mengontrol konektivitas jaringan.
Konektivitas keluar untuk URL
Jika Anda menggunakan proksi firewall berbasis URL untuk mengontrol konektivitas keluar, izinkan akses ke URL ini:
| URL | Rincian |
|---|---|
| portal.azure.com | Arahkan ke portal Microsoft Azure. |
*.windows.net *.msftauth.net*.msauth.net*.microsoft.com*.live.com *.office.com |
Untuk masuk ke langganan Azure Anda. |
*.microsoftonline.com |
Buat aplikasi Microsoft Entra untuk appliance untuk berkomunikasi dengan Azure Site Recovery. |
| management.azure.com | Buat aplikasi Microsoft Entra untuk appliance untuk berkomunikasi dengan layanan Azure Site Recovery. |
*.services.visualstudio.com |
Menggunggah log aplikasi yang digunakan untuk pemantauan internal. |
*.vault.azure.net |
Kelola rahasia di Azure Key Vault. Catatan: Pastikan server yang ingin mereplikasi memiliki akses ke sini. |
| aka.ms | Izinkan akses ke tautan aka.ms. Digunakan untuk pembaruan appliance Azure Site Recovery. |
| download.microsoft.com/download | Mengizinkan pengunduhan dari unduhan Microsoft. |
*.servicebus.windows.net |
Komunikasi antara peralatan dan layanan Azure Site Recovery. |
*.discoverysrv.windowsazure.com |
Menghubungkan ke URL layanan penemuan Azure Site Recovery. |
*.hypervrecoverymanager.windowsazure.com |
Menghubungkan ke URL layanan mikro Azure Site Recovery |
*.blob.core.windows.net |
Menghubungkan data ke penyimpanan Azure yang digunakan untuk membuat disk target |
*.backup.windowsazure.com |
URL layanan perlindungan – layanan mikro yang digunakan oleh Azure Site Recovery untuk memproses dan membuat disk yang direplikasi di Azure |
Proses replikasi
Saat Anda mengaktifkan replikasi untuk sistem, replikasi awal ke penyimpanan Azure dimulai, menggunakan kebijakan replikasi yang ditentukan. Berikut hal-hal yang perlu diketahui:
- Untuk komputer fisik, replikasi tingkat blok, hampir berkelanjutan, menggunakan agen layanan Mobilitas yang berjalan pada sistem.
- 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.
- 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 fisik meminta rekam jepret VSS sesuai dengan pengaturan ini, dan bookmark yang tepat waktu 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 berkomunikasi dengan appliance lokal pada port HTTPS 443 masuk, untuk manajemen replikasi.
- Appliance mengatur replikasi dengan Azure melalui port HTTPS 443 outbound.
- Komputer mengirim data replikasi ke server proses 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 data disimpan di Disk Terkelola Azure (disebut sebagai asrseeddisk). Titik pemulihan dibuat pada disk ini.
Proses failover dan failback
Setelah Anda menyiapkan replikasi dan menjalankan latihan pemulihan bencana (uji failover) untuk memeriksa bahwa semuanya berfungsi seperti yang diharapkan, Anda dapat menjalankan melanjutkan ke failover sesuai kebutuhan.
Catatan
Untuk server fisik, failback tidak didukung
- Anda dapat menjalankan failover untuk satu komputer atau membuat rencana pemulihan untuk failover beberapa server secara bersamaan. Keuntungan dari rencana pemulihan daripada failover komputer tunggal meliputi:
- Anda dapat memodelkan dependensi aplikasi dengan menyertakan semua server 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.
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 mesin mengalami pematian 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 menyinkronkan ulang sistem secara manual. Untuk melakukan ini, buka portal Azure, pilih Komputer >fisik Sinkronkan 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.
Kebijakan replikasi
Saat Anda mengaktifkan replikasi komputer virtual Azure, Site Recovery membuat kebijakan replikasi baru secara default dengan pengaturan default yang diringkas dalam tabel.
| Pengaturan kebijakan | Rincian | Default |
|---|---|---|
| Retensi titik pemulihan | Menentukan berapa lama Azure Site Recovery mempertahankan titik pemulihan | 1 hari |
| Frekuensi rekam jepret yang konsisten dengan aplikasi | Seberapa sering Site Recovery mengambil rekam jepret yang konsisten dengan aplikasi | Nonaktif |
Snapshot dan titik pemulihan
Titik pemulihan dibuat dari rekam jepret disk komputer yang diambil pada titik waktu tertentu. Saat Anda melakukan failover pada sistem, Anda menggunakan titik pemulihan untuk memulihkan komputer fisik sebagai VM 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 | Rincian | 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. Ini berisi setara dengan data pada disk yang akan ada jika sistem mengalami crash atau kabel daya ditarik dari server pada saat rekam jepret diambil. Crash-consistent tidak menjamin konsistensi data untuk sistem operasi, atau untuk aplikasi pada komputer. |
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 | Rincian | 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. Ini memengaruhi performa aplikasi yang berjalan pada sistem yang diaktifkan untuk replikasi. |
Langkah berikutnya
Ikuti tutorial ini untuk mengaktifkan komputer fisik dan VMware ke replikasi Azure.