Memulihkan bencana untuk mesin virtual Azure Stack Hub

Artikel ini menjelaskan arsitektur dan pertimbangan desain solusi yang memberikan pendekatan yang dioptimalkan untuk pemulihan bencana beban kerja yang berjalan pada komputer virtual (VM) yang dihosting di Azure Stack Hub.

Sistem

Unduh file Visio arsitektur ini.

Alur kerja

Komponen cloud dari solusi yang diusulkan mencakup layanan berikut:

• Langganan Azure yang menghosting semua sumber daya cloud yang merupakan bagian dari solusi ini.

• Penyewa ID Microsoft Entra yang terkait dengan langganan Azure yang menyediakan autentikasi prinsip keamanan Microsoft Entra untuk mengotorisasi akses ke sumber daya Azure.

• Vault Azure Recovery Services di wilayah Azure yang paling dekat dengan pusat data lokal yang menghosting penyebaran Azure Stack Hub.

  Catatan

  Pilihan wilayah Azure yang paling dekat dengan pusat data lokal khusus untuk skenario sampel yang disertakan dalam artikel ini. Dari sudut siaga pemulihan bencana, lebih baik memilih wilayah Azure yang lebih jauh dari lokasi yang menghosting lingkungan produksi. Namun, keputusan dapat bergantung pada faktor lain, seperti kebutuhan untuk meminimalkan latensi umpan data regional atau untuk memenuhi persyaratan residensi data.

• Sirkuit Azure ExpressRoute yang menghubungkan pusat data lokal ke wilayah Azure yang menghosting vault Azure Recovery Services, dikonfigurasi dengan peering privat dan peering Microsoft. Yang pertama memastikan bahwa persyaratan latensi terpenuhi setelah failover. Tujuan yang terakhir adalah untuk meminimalkan jumlah waktu yang diperlukan untuk mereplikasi perubahan antara beban kerja lokal dan situs failover di Azure.

• Akun Azure Storage yang menyimpan blob yang berisi file VHD yang dibuat oleh replikasi sistem operasi dan volume data VM Azure Stack Hub yang dilindungi. File VHD ini berfungsi sebagai sumber untuk disk terkelola Azure VM yang secara otomatis disediakan setelah failover.

• Jaringan virtual Azure yang menghosting lingkungan pemulihan bencana. Ini dikonfigurasi dengan cara yang mencerminkan lingkungan jaringan virtual di Azure Stack Hub yang menghosting beban kerja produksi, termasuk komponen seperti load balancer dan kelompok keamanan jaringan. Jaringan virtual ini biasanya tersambung ke jaringan virtual Azure Stack Hub melalui koneksi ExpressRoute untuk memfasilitasi pemulihan tingkat beban kerja.

  Catatan

  Terkadang koneksi VPN situs-ke-situs cukup dalam skenario di mana persyaratan Tujuan Titik Pemulihan (RPO) kurang ketat.

• Jaringan virtual Azure terisolasi yang ditujukan untuk pengujian failover, dikonfigurasi dengan cara yang mencerminkan lingkungan jaringan virtual di Azure Stack Hub yang menghosting beban kerja produksi, termasuk komponen seperti load balancer dan kelompok keamanan jaringan.

Komponen lokal dari solusi yang diusulkan mencakup layanan berikut:

• Sistem terintegrasi Azure Stack Hub dalam model penyebaran yang terhubung. Sistem menjalankan pembaruan saat ini (2002 per 9/20) dan berada di pusat data lokal pelanggan.

• Langganan Azure Stack Hub dan jaringan virtual, atau beberapa jaringan virtual yang di-peering, yang menghosting semua VM lokal untuk solusi ini.

• Konfigurasi Azure Site Recovery dan server proses yang berjalan pada VM Azure Hub Stack Windows Server 2016 atau 2012 R2. Server mengelola komunikasi dengan vault Azure Recovery Services, dan perutean, pengoptimalan, dan enkripsi lalu lintas replikasi.

  Catatan

  Secara default, server konfigurasi menghosting server proses tunggal. Anda dapat menyebarkan server proses khusus untuk mengakomodasi volume lalu lintas replikasi yang lebih besar.

• VM Azure Stack Hub yang akan dilindungi. Mereka menjalankan versi sistem operasi Windows Server, CentOS, dan Ubuntu yang didukung.

• Layanan Mobilitas Site Recovery (juga disebut sebagai agen mobilitas) yang berjalan pada VM yang dilindungi. Ini melacak perubahan pada disk lokal, merekam perubahan log replikasi, dan mereplikasi log ke server proses. Server proses merutekannya ke akun penyimpanan Azure target. Log digunakan untuk membuat titik pemulihan untuk disk terkelola yang diimplementasikan dengan menggunakan blob yang disimpan di akun penyimpanan Azure yang Anda tetapkan.

Komponen

• Microsoft Entra ID
• Microsoft Azure Virtual Network
• Layanan Pemulihan Azure
• Azure ExpressRoute
• Penyimpanan Blob Azure
• Azure Stack Hub

Alternatif

Solusi yang direkomendasikan yang dijelaskan dalam artikel ini bukan satu-satunya cara untuk menyediakan fungsionalitas pemulihan bencana untuk beban kerja berbasis VM Azure Stack Hub. Pelanggan memiliki opsi lain, termasuk:

• Failover untuk stempel Azure Stack Hub lainnya. Pengguna yang perlu melindungi dari pusat data atau penonaktifan situs mungkin dapat menggunakan penyebaran Azure Stack Hub lain untuk menerapkan ketentuan pemulihan bencana. Dengan lokasi utama dan sekunder, pengguna dapat menyebarkan aplikasi dalam konfigurasi aktif/pasif di dua lingkungan. Untuk beban kerja yang kurang penting, mungkin dapat diterima untuk menggunakan kapasitas yang tidak digunakan di lokasi sekunder untuk melakukan pemulihan aplikasi sesuai permintaan dari cadangan. Anda juga dapat menerapkan situs pemulihan di pusat data lain, yang, pada gilirannya, menggunakan Site Recovery untuk menyediakan replika situs pemulihan di Azure. Beberapa faktor menentukan apakah penggunaan Site Recovery dengan Azure berfungsi sebagai situs failover adalah solusi yang layak. Faktor-faktor ini termasuk peraturan pemerintah, kebijakan perusahaan, dan persyaratan latensi.

  Catatan

  Mulai Juli 2020, Site Recovery tidak mendukung skenario ini, yang berarti bahwa implementasi harus menggunakan solusi mitra atau internal.

• Cadangkan dan pulihkan. Mencadangkan aplikasi dan himpunan data memungkinkan Anda untuk pulih dengan cepat dari waktu henti yang dihasilkan dari kerusakan data, penghapusan yang tidak disengaja, atau pemadaman yang dilokalkan. Untuk aplikasi berbasis Azure Stack Hub VM, Anda dapat menggunakan agen dalam tamu untuk melindungi data aplikasi, konfigurasi sistem operasi, dan data yang disimpan pada volume. Mencadangkan VM dengan menggunakan agen OS tamu biasanya mencakup pengambilan konfigurasi sistem operasi, file, folder, volume, biner aplikasi, dan data aplikasi. Memulihkan aplikasi dari agen memerlukan rekreasi VM, diikuti dengan penginstalan sistem operasi dan agen tamu. Pada saat itu, Anda dapat memulihkan data ke OS tamu.

