Freigeben über

Konfigurieren der Georeplikation für Azure Cache for Redis-Instanzen (Premium-Tarif)

  • Artikel

In diesem Artikel erfahren Sie, wie man mithilfe des Azure-Portals die passive Georeplikation für ein Paar von Azure Cache for Redis-Instanzen konfiguriert.

Die passive Georeplikation verknüpft zwei Azure Cache for Redis-Instanzen (Premium-Tarif) und erstellt eine aktiv/passive Datenreplikationsbeziehung. Aktiv/Passiv bedeutet, dass es ein Paar von Caches (primär und sekundär) gibt, für die die Daten synchronisiert werden. Man kann jedoch nur auf eine Seite des Paares schreiben, die primäre. Die andere Seite des Paares, der sekundäre Cache, ist schreibgeschützt.

Vergleichen Sie Aktiv/Passiv mit Aktiv/Aktiv, wo Sie auf eine Seite des Paars schreiben können, und diese mit der anderen Seite synchronisiert wird.

Bei der passiven Georeplikation befinden sich diese Cache-Instanzen normalerweise in unterschiedlichen Azure-Regionen, obwohl dies nicht erforderlich ist. Eine Instanz fungiert als primärer und die andere als sekundärer Cache. Der primäre Cache verarbeitet Lese- und Schreibanforderungen und der primäre gibt Änderungen an den sekundären weiter.

Ein Failover erfolgt nicht automatisch. Weitere Informationen zur Nutzung eines Failovers finden Sie unter Initiieren eines Failovers vom primären geografischen Standort zum sekundären geografischen Standort.

Hinweis

Die passive Georeplikation ist als Lösung für die Notfallwiederherstellung konzipiert.

Umfang der Verfügbarkeit

Tarif Basic, Standard Premium Enterprise, Enterprise Flash
Verfügbar Nein Ja Ja

Die passive Georeplikation ist nur im Premium-Tarif von Azure Cache for Redis verfügbar. Die Enterprise- und Enterprise Flash-Ebenen bieten auch Georeplikation, aber diese Ebenen verwenden eine erweiterte Version, die als aktive Georeplikation bezeichnet wird.

Voraussetzungen für die Georeplikation

Um die Georeplikation zwischen zwei Caches zu konfigurieren, müssen die folgenden Voraussetzungen erfüllt sein:

  • Für beide Caches gilt der Premium-Tarif.
  • Beide Caches müssen sich in demselben Azure-Abonnement befinden.
  • Der sekundäre verknüpfte Cache hat entweder die gleiche Größe oder ist größer als der primäre verknüpfte Cache. Für die Verwendung des Geofailovers müssen beide Caches die gleiche Größe aufweisen.
  • Beide Caches wurden erstellt und werden ausgeführt.
  • In beiden Caches wird die gleiche Version des Redis-Servers ausgeführt.

Hinweis

Die Datenübertragung zwischen Azure-Regionen wird mit den Standardbandbreitensätzen abgerechnet.

Einige Funktionen werden für die Georeplikation nicht unterstützt:

  • Für die Georeplikation wird Zonenredundanz nicht unterstützt.
  • Für die Georeplikation wird Persistenz nicht unterstützt.
  • Caches mit mehreren Replikaten können nicht georepliziert werden.
  • Das Clustering wird unterstützt, wenn für beide Caches das Clustering aktiviert ist und jeweils die gleiche Anzahl von Shards vorhanden ist.
  • Caches im gleichen Virtual Network (VNet) werden unterstützt.
  • Caches in unterschiedlichen VNets werden mit Einschränkungen unterstützt. Weitere Informationen finden Sie unter Kann ich die Georeplikation bei meinen Caches in einem VNet verwenden?.

Nach der Konfiguration der Georeplikation gelten folgende Einschränkungen für Ihr verknüpftes Cachepaar:

  • Der sekundäre verknüpfte Cache ist schreibgeschützt. Sie können daraus lesen, aber Sie können keine Daten darin schreiben. Falls Sie Daten aus der sekundären Geoinstanz lesen möchten, Wenn zwischen der primären und der sekundären Geoinstanz eine vollständige Datensynchronisierung stattfindet, werden von der sekundären Geoinstanz bei jedem für sie ausgeführten Redis-Vorgang Fehler ausgelöst, bis die vollständige Datensynchronisierung abgeschlossen ist. Die Fehler geben an, dass eine vollständige Datensynchronisierung ausgeführt wird. Außerdem werden die Fehler ausgelöst, wenn entweder die primäre oder die sekundäre Geoinstanz aktualisiert wird. Sie werden auch in einigen Neustartszenarien ausgelöst. Anwendungen, die Daten aus der sekundären Geoinstanz lesen, müssen so gestaltet sein, dass sie auf die primäre Geoinstanz ausweichen, wenn von der sekundären Geoinstanz solche Fehler ausgelöst werden.

  • Alle Daten, die vor dem Hinzufügen der Verknüpfung im sekundären verknüpften Cache enthalten waren, werden entfernt. Wenn die Georeplikation aber später entfernt wird, verbleiben die replizierten Daten im sekundären verknüpften Cache.

  • Sie können keinen dieser Caches skalieren, während die Caches verknüpft sind.

  • Sie können die Anzahl von Shards nicht ändern, wenn für den Cache das Clustering aktiviert ist.

  • Für keinen der Caches kann Persistenz aktiviert werden.

  • Der Export aus den Caches ist möglich.

  • Es ist nicht möglich, einen Import in den sekundären verknüpften Cache durchzuführen.

  • Sie können die verknüpften Caches oder die Ressourcengruppe, in denen diese enthalten sind, erst löschen, nachdem Sie die Verknüpfung der Caches aufgehoben haben. Weitere Informationen finden Sie unter Warum ist bei dem Versuch, meinen verknüpften Cache zu löschen, ein Fehler beim Vorgang aufgetreten?

  • Wenn sich die Caches in unterschiedlichen Regionen befinden, fallen für die Daten, die zwischen Regionen verschoben werden, Kosten für ausgehenden Netzwerkdatenverkehr an. Weitere Informationen finden Sie unter Wie viel kostet die Replikation meiner Daten über verschiedene Azure-Regionen hinweg?

  • Ein Failover erfolgt nicht automatisch. Sie müssen das Failover vom primären auf den sekundären verknüpften Cache starten. Weitere Informationen zur Nutzung eines Failovers finden Sie unter Initiieren eines Failovers vom primären geografischen Standort zum sekundären geografischen Standort.

  • Private Verbindungen können nicht zu Caches hinzugefügt werden, die bereits georepliziert sind. So fügen Sie einem georeplizierten Cache eine private Verbindung hinzu: 1. Heben Sie die Verknüpfung mit der Georeplikation auf. 2. Fügen Sie eine private Verbindung hinzu. 3. Verknüpfen Sie schließlich die Georeplikation erneut.

  1. Wählen Sie zum Verknüpfen von zwei Caches für die Georeplikation zuerst im Menü „Ressource“ des Caches, der als primärer verknüpfter Cache verwendet werden soll, die Option Georeplikation aus. Wählen Sie anschließend im Arbeitsbereich die Option Cache-Replikationslink hinzufügen aus.

    Screenshot: Menü „Georeplikation“ des Caches

  2. Klicken Sie in der Liste Kompatible Caches auf den Namen des gewünschten sekundären Caches. Wenn der sekundäre Cache nicht in der Liste angezeigt wird, sollten Sie sicherstellen, dass die Voraussetzungen für die Georeplikation für den sekundären Cache erfüllt sind. Klicken Sie zum Filtern der Caches nach Region auf der Karte auf die Region, um nur Caches in der Liste Kompatible Caches anzuzeigen.

    Screenshot: kompatible Caches für die Verknüpfung mit der Georeplikation

    Sie können mithilfe des Kontextmenüs auch den Verknüpfungsvorgang starten oder Details zum sekundären Cache anzeigen.

    Screenshot: Kontextmenü für die Georeplikation

  3. Klicken Sie auf Verknüpfen, um zwei Caches zu verknüpfen und den Replikationsvorgang zu starten.

    Screenshot: Verknüpfen von Caches für die Georeplikation

  4. Sie können den Status des Replikationsvorgangs mittels der Option Georeplikation im Menü „Ressourcen“ anzeigen.

    Screenshot des aktuellen Verknüpfungsstatus

    Sie können auch den Verbindungsstatus mittels der Option Übersicht im Menü „Ressourcen“ sowohl für den primären als auch den sekundären Cache anzeigen.

    Screenshot: Anzeigen des Verknüpfungsstatus für den primären Cache und sekundäre Caches.

    Nach Abschluss des Replikationsvorgangs wechselt der Link „Bereitstellungsstatus“ zu Erfolgreich.

    Screenshot: Cacheverknüpfungsstatus als Erfolgreich

    Der primäre verknüpfte Cache bleibt während des Verknüpfungsvorgangs für die Nutzung verfügbar. Der sekundäre verknüpfte Cache ist erst verfügbar, nachdem der Verknüpfungsvorgang abgeschlossen wurde.

URL im primären geografischen Standort

Sobald die Caches verknüpft sind, wird für jeden Cache eine URL generiert, die immer auf den primären Cache im geografischen Standort verweist. Wenn ein Failover vom geoprimären zum geosekundären Cache initiiert wird, bleibt die URL identisch, und der zugrunde liegende DNS-Eintrag wird automatisch aktualisiert, sodass er auf den neuen geoprimären Cache verweist.

Screenshot: Vier URLs, die durch Hinzufügen der Georeplikation erstellt wurden

Es werden drei URLs angezeigt:

  • Die geoprimäre URL ist eine Proxy-URL im Format <cachename>.geo.redis.cache.windows.net. Die URL verweist immer auf denjenigen Cache im Georeplikationspaar, welcher der aktuell primäre im geografischen Standort ist.
  • Der aktuelle geoprimäre Cache ist die direkte Adresse des Caches, der derzeit der geoprimäre ist. Die Adresse ist redis.cache.windows.net, nicht geo.redis.cache.windows.net. Die im Feld aufgeführte Adresse ändert sich, wenn ein Failover initiiert wird.
  • Der aktuelle geosekundäre Cache ist die direkte Adresse des Caches, der derzeit der geosekundäre ist. Die Adresse ist redis.cache.windows.net, nicht geo.redis.cache.windows.net. Die im Feld aufgeführte Adresse ändert sich, wenn ein Failover initiiert wird.

Initiieren eines Failovers von primären zum sekundären Cache im geografischen Standort

Mit einer Auswahl können Sie ein Failover vom primären auf den sekundären Cache im geografischen Standort auslösen.

Screenshot: verknüpfte Caches mit hervorgehobenem Failover

Dies führt dazu, dass die folgenden Schritte ausgeführt werden:

  1. Der geosekundäre Cache wird zum geoprimären heraufgestuft.
  2. DNS-Einträge werden aktualisiert, um die geoprimären URLs an den neuen geoprimären Cache umzuleiten.
  3. Der alte geoprimäre Cache wird zum sekundären heruntergestuft und versucht, einen Link zum neuen geoprimären Cache zu bilden.

Der Geo-Failoverprozess dauert einige Minuten.

Vor dem Initiieren des Geofailovers zu überprüfende Einstellungen

Wenn das Failover initiiert wird, tauschen die geoprimären und geosekundären Caches ihre Plätze. Wenn der neue geoprimäre Cache anders konfiguriert ist als der geosekundäre, kann dies Probleme für Ihre Anwendung verursachen.

Beachten Sie unbedingt folgende Punkte:

  • Wenn Sie in beiden Caches eine Firewall verwenden, stellen Sie sicher, dass die Firewalleinstellungen ähnlich sind, damit keine Verbindungsprobleme auftreten.
  • Stellen Sie sicher, dass beide Caches denselben Port und dieselben TLS/SSL-Einstellungen verwenden.
  • Die geoprimären und geosekundären Caches verfügen über unterschiedliche Zugriffsschlüssel. Wenn ein Failover ausgelöst wird, stellen Sie sicher, dass Ihre Anwendung den Zugriffsschlüssel aktualisieren kann, der verwendet wird, damit er mit dem neuen primären Cache im geografischen Standort übereinstimmt. Sie können auch Microsoft Entra-Token für die Cacheauthentifizierung verwenden, sodass Sie dieselben Anmeldeinformationen für die Authentifizierung sowohl für den geoprimären als auch für den geosekundären Cache verwenden können.

Failover mit minimalem Datenverlust

Geo-Failoverereignisse können während des Übergangs zu Dateninkonsistenzen führen, insbesondere, wenn der Client während des Failoverprozesses eine Verbindung mit dem alten geoprimären Cache aufrechterhält. Mit den folgenden Tipps können Sie bei einem geplanten Geo-Failoverereignis Datenverluste minimieren:

  • Überprüfen Sie die Metrik des Georeplikations-Datensynchronisierungsoffset. Die Metrik wird vom aktuellen geoprimären Cache ausgegeben. Diese Metrik gibt an, wie viele Daten noch zum geoprimären Cache repliziert werden müssen. Initiieren Sie nach Möglichkeit ein Failover nur, wenn die Metrik angibt, dass weniger als 14 Bytes geschrieben werden müssen.
  • Führen Sie den Befehl CLIENT PAUSE in der aktuellen geoprimären Instanz aus, bevor Sie das Failover initiieren. Das Ausführen von CLIENT PAUSE blockiert alle neuen Schreibanforderungen und gibt stattdessen Timeoutfehler an den Azure Cache for Redis-Client zurück. Der Befehl CLIENT PAUSE erfordert die Bereitstellung eines Timeoutzeitraums in Millisekunden. Stellen Sie sicher, dass ein ausreichend langer Timeoutzeitraum angegeben ist, um das Failover zu ermöglichen. Die Einstellung des Pausenwerts auf etwa 30 Minuten (1.800.000 Millisekunden) ist ein guter Ausgangswert. Sie können diese Zahl bei Bedarf immer senken.

Es ist nicht erforderlich, den Befehl CLIENT UNPAUSE auszuführen, da der neue geoprimäre Cache die Clientpause beibehält.

Hinweis

Die Verwendung der Microsoft Entra ID-basierten Authentifizierung für Ihren Cache wird in Geofailoverszenarien empfohlen, da die Schwierigkeit der Verwaltung verschiedener Zugriffsschlüssel für den geoprimären und den geosekundären Cache entfällt.

  1. Um die Verknüpfung zwischen zwei Caches zu entfernen und die Georeplikation zu beenden, wählen Sie links unter Georeplikation die Option Verknüpfung von Caches aufheben aus.

    Screenshot: Aufheben der Verknüpfung von Caches

    Wenn der Vorgang zur Aufhebung der Verknüpfung abgeschlossen ist, ist der sekundäre Cache für Lese- und Schreibvorgänge verfügbar.

Hinweis

Wenn die Verknüpfung für die Georeplikation entfernt wird, bleiben die replizierten Daten aus dem primären verknüpften Cache im sekundären Cache.

FAQs zur Georeplikation

Kann ich die Georeplikation bei einem Cache mit Standard- oder Basic-Tarif verwenden?

Nein, die passive Georeplikation ist nur im Premium-Tarif verfügbar. Eine erweiterte Version der Georeplikation mit dem Namen aktive Georeplikation ist im Enterprise- und Enterprise Flash-Tarif verfügbar.

Ist mein Cache während des Vorgangs zur Verknüpfung oder Aufhebung der Verknüpfung verfügbar?

  • Der primäre verknüpfte Cache bleibt verfügbar, bis der Verknüpfungsvorgang abgeschlossen wurde.
  • Der sekundäre verknüpfte Cache ist erst verfügbar, nachdem der Verknüpfungsvorgang abgeschlossen wurde.
  • Beide Caches bleiben verfügbar, bis die Aufhebung der Verknüpfung abgeschlossen wurde.

Wann kann ich nach dem Initiieren des Failovers in den neuen primären Cache im geografischen Standort schreiben?

Wenn der Failoverprozess initiiert wird, wird der Link für den Bereitstellungsstatus auf Löschen aktualisiert, was angibt, dass der vorherige Link bereinigt wird. Nachdem dies abgeschlossen ist, wird der Link für den Bereitstellungsstatus in Erstellen aktualisiert. Dies gibt an, dass der neue primäre Cache des geografischen Standorts ausgeführt wird und versucht, eine Georeplikationsverbindung mit dem alten primären Cache im geografischen Standort wie folgt einzurichten. An diesem Punkt können Sie sofort eine Verbindung mit der neuen primären Cache-Instanz im geografischen Standort für Lese- und Schreibvorgänge herstellen.

Ja, es stehen mehrere Metriken zur Verfügung, um den Status der Georeplikation nachzuverfolgen. Diese Metriken sind im Azure-Portal verfügbar.

  • Georeplikation fehlerfrei zeigt den Status des Georeplikationslinks an. Der Link wird als fehlerhaft angezeigt, wenn entweder der geoprimäre oder der geosekundäre Cache ausgefallen ist. Dies ist in der Regel auf Standardpatchvorgänge zurückzuführen, könnte aber auch auf eine Fehlersituation hinweisen.
  • Die Georeplikations-Konnektivitätsverzögerung zeigt die Zeit seit der letzten erfolgreichen Datensynchronisierung zwischen geoprimärem und geosekundärem Cache an.
  • Georeplikations-Datensynchronisierungsoffset zeigt die Datenmenge an, die noch mit dem geosekundären Cache synchronisiert werden muss.
  • Georeplikationsereignis zur vollständigen Synchronisierung gestartet zeigt an, dass eine vollständige Synchronisierungsaktion zwischen dem geoprimären und dem geosekundären Cache initiiert wurde. Dies tritt auf, wenn die Standardreplikation mit der Anzahl neuer Schreibvorgänge nicht Schritt halten kann.
  • Georeplikationsereignis zur vollständigen Synchronisierung beendet zeigt an, dass eine vollständige Synchronisierungsaktion abgeschlossen wurde.

Es gibt auch eine vorgefertigte Arbeitsmappe mit dem Namen Georeplikationsdashboard, die alle Integritätsmetriken der Georeplikation in einer Ansicht enthält. Die Verwendung dieser Ansicht wird empfohlen, da sie Informationen aggregiert, die nur von den primären oder sekundären Cache-Instanzen des geografischen Standorts ausgegeben werden.

Nein, Sie können nur zwei Caches miteinander verknüpfen, wenn Sie die passive Georeplikation verwenden. Die aktive Georeplikation unterstützt bis zu fünf verknüpfte Caches.

Nein, beide Caches müssen sich im selben Azure-Abonnement befinden.

Ja, solange der sekundäre verknüpfte Cache größer ist als der primäre verknüpfte Cache. Sie können das Failoverfeature jedoch nicht verwenden, wenn die Caches unterschiedlich groß sind.

Kann ich die Georeplikation mit aktiviertem Clustering verwenden?

Ja, solange beide Caches über dieselbe Anzahl von Shards verfügen.

Kann ich die Georeplikation bei meinen Caches in einem VNet verwenden?

In den meisten Fällen wird die Verwendung von Azure Private Link anstelle von VNet-Einbindung empfohlen. Weitere Informationen finden Sie unter Migrieren von VNet-Injektionscaches zu Private Link-Caches.

Obwohl es technisch immer noch möglich ist, VNet-Injektion beim Georeplizieren Ihrer Caches zu verwenden, empfehlen wir Azure Private Link.

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.

Weitere Informationen zur Unterstützung der Georeplikation mit VNets finden Sie unter Georeplikation mit VNet-Einfügung mit Premium-Caches.

Was ist der Replikationszeitplan für die Redis-Georeplikation?

Die Replikation ist fortlaufend und asynchron. Dies erfolgt nicht nach einem bestimmten Zeitplan. Alle Schreibvorgänge für die primäre Datenbank werden sofort und asynchron in der sekundären Datenbank repliziert.

Wie lange dauert die Georeplikation?

Die Replikation ist ein inkrementeller, asynchroner und kontinuierlicher Vorgang, und die in Anspruch genommene Zeit unterscheidet sich nicht wesentlich von der Latenz zwischen Regionen. Unter bestimmten Umständen muss für den sekundären Cache eine vollständige Synchronisierung der Daten aus der primären Datenbank erfolgen. Die Replikationszeit hängt in diesem Fall von vielen Faktoren ab, z. B. der Last im primären Cache, der verfügbaren Netzwerkbandbreite, der Wartezeit zwischen Regionen usw. Wir haben ermittelt, dass die Replikationsdauer für ein Georeplikationspaar mit 53 GB zwischen 5 und 10 Minuten betragen kann. Mithilfe der Metrik Geo Replication Data Sync Offset können Sie die Datenmenge, die noch repliziert werden muss, in Azure Monitor nachverfolgen.

Ist der Wiederherstellungspunkt für die Replikation garantiert?

Für Caches in einem georeplizierten Modus ist die Persistenz deaktiviert. Wenn die Verknüpfung eines Georeplikationspaars aufgehoben wird, z. bei einem vom Kunden initiierten Failover, werden die synchronisierten Daten des sekundären verknüpften Caches bis zu diesem Zeitpunkt beibehalten. In diesen Situationen wird kein Wiederherstellungspunkt garantiert.

Zum Erhalten eines Wiederherstellungspunkts können Sie einen Export aus einem der beiden Caches durchführen. Später können Sie dann einen Import in den primären verknüpften Cache durchführen.

Kann ich die Georeplikation mit PowerShell oder der Azure CLI verwalten?

Ja. Die Georeplikation kann über das Azure-Portal, PowerShell oder die Azure CLI verwaltet werden. Weitere Informationen finden Sie in den PowerShell-Dokumenten bzw. Azure CLI-Dokumenten.

Wie viel kostet die Replikation meiner Daten über verschiedene Azure-Regionen hinweg?

Wenn Sie die Georeplikation verwenden, werden Daten aus dem primären verknüpften Cache in den sekundären verknüpften Cache repliziert. Es fallen keine Gebühren für die Datenübertragung an, wenn sich die beiden verknüpften Caches in derselben Region befinden. Falls sich die beiden verknüpften Caches in unterschiedlichen Regionen befinden, entsprechen die Gebühren für die Datenübertragung den Kosten für ausgehenden Netzwerkdatenverkehr in beiden Regionen. Weitere Informationen finden Sie unter Bandbreite – Preisdetails.

Warum ist bei dem Versuch, meinen verknüpften Cache zu löschen, ein Fehler beim Vorgang aufgetreten?

Georeplizierte Caches und die zugehörigen Ressourcengruppen können nicht gelöscht werden, während sie verknüpft sind, sondern erst nach dem Entfernen der Verknüpfung für die Georeplikation. Wenn Sie versuchen, die Ressourcengruppe zu löschen, die einen oder beide verknüpfte Caches enthält, werden die anderen Ressourcen in der Ressourcengruppe gelöscht, die Ressourcengruppe bleibt jedoch im Status deleting und alle verknüpften Caches in der Ressourcengruppe im Status running. Um die Ressourcengruppe und die darin enthaltenen verknüpften Caches vollständig zu löschen, müssen Sie die Verknüpfung des Caches aufheben. Dies ist unter Entfernen einer Verknüpfung für die Georeplikation beschrieben.

Welche Region sollte ich für meinen sekundären verknüpften Cache verwenden?

Grundsätzlich sollte sich Ihr Cache in derselben Azure-Region wie die Anwendung befinden, die darauf zugreift. Für Anwendungen mit separater primärer Region und Fallbackregion wird empfohlen, dass sich Ihre primären und sekundären Caches in denselben Regionen befinden. Weitere Informationen zu gekoppelten Regionen finden Sie unter Best Practices – gekoppelte Azure-Regionen.

Kann ich eine Firewall mit Georeplikation konfigurieren?

Ja, Sie können eine Firewall mit Georeplikation konfigurieren. Damit Georeplikation mit einer Firewall funktioniert, müssen Sie sicherstellen, dass die IP-Adresse des sekundären Caches den Firewallregeln des primären Caches hinzugefügt wird. Wenn der Zugriff auf öffentliche Netzwerke jedoch im Cache deaktiviert ist und nur privater Endpunkt aktiviert ist, wird die Verwendung der Firewall im Cache nicht unterstützt.

Nächste Schritte

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