UNICORNE COLLEGE BAKALÁŘSKÁ PRÁCE

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

Č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 30.4.2014

................................... (Jan Mikolášek)

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.

Ř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

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

Obsah Úvod 1.

2.

3.

9

Co je vysoká dostupnost

12

1.1.

Plánované a neplánované výpadky

12

1.2.

Obecné řešení vysoké dostupnosti

13

1.3.

Celková dostupnost

17

1.4.

Řešení disaster recovery

19

1.5.

Klíčové prvky vysoké dostupnosti databázových systémů

21

1.5.1

Dostupnost aplikace z pohledu klienta

21

1.5.2

Data aplikace v režimu vysoké dostupnosti

22

1.5.3

Transakce v režimu vysoké dostupnosti

23

Řešení vysoké dostupnosti jednotlivých databází

25

2.1.

Oracle

25

2.2.

IBM DB2

35

2.3.

Microsoft SQL server

45

2.4.

mySQL

55

Porovnání vlastností HA pro jednotlivé DB

64

3.1.

Active/Active versus Active/Passive

64

3.2.

Stanby systémy

65

3.3.

Disaster Recovery

65

3.4.

Správa běžících transakcí

66

3.5.

Rozšiřitelnost celkové infrastruktury

66

3.6.

Přístup klienta/aplikace

66

3.7.

Závislost na komponentách třetích stran

67

3.8.

Složitost a robustnost celkového řešení

67

4.

Vlastní srovnání

68

5.

Vyhodnocení jednotlivých řešení, doporučení

77

6.

Závěr

79

7.

Seznam použité literatury

81

8.

Seznam použitých zkratek

84

9.

Seznam obrázků

87

10. Seznam tabulek

88 8

Ú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]. 2011 [cit. 2014-01-26]. Dostupné z: http://www.evolven.com/blog/downtime-outages-and-failures-understanding-their-truecosts.html

9

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

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

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á.

1.1.

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

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: http://www.appdynamics.com/blog/2013/09/04/how-much-doesdowntime-cost/

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“).

1.2.

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]. 4.9.2013 [cit. 2014-02-15]. Dostupné z: http://www.appdynamics.com/blog/devops/how-much-does-downtime-cost

13

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

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

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

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í.

1.3.

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 %: Dostupnost (%) =

DobaDostupnosti . 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): Dostupnost =

MTBF . 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

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: http://www.continuitycentral.com/feature0267.htm

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

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

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: http://www.macexperts.com.au/about/business-continuity

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

po kterou systém nebude dostupný, a na základě tohoto předpokladu navrhnout adekvátní řešení.

1.5.

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í. 1.5.1

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

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í. 1.5.2

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

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ě. 1.5.3

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

•

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

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 5.6.

2.1.

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

Obrázek 6: Oracle Real Application Cluster

Zdroj: http://www.oracle.com/technetwork/database/options/clustering/rac-wp12c-1896129.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

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

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

Obrázek 8: Load balancing připojení pomocí SCAN

Zdroj: http://www.oracle.com/technetwork/products/clustering/overview/scan129069.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: http://www.oracle.com/technetwork/products/cloud-storage/oracle-12casm-overview-1965430.pdf

29

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 STMG94055

30

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: http://www.oracle.com/technetwork/products/cloud-storage/oracle-12casm-overview-1965430.pdf Všechny zmiňované služby (Oracle ASM, CloudFS a Oracle clusterware), nutné, nebo doporučované pro implementaci Oracle RAC tvoří tzv. Oracle Grid Infrastructure3, 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, 2013. [cit. 2014-03-02].[dokument ve formátu PDF] Dostupný z URL: < http://www.oracle.com/technetwork/database/options/clustering/rac-wp-12c-1896129.pdf>.

31

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

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

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: http://www.oracle.com/technetwork/database/availability/active-dataguard-wp-12c-1896127.pdf 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

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.

2.2.

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

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 10.5. 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 DB2 10.5 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

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

•

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

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

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: http://www.redbooks.ibm.com/redbooks/pdfs/sg247363.pdf 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

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

•

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%2Fc0011724.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

•

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: http://www05.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

některý z členů clusteru požaduje provést modifikaci konkrétních dat. Člen clusteru pomocí RDMA zapíše požadavek na aplikaci zámku pro konkrétní záznam přímo do paměti CF. Následně CF potvrdí možnost přidělení tohoto zámku členovi clusteru zapsáním této informace přímo do jeho paměti. Další důležitou vlastností DB2 pureScale je systém správy dat a kontroly jejich integrity. IBM DB2 poskytuje plný přístup ke všem datům, které jsou validní a nepotřebují opravu. Data, která např. z důvodu nedokončení transakce potřebují opravu, jsou evidována a než jsou opět zpřístupněna, jsou nad nimi provedeny opravné operace. Pokaždé kdy jsou data z databáze načítána kterýmkoliv členem clusteru do jeho lokálního bufferpoolu, je v CF uložen záznam o této události. Kdykoliv je z aplikace proveden commit změn, je tato událost uložena členem clusteru, který požadavek klienta obsluhoval, přímo do paměti CF. Tento přístup mj. umožňuje čtení modifikovaných dat kterýmkoliv členem clusteru. Mnohem důležitější činnost CF přichází v situaci, kdy je člen clusteru, který data modifikoval, nedostupný. V tuto chvíli je úlohou CF provedení patřičných operací, a to zapsání commitovaných operací na disk a zrušení transakcí, které ještě nebyly commitovány. V případě clusteru se sdíleným diskem je nutné zajistit, aby k datům nikdo nepřistoupil do té doby, než budou opravena. Využívá se při tom situace, kdy CF je informován o všech transakcích,

které nedostupný člen clusteru

zpracovával, včetně již

commitovaných transakcí. Pro opravu je zvolen dostupný člen clusteru, který si jako první úkol vyčte data z paměti CF. Pro následný opravný proces si vyčte informace z log file nedostupného serveru a provede patřičné opravy dotčených dat. Vzhledem k tomu, že CF je klíčovou komponentou celého řešení, je doporučeno mít implementovány minimálně dvě CF komponety. Následně je možné nastavit ukládání dat do cache a informací o zámcích do obou CF a zajistit tím jejich redundanci. Následující obrázek znázorňuje minimální doporučovanou architekturu IBM DB2 pureScale s dvěma servery CF a čtyřmi členy clusteru poskytujících služby databáze.

44

Obrázek 17: Doporučená architektura IBM DB2 pureScale

Zdroj: http://www.redbooks.ibm.com/technotes/tips0926.pdf V rámci každého člena clusteru běží služba Cluster Service, která má za úkol monitoring následujících činností: •

přístup na filesystem,

•

CF procesy,

•

procesy DB2,

•

servery v clusteru,

•

síťové adaptéry.

I když IBM nabízí pro řešení disaster recovery technologii HADR, existuje i možnost nasadit DB2 pureScale cluster mezi dvěma vzdálenými lokalitami. Řešení IBM DB2 pureScale je plnohodnotným nástrojem pro řešení clusteringu databází a přináší sebou řadu zajímavých vlastností jakými jsou např. centrální správa zámků v databází nebo přímý přístup do paměti mezi členy clusteru.

2.3.

Microsoft SQL server

Poslední z řady Enterprise databázových systémů zařazených do tohoto srovnání je SQL server od společnosti Microsoft. Aktuální verze tohoto

45

produktu je SQL server 2012, i když se již blíží uvolnění nové verze SQL server 2014. Vzhledem k tomu, že spousta zajímavých vlastností a funkcionalit pro zajištění vysoké dostupnosti byla uvedena již ve verzi SQL server 2012, bude tato kapitola věnována právě této verzi. Společnost Microsoft, jakožto významný výrobce operačních systému jak pro servery tak pro pracovní stanice, již dlouho dobu poskytuje vlastní clusterware software Microsoft cluster server, který je součástí vybraných edicí serverových operačních systémů. Tento clusterware je součástí řešení vysoce dostupných databázových systémů od společnosti Microsoft. SQL server využívá konkrétně vlastností Windows server failover clustering (WSFC). Stejně jako u kterékoliv jiné implementace clusterware je WSFC cluster skupina několika serverů jevících se navenek jako celek. Důležitou vlastností clusterware od společnosti Microsoft je služba zajišťující správu unikátní IP adresy a hostname pro poskytované služby clusteru. Jinými slovy: tato IP adresa a hostname je nezávislá na síťovém nastavení jednotlivých serverů clusteru a je transparentní pro klientské aplikace, bez ohledu na to, který server clusteru aktuálně spravuje běžící aplikaci. Každá aplikace nasazená do prostředí Microsoft cluster server musí mít podporu pro tento typ nasazení, která je samozřejmou součástí SQL serveru již od verze 2000. Každá klientská aplikace je v rámci clusteru obsluhována vždy právě jedním serverem. Při výpadku aktivního serveru jsou služby buď automaticky, nebo manuálně startovány na jiném serveru, který je součástí clusteru. Každá aplikace běžící v clusteru má definovaný jeden primární server a jeden, nebo více sekundárních serverů, na kterých může být nastartována v případě výpadku primárního serveru. Toto vyplývá ze slovního spojení cluster failover, což znamená, že v případě selhání primárního serveru je proveden failover běžících služeb na záložní server. Microsoft cluster server 2012 podporuje až 64 serverů běžících v jednom clusteru 4. Vzhledem k tomu, že konkrétní aplikace běží vždy pouze na jednom serveru, nemůže dojít k přístupu ke stejným datům z více serverů. To ulehčuje správu konkurenčního přístupu ke stejným datům, avšak na druhou stranu znemožňuje škálování konkrétní 4

What's New in Failover Clustering in Windows Server 2012. Resources and Tools for IT Professionals | TechNet [online]. 2012, 2014 [cit. 2014-03-23]. Dostupné z: http://technet.microsoft.com/en-us/library/187d6191-4f92-4f98-9caec5e6d5b74e76#BKMK_SCALE

46

aplikace přidáváním více serverů do clusteru. V případě Microsoft clusteru je ale možné spravovat různé instance databázového serveru jinými fyzickými servery. Obrázek 18: SQL server Active/Passive cluster

Zdroj: http://blogs.technet.com/b/sql_server_isv/archive/2010/11/01/sql-server2008-r2-high-availability-options-for-temenos-t24-part-1-of-4-failoverclustering.aspx Ve verzi SQL server 2012 přišel Microsoft s funkcionalitou AlwaysOn, která přináší komplexní řešení pro vysokou dostupnost a disaster recovery. Jednou ze součástí AlwaysOn je tzv. AlwaysOn Failover Cluster Instance (FCI) využívající služeb Windows server failover clustering pro poskytování služeb redundance. FCI představuje samostatnou instanci SQL serveru nasazenou na více serverů WSFC. Z pohledu klienta představuje FCI transparentní instanci SQL serveru, tak jako by běžela na jednom serveru. FCI dále využívá další součást AlwaysOn funkcionality Availability Group (viz níže) pro podporu disaster recovery ve vzdálené lokalitě. Důležitým aspektem tohoto řešení je transparentní přístup klienta k databázi, která z jeho pohledu běží na stále stejné cílové adrese. V rámci clusteru je definována skupina serverů pro 47

konkrétní databázovou instanci, a platí, že vždy právě jeden server obsluhuje všechny uživatelské požadavky a ostatní servery jsou připraveny převzít jeho úlohu v případě jeho nedostupnosti. Takovýto server spravuje následující služby spojené s konkrétní instancí SQL serveru: •

síťové jméno serveru pro přístup k databázové instanci,

•

virtuální IP adresa serveru pro přístup k databázové instanci,

•

sdílené úložiště,

•

služby SQL serveru.

V případě, že dojde k pádu primárního serveru, dojde k failoveru na záložní server s provedením následujících činností: •

Pokud nedojde k chybě hardware nebo celého systému, jsou všechna transakční data uložená v paměti serveru zapsána na disk.

•

Všechny služby vztahující se k dané databázové instanci jsou zastaveny.

•

Vlastnictví databázové instance je přeneseno na jiný server v rámci FCI.

•

Nový vlastník databázové instance nastartuje potřebné služby.

•

Klientské požadavky jsou automaticky přesměrovány na nový server.

Čas nutný pro provedení failoveru ovlivňuje primárně faktor množství transakčních dat v paměti serveru. První činností, která je prováděna v rámci failoveru, je zapsání dat z paměti serveru na disk. Těchto dat v paměti serveru může být poměrně velké množství a může tedy trvat značnou dobu, než jsou data na disk zapsána. Z výkonových důvodů provádí databázový engine modifikaci dat ve své paměti a data na disk jsou zapisována v určitých intervalech, nikoliv však po každé změně. Parametr, který určuje zápis dat na disk, se nazývá Checkpoint, který je možné nastavit do jednoho z následujících režimů: •

Automatic – checkpoint je proveden automaticky na pozadí, maximálně v intervalu, který je dán parametrem recovery interval udávaném v sekundách. Tento parametr je nastaven na úrovni databázového serveru.

•

Indirect – checkpoint je proveden opět na pozadí, ale tentokrát je interval

určen

parametrem

target_recovery_time

udávaném

v sekundách, nebo minutách. Tento parametr je na rozdíl od

48

předchozího automatického checkpointu nastaven na úrovni databáze a jeho výchozí hodnota je rovna nule, což znamená využití nastavení automatického checkpointu. •

Manual – checkpoint je proveden manuálně, přímo pomocí SQL příkazu.

•

Internal – checkpoint je spuštěn pomocí specifických operací na serveru, jako je např. backup.

SQL server 2012 přichází s možností využití indirect checkpointu, který umožňuje ovlivnit maximální množství dat v paměti serveru a tím i dobu potřebnou pro provedení failover. Kdy a za jakých podmínek dojde k failoveru služeb na jiný server, je možné ovlivnit pomocí nastavení konkrétní úrovně pro parametr FailureConditionLevel. Následující tabulka uvádí seznam všech možných úrovní.

49

Tabulka 2: Úroveň chyby pro failover SQL serveru

Level

Akce

Popis naplnění podmínek pro provední akce

0

Automatický restart nebo Není naplněna žádná podmínka failover není proveden

1

•

Služba SQL server neběží

Automatický restart nebo

•

Služba SQL server neběží

failover

•

SQL

Automatický restart nebo failover

je

v případě,

že

proveden server

je

zastavený. 2

v případě,

je kdy

proveden server

nepřijme žádná data)

Automatický restart nebo

•

Služba SQL server neběží

failover

proveden

•

SQL server instance neodpovídá

v případě kritických chyb

•

sp_server_diagnostics

je

na serveru. 4

instance

neodpovídá(sp_server_diagnostics

neodpovídá. 3

server

vrátí

stav

„system error“

Automatický restart nebo

•

Služba SQL server neběží

failover

proveden

•

SQL server instance neodpovídá

v případě chyb na serveru

•

sp_server_diagnostics

je

nižší kategorie.

vrátí

stav

vrátí

stav

„system error“ •

sp_server_diagnostics „resource error“

5

Automatický restart nebo

•

Služba SQL server neběží

failover

proveden

•

SQL server instance neodpovídá

v případě jakékoliv chyby

•

sp_server_diagnostics

je

na serveru.

vrátí

stav

vrátí

stav

vrátí

stav

„system error“ •

sp_server_diagnostics „resource error“

•

sp_server_diagnostics

„query_processing error“ Zdroj: http://technet.microsoft.com/en-us/library/ff878664.aspx

50

Další součástí SQL Server AlwaysOn je služba tzv. Availability groups pro zajištění vysoké dostupnosti a disaster recovery na úrovni konkrétní databáze. Pomocí tohoto nástroje je možné vydefinovat skupinu databází, které jsou na sobě jakkoliv závislé, a je tedy zapotřebí udržet je dostupné pohromadě. V případě výpadku primárního serveru je pro všechny databáze v rámci konkrétní skupiny, tzv. availability databases, proveden failover na záložní server společně. Každá takto definovaná skupina je spravována pomocí tzv. availability replica. Availability replica je instancí availability groupy a může

být dvou typů. Primární replika je určena pro operace zápis/čtení a ke každé primární replice může existovat jedna až čtyři sekundární repliky. Sekundární replika slouží pro případ failoveru, kdy je proveden pro celou availability repliku, tedy pro skupinu konkrétních databází. Sekundární replika také poskytuje služby pro čtecí operace. Primární replika odesílá transakční data směrem k sekundárním replikám, kde jsou změny aplikovány do jednotlivých databází. Pro nasazení funkcionality availability group je opět nutný Windows server failover clustering. Každá availability replika musí být spravována jinou instancí SQL serveru dále spravovanou různými servery v rámci WSFC. Na druhou stranu je možné, aby každá SQL server instance byla využívána více skupinami availability group. Obrázek 19: SQL AlwaysOn availability group

Zdroj: http://technet.microsoft.com/en-us/library/ff877884.aspx Pro každou availability group je možné nastavit dvě úrovně commitu databázových transakcí: •

Asynchronous commit – primární replika provede commit transakce, aniž by čekala na potvrzení ze sekundárních replik, že byl proveden zápis do logu. Tento mód vylepšuje celkovou výkonnost řešení.

51

Určitým rizikem je však ztráta dat uložených v konkrétním časovém úseku. Tento mód je dobré použít v případě disater recovery, kdy jsou změny distribuovány přes sekundární repliky s minimální latencí transakcí. •

Synchronous commit – primární replika čeká na potvrzení ze sekundárních replik o úspěšném zápisu transakčních dat, než potvrdí commit. Tento mód umožňuje synchronní commit transakce až přes tři repliky, a to včetně commitu na primární replice. Je zde ovšem nutné počítat s určitým dopadem na výkonnost řešení.

Z pohledu procesu failover jsou role primární a sekundární repliky zaměnitelné. V případě failover se totiž ze sekundární repliky stává primární a je otevřena pro operace zápisu i čtení. Poté, co je původní primární replika opět spuštěna, zařadí se do role sekundární repliky. V rámci failover existují tři režimy, které jsou aplikovány na základě určitého nastavení: •

Plánovaný manuální failover – je proveden na základě požadavku administrátora. V tomto případě jsou prohozeny role primární a sekundární repliky. Tento typ failoveru je možný pouze v případě, že data mezi primární a sekundární replikou jsou synchronizována a mód commitu je nastaven na synchronní. Failoveru je tak zajištěn bez ztráty dat, jsou ztracena pouze data rozpracovaných transakcí, neboť primární replika provede rollback necommitovaných transakcí.

•

Automatický failover – nastává v reakci na nějakou chybu. Sekundární replika je opět povýšena na primární. Opět je za potřebí, aby byl mód commitu nastaven na synchronní, byl povolen automatický failover a aby sekundární replika byla synchronizována. Failover je opět proveden bez ztráty dat. Primární replika i v tomto případě provede rollback necommitovaných transakcí.

•

Vynucený manuální failover – používá se v případě disaster recovery a může být vyvolaný pouze manuálně. Pro tento typ failover je potřeba nastavení módu commitu na asynchronní. Při failoveru může dojít ke ztrátě dat. Před jeho provedním je proto nutné provést manuální kontrolu poslední commitované transakce na primárních a sekundárních replikách za účelem zjištění rozdílu v datech.

52

Klientské aplikace se připojují pomocí tzv. availability group listener, který definuje virtuální jméno serveru. Součástí této konfigurace může být i informace o sekundárních replikách, které klient může použít pro případ, že požaduje provést pouze operaci čtení. V případě, že dojde k failoveru v průběhu aktivního připojení klienta k databázi, musí klient navázat spojení znovu. Zajímavou možností, kterou přínáší availability group, je možnost patchování databáze za běhu. Je možné pozastavit server spravující sekundární repliku, aplikovat patche a zpět nastartovat. V případě, že je aplikace patchů úspěšná, je možné provést manuální failover a aplikovat patche i na primárním serveru. Další možností řešení je database mirroring. Jeho princip je podobný tomu, které používají availability group. Změny v datech jsou odesílány na záložní server, kde jsou aplikovány na databázi. Společnost Microsoft tuto funkcionalitu ve verzi SQL Server 2012 podporuje, nicméně je tato možnost utlumována a je doporučováno zákazníkům využití funkcionality availability group. Database mirroring funguje na principu dvou serverů spojených do tzv. database mirroring session. V rámci tohoto spojení vystupuje jeden server jako

primární, jeho role je označována jako principal server, a druhý server v režimu standby, označovaný jako mirror server. Toto spojení je vždy tvořeno právě dvěma servery, které mohou být umístěny v různých lokalitách. Přenos dat může opět fungovat jak v režimu synchronním, tak asynchronním. Na volbě režimu opět závisí rychlost celého řešení a také úroveň ztráty dat. Na rozdíl od dříve zmíněných replik, které fungují na logické úrovni, database mirroring funguje na fyzické úrovni práce s vlastními soubory transakčních logů. Od verze SQL server 2008 jsou data před jejich odesláním na mirror server komprimována. Pro failover mezi primárním serverem a mirror serverem platí stejné podmínky jako v předchozím případě a je možné využití tří typů failover: manuální failover, automatický failover a vynucený failover. Pro automatický failover je nutná implementace dalšího serveru, tzv. witness server, který monitoruje primární server. V rámci database mirroringu je

možné nastavit i konkurenční session, kdy dva servery jsou spojeny v rámci dvou různých session. Každý ze serveru figuruje v jiné roli pro různé session.

53

Obrázek 20: SQL database mirroring cuncurent session

Zdroj: http://technet.microsoft.com/en-us/library/ms189852.aspx Poslední možností pro zajištění vysoké dostupnosti Microsoft SQL databáze je možnost log shipping. Jak už název napovídá, jedná se o distribuci transakčních logů databáze z primárního serveru na sekundární servery. V případě Microsoft SQL se jedná o jednoduchý princip zálohování logů na primárním serveru, distribuci na sekundární servery a následné obnově těchto logů. Zde se spíše jedná o zajištění disaster recovery a ztráta dat bude primárně ovlivněna frekvencí zálohování. Typická architektura tohoto řešení je založena na sdílení záloh transakčních logů mezi primárním a sekundárními servery. Do celého řešení je možné zahrnout monitorovací server, který udržuje informace o průběhu zálohování a obnovy dat. Obrázek 21: SQL server log shipping

Zdroj: http://technet.microsoft.com/en-us/library/ms187103.aspx

54

Stejně tak jako předchozí dvě databáze od Oracle a IBM i databázové řešení společnosti Microsoft přináší více možností implementace vysoké dostupnosti. Jistým odlišením od předchozích dvou je implementace jednotného přístupu k databázi pomocí virtuálního jména serveru.

2.4.

mySQL

Posledním produktem zařazeným do porovnání je databázový systém mySQL. Do porovnání je zařazen mySQL verze 5.6 a mySQL Cluster NDB 7.3. Jedná se o databázový systém původně vyvinutý švédskou společností MySQL AB, která byla v roce 2008 koupena společností Sun Microsystem. Tato se rok po té stala součástí společnosti Oracle. Od té doby došlo k určitým změnám, nicméně databáze mySQL je stále poskytována v rámci bezplatné licence GPL nebo i nově pod komerční placenou licencí. Tento databázový systém je hojně využíván vývojáři webových stránek díky své jednoduchosti a nenáročnému způsobu nasazení. Databáze mySQL je oproti dříve popisovaným databázovým systémům o mnoho jednodušší, nicméně poskytuje dostatečný výkon a potřebné funkcionality, např. právě pro vývoj webových stránek. Často je i součástí sady software LAMP, která poskytuje jednoduchou a hlavně bezplatnou základnu pro webový server. I databázový systém mySQL se snaží reagovat na nové požadavky a neustále se tedy rozrůstá o nové funkcionality. Jeho součástí je mimo jiné podpora nasazení databázového systému v režimu vysoké dostupnosti. Poskytuje celou řadu možností pro implementaci vysoce dostupného řešení, od replikace dat až po clusterové řešení. První možností pro řešení vysoké dostupnosti mySQL je replikace dat mezi několika servery, kdy jeden server funguje jako primární a několik dalších serverů funguje v režimu slave. Vlastnost replikace databáze je standardní součástí distribuce mySQL. Veškeré změny do databáze jsou prováděny na úrovni primárního serveru a následně přenášeny a aplikovány na slave servery. Slave servery mohou být použity pro read operace a tím je možné snížit zatížení primárního serveru.

55

Obrázek 22: mySQL replication

Zdroj: http://www.mysql.com/content/download/id/371 Existuje několik módů replikace dat, a to buď replikace v asynchronním módu, synchronním módu, nebo speciálním semi-synchronním módu. Asynchronní replikace má jednu obrovskou výhodu, a to v tom, že primární server nečeká na potvrzení aplikace změn na slave serverech a může ihned po dokončení jedné transakce na primárním serveru pokračovat zpracováním dalších. Slave server nemusí být dokonce neustále připojen ke svému primárnímu serveru a replikace může probíhat v určitých časových intervalech a na velké vzdálenosti. Pomocí mySQL replikací je tedy možno implementovat geograficky rozsáhlé řešení distribuované databáze. V rámci replikace je možné vybrat pouze určitou část databázového systému až na úroveň konkrétních tabulek databáze. Úskalím jakékoliv asynchronní replikace je konzistence dat mezi primární a sekundární lokalitou, což se mySQL snaží řešit pomocí semi-synchronní replikace. V případě tohoto módu replikace je klientská aplikace informována o úspěšném commitu transakce pouze v případě, kdy je slave server úspěšně informován o změně v databázi, nebo dojde k timeoutu spojení mezi primárním a slave serverem (není podmínkou aplikace změn dat na slave serveru). Tento mód replikace je možné nastavit na úrovni konkrétního slave serveru. Je tedy možné vytvořit infrastrukturu

56

s různými módy replikací dat (asynchronnímy, nebo semi-synchronnímy) pro různé skupiny slave serverů. Posledního módu synchronní replikace je možné dosáhnout pomocí dvoufázových commitů. V tomto případě jsou změny aplikovány přes dva, nebo více systémů v rámci jedné operace commitu. Tato synchronní replikace přináší vyšší nároky na vnitřní komunikaci jednotlivých serverů spravujících prostředky zahrnuté do dvoufázového commitu. Další zajímavostí mySQL replikace je možnost jejího provádění pouze na úrovni SQL dotazů, nikoliv celých dat. Takovýto typ replikace přináší výhody např. v případě update velkého množství záznamů v databázi, kdy přenos vlastních změněných dat by byl mnohem náročnější než pouhá replikace SQL dotazu. Toto je výchozí mód mySQL replikace. Další alternativou je replikace na úrovni jednotlivých změněných řádků, kdy jsou události změny řádku zapsány do logu a replikovány na slave servery. Takováto replikace na jedné straně přináší vyšší požadavky na objem přenášených dat, na druhou stranu nevyžaduje tolik databázových zámků, a tudíž poskytuje i vyšší výkonnost celého řešení. Pro zajištění vysoké dostupnosti v případě implementace mySQL replikace je důležitý ještě jeden prvek s názvem Global Transaction Identifier (GTID), který jednoznačně identifikuje transakce na úrovní každého

serveru. Primárním účelem GTID je zajištění jednoduchého failoveru v případě nedostupnosti primárního serveru. Vzhledem k tomu, že replikace je asynchronní, je možné, že každý server v režimu slave přijal různou sadu transakcí, které aplikoval na svoji sekundární kopii. Pomocí GTID je možno určit, který server má nejaktuálnější data ve své lokální kopii. Tento server pak v případě failoveru převezme primární roli a následně jsou na zbylých serverech provedeny updaty transakcí, které ještě nebyly provedeny na ostatních slave serverech, ale byly provedeny na nově určeném primárním serveru. Následně pak všechny slave servery přijímají update z nově určeného primárního serveru. GTID se skládá ze dvou části: •

První část GTID je náhodně generované 128bitové číslo jednoznačně určující server.

•

Druhá část GTID určuje pořadí transakce, které je po každém úspěšném commitu do databáze automaticky povýšeno o jedničku.

První složka GTID zaručí unikátnost jedné transakce prováděné na různých serverech, zatímco druhá složka zaručí unikátnost pro různé transakce 57

provedené na stejném serveru. Na základě těchto údajů je možné pro mySQL replikace nastavit buď automatický, nebo manuální failover. Na základě definovaných podmínek je v případě nedostupnosti primárního serveru vybrán jeden server v roli slave, a to jako nový primární server celé infrastruktury. MySQL replikaci je také možné efektivně využít např. při potřebě aplikace opravných balíčků pro mySQL server. Je možné provést tzv. switchover, při němž je vybrán nový primární server z dostupných slave serverů. Na tento server jsou nejdříve aplikovány veškeré změny a původní primární server je uzamčen pro nové změny. Po aplikaci všech změn je původní primární server vypnut a vybraný slave server přebírá roli primárního serveru. Součástí mySQL replikace je také detekce chyb, aby nedocházelo k aplikaci poškozených dat při přenosu. Další užitečnou možností je využití time-delayed replikace, při níž jsou data replikována v časových intervalech. V případě, kdy dojde k nechtěnému smazání databázové tabulky, data mohou být dostupná ještě po určitý čas na ostatních slave serverech. Pokud při využití mySQL replikací dojde k failoveru, je nutné informovat všechny klienty o nutnosti přesměrovat své požadavky na zápis do databáze na nový primární server. Databázový systém mySQL přichází i se svým vlastním clusterovým řešením pod názvem mySQL Cluster NDB. Jedná se o tzv. in-memory cluster v režimu shared-nothing. Shared-nothing architektura počítá s tím, že každý server v infrastruktuře poskytující služby mySQL clusteru má své vlastní prostředky, jako jsou paměť, disky apod. Sdílená úložiště nejsou v případě mySQL clusteru podporována. Vzhledem k tomu, že se jedná o in-memory cluster, který pracuje s daty uloženými přímo v paměti serveru, je kladen důraz na velikost paměti každého serveru v clusteru. Tento clusterový systém implementuje služby mySQL serveru spolu s clusterovým in-memory úložištěm zvaným Network database (NDB). MySQL cluster se skládá z několika serverů nazývajících se cluster node, na kterých běží služby mySQL. Tyto cluster node existují ve třech typech: •

SQL node – proces mySQL serveru speciálně vyvinutý pro práci v clusteru který přistupuje k datům spravovaných data nodem.

•

Data node – stará se o správu dat (databázové tabulky a jejich data) mySQL clusteru.

58

•

Management node – stará se o vlastní správu celého mySQL clusteru. Spravuje jednotný konfigurační soubor clusteru, který distribuuje na jednotlivé nody clusteru. Obrázek 23: mySQL cluster

Zdroj: http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-overview.html Pokud kterýkoliv proces SQL node provede změnu v datech, ta je okamžitě dostupná všem ostatním SQL nodům neboť data jsou v synchroním režimu ukládána na disk spravována data nodem. MySQL server zajišťuje neustálou dostupnost služeb. V případě výpadku kteréhokoliv serveru clusteru dojde pouze ke zrušení transakcí prováděných tímto serverem. Nejdůležitějším článkem mySQL clusteru z pohledu dostupnosti dat je data node. Každý data node je zodpovědný za správku tzv. repliky, která odpovídá kopii určité části dat (partition) spravované mySQL clusterem. Každý z data node je zodpovědný za správu jedné nebo více replik. Data node jsou následně zařazeny do tzv. node group. Každá z nich spravuje sadu partition, nebo replik. Počet node group je dán poměrem počtu data nodů a replik. Na následujícím obrázku je naznačena vzorová architektura data node spravující celkem dvě repliky pro čtyři partition. Takováto architektura je schopna odolat výpadku až dvou serverů v případě, kdy každý z nich je členem jiné node group.

59

Obrázek 24: mySQL cluster dataNode

Zdroj: http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-nodesgroups.html Přístup klientských aplikací je možný několika způsoby podporujícími loadbalancing a failover. V případě Java klienta je možné nastavit load-balancing pomocí JDBC url. V případě NDB klientských programů je možné přistoupit přímo do úložiště mySQL clusteru a obejít tím mySQL server zapojený do clusteru. Zajímavou vlastností, kterou z popisovaných databázových systémů poskytuje pouze mySQL, je tzv. sharding. MySQL cluster automaticky rozděluje databáze do tzv. shardů, kdy jedna databázová tabulka je distribuována na více nodů. Z pohledu aplikace se tabulka tváří jako celek, nicméně různé části tabulky mohou být spravovány jinými servery. Tímto způsobem je možné zvýšit výkonnost celého řešení, protože za správu stejných dat databázové tabulky je zodpovědno více fyzických serverů a tím je umožněno paralelní zpracování. Rozdělením databázové tabulky se také snižuje velikost databázového indexu, který opět zvyšuje výkon celého řešení.

60

Obrázek 25: mySQL database sharding

Zdroj: https://www.mysql.com/products/cluster/scalability.html Další alternativou pro vysokou dostupnost mySQL přímo poskytovanou společností Oracle je využití Oracle VM Template. Tento způsob implementace je primárně určen pro cloud computing. Jedná se o integraci mySQL serveru, Oracle Linux a Oracle VM Template poskytující virtualizované prostředí mySQL clusteru. Oracle VM Template se skládá z následujících produktů: •

Oracle Enterprise Linux,

•

Oracle VM,

•

Oracle VM Manager,

•

Oracle Cluster File System,

•

MySQL databáze. Obrázek 26: Oracle VM

Zdroj: http://www.mysql.com/content/download/id/276/

61

Jedná se o předinstalované a předkonfigurované virtuální stroje s instalovaným mySQL databázovým systémem. Mezi zajímavé vlastnosti tohoto řešení patří nástroje pro automatické zotavení se z chyby a migrace běžících instancí mySQL serveru mezi fyzickými servery virtualizovaného prostředí. Když dojde k chybě, Oracle VM zajistí restart služby na jiném dostupném serveru v rámci skupiny serverů Oracle VM. V případě údržby serveru je také možné běžící instance mySQL přesunout na jiný fyzický. Samozřejmostí tohoto řešení je automatický IP failover, při němž systém využívá virtualizovanou IP adresu pro zajištění jednotného klientského přístupu, bez ohledu na to, na kterém fyzickém serveru služba běží. Oracle VM je možné provozovat v režimu Active/Passive. V případě výpadku primárního serveru je za pomoci automatické detekce chyby nastartována služba na jiném serveru. Poslední možností mySQL pro implementaci vysoce dostupného řešení je MySQL s DRBD/Pacemaker/Corosync/Oracle Linux. Jedná se o kombinaci clusterového řešení s replikací dat. Největším rozdílem mezi klasickým a tímto clusterovým řešením je absence sdíleného diskového úložiště. Data jsou zrcadlena mezi dvěma servery pomocí DRBD (Distributed replicated block device). DRDB je implementace distribuovaného a replikovaného úložiště pro Linux platformu. Toto zrcadlení je prováděno v synchronním režimu, tudíž je v případě pádu primárního serveru zajištěna dostupnost všech commitovaných transakcí na druhém serveru. Toto řešení umožňuje nasazení v režimu jednoho aktivního serveru a druhého v režimu standby. Přístup k datům, ať už pro čtení nebo zápis, je vždy možný pouze z jednoho serveru, druhý server nemůže fungovat ani pro operace typu čtení. Celé řešení je rozděleno do tří logických vrstev: •

Fyzické servery – běží na nich nutné služby tohoto řešení, které jsou aktivní vždy jen na jednom serveru.

•

Cluster vrstva – stará se o dostupnost jednotlivých služeb.

•

Poskytované služby.

62

Obrázek 27: MySQL, DRBD,Pacemaker,Corosync

Zdroj: http://dev.mysql.com/doc/mysql-ha-scalability/en/ha-drbd.html Vrstva clusterware je složena ze dvou klíčových služeb: •

Pacemaker – zajišťuje správný běh služeb výhradně na jednom serveru a používá agenty pro správu níže uvedených služeb: o DRDB služby – zajišťují zrcadlení dat, o služby mySQL databáze – spravují vlastní data v databázi, o Virtual IP address – spravuje virtuální adresy používané klienty pro transparentní přístup k mySQL databázi;

•

Corosync – poskytuje služby pro zasílání zpráv mezi servery a v případě jakýchkoliv změn v rámci clusteru o nich informuje službu pacemaker .

Tento model umožňuje transparentní přístup ze strany klientských aplikací a je hojně využívanou alternativou řešení vysoké dostupnosti pro mySQL databáze. MySQL poskytuje opět velmi různorodou škálu možností nasazení databáze do vysoce dostupného prostředí. Určitě zajímavou vlastností, se kterou přichází mySQL, je nasazení v režimu shared-nothing se současnou možností využití database sharding. Umožňuje nejen nasazení v režimu vysoké dostupnosti, ale i efektivní řešení pro zlepšení výkonu.

63

3.

Porovnání vlastností HA pro jednotlivé DB

Z dosavádního popisu plyne, že všechny popisované databázové systémy nabízejí řadu možností řešení vysoké dostupnosti. V některých případech jsou nabízené možnosti takřka totožné, v jiných se jedná o zcela unikátní případy, např. mySQL s funkcí database sharding. Z pohledu vysoké dostupnosti databázových systémů jsou klíčové zejména tři oblasti: dostupnost databáze z pohledu aplikace/klienta, správa sdílených dat a správa transakcí. Existují ale i další pohledy na vysoce dostupné řešení, mezi které může patřit např. výkon řešení, náročnost na celkovou hardwarovou infrastrukturu, podpora DR aj. Tato kapitola popisuje jednotlivá srovnávací kritéria.

3.1.

Active/Active versus Active/Passive

Hlavní rozdíl nasazení v režimech Active/Active nebo Active/Passive spočívá v počtu současně běžících aktivních služeb. V případě Active/Passive je služba spuštěna pouze na jednom serveru, který pak obsluhuje veškeré požadavky od klientů. Oproti tomu je v režimu Active/Active služba spuštěna na více serverech v rámci celé infrastruktury a klientské požadavky jsou směrovány dle vnitřní logiky řešení na různé servery. Většina výrobců se snaží implementovat takový algoritmus, aby byly požadavky rovnoměrně distribuovány mezi jednotlivé servery tak, aby se maximálně využilo jejich celkové kapacity. Mezi další výhody implementace v režimu Active/Active patří možnost sdílení informací mezi jednotlivými servery. V případě nedostupnosti kteréhokoliv serveru je takřka okamžitě schopen převzít jeho úlohu jiný server. Důležité je při tom zejména korektní ukončení rozpracovaných úloh nedostupného serveru. Pro režim Active/Passive je specifická určitá prodleva, po níž se všechny služby na pasivně čekajícím serveru nastartují. Mezi další výhody patří rozšiřitelnost řešení v režimu Active/Active v případě vzrůstajících nároků na databázový systém. Toto rozšiřování v režimu Active/Passive má určité limity, jeden server není možné rozšiřovat donekonečna. Součástí srovnání režimů Active/Active a Active/Passive je i přístup k vlastním datům, a to z pohledu sdílení dat mezi jednotlivými servery. Data mohou být buď sdílená, nebo může mít každý server vlastní kopii dat.

64

Model Active/Passive zvolí ten, kdo vyžaduje zvýšení dostupnosti svého systému a neočekává nárůst požadavků na jeho výkon. Opakem bude řešení Active/Active, při kterém je požadována maximální dostupnost řešení a zachována možnost zvýšení výkonu.

3.2.

Stanby systémy

Výhoda implementace standby systému spočívá především v jeho nezávislosti na primárním zdroji, tj. jedná se o úplně oddělený systém. Standby systém přijímá od svého primárního zdroje (systému) veškeré prováděné změny, které aplikuje na kopii dat standby systému. Pokud je primární systém nedostupný, je standby systém schopen převzít kompletně jeho roli. Tato varianta se nápadně podobá předchozímu řešení Active/Passive. Hlavní rozdíl spočívá v úplném oddělení standby systému, a to včetně diskového úložiště. Není tedy ani závislý na hardwarovém výpadku jakékoliv komponenty primární strany. Další častou výhodou tohoto řešení je možnost definovat více než jeden standby systém a poskytnout jeho data pro operace typu čtení. Znamená to tedy, že standby systém zároveň přijímá změny z primárního zdroje a poskytuje služby systému pro čtení. Toto řešení bude zvoleno k zajištění dostupnosti dat i při úplném výpadku celé primární infrastruktury. Může být částečně použito pro zvýšení celkového výkonu řešení, popř. i jako ochrana proti lidské chybě.

3.3.

Disaster Recovery

Jakkoliv robustní řešení stále nezaručuje neustálou dostupnost poskytovaných služeb. Jak již název napovídá, toto řešení má za úkol obnovu systému po totálním výpadku. Většinou se jedná o výpadek celé jedné lokality. Takovýchto výpadků může být celá řada, a to od výpadku proudu, internetového připojení až po povodeň nebo zemětřesení. IT systémy, které jsou pro společnost klíčové, musí být implementovány nejen v režimu HA, ale i v režimu DR, a to právě pro případy výše zmíněných událostí. Je tedy nutná podpora IT systému pro vybudování shodné infrastruktury ve vzdálené lokalitě. Zajímavou možností pro DR je poskytování omezených služeb v rámci DR lokality, např. služby pro čtení dat.

65

3.4.

Správa běžících transakcí

Jedním ze základních požadavků na databázový systém je udržení konzistence dat. Tento požadavek je zajištěn pomocí databázových transakcí. V případě vysoce dostupného řešení je každá jednotlivá transakce zpracovávána právě jedním serverem. V případě zpracování dlouhých transakcí může v průběhu dojít pádu serveru a tím k narušení konzistence dat. Klíčovou vlastností databázového systému je tedy schopnost každou takovouto transakci korektně dokončit. Většinou dochází k rollbacku poslední nedokončené transakce a opětovnému spuštění na jiném běžícím serveru. V případě nasazení v režimu HA je úlohou ostaních serverů infrastruktury postarat se o dokončení transakce nedostupného serveru.

3.5.

Rozšiřitelnost celkové infrastruktury

Častým problémem při implementaci jakéhokoliv IT systému je odhadnutí potřebného výkonu. Nejenže je to poměrně složitý úkol a celkový výsledek ovlivňuje mnoho faktorů, ale požadavky na jakýkoliv IT systém se v průběhu jeho života mění a většinou se nároky zvyšují. Proto je klíčovou vlastností každého IT systému jeho rozšiřitelnost, neboli škálovatelnost. V případě škálování jde primárně o možnost spustit více procesů poskytované služby a tím zvýšit celkový výkon řešení. V praxi je možné se potkat se dvěma základními typy škálování, a to vertikálním nebo horizontálním. Vertikální škálování znamená změnu parametrů jednoho serveru. Oproti tomu horizontální škálování představuje přidání dalších fyzických serverů do infrastruktury. Na možnost škálování by měl být kladen důraz tehdy, když není možné přesněji odhadnout nutný počáteční výkon řešení, nebo je očekáváno vyšší zatížení systému s výhledem do budoucna.

3.6.

Přístup klienta/aplikace

V době stále se zvyšujích nároků na dostupnost IT systému je klíčová i role přístupů klientských aplikací. Je takřka nemožné provádět v případě výpadku jedné z částí vysoce dostupného řešení rekonfiguraci klientských aplikací. Mezi klienty databázových systémů nepatří jen samotní uživatelé s přímým

66

přístupem do databáze, ale hlavně i další aplikace, které pro svůj běh potřebují data z databáze. Je tedy naprostou nutností zajistit transparentní přístup klientských požadavků k databázi, bez ohledu na to, který ze serverů vysoce dostupného řešení bude požadavek obsluhovat. V ideálním případě by klient neměl poznat, že přistupuje k databázi implementované ve vysoce dostupném prostředí. Přístup by měl být identický jako v případě nasazení na jeden server. V souvislosti s tím je potřeba také zmínit, že klientské aplikace musí být psány s ohledem na možnost jejich nasazení do vysoce dostupného prostředí. I když se výrobci databázových systémů neustále snaží rozdíl mezi klientským přístupem k vysoce dostupnému řešení a k řešení implementovanému na jednom serveru zmenšovat, vývojáři aplikací by měli mít tuto skutečnost na paměti. Každá klientská aplikace musí být např. schopna reagovat na chybové hlášení databázového systému o nedostupnosti služby.

3.7.

Závislost na komponentách třetích stran

Při rozhodování, jaký databázový systém zvolit, mohou hrát významnou roli i dodatečné požadavky na softwarové vybavení pro implementaci vysoce dostupného řešení. Takovým dodatečným požadavkem může být např. clusterware software pro zajištění vysoké dostupnosti služeb systému. Pokud systém nepotřebuje dodatečné komponenty a součástí jeho dodávky jsou všechny potřebné nástroje, je pravděpodobné, že právě tyto nástroje jsou ideálně vyladěny pro konkrétní systém. Dalším významným aspektem je i podpora operačních systémů, na které bude systém nasazen. Většina výrobců podporuje všechny nejčastěji používané operační systémy, ale existují i určité výjimky, které by mohly být v rozporu s IT strategií společnosti.

3.8.

Složitost a robustnost celkového řešení

Posledním porovnávaným kritériem je celková náročnost na impementaci řešení. Jedná se zejména o hardwarové nároky na infrastrukturu. Každý systém umožňuje různé způsoby implementace, které mohou ovlivnit celkovou robustnost řešení. Celková odolnost prostředí vůči okolním vlivům bude zcela jistě hrát významnou roli při výběru systému.

67

4.

Vlastní srovnání

Tato kapitola poskytuje srovnání jednotlivých databázových systémů z pohledu funkcionalit pro řešení vysoké dostupnosti. Jednotlivé parametry srovnání jsou blíže popsány v předcházející kapitole. Vzhledem k tomu, že některé databázové systémy jsou dostupné v různých edicích, které disponují rozlišnými možnostmi řešení vysoké dostupnosti, jsou tyto edice ve srovnání uvedeny odděleně. Pro lepší přehlednost je celkové srovnání rozděleno do více tabulek. Každá tabulka reprezentuje jedno srovnávací kritérium.

68

Tabulka 3: Srovnání Active/Active versus Active/Passive

Databázový Popis systém Oracle 12c

Oracle

RAC

nabízí

implementaci

clusteru

v režimu

Active/Active. Všechny servery clusteru využívají sdílené diskové úložiště spravované nástrojem Advanced storage management (ASM) od společnosti Oracle. Tento nástroj poskytuje i možnost zrcadlení dat. IBM

DB2 Implementováno v režimu Active/Passive. Pro implementaci

10.5 HADR

v režimu Active/Active je potřebný další nástroj pro clustering. Data jsou v režimu Active/Passive přenášena na separátní diskové úložiště.

IBM

DB2 Řešení umožňuje implementaci v režimu Active/Active se

10.5

sdíleným diskovým úložištěm.

pureScale Microsoft

Tato varianta umožňuje implementace v režimu Active/Passive

SQL server se sdíleným diskovým úložištěm. 2012 MySQL

Řešení funguje v režimu Active/Passive. Každý server tohoto

server 5.6

řešení spravuje vlastní diskové úložiště.

MySQL

Jedná se o takzvaný cluster in-memory v režimu shared-nothing.

cluster NDB Pracuje režimu Active/Active. Data jsou spravována separátním 7.3

serverem, data node. Pro zajištění redundance dat je možné stejná data spravovat více data nody. Zdroj: Vlastní zpracování

69

Tabulka 4: Srovnání stanby systémy

Databázový Popis systém Oracle 12c

Možnost implementace tzv. Cold cluster failover. Všechny databázové služby běží na primárním stroji a v případě jeho výpadku

je

nastartován

záložní

server,

který

přebírá

funkcionalitu prímárního serveru. IBM

DB2 Možnost řešení pomocí funkcionality suspended I/O and online

10.5 HADR

split mirror. Data jsou zrcadlena na standby systém v určitých časových intervalech.

IBM

DB2 Poskytuje stejné možnosti jako IBM DB2 HADR.

10.5 pureScale Microsoft

Funkcionalita log shipping transportuje transakční logy na

SQL server sekundární, neboli standby server. Tento server může být 2012

kdykoliv

nastartován

s daty

dostupnými

dle

posledního

transportu transakčních logů. MySQL

Funkce time-delayed umožňuje replikaci dat v časových

server 5.6

intervalech. Kterýkoliv ze slave serverů je možné využít jako standby systém.

MySQL

Poskytuje stejné možnosti jako mySQL server.

cluster NDB 7.3 Zdroj: Vlastní zpracování

70

Tabulka 5: Srovnání Disaster Recovery

Databázový Popis systém Oracle 12c

O disaster recovery se stará komponenta Active Data Guard. Tato služba umožňuje vybudování standby databáze ve vzdálené lokalitě a zajišťuje nulovou ztrátu dat po přepnutí. DR strana poskytuje svá data pro operace typu čtení.

IBM

DB2 Možnost implementace až tří replik databáze, a to jak ve stejné,

10.5 HADR

tak i ve vzdálené lokalitě. Repliky databází mohou být použity pro čtecí operace.

IBM

DB2 Od verze DB2 10.5 je možné využít obdobných možností, jaké

10.5

poskytuje IBM DB2 HADR, včetně replikace do vzdálených

pureScale

lokalit.

Microsoft

Možnost disater recovery zajišťuje funkcionalita availability

SQL server group. Sekundární servery mohou poskytovat služby pro čtení 2012

dat z databáze.

MySQL

Využívá možnosti replikace dat na vzdálené servery. Replikaci

server 5.6

dat je možné zapnout až na úroveň konktrétní tabulky a tím zajistit replikaci různých dat do jiných lokalit. Slave servery nemusí být neustále připojeny k primárnímu serveru, je možné provádět replikace na velké vzdálenosti i po méně kvalitních linkách.

MySQL

Poskytuje stejné možnosti jako mySQL replikace.

cluster NDB 7.3 Zdroj: Vlastní zpracování

71

Tabulka 6: Srovnání správy běžících transakcí

Databázový Popis systém Oracle 12c

Správa transakcí je zajištěna funkcí Transparent Application Failover (TAF). Umožňuje pokračovat v operacích typu select na jiném node clusteru. V případě transakcí měnících data v databázi provede rollback a informuje o této události klienta. Nástrojem pro podporu dlouhých databázových procedur je Transaction Guard. Na základě logical transaction ID (LTXID) je možné zajistit výstup z posledního provedeného commitu do databáze.

IBM

DB2 V případě přechodu do záložní lokality jsou aplikována data

10.5 HADR

z dostupných transakčních logů. Záleží na volbě synchronizace transakčních logů mezi primární a sekundární stranou. Pro případné nedokončené transkace je proveden rollback.

IBM

DB2 O správu transakcí se stará speciální člen clusteru, tzv. Cluster

10.5

caching facilities. Tento node je zodpovědný za dokončení

pureScale

rozběhnutých transakcí a případný rollback nedokončených transakcí.

Microsoft

V případě, že nedojde k chybě hardware, jsou všechna

SQL server transakční data zapsána z paměti serveru na disk. Nově spuštěný 2012

server se následně postará o commit transakcí, popř. rollback nedokončených transakcí.

MySQL

Global Transaction Identifier (GTID) jednoznačně identifikuje

server 5.6

transakce na úrovní každého serveru. V případě failover je možné využít slave server s nejaktuálnějšími daty. Transakční data jsou následně zajišťována novým primárním serverem.

MySQL

Všechny commitované transakce jsou v synchronním režimu

cluster NDB z paměti serveru ukládány na disk všech data nodů spravujících 7.3

konkrétní data. Zdroj: Vlastní zpracování

72

Tabulka 7: Srovnání rozšiřitelnosti celkové infrastruktury

Databázový Popis systém Oracle 12c

Oracle RAC je možné rozšiřovat o další servery v rámci RAC infrastruktury. Umožňuje rozšiřování diskové kapacity bez nutnosti vypnutí databáze díky ASM.

IBM

DB2 Umožňuje

10.5 HADR

pouze

omezenou

možnost

rozšíření

celé

infrastruktury maximálně o tři servery s replikou databáze. V této architektuře má každý server svůj vlastní diskový prostor s kompletní databází.

IBM

DB2 Cluster umožňuje rozšíření o servery poskytující jak služby

10.5

Cluster caching facilities, tak i DB2.

pureScale Microsoft

Umožňuje škálování prostřednictvím správy různých databází

SQL server různými servery. Problémem je nemožnost poskytování služeb 2012

jedné databázi více servery.

MySQL

Umožňuje rozšířit infrastrukturu o další slave servery pro

server 5.6

replikaci dat.

MySQL

Infrastruktura je rozšiřitelná o další servery, a to jak o SQL nody

cluster NDB pro obsluhu klientských požadavků, tak o data nody pro správu 7.3

dat. Zdroj: Vlastní zpracování

73

Tabulka 8: Srovnání přístupu klienta/aplikace

Databázový Popis systém Oracle 12c

Pro

přístup

vlastních

klientů

k databázi

je

použito

jednoznačného identifikátoru celého RAC clusteru za využití Single Client Access Name (SCAN). Tento jednoznačný identifikátor je platný pro celou infrastrukturu, bez ohledu na vnitřní konfiguraci RAC. V případě výpadku jakéhokoliv serveru, jsou požadavky klientů automaticky přesměrovány na jiné dostupné servery. IBM

DB2 Využívá Automatic client reroute (ACR) se seznamem

10.5 HADR

sekundárních serverů pro přesměrování požadavků klienta v případě pádu primárního serveru.

IBM

DB2 Poskytuje stejné možnosti jako IBM DB2 HADR.

10.5 pureScale Microsoft

V rámci Microsoft clusteru je provozována služba virtual IP a

SQL server hostname. Toto virtuální jméno používají klienti pro přístup 2012

k databázi.

MySQL

Vyžaduje manuální rekonfiguraci klientů, nebo manuální zásah

server 5.6

na úrovni DNS.

MySQL

Přístup klientských aplikací podporuje transparentní load-

cluster NDB balancing i failover. 7.3 Zdroj: Vlastní zpracování

74

Tabulka 9: Srovnání závislosti na komponentách třetích stran

Databázový Popis systém Oracle 12c

Podporuje využití jiných clusterware software, nicméně je doporučováno využítí nástrojů dodávaných výrobcem, jako je Oracle clusterware a Oracle ASM. Implementace tohoto řešení je podporována na všech typických serverových operačních systémech.

IBM

DB2 Ve své základní variantě Active/Passive nepotřebuje žádný další

10.5 HADR

software třetích stran. Při implementaci v režimu Active/Active je nutno implementovat clusterware, nebo využít IBM PowerHA. Ten je ale dostupný pouze pro operační systém AIX. Podpora DB2 HADR existuje pro všechny standardní serverové operační systémy.

IBM

DB2 Tento systém je možné implementovat bez jakýchkoliv dalších

10.5

nástrojů třetích stran. Existuje podpora pouze pro operační

pureScale

systémy typu Linux a AIX.

Microsoft

Využívá clusterware software od společnosti Microsoft a je

SQL server podporován pouze operačním systémem Windows. 2012 MySQL

Není závislý na produktech třetích stran. Toto řešení podporuje

server 5.6

všechny standardní serverové operační systémy

MySQL

Není závislý na produktech třetích stran. Toto řešení podporuje

cluster NDB všechny standardní serverové operační systémy 7.3 Zdroj: Vlastní zpracování

75

Tabulka 10: Srovnání složitosti a robustnosti celkového řešení

Databázový Popis systém Oracle 12c

Řešení odolné vůči výpadku jednoho i více serverů (riziko sníženého výkonu). Velký důraz je kladen na vnitřní síť clusteru interconnect. Prostřednictvím server pool je možné rozdělovat zátěž dle priorit.

IBM

DB2 Řešení poskytuje vysokou robustnost z pohledu odděleného HW

10.5 HADR

pro jednotlivé servery infrastruktury, včetně diskového prostoru. Značné nároky jsou kladeny na síťovou konektivitu mezi primární a sekundární lokalitou.

IBM

DB2 Velice robustní řešení, jehož funkcionalitu neohrozí ani výpadek

10.5

více serverů. Náročné řešení na celkový počet serverů

pureScale

infrastruktury, jejich paměť a na stabilitu vnítřní sítě interconnect.

Microsoft

Umožňuje

implementovat

až

64

serverů

do

celkové

SQL server infrastruktury. Řešení umožňuje distribuci různých databází na 2012

různé servery, což zvyšuje celkový výkon. Velké nároky jsou kladeny na spolehlivost sítě interconnect.

MySQL

Celkovou infrastrukturu tvoří několik nezávislých serverů

server 5.6

zvyšujicích robustnost řešení. Pro úspěšnou replikaci dat není podmínkou kvalitní síťové připojení.

MySQL

Velice robustní řešení odolné nejen proti výpadku serveru pro

cluster NDB databázové služby ale i správu dat. Vzhledem ke své robustnosti 7.3

je náročné na počet serverů infrastruktury a vnitřní síťovou komunikaci mezi nimi.

In-memory cluster má vysoké

požadavky na paměť serveru. Zdroj: Vlastní zpracování

76

5.

Vyhodnocení jednotlivých řešení, doporučení

Z celkového popisu plyne, že každý databázový systém se snaží o řešení všech klíčových problémů vysoce dostupného řešení. Např. co do přístupu klientů nebo správy transakcí má každý databázový systém svá vlastní řešení těchto problémů. Rozdíl v jednotlivých databázových systémech se dá tedy spíše nalézt v rozšiřitelnosti, robustnosti a podpoře jejich nasazení pro různé platformy. Jistou jedinečnost v tomto hodnocení představuje databázový systém mySQL se svojí vlastností database sharding. Obdobnou funkcionalitu poskytuje i databázový partitioning dostupný ve všech ostatních databázových systémech. Hlavní rozdíl je v tom, že partitioning je spracováván jednou instancí serveru, kdežto sharding může spravovat více serverů. Pomocí shardingu je možné zvýšit nejen dostupnost celkového řešení, ale i jeho výkon, a to rozložením tabulek přes více serverů. Další ojedinělou funkcionalitou popisovaných databázových systémů je využití přímého vzdáleného přístupu do paměti serveru v clusteru řešení IBM DB2 pureScale. Tato funkcionalita primárně zvyšuje výkon celého řešení a to vzhledem k její nižší závislosti na diskových I/O operacích. Po shrnutí všech popsaných skutečností se jako nejideálnější řešení pro zajištění vysoké dostupnosti klíčových databázových systémů jeví produkt společnosti Oracle. Tento databázový systém nabízí vytvoření redundantního a vysoce dostupného řešení za pomoci poměrně malé hardwarové infrastruktury. Toto řešení umožňuje v případě potřeby jednoduché rozšíření o další plnohodnotné aktivní prvky. Další výhodou je možnost implementace na takřka libovolném operačním systému, což může být často limitující faktor s ohledem na IT strategii společnosti. Databázový systém od společnosti Oracle bude vhodnou volbou při požadavku na maximální dostupnost databáze, celkovou jednoduchost nasazení a vlastní správy. V rámci produktu od společnosti Oracle jsou dodávány další užitečné nástroje pro podporu zálohování a disaster recovery. Pro náročné aplikace je vhodným řešením produkt společnosti IBM, a to konkrétně IBM DB2 pureScale. Oproti předchozímu řešení nabízí mnohem větší robustnost, která ovšem přináší značné nároky na hardwarovou

77

infrastrukturu celého řešení. Nároky na harwarovou infrastrukturu mohou sehrát ještě větší roli v případě potřeby disaster recovery prostředí, které přináší velice výkonné a snadno rozšiřitelné řešení pro kritické databázové systémy. IBM DB2 pureScale je vhodné pro kritické a na výkon velice náročné aplikace. Jistou nevýhodou tohoto řešení je omezená podpora operačních systémů pro implementaci IBM DB2 pureScale. Jistým průnikem dvou přechozích řešení je mySQL cluster, disponující vysokou mírou robustnosti a v případě potřeby i možností rozšíření. Hlavním rozdílem oproti předchozím dvěma systémům je možnost zajištění vysoké dostupnosti a zároveň redundance dat bez nutnosti implementace často nákladných nástrojů pro zrcadlení dat. MySQL cluster se jeví jako ideální řešení pro nasazení v distribuovaném a geograficky odděleném prostředí. Produktem s nejnižší podporou vysoké dostupnosti je databázový systém Microsoft SQL server. Ten v rámci své nativní implementace nepodporuje plnohodnotné řešení Active/Active. Tento databázový systém nabízí možnost nasazení v distribuovaném prostředí, ale při případné potřebě zvýšení výkonu pro konkrétní databázi bude narážet na své architektonické limity. Tento systém se jeví vhodný pro nasazení v prostředí, které vyžaduje jistou míru dostupnosti bez extrémních nároků na výkon.

78

6.

Závěr

Hlavním cílem této bakalářské práce bylo srovnat vybrané databázové systémy s ohledem na možnosti, které poskytují pro nasazení v režimu vysoké dostupnosti. Z celkového popisu plyne, že každý výrobce poskytuje více možností jak tuto problematiku řešit. Je vždy otázka vlastních požadavků na konkrétní systém, který databázový systém bude nejvýhodnější. Největší roli bude samozřejmě hrát způsob řešení implementace vysoce dostupného systému, ale určitý ohled bude brán např. i na úlohu administrátorů. V ideálním případě bude vybrán systém, který pro zajištění vysoké dostupnosti nepožaduje součinnost administrátora systému, ale v některých případech nemusí být nutnost manuálního zásahu překážkou. Z popisu jednotlivých možností různých databázových systému je zřejmé, že vysoká dostupnost se prolíná i s dalšími aspekty správy IT systému jako je např. zálohování a patchování systémů. Pro pochopení co to vlastně vysoce dostupný systém je, byly v úvodní části této práce popsány největší úskalí na které je potřeba brát zřetel při implementaci takovéhoto systému. Vysoce dostupný systém neznamená pouhé zdvojení všech komponent, ale je potřeba brát ohled na práci s daty, přístupu klientských aplikací, nebo práce s transakcemi. V hlavní části této práce byly popsány možnosti vybraných databázových systému. Každý z výrobců poskytuje nejen možnosti pro implementaci ve vysoce dostupném prostředí, ale i možnost replikace dat a řešení disaster recovery. V následující části byly jednotlivé systémuy srovnány a to nejen s ohledem na vysokou dostupnost, ale i na celkovou robustnost, rozšiřitelnost nebo náročnost na implementaci. U žádného z popisovaných systému nelze jednoznačně určit, že právě ten je nejlepší. Vždy je potřeba brát ohled na konkrétní případ nasazení. Z dostupných informací plyne, že nejvhodnějším kandidátem pro vysoce dostupný databázový systém z pohledu jednoduchosti nasazení a správy je produkt od společnosti Oracle. V případě vysokých požadavků na robustnost celého řešení je jednoznačným vítězem produkt IBM DB2 pureScale. Trochu

79

překvapivé bylo zjištění u databázového systému mySQL, který za poslední roky učinil velký pokrok v řešení vysoce dostupného systému a ve své verzi mySQL cluster NDB poskytuje plnohodnotné řešení s vysokou mírou robustnosti a možnosti dalšího rozšíření.

80

7.

Seznam použité literatury

EVAN, Marcus, STERN Hal: Blueprints for High Availability. Second edition. Indianapolis, Indiana: Wiley Publishing, 2003. 618 s. ISBN: 0-471-43026-9 BELL, Charles, KINDAHL, Mats, THALMANN Lars: MySQL High Availability. First edition. Sebastopol, CA: O’Reilly Media, Inc., 2010. 624 s. ISBN: 978-0-596-80730-6

Internetové zdroje

BARTOWSKI, Stanislaw, DE BUITLEAR Ciaran, KALICKI, Adrian, LOSTER, Michael, MARCZEWSKI, Marcin, MOSSAD, Anas, NELKEN, Jan, SOLIMAN, Mohamed, SUBTIL, Klaus, VRHONIK, Marko, ZIMNOL, Karol: High Availability and Disaster Recovery Options for DB2 for Linux, UNIX, and Windows[online]. Armonk, NY: IBM, Redbooks publication, 2012. 584

s

(PDF).

[cit.

2014-02-15].

Dostupný

z URL:

<

http://www.redbooks.ibm.com/abstracts/sg247363.html?Open >. PEDREGAL MARTIN, Cris: Maximize Availability with Oracle Database 12c[online]. Redwood Shores, CA: Oracle Corporation, 2013. 28 s (PDF). [cit. 2014-02-15].

Dostupný

z URL:

. MICHALEWICZ, Markus: Oracle Real Application Clusters (RAC)[online]. Redwood Shores, CA: Oracle Corporation, 2013. 23 s (PDF). [cit. 2014-0215].

Dostupný

z URL:

<

http://www.oracle.com/technetwork/database/options/clustering/rac-wp-12c1896129.pdf>. LEROY Tuttle, Microsoft SQL Server AlwaysOn Solutions Guide for High Availability and Disaster Recovery[online]. Microsoft, 2012. 33 s (DOC). [cit. 2014-02-15].

Dostupný

z URL:


us/library/hh781257.aspx>. Oracle HA Product Management: Technical Comparison Oracle Database 12c vs. IBM DB2 10.5: Focus on High Availability [online]. Redwood Shores, CA:

81

Oracle Corporation, 2013. 62 s (PDF). [cit. 2014-02-15]. Dostupný z URL: < http://www.oracle.com/technetwork/database/availability/cwp-ha-oracle12cdb2-10-5-2043457.pdf>. Oracle HA Product Management: Technical Comparison of Oracle Database 12c vs. Microsoft SQL Server 2012 Focus on High Availability [online]. Redwood Shores, CA: Oracle Corporation, 2013. 68 s (PDF). [cit. 2014-0215].

Dostupný

z URL:

<

http://www.oracle.com/technetwork/database/availability/ha-oracle12csqlserver2012-2049933.pdf>. Oracle Active Data Guard Real-Time Data Protection and Availability [online]. Redwood Shores, CA: Oracle Corporation, 2013. 23 s (PDF). [cit. 2014-0330].

Dostupný

z URL:

<

http://www.oracle.com/technetwork/database/availability/active-data-guardwp-12c-1896127.pdf>. Continuous Availability with the IBM DB2 pureScale Feature [online]. IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099 2455 South Road Poughkeepsie, NY 12601-5400 U.S.A., 2012. 9 s

(PDF).

[cit.

2014-03-30].

Dostupný

z URL:

<

http://www.redbooks.ibm.com/technotes/tips0926.pdf>. DB2 pureScale Feature: Workload balancing, automatic client reroute, and client affinities concepts and administration [online]. IBM Canada 8200 Warden Avenue Markham, ONL6G 1C7 Canada, 2013. 43 s (PDF). [cit. 201403-30].

Dostupný

z URL:

<

http://www.redbooks.ibm.com/technotes/tips0926.pdf>. Transparent application scaling with IBM DB2 [online]. IBM Corporation Software Group Route 100 Somers, NY 10589, 2013. 8 s (PDF). [cit. 2014-0330].

Dostupný

z URL:

<

http://public.dhe.ibm.com/common/ssi/ecm/en/imw14253usen/IMW14253USE N.PDF>. Guide to Scaling Web Databases with MySQL Cluster [online]. Oracle Corporation, 2013. 18 s (PDF). [cit. 2014-03-30]. Dostupný z URL: < http://www.mysql.com/content/download/id/277>.

82

Oracle VM Template for MySQL Enterprise Edition [online]. Oracle Corporation, 2011. 15 s (PDF). [cit. 2014-03-30]. Dostupný z URL: < http://www.mysql.com/content/download/id/276/>. MySQL 5.6 Replication [online]. Oracle Corporation, 2014. 27 s (PDF). [cit. 2014-03-30].

Dostupný

http://www.mysql.com/content/download/id/371/>.

83

z URL:

<

8.

Seznam použitých zkratek

Zkratka

Popis

IT

Obor informačních technologií.

IBM

International Business Machine

SaaS

Software as a Service. Služba nebo aplikace poskytovaná v rámci cloud řešení.

DBMS

Database

management

systém,

software pro správu databází. SQL

Structured query language

TCO

Total

cost

of

ownership

neboli

celkové náklady vlastnictví. HW

Hardware, komponenta serveru, nebo celý server.

SW

Software, aplikace běžící na počítači.

SpoF

Single point of failure, jedinečné místo

v infrastruktuře,

při

jehož

výpadku je nedostupný celý systém. URL

Unikátní odkaz do dokumentů na internetu.

RAID

Redundant array of independent disks, soubor separátních disků zajišťující redundanci disků v poli.

SAN

Storage area network, speciální síť zajišťující serveru přístup k diskovým polím.

DNS

Domain name server, komponenta starající se o překlad jmen serverů na jejich unikátní adresu.

MTBF

Mean time between failure, střední doba mezi poruchami systému.

MTTR

Mean time to repair, střední doba pro

84

opravu poruchy. SLA

Service level agreement, smlouva mezi poskytovatelem služby a jeho klientem.

RTO

Recovery time objective, maximální čas pro obnovu systému po výpadku.

RPO

Recovery point objective, maximální čas, po který je možné přijít o data v případě výpadku systému.

DR

Disaster recovery, proces obnovy systému po totální havárii.

ACID

Zkratka

vlastností

databázové

transkace

Atomicity,

Consistency,

Isolation a Durability API

Application Programming Interface označuje rozhraní pro programování klientských aplikací.

RAC

Oracle Real Application Cluster je proprietární technologií společnosti Oracle

pro

dostupnosti

podporu jejich

vysoké

databázových

systémů. OCW

Oracle

clusterware

společnosti

je

Oracle

produkt umožňující

sdružení více serveru do jednoho celku poskytující konkrétní aplikaci. MAA

Oracle

Maximum

Availability

Architecture ASM

Automatic Storage Management

OCR

Oracle Cluster Registry

GNS

Grid Naming Service

IP

Internet protocol

SCAN

Single Client Access Name

85

SPFILE

Shared server parameter file

TAF

Transaprent Application Failover

LTXID

Logical Transaction ID

RAW

Speciální

typ

blokového

zařízení

umožňující přímý přístup k pevnému disku. I/O

Input/Output nebo-li vstupně výstupní operace.

HADR

High Availability Disaster Recovery

ACR

Automatic client reroute

CF

Cluster caching facilities

GPFS

General parallel file system

RDMA

Remote direct memory access

WSFC

Windows server failover clustering

FCI

Failover Cluster Instance

GPL

General public license, neboli veřejná licence.

LAMP

Linux, Apache, MySQL a PHP. Sada volně

stažitelného

software

pro

implementaci webových stránek. GTID

Global Transaction Identifiers

NDB

Network database

JDBC

Java database connectivity

VM

Virtiual machine

DRBD

Distributed Replicated Bloc Device

86

9.

Seznam obrázků

Obrázek 1: Cena výpadku aplikace za jednu minutu

13

Obrázek 2: Třívrstvá architektura

14

Obrázek 3: Redundance komponent v režimu vysoké dostupnosti

14

Obrázek 4: Řešení disaster recovery

19

Obrázek 5: DR plán

20

Obrázek 6: Oracle Real Application Cluster

26

Obrázek 7: Oracle clusterware

27

Obrázek 8: Load balancing připojení pomocí SCAN

29

Obrázek 9: Oracle ASM

29

Obrázek 10: Oracle RAC s využitím ASM

30

Obrázek 11: Oracle Flex ASM

31

Obrázek 12: Oracle Data Guard

34

Obrázek 13: IBM DB2 Log shipping

38

Obrázek 14: IBM DB2 Automatic client reroute

40

Obrázek 15: DB2 HADR synchronizační módy

42

Obrázek 16: IBM DB2 pureScale cluster member

43

Obrázek 17: Doporučená architektura IBM DB2 pureScale

45

Obrázek 18: SQL server Active/Passive cluster

47

Obrázek 19: SQL AlwaysOn availability group

51

Obrázek 20: SQL database mirroring cuncurent session

54

Obrázek 21: SQL server log shipping

54

Obrázek 22: mySQL replication

56

Obrázek 23: mySQL cluster

59

Obrázek 24: mySQL cluster dataNode

60

Obrázek 25: mySQL database sharding

61

Obrázek 26: Oracle VM

61

Obrázek 27: MySQL, DRBD,Pacemaker,Corosync

63

87

10.

Seznam tabulek

Tabulka 1: Časová dostupnost systému v jednotlivých kategorií „devítek“

18

Tabulka 2: Úroveň chyby pro failover SQL serveru

50

Tabulka 3: Srovnání Active/Active versus Active/Passive

69

Tabulka 4: Srovnání stanby systémy

70

Tabulka 5: Srovnání Disaster Recovery

71

Tabulka 6: Srovnání správy běžících transakcí

72

Tabulka 7: Srovnání rozšiřitelnosti celkové infrastruktury

73

Tabulka 8: Srovnání přístupu klienta/aplikace

74

Tabulka 9: Srovnání závislosti na komponentách třetích stran

75

Tabulka 10: Srovnání složitosti a robustnosti celkového řešení

76

88