Mik az üzletmenet-folytonosság, a magas rendelkezésre állás és a vészhelyreállítás?

Ez a cikk az üzletmenet-folytonosság és az üzletmenet-folytonosság tervezését határozza meg és ismerteti a magas rendelkezésre állás és vészhelyreállítási tervezés révén történő kockázatkezelés szempontjából. Bár ez a cikk nem nyújt explicit útmutatást a saját üzletmenet-folytonossági igényeinek való megfeleléshez, segít megérteni a Microsoft megbízhatósági útmutatójában használt fogalmakat.

Az üzletmenet-folytonosság az az állapot, amelyben a vállalat folytathatja a műveleteket hibák, kimaradások vagy katasztrófák során. Az üzletmenet-folytonosság proaktív tervezést, előkészítést és rugalmas rendszerek és folyamatok megvalósítását igényli.

Az üzletmenet-folytonosság tervezéséhez szükség van a kockázatok azonosítására, megértésére, besorolására és kezelésére. A kockázatok és azok valószínűsége alapján a magas rendelkezésre állás (HA) és a vészhelyreállítás (DR) tervezése.

A magas rendelkezésre állás egy olyan megoldás kialakításáról szól, amely ellenáll a napi problémáknak, és kielégíti az üzleti igényeket a rendelkezésre álláshoz.

A vészhelyreállítás a nem gyakori kockázatok és az ebből eredő katasztrofális kimaradások kezelésének tervezéséről szól.

Az üzletmenet folytonossága

A felhőmegoldások általában közvetlenül üzleti műveletekhez kötődnek. Ha egy felhőmegoldás nem érhető el, vagy súlyos problémát tapasztal, az üzleti műveletekre gyakorolt hatás súlyos lehet. Egy súlyos hatás megszakíthatja az üzletmenet folytonosságát.

Az üzletmenet-folytonosságra gyakorolt súlyos hatások a következők lehetnek:

• Üzleti bevételkiesés.
• Az, hogy nem lehet fontos szolgáltatást nyújtani a felhasználóknak.
• Egy ügyfél vagy egy másik fél felé tett kötelezettségvállalás megszegése.

Fontos megérteni és közölni az üzleti elvárásokat és a hibák következményeit a fontos érdekelt felekkel, beleértve azokat is, akik megtervezik, megvalósítják és működtetik a számítási feladatot. Ezek az érdekelt felek ezt követően úgy válaszolnak, hogy megosztják a jövőkép teljesítésével járó költségeket. Általában a költségvetés és egyéb korlátozások alapján zajlik a tárgyalások és a vízió felülvizsgálata.

Üzletmenet-folytonosság tervezése

Az üzletmenet-folytonosságra gyakorolt negatív hatás szabályozása vagy teljes elkerülése érdekében fontos proaktívan létrehozni egy üzletmenet-folytonossági tervet. Az üzletmenet-folytonossági terv a kockázatértékelésen és a kockázatok különböző megközelítéseken keresztüli ellenőrzésének módszerein alapul. A konkrét kockázatokat és a mérséklésre szolgáló megközelítések az egyes szervezetek és számítási feladatok esetében eltérőek.

Az üzletmenet-folytonossági terv nem csak a felhőplatform rugalmassági funkcióit veszi figyelembe, hanem az alkalmazás funkcióit is. A robusztus üzletmenet-folytonossági terv magában foglalja az üzleti támogatás minden aspektusát, beleértve a személyeket, az üzleti vonatkozású manuális vagy automatizált folyamatokat és egyéb technológiákat.

Az üzletmenet-folytonosság tervezésének a következő szekvenciális lépéseket kell tartalmaznia:

1. Kockázat azonosítása. A számítási feladatok rendelkezésre állását vagy funkcióit érintő kockázatok azonosítása. Lehetséges kockázatok lehetnek hálózati problémák, hardverhibák, emberi hiba, régiókimaradás stb. Ismerje meg az egyes kockázatok hatását.

2. Kockázati besorolás. Sorolja be az egyes kockázatokat közös kockázatként, amelyet figyelembe kell venni a HA-tervekben, vagy egy nem gyakori kockázatként, amelynek a DR-tervezés részét kell képeznie.

3. Kockázatcsökkentés. Tervezzen kockázatcsökkentési stratégiákat a ha- vagy dr. vészhelyreállításhoz a kockázatok minimalizálása vagy csökkentése érdekében, például redundancia, replikáció, feladatátvétel és biztonsági másolatok használatával. Fontolja meg a nem műszaki és folyamatalapú kockázatcsökkentéseket és -vezérléseket is.

Az üzletmenet-folytonosság tervezése folyamat, nem egyszeri esemény. Minden létrehozott üzletmenet-folytonossági tervet rendszeresen felül kell vizsgálni és frissíteni kell annak biztosítása érdekében, hogy az releváns és hatékony maradjon, és hogy a jelenlegi üzleti igényeket is kielégítse.

Kockázat azonosítása

Az üzletmenet-folytonosság tervezésének első fázisa a számítási feladatok rendelkezésre állását vagy funkcióit érintő kockázatok azonosítása. Minden kockázatot elemezni kell annak valószínűségének és súlyosságának megértése érdekében. A súlyosságnak tartalmaznia kell bármilyen lehetséges állásidőt vagy adatvesztést, valamint azt, hogy a megoldás többi részének bármely aspektusa kompenzálhatja-e a negatív hatásokat.

Az alábbi táblázat a kockázatok nem teljes listáját tartalmazza, a valószínűség csökkentésével rendezve:

Az üzletmenet-folytonosság tervezése nem csupán a felhőplatformról és az infrastruktúráról szól. Fontos figyelembe venni az emberi hibák kockázatát. Ezenkívül bizonyos kockázatokat, amelyek hagyományosan biztonsági, teljesítmény- vagy üzemeltetési kockázatnak tekinthetők, megbízhatósági kockázatnak is kell tekinteni, mivel ezek befolyásolják a megoldás rendelkezésre állását.

Íme néhány példa:

A hibamód-elemzés (FMA) az a folyamat, amely azonosítja a számítási feladatok vagy összetevői meghibásodásának lehetséges módjait, valamint azt, hogy a megoldás hogyan viselkedik ezekben a helyzetekben. További információ: Javaslatok a hibamód-elemzés végrehajtásához.

Kockázatbesorolás

Az üzletmenet-folytonossági terveknek a gyakori és a nem gyakori kockázatokkal is foglalkozniuk kell.

• A közös kockázatok megtervezve és elvárva vannak. Felhőkörnyezetben például gyakori, hogy átmeneti hibák lépnek fel, például rövid hálózati kimaradások, javítások miatti berendezések újraindítása, időtúllépések, amikor egy szolgáltatás foglalt, és így tovább. Mivel ezek az események rendszeresen történnek, a számítási feladatoknak rugalmasnak kell lenniük velük szemben.

  A magas rendelkezésre állási stratégiának figyelembe kell vennie és szabályoznia kell az ilyen típusú kockázatokat.

• A nem gyakori kockázatok általában egy előre nem látható esemény, például természeti katasztrófa vagy nagyobb hálózati támadás eredménye, amely katasztrofális kimaradáshoz vezethet.

  A vészhelyreállítási folyamatok kezelik ezeket a ritka kockázatokat.

A magas rendelkezésre állás és a vészhelyreállítás egymással összefügg, ezért fontos, hogy mindkettőhöz közösen tervezze meg a stratégiákat.

Fontos tisztában lenni azzal, hogy a kockázatbesorolás a számítási feladatok architektúrájától és az üzleti követelményektől függ, és egyes kockázatok ha-ként besorolhatók az egyik számítási feladathoz, a dr. pedig egy másik számítási feladathoz. A teljes Azure-régió kimaradása például általában az adott régióban lévő számítási feladatokra vonatkozó DR-kockázatnak minősül. A több Azure-régiót teljes replikációval, redundanciával és automatikus feladatátvétellel rendelkező aktív-aktív konfigurációban használó számítási feladatok esetében azonban a régiókimaradás ha-kockázatként van besorolva.

Kockázatcsökkentés

A kockázatcsökkentés a ha- vagy dr. vészhelyreállítási stratégiák kidolgozásából áll, amelyek minimalizálják vagy mérsékelik az üzletmenet-folytonossági kockázatokat. A kockázatcsökkentés lehet technológiaalapú vagy emberi alapú.

Technológiaalapú kockázatcsökkentés

A technológiaalapú kockázatcsökkentés a számítási feladat implementálásán és konfigurálásán alapuló kockázatvezérlőket használ, például:

• Redundancia
• Adatreplikáció
• Feladatátvétel
• Biztonsági másolatok

A technológiaalapú kockázatkezelést az üzletmenet-folytonossági terv kontextusában kell figyelembe venni.

Példa:

• Alacsony állásidőre vonatkozó követelmények. Egyes üzletmenet-folytonossági tervek szigorú magas rendelkezésre állási követelmények miatt nem képesek elviselni az állásidő bármilyen formáját. Vannak bizonyos technológiaalapú vezérlők, amelyekhez időre lehet szükség ahhoz, hogy egy ember értesítést kapjon, majd válaszoljon. A lassú manuális folyamatokat tartalmazó technológiaalapú kockázatellenőrzések valószínűleg alkalmatlanok a kockázatcsökkentési stratégiájukba való felvételre.

• A részleges hibáktól való tűrés. Egyes üzletmenet-folytonossági tervek képesek elviselni a csökkentett állapotban futó munkafolyamatokat. Ha egy megoldás csökkentett állapotban működik, előfordulhat, hogy egyes összetevők le vannak tiltva vagy nem működnek, de az alapvető üzleti műveletek továbbra is végrehajthatók. További információ: Javaslatok az öngyógyításhoz és az önmegőrzéshez.

Emberi alapú kockázatcsökkentés

Az emberi alapú kockázatcsökkentés olyan kockázatkezeléseket használ, amelyek üzleti folyamatokon alapulnak, például:

• Válasz forgatókönyv aktiválása.
• Vissza a manuális műveletekre.
• Képzés és kulturális változások.

Mivel az emberi alapú kockázatkezelések gyakran lassabbak, mint a technológiaalapú vezérlők, és hajlamosabbak az emberi hibákra, egy jó üzletmenet-folytonossági tervnek tartalmaznia kell egy formális változásvezérlési folyamatot minden olyan dologhoz, amely megváltoztatná a futó rendszer állapotát. Fontolja meg például a következő folyamatok implementálását:

• A számítási feladatok szigorú tesztelése a számítási feladatok kritikusságának megfelelően. A módosításokkal kapcsolatos problémák elkerülése érdekében mindenképpen tesztelje a számítási feladaton végrehajtott módosításokat.
• A számítási feladatok biztonságos üzembehelyezési gyakorlatának részeként stratégiai minőségi kapukat vezet be. További információ: Javaslatok a biztonságos üzembe helyezési eljárásokhoz.
• Az alkalmi éles hozzáférés és az adatmanipuláció eljárásainak formalizálása. Ezek a tevékenységek, függetlenül attól, hogy milyen kisebbek, nagy kockázatot jelenthetnek a megbízhatósági incidensek okozására. Az eljárások közé tartozhat például egy másik mérnökkel való párosítás, ellenőrzőlisták használata, valamint a szkriptek végrehajtása vagy a módosítások alkalmazása előtt a társértékelések lekérése.

Magas szintű rendelkezésre állás

A magas rendelkezésre állás az az állapot, amelyben egy adott számítási feladat napi szinten képes fenntartani a szükséges üzemidőt, még átmeneti hibák és időszakos hibák esetén is. Mivel ezek az események rendszeresen történnek, fontos, hogy minden számítási feladatot magas rendelkezésre állásra tervezzenek és konfiguráljon az adott alkalmazás követelményeinek és az ügyfelek elvárásainak megfelelően. Az egyes számítási feladatok HA-ja hozzájárul az üzletmenet-folytonossági tervhez.

Mivel a HA az egyes számítási feladatoktól eltérő lehet, fontos tisztában lenni a magas rendelkezésre állás meghatározásával kapcsolatos követelményekkel és az ügyfelek elvárásaival. Előfordulhat például, hogy egy olyan alkalmazás, amelyet a szervezet az irodai eszközök megrendelésére használ, viszonylag alacsony üzemidőt igényelhet, míg egy kritikus pénzügyi alkalmazás sokkal magasabb üzemidőt igényelhet. A különböző folyamatoknak még a számítási feladatokon belül is eltérő követelményekkel kell rendelkezniük. Egy e-kereskedelmi alkalmazásban például a megrendeléseket böngésző és leadó ügyfeleket támogató folyamatok fontosabbak lehetnek, mint a megrendelések teljesítése és a háttériroda feldolgozási folyamatai. A folyamatokról további információt a folyamatok azonosítására és minősítésére vonatkozó javaslatokban talál.

Az üzemidőt általában a "kilences" érték alapján mérik az üzemidő százalékos arányában. Az üzemidő százalékos aránya ahhoz kapcsolódik, hogy mennyi állásidőt engedélyez egy adott időszakban. Íme néhány példa:

• A 99,9%-os üzemidőre vonatkozó követelmény (három kilences) körülbelül 43 perc állásidőt tesz lehetővé egy hónapban.
• A 99,95%-os üzemidőre vonatkozó követelmény (három és fél kilences) körülbelül 21 perc állásidőt tesz lehetővé egy hónapban.

Minél magasabb az üzemidőre vonatkozó követelmény, annál kisebb a kimaradásokkal szembeni tolerancia, és annál több munkát kell elvégeznie ahhoz, hogy elérje ezt a rendelkezésre állási szintet. Az üzemidőt nem egyetlen összetevő, például egy csomópont üzemideje, hanem a teljes számítási feladat általános rendelkezésre állása méri.

Magas rendelkezésre állású tervezési elemek

A HA-követelmények elérése érdekében a számítási feladatok számos tervezési elemet tartalmazhatnak. A gyakori elemek némelyikét az alábbiakban találja és ismerteti ebben a szakaszban.

Magas rendelkezésre állást támogató Azure-szolgáltatások és -szintek

Számos Azure-szolgáltatás magas rendelkezésre állású, és magas rendelkezésre állású számítási feladatok létrehozásához használható. Íme néhány példa:

• Az Azure-beli virtuálisgép-méretezési csoportok magas rendelkezésre állást biztosítanak a virtuális gépek (VM-ek) számára a virtuálisgép-példányok automatikus létrehozásával és kezelésével, valamint a virtuálisgép-példányok elosztásával az infrastruktúra hibáinak hatásának csökkentése érdekében.
• Azure-alkalmazás szolgáltatás számos megközelítéssel biztosítja a magas rendelkezésre állást, beleértve a feldolgozók automatikus áthelyezését a nem megfelelő csomópontról egy kifogástalan állapotú csomópontra, valamint számos gyakori hibatípus öngyógyítási lehetőségeit.

Az egyes szolgáltatás-megbízhatósági útmutatók segítségével megismerheti a szolgáltatás képességeit, meghatározhatja a használni kívánt szinteket, és meghatározhatja, hogy mely képességeket vegye fel a magas rendelkezésre állási stratégiába.

Tekintse át az egyes szolgáltatásokra vonatkozó szolgáltatásiszint-szerződéseket (SLA-kat), hogy megismerje a várt rendelkezésre állási szinteket és azokat a feltételeket, amelyeknek meg kell felelnie. Előfordulhat, hogy bizonyos rendelkezésre állási szintek eléréséhez ki kell választania vagy el kell kerülnie bizonyos szolgáltatási szinteket. A Microsoft egyes szolgáltatásai azzal a megértéssel érhetők el, hogy nem biztosítanak SLA-t, például fejlesztési vagy alapszintű szinteket, vagy hogy az erőforrás visszaigényelhető a futó rendszerből, például a kihasználatlan ajánlatokból. Egyes szintek emellett megbízhatósági funkciókat is hozzáadtak, például a rendelkezésre állási zónák támogatását.

Hibatűrés

A hibatűrés a rendszer azon képessége, hogy hiba esetén bizonyos meghatározott kapacitásban továbbra is működjön. Előfordulhat például, hogy egy webalkalmazás úgy van kialakítva, hogy továbbra is működjön, még akkor is, ha egyetlen webkiszolgáló meghibásodik. A hibatűrés redundanciával, feladatátvétellel, particionálással, kecses leépítéssel és egyéb technikákkal érhető el.

A hibatűrés azt is megköveteli, hogy az alkalmazások átmeneti hibákat kezeljenek. Ha saját kódot hoz létre, előfordulhat, hogy engedélyeznie kell az átmeneti hibakezelést. Egyes Azure-szolgáltatások bizonyos helyzetekben beépített átmeneti hibakezelést biztosítanak. Az Azure Logic Apps például alapértelmezés szerint automatikusan újrapróbálkozza a más szolgáltatásokra irányuló sikertelen kéréseket. További információkért tekintse meg az átmeneti hibák kezelésére vonatkozó javaslatokat.

Redundancia

A redundancia a példányok vagy adatok duplikálásának gyakorlata a számítási feladat megbízhatóságának növelése érdekében.

A redundancia a replikák vagy redundáns példányok eggyel több módon történő elosztásával érhető el:

• Adatközponton belül (helyi redundancia)
• Régión belüli rendelkezésre állási zónák között (zónaredundancia)
• Régiók közötti (georedundancia).

Íme néhány példa arra, hogy egyes Azure-szolgáltatások hogyan biztosítanak redundancialehetőségeket:

• Azure-alkalmazás szolgáltatás lehetővé teszi az alkalmazás több példányának futtatását, hogy az alkalmazás akkor is elérhető maradjon, ha egy példány meghibásodik. Ha engedélyezi a zónaredundanciát, ezek a példányok a használt Azure-régió több rendelkezésre állási zónájában is el vannak osztva.
• Az Azure Storage legalább háromszor automatikusan replikálja az adatokat. Ezeket a replikákat eloszthatja a rendelkezésre állási zónák között a zónaredundáns tárolás (ZRS) engedélyezésével, és számos régióban georedundáns tárolással (GRS) is replikálhatja a tárolási adatokat a régiók között.
• Az Azure SQL Database több replikával is rendelkezik, így az adatok akkor is elérhetők maradnak, ha egy replika meghibásodik.

A redundanciával kapcsolatos további információkért tekintse meg a redundancia tervezésére vonatkozó javaslatokat, valamint a rendelkezésre állási zónák és régiók használatára vonatkozó javaslatokat.

Méretezhetőség és rugalmasság

A skálázhatóság és a rugalmasság a rendszer azon képessége, hogy kezelni tudja a megnövekedett terhelést erőforrások hozzáadásával és eltávolításával (méretezhetőség), és ezt a követelmények változásával (rugalmasság) gyorsan elvégezheti. A méretezhetőség és a rugalmasság segíthet a rendszernek fenntartani a rendelkezésre állást a csúcsterhelések során.

Számos Azure-szolgáltatás támogatja a méretezhetőséget. Íme néhány példa:

• Az Azure Virtual Machine Scale Sets, az Azure API Management és számos más szolgáltatás támogatja az Azure Monitor automatikus skálázását. Az Azure Monitor automatikus skálázásával olyan szabályzatokat adhat meg, mint a "ha a processzorom következetesen 80% fölé megy, adjon hozzá egy másik példányt".
• Az Azure Functions dinamikusan kiépítheti a példányokat a kérések kiszolgálásához.
• Az Azure Cosmos DB támogatja az automatikus skálázás átviteli sebességét, ahol a szolgáltatás automatikusan kezelheti az adatbázisokhoz rendelt erőforrásokat az Ön által megadott szabályzatok alapján.

A méretezhetőség kulcsfontosságú tényező a részleges vagy teljes hibás működés során. Ha egy replika vagy számítási példány nem érhető el, előfordulhat, hogy a többi összetevőnek nagyobb terhelést kell viselnie a hibás csomópont által korábban kezelt terhelés kezeléséhez. Fontolja meg a túlméretezést , ha a rendszer nem tud elég gyorsan méretezni a várt terhelésváltozások kezeléséhez.

A skálázható és rugalmas rendszerek tervezéséről további információt a megbízható skálázási stratégia kialakítására vonatkozó javaslatok című témakörben talál.

Nulla állásidő üzembe helyezési technikák

Az üzemelő példányok és más rendszerváltozások jelentős leállási kockázatot jelentenek. Mivel az állásidő-kockázat kihívást jelent a magas rendelkezésre állási követelmények szempontjából, fontos, hogy nulla állásidős üzembe helyezési eljárásokkal végezze el a frissítéseket és a konfigurációs módosításokat a szükséges állásidő nélkül.

A leállási idő nélküli üzembe helyezési technikák a következők lehetnek:

• Az erőforrások egy részhalmazának frissítése egyszerre.
• Az új üzembe helyezést elérő forgalom mennyiségének szabályozása.
• Monitorozás a felhasználókra vagy a rendszerre gyakorolt bármilyen hatás esetén.
• Gyorsan elháríthatja a problémát, például egy korábbi, jól ismert üzembe helyezésre való visszalépéssel.

A leállási idő nélküli üzembe helyezési technikákkal kapcsolatos további információkért tekintse meg a biztonságos üzembehelyezési eljárásokat.

Maga az Azure nulla állásidős üzembe helyezési módszereket használ a saját szolgáltatásainkhoz. Ha saját alkalmazásokat készít, különböző megközelítésekkel, például a következő módszerekkel alkalmazhat leállási idő nélküli üzembe helyezéseket:

• Az Azure Container Apps az alkalmazás több változatát is biztosítja, amelyek a nulla állásidős üzemelő példányok elérésére használhatók.
• Az Azure Kubernetes Service (AKS) számos zéró állásidős üzembe helyezési technikát támogat.

Bár a nulla állásidős üzemelő példányokat gyakran társítják az alkalmazástelepítésekhez, a konfigurációs módosításokhoz is használni kell őket. Az alábbiakban néhány módszert talál a konfigurációs módosítások biztonságos alkalmazására:

• Az Azure Storage lehetővé teszi a tárfiók hozzáférési kulcsának több fázisban történő módosítását, ami megakadályozza az állásidőt a kulcsforgatási műveletek során.
• Azure-alkalmazás Konfiguráció funkciójelzőket, pillanatképeket és egyéb képességeket biztosít a konfigurációmódosítások alkalmazásának szabályozásához.

Ha úgy dönt, hogy nem valósít meg leállási idő nélküli üzemelő példányokat, győződjön meg arról, hogy karbantartási időszakokat határoz meg, hogy rendszermódosításokat hajtson végre a felhasználók által elvárt időpontban.

Automatizált tesztelés

Fontos tesztelni, hogy a megoldás képes-e ellenállni azoknak a kimaradásoknak és hibáknak, amelyeket a HA hatókörének tekint. Ezek közül a hibák közül sok szimulálható tesztkörnyezetekben. A megoldás különböző hibatípusokból való automatikus elviselésének vagy helyreállításának tesztelését káosz-tervezésnek nevezzük. A káosztervezés kritikus fontosságú az érett szervezetek számára, amelyek szigorú szabványokat használnak a HA-hoz. Az Azure Chaos Studio egy káoszmérnöki eszköz, amely képes szimulálni néhány gyakori hibatípust.

További információkért tekintse meg a megbízhatósági tesztelési stratégia tervezésére vonatkozó javaslatokat.

Figyelés és riasztás

A monitorozás akkor is tájékoztatja a rendszer állapotáról, ha automatizált kockázatcsökkentésre kerül sor. A monitorozás kritikus fontosságú a megoldás működésének megértéséhez, valamint a hibák korai jeleinek, például a megnövekedett hibaarányok vagy a magas erőforrás-felhasználás figyeléséhez. Riasztásokkal proaktív módon fogadhat fontos változásokat a környezetben.

Az Azure számos monitorozási és riasztási funkciót kínál, többek között a következőket:

• Az Azure Monitor naplókat és metrikákat gyűjt az Azure-erőforrásokból és -alkalmazásokból, és riasztásokat küldhet, és adatokat jeleníthet meg az irányítópultokon.
• Az Azure Monitor Application Insights az alkalmazások részletes monitorozását biztosítja.
• Az Azure Service Health és az Azure Resource Health monitorozza az Azure-platform és az erőforrások állapotát.
• Az ütemezett események azt tanácsolják, hogy mikor terveznek karbantartást a virtuális gépeken.

További információ: Javaslatok megbízható figyelési és riasztási stratégia kialakításához.

Vészhelyreállítás

A katasztrófa egy különálló, nem gyakori, jelentős esemény, amelynek nagyobb és tartósabb hatása van, mint egy alkalmazás, a kialakítás magas rendelkezésre állásával mérsékelhető. Példák a katasztrófákra:

• Természeti katasztrófák, például hurrikánok, földrengések, árvizek vagy tüzek.
• Az olyan emberi hibák, amelyek jelentős hatással vannak, például az éles adatok véletlen törlése, vagy egy hibásan konfigurált tűzfal, amely bizalmas adatokat tesz elérhetővé.
• Jelentős biztonsági incidensek, például szolgáltatásmegtagadás vagy zsarolóprogram-támadások, amelyek adatsérüléshez, adatvesztéshez vagy szolgáltatáskimaradáshoz vezetnek.

A vészhelyreállítás az ilyen helyzetekre való reagálás tervezéséről szól.

Vészhelyreállítási követelmények

A vészesemények ritkasága és súlyossága miatt a dr. Számos szervezet elfogadja azt a tényt, hogy katasztrófahelyzetben elkerülhetetlen bizonyos szintű állásidő vagy adatvesztés. A teljes DR-tervnek az alábbi kritikus üzleti követelményeket kell megadnia az egyes folyamatokhoz:

• A helyreállítási pont célkitűzése (RPO) az elfogadható adatvesztés maximális időtartama katasztrófa esetén. Az RPO-t időegységekben mérik, például "30 percnyi adat" vagy "négy órányi adat".

• A helyreállítási idő célkitűzése (RTO) az elfogadható állásidő maximális időtartama katasztrófa esetén, ahol az "állásidőt" az Ön specifikációja határozza meg. Az RTO mérése időegységekben is történik, például "nyolc óra állásidő".

A számítási feladat minden egyes összetevője vagy folyamata egyedi RPO- és RTO-értékekkel rendelkezhet. A követelmények meghatározásakor vizsgálja meg a vészforgatókönyv-kockázatokat és a lehetséges helyreállítási stratégiákat. Az RPO és az RTO meghatározásának folyamata hatékonyan létrehozza a számítási feladatra vonatkozó dr. követelményeket az egyedi üzleti problémák (költségek, hatás, adatvesztés stb.) eredményeként.

Vészhelyreállítási tervek

A katasztrófa okától függetlenül fontos, hogy egy jól definiált és tesztelhető DR-tervet hozzon létre. Ez a terv az infrastruktúra és az alkalmazástervezés részeként lesz felhasználva annak aktív támogatásához. Több DR-csomagot is létrehozhat különböző helyzetekhez. A DR-tervek gyakran folyamatvezérlőkre és manuális beavatkozásra támaszkodnak.

A DR nem az Azure automatikus funkciója. Számos szolgáltatás azonban olyan funkciókat és képességeket biztosít, amelyekkel támogathatja a DR-stratégiákat. Tekintse át az egyes Azure-szolgáltatások megbízhatósági útmutatóit a szolgáltatás működésének és képességeinek megismeréséhez, majd ezeket a képességeket a DR-csomaghoz rendelje.

Az alábbi szakaszok felsorolják a vészhelyreállítási terv néhány gyakori elemét, és ismertetik, hogy az Azure hogyan segíthet ezek elérésében.

Feladatátvétel és feladat-visszavétel

Egyes vészhelyreállítási tervek egy másodlagos üzembe helyezés kiépítését foglalják magukban egy másik helyen. Ha egy katasztrófa hatással van a megoldás elsődleges üzembe helyezésére, akkor a forgalom feladatátvételt végezhet a másik helyre. A feladatátvétel gondos tervezést és megvalósítást igényel. Az Azure számos szolgáltatást kínál a feladatátvételhez, például:

• Az Azure Site Recovery automatizált feladatátvételt biztosít a helyszíni környezetekhez és a virtuális gépek által üzemeltetett megoldásokhoz az Azure-ban.
• Az Azure Front Door és az Azure Traffic Manager támogatja a bejövő forgalom automatikus feladatátvételét a megoldás különböző üzemelő példányai között, például különböző régiókban.

A feladatátvételi folyamat általában némi időt vesz igénybe annak észleléséhez, hogy az elsődleges példány meghiúsult, és a másodlagos példányra kell váltani. Győződjön meg arról, hogy a számítási feladat RTO-ja igazodik a feladatátvételi időhez.

Fontos megfontolni a feladat-visszavételt is, amely az a folyamat, amellyel visszaállítja a műveleteket az elsődleges régióban a helyreállítás után. A feladat-visszavétel tervezése és megvalósítása összetett lehet. Előfordulhat például, hogy az elsődleges régió adatai a feladatátvétel megkezdése után lettek megírva. Körültekintő üzleti döntéseket kell hoznia az adatok kezeléséről.

Biztonsági másolatok

A biztonsági mentések magukban foglalják az adatok másolatának felvételét és biztonságos tárolását egy meghatározott ideig. Biztonsági másolatokkal helyreállíthatja a vészhelyreállítást, ha az automatikus feladatátvétel nem lehetséges egy másik replikára, vagy ha adatsérülés történt.

Ha biztonsági mentéseket használ vészhelyreállítási terv részeként, fontos figyelembe venni a következőket:

• Tárolási hely. Ha vészhelyreállítási terv részeként használ biztonsági mentéseket, azokat külön kell tárolni a fő adatokhoz. A biztonsági mentések általában egy másik Azure-régióban vannak tárolva.

• Adatvesztés. Mivel a biztonsági mentéseket általában ritkán készítik el, a biztonsági mentés visszaállítása általában adatvesztéssel jár. Ezért a biztonsági mentési helyreállítást végső megoldásként kell használni, és egy vészhelyreállítási tervnek meg kell adnia a biztonsági másolatból való visszaállítás előtt végrehajtott lépések és helyreállítási kísérletek sorrendjét. Fontos meggyőződni arról, hogy a számítási feladat RPO-ja igazodik a biztonsági mentési időközhöz.

• Helyreállítási idő. A biztonsági mentések visszaállítása gyakran időt vesz igénybe, ezért kritikus fontosságú a biztonsági másolatok és a visszaállítási folyamatok tesztelése, hogy ellenőrizze az integritásukat, és megértse, mennyi ideig tart a visszaállítási folyamat. Győződjön meg arról, hogy a számítási feladat RTO-fiókjai a biztonsági mentés visszaállításához szükséges ideig tart.

Számos Azure-adat- és tárolási szolgáltatás támogatja a biztonsági mentéseket, például a következőket:

• Az Azure Backup automatizált biztonsági mentéseket biztosít virtuálisgép-lemezekhez, tárfiókokhoz, AKS-hez és számos más forráshoz.
• Számos Azure-adatbázis-szolgáltatás, köztük az Azure SQL Database és az Azure Cosmos DB automatikus biztonsági mentési képességgel rendelkezik az adatbázisokhoz.
• Az Azure Key Vault olyan funkciókat biztosít, amelyekkel biztonsági másolatot készíthet a titkos kulcsokról, tanúsítványokról és kulcsokról.

Automatizált üzembe helyezés

A szükséges erőforrások vész esetén történő gyors üzembe helyezéséhez és konfigurálásához használja az infrastruktúra kód (IaC) eszközeit, például Bicep-fájlokat, ARM-sablonokat vagy Terraform-konfigurációs fájlt. Az IaC használata csökkenti a helyreállítási időt és a hibalehetőségeket az erőforrások manuális üzembe helyezéséhez és konfigurálásához képest.

Tesztelés és próbák

Kritikus fontosságú a DR-tervek rutinszerű ellenőrzése és tesztelése, valamint a szélesebb körű megbízhatósági stratégia. Vegye fel az összes emberi folyamatot a gyakorlatokba, és ne csak a technikai folyamatokra összpontosítson.

Ha még nem tesztelte a helyreállítási folyamatokat egy vészszimulációban, nagyobb valószínűséggel szembesül a súlyos problémákkal, amikor tényleges katasztrófa esetén használja őket. Emellett a DR-tervek és a szükséges folyamatok tesztelésével ellenőrizheti az RTO megvalósíthatóságát.

További információkért tekintse meg a megbízhatósági tesztelési stratégia tervezésére vonatkozó javaslatokat.

Kapcsolódó tartalom

• Az Azure szolgáltatás megbízhatósági útmutatói segítségével megismerheti, hogy az egyes Azure-szolgáltatások hogyan támogatják a megbízhatóságot a kialakításában, és megismerheti azokat a képességeket, amelyek a HA- és DR-csomagokba építhetők.
• Az Azure Well-Architected Framework: Megbízhatósági pillérrel többet tudhat meg arról, hogyan tervezhet megbízható számítási feladatokat az Azure-ban.
• Az Azure-szolgáltatások jól felépítésű keretrendszerével többet tudhat meg arról, hogyan konfigurálhatja az egyes Azure-szolgáltatásokat úgy, hogy megfeleljenek a megbízhatósági követelményeknek, valamint a jól felépítésű keretrendszer többi alappillére között.
• A vészhelyreállítás tervezésével kapcsolatos további információkért tekintse meg a vészhelyreállítási stratégia tervezésére vonatkozó javaslatokat.