Architektura Azure Managed Redis

Azure Managed Redis běží na stacku Redis Enterprise , který nabízí významné výhody oproti komunitní edici Redis. Následující informace poskytují podrobnější informace o tom, jak je Azure Managed Redis navržen, včetně informací, které můžou být užitečné pro výkonné uživatele.

Porovnání se službou Azure Cache for Redis

Úrovně Basic, Standard a Premium služby Azure Cache for Redis byly založeny na komunitní edici Redis. Tato komunitní edice Redis má několik důležitých omezení, včetně toho, že je jednovláknová. Tím se výrazně snižuje výkon a škálování je méně efektivní, protože služba plně nevyužívá více virtuálních procesorů. Typická instance Azure Cache for Redis používá architekturu, jako je tato:

Všimněte si, že se používají dva virtuální počítače – primární a replika. Tyto virtuální počítače se také nazývají "uzly". Primární uzel obsahuje hlavní proces Redis a přijímá všechny zápisy. Replikace se provádí asynchronně do uzlu repliky, aby během údržby, škálování nebo neočekávaného selhání poskytovala záložní kopii. Každý uzel může spustit pouze jeden proces serveru Redis kvůli jednovláknovému návrhu komunitního Redis.

Vylepšení architektury Azure Managed Redis

Azure Managed Redis používá pokročilejší architekturu, která vypadá nějak takto:

Existuje několik rozdílů:

• Každý virtuální počítač (neboli uzel) paralelně spouští několik procesů serveru Redis (nazývaných shardy). Více shardů umožňuje efektivnější využití vCPU na každém virtuálním stroji a vyšší výkon.
• Ne všechny primární shardy Redis jsou na stejném virtuálním počítači nebo uzlu. Místo toho jsou primární a replikační shardy rozděleny mezi oběma uzly. Vzhledem k tomu, že primární horizontální oddíly používají více prostředků procesoru než horizontální oddíly replik, tento přístup umožňuje paralelní spouštění více primárních horizontálních oddílů.
• Každý uzel má vysoce výkonný proxy proces pro správu shardů, správu připojení a spuštění samoopravy.

Tato architektura umožňuje vyšší výkon i pokročilé funkce, jako je aktivní geografická replikace.

Klastrování

Každá instance Azure Managed Redis je interně nakonfigurovaná tak, aby používala clustering napříč všemi úrovněmi a skladovými položkami. Azure Managed Redis je založený na Redis Enterprise, který dokáže používat více shardů na uzel. To zahrnuje menší instance, které jsou nastavené pouze pro použití jednoho shardu. Clustering je způsob, jak rozdělit data v instanci Redis mezi několik procesů Redis, označovaných také jako "sharding". Azure Managed Redis nabízí tři zásady clusteru, které určují, jaký protokol mohou klienti Redis použít pro připojení k instanci mezipaměti.

Zásady clusteru

Azure Managed Redis nabízí tři zásady clusteringu: OSS, Enterprise a Non-Clustered. Pro většinu aplikací se doporučuje zásady clusteru OSS , protože podporují vyšší maximální propustnost, ale pro každou verzi existují výhody a nevýhody.

Zásady clusteringu OSS implementují stejné rozhraní API clusteru Redis jako úrovně Azure Cache for Redis. Rozhraní API clusteru Redis umožňuje klientovi Redis připojit se přímo k horizontálním oddílům na každém uzlu Redis, což minimalizuje latenci a optimalizuje propustnost sítě, což umožňuje škálování propustnosti téměř lineárně s rostoucím počtem horizontálních oddílů a virtuálních procesorů. Zásady clusteringu operačního systému obecně poskytují nejlepší latenci a výkon propustnosti. Zásady clusteru operačního systému ale vyžadují, aby vaše klientská knihovna podporovala rozhraní API clusteru Redis. Dnes téměř všichni klienti Redis podporují rozhraní API clusteru Redis, ale kompatibilita může být problém se staršími verzemi klientů nebo specializovanými knihovnami.

Zásady clusteringu operačního systému se nedají použít s modulem RediSearch.

Protokol clusteringu OSS vyžaduje, aby klient navázal správná připojení shardů. Počáteční připojení je přes port 10000. Připojení k jednotlivým uzlům se provádí pomocí portů v rozsahu 85XX. Porty 85xx se můžou v průběhu času měnit a neměly by být pevně zakódované do vaší aplikace. Klienti Redis, kteří podporují clustering, používají příkaz CLUSTER NODES k určení přesných portů používaných pro primární a replikační shardy a vytvoření spojení s nimi za vás.

Zásady podnikového clusteringu jsou jednodušší konfigurací, která pro všechna připojení klientů využívá jeden koncový bod. Pomocí zásad podnikového clusteringu směruje všechny požadavky na jeden uzel Redis, který se pak používá jako proxy server, interně směruje požadavky na správný uzel v clusteru. Výhodou tohoto přístupu je, že Azure Managed Redis vypadá pro uživatele jako neklastrovaný. To znamená, že klientské knihovny Redis nemusí podporovat Clustering Redis, aby získaly některé výhody výkonu Redis Enterprise. Použití jednoho koncového bodu zvyšuje zpětnou kompatibilitu a zjednodušuje připojení. Nevýhodou je, že proxy s jedním uzlem může být kritickým bodem buď využití výpočetních prostředků, nebo propustnosti sítě.

Zásady clusteringu Enterprise jsou jediné, které lze použít s modulem RediSearch. I když se u podnikových zásad clusteru zdá, že instance Azure Managed Redis není pro uživatele clusterovaná, stále má určitá omezení u příkazů s více klíči.

Zásady clusteringu, které nejsou clusteringem, ukládají data do každého uzlu bez horizontálního dělení. Platí jenom pro ukládání do mezipaměti o velikosti 25 GB a menší. Mezi scénáře použití zásad clusteringu bez clusteringu patří:

• Při migraci z prostředí Redis, které není horizontálně dělené. Například topologie bez shardingů u základních, standardních a prémiových SKU služby Azure Cache for Redis.
• Při rozsáhlém spouštění příkazů mezi sloty a rozdělení dat na fragmenty by mohlo dojít k chybám. Například příkazy MULTI.
• Při použití Redisu jako zprostředkovatele zpráv, když nevyžaduje horizontální dělení.

Aspekty použití zásad bez clusteru jsou následující:

• To platí jenom pro úrovně Azure Managed Redis, které jsou menší nebo rovny 25 GB.
• Není tak výkonná jako jiné metody clusteringu, protože procesory můžou využívat více vláken pouze se softwarem Redis Enterprise, když je mezipaměť rozdělena na části.
• Pokud chcete vertikálně navýšit kapacitu mezipaměti Azure Managed Redis, musíte nejprve změnit zásady clusteru.
• Pokud přecházíte z topologie Basic, Standard nebo Premium, zvažte použití OSS clusterů ke zlepšení výkonu. Konfigurace, které nejsou clusterované, by se měly používat jenom v případě, že aplikace nepodporuje topologie operačního systému nebo enterprise.

Horizontální navýšení kapacity nebo přidání uzlů

Základní software Redis Enterprise umožňuje vertikální navýšení kapacity (pomocí větších virtuálních počítačů) nebo horizontální navýšení kapacity (přidáním dalších uzlů nebo virtuálních počítačů). Nakonec má každá akce škálování stejný výsledek – přidání další paměti, více vCPU a více shardů. Kvůli této redundanci azure Managed Redis nenabízí možnost řídit konkrétní počet uzlů používaných v každé konfiguraci. Tento detail implementace je abstrahován pro uživatele, aby se zabránilo nejasnostem, složitosti a neoptimální konfiguraci. Místo toho je každá skladová položka navržená s konfigurací uzlu, která maximalizuje virtuální procesory a paměť. Některé skladové položky Azure Managed Redis používají jenom dva uzly, zatímco některé používají více.

Příkazy s více klíči

Vzhledem k tomu, že instance Azure Managed Redis jsou navržené s clusterovou konfigurací, můžou se zobrazit CROSSSLOT výjimky u příkazů, které pracují s několika klíči. Chování se liší v závislosti na použitých zásadách clusteringu. Pokud používáte zásady clusteringu operačního systému, příkazy s více klíči vyžadují, aby se všechny klíče mapovaly na stejný slot hash.

U podnikových zásad clusteringu se také můžou zobrazit chyby CROSSSLOT. Napříč sloty s podnikovým clusteringem jsou povoleny pouze následující příkazy s více klíči: DEL, MSET, MGET, EXISTS, UNLINK a TOUCH.

V databázích aktivní-aktivní lze příkazy pro zápis s více klíči (DEL, MSET, UNLINK) spouštět pouze na klíčích, které jsou ve stejném slotu. Následující příkazy s více klíči jsou však povoleny napříč sloty v Active-Active databázích: MGET, EXISTS a TOUCH. Další informace získáte v tématu Clustering databáze.

Konfigurace horizontálního dělení

Každá SKU systému Azure Managed Redis je nakonfigurována tak, aby spouštěla určitý počet procesů serveru Redis, shardů paralelně. Vztah mezi průchodností, počtem shardů a počtem vCPU dostupných na každé instanci je složitý. Přidávání shardů obecně zvyšuje výkon, protože operace Redis mohou být spuštěny paralelně. Pokud však shardy nemohou spouštět příkazy, protože nejsou k dispozici žádné virtuální procesory pro jejich spuštění, výkon se může ve skutečnosti snížit. Následující tabulka ukazuje konfiguraci horizontálního dělení pro každou skladovou položku Azure Managed Redis. Tyto horizontální oddíly se mapují tak, aby optimalizovaly využití jednotlivých vCPU při rezervaci cyklů vCPU pro proxy server Redis Enterprise, agenta pro správu a systémové úlohy operačního systému, které mají vliv také na výkon.

Poznámka:

Azure Managed Redis v průběhu času optimalizuje výkon změnou počtu shardů a vCPU používaných pro jednotlivé SKU.

Důležité

Všechny paměťové vrstvy, které používají více než 235 GB úložiště, jsou ve verzi Public Preview, včetně Memory Optimized M350 a vyšších; Balanced B350 a vyšších; a Compute Optimized X350 a vyšších. Všechny tyto úrovně a vyšší jsou ve verzi Public Preview.

Všechny úrovně Optimalizované pro Flash jsou ve verzi Public Preview.

Skladové položky optimalizované pro paměť, vyvážený výkon a výpočetní kapacitu

Úrovně	Optimalizováno pro Paměť	Vyvážené	Optimalizované výpočetní prostředky
Velikost (GB)	virtuální CPU / primární fragmenty	virtuální CPU / primární fragmenty	virtuální CPU / primární fragmenty
0,5	-	2/1	-
1	-	2/1	-
3	-	2/2	4/2
6	-	2/2	4/2
12	2/2	4/2	8/6
dvacet čtyři	4/2	8/6	16. 12.
60	8/6	16. 12.	32/24
120	16. 12.	32/24	64/48
175	24/24	48/48	96/96
235	32/24	64/48	128/96
360 *	48/48	96/96	192/192
480 *	64/48	128/96	256/192
720 *	96/96	192/192	384/384
960 *	128/192	256/192	-
1440 *	192/192	-	-
1920 *	256/192	-	-

* Tyto úrovně jsou ve verzi Public Preview.

Skladová položka optimalizovaná pro Flash

Úrovně	Optimalizováno pro Flash (náhled)
Velikost (GB)	virtuální CPU / primární fragmenty
235 *	8/6
480 *	16. 12.
720 *	24/24
960 *	32/24
1440 *	48/48
1920 *	64/48
4500 *	144/96

* Tyto úrovně jsou ve verzi Public Preview.

Provoz bez povoleného režimu vysoké dostupnosti

Je možné spustit bez aktivovaného režimu vysoké dostupnosti (HA). To znamená, že vaše instance Redis nemá povolenou replikaci a nemá přístup ke sla dostupnosti. Nedoporučujeme spouštět v ne-HA režimu mimo scénáře určené pro vývoj/testování. V instanci, která je už vytvořená, nemůžete zakázat vysokou dostupnost. Vysokou dostupnost můžete povolit v instanci, která ji ale nemá. Vzhledem k tomu, že instance spuštěná bez vysoké dostupnosti využívá méně virtuálních počítačů a uzlů, virtuální procesory se nedají využívat tak efektivně, takže výkon může být nižší.

Vyhrazená paměť

V každé spravované instanci Azure Redis je přibližně 20 % dostupné paměti rezervované jako vyrovnávací paměť pro operace mimo mezipaměť, jako je replikace při převzetí služeb při selhání a aktivní vyrovnávací paměť geografické replikace. Tato vyrovnávací paměť pomáhá zlepšit výkon mezipaměti a zabránit vyhladovění paměti.

Zmenšování

Vertikální snížení kapacity se v současné době ve službě Azure Managed Redis nepodporuje. Další informace najdete v tématu Omezení škálování Azure Managed Redis.

Úroveň Optimalizovaná pro Flash

Úroveň Optimalizovaná pro Flash využívá úložiště NVMe Flash i paměť RAM. Vzhledem k tomu, že úložiště Flash má nižší náklady, použití úrovně Flash Optimized vám umožňuje snížit výkon ve prospěch cenové efektivity.

V instancích Optimalizovaných pro Flash je 20 % místa v mezipaměti v paměti RAM, zatímco druhý 80 % využívá úložiště Flash. Všechny klíče jsou uložené v paměti RAM, zatímco hodnoty mohou být uloženy v úložišti Flash nebo v paměti RAM. Software Redis inteligentně určuje umístění hodnot. Horké hodnoty, ke kterým se přistupuje často, jsou uloženy v paměti RAM, zatímco studené hodnoty, které se méně často používají, se uchovávají na flash. Před čtením nebo zápisem dat je nutné je přesunout do paměti RAM, čímž se stanou horkými daty.

Vzhledem k tomu, že Redis optimalizuje nejlepší výkon, instance nejprve vyplní dostupnou paměť RAM před přidáním položek do úložiště Flash. Naplnění paměti RAM má nejprve několik důsledků pro výkon:

• Při testování s nízkým využitím paměti může dojít k lepšímu výkonu a nižší latenci. Testování s úplnou instancí mezipaměti může přinést nižší výkon, protože se ve fázi testování nedostatku paměti používá pouze paměť RAM.
• Při zápisu dalších dat do mezipaměti se poměr dat v paměti RAM v porovnání s úložištěm Flash snižuje, což obvykle způsobuje snížení latence a výkonu propustnosti.

Úlohy vhodné pro úroveň Optimalizované pro Flash

Úlohy, které budou pravděpodobně dobře fungovat na úrovni Optimalizované pro Flash, mají často následující charakteristiky:

• Čtení náročné, s vysokým poměrem čtecích příkazů k zápisovým příkazům.
• Access se zaměřuje na podmnožinu klíčů, které se používají mnohem častěji než zbytek datové sady.
• Relativně velké hodnoty ve srovnání s názvy klíčových prvků. (Vzhledem k tomu, že názvy klíčů jsou vždy uložené v paměti RAM, mohou se velké hodnoty stát kritickým bodem pro růst paměti.)

Úlohy, které nejsou vhodné pro úroveň Optimalizované pro Flash

Některé úlohy mají charakteristiky přístupu, které jsou méně optimalizované pro návrh úrovně Optimalizované pro Flash:

• Psaní náročných úloh
• Vzory náhodného nebo jednotného přístupu k datům ve většině datových sad
• Dlouhé názvy klíčů s relativně malými velikostmi hodnot

Související obsah

• Škálování instance Azure Managed Redis