Azure Managed Redis-architektúra

Az Azure Managed Redis a Redis Enterprise technológiai veremben fut, amely jelentős előnyöket biztosít a Redis közösségi kiadáshoz képest. Az alábbi információk részletesebben ismertetik az Azure Managed Redis létrehozásának módját, beleértve azokat az információkat is, amelyek hasznosak lehetnek a felhasználók számára.

Összehasonlítás az Azure Cache for Redis szolgáltatással

Az Azure Cache for Redis alapszintű, standard és prémium szintjei a Redis közösségi kiadásán futnak. A Redis e közösségi kiadása számos jelentős korlátozást tartalmaz, beleértve az egyszálas kiadást is. Ez a korlátozás jelentősen csökkenti a teljesítményt, és kevésbé hatékonyá teszi a skálázást, mivel a szolgáltatás nem használja teljes mértékben a több vCPU-t. Egy tipikus Azure Cache for Redis-példány az alábbihoz hasonló architektúrát használ:

Figyelje meg, hogy két virtuális gépet használnak : egy elsődleges és egy replikát. Ezeket a virtuális gépeket csomópontoknak is nevezik. Az elsődleges csomópont tartalmazza a fő Redis-folyamatot, és minden írást elfogad. A replikáció aszinkron módon történik a replikacsomóponton, hogy biztonsági másolatot készítsen a karbantartás, a skálázás vagy a váratlan hiba során. Minden csomópont csak egyetlen Redis-kiszolgálófolyamatot futtathat a közösségi Redis egyszálas kialakítása miatt.

Az Azure Managed Redis architekturális fejlesztései

Az Azure Managed Redis egy fejlettebb architektúrát használ, amely így néz ki:

Több különbség is van:

• Minden virtuális gép (vagy csomópont) több Redis-kiszolgálófolyamatot (úgynevezett szegmenseket) futtat párhuzamosan. A több szegmens lehetővé teszi a vCPU-k hatékonyabb kihasználását az egyes virtuális gépeken és nagyobb teljesítményt.
• Nem minden elsődleges Redis-szegmens található ugyanazon a virtuális gépen/csomóponton. Ehelyett az elsődleges és replika szegmensek mindkét csomóponton el vannak osztva. Mivel az elsődleges szegmensek több CPU-erőforrást használnak, mint a replika szegmensei, ez a megközelítés lehetővé teszi, hogy több elsődleges szegmens fusson párhuzamosan.
• Minden csomópont nagy teljesítményű proxyfolyamattal rendelkezik a szegmensek kezeléséhez, a kapcsolatkezelés kezeléséhez és az öngyógyítás aktiválásához.

Ez az architektúra lehetővé teszi a nagyobb teljesítményt és a speciális funkciókat, például az aktív georeplikációs funkciókat.

Klaszterezés

Minden Azure Managed Redis-példány belsőleg van konfigurálva a fürtözés használatára minden szinten és termékváltozatban. Az Azure Managed Redis a Redis Enterprise-on alapul, amely csomópontonként több szegmenst is használhat. Ez a képesség kisebb példányokat is tartalmaz, amelyek csak egyetlen szegmens használatára vannak beállítva. A fürtözés lehetővé teszi a Redis instanciában lévő adatok felosztását a több Redis-folyamat között, más néven sharding. Az Azure Managed Redis három fürtszabályzatot kínál, amelyek meghatározzák, hogy melyik protokoll érhető el a Redis-ügyfelek számára a gyorsítótárpéldányhoz való csatlakozáshoz.

Klaszterszabályzatok

Az Azure Managed Redis három fürtszabályzatot kínál: OSS, Enterprise és Nem fürtözött. Az OSS-fürtözési szabályzat a legtöbb alkalmazás számára jó, mivel támogatja a nagyobb maximális átviteli sebességet, de mindegyik verziónak megvannak a maga előnyei és hátrányai.

• Ha alapszintű, standard vagy prémium szintű, nemclustered topológiáról szeretne áttérni, fontolja meg az OSS-fürtözés használatát a teljesítmény javítása érdekében. Csak akkor használjon nem külső szervezésű konfigurációkat, ha az alkalmazás nem támogatja az OSS vagy az Enterprise topológiákat. Az OSS-fürtkezelési szabályzat ugyanazt az API-t implementálja, mint a Redis nyílt forráskódú szoftverét. A Redis Cluster API lehetővé teszi, hogy a Redis-ügyfél közvetlenül csatlakozzon az egyes Redis-csomópontok szegmenseihez, minimalizálva a késést és optimalizálni a hálózati átviteli sebességet. Az átviteli sebesség a szegmensek és a vCPU-k számának növekedésével közel lineárisan skálázható. Az OSS-fürtözési szabályzat általában a legalacsonyabb késést és a legjobb átviteli sebességet biztosítja. Az OSS-fürtkezelési szabályzat azonban megköveteli, hogy az ügyfélkódtár támogassa a Redis Cluster API-t. Ma szinte minden Redis-ügyfél támogatja a Redis Cluster API-t, de a kompatibilitás problémát jelenthet a régebbi ügyfélverziók vagy speciális kódtárak esetében.

Nem használhatja az OSS-fürtkezelési szabályzatot a RediSearch modullal.

Az OSS-klaszterezési szabályzat megköveteli, hogy a kliens a megfelelő shardkapcsolatokat létesítse. A kezdeti kapcsolat az 10000-s porton keresztül történik. Az egyes csomópontokhoz való csatlakozás a 85XX tartományban lévő portokat használja. A 85xx portok idővel változhatnak, és nem szabad őket az alkalmazásba kódolni. A fürtözést támogató Redis kliensek a CLUSTER NODES paranccsal határozzák meg az elsődleges és replika adatdarabokhoz használt pontos portokat, és alakítják ki az adatdarabkapcsolatokat.

A vállalati klaszterezési szabályzat egy egyszerűbb konfiguráció, amely egyetlen végpontot használ minden ügyfélkapcsolathoz. A vállalati fürtkezelési szabályzat használatakor az összes kérést egyetlen, proxyként működő Redis-csomópontra irányítja. Ez a csomópont belsőleg irányítja a kérelmeket a fürt megfelelő csomópontjára. Ennek a megközelítésnek az az előnye, hogy az Azure Managed Redis a felhasználók számára nem fürtözöttnek tűnik. Ez azt jelenti, hogy a Redis ügyfélkódtáraknak nem kell támogatniuk a Redis-fürtözést a Redis Enterprise teljesítménybeli előnyeinek kihasználásához. Egyetlen végpont használata növeli a visszamenőleges kompatibilitást, és egyszerűbbé teszi a kapcsolatot. A hátránya az, hogy az egyetlen proxy csomópont szűk keresztmetszet lehet a számítási erőforrások kihasználtságában vagy a hálózati sávszélességben.

A Vállalati fürtkezelési szabályzat az egyetlen szabályzat, amely használható a RediSearch modullal. Bár az Enterprise-fürtözési szabályzat miatt az Azure Managed Redis-példány a felhasználók számára nem fürtözöttnek tűnik, a Multi-key parancsok esetén továbbra is vannak bizonyos korlátozások.

A nem fürtözött fürtözési szabályzat adatparticionálás nélkül tárolja az adatokat minden csomóponton. Csak a 25 GB-os és kisebb méretű gyorsítótárakra vonatkozik. A nem fürtözött csoportosítási szabály használatának lehetséges forgatókönyvei a következők:

• Nem shardolt Redis-környezetből való migráláskor. Például az Azure Cache for Redis alapszintű, standard és prémium termékváltozatainak nem horizontális topológiái.
• A pontközi parancsok széles körű futtatása és az adatok szegmensekre való felosztása hibákat okozhat. Például parancsok MULTI .
• Ha a Redist olyan üzenetközvetítőként használja, amely nem igényel horizontális skálázást.

A nem fürtözött fürtözési szabályzat használatának szempontjai a következők:

