Informačná bezpečnosť

Informačná bezpečnosť: Geograficky distribuovaná ochrana dát

Ako mi­ni­ma­li­zo­vať vý­pa­dok IT slu­žieb a stra­tu dát v dôs­led­ku ne­priaz­ni­vých uda­los­tí. 

Za­tiaľ čo v pre­doš­lej de­ká­de sta­či­lo chrá­niť pred vý­pad­kom niek­to­ré kri­tic­ké ap­li­ká­cie, s prí­cho­dom vir­tua­li­zá­cie sa veľ­ké množ­stvo slu­žieb, aj tých me­nej vý­znam­ných z poh­ľa­du kon­ti­nui­ty pod­ni­ka­nia, pre­su­nu­lo na ma­lý po­čet fy­zic­kých za­ria­de­ní. Vý­pa­dok ta­ké­ho­to za­ria­de­nia sa mô­že v ko­neč­nom dôs­led­ku rov­nať vý­pad­ku niek­to­ré­ho kri­tic­ké­ho kom­po­nen­tu IT infra­štruk­tú­ry. To eš­te viac pris­pie­va k pot­re­be za­bez­pe­če­nia IT sys­té­mov a dát, kto­ré dnes ne­zried­ka pred­sta­vu­jú naj­hod­not­nej­šiu ko­mo­di­tu fir­my.

MetroCluster_demo_pic.jpg

Ilus­tra­tív­ny sche­ma­tic­ký nák­res vý­pad­ku ce­lé­ho dá­to­vé­ho cen­tra pri geog­ra­fic­ky dis­tri­buo­va­nom rie­še­ní

Zá­klad­ný me­chan­izmus umož­ňu­jú­ci pred­chá­dzať vý­pad­ku služ­by/ap­li­ká­cie je re­dun­dan­cia kom­po­nen­tov sys­té­mu (HA), spo­je­ná so schop­nos­ťou pres­me­ro­va­nia zá­ťa­že na ak­tuál­ne dos­tup­ný kom­po­nent. Ak je však ta­ký­to sys­tém umies­tne­ný v jed­nej lo­ka­li­te, ne­do­ká­že za­brá­niť vý­pad­kom v dôs­led­ku uda­los­tí pos­ti­hu­jú­cich ce­lú lo­ka­li­tu (napr. vý­pa­dok elek­tric­ké­ho na­pá­ja­nia, sie­ťo­vé­ho spo­je­nia, po­žiar, lo­kál­na prí­rod­ná poh­ro­ma a pod.). Pre­to mno­hé fir­my a in­šti­tú­cie vy­uží­va­jú roz­de­le­nie svo­jej IT infra­štruk­tú­ry, a to naj­čas­tej­šie me­dzi dve geog­ra­fic­ky vzdia­le­né lo­ka­li­ty.

Mô­že ísť o dve rôz­ne dá­to­vé cen­trá v tom is­tom mes­te ale­bo aj o lo­ka­li­ty vzdia­le­né nie­koľ­ko sto­viek ki­lo­met­rov. Dô­le­ži­té je po­cho­piť, že ani ta­ká­to re­dun­dan­cia nie je úpl­ne „dis­as­ter to­le­rant" rie­še­nie. Ak nap­rík­lad dôj­de k poš­ko­de­niu da­ta­bá­zy v dôs­led­ku ľud­ské­ho po­chy­be­nia, zá­lož­ná kó­pia tých is­tých dát v inej lo­ka­li­te prob­lém ne­vy­rie­ši. Pre­to aj pri rie­še­niach HA tre­ba pa­mä­tať na vhod­ný spô­sob ob­no­vy sys­té­mu/dát po ka­tas­tro­fe (DR). Geog­ra­fic­ky dis­tri­buo­va­né rie­še­nie však mô­že vý­znam­ne pris­pieť k mi­ni­ma­li­zá­cii vý­pad­kov slu­žieb v prí­pa­de ne­fun­kčnos­ti jed­nej lo­ka­li­ty.

A to v prí­pa­de, že kaž­dá lo­ka­li­ta pok­rý­va časť bež­iacich slu­žieb (kon­fi­gu­rá­cia ac­ti­ve-ac­ti­ve), na roz­diel od pa­sív­ne­ho zá­lož­né­ho rie­še­nia (ac­ti­ve-pas­si­ve), kto­ré pre­be­rá fun­kciu až v prí­pa­de vý­pad­ku. Geog­ra­fic­ky dis­tri­buo­va­né rie­še­nie (klas­ter) mô­že­me te­da chá­pať aj ako me­chan­izmus ob­me­dzenia ri­zi­ka ka­tas­tro­fy.

Úsi­lie o zni­žo­va­nie RPO (prí­pus­tná stra­ta pos­led­ne mo­di­fi­ko­va­ných dát) na tak­mer nu­lo­vú hod­no­tu (prak­tic­ky to zna­me­ná napr. mi­nú­ty ver­zus ho­di­ny až dni) ve­die k nut­nos­ti syn­chrón­nej rep­li­ká­cie dát me­dzi dvo­ma lo­ka­li­ta­mi a pou­ži­tiu auto­ma­ti­zo­va­né­ho sof­tvé­ro­vé­ho rie­še­nia. To mož­no do­siah­nuť buď na úrov­ni ap­li­ká­cie, ale­bo pria­mo na úrov­ni dis­ko­vé­ho po­ľa pou­ži­tím klas­tro­vé­ho di­zaj­nu. Dru­hý uve­de­ný spô­sob pri­ná­ša tú vý­ho­du, že je auto­ma­tic­ky ap­li­ko­va­ný na všet­ky server­y a ap­li­ká­cie, čo ho ro­bí oby­čaj­ne aj fi­nan­čne vý­hod­nej­ším.

Z poh­ľa­du vzdia­le­nos­ti roz­li­šu­je­me geog­ra­fic­ké ale­bo tzv. met­rok­las­tre dis­ko­vých po­lí na ma­lú vzdia­le­nosť (v sú­čas­nos­ti do 500 m), kto­ré sa ozna­ču­jú aj ter­mí­nom stret­ched (roz­tiah­nu­tý) a sú v zá­sa­de li­mi­to­va­né do­sa­hom op­tic­kej ka­be­lá­že bez pou­ži­tia pre­pí­na­čov FC, a fab­ric (zo­sie­ťo­va­né) met­rok­las­tre na veľ­kú vzdia­le­nosť de­sia­tok až sto­viek ki­lo­met­rov. Roz­tiah­nu­té met­rok­las­tre pou­ží­va­jú na spo­je­nie dis­ko­vých ra­di­čov s dis­ko­vý­mi po­li­ca­mi op­tic­kú ka­be­láž. Mô­že ísť o pri­po­je­nie FC ale­bo op­tic­kú ka­be­láž SAS, prí­pad­ne o kom­bi­ná­ciu pri­po­je­nia FC a SAS s vhod­ným kon­ver­to­rom ko­mu­ni­ká­cie.

V tom­to prí­pa­de je dô­le­ži­tá dos­tup­nosť dos­ta­toč­né­ho poč­tu op­tic­kých vlá­kien me­dzi lo­ka­li­ta­mi a níz­ka la­ten­cia (po­žia­dav­ky ko­lí­šu pod­ľa kon­krét­ne­ho rie­še­nia). Vý­ho­dou ta­kých­to klas­trov bý­va čas­to mož­nosť sú­čas­né­ho prís­tu­pu klient­skych server­ov z obid­voch lo­ka­lít k obid­vom po­liam, resp. ra­di­čom.

To zjed­no­du­šu­je pro­ces prek­lo­pe­nia pre­vádz­ky me­dzi lo­ka­li­ta­mi v prí­pa­de po­ru­chy niek­to­rej čas­ti sys­té­mu a dá­va pries­tor na auto­ma­ti­zá­ciu, čo v ko­neč­nom dôs­led­ku zna­me­ná mi­ni­ma­li­zá­ciu vý­pad­ku slu­žieb. Na dru­hej stra­ne zo­sie­ťo­va­né met­rok­las­tre vy­uží­va­jú op­tic­kú sieť ria­de­nú pre­pí­nač­mi, čo zni­žu­je ná­ro­ky na po­čet spo­je­ní a vý­znam­ne predl­žu­je vzdia­le­nosť me­dzi lo­ka­li­ta­mi. Ne­vý­hod­né mô­že byť ne­dos­ta­toč­né pre­po­je­nie na stra­ne prís­tu­pu server­ov k dis­ko­vým po­liam, čo ve­die k nut­nos­ti naš­tar­to­va­nia slu­žieb z dru­hej lo­ka­li­ty v prí­pa­de vý­pad­ku. Ta­ké­to rie­še­nie sa skôr vní­ma ako DR, ho­ci v sku­toč­nos­ti ide o „dis­as­ter avoi­dan­ce" (pred­chá­dzanie ka­tas­tro­fic­kej stra­te slu­žieb).

Az­da naj­dô­le­ži­tej­šia vlas­tnosť geog­ra­fic­ky dis­tri­buo­va­né­ho klas­tro­vé­ho rie­še­nia je je­ho schop­nosť od­olá­vať vý­pad­kom rôz­nych kom­po­nen­tov a pre­po­je­ní. Dis­ko­vé po­lia to ma­jú zvy­čaj­ne vy­rie­še­né s vy­so­kým stup­ňom auto­ma­ti­zá­cie, te­da pre­ne­se­nie ob­slu­hy klient­skych server­ov z jed­nej lo­ka­li­ty do dru­hej pre­bie­ha v krát­kom ča­se a bez nut­nos­ti zá­sa­hu ad­mi­nis­trá­to­ra. Otáz­kou však zos­tá­va, ako je vy­rie­še­ný pro­ces prek­lo­pe­nia pre­vádz­ky na stra­ne server­ov a slu­žieb.

Vo vir­tua­li­zo­va­nom pros­tre­dí ob­vyk­le nie je prob­lém naš­tar­to­vať vir­tuál­ne server­y v dru­hej lo­ka­li­te. Mu­sia však byť správ­ne nas­ta­ve­né ich „af­fi­ni­ty ru­les" t. j. pra­vid­lá na pris­tu­po­va­nie k dá­tam, aby sa nes­ta­lo, že server je sí­ce naš­tar­to­va­ný v al­ter­na­tív­nej lo­ka­li­te, ale k dá­tam sa po­kú­ša pris­tu­po­vať z pô­vod­nej lo­ka­li­ty, kto­rá má vý­pa­dok. Na ap­li­kač­nej úrov­ni oby­čaj­ne via­ce­ro server­ov spo­lu sú­vi­sí a ich štar­to­va­nie/vy­pí­na­nie tre­ba uro­biť v ur­či­tom po­ra­dí. Ta­kis­to nes­mie­me za­bú­dať na dôk­lad­né navr­hnu­tie sie­ťo­vých pre­po­je­ní aj s oh­ľa­dom na prek­lo­pe­nie pre­vádz­ky (dos­tup­nosť VLAN, prek­lo­pe­nie IP adries, zó­no­va­nie por­tov FC a pod.).

Na zá­ver tre­ba spo­me­núť eš­te je­den špe­ci­fic­ký prí­pad vý­pad­ku pri klas­tro­vých rie­še­niach, kto­rý sa ozna­ču­je ter­mí­nom split brain (roz­štie­pe­nie iden­ti­ty). Ide o úpl­ný vý­pa­dok spo­je­nia me­dzi lo­ka­li­ta­mi, resp. en­ti­ta­mi klas­tra, kto­ré sí­ce zo svoj­ho poh­ľa­du fun­gu­jú nor­mál­ne, ale ne­do­ká­žu ur­čiť stav par­tner­ských en­tít v klas­tri ani syn­chro­ni­zo­vať dá­ta s ni­mi. Ta­ká­to si­tuácia mô­že vznik­núť veľ­mi jed­no­du­cho - napr. pri neú­my­sel­nom pre­ťa­tí ka­be­lá­že pri vý­ko­po­vých prá­cach v uli­ciach.

V tom­to prí­pa­de ne­mô­že prek­lo­pe­nie pre­vádz­ky z jed­nej lo­ka­li­ty do dru­hej pre­beh­núť auto­ma­tic­ky, je pot­reb­ný zá­sah ad­mi­nis­trá­to­ra. Ur­či­té rie­še­nie umož­ňu­jú­ce auto­ma­ti­zá­ciu aj toh­to sce­ná­ra je vy­tvo­re­nie tre­tej ne­zá­vis­lej lo­ka­li­ty, kto­rá má spo­je­nie so všet­ký­mi en­ti­ta­mi klas­tra a do­ká­že roz­hod­núť da­nú si­tuáciu. Ta­ké­to za­ria­de­nie sa ozna­ču­je ako quorum za­ria­de­nie ale­bo aj sve­dok (wit­ness).

Na­priek sú­čas­ným pok­ro­či­lým mož­nos­tiam za­bez­pe­če­nia kon­ti­nui­ty IT slu­žieb net­re­ba za­bú­dať, že je­di­ná zá­ru­ka spo­koj­né­ho spán­ku v reál­nych si­tuáciách je dôk­lad­né otes­to­va­nie vý­pad­ku kom­po­nen­tov HA rie­še­nia ich ne­kom­pro­mis­ným vy­ra­de­ním z pre­vádz­ky.

Sta­nis­lav Stra­šík, Sys­tems En­gi­neer, ALEF Dis­tri­bu­tion SK, s. r. o.,
e-mail: sk-sup­port@alef­nu­la.com

Zdroj: IW 5-6/2014


Ohodnoťte článok:
   
 

24 hodín

týždeň

mesiac

Najnovšie články

In­for­mač­ná bez­peč­nosť: Geog­ra­fic­ky dis­tri­buo­va­ná ochra­na dát
Ako minimalizovať výpadok IT služieb a stratu dát v dôsledku nepriaznivých udalostí. Zatiaľ čo v predošlej dekáde stačilo chrániť pred výpadkom niektoré aplikácie.  čítať »
 
Pla­te­ná rek­la­ma vs. op­ti­ma­li­zá­cia SEO – vý­ho­dy, ne­ga­tí­va, mož­nos­ti
Špecialisti na SEO tvrdia, že správnou optimalizáciou webu máte šancu získať oveľa viac ako platenou reklamou. Naproti tomu experti na platenú reklamu argumentujú dosahovaním rýchlych a merateľných výsledkov. čítať »
 
Ar­chi­tekt vs Pro­jek­to­vý ma­na­žér - spo­jen­ci, či ne­pria­te­lia?
Tieto roly existujú v každom väčšom projekte, ale napriek tomu ich spolupráca často neprebieha tak hladko ako by sa očakávalo. Je dôvod v samotných rolách, alebo leží úplne inde? čítať »
 
Ap­pli­ca­tion De­li­ve­ry – efek­tív­na ochra­na pro­ti hac­ke­rom a op­ti­ma­li­zá­cia vý­ko­nu slu­žieb
Sú vaše webové služby chránené proti hackerom? Programátori často urobia chyby, ktoré dokážu útočníci zneužiť.   čítať »
 
Cloud com­pu­ting: Oča­ká­va­nia a reali­ta, preh­ľad pos­ky­to­va­te­ľov (Ama­zon, Goog­le, IBM, Mic­ro­soft)
Cloud computing, technológia predstavujúca model zdieľania hardvérových zdrojov pomocou virtualizácie a automatizácie, v súčasnosti naberá rýchlosť pri globálnom rozširovaní sa do celého spektra sektorov poskytujúcich obrovské množstvo služieb. čítať »
 
Dá­ta nie sú len ved­ľaj­ším pro­duk­tom pre­vádz­ky IS
Na otázku, ako stručne hodnotíte informačný systém vašej organizácie, by sme dostali mnoho rôznych odpovedí. čítať »
 
BYOD pod­po­ru­je ino­vač­né ini­cia­tí­vy ta­len­to­va­ných za­mes­tnan­cov
Jeden z charakteristických atribútov trendu BYOD je možnosť vynútenia technologického pokroku v IT podpore biznisu „zdola", najčastejšie zo strany mladších používateľov. čítať »
 
Li­cen­čnú čis­to­tu je ťaž­ké us­trá­žiť
Pre licenčného manažéra je znalosť aktuálnych licenčných podmienok od dvoch až troch výrobcov softvéru na všetok využívaný softvér v spoločnosti nedosiahnuteľná méta. čítať »
 
 
 
  Zdieľaj cez Facebook Zdieľaj cez Google+ Zdieľaj cez Twitter Zdieľaj cez LinkedIn Správy z RSS Správy na smartfóne Správy cez newsletter