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. ( 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: 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: jdbc:oracle:thin:@scan_dns_name:1521/oraclesid. 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: 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: 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: 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