Sdílet prostřednictvím

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

  • Článek

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, škálování se obvykle používá jen ke změně charakteristik paměti a výkonu.

Důležité

V současné době se podporuje 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ň se zatím nepodporuje.

Typy škálování

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

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

  • VCPUs Azure Managed Redis nabízí tři úrovně (Optimalizováno pro paměť, Vyvážené a Optimalizované výpočty), které mají rostoucí počet virtuálních procesorů pro každou úroveň paměti. Škálování na úroveň s více virtuálními procesory zvyšuje výkon vaší instance, aniž byste museli zvýšit paměť. Na rozdíl od komunitní edice Redis, která může využívat pouze jeden virtuální procesor, Azure Managed Redis používá 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čené 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ážená (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. Poskytuje rovnováhu paměti a výpočetních prostředků v dobrém stavu.
  • 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 vrstva ukládá data jak v paměti, tak na disk:

  • Optimalizované pro blesk. Umožňuje clusterům Redis automaticky přesouvat méně často přístupná 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 pomocí Azure Managed Redis.

Kdy škálovat

Pomocí funkcí monitorování služby Azure Managed Redis můžete monitorovat stav a výkon mezipaměti. 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 vCPU 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 velikost dat je pro aktuální velikost mezipaměti příliš velká. Zvažte škálování na velikost mezipaměti s větší pamětí.
  • Klientská připojení
    • Každá velikost mezipaměti má limit počtu klientských připojení, která může podporovat. Pokud se připojení klientů blíží limitu velikosti 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 pomocí Azure Managed Redis.
  • Šířka pásma sítě
    • Pokud server Redis překročí dostupnou šířku pásma, klienti můžou časového limitu, protože server nemůže odesílat data klientovi dostatečně rychle. Pokud chcete zjistit, kolik šířky pásma na straně serveru se používá, zkontrolujte metriky Čtení mezipaměti a Zápis 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ší velikost mezipaměti.
    • Volba zásad clusteru má vliv na dostupnou šířku pásma sítě. Obecně platí, že zásady clusteru operačního systému mají větší šířku pásma sítě než zásady podnikového clusteru. Další informace najdete v tématu 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 pomocí Azure Managed Redis.

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

Poznámka:

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

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

  • Nemůžete škálovat z úrovní Optimalizováno pro paměť, Vyrovnávání nebo Optimalizováno pro výpočty na úroveň Optimalizované pro Flash nebo naopak.
  • Nejde vertikálně snížit kapacitu na skladovou položku s menším počtem vCPU. (Napříč úrovněmi nebo v rámci vrstvy.)
  • 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 použijete IP adresu 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, 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 Omezení škálování geografické replikace?

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í pomocí PowerShellu

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

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

Škálování pomocí Azure CLI

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

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

Nejčastější 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.

Můžu škálovat v rámci nebo napříč úrovněmi?

Vždy můžete škálovat na vyšší úroveň výkonu se stejnou velikostí paměti nebo větší velikostí paměti ve 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 a omezení škálování Azure Managed Redis.

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

Ne, 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ří novou velikost. Potom se data přenesou a druhý uzel provede podobné převzetí služeb při selhání před opětovným zřízením. Podobá se 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 přidají nové horizontální oddíly do clusteru serveru Redis. Data se pak znovu horizontálně dě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í.

Při škálování ztratím data z mezipaměti?

  • Pokud je povolený režim vysoké dostupnosti, během operací škálování by se měla zachovat všechna data.
  • Pokud vertikálně navyšujete kapacitu na menší úroveň paměti, může dojít ke ztrátě dat, pokud velikost dat překročí novou menší velikost při vertikálním snížení kapacity mezipaměti. Pokud při vertikálním snížení kapacity dojde ke ztrátě dat, klíče se vyřadí pomocí zásad vyřazení 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ěť dostupná během škálování?

  • 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 ke třem tečkám připojení. Tyto tři tečky 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.

Existují omezení škálování u geografické replikace?

Když je nakonfigurovaná aktivní geografická replikace , nemůžete kombinovat a odpovídat velikostem mezipaměti ve skupině geografické replikace. 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 trvá škálování?

Doba škálování závisí na několika faktorech. Tady jsou některé faktory, které můžou ovlivnit, jak dlouho škálování trvá.

  • 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 server Redis je zaneprázdněný a k dokončení redistribuce dat jsou k dispozici omezené cykly procesoru.

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

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

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ů pro 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 komunitě Redis. Další informace o konkrétním počtu horizontálních oddílů používaných v jednotlivých skladových posílaných skladových posílaných skladových položek najdete v konfiguraci horizontálního dělení.

Jak se klíče distribuují v clusteru?

V dokumentaci k Redisu o distribučním 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, aby se zajistilo, že se více klíčů nachází ve stejném horizontálním oddílu pomocí značek hash.

  • Klíče se značkou hash – pokud je některá část klíče uzavřená { a }tato část klíče je 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 pouze key část názvu je hashována. Úplný seznam specifikací značek hash klíčů najdete v tématu Značky hash klíčů.
  • Klíče bez značky hash – celý název klíče se používá k hashování, 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 rovnoměrně distribuovat klíče. Pokud používáte klíče se značkou hash, je zodpovědností aplikace zajistit rovnoměrné distribuce klíčů.

Další informace najdete v tématu Distribuční model klíčů, horizontální dělení dat clusteru Redis a značky hash klíčů.

Jaká je největší velikost mezipaměti, kterou můžu vytvořit?

Největší velikost mezipaměti, kterou můžete mí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 operačního systému a clusteru Enterprise?

Zásady clusteru OSS jsou stejné jako přístup clusteringu používaný v komunitní edici Redis. Zásady clusteru OSS jsou obvykle výkonnější. Zásady podnikového clusteru implementují clustering tak, aby se klientovi zdály 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í možné přepínat mezi zásadami clusteru ve spuštěné instanci. Další informace najdete v tématu Zásady clusteru.

Další kroky