CO SE MŮŽE POKAZIT, TO SE TAKY POKAZÍ
ZÁKLADNÍ MURPHYHO ZÁKON Pokud na vaší službě závisí klíčová aktivita, reputace, nebo dokonce finanční zisky společnosti, je vždy nutné mít pro případ její nedostupnosti připraven plán „B“. Takovýmto plánem „B“ se v prostředí ICT stává Disaster Recovery řešení. Slovo „disaster” (angl. havárie, neštěstí, pohroma) nemusí vždy znamenat pouze fatální katastrofy spojené s požárem, povodní a podobnými živelními událostmi, byť mohou být důsledkem jejich působení ve více či méně vzdáleném okolí. Může se jednat o poruchu klimatizace, delší přerušení dodávky elektrické energie apod. Disaster Recovery (DR) řešení je budováno jako záložní prostředí pro případ, že nebude možné z jakéhokoli důvodu používat primární IT pracoviště (nebo jeho část) a bude nutné zajistit provoz klíčových IT služeb v náhradních podmínkách. Jedná se o ty IT služby, které jsou pro chod organizace nezbytné, nebo jejich výpadek implikuje rozhodující snížení produktivity, zisku, vnímání organizace apod. Je mnoho aktivit podporovaných IT službami, které je možné procesně nahradit po určitou dobu manuálními postupy bez podpory IT, ale některé interní nebo externí procesy nahradit nelze (e-shopy, podnikové ERP systémy, řízení výroby apod.). HP Solutions #5
1/5
Poznámka autora: V této souvislosti vzpomínám na povodně v Praze v roce 2002, kdy DR řešení dodávané společností HP umožnilo téměř nepřerušenou dodávku služeb kritického bankovního systému poté, co byla přerušena dodávka elektrické energie do jednoho datového centra a zároveň nebylo ani možné zásobit datové centrum pohonnými hmotami pro dieselový generátor.
Vlastníkem DR řešení se stává obchodní oddělení společnosti Každá organizace spravující své vlastní IT si musí položit následující otázku: Jaké je finanční vyjádření výpadku jednotlivých IT služeb? Kolik finančních prostředků musí společnost vynaložit v případě jejich výpadku, resp. kolik finančních prostředků nezíská v případě výpadku některé IT služby. Pokud není organizace schopna ohodnotit ztrátu finančními prostředky, je možné se pro DR řešení rozhodovat na základě dalších kritérií, kterými jsou ztráta prestiže organizace, omezení služeb poskytovaných uvnitř a vně organizace, možná ztráta pozice na trhu, ale i riziko dalších nepřímých nákladů spojených s postihem za neplnění smluvních podmínek svým odběratelům.
Jak přistoupit k budování DR řešení? V první řadě je nutné definovat dva základní parametry DR řešení: Recovery Time Objectives (RTO) a Recovery Point Objectives (RPO). RTO parametr definuje, za jak dlouho po výpadku bude služba v záložním centru dostupná, parametr RPO, jakou ztrátu změnových dat jsme schopni tolerovat v případě nutnosti přesunu služby do záložní lokality.
HP Solutions #5
2/5
Obecný požadavek obchodní části organizace (té části organizace, která realizuje hlavní obrat) je, aby oba tyto parametry byly co nejmenší, tedy limitně se blížily k nule. Je zřejmé, že takovéto řešení je adekvátně nákladné k velikosti IT. Opačný extrém je přístup, kdy DR řešení není třeba budovat vůbec, a náklady na toto řešení jsou nulové. V tomto případě ztráta výpočetního střediska (datového centra) znamená kompletní náhradu IT na „zelené louce“, což může v mnoha případech znamenat projekt na několik týdnů či měsíců. Během této doby budou pracovníci organizace komunikovat pomocí gmailu, Facebooku apod. Jistě se shodneme na tom, že vhodné DR řešení nereprezentuje ani jedna z těchto krajních variant a jeho konečná podoba bude výsledkem rozumného kompromisu. Jak se ale k němu dostat? Jde o to najít vyvážené řešení, jehož vybudování a provoz nestojí více než obchodní ztráta způsobená případným výpadek IT služby. Pro různé typy organizací a samozřejmě i rozdílné IT služby v rámci jedné organizace jsou požadavky na obnovení služby rozdílné. Jiné požadavky na DR řešení budou mít systémy, které zajišťují on-line komunikaci se zákazníky (zákaznické portály, expediční systémy, podpora výroby v reálném čase apod.), jiné požadavky budou mít systémy podporující interní funkce organizace. Jiné požadavky bude mít menší organizace zaměřená na poskytování služeb, jiné výrobní podnik a jiné velká finanční organizace.
Projekt DR řešení není projektem IT oddělení, ale – a to je důležité si uvědomit – projektem organizace jako celku. Vlastníkem (moderně řečeno sponzorem) DR projektu by měl být ten, kdo řídí organizaci obchodně. Ten má přehled, kolik zisku organizace vytvoří (nebo nevytvoří v případě výpadku IT služby) za jednotku času, jaká je míra rizika ztráty pozice na trhu v důsledku nedostupnosti služby atd. Vyjádřeno ekonomicky, jaké jsou tedy rozpočtové hranice DR projektu. Takto se DR řešení stává součástí daleko většího celku, tzv. Business Continuity Planning - plánování nepřerušené obchodní činnosti.
Co vše je nutné pro DR řešení zajistit?
HP Solutions #5
1. Finanční zhodnocení rizik 2. Umístění záložního střediska V prvé řadě je nutné ohodnotit rizika provozu IT v dané lokalitě a zvolit umístění záložního střediska. Vzdálenost mezi dvěma oddělenými středisky se může pohybovat od několika set metrů v případě umístění sálů výpočetní techniky do dvou samostatných budov v rámci areálu až po několik set kilometrů. Pro DR řešení je nutné, aby kompletní ztráta jedné lokality (budovy) neohrozila provoz IT ve středisku se záložními systémy. 3. Replikace dat Další nutnou podmínkou je zajištění spolehlivého přenosu (replikace) dat z primárního do záložního centra. Typ replikace dat je klíčový zejména s ohledem na požadavek RPO. Čím je parametr RPO menší, tím sofistikovanější a spolehlivější musí být použitá replikace. V případě RTO a RPO v řádu jednotek hodin plně postačuje pravidelné zálohování na zařízení mimo primární středisko eventuálně dvojice deduplikačních zálohovacích zařízení s nastavenou automatickou replikací záloh do vzdálené lokality. Čím je požadavek na RTO a RPO nižší, tím je nutné uvažovat o sofistikovanějších řešeních ať už replikace na úrovni operačního systému, diskových polí, nebo replikace pomocí vlastní aplikace (databázové systémy, replikované souborové systémy apod.) 3/5
4. Administrace DR řešení Neméně důležitou otázkou je, jakým způsobem bude DR řešení administrováno. Požaduje organizace plně automatizované řešení, které zajistí automatický přechod služby v případě výpadku, nebo bude přepnutí do záložní lokality prováděno výhradně administrátorem systému? Jakým způsobem bude zajištěno převedení služby zpět do primární lokality? Jak náročný je tento zpětný převod? Tyto a celou řadu dalších otázek je nutné zodpovědět na začátku tvorby technického designu DR řešení.
5. Koordinace
6. Testování
Podmínkou nutnou pro provoz systémů na více systémech, kde jeden systém nahrazuje druhý, je spolehlivá ochrana proti tzv. „Split Brain“. Jde v podstatě o to, že stejná služba nesmí být aktivována najednou v obou lokalitách. V opačném případě může dojít k vážnému poškození konzistence dat, které může vést až k nutnosti obnovy dat ze zálohy a tím k daleko větším časovým ztrátám.
V neposlední řadě je nutné DR řešení pravidelně testovat. Procesy testování slouží nejen k ověření funkčnosti celého řešení, ale zajistí i schopnost personálu s tímto řešením pracovat a efektivně jej spravovat.
Disaster Recovery v praxi Implementace podnikového systému SAP v realitní kanceláři (Ostravsko) Systém SAP v sobě obecně zahrnuje celou řadu modulů pro podporu aktivit pro různé typy organizací. V okamžiku, kdy se organizace rozhodne zavést automatizaci některých procesů na SAP, je tento systém klíčový, neboť je na něj navázána zpravidla celá řada aktivit od řízení skladového hospodářství, přes správu majetku po finanční systémy apod. Podnikový systém je provozován ve dvou lokalitách ve vzdálenosti cca 10 km. Replikace dat je prováděna pomocí zrcadlení diskových prostorů v prostředí operačního systému. V primární lokalitě je provozován produkční systém, v záložní pak vývojový a testovací systém. Zajištění nekolizního provozu je ošetřeno pomocí skriptů, které nedovolí spustit SAP v případě, že je aktivní na druhém systému. Investice do DR řešení nebyla v tomto případě příliš vysoká, neboť se jako záloha produkce využil vývojový a testovací server. Za účelem navýšení výkonu záložního serveru pro produkční účely je možné vývojovou a testovací instanci na nezbytně nutnou dobu zastavit. Výrobní podnik (Pardubicko) Zdejší IT oddělení poskytuje služby jednak přímo lokálnímu závodu, jednak ostatním závodům rozmístěným v jiných zemích od Asie po Ameriku. Z tohoto důvodu je téměř nepřetržitá dostupnost vybraných IT služeb nutností. Pro zajištění odpovídající úrovně dostupnosti bylo vybudováno clusterové prostředí pracující v režimu extended campus cluster. Geograficky se jedná o párovou instalaci, kdy je každý samostatně provozovatelný výpočetní celek (servery, diskové pole a podpůrná infrastruktura) umístěn v jedné budově a propojen pomocí SAN a LAN s ekvivalentním celkem v budově druhé. Replikace dat je prováděna pomocí zrcadlení diskových prostorů, čímž je zajištěna téměř nulová hodnota parametru RPO. Parametr RTO se pohybuje díky plně automatickému přepínání pomocí clusterového softwaru v řádech jednotek minut. Ani zde nedošlo k výraznému navýšení investice, neboť systémy pro lokální IT tvoří „teplou“ zálohu pro HP Solutions #5
4/5
systémy korporátní a obráceně. Díky virtualizačním technikám je umožněn na tomtéž fyzickém serveru provoz samostatné vývojové instance. Vzhledem ke kritičnosti provozovaných systémů a malé vzdálenosti výpočetních center (několika set metrů) je pro případ ztráty celého závodu a tím i lokálního IT nastaven replikační tok na úrovni databázového systému do dalšího datového centra vzdáleného cca 1500 km. Případné přepnutí provozu do této vzdálené lokality je však řešeno již výhradně manuálně zásahem administrátorů.
Mezinárodní finanční organizace Současný trend prodeje služeb se stále více orientuje na on-line služby přes internet. Výpadek takové služby má potom přímý dopad na obchodní výsledky společnosti. Ve finančních organizacích typu pojišťovny se nejedná pouze o podporu vnějších služeb, ale je nutné zajistit i vnitřní potřeby firmy a poskytování informačních služeb zaměstnancům organizace pracujícím lokálně na pobočkách, nebo mobilním pracovníkům přímo v terénu. Z tohoto důvodu bylo vybudováno metroclusterové řešení zahrnující více než jednu desítku serverů umístěných ve dvou lokalitách vzdálených cca 25 km. Synchronní replikace dat je prováděna bez účasti operačního systému přímo na úrovni diskových polí. Clusterový SW doplněný o moduly pro práci s diskovými poli zajišťuje nepřetržitý monitoring dostupnosti infrastruktury (SAN, LAN, storage) a IT služeb na úrovni aplikace. V případě zjištění výpadku provádí automatické korekce (restart služby), případně převedení služby na náhradní komponentu včetně automatického převedení služby do záložního centra v případě nutnosti. Na serverech v záložní lokalitě jsou v nominálním stavu provozovány předprodukční (akceptační, testovací) systémy, jejichž provoz je automaticky ukončen v okamžiku převedení produkce na záložní server. Tímto jsou do jisté míry ochráněny investice do nákupu HW a SW pro záložní lokalitu.
Systém provádí v případě zjištění výpadku restart služby
Závěrem Rozhodnutí o vybudování DR řešení není záležitostí pouze IT oddělení, ale hlavní roli zde hraje především obchodní strategie firmy. Bez této podpory je jeho realizace obtížná a může ve svém důsledku znamenat i neefektivní vynakládání investičních prostředků. Problematika DR řešení se netýká jen velkých organizací. Tým specialistů HP je připraven poskytnout konzultační a implementační služby na požadované úrovni a nalézt vyvážené DR řešení pro každý typ organizace, od malé až po velkou. Naším cílem je poskytnout odpovídající spolupráci jak při tvorbě řešení, tak při jeho implementaci a v neposlední řadě při jeho trvalé podpoře.
Vizitka autora
Milan Mazáč Infrastructure Solution Architect, HP TS Consulting
Milan má za sebou třicetiletou praxi v oblasti budování a provozu kritických informačních systémů. Své zkušenosti získal jednak ve společnostech PVT a DNS, a zejména pak za svého více než desetiletého působení ve státní správě při budování celostátních informačních systémů. V HP působí od roku 2000 jako technický HP Solutions #5 konzultant a architekt pro IT infrastrukturu se zaměřením na vysokou
dostupnost, DR řešení, zálohování a storage. V této oblasti dodává ročně několik projektů od malých až po velká podniková řešení. Milan vystudoval obor elektronické počítače na Elektrotechnické fakultě ČVUT v Praze, kterou absolvoval v roce 1983. Žije s rodinou poblíž Prahy a ve svém volném čase se věnuje rekreačnímu sportu, fotografování, hudbě a jako člen Českého včelařského svazu i aktivně včelaří.
LinkedIn: http://cz.linkedin.com/in/milanmazac
5/5
