Képzelje el: Ön egy nagy bevásárlóközpont informatikai infrastruktúráját szolgálja ki. Elkezd esni az eső a városban. Esőpatakok törnek át a tetőn, a víz bokáig megtölti a kiskereskedelmi helyiségeket. Reméljük, hogy az Ön szerverszobája nem az alagsorban van, különben nem lehet elkerülni a problémákat.
A leírt történet nem fantázia, hanem néhány 2020-as esemény együttes leírása. A nagyvállalatoknál mindig kéznél van egy katasztrófa-helyreállítási terv vagy katasztrófa-helyreállítási terv (DRP). A vállalatoknál ez az üzletmenet-folytonossági szakemberek felelőssége. A közép- és kisvállalatoknál azonban az ilyen problémák megoldása az informatikai szolgáltatásokra hárul. Önnek meg kell értenie az üzleti logikát, meg kell értenie, mi és hol hibásodhat meg, elő kell állítania a védelmet és végre kell hajtania.
Nagyon jó, ha egy informatikus tud tárgyalni a vállalkozással és megbeszéli a védelem szükségességét. De nem egyszer láttam, ahogy egy cég spórolt egy katasztrófa-helyreállítási (DR) megoldással, mert azt feleslegesnek tartotta. Amikor egy baleset történt, a hosszú felépülés veszteségekkel fenyegetett, és az üzlet nem volt kész. Tetszés szerint ismételheti: „Megmondtam”, de az informatikai szolgáltatásnak továbbra is vissza kell állítania a szolgáltatásokat.
Az építész pozíciójából elmondom, hogyan kerülheti el ezt a helyzetet. A cikk első részében bemutatom az előkészítő munkát: hogyan beszéljünk meg három kérdést az ügyféllel a biztonsági eszközök kiválasztásához:
- Mit védünk?
- Mitől védünk?
- Mennyit védünk?
A második részben a kérdés megválaszolásának lehetőségeiről fogunk beszélni: hogyan védekezzünk. Példákat fogok hozni arra az esetre, amikor a különböző ügyfelek hogyan építik fel a védelmet.
Amit védünk: a kritikus üzleti funkciók azonosítása
A felkészülést jobb úgy kezdeni, hogy megbeszéljük az üzleti ügyféllel a vészhelyzet utáni intézkedési tervet. A fő nehézség itt a közös nyelv megtalálása. Az ügyfelet általában nem érdekli, hogyan működik az informatikai megoldás. Érdekel, hogy a szolgáltatás képes-e üzleti funkciókat ellátni és pénzt hozni. Például: ha az oldal működik, de a fizetési rendszer nem működik, nincs bevétel az ügyfelektől, és a „szélsőségesek” továbbra is informatikusok.
Egy informatikusnak több okból is nehézségei lehetnek az ilyen tárgyalásokon:
- Az informatikai szolgáltatás nem teljesen érti az információs rendszer szerepét az üzleti életben. Például, ha nem áll rendelkezésre üzleti folyamatok leírása vagy átlátható üzleti modell.
- Nem a teljes folyamat függ az informatikai szolgáltatástól. Például amikor a munkák egy részét vállalkozók végzik, és az informatikusoknak nincs rájuk közvetlen befolyásuk.
A beszélgetést így strukturálnám:
- Elmagyarázzuk a vállalkozásoknak, hogy balesetek mindenkivel előfordulnak, és a felépülés időbe telik. A legjobb dolog az, ha bemutatjuk a helyzeteket, hogyan történik ez, és milyen következményekkel járhat.
- Megmutatjuk, hogy nem minden múlik az informatikai szolgáltatáson, de Ön készen áll, hogy segítsen egy cselekvési tervvel az Ön felelősségi körében.
- Arra kérjük az üzleti ügyfelet, hogy válaszoljon: ha megtörténik az apokalipszis, melyik folyamatot kell először helyreállítani? Kik és hogyan vesznek részt benne?
Egyszerű válaszra van szükség a vállalkozástól, például: a telefonos ügyfélszolgálatnak a hét minden napján, 24 órában kell folytatnia a jelentkezések regisztrálását.
- Megkérünk egy-két rendszerhasználót, hogy írja le részletesen ezt a folyamatot.
Jobb, ha bevonunk egy elemzőt, hogy segítsen, ha cége rendelkezik ilyennel.Kezdetben a leírás a következőképpen nézhet ki: a call center telefonon, e-mailben és a webhelyről érkező üzenetekben fogadja a kéréseket. Aztán a webes felületen keresztül beviszi őket az 1C-be, a gyártás pedig onnan veszi őket így.
- Ezután megnézzük, milyen hardver- és szoftvermegoldások támogatják a folyamatot. Az átfogó védelem érdekében három szintet veszünk figyelembe:
- alkalmazások és rendszerek a helyszínen (szoftver szinten),
- maga a webhely, ahol a rendszerek futnak (infrastruktúra szint),
- hálózat (gyakran megfeledkeznek róla).
- Kiderítjük a lehetséges hibapontokat: rendszercsomópontokat, amelyektől a szolgáltatás teljesítménye függ. Külön megjegyezzük a más cégek által támogatott csomópontokat: távközlési szolgáltatók, tárhelyszolgáltatók, adatközpontok stb. Ezzel visszatérhet az üzleti ügyfélhez a következő lépéshez.
Amitől védünk: kockázatok
Ezután az üzleti ügyféltől megtudjuk, hogy milyen kockázatoktól védjük meg magunkat először. Minden kockázat két csoportra osztható:
- időveszteség a szolgáltatás leállása miatt;
- adatvesztés fizikai hatások, emberi tényezők stb. miatt.
A vállalkozások félnek az adatok és az idő elvesztésétől – mindez pénzveszteséghez vezet. Tehát ismét kérdéseket teszünk fel minden kockázati csoport számára:
- Ennél a folyamatnál meg tudjuk becsülni, hogy mennyi adatvesztés és időveszteség kerül pénzben?
- Milyen adatokat nem veszíthetünk el?
- Hol nem engedhetjük meg az állásidőt?
- Mely események a legvalószínűbbek és a legfenyegetőbbek ránk?
A megbeszélés után meg fogjuk érteni, hogyan kell prioritást adni a hibapontoknak.
Mennyit védünk: RPO és RTO
Amikor a meghibásodás kritikus pontjai egyértelműek, kiszámítjuk az RTO és RPO mutatókat.
Hadd emlékeztessem önöket erre RTO (helyreállási idő célkitűzés) — ez a megengedhető idő a baleset pillanatától a szolgáltatás teljes helyreállításáig. Üzleti nyelven ez elfogadható állásidő. Ha tudjuk, hogy mennyi pénzt hozott a folyamat, akkor minden percnyi leállásból ki tudjuk számítani a veszteségeket, és kiszámítani az elfogadható veszteséget.
RPO (helyreállítási pont cél) — érvényes adat-helyreállítási pont. Meghatározza, hogy mennyi idő alatt veszíthetünk el adatokat. Üzleti szempontból az adatvesztés például bírságot vonhat maga után. Az ilyen veszteségek pénzre is válthatók.
A helyreállítási időt a végfelhasználó számára kell kiszámítani: mennyi ideig tud bejelentkezni a rendszerbe. Tehát először összeadjuk a lánc összes láncszemének helyreállítási idejét. Itt gyakran elkövetnek egy hibát: elveszik a szolgáltató RTO-ját az SLA-ból, és elfelejtik a fennmaradó feltételeket.
Nézzünk egy konkrét példát. A felhasználó bejelentkezik az 1C-be, a rendszer adatbázis-hibával nyílik meg. Felveszi a kapcsolatot a rendszergazdával. Az adatbázis a felhőben található, a rendszergazda jelenti a problémát a szolgáltatónak. Tegyük fel, hogy minden kommunikáció 15 percet vesz igénybe. A felhőben egy ekkora adatbázis mentésből egy óra alatt visszaáll, ezért az RTO a szolgáltatói oldalon egy óra. De ez nem a végső határidő, a felhasználó számára 15 percet adtak hozzá a probléma észlelésére.
Ezután a rendszergazdának ellenőriznie kell az adatbázis helyességét, csatlakoztatnia kell az 1C-hez, és el kell indítania a szolgáltatásokat. Ehhez még egy óra kell, ami azt jelenti, hogy a rendszergazdai oldalon az RTO már 2 óra 15 perc. A felhasználónak további 15 percre van szüksége: jelentkezzen be, ellenőrizze, hogy megjelentek-e a szükséges tranzakciók. Ebben a példában 2 óra 30 perc a teljes szolgáltatás-helyreállítási idő.
Ezek a számítások megmutatják a vállalkozásnak, hogy milyen külső tényezőktől függ a helyreállítási időszak. Például, ha az irodát elárasztotta a víz, először meg kell találnia a szivárgást, és meg kell javítania. Időbe fog telni, ami nem az IT-n múlik.
Hogyan védekezzünk: eszközök kiválasztása a különböző kockázatokhoz
Az összes pont megbeszélése után az ügyfél már megérti, hogy egy baleset mennyibe kerül a vállalkozás számára. Most kiválaszthatja az eszközöket, és megvitathatja a költségvetést. Ügyfél esetek példáin keresztül bemutatom, milyen eszközöket kínálunk a különböző feladatokhoz.
Kezdjük a kockázatok első csoportjával: a szolgáltatás leállás miatti veszteségekkel. A probléma megoldásainak jó RTO-t kell biztosítaniuk.
- Hozd az alkalmazást a felhőben
Kezdésként egyszerűen áttérhet a felhőre - a szolgáltató már végiggondolta a magas rendelkezésre állás kérdéseit. A virtualizációs gazdagépeket fürtbe állítják össze, az áramot és a hálózatot lefoglalják, az adatokat hibatűrő tárolórendszereken tárolják, az állásidőért pedig a szolgáltató anyagi felelősséggel tartozik.
Például hostolhat egy virtuális gépet egy adatbázissal a felhőben. Az alkalmazás külsőleg csatlakozik az adatbázishoz egy létrehozott csatornán vagy ugyanabból a felhőből. Ha problémák merülnek fel a fürt egyik kiszolgálójával, a virtuális gép kevesebb mint 2 percen belül újraindul a szomszédos kiszolgálón. Ezt követően elindul benne a DBMS, és néhány perc múlva elérhetővé válik az adatbázis.
OTR: percben mérve. Ezeket a feltételeket a szolgáltatóval kötött szerződésben lehet meghatározni.
Költség: Kiszámoljuk az alkalmazás felhőalapú erőforrásainak költségét.
Amitől nem véd meg: a szolgáltató telephelyén bekövetkezett súlyos meghibásodások miatt, például városi szintű balesetek miatt. - Csoportosítsa az alkalmazást
Ha javítani szeretné az RTO-t, megerősítheti az előző lehetőséget, és azonnal elhelyezhet egy fürtözött alkalmazást a felhőben.
A fürt aktív-passzív vagy aktív-aktív módban valósítható meg. Számos virtuális gépet hozunk létre a szállító igényei alapján. A nagyobb megbízhatóság érdekében ezeket különböző szervereken és tárolórendszereken osztjuk szét. Ha az egyik adatbázissal rendelkező kiszolgáló meghibásodik, a biztonsági mentési csomópont néhány másodpercen belül átveszi a terhelést.
OTR: másodpercben mérve.
Költség: valamivel drágább, mint egy hagyományos felhő, további erőforrásokra lesz szükség a fürtözéshez.
Amitől nem véd meg: Még mindig nem véd a súlyos helyszíni hibák ellen. A helyi fennakadások azonban nem tartanak sokáig.A gyakorlatból: A kiskereskedelmi cégnek több információs rendszere és weboldala volt. Az összes adatbázis helyben, a cég irodájában volt. Addig nem gondoltak DR-re, amíg az iroda többször egymás után áram nélkül maradt. Az ügyfelek elégedetlenek voltak a webhely összeomlásával.
A szolgáltatás elérhetőségével kapcsolatos probléma a felhőbe való átállás után megoldódott. Ráadásul a csomópontok közötti forgalom kiegyensúlyozásával sikerült optimalizálnunk az adatbázisok terhelését. - Menjen át egy katasztrófabiztos felhőbe
Ha meg kell győződnie arról, hogy a fő oldalon egy természeti katasztrófa sem zavarja a munkáját, választhat egy katasztrófaálló felhőt, amelynél a szolgáltató a virtualizációs klasztert 2 adatközpontra osztja szét. Folyamatos szinkron replikáció történik az adatközpontok között, egytől egyig. Az adatközpontok közötti csatornák le vannak foglalva és különböző útvonalakon haladnak, így egy ilyen klaszter nem fél a hálózati problémáktól.
OTR: 0-ra hajlik.
Költség: A legdrágább felhő opció.
Amitől nem véd meg: Az adatsérülések ellen, valamint az emberi tényezőtől nem segít, ezért ajánlott egyidejűleg biztonsági mentést is készíteni.A gyakorlatból: Egyik ügyfelünk átfogó katasztrófa-helyreállítási tervet dolgozott ki. Ezt a stratégiát választotta:
- A katasztrófa-tűrő felhő védi az alkalmazást az infrastruktúra szintű hibáktól.
- A kétszintű biztonsági mentés védelmet nyújt emberi hiba esetén. Kétféle biztonsági mentés létezik: „hideg” és „meleg”. A „hideg” biztonsági másolat letiltott állapotban van, és időbe telik a telepítés. A „forró” biztonsági másolat már használatra kész, és gyorsabban visszaáll. Egy speciálisan erre a célra szolgáló tárolórendszeren tárolják. A harmadik példányt szalagra rögzítik, és egy másik szobában tárolják.
Az ügyfél hetente egyszer teszteli a védelmet, és ellenőrzi az összes biztonsági másolat működőképességét, beleértve a szalagról készülteket is. A vállalat minden évben teszteli a teljes katasztrófaálló felhőt.
- Másik webhelyre történő replikáció megszervezése
Egy másik lehetőség a globális problémák elkerülésére a fő oldalon: biztosítson földrajzi foglalást. Más szavakkal, hozzon létre tartalék virtuális gépeket egy másik városban található helyen. Erre a speciális DR-megoldások alkalmasak: cégünknél VMware vCloud Availabilityt (vCAV) használunk. Segítségével védelmet konfigurálhat több felhőszolgáltató webhely között, vagy helyreállíthat egy helyszíni webhelyről a felhőbe. Már részletesebben beszéltem a vCAV-val való munkavégzés sémájáról .
RPO és RTO: 5 perctől.
Költség: drágább, mint az első lehetőség, de olcsóbb, mint a hardveres replikáció egy katasztrófabiztos felhőben. Az ár a vCAV licenc költségéből, az adminisztrációs díjakból, a felhő erőforrások költségéből és a PAYG modell szerinti tartalék erőforrásokból áll (a kikapcsolt virtuális gépeknél a munkaerőforrások költségének 10%-a).
A gyakorlatból: Az ügyfél 6 különböző adatbázisú virtuális gépet tartott a moszkvai felhőnkben. A védelmet eleinte biztonsági mentés biztosította: a biztonsági másolatok egy részét a moszkvai felhőben, egy részét pedig a szentpétervári telephelyünkön tároltuk. Idővel az adatbázisok mérete nőtt, és a biztonsági másolatból történő visszaállítás több időt vett igénybe.
A VMware vCloud elérhetőségen alapuló replikáció hozzáadva a biztonsági másolatokhoz. A virtuális gépek replikáit szentpétervári biztonsági mentési helyen tárolják, és 5 percenként frissülnek. Ha meghibásodás történik a fő telephelyen, az alkalmazottak önállóan váltanak át a virtuális gép egy szentpétervári replikájára, és folytatják vele a munkát.
Az összes figyelembe vett megoldás magas rendelkezésre állást biztosít, de nem véd a ransomware vírus vagy a munkavállaló véletlen hibája miatti adatvesztés ellen. Ebben az esetben biztonsági másolatokra lesz szükségünk, amelyek biztosítják a szükséges RPO-t.
5. Ne feledkezzen meg a biztonsági mentésről
Mindenki tudja, hogy biztonsági másolatot kell készítenie, még akkor is, ha a legmenőbb katasztrófabiztos megoldással rendelkezik. Ezért csak röviden emlékeztetlek néhány pontra.
Szigorúan véve a biztonsági mentés nem DR. És ezért:
- Ez hosszú idő. Ha az adatokat terabájtban mérik, a helyreállítás több mint egy órát vesz igénybe. Vissza kell állítani, hálózatot rendelni, ellenőrizni, hogy bekapcsol, megnézni, hogy az adatok rendben vannak-e. Tehát csak akkor tud jó RTO-t biztosítani, ha kevés az adat.
- Előfordulhat, hogy az adatok első alkalommal nem állnak vissza, és időt kell hagynia a művelet megismétlésére. Például előfordul, hogy nem tudjuk pontosan, mikor vesztek el az adatok. Tegyük fel, hogy a veszteséget 15.00-kor vették észre, és óránként készülnek másolatok. 15.00 órától megnézzük az összes helyreállítási pontot: 14:00, 13:00 és így tovább. Ha fontos a rendszer, igyekszünk minimalizálni a helyreállítási pont korát. De ha a friss biztonsági másolat nem tartalmazza a szükséges adatokat, akkor a következő pontot vesszük - ez további idő.
Ebben az esetben a biztonsági mentés ütemezése biztosíthatja a szükségeset RPO. A biztonsági mentéseknél fontos a földrajzi foglalás biztosítása a fő oldallal kapcsolatos problémák esetén. Javasoljuk, hogy néhány biztonsági másolatot külön tároljon.
A végső katasztrófa-helyreállítási tervnek legalább 2 eszközt kell tartalmaznia:
- Az 1-4 opciók egyike, amely megvédi a rendszereket a meghibásodásoktól és leesésektől.
- Biztonsági mentés az adatok elvesztésének elkerülése érdekében.
Érdemes tartalék kommunikációs csatornáról is gondoskodni arra az esetre, ha a fő internetszolgáltató leállna. És - íme! — A minimálbéres DR már készen áll.
Forrás: will.com