Asal dan grup asal di Azure Front Door

  • 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).

Catatan

Asal dan grup asal dalam artikel ini mengacu pada bagian belakang dan kumpulannya di konfigurasi Azure Front Door (klasik).

Artikel ini menjelaskan konsep tentang cara memetakan penyebaran aplikasi web Anda dengan Azure Front Door. Anda mempelajari tentang apa itu grup asal dan asal dalam konfigurasi Azure Front Door.

Asal

Asal mengacu pada penyebaran aplikasi yang diambil Azure Front Door dari saat penembolokan tidak diaktifkan atau ketika cache terlewatkan. Azure Front Door mendukung asal yang dihosting di Azure dan aplikasi yang dihosting di pusat data lokal Anda atau dengan penyedia cloud lain. Asal tidak boleh disamakan dengan tingkat basis data atau tingkat penyimpanan Anda. Asal harus dilihat sebagai titik akhir untuk backend aplikasi Anda. Saat menambahkan asal ke grup asal dalam konfigurasi Front Door, Anda juga harus mengonfigurasi pengaturan berikut:

  • Jenis asal: Jenis sumber daya yang ingin Anda tambahkan. Front Door mendukung penemuan otomatis backend aplikasi Anda dari Azure App Service, layanan cloud, atau penyimpanan. Jika Anda menginginkan sumber daya yang berbeda di Azure atau bahkan backend non-Azure, pilih Host kustom.

    Penting

    Selama konfigurasi, API tidak memvalidasi apakah asal tidak dapat diakses dari lingkungan Front Door. Pastikan Front Door dapat mencapai asal Anda.

  • Nama host langganan dan asal: Jika Anda tidak memilih Host kustom untuk jenis host backend Anda, pilih backend dengan memilih langganan yang tepat dan nama host backend yang sesuai.

  • Private Link: Azure Front Door Premium tier mendukung pengiriman lalu lintas ke asal dengan menggunakan Private Link. Untuk informasi selengkapnya, lihat Mengamankan Asal Anda dengan Private Link.

  • Validasi nama subjek sertifikat: selama Azure Front Door ke koneksi TLS asal, Azure Front Door memvalidasi apakah nama host permintaan cocok dengan nama host dalam sertifikat yang disediakan oleh asal. Dari sudut pandang keamanan, Microsoft tidak menyarankan menonaktifkan pemeriksaan nama subjek sertifikat. Untuk informasi selengkapnya, lihat Enkripsi TLS end-to-end, terutama jika Anda ingin menonaktifkan fitur ini.

  • Header host asal: Nilai header host yang dikirim ke backend untuk setiap permintaan. Untuk informasi selengkapnya, lihat Header host asal.

  • Prioritas. Tetapkan prioritas ke berbagai backend Anda saat Anda ingin menggunakan backend layanan utama untuk semua lalu lintas. Selain itu, sediakan cadangan jika backend utama atau cadangan tidak tersedia. Untuk informasi selengkapnya, lihat Prioritas.

  • Berat. Tetapkan berat ke berbagai backend Anda untuk mendistribusikan lalu lintas di set backend, baik secara merata atau sesuai dengan koefisien berat. Untuk informasi selengkapnya, lihat Berat.

Header host asal

Permintaan yang diteruskan oleh Azure Front Door ke asal menyertakan bidang header host yang digunakan asal untuk mengambil sumber daya yang ditargetkan. Nilai untuk bidang ini biasanya datang dari URI asal yang memiliki header dan port host.

Misalnya, permintaan yang dibuat untuk www.contoso.com memiliki header www.contoso.comhost . Jika Anda menggunakan portal Azure untuk mengonfigurasi asal Anda, nilai default untuk bidang ini adalah nama host asal. Jika asal Anda adalah contoso-westus.azurewebsites.net, dalam portal Azure, nilai yang diisi otomatis untuk header host asal adalah contoso-westus.azurewebsites.net. Namun, jika Anda menggunakan templat Azure Resource Manager atau metode lain tanpa mengatur bidang ini secara eksplisit, Front Door mengirimkan nama host masuk sebagai nilai untuk header host. Jika permintaan dibuat untuk www.contoso.com, dan asal contoso-westus.azurewebsites.net Anda memiliki bidang header kosong, Front Door mengatur header host sebagai www.contoso.com.

Sebagian besar backend aplikasi (Azure Web Apps, penyimpanan Blob, dan Cloud Services) mengharuskan header host untuk mencocokkan domain backend. Namun, host frontend yang merutekan ke asal Anda menggunakan nama host yang berbeda seperti www.contoso.net.

Jika Origin Anda memerlukan header host agar cocok dengan nama host asal, pastikan header host asal menyertakan nama host asal.

Catatan

Jika Anda menggunakan App Service sebagai asal, pastikan App Service juga memiliki nama domain kustom yang dikonfigurasi. Untuk informasi selengkapnya, lihat memetakan nama DNS kustom yang sudah ada ke Azure App Service.

