Omówienie sond kondycji usługi Application Gateway
aplikacja systemu Azure Gateway monitoruje kondycję wszystkich serwerów w puli zaplecza i automatycznie zatrzymuje wysyłanie ruchu do dowolnego serwera, który uważa za w złej kondycji. 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ć sond niestandardowych, aby skonfigurować je w sposób.
Zachowanie 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 frontonu 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 sonduje wszystkie serwery puli zaplecza. Przychodzące żądania, które zaczynają odbierać, są wysyłane tylko do serwerów w dobrej kondycji. 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 ustawień serwera zaplecza i 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 i kombinację ustawienia zaplecza. Można to wyświetlić na stronie Kondycja zaplecza.
Ponadto wszystkie wystąpienia bramy aplikacji sonduje 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 "Próg złej kondycji" zostanie wyłączony i oznaczy serwer jako w złej kondycji, jeśli kolejna liczba niepomyślnie pasuje do skonfigurowanego progu. W związku z tym, jeśli ustawisz ten próg złej kondycji jako 2, kolejna sonda 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 kondycji zaplecza jest aktualizowany na podstawie interwału odświeżania odpowiedniego sondy i nie zależy od żądania użytkownika.
Domyślna sonda kondycji
Brama aplikacji automatycznie konfiguruje domyślną sondę kondycji, gdy nie konfigurujesz żadnej niestandardowej konfiguracji sondy. Zachowanie monitorowania działa przez wysłanie żądania HTTP GET do adresów IP lub nazwy FQDN skonfigurowanej 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: brama aplikacji umożliwia używanie 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 w dobrej kondycji ma kod stanu z zakresu od 200 do 399. W takim przypadku żądanie 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 oczekiwania w sekundach przed wysłaniem następnej sondy kondycji. |
| Limit czasu | 30 | Czas w sekundach oczekiwania bramy aplikacji na odpowiedź sondy przed oznaczeniem sondy jako w złej kondycji. Jeśli sonda zwróci wartość w dobrej kondycji, odpowiednie zaplecze jest natychmiast oznaczone jako w dobrej kondycji. |
| Próg złej kondycji | 3 | Określa, ile sond ma być wysyłanych w przypadku awarii regularnej sondy kondycji. W wersji 1 jednostka SKU te dodatkowe sondy kondycji są wysyłane w krótkim odstępie czasu, aby szybko określić kondycję zaplecza i nie czekać na interwał sondy. W przypadku jednostki SKU w wersji 2 sondy kondycji czekają interwał. Serwer zaplecza jest oznaczony jako wyłączony po osiągnięciu progu złej kondycji przez kolejną liczbę niepowodzeń sondy. |
Sonda domyślna sprawdza tylko <protokół>://127.0.0.1:<port> w celu określenia stanu kondycji. 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 i liczbę nieudanych odpowiedzi do zaakceptowania przed oznaczeniem wystąpienia puli zaplecza jako w złej kondycji 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 http zaplecza. |
| Protokół | Protokół używany do wysyłania sondy. Musi to być zgodne z protokołem zdefiniowanym w ustawieniach protokołu HTTP zaplecza, które są skojarzone z |
| Gospodarz | Nazwa hosta do wysłania sondy za pomocą polecenia . W wersji 1 jednostka SKU ta wartość jest używana tylko dla nagłówka hosta żądania sondy. W wersji 2 jednostka SKU 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 jednostce SKU w wersji 2 |
| Interwał | Interwał sondy w sekundach. Ta wartość to przedział czasu między dwoma kolejnymi sondami |
| Limit czasu | Limit czasu sondy w sekundach. Jeśli prawidłowa odpowiedź nie zostanie odebrana w tym przedziale czasu, sonda zostanie oznaczona jako nieudana |
| Próg złej kondycji | 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 z kodem stanu z zakresu od 200 do 399 jest uważana za w dobrej kondycji. Niestandardowe sondy kondycji dodatkowo obsługują dwa kryteria dopasowania. Kryteria dopasowania mogą służyć do opcjonalnego modyfikowania domyślnej interpretacji tego, co sprawia, że odpowiedź w dobrej kondycji.
Poniżej przedstawiono kryteria dopasowania:
- 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 tylko obecność określonego ciągu użytkownika w treści odpowiedzi i nie jest pełnym dopasowaniem wyrażenia regularnego. Określone dopasowanie musi zawierać 4090 znaków lub mniej.
Kryteria dopasowania można określić przy użyciu New-AzApplicationGatewayProbeHealthResponseMatch polecenia 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 dla 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 domeny podrzędne, można użyć sondy niestandardowej z określoną nazwą hosta (wymaganą dla sieci SNI), która jest akceptowana w celu ustanowienia pomyślnej sondy TLS i raportowania tego serwera jako dobrej kondycji. W przypadku ustawienia "przesłonięć nazwę hosta" w ustawieniu zaplecza na NIE, różne przychodzące nazwy hostów (poddomeny) zostaną przekazane jako do zaplecza.
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 usługi Application Gateway w wersji 1, a porty TCP 65200-65535 dla jednostki SKU w wersji 2 z docelową podsiecią jako dowolną i źródło jako tag 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 usługi Application Gateway można skonfigurować niestandardową sondę kondycji w witrynie Azure Portal lub niestandardową sondę kondycji przy użyciu programu PowerShell i modelu wdrażania usługi Azure Resource Manager.