Az Azure Stack Hubon üzembe helyezett virtuális gépek védelme – Ruggedized

  • Cikk

Ebből a cikkből megtudhatja, hogyan alakíthat ki tervet a felhasználók által az Azure Stack Hubon üzembe helyezett virtuális gépek (VM-ek) védelmére.

Az adatvesztés és a nem tervezett állásidő elleni védelem érdekében implementáljon egy adatvédelmi és vészhelyreállítási tervet a virtuálisgép-alapú alkalmazásokhoz az Azure Stack Hubon. A megvalósított védelmi terv az üzleti követelményektől és az alkalmazás kialakításától függ. Ennek a tervnek a szervezet átfogó üzletmenet-folytonossági és vészhelyreállítási (BC/DR) stratégiája által létrehozott keretrendszert kell követnie.

Alkalmazás-helyreállítási célkitűzések

Határozza meg, hogy a szervezet mennyi állásidőt és adatvesztést tolerálhat az egyes alkalmazások esetében. Az állásidő és az adatvesztés számszerűsítésével létrehozhat egy helyreállítási tervet, amely minimalizálja a katasztrófa szervezetre gyakorolt hatását. Minden alkalmazáshoz vegye figyelembe a következőket:

  • Helyreállítási időre vonatkozó célkitűzés (RTO)
    Az RTO az az elfogadható maximális idő, amikor egy alkalmazás nem érhető el egy incidens után. Egy 90 perces RTO például azt jelenti, hogy a katasztrófa kezdetétől számított 90 percen belül vissza kell tudnia állítani az alkalmazást futó állapotba. Ha alacsony RTO-t használ, előfordulhat, hogy egy második üzemelő példány folyamatosan fut készenlétben, hogy megvédje magát a regionális kimaradástól.

  • Helyreállítási időkorlát (RPO)
    A helyreállítási időkorlát (RPO) a katasztrófa során elfogadható adatveszteség maximális ideje. Ha például egyetlen adatbázisban tárol adatokat, amelyekről óránként készül biztonsági másolat, és nem rendelkezik replikációval más adatbázisokba, akár egy órányi adatot is elveszíthet.

Végezzen értékelést az RTO és az RPO meghatározásához az egyes alkalmazásokhoz.

Egy másik fontos metrika a helyreállítás átlagos ideje (MTTR), amely az alkalmazás meghibásodás utáni visszaállításához szükséges átlagos idő. Az MTTR egy rendszer empirikus értéke. Ha az MTTR meghaladja az RTO-t, akkor a rendszer meghibásodása elfogadhatatlan üzleti fennakadást okoz, mert nem lehet visszaállítani a rendszert a meghatározott RTO-ban.

Védelmi lehetőségek IaaS virtuális gépekhez

Biztonsági mentés visszaállítása

A virtuálisgép-alapú alkalmazások leggyakoribb védelmi sémája a biztonsági mentési szoftverek használata. A virtuális gépek biztonsági mentése általában magában foglalja az operációs rendszert, az operációs rendszer konfigurációját, az alkalmazás bináris fájljait és a virtuális gépen található állandó alkalmazásadatokat. A biztonsági másolatok a vendég operációs rendszer ügynökének használatával jönnek létre az alkalmazások, operációs rendszerek vagy fájlrendszerek/kötetek rögzítéséhez. Egy másik megközelítés az ügynök nélküli megoldás, ha az Azure Stack Hub API-kkal való integrációra támaszkodik a virtuális gép konfigurációjával kapcsolatos információk olvasásához és a virtuális géphez csatolt lemezek pillanatképének megtekintéséhez. Vegye figyelembe, hogy az Azure Stack Hub nem támogatja a közvetlenül a hipervizorból történő biztonsági mentést.

A biztonsági mentési stratégia megtervezése

A biztonsági mentési stratégia megtervezése és a skálázási követelmények meghatározása a védeni kívánt virtuálisgép-példányok számának számszerűsítésével kezdődik. Előfordulhat, hogy a rendszer összes virtuális gépének biztonsági mentése nem a leghatékonyabb módja az alkalmazás védelmének. Az Azure Stack Hubbal a méretezési csoportban vagy rendelkezésre állási csoportban lévő virtuális gépekről nem szabad biztonsági másolatot készíteni a virtuális gép szintjén. Ezek a virtuális gépek rövid élettartamúnak minősülnek, mivel a virtuális gépek halmaza fel- vagy leskálázható. Ideális esetben minden megőrzendő adat egy külön adattárban, például egy adatbázisban vagy objektumtárolóban található. Ha a kibővített architektúrában üzembe helyezett alkalmazások olyan adatokat tartalmaznak, amelyeket meg kell őrizni és védeni kell, akkor az alkalmazásszintű biztonsági mentést az alkalmazás által biztosított natív képességek vagy egy ügynök használatával kell elvégezni.

Fontos szempontok az Azure Stack virtuális gépeinek biztonsági mentéséhez:

  • Kategorizálás
    • Vegyünk egy olyan modellt, amelyben a felhasználók a virtuális gépek biztonsági mentését választják.
    • Helyreállítási szolgáltatásiszint-szerződés (SLA) meghatározása az alkalmazások prioritása vagy az üzletmenetre gyakorolt hatás alapján.
  • Méretezés
    • Nagy számú új virtuális gép beszálláskor fontolja meg az átmeneti biztonsági mentéseket (ha biztonsági mentésre van szükség).
    • Értékelje ki azokat a biztonsági mentési termékeket, amelyek hatékonyan rögzíthetik és továbbíthatják a biztonsági mentési adatokat a megoldás erőforrás-tartalmának minimalizálása érdekében.
    • Értékelje ki azokat a biztonsági mentési termékeket, amelyek növekményes vagy különbségi biztonsági mentésekkel hatékonyan tárolják a biztonsági mentési adatokat, hogy minimálisra csökkentse a teljes biztonsági mentés szükségességét a környezet összes virtuális gépén.
  • Visszaállítás
    • A biztonsági mentési termékek visszaállíthatják a virtuális lemezeket, az alkalmazásadatokat egy meglévő virtuális gépen belül, vagy a teljes virtuálisgép-erőforrást és a társított virtuális lemezeket. A szükséges visszaállítási séma attól függ, hogyan tervezi visszaállítani az alkalmazást. Egyszerűbb lehet például újra üzembe helyezni az SQL Servert egy sablonból, majd visszaállítani az adatbázisokat a teljes virtuális gép vagy virtuálisgép-készlet visszaállítása helyett.

Replikáció/manuális feladatátvétel

A helyreállítás támogatásának alternatív módszere az adatok másik környezetbe való replikálás. Az adatok hatóköre az alkalmazásra, például az adatbázis-replikációra vagy a vendég operációs rendszer operációs rendszerére terjedhet ki egy ügynökkel, vagy a virtuális gép szintjén az Azure Stack Hub API-kkal való integrációval. Katasztrófa esetén feladatátvételre van szükség a másodlagos helyre. A feladatátvételt az alkalmazás natív módon, például az SQL rendelkezésre állási csoportokkal vagy a vendég operációs rendszer szintjén kezelheti ügynökök vagy fürttechnológiák használatával, vagy a virtuális gép szintjén egy védelmi termék használatával.

Magas rendelkezésre állás/automatikus feladatátvétel

Azok az alkalmazások, amelyek natív módon támogatják a magas rendelkezésre állást, vagy fürtszoftverre támaszkodnak a csomópontok közötti magas rendelkezésre állás eléréséhez, üzembe helyezhetők virtuális gépek egy csoportjában egy Azure Stack Hubban vagy több Azure Stack Hub-példányon. Minden esetben bizonyos szintű terheléselosztásra van szükség az alkalmazásforgalom megfelelő irányításának biztosításához. Ebben a konfigurációban az alkalmazás automatikusan helyre tud állni a hibákból. A helyi hardverhibák esetén az Azure Stack Hub-infrastruktúra magas rendelkezésre állást és hibatűrést valósít meg a fizikai infrastruktúrában. Számítási szintű hibák esetén az Azure Stack Hub több csomópontot használ egy skálázási egységben egy N-1 konfigurációban. A virtuális gép szintjén a rendelkezésre állási és méretezési csoportok hibatartományként modellezik a skálázási egység összes csomópontját, hogy garantálják a csomópontszintű affinitást, így a csomóponthibák nem veszik le az elosztott alkalmazásokat.

Nincs védelem

Előfordulhat, hogy egyes alkalmazások nem rendelkeznek olyan adatokkal, amelyeket meg kell őrizni. A fejlesztéshez és teszteléshez használt virtuális gépeket például általában nem kell helyreállítani. Egy másik példa egy állapot nélküli alkalmazás, amely hiba esetén újra üzembe helyezhető egy CI/CD-folyamatból. Fontos azonosítani azokat az alkalmazásokat, amelyek nem igényelnek védelmet a virtuális gépek szükségtelen védelmének elkerülése érdekében.

Partnertermékek