Architectuur van Azure Managed Redis (preview)
Azure Managed Redis (preview) 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.
Belangrijk
Azure Managed Redis is momenteel in PREVIEW. Raadpleeg de Aanvullende voorwaarden voor Microsoft Azure-previews voor juridische voorwaarden die van toepassing zijn op Azure-functies die in bèta of preview zijn of die anders nog niet algemeen beschikbaar zijn.
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 versie van Redis heeft verschillende belangrijke beperkingen, waaronder een ontwerp met éé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 op het replicaknooppunt om een back-upkopie te bieden tijdens onderhoud, schalen of onverwachte fouten. 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
Clustering
Omdat Redis Enterprise meerdere shards per knooppunt kan gebruiken, is elk Beheerd Redis-exemplaar van Azure intern geconfigureerd voor het gebruik van clustering, in alle lagen en SKU's. 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 twee clusterbeleidsregels die bepalen welk protocol beschikbaar is voor Redis-clients om verbinding te maken met het cache-exemplaar.
Clusterbeleid
Azure Managed Redis biedt twee opties voor clusterbeleid: OSS en Enterprise. 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 redis-editie Redis. 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 ook niet worden gebruikt met de RediSearch-module.
Het clusteringbeleid voor ondernemingen is een eenvoudigere configuratie die gebruikmaakt van één eindpunt voor alle clientverbindingen. Met behulp van het clusterbeleid voor ondernemingen worden alle aanvragen gerouteerd naar één Redis-knooppunt dat vervolgens wordt gebruikt als proxy, intern routeringsaanvragen naar het juiste knooppunt in het cluster. Het voordeel van deze benadering is dat Azure Managed Redis er niet-geclusterd voor gebruikers uitziet. Dit betekent dat Redis-clientbibliotheken redis-clustering niet hoeven te ondersteunen om enkele prestatievoordelen van Redis Enterprise te verkrijgen, compatibiliteit met eerdere versies te stimuleren en de verbinding eenvoudiger te maken. 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 een Azure Managed Redis-exemplaar lijkt te zijn die niet is geclusterd voor gebruikers, heeft het nog steeds enkele beperkingen met opdrachten met meerdere sleutels.
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 met 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. Als shards echter geen opdrachten kunnen uitvoeren omdat er geen vCPU's beschikbaar zijn om opdrachten uit te voeren, kunnen de prestaties daadwerkelijk worden verwijderd. 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.
Notitie
Het aantal shards en vCPU's dat op elke SKU wordt gebruikt, kan na verloop van tijd veranderen omdat de prestaties worden geoptimaliseerd door het Azure Managed Redis-team.
| Lagen | Flash geoptimaliseerd | Geoptimaliseerd geheugen | Gebalanceerd | Geoptimaliseerde rekenkracht |
|---|---|---|---|---|
| Grootte (GB) | vCPU's/primaire shards | vCPU's/primaire shards | vCPU's/primaire shards | vCPU's/primaire shards |
| 0,5 | - | - | 2/2 | - |
| 1 | - | - | 2/2 | - |
| 3 | - | - | 2/2 | 4/2 |
| 6 | - | - | 2/2 | 4/2 |
| 12 | - | 2/2 | 4/2 | 8/6 |
| 24 | - | 4/2 | 8/6 | 16/12 |
| 60 | - | 8/6 | 16/12 | 32/24 |
| 120 | - | 16/12 | 32/24 | 64/48 |
| 180 | - | 24/24 | 48/48 | 96/96 |
| 240 | 8/6 | 32/24 | 64/48 | 128/96 |
| 360 | - | 48/48 | 96/96 | 192/192 |
| 480 | 16/12 | 64/48 | 128/96 | 256/192 |
| 720 | 24/24 | 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 | - | - | - |
Uitvoeren zonder modus voor hoge beschikbaarheid ingeschakeld
Het is mogelijk om te worden uitgevoerd zonder hoge beschikbaarheidsmodus ingeschakeld. Dit betekent dat uw Redis-exemplaar geen replicatie heeft ingeschakeld en geen toegang heeft tot de SLA voor beschikbaarheid. Het wordt afgeraden om buiten ontwikkel-/testscenario's te worden uitgevoerd in de niet-HA-modus. 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.
Omlaag schalen
Omlaag schalen wordt momenteel niet ondersteund in Azure Managed Redis. Zie Vereisten/beperkingen voor het schalen van Azure Managed Redis voor meer informatie.
Laag geoptimaliseerd voor Flash
De laag Flash geoptimaliseerd voor Flash 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. Dynamische waarden die vaak worden gebruikt, worden opgeslagen in ram-geheugen, terwijl koude waarden die minder vaak worden gebruikt, op Flash worden bewaard. Voordat gegevens worden gelezen of geschreven, moeten ze worden verplaatst naar ram-geheugen en worden ze dynamische gegevens.
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 laag Flash Optimized
Werkbelastingen die waarschijnlijk goed worden uitgevoerd op de laag Flash Optimized, 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:
- Schrijf zware werkbelastingen.
- Willekeurige of uniforme patronen voor gegevenstoegang in de meeste gegevenssets.
- Lange sleutelnamen met relatief kleine waardegrootten.