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.
Berlaku untuk: ✔️ Front Door Standard ✔️ Front Door Premium ✔️ Front Door (klasik)
Penting
Azure Front Door (klasik) akan dihentikan pada 31 Maret 2027. Untuk menghindari gangguan layanan apa pun, penting bahwa Anda memigrasikan profil Azure Front Door (klasik) Anda ke tingkat Azure Front Door Standard atau Premium pada Maret 2027. Untuk informasi selengkapnya, lihat Berakhirnya Layanan Azure Front Door (klasik).
Azure Front Door mendukung empat metode perutean lalu lintas untuk mengelola bagaimana lalu lintas HTTP/HTTPS Anda didistribusikan di antara berbagai sumber asal. Ketika permintaan pengguna mencapai lokasi tepi jaringan Front Door, metode perutean yang dikonfigurasi memastikan permintaan diteruskan ke sumber daya backend yang paling optimal.
Catatan
Dalam artikel ini, Origin mengacu pada backend, dan grup asal mengacu pada kumpulan backend dalam konfigurasi Azure Front Door (klasik).
Empat metode pengaturan lalu lintas adalah:
Latensi: Merutekan permintaan ke asal dengan latensi terendah dalam rentang sensitivitas yang dapat diterima, memastikan permintaan dikirim ke asal terdekat dalam hal latensi jaringan.
Prioritas: Memungkinkan Anda menetapkan prioritas untuk asal Anda, menunjuk asal utama untuk menangani semua lalu lintas dan asal sekunder sebagai cadangan jika primer menjadi tidak tersedia.
Pembobotan: Menetapkan bobot pada setiap asal untuk mendistribusikan lalu lintas secara merata atau menurut koefisien berat yang ditentukan. Lalu lintas didistribusikan berdasarkan nilai berat jika latensi asal berada dalam rentang sensitivitas yang dapat diterima.
Afinitas Sesi: Memastikan bahwa permintaan dari pengguna akhir yang sama dikirim ke asal yang sama dengan cara mengonfigurasi afinitas sesi untuk host atau domain frontend Anda.
Catatan
Di tingkat Azure Front Door Standard dan Premium, Nama Endpoint disebut sebagai Frontend host di Azure Front Door (klasik).
Semua konfigurasi Front Door mencakup pemantauan kesehatan sistem backend dan failover global yang otomatis. Untuk informasi selengkapnya, lihat Pemantauan sistem Front Door. Azure Front Door dapat menggunakan satu metode perutean atau menggabungkan beberapa metode untuk membuat topologi perutean yang optimal berdasarkan kebutuhan aplikasi Anda.
Catatan
Dengan menggunakan mesin aturan Front Door, Anda dapat mengonfigurasi aturan untuk menimpa konfigurasi rute pada tingkatan Standar dan Premium di Azure Front Door atau menimpa kumpulan backend di Azure Front Door (klasik) terhadap permintaan. Kelompok asal atau kolam backend yang ditetapkan oleh mesin aturan menggantikan proses perutean yang dijelaskan dalam artikel ini.
Alur keputusan keseluruhan
Diagram berikut mengilustrasikan alur keputusan keseluruhan:
Langkah-langkah keputusannya adalah:
-
Asal yang tersedia: Pilih semua asal yang telah diaktifkan dan sehat (200 OK) berdasarkan uji kesehatan.
- Contoh: Jika ada enam asal A, B, C, D, E, dan F, dan C tidak sehat dan E dinonaktifkan, asal yang tersedia adalah A, B, D, dan F.
-
Prioritas: Pilih asal prioritas teratas dari yang tersedia.
- Contoh: Jika asal A, B, dan D memiliki prioritas 1 dan asal F memiliki prioritas 2, asal yang dipilih adalah A, B, dan D.
-
Sinyal latensi (berdasarkan pemeriksaan kesehatan): Pilih asal dalam rentang latensi yang diizinkan dari lingkungan Front Door tempat permintaan tiba. Rentang ini didasarkan pada pengaturan sensitivitas latensi grup asal dan latensi asal terdekat.
- Contoh: Jika latensi ke asal A adalah 15 ms, hingga B adalah 30 ms, dan ke D adalah 60 ms, dan sensitivitas latensi diatur ke 30 ms, asal yang dipilih adalah A dan B, karena D melebihi rentang 30 ms.
-
Bobot: Mendistribusikan lalu lintas di antara asal akhir yang dipilih berdasarkan rasio berat yang ditentukan.
- Contoh: Jika asal A memiliki berat 3 dan asal B memiliki berat 7, lalu lintas didistribusikan 3/10 ke A dan 7/10 ke B.
Jika Anda mengaktifkan afinitas sesi, permintaan pertama dalam sesi mengikuti alur yang dijelaskan sebelumnya. Permintaan berikutnya masuk ke asal yang dipilih dalam permintaan pertama.
Perutean lalu lintas berbasis latensi terendah
Menyebarkan asal di beberapa lokasi global dapat meningkatkan respons aplikasi Anda dengan merutekan lalu lintas ke asal yang "paling dekat" dengan pengguna akhir Anda. Metode perutean Latency merupakan default untuk konfigurasi Azure Front Door. Metode ini mengarahkan permintaan pengguna ke asal dengan latensi jaringan terendah, daripada lokasi geografis terdekat, memastikan performa optimal.
Arsitektur anycast Azure Front Door, dikombinasikan dengan metode pengalihan berdasarkan latensi, memastikan bahwa setiap pengguna merasakan performa terbaik berdasarkan lokasi mereka. Setiap lingkungan layanan Front Door secara independen mengukur latensi ke server asal, yang berarti pengguna di lokasi yang berbeda dirutekan ke server asal yang menawarkan performa terbaik untuk lingkungan spesifik mereka.
Catatan
Secara bawaan, properti sensitivitas latensi diatur ke 0 ms. Dengan pengaturan ini, permintaan selalu diteruskan ke asal tercepat yang tersedia. Bobot pada asal hanya berlaku jika dua asal memiliki latensi jaringan yang sama.
Untuk informasi selengkapnya, lihat Arsitektur perutean Azure Front Door.
Perutean lalu lintas berbasis prioritas
Untuk memastikan ketersediaan tinggi, sebarkan layanan cadangan untuk mengambil alih jika layanan utama gagal. Penyiapan ini dikenal sebagai penyebaran Aktif/Siaga atau Aktif/Pasif. Metode pengaturan lalu lintas Priority di Azure Front Door membantu Anda menerapkan pola failover ini.
Secara default, Azure Front Door merutekan lalu lintas ke asal dengan prioritas tertinggi (nilai prioritas terendah). Jika asal utama ini menjadi tidak tersedia, lalu lintas akan dirutekan ke asal sekunder (prioritas terendah berikutnya). Proses ini berlanjut dengan asal tersier jika asal primer dan sekunder tidak tersedia. Sensor kesehatan memantau ketersediaan asal-usul berdasarkan status dan kesehatan yang dikonfigurasikan.
Mengonfigurasi prioritas untuk sumber
Setiap asal dalam grup asal Azure Front Door Anda memiliki properti Priority, yang dapat Anda atur ke nilai antara 1 dan 5. Nilai yang lebih rendah menunjukkan prioritas yang lebih tinggi. Beberapa asal dapat berbagi nilai prioritas yang sama.
Metode pengaturan lalu lintas tertimbang
Catatan
Untuk pelanggan dengan RPS yang sangat rendah (permintaan per detik), karena cara distribusi POP dan mesin AFD, Azure Front Door tidak dapat menjamin bahwa bobot yang Anda konfigurasikan sepenuhnya diikuti dan penyeimbangan beban mungkin tampak tidak merata.
Metode perutean lalu lintas Tertimbang mendistribusikan lalu lintas berdasarkan bobot tertentu yang telah ditentukan sebelumnya.
Dalam metode ini, Anda menetapkan bobot pada setiap asal di grup asal Azure Front Door Anda. Beratnya adalah bilangan bulat antara 1 dan 1.000, dengan nilai default 50.
Lalu lintas didistribusikan di antara asal yang tersedia dengan menggunakan mekanisme round-robin berdasarkan rasio berat yang ditentukan, asalkan asal memenuhi sensitivitas terhadap latensi yang dapat diterima. Jika Anda mengatur sensitivitas latensi ke 0 milidetik, bobot hanya akan berlaku jika dua sumber memiliki latensi jaringan yang sama.
Metode tertimbang mendukung beberapa skenario:
- Pembaruan aplikasi bertahap: Mengarahkan persentase traffic ke asal baru dan secara bertahap meningkatkannya dari waktu ke waktu.
- Migrasi aplikasi ke Azure: Membuat grup asal menggunakan asal Azure dan eksternal. Sesuaikan bobot untuk lebih memilih sumber baru, secara bertahap meningkatkan porsi lalu lintas mereka sampai mereka mengendalikan sebagian besar lalu lintas, lalu nonaktifkan dan hapus sumber yang kurang diutamakan.
- Cloud-bursting untuk kapasitas tambahan: Perluas penyebaran lokal ke cloud dengan menambahkan atau mengaktifkan lebih banyak asal dan mengatur distribusi lalu lintas.
Keterikatan Sesi
Secara default, Azure Front Door meneruskan permintaan dari klien yang sama ke asal yang berbeda. Namun, afinitas sesi berguna untuk aplikasi yang memerlukan penyimpanan status atau skenario di mana permintaan berikutnya dari pengguna yang sama perlu diproses oleh server asal yang sama. Fitur ini memastikan bahwa sumber yang sama menangani sesi pengguna, yang bermanfaat untuk skenario seperti autentikasi klien.
Azure Front Door menggunakan afinitas sesi berbasis cookie, di mana cookie yang dikelola diidentifikasi oleh SHA256 dari URL asal. Metode ini mengarahkan lalu lintas berikutnya dari sesi pengguna ke asal yang sama.
Anda dapat mengaktifkan afinitas sesi di tingkat grup asal di tingkat Azure Front Door Standar dan Premium, dan pada tingkat host frontend di Azure Front Door (klasik) untuk setiap domain atau subdomain yang dikonfigurasi. Saat Anda mengaktifkan fitur ini, Azure Front Door menambahkan cookie bernama ASLBSA dan ASLBSACORS ke sesi pengguna. Cookie ini membantu mengidentifikasi pengguna yang berbeda bahkan jika mereka berbagi alamat IP yang sama, yang memungkinkan distribusi lalu lintas yang lebih merata di antara asal.
Masa pakai cookie cocok dengan sesi pengguna, karena Front Door saat ini hanya mendukung cookie sesi.
Catatan
Cookie sesi di peramban mempertahankan afinitas sesi di tingkat domain. Subdomain di bawah domain wildcard yang sama dapat berbagi afinitas sesi selama browser pengguna mengirim permintaan untuk sumber daya asal yang sama.
Proksi publik mungkin mengganggu afinitas sesi karena pembentukan sesi memerlukan Front Door untuk menambahkan cookie afinitas sesi ke dalam respons. Tindakan ini tidak dapat dilakukan jika respons dapat di-cache, karena akan mengganggu cookie untuk klien lain yang meminta sumber daya yang sama. Untuk mencegah masalah ini, kesetiaan sesi tidak dibuat jika asal mengirim respons yang boleh di-cache. Jika sesi sudah ditetapkan, kemampuan caching respons tidak menjadi masalah.
Afinitas sesi ditetapkan dalam keadaan berikut di luar skenario standar yang tidak dapat di-cache:
- Respons mencakup
Cache-Controlheader dengan no-store. - Respons berisi header yang valid
Authorization. - Respons memiliki kode status HTTP 302.
Langkah berikutnya
- Pelajari cara membuat Azure Front Door.
- Pelajari cara kerja Azure Front Door.