Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
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 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, trade-off yang terlibat dalam setiap pendekatan, dan efek setiap pendekatan pada pilar inti Azure Well-Architected Framework.
Wilayah Azure yang Anda gunakan untuk solusi Anda adalah pilihan penting. Panduan Pilih Wilayah Azure menjelaskan cara memilih dan beroperasi di beberapa wilayah geografis. Cara Anda menggunakan wilayah dan zona ketersediaan dalam solusi Anda juga memengaruhi beberapa pilar Well-Architected Framework:
Keandalan: 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 mengharuskan Anda untuk menyebarkan lebih banyak sumber daya daripada pendekatan 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 sering kali lebih tinggi ketika Anda memiliki persyaratan bisnis yang komprehensif.
Efisiensi Performa: Zona ketersediaan terhubung bersama melalui tautan jaringan dengan bandwidth tinggi dan latensi rendah. Tautan ini cukup bagi sebagian besar beban kerja untuk mengaktifkan replikasi dan komunikasi sinkron di seluruh zona. Namun, jika Anda menguji beban kerja dan menentukan bahwa beban kerja 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. Untuk solusi yang sangat tersedia, Anda mungkin juga 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.
Pilar Keamanan berlaku terlepas dari bagaimana Anda merancang solusi Anda. 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.
Petunjuk / Saran
Untuk banyak beban kerja produksi, penyebaran zona-redundan memberikan keseimbangan terbaik dari trade-off. 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 lainnya ketika Anda memerlukan manfaat spesifik yang diberikan pendekatan tersebut, tetapi ketahui trade-off.
Definisi
| Istilah | Definition |
|---|---|
| Active-active | Arsitektur di mana beberapa instans solusi secara aktif memproses permintaan secara bersamaan. |
| Active-passive | Arsitektur di mana satu instans solusi ditetapkan sebagai lalu lintas utama dan proses, dan satu atau beberapa instans sekunder disebarkan untuk melayani lalu lintas jika instans utama 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 zona ketersediaan lainnya dan memiliki infrastruktur daya, pendinginan, dan jaringannya sendiri. Banyak wilayah mendukung zona ketersediaan. |
| Datacenter | 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 berpasangan | 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. |
Memahami bagaimana wilayah dan zona ketersediaan diatur di Azure
Azure memiliki banyak pusat data di seluruh dunia. 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 dikenal sebagai arsitektur wilayah.
Banyak wilayah Azure menyediakan zona ketersediaan, yang merupakan grup pusat data terpisah. Dalam suatu wilayah, zona ketersediaan cukup dekat untuk memiliki koneksi latensi rendah ke zona ketersediaan lain tetapi cukup jauh untuk mengurangi kemungkinan lebih dari satu zona dipengaruhi oleh pemadaman lokal atau cuaca. Zona ketersediaan memiliki infrastruktur daya, pendinginan, dan jaringan independen. Mereka dirancang sehingga jika satu zona mengalami pemadaman, zona yang tersisa dapat terus mendukung layanan regional, kapasitas, dan ketersediaan tinggi.
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 zona disematkan ke zona ketersediaan tertentu. Anda dapat menggabungkan beberapa penyebaran zona di berbagai zona untuk memenuhi persyaratan keandalan tinggi. Anda bertanggung jawab untuk mengelola replikasi data dan mendistribusikan permintaan di seluruh zona. Jika pemadaman terjadi dalam satu zona ketersediaan, Anda bertanggung jawab atas failover ke zona ketersediaan lain.
Sumber daya redundan zona tersebar di beberapa zona ketersediaan. Microsoft mengelola distribusi permintaan dan replikasi data di seluruh zona. Jika pemadaman terjadi dalam satu zona ketersediaan, Microsoft mengelola failover secara otomatis.
Layanan Azure mendukung salah satu atau kedua pendekatan ini. Solusi Platform as a service (PaaS) biasanya mendukung penyebaran zona-redundan. Solusi 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.
Microsoft mencoba menggunakan pendekatan yang paling tidak mengganggu selama penyebaran pembaruan layanan. Misalnya, Microsoft 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 berlangsung. Namun, pada akhirnya tim beban kerja bertanggung jawab untuk memastikan bahwa 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. Pertimbangkan provisi berlebih, yang 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 cara Azure menggunakan wilayah dan zona ketersediaan, lihat Wilayah Azure dan zona ketersediaan.
Memahami tanggung jawab bersama
Prinsip tanggung jawab bersama menjelaskan bagaimana tanggung jawab dibagi antara penyedia cloud dan Anda. Bergantung pada jenis layanan yang Anda gunakan, Anda mungkin mengambil lebih banyak atau kurang tanggung jawab 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. Tanggung jawab ini mungkin mencakup replikasi data, failover, failback, dan tugas lain yang terkait dengan pengoperasian sistem terdistribusi.
Kode Anda sendiri perlu mengikuti praktik dan pola desain yang direkomendasikan untuk menangani kegagalan dengan anggun. Praktik ini sangat penting selama operasi failover, seperti operasi yang terjadi ketika zona ketersediaan atau failover wilayah terjadi, karena failover antara zona atau wilayah sering mengharuskan aplikasi Anda untuk 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. Diskusi antara perancang solusi dan pemangku kepentingan bisnis harus mendorong persyaratan ini.
Toleransi risiko
Organisasi yang berbeda memiliki berbagai tingkat toleransi risiko. Bahkan dalam satu organisasi, toleransi risiko sering berbeda berdasarkan beban kerja. Sebagian besar beban kerja tidak memerlukan ketersediaan yang sangat tinggi. Namun, beberapa beban kerja sangat penting sehingga perlu dimitigasi bahkan tidak mungkin berisiko, seperti bencana alam utama yang memengaruhi area geografis yang luas.
Tabel berikut mencantumkan beberapa risiko umum yang harus Anda pertimbangkan di lingkungan cloud.
| Risiko | Examples | Kemungkinan |
|---|---|---|
| Pemadaman perangkat keras | - Masalah dengan hard disk atau peralatan jaringan - Boot ulang 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 daerah metropolitan |
Menengah |
| 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 |
Low |
Sangat ideal untuk mengurangi setiap kemungkinan risiko untuk setiap beban kerja. Namun, pendekatan ini tidak praktis atau hemat biaya. Penting untuk berdiskusi terbuka dengan pemangku kepentingan bisnis sehingga Anda dapat membuat keputusan berdasarkan informasi tentang risiko yang harus Anda mitigasi.
Petunjuk / Saran
Terlepas dari target keandalan, semua beban kerja harus memiliki beberapa mitigasi untuk pemulihan bencana (DR). 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 dapat diterima dan risiko mana yang perlu mitigasi.
Persyaratan keandalan
Penting untuk memahami persyaratan keandalan untuk beban kerja Anda, misalnya menyetujui target pemulihan seperti tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO). Persyaratan keandalan 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 Strategi arsitektur untuk mengidentifikasi dan memberi peringkat alur.
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 menentukan ketersediaan layanan mungkin tidak selalu selaras dengan cara Anda menilai 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.
Lokasi Penyimpanan 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 skenario 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.
Nota
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 Azure global 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 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. Pastikan Anda mengikuti prinsip kesederhanaan.
Contoh skenario
Dengan menyediakan wilayah dan zona ketersediaan, Azure memungkinkan Anda memilih pendekatan penyebaran yang sesuai dengan kebutuhan Anda. Setiap pendekatan memberikan manfaat khusus dan menimbulkan biaya terkait.
Untuk mengilustrasikan pendekatan penyebaran yang dapat Anda gunakan, pertimbangkan contoh skenario. Misalkan Anda ingin 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 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 berikut ini meringkas beberapa kekhawatiran pilar.
| Pilar | Redundan secara lokal | Zonal (disematkan) | Zone-redundant | Multi-wilayah |
|---|---|---|---|---|
| Reliability | 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 Operasi | Persyaratan operasional rendah | Persyaratan operasional tinggi | Persyaratan operasional rendah | Persyaratan operasional tinggi |
Tabel berikut ini meringkas beberapa pendekatan yang bisa Anda gunakan dan pengaruhnya terhadap arsitektur Anda.
| Kekhawatiran arsitektur | Redundan secara lokal | Zonal (disematkan) | Zone-redundant | Multi-wilayah |
|---|---|---|---|---|
| Kepatuhan terhadap residensi data | High | High | High | 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 skenario, 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 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 dapat 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, penurunan performa ini tidak menjadi perhatian bagi sebagian besar beban kerja.
Tabel berikut ini meringkas beberapa kekhawatiran pilar.
| Pilar | Dampak |
|---|---|
| Reliability | 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 mungkin berada di zona ketersediaan yang berbeda, sehingga komponen yang sangat sensitif terhadap latensi dapat mengalami performa yang lebih rendah. |
| Keunggulan Operasi | Efisiensi operasional yang tinggi. Anda hanya perlu menyebarkan dan mengelola satu instans dari setiap sumber daya. |
Tabel berikut 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.
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 infrastruktur sebagai kode (IaC) sehingga Anda dapat dengan cepat menyebarkan ulang ke wilayah lain jika bencana besar terjadi. Pastikan bahwa alat dan proses penyebaran Anda tangguh seperti 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, yang dikenal sebagai titik pemulihan Anda. Anda biasanya dapat mengontrol frekuensi pencadangan sehingga Anda dapat memenuhi RPO Anda.
Tabel berikut ini meringkas beberapa kekhawatiran pilar.
| Pilar | Dampak |
|---|---|
| Reliability | 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 mungkin berada di zona ketersediaan yang berbeda, sehingga komponen yang sangat sensitif terhadap latensi dapat mengalami performa yang lebih rendah. |
| Keunggulan Operasi | Selama pemadaman apa pun dalam suatu wilayah:Efisiensi operasional rendah. Failover adalah tanggung jawab Anda dan mungkin memerlukan operasi manual dan penyebaran ulang. |
Tabel berikut 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 dikenal sebagai 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 zonal, Anda mengasumsikan 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, seperti dengan menggunakan 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 dikenal sebagai DR di wilayah atau DR metro.
Tabel berikut ini meringkas beberapa kekhawatiran pilar.
| Pilar | Dampak |
|---|---|
| Reliability |
-
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 Operasi | 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 berikut 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 (VM). 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. Untuk mencantumkan SKU VM mana yang tersedia di setiap zona ketersediaan, lihat Memeriksa ketersediaan SKU VM.
Petunjuk / Saran
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 terpasang di dalam layanan akan menyebarkan permintaan di seluruh instans di setiap zona ketersediaan. Layanan itu sendiri mencakup 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. Transaksi dianggap selesai hanya ketika semua perubahan ini selesai. Proses ini memastikan bahwa setiap zona ketersediaan selalu memiliki salinan data up-to-date. 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. Namun, karena data direplikasi secara sinkron, aplikasi Anda harus menunggu data ditulis di beberapa lokasi terpisah yang mungkin berada di berbagai bagian area metropolitan. Untuk sebagian besar aplikasi, latensi 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 berikut ini meringkas beberapa kekhawatiran pilar.
| Pilar | Dampak |
|---|---|
| Reliability | Keandalan tinggi. Layanan tahan terhadap pemadaman pusat data atau zona ketersediaan. Data direplikasi secara sinkron di seluruh zona ketersediaan 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 Operasi | 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 berikut 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 (AKS), Azure Storage, Azure SQL, Azure Service Bus, dan banyak layanan 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 tangguh seperti 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, yang dikenal sebagai titik pemulihan Anda. Anda biasanya dapat mengontrol frekuensi cadangan untuk memenuhi RPO Anda.
Petunjuk / Saran
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 berikut ini meringkas beberapa kekhawatiran pilar.
| Pilar | Dampak |
|---|---|
| Reliability | Keandalan yang sangat tinggi. Layanan tahan terhadap pemadaman pusat data atau zona ketersediaan. Untuk sebagian besar layanan, data direplikasi di seluruh zona secara otomatis 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 Operasi |
-
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 berikut 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 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 selengkapnya tentang solusi multi-wilayah aktif-aktif, lihat Pola stempel penyebaran dan pola Geode.
Replikasi data
Komunikasi lintas wilayah jauh lebih lambat daripada komunikasi intra-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. Untuk informasi selengkapnya tentang latensi jaringan yang diharapkan saat Anda terhubung di antara dua wilayah, lihat Statistik latensi pulang pergi jaringan Azure.
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 direplikasi ke wilayah lain.
Tabel berikut ini meringkas beberapa kekhawatiran pilar.
| Pilar | Dampak |
|---|---|
| Reliability | 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 Operasi | 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 berikut 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 berikut ini meringkas beberapa kekhawatiran pilar.
| Pilar | Dampak |
|---|---|
| Reliability | Keandalan yang sangat tinggi. Solusi ini tahan terhadap pemadaman pusat data, zona ketersediaan, atau seluruh wilayah. Data selalu disinkronkan di seluruh wilayah. Jadi, meskipun seluruh wilayah gagal, data Anda tetap lengkap dan tersedia 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 Operasi | 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 berikut 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 Penyimpanan, Anda dapat menggunakan penyimpanan geo-redundan (GRS) dengan wilayah yang dipasangkan. Jika GRS tidak tersedia, pertimbangkan untuk menggunakan fitur seperti replikasi objek 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.
Cara layanan Azure mendukung pendekatan penyebaran
Penting untuk memahami detail spesifik layanan Azure yang Anda gunakan. Misalnya, beberapa layanan Azure mengharuskan Anda menyiapkan konfigurasi zona ketersediaannya saat pertama kali menyebarkan sumber daya, sementara layanan 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.
Gunakan contoh kasus
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 (LOB) untuk mengelola beberapa komponen proses keuangannya.
Persyaratan bisnis: Informasi yang dikelola sistem sulit diganti, sehingga data perlu dipertahankan dengan andal. Arsitek membutuhkan sistem untuk menimbulkan waktu henti dan kehilangan data sesedikit mungkin. Karyawan Contoso menggunakan sistem sepanjang hari kerja, jadi performa tinggi penting untuk menghindari menjaga anggota tim 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. Mereka berencana menggunakan pendekatan IaaS yang didasarkan pada VM. 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:
Fabrikam harus terlebih dahulu mencoba penyebaran zona-redundan. Mereka harus memverifikasi bahwa performa memenuhi persyaratan mereka.
Jika performa solusi zona-redundan tidak dapat diterima, mereka harus mempertimbangkan 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, mereka harus mempertimbangkan penyebaran zona-redundan atau penyebaran zona-redundan dengan cadangan di seluruh wilayah yang menyediakan solusi wilayah tunggal.
Sistem perbankan
Woodgrove Bank menjalankan operasi perbankan intinya dari solusi besar yang disebarkan ke Azure.
Persyaratan bisnis: Sistem ini sangat 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, mereka harus menggunakan penyebaran multi-wilayah multi-zona dan memastikan bahwa wilayah tersebut sesuai dengan persyaratan residensi data perusahaan.
Perangkat lunak sebagai layanan
Proseware, Inc., membangun perangkat lunak yang digunakan 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 perangkat lunak sebagai layanan (SaaS), terutama ketika digunakan dalam pola Stempel Penyebaran.
Penyebaran zona redundan satu wilayah dengan solusi akselerasi lalu lintas global, seperti Azure Front Door.
Langkah selanjutnya
Arsitektur referensi dan contoh skenario berikut adalah untuk solusi multi-zona dan multi-wilayah:
- Garis besar aplikasi web redundan zona yang sangat tersedia
- Aplikasi web multi-wilayah dengan ketersediaan tinggi
- aplikasi N-tingkat multi-wilayah
- Aplikasi web multi-tingkat yang dibuat untuk ketersediaan tinggi dan DR
Gunakan layanan Azure berikut untuk menerapkan solusi di beberapa zona ketersediaan: