Sondy kondycji usługi Azure Load Balancer

Artykuł
10/26/2023

Sonda kondycji usługi Azure Load Balancer to funkcja, która wykrywa stan kondycji wystąpień aplikacji. Wysyła ona żą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 kondycji i odpowiedzi sondy określa, które wystąpienia puli zaplecza odbierają nowe połączenia. Użyj sond kondycji, aby wykryć błąd 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 kondycji zakończy się niepowodzeniem, moduł równoważenia obciążenia przestanie wysyłać nowe połączenia do odpowiedniego wystąpienia w złej kondycji. Łączność wychodząca nie ma wpływu tylko na ruch przychodzący.

Protokoły sondy

Sondy kondycji obsługują wiele protokołów. Dostępność określonego protokołu sondy kondycji zależy od jednostki SKU usługi Load Balancer. 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:

	Standardowy SKU	Podstawowy SKU
Protokół sondy	TCP, HTTP, HTTPS	TCP, HTTP
Zachowanie sondy w dół	Wszystkie sondy w dół, wszystkie przepływy TCP są kontynuowane.	Wszystkie sondy w dół, wszystkie przepływy TCP wygasają.

Właściwości sondy

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

Nazwa właściwości sondy kondycji	Szczegóły
Nazwisko	Nazwa sondy kondycji. Jest to nazwa, którą można zdefiniować dla sondy kondycji
Protokół	Protokół sondy kondycji. Jest to typ protokołu, który ma być używany przez sondę kondycji. Opcje to: TCP, HTTP, HTTPS
Port	Port sondy kondycji. Port docelowy, który ma być używany przez sondę kondycji podczas nawiązywania połączenia z maszyną wirtualną w celu sprawdzenia jego kondycji
Interwał (w sekundach)	Interwał sondy kondycji. Czas (w sekundach) między różnymi sondami w dwóch kolejnych próbach kontroli kondycji maszyny wirtualnej
Używana przez	Lista reguł modułu równoważenia obciążenia przy użyciu tej konkretnej sondy kondycji. Aby była skuteczna, należy mieć co najmniej jedną regułę używającą sondy kondycji

Konfiguracja sondy

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

Konfiguracja sondy kondycji	Szczegóły
Protokół	Protokół sondy kondycji. Jest to typ protokołu, który ma być używany przez sondę kondycji. Dostępne opcje to: TCP, HTTP, HTTPS
Port	Port sondy kondycji. Port docelowy, który ma być używany przez sondę kondycji podczas nawiązywania połączenia z maszyną wirtualną w celu sprawdzenia stanu kondycji maszyny wirtualnej. Upewnij się, że maszyna wirtualna nasłuchuje również na tym porcie (czyli jest otwarty port).
Interwał	Interwał sondy kondycji. Czas (w sekundach) między kolejnymi próbami sprawdzania kondycji maszyny wirtualnej

Protokół sondy

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

Scenariusz	Sonda TCP	Sonda HTTP/HTTPS
Omówienie	Sondy TCP inicjują połączenie, wykonując trzykierunkowe uzgadnianie protokołu TCP ze zdefiniowanym portem. Sondy TCP przerywają połączenie z czterokierunkowym uściskiem dłoni TCP.	Protokół HTTP i HTTPS wystawiają żądania HTTP GET z określoną ścieżką. Obie te sondy obsługują ścieżki względne dla żądania HTTP GET. Sondy HTTPS są takie same jak sondy HTTP z dodatkiem protokołu Transport Layer Security (TLS). Sondy HTTP/HTTPS mogą być przydatne do zaimplementowania własnej logiki w celu usunięcia wystąpień z modułu równoważenia obciążenia, jeśli port sondy jest również odbiornikiem usługi.
Zachowanie niepowodzenia sondy	Sonda TCP kończy się niepowodzeniem, gdy: 1. Odbiornik TCP w wystąpieniu nie odpowiada w ogóle w okresie przekroczenia limitu czasu. Sonda jest oznaczona w dół na podstawie liczby żądań sondy limitu czasu, które zostały skonfigurowane do przechodzenia bez odpowiedzi przed oznaczeniem sondy w dół. 2. Sonda odbiera resetowanie protokołu TCP z wystąpienia.	Sonda HTTP/HTTPS kończy się niepowodzeniem, gdy: 1. Punkt końcowy sondy zwraca kod odpowiedzi HTTP inny niż 200 (na przykład 403, 404 lub 500). 2. Punkt końcowy sondy w ogóle nie odpowiada w ciągu minimalnego interwału sondy i 30-sekundowego limitu czasu. Wiele żądań sondy może przejść bez odpowiedzi, zanim sonda zostanie oznaczona jako nie uruchomiona i do momentu osiągnięcia sumy wszystkich interwałów przekroczenia limitu czasu. 3. Punkt końcowy sondy zamyka połączenie za pośrednictwem resetowania protokołu TCP.
Zachowanie sondy	Sondy kondycji TCP są uznawane za w dobrej kondycji i oznaczają punkt końcowy zaplecza jako w dobrej kondycji, gdy: 1. Sonda kondycji jest pomyślna raz po uruchomieniu maszyny wirtualnej. 2. Każdy punkt końcowy zaplecza, który osiągnął stan dobrej kondycji, kwalifikuje się do odbierania nowych przepływów.	Sonda kondycji jest oznaczona, gdy wystąpienie odpowiada stanem HTTP 200 w okresie przekroczenia limitu czasu. Sondy kondycji HTTP/HTTPS są uznawane za w dobrej kondycji i oznaczają punkt końcowy zaplecza jako w dobrej kondycji, gdy: 1. Sonda kondycji jest pomyślna raz po uruchomieniu maszyny wirtualnej. 2. Każdy punkt końcowy zaplecza, który osiągnął stan dobrej kondycji, kwalifikuje się do odbierania nowych przepływów.

