Azure Managed Redis-architectuur

Azure Managed Redis wordt uitgevoerd op de Redis Enterprise-stack , die aanzienlijke voordelen biedt ten opzichte van de communityversie van Redis. De volgende informatie bevat meer informatie over hoe Azure Managed Redis is ontworpen, inclusief informatie die nuttig kan zijn voor hoofdgebruikers.

Vergelijking met Azure Cache voor Redis

De Basic-, Standard- en Premium-lagen van Azure Cache voor Redis zijn gebouwd op de communityversie van Redis. Deze communityversie van Redis heeft verschillende belangrijke beperkingen, waaronder één thread. Dit vermindert de prestaties aanzienlijk en maakt schalen minder efficiënt omdat er niet volledig gebruik wordt gemaakt van vCPU's door de service. Een typisch Azure Cache voor Redis exemplaar maakt gebruik van een architectuur zoals deze:

U ziet dat twee VIRTUELE machines worden gebruikt: een primaire en een replica. Deze VM's worden ook wel 'knooppunten' genoemd. Het primaire knooppunt bevat het belangrijkste Redis-proces en accepteert alle schrijfbewerkingen. Replicatie wordt asynchroon uitgevoerd naar het replicaknooppunt om een back-upkopie beschikbaar te stellen tijdens onderhoud, uitbreiding of onverwachte storingen. Elk knooppunt kan slechts één Redis-serverproces uitvoeren vanwege het ontwerp met één thread van community Redis.

Verbeteringen in de architectuur van Azure Managed Redis

Azure Managed Redis maakt gebruik van een geavanceerdere architectuur die er ongeveer als volgt uitziet:

Er zijn verschillende verschillen:

• Elke virtuele machine (of knooppunt) voert meerdere Redis-serverprocessen (ook wel 'shards' genoemd) parallel uit. Meerdere shards zorgen voor efficiënter gebruik van vCPU's op elke virtuele machine en hogere prestaties.
• Niet alle primaire Redis-shards bevinden zich op dezelfde VM/hetzelfde knooppunt. In plaats daarvan worden primaire en replica-shards verdeeld over beide knooppunten. Omdat primaire shards meer CPU-resources gebruiken dan replica-shards, kunnen met deze benadering meer primaire shards parallel worden uitgevoerd.
• Elk knooppunt heeft een proxyproces met hoge prestaties voor het beheren van de shards, het afhandelen van verbindingsbeheer en het activeren van zelfherstel.

Deze architectuur maakt zowel hogere prestaties als geavanceerde functies mogelijk, zoals actieve geo-replicatie

Clustervorming

Elk beheerd Redis-exemplaar van Azure is intern geconfigureerd voor het gebruik van clustering in alle lagen en SKU's. Azure Managed Redis is gebaseerd op Redis Enterprise, dat meerdere shards per knooppunt kan gebruiken. Dit omvat kleinere exemplaren die alleen zijn ingesteld voor het gebruik van één shard. Clustering is een manier om de gegevens in het Redis-exemplaar te verdelen over de meerdere Redis-processen, ook wel 'sharding' genoemd. Azure Managed Redis biedt drie clusterbeleidsregels die bepalen welk protocol beschikbaar is voor Redis-clients om verbinding te maken met het cache-exemplaar.

Clusterbeleid

Azure Managed Redis biedt drie clusteringbeleidsregels: OSS, Enterprise en Niet-geclusterd (preview). OSS-clusterbeleid wordt aanbevolen voor de meeste toepassingen omdat het hogere maximale doorvoer ondersteunt, maar er zijn voor- en nadelen voor elke versie.

Het OSS-clusteringbeleid implementeert dezelfde Redis-cluster-API als Azure Cache voor Redis-lagen. Met de Redis-cluster-API kan de Redis-client rechtstreeks verbinding maken met shards op elk Redis-knooppunt, waardoor latentie wordt geminimaliseerd en netwerkdoorvoer wordt geoptimaliseerd, zodat doorvoer bijna lineair kan worden geschaald naarmate het aantal shards en vCPU's toeneemt. Het OSS-clusteringbeleid biedt over het algemeen de beste latentie en doorvoerprestaties. Het OSS-clusterbeleid vereist echter dat uw clientbibliotheek ondersteuning biedt voor de Redis-cluster-API. Tegenwoordig ondersteunen bijna alle Redis-clients de Redis-cluster-API, maar compatibiliteit kan een probleem zijn voor oudere clientversies of gespecialiseerde bibliotheken.

