Kelangsungan bisnis dan pemulihan bencana untuk analitik skala cloud

  • Artikel

Saat Anda merancang arsitektur untuk layanan cloud, pertimbangkan persyaratan ketersediaan Anda dan cara merespons potensi gangguan dalam layanan. Masalah dapat dilokalkan ke instans tertentu atau di seluruh wilayah. Memiliki rencana untuk keduanya adalah hal yang penting. Bergantung pada tujuan waktu pemulihan Anda dan tujuan titik pemulihan, Anda dapat memilih strategi yang agresif untuk ketersediaan tinggi dan pemulihan bencana.

Ketersediaan tinggi dan pemulihan bencana kadang-kadang dapat dikombinasikan. Kedua bidang ini memiliki strategi yang sedikit berbeda, terutama dalam hal data. Untuk mempelajari selengkapnya, lihat Kerangka kerja Microsoft Azure Well-Architected dan prinsip keandalannya.

Alih-alih mencoba mencegah kegagalan, terimalah di awal bahwa kegagalan dapat dan memang terjadi. Meminimalkan efek dari setiap komponen kegagalan tunggal dalam siklus hidup. Toleransi Anda terhadap biaya, tujuan titik pemulihan, dan tujuan waktu pemulihan menentukan jenis solusi yang akan diterapkan.

Strategi pencadangan

Banyak strategi alternatif tersedia untuk menerapkan komputasi terdistribusi di seluruh wilayah. Strategi harus disesuaikan dengan persyaratan bisnis dan keadaan aplikasi Anda. Di tingkat tinggi, pendekatan jatuh ke dalam kategori berikut:

  • Pencadangan dan pemulihan: Pulihkan aplikasi database dari salinan cadangan terakhir sebelum bencana. Pendekatan ini umumnya digunakan setelah korupsi data atau penghapusan yang tidak disengaja.

  • Penyebaran ulang saat bencana: Menyebarkan ulang aplikasi dari awal pada saat bencana. Pendekatan ini sesuai untuk aplikasi non-kritis yang tidak memerlukan waktu pemulihan yang terjamin.

  • Cadangan hangat (aktif/pasif): Membuat layanan sekunder yang di-host di wilayah alternatif. Menyebarkan peran untuk menjamin kapasitas minimal. Peran tersebut tidak menerima lalu lintas produksi. Pendekatan ini berguna untuk aplikasi yang belum dirancang untuk mendistribusikan lalu lintas ke seluruh wilayah.

  • Cadangan panas (aktif/aktif): Merancang aplikasi untuk menerima beban produksi di beberapa wilayah. Anda dapat mengonfigurasi layanan cloud di setiap wilayah untuk kapasitas yang lebih tinggi daripada yang diperlukan untuk tujuan pemulihan bencana. Sebaliknya, Anda dapat memperluas skala layanan cloud seperlunya pada saat bencana dan failover.

    Pendekatan ini membutuhkan investasi dalam desain aplikasi, tetapi memiliki keuntungan. Ini menawarkan waktu pemulihan yang singkat dan terjamin. Ada pengujian berkelanjutan dari semua lokasi pemulihan dan penggunaan kapasitas yang efisien. Untuk aplikasi database, pendekatan ini mencakup penyeimbang beban untuk dua database yang disinkronkan dengan satu titik koneksi.

Pemulihan bencana dan ketersediaan tinggi untuk layanan Azure

Bagian berikut membahas berbagai layanan Azure.

Azure Cosmos DB

Untuk gambaran umum ketersediaan tinggi dengan Azure Cosmos DB, lihat Cara Azure Cosmos DB menyediakan ketersediaan tinggi.

Azure Data Factory

Integrasi data dan produk data kemungkinan memiliki repositori Azure DevOps yang terkait dengan Azure Data Factory. Anda dapat menyebarkan alur ke Data Factory lain dengan waktu henti minimal. Untuk menggunakan perangkat lunak kontrol versi kode selain dari repositori GitHub dan Azure DevOps, gunakan Azure Data Factory SDK untuk membuat alur dan objek Azure Data Factory lainnya.

