Megosztás a következőn keresztül:

Átállás és frissítés az Azure Cache for Redishez

  • A következőre érvényes:: ✅ Azure Cache for Redis

Fontos

Az Azure Cache for Redis bejelentette az összes termékváltozat kivonási ütemtervét. Javasoljuk, hogy a meglévő Azure Cache for Redis-példányokat mihamarabb áthelyezhesse az Azure Managed Redisbe .

További részletek a nyugdíjba vonulásról:

A rugalmas és sikeres ügyfélalkalmazások létrehozásához kritikus fontosságú megérteni a feladatátvételt az Azure Cache for Redis szolgáltatásban. A feladatátvétel a tervezett felügyeleti műveletek része lehet, vagy nem tervezett hardver- vagy hálózati hibák okozhatják. A gyorsítótár feladatátvételét gyakran alkalmazzák, amikor a felügyeleti szolgáltatás frissíti az Azure Cache for Redis bináris fájljait.

Ebben a cikkben a következő információkat találja:

  • Mi az a feladatátvétel?
  • Hogyan történik a feladatátvétel a javítás során.
  • Rugalmas ügyfélalkalmazás létrehozása.

Mi az a feladatátvétel?

Kezdjük az Azure Cache for Redis feladatátvételének áttekintésével.

A gyorsítótárarchitektúra gyors összefoglalása

A gyorsítótár több, különálló és privát IP-címmel rendelkező virtuális gépből áll. Minden virtuális gép, más néven csomópont egy megosztott terheléselosztóhoz csatlakozik egyetlen virtuális IP-címmel. Minden csomópont futtatja a Redis-kiszolgáló folyamatát, és hostnév és a Redis-portok használatával érhető el. Minden csomópont elsődlegesnek vagy replikacsomópontnak minősül. Amikor egy ügyfélalkalmazás csatlakozik egy gyorsítótárhoz, a forgalom ezen a terheléselosztón halad át, és automatikusan az elsődleges csomópontra irányítja.

Az alapszintű gyorsítótárban az egyetlen csomópont mindig elsődleges. A standard vagy prémium szintű gyorsítótárban két csomópont található: az egyik elsődleges, a másik a replika. Mivel a standard és a prémium szintű gyorsítótárak több csomópontot is használnak, előfordulhat, hogy az egyik csomópont nem érhető el, míg a másik folytatja a kérések feldolgozását. A klaszterezett gyorsítótárak számos szegmensből állnak, minden szegmens különálló elsődleges és replikacsomópontokkal rendelkezik. Előfordulhat, hogy az egyik szegmens le van omlva, míg a többi elérhető marad.

Megjegyzés:

Az alapszintű gyorsítótárak nem rendelkeznek több csomóponttal, és nem kínálnak szolgáltatásiszint-szerződést (SLA) a rendelkezésre állásához. Az alapszintű gyorsítótárak csak fejlesztési és tesztelési célokra ajánlottak. A rendelkezésre állás növeléséhez használjon standard vagy prémium szintű gyorsítótárat többcsomópontos üzembe helyezéshez.

Átkapcsolás magyarázata

Feladatátvétel akkor történik, ha egy replikacsomópont előlépteti magát elsődleges csomóponttá, és a régi elsődleges csomópont bezárja a meglévő kapcsolatokat. Miután az elsődleges csomópont újra működőképes lesz, észreveszi a szerepkörök változását, és lefokozza magát replikává. Ezután csatlakozik az új elsődlegeshez, és szinkronizálja az adatokat. Az átállás lehet tervezett vagy nem tervezett.

A tervezett feladatátvétel két különböző időpontban történik:

  • Rendszerfrissítések, például Redis-javítások vagy operációsrendszer-frissítések.
  • Felügyeleti műveletek, például skálázás és újraindítás.

Mivel a csomópontok előzetes értesítést kapnak a frissítésről, együttműködve felcserélhetik a szerepköröket, és gyorsan frissíthetik a változás terheléselosztóját. A tervezett feladatátvétel általában kevesebb mint 1 másodperc alatt fejeződik be.

Nem tervezett feladatátvétel történhet hardverhiba, hálózati hiba vagy az elsődleges csomópont egyéb váratlan leállása miatt. A replikacsomópont előlépteti magát elsődlegesként, de a folyamat tovább tart. A replikacsomópontnak először észlelnie kell, hogy az elsődleges csomópont nem érhető el, mielőtt elindíthatja a feladatátvételi folyamatot. A felesleges feladatátvétel elkerülése érdekében a replikacsomópontnak azt is ellenőriznie kell, hogy ez a nem tervezett hiba nem átmeneti vagy helyi-e. Az észlelés késlekedése azt eredményezi, hogy a nem tervezett feladatátvétel általában 10-15 másodpercen belül befejeződik.

Hogyan történik a javítás?

Az Azure Cache for Redis szolgáltatás rendszeresen frissíti a gyorsítótárat a legújabb platformfunkciókkal és javításokkal. A gyorsítótár javításához a szolgáltatás az alábbi lépéseket követi:

  1. A szolgáltatás először kijavítja a replikacsomópontot.
  2. A javított replika kooperatív módon előtérbe helyezi magát fő példányként. Ez az előléptetés tervezett feladatátvételnek minősül.
  3. A korábbi elsődleges csomópont újraindul az új módosítások elfogadása érdekében, és replikacsomópontként lép működésbe.
  4. A replikacsomópont csatlakozik az elsődleges csomóponthoz, és szinkronizálja az adatokat.
  5. Ha az adatszinkronizálás befejeződött, a javítási folyamat megismétli a többi csomópontot.

Mivel a javítás egy tervezett átfedési folyamat, a replikacsomópont gyorsan előlépteti magát elsődlegessé. Ezután a csomópont megkezdi a karbantartási kérelmeket és az új kapcsolatokat. Az alapszintű gyorsítótárak nem rendelkeznek replikacsomópontokkal, és a frissítés befejezéséig nem érhetők el. A fürtözött gyorsítótár egyes szegmensei külön-külön lesznek javítva, és nem zárják be a kapcsolatokat egy másik szegmenshez.

Fontos

A csomópontok egyenként vannak javítva az adatvesztés megakadályozása érdekében. Az alapszintű gyorsítótárak adatvesztéssel járnak. A fürtözött gyorsítótárakat egy szegmensenként javítják.

Az ugyanabban az erőforráscsoportban és régióban található gyorsítótárak is egyenként vannak javítva. A különböző erőforráscsoportokban vagy régiókban található gyorsítótárak egyidejűleg frissítésre kerülhetnek.

Mivel a teljes adatszinkronizálás a folyamat megismétlése előtt történik, az adatvesztés nem valószínű, ha standard vagy prémium szintű gyorsítótárat használ. Az adatok exportálásával és az adatmegőrzés engedélyezésével tovább védheti az adatvesztést.

További gyorsítótárbetöltés

Amikor feladatátvétel történik, a Standard és a Premium gyorsítótáraknak adatokat kell replikálnia az egyik csomópontról a másikra. Ez a replikáció némi terhelésnövekedést okoz mind a kiszolgáló memóriájában, mind a CPU-ban. Ha a gyorsítótárpéldány már erősen betöltődött, az ügyfélalkalmazások nagyobb késést tapasztalhatnak. Szélsőséges esetekben előfordulhat, hogy az ügyfélalkalmazások időtúllépési kivételeket kapnak. A nagyobb terhelés hatásának csökkentése érdekében konfigurálja a gyorsítótár beállítását maxmemory-reserved .

Hogyan befolyásolja a feladatátvétel az ügyfélalkalmazásomat?

Az ügyfélalkalmazások hibákat kaphatnak az Azure Cache For Redistől. Az ügyfélalkalmazás által észlelt hibák száma attól függ, hogy hány művelet volt függőben a kapcsolaton a feladatátvétel időpontjában. A lezárt kapcsolatokkal rendelkező csomóponton keresztül irányított bármely kapcsolat hibákat tapasztal.

Számos ügyfélkódtár különböző típusú hibákat okozhat a kapcsolatok megszakadásakor, például:

  • Időtúllépési kivételek
  • Hálózati kivételek
  • Socket kivételek

A kivételek száma és típusa attól függ, hogy a kérés hol található a kód elérési útján, amikor a gyorsítótár bezárja a kapcsolatokat. Előfordulhat például, hogy egy olyan művelet, amely kérést küld, de nem kapott választ a feladatátvétel során, időtúllépési kivételt kaphat. A bezárt kapcsolatobjektum új kérései kapcsolati kivételeket kapnak, amíg az újracsatlakozás sikeresen meg nem történik.

