Ukládání dat se zaměřením na jejich dostupnost

Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování

Ukládání dat se zaměřením na jejich dostupnost

Diplomová práce

Autor:

David Kolenatý Informační technologie a management

Vedoucí práce:

Praha

Ing. Vladimír Beneš

Duben, 2009

Prohlášení:

Prohlašuji, že jsem diplomovou práci zpracoval samostatně a s použitím uvedené literatury.

podpis autora V Praze dne 12.4.2009

David Kolenatý

Anotace práce:

Cílem této práce je popis technologií ukládání dat z pohledu zajištění jejich dostupnosti pro podnik se zaměřením na speciální funkce diskových polí, páskových zařízení a datové infrastruktury jako je vyváření klonů dat, jejich zrcadlení nebo kryptace. Hlavní část je věnovaná způsobu výběru, implementaci a následnému zhodnocení projektů Business Continuity s lokálním či transkontinentálním nasazením. Druhou oblastí, které je v mé práci věnována pozornost, jsou zkušenosti s nasazováním projektů Information Lifecycle Management, a to především z pohledu dlouhodobého uchovávání dat. K dosažení celkového pohledu na optimální ukládání dat je poukázáno na uplatnění virtualizace diskových a páskových systémů v praxi. V poslední kapitole o strategii a vývoji je nástin nejnovější technologie pro efektivní zálohování dat, kterou je deduplikace.

The goal of this document is description of data storage technology in point of view assuring their continuity for enterprise in focus on special functions of disk subsystems, tapes and storage infrastructure like creating snapshots, date mirroring and encryption. Main part is deliberative to choosing methodology, implementation and following evaluation Business Continuity projects in local or trnascontinental environment. Next scope is aim at experience with implementation of Information Lifecycle Management projects, mainly in data retention point of view. To reach complete picture of optimalization data storing is refer to use disk and tape virtualization in practice. In last chapter about strategy and development is short sketch of new deduplication technology for effective backup.

Obsah 1

ÚVOD

6

2

KRITICKÁ DOSTUPNOST DAT PRO DNEŠNÍ PODNIK

7

3

NOVÉ TECHNOLOGIE PRO ZVÝŠENÍ DOSTUPNOSTI DAT 3.1

Lokální Storage Area Network

11

3.1.2

Zálohování lokalit

12 13

Vytváření lokálních kopií

13

3.2.2

Vzdálené zrcadlení dat

15

KRYPTOVÁNÍ DAT

KONCEPT BUSINESS CONTINUITY Z POHLEDU STORAGE

18 20

4.1

METODOLOGIE VÝBĚRU ŘEŠENÍ

22

4.2

REALIZACE ŘEŠENÍ BUSINESS CONTINUITY

27

4.2.1

Řešení pro státní správu

28

4.2.2

Business Continuity přes oceán

45

4.3

ZHODNOCENÍ VÝSLEDKŮ A NÁVRHY NA ZLEPŠENÍ

KONCEPT INFORMATION LIFECYCLE MANAGEMENT

47 48

5.1

METODOLOGIE VÝBĚRU ŘEŠENÍ

50

5.2

REALIZACE ŘEŠENÍ INFORMATION LIFECYCLE MANAGEMENT

53

5.2.1

Retence dat v automobilovém průmyslu

53

5.2.2

Zpracování digitalizovaných dat

55

5.2.3

Tierovaná storage v bance

59

5.2.4

Alternativní technologie pro levné uchovávání dat

60

5.3 6

POKROČILÉ FUNKCE PRO ZABEZPEČENÍ DOSTUPNOSTI DAT

3.2.1

3.3

5

11

3.1.1

3.2

4

LOKÁLNÍ ZABEZPEČENÍ DAT NA ZAŘÍZENÍCH PRO UKLÁDÁNÍ DAT

10

ZHODNOCENÍ VÝSLEDKŮ A NÁVRHY ZLEPŠENÍ

VYUŽITÍ VIRTUALIZACE PRO EFEKTIVNĚJŠÍ DOSTUPNOST DAT

61 62

6.1

VIRTUALIZACE DISKŮ

62

6.2

VIRTUALIZACE PÁSEK

64

7

STRATEGIE A VÝVOJ

67

8

ZÁVĚR

69

9

SEZNAM POUŽITÉ LITERATURY 9.1

KNIHY

70 70

10

SEZNAM OBRÁZKŮ

71

11

SEZNAM TABULEK

73

1 Úvod Pro svou diplomovou práci jsem si zvolil téma ukládání dat se zaměřením na jejich dostupnost především proto, že tato oblast je dnes strategickým trendem při zacházení s daty v podnikové sféře. Kritičnost podnikových dat je čím dál větší a firmy si uvědomují finanční dopad nedostupnosti nebo dokonce ztráty svých cenných informací. Na začátku své práce chci představit technologie, které se používají jednak pro lokální ochranu dat na zařízeních typu storage1 a jednak s pokročilými funkcemi sloužícími pro zabezpečení vysoké dostupnosti dat. Funkce, kterým se hromadně říká kopírovací, umožňují urychlení zálohovacích procesů, zrcadlení diskových subsystémů na lokální a vzdálenou záložní lokalitu s různou úrovní zachování dat při pádu výpočetního střediska. Samostatná kapitola je věnována novým možnostem kryptování dat na různých datových médiích. Hlavní část práce obsahuje zkušenosti z implementace dvou důležitých konceptů, které zvyšují dostupnost a efektivnost zacházení s daty a těmi jsou Business Continuity a Information Lifecycle Management. Každá kapitola má za cíl seznámit s principy těchto konceptů, výběrem vhodné metodologie nasazení, reálným nasazením v prostředí českých a zahraničních firem a v závěru také zhodnocení zkušeností. V části věnované dlouhodobému uchovávání dat se musím zmínit i o oblasti ukládání zákonem stanovených dat, která jsou u nás firmy čím dál více nuceni uchovávat pro případ následné kontroly. Mezi tato data patří například účetní doklady, finanční výkazy a analýzy, a různé druhy smluv. Součástí mé práce je také pojednání o virtualizaci dat a zkušeností z implementace tohoto moderního konceptu především pro oblast zálohování dat na virtualizační páskové knihovny. Na závěr, v kapitole o strategii a vývoji je nástin nejnovější technologie pro efektivní zálohování dat, kterou je deduplikace.

1

Zařízení pro ukládání dat 6

2 Kritická dostupnost dat pro dnešní podnik V současné době si čím dál více firem uvědomuje, že ztráta jejich firemních dat pro ně má obrovskou nenahraditelnou hodnotu a proto investice do storage a serverových technologií a zabezpečení exponenciálně roste. Již i v České republice, významné společnosti z oblasti bankovnictví, telekomunikací či průmyslu jsou schopni přesně definovat finanční ztrátu v případě výpadku IT či nedostupnosti k datům až na úroveň jednotek minut. Na rozdíl od minulých let, kdy bylo oddělení IT chápáno jen jako nákladová položka firemního rozpočtu jeho úloha pro dnešní podnik má daleko větší význam neboť umožňuje nejen zpracování informací, ale jeho stěžejním úkolem, je poskytnou rychle a kvalitně připravená data pro operativní a manažerské rozhodování. Z těchto důvodů je proto kladen velký důraz i na kvalitní a bezpečnou infrastrukturu včetně zařízení pro ukládání dat. Tím hlavním konceptem pro zachování co možná nejvyšší dostupnosti je Business Continuity2 , který definuje jak nasadit infrastrukturu a jaká pravidla dodržovat. Někdy se přirovnává Business Continuity k dobrému pojištění, protože stojí dost peněz a když ho máte tak ho většinou nepotřebujete a přijde Vám to jako zbytečně vynaložené prostředky. A když ho nemáte, tak se stane „malér“ a v tu chvíli by jste dali cokoli za to, aby se to nestalo nebo aby jste pojištění měli. Ze zkušenosti z České republiky je vidět, že většina velkých společnosti si již uvědomila, že to nejcennější co mají jsou data a podle toho s nimi zacházejí. Tlak na maximální dostupnost dat je především ze strany obchodních jednotek, které se snaží zajistit co možná nejdelší přístup zákazníkům ke svým produktů a službám, a tak většina společností jako jsou banky, pojišťovny, telekomunikace, státní organizace poskytující služby pro občany a firmy či retailové firmy přechází nevyhnutelně na režim 7x24, tedy kontinuální nepřerušený provoz. Problémem se pak nestává jen stálá dostupnost dat, ale i potřeba najít čas pro vytvoření zálohy dat a přitom neomezit přístup k primárním datům. Pro dokreslení Business Continuity řešení je potřeba si uvést dva základní pojmy, kterými se výběr takového řešení musí řídit:

2

Business Continuty (BC) – kontinuita obchodních procesů 7

RPO - Recovery Point Objective – Maximální možný objem ztracených dat (v minutách). Nulová hodnota znamená, že při výpadku nedojde ke ztrátě dat. RTO - Recovery Time Objective – Maximální čas potřebný k obnovení plného provozu směrem k uživateli.

Škálování bez nutnosti odstávky V posledních deseti letech se u firem projevuje obrovská potřeba diskových prostor pro ukládání dat. Hlavní podíl na tom má především implementace aplikací jako jsou e-business, e-mail, business intelligence a data warehouse. Někteří analytici, jako IDC a Gartner Group, odhadují, že elektronicky uložená data se každý rok násobně zvětšují. V případě aplikací e-business a otevření obchodování prostřednictvím internetu se jedná dokonce o desetinásobný meziroční růst. Zatímco připojování diskové kapacity přímo k serverům je velmi omezeno, tak SAN3 umožňuje přidávat kapacitu v podstatě neomezeně dle potřeb a bez odstávky provozu. SAN umožňuje růst kapacity nezávisle na připojených serverech a tím přispívá k lepší dostupnosti dat.

Dlouhodobé uchovávání I když zde mluvíme převážně o produkčních datech jako o kritických, tak i data, která jsou stará i několik let a tím myslím data o smlouvách či účetnictví je nutné uchovat tak aby byla neustále dostupná i když je zde požadavek na rychlost přístupu výrazně jiný než u dat produkčních. Z této situace vyplývá jedna nezodpovězená otázka: Jak uchovávat dlouhodobě data, abych je za mnoho let až je budu potřebovat přečetl? Správná odpověď dnes v podstatě neexistuje. Existuje mnoho názorů jak a na čem data uchovat, ale jedná se jen o spekulace. Když si vezmeme to nejideálnější médium pro dlouhodobé uchování dat, kterým je páska chráněná proti přepisu, protože má výrazně lepší parametry a je připravena uchovat data po dobu desítek let, tak se nám objeví problém jak pásku za dvacet let přečteme. Vývoj jde dnes velmi rychle dopředu a technologie, která přijde na trh za pět až šest let již nebude schopna číst média zapsaná dnešní technologií. A tak jednou z rad, kterými se dnes firmy řídí, je data z médií po

3

Storage Area Network (SAN) – síťová architektura pro disková a pásková zařízení 8

určité době přemigrovat na jiné, technologicky novější, médium. V případě disků se jedná o jednodušší řešení než je tomu u pásek.

9

3 Nové technologie pro zvýšení dostupnosti dat V této kapitole bych rád rozvedl základní stavební prvky sloužící pro maximální dostupnost dat na úrovni zařízení pro ukládání dat a zároveň se zmínil o uplatnění těchto komponent v reálném nasazení u zákazníků.

Fibre Channel4 přes Ethernet5 Jednou ze zajímavých technologií pro přenos dat, především pak mezi dvěma středisky patří přenos přes standardní LAN6 síť. V současné době to jsou dva koncepty a to Fibre Channel přes IP a Fibre Channel přes Ethernet, který je novějším a v dnešní době ho prosazuje především firma Cisco na svých zařízeních Nexus. Výhodou těchto technologií pro implementaci Business Continuity je především úspora investic, protože využití stávajících Ethernetových linek je Obrázek 1 – switch Nexus

méně

nákladné

než

postavit

nebo

si

pronajmout linku pro Fibre Channel nebo temné vlákno (Dark Fibre). Rozdíle těchto technologií je především v způsobu přenosu dat. Zatímco Fibre Channel přes IP7 funguje tím způsobem, že standardní protokol SCSI pro Fibre Channel se zabalí do formátu IP a pak se pošle do sítě, která je ale ztrátová, takže v případě ztráty paketu se Fibre Channel

operace

musí

opakovat.

Tak

Zdroj: CISCO

v případě nové technologie se Fibre Channel přes Ethernet, která používá svůj vlastní protokol, který protlačí pakety Fibre Channel přímo 10 Gb Ethernetem, se toto stát nemůže neboť se jedná o technologii bezztrátovou. Navíc výhodou je, že firma může používat pouze jedno spojení mezi serverem a Storage Area Network, neboť v jednom kabelu může procházet jak provoz Fibre Channel, tak paralelně i Ethernet.

4

Fibre Channel – optické vlákno užívané pro propojení serverů, pracovních stanic a zařízení pro ukládání dat 5 Ethernet - je jeden z typů lokálních sítí, který realizuje vrstvu síťového rozhraní 6 Local Area Network – lokální síť pro komunikaci prostřednictvím infrastruktury 7 IP - datový protokol používaný pro přenos dat přes paketové sítě 10

3.1 Lokální zabezpečení dat na zařízeních pro ukládání dat Hlavním prvkem pro bezpečnost dat na úrovni diskových polí je využití technologie nazývané RAID8 (Redundant Array of Independent Disks). Pro vyjasnění terminologie byly definovány tzv. úrovně RAID. Některé se s vývojem techniky již přestaly používat. V současné době jsou nejpoužívanější úrovně RAID 0, 1, 5 a 10. Co se týče praxe, tak ochrana dat RAID 10, která je kombinací RAID 0 (stripe) a RAID 1 (zrcadlo), jedná se vlastně o zrcadlený stripe, se používá především u nejkritičtějších dat, kde chce zákazník maximální bezpečnost svých dat a je ochoten za to zaplatí vyšší cenu. RAID 5 je pak alternativou pro naprostou většinu zákazníků a aplikací. V poslední době se začínají používat také pole typu RAID 6, které se zdají být nejoptimálnějším řešením, protože je to určitý kompromis mezi výkonností ukládání a obnovy dat a cenou, kterou zákazníci zaplatí za počet disků. Pole RAID 6 je odolné proti výpadku až dvou disků. Důležitá je i skutečnost, že při obrovských kapacitách dnešních disků, u Fibre Channel až 450 GB a u SATA až 1 TB, trvá rekonstrukce pole při výpadku disku dosti dlouho, a po dobu rekonstrukce již pole není chráněno proti výpadku dalšího disku. Dalšími požadavky na zabezpečení dat na úrovni a to nejen diskových polí je, že pokud možno všechny komponenty musí být zdvojeny a zároveň vyměnitelné za chodu, aby se docílilo při výpadku i té nejposlednější komponenty nulové odstávky a aby aplikace pokud možno vůbec nepoznala že došlo k nějaké chybě na úrovni storage infrastruktury. Samozřejmostí je také co nejrychlejší oprava nebo náhrada chybné komponenty a proto v zařízeních, která jsou určena do prostředí produkce a mají být základem pro Business Continuity koncept mají implementovánu funkcionalitu „Call Home“, která má za úkol při jakékoliv chybě zařízení kontaktovat výrobce a upozornit právě na nastalou skutečnost. Dodavatel by měl co nejrychleji reagovat v závislosti na dohodnutých smluvních podmínkách a zařízení opravit a uvést ho do plně redundantního modu.

3.1.1 Lokální Storage Area Network Pokud se posuneme o krok výše a to k přenosové síti určené pro storage data, tak zde je cílem opět využít redundantní komponenty, a dále pak vytvoření konceptu duálního

8

Redundant array of inexpensive drives (disks) – redundantní pole levných disků 11

