Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Pemeriksaan kesehatan Azure Load Balancer adalah fitur yang mendeteksi status kesehatan instans aplikasi Anda. Ini mengirimkan permintaan ke instans untuk memeriksa apakah mereka tersedia dan menanggapi permintaan. Pemeriksaan kesehatan dapat dikonfigurasi untuk menggunakan protokol yang berbeda seperti TCP, HTTP, atau HTTPS. Ini adalah fitur penting karena membantu Anda mendeteksi kegagalan aplikasi, mengelola beban, dan merencanakan waktu henti.
Azure Load Balancer aturan memerlukan pemeriksaan kesehatan untuk mendeteksi status titik akhir. Konfigurasi respons pemeriksaan kesehatan dan pemeriksaan menentukan instans kumpulan backend mana yang menerima koneksi baru. Gunakan pemeriksaan kesehatan untuk mendeteksi kegagalan aplikasi. Hasilkan respons khusus terhadap pemeriksaan kesehatan. Gunakan pemeriksaan kesehatan untuk kontrol aliran untuk mengelola beban atau waktu henti yang direncanakan. Ketika pemeriksaan kesehatan gagal, load balancer berhenti mengirim koneksi baru ke instans yang tidak sehat masing-masing. Konektivitas keluar tidak terpengaruh, hanya konektivitas masuk yang terpengaruh.
Protokol pemeriksaan
Pemeriksaan kesehatan mendukung beberapa protokol. Ketersediaan protokol pemeriksaan kesehatan tertentu bervariasi tergantung pada SKU Penyeimbang Beban. Selain itu, perilaku layanan bervariasi menurut Load Balancer SKU seperti yang ditunjukkan dalam tabel ini:
| SKU | Protokol pemeriksaan | Perilaku penurunan probe |
|---|---|---|
| Standar | TCP, HTTP, HTTPS | Semua penyelidikan turun, semua aliran TCP berlanjut. |
| Dasar | TCP, HTTP | Semua penyelidikan turun, semua aliran TCP kedaluwarsa. |
Properti pemeriksaan
Pemeriksaan kesehatan memiliki properti berikut:
| Nama properti Pemeriksaan Kesehatan | Detil |
|---|---|
| Nama | Nama alat pemeriksaan kesehatan. Ini adalah nama yang dapat Anda tentukan untuk pemeriksaan kesehatan Anda |
| Protokol | Protokol pemeriksaan kesehatan. Ini adalah jenis protokol yang Anda inginkan digunakan untuk pemeriksaan kesehatan. Opsinya adalah: TCP, HTTP, HTTPS |
| Pelabuhan | Port pemeriksaan kesehatan. Port tujuan yang Anda inginkan untuk digunakan pemeriksaan kesehatan saat tersambung ke komputer virtual untuk memeriksa kesehatannya |
| Interval (detik) | Interval pemeriksaan kesehatan. Jumlah waktu (dalam detik) antara pemeriksaan yang berbeda pada dua upaya pemeriksaan kesehatan berturut-turut ke komputer virtual |
| Ambang | Ambang batas pemeriksaan kesehatan. Jumlah kali probe kesehatan harus berhasil atau gagal agar lalu lintas diizinkan atau ditolak untuk diteruskan ke komputer virtual |
| Digunakan oleh | Daftar aturan load balancer yang menggunakan probe kesehatan ini. Anda harus memiliki setidaknya satu aturan yang menggunakan pengecekan kesehatan agar dapat berfungsi dengan baik. |
Konfigurasi probe
Konfigurasi pemeriksaan kesehatan terdiri dari unsur-unsur berikut:
| Konfigurasi Probe Kesehatan | Detil |
|---|---|
| Protokol | Protokol pemeriksaan kesehatan. Ini adalah jenis protokol yang Anda inginkan digunakan untuk pemeriksaan kesehatan. Opsi yang tersedia adalah: TCP, HTTP, HTTPS |
| Pelabuhan | Port pemeriksaan kesehatan. Port tujuan yang ingin Anda gunakan ketika pemantauan kesehatan terhubung ke mesin virtual untuk memeriksa status kesehatan mesin virtual. Anda harus memastikan bahwa komputer virtual juga mendengarkan port ini (artinya, port terbuka). |
| Interval | Interval pemeriksaan kesehatan. Jumlah waktu (dalam detik) antara upaya pemeriksaan kesehatan berturut-turut ke komputer virtual |
Protokol pemeriksaan
Protokol yang digunakan oleh health probe dapat dikonfigurasi ke salah satu opsi berikut: TCP, HTTP, HTTPS.
| Skenario | TCP periksa | Pemeriksaan HTTP / HTTPS |
|---|---|---|
| Gambaran Umum | Sonde TCP memulai koneksi dengan melakukan handshake TCP tiga arah dengan port yang ditentukan. Pemeriksaan TCP mengakhiri koneksi dengan jabat tangan TCP empat arah. | HTTP dan HTTPS mengeluarkan HTTP GET dengan jalur yang ditentukan. Kedua pengujian ini mendukung jalur relatif untuk HTTP GET. Pemeriksaan HTTPS sama dengan pemeriksaan HTTP dengan penambahan Transport Layer Security (TLS). Pemeriksaan HTTP/HTTPS dapat berguna untuk mengimplementasikan logika Anda sendiri untuk menghapus instance dari load balancer jika port pemeriksaan juga merupakan listener untuk layanan tersebut. |
| Perilaku kegagalan pemeriksaan | Pemeriksaan TCP gagal ketika: 1. Pendengar TCP pada instans tidak merespons sama sekali selama periode batas waktu. Pengujian ditandai berdasarkan jumlah permintaan pengujian yang melebihi batas waktu, yang dikonfigurasi untuk tidak mendapat jawaban sebelum menandai pengujian tersebut. 2. Proba menerima reset TCP dari instans. |
Pemeriksaan HTTP/HTTPS gagal ketika: 1. Titik akhir pemeriksaan mengembalikan kode respons HTTP selain 200 (misalnya, 403, 404, atau 500). 2. Titik akhir probe tidak merespons sama sekali selama interval minimum probe dan periode waktu kedaluwarsa 30 detik. Beberapa permintaan probe mungkin tidak mendapat respons sebelum probe tersebut ditandai sebagai tidak berjalan dan hingga jumlah semua interval batas waktu tercapai. 3. Titik akhir probe menutup koneksi melalui reset TCP. |
| Penyelidikan perilaku | Pemeriksaan kesehatan TCP dianggap sehat dan menandai endpoint backend sebagai memiliki status sehat ketika: 1. Pemeriksaan kesehatan berhasil sekali setelah VM dinyalakan. 2. Setiap titik akhir backend dalam keadaan sehat memenuhi syarat untuk menerima alur baru. |
Pemeriksaan kesehatan ditandai ketika instans merespons dengan status HTTP 200 dalam periode waktu habis. Pemeriksaan kesehatan HTTP/HTTPS dianggap sehat dan menandai titik akhir backend sebagai sehat ketika: 1. Pemeriksaan kesehatan berhasil sekali setelah VM dinyalakan. 2. Setiap titik akhir backend dalam keadaan sehat memenuhi syarat untuk menerima alur baru. |
Catatan
Pemeriksaan HTTPS memerlukan penggunaan sertifikat berdasarkan yang memiliki tanda tangan hash minimum SHA256 di seluruh rantai.
Perilaku penyelidikan lebih mendalam
| Skenario | Koneksi TCP | Datagram UDP |
|---|---|---|
| Sistem pemantauan instans tunggal sedang mati | Koneksi TCP baru berhasil untuk tetap menjadi titik akhir backend yang sehat. Koneksi TCP yang dibuat ke titik akhir backend ini berlanjut. | Alur UDP yang ada berpindah ke instans sehat lain di kumpulan backend. |
| Semua pemeriksaan instans mengalami kegagalan | Tidak ada aliran baru yang dikirim ke kumpulan backend. Load Balancer Standar memungkinkan aliran TCP yang sudah terhubung untuk terus berlanjut selama kumpulan backend memiliki lebih dari satu instans backend. Basic Load Balancer (dipensiunkan) mengakhiri semua alur TCP yang ada ke backend pool. | Semua alur UDP yang ada dihentikan. |
Interval pemeriksaan & waktu habis
Nilai interval menentukan seberapa sering pemantauan kesehatan memeriksa respons instans kumpulan backend Anda. Jika probe kesehatan gagal, penyeimbang beban segera menandai instance dalam kumpulan backend Anda sebagai tidak sehat. Jika pemeriksaan kesehatan berhasil pada pemeriksaan berikutnya, Azure Load Balancer menandai instans kumpulan backend Anda berstatus sehat. Secara default, probe kesehatan mencoba memeriksa port probe kesehatan yang dikonfigurasi setiap 5 detik melalui portal Azure, tetapi Anda dapat mengubahnya ke nilai lain. Saat Anda menerapkan melalui template ARM, REST API, Azure CLI, atau PowerShell, interval default adalah 15 detik (minimal 5 detik).
Untuk memastikan tanggapan diterima tepat waktu, pemeriksaan kesehatan HTTP/S memiliki batas waktu yang sudah terpasang. Berikut ini adalah durasi batas waktu untuk pemeriksaan TCP dan HTTP/S:
- Durasi batas waktu pemeriksaan TCP: Tidak Berlaku (pemeriksaan akan gagal setelah interval pemeriksaan yang dikonfigurasi berakhir dan pemeriksaan berikutnya dilakukan)
- Durasi batas waktu probe HTTP/S: 30 detik
Untuk pemeriksaan HTTP/S, jika interval yang dikonfigurasi lebih lama dari periode batas waktu di atas, waktu pemeriksaan kesehatan habis dan gagal jika tidak ada respons yang diterima selama periode waktu habis. Misalnya, jika pemeriksaan kesehatan HTTP dikonfigurasi dengan interval pemeriksaan 120 detik (setiap 2 menit), dan tidak ada respons pemeriksaan yang diterima dalam 30 detik pertama, pemeriksaan mencapai batas waktu habis dan gagal. Ketika interval yang dikonfigurasi lebih pendek dari periode batas waktu di atas, pemeriksaan kesehatan akan gagal jika tidak ada respons yang diterima sebelum periode interval yang dikonfigurasi selesai dan pemeriksaan berikutnya akan segera dikirim.
Ambang batas probe
Nilai ambang batas pemeriksaan adalah berapa kali pemeriksaan kesehatan perlu berhasil atau gagal secara berturut-turut agar pemeriksaan menandai instans backend sebagai sehat atau tidak sehat, masing-masing.
Untuk pemeriksaan TCP, jika ambang batas pemeriksaan dikonfigurasi ke 2, pemeriksaan harus menerima 2 respons berturut-turut sebelum instans backend mulai menerima lalu lintas. Demikian pula, setelah instans backend dianggap sehat, 2 kegagalan berturut-turut atau batas waktu diperlukan agar instans dianggap tidak sehat dan berhenti menerima lalu lintas baru.
Untuk probe HTTP, respons eksplisit akan segera menandai probe sebagai aktif untuk respons 200 dan nonaktif untuk respons non-200, serta secara efektif mereset nilai ambang batas. Ini berarti bahwa nilai ambang batas hanya berlaku untuk pemeriksaan HTTP jika waktu pemeriksaan habis karena tidak ada respons.
Panduan desain
Ketika Anda merancang model kesehatan untuk aplikasi Anda, uji sebuah port pada titik akhir backend yang menggambarkan kesehatan instans tersebut dan layanan aplikasi. Port aplikasi dan port pengujian tidak perlu sama. Dalam beberapa skenario, mungkin diinginkan agar port probe berbeda dari port yang digunakan aplikasi Anda; namun, umumnya disarankan agar probe menggunakan port yang sama.
Ini dapat berguna bagi aplikasi Anda untuk menghasilkan respons penilaian kesehatan, dan memberikan sinyal kepada load balancer apakah instans Anda harus menerima koneksi baru. Anda dapat memanipulasi respons sistem pemeriksaan untuk membatasi pengiriman koneksi baru ke instans dengan menyebabkan kegagalan pada pemeriksaan kesehatan. Anda dapat mempersiapkan pemeliharaan aplikasi Anda dan memulai pengeringan koneksi ke aplikasi Anda. Sinyal probe down selalu memungkinkan alur TCP berlanjut hingga batas waktu diam atau penutupan koneksi di Load Balancer Standar.
Untuk aplikasi keseimbangan beban UDP, buat sinyal pemeriksaan kesehatan kustom dari titik akhir backend. Gunakan TCP, HTTP, atau HTTPS untuk deteksi kesehatan yang sesuai dengan pendengar yang terkait.
Aturan penyeimbangan beban Port HA dengan Standard Load Balancer. Semua port memiliki beban seimbang dan respons pemeriksaan kesehatan tunggal harus mencerminkan status seluruh instans.
Jangan menerjemahkan atau proksi pemeriksa kesehatan melalui instans yang menerima pemeriksa kesehatan ke instans lain dalam jaringan virtual Anda. Konfigurasi ini dapat menyebabkan kegagalan dalam skenario Anda. Sebagai contoh: Sekumpulan perangkat pihak ketiga dikerahkan dalam kumpulan backend dari sebuah penyeimbang beban untuk menyediakan skala dan redundansi pada perangkat tersebut. Pemeriksaan kesehatan dikonfigurasi untuk memeriksa port yang diproksikan atau diterjemahkan oleh appliance pihak ketiga ke mesin virtual lain di belakang appliance. Jika Anda memeriksa port yang sama yang digunakan untuk menerjemahkan atau memproksi permintaan ke mesin virtual lain di belakang perangkat, respons pemeriksaan apa pun dari satu mesin virtual dapat menandai perangkat sebagai tidak aktif atau gagal. Konfigurasi ini dapat menyebabkan kegagalan beruntun aplikasi. Pemicu dapat menjadi kegagalan pemeriksaan terputus-terputus yang menyebabkan load balancer menandai instans appliance. Tindakan ini dapat menonaktifkan aplikasi Anda. Pemeriksaan kesehatan perangkat itu sendiri. Pemilihan pemeriksaan untuk menentukan sinyal kesehatan merupakan pertimbangan penting untuk skenario appliance jaringan virtual (NVA). Konsultasikan dengan vendor aplikasi Anda untuk sinyal kesehatan yang sesuai dengan skenario tersebut.
Jika Anda memiliki beberapa antarmuka yang dikonfigurasi di mesin virtual Anda, pastikan Anda menanggapi pemeriksaan pada antarmuka yang Anda terima. Anda mungkin perlu sumber alamat jaringan menerjemahkan alamat ini di VM berdasarkan per antarmuka.
Definisi pemeriksaan tidak wajib atau diperiksa saat menggunakan Azure PowerShell, Azure CLI, Templat, atau API. Pengujian validasi hanya dilakukan saat menggunakan portal Azure.
Jika pemeriksaan kesehatan berubah-ubah, penyeimbang beban menunggu lebih lama sebelum mengembalikan titik akhir backend ke kondisi sehat. Waktu tunggu ekstra ini melindungi pengguna dan infrastruktur dan merupakan kebijakan yang disengaja.
Pastikan instans komputer virtual Anda sedang beroperasi. Untuk setiap instans yang berjalan di kumpulan backend, pemeriksaan kesehatan memeriksa ketersediaan. Jika instans dihentikan, instans tersebut tidak akan diperiksa hingga dimulai lagi.
Jangan konfigurasikan VNet Anda dengan rentang alamat IP milik Microsoft yang berisi 168.63.129.16. Konfigurasi bertabrakan dengan alamat IP pemeriksaan kesehatan dan dapat menyebabkan skenario Anda gagal.
Untuk menguji kegagalan pemeriksa kesehatan atau menandai instans individu, gunakan kelompok keamanan jaringan untuk secara eksplisit memblokir pemeriksa kesehatan. Buat aturan NSG untuk memblokir port tujuan atau IP sumber untuk mensimulasikan kegagalan pemeriksaan.
Tidak seperti aturan penyeimbangan beban, aturan NAT masuk tidak memerlukan pemeriksaan kesehatan yang melekat padanya.
Tidak disarankan untuk memblokir IP atau port pemeriksaan kesehatan Azure Load Balancer dengan aturan NSG. Ini adalah skenario yang tidak didukung dan dapat menyebabkan aturan NSG mengalami keterlambatan penerapan, yang mengakibatkan pengujian kesehatan dapat menggambarkan secara tidak akurat ketersediaan instans backend Anda.
Memecahkan masalah pada respons probe kesehatan NVA
Jika antarmuka jaringan manajemen perangkat virtual jaringan (NVA) menerima probe kesehatan tetapi perangkat tidak meresponsnya, gunakan Troubleshoot kegagalan probe kesehatan di Azure Load Balancer untuk memeriksa konfigurasi probe, aturan keamanan jaringan, dan pendengar. Untuk NVA dengan beberapa antarmuka jaringan, pastikan juga bahwa perangkat memberikan respons pada antarmuka yang menerima probe, seperti yang dijelaskan dalam Panduan desain.
Untuk menemukan log alur yang ada di wilayah NVA, jalankan perintah Azure CLI berikut. Kemudian, gunakan log alur jaringan virtual atau analitik lalu lintas untuk memfilter lalu lintas berdasarkan alamat IP privat antarmuka jaringan manajemen dan port probe yang dikonfigurasi. Untuk probe IPv4, saring juga berdasarkan alamat IP sumber 168.63.129.16. Untuk probe IPv6, gunakan alamat sumber link-local yang tercantum di Probe source IP address.
az network watcher flow-log list --location '<region>' --output table
Untuk memvalidasi probe IPv4 pada tingkat paket, mulai penangkapan paket yang difilter pada mesin virtual NVA.
Penangkapan paket Network Watcher memerlukan AzureNetworkWatcherExtension pada VM target. Verifikasi bahwa perangkat mendukung ekstensi dan memenuhi prasyarat penangkapan paket yang terdokumentasi sebelum menggunakan perintah ini. Untuk perangkat yang tidak dapat menggunakan ekstensi, lihat prosedur pengambilan tangkapan yang didukung vendor. Ganti nilai placeholder pada perintah berikut:
az network watcher packet-capture create \
--resource-group '<nva-resource-group>' \
--name 'nva-health-probe' \
--vm '<nva-vm-name>' \
--storage-account '<storage-account-name-or-id>' \
--time-limit 300 \
--filters '[{"protocol":"TCP","remoteIPAddress":"168.63.129.16","localIPAddress":"<management-interface-private-ip>","localPort":"<probe-port>"}]'
Jika perangkat menampilkan log sistem operasi atau firewall, gunakan instruksi logging vendor untuk membandingkan entri yang relevan dengan timestamp penangkapan dan detail koneksi. Jika penangkapan paket menunjukkan probe yang masuk tetapi tidak ada respons, periksa konfigurasi listener, firewall, dan jalur balik menggunakan daftar periksa pemecahan masalah NVA, dan libatkan vendor perangkat jika diperlukan.
Pemantauan
Standard Load Balancer mengekspos status pemeriksaan kesehatan per titik akhir dan titik akhir backend melalui Azure Monitor. Layanan Azure atau aplikasi mitra lainnya dapat menggunakan metrik ini. log Azure Monitor tidak didukung pada Basic Load Balancer (telah dihentikan).
Alamat IP sumber pemeriksaan
Agar pemeriksaan kesehatan Azure Load Balancer menandai instans Anda, Anda harus mengizinkan alamat IP 168.63.129.16 di grup keamanan jaringan Azure dan kebijakan firewall lokal apa pun. Tag AzureLoadBalancer layanan mengidentifikasi alamat IP sumber ini di grup keamanan jaringan Anda dan mengizinkan lalu lintas pemeriksaan kesehatan secara default. Anda dapat mempelajari lebih lanjut tentang IP ini di sini.
Jika Anda tidak mengizinkan IP sumber pemeriksaan dalam kebijakan firewall Anda, pemeriksaan kesehatan gagal karena tidak dapat menjangkau instans Anda. Pada gilirannya, Azure Load Balancer menandai instans Anda sebagai -down- karena kegagalan pemeriksaan kesehatan. Kesalahan konfigurasi ini dapat menyebabkan skenario aplikasi seimbang beban Anda gagal. Semua pemeriksaan kesehatan IPv4 Load Balancer berasal dari alamat IP 168.63.129.16 sebagai sumbernya. Probing IPv6 menggunakan alamat lokal tautan (fe80::1234:5678:9abc) sebagai sumbernya. Untuk Azure Load Balancer dual stack, Anda harus mengonfigurasi Network Security Group agar pengujian kesehatan IPv6 berfungsi.
Batasan
Pengujian HTTPS tidak mendukung autentikasi dua arah dengan sertifikat klien.
Pemeriksaan HTTP tidak mendukung penggunaan nama host untuk pemeriksaan backend.
Mengaktifkan tanda waktu TCP dapat menyebabkan pembatasan atau masalah performa lainnya, yang kemudian dapat menyebabkan pemeriksaan kesehatan kehabisan waktu.
Health probe untuk Basic Load Balancer (sudah pensiun) tidak didukung dengan set timbangan mesin virtual.
Pengecekan HTTP tidak mendukung pengecekan pada port berikut karena masalah keamanan: 19, 21, 25, 70, 110, 119, 143, 220, 993.