• Cadangan snapshot disk. Dimungkinkan untuk menggunakan rekam jepret untuk mengambil konfigurasi VM Azure Stack Hub dan disk yang dilampirkan ke VM yang dihentikan. Proses ini memerlukan produk cadangan yang terintegrasi dengan API Azure Stack Hub untuk mengambil konfigurasi VM dan membuat rekam jepret disk.

  Catatan

  Mulai Juli 2020, menggunakan rekam jepret disk untuk VM yang sedang berjalan tidak didukung. Membuat rekam jepret disk yang dilampirkan ke VM yang sedang berjalan dapat menurunkan performa atau memengaruhi ketersediaan sistem operasi atau aplikasi di VM.

• Cadangkan dan pulihkan VM dengan menggunakan solusi cadangan eksternal di pusat data yang sama, lalu replikasi cadangan ke lokasi lain. Dengan cara ini, Anda dapat memulihkan VM Azure Stack Hub ke instans Azure Stack Hub yang sama, atau ke yang berbeda, atau ke Azure.

Detail skenario

Azure Stack Hub mencakup fungsionalitas penyembuhan mandiri, menyediakan remediasi otomatis dalam berbagai skenario yang melibatkan kegagalan komponen yang dilokalkan. Namun, kegagalan skala besar, termasuk pemadaman yang memengaruhi rak server atau bencana tingkat situs, memerlukan pertimbangan tambahan. Pertimbangan ini harus menjadi bagian dari keberlangsungan bisnis dan strategi pemulihan bencana untuk beban kerja pengguna berbasis VM. Strategi ini juga harus memperhitungkan pemulihan infrastruktur Azure Stack, yang terpisah dari pemulihan beban kerja.

Solusi pemulihan beban kerja lokal tradisional rumit untuk dikonfigurasi, mahal, dan padat karya untuk dipertahankan, dan sulit diotomatiskan, terutama ketika Anda menggunakan lokasi lokal lain sebagai situs failover. Microsoft merekomendasikan solusi alternatif yang bergantung pada kombinasi komponen cloud dan lokal untuk memberikan cara yang tangguh, berbasis performa, sangat otomatis, dan mudah untuk menerapkan, mengamankan, dan mengelola strategi pemulihan bencana yang hemat biaya. Elemen inti dari solusi ini adalah Site Recovery, dengan situs failover berada di Azure.

Kemungkinan kasus penggunaan

Site Recovery dengan Azure sebagai situs failover menghilangkan semua kelemahan yang disebutkan di atas. Anda dapat menggunakan kemampuannya untuk melindungi server fisik dan virtual, termasuk yang berjalan di platform virtualisasi Microsoft Hyper-V atau VMware ESXi. Anda juga dapat menggunakan kemampuan yang sama untuk memfasilitasi pemulihan beban kerja yang berjalan di VM Azure Stack Hub.

Fungsi inti

Site Recovery adalah solusi pemulihan bencana yang memfasilitasi perlindungan komputer fisik dan virtual dengan menyediakan dua set fitur:

• Replikasi perubahan pada disk komputer yang berada di antara lokasi produksi dan pemulihan bencana
• Orkestrasi failover dan failback antara dua lokasi ini

Site Recovery menawarkan tiga jenis failover:

• Uji failover. Failover ini memberi Anda kesempatan untuk memvalidasi konfigurasi Site Recovery Anda di lingkungan yang terisolasi, tanpa kehilangan atau dampak data ke lingkungan produksi.
• Kegagalan terencana. Failover ini memberi Anda opsi untuk memulai pemulihan bencana tanpa kehilangan data, biasanya sebagai bagian dari waktu henti yang direncanakan.
• Kegagalan tidak terencana. Failover ini berfungsi sebagai upaya terakhir jika terjadi penonaktifan yang tidak direncanakan yang memengaruhi ketersediaan situs utama dan berpotensi mengakibatkan hilangnya data.

Site Recovery mendukung beberapa skenario, seperti failover dan failback antara dua situs lokal, failover dan failback antara dua wilayah Azure, dan migrasi dari cloud penyedia pihak ketiga. Namun, dalam konteks artikel ini, fokusnya adalah pada replikasi disk lokal VM Azure Stack Hub ke Azure Storage, dan pada failover VM dan failback antara tumpukan Azure Stack Hub dan wilayah Azure.

Detail arsitektur Site Recovery dan komponennya bergantung pada sejumlah kriteria, termasuk:

• Jenis komputer yang akan dilindungi (fisik versus virtual).
• Untuk lingkungan virtual, jenis hypervisor yang menghosting mesin virtual harus dilindungi (Hyper-V versus VMware ESXi).
• Untuk lingkungan Hyper-V, penggunaan System Center Virtual Machine Manager (SCVMM) untuk pengelolaan host Hyper-V.

Dengan Azure Stack Hub, arsitekturnya cocok dengan arsitektur yang berlaku untuk komputer fisik. Ini tidak terlalu mengejutkan, karena dalam kedua kasus, Site Recovery tidak dapat memperoleh manfaat dari akses langsung ke hypervisor. Sebaliknya, mekanisme yang melacak dan mereplikasi perubahan ke disk lokal diterapkan dalam sistem operasi yang dilindungi.

Untuk mencapai hal ini, Site Recovery bergantung pada layanan Mobilitas Site Recovery (juga disebut sebagai agen mobilitas), yang secara otomatis disebarkan ke masing-masing VM saat Anda mendaftarkannya ke dalam cakupan perlindungan berbasis Site Recovery. Pada setiap VM yang dilindungi, instans agen mobilitas yang diinstal secara lokal secara terus-menerus memantau dan meneruskan perubahan ke sistem operasi dan disk data ke server proses. Namun, untuk mengoptimalkan dan mengelola arus lalu lintas replikasi yang berasal dari VM yang dilindungi, Site Recovery menerapkan serangkaian komponen tambahan yang berjalan pada VM terpisah, yang disebut sebagai server konfigurasi.

Server konfigurasi mengoordinasikan komunikasi dengan vault Site Recovery dan mengelola replikasi data. Selain itu, server konfigurasi menghosting komponen yang disebut sebagai server proses, yang bertindak sebagai gateway, menerima data replikasi, mengoptimalkannya melalui penembolokan dan kompresi, mengenkripsinya, dan akhirnya meneruskannya ke Azure Storage. Secara efektif, server konfigurasi berfungsi sebagai titik integrasi antara Site Recovery dan VM yang dilindungi yang berjalan di Azure Stack Hub. Anda menerapkan integrasi tersebut dengan menyebarkan server konfigurasi dan mendaftarkannya ke brankas Azure Recovery Services.

Sebagai bagian dari konfigurasi Site Recovery, Anda menentukan lingkungan pemulihan bencana yang dimaksudkan, termasuk komponen infrastruktur seperti jaringan virtual, load balancer, atau kelompok keamanan jaringan dengan cara yang mencerminkan lingkungan produksi. Konfigurasi juga mencakup kebijakan replikasi, yang menentukan kemampuan pemulihan dan terdiri dari parameter berikut:

• Ambang RPO. Pengaturan ini mewakili tujuan titik pemulihan yang diinginkan yang ingin Anda terapkan dan menentukan frekuensi Site Recovery menghasilkan rekam jepret titik pemulihan yang konsisten dengan crash. Nilainya tidak memengaruhi frekuensi replikasi karena replikasi tersebut berlangsung terus menerus. Site Recovery akan menghasilkan pemberitahuan, dan secara opsional, pemberitahuan email, jika RPO efektif saat ini yang disediakan oleh Site Recovery melebihi ambang yang Anda tentukan. Site Recovery menghasilkan rekam jepret titik pemulihan yang konsisten dengan crash setiap lima menit.

  Catatan

  Rekam jepret yang konsisten dengan crash menangkap data yang ada di disk saat rekam jepret diambil. Ini tidak termasuk konten memori. Secara efektif, snapshot yang konsisten dengan crash tidak menjamin konsistensi data untuk sistem operasi atau aplikasi yang diinstal secara lokal.

• Retensi titik pemulihan. Pengaturan ini mewakili durasi (dalam jam) dari jangka waktu retensi untuk setiap snapshot titik pemulihan. VM yang dilindungi dapat dipulihkan ke titik pemulihan mana pun dalam jangka waktu retensi. Site Recovery mendukung retensi hingga 24 jam untuk VM yang direplikasi ke akun Azure Storage dengan tingkat performa premium. Ada batas retensi 72 jam saat menggunakan akun Azure Storage dengan tingkat performa standar.

• Frekuensi snapshot yang konsisten dengan aplikasi. Pengaturan ini menentukan frekuensi (dalam jam) di mana Site Recovery menghasilkan rekam jepret yang konsisten dengan aplikasi. Snapshot yang konsisten dengan aplikasi mewakili snapshot point-in-time dari aplikasi yang berjalan di VM yang dilindungi. Ada batas 12 rekam jepret yang konsisten dengan aplikasi. Untuk VM yang menjalankan Windows Server, Site Recovery menggunakan Layanan Salinan Bayangan Volume (VSS). Site Recovery juga mendukung rekam jepret yang konsisten dengan aplikasi untuk Linux, tetapi memerlukan penerapan skrip kustom. Skrip digunakan oleh agen mobilitas saat menerapkan snapshot yang konsisten dengan aplikasi.

  Catatan

  Untuk detail mengenai penerapan rekam jepret yang konsisten dengan aplikasi di VM Azure Stack Hub yang menjalankan Linux, lihat Pertanyaan umum tentang Site Recovery.

Untuk setiap disk VM Azure Stack Hub yang dilindungi yang Anda tentukan, data direplikasi ke disk terkelola yang sesuai di Azure Storage. Disk menyimpan salinan disk sumber dan semua snapshot yang konsisten dengan aplikasi dan konsisten dengan crash titik pemulihan. Sebagai bagian dari failover, Anda memilih snapshot yang konsisten dengan aplikasi dan konsisten dengan crash titik pemulihan yang harus digunakan saat melampirkan disk terkelola ke Azure VM, yang berfungsi sebagai replika Azure Stack Hub VM yang dilindungi.

Selama operasi bisnis reguler, beban kerja yang dilindungi berjalan di Azure Stack Hub VM, dengan perubahan pada disk yang terus direplikasi melalui interaksi antara agen mobilitas, server proses, dan server konfigurasi ke akun Azure Storage yang ditentukan. Saat Anda memulai pengujian, rencana, atau failover yang tidak direncanakan, Site Recovery secara otomatis memprovisikan Azure VM menggunakan replika disk VM Azure Stack Hub yang sesuai.

Anda memiliki opsi untuk mengatur failover dengan membuat rencana pemulihan yang berisi langkah-langkah manual dan otomatis. Untuk menerapkan yang terakhir, Anda dapat menggunakan runbook Azure Automation, yang terdiri dari skrip PowerShell kustom, alur kerja PowerShell, atau skrip Python 2.

Setelah situs utama tersedia lagi, Site Recovery mendukung pembalikan arah replikasi, memungkinkan Anda melakukan failback dengan waktu henti yang diminimalkan dan tanpa kehilangan data. Namun, dengan Azure Stack Hub, pendekatan ini tidak tersedia. Sebagai gantinya, untuk gagal kembali, Anda perlu mengunduh file disk Azure VM, mengunggahnya ke Azure Stack Hub, dan melampirkannya ke VM yang ada atau baru.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Keandalan

Keandalan memastikan bahwa aplikasi Anda dapat memenuhi komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keandalan.

Azure Stack Hub membantu meningkatkan ketersediaan beban kerja melalui ketahanan yang melekat pada infrastrukturnya. Ketahanan ini memberikan ketersediaan tinggi untuk VM Azure Stack Hub yang dilindungi oleh Site Recovery dan komponen penting dari infrastruktur Site Recovery lokal, termasuk konfigurasi dan server proses.

Demikian pula, Anda memiliki opsi untuk menggunakan ketahanan komponen berbasis cloud infrastruktur Site Recovery. Secara default, Azure Recovery Services bersifat geo-redundan, yang berarti konfigurasinya secara otomatis direplikasi ke wilayah Azure yang merupakan bagian dari pasangan wilayah yang telah ditentukan sebelumnya. Anda memiliki opsi untuk mengubah pengaturan replikasi menjadi redundan secara lokal jika itu cukup untuk kebutuhan ketahanan Anda. Perhatikan bahwa Anda tidak dapat mengubah opsi ini jika brankas berisi item yang dilindungi. Opsi ketahanan yang sama tersedia untuk semua akun Azure Storage dengan tingkat performa standar, meskipun dimungkinkan untuk mengubahnya kapan saja.

Anda dapat lebih meningkatkan tingkat ketahanan ini dengan merancang dan menerapkan solusi yang memperluas cakupan perlindungan beban kerja. Ini adalah nilai tambah yang disediakan oleh Site Recovery. Dalam konteks Site Recovery yang berjalan di Azure Stack Hub, ada dua aspek utama ketersediaan beban kerja yang perlu dieksplorasi secara lebih rinci:

• Failover ke Azure
• Failback ke Azure Stack Hub

Anda perlu mempertimbangkan keduanya saat mengembangkan strategi pemulihan bencana yang didorong oleh tujuan titik pemulihan (RPO) dan tujuan waktu pemulihan (RTO). RTO dan RPO mewakili persyaratan kontinuitas yang ditetapkan oleh fungsi bisnis individu dalam suatu organisasi. RPO menunjukkan periode waktu yang mewakili kehilangan data maksimum yang dapat diterima setelah insiden yang memengaruhi ketersediaan data tersebut. RTO menentukan durasi waktu maksimum yang dapat diterima yang diperlukan untuk memulihkan fungsi bisnis setelah insiden yang memengaruhi ketersediaan fungsi ini.

Failover ke Azure

Failover ke Azure adalah inti pertimbangan ketersediaan dalam konteks perlindungan berbasis Site Recovery dari VM Azure Stack Hub. Untuk memaksimalkan ketersediaan beban kerja, strategi failover harus menjawab kebutuhan untuk meminimalkan potensi kehilangan data (RPO) dan meminimalkan waktu failover (RTO).

Untuk meminimalkan potensi kehilangan data, Anda dapat mempertimbangkan:

• Memaksimalkan throughput dan meminimalkan latensi lalu lintas replikasi dengan mengikuti pertimbangan skalabilitas dan performa. Untuk informasi selengkapnya, lihat bagian berikutnya dari artikel ini.
• Meningkatkan frekuensi titik pemulihan yang konsisten dengan aplikasi untuk beban kerja database (hingga maksimum satu titik pemulihan per jam). Titik pemulihan yang konsisten dengan aplikasi dibuat dari rekam jepret yang konsisten dengan aplikasi. Snapshot yang konsisten dengan aplikasi mengambil data aplikasi pada disk dan memori. Meskipun pendekatan ini meminimalkan potensi kehilangan data, pendekatan ini memiliki satu kelemahan utama. Snapshot yang konsisten aplikasi memerlukan penggunaan Layanan Menyalin Bayangan Volume di Windows atau skrip kustom di Linux, untuk menghentikan aplikasi yang diinstal secara lokal. Proses penangkapan dapat merusak performa, terutama jika pemanfaatan sumber daya tinggi. Kami tidak menyarankan Anda menggunakan frekuensi rendah untuk rekam jepret yang konsisten dengan aplikasi untuk beban kerja non-database.

Metode utama untuk meminimalkan waktu failover melibatkan penggunaan rencana pemulihan Site Recovery. Rencana pemulihan mengatur failover antara situs primer dan sekunder, menentukan urutan kegagalan server yang dilindungi. Anda dapat menyesuaikan rencana dengan menambahkan instruksi manual dan tugas otomatis. Tujuannya adalah untuk membuat prosesnya konsisten, akurat, berulang, dan otomatis.

Saat membuat rencana pemulihan, Anda menetapkan server yang dilindungi ke grup pemulihan untuk tujuan failover. Server di setiap grup memindahkan bersama. Ini membantu Anda untuk membagi proses failover menjadi lebih kecil, lebih mudah untuk mengelola unit, mewakili kumpulan server yang dapat memindahkan tanpa bergantung pada dependensi eksternal.

Untuk meminimalkan waktu failover, sebagai bagian dari pembuatan rencana pemulihan, Anda harus:

• Menentukan grup Azure Stack Hub VM yang harus memindahkan bersama.
• Menentukan dependensi antara grup Azure Stack Hub VM untuk menentukan urutan failover yang optimal.
• Mengotomatiskan tugas failover, jika memungkinkan.
• Sertakan tindakan manual kustom, jika diperlukan.

Anda menentukan rencana pemulihan dan membuat grup pemulihan untuk mengambil properti khusus aplikasi. Sebagai contoh, mari kita pertimbangkan aplikasi tiga tingkat tradisional dengan back end berbasis SQL Server, komponen middleware, dan ujung depan web. Saat membuat rencana pemulihan, Anda dapat mengontrol urutan startup server di setiap tingkatan, dengan server yang menjalankan instans SQL Server menjadi online terlebih dahulu, diikuti oleh server di tingkat middleware, dan bergabung setelahnya oleh server yang menghosting front end web. Urutan ini memastikan bahwa aplikasi berfungsi pada saat server terakhir dimulai. Untuk menerapkannya, Anda cukup membuat rencana pemulihan dengan tiga grup pemulihan, yang berisi server di tingkat masing-masing.

Selain mengontrol failover dan urutan pengaktifan, Anda juga memiliki opsi untuk menambahkan tindakan ke rencana pemulihan. Secara umum, ada dua jenis tindakan:

• Otomatis. Tindakan ini didasarkan pada runbook Azure Automation, yang melibatkan salah satu dari dua jenis tugas:
  • Memprovisi dan mengonfigurasi sumber daya Azure, termasuk, misalnya, membuat alamat IP publik dan mengaitkannya dengan antarmuka jaringan yang dilampirkan ke Azure VM.
  • Mengubah konfigurasi sistem operasi dan aplikasi yang berjalan dalam Azure VM yang tersedia setelah failover.
• Manual. Tindakan ini tidak mendukung automasi dan disertakan dalam rencana pemulihan terutama untuk tujuan dokumentasi.

Failback ke Azure Stack Hub

Dalam skenario berbasis Site Recovery, failback, jika diimplementasikan dengan benar, tidak melibatkan kehilangan data. Artinya, fokus dari strategi failover adalah meminimalkan waktu failback (RTO). Namun, seperti yang disebutkan sebelumnya, ketika gagal kembali ke Azure Stack Hub, Anda tidak dapat mengandalkan rencana pemulihan Anda. Sebaliknya, failback melibatkan urutan langkah-langkah berikut:

1. Hentikan dan batalkan alokasi Azure VM di lingkungan pemulihan bencana.
2. Identifikasi parameter URI dari setiap disk terkelola yang dilampirkan ke VM yang ingin Anda unduh.
3. Unduh file hard disk virtual (VHD) yang diidentifikasi oleh parameter URI yang Anda identifikasi di langkah sebelumnya ke lingkungan lokal Anda.
4. Unggah file VHD ke Azure Stack Hub.
5. Lampirkan VHD yang diunggah ke Azure Stack Hub VM baru atau yang sudah ada.
6. Mulai Azure Stack Hub VM.

Pendekatan optimal untuk meminimalkan waktu failback adalah mengotomatiskannya.

Pertimbangan khusus beban kerja

Site Recovery terintegrasi dengan aplikasi dan peran berbasis Windows Server, termasuk SharePoint, Exchange, SQL Server, dan Active Directory Domain Services (AD DS). Ini memungkinkan Anda menggunakan kemampuan berikut untuk menerapkan perlindungan dan pemulihan tingkat aplikasi:

• Integrasi dengan teknologi replikasi tingkat aplikasi, seperti Grup Ketersediaan AlwaysOn SQL Server, Grup Ketersediaan Database Exchange (DAG), dan replikasi AD DS
• Snapshot yang konsisten dengan aplikasi, untuk aplikasi tingkat tunggal atau ganda
• Pustaka automasi beragam yang menyediakan skrip khusus aplikasi siap produksi yang dapat diunduh dan diintegrasikan dengan rencana pemulihan

Atau, Anda memiliki opsi untuk menggunakan mekanisme replikasi khusus beban kerja guna memberikan ketahanan tingkat situs. Ini adalah opsi yang umum digunakan saat menerapkan pemulihan bencana untuk pengontrol domain AD DS, SQL Server, atau Exchange, yang semuanya mendukung replikasi. Meskipun ini memerlukan penyediaan Azure VM yang menghosting beban kerja ini di lingkungan pemulihan bencana, yang meningkatkan biaya, ia menawarkan manfaat berikut:

• Mengurangi waktu yang dibutuhkan untuk failover dan failback
• Menyederhanakan failover tingkat beban kerja, mengakomodasi skenario yang failover tingkat situsnya tidak diperlukan

Keamanan

