Architektura Azure Managed Redis (Preview)
Azure Managed Redis (Preview) 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.
Důležité
Azure Managed Redis je aktuálně ve verzi PREVIEW. Právní podmínky, které platí pro funkce Azure, které jsou ve verzi beta, verzi Preview nebo které zatím nejsou veřejně dostupné, najdete v Dodatečných podmínkách použití pro Microsoft Azure verze Preview.
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 verze Redis má několik významných omezení, včetně návrhu s jedním vláknem. 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 je schopen spustit pouze jeden proces serveru Redis kvůli návrhu komunity Redis s jedním vláknem.
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) spouští paralelně několik procesů serveru Redis (označovaných jako horizontální oddíly). Více horizontálních oddílů umožňuje efektivnější využití virtuálních procesorů na každém virtuálním počítači a vyšší výkon.
- Ne všechny primární horizontální oddíly Redis jsou na stejném virtuálním počítači nebo uzlu. Místo toho se horizontální oddíly primárních i replik distribuují napříč 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ý proces proxy pro správu horizontálních oddílů, zpracování správy připojení a aktivaci samoopravení.
Tato architektura umožňuje vyšší výkon i pokročilé funkce, jako je aktivní geografická replikace.
Clustering
Vzhledem k tomu, že Redis Enterprise dokáže používat více horizontálních oddílů na uzel, je každá instance Azure Managed Redis interně nakonfigurovaná tak, aby používala clustering napříč všemi úrovněmi a skladovými položkami. To zahrnuje menší instance, které jsou nastavené pouze pro použití jednoho horizontálního oddílu. Clustering je způsob, jak rozdělit data v instanci Redis mezi několik procesů Redis, označované také jako horizontální dělení. Azure Managed Redis nabízí dvě zásady clusteru, které určují, který protokol je pro klienty Redis dostupný pro připojení k instanci mezipaměti.
Zásady clusteru
Azure Managed Redis nabízí dvě možnosti pro zásady clusteringu: OSS a Enterprise. 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 operačního systému implementují stejné rozhraní API clusteru Redis jako komunitní edice 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 OSS se také nedají použít s modulem RediSearch.
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á neclusterovaným uživatelům. To znamená, že klientské knihovny Redis nemusí podporovat Clustering Redis, aby získaly některé výhody výkonu Redis Enterprise, což 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ž zásady podnikového clusteru zdají, že instance Azure Managed Redis je pro uživatele neclusterovaná, stále má určitá omezení u příkazů s více klíči.
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čů). Akce škálování nakonec dosáhne stejného výsledku – přidání další paměti, více virtuálních procesorů a dalších horizontálních oddílů. 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 zásad podnikového clusteringu se také můžou zobrazit CROSSSLOT chyby. Mezi sloty s clusteringem Enterprise jsou povoleny pouze následující příkazy s více klíči: DEL, MSET, MGET, EXISTS, UNLINKa TOUCH.
V databázích Active-Active 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 databázích Active-Active: MGET, EXISTSa TOUCH. Další informace naleznete v tématu Clustering databáze.
Konfigurace horizontálního dělení
Každá skladová položka Azure Managed Redis je nakonfigurovaná tak, aby spouštěla určitý počet procesů serveru Redis, horizontálních oddílů paralelně. Vztah mezi výkonem propustnosti, počtem horizontálních oddílů a počtem virtuálních procesorů dostupných v každé instanci je složitý. Přidávání horizontálních oddílů obecně zvyšuje výkon, protože operace Redis je možné spouštět paralelně. Pokud však horizontální oddíly nemůžou spouštět příkazy, protože nejsou k dispozici žádné virtuální procesory pro spouštění příkazů, výkon může ve skutečnosti vypustit. 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:
Počet horizontálních oddílů a virtuálních procesorů používaných v jednotlivých skladových počtech se může v průběhu času měnit, protože výkon optimalizuje tým Azure Managed Redis.
| Úrovně | Optimalizované pro flash | Optimalizováno pro paměť | Vyvážené | Compute Optimized |
|---|---|---|---|---|
| Velikost (GB) | virtuální procesory / primární horizontální oddíly | virtuální procesory / primární horizontální oddíly | virtuální procesory / primární horizontální oddíly | virtuální procesory / primární horizontální oddíly |
| 0.5 | - | - | 2/2 | - |
| 0 | - | - | 2/2 | - |
| 3 | - | - | 2/2 | 4/2 |
| 6 | - | - | 2/2 | 4/2 |
| 12 | - | 2/2 | 4/2 | 8/6 |
| 24 | - | 4/2 | 8/6 | 16/12 |
| 60 | - | 8/6 | 16/12 | 32/24 |
| 120 | - | 16/12 | 32/24 | 64/48 |
| 180 | - | 24/24 | 48/48 | 96/96 |
| 240 | 8/6 | 32/24 | 64/48 | 128/96 |
| 360 | - | 48/48 | 96/96 | 192/192 |
| 480 | 16/12 | 64/48 | 128/96 | 256/192 |
| 720 | 24/24 | 96/96 | 192/192 | 384/384 |
| 960 | 32/24 | 128/192 | 256/192 | - |
| 1440 | 48/48 | 192/192 | - | - |
| 1920 | 64/48 | 256/192 | - | - |
| 4500 | 144/96 | - | - | - |
Spuštění bez povoleného režimu vysoké dostupnosti
Bez povoleného režimu vysoké dostupnosti je možné spustit. To znamená, že vaše instance Redis nemá povolenou replikaci a nemá přístup ke sla dostupnosti. Nedoporučujeme spouštět v režimu mimo vysokou dostupnost mimo scénáře vývoje/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 nedostatku paměti.
Vertikální snížení kapacity
Vertikální snížení kapacity se v současné době ve službě Azure Managed Redis nepodporuje. Další informace najdete v tématu Požadavky a 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 je úložiště Flash nižší, můžete pomocí úrovně Flash Optimized odměňovat některé výkony za účelem 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 a stát se 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 příkazů pro čtení k zápisu příkazů.
- 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íčů. (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