Rekomendasi untuk merancang redundansi

  • Artikel

Berlaku untuk rekomendasi daftar periksa Keandalan Azure Well-Architected Framework ini:

RE:05 Tambahkan redundansi pada tingkat yang berbeda, terutama untuk alur kritis. Terapkan redundansi ke tingkat komputasi, data, jaringan, dan infrastruktur lainnya sesuai dengan target keandalan yang diidentifikasi.

Panduan terkait:Desain multiregional yang sangat tersediaMenggunakan zona ketersediaan dan wilayah |

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 tingkat komputasi, data, jaringan, dan 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 waktu henti yang diperpanjang karena potensi kegagalan.

Definisi

Istilah Definisi
Redundansi 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 sinkron atau tidak sinkronnya himpunan data tertentu di beberapa penyimpanan.
Partisi Proses pembagian data secara fisik menjadi penyimpanan data terpisah.
Pecahan Strategi pemartisian database horizontal yang mendukung beberapa instans penyimpanan dengan skema umum. Data tidak direplikasi di semua instans.

Strategi desain utama

Dalam konteks keandalan, gunakan redundansi untuk berisi masalah yang memengaruhi satu sumber daya dan pastikan 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 dapat menyebarkan sejumlah replika terbatas sehingga alur beroperasi dalam keadaan terdegradasi hingga 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 bahwa 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 kewalahan karena tidak dapat beroperasi pada 120 persen. Sebarkan beban dengan simpul lain untuk memastikan bahwa target performa dan keandalan Anda dijunjunkan.

Pertukaran:

  • Lebih banyak redundansi beban kerja sama dengan lebih banyak biaya. Pertimbangkan untuk menambahkan redundansi dan secara teratur meninjau arsitektur Anda untuk memastikan bahwa Anda mengelola biaya, terutama ketika Anda menggunakan provisi berlebih. Saat 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 atau wilayah ketersediaan 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 aliran 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 tertinggi, tetapi secara signifikan lebih mahal daripada desain aktif-pasif. 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 aktif-pasif, ikuti pola desain Deployment Stamps untuk memastikan bahwa Anda menyebarkan beban kerja Anda 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 satuan 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 aktif-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 aktif-pasif, manfaatkan zona ketersediaan dalam wilayah aktif untuk mengoptimalkan ketahanan Anda sepenuhnya. 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.

Panduan lapisan infrastruktur

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 sesuai pada layanan komputasi tertentu. Misalnya, beban kerja SAP biasanya paling cocok untuk layanan komputasi infrastruktur sebagai layanan (IaaS). Untuk aplikasi dalam kontainer, tentukan fungsionalitas tertentu yang perlu Anda kontrol untuk menentukan apakah akan menggunakan solusi Azure Kubernetes Service (AKS) atau 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 di dokumentasi 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 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 berlebih untuk mengurangi kegagalan instans redundan, bahkan sebelum operasi penskalaan otomatis dimulai, sehingga sistem terus beroperasi setelah kegagalan komponen. Hitung efek kesalahan yang dapat diterima ketika Anda memasukkan provisi berlebih ke dalam desain redundansi Anda. Seperti halnya proses pengambilan keputusan redundansi Anda, target keandalan dan keputusan tradeoff keuangan Anda menentukan sejauh Anda menambahkan kapasitas cadangan dengan provisi berlebih. Provisi berlebih secara khusus mengacu pada peluasan skala, 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 yang 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.

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 seiring meningkatnya jumlah data dalam solusi Anda.  

  • 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. Saat data didistribusikan, gunakan koordinasi yang sesuai untuk menegakkan 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 pecahan hanya mengganggu subset dari total transaksi.

  • Jika sharding bukan pilihan, Anda dapat menggunakan pola Command and Query Responsibility Segregation (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.

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 dibangun dan diskalakan.

  • Pilih layanan jaringan yang sesuai untuk menyeimbangkan dan mengalihkan permintaan 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 bandwidth dan persyaratan 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:

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 ini memperlihatkan contoh lain:

Diagram yang menunjukkan arsitektur implementasi referensi.

Untuk mempelajari selengkapnya tentang redundansi, lihat sumber daya berikut ini:

Daftar periksa keandalan

Lihat serangkaian rekomendasi lengkap.

Daftar periksa keandalan