Vysoká dostupnost a zotavení z katastrofy pro podnikové IS

Rozměr: px
Začít zobrazení ze stránky:

Download "Vysoká dostupnost a zotavení z katastrofy pro podnikové IS"

Transkript

1 Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování Vysoká dostupnost a zotavení z katastrofy pro podnikové IS Diplomová práce Autor: Bc. Jan Suchý Vedoucí práce: Ing. Vladimír Beneš Praha Duben, 2009

2 Prohlášení Prohlašuji, že jsem diplomovou práci zpracoval samostatně a s použitím uvedené literatury. V Praze dne 14. dubna 2009 Jan Suchý

3 Anotace práce Obsahem této práce je seznámení s problematikou nasazování informačních systémů a realizace potřebné IT infrastruktury pro jejich provozování s ohledem na vysokou dostupnost služby a zotavení z případné katastrofy. Tato diplomová práce porovnává možné návrhy realizace infrastruktury a analyzuje cenovou hladinu pro dosažení jednotlivých úrovní vysoké dostupnosti, včetně rozboru klíčových komponentů návrhu. Trend požadavků na výkonnost a dostupnost vede k instalaci dalších serverů, které jsou stejně tak, jako již instalované servery neefektivně využívané. V práci uvádím praktické příklady, jak by mělo být postupováno s ohledem na efektivní využívání zdrojů hardwaru směrem je konsolidaci IT infrastruktury. Konsolidace serverů s použitím virtualizace je jediným možným konceptem jak udržet IT infrastruktury v ekonomicky výhodném provozu. The document contains introduction how to roll-out information systems and best practises with IT infrastructure solution as well as high availability and disaster recovery design. There is also included comparison among possible infrastructure designs and analyzes from price levels point of view by particular solutions and components. Current trend in performance requirements and availability will demand a new server s installation. But all servers are typically underutilized in common operation. The examples of process how to effectively utilize hardware are based on real life experience. And trend towards IT consolidation is also shown. Server consolidation mostly based on virtualization technology is the only way how to run IT infrastructure effective from financial point of view. Helps as well significantly form manageability and facility point of view as well.

4 Obsah 1 PROBLEMATIKA ZAJIŠTĚNÍ DOSTUPNOSTI SLUŽBY VYSOKÁ DOSTUPNOST PRO APLIKACE VYSOKÁ DOSTUPNOST PRO DATA VYSOKÁ DOSTUPNOST PRO IT INFRASTRUKTURU 8 2 PRINCIPY VYSOKÉ DOSTUPNOSTI VYSOKÁ DOSTUPNOST PŘÍKLADY REALIZACÍ JEDNOTLIVÝCH SLA SLA 99 % SLA 99,9 % SLA 99,99 % SLA 99,999 % Zhodnocení ZOTAVENÍ Z KATASTROFY Možné varianty DR řešení Třída Třída Třída EFEKTIVNÍ VYUŽÍVÁNÍ HARDWAROVÝCH ZDROJŮ VIRTUALIZACE SERVERŮ Přehled vizualizačních technologií Vhodnost jednotlivých konceptů VIRTUALIZACE PRO DATA Virtualizace pro disková úložiště Virtualizace pásek BEZPEČNOST VIRTUALIZACE PRO SERVERY A DATOVÁ ÚLOŽIŠTĚ Nejdůležitější bezpečnostní úskalí u serverů Bezpečnosti na úrovni virtuálních serverů Bezpečnost při zálohování ve virtuálním prostředí Kontinuita provozu na virtuálních serverech 45 4 APLIKAČNÍ HOSTING A OUTSOURCING POSKYTOVANÉ SLUŽBY ICT KOMPLETNÍ SLUŽBY ICT NEPŘETRŽITÁ BYZNYS PODPORA 49 5 DATOVÁ CENTRA A IT KONSOLIDACE STRATEGIE PROVOZOVÁNÍ APLIKACÍ A DAT V DATOVÉM CENTRU 50 4

5 5.1.1 Rozdělení aplikací Profily pro nasazení aplikací INFRASTRUKTURA Řízení nákladů na energie Užívání energií v DC KONSOLIDACE Centralizace systémů IT Analýza klíčových aplikací Standardizace aplikací Infrastruktura společností Konsolidace serverů STRATEGIE NASAZENÍ APLIKACÍ Kritické aplikace Třída 1 a Licenční politika Příklad nasazení aplikace SAP R/ UKLÁDÁNÍ DAT A ZÁLOHOVÁNÍ 67 ZÁVĚRY A DOPORUČENÍ 70 SEZNAM POUŽITÉ LITERATURY 72 SEZNAM OBRÁZKŮ A TABULEK 73 5

6 Úvod Uživatelé ICT technologií dnes očekávají trvale dostupnou službu, kterou jsou zvyklí používat kdykoliv mají potřebu. Pokud některá služba není dostupná tak to vnímají jako určitou újmu. Představte si, že nebude fungovat síť mobilního operátora, nebo připojení k internetu v okamžiku, kdy je nejvíce budete potřebovat. Problematika dostupnosti služby je tedy nejdůležitější úkol ICT odborníků. Principy vysoké dostupnosti jsou závislé na požadavcích a možnostech, které jsme ochotni za vysokou dostupnost zaplatit. Pokud vyžadujeme nepřetržitý provoz, projeví se to s největší pravděpodobností v nákladech a ceně za danou službu. Je tedy na místě zvážit jaké jsou naše skutečné požadavky. Vysoký počet různých služeb, které vyžadují rozdílnou infrastrukturu pro vlastní provoz s ohledem na dostupnost a požadavky klientů, vede k rapidnímu nárůstu počtu komponentů, ze kterých je ICT infrastruktura sestavena. Efektivita využívání zdrojů je pro každý systém různá, ale v celkovém pohledu je velmi nízká. Množství různých málo vytěžovaných systémů pak vede uživatele k myšlence hostování aplikací v datovém centru, nebo se kloní k úplnému outsourcingu svých ICT služeb. Uživatelé služeb pak svoji aktivitu soustředí na oblast jejich hlavní obchodní činnosti. Vedlejším efektem je racionální využívání ICT infrastruktury, která je poskytovaná profesionální společností pro více zákazníků najednou. Datová centra s větším počtem různých systémů jsou potřeba navrhovat s myšlenkou dlouhodobého efektivního provozu. Správná strategie nasazování aplikací na konkrétní platformy pak umožní využívání virtualizačních konceptů a efektivně tak využívat hardwarové zdroje poskytované ICT infrastrukturou. Konsolidace ICT infrastruktury je současným trendem k získání efektivního, energeticky úsporného a hlavně ekonomického provozování ICT služeb. Vybudování Green IT je cílem mnoha firem, které se více či méně stali úspěšné v konceptu nasazování špičkových technologií k dosažení energeticky efektivní infrastruktury. 6

7 1 Problematika zajištění dostupnosti služby Volbou správné strategie osazování datového centra vhodnou infrastrukturou a technologií pro aplikace lze předcházet značným problémům s vlastním provozem. Důležité pro vhodný návrh je dostatek informací o provozovaných aplikacích, jejich datech, požadavků na dostupnost SLA 1 a především další rozvoj po stránce nárůstu požadovaného výkonu a kapacity dat. 1.1 Vysoká dostupnost pro aplikace Celkový návrh splňuje prvky vysoké dostupnosti, pokud jsou zabezpečeny následující podmínky. Veškeré komponenty jsou zcela redundantní. Komunikace mezi jednotlivými částmi probíhá po dvou nezávislých cestách přičemž, pro případ havárie některého z funkčních celků nebo je vždy k dispozici druhý, který převezme jeho funkci. Aplikace jsou automaticky spouštěny na záložním hardware po vyhodnocení nedostupnosti služby na primárním systému. Rychlost přesunu je závislá na povaze aplikace a její schopnosti pracovat ve vysoko dostupném prostředí. Existují aplikace s vestavěnou funkčností, kdy se přesun na záložní hardware uskuteční okamžitě a bez výpadku. Dále jsou aplikace, které to dokážou v rekordně nízkém čase, řádově několik sekund a následuje největší skupina aplikací, které takové vlastnosti nemají a tak je nutné je zajistit náhradním softwarem. Hovoříme o cluster softwaru, který doplňuje operační systém hostující danou aplikaci. Cluster software monitoruje a kontroluje důležité komponenty na straně serveru tzv. Heart Beat 2, tedy kontrola životních funkcí serveru a ověření funkce po společných komunikačních linkách na více úrovních (RS232, LAN, SAN, atd.), dále důležité části operačního systému a klíčové části samotné aplikace. Hlavní funkcí cluster softwaru je monitorování a provedení polo nebo plně automatické zásahů, tak abychom zajistili vysokou dostupnost pro aplikace. 1 SLA Service Layer Agreemnet. 2 Heart Beat doslova srdeční pulz. 7

8 1.2 Vysoká dostupnost pro data Výběrem diskového pole určíme celkovou spolehlivost datové infrastruktury. Samotná disková pole jsou dnes navržena jako plně redundantní celek. Taková pole disponují dvojicí kontrolérů řídících komunikaci se servery na jedné straně a na druhé pak směrem k vlastním fyzickým diskům tvořícím kapacitu pole. Důležitou vlastností je bezvýpadkový přesun zátěže mezi kontroléry. Každý disk v diskovém poli je k serverům připojený pomocí duálních cest tedy existují dvě cesty pro případ hardwarové poruchy některého z komponentů infrastruktury. Největším problémem je stav výpadku kontroléru a jak se diskové pole vyrovná s takovou událostí. Co se stane s daty, která ještě nebyla uložena na disky a byla v době výpadku kontroléru v jeho vyrovnávací paměti? Taková paměť je u dnešních diskových polí v kapacitě až desítek GB. Jednoznačně je potřeba vybrat správné zařízení, které pamatuje na tuto možnost a provádí synchronní zrcadlení vyrovnávací paměti na druhý kontrolér. Pokud toto neumožňuje je nutné pro zápisy na pole tuto paměť zakázat a používat ji jen pro čtení. Uvědomme si, že dojde k omezení výkonu pro operace zápisu na pole tedy především o potvrzení převzetí dat což je daň za levnější disková pole. Ačkoliv máme super spolehlivé pole, může nastat situace, kdy pole přestane odpovídat nebo je potřeba udělat servisní zásah a je nutný restart celého systému. Na základě vlastních zkušeností se jako jediné možné řešení, jak zajistit vysokou dostupnost pro data jeví nutnost instalace druhého diskového pole. Dále je potřeba zajistit replikaci nebo kopírování dat tak aby byly ve stejný čas identická data na obou diskových polích. 1.3 Vysoká dostupnost pro IT infrastrukturu Infrastruktura je důležitou součástí, bez které nelze IT technologie rozumě provozovat. Jedná se o sítě pro komunikace prostřednictvím běžně užívaných protokolů. V současně době se těmito sítěmi rozumí především LAN a SAN sítě. Důležitým požadavkem na tyto sítí je redundance připojení. Klientská pracoviště jsou sice připojena do LAN sítě jedním kabelem, tedy pouze do jednoho aktivního prvku ale v případě propojení serverů a diskových polí se vždy jedná o striktně duální propojení s eliminací možného výpadku vlivem, některé komponenty infrastruktury. 8

9 2 Principy vysoké dostupnosti 2.1 Vysoká dostupnost High Availability neboli HA je v současné době nezbytnou součástí každé firemní infrastruktury a zcela důležitou součástí efektivního fungování firmy. Tento stav je mnohdy managementem firem brán na lehkou váhu. Pro nasazení vysoké dostupnosti mnohdy hovoří ekonomické ukazatele. Zejména pak vyjádření ztráty při odstavení výrobního provozu, expedice nebo fakturace. V případě prvního výskytu problému s nedostupností požadované služby je ihned požadováno takové řešení, aby k podobným incidentům již nedocházelo. Základním parametrem je definování dostupnosti služby SLA pro dané aplikace, služby, dostupnosti dat apod. Definicí potřebného SLA se zejména myslí povolený výpadek uváděný v procentech. Příkladem tedy mohou být následující definice SLA: Služba musí dosahovat dostupnosti 99 % v režimu 7x24 Služba fakturace musí dosahovat dostupnost 99,9 % v režimu 5x12 Služba výroba musí dosahovat 99,99 % v režimu 7x24 Uvedené definice nám říkají, jak jsou jednotlivé systém pro uživatele kritické a jak je potřeba zajistit jejich provoz. Procenta dostupnosti definují, kolik času musí být systém v provozu a naopak kolik času zůstává na jeho opravy. Uvedené příklady nám tedy prozrazují tyto informace. Službu potřebuje zákazník 24 hodin denně, 7 dní v týdnu a (ne)plánovaný výpadek nesmí překročit 3,65 dne za rok. Jinými slovy pokud služba nebude funkční 1 den 3x za rok není to omezující pro fungování firmy. Z uvedené tabulky č. 1 je zřejmé, že SLA požadavky od 99,9% výše jsou již daleko kritičtější a vyžaduje zvláštní rozbor každé z nich. Následující tabulka nejlépe postihuje rovnováhu mezi definicí SLA, skutečnou dostupností v čase a patřičných nákladech spojených s vlastní realizací infrastruktury. 9

10 Tabulka 1: Přehled SLA podmínek a trend nákladů na jeho dosažení. Časové období SLA 1 rok 99 % 99,9 % 99,99 % 99,999 % 365 dní 3,65 0,365 0,0365 0, hodin 87,6 8,76 0,876 0, minut ,6 52,56 5,256 Náklady Kč nízké vysoké Zdroj: Vlastní. 2.2 Příklady realizací jednotlivých SLA Pro příklad uvádím praktické zkušenosti s nasazováním aplikací, služeb pro jednotlivé SLA. Předpokládejme, že máme informační systém vyžadující aplikační a databázový server s připojením do lokální sítě 100 MB, diskový prostor pro data o velikosti 1,0 TB. Zálohování pro případ výpadku je realizováno nejvýkonnější zálohovací technologií LTO4. Zpravidla se SLA podmínky uvádění na dostupnost infrastruktury nikoliv na celek. Důvodem je poměrně těžko definovatelná garance pro dostupnost konkrétních částí. Dalším problémem je zajištění různých částí infrastruktury různými dodavateli. Garance za kvalitu aplikací lze jen obtížně definovat. Celkové SLA pak je možně jen v případech totálního outsourcingu. Dále jsem popsal pro názornost problematiku jednotlivých dostupností z pohledu infrastruktury, dat a zajištění opětovného provozu SLA 99 % Požadavek na dostupnost služby 99 % nám dává poměrně volnost ve volbě technologie, na které budeme IS provozovat. Výpadek téměř 88 hodin lze pokrýt následujícím hardware: Aplikační (APP), databázový (DB) server s procesory x86 operační systém Windows/Linux. Servery by měli mít redundantní klíčové komponenty (adaptery, disky, zdroje, atd.). Data lze umístit na lokální disky DB serveru s RAID 3 redundancí. Pro případnou poruchu hardware je vhodné servery zajistit servisním pokrytím s garantovanou dobou opravy na místě u zákazníka. Tedy požadavek SLA přeneseme na dodavatele hardware, který bude schopen nejlépe zabezpečit servis v lokalitě datového centra. 3 RAID Redundant Array of Inexpensive/Independent Disks redundantní diskové pole z nezávislých disků. 10

11 Řekněme, že budeme požadovat opravu do 24 hodin z důvodu ceny za požadovanou službu. Pokud máme opravený hardware, nastává okamžik, kdy musíme obnovit systém, případně data. Uvažujme nejhorší možnou variantu, že musíme udělat kompletní obnovu dat ze zálohy. Doba kompletní obnovy bude teoreticky trvat 2,38 hodiny, což neovlivní výpadek přes požadované SLA. Rekapitulace celkového času obnovy - RTO 4. Nejzazší doba opravy serveru podle SLA dodavatele HW - 24 hodin Teoretická obnova dat ze zálohovací mechaniky LTO4-2,38 hodiny Reakce obsluhy na problém a zahájení opravy sytému - 1 hodina Celkově by měla RTO být maximálně 27 hodin při nejhorším možném scénáři. Což znamená, že je možné zopakovat podobný zásah 3x za rok. Náklady na pořízení jsou vyjádřeny v následující tabulce č. 2. Tabulka 2: Celkové náklady na pořízení infrastruktury pro SLA 99 %. Komponenty Popis Cena v Kč Hardware Servery 2x x86 pro APP a DB + interní diskové pole Zálohování LTO4 mechanika Software Operační systém licence Podpora Servery HW SLA 24 hodin FIX 3 roky SW Operační systém 3 roky Celkové náklady za 3 roky Zdroj: Vlastní Celkové náklady na dosažení SLA po dobu 3 let budu pro tento případ cca Kč SLA 99,9 % Výpadek necelých 9 hodin za rok je již podstatné zkrácení. Zde není prostor na úvahy co dělat v případě, že dojde k výpadku některé části infrastruktury. Pokud se podíváme na předchozí příklad s RTO = 27 hodin je zřejmé, že takové řešení nesplňuje požadavky 4 RTO Recovery Time Objektive celkový čas obnovy. 11

12 kladené v SLA. Co je tedy potřeba zlepšit? V prvé řadě je potřeba zvážit kolikrát si můžeme dovolit výpadek, kdy opravdu dojde k totálnímu výpadku. Návrhů, jak řešit vzniklou situaci je mnoho v závislosti na finančních možnostech. Varianta A - ideální se zdá být automatický fail-over 5, který zajistí běh aplikace na druhém serveru. Pro úspěšné přesunutí je zapotřebí umístit data na externí diskové pole a zajistit sdílený přístup z obou serverů. Diskové pole musí podporovat možnost automatického přesunu logických svazků na druhý server. Opět platí nutnost redundance všech klíčových komponentů návrhu včetně redundance přístupu k datům na diskovém poli. Nevýhodou tohoto řešení je možný SPOF 6 na diskovém poli. V tomto případě lze eliminovat možný SPOF přidáním diskového pole nebo uzavřením SLA na opravu diskového pole s garantovanou dobou opravy do 4 hodin. Obě varianty jsou nákladné investice, přičemž druhé pole je vhodnější volbou. Obrázek 1: Obecné zapojení pro HA cluster se dvěma poli. Zdroj: Vlastní. Varianta B - vhodnou alternativou je využití replikačních vlastností některých databází. Pokud máme kvalitní databázový stroj, je možné používat online synchronní replikace mezi DB 7 stroji na obou serverech. Případný fail-over proces je pak v režii manažeru DB, který zajistí přesun zátěže na druhý server. V tomto případě není nutné používat externí diskové pole. Každý server má vlastní diskový prostor pro data. Další výhodou oproti předchozímu řešení je pak duplicitní ukládání dat. 5 Fail-over jedná se o zásah cluster nadstavby operačního systému. 6 SPOF Single Point Of Failure případný výpadek vlivem chyby jedné komponenty. 7 DB Databáze. 12

13 Obrázek 2: Databázové replikace. Zdroj: Vlastní. Jaké jsou tedy skutečné možnosti výpadku a jaký bude RTO pro obě varianty? V prvním případě, kdy dojde k výpadku diskového vlivem hardwarové poruchy a s následnou chybou servisního technika, při které bude navíc nutné obnovit data na poli je výpočet následující: Rekapitulace celkového času obnovy RTO: Varianta A - automatický cluster s diskovým polem: Nejzazší doba opravy serveru podle SLA dodavatele HW - 4 hodin. Teoretická obnova dat ze zálohovací mechaniky LTO4-2,38 hodiny. Reakce obsluhy na problém a zahájení opravy sytému - 1 hodina. Celkový čas RTO je cca 8 hodin což nám dovoluje jediný možný výpadek za celý rok. Doporučení je instalace druhého diskového pole a zrcadlení dat na obě pole. Tím se eliminuje nutnost kritického SLA na opravu HW s dobou 4 hodiny. Dále můžeme předpokládat, že nebude potřeba obnovovat data v důsledku výpadku diskového pole. Tedy dobu kdy automatický fail-over cluster software převede aplikace a nastolí opětovný běh systému. Celkový čas RTO by se pak snížil na jednotky minut. Pro další porovnání variantu s dvojicí diskových polí označím jako Varianta A1. Varianta B - databázové replikace: Nejzazší doba opravy serveru podle SLA dodavatele HW - 24 hodin. Teoretická obnova dat ze zálohovací mechaniky LTO4-2,38 hodiny. Reakce obsluhy na problém a zahájení opravy sytému - 1 hodina. Celkový čas RTO je závislý od reakce databázového systému a automatické reakce cluster systému. Prakticky se tato hodnota pohybuje v řádu jednotek minut. 13

14 Náklady na pořízení jsou vyjádřeny v následující tabulce č. 3 pro všechny varianty, kde je patrný nárůst nákladů na vlastnictví infrastruktury pro aplikace v uvedeném SLA pokrytí. Při realizaci jednotlivých variant musíme vhodně volit technologie, abychom dosáhli požadovaného výsledku. Pro všechny varianty platí, že klíčovým parametrem bude spolehlivost každé komponenty, abychom udrželi co nejlepší hodnotu MTBF 8 a tím i reálnou možnost úspěšného splnění SLA podmínek. Tabulka 3: Celkové náklady na pořízení infrastruktury pro SLA 99,9 %. Komponenty Varianta A Varianta A1 Varianta B Popis Cena v Kč Cena v Kč Cena v Kč Hardware Servery 2x x86 pro APP a DB Diskové pole (2x Varianta A1) Zálohování LTO4 mechanika Software Operační systém licence Cluster software Podpora Servery HW SLA 24 hodin FIX 3 roky Disková pole HW SLA 4 hodin FIX 3 roky Disková pole HW SLA 24 hodin FIX 3 roky SW Operační systém 3 roky SW Cluster 3 roky Celkové náklady za 3 roky Zdroj: Vlastní. Volba operačního systému je důležitá z několika hledisek. Musí být bezpečný, spolehlivý, stabilní a navíc poskytovat funkcionalitu, kterou potřebujeme. Další důležitou informací pro výběr je vzájemná podpora mezi výrobcem operačního systému a aplikací. U varianty A je nejen potřeba dbát na kvalitu produktů ale hlavně na kvalitu servisního pokrytí hardware diskového pole. Klíčovou úlohu zde bude hrát i spolehlivost dodavatele zda je schopen dostát SLA podmínek. Naopak u varianty A1 je nejdůležitější schopnost OS synchronně zapisovat data na obě pole současně. Zde jsou nejlepší zkušenosti s LVM 9 Linux a Unix operačních systémů. Pro MS Windows existuje vhodná alternativa v podobě Veritas LVM, který je ovšem za poplatek nicméně jedná se o výborný produkt. 8 MTBF - Mean Time Between Failures střední doba mezi poruchami. Vyšší hodnota = vyšší spolehlivost. 9 LVM - Logical Volume Manager manažer disků. 14

15 Oproti předchozím variantám je varianta B jednodušší z pohledu hardwarové infrastruktury. Klíčovou úlohu zde hraje především kvalita DB stroje a jeho replikačních schopností. Mnoho zákazníků dává přednost právě replikaci na úrovni DB stroje, protože je tím zajištěna kontinuálnost provozu s minimálními požadavky na hardware. Ovšem i zde existují úskalí. Je vždy potřeba se seznámit s licenčními podmínkami výrobce DB stroje. Některé produkty jsou vybaveny replikačními funkcemi a není potřeba je dokupovat, jiné jsou naopak zpoplatněné. Dále záleží na náhledu výrobce DB stroje, jak hodnotí celou infrastrukturu z pohledu licenční náročnosti. V některých případech je rozdíl i v tom, zda je DB uložena na jednom či více diskových polích. Pro všechny varianty ovšem platí, že pokud chceme zajistit automatický fail-over je potřeba integraci s cluster softwarem, který zajistí všechna potřebná nastavení. Jedná se o operace, jako jsou namontování disků, změny IP 10 adres a pojmenování LAN adapterů tak, aby dotazy byly správně směrovány na nový server SLA 99,99 % Výpadek necelou hodinu za rok znamená, že nemůžeme již podcenit žádnou část běhu systému. Ideální technologie pro takovou dostupnost je ta, která umožňuje online správu. Operační systém by měl být opravitelný za běhu, stejně tak i hardware, který by měl mít co nejvíce za chodu opravitelných komponentů. Uvažujeme o hardware pro servery s následujícími vlastnostmi: Prediktivní kontrola a samo-opravné reakce u klíčových komponent, jako jsou procesory, paměti, sběrnice. Interní systém serveru musí monitorovat provoz serveru a reagovat preventivně na potenciální problematické chování tak aby nedošlo k totálnímu výpadku serveru. Kontrolní systém dokáže de-alokovat potenciálně vadný procesor nebo paměťový čip, který by vykazoval podezřelé chování. Redundantní architektura serveru v oblastech jako jsou paritní informace na sběrnicích a pamětech nebo princip dvojitého osazování komunikačních adapterů, napájecích zdrojů a ventilátorů. 10 IP Internet Protocol všeobecně používaný protokol ke komunikaci v LAN sítích. 15

16 Spolupráce s operačním systémem musí zajišťovat online provoz i v případě výskytu kritických poruch. Tedy výpadek procesoru nesmí způsobit pád operačního systému a aplikací které hostuje. Jaký hardware takovými vlastnostmi disponuje? Většinou se jedná o servery s RISC procesory a operačním systémem UNIX od IBM, HP nebo SUN Microsystems. Další možností je zajistit více početný cluster systém pro x86 servery, které nemají zdaleka tak propracovanou prediktivní a samo-opravnou architekturu jako zmíněné RISC servery. Zde je potřeba vhodně volit management a cluster software k zajištění dostupnosti. Jak budou vypadat řešení infrastruktur? V podstatě se příliš nezmění od předchozí varianty s dvojicí diskových polí. Jen servery je potřeba upravit ve smyslu spolehlivější hardwarové architektury. Aplikační servery by bylo vhodné nasadit na dvojici oddělených serverů ideálně propojených do aplikačního clusteru. To znamená, že aplikace jsou online aktivní na obou serverech a kontrolují vzájemnou utilizaci a zajišťují distribuci zátěže mezi sebou. Pro databáze bude ideální DB cluster dvou RISC serverů a dvou diskových polí. Co je potřeba detailně zvážit je princip replikace dat na disková úložiště. Ne všechny možnosti budou vyhovovat pro případné výpadky. Následně uvádím klady a zápory jednotlivých možností Zrcadlení dat prostředky operačního systému LVM Jedná se o zrcadlení dvou logických disku, každý z jiného pole a jejich propagování do operačního systému jako jeden disk pro databázi, která na takový disk zapisuje data. Veškerá režie při zrcadlení dat mezi diskovými poli je na serveru a operačním systému. Pozitiva: Negativa: o Jednoznačně nejsnazší synchronizace dat mezi dvě disková pole. o Výpadek jednoho pole neovlivní funkci druhého. o Cenově výhodné řešení. o Výkonová režie je na operačním systému serveru. o Špatný zápis způsobený chybou operačního sytému nebo DB stroje se provede na obě pole najednou. o Případný fail-over databáze z primárního na záložní server bude provádět kontrolu souborového systému a následnou kontrolu DB, což může trvat i 16

17 několik minut u velkých DB v řádech TB je možné očekávat i desítky minut! o Obě pole by měla být shodná, aby nedocházelo k výkonnostním rozdílům při zápisu dat Zrcadlení prostředky diskových polí Zrcadelní často známé pod označením Mirroring nebo Remote Mirroring vzdálené zrcadlení. Princip je na replikaci dat prostředky, kterými disponují disková pole. Jedná se o vlastnost diskových polí střední až vysoké třídy. Komunikační rozhraní je FC 11 a připojují se do SAN 12 sítí. Jedno pole je vždy určeno jako primární a druhé záložní. Primární pole zasílá blokové změny dat druhému poli a po potvrzení přijetí je teprve poté potvrzen zápis operačnímu systému zapisujícímu data. Tedy replikace se provádí jen u změn nikoliv pro celá data Díky vysoko propustné síti SAN a blízké vzdálenosti je toto provedeno okamžitě bez zpoždění. Pozitiva: Negativa: o Nemá vliv na výkon serveru, režie je na diskovém poli, které replikuje jen malé změny. o Funguje na velké vzdálenosti. Používá se DR 13 řešení. o Špatný zápis způsobený chybou OS nebo DB stroje se provede na obě pole najednou po potvrzení zápisu na vzdáleném poli. o Záložní pole je vždy v módu target cíl. To znamená, že v případě výpadku primárního pole je potřeba zajistit změnu stavu na source zdroj. Pak teprve můžeme začít fail-over operaci. Tuto většinou provádí automaticky cluster software. o Případný fail-over databáze z primárního na záložní server bude provádět kontrolu souborového systému a následnou kontrolu DB, což může trvat i několik minut u velkých DB v řádech TB je možné očekávat i desítky minut! 11 FC Fibre Channel protokol pro přenos dat mezi zařízeními infrastruktury. 12 SAN Storage Area Network Obdoba LAN sítě jen určena pro komunikaci FC protokolem zejména použitých v infrastruktuře pro disková pole, servery a zálohovací knihovny. 13 DR Disaster Recovery zotavení z katastrofy. Více samostatná kapitola v této práci. 17

18 o Obě pole by měla být technologicky stejná, aby fungovala vzájemná komunikace. o Cena řešení je nejvyšší ze všech uvedených - licence RM funkcionality diskových polí Databázové replikace a online databázový cluster Jak již bylo popsáno výše. Jedná se o replikaci dat prostřednictvím DB strojů a jejich replikačního manažeru. Požadavky na zápisy dat jsou posílány primárním DB serverem prostřednictvím redo 14 nebo podobných logů na vzdálený server. Při potvrzení záložním serverem o přečtení a aplikování těchto logů na vlastní data je teprve odesláno potvrzení aplikaci, že byl požadavek o zápis proveden. Existuje i možnost online DB clusteru, kde oba DB servery jsou online a případný pád jednoho z nich nemá vliv na funkci DB vrstvy. Pozitiva: Negativa: o Jednoznačným pozitivem tohoto řešení je nezávislost diskových polí navzájem jako v předchozích řešeních. o Data, respektive popis změn dat, jsou velmi rychle přenášena na druhý server. o Funguje na velké vzdálenosti. Používá se DR řešení. o Chyby zápisu vlivem OS nebo DB stroje nemají vliv na záložní server! o Případný fail-over je u některých DB systémů do jednotek sekund! o Cena licencí za replikační nástroje může být vysoká. Záleží na výrobci a typu řešení. Rekapitulace celkového času obnovy RTO: Zrcadlení dat prostředky operačního systému LVM je nejčastěji používaným řešením běžně užívaným pro dosažení vysoké dostupnosti. Dobré praktické zkušenosti jsou zaznamenány i na diskových polích třídy Enterprise určené pro kritické podnikové aplikace. Jak bylo již popsáno, hlavní nevýhodou tohoto řešení je zápis na obě pole 14 Redo log především v terminologii Oracle DB. Znamená logování všech změn v DB, které provádí DB stroj a ukládá vše do unikátního souboru. 18

19 najednou, kdy může nastat zápis špatných dat vlivem chyby OS nebo DB stroje. Pak nemáme data ani na jednom poli. Jediným vhodným řešením jak zabránit nutnosti obnovy dat z pomalé zálohovací knihovny je pořizovat okamžité kopie dat na diskových polích. Tato operace proběhne v řádu několika sekund a umožní nám návrat k datům z doby, kdy jsme kopii vytvořili. Celkový čas na obnovu funkční infrastruktury bude tedy nejvíce závislý na obsluze, jak dokáže aplikovat návrat do konzistentního stavu a uvést systém zpět do produkce. Rozdíl mezi dobou vytvoření kopie a dobou poruchy je potřeba rekonstruovat z logů, které tvoří databáze. V případě, že dojde k překročení požadované doby obnovy je potřeba zkrátit čas mezi jednotlivými kopiemi dat na potřebnou dobu. Zrcadlení prostředky diskových polí remote mirroring je alternativním řešením k předchozímu se stejnými problémy. Z pohledu RTO jsou tyto řešení poměrně shodná. Databázové replikace online databázový cluster je zcela jiné koncepce a vlastní data mohou být ukládána na zcela jiná disková pole od jiného výrobce nebo jiné technologické architektury. Vlastní chyba zápisu způsobená OS nebo DB strojem se nepřenáší na vzdálenou lokalitu. Což nám zajišťuje větší míru bezpečnosti než předchozí dvě řešení. Z těchto známých skutečností lze tuto variantu hodnotit jako nejvýhodnější řešení s nejlepší hodnotou RTO. Možnost využití okamžitých kopií je možným doplňkem pro zajištění duplikace dat pro možnost obnovy. Obecně platí, že pro případy poruchy musí mít obsluha připravený a ověřený postup pro obnovu chodu. Dále je velmi vhodné provozovat i testovací prostředí na ověření postupu obnovy a aplikaci změn a jejich pravidelném ověřování. Zejména je potřeba mít na zřeteli chybný zásah uživatele a to nejen běžných pracovníků ale i odborných administrátorů a servisních techniků. V případě modifikace dat způsobené uživatelem je většinou nutné obnovit data ze záloh a to buď na kopiích, uložených na diskových polích nebo na páskových zařízeních. Náklady na pořízení pro jednotlivé varianty se v praxi od sebe příliš neliší nebo minimálně. Důvodem je skutečnost, že danou dostupnost požadují firmy s větším investičními rozpočty pro IT oddělení. Následně uvádím potřebné součásti infrastruktury, které je potřeba zohlednit při návrhu: 19

20 Dostatečně spolehlivý hardware podle MTBF nebo MTBHI 15. Výrobce hardwaru by měl takové nebo podobné hodnoty uvádět pro svá zařízení na požádání. Požadovaná servisní podpora s garantovanou dobou opravy alespoň 8 hodin. Kopírovací funkce diskových polí pro zajištění průběžné duplikace dat. Operační systém serverů s podporou LVM. Databázové replikační prostředky. Cluster software pro automatizaci reakcí na chybové stavy. Redundantní infrastruktura SAN a LAN. Z uvedené tabulky č. 4 je zřejmý rozdíl v pořizovací ceně jednotlivých řešení. Vzhledem k ceně a vlastnostem ukládání dat se zdá být nejvýhodnější varianta DB replikací. Nicméně opět upozorňuji na licenční politiku výrobce, která může výrazně změnit cenovou výhodnost této varianty. Tabulka 4: Celkové náklady na pořízení infrastruktury pro SLA 99,99 %. Komponenty LVM Rem. Mirr. DB Repl. Popis Cena v Kč Cena v Kč Cena v Kč Hardware Servery 2x RISC pro APP a DB Disková pole 2x 1TB dat Replikační spužby diskových polí Kopírovací služby diskových polí Zálohování LTO4 mechanika Software Operační systém licence Cluster software Podpora Servery HW SLA 8 hodin FIX 3 roky Disková pole HW SLA 8 hodin FIX 3 roky SW Operační systém 3 roky SW Cluster 3 roky Celkové náklady za 3 roky Zdroj: Vlastní. Předpokladem je využití serverů s RISC procesory a operačním systémem Linux / UNIX. Zde je záruka splnění kritických požadavků na chování serveru v případě chyby nějaké komponenty. 15 MTBHI - Mean Time Between High Impact obdoba MTBF. Hodnotí se jen totální výpadek systému nebo takový výpadek, který způsobí vážné ochromení běhu aplikací. 20

21 Disková pole budou standardní FC zařízení disponující kopírovacími a replikačními funkcemi SLA 99,999 % Výpadek 5 minut za rok znamená, že máme zcela bezchybné řešení, které můžeme online spravovat, aniž bychom potřebovali plánovanou odstávku. Jednotlivé výskyty chyb v infrastruktuře musí být opravitelné bez ztráty dostupnosti služby. Data jsou ukládána rovněž duplicitně na více diskových polí. V podstatě lze říci, že již není k metodám vysoké dostupnosti co dodat. Veškeré možnosti byly popsány v předchozí kapitole. Pro pěti devítkovou dostupnost budeme jen vybírat spolehlivější produkty a dbát na celkovou dostupnost celého řešení tak, aby se dosáhlo očekávaného výsledku. Pravdou je, že existuje online cluster systém, který je schopen přesouvat zátěž mezi jednotlivými uzly clusteru tak, že uživatel nepozná, že se přesunul na jiný server. Je neustále připojený a jeho aktivní operace se stěhují dle potřeby ze serveru na server. Taková řešení nabízí například společnost IBM na produktech s označením IBM zseries 16 také známé jako Mainframe nebo S/390. Servery této třídy mají unikátní vlastnost pro vysokou dostupnost. Dva takové servery můžeme spojit do Paralell Sysplex zjednodušeně řečeno, servery mohou pracovat jako jeden, ačkoliv jsou odděleny i na větší vzdálenost. Duplikují, replikují vše důležité a umožňují okamžitý fail-over na druhý uzel v rámci HA clusteru. Další možností jsou Non-Stop servery od společnosti HP dříve produkty společnosti Tandem. Aplikace volíme tedy tak, aby umožňovaly automatické přesouvání zátěže bez nutnosti instalace dalšího obslužného softwaru, jakým je cluster. Tato vlastnost je již posunuta do vlastních aplikací. Aplikační servery všech předních firem mají takovou funkcionalitu. Aplikační servery jsou většinou napojeny na databáze a zde je asi největší problém. Databáze je tedy klíčovou částí návrhu a je potřeba zajistit co nejoptimálnější nasazení a vhodný výběr DB stroje v závislosti na hardwarové platformě. Jak tedy zajistit aby DB stroj byl aktivní jako více uzlový cluster a byl schopen odpovídat z jiného uzlu? Existují v podstatě jen dvě možná řešení. Společnost Oracle nabízí produkt 16 zseries z znamená zero downtime, tedy bez výpadkový provoz. 21

22 RAC 17, který disponuje logikou, kdy na dva a více serverů instalujeme DB stroj a propojíme je navzájem do online clusteru. Toto řešení pracuje s jedním datovým prostorem, který je možné pomocí LVM nebo RM distribuovat na další, fyzicky oddělené pole. Poškození dat špatným zápisem je tedy opět fatální problém. Druhou možností je replikace a rychlý fail-over na záložní server. Tuto technologií disponují produkty IBM DB2 HARD, Informix Enterpise Replication, Sybase Replication Server, Progress DB Replication a další. V případě IBM DB2 je například fail-over možné zajistit za 11 sekund. To je velmi krátký čas, po který uživatel může narazit na problém zápisu dat. Pokud se tak opravdu stane je poslední nepotvrzená transakce vrácena zpět a uživatel je vyrozuměn, že došlo k chybě. Pokud operaci zopakuje tak s největší pravděpodobností úspěšně projde bez problémů na druhém serveru, který nahradí v mezičase primární server. Výhody a nevýhody obou řešení jsou zřejmé. Pro Oracle RAC především hovoří teoreticky bezvýpadkový provoz a neustálá online služba. Pravdou je, že i toto řešením má svá úskalí. Podívejme se na následující porovnání z mnoha pohledů, které nejlépe vypovídají o jednotlivých vlastnostech řešení. 17 Oracle RAC Real Application Cluster online cluster více uzlů DB strojů. 22

23 Tabulka 5: Porovnání dostupnosti DB řešení pro vysokou dostupnost. Vlastnost Oracle RAC DB Replication Hodnocení Diskový prostor Jeden pro všechny RAC DB Fyzicky oddělené nezávislé Výhoda DB Replication uzly diskové prostory Čas fail- over Teoreticky 0s. Praxe ukazuje Jednotky sekund Shodné zmrazení celého clusteru po dobu re-konfigurace v řádech sekund. Výkon clusteru Výkon všech uzlů se sčítá. Pouze jeden server na 100 %. Výhoda Oracle RAC Režie clusteru je cca do 7 % a Režie pro replikační službu je závisí na počtu uzlů. Tedy zanedbatelná. Maximální cluster 2 serverů disponuje výkon je vždy jen 100 % výkonem cca 193 %. jednoho serveru pro zápis. Čtení je možné realizovat i ze záložního serveru. Plánovaný servis Upgrade OS + DB, které mají U IBM DB2 je možné udělat Výhoda DB Replication vliv na kompatibilitu dat je upgrade jednoho serveru a pak nutné provést najednou na druhého. Replikace jsou všech uzlech. Pak rozběhnout kompatibilní na různých službu. Nelze udělat bez verzích DB. Lze udělat bez výpadku. výpadku. Vzdálenost mezi Shodné uzly Většinou LAN/SAN do vzdálenosti v jednotkách km, v závislosti na latenci interní komunikace clusteru. Většinou LAN/SAN do vzdálenosti v jednotkách km, v závislosti na latenci interní komunikace clusteru. Celkové hodnocení RAC disponuje větším výkonem součtem všech serverů. Naopak zásadní nevýhodou je nutnost plánované odstávky pro případ upgrade a závislost na jednom datovém úložišti i když duplikovaném. Replikace disponují nezávislostí na diskovém úložišti vynikají delší vzdáleností a jsou v některých případech nezávislé na plánovaných odstávkách z důvodu upgrade. Oracle RAC: + vyšší výkon - dostupnost DB Replication: + dostupnost - výkon proti RAC Zdroj: Vlastní. Náklady na pořízení infrastruktury budou nesrovnatelně vyšší oproti předchozím variantám. Z uvedených informací a eliminace rizik je vhodné infrastrukturu budovat na prověřených a spolehlivých technologiích. Praxí ověřená infrastruktura by měla vypadat takto. Servery s operačním systémem UNIX s garantovanou vlastní dostupností alespoň 99,99 %. Jedná se tedy o spolehlivost hardwarových a všech komponent. Pro příklad uvádím informaci dostupnosti získaný pro server IBM PowerSystems 570. Uvedené výsledky neobalují vliv operačního systému a ignorují možné externí vlivy, jako mohou být výpadek elektrické energie, chlazení nebo jiné cizí zavinění s přímým vlivem na výpadek serveru. Je to tedy posouzení pouze vlastního hardwaru serveru. 23

24 Tabulka 6: Příklad dostupnosti pro server IBM pseries 570. Server IBM pseries CPU, 128GB Memory, 12 I/O Adapters, 8 X 73,4 GB Stabilita 0,914 výpadků / rok Stabilita 0,079 neplánovaný výpadek / rok MTTR 4 hodiny Dostupnost 0,99996 (99,669 %) MTBF 1,094 roků MTBUIRA 12,65 roků Zdroj: Interní IBM dokument Letter 116 zhotovený na požadavek získání dostupnosti pro server IBM pseries 570. Důležité jsou především hodnoty pro dostupnost, MTTR 18 a MTBUIRA 19. Disková pole je vhodné volit z třídy High-end. Do kalkulace jsem použil pole DS8100 s propracovanou technologií monitoringu. Pro náš příklad je toto pole poněkud zbytečně naddimenzované s ohledem na požadovanou kapacitu pouze 1 TB. Disková pole této třídy jsou většinou určena pro desítky TB. Infrastruktura pro vzájemné propojení je potřeba dvojice SAN přepínačů. Ideálním produktem pak bude přepínače od společností Brocade nebo Cisco. V kalkulaci jsem použit prvky Brocade z důvodu přítomnosti 8 Gb Fibre Channel technologie. Operační systém a cluster software je potřeba použít spolehlivý systém tedy UNIX. Pro návrh jsem využil nabídku operačního sytému AIX 6.1 a jeho podporu pro clustering software PowerHA. Aplikace a databáze při návrhu již musíme uvažovat o všech scénářích možných příčin výpadku a následné obnovy. Ideální je vždy použít aplikační a databázový server od jednoho softwarového dodavatele jakou jsou IBM, Oracle, Sybase. Pečlivě projdeme vlastnosti jednotlivých produktů a vybereme nevhodnější kombinaci, tak aby vše fungovalo správně. Výběr nám také musí umožnit nasazovaná aplikace. Mnohdy jsou dodavatelé aplikací svázáni s jedním dodavatelem a nelze výběr provézt, v horším případě je omezení i na serverovou platformu a potřebný operační systém. Zde je pak řešení dané možnostmi aplikací. Tedy pozor při výběru aplikace zda nejde o produkt těsně svázaný s platformou, která nemusí zcela vyhovovat. Kvalitní produkty se vyznačují používáním 18 MTTR - The Mean Time to Repair průměrná doba opravy techniků IBM. 19 MTBUIRA - Mean Time Between Unscheduled Interrupt Action střední doba mezi neplánovanými akcemi vedoucí k přerušení provozu. Pokud takový incident nastane, dojde k restartu a systém naběhne v degradovaném módu. Uživatel zaznamená výpadek. 24

25 obecných technologií a podporou více DB strojů. Pro vyjasnění uvádím dva příklady, které by měli ukázat rozdílnou možnost nasazení: Příklad 1: aplikace vyvíjená v prostředí Microsoft.Net s možností připojení na Microsoft SQL server. Příklad 2: aplikace vyvíjená v C, C++, Java s možností napojení na DB stroje DB/2, Oracle, Informix nebo Sybase. Obě aplikace mohou disponovat stejnou funkčností ale jejich nasazení je zásadně rozdílné. Podmínka v příkladu 1 nám přímo diktuje, jak bude vypadat požadavek na platformu hardwaru a použitelného operačního systému. Produkty společnosti Microsoft nelze instalovat na RISC servery s operačním systémem UNIX. Je tedy jednoznačně daná platforma pro nasazení. Tedy x86 servery s Windows 2xxx Servere operačním systémem. A je vybráno! Tento neutěšený stav lze změnit už jen produkty třetí strany. Tedy vylepšeními nebo nadstavbou pro Windows operační systém od jiných dodavatelů jakou jsou Veritas Foundation, Double-Take a mnoho dalších. Příklad 2 je naprosto odlišný od předchozího. Hlavní výhodou je možnost rekompilace nebo úpravy aplikačního kódu pro cílovou platformu. Tedy pokud víme, že cílový operační systém bude Linux, IBM AIX, SUN Solaris nebo HP-UX můžeme docílit ideální funkčnosti a využít vlastností operačních systémů a také hardware na kterém bude provozován. DB vrstva orientovaná na produkty podporující více platforem je také velmi vhodná. Umožní nám opět volbu cílové platformy s ohledem na licenční výhodnost nebo výkonnostní parametry hardware. Do infrastruktury jsem navrhl možnost použití jazyků Java / C++ pro aplikační server s podporou online clusteringu na aplikační úrovni. Vhodné produkty jsou v nabídce firem IBM, Oracle, Sybase, BEA, Progress a další. Pro DB vrstvu je vhodné použití buď online cluster Oracle RAC nebo IBM DB/2 případně jiný DB stroj s podobnými replikačními vlastnostmi. Podle DB vrstvy je pak vhodné použít i aplikační server, Oracle Application Server, IBM WebSphere Application Server nebo jiné inteligentní aplikační servery. 25

26 Tabulka 7: Celkové náklady na infrastrukturu 99,999 %. Komponenty DB + WAS Popis Cena v Kč Hardware Servery 2x PWR570 pro APP a DB Disková pole 2x DS8100 1TB dat Kopírovací služby diskových polí PTC SAN přepínač 2x Boracade 8(24)port 8Gb Zálohování LTO4 mechanika Software Operační systém licence Cluster software Podpora Servery HW SLA 8 hodin FIX 3 roky Disková pole HW SLA 8 hodin FIX 3 roky SW Operační systém 3 roky SW Cluster 3 roky Celkové náklady za 3 roky Zdroj: Vlastní. Celkové náklady jsou vyčísleny v tabulce č. 7. Návrh nezahrnuje volbu aplikační a DB vrstvy. K ceně je tedy potřeba připočíst cenu za licence softwaru Zhodnocení Z uvedených údajů je patrné, jak je potřeba přistupovat ke tvorbě infrastruktury pro hostování aplikací s rozdílným požadavkem na dostupnost. V praxi při určování infrastruktury se většinou postupuje v několika iteracích, kdy nejprve zákazník definuje nejpřísnější SLA tedy požadavek na 99,999 % a po předložení ceny za řešení ustoupí od tohoto požadavku na úměrnou mez damou finančními možnostmi a rozpočtem. Ovšem jsou i případy, kdy pravdu hodinový výpadek znamená značné finanční ztráty a pokud už zákazník má podobnou negativní zkušenost s nedostupností služby je svolný k vyšším investicím do infrastruktury a tedy i realizaci podobného řešení jak bylo mnou vtrženo. Pro porovnání jsem připravil tabulku č. 8 nákladů na infrastrukturu pro jednotlivé SLA podmínky. 26

27 Tabulka 8: Závislost požadavku na dostupnost a ceny za pořízení infrastruktury. Časové období SLA 1 rok 99 % 99,9 % 99,99 % 99,999 % 365 dní 3,65 0,365 0,0365 0, hodin 87,6 8,76 0,876 0, minut ,6 52,56 5,256 Náklady Kč Zdroj: Vlastní. Z uvedené tabulky č. 8 vyplývá náročnost investice vzhledem k požadovanému stupni dostupnosti. Pro ilustraci jsem doplnil obrázek č. 3 znázorňující graf závislosti požadavků na SLA a nákladů spojených s realizací potřebné infrastruktury. Obrázek 3: Graf závislosti nákladů, možného výpadku pro různé SLA podmínky. Náklady na relizaci (Mil. Kč) Náklady na dostupnost infrastruktury 99 % 99,9 % 99,99 % 99,999 % Cena za řešení Možný výpadek 87,6 8,76 0,876 0, Možný výpadek (h) Zdroj: Vlastní. 2.3 Zotavení z katastrofy DR je všeobecně používanou zkratkou pro Disaster Recovery tedy zotavení z katastrofy, která zničila primární datové centrum. Stupňů řešení DR je mnoho a jsou zpracovany do kategorií podle následujících požadavků: Čas obnovy data centra a opětovný chod infrastruktury. Jedná se o definici času, za kterou je potřeba zajistit opětovný chod infrastruktury ze záložní lokality. Předpokládá se přítomnost minimální hardware konfigurace pro dostatečný chod firmy v krizových podmínkách. Akceptovatelná velikost dat, která budou ztracena důsledkem katastrofy. Množství dat, která nebyla přenesena do záložní lokality. Zpravidla se jedná o časové období mezi provedenými zálohami dat a přenesením na záložní lokalitu. 27

28 Technologie užívané pro DR jsou obdobné technologiím užívaným při návrhu HA řešení. Následující obrázek č. 4 vypovídá o základním principu, jak DR vypadá v praxi. Obrázek 4: Schéma architektury DR. Zdroj: Vlastní. Produkční lokalita je hlavní data centrum, kde je vybudovaná veškerá infrastruktura s požadavky na vysokou dostupnost pro aplikace i data. Lokalita DR je záložní data centrum vzdálené od produkční lokality tak, aby byl eliminován vliv možné katastrofy. Při definici katastrofy a jejího vlivu na chod infrastruktury je potřeba dbát na následující body: Chyby infrastruktury a obsluhy. Hardware, software, komunikace sítě LAN, SAN, WAN, pracovní podmínky, zdravotní nebezpečí a další, legislativní omezení. Násilné činy. Teroristický útok, sabotáž, epidemie, lidská chyba, hacking a další. Povětrnostní vlivy. Zemětřesení, povodně, požár, tornáda, větrné bouře, sopečná činnost a další. Každý zákazník podle regionu, politické situace a mnoha dalších podmínek definuje možná rizika výpadku infrastruktury. Dále definuje vliv výpadku na jeho klíčový business a dopad na hospodářský výsledek firmy. Otázka rozpočtu a velikosti investice pro vybudování DR lokality je důležitým ukazatelem, jak bude vypadat stupeň DR řešení. 28

29 2.3.1 Možné varianty DR řešení IBM definuje DR koncept v 7mi stupních podle požadavku na kontinuálnost provozu Business continuity. Ke každému stupni navrhuje řešení, jak by měla vypadat infrastruktura a přenos dat. Následující obrázek č. 5 nejlépe vystihuje změny návrhu obnovy dat při zvyšování stupně, tedy zkrácení času obnovy. Tyto třídy jsou dále rozděleny do těchto segmentů: Kontinuální dostupnost pro třídu 7 Rychlá obnova dat pro třídy 6 4 Záloha obnova pro třídy 3 1 Jednotlivé segmenty jsou především určeny dobou, za kterou potřebujeme obnovu provést. Obrázek 5 Třídy business kontinuity a vliv doby obnovy dat na použité technologii. Zdroj: IBM System Storage Business Continuity Solutions Overview dostupný na Z obrázku je zřejmé, že data budou v závislosti na třídě a tedy na požadavku doby obnovy zálohována a obnovována různými technologiemi. Pro kratší čas bude nutné obnovu provádět z disků a naopak pro delší časové období je možné využívat záloh na páskových systémech. Projděme si tedy jednotlivé třídy z pohledu technologie pro infrastrukturu. Jaké jsou jejich rozdíly a dopady na cenu řešení. 29

30 2.3.2 Třída 7 Nejvyšší třída, kdy očekáváme obnovu data centra v řádech několika minut. Pro splnění těchto požadavků je nutné, aby obě lokality tedy produkční a DR byly v synchronním stavu. Ideální by bylo, kdyby DR lokalita byla navržena tak, aby byla také produkční. To znamená, že infrastruktura mezi centry bude na takové úrovni, aby bylo možné provozovat aplikace a ukládat data na obě lokality najednou tedy aktiv / aktiv provoz. Požadavky jsou v tomto případě především na průchodnost sítí LAN a SAN, které propojují datová centra. V dnešní době je již možné propojit datová centra v rozumné vzdálenosti na velmi rychlém spojení. Pro sítě LAN je postačující 1 GB Ethernet propojení. Na SAN sítích se bez problémů dosahuje rychlosti 4 GB na vzdálenost až 10tky km. Což je dostačující pro vybudování vhodné DR lokality s ohledem na lokální rizika. Po tento příklad uvádím nejběžnější příklad z praxe, který je užíván pro zajištění DR stupně 7. Obrázek 6: Příklad DR infrastruktury pro třídu 7. Lokalita Produkce Server DB/APP Lokalita DR Server APP/DB HA cluster (LAN, SAN) DB Replikace (LAN) LW 4Gb SAN Infrastruktura LW 4Gb Diskové pole Remote Copy (SAN) Diskové pole Zdroj: Vlastní. Z obrázku č. 6 je zřejmé propojení obou lokalit na vzdálenost, kdy jsme schopni udržet přenosové rychlosti. To je důležité především pro zajištění synchronních dat v obou lokalitách. Navržené řešení by mělo splňovat následující požadavky. Přístup klientů je balancovaný mezi obě data centra tak, aby byla zátěž rovnoměrně rozložena podle potřeby. K tomu je potřeba vybudovat LAN síť s inteligentními směrovači 30

31 disponující funkcí Load Balancing, tedy rozklad zátěže přicházející od klientských počítačů. Aplikace musí být rozděleny podle potřeby opět rovnoměrně, aby bylo možné odpovídat na dotazy klientů nezávisle na tom, do kterého datového centra je dotaz směřován. V případě inteligentních aplikací a aplikačních serverů je řešení poměrně snadné. Provede se instalace aplikace na více nezávislých serverů v obou lokalitách a zajistí se jen vlastní cluster podpora samotnými aplikačními servery. Inteligentní LAN prvky už zajistí, aby se rozložila zátěž na všechny servery disponující danou aplikací. Pro databáze platí v tomto případě stejná pravidla jako pro HA řešení. Tedy je možné použít Oracle RAC cluster nebo Replikace DB v případě ostatních produktů od IBM, Sybase a dalších. Vždy ovšem platí, že při dotazování aplikačních serverů směrem k DB nastává poměrně intenzivní komunikace a proto je potřeba vhodně dimenzovat propojení mezi lokalitami. Řešení Oracle RAC sice eliminuje tuto komunikaci mezi aplikačními a DB servery na společnou lokalitu, ale za to vyžaduje speciální linku mezi servery, po které probíhá intenzivní komunikace pro zajištění provozu. Infrastruktura je tedy klíčovým prostředkem jak vůbec zajistit aktiv/aktiv fungování obou data center. Je zřejmé, že se nevyhneme vyšším investicím nejen do vlastních LAN a SAN aktivních prvků, ale také do vybudování nebo pronajmutí komunikačních linek mezi lokalitami. Obecně platí, čím větší vzdálenost a požadavek na propustnost, tím komplikovanější a samozřejmě nákladnější konfigurace potřebných prvků. Konfigurace LAN i SAN sítě by měla z pohledu serverů vypadat tak, že se jedná v každém případě o jednu redundantní síť. V praxi to znamená, že použijeme redundantní produkty, které jsou již vyrobeny tak aby poskytovaly potřebnou redundanci. Druhou možností je použít fyzicky oddělené boxy tedy místo jednoho redundantního přepínače dva. Jak je patrno z předcházejícího obrázku č. 6 do každé lokality je umístěna dvojice SAN přepínačů. Ty jsou pak propojeny vždy každý zvlášť s přepínačem ve druhé lokalitě pomocí LW 20 technologie. Tím je zajištěna plná propustnost mezi lokalitami pro data po dvou oddělených vláknech. 20 LW Long Wave je technologie jak propojit Fibre Channel zařízení na větší vzdálenosti. 31

32 Data jsou obdobně jako v případě HA synchronizována mezi lokalitami pomocí všech dostupných technologií se všemi vlastnostmi, které s sebou nesou. Fail-over je zcela automatický a využívá se pro něj automatické funkce cluster podpory operačních systémů. V tomto případě se DR od HA řešení neliší ničím, až na větší vzdálenost a rozdělení infrastruktury do dvou datových center a tím větší investice právě do jejich propojení Třída 6 4 V těchto třídách je výpadek již v jednotkách hodin. Zde je nejčastěji vyžadována asistence administrátora, který rozhodne, zda se má udělat fail-over na záložní lokalitu či nikoliv. Administrátor zjistí, zda nejde jen o planý poplach a teprve po vyhodnocení situace udělá manuálně zásah, fail-over operaci. Infrastruktura pro tyto stupně je již poněkud jednodušší a předpokládá se možný výpadek několika hodin, během kterých je dostatek času pro plánované nastartování záložní lokality. Nejdůležitější pro obnovu provozu je opět přítomnost dat v DR lokalitě. Jejich kvalita v porovnání s produkční lokalitou je daná zvolenou technologií přesunu dat. Nejčastěji je využívána DB replikace. Požadavek na infrastrukturu je omezen jen na LAN/WAN síť, protože DB replikace využívají pouze tuto cestou. Navíc není potřeba používat technologicky kompatibilní pole jako v lokalitě produkční pro ukládání dat. Druhá možnost je Remote Mirroring. Zde je ale vyžadováno technologicky kompatibilní diskové pole a SAN infrastruktura potřebné propustnosti pro synchronní spojení diskových polí. Alternativně je možné pro nižší požadavky na časové obnovení použít okamžitých kopií dat, které se pak přesunou do záložní lokality kopírováním prostřednictvím například GLVM 21 nebo vystavení kopie dat jako NFS 22. Data je pak možné kopírovat prostřednictvím LAN sítě a není potřeba budovat náročnou SAN infrastrukturu. To ovšem platí tehdy, pokud jsme schopni data přesunout v požadovaném časovém okně, které nám vyplývá z požadavku na obnovu. Pokud jsou data kopírována na DR lokalitu, je možné v případě katastrofy rozhodnutí administrátora o přesunu produkce do DR lokality, pokud to bude nezbytně nutné. 21 GLVM Geographic LVM rozšíření LVM o možnost vzdálené správy a zrcadlení dat. 22 NFS Network File Systém souborový systém přístupný po síti LAN/WAN. 32

33 Takto se postupovalo u firem, které měly primární datová centra v Praze Holešovicích při záplavách v roce 2002 a měly vybudované DR lokality na jiných místech v Praze a okolí. Následující tabulka č. 9 zhodnocuje jednotlivé řešení podle vlastností replikací dat, kterými disponují. Nelze jednoznačně říci, které z řešení je lepší a které je horší. Vždy se musí řešet případ od případu. Argumenty pro konkrétní řešení budou ovlivňovat mnohé parametry, o kterých jsem se již zmínil v této kapitole. Především je to velikost dat, možnost jejich ztráty definovaná v DR konceptu, požadavky na vzdálenost lokalit a času potřebného na fail-over. Pokud máme tyto informace, můžeme vybrat správné a také dostatečné řešení DR konceptu s ohledem na rozpočet, který nakonec ovlivní celkový návrh nejvíce. Řešení replikace DAT Vzdálenost Tabulka 9: Přehled vlastností replikace dat pro jednotlivé DR řešení. OS LVM, GLVM Remote Mirroring diskových polí 4Gb do 150m, 2 Gb/s do 4Gb do 150m, 2 Gb/s do 250m a 1 Gb/s do 500m. 250m a 1 Gb/s do 500m. Pro větší vzdálenosti je Pro větší vzdálenosti je potřeba LW propojení. potřeba LW propojení. Náklady Na větší vzdálenost LW komponenty (Gbic) v aktivních prvcích a FC linka mezi lokalitami. Aktivace funkcionality na diskových polí. Většinou za oplatek. Dále na větší vzdálenost LW komponenty (Gbic) v aktivních prvcích a FC linka mezi lokalitami. DB Replikace Omezená propustností LAN/WAN až 100ky km DB replikační nástroje. Buďto obsažené v DB stroji nebo nadstavbový produkt. Existuje i možnost využití produktu třetích stran pro náš DB stroj. Rozšíření Nad 500m je potřeba LW Nad 500m je potřeba LW Propustnost LAN/WAN Gbic potřebného výkonu Gbic potřebného výkonu například 10km a vhodné například 10km a vhodné linky. linky. Infrastruktura Nutné pořídit LW Gbic do Nutné pořídit LW Gbic do Pronájem větší SAN switchů a dimenzovat SAN switchů a dimenzovat propustnosti. Většinou propojení včetně počtu FC propojení včetně počtu FC levnější a dostupnější než u vláken. vláken. FC linek. Hodnocení Nejjednodušší řešení a Vyžaduje pokročilé funkce DB Replikace jsou cenově nejpříznivější. diskových polí a dokáže nejpoužívanější řešení pro Vzdálenost lokalit je eliminovat problémy prostředí, kde potřebujeme závislá na výkonu do DR lokality kopírovat infrastruktury a její latenci. pouze DB data. Ostatní data Pro větší datové objemy je musíme zajišťovat jiným toto řešení nevhodné. V způsobem. Často je v případě re-synchronizaci zrcadlení disků LVM manažerem by nastala dlouhodobá utilizace předchozí varianty (LVM). Není závislá na velikosti dat. Spíše je toto řešení zvoleno pro velké datové objemy. Replikace na pozadí diskových polí navíc nezatěžuje servery a poskytuje ma Enterprise prostředí doplněno o RM nebo LVM pokud je to možné. Pokud je doplněno o RM Zdroj: Vlastní. 33

34 2.3.4 Třída 3 1 V těchto třídách se předpokládá vytvoření off-site 23 kopií zálohovaných dat, které jsou uchovávány na bezpečných místech. Ideálně pokud jsou převáženy do DR lokality, kde jsou ukládány do trezoru pro potřebu obnovy dat v případě zničení produkčního datového centra. V lepším případě jsou použity pro kopírování dat na diskové pole DR lokality a tím je zároveň ověřeno, zda zálohovací systém pracuje správně a máme data skutečně aktivně zálohována. Při použití této metody pro zálohování datového centra je jasné, že naše poslední data jsou ta, která máme na posledních zálohovacích médiích. Proto je potřeba s nimi podle toho zacházet. Obnova provozu z DR lokality je pak dána množstvím dat, která přenášíme a stavem infrastruktury, kterou máme v DR lokalitě připravenou. Z praxe jsou známé i příklady, kdy zákazník má přesně definovaný seznam potřebného hardware pro obnovu a ten mu zajišťuje smluvní partner pro případ obnovy data centra. Osobně nevlastní žádný hardware, jen má za poplatek ošetřený servis typu Business Continuity Service. Tento systém zajištění dostupnosti vlastní služby cizím subjektem již přechází v částečný outsourcing. 23 Off-site kopie, zálohy dat, které jsou uchovávány mimo hlavní datové centrum. 34

35 3 Efektivní využívání hardwarových zdrojů Důvod, proč je virtualizace citována téměř v každém článku, který je dnes publikován, je celkem zřejmý. Počty serverů rapidně narůstají a je potřeba řešit jejich efektivní využívání. Z vlastní zkušenosti mohu potvrdit, že průměrná utilizace serveru s architekturou x86 je cca 15 % a pro RISC architekturu cca 25 %. Na první pohled to může vypadat nereálně, protože každý z nás má pocit, že server, na kterém právě pracuje, je málo výkonný a potřeboval by přidat nějaký ten výkon navíc nebo rovnou vyměnit. Jak to tedy je s průměrným využitím výkonu serveru. Pro zajímavost jsem použil výkonový snímek serveru, používaného ve společnosti, kde slouží pro výrobu, fakturaci, expedici atd. Obrázek 7: Snímek utilizace procesorů serveru IBM System p 560. CPU Total a User% Sys% Wait% :10 00:40 01:10 01:40 02:10 02:40 03:10 03:40 04:10 04:40 05:10 05:40 06:10 06:40 07:10 07:40 08:10 08:40 09:10 09:40 10:10 10:40 11:10 11:40 12:10 12:40 13:10 13:40 14:10 14:40 15:11 15:41 16:11 16:41 17:11 17:41 18:11 18:41 19:11 19:41 20:11 20:41 21:11 Zdroj: IBM Global Services monitoring serveru zákazníka v ČR. Z uvedeného obrázku č. 7 je patrné, že server je ve špičce vytížen na maximálně na 50 %, ale v průměru je vytížení podstatně menší. Tento příklad je poněkud odlišný, než je běžná praxe. Většinou se projevují v klasické obchodní firmě 3 špičky za den. Jedná se o příchod pracovníků do kanceláří a dopolední agenda. Druhá špička nastává odpoledne po obědě a končí odchodem zaměstnanců domů. Třetí fáze je servisní, která nastává po odchodu pracovníků. Systémy začínají zpracovávat dávkově data, replikovat je do jiných systémů a nakonec proběhne denní záloha. Tyto činnosti musí být hotové před příchodem zaměstnanců další den. Pokud si představíme, že takto vypadá normální běh všech serverů ve všech společnostech tak je zde otevřená otázka co s výkonem serverů po dobu, kdy je nikdo nepotřebuje. 35

36 Odpovědí na mnoho podobných otázek je serverová virtualizace. 3.1 Virtualizace serverů Virtualizace je technologie, která je jednoznačně přináší největší úspory nejen při konsolidačních projektech, ale také při nasazování aplikací v malých a středních firmách. Existuje mnoho systémů pro virtualizaci hardware zdrojů. Nejefektivnější jsou koncepty pracující přímo na úrovni samotného hardware. Existují i software nadstavby, které emulují virtualizační vrstvu jako nadstavbu hardware, který nedisponuje vlastní virtualizační technologií. Na obrázku č. 8 je znázorněný princip virtualizace. Větší množství malých nebo málo výkonných serverů je konsolidováno do virtuálních serverů nad jedním nebo více výkonnými servery. Předpokladem úspěchu je vyřešení nízké vytíženosti malých serverů a naopak zajištění daleko vyšší vytíženosti větších serverů. Obrázek 8: Blokové schéma konsolidace a virtualizace serverů. Virtuální server 1 Virtuální server 2 Virtuální server 3 Virtuální server 4 Virtuální server 5 Virtuální server 6 Zdroj: Vlastní. Důležitou vlastností operačních a vizualizačních systémů je oddělení jednotlivých aplikací s nejvyšší možnou bezpečností tak, aby nebyly vzájemně ovlivnitelné. Pro certifikaci 36

