Sondy kondycji usługi 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 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:
| SKU | Protokół sondy | Zachowanie sondy w dół |
|---|---|---|
| Standardowa | TCP, HTTP, HTTPS | Wszystkie sondy w dół, wszystkie przepływy TCP są kontynuowane. |
| Podstawowy | TCP, HTTP | 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 otwartego 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 w stanie 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 w stanie 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 w witrynie Azure Portal, ale można jawnie ustawić 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 przekazaniu 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 limit czasu, sonda kondycji przekracza limit czasu i kończy się niepowodzeniem, jeśli w okresie przekroczenia limitu czasu nie otrzymano odpowiedzi. 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.
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 sondy używały tego samego portu.
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.
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.
W przeciwieństwie do reguł równoważenia obciążenia reguły NAT dla ruchu przychodzącego nie wymagają dołączonej sondy kondycji.
Nie zaleca się blokowania adresu IP lub portu sondy kondycji usługi Azure Load Balancer przy użyciu reguł sieciowej grupy zabezpieczeń. Jest to nieobsługiwany scenariusz i może spowodować opóźnienie działania reguł sieciowej grupy zabezpieczeń, co powoduje niedokładne reprezentowanie dostępności wystąpień zaplecza przez sondy kondycji.
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 Azure Load Balancer oznaczyła wystąpienie, musisz zezwolić na adres IP 168.63.129.16 we wszystkich sieciowych grupach zabezpieczeń platformy Azure i lokalnych zasadach zapory. Tag AzureLoadBalancer usługi 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 znajdziesz 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 -down- 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 (fe80::1234:5678:9abc) jako źródła. W przypadku usługi Azure Load Balancer z dwoma stosami należy skonfigurować sieciową grupę zabezpieczeń dla sondy kondycji IPv6 do działania.
Ograniczenia
Sondy HTTPS nie obsługują wzajemnego uwierzytelniania przy użyciu certyfikatu klienta.
Sondy HTTP nie obsługują używania nazw hostów dla zapleczy sond.
Włączenie sygnatur czasowych protokołu TCP może spowodować ograniczenie przepustowości lub inne problemy z wydajnością, co może spowodować przekroczenie limitu czasu sond kondycji.
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.