Keandalan di Load Balancer

Artikel ini berisi rekomendasi keandalan khusus untuk Load Balancer, serta informasi terperinci tentang ketahanan regional Load Balancer dengan zona ketersediaan dan pemulihan bencana lintas wilayah dan kelangsungan bisnis.

Untuk gambaran umum arsitektur keandalan di Azure, lihat Keandalan Azure.

Rekomendasi keandalan

Bagian ini berisi rekomendasi untuk mencapai ketahanan dan ketersediaan. Setiap rekomendasi termasuk dalam salah satu dari dua kategori:

• Item kesehatan mencakup area seperti item konfigurasi dan fungsi yang tepat dari komponen utama yang membentuk Azure Workload Anda, seperti pengaturan konfigurasi Sumber Daya Azure, dependensi pada layanan lain, dan sebagainya.

• Item risiko mencakup area seperti persyaratan ketersediaan dan pemulihan, pengujian, pemantauan, penyebaran, dan item lain yang, jika dibiarkan tidak terselesaikan, meningkatkan kemungkinan masalah di lingkungan.

Matriks prioritas rekomendasi keandalan

Setiap rekomendasi ditandai sesuai dengan matriks prioritas berikut:

Gambar	Prioritas	Deskripsi
	Sangat Penting	Perbaikan langsung diperlukan.
	Medium	Perbaiki dalam waktu 3-6 bulan.
	Kurang Penting	Perlu ditinjau.

Ringkasan rekomendasi keandalan

Category	Prioritas	Rekomendasi
Ketersediaan		Pastikan Load Balancer Standar bersifat zona-redundan
		Pastikan bahwa kumpulan backend berisi setidaknya dua instans
Efisiensi Sistem		Menggunakan NAT Gateway alih-alih aturan keluar untuk beban kerja produksi
		Menggunakan SKU Load Balancer Standar

Ketersediaan

Pastikan Load Balancer Standar bersifat zona-redundan

Di wilayah yang mendukung zona ketersediaan, Load Balancer Standar harus disebarkan dengan redundansi zona. Load Balancer zona redundan memungkinkan lalu lintas dilayani oleh satu alamat IP frontend yang dapat bertahan dari kegagalan zona. IP frontend dapat digunakan untuk menjangkau semua anggota kumpulan backend (tidak terpengaruh) terlepas dari zona. Jika zona ketersediaan gagal, jalur data dapat bertahan selama zona yang tersisa di wilayah tersebut tetap sehat. Untuk informasi selengkapnya, lihat Load balancer zona-redundan.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with with regional or zonal public IP Addresses
resources
| where type == "microsoft.network/loadbalancers"
| where tolower(sku.name) != 'basic'
| mv-expand feIPconfigs = properties.frontendIPConfigurations
| extend
    feConfigName = (feIPconfigs.name),
    PrivateSubnetId = toupper(feIPconfigs.properties.subnet.id),
    PrivateIPZones = feIPconfigs.zones,
    PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
    JoinID = toupper(id)
| where isnotempty(PrivateSubnetId)
| where isnull(PrivateIPZones) or array_length(PrivateIPZones) < 2
| project name, feConfigName, id
| union (resources
    | where type == "microsoft.network/loadbalancers"
    | where tolower(sku.name) != 'basic'
    | mv-expand feIPconfigs = properties.frontendIPConfigurations
    | extend
        feConfigName = (feIPconfigs.name),
        PIPid = toupper(feIPconfigs.properties.publicIPAddress.id),
        JoinID = toupper(id)
    | where isnotempty(PIPid)
    | join kind=innerunique (
        resources
        | where type == "microsoft.network/publicipaddresses"
        | where isnull(zones) or array_length(zones) < 2
        | extend
            LBid = toupper(substring(properties.ipConfiguration.id, 0, indexof(properties.ipConfiguration.id, '/frontendIPConfigurations'))),
            InnerID = toupper(id)
    ) on $left.PIPid == $right.InnerID)
| project recommendationId = "lb-4", name, id, tags, param1="Zones: No Zone or Zonal", param2=strcat("Frontend IP Configuration:", " ", feConfigName)

Pastikan bahwa kumpulan backend berisi setidaknya dua instans

Sebarkan Load Balancer dengan setidaknya dua instans di backend. Satu kejadian bisa mengakibatkan satu titik kegagalan. Untuk membangun skala, Anda mungkin ingin memasangkan load balancer dengan Virtual Machine Scale Sets.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers which only have 1 backend pool defined or only 1 VM in the backend pool
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend bep = properties.backendAddressPools
| extend BackEndPools = array_length(bep)
| where BackEndPools == 0
| project recommendationId = "lb-2", name, id, Param1=BackEndPools, Param2=0, tags
| union (resources
        | where type =~ 'Microsoft.Network/loadBalancers'
        | extend bep = properties.backendAddressPools
        | extend BackEndPools = array_length(bep)
        | mv-expand bip = properties.backendAddressPools
        | extend BackendAddresses = array_length(bip.properties.loadBalancerBackendAddresses)
        | where BackendAddresses <= 1
        | project recommendationId = "lb-2", name, id, tags, Param1=BackEndPools, Param2=BackendAddresses)

Efisiensi Sistem

Menggunakan NAT Gateway alih-alih aturan keluar untuk beban kerja produksi

Aturan keluar mengalokasikan jumlah tetap port SNAT ke setiap instans komputer virtual dalam kumpulan backend. Metode alokasi ini dapat menyebabkan kelelahan port SNAT, terutama jika pola lalu lintas yang tidak merata mengakibatkan komputer virtual tertentu mengirim volume koneksi keluar yang lebih tinggi. Untuk beban kerja produksi, disarankan agar Anda menggabungkan Load Balancer Standar atau penyebaran subnet apa pun dengan Azure NAT Gateway. NAT Gateway secara dinamis mengalokasikan port SNAT di semua instans komputer virtual dalam subnet dan pada gilirannya mengurangi risiko kelelahan port SNAT.

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers with Outbound rules configured
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| extend outboundRules = array_length(properties.outboundRules)
| where outboundRules > 0
| project recommendationId = "lb-3", name, id, tags, Param1 = "outboundRules: >=1"

Menggunakan SKU Load Balancer Standar

Load Balancer SKU Standar mendukung zona ketersediaan dan ketahanan zona, sementara SKU Dasar tidak. Saat zona tidak berfungsi, Load Balancer Standar zona redundan Anda tidak akan terpengaruh dan penyebaran Anda dapat menahan kegagalan zona dalam suatu wilayah. Selain itu, Standard Load Balancer mendukung penyeimbangan beban lintas wilayah untuk memastikan bahwa aplikasi Anda tidak terpengaruh oleh kegagalan wilayah.

Catatan

Load balancer dasar tidak memiliki Perjanjian Tingkat Layanan (SLA).

Azure Resource Graph

// Azure Resource Graph Query
// Find all LoadBalancers using Basic SKU
resources
| where type =~ 'Microsoft.Network/loadBalancers'
| where sku.name == 'Basic'
| project recommendationId = "lb-1", name, id, tags, Param1=strcat("sku-tier: basic")

Dukungan zona ketersediaan

Zona ketersediaan Azure adalah setidaknya tiga grup pusat data yang terpisah secara fisik dalam setiap wilayah Azure. Pusat data dalam setiap zona dilengkapi dengan infrastruktur daya, pendinginan, dan jaringan independen. Dalam kasus kegagalan zona lokal, zona ketersediaan dirancang sehingga jika satu zona terpengaruh, layanan regional, kapasitas, dan ketersediaan tinggi didukung oleh dua zona yang tersisa.

Kegagalan dapat berkisar dari kegagalan perangkat lunak dan perangkat keras hingga peristiwa seperti gempa bumi, banjir, dan kebakaran. Toleransi terhadap kegagalan dicapai dengan redundansi dan isolasi logis layanan Azure. Untuk informasi selengkapnya tentang zona ketersediaan di Azure, lihat Wilayah dan zona ketersediaan.

Layanan berkemampuan zona ketersediaan Azure dirancang untuk memberikan tingkat keandalan dan fleksibilitas yang tepat. Mereka dapat dikonfigurasi dalam dua cara. Mereka dapat berupa zona redundan,dengan replikasi otomatis di seluruh zona, atau zonal, dengan instans yang disematkan ke zona tertentu. Anda juga dapat menggabungkan pendekatan ini. Untuk informasi selengkapnya tentang arsitektur zonal vs. zona-redundan, lihat Rekomendasi untuk menggunakan zona dan wilayah ketersediaan.

Azure Load Balancer mendukung skenario zona ketersediaan. Anda dapat menggunakan Load Balancer Standar untuk meningkatkan ketersediaan di seluruh skenario Anda dengan meratakan sumber daya dengan, dan distribusi di seluruh zona. Tinjau dokumen ini untuk memahami konsep-konsep ini dan panduan desain skenario mendasar.

Meskipun disarankan agar Anda menyebarkan Load Balancer dengan zona-redundansi, Load Balancer dapat berupa zona redundan, zonal, atau non-zonal. Pemilihan zona ketersediaan load balancer identik dengan pemilihan zona IP frontend-nya. Untuk penyeimbang beban publik, jika IP publik di frontend Load balancer adalah zona redundan maka load balancer juga zona-redundan. Jika IP publik di frontend load balancer adalah zonal, maka load balancer juga akan ditunjuk ke zona yang sama. Untuk mengonfigurasi properti terkait zona untuk load balancer Anda, pilih jenis frontend yang sesuai yang diperlukan.

Catatan

Tidak diperlukan untuk memiliki load balancer untuk setiap zona, melainkan memiliki penyeimbang beban tunggal dengan beberapa frontend (zonal atau zona redundan) yang terkait dengan kumpulan backend masing-masing akan melayani tujuan tersebut.

Prasyarat

• Untuk menggunakan zona ketersediaan dengan Load Balancer, Anda perlu membuat load balancer di wilayah yang mendukung zona ketersediaan. Untuk melihat wilayah mana yang mendukung zona ketersediaan, lihat daftar wilayah yang didukung.

• Gunakan SKU Standar untuk load balancer dan IP Publik untuk dukungan zona ketersediaan.

• Jenis SKU dasar tidak didukung.

• Untuk membuat sumber daya, Anda harus memiliki peran Kontributor Jaringan atau yang lebih tinggi.

Pembatasan

• Zona tidak dapat diubah, diperbarui, atau dibuat untuk sumber daya setelah dibuat.
• Sumber daya tidak dapat diperbarui dari zonal ke zona redundan atau sebaliknya setelah dibuat.

Penyeimbang muatan zona redundan

Di wilayah dengan zona ketersediaan, Load Balancer Standar dapat berlebihan zona dengan lalu lintas yang dilayani oleh satu alamat IP. Satu alamat IP frontend bertahan dari kegagalan zona. IP ujung depan dapat digunakan untuk menjangkau semua anggota kumpulan ujung belakang (tidak terpengaruh) apa pun zonanya. Hingga satu zona ketersediaan dapat gagal dan jalur data bertahan selama zona yang tersisa di wilayah tersebut tetap sehat.

Alamat IP ujung depan dilayani secara bersamaan oleh beberapa penyebaran infrastruktur independen di beberapa zona ketersediaan. Percobaan ulang atau pemulihan apa pun akan berhasil di zona lain yang tidak terpengaruh oleh kegagalan zona.

Catatan

VM 1,2, dan 3 dapat termasuk dalam subnet yang sama dan tidak harus berada di zona terpisah sebagai saran diagram.

Anggota di kumpulan backend load balancer biasanya dikaitkan dengan satu zona seperti dengan komputer virtual zona. Desain umum untuk beban kerja produksi adalah memiliki beberapa sumber daya zona. Misalnya, menempatkan komputer virtual dari zona 1, 2, dan 3 di backend load balancer dengan frontend zona redundan memenuhi prinsip desain ini.

Penyeimbang beban zona

Anda dapat memilih agar ujung depan dijamin untuk satu zona, yang dikenal sebagai zonal. Dengan skenario ini, satu zona di suatu wilayah melayani semua alur masuk atau keluar. Ujung depan Anda berbagi nasib dengan kesehatan zona. Jalur data tidak dipengaruhi oleh kegagalan di zona selain di mana ia dijamin. Anda dapat menggunakan ujung depan zonal untuk mengekspos alamat IP per Zona Ketersediaan.

Selain itu, penggunaan frontend zona secara langsung untuk endpoint dengan beban seimbang dalam setiap zona juga didukung. Anda dapat menggunakan konfigurasi ini untuk mengekspos per titik akhir dengan muatan seimbang zona untuk memantau setiap zona secara individu. Untuk titik akhir publik, Anda dapat mengintegrasikannya dengan produk load balancing DNS seperti Traffic Manager dan menggunakan satu nama DNS.

Untuk ujung depan load balancer publik, Anda tambahkan parameter zona ke IP publik. IP publik ini dirujuk oleh konfigurasi IP ujung depan yang digunakan oleh aturan masing-masing.

Untuk ujung depan load balancer internal, tambahkan parameter zona ke konfigurasi IP ujung depan load balancer internal. Ujung depan zonal menjamin alamat IP dalam subnet ke zona tertentu.

Load balancer non-zonal

Load Balancer juga dapat dibuat dalam konfigurasi non-zonal dengan menggunakan frontend "tanpa zona". Dalam skenario ini, load balancer publik akan menggunakan IP publik atau awalan IP publik, load balancer internal akan menggunakan IP privat. Opsi ini tidak memberikan jaminan redundansi.

Catatan

Semua alamat IP publik yang ditingkatkan dari SKU Dasar ke SKU Standar akan berjenis "tanpa zona". Pelajari cara Meningkatkan alamat IP publik di portal Azure.

Peningkatan SLA

Karena zona ketersediaan secara fisik terpisah dan menyediakan sumber daya, jaringan, dan pendinginan yang berbeda, SLA (Perjanjian tingkat layanan) dapat meningkat. Untuk informasi selengkapnya, lihat Perjanjian Tingkat Layanan (SLA) untuk Layanan Online.

Membuat sumber daya dengan zona ketersediaan diaktifkan

Untuk mempelajari cara memuat VM keseimbangan dalam zona atau di beberapa zona menggunakan Load Balancer, lihat Mulai Cepat: Membuat load balancer publik untuk memuat VM keseimbangan.

Catatan

• Zona tidak dapat diubah, diperbarui, atau dibuat untuk sumber daya setelah dibuat.
• Sumber daya tidak dapat diperbarui dari zonal ke zona redundan atau sebaliknya setelah dibuat.

Toleransi kegagalan

Komputer virtual dapat melakukan failover ke server lain dalam kluster, dengan sistem operasi VM dimulai ulang di server baru. Anda harus merujuk ke proses failover untuk pemulihan bencana, mengumpulkan komputer virtual dalam perencanaan pemulihan, dan menjalankan latihan pemulihan bencana untuk memastikan solusi toleransi kesalahan mereka berhasil.

Untuk informasi selengkapnya, lihat proses pemulihan situs.

Pengalaman zona tidak berfungsi

Zona redundansi tidak menyiratkan sarana data atau sarana kontrol tanpa hit. Alur zona berlebihan dapat menggunakan zona apa pun dan alur Anda akan menggunakan semua zona sehat di suatu wilayah. Dalam kegagalan zona, alur lalu lintas menggunakan zona sehat tidak terpengaruh.

Alur lalu lintas menggunakan zona pada saat kegagalan zona mungkin terpengaruh tetapi aplikasi dapat pulih. Lalu lintas berlanjut di zona sehat di wilayah tersebut setelah transmisi ulang ketika Azure telah berkumpul di sekitar kegagalan zona.

Ulas pola desain cloud Azure untuk meningkatkan ketahanan aplikasi Anda terhadap skenario kegagalan.

Beberapa ujung depan

Menggunakan beberapa frontend memungkinkan Anda untuk memuat lalu lintas penyeimbang muatan di lebih dari satu port dan/atau alamat IP. Saat merancang arsitektur Anda, pastikan Anda memperhitungkan bagaimana redundansi zona berinteraksi dengan beberapa frontend. Jika tujuan Anda adalah untuk selalu memiliki setiap frontend tahan terhadap kegagalan, maka semua alamat IP yang ditetapkan sebagai frontend harus zona-redundan. Jika satu set frontend dimaksudkan untuk dikaitkan dengan satu zona, maka setiap alamat IP untuk set tersebut harus dikaitkan dengan zona spesifik tersebut. Load balancer tidak diperlukan di setiap zona. Sebagai gantinya, setiap ujung depan zonal, atau set frontend zonal, dapat dikaitkan dengan komputer virtual di kumpulan backend yang merupakan bagian dari zona ketersediaan tertentu tersebut.

Brankas teknik penyebaran

Ulas pola desain cloud Azure untuk meningkatkan ketahanan aplikasi Anda terhadap skenario kegagalan.

Dukungan bermigrasi ke zona ketersediaan

Dalam kasus di mana wilayah ditambahkan untuk memiliki zona ketersediaan, IP yang ada akan tetap non-zonal seperti IP yang digunakan untuk frontend load balancer. Untuk memastikan arsitektur Anda dapat memanfaatkan zona baru, disarankan agar Anda membuat IP frontend baru. Setelah dibuat, Anda dapat mengganti frontend non-zonal yang ada dengan frontend zona redundan baru. Untuk mempelajari cara memigrasikan VM ke dukungan zona ketersediaan, lihat Memigrasikan Load Balancer ke dukungan zona ketersediaan.

Pemulihan bencana lintas wilayah dan kelangsungan bisnis

Pemulihan bencana (DR) adalah tentang pemulihan dari peristiwa berdampak tinggi, seperti bencana alam atau penyebaran gagal yang mengakibatkan waktu henti dan kehilangan data. Terlepas dari penyebabnya, obat terbaik untuk bencana adalah rencana DR yang terdefinisi dan teruji dengan baik dan desain aplikasi yang secara aktif mendukung DR. Sebelum Anda mulai berpikir tentang membuat rencana pemulihan bencana Anda, lihat Rekomendasi untuk merancang strategi pemulihan bencana.

Ketika datang ke DR, Microsoft menggunakan model tanggung jawab bersama. Dalam model tanggung jawab bersama, Microsoft memastikan bahwa infrastruktur dasar dan layanan platform tersedia. Pada saat yang sama, banyak layanan Azure tidak secara otomatis mereplikasi data atau mundur dari wilayah yang gagal untuk mereplikasi silang ke wilayah lain yang diaktifkan. Untuk layanan tersebut, Anda bertanggung jawab untuk menyiapkan rencana pemulihan bencana yang berfungsi untuk beban kerja Anda. Sebagian besar layanan yang berjalan pada penawaran platform as a service (PaaS) Azure menyediakan fitur dan panduan untuk mendukung DR dan Anda dapat menggunakan fitur khusus layanan untuk mendukung pemulihan cepat untuk membantu mengembangkan rencana DR Anda.

Azure Standard Load Balancer mendukung penyeimbangan beban lintas wilayah yang memungkinkan skenario ketersediaan tinggi geo-redundan seperti:

• Lalu lintas masuk yang berasal dari beberapa wilayah.
• Kegagalan global instan untuk penyebaran regional optimal berikutnya.
• Muat distribusi di seluruh wilayah ke wilayah Azure terdekat dengan latensi ultra rendah.
• Kemampuan untuk meningkatkan/menurunkan skala di belakang satu titik akhir.
• Alamat IP global anycast statis
• Preservasi IP klien
• Buat solusi penyeimbang muatan yang ada tanpa kurva pembelajaran

Konfigurasi IP ujung depan dari penyeimbang muatan lintas wilayah Anda bersifat statis dan ditetapkan di seluruhwilayah Azure.

Catatan

Port ujung belakang dari aturan penyeimbangan muatan Anda pada penyeimbang muatan lintas wilayah harus cocok dengan port ujung depan dari aturan penyeimbang muatan/aturan nat masuk pada penyeimbang muatan standar regional.

Pemulihan bencana dalam geografi multi-wilayah

Redundansi regional

Konfigurasikan redundansi regional dengan menghubungkan load balancer lintas wilayah dengan lancar ke load balancer regional Anda yang ada.

Jika satu wilayah gagal, lalu lintas dirutekan ke load balancer regional sehat terdekat berikutnya.

Pemeriksaan kesehatan load balancer lintas wilayah mengumpulkan informasi tentang ketersediaan setiap penyeimbang beban regional setiap 5 detik. Jika satu penyeimbang beban regional menurunkan ketersediaannya menjadi 0, load balancer lintas wilayah mendeteksi kegagalan. Penyeimbang muatan regional selanjutnya ditarik dari rotasi.

Latensi ultra rendah

Algoritme penyeimbangan muatan kedekatan geografis didasarkan pada lokasi geografis pengguna Anda dan penyebaran regional Anda.

Lalu lintas dimulai dari klien mencapai wilayah terdekat yang berpartisipasi dan melakukan perjalanan melalui backbone jaringan global Microsoft untuk tiba di penyebaran regional terdekat.

Misalnya, Anda memiliki penyeimbang muatan lintas wilayah dengan penyeimbang muatan standar di wilayah Azure:

• US Barat
• Eropa Utara

Jika alur dimulai dari Seattle, lalu lintas memasuki AS Barat. Wilayah ini adalah wilayah terdekat yang berpartisipasi dari Seattle. Lalu lintas dialihkan ke penyeimbang muatan wilayah terdekat, yaitu AS Barat.

Penyeimbang muatan lintas wilayah Azure menggunakan algoritme penyeimbangan muatan kedekatan geografis untuk keputusan perutean.

Mode distribusi muatan yang dikonfigurasi dari penyeimbang muatan regional digunakan untuk membuat keputusan perutean akhir ketika beberapa penyeimbang muatan regional digunakan untuk kedekatan geografis.

Selengkapnya, lihat Mengonfigurasi mode distribusi Azure Load Balancer.

Lalu lintas keluar mengikuti preferensi perutean yang ditetapkan pada penyeimbang beban regional.

Kemampuan untuk meningkatkan/menurunkan skala di belakang satu titik akhir

Saat Anda memperlihatkan titik akhir global penyeimbang muatan lintas wilayah kepada pelanggan, Anda dapat menambahkan atau menghapus penyebaran regional di belakang titik akhir global tanpa gangguan.

Alamat IP global anycast statis

Penyeimbang muatan lintas wilayah dilengkapi dengan IP publik statis, yang memastikan alamat IP tetap sama. Untuk mempelajari lebih lanjut tentang IP statis, baca selengkapnya di sini

Preservasi IP klien

Penyeimbang muatan lintas wilayah adalah penyeimbang muatan jaringan pass-through Layer-4. Pass-through ini mempertahankan IP paket asli. IP asli tersedia untuk kode yang berjalan pada komputer virtual. Preservasi ini memungkinkan Anda menerapkan logika yang khusus untuk alamat IP.

IP Float

IP Mengambang dapat dikonfigurasi pada tingkat IP global dan tingkat IP regional. Untuk informasi selengkapnya, kunjungi Beberapa frontend untuk Azure Load Balancer

Penting untuk dicatat bahwa IP mengambang yang dikonfigurasi pada Load Balancer lintas wilayah Azure beroperasi secara independen dari konfigurasi IP mengambang pada load balancer regional backend. Jika IP mengambang diaktifkan pada load balancer lintas wilayah, antarmuka loopback yang sesuai perlu ditambahkan ke VM backend.

