Häufig gestellte Fragen zu Azure Cache for Redis

Das Open-Source-Projekt Redis ist auf ein Dual-Lizenz-Modell mit Unterstützung für RSALv2 (Redis Source Available License Version 2) oder SSPLv1 (Server-Side Public License Version 1) umgestiegen. Weitere Informationen finden Sie in der Redis-Pressemitteilung. Lesen Sie auch den Microsoft-Blogbeitrag zur Redis-Lizenzierungsänderung.

Nein, Azure Cache for Redis wird Kunden und Kundinnen unter den Microsoft-Vertragsbedingungen angeboten. Die Lizenzen RSALv2 und SSPLv1 gelten nicht für Ihre Verwendung von Azure Cache for Redis.

Ja, Azure Cache for Redis, Azure Cache for Redis Enterprise und Enterprise Flash erhalten auch nach der Ankündigung der Lizenzänderung weiterhin Patches und Fehlerbehebungen.

Für unsere Azure-Kunden und -Kundinnen ist keine Aktion in Bezug auf die Ankündigung der Lizenzierungsänderung erforderlich.

• Managed Cache Service: Managed Cache Service wurde am 30. November 2016 außer Betrieb gesetzt.

• In-Role Cache: In-Role Cache wurde am 30. November 2016 außer Betrieb gesetzt.

Sie sollten alle Caches mit einer Abhängigkeit von Cloud-Diensten (klassisch) migrieren. Im August 2021 kündigten wir Cloud-Dienste (klassisch) am 31. August 2024 an. Alle Instanzen von Azure Cache for Redis, die von Cloud-Diensten (klassisch) abhängig sind, müssen zum gleichen Datum eingestellt werden.

Sie sollten Caches, die von Cloud-Diensten (klassisch) abhängig sind, vor dem 31. August 2024 migrieren.

Wir haben versucht, so viele Caches wie möglich auf transparente Weise zu migrieren. Aus diesem Gründen sind einige Caches und Kunden betroffen.

So überprüfen Sie Azure Advisor-Empfehlungen. Wenn Ihr Cache betroffen ist, wird in Ihrem Abonnement eine Empfehlung angezeigt.

Wir haben die meisten auf (klassischen) Cloud Services aufbauenden Caches zu auf Azure Virtual Machine Scale Sets aufbauenden Caches migriert. Die Migration zu Azure Virtual Machine Scale Sets entfernt die Abhängigkeit. Es gibt drei Möglichkeiten, diesen Prozess für Caches in einem virtuellen Netzwerk zu initiieren:

• Migration zu einem neuen Cache mit Private Link:

  Erstellen Sie einen neuen Cache, der Private Link für die Netzwerkisolierung verwendet, anstatt die VNet-Injektion zu verwenden, und migrieren Sie Ihre Daten zu diesem Cache. Diese Option bietet Ihnen die beste und sicherste Möglichkeit der Netzwerkisolierung und stellt gleichzeitig sicher, dass alle neuen Caches mit einer aktualisierten Infrastruktur erstellt werden.

• Migrieren Sie zu einem neuen Cache in einem neuen Azure Resource Manager VNet-Subnetz.

  Beim Erstellen eines Caches in einem klassischen VNet wird ein (klassischer) Cloud Services-Cache und kein Azure Virtual Machine Scale Sets-Cache erstellt. Durch die Migration zu einem neuen Cache in einem neuen Azure Resource Manager-VNet-Subnetz wird die zugrunde liegende Abhängigkeit von Cloud Services aufgehoben, aber gleichzeitig eine ähnliche VNet-Funktionalität beibehalten.

  Wir haben die meisten auf (klassischen) Cloud Services aufbauenden Caches zu auf Azure Virtual Machine Scale Sets aufbauenden Caches migriert. Für die Migration löschen Sie den vorhandenen Cache und erstellen einen neuen Cache in einem neuen Azure Resource Manager VNet-Subnetz. Es wird dringend empfohlen, beim Migrieren von Caches keine alten Subnetze zu verwenden. Empfohlene Optionen zum Migrieren der Daten im Cache finden Sie unter Migrieren zu Azure Cache for Redis.

• Automatische Migration mit Datenverlust (empfohlen):

  Wir können Caches von der Verwendung von Cloud Services (klassisch) zur automatischen Verwendung von Virtual Machine Scale Sets migrieren, wobei die Cachekonfiguration (einschließlich Zugriffsschlüssel und Hostnamen) beibehalten wird. Diese Methode zieht jedoch eine Downtime von ca. 30 Minuten und den vollständigen Verlust der Daten im Cache nach sich. Sie können das Feature zum Importieren/Exportieren verwenden, um vor der Migration eine Kopie Ihrer Daten zu speichern.

  Wenden Sie sich an azurecachemigration@microsoft.com, oder erstellen Sie eine Supportanfrage, um eine Migration zu beantragen.

Überprüfen Sie, ob Ihr Cache Georeplikation verwendet. Wenn ja, müssen Sie Ihre Daten von Ihrem aktuellen georeplizierten Paar zu einem neuen georeplizierten Paar migrieren.

Beispiel:

1. Erstellen Sie ein neues georepliziertes Paar Premium-Caches, das der gleichen Konfiguration entspricht wie Ihr aktuelles Cache-Paar.
2. Heben Sie die Verknüpfung Ihres ursprünglichen Paares von georeplizierten Caches auf und exportieren Sie eine RDB-Datei aus dem primären Cache.
3. Importieren Sie die RDB-Datei in den primären Cache in Ihrem neuen georeplizierten Paar.

Das neue Paar georeplizierter Caches ist nicht mehr in gleichem Maße von den Cloud-Diensten abhängig.

Wir beginnen damit, die Erstellung neuer Caches mithilfe des (klassischen) Bereitstellungsmodells von Cloud Services zu blockieren. Neue Caches können weiterhin mit diesem alten Bereitstellungsmodell erstellt werden, wenn sie in einem VNet-Subnetz erstellt werden, das einst einen Cloud Services-Cache enthielt, oder wenn ein Cache in einem klassischen VNet bereitgestellt wird. Wenn diese Meldung angezeigt wird, erstellen Sie ein neues Subnetz in Ihrem VNet, in dem der Cache bereitgestellt werden soll. Durch das Erstellen eines Subnetzes in Ihrem virtuellen Netzwerk wird sichergestellt, dass ein Cache ohne Abhängigkeit von Cloud Services erstellt wird.

Um zu überprüfen, ob Sie einen oder mehrere Cloud Services-basierte Caches in Ihrem Subnetz haben, können Sie Azure Advisor im Portal überprüfen oder die REST-API für Ressourcennavigationslinks verwenden. Verwenden Sie die resource-navigation-links-API mit Ihrer Abonnement-ID, dem Ressourcengruppennamen, dem VNet-Namen und dem Subnetznamen, um Caches in diesem Subnetz abzurufen, das Cloud Services verwendet.

Stellen Sie außerdem sicher, dass Sie die Redis-Konfiguration {"CacheVmType": "CloudService"} nicht zusammen mit der Erstellungsanforderung übergeben, wenn Sie einen neuen Cache mithilfe der REST-API erstellen. Diese Parameter sind nicht dokumentiert, daher ist es unwahrscheinlich, dass Sie das tun.

Wenn Sie neue Caches mithilfe des (klassischen) Cloud Services-Bereitstellungsmodells erstellen müssen, wenden Sie sich an azurecachemigration@microsoft.com, oder erstellen Sie eine Supportanfrage, um eine Ausnahme zu beantragen.

Diese Caches werden heruntergefahren, und Sie verlieren alle Daten in Ihren Caches.

Die Außerbetriebnahme erfolgt in drei Phasen, damit Sie möglichst viel Zeit für die Migration haben:

1. Aktive Phase (jetzt bis 30. April 2023)

   Caches werden voll unterstützt, der Status hat sich gegenüber heute nicht geändert. Dieser Zeitraum wird gewährt, um den Kunden Zeit zu geben, den Cloud-Dienst (klassisch) mit minimaler Unterbrechung zu ermöglichen.

2. Wartungsphase (1. Mai 2023 bis 31. Dezember 2023)

   Caches erhalten kritische Sicherheits-, Stabilitäts- und Fehlerbehebungen, aber keine neuen Funktionen.

3. Inaktive Phase (1. Januar 2024 bis 31. August 2024)

   Caches erhalten nur wichtige Sicherheitsfixes. Alle Kunden mit Supportproblemen werden aufgefordert, zu einem VMSS-basierten Cache zu migrieren, bevor sie Support erhalten. Kunden müssen ihre Caches bis zum 31. August 2024 deaktivieren.

Nein. Dieser Zeitplan gilt nur für Caches, die auf Redis 6.0 ausgeführt werden. Redis 4.0 ist Teil einer separaten Außerbetriebnahme, die vor der Außerbetriebnahme von Cloud Services (klassisch) abgeschlossen wird. Alle verbleibenden Caches mit Redis 4.0 für Cloud Services (klassisch) werden automatisch migriert. Nach dem 31. Oktober 2023 verwenden sie automatisch Virtual Machine Scale Sets und Redis 6.0. Diese Migrationsmethode zieht Downtime und einen vollständigen Datenverlust im Cache nach sich. Migrieren Sie also vor diesem Datum, um Downtime oder Datenverlust zu vermeiden. Wenden Sie sich vor dem 31. Oktober 2023 an azurecachemigration@microsoft.com, oder erstellen Sie eine Supportanfrage, um ein automatisches Upgrade zu beantragen.

Stellen Sie Ihre Fragen auf der Q&A-Seite zur Einstellung von Cloud Services (klassisch). Außerdem können Sie E-Mails senden, um azurecachemigration@microsoft.com weitere Informationen zu erhalten.

Wenn Ihre Frage hier nicht aufgeführt wird, informieren Sie uns, damit wir Ihnen helfen können, eine Antwort zu finden.

• Sie können eine Frage auf der Q&A-Seite von Microsoft zu Azure Cache stellen und mit dem Azure Cache-Team und anderen Mitgliedern der Community diskutieren, um eine größere Benutzergruppe zu erreichen

• Featureanfragen und Anregungen können an Azure Cache for Redis User Voice gesendet werden.

• Sie können uns Ihre Frage auch an azurecache@microsoft.com senden.