Mengelola pemulihan bencana beban kerja berbasis VM pengguna dalam skenario hibrida memerlukan pertimbangan keamanan tambahan. Pertimbangan ini dapat dikelompokkan dalam kategori berikut:

• Enkripsi saat transit. Ini termasuk komunikasi antara VM Azure Stack Hub yang dilindungi, komponen Site Recovery lokal, dan komponen Site Recovery berbasis cloud:

  • Agen mobilitas yang diinstal pada VM yang dilindungi selalu berkomunikasi dengan server proses melalui Keamanan Lapisan Transportasi (TLS) 1.2.
  • Dimungkinkan untuk komunikasi dari server konfigurasi ke Azure dan dari server proses ke Azure untuk menggunakan TLS 1.1 atau 1.0. Untuk meningkatkan tingkat keamanan konektivitas hibrida, Anda harus mempertimbangkan untuk memberlakukan penggunaan TLS 1.2.

  Catatan

  Untuk detail tentang mengonfigurasi enkripsi berbasis TLS 1.2, lihat Pengaturan registri Keamanan Lapisan Transportasi (TLS) dan Perbarui untuk mengaktifkan TLS 1.1 dan TLS 1.2 sebagai protokol aman default di WinHTTP di Windows

• Enkripsi saat tidak aktif. Ini termasuk Azure Storage dan Azure VM di situs pemulihan bencana.

  • Azure Storage dienkripsi saat tidak aktif untuk semua akun penyimpanan menggunakan enkripsi Standar Enkripsi Tingkat Lanjut 256-bit dan sesuai dengan Standar Pemrosesan Informasi Federal 140-2. Enkripsi diaktifkan secara otomatis dan tidak dapat dinonaktifkan. Secara default, enkripsi menggunakan kunci yang dikelola Microsoft, tetapi pelanggan memiliki opsi untuk menggunakan kunci mereka sendiri yang disimpan di brankas Azure Key.
  • Disk terkelola dari Azure VM secara otomatis dienkripsi dengan menggunakan enkripsi sisi server dari disk terkelola Azure, yang juga berlaku untuk snapshotnya, dengan mengandalkan penggunaan kunci enkripsi yang dikelola platform.

Selain itu, Anda dapat memberlakukan akses terbatas ke akun Azure Storage yang menghosting konten disk yang direplikasi Site Recovery. Untuk melakukannya, aktifkan identitas terkelola untuk brankas Recovery Services dan tetapkan ke identitas terkelola tersebut peran kontrol akses berbasis peran Azure (Azure RBAC) berikut di tingkat akun Azure Storage:

• Akun penyimpanan berbasis Resource Manager (tingkat performa standar):
  • Kontributor
  • Kontributor Data Blob Penyimpanan
• Akun penyimpanan berbasis Resource Manager (tingkat performa premium):
  • Kontributor
  • Pemilik Data Blob Penyimpanan

Brankas Azure Recovery Services menawarkan mekanisme yang lebih melindungi kontennya, termasuk perlindungan berikut:

• Azure RBAC. Hal ini memungkinkan pendelegasian dan pemisahan tanggung jawab sesuai dengan prinsip hak istimewa terkecil. Ada tiga peran bawaan terkait Site Recovery yang membatasi akses ke operasi Site Recovery:
  • Kontributor Site Recovery. Peran ini memiliki semua izin yang diperlukan untuk mengelola operasi Site Recovery di vault Azure Recovery Services. Namun, pengguna dengan peran ini tidak dapat membuat atau menghapus brankas atau menetapkan hak akses ke pengguna lain. Peran ini paling cocok untuk administrator pemulihan bencana yang dapat mengaktifkan dan mengelola pemulihan bencana untuk penyewa Azure Stack Hub.
  • Operator Site Recovery. Peran ini memiliki izin untuk menjalankan dan mengelola operasi failover dan failback. Pengguna dengan peran ini tidak dapat mengaktifkan atau menonaktifkan replikasi, membuat atau menghapus brankas, mendaftarkan infrastruktur baru, atau menetapkan hak akses ke pengguna lain. Peran ini paling cocok untuk operator pemulihan bencana yang dapat memindahkan melalui Azure Stack Hub VM saat diinstruksikan oleh pemilik aplikasi dan administrator IT dalam skenario bencana aktual atau simulasi.
  • Pembaca Site Recovery. Peran ini memiliki izin untuk melacak semua operasi manajemen Site Recovery. Peran ini paling cocok untuk staf IT yang bertanggung jawab untuk memantau status Azure Stack Hub VM yang dilindungi dan meningkatkan tiket dukungan jika diperlukan.
• Kunci Sumber Daya Azure. Anda memiliki opsi untuk membuat dan menetapkan kunci baca-saja dan menghapus ke vault Site Recovery untuk mengurangi risiko vault diubah atau dihapus secara tidak sengaja dan berbahaya.
• Penghapusan sementara. Tujuan penghapusan lunak adalah untuk membantu melindungi brankas dan datanya dari penghapusan yang tidak disengaja atau berbahaya. Dengan penghapusan sementara, setiap konten yang dihapus akan dipertahankan selama 14 hari tambahan, memungkinkan pengambilannya selama periode tersebut. Retensi 14 hari tambahan konten brankas tidak dikenakan biaya apa pun. Penghapusan sementara diaktifkan secara default.
• Perlindungan operasi sensitif keamanan. Brankas Azure Recovery Services memungkinkan Anda untuk mengaktifkan lapisan autentikasi tambahan setiap kali operasi yang sensitif terhadap keamanan, seperti menonaktifkan perlindungan, dicoba. Validasi ekstra ini membantu memastikan bahwa pengguna yang berwenang melakukan operasi tersebut.
• Pemantauan dan peringatan aktivitas yang mencurigakan. Azure Recovery Services menyediakan pemantauan dan peringatan internal tentang peristiwa sensitif keamanan yang terkait dengan operasi brankas.

Pengoptimalan biaya

Optimalisasi biaya adalah tentang mencari cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Gambaran umum pilar pengoptimalan biaya.

Saat mempertimbangkan biaya solusi pemulihan bencana berbasis Site Recovery yang dijelaskan dalam artikel ini, Anda perlu memperhitungkan komponen lokal dan berbasis cloud. Model harga Azure Stack Hub menentukan harga komponen lokal. Seperti Azure, Azure Stack Hub menawarkan pengaturan bayar sesuai penggunaan, tersedia melalui perjanjian perusahaan dan program Penyedia Solusi Cloud. Pengaturan ini termasuk harga bulanan untuk setiap Windows Server VM. Jika Anda memiliki opsi untuk menggunakan lisensi Windows Server yang ada, Anda dapat secara signifikan mengurangi biaya ke harga VM dasar. Namun, dengan Site Recovery, Anda biasanya hanya memerlukan satu Azure Stack Hub VM per penyewa, yang diperlukan untuk mengimplementasikan server konfigurasi khusus penyewa.

Biaya terkait Azure dikaitkan dengan penggunaan sumber daya berikut ini:

• Azure Recovery Services. Harga ditentukan oleh jumlah instans yang dilindungi. Perlu dicatat bahwa setiap instans yang dilindungi tidak dikenakan biaya Site Recovery selama 31 hari pertama.

• Azure Storage. Harga mencerminkan kombinasi dari faktor-faktor berikut:

  • Tingkat performa
  • Volume data yang disimpan
  • Volume transfer data keluar
  • Kuantitas dan jenis operasi yang dilakukan (hanya untuk tingkat performa standar)
  • Redundansi data (hanya untuk tingkat performa standar)

• Azure ExpressRoute. Harga didasarkan pada salah satu dari dua model:

  • Data tidak terbatas. Model ini termasuk biaya bulanan dengan semua transfer data masuk dan keluar disertakan.
  • Paket data terukur. Model ini mencakup biaya bulanan dengan semua transfer data masuk gratis dan transfer data keluar dikenakan biaya per GB.

  Catatan

  Penilaian ini tidak termasuk biaya koneksi fisik yang dikirimkan oleh penyedia konektivitas pihak ketiga.

• Azure VM Harga Azure VM mencerminkan kombinasi dua komponen:

  • Biaya komputasi. Ukuran VM, waktu aktifnya, dan model lisensi sistem operasinya menentukan biaya.
  • Biaya disk terkelola. Ukuran disk dan tingkat performa menentukan biaya.

  Catatan

  Perlu dicatat bahwa hidrasi menghilangkan kebutuhan untuk menjalankan Azure VM selama operasi bisnis reguler, dengan beban kerja yang berjalan di Azure Stack Hub, yang sangat mengurangi biaya komputasi implementasi berbasis Site Recovery, terutama dibandingkan dengan solusi pemulihan bencana tradisional.

  Catatan

  Harga sumber daya bervariasi antara wilayah Azure.

  Catatan

  Untuk detail mengenai harga, lihat Harga Azure.

Keunggulan operasional

Keunggulan operasional mencakup proses operasi yang menyebarkan aplikasi dan membuatnya tetap berjalan dalam produksi. Untuk informasi selengkapnya, lihat Gambaran umum pilar keunggulan operasional.

Pertimbangan utama mengenai pengelolaan pemulihan bencana berbasis Site Recovery dari VM Azure Stack Hub meliputi:

• Implementasi Site Recovery di Azure Stack Hub
• Prosedur failover dan failback
• Delegasi peran dan tanggung jawab
• DevOps

Implementasi Site Recovery di Azure Stack Hub

Untuk menerapkan Site Recovery di Azure Stack Hub di lingkungan penyewa tunggal berukuran kecil hingga menengah, Anda dapat mengikuti proses provisi manual yang didorong oleh antarmuka grafis Vault Layanan Pemulihan di portal Azure. Untuk penerapan multi-penyewa, Anda mungkin ingin mempertimbangkan untuk mengotomatiskan bagian dari proses penerapan, karena Anda biasanya perlu menyiapkan VM server konfigurasi terpisah dan brankas Recovery Services terpisah untuk setiap penyewa. Anda juga memiliki opsi untuk mengotomatiskan penyebaran agen mobilitas dengan mengikuti prosedur yang dijelaskan di Menyiapkan komputer sumber untuk penginstalan otomatis agen mobilitas.

Prosedur failover dan failback

Untuk menyederhanakan manajemen failover, pertimbangkan untuk menerapkan rencana pemulihan untuk semua beban kerja yang dilindungi. Untuk informasi selengkapnya, lihat bagian Keandalan sebelumnya di artikel ini. Anda juga akan menemukan rekomendasi untuk mengoptimalkan manajemen prosedur failback.

Delegasi peran dan tanggung jawab

Merencanakan dan menerapkan pemulihan bencana beban kerja berbasis VM Azure Stack Hub dengan menggunakan Site Recovery biasanya melibatkan interaksi pemangku kepentingan:

• Operator Azure Stack Hub mengelola infrastruktur Azure Stack Hub, memastikan bahwa ada cukup sumber daya komputasi, penyimpanan, dan jaringan yang diperlukan untuk menerapkan solusi pemulihan bencana yang komprehensif dan membuat sumber daya ini tersedia untuk penyewa. Operator tersebut juga berkolaborasi dengan pemilik aplikasi dan data untuk membantu menentukan pendekatan optimal guna menyebarkan beban kerjanya ke Azure Stack Hub.
• Administrator Azure mengelola sumber daya Azure yang diperlukan untuk menerapkan solusi pemulihan bencana hibrida.
• Administrator Microsoft Entra mengelola sumber daya Microsoft Entra, termasuk objek pengguna dan grup yang digunakan untuk menyediakan, mengonfigurasi, dan mengelola sumber daya Azure.
• Staf IT penyewa Azure Stack Hub merancang, mengimplementasikan, dan mengelola Site Recovery, termasuk failover dan failback.
• Pengguna Azure Stack Hub perlu menyediakan persyaratan RPO dan RTO dan mengirimkan permintaan untuk menerapkan pemulihan bencana untuk beban kerjanya.

Pastikan ada pemahaman yang jelas tentang peran dan tanggung jawab yang dikaitkan dengan pemilik dan operator aplikasi dalam konteks perlindungan dan pemulihan. Pengguna bertanggung jawab untuk melindungi VM. Operator bertanggung jawab atas status operasional infrastruktur Azure Stack Hub.

DevOps

Meskipun mengonfigurasi pemulihan tingkat VM dengan menggunakan Site Recovery terutama merupakan tanggung jawab operasi TI, ada beberapa pertimbangan khusus DevOps yang harus dimasukkan ke dalam strategi pemulihan bencana yang komprehensif. Azure Stack Hub memfasilitasi penerapan Infrastructure-as-Code (IaC), yang menggabungkan penyebaran otomatis berbagai beban kerja, termasuk aplikasi dan layanan berbasis VM. Anda dapat menggunakan kemampuan ini untuk menyederhanakan provisi skenario pemulihan bencana berbasis Site Recovery, yang menyederhanakan penyiapan awal dalam beberapa skenario penyewa.

Misalnya, Anda dapat menggunakan templat Azure Resource Manager yang sama untuk menyediakan semua sumber daya jaringan yang diperlukan untuk mengakomodasi beban kerja berbasis VM di stempel Azure Stack Hub untuk aplikasi Anda dalam satu operasi terkoordinasi. Anda dapat menggunakan templat yang sama untuk menyediakan kumpulan sumber daya yang cocok di Azure untuk menyediakan situs pemulihan bencana. Untuk memperhitungkan perbedaan antara dua lingkungan, Anda cukup menentukan nilai parameter templat yang berbeda dalam setiap kasus.

Efisiensi kinerja

Efisiensi performa adalah kemampuan beban kerja Anda untuk diskalakan agar memenuhi permintaan yang diberikan oleh pengguna dengan cara yang efisien. Untuk informasi selengkapnya, lihat Gambaran umum pilar efisiensi performa.

Saat berencana untuk menyebarkan Site Recovery di Azure Stack Hub, Anda perlu mempertimbangkan jumlah sumber daya pemrosesan, penyimpanan, dan jaringan yang dialokasikan untuk konfigurasi dan server proses. Anda mungkin perlu menyesuaikan perkiraan ukuran VM Azure Stack Hub yang menghosting komponen Site Recovery pasca penyebaran untuk mengakomodasi perubahan dalam persyaratan pemrosesan atau penyimpanan. Anda memiliki tiga opsi dasar untuk menyesuaikan ukuran:

