Vészhelyreállítási szolgáltatások

Befejeződött

Az adatok biztonsági másolatainak visszaállítása nyilvánvaló okokból a biztonsági mentési szolgáltatások szabványos funkciója. A katasztrófák hatása azonban nem korlátozódik az adatvesztésre. Egy olyan kiesés, amely megakadályozza a vállalat valódi vagy virtuális, helyszíni vagy felhőbeli kiszolgálóinak elérését, káros – olykor akár katasztrofális – következményekkel jár a vállalatra nézve. A vészhelyreállítási (DR) szolgáltatás szerepe, hogy ne csak az adatok és az egyes erőforrások, hanem teljes rendszerek biztonsági másolatát biztosítsa, hogy amikor egy ilyen rendszer leáll vagy a kapcsolata megszakad, a szolgáltatás fenntartható legyen a forgalomnak a terhelés átvételére készen álló replikákra irányításával.

A vészhelyreállítás az a terület, ahol a nyilvános felhő valódi haszna megmutatkozik. Sokkal több, mint egy hatalmas szalagos meghajtó. Mivel a felhőbeli erőforrások virtuálisak, a replikáik egy pillanat alatt elindíthatók, hogy átvegyék a váratlanul eltűnő erőforrások helyét. A replikák akár a világ különböző pontjain is üzemeltethetők, a tükrözött rendszertől távol, hogy elkerüljék az egész területeket érintő kimaradásokat. A fizikai informatikai rendszerek fizikai replikáinak (földrajzilag távoli helyeken való) fenntartásával járó költséghez viszonyítva nyilvánvalóvá válik a felhő értéke a rendszerfolytonosság fenntartásában.

A piacvezető felhőszolgáltatók szolgáltatásként nyújtott vészhelyreállítást (DRaaS) is kínálnak, de ezeket a szolgáltatásokat nagyon gondosan kell megtervezni és konfigurálni ahhoz, hogy az ügyfél által kívánt feladatátvételi támogatást nyújtsák. Éppen ezért először az ilyen tervek készítésekor figyelembe veendő célkitűzéseket és metrikákat vizsgáljuk meg.

Célkitűzések és metrikák

Katasztrófa esetén a vállalatok és ügyfeleik egyidejűleg a digitális összetevők több kategóriájához való hozzáférést is elveszíthetik. A legfontosabbak a következők:

  • Adatbázisok és adattárak, amelyek az ügyfelekkel és a termékekkel és/vagy szolgáltatásokkal kapcsolatos kulcsfontosságú információk nyilvántartása mellett az üzleti tranzakciók és folyamatok aktív állapotát is fenntartják az egész vállalat számára

  • Tömeges adatok, köztük dokumentumok, multimédia-fájlok és más rögzített adatok, amelyek az emberek által használt alkalmazások termékei

  • Kommunikáció és kapcsolattartás emberekkel és üzleti szolgáltatásokkal, amelyen minden folyamatban lévő üzleti tevékenység sikere múlik

  • Alkalmazások, amelyek a vállalat ügyfelek, partnerek és a saját érdekeltek felé mutatott arculatát alkotják

Bár a vészhelyreállítás egyetlen szolgáltatásként jelenik meg az ügyfelek számára, az egyes kategóriák helyreállításának folyamatai elkülönülnek egymástól. Az ügyfél/kiszolgáló rendszerek korában sok vállalat személyi számítógépeken bonyolította mindennapi üzleti tevékenységét. Ha egy PC leállt, és rendelkezésre állt a PC helyi tárterületének biztonságimásolat-képfájlja, elméletileg helyreállítható volt egy másik PC-n, és folytatódhatott a munka. Az első hálózatba kötött, LAN-képes operációs rendszerekkel és Ethernet-kábelekkel összekapcsolt PC-k megjelenése után egy hálózat összes személyi számítógépe helyreállítható lett egy mentett lemezképből, így maga a hálózat vált ismét működőképessé.

A felhő nem így működik. Még a vállalati alkalmazások kiszolgálójaként szolgáló virtuális gépek sem tartalmazzák teljes egészben az általuk végzett munka bármelyik részét. A biztonsági mentési szolgáltatások védőhálót biztosítanak a tömeges adatok, és bizonyos mértékig a tranzakciós adatok és adatbázisok számára is. Azonban ezen entitások mindegyike önmaga összetevője, ezért katasztrófa esetén az üzleti funkciók helyreállításához az összes összetevő szinte valamennyi funkcióját helyre kell állítani egy biztonságos és védett helyről.

A vészhelyreállítási folyamat tehát az összes végrehajtott eljárás összehangolását követeli meg a vállalat teljes működőképességének helyreállításához. Ráadásul az ebben az időszakban végzett üzleti tevékenység szerepe még kritikusabb, éppen a katasztrófa miatt. Egy olyan esemény, amely képes volt leállítani a kritikus szerepű infrastruktúrát, feltehetően a vállalat más üzemi területeit – a raktározást, szállítást, gyártást, és kézbesítést – is károsította. A helyreállított üzlet valószínűleg nem tudja zökkenőmentesen folytatni a katasztrófa előtti üzletvitelt.

Ami ezeket az eljárásokat összefogja, az a közös, egyértelműen definiált szolgáltatásiszint-célkitűzések megléte. Az AWS, az Azure, valamint a Google Cloudra épülő külső szolgáltatások vészhelyreállítási szolgáltatásai az alábbiakat veszik figyelembe:

  • Helyreállításipont-célkitűzés (RPO) – Az a minimális adatmennyiség, amelyet a ügyfeleknek vissza kell nyerniük ahhoz, hogy a mentett összetevőkre alapuló szolgáltatás helyreállítottnak minősüljön. Más szemszögből ez a mennyiség megadható a maximális elfogadható adatvesztésként, a 100-ból kivont százalékos aránnyal kifejezve.

  • Helyreállítási idő célkitűzése (RTO) – Az a maximális időtartam, amely alatt a helyreállítási folyamatnak be kell fejeződnie. Ez megfogalmazható úgy is, mint a vállalat által elfogadott állásidő mértéke.

  • Megőrzési időtartam – A biztonságimásolat-készletek megőrzésének maximálisan megengedett időtartama, melynek lejárta után azokat frissíteni és cserélni kell.

Az RTO és az RPO egymással ellentétben és egyensúlyban képzelhető el, az ügyfél például dönthet úgy, hogy vállalja a hosszabb helyreállítási időt a közelebbi helyreállítási pont (nagyobb RPO) elérése érdekében. Ha a rendelkezésre álló sávszélesség vagy az állásidővel járó kockázat miatt a helyreállítási idő fontos az ügyfél számára, akkor nem feltétlenül lehet magas RPO-t elérni.

A hivatásos kockázati vagy üzletfolytonossági tanácsadók szinte biztosan ragaszkodnak ennek a három változónak a figyelembe vételéhez egy vészhelyreállítási szabályzat kidolgozása során. Az RTO és az RPO központi szerepet kap az üzleti hatás elemzési (BIA) jelentések nagy többségében. Mindkettő kulcsfontosságú változó a tanácsadó számára a katasztrófák következtében lehetséges veszteségek felbecsüléséhez. Egyes tanácsadók egy szolgáltatásiszint-célkitűzés (SLO) nevű összesített változót használnak, de az SLO-t meghatározó egyetlen képlet még kidolgozásra vár. Az a tény, hogy a felhőszolgáltatók a kockázatelemzők által már ismert és jól értett fogalmakkal tudják megadni a szolgáltatási szinteket, megkönnyíti a két fél együttműködését – márpedig a vészhelyreállítási szolgáltatót választó vállalatok gyakran ez alapján hozzák meg a végső döntést.

Módszertanok és eljárások

Az előző lecke bemutatta az informatikai rendszerek helyreállításának legalapvetőbb formáját, amely a kapcsolódó fájlok, tárkötetek és virtuálisgép-lemezképek biztonsági másolatait használja. Bár ez továbbra is szerepel a vészhelyreállítási szolgáltatások kínálatában, a gyakorlatban egyre kevesebb vállalatnál van használatban, elsősorban azért, mert az RTO-célkitűzések nem tarthatók be megfelelően.

A professzionális vészhelyreállítási szolgáltatások többféle üzembe helyezési és felügyeleti módszertant kínálnak, amelyek egy része a szolgáltatások katasztrófát megelőző karbantartására is kiterjed. Ezeket a módszereket összegezzük az alábbiakban. Mindhárom az előző leckében ismertetett biztonsági mentési lehetőségekre épül, és valamennyi szolgáltatóra egyformán érvényesek. Az ezen helyreállítási módok egyikét alkalmazni kívánó ügyfeleknek ki kell választaniuk az adott módhoz leginkább illő replikációt, földrajzi elhelyezést és tárolási osztályt.

Gyújtóláng

Ezzel a módszerrel (5. ábra) van hely egy teljes tartalék adatközpont számára. Itt egyes alapszolgáltatások és alkalmazások, valamint az azokat támogató adatok tarthatók fenn egy feladatátvevő fürtben, amely a katasztrófaesemény aktiválásának pillanatában „begyújtható”, többnyire automatikusan. Ezek mellett virtuális kiszolgálók vannak üzembe helyezve éppen elégséges alapszintű funkcionalitással ahhoz, hogy aktívak maradjanak, ha szükség lenne rájuk. Ezek a csökkentett funkcionalitású kiszolgálók e-mail- és webfunkciókat is elláthatnak, hogy lehetővé tegyék a kommunikációt az ügyfelekkel és a vállalaton belül. A gyújtóláng helyreállítási mód engedélyezéséhez szükség lehet a gyorsan változó adattárak, például tranzakciós adatbázisok és e-mail-kötetek folyamatos szinkronizálására.

Figure 5: The active and passive components of a Pilot Light recovery scenario.

5. ábra: A Próbafény-helyreállítási forgatókönyv aktív és passzív összetevői.

Üzemi tartalék

Ebben a 6. ábrán szemléltetett helyreállítási módban a rendszer összes szolgáltatásának és alkalmazásának folyamatosan futó replikája, valamint az összes kritikus fontosságú adat is legalább egy földrajzilag külön helyen fenn van tartva. Az aktív útválasztó egészen addig eltereli az ehhez a teljes replikához való hozzáférést, amíg a katasztrófaesemény nem aktivál egy szabályt, amely felcseréli az aktív hálózat címét a kerülő útvonaléval.

Figure 6: A Warm standby recovery scenario with some components in the standby namespace fully operational.

6. ábra: Meleg készenléti helyreállítási forgatókönyv, amelyben a készenléti névtér egyes összetevői teljesen működőképesek.

Készenléti tartalék

Ebben a forgatókönyvben (7. ábra) az összes szolgáltatás és alkalmazás legalább két replikája fut folyamatosan úgy, hogy az adatok teljesen és folyamatosan szinkronizálva vannak közöttük. Egy főútválasztó egyfajta nagybani terheléselosztóként működve, nagyjából egyenletesen osztja szét a kéréseket az összes kiszolgálóhely között. Egy katasztrófaesemény bekövetkezése egy tűzfalhoz hasonló folyamatot aktivál, amelynek során az érintett rendszer el lesz távolítva az útvonaltáblából.

Figure 7: With Hot standby, all components in the namespace of what would normally have been the reserve, standby space, are active, fully operational, and processing replicas of the primary data in real time.

7. ábra: A készenléti állapotban az elsődleges adatok replikáinak valós idejű, aktív, teljes mértékben működőképes és feldolgozása a tartalék, készenléti terület névterében lévő összes összetevő.

Felhőalapú alkalmazások

Elméletileg lehetséges, hogy egy vállalat az egyik szolgáltató vészhelyreállítási szolgáltatását egy másik szolgáltató által üzemeltetett szolgáltatásokhoz használja biztonsági hálóként. Másként fogalmazva, az informatikusok kellő odafigyelése mellett az egyik felhőszolgáltató (például a Google) infrastruktúrája feladatátvételi célként szolgálhat egy üzemi készenléti eljáráshoz, amely egy másik felhőszolgáltató (például az Azure) infrastruktúrájában van üzemeltetve. Ez a megoldás szükségessé válhat könyvelési szempontból vagy olyankor, ha egy nagyvállalat számítástechnikai erőforrásait különböző részlegek üzemeltetik a világ több pontján.

Jelenleg a tárolóba helyezett infrastruktúra jelenléte a helyszíni adatközpontban vagy a felhőben jelentősen befolyásolhatja az összes vészhelyreállítási módszert. Az úgynevezett natív felhőalapú alkalmazások, amelyeket kizárólag a nyilvános felhőplatformra, vagy azzal azonos módon működő platformra (amilyen a Microsoft Azure Stack) fejlesztettek, több tárolóreplikára osztja szét a funkcióit, amelyek egy része vagy mindegyike egyidejűleg működhet. Ezt elsősorban nem egy újfajta vészhelyreállítási forgatókönyv lehetővé tétele indokolja, hanem a számítási feladatok processzorok közötti elosztása.

A felhőalapú architektúrák egy másik jellemzője az a képesség, hogy az eleve automatikusan replikált adatbázisokhoz olyan hálózati címen lehet kapcsolódni, amely kizárólag az adott alkalmazáshoz kötődik. (Más szóval, bár az Internet Protocolot használja, a címe nem a szélesebb körű nyilvános interneten található.) Így egy katasztrófaesemény során, miközben az adatbázishoz csatolt egyes csomópontok leállhatnak, sokan megmaradnak, mások pedig a nem elérhető csomópontok helyett. Ez még nem feltétlenül minősül beépített vészhelyreállításnak, de kétségtelenül katasztrófatűrő tulajdonságnak nevezhető.

Szolgáltatásként nyújtott vészhelyreállítás (DRaaS)

A nyilvános felhőszolgáltatók szempontjából a vészhelyreállítás az alapvető biztonsági mentési és adatátviteli szolgáltatások szolgálatba állítását jelenti. A biztonsági mentési szolgáltatásokra építve a jelentős felhőszolgáltatók mindegyike más stratégiát alkalmaz a vészhelyreállítás végrehajtására.

AWS CloudEndure

A szolgáltatás-áttelepítés azt jelenti, hogy a virtuális számítási feladatokat a privát, helyszíni infrastruktúrából a nyilvános felhőinfrastruktúrába telepítik át. Ez az áttelepítés a nyilvános felhőben működő vészhelyreállítási szolgáltatások némelyike igényli, hogy a katasztrófaesemény után néhány percen belül teljesíthesse a feladatátvételre és helyreállításra vonatkozó célkitűzéseket.

2019 januárjában az Amazon megvásárolta a CloudEndure privát szolgáltatásmigrálási szolgáltatást, amely addig is az AWS-t használta infrastruktúra-szolgáltatóként. Azóta a fő szolgáltatásai közé integrálta a CloudEndure-t, és díjmentesen kínál szolgáltatásáttelepítést az Amazon ügyfeleinek. Az AWS most az üzemi vagy készenléti tartalékot használó eljárás gyors előkészítésének eszközeként alkalmazza a szolgáltatás-áttelepítést. Az AWS az áttelepítési eljárásért nem számít fel díjat az ügyfeleknek, az egyes vészhelyreállítási forgatókönyvekhez kiépített redundáns erőforrásokért viszont díjat számít fel. A felármentesség még így is rengeteg külső vészhelyreállítási szolgáltatással szemben teszi azonnal versenyképessé a CloudEndure-t.

Azure Site Recovery

A Microsoft vészhelyreállítási szolgáltatása, az Azure Site Recovery egy üzemi tartalékot használó helyreállítási módszer felügyelt üzemelő példánya virtuálisgép-alapú környezetekhez és Linux vagy Windows rendszerű fizikai (helyszíni) kiszolgálókhoz. A virtuális gépek aktívan vannak egy másodlagos régióba replikálva (8. ábra), amelybe a feladatátvétel egyetlen kattintással kezdeményezhető. Az ügyfeleknek havi díjat kell fizetnie (jelenleg körülbelül 25 usd) minden olyan kiszolgálóért vagy virtuális gépért, amelyet az Azure Site Recovery véd.

Figure 8: Failover scenario implemented using Azure Site Recovery.

8. ábra: Az Azure Site Recovery használatával implementált feladatátvételi forgatókönyv.

Google Cloud DR

A Google, ahogyan a biztonsági mentéshez, úgy kifejezetten a vészhelyreállításhoz sem kínál nevesített szolgáltatást. Ehelyett elérhetővé teszi az adattároláshoz és adatátvitelhez szükséges eszközöket és erőforrásokat, valamint útmutatást nyújt ügyfeleinek azok legmegfelelőbb felhasználásáról a különböző vészhelyreállítási helyzetekben.

Mivel a Google ritka elérésű tárolási lehetőségeket kínál, amelyekre kedvezményt ad, a GCP sokféle forgatókönyvben alkalmazható. A ritka elérésű tár vonzó lehetőség olyan vállalatoknak, amelyek nagy mennyiségű tömeges adatot tárolnak. A forgó mágneslemezek nem praktikus adathordozói az átlagosan több tíz gigabájt méretű multimédia-fájloknak. A hálózati tároló (NAS) összetevők megoldást kínálnak a multimédiát előállító vállalatoknak a hozzáférés és kezelhetőség problémájára, de csakis helyi szinten. Rendelkeznek belső redundanciával, de nem katasztrófatűrők. A fentiekben ábrázolt háromhoz hasonló vészhelyreállítási forgatókönyv az ilyen ügyfelek számára nem volna praktikus (vagy akár kifizetődő). A ritka elérésű tárolás legalább egy járható utat kínál ezeknek az ügyfeleknek arra, hogy biztosítsák az üzletfolytonosság névleges szintjét.

Tesztelje tudását

1.

Vészhelyreállítás esetén feladatátvétel történik, ha egy elsődleges erőforráskészlet elérhetetlenné válik vagy nem válaszok, és a forgalom egy, az elsődlegest tükröző másodlagos erőforráscsoporthoz van átirányítva. A feladatátvételi idő azért fontos, mert minimalizálni kell az állásidőt. Az alábbi vészhelyreállítási módszerek közül melyiknek a legnagyobb a várható feladatátvételi ideje?

2.

A három legfontosabb szolgáltatásiszint-célkitűzés, amely alapján a vállalatok felépítik a biztonsági mentési és vészhelyreállítási terveket, a helyreállításipont-célkitűzés (RPO), a helyreállítási idő célkitűzése (RTO) és az adatmegőrzés időtartama. Tegyük fel, hogy egy vállalat fontosabbnak ítéli az adatvesztés minimalizálását, mint az állásidőét. Melyik a vállalat által leglényegesebbnek ítélt szolgáltatásiszint-célkitűzés?