Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Usługa Azure Application Gateway monitoruje kondycję wszystkich serwerów w puli zaplecza i automatycznie zatrzymuje wysyłanie ruchu do każdego serwera, który uważa za niesprawny. Sondy nadal monitorują taki serwer w złej kondycji, a brama uruchamia kierowanie ruchu do niego po raz kolejny, gdy tylko sondy wykryją go jako w dobrej kondycji.
Domyślna sonda używa numeru portu ze skojarzonego ustawienia zaplecza i innych wstępnych konfiguracji. Możesz użyć niestandardowych sond, aby skonfigurować je według własnych upodobań.
Działanie sond
Źródłowy adres IP
Źródłowy adres IP sond zależy od typu serwera zaplecza:
- Jeśli serwer w puli zaplecza jest publicznym punktem końcowym, adres źródłowy będzie publicznym adresem IP frontendu bramy aplikacji.
- Jeśli serwer w puli zaplecza jest prywatnym punktem końcowym, źródłowy adres IP będzie pochodził z przestrzeni adresowej podsieci bramy aplikacji.
Operacje sondy
Brama uruchamia sondy natychmiast po skonfigurowaniu reguły przez skojarzenie jej z ustawieniem zaplecza i pulą zaplecza (i odbiornikiem, oczywiście). Ilustracja pokazuje, że brama niezależnie bada wszystkie serwery puli zapleczowych. Przychodzące żądania, które zaczynają napływać, są wysyłane tylko do serwerów sprawnych. Serwer zaplecza jest domyślnie oznaczony jako w złej kondycji do momentu odebrania pomyślnej odpowiedzi sondy.
Wymagane sondy są określane na podstawie unikatowej kombinacji serwera zaplecza i ustawień serwera zaplecza. Rozważmy na przykład bramę z jedną pulą zaplecza z dwoma serwerami i dwoma ustawieniami zaplecza, z których każda ma różne numery portów. Gdy te odrębne ustawienia zaplecza są skojarzone z tą samą pulą zaplecza przy użyciu odpowiednich reguł, brama tworzy sondy dla każdego serwera oraz dla każdej kombinacji ustawień zaplecza. Można to wyświetlić na stronie Kondycja zaplecza.
Ponadto wszystkie wystąpienia bramy aplikacji sondują serwery zaplecza niezależnie od siebie.
Interwały sond
Ta sama konfiguracja sondy ma zastosowanie do każdego wystąpienia usługi Application Gateway. Jeśli na przykład brama aplikacji ma dwa wystąpienia, a interwał sondy jest ustawiony na 20 sekund, oba wystąpienia będą wysyłać sondę kondycji co 20 sekund.
Gdy sonda wykryje niepowodzenie odpowiedzi, licznik "niezdrowy próg" zostaje uruchomiony i oznacza serwer jako w złej kondycji, jeśli liczba kolejnych niepowodzeń odpowiada skonfigurowanemu progowi. W związku z tym jeśli ustawisz próg niezdrowości jako 2, kolejna próba diagnostyczna najpierw wykryje ten błąd. Następnie brama aplikacji oznaczy serwer jako w złej kondycji po 2 kolejnych nieudanych sondach [Pierwsze wykrywanie 20 sekund + (2 kolejne nieudane sondy * 20 sekund)].
Uwaga
Raport stanu zaplecza jest aktualizowany na podstawie częstotliwości odświeżania odpowiedniej sondy i nie zależy od żądania użytkownika.
Domyślna sonda kondycji
Brama aplikacji automatycznie konfiguruje domyślną sondę stanu zdrowia, gdy nie konfigurujesz żadnej niestandardowej konfiguracji sondy. Monitorowanie działa poprzez wysłanie żądania HTTP GET do adresów IP lub nazw FQDN skonfigurowanych w puli zaplecza. W przypadku domyślnych sond, jeśli ustawienia http zaplecza są skonfigurowane dla protokołu HTTPS, sonda używa protokołu HTTPS do testowania kondycji serwerów zaplecza.
Na przykład: Konfigurujesz swoją bramę aplikacji, by korzystać z serwerów zaplecza A, B i C do odbierania ruchu sieciowego HTTP na porcie 80. Domyślne monitorowanie kondycji testuje trzy serwery co 30 sekund dla dobrej kondycji odpowiedzi HTTP z 30-sekundowym limitem czasu dla każdego żądania. Odpowiedź HTTP jest poprawna, jeśli ma kod stanu z zakresu od 200 do 399. W takim przypadku nagłówek hosta HTTP GET dla sondy kondycji wygląda następująco: http://127.0.0.1/. Zobacz również kody odpowiedzi HTTP w usłudze Application Gateway.
Jeśli domyślne sprawdzanie sondy zakończy się niepowodzeniem dla serwera A, brama aplikacji zatrzymuje przekazywanie żądań do tego serwera. Domyślna sonda nadal sprawdza serwer A co 30 sekund. Gdy serwer A odpowiada pomyślnie na jedno żądanie z domyślnej sondy kondycji, usługa Application Gateway ponownie uruchamia przekazywanie żądań do serwera.
Domyślne ustawienia sondy kondycji
| Właściwość sondy | Wartość | Opis |
|---|---|---|
| Adres URL sondy | <protocol>://127.0.0.1:<port>/ | Protokół i port są dziedziczone z ustawień http zaplecza, z którymi jest skojarzona sonda |
| Interwał | 30 | Czas w sekundach do odczekania przed wysłaniem kolejnej sondy sprawdzającej kondycję. |
| Przerwa | 30 | Czas oczekiwania, wyrażony w sekundach, jaki brama aplikacji przeznacza na odpowiedź sondy, zanim oznaczy sondę jako niezdrową. Jeśli sonda zwróci informację, że jest sprawna, odpowiednie zaplecze jest natychmiast oznaczone jako sprawne. |
| Niezdrowy próg | 3 | Określa, ile sond ma być wysyłanych w przypadku awarii regularnej sondy monitorującej stan. W wersji 1 SKU te dodatkowe sondy kondycji są wysyłane w krótkim odstępie czasu, aby szybko określić kondycję zaplecza, bez oczekiwania na standardowy interwał sondy. W przypadku jednostki SKU w wersji 2 sondy kondycji czekają przez interwał. Serwer zaplecza jest oznaczony jako niedziałający, gdy liczba kolejnych nieudanych prób osiągnie próg niezdrowej kondycji. |
Sonda domyślna sprawdza tylko <protokół>://127.0.0.1:<port> w celu określenia stanu zdrowia. Jeśli musisz skonfigurować sondę kondycji, aby przejść do niestandardowego adresu URL lub zmodyfikować inne ustawienia, musisz użyć sond niestandardowych. Aby uzyskać więcej informacji na temat sond HTTPS, zobacz Overview of TLS termination and end to end TLS with Application Gateway (Omówienie kończenia żądań protokołu TLS i end to end TLS with Application Gateway).
Niestandardowa sonda kondycji
Niestandardowe sondy umożliwiają bardziej szczegółową kontrolę nad monitorowaniem kondycji. W przypadku używania sond niestandardowych można skonfigurować niestandardową nazwę hosta, ścieżkę adresu URL, interwał sondy oraz liczbę nieudanych odpowiedzi akceptowanych przed oznaczeniem instancji puli zaplecza jako niesprawnej itp.
Niestandardowe ustawienia sondy kondycji
Poniższa tabela zawiera definicje właściwości niestandardowej sondy kondycji.
| Właściwość sondy | Opis |
|---|---|
| Nazwa/nazwisko | Nazwa sondy. Ta nazwa służy do identyfikowania i odwoływania się do sondy w ustawieniach zaplecza HTTP. |
| Protokół | Protokół używany do wysyłania sondy. To musi być zgodne z protokołem zdefiniowanym w ustawieniach HTTP zaplecza, z którymi jest powiązane. |
| Gospodarz | Nazwa hosta do wysłania sondy. W wersji SKU v1 ta wartość jest używana tylko w nagłówku hosta dla żądania sondy. W wersji SKU v2 jest używana zarówno jako nagłówek hosta, jak i SNI |
| Ścieżka | Względna ścieżka sondy. Prawidłowa ścieżka zaczyna się od "/" |
| Port | Jeśli jest zdefiniowana, jest to używane jako port docelowy. W przeciwnym razie używa tego samego portu co ustawienia PROTOKOŁU HTTP, z którymi jest skojarzony. Ta właściwość jest dostępna tylko w SKU wersji 2 |
| Interwał | Interwał sondy w sekundach. Ta wartość to przedział czasu między dwoma kolejnymi sondami |
| Przerwa | Limit czasu wyczekiwania sondy w sekundach. Jeśli prawidłowa odpowiedź nie zostanie odebrana w tym przedziale czasu, sonda zostanie oznaczona jako nieudana |
| Niezdrowy próg | Liczba ponownych prób sondy. Serwer zaplecza jest oznaczony jako wyłączony po osiągnięciu progu złej kondycji przez kolejną liczbę niepowodzeń sondy |
Dopasowywanie sondy
Domyślnie odpowiedź HTTP(S) z kodem stanu w zakresie od 200 do 399 jest uważana za prawidłową. Niestandardowe sondy kondycji dodatkowo obsługują dwa kryteria dopasowania. Kryteria zgodności mogą być używane do opcjonalnego modyfikowania domyślnej interpretacji tego, co stanowi zdrową odpowiedź.
Kryteria dopasowania to:
- Dopasowanie kodu stanu odpowiedzi HTTP — kryterium dopasowania sondy do akceptowania kodu odpowiedzi HTTP lub zakresów kodu odpowiedzi http. Obsługiwane są poszczególne kody stanu odpowiedzi rozdzielane przecinkami lub zakres kodu stanu.
- Dopasowanie treści odpowiedzi HTTP — kryterium dopasowania sondy, które analizuje treść odpowiedzi HTTP i pasuje do określonego ciągu użytkownika. Dopasowanie wyszukuje jedynie obecność ciągu określonego przez użytkownika w treści odpowiedzi i nie jest pełnym dopasowaniem do wyrażenia regularnego. Określone dopasowanie musi zawierać 4090 znaków lub mniej.
Kryteria dopasowania można określić przy użyciu polecenia New-AzApplicationGatewayProbeHealthResponseMatch cmdlet.
Na przykład:
$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399
$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"
Kryteria dopasowania można dołączyć do konfiguracji sondy przy użyciu -Match operatora w programie PowerShell.
Niektóre przypadki użycia sond niestandardowych
- Jeśli serwer zaplecza zezwala na dostęp tylko do uwierzytelnionych użytkowników, sondy bramy aplikacji otrzymają kod odpowiedzi 403 zamiast 200. Ponieważ klienci (użytkownicy) są zobowiązani do uwierzytelniania się dla ruchu na żywo, możesz skonfigurować ruch sondy tak, aby akceptował 403 jako oczekiwaną odpowiedź.
- Gdy serwer zaplecza ma zainstalowany certyfikat wieloznaczny (*.contoso.com) obsługujący różne subdomeny, można użyć sondy niestandardowej z określoną nazwą hosta (wymaganą przez SNI), która jest akceptowana w celu ustanowienia pomyślnej sondy TLS i raportowania tego serwera jako będącego w dobrej kondycji. W przypadku ustawienia "przesłoń nazwę hosta" w ustawieniach zaplecza na NIE, różne przychodzące nazwy hostów (poddomeny) zostaną przekazane do zaplecza w niezmienionej formie.
Zagadnienia dotyczące sieciowej grupy zabezpieczeń
Szczegółowa kontrola nad podsiecią usługi Application Gateway za pośrednictwem reguł sieciowej grupy zabezpieczeń jest możliwa w publicznej wersji zapoznawczej. Więcej informacji można znaleźć tutaj.
W przypadku bieżących funkcji istnieją pewne ograniczenia:
Musisz zezwolić na przychodzący ruch internetowy na portach TCP 65503-65534 dla jednostki SKU Application Gateway w wersji 1 oraz na portach TCP 65200-65535 dla jednostki SKU w wersji 2, gdzie docelowa podsieć to Any, a źródło to oznaczenie usługi GatewayManager. Ten zakres portów jest wymagany do komunikacji infrastruktury platformy Azure.
Ponadto nie można zablokować wychodzącej łączności internetowej, a ruch przychodzący pochodzący z tagu AzureLoadBalancer musi być dozwolony.
Aby uzyskać więcej informacji, zobacz Omówienie konfiguracji usługi Application Gateway.
Następne kroki
Po zapoznaniu się z monitorowaniem kondycji w usłudze Application Gateway, można skonfigurować niestandardową sondę kondycji w portalu Azure lub niestandardową sondę kondycji przy użyciu programu PowerShell i modelu wdrażania Azure Resource Manager.