Teilen über

Konfigurieren der Unterstützung virtueller Netzwerke (VNet) einer Azure Cache for Redis-Instanz vom Typ „Premium“

  • Artikel

Die Bereitstellung über Azure Virtual Network bietet für Subnetze ein höheres Maß an Sicherheit und Isolation. Sie profitieren außerdem von Richtlinien für die Zugriffssteuerung sowie von weiteren Features zur Begrenzung des Zugriffs. Wenn eine Azure Cache for Redis-Instanz mit einem virtuellen Netzwerk konfiguriert ist, ist sie nicht öffentlich adressierbar. Stattdessen kann nur von virtuellen Computern und Anwendungen innerhalb des virtuellen Netzwerks auf die Instanz zugegriffen werden. In diesem Artikel erfahren Sie, wie Sie die Unterstützung eines virtuellen Netzwerks für eine Azure Cache for Redis-Instanz im Premium-Tarif konfigurieren.

Hinweis

Das klassische Bereitstellungsmodell wird im August 2024 eingestellt. Weitere Informationen finden Sie unter Bereitstellungsmodell „Cloud Services (klassisch)“ wird am 31. August 2024 außer Betrieb genommen.

Wichtig

Azure Cache for Redis empfiehlt die Verwendung von Azure Private Link, wodurch die Netzwerkarchitektur vereinfacht und die Verbindung zwischen Endpunkten in Azure geschützt wird. Sie können aus Ihrem virtuellen Netzwerk über einen privaten Endpunkt, dem eine private IP-Adresse in einem Subnetz innerhalb des virtuellen Netzwerks zugewiesen ist, eine Verbindung mit einer Azure Cache-Instanz herstellen. Azure Private Link wird in allen unseren Tarifen angeboten, umfasst Azure Policy-Unterstützung sowie eine vereinfachte Netzwerksicherheitsgruppen-Regelverwaltung. Weitere Informationen finden Sie unter Dokumentation zu Private Link. Informationen zum Migrieren Ihrer in das VNet eingeschleusten Caches zu Private Link finden Sie unter Migrieren von VNet-Einschleusungscaches zu Private Link-Caches.

Einschränkungen der VNet-Injektion

  • Das Erstellen und Verwalten von Konfigurationen virtueller Netzwerke ist häufig fehleranfällig. Auch die Problembehandlung ist eine Herausforderung. Falsche Konfigurationen virtueller Netzwerke können zu Problemen führen:
    • blockierte Metrikübertragung von Ihren Cache-Instanzen
    • Fehler des Replikatknotens beim Replizieren von Daten vom primären Knoten
    • potenzieller Datenverlust
    • Fehler bei Verwaltungsvorgängen wie Skalierung
    • in den schwerwiegendsten Szenarien: Verlust der Verfügbarkeit
  • In VNet eingefügte Caches sind nur für Azure Cache for Redis Premium verfügbar, nicht in anderen Dienstebenen.
  • Wenn Sie einen in das VNet eingefügten Cache verwenden, müssen Sie Ihr VNet ändern, um Abhängigkeiten wie CRLs/PKI, AKV, Azure Storage, Azure Monitor und mehr zwischenzuspeichern.
  • Sie können keine vorhandene Azure Cache for Redis-Instanz in eine Virtual Network-Instanz einfügen. Sie müssen diese Option auswählen, wenn Sie den Cache erstellen.

Einrichten der Unterstützung für virtuelle Netzwerke

Die Unterstützung für ein virtuelles Netzwerk wird während der Erstellung des Caches auf dem Blatt Neue Azure Cache for Redis-Instanz konfiguriert.

  1. Melden Sie sich zum Erstellen einer Azure Cache for Redis-Instanz im Premium-Tarif beim Azure-Portal an, und wählen Sie Ressource erstellen aus. Sie können sie auch mithilfe von Resource Manager-Vorlagen, PowerShell oder der Azure CLI erstellen. Informationen über das Erstellen einer Azure Cache for Redis-Instanz finden Sie unter Erstellen eines Caches.

    Screenshot: Option „Ressource erstellen“.

  2. Wählen Sie auf der Seite Neu die Option Datenbanken aus. Wählen Sie dann Azure Cache for Redis aus.

    Screenshot: Auswählen von „Azure Cache for Redis“.

  3. Konfigurieren Sie auf der Seite Neuer Redis Cache die Einstellungen für die neue Cache-Instanz im Premium-Tarif.

    Einstellung Vorgeschlagener Wert BESCHREIBUNG
    DNS-Name Geben Sie einen global eindeutigen Namen ein. Der Cachename muss zwischen 1 und 63 Zeichen lang sein und darf nur Ziffern, Buchstaben und Bindestriche enthalten. Der Name muss mit einer Zahl oder einem Buchstaben beginnen und enden und darf keine aufeinanderfolgenden Bindestriche enthalten. Der Hostname Ihrer Cache-Instanz ist \<DNS name>.redis.cache.windows.net.
    Abonnement Wählen Sie in der Dropdownliste Ihr Abonnement aus. Das Abonnement, unter dem diese neue Azure Cache for Redis-Instanz erstellt wird.
    Ressourcengruppe Wählen Sie eine Ressourcengruppe in der Dropdownliste oder Neu erstellen aus, und geben Sie einen Namen für eine neue Ressourcengruppe ein. Der Name der Ressourcengruppe, in der Ihr Cache und weitere Ressourcen erstellt werden. Wenn Sie alle Ihre App-Ressourcen in einer Ressourcengruppe zusammenfassen, können Sie sie einfacher gemeinsam verwalten oder löschen.
    Location Wählen Sie in der Dropdownliste einen Standort aus. Wählen Sie eine Region in der Nähe anderer Dienste aus, die Ihren Cache verwenden.
    Cachetyp Wählen Sie in der Dropdown Liste eine Cache-Instanz im Premium-Tarif aus, um Features im Premium-Tarif zu konfigurieren. Weitere Informationen finden Sie unter Azure Cache for Redis – Preise. Der Tarif bestimmt Größe, Leistung und verfügbare Features für den Cache. Weitere Informationen finden Sie unter Azure Cache for Redis.

  4. Wählen Sie die Registerkarte Netzwerk oder unten auf der Seite die Schaltfläche Netzwerk aus.

  5. Wählen Sie auf der Registerkarte Netzwerk die Option Virtuelle Netzwerke als Konnektivitätsmethode aus. Um ein neues virtuelles Netzwerk verwenden zu können, müssen Sie es zuerst erstellen. Befolgen Sie dazu die Anleitungen unter Erstellen eines virtuellen Netzwerks über das Azure-Portal und Erstellen eines virtuellen Netzwerks (klassisch) über das Azure-Portal. Kehren Sie anschließend zum Bereich Neue Azure Cache for Redis-Instanz zurück, um Ihre Cache-Instanz im Premium-Tarif zu erstellen und zu konfigurieren.

    Wichtig

    Wenn Sie Azure Cache for Redis in einem virtuellen Netzwerk unter Resource Manager bereitstellen muss sich der Cache in einem dedizierten Subnetz befinden, das keine anderen Ressourcen außer Azure Cache for Redis-Instanzen enthält. Wenn Sie versuchen, eine Azure Cache for Redis-Instanz in einem virtuellen Resource Manager-Subnetz bereitzustellen, das andere Ressourcen enthält, oder dem ein NAT Gateway zugewiesen ist, tritt bei der Bereitstellung ein Fehler auf. Der Fehler wird dadurch verursacht, dass Azure Cache for Redis Load Balancer Basic verwendet, der mit einem NAT Gateway nicht kompatibel ist.

    Einstellung Vorgeschlagener Wert BESCHREIBUNG
    Virtuelles Netzwerk Wählen Sie Ihr virtuelles Netzwerk in der Dropdownliste aus. Wählen Sie ein virtuelles Netzwerk aus, das sich im selben Abonnement und am selben Standort befindet wie der Cache.
    Subnetz Wählen Sie Ihr Subnetz in der Dropdownliste aus. Der Adressbereich des Subnetzes in CIDR-Schreibweise (z. B. 192.168.1.0/24). Er muss innerhalb des Adressraums des virtuellen Netzwerks liegen.
    Statische IP-Adresse (Optional) Geben Sie eine statische IP-Adresse ein. Wenn Sie keine statische IP-Adresse angeben, wird automatisch eine IP-Adresse ausgewählt.

    Wichtig

    Einige IP-Adressen innerhalb jedes Subnetzes sind in Azure reserviert und können deshalb nicht genutzt werden. Die erste und letzte IP-Adresse der Subnetze sind aus Gründen der Protokollkonformität reserviert. Darüber hinaus sind drei weitere für Azure-Dienste verwendete IP-Adressen reserviert. Weitere Informationen finden Sie unter Unterliegen die in den Subnetzen verwendeten IP-Adressen bestimmten Beschränkungen?.

    Zusätzlich zu den IP-Adressen, die von der virtuellen Azure-Netzwerkinfrastruktur verwendet werden, nutzt jede Azure Cache for Redis-Instanz im Subnetz zwei IP-Adressen pro Shard und eine zusätzliche IP-Adresse für den Lastenausgleich. Ein nicht gruppierter Cache hat definitionsgemäß einen Shard.

  6. Wählen Sie unten auf der Seite die Schaltfläche Next: Erweitert aus, oder wählen Sie die Schaltfläche Weiter: Erweitert unten auf der Seite aus.

  7. Konfigurieren Sie auf der Registerkarte Erweitert für eine Cache-Instanz im Premium-Tarif die Einstellungen für einen Nicht-TLS-Port sowie für Clustering und Datenpersistenz.

  8. Wählen Sie unten auf der Seite die Schaltfläche Next: Tags aus, oder wählen Sie die Schaltfläche Weiter: Tags (Weiter: Tags) aus.

  9. Geben Sie optional auf der Registerkarte Tags den Namen und den Wert ein, wenn Sie die Ressource kategorisieren möchten.

  10. Klicken Sie auf Überprüfen und erstellen. Sie werden zur Registerkarte Überprüfen und erstellen weitergeleitet, auf der Azure Ihre Konfiguration überprüft.

  11. Wenn die grüne Meldung Validierung erfolgreich angezeigt wird, wählen Sie Erstellen aus.

Es dauert eine Weile, bis der Cache erstellt wird. Sie können den Fortschritt auf der Seite Übersicht von Azure Cache for Redis überwachen. Wenn Wird ausgeführt als Status angezeigt wird, ist der Cache einsatzbereit. Nachdem der Cache erstellt wurde, können Sie die Konfiguration für das virtuelle Netzwerk anzeigen, indem Sie im Ressourcenmenü die Option Virtuelles Netzwerk auswählen.

Virtuelles Netzwerk

Azure Cache for Redis und virtuelle Netzwerke: häufig gestellte Fragen

Die folgende Liste enthält Antworten auf häufig gestellte Fragen zur Netztechnologie von Azure Cache for Redis.

Welche Probleme treten häufig bei einer fehlerhaften Konfiguration von Azure Cache for Redis und virtuellen Netzwerken auf?

Beim Hosten von Azure Cache for Redis in einem virtuellen Netzwerk werden die in den folgenden Tabellen angegebenen Ports verwendet.

Wichtig

Wenn diese Ports gesperrt sind, funktioniert der Cache möglicherweise nicht ordnungsgemäß. Eine bestehende Sperre für mindestens einen dieser Ports ist die häufigste Fehlkonfiguration, die beim Verwenden von Azure Cache for Redis in einem virtuellen Netzwerk auftritt.

Anforderungen für ausgehende Ports

Es liegen Anforderungen für neun ausgehende Ports vor. Ausgehende Anforderungen in diesen Bereichen sind entweder: a) ausgehend zu anderen Diensten, die erforderlich sind, damit der Cache funktioniert, oder b) intern an das Redis-Subnetz für die Kommunikation zwischen Knoten gerichtet. Bei der Georeplikation liegen weitere Anforderungen an ausgehenden Datenverkehr für die Kommunikation zwischen Subnetzen des primären Caches und des Replikatcaches vor.