A legtöbb ügyfélkönyvtár megpróbál újracsatlakozni a gyorsítótárhoz, ha erre van beállítva. Az előre nem látható hibák azonban időnként helyreállíthatatlan állapotba helyezhetik a tárobjektumokat. Ha a hibák hosszabb ideig maradnak fenn, mint egy előre konfigurált időtartam, a kapcsolatobjektumot újra létre kell hozni. A Microsoft.NET és más objektumorientált nyelvekben a kapcsolat újrakezdése az alkalmazás újraindítása nélkül is elvégezhető Egy ForceReconnect-minta használatával.

Értesítést kaphatok a karbantartás előtt?

Az Azure Cache for Redis a futásidejű karbantartási értesítéseket egy közzétételi/előfizetési (pub/sub) csatornán teszi AzureRedisEventsközzé. Számos népszerű Redis klienskönyvtár támogatja a közzétételi/feliratkozási csatornákra való feliratkozást. Az értesítések fogadása a AzureRedisEvents csatornáról általában az ügyfélalkalmazás egyszerű kiegészítése. További információ a karbantartási eseményekről: AzureRedisEvents.

Megjegyzés:

A AzureRedisEvents csatorna nem olyan mechanizmus, amely napokat vagy órákat előre tud értesíteni. A csatorna értesítheti az ügyfeleket minden olyan közelgő kiszolgálókarbantartási eseményről, amely befolyásolhatja a kiszolgáló rendelkezésre állását. AzureRedisEvents csak alapszintű, standard és prémium szintű szintekhez érhető el.

Milyen frissítéseket tartalmaz a karbantartás?

A karbantartás a következő frissítéseket tartalmazza:

  • Redis Server-frissítések: A Redis-kiszolgáló bináris fájljainak bármilyen frissítése vagy javítása.
  • Virtuális gép (VM) frissítései: A Redis szolgáltatást üzemeltető virtuális gép minden frissítése. A virtuális gépek frissítései közé tartozik a szoftverösszetevők javítása az üzemeltetési környezetben a hálózati összetevők frissítése vagy a leszerelés érdekében.

Megjelenik a karbantartás az Azure Portal szolgáltatásállapotában javítás előtt?

Nem, a karbantartás nem jelenik meg sehol a portál szolgáltatásállapotában vagy más helyen.

Mennyi ideig kaphatom meg az értesítést a tervezett karbantartás előtt?

Amikor a AzureRedisEvents csatornát használja, 15 perccel a karbantartás előtt értesítést kap.

Ügyfél hálózatkonfigurációjának változásai

Bizonyos ügyféloldali hálózatkonfigurációs módosítások kapcsolati hibákat válthatnak ki. Ilyen módosítások lehetnek a következők:

  • Az ügyfélalkalmazás virtuális IP-címének átcserélése az előkészítési és az éles rések között.
  • Az alkalmazás méretének vagy példányainak számának skálázása.

Az ilyen módosítások olyan csatlakozási problémákat okozhatnak, amelyek általában egy percnél rövidebb ideig tartanak. Az ügyfélalkalmazás valószínűleg elveszíti a kapcsolatot más külső hálózati erőforrásokkal, de az Azure Cache for Redis szolgáltatással is.

Rugalmasság kiépítése

A feladatátvételeket nem lehet teljesen elkerülni. Ehelyett írja be az ügyfélalkalmazásokat, hogy rugalmasak legyenek a kapcsolat megszakadása és a sikertelen kérések esetén. A legtöbb ügyfélkódtár automatikusan újracsatlakozik a gyorsítótárvégponthoz, de közülük kevesen próbálják meg újrapróbálkozni a sikertelen kéréseket. Az alkalmazás forgatókönyvétől függően érdemes lehet újrapróbálkozási logikát használni a visszalépéssel.

Hogyan teheti rugalmassá az alkalmazást?

Ezeket a tervezési mintákat követve rugalmas klienseket hozhat létre, különösen a körmegszakító és az újrapróbálkozási minták alkalmazásával.

Az ügyfélalkalmazás rugalmasságának teszteléséhez használjon újraindítást manuális eseményindítóként a kapcsolat megszakadásához.

Azt is javasoljuk, hogy ütemezett frissítésekkel válasszon ki egy frissítési csatornát és egy karbantartási időszakot a gyorsítótár számára, hogy redis futtatókörnyezeti javításokat alkalmazzon adott heti időszakokban. Ezek az ablakok általában olyan időszakok, amikor az ügyfélalkalmazások forgalma alacsony, a lehetséges incidensek elkerülése érdekében. További információ: Frissítési csatorna és Frissítések ütemezése.

További információ: Kapcsolat rugalmassága.

Kapcsolódó tartalom

  • Last updated on