Mendesain arsitektur data yang didistribusikan secara geografis
Bagian akhir dari desain arsitektur aplikasi kami untuk dipertimbangkan adalah tingkat penyimpanan data. Kami ingin memastikan bahwa data dapat dibaca dan dapat ditulis dengan fungsionalitas penuh setelah kegagalan di seluruh wilayah.
Di portal pelacakan pengiriman, kami memilih untuk menggunakan Azure Front Door untuk mengirim semua permintaan ke App Services di wilayah US Timur. Jika wilayah AS Timur gagal, Front Door mendeteksi kegagalan, dan mengirim permintaan untuk menduplikasi komponen App Services di wilayah US Barat. Dalam arsitektur asli kawasan tunggal kami, kami menyimpan data relasional di Azure SQL Database dan data semi terstruktur di Cosmos DB. Sekarang, kita ingin memahami bagaimana kita dapat memastikan bahwa kedua database tetap tersedia jika wilayah US Timur gagal.
Di sini, kami mempelajari cara mereplikasi data antar wilayah, dan cara memastikan bahwa failover dapat terjadi dengan cepat, jika perlu.
Database Azure SQL
Untuk membuat implementasi multi-wilayah Azure SQL Database untuk menyimpan data relasional, kita dapat menggunakan:
- Replikasi Geo Aktif
- Grup failover otomatis
Replikasi Geo Aktif
Azure SQL Database dapat secara otomatis mereplikasi database dan semua perubahannya dari satu database ke database lainnya dengan fitur replikasi geografis aktif. Hanya server logis utama yang menghosting salinan database yang dapat ditulis. Kita dapat membuat hingga empat server logis lainnya yang menghosting salinan database baca-saja.
Untuk portal pelacakan pengiriman, buat database sekunder di wilayah US Barat dan konfigurasikan replikasi geografis dari wilayah US Timur. Ketika kegagalan regional terjadi, Front Door mengalihkan permintaan pengguna ke App Services di wilayah US Barat. App Services dan Azure Functions bisa mendapatkan akses ke data relasional karena salinan telah direplikasi ke wilayah US Barat.
Perubahan ini otomatis, tetapi ingat bahwa database sekunder di AS Barat baca-saja. Jika pengguna mencoba mengubah data, misalnya, dengan membuat pengiriman baru, kesalahan mungkin muncul. Kita dapat secara manual memulai failover ke AS Barat segera setelah kita melihat masalah dalam portal Azure. Jika kami ingin mengotomatiskan proses ini, pengembang kami dapat menulis kode yang memanggil failover metode di Azure SQL Database REST API.
Catatan
Instans terkelola Azure SQL Database tidak mendukung replikasi geografis Aktif. Instans terkelola dirancang untuk memudahkan migrasi data dari SQL Server lokal sambil menjaga keamanan. Jika Anda menggunakan instans terkelola, pertimbangkan untuk menggunakan grup failover sebagai gantinya.
Grup failover otomatis
Grup failover otomatis adalah sekelompok database di mana data direplikasi secara otomatis dari server sekunder utama ke satu atau lebih. Desain ini seperti replikasi geografis aktif dan menggunakan metode replikasi data yang sama. Namun, kita dapat mengotomatiskan respons terhadap kegagalan dengan mendefinisikan kebijakan.
Untuk portal pengiriman, kami membuat database sekunder di wilayah US Barat. Kami kemudian menambahkan kebijakan yang gagal atas replika utama database ke AS Barat jika kegagalan bencana terjadi di wilayah AS Timur. Jika itu terjadi, replika AS Barat secara otomatis menjadi database utama yang dapat ditulis, dan fungsionalitas penuh dipertahankan.
Pertimbangkan untuk menggunakan grup failover otomatis jika Anda ingin mengotomatiskan failover database yang dapat ditulis tanpa menulis kode kustom untuk memicunya. Selain itu, gunakan grup failover otomatis jika database Anda berjalan dalam instans terkelola Azure SQL Database.
Penting
Replikasi yang mendasari replikasi geografis aktif dan kelompok failover otomatis tidak sinkron. Pengakuan dikirim ke klien ketika perubahan diterapkan ke replika utama. Pada titik ini, transaksi dianggap selesai, dan terjadi replikasi. Jika kegagalan terjadi, perubahan terbaru yang dilakukan dalam database utama mungkin tidak direplikasi ke sekunder. Perlu diingat bahwa, setelah bencana, perubahan database terbaru mungkin telah hilang.
Azure Cosmos DB
Konfigurasi kami kurang kompleks dengan Azure Cosmos DB karena dirancang sebagai sistem database cloud multi-regional. Cosmos DB adalah database multi-model, mampu menyimpan data relasional, data semi terstruktur, dan bentuk data lainnya. Bahkan jika kita menjalankan Cosmos DB dalam satu wilayah, data direplikasi ke beberapa instans di berbagai domain kesalahan untuk ketersediaan terbaik.
Ketika kita membuat multi-wilayah akun Cosmos DB, kita dapat memilih dari mode berikut:
Akun multi-wilayah dengan beberapa wilayah tulis.
Dalam mode ini, semua salinan database selalu dapat ditulis. Jika suatu wilayah gagal, tidak perlu failover.
Akun multi-wilayah dengan satu wilayah tulis.
Dalam mode ini, hanya wilayah utama yang berisi database yang dapat ditulis. Data yang direplikasi ke wilayah sekunder berdasarkan baca-saja. Pembaruan dinonaktifkan secara default saat wilayah utama gagal. Namun, kita dapat memilih aktifkan failover otomatis sehingga Cosmos DB secara otomatis gagal atas salinan utama dan dapat ditulis dari database ke wilayah lain.
Penting
Di Cosmos DB, replikasi data sinkron. Ketika perubahan diterapkan, transaksi tidak dianggap selesai sampai direplikasi ke kuorum replika. Kemudian pengakuan dikirim ke klien. Ketika kegagalan terjadi, tidak ada perubahan terbaru yang hilang karena replikasi telah terjadi.