• Ez a szabályzat csak a 25 GB-nál kisebb vagy azzal egyenlő Azure Managed Redis-szintekre vonatkozik.
• Nem rendelkezik olyan teljesítménnyel, mint más fürtözési szabályzatok, mivel a CPU-k csak a Redis Enterprise szoftverrel képesek többszálas feldolgozásra, ha a gyorsítótár fel van darabolva.
• Ha fel szeretné skálázni az Azure Managed Redis gyorsítótárat, először módosítania kell a klaszterszabályzatot.
• Ha alapszintű, standard vagy prémium szintű, nemclustered topológiáról szeretne áttérni, fontolja meg az OSS-fürtkezelési szabályzat használatát a teljesítmény javítása érdekében. Csak akkor használjon nem külső szervezésű konfigurációkat, ha az alkalmazás nem támogatja az OSS vagy az Enterprise topológiákat.
• A nem fürtözött gyorsítótárak támogatják az aktív georeplikációt. A fürtözési szabályzat azonban nem módosítható a georeplikációt engedélyező gyorsítótárak létrehozása után. Ennek az az oka, hogy egy georeplikációs csoport összes példányának azonos fürtözési konfigurációval kell rendelkeznie a parancskonzisztencia hibáinak, például CROSSSLOT a hibáknak a elkerülése érdekében.

Csomópontok bővítése vagy hozzáadása

Az alapvető Redis Enterprise-szoftver nagyobb virtuális gépek használatával vertikálisan felskálázható, vagy további csomópontok vagy virtuális gépek hozzáadásával skálázható fel. Mindkét méretezési beállítás több memóriát, több vCPU-t és több szegmenst ad hozzá. Emiatt a redundancia miatt az Azure Managed Redis nem biztosítja az egyes konfigurációkban használt csomópontok meghatározott számának szabályozását. A megvalósítás részleteinek absztrakciója a keveredés, az összetettség és az optimálisnál rosszabb konfigurációk elkerülése érdekében történik. Ehelyett minden termékváltozat olyan csomópontkonfigurációval van kialakítva, amely maximalizálja a virtuális processzorokat és a memóriát. Az Azure Managed Redis egyes termékváltozatai két csomópontot használnak, míg mások többet.

Többkulcsos parancsok

Mivel az Azure Managed Redis-példányok fürtözött konfigurációt használnak, előfordulhatnak CROSSSLOT kivételek a több kulcsot kezelő parancsoknál. A viselkedés a használt klaszterezési szabályzattól függően változik. Ha az OSS-fürtkezelési szabályzatot használja, a többkulcsos parancsok összes kulcsának ugyanarra a hash helyre kell illeszkednie.

A nagyvállalati fürtözési szabályzattal kapcsolatos CROSSSLOT hibák is megjelenhetnek. Csak a következő többkulcsos parancsok engedélyezettek a slotok között vállalati klaszterezési szabályzat mellett: DEL, MSET, MGET, EXISTS, UNLINK és TOUCH.

Active-Active adatbázisokban a többkulcsos írási parancsok (DEL, MSET, ) UNLINKcsak ugyanazon a ponton lévő kulcsokon futtathatók. A következő többkulcsos parancsok azonban Active-Active adatbázisokban lévő pontokon engedélyezettek: MGET, EXISTSés TOUCH. További információ: Adatbázis-csoportosítás.

Shardolási konfiguráció

Az Azure Managed Redis minden SKU-ja adott számú Redis-kiszolgálófolyamatot futtat, amelyeket shardoknak hívnak. Az átviteli teljesítmény, a szilánkok száma és az egyes példányokon elérhető virtuális processzorok száma közötti kapcsolat összetett. A szegmensek száma manuálisan nem módosítható.

Egy adott memóriaméret esetén a memóriaoptimalizált verzióban a legkevesebb vCPU és szegmens található, míg a számításoptimalizált verzióé a legmagasabb.

