Redis Sentinel-High Availability: minden, amit tudni kell a DEV-től a PROD – ig: teljes útmutató

mit jelent valójában a ‘Redis’ kifejezés?

távoli Szótárkiszolgálót jelent.

rendben! Rengeteg különböző Redis cikkek odakinn, de szerettem volna megosztani a tapasztalataimat, mint a fejlesztő Redis létrehozásával “minden egy megfelelő cikket”, amely a legfontosabb és legfontosabb dolog, ami szükséges és hasznos a fejlesztő vagy a devops mérnök, hogy építsenek egy nagyon Elérhető Redis klaszter Sentinel.

Tehát kezdjük el…

a Redis, amely egy nyílt forráskódú memória adatstruktúra-áruház, nagyon népszerű választás a gyorsítótárazási célokra használt fejlesztők körében, üzenetközvetítőként, és főleg NoSQL kulcs-érték adatbázisként használják különböző felhasználási esetekhez.

ebben a bejegyzésben kifejezetten megvitatom és bemutatom a Redis – t, valamint a Master/Slave replikációt, a magas rendelkezésre állást (Redis Sentinel), az automatikus feladatátvételt, néhány termelési szint optimalizálási tippet és megfigyelési szempontokat. Ezen kívül ezekkel a témákkal együtt megemlítem azokat a problémákat és hibákat, amelyekkel a Redis Sentinel Ubuntuval történő végrehajtása során szembesültem. Az alábbiakban az operációs rendszer verziója és a Redis verzió részletei láthatók.

OS version: Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-119-generic x86_64)
Redis Version: 4.0.9

ezenkívül szeretném kiemelni, hogy a Redis dokumentáció nagyon informatív, és ez a ‘go to place’, ha további tisztázásra van szüksége a Redisről.

Továbblépés a Redis basics oldalra; a Redis egy memórián belüli adatbázis, ami egyszerűen azt jelenti, hogy a Redis RAM-on fut. Azt is tudnia kell, hogy a Redis számos adatstruktúrát támogat, például karakterláncokat, hash-eket, listákat, készleteket, rendezett készleteket tartomány lekérdezésekkel, bitképekkel. Ezenkívül támogatja az olyan atomi műveleteket is, mint például egy karakterlánc hozzáfűzése, az érték növelése a hash-ban, egy elem listára tolása stb.

nos, kezdjük el a dolgokat a Redis High Availability-vel.

a Redis sentinel a Redis által kínált magas rendelkezésre állású megoldás. A Redis fürt meghibásodása esetén a Sentinel automatikusan felismeri a meghibásodási pontot, és emberi beavatkozás nélkül visszaállítja a fürtöt stabil üzemmódba.

mi történik valójában a Redis Sentinel belsejében ?

a Sentinel mindig ellenőrzi a Redis fürt MASTER és SLAVE példányait, ellenőrizve, hogy a várt módon működnek-e. Ha a Sentinel hibát észlel egy adott fürt fő csomópontjában, a Sentinel megkezdi a feladatátvételi folyamatot. Ennek eredményeként a Sentinel kiválaszt egy SLAVE példányt, és előlépteti azt mesterré. Végül a többi megmaradt SZOLGAPÉLDÁNY automatikusan újrakonfigurálódik az új MESTERPÉLDÁNY használatához.

a Sentinel konfigurációs szolgáltatóként vagy jogosultsági forrásként működik az ügyfelek szolgáltatáskeresésében.

mit jelent ez ? Egyszerűen, az alkalmazás kliensek csatlakoznak a Sentinelekhez, és a Sentinelek megadják nekik a legújabb Redis MASTER címet.

ezenkívül a Sentinel egy robusztus elosztott rendszer, ahol több sentinelnek meg kell egyeznie azzal a ténnyel, hogy egy adott mester már nem érhető el. Ezután csak a feladatátvételi folyamat indul egy válasszon egy új mester csomópont. Ez a sentinel megállapodás a kvórum értékének megfelelően történik.

mi a határozatképesség ?

a kvórumérték azoknak az Őrszemeknek a száma, akiknek meg kell állapodniuk arról, hogy a mester nem érhető el. A határozatképességet azonban csak a hiba észlelésére használják. Annak érdekében, hogy ténylegesen elvégezzék a feladatátvételt, az egyik őrszemnek meg kell választania a feladatátvétel vezetőjét, és felhatalmazást kell kapnia a folytatásra. Ez csak a Sentinel folyamatok többségének szavazatával történik.

piszkoljuk be a kezünket a Redis Sentinellel.

ragaszkodunk az alapbeállításhoz 3 szerverpéldánnyal.

kérjük, olvassa el a fenti ábrát, amely a 3 szerverpéldány alapbeállítását szemlélteti. Először is ellenőrizze, hogy az Ubuntu példányai naprakészek-e a releváns építési függőségekkel. Néha, lehet, hogy szüksége van jemallocra is. Az alábbiakban bemutatjuk a Redis telepítésének lépéseit a kiszolgálópéldányokra.

sudo apt-get update 
sudo apt-get install build-essential tcl
sudo apt-get install libjemalloc-dev (Optional)curl -O http://download.redis.io/redis-stable.tar.gz
tar xzvf redis-stable.tar.gz
cd redis-stable
make
make test
sudo make install

most a redis könyvtárban mindkét Redist látnia kell.conf és sentinel.conf konfigurációs fájlok.

a Redis futtatása előtt hajtsunk végre néhány szükséges alapkonfigurációt a Redis klaszter futtatásához. Az alábbiakban bemutatjuk ennek a beállításnak az IP-címeit.

10.52.209.46 (Initial Master Node)
10.52.209.47 (Initial Slave Node)
10.52.209.49 (Initial Slave Node)

a Redis server alapértelmezett portja 6379, a Sentinel pedig 26379. Ezért győződjön meg róla, hogy megnyitja ezeket a portokat,

sudo ufw allow 6379
sudo ufw allow 26379

a Redis konfigurációk (mindkettő redis-ben.conf és sentinel.conf) a fenti szervereket a következőképpen kell konfigurálni.

az alapbeállításhoz a fenti konfigurációk elegendőek lesznek, de a termelési szinthez kérjük, vegye figyelembe a bejegyzés második részében említett tippeket. Az egyetlen különbség redis.conf fájlokat 3 szerverek, hogy az összes rabszolgák kell a következő config. 10.52.209.46 a mester IP-cím.

slaveof 10.52.209.46 6379

a slaveof azt mondja a Redis clusternek, hogy ezt az adott szerverpéldányt az adott fő csomópont SLAVE példányaként készítse el (10.52.209.46).

a sentinelben.conf, következő config értesíti Sentinel kezdeni a fürt monitoring következő kezdeti beállításokat. Ezt követően ez a Konfigurációs beállítás automatikusan frissül ennek megfelelően.

sentinel monitor mymaster 10.52.209.46 6379 2
(This tells sentinel to monitor the master node. And the last argument which is 2 is the quorum value)

további, sentinel.a conf a következő konfigurációs értékeket is tartalmazza.

sentinel down-after-milliseconds mymaster 5000
(Means server will unresponsive for 5 seconds before being classified as +down and consequently activating a +vote to elect a new master node.)sentinel failover-timeout mymaster 10000
(Specifies the failover timeout in milliseconds.)

Okie Dokie! Most pedig … futtassuk le Redist.

a Redis futtatásának számos módja van. Ebben a demóban ragaszkodni fogok a következő parancshoz.

(Go to src folder.)
cd src/ && redis-server ../redis.conf &
cd src/ && redis-server ../sentinel.conf — sentinel &(Or else you can simply use cd utils && ./install_server.sh.)

Ezután egyszerűen ellenőrizheti a Redis folyamatokat a ps-ef | grep redis paranccsal. Minden szerverpéldánynak futnia kell mind a Redis folyamat, mind a Sentinel folyamat. Ha minden a tervhez megy, akkor 2 folyamatnak kell futnia az alábbiak szerint.

most csatlakozzon a Redis klienshez az alábbi parancs egyikével, és ellenőrizze, hogy a Redis jól működik-e.

redis-cli ping
or
redis-cli -h IP_Address pingYou should get a output of PONG.

félelmetes! Most már Redis is működik. Koncentráljunk a Master / Slave replikációra.

Master/Slave replikáció

most, ha ellenőrzi a redis-t.napló (amely a redis-ben meghatározott helyen található.conf) az egyes példányok, akkor kap, hogy a Master — Slave szinkronizálás történt.

fő csomópont — redis.napló

Rabszolga csomópont-redis.napló

replikációs állapot ellenőrzése

a replikációs információkat a Redis CLI info replikációs parancsán keresztül is ellenőrizheti. A szerep attribútum alatt megemlíti, hogy az adott csomópont mester vagy szolga (sárga doboz).ezenkívül a fő csomópontban megjeleníti az összes csatlakoztatott Rabszolga részleteit. (zöld doboz)

most nézzük meg, mi sentinel.napló jelzi. (amely a sentinelben meghatározott helyen található.conf)

Továbbá, ha ellenőrzi a sentinel.conf fájl, láthatja, hogy a conf fájl automatikusan frissül a legújabb konfigurációkkal, beleértve a Sentinel knowled-slave és a sentinel knowled-sentinel értékeket.

király! Most hozzunk létre egy minta értéket az összes csomópontban.

127.0.0.1:6739> set demokey "Amila"

amint az a fenti ábrán látható, a rabszolgák csak olvashatók, ezért csak adatokat írhat a mesterhez. Mivel a Redis aszinkron módon replikálódik az összes többi rabszolgával, a beszúrt értéket bármelyik Redis rabszolgából lekérheti ugyanazzal a kulccsal. Ezen kívül via,KEYS* felsorolhatja az összes behelyezett kulcsot. A fenti ábra világosan leírja, miről beszéltünk.

most nézzük meg, hogyan működik a Redis Sentinel automatikus feladatátvétel.

Redis Sentinel Automatikus Feladatátvétel

Okiee! Szimuláljunk egy automatikus feladatátvételi forgatókönyvet. A feladatátvételi forgatókönyv szimulálásához egyszerűen leállíthatja a Redis szervert, vagy megölheti a Redis folyamatot a FŐPÉLDÁNYBAN. Még akkor is aludni a Redis folyamat is. Választhat, amit csak akar.

kill -9 <process id>
or
redis-cli -p 6379 DEBUG sleep 30
or
redis-cli -p 6379 DEBUG SEGFAULT

amint azt a fenti ábra szemlélteti, feladatátvétel esetén, ha a fő csomópont meghibásodik, akkor a fennmaradó 2 őrszem határozza meg a feladatátvételt, és ha mindkettő egyetért (mivel a határozatképesség értéke 2), akkor a fennmaradó 2 csomópont közül új mestert választanak.

az alábbiakban a feladatátvételi forgatókönyv naplófarkja látható.

redis.Slave csomópontok naplója.

őrszem.Slave csomópontok naplója

most ellenőrizzük a replikáció állapotát az info replikációs paranccsal.

a log farok további kidolgozása,

minden Sentinel észleli, hogy a mester +sdown eseménnyel van Lent. (+sdown azt jelenti, hogy a megadott példány szubjektíven lefelé van.)

+új korszak azt jelenti, hogy az aktuális korszak frissült.

+sdown esemény később eszkalálódik +odown, ami azt jelenti, hogy több őrszem egyetért abban, hogy a mester nem érhető el. (+odown azt jelenti, hogy a megadott példány most objektíven Le állapotban van.)

Sentinels +szavazzon egy Sentinelre, amely elindítja az első feladatátvételi kísérletet.

a feladatátvétel megtörténik.

további, következő mutatja upstart munkahelyek.

felfelé a Redis számára

description "Redis Server"start on runlevel 
stop on runlevel script
echo $$ > /var/run/redis.pid
su - amila -c "cd /home/amila/redis-stable/src/; redis-server ../redis.conf"
end scriptpost-stop script
rm -f /var/run/redis.pid
end script

felfelé a Sentinel számára

description "Redis Sentinel Server"start on runlevel 
stop on runlevel script
echo $$ > /var/run/redis.pid
su - amila -c "cd /home/amila/redis-stable/src/; redis-server ../sentinel.conf --sentinel"
end scriptpost-stop script
rm -f /var/run/redis.pid
end script

gratulálok! Egyszerűen ennyi. Így kezeli a Redis a magas rendelkezésre állást és az automatikus feladatátvételt. Most vessünk egy pillantást néhány érdekes Redis tényeket, mielőtt ugrik be, hogy optimalizálja a tippeket és trükköket.

érdekes tények a Redisről.

a Redis legfeljebb 2 32 kulcsot képes kezelni, és a gyakorlatban tesztelték, hogy példányonként legalább 250 millió kulcsot kezeljen.

egy üres példány ~ 3 MB memóriát használ.

1 millió kis kulcs -> karakterláncérték-Párok ~ 85 MB memóriát használnak.

1 millió kulcs -> Hash érték, amely 5 mezővel rendelkező objektumot képvisel, ~ 160 MB memóriát használ.

Redis egyszálú. Hogyan használhatok ki több CPU / magot?

nem túl gyakori, hogy a CPU a Redis szűk keresztmetszetévé válik, mivel általában a Redis vagy memória, vagy hálózat kötött. Ebben az esetben a Redis példányok vízszintes vagy függőleges méretezése segít csökkenteni a CPU-val kapcsolatos szűk keresztmetszeteket.

a Redis egy memóriában lévő, de állandó lemezadatbázis.

Redis Perzisztencia – > RDB : point-in-time Pillanatképek az adatkészlet meghatározott időközönként. (Data backup) / AOF: naplózza a szerver által kapott minden írási műveletet. (Tartósabb)

ha Java-t használ, használhatja a Jedis-t, amely egy java kliens, hogy összekapcsolja a Java alkalmazást a Redis-szel. Megjegyzés: a Jedis az Apache Commons Pool-t használja a kapcsolat egyesítéséhez (GenericObjectPool). A single Jedis instance is not threadsafe! ezen problémák elkerülése érdekében használja a jedispoolot, amely a hálózati kapcsolatok threadsafe készlete. Alapértelmezett Max kapcsolat medence mérete 8.

most összpontosítsunk a felmerülő problémákra/hibákra, valamint néhány termelési teljesítmény-optimalizálási tippre és trükkre a Redis számára.

problémák/hiba, hogy lehet kapni & termelési teljesítmény optimalizálása tippek és trükkök

először is, a redis.conf és sentinel.conf, az összes konfiguráció sorrendben van, ezért ne zavarja a sorrendet. Ellenkező esetben konfigurációs hibákat kap, mint például a következők.

*** FATAL CONFIG FILE ERROR ***
Reading the configuration file, at line 98
>>> 'sentinel down-after-milliseconds mymaster 5000'
No such master with specified name.

biztonsági szempontból állítson be egy jelszót a hitelesítéshez a mesterrel és a rabszolgákkal. Ehhez könnyen megváltoztathatja a redis-t.conf és sentinel.conf ennek megfelelően a következő config értéket.

In sentinel.conf
sentinel auth-pass <master-name> <password>In redis.conf
masterauth <master-password>

győződjön meg arról, hogy a TCP backlog beállítás (Max kapcsolatok) 511. Ezt az értéket ennek megfelelően állíthatja be (figyelembe véve a szerver specifikációját) a következő lépésekkel.

sudo nano /etc/rc.local
Add this:
sysctl -w net.core.somaxconn=65535When you reboot the next time, the new setting will be to allow 65535 connections instead of 128 as before. When you add the line to rc.local make sure it's before the exit 0.

néhány figyelmeztetés, hogy lehet, hogy találkoznak a redis.napló lehet,

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.You can add this via following command as well as using a cat command you can makesure whether the value is set properly.echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
cat /etc/sysctl.conf

