Sondy kondycji Azure Load Balancer

Sonda kondycji usługi Azure Load Balancer to funkcja, która wykrywa stan kondycji wystąpień aplikacji. Wysyła żądanie do wystąpień, aby sprawdzić, czy są one dostępne i odpowiadają na żądania. Sondę kondycji można skonfigurować do używania różnych protokołów, takich jak TCP, HTTP lub HTTPS. Jest to ważna funkcja, ponieważ pomaga wykrywać błędy aplikacji, zarządzać obciążeniem i planować przestoje.

Reguły usługi Azure Load Balancer wymagają sondy kondycji w celu wykrycia stanu punktu końcowego. Konfiguracja sondy zdrowia i odpowiedzi sondy określa, które instancje w puli zaplecza otrzymują nowe połączenia. Użyj sond zdrowotnych, aby wykryć awarię aplikacji. Wygeneruj niestandardową odpowiedź na sondę kondycji. Użyj sondy kondycji do sterowania przepływem, aby zarządzać obciążeniem lub zaplanowanym przestojem. Gdy sonda stanu zdrowia zakończy się niepowodzeniem, moduł równoważenia obciążenia przestanie wysyłać nowe połączenia do odpowiedniej niesprawnej instancji. Łączność wychodząca nie jest dotknięta, tylko przychodząca.

Protokoły sondy

Sondy monitorujące kondycję obsługują wiele protokołów. Dostępność określonego protokołu sondy kondycji zależy od SKU Load Balancera. Ponadto zachowanie usługi różni się w zależności od jednostki SKU modułu równoważenia obciążenia, jak pokazano w poniższej tabeli:

Właściwości sondy

Sondy kondycji mają następujące właściwości:

Konfiguracja sondy

Konfiguracja sondy kondycji składa się z następujących elementów:

Protokół sondy

Protokół używany przez sondę kondycji można skonfigurować do jednej z następujących opcji: TCP, HTTP, HTTPS.

Zachowanie sondy podczas ruchu w dół

Interwał sondy i limit czasu

Wartość interwału określa, jak często sonda kontrolna kondycji przeprowadza sprawdzanie odpowiedzi z wystąpień puli zaplecza. Jeśli test kondycji nie powiedzie się, moduł równoważenia obciążenia natychmiast oznaczy instancje w puli zaplecza jako niezdrowe. Jeśli sonda kondycji zakończy się pomyślnie podczas następnego sprawdzenia, Azure Load Balancer oznaczy instancje w puli zaplecza jako będące w dobrej kondycji. Sonda zdrowia domyślnie próbuje sprawdzać skonfigurowany port sondy co 5 sekund w portalu Azure, ale możesz ustawić ją na inną wartość. Gdy wdrażasz przez szablony ARM, REST API, Azure CLI lub PowerShell, domyślny odstęp wynosi 15 sekund (minimum 5 sekund).

Aby upewnić się, że odebrano terminową odpowiedź, sondy kondycji HTTP/S mają wbudowane limity czasu. Poniżej przedstawiono czasy przekroczenia limitu czasu dla sond TCP i HTTP/S:

• Czas trwania limitu czasu sondy TCP: N/D (sondy zakończą się niepowodzeniem po upływie skonfigurowanego interwału czasu sondy i wysłaniu następnej sondy)
• Czas trwania sondy HTTP/S: 30 sekund

W przypadku sond HTTP/S, jeśli skonfigurowany interwał jest dłuższy niż powyższy limit czasu, sonda kontrolna zdrowia przekracza limit czasu i kończy się niepowodzeniem, jeśli nie otrzymano odpowiedzi w tym czasie. Jeśli na przykład sonda kondycji HTTP jest skonfigurowana z interwałem sondy wynoszącym 120 sekund (co 2 minuty), a żadna odpowiedź sondy nie zostanie odebrana w ciągu pierwszych 30 sekund, sonda osiągnie limit czasu i zakończy się niepowodzeniem. Jeśli skonfigurowany interwał jest krótszy niż powyższy okres limitu czasu, sonda kondycji zakończy się niepowodzeniem, jeśli żadna odpowiedź nie zostanie odebrana przed zakończeniem skonfigurowanego okresu interwału, a następna sonda zostanie wysłana natychmiast.

Próg sondowania

Wartość progowa sondy to liczba kolejnych pomyślnych lub nieudanych prób sondy kondycji, wymagana do tego, aby sonda oznaczyła instancję zaplecza odpowiednio jako zdrową lub niezdrową.

W przypadku sond TCP, jeśli próg sondy jest ustawiony na 2, sonda będzie musiała otrzymać 2 kolejne odpowiedzi, zanim instancja zaplecza zacznie odbierać ruch. Podobnie, gdy wystąpienie zaplecza zostanie uznane za w dobrej kondycji, 2 kolejne błędy lub przekroczenia limitu czasu są wymagane, aby wystąpienie zostało uznane za w złej kondycji i przestało odbierać nowy ruch.

W przypadku sond HTTP jednoznaczne odpowiedzi natychmiast oznaczą sondę jako działającą lub niedziałającą w przypadku odpowiedzi 200 oraz innych niż 200, a także skutecznie zresetują wartość progową. Oznacza to, że wartość progowa ma zastosowanie tylko do sond HTTP, jeśli sonda przekroczy limit czasu z powodu braku odpowiedzi.

Wskazówki projektowe

• Podczas projektowania modelu kondycji aplikacji sprawdzaj port w tylnym punkcie końcowym, który odzwierciedla kondycję wystąpienia i usługi aplikacji. Port aplikacji i port sondy nie muszą być takie same. W niektórych scenariuszach może być pożądane, aby port sondy był inny niż port używany przez aplikację, ale ogólnie zaleca się, aby sondy używały tego samego portu.

• Może być użyteczne dla Twojej aplikacji generowanie odpowiedzi sondy kondycji i sygnalizowanie modułu równoważenia obciążenia, czy instancja powinna przyjmować nowe połączenia. Możesz manipulować odpowiedzią sondy w celu ograniczenia dostarczania nowych połączeń z wystąpieniem przez niepowodzenie sondy kondycji. Możesz przygotować się do konserwacji aplikacji i zainicjować opróżnianie połączeń z aplikacją. Sygnał końca zawsze umożliwia kontynuowanie przepływów TCP do czasu bezczynności lub zamknięcia połączenia w Standardowym Load Balancerze.

• W przypadku aplikacji z równoważeniem obciążenia UDP wygeneruj niestandardowy sygnał kontrolny kondycji z punktu końcowego zaplecza. Użyj protokołu TCP, HTTP lub HTTPS dla sondy stanu zgodnej z odpowiednim odbiornikiem.

• Reguła równoważenia obciążenia dla portów HA z Standardową usługą Load Balancer. Wszystkie porty są równoważone pod względem obciążenia, a pojedyncza odpowiedź sondy monitorującej kondycję musi odzwierciedlać stan całego wystąpienia.

• Nie przesyłaj ani nie rozprowadzaj sondy stanu przez wystąpienie, które odbiera tę sondę, do innego wystąpienia w twojej sieci wirtualnej. Ta konfiguracja może prowadzić do niepowodzeń w danym scenariuszu. Na przykład: zestaw urządzeń zewnętrznych jest wdrażany w zapleczowej puli urządzenia równoważenia obciążenia w celu zapewnienia skalowania i nadmiarowości dla tych urządzeń. Sonda kondycji jest skonfigurowana do sondowania portu, który jest przekierowywany lub tłumaczony przez urządzenie innej firmy do innych maszyn wirtualnych znajdujących się za urządzeniem. Jeśli sondujesz ten sam port używany do tłumaczenia lub pośredniczenia żądań do innych maszyn wirtualnych za urządzeniem, jakakolwiek odpowiedź sondy z pojedynczej maszyny wirtualnej oznacza, że urządzenie jest uznane za niedostępne. Ta konfiguracja może prowadzić do awarii kaskadowej aplikacji. Wyzwalaczem może być sporadyczne uszkodzenie sondy, które powoduje, że moduł równoważenia obciążenia oznacza instancję urządzenia jako wyłączoną. Ta akcja może wyłączyć aplikację. Sonduj kondycję samego urządzenia. Wybór sondy w celu określenia sygnału stanu zdrowia jest ważnym czynnikiem dla scenariuszy wirtualnych urządzeń sieciowych (NVA). W takich scenariuszach należy skontaktować się z dostawcą aplikacji, aby uzyskać odpowiedni wskaźnik zdrowotny.

