Jaké jsou osvědčené postupy pro úrovně Enterprise a Enterprise Flash
Tady jsou osvědčené postupy při používání úrovní Enterprise a Enterprise Flash služby Azure Cache for Redis.
Zónová redundance
Důrazně doporučujeme nasadit nové mezipaměti v zónově redundantní konfiguraci. Redundance zón zajišťuje, aby se uzly Redis Enterprise rozprostřely mezi tři zóny dostupnosti, což zvyšuje redundanci z výpadků na úrovni datového centra. Použití redundance zón zvyšuje dostupnost. Další informace najdete v tématu Smlouvy o úrovni služeb (SLA) pro online služby.
Redundance zón je důležitá na podnikové úrovni, protože instance mezipaměti vždy používá alespoň tři uzly. Dva uzly jsou datové uzly, které obsahují vaše data, a uzel kvora. Zvýšení kapacity škáluje počet datových uzlů v přírůstcích sudých čísel.
Existuje také jiný uzel označovaný jako uzel kvora. Tento uzel monitoruje datové uzly a automaticky vybere nový primární uzel, pokud došlo k převzetí služeb při selhání. Redundance zón zajišťuje rovnoměrné rozdělení uzlů napříč třemi zónami dostupnosti, což minimalizuje potenciál ztráty kvora. Zákazníci se neúčtují za uzel kvora a za použití redundance zóny nad rámec poplatků za zónovou šířku pásma uvnitř zón se neúčtují žádné další poplatky.
Škálování
Ve vrstvách Enterprise a Enterprise Flash služby Azure Cache for Redis doporučujeme určit prioritu vertikálního navýšení kapacity nad horizontálním navýšením kapacity. Určete prioritu vertikálního navýšení kapacity, protože úrovně Enterprise jsou založené na Redis Enterprise, což umožňuje využívat více jader procesoru ve větších virtuálních počítačích.
Naopak opačné doporučení platí pro úrovně Basic, Standard a Premium, které jsou založené na opensourcových redisech. Vevětšiněch
Horizontální dělení a využití procesoru
V úrovních Basic, Standard a Premium služby Azure Cache for Redis je určení počtu virtuálních procesorů využitých vCPU jednoduché. Každý uzel Redis běží na vyhrazeném virtuálním počítači. Proces serveru Redis je jednovláknový a využívá jeden virtuální procesor na každém primárním a každém uzlu repliky. Ostatní virtuální procesory na virtuálním počítači se stále používají pro jiné aktivity, jako je koordinace pracovních postupů pro různé úlohy, monitorování stavu a zatížení TLS.
Když používáte clustering, výsledkem je rozložení dat mezi více uzlů s jedním horizontálním oddílem na jeden uzel. Zvýšením počtu horizontálních oddílů lineárně zvýšíte počet virtuálních procesorů, které používáte, na základě počtu horizontálních oddílů v clusteru.
Redis Enterprise může na druhou stranu použít více virtuálních procesorů pro samotnou instanci Redis. Jinými slovy, všechny úrovně Azure Cache for Redis můžou pro úlohy na pozadí a monitorování používat více virtuálních procesorů, ale pouze úrovně Enterprise a Enterprise Flash můžou využívat více virtuálních procesorů na virtuální počítač pro horizontální oddíly Redis. Tabulka ukazuje počet efektivních virtuálních procesorů používaných pro každou konfiguraci skladové položky a kapacity (tj. horizontálního navýšení kapacity).
Tabulky zobrazují počet virtuálních procesorů používaných pro primární horizontální oddíly, nikoli horizontální oddíly repliky. Horizontální oddíly nemapují 1:1 na počet virtuálních procesorů. Tabulky znázorňují jenom virtuální procesory, nikoli horizontální oddíly. Některé konfigurace používají více horizontálních oddílů, než jsou dostupné virtuální procesory, aby se zvýšil výkon v některých scénářích použití.
E1
| Kapacita | Efektivní virtuální procesory |
|---|---|
| 2 | 1 (nárazové) |
E5
| Kapacita | Efektivní virtuální procesory |
|---|---|
| 2 | 1 |
| 4 | 2 |
| 6 | 6 |
E10
| Kapacita | Efektivní virtuální procesory |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E20
| Kapacita | Efektivní virtuální procesory |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E50
| Kapacita | Efektivní virtuální procesory |
|---|---|
| 2 | 6 |
| 4 | 6 |
| 6 | 6 |
| 8 | 30 |
| 10 | 30 |
E100
| Kapacita | Efektivní virtuální procesory |
|---|---|
| 2 | 6 |
| 4 | 30 |
| 6 | 30 |
| 8 | 30 |
| 10 | 30 |
E200
| Kapacita | Efektivní virtuální procesory |
|---|---|
| 2 | 30 |
| 4 | 60 |
| 6 | 60 |
| 8 | 120 |
| 10 | 120 |
E400
| Kapacita | Efektivní virtuální procesory |
|---|---|
| 2 | 60 |
| 4 | 120 |
| 6 | 120 |
| 8 | 240 |
| 10 | 240 |
F300
| Kapacita | Efektivní virtuální procesory |
|---|---|
| 3 | 6 |
| 9 | 30 |
F700
| Kapacita | Efektivní virtuální procesory |
|---|---|
| 3 | 30 |
| 9 | 30 |
F1500
| Kapacita | Efektivní virtuální procesory |
|---|---|
| 3 | 30 |
| 9 | 90 |
Clustering v podniku
Úrovně Enterprise a Enterprise Flash jsou v podstatě clusterované, na rozdíl od úrovní Basic, Standard a Premium. Implementace závisí na vybraných zásadách clusteringu. Úrovně Enterprise nabízejí 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 open source Redis. Rozhraní API clusteru Redis umožňuje klientovi Redis připojit se přímo ke každému uzlu Redis, což minimalizuje latenci a optimalizuje propustnost sítě. V důsledku toho se při horizontálním navýšení kapacity clusteru s více uzly získá téměř lineární škálovatelnost. Zásady clusteringu operačního systému obecně poskytují nejlepší latenci a výkon propustnosti, ale vyžaduje, aby vaše klientská knihovna podporovala clustering Redis. 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 klientské knihovny Redis nemusí podporovat clustering Redis, aby využívaly více uzlů. 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.
Příkazy s více klíči
Vzhledem k tomu, že úrovně Enterprise používají clusterovanou konfiguraci, můžou se zobrazit CROSSSLOT výjimky u příkazů, které pracují s více 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.
Osvědčené postupy pro Enterprise Flash
Úroveň Enterprise Flash využívá úložiště NVMe Flash i paměť RAM. Vzhledem k tomu, že úložiště Flash je nižší, díky použití úrovně Enterprise Flash můžete snížit výkon za účelem cenové efektivity.
V instancích Enterprise 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ň Enterprise Flash
Úlohy, které budou pravděpodobně dobře fungovat na podnikové úrovni 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ň Enterprise Flash
Některé úlohy mají charakteristiky přístupu, které jsou méně optimalizované pro návrh úrovně 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
Zpracování scénářů mimo oblast s aktivní geografickou replikací
Aktivní geografická replikace je výkonná funkce, která výrazně zvyšuje dostupnost při používání úrovní Enterprise služby Azure Cache for Redis. Pokud dojde k výpadku oblasti, měli byste však podniknout kroky k přípravě mezipamětí.
Podívejte se například na tyto tipy:
- Určete předem, na kterou jinou mezipaměť ve skupině geografické replikace se má přepnout, pokud oblast přestane fungovat.
- Ujistěte se, že jsou brány firewall nastavené tak, aby všechny aplikace a klienti měli přístup k identifikované mezipaměti zálohování.
- Každá mezipaměť ve skupině geografické replikace má svůj vlastní přístupový klíč. Určete, jak se aplikace při cílení na mezipaměť zálohování přepne na jiné přístupové klíče.
- Pokud dojde ke snížení mezipaměti ve skupině geografické replikace, začne ve všech mezipamětí ve skupině geografické replikace probíhat sestavení metadat. Metadata nelze zahodit, dokud se zápisy nedají znovu synchronizovat do všech mezipamětí. Můžete zabránit sestavení metadat vynucením zrušení propojení mezipaměti, která je mimo provoz. Zvažte monitorování dostupné paměti v mezipaměti a zrušení propojení, pokud dochází k zatížení paměti, zejména u úloh náročných na zápis.
Je také možné použít model jističe. Pomocí vzoru můžete automaticky přesměrovat provoz mimo mezipaměť, u které dochází k výpadku oblasti, a do záložní mezipaměti ve stejné skupině geografické replikace. K povolení přesměrování použijte služby Azure, jako je Azure Traffic Manager nebo Azure Load Balancer .
Trvalost dat vs. zálohování dat
Funkce trvalosti dat na úrovních Enterprise a Enterprise Flash je navržená tak, aby automaticky poskytovala rychlý bod obnovení pro data, když mezipaměť klesne. Rychlé obnovení je možné uložením souboru RDB nebo AOF do spravovaného disku připojeného k instanci mezipaměti. Soubory trvalosti na disku nejsou přístupné uživatelům.
Mnoho zákazníků chce používat trvalost k pravidelnému zálohování dat v mezipaměti. Tímto způsobem nedoporučujeme používat trvalost dat. Místo toho použijte funkci importu a exportu. Kopie dat mezipaměti můžete exportovat ve formátu RDB přímo do zvoleného účtu úložiště a aktivovat export dat tak často, jak potřebujete. Export je možné aktivovat z portálu nebo pomocí nástrojů rozhraní příkazového řádku, PowerShellu nebo sady SDK.
Omezení skladové položky E1
Skladová položka E1 je určená především pro scénáře vývoje/testování. E1 běží na menších virtuálních počítačích s možností nárazu. Virtuální počítače s možností nárazu nabízejí proměnlivý výkon na základě využití procesoru. Na rozdíl od jiných nabídek SKU Enterprise nemůžete vertikálně navýšit kapacitu skladové položky E1, i když je stále možné vertikálně navýšit kapacitu na větší skladovou položku. Skladová položka E1 také nepodporuje aktivní geografickou replikaci.