Wilayah zona pendaratan

Artikel ini menjelaskan cara zona pendaratan menggunakan wilayah Azure. Arsitektur zona pendaratan Azure bersifat agnostik wilayah, tetapi Anda perlu menentukan wilayah Azure untuk menyebarkan arsitektur zona pendaratan Azure Anda. Panduan berikut menjelaskan cara menambahkan wilayah ke zona pendaratan yang ada dan juga memberikan pertimbangan saat Anda memigrasikan properti Azure Anda ke wilayah yang berbeda.

Dalam beberapa situasi, Anda harus menyebarkan aplikasi ke beberapa wilayah Azure untuk mendukung ketersediaan tinggi dan persyaratan bisnis pemulihan bencana Anda. Anda mungkin tidak memiliki kebutuhan langsung untuk aplikasi multi-wilayah, tetapi Anda harus merancang platform zona pendaratan Azure Anda untuk mendukung beberapa wilayah, terutama untuk layanan konektivitas, identitas, dan manajemen. Pastikan Anda dapat dengan cepat mengaktifkan dan mendukung zona pendaratan aplikasi multi-wilayah.

Untuk informasi selengkapnya, lihat Memilih wilayah Azure.

Zona pendaratan dan wilayah Azure

Zona pendaratan Azure terdiri dari sekumpulan sumber daya dan konfigurasi. Beberapa item ini, seperti grup manajemen, kebijakan, dan penetapan peran, disimpan di tingkat penyewa atau grup manajemen dalam arsitektur zona pendaratan Azure. Sumber daya ini tidak disebarkan ke wilayah tertentu dan sebaliknya disebarkan secara global. Namun, Anda masih perlu menentukan wilayah penyebaran karena Azure melacak beberapa metadata sumber daya di penyimpanan metadata regional.

Sumber daya lain disebarkan secara regional. Bergantung pada konfigurasi zona pendaratan Anda sendiri, Anda mungkin memiliki beberapa atau semua sumber daya yang disebarkan secara regional berikut:

• Ruang kerja Log Azure Monitor, termasuk solusi yang dipilih
• Akun Azure Automation
• Grup sumber daya, untuk sumber daya lainnya

Jika Anda menyebarkan topologi jaringan, Anda juga perlu memilih wilayah Azure untuk menyebarkan sumber daya jaringan. Wilayah ini bisa berbeda dari wilayah yang Anda gunakan untuk sumber daya yang tercantum dalam daftar sebelumnya. Bergantung pada topologi yang Anda pilih, sumber daya jaringan yang Anda sebarkan mungkin meliputi:

• Azure Virtual WAN, termasuk hub Virtual WAN
• Jaringan virtual Azure
• Gateway VPN
• Gateway Azure ExpressRoute
• Azure Firewall
• Paket Azure DDoS Protection
• Zona DNS privat Azure, termasuk zona untuk Azure Private Link
• Grup sumber daya, untuk berisi sumber daya sebelumnya

Catatan

Untuk meminimalkan efek pemadaman regional, kami sarankan Anda menempatkan sumber daya di wilayah yang sama dengan grup sumber daya. Untuk informasi selengkapnya, lihat Perataan lokasi grup sumber daya.

Menambahkan wilayah baru ke zona pendaratan yang sudah ada

Anda harus mempertimbangkan strategi multi-wilayah, baik dari awal perjalanan cloud Anda, atau dengan memperluas ke lebih banyak wilayah Azure setelah Anda menyelesaikan penyebaran awal arsitektur zona pendaratan Azure Anda. Misalnya, jika Anda menggunakan Azure Site Recovery untuk mengaktifkan pemulihan bencana untuk komputer virtual, Anda mungkin ingin mereplikasinya ke wilayah Azure yang berbeda. Untuk menambahkan wilayah Azure dalam arsitektur zona arahan Azure Anda, pertimbangkan rekomendasi berikut:

Luas	Rekomendasi
Grup pengelolaan	Tidak ada tindakan yang diperlukan. Grup manajemen tidak terikat pada suatu wilayah. Anda tidak boleh membuat struktur grup manajemen berdasarkan wilayah.
Langganan	Langganan tidak terkait dengan wilayah.
Kebijakan Azure	Buat perubahan dalam Azure Policy jika Anda menetapkan kebijakan untuk menolak penyebaran sumber daya ke semua wilayah dengan menentukan daftar wilayah Azure "diizinkan". Perbarui tugas ini untuk mengizinkan penyebaran sumber daya ke wilayah baru yang ingin Anda aktifkan.
Kontrol akses berbasis peran (RBAC)	Tidak ada tindakan yang diperlukan. Azure RBAC tidak terikat pada suatu wilayah.
Pemantauan dan pengelogan	Putuskan apakah akan menggunakan satu ruang kerja Log Azure Monitor untuk semua wilayah atau membuat beberapa ruang kerja untuk mencakup berbagai wilayah geografis. Setiap pendekatan memiliki kelebihan dan kekurangan, termasuk potensi biaya jaringan lintas wilayah. Untuk informasi selengkapnya, lihat Mendesain arsitektur ruang kerja Analitik Log.
Jaringan	Jika Anda menyebarkan topologi jaringan, Virtual WAN, atau hub tradisional dan spoke, perluas jaringan ke wilayah Azure baru. Buat hub jaringan lain nya dengan menyebarkan sumber daya jaringan yang diperlukan ke langganan Konektivitas yang ada di wilayah Azure yang baru. Azure Virtual Network Manager dapat memudahkan untuk memperluas dan mengelola jaringan virtual dalam skala besar di beberapa wilayah. Dari perspektif Sistem Nama Domain (DNS), Anda mungkin juga ingin menyebarkan penerus, jika Anda menggunakannya, ke wilayah Azure baru. Gunakan penerus untuk jaringan virtual spoke di wilayah baru untuk resolusi. Zona Azure DNS adalah sumber daya global dan tidak terkait dengan satu wilayah Azure, sehingga tidak memerlukan tindakan apa pun.
Identitas	Jika Anda menyebarkan Active Directory Domain Services atau Microsoft Entra Domain Services ke langganan identitas atau spoke Anda, perluas layanan ke wilayah Azure baru.

