Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Den här artikeln förklarar varför och hur du migrerar från Azure Cache for Redis (inklusive nivåerna Basic, Standard, Premium och Enterprise) till Azure Managed Redis.
Du lär dig mer om:
- Fördelarna med att välja Azure Managed Redis jämfört med tidigare nivåer.
- Viktiga funktionsskillnader mellan tjänsterna.
- Strategier för att migrera cachedata.
- Sätt att säkerställa en smidig migreringsprocess.
- Vägledning om hur du väljer rätt Azure Managed Redis SKU och prestandanivå för dina behov.
- Överväganden och rekommendationer för att uppdatera dina klientprogram.
Oavsett om du använder nivåerna Basic, Standard, Premium ellerEnterprise eller OSS hjälper den här guiden dig att planera och köra migreringen till Azure Managed Redis.
Dokumentet delas in i två avsnitt. Den ena handlar om Enterprise-instanser. Det andra handlar om nivåerna Basic, Standard och Premium i Azure Cache for Redis.
- Fördelar med att flytta från Enterprise till Azure Managed Redis
- Fördelar med att flytta från Basic-, Standard- eller Premium-cacheminnen till Azure Managed Redis
Fördelar med att flytta från Enterprise till Azure Managed Redis
Azure Managed Redis bygger på den avancerade Redis Enterprise-programvaran. Azure Managed Redis är ett azure-erbjudande från första part, vilket innebär att det inte finns någon Azure Marketplace-komponent inblandad och användarna behöver inte handla separat med Marketplace. Du etablerar, hanterar och betalar för Azure Managed Redis som alla andra interna Azure-tjänster eller produkter.
Azure Managed Redis behöver inte kvorumnoden som leder till underanvända resurser och begränsar de regioner eller moln där Azure Cache for Redis Enterprise kan erbjudas. Azure Managed Redis är nu tillgängligt i de flesta Azure-regioner med planer på att stödjas i andra nationella moln. Mer information om kvorumnod finns i Enterprise- och Enterprise Flash-nivåer. Genom att ta bort den oanvända kvorumnoden får du ökad kostnadseffektivitet eftersom alla noder kan användas som datanoder.
Azure Managed Redis är zonredundant som standard.
Du kan använda Azure Managed Redis utan hög tillgänglighet (HA) för dina utvecklings- och testmiljöer. Om du använder icke-produktionsmiljöer utan HA halveras kostnaden för din instans.
SKU-strukturen för Azure Managed Redis baseras på dina minnes- och prestandabehov. I stället för att hantera skalningsfaktorer eller kapacitet som med Azure Cache for Redis Enterprise kan du välja mellan tre prestandanivåer i Azure Managed Redis. Mer information finns i Välja rätt nivå.
Slutligen erbjuder Azure Managed Redis Microsoft Entra ID-autentisering när du skapar en cache för att förbättra arbetsbelastningens säkerhetsstatus.
Jämförelse av funktioner
| Egenskap | Azure Cache för Redis Enterprise | Azure Managed Redis | 
|---|---|---|
| Redis-version | 7.2 | 7.4 | 
| Klustringsprincip | OSS, Företagslösningar | OSS, Enterprise, Ickeklustrerad | 
| Geo-replication | Active | Active | 
| SLA | Upp till 99.999% | Upp till 99.999% | 
| Zon-redundans | Yes | *Ja med hög tillgänglighet | 
| Icke-HA-läge | No | Ja (för dev/test) | 
| Databeständighet | Ja (i förhandsversion) | Yes | 
| Scaling | Yes | Yes | 
| Stöd för TLS-version | 1.2,1.3 | 1.2,1.3 | 
| Microsoft Entra ID-autentisering | No | Yes | 
| Stöd för Azure-region | Limited | Omfattande | 
| Stöd för Azure Sovereign Cloud | No | Ja (kommer snart) | 
| DNS-suffix för värdnamn | <name>.<region>.redisenterprise.cache.azure.net | <name>.<region>.redis.azure.net | 
* När hög tillgänglighet är aktiverat är Azure Managed Redis zonredundant i regioner med flera tillgänglighetszoner.
Överväganden när du flyttar från Enterprise till Azure Managed Redis
Azure Managed Redis använder samma programvarustack som Azure Cache for Redis Enterprise, så dina befintliga program som använder Enterprise-nivån behöver inte många ändringar. Det viktiga undantaget är behovet av att ändra autentiseringsuppgifterna för anslutningen.
Olika värdnamn och suffix
Även om kärnprogramvaran för Azure Cache for Redis Enterprise och Azure Managed Redis är liknande, skiljer sig DNS-suffixet för redis-klustrets värdnamn. När du flyttar till Azure Managed Redis måste programmet ändra Värdnamnet för Redis-klustret. Om du använder åtkomstnycklar för att ansluta till cacheminnet måste du även uppdatera åtkomstnyckeln som används för att ansluta till cachen.
Viktigt!
Överväg att uppdatera koden som ansluter till cacheminnet. Använd Microsoft Entra-ID i stället för att använda åtkomstnycklar. Vi rekommenderar att du använder Microsoft Entra-ID i stället för åtkomstnycklar.
Välja rätt Azure Managed Redis-storlek och SKU
Azure Managed Redis erbjuder många minnesstorlekar och tre prestandanivåer. Du kan läsa mer information om minnesstorlekar och prestandanivåer här Välja rätt nivå.
Identifiera minnesstorleken för befintlig Azure Cache for Redis Enterprise-instans
Azure Cache for Redis Enterprise-instanser kan skalas ut för att ge både mer minne och fler beräkningsresurser, så det är viktigt att notera utskalningsfaktorn för cacheminnet. Utskalning är också relaterat till kapacitet, vilket i huvudsak är antalet virtuella datorer som körs för klustret.
Så här väljer du rätt minnesstorlek för Azure Managed Redis:
- Gå till Azure-portalen och välj Översikt på resursmenyn.
- Kontrollera fältet Status i Översikt över din Enterprise-instans. Fältet Status visar minnesstorleken för din Redis Enterprise-instans.
Nu ska vi titta på ett möjligt scenario.
Om du tittar på fönstret Statusi översikten ser du Running – Enterprise 8GB (2 x 4GB). Den här notationen innebär att cachen för närvarande använder en E5 Enterprise-SKU med en skala på 2, vilket ger en cache på 8 GB. Därför bör du börja med minst 10 GB cacheminne på Azure Managed Redis.
I det här fallet använder du någon av de nivåer som erbjuder 12 GB minne.
| artikelnummer (SKU) | Tier | 
|---|---|
| M10 | Memory Optimized | 
| B10 | Balanced | 
| X10 | Compute Optimized | 
Identifiera prestandanivå
Du bör också överväga om din arbetsbelastning är minnesintensiv eller beräkningsintensiv. Om din aktuella Enterprise-instans är mer sannolikt att få slut på minne före CPU är din arbetsbelastning minnesintensiv. Överväg att välja från prestandanivån Minnesoptimerad .
Om arbetsbelastningen är genomflödesintensiv eller har alltför hög latens, då är arbetsbelastningen beräkningsintensiv. Överväg att välja från beräkningsoptimerad prestandanivå.
Om du är osäker kan du börja med nivån Balanserad prestanda eftersom den erbjuder en hälsosam blandning av minne och prestanda.
Om du för närvarande använder Redis Enterprise Flash-nivån bör du välja flashoptimerad nivå.
Skapa en ny Azure Managed Redis-instans
När du har valt minnes- och prestandanivå för din nya Azure Managed Redis-instans kan du skapa den nya Azure Managed Redis-instansen. Mer information om hur du skapar en cache finns i Snabbstart: Skapa en Azure Managed Redis-instans.
Därefter måste du välja en strategi för att flytta dina data. Och slutligen måste du uppdatera ditt program för att använda den nya cachen.
Uppdatera appen för att ansluta till Azure Managed Redis-instansen
När du har skapat en ny Azure Managed Redis-instans måste du ändra Redis-slutpunkten/värdnamnet och åtkomstnyckeln i ditt program så att den pekar på din nya Azure Managed Redis-instans. Vi rekommenderar att du publicerar den här slutpunktsändringen utanför kontorstid eftersom det resulterar i ett kortvarigt avbrott i anslutningen.
Note
Om du ansluter till din befintliga Redis Enterprise-instans via en privat slutpunkt kontrollerar du att din nya Azure Managed Redis-cache också är peer-kopplad till programmets virtuella nätverk. Den nya cachen måste ha en liknande konfiguration som den befintliga Redis Enterprise-instansen.
Kontrollera att programmet körs som förväntat och ta sedan bort din tidigare Redis Enterprise-instans.
Flytta dina data från Enterprise-cachen till en ny Azure Managed Redis-cache
När du migrerar till Azure Managed Redis-instansen måste du överväga det bästa sättet att flytta dina data från den befintliga Redis Enterprise-instansen till din nya Azure Managed Redis-instans. Om ditt program kan tolerera dataförlust eller har andra mekanismer för att extrahera cachen utan negativa effekter hoppar du över det här steget och fortsätter till nästa steg.
Om ditt program måste se till att data också migreras till den nya Azure Managed Redis-instansen väljer du något av följande alternativ:
Dataexport och import med hjälp av en RDB-fil
- Fördelar: Bevarar ögonblicksbild av data.
- Nackdelar: Risk för dataförlust om skrivningar inträffar efter en ögonblicksbild.
Här är den grundläggande export-/importproceduren:
- Exportera RDB från befintlig Redis Enterprise-cache till ditt Azure Storage-konto.
- Importera data från Azure Storage-kontot till en ny Azure Managed Redis-cache.
- Läs mer om dataexport/import här Importera och exportera data i Azure Managed Redis.
Strategin för Dual-Write
- Fördelar: Noll stilleståndstid, säker övergång.
- Nackdelar: Kräver tillfällig installation med dubbla cacheminnen.
Här är den grundläggande dubbelskrivningsproceduren:
- Ändra ditt program så att det skriver till befintligt både Azure Cache for Redis Enterprise-cacheminnet och den nya Azure Managed Redis-cachen.
- Fortsätt läsa och skriva från Redis Enterprise-cacheminnet.
- Efter tillräcklig datasynkronisering växlar du läsoperationer till Azure Managed Redis och tar bort Redis Enterprise-instansen
Programmatisk migrering med RIOT-X
RIOT-X är ett sätt att migrera ditt innehåll från Enterprise till Azure Managed Redis. Mer information finns i Datamigrering med RIOT-X för Azure Managed Redis.
- Fördelar: Fullständig kontroll, anpassningsbar.
- Nackdelar: Kräver utvecklingsarbete.
Fördelar med att flytta från Basic-, Standard- eller Premium-cacheminnen till Azure Managed Redis
Om du använder någon av OSS-SKU:erna, Basic, Standard eller Premium, erbjuder övergången till Azure Managed Redis fler funktioner på varje cachenivå.
Här är en tabell som jämför funktionerna från Azure Cache for Redis med funktionerna i Azure Managed Redis
| Funktionsbeskrivning | Basic OSS | Standard OSS | Premium OSS | Balanced AMR | Memory Optimized AMR | Compute Optimized AMR | 
|---|---|---|---|---|---|---|
| Availability | N/A | 99.9% | 99.9% | Upp till 99.999% | Upp till 99.999% | Upp till 99.999% | 
| Datakryptering under överföring | Yes | Yes | Yes | Yes | Yes | Yes | 
| Nätverksisolering | Yes | Yes | Yes | Yes | Yes | Yes | 
| Skala upp/ut | Yes | Yes | Yes | Yes | Yes | Yes | 
| Skala ner/in | Yes | Yes | Yes | No | No | No | 
| OSS-klustring | No | No | Yes | Yes | Yes | Yes | 
| Databeständighet | No | No | Yes | Yes | Yes | Yes | 
| Zon-redundans | No | Ja (förhandsversion) | Yes | *Ja med hög tillgänglighet | *Ja med hög tillgänglighet | *Ja med hög tillgänglighet | 
| Geo-replication | No | No | Ja (passiv) | Ja (aktiv) | Ja (aktiv) | Ja (aktiv) | 
| Anslutningsgranskningsloggar | No | No | Yes | Yes(Event-based) | Yes(Event-based) | Yes(Event-based) | 
| Redis-moduler | No | No | No | Yes | Yes | Yes | 
| Import/Export | No | No | Yes | Yes | Yes | Yes | 
| Reboot | Yes | Yes | Yes | No | No | No | 
| Schemalagda uppdateringar | Yes | Yes | Yes | No | No | No | 
| Microsoft Entra ID-autentisering | Yes | Yes | Yes | Yes | Yes | Yes | 
| Microsoft Entra ID RBAC (Rollbaserad åtkomstkontroll) | Yes | Yes | Yes | No | No | No | 
| Meddelande om Keyspace | Yes | Yes | Yes | No | No | No | 
| Ej hög tillgänglighet | N/A | No | No | Yes | Yes | Yes | 
              OSS refererar till Azure Cache for Redis
              AMR refererar till Azure Managed Redis
* När hög tillgänglighet är aktiverat är Azure Managed Redis zonredundant i regioner med flera tillgänglighetszoner.
Här följer några andra skillnader att tänka på när du implementerar Azure Managed Redis. Överväg dessa ändringar av klientprogrammet:
| Funktionsbeskrivning | Azure-cache för Redis | Azure Managed Redis | 
|---|---|---|
| DNS-suffix (endast för PROD-moln) | .redis.cache.windows.net | <region>.redis.azure.net | 
| TLS-port | 6380 | 10000 | 
| Icke-TLS-port | 6379 | Stöds inte | 
| TLS-portar för enskilda noder | 13XXX | 85xx | 
| Enskild nod som inte är TLS-port | 15XXX | Stöds inte | 
| Stöd för klustring | OSS-klustringsläge | OSS- och Enterprise-klusterlägen | 
| Kommandon som inte stöds | Kommandon som inte stöds | Kommandon med flera tangenter | 
| Regional tillgänglighet | Alla Azure-regioner | * Se listan över regioner efter det här avsnittet. | 
| Redis-version | 6 | 7.4 | 
| TLS-versioner som stöds | 1.2 och 1.3 | 1.2 och 1.3 | 
Migrera din Basic-, Standard- eller Premium-cache till Azure Managed Redis
Baserat på tabellen finns här några mappningar mellan Azure Cache for Redis SKU:er och alternativ för cacheminnen i Azure Managed Redis.
Note
Använd alternativet för icke-hög tillgänglighet för Azure Managed Redis för migrering av grundläggande SKU:er
| Azure-cache för Redis | Azure Managed Redis | Ytterligare minne (%) | 
|---|---|---|
| Basic/Standard – C0 | Balanserad – B0 | 50 | 
| Basic/Standard – C1 | Balanserad – B1 | 0 | 
| Basic/Standard – C2 | Balanserad – B3 | 17 | 
| Basic/Standard – C3 | Balanserad – B5 | 0 | 
| Basic/Standard – C4 | Minnesoptimerad – M10* | -8 | 
| Bas/Standard – C4 | Minnesoptimerad – M20** | 46 | 
| Basic/Standard – C5 | Minnesoptimerad – M20* | -8 | 
| Grundläggande/Standard – C5 | Minnesoptimerad – M50** | 57 | 
| Basic/Standard – C6 | Minnesoptimerad – M50 | 12 | 
| Premium – P1 | Balanserad – B5 | 0 | 
| Premium – P2 | Balanserad – B10* | -8 | 
| Premium – P2 | Balanserad – B20** | 46 | 
| Premium – P3 | Balanserad – B20* | -8 | 
| Premium – P3 | Balanserad – B50** | 57 | 
| Premium – P4 | Balanserad – B50 | 12 | 
| Premium – P5 | Balanserad – B100 | 0 | 
- * Det här alternativet är för kostnadseffektivitet. Se till att den totala mängden använt minne under den senaste månaden är mindre än det föreslagna Azure Managed Redis-minnet för att välja det här alternativet.
- ** Det här alternativet är för riklig minnesförbrukning.
Azure Cache for Redis Premium klustrad
- För fragmenterade kluster väljer du en minnesoptimerad nivå som har motsvarande totalt minne.
- För kluster med mer än en läsreplik väljer du en beräkningsoptimerad nivå med motsvarande totalt minne som primär replik.
Migreringsalternativ
Klientprogram bör kunna använda en Azure Managed Redis-instans som har olika klusterlägen och slutpunkter. Azure Cache for Redis och Azure Managed Redis är kompatibla, så inga andra programkodändringar än anslutningskonfigurationer krävs för de flesta scenarier.
Läs mer på:
Alternativ för att migrera Azure Cache for Redis till Azure Managed Redis
| Option | Advantages | Disadvantages | 
|---|---|---|
| Skapa en ny cache | Enklast att implementera. | Behöver fylla i data till den nya cachen, vilket kanske inte fungerar med många program. | 
| Exportera och importera data via RDB-fil | Kompatibel med alla Redis-cacheminnen i allmänhet. | Vissa data kan gå förlorade om de skrivs till den befintliga cachen när RDB-filen har genererats. | 
| Dubbelskrivningsdata till två cacheminnen | Ingen dataförlust eller stilleståndstid. Oavbruten drift av den befintliga cachen. Enklare testning av den nya cachen. | Behöver två cacher under en längre tidsperiod. | 
| Migrera data programmatiskt | Fullständig kontroll över hur data flyttas. | Kräver anpassad kod. | 
Skapa en ny Azure Cache for Redis
Den här metoden är tekniskt sett inte en migrering. Om dataförlust inte är ett problem är det enklaste sättet att flytta till Azure Managed Redis-nivån att skapa en ny cacheinstans och ansluta ditt program till den. Om du till exempel använder Redis som en cache med databasposter kan du enkelt återskapa cacheminnet från grunden. Allmänna steg för att implementera det här alternativet är:
- Skapa en ny Azure Managed Redis-instans.
- Uppdatera programmet så att det använder den nya instansen.
- Ta bort den gamla Azure Cache for Redis-instansen.
Exportera data till en RDB-fil och importera dem till Azure Managed Redis
Det här alternativet gäller endast för premiumnivåcacheminnen. Redis med öppen källkod definierar en standardmekanism för att ta en ögonblicksbild av en cacheminnesdatauppsättning och spara den i en fil. En annan Redis-cache kan läsa RDB-filen som exporterades. Azure Cache for Redis premiumnivå stöder export av data från en cacheinstans via RDB-filer. Du kan använda en RDB-fil för att överföra data från en befintlig Azure Cache for Redis-instans till Azure Managed Redis-instansen.
Allmänna steg för att implementera det här alternativet är:
- Skapa en ny Azure Managed Redis-instans som har samma storlek (eller större än) den befintliga Azure Cache for Redis-instansen.
- Exportera RDB-filen från en befintlig Azure Cache for Redis-instans med hjälp av dessa exportinstruktioner eller PowerShell Export-cmdleten
- Importera RDB-filen till den nya Azure Managed Redis-instansen med hjälp av dessa importinstruktioner eller PowerShell-import-cmdleten
- Uppdatera programmet så att det använder den nya Azure Managed Redis-instansen anslutningssträng.
Skriv till två Redis-cacheminnen samtidigt under migreringsperioden
I stället för att flytta data direkt mellan cacheminnen kan du använda ditt program för att skriva data till både en befintlig cache och en ny som du konfigurerar. Programmet läser fortfarande data från den befintliga cachen från början. När den nya cachen har nödvändiga data växlar du programmet till cacheminnet och drar tillbaka den gamla. Anta till exempel att du använder Redis som ett sessionsarkiv och att programsessionerna är giltiga i sju dagar. När du har skrivit till de två cacheminnena i en vecka är du säker på att den nya cachen innehåller all icke-förbrukad sessionsinformation. Du kan lita på det från och med då utan att behöva bry dig om dataförlust.
Allmänna steg för att implementera det här alternativet är:
- Skapa en ny Azure Managed Redis-instans som är lika stor som (eller större än) den befintliga Azure Cache for Redis-instansen.
- Ändra programkoden så att den skrivs till både den nya och den ursprungliga instansen.
- Fortsätt att läsa data från den ursprungliga instansen tills den nya instansen är tillräckligt fylld med data.
- Uppdatera programkoden till att endast läsa och skriva från den nya instansen.
- Ta bort den ursprungliga instansen.
Migrera programmatiskt
Skapa en anpassad migreringsprocess genom att programmatiskt läsa data från en befintlig Azure Cache for Redis-instans och skriva dem till Azure Managed Redis-instansen. Det finns två öppen källkod verktyg som du kan prova:
- 
              Redis-copy
- Det här verktyget med öppen källkod kan användas för att kopiera data från en Azure Cache for Redis-instans till en annan. Det här verktyget är användbart för att flytta data mellan cacheinstanser i olika Azure Cache-regioner. En kompilerad version är också tillgänglig. Du kan också se källkoden som en användbar guide för att skriva ett eget migreringsverktyg.
 
- 
              RIOT
- RIOT är ett annat populärt migreringsverktyg som testats av Redis community. Det är ett kommandoradsverktyg som hjälper dig att hämta data till och från Redis.
 
Note
Det här verktyget stöds inte officiellt av Microsoft.
Allmänna steg för att implementera det här alternativet är:
- Skapa en virtuell dator i den region där den befintliga cachen finns. Om datamängden är stor väljer du en relativt kraftfull virtuell dator för att minska kopieringstiden.
- Skapa en ny Azure Managed Redis-instans.
- Rensa data från den nya cachen för att säkerställa att den är tom. Det här steget krävs eftersom själva kopieringsverktyget inte skriver över någon befintlig nyckel i målcachen. Viktigt: Se till att INTE rensa från källcachen.
- Använd ett program som verktyget med öppen källkod som nämndes tidigare för att automatisera kopieringen av data från källcachen till målet. Kom ihåg att kopieringsprocessen kan ta ett tag att slutföra beroende på storleken på din datauppsättning.
Regional tillgänglighet för Azure Managed Redis
Azure Managed Redis expanderar kontinuerligt till nya regioner. Information om hur du kontrollerar tillgängligheten per region finns i Produkter som är tillgängliga per region.
