Delen via


Problemen met verbindingen oplossen

In dit artikel bieden we hulp bij het oplossen van problemen voor het verbinden van uw clienttoepassing met Azure Cache voor Redis. Verbinding maken iviteitsproblemen zijn onderverdeeld in twee typen: onregelmatige verbindingsproblemen en continue connectiviteitsproblemen.

Onregelmatige verbindingsproblemen

Uw clienttoepassing kan onregelmatige verbindingsproblemen hebben die worden veroorzaakt door gebeurtenissen zoals toepassing van een patch of pieken in het aantal verbindingen.

Serveronderhoud

Soms ondergaat uw cache een gepland of ongepland serveronderhoud. Uw toepassing kan negatief worden beïnvloed tijdens het onderhoud. U kunt valideren door de Errors (Type: Failover) metrische gegevens in uw portal te controleren. Zie Verbinding maken ietolerantie om de gevolgen van failovers te minimaliseren.

Aantal verbonden clients

Controleer of het maximumaantal toegestane Connected Clients verbindingen voor een bepaalde cachegrootte bijna of hoger is dan het maximumaantal toegestane verbindingen. Zie Azure Cache voor Redis prestaties voor meer informatie over het aanpassen van de grootte per clientverbinding.

Door Kubernetes gehoste toepassingen

  • Als uw clienttoepassing wordt gehost op Kubernetes, controleert u of de pod waarop de clienttoepassing of de clusterknooppunten worden uitgevoerd, niet onder geheugen-/CPU-/netwerkdruk staan. Een pod waarop de clienttoepassing wordt uitgevoerd, kan worden beïnvloed door andere pods die op hetzelfde knooppunt worden uitgevoerd en Redis-verbindingen of IO-bewerkingen beperken.
  • Als u Istio of een andere service-mesh gebruikt, controleert u of uw service-mesh-proxy poort 13000-13019 of 15000-15019 reserveert. Deze poorten worden gebruikt door clients om te communiceren met geclusterde Azure Cache voor Redis-knooppunten en kunnen connectiviteitsproblemen op deze poorten veroorzaken.

Linux-clienttoepassing

Het gebruik van optimistische TCP-instellingen in Linux kan ertoe leiden dat clienttoepassingen verbindingsproblemen ondervinden. Zie Verbinding maken ion stallen die 15 minuten duren.

Continue connectiviteit

Als uw toepassing geen verbinding kan maken met uw Azure Cache voor Redis, is een configuratie in de cache mogelijk niet juist ingesteld. De volgende secties bevatten suggesties voor het controleren van de juiste configuratie van uw cache.

Connectiviteit testen met redis-cli

Test de connectiviteit met redis-cli. Gebruik het opdrachtregelprogramma Redis met Azure Cache voor Redis voor meer informatie over CLI.

Connectiviteit testen met PSPING

Als redis-cli geen verbinding kan maken, kunt u de connectiviteit testen met behulp van PSPING in PowerShell.

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

U kunt controleren of het aantal verzonden pakketten gelijk is aan de ontvangen pakketten. Bevestigen zorgt ervoor dat de connectiviteit niet afneemt.

Configuratie van virtueel netwerk

Stappen voor het controleren van de configuratie van uw virtuele netwerk:

  1. Controleer of een virtueel netwerk is toegewezen aan uw cache vanuit de sectie Virtueel netwerk onder de Instellingen in het menu Resource van Azure Portal.
  2. Zorg ervoor dat de clienthostmachine zich in hetzelfde virtuele netwerk bevindt als de Azure Cache voor Redis.
  3. Wanneer de clienttoepassing zich in een ander VNet bevindt dan uw Azure Cache for Redis, moeten beide VNets VNet-peering hebben ingeschakeld binnen dezelfde Azure-regio.
  4. Controleer of de regels voor binnenkomend en uitgaand verkeer voldoen aan de vereiste.
  5. Zie Een virtueel netwerk configureren - Premium-laag Azure Cache voor Redis exemplaar voor meer informatie.

Privé-eindpunt - configuratie

Stappen voor het controleren van de configuratie van uw privé-eindpunt:

  1. Public Network Access vlag is standaard uitgeschakeld bij het maken van een privé-eindpunt. Zorg ervoor dat u de Public Network Access juist hebt ingesteld. Wanneer u uw cache in Azure Portal hebt, kijkt u onder Privé-eindpunt in het menu Resource aan de linkerkant voor deze instelling.
  2. Als u verbinding probeert te maken met uw privé-eindpunt voor de cache van buiten uw virtuele netwerk van uw cache, Public Network Access moet deze zijn ingeschakeld.
  3. Als u uw privé-eindpunt hebt verwijderd, moet u ervoor zorgen dat de toegang tot het openbare netwerk is ingeschakeld.
  4. Controleer of uw privé-eindpunt juist is geconfigureerd. Zie Een privé-eindpunt maken met een nieuw Azure Cache voor Redis-exemplaar voor meer informatie.
  5. Controleer of uw toepassing verbinding maakt met <cachename>.redis.cache.windows.net poort 6380. We raden u aan het gebruik van <cachename>.privatelink.redis.cache.windows.net in de configuratie of de verbindingsreeks te vermijden.
  6. Voer een opdracht uit zoals nslookup <hostname> vanuit het VNet dat is gekoppeld aan het privé-eindpunt om te controleren of de opdracht wordt omgezet in het privé-IP-adres voor de cache.

Firewall-regels

Als u een firewall hebt geconfigureerd voor uw Azure Cache voor Redis, moet u ervoor zorgen dat het IP-adres van uw client wordt toegevoegd aan de firewallregels. U kunt Firewall controleren in het menu Resource onder Instellingen in Azure Portal.

Firewall van derden of externe proxy

Wanneer u een firewall of proxy van derden in uw netwerk gebruikt, controleert u of het eindpunt voor Azure Cache voor Redis, *.redis.cache.windows.net, is toegestaan, samen met de poorten 6379 en 6380. Mogelijk moet u meer poorten toestaan wanneer u een geclusterde cache of geo-replicatie gebruikt.

Wijziging van openbaar IP-adres

Als u een netwerk- of beveiligingsresource hebt geconfigureerd voor het gebruik van het openbare IP-adres van uw cache, controleert u of het openbare IP-adres van uw cache is gewijzigd. Zie Vertrouwen op hostnaam en niet op openbaar IP-adres voor uw cache voor meer informatie.

Geo-replicatie met behulp van VNet-injectie met Premium-caches

Hoewel het mogelijk is om VNet-injectie te gebruiken met uw Premium-caches, raden we Azure Private Link aan.

Zie voor meer informatie:

Geo-replicatie van caches in VNets wordt ondersteund met opmerkingen:

  • Geo-replicatie tussen caches in hetzelfde VNet wordt ondersteund.
  • Geo-replicatie tussen caches in verschillende VNets wordt ook ondersteund.

Als u uw VNet effectief wilt configureren en geo-replicatieproblemen wilt voorkomen, moet u zowel de binnenkomende als uitgaande poorten correct configureren. Zie De vereisten voor peerpoorten voor geo-replicatie voor geo-replicatie voor meer informatie over het voorkomen van de meest voorkomende VNet-onjuiste configuratieproblemen.

Deze artikelen bieden meer informatie over connectiviteit en tolerantie: