Azure Managed Redis-architectuur

Azure Managed Redis wordt uitgevoerd op de Redis Enterprise-stack , wat 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 worden uitgevoerd in de communityversie van Redis. Deze communityversie van Redis heeft verschillende belangrijke beperkingen, waaronder één thread. Deze beperking vermindert de prestaties aanzienlijk en maakt schalen minder efficiënt omdat de service niet volledig gebruikmaakt van meer vCPU's. Een typisch Azure Cache voor Redis exemplaar maakt gebruik van een architectuur zoals deze:

U ziet dat er twee VM's 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 elk knooppunt) voert meerdere Redis-serverprocessen (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. Deze mogelijkheid 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. Het OSS-clusterbeleid is geschikt voor de meeste toepassingen omdat het hogere maximale doorvoer ondersteunt, maar elke versie heeft zijn eigen voor- en nadelen.

• Als u overstapt van een niet-geclusterde Basic-, Standard- of Premium-topologie, kunt u OSS-clustering gebruiken om de prestaties te verbeteren. Gebruik alleen niet-geclusterde configuraties als uw toepassing geen ondersteuning biedt voor OSS- of Enterprise-topologieën. Het OSS-clusteringbeleid implementeert dezelfde API als Redis opensource-software. Met de Redis-cluster-API kan de Redis-client rechtstreeks verbinding maken met shards op elk Redis-knooppunt, waardoor de latentie wordt geminimaliseerd en de netwerkdoorvoer wordt geoptimaliseerd. Doorvoer wordt bijna lineair geschaald naarmate het aantal shards en vCPU's toeneemt. Het OSS-clusteringbeleid biedt over het algemeen de laagste latentie en de beste 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.

U kunt oss-clusteringbeleid niet gebruiken 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 maakt gebruik van poorten in het bereik 85XX. De 85xx-poorten kunnen na verloop van tijd veranderen en u moet ze niet in uw toepassing hardcoderen. 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. Wanneer u het enterprise-clusteringbeleid gebruikt, worden alle aanvragen gerouteerd naar één Redis-knooppunt dat als proxy fungeert. Dit knooppunt stuurt aanvragen intern naar het juiste knooppunt in het cluster. 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 u kunt gebruiken 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.

Met het beleid voor niet-geclusterde clustering worden gegevens op elk knooppunt opgeslagen zonder sharding. Dit geldt alleen voor caches van 25 GB en kleiner. Scenario's voor het gebruik van niet-geclusterd clusteringbeleid zijn onder andere:

• Wanneer u migreert vanuit een Redis-omgeving die niet is geshard. Bijvoorbeeld de niet-geharde 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 beleid zijn:

• Dit beleid is alleen van toepassing op Azure Managed Redis-lagen die kleiner zijn dan of gelijk zijn aan 25 GB.
• Het presteert niet zo goed als ander clusteringbeleid, omdat CPU's alleen multithread met Redis Enterprise-software kunnen gebruiken wanneer de cache is opgeknipt.
• 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 die niet is geclusterd, kunt u OSS-clusters gebruiken om de prestaties te verbeteren. Gebruik alleen niet-geclusterde configuraties als uw toepassing geen ondersteuning biedt voor OSS- of Enterprise-topologieën.

Uitschalen of knooppunten toevoegen

De belangrijkste Redis Enterprise-software wordt omhoog geschaald met behulp van grotere VM's of uitschalen door meer knooppunten of VM's toe te voegen. Beide schaalopties voegen meer geheugen, meer vCPU's en meer shards toe. 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 om verwarring, complexiteit en suboptimale configuraties te voorkomen. In plaats daarvan is elke SKU ontworpen met een knooppuntconfiguratie waarmee vCPU's en geheugen worden gemaximaliseerd. Sommige SKU's van Azure Managed Redis gebruiken twee knooppunten, terwijl andere meer gebruiken.

Multisleutelopdrachten