Ports Direction Transportprotokoll Zweck Lokale IP Remote-IP
80, 443 Ausgehend TCP Redis-Abhängigkeiten von Azure Storage/PKI (Internet) (Redis-Subnetz) * 4
443 Ausgehend TCP Redis-Abhängigkeit von Azure Key Vault und Azure Monitor (Redis-Subnetz) AzureKeyVault, AzureMonitor 1
53 Ausgehend TCP/UDP Redis-Abhängigkeiten von DNS (Internet/virtuelles Netzwerk) (Redis-Subnetz) 168.63.129.16 und 169.254.169.254 2 und jeder benutzerdefinierte DNS-Server für das Subnetz 3
8443 Ausgehend TCP Interne Kommunikation für Redis (Redis-Subnetz) (Redis-Subnetz)
10221-10231 Ausgehend TCP Interne Kommunikation für Redis (Redis-Subnetz) (Redis-Subnetz)
20226 Ausgehend TCP Interne Kommunikation für Redis (Redis-Subnetz) (Redis-Subnetz)
13000-13999 Ausgehend TCP Interne Kommunikation für Redis (Redis-Subnetz) (Redis-Subnetz)
15000-15999 Ausgehend TCP Interne Kommunikation für Redis und Georeplikation (Redis-Subnetz) (Redis-Subnetz) (Georeplikat pro Subnetz)
6379-6380 Ausgehend TCP Interne Kommunikation für Redis (Redis-Subnetz) (Redis-Subnetz)

1 Sie können die Diensttags AzureKeyVault und AzureMonitor mit Resource Manager-Netzwerksicherheitsgruppen (NSGs) verwenden.

2 Diese IP-Adressen im Besitz von Microsoft werden für die Host-VM verwendet, die Azure DNS bereitstellt.

3 Diese Information ist für Subnetze ohne benutzerdefinierten DNS-Server oder neuere Redis Cache-Instanzen, die benutzerdefiniertes DNS ignorieren, nicht erforderlich.

4 Weitere Informationen finden Sie unter Zusätzliche VNET-Netzwerkverbindungsanforderungen.

Anforderungen an Peer-Ports für die Georeplikation

Wenn Sie die Georeplikation zwischen Caches in virtuellen Azure-Netzwerken verwenden, heben Sie a) die Sperrung der Ports 15000-15999 für das gesamte Subnetz in eingehender und ausgehender Richtung und b) für beide Caches auf. Mit dieser Konfiguration können alle Replikatkomponenten im Subnetz auch bei einem zukünftigen geografischen Failover direkt miteinander kommunizieren.

Anforderungen für eingehende Ports

Es liegen Anforderungen für acht eingehende Portbereiche vor. Eingehende Anforderungen in diesen Bereichen gehen entweder von anderen im gleichen virtuellen Netzwerk gehosteten Diensten ein. Andernfalls sind sie intern für die Redis-Subnetzkommunikation.

Ports Direction Transportprotokoll Zweck Lokale IP Remote-IP
6379, 6380 Eingehend TCP Clientkommunikation mit Redis, Azure-Lastenausgleich (Redis-Subnetz) (Redis-Subnetz), (Clientsubnetz), AzureLoadBalancer 1
8443 Eingehend TCP Interne Kommunikation für Redis (Redis-Subnetz) (Redis-Subnetz)
8500 Eingehend TCP/UDP Azure-Lastenausgleich (Redis-Subnetz) AzureLoadBalancer
10221-10231 Eingehend TCP Clientkommunikation mit Redis-Clustern, interne Kommunikation für Redis (Redis-Subnetz) (Redis-Subnetz), (Clientsubnetz), AzureLoadBalancer
13000-13999 Eingehend TCP Clientkommunikation mit Redis-Clustern, Azure-Lastenausgleich (Redis-Subnetz) (Redis-Subnetz), (Clientsubnetz), AzureLoadBalancer
15000-15999 Eingehend TCP Clientkommunikation mit Redis-Clustern, Azure-Lastenausgleich und Georeplikation (Redis-Subnetz) (Redis-Subnetz), (Clientsubnetz), AzureLoadBalancer, (Peersubnetz des Georeplikats)
16001 Eingehend TCP/UDP Azure-Lastenausgleich (Redis-Subnetz) AzureLoadBalancer
20226 Eingehend TCP Interne Kommunikation für Redis (Redis-Subnetz) (Redis-Subnetz)

1 Sie können für die Erstellung der NSG-Regeln das Diensttag AzureLoadBalancer für Resource Manager oder AZURE_LOADBALANCER für das klassische Bereitstellungsmodell verwenden.

Zusätzliche Verbindungsanforderungen für virtuelle Netzwerke

Manche Netzwerkverbindungsanforderungen für Azure Cache for Redis können möglicherweise anfänglich nicht von einem virtuellen Netzwerk erfüllt werden. Azure Cache for Redis erfordert bei Verwendung in einem virtuellen Netzwerk, dass alle folgenden Voraussetzungen erfüllt sind:

  • Ausgehende Netzwerkverbindungen mit Azure Key Vault-Endpunkten in der ganzen Welt. Azure Key Vault-Endpunkte werden unter der DNS-Domäne vault.azure.net aufgelöst.
  • Ausgehende Netzwerkverbindungen mit Azure-Speicherendpunkten in der ganzen Welt. Endpunkte, die sich in derselben Region wie die Azure Cache for Redis-Instanz befinden, und Speicherendpunkte in anderen Azure-Regionen. Azure Storage-Endpunkte werden unter den folgenden DNS-Domänen aufgelöst: table.core.windows.net, blob.core.windows.net, queue.core.windows.net und file.core.windows.net.
  • Ausgehende Netzwerkkonnektivität zu ocsp.digicert.com, crl4.digicert.com, ocsp.msocsp.com, mscrl.microsoft.com, crl3.digicert.com, cacerts.digicert.com, oneocsp.microsoft.com und crl.microsoft.com. Diese Verbindungen sind zur Unterstützung von TLS-/SSL-Funktionen erforderlich.
  • Die DNS-Konfiguration für das virtuelle Netzwerk muss alle der zuvor genannten Endpunkte und Domänen auflösen können. Diese DNS-Anforderungen können erfüllt werden, indem Sie sicherstellen, dass eine gültige DNS-Infrastruktur für das virtuelle Netzwerk konfiguriert und beibehalten wird.
  • Ausgehende Netzwerkkonnektivität mit den folgenden Azure Monitor-Endpunkten, die sich unter den folgenden DNS-Domänen auflösen: shoebox2-black.shoebox2.metrics.nsatc.net, north-prod2.prod2.metrics.nsatc.net, azglobal-black.azglobal.metrics.nsatc.net, shoebox2-red.shoebox2.metrics.nsatc.net, east-prod2.prod2.metrics.nsatc.net, azglobal-red.azglobal.metrics.nsatc.net, shoebox3.prod.microsoftmetrics.com, shoebox3-red.prod.microsoftmetrics.com, shoebox3-black.prod.microsoftmetrics.com, azredis-red.prod.microsoftmetrics.com und azredis-black.prod.microsoftmetrics.com.

Wie kann ich sicherstellen, dass mein Cache in einem virtuellen Netzwerk funktioniert?

Wichtig

Wenn Sie eine Verbindung mit einer Azure Cache for Redis-Instanz herstellen, die in einem virtuellen Netzwerk gehostet wird, müssen sich Ihre Cacheclients im selben virtuellen Netzwerk befinden oder in einem virtuellen Netzwerk, in dem das Peering virtueller Netzwerke innerhalb der gleichen Azure-Region aktiviert ist. Globales Peering virtueller Netzwerke wird zurzeit nicht unterstützt. Diese Anforderung schließt alle Testanwendungen oder Diagnosepingtools ein. Unabhängig davon, wo die Clientanwendung gehostet wird, müssen NSGs oder andere Netzwerkschichten so konfiguriert sein, dass der Netzwerkdatenverkehr des Clients die Azure Cache for Redis-Instanz erreichen kann.

Nachdem die Portanforderungen wie im vorherigen Abschnitt beschrieben konfiguriert wurden, ist in den meisten Fällen ein Neustart erforderlich, um sicherzustellen, dass die Änderungen korrekt übernommen werden. Andernfalls treten möglicherweise Konnektivitätsprobleme auf. Sie können überprüfen, ob Ihr Cache funktioniert, indem Sie die folgenden Schritte ausführen:

  • Starten Sie alle Cacheknoten neu. Der Cache kann nicht neu gestartet werden, wenn keine der erforderlichen Cacheabhängigkeiten wie unter Anforderungen für eingehende Ports und Anforderungen für ausgehende Ports dokumentiert erreicht werden kann.
  • Nachdem die Cacheknoten wie durch den Cachestatus im Azure-Portal gemeldet neu gestartet wurden, können Sie folgende Tests durchführen:

    • Pingen Sie mit tcping den Cacheendpunkt über Port 6380 von einem Computer, der sich im selben virtuellen Netzwerk wie der Cache befindet. Beispiel:

      tcping.exe contosocache.redis.cache.windows.net 6380

      Wenn das Tool tcping meldet, dass der Port geöffnet ist, ist der Cache für die Verbindung über Clients im virtuellen Netzwerk verfügbar.

    • Eine andere Testmöglichkeit: Erstellen Sie einen Testcacheclient, der eine Verbindung mit dem Cache herstellt und dann dem Cache einige Elemente hinzufügt und einige daraus abruft. Der Testcacheclient könnte eine Konsolenanwendung sein, die StackExchange.Redis verwendet. Installieren Sie die Beispielclientanwendung auf einer VM, die sich im gleichen virtuellen Netzwerk wie der Cache befindet. Führen Sie sie anschließend aus, um die Konnektivität zum Cache zu überprüfen.

Warum erhalte ich beim Versuch, eine Verbindung mit Azure Cache for Redis in einem virtuellen Netzwerk herzustellen, die Fehlermeldung, dass das Remotezertifikat ungültig sei?

Beim Versuch, eine Verbindung mit einer Azure Cache for Redis-Instanz in einem virtuellen Netzwerk herzustellen, wird ein Zertifikatvalidierungsfehler wie dieser angezeigt:

{"No connection is available to service this operation: SET mykey; The remote certificate is invalid according to the validation procedure.; …"}

Die Ursache könnte sein, dass Sie sich über die IP-Adresse mit dem Host verbinden. Sie sollten den Hostnamen verwenden. Verwenden Sie also folgende Zeichenfolge:

[mycachename].redis.cache.windows.net:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

Vermeiden Sie die Verwendung einer IP-Adresse, die der folgenden Verbindungszeichenfolge ähnelt:

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

Wenn Sie den DNS-Namen nicht auflösen können, enthalten einige Clientbibliotheken Konfigurationsoptionen wie sslHost, die vom StackExchange.Redis-Client bereitgestellt werden. Mit dieser Option können Sie den für die Zertifikatsvalidierung verwendeten Hostnamen überschreiben. Beispiel:

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False;sslHost=[mycachename].redis.cache.windows.net

Kann ich virtuelle Netzwerke mit einem Standard-Cache oder Basic-Cache verwenden?

Virtuelle Netzwerke können nur für Cache-Instanzen im Premium-Tarif verwendet werden.

Warum tritt beim Erstellen einer Azure Cache for Redis-Instanz in einigen Subnetzen ein Fehler auf, aber in anderen nicht?

Wenn Sie eine Azure Cache for Redis-Instanz in einem virtuellen Netzwerk bereitstellen, muss sich der Cache in einem dedizierten Subnetz befinden, das keine anderen Ressourcentypen enthält. Wird versucht, eine Azure Cache for Redis-Instanz in einem virtuellen Subnetz unter Resource Manager bereitzustellen, das andere Ressourcen wie Azure Application Gateway-Instanzen und ausgehende NAT enthält, tritt bei der Bereitstellung in der Regel ein Fehler auf. Löschen Sie die vorhandenen anderen Ressourcentypen, bevor Sie eine neue Azure Cache for Redis-Instanz erstellen.

Außerdem müssen Sie über genügend IP-Adressen im Subnetz verfügen.

Welche Anforderungen gelten für den Subnetzadressraum?

Einige IP-Adressen innerhalb jedes Subnetzes sind in Azure reserviert und können deshalb nicht genutzt werden. Die erste und letzte IP-Adresse der Subnetze sind aus Gründen der Protokollkonformität reserviert. Darüber hinaus sind drei weitere für Azure-Dienste verwendete IP-Adressen reserviert. Weitere Informationen finden Sie unter Unterliegen die in den Subnetzen verwendeten IP-Adressen bestimmten Beschränkungen?

Zusätzlich zu den IP-Adressen, die von der virtuellen Azure-Netzwerkinfrastruktur verwendet werden, nutzt jede Azure Cache for Redis-Instanz im Subnetz zwei IP-Adressen pro Clustershard und ggf. IP-Adressen für zusätzliche Replikate. Für den Lastenausgleich wird eine weitere IP-Adresse verwendet. Ein nicht gruppierter Cache hat definitionsgemäß einen Shard.

Kann ich über ein virtuelles Netzwerk mit Peering eine Verbindung mit meinem Cache herstellen?

Wenn sich die VNETs in derselben Region befinden, können Sie sie per VNET-Peering oder VPN Gateway-VNET-zu-VNET-Verbindung verbinden.

Wenn sich die mittels Peering verbundenen virtuellen Azure-Netzwerke in unterschiedlichen Regionen befinden: Eine Client-VM in Region 1 kann aufgrund einer Einschränkung bei Load Balancer Basic-Instanzen nicht über ihre IP-Adresse mit Lastenausgleich auf den Cache in Region 2 zugreifen. Es sei denn, es handelt sich um einen Cache mit einer Load Balancer Standard-Instanz, der derzeit nur ein Cache ist, der mit Verfügbarkeitszonen erstellt wurde.

Weitere Informationen zu Einschränkungen beim VNET-Peering finden Sie unter „Virtuelles Netzwerk – Peering – Anforderungen und Einschränkungen“. Eine Lösung wäre, anstelle des Peerings virtueller Netzwerke eine VPN Gateway-VNET-zu-VNET-Verbindung zu verwenden.

Funktionieren alle Cachefeatures, wenn ein Cache in einem virtuellen Netzwerk gehostet wird?

Wenn der Cache Teil eines virtuellen Netzwerks ist, haben nur Clients im virtuellen Netzwerk Zugriff auf den Cache. Daher stehen zurzeit in diesem Fall folgende Cacheverwaltungsfunktionen nicht zur Verfügung:

  • Redis-Konsole: Da die Redis-Konsole in Ihrem lokalen Browser ausgeführt wird – der sich in der Regel auf einem Entwicklercomputer befindet, der nicht mit dem virtuellen Netzwerk verbunden ist – kann keine Verbindung mit dem Cache hergestellt werden.

Wird die VNet-Einschleusung in einem Cache unterstützt, in dem Azure Lighthouse aktiviert ist?

Nein, wenn Für Ihr Abonnement Azure Lighthouse aktiviert ist, können Sie die VNet-Einschleusung nicht für eine Azure Cache for Redis-Instanz verwenden. Verwenden Sie stattdessen private Verbindungen.

Verwenden von ExpressRoute mit Azure Cache for Redis

Kunden können eine Azure ExpressRoute-Verbindung mit der Infrastruktur ihres virtuellen Netzwerks herstellen. Auf diese Weise erweitern sie das lokale Netzwerk auf Azure.

Standardmäßig verwendet eine neu erstellte ExpressRoute-Verbindung in einem virtuellen Netzwerk kein erzwungenes Tunneling (Ankündigung einer Standardroute, 0.0.0.0/0). Daher ist die ausgehende Internetkonnektivität direkt aus dem virtuellen Netzwerk zulässig. Clientanwendungen können eine Verbindung mit anderen Azure-Endpunkten einschließlich einer Azure Cache for Redis-Instanz herstellen.

Eine gängige Kundenkonfiguration sieht die Verwendung eines erzwungenen Tunnelings (Ankündigung einer Standardroute) vor, das ausgehenden Internetdatenverkehr stattdessen zwingt, die lokale Infrastruktur zu durchlaufen. Dieser Datenverkehrsfluss unterbricht die Verbindung mit Azure Cache for Redis, wenn der ausgehende Datenverkehr anschließend lokal so blockiert wird, dass die Azure Cache for Redis-Instanz nicht mit ihren Abhängigkeiten kommunizieren kann.

Die Lösung besteht darin, mindestens eine benutzerdefinierte Route (User-Defined Routes, UDRs) in dem Subnetz zu definieren, in dem sich die Azure Cache for Redis-Instanz befindet. Eine benutzerdefinierte Route definiert subnetzspezifische Routen, die anstelle der Standardroute berücksichtigt werden.

Verwenden Sie wenn möglich die folgende Konfiguration:

  • Die ExpressRoute-Konfiguration kündigt 0.0.0.0/0 an und tunnelt standardmäßig allen ausgehenden Datenverkehr zwangsweise lokal.
  • Die für das Subnetz mit der Azure Cache for Redis-Instanz geltende benutzerdefinierte Route definiert 0.0.0.0/0 mit einer funktionierenden Route für TCP/IP-Datenverkehr zum öffentlichen Internet. Beispielsweise wird der Typ des nächsten Hops auf internetfestgelegt.

Gemeinsam führen diese Schritte dazu, dass die benutzerdefinierte Route auf Subnetzebene Vorrang vor erzwungenen ExpressRoute-Tunneln hat. Dadurch wird ausgehender Internetzugriff aus der Azure Cache for Redis-Instanz sichergestellt.

Das Herstellen einer Verbindung mit einer Azure Cache for Redis-Instanz aus einer lokalen Anwendung mithilfe von ExpressRoute ist aus Leistungsgründen kein typisches Verwendungsszenario. Um die optimale Leistung zu erzielen, sollten Azure Cache for Redis-Clients sich in der gleichen Region wie die Azure Cache for Redis-Instanz befinden.

Wichtig

Die in einer UDR definierten Routen müssen ausreichend spezifisch sein, damit sie Vorrang vor allen von der ExpressRoute-Konfiguration angekündigten Routen erhalten. Im folgenden Beispiel wird der allgemeine Adressbereich 0.0.0.0/0 verwendet, der durch Routenankündigungen mit spezifischeren Adressbereichen versehentlich überschrieben werden kann.

Warnung

Azure Cache for Redis wird nicht mit ExpressRoute-Konfigurationen unterstützt, die fälschlicherweise Routen „über Kreuz“ vom öffentlichen Peeringpfad zum privaten Peeringpfad ankündigen. ExpressRoute-Konfigurationen, für die öffentliches Peering konfiguriert ist, erhalten Routenankündigungen von Microsoft für zahlreiche Microsoft Azure-IP-Adressbereiche. Werden diese Adressbereiche fälschlicherweise „über Kreuz“ im privaten Peeringpfad angekündigt, führt dies dazu, dass alle ausgehenden Netzwerkpakete aus dem Subnetz der Azure Cache for Redis-Instanz fälschlicherweise erzwungenermaßen zur lokalen Netzwerkinfrastruktur eines Kunden getunnelt werden. Dieser Netzwerkdatenfluss unterbricht Azure Cache for Redis. Die Lösung für dieses Problem besteht darin, „Über-Kreuz-Ankündigungen“ von Routen vom öffentlichen Peeringpfad zum privaten Peeringpfad zu verhindern.

Hintergrundinformationen zu UDRs finden Sie in Routing von Datenverkehr für virtuelle Netzwerke.

Weitere Informationen über ExpressRoute finden Sie unter ExpressRoute – technische Übersicht.

Zugehöriger Inhalt

Erfahren Sie mehr über Azure Cache for Redis-Features.