Gambaran umum pemeriksaan kesehatan Application Gateway
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.
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.
Selain itu, semua instans gateway aplikasi memeriksa server backend secara independen satu sama lain.
Jeda pemeriksaan
Konfigurasi pemeriksaan yang sama berlaku untuk setiap instans Application Gateway Anda. Misalnya, jika gateway aplikasi memiliki dua instans dan interval pemeriksaan diatur ke 20 detik, kedua instans akan mengirim pemeriksaan kesehatan setiap 20 detik.
Setelah pemeriksaan mendeteksi respons yang gagal, penghitung untuk "Ambang tidak sehat" dimatikan dan menandai server sebagai tidak sehat jika jumlah gagal berturut-turut cocok dengan ambang batas yang dikonfigurasi. Oleh karena itu, jika Anda menetapkan Ambang Tidak Sehat ini sebagai 2, pemeriksaan berikutnya akan terlebih dahulu mendeteksi kegagalan ini. Gateway aplikasi kemudian akan menandai server sebagai tidak sehat setelah 2 pemeriksaan gagal berturut-turut [Deteksi pertama 20 detik + (2 pemeriksaan gagal berturut-turut * 20 detik)].
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 | Deskripsi |
|---|---|---|
| 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. Untuk informasi selengkapnya tentang pemeriksaan HTTPS, lihat Gambaran umum penghentian TLS dan TLS end to end dengan Application Gateway.
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 | Deskripsi |
|---|---|
| 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.
Contohnya:
$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399
$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"
Kriteria pencocokan dapat dilampirkan ke konfigurasi pemeriksaan menggunakan -Match operator di PowerShell.
Beberapa kasus penggunaan untuk 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 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.
Untuk informasi selengkapnya, lihat ringkasan konfigurasi Application Gateway.
Langkah berikutnya
Setelah mempelajari tentang pemantauan kesehatan Application Gateway, Anda dapat mengonfigurasi pemeriksaan kesehatan kustom di portal Microsoft Azure atau pemeriksaan kesehatan kustom menggunakan PowerShell dan model penyebaran Azure Resource Manager.