OSS-clusteringbeleid kan niet worden gebruikt met de RediSearch-module.

Voor het OSS-clusteringprotocol moet de client de juiste shardverbindingen maken. De eerste verbinding verloopt via poort 10000. Verbinding maken met afzonderlijke knooppunten wordt uitgevoerd met behulp van poorten in het bereik 85XX. De 85xx-poorten kunnen na verloop van tijd veranderen en mogen niet in uw toepassing worden vastgelegd. Redis-clients die clustering ondersteunen, gebruiken de opdracht CLUSTERKNOOPPUNTen om de exacte poorten te bepalen die worden gebruikt voor de primaire en replica-shards en om de shardverbindingen voor u te maken.

Het clusteringbeleid voor ondernemingen is een eenvoudigere configuratie die gebruikmaakt van één eindpunt voor alle clientverbindingen. Het gebruik van het Enterprise clusterbeleid stuurt alle aanvragen naar één enkel Redis-knooppunt dat vervolgens als proxy wordt gebruikt en die intern verzoeken naar het juiste knooppunt in het cluster doorstuurt. Het voordeel van deze aanpak is dat Azure Managed Redis er niet-geclusterd voor gebruikers uitziet. Dat betekent dat Redis-clientbibliotheken geen ondersteuning hoeven te bieden voor Redis Clustering om enkele prestatievoordelen van Redis Enterprise te verkrijgen. Het gebruik van één eindpunt verhoogt de compatibiliteit met eerdere versies en maakt de verbinding eenvoudiger. Het nadeel is dat de proxy met één knooppunt een knelpunt kan zijn in het rekengebruik of de netwerkdoorvoer.

Het clusteringbeleid voor ondernemingen is de enige die kan worden gebruikt met de RediSearch-module. Hoewel het enterprise-clusterbeleid ervoor zorgt dat een azure Managed Redis-exemplaar niet is geclusterd voor gebruikers, heeft het nog steeds enkele beperkingen met opdrachten met meerdere sleutels.

Het clusteringbeleid voor niet-geclusterde (preview) slaat gegevens op elk knooppunt op zonder sharding. Dit geldt alleen voor caches van 25 GB en kleiner. Scenario's voor het gebruik van niet-geclusterd clusteringbeleid (preview) zijn onder andere:

• Wanneer u migreert vanuit een Redis-omgeving die niet is geshard. Bijvoorbeeld de niet-gefragmenteerde topologieën van Basic, Standard en Premium SKU's van Azure Cache voor Redis.
• Bij het uitvoerig uitvoeren van cross-slot-opdrachten en het verdelen van gegevens in shards zouden er fouten optreden. Bijvoorbeeld de MULTI-opdrachten.
• Wanneer u Redis gebruikt als berichtbroker en geen sharding nodig hebt.

De overwegingen voor het gebruik van niet-geclusterd (preview)-beleid zijn:

• Dit geldt alleen voor Azure Managed Redis-lagen die kleiner zijn dan of gelijk zijn aan 25 GB.
• Het is niet zo goed als andere clusteringbeleidsregels, omdat CPU's alleen meerdere threads met Redis Enterprise-software kunnen gebruiken wanneer de cache is geshard.
• Als u de Azure Managed Redis-cache wilt opschalen, moet u eerst het clusterbeleid wijzigen.
• Als u overstapt van een Basic-, Standard- of Premium-topologie zonder cluster, kunt u OSS-clusters gebruiken om de prestaties te verbeteren. Niet-geclusterde configuraties mogen alleen worden gebruikt als de toepassing geen ondersteuning biedt voor OSS- of Enterprise-topologieën.

Uitschalen of knooppunten toevoegen

