Dela via

Felsökning av anslutning

  • Artikel

I den här artikeln tillhandahåller vi felsökningshjälp för att ansluta klientprogrammet till Azure Cache for Redis. Anslutningsproblem kan delas in i två typer: tillfälliga och kontinuerliga.

Tillfälliga anslutningsproblem

Klientprogrammet kan ha tillfälliga anslutningsproblem som orsakas av händelser som korrigeringar eller toppar i antalet anslutningar.

Serverunderhåll

Ibland genomgår cachen ett planerat eller oplanerat serverunderhåll. Programmet kan påverkas negativt under underhållet. Du kan verifiera genom att kontrollera måttet Errors (Type: Failover) i portalen. Information om hur du minimerar effekterna av redundansväxlingar finns i Anslutningsåterhämtning.

Antal anslutna klienter

Kontrollera om maxmåttet för Connected Clients är nära eller högre än det maximala antalet tillåtna anslutningar för en viss cachestorlek. Mer information om storleksändring per klientanslutningar finns i Prestanda för Azure Cache for Redis.

Kubernetes-värdbaserade program

  • Om klientprogrammet finns på Kubernetes kontrollerar du att podden som kör klientprogrammet eller klusternoderna inte är under minnes-/CPU-/nätverksbelastning. En podd som kör klientprogrammet kan påverkas av andra poddar som körs på samma nod och begränsar Redis-anslutningar eller I/O-åtgärder.
  • Om du använder Istio eller något annat servicenät kontrollerar du att service mesh-proxyn reserverar port 13000-13019 eller 15000-15019. Dessa portar används av klienter för att kommunicera med en klustrad Azure Cache for Redis-noder och kan orsaka anslutningsproblem på dessa portar.

Linux-baserat klientprogram

Om du använder optimistiska TCP-inställningar i Linux kan klientprogram få anslutningsproblem. Se Anslutningsuppehåll varar i 15 minuter.

Kontinuerlig anslutning

Om ditt program inte kan ansluta till din Azure Cache for Redis är det möjligt att en viss konfiguration i cacheminnet inte är korrekt konfigurerad. Följande avsnitt innehåller förslag på hur du ser till att cacheminnet är korrekt konfigurerat.

Testa anslutningen med redis-cli

Testa anslutningen med redis-cli. Mer information om CLI finns i Redis-kommandoradsverktyget med Azure Cache for Redis.

Testa anslutningen med PSPING

Om det inte går att ansluta med redis-cli kan du testa anslutningen med hjälp av PSPING i PowerShell.

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

Du kan bekräfta att antalet skickade paket är lika med de mottagna paketen. Att bekräfta säkerställer att anslutningen inte avbryts.

Konfiguration av virtuellt nätverk

Steg för att kontrollera konfigurationen av det virtuella nätverket:

  1. Kontrollera om ett virtuellt nätverk har tilldelats din cache från avsnittet "Virtuellt nätverk" under Inställningar på resursmenyn i Azure Portal.
  2. Kontrollera att klientvärddatorn finns i samma virtuella nätverk som Azure Cache for Redis.
  3. När klientprogrammet finns i ett annat virtuellt nätverk (VNet) från Azure Cache for Redis måste båda de virtuella nätverken ha VNet-peering aktiverat i samma Azure-region.
  4. Kontrollera att reglerna för inkommande och utgående trafik uppfyller kravet.
  5. Mer information finns i Konfigurera ett virtuellt nätverk – Azure Cache for Redis-instans på Premium-nivå.

Konfiguration av privat slutpunkt

Steg för att kontrollera konfigurationen av din privata slutpunkt:

  1. Public Network Access -flaggan är inaktiverad som standard när du skapar en privat slutpunkt. Kontrollera att du har angett rätt Public Network Access . När du har cacheminnet i Azure Portal kan du titta under Privat slutpunkt på menyn Resurs till vänster för den här inställningen.
  2. Om du försöker ansluta till din privata cacheslutpunkt utanför ditt virtuella nätverk i cachen Public Network Access måste du vara aktiverad.
  3. Om du tar bort din privata slutpunkt kontrollerar du att åtkomsten till det offentliga nätverket är aktiverad.
  4. Kontrollera om din privata slutpunkt är korrekt konfigurerad. Mer information finns i avsnittet om att skapa en privat slutpunkt med en ny Azure Cache for Redis-instans.
  5. Kontrollera om programmet ansluter till <cachename>.redis.cache.windows.net på port 6380. Vi rekommenderar att du undviker att använda <cachename>.privatelink.redis.cache.windows.net i konfigurationen eller anslutningssträngen.
  6. Kontrollera att kommandot matchar den privata IP-adressen för cachen genom att köra ett kommando som nslookup <hostname> från det virtuella nätverket (VNet) som är länkat till den privata slutpunkten.

Brandväggsregler

Om du har konfigurerat en brandvägg för Azure Cache for Redis kontrollerar du att klientens IP-adress har lagts till i brandväggsreglerna. Du kan kontrollera Brandvägg på menyn Resurs under Inställningar i Azure-portalen.

Brandvägg från tredje part eller extern proxy

När du använder en brandvägg eller proxy från tredje part i nätverket kontrollerar du att slutpunkten för Azure Cache for Redis, *.redis.cache.windows.net, tillåts tillsammans med portarna 6379 och 6380. Du kan behöva tillåta fler portar när du använder en klustrad cache eller geo-replikering.

Ändring av offentlig IP-adress

Om du konfigurerar nätverks- eller säkerhetsresurser för att använda cachens offentliga IP-adress kontrollerar du om cachens offentliga IP-adress har ändrats. Mer information finns i avsnittet om att förlita dig på värdnamn, inte offentlig IP-adress för din cache.

Geo-replikering med VNet-inmatning med Premium-cacheminnen

Även om det är möjligt att använda inmatning av virtuella nätverk (VNet) med dina Premium-cacheminnen rekommenderar vi Azure Private Link.

Mer information finns i:

Geo-replikering av cacheminnen i virtuella nätverk (VNet)s stöds med förbehåll:

  • Geo-replikering mellan cacheminnen i samma virtuella nätverk stöds.
  • Geo-replikering mellan cacheminnen i olika virtuella nätverk stöds också.
    • Om de virtuella nätverken finns i samma region kan du ansluta dem med VNet-peering eller en VPN Gateway VNet-till-VNet-anslutning.
    • Om de virtuella nätverken finns i olika regioner stöds inte geo-replikering med VNet-peering. En virtuell klientdator i VNet 1 (region 1) kan inte komma åt cachen i VNet 2 (region 2) med sitt DNS-namn på grund av en begränsning med grundläggande interna lastbalanserare. Mer information om begränsningar för VNet-peering finns i Virtual Network – Peering – Krav och begränsningar. Vi rekommenderar att du använder en VPN Gateway VNet-till-VNet-anslutning.

Om du vill konfigurera ditt virtuella nätverk (VNet) effektivt och undvika problem med geo-replikering måste du konfigurera både inkommande och utgående portar korrekt. Mer information om hur du undviker de vanligaste felkonfigurationsproblemen för virtuella nätverk finns i Krav för peer-port för geo-replikering.

Relaterat innehåll

De här artiklarna innehåller mer information om anslutning och motståndskraft: