DR az Azure Data Platformhoz – Javaslatok

A levont következtetések

1. Győződjön meg arról, hogy az összes érintett fél tisztában van a magas rendelkezésre állás (HA) és a vészhelyreállítás (DR) közötti különbséggel: gyakori buktató a két fogalom összekeverése és a hozzájuk kapcsolódó megoldások eltérése
2. Beszélje meg az üzleti érdekelt felekkel a helyreállítási pont célkitűzéseinek (RRP-k) és a helyreállítási idő célkitűzéseinek (RTO-k) meghatározására vonatkozó elvárásaikat:
   1. Mennyi állásidőt tudnak tolerálni, szem előtt tartva, hogy általában minél gyorsabb a helyreállítás, annál magasabb a költség
   2. Azoknak az incidenseknek a típusa, amelyektől védelmet szeretnének biztosítani, megemlítve az ilyen esemény kapcsolódó valószínűségét. Egy kiszolgáló leállásának valószínűsége például nagyobb, mint egy természeti katasztrófa, amely egy régió összes adatközpontját érinti
   3. Milyen hatással van a nem elérhető rendszer az üzletmenetére?
   4. A megoldás opex költségvetése előrehaladtával
3. Gondolja át, milyen csökkentett szolgáltatási lehetőségeket fogadhatnak el a végfelhasználók. Ezek a következők lehetnek:
   1. Továbbra is hozzáférhet a vizualizációs irányítópultokhoz a legfrissebb adatok nélkül is, vagyis ha a betöltési folyamatok nem működnek, a végfelhasználók továbbra is hozzáférhetnek az adataikhoz
   2. Olvasási hozzáférés, írási hozzáférés nélkül
4. A cél RTO- és RPO-metrikák meg tudják határozni, hogy milyen vészhelyreállítási stratégiát szeretne megvalósítani:
   1. Aktív/aktív
   2. Aktív/passzív
   3. Aktív/ismételt üzembe helyezés katasztrófa esetén
   4. Támaszkodhat a Microsoft szolgáltatásiszint-szerződésére (SLA)
5. Győződjön meg arról, hogy ismeri az összes olyan összetevőt, amely befolyásolhatja a rendszerek rendelkezésre állását, például:
   1. Identitáskezelés
   2. Hálózati topológia
   3. Titkos kulcsok/kulcsok kezelése
   4. Adatforrások
   5. Automatizálás/feladatütemező
   6. Forrásadattár és üzembehelyezési folyamatok (GitHub, Azure DevOps)
6. A kimaradások korai észlelése az RTO- és RPO-értékek jelentős csökkentésének is módja. Az alábbiakban néhány szempontot érdemes figyelembe venni:
   1. Határozza meg, hogy mi az a kimaradás, és hogyan képezheti le a Microsoft a kimaradás definícióját. A Microsoft-definíció az Azure szolgáltatásiszint-szerződés oldalán érhető el termék- vagy szolgáltatásszinten.
   2. Egy hatékony monitorozási és riasztási rendszer elszámoltatható csapatokkal, amelyek időben áttekintik ezeket a metrikákat és riasztásokat, segítenek megfelelni a célnak
7. Az összetett SLA-k azt jelentik, hogy minél több összetevővel rendelkezik az architektúrában, annál nagyobb a meghibásodás valószínűsége. Az összetett SLA-val meghatározhatja az összetevők kimaradásának esélyét.
8. Az előfizetés kialakítását illetően a vészhelyreállítás további infrastruktúrája az eredeti előfizetésben tárolható. A Szolgáltatásként (PaaS) nyújtott szolgáltatások, például az ADLS Gen2 vagy az Azure Data Factory általában natív funkciókkal rendelkeznek, amelyek lehetővé teszik a feladatátvételt más régiókban lévő másodlagos példányokra, miközben az eredeti előfizetésben maradnak. Előfordulhat, hogy egyes ügyfeleknek érdemes megfontolniuk egy dedikált erőforráscsoport használatát az erőforrásokhoz, amelyeket csak a dr. forgatókönyvekben használnak költségcélokra
   1. Meg kell jegyezni, hogy az előfizetési korlátok kényszerként szolgálhatnak ehhez a megközelítéshez
   2. Egyéb korlátozások lehetnek a tervezési összetettség és a felügyeleti vezérlők, amelyek biztosítják, hogy a DR-erőforráscsoportok ne legyenek használatban a BAU-munkafolyamatokhoz
9. A DR munkafolyamat megtervezése a megoldás kritikussága és függőségei alapján. Például ne próbálja újraépíteni az Azure Analysis Services-példányt, mielőtt az adattárháza üzembe lenne állítva, mert az hibát fog kiváltani. Hagyja a fejlesztési tesztkörnyezeteket a folyamat későbbi szakaszában, és először állítsa helyre az alapvető vállalati megoldásokat
10. Próbálja meg azonosítani a megoldásokkal párhuzamos helyreállítási feladatokat, csökkentve a teljes RTO-t
11. Ha az Azure Data Factoryt egy megoldásban használják, ne felejtse el a saját üzemeltetésű integrációs modulokat is belefoglalni a hatókörbe. Az Azure Site Recovery ideális ezekhez a gépekhez
12. A manuális műveleteket a lehető legnagyobb mértékben automatizálni kell az emberi hibák elkerülése érdekében, különösen nyomás alatt. Javasoljuk, hogy:
    1. Erőforrás-kiépítés bevezetése Bicep-, ARM-sablonok vagy PowerShell-szkriptek használatával
    2. A forráskód és az erőforráskonfiguráció verziószámozásának bevezetése
    3. Ci/CD kiadási folyamatok használata kattintási műveletek helyett
13. Mivel rendelkezik feladatátvételi tervvel, érdemes megfontolnia az elsődleges példányokra való visszalépés eljárásait
14. Adjon meg egyértelmű mutatókat/metrikákat annak ellenőrzéséhez, hogy a feladatátvétel sikeres volt-e, és hogy a megoldások működnek-e, vagy hogy a helyzet visszaáll-e a normál állapotra (más néven elsődleges funkcionális)
15. Döntse el, hogy az SLA-k a feladatátvétel után is változatlanok maradnak-e, vagy engedélyezi-e a csökkentett teljesítményű szolgáltatást
    1. Ez a döntés nagyban függ a támogatott üzleti szolgáltatási folyamattól. Egy szobafoglalási rendszer feladatátvétele például sokkal másképp fog kinézni, mint egy központi üzemeltetési rendszer
16. Az RTO-/RPO-definícióknak nem az infrastruktúra szintjén, hanem konkrét felhasználói forgatókönyveken/megoldásokon kell alapulniuk. Részletesebb képet ad arról, hogy milyen folyamatokat és összetevőket kell először helyreállítani, ha kimaradás vagy katasztrófa történik
17. Győződjön meg arról, hogy a feladatátvétel előtt a célrégióba is be kell vonnia a kapacitás-ellenőrzéseket: Ha súlyos katasztrófa történik, vegye figyelembe, hogy sok ügyfél egyszerre próbál meg feladatátvételt végrehajtani ugyanarra a párosított régióra, ami késést vagy versengést okozhat az erőforrások kiépítésében
    1. Ha ezek a kockázatok elfogadhatatlanok, aktív/aktív vagy aktív/passzív DR stratégiát kell figyelembe venni
18. Létre kell hozni és karbantartani kell egy vészhelyreállítási tervet a helyreállítási folyamat és a művelettulajdonosok dokumentálásához. Vegye figyelembe azt is, hogy az emberek szabadságon vannak, ezért ügyeljen arra, hogy másodlagos névjegyeket is tartalmazzon
19. Rendszeres vészhelyreállítási próbákat kell végrehajtani a DR-terv munkafolyamatának ellenőrzéséhez, a szükséges RTO/RPO-nak való teljesítéséhez, valamint a felelős csapatok betanítása érdekében
    1. Az adatokat és a konfigurációs biztonsági mentéseket is rendszeresen tesztelni kell annak biztosítása érdekében, hogy a helyreállítási tevékenységek támogatására "alkalmasak legyenek".
20. A hálózatkezelésért, identitáskezelésért és erőforrás-kiépítésért felelős csapatokkal való korai együttműködés lehetővé teszi a legoptimálisabb megoldással kapcsolatos megállapodást:
    1. Felhasználók és forgalom átirányítása az elsődleges webhelyről a másodlagos helyre. Az olyan fogalmak, mint a DNS-átirányítás vagy az azure Traffic Managerhez hasonló konkrét eszközök használata kiértékelhetők
    2. A másodlagos helyhez való hozzáférés és jogok biztosítása időben és biztonságosan
21. Katasztrófa esetén a sok érintett fél közötti hatékony kommunikáció kulcsfontosságú a terv hatékony és gyors végrehajtásához:
    1. Döntéshozók
    2. Incidenskezelési csapat
    3. Érintett belső célközönség
    4. Külső csapatok
22. A különböző erőforrások megfelelő időben történő vezénylése biztosítja a vészhelyreállítási terv végrehajtásának hatékonyságát

Megfontolások

Antipatterns

• A cikksorozat másolása/beillesztése Ez a cikksorozat útmutatást nyújt azoknak az ügyfeleknek, akik egy Azure-specifikus dr. folyamat következő részletességi szintjét keresik. Ezért az általános Microsoft IP-címeken és referenciaarchitektúrákon alapul, nem pedig egyetlen ügyfélspecifikus Azure-implementáción.

Bár a megadott részletek elősegítik a szilárd alapszintű megértést, az ügyfeleknek saját konkrét környezetüket, megvalósításukat és követelményeiket kell alkalmazniuk, mielőtt "célhoz illő" DR-stratégiát és folyamatot kapnak.

• A dr. csak tech-only folyamatként való kezelése az üzleti érdekelt feleknek kritikus szerepet játszik a dr. folyamat követelményeinek meghatározásában és a szolgáltatás helyreállításának megerősítéséhez szükséges üzleti érvényesítési lépések végrehajtásában. Annak biztosítása, hogy az üzleti érdekelt felek minden dr. tevékenységben részt vegyenek, egy olyan dr. folyamatot biztosít, amely "célnak megfelelő", üzleti értéket képvisel, és végrehajtható.

• A "Set and forget" DR-tervek az Azure folyamatosan fejlődnek, ahogy az egyes ügyfelek különböző összetevők és szolgáltatások használata is. A "célnak megfelelő" DR-folyamatnak velük együtt kell fejlődnie. Az SDLC-folyamaton vagy rendszeres felülvizsgálatokon keresztül az ügyfeleknek rendszeresen újra meg kell tekinteniük a DR-tervüket. A cél a szolgáltatás-helyreállítási terv érvényességének biztosítása, valamint az összetevők, szolgáltatások vagy megoldások közötti eltérések számba vétele.

• Papíralapú értékelések Bár egy dr. esemény teljes körű szimulációja nehéz lesz egy modern adat-ökorendszerben, erőfeszítéseket kell tenni annak érdekében, hogy a lehető legközelebb kerüljön egy teljes szimulációhoz az érintett összetevők között. A rendszeresen ütemezett fúrók felépítik a szervezet által igényelt "izommemória"-t, hogy magabiztosan végrehajthassák a DR-tervet.

• Ha a Microsoftra támaszkodik, hogy mindezt a Microsoft Azure-szolgáltatásokon belül végezze el, egyértelmű felelősségi felosztás áll fenn, amelyet a használt felhőszolgáltatási szint rögzít: Még akkor is, ha teljes körű szolgáltatásként (SaaS-) vermet használnak, az ügyfél továbbra is fenntartja a felelősséget annak biztosítása érdekében, hogy a fiókok, identitások és adatok helyesek/naprakészek legyenek, valamint az Azure-szolgáltatásokkal való interakcióhoz használt eszközökkel együtt.

Esemény hatóköre és stratégiája

Vészesemény hatóköre

A különböző eseményeknek eltérő hatásuk lesz, és ezért más a válaszuk. Az alábbi ábra ezt egy katasztrófaesemény esetében szemlélteti:

Vészstratégiai lehetőségek

A vészhelyreállítási stratégia négy magas szintű lehetőséget kínál:

• Várja meg a Microsoftot – Ahogy a neve is sugallja, a megoldás offline állapotban van, amíg a Microsoft nem állítja helyre az érintett régió szolgáltatásainak teljes helyreállítását. A helyreállítás után a megoldást az ügyfél érvényesíti, majd naprakészen hozza létre a szolgáltatás-helyreállítást
• Vészhelyreállítás – A megoldás manuális újratelepítése egy elérhető régióba a katasztrófa utáni eseményektől kezdve
• Meleg tartalék (aktív/passzív) – Másodlagos üzemeltetett megoldás jön létre egy másik régióban, és az összetevők a minimális kapacitás garantálása érdekében vannak üzembe helyezve; az összetevők azonban nem fogadják az éles forgalmat. Az alternatív régió másodlagos szolgáltatásai "ki lesznek kapcsolva" vagy alacsonyabb teljesítményszinten futnak, amíg dr.
• Gyakori elérésű tartalék (aktív/aktív) – A megoldás egy aktív/aktív beállításban található több régióban. A másodlagos üzemeltetett megoldás a nagyobb rendszer részeként fogadja, dolgozza fel és szolgálja ki az adatokat

A dr. stratégia hatásai

Bár a magasabb szolgáltatási rugalmassághoz rendelt üzemeltetési költségek gyakran a dr. stratégia kulcstervezési döntését (KDD) uralják. Vannak más fontos szempontok is.

A bevált példa dr. forgatókönyve egy teljes Azure-beli regionális kimaradás, amely közvetlenül érinti a Contoso Data Platformot üzemeltető elsődleges régiót. Ebben a kimaradási forgatókönyvben a négy magas szintű dr. stratégiára gyakorolt relatív hatás a következő:

Besorolási kulcs

• Helyreállítási idő célkitűzése (RTO) – a vészeseménytől a platformszolgáltatás helyreállításáig eltelt idő
• A végrehajtás összetettsége – a szervezet összetettsége a helyreállítási tevékenységek végrehajtásához
• A megvalósítás összetettsége – a szervezet összetettsége a DR stratégia implementálásához
• Az ügyfelekre gyakorolt hatás – az adatplatform-szolgáltatás ügyfeleire gyakorolt közvetlen hatás a DR stratégiából
• A fenti OPEX-költség – a stratégia implementálásától várható többletköltség, például az Azure havi számlázásának növelése további összetevők és a támogatáshoz szükséges további erőforrások esetében

Következő lépések

Most, hogy megismerte a forgatókönyvre vonatkozó javaslatokat, megtudhatja, hogyan helyezheti üzembe ezt a forgatókönyvet

Kapcsolódó erőforrások

• DR az Azure Data Platformhoz – Áttekintés
• DR az Azure Data Platformhoz – Architektúra
• DR az Azure Data Platformhoz – Forgatókönyv részletei
• DR az Azure Data Platformhoz – Összefoglalás