UNICORNE COLLEGE BAKALÁŘSKÁ PRÁCE

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

Download "UNICORNE COLLEGE BAKALÁŘSKÁ PRÁCE"

Transkript

1 UNICORNE COLLEGE Katedra informačních technologií BAKALÁŘSKÁ PRÁCE Řešení vysoké dostupnosti databází z pohledu neplánovaných výpadků Autor BP: Jan Mikolášek Vedoucí BP: Ing. Miroslav Žďárský 2014 Praha

2

3

4 Čestné prohlášení Prohlašuji, že jsem svou bakalářskou práci na téma Řešení vysoké dostupnosti databází vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení 11 a následujících autorského zákona č. 121/2000 Sb. V Praze, dne (Jan Mikolášek)

5 Poděkování Děkuji vedoucímu mé bakalářské práce Ing. Miroslavu Žďárskému za odbornou pomoc a další užitečné technické rady při zpracování mé bakalářské práce.

6 Řešení vysoké dostupnosti databází z pohledu neplánovaných výpadků Solution of database high availability from the perspective of unplanned downtime 6

7 Abstrakt Cílem bakalářské práce je srovnání nejpoužívanějších databázových systému s ohledem na možnosti jejich nasazení do vysoce dostupného prostředí. V úvodu práce bude vysvětlen pojem vysoké dostupnosti ve světě informačních technologií a aspekty jeho nasazení, na které je třeba brát zřetel. Následuje popis čtyř databázových systému a to konkrétně možností, které poskytují pro zajištění vysoké dostupnosti. Další kapitola popisuje srovnávací kritéria použitá v této práci pro porovnání databázových systémů. Po této kapitole následuje vlastní srovnání, které je hlavním cílem této práce. Srovnání se netýká pouze možností pro řešení vysoké dostupnosti, ale také celkové robustnosti, požadavků na hardware a zotavení po havárii. Závěrem této práce je doporučení pro výběr konkrétního databázového systému dle požadavků na něj. Klíčová slova: vysoká dostupnost, databázový systém, cluster, zotavení po havárii, databázová transakce, replikace, redundance Abstract The goal of this bachelor work is to compare the most widely used database system with respect to their implementation in high available environment. The introduction will explain the concept of high availability in the world of information technology and its deployment aspects which should be taken into account. The following describes the four database system, specifically functionalities that provide for high availability. The next chapter describes the benchmarks used in this study to compare database systems. This chapter is followed by the comparison, which is the main objective of this work. The comparison is not only related to the options for high availability, but also the overall system robustness and requirements for hardware and disaster recovery. The conclusion of this work is the recommendation for the database system choice according to the requirements for it. Keywords: high availability, database system, cluster, disaster recovery, database transaction, replication, redundancy 7

8 Obsah Úvod 9 1. Co je vysoká dostupnost Plánované a neplánované výpadky Obecné řešení vysoké dostupnosti Celková dostupnost Řešení disaster recovery Klíčové prvky vysoké dostupnosti databázových systémů Dostupnost aplikace z pohledu klienta Data aplikace v režimu vysoké dostupnosti Transakce v režimu vysoké dostupnosti Řešení vysoké dostupnosti jednotlivých databází Oracle IBM DB Microsoft SQL server mysql Porovnání vlastností HA pro jednotlivé DB Active/Active versus Active/Passive Stanby systémy Disaster Recovery Správa běžících transakcí Rozšiřitelnost celkové infrastruktury Přístup klienta/aplikace Závislost na komponentách třetích stran Složitost a robustnost celkového řešení Vlastní srovnání Vyhodnocení jednotlivých řešení, doporučení Závěr Seznam použité literatury Seznam použitých zkratek Seznam obrázků Seznam tabulek 88 8

9 Úvod Takřka všechny společnosti, ať už velké, nebo malé, řeší problém dostupnosti svých IT aplikací podporujících jejich obchod. V případě, že jejich aplikace nejsou dostupné, nemůže společnost vykonávat svoji činnost a tím přichází o zisky. V současné době obrovského konkurenčního boje si žádná společnost nemůže dovolit výpadek ve své činnosti způsobené jakoukoliv událostí, mezi které patří i výpadek IT infrastruktury. Výpadek klíčového IT systému může mít pro společnost nedozírné následky, a to jak z pohledu ztráty zisku společnosti, tak i z pohledu celkové reputace společnosti v očích jejích zákazníků. Kupříkladu v roce 2010 došlo k výpadku IT systému společnosti Virgin Blue spravující proces pro check-in pasažérů a online rezervace letenek. Tento výpadek trval dlouhých 11 dní a následně musela společnost provozující tento systém zaplatit společnosti Blue Virgin odškodnění ve výši 20 milionů dolarů. 1 Základem takřka každé aplikace, která nějakým způsobem pracuje s daty, je databáze. Proto jsou na spolehlivost a dostupnost databázových systémů kladené obrovské nároky. V současné době existuje na trhu mnoho databázových řešení poskytujících vysokou dostupnost. Společnosti dodávající tyto aplikace neustále reagují na nové trendy a stále přicházejí s novými možnostmi řešení. Každý z výrobců databázových systémů nabízí své specifické řešení vysoké dostupnosti. Vzhledem k obrovskému konkurenčnímu boji se každý výrobce snaží od ostatních co nejvíce odlišit a přinést vlastnost, která je nová a poskytuje další možnosti správy a využití systému včetně podpory vysoké dostupnosti. Proto jsem se rozhodl napsat tuto práci, v níž bych jednotlivé vlastnosti pro zajištěnní vysoké dostupnosti popsal a následně provedl porovnání všech řešení najednou. Tato práce je zaměřena pouze na služby poskytované pro zajištění vysoké dostupnosti jako obranu proti neplánovaným výpadkům. Každý systém poskytuje vícero možností, jak dosáhnout vysoce dostupného řešení, a to 1 PERLIN, Martin. Cost of Downtime, Outages and Failures - Understanding Their True Costs. IT Operations Analytics Configuration Management and Change Management Software Evolven [online] [cit ]. Dostupné z: 9

10 v různých módech. Do této práce jsou zařazeny databázové systémy předních výrobců, kterými jsou Oracle, IBM a Microsoft. Tito výrobci poskytují opravdu robustní řešení pro nasazení ve velkých společnostech. Systémy těchto výrobců obsahují nejrůznější komponenty, které mnohdy přesahují potřeby menších a středních zákazníků. Proto jsem se rozhodl do porovnání zahrnout i databázový systém pocházející ze světa OpenSource, a to konkrétně databázový systém MySQL. Hlavním cílem této práce je provést rešerši těchto databázových systémů, popsat výhody a nevýhody jednotlivých řešení s ohledem na vysokou dostupnost, provést srovnání a poskytnout doporučení pro výběr správné DB pro splnění požadavků různých systémů s odlišnými požadavky na dostupnost. Úvodní část této práce popisuje co to vlastně vysoká dostupnost je a do jaké míry je potřebné zabývat se souvisejícími problémy a specifiky při návrhu jejího řešení. Existují i určité důležité metriky, podle kterých se stanovuje vysoká dostupnost nebo požadavky na zotavení systému. Tyto metriky budou také součástí úvodní kapitoly. V další části budou popsány možnosti jednotlivých databázových systémů pro zajištění vysoké dostupnosti. V závěrečné části budou všechny již dříve popsané vlastnosti porovnány. V rámci vlastního porovnání uvedu několik doporučení, na které je dobré brát zřetel v případě návrhu vysoce dostupného databázového systému. V současné době existuje řada publikací, nebo odborných článků, které problematiku vysoké dostupnosti databázových systémů popisují. Každý výrobce má poměrně detailně popsané veškeré funkcionality svých systémů, nicméně neexistuje takřka žádná publikace, která by jednotlivé databázové systémy srovnávala. Každý výrobce po uvedení nové funkcionality nebo nové verze systému okamžitě publikuje spoustu elektronických dokumentů tak, aby co možná nejdříve seznámil veřejnost s těmito novinkami. Proto jsem se rozhodl pro primární využití elektronických materiálů, zejména publikací vybraných výrobců software. Prvními použitými publikacemi jsou dokumenty od společnosti Oracle Maximum Availability with Oracle Database 12c nebo Oracle Real Application Cluster. V prvním dokumentu jsou popsány možnosti vysoké dostupnosti databáze Oracle pro nejnovější verzi databázového systému Oracle 12c. Druhý dokument popisuje technologii Oracle Real Application 10

11 cluster využívanou pro podporu vysoké dostupnosti již v dřívějších verzích databázových systémů od společnosti Oracle. Od společnosti IBM se jedná o publikaci High Availability and Disaster Recovery Options for DB2 for Linux, UNIX and Windows, která popisuje právě vlastnosti databázového systému IBM DB2 pro nasazení v prostředí vysoké dostupnosti. Společnost Microsoft vydala publikaci Microsoft SQL Server AlwaysOn Solutions Guide for High Availability and Disaster Recovery popisující jejich službu AlwaysOn, která byla implementována v nejnovější verzi SQL serveru pro podporu vysoké dostupnosti. Tato publikace opět poskytuje komplexní pohled na implementaci SQL serveru do vysoce dostupného prostředí. Pro poslední databázový systém použiji knihu MySQL High Availability. Tato publikace se opět zbývá tematikou vysoké dostupnosti a obsahuje i popis jednotlivých možností nasazení databázového systému mysql do vysoce dostupného prostředí. Jako zdroj pro obecnou definici standardů vysoké dostupnosti jsem použil knihu Blueprints for High Availability. Tato publikace popisuje základní a známé koncepty vysoce dostupných IT systému bez ohledu na konkrétní použití. Jsou zde uvedeny problémy na které je potřeba se soustředit během návrhu jakéhokoliv IT systému s podporou vysoké dostupnosti. Jsou zde i obecné informace o vyhodnocování a kategorizaci vysoce dostupných IT systémů. Jako doplňkové materiály použiji srovnávací publikace od společnosti Oracle, a to konkrétně Technical Comparison Oracle Database 12c vs. IBM DB2 10.5: Focus on High Availability a Technical Comparison of Oracle Database 12c vs. Microsoft SQL Server 2012 Focus on High Availability. 11

12 1. Co je vysoká dostupnost Tato úvodní kapitola popisuje základní oblasti problematiky vysoké dostupnosti použité v rámci této práce pro vlastní srovnání. Kapitola je zaměřená na to, co to vysoká dostupnost (High Availabilty) je a jak celý koncept obecně vypadá Plánované a neplánované výpadky Ani sebelepší IT systém se neobejde bez výpadku. Výpadkem (anglicky Downtime) ruzumíme dobu, kdy uživatel nemůže aplikaci využívat v předem dohodnuté kvalitě. Výpadek systému může být buď plánovaný, nebo neplánovaný. Jak už z názvu plyne na plánované výpadky je stanoven přesný harmonogram prací a dá se na ně připravit. Mezi typicky plánované úlohy patří třeba upgrade hardwarových komponentů serveru, patchování operačního systému, aplikace opravných nebo rozšiřujících balíčků aplikace, apod. Některé z těchto činností vyžadují restart serveru, nebo v případě upgrade hardware i vypnutí celého serveru. V tuto dobu jsou služby aplikace nebo aplikací spouštěných na konkrétním serveru nedostupné. Jednoduše řečeno: plánovaný výpadek je důsledkem nějaké plánované a předem připravené akce. Naopak neplánovaný výpadek je neočekávaná událost, na kterou je ale potřeba být připraven. Mezi takovéto události patří např. výpadek hardwarových komponentů serveru, na které běží aplikace. Další události může být problém v samotné aplikaci, která např. kvůli nevyřešené chybě spadla. Výpadek tohoto typu ale může být způsoben i některými dalšími vnějšími vlivy, tj. třeba přerušením elektrického napájení, nebo nedostupností síťové konektivity. Neplánovaným výpadkům je tedy potřeba předcházet důkladným monitoringem nejen vlastních aplikací, ale i celé infrastruktury, která je důležitá pro běh aplikace. Pro každý typ výpadku je pak potřeba mít připravené postupy, jak se v případě konkrétní události zachovat. Dle studie společnosti Standish group international, inc. (http://www.standishgroup.com/about), je cena za jednu minutu výpadku IT systému u každé společnosti jiná (viz 12

13 Obrázek 1 - Cena výpadku aplikace za jednu minutu). Průměrná cena výpadku dle Ponemon institutu je průměrně $5,600 za minutu. 2 Obrázek 1: Cena výpadku aplikace za jednu minutu Zdroj: Plánovaným i neplánovaným výpadkům se dá samozřejmě zabránit správným návrhem infrastruktury, např. instalací aplikace na více serverů, zařazením záložního zdroje napájení pro servery, implementací redundantních disků apod. Možnosti instalace aplikace na více serverů jsou popsány v následujících částech této práce. Plánované i neplánované výpadky jsou následně započítávány do celkové dostupnosti vlastního řešení (viz kapitola Celková dostupnost ) Obecné řešení vysoké dostupnosti Velice jednoduše řečeno: je-li potřeba řešit vysokou dostupnost pro jakýkoliv systém, musíme zajistit to, aby žádná z komponent v celé infrastruktuře nepůsobila jako tzv. Single Point of Failure (SPoF). Tato zkratka by se dala do češtiny volně přeložit jako Jeden bod infrastruktury, při jehož výpadku je nedostupná celá služba. V případě návrhu celkové infrastruktury je tedy potřeba se zaměřit na všechny prvky celého řešení a navrhnout je tak, aby jeho výpadek neohrozil celou službu. Jinými slovy: každý prvek by měl být 2 MAPPIC, Sandy. How much does downtime cost?. Application Performance Monitoring and Management from AppDynamics [online] [cit ]. Dostupné z: 13

14 redundantní. Mezi tyto prvky nepatří pouze jen hardware nebo software, ale i např. síťová konektivita, dostupnost serveru a úložiště až po vlastní aplikaci. Na následujícím jednoduchém obrázku znázorňující třívrstvou architekturu je možné si představit, že v případě výpadku kterékoliv vrstvy je celá služba nedostupná. Obrázek 2: Třívrstvá architektura Zdroj: Vlastní zpracování Následující text vystihuje nejdůležitější prvky celé infrastruktury a způsob řešení jejich redundance. Obrázek 3: Redundance komponent v režimu vysoké dostupnosti Zdroj: Vlastní zpracování 14

15 Na předchozím obrázku je vidět typické nasazení aplikace do prostředí vysoké dostupnosti. V nákresu je vidět řešení problému s výpadkem diskového subsystému, síťový výpadek nebo vlastní výpadek aplikace. Celá architektura se skládá z následujících komponent: Server je zde reprezentován dvěma fyzickými servery. V případě výpadku celého jednoho serveru může okamžitě převzít jeho činnost druhý server. Tato konfigurace má dvě základní varianty, a to Active/ /Active a Active/Passive. V první variantě jsou oba servery v podstatě rovnocenné a během normálního provozu, kdy jsou oba servery dostupné, jsou požadavky od klientů distribuovány na oba dva servery (každý server zpracovává různé požadavky od klientů). V případě výpadku jednoho serveru jsou všechny požadavky směrovány pouze na druhý server. V této konfiguraci se ještě řeší situace s rozpracovanými transakcemi serveru, který vypadl. Je totiž možné zajistit takovou konfiguraci, aby server, který běží, rozpracované transakce vypadnuvšiho serveru korektně ukončil. V případě konfigurace Active/Active je potřeba správně navrhnout hardwarovou konfiguraci serverů, tak aby v době výpadku jednoho serveru byl druhý server schopen obsloužit všechny požadavky klientů v požadované kvalitě. V případě konfigurace Active/Passive je druhý server v tzv. StandBy režimu a začíná pracovat pouze v případě, kdy je aktivní server nedostupný. I zde je nutné správně zvolit hardwarovou konfiguraci obou serverů. V obou režimech je nutné, aby na obou serverech byla instalovaná aplikace v identické verzi a aby tato aplikace podporovala nasazení v režimu vysoké dostupnosti. Architektura vysoce dostupného řešení vyžaduje využití minimálně dvou serverů, ale je samozřejmě možné implementace i více serverů až do počtu limitovaného výrobcem. Využití více serverů přináší další výhody z pohledu výkonosti a robustnosti celého řešení. Diskový subsystém je na obrázku rozdělen na dva typy, a to na systémové disky, kde je instalován operační systém a aplikace, a datové disky, kde jsou vlastní data aplikace. Většinou jsou systémové disky umístěny uvnitř serveru a datové disky na externím poli, i když je 15

16 možná i varianta se systémovými disky na externím poli, nikoliv však naopak. Bez ohledu na to jedná-li se o systémový, nebo datový disk, je potřeba jej chránit proti výpadku. K tomuto účelu se používá tzv. technologie Redundant Array of Independent Disks (RAID), která zajišťuje dostupnost dat i při výpadku disku/disků. Data pro aplikaci musí být pro oba servery dostupná v identické podobě, proto je pro disky s daty použito externí diskové pole připojené ke všem severům. Je potřeba zabezpečit řešení i proti výpadku celého diskového pole, proto je v architektuře na obrázku naznačeno i druhé diskové pole, na které se data replikují. Replikaci je možné provádět buď v synchronním, nebo asynchronním režimu. Zvolení typu replikace je opět závislé na více faktorech, např. na kapacitě linky, přes kterou se replikace provádí, nicméně její popis je nad rámec této práce. Externí diskové pole je připojeno k serverům pomocí diskových řadičů (karta umístěná v serveru), a proto i tyto řadiče musejí být redundantní. Každý server tedy obsahuje dva řadiče. V současné době se používá technologie Storage Area Network (SAN), kdy připojení diskových polí je prováděno přes FibreChannel switche, které spojují řadič serveru a vlastní diskové pole. Závěrem této části týkající se diskových prostor je zapotřebí zdůraznit, že jakákoliv zabezpečení s využitím technologie RAID nezbavují administrátory povinnosti provádět pravidelné zálohy dat, a to jak na systémových, tak i datových discích. Síťová vrstva, po které komunikuje klient se serverem, hraje v celkovém řešení rovněž velkou roli. Výpadek síťové karty serveru může mít za následek kompletní nedostupnost aplikace. Za tímto účelem je proto vhodné, aby server měl opět redundantní síťové karty, kdy v případě výpadku jedné z nich může požadavky ze sítě přijímat druhá síťová karta. I možností, jak nakonfigurovat síťové adaptéry, je celá řada, a to od režimu standby až po režim loadbalancingu. Neméně důležítá je také redundance síťových segmentů, cesty po které komunikuje uživatel s aplikací na serveru. Ideální je připojit každou síťovou kartu do jiného síťového segmentu. Informování klienta o změně síťového segmentu nebo i serveru, který zpracovává jeho 16

17 požadavky, je možné pomocí síťových balancerů, nebo pomocí změn DNS záznamů. Toto byl výčet těch nejdůležitějších prvků, a to zejména z pohledu hardwarové infrastruktury. Je tedy nutné si uvědomit, že i v případě sebelepšího řešení vysoké dostupnosti vlastní aplikací bude vše k ničemu, pokud nebudeme mít dostatečnou podporu ze strany hardwarové infrastruktury. V případě návrhu vysoce dostupné architektury je tedy třeba brát v potaz jak softwarové, tak i hardwarové vybavení Celková dostupnost Předchozí dvě kapitoly popisují, co to jsou výpadky a jak vlastně vypadá vysoce dostupná architektura, ale jak se vlastně určuje dostupnost systému? Dostupnost systému = procentuální pravděpodobnost, s jakou je systém v daném časovém okamžiku a za daných podmínek dostupný. Určuje ji podíl doby dostupnosti a součtu doby dostupnosti a doby nedostupnosti, který se vyjadřuje v %: DobaDostupnosti Dostupnost(%) =. DobaDostupnosti + DobaNedostupnosti Častokrát se řeší kolik devítek má mít řešení vysoké dostupnosti. Tato otázka právě směřovala k procentuální době dostupnosti řešení. Dostupnost nabývá hodnot od 90 %, což značí jednu devítku, až po 99,99999%, což značí hodnotu sedmi devítek. Druhou možností výpočtu doby dostupnosti systému je podíl střední doby mezi poruchami (MTBF) a součtu střední doby mezi poruchami a střední dobou opravy (MTTR): MTBF Dostupnost =. MTBF + MTTR V následující tabulce (viz Časová dostupnost systému v jednotlivých kategorií devítek ) je uvedena doba, po kterou musí být systém dostupný tak, aby splňoval určité kritérium, neboli počet devítek. Často je na tento parametr vázáno SLA, které mimo jiné udává, jak kvalitní (dostupnou) službu dodavatel dodává. 17

18 Tabulka 1: Časová dostupnost systému v jednotlivých kategorií devítek Dostupnost (%) Výpadek za rok Výpadek za měsíc Výpadek za týden 90% 36,5 dne 72 hodin 16,8 hodin 95% 18,25 dnů 36 hodin 8,4 hodin 97% 10,96 dnů 21,6 hodin 5,04 hodin 98% 7,30 dnů 14,4 hodin 3,36 hodin 99% 3,65 dnů 7,2 hodin 1,68 hodin 99,5% 1,83 dnů 3,6 hodin 50,4 minut 99,8% 17,52 hodin 86,23 minut 20,16 minut 99,9% 8,76 hodin 43,8 minut 10,1 minut 99,95% 4,38 hodin 21,56 minut 5,04 minut 99,99% 52,56 minut 4,32 minut 1,01 minut 99,999% 5,26 minut 25,9 sekund 6,05 sekund 99,9999% 31,5 sekund 2,59 sekund 0,605 sekund 99,99999% 3,15 sekund 0,259 sekund 0,0605 sekund Zdroj: Z výše uvedené tabulky je patrné, že systém dosahující úrovně pěti devítek je již takřka neustále dostupný. Nicméně z pohledu ceny výpadku může i tato hranice znamenat pro některé společnosti významné ztráty. Občas se zaměňují pojmy uptime a availability. Přitom uptime udává čas, po který je systém v chodu, a availability čas, po který je systém dostupný. Jak už bylo ale uvedeno v předchozích kapitolách, v případě výpadku sítě je aplikace pro uživatele nedostupná, i když systém běží v pořádku. Z toho je zřejmé, že často je do vysoce dostupného řešení zahrnuto více subjektů, které mezi sebou uzavírají již dříve zmíněné SLA. Součástí SLA je požadovaná dostupnost systému a případné sankce při nedodržení kvality služby. Asi je jasné, že pokud bude nedostupné on-line bankovnictví kvůli výpadku internetové linky banky, není na vině banka, ale její poskytovatel internetového připojení. Bance v tomto případě vzniknou ztráty a původce tohoto pochybení by jí měl ztráty kompenzovat. Na druhou stranu je nutné si uvědomit, že čím více devítek, tím vyšší cena. Proto je opět nutné hledat vyvážený vztah mezi cenou a dostupností. 18

19 1.4. Řešení disaster recovery V předchozích kapitolách bylo naznačeno, co je to vysoká dostupnost, jak jí docílíme a také co jsou to výpadky. V kapitole o výpadcích byly zmiňovány výpadky omezující provoz jednotlivé části architektury. Nicméně z pohledu dostupnosti je nutné řešit i situaci kdy dojde k výpadku celé jedné lokality. Problémy tohoto typu řeší proces disaster recovery, neboli proces zotavení se po havárii celé IT infrastruktury společnosti v jedné lokalitě. K tomuto problému se dá přistoupit několika způsoby, ale vždy je nutné mít přesně definovaný proces DR. V podstatě jsou možné dvě alternativy řešení. První spočívá ve vybudování podobné infrastruktury v oddělené lokalitě a druhá v připraveném plánu obnovy ze záloh v primární lokalitě. Oba přístupy mají svá pro i proti, jako je např. pronájem oddělené lokality s dostatečnou konektivitou pro replikaci dat v prvním případě. V případě vybudování záložní lokality se většinou nebuduje infrastruktura hardwarově identická a také mnohdy není nutné zajistit vysoce dostupné řešení v této lokalitě. Důvod je poměrně jednoduchý: většinu času je infrastruktura nevyužita a není tedy nutné investovat prostředky do něčeho, co se takřka nevyužívá. Na druhou stranu - v případě výpadku primární lokality - musí záložní lokalita poskytnout kvalitu služeb v definované kvalitě. Obrázek 4: Řešení disaster recovery Zdroj: Vlastní zpracování 19

20 Důležité také je mít pevně stanovený DR plán, který je v průběhu času neustále validován např. i tím, že se úmyslně zastaví primární lokalita a veškerý provoz přesune na sekundární lokalitu. V případě DR procesu se setkáváme se dvěma základními pojmy, kterými jsou RTO a RPO. Recovery time objective (RTO) udává čas, za jaký musí být systém obnoven tak, aby neohrozil činnost společnosti. Recover Point Objective (RPO) udává akceptovatelnou časovou periodu ztráty dat. Jinými slovy: pokud je RPO nastaveno např. na čtyři hodiny, je potřeba zajistit, aby data byla každé čtyři hodiny zálohována tak, aby v případě havárie bylo možné obnovit data ne starší než čtyři hodiny. Na následujícím obrázku (viz DR plán) jsou jednotlivé pojmy znázorněny v čase. Obrázek 5: DR plán Zdroj: Z obrázku je patrné, že zálohy je potřeba provádět v pravidelných intervalech tak, jak je definováno kritériem RPO, a vlastní plán obnovy mít nastavený tak, aby splňoval kritérium RTO. Je tedy jasné, že žádná větší společnost se nevyhne řešení problému vysoké dostupnosti a DR plánu. Při rozhodování se, jakou cestu zvolit, se vždy musejí brát v potaz konkrétní požadavky společností na dostupnost IT systému a na základě nich navrhnout vyhovující řešení. Jak již bylo naznačeno v dřívějších kapitolách, obecně platí, že čím lepší řešení, tím více peněz. Je tedy nutné se zamyslet i nad tím, jestli opravdu některým menším společnostem doporučit kritérium pěti devítek a RTO čtyři hodiny. Při návrhu vlastního řešení je tedy vždy dobré vyjít především z údaje, cca na kolik peněz společnost přijde čas, 20

21 po kterou systém nebude dostupný, a na základě tohoto předpokladu navrhnout adekvátní řešení Klíčové prvky vysoké dostupnosti databázových systémů Jak již bylo zmíněno v předchozím textu, pro návrh vysoce dostupného databázového systému existují určité klíčové aspekty, které je potřeba potřeba vyřešit. Základním prvkem každého vysoce dostupného systému je funkcionalita, která zajistí transparentní chování aplikace pro uživatele. Uživatele aplikace nezajímá, jak je serverová služba, kterou používá, implementována, ale pouze to, jestli s aplikací může, nebo nemůže pracovat. Klientovi je v podstatě jedno jestli je systém implementován jako vysoce dostupný, či pouze jako jedna instance. Dalším důležitým prvkem v implementaci vysoce dostupného systému je zajištění konzistence dat aplikace při přístupu k datům z více serverů. Pro zajištění vysoké dostupnosti a tedy eliminaci problému SPoF je potřeba nasadit aplikaci na více serverů, nicméně tyto servery musí mít přístup ke konzistentním datům. Není možné, aby dva servery zároveň modifikovaly stejná data. Posledním důležitým prvkem je správa transakcí vysoce dostupného systému. Pojem transakce je známý hlavně ze světa databází, nicméně nejen databázové systémy pracují v režimu transakčního zpracování. Je tedy nutné v případě pádu kterékoliv komponenty vysoce dostupného systému zajistit opravné mechanismy pro rozpracované transakce. V této podkapitole budou popsány výše zmíněné aspekty z obecného pohledu, v hlavní části této práce bude následně popsáno, jak se který databázový systém k těmto problémům staví Dostupnost aplikace z pohledu klienta Jak již bylo napsáno dříve, klientovi je jedno, jak je jeho aplikace implementována. Klient přistupuje k aplikaci jako k jednomu celku a přístup by pro něj měl být transparentní. Toto je z pohledu klienta zajištěno tzv. loadbalancingem nebo failover procesem. V případě load-balancingu to znamená, že všechny servery vysoce dostupného řešení běží a že klientské požadavky 21

22 jsou mezi těmito servery automaticky distribuovány dle jednoho z následujících pravidel: Round-robin požadavky jsou rovnoměrně distribuovány mezi jednotlivé servery. Váhy serveru každý server v architektuře řešení má přiřazenou určitou váhu, podle které jsou požadavky mezi servery distribuovány. Dostupnost před zasláním požadavku na konkrétní server je provedeno základní otestování dostupnosti a teprve následně je požadavek na server zaslán. V případě databází to může být např. jednoduchý příkaz SELECT, kdy v případě, že server vrátí výsledek, je považován za dostupný a požadavek je na něj odeslán. V případě failover znamená, že při výpadku serveru je požadavek odeslán na jiný aktivní server. Opět existuje několik režimů failover řešení: Cold failover aktivní pouze jeden server a všechny požadavky jsou zpracovávány tímto serverem. V případě jeho výpadku startuje druhý, záložní server, a začíná zpracovávat požadavky klientů. Hot failover všechny servery jsou nastartované a požadavky jsou směřovány na jeden server. V případě výpadku serveru jsou požadavky směřovány na jiný server. Obě popsaná řešení mohou být kombinována a tím je dosaženo nejen vysoké dostupnosti řešení, ale i škálovatelnosti a celkové zvyšování výkonu. Jak bude zmíněno v části o zpracovávání transakcí, je nutné, aby každý klient byl programován s ohledem na jeho možné využití ve vysoce dostupném prostředí Data aplikace v režimu vysoké dostupnosti Každá aplikace, databázový systém není vyjímkou, ukládá svá data na disk. Databáze se skládá z několika klíčových souborů, jako jsou vlastní datafily pro ukládání dat, transakční logy databáze pro udržování konzistence dat v databázi a systémové soubory udržující informace o databázi. V případě instalace v režimu vysoké dostupnosti na více serverů je potřeba, aby všechny tyto soubory byly dostupné pro všechny servery v infrastruktuře. V případě dat existují v zásadě dva přístupy: řešení pomocí sdíleného disku nebo replikace dat mezi jednotlivými úložišti. V druhém případě většinou existuje jedno 22

23 primární úložiště, kde jsou prováděny veškeré změny a následně jsou replikovány na sekundární úložiště, které fungují v režimu stand-by. V případě, že je primární úložiště nedostupné, je sekundární úložiště přepnuto do role primárního úložiště. Tato replikace může fungovat ve dvou režimech: v prvním případě se data v rámci jedné akce synchronně zapíší na primární i sekundární úložiště, v druhém případě se data zapíší pouze na primární úložiště a následně se data asynchronně replikují na sekundární úložiště. V případě využití sdíleného disku je stejný diskový prostor připojen ke všem serverům architektury a data jsou dostupná najednou všem serverům. V tomto případě je nutné zajistit přístup k datům pro všechny servery. Většinou se k řešení tohoto problému používá tzv. clustered file system, který je jakýmsi rozšířením standardního file systému umožňujícím přístup k datům pro čtení i zápis všem serverům. Největším problémem, který clustered file systém řeší je problém modifikace stejných dat z různých serverů. Opět je možné oba popsané přístupy ke sdílení dat spojit do jednoho a využít sdíleného úložiště mezi jednotlivými servery s následnou replikací dat do jiného úložiště Transakce v režimu vysoké dostupnosti V případě databáze znamená transakce posloupnost instrukcí prováděných nad daty v databázi v rámci jedné hlavní operace. Každá transakce probíhá jako celek a výsledkem transakce je změna dat v databázi. Mnohdy se stává, že při složitějších operacích nad obrovským množstvím dat může transakce trvat delší dobu. Každá databázová transakce musí splňovat vlastnosti ACID, které zajišťují její správný průběh. Zkratka ACID postihuje následující povinné vlastnosti: Atomicity transakce je nedělitelná. Provede se buď kompletně celá, nebo vůbec. Např. není možné při převodu peněz z jednoho bankovního účtu peníze na jedné straně odepsat bez následného připočtení částky na účet příjemce. Consistency transakce nesmí porušit definovaná omezení. Databáze musí být po dokončení transakce opět ve validním stavu, tak jako před začátkem transakce. 23

24 Isolation vnitřní běh transakce je skrytý pro okolí. Změny prováděné jednou transakcí jsou viditelné pro ostatní až po dokončení transakce (commit transakce). Durability změny provedené transakcí, které jsou systémem potvrzeny, jsou uloženy a již nemohou být ztraceny. Z pohledu vysoké dostupnosti jsou hlavně zajímavé vlastnosti durability a consistency, zbylé vlastnosti jsou doménou databázových systémů a jsou řešeny pouze na úrovni vlastní databáze. Transakce je zpracovávána jedním serverem vysoce dostupného řešení a v případě jeho selhání je potřeba takovouto spuštěnou transakci korektně ukončit. Celou transakci je buď nutné dokončit, nebo dosavadní změny provedené transakcí vrátit zpět do původního stavu. V případě zpracovávání vlastních transakcí není rozdíl v implementace vysoce dostupného databázového systému a klasické implementace. V průběhu transakce se modifikovaná data odkládají do transakčních logů pro případ, že je potřeba celou transakci vrátit. Je tedy nutné, aby všechny servery vysoce dostupného databázového systému měly přístup k těmto logům a mohly případně transakci korektním způsobem dokončit. V případě dlouhých transakcí je žádoucí, aby v případě výpadku serveru, který transakci zpracovává, se klient automaticky připojil na jiný dostupný server a pokračoval bez přerušení ve zpracování konkrétní transakce. Proto je potřeba, aby byl databázový klient imlementován s ohledem na tuto skutečnost. Databázové systémy by měly poskytovat API s těmito funkcionalitami. Všechny tyto požadavky jsou klíčové pro zpracování tzv. in-flight transakcí, což je označení probíhajících transakcí. V případě, že klient v době pádu serveru nemá rozběhnutou žádnou transakci je při požadavku na zahájení nové transakce automaticky odkázán na dostupný server. 24

25 2. Řešení vysoké dostupnosti jednotlivých databází Tato kapitola detailně popisuje způsob řešení vysoké dostupnosti pro jednotlivé systémy. Jsou zde popsány vlastnosti, které implementují jako ochranu proti neplánovaným výpadkům. Mezi události, které spadají do kategorie neplánovaných výpadků, mohou být situace, jako je např. lidská chyba, chyba v datech apod. Tyto výpadky nejsou součástí tohoto srovnání. Postupně budou popsány vlastnosti aktuálních verzí databázových systému, kterými jsou Oracle 12c, IBM DB2 10.5, Microsoft SQL Server 2012 a mysql Oracle Společnost Oracle je jednou z nejvýznamějších společností působících na trhu s databázovými systémy. Databázové systémy tohoto výrobce jsou používány mnoha společnostmi, a proto je zde patrný neustálý rozvoj. Současnou aktuální verzí databáze je verze 12c, která opět přináší spoustu novinek, a to nejen z pohledu možností pro řešení vysoké dostupnosti. Vzhledem k neustálému vývoji je mnoho prvků převzato a v některých ohledech i vylepšeno z dřívějších verzí, jiné jsou právě novinkami verze 12c. V souvislosti s vysoce dostupnými řešeními společnosti Oracle se můžeme setkat s pojmem Maximum Availability Architecture (MAA), což je jakýsi seznam best practice pro zajištění vysoce dostupného systému. Vysoká dostupnost je již více než deset let zajišťována technologií Real Application Cluster (RAC), která nabízí řadu možností pro nasazení kritických databázových systémů. Technologie Oracle RAC umožňuje nasadit několik databázových instancí na více serverů sdílejících jedno datové úložiště. Toto řešení se navenek jeví jako jeden celek, ke kterému klienti přistupují se svými požadavky. 25

26 Obrázek 6: Oracle Real Application Cluster Zdroj: 12c pdf Základem řešení Oracle RAC je Oracle clusterware (OCW), který je nutnou podmínkou pro nasazení této technologie. I když jsou podporovány i clusterware produkty ostatních výrobců, plné a efektivní využití technologie RAC je možné pouze s OCW. Oracle clusterware je nástroj umožňující spojit servery do jednoho celku, tzv. clusterů. Tyto servery spolu vzájemně komunikují a obsluhují požadavky klientů, tak jako by se jednalo o jeden server. Tuto komponentu lze využít pro implementaci vysoké dostupnosti nejen databázových systémů. V případě výpadku kteréhokoliv serveru, jsou požadavky klientů automaticky přesměrovány na ostatní servery. Tato podpora OCW se poprvé objevila ve verzi Oracle 10g R1, jakožto nutná podmínka pro implementaci Oracle RAC. 26

27 Obrázek 7: Oracle clusterware Zdroj:http://docs.oracle.com/cd/E11882_01/rac.112/e16794/intro.htm#CWAD D91256 Oracle clusterware, kromě svých binárních souborů, využívá dva důležité diskové prostory pro sdílení informací mezi jednotlivými servery clusteru. Příslušnost jednotlivých serverů clusteru je uložena v tzv. souborech voting disk a vlastní konfigurace v tzv. Oracle Cluster Registry (OCR). Voting disky a OCR musí být umístěny na sdíleném úložišti přístupném pro všechny servery. Ke všem serverům musí být také připojeno sdílené úložiště pro data databázových instancí, jako jsou datafily (včetně undo), redo log soubory (minimálně dva pro každou instanci) atd. Doporučované je také umístění SPFILE na sdílené úložiště. Oracle clusterware je dále integrován se speciálním nástrojem pro správu diskového prostoru Oracle ASM, proto je doporučováno jeho využití pro správu sdíleného diskového úložiště. Jak je také vidět z předchozího obrázku, v infrastruktuře clusteru se nachází dvě dedikované sítě. Jedna slouží jako tzv. interconnect a druhá pro obsluhu klientských požadavků. Síť interconnect je důležitá z pohledu vnitřní komunikace mezi jednotlivými servery a má celkem dva úkoly. Prvním z nich je tzv. heartbeat pro monitoring stavu ostatních členů clusteru. Zprávy zasílané na této úrovni jsou poměrně malé, s průměrnou velikostí zhruba 200 bytů. Druhým úkolem je přenos aplikačních dat mezi cache buffer. V případě přenosu aplikačních dat je již velikost odvislá od aplikace a způsobu přístupu k datům. Velikost těchto dat se může pohybovat od 2 do 16 kilobytů. Proto je 27

28 důležité, aby tato síť byla oddělena od běžného provozu a dosahovala vysoké míry spolehlivosti. Co se týče vlastní eliminace SpoF v celém řešení, záleží již na konkrétním použitém hardware. Pro přístup vlastních klientů k databázovým službám je použito funkcionality tzv. Single Client Access Name (SCAN), která klientům umožňuje jednoduchý přístup na základě jednoznačného síťového názvu RAC clusteru. Např.: pro přístup ke konkrétní databázové instanci běžící v RAC clusteru pomocí JDBC je možné použít následující url: Implementace SCAN je možná dvěma způsoby. První variantou je korporátní DNS, kdy jsou přiřazeny až tři IP adresy pro virtuální scan_dns_name. Požadavky od klientů jsou pomocí round-robin distribuovány na různé IP adresy. Tyto přidělené IP adresy jsou pouze virtuální a jsou spravovány Oracle RAC. Druhou variantou je využití tzv. Oracle Grid Naming Service (GNS), který spravuje GNS virtual IP, na níž jsou směrovány požadavky pro přístup do Oracle RAC. Služba GNS disponuje údaji o IP adresách v rámci celého clusteru a je schopna poskytovat informace o jednotlivých serverech a jejich IP. GNS služba běží vždy na jednom serveru RAC clusteru. V případě, že server, na kterém běží GNS služba, spadne, je automaticky služba spuštěna na jiném serveru RAC clusteru. Při každém přidání nového serveru do RAC clusteru GNS zaktualizuje své informace o síťovém nastavení nově přidaného serveru. Pomocí SCAN je možné nastavit dva typy load-balancingu: Client-side loadbalancing - využívá lokální nastavení se seznamem všech SCAN listenerů. Z nich je následně náhodně vybrán jeden, na který jsou odeslány požadavky. V případě, že vybraný server neodpovídá, je využit další server v pořadí. Server-side loadbalancing - využívá vlastní SCAN listener k distribuci požadavku na jednotlivé servery clusteru. Vzhledem k tomu, že SCAN listener disponuje informacemi o všech běžících serverech v clusteru a jejich zatížení, umožňuje distribuovat efektivně požadavky mezi nimi. 28

29 Obrázek 8: Load balancing připojení pomocí SCAN Zdroj: pdf O správu sdíleného datového úložiště clusteru se stará další komponenta, a to Oracle Automatic Storage Mangement (ASM). Stejně jako RAC využívá clusterware OCW. Pomocí tohoto nástroje je možné spravovat nejen vlastní soubory databázové instance, ale i další soubory nutné pro běh Oracle RAC, resp. Oracle clusterware. Komponenta ASM byla za dobu svého vývoje speciálně vyladěna pro správu souborů databázových instancí. Z tohoto důvodu je proto vhodné ji využít i při správě sdíleného diskového prostoru Oracle RAC. Obrázek 9: Oracle ASM Zdroj: 29

30 Oracle ASM je spojení komponent volume manager a file system. Oracle ASM maximalizuje výkon, zajišťuje maximální dostupnost datových souborů a celkově zjednodušuje správu. Pro ukládání souborů databázových instancí používá tzv. disk groupy. Tyto disk groupy jsou složené z jednotlivých fyzických disků, na kterých je vybudován file system pro data. Ukládaná data jsou rovnoměrně distribuována mezi jednotlivé disky pomocí tzv. data stripping. Pomocí data stripping jsou soubory rozdělěny na menší celky (chunky) a následně uloženy na více fyzických disků. Díky tomuto rozdělení je snížena I/O latence pro malé I/O operace a zvýšen celkový výkon při práci s daty na disku. Výsledkem je výkon srovnatelný s RAW devices. Tato komponenta umožňuje volně přidávat disky, aniž by bylo nutné zastavit databázové služby. Dále poskytuje možnost zrcadlení dat a tím i zajištění jejich redundance. Další zajímavou vlastností ASM je funkce Intelligent Data Placement. Pomocí této funkcionality je možné rozdělovat ukládaná data dle své povahy na různé disky pomocí disk regionů. Je tedy možné definovat region pro často čtená data, který je rozmístěn na rychlých discích, zatímco méně čtená data budou ukládána do regionu umístěného na pomalejších discích. Tímto způsobem je možné zvýšit výkon celého řešení. Na následujícím obrázku je naznačená možná implementace Oracle RAC s využitím ASM. Databáze jsou konsolidované a využívají dvě společné disk groupy. Obrázek 10: Oracle RAC s využitím ASM Zdroj:http://docs.oracle.com/cd/E11882_01/server.112/e18951/asmcon.htm#O STMG

31 S příchodem Oracle verze 11.2 bylo ASM rozšířeno o funkcionalitu separátního file systemu pro použití ukládání dat jiných, než pouze dat databázových služeb. Vzhledem k širokému rozšíření cloudových řešení byla s verzí Oracle 12c implementována podpora cloud computingu rozšířením o službu Oracle Flex ASM. Tato služba umožňuje rychlou reakci na změnu zátěže serverů v cloud computingu. V dřívějších implementacích Oracle ASM běžela vždy služba na každém serveru clusteru. Tyto servery tvořily tzv. ASM cluster. V případě, že instance ASM na serveru nebyla dustupná, nebyly na něm dostupné ani databázové služby. Ve verzi 12c již není potřeba, aby služba ASM běžela vždy na každém serveru, ale stačí pouze omezený počet běžících instancí ASM. V případě, že služba na jednom serveru vypadne, je automaticky nastartovaná na jiném. Všechny databázové služby závislé na nedostupné ASM službě se automaticky připojí k jiné, aktivní službě. Tyto služby jsou ve výchozím stavu tři a jejich počet je možné manuálně nastavit. Zátěž je pak rovnoměrně distribuována mezi jednotlivé běžící služby ASM. Obrázek 11: Oracle Flex ASM Zdroj: Všechny zmiňované služby (Oracle ASM, CloudFS a Oracle clusterware), nutné, nebo doporučované pro implementaci Oracle RAC tvoří tzv. Oracle Grid Infrastructure 3, který je nedílnou součástí Oracle Maximum Availability Architecture. Oracle RAC cluster bude ve většině případů poskytovat více databázových instancí než jednu. Oracle RAC cluster se skládá z více serverů a je tedy 3 MICHALEWICZ, Markus: Oracle Real Application Clusters (RAC). Redwood Shores, CA: Oracle Corporation, [cit ].[dokument ve formátu PDF] Dostupný z URL: < 31

