Bagikan melalui

Keandalan di Azure DocumentDB

Artikel ini berisi informasi terperinci tentang ketahanan regional dengan zona ketersediaan dan pemulihan bencana lintas wilayah dan kelangsungan bisnis untuk Azure DocumentDB.

Untuk gambaran umum arsitektur keandalan di Azure, lihat Keandalan Azure.

Dukungan zona ketersediaan

Zona ketersediaan adalah grup pusat data yang terpisah secara fisik dalam wilayah Azure. Ketika satu zona gagal, layanan dapat melakukan failover ke salah satu zona yang tersisa.

Untuk mendapatkan dukungan zona ketersediaan, Anda harus mengaktifkan Ketersediaan tinggi (HA).

HA menghindari waktu henti database dengan mempertahankan replika siaga dari setiap shard dalam kluster. Jika sebuah shard tidak berfungsi, Azure DocumentDB mengalihkan koneksi masuk dari shard yang mengalami kegagalan ke replika cadangannya.

Ketika HA diaktifkan di wilayah yang mendukung zona ketersediaan, shard replika HA disediakan di zona ketersediaan yang berbeda dari shard primernya. Replika HA tidak menerima permintaan dari klien kecuali shard utama mereka gagal.

Jika HA dinonaktifkan, setiap shard memiliki penyimpanan redundan lokal (LRS) sendiri dengan tiga replika sinkron yang dikelola oleh layanan Azure Storage. Jika ada satu kegagalan replika, layanan Azure Storage mendeteksi kegagalan, dan secara transparan membuat ulang data yang relevan. Untuk ketahanan penyimpanan LRS, lihat Ringkasan opsi redundansi. Namun, jika suatu wilayah gagal, Anda menghadapi risiko waktu henti yang lama dan kemungkinan kehilangan data.

Membuat sumber daya dengan zona ketersediaan diaktifkan

Untuk mengaktifkan zona ketersediaan, Anda harus mengaktifkan Ketersediaan tinggi (HA) saat membuat kluster atau di bagian Skala kluster yang ada di portal Azure.

Pemulihan bencana lintas wilayah dan kelangsungan bisnis

Pemulihan bencana (DR) mengacu pada praktik yang digunakan organisasi untuk pulih dari peristiwa berdampak tinggi, seperti bencana alam atau penyebaran gagal yang mengakibatkan waktu henti dan kehilangan data. Terlepas dari penyebabnya, obat terbaik untuk bencana adalah rencana DR yang terdefinisi dan teruji dengan baik dan desain aplikasi yang secara aktif mendukung DR. Sebelum Anda mulai membuat rencana pemulihan bencana, lihat rekomendasi untuk merancang strategi pemulihan bencana.

Untuk DR, Microsoft menggunakan model tanggung jawab bersama . Dalam model ini, Microsoft memastikan bahwa infrastruktur dasar dan layanan platform tersedia. Namun, banyak layanan Azure tidak secara otomatis mereplikasi data atau beralih dari wilayah yang gagal untuk mereplikasi ke wilayah lain yang tersedia. Untuk layanan tersebut, Anda bertanggung jawab untuk menyiapkan rencana pemulihan bencana yang berfungsi untuk beban kerja Anda. Sebagian besar layanan yang berjalan di penawaran platform as a service (PaaS) Azure menyediakan fitur dan panduan untuk mendukung DR. Anda dapat menggunakan fitur khusus layanan untuk mendukung pemulihan cepat dan membantu mengembangkan rencana DR Anda.

Azure DocumentDB tidak menyediakan failover otomatis bawaan atau pemulihan bencana. Merencanakan ketersediaan tinggi adalah langkah penting ketika solusi Anda berkembang pesat.

Pemulihan bencana dalam geografi wilayah tunggal

Untuk memaksimalkan waktu aktif Anda, rencanakan ke depan untuk menjaga kelangsungan bisnis dan mempersiapkan pemulihan bencana dengan Azure DocumentDB.

Meskipun layanan Azure dirancang untuk memaksimalkan waktu aktif, pemadaman layanan yang tidak diencana mungkin terjadi. Rencana pemulihan bencana memastikan bahwa Anda memiliki strategi untuk menangani pemadaman layanan regional.

Azure DocumentDB secara otomatis mengambil cadangan data Anda secara berkala. Pencadangan otomatis diambil tanpa mempengaruhi kinerja atau ketersediaan operasi database. Semua cadangan dilakukan secara otomatis di latar belakang dan disimpan secara terpisah dari data sumber dalam layanan penyimpanan. Pencadangan otomatis ini berguna dalam skenario ketika Anda secara tidak sengaja menghapus atau memodifikasi sumber daya dan nantinya memerlukan versi asli.

Pencadangan otomatis dipertahankan dalam berbagai interval berdasarkan apakah kluster saat ini aktif atau baru dihapus.

Jangka waktu retensi
Kluster aktif 35 hari
Kluster yang dihapus 7 hari

Desain untuk ketersediaan tinggi

Ketersediaan tinggi (HA) harus diaktifkan untuk kluster Azure DocumentDB penting yang menjalankan beban kerja produksi. Dalam kluster yang diaktifkan HA (ketersediaan tinggi), setiap shard berfungsi sebagai utama bersama dengan shard standby aktif yang disediakan di zona ketersediaan lain. Replikasi antara shard primer dan sekunder bersifat sinkron sebagai pengaturan awal. Setiap modifikasi pada database dipertahankan pada shard primer dan sekunder (siaga panas) sebelum respons dari database diterima.

Layanan ini menjalankan pemeriksaan kesehatan dan heartbeat ke setiap pecahan primer dan sekunder kluster. Jika shard utama menjadi tidak tersedia karena gangguan wilayah atau regional, shard sekunder secara otomatis dipromosikan menjadi shard utama yang baru dan shard sekunder baru akan dibuat untuk shard utama yang baru. Selain itu, jika shard sekunder menjadi tidak tersedia, layanan secara otomatis membuat shard sekunder baru dengan salinan lengkap data dari primer.

Jika layanan memicu failover dari shard primer ke shard sekunder, koneksi dirutekan secara otomatis dan mulus ke shard primer baru.

Replikasi sinkron antara pecahan primer dan sekunder menjamin tidak ada kehilangan data jika ada failover.

Langkah selanjutnya

  • Last updated on