Vanliga frågor och svar om Azure Cache for Redis

Redis-projektet med öppen källkod har ändrats till en modell med dubbla licenser med stöd för Redis Source Available License version 2 (RSALv2) eller serversidans offentliga licensversion 1 (SSPLv1). Mer information finns i Redis pressmeddelande . Se även Microsoft-blogginlägget om Redis-licensändringen.

Nej, Azure Cache for Redis erbjuds till kunder enligt Microsofts tjänstvillkor. RSALv2- och SSPLv1-licenserna gäller inte för din användning av Azure Cache for Redis.

Ja, Azure Cache for Redis, Azure Cache for Redis Enterprise och Enterprise Flash fortsätter att ta emot korrigeringar och felkorrigeringar även efter licensieringsmeddelandet.

Det krävs ingen åtgärd för våra Azure-kunder när det gäller licensieringsmeddelandet.

• Hanterad cachetjänst – Managed Cache-tjänsten drogs tillbaka den 30 november 2016.

• Cachelagring i rollen – Cachen i rollen drogs tillbaka den 30 november 2016.

Du bör migrera alla cacheminnen med ett beroende av Cloud Services (klassisk). I augusti 2021 meddelade vi att Cloud Services (klassisk) kommer att dras tillbaka den 31 augusti 2024. Alla instanser av Azure Cache for Redis som är beroende av Cloud Services (klassisk) måste dras tillbaka vid samma datum.

Du bör migrera cacheminnen med ett beroende av Cloud Services (klassisk) före den 31 augusti 2024.

Vi har gjort ett försök att migrera så många cacheminnen som möjligt. På grund av detta påverkas få cacheminnen och kunder.

Kontrollera Azure Advisor-Rekommendationer. Om cachen påverkas visas en rekommendation i din prenumeration.

Vi har migrerat de flesta cacheminnen från att byggas på Cloud Services (klassisk) till att byggas på Azure Virtual Machine Scale Sets. Om du migrerar till Skalningsuppsättningar för virtuella Azure-datorer tar du bort beroendet. Det finns tre sätt att initiera den här processen för cacheminnen i ett virtuellt nätverk:

• Migrera till en ny cache med hjälp av privata länkar.

  Skapa en ny cache som använder Private Link för nätverksisolering i stället för inmatning av virtuella nätverk och migrera dina data till den här cachen. Det här alternativet ger dig den bästa och säkraste nätverksisoleringsupplevelsen, samtidigt som du ser till att alla nya cacheminnen skapas med uppdaterad infrastruktur.

• Migrera till en ny cache i ett nytt virtuellt Azure Resource Manager-undernät.

  När du skapar en cache i ett klassiskt virtuellt nätverk skapas en Cloud Services-cache (klassisk) och inte en Azure Virtual Machine Scale Sets-cache. Om du migrerar till en ny cache i ett nytt virtuellt Azure Resource Manager-undernät korrigeras det underliggande beroendet av Cloud Services samtidigt som en liknande virtuell nätverksupplevelse upprätthålls.

  Vi har migrerat de flesta cacheminnen från att byggas på Cloud Services (klassisk) till att byggas på Azure Virtual Machine Scale Sets. Om du vill migrera tar du bort den befintliga cachen och skapar en ny cache i ett nytt azure Resource Manager VNet-undernät. Vi rekommenderar starkt att du inte använder gamla undernät när du migrerar cacheminnen. Rekommenderade alternativ för att migrera data i cacheminnet finns i Migrera till Azure Cache for Redis.

• Automatisk migrering med dataförlust (rekommenderas).

  Vi kan migrera cacheminnen från att använda Cloud Services (klassisk) till att använda vm-skalningsuppsättningar automatiskt, med cachekonfiguration (inklusive åtkomstnycklar och värdnamn) bevarade. Den här metoden kräver dock cirka 30 minuters stilleståndstid och fullständig dataförlust i cacheminnet. Du kan använda import-/exportfunktionen för att spara en kopia av dina data före migreringen.

  Om du vill använda det här alternativet kontaktar azurecachemigration@microsoft.com eller skapar du en supportbegäran för att begära en migrering.

Kontrollera om cachen använder geo-replikering. I så fall måste du migrera dina data från ditt aktuella geo-replikerade par till ett nytt geo-replikerat par.

Till exempel:

1. Skapa ett nytt geo-replikerat par Premium-cacheminnen som matchar samma konfiguration som ditt aktuella cachepar.
2. Ta bort länken mellan ditt ursprungliga par geo-replikerade cacheminnen och exportera en RDB-fil från den primära cachen.
3. Importera RDB-filen till den primära cachen i det nya geo-replikerade paret.

Det nya paret geo-replikerade cacheminnen har inte samma beroende av Cloud Services.

Vi börjar blockera skapandet av nya cacheminnen med hjälp av distributionsmodellen Cloud Services (klassisk). Nya cacheminnen kan fortfarande skapas med den här gamla distributionsmodellen om de skapas i ett virtuellt nätverksundernät som en gång innehöll en Cloud Services-cache, eller om en cache distribueras till ett klassiskt virtuellt nätverk. Om du ser det här meddelandet skapar du ett nytt undernät i ditt virtuella nätverk där cachen ska distribueras. Om du skapar ett undernät i ditt virtuella nätverk säkerställer du att en cache skapas utan Cloud Services-beroendet.

Om du vill kontrollera om du har en eller flera Cloud Services-baserade cacheminnen i undernätet kan du kontrollera Azure Advisor i portalen eller använda rest-API:et resource-navigation-links. Använd API:et resource-navigation-links med ditt prenumerations-ID, resursgruppsnamn, namn på virtuellt nätverk och undernätsnamn för att hämta cacheminnen i det undernät som använder Cloud Services.

Om du skapar en ny cache med hjälp av REST-API:et kontrollerar du också att du inte skickar redis-konfigurationen {"CacheVmType": "CloudService"} tillsammans med begäran om att skapa. Parametrarna är en odokumenterad parameter, så det är osannolikt att du gör detta.

Om du behöver skapa nya cacheminnen med hjälp av distributionsmodellen för Cloud Services (klassisk) kontaktar azurecachemigration@microsoft.com du eller skapar en supportbegäran för att begära ett undantag.

Dessa cacheminnen stängs av och du förlorar alla data i dina cacheminnen.

Pensionering sker i tre faser så att du har maximal tid att migrera:

1. Aktiv fas (nu till 30 april 2023)

   Cacheminnen har fullt stöd, utan någon ändring i status från och med idag. Den här perioden ges för att ge kunderna tid att övergå från Cloud Service (klassisk) med minimalt avbrott.

2. Underhållsfas (1 maj 2023 till 31 december 2023)

   Cacheminnen får kritiska säkerhets-, stabilitets- och felkorrigeringar, men inga nya funktioner.

3. Inaktiv fas (1 januari 2024 till 31 augusti 2024)

   Cacheminnen tar bara emot kritiska säkerhetskorrigeringar. Alla kunder med supportproblem måste migrera till en VMSS-baserad cache innan de får support. Kunder måste flytta från sina cacheminnen senast den 31 augusti 2024.

Nej. Den här tidslinjen gäller endast för cacheminnen som körs på Redis 6.0. Redis 4.0 är en del av en separat tillbakadragning som avslutas innan Cloud Services (klassisk) pensionering. Alla återstående cacheminnen med Redis 4.0 på Cloud Services (klassisk) migreras automatiskt för att använda VM-skalningsuppsättningar och Redis 6.0 efter den 31 oktober 2023. Den här migreringsmetoden kräver stilleståndstid och fullständig dataförlust i cacheminnet, så migrera före det här datumet om du vill undvika stilleståndstid eller dataförlust. Kontakta azurecachemigration@microsoft.com eller skapa en supportbegäran för att begära en automatisk uppgradering före den 31 oktober 2023.

Publicera någon av dina frågor på Q&A-sidan för cloud services (klassisk) tillbakadragning. Du kan också skicka e-post till azurecachemigration@microsoft.com för mer information.

Om din fråga inte visas här kan du meddela oss så att vi kan hjälpa dig att hitta ett svar.

• Om du vill nå en bredare målgrupp kan du publicera en fråga på microsofts Q&A-frågesida för Azure Cache och interagera med Azure Cache-teamet och andra medlemmar i communityn.

• Om du vill göra en funktionsbegäran kan du skicka dina begäranden och idéer till Azure Cache for Redis User Voice.

• Du kan också skicka din fråga till oss på azurecache@microsoft.com.