Vilka är metodtipsen för Enterprise- och Enterprise Flash-nivåerna
Här följer de bästa metoderna när du använder Enterprise- och Enterprise Flash-nivåerna i Azure Cache for Redis.
Zonredundans
Vi rekommenderar starkt att du distribuerar nya cacheminnen i en zonredundant konfiguration. Zonredundans säkerställer att Redis Enterprise-noder sprids mellan tre tillgänglighetszoner, vilket ökar redundansen från avbrott på datacenternivå. Om du använder zonredundans ökar tillgängligheten. Mer information finns i ServiceNivåavtal (SLA) för onlinetjänster.
Zonredundans är viktigt på Enterprise-nivån eftersom cacheinstansen alltid använder minst tre noder. Två noder är datanoder som innehåller dina data och en kvorumnod. Om du ökar kapaciteten skalas antalet datanoder i jämna talsteg.
Det finns också en annan nod som kallas kvorumnod. Den här noden övervakar datanoderna och väljer automatiskt den nya primära noden om det uppstod en redundansväxling. Zonredundans säkerställer att noderna fördelas jämnt över tre tillgänglighetszoner, vilket minimerar risken för kvorumförlust. Kunder debiteras inte för kvorumnoden och det finns ingen annan avgift för att använda zonredundans utöver bandbreddsavgifter inom zon.
Skalning
På Enterprise- och Enterprise Flash-nivåerna i Azure Cache for Redis rekommenderar vi att du prioriterar skalning framför utskalning. Prioritera uppskalning eftersom Enterprise-nivåerna bygger på Redis Enterprise, som kan använda fler CPU-kärnor i större virtuella datorer.
Omvänt gäller den motsatta rekommendationen för nivåerna Basic, Standard och Premium, som bygger på Redis med öppen källkod. I de här nivåerna rekommenderar vi att du prioriterar utskalning framför uppskalning i de flesta fall.
Horisontell partitionering och CPU-användning
På nivåerna Basic, Standard och Premium i Azure Cache for Redis är det enkelt att fastställa antalet virtuella processorer (vCPU:er) som används. Varje Redis-nod körs på en dedikerad virtuell dator. Redis-serverprocessen är enkeltrådad och använder en vCPU på varje primär och varje repliknod. De andra virtuella processorerna på den virtuella datorn används fortfarande för andra aktiviteter, till exempel arbetsflödessamordning för olika uppgifter, hälsoövervakning och TLS-belastning, bland annat.
När du använder klustring är effekten att sprida data över fler noder med en shard per nod. Genom att öka antalet shards ökar du linjärt antalet vCPU:er som du använder, baserat på antalet shards i klustret.
Redis Enterprise kan däremot använda flera vCPU:er för själva Redis-instansen. Med andra ord kan alla nivåer i Azure Cache for Redis använda flera vCPU:er för bakgrunds- och övervakningsuppgifter, men endast Enterprise- och Enterprise Flash-nivåerna kan använda flera vCPU:er per virtuell dator för Redis-shards. Tabellen visar antalet effektiva vCPU:er som används för varje SKU och kapacitetskonfiguration (dvs. utskalning).
Tabellerna visar antalet vCPU:er som används för de primära shardsna, inte replikskärvorna. Shards mappar inte en-till-en till antalet vCPU:er. Tabellerna illustrerar bara vCPU:er, inte shards. Vissa konfigurationer använder fler shards än tillgängliga vCPU:er för att öka prestanda i vissa användningsscenarier.
E5
| Kapacitet | Effektiva vCPU:er |
|---|---|
| 2 | 1 |
| 4 | 2 |
| 6 | 6 |
E10
| Kapacitet | Effektiva vCPU:er |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E20
| Kapacitet | Effektiva vCPU:er |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E50
| Kapacitet | Effektiva vCPU:er |
|---|---|
| 2 | 6 |
| 4 | 6 |
| 6 | 6 |
| 8 | 30 |
| 10 | 30 |
E100
| Kapacitet | Effektiva vCPU:er |
|---|---|
| 2 | 6 |
| 4 | 30 |
| 6 | 30 |
| 8 | 30 |
| 10 | 30 |
E200
| Kapacitet | Effektiva vCPU:er |
|---|---|
| 2 | 30 |
| 4 | 60 |
| 6 | 60 |
| 8 | 120 |
| 10 | 120 |
E400
| Kapacitet | Effektiva vCPU:er |
|---|---|
| 2 | 60 |
| 4 | 120 |
| 6 | 120 |
| 8 | 240 |
| 10 | 240 |
F300
| Kapacitet | Effektiva vCPU:er |
|---|---|
| 3 | 6 |
| 9 | 30 |
F700
| Kapacitet | Effektiva vCPU:er |
|---|---|
| 3 | 30 |
| 9 | 30 |
F1500
| Kapacitet | Effektiva vCPU:er |
|---|---|
| 3 | 30 |
| 9 | 90 |
Klustring på företag
Enterprise- och Enterprise Flash-nivåerna är i sig klustrade, till skillnad från nivåerna Basic, Standard och Premium. Implementeringen beror på vilken klustringsprincip som har valts. Enterprise-nivåerna erbjuder två alternativ för klustringsprincip: OSS och Enterprise. OSS-klusterprincip rekommenderas för de flesta program eftersom den stöder högre maximalt dataflöde, men det finns fördelar och nackdelar med varje version.
OSS-klustringsprincipen implementerar samma Redis-kluster-API som Redis med öppen källkod. Redis-kluster-API:et gör att Redis-klienten kan ansluta direkt till varje Redis-nod, vilket minimerar svarstiden och optimerar nätverkets dataflöde. Därför erhålls nästan linjär skalbarhet när klustret skalas ut med fler noder. OSS-klustringsprincipen ger vanligtvis bästa svarstid och dataflödesprestanda, men kräver att klientbiblioteket stöder Redis-klustring. OSS-klustringsprincipen kan inte heller användas med RediSearch-modulen.
Enterprise-klustringsprincipen är en enklare konfiguration som använder en enda slutpunkt för alla klientanslutningar. Med hjälp av enterprise-klustringsprincipen dirigeras alla begäranden till en enda Redis-nod som sedan används som proxy och som internt dirigerar begäranden till rätt nod i klustret. Fördelen med den här metoden är att Redis-klientbibliotek inte behöver stöd för Redis-klustring för att dra nytta av flera noder. Nackdelen är att proxyn för en nod kan vara en flaskhals, antingen i beräkningsanvändningen eller nätverkets dataflöde. Enterprise-klustringsprincipen är den enda som kan användas med RediSearch-modulen.
Kommandon med flera nycklar
Eftersom Enterprise-nivåerna 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 kräver kommandon med flera nycklar att alla nycklar mappas till samma hash-plats.
Du kan också se CROSSSLOT fel med enterprise-klustringsprincipen. Endast följande flernyckelkommandon tillåts mellan platser med Enterprise-klustring: DEL, MSET, MGET, EXISTS, UNLINKoch TOUCH.
I Active-Active-databaser kan skrivkommandon med flera nycklar (DEL, MSET, UNLINK) endast köras på nycklar som finns i samma fack. Följande kommandon med flera nycklar tillåts dock mellan platser i Active-Active-databaser: MGET, EXISTSoch TOUCH. Mer information finns i Databaskluster.
Metodtips för Enterprise Flash
Enterprise Flash-nivån använder både NVMe Flash Storage och RAM. Eftersom Flash Storage är en lägre kostnad kan du med hjälp av Enterprise Flash-nivån kompromissa med vissa prestanda för priseffektivitet.
På Enterprise Flash-instanser finns 20 % av cacheutrymmet på RAM-minne, 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. Platsen för värdena bestäms intelligent av Redis-programvaran. "Frekventa" värden som används lagras fequently på RAM-minnet, medan "Kalla" värden som används mindre ofta sparas på Flash. Innan data läs- eller skrivs måste de flyttas till RAM-minne och bli "frekventa" data.
Eftersom Redis väljer bästa prestanda fyller instansen först upp det tillgängliga RAM-minnet innan objekt läggs till i Flash Storage. Detta har några konsekvenser för prestanda:
- Vid testning med låg minnesanvändning kan prestanda och svarstid vara betydligt bättre än med en fullständig cacheinstans eftersom endast RAM används.
- 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 Enterprise Flash-nivån
Arbetsbelastningar som sannolikt kommer att köras bra på Enterprise Flash-nivån 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 används mycket oftare än resten av datamängden.
- Relativt stora värden jämfört med nyckelnamn. (Eftersom nyckelnamn alltid lagras i RAM kan detta bli en flaskhals för minnestillväxt.)
Arbetsbelastningar som inte passar bra för Enterprise Flash-nivån
Vissa arbetsbelastningar har åtkomstegenskaper som är mindre optimerade för designen av Flash-nivån:
- Skriva tunga arbetsbelastningar.
- Slumpmässig eller enhetlig dataåtkomst i större delen av datamängden.
- Långa nyckelnamn med relativt små värdestorlekar.
Hantera scenarier för region ned med aktiv geo-replikering
Aktiv geo-replikering är en kraftfull funktion för att avsevärt öka tillgängligheten när du använder Enterprise-nivåerna i Azure Cache for Redis. Du bör dock vidta åtgärder för att förbereda dina cacheminnen om det uppstår ett regionalt avbrott.
Tänk till exempel på följande tips:
- Identifiera i förväg vilken annan cache i geo-replikeringsgruppen som ska växlas över till om en region slutar fungera.
- Se till att brandväggar har angetts så att alla program och klienter kan komma åt den identifierade cachen för säkerhetskopiering.
- Varje cache i gruppen geo-replikering har en egen åtkomstnyckel. Avgör hur programmet växlar till olika åtkomstnycklar när du riktar in dig på en cache för säkerhetskopiering.
- Om en cache i gruppen geo-replikering går ned börjar en uppbyggnad av metadata ske i alla cacheminnen i gruppen geo-replikering. Metadata kan inte ignoreras förrän skrivningar kan synkroniseras igen till alla cacheminnen. Du kan förhindra att metadata byggs upp genom att framtvinga avlänkning av cacheminnet som ligger nere. Överväg att övervaka det tillgängliga minnet i cacheminnet och ta bort länkning om det finns minnesbelastning, särskilt för skrivintensiva arbetsbelastningar.
Det går också att använda ett kretsbrytarmönster. Använd mönstret för att automatiskt omdirigera trafik bort från en cache som drabbas av ett regionstopp och mot en säkerhetskopieringscache i samma geo-replikeringsgrupp. Använd Azure-tjänster som Azure Traffic Manager eller Azure Load Balancer för att aktivera omdirigeringen.
Datapersistence jämfört med säkerhetskopiering av data
Funktionen för datapersistence på Enterprise- och Enterprise Flash-nivåerna är utformad för att automatiskt tillhandahålla en snabb återställningspunkt för data när ett cacheminne går ned. Snabbåterställningen möjliggörs genom att RDB- eller AOF-filen lagras på en hanterad disk som är monterad på cacheinstansen. Beständighetsfiler på disken är inte tillgängliga för användare.
Många kunder vill använda beständighet för att utföra regelbundna säkerhetskopieringar av data i cacheminnet. Vi rekommenderar inte att du använder datapersistence på det här sättet. Använd i stället funktionen import/export . Du kan exportera kopior av cachedata i RDB-format direkt till ditt valda lagringskonto och utlösa dataexporten så ofta du behöver. Export kan utlösas antingen från portalen eller med hjälp av CLI-, PowerShell- eller SDK-verktygen.