Merencanakan dan menerapkan Azure Application Gateway

  • 10 menit

Azure Application Gateway adalah penyeimbang beban lalu lintas web (OSI lapisan 7) yang memungkinkan Anda mengelola lalu lintas ke aplikasi web Anda. Penyeimbang muatan tradisional beroperasi di lapisan transportasi (OSI layer 4 - TCP dan UDP) dan lalu lintas rute berdasarkan alamat IP sumber dan port, ke alamat IP tujuan dan port.

Azure Application Gateway dapat membuat keputusan perutean berdasarkan atribut tambahan dari permintaan HTTP, misalnya jalur URI atau header host. Misalnya, Anda dapat merutekan lalu lintas berdasarkan URL masuk. Jadi, jika /images ada di URL masuk, Anda dapat merutekan lalu lintas ke set server tertentu (dikenal sebagai kumpulan) yang dikonfigurasi untuk gambar. Jika /video ada di URL, lalu lintas akan dirutekan ke kumpulan lain yang dioptimalkan untuk video.

Diagram memperlihatkan contoh Azure Application Gateway.

Jenis perutean ini dikenal sebagai penyeimbangan beban lapisan aplikasi (OSI layer 7). Azure Application Gateway dapat melakukan perutean berbasis URL dan banyak lagi.

Komponen Azure Application Gateway

Gateway aplikasi berfungsi sebagai titik kontak tunggal untuk klien. Gateway aplikasi mendistribusikan lalu lintas aplikasi yang masuk ke beberapa kumpulan ujung belakang, yang mencakup Azure VMs, set skala mesin virtual, Azure App Service, dan server lokal/eksternal.

Diagram memperlihatkan komponen gateway aplikasi Azure.

Infrastruktur

Infrastruktur Application Gateway mencakup jaringan virtual, subnet, grup keamanan jaringan, dan rute yang ditentukan pengguna.

Alamat IP ujung depan

Anda dapat mengonfigurasi application gateway untuk memiliki alamat IP publik, alamat IP privat, atau keduanya. Alamat IP publik diperlukan ketika Anda meng-hosting ujung belakang yang harus diakses klien melalui Internet melalui akses internet IP virtual (VIP).

Alamat IP publik tidak diperlukan untuk titik akhir internal yang tidak terekspos ke internet. Konfigurasi frontend privat berguna untuk aplikasi lini bisnis internal yang tidak terekspos ke internet. Ini juga berguna untuk layanan dan tingkatan dalam aplikasi multitier dalam batas keamanan yang tidak terekspos ke internet tetapi memerlukan distribusi beban round-robin, kelekatan sesi, atau penghentian TLS.

Hanya satu alamat IP publik dan satu alamat IP privat yang didukung. Anda memilih IP frontend saat membuat gateway aplikasi.

Catatan

Front end Application Gateway mendukung alamat IP tumpukan ganda (pratinjau publik). Anda dapat membuat hingga empat IP frontend. Dua adalah alamat IPv4 (publik dan privat) dan dua adalah alamat IPv6 (publik dan privat).

  • Untuk alamat IP publik, Anda bisa membuat alamat IP publik baru atau menggunakan IP publik yang ada di lokasi yang sama dengan gateway aplikasi. Untuk informasi selengkapnya, lihat Alamat IP publik statis versus dinamis.
  • Untuk alamat IP privat, Anda dapat menentukan alamat IP privat dari subnet tempat gateway aplikasi dibuat. Untuk penyebaran SKU Application Gateway v2, alamat IP statis harus ditentukan saat Anda menambahkan alamat IP privat ke gateway. Untuk penyebaran SKU Application Gateway v1, jika Anda tidak menentukan alamat IP, alamat IP yang tersedia secara otomatis dipilih dari subnet. Jenis alamat IP yang Anda pilih (statis atau dinamis) bersifat permanen.

Alamat IP frontend dikaitkan dengan pendengar, yang memeriksa permintaan masuk pada IP frontend.

Anda dapat membuat listener privat dan publik dengan nomor port yang sama. Namun, waspadai grup keamanan jaringan (NSG) apa pun yang terkait dengan subnet Application Gateway. Bergantung pada konfigurasi NSG, Anda mungkin memerlukan aturan izinkan masuk dengan alamat IP Tujuan sebagai IP frontend publik dan privat gateway aplikasi Anda. Saat Anda menggunakan port yang sama, gateway aplikasi Anda mengubah Tujuan alur masuk ke IP frontend gateway Anda.

Aturan masuk:

  • Sumber: Sesuai dengan persyaratan Anda
  • Tujuan: IP frontend publik dan privat gateway aplikasi Anda.
  • Port tujuan: Menurut listener yang dikonfigurasi
  • Protocol: TCP

Aturan keluar: Tidak ada persyaratan khusus

Pendengar

Listener adalah entitas logis yang memeriksa permintaan koneksi masuk dengan menggunakan port, protokol, host, dan alamat IP. Saat mengonfigurasi listener, Anda harus memasukkan nilai untuk ini yang cocok dengan nilai yang sesuai dalam permintaan masuk di gateway.

Saat Anda membuat app gateway dengan menggunakan portal Microsoft Azure, Anda juga membuat listener default dengan memilih protokol dan port untuk listener. Anda bisa memilih apakah akan mengaktifkan dukungan HTTP2 pada listener. Setelah Anda membuat app gateway, Anda bisa mengedit pengaturan listener default tersebut (appGatewayHttpListener) atau membuat listener baru.

Jenis pendengar

Pendengar adalah entitas logis yang memeriksa permintaan koneksi masuk. Pendengar menerima permintaan jika protokol, port, nama host, dan alamat IP yang terkait dengan permintaan cocok dengan elemen yang sama dengan konfigurasi pendengar.

Sebelum menggunakan gateway aplikasi, Anda harus menambahkan setidaknya satu pendengar. Mungkin ada beberapa pendengar yang dilampirkan ke gateway aplikasi, dan mereka dapat digunakan untuk protokol yang sama.

Setelah pendengar mendeteksi permintaan masuk dari klien, gateway aplikasi mengalihkan permintaan ini kepada anggota di kumpulan ujung belakang yang dikonfigurasi dalam aturan.

Pendengar mendukung port dan protokol berikut.

Port

Port adalah tempat pendengar mendengarkan permintaan klien. Anda dapat mengonfigurasi port untuk SKU v1 dan v2 sesuai di bawah ini.

SKU Rentang port yang didukung Pengecualian
V2 1 hingga 64999 22
V1 1 hingga 65502 3389

Protokol

Application Gateway mendukung empat protokol: HTTP, HTTPS, HTTP/2, dan WebSocket:

Catatan

Dukungan protokol HTTP/2 tersedia untuk klien yang terhubung ke pendengar gateway aplikasi saja. Komunikasi ke kumpulan server ujung belakang selalu melalui HTTP / 1.1. Secara default, dukungan HTTP/2 dinonaktifkan. Anda dapat memilih untuk mengaktifkannya.

  • Tentukan antara protokol HTTP dan HTTPS dalam konfigurasi pendengar.
  • Dukungan untuk WebSocket dan protokol HTTP/2 disediakan, dan dukungan WebSocket diaktifkan secara default. Tidak ada pengaturan yang dapat dikonfigurasi pengguna untuk mengaktifkan atau menonaktifkan dukungan WebSocket secara selektif. Gunakan WebSocket dengan pendengar HTTP dan HTTPS.

Gunakan pendengar HTTPS untuk penghentian TLS. Pendengar HTTPS membongkar enkripsi dan dekripsi pekerjaan ke gateway aplikasi Anda, sehingga server web Anda tidak terbebani oleh overhead.

Meminta aturan perutean

Saat Anda membuat gateway aplikasi menggunakan portal Microsoft Azure, Anda membuat aturan default(aturan1). Aturan ini mengikat pendengar default (appGatewayHttpListener) dengan kumpulan backend default (appGatewayBackendPool) dan pengaturan HTTP backend default (appGatewayBackendHttp Pengaturan). Setelah membuat gateway, Anda dapat mengedit pengaturan aturan default atau membuat aturan baru.

Jenis aturan

Saat Anda membuat aturan, Anda memilih antara dasar dengan berbasis jalur.

  • Pilih dasar jika Anda ingin meneruskan semua permintaan pada listener terkait (misalnya, blog.contoso.com/*) ke satu kumpulan backend.
  • Pilih berbasis jalur jika Anda ingin merutekan permintaan dari jalur URL tertentu ke kumpulan backend tertentu. Pola jalur hanya diterapkan ke jalur URL, bukan ke parameter kuerinya.

Pendengar terkait

Kaitkan pendengar ke aturan sehingga aturan perutean permintaan yang terkait dengan pendengar dievaluasi untuk menentukan kumpulan backend untuk merutekan permintaan.

Kumpulan backend terkait

Kaitkan dengan aturan kumpulan backend yang berisi target backend yang melayani permintaan yang diterima pendengar.

  • Untuk aturan dasar, hanya satu kumpulan backend yang diizinkan. Semua permintaan pada listener terkait diteruskan ke kumpulan backend tersebut.
  • Untuk aturan berbasis jalur, tambahkan beberapa kumpulan backend yang sesuai dengan setiap jalur URL. Permintaan yang cocok dengan jalur URL yang dimasukkan diteruskan ke kumpulan backend yang sesuai. Selain itu, tambahkan kumpulan backend default. Permintaan yang tidak cocok dengan jalur URL apa pun dalam aturan akan diteruskan ke kumpulan tersebut.

Pengaturan HTTP backend terkait

Tambahkan pengaturan HTTP backend untuk setiap aturan. Permintaan dirutekan dari gateway aplikasi ke target backend dengan menggunakan nomor port, protokol, dan informasi lain yang ditentukan dalam pengaturan ini.

Untuk aturan dasar, hanya satu pengaturan HTTP backend yang diizinkan. Semua permintaan pada listener terkait diteruskan ke target backend yang sesuai dengan menggunakan pengaturan HTTP ini.

Untuk aturan berbasis jalur, tambahkan beberapa pengaturan HTTP backend yang sesuai dengan setiap jalur URL. Permintaan yang cocok dengan jalur URL dalam pengaturan ini diteruskan ke target backend yang sesuai dengan menggunakan pengaturan HTTP yang sesuai dengan setiap jalur URL. Selain itu, tambahkan pengaturan HTTP default. Permintaan yang tidak cocok dengan jalur URL apa pun dalam aturan ini diteruskan ke kumpulan backend default dengan menggunakan pengaturan HTTP default.

Pengaturan pengalihan

Jika pengalihan dikonfigurasi untuk aturan dasar, semua permintaan pendengar terkait dialihkan ke target. Ini adalah pengalihan global. Jika pengalihan dikonfigurasi untuk aturan berbasis jalur, hanya permintaan di area situs tertentu yang dialihkan. Contohnya adalah area kelir belanja yang ditandai dengan /cart/*. Ini adalah pengalihan berbasis jalur.

Listener

Pilih pendengar sebagai target pengalihan untuk mengalihkan lalu lintas dari satu pendengar ke pendengar lainnya di dalam gateway. Pengaturan ini diperlukan ketika Anda ingin mengaktifkan pengalihan HTTP-ke-HTTPS. Ini mengalihkan lalu lintas dari pendengar sumber yang memeriksa permintaan HTTP masuk ke pendengar tujuan yang memeriksa permintaan HTTPS masuk. Anda juga dapat memilih untuk menyertakan untai (karakter) kueri dan jalur dari permintaan asli dalam permintaan yang diteruskan ke target pengalihan.

Cuplikan layar memperlihatkan contoh halaman pengaturan konfigurasi pengalihan.

Situs eksternal

Pilih situs eksternal jika Anda ingin mengalihkan lalu lintas pada pendengar yang terkait dengan aturan ini ke situs eksternal. Anda dapat memilih untuk menyertakan untai (karakter) kueri dari permintaan asli dalam permintaan yang diteruskan ke target pengalihan. Anda tidak dapat meneruskan jalur ke situs eksternal yang ada di permintaan asli.

Regenerasi header HTTP dan URL

Dengan menggunakan aturan regenerasi, Anda dapat menambahkan, menghapus, atau memperbarui permintaan HTTP(S) dan header respons serta jalur URL dan parameter string kueri saat paket permintaan dan respons berpindah antara klien dengan kumpulan ujung belakang melalui gateway aplikasi.

Parameter header dan URL dapat diatur ke nilai statik atau ke header dan variabel server lainnya. Hal tersebut membantu kasus penggunaan penting, seperti mengekstrak alamat IP klien, menghapus informasi sensitif tentang back-end, meningkatkan keamanan yang lebih banyak, dan sebagainya.

Pengaturan HTTP

Gateway aplikasi merutekan lalu lintas ke server backend dengan menggunakan konfigurasi yang Anda tentukan di sini. Setelah Anda membuat pengaturan HTTP, Anda harus mengaitkannya dengan satu atau beberapa aturan permintaan perutean.

Azure Application Gateway menggunakan cookie yang dikelola gateway untuk mempertahankan sesi pengguna. Ketika pengguna mengirim permintaan pertama ke Application Gateway, ia menetapkan cookie afinitas sebagai respons dengan nilai hash yang berisi detail sesi, sehingga permintaan berikutnya yang membawa cookie afinitas akan dirutekan ke server ujung belakang yang sama untuk mempertahankan kelekatan.

Fitur ini berguna ketika Anda ingin mempertahankan sesi pengguna di server yang sama dan ketika status sesi disimpan secara lokal di server untuk sesi pengguna. Jika aplikasi tidak dapat menangani afinitas berbasis cookie, Anda tidak dapat menggunakan fitur ini. Untuk menggunakannya, pastikan bahwa klien mendukung cookie.

Catatan

Beberapa pemindaian kerentanan dapat menandai cookie afinitas Application Gateway karena bendera Aman atau HttpOnly tidak diatur. Pemindaian ini tidak memperhitungkan bahwa data dalam cookie dihasilkan menggunakan hash satu arah. Cookie tidak berisi informasi pengguna apa pun dan digunakan murni untuk perutean.

Pengurasan koneksi

pengurasan Koneksi ion membantu Anda menghapus anggota kumpulan backend dengan anggun selama pembaruan layanan yang direncanakan. Ini berlaku untuk instans backend yang

  • secara eksplisit dihapus dari kumpulan backend,
  • dihapus selama operasi penyempurnaan skala, atau
  • dilaporkan tidak sehat oleh pemeriksaan kesehatan.

Anda dapat menerapkan pengaturan ini ke semua anggota kumpulan backend dengan mengaktifkan pengurasan Koneksi ion di Pengaturan Backend. Ini memastikan bahwa semua instans yang membatalkan pendaftaran di kumpulan backend tidak menerima permintaan/koneksi baru sambil mempertahankan koneksi yang ada hingga nilai batas waktu yang dikonfigurasi. Ini juga berlaku untuk koneksi WebSocket.

Jenis Konfigurasi Nilai
Nilai default saat pengurasan Koneksi ion tidak diaktifkan di Pengaturan Backend 30 detik
Nilai yang ditentukan pengguna saat pengurasan Koneksi ion diaktifkan di Pengaturan Backend 1 hingga 3600 detik

Satu-satunya pengecualian untuk ini adalah permintaan yang terikat untuk membatalkan pendaftaran instans karena afinitas sesi yang dikelola gateway dan akan terus diteruskan ke instans yang membatalkan pendaftaran.

Protokol

Application Gateway mendukung HTTP dan HTTPS untuk permintaan perutean ke server backend. Jika Anda memilih HTTP, lalu lintas ke server backend tidak terenkripsi. Jika komunikasi tidak terenkripsi tidak dapat diterima, pilih HTTPS.

Pengaturan ini dikombinasikan dengan HTTPS di pendengar mendukung TLS ujung ke ujung. Ini memungkinkan Anda untuk mengirimkan data sensitif secara aman yang dienkripsi ke ujung belakang. Setiap server backend di kumpulan backend yang mengaktifkan TLS end-to-end harus dikonfigurasi dengan sertifikat untuk memungkinkan komunikasi yang aman.

Port

Pengaturan ini menentukan port tempat server backend mendengarkan lalu lintas dari gateway aplikasi. Anda dapat mengonfigurasi port mulai dari 1 hingga 65535.

Sertifikat akar tepercaya

Jika Anda memilih HTTPS sebagai protokol backend, Application Gateway memerlukan sertifikat akar tepercaya untuk mempercayai kumpulan backend untuk SSL end-to-end. Secara default, opsi Gunakan sertifikat CA terkenal diatur ke Tidak. Jika Anda berencana untuk menggunakan sertifikat yang ditandatangani sendiri, atau sertifikat yang ditandatangani oleh Otoritas Sertifikat internal, maka Anda harus memberikan Application Gateway sertifikat publik yang cocok yang akan digunakan oleh kumpulan backend. Sertifikat ini harus diunggah langsung ke Application Gateway di . Format CER.

Jika Anda berencana untuk menggunakan sertifikat pada kumpulan backend yang ditandatangani oleh Otoritas Sertifikat publik tepercaya, maka Anda dapat mengatur opsi Gunakan sertifikat CA terkenal ke Ya dan melewati pengunggahan sertifikat publik.

Waktu permintaan habis

Pengaturan ini adalah jumlah detik gateway aplikasi menunggu untuk menerima respons dari server backend.

Ambil alih jalur backend

Pengaturan ini memungkinkan Anda mengonfigurasi jalur penerusan kustom opsional untuk digunakan saat permintaan diteruskan ke back end. Setiap bagian dari jalur masuk yang cocok dengan jalur kustom di bidang jalur ujung belakang override disalin ke jalur yang diteruskan. Tabel berikut ini memperlihatkan cara kerja fitur ini:

Ketika pengaturan HTTP dilampirkan ke aturan dasar permintaan perutean:

Permintaan asli Mengambil alih jalur backend Permintaan diteruskan ke back end
/home/ /override/ /override/home/
/home/secondhome/ /override/ /override/home/secondhome/

Ketika pengaturan HTTP dilampirkan ke aturan dasar permintaan perutean:

Permintaan asli Aturan jalur Mengambil alih jalur backend Permintaan diteruskan ke back end
/pathrule/home/ /pathrule* /override/ /override/home/
/pathrule/home/secondhome/ /pathrule* /override/ /override/home/secondhome/
/home/ /pathrule* /override/ /override/home/
/home/secondhome/ /pathrule* /override/ /override/home/secondhome/
/pathrule/home/ /pathrule/home* /override/ /override/
/pathrule/home/secondhome/ /pathrule/home* /override/ /override/secondhome/
/pathrule/ /pathrule/ /override/ /override/

Menggunakan pemeriksaan kustom

Pengaturan ini mengaitkan pemeriksaan kustom dengan pengaturan HTTP. Anda hanya dapat mengaitkan satu pemeriksaan kustom dengan pengaturan HTTP. Jika Anda tidak secara eksplisit mengaitkan pemeriksaan kustom, pemeriksaan default digunakan untuk memantau kesehatan ujung belakang. Kami menyarankan agar Anda membuat pemeriksaan kustom untuk kontrol yang lebih besar atas pemantauan kesehatan ujung belakang Anda.

Catatan

Pemeriksaan kustom tidak memantau kesehatan kumpulan backend kecuali pengaturan HTTP yang sesuai secara eksplisit terkait dengan pendengar.

Mengonfigurasi nama host

Application Gateway memungkinkan koneksi yang dibuat ke backend untuk menggunakan nama host yang berbeda dari yang digunakan oleh klien untuk menyambungkan ke Application Gateway. Meskipun konfigurasi ini dapat berguna dalam beberapa kasus, mengganti nama host agar berbeda antara klien dan gateway aplikasi dan gateway aplikasi ke target backend, harus dilakukan dengan hati-hati.

Dalam produksi, disarankan untuk menyimpan nama host yang digunakan oleh klien menuju gateway aplikasi sebagai nama host yang sama yang digunakan oleh gateway aplikasi ke target backend. Ini menghindari potensi masalah dengan URL absolut, URL pengalihan, dan cookie yang terikat host.

Sebelum menyiapkan Application Gateway yang menyimpang dari ini, silakan tinjau implikasi konfigurasi tersebut seperti yang dibahas secara lebih rinci di Pusat Arsitektur: Pertahankan nama host HTTP asli antara proksi terbalik dan aplikasi web backend-nya.

Ada dua aspek pengaturan HTTP yang memengaruhi header HTTP Host yang digunakan oleh Application Gateway untuk menyambungkan ke backend:

  • Pilih nama host dari alamat backend
  • Ganti nama host

Pilih nama host dari alamat backend

Kemampuan ini secara dinamis mengatur header host dalam permintaan ke nama host kumpulan backend. Ini menggunakan alamat IP atau FQDN.

Fitur ini membantu ketika nama domain ujung belakang berbeda dari nama DNS gateway aplikasi, dan ujung belakang bergantung pada header host tertentu untuk mengatasi titik akhir yang benar.

Contoh kasus adalah layanan multipenyewa sebagai ujung belakang. Layanan aplikasi adalah layanan multipenyewa yang menggunakan ruang bersama dengan satu alamat IP. Jadi, layanan aplikasi hanya dapat diakses melalui nama host yang dikonfigurasi di pengaturan domain kustom.

Secara default, nama domain kustom example.azurewebsites.net. Untuk mengakses layanan aplikasi Anda dengan menggunakan gateway aplikasi melalui nama host yang tidak terdaftar secara eksplisit di layanan aplikasi atau melalui FQDN gateway aplikasi, Anda dapat mengganti nama host dalam permintaan asli ke nama host layanan aplikasi. Untuk melakukan ini, aktifkan pengaturan pilih nama host dari alamat backend.

Untuk domain kustom yang nama DNS kustom yang ada dipetakan ke layanan aplikasi, konfigurasi yang direkomendasikan adalah tidak mengaktifkan nama host pilihan dari alamat backend.

Ganti nama host

Kemampuan ini menggantikan header host dalam permintaan masuk pada gateway aplikasi dengan nama host yang Anda tentukan.

Misalnya, jika www.contoso.com ditentukan dalam pengaturan Nama host, permintaan asli *https://appgw.eastus.cloudapp.azure.com/path1diubah menjadi *https://www.contoso.com/path1 ketika permintaan diteruskan ke server backend.

Kumpulan backend

Anda dapat mengarahkan kumpulan backend ke empat jenis anggota backend: komputer virtual tertentu, set skala komputer virtual, alamat IP/FQDN, atau layanan aplikasi.

Setelah membuat kumpulan backend, Anda harus mengaitkannya dengan satu atau beberapa aturan perutean permintaan. Anda juga harus mengonfigurasi pemeriksaan kesehatan untuk setiap kumpulan backend di gateway aplikasi Anda. Ketika kondisi aturan perutean permintaan terpenuhi, gateway aplikasi meneruskan lalu lintas ke server yang sehat (sebagaimana ditentukan oleh pemeriksaan kesehatan) di kumpulan backend yang sesuai.

Pemeriksaan kesehatan

Azure Application Gateway memantau kesehatan semua server di kumpulan backend-nya dan secara otomatis berhenti mengirim lalu lintas ke server apa pun yang dianggap tidak sehat. Pemeriksaan terus memantau server yang tidak sehat seperti itu, dan gateway mulai merutekan lalu lintas ke sana sekali lagi segera setelah pemeriksaan mendeteksinya sebagai sehat.

Pemeriksaan default menggunakan nomor port dari Pengaturan Backend terkait dan konfigurasi prasetel lainnya. Anda dapat menggunakan Pemeriksaan Kustom untuk mengonfigurasinya dengan cara Anda.

Perilaku pemeriksaan

Alamat IP sumber

Alamat IP sumber pemeriksaan tergantung pada jenis server backend:

  • Jika server di kumpulan backend adalah titik akhir publik, alamat sumber akan menjadi alamat IP publik frontend gateway aplikasi Anda.
  • Jika server di kumpulan backend adalah titik akhir privat, alamat IP sumber akan berasal dari ruang alamat subnet gateway aplikasi Anda.

Operasi pemeriksaan

Gateway mulai menembakkan pemeriksaan segera setelah Anda mengonfigurasi Aturan dengan mengaitkannya dengan Pengaturan Backend dan Kumpulan Backend (dan Listener, tentu saja). Ilustrasi menunjukkan bahwa gateway secara independen memeriksa semua server kumpulan backend. Permintaan masuk yang mulai tiba hanya dikirim ke server yang sehat. Server backend ditandai sebagai tidak sehat secara default hingga respons pemeriksaan berhasil diterima.

Diagram memperlihatkan contoh operasi pemeriksaan kesehatan gateway aplikasi Azure.

Pemeriksaan yang diperlukan ditentukan berdasarkan kombinasi unik Dari Server Backend dan Pengaturan Backend. Misalnya, pertimbangkan gateway dengan satu kumpulan backend dengan dua server dan dua pengaturan backend, masing-masing memiliki nomor port yang berbeda. Ketika pengaturan backend yang berbeda ini dikaitkan dengan kumpulan backend yang sama menggunakan aturan masing-masing, gateway membuat pemeriksaan untuk setiap server dan kombinasi pengaturan backend. Anda dapat melihat ini di halaman kesehatan Backend.

Cuplikan layar memperlihatkan contoh pengaturan kesehatan backend.

Selain itu, semua instans gateway aplikasi memeriksa server backend secara independen satu sama lain.

Catatan

Laporan kesehatan Backend diperbarui berdasarkan interval refresh masing-masing pemeriksaan dan tidak bergantung pada permintaan pengguna.

Pemeriksaan kesehatan default

Gateway aplikasi secara otomatis mengonfigurasi pemeriksaan kesehatan default saat Anda tidak menyiapkan konfigurasi pemeriksaan kustom apa pun. Perilaku pemantauan bekerja dengan membuat permintaan HTTP GET ke alamat IP atau FQDN yang dikonfigurasi di kumpulan backend. Untuk pemeriksaan default jika pengaturan http ujung belakang dikonfigurasi untuk HTTPS, pemeriksaan menggunakan HTTPS untuk menguji kesehatan server ujung belakang.

Misalnya: Anda mengonfigurasi gateway aplikasi untuk menggunakan server backend A, B, dan C untuk menerima lalu lintas jaringan HTTP pada port 80. Pemantauan kesehatan default menguji tiga server setiap 30 detik untuk respons HTTP yang sehat dengan batas waktu 30 detik untuk setiap permintaan. Respons HTTP yang sehat memiliki kode status antara 200 dan 399. Dalam hal ini, permintaan HTTP GET untuk pemeriksaan kesehatan terlihat seperti http://127.0.0.1/. Lihat juga kode respons HTTP di Application Gateway.

Jika pemantauan pemeriksaan default gagal untuk server A, gateway aplikasi berhenti meneruskan permintaan ke server ini. Pemeriksaan default masih terus memeriksa server A setiap 30 detik. Ketika server A berhasil merespons satu permintaan dari pemeriksaan kesehatan default, gateway aplikasi mulai meneruskan permintaan ke server lagi.

Pengaturan pemeriksaan kesehatan default

Properti pemeriksaan Nilai Keterangan
URL Pemeriksaan <protocol>://127.0.0.1:<port>/ Protokol dan port diwarisi dari pengaturan HTTP ujung belakang yang dikaitkan dengan pemeriksaan
Interval 30 Jumlah waktu dalam hitungan detik untuk menunggu sebelum pemeriksaan kesehatan berikutnya dikirim.
Waktu habis 30 Jumlah waktu dalam detik gateway aplikasi menunggu respons pemeriksaan sebelum menandai pemeriksaan tersebut sebagai tidak sehat. Jika pemeriksaan kembali sebagai sehat, ujung belakang yang sesuai segera ditandai sebagai sehat.
Ambang tidak sehat 3 Mengatur berapa banyak pemeriksaan untuk dikirim jika ada kegagalan pemeriksaan kesehatan biasa. Dalam SKU v1, pemeriksaan kesehatan tambahan ini dikirim secara cepat berturut-turut untuk menentukan kesehatan ujung belakang dengan cepat dan tidak menunggu jeda pemeriksaan. Untuk SKU v2, pemeriksaan kesehatan menunggu interval. Server backend ditandai ke bawah setelah jumlah kegagalan pemeriksaan berturut-turut mencapai ambang tidak sehat.

Pemeriksaan default hanya <melihat protokol>://127.0.0.1:<port> untuk menentukan status kesehatan. Jika Anda perlu mengonfigurasi pemeriksaan kesehatan untuk masuk ke URL kustom atau mengubah pengaturan lainnya, Anda harus menggunakan pemeriksaan kustom.

Pemeriksaan kesehatan kustom

Pemeriksaan khusus memungkinkan Anda untuk memiliki kontrol yang lebih terperinci atas pemantauan kesehatan. Saat menggunakan pemeriksaan kustom, Anda dapat mengonfigurasi nama host kustom, jalur URL, interval pemeriksaan, dan berapa banyak respons yang gagal diterima sebelum menandai instans kumpulan backend sebagai tidak sehat, dll.

Pengaturan pemeriksaan kesehatan default

Tabel berikut ini menyediakan definisi untuk properti pemeriksaan kesehatan kustom.

Properti pemeriksaan Keterangan
Nama Nama pemeriksaan. Nama ini digunakan untuk mengidentifikasi dan merujuk ke probe dalam pengaturan HTTP backend.
Protokol Protokol yang digunakan untuk mengirim pemeriksaan. Ini harus cocok dengan protokol yang ditentukan dalam pengaturan HTTP backend yang terkait dengannya
Host Nama host untuk mengirimkan pemeriksaan. Di SKU v1, nilai ini hanya digunakan untuk header host permintaan pemeriksaan. Dalam SKU v2, digunakan sebagai header host dan SNI
Jalur Jalur relatif dari pemeriksaan. Jalur yang valid dimulai dengan '/'
Port Jika didefinisikan, ini digunakan sebagai port tujuan. Jika tidak, ia menggunakan port yang sama dengan pengaturan HTTP yang terkait dengannya. Properti ini hanya tersedia di SKU v2
Interval Jeda pemeriksaan dalam hitungan detik. Nilai ini adalah jeda waktu antara dua pemeriksaan berurutan
Waktu habis Menyelidiki waktu habis dalam hitungan detik. Jika respons yang valid tidak diterima dalam periode waktu habis ini, pemeriksaan ditandai sebagai gagal
Ambang tidak sehat Menyelidiki jumlah percobaan kembali. Server backend ditandai ke bawah setelah jumlah kegagalan pemeriksaan berturut-turut mencapai ambang tidak sehat

Pencocokan pemeriksaan

Secara default, respons HTTP dengan kode status antara 200 dan 399 dianggap sehat. Pemeriksaan kesehatan kustom juga mendukung dua kriteria yang cocok. Kriteria pencocokan dapat digunakan untuk secara opsional mengubah interpretasi default dari apa yang membuat respons yang sehat.

Berikut ini adalah kriteria yang cocok:

  • Kecocokan kode status respons HTTP - Kriteria pencocokan pemeriksaan untuk menerima kode respons http yang ditentukan pengguna atau rentang kode respons. Kode status respons individual yang dipisahkan koma atau rentang kode status didukung.
  • Kecocokan badan respons HTTP - Kriteria pencocokan pemeriksaan yang melihat badan respons HTTP dan cocok dengan string yang ditentukan pengguna. Kecocokan hanya mencari kehadiran string yang ditentukan pengguna dalam isi respons dan bukan kecocokan ekspresi reguler penuh. Kecocokan yang ditentukan harus 4090 karakter atau kurang.

Kriteria kecocokan dapat ditentukan menggunakan New-AzApplicationGatewayProbeHealthResponseMatch cmdlet.

Misalnya:

Azure PowerShell

$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399




$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"

Kriteria pencocokan dapat dilampirkan ke konfigurasi pemeriksaan menggunakan -Match operator di PowerShell.

Kasus penggunaan pemeriksaan kustom

  • Jika server backend memungkinkan akses hanya ke pengguna yang diautentikasi, pemeriksaan gateway aplikasi akan menerima kode respons 403 alih-alih 200. Karena klien (pengguna) terikat untuk mengautentikasi diri mereka sendiri untuk lalu lintas langsung, Anda dapat mengonfigurasi lalu lintas pemeriksaan untuk menerima 403 sebagai respons yang diharapkan.
  • Ketika server backend memiliki sertifikat kartubebas (*.contoso.com) yang diinstal untuk melayani sub-domain yang berbeda, Anda dapat menggunakan pemeriksaan Kustom dengan nama host tertentu (diperlukan untuk SNI) yang diterima untuk membuat pemeriksaan TLS yang berhasil dan melaporkan server tersebut sehat. Dengan "ganti nama host" di Pengaturan Backend diatur ke TIDAK, nama host masuk (subdomain) yang berbeda akan diteruskan apa adanya ke backend.

Pertimbangan kelompok keamanan jaringan (NSG)

Kontrol butir halus atas subnet Application Gateway melalui aturan NSG dimungkinkan dalam pratinjau publik. Rincian selengkapnya dapat ditemukan di sini.

Dengan fungsionalitas saat ini ada beberapa batasan:

Anda harus mengizinkan lalu lintas Internet masuk pada port TCP 65503-65534 untuk SKU v1 Application Gateway, dan port TCP 65200-65535 untuk SKU v2 dengan subnet tujuan sebagai Apa pun dan sumber sebagai tag layanan GatewayManager. Rentang port ini diperlukan untuk komunikasi infrastruktur Azure.

Selain itu, konektivitas Internet keluar tidak dapat diblokir, dan lalu lintas masuk yang berasal dari tag AzureLoadBalancer harus diizinkan.

Cara kerja app gateway

Diagram memperlihatkan contoh cara kerja gateway aplikasi Azure.

Cara app gateway menerima permintaan

  1. Sebelum klien mengirim permintaan ke app gateway, ia menyelesaikan nama domain app gateway menggunakan server Sistem Nama Domain (DNS). Azure mengontrol entri DNS karena semua app gateway berada di domain azure.com.
  2. Azure DNS mengembalikan alamat IP ke klien, yang merupakan alamat IP frontend app gateway.
  3. App gateway menerima lalu lintas masuk pada satu atau beberapa listener. Listener adalah entitas logis yang memeriksa permintaan koneksi masuk. Dikonfigurasi dengan alamat IP frontend, protokol, dan nomor port untuk koneksi dari klien ke app gateway.
  4. Jika aplikasi web firewall (WAF) sedang digunakan, app gateway memeriksa header permintaan dan isi, jika ada, melanggar aturan WAF. Tindakan ini menentukan apakah permintaan tersebut adalah permintaan yang valid atau ancaman keamanan. Jika permintaan valid, permintaan dirutekan ke backend. Jika permintaan tidak valid dan WAF dalam mode Pencegahan, permintaan diblokir sebagai ancaman keamanan. Jika dalam mode Deteksi, permintaan dievaluasi dan dicatat, tapi tetap diteruskan ke server backend.

Azure Application Gateway bisa digunakan sebagai load balancer aplikasi internal atau load balancer aplikasi akses internet. App gateway akses internet menggunakan alamat IP publik. Nama DNS app gateway akses internet bisa ditentukan secara publik ke alamat IP publiknya. Hasilnya, app gateway akses internet bisa merutekan permintaan klien dari internet.

App gateway internal hanya menggunakan alamat IP privat. Jika Anda menggunakan zona DNS Kustom atau Privat, nama domain harus dapat diselesaikan secara internal ke alamat IP privat Application Gateway. Karenanya, load balancer internal hanya bisa merutekan permintaan dari klien dengan akses ke jaringan virtual untuk app gateway.

Bagaimana app gateway merutekan permintaan

Jika permintaan valid dan tidak diblokir oleh WAF, app gateway mengevaluasi aturan perutean permintaan yang terkait dengan listener. Tindakan ini menentukan kumpulan backend mana yang akan merutekan permintaan.

Berdasarkan aturan perutean permintaan, app gateway menentukan apakah akan merutekan semua permintaan di listener ke kumpulan backend tertentu, atau merutekan permintaan ke kumpulan backend yang berbeda berdasarkan jalur URL, atau mengalihkan permintaan ke port atau situs eksternal lain.

Ketika app gateway memilih kumpulan backend, app gateway akan mengirimkan permintaan ke salah satu server backend yang sehat di pool (y.y.y.y). Kesehatan server ditentukan oleh pemeriksaan kesehatan. Jika kumpulan backend berisi beberapa server, app gateway menggunakan algoritma round-robin untuk merutekan permintaan antara server sehat. Muatan ini menyeimbangkan permintaan pada server.

Setelah app gateway menentukan server backend, app gateway akan membuka sesi TCP baru dengan server backend berdasarkan pengaturan HTTP. Pengaturan HTTP menentukan protokol, port, dan setelan terkait perutean lainnya yang diperlukan untuk membuat sesi baru dengan server backend.

Port dan protokol yang digunakan dalam pengaturan HTTP menentukan apakah lalu lintas antara app gateway dan server backend dienkripsi (sehingga menyelesaikan TLS end-to-end) atau tidak terenkripsi.

Catatan

Aturan diproses sesuai urutan yang tercantum di portal untuk v1 SKU.

Ketika app gateway mengirim permintaan asli ke server backend, app gateway akan mematuhi konfigurasi kustom apa pun yang dibuat dalam pengaturan HTTP terkait untuk menimpa nama host, jalur, dan protokol. Tindakan ini mempertahankan afinitas sesi berbasis cookie, pengurasan koneksi, pemilihan nama host dari backend, dan sebagainya.

Jika kumpulan backend:

  • Adalah titik akhir publik, app gateway menggunakan IP publik frontend nya untuk mencapai server. Jika tidak ada alamat IP publik frontend, alamat IP publik ditetapkan untuk konektivitas eksternal keluar.
  • Berisi FQDN yang disesuaikan secara internal atau alamat IP pribadi, app gateway merutekan permintaan ke server backend dengan menggunakan alamat IP pribadi instans nya.
  • Berisi titik akhir eksternal atau FQDN yang bisa di-penyelesaian secara eksternal,app gateway merutekan permintaan ke server backend dengan menggunakan alamat IP publik frontend nya. Jika subnet berisi titik akhir layanan, gateway aplikasi akan merutekan permintaan ke layanan melalui alamat IP privatnya. Resolusi DNS didasarkan pada zona DNS privat atau server DNS kustom, jika dikonfigurasi, atau menggunakan DNS default yang disediakan Azure. Jika tidak ada alamat IP publik frontend, alamat IP publik ditetapkan untuk konektivitas eksternal keluar.

Resolusi DNS server backend

Saat server kumpulan backend dikonfigurasi dengan Nama Domain yang Sepenuhnya Memenuhi Syarat (FQDN), Application Gateway melakukan pencarian DNS untuk mendapatkan alamat IP nama domain. Nilai IP disimpan di cache gateway aplikasi Anda untuk memungkinkannya mencapai target lebih cepat saat melayani permintaan masuk.

Application Gateway menyimpan informasi cache ini untuk periode yang setara dengan TTL (waktu hidup) rekaman DNS tersebut dan melakukan pencarian DNS baru setelah TTL kedaluwarsa. Jika gateway mendeteksi perubahan alamat IP untuk kueri DNS berikutnya, gateway akan mulai merutekan lalu lintas ke tujuan yang diperbarui ini. Jika terjadi masalah seperti pencarian DNS yang gagal menerima respons atau catatan tidak ada lagi, gateway terus menggunakan alamat IP terakhir yang diketahui baik. Ini memastikan dampak minimal pada jalur data.

  • Saat menggunakan server DNS kustom dengan Virtual Network Application Gateway, sangat penting bahwa semua server identik dan merespons secara konsisten dengan nilai DNS yang sama.
  • Pengguna server DNS kustom lokal harus memastikan konektivitas ke Azure DNS melalui Azure DNS Private Resolver (disarankan) atau komputer virtual penerus DNS saat menggunakan zona DNS Privat untuk titik akhir Privat.

Modifikasi pada permintaan

Gateway aplikasi menyisipkan enam header tambahan ke semua permintaan sebelum meneruskan permintaan ke backend. Header ini adalah x-forwarded-for, x-forwarded-port, x-forwarded-proto, x-original-host, x-original-url, dan x-appgw-trace-id. Format untuk header x-forwarded-for adalah daftar IP:port yang dipisahkan koma.

Nilai yang valid untuk x-teruskan-proto adalah HTTP atau HTTPS. X-forwarded-port menentukan port di mana permintaan mencapai app gateway. Header X-original-host berisi header host asli tempat permintaan tiba. Header ini berguna dalam integrasi situs web Azure, di mana header host masuk dimodifikasi sebelum lalu lintas dirutekan ke backend. Jika afinitas sesi diaktifkan sebagai opsi, maka akan menambahkan cookie afinitas yang dikelola gateway.

X-appgw-trace-id adalah guid unik yang dihasilkan oleh gateway aplikasi untuk setiap permintaan klien dan disajikan dalam permintaan yang diteruskan ke anggota kumpulan backend. Guid terdiri dari 32 karakter alfanumerik yang disajikan tanpa tanda hubung (misalnya: ac882cd65a2712a0fe1289ec2bb6aee7). Guid ini dapat digunakan untuk menghubungkan permintaan yang diterima oleh gateway aplikasi dan dimulai ke anggota kumpulan backend melalui properti transactionId di Log Diagnostik.

Anda bisa mengonfigurasi app gateway untuk memodifikasi permintaan dan merespon header dan URL menggunakanRegenerasi HTTP header dan URL atau untuk memodifikasi jalur URI menggunakan pengaturan ambil alih jalur. Tapi, kecuali dikonfigurasi untuk melakukannya, semua permintaan yang masuk diproksikan ke backend.