De kernsoftware van Redis Enterprise kan omhoog schalen (met behulp van grotere VM's) of uitschalen (door meer knooppunten/VM's toe te voegen). Uiteindelijk bereikt een schaalactie hetzelfde: meer geheugen, meer vCPU's en meer shards toevoegen. Vanwege deze redundantie biedt Azure Managed Redis niet de mogelijkheid om het specifieke aantal knooppunten te beheren dat in elke configuratie wordt gebruikt. Deze implementatiedetails worden geabstraheerd voor de gebruiker om verwarring, complexiteit en suboptimale configuraties te voorkomen. In plaats daarvan is elke SKU ontworpen met een knooppuntconfiguratie om vCPU's en geheugen te maximaliseren. Sommige SKU's van Azure Managed Redis gebruiken slechts twee knooppunten, terwijl er meer worden gebruikt.

Multisleutelopdrachten

Omdat Azure Managed Redis-exemplaren zijn ontworpen met een geclusterde configuratie, ziet CROSSSLOT u mogelijk uitzonderingen op opdrachten die op meerdere sleutels werken. Het gedrag varieert afhankelijk van het gebruikte clusterbeleid. Als u het OSS-clusterbeleid gebruikt, vereisen multi-sleutelopdrachten dat alle sleutels worden toegewezen aan dezelfde hash-slot.

U kunt ook CROSSSLOT fouten zien bij het Enterprise-clusterbeleid. Alleen de volgende multi-key opdrachten zijn toegestaan in slots met Enterprise clustering: DEL, MSET, MGET, EXISTS, UNLINK, en TOUCH.

In Active-Active databases kunnen schrijfopdrachten voor meerdere sleutels (DEL, MSET, UNLINK) alleen worden uitgevoerd op sleutels die zich in dezelfde slot bevinden. De volgende multi-key commando's zijn echter toegestaan tussen slots in Active-Active databases: MGET, EXISTS, en TOUCH. Zie Database-clustering voor meer informatie.

Sharding-configuratie

Elke SKU van Azure Managed Redis is geconfigureerd voor het parallel uitvoeren van een specifiek aantal Redis-serverprocessen, shards . De relatie tussen doorvoerprestaties, het aantal shards en het aantal beschikbare vCPU's op elk exemplaar is ingewikkeld. Het toevoegen van shards verhoogt doorgaans de prestaties omdat Redis-bewerkingen parallel kunnen worden uitgevoerd. nl-NL: Als shards echter geen opdrachten kunnen uitvoeren omdat er geen vCPU's beschikbaar zijn, kan de prestatie daadwerkelijk afnemen. In de volgende tabel ziet u de shardingconfiguratie voor elke beheerde Azure Redis-SKU. Deze shards worden toegewezen om het gebruik van elke vCPU te optimaliseren terwijl vCPU-cycli worden gereserveerd voor Redis Enterprise-proxy-, beheeragent- en besturingssysteemsysteemtaken die ook van invloed zijn op de prestaties.

Opmerking

Azure Managed Redis optimaliseert de prestaties in de loop van de tijd door het aantal shards en vCPU's te wijzigen dat op elke SKU wordt gebruikt.

Belangrijk

Alle in-memory lagen die meer dan 120 GB aan opslagruimte gebruiken, zijn in publieke preview, inclusief Geheugen Geoptimaliseerde M150 en hoger; Gebalanceerde B150 en hoger; en Rekenkracht Geoptimaliseerde X150 en hoger. Al deze lagen en hoger bevinden zich in openbare preview.

Alle voor Flash geoptimaliseerde lagen bevinden zich in openbare preview.

Niveaus	Geoptimaliseerd voor Flash (preview)	Geoptimaliseerd geheugen	Gebalanceerd	Rekenkracht geoptimaliseerd
Grootte (GB)	vCPU's/primaire shards	vCPU's/primaire shards	vCPU's/primaire shards	vCPU's/primaire shards
0,5	-	-	2/1	-
1	-	-	2/1	-
3	-	-	2/2	4/2
6	-	-	2/2	4/2
12	-	2/2	4/2	8 juni
24	-	4/2	8 juni	16 december
60	-	8 juni	16 december	32/24
120	-	16 december	32/24	64/48
180 *	-	24/7	48/48	96/96
240 *	8 juni	32/24	64/48	128/96
360 *	-	48/48	96/96	192/192
480 *	16 december	64/48	128/96	256/192
720 *	24/7	96/96	192/192	384/384
960 *	32/24	128/192	256/192	-
1440 *	48/48	192/192	-	-
1920 *	64/48	256/192	-	-
4500 *	144/96	-	-	-

* Deze lagen bevinden zich in publieke preview.

