Udostępnij za pośrednictwem


Rozwiązywanie problemów z odpowiedziami ruchu zaplecza usługi Azure Load Balancer

Ta strona zawiera informacje dotyczące rozwiązywania problemów z pytaniami dotyczącymi usługi Azure Load Balancer.

Maszyny wirtualne za modułem równoważenia obciążenia otrzymują nierównomierną dystrybucję ruchu

Jeśli podejrzewasz, że członkowie puli zaplecza otrzymują ruch, może to być spowodowane następującymi przyczynami. Usługa Azure Load Balancer dystrybuuje ruch na podstawie połączeń. Pamiętaj, aby sprawdzić dystrybucję ruchu na połączenie, a nie na pakiet. Sprawdź, czy używasz karty Dystrybucja przepływu na wstępnie skonfigurowanym pulpicie nawigacyjnym usługi Load Balancer Szczegółowe informacje.

Usługa Azure Load Balancer nie obsługuje rzeczywistego równoważenia obciążenia działania okrężnego, ale obsługuje tryb dystrybucji oparty na skrótach.

Przyczyna 1. Skonfigurowano trwałość sesji

Użycie trybu dystrybucji trwałości źródłowej może spowodować nierównomierny rozkład ruchu. Jeśli ta dystrybucja nie jest wymagana, trwałość sesji aktualizacji ma wartość Brak , więc ruch jest dystrybuowany we wszystkich wystąpieniach w dobrej kondycji w puli zaplecza. Dowiedz się więcej o trybach dystrybucji dla usługi Azure Load Balancer.

Przyczyna 2. Masz skonfigurowany serwer proxy

Klienci, którzy działają za serwerami proxy, mogą być postrzegani jako jedna unikatowa aplikacja kliencka z punktu widzenia modułu równoważenia obciążenia.

Maszyny wirtualne za modułem równoważenia obciążenia nie odpowiadają na ruch na skonfigurowanym porcie danych

Jeśli maszyna wirtualna puli zaplecza jest wymieniona jako w dobrej kondycji i odpowiada na sondy kondycji, ale nadal nie uczestniczy w równoważeniu obciążenia lub nie odpowiada na ruch danych, może to być spowodowane żadnym z następujących powodów:

  • Maszyna wirtualna puli zaplecza modułu równoważenia obciążenia nie nasłuchuje na porcie danych

  • Sieciowa grupa zabezpieczeń blokuje port na maszynie wirtualnej puli zaplecza modułu równoważenia obciążenia

  • Uzyskiwanie dostępu do modułu równoważenia obciążenia z tej samej maszyny wirtualnej i karty sieciowej

  • Uzyskiwanie dostępu do frontonu internetowego modułu równoważenia obciążenia z uczestniczących maszyn wirtualnych puli zaplecza modułu równoważenia obciążenia

Przyczyna 1. Maszyna wirtualna puli zaplecza modułu równoważenia obciążenia nie nasłuchuje na porcie danych

Jeśli maszyna wirtualna nie odpowiada na ruch danych, może to być spowodowane tym, że port docelowy nie jest otwarty na uczestniczącej maszynie wirtualnej lub maszyna wirtualna nie nasłuchuje na tym porcie.

Walidacja i rozwiązywanie problemów

  1. Zaloguj się do maszyny wirtualnej zaplecza.

  2. Otwórz wiersz polecenia i uruchom następujące polecenie, aby sprawdzić, czy aplikacja nasłuchuje na porcie danych:

    netstat -an 
    
  3. Jeśli port nie znajduje się na liście ze stanem LISTENING, skonfiguruj odpowiedni port odbiornika

  4. Jeśli port jest oznaczony jako NASŁUCHIWANIE, sprawdź aplikację docelową na tym porcie pod kątem ewentualnych problemów.

Przyczyna 2. Sieciowa grupa zabezpieczeń blokuje port na maszynie wirtualnej puli zaplecza modułu równoważenia obciążenia

Jeśli co najmniej jedna sieciowa grupa zabezpieczeń skonfigurowana w podsieci lub na maszynie wirtualnej blokuje źródłowy adres IP lub port, maszyna wirtualna nie może odpowiedzieć.

W przypadku publicznego modułu równoważenia obciążenia adres IP klientów internetowych będzie używany do komunikacji między klientami a maszynami wirtualnymi zaplecza modułu równoważenia obciążenia. Upewnij się, że adres IP klientów jest dozwolony w sieciowej grupie zabezpieczeń maszyny wirtualnej zaplecza.

  1. Wyświetl listę sieciowych grup zabezpieczeń skonfigurowanych na maszynie wirtualnej zaplecza. Aby uzyskać więcej informacji, zobacz Zarządzanie sieciowymi grupami zabezpieczeń

  2. Na liście sieciowych grup zabezpieczeń sprawdź, czy:

    • Ruch przychodzący lub wychodzący na porcie danych ma interferencję.

    • Reguła odmów wszystkich sieciowych grup zabezpieczeń na karcie sieciowej maszyny wirtualnej lub podsieci o wyższym priorytcie, która zezwala na sondy i ruch modułu równoważenia obciążenia (sieciowe grupy zabezpieczeń muszą zezwalać na adres IP modułu równoważenia obciążenia 168.63.129.16, czyli port sondy)

  3. Jeśli którakolwiek z reguł blokuje ruch, usuń i ponownie skonfiguruj te reguły, aby zezwolić na ruch danych. 

  4. Przetestuj, czy maszyna wirtualna zaczęła odpowiadać na sondy kondycji.

