Kelangsungan bisnis dan pemulihan bencana untuk Azure VMware Solution

  • Artikel

Skenario skala perusahaan ini membantu meningkatkan kelangsungan bisnis dan pemulihan bencana (BCDR). Azure VMware Solution menyediakan cloud privat yang berisi kluster VMware vSphere yang dibangun dari infrastruktur Azure bare-metal khusus. Solusi ini dilengkapi dengan minimal tiga host ESXi, hingga maksimal 16 host per kluster. Semua cloud privat yang disediakan memiliki VMware vCenter Server, VMware vSAN, VMware vSphere, dan VMware NSX-T Data Center. Untuk mempelajari tentang perjanjian tingkat layanan (SLA) untuk Azure VMware Solution, lihat SLA untuk Azure VMware Solution.

Baik Anda memiliki Azure VMware Solution atau lokal, Anda harus mempertimbangkan berbagai faktor BCDR untuk mempersiapkan bencana. Rencana BCDR yang kuat bertujuan untuk melindungi perusahaan dari kehilangan data, kerugian keuangan, dan waktu henti jika ada peristiwa yang mengganggu. Pohon keputusan berikut menunjukkan berbagai opsi BCDR yang tersedia untuk Azure VMware Solution.

Diagram that shows a flow chart for business continuity and disaster recovery.

Catatan

Lingkungan lampu pilot disiapkan dengan konfigurasi minimal, hanya dengan komponen inti untuk mendukung serangkaian aplikasi penting. Namun, itu dapat menskalakan dan menghasilkan lebih banyak host untuk mengambil sebagian besar beban jika kegagalan terjadi. Untuk pemulihan bencana beban kerja solusi Azure VMware intensif komputasi dan memori, jumlah penyimpanan yang sama diperlukan di situs sekunder.

Pertimbangan desain kelangsungan bisnis

  • Kebijakan penyimpanan VMware vSAN di Azure VMware Solution diimplementasikan dengan mempertimbangkan ketersediaan penyimpanan. Ketika kluster memiliki antara tiga dan lima host, jumlah kegagalan host yang dapat ditoleransi tanpa kehilangan data sama dengan satu. Jika kluster memiliki antara 6 dan 16 host, jumlah kegagalan host yang akan ditolerir sebelum kehilangan data dapat terjadi sama dengan dua. Kebijakan penyimpanan VMware vSAN dapat diterapkan berdasarkan per-VM. Meskipun kebijakan ini adalah default, Anda dapat mengubah kebijakan agar sesuai dengan persyaratan kustom. Untuk informasi selengkapnya, lihat Konsep penyimpanan Azure VMware Solution.

  • Ketersediaan tinggi vSphere diaktifkan secara default di Azure VMware Solution. Kebijakan pengakuan ketersediaan tinggi mencadangkan kapasitas komputasi dan memori untuk satu simpul. Reservasi ini memastikan kapasitas yang memadai untuk memulai ulang beban kerja di simpul lain di kluster Azure VMware Solution.

  • Ketersediaan tinggi dengan kluster stretch: Dengan Azure VMware Solution, host ESXi yang disebarkan dalam kluster vSphere standar secara tradisional berada dalam satu zona ketersediaan Azure dan dilindungi oleh ketersediaan tinggi vSphere. Namun, beban kerja tidak dilindungi dari kegagalan zona ketersediaan. Untuk melindungi dari kegagalan, satu kluster vSAN dapat mencakup dua zona ketersediaan terpisah, yang disebut kluster yang direntangkan vSAN. Untuk informasi selengkapnya, lihat Menyebarkan kluster yang direntangkan vSAN.

  • Pilih solusi pencadangan yang divalidasi untuk komputer virtual (VM) VMware vSphere, seperti Microsoft Azure Backup Server atau solusi pencadangan mitra.

  • Untuk informasi tentang fitur yang didukung dalam solusi pencadangan mitra, lihat dokumentasi mitra masing-masing.

    Catatan

    Konfigurasi vCenter Server dan NSX-T Data Center untuk cloud privat dicadangkan setiap jam, dan cadangan disimpan selama tiga hari.

  • Komponen Azure VMware Solution seperti vCenter Server, NSX-T Manager, atau Manajer HCX adalah layanan terkelola tempat Azure mengelola pencadangan. Untuk memulihkan dari cadangan, buat permintaan Dukungan Azure.

Rekomendasi desain kelangsungan bisnis

  • Gunakan Azure Backup Server untuk mencadangkan cloud privat Azure VMware Solution. Untuk informasi selengkapnya, lihat Mencadangkan VM VMware vSphere dengan Azure Backup. Topologi penyebaran yang didukung termasuk Agen MARS dan Manajer Perlindungan Data. Setiap topologi penyebaran memiliki matriks dukungan, batasan, dan batasannya sendiri.

  • Sebarkan Server Azure Backup di wilayah Azure yang sama dengan cloud privat Azure VMware Solution. Metode penyebaran ini mengurangi biaya lalu lintas, memudahkan administrasi, dan mempertahankan topologi primer/sekunder. Lihat panduan pemilihan wilayah Azure untuk praktik terbaik penyebaran wilayah Azure.

  • Azure Backup dapat disebarkan sebagai VM infrastruktur sebagai layanan (IaaS) Azure atau dalam cloud privat Azure VMware Solution. Sangat disarankan untuk menyebarkannya di luar cloud privat Azure VMware Solution. Sebarkan Cadangan di jaringan virtual Azure dan pastikan jaringan virtual ini terhubung ke ExpressRoute yang sama yang terhubung ke cloud privat Azure VMware Solution. Menjalankan Server Cadangan di luar cloud privat Azure VMware Solution membantu mengurangi konsumsi vSAN, karena vSAN adalah sumber daya kapasitas terbatas dalam cloud privat Azure VMware Solution.

    Azure Backup Server disebarkan sebagai Azure IaaS VM.

    Diagram that shows Azure Backup Server deployed as an Azure IaaS VM.

    Azure Backup Server disebarkan sebagai VM Azure VMware Solution.

    Diagram that shows Azure Backup Server deployed as an Azure VMware Solution VM.

  • Gunakan daftar periksa persyaratan performa aplikasi untuk tiba pada kapasitas dan jenis disk yang tepat, seperti HDD, SSD, atau Ultra. Pertimbangkan Azure IaaS VM SKU yang mendukung jenis disk dan kapasitas untuk operasi pencadangan.

  • Gunakan perencana kapasitas Azure Backup Server untuk menentukan jumlah server, penyimpanan, dan persyaratan IOPS untuk masing-masing server. Saat memberikan nilai "Total Ukuran Beban Kerja (GB)*" dalam perencana kapasitas, gunakan nilai median antara "penyimpanan yang digunakan" dan "penyimpanan yang dialokasikan" dari semua VM di vCenter yang ingin Anda cadangkan.

  • Gunakan kumpulan penyimpanan dengan Azure Backup Server untuk IOPS/throughput disk yang ditingkatkan. Gunakan penyimpanan berjenjang di Server Cadangan untuk operasi yang ditingkatkan. Atur nilai konfigurasi DisableWriteAutoTiering ke 1 pada volume MABS sehingga seluruh tingkat performa tersedia untuk menyimpan metadata ReFS.

  • Identifikasi jumlah pekerjaan pencadangan paralel dan operasi pemulihan untuk dijalankan di server Azure Backup. Saat ini, delapan pekerjaan pencadangan paralel didukung. Ukur jumlah waktu yang diperlukan untuk mencadangkan dan memulihkan beban kerja misi penting selama beberapa eksekusi. Validasi bahwa waktu pencadangan dan pemulihan memenuhi persyaratan RPO dan RTO untuk server Azure Backup. Pastikan bahwa datastore AVS vSAN memiliki kapasitas yang cukup untuk menyimpan cadangan yang dipulihkan.

  • Tambahkan pengecualian Antivirus yang diperlukan untuk file dan folder Azure Backup Server seperti yang didokumenkan di sini jika ada perangkat lunak Antivirus/Antimalware yang berjalan di Azure Backup Server. Saat menggunakan agen perlindungan DPM pada VM Azure VMware Solution apa pun untuk pencadangan aplikasi (misalnya, SQL, Sharepoint, dll.), nonaktifkan pemantauan dpmra.exe secara real time.

  • Konfigurasikan aturan NSG (Kelompok Keamanan Jaringan) yang sesuai pada subnet yang menghosting Azure Backup Server untuk memungkinkan komunikasi jaringan dari agen perlindungan DPM yang berjalan pada VM yang dilindungi di Azure VMware Solution. Agen perlindungan DPM berkomunikasi dengan Azure Backup Server pada port dinamis apa pun antara 1024 dan 65535.

  • Saat ini, Azure Backup Server tidak mendukung pemulihan lintas wilayah untuk cloud privat Azure VMware Solution. Lihat bagian solusi pencadangan mitra dan pemulihan bencana saat pemulihan Azure VMware Solution lintas wilayah diperlukan.

Pertimbangan desain pemulihan bencana

  • Selaraskan persyaratan bisnis dengan tujuan waktu pemulihan (RTO), kapasitas, dan tujuan titik pemulihan (RPO) untuk aplikasi. Rencanakan dan rancang sesuai untuk mencapai tujuan ini menggunakan teknologi replikasi yang paling tepat. Misalnya, mereplikasi database SQL secara asli menggunakan grup ketersediaan SQL AlwaysOn, atau menggunakan alat pemulihan bencana seperti VMware Site Recovery Manager.

  • Tentukan situs pemulihan bencana target untuk cloud privat Azure VMware Solution yang dilindungi. Situs ini memengaruhi alat pemulihan bencana mana yang cocok untuk lingkungan. Misalnya, jika Anda ingin memulihkan beban kerja Azure VMware Solution ke komputer virtual IaaS asli Azure, Anda dapat mempertimbangkan Azure Site Recovery atau Zerto.

  • Tentukan subset beban kerja Azure VMware Solution mana yang memerlukan perlindungan jika ada peristiwa pemulihan bencana. Pertimbangkan untuk mengategorikan beban kerja berdasarkan prioritas: P0 untuk beban kerja penting bisnis, dan P1, P2, P3 untuk beban kerja lain yang penting tetapi tidak penting bagi bisnis untuk beroperasi. Rencana kelangsungan bisnis pelanggan mendefinisikan tingkat prioritas, yang membantu mengontrol biaya yang terkait dengan implementasi pemulihan bencana.

  • Dalam kebanyakan kasus, lingkungan nonproduksi seperti dev, test, atau UAT tidak perlu melakukan failover ke situs sekunder. Anda harus menjalankan lampu pilot di situs sekunder dengan kapasitas yang berkurang untuk beban kerja produksi dan kritis untuk menghemat biaya. Untuk kapasitas lebih, Anda dapat memperluas skala untuk menambahkan host ESXi ke kluster selama peristiwa pemulihan bencana.

  • Untuk penyebaran lampu pilot terutama, pastikan Anda telah mengamankan semua kuota host yang diperlukan di situs sekunder sehingga Anda tidak perlu menunggu kapasitas yang diperlukan selama peluasan skala penuh. Lihat Meminta kuota host untuk Azure VMware Solution.

  • Siapkan peran domain fungsional, seperti pengendali domain Active Directory, di lingkungan sekunder.

  • Solusi dari mitra seperti JetStream dan Zerto umumnya tersedia dan divalidasi di Azure VMware Solution. Mereka mendukung sebagian besar skenario pemulihan bencana dan dapat memberikan pemulihan yang lebih cepat dengan RPO hampir nol.

  • VMware Site Recovery Manager, Jetstream, dan Zerto mendukung migrasi dari lokasi pihak ketiga ke Azure VMware Solution.

  • VMware HCX juga merupakan solusi pemulihan bencana yang hemat biaya. Namun, tidak disarankan untuk beban kerja produksi besar karena orkestrasi manual.

  • Untuk pemulihan bencana antara cloud privat Azure VMware Solution di wilayah Azure yang berbeda, Anda perlu mengaktifkan ExpressRoute Global Reach di antara kedua sirkuit ExpressRoute backend. Sirkuit ini membuat konektivitas cloud privat primer ke sekunder saat diperlukan untuk solusi seperti VMware SRM dan VMware HCX.

  • Untuk pemulihan bencana antara cloud privat Azure VMware Solution di wilayah Azure yang sama, Anda perlu mengaktifkan Interkoneksi Azure VMware Solution. Ini membuat tautan perutean antara manajemen dan jaringan beban kerja cloud privat Azure VMware Solution untuk komunikasi antara cloud. Pastikan bahwa ruang alamat IP yang dirutekan di setiap cloud privat unik dan tidak tumpang tindih.

  • Saat bekerja dengan pemulihan bencana, Anda dapat menggunakan ruang alamat IP sumber yang sama di wilayah Azure utama dan wilayah Azure sekunder. Namun, diperlukan upaya desain dan rekayasa tambahan.

    • Pertahankan alamat IP yang sama: Komputer virtual di situs Azure VMware Solution sekunder dapat dipulihkan menggunakan alamat IP sumber yang sama dengan situs utama. Untuk metode ini, buat segmen VLAN atau NSX-T terisolasi di situs sekunder dan pastikan bahwa tidak ada VLAN atau segmen terisolasi ini yang terhubung ke lingkungan. Ubah rute pemulihan bencana Anda untuk mencerminkan bahwa subnet telah berpindah ke situs sekunder dan lokasi alamat IP baru. Meskipun metode ini berfungsi, metode ini juga menciptakan overhead rekayasa saat membidik pemulihan bencana yang sepenuhnya otomatis.

    • Gunakan alamat IP yang berbeda: Anda juga dapat menggunakan alamat IP yang berbeda untuk VM yang dipulihkan. Jika VM dipindahkan ke situs sekunder, rencana pemulihan dalam Manajer Site Recovery VMware merinci peta IP kustom. Pilih peta ini untuk perubahan alamat IP. VM dimunculkan di segmen NSX-T baru dan alamat IP baru ditetapkan. Alat ini dapat berbeda untuk solusi pemulihan bencana yang berbeda.

  • Faktor penting untuk skenario pemulihan bencana parsial dan penuh:

    • VMware Site Recovery Manager mendukung pemulihan parsial, yang hanya memulihkan subset komputer virtual, dan pemulihan bencana penuh. Antara dua situs Azure VMware Solution di wilayah 1 dan wilayah 2, semua atau beberapa VM dapat gagal.

    • Persyaratan retensi alamat IP sumber untuk VM yang dipulihkan menentukan apakah pemulihan bencana parsial versus penuh dimungkinkan.

    • Untuk mempertahankan alamat IP sumber saat melakukan pemulihan bencana parsial di Site Recovery Manager, gateway subnet perlu berpindah ke situs sekunder.

    Catatan

    Pemulihan bencana siaga aktif tidak memerlukan peregangan Lapisan 2.

