Metode perutean lalu lintas ke asal

  • Artikel

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 yang berbeda untuk menentukan bagaimana lalu lintas HTTP/HTTPS Anda didistribusikan antara asal yang berbeda. Ketika permintaan pengguna mencapai lokasi tepi Front Door, metode perutean yang dikonfigurasi akan diterapkan guna memastikan permintaan diteruskan ke sumber daya backend terbaik.

Catatan

Grup Asal dan asal dalam artikel ini mengacu pada kumpulan backend dan backend konfigurasi Azure Front Door (klasik).

Empat metode perutean lalu lintas tersebut adalah:

  • Latensi: Perutean berbasis latensi akan memastikan bahwa permintaan dikirim ke asal latensi terendah yang dapat diterima dalam rentang sensitivitas. Dengan kata lain, permintaan dikirim ke set asal terdekat sehubungan dengan latensi jaringan.

  • Prioritas: Prioritas dapat diatur ke asal Anda saat Anda ingin mengonfigurasi asal utama untuk melayani semua lalu lintas. Asal sekunder dapat menjadi cadangan jika asal utama menjadi tidak tersedia.

  • Tertimbang: Nilai tertimbang dapat ditetapkan ke asal Anda saat Anda ingin mendistribusikan lalu lintas di serangkaian asal secara merata atau sesuai dengan koefisien berat. Lalu lintas didistribusikan berdasarkan nilai berat jika latensi asal berada dalam rentang sensitivitas latensi yang dapat diterima di grup asal.

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

Catatan

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

Semua konfigurasi Front Door memiliki pemantauan kesehatan backend dan failover global instan otomatis. Untuk informasi selengkapnya, lihat Pemantauan backend Front Door. Azure Front Door dapat digunakan dengan satu metode perutean. Tetapi tergantung kebutuhan aplikasi, Anda juga dapat menggabungkan beberapa metode perutean untuk membangun topologi perutean yang optimal.

Catatan

Saat Anda menggunakan mesin aturan Front Door, Anda dapat mengonfigurasi aturan untuk mengambil alih konfigurasi rute di Azure Front Door tingkat 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 mengambil alih proses perutean yang dijelaskan dalam artikel ini.

Alur keputusan keseluruhan

Diagram berikut menunjukkan 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 dikembalikan sehat (200 OK) untuk pemeriksaan kesehatan.
    • Contoh: Misalkan ada enam asal A, B, C, D, E, dan F, dan di antaranya C tidak sehat dan E dinonaktifkan. Daftar asal yang tersedia adalah A, B, D, dan F.
  2. Prioritas: Asal prioritas teratas di antara yang tersedia dipilih.
    • Contoh: Misalkan asal A, B, dan D memiliki prioritas 1 dan asal F memiliki prioritas 2. Kemudian, 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. Sinyal ini didasarkan pada pengaturan sensitivitas latensi pada grup asal, dan latensi asal yang lebih dekat.
    • Contoh: Misalkan Front Door telah mengukur latensi dari lingkungan tempat permintaan tiba ke asal A pada 15 ms, sementara latensi untuk B adalah 30 ms dan D berjarak 60 ms. Jika sensitivitas latensi grup asal diatur ke 30 ms, maka kumpulan latensi terendah terdiri dari asal A dan B, karena D berada di luar 30 ms jauhnya dari asal terdekat yaitu A.
  4. Bobot: Terakhir, Azure Front Door membulatkan lalu lintas di antara grup asal yang dipilih akhir dalam rasio bobot yang ditentukan.
    • Contoh: Jika asal A memiliki berat 3 dan asal B memiliki berat 7, lalu lintas didistribusikan 3/10 ke asal A dan 7/10 ke asal B.

Jika afinitas sesi diaktifkan, maka permintaan pertama dalam sesi mengikuti alur yang tercantum sebelumnya. Permintaan berikutnya dikirim ke asal yang dipilih dalam permintaan pertama.

Perutean lalu lintas berbasis latensi terendah

Menyebarkan asal di dua atau lebih lokasi di seluruh dunia dapat meningkatkan daya tanggap aplikasi Anda dengan merutekan lalu lintas ke tujuan yang 'terdekat' dengan pengguna akhir Anda. Latensi adalah metode perutean lalu lintas default untuk konfigurasi Front Door Anda. Metode perutean ini meneruskan permintaan dari pengguna akhir Anda ke asal terdekat di belakang Azure Front Door. Mekanisme perutean ini dikombinasikan dengan arsitektur anycast Azure Front Door memastikan bahwa setiap pengguna akhir Anda mendapatkan performa terbaik berdasarkan lokasi mereka.

Asal 'terdekat' belum tentu paling dekat seperti pengukuran menggunakan jarak geografis. Sebagai gantinya, Front Door menentukan backend terdekat dengan mengukur latensi jaringan. Baca selengkapnya tentang arsitektur perutean Azure Front Door.

Setiap lingkungan Front Door mengukur latensi asal secara terpisah. Ini berarti bahwa pengguna yang berbeda di lokasi yang berbeda dirutekan ke asal dengan performa terbaik untuk lingkungan tersebut.

Catatan

Secara default, properti sensitivitas latensi diatur ke 0 md. Dengan pengaturan ini permintaan selalu diteruskan ke asal tercepat yang tersedia dan bobot di asal tidak berlaku kecuali dua asal memiliki latensi jaringan yang sama.

Perutean lalu lintas berbasis prioritas

Seringkali organisasi ingin memberikan ketersediaan tinggi untuk layanan mereka dengan menerapkan lebih dari satu layanan cadangan jika layanan utama tidak berfungsi. Di seluruh industri, topologi jenis ini juga disebut sebagai penyebaran Aktif/Siaga atau Aktif/Pasif. Metode perutean lalu lintas Prioritas memungkinkan Anda dengan mudah menerapkan pola failover ini.

Azure Front Door default berisi daftar prioritas asal yang sama. Secara default, Azure Front Door mengirimkan lalu lintas hanya ke asal prioritas teratas (nilai terendah dalam prioritas) sebagai set utama asal. Jika asal utama tidak tersedia, Azure Front Door merutekan lalu lintas ke set asal sekunder (nilai terendah kedua untuk prioritas). Jika asal primer dan sekunder tidak tersedia, lalu lintas akan menuju ke asal ketiga, dan seterusnya. Ketersediaan asal didasarkan pada status yang dikonfigurasi dan status kesehatan asal yang sedang berlangsung yang ditentukan oleh pemeriksaan kesehatan.

Mengonfigurasi prioritas untuk asal

Setiap asal di grup asal konfigurasi Azure Front Door Anda memiliki properti bernama Prioritas, yang dapat berjumlah antara 1 dan 5. Dengan Azure Front Door, Anda mengonfigurasi prioritas asal secara eksplisit menggunakan properti ini untuk setiap asal. Properti ini adalah nilai antara 1 dan 5. Semakin rendah nilainya, semakin tinggi prioritasnya. Asal dapat berbagi nilai prioritas yang sama.

Metode perutean lalu lintas tertimbang

Metode perutean lalu lintas Tertimbang memungkinkan Anda mendistribusikan lalu lintas secara merata atau menggunakan pembobotan yang telah ditentukan sebelumnya.

Dalam metode perutean lalu lintas Tertimbang, Anda menetapkan berat untuk setiap asal dalam konfigurasi Azure Front Door dari grup asal Anda. Beratnya adalah bilangan bulat dari 1 hingga 1000. Parameter ini menggunakan berat default 50.

Dengan daftar asal yang tersedia yang memiliki sensitivitas latensi yang dapat diterima, lalu lintas didistribusikan dengan mekanisme round-robin menggunakan rasio berat yang ditentukan. Jika sensitivitas latensi diatur ke 0 milidetik, maka properti ini tidak berlaku kecuali ada dua asal dengan latensi jaringan yang sama.

Metode tertimbang memungkinkan beberapa skenario yang berguna:

  • Peningkatan aplikasi bertahap: Memberikan persentase lalu lintas untuk dirutekan ke asal yang baru, dan secara bertahap meningkatkan lalu lintas dari waktu ke waktu untuk membuatnya setara dengan asal lainnya.
  • Migrasi aplikasi ke Azure: Membuat grup asal menggunakan asal eksternal dan Azure. Sesuaikan berat asal untuk menyesuaikan asal yang baru. Anda dapat menyiapkannya secara bertahap dimulai dengan menonaktifkan asal baru, lalu menetapkan berat terendah, secara perlahan meningkatkannya ke tingkat yang paling banyak menerima lalu lintas. Kemudian akhirnya menonaktifkan asal yang kurang disukai dan menghapusnya dari grup.
  • Cloud-bursting untuk kapasitas tambahan: Dengan cepat memperluas penyebaran lokal ke cloud dengan meletakkannya di belakang Front Door. Saat Anda membutuhkan kapasitas ekstra di cloud, Anda dapat menambah atau mengaktifkan lebih banyak asal dan menentukan bagian lalu lintas mana yang masuk ke setiap asal.

Afinitas sesi

Secara default, tanpa afinitas sesi, Azure Front Door meneruskan permintaan yang berasal dari klien yang sama ke asal yang berbeda. Beberapa aplikasi berstatus atau dalam skenario tertentu saat permintaan selanjutnya dari pengguna yang sama lebih memilih asal yang sama yang memproses permintaan awal. Fitur afinitas sesi berbasis cookie akan berguna saat Anda ingin mempertahankan sesi pengguna pada asal yang sama. Saat Anda menggunakan cookie terkelola dengan SHA256 dari URL asal sebagai pengidentifikasi dalam cookie, Azure Front Door dapat mengarahkan lalu lintas berikutnya dari sesi pengguna ke asal yang sama untuk pemrosesan.

Afinitas sesi dapat diaktifkan tingkat grup asal di Azure Front Door tingkat Standard dan Premium dan tingkat host ujung depan di Azure Front Door (klasik) untuk setiap domain yang dikonfigurasi (atau subdomain). Setelah diaktifkan, Azure Front Door menambahkan cookie ke sesi pengguna. Cookie disebut juga sebagai ASLBSA dan ASLBSACORS. Afinitas sesi berbasis cookie memungkinkan Front Door mengidentifikasi pengguna yang berbeda meskipun berada di balik alamat IP yang sama, yang pada gilirannya memungkinkan distribusi lalu lintas yang lebih merata di antara asal Anda yang berbeda.

Masa pakai cookie sama dengan sesi pengguna, karena Front Door saat ini hanya mendukung cookie sesi.

Catatan

Terlepas dari tempat ia dikonfigurasi, afinitas sesi diingat melalui cookie sesi browser di tingkat domain. Subdomain di bawah domain kartubebas yang sama dapat berbagi afinitas sesi selama browser pengguna yang sama mengirim permintaan untuk sumber daya asal yang sama.

Proksi publik dapat mengganggu afinitas sesi. Ini karena membuat sesi mengharuskan Front Door untuk menambahkan cookie afinitas sesi ke respons, yang tidak dapat dilakukan jika respons dapat di-cache karena akan mengganggu cookie klien lain yang meminta sumber daya yang sama. Untuk melindungi dari ini, afinitas sesi tidak akan ditetapkan jika asal mengirimkan respons yang dapat di-cache saat hal ini dicoba. Jika sesi telah ditetapkan, tidak masalah jika respons dari asal dapat di-cache.

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

  • Respons harus mencakup header Cache-Control dari no-store.
  • Jika respons berisi header Authorization, ia tidak boleh kedaluwarsa.
  • Respons memiliki kode status HTTP 302.

Langkah berikutnya