Diplomsko delo visokošolskega strokovnega študija Smer

UNIVERZA V MARIBORU FAKULTETA ZA ORGANIZACIJSKE VEDE

Diplomsko delo visokošolskega strokovnega študija Smer: Informatika v organizaciji in managementu

IZGRADNJA NADOMESTNEGA INFORMACIJSKEGA SISTEMA V

SPARKASSE D.D. Mentor: red. prof. dr. Vladislav Rajkovi� Kandidat: Uroš Štefe

Kranj, december 2006

ZAHVALA Zahvaljujem se mentorju, prof. dr. Vladislavu Rajkovi�u, za pomo� in svetovanje pri pisanju diplomske naloge. Za podporo in izkazano pomo� se zahvaljujem tudi ožjim sodelavcem v podjetju Banka Sparkasse d.d., vodji sektorja za informacijsko tehnologijo gospodu Roku Založniku, univ. dipl. ing. ra�unalništva in informatike ter vodji oddelka za infrastrukturo informacijske tehnologije gospodu Viktorju Prevor�niku, univ. dipl. ing. ra�unalništva in informatike. Zahvaljujem se tudi svoji družini za podporo pri študiju.

POVZETEK V diplomskem delu je predstavljen projekt izgradnje nadomestnega informacijskega sistema v Banki Sparkasse d.d. Omenjeni projekt je sestavni del projekta zagotavljanja neprekinjenega poslovanja banke. Predstavljena so nekatera dejstva, ki prikazujejo pomembnost izgradnje nadomestnega informacijskega sistema za organizacije, ki so življenjsko odvisne od njenega delovanja. V diplomskem delu je predstavljen princip delovanja obstoje�ega informacijskega sistema, ki temelji na Informix bazi. Predstavljen je na�rt prenove informacijskega sistema na osnovi sodobne tehnologije. KLJU�NE BESEDE

- ban�no poslovanje - nadomestni informacijski sistem - rezervna lokacija

ABSTRACT In graduation thesis is presented the project of building disaster recovery site at Banka Sparkasse d.d. This project is a part of project for assuring business continuity of bank. There are presented some facts, which shows the importance of building a disaster recovery for organizations that are critically dependent on their information systems. In graduation thesis is presented the principle how the current information system works, founded on Informix database. It is also presented the renovation of information system based on modern technology. KEYWORDS

- bank business - disaster recovery plan - recovery site

KAZALO 1 Uvod ......... ..................................................................................................

1.1 Predstavitev problema ........................................................................ 5 1.2 Predstavitev problemskega okolja, Banke Sparkasse d.d. ................... 6 1.3 Metode dela ....................................................................................... 7

2 Teoreti�ne osnove ...................................................................................... 2.1 Analiza tveganj ................................................................................... 8 2.2 Upravljanje s tveganji........................................................................... 9 2.3 Na�rtovanje neprekinjenega poslovanja............................................... 10

3 Obstoje�e stanje ......................................................................................... 3.1 Posnetek stanja ................................................................................... 11 3.1.1 Obstoje�i informacijski sistem ............................................... 11 3.1.2 Infrastruktura obstoje�ega strežniškega sistema .................... 13 3.1.3 Komunikacijska infrastruktura ............................................... 14 3.1.4 Sistem za izdelavo varnostne kopije podatkov ...................... 16 3.2 Kriti�na analiza ................................................................................. 17

4 Prenova ...................................................................................................... 4.1 Priprave na izvedbo rešitve ................................................................ 18 4.1.1 Najpogostejši vzroki za izpad informacijskega sistema....... 18 4.1.2 Dolo�itev stroškov................................................................ 19 4.1.3 Dolo�itev kriti�nih strežnikov ............................................. 20 4.2 Opis rešitve ........................................................................................

4.2.1 Dimenzioniranje informacijskega sistema .......................... 21 4.2.2 Prenova in principi delovanja po posameznih sklopih......... 22 4.2.3 Inštalacija opreme in testni zagon na rezervni lokaciji ........ 28 4.2.4 Razvoj na�rta okrevanja po nesre�ah ................................... 29 4.2.5 Udeležba in naloge oddelka informacijske tehnologije ....... 30

5 Kriti�na ocena predlagane rešive ...................................................... 32 5.1 SWOT analiza.................................................................................... 32

6 Zaklju�ek .................................................................................................... 34

Literatura in viri ................................................................................................. 35

Univerza v Mariboru – Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija

Uroš Štefe: Izgradnja nadomestnega informacijskega sistema v Sparkasse d.d.

5

1. Uvod 1.1 Predstavitev problema V današnjem �asu je poslovanje organizacij vse bolj odvisno od informacijske tehnologije, zato je potrebno v informacijske sisteme vgraditi varnostne mehanizme, ki prepre�ujejo zaustavitev poslovanja zaradi odpovedi informacijskega sistema. Organizacije, ki nimajo pripravljenega na�rta za okrevanje v takšnih situacijah lahko utrpijo veliko izgubo, naj si bo to izguba dobi�ka, tržnega deleža, ugleda, konkuren�nosti, v najslabšem primeru pa lahko celo propadejo. V na�rtu za neprekinjeno poslovanje (angl. Business Continuity Plan) morajo biti opredeljene kriti�ne in vitalne poslovne funkcije. Slovenski standard PSIST BS 7799, kodeks varovanja informacij navaja, da naj na�rtovanje neprekinjenega poslovanja vklju�uje ukrepe za ugotavljanje in zmanjševanje nevarnosti, omejuje naj posledice v primeru uresni�evanja varnostne grožnje in zagotavlja naglo vzpostavitev pomembnih dejavnosti. Na�rt neprekinjenega poslovanja je sestavljen iz naslednjih glavnih na�rtov: - na�rt obnovitve poslovanja - na�rt obnovitve in reševanja - na�rt ravnanja ob incidentih - na�rt neprekinjenega delovanja in - na�rt okrevanja po nesre�ah Na�rt obnovitve poslovanja, na�rt zaš�ite in reševanja ter na�rt neprekinjenega delovanja se ne navezujejo na informacijsko tehnologijo. Kriti�nost posameznih poslovnih funkcij dolo�imo na podlagi analize tveganj. Analiza tveganj vklju�uje po prioriteti razvrš�ene kriti�ne sisteme v skladu z �asovno ob�utljivostjo, kriti�nostjo in neobhodno potrebo za nadaljevanje poslovanja, ki sledi nesre�i. Pomemben del na�rta zagotavljanja neprekinjenega poslovanja v kriznih situacijah je izgradnja rezervne lokacije. Na�rt predvideva izgradnjo nadomestnega (rezervnega) informacijskega sistema na obstoje�i ali oddaljeni lokaciji, kar pa za organizacijo ponavadi pomeni velik finan�ni zalogaj. Namen diplomske naloge je izdelati kvaliteten dokument, v katerem bo predstavljena optimalna rešitev za izdelavo na�rta za izgradnjo nadomestnega informacijskega sistema in bo služil kot podlaga za izdelavo na�rta za neprekinjeno poslovanje v Banki Sparkasse d.d.



6

1.2 Predstavitev problemskega okolja Banke Sparkasse d.d. Zgodovina Banke Sparkasse d.d. Kärntner Sparkasse je leta 1991 kot prva tuja banka odprla predstavništvo v Ljubljani, nato pa še poslovalnice v drugih ve�jih krajih po Sloveniji. Leta 1995 je bila v Sloveniji ustanovljena še družba Sparkassen Leasing. Sredi leta 1999 je Banka Slovenije banki Kärntner Sparkasse AG, kot prvemu tujemu kreditnemu zavodu, podelila koncesijo za podružnico. Podružnica v Ljubljani je bila odprta 9. novembra 1999, pod vodstvom Josefa Lausseggerja in dr. Paula Tautscherja. S 1. oktobrom 2006 smo se zaradi uspešnega poslovanja Podružnice Kärntner Sparkasse AG Celovec, preoblikovali v samostojno Banko Sparkasse d.d. Kärntner Sparkasse AG izgrajuje svoj poslovni sistem v Sloveniji na najmodernejši informacijski tehnologiji. Na slovenskem trgu deluje kot tako imenovana »druga�na banka«, s široko paleto ban�nih storitev, kot so financiranje za podjetja in zasebne stranke, izbrani var�evalni produkti ter transakcijski ra�uni in gotovinsko poslovanje. Vir: www.sparkasse.si, Banka Sparkasse d.d., September 2006



7

1.3 Metode dela Za izvedbo projekta se oblikuje projektni tim. Projektni tim je sestavljen iz specialistov, tako na tehni�nem kot na poslovnem podro�ju. Dolo�i se vodja projektnega tima, ki je odgovoren za �asovno usklajenost projekta s terminskim planom projekta. Odgovoren je tudi za delitev nalog, ter komunikacijo in koordinacijo z ostalimi sektorji v banki. Izbrana arhitektura bo zagotovila ustrezno informacijsko infrastrukturo za naslednjih 3-5 let. Upoštevati je potrebno predvideno rast banke v tem obdobju. Pri izbiri je mo�an dejavnik vsekakor cena. Velja pa pravilo, varnejše je dražje.



8

2 Teoreti�ne osnove 2.1 Analiza tveganj V vsakem podjetju oziroma organizaciji je analiza tveganj osnova za zagotavljanje varnosti. Stroški in ukrepi morajo biti prilagojeni tveganjem, katerim je podjetje izpostavljeno. V osnovi lo�imo dva tipa analize tveganj: Kvantitativni tip analize tveganj, pri katerem se uporabita dva osnovna elementa in sicer: verjetnost nekega dogodka, da se bo storil in možna nastala škoda, ki bo nastala, �e se bo dogodek zgodil. Kvalitativni tip analize tveganj je pogostejši. V tem primeru verjetnostni podatki niso potrebni, ocenjuje se le potencialna škoda. Analiza tveganj je pomembna faza izdelave plana za neprekinjeno poslovanje. V tej fazi je potrebno izdelati seznam kriti�nih sistemov, ugotoviti grožnje za te sisteme ter oceniti, kaj za podjetje predstavlja nesprejemljivo prekinitev oziroma maksimalen �as prekinitve. Same poslovne funkcije v podjetju lahko rangiramo, glede na �asovno ob�utljivost in glede na potrebnost za nadaljevanje poslovanja, slede�e:

• Kriti�ne poslovne funkcije se ne morejo izvajati z ro�nimi metodami. Toleranca za te funkcije je ob prekinitvah zelo nizka, stroški prekinitve pa zelo visoki.

• Vitalne poslovne funkcije se lahko izvajajo ro�no, toda le kratko �asovno

obdobje in imajo višjo toleranco za prekinitve kot kriti�ne poslovne funkcije. Stroški prekinitve so obi�ajno pri teh funkcijah nižji kot pri kriti�nih funkcijah.

• Ob�utljive funkcije se lahko izvajajo ro�no neko daljše �asovno obdobje in to

z zmernimi stroški. Izvajanje teh funkcij obi�ajno zahteva dodatne napore. • Nekriti�ne poslovne funkcije se lahko prekinejo za dolo�en �as. Pri tem

obi�ajno nastane malo ali ni� stroškov za družbo in se lahko hitro vzpostavijo.

Toleranca je lahko izražena v denarni vrednosti ali v izgubi ugleda družbe. Nizka toleranca je pogojena z visoko denarno vrednostjo.



9

Da se izognemo prevelikemu številu scenarijev, katastrofe klasificiramo po njihovih efektih. Na podlagi tega izdelamo dva scenarija in sicer: - scenarij za totalno izgubo in - scenarij za delno izgubo. Scenariji za totalno izgubo vklju�ujejo prekinitve, ki prekinejo poslovanje vseh ali ve�ine kriti�nih in vitalnih poslovnih funkcij. Scenarije za delno izgubo si predstavljamo kot prekinitev nekaterih kriti�nih funkcij, medtem ko so ostale neovirane. 2.2 Upravljanje s tveganji��

Upravljanje s tveganji je disciplina, ki se ukvarja z ugotavljanjem verjetnosti ali bo nek dogodek v prihodnosti povzro�il škodo in ocenjevanjem, kakšna ta škoda bo. Zato uporablja razli�ne strategije, metode, tehnike ter pristope za napovedovanje, razpoznavanje in reševanje možnih nevarnosti, ki bi vplivale na doseganje ciljev organizacije. Upravljanje s tveganji je torej napovedovanje vplivov, ki jih bi pojav dolo�ene motnje na proces imel, �e bi ta motnja nastala. U�inkovito upravljanje s tveganji mora znati odgovoriti na tri vprašanja:

• Kaj bi lahko šlo narobe? • Kako bomo v tem primeru ukrepali? • �e bo že šlo kaj narobe, kako bomo ublažili u�inke?

Proces upravljanja s tveganji je mo�no odvisen od sposobnosti sistema, da zgradi strategije reševanja predvidljivih problemov. Ve�ja podjetja - predvsem banke, zavarovalnice in druge finan�ne institucije - imajo posebne oddelke, ki so zadolženi za upravljanje s tveganji. V teh oddelkih se ukvarjajo predvsem s planiranjem scenarijev, reševanjem sporov, koordiniranjem varnostnih programov in analiziranjem stanja ter dogodkov s kompleksnimi analizami. Na�rt za neprekinjeno poslovanje mora biti zasnovan modularno, da lahko aktiviramo celotni na�rt ali le del na�rta, kar je odvisno od vrste prekinitve. Moduli morajo biti organizirani po funkcijah, da se lažje vzdržujejo.



10

2.3 Na�rtovanje neprekinjenega poslovanja Pri samem na�rtovanju je nujno potrebno upoštevati dokument Združenja bank Slovenije »Metodologija zagotavljanja neprekinjenega poslovanja in vzpostavitev rezervnih zmogljivosti«. Omenjeni dokument predstavlja metodologijo oziroma procese, ki so potrebni pri izvedbi konkretne rešitve za na�rtovanje neprekinjenega poslovanja, s poudarkom na pripravi centrov rezervnih zmogljivosti. Zanimiva je tudi shema Gartnerja, ki prikazuje metodologijo neprekinjenega poslovanja po posameznih korakih.

Slika 1: Zaporedni koraki zagotavljanja BCP (vir Gartner, 2002)



11

3 Obstoje�e stanje 3.1 Posnetek stanja 3.1.1 Obstoje�i informacijski sistem Glavni del informacijskega sistema, ki podpira vse poslovne procese Banke Sparkasse d.d., temelji na podlagi Informix podatkovne baze. Informix baza poteka na dveh AIX strežnikih, ki sta povezana v gru�o (angl. cluster). V gru�o sta povezana po metodi HaCMP. Tak na�in povezave nam optimalno zmanjša možnost izpada zaradi strojne napake v eni sami to�ki (angl. single point of failure). Strežnika sta v lo�enih prostorih v banki. Podatki se shranjujejo na zunanje diskovno polje (FastT), ki je v sistemu RAID 1. Tretjina od 250 zaposlenih dnevno potrebuje Informix bazo pri svojem delu, kar pomeni dnevno preko 80 simultanih povezav do baze. Upoštevati je potrebno dejstvo, da ima v dolo�enem trenutku uporabnik lahko odprtih tudi ve� sej naenkrat. Delovanje AIX strežnika je bistvenega pomena za izvajanje pla�ilnega prometa, delovanje aplikacije ban�nega okenca (NetKsp) ter delovanje elektronskega ban�ništva. Aplikacija ban�nega okenca poteka na dveh strežnikih povezanih v legatto gru�o. Aplikacija elektronskega ban�ništva (NetStik) poteka prav tako na dveh strežnikih povezanih preko NLB (angl. Network Load Balancing) metode. Poleg omenjenih Informix bazo uporabljajo knjigovodski programi (glavna knjiga, saldakonti). Za izvajanje pla�ilnega prometa je potrebno, poleg AIX strežnikov, zagotoviti še ustrezno delovanje strežnika s Swift aplikacijo in datote�nega strežnika na katerem je nameš�ena pametna kartica. Informix baza se uporablja tudi za legitimacijo v telefonskem ban�ništvu (angl. e-banking). Za upravljanje s strankami se uporablja aplikacija UBM. Aplikacija poteka na Windows strežniku, za shranjevanje podatkov pa uporablja DB2 bazo.



12

Slika 2: Povezava na Informix bazo Poleg Informix in DB2 baze se uporablja še SQL baza, ki jo uporablja program Sabine, ki se uporablja za izra�unavanje bonitet. Na lo�enem strežniku SQL bazo uporablja spletni portal Banke Sparkasse d.d. (S-Net). Trenutno ima ve�ina svetovalcev v banki na svojem ra�unalniku inštalirano virtualno okolje programa Windows, na vsaki od njih pa poteka instanca SQL baze, ki ga potrebuje program Wienner Staedtische in se uporablja za sklepanje pogodb življenjskih zavarovanj strank. Prav tako poteka aplikacija za registracijo prisotnosti na instanci SQL baze. Exchange poštni strežnik se uporablja za izmenjavo elektronske pošte. Strežnik ima lokalne diske v diskovnem polju. Vsak uporabnik ima koli�insko omejen prostor na strežniku, na katerem pa zaradi rasti banke in s tem pove�evanja števila zaposlenih zmanjkuje prostora. Trenutno se uporablja Exchange verzija 5.5. Informacijski sistem sestavljata dva domenska strežnika, ki sta bistvenega pomena za nadzor informacijskega sistema ter dolo�anje pravic uporabnikov.



13

Med pomembnejšimi so tudi skupina datote�nih Windows strežnikov. Pomembnejši podatki (npr. dokumenti uporabnikov) se shranjujejo na zunanja diskovna polja. Poleg vseh omenjenih informacijski sistem sestavlja še preko 25 ostalih strežnikov, ki pa niso kriti�nega pomena za poslovanje in obstoj banke. Med njimi je terminalski strežnik, ki omogo�a uporabnikom na poslovnih enotah uporabo UBM–a ter še nekaterih ostalih aplikacij. Strežnik, ki omogo�a delovanje in upravljanje TSM knjižnice, ki se uporablja za izdelovanje varnostnih kopij podatkov. Xwall opravlja vlogo strežnika za nadzor nad elektronsko pošto (antivirus, blokade priponk, antispam, omejite velikosti poslanih oziroma prejetih sporo�il). Strežnik z antivirusno aplikacijo z upravljalno konzolo, ki dolo�a politiko zaš�ite pred virusi ter omogo�a pregled nad zdravstvenim stanjem sistema. Lo�en je tudi DHCP strežnik, ki omogo�a povezavo v omrežje preko dinami�nega IP-ja. Prav tako je lo�en strežnik z Lotus Notes aplikacijo v kateri se hranijo interna navodila posameznih sektorjev ter projektna dokumentacija. Ostali strežniki:

• faks strežnik, • strežniki klicnega centra, • strežniki za snemanje pogovorov elektronskega ban�ništva, • strežnik za izdelovanje nekaterih varnostnih kopij s programsko opremo CA

ArcServe backup, • strežniki s pomožno programsko opremo za nadzor informacijskega sistema, • strežniki z najrazli�nejšo uporabniško programsko opremo, ki nima

neposrednega vpliva na poslovanje banke, ter se ne uporablja za delo s strankami,

• strežnika za dostop zunanjih pogodbenih vzdrževalcev. 3.1.2 Infrastruktura obstoje�ega strežniškega sistema Obstoje�a strežniška struktura je sestavljena v glavnem iz IBM strežnikov in IBM ra�unalnikov, ki opravljajo funkcijo strežnika. Izdelani seznam strežnikov je zaupne narave, zato ga ne prilagam.



14

Pomembnejši podatki se shranjujejo na skupno IBM diskovno polje po ve�ini tipa RAID 1 ali RAID 5.

Slika 3,4: Strežniki ter diskovno polje (FastT) Varnostna kopija podatkov (backup) se dnevno izdeluje in ustrezno hrani preko IBM TSM knjižnice. 3.1.3 Komunikacijska infrastruktura Komunikacijsko infrastrukturo sestavljajo usmerjevalniki ter stikala proizvajalcev 3com in Cisco Systems. Trenutno zgradbo lokalnega omrežja prikazuje slede�a shema. Natan�nejša shema je zaupne narave, zato je ne prilagam.



15

Slika 5: Komunikacijska infrastruktura



16

3.1.4 Sistem za izdelavo varnostne kopije podatkov (backup) Zelo pomembno je, da se varnostna kopija podatkov izvaja pravilno in da �im manj obremenjuje glavni sistem. Za ustvarjanje varnostne kopije podatkov se uporablja TSM knjižnica s 60 LTO kasetami, na katere gre 400GB nekompresiranih oziroma do 800 GB kompresiranih podatkov. Knjižnico se upravlja preko management konzole na fizi�no lo�enem strežniku. Varnostna kopija podatkov se pono�i najprej prenese na diskovna polja, ker je hitrost mnogo višja kot pa ob prenosu na LTO trakove. Nato se podatki iz diskovnega polja prenesejo na dolo�eni sektor (angl. Storage pool) v TSM knjižnici. Posebej pa se ustvari še iznosljiva varnostna kopija podatkov, ki jih je dnevno cirka 200GB. Iznosljivo kopijo se dnevno pošilja na oddaljeno lokacijo. S tem je banka obvarovana pred izgubo kriti�nih podatkov potrebnih za poslovanje. V primeru napake (odpovedi) pri izdelavi varnostne kopije se le-ta (le za AIX strežnik) avtomatsko preusmeri na drug kolinearen sektor. Princip izdelave varnostne kopije nazorno prikazuje slede�a shema.

Dikovno polje

Strežniki

Princip izdelave varnostnih kopij

AIX strežnikaAIX

skladiš�e (angl. storage pool) BACK_LTO2

Primer odpovedi skladiš�e (angl. storage pool) BACK_LTO2_COL

skladiš�e (angl. storage pool) BAARC_LTO2_COPY

- kolinearni pool

-iznosljiva kopija

Slika 6: Princip izdelave varnostnih kopij



17

3.2 Kriti�na analiza Izgradnja nadomestnega informacijskega sistema je vsekakor nujna. V primeru ve�je katastrofe bo mogo�a hitra povrnitev informacijskega sistema v prvotno stanje. S tem bo banka tudi ugodila priporo�ilom Banke Slovenije o nadomestnem informacijskem sistemu na rezervni lokaciji. Obstoje�i informacijski sistem je vsekakor sestavljen iz prevelikega števila strežnikov, zato je nujna konsolidacija in optimizacija strežnikov. Postaviti je potrebno infrastrukturo, ki bo zadostovala potrebam za naslednjih 3-5 let. Rešitev mora upoštevati predvideno rast banke v tem obdobju. Infrastruktura naj bo nadgradljiva in cenovno sprejemljiva. Obstoje�i sistem je vsekakor težko upravljati in nadzorovati. Zato je potrebno uvesti metode, ki bodo to omogo�ale. S tem bo omogo�eno lažje in pravo�asno odkrivanje morebitnih nepravilnosti v sistemu ter takojšnje reagiranje. Trenutna politika shranjevanja varnostne kopije podatkov ni ustrezna. Podrobno je potrebno analizirati, koliko �asa banka potrebuje posamezne podatke in dolo�iti politiko v skladu z rezultati te analize. V obstoje�i knjižnici zaradi neustrezne politike po nepotrebnem zmanjkuje prostora. Potrebno je dodati še en terminalski strežnik, ki bo omogo�al še ostalim uporabnikom na lokacijah uporabo mrežnega UBM-a, ter še nekaterih ostalih aplikacij. Trenutne mrežne povezave do poslovalnic na lokacijah ne zagotavljajo ustrezne hitrosti. Terminalski na�in bo omogo�il hitrejše delovanje teh aplikacij, saj se bo preko mreže do uporabnika prenašala le slika zaslona.



18

4 Prenova 4.1 Priprave na izvedbo rešitve 4.1.1 Najpogostejši vzroki za izpad informacijskega sistema Kot navaja spletna stran www.McData.com (McData, 2006) so med najpogostejšimi vzroki za izpad informacijskega sistema izpad elektri�ne energije (16%), napaka na ra�unalniški strojni opremi (13%), požar(11%) ter poplava(10%). V ve� kot polovici primerov je potreben preklop na rezervno lokacijo. V najve� odstotkih je preklop potreben v primeru požarov. Po posameznih branžah izpad najbolj prizadene organizacije na podro�ju energije, telekomunikacij, proizvodnje, finan�ništva, informacijske tehnologije. Ban�ništvo se nahaja na devetem mestu v svetovnem povpre�ju z izpadom približno milijon dolarjev na uro.

0

5

10

15

20

vrsta grožnje

v %

Izpad elektri�ne energije Strojna ra�unalniška napaka PožarPoplava Potres OrkaniProgramska napaka Bombandiranje Neurje sneg/veterIzpad mreže Kontaminacija Po�ena cevPisilna evakuacija HVAC napaka Zakasnjena relokacijaNemiri

Slika 7: Najpogostejši vzroki za izpad (vir:McData, www.McData.com)



19

4.1.2 Dolo�itev stroškov Banka mora dolo�iti izgubo, ki jo prizadene v razli�nih �asovnih obdobjih, zaradi nedelovanja informacijskega sistema. Izguba se mora definirati po posameznih poslovnih podro�jih banke. Na podlagi rezultatov se izvede povezava s strojno opremo ter aplikacijami, ki jih dolo�eno poslovno podro�je potrebuje. Glede na izgube se dolo�i na�in restavriranja ter izbere ustrezna stojna oprema.

Izgub

e

Str

oški

�as odpovedi

Stro

ški

�as odpovedi

Stroški

Stro

ški

�as odpovedi

stroški izgube

Maksimalni stroški izgradnje rezervnega centra.

Sprejemljiv �as nedelovanja IS

Slika 8: Dolo�itev stroškov (vir: Von Magazine, Disaster recovery and business continuity, Oktober 2006)



20

4.1.3 Dolo�itev kriti�nih strežnikov Posamezni sektorji ocenijo vrednost direktnih in indirektnih izgub zaradi odpovedi informacijskega sistema. Glede na rezultate se izdela tabela kriti�nih aplikacij. Ob tem je potrebno za vsako aplikacijo dolo�iti, v kakšnem roku je za sam poslovni proces še sprejemljivo, da se vzpostavi njeno delovanje na nadomestni lokaciji. Strežnike razdelimo na podlagi rezultatov v skupine glede na njihovo pomembnost za poslovanje. V primeru lokalnih odpovedi se �as odpovedi razdeli v štiri kategorije. Najve� 2 uri izpada – v to kategorijo spadajo vsi strežniki s programi za izvajanje pla�ilnega prometa in strežniki za izvajanje elektronskega ban�ništva ter aplikacije ban�nega okenca. Najve� 4 ure izpada – v to kategorijo spadajo vsi strežniki z bazami (DB2, SQL, EX) Najve� 8 ur (en delovni dan) – razni aplikacijski strežniki. Nad 8 ur - manj kriti�ni strežniki, ki služijo na primer za nadzor sistema. Na podlagi teh informacij lahko dolo�imo potrebno strojno opremo in na�in prenosa podatkov na rezervno lokacijo.



21

4.2 Opis rešitve 4.2.1 Dimenzioniranje informacijskega sistema Izbor komunikacijskih vodov Informacijski sistem je potrebno z rezervno lokacijo povezati preko opti�ne povezave. Ta na�in povezave omogo�a nemoteno replikacijo podatkov na rezervno lokacijo. Na izbiro sta dve opciji povezave preko opti�nih vlaken: DWDM (Dense Wave Division Multiplexing) – ta na�in omogo�a povezave do 200 km in tudi ve� s pomo�jo oja�evalnikov. Omogo�a šestnajst in ve� razli�nih signalov. CWDM (Coarse Wave Division Multiplexing) - ta na�in je dejansko pasivna metoda opti�nega prenosa in omogo�a povezave nekje do 50 km z do osmimi razli�nimi signali. Ta na�in povezave je v primerjavi s povezavo DWDM bistveno cenejši, prav tako pa so nižji vzdrževalni stroški. Glede na to, da se že predhodno izbrana lokacija nahaja znotraj radiusa petdesetih kilometrov, se seveda odlo�imo za ugodnejšo opcijo povezave (CWDM). Prenovljena komunikacijska infrastruktura Namesto podvojenih povezav na primarni lokaciji se ena povezava prenese na rezervno lokacijo. Prav tako se spremeni in posodobi metoda nekaterih povezav in dostopov. Komunikacijsko strukturo prikazuje slede�a shema. Izdelana je bila tudi podrobnejša shema, ki pa je ne prilagam, ker je zaupne narave.



22

Slika 9: Prenovljena komunikacijska infrastruktura



23

4.2.2 Prenova in principi delovanja po posameznih sklopih AIX strežnik z Informix bazo Glavni transakcijski sistem, ki je kriti�nega pomena za poslovanje banke, poteka na AIX strežniku z Informix bazo. Glede na predvideno rast banke je potrebno obstoje�a AIX strežnika nadgraditi. V vsakega izmed njiju se doda dual core procesor ter dodatna spominska kartica. Dokupi se dodatni IBM AIX 570. Enega izmed strežnikov (AIX2), ki sta v gru�i se preseli na rezervno lokacijo. Novega pa se locira na primarni lokaciji. Strojna oprema:

• 2–krat strežnik IBM 550 (RAM CPU), povezan v SAN diskovno polje (FastT) v RAID 1.

• 1–krat strežnik IBM AIX 570 (RAM CPU), povezan na San diskovno polje (FastT) v RAID 1.

• 1–krat strežnik IBM AIX 520 (RAM CPU), povezan na San diskovno polje (FastT) v RAID 1. Uporablja le v testne in razvojne namene.

• Mrežna komunikacijska oprema (usmerjevalniki in stikala Cisco Systems). Zmogljivost: Trenutna zmogljivost omogo�a preko 200 so�asnih povezav do baze. Omogo�a 100% procesiranje transakcij aplikacij pla�ilnega prometa, ban�nega okenca ter elektronskega ban�ništva. Metoda replikacije: Aktivna strežnika na primarni sta povezana v gru�o preko opti�ne povezave po metodi HaCMP (High Availability Cluster Multi-Processing). Strežnika sta dodatno povezana preko tehnologije Neverfail Heartbeat, ki poteka preko LAN omrežja, preko katerega prvi strežnik neprestano preverja status drugega in obratno. V primeru odpovedi enega izmed njiju delujo�i avtomatsko prevzame nase še grupo instanc baz strežnika, ki je odpovedal. Strežnik, lociran na sekundarni lokaciji, je v standby metodi. V primeru odpovedi obeh strežnikov se baza dvigne iz tretjega strežnika. Ob normalnem delovanju se podatki shranjujejo na diskovno polje na primarni lokaciji ter se iz njega sinhrono replicirajo na diskovno polje na sekundarni lokaciji.



24

Apptestno okolje

Ifmx testno okolje

MQ

IBM p570

IBM p550p5

TRX SP

TRX-vp

SP TRX

TRX

SP

TRX-vp

MQ

Primarna lokacija Rezervna lokacija

IBM p550

TRX

SP

TRX-vp

IBM p520

MQ

CPU CPU CPU CPU CPU CPU

HA

CM

P

TRX-vp

SIBI

SIBI

MQ

SIBI

p5

HA

CM

PH

AC

MP

TRX

SP

TRX-vp

MQ

Sinhrona replikacija

p5 p5 p5

CPU CPU

CPU

CPU

CPU

CPU

CPU

Dinami�na dodelitev

CPU

CPU

Slika 10: Princip delovanja AIX strežnikov. Aktivacijski �as in proces V primeru, da odpove le eden od aktivnih strežnikov, ki sta v gru�i, delujo�i v trenutku prevzame tudi vlogo nedelujo�ega. V tem primeru ban�no poslovanje ni prekinjeno, pojavi se lahko le po�asnejše procesiranje transakcij.. V primeru katastrofe na primarni lokaciji, strežnik na rezervni lokaciji prevzame vlogo obeh strežnikov na primarni lokaciji. Aktivira se diskovno polje na rezervni lokaciji Preden prevzame to vlogo, je potrebno izvesti kontrolo sistema in vseh pomožnih strežnikov. Za vse dodatne aktivnosti je predviden �as dveh ur. Ta �as predstavlja aktivacijski �as po prejetju zahteve kriznega managementa po aktiviranju rezervne lokacije. Standby metoda tretjega strežnika nam omogo�a hitro aktivacijo v primeru odpovedi obeh aktivnih strežnikov. Strežnik prevzame vlogo primarnega strežnika. Preden pa



25

prevzame to vlogo, je potrebno izvesti kontrolo sistema in vseh pomožnih strežnikov. Za vse dodatne aktivnosti je predviden �as ene ure. Ta �as predstavlja aktivacijski �as po prejetju zahteve kriznega managementa za aktiviranje tretjega strežnika. Preklop nazaj na glavni informacijski sistem. V primeru katastrofe je po aktivaciji rezervnega centra potrebna �imprejšnja vzpostavitev prvotnega stanja na primarni lokaciji. Po zagotovitvi vse ustrezne infrastrukture je potrebno podatke na diskovnem polju prekopirati na diskovno polje na primarni lokaciji ter zagotoviti sinhrono replikacijo podatkov. Vzpostaviti je potrebno standby bazo, ki bo vezana na to diskovno polje. Po izklopu sistema na rezervni lokaciji bo ta baza ponovno prevzela vlogo aktivne baze. Bazo na rezervni lokaciji moramo nato dolo�iti za standby bazo. Možnosti uporabe rezervnega sistema Strežnika na rezervni lokaciji se bo uporabljalo za razli�na testiranja in razvoj. Na rezervno lokacijo se bo prenesel eden od trenutnih produkcijskih strežnikov, kjer se mu bo dodelila druga�na vloga. Strežnika bosta uporabljala dsiskovno polje na primarni lokaciji. Virtualizacija Widows strežnikov Ve�ina ostalih strežnikov poteka v Microsoftovem Windows okolju. Glede na trenutne potrebe banke in ponudbo tehnologije se odlo�imo prenesti ve�ino strežnikov v virtualno okolje. Prav tako se bo v virtualno okolje prenesel strežnik z DB2 bazo. Baza bo locirana na diskovnem polju. Prenos v virtualno okolje bo potekal postopoma. Pred samo izvedbo virtualizacije je potrebna konsolidacija strežnikov. Glede na specifikacijo in zahteve se naredi seznam strežnikov, ki jih lahko združimo v isto okolje, v isti virtualni strežnik.



26

ESX-1

sinhrona replikacija

Staro diskovno polje

ESX-2 ESX-3

Produkcijski strežniki

PRC DRC

Testni & Razvojni strežniki

Slika 11: Princip delovanja ob normalnih razmerah Strojna oprema: 3-krat ESX strežnik.

Specifikacija strojne opreme za en ESX:

• 4 x Intel Xeon dualcore • 16 GB ECC DDR RAM (razširljivost na 32) • 2 x 73GB SAS HDD • 2 x dual port 10/100/1000 ethernet, quad port ethernet • 2 x FC adapter • 2 x HBA • 2 x dualport NIC • 1 x quadport NIC

Zmogljivost: Novi ESX strežnik omogo�a prenos vseh obstoje�ih strežnikov v virtualno okolje, ter zagotavlja zmogljjivosti in kapacitete za naslednjih tri do pet let glede na predvideno rast banke.



27

Metoda replikacije: Varnostno kopiranje izvajamo na treh nivojih. Pri vseh gre za kopiranje virtualnega strežnika med njegovim delovanjem:

• Agent znotraj virtualnega strežnika (tu ni razlik glede na nevirtualizirano okolje)

• Kopiranje datotek VMDK:

Vklopi se REDO. Originalen VMDK se potem ne spreminja ve� in ga lahko preko omrežja kopiramo. Alternativno lahko kopiramo tudi preko SAN-a, za kar je pogoj TSM na Windows Server 2003 in povezava TSM na SAN. Po kon�anem kopiranju se REDO aplicira (angl. commit) v originalen VMDK.

• Izdelovanje trenutnih posnetkov (angl. snapshot in snapclone).

Strojna oprema izvede kopijo ali posnetek LUN-a, ki ga potem kopiramo na trak in hranimo do naslednje kopije/posnetka.

ESX-1 ESX-2 ESX-3

Produkcijski strežniki

PRC DRC

Testni & Razvojni strežniki

Slika12: Princip delovanja v primeru katastrofe Aktivacijski �as in proces V primeru katastrofe na primarni lokaciji se aktivira ESX strežnik na rezervni lokaciji. Aktivira se diskovno polje na rezervni lokaciji. Preden pa prevzame to



28

vlogo, je potrebno izvesti kontrolo sistema in vseh pomožnih strežnikov. Za vse dodatne aktivnosti je predviden �as dveh ur. Ta �as predstavlja aktivacijski �as po prejetju zahteve kriznega managementa po aktiviranju rezervne lokacije. Preklop nazaj na glavni informacijski sistem V primeru katastrofe je po aktivaciji rezervnega centra potrebna �imprejšnja vzpostavitev prvotnega stanja na primarni lokaciji. Po zagotovitvi vse ustrezne infrastrukture je potrebno podatke na diskovnem polju prekopirati na diskovno polje na primarni lokaciji ter zagotoviti sinhrono replikacijo podatkov. Postopek izgradnje bo potekal postopoma, zato ga razdelimo v ve� faz. Po sami izgradnji pa izvedemo testni zagon. 4.2.3 Inštalacija opreme in testni zagon na rezervni lokaciji Pred samo dobavo opreme je potrebno zagotoviti ustrezno opremljenost prostora v rezervnem centru. V rezervnem centru morajo biti zagotovljeni enaki pogoji kot na primarni lokaciji. Tako kot primarni center mora imeti tudi rezervni center možnost lastnega napajanja, ki ga zagotovimo z ustreznim številom UPS modulov. Prostori morajo biti ustrezno klimatizirani. Mo� izra�unamo na podlagi specifikacije opreme o oddani toploti z upoštevanjem 30% pove�anja. Prav tako mora biti na rezervni lokaciji zagotovljena varnost z ustreznim nadzornim in alarmnim sistemom ali pa s fizi�nim varovanjem. V centru mora biti prav tako ustrezno število gasilnih aparatov polnjenih z dušikom, ki so namenjeni za gašenje elektri�nih naprav. Vzpostavljena mora biti seveda opti�na povezava s primarno lokacijo ter povezava z ostalimi poslovnimi enotami po Sloveniji. Naslednja faza po dobavi je inštalacija opreme. Prenos oziroma inštalacija strežnikov na rezervni lokaciji bo potekala postopoma .

• 1. faza: Najprej se na rezervni lokaciji inštalira mrežna oprema s centralnim stikalom in komunikacijskimi usmerjevalniki, ter stikali za povezavo med glavnim in nadomestnim centrom.

• 2. faza: Sledi inštalacija diskovnega polja, ki bo zagotavljal vse potrebe po

diskovnem polju na rezervni lokaciji. • 3. faza: Naslednja faza je inštalacija AIX strežnika z Informix bazo na

primarni, nato še na rezervni lokaciji.



29

• 4. faza: Postopoma se v virtualno okolje na ESX strežnik prenese vse ostale

ve�inoma Windows strežnike. Po inštalaciji posameznih sklopov se vedno lokalno preveri delovanje le tega. Po kon�ani zadnji fazi se lahko izvede skupni test delovanja informacijskega sistema na rezervni lokaciji kot celote. Za izvedbo samega testa se dolo�i projektno skupino, ki se bo aktivirala tudi primeru dejanske katastrofe. Dolo�i se tudi vodjo projektne skupine. 4.2.4 Razvoj na�rta okrevanja po nesre�ah Za razvoj na�rta je predhodno potrebno izdelati oceno tveganosti informacijskega sistema. Dolo�iti je potrebno vire, ki so nujno potrebni za vsakodnevno poslovanje. Po opravljeni analizi se pripravi na�rt aktivnosti. Klju�ne faze pri razvoju na�rtovanja okrevanja po nesre�ah so:

• ustanovitev projektne skupine, • izdelava analize tveganja, • dolo�itev prioritet za aplikacije in omrežja, • izdelava strategije okrevanja, • izdelava inventarja in dokumentacije na�rta, • dolo�itev overitvenih kriterijev in postopkov, • implementacija na�rta.

Na�rt je potrebno redno posodabljati. Prav tako pa je potrebno redno izobraževati zaposlene. Vsekakor ni izdelava na�rta okrevanja po nesre�ah naloga posameznika. Za izdelavo je potrebno strokovno znanje in sodelovanje zaposlenih na vseh ravneh odlo�anja. V nadaljevanju je predstavljena udeležba oddelka informacijske tehnologije povzeta po Hawkins, Yen, Chou (2000, str. 255)



30

4.2.5 Udeležba in naloge oddelka informacijske tehnologije Ob izpeljavi projekta izgradje rezervnega centra mora oddelek informacijske tehnologije poskrbeti še za spodaj naštete udeležbe in naloge.

• Standardizacija strojne in programske opreme Organizacija, ki ima heterogeno programsko in strojno opremo, potrebuje neprimerno ve� �asa za obnovitev sistema v prvotno stanje. Iz tega razloga je pametno imeti homogeno programsko in strojno opremo.

• Izdelava natan�nega na�rta omrežja

Na�rt za izgradnjo omrežja nam v primeru ve�je katastrofe, ki uni�i del ali celotno stavbo, pomaga, da ponovna izgradnja omrežja traja �im manj �asa.

• Nadziranje dostopa do interneta

Internet nam zagotavlja hiter dostop do informacij po celem svetu, vsekakor pa predstavlja našemu informacijskemu okolju tudi veliko grožnjo. Naloga oddelka informacijske tehnologije je, da vgradi ustrezne varnostne mehanizme, ki zmanjšujejo možnosti vdorov oziroma nekontroliranega pretoka zaupnih podatkov.

• Zagotovitev sistema neprekinjenega napajanja

Prekinitve pri dobavljanju elektri�ne energije so eden glavnih razlogov izgube podatkov. Rešitev je lahko vgraditev UPS sistemov, ki v takem primeru samodejno prevzamejo vlogo.

• Zaš�ita strojne opreme pred škodo iz okolja

Strežniki morajo biti zavarovani pred previsoko napetostjo elektri�nega toka, prav tako pa pred vplivi stati�ne elektrike. Ustrezno morajo biti zaš�iteni tudi pred drugimi nevarnostmi kot so na primer: razlitje vode, požar, fizi�ne poškodbe in podobno.

• Zaš�ita pred virusi

Informacijski sistem je nujno potrebno zaš�ititi z dobrim protivirusnim programom. Po nekaterih raziskavah v povpre�ju nezaš�itena delovna postaja v omrežju neokužena preživi le nekaj minut.

• Zagotovitev podpore vodstva za na�rtovanje okrevanja po nesre�ah

Naloga oddelka informacijske tehnologije je zagotoviti podporo vodstva pri izvajanju procesov. V mnogih podjetjih se vodstvo ne zaveda dejanske vrednosti podatkov.

• Zagotovitev podpore dobaviteljev

Za kriti�ne primere je za nujno opremo potrebno zagotoviti dobavitelja, ki nam jo v najkrajšem možnem �asu lahko zagotovi ne glede na ceno.



31

Ob realizaciji naštetih nalog bo bistveno zmanjšana možnost nastopa katastrofe. V primeru, da do katastrofe dejansko pride, pa bo mogo� hiter povratek v prvotno stanje.



32

5 Kriti�na ocena predlagane rešitve 5.1 SWOT analiza S pomo�jo analize SWOT celovito ocenimo projekt izgradnje nadomestnega informacijskega sistema, analiziramo prednosti in slabosti ter poslovne priložnosti in nevarnosti, ki so prisotne v notranjem in zunanjem okolju organizacije. Rezultat analize daje vpogled v dejavnosti, ki jih je potrebno izboljšati oziroma razviti, da bodo prispevale k boljši poslovni uspešnosti. Tako se lahko poslovna organizacija pripravi na nevarnosti in izkoristi priložnosti, ki jih ponuja trg (Šušterši� in Rajkovi�, 2000). Prednosti

• Skoraj ni�na možnost izgube kriti�nih podatkov, ki jih z izdelovanjem rednih varnostnih kopij ni bilo mogo�e dose�i. Vsi pomembni podatki se sinhrono replicirajo na diskovno polje na rezervni lokaciji.

• V primeru katastrofe ponovna vzpostavitev sistema v zelo kratkem �asu. V

rezervnem centru imamo takoj na razpolago že vso nujno potrebno strojno opremo in vse pomembnejše podatke, prav tako je oblikovana že projektna skupina za take primere, ki zna hitro odreagirati v primeru katastrofe.

• Kvalitetnejša ponudba strankam Banke Sparkasse d.d.. Ni�na oziroma

minimalna možnost izgube strank zaradi nedelovanja informacijskega sistema.

• Nižji stroški poslovanja zaradi uporabe virtualnih strežnikov in zaradi

manjših rezervacij, ki so potrebne po predpisih Banke Slovenije. Glede na to, da se bo ve�ina strežnikov prenesla v virtualno okolje, kar pomeni bistveno manj strojne opreme in s tem manjšo porabo elektri�ne energije.

• Skoraj ni�na možnost propada banke zaradi izgube kriti�nih podatkov.

• Bistveno boljši nadzor in lažje upravljanje sistema. Konsolidacija strežnikov

bo bistveno pripomogla k temu, prav tako pa tudi centralna upravljalna konzola, ki bo na novo vpeljana.

Slabosti

• Visoki stroški investicije zaradi skoraj popolne prenove informacijskega sistema. Stari informacijski sistem se iz cenovnega vidika ne izpla�a nadgrajevati oziroma ne dovoljuje nadgradnje, ki bi si jo želeli.



33

• Visoki stroški vzdrževanja povezav, infrastrukture in opreme na rezervni lokaciji. Sama opti�na povezava do rezervne lokacije predstavlja izjemen strošek za banko. Strojno in programsko opremo je potrebno vzdrževati in nadgrajevati na obeh lokacijah.

• Nova to�ka z možnostjo vdora v informacijski sistem. S postavitvijo in

povezavo do rezervnega centra se hekerjem ponudi nova to�ka za vdor v sistem.

Priložnosti

• Banka lahko ponudi cenovno ugodnejše produkte na trgu zaradi manjših stroškov rezervacij.

Nevarnosti

• Drago vzdrževanje dveh informacijskih centrov.

• Paziti moramo, da se vsi potrebni podatki iz primarnega centra ustrezno replicirajo v rezervni center. Enako pazimo, da oba sistema nadgrajujemo, tako programsko kot tudi strojno opremo.



34

6. Zaklju�ek Za finan�no institucijo kot je Banka Sparkasse d.d. je izgradnja nadomestnega informacijskega sistema nujno potrebna. S tem je narejen velik korak naprej v okviru zagotavljanja neprekinjenega poslovanja banke. Izbrana je bila optimalna rešitev, ki bo zagotovila potrebam banke v prihodnjih letih ter ugodila zahtevam Banke Slovenije. Racionalna rešitev bo omogo�ala uporabo rezervnega informacijskega sistema tudi v obdobju normalnega delovanja primarnega informacijskega sistema. Uporabljal se bo za razli�na testna okolja in razvoj. S tem bo pove�ana njegova vrednost ter uporabnost, kar bo lažje upravi�ilo visoke stroške izgradnje in vzdrževanja. Z diplomsko nalogo so bili postavljeni temelji za izgradnjo rezervne lokacije banke.



35

LITERATURA IN VIRI Knjige:

• Rajkovi�, V.(2000) Informacijski sistem patronažne zdravstvene nege, Založba Moderna organizacija, Kranj.

• Gradišar, M(1998) Informatika v organizaciji, Moderna organizacija, Kranj. • Hawkins Steve, Yen David, Chou David, (2000), Disaster recovery planning:

a strategy for data security. �lanek:

• �lanek v reviji Sistem, (junij 2006), Podatki non stop. Diplome, magisteriji:

• Bizjak, M.(2004) Izgradnja nadomestnega informacijskega sistema v primeru obvladovanja katastrofe, diplomsko delo, Univerza v Mariboru, Fakulteta za organizacijske vede.

• Zor�, G. (2004) Okrevanje informacijskih sistemov po nesre�ah, magistrsko delo.

• Gril, M. (2003) Varnost in tehnološka zaš�ita informacijskega sistema v banki, Univerza v Ljubljani, Ekonomska fakulteta.

Poro�ila, interni dokumenti:

• Microsoft, Moškon, A. (marec 2006), Svetovanje pri na�rtovanju neprekinjenega poslovanja in vzpostavljanju rezervnih zmogljivosti.

• ZBS, (2005) Metodologija na�rtovanja neprekinjenega poslovanja in vzpostavitev rezervnih zmogljivosti verzija 1.1.

• Nicolett, M., Luevano F., The 'How to's' of Disater Recovery Planning, Gartner GroupSymposium/Itxpo.

Spletne strani:

• Michigan State Uneversity, Disaster recovery planning, http://www.drp.msu.edu.

• McData, IT infrastructure of business continuity planning, http://www.mcdata.com/downloads/mkt/wpaper/wp_it_infrastructure_of_business_continuity_779.pdf#xml=http://search.mcdata.com/texis/Webinator/search/pdfhi.txt?query=business+continuity+planning&pr=www-en&prox=page&rorder=500&rprox=500&rdfreq=500&rwfreq=500&rlead=500&sufs=0&order=r&cq=&id=44d7a6c18.

• Hawlett Packard, business continuity services – A brief http://h50043.www5.hp.com/hpservices/whitepapers/BCP_brief.pdf.

• Banka Sparkasse d.d., Banka Sparkasse v Sloveniji http://www.sparkasse.si • Von Magazine, Disaster recovery and business continuity,

http://www.vonmag.com/index.asp.



36

PRILOGE Priloga 1: Obstoje�a strežniška struktura KAZALO SLIK Slika 1: Zaporedni koraki zagotavljanja BCP (vir Gartner, 2002). Slika 2: Povezava na Informix bazo. Slika 3,4: Strežniki ter diskovno polje (FastT). Slika 5: Komunikacijska infrastruktura. Slika 6: Princip izdelave varnostnih kopij. Slika 7: Najpogostejši vzroki za izpad (vir:McData, www.McData.com). Slika 8: Dolo�itev stroškov (vir: Von Magazine, Disaster recovery and business continuity, Oktober 2006). Slika 9: Prenovljena komunikacijska infrastruktura. Slika 10: Princip delovanja AIX strežnikov. Slika 11: Princip delovanja ob normalnih razmerah. Slika 12: Princip delovanja v primeru katastrofe. POJMOVNIK

• FastT: IBM- ovo diskovno polje. • Neverfail Heartbeat: na�in povezave dveh strežnikov. • Standby: baza: pomožna, nadomestna baza. • Legatto: tip povezave strežnikov v gru�o.

KRATICE IN AKRONIMI

• TSM: IBM knjižnica, za izdelavo varnostnih kopij podatkov. • LTO: Linear Tape-Open; magnetni trak za shranjevanje podatkov. • NLB: Network Load Balancing, Microsoftova metoda povezovanja

strežnikov v gru�o. • SQL: Standard query language: standardni poizvedbeni jezik. • ESX: VMware-ov strežnik, primeren za gostovanje virtualnih strežnikov. • SAN: storage area network. • HBA: Host Bus Adapter; adapter, ki omogo�a preklop med kanaloma pri

opti�ni povezavi. • NIC: network interface controller, mrežna kartica za povezavo v LAN. • MOM: Microsoft Operations Manager; Microsoftov produkt za nadzor nad

sistemi. • HaCMP: High Availability Cluster Multiprocessing; BM-jeva programska

oprema za postavitev visoko zmogljivih in zanesljivih strežniških gru�. • FR: Frame Relay:tehnologija za prenos podatkov do hitrosti 2 Mbit/s. • Lun: Logical unit number; navidezna logi�na enota.

Documents

Diplomsko delo visokošolskega strokovnega študija Smer