• Jeśli masz wiele interfejsów skonfigurowanych na maszynie wirtualnej, upewnij się, że odpowiadasz na sondę na interfejsie, na którym ją otrzymałeś. Może być konieczne przetłumaczenie tego adresu sieciowego na maszynie wirtualnej na podstawie interfejsu.

• Definicja sondy nie jest obowiązkowa ani sprawdzana podczas korzystania z Azure PowerShell, Azure CLI, szablonów lub interfejsu API. Testy poprawności sondy są wykonywane tylko w przypadku korzystania z witryny Azure Portal.

• Jeśli sonda kondycji waha się, moduł równoważenia obciążenia czeka dłużej, zanim przywróci punkt końcowy zaplecza do stanu dobrej kondycji. Ten dodatkowy czas oczekiwania chroni użytkownika i infrastrukturę i jest celową zasadą.

• Upewnij się, że wystąpienia maszyn wirtualnych są uruchomione. Dla każdego uruchomionego wystąpienia w puli zaplecza sonda kondycji sprawdza dostępność. Jeśli wystąpienie zostanie zatrzymane, nie będzie badane, dopóki nie zostanie uruchomione ponownie.

• Nie konfiguruj sieci wirtualnej przy użyciu zakresu adresów IP należących do firmy Microsoft, który zawiera 168.63.129.16. Konfiguracja koliduje z adresem IP sondy diagnostycznej i może spowodować niepowodzenie scenariusza.

• Aby przetestować awarię sondy kondycji lub oznaczyć pojedynczy przypadek, użyj grupy zabezpieczeń sieciowych, aby jawnie zablokować sondę kondycji. Utwórz regułę grupy zabezpieczeń sieciowych, aby zablokować port docelowy lub źródłowy adres IP w celu symulowania awarii sondy.

• W przeciwieństwie do reguł równoważenia obciążenia, reguły NAT dla ruchu przychodzącego nie wymagają dołączonej sondy zdrowotnej.

• Nie zaleca się blokowania adresu IP lub portu kontroli stanu usługi Azure Load Balancer przy użyciu reguł sieciowej grupy zabezpieczeń. Jest to nieobsługiwany scenariusz i może spowodować opóźnienie w działaniu reguł NSG (grupy zabezpieczeń sieci), co skutkuje niedokładnym przedstawianiem dostępności instancji zaplecza przez kontrole kondycji.

Rozwiązywanie problemów z odpowiedziami sond zdrowotnych NVA

Jeśli interfejs sieciowy zarządzania sieciowego urządzenia wirtualnego (NVA) otrzymuje sondy kondycji, ale urządzenie na nie nie odpowiada, użyj artykułu Rozwiązywanie problemów z awariami sond kondycji w usłudze Azure Load Balancer, aby sprawdzić konfigurację sondy, reguły zabezpieczeń sieci i odbiornik. Dla NVA z wieloma interfejsami sieciowymi należy również potwierdzić, że urządzenie odpowiada na interfejsie, który otrzymał sondę, zgodnie z wytycznymi projektowymi.

Aby zlokalizować istniejące dzienniki przepływu w regionie NVA, wykonaj następujące polecenie Azure CLI. Następnie użyj wirtualnych dzienników przepływu sieci lubanalityki ruchu , aby filtrować ruch według prywatnego adresu IP interfejsu sieci zarządzającej oraz skonfigurowanego portu sondy. Dla sondy IPv4 również filtruj według adresu 168.63.129.16IP źródła. Dla sondy IPv6 użyj lokalnego adresu źródłowego łącza podanego w polu Adres IP źródła sondy.

az network watcher flow-log list --location '<region>' --output table

