Feladatátvétel és javítás az Azure Cache for Redis kapcsán

  • Cikk

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ének gyakori használata akkor következik be, ha a felügyeleti szolgáltatás kijavítja 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 a gazdagépné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 fürtözött gyorsítótárak számos szegmensből állnak, amelyek mindegyike különálló elsődleges és replikacsomópontokkal van elérhetővé téve. Előfordulhat, hogy az egyik szegmens le van omlva, míg a többi elérhető marad.

Feljegyzé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.

Feladatátvétel 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. Az elsődleges csomópont biztonsági mentése után megfigyeli 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. Előfordulhat, hogy feladatátvételt terveznek vagy nem tervezettek.

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ésleltetése azt jelenti, 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őlépteti magát az elsődleges példányra. 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 végrehajtása érdekében, és replikacsomópontként fog biztonsági másolatot készíteni.
  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 tervezett feladatátvétel, a replikacsomópont gyorsan előlépteti magát elsődlegesként. 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árak egyenként egy szegmensben vannak javítva.

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 javíthatók.

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 .

Milyen hatással van a feladatátvétel az ügyfélalkalmazásomra?

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 kapcsolatokat lezáró csomóponton keresztül átirányított kapcsolatok hibákat látnak.

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
  • Csatlakozás-kivételek
  • Szoftvercsatorna-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ódtár megpróbál újracsatlakozni a gyorsítótárhoz, ha erre van konfigurálva. 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. Az Microsoft.NET és más objektumorientált nyelvekben az alkalmazás újraindítása nélkül újra lehet indítani a kapcsolatot 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-ügyfélkódtár támogatja a pubra/alcsatorná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.

Feljegyzé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?

A csatorna használatakor AzureRedisEvents 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 nem válthatnak ki kapcsolati hibákat . Ilyen módosítások lehetnek a következők:

  • Az ügyfélalkalmazás virtuális IP-címének felcserélése az előkészítési és az éles tárolóhelyek 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.

Buildelés rugalmasságban

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 rugalmassá tenni az alkalmazást?

Ezeket a tervezési mintákat követve rugalmas ügyfeleket hozhat létre, különösen az áramkör-megszakítót és az újrapróbálkozási mintákat:

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ó: Csatlakozás ion rugalmassága.

Kapcsolódó tartalom