A Fujitsu mindig is elkötelezett híve volt a rendszerösszeomlás- és egyéb hasonló téren bekövetkezhető katasztrófák elhárítása terén. Most a hazai Fujitsu blog egy kapcsolódó írását mutatjuk be a Techaddikt.hu olvasóinak.
Előfordult már Önnel, hogy amikor megpróbálta visszaállítani mobiltelefonja beállításait, véletlenül mindent letörölt, és mivel az adatokat korábban nem mentette el máshova, a telefonon tárolt összes telefonszám, fénykép, videó, zeneszám és dokumentum elveszett? Reméljük, nem. De az talán már megtörtént, hogy épp a noteszgépén dolgozott, amikor tönkrement a merevlemez, és az adatokat csak részlegesen sikerült visszanyerne, miután hosszú órákat töltött el feleslegesen a visszaállítással.
Nehéz helyzetek ezek. És ha nehezek az egyén számára, gondoljunk csak bele, mennyire kritikus lehet az adatvesztés egy szervezetnél. Képzeljünk el egy távközlési vállalatot, amely nem tudja lehetővé tenni ügyfeleinek a telefonszámla kifizetését, vagy a kártyaegyenleg feltöltését az infrastruktúra hibája miatt. Vagy egy online áruházat, amely leállás miatt elérhetetlen a vevők számára, ami végső soron ügyfél- és üzletvesztéshez vezet. Esetleg egy egészségügyi szolgáltatót, amely hiába van jelen több helyszínen, egy üzemkiesés következtében hosszabb időn keresztül nem tudja nyújtani szolgáltatásait, és elérni a betegnyilvántartást, a fájlokat vagy a vizsgálati eredményeket.
Olyan világban élünk, ahol sokféle módon függünk a technológiától. Számos területen megkönnyíti az életünket, de megvannak a maga hátrányai is, főleg a munkavégzés terén. Legyen szó egyénről vagy szervezetről, a technológia az a médium, amely összekapcsol minket másokkal, az ügyfeleket is ideértve. Bármilyen emberi mulasztás, természeti katasztrófa, hardver- vagy szoftverhiba, erőforráshiány, sávszélesség-, adatbázis-/alkalmazás- vagy webhelyprobléma által okozott leállás ugyanazzal a végeredménnyel jár: komoly kellemetlenség a vállalat számára, amelyet – a pénzügyi veszteség megelőzése érdekében – megfelelő intézkedéseknek kell követnie.
Nem hiába mondják, hogy az üzleti életben a katasztrófakezelés a túlélés kulcsa.
Még a legjobb szándék esetén is előfordulhat katasztrófa!
Reálisan nézve csak a katasztrófa utáni helyzet súlyosságát lehet (valamilyen mértékben) hatásosan enyhíteni katasztrófakezelő megoldással. Megfelelő katasztrófaelhárítás (DR) esetén az IT-infrastruktúra adatvesztés nélkül vagy minimális adatvesztéssel visszaállítható, így a felhasználók garantáltan hozzáférnek a számukra szükséges adatokhoz.
A DR-megoldások besorolása attól függ, melyiknél mekkora hangsúlyt fektetnek a különböző tényezőkre. A legtöbb DR-terv azonban az alábbi két megoldásra vagy ezek valamelyikére épül:
Adatreplikáció: Ebben az esetben az adatsorokat valamely forrásból egy másikba másolják. A másolatkészítés valós idejű adatátvitelre épül, így katasztrófa esetén az adatok visszaállítása is azonnali.
Biztonsági mentés és archiválás: Ebben az esetben az adatsorokat vagy egy másodlagos forrásba másolják át vagy ott archiválják, és onnan hívják elő katasztrófa esetén. Mivel ilyenkor az adatátvitel nem valós idejű, látencia lehet az adatvisszaállításban.
Magától értetődik, hogy mind a replikációnak, mind pedig a biztonsági mentésnek megvannak a maga előnyei és költségei, és az adott felhasználási helyzettől függ, melyiket érdemes választani. A replikáció nem helyettesíti a mentést és fordítva. Ha például az elsődleges helyszínen sérültek az adatok, manipulálták őket, ez a másodlagos helyszínt is érinti. Ebben az esetben a biztonsági mentésből kinyerhető az adatok múltbeli változata az adatsérülés előtti időből. De az adatok visszaállításánál látencia léphet fel, ami hátrányos a kritikus alkalmazások szempontjából. Ezért ideális esetben az adatreplikáció és a biztonsági mentés kombinációját alkalmazzák a katasztrófaelhárításhoz.
Ugyanakkor néhány alapvető szempontot mindenképpen érdemes figyelembe venni a DR-megoldás kidolgozása során. Egyszerűen sorra lehet venni őket. Elég körülnézni, és eldönteni, melyek a legfontosabb szempontok az Önök számára:
Mekkora leállási költség (USD/perc) tolerálható az Önök számára?
Milyen alkalmazásokkal dolgoznak? Ezek közül melyek kritikusak?
Milyen hálózati sávszélességgel rendelkeznek, milyen mértékben tudják ezt növelni?
Hol, az elsődleges helyszíntől milyen távolságra található a másodlagos helyszín?
Katasztrófa esetén mekkora az az elfogadható időtartam, ameddig képesek tolerálni a leállást, és milyen gyorsan szeretnék végrehajtani a visszaállítást?
Átlátható átállási (failover) megoldást keresnek, vagy manuális beavatkozás is elképzelhető?
Szeretnék, ha mindkét (vagy az összes) helyszín valós időben kommunikálna egymással?
Szeretnék, ha a másodlagos helyszín csak katasztrófa esetén venné át a feladatokat?
Összesen mekkora költségvetésük van a komplett megoldásra?
Mennyire reális az az összeg, amit hardverre és (a licencdíjakat is beleértve) szoftverre fordítottak eddig, illetve fognak fordítani a jövőben?
Ha az alapvető keretrendszer a fenti kérdésekre adott válaszok alapján elkészült, ki lehet választani a szervezet számára megfelelő katasztrófaelhárítási lehetőséget. Ha az üzleti igények azt teszik szükségessé, hogy az adatokról pontos másolat készüljön egy másodlagos helyszínen, adott operatív teljesítmény fenntartása mellett, akkor el kell dönteni, mi a megfelelőbb: a hardveralapú vagy a szoftveralapú replikációs megoldás. A hardveralapú replikáció többféle lehetőséget kínál a támogatásra és a következetesség fenntartására. A szoftveralapú replikáció pedig egyebek mellett hatékonyabban támogatja a valós idejű másolatkészítést, és gyorsabb visszaállást tesz lehetővé.
A hardveralapú replikációs megoldások is eltérhetnek egymástól – pl. költségek, rugalmasság és skálázhatóság terén. A különbségek alapján ezek a megoldások az alábbiak szerint csoportosíthatók:
Gazdagép-alapú (host-based) replikáció: A szerver szintjén működő megoldás egyszerveres fiókirodáknál vagy kisebb vállalkozásoknál használható. Bár a bevezetés után kissé nehézkes a vertikális skálázás, a hardver, a szoftver, a támogatás és a bevezetés összköltségét tekintve eléggé költséghatékony módszer. Emellett gyors, felhasználható konkrét alkalmazások SLA-szintjének javítására vagy a szervezeten belül egy vagy több részleg speciális igényeinek kiszolgálására.
Hálózatalapú (network-based) replikáció: A hálózat szintjén működő megoldás alkalmasabb több szerverből és tárolóból álló, heterogén környezetek támogatására. Mivel a megoldás hálózatalapú, működése is független a szerverektől és a tárolókomponensektől. Megvalósítása általában nagyobb költséggel jár, talán azért, mert ez a megoldás a gazdagép-alapú és a tárolótömb-alapú replikációs megoldások bizonyos előnyeit is biztosítja. Létrehozható inline célgépalapú és/vagy fabric-alapú megoldásként. A megoldás kialakítása előtt meg kell vizsgálni a két helyszín közötti távolságot, a sávszélességet, a replikálandó alkalmazásokat/adatokat és a bevezetés után szükséges skálázhatóságot.
Tárolótömb-alapú (array-based) replikáció: A tömbszinten működő megoldás olyan szervezeteknél ideális, ahol több, leállást egyáltalán nem toleráló, kritikus alkalmazás működik. Központosítottabb szemléletet követ, és bevezetés után rugalmasan skálázható vertikálisan, ha vállalják az ezzel járó licencköltségeket. A megoldás bevezetésének egyik előfeltétele, hogy mindkét helyszínen hasonló konfigurációjú, hasonló tárolómodelleket használjanak. Ez a megoldás azonban szállítóspecifikus, mivel a bevezetési és egyéb követelményeket előre részletesen tisztázni kell.
Az adatok megóvása katasztrófa esetén, és szervezet védelme a pénzügyi veszteségekkel szemben ugyanannak az éremnek a két oldala. Hogy mi a végső következtetés? Tekintve, hogy katasztrófa bármikor, bárkinél előfordulhat, fel kell tenni a kérdést, milyen hatást gyakorolna bármely típusú leállás a vállalatra. A megelőző katasztrófa-elhárítási tervezés sokféleképpen elvégezhető. Ha csak alapvető keretrendszerre van szükség, a rendelkezésre álló költségvetés szempontjait (és az üzleti szükségleteket) is figyelembe véve lehet egyszerűsítésekkel élni.
Mivel a megelőzés mindig jobb stratégia, mint a gyógyítás, a megelőző intézkedésekre kell az elsődleges hangsúlyt fektetni.
Forrás: Fujitsu Blog – az eredti bejegyzés IDE kattintva érhető el.