propojení mezi servery a zařízeními pro ukládání dat. Pro nastavení komunikace se pak využívají Multi-path Subsystem Device ovladače, které jednak provádějí vyrovnání zátěže pro duální cesty a optimalizují tak rychlost přenosu dat, tak také zajišťují v případě výpadku jedné z datových cest, automatické přesunutí komunikace na alternativní cestu. Mezi nové technologie v oblasti Storage Are Network pro zabezpečení dostupnosti dat nasazení virtuálních SAN tzv. VSAN, které má ve svém portfoliu firma Cisco. Tato technologie umožňuje rozdělení Fibre Channel directoru na několik virtuálních části, které jsou od sebe logicky odděleny a poskytují v případě výpadku jednoho VSAN možnost bezodstávkově používat ostatní části directoru. U ostatních produktů pro SAN toto možné není a v případě výpadku nebo instalace nových verzí microcode je potřeba zařízení vypnout a tím i ohrozit dostupnost dat.

3.1.2 Zálohování lokalit Nedílnou součástí zabezpečení dostupnosti dat v případě výpadku primárního úložiště je samozřejmě optimální způsob zálohování dat pomocí operačního systému nebo zálohovacím software. Z pohledu hardware je pak potřeba si uvědomit jak velký časový prostor má zákazník pro vytvoření zálohy a ještě větší důraz je kladen na rychlost obnovy dat. Zároveň je potřeba zvážit kolik finančních prostředků je společnost schopna a ochotna do takového řešení investovat. Tradičním způsoben je záloha na páskové zařízení a to buď na samostatnou mechaniku typu LTO, Jaguar, StorageTek, DLT atd., které se liší především rychlostí zpracování a kapacitou média, nebo na automatizovanou páskovou knihovnu. Někteří zákazníci volí výkonnostně optimálnější variantu a to dvoukrokové zálohování, kdy nejprve provádí první zálohu na diskové pole levnějšího typu s použitím například disků typu SATA9 nebo FATA10 a v druhém kroku pak dochází k odlití dat na páskovou technologii. Tento způsob přináší jednak výhodu v rychlém provedení zálohy a tím zkrácení dopadu na provoz aplikace a zároveň pokud pole slouží i jako zálohovací cache, tak je takové řešení připraveno na velmi rychlou obnovu dat při ztrátě primárních dat.

9

Serial ATA - počítačová sběrnice Fibre ATA – počítačová sběrnice

10

12

3.2 Pokročilé funkce pro zabezpečení dostupnosti dat Pokročilé funkce diskových polí jsou základem jednak pro řešení Business Continuity, Information Lifecycle Management11, tak i pro efektivní zálohování dat nebo optimální využívání produkčních dat pro vývoj aplikací nebo testování nových verzí software.

3.2.1 Vytváření lokálních kopií Účelem lokální kopie je vytvoření klonu k určitému přesně definovanému časovému okamžiku při zachování konzistence dat. Vytváření lokálních kopií se v terminologii IBM produktů nazývá „Point-in-Time Copy“ a již z názvu je možné odvodit, že se jedná o kopii dat k určitému okamžiku. Tato technologie se používá zejména z důvodu eliminace času pro zastavení produkční aplikace, neboť je schopna vytvořit klon dat jen s několika sekundovým zastavením aplikace, přistupujícím ke zdrojovým datům. Toto zastavení se používá pro dosažení konzistence dat a má minimální dopad na dostupnost primární aplikace. K dispozici jsou pak dvě základní alternativy a to základní, která se nazývá FlashCopy12 a pokročilá FlashCopy SE, která navíc umožňuje efektivnější využití diskového prostoru pro vytvoření klonu dat. U obou variant je možné paralelní vytváření i několika nezávislých zdrojů. Využití kopií většinou bývá opakované, právě z důvodu pravidelného denního zálohování, a proto pokud chceme vytvořit zdroj druhý den ještě jednou je funkce FlashCopy schopna udělat jen tzv. inkrementální kopii na cíl, to znamená, že dojde pouze přesunutí dat, která byla od posledního vytvoření kopie změněna. Tento inkrementální přesun snižuje dobu, po které je diskové pole vytíženo kopírováním dat na pozadí a zvyšuje se tím výkonnost dat pro využití aplikací.

FlashCopy Při zapnutí funkce FlashCopy se vytvoří vztah mezi zdrojovým a cílovým volume a je vytvořena bitmapa cílového volume. Jakmile se vytvoří tento vztah je cílový i zdrojový volume okamžitě dostupný a samotná data se začnou na pozadí kopírovat ze zdroje na cíl. Jakmile je FlashCopy zapnuto stačí jen několik vteřin pro vytvoření požadovaného 11 12

Lifecycle Management (ILM) – řízení a správa životnímu cyklu informací FlashCopy – vytváření lokálních kopií dat, uvnitř pole 13

vztahu mezi zdrojem a cílem. Následně je pak možné číst i zapisovat data na obou stranách (zdroj i cíl). Je nutné počítat s tím, že pro vytvoření cílového volume je potřeba mít k dispozici stejnou kapacitu jako u zdroje. V průběhu kopírování dat na pozadí mohou nastat dva druhy kolizních situací a to: Produkční aplikace se snaží udělat

Obrázek 2 – funkce FlashCopy

změnu na zdrojových datech, která ještě nebyla odkopírována na cílový volume. V tomto případě se tato I/O operace předřadí a dojde nejprve k odkopírování původních dat ze zdroje na cíl a potom k přepisu dat novými na zdroji. Zálohovací nebo testovací aplikace požaduje čtení dat z cíle, kde ještě

Zdroj: IBM Corporation

data fyzicky nejsou k dispozici. I zde se tato I/O operace předřadí a dojde k odkopírování požadovaných dat ze zdroje na cíl, kde jsou následně použita. FlashCopy SE Funkce FlashCopy SE je novou variantní technologií, kde vytvořený cílový volume je nazýván Space Efficient a jeho velkou výhodou je redukce celkového diskového prostoru potřebného pro vytvoření cílového volume. Princip spočívá v tom, že na rozdíl od klasické FlashCopy se data na pozadí fyzicky nekopírují, ale vytváří se jen bitmapa na cílovém volume, která ukazuje na primární data. Teprve pokud dojde ke změně primárních dat je nutné původní data fyzicky odkopírovat na cílový volume, který je typem Space Efficient.

14

Space Efficient je volume, který v případě FlashCopy SE dynamicky

Obrázek 3 – funkce FlashCopy Space Efficient

čerpá potřebnou kapacitu pro cílová data z předem definované repository. Repository

je

speciální

volume

obsahující fyzický diskový prostor, který

přiděluje

Efficient

jednotlivým

volumům

Space

prostor

dle

požadavku na fyzická data. Vzhledem k tomu,

že

odkopírovávají

v tomto pouze

případě změny,

se není

potřeba mít cílový prostor stejně velký jako zdroj a zákazník tím šetří cenný


prostor na discích. Tato technologie se nicméně používá u dat, kde se očekává menší změnovost primárních dat a případně využití cílových dat je jen pro kratší časový úsek v řádech hodin. To však plně splňuje požadavky pro naprostou většinu zálohovacích strategií a umožní firmě realizovat zálohu a následně cílový volume smazat.

3.2.2 Vzdálené zrcadlení dat V podstatě nejdůležitější funkcí pro Business Continuity na bázi ukládání primárních dat na disková pole je funkce pro vzdálené zrcadlení Remote Mirror and Copy13, která poskytuje různé druhy zrcadlících technik mezi dvěmi nebo více diskovými poli. Tato funkce disponuje několika typy zrcadlení, která se od sebe liší jednak synchronností či asynchonností přenosu, tak i dosažením úrovně konzistence dat. Metro Mirror Metro Mirror poskytuje zrcadlení logických volume mezi dvěma poli stejného typu v reálném čase na vzdálenost až 300 km. Jedná se o synchronní kopii dat, kdy potvrzení o zapsání dat na diskové pole je serveru potvrzeno, až po zapsání dat na obě lokality. Tento typ zrcadlení je u nás používán nejčastěji protože poskytuje 99,999% dostupnost dat na diskovém subsystému při zachování naprosté konzistence dat.

13

Remote Mirroring – zrcadlení dat na druhé diskové pole 15

Je zde ovšem i jedna nevýhoda, která není ani tak nevýhodou diskového pole jako spíše chybou na straně uživatele. Pokud totiž na primární straně vznikne chyba v datech na straně aplikace, tak funkce Metro Mirror tuto chybu přenese i na záložní lokalitu, neboť tato funkce nehodnotí kvalitu dat, ale zaručuje pouze jejich maximální dostupnost v případě výpadku primární lokality. Global Copy Global Copy kopíruje data nesynchronním způsobem na velkou vzdálenost a je tedy

Obrázek 4 – zrcadlení dat Metro Mirror

vhodná tam, kde již nestačí Metro Mirror. Použitím funkce Global Copy posílá diskové pole inkrementální kopii změněných dat ze zdrojového volume periodicky na cílový volume namísto kontinuálního přenosu dat mezi zdrojem a cílem. Výhodou je nižší výkonnostní dopad na primární aplikaci a menší požadavek na propustnost datových cest mezi oběma poli.


Global Copy neudržuje sekvenci zápisových operací a proto data na záložní lokalitě nejsou v konkrétní okamžik konzistentní. Pokud je nutná konzistence, je zapotřebí zastavit aplikaci a na záložní lokalitě udělat klon (FlashCopy), který jej již konzistentní kopií primárních dat. To je důvod proč tento způsob zabezpečení se v praxi používá velmi zřídka a pro potřeby Business Continuity je v podstatě nepoužitelný.

Global Mirror Obrázek 5 – zrcadlení dat funkcí Global Mirror

Global Copy je asynchronní zrcadlení dat mezi

dvěma

vzdálenost

stranami

na

s udržením

velkou dat

v konzistentním stavu, takže je adekvátní náhradou funkce Metro Mirror tak kde problémem je vzdálenost. Funkce Global Mirror se používá dohromady s funkcí Zdroj: IBM Corporation 16

FlashCopy v automatickém módu za pomoci konzistentních skupin, aby se zabezpečila konzistence dat. Data jsou asynchronně přenášena z primární strany na druhou a jednou za určitý čas, například po 5 sekundách se automaticky na druhé lokalitě vytváří klon (FlashCopy), který se právě každých 5 sekund pomocí inkrementálního principu obměňuje. Po vytvoření klonu je primární diskové pole informováno o vytvoření konzistentního klonu, který je pro případ pádu primární lokality možné využít. Tímto způsobem je jednak možné docílit obnovení sytému s minimální ztrátou dat a zároveň je to jediný způsob jak přenášet data na záložní lokalitu, která je vzdálená více jak 300 km.

3-stranné Metro/Global zrcadlení Metro/Global Mirror kombinuje

Obrázek 6 – modelové nasazení konceptu 3-stranného zrcadlení

funkce Metro Mirror a Global Mirror dohromady a poskytuje možnost implementovat Disaster Recovery řešení pro tří stranné zrcadlení

dat

a

tím

docílit

maximálně možného zabezpečení dat s 99,99999% dostupností dat. Řešení

funguje

na

bázi

synchronního zrcadlení dat mezi primární a záložní lokalitou, Zdroj: IBM Corporation

která je pro tento případ umístěna

do vzdálenosti cca 500 metrů od primární lokality a tím je zabezpečena maximální rychlost zrcadlení dat, za pomoci funkce Metro Mirror. Následně jsou data ze sekundární lokality asynchronně zrcadlena do třetí lokality, která je již vzdálena obvykle více jak 200 km, aby se docílilo geografické nezávislosti a ochraně proti takovým katastrofám jako je zemětřesení, rozsáhlé požáry nebo povodně. Toto řešení vyžaduje značné finanční prostředky a to nejen do storage infrastruktury, ale vybudování i kompletní třetí lokality. To je i důvod proč není takového řešení v České republice nasazeno.

17

3.3 Kryptování dat Kryptování dat se stává nedílnou součástí implementace infrastruktury pro ukládání dat. Čím dál více firmy zjišťují, že cena jejich dat má pro ně obrovskou hodnotu a jejich případné zneužití mé nedozírné následky ať po stránce právní tak hlavně z pohledu jejich obchodní činnosti. Soutěž konkurenčních firem dnes není již jen otázkou standardních postupů, ale velmi často se setkáváme s nekalými praktikami mezi které patří i krádež cenných podnikových informací jakou jsou jména klientů, nabízené produkty a řešení, cenotvorba či obchodní strategie.

Kryptování na páskových systémech Výrobci se proto snaží vyvíjet nejen systémy na ochranu samotných dat, ale i technologie, které data zabezpečí právě pro tyto účely krádeží či zneužití obsahu. IBM přišla již před pár lety s možností kryptace dat s využitím standardní AES (Advanced Encryption Standard) algoritmu na páskových mechanikách, které postupně rozšířila do technologií LTO a Jaguar. Kryptace je implementována přímo na hardware páskové mechaniky a zabezpečuje data těsně před zápisem na medium. Tím je myšleno, že data se primárně zkomprimují a následně zakryptují, tím je zajištěna nulová ztráta kapacity v průběhu kryptace. Pokud totiž dojde nejprve ke kryptaci a potom ke kompresi dochází k velmi malému poměru komprimovaného obsahu oproti původní velikosti. Oproti kryptaci dat na úrovni aplikace nemá hardwarová kryptace dopad na výkonnost zálohování, protože data se kódují online se zachováním maximální rychlosti zálohovací mechaniky. Na rozdíl od tzv. symetrické kryptografie, kdy je stejný klíč použit pro kryptování i dekryptování, používá IBM řešení kryptografii asymetrickou. Datový klíč, který je používán pro šifrování dat, je rovněž kryptován tzv. veřejným klíčem před uložením na páskové médium a k jeho dekryptování je zapotřebí korespondující tzv. privátní klíč. Data jsou tímto způsobem mnohem lépe zabezpečena především pro převoz mezi lokalitami. Celkové řešení ovšem musí brát v úvahu rovněž i správu klíčů a politiku kryptování. Řešení od IBM vyhovuje třem základním metodám správy klíčů - spravované aplikací, spravované přes systémem a spravované přes knihovnu. Toto řešení je podporováno

18

dvěma základními způsoby - buď správa kryptovacích klíčů je uskutečněna prostřednictvím aplikace (např. TSM) nebo nového nástroje pro správu šifrovacích klíčů EKM (IBM Encryption Key Manager). V České republice je toto řešení nasazeno u bankovních zákazníků, kde se správa klíčů řeší převážně za pomoci správy knihovny.

Kryptace na diskových polích Nejnovější technologií kryptace dat je kryptace na úrovni diskových zařízení, IBM tuto technologii poprvé ohlásila v březnu 2009 pro svoje hi-endová14 disková pole DS8000 a postupně ji bude implementovat do ostatních diskových subsystémů. Technologie má za úkol obdobným způsobem jako je to na páskových zařízeních kryptovat data přímo na diskových modulech s nulovým dopadem na výkonnost aplikace, která data spravuje. Vzhledem k tomu že se jedná o novou technologii, v současné době neexistuje reálné řešení v České republice, ale především bankovní společnosti již o tento druh ochrany dat projevilo zájem a plánuje nasazení v nejbližších měsících.

14

Disková pole nejvyšší řady určená do nejnáročnějších podnikových prostředí 19

4 Koncept Business Continuity z pohledu storage V dnešním prostředí má inovace mnoho podob jako jsou zajímavé produkty a služby, nové zajímavé trhy, operační procesy, nové modely testování, kvalifikace a strategie. Ale jakákoliv inovace v dnešních společnostech je prakticky nemožná pokud IT oddělení nevytvoří dostatečně kvalitní podpůrné prostředí. A jedním z hlavních předpokladů pro optimální prostředí je prostředí, které zajišťuje kontinuální podporu obchodních procesů s maximální dostupností dat. Proto v mé práci uvádím praktické zkušenosti z implementace několika řešení Business Continuity. K zajištění co nejvyšší dostupnosti, využitelnosti a bezpečnosti implementují firmy vysoce dostupné storage řešení schopné zvyšovat právě dostupnost dat pro všechny uživatele a aplikace v okamžiku, kdy je potřebují. Mezi firmy s typicky potřebnou maximální dostupností patří především bankovní domy, pojišťovny, telekomunikační poskytovatelé, firmy z oblasti energetiky, ale také velké státní organizace. Redukováním a eliminováním všech míst selhání v těchto výkonných prostředích SAN pomáhá zvyšovat hlavně dostupnost obchodních transakcí. A případným využitím vysoce

dostupných

Obrázek 7 – základní obrázek Business Continuity

komponent a bezpečnostních řešení jsou SAN schopni poskytovat operativní režim

zmiňovaných

společností

Tier 6

Rychlá obnova dat

Náklady

7x24 hodin, který je u již

Stálá dostupnost

Tier 7

Tier 4 Tier 3 Záloha a obnova

garancí úspěšnosti podnikání či

poskytování

u

státních

služeb

Tier 2

15 Min.

1-4 Hr..

4 -8 Hr..

8-12 Hr..

12-16 Hr..

24 Hr..

Tier 1

Days

Doba obnovy systému

organizací.

Nejdůležitějším konceptem je


využití redundantních komponent, software, propojení a vytvoření tzv. redundantních cest, které jsou maximálně odolné proti výpadku dostupnosti k samotným datům a zároveň zajišťují možnost optimálního vytížení všech přípojných cest. Dalším krokem v získání dostupnosti je víceúrovňová redundance, kdy jde o zdvojení všech komponent uvnitř jednotlivých zařízení uvnitř SAN sítě.

20

Business Continuity je ustálený anglický název pro kontinuitu obchodních procesů a znamená, že kritická data a zdroje jsou neustále nebo skoro neustále k dispozici. Nicméně Business Continuity není Disaster Recovery15, je to nepřetržitý provoz hlavních transakcí v případě katastrofy či pádu systému, ale také v průběhu standardní rutinních IT operací jako je zálohování, údržba aplikace nebo upgrade systému. Ne všechny aplikace, ale vyžadují tu nejvyšší a samozřejmě nejdražší úroveň obnovy v případě výpadku. Pro každou takovou aplikaci se zvažuje optimální nasazení nejvhodnější, dostatečně bezpečné a zároveň finančně únosného řešení. Vždy je potřeba si definovat jaký čas je ještě akceptovatelný pro obnovu takové aplikace po pádu systému a porovnat s náklady na takové řešení. Business Continuity je zaměřeno na přístup k datům a ochranu kritických obchodních procesů a skládá se ze tří úrovní: Záloha a obnova. Rychlá obnova dat. Stálá dostupnost. Celkový plán pro Business Continuity má mnoho různých částí, které je potřeba zvažovat pokud chce být firma dostatečně dobře připravena na neočekávaný stav, a těmi částmi jsou krizový řídící plán, analýza dopadu na obchodní činnost, řízení lidských zdrojů, procedury pro případ obnovy systému a další dokumentace popisující aplikace a systémy. S tím souvisí i primární aspekty Business Continuity:

High Availability16 Vysoká dostupnost je schopnost a způsob jak poskytnout přístup aplikacím bez ohledu na lokální poruchu, způsobenou v systémech, fyzických zařízeních nebo IT software a hardware.

Continuous Operations17 15 16

Disaster Recovery – obnova systému po zhroucení High Availability – vysoká dostupnost 21

Stálý provoz je schopnost udržet bezodstávkový provoz i za předpokladu, že systémy jedou, ale potřebujete udělat zálohy dat či plánovanou údržbu.

Disaster Recovery Obnova po zhroucení systému je schopnost obnovit datové centrum v záložní lokalitě, pokud došlo ke zničení primární lokality nebo její neschopnosti provozovat nadále systémy, na jiném hardware.

4.1 Metodologie výběru řešení V této kapitole si rozeberme jednotlivé úrovně řešení Business Continuity, kterým se říká Tiery. Každá taková úroveň definuje přesně výši zabezpečení dat pro případ výpadku a rychlost obnovy do provozního stavu, přičemž každá má velmi rozdílné finanční nároky na realizaci a to exponenciálním růstem. Obrázek 8 – úrovně řešení Business Continuity - Tier


Rozhodnutí firmy který Tier bude implementován v daném prostředí je prakticky to nejdůležitější při výběru technologie, postupů činností a přijmutí případných rizik spojených s nečekanou nebo plánovanou odstávkou. Celkem je definováno sedm úrovní od základního uložení dat bez jakékoliv ochrany až po zcela nepřetržitý automatizovaný provoz. Tato definice vznikla již v roce 1992 ve

17

Continuous Operations – stálý provoz 22

Spojených státech ve spolupráci IBM a skupinou SHARE. A vznikla tak jednoduchá metodologie pro vytváření Business Continuity řešení.

Tier 0: Data bez ochrany Řešení, pokud se to tak dá nazvat, je v Tier 0 bez jakéhokoliv záložního plánu, takže nejsou k dispozici žádné zálohy dat, žádná dokumentace a ani žádný plán obnovy. Typický čas pro obnovu je v podstatě nepředvídatelný a vůbec není jisté že se obnova dat povede. Tento způsob se prakticky u velkých společností nepoužívá.

Tier 1: Zálohování dat bez záložní lokality Řešení používající Tier 1 zálohuje data na pásku a ukládá je do tak zvané spící lokality, kterou může být například trezor. V závislosti na tom jak často se tato záloha dělá je možné v případě pádu sytému obnovit data k datu poslední zálohy což může být i několik dní či týdnů. Nicméně data jsou uložena na pásce a bezpečně uschována, takže obnova dat je možná. Řešení je základním kamenem prakticky každé společnosti a je to koncept, ze kterého většina velkých firem vycházela a implementovala ho v České republice v devadesátých letech minulého století. Typ řešení: IBM Tivoli Storage Manager, Legato Networker

Tier 2: Zálohovaná data se záložní lokalitou Řešení používající Tier 2 vytváří opět zálohu dat na pásku, ale kromě toho, že jsou data na pásku uložena na nějakém bezpečném místě, existuje ještě záložní místo včetně zařízení pro čtení pásek. V případě pádu systému se mohou data převézt a obnovit v záložní lokalitě, ale obnovovací proces může trvat několik hodin nebo až dní. Ještě nedávno velmi oblíbená metodika, která využívala přenos dat pomocí automobilů nebo messangerů. Ještě dnes se s tímto typem Business Continuity můžeme setkat u společností, pro které je investice do Tier 3, tedy do optické linky pro elektronický přenos dat příliš nákladná a spoléhají, že v případě obnovy budou schopni relativně rychle dovézt data po tradičních cestách. Typ řešení: Pásková knihovna, IBM Tivoli Storage Manager, Legato Networker Tier 3: Elektronické přesouvání

23

Řešení Tier 3 obsahuje stejné komponenty jako Tier 2, ale navíc je zde pro kritická data vytvořeno elektronické propojení na záložní lokalitu, kde mohou být data na pásce v druhé kopii a v případě výpadku mohou být data aktuálnější a rychleji obnovena. Tato alternativa v České republice znamená oproti investici do Tier 2 několik set tisíc Kč měsíčně do optického propojení. Záleží pak kolik tras chce zákazník použít pro propojení. Nicméně ze zkušeností je potřeba říci, že pokud se zákazník rozhodne investovat do optické linky mezi dvěma lokalitami, tak by měl využít minimálně dvě na sobě nezávislé trasy z důvodu bezpečnosti, a zároveň pokud si takovou linku pronajme, což je 90% případů, tak by si měl nechat od poskytovatele linky garantovat rychlost a kvalitu spojení a zároveň nastavit smluvně penalizaci v případě nedodržení parametrů. Typ řešení: Elektronická cesta tmavé vlákno, LAN, Pásková knihovna, IBM Tivoli Storage Manager, Legato Networker

Tier 4: Kopie v přesně definovaném čase Řešení Tier 4 se používá pro oblasti s větším objemem dat a požadavkem na rychlejší obnovu. Jedná se opět o zálohu dat na pásky, ale zároveň se již využívá diskových řešení, která jsou rychlejší a snižují tak dobu obnovy na pár hodin. V podstatě se pravidelně po určitých přesně definovaných časových okamžicích vytvářejí datové kopie diskových oblastí, které se elektronicky přenášejí do záložní lokality. Tento Tier je již nákladnější, neboť investice do licencí pro vytváření klonů je otázkou několika milionů korun. Toto řešení je v poslední době již standardem pro větší společnosti, které si nemohou dovolit přerušení provozu na jeden den. Typ řešení: FlashCopy, FlashCopy Manager, Peer-to-Peer Virtual Tape Server, Rapid Data Recovery pro UNIX18 a Windows (eRCMF)

Tier 5: Integrita transakcí Řešení Tier 5 se používá pro oblasti podnikání s požadavkem na konzistentní data a kde je absolutním požadavkem minimální ztráta dat v případě obnovy v záložním středisku. A funkcionalita je do jisté míry využívána i na úrovni samotných operačních systémů a provozovaných aplikací. Dnešní moderní datová centra, která vznikají ve většině

18

UNIX – operační systém pro servery s RISC procesory jakou jsou IBM (AIX), HP (HP-UX) nebo SUN (Solaris) 24

velkých organizací, které potřebují zpracovávat velké objemy dat o svých zákaznících, produktech nebo dělají analýzy trhu, již v počátku výstavby plánují výhradně řešení Business Continuity minimálně na bázi Tier 5 s redundantní infrastrukturou mezi dvěma středisky. Příkladem jsou velké retailové firmy či telekomunikační firmy. Typ řešení: Klastr na úrovni operačního systému

Tier 6: Nulová ztráta dat Řešení Tier 6 již vyžaduje maximální úroveň obnovených dat s předpokladem nulové ztráty dat. Druhým důležitým kritériem je co možná nejrychlejší obnova dat a pro zajištění konzistence dat se už nepoužívají prostředky aplikace, ale samotného hardware a to prostředků vzdáleného zrcadlení na úrovni diskových polí. Taková synchronizace se provádí buď formou synchronního přenosu, který zajišťuje že data jsou v každém okamžiku uložena jak na primárním, tak i sekundárním poli. V druhém případě pokud je vzdálenost mezi lokalitami příliš velká a je požadavek na rychlost odezvy, využívá se zrcadlení asynchronního, které přenáší data do sekundární lokality a nečeká na potvrzování této operace v primární lokalitě. Tier 6 je v podstatě řešení, které dnes používá většina bankovních společností nebo společností, které poskytují svým klientům přístup 7x24. Pro tyto firmy je zastavení aplikace i na několik málo hodin kritickou záležitostí, která jednak ovlivňuje jejich finanční výsledky z pohledu nedostupnosti systémů a zároveň mnohdy může způsobit i odliv klientů ke konkurenci. Z ostatních firem, které mají vybudovány řešení Tier 6 patří například Třinecké železárny nebo Arcelor Mittal, kde se používá spojení dvou světů a to Open systémů a systémů typu mainframe. Tyto společnosti využívají synchronní přenos dat na relativně krátkou vzdálenost do 5 km neboť se nepředpokládá, že případná katastrofa bude rozsáhlejšího charakteru. Zároveň důvodem pro tak krátkou vzdálenost je i fakt, že střediska jsou propojena na kříž, takže v případě výpadku jednoho pole není potřeba přepínat celé středisko, ale dochází pouze k rozpojení zrcadlícího páru polí a přepnutí na data z diskového pole druhé lokality. V případě obnovy pole v primárním středisku se provede otočení zrcadlení funkce Remote Mirroring a udělá se tzv. dosynchronizace dat, aby data která byla po dobu nefunkčnosti primární lokalitě na sekundární straně se sesynchronizovala a mohlo opět dojít k přepnutí na primární diskové pole.

25

Typ řešení: Metro Mirror19, Global Mirror20, GDPS HyperSwap Manager21, Peer-toPeer VTS, HACMP22

Tier 7: Plně automatizované řešení s plnou integritou data Řešení Tier 7 obsahuje všechny komponenty z předešlých Tier řešení, ale navíc má plně automatizovaný provoz celého systému. Tier 7 zajišťuje plnou konzistenci dat ještě nad rámec Tier 6 a splňuje předpoklad plné automatizace obnovy při výpadku. Automatizovaná obnova dat je výrazně efektivnější a rychlejší než sebelepší manuální provoz a tím pádem i obnova je otázkou několika sekund i při výpadku celé primární lokality. Tier 7 již používá velmi málo firem, přestože se případné přepnutí střediska a dostupnost dat snižuje na jednotky minut v době výpadku, tak finanční rozdíl mezi Tier 6 a Tier 7 je někdy až v desítkách milionů korun. Jedním z nejlepších systémů pro vytvoření Tier 7 je tzv. Parallel Sysplex, což je clusterové řešení na serverech typu mainframe s použitím řešení GDPS (Geographically Dispersed Parallel Sysplex), které je postaveno na spojení software, skriptů dělaných na míru a služeb implementace. Toto řešení IBM vyvinula primárně pro jednu Švédskou banku na začátku devadesátých let a postupně bylo toto řešení modifikováno a implementováno do dalších především bankovních prostředí. V České republice používá GDPS Česká Spořitelna na storage infrastruktuře diskových polí EMC. Česká Spořitelna je tímto řešením schopna v případě kompletního výpadku jedné lokality zcela automatizovaně přejít na záložní stranu do 15 minut. Typ řešení: GDPS/PPRC s využitím HyperSwap pro mainframe aplikace, AIX HACMP/XD s Metro Mirror zrcadlením pro open systémy, Continuous Availability pro Windows

Výběr platformy 19

Metro Mirror – synchronní zrcadlení dat Global Mirror – asynchronní zrcadlení dat 21 GDPS HyperSwap Manager – geografický paralelní klastr mainframových serverů 22 HACMP - cluster řešení IBM – High Available Cluster Multi Processor 20

26

Jestliže plánuji vytvoření Business Continuity řešení musím si kromě rozhodnutí o úrovni Tier říci, která data jsou pro mě kritická jak z pohledu časového, tak z pohledu jejich ztráty. V případě ztráty dat se musím ještě rozhodnout jak velké množství, tedy jak dlouhý časový úsek dozadu, je pro mne adekvátní. Z výběru dat mi tím pádem vychází informace o tom jaký objem dat se bude chránit a tím volím i odpovídající diskovou a páskovou platformu. Parametrem Business Continuity, který vychází z vlastností diskových polí, je typ používaného zrcadlení, protože nejvhodnější způsob synchronního přenosu dat nemusí vždy vyhovovat jednak z pohledu vzdálenosti, tak z pohledu propustnosti linek mezi oběma středisky. A tak je potřeba přistoupit k asynchronní ochraně dat. Zkušenost s tímto druhem ochrany popíši v kapitole o nasazování konceptu Business Continuity. Mezi poslední dvě oblasti k rozhodování o implementaci vhodného řešení patří znalost lidí, případně dodavatelské firmy a jaké interní standardy je schopna firma implementovat. Protože pokud máme výbornou technologii, ale v případě jakéhokoliv problému nejsou lidé schopni správným způsobem reagovat, pak investice do IT jsou doslova vyhozené peníze. Nastavení přesných procesů a postupů, které je potřeba učinit v případě nestandardního nebo i očekávaného výpadku jsou zásadní pro optimální provoz Business Continuity řešení. Pro definice těchto plánů a standardů se většinou používá pomoc externích firem, neboť ty mají většinou zkušenosti z implementace obdobných řešení a firma si tak ušetří spoustu času hledáním slepých uliček a ve finále i ušetří finanční prostředky implementací nevhodného řešení.

4.2 Realizace řešení Business Continuity Realizací Business Continuity se u nás realizovalo již velké množství od těch nejjednodušších až po řešení Tier 7, jak jsem uvádím v minulé kapitole. V rámci mé diplomové práce bych Vás chtěl seznámit se dvěmi implementacemi, přičemž první zkušenost je již implementována ve státní správě a hodnotí se již dosažené výsledky a druhá, která je velmi ojedinělým řešením v rámci celého světa, z oblasti přepravy je ještě ve fázi implementace.

27

4.2.1 Řešení pro státní správu Cílem návrhu řešení bylo především vyhovět funkčním požadavkům kladeným na datové úložiště jako celek. Tyto požadavky (funkčního a nefunkčního charakteru) byly zejména následující: Využití moderních a otevřených technologií. Možnost kooperace s existujícími systémy zákazníka. Využití již existujících znalostí na straně zákazníka. Velká škálovatelnost systému. Celkově vysoká dostupnost včetně funkce geografické disaster recovery. Jádrem řešení je lokální databázový cluster založený na databázovém software Oracle. Hardwarovým zázemím pro tento cluster je osmiprocesorový server IBM pSeries p570 s procesory IBM Power5. Síťová infrastruktura zahrnující přepínače L2, L3 a bezpečnostní bránu (firewall) od firmy Cisco je navržena v plné redundanci. Z tohoto pohledu se v systému nevyskytuje jediné kritické místo („single point of failure“), které může způsobit chybu systému jako celku. Oba servery i disková pole mají zdvojené nezávislé napájení, a tak je využito dodatečné hardwarové dostupnosti realizací napájení ze dvou nezávislých zdrojů (přívod elektrické energie z hlavního rozvaděče a z rozvaděče, který je chráněn nepřerušitelným zdrojem napájení).

Cíl projektu Komplexní dodávka datového úložiště Cílem projektu DÚ (Datového úložiště) byla komplexní dodávka datového úložiště sestávající se z Hlavního datového úložiště (HDÚ) a Záložního datového úložiště (ZDÚ), a to včetně jejich plného zprovoznění. Obě datová úložiště byla propojena v reálném čase dvojicí optických vláken, přes které bylo zajištěno zrcadlení dat on-line. Záložní datové úložiště v případě výpadku Hlavního datového úložiště přebírá všechny jeho funkce. V době, kdy ZDÚ pracuje pouze v záložním režimu, slouží pro testování a vývoj. V době provozování pouze Hlavního datového úložiště (první etapa) byla požadována jeho funkce v režimu lokální vysoké dostupnosti (High Availability). Po zprovoznění a předání Záložního datového úložiště byl požadován režim geografické vysoké dostupnosti, kdy po krizovém výpadku Hlavního datového úložiště přebírá jeho funkci Záložní datové úložiště.

28

Součástí projektu byla dodávka v oblasti hardware v rozsahu servery, disková pole, SAN infrastruktura a pásková zálohovací zařízení. Obě datová úložiště byla dodána se všemi technickými zařízeními jako provozuschopný celek. Součástí dodávky byl i požadavek na zajištění síťové infrastruktury LAN a WAN zákazníka.

Kontext datového úložiště v rámci informační centrály zákazníka Projekt datové úložiště (DÚ) se všemi technickými parametry tvoří budoucí platformu pro realizaci jednotného datového úložiště zákazníka. Datové úložiště tvoří otevřenou databázovou infrastrukturu pro implementaci jakýchkoliv dalších databází a podpůrných prostředků typu datový sklad (DW, Data Warehouse), datový trh (Data Mart), analytický server (OLAP) a podobně. Koncept datového úložiště s těmito nadstavbami počítal již v samotném začátku, nicméně v definovaném rozsahu projektu DÚ byly zahrnuty následující oblasti: Databázové prostředí (platforma Oracle). Řídící subsystémy (platforma Tivoli). Ostatní infrastruktura (sítě, pásky, disky, UPS, řešení geografického clusteru atp.). Databáze. Infrastruktura DÚ je navržena tak, aby byla plně výkonově a funkčně škálovatelná (horizontálně-vertikálně) pro budoucí požadavky zákazníka. V rámci tohoto škálování je DÚ připraveno pro využití dalšími nad rámec projektu DÚ. Následující schémata základní topologie v etapě II a etapě III rozkrývají hardwarové obsazení pro řešení jednotlivých úloh datového úložiště (čárkovaně vyznačené oblasti v obou obrázcích specifikují skupinu hardware, která byla součástí jednotlivých fází projektu DÚ). Základem řešení infrastruktury byla síťová vrstva zahrnující přepínače (oddělení sítí s funkcí failover), bezpečnostní brány (firewally) pro ochranu přístupu k řízení a sledování systémů, optickou přepínanou sít SAN (FibreSwitch) a spojení obou lokalit hlavního a záložního datového úložiště v cílové etapě projektu.

29

Následující schéma demonstruje topologii cílového stavu pro etapu II: Obrázek 9 – cílový stav po II etapě


Cílový stav etapy III spočíval v plném rozšíření výpočetního systému pro obě lokality a je naznačen obrázkem číslo 10. (Je zde patrné využití komunikační vrstvy pro komunikaci přepínačů a směrovačů a pro vzájemné propojení optických přepínačů SAN.)

30

Obrázek 10 – cílový stav po III etapě


Stavební prvky oblasti storage Primární diskové pole: Využitelná formátovaná kapacita 20 TB (netto) s využitím technologie RAID a disků 300 GB. Vnitřní cache23 32 GB zrcadlená s možností rozšiřitelnosti na 256 GB. Diskové pole je rozděleno na dvě logická zařízení, která se výkonnostně neovlivňují. Napojení na dohledové systémy s podporou vzdálené diagnostiky. Dva samostatné napájecí zdroje, které zajišťují bezpečné uložení všech dat na disky v případě výpadku napájení. Zabezpečení proti přístupu servisní organizace k produkčním datům.

23

Rychlá paměť pro dočasné uložení dat 31

Vyvažování průchodnosti při přenosu dat přes externí porty a automatická náhrada (fail over) při výpadku některého připojení na servery nebo datovou síť přes externí porty. Připojitelnost diskového pole do datové sítě SAN přes 16 Fibre Channel portů každý s přenosovou rychlostí 2 Gbit/s. Pole umožňuje funkcionalitu vytváření okamžitých kopií dat FlashCopy (chráněné RAID).

Primární pásková knihovna: Velikost knihovny pro uchování 713 páskových médií. Využití páskové technologie LTO24 Ultrium 3. Pásková média pro uchování dat s objemem 200 TB bez komprese. Průchodnost páskových mechanik o celkovém počtu 6 v knihovně 480 MB/sec bez komprese celkem.

Přepínače FC pro síť SAN v lokalitě KP1: Připojení na servery prostřednictvím datové sítě (SAN) přes 2 přepínače Fibre Channel IBM 2005-B32. Celkový počet portů pro připojení zařízení je tedy 2x 32 Fibre Channel 4 Gbit/s. Zapojení přepínačů do plně redundantního režimu. Upgrade primárního diskového pole pro etapu III: Upgrade pole na využitelnou formátovanou kapacitu 36 TB (netto) s využitím technologie RAID a disků 300 GB. Vnitřní cache rozšířená na 64 GB zrcadlená. Rozšíření připojitelnosti diskového pole do datové sítě SAN na 32 Fibre Channel portů každý s přenosovou rychlostí 2 Gbit/s. Přidání funkcionality pro zabezpečení vzdáleného zrcadlení dat po propojení HDÚ a ZDÚ.

Sekundární diskové pole: 24

Linear Tape Open – pásková technologie 32

Využitelná formátovaná kapacita 36 TB (netto) s využitím technologie RAID a disků 300 GB. Vnitřní cache minimálně 64 GB zrcadlená. Diskové pole umožňuje rozdělení na dvě logická zařízení, která se výkonnostně neovlivňují. Napojení na dohledové systémy a možnost vzdálené diagnostiky. Dva samostatné napájecí zdroje, které zajišťují bezpečné uložení všech dat na disky v případě výpadku napájení. Zabezpečení proti přístupu servisní organizace k produkčním datům. Vyvažování průchodnosti při přenosu dat přes externí porty a automatická náhrada (fail over) při výpadku některého připojení na servery nebo datovou síť přes externí porty. Připojitelnost diskového pole do datové sítě SAN přes 32 Fibre Channel portů každý s přenosovou rychlostí 2 Gbit/s. Funkcionalita pro zabezpečení vzdáleného zrcadlení dat po propojení HDÚ a ZDÚ. Pole umožňuje funkcionalitu vytváření okamžitých kopií dat FlashCopy (chráněné RAID).

Sekundární pásková knihovna: Velikost knihovny pro uchování 713 páskových médií. Využití páskové technologie LTO Ultrium 3. Pásková média pro uchování dat s objemem 200 TB bez komprese. Požadovaná průchodnost páskových mechanik o celkovém počtu 6 v knihovně 480 MB/sec bez komprese celkem.

Přepínače FC pro síť SAN v lokalitě KP2: Připojení na servery prostřednictvím datové sítě (SAN) přes 2 přepínače Fibre Channel IBM 2005-B32. Celkový počet portů pro připojení zařízení je tedy 2x 32 Fibre Channel 4 Gbit/s.

33

Infrastruktura SAN Navržená infrastruktura optické sítě SAN byla navržena jako zcela izolovaná od existujících podobných sítí a stejně tak od ostatních výpočetních zdrojů zákazníka. K tomuto rozhodnutí došlo z důvodů: Zajištění bezpečného provozu této sítě (síť nebude ovlivněna jinými servery, jinými úložnými subsystémy, bude ochráněna od případných vnějších zásahů do DÚ jako celku). Zajištění a garance kompatibility použitých komponent sítě (adaptéry FC, přepínače SAN, optické kabely, podpůrné ovladače na straně operačního sytému AIX, stejně tak ovladače na straně systému diskových polí a páskových jednotek). Možnost monitorování a rekonfigurace sítě SAN jako celku. Garance celkového výkonu sítě SAN jako celku bez vlivu jiných výpočetních systémů mimo rámec DÚ.

Následujícím výčtem jsou charakterizovány technické parametry a vlastnosti zapojení SAN: Zónování bylo řešeno metodologií Single Initiator. Tento postup zaručuje maximální čitelnost, nekonfliktnost a správu zón. Zónování bylo řešeno použitím aliasů25. Tento postup zaručuje čitelnost zón a odolnost proti lidské chybě při omylu v zapojení do switche SAN resp. jiného než definovaného portu. Jmenná konvence aliasů byla Jméno LPARu_FC adapter. Např. ORA1_FC0. Přepínače byla mezi sebou propojena mostem (linky InterSwitch) aby tvořila jednu síť. Zamezení redundantních cest, které dále nezvyšují dostupnost systému jako celku (maskování Lun Masking je směrováno na pole DS8300). Propojení mezi lokalitami bylo řešeno pomocí datového multiplexoru. Management přepínačů byl realizován pomocí přístupové metody Telnet, SSH, a http (z tohoto důvodu jsou přepínače připojeny do gigabitové ethernetové sítě, konkrétně sítě pro sledování a řízení MGMT1). Management Páskové knihovny byl řešen pomocí přístupu https. 25

Alias - zástupce 34

Management DS8300 je realizován pomocí přístupu z řídící konzole HMC (nutná fyzická přítomnost administrátora v pracovišti KP1, respektive KP2).

Základní struktura sítě SAN (jak v HDÚ-KP1, tak i v ZDÚ-KP2) se opírá o redundantní zapojení jednotlivých zařízení do hvězdy (dva přepínače v každé lokalitě). Obecný princip zapojení FC hvězdy je na následujícím obrázku. Obrázek 11 – struktura SAN

SRV xyz SRV xyz

SRV xyz

SRV xyz

WAN multiplex DWDM

DSK xyz Přepínače FC TAPE xyz

Přepínače FC

DSK xyz TAPE xyz


Vnitřní infrastruktura diskového systému a návrh obou polí pro DÚ Diskové pole DS8300 – 9A2 je rozděleno na dvě logická zařízení – Storage Facility Image. Logická pole jsou na sobě nezávislá. Každé vlastní procesory, vyrovnávací paměť a má připojen vlastní diskový subsystém přes oddělené datové cesty. Obrázek 12 – vnitřní schéma diskového systému DS8000


35

Procesorový komplex je IBM p570 systémová jednotka. Využívá 4 procesory Power5 – 1,9 GHz, operační paměť. U pole DS8300 Model 9A2 je každý procesorový komplex rozdělen na dvě logické části – LPAR26. LPAR je množina prostředků v procesorovém komplexu, na které je provozován operační systém. Storage Facility Image je sestaven ze dvou LPAR, jeden z každého procesorového komplexu. Název Storage facility Image se někdy zkracuje na Storage image, který je určen pro rozdělení na dvě logicky i výkonnostně oddělená pole. I/O drawer obsahuje adaptéry pro připojení diskového subsystému a adaptéry pro připojení hostujících serverů. I/O drawer zajišťuje propojení adaptérů s procesorovým komplexem pomocí sběrnice RIO-G. S-HMC (celý název je Storage Hardware Management Console). Jedná se o dedikovaný počítač pro správu diskového pole. Pro potřeby zákazníka byl diskový subsystém logického pole 1 navržen tak, že je tvořen celkem 112 fyzickými disky 300 GB s 10 000 rpm27, které jsou rozděleny do 14 skupin po 8 discích. Z každé skupiny 8 disků je naformátováno diskové pole RAID 5. Počet náhradních disků je dán počtem skupin a nelze jej měnit. Diskový subsystém logického pole 2 je tvořen celkem 48 fyzickými disky 300 GB s 10 000 rpm, které jsou rozděleny do 6 skupin po 8 discích. Z každé skupiny 8 disků je naformátováno diskové pole RAID 5. Počet náhradních disků je dán počtem skupin a nelze jej měnit. Obrázek 13 – návrh rozložení logických polí


26

Logical Partitioning (LPAR) – schopnost systému rozdělovat svoje hardware zdroje do menších nezávislých celků 27 RPM – rychlost otáček za minutu 36

Dostupnost databází a jejich zabezpečení proti neplánovanému výpadku Dostupnost databází v případě výpadku jednotlivých subsystémů Následující tabulka popisuje dostupnost jednotlivých typů databází v případě výpadku a následné nedostupnosti některého (jednoho) ze subsystémů, tvořící celé datové úložiště. Subsystémem se v tomto případě rozumí např. server, diskové pole, lokalita. Nejedná se v tomto případě o výpadek komponenty jako je např. síťový adaptér. Při dlouhodobém výpadku některého ze subsystémů je nutné primárně pokrýt potřeby (výkon) „BC“ a „C“ databází použitím dynamické realokace zdrojů. Při krátkodobém výpadku nebo při výpadku mimo hlavní pracovní dobu lze ponechat alokované zdroje v původní (snížené) velikosti. Popis jednotlivých typů databází: BC - Především provozní, produkční databáze, maximální dostupnost, nulová ztráta dat v případě DR události. C - Převážně systémové, ale i provozní a databáze se specifickým určením, převážně nulová ztráta dat při DR události, DR konfigurace umožňuje využití i pro HA. NC - Vývojové, testovací a ostatní databáze, nenulová ztráta dat v případě DR události, nejnižší priorita v rámci Disaster Recovery scénáře.

Tabulka 1 – způsob ochrany jednotlivých typů databází

Typ databáze

Výpadek jednotlivého

Výpadek celého

Výpadek

disku

pole

serveru

ANO

ANO

ANO

ANO

(RAID5)

(PPRC)

(RAC)

(RAC/PPRC)

ANO

ANO

ANO

(DataGuard/

(DataGuard/

(DataGuard/

Replikace)

Replikace)

Replikace)

ANO

NE

NE

NE

(RAID5)

(Restore)

(Restore)

(Restore)

Výpadek lokality

Business Critical

ANO Critical (RAID5)

Non Critical

37


Standardní režim, všechny subsystémy a komponenty jsou dostupné: Obě lokality KP1 a KP2 jsou v provozu. Všechny databáze pracují a jsou dostupné. „BC“ databáze alokují plný výkon. „C“ databáze alokují plný výkon. „NC“ databáze alokují plný výkon. Dlouhodobý výpadek serveru RGT1, nouzový režim: Dostupnost RGT2 (volné zdroje a zdroje z „NC“ LPARů lze přidat „BC“ databázím). Provoz „BC“ a „C“ databází pokračuje nebo je převeden na RGT2 (pro „C“ databáze jsou aktivovány Standby databáze v rámci DR scénáře). „NC“ databáze z RGT2 jsou dostupné, databáze z RGT1 jsou dostupné po obnově ze záloh. Probíhá oprava RGT1. Dlouhodobý výpadek serveru RGT2, nouzový režim: Dostupnost RGT1 (zdroje z „NC“ LPARů lze přidat „BC“ databázím). Provoz „BC“ a „C“ databází pokračuje nebo je převeden na RGT1. „NC“ databáze z RGT1 jsou dostupné, databáze z RGT2 jsou dostupné po obnově ze záloh. Probíhá oprava RGT2. Výpadek primárního diskového pole, nouzový režim, lokalita KP1: „BC“ a „C“ databáze jsou k dispozici v rámci DR scénáře na záložním poli v lokalitě KP2 (nutný restart „BC“ databází, aktivace standby databází pro „C“ databáze). „NC“ databáze z RGT2 jsou dostupné, databáze z RGT1 jsou dostupné po obnově je záloh. Probíhá oprava primárního diskového pole.

38

Výpadek záložního diskového pole, lokalita KP2: Databáze pracují v normálním režimu na diskovém poli v lokalitě KP1. „NC“ databáze z RGT1 jsou dostupné, databáze z RGT2 jsou dostupné po obnově ze záloh. Probíhá oprava záložního diskového pole. Dlouhodobý výpadek lokality KP1: Nedostupnost KP1, dostupnost KP2. „BC“ a „C“ databáze jsou k dispozici v rámci DR scénáře na záložním poli v lokalitě KP2 (nutný restart „BC“ databází, aktivace standby databází pro „C“ databáze). „NC“ databáze z RGT2 jsou dostupné, databáze z RGT1 jsou dostupné po obnově ze záloh. Probíhá oprava KP1. Dlouhodobý výpadek lokality KP2: Nedostupnost KP2, dostupnost KP1. Provoz „BC“ a „C“ databází pokračuje nebo je převeden na RGT1. „NC“ databáze z RGT1 jsou dostupné, databáze z RGT2 jsou dostupné po obnově ze záloh. Probíhá oprava KP2. Rozpojení komunikace mezi lokalitami KP1 a KP2: Krátkodobá nedostupnost „BC“ databází (běžně 10 minut), instance pracují, ale nedovolí měnit data v databázích z hlediska konzistence. „C“ databáze jsou dostupné lokalitě KP1, pouze nesynchronizují data se standby databázemi v lokalitě KP1, po opětovném spojení dojde k synchronizaci. „NC“ databáze jsou dostupné. Pravděpodobnost, že nastane tato situace je minimální, jelikož primární požadavek na propojení (WAN/SAN) obou lokalit byl duplicitní, nezávislé propojení lokalit KP1 a KP2. Z tohoto důvodu by za žádných okolností nemělo dojít ke kompletnímu rozpojení obou lokalit.

39

Dostupnost databází v případě výpadku jednotlivých lokálních komponent Konfigurace jednotlivých subsystémů (serverů, diskových polí atp.) je navržena tak, aby byl subsystém schopen bez výpadku pracovat při nedostupnosti určité lokální komponenty jako například síťový adapter, Fibre Channel adaptér apod. Subsystémy používají pro Obchodně kritické „BC“ a kritické „C“ databáze redundantní připojení. To znamená, že každý adaptér je k dispozici minimálně ve dvojím provedení a nakonfigurován tak, aby výpadek jednotlivého adaptéru byl v rámci AIXu transparentní pro ostatní vrstvy a nezpůsobil výpadek celého subsystému.

Disaster recovery řešení pro obchodně kritické databáze Disaster Recovery řešení je realizováno mirroringem na úrovní diskového pole, diskové prostory pro všechny databázové soubory jsou synchronně zrcadleny na druhé diskové pole v záložní lokalitě přes SAN infrastrukturu. V případě dlouhodobé nedostupnosti primární lokality KP1 lze přepnout provoz databází na lokalitu KP2 a pokračovat v provozním režimu společně s obnovou lokality KP1. V případě krátkodobé nedostupnosti (výpadek dodávky el. energie bez dopadu na infrastrukturu a konzistenci dat v databázi) lze převést provoz na záložní lokalitu, nicméně je potřeba provést analýzu

efektivnosti

přepnutí

na

záložní

lokalitu

vzhledem

ke krátkodobé

nedostupnosti. Obnova v případě poškození databáze, například nekonzistence v důsledku lidské chyby nebo fyzické poškození databáze, je realizována standardními prostředky, tj. RMAN utilitou ze záloh.

Popis DR procedur v případě výpadku primární lokality Z pohledu zrcadlících funkcí diskových polí DS8300 jsou definovány dva základní procesy: Failover – proces, kdy se přebírá provoz z primárního pole na záložní. Dojde pouze k rozpojení diskových párů a aktivování disků na záložní straně. Synchronizační mapy zrcadlících párů zůstanou zachovány. Mapy disků na záložní straně se dále "špiní" (mění) v důsledku provozu aplikace. Failback – proces, kdy se obnovuje provoz na primárním poli. Nová data, která vznikla za dobu provozu na záložní straně, se synchronizují ze záložního pole na

40

primární. Směr synchronizace se otočí, disky na primární straně jsou aktivované a dostupné, disky na záložní straně jsou synchronizovány. V procesu synchronizace se použijí mapy.

Vlastní DR postup, z pohledu diskového pole Failover proces: Zastavení aplikací (pokud už nejsou zastaveny díky nedostupnosti k disků na primárním poli). Vymazání z ODM PVID disků primárního diskového pole na úrovni operačního systému AIX. Aktivace disků na záložní straně => funkce Failover PPRC na úrovni diskového pole. Načtení nových PVID do ODM na úrovni operačního systému AIX. Start databází, aplikací.

Obnova primární strany do původní DR konfigurace, z pohledu diskového pole Failback proces: Obnova ze záloh, pokud dojde k poškození systému, za normálních okolností tento krok není potřeba, protože k poškození nedojde a systém je dostupný a pracuje v záložní lokalitě. Aktivace disků na primární straně => funkce Failback zrcadlení diskového pole, data se synchronizují ze záložního pole na primární pole, disky na primárním poli jsou nedostupné. Po dokončení synchronizace lze naplánovat výpadek pro přepnutí na primární stranu: o Zastavení aplikací, databází. o Vymazání z ODM PVID disků na záložní straně na úrovni operačního systému AIX. o Aktivace disků na primární straně => start synchronního PPRC v původním směru synchronizace na úrovni diskového pole. o Načtení PVID disků z primárního pole na úrovni operačního systému AIX. o Start aplikací, databází.

41

Infrastruktura pro zálohování a archivaci Základní pilíře řešení zálohování a archivace byly postaveny na programu TSM Tivoli Storage Manager. Tento zálohovací software komunikuje s klientem a TSM Tivoli Storage agentem nainstalovaným na zálohovaných LPARech. Klient spouští zálohu a vykomunikovává s TSM serverem parametry zálohy. TSM server provede potřebné kroky a připraví prostředí pro Storage agenta (TSM for SAN) na zálohovaném LPARu. TSM server dá signál TSM klientu a spouští zálohu. Tento postup umožňuje směrovat datové toky na zálohovaném LPARu a dále pomocí SAN přímo na páskové jednotky. Tato technologie (LAN-Free) umožňuje provádět masivní zálohy bez zbytečných dopadů na produkční infrastrukturu, např. LAN, TSM server a paralelní zálohy. Samotný TSM klient umí zálohovat soubory na úrovni operačního systému. Pro zálohování databází se používá TDP modul pro databáze, což je interface mezi TSM klientem a zálohovacím nástrojem Oracle, v tomto případě Oracle RMAN. TSM software zajišťuje správu zálohovaných dat. Udržuje databázi pravidel pro zálohování a přiřazení zálohovaných serverů k těmto pravidlům. Řídí zálohovací zařízení (páskové knihovny, optické knihovny, CD boxy…). V rámci zálohovacích politik zajišťuje migraci zálohovaných dat, tzv. „Hierarchical Storage Management“. To umožní například zálohovat v jednom okamžiku desítky serverů na disk TSM serveru. Z disku jsou data automaticky přelévána na pásky. Toto je podstatná výhoda, jelikož při přímém přístupu na pásku by na ni mohl v jednom okamžiku zapisovat pouze jeden server. V případě potřeby TSM server vytváří duplicity dat uložených na sekvenčních mediích (např.

pásky)

pro

případ

jejich Obrázek 14 – schéma toku dat při LAN-Free

poškození a zajišťuje management offsite záloh (trezor, jiná lokalita) tj. Disaster Recovery řešení použitím DRM (Disaster Recovery Modul). Pro potřeby tohoto projektu byly určeny dvě páskové knihovny IBM 3584 s celkovým počtem 6 mechanik LTO Ultrium 3 o celkové nativní propustnosti 480 MB/s a médii LTO Ultrium 3 o celkovém objemu 200TB na každé straně.

Zdroj: IBM Corporation 42

LAN-free backup na rozdíl od tradičního LAN backupu nepřenáší data po LAN na TSM server, ale po datové síti SAN přímo na sdílené páskové případně diskové zařízení. Po LAN se komunikují pouze metadata o zálohovaných datech. Po síti LAN také probíhá komunikace LAN-free agenta s TSM serverem o přidělení výhradního přístupu k zařízení. Vlastníkem zařízení (páskové knihovny nebo mechaniky) je TSM server, který svoje prostředky pouze „zapůjčuje” zálohujícím serverům. Výhody použití LAN-Free backupu pro BusinessContinuity: Minimální zatížení serverů v době zálohování - přenos po SAN nezatěžuje LAN a narozdíl od TCP/IP komunikace nezatěžuje CPU. Velké objemy zálohovaných dat – menší množství dat a nespojité zálohy z více zdrojů je vhodnější posílat na diskové cache. U souvislého proudu dat velkého objemu je efektivnější přímý zápis na pásku. Požadavky na rychlost zálohy/obnovy – možnost paralelního zápisu na více médií při využití plného výkonu pásek, není bržděno souběžnými backupy jiných serverů, neprochází sběrnicí TSM Serveru. Pro rychlejší zálohování byl vytvořen na každém diskovém poli DS8000 předřazený diskový pool o velikosti 300GB v oblasti určené primárně pro testovací a vývojové účely, kam se data primárně zálohují. Posléze jsou data přenášena na páskovou knihovnu.

Disaster Recovery z pohledu TSM TSM zálohy z primárního storage poolu

Obrázek 15 – DRM implementace

byly v rámci Disaster Recovery migrovány do sekundárního copy storage poolu na Lib2 v záložní lokalitě. Přenos probíhal mimo běžnou pracovní dobu (v době nejmenšího zatížení SAN). Každá

knihovna

byla

rozdělená

na

2 logické knihovny, přenos pásek do trezoru (Vault), vypršení platnosti zálohy (Vaultretrieve) a přenos neplatných záloh (Onsiteretrieve). Zálohy se vytvářely na p5

p5

43 Zdroj: IBM Corporation

lokální knihovnu, na vzdálenou knihovnu se vytvářela kopie záloh a tyto kopie se případně přenášejí do trezoru. V každém momentě tedy existují minimálně 2 kopie zálohy. Na TSM serveru na sekundární lokalitě a knihovně probíhal vlastní DRM proces tj. proces zálohy již pořízených záloh (vytváření kopií pásek). Zálohy byly tímto způsobem redundantní tj. existovali dvě zálohy. V případě rutinního restore se používají primární pásky na primární lokalitě. V případě, že nejsou dostupné, existuje jejich duplikát na sekundární straně. Disaster Recovery cyklus zároveň řeší „občerstvování“ archivních pásek, tzn. zamezení stavu, kdy páska ležící v archivu mnoho let je již nečitelná.

Obrázek 16 – DRM mechanismus rotace pásek


44

4.2.2 Business Continuity přes oceán Nyní se v České republice implementuje, respektive ladí řešení pro zákazníka z oblasti přepravy, který požaduje dvě oddělené lokality přes oceán na vzdálenost 9000km. Toto řešení je v kontextu celého světa velmi ojedinělé a podílí se na něm experti přímo z vývoje kopírovacích a zrcadlících funkcí. Celé řešení je postaveno na použití serverů typu mainframe a diskových polí IBM DS8000 s podporou kopírovacích funkcí pro asynchronní zrcadlení Global Mirror ve spolupráci s funkcí FlashCopy pro vytváření konzistentních skupin dat. Zároveň tento zákazník pro aplikace fungujících na bázi serverů IBM iSeries má implementované Business Continuity řešení v Praze na bázi synchronního zrcadlení Metro Mirror. V této kapitole se chci zaměřit pouze na řešení pro servery mainframe. Zákazník v současné době používá tři geograficky vzdálené lokality pro zrcadlení aplikací a dat, které se nachází v USA, Praze a Malajsii. Pro svojí kritickou aplikaci operující v USA se rozhodl vytvořit záložní lokalitu v Praze. Zákazník pro zrcadlení standardně využívá funkcí synchronního přenosu, ale díky tomu že vzdálenost pro tento případ neumožňuje z technického hlediska použít tuto technologii, protože reakční čas by se pohyboval v sekundách až minutách, zatímco požadavek byl v nano sekundách, tak je použito asynchronní zrcadlení. Toto řešení vyžadovalo velmi pečlivé ladění jednotlivých kroků zrcadlení a vytváření konzistencí, a to hned z několika důvodů. Jednak to byl relativně velký objem dat, které je nutné řídit a zrcadlit a to přes ne příliš propustnou linku mezi USA a Evropou a druhým spektrem bylo kolik ztracených dat je zákazník ochoten akceptovat v případě výpadku primární lokality. Po několika nastaveních a problémech s potvrzováním zrcadlených dat se docílilo, že na záložní lokalitě jsou data oproti primární straně starší o 30 sekund, což zákazník považuje za adekvátní ztrátu vzhledem v vzdálenosti lokalit. Obrázek 17 – původní návrh řešení zrcadlení na velkou vzálenost

45


46

Obrázek 18 – finální návrh implementace Global Mirror Intercontinental Global Mirror

Location Prague Czech Republic

Location: Arizona USA

9000 km

System I

System I

Metro Mirror Cluster Mimix

C1 0

C0 2

C0 3

C0 4

C0 5

C0 6

C0 7

C0 8

C0 9

C1 0 C1 1

C1 2

C1 3

C1 4

C1 5

J 11

J 14

J 15

J 16

C0 1

DS8100

DS8300

OUT

FCIP

FCIP

2 I C

IN

T 1

2

T 2

1

R ( T )3

IPIP

C0 3

C0 4

C0 5

C0 6

C0 7

C0 8

IN

C0 9

C1 1

C1 2

C1 3

C1 4

C1 5

J 11

J 14

J 15

J 16

OUT

T 1

2

T 2

1

R ( T )3

FCIP IC 2

FCIP

C0 2

2 I C

C0 1

T 1

2

T 2

1

(R T )3

FCIP

FCIP

FCIP

FCIP

DS8300

DS8300 Global Mirror GDPS zSeries

zSeries


4.3 Zhodnocení výsledků a návrhy na zlepšení Z implementovaných projektu je zřejmé, že pro návrh fungujícího Business Continuity je potřeba si uvědomit několik aspektů. Jednak je to definování času, po který mohou být data nedostupná v případě pádu i celé lokality a druhým kritériem je případná ztráta dat a pokud je povolená ztráta dat, tak jak velký časový okamžik před pádem jsme ochotni tuto ztrátu akceptovat. Pokud máme definovaná tato kritéria a rozsah aplikací pro které je definujeme, jsme schopni definovat rámcovou cenu celého řešení, která nemusí odrážet firemní možnosti. Pak je potřeba přistoupit k postupnému hledání kompromisů. V neposlední řadě je pak si potřeba uvědomit, že nasazení Business Continuity projektu je časově velmi náročné a lidé, kteří se na něm podílí k němu musí přistupovat zodpovědně a komplexně i s ohledem na podnikové procesy.

47

5 Koncept Information Lifecycle Management Information Lifecycle Management (ILM) je ustálený anglický název pro řízení a

správu

životního

cyklu

Obrázek 19 – model ILM

informace a je to proces řízení Information Lifecycle

informací od jejich pořízení až po jejich zánik s ohledem na poměr mezi cenou za uložení

Cyklus obsahu

Cyklus obsahu

Cyklus obsahu

Cyklus obsahu

Cyklus obsahu

Vytvoření

Revize

Přesun

Schválení

Publikování

těchto dat a jejich měnící se

vyhledávat,

informace

regulačnímu

na ke a

Korporátní politiky Policies Obchodní pravidla

Audit

Bezpečnost

archivovat, „dolovat“ a ničit

požadavku

Svolení

Deklarace

procesům

katalogovat,

Archivace / Zničení

Informační Management Klasifikace

hodnotou v čase. To poskytuje obchodním

Cyklus obsahu

Klasifikovaná Storage

základě komerčnímu, zákonnému

využití. Hlavním cílem při řízení informací je i nadále snižování

nákladů


na

vlastnictví těchto dat neboli Total Cost of Ownership (TCO)28.

Základní prvky Information Lifecycle Managementu K řízení životního cyklu dat a přípravě obchodních procesů pro poskytování služeb na požádání existují čtyři základní kameny, které propojují obchodní činnost s prostředím ILM a jsou to: Řízení klasifikované storage, Dlouhodobé uchovávání dat, Řízení životnímu cyklu dat a Řízení archivace na základě politik. Většina firem dnes hledá storage řešení, které jim pomůže řídit data efektivněji. Chtějí především redukovat náklady na ukládání velkého a neustále rostoucího objemu dat Obrázek 20 – klasifikovaná storage

a souborů a udržet plynulý chod jejich obchodních procesů. Prostřednictvím klasifikované storage, je možné redukovat celkové náklady na diskovou kapacitu s následujícími výhodami: 28

Total Cost of Ownership (TCO) – celkové náklady na vlastnictví

48

Redukování celkových nákladů na diskovou

kapacitu

aktuálních

a

alokováním nejkritičtějších

obchodních dat na nejvýkonnější diskové zařízení a přesunutí starých a méně kritických dat na levnou diskovou kapacitu. Zdroj: IBM Corporation

Urychlení obchodních procesů při přesunutí nejaktuálnějších a nejvyužívanějších dat na zařízení s nejrychlejším přístupem. Při přesouvání dat mezi jednotlivými klasifikovanými storage zařízeními je nutné dodržovat pravidla, aby důležitá a aktuální data byla uložena na nejrychlejším zařízení jako jsou například disková pole s použitím Fibre Channel technologie a postupně stárnoucí a méně využívaná data byla postupně přesouvána na pomalejší disky SATA nebo iSCSI, případně pásková zařízení jak je tomu na následujícím obrázku. Hlavními výhodami přesouvání dat mezi klasifikovanými storage zařízeními jsou: Redukce

celkových

nákladů

na

Obrázek 21 – klasifikovaná storage dle úrovně

vlastnictví (TCO) a pomoc při optimalizaci ceny za vlastnictví dat a jejich správu. Segmentace dat podle jejich hodnoty a

tím

vytvářet

rovnováhu zařízení

mezi a

ekonomickou cenou

hodnotou

storage na

nich

uložených dat. Pomáhá

dělat

rozhodnutí


o přesouvání, zachovávání a mazání dat. Pomáhá při rozhodování o tom, jak se z daty bude zacházet na základě jejich obsahu a ne jen technických parametrů dat.

Dlouhodobé uchovávání dat

49

V poslední době čím dál více roste objem daných specifických dat, pro které je charakteristická jedna vlastnost a tím je dlouhá doba uchování. Tato data jsou i v řádech desítek terabytů a pocházejí především z oblasti účetnictví, různých finančních oblastí a různé druhy smluv. Ona data je nutné ze zákonných a jiných regulativních důvodů skladovat po dlouhou řadu let s tím, že jejich obsah se z přibývajícími lety čím dál méně využívá a obvykle jen při různých typech auditů. Největším rozmachem tohoto způsobu uchovávání dat je smlouva Sarbanes-Oxley ze Spojených států z roku 2002. Obchodní procesy musí ctít zákony a regulativy a tyto informace, které obsahují e-mail, různé zprávy, obchodní transakce, účetní transakce, kontrakty, pojišťovací události a další, musí skladovat s atributem nepřepisovatelnosti a zachování původního obsahu po dobu i 50 let. Pro uložení tohoto typu dat je dle ILM nejvhodnějším způsobem nepřepisovatelné páskové médium nazývané WORM29. V neposlední řadě musím zmínit i oblast ukládání zákonem stanovených dat, přestože zatím v Čechách tento trend není zatím tak významný, tak ve světě jsou firmy čím dál více nuceni uchovávat státem definovaná dat pro případ následné kontroly. Mezi tato data patří například účetní doklady, finanční výkazy a analýzy a různé druhy smluv.

5.1 Metodologie výběru řešení Aby bylo možné ILM strategii efektivně implementovat je potřeba, aby si uživatelé definovali jakým způsobem jsou data vytvářena, využívána, měněna a kdy mohou být smazána. ILM segmentuje pak tyto data na základě jejich hodnoty a

vytváří

ekonomickou rovnováhu mezi cenou storage zařízení a hodnotou informace, která je na něm uložena. Základní charakteristikou procesu ILM je pak přesouvání dat mezi jednotlivými klasifikovanými storage zařízeními, počínaje hi-end diskovým pole, přes pole levnější kategorie jako jsou například SATA disky, přes pásková zařízení až po ty nejlevnější archivační úložiště jako třeba DVD nebo jiné optické disky. ILM není jen přesouvání dat, ale také určitý proces definice, kdy a jak se data přesouvají na základě definovaných politik, která monitorují využívání konkrétních informací. Obdobně jako u řešení Business Continuity i u ILM platí, že zákazník si musí předem říci jak velká investice do řešení je pro něj akceptovatelná a opodstatněná vůči jeho 29

Write Once Read Many – nepřepisovatelné médium 50

obchodním cílům a navrhnout nebo si nechat navrhnout balancované řešení s odpovídajícími politikami. Je potřeba přihlédnout k ceně informace, které chceme spravovat systémem ILM, jejich množství a také ke změně jejich ceny v průběhu životního cyklu. Na obrázku je vidět konkrétní typy dat a jejich hodnotu v časové ose od 7 dnů až po 10 let. Obrázek 22 – hodnota dat v závislosti na jejich stáří


V praxi se dnes používá ILM v následujících oblastech: Přesun citlivých dat z disků na pásky v horizontu desítek let – tzv. retence dat. Postupný přesun méně důležitých dat z drahých disků Fibre Channel na levné disky SATA/FATA. Zálohování dat ve dvou krocích a to první na diskové pole a následně přesun na pásku. Obecně archivační data a jejich postupný přesun mezi různými typy storage zařízení. Dočasný přesun dat z drahých disků na levné a po vypršení potřebné doby návrat na drahou storage. Přesun duplikovaných dat na levnou storage nebo jsou přesunuta do trezoru jako inaktivní. Virtualizace dat se zahrnutím různých fyzických zařízení s různou cenou. Fyzická kapacita jen pro reálná data bez ohledu na logickou velikost volume.

51

Pokud máme představu, která data chceme spravovat systémem ILM a víme co, kdy a kam uložit, je nutné si definovat hardwarové komponenty, softwarové řešení ale také především politiky podle, kterých se bude celé řešení řídit. Tyto politiky musí být striktně popsané i v podnikových procesech a musí být jimi podporovány. Velmi často se stává, že celý projekt ILM zkrachuje již v době výběru, protože firma se uvědomí, že její procesy nejsou dostatečně flexibilní a nedovolí tedy efektivně přesouvat data mezi jednotlivými Tiery. Pro příklad uvádím některé ILM politiky: Nová data musí být alespoň X měsíců na discích - legislativní důvody. Data, která nebyla použita více jak 1 měsíc jsou automaticky přesunuta na levnější zařízení. Data, která jsou použita maximálně třikrát za poslední měsíc jsou odlita na levnější zařízení. Pro velmi stará data - po uplynutí cca 20ti let se dnes předpokládá, že by pásky nebyly online v mechanice, ale data by byla dostupná "na vyžádání" např. do 24 nebo 48 hodin. Data citlivá z účetního hlediska musí být uložena na nepřepisovatelném médiu. Kritická data musí být enkryptována. Přesun dat mezi Tiery musí být realizováno do x minut. V současné době mezi obecné definice při návrhu hierarchického managementu dat patři rychlý disk do oblasti online storage, levné disky SATA do oblasti nearline storage a páska je definovaná jako off-line storage. Obrázek 23 – definice hierarchického managamentu


52

5.2 Realizace řešení Information Lifecycle Management V této kapitole bych rád uvedl tři konkrétní projekty, přičemž jeden se v podstatě z pohledu ILM nestal příliš úspěšným, protože nedošlo u zákazníka k souladu představ o postupném přelívání dat, očekáváním obchodních jednotek a hlavně schopnosti procesů přizpůsobit se požadavku IT na efektivní a rychlé přelévání dočasných dat. Ještě než přejdu ke konkrétním příkladům chtěl bych uvést, že se dnes ILM používá nejčastěji ve dvou oblastech: retence citlivých dat a přesouvání historický starých dat z drahých disků na disky levné. Posledně zmiňované řešení je asi nejrozšířenější a speciálně v bankovním sektoru se používá velmi často.

5.2.1 Retence dat v automobilovém průmyslu Dalším zajímavým řešením ILM implementovaným v České republice je instalace v automobilovém průmyslu, kde zákazník potřeboval implementovat retenční řešení s dlouhodobým uchováváním dat po dobu cca 15 let s tím, že musí být zachován princip nepřepisovatelnosti dat, protože se jedná o účetní dokumenty z prostředí aplikačního balíku SAP. Na základě zhruba definovaných požadavků ze strany zákazníka bylo vybráno jako nejvhodnější zařízení IBM DR550. Jedná se o kompaktní zařízení pro podporu správy dokumentů, především z pohledu jejich archivace, retence na základě předem definovaných podmínek a ochrany před jejich modifikací a smazáním. Jde o kombinaci hardware (především serveru System p s oper. systémem AIX a diskového pole DS4700) a software (především System Storage Archive Manager, dříve Tivoli Storage Manager for Data Retention). Zajímavým konceptem z pohledu ILM je způsob uložení dat na interní diskové pole , které slouží jako cache s kapacitou až 89 TB, kde jsou data primárně uložena, chráněna proti přepisu a zároveň kryptována. Kryptace chrání data pro případ krádeže jednotlivých disků nebo celého zařízení, proti zneužití citlivých informací, v tomto případě účetních. Data mají nastavena příznak nepřepisovatelnosti a tento parametr je odblokován až pokud ILM politika dovolí přesunout data na levnější storage, v případě zmiňovaného projektu přesun na páskové nepřepisovatelné médium. Po migraci dat na pásku je diskový prostor po těchto datech smazán a uvolněn pro další nová data, která jsou pět chráněna proti přepisu. Na základě definovaných požadavků ze strany zákazníka, byly zkonfigurovány tři níže uvedené varianty. Všechny zahrnují tzv. File System Gateway, umožňující přístup taktéž pomocí protokolů CIFS a NFS. 53

Varianty nasazení zařízení DR550: Jedna lokalita, dvojitý nód. „Startovací“ konfigurace, s dvojicí System p serverů, propojených do HACMP clusteru, jedna lokalita, hrubá disková kapacita 12,146 TB, „čistá“ kapacita pro archivovaná data 8,022 TB. Dvě lokality, jednoduchý nód v každé z nich. Dvě vzdálené lokality, v každé z nich jednonódový System p server, zrcadlená disková pole, hrubá disková kapacita 12,146 +12,146 TB, „čistá“ kapacita pro archivovaná data 8,022 +8,022 TB. Dvě lokality, dvojitý nód v každé z nich. Dvě lokality, s dvojicí System p serverů, propojených do HACMP clusteru, hrubá disková kapacita 12,146 +12,146 TB, „čistá“ kapacita pro archivovaná data 8,022 + 8,022 TB.

Na základě těchto variant se došlo ke kompromisu mezi bezpečností a investicí do celkového řešení. Bylo důležité, aby alespoň na lokální úrovni byly data zabezpečena z důvodu pádu komponenty, proto byla vybrána alternativa první a to lokální zabezpečení na úrovni clusteru. Dále pak jsou data na pozadí zálohována na standardní páskové zařízení, jedná se ale o zálohu a ne o ILM přesun dat na levnější prostředky. Pro tyto účely bude do budoucna s největší pravděpodobností určena WORM páska. Nicméně přesun dat na levnější nepřepisovatelné médium

ještě

není

Obrázek 24 – předpokládané finální řešení

definován v ILM politice a projekt se teprve plánuje. Očekávaná politika bude dána podle dvou kritérií: doba

uložení

dat

na

interním diskovém poli 2-3 měsíce využívání

a

dále dat,

četnost kde

se

očekává metrika, že data, která nebudou využívána aktivně po více jak dva měsíce přesunuta

mohou na

být páskové Zdroj: IBM Corporation

zařízení.

54

V současné době je řešení nasazeno v reálném provozu a denně ukládá několik stovek dokumentů, u kterých se očekává životnost po dobu minimálně 15 let pro účely auditovatelnosti. Dalším krokem, kromě nastavení politik ILM je snaha dosáhnout maximálního zabezpečení dat a je navržena implementace druhého klastru v záložní lokalitě a tím vytvoření Disaster Recovery řešení.

5.2.2 Zpracování digitalizovaných dat Společnost IBM uskutečnila ve Fakultní nemocnici Motol první instalaci technologie GMAS (Grid Medical Archive Solution) v Evropě. Ta zajišťuje bezpečnou a pokročilou správu velkých objemů statických dat, která jsou denně generována jednotlivými lékařskými přístroji, jako jsou např. magnetická rezonance, rentgen či počítačová tomografie.

Tato

vyšetření

produkují již téměř výlučně

Obrázek 25 – implementace GMAS

digitální data, a to v rozsahu desítek

gigabajtů

z jednoho

vyšetření. Pilotní

projekt

odstartoval

v prosinci 2007 a zahrnoval dodávku technologie GMAS skládající

se

ze

softwaru

společnosti Bycast a serverů x86 doplněné o implementaci. Technologie ideálním

GMAS řešením

je všech

legislativních a organizačních požadavků,

které

zdravotnická v současné Jedná o

musí zařízení

době se

požadavek

splňovat. především bezpečného


uložení a archivace všech lékařských záznamů o pacientech po dobu 5 let. V některých případech se však data archivují i déle, a to až do doby úplného vyléčení pacienta. To představuje obrovské množství dat, které musí být bezpečně uloženo a u kterého má 55

zdravotnické zařízení povinnost kdykoliv po tuto dobu prokázat jeho vlastnictví a neporušenost. Zatímco běžné technologie neumožňují obnovu velkého objemu dat v reálně krátkém čase, GMAS zajišťuje absolutní dostupnost díky komplexnímu systému, který data nezálohuje, ale rozkopírovává v rámci tzv. mřížky (gridu) na více míst. Každý soubor je také opatřen elektronickým podpisem, který je periodicky v rámci celého gridu kontrolován, takže kdykoliv systém zná aktuální dostupnost a konzistenci dat. Všechna data se v gridu vyskytují minimálně dvakrát, v řadě případů však i vícekrát. Pokud dojde k výpadku disku, pole, switche, celé serverovny nebo jiných částí infrastruktury, začne GMAS automaticky poskytovat data z těch datových úložišť, které právě v danou chvíli umožňují jejich dostupnost. Jednotlivým typům dat je dále možné přiřazovat různé typy chování ILM. Systém ILM definuje parametry souborů a tím určuje, na jakých datových úložištích mají být data uložena, např. krátkodobé soubory na rychlejších discích a naopak málo používané dlouhodobé soubory na pomalejších discích nebo páskách. GMAS pak bez jakéhokoliv zásahu administrátorů přesouvá data z blízkých datových úložišť na vzdálená a z rychlých datových úložišť na pomalejší. Kromě toho také zjednodušuje migraci dat v případě hardwarových zásahů v infrastruktuře, která se realizuje pouze přes grid a je plně automatická. Velmi důležitá je i funkce automatické obnovy dat například v případě poruchy disku, kdy je po výměně disku obnova provedena automaticky bez nutnosti náročného manuálního postupu jak tomu bývá v běžných systémech.

Nody - role v gridu SN - Storage Node Storage node zajišťuje a obsluhuje bezpečné uložení dat na disky a bezpečný přenos uživatelských dat mezi nody clusteru. Ve FNM je navrhován do každé lokality navrhován jeden, který bude spravovat veškerou kapacitu příslušné lokality.

CN - Control Node Control node ukládá a obsluhuje metadata, ovládá ILM politiky, obsluhuje databázi objektů a jejich umístění, kontroluje konzistenci dat, řídí replikace dat a autentizační

56

a topologické mechanismy gridu. Tento Nod obsahuje kritická data a pro FNM jsou navrženy 3 vzájemně replikované Control nody.

GW - Gateway Node Gateway Node poskytuje rozhraní, které využívají externí aplikace ukládající data do gridu. Mezi služby, které je možné využívat patří přístup do exportovaného filesystému NFS nebo CIFS. Zvláštní službou je možnost ukládat / číst data pomocí http volání (put / get / query ). Gateway Node směruje příchozí dotazy a zajišťuje optimální odezvy, na základě geografické topologie a dostupnosti dat v clusteru. Gateway nody mohou být uspořádány buď v uspořádání ‚Redundant GW‘ nebo ‚HA Redundant GW‘. Pro FNM je konfigurována první varianta. Ta vyžaduje dva GW nody na rozdíl od druhé varianty, která vyžaduje specielní licenci a tři nody.

AR - Archive Node Archive node zajišťuje ukládání „offline“ dat dle ILM politiky. Archive node je ‚archive‘ klientem Tivoli Storage Manageru, který obsluhuje páskovou mechaniku. Pro FNM jsou navrženy 2 Admin nody, každý zasílá do Tivoli Storage Manageru data pouze ze své lokality. GMAS lokality jsou ve FNM navrženy jako redundantní (DC/DR), tzn. v nich budou umístěna stejná data.

AD - Admin Node Admin Node server poskytuje administrační rozhraní, monitoring, logování a auditování v topologii clusteru. Dále je zodpovědný za distribuci packages (změny konfigurací, upgrade balíčků atd). Pro FNM jsou navrhovány 2 admin nody. Oba pracují paralelně a jejich činnost se tak zastupuje.

Nody a hardware konfigurace HW konfigurace GMAS je předepsána tak, aby instalace všech vzájemně provázaných služeb OS a GAM byla snadno proveditelná a jasně dokumentovaná. HW konfigurace je založena na IBM serverech x3650 osazených interními disky pro GAM databáze

57

metadat. Fyzické uložení uživatelských dat je realizováno na diskovém poli s využitím disků SATA.

LAN připojení Veškerá komunikace všech nodů je realizována přes LAN, nikoliv přes SAN. Veškerá LAN připojení jsou redundantní. Každý adaptér je duální. Nody mají buď 1 nebo 2 ethernetové adaptéry, resp. 2 nebo 4 porty. Páry portů budou tvořit ‚bondy‘ (team, etherchannel) v režimu failover (nikoliv ‚load balance‘). GW-AD a AR nody mají 4 ethernetové adaptéry, tedy dva bondy, jeden bond slouží pro ‚public‘ (‚external‘, resp. ‚application‘, resp. ‚user‘) přístup, druhý pro interní komunikaci v gridu. Ostatní nody komunikují pouze mezi sebou a to jedním bondem. Při realizaci je nutno dbát na to, aby každý člen bondu komunikoval jinou cestou (přes nezávislý switch), v případě GW-AD a AR nodu bylo navrženo redundanci dále zvýšit tak, že každý člen bude umístěn na jiném duálním adaptéru. Jak bylo řečeno všechny nody komunikují přes jediný bondovaný interface. Výjimku tvoří GW-AD nod a AR nod. Je to dáno tím, že oba jsou ‚dual homed‘, tzn. jeden interface připojuje stávající síť FNM a druhý připojuje dedikovanou síť GMAS. GW-AD nod musí být připojen do obou sítí z důvodu administrace ze sítě FNM a také proto, aby mohl překládat vnitřní adresy GMAS objektů na jména souborů a tato prezentovat do sítě FNM (PACS) sdíleným souborovým systémem. AR nod je připojen do FNM sítě pouze ze strategických důvodů, proto, aby mohl komunikovat s TSM serverem, o němž je rozhodnuto, že bude umístěn mimo grid. Dedikovaná síť se v GMAS terminologii nazývá ‚backplane network‘. Bylo navrženo backplane vytvořit jak v rámci racku, tak v rámci celé lokality, jakož i mezi lokalitami. Bylo rozhodnuto, že řešení s backplane je pro FNM vhodnější, než řešení bez něho. To by totiž vyžadovalo velmi přesné plánování adresace, komplikace při eventuální změně atd. Pro backplane byly stanoveny vlastní IP subnety. Do adresace FNM se tak musí přidat pouze nody GW-AD a AR.

58

SAN připojení a Diskové kapacity Každý nod spravuje nějaké informace. Buď spravuje vlastní uživatelská data, nebo informace o datech (metadata) a o gridu (stav). Pro uložení metadat a stavu vyžaduje GAM poměrně značné diskové kapacity realizované mimo systémové disky. Na serverech IBM x3650 jsou příslušné prostory vytvořeny na interních 300 GB discích (systémové disky mají kapacitu 73 GB). Do SAN jsou připojeny pouze nody, které spravují uživatelská data, tj. nody SN (disky) a TSM (pásky). Každé připojení do SAN bylo navrženo realizovat párem jednoportových HBA. Porty jsou využity v režimu ‚failover‘ (nikoliv ‚load balance‘).

Obrázek 26 – finální implementace GMAS Zdroj: IBM Corporation

5.2.3 Tierovaná storage v bance Poslední projekt, ze kterého jsou zkušenosti z řešení ILM pochází z bankovního sektoru. Příklad uvádím hlavně jako zkušenost z nesprávně nastaveného očekávání a nepřipravenosti na ILM řešení. Zákazník v první fázi očekával implementaci ILM řešení postaveného na přesunu dat z rychlých na levné diskové prostory a další přesunutí dat po jejich aktivní expiraci do archivu na páskové zařízení. Zcela inovativní 59

přístup se očekával právě v automatickém a flexibilním přelévání produkčních dat momentálně nevyužívaných z Fibre Channel disků na disky typu SATA v situaci, kdy je rychlý diskový prostor potřeba pro jinou aplikaci, která bude provádět například uzávěrku dat nebo jiné dávkové zpracování. Následně by pak bylo možné opět odsunutá data vrátit na původní diskové prostory. Návrh řešení byl postaven na virtualizaci diskových prostor, aby přesun dat byl co možná nejrychlejší a bylo možné použít různá disková zařízení s rozdílnou cenou zařízení a od různých výrobců. Projekt byl nakonec implementován ve velmi omezené míře a to jen na úrovni centrálního diskového pole, kde byly oba typy disků Fibre Channel a SATA. Data se na levnou storage přesouvají jen pokud nejsou již klasifikována jako produkční a již se neočekává jejich návrat na rychlý diskový prostor. Problémem se totiž ukázala procesní stránka věci, neboť banka nebyla schopna tak rychle schvalovat přesuny produkčních dat a celkový čas na takovou operaci by se prodloužil na několik dní a tím celá idea o efektivním přesouvání a vracení dat byla vyhodnocena jako nerealizovatelná.

5.2.4 Alternativní technologie pro levné uchovávání dat V posledních měsících IBM uvedla na trh nový produkt nazývaný XIV. XIV je nové diskové pole využívající

Obrázek 27 – XIV

nejnovější technologické trendy, aby splňovalo klíčové současné

i

budoucí

infrastrukturu.

Je

požadavky

založeno

na

na

gridu

informační standardních

Intel/Linux komponent propojených topologií any-to-any na bázi Gigabit Ethernetu. Zlomová XIV architektura přináší vynikající výkonnost, škálovatelnost, dostupnost a spolehlivost. XIV je založeno na SATA discích, na které však aplikuje unikátní paralelní architekturu, cache algoritmus atd., čímž dosahuje výkonnost na úrovni fibre channel diskových

systémů.

Součástí

systémů

je

velmi

jednoduchý management a neuvěřitelně nízké celkové


TCO. To vše jsou základní parametry pro náhradu řešení ILM, tedy distribuovaného uchovávání dat. V rámci této technologie je možné za nízkých nákladů uchovávat data

60

s velmi rychlým přístupem k informacím. V současné době nejsou zatím s tímto produktem v Čechách reálné zkušenosti, ale věřím, že kdyby tento produkt byl dostupný dříve, byl by ideálním řešením pro neúspěšný projekt z kapitoly 5.2.3, protože by nebylo potřeba fyzicky migrovat data z drahých disků na levné přes několik druhů diskových polí. XIV bourá systém tierování storage podle důležitosti dat, která jsou ukládána. Mezi další důležité parametry poskytující náhradu klasického ILM patří: Skvělá spolehlivost, rebuild dat do 30 minut nebo i méně, což probíhá automaticky na základě self-healing mechanismu a unikátní gridové N+1 systémové redundanci. Jednoduchý management je založen na virtualizaci systému, data jsou automaticky rozdělovány na tzv. chunky a redundantně ukládány na všechny disky. Nehrozí nedostatečná výkonnost vlivem špatné logické konfigurace, ta je automatická. Nízká spotřeba energie je až čtvrtinová při stejné kapacitě v porovnání s klasickými enterprise diskovými systémy. Díky unikátnímu designu dosahuje XIV na stejné kapacitě postavené na SATA discích stejné výkonnosti jako tradiční systémy na FC discích při čtvrtinové spotřebě energie. Možnost migrace dat z jiných např. starších diskových systémů přes FC.

TCO – celkové náklady jsou výrazně nižší než u tradičních high-end systémů vzhledem k designu (SATA disky), jednoduchému managementu, nižší spotřebě energie.

5.3 Zhodnocení výsledků a návrhy zlepšení Při implementaci řešení ILM se u zákazníků prokázala výrazná úspora finančních prostředků při správné definici méně používaných dat, která byla postupně přenesena na levnější médium, a to diskové, typu SATA nebo páskové. Pro uchovávání citlivých a auditovatelných dat se osvědčilo retenční řešení typu DR550, které splňuje požadavky na zachování nepřepisovatelnosti dat při využití diskové kryptace. Praxe také ukazuje, že ne vždy jsou očekávání klienta splněna, pokud on sám není schopen přizpůsobit své procesy požadavkům plánovaného ILM řešení.

61

6 Využití virtualizace pro efektivnější dostupnost dat V mnoha společnostech se o virtualizaci začíná mluvit, zvažuje se její nasazení a někde je již tento koncept produkčně používán. Oblast virtualizace se stává zajímavým řešením právě v místech, kde jsou problémy s optimální využitelností stávajícího hardware od různých výrobců a uplatňuje se také tam, kde je nutné efektivně přenášet data mezi jednotlivými zařízením na základě hodnoty a využitelnosti samotných dat. Pokud potřebujete řešení, které dokáže redukovat složitost a náklady na správu ukládání dat v rámci vašich sítí SAN, tak mohou pomoci produkty pro virtualizaci v oblasti ukládání dat. Dnes nabízená řešení pomohou zjednodušit infrastrukturu a optimalizovat využití prostředků pro ukládání dat, a umožní tak firmám rychle se přizpůsobovat proměnlivému prostředí. Virtualizace a efektivní správa ukládání dat pomáhá při budoucím budování prostředí fungujícího na principu On Demand30. V následujících kapitolách uvádím zkušenosti s implementací jak diskové, tak páskové virtualizace.

6.1 Virtualizace disků SAN Volume Controller (SVC) zjednodušuje infrastrukturu pro ukládání dat, neboť umožňuje provádět změny fyzických

prostředků

ukládání

dat

pro

Obrázek 28 – virtualizace disků

takovým

způsobem, který nijak nenaruší chod aplikací. SAN Volume Controller sdružuje kapacitu několika nezávislých diskových systémů různých výrobců pro ukládání dat do jediné z

jediného

společné místa.

paměťové To

vede

ke

oblasti,

kterou

zjednodušení

správy,

lze

spravovat

optimalizaci

využití

a zvýšení dostupnosti aplikací. Řešení formou SAN Volume Controlleru je založeno na tzv. symetrické virtualizaci. V klasickém pojetí sítí pro

SANs Today

Virtualization

SAN

Virtualization Layer

ukládání dat SAN (Storage Area Networks) jsou logické jednotky 30

(LUNs),

On Demand – připraveno k užití na požádání 62

Servers are mapped to specific physical disks i.e., "physical mapping"


Servers are mapped to a virtual disk i.e., "logical mapping"

definované uvnitř diskového subsystému, přímo prezentovány hostitelským serverům. Při symetrické virtualizaci (někdy známé jako bloková agregace či „in-band“ virtualizace) se využívá vyhrazeného zařízení umístěného v datové cestě, které přebírá správu nad jedním či více fyzickými zařízeními pro ukládání dat a nabízí je hostitelským serverům jako „virtuální“ disky. Takto koncipované řešení na bázi blokové agregace přináší pro společnosti tři hlavní výhody:

A. Zvýšení produktivity administrátora určeného pro správu storage Administrátor s využitím integrovaného programového vybavení s grafickým rozhraním může spravovat, přidávat a migrovat fyzické disky bez přerušení z pohledu aplikačních serverů. Z provozního pohledu je možné provádět plánované odstávky, údržbu a zálohování, aniž by došlo k nutnosti přerušení aplikací. Toho je docíleno izolováním pohledu, jakým se dívají servery na logické disky od fyzické prezentace disku storage subsystémů.

B. Společná platforma pro vyspělé kopírovací funkce Na rozdíl od původních kopírovacích funkcí, které mohly probíhat pouze mezi „podobnými“ zařízeními na úrovni jejich kontrolerů, jsou nyní kopírovací služby přesunuty na úroveň SAN. Například vytváření okamžitých kopií (FlashCopy) či vzdálené zrcadlení (PPRC – Peer to Peer Remote Copy) je k dispozici mezi všemi spravovanými heterogenními diskovými subsystémy, což sebou přináší nejen zjednodušení správy těchto funkcí, ale i značné úspory nákladů za jejich nákup k jednotlivým zařízením.

C. Výrazné zvýšení využitelnosti spravované kapacity všech zařízení Nevyužitou volnou kapacitu fyzických disků lze dynamicky realokovat bez přerušení aplikací nezávisle na prostředí operačních systémů a platforem. Logické disky je možné vytvořit a dynamicky měnit nad libovolnými fyzickými disky všech spravovaných storage subsystémů. Toho lze využít k úspoře dalších nákladů tím, že data méně náročných aplikací či aplikací, které dočasně nepotřebují vysoký diskový výkon, mohou být přenesena na levnější fyzické subsystémy. Naopak data, ke kterým je vyžadován

63

rychlý přístup, se přesunou na dražší a výkonnější zařízení podle momentálních požadavků. Využití diskové virtualizace v českých podmínkách je zatím velmi ojedinělé, protože český trh je velmi konzervativní k novým přístupům a využívá spíše klasické metody ukládání dat na samostatná disková pole kde využívá standardní mixování diskových modulů různých typů, velikostí a rychlosti otáček a v případě, že se jedná o zastaralý model vybírá se nové řešení a zastaralé se přesouvá do oblasti vývoje či testování. A přestože využití stávajících zařízení je obvykle jen kolem 50-70 % nebyly doposud zákazníci nijak tlačeni k optimalizaci svých zdrojů a tím i úsporám. Nejobvyklejším rozhodnutím pro implementaci jsou dva důvody. Prvním je realizace virtualizace v heterogenním prostředí, kde zákazník provozuje diskový subsystém jednoho výrobce a chce nasadit druhé zařízení jiného dodavatel s tím, že data chce mít pod jednou správou a bude schopen dělat migraci dat mezi oběma poli. Druhým důvodem a to častějším je využívání diskové virtualizace pro dosažení Business Continuity na bázi Tier 6, kdy zákazník využívá primární diskové pole typu Hi-end31, a přestože buduje záložní lokalitu, nechce investovat značné prostředky do nákupu druhého pole stejného typu (investice cca 20 mil. Kč) a rozhodne se pro midrange typ, kde se investice pohybuje do 5 mil. Kč. Vzhledem k tomu, že zrcadlení mezi dvěma poli různého typu nepodporuje žádný výrobce je nutné přistoupit k implementaci diskové virtualizace, která si s tímto problémem poradí a umožní implementaci s výrazně nižšími investičními náklady s možností neomezeného bezodstávkového růstu celkového řešení.

6.2 Virtualizace pásek Virtualizace pásek je v posledních letech více využívanou technologií než je virtualizace disků. Důvod je jednoduchý, je jím daleko větší přínos pro firmu a pro dostupnost dat než je tomu u klasické diskové virtualizace. Hlavními důvody pro nasazení virtualizace pásek je úspora času pro zálohování dat a o to více případná obnova zálohovaných dat, kdy každá minuta, kdy jsou ztracená data nedostupná přináší firmě velké finanční ztráty. Dalším důvodem je efektivní využívání páskových médií. Principem páskové virtualizace je zálohování dat na diskový systém, který se navenek

31

diskové pole nejvyšší třídy s dostupností minimálně 99,99 % 64

propaguje jako pásková knihovna, mechanika nebo virtuální páska. V dnešní době se používají dva druhy virtualizování páskových zařízení.

Virtualizace pro mainframe Prvním je virtualizace pro servery typu mainframe, kde zařízení funguje jen jako cache, která má kapacitu několik málo terabytů, do které zálohovací aplikace ukládá data. Na pozadí, kdy je ukončen zálohovací proces pak dochází k přesunu dat na páskovou knihovnu a v cache zůstávají data jen pro potřeby rychlé obnovy. S odstartováním dalšího zálohovacího procesu se data v cache přepisují daty novějšími. Dalším úkolem této virtualizace je zajišťovat, aby využitelnost páskových médií byla co největší, takže pokud

zálohy

na

páskách postupem času

Obrázek 29 – mainframová virtualizace pásek

expirují, zařízení si tyto málo

využitá

překopíruje

média

zpět

do

cache a setřídí. Potom jsou optimálně seřazená data opět přesunuta na pásku, která se stane využitou na 100%. Mainframe virtualizace je

u

nás

nasazena

u zákazníka, který má dvě zařízení zrcadlená přes

dva


kontinenty

a využívá 3 TB diskové kapacity jako cache. Na pozadí jsou pak data ukládána prostřednictvím páskové technologie Jaguar na páskového robota. Z finančního hlediska je tento způsob nejdražším, i když nejbezpečnějším, zálohováním dat a cena se pohybuje v desítkách milionů korun.

Virtualizace pro otevřené systémy

65

Druhá virtualizace je určena pro ostatní otevřené platformy jako jsou systémy typu Unix, Windows a Linux. V tomto případě funguje virtualizace trochu jiným způsobem. Stejně jako v prvním případě jsou data zálohována na virtualizační jednotku, která se propaguje

jako

Obrázek 30 – virtualizace pro otevřené systémy

páskové zařízení, ale zde již data zůstávají a není nutné je dále přesouvat Z tohoto

na

pásku.

důvodu

kapacita

je

cache

v desítkách TB, aby bylo možné zachovávat několik záloh a obnova všech

souborů

rychlá okamžik

byla

v jakýkoliv


ztráty

primárních dat. I přesto je uživatelům k dispozici funkce pro překopírování dat na páskové médium, ale to se používá především jen jako druhá záloha dat, která je přenesena na bezpečné místo, jako je třeba trezor. Řešení je možné postavit jako zrcadlené a to buď lokálně nebo i na velkou vzdálenost na sekundární zařízení. Pro účely bezpečnosti je vhodné využít kryptování dat přenášených na druhé zařízení, aby se předešlo zneužití citlivých dat klienta. V České republice je tento typ virtualizace nasazen u bankovního zákazníka, který se rozhodl implementovat virtualizaci v roce 2007. V dnešní době má tímto způsobem zálohováno již více jat 10 TB dat a plánuje další rozšíření. Protože se jedná o bankovní společnost, kde je kladen velký důraz na bezpečnost, je celá technologie lokálně i vzdáleně zrcadlena.

Klient hodnotí přínos nasazení především v úspoře času

vyhraženého pro zálohování a to až o několik hodin.

66

7 Strategie a vývoj Dostupnost dat a technologie k tomu určené se neustále vyvíjejí a výrobci hardware nebo software přicházejí s novými způsoby jak zajistit co nejlepší dostupnost informací. Technologie se nezaměřují pouze na dosahování vyššího výkonu, vyšší bezpečnosti či nekonečné kapacity, ale jsou to také zcela nové strategické postupy. Dnes není problém vytvořit petabytové pole nebo páskovou knihovnu o stovkách mechanik, kde všechno pracuje na bázi 8 Gb Fibre Channel technologie. Problém je především v úspoře peněz a v efektivnosti využití zdrojů. O aspektu efektivnosti se zmiňuji právě v době, kdy všichni výrobci začínají mluvit o tzv. „zelené planetě“ tedy o šetrném zacházení se zdroji, které lidstvo má k dispozici. Investuje se velké množství prostředků do zařízení, která mají menší spotřebu elektrické energie, spotřebovávají daleko méně tepla a také zabírají méně místa.

Deduplikace dat Jedním z nejnovějších trendů, který se snaží efektivně řešit problematiku velkého objemu zálohovaných dat je deduplikace. S tímto konceptem přišla izraelská firma před několika lety. Tehdejším cíle jejich odborníků bylo zjistit, jestli je potřeba opravdu ukládat všechna data, tak

Obrázek 31 – schéma řešení deduplikace

jak jsou nebo jestli je možné uspořit místo jen pro to co je důležité. Matematičtí experti přišli se zjištěním, že v každé firmě se nachází velké množství dat, která jsou uložena dvakrát, třikrát i vícekrát. Vznikl tedy software pro zálohování dat

a

posléze

k němu

i hardwarové řešení, které


je schopno tyto duplicity najít a eliminovat je. Proces probíhá za online provozu, kdy na diskové pole, které se

67

chová jako virtualizovaná páska jsou ukládána data jen jednou a pokud se vyskytuje jejich duplicita na pole se uloží už jen odkaz na primárně pořízená data. Tento odkaz je o velikosti jen několik byte. Uživatel pokud potřebuje využít tímto způsobem uložená data pak přistupuje pouze k jednomu obrazu dat. Na základě analýzy, která byla provedena u zákazníků z různých oblastí se zjistilo, že nasazením konceptu deduplikace došlo k obrovských úsporám a to až k 22 násobnému snížení kapacity potřebné pro zálohování dat. Hlavní oblastí úspor je zálohování mailových schránek a datových skladů, kde se data velmi často opakují. Tabulka 2 – úspory dat při použití deduplikace

Původní zdrojová data v TB

Fyzická využitá kapacita v TB

Telekomunikace

190

13

Prodej firmy

880

40

Finanční sektor

850

50

Výrobní sektor

450

37


Typickým klientem vhodným pro nasazení deduplikace je společnost, která provádí každý den plnou zálohu dat a data se od poslední zálohy změní pouze v objemu 10 až 20 %. V současné době jsou u nás již realizované úspěšné projekty deduplikace dat, které přinesly očekávanou úsporu kapacit a zároveň s minimálním dopadem na obnovu dat ze záloh.

On Demand kapacita Posledním konceptem, o kterém se chci zmínit je On Demand kapacita, avšak jiným způsobem než tomu bylo v předešlých letech, kdy se jednalo jen o zdroje připravené k rychlému použití. Někteří dnešní klienti si pod tímto pojmem představují nejen připravenou kapacitu navíc, ale především flexibilní měsíční platbu jen za využívanou kapacitu s možností okamžité aktivace další, s automatickým navýšením platby. Hlavním důvodem je přesun odpovědnosti za rozšiřování zdrojů na dodavatele technologie a za druhé, efektivnější plánování finančního rozpočtu klienta s konkrétním rozpočtením na jednotlivé projekty či provozované systémy, které ukládají data.

68

8 Závěr Ve své diplomové práci jsem pojednával o kritické dostupnosti dat pro dnešní podnikovou sféru. Zaměřil jsem se na představení pokročilých technologií, které se používají pro zabezpečení vysoké dostupnosti dat. V samostatné kapitole jsem poskytl ucelený pohled na kryptování citlivých dat na jednotlivých typech hardware. Nedílnou součástí mé práce bylo především využití vlastních zkušeností z působení v tomto oboru již po dobu 9 let ve společnosti IBM, kde jsem se zúčastnil návrhu a implementace projektů pro největší české a mezinárodní zákazníky. Zkušenosti, které jsem v práci použil jsou jak z projektů Business Continuity, ILM tak virtualizace a různých konceptů zálohování dat. Zkušenosti, které jsou promítnuty v jednotlivých kapitolách jsou i na závěr každé z nich zhodnoceny a vyzvednuty ty nejdůležitější aspekty těchto řešení a poznatky z jejich zavádění a provozu. Hlavní význam mé práce a splnění jejího cíle spatřuji v prezentaci zkušeností z implementací náročných a zajímavých projektů, které v dnešní době řeší naprostá většina firem, kde se ukládají data a kde si uvědomují, že podniková data jsou to nejcennější, kromě samotných zaměstnanců, co mají a co si nemohou dovolit ztratit. Práce může také posloužit lidem pro plánování a návrh Business Continuity a ILM řešení v konkrétní firmě a vyhnout se chybným krokům. Součástí mé práce bylo také pojednání o virtualizaci dat, především pak z projektů virtualizace zálohovaných informací, kde se ukazuje velký přínos při zkracování doby provádění záloh dat a ještě více při jejich obnově. Posledním úkolem práce bylo ukázat nové možnosti a strategii v dosahování dostupnosti dat, kde jedním z nejzajímavějších konceptů je deduplikace dat, která je schopna firmám umožnit výrazné úspory finančních prostředků při pořizování storage zařízení a zároveň zefektivnit zálohovací procesy.

69

9 Seznam použité literatury 9.1 Knihy Charlotte Brooks, Clem Leung, Aslam Mirza, Curtis Neal, Yin Lei Qiu, John Sing, Francis TH Wong, Ian R Wright. IBM System Storage Business Continuity: Part 1 Planning Guide. Březen 2007. SG24-6547-03 Charlotte Brooks, Clem Leung, Aslam Mirza, Curtis Neal, Yin Lei Qiu, John Sing, Francis TH Wong, Ian R Wright. IBM System Storage Business Continuity: Part 2 Solutions Guide. Únor 2007. SG24-6548-00 Bert Dufrasne, Wilhelm Gardt, Jana Jamsek, Peter Kimmel, Jukka Myyrylainen, Mrkus Oscheka, Gerhard Pieper, Stephen West, Axel Wstphal, Roland Wolf. IBM System Storage DS8000: Copy Services in Open Environments. Květen 2008. SG24-6788-03 Charlotte Brooks, Aslam Mirza, John Sing. IBM System Storage Business Continuity Solution Selection Methodology. Duben 2007. REDP-4062-01 Babette Haeusser, Alessio Bagnaresi, Michael Bocian, Rik Foote, Abbe Woodcock. Guide to Data De-duplication: The IBM System Storage TS7650G ProtecTIER Deduplication Gateway. Listopad 2008. SG24-7652-00 Bertrand Dufrasne, Frank Boerner, Deeporn Beardsley, Torsten Protze, Alexander Safonov, Rene Wuellenweber. IBM System Storage DR550 V4.5 Setup and Implementation. Červenec 2008. SG24-7091-05 Babette Haeusser, Alex Osuma, Christian Bosman, Dirk Jahn, Giulio John Tarella. ILM Library: Information Lifecycle Management Best Practices Guide. Leden 2007. SG247251-00 Charlotte Brooks, Frank Byrne, Leonardo Higuera, Carsten Krax, John Kuo. IBM System Storage Solutions Handbook. Říjen 2006. SG24-5250-06 Všechny dostupné na: http://www.redbooks.ibm.com IBM Česká republika spol. s r.o., Praha. Interní materiály. 2006-2009 David Kolenatý, Bakalářské práce: Datová úložiště a SAN Infrastruktura. Duben 2007

70

10 Seznam obrázků Obrázky Obrázek 1 – switch Nexus

10

Obrázek 2 – funkce FlashCopy

14

Obrázek 3 – funkce FlashCopy Space Efficient

15

Obrázek 4 – zrcadlení dat Metro Mirror

16

Obrázek 5 – zrcadlení dat Global Mirror

16

Obrázek 6 – modelové nasazení konceptu 3-stranného zrcadlení

17

Obrázek 7 – základní obrázek Business Continuity

20

Obrázek 8 – úrovně řešení Business Continuity

22

Obrázek 9 – cílový stav po II. etapě

30

Obrázek 10 – cílový stav po III. etapě

31

Obrázek 11 – struktura SAN

35

Obrázek 12 – vnitřní schéma diskového systému DS8000

36

Obrázek 13 – návrh rozložení logických polí

37

Obrázek 14 – schéma toku dat při LAN-Free

43

Obrázek 15 – DRM implementace

44

Obrázek 16 – DRM mechanismus rotace pásek

45

Obrázek 17 – původní návrh řešení zrcadlení na velkou vzdálenost

46

Obrázek 18 – finální návrh implementace Global Mirror

47

Obrázek 19 – model ILM

48

Obrázek 20 – klasifikovaná storage

49

Obrázek 21 – klasifikovaná storage dle úrovně

49

Obrázek 22 – hodnota dat v závislosti na jejich stáří

51

Obrázek 23 – definice hierarchického managementu

52

Obrázek 24 – předpokládané finální řešení

54

Obrázek 25 – implementace GMAS

55

Obrázek 26 – finální implementace GMAS

59

71

Obrázek 27 – XIV

60

Obrázek 28 – virtualizace disků

62

Obrázek 29 – mainframová virtualizace pásek

65

Obrázek 30 – virtualizace pro otevřené systémy

66

Obrázek 31 – schéma řešení deduplikace

67

72

11 Seznam tabulek Tabulky Tabulka 1 – způsob ochrany jednotlivých typů databází

38

Tabulka 2 – úspory dat při použití deduplikace

68

73

Ukládání dat se zaměřením na jejich dostupnost

Recommend Documents