In diesem Artikel erhalten Sie Antworten auf häufig gestellte Fragen sowie Informationen zu Mustern und Best Practices für Azure Cache for Redis.
Redis-Lizenzierungsänderung
Welche Änderungen wurden an der Redis-Lizenzierung vorgenommen?
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.
Wird Azure Cache for Redis jetzt auch von den Lizenzen RSALv2 und SSPLv1 abgedeckt?
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.
Erhält meine Azure Cache for Redis-Instanz weiterhin Patches und Fehlerbehebungen?
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.
Was muss ich als Azure Cache for Redis-Kunde/-Kundin als Reaktion auf diese Ankündigung der Lizenzierungsänderung tun?
Für unsere Azure-Kunden und -Kundinnen ist keine Aktion in Bezug auf die Ankündigung der Lizenzierungsänderung erforderlich.
Veraltete Dienste
Welche Azure Cache for Redis-Dienste wurden als veraltet gekennzeichnet?
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.
Caches mit einer Abhängigkeit von Cloud-Diensten (klassisch)
Was soll ich mit den Instanzen von Azure Cache for Redis tun, die von Cloud-Diensten (klassisch) abhängig sind?
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.
Wie viele Caches sind betroffen?
Wir haben versucht, so viele Caches wie möglich auf transparente Weise zu migrieren. Aus diesem Gründen sind einige Caches und Kunden betroffen.
Wie weiß ich, ob ein Cache betroffen ist?
So überprüfen Sie Azure Advisor-Empfehlungen. Wenn Ihr Cache betroffen ist, wird in Ihrem Abonnement eine Empfehlung angezeigt.
Wie werden Cloud Services- (klassisch) Caches zu Azure Virtual Machine Scale Sets migriert?
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.
Mein Cache verwendet keine VNet-Injektion, aber ich wurde benachrichtigt, dass ich migrieren muss. Wie sollte ich vorgehen?
Ü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:
- Erstellen Sie ein neues georepliziertes Paar Premium-Caches, das der gleichen Konfiguration entspricht wie Ihr aktuelles Cache-Paar.
- Heben Sie die Verknüpfung Ihres ursprünglichen Paares von georeplizierten Caches auf und exportieren Sie eine RDB-Datei aus dem primären Cache.
- 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.
Was soll ich tun, wenn ich keine neue Cache-Instanz mit der Fehlermeldung „Das Subnetz ist von der Außerbetriebnahme von Cloud Services betroffen“ erstellen kann?
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.
Was passiert, wenn die Caches nicht bis zum 31. August 2024 aktualisiert/migriert werden?
Diese Caches werden heruntergefahren, und Sie verlieren alle Daten in Ihren Caches.
Wie ist die Zeitspanne für den Support?
Die Außerbetriebnahme erfolgt in drei Phasen, damit Sie möglichst viel Zeit für die Migration haben:
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.
Wartungsphase (1. Mai 2023 bis 31. Dezember 2023)
Caches erhalten kritische Sicherheits-, Stabilitäts- und Fehlerbehebungen, aber keine neuen Funktionen.
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.
Gilt dieser Zeitplan für Caches, die auf Redis 4.0 ausgeführt werden?
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.
Wo kann ich weitere Informationen erhalten, wenn ich mehr Fragen zu diesem Ruhestand habe?
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.
Allgemeine Fragen
Was kann ich tun, wenn meine Frage zu Azure Cache for Redis hier nicht beantwortet wird?
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.