Membuat semua hal menjadi berlebihan

Membangun redundansi ke dalam aplikasi Anda, untuk menghindari satu titik kegagalan

Rute aplikasi tangguh di sekitar kegagalan. Mengidentifikasi jalur penting dalam aplikasi Anda. Apakah ada redundansi di setiap titik jalur? Ketika subsistem gagal, apakah aplikasi akan gagal ke hal lain?

Rekomendasi

Pertimbangkan persyaratan bisnis. Jumlah redundansi yang dibangun ke dalam sistem dapat mempengaruhi biaya dan kerumitan. Arsitektur Anda harus diinformasikan oleh persyaratan bisnis Anda, seperti tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO). Anda juga harus mempertimbangkan persyaratan performa Anda, dan kemampuan tim Anda untuk mengelola serangkaian sumber daya yang kompleks.

Pertimbangkan arsitektur multi-zona dan multi-wilayah. Pastikan Anda memahami bagaimana zona dan wilayah ketersediaan memberikan ketahanan dan serangkaian tradeoff arsitektur yang berbeda.

Zona ketersediaan Azure adalah kumpulan pusat data yang terisolasi dalam suatu wilayah. Dengan menggunakan zona ketersediaan, Anda dapat tahan terhadap kegagalan satu pusat data atau seluruh zona ketersediaan. Anda dapat menggunakan zona ketersediaan untuk melakukan tradeoff antara biaya, mitigasi risiko, performa, dan pemulihan. Misalnya, saat Anda menggunakan layanan redundansi zona dalam arsitektur Anda, Azure menyediakan replikasi data otomatis dan failover antara instans yang dipisahkan secara geografis, yang mengurangi berbagai jenis risiko.

Jika Anda memiliki beban kerja misi penting dan perlu mengurangi risiko pemadaman di seluruh wilayah, pertimbangkan penyebaran multi-wilayah. Meskipun penyebaran multi-wilayah mengisolasi Anda terhadap bencana regional, penyebaran tersebut dikenakan biaya. Penyebaran multi-wilayah lebih mahal daripada penyebaran wilayah tunggal, dan lebih rumit untuk dikelola. Anda akan memerlukan prosedur operasional untuk menangani failover dan failback. Bergantung pada persyaratan RPO Anda, Anda mungkin perlu menerima performa yang sedikit lebih rendah untuk mengaktifkan replikasi data lintas wilayah. Biaya dan kompleksitas tambahan mungkin dibenarkan untuk beberapa skenario bisnis.

Tip

Untuk banyak beban kerja, arsitektur zona-redundan menyediakan serangkaian tradeoff terbaik. Pertimbangkan arsitektur multi-wilayah jika persyaratan bisnis Anda menunjukkan bahwa Anda perlu mengurangi risiko pemadaman di seluruh wilayah yang tidak mungkin, dan jika Anda siap untuk menerima tradeoff yang terlibat dalam pendekatan tersebut.

Untuk mempelajari selengkapnya tentang cara merancang solusi Anda untuk menggunakan zona dan wilayah ketersediaan, lihat Rekomendasi untuk menggunakan zona dan wilayah ketersediaan.

Tempatkan Mesin Virtual di belakang load balancer. Jangan gunakan satu Mesin Virtual untuk beban kerja yang sangat penting. Sebagai gantinya, tempatkan beberapa Mesin Virtual di belakang load balancer. Jika ada Mesin Virtual yang tidak tersedia, load balancer mendistribusikan lalu lintas ke Mesin Virtual sehat lainnya. Untuk mempelajari cara menyebarkan konfigurasi ini, lihat [Beberapa VM untuk skalabilitas dan ketersediaan][cetak biru multi-vm].

Replikasi database. Azure SQL Database dan Azure Cosmos DB secara otomatis mereplikasi data dalam suatu wilayah, dan dapat dikonfigurasi untuk mereplikasi di seluruh zona ketersediaan untuk ketahanan yang lebih tinggi. Anda juga dapat memilih untuk mengaktifkan replikasi geografis di seluruh wilayah. Replikasi geografis untuk Azure SQL Database dan Azure Cosmos DB membuat replika data sekunder yang dapat dibaca di satu atau beberapa wilayah sekunder. Jika pemadaman terjadi di wilayah utama, database dapat melakukan failover ke wilayah sekunder untuk penulisan. Bergantung pada konfigurasi replikasi, Anda mungkin mengalami beberapa kehilangan data dari transaksi yang tidak direplikasi.

Jika Anda menggunakan solusi database IaaS, pilih solusi yang mendukung replikasi dan failover, seperti grup ketersediaan AlwaysOn SQL Server.

Partisi untuk ketersediaan. Partisi database sering digunakan untuk meningkatkan skalabilitas, tetapi juga dapat meningkatkan ketersediaan. Jika satu shard jatuh, shard lainnya masih dapat dijangkau. Kegagalan dalam satu shard hanya akan mengganggu sebagian dari total transaksi.

Solusi multi-wilayah

Diagram berikut memperlihatkan aplikasi multi-wilayah yang menggunakan Azure Traffic Manager untuk menangani failover.

Jika Anda menggunakan Traffic Manager dalam solusi multi-wilayah, pertimbangkan rekomendasi berikut:

Sinkronkan failover depan dan belakang. Gunakan Traffic Manager untuk melakukan failover di ujung depan. Jika frontend menjadi tidak dapat dijangkau di satu wilayah, Traffic Manager akan mengarahkan permintaan baru ke wilayah sekunder. Bergantung pada komponen backend dan solusi database Anda, Anda mungkin perlu mengoordinasikan failover pada layanan dan database backend Anda.

Gunakan failover otomatis tetapi failback manual. Gunakan Traffic Manager untuk failover otomatis, tetapi tidak untuk failback otomatis. Failback otomatis membawa risiko bahwa Anda mungkin beralih ke wilayah utama sebelum wilayah tersebut benar-benar sehat. Sebaliknya, verifikasi bahwa semua subsistem aplikasi sehat sebelum melakukan fallback secara manual. Juga, tergantung pada database, Anda mungkin perlu memeriksa konsistensi data sebelum melakukan fallback.

Untuk mencapai hal ini, nonaktifkan titik akhir utama Traffic Manager setelah failover. Perhatikan bahwa jika interval pemantauan pemeriksaan pendek dan jumlah kegagalan yang ditoleransi kecil, failover serta failback akan terjadi dalam waktu singkat. Dalam beberapa kasus, menonaktifkan tidak akan selesai tepat waktu. Untuk menghindari failback yang tidak dikonfirmasi, pertimbangkan juga menerapkan titik akhir kesehatan yang dapat memverifikasi bahwa semua subsistem sehat. Lihat pola Pemantauan Titik Akhir Kesehatan.

Sertakan redundansi untuk Traffic Manager. Traffic Manager adalah titik kegagalan yang memungkinkan. Tinjau SLA Traffic Manager, dan tentukan apakah hanya menggunakan Traffic Manager akan memenuhi persyaratan bisnis Anda untuk ketersediaan tinggi. Jika tidak, pertimbangkan untuk menambahkan solusi manajemen lalu lintas lain sebagai failback. Jika layanan Azure Traffic Manager gagal, ubah data CNAME Anda di DNS untuk mengarah ke layanan manajemen lalu lintas lainnya.