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.
Ten artykuł może pomóc w zbadaniu problemów wpływających na dostępność adresu IP frontend i zasobów backend modułu równoważenia obciążenia.
Możesz użyć funkcji stanu zasobów w usłudze Azure Load Balancer, aby określić kondycję twojego modułu równoważenia obciążenia. Analizuje metrykę dostępności ścieżki danych, aby określić, czy są dostępne punkty końcowe dla równoważenia obciążenia, adres IP front-endu i kombinacje portów frontonu z regułami równoważenia obciążenia.
Uwaga
Usługa Load Balancer w warstwie podstawowej nie obsługuje funkcji stanu zasobów.
W poniższej tabeli opisano logikę określania stanu kondycji modułu równoważenia obciążenia.
| Stan kondycji zasobu | Opis |
|---|---|
| Dostępny | Zasób modułu równoważenia obciążenia jest w dobrej kondycji i jest dostępny. |
| Obniżona wydajność | Moduł równoważenia obciążenia ma zdarzenia inicjowane przez platformę lub użytkownika, które wpływają na wydajność. Metryka dostępności ścieżki danych zgłosiła mniej niż 90%, ale więcej niż 25% zdrowia przez co najmniej dwie minuty. Może wystąpić umiarkowany lub poważny spadek wydajności. |
| Niedostępny | Zasób modułu równoważenia obciążenia nie jest w dobrej kondycji. Metryka Dostępność ścieżki danych zgłosiła mniej niż 25% kondycji przez co najmniej dwie minuty. Może wystąpić znaczne obniżenie wydajności lub brak dostępności łączności przychodzącej. Zdarzenia użytkownika lub platformy mogą powodować niedostępność. |
| Nieznane | Stan kondycji zasobu modułu równoważenia obciążenia nie został zaktualizowany ani nie odebrał informacji o dostępności ścieżki danych w ciągu ostatnich 10 minut. Ten stan może być przejściowy lub moduł równoważenia obciążenia może nie obsługiwać funkcji kondycji zasobów. |
Monitorowanie dostępności modułu równoważenia obciążenia
Dwie metryki używane przez usługę Azure Load Balancer do sprawdzania kondycji zasobów to Dostępność ścieżki danych i Stan sondy kondycji. Ważne jest, aby zrozumieć ich znaczenie, aby uzyskać poprawne szczegółowe informacje.
Dostępność ścieżki danych
Polecenie ping TCP generuje metrykę dostępności ścieżki danych co 25 sekund na wszystkich portach węzła frontowego, na których skonfigurowano reguły równoważenia obciążenia. Polecenie ping TCP jest kierowane do jednego z dostępnych wystąpień zaplecza w dobrej kondycji (które zostały sprawdzone). Metryka to zintegrowany procentowy współczynnik sukcesu poleceń ping protokołu TCP dla każdej kombinacji adresu IP/portu przedniego dla każdej z twoich reguł równoważenia obciążenia w próbce czasowej.
Stan sondy kondycji
Polecenie ping protokołu zdefiniowanego w sondzie zdrowia generuje metrykę stanu sondy zdrowia. Ping jest wysyłany do każdego wystąpienia puli zaplecza i na porcie zdefiniowanym w sondzie stanu zdrowia. W przypadku sond HTTP i HTTPS udane sprawdzenie wymaga HTTP 200 OK odpowiedzi. W przypadku sond TCP każda odpowiedź jest uznawana za pomyślną.
Usługa Azure Load Balancer określa stan każdego wystąpienia zaplecza, gdy sonda osiąga liczbę kolejnych sukcesów lub niepowodzeń, którą skonfigurowano jako próg sondy. Stan zdrowia każdej instancji zaplecza określa, czy jest dozwolone odbieranie ruchu przez daną instancję zaplecza.
Podobnie jak metryka Dostępność ścieżki danych, metryka Stan sondy zdrowotnej agreguje średnią liczbę pomyślnych i całkowitych poleceń ping w interwale próbkowania. Wartość stanu sondy zdrowia wskazuje stan zdrowia zaplecza, działając niezależnie od modułu równoważenia obciążenia, poprzez sondowanie instancji zaplecza bez kierowania ruchu przez frontend.
Ważne
Stan sondy kondycji jest próbkowany co minutę. To próbkowanie może prowadzić do drobnych wahań w inaczej stałej wartości.
Rozważmy na przykład scenariusze aktywne/pasywne, w których istnieją dwa wystąpienia zaplecza, jeden sondowany w górę i jeden sondowany w dół. Usługa sondy kondycji może przechwytywać siedem próbek dla zdrowego przypadku i sześć dla niezdrowego przypadku. Taka sytuacja prowadzi do tego, że uprzednio stała wartość 50 jest wyświetlana jako 46,15 dla interwału jednominutowego.
Diagnozowanie zdegradowanych i niedostępnych równoważników obciążenia
Jak opisano w tym artykule dotyczącym kondycji zasobów, obniżona wydajność modułu równoważenia obciążenia pokazuje między 25% a 90% dostępności ścieżki danych. Niedostępny moduł równoważenia obciążenia to taki, którego dostępność ścieżki danych wynosi mniej niż 25% w okresie dwóch minut.
Możesz wykonać te same kroki, aby zbadać błąd widoczny w dowolnym skonfigurowanym stanie sondy kondycji lub alertach dostępności ścieżki danych. W poniższych krokach opisano, co zrobić, jeśli sprawdzisz kondycję zasobu i stwierdzisz, że moduł równoważenia obciążenia jest niedostępny z wartością dostępności ścieżki danych wynoszącą 0%. Twoja usługa nie działa.
W portalu Azure przejdź do szczegółowego widoku metryk dla informacji o module równoważenia obciążenia. Uzyskaj dostęp do widoku ze strony zasobu urządzenia równoważącego obciążenie lub linku w komunikacie o kondycji zasobu.
Przejdź do karty dostępności frontendu i backendu, a następnie przejrzyj 30-minutowy przedział czasowy, w którym wystąpił stan obniżonej wydajności lub niedostępności. Jeśli wartość dostępności ścieżki danych wynosi 0%, wiesz, że coś uniemożliwia ruch dla wszystkich reguł równoważenia obciążenia. Możesz również zobaczyć, jak długo ten problem trwał.
Sprawdź metrykę Stan sondy kondycji, aby określić, czy ścieżka danych jest niedostępna, ponieważ nie masz zdrowych instancji zaplecza do obsługi ruchu. Jeśli masz co najmniej jedną zdrową instancję zaplecza dla wszystkich reguł równoważenia obciążenia oraz reguł ruchu przychodzącego, masz pewność, że to nie konfiguracja powoduje niedostępność ścieżek danych. Ten scenariusz wskazuje problem z platformą Azure. Chociaż problemy z platformą są rzadkie, wyzwalają automatyczny alert do naszego zespołu w celu szybkiego rozwiązywania problemów.
Diagnozowanie błędów czujnika kondycji
Jeśli metryka statusu sondy kondycji wskazuje, że instancje zaplecza są niezdrowe, zalecamy użycie następującej listy kontrolnej, aby wykluczyć typowe błędy konfiguracji.
Sprawdź wykorzystanie procesora dla zasobów, aby ustalić, czy są one pod dużym obciążeniem.
Możesz to sprawdzić, wyświetlając metrykę Procentowe użycie CPU zasobu na stronie Metryki. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z wysokim użyciem procesora dla maszyn wirtualnych z systemem Windows na platformie Azure.
Jeśli używasz sondy HTTP lub HTTPS, sprawdź, czy aplikacja działa prawidłowo i reaguje.
Sprawdź, czy aplikacja działa, uzyskując do niej bezpośredni dostęp przez przypisany do Twojej instancji backendu prywatny adres IP lub publiczny adres IP na poziomie instancji.
Przejrzyj sieciowe grupy zabezpieczeń zastosowane do zasobów zaplecza. Upewnij się, że żadne reguły, które blokują sondę diagnostyczną, nie mają wyższego priorytetu niż
AllowAzureLoadBalancerInBound.To zadanie można wykonać, przechodząc do ustawień sieci maszyn wirtualnych zaplecza lub zestawów skalowania maszyn wirtualnych. Jeśli okaże się, że ten problem z sieciową grupą zabezpieczeń występuje, przenieś istniejącą
Allowregułę lub utwórz nową regułę o wysokim priorytecie, aby zezwolić na ruch usługi Azure Load Balancer.Sprawdź system operacyjny. Upewnij się, że twoje maszyny wirtualne nasłuchują na porcie sondy. Przejrzyj również reguły zapory systemu operacyjnego dla maszyn wirtualnych, aby upewnić się, że nie blokują ruchu sondy pochodzącego z adresu
168.63.129.16IP.Porty nasłuchiwania można sprawdzić, uruchamiając polecenie
netstat -aw wierszu polecenia systemu Windows lubnetstat -lw terminalu systemu Linux.Upewnij się, że używasz odpowiedniego protokołu. Na przykład sonda używająca protokołu HTTP do sondowania portu nasłuchiwania dla aplikacji spoza protokołu HTTP kończy się niepowodzeniem.
Nie umieszczaj usługi Azure Firewall w puli zaplecza modułów równoważenia obciążenia. Aby uzyskać więcej informacji, zobacz Integrowanie usługi Azure Firewall z usługą Azure Standard Load Balancer.