Uwaga

Sonda HTTPS wymaga użycia certyfikatów opartych na minimalnych skrótach podpisów SHA256 w całym łańcuchu.

Zachowanie sondy w dół

Scenariusz	Połączenia TCP	Datagramy UDP
Sondy pojedynczego wystąpienia w dół	Nowe połączenia TCP kończą się powodzeniem, aby zachować punkt końcowy zaplecza w dobrej kondycji. Nawiązane połączenia TCP z tym punktem końcowym zaplecza będą kontynuowane.	Istniejące przepływy UDP przechodzą do innego wystąpienia w dobrej kondycji w puli zaplecza.
Sonda wszystkich wystąpień w dół	Do puli zaplecza nie są wysyłane żadne nowe przepływy. usługa Load Balancer w warstwie Standardowa umożliwia kontynuowanie ustanowić przepływy TCP, biorąc pod uwagę, że pula zaplecza ma więcej niż jedno wystąpienie zaplecza. Podstawowy moduł równoważenia obciążenia kończy wszystkie istniejące przepływy TCP do puli zaplecza.	Wszystkie istniejące przepływy UDP kończą się.

Interwał sondy i limit czasu

Wartość interwału określa, jak często sonda kondycji sprawdza odpowiedź z wystąpień puli zaplecza. Jeśli sonda kondycji zakończy się niepowodzeniem, wystąpienia puli zaplecza zostaną natychmiast oznaczone jako w złej kondycji. Jeśli sonda kondycji powiedzie się w następnej dobrej kondycji sondy, usługa Azure Load Balancer oznaczy wystąpienia puli zaplecza jako w dobrej kondycji. Sonda kondycji próbuje domyślnie sprawdzić skonfigurowany port sondy kondycji co 5 sekund, ale może być jawnie ustawiona na inną wartość.

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/A (sondy kończą się niepowodzeniem po upływie skonfigurowanego interwału 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 okres limitu czasu, sonda kondycji przekroczy limit czasu i zakończy się niepowodzeniem, jeśli żadna odpowiedź nie zostanie odebrana w okresie przekroczenia limitu czasu. 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.

Wskazówki projektowe

Podczas projektowania modelu kondycji aplikacji sonduj port w punkcie końcowym zaplecza, 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 były to ten sam port.
Aplikacja może być przydatna do generowania odpowiedzi sondy kondycji i sygnalizowania modułu równoważenia obciążenia, czy wystąpienie powinno odbierać 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ł sondy w dół zawsze umożliwia kontynuowanie przepływów TCP do czasu bezczynności lub zamknięcia połączenia w usługa Load Balancer w warstwie Standardowa.
W przypadku aplikacji o zrównoważonym obciążeniu UDP wygeneruj niestandardowy sygnał sondy kondycji z punktu końcowego zaplecza. Użyj protokołu TCP, HTTP lub HTTPS dla sondy kondycji zgodnej z odpowiednim odbiornikiem.
Reguła równoważenia obciążenia portów wysokiej dostępności z usługa Load Balancer w warstwie Standardowa. Wszystkie porty są ze zrównoważonym obciążeniem, a pojedyncza odpowiedź sondy kondycji musi odzwierciedlać stan całego wystąpienia.
Nie tłumacz ani nie proxy sondy kondycji za pośrednictwem wystąpienia, które odbiera sondę kondycji do innego wystąpienia w sieci wirtualnej. Ta konfiguracja może prowadzić do niepowodzeń w danym scenariuszu. Na przykład: zestaw urządzeń innych firm jest wdrażany w puli zaplecza modułu równoważenia obciążenia w celu zapewnienia skalowania i nadmiarowości dla urządzeń. Sonda kondycji jest skonfigurowana do sondowania portu, który jest serwerem proxy urządzenia innej firmy lub przekłada się na inne maszyny wirtualne za urządzeniem. Jeśli sondujesz ten sam port używany do tłumaczenia żądań lub serwera proxy do innych maszyn wirtualnych za urządzeniem, każda odpowiedź sondy z jednej maszyny wirtualnej oznacza urządzenie w dół. Ta konfiguracja może prowadzić do awarii kaskadowej aplikacji. Wyzwalacz może być sporadyczne niepowodzenie sondy, które powoduje, że moduł równoważenia obciążenia oznacza wystąpienie urządzenia. Ta akcja może wyłączyć aplikację. Sonduj kondycję samego urządzenia. Wybór sondy w celu określenia sygnału kondycji jest ważnym czynnikiem dla scenariuszy wirtualnych urządzeń sieciowych (WUS). W takich scenariuszach należy skontaktować się z dostawcą aplikacji, aby uzyskać odpowiedni sygnał kondycji.
Jeśli masz wiele interfejsów skonfigurowanych na maszynie wirtualnej, upewnij się, że odpowiadasz na sondę w interfejsie, na którym został on odebrany. Może być konieczne przetłumaczenie tego adresu sieciowego na maszynie wirtualnej na podstawie interfejsu.
Pamiętaj, że definicja sondy nie jest obowiązkowa ani sprawdzana podczas korzystania z programu Azure PowerShell, interfejsu wiersza polecenia platformy Azure, szablonów lub interfejsu API. Testy poprawności sondy są wykonywane tylko w przypadku korzystania z witryny Azure Portal.
Jeśli sonda kondycji zmieni się, moduł równoważenia obciążenia czeka dłużej, zanim przywróci punkt końcowy zaplecza w stanie dobrej kondycji. Ten dodatkowy czas oczekiwania chroni użytkownika i infrastrukturę i jest celowymi zasadami.
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 zostanie ono sondowane, 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 kondycji i może spowodować niepowodzenie scenariusza.
Aby przetestować błąd sondy kondycji lub oznaczyć pojedyncze wystąpienie, użyj sieciowej grupy zabezpieczeń, aby jawnie zablokować sondę kondycji. Utwórz regułę sieciowej grupy zabezpieczeń, aby zablokować port docelowy lub źródłowy adres IP w celu symulowania awarii sondy.

Monitorowanie

usługa Load Balancer w warstwie Standardowa uwidacznia stan sondy kondycji punktu końcowego i punktu końcowego zaplecza za pośrednictwem usługi Azure Monitor. Inne usługi platformy Azure lub aplikacje partnerskie mogą korzystać z tych metryk. Dzienniki usługi Azure Monitor nie są obsługiwane w przypadku usługi Load Balancer w warstwie Podstawowa.

Źródłowy adres IP sondy

Aby sonda kondycji usługi Load Balancer oznaczyła wystąpienie, należy zezwolić na adres IP 168.63.129.16 w dowolnych sieciowych grupach zabezpieczeń platformy Azure i lokalnych zasadach zapory. Tag usługi AzureLoadBalancer identyfikuje ten źródłowy adres IP w sieciowych grupach zabezpieczeń i domyślnie zezwala na ruch sondy kondycji. Więcej informacji na temat tego adresu IP można znaleźć tutaj.

Jeśli nie zezwolisz na źródłowy adres IP sondy w zasadach zapory, sonda kondycji zakończy się niepowodzeniem, ponieważ nie może nawiązać połączenia z wystąpieniem. Z kolei usługa Azure Load Balancer oznacza wystąpienie jako wyłączone z powodu błędu 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 lokalnego linku jako źródła.

Ograniczenia

Sondy HTTPS nie obsługują wzajemnego uwierzytelniania przy użyciu certyfikatu klienta.
Należy założyć, że sondy kondycji kończą się niepowodzeniem po włączeniu sygnatur czasowych protokołu TCP.
Sonda kondycji podstawowego modułu równoważenia obciążenia jednostki SKU nie jest obsługiwana w zestawie 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.