Udostępnij za pośrednictwem

Rozwiązywanie problemów z połączeniem

  • Artykuł

W tym artykule udostępniamy pomoc dotyczącą rozwiązywania problemów dotyczących łączenia aplikacji klienckiej z usługą Azure Cache for Redis. Problemy z łącznością są podzielone na dwa typy: sporadyczne problemy z łącznością i problemy z ciągłą łącznością.

Sporadyczne problemy z łącznością

Aplikacja kliencka może mieć sporadyczne problemy z łącznością spowodowane zdarzeniami takimi jak stosowanie poprawek lub skoki liczby połączeń.

Konserwacja serwera

Czasami pamięć podręczna jest poddawana planowanej lub nieplanowanej konserwacji serwera. Konserwacja może mieć negatywny wpływ na Twoją aplikację. Możesz sprawdzić poprawność, sprawdzając metryki Errors (Type: Failover) w portalu. Aby zminimalizować skutki przejścia w tryb failover, zobacz Odporność połączenia.

Liczba połączonych klientów

Sprawdź, czy maksymalna agregacja dla Connected Clients metryki jest bliska lub większa niż maksymalna liczba dozwolonych połączeń dla określonego rozmiaru pamięci podręcznej. Aby uzyskać więcej informacji na temat określania rozmiaru na połączenia klienckie, zobacz Wydajność usługi Azure Cache for Redis.

Aplikacje hostowane na platformie Kubernetes

  • Jeśli aplikacja kliencka jest hostowana na platformie Kubernetes, sprawdź, czy zasobnik z uruchomioną aplikacją kliencką lub węzły klastra nie wykazują nadmiernego obciążenia pamięci/procesora CPU/sieci. Na zasobnik z uruchomioną aplikacją kliencką mogą wpływać inne zasobniki uruchomione w tym samym węźle, powodując ograniczanie połączeń usługi Redis lub operacji we/wy.
  • Jeśli używasz usługi Istio lub innej siatki usług, sprawdź, czy serwer proxy usługi service mesh rezerwuje port 13000-13019 lub 15000-15019. Te porty są używane przez klientów do komunikowania się z klastrowanych węzłów usługi Azure Cache for Redis i mogą powodować problemy z łącznością na tych portach.

Aplikacja kliencka oparta na systemie Linux

Korzystanie z optymistycznych ustawień TCP w systemie Linux może powodować problemy z łącznością aplikacji klienckich. Zobacz Stoiska połączeń trwające przez 15 minut.

Ciągła łączność

Jeśli aplikacja nie może nawiązać połączenia z usługą Azure Cache for Redis, być może konfiguracja pamięci podręcznej nie jest poprawnie określona. Poniższa tabela zawiera sugestie dotyczące upewniania się, że pamięć podręczna jest poprawnie skonfigurowana.

Testowanie łączności przy użyciu interfejsu wiersza polecenia redis

Przetestuj łączność przy użyciu interfejsu wiersza polecenia redis. Aby uzyskać więcej informacji na temat interfejsu wiersza polecenia, użyj narzędzia wiersza polecenia redis z usługą Azure Cache for Redis.

Testowanie łączności przy użyciu polecenia PSPING

Jeśli narzędzie redis-cli nie może nawiązać połączenia, możesz przetestować łączność przy użyciu polecenia PSPING w programie PowerShell.

psping -q <cache DNS endpoint>:<Port Number>

Możesz sprawdzić, czy liczba wysłanych pakietów jest równa liczbie odebranych pakietów. Jeśli zostanie to potwierdzone, spadek łączności nie występuje.

Konfiguracja sieci wirtualnej

Kroki sprawdzania konfiguracji sieci wirtualnej:

  1. Sprawdź, czy sieć wirtualna jest przypisana do pamięci podręcznej z sekcji "Sieć wirtualna" w menu Ustawienia w menu Zasób witryny Azure Portal.
  2. Upewnij się, że maszyna hosta klienta znajduje się w tej samej sieci wirtualnej co usługa Azure Cache for Redis.
  3. Gdy aplikacja kliencka znajduje się w innej sieci wirtualnej z usługi Azure Cache for Redis, obie sieci wirtualne muszą mieć włączoną komunikację równorzędną sieci wirtualnych w tym samym regionie świadczenia usługi Azure.
  4. Sprawdź, czy reguły ruchu przychodzącego i wychodzącego spełniają wymagania.
  5. Aby uzyskać więcej informacji, zobacz Konfigurowanie sieci wirtualnej — wystąpienie usługi Azure Cache for Redis w warstwie Premium.

Konfiguracje prywatnego punktu końcowego