lehet, hogy le kell tiltania a THP-t vagy az Átlátszó hatalmas oldalt.

WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.Fixsudo nano /etc/rc.local
echo never > /sys/kernel/mm/transparent_hugepage/enabled

a UNIX socket használata a 6379-es TCP port helyett szintén hozzájárul a Redis teljesítménynövekedéséhez.

ennek elérése érdekében, redis.conf kell változtatni a következő beállítást.

unixsocket /var/run/redis.sock
unixsocketperm 777# Accept connections on the specified port, default is 6379.
# If port 0 is specified Redis will not listen on a TCP socket.
port 0

ezenkívül a Felhasználási esettől függően konfigurálhatja a Redis perzisztencia opciót is.

ha szeretné, letilthatja perzisztencia egyáltalán, ha azt szeretné, hogy az adatok csak létezik, amíg a szerver fut. Megjegyzés: letilthatja az RDB perzisztenciát, ha kommentálja az összes “mentés” sort a redis-ben.conf az alábbiak szerint.

Comment out these 3 values in redis.conf
save 900 1
save 300 10
save 60 10000rdbcompression no
rdbchecksum no

az AoF persistance (csak Fájl hozzáfűzése) alapértelmezés szerint le van tiltva a redis-ben.conf.

appendonly no

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Monitoring Redis

Monitoring szempontból számos eszköz létezik a Redis monitorozására. NewRelic nyújt előre képességek figyelemmel kíséri és elemzi Redis beleértve a” legtöbb időt fogyasztott db műveletek”,” műveletek áteresztőképesség”,” műveletek lekérdezési idő ” és stb.

További információ A New Relic Redisről itt található. Továbbá, Redis-stat is egy jó nyílt forráskódú Redis monitoring eszköz.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

AWS ElasticCache

az AWS memórián belüli gyorsítótár-felhőszolgáltatást is kínál “ElastiCache” néven, amelyhez a Redis is tartozik. Hatékony, könnyen használható felhőszolgáltatásként határozható meg, amely a legtöbb kézi konfigurációt és adminisztrációs feladatot tehermentesíti.

az ElastiCache egy olyan webes szolgáltatás, amely megkönnyíti az elosztott memória-gyorsítótár elindítását, kezelését és méretezését a felhőben.

érdekes, hogy a hajók mesés fejlett funkciók, mint a klaszter mód sharding belül néhány kattintással, Multi-Az automatikus feladatátvétel, titkosítás nyugalmi, titkosítás tranzit, Import RDB fájlt S3, lehetővé teszi az automatikus mentést, és még sok más.

legmenőbb jellemzője AWS ElastichCache, hogy kínál egy átfogó monitoring műszerfal a Redis klaszter, beleértve a felügyeleti szempontok, mint a CPU/memória kihasználtság (Swap és szabad memória), Kapcsolat száma, elem száma, kilakoltatások, String;kulcs;Hash alapú parancs száma, replikáció lag és még sok más.

Nos … ez nagyjából ez a poszt!

mint a bejegyzés elején említettem, rengeteg különböző Redis cikk létezik, de szerettem volna létrehozni egy “mindent egy megfelelő cikkben”, amely a legfontosabb tényeket és tippeket tartalmazza, amelyek szükségesek és hasznosak egy fejlesztő vagy egy devops mérnök számára, hogy egy nagyon Elérhető Redis klasztert építsenek a Sentinel segítségével.

mielőtt befejeztem ezt a bejegyzést, az egyik érdekes cikk, amelyet találtam, az volt, hogy a Flickr hogyan valósította meg a Redis Sentinelt. Kérjük, ellenőrizze azt a bejegyzést is.

oké. Szóval nagyon köszönöm, hogy elolvastad ezt a cikket, és alig várom, hogy jöjjön fel egy másik érdekes cikket hamarosan, megosztom tapasztalataimat, mint a fejlesztő. Addig is, egészségünkre! Boldog kódolás!