Catatan

Anda juga harus menggunakan zona ketersediaan untuk ketersediaan tinggi dalam suatu wilayah. Periksa apakah wilayah dan layanan Anda mendukung zona ketersediaan.

Microsoft Cloud for Sovereignty memiliki panduan untuk membatasi layanan dan wilayah. Anda dapat menggunakan panduan ini untuk menerapkan konfigurasi layanan untuk membantu pelanggan mencapai kebutuhan residensi data mereka.

Pendekatan tingkat tinggi

Saat Anda memperluas zona pendaratan Azure ke wilayah baru, pertimbangkan untuk mengikuti langkah-langkah di bagian ini. Sebelum memulai, Anda perlu memutuskan wilayah Azure baru, atau beberapa wilayah Azure, untuk diperluas.

Jaringan

Arsitektur hub dan spoke tradisional

Tip

Lihat arsitektur hub-and-spoke tradisional.

1. Tentukan apakah Anda memerlukan langganan zona pendaratan platform baru. Kami menyarankan agar sebagian besar pelanggan menggunakan langganan Koneksi ivity yang ada, bahkan ketika mereka menggunakan beberapa wilayah.

2. Dalam langganan, buat grup sumber daya baru di wilayah target baru.

3. Buat jaringan virtual hub baru di wilayah target baru.

4. Jika berlaku, sebarkan Azure Firewall atau appliance virtual jaringan (NVA) ke jaringan virtual hub baru Anda.

5. Jika berlaku, sebarkan gateway jaringan virtual untuk konektivitas VPN atau ExpressRoute, dan buat koneksi. Pastikan sirkuit ExpressRoute dan lokasi lokal Anda mengikuti rekomendasi ketahanan Microsoft. Untuk informasi selengkapnya, lihat Merancang untuk pemulihan bencana dengan peering privat ExpressRoute.

6. Buat peering jaringan virtual antara jaringan virtual hub baru dan jaringan virtual hub lainnya.

7. Buat dan konfigurasikan perutean yang diperlukan, seperti Azure Route Server atau rute yang ditentukan pengguna.

8. Jika diperlukan, sebarkan penerus DNS untuk wilayah target baru dan tautkan ke zona DNS privat apa pun untuk mengaktifkan resolusi nama.

   • Beberapa pelanggan mungkin mengonfigurasi resolusi nama pada pengontrol domain Windows Server Active Directory mereka dalam langganan zona pendaratan platform Identitas .

Untuk menghosting beban kerja, Anda kemudian dapat menggunakan peering jaringan virtual untuk menghubungkan spoke zona pendaratan aplikasi ke jaringan virtual hub baru di wilayah baru.

Tip

Virtual Network Manager dapat mempermudah perluasan dan pengelolaan jaringan virtual dalam skala besar di beberapa wilayah.

Rancangan Azure Virtual WAN

Tip

Lihat arsitektur Virtual WAN.

1. Dalam Virtual WAN Anda yang ada, buat hub virtual baru di wilayah target baru.

2. Sebarkan Azure Firewall atau appliance virtual jaringan (NVA) lain yang didukung ke hub virtual baru Anda. Konfigurasikan niat perutean virtual WAN dan kebijakan perutean untuk merutekan lalu lintas melalui hub virtual aman baru.

3. Jika berlaku, sebarkan gateway jaringan virtual untuk konektivitas VPN atau ExpressRoute di hub virtual baru dan buat koneksi. Pastikan sirkuit ExpressRoute dan lokasi lokal Anda mengikuti rekomendasi ketahanan Microsoft. Untuk informasi selengkapnya, lihat Merancang untuk pemulihan bencana dengan peering privat ExpressRoute.

4. Buat dan konfigurasikan perutean lain yang Anda butuhkan, seperti rute statis hub virtual.

5. Jika berlaku, sebarkan penerus DNS untuk wilayah target baru dan tautkan ke zona DNS privat apa pun untuk mengaktifkan resolusi.

   • Beberapa pelanggan mungkin mengonfigurasi resolusi nama pada pengontrol domain Direktori Aktif mereka dalam langganan zona pendaratan platform Identitas .

   • Dalam penyebaran Virtual WAN, ini harus berada di jaringan virtual spoke yang terhubung ke hub virtual melalui koneksi jaringan virtual, mengikuti pola ekstensi Hub virtual.

Untuk menghosting beban kerja, Anda kemudian dapat menggunakan peering jaringan virtual untuk menghubungkan spoke zona pendaratan aplikasi ke jaringan virtual hub baru di wilayah baru.

Identitas

Tip

Tinjau area desain zona arahan Azure untuk manajemen identitas dan akses.

1. Tentukan apakah Anda memerlukan langganan zona pendaratan platform baru. Kami menyarankan agar sebagian besar pelanggan menggunakan langganan Identitas yang ada, bahkan ketika mereka menggunakan beberapa wilayah.

2. Buat grup sumber daya baru di wilayah target baru.

3. Buat jaringan virtual baru di wilayah target baru.

4. Buat peering jaringan virtual kembali ke jaringan virtual hub regional yang baru dibuat dalam langganan Koneksi ivity.

5. Sebarkan beban kerja identitas, seperti komputer virtual pengontrol domain Active Directory, ke jaringan virtual baru.

   • Anda mungkin perlu melakukan lebih banyak penyiapan beban kerja setelah disediakan, seperti langkah-langkah konfigurasi berikut:

     • Promosikan komputer virtual pengontrol domain Active Directory ke domain Direktori Aktif yang ada.

     • Buat situs dan subnet Direktori Aktif baru.

     • Mengonfigurasi pengaturan server DNS seperti penerus kondisional.

Memindahkan estate Azure Anda ke wilayah baru

Anda mungkin kadang-kadang perlu memindahkan seluruh properti Azure Anda ke wilayah yang berbeda. Misalnya, Anda menyebarkan zona pendaratan dan beban kerja ke wilayah Azure di negara atau wilayah tetangga, lalu wilayah Azure baru diluncurkan di negara atau wilayah asal Anda. Anda mungkin memilih untuk memindahkan semua beban kerja Anda ke wilayah baru untuk meningkatkan latensi komunikasi, atau untuk mematuhi persyaratan residensi data.

Catatan

Artikel ini menyediakan informasi tentang memigrasikan komponen zona pendaratan estate Anda. Untuk informasi selengkapnya, lihat Merelokasi beban kerja cloud.

Konfigurasi zona pendaratan global

Sebagian besar konfigurasi zona pendaratan yang disebarkan secara global biasanya tidak perlu dimodifikasi saat Anda memindahkan wilayah. Namun, pastikan Anda memeriksa penetapan kebijakan apa pun yang membatasi penyebaran wilayah dan memperbarui kebijakan untuk memungkinkan penyebaran ke wilayah baru.

Sumber daya zona pendaratan regional

Sumber daya zona pendaratan khusus wilayah sering kali memerlukan pertimbangan yang lebih besar karena Anda tidak dapat memindahkan beberapa sumber daya Azure antar wilayah. Pertimbangkan pendekatan berikut:

1. Tambahkan wilayah tujuan sebagai wilayah tambahan ke zona arahan Anda: Untuk informasi selengkapnya, lihat Menambahkan wilayah baru ke zona pendaratan yang sudah ada.

2. Menyebarkan komponen terpusat di wilayah tujuan: Misalnya, sebarkan ruang kerja Log Azure Monitor baru di wilayah tujuan Anda sehingga beban kerja dapat mulai menggunakan komponen baru setelah Anda memigrasikan beban kerja.

3. Migrasikan beban kerja Anda dari wilayah sumber ke wilayah tujuan: Selama proses migrasi beban kerja, konfigurasi ulang sumber daya untuk menggunakan komponen jaringan wilayah tujuan, komponen identitas, ruang kerja Log Azure Monitor, dan sumber daya regional lainnya.

4. Menonaktifkan sumber daya di wilayah sumber setelah Anda menyelesaikan migrasi.

Pertimbangkan tips berikut saat Anda memigrasikan sumber daya zona pendaratan di seluruh wilayah:

• Gunakan infrastruktur sebagai kode: Gunakan Bicep, templat Azure Resource Manager (templat ARM), Terraform, pembuatan skrip, atau pendekatan serupa untuk mengekspor dan meniru kembali konfigurasi kompleks, seperti aturan untuk Azure Firewall.

• Otomatisasi: Gunakan skrip untuk memigrasikan sumber daya Automation antar wilayah.

• ExpressRoute: Pertimbangkan apakah Anda dapat menggunakan SKU Lokal ExpressRoute di wilayah tujuan Anda. Jika lingkungan lokal Anda berada dalam area metropolitan yang sama dengan wilayah Azure Anda, ExpressRoute Local dapat menyediakan opsi biaya lebih rendah dibandingkan dengan SKU ExpressRoute lainnya.

Langkah selanjutnya

Meningkatkan tata kelola zona pendaratan