Azure Managed Redis-arkitektur

Azure Managed Redis körs på Redis Enterprise-stacken , vilket ger betydande fördelar jämfört med communityversionen av Redis. Följande information innehåller mer information om hur Azure Managed Redis är konstruerat, inklusive information som kan vara användbar för användare.

Jämförelse med Azure Cache for Redis

Nivåerna Basic, Standard och Premium i Azure Cache for Redis körs på communityversionen av Redis. Den här versionen av Redis för communitybruk har flera betydande begränsningar, inklusive att vara enkeltrådad. Den här begränsningen minskar prestanda avsevärt och gör skalningen mindre effektiv eftersom tjänsten inte använder fler virtuella processorer fullt ut. En typisk Azure Cache for Redis-instans använder en arkitektur som den här:

Observera att två virtuella datorer används – en primär och en replik. Dessa virtuella datorer kallas också noder. Den primära noden innehåller den huvudsakliga Redis-processen och accepterar alla skrivningar. Replikeringen utförs asynkront till repliknoden för att tillhandahålla en säkerhetskopieringskopia under underhåll, skalning eller oväntat fel. Varje nod kan bara köra en enskild Redis-serverprocess på grund av den enkeltrådade designen av communityn Redis.

Arkitektoniska förbättringar av Azure Managed Redis

Azure Managed Redis använder en mer avancerad arkitektur som ser ut ungefär så här:

Det finns flera skillnader:

• Varje virtuell dator (eller nod) kör flera Redis-serverprocesser (kallas shards) parallellt. Flera shards möjliggör effektivare användning av vCPU:er på varje virtuell dator och högre prestanda.
• Alla primära Redis-shards finns inte på samma virtuella dator/nod. I stället distribueras primära och replika skärvor över båda noderna. Eftersom primära shards använder fler CPU-resurser än replikskärvor gör den här metoden att fler primära shards kan köras parallellt.
• Varje nod har en proxyprocess med höga prestanda för att hantera shards, hantera anslutningshantering och utlösa självåterställning.

Den här arkitekturen möjliggör både högre prestanda och avancerade funktioner som aktiv geo-replikering.

Klustring

Varje Azure Managed Redis-instans är internt konfigurerad för att använda klustring på alla nivåer och SKU:er. Azure Managed Redis baseras på Redis Enterprise, som kan använda flera shards per nod. Den funktionen innehåller mindre instanser som bara har konfigurerats för att använda en enda shard. Klustring är ett sätt att dela upp data i Redis-instansen över flera Redis-processer, även kallat horisontell partitionering. Azure Managed Redis erbjuder tre klusterprinciper som avgör vilket protokoll som är tillgängligt för Redis-klienter för anslutning till cacheinstansen.

Klusterriktlinjer

Azure Managed Redis erbjuder tre klustringsprinciper: OSS, Enterprise och Icke-klustrad. OSS-klusterprincipen är bra för de flesta program eftersom den stöder högre maximalt dataflöde, men varje version har sina egna fördelar och nackdelar.

• Om du flyttar från en icke-klustrad topologi av Basic, Standard eller Premium kan du överväga att använda OSS-klustring för att förbättra prestandan. Använd endast icke-klustrade konfigurationer om programmet inte har stöd för OSS- eller Enterprise-topologier. OSS-klustringsprincipen implementerar samma API som Redis programvara med öppen källkod. Redis-kluster-API:et gör att Redis-klienten kan ansluta direkt till shards på varje Redis-nod, vilket minimerar svarstiden och optimerar nätverkets dataflöde. Dataflödet skalas nästan linjärt när antalet shards och vCPU:er ökar. OSS-klustringsprincipen erbjuder vanligtvis lägsta svarstid och bästa dataflödesprestanda. DOCK KRÄVER OSS-klusterprincipen att klientbiblioteket stöder Redis-kluster-API:et. I dag stöder nästan alla Redis-klienter Redis-kluster-API:et, men kompatibilitet kan vara ett problem för äldre klientversioner eller specialiserade bibliotek.

Du kan inte använda OSS-klustringsprincipen med RediSearch-modulen.

OSS-klustringsprotokollet kräver att klienten gör rätt shardanslutningar. Den första anslutningen sker via port 10000. Anslutning till enskilda noder använder portar i 85XX-intervallet. 85xx-portarna kan ändras med tiden och du bör inte hårdkoda dem i ditt program. Redis-klienter som stöder klustring använder kommandot KLUSTERNODER för att fastställa de exakta portarna som används för de primära partitionerna och replikskärvorna och göra shardanslutningarna åt dig.

Enterprise-klustringsprincipen är en enklare konfiguration som använder en enda slutpunkt för alla klientanslutningar. När du använder enterprise-klustringsprincipen dirigeras alla begäranden till en enda Redis-nod som fungerar som proxy. Den här noden dirigerar internt begäranden till rätt nod i klustret. Fördelen med den här metoden är att den gör att Azure Managed Redis ser icke-klustrad ut för användare. Det innebär att Redis-klientbibliotek inte behöver stöd för Redis-klustring för att få några av prestandafördelarna med Redis Enterprise. Att använda en enda slutpunkt ökar bakåtkompatibiliteten och gör anslutningen enklare. Nackdelen är att proxyn för en nod kan vara en flaskhals i antingen beräkningsanvändningen eller nätverkets dataflöde.

Enterprise-klustringsprincipen är den enda som du kan använda med RediSearch-modulen. Även om enterprise-klusterprincipen gör att en Azure Managed Redis-instans verkar vara icke-klustrad för användare, har den fortfarande vissa begränsningar med kommandon med flera nycklar.

Principen för icke-klustrad klustring lagrar data på varje nod utan horisontell partitionering. Det gäller endast cacheminnen med storleken 25 GB och mindre. Scenarier för att använda en icke-klustrad klustringspolicy är:

• När du migrerar från en Redis-miljö som inte är fragmenterad. Till exempel de icke-fragmenterade topologierna för Basic-, Standard- och Premium-SKU:er för Azure Cache for Redis.
• När du kör kommandon över flera platser i stor utsträckning och delar upp data i fragment, skulle det orsaka fel. Till exempel MULTI-kommandona.
• När du använder Redis som meddelandekö och inte behöver horisontell partitionering.

Övervägandena för att använda icke-klustrad policy är:

• Den här principen gäller endast för Azure Managed Redis-nivåer som är mindre än eller lika med 25 GB.
• Det är inte lika effektivt som andra klusterstrategier, eftersom processorer endast kan flertrådas med Redis Enterprise-programvara när cachen är fragmenterad.
• Om du vill skala upp Azure Managed Redis-cachen måste du först ändra klusterprincipen.
• Om du flyttar från en icke-klustrad topologi av Basic-, Standard- eller Premium-typ, kan du överväga att använda kluster för att förbättra systemets prestanda. Använd endast icke-klusterkonfigurationer om programmet inte har stöd för varken OSS- eller Enterprise-topologier.

Skala ut eller lägga till noder

Redis Enterprise-kärnprogramvaran skalas upp med hjälp av större virtuella datorer eller skalas ut genom att lägga till fler noder eller virtuella datorer. Båda skalningsalternativen lägger till mer minne, fler vCPU:er och fler shards. På grund av den här redundansen ger Azure Managed Redis inte möjlighet att styra det specifika antalet noder som används i varje konfiguration. Den här implementeringsinformationen är abstrakt för att undvika förvirring, komplexitet och suboptimala konfigurationer. I stället är varje SKU utformad med en nodkonfiguration som maximerar vCPU:er och minne. Vissa SKU:er för Azure Managed Redis använder två noder, medan andra använder fler.

Kommandon med flera tangenter

Eftersom Azure Managed Redis-instanser använder en klustrad konfiguration kan du se CROSSSLOT undantag för kommandon som körs på flera nycklar. Beteendet varierar beroende på vilken klustringsprincip som används. Om du använder OSS-klustringsprincipen måste alla nycklar i flernyckelkommandon mappas till samma hash-plats.

Du kan också se CROSSSLOT fel med klustringsprincipen för företag. Endast följande multikey-kommandon tillåts mellan platser med Enterprise-klustring: DEL, , MSETMGET, EXISTS, UNLINKoch TOUCH.

I Active-Active databaser kan skrivkommandon för flera nycklar (DEL, MSET, UNLINK) bara köras på nycklar som finns i samma fack. Följande multikey-kommandon tillåts dock mellan platser i Active-Active databaser: MGET, EXISTSoch TOUCH. Mer information finns i Databaskluster.

Shardingkonfiguration

Varje SKU för Azure Managed Redis kör ett visst antal Redis-serverprocesser, så kallade shards, parallellt. Relationen mellan dataflödesprestanda, antalet shards och antalet tillgängliga vCPU:er för varje instans är komplex. Du kan inte ändra antalet shards manuellt.

För en viss minnesstorlek har den minnesoptimerade versionen minst antal vCPU:er och shards, medan den beräkningsoptimerade versionen har högst.

Om du ökar antalet shards ökar vanligtvis prestandan eftersom Redis-åtgärder kan köras parallellt. Men om det inte finns några vCPU:er tillgängliga för att köra kommandon kan prestandan sjunka.

Shards mappas för att optimera användningen av varje vCPU och reserverar samtidigt vCPU-cykler för Redis-serverprocessen, hanteringsagenten och operativsystemets systemuppgifter som också påverkar prestanda. Klientprogrammen som du skapar interagerar med Azure Managed Redis som om det vore en enda logisk databas. Tjänsten hanterar routning mellan vCPU:er och shards.

För att öka antalet shards i en SKU, välj en större nivå inom den aktuella SKU. Du kan också ändra SKU:erna så att de matchar dina prestandabehov.

I följande tabell visas förhållandet mellan vCPU:er och primära shards med en viss nivåstorlek. Data i kolumnerna representerar inte en garanti för att det här är antalet vCPU:er eller shards. Tabellerna är endast till för illustration.

Anmärkning

Azure Managed Redis optimerar prestanda över tid genom att ändra antalet shards och vCPU:er som används på varje SKU.