A szegmensek számának növelése általában növeli a teljesítményt, mivel a Redis-műveletek párhuzamosan futhatnak. Ha azonban nem érhetők el vCPU-k a parancsok végrehajtásához, a teljesítmény csökkenhet.

A szegmensek úgy vannak leképezve, hogy optimalizálják az egyes vCPU-k használatát, miközben vCPU-ciklusokat foglalnak a Redis-kiszolgáló folyamatához, a felügyeleti ügynökhöz és az operációsrendszer-rendszer feladataihoz, amelyek szintén befolyásolják a teljesítményt. A létrehozott ügyfélalkalmazások úgy használják az Azure Managed Redist, mintha egyetlen logikai adatbázis lenne. A szolgáltatás kezeli az útválasztást a vCPU-k és töredékek között.

A termékváltozatban lévő szegmensek számának növeléséhez használjon egy nagyobb réteget az adott termékváltozatban. Az SKU-kat a teljesítmény igényeinek megfelelően is módosíthatja.

Az alábbi táblázat a vCPU-k és az elsődleges szegmensek arányát mutatja egy adott rétegméreten. Az oszlopokban lévő adatok nem garantálják, hogy ez a vCPU-k vagy szegmensek száma. A táblák csak illusztrációk.

Megjegyzés:

Az Azure Managed Redis az egyes termékváltozatokon használt szegmensek és vCPU-k számának módosításával optimalizálja a teljesítményt az idő függvényében.

Memóriaoptimalizált, kiegyensúlyozott és számításra optimalizált verziók

Ez a táblázat a Méret és a vCPU-k/elsődleges szegmensek közötti kapcsolat általános példáját mutatja be.

Szolgáltatási szintek	Memóriára optimalizált	Kiegyensúlyozott	Számításra optimalizált
Méret (GB)	vCPU-k/elsődleges szegmensek	vCPU-k/elsődleges szegmensek	vCPU-k/elsődleges szegmensek
24 ¹	4/2	8/6	16/12
60 ¹	8/6	16/12	32/24

¹ A vCPU-k és az elsődleges szegmensek aránya egy adott szintméretnél nem jelent garanciát az SKU-ra vagy a rétegre vonatkozóan.

Flash-optimalizált verzió

Ez a táblázat a Méret és a vCPU-k/elsődleges szegmensek közötti kapcsolat általános példáját mutatja be.

Szolgáltatási szintek	Flashre optimalizált
Méret (GB)	vCPU-k/elsődleges szegmensek
480 ¹	16/12
720 ¹	24/24

¹ A vCPU-k és az elsődleges szegmensek aránya egy adott szintméretnél nem jelent garanciát az SKU-ra vagy a rétegre vonatkozóan.

Fontos

A 350 GB-nál több tárhelyet használó összes memóriabeli szint előzetes verzióban érhető el, beleértve a Memóriaoptimalizált M500-as és újabb, a Kiegyensúlyozott B500-as és újabb, valamint a Számításoptimalizált X500-as és újabb szinteket. Ezek a szintek és magasabb szintek előzetes verzióban érhetők el.

Az A2000 és az A4500 flashoptimalizált szintjei előzetes verzióban érhetők el.

Futás magas rendelkezésre állási mód engedélyezése nélkül

A magas rendelkezésre állás (HA) mód engedélyezése nélkül is futtatható. Ez a konfiguráció azt jelenti, hogy a Redis-példány replikációja nincs engedélyezve, és nem rendelkezik hozzáféréssel a rendelkezésre állási SLA-hoz. Ne futtasson nem HA módban a fejlesztési és tesztelési forgatókönyveken kívül. Nem tilthatja le a magas rendelkezésre állást egy már létrehozott példányban. Engedélyezheti a magas rendelkezésre állást egy olyan példányban, amely nem rendelkezik vele. Mivel a magas rendelkezésre állás nélkül futó példányok kevesebb virtuális gépet és csomópontot használnak, a vCPU-k nem használhatók hatékonyan, így a teljesítmény alacsonyabb lehet.