Omdat Azure Managed Redis-exemplaren een geclusterde configuratie gebruiken, ziet CROSSSLOT u mogelijk uitzonderingen voor opdrachten die op meerdere sleutels werken. Het gedrag varieert afhankelijk van het gebruikte clusterbeleid. Als u het OSS-clusteringbeleid gebruikt, moeten alle sleutels in opdrachten met meerdere sleutels worden toegewezen aan dezelfde hash-site.

U kunt ook CROSSSLOT fouten zien bij het Enterprise-clusterbeleid. Alleen de volgende opdrachten met meerdere sleutels zijn toegestaan voor sites met Enterprise-clustering: DEL, MSET, MGET, EXISTS, , UNLINKen TOUCH.

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

Sharding-configuratie

Elke SKU van Azure Managed Redis voert een specifiek aantal Redis-serverprocessen, ook wel shards genoemd, parallel uit. De relatie tussen doorvoerprestaties, het aantal shards en het aantal beschikbare vCPU's voor elk exemplaar is complex. U kunt het aantal shards niet handmatig wijzigen.

Voor een gegeven geheugengrootte heeft de versie Geoptimaliseerd voor Geheugen het laagste aantal vCPU's en shards, terwijl de versie Geoptimaliseerd voor Compute het hoogste aantal heeft.

Als u het aantal shards verhoogt, worden de prestaties over het algemeen verhoogd, omdat Redis-bewerkingen parallel kunnen worden uitgevoerd. Maar als er geen vCPU's beschikbaar zijn om opdrachten uit te voeren, kan de prestatie verminderen.

Shards worden toegewezen om het gebruik van elke vCPU te optimaliseren. Tegelijkertijd wordt vCPU-tijd gereserveerd voor het Redis-serverproces, de beheeragent en de systeemtaken van het besturingssysteem die eveneens van invloed zijn op de prestaties. De clienttoepassingen die u maakt, communiceren met Azure Managed Redis alsof het één logische database is. De service verwerkt routering tussen de vCPU's en shards.

Als u het aantal shards in een SKU wilt verhogen, gebruikt u een grotere laag in die SKU. U kunt ook de SKU's aanpassen aan uw prestatiebehoeften.

In de volgende tabel ziet u de verhouding tussen vCPU's en primaire shards bij een bepaalde laaggrootte. De gegevens in de kolommen geven geen garantie dat dit het aantal vCPU's of het aantal shards is. De tabellen zijn alleen ter illustratie.

Voor geheugen geoptimaliseerde, evenwichtige prestaties en rekenkracht geoptimaliseerde versies

In deze tabel ziet u een algemeen voorbeeld van de relatie tussen grootte en vCPU's/primaire shards.

¹ De verhouding van vCPU's tot primaire shards op een bepaalde laaggrootte vertegenwoordigt geen garantie voor de SKU of laag.

Flash geoptimaliseerde versie

In deze tabel ziet u een algemeen voorbeeld van de relatie tussen grootte en vCPU's/primaire shards.

¹ Deze niveaus zijn beschikbaar als openbare preview.

² De verhouding van vCPU's ten opzichte van primaire shards op een bepaalde niveaugrootte vormt geen garantie voor de SKU of niveau.

Uitvoeren zonder modus voor hoge beschikbaarheid ingeschakeld

U kunt iets uitvoeren zonder dat de hoge beschikbaarheidsmodus is ingeschakeld. Deze configuratie betekent dat uw Redis-exemplaar geen replicatie heeft ingeschakeld en geen toegang heeft tot de SLA voor beschikbaarheid. Voer de niet-HA-modus niet uit buiten ontwikkelings- en testscenario's. U kunt hoge beschikbaarheid niet uitschakelen in een exemplaar dat u al hebt gemaakt. U kunt hoge beschikbaarheid inschakelen in een exemplaar dat deze niet heeft. Omdat een exemplaar zonder hoge beschikbaarheid minder VM's en knooppunten gebruikt, worden vCPU's niet zo efficiënt gebruikt, waardoor 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 Azure Managed 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

Werkbelastingen die goed presteren op de Flash Geoptimaliseerde laag hebben vaak de volgende kenmerken:

• Lees zwaar, met een hoge verhouding van leesopdrachten tot schrijfopdrachten.
• Access is gericht op een subset sleutels die u veel vaker 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