Konfigurasikan header host asal untuk asal

Untuk mengonfigurasi bidang header host asal untuk asal di bagian grup asal:

  1. Buka sumber daya Front Door Anda dan pilih grup asal dengan asal untuk dikonfigurasi.

  2. Tambahkan asal jika Anda belum melakukannya, atau edit yang sudah ada.

  3. Atur bidang header host asal ke nilai kustom atau biarkan kosong. Nama host untuk permintaan masuk digunakan sebagai nilai header host.

Grup asal

Grup asal di Azure Front Door mengacu pada kumpulan asal yang menerima lalu lintas serupa untuk aplikasi mereka. Anda dapat menentukan grup asal sebagai pengelompokan logis dari instans aplikasi Anda di seluruh dunia yang menerima lalu lintas yang sama dan merespons dengan perilaku yang diharapkan. Asal ini disebarkan di berbagai wilayah atau dalam wilayah yang sama. Semua asal dapat disebarkan dalam konfigurasi Aktif/Aktif atau Aktif/Pasif.

Grup asal menentukan bagaimana asal dievaluasi oleh pemeriksaan kesehatan. Ini juga mendefinisikan metode penyeimbangan beban di antara mereka.

Pemeriksaan kesehatan

Azure Front Door mengirimkan permintaan pemeriksaan HTTP/HTTPS secara berkala ke setiap asal yang Anda konfigurasikan. Permintaan pemeriksaan menentukan kedekatan dan kesehatan setiap asal untuk memuat keseimbangan permintaan pengguna akhir Anda. Pengaturan pemeriksaan kesehatan untuk grup asal menentukan cara kami melakukan polling status kesehatan backend aplikasi. Pengaturan berikut tersedia untuk konfigurasi load-balancing:

  • Jalur: URL yang digunakan untuk permintaan pemeriksaan untuk semua asal dalam grup asal ini. Misalnya, jika salah satu asal Anda adalah contoso-westus.azurewebsites.net dan jalur diatur ke /probe/test.aspx, Maka Front Door mengirimkan permintaan pemeriksaan kesehatan ke http://contoso-westus.azurewebsites.net/probe/test.aspx jika protokol diatur ke HTTP.

  • Protokol: Menentukan apakah akan mengirim permintaan pemeriksaan kesehatan dari Front Door ke asal Anda dengan protokol HTTP atau HTTPS.

  • Metode: Metode HTTP yang akan digunakan untuk mengirim probe kesehatan. Opsi termasuk GET atau HEAD (default).

    Catatan

    Untuk beban dan biaya yang lebih rendah pada backend Anda, Azure Front Door merekomendasikan penggunaan permintaan HEAD untuk probe kesehatan.

  • Interval (detik): Menentukan frekuensi probe kesehatan ke backend Anda, atau interval di mana masing-masing lingkungan Front Door mengirimkan pemeriksaan.

    Catatan

    Untuk kegagalan yang lebih cepat, atur interval ke nilai yang lebih rendah. Semakin rendah nilainya, semakin tinggi volume pemeriksaan kesehatan yang diterima backend Anda. Misalnya, jika interval diatur ke 30 detik dengan katakanlah, 100 POP Front Door secara global, setiap backend akan menerima sekitar 200 permintaan pemeriksaan per menit.

Untuk informasi selengkapnya, lihat Pemeriksaan kesehatan.

Pengaturan load balancing

Pengaturan penyeimbangan beban untuk grup asal menentukan cara kami mengevaluasi pemeriksaan kesehatan. Pengaturan ini menentukan apakah asal sehat atau tidak sehat. Mereka juga memeriksa cara memuat lalu lintas keseimbangan antara asal yang berbeda dalam kelompok asal. Pengaturan berikut tersedia untuk konfigurasi load-balancing:

  • Ukuran sampel: Identifikasi berapa banyak sampel pemeriksaan kesehatan yang perlu dipertimbangkan untuk evaluasi kesehatan asal.

  • Ukuran sampel berhasil: Menentukan ukuran sampel yang sebelumnya disebutkan, jumlah sampel berhasil yang diperlukan untuk menyebut asal sehat. Misalnya, asumsikan interval pemeriksaan kesehatan Front Door adalah 30 detik, ukuran sampel adalah 5, dan ukuran sampel yang berhasil adalah 3. Setiap kali kami mengevaluasi pemeriksaan kesehatan untuk asal Anda, kami melihat lima sampel terakhir selama 150 detik (5 x 30). Setidaknya tiga pemeriksaan berhasil yang diperlukan untuk menyatakan bahwa asal sehat.

  • Sensitivitas latensi (latensi ekstra): Menentukan apakah Anda ingin Front Door mengirim permintaan ke asal dalam rentang sensitivitas pengukuran latensi atau meneruskan permintaan ke backend terdekat.

Untuk informasi selengkapnya, lihat Metode perutean berbasis latensi paling sedikit.

Langkah berikutnya