Bagikan melalui

Keandalan di Azure Cosmos DB untuk MongoDB vCore

  • Artikel

BERLAKU UNTUK: MongoDB vCore

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

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

Dukungan zona ketersediaan

Zona ketersediaan Azure adalah setidaknya tiga grup pusat data yang terpisah secara fisik dalam setiap wilayah Azure. Pusat data dalam setiap zona dilengkapi dengan infrastruktur daya, pendinginan, dan jaringan independen. Dalam kasus kegagalan zona lokal, zona ketersediaan dirancang sehingga jika satu zona terpengaruh, layanan regional, kapasitas, dan ketersediaan tinggi didukung oleh dua zona yang tersisa.

Kegagalan dapat berkisar dari kegagalan perangkat lunak dan perangkat keras hingga peristiwa seperti gempa bumi, banjir, dan kebakaran. Toleransi terhadap kegagalan dicapai dengan redundansi dan isolasi logis layanan Azure. Untuk informasi selengkapnya tentang zona ketersediaan di Azure, lihat Wilayah dan zona ketersediaan.

Layanan berkemampuan zona ketersediaan Azure dirancang untuk memberikan tingkat keandalan dan fleksibilitas yang tepat. Mereka dapat dikonfigurasi dalam dua cara. Mereka dapat berupa zona redundan,dengan replikasi otomatis di seluruh zona, atau zonal, dengan instans yang disematkan ke zona tertentu. Anda juga dapat menggabungkan pendekatan ini. Untuk informasi selengkapnya tentang arsitektur zonal vs. zona-redundan, lihat Rekomendasi untuk menggunakan zona dan wilayah ketersediaan.

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 shard tidak berfungsi, Azure Cosmos DB untuk MongoDB vCore mengalihkan koneksi masuk dari shard yang gagal ke replika siaganya.

Ketika KETERSEDIAAN TINGGI diaktifkan di wilayah yang mendukung zona ketersediaan, pecahan replika HA disediakan di zona ketersediaan yang berbeda dari pecahan utamanya. Replika HA tidak menerima permintaan dari klien kecuali pecahan 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 durabilitas penyimpanan LRS, lihat Ringkasan opsi redundansi. Namun, dalam kasus kegagalan wilayah, Anda menjalankan risiko waktu henti yang luas 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) adalah tentang pemulihan 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 berpikir tentang membuat rencana pemulihan bencana Anda, lihat Rekomendasi untuk merancang strategi pemulihan bencana.

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

Azure Cosmos DB for MongoDB vCore tidak menyediakan failover otomatis bawaan atau pemulihan bencana. Merencanakan ketersediaan tinggi adalah langkah penting saat solusi Anda diskalakan.

Pemulihan bencana dalam geografi wilayah tunggal

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

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 Cosmos DB for MongoDB vCore 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.

Periode retensi
Kluster aktif 35 hari
Kluster yang dihapus 7 hari

Desain untuk ketersediaan tinggi

Ketersediaan tinggi (HA) harus diaktifkan untuk azure Cosmos DB penting untuk kluster MongoDB vCore yang menjalankan beban kerja produksi. Dalam kluster dengan ketersediaan tinggi, setiap shard berfungsi sebagai primer bersama dengan shard siaga panas yang disediakan di zona ketersediaan lain. Replikasi antara shard primer dan sekunder sinkron secara default. Setiap modifikasi pada database dipertahankan pada shard primer dan sekunder (siaga panas) sebelum respons dari database diterima.

Layanan ini mempertahankan pemeriksaan kesehatan dan heartbeat ke setiap pecahan utama dan sekunder kluster. Jika pecahan utama menjadi tidak tersedia karena pemadaman zona atau regional, shard sekunder secara otomatis dipromosikan untuk menjadi primer baru dan pecahan sekunder berikutnya dibangun untuk primer 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 sekunder, koneksi dirutekan dengan mulus di bawah penutup ke shard utama baru.

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

Langkah berikutnya