Pemulihan bencana Azure Virtual Desktop

  • Artikel

Untuk menjaga keamanan data organisasi Anda, Anda harus mengadopsi dan mengelola strategi kelangsungan bisnis dan pemulihan bencana (BCDR). Strategi BCDR yang sehat membuat aplikasi dan beban kerja Anda tetap aktif dan berjalan selama layanan yang direncanakan dan tidak direncanakan atau pemadaman Azure. Paket ini harus mencakup mesin virtual host sesi (VM) yang dikelola oleh pelanggan, berbeda dengan layanan Azure Virtual Desktop yang dikelola oleh Microsoft. Untuk informasi selengkapnya tentang area manajemen, lihat konsep pemulihan bencana Azure Virtual Desktop.

Layanan Azure Virtual Desktop dirancang dengan mempertimbangkan high availability. Azure Virtual Desktop adalah layanan global yang dikelola oleh Microsoft, dengan beberapa instans komponen independen yang didistribusikan di beberapa wilayah Azure. Jika ada pemadaman tak terduga di salah satu komponen, lalu lintas Anda akan dialihkan ke salah satu instans yang tersisa atau Microsoft akan memulai failover penuh ke infrastruktur yang berlebihan di wilayah Azure lain.

Untuk memastikan pengguna masih dapat terhubung selama pemadaman wilayah di mesin virtual host sesi, Anda perlu merancang infrastruktur dengan mempertimbangkan high availability dan pemulihan bencana. Rencana pemulihan bencana yang umum mencakup replikasi mesin virtual (VM) ke lokasi yang berbeda. Selama pemadaman, situs utama yang gagal dialihkan ke VM yang direplikasi di lokasi sekunder. Pengguna dapat terus mengakses aplikasi dari lokasi sekunder tanpa gangguan. Selain replikasi VM, Anda harus menjaga identitas pengguna tetap dapat diakses di lokasi sekunder. Jika menggunakan kontainer profil, Anda juga harus mereplikasinya. Terakhir, pastikan aplikasi bisnis Anda yang mengandalkan data di lokasi utama yang gagal dapat dialihkan dengan data lainnya.

Untuk meringkas, agar pengguna Anda tetap terhubung selama pemadaman, Anda harus melakukan hal-hal berikut:

  • Replikasi mesin virtual ke lokasi sekunder.
  • Jika Anda menggunakan kontainer profil, siapkan replikasi data di lokasi sekunder.
  • Pastikan identitas pengguna yang Anda atur di lokasi utama tersedia di lokasi sekunder. Untuk memastikan ketersediaan, pastikan Pengendali Domain Direktori Aktif Anda tersedia di atau dari lokasi sekunder.
  • Pastikan semua aplikasi lini bisnis dan data di lokasi utama Anda yang juga gagal dialihkan ke lokasi sekunder.

Rencana pemulihan bencana aktif-pasif dan aktif-aktif

Ada dua jenis infrastruktur pemulihan bencana: aktif-pasif dan aktif-aktif. Setiap jenis infrastruktur bekerja dengan cara yang berbeda, jadi mari kita lihat apa perbedaannya.

Paket aktif-pasif adalah ketika Anda memiliki wilayah dengan satu set sumber daya yang aktif dan yang dimatikan hingga diperlukan (pasif). Jika wilayah aktif menjadi offline karena gangguan atau bencana, organisasi dapat beralih ke wilayah pasif dengan menyalakannya dan mengarahkan semua pengguna ke sana.

Opsi lainnya adalah penyebaran aktif-aktif, di mana Anda menggunakan kedua set infrastruktur secara bersamaan. Meskipun beberapa pengguna mungkin terpengaruh oleh pemadaman, dampaknya terbatas pada pengguna di wilayah yang mengalami gangguan. Pengguna di wilayah lain yang masih online tidak akan terpengaruh, dan pemulihan terbatas pada pengguna di wilayah yang terpengaruh yang menyambung kembali ke wilayah aktif yang berfungsi. Penyebaran aktif-aktif dapat mengambil banyak formulir, termasuk:

  • Penyediaan infrastruktur yang berlebihan di setiap wilayah untuk mengakomodasi pengguna yang terkena dampak jika salah satu wilayah mengalami gangguan. Kelemahan potensial dari metode ini adalah bahwa mempertahankan sumber daya tambahan membutuhkan biaya lebih.
  • Memiliki host sesi tambahan di kedua wilayah aktif, tetapi batalkan alokasinya saat tidak diperlukan, yang mengurangi biaya.
  • Hanya provisikan infrastruktur baru selama pemulihan bencana dan izinkan pengguna yang terpengaruh untuk terhubung ke host sesi yang baru disediakan. Metode ini memerlukan pengujian rutin dengan alat infrastruktur sebagai kode sehingga Anda dapat menyebarkan infrastruktur baru secepat mungkin selama bencana.

