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.
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 serwerów zaplecza otrzymują ruch sieciowy, 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. Zweryfikuj za pomocą zakładki Dystrybucja przepływu na wstępnie skonfigurowanym pulpicie nawigacyjnym Load Balancer Insights.
Usługa Azure Load Balancer nie obsługuje równoważenia obciążenia metodą round robin, ale obsługuje tryb dystrybucji oparty na skrótach.
Przyczyna 1. Skonfigurowano trwałość sesji
Użycie trybu dystrybucji z wykorzystaniem trwałości źródłowej może prowadzić do nierównomiernego rozkładu ruchu. Jeśli ta dystrybucja nie jest pożądana, zaktualizuj trwałość sesji na Brak, aby ruch był rozprowadzany na wszystkie zdrowe wystąpienia 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 w puli zaplecza jest wymieniona jako sprawna i odpowiada na sondy kondycji, ale nadal nie uczestniczy w równoważeniu obciążenia lub nie reaguje na ruch danych, może to być spowodowane jednym z następujących powodów:
VM zaplecza load balancera nie nasłuchuje portu 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 internetowego interfejsu modułu równoważenia obciążenia z maszyn wirtualnych znajdujących się w 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 backend.
Otwórz wiersz polecenia i uruchom następujące polecenie, aby sprawdzić, czy aplikacja nasłuchuje port 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 adresy IP klientów są dozwolone w grupie zabezpieczeń sieciowych maszyny wirtualnej na zapleczu.
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 sieciowej grupy zabezpieczeń typu Deny All na karcie sieciowej maszyny wirtualnej lub podsieci, która ma wyższy priorytet niż reguła domyślna zezwalająca 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 na 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 backendowej dla każdej aplikacji.
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 wyjściowy przepływ z maszyny wirtualnej w puli zaplecza podejmie próbę przepływu do frontu wewnętrznego równoważnika obciążenia w puli i jest mapowany z powrotem na siebie, dwa elementy przepływu nie są zgodne. Ponieważ nie są one zgodne, przepływ kończy się niepowodzeniem. Przepływ powiedzie się, jeśli nie zostanie zamapowany z powrotem na tę samą maszynę wirtualną w puli zaplecza, która utworzyła przepływ do interfejsu.
Gdy przepływ odnosi się z powrotem do siebie, przepływ wychodzący wydaje się pochodzić z maszyny wirtualnej do interfejsu frontowego, a odpowiedni przepływ przychodzący wydaje się pochodzić również z maszyny wirtualnej, ale jest skierowany do niej samej. Z punktu widzenia systemu operacyjnego gościa, części ruchu przychodzącego i wychodzącego tego samego przepływu danych nie pasują do siebie wewnątrz maszyny wirtualnej. Stos TCP nie będzie rozpoznawać tych połówek jako część tej samej transmisji. Źródło i miejsce docelowe nie są zgodne. Gdy przepływ jest mapowany na dowolną inną maszynę wirtualną w puli zaplecza, połówki przepływu zgadzają się, a maszyna wirtualna może odpowiednio na niego zareagować.
Objawem tego scenariusza jest sporadyczne przekroczenie limitu czasu połączenia, gdy przepływ powraca do tego samego serwera zaplecza, który rozpoczął przepływ. 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 jest starannie zarządzane.
Maszyny wirtualne usunięte z modułu równoważenia obciążenia odbierają ruch
Zgodnie z projektem istniejące połączenia TCP będą nadal działać na maszynie wirtualnej nawet po usunięciu zaplecza z modułu równoważenia obciążenia. Po przekierowaniu połączenia do wystąpienia zaplecza przez moduł równoważenia obciążenia ruch jest ustanawiany bezpośrednio między klientem a wystąpieniem zaplecza. Połączenia będą kontynuowane, dopóki maszyna wirtualna nie zostanie zatrzymana lub zdealokowana.
Następne kroki
Jeśli powyższe kroki nie rozwiążą problemu, otwórz zgłoszenie pomocy technicznej.