Een Azure Managed Redis-exemplaar schalen

Azure Managed Redis heeft verschillende SKU's en lagen die flexibiliteit bieden bij de keuze van de cachegrootte en prestaties. U kunt schalen naar een grotere geheugengrootte of overschakelen naar een laag met meer rekenprestaties. U kunt ook omlaag schalen naar een kleinere of meer geschikte laag. In dit artikel leest u hoe u uw cache kunt schalen met behulp van Azure Portal, plus hulpprogramma's zoals Azure PowerShell en Azure CLI.

Typen schalen

Azure Managed Redis biedt ondersteuning voor schalen in twee dimensies:

• Geheugen Als het geheugen groter wordt, wordt ook het Redis-exemplaar groter, zodat u meer data kunt opslaan. Wanneer u het geheugen vermindert, moet u ervoor zorgen dat uw huidige geheugengebruik kleiner is dan de nieuwe geheugengrootte die u wilt gebruiken.

• vCPU's Azure Managed Redis biedt drie lagen (geoptimaliseerd voor geheugen, evenwichtig en geoptimaliseerd voor rekenkracht) met een toenemend aantal vCPU's voor elk geheugenniveau. Schalen naar een laag met meer vCPU's verhoogt de prestaties van uw exemplaar zonder dat u het geheugen hoeft te vergroten. In tegenstelling tot de Basic-, Standard- en Premium-lagen van Azure Cache voor Redis die slechts één vCPU gebruiken, maakt Azure Managed Redis gebruik van de Redis Enterprise-stack. De Redis Enterprise-stack kan meerdere vCPU's gebruiken, wat betekent dat het aantal vCPU's dat door uw Redis-exemplaar wordt gebruikt, rechtstreeks correleert met de doorvoer- en latentieprestaties.

Prestatielagen

Er zijn vier lagen van Azure Managed Redis beschikbaar, elk met verschillende prestatiekenmerken en prijsniveaus.

Drie lagen zijn voor in-memory gegevens:

• Geoptimaliseerd voor geheugen : ideaal voor geheugenintensieve gebruiksvoorbeelden waarvoor een hoge geheugen-naar-vCPU-verhouding (8:1) is vereist, maar waarvoor de hoogste doorvoerprestaties niet nodig zijn. Het biedt een lager prijspunt voor scenario's waarbij minder verwerkingskracht of doorvoer nodig is, waardoor het een uitstekende keuze is voor ontwikkel- en testomgevingen.
• Balanced (Memory + Compute): biedt een evenwichtige verhouding tussen geheugen en vCPU (4:1), waardoor deze ideaal is voor standaardworkloads. Het biedt een gezonde balans tussen geheugen en rekenresources.
• Geoptimaliseerd voor rekenkracht : ontworpen voor prestatiesintensieve workloads waarvoor maximale doorvoer is vereist, met een lage verhouding tussen geheugen en vCPU (2:1). Het is ideaal voor toepassingen die de hoogste prestaties eisen.

In één laag worden gegevens zowel in het geheugen als op de schijf opgeslagen:

• Flash Geoptimaliseerd (preview) - Hiermee kunnen Redis-clusters automatisch minder vaak gebruikte gegevens van geheugen (RAM) naar NVMe-opslag verplaatsen. Dit vermindert de prestaties, maar maakt rendabele schaling van caches met grote gegevenssets mogelijk.

Lagen en SKU's in één oogopslag

Prestaties (Latentie- en doorvoerprestaties)

Zie Prestatietests met Azure Managed Redis voor meer informatie over het meten van de prestaties van elke SKU en laag

Wanneer schalen

U kunt de bewakingsfuncties van Azure Managed Redis gebruiken om de status en prestaties van uw cache te bewaken. Gebruik deze informatie om te bepalen wanneer de cache moet worden geschaald.

U kunt de volgende metrische gegevens controleren om te bepalen of u moet schalen.

• CPU
  • Hoog CPU-gebruik betekent dat de Redis-server niet in staat is om te voldoen aan aanvragen van alle clients. Door te schalen naar meer vCPU's kunt u aanvragen verdelen over meerdere Redis-processen. Met schalen kunt u ook TLS-versleuteling/ontsleuteling en verbinding/verbinding verbreken, waardoor cache-exemplaren sneller worden gebruikt met behulp van TLS.
• Geheugengebruik
  • Hoog geheugengebruik geeft aan dat uw datagrootte te groot is voor de huidige cachegrootte. Overweeg om te schalen naar een cachegrootte met een groter geheugen. Wanneer u het geheugen vermindert, moet u ervoor zorgen dat het geheugengebruik van uw huidige cache lager is dan de nieuwe geheugengrootte die u wilt gebruiken. U kunt een grote gegevensset niet in een kleinere cache plaatsen.
• clientverbindingen
  • Elke cachegrootte heeft een limiet voor het aantal clientverbindingen dat kan worden ondersteund. Als uw clientverbindingen dicht bij de limiet voor de cachegrootte liggen, kunt u overwegen om te schalen naar een grotere geheugengrootte of een hogere prestatielaag.
  • Zie Prestatietests met Azure Managed Redis voor meer informatie over verbindingslimieten per cachegrootte.
• Netwerkbandbreedte
  • Als de Redis-server de beschikbare bandbreedte overschrijdt, kunnen er een time-out optreedt voor clients omdat de server geen gegevens naar de client kan pushen. Bekijk metrische waarden "Gelezen uit cache" en "Geschreven naar cache" gebruiken om te zien hoeveel bandbreedte er op de server wordt gebruikt. Als uw Redis-server de beschikbare netwerkbandbreedte overschrijdt, kunt u overwegen om te schalen naar een hogere prestatielaag of een grotere cachegrootte.
  • De keuze van het clusterbeleid is van invloed op de beschikbare netwerkbandbreedte. Over het algemeen heeft het OSS-clusterbeleid een hogere netwerkbandbreedte dan het enterprise-clusterbeleid. Zie Clusterbeleid voor meer informatie
  • Zie Prestatietests met Azure Managed Redis voor meer informatie over de beschikbare netwerkbandbreedte per cachegrootte.

Zie De juiste laag kiezen voor meer informatie over het bepalen van de cacheprijscategorie die u wilt gebruiken.

Zie de aanbevolen procedures voor het schalen voor meer informatie over het optimaliseren van het schaalproces

Beperkingen van het schalen van Azure Managed Redis

• U kunt niet schalen vanuit de lagen Geoptimaliseerd voor geheugen, Gebalanceerd of Met geoptimaliseerde rekenkracht naar de laag Flash geoptimaliseerd of omgekeerd.
• Wanneer u het geheugen voor uw Redis-exemplaar vermindert, moet het huidige geheugengebruik van uw Redis-exemplaar kleiner zijn dan de beoogde nieuwe geheugengrootte. Zie Wat gebeurt er met mijn gegevens als ik schaal naar kleinere geheugengrootte? voor meer informatie.
• Wanneer u het geheugen of de vCPU voor uw Redis-exemplaar verkleint, kunt u alleen schalen naar SKU's die een vCPU- en shardconfiguratie hebben die compatibel is met de configuratie op uw huidige exemplaar.
• In sommige gevallen kan het onderliggende IP-adres van het Redis-exemplaar worden gewijzigd. De DNS-record voor het exemplaar wordt gewijzigd en is transparant voor de meeste toepassingen. Als u echter een IP-adres gebruikt om de verbinding met uw Redis-exemplaar te configureren of om NSG's of firewalls te configureren die verkeer naar het Redis-exemplaar toestaan, kan het zijn dat uw toepassing enige tijd problemen ondervindt bij het maken van verbinding nadat de DNS-recordupdates zijn bijgewerkt.
• Het schalen van een exemplaar in een geo-replicatiegroep heeft nog enkele beperkingen. Zie Zijn er schaalbeperkingen met geo-replicatie? voor meer informatie.
• Wanneer u omlaag schaalt, kunt u alleen naar bepaalde lagen schalen. Zie Waarom kan ik alleen omlaag schalen naar een subset van kleinere SKU's? voor meer informatie.

Schalen

In deze sectie wordt beschreven hoe u een Azure Managed Redis Cache schaalt.

Schalen met behulp van Azure Portal

1. Als u de cache wilt schalen, bladert u naar de cache in Azure Portal en selecteert u Schalen in het menu Resource.

2. Als u de schaal van uw vCPU's wilt aanpassen, kiest u een ander cachetype en kiest u Opslaan.

   Belangrijk

   Als u een SKU selecteert waarnaar niet kan worden geschaald, is de optie Opslaan uitgeschakeld. Raadpleeg de sectie Beperkingen van het schalen van Azure Managed Redis voor meer informatie over welke schaalopties zijn toegestaan.

3. Terwijl de cache wordt geschaald naar de nieuwe laag, wordt er een melding over het schalen van Redis Cache weergegeven.

4. Wanneer het schalen is voltooid, verandert de status van Schalen naar Actief bij het weergeven van de sectie Overzicht van het menu Resource.

Schalen met PowerShell

U kunt uw Azure Managed Redis-exemplaren schalen met PowerShell met behulp van de cmdlet Update-AzRedisEnterpriseCache . U kunt de Sku eigenschap wijzigen om de gewenste laag en SKU te selecteren. In het volgende voorbeeld ziet u hoe u een cache met de naam myCache schaalt naar een X20-exemplaar (24 GB) dat is geoptimaliseerd voor compute.

   Update-AzRedisEnterpriseCache -ResourceGroupName <your-group> -Name <your-cache-name> -Sku <sku-name>

Schalen met Azure CLI

Als u uw Azure Managed Redis-exemplaren wilt schalen met behulp van Azure CLI, roept u de opdracht az redisenterprise update aan. U kunt de sku eigenschap wijzigen om de gewenste laag en SKU te selecteren. In het volgende voorbeeld ziet u hoe u een cache met de naam myCache schaalt naar een X20-exemplaar (24 GB) dat is geoptimaliseerd voor compute.

az redisenterprise update --cluster-name <your-cache-name> --resource-group <your-resource-group> --sku <name-of-sku>

Veelgestelde vragen over schalen

De volgende lijst bevat antwoorden op veelgestelde vragen over het schalen van Azure Managed Redis.

• Kan ik binnen of tussen lagen schalen?
• Wat gebeurt er met mijn gegevens als ik schaal naar een kleinere geheugengrootte?
• Moet ik na het schalen mijn cachenaam of toegangssleutels wijzigen?
• Hoe werkt schalen?
• Verlies ik data uit mijn cache tijdens het schalen?
• Is mijn cache beschikbaar tijdens het schalen?
• Zijn er schaalbeperkingen met geo-replicatie?
• Hoe lang duurt schalen?
• Hoe kan ik zien wanneer schalen is voltooid?
• Maakt Azure Managed Redis gebruik van clustering?Hoeveel shards gebruikt elke door Azure beheerde Redis-SKU?
• Hoe worden sleutels gedistribueerd in een cluster?
• Wat is de grootste cachegrootte die ik kan maken?
• Waarom kan ik alleen omlaag schalen naar een subset van kleinere SKU's?
• Kan het clusterbeleid worden gewijzigd nadat u OSS of Enterprise-cluster hebt geselecteerd?

Kan ik binnen of tussen lagen schalen?

U kunt altijd schalen naar een hogere prestatielaag met dezelfde geheugengrootte of een grotere geheugengrootte binnen dezelfde prestatielaag. Voor het schalen naar een lagere prestatielaag of een kleinere geheugengrootte raden we u aan de REST API 'listskusforsforscaling' uit te voeren om de lijst met SKU's op te halen waarnaar u kunt schalen.

az redisenterprise list-skus-for-scaling --cluster-name <your-redis-instance> --resource-group <your-resource-group>

Wat gebeurt er met mijn gegevens als ik schaal naar een kleinere geheugengrootte?

U kunt alleen schalen naar een kleinere geheugengrootte als het huidige geheugengebruik kleiner is dan de beoogde kleinere geheugengrootte. Als het huidige geheugengebruik hoger is dan de beoogde kleinere grootte, mislukt de schaalaanvraag. U kunt het huidige geheugengebruik verminderen door ongewenste sleutelwaardeparen te verwijderen of door de flush-bewerking uit te voeren.

az redisenterprise database flush --cluster-name <your-redis-instance> --resource-group <your-resource-group>

Moet ik na het schalen mijn cachenaam of toegangssleutels wijzigen?

Nee, uw cachenaam en toegangssleutels worden niet gewijzigd tijdens een schaalbewerking.

Hoe werkt schalen?

• Wanneer u een Redis-exemplaar schaalt, wordt een van de knooppunten in het Redis-cluster afgesloten en opnieuw ingericht voor de nieuwe grootte. Vervolgens worden gegevens overgedragen, en het andere knooppunt voert daarna een vergelijkbare failover uit, voordat de herinrichting plaatsvindt. Dit is vergelijkbaar met het proces dat optreedt tijdens het patchen of een fout van een van de cacheknooppunten.
• Wanneer u schaalt naar een exemplaar met meer vCPU's, worden nieuwe shards ingericht en toegevoegd aan het Redis-servercluster. Gegevens worden vervolgens opnieuw gehard voor alle shards.

Zie Sharding-configuratie voor meer informatie over hoe Azure Managed Redis sharding verwerkt.

Verlies ik data uit mijn cache tijdens het schalen?

• Als de modus voor hoge beschikbaarheid is ingeschakeld, moeten alle gegevens behouden blijven tijdens schaalbewerkingen.
• Als u schaalt naar een kleiner geheugenniveau, moet u ervoor zorgen dat het huidige geheugengebruik kleiner is dan de beoogde nieuwe geheugengrootte. Als het huidige geheugengebruik meer is dan de beoogde SKU-geheugengrootte, kunt u uw gegevens leegmaken met behulp van de bewerking Leegmaken of handmatig sleutelwaarden kiezen om te verwijderen.
• Als de modus voor hoge beschikbaarheid is uitgeschakeld, gaan alle gegevens verloren en is de cache niet beschikbaar tijdens de schaalbewerking.

Is mijn cache beschikbaar tijdens het schalen?

• Azure Managed Redis-exemplaren waarvoor de modus voor hoge beschikbaarheid is ingeschakeld, blijven beschikbaar tijdens de schaalbewerking. Verbindingslips kunnen echter optreden tijdens het schalen van deze caches. Deze verbindingslips zijn doorgaans kort en Redis-clients kunnen hun verbinding over het algemeen onmiddellijk opnieuw tot stand brengen.
• Als de modus voor hoge beschikbaarheid is uitgeschakeld, is het Azure Managed Redis-exemplaar offline tijdens schaalbewerkingen.

Zijn er schaalbeperkingen met geo-replicatie?

Het schalen van geo-gerepliceerde caches bevindt zich in openbare preview. Als actieve geo-replicatie is geconfigureerd, kunt u cachegrootten niet combineren en vergelijken in een geo-replicatiegroep. Als gevolg hiervan vereist het schalen van de caches in een geo-replicatiegroep nog enkele stappen. Zie Instanties schalen in een geo-replicatiegroep voor instructies.

Omlaag schalen naar een kleinere geheugengrootte of een kleiner aantal shards wordt niet ondersteund voor geo-gerepliceerde caches. Zie voor meer informatie hoeveel shards elke Azure Managed Redis-SKU gebruikt om shards in uw cluster te achterhalen.

Hoe lang duurt schalen?

Schaaltijd is afhankelijk van een paar factoren. Hier volgen enkele factoren die van invloed kunnen zijn op hoe lang schalen duurt.

• Hoeveelheid gegevens: het duurt langer om grotere hoeveelheden gegevens te repliceren
• Hoge schrijfaanvragen: een hoger aantal schrijfbewerkingen betekent dat er meer gegevens worden gerepliceerd tussen knooppunten of shards
• Hoog CPU-gebruik: hoger CPU-gebruik betekent dat de Redis-server bezet is en dat er beperkte CPU-cycli beschikbaar zijn om de herdistributie van gegevens te voltooien

Over het algemeen duurt het ongeveer 10 minuten wanneer u een exemplaar schaalt zonder gegevens.

Hoe kan ik zien wanneer schalen is voltooid?