Przyczyna 3. Dostęp do wewnętrznego modułu równoważenia obciążenia z tej samej maszyny wirtualnej i interfejsu sieciowego

Jeśli aplikacja hostowana na maszynie wirtualnej zaplecza wewnętrznego modułu równoważenia obciążenia próbuje uzyskać dostęp do innej aplikacji hostowanej na tej samej maszynie wirtualnej zaplecza za pośrednictwem tego samego interfejsu sieciowego, jest to nieobsługiwany scenariusz i zakończy się niepowodzeniem.

Rozwiązanie

Ten problem można rozwiązać za pomocą jednej z następujących metod:

  • Skonfiguruj oddzielne maszyny wirtualne puli zaplecza na aplikację.

  • Skonfiguruj aplikację na maszynach wirtualnych z dwiema kartami sieciowymi, aby każda aplikacja korzystała z własnego interfejsu sieciowego i adresu IP.

Przyczyna 4. Dostęp do wewnętrznego frontonu modułu równoważenia obciążenia z uczestniczących maszyn wirtualnych puli zaplecza modułu równoważenia obciążenia

Jeśli wewnętrzny moduł równoważenia obciążenia jest skonfigurowany wewnątrz sieci wirtualnej, a jedna z maszyn wirtualnych zaplecza uczestnika próbuje uzyskać dostęp do wewnętrznego frontonu modułu równoważenia obciążenia, błędy mogą wystąpić, gdy przepływ jest mapowany na źródłową maszynę wirtualną. Ten scenariusz nie jest obsługiwany.

Rozwiązanie

Istnieje kilka sposobów odblokowania tego scenariusza, w tym korzystania z serwera proxy. Oceń usługę Application Gateway lub inne serwery proxy innych firm (na przykład serwer nginx lub haproxy). Aby uzyskać więcej informacji na temat usługi Application Gateway, zobacz Omówienie usługi Application Gateway

Szczegóły

Wewnętrzne moduły równoważenia obciążenia nie tłumaczą połączeń wychodzących pochodzących z frontonu wewnętrznego modułu równoważenia obciążenia, ponieważ oba są w prywatnej przestrzeni adresowej IP. Publiczne moduły równoważenia obciążenia zapewniają połączenia wychodzące z prywatnych adresów IP wewnątrz sieci wirtualnej do publicznych adresów IP. W przypadku wewnętrznych modułów równoważenia obciążenia takie podejście pozwala uniknąć potencjalnego wyczerpania portów SNAT wewnątrz unikatowej wewnętrznej przestrzeni adresowej IP, gdzie tłumaczenie nie jest wymagane.

Efektem ubocznym jest to, że jeśli przepływ wychodzący z maszyny wirtualnej w puli zaplecza podejmie próbę przepływu do frontonu wewnętrznego modułu równoważenia obciążenia w puli i jest mapowany z powrotem na siebie, dwie nogi przepływu nie są zgodne. Ponieważ nie są one zgodne, przepływ kończy się niepowodzeniem. Przepływ powiedzie się, jeśli przepływ nie został zamapowyny z powrotem na tę samą maszynę wirtualną w puli zaplecza, która utworzyła przepływ do frontonu.

Gdy przepływ mapuje się z powrotem na siebie, przepływ wychodzący wydaje się pochodzić z maszyny wirtualnej do frontonu, a odpowiedni przepływ przychodzący wydaje się pochodzić z maszyny wirtualnej do samego siebie. Z punktu widzenia systemu operacyjnego gościa części ruchu przychodzącego i wychodzącego tego samego przepływu nie są zgodne wewnątrz maszyny wirtualnej. Stos TCP nie rozpozna tych połówek tego samego przepływu co część tego samego przepływu. Źródło i miejsce docelowe nie są zgodne. Gdy przepływ jest mapowy na dowolną inną maszynę wirtualną w puli zaplecza, połówki przepływu są zgodne, a maszyna wirtualna może reagować na przepływ.

Objawem tego scenariusza jest sporadyczne przekroczenie limitu czasu połączenia, gdy przepływ powraca do tego samego zaplecza, które pochodzi z przepływu. Typowe obejścia obejmują wstawianie warstwy serwera proxy za wewnętrznym modułem równoważenia obciążenia i używanie reguł stylu powrotu serwera bezpośredniego (DSR). Aby uzyskać więcej informacji, zobacz Wiele frontonów dla usługi Azure Load Balancer.

Wewnętrzny moduł równoważenia obciążenia można połączyć z dowolnym serwerem proxy innej firmy lub użyć wewnętrznej usługi Application Gateway na potrzeby scenariuszy serwera proxy z protokołem HTTP/HTTPS. Chociaż można użyć publicznego modułu równoważenia obciążenia, aby rozwiązać ten problem, wynikowy scenariusz jest podatny na wyczerpanie SNAT. Unikaj tego drugiego podejścia, chyba że starannie zarządzane.

Następne kroki

Jeśli powyższe kroki nie rozwiążą problemu, otwórz bilet pomocy technicznej.