Behandlung von Konnektivitätsproblemen

  • Artikel

In diesem Artikel erhalten Sie Hilfe bei der Behandlung von Problemen beim Verbinden Ihrer Clientanwendung mit Azure Cache for Redis. Verbindungsprobleme sind in zwei Typen unterteilt: zeitweilige Verbindungsprobleme und fortlaufende Verbindungsprobleme.

Zeitweilige Verbindungsprobleme

Bei Ihrer Clientanwendung treten möglicherweise zeitweilige Verbindungsprobleme auf, die durch Ereignisse wie Patchen oder Spitzen bei der Anzahl von Verbindungen verursacht werden.

Serverwartung

Manchmal wird Ihr Cache einer geplanten oder ungeplanten Serverwartung unterzogen. Ihre Anwendung kann während der Wartung beeinträchtigt werden. Sie können dies überprüfen, indem Sie die Metrik Errors (Type: Failover) in Ihrem Portal überprüfen. Informationen zum Minimieren der Auswirkungen von Failovern finden Sie unter Verbindungsresilienz.

Anzahl verbundener Clients

Überprüfen Sie, ob das Max-Aggregat für die Metrik Connected Clients die maximale Anzahl zulässiger Verbindungen für eine bestimmte Cachegröße allmählich erreicht oder überschreitet. Weitere Informationen zur Anpassung der Größe pro Clientverbindung finden Sie unter Azure Cache for Redis – Leistung.

Auf Kubernetes gehostete Anwendungen

  • Wenn Ihre Clientanwendung auf Kubernetes gehostet wird, vergewissern Sie sich, dass für den Pod, auf dem die Clientanwendung ausgeführt wird, oder die Clusterknoten keine hohe Arbeitsspeicher-, CPU- oder Netzwerkauslastung besteht. Ein Pod, auf dem die Clientanwendung ausgeführt wird, kann von anderen auf demselben Knoten ausgeführten Pods beeinträchtigt werden. Dies kann zur Drosselung von Redis-Verbindungen oder E/A-Vorgänge führen.
  • Wenn Sie Istio oder ein anderes Dienstnetz verwenden, vergewissern Sie sich, dass Ihr Dienstnetzproxy Port 13000-13019 oder 15000-15019 reserviert. Diese Ports werden von Clients für die Kommunikation mit gruppierten Azure Cache for Redis-Knoten verwendet und können zu Konnektivitätsproblemen an diesen Ports führen.

Linux-basierte Clientanwendung

Die Verwendung optimistischer TCP-Einstellungen unter Linux kann bei Clientanwendungen zu Konnektivitätsproblemen führen. Weitere Informationen finden Sie unter Connection stalls lasting for 15 minutes (Verbindungsunterbrechungen mit einer Dauer von 15 Minuten).

Fortlaufende Verbindung

Wenn Ihre Anwendung keine Verbindung mit Azure Cache for Redis herstellen kann, sind möglicherweise einige Konfigurationen für den Cache nicht ordnungsgemäß eingerichtet. Die folgenden Abschnitte enthalten Vorschläge, wie Sie sicherstellen können, dass Ihr Cache ordnungsgemäß konfiguriert ist.

Testen der Konnektivität mithilfe von redis-cli

Testen Sie die Konnektivität mithilfe von redis-cli. Weitere Informationen zu CLI finden Sie unter Verwenden des Redis-Befehlszeilentools mit Azure Cache for Redis.

Testen der Konnektivität mithilfe von PSPING

Wenn redis-cli keine Verbindung herstellen kann, können Sie die Konnektivität mithilfe von PSPING in PowerShell testen.

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

Sie können überprüfen, ob die Anzahl der gesendeten Pakete mit der Anzahl der empfangenen Pakete übereinstimmt. Durch die Überprüfung wird sichergestellt, dass die Konnektivität nicht abfällt.

Konfiguration von virtuellen Netzwerken

Schritte zum Überprüfen der Konfiguration des virtuellen Netzwerks:

  1. Überprüfen Sie im Abschnitt „Virtuelles Netzwerk“ unter Einstellungen im Ressourcenmenü des Azure-Portals, ob Ihrem Cache ein virtuelles Netzwerk zugewiesen ist.
  2. Stellen Sie sicher, dass sich der Clienthostcomputer in demselben virtuellen Netzwerk wie Azure Cache for Redis befindet.
  3. Wenn sich die Clientanwendung in einem anderen VNet als Azure Cache for Redis befindet, muss für beide VNets das VNet-Peering in derselben Azure-Region aktiviert sein.
  4. Überprüfen Sie, ob die Eingangs- und Ausgangs-Regeln die Anforderung erfüllen.
  5. Weitere Informationen finden Sie unter Konfigurieren eines virtuellen Netzwerks – Azure Cache for Redis-Instanz im Premium-Tarif.

Konfiguration des privaten Endpunkts

Schritte zum Überprüfen der Konfiguration des privaten Endpunkts:

  1. Public Network Access-Flag ist beim Erstellen eines privaten Endpunkts standardmäßig deaktiviert. Stellen Sie sicher, dass Sie Public Network Access ordnungsgemäß festgelegt haben. Wenn Sie Ihren Cache im Azure-Portal haben, suchen Sie unter Privater Endpunkt im Ressourcenmenü auf der linken Seite nach dieser Einstellung.
  2. Wenn Sie versuchen, von außerhalb Ihres virtuellen Netzwerks Ihres Caches eine Verbindung mit dem privaten Endpunkt Ihres Caches herzustellen, muss Public Network Access aktiviert werden.
  3. Wenn Sie Ihren privaten Endpunkt gelöscht haben, stellen Sie sicher, dass der Zugriff auf das öffentliche Netzwerk aktiviert ist.
  4. Überprüfen Sie, ob Ihr privater Endpunkt richtig konfiguriert ist. Weitere Informationen finden Sie unter Erstellen eines privaten Endpunkts mit einer neuen Azure Cache for Redis-Instanz.
  5. Überprüfen Sie, ob Ihre Anwendung an Port 6380 eine Verbindung mit <cachename>.redis.cache.windows.net herstellt. Es wird empfohlen, die Verwendung von <cachename>.privatelink.redis.cache.windows.net in der Konfiguration oder der Verbindungszeichenfolge zu vermeiden.
  6. Führen Sie einen Befehl wie nslookup <hostname> aus dem VNet aus, das mit dem privaten Endpunkt verknüpft ist, um zu überprüfen, ob der Befehl die private IP-Adresse für den Cache auflöst.

Firewallregeln

Wenn Sie eine Firewall für Azure Cache for Redis konfiguriert haben, stellen Sie sicher, dass Ihre Client-IP-Adresse den Firewallregeln hinzugefügt wurde. Sie können Firewall im Ressourcenmenü unter Einstellungen im Azure-Portal überprüfen.

Firewall von Drittanbietern oder externer Proxy

Wenn Sie eine Firewall oder einen Proxy eines Drittanbieters in Ihrem Netzwerk verwenden, überprüfen Sie, ob der Endpunkt für Azure Cache for Redis, *.redis.cache.windows.net, zusammen mit den Ports 6379 und 6380 zulässig ist. Möglicherweise müssen Sie weitere Ports zulassen, wenn Sie einen gruppierten Cache oder eine Georeplikation verwenden.

Änderung der öffentlichen IP-Adresse

Wenn Sie Netzwerk- oder Sicherheitsressourcen für die Verwendung der öffentlichen IP-Adresse Ihres Cache konfiguriert haben, überprüfen Sie, ob sich die öffentliche IP-Adresse Ihres Cache geändert hat. Weitere Informationen finden Sie unter Verwenden des Hostnamens und nicht der öffentlichen IP-Adresse für Ihren Cache.

Georeplikation mit VNet-Injektion mit Premium-Caches

Obwohl es möglich ist, die VNet-Einfügung mit Ihren Premium-Caches zu verwenden, empfehlen wir Azure Private Link.

Weitere Informationen finden Sie unter:

Die Georeplikation von Caches in VNets wird mit Einschränkungen unterstützt:

  • Es wird Unterstützung für die Georeplikation zwischen Caches im selben VNet geboten.
  • Die Georeplikation zwischen Caches in unterschiedlichen VNets wird ebenfalls unterstützt.
    • Wenn sich die VNets in derselben Region befinden, können Sie sie per VNet-Peering oder per VPN Gateway-VNet-zu-VNet-Verbindung verbinden.
    • Wenn sich die VNets in verschiedenen Regionen befinden, wird die Georeplikation mithilfe von VNet-Peering nicht unterstützt. Ein Client-VM in VNet 1 (Region 1) kann aufgrund einer Einschränkung beim internen Lastenausgleich im Tarif „Basic“ nicht über seinen DNS-Namen auf den Cache in VNet 2 (Region 2) zugreifen. Weitere Informationen zu Einschränkungen beim VNet-Peering finden Sie im Artikel zu den Anforderungen und Einschränkungen beim VNet-Peering. Es wird empfohlen, eine VPN Gateway-VNet-zu-VNet-Verbindung zu verwenden.

Um Ihr VNet effektiv zu konfigurieren und Probleme bei der Georeplikation zu vermeiden, müssen Sie sowohl die eingehenden als auch die ausgehenden Ports richtig konfigurieren. Weitere Informationen zum Vermeiden der häufigsten VNet-Fehlkonfigurationen finden Sie unter Anforderungen an Peer-Ports für die Georeplikation.

Verwandte Inhalte

Die folgenden Artikel enthalten weitere Informationen zu Konnektivität und Resilienz: