Rekomendasi untuk menggunakan zona dan wilayah ketersediaan
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: Redundansi desain | multiregional yang sangat tersedia
Panduan ini menjelaskan rekomendasi untuk menentukan kapan harus menyebarkan beban kerja di seluruh zona atau wilayah ketersediaan.
Saat merancang solusi untuk Azure, Anda perlu memutuskan apakah Anda akan menyebarkan di beberapa zona ketersediaan di suatu wilayah atau menyebarkan ke beberapa wilayah. Keputusan ini memengaruhi keandalan, biaya, dan performa solusi Anda, dan kemampuan tim Anda untuk mengoperasikan solusi. Panduan ini menyediakan informasi tentang persyaratan bisnis utama yang memengaruhi keputusan Anda, pendekatan yang dapat Anda pertimbangkan, tradeoff yang terlibat dalam setiap pendekatan, dan efek setiap pendekatan pada pilar inti Azure Well-Architected Framework.
Keputusan tentang wilayah Azure terbaik untuk digunakan untuk solusi Anda adalah pilihan penting. Panduan Pilih Wilayah Azure menjelaskan cara memilih dan beroperasi di beberapa wilayah geografis. Pilihan Anda tentang cara Anda menggunakan wilayah dan zona ketersediaan dalam solusi Anda juga memengaruhi beberapa pilar Kerangka Kerja Yang Dirancang Dengan Baik:
- Keandalan: Pilihan pendekatan penyebaran Anda dapat membantu Anda mengurangi berbagai jenis risiko. Secara umum, dengan menyebarkan beban kerja Anda di area yang lebih terdistribusi secara geografis, Anda dapat mencapai ketahanan yang lebih tinggi.
- Pengoptimalan Biaya: Beberapa pendekatan arsitektur memerlukan penyebaran lebih banyak sumber daya daripada yang lain, yang dapat meningkatkan biaya sumber daya Anda. Pendekatan lain melibatkan pengiriman data di seluruh zona ketersediaan atau wilayah yang dipisahkan secara geografis, yang mungkin dikenakan biaya lalu lintas jaringan. Penting juga untuk mempertimbangkan biaya berkelanjutan dalam mengelola sumber daya Anda, yang biasanya lebih tinggi ketika Anda memiliki persyaratan bisnis yang komprehensif.
- Efisiensi Performa: Zona ketersediaan terhubung bersama melalui tautan jaringan dengan bandwidth tinggi dan latensi rendah, yang cukup bagi sebagian besar beban kerja untuk mengaktifkan replikasi dan komunikasi sinkron di seluruh zona. Namun, jika beban kerja Anda telah diuji dan sensitif terhadap latensi jaringan di seluruh zona, Anda mungkin perlu mempertimbangkan untuk menemukan komponen beban kerja Anda secara fisik yang berdekatan untuk meminimalkan latensi saat berkomunikasi.
- Keunggulan Operasional: Arsitektur yang kompleks membutuhkan lebih banyak upaya untuk menyebarkan, mengonfigurasi, dan mengelola. Selain itu, untuk solusi yang sangat tersedia, Anda mungkin perlu merencanakan cara melakukan failover ke serangkaian sumber daya sekunder. Failover, failback, dan pengalihan lalu lintas Anda secara transparan bisa rumit, terutama ketika langkah manual diperlukan. Ini adalah praktik yang baik untuk mengotomatiskan proses penyebaran dan manajemen Anda. Untuk informasi selengkapnya, lihat panduan pilar Keunggulan Operasional, termasuk Infrastruktur OE:05 sebagai kode, otomatisasi Tugas OE:09, desain OE:10 Automation, dan praktik Penyebaran OE:11.
Namun Anda merancang solusi Anda, pilar Keamanan berlaku. Biasanya, keputusan tentang apakah dan bagaimana Anda menggunakan zona ketersediaan dan wilayah tidak mengubah postur keamanan Anda. Azure menerapkan kekakuan keamanan yang sama ke setiap wilayah dan zona ketersediaan.
Tip
Untuk banyak beban kerja produksi, penyebaran zona-redundan memberikan keseimbangan terbaik dari tradeoff. Anda dapat memperluas pendekatan ini dengan pencadangan data asinkron ke wilayah lain. Jika Anda tidak yakin pendekatan mana yang akan dipilih, mulailah dengan jenis penyebaran ini.
Pertimbangkan pendekatan beban kerja lain ketika Anda memerlukan manfaat spesifik yang diberikan pendekatan tersebut, tetapi ketahuilah tradeoff yang terlibat.
Definisi
| Istilah | Definisi |
|---|---|
| Aktif-aktif | Arsitektur di mana beberapa instans solusi secara aktif memproses permintaan secara bersamaan. |
| Aktif-pasif | Arsitektur di mana satu instans solusi ditetapkan sebagai lalu lintas utama dan memproses, dan satu atau beberapa instans sekunder disebarkan untuk melayani lalu lintas jika primer tidak tersedia. |
| Replikasi asinkron | Pendekatan replikasi data tempat data ditulis dan diterapkan ke satu lokasi. Di lain waktu, perubahan direplikasi ke lokasi lain. |
| Zona ketersediaan | Grup pusat data yang dipisahkan dalam suatu wilayah. Setiap zona ketersediaan tidak bergantung pada yang lain, dengan infrastruktur daya, pendinginan, dan jaringannya sendiri. Banyak wilayah mendukung zona ketersediaan. |
| Pusat data | Fasilitas yang berisi server, peralatan jaringan, dan perangkat keras lainnya untuk mendukung sumber daya dan beban kerja Azure. |
| Penyebaran redundan lokal | Model penyebaran di mana sumber daya disebarkan ke satu wilayah tanpa merujuk ke zona ketersediaan. Di wilayah yang mendukung zona ketersediaan, sumber daya mungkin disebarkan di salah satu zona ketersediaan wilayah. |
| Penyebaran multi-wilayah | Model penyebaran tempat sumber daya disebarkan ke beberapa wilayah Azure. |
| Wilayah yang dipasangkan | Hubungan antara dua wilayah Azure. Beberapa wilayah Azure tersambung ke wilayah lain yang ditentukan untuk mengaktifkan jenis solusi multi-wilayah tertentu. Wilayah Azure yang lebih baru tidak dipasangkan. |
| Wilayah | Perimeter geografis yang berisi sekumpulan pusat data. |
| Arsitektur wilayah | Konfigurasi spesifik wilayah Azure, termasuk jumlah zona ketersediaan dan apakah wilayah dipasangkan dengan wilayah lain. |
| Replikasi sinkron | Pendekatan replikasi data tempat data ditulis dan diterapkan ke beberapa lokasi. Setiap lokasi harus mengakui penyelesaian operasi tulis sebelum operasi penulisan keseluruhan dianggap selesai. |
| Penyebaran zonal (disematkan) | Model penyebaran tempat sumber daya disebarkan ke zona ketersediaan tertentu. |
| Penyebaran zona-redundan | Model penyebaran tempat sumber daya disebarkan di beberapa zona ketersediaan. Microsoft mengelola sinkronisasi data, distribusi lalu lintas, dan failover jika zona mengalami pemadaman. |
Strategi desain utama
Azure memiliki jejak global yang besar. Wilayah Azure adalah perimeter geografis yang berisi sekumpulan pusat data. Anda harus memiliki pemahaman lengkap tentang wilayah Azure dan zona ketersediaan.
Wilayah Azure memiliki berbagai konfigurasi, yang juga disebut arsitektur wilayah.
Banyak wilayah Azure menyediakan zona ketersediaan, yang merupakan grup pusat data yang dipisahkan. Dalam suatu wilayah, zona ketersediaan cukup dekat untuk memiliki koneksi latensi rendah ke zona ketersediaan lain, tetapi cukup jauh untuk mengurangi kemungkinan bahwa lebih dari satu akan dipengaruhi oleh pemadaman atau cuaca lokal. Zona ketersediaan memiliki infrastruktur daya, pendinginan, dan jaringan mandiri. Zona ketersediaan dirancang sedemikian rupa sehingga jika satu zona mengalami pemadaman, maka layanan regional, kapasitas, dan ketersediaan tinggi didukung oleh zona lainnya.
Diagram berikut menunjukkan beberapa contoh wilayah Azure. Wilayah 1 dan 2 mendukung zona ketersediaan.
Jika Anda menyebarkan ke wilayah Azure yang berisi zona ketersediaan, Anda dapat menggunakan beberapa zona ketersediaan bersama-sama. Dengan menggunakan beberapa zona ketersediaan, Anda dapat menyimpan salinan terpisah aplikasi dan data Anda dalam pusat data fisik terpisah di area metropolitan yang besar.
Ada dua cara untuk menggunakan zona ketersediaan dalam solusi:
- Sumber daya zonasi disematkan ke zona ketersediaan tertentu. Anda dapat menggabungkan beberapa penyebaran zonasi di zona-zona yang berbeda untuk memenuhi persyaratan keandalan tinggi. Anda bertanggung jawab untuk mengelola replikasi data dan mendistribusikan permintaan di seluruh zona. Jika terjadi pemadaman di dalam satu zona ketersediaan, Anda bertanggung jawab melakukan failover ke zona ketersediaan lain.
- Sumber daya redundan zona tersebar di beberapa zona ketersediaan. Microsoft mengelola permintaan penyebaran di seluruh zona dan replikasi data di seluruh zona. Jika terjadi pemadaman di dalam satu zona ketersediaan, Microsoft mengelola failover secara otomatis.
Layanan Azure mendukung salah satu atau kedua pendekatan ini. Layanan Platform as a service (PaaS) biasanya mendukung penyebaran zona-redundan. Layanan Infrastruktur sebagai layanan (IaaS) biasanya mendukung penyebaran zona. Untuk informasi selengkapnya tentang cara kerja layanan Azure dengan zona ketersediaan, lihat Layanan Azure dengan dukungan zona ketersediaan.
Saat Microsoft menyebarkan pembaruan ke layanan, kami mencoba menggunakan pendekatan yang paling tidak mengganggu Anda. Misalnya, kami bertujuan untuk menyebarkan pembaruan ke satu zona ketersediaan pada satu waktu. Pendekatan ini dapat mengurangi dampak yang mungkin dilakukan pembaruan pada beban kerja aktif, karena beban kerja dapat terus berjalan di zona lain saat pembaruan sedang dalam proses. Namun, pada akhirnya tim beban kerja bertanggung jawab untuk memastikan beban kerja mereka terus berfungsi selama peningkatan platform. Misalnya, saat Anda menggunakan set skala komputer virtual dengan mode orkestrasi fleksibel, atau sebagian besar layanan Azure PaaS, Azure dengan cerdas menempatkan sumber daya Anda untuk mengurangi dampak pembaruan platform. Selain itu, Anda mungkin mempertimbangkan provisi berlebih - menyebarkan lebih banyak instans sumber daya - sehingga beberapa instans tetap tersedia saat instans lain ditingkatkan. Untuk informasi selengkapnya tentang cara Azure menyebarkan pembaruan, lihat Memajukan praktik penyebaran yang aman.
Banyak wilayah juga memiliki wilayah berpasangan. Wilayah berpasangan mendukung jenis pendekatan penyebaran multi-wilayah tertentu. Beberapa wilayah yang lebih baru memiliki beberapa zona ketersediaan dan tidak memiliki wilayah yang dipasangkan. Anda masih dapat menyebarkan solusi multi-wilayah ke wilayah ini, tetapi pendekatan yang Anda gunakan mungkin berbeda.
Untuk informasi selengkapnya tentang bagaimana Azure menggunakan wilayah dan zona ketersediaan, lihat Apa itu wilayah Azure dan zona ketersediaan?
Memahami tanggung jawab bersama
Prinsip tanggung jawab bersama menjelaskan bagaimana tanggung jawab dibagi antara penyedia cloud (Microsoft) dan Anda. Bergantung pada jenis layanan yang Anda gunakan, Anda mungkin bertanggung jawab lebih atau kurang untuk mengoperasikan layanan.
Microsoft menyediakan zona dan wilayah ketersediaan untuk memberi Anda fleksibilitas dalam cara Anda merancang solusi untuk memenuhi kebutuhan Anda. Saat Anda menggunakan layanan terkelola, Microsoft mengambil lebih banyak tanggung jawab manajemen untuk sumber daya Anda, yang bahkan mungkin menyertakan replikasi data, failover, failback, dan tugas lain yang terkait dengan pengoperasian sistem terdistribusi.
Kode Anda sendiri perlu direkomendasikan praktik dan pola desain untuk menangani kegagalan dengan anggun. Praktik ini bahkan lebih penting selama operasi failover, seperti yang terjadi ketika zona ketersediaan atau failover wilayah terjadi, karena failover antara zona atau wilayah biasanya mengharuskan aplikasi Anda mencoba kembali koneksi ke layanan.
Mengidentifikasi persyaratan bisnis dan beban kerja utama
Untuk membuat keputusan berdasarkan informasi tentang cara menggunakan zona ketersediaan dan wilayah dalam solusi Anda, Anda perlu memahami kebutuhan Anda. Persyaratan ini harus didorong oleh diskusi antara desainer solusi dan pemangku kepentingan bisnis.
Toleransi risiko
Organisasi yang berbeda memiliki tingkat toleransi risiko yang berbeda. Bahkan dalam organisasi, toleransi risiko sering berbeda untuk setiap beban kerja. Sebagian besar beban kerja tidak memerlukan ketersediaan yang sangat tinggi. Namun, beberapa beban kerja sangat penting sehingga bahkan layak untuk mengurangi risiko yang tidak mungkin terjadi, seperti bencana alam besar yang memengaruhi area geografis yang luas.
Tabel ini mencantumkan beberapa risiko umum yang harus Anda pertimbangkan di lingkungan cloud:
| Risiko | Contoh | Kecenderungan |
|---|---|---|
| Pemadaman perangkat keras | Masalah dengan hard disk atau peralatan jaringan. Reboot host. |
Tinggi. Strategi ketahanan apa pun harus memperhitungkan risiko ini. |
| Pemadaman pusat data | Daya, pendinginan, atau kegagalan jaringan di seluruh pusat data. Bencana alam di salah satu bagian dari wilayah metropolitan. |
Medium |
| Pemadaman wilayah | Bencana alam besar yang mempengaruhi wilayah geografis yang luas. Masalah jaringan atau layanan yang membuat satu atau beberapa layanan Azure tidak tersedia di seluruh wilayah. |
Kurang Penting |
Sangat ideal untuk mengurangi setiap kemungkinan risiko untuk setiap beban kerja, tetapi tidak praktis atau hemat biaya untuk melakukannya. Penting untuk berdiskusi terbuka dengan pemangku kepentingan bisnis sehingga Anda dapat membuat keputusan berdasarkan informasi tentang risiko yang harus Anda mitigasi.
Tip
Terlepas dari target keandalan, semua beban kerja harus memiliki beberapa mitigasi untuk pemulihan bencana. Jika beban kerja Anda menuntut target keandalan tinggi, maka strategi mitigasi Anda harus komprehensif dan Anda harus mengurangi risiko peristiwa kemungkinan rendah. Untuk beban kerja lain, buat keputusan berdasarkan informasi tentang risiko mana yang siap Anda terima dan yang perlu Anda mitigasi.
Persyaratan ketahanan
Penting untuk memahami persyaratan ketahanan untuk beban kerja Anda, termasuk tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO). Tujuan ini membantu Anda memutuskan pendekatan mana yang akan disingkirkan. Jika Anda tidak memiliki persyaratan yang jelas, Anda tidak dapat membuat keputusan berdasarkan informasi tentang pendekatan mana yang harus diikuti. Untuk informasi selengkapnya, lihat Persyaratan fungsional dan nonfungsi target.
Tujuan tingkat layanan
Anda harus memahami tujuan tingkat layanan (SLO) uptime yang diharapkan solusi Anda. Misalnya, Anda mungkin memiliki persyaratan bisnis yang dibutuhkan solusi Anda untuk memenuhi waktu aktif 99,9%.
Azure menyediakan perjanjian tingkat layanan (SLA) untuk setiap layanan. SLA menunjukkan tingkat waktu aktif yang harus Anda harapkan dari layanan dan kondisi yang perlu Anda penuhi untuk mencapai SLA yang diharapkan. Namun, ingatlah bahwa cara Azure SLA menunjukkan ketersediaan layanan tidak selalu cocok dengan cara Anda mempertimbangkan kesehatan beban kerja Anda.
Keputusan arsitektur Anda memengaruhi SLO komposit solusi Anda. Secara umum, semakin banyak redundansi yang Anda bangun ke dalam solusi Anda, semakin tinggi kemungkinan SLO Anda. Banyak layanan Azure menyediakan SLA yang lebih tinggi saat Anda menyebarkan layanan dalam konfigurasi zona redundan atau multi-wilayah. Tinjau SLA untuk setiap layanan Azure yang Anda gunakan untuk memastikan bahwa Anda memahami cara memaksimalkan ketahanan dan SLA layanan.
Residensi data
Beberapa organisasi menempatkan pembatasan pada lokasi fisik tempat data mereka dapat disimpan dan diproses. Terkadang persyaratan ini didasarkan pada standar hukum atau peraturan. Dalam situasi lain, organisasi mungkin memutuskan untuk mengadopsi kebijakan residensi data untuk menghindari kekhawatiran pelanggan. Jika Anda memiliki persyaratan residensi data yang ketat, Anda mungkin perlu menggunakan penyebaran satu wilayah atau menggunakan subset wilayah dan layanan Azure.
Catatan
Hindari membuat asumsi yang tidak berdasar tentang persyaratan residensi data Anda. Jika Anda perlu mematuhi standar peraturan tertentu, verifikasi apa yang sebenarnya ditentukan standar tersebut.
Lokasi pengguna
Dengan memahami lokasi pengguna, Anda dapat membuat keputusan berdasarkan informasi tentang cara mengoptimalkan latensi dan keandalan untuk kebutuhan Anda. Azure menyediakan banyak opsi untuk mendukung basis pengguna yang tersebar secara geografis.
Jika pengguna Anda terkonsentrasi dalam satu area, penyebaran satu wilayah dapat menyederhanakan persyaratan operasional Anda dan mengurangi biaya Anda. Namun, Anda perlu mempertimbangkan apakah penyebaran satu wilayah memenuhi persyaratan keandalan Anda. Untuk aplikasi misi penting, Anda masih harus menggunakan penyebaran multi-wilayah meskipun pengguna Anda dikolokasikan.
Jika pengguna Anda tersebar secara geografis, mungkin masuk akal untuk menyebarkan beban kerja Anda di beberapa wilayah. Layanan Azure menyediakan kemampuan yang berbeda untuk mendukung penyebaran multi-wilayah, dan Anda dapat menggunakan jejak global Azure untuk meningkatkan pengalaman pengguna Anda dan membawa aplikasi Anda lebih dekat ke basis pengguna Anda. Anda dapat menggunakan pola Stempel Penyebaran atau pola Geode, atau mereplikasi sumber daya Anda di beberapa wilayah.
Bahkan jika pengguna Anda berada di area geografis yang berbeda, pertimbangkan apakah Anda memerlukan penyebaran multi-wilayah. Pertimbangkan apakah Anda dapat mencapai persyaratan Anda dalam satu wilayah dengan menggunakan akselerasi lalu lintas global, seperti akselerasi yang disediakan oleh Azure Front Door.
Anggaran
Jika Anda beroperasi dengan anggaran terbatas, penting untuk mempertimbangkan biaya yang terlibat dalam penyebaran komponen beban kerja yang berlebihan. Biaya ini dapat mencakup biaya sumber daya tambahan, biaya jaringan, dan biaya operasional untuk mengelola lebih banyak sumber daya dan lingkungan yang lebih kompleks.
Kompleksitas
Ini adalah praktik yang baik untuk menghindari kompleksitas yang tidak perlu dalam arsitektur solusi Anda. Semakin kompleksitas yang Anda perkenalkan, semakin sulit untuk membuat keputusan tentang arsitektur Anda. Arsitektur yang kompleks lebih sulit dioperasikan, lebih sulit diamankan, dan seringkali kurang berkinerja. Ikuti prinsip kesederhanaan.
Fasilitasi Azure
Dengan menyediakan wilayah dan zona ketersediaan, Azure memungkinkan Anda memilih pendekatan penyebaran yang sesuai dengan kebutuhan Anda. Ada banyak pendekatan yang dapat Anda pilih, yang masing-masing memberikan manfaat dan menimbulkan biaya.
Untuk mengilustrasikan pendekatan penyebaran yang dapat Anda gunakan, pertimbangkan contoh skenario. Misalkan Anda berpikir untuk menyebarkan solusi baru yang menyertakan aplikasi yang menulis data ke semacam penyimpanan:
Contoh ini tidak spesifik untuk layanan Azure tertentu. Ini dimaksudkan untuk memberikan contoh sederhana untuk mengilustrasikan konsep dasar.
Ada beberapa cara untuk menyebarkan solusi ini. Setiap pendekatan memberikan serangkaian manfaat yang berbeda dan menimbulkan biaya yang berbeda. Pada tingkat tinggi, Anda dapat mempertimbangkan penyebaran redundan lokal, zonal (disematkan), zona-redundan, atau multi-wilayah. Tabel ini merangkum beberapa masalah pilar:
| Pilar | Redundan secara lokal | Zonal (disematkan) | Zone-redundant | Multi-wilayah |
|---|---|---|---|---|
| Keandalan | Keandalan rendah | Tergantung pada pendekatan | Keandalan tinggi atau sangat tinggi | Keandalan tinggi atau sangat tinggi |
| Pengoptimalan Biaya | Biaya rendah | Tergantung pada pendekatan | Biaya sedang | Biaya tinggi |
| Efisiensi Performa | Performa yang dapat diterima (untuk sebagian besar beban kerja) | Performa tinggi | Performa yang dapat diterima (untuk sebagian besar beban kerja) | Tergantung pada pendekatan |
| Keunggulan Operasional | Persyaratan operasional rendah | Persyaratan operasional tinggi | Persyaratan operasional rendah | Persyaratan operasional tinggi |
Tabel ini meringkas beberapa pendekatan yang dapat Anda gunakan dan pengaruhnya terhadap arsitektur Anda:
| Kekhawatiran arsitektur | Redundan secara lokal | Zonal (disematkan) | Zone-redundant | Multi-wilayah |
|---|---|---|---|---|
| Kepatuhan terhadap residensi data | Sangat Penting | Sangat Penting | Sangat Penting | Bergantung pada wilayah |
| Ketersediaan regional | Semua wilayah | Wilayah dengan zona ketersediaan | Wilayah dengan zona ketersediaan | Bergantung pada wilayah |
Sisa artikel ini menjelaskan setiap pendekatan yang tercantum dalam tabel sebelumnya. Daftar pendekatan tidak lengkap. Anda mungkin memutuskan untuk menggabungkan beberapa pendekatan atau menggunakan pendekatan yang berbeda di berbagai bagian solusi Anda.
Pendekatan penyebaran 1: Penyebaran redundan lokal
Jika Anda tidak menentukan beberapa zona atau wilayah ketersediaan saat menyebarkan sumber daya, Azure tidak membuat jaminan apa pun tentang apakah sumber daya disebarkan ke dalam satu pusat data atau dibagi di beberapa pusat data di wilayah tersebut. Dalam beberapa situasi, Azure mungkin juga memindahkan sumber daya Anda di antara zona ketersediaan.
Sebagian besar sumber daya Azure sangat tersedia secara default, dengan SLA tinggi dan redundansi bawaan dalam pusat data yang dikelola oleh platform. Namun, dari perspektif keandalan, jika ada bagian dari wilayah yang mengalami pemadaman, ada kemungkinan beban kerja Anda mungkin terpengaruh. Jika ya, solusi Anda mungkin tidak tersedia, atau data Anda bisa hilang.
Untuk beban kerja yang sangat sensitif terhadap latensi, pendekatan ini mungkin juga mengakibatkan performa yang lebih rendah. Komponen beban kerja Anda mungkin tidak terletak di pusat data yang sama, sehingga Anda mungkin mengamati beberapa latensi untuk lalu lintas intra-wilayah. Azure mungkin juga secara transparan memindahkan instans layanan Anda di antara zona ketersediaan, yang mungkin sedikit memengaruhi performa. Namun, ini bukan masalah bagi sebagian besar beban kerja.
Tabel ini merangkum beberapa masalah pilar:
| Pilar | Dampak |
|---|---|
| Keandalan | Keandalan rendah. Layanan tunduk pada pemadaman jika pusat data gagal. Namun, Anda dapat membangun aplikasi agar tahan terhadap jenis kegagalan lainnya. |
| Pengoptimalan Biaya | Biaya terendah. Anda hanya perlu memiliki satu instans dari setiap sumber daya, dan Anda tidak dikenakan biaya bandwidth antarwilayah. |
| Efisiensi Performa | Untuk sebagian besar beban kerja: Performa yang dapat diterima. Pendekatan ini kemungkinan akan memberikan performa yang memuaskan. Untuk beban kerja yang sangat sensitif terhadap latensi: Performa rendah. Komponen tidak dijamin terletak di zona ketersediaan yang sama, sehingga Anda mungkin melihat performa yang lebih rendah untuk komponen yang sangat sensitif terhadap latensi. |
| Keunggulan Operasional | Efisiensi operasional yang tinggi. Anda hanya perlu menyebarkan dan mengelola satu instans dari setiap sumber daya. |
Tabel ini merangkum beberapa kekhawatiran dari perspektif arsitektur:
| Kekhawatiran arsitektur | Dampak |
|---|---|
| Kepatuhan terhadap residensi data | Tinggi. Saat Anda menyebarkan solusi yang menggunakan pendekatan ini, data disimpan di wilayah Azure yang Anda pilih. |
| Ketersediaan regional | Tinggi. Pendekatan ini dapat digunakan di wilayah Azure mana pun. |
Penyebaran redundan lokal dengan pencadangan di seluruh wilayah
Anda dapat memperluas penyebaran redundan lokal dengan melakukan pencadangan reguler infrastruktur dan data Anda ke wilayah sekunder. Pendekatan ini menambahkan lapisan perlindungan tambahan untuk mengurangi pemadaman di wilayah utama Anda. Berikut tampilannya:
Ketika Anda menerapkan pendekatan ini, Anda perlu mempertimbangkan RTO dan RPO Anda dengan hati-hati:
- Waktu pemulihan: Jika pemadaman regional terjadi, Anda mungkin perlu membangun kembali solusi Anda di wilayah Azure lain, yang memengaruhi waktu pemulihan Anda. Pertimbangkan untuk membangun solusi Anda dengan menggunakan pendekatan infrastructure-as-code (IaC) sehingga Anda dapat dengan cepat menyebarkan ulang ke wilayah lain jika terjadi bencana besar. Pastikan bahwa alat dan proses penyebaran Anda sama tangguhnya dengan aplikasi Anda sehingga Anda dapat menggunakannya untuk menyebarkan ulang solusi Anda bahkan jika ada pemadaman. Rencanakan dan pulihkan langkah-langkah yang diperlukan untuk memulihkan solusi Anda kembali ke status kerja.
- Titik pemulihan: Frekuensi pencadangan Anda menentukan jumlah kehilangan data yang mungkin Anda alami (titik pemulihan Anda). Anda biasanya dapat mengontrol frekuensi pencadangan sehingga Anda dapat memenuhi RPO Anda.
Tabel ini merangkum beberapa masalah pilar:
| Pilar | Dampak |
|---|---|
| Keandalan | Keandalan sedang. Layanan tunduk pada pemadaman jika pusat data gagal. Data dicadangkan secara asinkron ke wilayah yang dipisahkan secara geografis, yang mengurangi efek pemadaman wilayah penuh dengan meminimalkan kehilangan data. Dalam pemadaman wilayah penuh, Anda dapat memulihkan operasi secara manual ke wilayah lain. Namun, proses pemulihan bisa rumit, dan perlu waktu untuk memulihkan secara manual ke wilayah lain. |
| Pengoptimalan Biaya | Biaya rendah. Biasanya, menambahkan cadangan ke wilayah lain biaya hanya sedikit lebih dari menyebarkan sumber daya yang berlebihan secara lokal. |
| Efisiensi Performa | Untuk sebagian besar beban kerja: Performa yang dapat diterima. Pendekatan ini kemungkinan akan memberikan performa yang memuaskan. Untuk beban kerja yang sangat sensitif terhadap latensi: Performa rendah. Komponen tidak dijamin terletak di zona ketersediaan yang sama, sehingga Anda mungkin melihat performa yang lebih rendah untuk komponen yang sangat sensitif terhadap latensi. |
| Keunggulan Operasional | Selama pemadaman apa pun dalam suatu wilayah: Efisiensi operasional rendah. Failover adalah tanggung jawab Anda dan mungkin memerlukan operasi manual dan penyebaran ulang. |
Tabel ini merangkum beberapa kekhawatiran dari perspektif arsitektur:
| Kekhawatiran arsitektur | Dampak |
|---|---|
| Kepatuhan terhadap residensi data | Tergantung pada pemilihan wilayah. Data terutama disimpan di wilayah Azure yang Anda tentukan. Namun, Anda perlu memilih wilayah lain untuk menyimpan cadangan Anda, jadi penting agar Anda memilih wilayah yang kompatibel dengan persyaratan residensi data Anda. |
| Ketersediaan regional | Tinggi. Anda dapat menggunakan pendekatan ini di wilayah Azure mana pun. |
Pendekatan penyebaran 2: Penyebaran zona (disematkan)
Dalam penyebaran zona, Anda menentukan bahwa sumber daya Anda harus disebarkan ke zona ketersediaan tertentu. Pendekatan ini terkadang disebut penyebaran yang disematkan zona.
Pendekatan zonal mengurangi latensi antara komponen Anda. Namun, dengan sendirinya, itu tidak meningkatkan ketahanan solusi Anda. Untuk meningkatkan ketahanan, Anda perlu menyebarkan beberapa instans komponen Anda ke beberapa zona ketersediaan dan memutuskan cara merutekan lalu lintas di antara setiap instans. Contoh ini menunjukkan pendekatan perutean lalu lintas pasif aktif:
Dalam contoh sebelumnya, load balancer disebarkan di beberapa zona ketersediaan. Penting untuk mempertimbangkan bagaimana Anda merutekan lalu lintas antar instans di zona ketersediaan yang berbeda, karena pemadaman zona mungkin juga memengaruhi sumber daya jaringan yang disebarkan ke zona tersebut. Anda mungkin juga mempertimbangkan untuk menggunakan load balancer global, seperti Azure Front Door atau Azure Traffic Manager, yang tidak disebarkan ke wilayah sama sekali.
Saat Anda menggunakan model penyebaran zona, Anda mengambil banyak tanggung jawab:
- Anda perlu menyebarkan sumber daya ke setiap zona ketersediaan, dan mengonfigurasi dan mengelola sumber daya tersebut satu per satu.
- Anda perlu memutuskan bagaimana dan kapan harus mereplikasi data antara zona ketersediaan, lalu mengonfigurasi dan mengelola replikasi.
- Anda bertanggung jawab untuk mendistribusikan permintaan ke sumber daya yang benar, dengan menggunakan, misalnya, load balancer. Anda perlu memastikan bahwa load balancer memenuhi persyaratan ketahanan Anda. Anda juga perlu memutuskan apakah akan menggunakan model distribusi permintaan aktif-pasif atau aktif-aktif.
- Jika zona ketersediaan mengalami pemadaman, Anda perlu menangani failover untuk mengirim lalu lintas ke sumber daya di zona ketersediaan lain.
Penyebaran pasif aktif di beberapa zona ketersediaan terkadang disebut DR di wilayah atau Metro DR.
Tabel ini merangkum beberapa masalah pilar:
| Pilar | Dampak |
|---|---|
| Keandalan | Saat disebarkan dalam satu zona ketersediaan: Keandalan rendah. Penyebaran zona tidak memberikan ketahanan apa pun terhadap pemadaman di pusat data atau zona ketersediaan. Anda harus menyebarkan sumber daya redundan di beberapa zona ketersediaan untuk mencapai ketahanan tinggi. Saat disebarkan di beberapa zona ketersediaan: Keandalan tinggi. Layanan dapat dibuat tahan terhadap pemadaman pusat data atau zona ketersediaan. |
| Pengoptimalan Biaya | Saat disebarkan dalam satu zona ketersediaan: Biaya rendah. Penyebaran zona tunggal hanya memerlukan satu instans dari setiap sumber daya. Saat disebarkan di beberapa zona ketersediaan: Biaya tinggi. Anda menyebarkan beberapa instans sumber daya, yang masing-masing ditagih secara terpisah. |
| Efisiensi Performa | Performa tinggi. Latensi bisa sangat rendah ketika komponen yang melayani permintaan terletak di zona ketersediaan yang sama. |
| Keunggulan Operasional | Efisiensi operasional yang rendah. Anda perlu mengonfigurasi dan mengelola beberapa instans layanan Anda. Anda perlu mereplikasi data antar zona ketersediaan. Selama pemadaman zona ketersediaan, failover adalah tanggung jawab Anda. |
Tabel ini merangkum beberapa kekhawatiran dari perspektif arsitektur:
| Kekhawatiran arsitektur | Dampak |
|---|---|
| Kepatuhan terhadap residensi data | Tinggi. Saat Anda menyebarkan solusi yang menggunakan pendekatan ini, data disimpan di wilayah Azure yang Anda pilih. |
| Ketersediaan regional | Wilayah dengan zona ketersediaan. Pendekatan ini tersedia di wilayah mana pun yang mendukung zona ketersediaan. |
Pendekatan ini biasanya digunakan untuk beban kerja yang didasarkan pada komputer virtual. Untuk daftar lengkap layanan yang mendukung penyebaran zona, lihat Layanan zona ketersediaan dan dukungan regional.
Saat Anda merencanakan penyebaran zonal, verifikasi bahwa layanan Azure yang Anda gunakan didukung di zona ketersediaan yang anda rencanakan untuk digunakan. Misalnya, untuk mencantumkan SKU komputer virtual mana yang tersedia di setiap zona ketersediaan, lihat Memeriksa ketersediaan SKU VM.
Tip
Saat Anda menyebarkan sumber daya ke zona ketersediaan tertentu, Anda memilih nomor zona. Urutan nomor zona berbeda untuk setiap langganan Azure. Jika Anda menyebarkan sumber daya di beberapa langganan Azure, verifikasi nomor zona yang harus Anda gunakan di setiap langganan. Untuk informasi selengkapnya, lihat Zona ketersediaan fisik dan logis.
Pendekatan penyebaran 3: Penyebaran zona-redundan
Saat Anda menggunakan pendekatan ini, tingkat aplikasi Anda tersebar di beberapa zona ketersediaan. Ketika permintaan tiba, load balancer yang dibangun ke dalam layanan (yang sendiri mencakup zona ketersediaan) menyebarkan permintaan di seluruh instans di setiap zona ketersediaan. Jika zona ketersediaan mengalami pemadaman, penyeimbang beban mengarahkan lalu lintas ke instans di zona ketersediaan yang sehat.
Tingkat penyimpanan Anda juga tersebar di beberapa zona ketersediaan. Salinan data aplikasi Anda didistribusikan di beberapa zona ketersediaan melalui replikasi sinkron. Ketika aplikasi membuat perubahan pada data, layanan penyimpanan menulis perubahan ke beberapa zona ketersediaan, dan transaksi dianggap selesai hanya ketika semua perubahan ini selesai. Proses ini memastikan bahwa setiap zona ketersediaan selalu memiliki salinan data terbaru. Jika zona ketersediaan mengalami pemadaman, zona ketersediaan lain dapat digunakan untuk mengakses data yang sama.
Pendekatan zona redundan meningkatkan ketahanan solusi Anda terhadap masalah seperti pemadaman pusat data. Karena data direplikasi secara sinkron, namun, aplikasi Anda harus menunggu data ditulis di beberapa lokasi terpisah yang mungkin berada di berbagai bagian area metropolitan. Untuk sebagian besar aplikasi, latensi yang terlibat dalam komunikasi antar-zona dapat diabaikan. Namun, untuk beberapa beban kerja yang sangat sensitif terhadap latensi, replikasi sinkron di seluruh zona ketersediaan dapat memengaruhi performa aplikasi.
Tabel ini merangkum beberapa masalah pilar:
| Pilar | Dampak |
|---|---|
| Keandalan | Keandalan tinggi. Layanan tahan terhadap pemadaman pusat data atau zona ketersediaan. Data direplikasi secara sinkron di seluruh zona ketersediaan dan tanpa penundaan. |
| Pengoptimalan Biaya | Biaya sedang. Bergantung pada layanan yang Anda gunakan, Anda mungkin dikenakan beberapa biaya untuk tingkat layanan yang lebih tinggi untuk mengaktifkan redundansi zona. |
| Efisiensi Performa | Untuk sebagian besar beban kerja: Performa yang dapat diterima. Pendekatan ini kemungkinan akan memberikan performa yang memuaskan. Untuk beban kerja yang sangat sensitif terhadap latensi: Performa rendah. Beberapa komponen mungkin sensitif terhadap latensi karena lalu lintas antar-zona atau waktu replikasi data. |
| Keunggulan Operasional | Efisiensi operasional yang tinggi. Anda biasanya hanya perlu mengelola satu instans logis dari setiap sumber daya. Untuk sebagian besar layanan, selama pemadaman zona ketersediaan, failover adalah tanggung jawab Microsoft dan terjadi secara otomatis. |
Tabel ini merangkum beberapa kekhawatiran dari perspektif arsitektur:
| Kekhawatiran arsitektur | Dampak |
|---|---|
| Kepatuhan terhadap residensi data | Tinggi. Saat Anda menyebarkan solusi yang menggunakan pendekatan ini, data disimpan di wilayah Azure yang Anda pilih. |
| Ketersediaan regional | Wilayah dengan zona ketersediaan. Pendekatan ini tersedia di wilayah mana pun yang mendukung zona ketersediaan. |
Pendekatan ini dimungkinkan dengan banyak layanan Azure, termasuk Azure Virtual Machine Scale Sets, Azure App Service, Azure Functions, Azure Kubernetes Service, Azure Storage, Azure SQL, Azure Bus Layanan, dan banyak lainnya. Untuk daftar lengkap layanan yang mendukung redundansi zona, lihat Layanan zona ketersediaan dan dukungan regional.
Penyebaran zona-redundan dengan pencadangan di seluruh wilayah
Anda dapat memperluas penyebaran zona-redundan dengan melakukan pencadangan reguler infrastruktur dan data Anda ke wilayah sekunder. Pendekatan ini memberi Anda manfaat dari pendekatan zona-redundan dan menambahkan lapisan perlindungan untuk mengurangi peristiwa yang sangat tidak mungkin dari pemadaman wilayah penuh.
Ketika Anda menerapkan pendekatan ini, Anda perlu mempertimbangkan RTO dan RPO Anda dengan hati-hati:
Waktu pemulihan: Jika pemadaman regional terjadi, Anda mungkin perlu membangun kembali solusi Anda di wilayah Azure lain, yang memengaruhi waktu pemulihan Anda. Pertimbangkan untuk membangun solusi Anda dengan menggunakan pendekatan IaC sehingga Anda dapat dengan cepat menyebarkan ulang ke wilayah lain selama bencana besar. Pastikan bahwa alat dan proses penyebaran Anda sama tangguhnya dengan aplikasi Anda sehingga Anda dapat menggunakannya untuk menyebarkan ulang solusi Anda bahkan jika pemadaman terjadi. Rencanakan dan pulihkan langkah-langkah yang diperlukan untuk memulihkan solusi Anda kembali ke status kerja.
Titik pemulihan: Frekuensi pencadangan Anda menentukan jumlah kehilangan data yang mungkin Anda alami (titik pemulihan Anda). Anda biasanya dapat mengontrol frekuensi cadangan untuk memenuhi RPO Anda.
Tip
Pendekatan ini sering memberikan keseimbangan yang baik untuk semua masalah arsitektur. Jika Anda tidak yakin pendekatan mana yang akan digunakan, mulailah dengan jenis penyebaran ini.
Tabel ini merangkum beberapa masalah pilar:
| Pilar | Dampak |
|---|---|
| Keandalan | Keandalan yang sangat tinggi. Layanan tahan terhadap pemadaman pusat data atau zona ketersediaan. Untuk sebagian besar layanan, data direplikasi di seluruh zona secara otomatis dan tanpa penundaan. Data dicadangkan secara asinkron ke wilayah yang dipisahkan secara geografis. Pencadangan ini mengurangi efek pemadaman wilayah penuh dengan meminimalkan kehilangan data. Setelah pemadaman wilayah penuh, Anda dapat memulihkan operasi secara manual ke wilayah lain. Namun, proses pemulihan bisa rumit, dan perlu waktu untuk memulihkan secara manual ke wilayah lain. |
| Pengoptimalan Biaya | Biaya sedang. Biasanya, menambahkan cadangan ke wilayah lain biaya hanya sedikit lebih dari menerapkan redundansi zona. |
| Efisiensi Performa | Untuk sebagian besar beban kerja: Performa yang dapat diterima. Pendekatan ini kemungkinan akan memberikan performa yang memuaskan. Untuk beban kerja yang sangat sensitif terhadap latensi: Performa rendah. Beberapa komponen mungkin sensitif terhadap latensi karena lalu lintas antar-zona atau waktu replikasi data. |
| Keunggulan Operasional | Selama pemadaman zona ketersediaan: Efisiensi operasional tinggi. Failover adalah tanggung jawab Microsoft dan terjadi secara otomatis. Selama pemadaman regional: Efisiensi operasional rendah. Failover adalah tanggung jawab Anda dan mungkin memerlukan operasi manual dan penyebaran ulang. |
Tabel ini merangkum beberapa kekhawatiran dari perspektif arsitektur:
| Kekhawatiran arsitektur | Dampak |
|---|---|
| Kepatuhan terhadap residensi data | Tergantung pada pemilihan wilayah. Data disimpan terutama di wilayah Azure yang Anda tentukan, tetapi Anda perlu memilih wilayah lain untuk menyimpan cadangan Anda. Pilih wilayah yang kompatibel dengan persyaratan residensi data Anda. |
| Ketersediaan regional | Wilayah dengan zona ketersediaan. Pendekatan ini tersedia di wilayah mana pun yang mendukung zona ketersediaan. |
Pendekatan penyebaran 4: Penyebaran multi-wilayah
Anda dapat menggunakan beberapa wilayah Azure bersama-sama untuk mendistribusikan solusi Anda di seluruh area geografis yang luas. Anda dapat menggunakan pendekatan multi-wilayah ini untuk meningkatkan keandalan solusi Anda atau untuk mendukung pengguna yang didistribusikan secara geografis. Dengan menyebarkan ke beberapa wilayah, Anda juga mengurangi risiko bahwa Anda akan mengalami batasan kapasitas sumber daya sementara dalam satu wilayah. Jika residensi data adalah perhatian penting bagi solusi Anda, pertimbangkan dengan cermat wilayah mana yang Anda gunakan untuk memastikan bahwa data Anda hanya disimpan di lokasi yang memenuhi kebutuhan Anda.
Wilayah aktif dan pasif
Arsitektur multi-wilayah kompleks, dan ada banyak cara untuk merancang solusi multi-wilayah. Untuk beberapa beban kerja, masuk akal untuk memiliki beberapa wilayah yang secara aktif memproses permintaan secara bersamaan (penyebaran aktif-aktif). Untuk beban kerja lain, lebih baik menunjuk satu wilayah utama dan menggunakan satu atau beberapa wilayah sekunder untuk failover (penyebaran pasif aktif). Bagian ini berfokus pada skenario kedua, di mana satu wilayah aktif dan wilayah lain pasif. Untuk informasi tentang solusi multi-wilayah aktif-aktif, lihat Pola stempel penyebaran dan pola Geode.
Replikasi data
Berkomunikasi di seluruh wilayah jauh lebih lambat daripada berkomunikasi dalam suatu wilayah. Secara umum, jarak geografis yang lebih besar antara dua wilayah menimbulkan lebih banyak latensi jaringan karena jarak fisik yang lebih panjang yang perlu ditempuh data. Lihat Statistik latensi pulang pergi jaringan Azure untuk latensi jaringan yang diharapkan saat Anda terhubung di antara dua wilayah.
Latensi jaringan lintas wilayah dapat secara signifikan memengaruhi desain solusi Anda karena Anda perlu mempertimbangkan dengan cermat bagaimana latensi tambahan memengaruhi replikasi data dan transaksi lainnya. Untuk banyak solusi, arsitektur lintas wilayah memerlukan replikasi asinkron untuk meminimalkan efek lalu lintas wilayah pada performa.
Replikasi data asinkron
Saat Anda menerapkan replikasi asinkron di seluruh wilayah, aplikasi Anda tidak menunggu semua wilayah mengakui perubahan. Setelah perubahan dilakukan di wilayah utama, transaksi dianggap selesai. Perubahan direplikasi ke wilayah sekunder di lain waktu. Pendekatan ini memastikan bahwa latensi koneksi antarwilayah tidak secara langsung memengaruhi performa aplikasi. Namun, karena keterlambatan replikasi, pemadaman di seluruh wilayah dapat mengakibatkan beberapa kehilangan data. Kehilangan data ini dapat terjadi karena suatu wilayah mungkin mengalami pemadaman setelah penulisan selesai di wilayah utama tetapi sebelum perubahan dapat direplikasi ke wilayah lain.
Tabel ini merangkum beberapa masalah pilar:
| Pilar | Dampak |
|---|---|
| Keandalan | Keandalan tinggi. Solusi ini tahan terhadap pemadaman pusat data, zona ketersediaan, atau seluruh wilayah. Data direplikasi tetapi mungkin tidak sinkron, sehingga beberapa kehilangan data dimungkinkan dalam skenario failover. |
| Pengoptimalan Biaya | Biaya tinggi. Anda perlu menyebarkan sumber daya terpisah di setiap wilayah, dan setiap sumber daya dikenakan biaya penyebaran dan pemeliharaan. Replikasi data di seluruh wilayah mungkin juga dikenakan biaya yang signifikan. |
| Efisiensi Performa | Performa tinggi. Permintaan aplikasi tidak memerlukan lalu lintas wilayah, sehingga lalu lintas biasanya latensi rendah. |
| Keunggulan Operasional | Efisiensi operasional yang rendah. Anda perlu menyebarkan dan mengelola sumber daya di beberapa wilayah. Anda juga bertanggung jawab atas failover antar wilayah selama pemadaman regional. |
Tabel ini merangkum beberapa kekhawatiran dari perspektif arsitektur:
| Kekhawatiran arsitektur | Dampak |
|---|---|
| Kepatuhan terhadap residensi data | Tergantung pada pemilihan wilayah. Pendekatan ini mengharuskan Anda memilih beberapa wilayah untuk menjalankan beban kerja Anda. Pilih wilayah yang kompatibel dengan persyaratan residensi data Anda. |
| Ketersediaan regional | Banyak wilayah Azure dipasangkan. Beberapa layanan Azure menggunakan wilayah berpasangan untuk mereplikasi data secara otomatis. Jika Anda menjalankan beban kerja di wilayah yang tidak memiliki pasangan, Anda mungkin perlu menggunakan pendekatan yang berbeda untuk mereplikasi data Anda. |
Replikasi data sinkron
Jika Anda menerapkan solusi multi-wilayah yang sinkron, aplikasi Anda harus menunggu operasi tulis selesai di setiap wilayah Azure sebelum transaksi dianggap selesai. Latensi yang terjadi dengan menunggu operasi tulis tergantung pada jarak antar wilayah. Untuk banyak beban kerja, latensi antar-wilayah dapat membuat replikasi sinkron terlalu lambat menjadi berguna.
Tabel ini merangkum beberapa masalah pilar:
| Pilar | Dampak |
|---|---|
| Keandalan | Keandalan yang sangat tinggi. Solusi ini tahan terhadap pemadaman pusat data, zona ketersediaan, atau seluruh wilayah. Data selalu sinkron di seluruh wilayah, jadi, bahkan jika kehilangan wilayah lengkap terjadi, data Anda tersedia dan lengkap di wilayah lain. |
| Pengoptimalan Biaya | Biaya tinggi. Anda perlu menyebarkan sumber daya terpisah di setiap wilayah, dan setiap sumber daya dikenakan biaya penyebaran dan pemeliharaan. Replikasi data di seluruh wilayah mungkin juga dikenakan biaya yang signifikan. |
| Efisiensi Performa | Performa rendah. Permintaan aplikasi memerlukan lalu lintas wilayah. Bergantung pada jarak antara wilayah, replikasi sinkron mungkin menambahkan latensi signifikan ke permintaan. |
| Keunggulan Operasional | Efisiensi operasional yang rendah. Anda perlu menyebarkan dan mengelola sumber daya di beberapa wilayah. Anda juga bertanggung jawab atas failover antar wilayah selama pemadaman regional. |
Tabel ini merangkum beberapa kekhawatiran dari perspektif arsitektur:
| Kekhawatiran arsitektur | Dampak |
|---|---|
| Kepatuhan terhadap residensi data | Tergantung pada pemilihan wilayah. Pendekatan ini mengharuskan Anda memilih beberapa wilayah untuk menjalankan beban kerja Anda. Pilih wilayah yang kompatibel dengan persyaratan residensi data Anda. |
| Ketersediaan regional | Banyak wilayah Azure dipasangkan. Beberapa layanan Azure menggunakan wilayah berpasangan untuk mereplikasi data secara otomatis. Jika Anda menjalankan beban kerja di wilayah yang tidak memiliki pasangan, Anda mungkin perlu menggunakan pendekatan yang berbeda untuk mereplikasi data Anda. |
Arsitektur wilayah
Saat Anda merancang solusi multi-wilayah, pertimbangkan apakah wilayah Azure yang Anda rencanakan untuk digunakan dipasangkan.
Anda dapat membuat solusi multi-wilayah bahkan ketika wilayah tidak dipasangkan. Namun, pendekatan yang Anda gunakan untuk menerapkan arsitektur multi-wilayah mungkin berbeda. Misalnya, di Azure Storage, Anda dapat menggunakan penyimpanan geo-redundan (GRS) dengan wilayah yang dipasangkan. Jika GRS tidak tersedia, pertimbangkan untuk menggunakan fitur seperti replikasi objek Azure Storage, atau rancang aplikasi Anda untuk menulis ke beberapa wilayah.
Menggabungkan pendekatan multi-zona dan multi-wilayah
Anda harus menggabungkan pernyataan multi-zona dan multi-wilayah jika persyaratan bisnis Anda menuntut solusi seperti itu. Misalnya, Anda dapat menyebarkan komponen zona-redundan ke setiap wilayah dan juga mengonfigurasi replikasi antar wilayah. Untuk beberapa solusi, pendekatan ini memberikan tingkat keandalan yang sangat tinggi. Namun, mengonfigurasi jenis pendekatan ini bisa rumit, dan pendekatan ini bisa mahal.
Penting
Beban kerja misi penting harus menggunakan beberapa zona ketersediaan dan beberapa wilayah. Untuk informasi selengkapnya tentang pertimbangan yang harus Anda berikan saat merancang beban kerja misi penting, lihat Dokumentasi beban kerja misi penting.
Cara layanan Azure mendukung pendekatan penyebaran
Penting untuk memahami detail spesifik layanan Azure yang Anda gunakan. Misalnya, beberapa layanan Azure mengharuskan Anda mengonfigurasi konfigurasi zona ketersediaannya saat pertama kali menyebarkan sumber daya, sementara yang lain mendukung perubahan pendekatan penyebaran nanti. Demikian pula, beberapa fitur layanan mungkin tidak tersedia dengan setiap pendekatan penyebaran.
Untuk mempelajari selengkapnya tentang opsi dan pendekatan penyebaran tertentu yang perlu dipertimbangkan untuk setiap layanan Azure, kunjungi hub Keandalan.
Contoh
Bagian ini menjelaskan beberapa kasus penggunaan umum dan persyaratan utama yang biasanya perlu Anda pertimbangkan untuk setiap beban kerja. Untuk setiap beban kerja, satu atau beberapa pendekatan penyebaran yang disarankan disediakan, berdasarkan persyaratan dan pendekatan yang dijelaskan dalam artikel ini.
Aplikasi lini bisnis untuk perusahaan
Contoso, Ltd., adalah perusahaan manufaktur besar. Perusahaan menerapkan aplikasi lini bisnis untuk mengelola beberapa komponen proses keuangannya.
Persyaratan bisnis: Informasi yang dikelola sistem sulit diganti, sehingga data perlu dipertahankan dengan andal. Arsitek mengatakan bahwa sistem perlu menimbulkan waktu henti sesedikit mungkin dan kehilangan data sesedikit mungkin. Karyawan Contoso menggunakan sistem sepanjang hari kerja, jadi performa tinggi penting untuk menghindari menjaga anggota tim tetap menunggu. Biaya juga menjadi perhatian, karena tim keuangan harus membayar solusinya.
Pendekatan yang disarankan: Penyebaran zona-redundan dengan pencadangan di seluruh wilayah memberikan beberapa lapisan ketahanan dengan performa tinggi.
Aplikasi internal
Fourth Coffee adalah bisnis kecil. Perusahaan sedang mengembangkan aplikasi internal baru yang dapat digunakan karyawan untuk mengirimkan lembar waktu.
Persyaratan bisnis: Untuk beban kerja ini, efisiensi biaya adalah perhatian utama. Fourth Coffee mengevaluasi dampak bisnis dari waktu henti dan memutuskan bahwa aplikasi tidak perlu memprioritaskan ketahanan atau performa. Perusahaan menerima risiko bahwa pemadaman di zona atau wilayah ketersediaan Azure mungkin membuat aplikasi tidak tersedia untuk sementara waktu.
Pendekatan yang disarankan:
- Penyebaran redundan secara lokal dengan cadangan di seluruh wilayah memiliki biaya terendah, tetapi juga memiliki risiko yang signifikan.
- Penyebaran zona-redundan dengan pencadangan di seluruh wilayah memberikan ketahanan yang lebih baik, tetapi dengan biaya yang sedikit lebih tinggi.
Migrasi aplikasi warisan
Fabrikam, Inc., memigrasikan aplikasi warisan dari pusat data lokal ke Azure. Implementasi akan menggunakan pendekatan IaaS yang didasarkan pada komputer virtual. Aplikasi ini tidak dirancang untuk lingkungan cloud, dan komunikasi antara tingkat aplikasi dan database sangat cerewet.
Persyaratan bisnis: Performa adalah prioritas untuk aplikasi ini. Ketahanan juga penting, dan aplikasi harus terus berfungsi meskipun pusat data Azure mengalami pemadaman.
Pendekatan yang disarankan:
- Fabrikan harus terlebih dahulu mencoba penyebaran zona-redundan. Mereka harus memverifikasi performa memenuhi persyaratan mereka.
- Jika performa solusi zona-redundan tidak dapat diterima, pertimbangkan penyebaran zonal (disematkan), dengan penyebaran pasif di beberapa zona ketersediaan (DR dalam wilayah).
Aplikasi layanan kesehatan
Lamna Healthcare Company menerapkan sistem catatan kesehatan elektronik baru di Azure.
Persyaratan bisnis: Karena sifat data yang disimpan solusi ini, residensi data sangat penting. Lamna beroperasi di bawah kerangka kerja peraturan ketat yang mengamanatkan bahwa data harus tetap berada di lokasi tertentu.
Pendekatan yang disarankan:
- Penyebaran multi-wilayah multi-zona, jika ada beberapa wilayah yang sesuai dengan persyaratan residensi data Lamna.
- Jika hanya ada satu wilayah yang sesuai dengan kebutuhan mereka, pertimbangkan penyebaran zona-redundan atau penyebaran zona-redundan dengan cadangan di seluruh wilayah menyediakan solusi satu wilayah
Sistem perbankan
Woodgrove Bank menjalankan operasi perbankan intinya dari solusi besar yang disebarkan ke Azure.
Persyaratan bisnis: Ini adalah sistem misi penting. Pemadaman apa pun dapat menyebabkan dampak finansial besar bagi pelanggan. Akibatnya, Woodgrove Bank memiliki toleransi risiko yang sangat rendah. Sistem membutuhkan tingkat keandalan tertinggi yang mungkin, dan arsitektur perlu mengurangi risiko kegagalan apa pun yang dapat dimitigasi.
Pendekatan yang disarankan: Untuk sistem misi penting, gunakan penyebaran multi-wilayah multi-zona. Pastikan wilayah tersebut sesuai dengan persyaratan residensi data perusahaan.
Software as a service (SaaS)
Proseware, Inc., membangun perangkat lunak yang digunakan oleh perusahaan di seluruh dunia. Basis pengguna perusahaan didistribusikan secara geografis secara luas.
Persyaratan bisnis: Proseware perlu memungkinkan setiap pelanggannya memilih wilayah penyebaran yang dekat dengan pelanggan. Mengaktifkan pilihan ini penting untuk latensi dan untuk persyaratan residensi data pelanggan.
Pendekatan yang disarankan:
- Penyebaran multi-wilayah multi-zona biasanya merupakan pilihan yang baik untuk penyedia SaaS, terutama ketika digunakan dalam pola Stempel Penyebaran.
- Penyebaran zona redundan satu wilayah bersama dengan solusi akselerasi lalu lintas global, seperti Azure Front Door.
Tautan terkait
Berikut adalah beberapa arsitektur referensi dan contoh skenario untuk solusi multi-zona dan multi-wilayah:
- Garis besar aplikasi web redundan zona yang sangat tersedia
- Aplikasi web multi-wilayah yang sangat tersedia
- Aplikasi N-tier multi-wilayah
- Aplikasi web multi-tingkat dibuat untuk HA/DR
Banyak layanan Azure memberikan panduan tentang cara menggunakan beberapa zona ketersediaan, termasuk contoh berikut:
- Azure Site Recovery: Mengaktifkan pemulihan bencana Azure VM antar zona ketersediaan
- Azure NetApp Files: Memahami replikasi lintas zona Azure NetApp Files
- Redundansi Azure Storage
Daftar periksa keandalan
Lihat kumpulan rekomendasi lengkap.