Aby zweryfikować sondę IPv4 na poziomie pakietów, rozpocznij przechwycenie pakietów z filtrem na maszynie wirtualnej NVA. Przechwytywanie pakietów w usłudze Network Watcher wymaga AzureNetworkWatcherExtension na docelowej maszynie wirtualnej. Przed użyciem tego polecenia sprawdź, czy urządzenie obsługuje rozszerzenie i spełnia udokumentowane wymagania dotyczące przechwytywania pakietów. W przypadku urządzenia, które nie może korzystać z rozszerzenia, sprawdź obsługiwaną przez dostawcę procedurę przechwytywania. Zamień wartości zastępcze w następującym poleceniu:

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>"}]'

Jeśli urządzenie udostępnia logi systemu operacyjnego lub zapory, skorzystaj z instrukcji logowania producenta, aby porównać odpowiednie wpisy ze znacznikami czasu przechwytu i szczegółami połączenia. Jeśli przechwytywanie pakietów wykazuje przychodzące sondy, ale brak odpowiedzi, zbadaj konfigurację usługi nasłuchującej, zapory i ścieżki powrotnej, korzystając z listy kontrolnej rozwiązywania problemów z urządzeniem NVA, i w razie potrzeby skontaktuj się również z dostawcą urządzenia.

Monitorowanie

usługa Load Balancer w warstwie Standardowa ujawnia stan sondy kondycji dla każdego punktu końcowego i punktu końcowego zaplecza za pośrednictwem Azure Monitor. Inne usługi platformy Azure lub aplikacje partnerskie mogą korzystać z tych metryk. Logi Azure Monitor nie są obsługiwane dla Basic Load Balancer (wycofany).

Źródłowy adres IP sondy

Aby sonda kondycji usługi Azure Load Balancer oznaczyła wystąpienie, musisz zezwolić na adres IP 168.63.129.16 we wszystkich grupach zabezpieczeń sieci Azure oraz lokalnych zaporach sieciowych. Tag AzureLoadBalancer usługi identyfikuje ten źródłowy adres IP w grupach zabezpieczeń sieci i domyślnie zezwala na ruch sondy kontrolnej. Więcej informacji na temat tego adresu IP znajdziesz tutaj.

Jeśli nie zezwolisz na źródłowy adres IP sondy w zasadach zapory, sonda sprawdzająca stan zakończy się niepowodzeniem, ponieważ nie może dotrzeć do twojego wystąpienia. Z kolei usługa Azure Load Balancer oznacza wystąpienie jako -down- z powodu niepowodzenia sondy kondycji. Ta nieprawidłowa konfiguracja może spowodować niepowodzenie scenariusza aplikacji ze zrównoważonym obciążeniem. Wszystkie sondy kondycji modułu równoważenia obciążenia IPv4 pochodzą z adresu IP 168.63.129.16 jako źródła. Sondy IPv6 używają adresu linku lokalnego (fe80::1234:5678:9abc) jako adresu źródłowego. W przypadku usługi Azure Load Balancer z dwoma stosami należy skonfigurować grupę zabezpieczeń sieci, aby sonda kondycji IPv6 mogła działać.

Ograniczenia

• Sondy HTTPS nie obsługują wzajemnego uwierzytelniania przy użyciu certyfikatu klienta.

• Sondy HTTP nie obsługują używania nazw hostów dla zaplecza sond.

• Włączenie znaczników czasowych TCP może spowodować ograniczenie przepustowości lub inne problemy z wydajnością, co może prowadzić do przekraczania limitu czasu podczas sondowania kondycji.

• Sondy kondycji dla wycofanego modułu Basic Load Balancer nie są obsługiwane w przypadku zestawu skalowania maszyn wirtualnych.

• Sondy HTTP nie obsługują sondowania na następujących portach ze względu na obawy dotyczące zabezpieczeń: 19, 21, 25, 70, 110, 119, 143, 220, 993.

Następne kroki

• Dowiedz się więcej o Standardowym Load Balancerze
• Dowiedz się , jak zarządzać sondami kondycji
• Wprowadzenie do tworzenia publicznego modułu równoważenia obciążenia w usłudze Resource Manager przy użyciu programu PowerShell
• Interfejs API REST dla sond kondycji