Azure Data Lake

Azure Data Lake Storage Gen2 sudah mendukung 3x replikasi untuk menjaga dari kegagalan perangkat keras yang dilokalkan. Opsi replikasi lain, seperti penyimpanan redundansi zona (zone-redundant storage/ZRS) atau penyimpanan zona redundansi geografis (geo-zone-redundant storage/GZRS), meningkatkan ketersediaan tinggi. Penyimpanan redundansi geografis (geo-redundant storage/GRS) dan penyimpanan redundansi geografis akses baca (read-access geo-redundant storage/RA-GRS) meningkatkan pemulihan bencana. Untuk ketersediaan tinggi, jika terdapat gangguan layanan, beban kerja memerlukan akses ke data terbaru secepat mungkin. Beban kerja dapat beralih ke instans yang direplikasi secara lokal atau ke wilayah baru.

Akun penyimpanan yang dikonfigurasi sebagai RA-GRS atau GRS dapat menjadi bagian dari rencana pemulihan bencana tetapi memerlukan uji tuntas menganalisis Tujuan Titik Pemulihan (RPO) dan Tujuan Waktu Pemulihan (RTO) dan meninjau opsi lain seperti skenario beban ganda yang menyalin data ke dua wilayah Azure yang berbeda.

Setiap zona pendaratan data harus memiliki tujuan titik pemulihan untuk produk datanya. Setiap zona pendaratan data harus memiliki strategi replikasi yang ditentukan untuk kasus penggunaannya.

Catatan

Failover akun yang dikelola pelanggan belum didukung di akun yang memiliki namespace layanan hierarkis (Azure Data Lake Storage Gen2).

Jika terjadi bencana yang memengaruhi wilayah utama, maka Microsoft akan mengelola failover akun yang memiliki namespace layanan hierarkis.

Untuk informasi selengkapnya, lihat Pemulihan bencana dan failover akun penyimpanan.

Azure Databricks

Untuk gambaran umum tentang arsitektur pemulihan bencana untuk kluster Azure Databricks, lihat Pemulihan bencana regional untuk kluster Azure Databricks.

Pembelajaran Mesin Azure

Untuk gambaran umum ketersediaan tinggi dengan Azure Machine Learning, lihat Failover untuk kelangsungan bisnis dan pemulihan bencana.

Azure Key Vault

Azure Key Vault menyediakan fitur untuk membantu Anda mempertahankan ketersediaan dan mencegah kehilangan data. Cadangkan rahasia hanya jika Anda memiliki pembenaran bisnis yang kritis. Mencadangkan rahasia di brankas kunci Anda dapat memperkenalkan tantangan operasional seperti memelihara beberapa set log, izin, dan cadangan saat rahasia kedaluwarsa atau berputar. Untuk informasi selengkapnya, lihat Cadangan Azure Key Vault.

Key Vault menjaga ketersediaan dalam skenario bencana. Layanan ini melakukan failover terhadap permintaan ke wilayah yang dipasangkan tanpa intervensi dari pengguna. Untuk informasi selengkapnya, lihat Ketersediaan dan redundansi Azure Key Vault. Sebagai alternatif, Anda dapat mempertimbangkan untuk menyimpan rahasia dan artefak Key Vault lainnya di brankas sekunder dengan izin yang sesuai. Pola ini mungkin cocok untuk aplikasi yang memerlukan brankas berada di wilayah yang sama dengan aplikasi.

Azure SQL Database

Untuk gambaran umum kelangsungan bisnis dengan Azure SQL Database, lihat Gambaran umum kelangsungan bisnis dengan Azure SQL Database.

Azure Synapse Analytics

Untuk gambaran umum tentang kelangsungan bisnis dengan Azure Synapse Analytics, lihat Ketersediaan tinggi untuk Azure Synapse Analytics.

Langkah berikutnya