Kroki sprawdzania konfiguracji prywatnego punktu końcowego:

  1. Public Network Access flaga jest domyślnie wyłączona podczas tworzenia prywatnego punktu końcowego. Upewnij się, że ustawiono poprawną wartość Public Network Access . Jeśli masz pamięć podręczną w witrynie Azure Portal, w obszarze Prywatny punkt końcowy w menu Zasób po lewej stronie tego ustawienia.
  2. Jeśli próbujesz nawiązać połączenie z prywatnym punktem końcowym pamięci podręcznej spoza sieci wirtualnej pamięci podręcznej, Public Network Access należy ją włączyć.
  3. Jeśli usuniesz prywatny punkt końcowy, upewnij się, że dostęp do sieci publicznej jest włączony.
  4. Sprawdź, czy prywatny punkt końcowy jest poprawnie skonfigurowany. Aby uzyskać więcej informacji, zobacz Tworzenie prywatnego punktu końcowego przy użyciu nowego wystąpienia usługi Azure Cache for Redis.
  5. Sprawdź, czy aplikacja łączy się <cachename>.redis.cache.windows.net z portem 6380. Zalecamy unikanie używania adresu <cachename>.privatelink.redis.cache.windows.net w konfiguracji i parametrach połączenia.
  6. Aby sprawdzić, czy polecenie jest rozpoznawane jako prywatny adres IP pamięci podręcznej, uruchom polecenie podobne nslookup <hostname> do z poziomu sieci wirtualnej połączonej z prywatnym punktem końcowym.

Reguły zapory

Jeśli masz zaporę skonfigurowaną dla usługi Azure Cache for Redis, upewnij się, że adres IP klienta został dodany do reguł zapory. Zaporę można sprawdzić w menu Zasób w obszarze Ustawienia w witrynie Azure Portal.

Zapora lub zewnętrzny serwer proxy innej firmy

Jeśli używasz zapory lub serwera proxy innej firmy w swojej sieci, sprawdź, czy punkt końcowy dla usługi Azure Cache for Redis (*.redis.cache.windows.net) jest dozwolony wraz z portami 6379 i 6380. W przypadku korzystania z klastrowanej pamięci podręcznej lub replikacji geograficznej może być konieczne zezwolenie na więcej portów.

Zmiana publicznego adresu IP

Jeśli skonfigurujesz jakikolwiek zasób sieciowy lub zasób zabezpieczeń, aby użyć publicznego adresu IP pamięci podręcznej, sprawdź, czy publiczny adres IP pamięci podręcznej uległ zmianie. Aby uzyskać więcej informacji, zobacz Należy używać nazwy hosta, a nie publicznego adresu IP pamięci podręcznej.

Replikacja geograficzna korzystająca z iniekcji sieci wirtualnej z pamięciami podręcznymi Premium

Chociaż istnieje możliwość użycia iniekcji sieci wirtualnej (VNet) z pamięciami podręcznymi w warstwie Premium, zalecamy użycie usługi Azure Private Link.

Aby uzyskać więcej informacji, zobacz:

Replikacja geograficzna pamięci podręcznych w sieci wirtualnej (VNet)s jest obsługiwana z zastrzeżeniami:

  • Replikacja geograficzna między pamięciami podręcznymi w tej samej sieci wirtualnej jest obsługiwana.
  • Replikacja geograficzna między pamięciami podręcznymi w różnych sieciach wirtualnych jest również obsługiwana.
    • Jeśli sieci wirtualne znajdują się w tym samym regionie, możesz połączyć je przy użyciu komunikacji równorzędnej sieci wirtualnych lub połączenia między sieciami wirtualnymi usługi VPN Gateway.
    • Jeśli sieci wirtualne znajdują się w różnych regionach, replikacja geograficzna korzystająca z komunikacji równorzędnej sieci wirtualnych nie jest obsługiwana. Maszyna wirtualna klienta w sieci wirtualnej 1 (region 1) nie może uzyskać dostępu do pamięci podręcznej w sieci wirtualnej 2 (region 2) przy użyciu jej nazwy DNS z powodu ograniczenia z wewnętrznymi modułami równoważenia obciążenia w warstwie Podstawowa. Aby uzyskać więcej informacji na temat ograniczeń komunikacji równorzędnej sieci wirtualnych, zobacz Virtual Network — Peering — Requirements and constraints (Sieć wirtualna — komunikacja równorzędna — wymagania i ograniczenia). Zalecamy używanie połączenia między sieciami wirtualnymi usługi VPN Gateway.

Aby efektywnie skonfigurować sieć wirtualną i uniknąć problemów z replikacją geograficzną, należy poprawnie skonfigurować porty przychodzące i wychodzące. Aby uzyskać więcej informacji na temat unikania najczęstszych problemów z błędną konfiguracją sieci wirtualnej, zobacz Wymagania dotyczące portów równorzędnych replikacji geograficznej.

Powiązana zawartość

Te artykuły zawierają więcej informacji na temat łączności i odporności: