Anmerkung
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel wird erläutert, warum und wie Sie von Azure Cache for Redis (einschließlich Basic, Standard, Premium und Enterprise-Ebenen) zu Azure Managed Redis migrieren.
Sie erfahren mehr über:
- Die Vorteile der Auswahl von Azure Managed Redis gegenüber früheren Ebenen.
- Wichtige Featureunterschiede zwischen den Diensten.
- Strategien für die Migration Ihrer Cachedaten.
- Möglichkeiten, einen reibungslosen Migrationsprozess sicherzustellen.
- Anleitung zum Auswählen der richtigen Azure Managed Redis-SKU und -Leistungsstufe für Ihre Anforderungen.
- Überlegungen und Empfehlungen zum Aktualisieren Ihrer Clientanwendungen.
Ganz gleich, ob Sie die Stufen "Basic", "Standard", "Premium" oder "Enterprise" oder "OSS" verwenden, in diesem Leitfaden können Sie Ihre Migration zu Azure Managed Redis planen und ausführen.
Das Dokument unterteilt sich in zwei Abschnitte. Eine handelt von Enterprise-Instanzen. Die andere betrifft die Basis-, Standard- und Premium-Stufen von Azure Cache für Redis.
- Vorteile des Wechsels von Enterprise zu Azure Managed Redis
- Vorteile des Wechsels von Basic-, Standard- oder Premium-Caches zu azure Managed Redis
Vorteile des Wechsels von Enterprise zu Azure Managed Redis
Azure Managed Redis basiert auf der erweiterten Redis Enterprise-Software. Azure Managed Redis ist ein Azure First Party-Angebot, was bedeutet, dass keine Azure Marketplace-Komponente beteiligt ist und Benutzer keine transaktionen mit Marketplace separat durchführen müssen. Sie stellen Azure Managed Redis wie jeden anderen nativen Azure-Dienst oder -Produkt bereit, verwalten und bezahlen.
Azure Managed Redis benötigt nicht den Quorumknoten , der zu nicht genutzten Ressourcen führt, und beschränkt die Regionen oder Clouds, in denen Azure Cache für Redis Enterprise angeboten werden kann. Azure Managed Redis ist jetzt in den meisten Azure-Regionen mit Plänen verfügbar, die in anderen souveränen Clouds unterstützt werden sollen. Weitere Informationen zum Quorumknoten finden Sie unter Enterprise- und Enterprise Flash-Ebenen. Durch das Entfernen des nicht verwendeten Quorumknotens erhalten Sie eine höhere Kosteneffizienz, da alle Knoten als Datenknoten verwendet werden können.
Azure Managed Redis ist standardmäßig zonenredundant.
Sie können Azure Managed Redis ohne hohe Verfügbarkeit (HA) für Ihre Entwicklungs- und Testumgebungen verwenden. Die Verwendung von Nichtproduktionsumgebungen ohne HA halbiert die Kosten Ihrer Instanz.
Die SKU-Struktur für Azure Managed Redis basiert auf Ihren Speicher- und Leistungsanforderungen. Anstatt Skalierungsfaktoren oder Kapazität wie bei Azure Cache für Redis Enterprise zu verwalten, können Sie aus drei Leistungsstufen in Azure Managed Redis auswählen. Weitere Informationen finden Sie unter Die richtige Ebene wählen.
Schließlich bietet Azure Managed Redis die Microsoft Entra ID-Authentifizierung an, wenn Sie einen Cache erstellen, um den Sicherheitsstatus Ihrer Workload zu verbessern.
Funktionsvergleich
| Merkmal | Azure Cache für Redis Enterprise | Azure Managed Redis |
|---|---|---|
| Redis-Version | 7.2 | 7.4 |
| Clusteringrichtlinie | OSS, Unternehmen | OSS, Enterprise, Nicht gruppiert |
| Geo-replication | Active | Active |
| Service Level Agreement (SLA) | Bis zu 99,999% | Bis zu 99,999% |
| Zonenredundanz | Yes | *Ja mit hoher Verfügbarkeit |
| Nicht-HA-Modus | No | Ja (für Dev/Test) |
| Datenpersistenz | Ja (in der Vorschau) | Yes |
| Scaling | Yes | Yes |
| TLS-Versionsunterstützung | 1.2,1.3 | 1.2,1.3 |
| Microsoft Entra ID-Authentifizierung | No | Yes |
| Unterstützung für Azure-Regionen | Begrenzt | Umfangreich |
| Azure Sovereign Cloud-Unterstützung | No | Ja (in Kürze verfügbar) |
| Hostname DNS-Suffix | <name>.<region>.redisenterprise.cache.azure.net |
<name>.<region>.redis.azure.net |
* Wenn hohe Verfügbarkeit aktiviert ist, ist Azure Managed Redis zonenredundant in Regionen mit mehreren Verfügbarkeitszonen.
Überlegungen beim Wechsel von Enterprise zu Azure Managed Redis
Azure Managed Redis verwendet den gleichen Softwarestapel wie Azure Cache für Redis Enterprise, sodass Ihre vorhandenen Anwendungen, die die Enterprise-Ebene verwenden, nicht viele Änderungen benötigen. Die wesentliche Ausnahme besteht darin, die Verbindungsanmeldeinformationen zu ändern.
Unterschiedlicher Hostname und Suffix
Während die Kernsoftware für Azure Cache für Redis Enterprise und Azure Managed Redis ähnlich ist, unterscheidet sich das DNS-Suffix für Ihren Redis-Clusterhostnamen. Wenn Sie zu Azure Managed Redis wechseln, muss Ihre Anwendung den Redis-Clusterhostnamen ändern. Wenn Sie Zugriffsschlüssel zum Herstellen einer Verbindung mit Ihrem Cache verwenden, müssen Sie auch den Zugriffsschlüssel aktualisieren, den er zur Verbindung mit dem Cache verwendet.
Von Bedeutung
Erwägen Sie das Aktualisieren des Codes, der eine Verbindung mit dem Cache herstellt. Verwenden Sie anstelle von Zugriffstasten die Microsoft Entra-ID. Wir empfehlen die Verwendung der Microsoft Entra-ID anstelle von Zugriffstasten.
Auswählen der richtigen Größe von Azure Managed Redis und SKU
Azure Managed Redis bietet viele Speichergrößen und drei Leistungsstufen. Weitere Informationen zu Arbeitsspeichergrößen und Leistungsstufen finden Sie hier Richtige Leistungsstufe wählen.
Identifizieren der Speichergröße eines vorhandenen Azure-Caches für Redis Enterprise-Instanz
Azure Cache for Redis Enterprise-Instanzen können skaliert werden, um sowohl mehr Arbeitsspeicher als auch mehr Computeressourcen bereitzustellen. Daher ist es wichtig, den Skalierungsfaktor für Ihren Cache zu beachten. Das Skalieren hängt auch mit der Kapazität zusammen, was im Wesentlichen die Anzahl der virtuellen Computer ist, die für Ihren Cluster ausgeführt werden.
So wählen Sie die richtige Azure Managed Redis-Speichergröße aus:
- Wechseln Sie zum Azure-Portal, und wählen Sie im Ressourcenmenü die Option "Übersicht" aus.
- Überprüfen Sie das Feld "Status " in der Übersicht über Ihre Enterprise-Instanz. Das Feld "Status " zeigt die Speichergröße Ihrer Redis Enterprise-Instanz an.
Sehen wir uns ein mögliches Szenario an.
Im Bereich "Status " im Übersichtsbereich sehen Sie "Running - Enterprise 8GB (2 x 4 GB)". Diese Notation bedeutet, dass der Cache derzeit eine E5 Enterprise-SKU mit einer Skalierung von 2 verwendet, was zu einem 8-GB-Cache führt. Daher sollten Sie mit mindestens 10 GB Cache auf Azure Managed Redis beginnen.
Verwenden Sie in diesem Fall eine der Ebenen, die 12 GB Arbeitsspeicher bieten.
| Artikelnummer (SKU) | Tarif |
|---|---|
| M10 | Memory Optimized |
| B10 | Balanced |
| X10 | Compute Optimized |
Identifizieren der Leistungsebene
Sie sollten auch berücksichtigen, ob Ihre Workload arbeitsspeicherintensiv oder rechenintensiv ist. Wenn Ihre aktuelle Enterprise-Instanz eher den Arbeitsspeicher als die CPU erschöpft, ist die Arbeitsauslastung speicherintensiv. Erwägen Sie die Auswahl aus der Speicheroptimierten Leistungsstufe.
Wenn Ihr Workload durchsatzintensiv ist oder eine hohe Latenz aufweist, ist Ihr Workload rechenintensiv. Erwägen Sie die Auswahl von " Compute Optimized performance tier".
Wenn Sie nicht sicher sind, können Sie mit der Stufe " Ausgewogene Leistung" beginnen, da sie eine gesunde Mischung aus Arbeitsspeicher und Leistung bietet.
Wenn Sie derzeit Redis Enterprise Flash-Ebene verwenden, sollten Sie die Stufe "Flash optimiert" auswählen.
Erstellen einer neuen Azure Managed Redis-Instanz
Nachdem Sie die Speicher- und Leistungsstufe für Ihre neue Azure Managed Redis-Instanz ausgewählt haben, können Sie die neue Azure Managed Redis-Instanz erstellen. Weitere Informationen zum Erstellen eines Caches finden Sie in der Schnellstartanleitung: Erstellen einer azure managed Redis-Instanz.
Als Nächstes müssen Sie eine Strategie zum Verschieben Ihrer Daten auswählen. Und schließlich müssen Sie Ihre Anwendung aktualisieren, um den neuen Cache zu verwenden.
Aktualisieren der App zum Herstellen einer Verbindung mit der Azure Managed Redis-Instanz
Nachdem Sie eine neue Azure Managed Redis-Instanz erstellt haben, müssen Sie den Redis-Endpunkt/Hostnamen und den Zugriffsschlüssel in Ihrer Anwendung ändern, um auf Ihre neue Azure Managed Redis-Instanz zu verweisen. Es wird empfohlen, diese Änderung des Endpunkts außerhalb der Geschäftszeiten zu veröffentlichen, da die Verbindung zu einer kurzen Unterbrechung führen kann.
Note
Wenn Sie eine Verbindung mit Ihrer vorhandenen Redis Enterprise-Instanz über einen privaten Endpunkt herstellen, stellen Sie sicher, dass Ihr neuer Azure Managed Redis-Cache auch mit dem virtuellen Netzwerk Ihrer Anwendung verbunden ist. Der neue Cache muss eine ähnliche Einrichtung wie vorhandene Redis Enterprise-Instanz aufweisen.
Stellen Sie sicher, dass Ihre Anwendung wie erwartet ausgeführt wird, und löschen Sie dann Die vorherige Redis Enterprise-Instanz.
Verschieben Ihrer Daten aus Ihrem Unternehmenscache in einen neuen Azure Managed Redis-Cache
Bei der Migration zu Azure Managed Redis-Instanz müssen Sie die beste Methode berücksichtigen, um Ihre Daten aus der vorhandenen Redis Enterprise-Instanz in Ihre neue Azure Managed Redis-Instanz zu verschieben. Wenn Ihre Anwendung Datenverluste tolerieren kann oder andere Mechanismen zum Rehydratieren des Caches ohne negative Auswirkungen hat, überspringen Sie diesen Schritt, und fahren Sie mit den nächsten Schritten fort.
Wenn Ihre Anwendung sicherstellen muss, dass Daten auch zur neuen Azure Managed Redis-Instanz migriert werden, wählen Sie eine der folgenden Optionen aus:
Datenexport und -import mithilfe einer RDB-Datei
- Vorteile: Behält die Daten-Snapshot bei.
- Nachteile: Risiko eines Datenverlusts, wenn Schreibvorgänge nach der Momentaufnahme auftreten.
Hier ist die grundlegende Export-/Importprozedur:
- Exportieren Sie RDB aus dem vorhandenen Redis Enterprise-Cache in Ihr Azure Storage-Konto.
- Importieren Sie Daten aus dem Azure Storage-Konto in einen neuen Azure Managed Redis-Cache.
- Weitere Informationen zum Datenexport/-import finden Sie hier : Importieren und Exportieren von Daten in Azure Managed Redis.
Dual-Write Strategie
- Pros: Null Ausfallzeiten, sicherer Übergang.
- Nachteile: Erfordert die temporäre Konfiguration des Dual-Caches.
Hier ist die grundlegende Dual-Write-Prozedur:
- Ändern Sie Ihre Anwendung so, dass sie sowohl in den bestehenden Azure Cache für Redis Enterprise als auch in den neuen Azure Managed Redis Cache schreibt.
- Lesen sie weiter und schreiben Sie aus dem Redis Enterprise-Cache.
- Wechseln Sie nach ausreichender Datensynchronisierung zu Azure Managed Redis und löschen Sie Redis Enterprise-Instanz
Programmgesteuerte Migration mit RIOT-X
RIOT-X bietet eine Möglichkeit, Ihre Inhalte von Enterprise zu Azure Managed Redis zu migrieren. Weitere Informationen finden Sie unter "Datenmigration mit RIOT-X für azure Managed Redis".
- Vorteile: Volle Kontrolle, anpassbar.
- Nachteile: Erfordert Entwicklungsaufwand.
Vorteile des Wechsels von Basic-, Standard- oder Premium-Caches zu azure Managed Redis
Wenn Sie eines der OSS-SKUs, Basic, Standard oder Premium verwenden, bietet ihnen der Wechsel zu Azure Managed Redis weitere Features auf jeder Ebene cache.
Hier ist eine Tabelle, die die Features von Azure Cache für Redis mit den Features in Azure Managed Redis vergleicht.
| Funktionsbeschreibung | Basic OSS |
Standard OSS |
Premium OSS |
Balanced AMR |
Memory Optimized AMR |
Compute Optimized AMR |
|---|---|---|---|---|---|---|
| Availability | N/A | 99.9% | 99.9% | Bis zu 99,999% | Bis zu 99,999% | Bis zu 99,999% |
| Datenverschlüsselung während der Übertragung | Yes | Yes | Yes | Yes | Yes | Yes |
| Netzwerkisolation | Yes | Yes | Yes | Yes | Yes | Yes |
| Hochskalieren/Skalierung nach außen | Yes | Yes | Yes | Yes | Yes | Yes |
| Vertikales Herunterskalieren/Horizontales Herunterskalieren | Yes | Yes | Yes | No | No | No |
| OSS-Clustering | No | No | Yes | Yes | Yes | Yes |
| Datenpersistenz | No | No | Yes | Yes | Yes | Yes |
| Zonenredundanz | No | Ja (Vorschau) | Yes | *Ja mit hoher Verfügbarkeit | *Ja mit hoher Verfügbarkeit | *Ja mit hoher Verfügbarkeit |
| Geo-replication | No | No | Ja (passiv) | Ja (Aktiv) | Ja (aktiv) | Ja (aktiv) |
| Verbindungsüberwachungsprotokolle | No | No | Yes | Yes(Event-based) | Yes(Event-based) | Yes(Event-based) |
| Redis-Module | No | No | No | Yes | Yes | Yes |
| Import/Export | No | No | Yes | Yes | Yes | Yes |
| Reboot | Yes | Yes | Yes | No | No | No |
| Geplante Updates | Yes | Yes | Yes | No | No | No |
| Microsoft Entra ID-Authentifizierung | Yes | Yes | Yes | Yes | Yes | Yes |
| Microsoft Entra ID RBAC | Yes | Yes | Yes | No | No | No |
| Keyspace-Benachrichtigung | Yes | Yes | Yes | No | No | No |
| Nicht hohe Verfügbarkeit | N/A | No | No | Yes | Yes | Yes |
OSS bezieht sich auf Azure Cache für Redis
AMR bezieht sich auf Azure Managed Redis
* Wenn hohe Verfügbarkeit aktiviert ist, ist Azure Managed Redis zonenredundant in Regionen mit mehreren Verfügbarkeitszonen.
Hier sind einige weitere Unterschiede, die Sie bei der Implementierung von Azure Managed Redis berücksichtigen sollten. Berücksichtigen Sie folgende Änderungen bei Clientanwendungen:
| Funktionsbeschreibung | Azure Cache für Redis | Azure Managed Redis |
|---|---|---|
| DNS-Suffix (nur für PROD-Cloud) | .redis.cache.windows.net |
<region>.redis.azure.net |
| TLS-Port | 6380 | 10000 |
| Nicht-TLS-Port | 6379 | Nicht unterstützt |
| TLS-Ports für einzelne Knoten | 13XXX | 85xx |
| Nicht-TLS-Ports für einzelne Knoten | 15XXX | Nicht unterstützt |
| Clustering-Unterstützung | OSS-Clusteringmodus | OSS- und Enterprise-Clustermodus |
| Nicht unterstützte Befehle | Nicht unterstützte Befehle | Befehle mit mehreren Schlüsseln |
| Regionale Verfügbarkeit | Alle Azure-Regionen | * Siehe die Liste der Regionen nach diesem Abschnitt. |
| Redis-Version | 6 | 7.4 |
| Unterstützte TLS-Versionen | 1.2 und 1.3 | 1.2 und 1.3 |
Migrieren Sie Ihren Basic-, Standard- oder Premium-Cache zu Azure Managed Redis
Basierend auf der Tabelle sind hier einige Zuordnungen zwischen dem Azure-Cache für Redis-SKUs und Optionen für Caches in Azure Managed Redis aufgeführt.
Note
Verwenden der Option „Keine Hochverfügbarkeit“ von Azure Managed Redis für die Migration von Basic-SKUs
| Azure Cache für Redis | Azure Managed Redis | Zusätzlicher Arbeitsspeicher (%) |
|---|---|---|
| Basic/Standard – C0 | Ausgewogen – B0 | 50 |
| Basic/Standard – C1 | Ausgewogen – B1 | 0 |
| Basic/Standard – C2 | Ausgewogen – B3 | 17 |
| Basic/Standard – C3 | Ausgewogen – B5 | 0 |
| Basic/Standard – C4 | Arbeitsspeicheroptimiert – M10 | -8 |
| Basic/Standard – C4 | Arbeitsspeicheroptimiert – M20** | 46 |
| Basic/Standard – C5 | Arbeitsspeicheroptimiert – M20* | -8 |
| Basic/Standard – C5 | Arbeitsspeicheroptimiert – M50** | 57 |
| Basic/Standard – C6 | Arbeitsspeicheroptimiert – M50 | 12 |
| Premium –P1 | Ausgewogen – B5 | 0 |
| Premium –P2 | Ausgewogen – B10* | -8 |
| Premium –P2 | Ausgewogen – B20** | 46 |
| Premium –P3 | Ausgewogen – B20* | -8 |
| Premium –P3 | Ausgewogen – B50* | 57 |
| Premium –P4 | Ausgewogen – B50 | 12 |
| Premium –P5 | Ausgewogen – B100 | 0 |
- * Diese Option ist für die Kosteneffizienz vorgesehen. Stellen Sie sicher, dass der Spitzenwert des insgesamt genutzten Speichers im letzten Monat unter dem empfohlenen Speicher für Azure Managed Redis liegt, um diese Option auszuwählen.
- ** Diese Option eignet sich für hohen Arbeitsspeicherverbrauch.
Azure Cache for Redis Premium (gruppiert)
- Wählen Sie für Shardcluster einen arbeitsspeicheroptimierten Tarif mit gleichwertigem Gesamtspeicher aus.
- Wählen Sie für Cluster mit mehr als einem Lesereplikat einen für Compute optimierten Tarif mit gleichwertigem Gesamtspeicher als primäres Replikat aus.
Migrationsoptionen
Clientanwendungen sollten in der Lage sein, eine Azure Managed Redis-Instanz mit unterschiedlichen Clusteringmodi und Endpunkten zu verwenden. Der Azure-Cache für Redis und azure Managed Redis sind kompatibel, sodass für die meisten Szenarien keine Anwendungscodeänderungen außer Verbindungskonfigurationen erforderlich sind.
Weitere Informationen finden Sie unter:
Optionen für das Migrieren von Azure Cache for Redis zu Azure Managed Redis
| Option | Advantages | Disadvantages |
|---|---|---|
| Erstellen eines neuen Caches | Die am einfachsten zu implementierende Methode. | Daten müssen im neuen Cache wieder aufgefüllt werden, was bei vielen Anwendungen möglicherweise nicht funktioniert. |
| Exportieren und Importieren von Daten über eine RDB-Datei | Im Allgemeinen mit jedem Redis-Cache kompatibel. | Einige Daten könnten verloren gehen, wenn sie nach dem Generieren der RDB-Datei in den vorhandenen Cache geschrieben werden. |
| Duale Schreibvorgänge in zwei Caches | Kein Datenverlust und keine Ausfallzeiten Unterbrechungsfreie Vorgänge im vorhandenen Cache. Einfacheres Testen des neuen Caches. | Für einen längeren Zeitraum sind zwei Caches erforderlich. |
| Programmgesteuertes Migrieren von Daten | Völlige Kontrolle über die Übertragung der Daten. | Erfordert benutzerdefinierten Code. |
Erstellen einer neuen Azure Managed Redis-Instanz
Dieser Ansatz ist technisch gesehen keine Migration. Wenn der Verlust von Daten kein Problem darstellt, besteht die einfachste Möglichkeit, zur Azure Managed Redis-Ebene zu wechseln, darin, eine neue Cacheinstanz zu erstellen und Ihre Anwendung damit zu verbinden. Wenn Sie Redis beispielsweise als Suchcache für Datenbank-Datensätze verwenden, können Sie den Cache problemlos von Grund auf neu erstellen. Hier finden Sie die allgemeinen Schritte zum Implementieren dieser Option:
- Erstellen Sie eine neue Azure Managed Redis-Instanz.
- Aktualisieren Sie Ihre Anwendung, sodass die neue Instanz verwendet wird.
- Löschen Sie die alte Azure Cache for Redis-Instanz.
Exportieren von Daten in eine RDB-Datei und Importieren in Azure Managed Redis
Diese Option gilt nur für Premium-Tarif-Caches. Open-Source-Redis definiert einen Standardmechanismus, um eine Momentaufnahme des In-Memory-Datasets eines Caches zu erstellen und in einer Datei zu speichern. Ein anderer Redis-Cache kann die exportierte RDB-Datei lesen. Der Azure Cache for Redis-Premium-Tarif unterstützt das Exportieren aus einer Cache-Instanz mithilfe von RDB-Dateien. Sie können eine RDB-Datei verwenden, um Daten aus einer vorhandenen Azure Cache for Redis-Instanz in Azure Managed Redis zu übertragen.
Hier finden Sie die allgemeinen Schritte zum Implementieren dieser Option:
- Erstellen Sie eine neue Azure Managed Redis-Instanz, die genauso groß (oder größer) wie die vorhandene Azure Cache for Redis-Instanz ist.
- Exportieren der RDB-Datei aus einer vorhandenen Azure Cache für Redis-Instanz mithilfe dieser Exportanweisungen oder des PowerShell-Export-Cmdlets
- Importieren der RDB-Datei mithilfe dieser Importanweisungen oder dem PowerShell-Cmdlet für den Import in die Azure Managed Redis-Instanz
- Aktualisieren Sie Ihre Anwendung so, dass sie die neue Azure Managed Redis-Instanz-Verbindungszeichenfolge verwendet.
Gleichzeitiges Schreiben in zwei Redis-Caches während der Migrationsphase
Anstatt Daten direkt zwischen Caches zu verschieben, können Sie Ihre Anwendung verwenden, um Daten sowohl in einen vorhandenen als auch in einen neuen, von Ihnen eingerichteten Cache zu schreiben. Die Anwendung liest Daten anfangs weiterhin aus dem vorhandenen Cache. Wenn der neue Cache über alle notwendigen Daten verfügt, konfigurieren Sie Ihre Anwendung für den neuen Cache und nehmen den alten außer Betrieb. Ein Beispiel: Sie verwenden Redis als Sitzungsspeicher, und die Anwendungssitzungen sind sieben Tage lang gültig. Nachdem eine Wochen lang in beide Caches geschrieben wurde, können Sie sicher sein, dass der neue Cache alle nicht abgelaufenen Sitzungsinformationen enthält. Ab diesem Zeitpunkt können Sie sich auf diesen Cache verlassen, ohne sich Gedanken um Datenverluste machen zu müssen.
Hier finden Sie die allgemeinen Schritte zum Implementieren dieser Option:
- Erstellen Sie eine neue Azure Managed Redis-Instanz, die genauso groß (oder größer) wie die vorhandene Azure Cache for Redis-Instanz ist.
- Ändern Sie den Anwendungscode, sodass die Anwendung sowohl in die neue als auch in die ursprüngliche Cache-Instanz schreibt.
- Verwenden Sie zum Lesen der Daten weiterhin die ursprüngliche Instanz, bis die neue Instanz ausreichend mit Daten aufgefüllt ist.
- Aktualisieren Sie den Anwendungscode, sodass die Anwendung zum Lesen und Schreiben von Daten ausschließlich die neue Instanz verwendet.
- Löschen Sie die ursprüngliche Instanz.
Programmgesteuertes Migrieren
Erstellen Sie einen benutzerdefinierten Migrationsprozess, indem Sie Daten programmgesteuert aus einer vorhandenen Azure Cache for Redis-Instanz lesen und in eine Azure Managed Redis-Instanz schreiben lassen. Es gibt zwei Open Source-Tools, die Sie dafür ausprobieren können:
-
Redis-copy
- Dieses Open-Source-Tool kann zum Kopieren von Daten aus einer Azure Cache for Redis-Instanz in eine andere verwendet werden. Dieses Tool ist sehr nützlich, wenn Sie Daten zwischen Cache-Instanzen in verschiedenen Azure Cache-Regionen verschieben müssen. Eine kompilierte Version ist ebenfalls verfügbar. Wenn Sie selbst ein Migrationstool schreiben, ist auch der Quellcode möglicherweise ein nützlicher Leitfaden.
-
RIOT
- RIOT ist ein weiteres beliebtes Migrationstool, das von der Redis-Community getestet wurde. Es ist ein Befehlszeilenprogramm, das Sie beim Abrufen von Daten aus Redis sowie beim Schreiben von Daten in Redis unterstützt.
Note
Dieses Tool wird von Microsoft nicht offiziell unterstützt.
Hier finden Sie die allgemeinen Schritte zum Implementieren dieser Option:
- Erstellen Sie eine VM in der Region, in der sich der vorhandene Cache befindet. Wenn Ihr Dataset groß ist, wählen Sie eine relativ leistungsstarke VM aus, um die Kopierdauer zu verkürzen.
- Erstellen Sie eine neue Azure Managed Redis-Instanz.
- Leeren Sie den neuen Cache, um sicherzustellen, dass sich keine Daten darin befinden. Dieser Schritt ist erforderlich, weil das Kopiertool selbst keine vorhandenen Schlüssel im Zielcache überschreibt. Wichtig: Stellen Sie sicher, dass Sie NICHT den Quellcache leeren.
- Verwenden Sie eine Anwendung wie z. B. das vorhin erwähnte Open-Source-Tool, um das Kopieren der Daten vom Quell- zum Zielcache zu automatisieren. Denken Sie daran, dass der Kopiervorgang je nach Größe Ihres Datasets eine Weile dauern kann.
Regionale Verfügbarkeit für Azure Managed Redis.
Azure Managed Redis wird fortlaufend auf neue Regionen ausgeweitet. Sie können die Verfügbarkeit nach Region unter Verfügbare Produkte nach Region überprüfen.