Keberlangsungan bisnis dan pemulihan bencana

  • Artikel

Beban kerja aplikasi organisasi dan perusahaan memiliki persyaratan tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO). Desain kelangsungan bisnis dan pemulihan bencana (BCDR) yang efektif menyediakan kemampuan tingkat platform yang memenuhi persyaratan ini. Untuk merancang kemampuan BCDR, penuhi persyaratan pemulihan bencana platform (DR).

Pertimbangan Desain

Pertimbangkan faktor-faktor berikut saat merancang BCDR untuk beban kerja aplikasi:

  • Persyaratan ketersediaan aplikasi dan data:

    • Persyaratan RTO dan RPO untuk setiap beban kerja.
    • Dukungan untuk pola ketersediaan aktif-aktif dan aktif-pasif.

  • BCDR sebagai layanan untuk layanan platform-as-a-service (PaaS):

    • Dukungan fitur DR asli dan ketersediaan tinggi (HA).
    • Kemampuan geo-replikasi dan DR untuk layanan PaaS.

  • Dukungan penyebaran berbagai wilayah untuk failover, dengan kedekatan komponen untuk performa.

  • Operasi aplikasi dengan fungsi berkurang atau performa yang menurun selama penonaktifan.

  • Kesesuaian beban kerja untuk Zona Ketersediaan atau kumpulan ketersediaan:

    • Berbagi data dan dependensi antar zona.
    • Zona Ketersediaan dibandingkan dengan kumpulan ketersediaan berdampak pada pembaruan domain.
    • Persentase beban kerja yang dapat berada dalam pemeliharaan secara bersamaan.
    • Dukungan Zona Ketersediaan untuk unit penyimpanan stok (SKU) mesin virtual (VM) tertentu. Misalnya, Penyimpanan Disk Ultra Azure perlu menggunakan Zona Ketersediaan.

  • Pencadangan yang konsisten untuk aplikasi dan data:

    • Snapshot mesin virtual.
    • Vault Layanan Pemulihan Azure Backup.
    • Batas langganan membatasi jumlah vault Recovery Services dan ukuran setiap vault.

  • Konektivitas jaringan jika failover terjadi:

    • Perencanaan kapasitas bandwidth untuk Azure ExpressRoute.
    • Perutean lalu lintas selama penonaktifan regional, zona, atau jaringan.

  • Failover yang direncanakan dan tidak direncanakan:

    • Persyaratan konsistensi alamat IP, dan potensi kebutuhan untuk mempertahankan alamat IP setelah failover dan failback.
    • Mempertahankan kemampuan Azure DevOps teknik.
    • DR Azure Key Vault untuk kunci aplikasi, sertifikat, dan rahasia.

  • Residensi data:

    • Pahami panduan dalam negeri/wilayah untuk residensi data yang menentukan apakah data harus disimpan dalam batas negara atau wilayah. Panduan ini memengaruhi desain Anda untuk replikasi lintas wilayah.
    • Wilayah Azure yang berada dalam geografi yang sama dengan set yang diaktifkan dapat membantu replikasi lintas wilayah untuk memenuhi persyaratan residensi data seperti persyaratan pajak dan penegakan hukum. Untuk informasi selengkapnya, lihat Replikasi lintas wilayah Azure.

Rekomendasi desain

Praktik desain berikut mendukung BCDR untuk beban kerja aplikasi:

  • Gunakan Azure Site Recovery untuk skenario Azure ke DR mesin virtual Azure.

    Site Recovery menggunakan replikasi real-time dan otomatisasi pemulihan untuk mereplikasi beban kerja di seluruh wilayah. Kemampuan platform bawaan untuk beban kerja mesin virtual memenuhi persyaratan RPO dan RTO yang rendah. Anda dapat menggunakan Site Recovery untuk menjalankan latihan pemulihan tanpa memengaruhi beban kerja produksi. Anda juga dapat menggunakan Azure Policy untuk mengaktifkan replikasi dan mengaudit perlindungan mesin virtual.

  • Gunakan kemampuan PaaS DR asli.

    Fitur PaaS bawaan menyederhanakan otomatisasi desain dan penyebaran untuk replikasi dan failover dalam arsitektur beban kerja. Organisasi yang menentukan standar layanan juga dapat mengaudit dan menegakkan konfigurasi layanan melalui Azure Policy.

  • Gunakan kemampuan pencadangan asli Azure.

    Fitur pencadangan Azure Backup dan asli PaaS tidak lagi membutuhkan perangkat lunak dan infrastruktur pencadangan pihak ketiga. Seperti fitur asli lainnya, Anda dapat mengatur, mengaudit, dan menerapkan konfigurasi cadangan dengan Azure Policy untuk memastikan kepatuhan terhadap persyaratan organisasi.

  • Gunakan beberapa wilayah dan lokasi peering untuk konektivitas ExpressRoute.

    Arsitektur jaringan hibrid yang berlebihan dapat membantu memastikan konektivitas lintas tempat tanpa gangguan jika penonaktifan memengaruhi wilayah Azure atau lokasi penyedia peering.

  • Hindari menggunakan rentang alamat IP yang tumpang tindih dalam jaringan produksi dan DR.

    Jaringan produksi dan DR yang memiliki alamat IP yang tumpang tindih memerlukan proses failover yang dapat mempersulit dan menunda failover aplikasi. Jika memungkinkan, rencanakan arsitektur jaringan BCDR yang menyediakan konektivitas bersamaan ke semua situs.