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
- Continue verbindingsfouten
- Geo-replicatie met behulp van VNet-injectie met Premium-caches
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:
- 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.
- Zorg ervoor dat de clienthostmachine zich in hetzelfde virtuele netwerk bevindt als de Azure Cache voor Redis.
- 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.
- Controleer of de regels voor binnenkomend en uitgaand verkeer voldoen aan de vereiste.
- 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:
Public Network Access
vlag is standaard uitgeschakeld bij het maken van een privé-eindpunt. Zorg ervoor dat u dePublic 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.- 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. - Als u uw privé-eindpunt hebt verwijderd, moet u ervoor zorgen dat de toegang tot het openbare netwerk is ingeschakeld.
- Controleer of uw privé-eindpunt juist is geconfigureerd. Zie Een privé-eindpunt maken met een nieuw Azure Cache voor Redis-exemplaar voor meer informatie.
- 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. - 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:
- Migreren van VNet-injectiecaches naar Private Link-caches
- Wat is Azure Cache voor Redis met Azure Private Link?
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 de VNets zich in dezelfde regio bevinden, kunt u deze verbinden met behulp van VNet-peering of een VNet-naar-VNet-verbinding van vpn-gateway.
- Als de VNets zich in verschillende regio's bevinden, wordt geo-replicatie met behulp van VNet-peering niet ondersteund. Een client-VM in VNet 1 (regio 1) heeft geen toegang tot de cache in VNet 2 (regio 2) met behulp van de DNS-naam vanwege een beperking met interne basic load balancers. Zie Virtual Network - Peering - Vereisten en beperkingen voor VNet-peering voor meer informatie over VNet-peeringbeperkingen. U wordt aangeraden een VPN Gateway-VNet-naar-VNet-verbinding te gebruiken.
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.
Gerelateerde inhoud
Deze artikelen bieden meer informatie over connectiviteit en tolerantie: