Az Azure Cache for Redis felügyelete

  • Cikk

Ez a cikk bemutatja, hogyan végezhet olyan adminisztrációs feladatokat, mint az újraindítás és a csatorna frissítése, valamint az Azure Cache for Redis-példányok frissítéseinek ütemezése.

Újraindítás

A bal oldalon az újraindítás lehetővé teszi a gyorsítótár egy vagy több csomópontjának újraindítását. Ez az újraindítási funkció lehetővé teszi az alkalmazás rugalmasságának tesztelését, ha egy gyorsítótárcsomópont meghibásodik.

Fontos

Az újraindítás még nem érhető el a nagyvállalati szinten. Az újraindítás minden más szinten elérhető.

Az Újraindítás menüt kiemelő képernyőkép

Válassza ki az újraindítani kívánt csomópontokat, majd válassza az Újraindítás lehetőséget.

Képernyőkép az újraindítható csomópontokról

Ha van egy prémium szintű gyorsítótára, amelyen engedélyezve van a fürtözés, kiválaszthatja, hogy a gyorsítótár mely szegmenseit indítsa újra.

képernyőkép a szegmensbeállításokról

A gyorsítótár egy vagy több csomópontjának újraindításához jelölje ki a csomópontokat, és válassza az Újraindítás lehetőséget. Ha van egy prémium szintű gyorsítótára, amelyen engedélyezve van a fürtözés, jelölje ki az újraindítandó szegmenseket, majd válassza az Újraindítás lehetőséget. Néhány perc múlva a kijelölt csomópontok újraindulnak, és néhány perccel később újra online állapotba kerülnek.

Az ügyfélalkalmazásokra gyakorolt hatás attól függően változik, hogy mely csomópontokat indítja újra.

  • Elsődleges – Az elsődleges csomópont újraindítása után az Azure Cache for Redis feladatátvételt indít a replikacsomóponton, és előlépteti az elsődleges csomópontra. A feladatátvétel során előfordulhat, hogy a kapcsolatok nem fognak csatlakozni a gyorsítótárhoz.
  • Replika – A replikacsomópont újraindítása általában nincs hatással a gyorsítótár-ügyfelekre.
  • Az elsődleges és a replika is – Mindkét gyorsítótár-csomópont újraindításakor az Azure Cache for Redis megkísérli a mindkét csomópontot kecsesen újraindítani, és megvárja, amíg az egyik befejeződik, mielőtt újraindítja a másikat. Az adatvesztés általában nem fordul elő. Az adatvesztés azonban továbbra is előfordulhat váratlan karbantartási események vagy hibák esetén. A gyorsítótár többszöri újraindítása növeli az adatvesztés esélyét.
  • Prémium szintű gyorsítótár csomópontjai a fürtszolgáltatás engedélyezésével – Ha egy prémium szintű gyorsítótár egy vagy több csomópontját újraindítja, és engedélyezve van a fürtözés, a kijelölt csomópontok viselkedése megegyezik a nem fürtözött gyorsítótár megfelelő csomópontjának vagy csomópontjainak újraindításakor.

Újraindítás – gyakori kérdések

Melyik csomópontot kell újraindítani az alkalmazás teszteléséhez?

Ha tesztelni szeretné az alkalmazás rugalmasságát a gyorsítótár elsődleges csomópontjának meghibásodása ellen, indítsa újra az elsődleges csomópontot. Ha tesztelni szeretné az alkalmazás rugalmasságát a replikacsomópont meghibásodása ellen, indítsa újra a replikacsomópontot .

Újraindíthatom a gyorsítótárat az ügyfélkapcsolatok törléséhez?

Igen, ha újraindítja a gyorsítótárat, az összes ügyfélkapcsolat törlődik. Az újraindítás akkor lehet hasznos, ha az ügyfélalkalmazásban logikai hiba vagy hiba miatt minden ügyfélkapcsolat fel van használva. Minden tarifacsomag különböző ügyfélkapcsolati korlátokkal rendelkezik a különböző méretekhez, és a korlátok elérése után a rendszer nem fogad el több ügyfélkapcsolatot. A gyorsítótár újraindítása lehetővé teszi az összes ügyfélkapcsolat törlését.

Fontos

Ha újraindítja a gyorsítótárat az ügyfélkapcsolatok törlése érdekében, a StackExchange.Redis automatikusan újracsatlakozik, amint a Redis-csomópont ismét online állapotba kerül. Ha az alapul szolgáló probléma nem oldódott meg, előfordulhat, hogy az ügyfélkapcsolatok továbbra is használatban lesznek.

Elveszítem az adatokat a gyorsítótáramból, ha újraindulok?

Ha az elsődleges és a replika csomópontot is újraindítja, a gyorsítótárban (vagy abban a szegmensben, ha prémium szintű gyorsítótárat használ, és engedélyezve van a fürtözés), valószínűleg biztonságos. Előfordulhat azonban, hogy bizonyos esetekben elvesznek az adatok. Mindkét csomópont újraindítását körültekintően kell eljárni.

Ha csak az egyik csomópontot indítja újra, az adatok általában nem vesznek el, de továbbra is előfordulhatnak. Ha például az elsődleges csomópont újraindul, és a gyorsítótár írása folyamatban van, a gyorsítótár írásából származó adatok elvesznek. Az adatvesztés másik forgatókönyve az lenne, ha újraindítja az egyik csomópontot, a másik csomópont pedig egy egyidejű hiba miatt leáll. További információ az adatvesztés lehetséges okairól: Mi történt az adataimmal a Redisben?

Újraindíthatom a gyorsítótárat a PowerShell, a parancssori felület vagy más felügyeleti eszközök használatával?

Igen, a PowerShell-utasításokért lásd : Azure Cache for Redis újraindítása.

Újraindíthatom a vállalati gyorsítótárat?

Szám Az újraindítás még nem érhető el a nagyvállalati szinten. Az újraindítás az alapszintű, a standard és a prémium szintű szinteken érhető el. A Rendszergazda istration erőforrás menüjében látható beállítások a gyorsítótár szintjétől függenek. Nem látja az újraindítást , ha gyorsítótárat használ a vállalati szintről.

Adatok kiürítése

Az Azure Cache for Redis Alapszintű, Standard vagy Prémium szintjeinek használatakor az erőforrás menüjében láthatja az adatok kiürítése lehetőséget. Az adatok kiürítése művelettel törölheti vagy kiürítheti az összes adatot a gyorsítótárban. Ez a kiürítési művelet a skálázási műveletek előtt használható, így csökkentheti a gyorsítótár skálázási műveletének befejezéséhez szükséges időt. Azt is beállíthatja, hogy a kiürítési műveletet rendszeresen futtassa a fejlesztői/tesztgyorsítótárakon a memóriahasználat ellenőrzése érdekében.

A fürtözött gyorsítótáron végrehajtott kiürítési művelet egyszerre törli az adatokat az összes szegmensből.

Fontos

Korábban a kiürítési művelet csak a georeplikált vállalati szintű gyorsítótárakhoz volt elérhető. Mostantól alapszintű, standard és prémium szinten is elérhető.

Képernyőkép a gyorsítótárpéldány erőforrásmenüjében kijelölt adatok kiürítéséről.

Csatorna frissítése és frissítések ütemezése

A bal oldalon a Frissítések ütemezése funkcióval kiválaszthat egy frissítési csatornát és egy karbantartási időszakot a gyorsítótárpéldányhoz.

A Stabil frissítési csatornát használó gyorsítótárpéldányok néhány héttel később kapnak frissítéseket, mint az előzetes verziójú frissítési csatornát használó gyorsítótárpéldányok. Javasoljuk, hogy a nem éles és kevésbé kritikus számítási feladatokhoz válassza az előzetes verziójú frissítési csatornát. Válassza ki a Legstabilabb frissítési csatornát a legkritikusabb éles számítási feladatokhoz. Alapértelmezés szerint az összes gyorsítótár alapértelmezés szerint a stabil frissítési csatornára van bekapcsolva.

Fontos

Ha módosítja a frissítési csatornát a gyorsítótárpéldányon, a gyorsítótár javítási eseményen megy keresztül a megfelelő frissítések alkalmazásához. Fontolja meg a frissítési csatorna módosítását a karbantartási időszak alatt.

A karbantartási időszak lehetővé teszi annak a hétnek a napjait és idejét, amelyek során a gyorsítótárat üzemeltető virtuális gépek frissíthetők. Az Azure Cache for Redis mindent megtesz annak érdekében, hogy a megadott időkereten belül megkezdje és befejezze a Redis-kiszolgáló szoftverének frissítését.

Fontos

A frissítési csatorna és a karbantartási időszak a Redis-kiszolgáló frissítésére és a gyorsítótárat üzemeltető virtuális gépek operációs rendszerének frissítésére vonatkozik. A frissítési csatorna és a karbantartási időszak nem vonatkozik a gazdagép operációs rendszerének frissítéseire a gyorsítótár virtuális gépeket vagy más Azure Networking-összetevőket üzemeltető gazdagépeken. Ritka esetekben, amikor a gyorsítótárakat régebbi modelleken üzemeltetik, a karbantartási időszak a vendég operációs rendszer frissítésére sem vonatkozik. Megállapíthatja, hogy a gyorsítótár egy régebbi modellen található-e, ha a gyorsítótár cloudapp.netDNS-neve az , chinacloudapp.cnusgovcloudapi.net vagy cloudapi.de.

Jelenleg nincs lehetőség a frissítési csatorna vagy a vállalati szintű gyorsítótár ütemezett frissítéseinek konfigurálására.

Képernyőkép az ütemezési frissítésekről

Karbantartási időszak megadásához ellenőrizze a kívánt napokat, és adja meg az egyes napok kezdési óráját. Ez után válassza az OK gombot. A karbantartási idő UTC-ben van, és csak óránként konfigurálható.

A frissítések alapértelmezett és minimális karbantartási ideje öt óra. Ez az érték nem konfigurálható az Azure Portalról, de a New-AzRedisCacheScheduleEntry parancsmag paraméterével konfigurálhatja a PowerShellbenMaintenanceWindow. További információ: Kezelhetim az ütemezett frissítéseket a PowerShell, a parancssori felület vagy más felügyeleti eszközök használatával?

Frissítések ütemezése – gyakori kérdések

Mikor történnek frissítések, ha nem használom az ütemezési frissítések funkciót?

Ha nem ad meg karbantartási időszakot, a frissítések bármikor elvégezhetők.

Milyen típusú frissítéseket végeznek az ütemezett karbantartási időszak alatt?

Az ütemezett karbantartási időszak alatt csak a Redis-kiszolgáló frissítése történik. A karbantartási időszak nem vonatkozik az Azure-frissítésekre vagy a gazdagép operációs rendszerének frissítésére.

Kezelhetim az ütemezett frissítéseket a PowerShell, a parancssori felület vagy más felügyeleti eszközök használatával?

Igen, az ütemezett frissítéseket a következő PowerShell-parancsmagokkal kezelheti:

Lehetséges az Ütemezett Frissítések szolgáltatás által lefedett és felügyelt frissítés az Ütemezett Frissítések ablakon kívül?

Igen. A rendszer általában nem alkalmazza a frissítéseket a konfigurált ütemezett Frissítések ablakban kívül. A ritka kritikus biztonsági frissítések a biztonsági szabályzat részeként a javítás ütemezésén kívül is alkalmazhatók.

Kapcsolódó tartalom

További információ az Azure Cache for Redis funkcióiról.