Uitvoeren zonder modus voor hoge beschikbaarheid ingeschakeld

Het is mogelijk om te draaien zonder de hoge beschikbaarheidsmodus ingeschakeld. Dit betekent dat uw Redis-exemplaar geen replicatie heeft ingeschakeld en geen toegang heeft tot de SLA voor beschikbaarheid. We raden af om in de niet-HA-modus te draaien buiten ontwikkel- en testsituaties. U kunt hoge beschikbaarheid niet uitschakelen in een exemplaar dat al is gemaakt. U kunt hoge beschikbaarheid inschakelen in een exemplaar dat deze niet heeft. Omdat een exemplaar zonder hoge beschikbaarheid minder VM's/knooppunten gebruikt, kunnen vCPU's niet zo efficiënt worden gebruikt, zodat de prestaties mogelijk lager zijn.

Gereserveerd geheugen

Op elk beheerd Redis-exemplaar van Azure wordt ongeveer 20% van het beschikbare geheugen gereserveerd als buffer voor niet-cachebewerkingen, zoals replicatie tijdens failover en actieve geo-replicatiebuffer. Deze buffer helpt de cacheprestaties te verbeteren en geheugenhongering te voorkomen.

Afbouwen

Omlaag schalen wordt momenteel niet ondersteund in Door Azure beheerde redis. Zie Beperkingen voor het schalen van Azure Managed Redis voor meer informatie.

Flash-geoptimaliseerde laag

De Flash-geoptimaliseerde laag maakt gebruik van zowel NVMe Flash-opslag als RAM. Omdat Flash-opslag lager is, kunt u met behulp van de categorie Geoptimaliseerd voor Flash bepaalde prestaties afruilen voor prijsefficiëntie.

Op exemplaren die zijn geoptimaliseerd voor Flash, bevindt 20% van de cacheruimte zich in het RAM-geheugen, terwijl de andere 80% Flash-opslag gebruikt. Alle sleutels worden opgeslagen in ram-geheugen, terwijl de waarden kunnen worden opgeslagen in Flash Storage of RAM. De Redis-software bepaalt op intelligente wijze de locatie van de waarden. Heet waarden die vaak worden gebruikt, worden opgeslagen in RAM, terwijl Koude waarden die minder vaak worden gebruikt, op Flash worden bewaard. Voordat gegevens worden gelezen of geschreven, moeten ze worden verplaatst naar het werkgeheugen, waarbij ze hot gegevens worden.

Omdat Redis optimaliseert voor de beste prestaties, vult het exemplaar eerst het beschikbare RAM-geheugen in voordat items worden toegevoegd aan Flash-opslag. Het vullen van ram-geheugen heeft eerst enkele gevolgen voor prestaties:

• Betere prestaties en lagere latentie kunnen optreden bij het testen met weinig geheugengebruik. Testen met een volledig cache-exemplaar kan lagere prestaties opleveren omdat alleen RAM wordt gebruikt in de testfase met weinig geheugen.
• Naarmate u meer gegevens naar de cache schrijft, neemt het aandeel gegevens in RAM-geheugen af in vergelijking met Flash-opslag, waardoor de latentie en doorvoerprestaties ook afnemen.

Workloads die geschikt zijn voor de Flash-geoptimaliseerde laag

Werklasten die waarschijnlijk goed presteren op de Flash Optimized-laag, hebben vaak de volgende kenmerken:

• Lees zwaar, met een hoge verhouding van leesopdrachten tot schrijfopdrachten.
• Access is gericht op een subset sleutels die veel vaker worden gebruikt dan de rest van de gegevensset.
• Relatief grote waarden in vergelijking met sleutelnamen. (Omdat sleutelnamen altijd in RAM worden opgeslagen, kunnen grote waarden een knelpunt worden voor geheugengroei.)

Workloads die niet geschikt zijn voor de laag Flash Optimized

Sommige workloads hebben toegangskenmerken die minder zijn geoptimaliseerd voor het ontwerp van de laag Flash Optimized:

• Creëer zware werkbelastingen.
• Willekeurige of uniforme patronen voor gegevenstoegang in de meeste gegevenssets.
• Lange sleutelnamen met relatief kleine waardegrootten.

Verwante inhoud

• Een Azure Managed Redis-exemplaar schalen