Rekomendasi untuk merancang untuk redundansi
Berlaku untuk rekomendasi daftar periksa Keandalan Azure Well-Architected Framework ini:
| RE:05 | Tambahkan redundansi pada tingkat yang berbeda, terutama untuk aliran kritis. Terapkan redundansi ke tingkat komputasi, data, jaringan, dan infrastruktur lainnya sesuai dengan target keandalan yang diidentifikasi. |
|---|
Panduan terkait: Desain | multiregional yang sangat tersedia Menggunakan zona dan wilayah ketersediaan
Panduan ini menjelaskan rekomendasi untuk menambahkan redundansi di seluruh alur kritis pada lapisan beban kerja yang berbeda, yang mengoptimalkan ketahanan. Penuhi persyaratan target keandalan yang Anda tentukan dengan menerapkan tingkat redundansi yang tepat ke komputasi, data, jaringan, dan tingkat infrastruktur lainnya. Terapkan redundansi ini untuk memberi beban kerja Anda fondasi yang kuat dan andal untuk dibangun. Saat Anda membangun beban kerja tanpa redundansi infrastruktur, ada risiko tinggi dari waktu henti yang diperpanjang karena potensi kegagalan.
Definisi
| Istilah | Definisi |
|---|---|
| Redundansi geografis | Implementasi beberapa instans identik dari komponen beban kerja. |
| Persistensi poliglot | Konsep penggunaan teknologi penyimpanan yang berbeda oleh aplikasi atau solusi yang sama untuk memanfaatkan kemampuan terbaik dari setiap komponen. |
| Konsistensi data | Ukuran bagaimana sinkronisasi atau di luar sinkronisasi himpunan data tertentu berada di beberapa penyimpanan. |
| Partisi | Proses pembagian data secara fisik menjadi penyimpanan data terpisah. |
| Shard | Strategi pemartisian database horizontal yang mendukung beberapa instans penyimpanan dengan skema umum. Data tidak direplikasi dalam semua instans. |
Strategi desain utama
Dalam konteks keandalan, gunakan redundansi untuk berisi masalah yang memengaruhi satu sumber daya dan memastikan bahwa masalah tersebut tidak memengaruhi keandalan seluruh sistem. Gunakan informasi yang Anda identifikasi tentang alur penting dan target keandalan Anda untuk membuat keputusan berdasarkan informasi yang diperlukan untuk redundansi setiap alur.
Misalnya, Anda mungkin memiliki beberapa simpul server web yang berjalan sekaligus. Kekritisan alur yang mereka dukung mungkin mengharuskan semuanya memiliki replika yang siap menerima lalu lintas jika ada masalah yang memengaruhi seluruh kumpulan, misalnya pemadaman regional. Atau, karena masalah skala besar jarang terjadi dan sangat mahal untuk menyebarkan seluruh set replika, Anda mungkin menyebarkan sejumlah replika terbatas sehingga alur beroperasi dalam keadaan terdegradasi sampai Anda menyelesaikan masalah.
Saat Anda merancang redundansi dalam konteks efisiensi performa, distribusikan beban di beberapa simpul redundan untuk memastikan bahwa setiap simpul berkinerja optimal. Dalam konteks keandalan, bangun dalam kapasitas cadangan untuk menyerap kegagalan atau kerusakan yang memengaruhi satu atau beberapa simpul. Pastikan kapasitas cadangan dapat menyerap kegagalan selama seluruh waktu yang diperlukan untuk memulihkan simpul yang terpengaruh. Dengan mengingat perbedaan ini, kedua strategi perlu bekerja sama. Jika Anda menyebarkan lalu lintas di dua node untuk performa dan keduanya berjalan pada pemanfaatan 60 persen dan satu node gagal, node Anda yang tersisa berisiko menjadi kewalahan karena tidak dapat beroperasi pada 120 persen. Sebarkan beban dengan simpul lain untuk memastikan bahwa target performa dan keandalan Anda ditingkatkan.
Tradeoffs:
- Lebih banyak redundansi beban kerja sama dengan lebih banyak biaya. Pertimbangkan untuk menambahkan redundansi dan meninjau arsitektur Anda secara teratur untuk memastikan bahwa Anda mengelola biaya, terutama ketika Anda menggunakan provisi berlebih. Ketika Anda menggunakan provisi berlebih sebagai strategi ketahanan, seimbangkan dengan strategi penskalaan yang terdefinisi dengan baik untuk meminimalkan inefisiensi biaya.
- Mungkin ada tradeoff performa ketika Anda membangun dalam tingkat redundansi yang tinggi. Misalnya, sumber daya yang tersebar di zona ketersediaan atau wilayah dapat memengaruhi performa karena Anda harus mengirim lalu lintas melalui koneksi latensi tinggi antara sumber daya redundan, seperti server web atau instans database.
- Alur yang berbeda dalam beban kerja yang sama mungkin memiliki persyaratan keandalan yang berbeda. Desain redundansi khusus alur berpotensi memperkenalkan kompleksitas ke dalam desain keseluruhan.
Desain arsitektur redundan
Pertimbangkan dua pendekatan saat Anda merancang arsitektur redundan: aktif-aktif atau aktif-pasif. Pilih pendekatan Anda tergantung pada kekritisan alur pengguna dan alur sistem yang didukung komponen infrastruktur. Dalam hal keandalan, desain aktif-aktif multi-wilayah membantu Anda mencapai tingkat keandalan setinggi mungkin, tetapi secara signifikan lebih mahal daripada desain pasif aktif. Memutuskan wilayah geografis yang sesuai menjadi pilihan penting berikutnya. Anda juga dapat menggunakan pendekatan desain ini untuk satu wilayah dengan menggunakan zona ketersediaan. Untuk informasi selengkapnya, lihat Rekomendasi untuk desain multi-wilayah yang sangat tersedia.
Stempel penyebaran dan unit skala
Baik Anda menyebarkan dalam model aktif-aktif atau pasif, ikuti pola desain Stempel Penyebaran untuk memastikan bahwa Anda menyebarkan beban kerja dengan cara yang dapat diulang dan dapat diskalakan. Stempel penyebaran adalah pengelompokan sumber daya yang diperlukan untuk mengirimkan beban kerja Anda ke subset tertentu dari pelanggan Anda. Misalnya, subset mungkin merupakan subset regional atau subset dengan semua persyaratan privasi data yang sama dengan beban kerja Anda. Anggap setiap stempel sebagai unit skala yang dapat Anda duplikat untuk menskalakan beban kerja Anda secara horizontal atau untuk melakukan penyebaran biru-hijau. Rancang beban kerja Anda dengan stempel penyebaran untuk mengoptimalkan implementasi aktif-aktif atau pasif Anda untuk beban ketahanan dan manajemen. Perencanaan untuk peluasan skala multi-wilayah juga penting untuk mengatasi potensi batasan kapasitas sumber daya sementara di suatu wilayah.
Zona ketersediaan dalam wilayah Azure
Baik Anda menyebarkan desain aktif-aktif atau pasif, manfaatkan zona ketersediaan dalam wilayah aktif untuk sepenuhnya mengoptimalkan ketahanan Anda. Banyak wilayah Azure menyediakan beberapa zona ketersediaan, yang merupakan grup pusat data yang dipisahkan dalam suatu wilayah. Bergantung pada layanan Azure, Anda dapat memanfaatkan zona ketersediaan dengan menyebarkan elemen beban kerja Anda secara berlebihan di seluruh zona atau menyematkan elemen ke zona tertentu. Untuk informasi selengkapnya, lihat Rekomendasi untuk menggunakan zona dan wilayah ketersediaan.
Menerapkan redundansi zona untuk sumber daya komputasi
Pilih layanan komputasi yang sesuai untuk beban kerja Anda. Bergantung pada jenis beban kerja yang Anda desain, mungkin ada beberapa opsi yang tersedia. Teliti layanan yang tersedia dan pahami jenis beban kerja mana yang paling berfungsi pada layanan komputasi tertentu. Misalnya, beban kerja SAP biasanya paling cocok untuk layanan komputasi infrastruktur sebagai layanan (IaaS). Untuk aplikasi dalam kontainer, tentukan fungsionalitas spesifik yang perlu Anda kontrol untuk menentukan apakah akan menggunakan Azure Kubernetes Service (AKS) atau solusi platform as a service (PaaS). Platform cloud Anda sepenuhnya mengelola layanan PaaS.
Gunakan opsi komputasi PaaS jika persyaratan Anda mengizinkannya. Azure sepenuhnya mengelola layanan PaaS, yang mengurangi beban manajemen Anda, dan tingkat redundansi yang didokumentasikan bawaan.
Gunakan Azure Virtual Machine Scale Sets jika Anda perlu menyebarkan komputer virtual (VM). Dengan Virtual Machine Scale Sets, Anda dapat secara otomatis menyebarkan komputasi Anda secara merata di seluruh zona ketersediaan.
Jaga agar lapisan komputasi Anda tetap bersih dari status apa pun karena simpul individual yang melayani permintaan mungkin dihapus, disalahkan, atau diganti kapan saja.
Gunakan layanan zona-redundan jika memungkinkan untuk memberikan ketahanan yang lebih tinggi tanpa meningkatkan beban operasional Anda.
Sumber daya penting provisi berlebihan untuk mengurangi kegagalan instans redundan, bahkan sebelum operasi penskalaan otomatis dimulai, sehingga sistem terus beroperasi setelah kegagalan komponen. Hitung efek kesalahan yang dapat diterima saat Anda memasukkan provisi berlebihan ke dalam desain redundansi Anda. Seperti halnya proses pengambilan keputusan redundansi Anda, target keandalan dan keputusan tradeoff keuangan Anda menentukan sejauh mana Anda menambahkan kapasitas cadangan dengan provisi berlebih. Provisi berlebih secara khusus mengacu pada penskalaan, yang berarti menambahkan instans tambahan dari jenis sumber daya komputasi tertentu, daripada meningkatkan kemampuan komputasi instans tunggal apa pun. Misalnya, jika Anda mengubah VM dari SKU tingkat lebih rendah ke SKU tingkat yang lebih tinggi.
Sebarkan layanan IaaS secara manual atau melalui otomatisasi di setiap zona ketersediaan atau wilayah tempat Anda ingin menerapkan solusi Anda. Beberapa layanan PaaS memiliki kemampuan bawaan yang secara otomatis direplikasi di seluruh zona dan wilayah ketersediaan.
Menerapkan redundansi zona untuk sumber daya data
Tentukan apakah replikasi data sinkron atau asinkron diperlukan untuk fungsionalitas beban kerja Anda. Untuk membantu Anda membuat penentuan ini, lihat Rekomendasi untuk menggunakan zona dan wilayah ketersediaan.
Pertimbangkan tingkat pertumbuhan data Anda. Untuk perencanaan kapasitas, rencanakan pertumbuhan data, retensi data, dan pengarsipan untuk memastikan persyaratan keandalan Anda terpenuhi saat jumlah data dalam solusi Anda meningkat.
Distribusikan data secara geografis, seperti yang didukung oleh layanan Anda, untuk meminimalkan efek kegagalan yang dilokalkan secara geografis.
Replikasi data di seluruh wilayah geografis untuk memberikan ketahanan terhadap pemadaman regional dan kegagalan bencana.
Mengotomatiskan failover setelah kegagalan instans database. Anda dapat mengonfigurasi failover otomatis di beberapa layanan data Azure PaaS. Failover otomatis tidak diperlukan untuk penyimpanan data yang mendukung penulisan multi-wilayah, seperti Azure Cosmos DB. Untuk informasi selengkapnya, lihat Rekomendasi untuk merancang strategi pemulihan bencana.
Gunakan penyimpanan data terbaik untuk data Anda. Rangkul persistensi poliglot atau solusi yang menggunakan campuran teknologi penyimpanan data. Data mencakup lebih dari sekadar data aplikasi yang bertahan. Data itu juga termasuk log aplikasi, kejadian, pesan, dan cache.
Pertimbangkan persyaratan konsistensi data dan gunakan konsistensi akhir saat persyaratan mengizinkannya. Ketika data didistribusikan, gunakan koordinasi yang sesuai untuk memberlakukan jaminan konsistensi yang kuat. Koordinasi dapat mengurangi throughput Anda dan membuat sistem Anda digabungkan dengan erat, yang dapat membuatnya lebih rapuh. Misalnya, jika operasi memperbarui dua database, alih-alih memasukkannya ke dalam satu cakupan transaksi, lebih baik jika sistem dapat mengakomodasi konsistensi akhir.
Data partisi untuk ketersediaan. Pemartisian database meningkatkan skalabilitas dan juga dapat meningkatkan ketersediaan. Jika satu pecahan turun, pecahan lainnya masih dapat dijangkau. Kegagalan dalam satu shard hanya mengganggu subset dari total transaksi.
Jika sharding bukan opsi, Anda dapat menggunakan pola Pemisahan Tanggung Jawab Perintah dan Kueri (CQRS) untuk memisahkan model data baca-tulis dan baca-saja Anda. Tambahkan lebih banyak instans database baca-saja yang berlebihan untuk memberikan lebih banyak ketahanan.
Pahami kemampuan replikasi dan redundansi bawaan dari layanan platform stateful yang Anda gunakan. Untuk kemampuan redundansi tertentu dari layanan data stateful, lihat Tautan terkait.
Menerapkan redundansi zona untuk sumber daya jaringan
Tentukan topologi jaringan yang andal dan dapat diskalakan. Gunakan model hub-and-spoke atau model Azure Virtual WAN untuk membantu Anda mengatur infrastruktur cloud dalam pola logis yang membuat desain redundansi Anda lebih mudah dibuat dan diskalakan.
Pilih layanan jaringan yang sesuai untuk menyeimbangkan dan mengalihkan permintaan di dalam atau di seluruh wilayah. Gunakan layanan penyeimbangan beban global atau zona redundan jika memungkinkan untuk memenuhi target keandalan Anda.
Pastikan Anda telah mengalokasikan ruang alamat IP yang memadai di jaringan virtual dan subnet Anda untuk memperhitungkan penggunaan yang direncanakan, termasuk persyaratan peluasan skala.
Pastikan bahwa aplikasi dapat menskalakan dalam batas port platform hosting aplikasi yang dipilih. Jika aplikasi memulai beberapa koneksi TCP atau UDP keluar, aplikasi mungkin menghabiskan semua port yang tersedia dan menyebabkan performa aplikasi yang buruk.
Pilih SKU dan konfigurasikan layanan jaringan yang dapat memenuhi persyaratan bandwidth dan ketersediaan Anda. Throughput gateway VPN bervariasi berdasarkan SKU mereka. Dukungan untuk redundansi zona hanya tersedia untuk beberapa SKU load balancer.
Pastikan desain Anda untuk menangani DNS dibangun dengan fokus pada ketahanan dan mendukung infrastruktur redundan.
Fasilitasi Azure
Platform Azure membantu Anda mengoptimalkan ketahanan beban kerja Anda dan menambahkan redundansi dengan:
Menyediakan redundansi bawaan dengan banyak solusi PaaS dan software as a service (SaaS), beberapa di antaranya dapat dikonfigurasi.
Memungkinkan Anda merancang dan menerapkan redundansi intra-wilayah dengan menggunakan zona ketersediaan dan redundansi antar-wilayah.
Menawarkan layanan penyeimbangan beban sadar replika seperti Azure Application Gateway, Azure Front Door, dan Azure Load Balancer.
Menawarkan solusi replikasi geografis yang mudah diimplementasikan seperti replikasi geografis aktif untuk Azure SQL Database. Terapkan distribusi global dan replikasi transparan dengan menggunakan Azure Cosmos DB. Azure Cosmos DB menawarkan dua opsi untuk menangani penulisan yang bertentangan. Pilih opsi terbaik untuk beban kerja Anda.
Menawarkan kemampuan pemulihan titik waktu untuk banyak layanan data PaaS.
Mengurangi kelelahan port melalui Azure NAT Gateway atau Azure Firewall.
Fasilitasi Azure khusus DNS
Untuk skenario resolusi nama internal, gunakan zona privat Azure DNS, yang memiliki redundansi zona bawaan dan redundansi geografis. Untuk informasi selengkapnya, lihat Ketahanan zona privat Azure DNS.
Untuk skenario resolusi nama eksternal, gunakan zona publik Azure DNS, yang memiliki redundansi zona bawaan dan redundansi geografis.
Layanan Azure DNS publik dan privat adalah layanan global yang tahan terhadap pemadaman regional karena data zona tersedia secara global.
Untuk skenario resolusi nama hibrid antara lingkungan lokal dan cloud, gunakan Azure DNS Private Resolver. Layanan ini mendukung redundansi zona jika beban kerja Anda terletak di wilayah yang mendukung zona ketersediaan. Pemadaman di seluruh zona tidak memerlukan tindakan selama pemulihan zona. Layanan ini secara otomatis menyembuhkan diri dan menyeimbangkan kembali untuk memanfaatkan zona sehat. Untuk informasi selengkapnya, lihat Ketahanan di Azure DNS Private Resolver.
Untuk menghilangkan satu titik kegagalan dan mencapai resolusi nama hibrid yang lebih tangguh di seluruh wilayah, sebarkan dua atau beberapa pemecah masalah privat Azure DNS di berbagai wilayah. Failover DNS, dalam skenario penerusan kondisional, dicapai dengan menetapkan resolver sebagai server DNS utama Anda. Tetapkan resolver lain di wilayah lain sebagai server DNS sekunder. Untuk informasi selengkapnya, lihat Menyiapkan failover DNS dengan menggunakan pemecah masalah privat.
Contoh
Untuk contoh penyebaran redundan multi-wilayah, lihat Garis besar aplikasi web redundan zona yang sangat tersedia.
Diagram berikut menunjukkan contoh lain:
Tautan terkait
Untuk mempelajari selengkapnya tentang redundansi, lihat sumber daya berikut ini:
- Panduan wilayah Azure
- Redundansi Azure Storage
- Penyimpanan zona-redundan
- Replikasi geografis aktif Azure SQL Database
- Mengonfigurasi replikasi antara dua instans terkelola
Daftar periksa keandalan
Lihat kumpulan rekomendasi lengkap.