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
Zaloguj się do maszyny wirtualnej zaplecza.
Otwórz wiersz polecenia i uruchom następujące polecenie, aby sprawdzić, czy aplikacja nasłuchuje na porcie danych:
netstat -anJeśli port nie znajduje się na liście ze stanem LISTENING, skonfiguruj odpowiedni port odbiornika
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.
Wyświetl listę sieciowych grup zabezpieczeń skonfigurowanych na maszynie wirtualnej zaplecza. Aby uzyskać więcej informacji, zobacz Zarządzanie sieciowymi grupami zabezpieczeń
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)
Jeśli którakolwiek z reguł blokuje ruch, usuń i ponownie skonfiguruj te reguły, aby zezwolić na ruch danych.
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.