Rekomendasi desain pemulihan bencana

  • Gunakan VMware Site Recovery Manager saat bekerja dengan Azure VMware Solution di situs utama dan sekunder. Situs primer dan sekunder masing-masing juga dikenal sebagai situs yang dilindungi dan pemulihan.

    Gambaran umum tingkat tinggi replikasi vSphere berkelanjutan.

    Diagram that shows a high-level example of continuous vSphere replication between two Azure VMware Solution sites.

    Contoh terperinci replikasi vSphere berkelanjutan antara situs primer dan sekunder.

    Diagram that shows a detailed example of continuous vSphere replication between two Azure VMware Solution sites.

  • Untuk aplikasi penting bisnis, Zerto dan JetStream tersedia sebagai solusi pemulihan bencana untuk cloud privat Azure VMware Solution. JetStream dan Zerto dibangun di atas fondasi perlindungan data berkelanjutan (CDP), menggunakan VMware vSphere API untuk kerangka kerja pemfilteran I/O (VAIO), yang memungkinkan minimal atau mendekati tidak ada kehilangan data. Ini juga memungkinkan pemulihan bencana hemat biaya dengan menggunakan sumber daya minimal.

  • Gunakan Azure Site Recovery atau Zerto, jika komputer virtual Azure IaaS adalah target pemulihan bencana untuk cloud privat Azure VMware Solution.

  • Minimalkan input manual dengan menggunakan rencana pemulihan otomatis dalam setiap solusi pemulihan bencana masing-masing. Paket ini berguna saat bekerja dengan VMware Site Recovery Manager atau solusi mitra. Rencana pemulihan menggabungkan mesin dalam grup pemulihan untuk failover. Kemudian membantu menentukan proses pemulihan sistematis dengan membuat unit independen yang dapat gagal.

  • Siapkan uji asap atau latihan pemulihan bencana setidaknya setahun sekali untuk memastikan rencana pemulihan berfungsi seperti yang diharapkan. Kemampuan orkestrasi alat pemulihan bencana yang dipilih menentukan tingkat upaya yang terlibat dengan menjalankan latihan ini.

  • Gunakan pasangan regional geopolitik sebagai lingkungan pemulihan bencana sekunder. Beberapa manfaat pasangan regional adalah pemulihan wilayah yang diprioritaskan, pembaruan berurutan, isolasi fisik, dan residensi data.

  • Pertahankan ruang alamat yang berbeda untuk menghindari alamat IP yang tumpang tindih antara kedua situs. Misalnya, Anda dapat menggunakan 192.168.0.0/16 untuk wilayah 1 dan 10.0.0.0/16 untuk wilayah 2.

  • Gunakan konektivitas Jangkauan Global ExpressRoute antara cloud privat primer dan sekunder di berbagai wilayah. Lihat lebih banyak pertimbangan dan rekomendasi jaringan di area desain yang relevan.

Langkah berikutnya

Pelajari pertimbangan dan rekomendasi untuk penyebaran awal Azure VMware Solution dan panduan untuk otomatisasi operasional.

Otomatisasi platform untuk Azure VMware Solution