• Menerapkan penyekalaan vertikal. Ini melibatkan modifikasi jumlah dan jenis prosesor, memori, dan sumber daya disk dari Azure Stack Hub VM yang menghosting server konfigurasi termasuk server proses. Untuk memperkirakan kebutuhan sumber daya, Anda dapat menggunakan informasi dalam tabel berikut:

  Tabel 1: Persyaratan ukuran server proses dan konfigurasi

  CPU	Memori	Disk cache	Tingkat perubahan data	Mesin-mesin yang dilindungi
  8 vCPU 2 soket * 4 core @ 2,5 GHz	16GB	300 GB	500 GB atau kurang	< 100 komputer
  12 vCPU 2 soket * 6 core @ 2,5 GHz	18 GB	600 GB	500 GB – 1 TB	100 hingga 150 komputer
  16 vCPU 2 soket * 8 core @ 2,5 GHz	32 GB	1 TB	1-2 TB	150-200 komputer

• Menerapkan penskalaan horizontal. Ini melibatkan provisi atau deprovisioning Azure Stack Hub VM dengan server proses yang diinstal agar sesuai dengan permintaan pemrosesan Azure Stack Hub VM yang dilindungi. Secara umum, jika Anda harus menskalakan penyebaran Anda ke lebih dari 200 komputer sumber, atau Anda memiliki total churn harian lebih dari dua terabyte (TB), Anda memerlukan server proses tambahan untuk menangani lalu lintas replikasi. Untuk memperkirakan jumlah dan konfigurasi server proses tambahan, lihat Rekomendasi ukuran untuk server proses.

• Mengubah kebijakan replikasi. Ini melibatkan perubahan parameter kebijakan replikasi, dengan fokus pada snapshot yang konsisten dengan aplikasi.

Dari sudut pandang jaringan, ada beberapa metode berbeda untuk menyesuaikan bandwidth yang tersedia untuk lalu lintas replikasi:

• Ubah ukuran VM. Ukuran Azure Stack Hub VM menentukan bandwidth jaringan maksimum. Namun, penting untuk dicatat bahwa tidak ada jaminan bandwidth. Sebagai gantinya, VM dapat memanfaatkan jumlah bandwidth yang tersedia hingga batas yang ditentukan oleh ukurannya.

• Ganti switch uplink. Sistem Azure Stack Hub mendukung berbagai switch perangkat keras, menawarkan beberapa pilihan kecepatan uplink. Setiap node kluster Azure Stack Hub memiliki dua uplink ke atas switch rak untuk toleransi kesalahan. Sistem mengalokasikan setengah dari kapasitas uplink untuk infrastruktur penting. Sisanya adalah kapasitas bersama untuk layanan Azure Stack Hub dan semua lalu lintas pengguna. Sistem yang disebarkan dengan kecepatan lebih cepat memiliki lebih banyak bandwidth yang tersedia untuk lalu lintas replikasi.

  Catatan

  Meskipun dimungkinkan untuk memisahkan lalu lintas jaringan dengan melampirkan adapter jaringan kedua ke server, dengan Azure Stack Hub VM, semua lalu lintas VM ke internet berbagi uplink yang sama. Kedua, adapter jaringan virtual tidak akan memisahkan lalu lintas di tingkat transportasi fisik.

• Ubah throughput koneksi jaringan ke Azure. Untuk mengakomodasi volume lalu lintas replikasi yang lebih besar, Anda mungkin mempertimbangkan untuk menggunakan Azure ExpressRoute dengan peering Microsoft untuk koneksi antara jaringan virtual Azure Stack Hub dan Azure Storage. Azure ExpressRoute memperluas jaringan lokal ke cloud Microsoft melalui koneksi privat yang disediakan oleh penyedia konektivitas. Anda dapat membeli sirkuit ExpressRoute untuk berbagai bandwidth, dari 50 megabit per detik (Mbps) hingga 100 gigabit per detik.

  Catatan

  Untuk detail tentang penerapan Azure ExpressRoute dalam skenario Azure Stack Hub, lihat Menghubungkan Azure Stack Hub ke Azure menggunakan Azure ExpressRoute.

• Ubah pembatasan lalu lintas replikasi di server proses. Anda dapat mengontrol berapa banyak bandwidth yang digunakan oleh lalu lintas replikasi di VM yang menghosting server proses dari antarmuka grafis agen Microsoft Azure Recovery Services. Kemampuan yang didukung termasuk pengaturan batas untuk jam kerja dan non-kerja, dengan nilai bandwidth mulai dari 512 kilobit per detik hingga 1.023 Mbps. Atau, Anda dapat menerapkan konfigurasi yang sama dengan menggunakan cmdlet PowerShell Set-OBMachineSetting.

• Ubah bandwidth jaringan yang dialokasikan per VM yang dilindungi di server proses. Untuk melakukannya, ubah nilai entri UploadThreadsPerVM dalam kunci HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\Replication. Secara default, nilainya diatur ke 4, tetapi Anda dapat meningkatkannya menjadi 32 jika ada cukup bandwidth jaringan yang tersedia.

Menyebarkan skenario ini

Prasyarat

Menerapkan solusi yang direkomendasikan bergantung pada pemenuhan prasyarat berikut:

• Akses ke langganan Azure, dengan izin yang memadai untuk menyediakan dan mengelola semua komponen cloud komponen Site Recovery, termasuk:

  • Brankas Azure Recovery Services di wilayah Azure yang ditentukan sebagai situs pemulihan bencana untuk lingkungan produksi Azure Stack Hub.
  • Akun Azure Storage yang menghosting konten disk yang direplikasi dari Azure Stack Hub VM.
  • Jaringan virtual Azure yang mewakili lingkungan pemulihan bencana tempat Azure VM terhidrasi akan tersambung setelah failover yang direncanakan atau tidak direncanakan.
  • Jaringan virtual Azure terisolasi yang mewakili lingkungan pengujian tempat Azure VM terhidrasi akan tersambung setelah pengujian failover.
  • Konektivitas berbasis Azure ExpressRoute antara lingkungan lokal, jaringan virtual Azure, dan akun penyimpanan Azure yang digunakan untuk menghosting salinan file VHD dengan konten yang direplikasi dari disk Azure Stack Hub VM yang dilindungi.

• Langganan pengguna Azure Stack Hub. Semua VM Azure Stack Hub yang dilindungi oleh server konfigurasi Site Recovery individual harus termasuk dalam langganan pengguna Azure Stack Hub yang sama.

• Jaringan virtual Azure Stack Hub. Semua VM yang dilindungi harus memiliki konektivitas langsung ke VM yang menghosting komponen server proses (secara default ini adalah VM server konfigurasi).

