Mik az ajánlott eljárások a Nagyvállalati és nagyvállalati Flash-szintekhez
Az Alábbi ajánlott eljárások az Azure Cache for Redis Nagyvállalati és Enterprise Flash-szintjeinek használatakor ajánlottak.
Zónaredundancia
Határozottan javasoljuk, hogy új gyorsítótárakat helyezzen üzembe zónaredundáns konfigurációban. A zónaredundancia biztosítja, hogy a Redis Enterprise-csomópontok három rendelkezésre állási zóna között legyenek elosztva, ezzel növelve az adatközpontszintű kimaradások miatti redundanciát. A zónaredundancia használata növeli a rendelkezésre állást. További információ: Szolgáltatásiszint-szerződések (SLA) az online szolgáltatásokhoz.
A zónaredundancia fontos a vállalati szinten, mert a gyorsítótárpéldány mindig legalább három csomópontot használ. Két csomópont az adatokat tároló adatcsomópontok és egy kvórumcsomópont. A kapacitás növelése páros számú növekményben skálázza az adatcsomópontok számát.
Van egy másik, kvórumcsomópontnak nevezett csomópont is. Ez a csomópont figyeli az adatcsomópontokat, és automatikusan kiválasztja az új elsődleges csomópontot feladatátvétel esetén. A zónaredundancia biztosítja, hogy a csomópontok egyenletesen oszlanak el három rendelkezésre állási zónában, ezzel minimalizálva a kvórumvesztés lehetőségét. Az ügyfeleknek nem kell fizetnie a kvórumcsomópontért, és a zónaredundancia az zonális sávszélességgel kapcsolatos díjakon túl semmilyen más díjat nem számít fel.
Méretezés
Az Azure Cache for Redis Nagyvállalati és Nagyvállalati Flash szintjeiben javasoljuk a horizontális felskálázás rangsorolását. Rangsorolja a vertikális felskálázást, mert a vállalati szintek a Redis Enterprise-ra épülnek, amely több processzormagot képes használni nagyobb virtuális gépeken.
Ezzel szemben az ellenkező javaslat igaz a nyílt forráskódú Redisre épülő Alapszintű, Standard és Prémium szintekre. Ezekben a szintekben a horizontális felskálázás rangsorolása a legtöbb esetben ajánlott.
Horizontális skálázás és CPU-kihasználtság
Az Azure Cache for Redis alapszintű, standard és prémium szintjeiben a felhasznált virtuális PROCESSZORok (vCPU-k) számának meghatározása egyszerű. Minden Redis-csomópont dedikált virtuális gépen fut. A Redis-kiszolgáló folyamata egyszálas, és minden elsődleges és replikacsomóponton egy vCPU-t használ. A virtuális gépen lévő többi vCPU-t továbbra is más tevékenységekhez használják, például a munkafolyamat-koordinációt a különböző feladatokhoz, az állapotfigyelést és a TLS-terhelést.
Fürtözés használata esetén az effektus az adatok csomópontonként egy szegmenst tartalmazó több csomóponton való elterjesztése. A szegmensek számának növelésével lineárisan növeli a használt vCPU-k számát a fürt szegmenseinek száma alapján.
A Redis Enterprise viszont több vCPU-t is használhat magának a Redis-példánynak. Más szóval az Azure Cache for Redis összes szintje több vCPU-t is használhat háttér- és monitorozási feladatokhoz, de csak a Nagyvállalati és Vállalati Flash szintek képesek virtuális gépenként több vCPU-t használni a Redis-szegmensekhez. A táblázat az egyes termékváltozatokhoz és kapacitásokhoz (azaz a vertikális felskálázáshoz) használt tényleges vCPU-k számát mutatja.
A táblák az elsődleges szegmensekhez használt vCPU-k számát mutatják, nem a replika szegmenseit. A szegmensek nem képeznek egy-az-egyhez leképezést a vCPU-k számához. A táblák csak a vCPU-kat szemléltetik, szegmenseket nem. Egyes konfigurációk több szegmenst használnak, mint a rendelkezésre álló vCPU-k, hogy növeljék a teljesítményt bizonyos használati helyzetekben.
E5
| Kapacitás | Hatályos vCPU-k |
|---|---|
| 2 | 0 |
| 4 | 2 |
| 6 | 6 |
E10
| Kapacitás | Hatályos vCPU-k |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E20
| Kapacitás | Hatályos vCPU-k |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E50
| Kapacitás | Hatályos vCPU-k |
|---|---|
| 2 | 6 |
| 4 | 6 |
| 6 | 6 |
| 8 | 30 |
| 10 | 30 |
E100
| Kapacitás | Hatályos vCPU-k |
|---|---|
| 2 | 6 |
| 4 | 30 |
| 6 | 30 |
| 8 | 30 |
| 10 | 30 |
E200
| Kapacitás | Hatályos vCPU-k |
|---|---|
| 2 | 30 |
| 4 | 60 |
| 6 | 60 |
| 8 | 120 |
| 10 | 120 |
E400
| Kapacitás | Hatályos vCPU-k |
|---|---|
| 2 | 60 |
| 4 | 120 |
| 6 | 120 |
| 8 | 240 |
| 10 | 240 |
F300
| Kapacitás | Hatályos vCPU-k |
|---|---|
| 3 | 6 |
| 9 | 30 |
F700
| Kapacitás | Hatályos vCPU-k |
|---|---|
| 3 | 30 |
| 9 | 30 |
F1500
| Kapacitás | Hatályos vCPU-k |
|---|---|
| 3 | 30 |
| 9 | 90 |
Fürtözés nagyvállalati verzióban
A vállalati és az Enterprise Flash-szintek eredendően fürtözöttek, szemben az alapszintű, a standard és a prémium szinttel. A megvalósítás a kiválasztott fürtkezelési szabályzattól függ. A vállalati szintek két lehetőséget kínálnak a fürtkezelési szabályzathoz: az OSS-t és a Nagyvállalati verziót. Az OSS-fürtszabályzat a legtöbb alkalmazáshoz ajánlott, mivel támogatja a nagyobb maximális átviteli sebességet, de minden verziónak vannak előnyei és hátrányai.
Az OSS-fürtkezelési szabályzat ugyanazt a Redis Cluster API-t implementálja, mint a nyílt forráskódú Redis. A Redis Cluster API lehetővé teszi, hogy a Redis-ügyfél közvetlenül csatlakozzon az egyes Redis-csomópontokhoz, minimalizálva a késést és optimalizálni a hálózati átviteli sebességet. Ennek eredményeképpen a fürt több csomóponttal való horizontális felskálázása közel lineáris skálázhatóságot eredményez. Az OSS-fürtkezelési szabályzat általában a legjobb késést és átviteli teljesítményt nyújtja, de az ügyfélkódtárnak támogatnia kell a Redis-fürtözést. Az OSS-fürtözési szabályzat a RediSearch modullal sem használható.
A vállalati fürtözési szabályzat egy egyszerűbb konfiguráció, amely egyetlen végpontot használ az összes ügyfélkapcsolathoz. A Vállalati fürtözési házirend használatával az összes kérés egyetlen, proxyként használt Redis-csomópontra irányítja át a kéréseket a fürt megfelelő csomópontja felé. Ennek a megközelítésnek az az előnye, hogy a Redis-ügyfélkódtáraknak nem kell támogatniuk a Redis-fürtözést, hogy kihasználhassák a több csomópont előnyeit. Hátránya, hogy az egyetlen csomópontproxy szűk keresztmetszet lehet a számítási kihasználtság vagy a hálózati átviteli sebesség tekintetében. A Vállalati fürtkezelési szabályzat az egyetlen, amely használható a RediSearch modullal.
Többkulcsos parancsok
Mivel a vállalati szintek fürtözött konfigurációt használnak, a több kulcson működő parancsokon kivételeket láthat CROSSSLOT . A viselkedés a használt fürtkezelési szabályzattól függően változik. Ha az OSS-fürtözési szabályzatot használja, a többkulcsos parancsokhoz az összes kulcsot ugyanarra a kivonatolási pontra kell leképezni.
A nagyvállalati fürtözési szabályzattal kapcsolatos hibák is megjelenhetnek CROSSSLOT . Csak a következő többkulcsos parancsok engedélyezettek a nagyvállalati fürtözésű pontokon: DEL, MSET, , MGETEXISTS, UNLINKés TOUCH.
Az Active-Active-adatbázisokban a többkulcsos írási parancsok (DEL, MSET, UNLINK) csak ugyanazon a ponton lévő kulcsokon futtathatók. Az active-active adatbázisokban azonban a következő többkulcsos parancsok engedélyezettek: MGET, EXISTSés TOUCH. További információ: Adatbázis-fürtözés.
Vállalati flash – ajánlott eljárások
Az Enterprise Flash szint NVMe Flash-tárolót és RAM-ot is használ. Mivel a Flash Storage alacsonyabb költséggel jár, a Nagyvállalati Flash-szinttel csökkentheti a teljesítményt az árhatékonyság érdekében.
Nagyvállalati Flash-példányokon a gyorsítótárterület 20%-a RAM-on, míg a másik 80%- a Flash Storage-ot 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. Az értékek helyét a Redis szoftver intelligensen határozza meg. A ritkán elérhető "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 a RAM-ba, és "gyakori" adatokká kell válniuk.
Mivel a Redis a legjobb teljesítményt választja, a példány először kitölti a rendelkezésre álló RAM-ot, mielőtt elemeket ad hozzá a Flash Storage-hoz. Ennek néhány hatása van a teljesítményre:
- Alacsony memóriahasználattal végzett tesztelés esetén a teljesítmény és a késés jelentősen jobb lehet, mint a teljes gyorsítótár-példány esetén, mivel csak RAM van használatban.
- Amikor több adatot ír a gyorsítótárba, az adatok aránya a RAM-ban 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 Nagyvállalati Flash-szinthez jól illeszkedő számítási feladatok
Az Enterprise Flash-szinten valószínűleg jól működő számítási feladatok gyakran a következő jellemzőkkel rendelkeznek:
- Nagy olvasási igényű, magas olvasási parancsok arányával a parancsok írásához.
- Az Access a kulcsok egy részhalmazára összpontosít, amelyeket sokkal gyakrabban használnak, mint a többi adathalmaz.
- A kulcsnevekhez képest viszonylag nagy értékek. (Mivel a kulcsnevek mindig RAM-ban vannak tárolva, ez szűk keresztmetszetet jelenthet a memória növekedéséhez.)
Az Enterprise Flash-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-szint kialakításához:
- Nagy számítási feladatok írása.
- Véletlenszerű vagy egységes adathozzáférési paternák az adathalmaz nagy részén.
- Hosszú kulcsnevek viszonylag kis értékméretekkel.
Régiók leállási forgatókönyveinek kezelése aktív georeplikációs funkcióval
Az aktív georeplikálás hatékony funkció, amely jelentősen növeli a rendelkezésre állást az Azure Cache for Redis nagyvállalati szintjeinek használatakor. A gyorsítótárak regionális leállás esetén történő előkészítéséhez azonban lépéseket kell tennie.
Vegyük például az alábbi tippeket:
- Előre azonosíthatja, hogy a georeplikációs csoportban melyik másik gyorsítótár váltson át egy régió leállása esetén.
- Győződjön meg arról, hogy a tűzfalak úgy vannak beállítva, hogy minden alkalmazás és ügyfél hozzáférhessen az azonosított biztonsági mentési gyorsítótárhoz.
- A georeplikációs csoport minden gyorsítótára saját hozzáférési kulccsal rendelkezik. Annak meghatározása, hogy az alkalmazás hogyan vált különböző hozzáférési kulcsra a biztonsági mentési gyorsítótár megcélzásakor.
- Ha a georeplikációs csoportban lévő gyorsítótár leáll, a metaadatok összeállítása a georeplikációs csoport összes gyorsítótárában megkezdődik. A metaadatok nem vethetők el, amíg az írások újra nem szinkronizálhatók az összes gyorsítótárba. A metaadatok összeállítását úgy akadályozhatja meg, ha kényszeríti a gyorsítótár leválasztását . Fontolja meg a gyorsítótárban rendelkezésre álló memória figyelését és a kapcsolat megszüntetését, ha memóriaterhelés van, különösen az írási terhelésű számítási feladatok esetében.
Az áramkör-megszakító minta is használható. A mintával automatikusan átirányíthatja a forgalmat egy régiókimaradást tapasztaló gyorsítótárból, és egy biztonsági mentési gyorsítótár felé ugyanabban a georeplikációs csoportban. Az átirányítás engedélyezéséhez használja az Azure-szolgáltatásokat, például az Azure Traffic Managert vagy az Azure Load Balancert .
Adatmegőrzés és adatmentés
A Nagyvállalati és Nagyvállalati Flash-szintek adatmegőrzési funkciója úgy lett kialakítva, hogy automatikusan gyors helyreállítási pontot biztosítson az adatokhoz, amikor a gyorsítótár leáll. A gyors helyreállítás lehetővé teszi az RDB- vagy AOF-fájl tárolását egy felügyelt lemezen, amely a gyorsítótárpéldányhoz van csatlakoztatva. A lemezen lévő adatmegőrzési fájlok nem érhetők el a felhasználók számára.
Sok ügyfél szeretne a gyorsítótárban lévő adatok rendszeres biztonsági mentéséhez adatmegőrzést használni. Nem javasoljuk, hogy ilyen módon használja az adatmegőrzést. Ehelyett használja az importálási/exportálási funkciót. A gyorsítótáradatok másolatait RDB formátumban exportálhatja közvetlenül a választott tárfiókba, és igény szerint aktiválhatja az adatexportálást. Az exportálás aktiválható a portálról, vagy a parancssori felület, a PowerShell vagy az SDK eszközeivel.