Delen via

Een exemplaar van Azure Managed Redis schalen (preview)

  • Artikel

Azure Managed Redis (preview) heeft verschillende SKU's en lagen die flexibiliteit bieden bij de keuze van de cachegrootte en prestaties. U kunt omhoog schalen naar een grotere geheugengrootte of overschakelen naar een laag met meer rekenprestaties. 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.

Notitie

Omdat elke laag van Azure Managed Redis vrijwel dezelfde functies heeft, wordt schalen meestal alleen gebruikt om de geheugen- en prestatiekenmerken te wijzigen.

Belangrijk

Op dit moment wordt alleen omhoog schalen naar grotere geheugengrootten of een hogere prestatielaag ondersteund. Het omlaag schalen van geheugengrootten of naar een minder presterende laag wordt nog niet ondersteund.

Typen schaling

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.

  • 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 communityversie van Redis, die slechts één vCPU kan gebruiken, maakt Azure Managed Redis gebruik van de Redis Enterprise-stack, die meerdere vCPU's kan gebruiken. Dit 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 gebruiksscenario's waarvoor een hoge geheugen-naar-vCPU-verhouding (8:1) is vereist, maar die de hoogste doorvoerprestaties niet nodig hebben. 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.
  • Evenwichtig (geheugen en rekenkracht). 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.
  • Met geoptimaliseerde rekenkracht. Ontworpen voor prestatie-intensieve workloads waarvoor maximale doorvoer is vereist, met een lage geheugen-naar-vCPU-verhouding (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. Hiermee kunnen Redis-clusters automatisch minder vaak gebruikte gegevens van het geheugen (RAM) verplaatsen naar NVMe-opslag. Dit vermindert de prestaties, maar maakt rendabele schaling van caches met grote gegevenssets mogelijk.

Lagen en SKU's in één oogopslag

Tabel met de verschillende geheugen- en vCPU-configuraties voor elke SKU en laag van Azure Managed Redis.

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. Omhoog schalen naar meer vCPU's helpt bij het distribueren van aanvragen 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.
  • Memory Usage (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.
  • 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.

Notitie

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

Vereisten/beperkingen voor 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.
  • U kunt niet omlaag schalen van naar een SKU met minder vCPU's. (Tussen lagen of binnen een laag.)
  • U kunt niet omlaag schalen naar een kleinere geheugengrootte, zelfs niet als deze dezelfde of meer vCPU's heeft.
  • 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 cache te configureren of om NSG's of firewalls te configureren die verkeer naar de cache 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.

Schalen

Tip

U kunt zowel de geheugengrootte als de prestatielaag in één bewerking wijzigen.

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.

    Schermopname van Schalen geselecteerd in het menu Resource voor een Enterprise-cache.

  2. Als u omhoog wilt schalen, 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 Vereisten/beperkingen voor het schalen van Azure Managed Redis voor meer informatie over welke schaalopties zijn toegestaan.

    Schermopname van de Enterprise-lagen in het werkvenster.

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

    Schermopname van de melding van het schalen van een Enterprise-cache.

  4. Wanneer het schalen is voltooid, verandert de status van Schalen naar Actief.

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 myGroup -Name myCache -Sku ComputeOptimized_X20

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 "myCache" --resource-group "myGroup" --sku "ComputeOptimized_X20"

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?

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 raadpleegt u de vereisten/beperkingen van het schalen van Azure Managed Redis.

Moet ik na het schalen mijn cachenaam of toegangssleutels wijzigen?

Nee, uw cachenaam en -sleutels zijn ongewijzigd 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 vervolgens voert het andere knooppunt een vergelijkbare failover uit voordat het opnieuw wordt geïmplementeerd. Dit is vergelijkbaar met het proces dat optreedt tijdens het patchen of een fout van een van de cacheknooppunten.
  • Bij het schalen 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 omlaag schaalt naar een kleiner geheugenniveau, kunnen gegevens verloren gaan als de gegevens groter zijn dan de nieuwe kleinere grootte wanneer de cache omlaag wordt geschaald. Als gegevens verloren gaan bij omlaag schalen, worden sleutels verwijderd met behulp van het verwijderingsbeleid allkeys-lru.
  • 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?

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.

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 Actief.

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.

Wat is het verschil tussen het OSS- en Enterprise-clusterbeleid?

OSS-clusterbeleid is hetzelfde als de clusteringbenadering die wordt gebruikt in redis van de communityversie. OSS-clusterbeleid is doorgaans beter presterend. Clusterbeleid voor ondernemingen implementeert clustering zodat het lijkt op een client als een niet-geclusterd Redis-exemplaar. Deze aanpak kan minder goed werken, maar kan compatibiliteitsproblemen met clients voorkomen. Het is momenteel niet mogelijk om te schakelen tussen clusterbeleidsregels op een actief exemplaar. Zie Clusterbeleid voor meer informatie.

Volgende stappen