Pemeriksaan Kesehatan

Load Balancer lintas wilayah Azure menggunakan kesehatan load balancer regional backend saat memutuskan ke mana harus mendistribusikan lalu lintas. Pemeriksaan kesehatan oleh load balancer lintas wilayah dilakukan secara otomatis setiap 5 detik, mengingat bahwa pengguna telah menyiapkan pemeriksaan kesehatan pada penyeimbang beban regional mereka.

Membangun solusi lintas wilayah pada Azure Load Balancer yang sudah ada

Kumpulan ujung belakang penyeimbang muatan lintas wilayah berisi satu atau beberapa penyeimbang muatan regional.

Tambahkan penyebaran penyeimbang muatan yang ada ke penyeimbang muatan lintas wilayah untuk penyebaran lintas wilayah dengan ketersediaan tinggi.

Wilayah asal adalah tempat penyeimbang muatan lintas wilayah atau Alamat IP Publik tingkat Global disebarkan. Wilayah ini tidak memengaruhi bagaimana lalu lintas dirutekan. Jika wilayah asal turun, arus lalu lintas tidak terpengaruh.

Wilayah asal

• US Tengah
• Asia Timur
• US Timur 2
• Eropa Utara
• Asia Tenggara
• UK Selatan
• US Gov Virginia
• Eropa Barat
• US Barat

Catatan

Anda hanya dapat menyebarkan load balancer lintas wilayah atau IP Publik di tingkat Global di salah satu wilayah Beranda yang tercantum.

Wilayah yang berpartisipasi adalah tempat IP publik Global dari penyeimbang muatan diiklankan.

Lalu lintas yang dimulai oleh pengguna melakukan perjalanan ke wilayah terdekat yang berpartisipasi melalui jaringan inti Microsoft.

Penyeimbang muatan lintas wilayah merutekan lalu lintas ke penyeimbang muatan regional yang sesuai.

Wilayah yang berpartisipasi

• Australia Timur
• Australia Tenggara
• India Tengah
• US Tengah
• Asia Timur
• AS Timur
• AS Timur 2
• Jepang Timur
• AS Tengah Bagian Utara
• Eropa Utara
• US Tengah Selatan
• Asia Tenggara
• UK Selatan
• US DoD Tengah
• US DoD Timur
• US Gov Arizona
• US Gov Texas
• US Gov Virginia
• AS Tengah Bagian Barat
• Eropa Barat
• US Barat
• US Barat 2

Catatan

Penyeimbang beban regional backend dapat disebarkan di Wilayah Azure yang tersedia untuk umum dan tidak terbatas hanya pada wilayah yang berpartisipasi.

Pembatasan

• Konfigurasi IP ujung depan lintas wilayah bersifat hanya publik. Ujung depan internal saat ini tidak didukung.

• Penyeimbang muatan privat atau internal tidak dapat ditambahkan ke kumpulan ujung belakang penyeimbang muatan lintas wilayah

• Terjemahan NAT64 saat ini tidak didukung. IP frontend dan backend harus berjenis yang sama (v4 atau v6).

• Lalu lintas UDP tidak didukung pada Load Balancer Lintas Wilayah untuk IPv6.

• Lalu lintas UDP pada port 3 tidak didukung pada Load Balancer Lintas Wilayah

• Aturan keluar tidak didukung pada Load Balancer Lintas wilayah. Untuk koneksi keluar, gunakan aturan keluar pada load balancer regional atau gateway NAT.

Harga dan SLA

Load balancer lintas wilayah berbagi SLA load balancer standar.

Langkah berikutnya

• Keandalan di Azure
• Lihat Tutorial: Membuat penyeimbang muatan lintas wilayah menggunakan portal Microsoft Azure untuk membuat penyeimbang muatan lintas wilayah.
• Pelajari selengkapnya tentang penyeimbang muatan lintas wilayah.
• Pelajari selengkapnya tentang Azure Load Balancer.