Dela via

Skala en Azure Managed Redis-instans (förhandsversion)

  • Artikel

Azure Managed Redis (förhandsversion) har olika SKU- och nivåerbjudanden så att du får flexibilitet vid valet av cachestorlek och prestanda. Du kan skala upp till en större minnesstorlek eller byta till en nivå med högre beräkningsprestanda. Den här artikeln visar hur du skalar cachen med hjälp av Azure-portalen, plus verktyg som Azure PowerShell och Azure CLI.

Kommentar

Eftersom varje nivå i Azure Managed Redis har i princip samma funktioner, används skalning vanligtvis endast för att åstadkomma andra minnes- och prestandaegenskaper.

Viktigt!

För närvarande stöds endast skalning upp till större minnesstorlekar eller till en högre prestandanivå. Det är i dagsläget inte möjligt att skala ned till mindre minnesstorlekar eller till en lägre prestandanivå.

Typer av skalning

Azure Managed Redis har stöd för skalning i två dimensioner:

  • Minne En ökning av minnet ökar storleken på Redis-instansen så att du kan lagra mer data.

  • vCPU:er Azure Managed Redis erbjuder tre nivåer (minnesoptimerad, balanserad och beräkningsoptimerad) med fler vCPI:er på varje minnesnivå. Om du skalar till en nivå med fler vCPU:er ökar prestandan hos din instans utan att du behöver öka minnet. Till skillnad från communityversionen av Redis, som bara kan använda en enstaka vCPU, används Redis Enterprise-stacken, som kan använda flera vCPU:er, i Azure Managed Redis. Det innebär att antalet vCPU:er som används av Redis-instansen direkt korrelerar med dataflödes- och latensprestanda.

Prestandanivåer

Azure Managed Redis finns på fyra nivåer med olika prestandaegenskaper och prisnivåer.

Tre nivåer avser minnesinterna data:

  • Minnesoptimerad Perfekt för minnesintensiva användningsfall som kräver ett högt förhållande mellan minne och vCPU (8:1) men som inte behöver den högsta dataflödesprestandan. Denna nivå ger ett lägre pris i tillämpningar som kräver mindre bearbetningskraft eller dataflöde, vilket gör den till ett utmärkt val för utvecklings- och testmiljöer.
  • Balanserad (minne + beräkning). Erbjuder ett balanserat förhållande mellan minne och vCPU (4:1), vilket gör det idealiskt för standardarbetsbelastningar. Den ger en sund balans mellan minnes- och beräkningsresurser.
  • Beräkningsoptimerad Utformad för prestandaintensiva arbetsbelastningar som kräver maximalt dataflöde, med ett lågt förhållande mellan minne och vCPU (2:1). Idealisk för tillämpningar som kräver högsta prestanda.

Data lagras både i minnet och på disk på en och samma nivå:

  • Flash-optimerad. Gör det möjligt för Redis-kluster att automatiskt flytta data som används mindre ofta från minne (RAM) till NVMe-lagring. Detta minskar prestandan men ger kostnadseffektiv skalning av cacheminnen med stora datamängder.

Översikt över nivåer och SKU:er

Tabell som visar olika minnes- och vCPU-konfigurationer för varje SKU och nivå för Azure Managed Redis.

Prestanda (dataflöde och latens)

Prestandamått och mer information om hur du mäter prestanda för varje SKU och nivå finns i Prestandatestning med Azure Managed Redis.

När ska du skala

Du kan använda övervakningsfunktionerna i Azure Managed Redis för att övervaka cachens hälsotillstånd och prestanda. Använd denna information för att avgöra när cacheminnet ska skalas.

Du kan övervaka följande mått för att avgöra om skalning behövs.

  • CPU
    • Hög CPU-användning innebär att Redis-servern inte kan hålla jämna steg med förfrågningar från alla klienter. Genom att skala upp till fler vCPU:er kan du fördela förfrågningar mellan flera Redis-processer. Skalning bidrar också till att fördela TLS-kryptering/dekryptering och anslutning/frånkoppling, vilket påskyndar cacheinstanser med TLS.
  • Minnesanvändning
    • Hög minnesanvändning indikerar att datastorleken är för stor för den aktuella cachestorleken. Överväg att skala till en cachestorlek med större minne.
  • Klientanslutningar
    • Varje cachestorlek har en maxgräns för antalet klientanslutningar som stöds. Om antalet klientanslutningar ligger nära cachestorlekens maxgräns kan du överväga att skala till en större minnesstorlek eller till en högre prestandanivå.
    • Mer information om anslutningsgränser per cachestorlek finns i Prestandatestning med Azure Managed Redis.
  • Nätverksbandbredd.
    • Om Redis-servern överstiger den tillgängliga bandbredden kan klienternas förfrågningar överskrida tidsgränsen, eftersom servern inte kan skicka data till klienten tillräckligt snabbt. Kontrollera måtten Cacheläsning och Cacheskrivning för att se hur mycket bandbredd som används på serversidan. Om Redis-servern överstiger den tillgängliga nätverksbandbredden bör du överväga att skala till en högre prestandanivå eller till en större cachestorlek.
    • Valet av klusterprincip påverkar tillgänglig nätverksbandbredd. I allmänhet gäller att OSS-klusterprincipen har högre nätverksbandbredd än Enterprise-klusterprincipen. Mer information finns i Klusterprincip.
    • Mer information om nätverkstillgänglig bandbredd per cachestorlek finns i Prestandatestning med Azure Managed Redis.

Mer information om hur du avgör vilken cacheprisnivå du bör välja finns i Välja rätt nivå.

Kommentar

Mer information om hur du optimerar skalningsprocessen finns i metodtipsen för skalning.

Krav/begränsningar för skalning av Azure Managed Redis

  • Du kan inte skala från nivåerna Minnesoptimerad, Balanserad och Beräkningsoptimerad till Flash-optimerad eller tvärtom.
  • Du kan inte skala ned från till en SKU med färre vCPU:er. (Mellan nivåer eller inom en nivå.)
  • Du kan inte skala ned till en mindre minnesstorlek, även om den har samma eller flera virtuella processorer.
  • I vissa fall kan Redis-instansens underliggande IP-adress ändras vid skalning. Instansens DNS-post ändras och är transparent för de flesta program. Om du använder en IP-adress för att konfigurera anslutningen till din cache, eller för att konfigurera NSG:er eller brandväggar som tillåter trafik till cachen, kan ditt program dock få problem med att ansluta ett tag efter att DNS-posten har uppdaterats.
  • Skalning av en instans i en geo-replikeringsgrupp omfattas av ytterligare begränsningar. Mer information finns i Finns det skalningsbegränsningar med geo-replikering?.

Hur du skalar

Dricks

Du kan ändra både minnesstorlek och prestandanivå i en och samma åtgärd.

Skala med hjälp av Azure Portal

  1. Om du vill skala cacheminnet bläddrar du till cachen i Azure Portal och väljer Skala på resursmenyn.

    Skärmbild som visar Skala som valts i resursmenyn för en Enterprise-cache.

  2. Om du vill skala upp väljer du en annan cachetyp och väljer sedan Spara.

    Viktigt!

    Om du väljer en SKU som inte kan skalas till inaktiveras alternativet Spara . Mer information om vilka skalningsalternativ som tillåts finns i avsnittet Krav/begränsningar för skalning av Azure Managed Redis.

    Skärmbild som visar Enterprise-nivåerna i arbetsfönstret.

  3. Medan cacheminnet skalas till den nya nivån visas ett meddelande om skalning av Redis Cache .

    Skärmbild som visar meddelande om skalning av en Enterprise-cache.

  4. När skalningen är klar ändras statusen från Skalning till Körning.

Skalning med PowerShell

Du kan skala dina Azure Managed Redis-instanser med PowerShell med hjälp av cmdleten Update-AzRedisEnterpriseCache. Du kan modifiera Sku-egenskapen för att välja den nivå och SKU som du behöver. Följande exempel visar hur du skalar en cache med namnet myCache till en beräkningsoptimerad X20-instans (24 GB).

   Update-AzRedisEnterpriseCache -ResourceGroupName myGroup -Name myCache -Sku ComputeOptimized_X20

Skalning med Azure CLI

För att skala dina Azure Managed Redis-instanser med hjälp av Azure CLI ska du anropa kommandot az redisenterprise update. Du kan modifiera sku-egenskapen för att välja den nivå och SKU som du behöver. Följande exempel visar hur du skalar en cache med namnet myCache till en beräkningsoptimerad X20-instans (24 GB).

az redisenterprise update --cluster-name "myCache" --resource-group "myGroup" --sku "ComputeOptimized_X20"

Vanliga frågor om skalning

Följande lista innehåller svar på vanliga frågor om skalning av Azure Managed Redis.

Kan jag skala inom eller mellan nivåer?

Du kan alltid skala till en högre prestandanivå med samma minnesstorlek eller till en större minnesstorlek på samma prestandanivå. Information om hur du skalar till en lägre prestandanivå eller till en mindre minnesstorlek finns i Krav/begränsningar för skalning av Azure Managed Redis.

Måste jag ändra cachenamnet eller åtkomstnycklarna efter skalning?

Nej, cachenamnet och nycklarna ändras inte under en skalningsåtgärd.

Hur fungerar skalning?

  • När du skalar en Redis-instans stängs en av noderna i Redis-klustret av och ometableras till den nya storleken. Sedan överförs data, och den andra noden gör en liknande redundansväxling innan den återskapas. Detta liknar den process som inträffar vid korrigering eller ett fel på en av cachenoderna.
  • När du skalar till en instans med fler vCPU:er etableras nya shards och läggs till i Redis-serverklustret. Data partitioneras sedan på nytt mellan alla shards.

Mer information om hur Azure Managed Redis hanterar horisontell partitionering finns i Partitioneringskonfiguration.

Försvinner data från cacheminnet under skalning?

  • Om läget för hög tillgänglighet är aktiverat bör alla data bevaras under skalningsåtgärderna.
  • Om du skalar ned till en lägre minnesnivå kan data gå förlorade om datastorleken överstiger den nya mindre storleken när cachen skalas ned. Om data går förlorade vid nedskalning avlägsnas nycklar enligt avlägsningsprincipen allkeys-lru.
  • Om läget för hög tillgänglighet är inaktiverat går alla data förlorade och cacheminnet är inte tillgängligt under skalningsåtgärden.

Är cachen tillgänglig under skalning?

  • Azure Managed Redis-instanser med läget för hög tillgänglighet är fortfarande tillgängliga under skalningsåtgärden. Det kan dock förekomma anslutningsstörningar när dessa cacheminnen skalas. Sådana störningar är vanligtvis korta och Redis-klienter kan oftast återupprätta anslutningen omedelbart.
  • Om läget för hög tillgänglighet är inaktiverat är Azure Managed Redis-instansen offline under skalningsåtgärderna.

Finns det skalningsbegränsningar med geo-replikering?

Med aktiv geo-replikering går det inte att kombinera olika cachestorlekar i en och samma geo-replikeringsgrupp. Därför kräver skalning av cacheminnena i en geo-replikeringsgrupp ytterligare några steg. Mer information finns i Skala instanser i en geo-replikeringsgrupp.

Hur lång tid tar skalningen?

Skalningstiden beror på ett antal olika faktorer. Detta är några faktorer som kan påverka hur lång tid skalningen tar.

  • Mängd data: Det tar längre tid att replikera större mängder data
  • Stort antal skrivförfrågningar: Fler skrivningar innebär att fler data replikeras mellan noder eller shards
  • Hög CPU-användning: Högre CPU-användning innebär att Redis-servern är upptagen och att begränsade CPU-cykler är tillgängliga för att slutföra omfördelningen av data

Skalning av en instans utan data tar vanligtvis cirka 10 minuter.

Hur vet jag när skalningen är klar?

Du kan se den pågående skalningsåtgärden i Azure-portalen. När skalningen är klar ändras cacheminnets status till Körs.

Använder Azure Managed Redis klustring?

Till skillnad från Azure Cache for Redis använder Azure Managed Redis klustring på alla nivåer och SKU:er. Klustring möjliggör betydande prestandaoptimeringar. Varje Azure Managed Redis-SKU är konfigurerad för ett optimerat antal shards per antalet tillgängliga vCPU:er. Antalet shards kan inte konfigureras av användaren.

Hur många shards använder varje Azure Managed Redis-SKU?

Eftersom Azure Managed Redis körs på Redis Enterprise-programvara kan shards användas i en tätare konfiguration än i communityversionen av Redis. Mer information om det specifika antalet shards som används i varje SKU finns i Partitioneringskonfiguration.

Hur fördelas nycklar i ett kluster?

Enligt Redis-dokumentationen om nyckeldistributionsmodellen: Nyckelutrymmet är uppdelat på 16 384 platser. Varje nyckel hashas och tilldelas någon av dessa platser, som fördelas mellan noderna i klustret. Du kan konfigurera vilken del av nyckeln som hashas för att säkerställa att flera nycklar finns i samma shard genom att använda hash-taggar.

  • Nycklar med en hash-tagg – Om någon del av nyckeln omges av { och } hashas endast denna del av nyckeln för att fastställa nyckelns hash-plats. Exempelvis finns följande tre nycklar i samma shard: {key}1, {key}2, och {key}3, eftersom endast key-delen av namnet hashas. En fullständig lista med specifikationer för hash-taggar för nycklar finns i Hash-taggar för nycklar.
  • Nycklar utan hash-tagg – Hela nyckelnamnet används för hashning, vilket resulterar i en statistiskt jämn fördelning mellan cachens shards.

För bästa prestanda och dataflöde rekommenderar vi att nycklarna fördelas jämnt. Om du använder nycklar med en hash-tagg ansvarar programmet för att se till att nycklarna fördelas jämnt.

Mer information finns i Nyckeldistributionsmodell, Partitionering av Redis-klusterdata och Hash-taggar för nycklar.

Vilken är den största cachestorleken jag kan skapa?

Den största tillåtna cachestorleken är 4,5 TB, vilket kallas Flash Optimized A4500-instans. Prissättning för Azure Cache for Redis.

Vad är skillnaden mellan OSS- och Enterprise-klusterprinciperna?

OSS-klusterprincipen är samma som den klustringsmetod som används i communityversionen av Redis. Vanligtvis ger OSS-klusterprincipen högre prestanda. Med Enterprise-klusterprincipen implementeras klustring så att den visas som en icke-klustrad Redis-instans för en klient. Denna metod kan ge lägre prestanda, men kan förhindra problem med klientkompatibilitet. Det är för närvarande inte möjligt att växla mellan klusterprinciper på en instans som körs. Mer information finns i Klusterprincip.

Nästa steg