In Azure Portal ziet u de schaalbewerking die wordt uitgevoerd. Wanneer het schalen is voltooid, wordt de status van de cache gewijzigd in Uitvoeren bij het weergeven van overzicht in het menu Resource.

Maakt Azure Managed Redis gebruik van clustering?

In tegenstelling tot Azure Cache voor Redis maakt Azure Managed Redis gebruik van clustering in alle lagen en SKU's. Clustering maakt aanzienlijke prestatieoptimalisaties mogelijk. Elke SKU van Azure Managed Redis is geconfigureerd voor een geoptimaliseerd aantal shards voor het aantal beschikbare vCPU's. Het aantal shards kan niet door de gebruiker worden geconfigureerd.

Hoeveel shards gebruikt elke door Azure Managed Redis-SKU?

Omdat Azure Managed Redis wordt uitgevoerd op Redis Enterprise-software, kunnen shards worden gebruikt in een compactere configuratie dan in community Redis. Zie Sharding-configuratie voor meer informatie over het specifieke aantal shards dat in elke SKU wordt gebruikt.

Hoe worden sleutels gedistribueerd in een cluster?

Volgens de Redis-documentatie over Het distributiemodel sleutels: de sleutelruimte wordt gesplitst in 16.384 sleuven. Elke sleutel wordt gehasht en toegewezen aan een van deze sites, die worden verdeeld over de knooppunten van het cluster. U kunt configureren welk deel van de sleutel is gehasht om ervoor te zorgen dat meerdere sleutels zich in dezelfde shard bevinden met behulp van hashtags.

• Sleutels met een hash-tag: als een deel van de sleutel is ingesloten { en }alleen dat deel van de sleutel wordt gehasht voor het bepalen van de hash-site van een sleutel. De volgende drie sleutels bevinden zich bijvoorbeeld in dezelfde shard: {key}1, {key}2en {key}3 omdat alleen het key deel van de naam is gehasht. Zie Hash-tags voor sleutels voor een volledige lijst met hashtagspecificaties voor sleutels.
• Sleutels zonder hash-tag: de volledige sleutelnaam wordt gebruikt voor hashing en dit leidt tot een statistisch gelijkmatige verdeling over de shards van de cache.

Voor de beste prestaties en doorvoer raden we u aan de sleutels gelijkmatig te distribueren. Als u sleutels met een hash-tag gebruikt, is het de verantwoordelijkheid van de toepassing om ervoor te zorgen dat de sleutels gelijkmatig worden verdeeld.

Zie voor meer informatie het distributiemodel sleutels, Redis Cluster gegevens sharding en sleutels hash-tags.

Wat is de grootste cachegrootte die ik kan maken?

De grootste cachegrootte die u kunt hebben, is 4,5 TB, genaamd Flash Optimized A4500 instance. Prijzen voor Azure Cache voor Redis.

Waarom kan ik alleen omlaag schalen naar een subset van kleinere SKU's?

Als u de compatibiliteit met het aantal shards en vCPU's wilt behouden, mag u alleen omlaag schalen naar bepaalde SKU's. U kunt zien naar welke SKU's uw Redis-exemplaar omlaag kan worden geschaald door de beschikbare opties in de sectie Schaal van Azure Portal te controleren. U kunt ook de volgende CLI-opdracht uitvoeren.

U kunt zien naar welke SKU's uw Redis-exemplaar omlaag kan worden geschaald door de beschikbare opties in de sectie Schaal van Azure Portal te controleren.

az redisenterprise list-skus-for-scaling --cluster-name <your-redis-instance> --resource-group <your-resource-group>

Kan het clusterbeleid worden gewijzigd nadat u OSS of Enterprise-cluster hebt geselecteerd?

Zodra u een clusterbeleid hebt ingesteld op OSSCluster of EnterpriseCluster wanneer u een cache maakt, kunt u dit niet wijzigen. Als u wilt overschakelen naar een ander clusteringsbeleid, moet u de Redis-cache verwijderen en opnieuw maken met de gewenste configuratie. Alleen caches met het beleid Niet-cluster kunnen na de implementatie worden bijgewerkt naar een geclusterde configuratie.

Verwante inhoud

• Best practices voor schalen