Untuk informasi selengkapnya tentang jenis rencana pemulihan bencana yang dapat Anda gunakan, lihat konsep pemulihan bencana Azure Virtual Desktop.

Mengidentifikasi metode mana yang paling cocok untuk organisasi Anda adalah hal pertama yang harus Anda lakukan sebelum memulai. Setelah Anda memiliki rencana Anda di tempat, Anda dapat mulai membangun rencana pemulihan Anda.

Replikasi VM

Pertama, Anda harus mereplikasi VM ke lokasi sekunder. Opsi Anda untuk melakukannya bergantung pada bagaimana VM Anda dikonfigurasi:

  • Anda dapat mengonfigurasi replikasi untuk semua mesin virtual Anda di kumpulan host dan kumpulan host privat dengan Azure Site Recovery. Untuk informasi selengkapnya tentang cara kerja proses ini, lihat Mereplikasi Azure VM ke wilayah Azure lainnya. Namun, jika Anda telah mengumpulkan kumpulan host yang Anda buat dari gambar yang sama dan tidak memiliki data pengguna privat yang disimpan secara lokal, Anda dapat memilih untuk tidak mereplikasinya. Sebagai gantinya, Anda memiliki opsi untuk membangun mesin virtual sebelumnya dan membiarkannya dimatikan. Anda juga dapat memilih untuk hanya menyediakan mesin virtual baru di wilayah sekunder saat bencana terjadi. Jika Anda memilih metode ini, Anda hanya perlu menyiapkan satu kumpulan host dan grup aplikasi dan ruang kerja terkait.
  • Anda dapat membuat kumpulan host baru di wilayah pengalihan sambil menonaktifkan semua sumber daya di lokasi kegagalan Anda. Untuk metode ini, Anda harus menyiapkan grup aplikasi dan ruang kerja baru di wilayah failover. Anda kemudian dapat menggunakan paket Azure Site Recovery untuk mengaktifkan kumpulan host.
  • Anda dapat membuat kumpulan host yang diisi oleh VM yang dibangun baik di wilayah utama maupun wilayah pengalihan sambil menonaktifkan VM di wilayah kegagalan. Dalam hal ini, Anda hanya perlu menyiapkan satu kumpulan host dan grup aplikasi dan ruang kerja terkait. Anda dapat menggunakan paket Azure Site Recovery untuk mengaktifkan kumpulan host dengan metode ini.

Kami menyarankan Anda menggunakan Azure Site Recovery untuk mengelola replikasi mesin virtual ke lokasi Azure lainnya, seperti yang dijelaskan dalam arsitektur pemulihan bencana Azure-ke-Azure. Kami secara khusus merekomendasikan penggunaan Azure Site Recovery untuk kumpulan host pribadi karena, sesuai dengan namanya, kumpulan host pribadi cenderung memiliki sesuatu yang pribadi tentang mereka untuk penggunanya. Azure Site Recovery mendukung SKU berbasis server dan berbasis klien.

Jika Anda menggunakan Azure Site Recovery, Anda tidak perlu mendaftarkan VM ini secara manual. Agen Azure Virtual Desktop di VM sekunder akan secara otomatis menggunakan token keamanan terbaru untuk terhubung ke instans layanan yang paling dekat dengannya. VM (host sesi) di lokasi sekunder akan secara otomatis menjadi bagian dari kumpulan host. Pengguna akhir harus terhubung kembali selama proses, tetapi selain itu, tidak ada operasi manual lainnya.

Jika ada koneksi pengguna yang ada selama pemadaman, sebelum admin dapat mulai gagal ke wilayah sekunder, Anda harus mengakhiri koneksi pengguna di wilayah saat ini.

Untuk memutuskan koneksi pengguna di Azure Virtual Desktop (klasik), jalankan cmdlet ini:

Invoke-RdsUserSessionLogoff

Untuk memutuskan sambungan pengguna di Azure Virtual Desktop, jalankan cmdlet ini:

Remove-AzWvdUserSession

Setelah Anda mengeluarkan semua pengguna di wilayah utama, Anda dapat mengalihkan VM di wilayah utama dan memungkinkan pengguna terhubung ke VM di wilayah sekunder.

Jaringan virtual

Selanjutnya, pertimbangkan konektivitas jaringan Anda selama pemadaman. Anda harus memastikan bahwa Anda telah menyiapkan jaringan virtual (VNET) di wilayah sekunder. Jika pengguna perlu mengakses sumber daya lokal, Anda harus mengonfigurasi VNET ini untuk mengaksesnya. Anda dapat membuat koneksi lokal dengan VPN, ExpressRoute, atau WAN virtual.

Kami menyarankan agar Anda menggunakan Azure Site Recovery untuk menyiapkan VNET di wilayah kegagalan karena mempertahankan pengaturan jaringan utama Anda dan tidak perlu peering.

Identitas pengguna.

Selanjutnya, pastikan bahwa pengontrol domain tersedia di lokasi sekunder.

Ada tiga cara untuk menjaga pengontrol domain tetap tersedia:

  • Memiliki satu atau lebih Pengendali Domain Direktori Aktif di lokasi sekunder
  • Menggunakan Active Directory Domain Controller di tempat
  • Replikasi Active Directory Domain Controller menggunakan Azure Site Recovery

Profil pengguna

Kami menyarankan agar Anda menggunakan FSLogix untuk mengelola profil pengguna. Untuk informasi, lihat Opsi kelangsungan bisnis dan pemulihan bencana untuk FSLogix.

Mencadangkan data Anda

Anda juga memiliki opsi untuk mencadangkan data Anda. Anda dapat memilih salah satu metode berikut untuk mencadangkan data Azure Virtual Desktop Anda:

  • Untuk data Komputasi, sebaiknya hanya mencadangkan kumpulan host pribadi dengan Azure Backup.
  • Untuk data Penyimpanan, solusi cadangan yang kami sarankan bervariasi berdasarkan penyimpanan back-end yang Anda gunakan untuk menyimpan profil pengguna:

Dependensi Aplikasi

Terakhir, pastikan bahwa aplikasi bisnis apa pun yang mengandalkan data yang berada di wilayah utama dapat dialihkan ke lokasi sekunder. Selain itu, pastikan untuk mengonfigurasi pengaturan yang dibutuhkan aplikasi untuk bekerja di lokasi baru. Misalnya, jika salah satu aplikasi bergantung pada backend SQL, pastikan untuk mereplikasi SQL di lokasi sekunder. Anda harus mengonfigurasi aplikasi untuk menggunakan lokasi sekunder sebagai bagian dari proses pengalihan atau sebagai konfigurasi defaultnya. Anda dapat memodelkan dependensi aplikasi pada paket Azure Site Recovery. Untuk mempelajari selengkapnya, lihat Tentang rencana pemulihan.

Pengujian pemulihan bencana

Setelah selesai menyiapkan pemulihan bencana, Anda harus menguji rencana tersebut untuk memastikan keberhasilannya.

Berikut adalah beberapa saran tentang cara menguji rencana Anda:

  • Jika mesin virtual pengujian memiliki akses internet, mereka akan mengambil alih semua host sesi yang ada untuk koneksi baru, tetapi semua koneksi yang ada ke host sesi asli akan tetap aktif. Pastikan admin yang menjalankan pengujian akan mengeluarkan semua pengguna aktif sebelum menguji paket.
  • Anda hanya boleh melakukan tes pemulihan bencana penuh selama jendela pemeliharaan agar tidak mengganggu pengguna Anda.
  • Pastikan pengujian Anda mencakup semua aplikasi dan data penting bisnis.
  • Kami sarankan Anda hanya mengalihkan hingga 100 VM sekaligus. Jika Anda memiliki lebih banyak VM dari itu, kami sarankan Anda mengalihkan dalam batch 10 menit terpisah.

Langkah berikutnya

Jika Anda memiliki pertanyaan tentang cara menjaga keamanan data Anda selain merencanakan pemadaman, lihat panduan keamanan kami.