Feladatátvétel és javítások alkalmazása az Azure felügyelt Redis szolgáltatáshoz

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

A rugalmas és sikeres ügyfélalkalmazások létrehozásához fontos megérteni a feladatátvételt a Azure Managed Redisservice 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 a Azure Felügyelt 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 az átváltás a javítási folyamat során.
  • Rugalmas ügyfélalkalmazás létrehozása.

Mi az a feladatátvétel?

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

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

Az Azure Managed Redis szolgáltatás architektúráját bemutató diagram.

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 (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. Előfordulhat, hogy az egyik szegmens le van omlva, míg a többi elérhető marad.

A Azure felügyelt Redis-architektúra részletes részletei here találhatók.

Átállás magyarázata

Feladatátvétel akkor történik, ha egy vagy több replikaszegmens előlépteti magát elsődleges szegmensekké, és a régi elsődleges szegmensek lezárják a meglévő kapcsolatokat. Az átkapcsolá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 a fürt egy vagy több csomópontjának váratlan leállása miatt. A fennmaradó csomópont(ok) replikaszegmense(i) előléptetik magukat elsődlegesként a rendelkezésre állás fenntartása érdekében, de a folyamat hosszabb időt vesz igénybe. A replikaszegmensnek először észlelnie kell, hogy az elsődleges szegmens nem érhető el, mielőtt elindíthatja a feladatátvételi folyamatot. A replikatöredéknek azt is ellenőriznie kell, hogy ez a nem tervezett hiba nem átmeneti-e vagy helyi, hogy elkerülje a szükségtelen átállást. 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?

A Azure Managed 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 új, naprakész virtuális gépeket hoz létre a javítás alatt álló összes virtuális gép helyére.
  2. Ezután előlépteti az egyik új virtuális gépet fürtvezetőként.
  3. A javítás alatt álló csomópontokat egyenként eltávolítják a klaszterből. Az ezeken a virtuális gépeken lévő szegmensek lefokozva lesznek, és át lesznek migrálva az új virtuális gépek egyikére.
  4. Végül az összes lecserélt virtuális gép törlődik.

A klaszterezett gyorsítótár minden részét külön-külön javítják, és a javítás során nem záródnak le a kapcsolatok más részekhez.

Megjegyzés:

Előfordulhat, hogy ugyanabban a régióban több gyorsítótár is ki lesz javítva egyszerre. Ha ez hatással van az alkalmazásra, konfigurálja a karbantartási ütemezéseket úgy, hogy az egyes gyorsítótárak egy másik időpontban lesznek javítva.

Mivel a teljes adatszinkronizálás a folyamat megismétlése előtt történik, nem valószínű, hogy adatvesztés történik a gyorsítótárban. 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

Feladatátvétel esetén a gyorsítótáraknak az egyik csomópontról a másikra kell replikálnia az adatokat. 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 terhelt, 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.

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

Az ügyfélalkalmazások hibaüzeneteket kaphatnak a Azure Felügyelt Redis-példányuktól. Az ügyfélalkalmazás által tapasztalt 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. Minden olyan kapcsolat, amely a kapcsolatait lezáró csomóponton keresztül van átirányítva, hibákat fog tapasztalni.

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ási kivételek
  • Csatlakozó 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. Például egy olyan művelet, amely kérést küld, de nem kapott választ, amikor az átállás bekövetkezik, kaphat időtúllépési kivételt. 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 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. A 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.

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.

Megjelennek a karbantartási előzmények a Azure portálon?

A Azure portál karbantartási előzményeiről a gyorsítótárpéldány Azure Activity naplójában tájékozódhat. A karbantartás megkezdésekor a rendszer a "healthevent" eseményt bocsátja ki.

Képernyőkép a karbantartási eseményről a portál tevékenységnaplójában.

Az értesítések automatikus fogadásához állítson be egy riasztást a tevékenységnaplóban.

Ügyfélhálózati-konfigurációs módosítások

Bizonyos ügyféloldali hálózatkonfigurációs módosítások Nincs elérhető kapcsolat 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 felcserélése az előkészítési és az éles tárolóhelyek között.
  • Az alkalmazás mérete vagy példányai 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 a Azure Managed Redis szolgáltatással is.

Építsünk be ellenállóképességet

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 csak kevesen próbálják megismételni 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 visszalépéssel.

Hogyan tehetem rugalmassá az alkalmazást?

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

Kapcsolódó tartalom

  • Last updated on