Docstoc

Diplomová práca - Disaster Recovery _ Business Continuity

Document Sample
Diplomová práca - Disaster Recovery _ Business Continuity Powered By Docstoc
					MASARYKOVA UNIVERZITA                FAKULTA INFORMATIKY




          DISASTER RECOVERY
                  &
 BUSINESS CONTINUITY FOR DATACENTER



                   DIPLOMOVÁ PRÁCA




                                    Bc. Roman Blažečka
                                         Brno, 2007/2008
                         Vedúci : RNDr. Jan Bouda, Ph.D.
Prehlásenie

      Prehlasujem, že táto diplomová práca je mojim pôvodným autorským dielom, ktoré
som vypracoval samostatne. Všetky zdroje, pramene a literatúru, ktoré som pri
vypracovaní používal, alebo z nich čerpal, v práci riadne citujem s uvedením úplného
odkazu na príslušný zdroj.


                                                                    Roman Blažečka




                                                                                   2
Poďakovanie

       Na tomto mieste by som veľmi rád poďakoval predovšetkým Ing. Věnkovi
Otevřelovi za profesionálny prístup, nespočetne mnoho odborných rád, i samotné
umožnenie tejto práce, ako aj RNDr. Janovi Boudovi, Ph.D. za vedenie po formálnej
stránke.




                                                                                    3
Zhrnutie

        Cieľom práce je navrhnúť riešenie zaisťujúce nepretržitý chod aplikácií a systémov,
ktoré splňuje atribúty zaistenia business kontinuity firemných procesov. Prvou časťou
práce je úvod do tejto problematiky a prehľad obvyklých funkcií a techník používaných
v tejto oblasti. Druhou časťou je vypracovanie systému pre konkrétnu organizáciu
vyhovujúcemu nasledujúcim vlastnostiam. Podpora práce geo-clusterových systémov pri
základnej vzdialenosti jednotlivých lokalít v oblasti do 35 km. Celé riešenie by malo
zohľadňovať špecifiká jednotlivých komponentov, ktoré sú neoddeliteľnou súčasťou
moderných dátových centier a ďalej zohľadňovať minimálne dva rozdielne operačné
systémy pracujúce v prostredí vysokej dostupnosti: MS Windows 2003 a IBM AIX 5.3.
Súčasťou návrhu by mal byť návrh implementácie riešenia zaisťujúci backup, recovery
a off-site vaulting zálohovacích médií. Výstupom práce by mal byť návrh riešenia, schéma
zapojenia systémov, popis nastavenia, testy funkcionality a patričná osnova denných
administrátorských úkonov. Vytvorený systém bude porovnaný s existujúcimi systémami
iných podnikov podľa dostupných informácií.




                                                                                          4
Kľúčové slová

Datacenter, Disaster Recovery, Business Continuity, DRP, BCP, RPO, RTO, TSM, SAN,
Fibre Channel, cluster




                                                                                    5
                                      Obsah
1 Úvod                                                                                8
     1.1 Motivácia                                                                    8
     1.2 Vytýčenie cieľov                                                             9
     1.3 Základné pojmy/skratky                                                       9
2 Proces plánovania DR & BC                                                           10
     2.1 Metodika tvorby DRP                                                          11
            2.1.1 Základné pojmy                                                      12
            2.1.2 Fázy procesu plánovania DR/BC                                       13
     2.2 7-úrovňový model Disaster Recovery                                           15
            2.2.1 Úroveň 0 – Do Nothing, no off-site data                             16
            2.2.2 Úroveň 1 – Offsite vaulting (PTAM)                                  16
            2.2.3 Úroveň 2 – Offsite vaulting with a hotsite (PTAM+hotsite)           16
            2.2.4 Úroveň 3 – Electronic vaulting                                      16
            2.2.5 Úroveň 4 – Electronic vaulting to hotsite (active secondary site)   17
            2.2.6 Úroveň 5 – Two-site two-phase commit                                17
            2.2.7 Úroveň 6 – Zero data loss                                           17
            2.2.8 Zhrnutie                                                            18
     2.3 Postup pri výbere riešení                                                    19
3 Používané technológie                                                               23
     3.1 Servery                                                                      23
            3.1.1 Architektúra x86                                                    23
            3.1.2 SPARC                                                               24
            3.1.3 PA-RISC                                                             24
            3.1.4 PowerPC                                                             24
            3.1.5 BladeCenters                                                        25
            3.1.6 Ďalšie platformy                                                    25
     3.2 Data Storage                                                                 26
            3.2.1 Disky a diskové polia                                               27
            3.2.2 Optické média, jukeboxi                                             30
            3.2.3 Pásky a páskové knižnice                                            30
     3.3 Sieťová infraštruktúra                                                       31
            3.3.1 Storage Area Networks – SANs                                        31
            3.3.2 Technológie vzdialeného pripojenia                                  36
     3.4 Software a automatizácia                                                     38
            3.4.1 TSM                                                                 38
            3.4.2 BMR techniky                                                        42
            3.4.3 Clustering                                                          42
4. Analýza prostredia a potrieb podniku                                               47
     4.1 Fyzická infraštruktúra                                                       47
     4.2 HW/SF platformy                                                              47
     4.3 Sieťová infraštruktúra LAN                                                   48
     4.4 Storage, SAN                                                                 49
     4.5 Nasadený software/aplikácie                                                  51
     4.6 Návrh tried aplikácií podľa požadovaného RPO/RTO                             52
     4.7 Mapovanie fault-tolerantných aplikácií do tried                              53
5 Návrh riešenia                                                                      54

                                                                                          6
      5.1 Návrh riešení Recovery tried                  54
      5.2 Dva základné varianty                         56
             5.2.1 Model s topológiou two-site          57
             5.2.2 Model s topológiou three-site        58
      5.3 Návrh BMR procedúr a obnovy aplikačných dát   60
      5.4 Stručný DRP plán                              62
6 Záver                                                 64

7 Použitá literatúra                                    65

8 Príloha A – použité skratky                           68

9 Príloha B – ukážky z DR plánu                         69




                                                         7
                                       1 Úvod

        Spolu s rýchlosťou a rastom vývoja moderných technológii v posledných
desaťročiach sa čím ďalej viac stretávame s ich integráciou do komerčnej podnikovej
sféry. Postupom času sa začali podniky všetkých veľkostí spoliehať a stavať na IT
infraštruktúre, či už pri začleňovaní do automatizácie interných procesov, ale aj pri
poskytovaní koncových služieb. V dnešnej dobe je už len veľmi ťažké, možno priam
nemožné nájsť podnik, ktorý moderné technológie nevyužíva. Klíma v dnešnom „on
demand“ businesse je veľmi konkurencieschopná, zákazníci, zamestnanci, dodávatelia či
obchodní partneri očakávajú schopnosť využívať aplikácie a pristupovať k dátam
v ľubovoľnom čase, z ľubovoľného miesta. Nielen rozsiahle medzinárodné korporácie, ale
aj podniky menšieho charakteru sa stali priamo závislými na e-mailových službách, instant
messagingu, IP službách, či rôznych komerčných aplikáciach, databázových, ERP
(Enterprise Resource Planning) a iných systémoch. Týmto všetkým samozrejme začali
narastať obrovské požiadavky na bezpečnosť, vysokú dostupnosť, kapacitu a hlavne
spoľahlivosť moderných dátových úložíšť – dátových centier (datacenters).
        Pre business v reálnom svete nie je takmer nič nepríjemnejšie, ako byť zasiahnutý
výpadkom systému čo len na pár minút. Pri týchto výpadkoch systémov prichádzajú
podniky a spoločnosti o nemalé zisky, ba čo viac dostávajú sa do obrovských strát, čo
často vedie ku kritickým situáciám a následne k nevyhnutnému ukončeniu obchodnej
činnosti. Fakt, že v dobe niekoľkých posledných rokov čelíme rýchlo rastúcemu počtu
nepredvídateľných udalostí charakteru rôznych havárii, živelných pohrôm
a v neposlednom rade aj rastúcim teroristickým hrozbám, čo nám potvrdzujú udalosti
z nedávnej minulosti, vedie moderné podniky i štátne organizácie ku stavu „byť
pripravený“ na takéto neplánované výpadky. Investujú preto do designu tvorby
kontingenčných plánov, plánov pre zotavenie z havárii, ako aj plánov pre zaistenie
nepretržitej obchodnej činnosti. Cieľom tejto práce bude vysvetliť teóriu tvorby
spomínaných procesov, z nich sa pozrieme do detailu na tvorbu procesu zotavenia
z havárie, popíšeme využívané technológie a v poslednej časti prevedieme analýzu a návrh
konkrétneho riešenia pre reálne prostredie fungujúceho podniku, ktorý z dôvodov
duševného vlastníctva budeme v tejto práci nazývať XYZ.



1.1 Motivácia
        Ako bolo načrtnuté v úvode, závislosť podnikov od IT infraštruktúry v modernom
businesse je esenciálna a v drvivej väčšine prípadov pri jej výpadku podnik nie je schopný
pokračovať vo výrobnej a obchodnej činnosti. Udalosti v USA z 11 septembra 2001 opäť
ukázali a potvrdili širokú škálu nepredvídateľných možností výpadkov a mnoho podnikov
nielen z finančnej sféry získalo inšpiráciu pre tvorbu rôznych kontingenčných plánov.
Avšak i dodnes existuje veľké množstvo organizácii, ktoré v IT infraštruktúre stále nemajú
korektne riešené ani procesy zálohovania, hoci sú tieto považované za základný kameň
celej IT infraštruktúry podniku. Potvrdzuje to štúdium vydané firmou Harris Interactive,
Inc. [31] v USA z roku 2006, ktoré uvádza, že 39% oslovených spoločností hľadá dôveru
v ich riešení pohotovosti voči haváriám. Zarážajúce je, že vysokým deficitom v dôvere
havarijných plánov sa vyznačujú práve spoločnosti s ročným ziskom vyšším ako 500
miliónov dolárov, pri ktorých sa spravidla počíta s väčšou spoľahlivosťou

                                                                                         8
a dôveryhodnosťou. Lepšia správa je, že „len“ 24% zainteresovaných podnikov pokladalo
ich plány pre prípad havárie za neadekvátne.
         V roku 2000 veľké množstvo podnikov a organizácií v USA pokladalo za
„kvalitné“ pohotovostné plány pre prípad havárii tvorbu off-site záloh. Ale po
teroristických útokoch, bombových a antraxových incidentoch, hurikánoch, či povodní
ktoré zasiahli Spojené štáty americké, si je väčšina IT odborníkov vedomá faktu, že tvorba
off-site záloh je len malá časť celkovej stratégie pre zotavenie z havárie. V dnešnom svete
si už žiadny podnik nemôže dovoliť jednoducho ignorovať potrebu plánovania
nepretržitého chodu obchodnej činnosti (Business Continuity), ako aj plánovania zotavenia
z havárie (Disaster Recovery). Potvrdzuje to aj štúdium CBS News [28], podľa ktorého
bola vypracovaná nasledovná štatistika:

       „V štúdiu z podnikov, ktoré zažili významnejšiu stratu dát bez predošlého
       vypracovania adekvátnych Business Continuity & Disaster Recovery plánov, 43%
       nebolo nikdy opätovne otvorených, 56% bolo zatvorených do nasledovných dvoch
       rokov a len 6% ich prežilo z dlhodobého hľadiska.“


1.2 Vytýčenie cieľov
       Cieľom tejto práce bude na základe vysvetlených skutočností a motivačných
faktorov zaoberať sa metodikou tvorby plánovania procesov pre zaistenie nepretržitej
obchodnej činnosti a zotavenia z havárie. Z nich podrobnejšie sa budeme zaoberať druhým
zo spomínaných, ďalej vysvetliť používané technológie moderných dátových centier
spojené s využitím týchto technológii pri tvorbe a návrhu kontingenčných plánov
a v poslednej časti po analýze konkrétneho reálneho prostredia fungujúceho podniku,
navrhneme možné riešenie (riešenia) pre zaistenie zotavenia z havárii práve z perspektívy
IT. Cieľom tiež bude poskytnúť komplexný pohľad na technologické riešenia pri
zaisťovaní Business Continuity a Disaster Recovery, aj z dôvodu absencie takejto literatúry
v inom ako anglickom jazyku.


1.3 Základné pojmy / skratky

        V záujmu dodržania odbornej a zaužívanej terminológie, bude pre pokračovanie
v tejto práci nevyhnutné vysvetliť a objasniť niekoľko základných pojmov a skratiek
používaných v ďalšom texte, ktorým sa budeme neskôr hlbšie venovať (Príloha A –
použité skratky).




                                                                                          9
                     2 Proces plánovania DR & BC

         V tejto kapitole sa budeme detailne venovať procesom plánovania DR&BC a ich
jednotlivým fázam pri návrhu.
         S rastom spoľahlivosti chodu podniku od IT infraštruktúry, lineárne vzrastajú
požiadavky na bezpečnosť, kapacitu a hlavne vysokú dostupnosť výpočtových
a kapacitných zdrojov hardwarových položiek. Dnes nie sú žiadnou výnimkou systémy od
ktorých sa očakáva dostupnosť po dobu 24 hodín denne, 7 dní v týždni, 365 dní v roku.
Výpadok takýchto systémov čo i len na dobu v rádu minút predstavuje pre podniky
obrovské straty, ktoré sa šplhajú v extrémnych prípadoch (finančný sektor, burzy...) do
výšky 6-7 miliónov dolárov za hodinu doby výpadku (z ang. Downtime), uvádza
vydavateľská spoločnosť Syngress vo svojej publikácii Business Continuity & Disaster
Recovery [1].
         Predstavme si situáciu, v ktorej sa nachádzame v úlohe výkonného riaditeľa
zodpovedného pre IT oddelenie veľkého podniku. V skorých ranných hodinách
pracovného dňa nás zobudí telefón, v ktorom nám rozrušený sieťový administrátor podá
hlásenie, že sme sa stali obeťou sieťového útoku, niekoľko kľúčových systémov bolo
napadnutých a „všetky“ aplikačné dáta sa zdajú byť poškodené. Obratom od nás očakáva
inštrukcie pre riešenie vzniknutého problému, pričom behom niekoľkých hodín začne do
práce prichádzať niekoľko tisíc zamestnancov pracujúcich nad týmito kritickými
aplikáciami. Práve pre takéto, ale aj o mnoho horšie situácie je najviac ocenenou hodnotou
dobre vypracovaný DRP. V tejto kapitole sa budeme venovať metodike a postupu
zaisťovania prípravy pre podobné vzniknuté neplánované situácie.
         Z prvého pohľadu by sa mohlo zdať, že dva procesy z názvu tejto kapitoly
predstavujú jednu a tú istú činnosť. Nie je však tomu tak. Pojem Business Continuity Plan
popisuje procesy a procedúry podľa ktorých sa bude postupovať počas a po havárii, či
pohrome (ang. disaster), pre zaistenie nepretržitého chodu esenciálnych funkcii
a opätovnej plnej funkcionality všetkých systémov tak rýchlo, ako to je možné. Na druhej
strane Disaster Recovery Plan (DRP) je IT-zameraný plán navrhnutý pre obnovu
operability cieľových systémov, aplikácii alebo počítačových zariadení (datacenters) v
alternatívnej lokalite v stave núdzi. DRP je aplikovaný na významné, zvyčajne
katastrofické udalosti, ktoré znemožnia prístup k bežným zariadeniam na predĺženú dobu,
prípadne spôsobia úplnú fyzickú stratu - deštrukciu týchto zariadení. Z hľadiska IT pri
zaisťovaní Business Continuity kľúčových procesov, či aplikácii, vstupujú do popredia
tieto tri primárne aspekty: vysoká dostupnosť (high availability), nepretržité operácie
(continuous operations) a zotavenie z havárie (disaster recovery).
         Cieľom high availability je získať nepretržitú dostupnosť výpočtových služieb
a zdrojov tak, že vzniknutý výpadok systému bude mať na užívateľov minimálny dopad.
Podstata veci spočíva v princípe, že systém sa po výpadku spamätá automaticky a tak
rýchlo, že vlastný výpadok užívateľ vôbec nezaregistruje. Využívané sú k tomu
technologické prístupy akými sú redundantná stavba sub-komponent, kontrola chýb
a samoopravné postupy (Error checking and correction for data), obnovovacie schopnosti
(retry capabilities) základných operácii, alternatívne či násobné cesty pre I/O požiadavky,
ale aj transparentne zrkadlené dáta na oddelených úložných zariadeniach. Takéto systémy
odolné voči chybám sú navrhnuté spôsobom, že pri zlyhaní internej komponenty, či
jedného z jej zariadení, neprestáva samotný systém pracovať. Ako typickým príkladom pre
redundantnú sub-komponentu je duálne dodávanie energie.

                                                                                         10
        Pod pojmom continuous operations si predstavme schopnosť minimalizácie
výpadkov systému počas bežných, rutinných a každodenných operácii nad IT
infraštruktúrou. Bežné operácie zahrňujú zálohovanie, údržbu systémov, upgrady,
rekonfigurácie a iné. Pre príklad uvediem funkcionalitu point-in-time copy (tiež nazývaná
snapshot), ktorá dovoľuje úložným systémom výrazne znižovať čas prerušenia aplikácie z
dôvodu vytvorenia konštantnej zálohy v istom časovom bode.
        Posledným aspektom BC je zotavenie z havárie (disaster recovery). Jedná sa
o predvytvorený proces reakcie na vzniknutú haváriu, prípadne pohromu, ktorého cieľom
je opätovne poskytnúť služby výpočtového výkonu z alternatívnej lokality. V prípade
takejto situácii sú si užívatelia vedomí, že výpadok zasiahol centrálne počítačové stredisko
a doba výpadku je priamo závislá od riešenia obnovy procesu Disaster Recovery.
        Je zrejmé že BCP nemusí byť a ani nie je orientovaný výhradne na IT
infraštruktúru, ale zasahuje do všetkých vrstiev rozprestierajúcich sa nad celým podnikom.
Tieto elementy budú zahrňovať organizáciu zamestnancov, dátové centrá, IT
infraštruktúru, ko-lokáciu, užívateľskú oblasť IT (laptopy, desktopy), dátovú a hlasovú
komunikáciu, kancelárske pracovné priestory, produkčné vybavenie, výrobné vybavenie,
kópie dát na sekundárnej lokalite (ďalej off-site data storage) a v neposlednej rade kritické
dáta či záznamy. Preto je nevyhnutné podotknúť, že v našom kontexte budeme hovoriť
o BC zamerané na oblasť IT, teda IT Business Continuity, pričom sa budeme zameriavať
a detailne venovať práve aspektu riešenia Disaster Recovery.



2.1 Metodika tvorby DRP
        Pred samým počiatkom tvorby riešenia Disaster Recovery, je veľmi dôležité si
uvedomiť širokú škálu možností havárii, z nich vybrať potenciálne možné hrozby pre naše
konkrétne prostredie a následne ako základný stavebný kameň položiť výber situácii na
ktoré chceme byť pripravení a pre ktoré tvoríme riešenie Disaster Recovery. Skupinu
potenciálnych rizík môžeme rozdeliť do troch podskupín. V prvom prípade sú to všetky
riziká prírodného charakteru. Môžme sem zaradiť živelné pohromy a iné prírodné
katastrofy akými sú zemetrasenia, tzunami, hurikány či cyklóny, snehové či tropické
búrky, rozsiahle povodne či požiare, ale aj vulkanická činnosť. Do druhej podskupiny
zaraďujeme riziká spôsobované ľudským faktorom, nazývané tiež antropogénne. Tu
môžeme spomenúť v modernom svete sa zvyšujúcu hrozbu terorizmu, bombové útoky,
rôzne civilné nepokoje či vzbury, ale hlavne elektronické útoky. Pod poslednú skupinu
rizík budú spadať všetky druhy nehôd a rizík technologického charakteru. Zahrňujú ich ako
dopravné, tak aj nehody všeobecnej infraštruktúry (elektrická, plynová...) či IT
infraštruktúry (internetová, komunikačná, hardwarová...). V najlepších prípadoch pri
tvorbe DRP sa po zvážení potenciálnych rizík počíta práve s prípadom straty celého
centrálneho dátového centra a to včítane celého hardwarového vybavenia.
        Druhým nemenej dôležitým bodom pred samým začiatkom tvorby DRP je potreba
zhodnotiť relatívnu cenu výpadku, prípadne cenu dát v prípade ich straty a následne ju
vyvážiť s cenou tvorby a údržby dostupnosti pre kritické podnikové procesy. Z hľadiska
stratégie podniku je nevýhodné ušetriť 100 000 korún, v prípade že si to vyžiada investíciu
125 000 korún. Jednoducho povedané, otázka je vo vyvážení. Zrejme pre podnik s ročným
ziskom 50 miliónov korún, nebude cena 2 miliónov pre tvorbu BC/DR plánovania príliš
veľká ako cena „poistky“ tohto typu. Na druhej strane podnik s ročným ziskom 1,5 milióna
nebude očividne potrebovať investovať 1 milión na BC/DR plánovanie. Každá tvorba

                                                                                           11
riešenia BC/DR je v konečnom dôsledku vždy predmetom balancovania týchto 3 faktorov:
konkrétne riešenie / downtime / cena.


2.1.1 Základné pojmy

      Skôr ako vysvetlíme jednotlivé fázy tvorby DRP ozrejmíme niekoľko ďalších
pojmov:

Business Impact Analysis (BIA)
Analýza dopadu na podnikovú činnosť vykonávaná pre zistenie dopadov spojených
s výpadkom na špecifické funkcie a procesy v podniku (detailnejšie v ďalšom texte).

Risk Analysis
Analýza rizík identifikuje dôležité funkcie, zdroje, či prostriedky, ktoré sú kritické pre
chod podniku, následne určuje pravdepodobnosť ich výpadku a prioritu ich obnovy po
havárii.

Disaster Tolerance
Tolerancia havárii definuje schopnosť navrhnutého prostredia a vzťahujúcich sa
obchodných procesov odolať potenciálne možným haváriám. Neskôr sa budeme venovať
technológiám používaným na rôznych vrstvách pre zaistenie redundancie a odstránenie
úzkych miest zlyhania (single-points-of-failure).

DR hotsite
Pod pojmom horúce miesto, alebo hotsite budeme rozumieť dátové centrum
v alternatívnej lokalite s plným hardwarovým a komunikačným vybavením potrebným na
spracovanie obnovy zálohovaných dát a systémov v prípade havárie.

DR warmsite
Teplé miesto, warmsite, bude analógia hotsite s rozdielom len čiastočného hardwarového
a komunikačného vybavenia.

DR coldsite
Coltsite bude v kontexte s DR predstavovať vyhradené priestory (bez akéhokoľvek
výpočtového hardwaru), s pred kvalifikovanými klimatizačnými podmienkami, pripojením
k energii, či komunikačným prístupom, v ktorých sa začne s procesom obnovy v prípade
havárii v centrálnom dátovom centre.

High Availability
Popisuje schopnosť systému pokračovať v spracovávaní požiadaviek a funkcionalite po
určitú časovú periódu, normálne po dobu veľmi vysokého percenta časovej periódy, ako
napríklad 99,999%. V IT infraštruktúre sa toto dosahuje elimináciou kritických bodov
zlyhania (SPOF-single point of failure), či zavádzaním duálnych sub-komponent.

Recovery Time Objective (RTO)
RTO v našom kontexte bude vyjadrovať časový úsek, počas ktorého je nevyhnutné obnovu
po havárii dokončiť, inými slovami aký dlhý downtime si môžeme dovoliť.

                                                                                             12
Recovery Point Objective (RPO)
RPO analogicky definuje časový bod pred haváriou do ktorého budeme schopní obnovu
previesť, čo v podstate znamená koľko dát z doby pred haváriou si môžeme dovoliť stratiť,
prípadne nemôžme stratiť žiadne.

Network Recovery Objective (NRO)
Indikuje čas potrebný pre obnovu sieťových operácii. Tu je potreba si uvedomiť fakt, že
obnova systémov a aplikácii nie je kompletná pokiaľ zákazník nie je schopný k nim
pristupovať cez sieťové pripojenie. Preto NRO bude zahrňovať čas potrebný pre
sprístupnenie alternatívnych komunikačných spojení, rekonfiguráciu smerovačov,
menných serverov (DNS) ale tiež alternatívnych parametrov TCP/IP adries.


2.1.2 Fázy procesu plánovania DR/BC
        Ako sme už načrtli, BCP zahrňuje procesy rozľahlé po celom podniku týkajúce sa
napríklad účtovníctva, zamestnancov, zariadení, systémov, či rôznych externých
elementov. Hlavným cieľom BCP je zamerať sa na udržanie kritických obchodných
procesov v čase neplánovaného výpadku. Celkom určite bude BCP zahrňovať aj IT
infraštruktúru. Z tejto perspektívy je často DRP považované za IT-zameranú logickú
podmnožinu procesu plánovania BC, na ktorú sa v tejto práci budeme tiež zameriavať.
        Plánovanie DR bude pozostávať z týchto 8 fáz:

   1. Iniciácia projektu a výber týmu – Project Initiation
   Zahájenie projektu začína pod vedením predstavenstva, či managementu a pokračuje
   určením project-leadra a výberom tímov pre plánovanie a implementáciu. Sú položené
   jasné očakávania od individuálnych rolí v projekte.

   2. Analýza obchodných procesov – Business Process Analysis
   V tejto fáze je vytvorená kolekcia informácii o business procesoch, ich technickej
   infraštruktúre, závislostiach, či stratégiách používaných inými organizáciami pre
   vyvarovanie sa rizikám.

   3. Analýza rizík a dopadu na obchodnú činnosť – Risk Analysis / BIA
   Analýza rizík spracováva informácie druhej fázy a jej hlavným výstupom je
   porozumenie rizikových systémov, či procesov a hlavne zdrojov potrebných pre ich
   obnovu v určitom časovom rámci. Od tejto časti DRP sa ďalej odvíja tvorba politík pre
   ukladanie dát. Nasleduje analýza dopadu na obchodnú činnosť prevádzanú tímom
   vybraným pre plánovanie, ktorá identifikuje finančné i nefinančné ohodnotenie
   obchodných procesov a podporných aplikácií. Táto analýza je potom využitá pre
   klasifikáciu systémov a tvorí kritický element vyvažovania nákladov na podporu IT
   infraštruktúry na jednej strane a hodnotu strát pri výpadku (downtime) na strane druhej.

   4. Analýza BIA/RPO/RTO - BIA/RPO/RTO Analysis
   Štvrtá fáza DRP sa sústredí na organizáciu obchodných požiadaviek takým spôsobom,
   že jednotlivé systémy, či dáta môžu byť klasifikované ich relatívnou dôležitosťou. Táto

                                                                                          13
   klasifikácia je následne preložená do technickej klasifikácie na základe ktorej sú ku
   každej triede určené požadované RPO, RTO, prípadne NRO. K takto vytvorenej škále
   sú neskôr konštruované politiky pre ukladanie dát.

   5. Tvorba politík – Data protection/Policy Creation
   Tvorba politík je akousi „alfou a omegou“ pre efektívne DR plánovanie so zameraním
   na manažment ukladania dát. Všetky analýzy vypracované v predošlých fázach sú
   kolektívne zlučované, výsledkom čoho sú konkrétne politiky. Tieto sú neskôr
   aplikované pri designe architektúry, či plánovaní kapacity dátových úložíšť.

   6. Plány obnovy – Recovery Plans
   Nasleduje fáza tvorby plánov obnovy, ktorá zahrňuje formuláciu stratégií použitých pri
   obnove systémov, sietí, či aplikácií. Prístupov k stratégiám jednotlivých aplikácii, či
   operačných systémov bude určite v každom prípade niekoľko, neexistuje preto žiadny
   štandard a prístupy sa budú líšiť od jednej organizácie k druhej.

   7. Školenie a testovanie – Training and Testing
   Fáza školenia zamestnancov pod ktorých spadá proces obnovy spolu s testovaním
   vytvorených plánov obnovy, spoločne validujú stratégie používané pri obnove.
   Testovanie plánov ponúka špecialistom akúsi možnosť vyskúšania si rôznych scenárov,
   čím zvyšujú svoje schopnosti a v reálne vzniknutej situácii, kedy sa často pracuje pod
   stresom, pracujú viac sebaisto a bez pochybenia.

   8. Manažment zmien - Change Management
   Nakoniec Change Management poskytuje mechanizmus udržiavania DR plánov
   v aktuálnom stave. Zaisťuje istú spätnú väzbu využívanú pre zaistenie schopnosti
   obnovy z havárie, nezávisle od času výskytu tohto výpadku.

Celkový proces plánovania DR v grafickej podobe zobrazuje Obrázok 2-1.




                                                                                        14
                           Obrázok 2-1 Proces DR plánovania



2.2 7-úrovňový model Disaster Recovery
         V súvislosti s DRP v roku 1992 definovala skupina založená v Los Angeles
s názvom SHARE [46] v spolupráci s IBM „7-úrovňový model Disaster Recovery“ (Seven
tiers of Disaster Recovery), o ktorý sa všetky firmy poskytujúce riešenia DR viac, či menej
opierajú a ktorý si následne detailnejšie popíšeme. Z predchádzajúceho čítania je zrejmé,
že jednotlivé vrstvy DR sa budú líšiť požadovanými hodnotami RTO, RPO vyvažovanými
nákladmi na konkrétne riešenie. Platí lineárny vzťah, na ktorý sa neskôr budeme často
odvolávať: „čím menšie RTO a RPO, tým vyššie náklady a naopak“. Uvedieme teraz
prehľad jednotlivých úrovní modelu SHARE a následne ich detailnejšie popíšeme:

          Úroveň 6 – Zero data loss
          Úroveň 5 – Two-site two-phase commit
          Úroveň 4 – Electronic vaulting to hotsite (active secondary site)
          Úroveň 3 – Electronic vaulting
          Úroveň 2 – Offsite vaulting with a hotsite (PTAM+hotsite)
          Úroveň 1 – Offsite vaulting (PTAM)
          Úroveň 0 – Do Nothing, no offsite data




                                                                                         15
2.2.1 Úroveň 0 – Do Nothing, no offsite data

        Ako napovedá samotný názov najnižšej úrovne modelu DR, nie je na tejto úrovni
nijakým spôsobom definované riešenie zabezpečenia zotavenia z havárie. Vrstva 0 je
charakterizovaná ako riešenie s jedinou lokalitou, bez žiadneho duplicitného hardwaru.
Mnoho krát nie je dokonca riešené ani samotné zálohovanie systémov, či aplikácii
a v kladnom prípade sú tieto zálohy ponechávané v primárnom dátovom centre, čím sa
dotyčné podniky vystavujú hrozbe havárii, z ktorej sa nikdy nemusia spamätať. Vyplýva z
toho tiež nepredvídateľný čas potrebný na obnovu – RTO. Z modernej perspektívy IT je
priam šokujúce, koľko organizácií by sa dalo stále zaradiť práve do tejto úrovne.


2.2.2 Úroveň 1 – Offsite vaulting (PTAM)

        Úroveň 1, tiež označovaná skratkou PTAM (z ang. Pickup Truck Access Method),
už začína riešiť DR zavedením ochrany dát, resp. tvorbou ďalších kópií záloh, určených
pre uskladnenie na bezpečnom mieste, zvyčajne väčšom trezore, v alternatívnej lokalite,
geograficky viac, či menej vzdialenej od primárneho miesta (z ang. offsite). Tým je
dosiahnuté, že v prípade fyzickej straty celej primárnej lokality sú offsite kópie dát použité
pre celkovú obnovu. V realite by sa dalo povedať, že práve tento druh „poistky“ využíva
najväčší počet spoločností a to hlavne kvôli jej relatívne nízkej finančnej náročnosti.
Zrejme najslabším miestom bude práve proces samotného transportu médií, nakoľko môže
byť ťažké určiť kde presne sa dáta nachádzajú v konkrétnom časovom bode.


2.2.3 Úroveň 2 – Offsite vaulting with a hotsite (PTAM+hotsite)

        Ďalšia úroveň prakticky rozširuje o stupeň nižšiu úroveň o horúce miesto – hotsite,
pričom sú zachované všetky ostatné princípy. Ako už bolo vysvetlené, hotsite bude
vybavené dostačujúcim fyzickým hardwarom a sieťovou infraštruktúrou potrebnými pre
obnovu chodu kritických systémov a aplikácií v stave núdzi. Keď čas RTO bol
v predchádzajúcom prípade závislý na čase potrebnom na znovu zaobstaranie potrebného
hardwaru, zníži sa celkový potrebný čas pre obnovu z cca. jedného týždňa na jeden až
niekoľko dní. Je vhodné poznamenať, že hotsite v tomto kontexte bude dátové centrum
v čisto pasívnom stave, do ktorého budú podľa potreby prenesené offsite zálohy dát
a prevedie sa celková obnova.


2.2.4 Úroveň 3 – Electronic vaulting

        Vrstva definovaná anglickým termínom Electronic vaulting opäť dopĺňa
predchádzajúcu vrstvu o funkcionalitu „elektronického skladovania“. Mimo tvorby offsite
kópií dát sa čisto pasívne hotsite z predošlej úrovne mení na akési kvázi aktívne hotsite,
čím rastie réžia pre údržbu a samotný beh. Keďže proces tvorby offsite kópií dát je
prevádzaný s pravidla jednodennou periódou, proces tvorby kópií elektronickou formou je
možné z princípu opakovať tak často ako je potrebné. Dáta sú kopírované do alternatívnej
lokality okamžite, čím sa vyhýba fyzickej manipulácii s médiom, avšak rýchlosť
a priepustnosť sú už závislé od konkrétnych dátových spojov. Preto je electronic vaulting

                                                                                            16
využívaný pri viac kritických aplikáciách, pri ktorých RPO vyžaduje častejšie
duplikovanie dát, ako jeden krát denne.


2.2.5 Úroveň 4 – Electronic vaulting to hotsite (active secondary site)
        Nasleduje vylepšenie predošlej úrovne definovanej ako dva dátové centrá, spolu
prepojené funkcionalitou electronic vaulting. Dôležitým faktom je, že dve počítačové
strediská sú fyzicky oddelené (aj geograficky vzdialené), ale navzájom sú spojené
dátovými spojmi o vysokej šírke pásma. Obidve strany sú v konfigurácií active-active,
z čoho plynie fakt, že medzi dátovými centrami sú po vysoko priepustných optických
spojoch neustále vysielané kritické dáta a tým sa dosahuje v ľubovoľnom momente ich
dostupnosti na obidvoch stranách. Využívajú sa k tomu rôzne techniky zrkadlenia (ďalej
mirroring, v tomto kontexte asynchrónny), replikácie a podobne. Ako neskôr popíšeme, na
tejto úrovni je využívaná hlavne funkcionalita kópií v istom časovom momente (ďalej
snapshot/point-in-time copies), či už na softwarovej úrovni, alebo na úrovni diskových
polí. V kontraste k tomu sú menej kritické, alebo nekritické dáta stále dostupné v offsite
zálohách a v prípade potreby sú opätovne kuriérom prinesené do sekundárneho strediska
pre obnovu. Active-active konfigurácia nakoniec umožňuje tiež využiť rozloženie záťaže
medzi jednotlivé centrá, čo na nižších úrovniach nebolo doposiaľ možné.


2.2.6 Úroveň 5 – Two-site two-phase commit
        Predposledná, šiesta úroveň opäť zakladá na princípoch predošlej, čím predpokladá
dva dátové centrá v režime active-active, s dedikovaným hardwarovým a sieťovým
vybavením, navzájom prepojenými spojmi o vysokej priepustnosti. Navyše pridáva
možnosť držania obrazu (ďalej image) vybraných logických zväzkov s kritickými dátami
na oboch stranách. Vybrané dáta sú uložené v definovaných konzistenčných skupinách (z
ang. consistency groups) na rôznych fyzických dátových storage na oboch stranách..
Požiadavka I/O (I/O Request) o update logického zväzku takto definovanej consistency
group, je považovaná za úspešnú až po potvrdení obidvoma stranami, z toho tiež názov
two-site two-phase commit. Dvojfázové potvrdzovanie môže byť riešené na softwarovej
úrovni, kde je zaistená len integrita transakcií, prípadne na úrovni hardwarovej. Týmto
spôsobom synchronizácie medzi stranami dosiahneme na oboch miestach totožné repliky
dát a v prípade straty primárneho dátového centra prichádzame len o malé množstvo dát,
ktoré boli v čase havárie „na ceste“ pred potvrdením sekundárnou stranou. IBM definuje
pre túto úroveň vo svojich publikáciách potrebnú RTO menej ako 12 hodín [8].


2.2.7 Úroveň 6 – Zero data loss
        Posledná, najvyššia úroveň SHARE modelu DR, predstavuje najsofistikovanejšie
a zároveň kvalite zodpovedajúce najnákladnejšie riešenie zotavenia z havárie. Samotnej
cene je úmerná i dĺžka RTO do niekoľkých minút. Definované sú dva dátové centrá s plne
duplicitným hardwarovým vybavením všetkých systémov spojených navzájom optickými
linkami o vysokej priepustnosti. Duplicitné hardwarové vybavenie je spolu konfigurované
do zhlukov (z ang. cluster) pomocou technológie clustering, čím je proces „prenesenia“ (z
ang. switchover) aplikácie spolu s dátami na záložnú lokalitu plne automatizovaný.

                                                                                        17
Samotné dáta sú potom zvyčajne replikované synchrónnym mirrorom na úrovni samotných
diskových subsystémov a o veci, akými sú kontrola dostupnosti, či pre-mapovanie storage
a podobne sa stará samotná clustrová aplikácia. Pre užívateľa je pritom celý tento proces
transparentný a nemusí dokonca vôbec zaregistrovať výpadok.


2.2.8 Zhrnutie
        Čitateľovi by už malo byť zrejmé, čo sme niekoľko krát avizovali a teda, že so
skracujúcim sa požadovaným RTO zákonite vzrastajú finančné nároky na realizáciu
riešenia a je nevyhnutné vytvoriť akýsi kompromis medzi týmito dvomi aspektmi. V praxi
sa veci javia byť rozdielne ako v teórii a tak sa aj v realite jednotlivé úrovne definovaného
modelu navzájom kombinujú do koncového riešenia. Obrázok 2-2 vyjadruje vzťah medzi
finančnými nákladmi, časom RTO a zároveň situuje do tohto grafu jednotlivé úrovne
modelu DR.




                             Obrázok 2-2 7-vrstvový model DR

        Pre ilustráciu ešte pridávame porovnanie jednotlivých typov „standby“
sekundárnych počítačových stredísk vo vzťahu k ich nákladom na požadovaný hardware
i času RTO (Obrázok 2-3) tak, ako to demonštruje publikácia od Sentryx [5].




                                                                                           18
                  Obrázok 2-3 Porovnanie typov „standby datacenters“



2.3 Postup pri výbere BC riešení
        Pri tvorbe riešenia BC sa po fázach ako analýza rizík, či BIA a nasledujúcou
analýzou stávajúceho prostredia dostávame k výberu konkrétnych riešení BC. V tejto
podkapitole sa budeme snažiť popísať akýsi všeobecný postup aplikovateľný na obecné
prípady. Keďže konkrétnych riešení je pre každú úroveň BC viac než dosť, môže výber
toho správneho a optimálneho znamenať veľké finančné úspory.
        Pre správny výber a kombináciu jednotlivých riešení IT BC rozdelíme tieto
technologické riešenia do piatich domén, ktorým sa v tretej kapitole budeme venovať
detailnejšie, kde vysvetlíme niektoré konkrétne používané technológie:

              1. Servery
              2. Storage
              3. Software a automatizácia
              4. Sieťová a fyzická infraštruktúra
              5. Schopnosti a služby potrebné pre funkčnosť domén 1-4

        Ako primárny nástroj pre organizáciu a usporiadanie produktov a používaných
technológii nebudeme využívať nič iné, ako samotný „7-úrovňový model DR“, nakoľko
i keď sa od času definície tohto modelu (SHARE 1988) zmenili používané technologické
postupy, koncepčná hodnota organizovania týchto technológií podľa ich rýchlosti RTO
zostala stále na mieste. Znamená to, že každá technológia využívaná pri zaisťovaní BC, by
sa dala zaradiť do jednej, prípadne viacerých úrovní modelu DR. Keby sme takto zaradili
do jednotlivých úrovní všetky riešenia od rôznych dodávateľov, rozdelili by sme tieto
riešenia na menšie podskupiny identifikované vyžadovanými hodnotami RTO. Zaradenie
možných používaných riešení do úrovní modelu DR by mohlo potom vypadať napríklad
takto (Obrázok 2-4).




                                                                                       19
                      Obrázok 2-4 Zaradenie riešení do modelu DR

        V praxi by sme zrejme uvažovali o produktoch len niekoľkých dodávateľov
v závislosti od stávajúceho prostredia.
        Ďalším krokom pri výbere riešení BC by malo byť „namapovanie“ obchodných
procesov a s nimi spojených IT aplikácií do modelu DR (so zaradenými riešeniami)
vytvoreného v predchádzajúcom kroku. Pri tomto mapovaní by mali byť procesy
a aplikácie rozdelené do niekoľkých segmentov líšiacich sa požadovaným časom pre
obnovu. IBM vo svojej literatúre [9] odporúča rozdelenie do troch segmentov s názvami
Continuous Availabiliy (nízka/žiadna tolerancia výpadku), Rapid Data Recovery
(priemerná tolerancia výpadku), Backup/Restore (veľká tolerancia výpadku). Niektoré iné
spoločnosti odporúčajú rozdelenie do štyroch, či piatich segmentov, mi sa však v tejto
práci budeme držať doporučení od IBM. Podľa počtu rozdelených segmentov by k nim
určite nemali chýbať aj ich charakterizácie. Charakterizujme teraz niektoré črty našich
tried.

   Continuous Availability
    dostupnosť 24x7 aplikácii spolu s ich dátami (dostupnosť serverov, storage
      i dostupnosť siete)
    plne automatizovaný proces failover (detailnejšie neskôr), prípadne site-failover
    veľmi rýchly a transparentný proces obnovy serverov, storage i siete
    požadované RTO – od niekoľko sekúnd do približne 1 hodiny

   Rapid Data Recovery
    vysoká dostupnosť storage systémov
    manuálny, či automatizovaný failover storage systémov
    rýchly proces obnovy z havárie - z replikovaných diskových storage systémov
    požadované RTO – od jednej do desať hodín
                                                                                         20
   Backup/Recovery
    zálohovanie a obnovy na/z diskov/pásiek
    proces obnovy po havárii výhradne z páskových záloh
    požadované RTO – desať a viac hodín

       Môžeme následne „namapovať“ definované segmenty na náš model DR, ako to
zobrazuje Obrázok 2-5.




                  Obrázok 2-5 Mapovanie tried aplikácií na model DR


        Keď už máme model DR s konkrétnymi riešeniami zaradenými do odpovedajúcich
úrovní spolu s „namapovanými“ definovanými segmentmi aplikácií, môžeme prejsť
k samotnému výberu riešení. S prekrytím dvoch zostrojených modelov získavame užšie
podmnožiny možných riešení, ktoré budeme ďalej zužovať. K tomu aby sme boli schopní
identifikovať riešenie pre konkrétne systémy/aplikácie, musíme položiť niekoľko otázok:

1. Akú aplikáciu je potrebné obnoviť?
2. Na akej HW/SW platforme je aplikácia položená?
3. Aké sú požadované RTO/RPO?
4. Aká je vzdialenosť medzi primárnym a sekundárnym (recovery) zariadením?
5. Aká forma konektivity medzi primárnym a sekundárnym zariadením je dispozícii?
6. Aká je dostupná šírka pásma?
7. Aké je množstvo dát potrebných pre obnovu?



                                                                                      21
       Kombináciou odpovedí na tieto otázky by sme mali byť schopní eliminovať
podmnožinu riešení na niekoľko pár možností, z ktorých už zrejme v každom podniku
budú vyberať podľa stávajúcich podnikových štandardov, zmlúv s dodávateľmi, prípadne
podľa jednotlivých cenových ponúk.




                                                                                   22
                          3 Používané technológie


        Už poznáme model riešenia DR a boli sme oboznámení s postupom pri výbere
konkrétnych riešení, ďalej je potrebné zoznámiť sa s niektorými používanými
technológiami pri zaisťovaní BC&DR. V tejto časti práce si rozdelíme riešenia do piatich
domén, detailnejšie popíšeme niektoré technologické možnosti, či postupy a tiež
vysvetlíme do ktorej odpovedajúcej úrovne modelu DR by sa dali zaradiť. Nakoľko riešení
v tejto oblasti je nespočetne mnoho, od veľa rôznych vedúcich korporácií v oblasti IT, nie
je možné na takto krátkom celku demonštrovať ani len ich väčšinu a preto sa budeme
zameriavať na vysvetlenie princípov, pričom poukážeme na niektoré konkrétne možnosti
od konkrétnych výrobcov.
        Rozdelíme si teda povahu riešení dátových centier a zaistenia ich DR do
nasledujúcich domén:

              1. Servery
              2. Storage
              3. Software a automatizácia
              4. Sieťová a fyzická infraštruktúra
              5. Schopnosti a služby potrebné pre funkčnosť domén 1-4


3.1 Servery
        Keďže základom všetkých počítačových stredísk a samozrejme používaných
aplikácií je výpočtový výkon, budeme sa v prvej časti tretej kapitoly zaoberať v komerčnej
sfére najviac využívanými hardwarovými i softwarovými platformami. Naším cieľom
nebude detailne popísať všetky procesorové architektúry, ale poskytnúť prehľad najviac
používaných druhov hardwarových platforiem i operačných systémov na nich bežiacich. Je
takmer nemožné pár vetami zhodnotiť ktorá platforma je najlepšia a naopak, ktorá
najhoršia, závisí to od mnoho faktorov. Zrejme v každom podniku budú presadzované
rozdielne štandardy preferovaných výrobcov, či druhov architektúr.
        Aj keď sa dá povedať, že určité procesory sú optimalizované pre istý druh
výpočtov, z čoho automaticky plynie ich optimalizácia pre konkrétne druhy aplikácie, vo
všeobecnosti platí z marketingového hľadiska výhodný fakt, že čím viac heterogénne
prostredie, tým väčší výber medzi dodávateľmi a teda väčšia konkurencia medzi nimi pri
snahe presadiť sa. Naopak z perspektívy správcov je najvýhodnejšie čo možno
najhomogénnejšie prostredie a to práve kvôli jednoduchosti administrácie.
        Ďalším kritériom pri výbere konkrétnej platformy je samotný výpočtový výkon,
pričom napríklad pre výpočtovo náročné aplikácie budú ideálnym riešením komerčné
RISCové procesory.


3.1.1 Architektúra x86

       Generickým pojmom x86 je dnes označovaná inštrukčná sada najviac komerčne
úspešnej procesorovej architektúry v histórii PC. Pojem x86 pochádza z historicky

                                                                                        23
označovaných 16-bitových procesorov rady 8086, ktoré boli neskôr doplňované o ďalšie
inštrukcie, pričom bola dodržovaná spätná kompatibilita. Nasledovali rady 386, 486 atď.
spolu s rozšírením na 32-bitovú architektúru. Za hlavných výrobcov architektúry x86 boli
vždy pokladaný Intel a AMD spolu s ich aktuálnymi serverovými procesormi ako Xeon
(Intel), Opteron a Phenom (AMD), ale aj do budúcnosti pripravovanými CPU s kódovým
označením „Bulldozer“ či „Bobcat“. Najviac využívanými operačnými systémami na
architektúre x86 vždy bola rodina produktov od spoločnosti Microsoft s aktuálnym
serverovým riešením Microsoft Windows Server 2003 a novo prichádzajúcou verziou
Microsoft Windows Server 2008, ale zaužívali sa aj iné riešenia, ako napríklad Linux
a Sun Solaris.


3.1.2 SPARC
       SPARC (Scalable Processor Architecture) je architektúra založená na RISCovej
inštrukčnej sade vyvinutá v 80 rokoch Sun Microsystems. Z RISCového designu
vychádzala snaha znižovať inštrukčnú sadu na čo najmenšiu, pričom zameranie bolo
kladené v optimálnom prípade na vykonanie jednej inštrukcie v každom takte procesoru.
Nie len absenciou inštrukcií ako delenie, či násobenie, ale aj mnoho ďalšími bola táto
architektúra dávaná do podobnosti s architektúrou MIPS. Hlavnými producentmi
procesorov tohto typu boli a stále sú Fujitsu i Sun Microsystems s aktuálnym procesorom
UltraSPARC II. Najviac zaužívané operačné systémy pod touto architektúrou boli ako
rodina OS Sun Solaris (aktuálny Solaris 10), tak aj FreeBSD, OpenBSD, či Linux.


3.1.3 PA-RISC
        Dnes už prekonaná architektúra PA-RISC bola vyvinutá firmami HP a VLSI
Technology v 80 rokoch. Ako napovedá samotný názov, architektúra bola založená na
RISCovej inštrukčnej sade, pričom označenie PA bolo odvodené z pojmu Precision
Architecture. Popri architektúre MIPS je už dnes celkom výnimočné stretnúť sa v praxi
s PARISCovými servermi a to aj kvôli faktu, že samotné HP prestalo ďalej túto
architektúru vyvíjať a v roku 2008 končí jej predajom. Zaujímavosťou väčšiny týchto
procesorov bolo, že úplne postrádali L2 cache, ktorá bola nahradzovaná veľkou L1 cache.
Jednou s neskorších vylepšení PA-RISC bolo napríklad zavedenie niektorých vektorových
inštrukcií, čo pridalo výpočtovému výkonu. Primárnym operačným systémom určeným pre
túto architektúru bol UNIXový OS HP-UX, ale neskôr boli prispôsobené aj ďalšie OS ako
Linux, OpenBSD, či NetBSD.


3.1.4 PowerPC
        PowerPC (Performance Computing) je RISCová architektúra založená na IBM
implementácii superskalárnej RISCovej architektúry POWER uvedenej na trh spolu
s RISCovým systémom RS/6000 začiatkom 90 rokov. Superskalárna architektúra
implementovala paralelizmus na úrovni samotných inštrukcii, kde pomocou technológie
pipelining bolo dosiahnuté prevedenie (execute) niekoľkých (podľa počtu pipelines)
inštrukcií za dobu jedného taktu procesoru. IBM využila možnosť vyrábať najrýchlejší
komerčný procesor na trhu a túto vlastnosť si drží aj v aktuálnom čase svojimi p6 (Power6)

                                                                                        24
procesormi z rady pSeries (System p) – pôvodne RS/6000. Optimálne využitie týchto
„silných gigantov“ je navyše znásobené mechanizmom virtualizácie – DLPAR (Dynamic
Logical Partitioning), kde jednotlivým LPARom je možné dynamicky prideľovať
systémové zdroje (pamäť, CPU, I/O interface...) a to bez potreby vypínania. Toto je
dosiahnuté pomocou dedikovaného systému spojeného s RS/6000 nazvaného HMC-
Hardware Management Console. IBM súčasne pre túto architektúru vyvinula vlastný
UNIX-based operačný systém pod názvom AIX (Advanced Interactive eXecutive), ktorého
poslednú open beta verziu 6.1 uviedla na trh v júni 2007. V súčasnej dobe pracuje IBM na
ďalšej verzii tohto komerčne najsilnejšieho RISCového procesoru pod názvom p7.


3.1.5 Blade Centers
        Systémy BladeCenters sú veľkokapacitné, vysokovýkonné, škálovatelné,
multiprocesorové, serverové systémy, špeciálne vyvinuté pre stredné a veľké (enterprise)
prostredia. Táto architektúra zdôrazňuje vysoký stupeň denzity, redundancie, i výkonu a je
založená na zásuvných obvodových doskách označovaných ako „žiletky“ (z ang. Blades).
Všetky Blades figurujú ako samostatné subsystémy s obecne rôznym designom i funkciou
a jedno BladeCenter môže obsahovať niekoľko takýchto obvodov. Pri zaistení stupňa
redundancie je využitý mechanizmus hot-swap a duálne zapojené moduly. Pod pojmom
hot-swap si predstavme schopnosť odobrať a následne vymeniť fyzickú komponentu
systému, ktorá z nejakého dôvodu zlyhala, pričom táto aktivita nemá žiadny dopad na
systém ako celok a je zaistený jeho nepretržitý beh. Pre predstavu si môžme ako analógiu
spomenúť dobre známe rozhranie USB. Celé BladeCenter je redundantne rozdelené na dve
časti (napr. vrchná vs. spodná), pričom obidve časti sú obvodovo nezávislé. Možnosťou je
tiež redundantné zapojenie zberníc ako RS-485, USB, či I2C. Celé BladeCenter je
administrované zo vzdialenosti pomocou management modulu (napr. cez webový
interface) a samozrejmosťou je tiež možnosť redundantne zapojených dvoch takýchto
modulov. Ďalšími redundantne zapojenými modulmi môžu byť Ethernet prípadne Fiber
Switch Modul pre sieťovú komunikáciu a nechýbajú ani duálne páry (pre každú časť jeden
pár) zdrojov elektriny, či duálne zapojené vetráky. Všetky tieto moduly disponujú už
spomenutou vlastnosťou hot-swap, čím je ich výmena pri zlyhaní rýchla, jednoduchá a bez
dopadu na systém ako celok.


3.1.6 Ďalšie platformy
         Do špeciálnej triedy by sa dali zaradiť rôzne či už na zákazku, alebo sériovo
vyrábané a zákazníkom customizované superpočítače určené pre náročné výpočty
(performance computing). V tejto triede by som asi ako jediný explicitne spomenul pojem
mainframe. Pre termín mainframe bol z historických dôvodov zaužívaný pojem „sálových
počitačov“, čo pri modernej miniaturizácii už rozhodne neplatí a dnes zaužívané
synonymum RAS (Reliability,Availability and Serviceability) je absolútne výstižnejšie.
Ako môže už byť zrejmé, dôraz pri týchto systémoch je kladený na redundantnú internú
stavbu vyúsťujúcu do vysoko spoľahlivých a zabezpečených systémov o veľmi vysokej
priepustnosti. Nie je žiadnou raritou, že tieto systémy pracujú nepretržite niekoľko rokov.
Toto je jedným z dôvodov, prečo sú tieto systémy s hovorovým prívlastkom „Big Iron“
nasadzované do kritických prostredí pre spracovávanie obrovského množstva transakcií,
štatistických dát, či ERP systémov.

                                                                                          25
       Vysoká spoľahlivosť mainframov je okrem hot-swap mechanizmu zaisťovaná celou
radou ďalších vymožeností, takže výpadok takmer ľubovoľnej komponenty systému
nespôsobí jeho prerušenie, ale všetko je fixované „za behu“. Virtualizácia je riešená dokonca
na troch rôznych úrovniach a to na úrovni logical partitions (LPARs), virtuálnych strojov (z/VM)
a na úrovni samotného OS (z/OS…). Práve táto dôkladná virtualizácia môže byť príčinou
nasadenia len jediného takéhoto „stroja“ pre celé podnikové prostredie a pre prípad zaistenia BC
potom celé riešenie môže spočívať len v nasadení ďalšieho identického systému v sekundárnej
lokalite. Trh v oblasti mainframes s prehľadom ovláda IBM s ich rodinou produktov zSeries
(System z).
         Hoci od výberu platforiem zaisťovanie BC&DR nie je priamo závislé, závisia od nich
viaceré konkrétne riešenia. Ako príklad si môžeme uviesť rozdiely v možnostiach moderného
trendu virtualizácie serverov. Týmto sme rozobrali najviac používané hardwarové i softwarové
platformy a môžeme postúpiť do druhej, pri zaisťovaní DR najdôležitejšej domény riešení Data
Storage.


3.2 Data Storage
        V tejto časti tretej kapitoly sa budeme detailnejšie venovať technológiám pre
ukladanie dát, navzájom ich stručne porovnáme a vysvetlíme ich kľúčovú pozíciu
a možnosti pri zaisťovaní business continuty. Keďže je trh producentov v oblasti storage
taký bohatý a každý výrobca ponúka vlastnú škálu koncových produktov pod unikátnymi
označeniami, zameriame sa pri výklade konkrétnych riešení na jedného producenta, IBM,
a to z prostého dôvodu. Ako uvidíme v ďalšej kapitole, kde sa budeme zaoberať analýzou
konkrétneho prostredia podniku XYZ, budú v tomto dominantou práve riešenia od firmy
IBM. Najväčšie postavenie na trhu v oblasti Storage zaujímajú okrem spomínanej IBM
tiež spoločnosti EMC, Hitachi, HP, Fujitsu, STK, DLT, či SUN, ku ktorým sa následne
pridávajú hlavní producenti SAN riešení (routers, switches, directors...) Cisco, Brocade
i McData. Faktom tiež je, že mnohokrát každý producent z princípu tie isté technológie
nazýva rozdielnym pomenovaním, aj keď v praxi ich má implementované viac, či menej
rozličným spôsobom, ktorým keby sme sa chceli venovať detailne a navzájom ich
porovnať, zrejme by sme si nevystačili s niekoľkými knižnými celkami.
        Riešenia pre ukladanie dát (data storage) môžeme rozdeliť podľa dvoch kritérií.
Jednak podľa spôsobu pripojenia zdroju dát k dátovému úložišťu, či podľa typu koncového
zariadenia. Podľa prvého kritéria rozdelíme zariadenia pre data storage do troch skupín.
Sú nimi DAS (Direct Attached Storage), NAS (Network Attached Storage) a SAN
(Storage Area Network). Naopak podľa typu koncového zariadenia delíme data storage
riešenia na diskové mechaniky a diskové polia, optické mechaniky a optické knižnice
(jukeboxi), páskové mechaniky a páskové knižnice. Každý typ storage bude mať svoje
výhody ale aj nevýhody a v tejto kapitole sa zameriame na ich porovnanie.
        Ako historicky prvým modelom storage je DAS (Direct Attached Storage). Jedná
sa o model, kde sú samotné storage zariadenia pripojené priamo k serveru. Toto riešenie je
z princípu jednoduché na implementáciu a tiež relatívne nenákladné, avšak veľkou
nevýhodou je, že všetky dáta musia prechádzať samotným serverom, čo nevyhnutne vedie
k nie veľkej výkonnosti systému. Veľkým obmedzením je tiež limitovaná vzdialenosť
storage od samotného serveru a fakt že nie je možné takto pripojené storage prostriedky
zdieľať medzi viacerými servermi, čo vedie k ich neefektívnemu využitiu. Z hľadiska
DR/BC je tento model pripojenia storage nevýhodný, pretože neumožňuje jednoduchý
a efektívny prístup k zálohovaniu a konsolidácii dát. Typickými DAS zariadeniami sú


                                                                                               26
interné disky serverov, prípadne jednoduché diskové polia zapojené v konfigurácii point-
to-point.
        Druhým modelom pripojenia je NAS (Network Attached Storage).
Charakteristickou črtou NAS je, že poskytuje data storage na úrovni súborovej (file level),
ale nie blokovej (block level) ako sme bežne zvyknutí. Výhodou NAS je jej jednoduchosť
implementácie do existujúcej LAN, ku ktorej bývajú väčšinou pripojené, ale aj jej využitie
v heterogénnom prostredí. Podporuje radu široko používaných protokolov, akými sú FTP,
SMB/CIFS, NFS, rsync, či AFP skrze celej škály OS platforiem z radov Windows, Unix,
Apple, Netware a podobne. NAS zariadenia by sa dali vlastnosťami porovnať k tradičným
fileserverom vybaveným s DAS. Disponujú vlastnými CPU, RAM a poskytujú na jednej
strane storage často logicky usporiadaný do redundantných kontajnerov RAID a súborový
systém na strane druhej. Táto skutočnosť je dávaná do kontrastu s modelom SAN, ktorý
poskytuje storage len na block-level úrovni a necháva riešenie súborového systému na
strane klienta. Z file-level úrovne NAS zariadení vyplýva tiež ich využitie hlavne v roli
fileserverov a zároveň ich vylúčenie v použití pri vedeckých výpočtoch, či aplikáciách
databázového typu. Medzi NAS zariadenia na trhu patrí napríklad séria rady od firmy IBM
- N Series, produkty z rady StorageWorks od HP, či rodina produktov Celerra od EMC.
        Posledným, tretím modelom zapojenia storage je SAN (Storage Area Network).
Tento model je kvalitatívne na úplne inej úrovni ako predchádzajúce dva modely.
Vychádza z konceptu dedikovanej špecializovanej siete pre výmenu dát medzi
zariadeniami plne oddelenej od sietí LAN, či WAN, ktorá poskytuje storage na blokovej
úrovni (block-level). Keďže má tento model zásadné postavenie pri zaisťovaní BC&DR,
detailnejšie sa mu budeme venovať neskôr.


3.2.1 Disky a diskové polia
        Pri rozdelení využívaných technológií pre ukladanie dát, je potreba sa pozerať na
viacero parametrov. Jednak je to samotná kapacita média, spôsob a rýchlosť prístupu
k dátam (random-access, sequential-access), spätná kompatibilita, poruchovosť a veľmi
významný parameter TOC (total cost of ownership), ktorý zahrňuje do ceny technológie
všetky aspekty spojené so samotným využívaním technológie (cena straty/obnovy dát,
médií, mechaník, prevádzkové náklady...).
        Ako najlepším médiom pre primárne ukladanie dát sú disky, prípadne diskové
polia. Jedná sa o médium s náhodným prístupom (random-access) k dátam, s rýchlou
dobou vystavenia, z čoho plynú aj ďalšie prednosti tejto technológie práve v prípade
primárneho ukladania dát. Využívaných je viacero štandardov, ako lacnejší a menej
výkonný SATA, ale aj drahšie a výkonnejšie paralelné SCSI, sériové SAS (Serial Attached
SCSI), či FC (Fibre Channel). Nevýhodou diskových mechaník je práve kapacita a nutnosť
ochrany dát pred zlyhaním disku (MTBF-Mean Time Between Failure). Tieto, ale aj
mnoho ďalších problémov riešia práve diskové polia. Jednoducho povedané, diskové pole
je zoskupenie niekoľkých diskov. V IT terminológií sa stretávame ešte s pojmom disk
enclosure, ktorý je od „bežného“ diskového poľa rozdielny tým, že obsahuje vlastnú
pamäť cache a istý stupeň inteligencie. Práve tento stupeň inteligencie hrá pri zaisťovaní
BC&DR kľúčová roľu.
        Moderné diskové polia už od samého základu poskytujú istú úroveň redundancie.
Jednak môžu disponovať už spomenutými hot-swap komponentami pre zaistenie
nepretržitej prevádzky, ďalej vlastnou pamäťou cache, duálne zapojenými zdrojmi energie


                                                                                         27
a vetrákmi, ale hlavne vlastnými radičmi (controller), ktoré tvoria dôležitú súčasť každého
poľa a ktorých môže byť v diskovom poli viac.
        Ako ochranou pred zlyhaním disku je využívanie mechanizmu RAID (Redundant
Array of Independent/Inexpensive Disks) na úrovni samotných diskových polí, čím sú
hosťovské počítače odľahčené od výpočtu I/O operácii, ako je tomu u softwarových RAID.
Existuje veľké množstvo rôznych implementácii RAID, niektoré dokonca patentované
istým výrobcom, avšak všetky využívajúce niektoré z troch prístupov, prípadne ich
kombináciu: striping (rozprestrenie zápisu po pásikoch-stripes), mirroring (zrkadlenie
zápisu), zápis redundantnej informácie-parity. Popri týchto technológiách je využívanou
tiež funkcionalitou hot-spare, kde pri zlyhaní jedného disku zaujme jeho postavenie
záložný disk (spared) a dáta na ňom sú následne dopočítané. Touto funkcionalitou
disponujú aj samotné diskové polia. Okrem známych „tradičných“ RAID 0 – RAID 6,
RAID 01, či RAID 10 sú využívané aj menej známe RAID S (EMC), RAID R, RAID 45,
RAID 7 (Storage Computer Corporation), RAID 1E, či RAID 5EE.
        Takto vytvoreným logickým jednotkám sú následne prideľované LUN (Logical
Unit Number), ktoré sú mapované na WWN (World Wide Name) koncových zariadení, ako
napríklad HBA (Host Bus Adapter). Tento proces autorizácie koncových zariadení
a následného povolenia prístupu k LUN je nazývaný LUN masking. Celé gro veci spočíva
vo fakte, že hosťovské počítače „vidia“ takto namapované LUN ako lokálne pripojené
SCSI disky, pričom o ostatných nemajú vôbec tušenia. Vo väčších prostrediach sú diskové
polia navzájom prepojované pomocou SAN (Storage Area Networks), ktoré popri LUN
maskingu disponujú ďalším prostriedkom kontroly prístupu zoning, ktorý môže byť opäť
implementovaný hardwarovo, či softwarovo. Samozrejme moderné diskové polia
disponujú mnoho ďalšími funkcionalitami, ako front-end caching, či PAV (Parallel Access
Volumes), naším cieľom však nie je detailne ich všetky rozoberať.
        Avšak veľmi dôležitú rolu pri zaisťovaní BC&DR hrajú diskové subsystémy ich
kopírovacími službami (z ang. copy services). Používajú sa tri hlavné techniky: replikácia
dát (zahrňuje synchrónne zrkadlenie a asynchrónne zrkadlenie), point-in-time kópie
logických zväzkov (snapshots) a migrácia dát. Replikácia dát je technika využívaná
v dvoch najvyšších úrovniach modelu DR. Využívajú sa dva typy replikácie a to
synchronous mirroring a asynchronous mirroring, niekedy sa hovorí tiež o semi-
synchronous mirroringu, v závislosti od implementácie.
        Pri synchrónnom zrkadlení je I/O operácia považovaná za dokončenú až po
potvrdení obidvoma stranami, tzn. že lokálny disk potvrdzuje úspešný update až po prijatí
potvrdenia od disku vzdialeného. Výhodou je, že v ľubovoľnom okamžiku sú oba disky
v úplne totožnom stave a v prípade havárie neprichádzame o žiadne dáta. Nevýhodou tohto
riešenia však je jeho obmedzenie na maximálnu vzdialenosť. Keďže svetlo sa v optických
vláknach (sklo) šíri rýchlosťou rovnou 2/3 rýchlosti šírenia svetla vo vákuu, narastajú so
vzdialenosťou aj tieto fyzikou dané latencie šírenia signálu v optických vláknach.
        Pre predstavu napríklad najrýchlejší možný roundtrip na vzdialenosť 10 km je
fyzikálne možný za čas 67 μs, pričom bežná doba zápisu lokálne cachovaných moderných
diskových subsystémov trvá 10-20 μs. Preto môže mať takéto obojstranné potvrdzovanie
I/O operácií veľký degradujúci dopad na celkový systém a je potrebné nasadenie tejto
technológie implementovať s veľkou opatrnosťou.
        Často prehliadaným faktom tiež je, že výpadok sieťového spojenia takto
replikovaných diskov by mal z definície „zero-data-loss“ za následok „zmrznutie“ celého
systému, nakoľko lokálny disk by stále čakal na potvrdenie zo vzdialenej strany, avšak
niektoré dnešné diskové subsystémy sa už vedia vysporiadať i s týmto problémom.


                                                                                        28
Producenti väčšinou podporujú tento typ replikácie do vzdialenosti 100 km, aj keď
uvádzajú možnosť zväčšenia tejto vzdialenosti na špeciálne zákazky.
        Asynchrónny mirroring práve rieši problém obmedzenia vzdialenosti na úkor straty
garancie zero-data-loss, tzn. I/O operácia je považovaná za dokončenú hneď po potvrdení
lokálnym diskom, ktorý už nečaká na potvrdenie zo vzdialenej strany. Opäť sú využívané
dve implementácie. Jednak je to replikácia založená na periodickej tvorbe snapshotov,
v takomto prípade sú periodicky replikované vytvorené point-in-time kópie storage.
V druhom prípade je to niekedy nazývaný semi-synchronous-mirror, kde primárna strana
nečaká na potvrdenie strany sekundárnej, na ktorej sú zmeny realizované s istým
oneskorením závislým na konkrétnom nastavení (bežne niekoľko sekúnd). Takáto
replikácia nemá žiadny dopad na celkový systém, avšak nie je ani možné garantovať
nulové straty dát. Preto je nasadenie tejto technológie obecne možné na ľubovoľnú
vzdialenosť a v praxi je jeho použitie bežne vidieť na vzdialenosti tisícok kilometrov.
        Medzi riešenia vzdialenej replikácie storage patria rodiny produktov ako PPRC
(Peer-to-Peer-Remote-Copy) od IBM, či SRDF (Symmetrix Remote Data Facility) od
spoločnosti EMC, ďalej rodina produktov od Hitachi s názvom TrueCopy/HRC (Hitachi
Remote Copy), prípadne riešenie od Symantecu VVR (Veritas Volume Replicator).
        Druhou využívanou technikou je tvorba point-in-time kópii logických zväzkov.
Tieto sú využívané hlavne vo štvrtej úrovni modelu DR. Point-in-time kópie môžu byť
tvorené popri hardwaru aj softwarovo, napríklad samotným OS (VSS-Windows 2003)
a zaužívaným pre nich bol tiež termín Snapshot. V prípade softwarovo tvorených
Snapshotov by sme mohli zaradiť riešenie do tretej úrovni modelu DR. Existuje viacero
implementácii na úrovni storage. Patrí medzi ne napríklad využitie copy-on-write
mechanizmu, prípadne využitie dočasnej schránky (z ang. repository) pre všetky update
požiadavky počas tvorby point-in-time kópie a následné premietnutie na reálne dáta. Medzi
jednotlivé implementácie od výrobcov patrí napríklad prevedenie od IBM FlashCopy, či
TimeFinder od EMC.
        Pod posledným pojmom využívaným copy services – migrácia dát, si môžeme
predstaviť akúsi skupinu metód využívaných pri presune dát z jedného fyzického disku na
druhý fyzický disk, pričom je zaistený nepretržitý prístup k logickému zväzku a
jeho migrovaným dátam. Napríklad nad týmito dátami môže v čase migrácii pracovať
aplikácia. Týmto je dosiahnuté vyhnutiu sa výpadku, nakoľko dáta sú po celý čas najvyššej
aplikačnej vrstve dostupné.
        Diskové polia sú väčšinou produkované v troch, prípadne dvoch triedach.
Najnižšou triedou je entry-level, pokračujúc triedou mid-range a končiacou najvyššou
triedou enterprise. Niektorí producenti však prvé dve triedy zlučujú a ponúkajú len dve
triedy diskových polí. Rozdiely medzi triedami by už mali byť celkom zrejmé. Jednak sú
veľké odlišnosti v možnostiach rozširovania, s čím súvisí škálovateľnosť, ďalej sú to
možnosti vybavenia hot-swap modulmi, či druhy a počet podporovaných sieťových
rozhraní. Dôležitým faktorom pri výbere diskového poľa je tiež skupina podporovaných
služieb, ako sú copy services, či jednotlivé druhy podporovaných RAID konfigurácií.
Ďalšie rozdiely sú vo veľkosti cache pamätí, ale nebudú chýbať ani rozdiely
v podporovaných topológiach pripojovaných SAN.
        Príkladmi enterprise triedy diskových polí sú rodiny produktov Symmetrix od
EMC, či IBM TotalStorage DS6000/DS8000, rada Storageworks XP od HP, i novinka
z dielne Hitachi - USP V (Hitachi Universal Storage Platform V). Nasledujú produkty
nižších tried DS4000 (IBM), Clarion (EMC), TagmaStore WMS - Workgroup Modular
Storage (Hitachi) a mnoho ďalších.


                                                                                       29
3.2.2 Optické média a jukeboxi
         K optickým médiám sa budeme venovať len stručne, nakoľko nie sú tak
významným médiom vo veľkých prostrediach dátových centier akými sú média páskové.
Optické média slúžia prevažne ako médium pre archiváciu dát a to hlavne z ich princípu
WORM (Write Once Read Many). Doba vystavenia dát môže byť podstatne kratšia
v porovnaní s páskami, nakoľko magnetickú pásku je potrebné previnúť na správny blok.
Zrejme najväčšou nevýhodou pri optických médiách bude ich nedostatok v kapacite a to
platí aj pre aktuálne prichádzajúce štandardy ako Blue-ray, či HD-DVD. Na druhej strane
kladnou stránkou optických médií bude o mnoho nižšia cena TCO, ako je tomu
u páskových technológiách, ktorých cenu TCO zvyšuje hlavne cena mechaník. Optické
média môžu ešte z časti konkurovať páskovým ich nasadením v jukeboxoch, kde sa
o vystavenie média stará robotické zariadenie.


3.2.3 Pásky a páskové knižnice

        Najviac rozšíreným médiom pre sekundárne ukladanie dát, či archiváciu sú páskové
média. Ich najväčšou prednosťou je práve veľkosť kapacity a nakoľko rýchlosť zápisu
či čítania na/z média už nie je dlho úzkym miestom transferu dát, smerovala táto
technológia k prvenstvu pre sekundárne ukladanie. Hlavnou nevýhodou týchto technológií
je cena páskových mechaník a páskových knižníc, ktoré pomocou robotickej ruky –
gripperu poskytujú rýchle sprístupnenie média. Samotné pretočenie pásky však celý proces
vystavenia dát rapídne predlžuje. Využívané sú ako pri archivácii dát (WORM), tak aj pri
zálohovaní (Read-Write). Tieto média so sekvenčným prístupom k dátam prešli v histórii
rozmanitým procesom vylepšovania a postupne sa vykryštalizovali tri najviac využívané
štandardy.
        Prvým formátom je v 80 rokoch 20 storočia vyvinutý DLT – Digital Linear Tape
firmou Digital Equipment a neskôr prebratý spoločnosťou Quantum corp., ktorá v roku
2007 zastavila ďalší vývoj tejto technológie v prospech dnes široko rozšírenej technológie
otvoreného formátu. Aktuálnymi typmi médií sú rady zamerané na výkon DLT-S, kde
média DLT-S4 dosahujú kapacity 800 GB pri rýchlosti toku dát 60 MB/s, či dvojnásobné
hodnoty pri použití hardwarovej kompresii, i optimalizovaná rada na cenu DLT-V
s omnoho nižšími parametrami.
        Druhým široko využívaným formátom je AIT- Advanced Intelligent Tape
vyvinutým a patentom držaným firmou Sony. Jednou z predností AIT pred ostatnými
formátmi je zaručovaná kompatibilita médií s mechanikami niekoľko verzii dozadu
i dopredu, pričom bežnou praxou iných formátov je zaručovaná kompatibilita len o jednu
až dve verzie. Postupne boli média vylepšované na aktuálne kapacity 800 GB, avšak
s menšou rýchlosťou toku dát ako tomu bolo u DLT pri rovnakej kapacite 45 MB/s.
        Dôvodom najväčšieho rozšírenia tretieho páskového formátu LTO – Linear Tape
Open, bola jeho otvorenosť, z čoho vyplývala možnosť výroby mechaník a médií
viacerými producentmi, pričom tieto produkty boli navzájom kompatibilné. LTO začali
spoločne vyvíjať v roku 1997 spoločnosti IBM, Seagate a HP ako alternatívu k dobovým
vedúcim formátom DLT a AIT. Postupne sa vyformovali dve línie LTO.
        Prvá línia s názvom Accelis bola optimalizovaná na rýchlosť prístupu k dátam, čo
bolo dosiahnuté tým, že cartridge obsahoval dve navíjacie cievky, podobne ako formát
AIT. Druhá línia Ultrium naopak optimalizovaná pre kapacitu média, obsahovala rovnako

                                                                                        30
ako DLT jedinú cievku. Neskôr sa ukázalo, že o Accelis nie je na trhu záujem a preto sa
začala presadzovať len rada Ultrium, pričom dnes sa táto automaticky spojuje s termínom
LTO. To tejto technológie boli postupne implementované rôzne ďalšie mechanizmy ako už
spomínaná hardwarová kompresia dát, či korekcia chýb, ale aj hardwarová implementácia
symetrickej 256-bitovej blokovej šifry AES-GCM, ktorá je v súčasnej dobe pokladaná za
bezpečnú. Ako bolo načrtnuté, že rýchlosť dátového toku pri páskových technológiách už
dlho nie je úzkym miestom, tak rýchlosť zápisu rady LTO3 – 80MB/s je vyššia ako
rýchlosť čítania väčšiny HDD, a táto je pri najaktuálnejšej rade LTO4 ešte zvýšená na
120MB/s. Čo sa týka kapacity médií formátu LTO, tak bola s príchodom novej verzie
LTO4 zvýšená zo 400GB na 800GB, pričom za použití kompresie sa kapacita zdvojnásobí.
        Plánované sú už aj verzie LTO5, i LTO6 s nativnými kapacitami 1.6TB, či 3.2TB
a rýchlosťou toku dát až 270MB v prípade LTO6. Samozrejme páskové knižnice sú
pripojované do dedikovaných Storage Area Networks či už cez rozhrania SCSI, alebo FC,
čím je celý proces zálohovania dát vysoko zefektívňovaný a zoptimalizovaný.



3.3 Sieťová infraštruktúra
        Treťou doménou riešení zaisťovania BC&DR je po DataStorage sieťová
infraštruktúra. V tejto doméne budeme predpokladať znalosť v oblasti LAN/WAN za
použitia TCP/IP a budeme sa výhradne venovať sieťam SAN, pričom v druhej časti
popíšeme možné technológie pre vzdialené pripojenie primárnej lokality so sekundárnym
(recovery) zariadením.


3.3.1 Storage Area Networks – SANs

       Asociácia SNIA (Storage Networking Industry Association) definuje pojem SAN
následovne [40]:

„...a network whose primary purpose is the transfer of data between computer systems and
storage elements.“

        SANs pozostávajú z komunikačnej infraštruktúry, ktorá poskytuje fyzické
prepojenia, i z vrstvy manažmentu, ktorá organizuje okrem týchto prepojení aj jednotlivé
storage elementy (diskové polia, páskové mechaniky, knižnice...) a počítačové systémy
tak, aby bol prenos dát efektívny a robustný. SANs sa stali akýmsi doplnkom
k využívaným LANs, či WANs (ktoré navzájom prepojujú jednotlivé servery), čím
vytvárajú dedikované siete práve pre transfer dát medzi storage zariadeniami. Pohľad na
takúto infraštruktúru demonštruje Obrázok 3-1.




                                                                                           31
                               Obrázok 3-1 LAN vs. SAN

       Medzi hlavné výhody SANs patrí zjednodušenie infraštruktúry, ďalej proces
nazývaný ILM (Information Lifecycle Management) a pre nás najdôležitejšie zaisťovanie
BC. Do zjednodušenia storage infraštruktúry môžeme potom zahrnúť celkovú
konsolidáciu, dnes veľmi modernú virtualizáciu, ale aj automatizáciu pri dosahovaní
vysokej dostupnosti. Detailnejšie si teraz popíšeme technológie využívané v oblasti SANs
a súčasne ich namapujeme na referenčný model ISO OSI.


Najnižšie vrstvy SAN v OSI – Fibre Channel

        V prvej časti oddielu SANs sa budeme venovať najnižšej úrovni abstrakcie a to
okrem fyzickej vrstvy aj vrstvám dátového spoju a súčasne vrstve sieťovej. Na týchto
sieťových úrovniach sa popri konvenčnému ethernetovému rozhraniu a v oblasti storage
zaužívanému rýchlemu paralelnému rozhraniu SCSI (Small Computer System Interface),
tiež rozšírilo relatívne nové rozhranie FC (Fibre Channel). Toto sériové rozhranie,
zvyčajne implementované nad optickou kabelážou sa veľmi rýchlo stalo primárnou
architektúrou pre budovanie dedikovaných Storage Area Networks. Jedným z dôvodov, že
sa stal FC tak populárnym je, že hravo prekonal obmedzenie SCSI v maximálnej dĺžke
káblu 25 metrov. Spolu so zvýšením podporovaných rýchlostí prenosu sa FC stal voľbou
číslo jedna pre storage riešenia v podnikovom prostredí.
        Stručne sa dá FC definovať ako rozhranie o vysokej priepustnosti medzi I/O
zariadeniami s procesormi. Je zaistená podpora aplikácii náročných na objem prenášaných
dát. Pôvodne bol FC zamýšľaný pre riešenie prepojenia pracovných staníc so super
počítačmi, avšak výsledkom štandardu bola architektúra kombinujúca sieťovú technológiu
s prepojením kanálov. Špecifikácia FC vzniká pod Americkou normalizačnou organizáciou
ANSI pod záštitou skupiny X3 výboru T11. Zo začiatku sa o podporu vývoju FC starala
skupina FCSI (Fiber Channel Systems Initiative) na čele s firmami ako IBM, HP, či SUN
Mycrosystems, no neskôr ju nahradila asociácia FCA (Fiber Channel Association), ktorá
združovala veľkú skupinu výrobcov v oblasti SAN.


                                                                                       32
        Základom komunikácie v FC je kanál (z ang. channel) buď priamy, alebo
prepínaný dvojbodový spoj. Cieľová adresa v kanáli je pri komunikácii dopredu známa, čo
spôsobuje výrazné zmenšenie komunikačnej réžií, nakoľko odpadáva celá rada funkcií ako
mapovanie fyzických adries na sieťové, ale hlavne smerovanie.
        Architektúra Fibre Channel pozostáva z piatich podvrstiev, kde tradične vrstvy
vyššie stavajú na vrstvách nižších, pričom najnižšie tri úrovne sú predmetom základnej
normy, ktorá definuje systém zložený so vzájomne prepojených uzlov. Každý uzol môže
byť pripojený pomocou n uzlových portov (N port) k prenosovému médiu (F port)
nazývanému tiež „tkanivo“ (z ang. fabric). Týmto je zaistená jedna z vlastností FC-
multipathing, tj. násobnosť možných ciest pre dátový tok, pomocou ktorej je dosiahnutá
redundancia dátových spojov a v prípade, že jedna cesta je narušená, využije sa cesta
alternatívna a čo je dôležité, pre koncové uzly je táto skutočnosť transparentná. Päť
vrstvový model pozostáva z vrstiev:

      FC-4   mapovanie (protocol mapping layer)
      FC-3   Vrstva spoločných služieb (common services layer)
      FC-2   Vrstva signalizácie (network layer)
      FC-1   Vrstva prenosu (data link layer)
      FC-0   Fyzická vrstva (physical layer)

        Fyzická vrstva definuje typ prenosového média (koaxiálny kábel, krútená
dvojlinka, jednovidový i mnohovidový optický kábel), podporované rýchlosti (1, 2, 4, 8,
10 Gbit/s) a tiež používané konektory. Vrstva dátového spoja rieši predovšetkým
kódovanie signálu a problémy s ním spojené. Ako kódovanie je použité kedysi patentom
chránené a vlastnené firmou IBM 8B/10B, ktoré osminu bitov kóduje do postupnosti
desiatich bitov. Tretia signalizačná vrstva rieši problémy akými sú inicializácia, riadenie
toku dát, detekcia chýb, enkapsulácia dát do rámcov, smerovanie ale aj multiplexing.
Poskytuje vyšším vrstvám tri triedy prenosu: prepínanie okruhov, prepínanie rámcov
a datagramovú službu. Riadenie toku dát je riešené formou kreditného schématu, kde
každý vysielajúci dostáva určitý počet kreditov odvodený z veľkosti cache prijímajúceho,
čím sa vyhýbame problémom spojeným so zaplnením vyrovnávacej pamäti prijímajúceho.


Stredné vrstvy SAN v OSI

        Do stredných vrstiev ISO OSI modelu zahrnieme a popíšeme vrstvu transportnú
a vrstvu relačnú. Na týchto vrstvách je využívaných niekoľko štandardizovaných
protokolov. Okrem tradičného FCP (Fibre Channel Protocol), či FCIP (Fibre Channel
over IP) boli možnosti rozšírené aj na iSCSI (Internet SCSI), či iFCP (Internet Fibre
Channel Protocol) a vylepšený bol relatívne starý ESCON (Enterprise Systems
Connection) štandardom FICON (Fiber Connectivity). FCP je v podstate implementácia
známeho storage protokolu SCSI na rozhraní Fibre Channel.
        Tak ako sa stal TCP/IP akousi asociáciou pre ethernet, stal sa tiež FCP pre Fibre
Channel (samozrejme je možná aj implementácia FCP na ethernete). Relatívne modernú
možnosť zníženia nákladov pri budovaní SANs ponúka už spomenutý transportný protokol
iSCSI, ktorý nesie SCSI príkazy od iniciátora k cieľu pomocou sietí TCP/IP, čím umožňuje
implementáciu IP-based Storage Area Networks, ktoré však môžu predstavovať radu
nevýhod oproti natívnym FC SANs (napr. dobu round trip). Výsledkom snahy
o implementáciu FC po IP sieťach sú tunelované riešenie FCIP a smerované riešenie iFCP.

                                                                                         33
         Keďže FCIP používa enkapsuláciu FC bloku dát a následne ho transportuje cez
TCP, je toto riešenie zvlášť vhodné pre vzdialené prepojenie FC-based SANs pomocou IP
sietí, nakoľko samotný FC nie je nahradený, ale len tunelovaný cez IP. Druhé riešenie
prepojenia FC SAN zariadení prostredníctvom IP sietí – iFCP, je gateway-to-gateway
protocol, ktoré opäť pre problémy ako riadenie zahltenia, detekciu, či obnovu z chyby
využíva protokol TCP. iFCP dovoľuje pripájať koncové SAN zariadenia priamo do IP sietí
pomocou transparentných gateways, čím uľahčuje napríklad proces migrácie natívnych
FC-SAN na IP-SAN, prípadne umožňuje ich kombináciu. Tak ako sa stal FCP štandardom
pre open-systems, stal sa protokol FICON štandardom v oblasti monolitických high-
performance počítačových systémov mainframes (z/Architecture), kde nahradil relatívne
starý protokol ESCON. V podstate nemá FICON okrem kompatibility s architektúrou Z
žiadne výhody pred FCP, avšak je stále nevyhnutne potrebný pri nasadení niektorých
špecifických riešení, ako napríklad pri zaisťovaní BC v oblasti mainframes rozšírený
GDPS (Geographically Dispersed Parralel Sysplex).


Najvyššie vrstvy SAN v OSI

        Do posledných, najvyšších vrstiev modelu OSI zahrnieme vrstvy prezentačnú
a aplikačnú. Túto problematiku sme už z časti vysvetlili v predchádzajúcej podkapitole,
kde sme sa venovali rozdeleniu typov datastorage. A teda služby SANs z perspektívy
najvyšších vrstiev ISO OSI, môžeme rozdeliť na Server-attached Storage a Network
Attached Storage. V prvom prípade je storage zariadenie priamo pripojené k zbernici
serveru pomocou adaptéru HBA (Host Bus Adapter) a server si samotný robí kontrolu nad
I/O operáciami. Z počiatku takto zapojené diskové, či páskové storage zariadenia nemali
integrovanú žiadnu vlastnú inteligenciu, avšak evolúcia viedla k nasadení kontrolných
jednotiek, ktoré začali poskytovať určitý stupeň inteligencie a prevádzať funkcie ako
cacheovanie I/O požiadaviek, funkcionalitu RAID, ale aj mnoho ďalších významných
pokročilých funkcionalít.
        V prípade NAS, ako už bolo povedané, je storage poskytujúci služby na úrovni
súborovej (file-level). Samotné zariadenie NAS pozostáva z hnacieho motoru, ktorý
implementuje súborové služby a jedného či viacerých zariadení pre ukladanie dát. NAS
napríklad dovoľuje dynamické pridanie ďalších HDD do siete, ktorá už je využívaná
servermi bez nutnosti ich vypínania. NAS zariadenia sa často pripojujú priamo do sietí
LANs, čo automaticky znamená menej nákladnú implementáciu zo strany serverov
(ethernet adaptéry sú lacnejšie ako FC adaptéry...). NAS ďalej môže byť ideálnym
riešením pre zdieľanie súborov uložených na SAN koncovým užívateľom (pripojených cez
IP) v prípadoch, kde by bolo nasadenie čistého FC neefektívne drahé a mohlo by byť
nasadené napríklad riešenie premostenia týchto dvoch svetov pomocou NAS gateway.


SAN virtualizácia

       Asociácia SNIA definuje pojem storage virtualization ako [40]:

„The act of integrating one or more (back-end) services or functions with additional
(front-end) functionality for the purpose of providing useful abstractions. Typically
virtualization hides some of the back-end complexity, or adds or integrates new
funtionality with existing back-end services....“

                                                                                        34
        Virtualizácia storage je proces abstrakcie logického storage od storage fyzického
za účelom získavania rady výhod, okrem iného aj pri zaisťovaní BC&DR . Takéto
predstavovanie sa storage naberá v realite formu virtuálnych diskových LUNs (Logical
Unit Number), ktoré sú hostiteľom transparentne prezentované ako SCSI diskové jednotky
(pozn.: LUN ako taká môže už byť ako vlastný logický disk). Rozlíšiť môžeme tri úrovne
virtualizácie storage (Obrázok 3-2 Úrovne virtualizácie storage).




                        Obrázok 3-2 Úrovne virtualizácie storage


        Virtualizáciu na úrovni storage už dnes poskytujú takmer všetky diskové systémy
tým, že mapujú logické zväzky na fyzické disky, prípadne skupiny diskov. Hlavnou
výhodou je optimalizácia pri snahe maximálneho využitia fyzického storage. Avšak
veľkým obmedzením takejto virtualizácie je jej ohraničenie len na jeden takýto storage
systém a nemožnosť rozprestrenia medzi viaceré.
        S virtualizáciou na úrovni serverov sa už možno aj nevedome stretol snáď každý
z nás. Takáto úroveň abstrakcie je väčšinou implementovaná priamo v operačnom systéme
v rámci LVM (Logical Volume Management), kde je možné okrem logických diskov
podľa typu LVM vytvárať aj niektoré základné RAID konfigurácie.
        Posledným typom virtualizácie storage na úrovni SAN „tkaniva“ (z ang. Fabric) je
vo veľkých podnikových (z ang. enterprise) prostrediach najefektívnejšie
a najsofistikovanejšie riešenie. Umožňuje totiž celkovú nezávislosť storage od
heterogénneho serverového prostredia tým, že virtualizuje celú storage pre hostiteľov ako
jeden celok. Vyplýva z toho automaticky obrovská výhoda klenutia storage pozdĺž obecne
n rôznych diskových subsystémov od rôznych výrobcov. Tým je samozrejme dosiahnuté
veľmi efektívne využitie storage prostriedkov, ale aj možnosti dynamickej škálovateľnosti

                                                                                       35
takpovediac „za behu“, teda jednoduchého rozširovania storage. Ďalším obrovským
prínosom virtualizácie na úrovni fabric, je práve využitie pri zaisťovaní BC&DR a to
pokročilými vymoženosťami SAN (z ang. advanced SAN features), ako AutoSiteFailover,
tvorba už spomínaných Point-In-Time images a hlavne v najvyšších úrovniach modelu DR
využívaných možností zrkadlenia storage po SAN. Niektoré z týchto funkcionalít už
v sebe implementujú aj samotné diskové systémy, typicky najvyššie Enterprise triedy,
avšak ich využitím by sme opäť ostali limitovaní len v oblasti jedného konkrétneho
subsystému. Ako príklad Fabric-Level virtualizačných produktov by som uviedol riešenie
Invista od spoločnosti EMC, či produkty SVC (SAN Volume Controller) a N series
Gateway od producenta IBM.


3.3.2 Technológie vzdialeného pripojenia
        Popri už bežne využívajúcemu modelu dvoch lokalít (z ang. Two-site Recovery) sa
moderný trend uberá smerom k modelu Three-site Recovery, pričom hlavne vo vyšších
úrovniach modelu DR hrá pri storage networking, či data mirroring infraštruktúre kľúčovú
úlohu práve sieťové prepojenie jednotlivých lokalít. Aj keď sa môže zdať rýchlosť šírenia
svetla „nekonečná“, je dôležité mať na zreteli, že rýchlosť šírenia svetla v skle (optické
vlákno) je rovná približne 2/3 rýchlosti šírenia svetla vo vákuu a tým vstupuje do hry popri
dôležitej dostupnej šírke pásma aj ďalší parameter a to latencia. Práve latencia môže byť
veľmi problémovou výzvou, pretože na rozdiel od šírky pásma, zvyšovaním investícii do
vyšších rýchlostí neznížime súčasne latenciu. Menovite pri niektorých formách
synchrónneho zrkadlenia môže už byť čo i len pár milisekúnd latencie navyše úplne
neakceptovateľné kvôli dopadu na systém ako celok. Stručne si následne popíšeme
technologické možnosti používané pre vzdialené prepojenie dátových centier.
        V súčasnosti by už malo byť každému jasné, že sa obmedzíme výhradne na optické
dátové prenosy, nakoľko metalické by už dlhú dobu neboli ani z ďaleka dostačujúce.
V princípe sú pre zaistenie vysokorýchlostného optického spojenia n dátových centier dve
možnosti a to prenajatie dedikovaného vlákna, či využitie sietí SONET (Synchronous
Optical NETwork), v Európe známych po pojmom SDH (Synchronous Digital Hierarchy).
Hoci štandardy SONET a SDH nie sú úplne identické, budeme ich nateraz pokladať za
ekvivalenty.
        Dedikované vlákno je typicky privátne vlastnená optická cesta, v ktorej v kontraste
so sieťami SONET putuje svetlo len v prípade, keď jej vlastník do nej zapojí koncové
zariadenia. Samozrejme obrovskou výhodou je plné využitie šírky pásma takéhoto vlákna,
nakoľko nie je nikým zdieľané. Na druhej strane si táto alternatíva vyžaduje vyššie
náklady, nielen zvyčajnou potrebou nasadenia niektorej formy multiplexingu, ale aj pri
zaisťovaní BC&DR nutnosťou prenajatia dvoch takýchto fyzicky odlišných optických ciest
kvôli eliminácii single-point-of-failure. Keďže táto sekundárna cesta bude takmer určite
dlhšia ako primárna, je potrebné pri robení výpočtov na sieťové požiadavky počítať s tou
dlhšou, nakoľko táto môže ľahko reprezentovať náš najhorší scenár. Ako akýsi kontrast
k tomuto riešeniu môžeme uviesť pojem tmavé vlákno (z ang. dark fiber), čo je v podstate
položené vlákno, avšak do teraz nepripojené k žiadnym zariadeniam a očakávané
k budúcemu využitiu. Prívlastok dark-tmavé je práve z dôvodu, že vláknom neprechádza
žiadny svetelný signál.
        Druhou možnosťou je využitie sietí SONET/SDH, čo je štandard prenosu dát
využívajúci infraštruktúru verejných telekomunikačných okruhov. Typicky firma
požadujúca pripojenie uzavrie kontrakt s telekomunikačnou spoločnosťou, prípadne

                                                                                          36
s poskytovateľom pripojenia na dané množstvo šírky pásma. Veľkou výhodou týchto sietí,
je ich redundantná stavba, nakoľko výpadok niektorého z uzlov nespôsobí výpadok celej
siete a tok dát bude presmerovaný opačným smerom okruhu. Jednou z možností
zefektívnenia dátových prenosov cez siete SONET môže byť napríklad využitie niektorej
z metód channel extension.
         Takmer nevyhnutnou súčasťou pri prenajatí dedikovaného vlákna je nasadenie
metódy pre zefektívnenie jeho využitia pre súčasný prenos viac kanálov v jeden časový
okamžik WDM-Wavelenght Division Multiplexing. Biele svetlo putujúce optickým
vláknom je rozložené do širšieho spektra farieb každé s inou vlnovou dĺžkou. Všetkým
pripojeným zariadeniam je potom pridelená vlnová dĺžka (známa ako lambda) a WDM
následne všetky lambdy vysiela vláknom súčasne v rovnakej oblasti svetelného spektra
okolo 1550 nanometrov. Toto umožňuje prepojenie viacerých zariadení pomocou jedného
páru single-mode optického vlákna.
         Sú známe dve varianty WDM a to CWDM, i DWDM. Coarse Wavelenght Division
Multiplexing rozprestruje jednotlivé lambdy ďalej od seba, čo vedie k menšiemu počtu
možných lambd (normálne 8), na druhej strane je však táto technológia výrazne lacnejšia
ako DWDM. Drahší Dense Wavelenght Division Multiplexing sa naopak snaží lambdy
priblížiť čo najbližšie k sebe a dnešné štandardy definujú využitie až 32 lambd súčasne. Pre
dosiahnutie ešte vyššej efektivity prenosu, je možné WDM ďalej kombinovať s ďalším
typom multiplexingu, napríklad časovým TDM (Time Division Multiplexing) apod. Bežné
nasadenie WDM dovoľuje dátové prenosy do vzdialenosti cca. 60 km a pre väčšie
vzdialenosti je nutné použiť prídavné aktívne prvky. Jednak sú to optické zosilovače, ktoré
jednoducho zosilujú svetelný signál a dovoľujú prenosy na stovky kilometrov, prípadne
môžu byť využité regeneratívne opakovače, ktoré svetelný signál prevedú na signál
elektrický, ten očistia od šumu a následne opäť prevedú na signál svetelný.
         Je teda potrebné počítať s nevyhnutnou šírkou pásma, ale aj akceptovateľnou
latenciou. V termínoch storage hovoríme o parametre data rate, ako o množstve dát
v jednotkách B, KB, či MB prenesených za jednotku času (MBps). Na druhej strane šírka
pásma sieťového spoju je hodnotená v jednotkách Kbps, Mbps, Gbps, ako množstvo bitov
schopných preniesť týmto spojom za jednotku času. Moderné diskové i páskové zariadenia
zvládajú data rate 80-90 MBps, čo pri odporúčanom prepočte (nie 1:8, ale 1:10) dáva šírku
pásma 800 Megabitov. Počítanie s latenciou môže však byť ďaleko ťažšie.
         Spravme si malú ilustráciu. Rýchlosť svetla vo vákuu c=3*108m/s, čo je
ekvivalentné 3.3μs/km. Rýchlosť šírenia svetla optickým vláknom je rovné 2/3*c, čo je
v prepočte približne 5μs/km. Dostávame sa k závislosti od použitého protokolu. Napríklad
zápis SCSI cez FCP potrebuje celkom dve roundtrips na každú I/O operáciu. Jednoduchým
prepočtom 2(roundtrips)*2(operácie)* 5μs/km=20μs/km dostávame dodatočnú latenciu
dvadsať mikrosekund každej SCSI I/O pri vzdialenosti jedného kilometra. Vo vzdialenosti
50km je latencia rovná už jednej milisekunde (1 ms) pre každú I/O. Na ilustrácii vidíme
nežiaduci dopad latencie pri nasadení synchrónneho zrkadlenia, načo budú senzitívne
najmä aplikácie s častými a krátkymi I/O požiadavkami, typicky transakčné databázy. Pri
nasadení synchrónnej replikácie potrebujeme teda zistiť „profily zápisov“ jednotlivých
serverov, ktoré budú do replikácii zahrnuté. Pri takýchto kalkuláciách nás budú menovite
zaujímať priemerné, ale aj „peak“ hodnoty počtu bajtov zapísaných na disk za sekundu
a tiež počtu I/O požiadaviek za jednotku času. Pomocou takýchto profilov potom budeme
schopní vypočítať našu potrebnú šírku pásma, ale aj maximálnu akceptovateľnú latenciu.




                                                                                         37
3.4 Software a automatizácia
       V poslednej doméne riešení BC&DR sa budeme venovať softwarom využívaných
pri manažmente dát, z nich detailnejšie popíšeme práve jeden, vysvetlíme pojem BMR
(Bare Machine Recovery) techniky zotavenia z havárie a nakoniec sa budeme venovať
technológii pre zaisťovanie vysokej dostupnosti – Clusteringu.


3.4.1 Tivoli Storage Manager
        Okrem tradičnej správy dát je aj proces zálohovania už nekrátku dobu pokladaný za
nevyhnutnú súčasť moderných dátových centier všetkých veľkostí. Spolu s rastom objemu
dát rastie aj komplikovanosť ich manažmentu. Preto začali takmer všetky popredné firmy
v oblasti IT storage vyvíjať aj software pre zálohovanie a správu dát veľkých enterprise
prostredí. Správna voľba tohto softwaru môže hrať pri plánovaní BC&DR kľúčovú rolu,
nakoľko pri strate primárneho počítačového centra bude hlavne v nižších úrovniach DR
modelu prevádzaný proces obnovy na sekundárne zariadenie práve pomocou takejto
aplikácie. Dnes medzi popredné patria predovšetkým IBM Tivoli Storage Manager (TSM),
Veritas NetBackup, EMC Networker, či Dataprotector od HP. Detailnejšie si popíšeme
niektoré z funkcionalít IBM TSM, nakoľko ako uvidíme v ďalšej kapitole, práve tento
bude nasadený v produkčnom prostredí riešeného podniku.
        IBM TSM je mocná skupina SW produktov v oblasti storage, ktorá adresuje výzvu
komplexného zálohovania, obnovovania a manažmentu dát skrz veľké heterogénne
prostredia. Podporuje viac ako 44 rôznych OS platforiem a okrem centralizovanej správy,
či plne automatizovanej ochrany dát (zálohovanie) podporuje aj vysoko-rýchlostné
automatizované obnovy rôznych typov (súborové systémy, databázy, či iné špecializované
dáta) a popritom zaisťuje plnú kompatibilitu so stovkami storage zariadení na LAN, WAN,
i SAN infraštruktúre. Nasledujúci obrázok sumarizuje jednotlivé komponenty TSM.




                             Obrázok 3-3 komponenty TSM


       TSM je produkt architektúry server-client postavený na relačnej databáze a ako
väčšina moderných aplikácií v sebe implementuje mechanizmus obnovy z havárie
pomocou transakčného logu. TSM databáza bude teda pri obnove z havárii najkritickejším

                                                                                       38
setom dát, nakoľko obsahuje informácie o všetkých držaných objektoch na páskach, či
diskoch a bez nej nie je možné obnoviť čo i len jeden súbor, nakoľko vo väčšine prípadov
budú dáta uložené v šifrovanej podobe (TSM podporuje DES i AES-Rijndael) s kľúčom
uloženým v tejto databáze. Všetky zálohované dáta ukladá TSM do objektov zvaných
storage pools, ktoré môžu byť na jednej strane primárne (s náhodným prístupom,
i prístupom sekvenčným) a kópie primárnych na strane druhej s využitím práve pri offsite
vault zálohovaní.
        Pravidlá pre manažment dát sú implementované pomocou presne definovaných
politík, ktorými sa riadi expirácia starých nepotrebných dát. Ďalšou integrovanou súčasťou
TSM je modul HSM (Hierarchy Storage Manager). HSM poskytuje tzv. hierarchický
manažment dát, kde konkrétne dátové objekty (napr. nevyužívané po istú dobu) postupne
migrujú z jednej hierarchickej úrovni na ďalšie, napríklad z diskov na menej nákladný
storage (pásky...), pričom celý tento proces je pre OS transparentný a pre užívateľov OS sú
migrované objekty neustále dostupné ako stubs, pričom pri vyžiadaní práce s týmto
objektom je opätovne migrovaný späť na primárny storage. Dôležitými modulmi pre TSM
sú špecializované moduly pre komerčne využívané aplikácie (mailové, ERP, či databázové
aplikácie) zvané TDP (Tivoli Data Protection), ktoré výrazne uľahčujú zálohovanie
aplikačných dát „za behu“, bez nutnosti vypnutia aplikácie. Pri plánovaní BC&DR je
dôležitým TSM modulom DRM (Disaster Recovery Manager), ktorý sa stará o správu a
životný cyklus médií určených pre offsite zálohy, i o plánovanie DR celého TSM serveru,
pričom automaticky generuje plán obnovy (z ang. Recovery Plan) spolu so scriptami
potrebnými pre automatizáciu obnovy.
        TSM ako ochranu databázy pred istými chybami v sebe implementuje dve
funkcionality. Sú nimi TSM database page shadowing a v praxi viac využiteľným TSM
database and recovery log mirroring. Okrem týchto funkcionalít TSM podporuje celú radu
ďalších mechanizmov pre optimalizáciu zálohovania, i obnovu pri DR. Sú nimi popri
bežným typom zálohovania (progresívne inkrementálne, selektívne, diferenciálne,
adaptive-subfile, journal-based, i image) aj špecializované typy záloh pre optimalizáciu
záťaže CPU, či LAN a to zálohy LAN-free (Obrázok 3-4), Server-free (Obrázok 3-5), Split-
mirror/point-in-time copy using SAN (Obrázok 3-6), ale aj zálohy NAS-based.




                                                                                         39
                            Obrázok 3-4 zálohy LAN-free

       Lan-free typ zálohovania je využívaný v prostrediach s dedikovanými SAN
komunikačnými sieťami, kde pre dátový prenos medzi zálohovaným serverom a TSM
serverom je použitá práve SAN namiesto LAN. Takýto presun dát potom nezaťažuje CPU
TSM serveru, a súčasne uvoľňuje od záťaže LAN. Po sieti LAN putuje len komunikácia
typu vyžiadanie namontovania média apod.




                           Obrázok 3-5 zálohy Server-free

                                                                                 40
        Zálohovanie Server-free uvoľňuje popri CPU TSM serveru a siete LAN, ako tomu
bolo u LAN-free aj CPU zálohovaného serveru, nakoľko oba serveri nemusia prenášané
dáta ani čítať, ani zapisovať. O samotný transfer dát sa stará zariadenie pripojené do SAN,
SAN Data Gateway, označované tiež termínom datamover, ktoré pomocou adresovania
jednotlivých LUNs prenáša dáta priamo prostredníctvom SAN. Na takýto typ zálohovania
je však kladené obmedzenie, že môžu byť prenášané len images zväzkov a nie individuálne
súbory.




                   Obrázok 3-6 zálohy Split-mirror/point-in-time copy


        Tento typ záloh priamo využíva hardwarovú implementáciu point-in-time obrazov
v diskových subsystémoch. Diskové pole vytvorí okamžitú kópiu logického zväzku, ktorá
je následne zazálohovaná TSM serverom opäť prostredníctvom SAN. Obrovskou výhodou
je znovu odklonenie záťaže z hostiteľského serveru aplikácie, pričom aplikácia môže
naďalej spracúvať užívateľské požiadavky.
        Poslednou vymoženosťou TSM, ktorú explicitne spomenieme je server-to-server
komunikácia medzi niekoľkými TSM servermi. Táto okrem logovania, či monitorovania
udalostí viacerých TSM serverov poskytuje pri zaisťovaní BC&DR mechanizmus zvaný
electronic vaulting (úrovne 3 a 4 modelu DR). Princíp spočíva vo fakte, že TSM server
v primárnej lokalite vytvára kópie primárnych storagepoolov na virtual-volumes, ktoré
figurujú v TSM serveru v sekundárnej lokalite ako sekvenčné súbory. Tým je dosiahnuté,
že kópie dát sú na sekundárnej DR lokalite okamžite a nie je potrebný ich fyzický presun
ako pri metóde PTAM.




                                                                                         41
3.4.2 BMR Techniky
        Do štvrtej domény riešení Software a automatizácia by sme mali po správnosti
zaradiť tiež všetky „3rd party“ softwarové produkty, ktoré budeme nasadzovať pri
obnovách BMR, prípadne pri ďalších špecializovaných riešeniach ako napríklad možnosť
od IBM GDPS-Geographically Dispersed Parallel Sysplex, prípadne GDDR-
Geographically Dispersed Disaster Restart od EMC a iné. Pojem BMR (Bare Machine
Recovery, niekedy tiež Bare Metal Recovery) bol zavedený pre obnovu celého serveru
(včítane OS), v prípade kde sme všetko stratili (možná aj fyzická strata serveru v prípade
havárie) a obnovujeme takpovediac „od nuly“. V takýchto prípadoch sa využíva rôzny
dodatočný software, prípadne rôzne mechanizmy implementované priamo v OS (napr.
Automated System Recovery v MS Windows 2003 Server) pomocou ktorého sa vytvárajú
zálohy (napr. image systémových partícií) a prevádzajú obnovy v prípade havárie. Keďže
rada konkrétnych možností je široká a závislá od viacerých faktorov, nie je priestor
vysvetliť všetky a explicitne spomenieme nami navrhované riešenie BMR v poslednej,
piatej kapitole – Návrh riešenia, pri konkrétnom navrhovanom riešení.


3.4.3 Clustering
        Čo je to vlastne Cluster? Cluster - z prekladu anglického slova zhluk – je skupina
počítačov, ktorá spoločne klientom poskytuje skupinu zdrojov. Môže sa jednať o zdroje
diskové, výpočtové, v praxi najčastejšie vo forme prístupu ku konkrétnej aplikácii. Cluster
sa môže skladať a pozostáva minimálne z dvoch, z obecného hľadiska z n fyzických
systémov (hostiteľov). Kľúčovým bodom clusteringu je, že klienti nemajú žiadne znalosti
o spodnej fyzickej hardwarovej vrstve clustru. Toto v podstate znamená, že ľubovoľné
zmeny na fyzickej vrstve sa pre klientov zdajú byť transparentné, respektíve sa o nich
vôbec nedozvedajú a tento fakt prináša radu veľkých výhod.
        Najväčšou a v praxi tiež najdôležitejšou výhodou je práve zaistenie vysokej
dostupnosti. Poskytované zdroje v Clustrovom prostredí pre klienta figurujú ako vysoko
dostupné zdroje v neClustrovom prostredí. Keď sa uzol v Clustru stáva nedostupným alebo
príliš zamestnaným pre odpovedanie na požiadavku o zdroj, je táto požiadavka
transparentne presunutá na uzol schopný ju spracovať. Klienti si preto nie sú vôbec vedomí
presnej lokality zdrojov, ktoré práve využívajú. V jednoduchom príklade môže klient
žiadať prístup k databázovej aplikácii bez toho, aby sa zaujímal o to na ktorom fyzickom
serveri bude jeho požiadavka spracovaná.
        Ďalším benefitom Clusteringu je škálovatelnosť. Keď napríklad behom času
potrebujeme do systému pridávať nových užívateľov, prípadne aplikácie, pričom chceme
zachovať výkon celého systému, riešením bude v takomto prípade pridanie nového uzlu do
Clustru ako súčasť celého systému. Typickým príkladom by mohol byť napríklad
informačný systém, ktorý cez webové rozhranie vybavuje užívateľské dotazy.
        Zdroje v Clustru sú organizované do skupín - Resource Groups a tie sú následne
prideľované k jednotlivým uzlom. Jednotlivé uzly spolu komunikujú a predávajú si signály
(napr. o ich dostupnosti) pomocou tzv. Cluster Heartbeat (tlkot srdca) a môžu figurovať
v konfiguráciách buď active-active alebo active-passive. V prípade, že aktívny uzol zlyhá,
sú skupiny ktoré hosťoval transferované na ďalší uzol v Clustru, ktorý môže byť vybraný
napríklad podľa priority. Tento proces sa nazýva failover. Naopak jemu reverzný proces je
nazývaný failback. Rozlišujeme nasledovné štyri druhy Clustrov:


                                                                                         42
        1. Shared nothing cluster
Tento typ Clustru je definovaný ako systém dvoch, alebo viac nezávislých fyzických
serverov s prístupom k spoločnému storage, avšak operujúcimi nad vlastnými zdrojmi
(disk, aplikácia...). Pre klientov je pritom celý systém viditeľný ako jedna entita. Uzly
môžu pracovať ako v konfigurácii active-active, tak aj active-passive. V prvom prípade
uzly pracujú nad vlastnými dátami i aplikáciami, pričom v prípade druhom pasívny uzol
čaká v stave standby, aby mohol prevziať v prípade failoveru rolu aktívneho uzlu.
Príkladmi tohto typu Clustru sú väčšinou aplikácie na úrovni operačného systému ako
napríklad MSCS-Microsoft Cluster Server (Windows), ktorý v súčasnosti nie je
považovaný za príliš efektívny a spoľahlivý, či IBM HACMP-High Availability Cluster
Multiprocessing (AIX) založený na technológii RSCT (Reliable Scalable Cluster
Technology), ktorá je súčasťou operačného systému AIX.




                           Obrázok 3-7 Shared Nothing Cluster


       2. Common shared cluster
Hlavný rozdiel od prvého typu Clustru spočíva v tom, že všetky uzly Common shared
clusteru pristupujú súčasne k rovnakým dátam i ostatným prostriedkom (resources)
Clustreru. Keďže viacero uzlov zároveň pristupuje k prostriedkom, samotný Cluster musí
byť opatrený funkcionalitou pre zaistenie konzistencie. Tu sa používajú rôzne mechanizmy
pre zamykanie dát, ale aj udržiavanie cache coherency (koherencia vyrovnávacích pamätí).
Jedným z príkladov druhej triedy Clustrov je vymoženosť DB2 v prostredí z/OS –
Datasharing.




                                                                                            43
                          Obrázok 3-8 Common Shared Cluster


        3. (Shared nothing) Application cluster
Tretí typ Clustru pozostáva z farmy na sebe nezávislých uzlov, ktoré sa navonok tvária ako
jediná entita. Dôležitými črtami sú, že všetky uzly pracujú nad vlastnými dátami a záťaž
medzi nimi distribuuje load-balancer. Najznámejšími aplikáciami v tejto oblasti sú
rozhodne CITRIX a IBM riešenie aplikačného serveru WebSphere.




                    Obrázok 3-9 Shared Nothing Application Cluster




                                                                                        44
        4. Geographically dispersed clusters
Asi najviac využívaným typom Clustru pri zaisťovaní BC je geograficky rozptýlený
cluster. Predchádzajúce typy nám vždy zaisťovali dostupnosť aplikácie v rámci jedného
dátového centra, ale čo keď nastane havária, ktorej následkom bude strata celého
primárneho zariadenia? Práve tento typ havárie rieši Geographically Dispersed Cluster,
ktorý rozširuje doterajšie modely Clusterov o funkcionalitu zrkadlenia Storage na
sekundárnu-disaster lokalitu. Zrkadlenie môže byť realizované buď na úrovni host-based
(softwarový mirroring) ako napríklad využitie LVM (Logical Volume Manager), alebo na
úrovni samotného Storage (hardware mirroring). Po strate primárnej lokality sú potom dáta
dostupné na zrkadlenom zväzku v sekundárnej lokalite, pričom klienti vôbec nemusia
zaznamenať výpadok. Ako príklad tejto triedy by sme mohli spomenúť architektúru
GDOC (Geographically Dispersed Open Clusters), prípadne riešenie v prostredí
mainframes (System Z family) od IBM GDPS-Geographically Dispersed Parallel Sysplex,
ale existujú aj rozšírenia už spomínaných cluster riešení MSCS a HACMP na model
geografických clustrov a to Majority Node Set (MNS) v prvom prípade, či HACMP/XD
(High Availability Cluster Multiprocessing eXtended Distance) a HACMP/HAGEO
v prípade druhom.




                      Obrázok 3-X Geographically dispersed cluster


        Technológiu Clusteringu môžeme v modelu DR zaradiť do poslednej najvyššej
úrovni, nakoľko je pomocou nej možné vybudovať a nakonfigurovať plne automatizovaný
proces udržania dostupnosti systémov, či aplikácií a to obecne po n geograficky
vzdialených lokalitách. Veľmi dôležité tiež je uvedomiť si pri akom druhu zlyhania nám
táto technológia pomáha. Clustering nechráni dáta pred logickými chybami, či ľudským
faktorom. Preto integrita transakcií, či konzistencia dát musí byť riešená funkcionalitou na
inej úrovni a dnes už takmer všetky moderné, komerčné aplikácie disponujú takýmto
mechanizmom (transakčné logy...). Na trhu je dnes veľa produktov tohto typu od rôznych

                                                                                          45
producentov líšiacimi sa napríklad v podpore platformy, možnosťou integrácií s ďalšími
modulmi, či inými aplikáciami, ale hlavne vymoženosťami samotného softwaru. Príkladmi
sú v heterogénnom prostredí podporovaný VCS-Veritas Cluster Server, IBM HACMP-
High Availability Cluster Multiprocessing (AIX), HP ServiceGuard Cluster (HP-UX),
ďalej SUN Cluster Softwre (Solaris), ale aj menej používaný NCS-Novel Cluster Services
(Netware 6.5).




                                                                                    46
             4 Analýza prostredia a potrieb podniku


       Nasleduje štvrtá kapitola, v ktorej budeme prevádzať analýzu reálneho prostredia
fungujúceho podniku, na ktorú bude nadväzovať návrh konkrétneho riešenia, prípadne
viacerých riešení. Len pripomenieme, že z dôvodov udržania anonymity riešeného podniku
budeme tento nazývať menom XZY. Rozdelíme analýzu do niekoľkých štrukturálnych
celkov podľa konkrétnej oblasti riešení.


4.1 Fyzická infraštruktúra
        Analyzované produkčné prostredie je zložené z dvoch dátových centier, fyzicky
oddelených a vzdialených od seba cca. 200 metrov. Obidve zariadenia splňujú všetky
atribúty moderných dátových centier ako po stránke vybavenia, tak aj po stránke
zabezpečenia a ich prevádzka je vzájomne na sebe plne nezávislá. Samozrejmosťou sú
naddimenzovaná klimatizácia, duálne záložné napájanie ako aj naftové generátory
elektrického prúdu, kvôli eliminácii single-point-of-failure. Nasledujú protipožiarne,
i protipovodňové zabezpečenia miestností pripojené k senzorom, vybaveným obvodmi pre
ohlasovanie udalostí. Nechýba metóda autentizácie pri fyzickom vstupe do zariadenia,
ktorá je implementovaná ako dvojfázová kontrola vlastníctva tokenu (čipová karta) spojená
s preukázaním znalosti tajnej informácie (PIN), kombinovaná s kamerovým systémom. Za
istý spôsob autentizácie založenej na biometrikách (fyzický vzhľad) sa dá pokladať aj
nevyhnutne predchádzajúci prechod vstupom do celkového zariadenia v kontakte so
strážnou službou.
        Prvým dôležitým faktom teda je, že zlyhanie prvého zariadenia, nebude mať žiadny
dopad na funkcionalitu druhého, pokiaľ dosah havárie nepresiahne 200 m. Prívetivá je tiež
možná nezávislosť od verejnej infraštruktúry (elektrina, plyn...). Je jasné, že sa jedná
o model dvoch prepojených dátových centier geograficky vzdialených pár stovák metrov
a po ďalšej analýze bude už zrejmé, že analyzované prostredie bude samo o sebe
poskytovať vysoký stupeň fault-tolerance a to aj z hľadiska zaisťovania BC&DR.


4.2 HW/SF platformy
       Celková výpočtová infraštruktúra by sa dala rozdeliť do dvoch častí a to Unix-
based i Windows-based platforiem. Kombináciou z širšej škály HW/SF platforiem si
podnik zaisťuje nezávislosť pri výbere hardware od jediného výrobcu.
       Základ Unix-based infraštruktúry je tvorený servermi od SUN Microsystems,
konkrétne modelmi Sun-Fire-V210, Sun-Fire-V440, či Sun-Fire-V490 vybavenými
procesormi z rád UltraSPARC, UltraSPARC IIIi, i UltraSPARC IV, doplnenými Midframe
modelmi Sun-Fire-3800, pracujúcimi s technológiou symetrického multiprocesingu nad 4
až 8 procesormi. Nasadený je operačný systém SUN Solaris vo verziách 9 i 10.
V niektorých prípadoch sú využívané formy virtualizácie na úrovni OS, tzv. zoning, takže
jedna globálna zóna je virtualizovaná do niekoľkých lokálnych zón. Nasleduje niekoľko
málo modelov od HP z rady HPDL385G2 vybavených architektúrou x86, konkrétne
procesormi AMD Opteron. Ako platforma OS je použitá distribúcia Linuxu. Pre kritické

                                                                                       47
aplikácie náročné na systémové zdroje je nasadené mid-range špičkové a robustné riešenie
od firmy IBM v podobe jednej jednotky „IBM System p 570“ v každom datovom centre,
ktoré navyše v oboch prípadoch dopĺňa „IBM System p 520“. Každá p570 pritom
pozostáva zo štyroch modulov osadených štyrmi najmodernejšími, komerčne dostupnými
procesormi POWER6 a dvoch HMC konzolí (eliminácia SPOF) využívaných pri
optimalizácii výkonu vo forme virtualizácie na LPARs -Logical Partitions. Ako operačný
systém je nasadený pre pSeries natívne vyvinutý AIX vo verziách 5.4 a ešte stále aktuálnej
5.3. Podobne ako je tomu u p570, sú aj všetky ostatné servery Unix-based infraštruktúry
duplikované po oboch datových centrách, na ktorých je potom riešený buď load-balancing
aplikácií, prípadne zaisťovanie vysokej dostupnosti.
        Celá Windows-based infraštruktúra je tvorená výhradne modelmi z rodiny
produktov xSeries od firmy IBM. Nasadené sú rackmounted modely IBM x336, x3850,
x340, či x3650, štandardu 1U prípadne 2U s nasadenými dvoj-jadrovými procesormi od
Intelu Xeon. Všetky tieto modely, až na pár výnimiek stand-alone serverov s málo
kritickými aplikáciami, sú podobne ako v prípade Unix-based duplikované po oboch
zariadeniach. Súčasťou Windows-based domény sú tiež Blade Centers s vysokou denzitou,
modelu IBM BladeCenter H Chassis v počte dva kusy pre každé datové centrum. Tieto sú
vybavené „žiletkami“ architektúry x86 a to modelov IBM HS20 osadenými procesormi
Xeon na jednej strane a modelov IBM LS20 vybavenými Opteronmi od AMD na strane
druhej. Počet procesorov je v každom prípade závislý od požadovaného výkonu
prevádzanej aplikácie. Ako OS platforma je takmer v 100% prípadoch nasadený MS
Windows 2003 Server s niekoľkými pár výnimkami už prekonaných MS Windows 2000
Server.
        Ako vidíme, pri takomto relatívne vysoko heterogénnom prostredí, bude potreba
zvoliť viacero odlišných prístupov riešenia DR (BMR procedúr) a to minimálne pre tri
základné OS platformy SUN Solaris 10, IBM AIX 5.3 i MS Windows 2003 Server.


4.3 Sieťová infraštruktúra LAN
        Oba datové centrá sú prepojené linkou o vysokej priepustnosti a tvoria spolu
internú LAN. Celá interná LAN je pripojená k internetu prostredníctvom dvoch
nezávislých poskytovateľov internetových služieb (ďalej ISP) – eliminácia SPOF. Celú
internú sieť teda môžeme označiť termínom multi-homed, čo opäť pridáva na robustnosti
a spoľahlivosti analyzovaného prostredia. O správu trafiky multi-homed siete sa stará
nasadené riešenie od firmy Radware - LinkProof, ktoré popri rozloženiu záťaže poskytuje
súčasne prvotnú úroveň zabezpečenia proti útokom a to ochranu pred útokom DoS (Denial
of Service – odoprenie služby), prevenciu pred vniknutím IPS (Intrusion Prevention
System), či rôznymi útokmi nultého dňa zero-day attacks (Floods, Pre-attack probes,
Spyware, Worms, Viruses...). Celkové zabezpečenie prostredia doplňuje produkt
DefensePro (Radware), ktoré tiež popri DoS a IPS poskytuje aj spoľahlivejšiu ochranu
proti útokom nultého dňa a „prieskumu bojom“. Ochrana proti zero-day útokom je
založená na signatúrach a inteligentnej heuristike, ktorá analyzuje chovanie siete a detekuje
odchýlky od bežného chodu, prípadne na ne vyvíja reakcie.
        Nasleduje firewall na prvej úrovni v podobe smerovača od spoločnosti Cisco, ktorý
oddeľuje externú demilitarizovanú zónu (nazývaná tiež perimeter network) od internetu.
Táto pozostáva z hostiteľov a služieb adresovaných a prístupných v internete (DNS,
www...). Externá DMZ je nakoniec od internej oddelená network layer firewallom, ktorý
zároveň plní funkciu prekladu sieťových adries. V roli tohto firewallu vystupuje populárne,

                                                                                          48
dnes už ale proprietárne riešenie Cisco PIX (Private Internet Exchange). Relevantnú časť
sieťovej infraštruktúry popisuje Obrázok 4-1 Schéma sieti LAN.




                             Obrázok 4-1 Schéma sieti LAN



4.4 Storage, SAN
        Všetky nasadené modely serverov sú pripojené zbernicou SCSI k vlastným
diskovým jednotkám formou Direct Attached Storage. Tieto sú využívané pre uloženie
menej kritických „bežných“ dát ako operačný systém, či iné aplikácie. Výnimku tvoria
BladeCenters, ktoré nedisponujú nijakým diskovým subsystémom a pracujú nad dátami
uloženými na dedikovanej SAN. Zahrňuje to aj samotný proces zavádzania operačného
systému boot. Všetky dáta považované za kritické (aplikačné dáta, databázy...) sú uložené
na konsolidovanom úložišti SAN topológie Switched Fabric, do ktorého sú pripojované
všetky servery pomocou optických HBA.
        Opäť podobne ako tomu bolo u LAN i SAN rozprestrená po oboch dátových
centrách tvorí jeden logický celok, pri ktorom je prístup ku zdrojom kontrolovaný na
dvoch úrovniach abstrakcie a to ako jednak zónovaním, tak aj maskovaním LUNs. Celá
SAN je postavená na rýchlych optických vláknach a využíva špičkovú sieťovú technológiu
Fibre Channel. Na sieťovej vrstve FC2 bol zvolený natívny protokol FCP (Fibre Channel
Protokol), ktorý vysoko efektívne prenáša komunikáciu SCSI. Celková SAN sa skladá
z dvoch nezávislých Fabrics, čo opätovne vedie k eliminácii SPOF, nakoľko je umožnené
využitie násobných dátových ciest (multipathing), ale aj algoritmu pre výpočet najkratšej
cesty FSPF – Fabric Shortest Path First (tento ale v analyzovanom prostredí nebude mať
signifikantný význam) v konjunkcii s algoritmom štandardizovaným IEEE - spanning-tree.
Funkciu jadrových core switchov zastávajú dva vysoko redundantne navrhnuté SAN
directors triedy enterprise v podobe modelov IBM TotalStorage SAN256B, ktoré

                                                                                           49
navzájom spojujú oba dátové centrá. Tento spoj je pre každú Fabric realizovaný pomocou
trunkovaných ISL (Inter-switch-link) cez E_ports tak, aby bola umožnená paralelná
komunikácia šírky 32Gbps. Do týchto core-switchov sú priamo pripojené BladeCenters
trunkovanými ISL šírky 8Gbps, všetky Storage zariadenia a nechýbajú ani všetky
hostiteľské serveri. Vzhľadom k počtu hostiteľov leží medzi nimi a core-switchom ďalšie
rozšírenie SAN v podobe jedného edge-switchu triedy mid-range pre každú Fabric,
konkrétne modelu IBM TotalStorage SAN32B-2. Tieto spoje sú podobne ako v predošlom
prípade realizované pomocou trunkovaných ISL do šírky 8Gbps. Celá SAN je popri
všetkému virtualizovaná na úrovni Fabric pomocou virtualizačného hardwaru IBM SAN
Volume Controller (SVC).
        Všetky Storage zariadenia pripojené do SAN sú duplikované po oboch dátových
centrách so vzájomne nakonfigurovanou a obojsmernou synchrónnou replikáciou.
Nasadené sú ako modely triedy mid-range IBM System Storage DS4300, DS4700,
DS4800, tiež označované pojmom FastT, tak aj vysoko redundantné diskové subsystémy
najvyššej triedy enterprise IBM System Storage DS8100 pracujúce nad symetrickým
multiprocesingom procesorov POWER5. Každé dátové centrum je nakoniec vybavené do
SAN pripojenou vysoko škálovateľnou knižnicou IBM System Storage TS3494,
pozostávajúcou z dvoch frames a obsahujúcou 12 LTO3 mechaník. Celková záťaž
zálohovania je potom distribuovaná a vyvažovaná po oboch knižniciach.
        V tejto časti analýzy je dôležité sa tiež zamerať na podporované copy services zo
strany nasadených diskových polí pre prípad potenciálneho nasadenia replikácie pri
zaisťovaní BC&DR. Modely z rady DS4000 poskytujú tri základné služby a to Flashcopy,
Enhanced Remote Mirroring a VolumeCopy. V prvom prípade sa jedná o možnosť
vytvárania point-in-time konzistentných kópii zväzkov. Vymoženosť Enhanced Remote
Mirroring zahrňuje všetky typy replikácii a posledná funkcionalita VolumeCopy je
využívaná pri migrácii dát z/do rôznych diskových systémov. Druhé, enterprise modely
z rád DS8000 poskytujú tiež okrem point-in-time kópií (Flashcopy) aj podporu Metro
Mirror (synchrónna replikácia), Global Mirror (asynchrónna replikácia) a Global Copy
(Global Mirror s asynchrónnou konzistenčnou skupinou), takže bude možné pri návrhu
riešenia počítať aj s potencionálnym nasadením niektorého druhu replikácie, prípadne s ich
kombináciou. Z dôvodu komplexnosti tejto časti analýzy ešte doplníme podporované copy
services IBM SAN Volume Controlleru, ktorý popri flashcopy podporuje aj PPRC (Peer-
to-peer-remote-copy) a to v obidvoch variantách (synchrónne i asynchrónne). Celkový
pohľad na SAN je zobrazený modelom na Obrázku 4-2 Schéma sieti SAN.




                                                                                        50
                              Obrázok 4-2 Schéma sieti SAN


4.5 Nasadený software/aplikácie
        Vysoká dostupnosť všetkých aplikácií považovaných za kritickú je dosahovaná
behom v clustrovom prostredí. Na jednej strane je to produkt MSCS (Microsoft Cluster
Services) pre Windows-based infraštruktúru doplnený o HACMP (High Availability
Cluster Multiprocesing) pre pSesies. Clustering je riešený vždy systémom, že jeden uzol je
fyzicky umiestnený v rozdielnom dátovom centre ako jeho uzol partnerský a pracuje vždy
v pasívnom stave čakajúc na failover.
        Na výpočtové zdroje najnáročnejšie je nasadenie systému pre Enterprise Resource
Planning, konkrétne v podobe najrozšírenejšieho v tejto skupine SAP (Systems,
Applications and Products in Data Processing). Implementovaných je niekoľko desiatok
instancií na databázovej platforme Oracle, pričom niektoré sú viac, niektoré menej kritické
a zaberajú od niekoľko desiatok GB až do dvoch TB na instanciu. Budeme ich označovať
skratkami SAP1-SAP30. Kvôli náročnosti aplikácie je využité HW platformy pSeries
spolu s HACMP pre najviac kritické instancie.
        Oracle vo verziách 9 a 10 poskytuje i zázemie pre niekoľko ďalších aplikácii,
v podobe instancií ako na OS AIX 5.3 tak aj na OS Windows 2003 Server (budeme značiť
ORA1-ORA4). Ako druhá hlavná relačná databáza (RDBMS) je nasadené riešenie od
Microsoftu MSSQL vo verzii SQL Server 2005. Kritické instancie MSSQL opäť pracujú
v clustrovom prostredí MSCS a najväčšia nepresahuje 80 GB (budeme značiť SQL1-
SQL8).
        Ako mail server je implementovaný MS Exchange Server v nie celkom aktuálnej
verzii 2003. Tento opäť pracuje v prostredí MSCS na Windows platformách (3+3 uzly)
a je rozložený na 1.5 TB dátového priestoru.

                                                                                         51
        Základné služby dostupné i z Internetu ako DNS, SMTP či WWW sú
implementované v prostredí SUN Solaris (Miranda, Apache…) a využívajú radu malých
databáz typov PostgreSQL, či MySQL.
        Nakoľko je zálohovanie už dlhšiu dobu pokladané za nevyhnutnú súčasť
moderných dátových centier, stará sa o celkové automatizované zálohovanie software od
IBM – Tivoli Storage Manager vo verzii Extended Edition 5.4. Tento je konfigurovaný v
prostredí HACMP na p520 (1+1 uzol). TSM distribuuje celkové zálohovanie po oboch
knižniciach TS3500 a v niektorých prípadoch využíva špecializované zálohy pre
optimalizáciu – LAN-Free, menovite u najväčších instancií SAP. Pre všetky špecializované
dáta so špecifickým prístupom k online zálohovaniu (databázy...) sú využívané moduly
TDP (Tivoli Data Protection).


4.6 Návrh tried aplikácii podľa požadovaného RPO/RTO

        Ďalším krokom analýzy bude navrhnutie tried aplikácii podľa požadovaného
RPO/RTO, ktorému bude nasledovať namapovanie samotných aplikácii do konkrétnej
triedy zodpovednými ľuďmi vo vedení. Mapovanie bude závislé od vykonaných analýz
obchodných procesov, rizík a dopadu na business, ktorými sa detailnejšie zaoberať
nebudeme. Navrhnutú skupinu tried aplikácií z hľadiska zaisťovania BC&DR spolu s ich
orientačným popisom zobrazuje nasledujúci Obrázok 4-3 Triedy aplikácii podľa
RPO/RTO.
  Class Max. RTO Max. RPO Description

 C1     4h           Approx 0     “Hot” recovery solution
                                  -hotsite, cluster systems, storage-based synchronous
                                  replication
 C2     1day         1day         “Warm” recovery solution
                                  -warmsite, daily storage-based sync. or async. repli.
                                  of data volumes and OS snapshots, offsite active
                                  servers
 C3     3days        1day         “Warm” recovery solution
                                  -warmsite, daily PTAM / storage-based replication,
                                  OS snapshots, offsite inactive servers
 C4     7days        1day         “Cold” recovery solution
                                  -coldsite, vendor HW supply contracts, daily PTAM
                                  offsite backups
 C5     40days       1day         “Cold” recovery solution
                                  -coldsite, no supply contracts, daily PTAM offsite
                                  backups
 C6     40days       7days        “Cold” recovery solution
                                  -coldsite, no supply contracts, weekly PTAM offsite
                                  backups
 C7     >40days      <7day        No BC/DR solution
 C8     >40days      >7days       No BC/DR solution


                     Obrázok 4-3 Triedy aplikácii podľa RPO/RTO
                                                                                       52
       Dalo by sa možno diskutovať na tému nedostatku počtu rozličných tried, avšak
z nášho pohľadu navrhnuté triedy splňujú celkovú komplexnosť rôznych RTO/RPO a budú
plne postačovať pre korektné zaradenie všetkých kritických aplikácií.


4.7 Mapovanie fault-tolerantných aplikácií do tried
        Pri mapovaní aplikácií do navrhnutých Recovery tried bude potreba rozlišovať
pohľady z dvoch perspektív. Tou prvou je zaisťovanie vysokej dostupnosti, ktorá v návrhu
bude musieť ostať zachovaná. Táto zabezpečí fault-toleranciu aplikácií voči logickým
chybám, či obecne chybám všetkým mimo fyzickej straty primárnej lokality. Druhým
pohľadom bude práve odolnosť prostredia a zaistenie zotavenia voči najhoršiemu scenáru
straty produkčného prostredia. V tomto prípade nás zaujíma perspektíva druhá.
        Z predchádzajúcich procesných fáz vyplynulo nasledovné zaradenie aplikácií
z pohľadu plánovania DR&BC. Do najvyššej Recovery triedy neboli zaradené žiadne
aplikácie. Vlastnosti triedy C2 sú vyžadované u piatich instanciách SAP1-SAP5 spolu so
štyrmi databázami SQL1-SQL2. RPO a RTO triedy C3 sú nevyhnutné popri dvoch databáz
SQL3-SQL4 i u ďalších dvoch instancií SAP6-SAP7. Predĺženého RTO triedy C4 sa
budeme opierať u ďalších dvoch ERP instancií SAP8-9. Na riešenie „cold recovery
solution“ tried C5 i C6 boli namapované mailové služby MS Exchange spolu s webovými
službami. Nakoniec do posledných tried C7 i C8 zaradíme všetky ostatné aplikácie,
ktorých obnova bude riešená postupne až po ukončení všetkých predošlých tried,
prihliadajúc k faktu, že táto obnova nebude nijak plánovaná a garantovaná (napr. opätovná
celková inštalácia spojená s vkladaním dát).




                                                                                       53
                                5 Návrh riešenia


        Dá sa povedať, že z analýzy vyplýva nasadený koncept dvoch dátových centier
so vzájomnou synchrónnou replikáciou a oba dva zariadenia si medzi sebou navzájom
poskytujú záložnú - disaster lokalitu. Sú tu však tri slabé miesta.
        Tým prvým je rozloženie zálohovania po oboch dátových centrách, z čoho vyplýva
fakt, že všetky zálohy sú fyzicky uložené buď v jednej alebo druhej knižnici, nie v oboch
súčasne. Teda fyzická strata jednej z knižníc, prípadne celého zariadenia, by síce neviedla
k strate produkčných dát (je implementovaná replikácia), ale spôsobila by nevyhnutnú
stratu záloh uložených v dotyčnej knižnici. Aj keď sú dotknuté „len“ zálohy, môže ich
strata znamenať veľmi dôkladný a bolestivý „úder pod pás“. Predstavme si napríklad
prípad archivovaných dát z účtovníctva, na ktorý sa vzťahujú rôzne legislatívne
ustanovenia. Pre vyriešenie tohto slabého miesta navrhnime teda zaobstaranie štyroch
dodatočných LTO3 mechaník IBM TS2230 pre každú knižnicu, ktoré umiestnime do
ďalšieho Framu, čím zároveň získame aj nové páskové sloty. Všetky denne nové
zazálohované dáta by sme automatizovane každý deň kopírovali v TSM z primary storage
poolov na copy storage pooly v druhej knižnici. Dve mechaniky by pracovali jedným
smerom, dve opačným. Spolu s nasadenou replikáciou by sme mali dosiahnutú existenciu
všetkých dát na oboch lokalitách v ľubovoľný okamžik. Takto si budú obe dátové centrá
skutočne navzájom poskytovať plnohodnotnú Disaster lokalitu.
        Druhým slabým miestom je relatívne malá fyzická vzdialenosť obidvoch lokalít
(cca. 300m). Ako vidíme implementované prostredie je síce vysoko fault-tolerantné, ale
len v prípade logických chýb, či naozaj lokálnych havárii s dopadom len do cca. 250
metrov. Je teda potrebné pristúpiť k modelu fault-tolerantnému na väčšiu vzdialenosť
(metro, regional, global). Pre tento účel bola vybraná lokalita v oblasti metro (do 50km),
vzdušnou čiarou vzdialená približne 15 km. V ďalšej časti kapitoly navrhneme niekoľko
riešení práve počítajúc s touto Disaster lokalitou v oblasti metro.
        Na záver posledným tretím slabým miestom je fakt, že v analyzovanom prostredí
nie sú implementované Geographically Dispersed Clusters, takže všetky uzly v clustru
pracujú i po vykonaní failoveru nad identickým storage. Z pohľadu zaisťovania DR&BC
nebude tento fakt síce dôležitý, nakoľko nie sú vyžadované žiadne riešenia aplikácií
v najvyššej Recovery triede, avšak ako uvidíme ďalej v jednom z navrhnutých modelov
(Two-site model) bude nevyhnutné zakomponovať do clustrov pri vykonaní failoveru (z
dôvodu udržania vysokej dostupnosti kritických aplikácií ) aj funkcionalitu premapovania
storage.


5.1 Návrh riešení Recovery tried
        Aplikácie v najsofistikovanejšej Recovery triede C1 si budú nevyhnutne vyžadovať
v záložnej lokalite hotsite s plným HW vybavením schopným ustáť plnú záťaž. Nulová
tolerovaná strata dát môže byť dosiahnutá jedine storage-based synchrónnou replikáciou
a dvojfázovým potvrdzovaním I/O operácií dátových zväzkov do záložnej lokality
a v prípade havárie by nastalo premaskovanie záložných vyreplikovaných LUNs za
primárne, nad ktorými by bola nasledovne pustená aplikácia opäť na HW v záložnej
lokalite. Keďže max. hodnota RTO rovná štyrom hodinám je príliš nízka pre

                                                                                         54
administrátorov na manuálne vykonanie potrebných úkonov (treba počítať s časom
detekcie havárie, ohlásenia havárie, analýzy havárie, zlyhanie ľudského faktoru...), bude
potrebné nasadenie clustrovej aplikácie. Keďže pôjde o Geographically Dispersed Cluster,
použijeme HACMP vo variante HACMP-XD (extended distance), ktoré samo o sebe
požadovanú funkcionalitu implementuje.
        V prípade MSCS budeme mať na výber v princípe jednu z troch možností, keďže
pri havárii bude quorum MSCS clustru nedostupné a sám cluster by sa z toho nespamätal.
Prvou z možností bude pripravenie dávkových scriptov, ktoré premapujú všetky zväzky
(včetne quorum) na zväzky replikované a následne nad nimi naštartujú aplikáciu. Tieto
budú potom spúšťané manuálne niektorým z administrátorov. Druhou možnosťou bude
nasadenie MSCS v konfigurácii Majority Node Set, pri ktorom je quorum uložené lokálne
a nie na zdieľanom úložisti SAN. Jeden z uzlov v takto nakonfigurovanom clustru (fyzicky
umiestnený napr. v Disaster lokalite) bude plniť úlohu sledovača a rozhodovača o nových
aktívnych uzloch pri failoveru. Mali by sme teda vytvorené dva uzly v primárnej lokalite
(jeden pre každé dátové centrum), ktoré by boli rozhodovačom preferované a dva ďalšie
uzly v Recovery lokalite, preferované v prípade strany primárnej. Prípadne by sa tento
MNS (Majority Node Set) pri strate celej primárnej lokality postaral len o prevedenie
pripravených scriptov z prvej možnosti, čím by sme celú vec zautomatizovali. Treťou
možnosťou prichádzajúcou do úvahy je zakúpenie a nasadenie 3rd party softwaru, ktorý by
nahradil tieto nedostatky MSCS a pracoval ako ich doplnok (napr. súčasť balíku Business
Continuity Planning od IBM, prípadne EMC SRDF/CE for MSCS).
        Druhá Recovery trieda C2 sa vyznačuje max. hodnotami RPO/RTO rovnými
jednému dňu. Bude teda nevyhnutná plne funkčná infraštruktúra schopná prebrať
spracovávanie kritických aplikácii v tejto triede - warmsite. Keďže z definície tejto triedy
vyplýva maximálna strata dát v dobe jedného dňa, sú potenciálne možné dva varianty
transportu dát závislé od množstva dátovej kapacity. Prvým je replikácia na úrovni storage,
pričom tu si vystačíme aj s asynchrónnou, nakoľko je tolerovaná jednodňová strata dát.
Tento variant bude vhodný obecne pre ľubovoľné množstvo replikovaných dát i keď bude
závislý od možnej šírky pásma potenciálneho sieťového spoju. Tým druhým bude denná
tvorba kópií nových denne zazálohovaných dát a ich fyzický presun do offsite trezoru. Tu
sme ale limitovaní menším množstvom dát, nakoľko tvorba samotných záloh súčasne s ich
kópiami si vyžiada značný čas a nemôžme zabudnúť započítať i dobu potrebnú pre ich
obnovu na Disaster lokalite. Vzhľadom na RTO veľkosti jedného dňa by sme toto mohli
garantovať len v prípade malého objemu dát. Preto bude hlavnou preferovanou metódou
transportu dát asynchrónna replikácia. Stále bude ale potreba udržovať servery s ich OS
v aktívnom a relatívne up-to-date stave, nakoľko by nebolo dosť času potrebného na
prevedenie kompletného System Recovery na všetkých serveroch.
        Nasledujúca trieda C3 je rozdielna od predošlej hodnotou maximálneho RTO
rovnému tri dni. Túto dobu je možné využiť k obnove celých serverov i aplikačných dát zo
záloh. Navrhnime preto ako preferovaný spôsob trafiky dát pre túto triedu kombináciu
metódy PTAM a electronic-vaulting, obe implementované na úrovni TSM. Pre metódu
PTAM preto nasadíme TSM modul DRM (Disaster Recovery Manager), ktorý bude mať
na starosti správu pásiek určených na offsite a nové kópie záloh budú odnášané do Disaster
lokality denne kuriérom. Metódu electronic-vaulting implementujeme formou druhej
instancie TSM serveru v Disaster lokalite, v ktorej definujeme storagepool, na ktorý budú
simultánne zapisované dáta primárnym TSM serverom počas bežného zálohovania na
primárne storagepools (funkcionalita simultaneous write to copy stgs ) a to formou server-
to-server komunikácie. Týmto navyše dosiahneme efektívneho využitia sieťového
prepojenia. Cez deň bude plne využité replikáciou (najviac systémy a aplikácie pracujú cez

                                                                                         55
deň) a v noci kedy sú zvyčajne naplánované zálohy a kedy sú aplikácie v dobe pokoja
(málo dát k replikácii), bude spoj využitý práve pre electronic-vaulting. Aj keď bude
nevyhnutné záložné HW vybavenie na Disaster lokalite - servery, budú tieto v neaktívnom
stave a v prípade havárie bude prevádzaná kompletná obnova (bude k dispozícií dostatočné
RTO tri dni) podľa navrhnutých BMR procedúr závislých od typu OS. Takéto BMR dáta
(obrazy systémových partícii a pod.) budú potom vytvárané a odnášané na offsite jeden
krát týždenne, ideálne cez víkend, keďže budú takéto images OS v relatívne up-to-date
postačujúcom stave.
        Trieda štvrtá – C4, zvyšuje maximálne tolerované RTO na sedem dní, čo nám
umožní dovoliť si nevybaviť Disaster lokalitu záložným výpočtovým HW, avšak stále
budú potrebné minimálne zabezpečené priestory s potrebnou základnou infraštruktúrou -
coldsite. Sedem dní by ale v prípade havárie takmer určite nestačilo na dodanie
nevyhnutného HW patričným výrobcom, preto siahneme po možnosti zabezpečenia
dodávky načas uzatvorením vhodných kontraktov s výrobcami. Po dodávke potrebného
HW budeme následne prevádzať ako obnovu OS (podľa navrhnutých BMR), tak aj obnovu
aplikačných dát zo záloh. Maximálna tolerovaná strata dát v rozmedzí jedného dňa nás
však opätovne obmedzí na metódu transportu dát v závislosti od množstva dát. Pri
najmenších kapacitách si vystačíme s metódou PTAM, stredne veľké objemy prenesieme
pri aplikácii TSM funkcionality electronic-vaulting a najväčšie budeme nútení prenášať
progresívnou replikáciou. V prípade prvých dvoch metód sa potom o korektnú obnovu
postarajú TSM moduly TDP, pričom v prípade replikácie to budú samotné aplikácie
svojimi integrovanými mechanizmami (transakčné logy u databáz a pod.).
        Navrhnuté triedy C5 i C6 definujú RTO vo veľkosti 40 dní a teda si dovolíme pri
zaisťovaní potrebného HW ubrať i od uzatvárania kontraktov s producentmi, keďže sa táto
doba javí ako dostačujúca pre včasnú dodávku. Budú ale stále nevyhnutne potrebné
pripravené priestory so základnou infraštruktúrou (UPS, generátory...) - coldsite, nakoľko
by takáto príprava mohla veľmi ľahko prekročiť i dva mesiace. V triede C5 budeme ako
transportný mechanizmus preferovať denné offsite kópie záloh, prípadne simultánny zápis
metódou electronic-vaulting pri väčších kapacitách. Popri tomu si v triede C6 vystačíme
len s týždennou tvorbou offsite kópií záloh, nakoľko je strata dát zo siedmich dní
akceptovateľná.
        Nakoniec posledné dve triedy C7 i C8 nebudú definovať žiadne núdzové riešenie
z pohľadu zaisťovania DR&BC a vystačíme si len s offiste tvorbou kópií aplikačných dát
s periódou menšou ako sedem dní v prípade prvom a väčšou ako sedem dní v prípade
druhom.
        Týmto sme definovali konkrétne riešenia zaisťovania DR&BC navrhnutých tried
aplikácií a v niektorých prípadoch budeme vyberať konkrétnu možnosť transportu dát
v závislosti od dátového množstva.


5.2 Dva základné varianty
        Pre vyriešenie druhého slabého miesta, teda malej vzdialenosti dvoch dátových
centier, navrhneme dva základné varianty. Pôjde o variant two-site podobný tomu
aktuálnemu a o variant modelu thee-site, ktorý začína už byť v modernej dobe (hlavne
v zahraničí a hlavne bohatšími spoločnosťami) tvrdo presadzovaným trendom a tiež
štandardom (Obrázok 5-1 Modely základných variantov). Tieto modely ďalej detailnejšie
navrhneme.


                                                                                        56
                       Obrázok 5-1 Modely základných variantov


        V prvom prípade bude teda implementovaný hotsite, pričom u modelu three-site
pôjde len o warmsite. V oboch prípadoch budú teda nevyhnutné vybavené a zabezpečené
priestory. Keďže sa dá infraštruktúra považovať za prvú úroveň ochrany, bude potrebné
ako základný stavebný kameň zakomponovať do návrhu kontrolu fyzického prístupu
k zariadeniu spojenú so zabezpečením proti rôznym druhom havárie (teplota, oheň, voda,
elektrina...). Toto bude implementované pomocou duálnych UPS, naftových generátorov,
naddimenzovanej klimatizácii, detektorov ohňa, dymu, vody spolu s mechanizmami
ochrany proti takýmto typom havárií. Pri návrhu priestorov bude tiež nevyhnutné počítať
s budúcim rastom celkového vybavenia a to minimálne pre dobu najbližších päť až desať
rokov. V každej oblasti bude imperatívom počítať s elimináciou SPOF. Keďže téma design
a návrh dátových centier by rozhodne niekoľko krát presahovala rozsah tejto práce,
nebudeme sa týmito fundamentálnymi elementmi ďalej zaoberať.


5.2.1 Model s topológiou two-site

        Pri prvom modelu s topológiou two-site pôjde v podstate o koncept dvoch dátových
centier identický tomu stávajúcemu, ale doplnený o riešenie malej geografickej
vzdialenosti. Bude sa teda jednať o fyzický presun celého jedného centra do disaster
lokality, čo so sebou prinesie niekoľko komplikácií. V prvom rade bude definitívne
nevyhnutné prenajatie dedikovaného vlákna darkfiber pre uspokojenie vysokých
požiadaviek na prenos dát. Pre elimináciu SPOF prenajmeme dva takéto vlákna vedené po
fyzicky rôznych trasách od rôznych poskytovateľov, nakoľko by moment zlyhania jedného
priniesol veľmi kritický okamžik. Po analýze trhu sú dostupné dve takéto trasy o dĺžke 25
a 30 kilometroch. Komplementárne nasadená bude vhodná forma multiplexingu – WDM,
v prípadnej kombinácii s TDM, podľa nameraných hodnôt útlmu i latencie a vypočítanej
potrebnej šírke pásma. Zakomponované tiež budú adekvátne aktívne prvky v trasách,
pričom si je potreba uvedomiť, že budeme používať synchrónnu replikáciu dát.
Podmnožina dostupných kanálov bude použitá pre LAN, ostatné pre SAN prepojenie.
Celkové topológie LAN i SAN ostanú pritom nezmenené.


                                                                                       57
        Aby bola zachovaná vysoká dostupnosť kritických aplikácií pri rozšírení
vzdialenosti, bude potreba aby sa samotný cluster software postaral pri vykonaní failoveru
i o premapovanie storage na disaster lokalitu v konjunkcii so zmenou na reverzný smer
replikácie. Toto bude ale potrebné len v prípade, že bude mat dopad zvýšenia latencie na
prostredie aktuálnou konfiguráciou degradujúci vplyv na chod aplikácií, čo jednoducho
otestujeme po ustanovení spoju. V takomto prípade nasadíme varianty HACMP-XD pre
platformu AIX spolu s modulom z rodiny produktov Veritas Suite ako doplnok pre MSCS
na platforme Windows.
        Celá zvyšná konfigurácia zostane identická stávajúcemu prostrediu, pričom
zachová všetky vyžadované elementy.


5.2.2 Model s topológiou three-site
        Sofistikovanejšie vysoko robustné riešenie three-site modelu prinesie však pri
návrhu ďalšie problémy. Stávajúci koncept dvoch dátových centier so synchrónnou
replikáciou ostane nezmenený a doplníme ho o warmsite na disaster lokalite, na ktorú
budeme replikovať asynchrónne, menovite dáta aplikácii v recovery triede C2. Dátové
centrá A i B si budú navzájom slúžiť ako primárna disaster lokalita v prípade lokálnych
havárií, pričom na dátové centrum C príde rada v prípade straty oboch primárnych
zariadení. Pre prepojenie s lokalitou C použijeme rovnakú technológiu ako tomu bolo
v predchádzajúcom modelu three-site, teda prenajatie dvoch odlišných optických trás
darkfiber spolu s potrebným vybavením (multiplexory, aktívne prvky...), spolu
s rozložením využitia kanálov pre LAN i SAN.
        V oblasti LAN v primárnej lokalite teda dôjde k rozšíreniu o LAN disaster lokality
podľa Obrázku 5-2 Rozšírenie LAN. Keďže bude nutné zachovanie IP adresovania
v prípade výpadku celej primárnej lokality (servisné IP adresy, či IP adresy serverov),
implementujeme medzi tieto LAN preklad sieťových adries – NAT.




                               Obrázok 5-2 Rozšírenie LAN

                                                                                        58
        Celú LAN na disaster lokalite implementujeme podľa vzoru primárnej LAN so
všetkými zabezpečovacími mechanizmami (LinkProof, DefencePro, Firewalls...) včítane
DMZ a dvojnásobným redundantným pripojením k Internetu od rôznych poskytovateľov
s distribuovaním záťaže. Keďže budeme mať celú spojenú LAN pripojenú k Internetu na
dvoch rozličných miestach, bude potreba vyriešiť problém IP adresovania prichádzajúcej
trafiky z okolitého sveta. Bolo by zrejme ťažké dosiahnuť interakciu medzi smerovačmi
poskytovateľov pri propagácii správnych IP adries, preto tento problém vyriešime
rozdielnou konfiguráciou metrík pre cesty cez jednotlivé brány. Cestám vedúcim cez
hraničný smerovač na primárnej lokalite bude priradená menšia hodnota metriky než
cestám vedúcim cez hraničný smerovač na disaster lokalite. Takto bude celá prichádzajúca
trafika z Internetu v prípade nedostupnosti primárneho hraničného smerovača
transparentne smerovaná cez hraničný smerovač disaster lokality pri stálom zachovaní
preferovaných primárnych trás.
        Neodkladne dôjde i k rozšíreniu SAN podľa Obrázku 5-3 Rozšírenie SAN.




                              Obrázok 5-3 Rozšírenie SAN

       K jadrovým core directorom bude pripojený ďalší jadrový switch adekvátne
vybraný podľa potrebného počtu portov. Do rozšírenej SAN zaobstaráme a pripojíme
diskové pole DS8200 spolu s nevyhnutným počtom midrange polí DS4000, na ktoré bude
prevádzaná asynchrónna replikácia. Komplementom bude virtualizačný SAN Volume
Controller kvôli možnosti replikácii aj virtualizovaných logických zväzkov. Replikáciu
navrhneme implementovať systémom tvorby snapshotov na úrovni diskových polí
(flashcopy).
       Novú disaster lokalitu vybavíme identickou páskovou knižnicou TS3494 o troch
frames spolu s páskovými mechanikami LTO3 v počte minimálne 16, pretože od týchto
                                                                                      59
bude práve závisieť doba obnovy RTO v našom najhoršom scenári. Obnova všetkých
serverov i aplikácií, ktoré nebudú v aktívnom stave (ich dáta nebudú replikované) bude
prevádzaná cez TSM postupmi definovanými v ďalšej podkapitole. Budeme teda odkázaní
na tvorbu offsite kópií záloh, ktorých periódu nakonfigurujeme podľa zaradenia aplikácií
do Recovery tried a pre automatizáciu obnovy samotného TSM serveru i manažment offsite
médií implementujeme na produkčnom prostredí modul DRM. Naším návrhom docielime
veľmi priaznivý stav, ktorý je odporúčaný aj samotným IBM a teda existenciu 3 kópií
všetkých záloh. Z nich dve budú fyzicky na primárnej lokalite, každá v jednom dátovom
centre a budú poskytovať odolnosť proti zlyhaniu páskového média (transparentný proces
riešený TSM), pričom tretia kópia dát bude vždy vo vyžadovanom čase bezpečne
uschovaná na disaster lokalite pre prípad riešenia DR&BC.
        Kritickým bodom bude zaistenie dostupnosti TSM databázy a preto ju zaistíme na
niekoľkých úrovniach. Keďže produkčný TSM server beží nad platformou AIX na
exkluzívnej volume groupe, budeme túto asynchrónne replikovať a v prípade havárie
vsadíme na samoopravný mechanizmus TSM databáze pomocou recovery logu
v rollforward móde. Ďalej na disaster lokalite implementujeme ďalší TSM server, na ktorý
budeme dva krát denne formou server-to-server komunikácie ukladať plnú zálohu
databáze produkčného TSM serveru, mechanizmom electronic vaulting, pri ktorom budú
tieto dáta paralelne ukladané tiež do oboch primárnych zariadení. V tomto procese budeme
paralelne tvoriť aj zálohy databázy určené na offsite a teda TSM databáza bude chránená až
na troch úrovniach.
        Keďže neboli zaradené do najvyššej triedy žiadne aplikácie, nebude okrem TSM
a NIM (viz. 5.3 Návrh BMR procedúr) serverov potrebná žiadna dodatočná aplikácia pre
automatizáciu zotavenia z havárie, včítane cluster SW. Na všetky ostatné vyžadované RTO
si vystačíme s dopredu pripravenými dávkovými scriptami pri všetkých aktivitách.


5.3 Návrh BMR procedúr a obnovy aplikačných dát
        Na záver nám ostáva navrhnúť BMR procedúry obnovy operačných systémov spolu
s definíciou postupov využívaných pri obnove aplikačných dát. Začneme teda prístupom
k BMR technikám, ktoré budeme využívať pri DR v prípadoch, kedy náš plán obnovy
bude založený na offsite zálohách (triedy C3-C8).
        Všetky BMR prístupy budú pozostávať z nasledujúcich krokov:

   1)   nabootovanie hardwaru
   2)   napartíciovanie diskového priestoru
   3)   prístup k zálohám
   4)   obnova zo záloh
   5)   post-restore customizácia

        V prípade OS platformy Windows máme na výber z niekoľkých najznámejších
prístupov, ktoré sa líšia poskytovanou funkcionalitou ako možnosť zálohovania otvorených
súborov, obnovou na rozdielny HW, integráciou s nasadeným SW produktom pre
zálohovanie, podporou multi-boot konfigurácie, či rýchlosťou samotnej procedúry. Popri
produktov Symantec Ghost, Acronis i CBMR (Cristie Bare Machine Recovery) poskytuje
tento typ obnovy i samotný MS Windows 2003 v podobe ASR (automated system
recovery). My však vsadíme na natívne riešenie TSM, kde budeme s periódou jedného
týždňa vytvárať konzistentné obrazy systémových partícii a v prípade obnovy nabootujeme

                                                                                        60
OS z WinPE-Live CD, ktoré už v sebe integruje i TSM klienta a následne obnovíme celú
systémovú partíciu. Pre prípad potreby obnovy na rozdielny HW budeme pomocou
mesačne načasovaného scriptu ukladať na bezpečné miesto potrebné systémové informácie
ako rozloženie diskového priestoru, diskové signatúry, či sieťovú konfiguráciu TCP/IP
a routovacie tabuľky (použijeme aplikácie msinfo32, srvinfo).
         Prístup k BMR procedúre pre platformu Linux bude začínať podobne ako
v predchádzajúcom prípade periodickým ukladaním systémových informácii typu
rozloženia diskového priestoru (počet i veľkosť partícií, mount points, filesystems…), OS
levels, nastavenie TCP/IP (mask, address, gateway, DNS...) či názov hostname. Ako zdroj
informácii využijeme aplikácie fdisk, df, ifconfig, výstupy adresárov /proc a /etc/sysconfig,
ale aj iné. Pre automatizáciu použijeme vytvorené scripty naplánované s mesačnou
periódou. Ďalším krokom bude tvorba záloh súborov OS. Použijeme známu archivačnú
aplikáciu tar (iným variantom by mohol byť napr. gzip) k vytvoreniu archívov
systémových i bootovacích súborov (/boot, /dev, /etc, /bin, /sbin, /lib, /usr/sbin…) a to
z dôvodu konzistentných záloh, ktoré následne budeme zálohovať pomocou TSM na
páskové média. Vytvoríme si obecné bootovacie médium, pomocou ktorého budeme pri
vykonávaní BMR OS Linux bootovať hardware do akéhosi mini-roota. Z niekoľkých
možností využijeme pre tento účel aplikáciu tomsrtbt (http://www.toms.net/rb). Ako
posledné budeme pomocou TSM denne zálohovať i všetky ostatné objekty na všetkých
súborových systémoch. Samotný proces obnovy bude potom začínať bootovaním
z pripraveného rescue media nasledovaný partíciovaním diskového priestoru podľa
uložených informácií (fdisk). Po pripravení diskového subsystému bude namontované
vymeniteľné médium (napr. CD, USB flash...), z ktorého budú obnovené archívy boot
a systémových súborov do dočasného adresáru /root. Tieto archívy budú musieť byť
v predstihu obnovené z TSM na naše vymeniteľné médium. Po zmene koreňového
adresáru na nový obnovený koreňový adresár (chroot) budeme schopní nabootovať do plne
funkčného OS Linux. Celá BMR procedúra bude zavŕšená konfiguráciou TSM klienta
prostredníctvom ktorého bude realizovaná obnova všetkých ostatných súborových
systémov.
         Pri obnove platformy AIX vsadíme na voliteľnú komponentu samotného OS,
Network Installation Management – NIM. Takto sme sa rozhodli práve z dôvodu
nepotrebnosti licencovania dodatočných produktov pre tento účel (napr. SysBack).
V produkčnom dátovom centre implementujeme jeden NIM master server, ktorý bude
zodpovedný za držanie špecifických informácii o klientoch súčasne s ich zálohami root
volume groups (vytvorené ako mksysb zálohy). Tieto zálohy budeme tvoriť s týždennou
periódou na všetkých NIM klientoch (servery na platforme AIX). Doplnkom zálohovacej
stratégie budú denné zálohy všetkých ostatných súborových systémov pomocou TSM na
pásky. Nevyhnutnosťou tiež budú TSM zálohy všetkých dát NIM master serveru ukladané
na tiež na páskové média. Na disaster lokalite pripravíme AIX-based server, na ktorom
implementujeme NIM master server a to z dôvodu urýchlenia obnovy klientov. V prípade
havárie bude ako prvý krok obnova dát do standby NIM master serveru z offsite kópii dát.
Nasledovať bude sieťový boot obnovovaných klientov z NIM serveru spojený s obnovou
root volume groups z pripravených mksysb záloh. Posledným krokom bude obnova
všetkých ostatných súborových systémov prostredníctvom nainštalovaných TSM B-A
clientov.
         Poslednou nasadenou OS platformou pre ktorú budeme musieť plánovať BMR
procedúry je SUN Solaris. Ako v predošlých prípadoch, aj tu budeme s mesačnou periódou
vytvárať a na bezpečnom mieste uskladňovať (napr. pásky, vytlačené dokumenty v trezore)
set systémových informácií (HW konfigurácia, logický diskový subsystém). Použijeme

                                                                                          61
vymoženosti OS ako uname, prtdiag, prtconf, iostat, sysdef, df a iné. Rozdelíme dáta do
dvoch skupín a to systémové dáta na jednej strane(súborové systémy /, /usr), či dáta
užívateľské (všetko mimo /, /usr) na strane druhej. Užívateľské dáta budeme denne
zálohovať pomocou TSM, systémom progresívnych inkrementálnych záloh. K zálohám
systémových dát budeme pristupovať pomocou internej utility ufsdumpi v single-user
móde, výstup ktorej bude samozrejme smerovaný na páskové média. Obnova po havárii
bude obnovou systémových ufsdump dát z TSM (vykonaná už na funkčnom servery) na
prenositeľné médium (CD). Z vytvoreného prenositeľného média bude potom vykonaná
obnova systémových súborových systémov pomocou ufsrestore do v single-user móde
nabootovanom prostredí Solarisu. Pokračovaním bude re-boot do normal módu
obnoveného systému, čo bude v sebe zahrňovať aj TSM B-A clienta, prostredníctvom
ktorého budú v záverečnej fáze obnovené všetky užívateľské dáta.
         Ostáva nám definovať zvolené postupy obnovy aplikačných dát. V prípade modelu
two-site bude celý proces obnovy transparentný, nakoľko všetky kritické aplikácie pracujú
v prostredí shared nothing clusters. Prácu v takomto prostredí integrujú v sebe všetky
nasadené aplikácie, takže nebude potreba dodatočne riešiť zachovanie konzistencie dát.
U modelu three-site môžeme rozdeliť aplikačné dáta do dvoch skupín. Bude to skupina
s aplikáciami mapovanými v Recovery triedach C2 i čiastočne C3 s transportným
mechanizmom asynchrónnej replikácie a skupina aplikácií s transportným mechanizmom
electronic vaulting súčasne s PTAM. U skupiny s replikáciou vsadíme na integrované
mechanizmy jednotlivých aplikácii (transakčné logy), pomocou ktorých by sa mala pri
spustení na disaster lokalite postarať o konzistenciu dát aplikácia samotná. Avšak pre
prípad neúspechu budeme mať stále konzistentné zálohy na offsite médiách obnoviteľné
pomocou modulov TDP. U druhej skupiny bude proces obnovy prebiehať výhradne
z offsite médií.


5.4 Stručný DRP plán
       Na záver navrhneme stručný postup celkovej obnovy z havárie u modelu three-site,
podľa ktorého sa bude postupovať, DRP plán.




                                                                                        62
     Čas:               Osoba:         Popis aktivity:
 1 t až t+01:00         monitoring     detekcia havárie službou monitoringu +
                      on duty          oboznámenie kompetentného managementu o situácii
 2 t+01:00 až t+01:30 management       overenie o vzniknutí informovanej skutočnosti +
                      on duty          vydanie pokynu k realizácií DRP
 3 t+01:30 až t+02:30 all admins       mobilizácia, pokyn na dodanie nakontraktovaného hardware+
                      on duty          objednávka potrebného hardware v triedach C5+C6
 4 t+02:30 až t+03:30 app. admins      štart aplikácií v C2 na aktívnych serverech
                      backup
 5 t+02:30 až t+03:30 admin            štart TSM, NIM na disaster lokalite+prípadná obnova TSM DB
                      backup
 5 t+03:00 až t+05:00 admin         import offsite médií do knižnice + príprava na obnovy
                                    obnova neaktívnych serverov s koreňovými službami def.
 6   t+04:00 až t+10:00 backup+OS   BMR-
                        admins      DNS, DHCP, Domain Controllers...Solaris, Win2003
 7   t+10:00 až t+12:00 app.+backup kontrola správneho behu aplikácii aktívnych serverov v C2 +
                        admins      prípadná obnova aplikačných dát v C2
 8   t+12:00 až t+20:00 app+backup+ obnova neaktívnych serverov triedy C2 podľa BMR z offsite/
                        OS admins   el.vault médií, prípadná obnova aplikačných dát v C2
 9   t+20:00 až t+45:00 app+backup+ obnova OS na prvkoch množiny C3 podľa BMR
                        OS admins
10   t+45:00 až t+60:00 app+backup+ obnova aplikačných dát skupiny C3
                        OS admins
11   t+3dni až t+7dní   app+backup+ obnova serverov v C4 na nakontraktovaný
                        OS admins   hardware podľa BMR a ich aplikačných dát
12   t+3dni až t+40dní  app+backup+ obnova serverov v C5+C6 na dodaný hardware podľa BMR
                        OS admins   a ich aplikačných dát
13   t+40dni a viac     app+backup+ postupné zaobstarávanie HW, inštalácia aplikácií,
                        OS admins   plnenie dát, prípadné obnovy z offsite médií pre triedy C7+C8




                                                                                            63
                                       6 Záver


        Po podrobnom zoznámení sa s jednotlivými elementami plánovania DR&BC pre
dátové centrá som vysvetlil využívané technológie a technologické postupy, pričom som sa
snažil zamerať na najdôležitejšie body z obecného hľadiska. Musím zhodnotiť, že
technologická oblasť riešenej práce je veľmi komplexná a rôznorodá, čím zahrňuje v sebe
množstvo riešených problémov heterogénneho charakteru.
        Analyzoval som reálne produkčné prostredie fungujúceho podniku, ktoré bolo celé
navrhnuté podľa vysokých a moderných štandardov. Toto prostredie poskytovalo už samo
o sebe vysoký stupeň redundancie, ale aj odolnosť voči rôznym haváriam, či typom
zlyhania. Vysvetlil som slabé miesta existujúceho prostredia z hľadiska zaisťovania
DR&BC.
        V poslednej časti som navrhol dva varianty možného riešenia slabých miest.
Vysvetlil som riešenie zaistenia odolnosti celkového prostredia voči scénáru fyzickej straty
celého riešeného dátového centra, pričom som navrhol, ale aj detailne definoval postupy
a procedúry pre zotavenie, to všetko podľa zadaných požiadavkov na jednotlivé aplikácie.
Pri celom návrhu som postupoval bez vedomosti o cenových reláciach jednotlivých
hardwarových komponent, nakoľko je veľmi obťiažne získať tieto informácie a takáto
téma býva predmetom rôznych rokovaní obchodníkov a predstaviteľov samotných firiem.
Obidva navrhnuté varianty sú v praxi plne realizovateľné a o ich výbere budú rozhodovať
kompetentné osoby riešeného podniku, čomu dôjde zrejme po obdržaní cenových ponúk
od jednotlivých dodávateľov a odhadnutí celkových finančných nákladov.
        Neúspechom skončilo porovnanie navrhnutého riešenia s riešením iného podniku,
nakoľko aj po veľkej snahe si takéto informácie každý väčší podnik drží ako svoje interné
„know-how” a duševné vlastníctvo.
        Podľa môjho názoru, v našich podmienkach máme v čom dobiehať trendy
vyspelých krajín, čo je iste dané i veľkosťou kapitálu samotných podnikov a ochotou
investovať naozaj nemalé prostriedky za akúsi „poistku“, akou plánovanie DR&BC
bezosporu je. Neostáva nám dodať, že plánovať je rozhodne potreba.




                                                                                         64
7 Použitá literatúra


[1]    Susan Snedaker: Business Continuity and Disaster Recovery Planning for IT
       Professionals. Syngress 2007, ISBN 1597491721

[2]    Rita Pužmanová: Moderní komunikační síte od A do Z, Computer Press 1998, ISBN
       80-7226-098-7

[3]    Peter Barnes, Andrew Hiles: The Definitive Handbook of Business Continuity
       Management. John Wiley & Sons Ltd. 1999, ISBN 0471986224

[4]    Janet G. Butler, Poul Badura: Contingency Planning and Disaster Recovery:
       Protecting Your Organization’s Resources. Computer Technology Research
       Corporation 1997, ISBN 1566079860

[5]    Akhtar Syed, Afsar Syed: Business Continuity Planning Methodology. Sentryx
       2003, ISBN 0973372508

[6]    Jon Wiliam Toigo, Margaret Romano Toigo: Disaster Recovery Planning:
       Strategies for Protecting Critical Information Assets. Prentice Hall 1999, ISBN
       013084506X

[7]    Andrew Hiles: Business Continuity: Best Practices-World-Class Business
       Continuity Management. Rothstein Associates Inc. 2003, ISBN 1931332223

[8]    IBM: IBM System Storage Business Continuity: Part 1 Planning Guide. IBM
       Redbooks 2007, ISBN 0738489700

[9]    IBM: IBM System Storage Business Continuity: Part 2 Solutions Guide. IBM
       Redbooks 2007, ISBN 0738489727

[10]   IBM: IBM System Storage Solutions Handbook. IBM Redbooks 2006, ISBN
       0738496774

[11]   IBM: IBM System Storage Business Continuity Solution Selection Methodology.
       IBM Redpaper 2007, REDP-4062-01

[12]   IBM: IBM System Storage Business Continuity Solutions Overview. IBM Redbooks
       2007, ISBN 0738489719

[13]   IBM: Disaster Recovery Strategies with Tivoli Storage Management. IBM
       Redbooks 2002, ISBN 0738426504

[14]   IBM: Virtualization on the IBM Systems Virtualization: Servers, Software and
       Storage. IBM Redpapers 2008, REDP-4396-00



                                                                                         65
[15]   General Accounting Office: Year 2000 Computing Crisis: Business Continuity and
       Contingency Planning. GAO/AIMD-10.1.19 1998

[16]   Marianne Swanson, Amy Wohl, Lucinda Pope, Tim Grance, Joan Hash, Ray
       Thomas: Contingency Planning Guide for Information Technology Systems. NIST
       National Institute of Standards and Technology 2002, NIST Special Publication
       800-34

[17]   IBM: IBM SAN Survival Guide. IBM Redbooks 2003, ISBN 0738454338

[18]   IBM: IBM System Storage DS8000: Copy Services in Open Environments. IBM
       Redbooks 2007, ISBN 0738496979

[19]   IBM: Disaster Recovery Using HAGEO and GeoRM. IBM Redbooks 2000, ISBN
       0738416061

[20]   IBM: IBM Tivoli Storage Manager Version 5.4 & 5.5 Technical Guide. IBM
       Redbooks 2008

[21]   IBM: IBM Tivoli Storage Manager in a Clustered Environment. IBM Redbooks
       2005, ISBN 0738491144

[22]   IBM: IBM BladeCenter Products and Technology. IBM Redbooks 2008, ISBN
       073848587X

[23]   IBM: NIM from A to Z in AIX 5L. IBM Redbooks 2005, ISBN 0738486310

[24]   IBM: Introduction to SAN Distance Solutions. IBM Redbooks 2002, ISBN
       0738424056

[25]   IBM: Backing Up Oracle Using Tivoli Storage Management. IBM Redbooks 2001,
       ISBN 0738421855

[26]   W. Curtis Preston, Gigi Estabrook: Unix Backup and Recovery. O’Reilly &
       Associates 1999, ISBN 1565926420

[27]   Association of Contingency Planners: http://www.acp-international.com


[28]   CBS News Disaster Links:
       http://www.cbsnews.com/digitaldan/disaster/disasters.htm

[29]   Contingency Planning Management (CPM): http://www.contingencyplanning.com

[30]   Disaster Recovery Institute International (DRII): http://www.drii.org

[31]   Disaster Recovery Journal (DRJ): http://www.drj.com

[32]   National Emergency Management Association: http://www.nemaweb.org

                                                                                    66
[33]   Survive: http://www.survive.com

[34]   IBM: http://www.ibm.com

[35]   SunGard: http://www.sungard.com

[36]   Iron Mountain: http://wwwironmountain.com

[37]   HP: http://www.hp.com

[38]   Brocade: http://www.brocade.com

[39]   EMC: http://www.emc.com

[40]   Storage Networking Industry Association: http://www.snia.org

[41]   Veritas: http://www.veritas.com

[42]   Cristie: http://www.cristie.co.uk

[43]   IBM SysBack: http://sysback.services.ibm.com

[44]   SUN Microsystems: http://www.sun.com

[45]   Microsoft: http://www.microsoft.com

[46]   SHARE: http://www.share.org




                                                                      67
                     8 Príloha A – použité skratky

BC/BCP – Business Continuity / Business Continuity Plan(ing)

DR/DRP – Disaster Recovery / Disaster Recovery Plan(ing)

SLA – Service Level Agreement

SAN – Storage Area Network

NAS – Network Attached Storage

DAS – Direct Attached Storage

HBA – Host Bus Adapter

NIC – Network Interface Card

RAID – Redundant Array of Independent Disks

TSM – Tivoli Storage Manager

BMR – Bare Machine Recovery

SPOF – Single Point Of Failure




                                                               68
                          9 Príloha B – DRM Plan

       Príloha B zobrazuje výstup (scripty) generovania DRM plánu testovacieho
prostredia, pomocou ktorého je obnova celého TSM Serveru výrazne uľahčovaná.
V kombinácii s technológiou clusteringu je možné túto obnovu plne zautomatizovať
v prípade straty celej primárnej lokality, pričom sa na jednotlivé časti DRM plánu pozerá
ako na start/stop scripty, ktoré spracováva samotný cluster software.

begin PLANFILE.DESCRIPTION
Recovery Plan for Server TEST_SERVER1
Created by DRM PREPARE on 03/27/2008 19:30:58
DRM PLANPREFIX C:\DRM\PLAN\TEST
Storage Management Server for Windows - Version 5, Release 3,
Level 0.0
end PLANFILE.DESCRIPTION
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin PLANFILE.TABLE.OF.CONTENTS
PLANFILE.DESCRIPTION
PLANFILE.TABLE.OF.CONTENTS
Server Recovery Stanzas:
SERVER.REQUIREMENTS
RECOVERY.INSTRUCTIONS.GENERAL
RECOVERY.INSTRUCTIONS.OFFSITE
RECOVERY.INSTRUCTIONS.INSTALL
RECOVERY.INSTRUCTIONS.DATABASE
RECOVERY.INSTRUCTIONS.STGPOOL
RECOVERY.VOLUMES.REQUIRED
RECOVERY.DEVICES.REQUIRED
RECOVERY.SCRIPT.DISASTER.RECOVERY.MODE script
RECOVERY.SCRIPT.NORMAL.MODE script
LOG.VOLUMES
DB.VOLUMES
LOGANDDB.VOLUMES.INSTALL script
LICENSE.REGISTRATION macro
COPYSTGPOOL.VOLUMES.AVAILABLE macro
COPYSTGPOOL.VOLUMES.DESTROYED macro
PRIMARY.VOLUMES.DESTROYED macro
PRIMARY.VOLUMES.REPLACEMENT.CREATE script
PRIMARY.VOLUMES.REPLACEMENT macro
STGPOOLS.RESTORE macro
VOLUME.HISTORY.FILE
DEVICE.CONFIGURATION.FILE
DSMSERV.OPT.FILE
LICENSE.INFORMATION
Machine Description Stanzas:
MACHINE.GENERAL.INFORMATION
MACHINE.RECOVERY.INSTRUCTIONS
MACHINE.CHARACTERISTICS
MACHINE.RECOVERY.MEDIA.REQUIRED
end PLANFILE.TABLE.OF.CONTENTS
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-


                                                                                            69
begin SERVER.REQUIREMENTS
Database Requirements Summary:
Available Space (MB): 2,048
Assigned Capacity (MB): 1,024
Pct. Utilization: 12.2
Maximum Pct. Utilization: 12.2
Physical Volumes: 2
Recovery Log Requirements Summary:
Available Space (MB): 128
Assigned Capacity (MB): 128
Pct. Utilization: 0.6
Maximum Pct. Utilization: 13.0
Physical Volumes: 1
Server Installation Directory: C:\Program Files\tivoli\tsm\
end SERVER.REQUIREMENTS
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin RECOVERY.INSTRUCTIONS.GENERAL
Recovery instructions for TSM server TEST
Any of the following people are authorized to perform the restore
and are familiar with the
system passwords - make sure they are contacted:
- System Administrator: XYZ, (work 000 123 4567, mob 1234 567 890)
- TSM Administrator: XYZ (work 000 123 4567, mob 1234 567 890)
- Database Administrator: XYZ (work 000 123 4567, mob 1234 567
890)
end RECOVERY.INSTRUCTIONS.GENERAL
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin RECOVERY.INSTRUCTIONS.OFFSITE
The offsite vault Trezor, Brno, CR – 000 123 456 24-hour
guaranteed priority
response line.
The courier company is Crourier Company, 123 4556 7890.
Make sure the list of volumes required for recovery is ready for
faxing (123 456 7890) or
e-mail (emergency@Trezor.com) to the vaulting service
end RECOVERY.INSTRUCTIONS.OFFSITE
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin RECOVERY.INSTRUCTIONS.INSTALL
TSM server requires Intel server machine from PC support group.
Minimum 512MB RAM, 12 GB of
disk, CD-ROM drive and Ethernet card
Install Windows 2000 and Service Pack 2. TCP/IP address is
test.ourcompany.com,
subnet mask 255.255.255.0, router, 192.168.5.254.
Install LTO drivers from http://index.storsys.ibm.com
Install TSM server v 5.3 from install CD
Install TSM server update v 5.3.0.0
end RECOVERY.INSTRUCTIONS.INSTALL
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin RECOVERY.INSTRUCTIONS.DATABASE
end RECOVERY.INSTRUCTIONS.DATABASE
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin RECOVERY.INSTRUCTIONS.STGPOOL
Restore the client backup storage pools first, not the HSM or
archive pools
                                                                 70
end RECOVERY.INSTRUCTIONS.STGPOOL
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin RECOVERY.VOLUMES.REQUIRED
Volumes required for data base restore
Location = Trezor, Brno, CR
Device Class = CLASS1
Volume Name =
ABA927L1
Volumes required for storage pool restore
Location = Trezor, Brno, CR
Copy Storage Pool = LTOCOPYSTG_01
Device Class = CLASS1
Volume Name =
ABA926L1
end RECOVERY.VOLUMES.REQUIRED
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin RECOVERY.DEVICES.REQUIRED
Purpose: Description of the devices required to read the
volumes listed in the recovery volumes required stanza.
Device Class Name: CLASS1
Device Access Strategy: Sequential
Storage Pool Count: 3
Device Type: LTO
Format: DRIVE
Est/Max Capacity (MB):
Mount Limit: DRIVES
Mount Wait (min): 60
Mount Retention (min): 60
Label Prefix: ADSM
Drive Letter:
Library: LB6.0.0.3
Directory:
Server Name:
Retry Period:
Retry Interval:
Twosided:
Last Update by (administrator): ADMIN
Last Update Date/Time: 03/25/2008 12:50:21
end RECOVERY.DEVICES.REQUIRED
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin RECOVERY.SCRIPT.DISASTER.RECOVERY.MODE script
@echo off
rem Purpose: This script contains the steps required to recover
the server
rem to the point where client restore requests can be satisfied
rem directly from available copy storage pool volumes.
rem Note: This script assumes that all volumes necessary for the
restore have
rem been retrieved from the vault and are available. This script
assumes
rem the recovery environment is compatible (essentially the same)
as the
rem original. Any deviations require modification to this script
and the


                                                                 71
rem macros and scripts it runs. Alternatively, you can use this
script
rem as a guide, and manually execute each step.
if not %1.==. if not %2.==. goto start
echo Specify the following positional parameters:
echo administrative client ID and password.
echo Script stopped.
goto end
:start
rem Set the server working directory.
pushd "C:\PROGRA~1\tivoli\tsm\server1\"
rem Restore server options, volume history, device configuration
files.
copy "C:\DRM\PLAN\TEST.DSMSERV.OPT.FILE"
"C:\PROGRA~1\TIVOLI\TSM\SERVER1\DSMSERV.OPT"
copy "C:\DRM\PLAN\TEST.VOLUME.HISTORY.FILE"
"C:\PROGRA~1\TIVOLI\TSM\SERVER1\VOLHIST.OUT"
copy "C:\DRM\PLAN\TEST.DEVICE.CONFIGURATION.FILE"
"C:\PROGRA~1\TIVOLI\TSM\SERVER1\DEVCNFG.OUT"
rem Initialize the log and database files.
call "C:\DRM\PLAN\TEST.LOGANDDB.VOLUMES.INSTALL.CMD" 1>
"C:\DRM\PLAN\TEST.LOGANDDB.VOLUMES.INSTALL.LOG" 2>&1
type "C:\DRM\PLAN\TEST.LOGANDDB.VOLUMES.INSTALL.LOG"
rem Restore the server database to latest version backed up per
the
rem volume history file.
"C:\PROGRAM FILES\TIVOLI\TSM\SERVER\DSMSERV" -k "Server1" restore
db todate= 03/27/2008 totime= 19:30:58 source=dbb
rem Start the server.
start "Server1" "C:\PROGRAM FILES\TIVOLI\TSM\SERVER\DSMSERV" -k
"Server1"
echo Wait for the server to start. Ensure that the Administrative
command
echo line client option file is set up to communicate with this
server, then
echo press enter to continue recovery script execution.
pause
rem Set the administrative command line client directory.
pushd "C:\Program Files\tivoli\tsm\baclient\"
rem Register the Server Licenses.
dsmadmc -id=%1 -pass=%2 -ITEMCOMMIT -
OUTFILE="C:\DRM\PLAN\TEST.LICENSE.REGISTRATION.LOG" macro
"C:\DRM\PLAN\TEST.LICENSE.REGISTRATION.MAC"
rem Tell the Server these copy storage pool volumes are available
for use.
rem Recovery Administrator: Remove from macro any volumes not
obtained from vault.
dsmadmc -id=%1 -pass=%2 -ITEMCOMMIT
-OUTFILE="C:\DRM\PLAN\TEST.COPYSTGPOOL.VOLUMES.AVAILABLE.LOG"
macro
"C:\DRM\PLAN\TEST.COPYSTGPOOL.VOLUMES.AVAILABLE.MAC"
rem Volumes in this macro were not marked as 'offsite' at the time
rem PREPARE ran. They were likely destroyed in the disaster.
rem Recovery Administrator: Remove from macro any volumes not
destroyed.
                                                                 72
dsmadmc -id=%1 -pass=%2 -ITEMCOMMIT
-OUTFILE="C:\DRM\PLAN\TEST.COPYSTGPOOL.VOLUMES.DESTROYED.LOG"
macro
"C:\DRM\PLAN\TEST.COPYSTGPOOL.VOLUMES.DESTROYED.MAC"
rem Mark primary storage pool volumes as ACCESS=DESTROYED.
rem Recovery administrator: Remove from macro any volumes not
destroyed.
dsmadmc -id=%1 -pass=%2 -ITEMCOMMIT -
OUTFILE="C:\DRM\PLAN\TEST.PRIMARY.VOLUMES.DESTROYED.LOG"
macro "C:\DRM\PLAN\TEST.PRIMARY.VOLUMES.DESTROYED.MAC"
rem Restore the previous working directory.
popd
rem Restore the previous working directory.
popd
:end
end RECOVERY.SCRIPT.DISASTER.RECOVERY.MODE script
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin RECOVERY.SCRIPT.NORMAL.MODE script
@echo off
rem Purpose: This script contains the steps required to recover
the server
rem primary storage pools. This mode allows you to return the
rem copy storage pool volumes to the vault and to run the
rem server as normal.
rem Note: This script assumes that all volumes necessary for the
restore
rem have been retrieved from the vault and are available. This
script
rem assumes the recovery environment is compatible (essentially
the
rem same) as the original. Any deviations require modification to
this
rem this script and the macros and scripts it runs. Alternatively,
you
rem can use this script as a guide, and manually execute each
step.
if not %1.==. if not %2.==. goto start
echo Specify the following positional parameters:
echo administrative client ID and password.
echo Script stopped.
goto end
:start
rem Create replacement volumes for primary storage pools that use
device
rem class DISK.
rem Recovery administrator: Edit script for your replacement
volumes.
call "C:\DRM\PLAN\TEST.PRIMARY.VOLUMES.REPLACEMENT.CREATE.CMD" 1>
"C:\DRM\PLAN\TEST.PRIMARY.VOLUMES.REPLACEMENT.CREATE.LOG" 2>&1
type "C:\DRM\PLAN\TEST.PRIMARY.VOLUMES.REPLACEMENT.CREATE.LOG"
rem Set the administrative command line client directory.
pushd "C:\Program Files\tivoli\tsm\baclient\"
rem Define replacement volumes in the primary storage pools. Must
rem have different name than original.


                                                                 73
rem Recovery administrator: Edit macro for your replacement
volumes.
dsmadmc -id=%1 -pass=%2 -ITEMCOMMIT
-OUTFILE="C:\DRM\PLAN\TEST.PRIMARY.VOLUMES.REPLACEMENT.LOG" macro
"C:\DRM\PLAN\TEST.PRIMARY.VOLUMES.REPLACEMENT.MAC"
rem Restore the primary storage pools from the copy storage pools.
dsmadmc -id=%1 -pass=%2 -ITEMCOMMIT -
OUTFILE="C:\DRM\PLAN\TEST.STGPOOLS.RESTORE.LOG" macro
"C:\DRM\PLAN\TEST.STGPOOLS.RESTORE.MAC"
rem Restore the previous working directory.
popd
:end
end RECOVERY.SCRIPT.NORMAL.MODE script
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin LOG.VOLUMES
"C:\TSMDB\TSMLOG01.DB" 128
end LOG.VOLUMES
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin DB.VOLUMES
"C:\TSMDB\TSMDB01.DB" 1024
"C:\TSMDB\TSMDB02.DB" 1024
end DB.VOLUMES
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin LOGANDDB.VOLUMES.INSTALL script
@echo off
rem Purpose: Initialize the log and database volumes.
rem Recovery Administrator: Run this to initialize the server
rem database and log volumes.
rem Set the server working directory.
pushd "C:\PROGRA~1\tivoli\tsm\server1\"
rem Erase any existing log and database volumes.
erase "C:\TSMDB\TSMLOG01.DB"
erase "C:\TSMDB\TSMDB01.DB"
erase "C:\TSMDB\TSMDB02.DB"
rem Install the log and database volumes.
"C:\PROGRAM FILES\TIVOLI\TSM\SERVER\DSMSERV" -k "Server1" format 1
FILE:"C:\DRM\PLAN\TEST.LOG.VOLUMES" 2
FILE:"C:\DRM\PLAN\TEST.DB.VOLUMES"
rem Restore the previous working directory.
popd
end LOGANDDB.VOLUMES.INSTALL script
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin LICENSE.REGISTRATION macro
/* Purpose: Register the server licenses by specifying the names
*/
/* of the enrollment certificate files necessary to re-create the
*/
/* licenses that existed in the server. */
/* Recovery Administrator: Review licenses and add or delete
licenses */
/* as necessary. */
register license file(drm.lic)
register license file(libshare.lic)
register license file(mgsyssan.lic) number=5
end LICENSE.REGISTRATION macro
                                                                 74
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin COPYSTGPOOL.VOLUMES.AVAILABLE macro
/* Purpose: Mark copy storage pool volumes as available for use in
recovery. */
/* Recovery Administrator: Remove any volumes that have not been
obtained */
/* from the vault or are not available for any reason. */
/* Note: It is possible to use the mass update capability of the
server */
/* UPDATE command instead of issuing an update for each volume.
However, */
/* the 'update by volume' technique used here allows you to select
*/
/* a subset of volumes to be processed. */
upd vol "ABA924L1" acc=READO wherestg=LTOCOPYSTG_01
upd vol "ABA926L1" acc=READO wherestg=LTOCOPYSTG_01
end COPYSTGPOOL.VOLUMES.AVAILABLE macro
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin COPYSTGPOOL.VOLUMES.DESTROYED macro
/* Purpose: Mark destroyed copy storage pool volumes as
unavailable. */
/* Volumes in this macro were not marked as 'offsite' at the time
the */
/* PREPARE ran. They were likely destroyed in the disaster. */
/* Recovery Administrator: Remove any volumes that were not
destroyed. */
end COPYSTGPOOL.VOLUMES.DESTROYED macro
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin PRIMARY.VOLUMES.DESTROYED macro
/* Purpose: Mark primary storage pool volumes as ACCESS=DESTROYED.
*/
/* Recovery administrator: Delete any volumes listed here */
/* that you do not want to recover. */
/* Note: It is possible to use the mass update capability of the
server */
/* UPDATE command instead of issuing an update for each volume.
However */
/* the 'update by volume' technique used here allows you to select
*/
/* a subset of volumes to be marked as destroyed. */
vary offline "H:\TSMDATA\STG_POOL_01.DSM" wait=yes
upd vol "H:\TSMDATA\STG_POOL_01.DSM" acc=DESTROYED
wherestg=DISK_STG_01
upd vol "ABA920L1" acc=DESTROYED wherestg=LTO_STGP_01
end PRIMARY.VOLUMES.DESTROYED macro
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin PRIMARY.VOLUMES.REPLACEMENT.CREATE script
@echo off
rem Purpose: Create replacement volumes for primary storage pools
that
rem use device class DISK.
rem Recovery administrator: Edit this section for your replacement
rem volume names. New name must be unique, i.e. different from any
rem original or other new name.
rem Set the TSM management console directory.
                                                                 75
pushd "C:\Program Files\tivoli\tsm\console\"
echo Replace H:\TSMDATA\STG_POOL_01.DSM DISK 2,048.0M in
DISK_STG_01
dsmfmt -data "H:\TSMDATA\STG_POOL_01.DSM@" 2048
rem Restore the previous working directory.
popd
end PRIMARY.VOLUMES.REPLACEMENT.CREATE script
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin PRIMARY.VOLUMES.REPLACEMENT macro
/* Purpose: Define replacement primary storage pool volumes for
either: */
/* 1. Original volume in a storage pool whose device class was
DISK. */
/* 2. Original volume in a storage pool with MAXSCRATCH=0. */
/* 3. Original volume in a storage pool and volume scratch=no. */
/* Recovery administrator: Edit this section for your replacement
*/
/* volume names. New name must be unique, i.e. different from any
*/
/* original or other new name. */
/* Replace H:\TSMDATA\STG_POOL_01.DSM DISK 2,048.0M in DISK_STG_01
*/
def vol DISK_STG_01 "H:\TSMDATA\STG_POOL_01.DSM@" acc=READW
/* Replace ABA920L1 CLASS1 190,734.0M in LTO_STGP_01 */
def vol LTO_STGP_01 "ABA920L1@" acc=READW
end PRIMARY.VOLUMES.REPLACEMENT macro
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin STGPOOLS.RESTORE macro
/* Purpose: Restore the primary storage pools from copy storage
pool(s). */
/* Recovery Administrator: Delete entries for any primary storage
pools */
/* that you do not want to restore. */
restore stgp DISK_STG_01
restore stgp LTO_STGP_01
end STGPOOLS.RESTORE macro
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin VOLUME.HISTORY.FILE
******************************************************************
*****************************
**********
*
* Sequential Volume Usage History
* Updated 03/27/2008 19:28:50
*
* Operation Volume Backup Backup Volume Device Volume
* Date/Time Type Series Oper. Seq Class Name Name
******************************************************************
*****************************
**********
2007/07/08 18:01:49 STGNEW 0 0 0 CLASS1 IBM001
2007/07/09 17:42:32 STGNEW 0 0 0 CLASS1 IBM002
2007/07/09 17:43:55 STGNEW 0 0 0 CLASS1 IBM003
2007/07/10 10:33:36 STGNEW 0 0 0 CLASS1 IBM004
2007/07/24 17:06:17 STGDELETE 0 0 0 CLASS1 IBM001
                                                                 76
2007/07/24 17:06:44 STGDELETE 0 0 0 CLASS1 IBM003
2007/07/24 17:28:41 STGNEW 0 0 0 CLASS1
ABA920L1
2007/07/24 18:04:52 STGDELETE 0 0 0 CLASS1 IBM004
2007/07/24 18:17:53 STGNEW 0 0 0 CLASS1
ABA922L1
2007/07/24 18:20:02 STGDELETE 0 0 0 CLASS1 IBM002
2007/07/24 18:32:39 STGNEW 0 0 0 CLASS1
ABA924L1
* Location for volume ABA925L1 is: 'Trezor, Brno, CR'
2007/07/24 19:20:33 BACKUPFULL 6 0 1 CLASS1
"ABA925L1"
2007/07/26 15:49:42 STGNEW 0 0 0 CLASS1
"ABA926L1"
* Location for volume ABA927L1 is: 'Trezor, Brno, CR'
2007/07/26 17:23:38 BACKUPFULL 7 0 1 CLASS1
"ABA927L1"
end VOLUME.HISTORY.FILE
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin DEVICE.CONFIGURATION.FILE
/* Device Configuration */
DEFINE DEVCLASS CLASS1 DEVTYPE=LTO FORMAT=DRIVE MOUNTLIMIT=DRIVES
MOUNTWAIT=60
MOUNTRETENTION=60 PREFIX=ADSM LIBRARY=LB6.0.0.3
DEFINE DEVCLASS FILEONFAST DEVTYPE=FILE FORMAT=DRIVE
MAXCAPACITY=512000K MOUNTLIMIT=1
DIRECTORY="H:\TSMDBBACKUP\" SHARED=NO
SET SERVERNAME TEST_SERVER1
SET SERVERPASSWORD 18c0be89
DEFINE LIBRARY LB6.0.0.3 LIBTYPE=SCSI SHARED=NO
DEFINE DRIVE LB6.0.0.3 MT01 ELEMENT=256 ONLINE=Yes
DEFINE DRIVE LB6.0.0.3 MT02 ELEMENT=257 ONLINE=Yes
/* LIBRARYINVENTORY SCSI LB6.0.0.3 ABA920L1 4096 101*/
/* LIBRARYINVENTORY SCSI LB6.0.0.3 ABA922L1 4101 101*/
/* LIBRARYINVENTORY SCSI LB6.0.0.3 ABA928L1 4097 101*/
/* LIBRARYINVENTORY SCSI LB6.0.0.3 ABA929L1 4100 101*/
/* LIBRARYINVENTORY SCSI LB6.0.0.3 ABA990L1 4102 101*/
DEFINE PATH TEST_SERVER1 LB6.0.0.3 SRCTYPE=SERVER DESTTYPE=LIBRARY
DEVICE=lb1.6.0.4 ONLINE=YES
DEFINE PATH TEST_SERVER1 MT01 SRCTYPE=SERVER DESTTYPE=DRIVE
LIBRARY=LB6.0.0.3 DEVICE=mt1.2.0.4
ONLINE=YES
DEFINE PATH TEST_SERVER1 MT02 SRCTYPE=SERVER DESTTYPE=DRIVE
LIBRARY=LB6.0.0.3 DEVICE=mt1.4.0.4
ONLINE=YES
end DEVICE.CONFIGURATION.FILE
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin DSMSERV.OPT.FILE
*
==================================================================
* Tivoli Storage Manager
* Server Options File - Version 5, Release 3, Level 0
* 5639-A09 (C) Copyright IBM Corporation, 1990, 2001,
* All Rights Reserved.


                                                                 77
*
==================================================================
*
* Tivoli Storage Manager (TSM):
* Server Options File (dsmserv.opt)
* Platform: Windows NT
*
* Note -- This file was generated by the TSM Options File Editor.
*
*
==================================================================
*
* HTTP
*
*
******************************************************************
* HTTPport
*
* Specifies the HTTP port address of a TSM Web interface.
*
* Syntax
* +------------------+--------------------------------------------
--+
* | HTTPort | port_addr |
* +------------------+--------------------------------------------
--+
*
COMMmethod HTTP
HTTPPort 1580
*
*
==================================================================
*
* TCPIP
*
*
******************************************************************
* TCPPort
*
* Specifies the TCP/IP port address of a TSM server.
*
* Syntax
* +------------------+--------------------------------------------
--+
* | TCPPort | port_addr |
* +------------------+--------------------------------------------
--+
*
COMMmethod TCPIP
TCPPort 1500
*
*
******************************************************************
* TCPWindowsize
*
                                                                 78
* Specifies the amount of data to send or receive
* before TCP/IP exchanges acknowledgements with the client node.
* This actual window size that is used in a session will be the
* minimum size of the server and client window sizes.
* Larger window sizes may improve performance
* at the expense of memory usage.
*
* Syntax
* +------------------+--------------------------------------------
--+
* | TCPWindowsize | window_size |
* +------------------+--------------------------------------------
--+
*
TCPWindowsize 63
*
*
******************************************************************
**
* TCPNODELAY
*
* Specifies whether the server should send small amounts
* of data or allow TCP/IP to buffer the data.
* Disallowing buffering may improve throughput at the expense
* of more packets being sent over the network.
*
* Syntax
* +------------------+--------------------------------------------
--+
* | TCPNODELAY | YES | NO |
* +------------------+--------------------------------------------
--+
*
TCPNODELAY Yes
*
*
==================================================================
*
* NAMEDPIPE
*
*
******************************************************************
* NAMEdpipename
*
* Specifies the name of the TSM server's named pipe.
*
* Syntax
* +------------------+--------------------------------------------
--+
* | NAMEdpipename | name |
* +------------------+--------------------------------------------
--+
*
COMMmethod NAMEDPIPE
NAMEdpipename \\.\pipe\Server1
                                                                 79
*
*
==================================================================
*
*
******************************************************************
**
* NPBUFFERSIZE
*
* Specifies the size of the named pipes communication buffer size
* in KB.
*
* Syntax
* +-----------------------+---------------------------------------
--+
* | NPBUFFERSIZE | value |
* +-----------------------+---------------------------------------
--+
*
NPBUFFERSIZE 8
*
*
==================================================================
*
*
******************************************************************
**
* SECUREPIPES
*
* Specifies whether or not to use secure named pipes (NT Unified
Logon.)
*
* Specify a value of Yes or No
*
* Syntax
* +-----------------------+---------------------------------------
--+
* | SECUREPIPES | value |
* +-----------------------+---------------------------------------
--+
*
SECUREPipes No
*
*
==================================================================
*
*
******************************************************************
**
* ADSMGroup
*
* Specifies the Windows NT Group name to use for authentication.
*
* Syntax


                                                                 80
* +-----------------------+---------------------------------------
--+
* | ADSMGROUP | groupname |
* +-----------------------+---------------------------------------
--+
*
ADSMGROUPname adsmserver
*
*
******************************************************************
**
* NPAUDITSuccess
*
* Specifies whether or not to audit successful use of secure named
pipes
*
* Specify a value of Yes or No
*
* Syntax
* +-----------------------+---------------------------------------
--+
* | NPAUDITSuccess | value |
* +-----------------------+---------------------------------------
--+
*
NPAUDITSuccess No
*
*
******************************************************************
* NPAUDITFailure
*
* Specifies whether or not to audit a failed attempt to use of
secure
* named pipes
*
* Specify a value of Yes or No
*
* Syntax
* +-----------------------+---------------------------------------
--+
* | NPAUDITFailure | value |
* +-----------------------+---------------------------------------
--+
*
NPAUDITFailure No
*
*
==================================================================
*
* MSGINTERVAL
*
*
******************************************************************
**
* MSGINTerval
                                                                 81
*
* Specifies the number of minutes to wait between issuing a mount-
tape
* tape message on the TSM server console.
*
* Syntax
* +------------------+--------------------------------------------
--+
* | MSGINTerval | value |
* +------------------+--------------------------------------------
--+
*
MSGINTerval 1
*
*
==================================================================
*
* MAXSESSIONS
*
*
******************************************************************
* MAXSessions
*
* Specifies the number of simultaneous client sessions.
*
* Syntax
* +------------------+--------------------------------------------
--+
* | MAXSessions | value |
* +------------------+--------------------------------------------
--+
*
MAXSessions 25
*
*
==================================================================
*
* BUFPOOLSIZE
*
*
******************************************************************
**
* BUFPoolsize
*
* Specifies the size of the database buffer pool in Kbytes.
*
* Syntax
* +------------------+--------------------------------------------
--+
* | BUFPoolsize | value |
* +------------------+--------------------------------------------
--+
*
BUFPoolsize 262144
*
                                                                 82
*
==================================================================
*
* LOGPOOLSIZE
*
*
******************************************************************
**
* LOGPoolsize
*
* Specifies the size of the log buffer pool in Kbytes.
*
* Syntax
* +------------------+--------------------------------------------
--+
* | LOGPoolsize | value |
* +------------------+--------------------------------------------
--+
*
LOGPoolsize 512
*
*
==================================================================
*
* COMMTIMEOUT
*
*
******************************************************************
* COMMTimeout
*
* Specifies the communication timeout value in seconds.
*
* Syntax
* +------------------+--------------------------------------------
--+
* | COMMTimeout | value |
* +------------------+--------------------------------------------
--+
*
COMMTimeout 60
*
*
==================================================================
*
* IDLETIMEOUT
*
*
******************************************************************
* IDLETimeout
*
* Specifies the number of minutes that a client session can be
idle
* before its session will be canceled.
*
* Syntax
                                                                 83
* +------------------+--------------------------------------------
--+
* | IDLETimeout | value |
* +------------------+--------------------------------------------
--+
*
IDLETimeout 15
*
*
==================================================================
*
* TXNGroupmax
*
*
******************************************************************
* TXNGroupmax
*
* Specifies the number of files tranferred as a group between
commit
* points.
*
* Syntax
* +------------------+--------------------------------------------
--+
* | TXNGroupmax | numfiles |
* +------------------+--------------------------------------------
--+
*
TXNGroupmax 256
*
*
==================================================================
*
* DATEFORMAT
*
*
******************************************************************
* DATEformat
*
* Specifies the format in which date references will be displayed.
*
* Syntax
* +------------------+--------------------------------------------
--+
* | DATEformat | value |
* +------------------+--------------------------------------------
--+
*
DATEformat 1
*
*
==================================================================
*
* TIMEFORMAT
*
                                                                 84
*
******************************************************************
* TIMEformat
*
* Specifies the format in which time references will be displayed.
*
* Syntax
* +------------------+--------------------------------------------
--+
* | TIMEformat | value |
* +------------------+--------------------------------------------
--+
*
TIMEformat 1
*
*
==================================================================
*
* NUMBERFORMAT
*
*
******************************************************************
* NUMberformat
*
* Specifies the format in which number references will be
displayed.
*
* Syntax
* +------------------+--------------------------------------------
--+
* | NUMberformat | value |
* +------------------+--------------------------------------------
--+
*
NUMberformat 1
*
*
==================================================================
*
* MESSAGEFORMAT
*
*
******************************************************************
* MESsageformat
*
* Specifies the format in which messages will be displayed.
*
* Syntax
* +------------------+--------------------------------------------
--+
* | MESsageformat | value |
* +------------------+--------------------------------------------
--+
*
MESsageformat 1
                                                                 85
*
*
==================================================================
*
* LANGUAGE
*
*
******************************************************************
* LANGuage
*
* Specifies the language to use for help and error messages.
*
* Syntax
* +------------------+--------------------------------------------
--+
* | LANGuage | name |
* +------------------+--------------------------------------------
--+
*
LANGuage AMENG
*
*
==================================================================
*
* EXPINTERVAL
*
*
******************************************************************
* EXPInterval
*
* Specifies the number of hours between automatic inventory
expiration
* runs.
*
* Syntax
* +------------------+--------------------------------------------
--+
* | EXPInterval | value |
* +------------------+--------------------------------------------
--+
*
EXPInterval 24
*
*
==================================================================
*
* EXPQUIET
*
*
******************************************************************
* EXPQUiet
*
* Reduces the number of policy change messages generated during
* expiration processing.
*
                                                                 86
* Specify a value of Yes or No
*
* Syntax
* +------------------+--------------------------------------------
--+
* | EXPQUiet | value |
* +------------------+--------------------------------------------
--+
*
EXPQUiet Yes
*
*
==================================================================
* MIRRORREAD
*
*
******************************************************************
* MIRRORRead
*
* Specifies the mode used for reading recovery log pages or data
base
* log pages
*
* Syntax
* +------------------+-----------+--------------------------------
--+
* | MIRRORRead | LOG | DB | Normal | Verify |
* +------------------+-----------+--------------------------------
--+
*
MIRRORRead DB Normal
*
*
==================================================================
*
* MIRRORWRITE
*
*
******************************************************************
* MIRRORWrite
*
* Specifies how mirrored volumes are accessed when the server
writes
* pages to the recovery log or database during normal processing.
*
* Syntax
* +------------------+-----------+--------------------------------
--+
* | MIRRORWrite | LOG | DB | Sequential | Parallel |
* +------------------+-----------+--------------------------------
--+
*
MIRRORWrite DB Sequential
*


                                                                 87
*
==================================================================
*
*
******************************************************************
* SELFTUNEBUFPOOLSIZE
*
* Specifies whether TSM can automatically tune the database buffer
pool
* size. If you specify YES, TSM resets the buffer cache statistics
at
* the start of expiration processing. After expiration completes,
if
* cache hit statistics are less than 98, TSM increases the
database
* buffer pool size to try to increase the cache hit percentage.
* The default is NO.
*
* Syntax
* +---------------------+-----+-----------------------------------
+
* | SELFTUNEBUFpoolsize | YES | NO |
* +---------------------+-----+-----------------------------------
+
*
SELFTUNEBUFpoolsize No
*
*
==================================================================
*
*
******************************************************************
* DBPAGESHADOW
*
* Specifies whether database page shadowing is enabled. If
database
* page shadowing is enabled TSM mirrors every write to a database
page.
* You can enable shadowing only if database volume mirrors are
written
* to in parallel (that is, the MIRRORWRITE DB option is set to
PARALLEL.
* The default is YES.
*
* Syntax
* +---------------------+-----+-----------------------------------
+
* | DBPAGEShadow | YES | NO |
* +---------------------+-----+-----------------------------------
+
*
DBPAGEShadow Yes
*
*
==================================================================
                                                                 88
*
*
******************************************************************
* DBPAGESHADOWFILE
*
* Specifies the name of the file to use for database page
shadowing.
* If database page shadowing is enabled, the page shadow either
goes
* to the default file or is created in the directory that the
server
* is running from. The default file, DBPGSHDW.BDT, resides in the
* directory where the server is installed.
*
* Syntax
* +-------------------+-------------------------------------------
+
* | DBPAGESHADOWFile | value |
* +-------------------+-------------------------------------------
+
*
DBPAGESHADOWFile "dbpgshdw.bdt"
*
*
==================================================================
* MIRRORREAD
*
*
******************************************************************
* MIRRORRead
*
* Specifies the mode used for reading recovery log pages or data
base
* log pages
*
* Syntax
* +------------------+-----------+--------------------------------
--+
* | MIRRORRead | LOG | DB | Normal | Verify |
* +------------------+-----------+--------------------------------
--+
*
MIRRORRead LOG Normal
*
*
==================================================================
*
* MIRRORWRITE
*
*
******************************************************************
* MIRRORWrite
*
* Specifies how mirrored volumes are accessed when the server
writes
                                                                 89
* pages to the recovery log or database during normal processing.
*
* Syntax
* +------------------+-----------+--------------------------------
--+
* | MIRRORWrite | LOG | DB | Sequential | Parallel |
* +------------------+-----------+--------------------------------
--+
*
MIRRORWrite LOG Parallel
*
*
==================================================================
*
* MOVEBATCHSIZE
*
*
******************************************************************
* MOVEBatchsize
*
* Use this entry field to specify the number of files that are to
be
* moved and grouped together in a batch within the same
transaction.
*
* Specify a number between 1 and 256.
*
* The default value is 32.
*
* Syntax
* +------------------+--------------------------------------------
--+
* | MOVEBatchsize | value |
* +------------------+--------------------------------------------
--+
*
MOVEBatchsize 40
*
*
==================================================================
*
* MOVESIZETHRESHOLD
*
*
******************************************************************
* MOVESizethreshold
*
* Use this entry field to specify a threshold, in megabytes, for
the amount
* of data moved as a batch within the same server transaction.
When this
* threshold is reached, no more files are added to the current
batch. A
* new transaction is then started after the current batch is
moved.
                                                                 90
*
* Specify a number between 1 and 500 (megabytes).
*
* The default value is 1 (megabyte).
*
* Syntax
* +-------------------+-------------------------------------------
---+
* | MOVESizethreshold | value |
* +-------------------+-------------------------------------------
---+
*
MOVESizethresh 500
*
*
==================================================================
*
*
******************************************************************
* SELFTUNETXNSIZE
*
* Specifies whether TSM can automatically change the values of the
* TXNGROUPMAX, MOVEBATCHSIZE, and MOVESIZETHRESH server options.
* TSM sets the TXNGROUPMAX option to optimize client-server
* throughput and sets the MOVEBATCHSIZE and MOVESIZETHRESH options
* to their maximum to optimize server throughput. The default is
NO.
*
* Syntax
* +-----------------+-----+---------------------------------------
+
* | SELFTUNETXNsize | YES | NO |
* +-----------------+-----+---------------------------------------
+
*
SELFTUNETXNsize No
*
*
==================================================================
*
* STATUSMSGCNT
*
*
******************************************************************
* STAtusmsgcnt
*
* Use this entry field to specify the number of records (times
1000)
* that will be processed between status messages during DSMSERV
DUMPDB
* and DSMSERV LOADDB commands.
*
* Specify a number between 1 and 10000 (this number is multiplied
by 1000).
*
                                                                 91
* The default value is 10.
*
* Syntax
* +--------------------+------------------------------------------
---+
* | STAtusmsgcnt | value |
* +--------------------+------------------------------------------
---+
*
STAtusmsgcnt 1
*
*
==================================================================
*
* VOLUMEHISTORY
*
******************************************************************
* VOLUMEHistory <filename>
*
* Specifies the name of a file that should contain sequential
* volume history information when it is changed by the server.
* Sequential volume history information is used by the
administrator
* and server processes during server database recovery.
*
* More than one of these parameters may be specified to record
* sequential volume history information to multiple files
*
* Syntax
* +------------------+--------------------------------------------
--+
* | VOLUMEHistory | filename |
* +------------------+--------------------------------------------
--+
*
* VOLUMEHistory "volhist.out"
* The previous line was replaced by PREPARE to provide a fully
qualified
* file name.
VOLHIST "C:\PROGRA~1\TIVOLI\TSM\SERVER1\VOLHIST.OUT"
*
*
==================================================================
*
* DEVCONFIG
*
******************************************************************
* DEVCONFig <filename>
*
* Specifies the name of a file that should contain device
* configuration information when it is changed by the server.
* Device configuration information is used by the
* server processes during server database recovery or load and
* DSMSERV DUMPDB processing.
*
                                                                 92
* More than one of these parameters may be specified to record
* device configuration information to multiple files.
*
* Syntax
* +------------------+--------------------------------------------
--+
* | DEVCONFig | filename |
* +------------------+--------------------------------------------
--+
*
* DEVCONFig "devcnfg.out"
* The previous line was replaced by PREPARE to provide a fully
qualified
* file name.
DEVCONF "C:\PROGRA~1\TIVOLI\TSM\SERVER1\DEVCNFG.OUT"
*
*
==================================================================
*
*
******************************************************************
* RESTOREINTERVAL
*
* Specifies the restore interval.
*
* Syntax
* +-----------------------+---------------------------------------
--+
* | RESTOREINTERVAL | value |
* +-----------------------+---------------------------------------
--+
*
RESTOREINTerval 1440
*
*
==================================================================
*
*
******************************************************************
**
* USELARGEBuffers
*
* Specifies whether or not to use large buffers.
*
* Specify a value of Yes or No
*
* Syntax
* +-----------------------+---------------------------------------
--+
* | USELARGEBUFFERS | values |
* +-----------------------+---------------------------------------
--+
*
USELARGebuffers Yes
*
                                                                 93
*
==================================================================
*
* MISC
*
*
******************************************************************
* DISABLESCeds
*
* Specifies whether or not administrative and client schedules are
* disabled during a TSM server recovery scenario
*
* Specify a value of Yes or No
*
* Syntax
* +------------------+--------------------------------------------
--+
* | DISABLESC | value |
* +------------------+--------------------------------------------
--+
*
DISABLESCHEDS No
*
*
==================================================================
*
* MISC
*
*
******************************************************************
* EVENTSERVER
*
* Specifies whether at startup this server should contact the TSM
* event server.
*
* Specify a value of Yes or No
*
* Syntax
* +------------------+--------------------------------------------
--+
* | EVENTSERVER | value |
* +------------------+--------------------------------------------
--+
*
EVENTSERVER Yes
*
*
==================================================================
*
* REQSYSAUTHFILE
*
* Specifies whether, system authority is required for
administrative
* commands that cause the server to write to an external file.
*
                                                                 94
* Syntax
* +-------------------+-----+----+
* | REQSYSauthoutfile | YES | NO |
* +-------------------+-----+----+
*
REQSYS Yes
*
*
==================================================================
*
* ENABLE3590LIBRARY
*
*
******************************************************************
* ENABLE3590LIBrary
*
* When 3590 support is enabled, the TSM server automatically
begins to
* use the category with a number that is one greater than the
existing
* scratch category code that was specified on the TSM server
* DEFINE LIBRARY command.
*
* Specify a value of Yes or No
*
* Syntax
* +--------------------+------------------------------------------
---+
* | ENABLE3590LIBrary | value |
* +--------------------+------------------------------------------
---+
*
ENABLE3590 Yes
*
*
==================================================================
*
* 3494SHARED
*
*
******************************************************************
* 3494SHARED
*
* Specifies whether to use extra polling when drives are being
shared.
* Default is No.
*
* Specify a value of Yes or No
*
* Syntax
* +--------------------+------------------------------------------
---+
* | 3494SHARED | value |
* +--------------------+------------------------------------------
---+
                                                                 95
*
3494SHARED Yes
*
*
==================================================================
*
* ASSISTVCRRECOVERY
*
* Specifies whether TSM assists an IBM 3570 or 3590 drive in
* recovering from a lost or corrupted Vital Cartridge Records
(VCR)
* condition. If YES, the default, TSM server will locate directly
* to the end-of-data to allow the drives to restore the VCR.
*
* Syntax
* +-------------------+-----+----+
* | ASSISTVCRRECovery | YES | NO |
* +-------------------+-----+----+
*
ASSISTVCRRECovery Yes
*
*
==================================================================
* QUERYAuth
*
*
******************************************************************
*
* Specifies the administrative authority level that should be
required
* to issue QUERY or SQL SELECT commands. By default any
administrator
* can issue a QUERY or SELECT command. If you would like to
restrict
* the use of these commands to administrators with a specific
* authority level, this option can be specified with the level of
* authority desired.
*
* Syntax
* +------------+--------------------------------------------------
-----+
* | QUERYAuth | NOne | SYstem | POlicy | STorage | OPerator |
ANalyst |
* +------------+--------------------------------------------------
-----+
*
* Parameters
*
* NONE Specifies that any administrator can issue
* QUERY or SELECT commands without requiring
* any administrative authority.
*
* SYSTEM Specifies that administrators must have SYSTEM
* authority to issue QUERY or SELECT commands
*
                                                                 96
* POLICY Specifies that administrators must have POLICY
* authority over one or more policy domains
* (or SYSTEM authority) to issue QUERY or SELECT commands
*
* STORAGE Specifies that administrators must have STORAGE
* authority over one or more storage pools
* (or SYSTEM authority) to issue QUERY or SELECT commands
*
* OPERATOR Specifies that administrators must have OPERATOR
* authority (or SYSTEM authority) to issue QUERY or SELECT
* commands
*
* The default value is NONE
*
* Examples
* QUERYAUTH SYSTEM
* QUERYAUTH OPERATOR
*
*
==================================================================
QUERYAuth NONE
*
*
==================================================================
*
* ADREGISTER
*
* Specifies whether the TSM registers itself with Active Directory
* when the server starts up. The default is No.
*
* Syntax
* +-------------------+-----+----+
* | ADREGISTER | YES | NO |
* +-------------------+-----+----+
*
ADREGISTER No
*
*
==================================================================
===
*
* ADUNREGISTER
*
* Specifies whether the TSM unregisters itself with Active
Directory
* when the server halts. The default is No.
*
* Syntax
* +-------------------+-----+----+
* | ADUNREGISTER | YES | NO |
* +-------------------+-----+----+
*
ADUNREGISTER No
*


                                                                 97
*
==================================================================
*
* ADSETDC
*
* Specifies the name or address of the domain controller that
* Active Directory is installed on. If this parameter is not
provided
* the default action is to attempt to automatically detect the
* domain controller that the machine is registered to.
*
* Syntax
* +-----------+-----------------------------------------+
* | ADSETDC | DomainController name or TCP/IP address |
* +-----------+-----------------------------------------+
*
*
*
==================================================================
*
* ADCOMMENT
*
* Specifies the comment used when registering the server with
* Active Directory. If this parameter is not provided a default
* comment will be generated during server registration.
*
* Syntax
* +-----------+-----------------------------------------+
* | ADCOMMENT | comment |
* +-----------+-----------------------------------------+
*
* The following option was added by PREPARE.
DISABLESCHEDS YES
* The following option was added by PREPARE.
DISABLESCHEDS YES
end DSMSERV.OPT.FILE
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
*-*-*-*
begin LICENSE.INFORMATION
Last License Audit: 03/02/2008 09:40:05
Number of space management clients in use: 0
Number of space management clients licensed: 0
Is Tivoli Disaster Recovery Manager in use ?: Yes
Is Tivoli Disaster Recovery Manager licensed ?: Yes
Number of TDP for Oracle in use: 0
Number of TDP for Oracle licensed: 0
Number of TDP for MS SQL Server in use: 0
Number of TDP for MS SQL Server licensed: 0
Number of TDP for MS Exchange in use: 0
Number of TDP for MS Exchange licensed: 0
Number of TDP for Lotus Notes in use: 0
Number of TDP for Lotus Notes licensed: 0
Number of TDP for Lotus Domino in use: 0
Number of TDP for Lotus Domino licensed: 0
Number of TDP for Informix in use: 0
                                                                 98
Number of TDP for Informix licensed: 0
Number of TDP for SAP R/3 in use: 0
Number of TDP for SAP R/3 licensed: 0
Number of TDP for ESS in use: 0
Number of TDP for ESS licensed: 0
Number of TDP for ESS R/3 in use: 0
Number of TDP for ESS R/3 licensed: 0
Number of TDP for EMC Symmetrix in use: 0
Number of TDP for EMC Symmetrix licensed: 0
Number of TDP for EMC Symmetrix R/3 in use: 0
Number of TDP for EMC Symmetrix R/3 licensed: 0
Is Library Sharing in use: No
Is Library Sharing licensed: Yes
Number of Managed System for LAN in use: 9
Number of Managed System for LAN licensed: 20
Number of Managed System for SAN in use: 0
Number of Managed System for SAN licensed: 5
Number of Managed Libraries in use: 0
Number of Managed Libraries licensed: 1
Tivoli Data Protection for NDMP in use ?: No
Tivoli Data Protection for NDMP licensed ?: No
Server License Compliance: Valid
end LICENSE.INFORMATION
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin MACHINE.GENERAL.INFORMATION
Purpose: General information for machine TSM_HOST.
This is the machine that contains the server TEST_SERVER1.
Machine Name: TSM_HOST
Machine Priority: 50
Building: BUDOVA1
Floor: 3
Room: 249B
Description: W2K ADV SERVER
Recovery Media Name: WIN2K_ADV_SERVER
end MACHINE.GENERAL.INFORMATION
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin MACHINE.RECOVERY.INSTRUCTIONS
Purpose: Recovery instructions for machine TSM_HOST.
1 Boot from Windows 2000 Installation CD
2 Create a System Partition (C:)
3 Set Computer Name and Complete a Basic Windows 2000 Install
4 Set IP Address Information to Original System Settings
5 Test Network Connection
6 Install Windows 2000 Service Packs to Original Levels
7 Install Any Drivers Related to Partition Restore Processes (for
example, adapter drivers
for external disk arrays)
8 Create and Configure Drive Partitions to Original State.
9 Install TSM Client and Configure Pointer to TSM Server
10 Perform a TSM restore of the boot / system partition (c:)
11 Perform a TSM restore of the Windows Systems Objects
12 Perform a TSM restore of all other system partitions
13 Verify that restore is valid
end MACHINE.RECOVERY.INSTRUCTIONS
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
                                                                 99
begin MACHINE.CHARACTERISTICS
Purpose: Hardware and software characteristics of machine
TSM_HOST.
System Information report written at:03/25/2007 09:53:40PM
[System Information]
[Following are sub - categories of this main category]
 [System Summary]
Item Value
OS Name Microsoft Windows 2000 Server
Version 5.0.2195 Service Pack 2 Build 2195
OS Manufacturer Microsoft Corporation
System Name TSM_HOST
System Manufacturer IBM
System Model eserver xSeries 330 -[867411X]-
System Type X86 - based PC
Processor x86 Family 6 Model 11 Stepping 1 Genuine Intel ~1128 Mhz
Processor x86 Family 6 Model 11 Stepping 1 Genuine Intel ~1128 Mhz
BIOS Version IBM BIOS Ver 0.0
Windows Directory C:\WINNT
System Directory C:\WINNT\System32
Boot Device \Device\Harddisk0\Partition 1
Locale United States
User Name TSM_HOST\Administrator
Time Zone Pacific Daylight Time
Total Physical Memory 3,866,068KB
Available Physical Memory 3,558,968KB
Total Virtual Memory 9,660,368KB
Available Virtual Memory 9,196,060KB
Page File Space 5,794,300KB
Page File C:\pagefile.sys
[Hardware Resources]
end MACHINE.CHARACTERISTICS
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
begin MACHINE.RECOVERY.MEDIA.REQUIRED
Purpose: Recovery media for machine TSM_HOST.
Recovery Media Name: WIN2K_ADV_SERVER
Type: Boot
Volume Names: MS-w2k_adv_server
Location: Frame 1, 3rd drawer, box W2k boot
Description: Windows 2000 Advanced server
Product: Windows2000AS
Product Information: Standard windows bootable medium
end MACHINE.RECOVERY.MEDIA.REQUIRED
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-




                                                                100

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:2/8/2012
language:
pages:100