Sdílet prostřednictvím

Škálování instance Azure Managed Redis (Preview)

  • Článek

Služba Azure Managed Redis (Preview) má různé nabídky skladových položek a úrovní, které poskytují flexibilitu při výběru velikosti a výkonu mezipaměti. Kapacitu můžete vertikálně navýšit na větší velikost paměti nebo změnit na úroveň s vyšším výpočetním výkonem. V tomto článku se dozvíte, jak škálovat mezipaměť pomocí webu Azure Portal a nástrojů, jako je Azure PowerShell a Azure CLI.

Poznámka:

Vzhledem k tomu, že každá úroveň Azure Managed Redis má prakticky stejné funkce, používá se škálování obvykle jen ke změně charakteristik paměti a výkonu.

Důležité

V současné době je podporováno pouze vertikální navýšení kapacity na větší velikost paměti nebo vyšší úroveň výkonu. Vertikální snížení kapacity paměti nebo na méně výkonnou úroveň zatím není podporováno.

Typy škálování

Azure Managed Redis podporuje škálování ve dvou dimenzích:

  • Paměť Zvýšení paměti zvyšuje velikost instance Redis, což umožňuje ukládat více dat.

  • Virtuální procesory Azure Managed Redis nabízí tři úrovně (Optimalizováno pro paměť, Vyvážené a Optimalizováno pro výpočty), které mají pro každou úroveň paměti rostoucí počet virtuálních procesorů. Škálování na úroveň s více virtuálními procesory zvyšuje výkon instance, aniž byste museli zvýšit paměť. Na rozdíl od komunitní edice Redis, která může využívat pouze jeden virtuální procesor, používá Azure Managed Redis sadu Redis Enterprise, která dokáže používat více virtuálních procesorů. To znamená, že počet virtuálních procesorů používaných vaší instancí Redis přímo koreluje s výkonem propustnosti a latence.

Úrovně výkonu

K dispozici jsou čtyři úrovně Azure Managed Redis, z nichž každá má různé charakteristiky výkonu a cenové úrovně.

Tři úrovně jsou určeny pro data v paměti:

  • Optimalizováno pro paměť Ideální pro případy použití náročné na paměť, které vyžadují vysoký poměr paměti k virtuálnímu procesoru (8:1), ale nepotřebují nejvyšší výkon propustnosti. Poskytuje nižší cenový bod pro scénáře, kdy je potřeba méně výpočetního výkonu nebo propustnosti, což je skvělou volbou pro vývojová a testovací prostředí.
  • Vyváženo (paměť + výpočty). Nabízí vyvážený poměr paměti k virtuálnímu procesoru (4:1), který je ideální pro standardní úlohy. Zajišťuje vhodnou rovnováhu paměti a výpočetních prostředků.
  • Optimalizováno pro výpočty. Navržené pro úlohy náročné na výkon, které vyžadují maximální propustnost, s poměrem nedostatku paměti na vCPU (2:1). Je ideální pro aplikace, které vyžadují nejvyšší výkon.

Jedna úroveň ukládá data jak v paměti, tak na disk:

  • Optimalizováno pro Flash Umožňuje clusterům Redis automaticky přesouvat méně často využívaná data z paměti (RAM) do úložiště NVMe. To snižuje výkon, ale umožňuje nákladově efektivní škálování mezipamětí s velkými datovými sadami.

Rychlé vrstvy a skladové položky

Tabulka znázorňující různé konfigurace paměti a virtuálních procesorů pro každou skladovou položku a úroveň Azure Managed Redis

Výkon (propustnost a latence)

Srovnávací testy výkonu a další informace o měření výkonu jednotlivých skladových položek a úrovní najdete v tématu Testování výkonu s využitím Azure Managed Redis.

Kdy škálovat

Stav a výkon mezipaměti můžete monitorovat pomocí funkcí monitorování služby Azure Managed Redis. Tyto informace slouží k určení, kdy se má mezipaměť škálovat.

Pokud potřebujete škálovat, můžete monitorovat následující metriky.

  • Procesor
    • Vysoké využití procesoru znamená, že server Redis nemůže držet krok s požadavky od všech klientů. Vertikální navýšení kapacity na více virtuálních procesorů pomáhá distribuovat požadavky napříč několika procesy Redis. Škálování také pomáhá distribuovat šifrování/dešifrování protokolu TLS a připojení/odpojení a zrychlit instance mezipaměti pomocí protokolu TLS.
  • Využití paměti
    • Vysoké využití paměti znamená, že pro aktuální velikost mezipaměti používáte příliš rozsáhlá data. Zvažte škálování na mezipaměť s větší pamětí.
  • Připojení klientů
    • Každá velikost mezipaměti má limit počtu klientských připojení, která může podporovat. Pokud se připojení klientů blíží limitu mezipaměti, zvažte škálování na větší velikost paměti nebo vyšší úroveň výkonu.
    • Další informace o limitech připojení podle velikosti mezipaměti najdete v tématu Testování výkonu s využitím Azure Managed Redis.
  • Šířka pásma sítě
    • Když server Redis překročí dostupnou šířku pásma, může požadavkům klientů vypršet časový limit, protože server nemůže odesílat data klientovi dostatečně rychle. Pokud chcete zjistit využití šířky pásma na straně serveru, můžete použít metriky Čtení z mezipaměti a Zápisy do mezipaměti. Pokud váš server Redis překračuje dostupnou šířku pásma sítě, zvažte škálování na vyšší úroveň výkonu nebo větší mezipaměť.
    • Na dostupnou šířku pásma sítě má vliv volba zásad clusteru. Obecně platí, že zásady clusteru OSS mají větší šířku pásma sítě než zásady clusteru Enterprise. Další informace najdete v článku Zásady clusteru.
    • Další informace o šířce pásma dostupné v síti podle velikosti mezipaměti najdete v tématu Testování výkonu s využitím Azure Managed Redis.

Další informace o určení cenové úrovně mezipaměti, kterou chcete použít, najdete v tématu Výběr správné úrovně.

Poznámka:

Další informace o optimalizaci procesu škálování najdete v průvodce doporučenými postupy pro škálování.

Požadavky/omezení škálování Azure Managed Redis

  • Z úrovní Optimalizováno pro paměť, Vyrovnáno nebo Optimalizováno pro výpočty není možné škálovat na úroveň Optimalizované pro Flash ani naopak.
  • Nejde vertikálně snížit kapacitu na skladovou položku s menším počtem vCPU. (Napříč úrovněmi nebo v rámci úrovně.)
  • Kapacitu nemůžete vertikálně snížit na menší velikost paměti, i když má stejné nebo více virtuálních procesorů.
  • V některých případech se při škálování může změnit základní IP adresa instance Redis. Záznam DNS pro instanci se změní a pro většinu aplikací je transparentní. Pokud ale ke konfiguraci připojení k mezipaměti nebo ke konfiguraci skupin zabezpečení sítě nebo bran firewall umožňujících provoz do mezipaměti použijete IP adresu, může mít vaše aplikace po aktualizaci záznamů DNS potíže.
  • Škálování instance ve skupině geografické replikace má určitá další omezení. Další informace najdete v tématu Je škálování při geografické replikaci omezeno?

Jak se dá škálovat

Tip

V jedné operaci můžete změnit velikost paměti i úroveň výkonu.

Škálování pomocí webu Azure Portal

  1. Pokud chcete škálovat mezipaměť, přejděte do mezipaměti na webu Azure Portal a v nabídce Prostředek vyberte Škálovat .

    Snímek obrazovky znázorňující možnost Škálování vybraná v nabídce Zdroje pro mezipaměť Organizace

  2. Pokud chcete vertikálně navýšit kapacitu, zvolte jiný typ mezipaměti a pak zvolte Uložit.

    Důležité

    Pokud vyberete skladovou položku, na kterou nelze škálovat, možnost Uložit je zakázaná. Podrobnosti o tom, které možnosti škálování jsou povolené, najdete v části Požadavky a omezení škálování Spravovaného Redisu v Azure.

    Snímek obrazovky znázorňující úrovně Enterprise v pracovním podokně

  3. Zatímco se mezipaměť škáluje na novou úroveň, zobrazí se oznámení o škálování redis Cache .

    Snímek obrazovky s oznámením o škálování podnikové mezipaměti

  4. Po dokončení škálování se stav změní ze škálování na Spuštěno.

Škálování přes rozhraní PowerShell

Instance Azure Managed Redis můžete škálovat v rozhraní PowerShell pomocí rutiny Update-AzRedisEnterpriseCache. Vlastnost Sku můžete upravit tak, aby vybrala požadovanou úroveň a skladovou položku. Následující příklad ukazuje, jak škálovat mezipaměť pojmenovanou myCache na instanci X20 optimalizovanou pro výpočty (24 GB).

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

Škálování přes rozhraní Azure CLI

Pokud chcete škálovat instance Azure Managed Redis v rozhraní Azure CLI, zadejte příkaz az redisenterprise update. Vlastnost sku můžete upravit tak, aby vybrala požadovanou úroveň a skladovou položku. Následující příklad ukazuje, jak škálovat mezipaměť pojmenovanou myCache na instanci X20 optimalizovanou pro výpočty (24 GB).

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

Časté dotazy ke škálování

Následující seznam obsahuje odpovědi na nejčastější dotazy týkající se škálování Azure Managed Redis.

Mohu škálovat v rámci nebo napříč úrovněmi?

Vždy můžete škálovat na vyšší úroveň výkonu při stejné velikostí paměti nebo na větší velikost paměti při stejné úrovni výkonu. Informace o škálování na nižší úroveň výkonu nebo menší velikost paměti najdete v tématu Požadavky/omezení škálování Azure Managed Redis.

Musím po škálování změnit název mezipaměti nebo přístupové klíče?

Nikoli, název a klíče mezipaměti se během operace škálování nezmění.

Jak škálování funguje?

  • Při škálování instance Redis se jeden z uzlů v clusteru Redis vypne a znovu vytvoří s novou velikostí. Potom se přenesou data a druhý uzel provede před opětovným zřízením podobné převzetí služeb při selhání. Podobá se to procesu, ke kterému dochází během oprav nebo selhání jednoho z uzlů mezipaměti.
  • Při škálování na instanci s více virtuálními procesory se zřídí a nové horizontální oddíly a jsou přidány do clusteru serveru Redis. Data se pak znovu sdílí napříč všemi horizontálními oddíly.

Další informace o tom, jak Azure Managed Redis zpracovává horizontální dělení, najdete v tématu Konfigurace horizontálního dělení.

Ztratím při škálování data z mezipaměti?

  • Pokud je povolený režim vysoké dostupnosti, měla by být během operací škálování zachována všechna data.
  • Pokud vertikálně snižujete kapacitu na menší úroveň paměti, může dojít ke ztrátě dat, pokud velikost dat při vertikálním snížení kapacity mezipaměti překročí novou, menší velikost. Pokud při vertikálním snížení kapacity dojde ke ztrátě dat, vyřadí se klíče pomocí zásad vyřazování allkeys-lru.
  • Pokud je režim vysoké dostupnosti zakázaný, dojde ke ztrátě všech dat a během operace škálování nebude mezipaměť k dispozici.

Bude mezipaměť během škálování dostupná?

  • Instance Azure Managed Redis s povoleným režimem vysoké dostupnosti zůstanou během operace škálování dostupné. Při škálování těchto mezipamětí ale může dojít k výkyvům připojení. Tyto výkyvy připojení jsou obvykle krátké a klienti Redis můžou obvykle znovu navázat připojení okamžitě.
  • Pokud je režim vysoké dostupnosti zakázaný, je instance Azure Managed Redis během operací škálování offline.

Je škálování při geografické replikaci omezeno?

Když je nakonfigurovaná aktivní geografická replikace, nemůžete ve skupině geografické replikace kombinovat velikosti mezipamětí. V důsledku toho škálování mezipamětí ve skupině geografické replikace vyžaduje několik dalších kroků. Pokyny najdete v tématu Škálování instancí ve skupině geografické replikace.

Jak dlouho škálování trvá?

Doba škálování závisí na několika faktorech. Podívejte se na některé faktory, které mohou dobu škálování ovlivnit.

  • Množství dat: Replikace větších objemů dat trvá delší dobu.
  • Vysoké požadavky na zápis: Vyšší počet zápisů znamená, že se více dat replikuje napříč uzly nebo horizontálními oddíly.
  • Vysoké využití procesoru: Vyšší využití procesoru znamená, že je server Redis zaneprázdněný a k dokončení redistribuce dat je k dispozici omezený počet cyklů procesoru.

Obecně platí, že když škálujete instanci bez dat, trvá tato akce přibližně 10 minut.

Jak zjistím, kdy je škálování dokončeno?

Na webu Azure Portal uvidíte probíhající operaci škálování. Po dokončení škálování se stav mezipaměti změní na Spuštěno.

Používá Azure Managed Redis clustering?

Na rozdíl od Azure Cache for Redis používá Azure Managed Redis clustering napříč všemi úrovněmi a skladovými položkami. Clustering umožňuje významné optimalizace výkonu. Každá skladová položka Azure Managed Redis je nakonfigurovaná pro optimalizovaný počet horizontálních oddílů na počet dostupných virtuálních procesorů. Počet horizontálních oddílů není konfigurovatelný uživatelem.

Kolik horizontálních oddílů používá každá skladová položka Azure Managed Redis?

Vzhledem k tomu, že Azure Managed Redis běží na softwaru Redis Enterprise, je možné horizontální oddíly používat v hustší konfiguraci než v komunitní verzi serveru Redis. Další informace o konkrétním počtu horizontálních oddílů používaných v jednotlivých skladových položkách najdete v konfiguraci horizontálního dělení.

Jak jsou klíče distribuovány v clusteru?

V dokumentaci Redis k distribučnímu modelu klíčů: Prostor klíčů je rozdělený na 16 384 slotů. Každý klíč je hashovaný a přiřazený jednomu z těchto slotů, které jsou distribuovány napříč uzly clusteru. Můžete nakonfigurovat, která část klíče je hashována, a zajistit tak umístění více klíčů ve stejném horizontálním oddílu pomocí mřížek.

  • Klíče s mřížkou – pokud je některá část klíče uzavřená ve znacích { a }, je tato část klíče hashována pouze pro účely určení slotu hash klíče. Například následující tři klíče by se nacházely ve stejném horizontálním oddílu: {key}1, {key}2a {key}3, protože je hashována pouze část názvu key. Úplný seznam specifikací mřížek klíčů najdete v tématu Mřížky klíčů.
  • Klíče bez mřížky – k hashování se používá celý název klíče, což vede ke statisticky rovnoměrné distribuci napříč horizontálními oddíly mezipaměti.

Pro zajištění nejlepšího výkonu a propustnosti doporučujeme distribuovat klíče rovnoměrně. Pokud používáte klíče s mřížkou, je zajištění rovnoměrné distribuce klíčů zodpovědností aplikace.

Další informace najdete v tématu Distribuční model klíčů, Horizontální dělení dat clusteru Redis a Mřížky klíčů.

Jaká je největší velikost mezipaměti, kterou mohu vytvořit?

Největší velikost mezipaměti, kterou můžete použít, je 4,5 TB, označovaná jako instance A4500 optimalizovaná pro Flash. Ceny služby Azure Cache for Redis

Jaký je rozdíl mezi zásadami clusterů OSS a Enterprise?

Zásady clusteru OSS jsou stejné jako přístup ke clusteringu používaný v komunitní edici Redis. Zásady clusteru OSS jsou obvykle výkonnější. Zásady clusteru Enterprise implementují clustering tak, aby se klientovi jevil jako neclusterovaná instance Redis. Tento přístup může být méně výkonný, ale může zabránit problémům s kompatibilitou klientů. V současné době není ve spuštěné instanci možné přepínat mezi zásadami clusteru. Další informace najdete v článku Zásady clusteru.

Další kroky