Udostępnij za pośrednictwem


Rozwiązywanie problemów z kondycją zasobów i dostępnością ruchu przychodzącego

Ten artykuł może pomóc w zbadaniu problemów wpływających na dostępność adresu IP frontonu i zasobów zaplecza modułu równoważenia obciążenia.

Możesz użyć funkcji kondycji zasobów w usłudze Azure Load Balancer, aby określić kondycję modułu równoważenia obciążenia. Analizuje metrykę Dostępność ścieżki danych, aby określić, czy są dostępne punkty końcowe równoważenia obciążenia, adres IP frontonu i połączenia portów frontonu z regułami równoważenia obciążenia.

Uwaga

Usługa Load Balancer w warstwie Podstawowa nie obsługuje funkcji kondycji 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ść ścieżki danych zgłosiła mniej niż 90%, ale większa niż 25% kondycji 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ść ścieżki danych co 25 sekund na wszystkich portach frontonu, na których skonfigurowano reguły równoważenia obciążenia. To polecenie ping PROTOKOŁU TCP jest kierowane do dowolnego wystąpienia zaplecza w dobrej kondycji (sondowane). Metryka jest zagregowanym procentowym współczynnikiem powodzenia poleceń ping protokołu TCP dla każdej kombinacji adresów IP/portów frontonu dla każdej reguły równoważenia obciążenia w okresie próbnym.

Stan sondy kondycji

Polecenie ping protokołu zdefiniowanego w sondze kondycji generuje metrykę Stan sondy kondycji. To polecenie ping jest wysyłane do każdego wystąpienia w puli zaplecza i na porcie zdefiniowanym w sondze kondycji. W przypadku sond HTTP i HTTPS pomyślne polecenie ping wymaga HTTP 200 OK odpowiedzi. W przypadku sond TCP każda odpowiedź jest uznawana za pomyślną.

Usługa Azure Load Balancer określa kondycję każdego wystąpienia zaplecza, gdy sonda osiągnie liczbę kolejnych sukcesów lub niepowodzeń skonfigurowanych dla właściwości progu sondy. Stan kondycji każdego wystąpienia zaplecza określa, czy wystąpienie zaplecza może odbierać ruch.

Podobnie jak metryka Dostępność ścieżki danych, metryka Stan sondy kondycji agreguje średnią pomyślną i łączną liczbę poleceń ping w interwale próbkowania. Wartość Stan sondy kondycji wskazuje kondycję zaplecza w izolacji od modułu równoważenia obciążenia przez sondowanie wystąpień zaplecza bez wysyłania ruchu przez fronton.

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 wystąpienia w dobrej kondycji i sześć dla wystąpienia w złej kondycji. Taka sytuacja prowadzi do wcześniejszej stałej wartości 50 wyświetlanej jako 46,15 dla interwału jednominutowego.

Diagnozowanie obniżonej wydajności i niedostępnych modułów równoważenia 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 jeden z mniej niż 25% dostępności ścieżki danych 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 znajdziesz moduł równoważenia obciążenia, aby był niedostępny z wartością dostępności ścieżki danych o wartości 0%. Twoja usługa nie działa.

  1. W witrynie Azure Portal przejdź do szczegółowego widoku metryk strony dla szczegółowych informacji modułu równoważenia obciążenia. Uzyskaj dostęp do widoku ze strony zasobu modułu równoważenia obciążenia lub linku w komunikacie kondycji zasobu.

  2. Przejdź do karty dostępności frontonu i zaplecza, a następnie przejrzyj 30-minutowe okno czasu, w których 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ł.

  3. Sprawdź metrykę Stan sondy kondycji, aby określić, czy ścieżka danych jest niedostępna, ponieważ nie masz wystąpień zaplecza w dobrej kondycji do obsługi ruchu. Jeśli masz co najmniej jedno wystąpienie zaplecza w dobrej kondycji dla wszystkich reguł równoważenia obciążenia i ruchu przychodzącego, wiesz, że konfiguracja nie powoduje niedostępności ś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 sondy kondycji

Jeśli metryka Stan sondy kondycji wskazuje, że wystąpienia zaplecza są w złej kondycji, zalecamy użycie następującej listy kontrolnej, aby wykluczyć typowe błędy konfiguracji:

  • Sprawdź wykorzystanie procesora CPU dla zasobów, aby ustalić, czy są one obciążone dużym obciążeniem.

    Możesz to sprawdzić, wyświetlając metrykę Procentowe użycie procesora CPU zasobu na stronie Metryki . Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z wysokim użyciem procesora CPU dla maszyn wirtualnych platformy Azure z systemem Windows.

  • Jeśli używasz sondy HTTP lub HTTPS, sprawdź, czy aplikacja jest w dobrej kondycji i odpowiada.

    Sprawdź, czy aplikacja działa, bezpośrednio uzyskując do niej dostęp za pośrednictwem prywatnego adresu IP lub publicznego adresu IP na poziomie wystąpienia skojarzonego z wystąpieniem zaplecza.

  • Przejrzyj sieciowe grupy zabezpieczeń zastosowane do zasobów zaplecza. Upewnij się, że żadne reguły nie mają wyższego priorytetu niż AllowAzureLoadBalancerInBound blokują sondę kondycji.

    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ń dotyczy, przenieś istniejącą Allow regułę lub utwórz nową regułę o wysokim priorytcie, aby zezwolić na ruch usługi Azure Load Balancer.

  • Sprawdź system operacyjny. Upewnij się, że 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 -a w wierszu polecenia systemu Windows lub netstat -l w 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 usługa Load Balancer w warstwie Standardowa.