32 rozumné rozdělit různé instance mezi různé servery. Problém ale může nastat ve chvíli, kdy jedna instance potřebuje více prostředků, než ji je schopna přidělená hardwarová infrastruktura poskytnout. Další problém přichází ve chvíli, kdy běží dvě nebo více instancí na stejné hardwarové infrastruktuře a jedna instance najednou využívá celou hardwarovou infrastrukturu přidělenou více instancím. V tuto chvíli jsou v podstatě všechny instance na stejném hardware nedostupné. Řesení těchto problémů přinesla verze 11.2, a to pomocí tzv. server pool. Tato služba umožňuje dynamicky měnit zdroje přidělené konkrétní instanci databáze na základě předem definovaných pravidel. Pomocí server pool je možné rozdělit servery do logických celků a následně nad nimi konfigurovat následující pravidla pro přidělování zdrojů: Na základě nastavené priority přidělit zdroje službě, která je potřebuje. Přiřadit určité službě minimální a maximální zdroje tak, aby neovlivňovala ostatní služby a zároveň aby nebyla ovlivňována ostatními službami. Zajistit izolaci databázových serverů od aplikačních. Na server pool navazuje možnost využití tzv. Dynamic Database Services. Pro každou aplikaci využívající databázi je možné definovat jinou databázovou službu, která je poskytována pomocí konkrétního server pool. Tímto způsobem je možné v případě implementace Oracle cluster spravovat zátěž jednotlivých databázových instancí z pohledu aplikací, které se k ní připojují. Pro aplikace připojující se do prostředí Oracle RAC je užitečná služba Fast Application Notification. Tato služba notifikuje aplikace využívající databázové služby o dostupnosti instance služby nebo vlastního serveru. Aplikace je notifikována o nedostupnosti služby dříve, než se pokusí připojit. Vysoce dostupné řešení od společnosti Oracle poskytuje také řešení pro správu rozběhnuté transakce v případě nedostupnosti serveru, který transakci zpracovával. Již z popisů vlastností ACID vyplývá, že žádná transakce nemůže narušit konzistenci databáze, a proto Oracle přišel s funkcí Transparent Application Failover (TAF). Tato vlastnost, implementovaná na klientské straně, umožňuje přepojení na sekundární instanci se stejnými parametry spojení, tak jak bylo původně navázano před pádem serveru. Na sekundárním serveru je následně možné pokračovat v operaci typu SELECT, aniž by byly ztraceny již načtené záznamy z databáze. V případě transkací typu INSERT 32

33 nebo UPDATE dojde k rollbacku takovéto transkace a odeslání informace o této skutečnosti klientovi. Nástrojem pro podporu dlouhých databázových procedur je Transaction Guard. V případě spuštění databázové procedury aplikace vyžaduje její kompletní dokončení včetně commitu všech změn do databáze. Takováto procedura se může skládat z několika oddělených transakcí. Po dokončení každé z nich dojde ke commitu výsledku do databáze, nicméně z pohledu aplikace je požadován kompletní dokončení všech operací včetně commitů v rámci volané procedury. V případě, že dojde k pádu databázového serveru, který proceduru zpracovává, klientská aplikace se nedozví, jak zpracování celé procedury dopadlo. Transaction guard poskytuje možnost využití tzv. logical transaction ID (LTXID) k zjištění výstupu z posledního commitu databázové session před výpadkem serveru. LTXID je udržováno jak na straně serveru, tak i klienta. V případě, že dojde k přerušení databázového spojení, klient může získat identifikaci LTXID. Tento identifikátor může být po navázaní nového spojení použit k zjištění stavu poslední transakce a pokusu o znovuspuštění posledního požadavku. Oracle RAC tedy poskytuje funkce vysoké dostupnosti s následujícími klíčovými vlastnostmi: Reliability databázový server nefiguruje v celém řešení jako SpoF. V případě nedostupnosti jednoho serveru clusteru ostatní servery zůstávají aktivní a jsou schopny přijímat klientské požadavky. Error detection Oracle clusterware monitoruje komponenty Oracle včetně databázových služeb a v případě problému se snaží o automatickou nápravu. Recoverability Oracle RAC poskytuje mnoho služeb pro obnovu systému v případě chyby. Continuous Operations Oracle RAC je schopen poskytovat služby databáze i v případě výpadků. Uživatel navenek takřka nepozná, že došlo k výpadku některé komponenty Oracle RAC infrastruktury. Společnost Oracle ještě nabízí speciální edici Oracle RAC, a to konkrétně Oracle RAC One. Jedná o variantu tzv. Cold cluster failover, kdy všechny instance databáze běží na jednom serveru a pouze v případě jeho výpadku je 33

34 automaticky nastartován záložní server, který přebírá úlohu primárního serveru. RAC One je také dobrým nástrojem pro konsolidaci databázových instancí na jeden server. Podporu pro řešení disaster recovery nabízí společnost Oracle v podobě Active Data Guard. Tato služba umožňuje vybudování standby databáze ve vzdálené lokalitě. V rámci Oracle Data Guard jsou databázové redo logy synchronizovány do vzdálené lokality, čímž je zajištěna dostupnost databáze v případě kompletního výpadku celé jedné lokality. Pomocí Data Guard je možné nastavit až 30 standby databází, do kterých se budou replikovat změny z primární databáze. Obrázek 12: Oracle Data Guard Zdroj: Oracle Data Guard přináší i další výhody z pohledu celkového řešení databázových systémů. Jednou z výhod tohoto řešení je možnost kontaktovat standby databázi pro operace typu čtení. Není tedy nutné zatěžovat primární databázi složitými a náročnými dotazy pro získání dat z databáze a je možné takovýto dotaz spustit na standby databázi, kde jsou identická data (v případě synchronní replikace) jako v primární lokalitě. Oracle Data Guard se také snaží o minimalizaci ovlivnění výkonu při zapnutí replikace. Jednou z důležitých vlastností je přímý přenos redo informací z paměti primárního serveru. Tento způsob replikace snižuje požadavky na I/O operace disku. Replikaci je možno zapnout v synchronním nebo asynchronním režimu. V případě synchronní replikace je utlumen výkon celého řešení. Primární databáze musí čekat na potvrzení ze strany standby o zápisu redo informací dříve, než může potvrdit 34

35 commit transakce aplikaci, která ji vyvolala. Oracle 12c proto přináší dva nové režimy nastavení synchronní replikace: Fast Sync - standby strana potvrdí přijetí redo informací ve chvíli kdy je zapíše do své paměti, nikoliv až na disk. Far Sync - volba dostupná pouze v případě Active Data Guard. V tomto případě existuje speciální instance serveru, která pouze přijímá redo informace z primární databáze a dále je asynchronně distribuuje do vzdálených stanby lokalit. Tato instance není plnohodnotnou náhradou pro poskytování databázových služeb, ale spravuje pouze control soubory a redo logy. Tuto instanci tedy není možné použít v případě pádu primární databáze a slouží pouze k urychlení procesu commit v případě replikace do vzdálených lokalit. V případě asynchronní replikace primární strana nečeká na potvrzení od stanby strany a potvrzuje commit transkace ihned po zápisu do redo logů na primární straně. Tato replikace nezajišťuje úplnou dostupnost dat v případě výpadku primární lokality. Data, která se nestihla replikovat na standby stranu z důvodu pádu primární lokality, jsou nedostupná. Za aplikaci redo informací je zodpovědná speciální služba Redo Apply Service. Tato služba validuje redo informace proti poškození a následně je aplikuje přímo na standby databázi. Tato služba běží nezávisle na vlastní replikaci, aby nesnižovala výkon celého řešení. Přepnutí z primární lokality na sekundární může být iniciováno manuálně (switchover) nebo automaticky (failover). Data Guard neustále monitoruje stav instancí a v případě problémů na primární lokalitě provede failover na definovanou standby lokalitu. Klienti databáze jsou informováni o nedostupnosti primární lokality zasláním informace o timeout spojení a jsou přesměrováni na novou primární lokalitu. Databázový systém od společnosti Oracle tedy poskytuje všechny potřebné funkcionality pro řešení vysoce dostupného prostředí včetně disaster recovery IBM DB2 Společnost IBM je dalším z významných hráčů nejen na poli software, ale také v oblasti hardware. Stejně jako ostatní velcí hráči na trhu i IBM neustále 35

36 reaguje na nové trendy, a to nejen v oblasti databází, a vylepšuje a zdokonaluje svá řešení. V současné době poskytuje svůj databázový systém IBM DB2 ve verzi Stejně jako společnost Oracle již dlouhou dobu používá a zdokonaluje technologii RAC pro řešení vysoké dostupnosti, IBM používá technologii HADR, která je zkratkou pro High Availability disaster recovery. Již z tohoto názvu vyplývá, že tato technologie se nezabývá pouhým řešením vysoké dostupnosti databázového systému, ale i řešením disaster recovery. IBM DB2 HADR je tedy možné implementovat jako vysoce dostupné řešení v jedné lokalitě i jako řešení disaster recovery mezi vzdálenými lokalitami. Toto řešení tedy napomáhá v situacích, kdy dojde k výpadku některé komponenty na jedné lokalitě, nebo kdy dojde ke kompletnímu výpadku datového centra celé lokality. Z pohledu řešení vysoké dostupnosti je v aktuální verzi IBM DB uvedena jedná zajímavá novinka. Tato novinka se týká podpory technologie HADR v prostředí DB2 purescale. IBM DB2 purescale je clusterové řešení v režimu Active/Active se sdílením stejných dat pro konkrétní databázovou instanci. Technologie purescale umožňuje vybudovat robustní řešení v jedné lokalitě, v případech kdy výpadek jednoho serveru neznamená výpadek databázových služeb, nebo přesun na druhou lokalitu. IBM popisuje technologii purescale jako nástroj pro continuous availability, tedy neustálou dostupnost řešení v případě plánovaných i neplánovaných odstávek. IBM DB2 purescale bylo ze své podstaty určeno k implementaci v jedné lokalitě, tak jako u většiny clusterových řešení. Pokud ale bylo potřeba do celkového řešení zahrnout i potřebu disaster recovery, byla zde nutnost využití dalších komponent pro replikaci dat mezi jednotlivými lokalitami. Ve verzi DB2 10.5, byla technologie HADR integrována pro použití v DB2 purescale. Následující text je tedy věnován popisu technologií HADR a purescale. Základní myšlenkou HADR je replikace transakčních logů z primárního serveru na jeden nebo více sekundárních serverů, na nichž jsou následně tyto informace aplikovány do standby databází. Tento přístup je známý spíše z procesu disaster recovery. Pro nasazení databáze IBM DB2 v režimu vysoké dostupnosti je stejně jako u ostatních systémů, nejen databázových, zapotřebí využít clusterware. Databáze IBM DB2 poskytuje několik služeb pro integraci s nejčastěji používanými 36

37 clusterware software. Možností je samozřejmě využití IBM DB2 purescale, který je podporován pouze na operačních systémech AIX nebo Linux a je součástí pouze vybraných edicí IBM DB2. IBM DB2 purescale je popsána později v rámci této kapitoly. Stejně jako společnost Oracle i IBM poskytuje svoje clusterware řešení IBM PowerHA SystemMirror, ale toto řešení je dostupné pouze pro operační systém AIX. Záleží tedy opět na požadavcích celkového řešení. Jedním z nejdůležitějších rozhodovacích kritérií je možnost použít clusterware v režimu Active/Active nebo pouze Active/Passive. V případě DB2 HADR je tedy zodpovědnost o správu sdílených dat, zjišťování dostupnosti serverů clusteru atd. v rukou clusterware. Je tedy nutné informovat clusterware o všech nastalých změnách, jako např. zastavení databázových služeb. To je důležité mj. z pohledu skutečnosti, že clusterware je zodpovědný za distribuci klientských požadavků na jednotlivé IBM DB2 servery. V případě, že by mu nebyla známa nedostupnost databázových služeb, snažil by se klientské požadavky směrovat dále na nesprávné servery. V tomto případě by klient dostával nepravdivé informace o důvodu nedostupnosti databáze. O integraci IBM DB2 s clusterware se stará DB2 High Availability features, která obsahuje následující komponety pro správu IBM DB2 v prostředí clusterware: IBM Tivoli System Automation for Multiplatform. Automatická synchronizace klíčových změn na databázové instanci do prostředí clusterware. Mezi tyto operace může např. patřit spuštění a zastavení databáze nebo i konfigurace jako je vytvoření nové databáze. Utilita db2haicu pro správu a konfiguraci vysoce dostupných databází v prostředí clusteru. Tato utilita spustitelná z příkazové řádky sbírá a spravuje informace o konkrétní databázové instanci, clusteru a vlastní správě celého clusteru. IBM DB2 nabízí i další alternativy bez využití clusterware pro zajištění vysoké dostupnosti databáze, které sebou přinášejí některé výhody i nevýhody. Mezi nevýhody patří větší zodpovědnost administrátorů za monitoring a provádění manuálních kroků v případě failover. Mezi výhody by se dala zařadit větší nezávislost na třetích stranách, a to zejména s ohledem na clusterware řešení. V zásadě existují dvě další řešení, která jsou postavena na replikaci dat mezi dvěmi databázovýmí servery. Jedná se o: 37

38 Přenos transakčních log souborů na standby server. Zrcadlení dat mezi servery. V prvním případě se jedná o tzv. log shipping, kdy jsou transakční logy databáze z primárního serveru přenášeny na standby server, kde jsou následně aplikovány na databázi. Jedním z úskalí tohoto řešení je manuální zásah administrátorů v případě nutnosti přepojení primární databáze na sekundární. Tato akce je časově náročná, a to nejen z pohledu manuálních úkolů administrátorů, ale i aplikace neuskutečněných změn na straně standby databáze. Dalším problémem je také přístup klientských aplikací, které musí být překonfigurovány směrem k standby databázi a vlastní failover nebude pro uživatele tak transparentní jako v případě řešení pomocí clusterware. Určitým rizikem může být i částečná ztráta dat v případě havárie primárního serveru. Co se týče nároku na hardware, klíčové pro toto řešení je celková velikost diskového prostoru, neboť na obou serverech musí být udržováno stejné množství dat. Možnou výjimkou je slabší hardware na straně standby, u něhož je možné v případě havárie primárního serveru akceptovat po omezenou dobu nižší výkon. Z pohledu softwarového vybavení musí být databázový software implementován ve stejné verzi, včetně veškerých opravných balíčků na všech serverech. Implementace celého řešení je na druhou stranu poměrně jednoduchá. Podmínkou pro využití funkce standby databáze je zapnutí log archiving, který umožňuje přesun a obnovení transakčních logů. Archivaci logů je možné zapnout ve dvou režimech, a to buď v režimu pull, kdy jsou logy ukládány na sdílené úložiště, nebo v režimu push, který zajišťuje přesun logů na standby stranu. Následně je na standby straně nastaven časový plán, ve kterém jsou logy z primární strany aplikovány na databázi. Obrázek 13: IBM DB2 Log shipping Zdroj:http://www.ibm.com/developerworks/data/library/techarticle/0304mcinni s/0304mcinnis.html 38

39 V případě, že dojde k výpadku primární strany, je potřeba pro failover na standby stranu provést následující kroky: Pokud je to možné, převést zbývající logy na standby server. Provést aplikaci všech dosud neaplikovaných změn v databázi pomocí logů. Přepojení klientů na standby stranu. V případě standby strany je možné vypnout automatické aplikace logů z primární strany, což přináší několik výhod tohoto řešení. Při porušení dat na primární straně není tato chyba přenesena ihned na standby stranu a je možné klienty přepnout na databázi s nepoškozenými daty. Další výhodou tohoto řešení je možnost nezávislé aplikace patchů produktu, které je možné aplikovat postupně. Po úspěšné aplikaci patchů jsou klienti přepojeni na nově opatchovaný server a patche jsou doinstalovány i na dalších serverech. Toto řešení tedy přináší relativně levnou a poměrně spolehlivou náhradu klasického řešení vysoké dostupnosti pomocí clusterware. Druhou alternativou vysoké dostupnosti je zrcadlení dat databáze mezi dvěma servery. Klíčovým prvkem tohoto řešení je suspended I/O and online split mirror funkcionalita. Pomocí této vlastnosti je možné provádět zrcadlení dat databáze za jejího běhu, aniž by bylo nutné databázi vypnout. Právě v případě zrcadlení dat na discích je potřeba zajistit, aby databáze nezapisovala jakákoliv data na disk, a to tak, aby nedošlo k nekonzistenci kopie dat provedené pomocí zrcadlení. Právě tím, že nejsou prováděny zápisy dat na disk, je zajištěna identická kopie v jednom konkrétním okamžiku. Takto zrcadlená data je možné následně použít pro start databáze na záložním serveru. Pro tuto možnost platí v podstatě obdobná omezení jako pro první variantu, tzn., že je opět nutné udržovat stejnou verzi IBM DB2 na obou serverech, a i nároky na hardware jsou identické. Rozdíl je v tom, že data jsou na druhou stranu přenesena tak, jak existovala v určitém čase, a není nijak zaručena jejich synchronizace od posledního zrcadlení. Změny dat je možné aplikovat pomocí transakčních logů manuálně. Toto řešení přináší další možnosti, které se primárně netýkají vysoké dostupnosti. Mezi tyto možnosti patří jednoduché provádění záloh databází nebo jejich klonů. Výhody a nevýhody jsou obdobné jako u předchozího řešení pomocí log shipping. V případě využití této varianty 39

40 se zvyšují nároky na činnost administrátorů systému a je zde větší pravděpodobnost ztráty určité části dat. Transparentní přístup klientů je možné zajistit využitím Automatic client reroute (ACR). Pomocí ACR je možné pro konkrétní instanci databáze uvést alternativní server, na který je možné směrovat požadavky v případě pádu primárního serveru. Na alternativním serveru musí databáze existovat a musí být zaručena aktuálnost dat pomocí některé ze zmíněných možností vysoce dostupného databázového systému. Záznam o alternativním serveru je uložen v konkrétní instanci databáze a následně je propagován klientům při jejich připojení k primárnímu serveru. Obrázek 14: IBM DB2 Automatic client reroute Zdroj: V případě, že je ACR nastaveno, klient se v případě prvního neúspěšného připojení k databázi pokusí znovu navázat spojení. V případě, že se spojení opět nezdaří, pokusí se spojit na alternativní server, který byl dříve nastaven pro konkrétní databázi. ACR má několik základních limitů, kterým je potřeba věnovat pozornost: Verze IBM DB2 na alternativním serveru musí být minimálně stejná, nebo vyšší než je na primárním serveru. V případě, že je klient přesměrován na alternativní server, jsou od té doby veškerá nová spojení prováděna na alternativní server. Pokud je potřeba klienty směrovat opět na primární server, je nutné provést manuální zásah. Přesměrování klientů zpět na primární server je 40

41 poměrně krkolomný proces, při kterém je zapotřebí buď vypnout alternativní server, zakatalogovat nový databázový alias pro původní primární server nebo zrušit databázový alias v katalogu a provést jeho znovuvytvoření. V případě zrušení spojení jsou všechna nastavení poplatná pro konkrétní session ztracena. Další důležitou vlastností, kterou IBM DB2 v rámci podpory vysoce dostupného prostředí poskytuje, jsou tzv. Server lists. Tyto listy serverů jsou následně využívány pro rozdělování zátěže v případě implementace DB2 purescale nebo pro automatické přesměrování klientských požadavků zmíněných dříve. Tyto listy obsahují názvy serverů a jejich prioritu. V případě, kdy se klient připojí k DB2 serveru, je mu tento list automaticky vrácen a klient si ho následně uloží pro svoje další použití. Tento seznam je průběžně aktualizován, aby klient měl vždy aktuální kopii seznamu všech serverů. V případě DB2 HADR je možné implementovat až tři standby databáze, čímž je možné dosáhnout vysoké dostupnosti s společně s implementací disaster recovery. Synchronizace dat je prováděna pomocí transakčních logů a je možné zvolit různé módy synchronizace v závislosti na požadované ochraně proti ztrátě dat. Čím bezpečnější mód, tím delší bude čas nutný na dokončení transakcí a celkové řešení bude ztrácet na výkonu. Je důležité vybrat ten správný mód s ohledem na požadavky. Mód synchronizace je možné vybrat z následujících čtyř variant: SYNC zápis do transakčního logu je úspěšný pouze v případě, že jsou informace zapsány do logu na primárním serveru a primární server přijme oznámení o úspěšném zápisu do logu na standby straně. NEARSYNC zápis do transakčního logu je úspěšný pouze v případě, že jsou informace zapsány do logu na primárním serveru a primární server přijme oznámení o úspěšném zápisu do paměti na standby straně. ASYNC zápis do transakčního logu je úspěšný pouze v případě, že jsou informace zapsány do logu na primárním serveru a informace jsou odeslány do vrstvy TCP na primárním serveru. V tomto módu se nečeká na potvrzení ze standby strany a zápis do logu je považován za úspěšný při pouhém odeslání informace standby straně. 41

42 SUPERASYNC zápis do transakčního logu je úspěšný pouze v případě, že jsou informace zapsány do logu na primárním serveru. Obrázek 15: DB2 HADR synchronizační módy Zdroj:http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/index.jsp?topic=%2Fco m.ibm.db2.luw.admin.ha.doc%2fdoc%2fc html Další užitečnou vlastností DB2 HADR je možnost Reads on standby umožňující nasměrovat klientské aplikace, které z databáze pouze čtou proti standby replikám databáze. Tato vlastnost vylepšuje celkovou výkonnost databázového systému tím, že všechny požadavky nejsou směrovány pouze na jeden server. Další možností nastavení je tzv. Delayed replay. Tato služba zajistí uchování aktuálního stavu dat standby databáze k určitému časovému okamžiku. Když dojde k poškození dat na primární databázi, je možné přepnout požadavky na standby databázi, kde data nejsou ovlivněna změnami na primární databázi. IBM se svojí databází DB2 také nabízí plnohodnotné cluster řešení. Službou, která tuto podporu nabízí, je IBM DB2 purescale. S touto edicí přichází klasické clusterové řešení, které se skládá z několika členů clusteru odbavujících požadavky ze strany klientů. Všichni členové tohoto clusteru mají přístup ke sdíleným datům a tím odpadá složité řešení replikace dat mezi jednotlivými členy clusteru tak jako u DB2 HADR. DB2 purescale v sobě zahrnuje následující softwarové komponenty podporující clusterové řešení: DB2 cluster member. Cluster caching facilities(cf). DB2 cluster service managemenet software založený na IBM Tivoli System Automation for Multiplatforms. 42

43 Clusterový filesystem založený na GPFS. V případě IBM DB2 purescale je možné využívat obdobných vlastností IBM DB2 HADR, jakými jsou rozdělování zátěže pomocí server listů a zajištění transparentního přístupu klientských aplikací pomocí ACR. Každý z členů clusteru má své vlastní bufferpooly, vlastní paměťové oblasti pro práci s daty a vlastní logy. Je tedy schopen samostatně obsluhovat požadavky klientů. Obrázek 16: IBM DB2 purescale cluster member Zdroj: 05.ibm.com/at/events/software_experience/pdf/DB2_pureScale_Architecture.p df Důležitou částí v celkovém řešení je server poskytující Cluster caching facilities (CF). Tato komponenta v celém řešení figuruje jako centrální správa zámku nad celou databází a centrální cache pro data. Všichni členové clusteru komunikují s CF pomocí interní sítě využívané pouze servery v clusteru. Další důležitou vlastností tohoto řešení je využití technologie RDMA umožňující vzdálený přístup kteréhokoliv člena clusteru přímo do paměti CF. V případě, že jakýkoliv člen clusteru vyžaduje přístup k datům z databáze, které nemá ve svém lokálním bufferpoll, prostřednictvím RDMA zapíše tento požadavek přímo do paměti CF. Pokud se požadovaná data nacházejí v centrálním bufferpool CF, zapíše tato data zpět pomocí RDMA přímo do paměti člena clusteru, který požadavek zaslal. Podobná operace probíhá i v případě, kdy 43

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

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

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

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

Healtcheck. databáze ORCL běžící na serveru db.tomas-solar.com pro

Healtcheck. databáze ORCL běžící na serveru db.tomas-solar.com pro Ukázka doporučení z health checku zaměřeného na PERFORMANCE. Neobsahuje veškeré podkladové materiály, proto i obsah píše špatné odkazy. Healtcheck databáze ORCL běžící na serveru db.tomas-solar.com pro

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

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

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

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

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

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

O Apache Derby detailněji. Hynek Mlnařík

O Apache Derby detailněji. Hynek Mlnařík O Apache Derby detailněji Hynek Mlnařík Agenda Historie Vlastnosti Architektura Budoucnost Historie 1997 Cloudscape Inc. - JBMS 1999 Informix Software, Inc. odkoupila Cloudscape, Inc. 2001 IBM odkoupila

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

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

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

UAI/612 - Cloudová Řešení. Návrh aplikací pro cloud

UAI/612 - Cloudová Řešení. Návrh aplikací pro cloud UAI/612 - Cloudová Řešení Návrh aplikací pro cloud Rekapitulace Cloud computing Virtualizace IaaS, PaaS, SaaS Veřejný, Privátní, Komunitní, Hybridní Motivace Návrh aplikací pro cloud Software as a Service

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

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

Služba ve Windows. Služba (service) je program

Služba ve Windows. Služba (service) je program Služby Windows Autorem materiálu a všech jeho částí, není-li uvedeno jinak, je Ing. Libor Otáhalík. Dostupné z Metodického portálu www.rvp.cz, ISSN: 1802-4785. Provozuje Národní ústav pro vzdělávání, školské

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

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

Cloudová Řešení UAI/612

Cloudová Řešení UAI/612 Cloudová Řešení UAI/612 Kontakt Ondřej Urbánek ondrej.urbanek@orchitech.cz Výuka 7.3. 2014 13:00 21.3.2014 13:00 11.4. 2014 13:00 24.5. 2014 13:00 Cloudová Řešení Co je to cloud? Co je pro něj charakteristické?

Více

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY

TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Příloha č. 3 k č.j. MV-159754-3/VZ-2013 Počet listů: 7 TECHNICKÁ SPECIFIKACE VEŘEJNÉ ZAKÁZKY Nové funkcionality Czech POINT 2012 Popis rozhraní egon Service Bus Centrální Místo Služeb 2.0 (dále jen CMS

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

Základní parametry tříd serveroven a datových center TIER

Základní parametry tříd serveroven a datových center TIER Základní parametry tříd serveroven a datových center TIER 1/6 Jaroslav Přibyl, 1. 2. 2008 Přehled použitých termínů a zkratek, základní pojmy Availability Reliability MTBF MTTR Redundancy SPOF (single

Více

Business Intelligence

Business Intelligence Business Intelligence Josef Mlnařík ISSS Hradec Králové 7.4.2008 Obsah Co je Oracle Business Intelligence? Definice, Od dat k informacím, Nástroj pro operativní řízení, Integrace informací, Jednotná platforma

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

Zabezpečení v síti IP

Zabezpečení v síti IP Zabezpečení v síti IP Problematika zabezpečení je dnes v počítačových sítích jednou z nejdůležitějších oblastí. Uvážíme-li kolik citlivých informací je dnes v počítačích uloženo pak je požadavek na co

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

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

Windows Server 2003 Active Directory

Windows Server 2003 Active Directory Windows Server 2003 Active Directory Active Directory ukládá informace o počítačích, uživatelích a ostatních objektech v síti. Zpřístupňuje tyto zdroje uživatelům. Poskytuje komplexní informace o organizaci,

Více

Hana Jedličková Novell Tour Praha, 19.4.2012

Hana Jedličková Novell Tour Praha, 19.4.2012 Novell Open Enterprise Server Hana Jedličková Novell Tour Praha, 19.4.2012 Řízení sítí na těch nejstabilnějších základech Novell Open Enterprise Server Open Enterprise Server (OES) nabízí jedinečnou možnost

Více

Zálohování a obnova databáze. Kryštof Měkuta 15. 12. 2011

Zálohování a obnova databáze. Kryštof Měkuta 15. 12. 2011 Zálohování a obnova databáze Kryštof Měkuta 15. 12. 2011 Zálohovací strategie RMAN User-Managed Backup and Recovery Import / Export On-line Backups Off-line Backups ARCHIVELOG mode V archivelog modu se

Více

Magic Power vzdálené sledování finančních dat. Popis a funkce systému. Strana: 1 / 6

Magic Power vzdálené sledování finančních dat. Popis a funkce systému. Strana: 1 / 6 Popis a funkce systému Strana: 1 / 6 OBSAH Úvod... 2 Popis systému... 2 Popis systému VTZ... 4 Popis systému server... 5 Popis systému klient... 6 ÚVOD Vícemístné technické zařízení (VTZ) Magic Power lze

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

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

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

Alcatel-Lucent VitalQIP DNS/DHCP & IP Management Software

Alcatel-Lucent VitalQIP DNS/DHCP & IP Management Software Vítáme Vás Alcatel-Lucent VitalQIP DNS/DHCP & IP Management Software Pavel Moulis 13.9.2012 COPYRIGHT 2011 ALCATEL-LUCENT ENTERPRISE. ALL RIGHTS RESERVED. AGENDA 1. Co je IPAM definice, výzvy 2. VitalQIP

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

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

Load Balancer. RNDr. Václav Petříček. Lukáš Hlůže Václav Nidrle Přemysl Volf Stanislav Živný

Load Balancer. RNDr. Václav Petříček. Lukáš Hlůže Václav Nidrle Přemysl Volf Stanislav Živný Load Balancer RNDr. Václav Petříček Lukáš Hlůže Václav Nidrle Přemysl Volf Stanislav Živný 1.4.2005 Co je Load Balancer Nástroj pro zvýšení výkonnosti serverů Virtuální server skrývající farmu skutečných

Více

9. Sítě MS Windows. Distribuce Windows. Obchodní označení. Jednoduchý OS pro osobní počítače, pouze FAT, základní podpora peer to peer sítí,

9. Sítě MS Windows. Distribuce Windows. Obchodní označení. Jednoduchý OS pro osobní počítače, pouze FAT, základní podpora peer to peer sítí, 9. Sítě MS Windows MS Windows existoval ve 2 vývojových větvích 9x a NT, tyto později byly sloučeny. V současnosti existují aktuální verze Windows XP a Windows 2003 Server. (Očekává se vydání Windows Vista)

Více

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

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

BM Software, Databáze Docházky 3000 na NAS serveru (pro MySQL) Němčičky 84, 69107 Němčičky u Břeclavi. Úvodní informace:

BM Software, Databáze Docházky 3000 na NAS serveru (pro MySQL) Němčičky 84, 69107 Němčičky u Břeclavi. Úvodní informace: BM Software, Němčičky 84, 69107 Němčičky u Břeclavi Vývoj, výroba, prodej a montáž docházkových a identifikačních systémů Tel: 519 430 765, Mobil: 608 447 546 e-mail: bmsoft@seznam.cz web: http://www.dochazka.eu

Více

Brno. 30. května 2014

Brno. 30. května 2014 Brno 30. května 2014 1 IBM regionální zástupci - Morava Lubomír Korbel phone: +420 737 264 440 e-mail: lubomir_korbel@cz.ibm.com Dagmar Krejčíková phone: +420 737 264 334 e-mail: dagmar_krejcikova@cz.ibm.com

Více

Daniela Lišková Solution Specialist Windows Client. daniela.liskova@microsoft.com

Daniela Lišková Solution Specialist Windows Client. daniela.liskova@microsoft.com DESKTOP: Windows Vista Daniela Lišková Solution Specialist Windows Client daniela.liskova@microsoft.com TCO desktopů analýzy spol. Gartner Téměř 80% všech nákladů v IT vzniká po nákupu tj. na správě, opravě,

Více

NAS 251 Seznámení s RAID

NAS 251 Seznámení s RAID NAS 251 Seznámení s RAID Nastavení disků s RAID A S U S T O R C O L L E G E CÍLE KURZU V tomto kurzu se naučíte: 1. Co je RAID a jeho různé nastavení 2. Nastavit nové disky s RAID PŘEDCHOZÍ ZNALOSTI Předchozí

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

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

Relační databáze. V dnešní době existuje řada komerčních DBMS, nejznámější jsou:

Relační databáze. V dnešní době existuje řada komerčních DBMS, nejznámější jsou: Relační databáze Pojem databáze, druhy databází Databází se myslí uložiště dat. V době začátků využívání databází byly tyto členěny hlavně hierarchicky, případně síťově (rozšíření hierarchického modelu).

Více

Tonda Beneš Aplikace bezpe nostních mechanism jaro 2011

Tonda Beneš Aplikace bezpe nostních mechanism jaro 2011 Dostupnost Pro? Hacke i, bezpe nostní slabiny Závady systému, disk,... Ztráty napájení Požáry Bou e Záplavy, voda Zem esení Teroristé Vandalismus, kriminální živly Extrémní teploty, vlhkost,... Ztráty

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

Ope p r e a r čn č í s ys y té t m é y y Windo d w o s Stručný přehled

Ope p r e a r čn č í s ys y té t m é y y Windo d w o s Stručný přehled Windows 2008 R2 - úvod Jan Žák Operační systémy Windows Stručný přehled Klientské OS Windows 95, 98, ME Windows NT Windows 2000 Windows XP Windows Vista Windows 7 Windows CE, Windows Mobile Windows Phone

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

Administrace a Enterprise vlastnosti. RNDr. Ondřej Zýka

Administrace a Enterprise vlastnosti. RNDr. Ondřej Zýka Administrace a Enterprise vlastnosti RNDr. Ondřej Zýka 1 Cíle administrace Instalace Zálohování Dostupnost Sledování Ladění Bezpečnost Obsah Řešení plánovaných i neplánovaných problémů 2 Administrace datového

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

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

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

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

INSTALACE DATABÁZE ORACLE A SYSTÉMU ABRA NA OS WINDOWS

INSTALACE DATABÁZE ORACLE A SYSTÉMU ABRA NA OS WINDOWS INSTALACE DATABÁZE ORACLE A SYSTÉMU ABRA NA OS WINDOWS 1. 2. 3. 4. 5. 6. 7. 8. 9. Instalace Oracle verze 11.02. 64 bit... 2 Instalace Listeneru... 8 Vytvoření instance databáze... 10 Úprava konfigurace

Více

Versiondog 2.1.1 Co je nového

Versiondog 2.1.1 Co je nového Versiondog 2.1.1 Co je nového Lukáš Rejfek, Pantek (CS) s.r.o. 11/2012 Strana 2 Úvod Nová verze produktu Versiondog 2.1.1 přináší oproti verzím 1.52.x mnoho nových funkčností i nové typy komponent, které

Více

DOPLNĚK. Projekt Informační systém základních registrů je spolufinancován Evropskou unií z Evropského fondu pro regionální rozvoj.

DOPLNĚK. Projekt Informační systém základních registrů je spolufinancován Evropskou unií z Evropského fondu pro regionální rozvoj. GLOBÁLNÍ ARCHITEKTURA ZÁKLADNÍCH REGISTRŮ DOPLNĚK Projekt Informační systém základních registrů je spolufinancován Evropskou unií z Evropského fondu pro regionální rozvoj. Obsah 1 Cíle dokumentu...3 2

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

Databáze II. 1. přednáška. Helena Palovská palovska@vse.cz

Databáze II. 1. přednáška. Helena Palovská palovska@vse.cz Databáze II 1. přednáška Helena Palovská palovska@vse.cz Program přednášky Úvod Třívrstvá architektura a O-R mapování Zabezpečení dat Role a přístupová práva Úvod Co je databáze Mnoho dat Organizovaných

Více

Microsoft.NET. AppTima Feedback Solution - komplexní systém pro zjišťování a vyhodnocování spokojenosti zákazníků

Microsoft.NET. AppTima Feedback Solution - komplexní systém pro zjišťování a vyhodnocování spokojenosti zákazníků Microsoft.NET AppTima Feedback Solution - komplexní systém pro zjišťování a vyhodnocování spokojenosti zákazníků Přehled Země: Velká Británie Odvětví: Informační technologie Profil zákazníka Pantek Ltd.

Více

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz

Vývoj moderních technologií při vyhledávání. Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz Vývoj moderních technologií při vyhledávání Patrik Plachý SEFIRA spol. s.r.o. plachy@sefira.cz INFORUM 2007: 13. konference o profesionálních informačních zdrojích Praha, 22. - 24.5. 2007 Abstrakt Vzhledem

Více

Společnost repostor by ráda snížila vaše TCO

Společnost repostor by ráda snížila vaše TCO Společnost repostor by ráda snížila vaše TCO V tomto dokumentu najdete odpovědi na vaše otázky týkající se: ROI (Return on Investment, Návratnost investic) Až 43 větší úspora místa TCO (Total Cost of Ownership,

Více

Semináˇr Java X J2EE Semináˇr Java X p.1/23

Semináˇr Java X J2EE Semináˇr Java X p.1/23 Seminář Java X J2EE Seminář Java X p.1/23 J2EE Složitost obchodních aplikací robusní, distribuované, spolehlivé aplikace s transakcemi na straně serveru, klientské aplikace co nejjednodušší Snaha : Návrh,

Více

Zotavení z chyb. Databázové systémy

Zotavení z chyb. Databázové systémy Zotavení z chyb Databázové systémy Zotavení z chyb v DBS Úloha: Po chybě obnovit poslední konzistentní stav databáze Třídy chyb: 1. Lokální chyba v ještě nepotvrzené transakci 2. Chyba se ztrátou hlavní

Více

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena.

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. 2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. GEOVAP, spol. s r. o. Čechovo nábřeží 1790 530 03 Pardubice Česká republika +420 466 024 618 http://www.geovap.cz V dokumentu použité názvy programových

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

Bezpečn č os o t t dat

Bezpečn č os o t t dat Bezpečnost dat Richard Biječek Samostatný pevný disk RAID (Redundant Array of Independent Disks) SW implementace (Dynamické disky) HW řešení (BIOS, Řadič disků) Externí disková pole iscsi Fiber Channel

Více

PRODEJ Prodej je pochopitelně základní funkcí pokladního systému. Systému MERCATOR umožňuje prodej realizovat ve 3 režimech:

PRODEJ Prodej je pochopitelně základní funkcí pokladního systému. Systému MERCATOR umožňuje prodej realizovat ve 3 režimech: MERCATOR Moderní pokladní systém od společnosti SICONET a.s. Co je MERCATOR MERCATOR je PC pokladní systém určený především maloobchodním a velkoobchodním prodejnám společností, jejichž podnikovým systémem

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

Instalujeme a zakládáme databázi Oracle Database 11g

Instalujeme a zakládáme databázi Oracle Database 11g KAPITOLA 2 Instalujeme a zakládáme databázi Oracle Database 11g Protože se instalace systému Oracle s každou novou verzí zjednodušuje, stojí uživatel před pokušením otevřít krabici s médii a ihned začít

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

Platební systém XPAY [www.xpay.cz]

Platební systém XPAY [www.xpay.cz] Platební systém XPAY [www.xpay.cz] implementace přenosu informace o doručení SMS verze 166 / 1.3.2012 1 Obsah 1 Implementace platebního systému 3 1.1 Nároky platebního systému na klienta 3 1.2 Komunikace

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

QNAP TS-409 a QNAP TS-409 Pro. Jak použít funkci Online RAID Capacity Expansion a RAID Level Migration

QNAP TS-409 a QNAP TS-409 Pro. Jak použít funkci Online RAID Capacity Expansion a RAID Level Migration QNAP TS-409 a QNAP TS-409 Pro Jak použít funkci Online RAID Capacity Expansion a RAID Level Migration [1] Úskalí současných firem Jedním největších problémů, kterým dnešní firmy čelí je výběr a správné

Více

12. Virtuální sítě (VLAN) VLAN. Počítačové sítě I. 1 (7) KST/IPS1. Studijní cíl. Základní seznámení se sítěmi VLAN. Doba nutná k nastudování

12. Virtuální sítě (VLAN) VLAN. Počítačové sítě I. 1 (7) KST/IPS1. Studijní cíl. Základní seznámení se sítěmi VLAN. Doba nutná k nastudování 12. Virtuální sítě (VLAN) Studijní cíl Základní seznámení se sítěmi VLAN. Doba nutná k nastudování 1 hodina VLAN Virtuální síť bývá definována jako logický segment LAN, který spojuje koncové uzly, které

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

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

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

Acronis. Lukáš Valenta lukas.valenta@acronis.cz www.acronis.cz

Acronis. Lukáš Valenta lukas.valenta@acronis.cz www.acronis.cz Acronis Lukáš Valenta lukas.valenta@acronis.cz www.acronis.cz Acronis Kdo jsme? Společnost se sídlem v USA Zálohovací software Software pro ochranu proti haváriím Nástroje pro správu disků Nástroje pro

Více

Slovenská spořitelna:

Slovenská spořitelna: Případová studie Slovenská spořitelna: Microsoft Dynamics CRM pro správu klientů ze segmentu malých a středních podniků Jak jsme Slovenské spořitelně usnadnily a zefektivnily práci s klienty ze segmentu

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

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

Vladimír Mach. @vladimirmach 2. 1. 2013

Vladimír Mach. @vladimirmach 2. 1. 2013 Vladimír Mach @vladimirmach 2. 1. 2013 SQL Server Compact Edition Jednoduchá relační databáze Použití i v malých zařízeních s omezenými zdroji Dříve pod názvem SQL Server Mobile Časté využití při programování

Více

1 Správce licencí Správce licencí Správce licencí Start > Všechny programy > IDEA StatiCa > Správce licencí Soubor > Správce licencí Licence

1 Správce licencí Správce licencí Správce licencí Start > Všechny programy > IDEA StatiCa > Správce licencí Soubor > Správce licencí Licence 1 Správce licencí Programy IDEA jsou chráněny proti neoprávněnému použití. Pro běh programu je vyžadována platná licence. Upozornění: Lokální licence na pracovní stanici a síťová licence Eleckey jsou softwarové

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

plussystem Příručka k instalaci systému

plussystem Příručka k instalaci systému plussystem Příručka k instalaci systému Tato příručka je určena zejména prodejcům systému a případně koncovým uživatelům. Poskytuje návod, jak provést potřebná nastavení komponent. ITFutuRe s.r.o. 26.2.2015

Více

Jakou cenu má IT pro vaši společnost Seminář Jak pomáhat českým firmám a institucím při přechodu do cloudu? VŠE, 12. 12. 2013

Jakou cenu má IT pro vaši společnost Seminář Jak pomáhat českým firmám a institucím při přechodu do cloudu? VŠE, 12. 12. 2013 Jakou cenu má IT pro vaši společnost Seminář Jak pomáhat českým firmám a institucím při přechodu do cloudu? VŠE, 12. 12. 2013 Martin Souček Manažer pro datová centra České radiokomunikace, a.s. IT vstupuje

Více

Instrukce pro vzdálené připojení do učebny 39d

Instrukce pro vzdálené připojení do učebny 39d Instrukce pro vzdálené připojení do učebny 39d Každá skupina má k dispozici jedno sdílené připojení, prostřednictvím kterého se může vzdáleně připojit do učebny 39d a pracovat na svých semestrálních projektech

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

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

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