• Azure Stack Hub Windows Server VM yang akan menghosting server konfigurasi dan server proses. VM harus termasuk dalam langganan yang sama dan dilampirkan ke jaringan virtual yang sama dengan Azure Stack Hub VM yang perlu dilindungi. Selain itu, VM perlu:

  • Mematuhi persyaratan perangkat lunak dan perangkat keras server konfigurasi Site Recovery
  • Memenuhi dokumentasi persyaratan jaringan konektivitas eksternal.

  Catatan

  Penyimpanan tambahan dan pertimbangan performa untuk konfigurasi dan server proses dijelaskan secara lebih rinci nanti dalam arsitektur ini.

  • Memenuhi persyaratan konektivitas internal. Secara khusus, Azure Stack Hub VM yang ingin Anda lindungi harus dapat berkomunikasi dengan:

    • Server konfigurasi melalui port TCP 443 (HTTPS) masuk untuk manajemen replikasi
    • Server proses melalui port TCP 9443 untuk mengirimkan data replikasi.

    Catatan

    Anda dapat mengubah port yang digunakan oleh server proses untuk konektivitas eksternal dan internal sebagai bagian dari konfigurasinya saat menjalankan Penyiapan Terpadu Site Recovery.

• Azure Stack Hub VM yang akan dilindungi, menjalankan salah satu sistem operasi yang didukung Untuk melindungi Azure Stack Hub VM yang menjalankan sistem operasi Windows Server, Anda harus:

  • Membuat akun Windows dengan hak administratif. Anda dapat menentukan akun ini saat mengaktifkan Site Recovery pada VM ini. Server proses menggunakan akun ini untuk menginstal layanan Mobilitas Site Recovery. Di lingkungan grup kerja, pastikan untuk menonaktifkan kontrol Akses Pengguna Jarak Jauh pada sistem operasi Windows Server target dengan mengatur nilai entri registri DWORD LocalAccountTokenFilterPolicy di kunci HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System ke 1.
  • Mengaktifkan aturan Instrumen Manajemen Windows dan Berbagi File dan Printer di firewall Microsoft Defender.

• Untuk melindungi Azure Stack Hub VM yang menjalankan sistem operasi Linux, Anda harus:

  • Membuat akun pengguna akar. Anda dapat menentukan akun ini saat mengaktifkan Site Recovery pada VM ini. Server proses menggunakan akun ini untuk menginstal layanan Mobilitas Site Recovery.
  • Menginstal paket openssh, openssh-server, dan openssl terbaru.
  • Mengaktifkan dan menjalankan port Shell Aman (SSH) 22.
  • Mengaktifkan subsistem FTP Aman dan autentikasi kata sandi.

Langkah-langkah implementasi tingkat tinggi

Pada tingkat tinggi, implementasi pemulihan bencana berbasis Site Recovery di Azure Stack Hub terdiri dari tahap-tahap berikut:

1. Siapkan VM Azure Stack Hub untuk dilindungi oleh Site Recovery. Pastikan bahwa VM memenuhi prasyarat Site Recovery yang tercantum di bagian sebelumnya.

2. Buat dan konfigurasikan brankas Azure Recovery Services. Siapkan brankas Azure Recovery Services dan tentukan apa yang ingin Anda replikasi. Komponen dan aktivitas Site Recovery dikonfigurasi dan dikelola dengan menggunakan vault.

3. Siapkan lingkungan replikasi sumber. Provisikan server konfigurasi Site Recovery dan server proses dengan menginstal biner Penyiapan Terpadu Site Recovery dan mendaftarkannya dengan vault.

   Catatan

   Anda dapat menjalankan ulang Penyiapan Terpadu Site Recovery untuk menerapkan server proses tambahan di VM Azure Stack Hub.

4. Siapkan lingkungan replikasi target. Buat atau pilih akun penyimpanan Azure yang sudah ada dan jaringan virtual Azure di wilayah Azure yang akan menghosting situs pemulihan bencana. Selama replikasi, konten disk untuk Azure Stack Hub VM yang dilindungi disalin ke akun Azure Storage. Selama failover, Site Recovery secara otomatis memprovisikan Azure VM yang berfungsi sebagai replika VM Azure Stack Hub yang dilindungi dan menghubungkannya ke jaringan virtual Azure.

5. Mengaktifkan replikasi. Konfigurasikan pengaturan replikasi dan aktifkan replikasi untuk Azure Stack Hub VM. Layanan mobilitas diinstal secara otomatis di setiap Azure Stack Hub VM yang replikasinya diaktifkan. Site Recovery memulai replikasi setiap VM Azure Stack Hub, sesuai dengan pengaturan kebijakan yang Anda tentukan.

6. Lakukan uji failover. Setelah replikasi dibuat, verifikasi bahwa failover akan berfungsi seperti yang diharapkan dengan melakukan uji failover.

7. Lakukan failover yang direncanakan atau tidak direncanakan. Setelah pengujian failover yang berhasil, Anda siap untuk melakukan failover yang direncanakan atau tidak direncanakan ke Azure. Anda memiliki opsi untuk menentukan Azure Stack Hub VM mana yang akan disertakan dalam failover.

8. Lakukan failback. Saat Anda siap untuk melakukan failback, hentikan Azure VM yang terkait dengan Azure Stack Hub VM yang gagal, unduh file disk ke penyimpanan lokal, unggah ke Azure Stack Hub, dan lampirkan ke VM yang ada atau baru.

Ringkasan

Kesimpulannya, Azure Stack Hub adalah penawaran unik, yang dari berbagai aspek berbeda dengan platform virtualisasi lainnya. Oleh karena itu, perlu pertimbangan khusus sehubungan dengan strategi keberlangsungan bisnis untuk beban kerjanya. Dengan menggunakan layanan Azure, Anda dapat menyederhanakan merancang dan menerapkan strategi ini. Dalam artikel referensi arsitektur ini, kami menjelajahi penggunaan Microsoft Site Recovery untuk melindungi beban kerja berbasis VM Azure Stack Hub dalam model penyebaran yang terhubung. Pendekatan ini memungkinkan pelanggan mendapatkan keuntungan dari ketahanan dan pengelolaan Azure Stack Hub dan dari kehadiran cloud Azure yang berskala besar dan global.

Penting untuk dicatat bahwa solusi pemulihan bencana yang dijelaskan di sini berfokus secara eksklusif pada beban kerja berbasis VM dari Azure Stack Hub. Ini hanya bagian dari keseluruhan strategi keberlangsungan bisnis yang harus memperhitungkan jenis dan skenario beban kerja Azure Stack Hub lainnya yang memengaruhi ketersediaannya.

Langkah berikutnya

Dokumentasi produk:

• Tentang Pemulihan Situs
• Gambaran umum Azure Stack Hub
• Apa itu ID Microsoft Entra?
• Apa itu penyimpanan Blob Azure?
• Apa itu Azure ExpressRoute?
• Apa itu Azure Virtual Network?

Modul Microsoft Learn:

• Azure Stack Hub
• Mengonfigurasi ID Microsoft Entra
• Mengonfigurasi akun penyimpanan
• Mengonfigurasi jaringan virtual
• Merancang dan mengimplementasikan Azure ExpressRoute
• Mendesain solusi pemulihan situs Anda di Azure

Sumber daya terkait

• Desain arsitektur hibrid
• Mencadangkan file dan aplikasi di Azure Stack Hub
• Sambungan Hibrid
• Berbagi file hibrid dengan pemulihan bencana untuk pekerja cabang jarak jauh dan lokal