Řešení vysoké dostupnosti databází

Transkript

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
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
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
•
failover
•
SQL
failover
je
v případě,
že
proveden
server
je
zastavený.
2
v případě,
je
kdy
proveden
server
nepřijme žádná data)
•
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“
•
failover
proveden
•
v případě chyb na serveru
•
je
nižší kategorie.
vrátí
stav
vrátí
stav
„system error“
•
„resource error“
5
•
failover
proveden
•
v případě jakékoliv chyby
•
je
na serveru.
vrátí
stav
vrátí
stav
vrátí
stav
„system error“
•
„resource error“
•
„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.
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
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
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.
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.
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
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
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.
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:
<http://www.oracle.com/technetwork/database/availability/maximumavailability-wp-12c-1896116.pdf>.
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:
<http://msdn.microsoft.com/en-
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].
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].
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

Řešení vysoké dostupnosti databází

Transkript

Podobné dokumenty

Plán školení Česká republika

Poznámky k vydání

PostgreSQL návrh a implementace náročných databázových aplikací

Priorita 5/2016 - Státní fond životního prostředí

Studie proveditelnosti

Osnovy předmětů

SOA nástroje pro Cloud_Computing

Automatic Storage Management (ASM)

CZ pro web

Prezentace aplikace PowerPoint

Big Data Technical Overview

ITerační VýVOj V PraXI

ÚVOD, KLASIFIKACE

UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE Efektivní datové

NoSQL databáze

KATALOG :

zvláštní neprodejná příloha | duben 2015

Šlechtitel - BŘEZEN 2008

databázový server firebird instalace,konfigurace

Z OBSAHU: - Notářská komora České republiky

ricoh mp cw2200sp

Diplomová práce