Bagikan melalui


Metode perutean lalu lintas ke asal

Penting

Azure Front Door (klasik) akan dihentikan pada 31 Maret 2027. Untuk menghindari gangguan layanan apa pun, penting untuk memigrasikan profil Azure Front Door (klasik) Anda ke Azure Front Door Standard atau tingkat Premium paling lambat Maret 2027. Untuk informasi selengkapnya, lihat Penghentian 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 asal. Ketika permintaan pengguna mencapai lokasi tepi Front Door, metode perutean yang dikonfigurasi memastikan permintaan diteruskan ke sumber daya backend terbaik.

Catatan

Dalam artikel ini, Origin mengacu pada backend, dan grup asal mengacu pada kumpulan backend dalam konfigurasi Azure Front Door (klasik).

Empat metode perutean lalu lintas tersebut 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.

  • Tertimbang: Menetapkan bobot ke setiap asal untuk mendistribusikan lalu lintas secara merata atau sesuai dengan koefisien berat yang ditentukan. Lalu lintas didistribusikan berdasarkan nilai berat jika latensi asal berada dalam rentang sensitivitas yang dapat diterima.

  • Afinitas Sesi: Memastikan permintaan dari pengguna akhir yang sama dikirim ke asal yang sama dengan mengonfigurasi afinitas sesi untuk host atau domain frontend Anda.

Catatan

Di tingkat Azure Front Door Standard dan Premium, Nama titik akhir disebut sebagai host Frontend di Azure Front Door (klasik).

Semua konfigurasi Front Door mencakup pemantauan kesehatan backend dan failover global otomatis. Untuk informasi selengkapnya, lihat Pemantauan backend 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 mengambil alih konfigurasi rute di tingkat Azure Front Door Standard dan Premium atau mengambil alih kumpulan backend di Azure Front Door (klasik) untuk permintaan. Grup asal atau kumpulan backend yang ditetapkan oleh mesin aturan akan mengambil alih proses perutean yang dijelaskan dalam artikel ini.

Alur keputusan keseluruhan

Diagram berikut mengilustrasikan alur keputusan keseluruhan:

Diagram yang menjelaskan bagaimana asal dipilih berdasarkan pengaturan prioritas, latensi, dan berat di Azure Front Door.

Langkah-langkah keputusannya adalah:

  1. Asal yang tersedia: Pilih semua asal yang diaktifkan dan sehat (200 OK) berdasarkan pemeriksaan 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.
  2. 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.
  3. Sinyal latensi (berdasarkan pemeriksaan kesehatan): Pilih asal dalam rentang latensi yang diizinkan dari lingkungan Front Door tempat permintaan tiba. 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.
  4. 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 afinitas sesi diaktifkan, permintaan pertama dalam sesi mengikuti alur yang dijelaskan sebelumnya. Permintaan berikutnya dikirim 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 Latensi adalah 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 perutean Latensi, memastikan bahwa setiap pengguna mengalami performa terbaik berdasarkan lokasi mereka. Setiap lingkungan Front Door secara independen mengukur latensi ke asal, yang berarti pengguna di lokasi yang berbeda dirutekan ke asal yang menawarkan performa terbaik untuk lingkungan spesifik mereka.

Catatan

Secara default, properti sensitivitas latensi diatur ke 0 md. 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, organisasi sering menyebarkan layanan cadangan untuk mengambil alih jika layanan utama gagal. Penyiapan ini dikenal sebagai penyebaran Aktif/Siaga atau Aktif/Pasif. Metode perutean lalu lintas Prioritas di Azure Front Door memungkinkan Anda menerapkan pola failover ini secara efektif.

Secara default, Azure Front Door merutekan lalu lintas ke asal dengan prioritas tertinggi (nilai prioritas terendah). Jika asal utama ini menjadi tidak tersedia, asal utama ini merutekan lalu lintas ke asal sekunder (nilai prioritas terendah berikutnya). Proses ini berlanjut dengan asal tersier jika asal primer dan sekunder tidak tersedia. Pemeriksaan kesehatan memantau ketersediaan asal berdasarkan status dan kesehatan yang dikonfigurasi.

Mengonfigurasi prioritas untuk asal

Setiap asal dalam grup asal Azure Front Door Anda memiliki properti Prioritas , yang dapat diatur ke nilai antara 1 dan 5. Nilai yang lebih rendah menunjukkan prioritas yang lebih tinggi. Beberapa asal dapat berbagi nilai prioritas yang sama.

Metode perutean lalu lintas tertimbang

Metode perutean lalu lintas Tertimbang memungkinkan Anda mendistribusikan lalu lintas berdasarkan bobot yang telah ditentukan sebelumnya.

Dalam metode ini, Anda menetapkan bobot ke setiap asal di grup asal Azure Front Door Anda. Bobotnya adalah bilangan bulat antara 1 dan 1000, dengan nilai default 50.

Lalu lintas didistribusikan di antara asal yang tersedia menggunakan mekanisme round-robin berdasarkan rasio berat yang ditentukan, asalkan memenuhi sensitivitas latensi yang dapat diterima. Jika sensitivitas latensi diatur ke 0 milidetik, bobot hanya berlaku jika dua asal memiliki latensi jaringan yang sama.

Metode tertimbang mendukung beberapa skenario:

  • Peningkatan aplikasi bertahap: Merutekan persentase lalu lintas ke asal baru dan secara bertahap meningkatkannya dari waktu ke waktu.
  • Migrasi aplikasi ke Azure: Membuat grup asal menggunakan asal eksternal dan Azure. Sesuaikan bobot untuk lebih memilih asal baru, secara bertahap meningkatkan berbagi lalu lintas mereka sampai mereka menangani sebagian besar lalu lintas, lalu nonaktifkan dan hapus asal yang kurang disukai.
  • Cloud-bursting untuk kapasitas tambahan: Perluas penyebaran lokal ke cloud dengan menambahkan atau mengaktifkan lebih banyak asal dan menentukan distribusi lalu lintas.

Afinitas Sesi

Secara default, Azure Front Door meneruskan permintaan dari klien yang sama ke asal yang berbeda. Namun, afinitas sesi berguna untuk aplikasi atau skenario stateful di mana permintaan berikutnya dari pengguna yang sama perlu diproses oleh asal yang sama. Fitur ini memastikan bahwa asal yang sama menangani sesi pengguna, yang bermanfaat untuk skenario seperti autentikasi klien.

Azure Front Door menggunakan afinitas sesi berbasis cookie, di mana cookie terkelola dengan SHA256 URL asal sebagai pengidentifikasi digunakan. Ini mengarahkan lalu lintas berikutnya dari sesi pengguna ke asal yang sama.

Afinitas sesi dapat diaktifkan di tingkat grup asal di tingkat Azure Front Door Standard dan Premium, dan pada tingkat host frontend di Azure Front Door (klasik) untuk setiap domain atau subdomain yang dikonfigurasi. Setelah diaktifkan, 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, 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

Afinitas sesi dipertahankan melalui cookie sesi browser 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 dapat mengganggu afinitas sesi karena membuat sesi memerlukan Front Door untuk menambahkan cookie afinitas sesi ke respons. Ini tidak dapat dilakukan jika respons dapat di-cache, karena akan mengganggu cookie untuk klien lain yang meminta sumber daya yang sama. Untuk mencegah hal ini, afinitas sesi tidak akan ditetapkan jika asal mengirim respons yang dapat di-cache. Jika sesi sudah ditetapkan, cacheability respons tidak masalah.

Afinitas sesi akan dibuat dalam keadaan berikut di luar skenario standar yang tidak dapat di-cache:

  • Respons mencakup Cache-Control header tanpa penyimpanan.
  • Respons berisi header yang valid Authorization .
  • Respons memiliki kode status HTTP 302.

Langkah berikutnya