Ha engedélyezi a HA módot, a példány az elsődleges és a replika szegmensekkel van üzembe helyezve, amelyek legalább két csomóponton oszlanak el. Ez a konfiguráció minden éles forgatókönyv esetében és a rendelkezésre állási SLA-hoz való hozzáféréshez ajánlott. A rendelkezésre állási zónákat támogató régiókban az Azure Managed Redis alapértelmezés szerint elosztja a csomópontokat zónák között. További információ: Megbízhatóság az Azure Managed Redisben.

Fenntartott memória

Minden Azure Managed Redis-példányon a rendelkezésre álló memória körülbelül 20%-a pufferként van fenntartva a nem biztonsági műveletekhez, például a feladatátvétel során történő replikációhoz és az aktív georeplikációs pufferhez. Ez a puffer segít a gyorsítótár teljesítményének javításában és a memória kiéhezésének megelőzésében.

Leskálázás

A leskálázás jelenleg nem támogatott az Azure Managed Redisben. További információ: Az Azure Managed Redis skálázásának korlátozásai.

Flash-optimalizált szint

A Flash-optimalizált szint az NVMe Flash-tárolót és a RAM-ot is használja. Mivel a flash tárolás alacsonyabb költségű, a Flash Optimalizált szint lehetővé teszi, hogy a teljesítmény egy részét feláldozza az árhatékonyság érdekében.

A Flash-optimalizált példányokon a gyorsítótárterület 20%-a RAM-on van, míg a másik 80% Flash-tárterületet használ. Az összes kulcs a RAM-on van tárolva, míg az értékek tárolhatók Flash Storage-ban vagy RAM-ban. A Redis szoftver intelligensen határozza meg az értékek helyét. A gyakran használt gyakori értékek ram-on vannak tárolva, míg a ritkábban használt hideg értékek a Flashen vannak tárolva. Az adatok olvasása vagy írása előtt át kell helyezni őket a RAM-ba, hogy aktív adatok legyenek.

Mivel a Redis a legjobb teljesítményre optimalizál, a példány először kitölti a rendelkezésre álló RAM-ot, mielőtt elemeket ad hozzá a Flash Storage-hoz. A RAM először feltöltése néhány következménnyel jár a teljesítményre nézve.

• Kisebb memóriahasználattal végzett tesztelés esetén jobb teljesítmény és kisebb késés fordulhat elő. A teljes gyorsítótár-példánnyal végzett tesztelés alacsonyabb teljesítményt eredményezhet, mivel a kevés memóriahasználat tesztelési fázisában csak RAM van használatban.
• Amikor több adatot ír a gyorsítótárba, a RAM-ban lévő adatok aránya a Flash Storage-hoz képest csökken, ami általában a késést és az átviteli teljesítményt is csökkenti.

A Flash-optimalizált szinthez jól illeszkedő számítási feladatok

A Flash Optimalizált szinten jól működő számítási feladatok gyakran a következő jellemzőkkel rendelkeznek:

• Az írási parancsokhoz viszonyítva magas olvasásiparancs-aránnyal rendelkező, olvasásintenzív munkaterhelések.
• Az Access a kulcsok egy részhalmazára összpontosított, amelyet sokkal gyakrabban használ, mint a többi adathalmaz.
• A kulcsnevekhez képest viszonylag nagy értékek. (Mivel a kulcsnevek mindig RAM-ban vannak tárolva, a nagy értékek szűk keresztmetszetet jelenthetnek a memória növekedéséhez.)

A Flash-optimalizált szinthez nem megfelelő számítási feladatok

Egyes számítási feladatok olyan hozzáférési jellemzőkkel rendelkeznek, amelyek kevésbé vannak optimalizálva a Flash-optimalizált szint kialakításához:

• Írásintenzív terhelések.
• Véletlenszerű vagy egységes adathozzáférési minták a legtöbb adathalmazban.
• Hosszú kulcsnevek viszonylag kis értékméretekkel.

Kapcsolódó tartalom

• Azure Managed Redis-példány skálázása