Dela via


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

Azure Managed Redis har olika SKU- och nivåerbjudanden som ger flexibilitet i valet av cachestorlek och prestanda. Du kan skala (förhandsversion) till en större minnesstorlek eller ändra till en nivå med mer beräkningsprestanda. Du kan också skala ned till en mindre eller mer lämplig nivå. Den här artikeln visar hur du skalar cachen med hjälp av Azure-portalen, plus verktyg som Azure PowerShell och Azure CLI.

Anmärkning

Eftersom varje nivå i Azure Managed Redis har nästan samma funktioner används skalning vanligtvis bara för att ändra minnes- och prestandaegenskaper. Skalning finns för närvarande i offentlig förhandsversion.

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. När du minskar minnet måste du se till att den aktuella minnesanvändningen är mindre än den nya minnesstorlek som du vill använda.

  • 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 nivåerna Basic, Standard och Premium i Azure Cache för Redis, som bara använder en enda vCPU, använder Azure Managed Redis Redis Enterprise-stacken. Redis Enterprise-stacken kan använda flera vCPU:er, vilket innebär att antalet vCPU:er som används av Redis-instansen direkt korrelerar med prestanda för dataflöde och svarstid.

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.
  • Balanserat (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 Optimized (förhandsversion) – Gör att Redis-kluster automatiskt kan 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.

Viktigt!

Alla minnesinterna nivåer som använder över 120 GB lagringsutrymme finns i offentlig förhandsversion, inklusive Minnesoptimerad M150 och senare. Balanserad B150 och högre; och Compute Optimized X150 och senare. Alla dessa nivåer och högre finns i offentlig förhandsversion.

Alla Flash-optimerade nivåer finns i offentlig förhandsversion.

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

  • PROCESSOR
    • 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 till fler vCPU:er kan du distribuera begäranden 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. När du minskar minnet måste du se till att minnesanvändningen för den aktuella cachen är lägre än den nya minnesstorlek som du vill använda. Du kan inte placera en stor datauppsättning i en mindre cachestorlek.
  • 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å.

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

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.
  • När du minskar minnet för redis-instansen bör den aktuella minnesanvändningen för Redis-instansen vara mindre än den avsedda nya minnesstorleken. Mer information finns i Vad händer med mina data om jag skalar till mindre minnesstorlek?.
  • När du minskar minnet eller vCPU:n för redis-instansen kan du bara skala till SKU:er som har en vCPU- och shard-konfiguration som är kompatibel med konfigurationen på den aktuella instansen.
  • I vissa fall kan Redis-instansens underliggande IP-adress ändras vid skalning. Instansens DNS-post ändras och är transparent för de flesta program. Men om du använder en IP-adress för att konfigurera anslutningen till din Redis-instans, eller för att konfigurera NSG:er eller brandväggar som tillåter trafik till Redis-instansen, kan ditt program ha problem med att ansluta någon gång efter att DNS-postuppdateringarna 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?.
  • När du skalar ned kan du bara skala till vissa nivåer. Mer information finns i Varför kan jag bara skala ned till en delmängd av mindre SKU:er?.

Hur man skalar (förhandsgranskning)

I det här avsnittet beskriver vi hur du skalar en Azure Managed Redis Cache.

Skala med hjälp av Azure Portal

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

  2. Om du vill skala dina vCPU:er 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 Begränsningar för skalning av Azure Managed Redis .

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

  4. När skalningen är klar ändras statusen från Skalning till Körs när du visar avsnittet Översikt på resursmenyn.

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 <your-group> -Name <your-cache-name> -Sku <sku-name>

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 <your-cache-name> --resource-group <your-resource-group> --sku <name-of-sku>

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å. För att skala till en lägre prestandanivå eller mindre minnesstorlek rekommenderar vi att du kör REST API:et "listskusforscaling" för att hämta listan över SKU:er som du kan skala till.

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

Vad händer med mina data om jag skalar till mindre minnesstorlek?

Du kan bara skala till en mindre minnesstorlek om den aktuella minnesanvändningen är mindre än den avsedda mindre minnesstorleken. Om den aktuella minnesanvändningen är högre än den avsedda mindre storleken misslyckas din skalningsbegäran. Du kan minska den aktuella minnesanvändningen genom att ta bort oönskade nyckelvärdepar eller genom att köra tömningsåtgärden.

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

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

Nej, cachenamnet och åtkomstnycklarna ä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 utför en liknande redundansväxling därefter innan den etableras igen. 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 till en mindre minnesnivå måste du se till att den aktuella minnesanvändningen är mindre än den avsedda nya minnesstorleken. Om den aktuella minnesanvändningen är större än den avsedda SKU-minnesstorleken kan du rensa dina data med hjälp av åtgärden Rensa eller manuellt välja nyckelvärden att ta bort.
  • 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 min cache 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 statusen för cacheminnet till Körs när du visar Översikt på resursmenyn.

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 i 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 över specifikationer för hashtaggar för nycklar finns i Nycklars hashtaggar.
  • 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, Redis-klusterdatasharding 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.

Varför kan jag bara skala ned till en delmängd av mindre SKU:er?

För att upprätthålla kompatibilitet med antalet shards och vCPU får du bara skala ned till vissa SKU:er. Om du vill ta reda på vilka SKU:er din Redis-instans kan skalas ned till kan du granska listan över SKU:er som är ifyllda i avsnittet Skala på resursmenyn i Azure-portalen. Du kan också köra följande CLI-kommando

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