Minnesoptimerade, balanserade och beräkningsoptimerade versioner

Den här tabellen visar ett allmänt exempel på relationen mellan Storlek och vCPU:er/primära shards.

Nivåer	Minnesoptimerad	Balanserad	Beräkningsoptimerad
Storlek (GB)	vCPU:er/primära skärvor	vCPU:er/primära skärvor	vCPU:er/primära skärvor
24 ¹	4 februari	8 juni	16 december
60 ¹	8 juni	16 december	32/24

¹ Förhållandet mellan vCPUs och primära skärvor vid en viss nivåns storlek representerar inte en garanti för SKU:n eller nivån.

Flash-optimerad version

Den här tabellen visar ett allmänt exempel på relationen mellan Storlek och vCPU:er/primära shards.

Nivåer	Flash Optimized (förhandsversion)
Storlek (GB)	vCPU:er/primära skärvor
480 ¹ ²	16 december
720 ¹ ²	24 timmar om dygnet

¹ Dessa nivåer är i offentlig förhandsversion.

² Förhållandet mellan vCPU:er och primära shards vid en viss nivåstorlek utgör ingen garanti för SKU:n eller nivån.

Viktigt!

Alla minnesinterna nivåer som använder över 235 GB lagringsutrymme finns i offentlig förhandsversion, inklusive Minnesoptimerad M350 och senare. Balanserad B350 och högre; och Compute Optimized X350 och senare. Alla dessa nivåer och högre finns i offentlig förhandsversion.

Alla Flash-optimerade nivåer finns i offentlig förhandsversion.

Körs utan aktiverat läge för hög tillgänglighet

Du kan köra utan att aktivera hög tillgänglighetsläge. Den här konfigurationen innebär att Redis-instansen inte har replikering aktiverad och inte har åtkomst till tillgänglighetsavtalet. Kör inte i icke-HA-läge utanför utvecklings- och testscenarier. Du kan inte inaktivera hög tillgänglighet i en instans som du redan har skapat. Du kan aktivera hög tillgänglighet i en instans som inte har den. Eftersom en instans som körs utan hög tillgänglighet använder färre virtuella datorer och noder används inte virtuella processorer lika effektivt, så prestandan kan vara lägre.

Reserverat minne

På varje Azure Managed Redis-instans reserveras cirka 20% av det tillgängliga minnet som en buffert för icke-cacheåtgärder, till exempel replikering under redundansväxling och aktiv geo-replikeringsbuffert. Den här bufferten hjälper till att förbättra cacheprestanda och förhindra minnessvält.

Skala ned

Nedskalning stöds för närvarande inte på Azure Managed Redis. Mer information finns i Begränsningar för skalning av Azure Managed Redis.

Flash-optimerad nivå

Nivån Flash Optimized använder både NVMe Flash Storage och RAM. Eftersom flashlagring är kostnadseffektivt kan du med nivån Flash-optimerad offra viss prestanda för att uppnå bättre priseffektivitet.

På Flash Optimized-instanser finns 20% av cacheutrymmet på RAM-minnet, medan de andra 80% använder Flash Storage. Alla nycklar lagras på RAM-minnet, medan värdena kan lagras antingen i Flash Storage eller RAM. Redis-programvaran avgör intelligent platsen för värdena. Frekventa värden som används ofta lagras på RAM-minnet, medan kalla värden som används mindre ofta sparas på Flash. Innan data läses eller skrivs måste det flyttas till RAM-minnet och bli hett data.

Eftersom Redis optimerar för bästa prestanda fyller instansen först upp det tillgängliga RAM-minnet innan objekt läggs till i Flash Storage. Att fylla RAM-minnet först har några konsekvenser för prestanda:

• Bättre prestanda och kortare svarstid kan inträffa vid testning med låg minnesanvändning. Testning med en full cache-instans kan ge försämrad prestanda eftersom endast RAM-minne används under testfasen med låg minnesanvändning.
• När du skriver mer data till cacheminnet minskar andelen data i RAM-minnet jämfört med Flash Storage, vilket vanligtvis gör att även svarstid och dataflödesprestanda minskar.

Arbetsbelastningar som passar bra för Flash Optimized-nivån

Arbetsbelastningar som körs bra på flashoptimerad nivå har ofta följande egenskaper:

• Läsintensivt, med ett högt förhållande mellan läskommandon och skrivkommandon.
• Åtkomst fokuserar på en delmängd nycklar som du använder mycket oftare än resten av datamängden.
• Relativt stora värden jämfört med nyckelnamn. (Eftersom nyckelnamn alltid lagras i RAM kan stora värden bli en flaskhals för minnestillväxt.)

Arbetsbelastningar som inte passar bra för Flash Optimized-nivån

Vissa arbetsbelastningar har åtkomstmönster som inte är lika optimerade för designen av Flashoptimerad nivå:

• Skriva tunga arbetsbelastningar.
• Slumpmässiga eller enhetliga dataåtkomstmönster i de flesta datamängder.
• Långa nyckelnamn med relativt små värdestorlekar.

Relaterat innehåll

• Skala en Azure Managed Redis-instans