Město Varnsdorf, nám. E. Beneše 470, 407 47 Varnsdorf, Česká republika SPECIFIKACE

Město Varnsdorf, nám. E. Beneše 470, 407 47 Varnsdorf, Česká republika SPECIFIKACE Město Varnsdorf, nám. E. Beneše 470, 407 47 Varnsdorf, Česká republika SPECIFIKACE VYBUDOVÁNÍ TECHNOLOGICKÉHO CENTRA ORP VARNSDORF část I Pořízení technické infrastruktury pro vybavení Technologického

Více

Příloha č.2 - Technická specifikace předmětu veřejné zakázky

Příloha č.2 - Technická specifikace předmětu veřejné zakázky Příloha č.2 - Technická specifikace předmětu veřejné zakázky Popis stávajícího řešení u zadavatele Česká centra (dále jen ČC ) provozují 8 fyzických serverů, připojené k local storage. Servery jsou rozděleny

Více

IT 3. Projekt centrálního zálohovacího systému v ČSOB Pojišťovně. Michal Mikulík. špička v každém směru

IT 3. Projekt centrálního zálohovacího systému v ČSOB Pojišťovně. Michal Mikulík. špička v každém směru Projekt centrálního zálohovacího systému v ČSOB Pojišťovně Michal Mikulík špička v každém směru Krátce o DELTAX Systems a.s. významný systémový integrátor technologická infrastruktura TOP 10 SI 2003, 2005,

Více

Jak spustit provoz v DR lokalitě snadno a rychle

Jak spustit provoz v DR lokalitě snadno a rychle Moderní a spolehlivá řešení pro ukládání dat Jak spustit provoz v DR lokalitě snadno a rychle David Gottvald GAPP System Požadavky zákazníků Potřebujeme mít data ve druhé lokalitě pro případ katastrofy.

Více

CHARAKTERISTIKA VEŘEJNÉ ZAKÁZKY

CHARAKTERISTIKA VEŘEJNÉ ZAKÁZKY Příloha č. 1 CHARAKTERISTIKA VEŘEJNÉ ZAKÁZKY Veřejná zakázka Poskytování služeb outsourcingu Zadavatel: Nemocnice Český Krumlov a.s., sídlem: Český Krumlov, Horní Brána 429, PSČ 381 27 IČ: 260 95 149 DIČ:

Více

Služby datového centra

Služby datového centra Služby datového centra Společnost DataSpring je poskytovatelem služeb ICT infrastruktury a provozu IT řešení, veškeré služby provozuje ve vlastních datových centrech v Praze (Lucerna) a v Lužicích u Hodonína.

Více

VÝZVA K PODÁNÍ NABÍDKY. Ukládání, zálohování a archivace dat

VÝZVA K PODÁNÍ NABÍDKY. Ukládání, zálohování a archivace dat Městský úřad, Odbor informatiky Váš dopis zn.: ze dne: Číslo jednací: Číslo evidenční: Více dodavatelů Vyřizuje: Tel.: E-mail: Datum: Místo: Kamil Válek 572 615 131 kamil.valek@ub.cz 2008-11-13 Uherský

Více

INTEGRACE IS DO STÁVAJÍCÍ HW A SW ARCHITEKTURY

INTEGRACE IS DO STÁVAJÍCÍ HW A SW ARCHITEKTURY INTEGRACE IS DO STÁVAJÍCÍ HW A SW ARCHITEKTURY Dušan Kajzar Slezská univerzita v Opavě, Filozoficko-přírodovědecká fakulta, Bezručovo nám. 13, 746 00 Opava, e-mail: d.kajzar@c-box.cz Česká pošta, s.p.,

Více

Datová úložiště. Zdroj: IBM

Datová úložiště. Zdroj: IBM Datová úložiště Zdroj: IBM Malé ohlédnutí Malé ohlédnutí Malé ohlédnutí (?) Ukládání dat domácí Uložení na pevný disk počítače Použití pro malé objemy Typicky domácí a kancelářské použití Když záloha,

Více

TSM for Virtual Environments Data Protection for VMware v6.3. Ondřej Bláha CEE+R Tivoli Storage Team Leader. TSM architektura. 2012 IBM Corporation

TSM for Virtual Environments Data Protection for VMware v6.3. Ondřej Bláha CEE+R Tivoli Storage Team Leader. TSM architektura. 2012 IBM Corporation TSM for Virtual Environments Data Protection for VMware v6.3 Ondřej Bláha CEE+R Tivoli Storage Team Leader TSM architektura 2012 IBM Corporation Tradiční zálohování a obnova dat ze strany virtuálního stroje

Více

Copyright 2012 EMC Corporation. All rights reserved.

Copyright 2012 EMC Corporation. All rights reserved. 1 DISASTER RECOVERY kritických podnikových aplikací a systémů 2 GAPP System, spol. s r.o. Na trhu od roku 1994 Od roku 1996 dodáváme SW vybavení NetWorker Nyní kompletní portfolio EMC Specializace Zálohování

Více

Rychlá obnova dat efektivně a jednoduše

Rychlá obnova dat efektivně a jednoduše Rychlá obnova dat efektivně a jednoduše Jindřich Rosička Technický ředitel jindrich.rosicka@is4tech.cz www.is4tech.cz Množství dat Jak na pasivní bezpečnost? 3000 2500 2000 1500 1000 500 0 0 5 10 15 20

Více

Zvýhodněné ceny: 3.999, * (6x 1TB SATA) nebo 10.499, * (12x 2TB SATA) Pouze do 30. dubna 2011!

Zvýhodněné ceny: 3.999, * (6x 1TB SATA) nebo 10.499, * (12x 2TB SATA) Pouze do 30. dubna 2011! Unikátní pokročilé funkce nyní za cenu low-endu NetApp FAS2020 Zvýhodněné ceny: 3.999, * (6x 1TB SATA) nebo 10.499, * (12x 2TB SATA) Pouze do 30. dubna 2011! Velmi jednoduchá a efektivní správa celého

Více

Outsourcing v podmínkách Statutárního města Ostravy

Outsourcing v podmínkách Statutárního města Ostravy Outsourcing v podmínkách Statutárního města Ostravy Říjen 2009 Ing. Stanislav Richtar Ředitel společnosti 1 OBSAH PREZENTACE 1. Outsourcing - obecně 2. Výchozí stav projektu 3. Model poskytovaných služeb

Více

Optimalizaci aplikací. Ing. Martin Pavlica

Optimalizaci aplikací. Ing. Martin Pavlica Optimalizaci aplikací Ing. Martin Pavlica Vize: Aplikace v dnešním světě IT Ze všech částí IT jsou aplikace nejblíže businessu V elektronizovaném světě významným způsobem podporují business, ten se na

Více

Disková pole (RAID) 1

Disková pole (RAID) 1 Disková pole (RAID) 1 Architektury RAID Základní myšlenka: snaha o zpracování dat paralelně. Pozice diskové paměti v klasickém personálním počítači vyhovuje pro aplikace s jedním uživatelem. Řešení: data

Více

IBM Tivoli Storage Manager 6.2 a IBM Tivoli Storage Manager FastBack 6.1.1

IBM Tivoli Storage Manager 6.2 a IBM Tivoli Storage Manager FastBack 6.1.1 IBM Tivoli Storage Manager 6.2 a IBM Tivoli Storage Manager FastBack 6.1.1 Reporting a Monitoring Ondřej Bláha CEE+R CoP Team / Tivoli Storage Team Leader Září 2010 2010 IBM Corporation TSM 6: Reporting

Více

Odbor informatiky a provozu informačních technologií

Odbor informatiky a provozu informačních technologií POLICEJNÍ PREZIDIUM ČR Odbor informatiky a provozu informačních technologií Příloha č. 1 a) název zakázky, Technická podpora software pro systém NS-VIS a VISMAIL b) předmět a rozsah plnění veřejné zakázky

Více

Část 1. Technická specifikace. Posílení ochrany demokratické společnosti proti terorismu a extremismu

Část 1. Technická specifikace. Posílení ochrany demokratické společnosti proti terorismu a extremismu příloha č. 1 k PPR-15689-2/ČJ-2013-990656 Část 1 Technická specifikace Posílení ochrany demokratické společnosti proti terorismu a extremismu Předmět Veřejné zakázky: Řešení pro dodání speciálního SW pro

Více

Wonderware Historian 10.0

Wonderware Historian 10.0 Wonderware Historian 10.0 Příklady vícevrstvých architektur Jiří Nikl Pantek (CS) s.r.o. Strana 2 Wonderware Historian 10.0 využití vícevrstvé architektury Nová verze historizační databáze Wonderware Historian

Více

MARIE PACS S PACSem hezky od podlahy když se data sypou!

MARIE PACS S PACSem hezky od podlahy když se data sypou! MARIE PACS S PACSem hezky od podlahy když se data sypou! Telemedicína, Brno, 3. března 2014 RNDr. Milan Pilný MARIE PACS Je to systém pro práci s obrazovými DICOM daty v medicíně. Je klasifikován jako

Více

Copyright 2012 EMC Corporation. All rights reserved.

Copyright 2012 EMC Corporation. All rights reserved. 1 EMC VPLEX Architektura pro mobilitu a vysokou dostupnost v EMC hybridním cloudu Vaclav.Sindelar@EMC.com 2 Cíl prezentace Na konci této prezentace porozumíme interní architektuře VPLEX Local, VPLEX Metro

Více

Na co se ptát poskytovatele cloudových služeb?

Na co se ptát poskytovatele cloudových služeb? Na co se ptát poskytovatele cloudových služeb? Tomáš Novák, technický ředitel December 08 th 2015 2015 Cloud4com, a.s. All rights reserved. www.cloud4com.com Společnost Cloud4com, a.s. Přední český poskytovatel

Více

VYSOKÁ ŠKOLA BÁŇSKÁ TECHNICKÁ UNIVERZITA OSTRAVA FAKULTA STROJNÍ

VYSOKÁ ŠKOLA BÁŇSKÁ TECHNICKÁ UNIVERZITA OSTRAVA FAKULTA STROJNÍ VYSOKÁ ŠKOLA BÁŇSKÁ TECHNICKÁ UNIVERZITA OSTRAVA FAKULTA STROJNÍ DATABÁZOVÉ SYSTÉMY ZÁLOHOVÁNÍ DAT V DATABÁZI Ing. Lukáš OTTE, Ph.D. Ostrava 2013 Tento studijní materiál vznikl za finanční podpory Evropského

Více

Není cloud jako cloud, rozhodujte se podle bezpečnosti

Není cloud jako cloud, rozhodujte se podle bezpečnosti Není cloud jako cloud, rozhodujte se podle bezpečnosti Marcel Jánský Manažer útvaru produktů a podpory prodeje 26. 2. 2013 České Radiokomunikace Vysílací služby Profesionální telekomunikační operátor Poskytovatel

Více

Kruhová topologie v bezdrátových sítích. Cesta ke zvýšení dostupnosti služeb

Kruhová topologie v bezdrátových sítích. Cesta ke zvýšení dostupnosti služeb Kruhová topologie v bezdrátových sítích Cesta ke zvýšení dostupnosti služeb Služby náročné na dostupnost internetu On-line hry Obchodování na finančních trzích VoIP telefonování Video přenosy On-line rádia

Více

SSD akcelerátor v PCIe slotu. Až 25 SSD/SAS/NL-SAS disků na jeden server

SSD akcelerátor v PCIe slotu. Až 25 SSD/SAS/NL-SAS disků na jeden server AC Privátní Cloud Popis funkcí 1. Základní stavební jednotka - x86 server Základní stavební jednotkou systému jsou 2U x86 servery, které slouží zároveň pro ukládání dat (storage cluster) i jako HW vrstva

Více

Využití moderních přístupů při budování Technologického centra kraje

Využití moderních přístupů při budování Technologického centra kraje Využití moderních přístupů při budování Technologického centra kraje Tomáš Horák, CCIE #11783 Systems Engineer, Data Center & Collaboration Email/XMPP: tohorak@cisco.com 2012 Cisco and/or its affiliates.

Více

O jedné metodě migrace velkých objemů dat aneb cesta ke snižování nákladů

O jedné metodě migrace velkých objemů dat aneb cesta ke snižování nákladů Ladislav Müller IBM GTS 9.2.2010 O jedné metodě migrace velkých objemů dat aneb cesta ke snižování nákladů Proč takové téma Objemy zpracovávaných dat rychle rostou Úkoly, které jsou při menším objemu dat

Více

Nimbus Data All Flash Systems

Nimbus Data All Flash Systems Moderní a spolehlivá řešení pro ukládání dat Nimbus Data All Flash Systems David Gottvald GAPP System All-Flash Systems Budoucnost je v technologii All-Flash Array. Performance poskytuje konzistentní a

Více

BrightStor ARCserve Backup r11.5. - Michal Opatřil - Consultant - michal.opatril@ca.com

BrightStor ARCserve Backup r11.5. - Michal Opatřil - Consultant - michal.opatril@ca.com BrightStor ARCserve Backup r11.5 - Michal Opatřil - Consultant - michal.opatril@ca.com Co je ARCserve Backup? -Spolehlivý a jednoduchý Backup a Restore -S podporou široké škály hardwaru -S managementem

Více

Celková správa sítě SAN IBM Tivoli Storage Productivity Center v4.2

Celková správa sítě SAN IBM Tivoli Storage Productivity Center v4.2 Celková správa sítě SAN IBM Tivoli Storage Productivity Center v4.2 Ondřej Blaha CEE+R CoP / Tivoli Storage Team Leader Co představuje síť Storage Area Network Storage area network (zkratka SAN) je dedikovaná

Více

Jan Tkáč 27.5. 2014. AutoCont Privátní cloud

Jan Tkáč 27.5. 2014. AutoCont Privátní cloud Jan Tkáč 27.5. 2014 AutoCont Privátní cloud Co je to AC Privátní cloud? AC Privátní cloud = vlastní produkt AutoContu AC Privátní cloud = Privátní datacentrum, které se nespravuje AC Privátní cloud = UNIKÁTNÍ

Více

Wonderware Historian. Příklady vícevrstvých architektur. Jiří Nikl, Tomáš Mandys Pantek (CS) s.r.o.

Wonderware Historian. Příklady vícevrstvých architektur. Jiří Nikl, Tomáš Mandys Pantek (CS) s.r.o. Wonderware Historian Příklady vícevrstvých architektur Jiří Nikl, Tomáš Mandys Pantek (CS) s.r.o. Strana 2 Wonderware Historian Server využití vícevrstvé architektury Historizační databáze Wonderware Historian

Více

Zajištění komplexních sluţeb pro provoz systémové infrastruktury OSMS ZADÁVACÍ DOKUMENTACE

Zajištění komplexních sluţeb pro provoz systémové infrastruktury OSMS ZADÁVACÍ DOKUMENTACE Zajištění komplexních sluţeb pro provoz systémové infrastruktury OSMS ZADÁVACÍ PŘÍLOHA Č. 4 POPIS STÁVAJÍCÍHO STAVU Následující kapitola přináší popis stávající informačně-technologické systémové infrastruktury

Více

Jak být online a ušetřit? Ing. Ondřej Helar

Jak být online a ušetřit? Ing. Ondřej Helar Jak být online a ušetřit? Ing. Ondřej Helar Obsah Co znamená být online ve škole? Rizika online přístupu Skryté náklady na straně školy Jak snížit rizika a náklady? Koncepce SaaS (Software as a Service)

Více

TECHNICKÁ SPECIFIKACE

TECHNICKÁ SPECIFIKACE TECHNICKÁ SPECIFIKACE Zabezpečení dat a komunikační infrastruktury opakované vyhlášení části B - Tabulka pro rozšíření nad rámec minimálních technických požadavků Typ Popis rozšířeného požadavku Splněno

Více

Softwarové balíky & bundles

Softwarové balíky & bundles Softwarové balíky & bundles Balíky & bundles V 6 softwarových balících je obsaženo více než 30 softwarových produktů Rozšíření základního NetApp FAS systému o softwarové nástroje ZDARMA Jednoduché sestavení

Více

Zálohování a rychlá obnova dat Konsolidace serverů a diskových polí Archivace elektronické pošty

Zálohování a rychlá obnova dat Konsolidace serverů a diskových polí Archivace elektronické pošty Zálohování a rychlá obnova dat Konsolidace serverů a diskových polí Archivace elektronické pošty Prezentace pro Kraj Vysočina 1. 2. 2006 Jiří Palkovský Petržílkova 23, Praha 5 tel. +420 251 610 285 fax:

Více

Ondřej Lorenc System x a virtualizace ondrej_lorenc@cz.ibm.com

Ondřej Lorenc System x a virtualizace ondrej_lorenc@cz.ibm.com Ondřej Lorenc System x a virtualizace ondrej_lorenc@cz.ibm.com 1 2 Virtualization on System x and BladeCenter IBM System x and IBM BladeCenter servers are designed for virtualization, leveraging the 40-year

Více

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Microsoft SharePoint Portal Server 2003 Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Přehled Země: Česká republika Odvětví: Velkoobchod Profil zákazníka

Více

www.cdc-monitoring.cz

www.cdc-monitoring.cz Monitoring sítí a serverů Dnešní požadavky na výkon ethernetových, wifi nebo jiných sítí, jejich serverů a aktivních prvků jsou velmi striktně nastaveny. Síť musí být koncipována tak, aby byla zaručena

Více

Koncept centrálního monitoringu a IP správy sítě

Koncept centrálního monitoringu a IP správy sítě Koncept centrálního monitoringu a IP správy sítě Implementace prostředí MoNet a AddNet Jindřich Šavel 31/5/2013 NOVICOM s.r.o. 2012 2013 Novicom All rights s.r.o. reserved. All rights reserved www.novicom.cz,

Více

Projekt 7006/2014 SDAT - Sběr dat pro potřeby ČNB. Návrh realizace řešení

Projekt 7006/2014 SDAT - Sběr dat pro potřeby ČNB. Návrh realizace řešení Projekt 7006/2014 SDAT - Sběr dat pro potřeby ČNB Návrh realizace řešení Tento dokument obsahuje informace důvěrného charakteru a informace v něm obsažené jsou vlastnictvím České národní banky. Žádná část

Více

Storage jako služba. Milan Petrásek Strategy product manager, GTS Czech 21.2.2012

Storage jako služba. Milan Petrásek Strategy product manager, GTS Czech 21.2.2012 Storage jako služba Milan Petrásek Strategy product manager, GTS Czech 21.2.2012 Anotace Objem dat na trhu roste exponenciálně a data se stávají klíčovým pro úspěch v podnikání. GTS je leader v oblasti

Více

IBM TotalStorage Productivity Center Overview

IBM TotalStorage Productivity Center Overview IBM TotalStorage Productivity Center Overview Ondřej Bláha IT Specialist oblaha@cz.ibm.com Důležité otázky na které má IBM TPC Center odpověď Kolik volného diskového prostoru mám k dispozici pro své aplikace?

Více

Příloha č. 1 k Č.j.: OOP/10039/2-2011 Specifikace zařízení

Příloha č. 1 k Č.j.: OOP/10039/2-2011 Specifikace zařízení Příloha č. 1 k Č.j.: OOP/10039/2-2011 Specifikace zařízení Zadavatel požaduje dodávku 16 kusů serverů a 4kusů síťových datových úložišť. Servery se požadují bez dodání operačního systému. Specifikace minimálních

Více

IBM Storwize Rapid Application Storage. Ondřej Bláha. CEE+R CoP Tivoli Storage Team Leader 2.2.2011

IBM Storwize Rapid Application Storage. Ondřej Bláha. CEE+R CoP Tivoli Storage Team Leader 2.2.2011 IBM Storwize Rapid Application Storage Ondřej Bláha CEE+R CoP Tivoli Storage Team Leader 2.2.2011 Firemní data, databáze, poštovní aplikace nebo ERP jsou Life Blood of a Business Finanční ztráta nebo poškození

Více

Efektivní ochrana dat ve virtualizovaném prostředí. Marek Bradáč

Efektivní ochrana dat ve virtualizovaném prostředí. Marek Bradáč Efektivní ochrana dat ve virtualizovaném prostředí Marek Bradáč Agenda Představení TSM for Virtual Environments 6.2 Praktická ukázka (video) 2 Úvod IBM Tivoli Storage Manager Vám může pomoci: Snížením

Více

Virtualizace storage infrastruktury

Virtualizace storage infrastruktury Virtualizace storage infrastruktury Ctirad Navrátil C&SI Client Technical Professional ctirad_navratil@cz.ibm.com SVC co v současnosti nabízí (funkční pohled) Caching 100% Virtualizce diskových polí Real-time

Více

Zkušenosti z průběhu nasazení virtualizace a nástrojů pro správu infrastruktury v IT prostředí České správy sociálního zabezpečení

Zkušenosti z průběhu nasazení virtualizace a nástrojů pro správu infrastruktury v IT prostředí České správy sociálního zabezpečení Zkušenosti z průběhu nasazení virtualizace a nástrojů pro správu infrastruktury v IT prostředí České správy sociálního zabezpečení Konference ISSS, Hradec Králové, 5. 4. 2011 Michal Osif, Senior Architect

Více

Portfolio úložišť WD pro datová centra Kapacitní úložiště prošlo vývojem

Portfolio úložišť WD pro datová centra Kapacitní úložiště prošlo vývojem Kapacitní úložiště, které posune váš výkon k inovacím. WD a logo WD jsou registrované ochranné známky společnosti Western Digital Technologies, Inc. v USA a dalších zemích; WD Ae, WD Re+, WD Re, WD Se,

Více

Příloha č. 3: Technické zadání zakázky Instalace a služby pro technologické centrum MÚ Pohořelice

Příloha č. 3: Technické zadání zakázky Instalace a služby pro technologické centrum MÚ Pohořelice Příloha č. 3: Technické zadání zakázky Instalace a služby pro technologické centrum MÚ Pohořelice Účelem veřejné zakázky je vybudování, provoz a údržba infrastruktury pro provozování aplikací a služeb

Více

Red Hat Enterprise Virtualization

Red Hat Enterprise Virtualization Red Hat Enterprise Virtualization Nové produkty Red Hat v oblasti virtualizace Ondřej Suchý, RHCVSP Enlogit s.r.o. Část 1 O Enlogit Enlogit: o nás IT pro firmy primární zaměření: služby významný implementátor

Více

Případové studie a kulatý stůl. Dalibor Kačmář, Microsoft

Případové studie a kulatý stůl. Dalibor Kačmář, Microsoft Případové studie a kulatý stůl Dalibor Kačmář, Microsoft Případová studie využití Microsoft Azure společnosti Ness Akviziční systém společnosti Cofidis Vysoká dostupnost celého řešení Zeštíhlení IT oddělení

Více

Migrace kompletní IT infrastruktury do prostředí Microsoft Azure

Migrace kompletní IT infrastruktury do prostředí Microsoft Azure Případová studie Migrace kompletní IT infrastruktury do prostředí Microsoft Azure Millennium je první společnost na Slovensku, která zcela zmigrovala svou IT infrastrukturu a profituje z flexibility a

Více

Zajištění rozvoje komunikační a systémové infrastruktury MPSV_I.

Zajištění rozvoje komunikační a systémové infrastruktury MPSV_I. Veřejná zakázka Zajištění rozvoje komunikační a systémové infrastruktury MPSV_I. zadávaná v otevřeném nadlimitním řízení dle zákona č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů

Více

Disaster recovery as a service od společnosti GAPP System

Disaster recovery as a service od společnosti GAPP System Konference GAPP 2015 Disaster recovery as a service od společnosti GAPP System Jan Cipra Motivace Není to jen o přírodních katastrofách HW nebo SW závada Počítačový virus Lidské selhání Neřeší jen Disaster

Více

VÝBĚR CLOUDU, ANEB JAK ZVOLIT TEN NEJLEPŠÍ

VÝBĚR CLOUDU, ANEB JAK ZVOLIT TEN NEJLEPŠÍ VÝBĚR CLOUDU, ANEB JAK ZVOLIT TEN NEJLEPŠÍ Infinity, a.s. U Panasonicu 375 Pardubice 530 06 Tel.: (+420) 467 005 333 www.infinity.cz PROČ SE ZABÝVAT VÝBĚREM CLOUDU 2 IT služba Jakákoliv služba poskytovaná

Více

Příloha č. 1 Servisní smlouvy. Katalog služeb. S2_P1_Katalog služeb

Příloha č. 1 Servisní smlouvy. Katalog služeb. S2_P1_Katalog služeb Příloha č. 1 Servisní smlouvy Katalog služeb S2_P1_Katalog služeb 1 Obsah 1 OBSAH... 2 2 DEFINICE SLUŽEB... 3 3 SPECIFIKACE SLUŽEB... 6 3.1 SLUŽBA PS01_PROVOZ A SPRÁVA... 6 3.2 SLUŽBA PS02_ZÁLOHA A OBNOVA...

Více

Moderní infrastruktura základ egovernmentu

Moderní infrastruktura základ egovernmentu Moderní infrastruktura základ egovernmentu www.huawei.com Tomáš Zloch tomas.zloch@huawei.com Úspory vs vyšší požadavky Snaha šetřit vs Požadavky na moderní služby Page 2 Vize... Digitalizace Centralizace

Více

Disková pole (RAID) 1

Disková pole (RAID) 1 Disková pole (RAID) 1 Architektury RAID Důvod zavedení RAID: reakce na zvyšující se rychlost procesoru. Pozice diskové paměti v klasickém personálním počítači vyhovuje pro aplikace s jedním uživatelem.

Více

Příspěvek je věnován základním informacím o způsobu volby vhodné strategie řízení kontinuity činností v organizaci.

Příspěvek je věnován základním informacím o způsobu volby vhodné strategie řízení kontinuity činností v organizaci. Mgr. Monika Johaníková Ochrana & Bezpečnost 2013, ročník II., č. 3 (podzim), ISSN 1805-5656 Stanovení strategie řízení kontinuity činností Anotace Příspěvek je věnován základním informacím o způsobu volby

Více

HP-USS: IT tak, jak potřebujete Karel Kotrba ředitel Enterprise Services HP ČR

HP-USS: IT tak, jak potřebujete Karel Kotrba ředitel Enterprise Services HP ČR HP-USS: IT tak, jak potřebujete Karel Kotrba ředitel Enterprise Services HP ČR Produkty a služby Enterprise services HP Virtualizace IT Systémy a služby Automatizace Řešení pro datová centra Managemen

Více

IBM Cloud computing. Petr Leština Client IT Architect. Jak postavit enterprise cloud na klíč. 2011 IBM Corporation

IBM Cloud computing. Petr Leština Client IT Architect. Jak postavit enterprise cloud na klíč. 2011 IBM Corporation IBM Cloud computing Jak postavit enterprise cloud na klíč Petr Leština Client IT Architect Agenda Úvod Architektura privátního cloudu (IaaS a PaaS) Smart Cabinet pro provoz cloud infrastruktury Závěr Cloud

Více

Principy budování datového centra VŠB-TU Ostrava

Principy budování datového centra VŠB-TU Ostrava Principy budování datového centra VŠB-TU Ostrava Martin Pustka Martin.Pustka@vsb.cz EUROPEN, Herbertov, 11.-14.května 2014 Je kumšt postavit dobré IT? Je větší kumšt vyrobit dobré víno, nebo dobrý film?

Více

Bezpečnostní mechanismy serverové infrastruktury

Bezpečnostní mechanismy serverové infrastruktury Bezpečnostní mechanismy serverové infrastruktury Miroslav Novotný Setkání správců NIS Seč, 19. 20.5.2008 Bezpečnostní hrozby Výskyt bezpečnostních incidentů za poslední dva roky a trend výskytu: 1. SPAM,

Více

Technická specifikace vymezené části 1 SERVER

Technická specifikace vymezené části 1 SERVER Technická specifikace vymezené části 1 SERVER 1 Předmět vymezené části 1.1 Předmětem veřejné zakázky je dodávka a moderního a spolehlivého serverového řešení pro potřeby Krajského ředitelství PČR Karlovarského

Více

Aktivní bezpečnost sítě

Aktivní bezpečnost sítě Aktivní bezpečnost sítě Jindřich Šavel 27/11/2014 NOVICOM s.r.o. 2012 2014 Novicom All rights s.r.o. reserved. All rights reserved www.novicom.cz, sales@novicom.cz Program prezentace Představení společnosti

Více

1.05 Informační systémy a technologie

1.05 Informační systémy a technologie Vypracoval Gestor Schválil Listů Příloh D. Marek(EOS/2) EOS VS 5 Směrnice platí pro všechny závody ŠKODA AUTO. Obsah: 1. Použité pojmy a zkratky 2. Plánování IT 3. Pořízení IT 4. Dodání IT 5. Provoz a

Více

Česká pošta, s.p. na Linuxu. Pavel Janík open source konzultant

Česká pošta, s.p. na Linuxu. Pavel Janík open source konzultant Česká pošta, s.p. na Linuxu Pavel Janík open source konzultant Česká pošta, s.p. 1993: založen státní podnik Česká pošta oddělením od společnosti Český Telecom nezávislá na státním rozpočtu poskytuje listovní,

Více

Bc. David Gešvindr MSP MCSA MCTS MCITP MCPD

Bc. David Gešvindr MSP MCSA MCTS MCITP MCPD Bc. David Gešvindr MSP MCSA MCTS MCITP MCPD 1. Příprava k instalaci SQL Serveru 2. Instalace SQL Serveru 3. Základní konfigurace SQL Serveru Vychází ze Sybase SQL Server Verze Rok Název Codename 7.0 1998

Více

Katalog služeb a podmínky poskytování provozu

Katalog služeb a podmínky poskytování provozu Příloha č. 1 Servisní smlouvy Katalog služeb a podmínky poskytování provozu Část P2_1 P2_1_Katalog služeb a podmínky poskytování provozu 1 Obsah 1 OBSAH... 2 2 DEFINICE POJMŮ... 3 3 DEFINICE SLUŽEB, KOMPONENT

Více

Trendy v budování datových center v roce 2016. Praha, 7.4.2016

Trendy v budování datových center v roce 2016. Praha, 7.4.2016 Trendy v budování datových center v roce 2016 Praha, 7.4.2016 Analytici a GAPP System Čtyři pohledy na datové centrum Infrastruktura Provoz Byznys Bezpečnost Datové centrum Čtyři pohledy na datové centrum

Více

Alternativy k SAP HANA appliance? Představení možnosti TDI a cloudové infrastruktury

Alternativy k SAP HANA appliance? Představení možnosti TDI a cloudové infrastruktury Alternativy k SAP HANA appliance? Představení možnosti TDI a cloudové infrastruktury Jiří Vrbický Senior Architekt 10. září 2015 Infrastruktura pro SAP HANA Možnosti zajištění infrastruktury pro SAP HANA:

Více

Příloha č. 2 ke smlouvě. Rozsah a podmínky provozní podpory

Příloha č. 2 ke smlouvě. Rozsah a podmínky provozní podpory Příloha č. 2 ke smlouvě Rozsah a podmínky provozní podpory Předmět smlouvy v části Provozní podpora zahrnuje zejména: A) Technickou, uživatelskou a administrativní správu a provozní podporu APV IS ROS

Více

obnova ZIS po bezpečnostn nostním m incidentu

obnova ZIS po bezpečnostn nostním m incidentu Efektivní zálohování a obnova ZIS po bezpečnostn nostním m incidentu Miroslav Novotný Setkání informatiků a správc vců NIS Svratka 16.6. 2011 Zálohování vs. archivace Cíl zálohování: zachovat kontinuitu

Více

Zátěžové testy aplikací

Zátěžové testy aplikací Zátěžové testy aplikací Obsah Zátěžové testy v životním cyklu vývoje software Kdy a proč provádět zátěžové testy Projekt zátěžového testu Fáze zátěžového testu Software pro zátěžové testy Zátěžové testy

Více

Zálohování a obnova dat

Zálohování a obnova dat Zálohování a obnova dat Rychlá záloha a obnovení dat StorageCraft nabízí sadu nástrojů a služeb, které pomáhají obnovit data, kdykoli, kdekoli a za jakékoliv situace. Skvěle doplňuje antivirovou ochranu

Více

ReDefine Midrange Storage VNX/VNXe. Václav Šindelář, EMC

ReDefine Midrange Storage VNX/VNXe. Václav Šindelář, EMC ReDefine Midrange Storage VNX/VNXe Václav Šindelář, EMC 1 Rok 2000 2 FLASH disky mění disková pole Design storage systemů je limitován rozdílnou technologií disků Kapacita disků a jejich IOPS 1.2 1 400GB

Více

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence schopnost, který je spolufinancován

Více

Cloud - jak jej monitorovat, reporty, účtování a fakturace

Cloud - jak jej monitorovat, reporty, účtování a fakturace Cloud - jak jej monitorovat, reporty, účtování a fakturace Ctibor Duda, Client Technical Professional Ctirad Navrátil, Client Technical Professional 1 2011 IBM Corporation Co dělá cloud cloudem Workflow

Více

QTD spol. s r.o. NetVault Backup 10

QTD spol. s r.o. NetVault Backup 10 Backup QTD spol. s r.o. Backup 10 Jiří Nosál Jan Valenta www.qtd.cz Co je Backup? Backup Zálohovací software Vlastnosti Backup 10 Backup Podpora mnoha OS a aplikací -Windows, Linux, Mac OS, UNIX -Vmware,

Více

Zadavatel: Česká republika Český statistický úřad Na padesátém 81/3268 100 82 Praha 10 Strašnice IČO: 00025593

Zadavatel: Česká republika Český statistický úřad Na padesátém 81/3268 100 82 Praha 10 Strašnice IČO: 00025593 Zadavatel: Česká republika Český statistický úřad Na padesátém 81/3268 100 82 Praha 10 Strašnice IČO: 00025593 Veřejná zakázka: VZ004 ICT Dodávka a obnova ICT v rámci projektu Redesign statistického informačního

Více

Hynek Cihlář Podnikový architekt 7.11..2013. Od Indoše ke Cloudu

Hynek Cihlář Podnikový architekt 7.11..2013. Od Indoše ke Cloudu Hynek Cihlář Podnikový architekt 7.11..2013 Od Indoše ke Cloudu Jediná jistota je změna Rychlost vstupu na trh, zvyšování efektivity, zjednodušení funkčnosti, snižování nákladů Obtížnost řízení a kontroly

Více

Nová éra diskových polí IBM Enterprise diskové pole s nízkým TCO! Simon Podepřel, Storage Sales 2. 2. 2011

Nová éra diskových polí IBM Enterprise diskové pole s nízkým TCO! Simon Podepřel, Storage Sales 2. 2. 2011 Nová éra diskových polí IBM Enterprise diskové pole s nízkým TCO! Simon Podepřel, Storage Sales 2. 2. 2011 Klíčovéatributy Enterprise Information Infrastructure Spolehlivost Obchodní data jsou stále kritičtější,

Více

Dodatečné informace č. 7

Dodatečné informace č. 7 Dodatečné informace č. 7 V souladu s ustanoveními 49 zákona č. 137/2006 Sb., o veřejných zakázkách, ve znění pozdějších předpisů, poskytuje zadavatel dodatečné informace č. 7 k zadávacím podmínkám veřejné

Více

Virtualizace síťových prvků

Virtualizace síťových prvků Virtualizace síťových prvků Martin Pustka Martin.Pustka@vsb.cz EUROPEN, Herbertov, 11.-14.května 2014 O čem se budeme bavit... o virtualizaci síťových prvků provozovaných jako VM v virtualizačních infrastrukturách

Více

Implementace vysoce dostupné virtualizované IT infrastruktury

Implementace vysoce dostupné virtualizované IT infrastruktury Implementace vysoce dostupné virtualizované IT infrastruktury Společnost AŽD Praha nabízí ve svém portfoliu řadu profesionálních systémů řízení provozu a zajištění jeho bezpečnosti. Stejnou filosofii se

Více

Migrace virtuálního prostředí VI3 na vsphere. Lukáš Radil, konzultant

Migrace virtuálního prostředí VI3 na vsphere. Lukáš Radil, konzultant Migrace virtuálního prostředí VI3 na vsphere Lukáš Radil, konzultant Agenda Agenda Výchozí stav Agenda Výchozí stav Důvody pro migraci Agenda Výchozí stav Důvody pro migraci Příprava projektu Agenda Výchozí

Více

End User Experience Monitoring Měření kvality IT služeb 7.10.2010, Brno Jiří Vozňák. information technology

End User Experience Monitoring Měření kvality IT služeb 7.10.2010, Brno Jiří Vozňák. information technology End User Experience Monitoring Měření kvality IT služeb 7.10.2010, Brno Jiří Vozňák information technology Základ firemní strategie Strategie firmy Lidé Procesy Nástroje Portfolio nabídky a služeb Crux

Více

1.05 Informační systémy a technologie

1.05 Informační systémy a technologie Vypracoval Gestor Schválil Listů Příloh D. Marek(EOS/2) EOS VS 7 Směrnice platí pro všechny závody ŠKODA AUTO. Obsah: 1. Použité pojmy a zkratky 2. Plánování IT 3. Pořízení IT 4. Dodání IT 5. Provoz a

Více

Aktuální otázky provozu datových skladů PAVEL HNÍK

Aktuální otázky provozu datových skladů PAVEL HNÍK Aktuální otázky provozu datových skladů PAVEL HNÍK K čemu slouží datové sklady IT podporuje business podniků S velikostí podniku se zvyšuje náročnost zpracování dat DWH = unifikovaná datová základna pro

Více

Michal Hroch Server Product Manager Microsoft Česká republika

Michal Hroch Server Product Manager Microsoft Česká republika Michal Hroch Server Product Manager Microsoft Česká republika Proč by vás Platforma měla vůbec zajímat? záruka spolehlivosti potenciál pro nové příležitosti Performance Point server 6 Point of Sale Retail

Více

Pokročilé zálohování a monitoring ve virtuálním prostředí

Pokročilé zálohování a monitoring ve virtuálním prostředí Pokročilé zálohování a monitoring ve virtuálním prostředí Vladimír Jelen Channel Manager CZ, SK, HU +420 777 200 350 vladimir.jelen@veeam.com Veeam Backup & Replication pro VMware a Hyper-V Ochrana dat

Více

Storage Management Workload Management Backup and Recovery Management

Storage Management Workload Management Backup and Recovery Management Storage Management Workload Management Backup and Recovery Management Přednáška pro ISE 2. května 2014 Marek Rychlý (a Ivana Burgetová) Obsah Storage Management SAN, NAS, RAID Primární, sekundární, off-line

Více

Od virtualizace serverů k virtualizaci desktopů. Nebo opačně? Jaroslav Prodělal, OldanyGroup VMware VCP, consultant

Od virtualizace serverů k virtualizaci desktopů. Nebo opačně? Jaroslav Prodělal, OldanyGroup VMware VCP, consultant Od virtualizace serverů k virtualizaci desktopů. Nebo opačně? Jaroslav Prodělal, OldanyGroup VMware VCP, consultant Virtuální desktopová infrastruktura I. Virtuální desktopová infrastruktura II. využívání

Více

Virtualizace jako nástroj snížení nákladů. Periodické opakování nákladů nové verze Licence na pevný počet klientů

Virtualizace jako nástroj snížení nákladů. Periodické opakování nákladů nové verze Licence na pevný počet klientů Model Mainframe Centralizované řešení Cena za strojový čas Klientská zařízení nedisponují výkonem Vysoké pořizovací náklady na hardware Bez softwarových licencí software na míru Model Klient Server Přetrvává

Více

2.17 Archivace a komprimace dat

2.17 Archivace a komprimace dat Název školy Číslo projektu Autor Název šablony Název DUMu Tematická oblast Předmět Druh učebního materiálu Anotace Vybavení, pomůcky Ověřeno ve výuce dne, třída Střední průmyslová škola strojnická Vsetín

Více