Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování
Ochrana dat Oracle databázového stroje Bakalářská práce
Autor:
Luděk Holý Informační technologie
Vedoucí práce:
Praha
Ing. Vladimír Beneš
Duben, 2010
Prohlášení:
Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a s použitím uvedené literatury.
V Praze, dne 9. 4. 2010
Luděk Holý
Anotace Bakalářská práce je zpracovaná na téma ochrany dat Oracle databázového serveru a má poskytnout ucelený přehled o možnostech ochrany databázových dat, mapuje různé zálohovací režimy Oracle databází a používané technologie sloužící k zajištění vyšší bezpečnosti uložení dat. V první části popisuji typy databázových záloh, v druhé hardwarové zálohovací zařízení na trhu, ve třetí možné režimy záloh. Ve čtvrté představím další vhodné možnosti ochrany dat a v závěrečné části zhodnotím popsané možnosti zálohování. Tato práce si neklade za cíl popsat ochranu dat na databázové úrovni ve smyslu bezpečnostních politik. Cílem práce je nalezení vhodných variant zálohování, ať již v oblasti zálohovacích strategií, tak i v použití jednotlivých zálohovacích systémů.
Annotation The theme of the Bachelor Thesis is data protection of the Oracle database server and it provides a comprehensive outline of the possibilities of protecting database data, it maps various backup regimes of Oracle databases and the technologies in use ensuring higher security of data storing. The first part describes the types of database backups, the second deals with hardware backup devices available in the market, and the third shows the possible backup regimes. The fourth part presents other suitable options of data protection and the final part evaluates the described possibilities of backup. This Thesis does not aim to describe data protection at the database level within the meaning of security policies. The paper aims to find suitable variants of backup, both in terms of backup strategies and of using the particular backup systems.
Obsah Úvod ...................................................................................................................................... 5 1 Možnosti zálohování .................................................................................................... 6 1.1 Dělení podle způsobu přístupu k datům databáze ................................................. 6 1.1.1 Logické zálohování........................................................................................ 6 1.1.2 Fyzické zálohování ........................................................................................ 6 1.2 Dělení podle režimu databáze................................................................................ 6 1.2.1 Offline zálohování ......................................................................................... 7 1.2.2 Online zálohování .......................................................................................... 7 1.3 Dělení podle způsobu uložení dat.......................................................................... 7 1.3.1 Souborový systém ......................................................................................... 7 1.3.2 Optické datové nosiče.................................................................................... 8 1.3.3 Magnetická pásková média ........................................................................... 8 1.4 Dělení podle použitého software ........................................................................... 9 1.4.1 Export a Import.............................................................................................. 9 1.4.2 Datová pumpa ................................................................................................ 9 1.4.3 Fyzická záloha datových souborů databáze................................................. 10 1.4.4 Recovery Manager....................................................................................... 11 2 Hardwarová zálohovací řešení ................................................................................. 14 2.1 HP Data Protector ................................................................................................ 16 2.2 HP Archive Backup System for OpenVMS ........................................................ 19 2.3 EMC NetWorker ................................................................................................. 20 2.4 IBM Tivoli Storage Manager .............................................................................. 23 2.5 Symantec Veritas NetBackup .............................................................................. 24 2.6 Oracle Secure Backup ......................................................................................... 26 3 Výběr vhodného režimu zálohování ........................................................................ 28 3.1 Úplná záloha databáze ......................................................................................... 30 3.2 Přírůstková záloha databáze ................................................................................ 30 3.3 Přírůstkově aktualizované zálohy ........................................................................ 34 3.4 Záloha databáze za využití parametru skip readonly........................................... 35 3.5 Záloha databáze za využití klonovacích technologií ........................................... 35 4 Další možnosti ochrany dat....................................................................................... 38 4.1 Cluster.................................................................................................................. 38 4.2 Cold/hot failover .................................................................................................. 40 4.3 Real Application Cluster ..................................................................................... 41 4.4 Oracle Data Guard ............................................................................................... 42 4.5 RAID ................................................................................................................... 44 4.6 Archivace dat ....................................................................................................... 46 5 Vyhodnocení popisovaných možnosti ...................................................................... 48 Závěr ................................................................................................................................... 53 Seznam použité literatury ................................................................................................. 54 Definice, akronymy a zkratky .......................................................................................... 55
Úvod Ve své bakalářské práci se zaměřím na možnosti, jak lze chránit databázová data. V dnešním světě se téměř žádná organizace neobejde bez použití informačních technologií. Pokud daná organizace zpracovává a uchovává jakákoliv data v elektronické podobě, nejčastěji si jako vlastní úložiště dat volí databázový systém. Podle svých potřeb si především vybírá z komerčních databázových produktů firem Oracle, Microsoft, IBM a dalších, případně si může pro uchování svých dat zvolit open source databázové produkty, například databázový produkt MySQL. Pracovníci odpovědní za rozvoj, správu a provoz IT musí nejpozději v době implementace nového informačního systému zvolit způsob ochrany a zálohování dat databázového systému, neboť jejich případná ztráta může fatálně poškodit provoz organizace citelnými finančními ztrátami a právními následky plynoucími z nesplněných závazků a povinností vůči obchodním partnerům a státním institucím a nezvratně tak poškodit důvěryhodnost firmy v očích jejích partnerů. V závislosti na povaze, provozním režimu a důležitosti informačního systému je nutné rozhodnout, jaký typ zálohování bude použit a na jaké záznamové medium bude vlastní záloha ukládána. Je nutné zvolit kompromis mezi důležitosti uchovávaných dat, rychlostí zálohy a případné obnovy a cenou zálohovacího systému. Výsledná volba je dále omezena dostupností zálohovacího systému na konkrétní hardwarové a softwarové platformě a možnostmi dalšího možného využití v organizaci, neboť nabízená hardwarová řešení zpravidla poskytují komplexní služby v oblasti zálohování i archivace celého podniku a neomezují se pouze na problematiku zálohování databází. Ve své práci se zaměřím na databázový systém firmy Oracle ve verzi 10g a postupně představím jednotlivé možnosti zálohování dat, dále popíši existující hardwarová zálohovací řešení, možné režimy zálohování a zmíním i další možné prostředky k zajištění vyšší bezpečnosti. Součástí práce je i kapitola vyhodnocení popisovaných možností, ve které se soustředím na výběr optimálního řešení zálohování databázového stroje v závislosti na požadavcích na finanční náročnost, rychlost a ochranu dat.
5
1 Možnosti zálohování Pro zálohování databázového systému můžeme zvolit různé programy, zálohovat můžeme v různých provozních režimech a zazálohovaná data lze uložit na různá zařízení. Zálohování lze dělit i na fyzické, které zahrnuje vlastní zálohu fyzických souborů databáze, a na logické, při kterém se čtou logické struktury databáze a ukládají se do fyzického souboru.
1.1 Dělení podle způsobu přístupu k datům databáze 1.1.1
Logické zálohování
Logickou zálohou nazýváme způsob vytvoření zálohy, během které program čte logické struktury databáze a následně je ukládá do souboru na zálohovací zařízení. Podmínkou pro online zálohování je databáze ve stavu open a přístup do datového slovníku. Pro logickou zálohu databáze lze využít utility Oracle Export/Import a Oracle Data Pump Export/Import. Za logickou zálohu lze považovat i vyselektování dat do souboru ve strukturované formě, kdy je možné pro případný návrat dat do databáze použít utilitu Oracle SQL Loader. 1.1.2
Fyzické zálohování
Fyzickou zálohou nazýváme způsob vytvoření zálohy, při kterém jsou fyzické soubory přesunuty na zálohovací zařízení v nezměněné podobě nebo uloženy do souboru (saveset, backupset).
Mezi
prostředky
využívající
fyzické
zálohování
patří
kopírovací,
komprimovací a zálohovací prostředky konkrétního operačního systému, softwarové produkty třetích stran, ať již komerční nebo open source. Pro fyzickou zálohu lze samozřejmě využít i utilitu RMAN.
1.2 Dělení podle režimu databáze Metody a použití konkrétních nástrojů pro zálohu databáze závisí na stavu databáze během zálohování. Tyto stavy lze rozdělit na dvě základní skupiny.
6
1.2.1
Offline zálohování
Databáze je zálohována v neaktivním stavu. Je důležité, aby byla databáze uzavřena korektním způsobem, jen za splnění této podmínky je záloha konzistentní. Offline zálohu lze
provést
na
databázi,
která
je
provozována
v režimu
ARCHIVELOG
i NOARCHIVELOG. Vlastní záloha spočívá ve zkopírování datových a řídících souborů, online transakčních žurnálů a konfiguračních souborů databáze na zálohovací zařízení. Je vhodné, ale není to nezbytná podmínka, provést zároveň zálohu databázového software. 1.2.2
Online zálohování
Databáze je během zálohovacího procesu ve stavu open a musí být provozována v režimu ARCHIVELOG. Jedině za splnění těchto podmínek je možné databázi obnovit a aplikací archivních žurnálů(redologů) dostat do konzistentního stavu. Online zálohování vyžaduje po dobu zálohy přepnutí tabulkových prostorů (tablespace) do režimu begin backup a po skončení zálohy přepnutí zpět do režimu end backup. Při použití utility RMAN není nutné během zálohy tabulkové prostory přepínat. Záloha spočívá ve zkopírování datových, řídících souborů databáze a také archivních žurnálů. Většina databází je v dnešní době zálohována pomocí online zálohy buď za pomoci prostředků operačního systému, nebo produktů třetích stran. Stále častěji se využívá utilita RMAN. Velkou výhodou online proti offline zálohování je možnost provádět konzistentní zálohu během provozu databáze, neboť velká část produkčních databází neumožňuje odstavovat databázi kvůli provedení zálohy.
1.3 Dělení podle způsobu uložení dat 1.3.1
Souborový systém
V dnešní době je uložení zálohy databáze do souborového systému (filesystem), ať již do lokálního, nebo sdíleného, nejlevnější variantou. Dnešní diskové systémy dosahují vynikajícího poměru rychlosti, spolehlivosti a také ceny. Zálohy můžeme ukládat jako savesety do souborového systému, ale můžeme využít i různé klonovací techniky na úrovni diskového pole, které vynikají rychlostí zálohování i obnovy databází.
7
1.3.2
Optické datové nosiče
Pro uložení databázové zálohy je možné použít i optické nosiče CD R/RW, DVD +/- R/RW/RAM, HD DVD a Blue-ray . Lze je využít pro jednorázové i opakované zálohy. Často se jedná o jediný způsob, jak za přijatelnou cenu nosiče s databázovými zálohami uskladnit na bezpečném místě. Pro zálohování velkých produkčních databází se ale většinou nepoužívají z důvodu malé kapacity, problematické životnosti záznamu a obtížích při manipulaci s médii. 1.3.3
Magnetická pásková média
Po uložení záloh do souborového systému se jedná o druhou nejčastější variantu. Nejpoužívanější magnetické pásky jsou typu DAT, DLT, SDLT, LTO a existuji v mnoha verzích. Pásková magnetická média lze použít buď v samostatné mechanice připojené k databázovému serveru s manuální obsluhou pásek, nebo častěji v páskovém robotu, což je systém skládající se ze sady páskových mechanik a příslušného poolu pásek, které jsou obsluhovány robotickým ramenem a jehož provoz je plně automatický, což v dnešní době již bývá jeden ze základních požadavků. Tento systém ale může paradoxně komplikovat plnění auditních předpisů, které s tímto režimem (uzavřený pool pásek obsluhovaný roboticky) nepočítají a vyžadují umísťování nahraných záloh do trezorů. Tento požadavek je často obtížně splnitelný. Zálohovací systém (často se používá termín zálohovací knihovna či robot) je dodáván jako balík hardware a software produktů, který zabezpečuje komplexní zálohovací služby včetně držení databáze záloh, automatické expirační politiky, řešení bezpečnosti přístupu k zálohám, clusterová řešení, robustní plánovač a GUI. Tyto systémy bývají ve společnostech využívány jako sdílené zálohovací a archivační řešení, jejich jednotlivé moduly umožňují standardní souborové zálohy a obsahují také zálohovací rozhraní pro různé typy aplikací i databází na několika platformách zároveň, v případě více vláknového napojení na firemní infrastrukturu umožňují souběžné zálohování. Zvláštní požadavek je kladen na kvalitu médií. Tyto zálohovací systémy poskytují pro databázové produkty komunikační softwarovou vrstvu MML (Media Management Layer), kterou využívá databázová utilita RMAN, například produkt IBM Tivoli Storage Manager (TSM), EMC NetWorker (Legato), HP
8
ABS/MDMS. Tyto produkty běžně poskytují MML na více operačních systémech zároveň, je tedy možné souběžně zálohovat Oracle databáze běžící na různých platformách. V oblasti velkých produkčních databází je využití těchto komplexních zálohovacích systémů považováno za preferovaný standard, který splňuje bezpečnostní i kapacitní požadavky a umožňuje plnou automatizaci zálohování. Nevýhodou bývá cena vlastního zálohovacího systému a medií.
1.4 Dělení podle použitého software 1.4.1
Export a Import
Export (exp) je nástroj pro exportování dat z Oracle databáze. Kromě jiných funkcí lze program exp využít pro logické zálohování databáze v režimu FULL, kdy je exportován obsah celé databáze včetně dat a definic databázových objektů. Dále pak v režimu OWNER, kdy jsou exportována data pouze zvoleného uživatele, v režimu TABLESPACE, který umožňuje export dat zvoleného tabulkového prostoru a nakonec v režimu TABLE, kdy se exportuji pouze specifikované tabulky. Párový nástroj programu export se jmenuje import (imp) a slouží k importu dat do databáze. Využívá se v analogických režimech programu export. Oba párové programy umožňují ovlivnit průběh zálohy mnoha parametry. Použití programů exp/imp jako zálohovacího řešení pro celý databázový stroj je problematické, neboť neumožňují plnou obnovu stavu databáze k okamžiku zálohy. Z tohoto důvodu se programy využívají spíše jako prostředek k záloze neprodukčních databází a i toto použití je na ústupu. Často se však z důvodu jednoduchosti a kompatibility využívá k záloze pouze části dat jako součást archivační strategie. V dnešní době je použití programů export a import na ústupu, neboť je ve verzi 10g nahradila nová utilita Datová pumpa. Export a Import není již nadále vyvíjen, ale z důvodu zpětné kompatibility je stále zachována možnost použití i v posledních verzích databáze Oracle 11g. 1.4.2
Datová pumpa
Oracle ve verzi databáze 10g uvedl nový nástroj, který nahrazuje zastaralé programy export/import. Utility Data Pump Export/Import (expdp/impdb) rozšiřují možnosti původních programu export/import, implementují nové funkce v ovládání procesů, v jejich
9
paralelizaci a tím pádem i v podstatném zrychlení exportu a importu dat. Filozofie nových utilit vychází z původních programů exp/imp, má tedy i stejné limity jako původní utility. Neumožňují kompletní obnovu k okamžiku zálohy a jsou tedy nevhodné jako zálohovací řešení produkčních systémů. Často se jich využívá k záloze části dat v rámci archivační strategie. Datové exporty z utilit export/import a Data Pump Export/Import nejsou vzájemně kompatibilní. 1.4.3
Fyzická záloha datových souborů databáze
Zálohování fyzických souboru databáze v online i offline režimu lze provádět prostředky operačního systému nebo komerčními programy ostatních výrobců. Lze použít open source produkty. Dostupnost jednotlivých produktů závisí na použitém operačním systému. Jednotlivé programy se můžou lišit možnostmi nastavení, robustností, implementací GUI, možnostmi plánování úloh, implementací bezpečnostních politik, možnostmi komprese či paralelizací úloh. Nejběžnější je na platformě wintel použití programu copy, pro zálohování lze ale užít celou řadu produktů, například Norton Ghost či Acronis True Image Home. Na unix platformě je možné využít program cp či příkaz tar. Lze také použít klienty produktů TSM, EMC Networker a další dostupné systémy k záloze dat na páskové knihovny. Na platformě OpenVMS je možné k záloze na disk či magnetické pásky kromě příkazu copy využít i příkaz backup. Lze využít i klientskou část zálohovacího systému ABS/MDMS. Ještě v nedávné době byla většina produkčních databází zálohována tímto způsobem. Na jedné straně tento přístup umožňuje administrátorovi maximální kontrolu nad zálohovacím procesem, je v principu jednoduchý a transparentní. Na druhou stranu je poměrně pracný pro administrátora databáze i obsluhu zálohovacího systému, umožňuje pouze menší stupeň automatizace. Není flexibilní, i běžné provozní změny (přidání datových souborů) často vyžadují zásah do provozních skriptů, čímž roste i riziko lidské chyby. Pokud není
10
aplikačně definovaná politika uchovávání záloh (retention politika), je nutné ji komplikovaně vytvořit. A jako fatální problém se postupem doby může jevit délka zálohy. Všechny tyto aspekty generují mnoho činností a nejsou v souladu se současnými trendy snižování provozních nákladů, jak v oblasti administrace systémů, tak i v obsluze datových center. 1.4.4
Recovery Manager
Recovery Manager (RMAN) jakožto nový softwarový nástroj pro zálohu a obnovu Oracle databází byl poprvé představen jako součást databáze Oracle verze 8.0.3. Postupným vývojem se z něj stal komplexní softwarový nástroj, který výrazně přesahuje problematiku zálohy a obnovy databáze. V začátcích často vzbuzoval v administrátorech nejistotu, protože jeho použitím se vzdávali maximální kontroly nad procesem zálohování i obnovy a přenechávali je ve značné míře na aplikační logice programu. RMAN si nicméně své postavení postupně vydobyl a dnes je nejpoužívanějším řešením. Hlavním impulsem opuštění strategie fyzického zálohování v naší organizaci se stala narůstající délka záloh, kdy záloha celé databáze ve dvou vláknech trvala více než 16 hodin. Zavedením utility RMAN klesl čas potřebný k záloze téže databáze ve dvou vláknech na 3 hodiny. Proč tedy použít RMAN: RMAN nezálohuje datové soubory blok po bloku jako v případě tradičního postupu. Naopak zálohy optimalizuje vynecháním nevyužitých bloků, čímž zkracuje dobu zálohy. a zároveň zmenšuje velikost vlastní zálohy. RMAN umožňuje online kompresi záloh. RMAN umožňuje provádět offline i online zálohy (v režimu ARCHIVELOG), nevyžaduje přepínání tabulkových prostorů do begin backup/end backup režimu, čímž snižuje zatížení databáze během zálohování. RMAN umožňuje během zálohy kontrolovat konzistenci databáze. RMAN umožňuje přírůstkové zálohy v různých režimech a podstatně tak snižuje čas potřebný k provedení záloh a zmenšuje velikost vlastní zálohy. RMAN umožňuje block-level recovery, v případě narušení jednotlivých databázových bloků umí obnovit pouze tyto konkrétní bloky a není nutné obnovovat celý datový soubor. RMAN umožňuje zálohovat a obnovovat databázi ve více vláknech. Tato vlastnost je možná pouze ve verzi Enterprise. RMAN je nezávislý na konkrétní hardwarové nebo softwarové platformě.
11
RMAN umožňuje přímý zápis na páskové mechaniky, pokud je při alokování kanálu specifikován parametrický soubor v proměnné ENV. RMAN implementuje skriptování a umožňuje ukládání skriptů v RMAN katalogu a jejich volání. RMAN katalogizuje záznamy o provedených zálohách. RMAN na základě nastavení retention politiky automaticky maže expirované zálohy všech databázových objektů. RMAN umí katalogizovat fyzické zálohy provedené prostředky operačního systému. RMAN umožňuje provedení image copy záloh příkazem backup as copy, což jsou zálohy identické s fyzickými databázovými soubory. RMAN umožňuje provádění duplex záloh. RMAN umožňuje ze svého prostředí zadávat příkazy operačního systému, sql příkazy databázi, startovat a zastavovat databázi. RMAN není možné využít pro zálohu souboru v operačním systému, jako například různé statické konfigurační soubory, databázový software, logy v souborovém systému. Jeho zálohovací schopnosti jsou spjaty s databází. RMAN je možné provozovat ve dvou základních režimech, které se liší místem uložení metadat o provedených zálohách. Nocatalog - kdy jsou informace o provedených zálohách a nastavení RMANa uloženy v řídícím souboru databáze(controlfile).Tento režim umožňuje základní operace a množství uchovávaných dat je limitováno velikostí řídícího souboru a inicializačním parametrem CONTROL_FILE_RECORD_KEEP_TIME. Catalog – kdy jsou informace o provedených zálohách a nastavení RMANa uloženy ve speciálním databázovém schématu(Recovery Catalog) v jiné databázi na jiném fyzickém serveru. Tento režim je doporučovaný, umožňuje větší variabilitu nastavení a usnadňuje obnovu databáze, avšak vyžaduje existenci další databáze. Použití catalogu je nutné v případech, kdy jsou v RMANu uložené skripty, catalog je možné použít pro více databází(ale nejedná se o doporučovanou variantu, je vždy lepší pro každou databázi použít vlastní catalog(nové Oracle schéma), nabízí větší možnosti reportů a umožňuje uložení některých konfiguračních parametrů. RMAN směruje uložení záloh podle parametru při alokovaní kanálů. Existují dva základní typy, type DISK a type SBT_TAPE. V případě varianty SBT_TAPE je nutné v proměnné ENV specifikovat konfigurační soubor páskové knihovny.
12
RMAN umožňuje provádět zálohu na úrovni datového souboru (datafilu), na úrovni tabulkového prostoru, zálohu celé databáze, řídících souborů, spfilu, archivních redologů. Jeho velkou předností je plná automatizace politik uchovávání záloh, kdy automaticky hlídá kombinace záloh databáze a zazálohovaných archivních redologů potřebných pro zotavení databáze, pravidelné čištění prostoru pro archivní redology, kdy RMAN hlídá, zda je daný redolog již zazálohován (případně zda je splněno množství požadovaných záloh) a jedině v tom případě je smazán. Toto byl v dobách před masovým rozšířením RMANa častý zdroj problémů. RMANa je možné ovládat z příkazového promptu nebo grafického prostředí Grid Console, samozřejmostí je dávkové spuštění v závislosti na možnostech konkrétního operačního systému. Na platformě wintel je možné použít dávkový příkaz AT či Naplánované spuštění, na platformě unix a linux crontab a v prostředí OpenVMS Queue Manager. Pro plánování spuštění záloh a údržbu catalogu je samozřejmě možné použít vestavěné plánovací funkce komerčních zálohovacích systému. V současné době představuje RMAN mocný nástroj na komplexní využití při záloze a obnově Oracle databází. Při jeho použití a splnění základních podmínek je bezpečnost databázových dat zaručena.
13
2 Hardwarová zálohovací řešení Dnešním standardem zálohování Oracle databází je využití utility RMAN a zároveň jeho propojení na existující zálohovací knihovnu (Media Management Server, MMS). Přestože stále klesá cena pevných disků a SAN diskové pole nabízejí stále se zvyšující bezpečnost a výkon, existuje řada důvodů pro zálohování na magnetické pásky. U rozsáhlých databází by pro zálohy byl potřeba několikanásobek velikosti databáze. Z tohoto důvodu vychází poměr cena za MB příznivěji pro pásku. Dalším důvodem je trvanlivost a bezpečnost uložení, kde také stále dominuje páska. Ukládáním záloh na disk se také můžeme dostat do konfliktu s požadavky na archivaci dat. Společnosti v současné době snižování nákladů využívají enterprise zálohovacích systému, kdy na jedno fyzické zařízení zálohují různá data z různých systému a nemusejí tak řešit každou aplikaci a systém zvlášť, což v konečném důsledku snižuje náklady na provoz. Utilita RMAN neumožňuje kromě zálohy na disk přímý přístup na zařízení, proto je nutné pro ukládání záloh využít vrstvu Media Management Layer (MML), která zpřístupní RMANu zálohovací systém pro zápis i čtení. Děje se tak při alokování kanálu v režimu SBT_TAPE, v proměnné ENV se specifikuje konfigurační soubor použité zálohovací knihovny. Zálohování Oracle databází se při použití režimu SBT_TAPE neliší od klasického zálohování na disk. Jediný rozdíl je ve způsobu alokování kanálu. Po úspěšné alokaci pak RMAN pouze posílá standardní příkazy MML vrstvě, která je zodpovědná za komunikaci s MMS. MML rozhraní pro RMANa není součástí databázového softwaru, ale dodává ho dodavatel MMS (zálohovací knihovny). Media Management Server se skládá ze tří základních komponent: Media management library - je softwarový plug-in pro utilitu RMAN, ve formě konfiguračního souboru nebo logického jména se specifikuje během alokace kanálu. Media management client software – je klientská část programu, který je zodpovědný za spojení a přenos dat do media management server. Media management server - je vlastní zálohovací systém.
14
Media management server lze dále dělit na několik softwarových a hardwarových komponent, jednotlivé komponenty se liší podle konkrétního dodavatele, nicméně vlastní architektura je podobná. Softwarová část se dělí na Media Manager Catalog (což je interní databáze, která obsahuje konfigurační údaje a dále informace o uložení záloh na konkrétních páskách), programy na zápis a čtení dat na pásky a také ovládací programy na podavač pásek. Hardwarová část se skládá z magnetických pásek, slotů, podavače a dalších komponent. Obrázek č. 1: Obecné schéma zálohování databázového serveru na MMS Media Management Server
Databázový server Oracle intance Databázové soubry
RMAN
Alokovaný kanál Media Management Library
Media management server software
Pásková mechanika
Media Management klient software
Zdroj: Oracle databáze 10g RMAN Backup&Recovery, vlastní úprava
Výběr použitého MML závisí na mnoha faktorech, především na ceně zálohovacího systému (MMS), ceně licence MML, robustnosti a vysoké dostupnosti MMS, požadované životnosti magnetických pásek a bývá podřízeno již existující firemní infrastruktuře a případně existujícímu zálohovacímu systému. U některých méně rozšířených platforem také existencí MML na dané platformě.
15
MML rozhraní pro zálohování Oracle databází dodávají následující společnosti: Arkeia Software - Arkeia Network Backup Tempo - Time Navigator BakBone Software - NetVault BridgeHead Software - HyperTape CommVault Systéme - QiNetix Galaxy CA – BrighStor - ARCServ backup EMC - EMC Disk Library, EMC Networker, EMC Avamar HP - Data Protektor, Archive Backup System for OpenVMS Novastor - NovaNet Backup Innovation Data Processing - FDR/UPSTREAM STORServer Inc. - SDP for Oracle on OpenVMS Syncsort - Backup Express IBM - Tivoli Storage Manager UTS Global LLC - Backup and Recovery Sterling Software - SAMS:Alexandria Symantec/Veritas – NetBackup, Backup Exec Sun - SUN's Soltice Backup Viton - NetBunker WumpusWare - OpenVMS Client to EMC Networker V další části podrobně popíši nejpoužívanější MML.
2.1 HP Data Protector Data Protector je zálohovací systém společnosti Hewlett Packard. Jedná se rozšířený komplexní zálohovací systém, známý také pod označením OMNIBack Data Protector. Vlastní systém se skládá ze softwarové části a hardwarové knihovny.
16
Softwarová část obsahuje interní databázi, umožňuje plnou automatizaci záloh, řízení přístupových práv, optimalizované zálohovací algoritmy (synthetic backups) a mnoho dalších funkčností. Systém je možné administrovat z příkazového terminálu nebo z grafického prostředí. HP Data Protector klienta je možné využívat na platformách MS Windows, Novell NetWare, HP-UX,Sun Solaris, Linux, IBM AIX, SGI IRIX, SNI SINIX, SCO OpenServer, SCO Unixware, HP True64 Unix, OpenVMS. HP Data Protector umožňuje přímé připojení páskových mechanik typu DDS, DLT,DLT1, SuperDLT,QIC/Travan, Magneto-Optical,Mammoth M2, Eliant, IBM 3590 (Magstar), STK 9840,STK 9940, AIT, LTO Ultrium. HP Data Protector také spolupracuje se zálohovacími knihovnami mnoha výrobců, například s HP, StorageTek, Sony, Dell, Seagate, ADIC, ATL, Spectralogical, Exabyte, Quantum,Breece Hill, Overland Data a další. HP Data Protector nabízí širokou škálu agentů pro zálohování různých typů aplikací a databází: Microsoft Exchange Microsoft SQL Server VMware Informix Sybase Oracle SAP R/3 IBM DB2 a další Pro zálohování Oracle databází je nutné nainstalovat na databázový server Data Protector Oracle integration software a například na unix platformě je dále nutné vytvořit symbolický link mezi rozhraním utility RMAN a MML knihovnou.
17
Tento krok se samozřejmě liší v závislosti na platformě operačního systému. Na OpenVMS systémech je nutné změnit další Oracle zdrojové soubory a následně zrelinkovat EXE spustitelné soubory . Pro použití Data Protector je nutné alokovat kanál jedním z následujících způsobů: allocate channel t1 type 'SBT_TAPE' PARMS='SBT_LIBRARY= /opt/omni/lib/libob2oracle8_64bit.sl'; allocate channel 'dev_1' type 'sbt_tape' parms 'ENV=OB2BARTYPE=Oracle,OB2APPNAME=orcl,OB2BARLIST=machlogs)'; Obrázek č. 2: Topologie HP Data Protector
Zdroj: HP OpenView Storage Data Protector Integration Guide for Oracle and SAP
HP Data Protector je v současné době nabízen ve verzi 6.1.
18
2.2 HP Archive Backup System for OpenVMS ABS/MDMS je komplexní zálohovací systém, který firma Hewlett Packard dodává jako standardní zálohovací řešení pro Aplha a Integrity serverové systémy na platformě OpenVMS. Jedná se robustní systém mající z důvodu vysoké dostupnosti clusterové řešení. ABS obsahuje interní databází záloh, plánovač úloh, umožňuje hardwarové i softwarové kryptování. ABS nabízí i plně automatické zálohy souborových systémů. Klientská část ABS je dostupná na platformách OpenVMS, MS Windows a True 64 Unix. Pro použití ABS MML utilitou RMAN je nutné nainstalovat klientskou část ABS programu, nadefinovat logické systémové jméno abs_sbt a korektně nakonfigurovat následující MDMS parametry: Media – definice typu použitého záznamového media. Location – umístění zálohovacího serveru. Domain - popis domény. Node – název serveru. Jukebox – specifikace použitého jukeboxu. Tape drives – specifikace použitých mechanik. Pool – specifikace použité skupiny pásek. Tape volumes – názvy použitých medií.
Při alokaci kanálu je nutné definovat proměnou MDMS$SBT_CATALOG, což je lokální, na serveru uložená interní databáze záloh a dále MDMS$SBT_ARCHIVE, kde jsou specifikovány parametry nutné k připojení MDMS serveru.
allocate channel ch1 type "sbt_tape" parms="ENV=(MDMS$SBT_ARCHIVE=ORA_ARCH_M24, MDMS$SBT_CATALOG=ORACLE_DB_M24)";
19
Obrázek č. 3: Topologie ABS/MDMS Cluster Databázový server A MDMS$Server A
Pásková knihovna A
Databázové soubory
RMAN
ABS klient
Lokalita A
Databázový server B Lokalita B
Databázové soubory MDMS$Server B
RMAN
Pásková knihovna B
ABS klient
Zdroj: vlastní úprava
ABS/MDMS je v současné době nabízen ve verzi 4.5.
2.3 EMC NetWorker NetWorker je produkt společnosti EMC. Jedná se o robustní a rozšířený komplexní zálohovací systém. EMC v minulosti zakoupilo tento produkt od společnosti Legato. Z tohoto historického důvodu je možné se často setkat s označením Legato NetWorker.
20
EMC NetWorker Server obsahuje kromě hardwarové části interní databázi záloh, robustní plánovač úloh, umožňuje plně automatické souborové zálohy a mnoho dalších modulů pro zálohování databází a aplikací: Networker Module for Oracle – pro zálohování Oracle databází. Networker Module for IBM DB2 – pro zálohování DB2 databází. Networker Module for IDM Informix. Networker Module for Lotus Notes/Domino. Networker Module for Microsoft Exchange Server. Networker Module for Microsoft SQL Server. Networker Module for SAP with Oracle. Networker Module for Sybase.
Klientská část EMC NEetWorker Module for Oracle (NMO) je dostupná na platformách AIX, HP-UX, Linux, Solaris, True64 Unix a MS Windows. Pro využití NMO MML utilitou RMAN je nutné na databázový server nainstalovat klientskou část programu Networker, následně vlastní modul Networker Module for Oracle posléze nastavit konfigurační soubor nwora.res v případě platformy MS Windows, na unix platformě je nutné vytvořit symbolický link na knihovnu libobk.a. Další nastavení je nutné provést i na straně EMC Networker serveru Jedná se o parametry: NSR_SERVER NSR_GROUP NSR_CLIENT NSR_DATA_VOLUME_POOL NSR_SAVESET_BROWSE NSR_SAVESET_RETENTION NMO umožňuje provádění záloh dvěma způsoby: Lokálně řízené zálohování – zálohovací skript je spuštěn manuálně nebo z lokálního plánovače úloh. Centrálně řízené spuštění záloh – zálohovací skripty jsou spouštěny centrálně z NetWorker Serveru.
21
Obě varianty mají klady i zápory často ovlivněné střetem mezi databázovým administrátorem a správcem NetWorker serveru. Databázový administrátor je odpovědný za stav databáze i provedených záloh, ale většinou nemá možnosti monitorovat stav a zatížení NetWorker serveru, což v prostředí velké společnosti může při souběhu záloh z různých systémů způsobovat zahlcení NetWorker serveru. Správce NetWorker má zase detailní přehled o stavu svého serveru, nicméně není odpovědný za stav zálohovaných databází a serverů, často se ani neangažuje v případné obnově. Pro použítí v utilitě RMAN je nutné kanál alokovat následujícím způsobem:
allocate channel t1 type 'SBT_TAPE'; send device type 'SBT_TAPE' 'ENV=(NSR_SERVER=
, NSR_GROUP=)'; Obrázek č. 4: Topologie EMC NetWorker
Zdroj: HART Matthew; FREEMAN Robert G. RMAN Backup&Recovery,The
EMC Networker Server je v současné době nabízen ve verzi 7.5.
22
2.4 IBM Tivoli Storage Manager Tivoli Storage Manager (TSM) je produkt společnosti IBM. I v tomto případě se jedná o velmi rozšířený komplexní zálohovací systém. TSM obsahuje kromě hardwarové části interní SQL databázi, plánovač úloh umožňující plně automatické souborové zálohy, šifrování dat, pro zvýšení dostupnosti je možné ho využívat TSM v clusterové konfiguraci. TSM má také mnoho dalších modulů pro zálohování různých typů databází a aplikací. TSM server je možné provozovat na platformách IBM AIX, HP-UX, Windows, Sun Solária, OS/390, Linux. TSM klient je možné používat na platformách AIX, HP-UX, Linux, Macintosh, Novell NetWare, OS/390, OS/400, Sun Solaris, Windows, Citrix Presentation Server,True64 Unix a MS Windows. Pro využití TSM MML utilitou RMAN je nutné na databázový server nainstalovat klientskou část programu TSM Tivoli Data Protector for Oracle (TDPO) a na unix platformě nastavit konfigurační soubory tdpo.opt, dsm.sys, dsm.opt a include.def, dále je nutné vytvořit symbolický link na knihovnu libobk.a. Nastavení je nutné provést i na straně TSM serveru: Node a heslo verdeleted retonly backdelete frequency verexists retextra mode serialization Pro použití TDPO je nutné alokovat kanál následujícím způsobem: allocate channel ch1 type SBT_TAPE parms 'ENV=(TDPO_OPTFILE=/home/oracle/rman/tdpo_sid.opt)';
23
Obrázek č. 5: Topologie TSM
Zdroj:HART Matthew; FREEMAN Robert G. RMAN Backup&Recovery,The
IBM Tivoli Storage Manager je v současné době nabízen ve verzi 6.1.
2.5 Symantec Veritas NetBackup Veritas NetBackup nabízí v současné době společnost Symantec, která toto enterprise zálohovací řešení odkoupila v roce 2005 od společnosti Openvision. Jedná se rozšířený, robustní zálohovací systém. Kompletní zálohovací řešení NetBackup se skládá z hardwarové a softwarové části, softwarová část obsahuje interní databázi, plánovač úloh umožňující plně automatické souborové zálohy, šifrování dat a optimalizované zálohovací algoritmy (synthetic backups). Symantec Veritas NetBackup dokáže spolupracovat s většinou dodavatelů páskových robotů, například s Dell, Exabyte, HP, IBM, Overland Data, Quasar, Quantum, Sony,Spectra Logic a SUNStorageTek. V současné době nabízí Symantec tři základní edice Veritas NetBackup: NetBackup Enterprise Server. NetBackup Server. NetBackup Starter Pack.
24
Veritas NetBackup nabízí širokou škálu agentů pro zálohování různých typů aplikací a databází: Lotus Notes and Lotus Domino Server. IBM DB2. Informix. Microsoft Active Directory. Microsoft Exchange Server. Microsoft SharePoint Portal Server. Microsoft SQL Server. Oracle. SAP. Sybase. Symantec Enterprise Vault. Veritas NetBackup for Oracle agent je dostupný na platformách HP-UX, HP True64 Unix, IBM AIX, Linux, Microsoft Windows, Novell NetWare, SGI IRIX a Sun Solaris. Pro používání Veritas NetBackupu je nutné na databázový server nainstalovat NetBackup Server software, NetBackup for Oracle a dále je nutné vytvořit symbolický link na knihovnu libobk.a. Pro zálohování Oracle databází je možné využít i samostatně licencovaný Netbackup for Oracle Advanced BLI (Block Level Incremental), který je součástí NetBackup Snapshot Client. Oproti standardnímu balíku redukuje množství zálohovaných dat. Při využití NetBackup MML je nutné alokovat kanál následujícím způsobem: allocate channel t1 type 'SBT_TAPE' parms 'ENV=(NB_ORA_SERV=server_name, NB_ORA_POLICY=RMAN_DEFAULT, NB_ORA_CLIENT=my_host_name), SBT_LIBRARY=/usr/openv/netbackup/bin/libobk.so64.1';
25
Obrázek č. 6: Topologie NetBackup
Zdroj: KUHL Darl; ALAPATI Sam; NANDA Arup. RMAN Recipes for Oracle Database 11g: ProblemSolution Approach
Symantec Veritas NetBackup je v současné době dostupný ve verzi 7.
2.6 Oracle Secure Backup Zálohovací systém Oracle Secure Backup (OSB) dodává přímo dodavatel Oracle databáze firma Oracle. Z důvodu licenčních podmínek se v současnosti jedná o populární a výhodnou možnost využití entreprise zálohovacího řešení za přijatelnou cenu. Softwarová část umožňuje všechny obvyklé vlastnosti, které jsou od robustního zálohovacího řešení požadovány, tj. plná automatizace zálohování souborových systému i databáze, využívání Network Attached Storage (NAS), přenos záloh z Virtual Tape Library (VTL) na fyzické pásky. Zvláště se zaměřuje integraci s ostatními produkty dodávané s Oracle databázemi (Grid Control, Real Application Cluster, Automatic Storage Management a Data Guard), na šifrování ukládaných dat, optimalizuje rotační politiku záloh mezi lokalitami (tape vaulting) a optimalizační algoritmy při zálohování (Oracle udává 25-40 % zrychlení oproti srovnatelným řešením ostatních dodavatelů při poklesu zatížení CPU o 10 %).
26
Oracle dodává OSB jako hotové řešení s hardwarovou knihovnou od firmy Sun StorageTek (v roce 2009 došlo k fůzi společností Sun Microsystem a Oracle), ale umožňuje také spolupráci s většinou dodavatelů páskových robotů. OSB umožňuje zálohovat souborové systémy a databáze v prostředí Microsoft Windows, Unix, Linux a NAS. Softwarová část je dodávána ve dvou verzích. Oracle Secure Backup Express je dodávána zdarma jako součást dodávky databázové softwaru a umožňuje zálohovat jeden databázový server na jednu páskovou mechaniku. Plná verze rozšiřuje nabízené možnosti o podporu VTL, Fibre Channel a šifrování. Při užívání OSB je nutné mít nainstalovaný administrativní server, media server a klientskou část OSB. Pro využití v utilitě RMAN je možné alokovat kanál následujícím způsobem: allocate channel ch1 device type sbt parms `env=(ob_device=drive3,ob_media_family=medfami1)`; Obrázek č. 7: Topologie OSB, varianta samostatný server
Zdroj: HART Matthew; FREEMAN Robert G. RMAN Backup&Recovery,The
Oracle Secure Backup v současné době dostupný ve verzi 10.3.
27
3 Výběr vhodného režimu zálohování Výběr vhodné zálohovací strategie závisí na mnoha faktorech a ve výsledku je ve většině případů založen na kompromisu mezi chtěným a možným. Databáze Oracle standardně umožňuje obnovu k poslední vytvořené záloze, na kterou lze následně aplikovat archivní redology. Podle situace a požadavků je databázi možné obnovit do dvou různých stavů. Kompletní obnova nepředstavuje žádnou ztrátu dat, naproti nekompletní obnova se využívá v situacích, kdy není možné databázi plně zotavit, ať už z chtěných důvodů (návrat databáze před okamžik chyby) či nechtěných (ztráta online redologů, nečitelnost zálohy atd.). Jak již bylo zmíněno výše, Oracle databáze umožňuje zálohování ve dvou různých stavech. Offline záloha představuje konzistentní zálohu, která vznikla při uzavřené databázi. Při využití prostředků OS jde o kompletně uzavřenou databázi, při využití utility RMAN pak je databáze ve stavu mount. Online záloha je oproti tomu vytvořena při otevřené databázi a je tedy z podstaty nekonzistentní a pro obnovu databáze je nutné aplikovat redology. Při záloze prostředky OS je nutné přepínat tabulkové prostory do stavu begin backup a end backup, při záloze utilitou RMAN to nutné není. Online zálohování předpokládá, že databáze je provozována v archivním režimu. Produkční Oracle databáze často není možné zálohovat v režimu offline, neboť tento typ zálohy vždy znamená její nedostupnost po dobu zálohování. Pokud rovnou pomineme databáze, které operují v režimu 24x7, i ostatní databáze, které mají požadovanou dostupnost jen v pracovních hodinách, není možné odstavovat v nočních hodinách, protože v té době probíhají systémové a aplikační údržbové úlohy, které není možné a ani žádoucí spouštět během denního provozu. Z výše uvedených důvodů proto bývají databáze zálohovány především v režimu online. Pro ochranu databáze a s ní související obnovu je ideální mít k dispozici co nejčerstvější plnou zálohu databáze. Obchodní útvary často požadují vytvořit zálohu před spuštěním EOD a v ranních hodinách před otevřením systému pro běžné uživatele. Lze se také setkat s požadavkem na velmi časté, i hodinové zálohování archivních redologů databáze, aby se co nejvíce minimalizovala ztráta dat během případné obnovy a zotavení databáze. V reálných podmínkách ale většinou není možné dělat zálohu 28
databáze častěji než jednou denně. Záloha archivních redologů pak probíhá dvakrát denně. Protože záloha vždy představuje znatelné zatížení zálohované databáze (CPU, IO), je snaha databáze zálohovat v době nejmenšího zatížení systému, což bývá zpravidla během nočních hodin. S růstem velikosti databáze se navíc na stávajícím zálohovacím zařízení čas potřebný k záloze protahuje, dochází ke kolizním špičkám mezi souběžně zálohovanými systémy. Pro efektivní plánování doby zálohování hraje velký význam, zda má databáze na zálohovacím zařízení dedikované mechaniky nebo zda zálohuje na sdílené. V druhém případě je pak nutná koordinace s dalšími administrátory a správcem zálohovacího systému. V další části budu popisovat režimy zálohování pouze utilitou RMAN, neboť zálohování prostředky OS je již v dnešní době považované za zastaralé a neplnící důležité požadavky (optimalizování průběhu zálohování, přírůstové zálohy, retention politika). Dodavatel databáze společnost Oracle doporučuje využívat utilitu RMAN. Dobu trvání zálohy i případné obnovy je možné zkrátit rozvlákněním. Podmínkou pro tento režim je existence více dostupných mechanik v zálohovacím systému. V utilitě RMAN je tento režim zajištěn použitím dalších kanálů, kdy si každý kanál alokuje jednu mechaniku (i LVT). V praxi se využívají dva až čtyři kanály. Běžně použití dvou kanálů znamená zkrácení doby potřebné na provedení zálohy na polovinu. Efektivita alokování více kanálů závisí na použitém zálohovacím systému i na hardwarové konfiguraci. Rozvláknění má ale i negativní stránku, neboť rozvlákněním roste riziko nečitelnosti medií a znamená i násobně větší zatížení jak vlastní databáze, tak i přenosové infrastruktury a zálohovacího systému. Ochranu zálohovaných dat na mediích je možné zvýšit režimem duplex během alokování kanálu. Stejně jako v předchozím případě i zde je nutné alokovat více mechanik. V podstatě to znamená, že při režimu duplex=2 každý kanál zapisuje na dvě mechaniky stejná data, databáze je tedy v jeden čas zazálohovaná dvakrát a data uložená na páskách jsou identická. V případě nečitelnosti jedné sady pásek je možné databázi obnovit ze záložní sady. Duplex režim, stejně jako předchozí režim rozvláknění, znamená v závislosti na počtu použitých kanálů násobné zatížení infrastruktury, ale čas potřebný k záloze i obnově databáze zůstává stejný jako použití jednoho vlákna. Cenou za vyšší bezpečnost je tedy větší zatížení infrastruktury při zachování délky zálohy i obnovy.
29
3.1 Úplná záloha databáze Úplná záloha databáze je nejčastějším typem zálohy. Z hlediska správy a případné obnovy přestavuje nejsnadnější a nejrychlejší možnost obnovy databáze. Během zálohy se kromě řídících a konfiguračních souborů zálohují všechny databázové soubory. Následně je nutné zálohovat vzniklé archivní redology. Doba trvání zálohy je ale ze všech popisovaných možnosti nejdelší. Pokud to neznamená problém, je možné tento typ trvale používat.
3.2 Přírůstková záloha databáze Pokud není možné databázi zazálohovat v požadovaném čase, je nutné přikročit k úpravě dosavadní zálohovací strategie. Jednou z možností je použití přírůstkové (inkrementální) zálohy. V určený den, typicky v době slabšího provozu během víkendu, je provedena speciální plná záloha databáze a v dalších dnech se v různých režimech zálohují pouze změněné databázové bloky. V případě obnovy je nejdříve aplikovaná nejčerstvější plná záloha, na ní jsou aplikovány nejnovější přírůstky a poté proběhne zotavení databáze za použití archivních redologů. Možné režimy jsou následující: Incremental level 0(L0) - speciální plná záloha databáze. Incremental level 1(L1) - rozdílová záloha databáze vztažená k jakékoli přírůstkové záloze databáze. Incremental level 1 cumulative(L1C) - kumulativní záloha databáze vztažená k počáteční záloze L0. Zvolení
způsobu
provádění
záloh
záleží
na
režimu
databáze
(OLTP
versus
Datawarehouse). Zvolený typ inkrementální zálohy také ovlivňuje případnou délku obnovy, neboť při využívání pouze L1 se nám zkrátí každodenní záloha, nicméně pro obnovu budeme potřebovat kromě L0 i několik L1 záloh, což obnovu prodlouží. Použití L1 cumulative naopak znamená, že denní zálohy budou delší, nicméně případná obnova využije pouze L0 a jednu L1C zálohu. Další možností zkrácení doby zálohování představují přírůstkově aktualizované zálohy, když se pouze aktualizuje L1 zálohou poslední L0 záloha.
30
Obrázek č. 8: Obecné schéma zálohování databázového serveru na MMS L0 L1
L1
L1
L1C
L1
Den 2
Den 3
L1C
Den 0
Den 1
Zdroj: vlastní úprava
Výrazného zrychlení přírůstkového zálohování je možné docílit i sledováním změn bloků v souboru sledování změn (block tracking file). Během zálohy pak RMAN nekontroluje každý blok databáze, zda se změnil, ale pouze zálohuje již zaznamenané změněné bloky ze souboru změn. Využití této metody sice přináší nepatrně zvýšenou zátěž, neboť databáze musí změny bloků zapisovat i do souboru, nicméně u rozsáhlých databází přináší použití souboru sledování změn významné úspory času během přírůstkové zálohy. Jak je patrné i na následujícím testu, zavedení přírůstkového zálohování sice výrazně zkracuje dobu záloh a množství ukládaných dat a v případě sdíleného zálohovacího systému i výrazně snižuje celkové zatížení (CPU, IO, síťové spojení), nicméně může mít negativní důsledky, protože znamená prodloužení doby potřebné na obnovu databáze. U méně důležitých systémů je možné přírůstkové zálohování bez většího váhání nasadit (typicky testovací a vývojová prostředí), ale u produkčních systémů je vždy nutné posoudit negativní vliv na délku případné obnovy, zvláště u systému, které se rychle mění. Z toho vyplývá, že přírůstkové zálohování je méně vhodné pro databázové systémy typu OLTP. V následující tabulce je možné vidět časy z jednotlivých testů, které předcházely zavádění přírůstkových záloh v naší společnosti. Cílem testů bylo porovnat doby zálohy a případné obnovy i se započítáním případné obnovy po pěti dnech přírůstkových záloh. Protože se jedná o sdílené prostředí, a to jak na úrovni serveru, tak i na úrovni zálohovacího systému TSM a koneckonců i na síťové vrstvě, není možné zabránit určitému
31
zkreslení testů, neboť nebylo možné utlumit provoz ostatních systémů. Z tohoto důvodu byly testy prováděny opakovaně. Testy byly prováděny na Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – za použití TSM(TDPO). Konfigurace serveru: System Model: IBM,9133-55A; Processor Type: PowerPC_POWER5 Number Of Processors: 4 Processor Clock Speed: 1648 MHz CPU Type: 64-bit Memory Size: 15328 MB
Tabulka č. 1: Testování délky záloh a obnovy databáze CLDDEV2 backup 1 2 3 4 5 6 7 8 9 10 11 12 13
Akce full backup incremental 0 create 2 tables & update 1GB data incremental 1 create 2 tables & update 1GB data incremental 1 create 2 tables & update 1GB data incremental 1 create 2 tables & update 1GB data incremental 1 create 2 tables & update 1GB data incremental 1 incremental 1 cumulative
použité savesety z akcí ve sloupci restore backup 1 restore (1) restore (1) 2 restore (2) restore (2)
start
stop
9:02:50 9:09:51
9:07:10 0:04:20 9:14:20 0:04:29
trvání size/MB 20824 20824
10:05:26 10:09:07 0:03:41
2045
10:14:29 10:17:49 0:03:20
2042
10:22:18 10:25:28 0:03:10
2040
10:30:03 10:33:14 0:03:11
2041
11:06:35 11:09:55 0:03:20 11:37:46 11:41:26 0:03:40
2043 9068
9:37:45 9:45:53 0:08:08 9:50:00 9:58:07 0:08:07 10:17:30 10:25:48 0:08:18 10:30:11 10:38:08 0:07:57
3 restore (2+4+6+8+10+12) restore (2+4+6+8+10+12) restore (2+4+6+8+10+12) 4 restore (2+13) restore (2+13) restore (2+13)
10:44:53 10:59:16 11:18:22 11:32:26 11:47:53 12:02:26 Zdroj: vlastní úprava
32
10:55:14 11:10:22 11:29:24 11:42:33 11:57:40 12:12:50
0:10:21 0:11:06 0:11:02 0:10:07 0:09:47 0:10:24
Tabulka č. 2 Testování délky záloh a obnovy databáze s použitím souboru sledování změn. CLDDEV2 backup 1 2 3 4 5 6 7 8 9 10 11 12 13
restore 1 2
3
4
block change tracking file start stop trvání size/MB
akce full backup incremental 0 create 2 tables & update 1GB data incremental 1 create 2 tables & update 1GB data incremental 1 create 2 tables & update 1GB data incremental 1 create 2 tables & update 1GB data incremental 1 create 2 tables & update 1GB data incremental 1 incremental 1 cumulative použité savesety z akcí ve sloupci backup restore (1) restore (1) restore (2) restore (2) restore (2+4+6+8+10+12) restore (2+4+6+8+10+12) restore (2+4+6+8+10+12) restore (2+13) restore (2+13) restore (2+13)
8:28:33 8:33:28
8:32:42 0:04:09 8:37:18 0:03:50
20914 20914
8:42:17
8:42:46 0:00:29
1902
8:51:34
8:52:02 0:00:28
1764
8:56:09
8:56:39 0:00:30
1764
9:00:16
9:00:46 0:00:30
1760
9:03:16 9:06:44
9:03:46 0:00:30 9:08:12 0:01:28
1760 9510
9:20:11 9:28:55 9:36:15 9:44:53 9:49:57 9:58:26 9:59:47 10:08:02 10:10:03 10:22:04 10:32:05 10:43:51 10:53:58 11:04:16
10:20:10 10:32:01 10:42:55 10:54:06 11:04:25 11:14:54
0:08:44 0:08:38 0:08:29 0:08:15 0:10:07 0:09:57 0:10:50 0:10:15 0:10:27 0:10:38
Zdroj: vlastní úprava
V první tabulce je možné vysledovat, že přírůstková záloha neznamenala podstatnou úsporu času, jen kolem 27 %. Množství ukládaných dat se snížilo o 90 %. Doba obnovy se průměrně protáhla o 37 %. V druhé tabulce, která popisuje přírůstkové zálohování při použití souboru sledování změn, je již zkrácení zálohy razantní – o více než 87 %. Doba obnovy se oproti prvnímu testu nezměnila, množství ukládaných dat se dokonce nepatrně snížilo. Z testů vyplývá vysoká důležitost použití souboru pro sledování změn, zátěž generovaná plněním tohoto souboru nebyla měřitelná.
33
3.3 Přírůstkově aktualizované zálohy Další možností, jak zefektivnit přírůstkovou zálohu a obnovu databáze, je možnost pravidelně aktualizovat L0 level zálohu. Zálohovací plány jsou často postaveny na režimu, kdy o víkendu proběhne přírůstková L0 záloha databáze (plná záloha databáze) a další dny až do dalšího víkendu probíhá již pouze L1 či L1C záloha. Z tohoto faktu plyne, že pokud nastane potřeba obnovy databáze těsně před vznikem další L0 zálohy, je při obnově nutné na starou L0 zálohu aplikovat několik dalších L0 či L1C přírůstkových záloh. Doba obnovy se na naší testovací databázi v takovém případě prodloužila o 37% (tabulka č.1 a č.2.),nicméně záleží na velikosti a provozu takové databáze. V reálném provozu tak může dojít k výraznému prodloužení doby obnovy. Tuto situaci lze vyřešit pravidelným aktualizováním přírůstkové L0 zálohy. Máme tak k dispozici vždy čerstvou L0 zálohu, což vede k výraznému zkrácení doby obnovy. Dalším pozitivem je fakt, že v tom případě není nutné ani periodicky zatěžovat infrastrukturu i databázi víkendovým vytvářením L0 zálohy, neboť máme tuto zálohu stále aktuální. Aktualizace L0 zálohy se používá ve dvou základních režimech: L0 záloha je stará 1 den a je na ní v případě potřeby aplikována jedna L1C záloha. run { recover copy of database with tag 'LEVEL_0'; backup incremental level 1 cumulative copies=1 for recover of copy with tag 'LEVEL_0' database; } Přírůstková záloha je ihned aplikována na L0 zálohu a plná záloha je vždy plně aktuální. run { backup incremental level 1 cumulative copies=1 for recover of copy with tag 'LEVEL_0' database; recover copy of database with tag 'LEVEL_0'; }
34
Tuto funkcionalitu, tedy vytváření kopií obrazů (backup copy), je možné použít pouze při alokaci zařízení typu DISK. Pro zařízení typu SBT_TAPE to není možné.
3.4 Záloha databáze za využití parametru skip readonly Oracle databáze umožňuje přepínat stav tabulkových prostorů do stavu readonly. Tento stav se využívá u dat, které je zapotřebí uchovávat v nezměněném stavu a do tabulkového prostoru je třeba zakázat zápis. Z povahy dat vyplývá, že se nemění. Pokud administrátor u podobné databáze potřebuje zkrátit dobu zálohy, je možné tyto readonly struktury ze zálohování vyloučit. Jedná se tedy o obdobu přírůstkové zálohy, kdy se denně nezálohují data, která se nemění. Využití této funkčnosti ale skrývá jeden závažný problém. Utilita RMAN bohužel nedokáže zachytit změny mezi dvěmi zálohami, takže případné přepnutí stavu tabulkového prostoru z readonly do readwrite, provedení změn a přepnutí zpět do readonly, nezaznamená a příslušné datové soubory nezazálohuje, což při případné obnově databáze může vést ke ztrátě dat. Využití read-only tabulkových prostorů v databázi s sebou nese ještě jeden problém, neboť utilita RMAN si při údržbě katalogu drží pouze jednu zálohu těchto objektů a nepřijatelně tak roste riziko ztráty dat při nečitelnosti jediného média, na kterém jsou tyto zálohy uchovány. Určitým řešením tohoto problému je změnit nastavení RMAN katalogu z RETENTION POLICY TO RECOVERY WINDOW na RETENTION POLICY TO REDUNDANCY. Nicméně i toto řešení přináší úskalí, protože pří spuštění mimořádné zálohy a následném spuštění údržby katalogu dojde i posunutí nejzazšího času, ze kterého je možné databázi obnovit, což může být v rozporu s obchodními podmínkami či uzavřeným SLA1.
3.5 Záloha databáze za využití klonovacích technologií U některých produkčních databází jsou kladeny mimořádné požadavky na rychlost zálohy i případné obnovy dat.
1
SLA – Service Level Agreement
35
Typickým příkladem jsou systémy, na kterých se zpracovávají události typu EOD, EOM, EOY2. V takovém případě existuje velký tlak na rychlost provedení zálohy databáze a v případě chyby během zpracovaní i rychlý návrat na začátek zpracování. Častý také bývá požadavek databázi zálohovat i před začátkem obchodních aktivit, aby v případě havárie bylo možné obnovit databázi do tohoto definovaného stavu. V případě rozsáhlejších databází tento požadavek není možné splnit za použití páskových zálohovacích systémů a případná záloha před i po EOD by výrazně prodlužovala celé zpracování i provoz. V tomto případě se nabízí možnost využití klonovacích technologii (Sync and Split Technology) SAN diskových polí. Tato funkčnost bývá někdy nazývána i jako fáze clone a add clone. Diskové pole alokuje pro uložení databázových souborů například tři diskové skupiny. V daný okamžik dojde k rozpojení (split) skupiny, databáze běží nad prvními dvěma skupinami a na třetí skupině disků leží kopie databáze v okamžiku rozpojení. Databáze na primárním serveru prochází následujícími kroky: Přepnutí tabulkových prostorů do stavu BEGIN BACKUP. Rozpojení diskových skupin za běhu databáze buď nástroji dodavatele diskového pole, které zajistí konzistentní stav databáze během rozpojení, nebo přepnutím databáze do suspend stavu (zastavení IO operací databáze) a návratu zpět (alter system suspend, alter system resume). První varianta neovlivňuje běh databáze, druhá varianta způsobí zastavení databáze na několik desítek sekund. Druhá varianta se dnes již běžně nevyužívá. Přepnutí tabulkových prostorů do stavu END BACKUP. Takto vzniklou třetí skupinu můžeme použít v případě havárie k rychlému obnovení prvních dvou diskových skupin a je také možné ji utilitou RMAN zazálohovat na páskový zálohovací systém. Během zálohování je nutné třetí skupinu připojit k primárnímu serveru (po rekonfiguraci diskových svazků) nebo ji připojit k záložnímu (zálohovacímu) serveru. 2
EOD – End of Day, zpracování konce dne EOM – End of Month, zpracování konce měsíce EOY – End of Year, zpracování konce roku
36
Druhá možnost je transparentní a doporučovaná, ale vyžaduje existenci záložního serveru. Při případném zotavení databáze bude nutné aplikovat archivní redology vzniklé během rozpojení diskové skupiny. Po skončení zpracování na primárním serveru je třetí disková skupina připojena (sync) zpět a až do okamžiku dalšího rozpojení běží databáze nad třemi diskovými skupinami.
37
4 Další možnosti ochrany dat 4.1 Cluster Pro zachování maximální možné dostupnosti se často využívají clusterové technologie. Ve zkratce jde o dva a více serverů, které se dokáží při výpadcích zastupovat a udržovat tak databázový systém v chodu. Tato funkčnost a tím pádem vysoká dostupnost je často vyžadovaná v SLA. Podle účelu je možné clustery dělit na[6]: Clustery zajišťující vysokou dostupnost (High Availibility) Clustery zajišťující rovnoměrné rozprostření zátěže (Load-ballancing) Clustery zajišťující vysoký výpočetní výkon (Compute) Clustery zajišťující přístup k souborovým systémům (Storage) Clustery vytvářené rozsáhlými heterogenními sítěmi spojených počítačů zaměřených na výpočetní výkon (GRID Computing)3 Implementace clusterové technologie se liší podle použité hardwarové a softwarové platformy, nicméně všechny mají podobné vlastnosti. Jde o zajištění síťové dostupnosti, kdy se používají různé varianty DNS jmen a IP adres pro jednotlivé členy clusterů (uzly) a zajištění clusterových souborových systémů, které jsou přístupné z jednotlivých uzlů clusteru. Další používanou funkčností je hlasování členů clusteru o primárním uzlu, kdy se často využívají quorum uzly či spare (voting) disky. Tato situace nastává, pokud cluster software ztratí kontakt s uzlem a účelem je zamezení nekoordinovaného běhu jednotlivých uzlů. Tyto specializované služby zajišťuje dodavatel serveru a operačního systému buď nativními prostředky operačního systému (byť často samostatně licencovanými) či programovým vybavením třetích stran. Jako příklad nativního programového vybavení pro zajištění clusterových služeb bych zmínil operační systém HP OpenVMS, který již v základní verzi zajišťuje všechny tyto požadavky, navíc využívá jednotnou databázi uživatelů (uživatelé mají na všech uzlech 3
Projekt SETI@home, analyzování dat z observatoře Arecibo a další
38
clusteru stejný uživatelský účet) a jednotlivé disky jsou vidět ze všech uzlů clusteru zároveň. Naproti tomu IBM využívá cluster technologii HACMP, která neumožňuje běžné sdílení souborového systému mezi uzly a každý uzel má vlastní uživatelskou databázi. IBM dále nabízí technologii Extended Model, která za cenu některých omezení také umožňuje funkčnost clusteru. Pokud daný operační systém nenabízí clusterové souborové služby nebo je nezajišťuje na požadované úrovni, je možné použít produkty třetích stran [7]: DataPlow Nasan File System DataPlow SAN File System (SFS) IBM General Parallel File System (GPFS) Microsoft Cluster Shared Volumes (CSV) Oracle Cluster File System (OCFS) PolyServe storage solutions Silicon Graphics clustered file system (CXFS) Red Hat Global File System (GFS) Sanbolic Melio FS clustered file system Sun QFS TerraScale Technologies TerraFS Veritas Cluster File System VMware VMFS Xsan Z Research/Open Source (GlusterFS) New Dream Network/Open Source (Ceph) Zvláště bych chtěl zvýraznit Oracle Cluster File Systém (OCFS), který je možné využít v cluster softwaru firmy Oracle - Cluster Ready Services (CRS). Alternativou OCFS je v CRS použití Automatic Storage Management (ASM) nebo raw device.
39
Jistou šanci, jak zpřístupnit bez dalších finančních nákladů souborové systémy mezi uzly clusteru tak, aby je mohla využívat Oracle databáze, je v unixovém světě využití takzvaných RAW device, což jsou speciální blokové zařízení diskových systémů, které jsou charakteristické obcházením služeb operačního systému (vyrovnávací paměti, buffery). Speciální podmnožinou clusterů jsou geografické clustery. Jedná se o dva a více serverů spojených do clusteru v různých lokalitách, které se dokáží při výpadcích zastupovat a udržovat tak databázový systém v chodu i v případě fyzické destrukce serveru nebo dokonce datového centra. Mimořádnou roli v geografickém clusteru hraje rychlost a kvalita síťového spojení mezi jednotlivými uzly a dále replikace dat na úrovni SAN pole. Pro vysokou dostupnost clusteru je nutné kromě existence dalších uzlů v clusteru použít i redundanci na všech úrovních, například zdvojení napájecích zdrojů, síťových karet, řadičů, procesorů a pamětí typu ECC4. Samozřejmostí by také mělo být využití UPS a diesel agregátů a zabezpečení datového centra prvky pasivní a aktivní ochrany.
4.2 Cold/hot failover Pojmem failover se míní převod provozu databáze z jednoho serveru na druhý. Děje se tak v mimořádných situacích při výpadku primárního serveru, ale i plánovaně, kdy je nutné na primárním serveru provést odstávkovou servisní činnost, jako je například výměna hardwarového dílu, patchování operačního systému, infrastrukturní akce mající dopad na dostupnost systémů (testy UPS, rekonfigurace síťových prvků) a v neposlední řadě i testování havarijních plánů aplikací. Vlastní failover je možné dělit na dva základní typy: Cold failover – Převod provozu databáze je odstávkový a vždy znamená výpadek provozu. Na primárním serveru dojde k uzavření databázové instance, odmontování diskových systémů. Na záložním serveru jsou následně tyto diskové systémy přimontovány a databázová instance nastartována. Na mnou spravovaných systémech
4
ECC – Error Correcting Code pamět
40
tato akce trvá tři až pět minut, po této době se klienti mohou připojit a pokračovat v práci. Na neaktivním serveru neběží databázová instance. Hot failover – Převod provozu databáze je bezodstávkový a při ošetření některých situací mohou klienti pokračovat bez přerušení v práci. Tato technologie se nazývá Real Application Cluster (RAC) a podrobněji se ji budu věnovat v následující kapitole. Na obou (a případně více serverech) jsou otevřené instance dané databáze, umožňují připojení a práci v obou instancích zároveň a při výpadku jedné z instancí přebírá připojené klienty druhá instance. Vlastní proces přesunu připojených uživatelů je závislý na konfiguraci databázové instance a nastavení databázového klienta (konfigurační soubor tnsnames.ora, konfigurace JDBC thin client a další).
4.3 Real Application Cluster Real Application Cluster (RAC) je označení databázové clusterové technologie společnosti Oracle, která zabezpečuje vysokou dostupnost a škálovatelnost Oracle databází. Jde o podobnou funkčnost, jakou Oracle až do verze databáze 8 označoval jako Parallel Server.
Obrázek č. 9: Konfigurace RAC clusteru
Zdroj: LONEY Kevin; BRYLA Bob. DBA Handbook:Oracle Database 10g
41
RAC se skládá z dvou a více otevřených databázových instancí, které umožňují rozprostření uživatelské zátěže mezi jednotlivé instance a v případě havárie jedné z nich přesun provozu na zbývající databázovou instanci. Tento přesun by uživatele měl co nejméně ovlivnit, v ideálním případě tuto akci vůbec nezaregistruje. RAC je možné nainstalovat na jednotlivé uzly clusteru, který využívá vlastní clusterové řešení a případně i produkty třetích stran, ale instalace Oracle CRS je povinná. Vlastní databázové soubory je možné uložit jak na clusterově sdílený souborový systém, například na OCFS, dále na raw device či do ASM. Velkou pozornost je třeba věnovat síťové komunikaci mezi jednotlivými databázovými instancemi. V RAC prostředí má mít každý uzel minimálně dvě síťové karty, jednu pro komunikaci s databázovými klienty a druhou pro vnitřní síť, která se používá pro komunikaci v rámci clusteru. Meziclusterová komunikace je mimořádně citlivá na rychlost a kvalitu síťového spojení a tento fakt brání nasazení RAC v případě vysoce zatížené databáze, kdy je mezi jednotlivými uzly delší vzdálenost. Ve společnosti, ve které pracuji, jsme RAC používali pro některé produkční systémy. Bohužel s nárůstem provozu se nám začala zpožďovat právě meziclusterová komunikace a v době provozních špiček docházelo k prodlužování odezev instancí s negativním dopadem na klienty. Vzdálenost mezi jednotlivými uzly clusteru byla patnáct kilometrů, síťové spojení mezi instancemi bylo sdílené a bylo využíváno i pro ostatní systémy. Řešením by zřejmě bylo budˇ zkrácení vzdálenosti mezi uzly (toto řešení je nereálné, servery jsou ve firemním datovém centru a není možné je přestěhovat jinam), nebo vytvoření speciální dedikované linky pouze pro potřeby konkrétní databáze (i toto řešení se ukázalo jako finančně velmi nákladné). V současné době tedy provozujeme databáze s RAC pouze jako cold failover (druhá instance je uzavřená).
4.4 Oracle Data Guard Oracle Data Guard je dalším řešením firmy Oracle zajišťující vysokou dostupnost. Tato funkčnost byla v dříve nazývaná jako standby databáze. Pomocí Data Guard technologie je možné vytvořit jednu a více kopií primární databáze na shodném operačním systému a platformě, které mohou být automaticky udržovány aplikací archivních redologů ve shodě s primární databází a v případě problémů primární databáze dokáží převzít její roli.
42
Kromě zajištění vyšší dostupnosti umožňuje Data Guard i přesun části zátěže z primární databáze na záložní, kterou je možné například pro generování reportů dočasně přepnout do režimu čtení a výrazně tak odlehčit primární databázi. Vlastní Data Guard je zajišťován třemi službami: Log Transport Services - zajišťují přenos redologů z primární databáze na záložní Log Apply Services – zajišťují zpracování přenesených redologů Role Management Services - zajišťují přechod záložních databází do role primární databáze Obrázek č. 10: Konfigurace Data Guard
Zdroj: LONEY Kevin; BRYLA Bob. DBA Handbook:Oracle Database 10g
Synchronizace primární a záložní databáze může probíhat ve třech režimech: V režimu maximální ochrany – transakce je na primárním systému potvrzena až po úspěšném přenesení redologů na záložní server, v případě problémů s přenosem je primární databáze zastavena. V režimu maximální dostupnosti - transakce je na primárním systému potvrzena až po úspěšném přenesení redologů na záložní server, v případě problémů s přenosem primární databáze pokračuje a po odstranění problému je přenos redologů dokončen. V režimu maximálního výkonu – transakce jsou na primárním systému potvrzeny a redology jsou přeneseny na záložní databázi až následně.
43
Záložní databázi je možné provozovat ve dvou režimech: Fyzická záložní databáze – záložní databáze je přesnou kopii primární databáze, lze ji dokonce využít pro zálohování místo primární databáze. Logická záložní databáze – záložní databáze může obsahovat některé struktury, například indexy, které primární databáze nemá a které usnadňují reporting. Je možné mít víc kopií primární databáze a tyto záložní databáze mohou být provozovány v obou režimech zároveň. Kromě nesporných přínosů má technologie Data Guard i stinné stránky. Pokud není databáze provozována v režimu maximální ochrany či dostupnosti, existuje nebezpečí ztráty dat během transportu na záložní databázi. Naopak použití režimu maximální ochrany nebo dostupnosti může výrazně negativně afektovat výkon primární databáze, v případě režimu maximální ochrany může dokonce nastat, například při síťových problémech během transportu redologů, okamžitá vyžadovaná odstávka primární databáze. Převod provozu z primární databáze na záložní není bezodstávkový, na rozdíl od RAC. Oracle Data Guard je naopak řešením v případě, kdy je pro velkou vzdálenost mezi jednotlivými databázovými servery problematické využití RAC technologie, neboť přenos archivních redologů není tak citlivý jako meziclusterová komunikace v rámci RAC.
4.5 RAID Oracle databáze ukládá své datové soubory do nějaké formy datového úložiště. Z výkonových a bezpečnostních důvodů bývá až na výjimky využívána nějaká varianta RAID konfigurace diskového pole. Podstatou RAID je použití speciálního řadiče, ke kterému jsou připojené jednotlivé disky, z kterých je sestaveno diskové pole. Jednotlivé RAID konfigurace se liší použitými hardwarovými komponenty a především požadovanou funkčnosti, podle které můžeme RAID dělit na jednotlivé varianty a případné kombinace[8]: RAID 0 – (striping) data jsou ukládána po částech na jednotlivé disky, výhodou je rychlost čtení, podstatnou nevýhodou je nízká odolnost vůči chybám. Pro databázové využití je naprosto nevhodné.
44
RAID 1 – (mirroring) data jsou ukládaná na dva disky zároveň, v případě výpadku jednoho disku se pracuje s druhou kopií, výhodou je tedy bezpečnost dat, nevýhodou využití pouze poloviční kapacity. RAID 0+1 - kombinace RAID 0 a 1, použití minimálně čtyř disků, data jsou zrcadlena i prokládána (striped, then mirrored), výhodou je rozložení zátěže mezi více disků, dobrá odolnost vůči výpadku, nevýhodou je využití pouze poloviční kapacity. RAID 1+0 – kombinace RAID 0 a 1, použití minimálně dvou disků, data jsou zrcadlena i prokládána (mirrored, then striped), oproti RAID 0+1 vytváří stripsety na mirrorovaných discích, výhodou je rozložení zátěže mezi více disků, vyšší odolnost vůči výpadku než RAID 0+1, nevýhodou je využití pouze poloviční kapacity. RAID 2 – data jsou stripována a zároveň zabezpečena (Hammingův kód), nevýhodou je malá propustnost a využití pouze poloviční kapacity, výhodou je zkrácení doby odpovědi pole. RAID 3 – data jsou ukládána na sérii disků, na speciální disk je ukládán paritní bit, výhodou je dobrá odolnost vůči výpadku a použitelné místo se krátí pouze o velikost paritního disku, nevýhodou je kapacitní úzké místo paritního disku. RAID 4 - data jsou ukládána po blocích, ne po bitech jako v RAID 3, vlastnosti jsou podobné jako u RAID 3. RAID 5 – podobné řešení jako RAID 3, ale paritní data jsou ukládána rovnoměrně po všech discích, výhodou je rovnoměrná zátěž, paralelní přístup k diskům, nevýhodou je pomalejší zápis. RAID 6 – obdoba RAID 5, navíc je přidáno počítání dalších paritních dat, výhodou je odolnost vůči výpadku dvou disků, rychlost čtení je srovnatelná s RAID 5, ale zápis je díky nutnosti vytváření dalších paritních dat pomalejší než RAID 5. Lze se setkat i s některými dalšími typy RAID konfigurací. V praxi se pro databázové servery nejčastěji využívají RAID 1 pro maximální bezpečnost, RAID 1+0 pro maximální výkon a RAID 5 pro efektivní využití diskového prostoru při zachování přijatelné odolnosti proti výpadkům a dobrého výkonu.
45
4.6 Archivace dat Z hlediska ochrany se jedná o zvláštní způsob uchování cenných dat. Nejedná se o klasickou databázovou zálohu, ale nejčastěji o vyvedení archivačních dat z databáze za použití utilit Export či Datové pumpy. Možné jsou i jiné způsoby, ať již jde o klasický sql dotaz čí použití nějakého typu datové replikace. Archivace se většinou od klasické zálohy liší kromě použitých prostředků i délkou a případně i zabezpečením ukládaných informací. Zatímco se klasická záloha málokdy uchovává déle než několik týdnů, archivační data se běžně uchovávají několik let. Běžné zálohy se uchovávají na zálohovacím médiu uvnitř zálohovacího systému, které leží v datacentru, archivační data se nejčastěji ukládají na magnetická média a následně přenášejí do trezoru. Tímto způsobem se uchovávají například auditní informace, ať již ze systémové nebo aplikační oblasti, podle daných požadavků. V bankovním prostředí jde často o plnění vyhlášek a zákonných ustanovení o uchovávání informací o uskutečněných finančních operacích, uzavřených smlouvách, disponenčních právech a obdobně. Bohužel je častým jevem, že v počátcích projektu IS se často archivace vůbec neimplementuje a případná archivační strategie se zpracovává až na již existujícím systému, což s sebou nese nemálo problémů. Často je nutné z těchto důvodů měnit datové struktury i programové vybavení. Při procesu archivace se řeší otázka přesouvání dat z provozních tabulek do speciálních archivačních, kde je obvykle využíván partitioning podle nastavených kritérií (nejčastěji dělení dle časových údajů) a vlastní přesun se děje buď onlinově (při vzniku provozního záznamu vzniká zároveň záznam do archivační tabulky) nebo následně dávkově v době slabého provozu. Pro onlinový přesun je možné kromě aplikačního programového vybavení použít i databázové triggery. V mé organizaci se používají oba výše uvedené způsoby archivace, v případě dávkového přesunu se v noci spouští automatická dávka, která přesouvá data do archivačních tabulek, které jsou rozdělené podle data (měsíční partitioning). Následný automaticky spuštěný proces je pak v určený čas exportuje na disk a proběhne záloha na magnetickou pásku ve dvou kopiích. Tyto pásky se pak do vypršení platnosti skladuji v trezoru.
46
Během tvorby návrhu archivační strategie je také potřebné definovat způsob přístupu k archivovaným datům. V ideálním případě je vytvořen nový databázový server, kde jsou veškerá archivovaná data online přístupná pro určené pracovníky, protože ad-hoc přístup k těmto datům bývá poměrně zdlouhavý. Přístup k historickým archivním datům také komplikují migrace na vyšší verze databází a jiné databázové či serverové platformy. Často je pak nutné převádět staré zálohy archivních dat na nová média a do nových formátů, protože udržování původních systémů deset i více let po opuštění platformy je finančně mimořádně náročné a často i technicky nemožné (ukončení technické podpory, nedostatek náhradních dílů, nedostatek obslužného personálu, stárnutí záznamového média).
47
5 Vyhodnocení popisovaných možnosti Jak již bylo popsáno v předešlých kapitolách, zálohovací strategii je nutné začít řešit již v okamžiku plánování vzniku nového databázového serveru. Nejprve je nutné zvolit vhodnou formu zálohy databáze. V dnešní době má pro zálohu databáze smysl použít pouze utilitu RMAN, která umožňuje flexibilní a komplexní služby. Pro obnovu je nejvýhodnější mít co nejčerstvější plnou zálohu databáze. Pokud není možné z nějakého důvodu provádět denně plnou zálohu, je možné využít jednu z forem přírůstkové zálohy, ať již denní provádění varianty L1 či L1C. V případě zálohy na disk je zajímavou variantou využití možnosti přírůstkově aktualizované zálohy. V druhém kroku je nutné rozhodnout, zda budeme zálohovat do souborového systému či na páskový zálohovací systém. V případě záloh na páskový zálohovací systém se rozhodujeme podle dostupnosti MML na dané platformě, důležitosti databáze, požadované dostupnosti a s tím související doby potřebné na obnovu, ceny za MML licenci a především pak podle případné existence zálohovacího systému v dané společnosti, protože pořízení kompletního dedikovaného systémů pro jednu databázi je finančně velmi náročné a nebývá zvykem. Trendem je naopak využívání enterprise zálohovacího systému pro velké množství databází a systémů zároveň. Bohužel nelze jednoduše porovnat jednotlivé ceny, neboť ceníky dodavatelských firem jsou nepřehledné a často nejsou ani veřejně uváděny, běžně využívají odlišný přepočet bránící přehlednému srovnání, například IBM využívá přepočet na PVU, Oracle licencuje na mechaniky, Symantec prodává minimálně pět licencí najednou, HP a EMC prodávají licenci pouze včetně roční podpory a HP Data Protector je navíc omezen na použití pouze jednoho kanálu. Pokud je požadovaná paralelizace, je tedy nutné dokoupit další licenci. Konečná cena se navíc může díky množstevním a jiným slevám snížit i o desítky procent. Licenční poplatek za použití MML agenta je v porovnání s investicí do robustního zálohovacího systému (softwarová a hardwarová část, záznamová média) minimální a v rozhodování, jaký typ zálohovacího systému použít, hraje podle mých zkušeností minoritní roli. 48
Následující tabulka poskytuje základní přehled poplatků za využití MML agentů pro zálohování Oracle databází.
Tabulka č. 3 Orientační ceny MML licencí
Název produktu
HP ABS Rmote Mgr OVMS Alp Q tier EMC Networker Module for Oracle6 IBM Tivoli Storage Manager for Databases (10 PVU)7 Symantec NetBackup Starter Pack 6.5 Linux Server8 Oracle Secure Backup9 HP Data Protector Oracle Integration software 10
Přepočet Přepočet 1 5 20 1 na 1 na 1 Měna klient klientů klientů mechanika klienta a mechaniku CZK5 v CZK CZK
87510
87510
EUR
1000
25406
EUR
151
3842
USD
3995
11995
USD CZK
18622 3500
33221
65261 33221
Zdroj: vlastní úprava
Do celkové ceny softwaru na zálohování databázového serveru je třeba dále započítat i základní poplatek za využití agenta pro daný operační systém, který je používán pro zálohy systémových a uživatelských souborových svazků, archivačních dat a podobně. Jednotlivé zálohovací systémy a jejich moduly pro zálohy Oracle databází nabízejí v podstatě srovnatelnou funkčnost a lze říci, že spolehlivě plní všechny běžně vyžadované požadavky.
5
6 7 8 9 10
Směnný kurz ČSOB EUR, deviza střed 19.3.2010 - 25,406 CZK USD, deviza střed 19.3.2010 - 18,646 CZK EMC prodává základní licenci pouze s povinnou roční podporou v ceně 500 EUR, cena za roční použití je 38109 Kč. IBM využívá speciálního přepočtu na PVUs - Processor Value Units. Například dvou procesorové servery v naší společnosti POWER6(p570) mají 240 PVU, cena za TDPO licenci na tomto stroji je 92202 Kč. Symantec nabízí pro hlavní softwarové platformy totožnou cenu. Oracle nabízí také produkt Oracle Secure Backup Express, který je pro jeden databázový server a k němu připojenou jednu zálohovací mechaniku zdarma. HP Data Protektor Oracle Integration software je prodáván výhradně včetně roční podpory v ceně 9000 Kč, celková částka za roční používání je tedy 42221 Kč s omezením na použití jednoho kanálu.
49
Mnohem podstatnější roli hraje typ použitých páskových mechanik, jejich cena, záznamová a čtecí rychlost a vlastnosti medií, jako je cena za kus, spolehlivost a dále rozšiřitelnost knihovny o další komponenty. Navíc při rozhodování, který typ páskového zálohovacího systému bude využit pro zálohování databázového serveru, hraje v praxi v podstatě jedinou roli typ zálohovacího systému, který společnost již vlastní. Ve společnosti, ve které pracuji, se využívají tři základní páskové zálohovací systémy. Pro platformu HP OpenVMS se jedná o HP Archive Backup System for OpenVMS, pro wintel platformu jde o EMC NetWorker(Legato) a pro IBM systémy jde o IBM Tivoli Storage Manager. Pro první seznámení bych doporučil bezplatný software Oracle Secure Backup Express, který při omezení na jednu mechaniku umožňuje získat zkušenosti se zálohami na páskové zařízení. Pro malé, případně méně důležité databázové systémy plně dostačuje ukládání záloh do souborového systému. Při přírůstkovém zálohování, které výrazně snižuje velikost zálohy, a při dobrém zajištění souborového systému proti havárii (RAID metody) se jedná o metodu vhodnou především pro testovací a vývojové prostředí. Zálohy do souborového systému je výhodné využít především kvůli nízké a stále klesající ceně za MB a nenáročné správě. Speciální kapitolou záloh do souborového systému jsou klonovací technologie na úrovni SAN diskového pole s následným uložením dat do páskového zálohovacího systému. Vzhledem k finanční a technické náročnosti je tato technologie předurčena především pro kritické produkční systémy s vysokými požadavky na rychlost zálohy a obnovy databáze. Během provozu databázového serveru se často dostaneme do situace, kdy je nutné prvotní rozhodnutí o zálohovací strategii přehodnotit. Jako příklad bych uvedl situaci v naší společnosti, když nám postupem času databáze pro dohledovou a administrativní konzoli Grid Control narostla na několikanásobek původní velikosti a dosud provozované zálohování do lokálního souborového systému začalo být z důvodu nedostatku volného diskového prostoru problematické. Protože se jednalo o databázi běžící na fyzickém serveru na wintel platformě a odmítli jsme připojení dodatečného SAN diskového pole, protože mělo nižší dostupnost, než byla 50
požadovaná pro Grid Control, rozhodli jsme se využít již existující zálohovací systém EMC Networker, který se v naší společnosti využívá pro zálohování serverů a aplikací na wintel platformě. Po nutné instalaci a konfiguraci EMC Networker klienta a MML rozšíření Networker Module for Oracle jsem provedl následující testy, které porovnávaly rychlost záloh do lokálního souborového systému a na magnetické pásky EMC Networker Serveru.
Testy probíhaly na Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 za použití EMC NMO v. 4.5. Operating System Microsoft Windows Server 2003 Server 5.2 Service Pack 2 (32-bit) Hardware Platform ProLiant DL380 G5 CPUs 4x 1333MHz Memory Size (MB) 8190 Local File Systems (GB) 715.5
Tabulka č. 4 Testy záloh do souborového systému a na magnetické pásky pořadí 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
typ testu záloha na disk(1 vlákno, fileperset 4) záloha na disk(2 vlákna, fileperset 4) záloha na disk(4 vlákna, fileperset 4) obnova z disku(1 vlákno) obnova z disku(2 vlákna) obnova z disku(4 vlákna) záloha na pásky(1 vlákno, fileperset 1) záloha na pásky(1 vlákno, fileperset 4) záloha na pásky(2 vlákna, fileperset 4) záloha na pásky(4 vlákna, fileperset 4) obnova z pásek(1 vlákno) obnova z pásek(2 vlákna) obnova z pásek(4 vlákna)
start 6:00:27 12:18:59 14:43:25 12:08:46 14:15:25 15:40:48 9:36:27 12:18:44 12:51:23 13:06:58 10:43:21 13:40:09 13:29:20
end 8:33:40 13:41:01 15:32:27 12:13:23 14:23:27 15:49:04 10:05:40 12:36:06 13:06:15 13:19:08 11:45:15 14:31:45 14:08:21
trvání 2:33:13 1:22:02 0:49:02 0:04:37 0:08:02 0:08:16 0:29:13 0:17:22 0:14:52 0:12:10 1:01:54 0:51:52 0:39:01
Zdroj: vlastní úprava
V tabulce je dobře vidět, že použití EMC Networker NMO výrazně urychlilo dobu potřebnou k provedení záloh. Oproti tomu ale narostla doba případné obnovy databáze. Jak je patrné z předchozích řádků, žádná univerzální rada, jak a na jaké zařízení zálohovat databázový server, není možná. Každý musí zvážit všechny dostupné varianty a vybrat pro databázový server optimální variantu z hlediska bezpečnosti, finančních a organizačních nákladů, rychlosti zálohování a dalších důležitých faktorů.
51
Při výběru je možné využít expertních služeb společnosti Oracle a dalších konzultačních firem a zálohovací strategii vybudovat až na základě jejich doporučení.
52
Závěr Cílem této bakalářské práce byl popis a výběr vhodných strategií zálohování Oracle databázových serverů. Každý existující systém musí být adekvátně zálohován, aby v případě selhání hardware, software, výskytu lidské chyby, nebo dokonce zlého úmyslu, nedošlo ke ztrátě dat. Každý správce musí dbát na pravidelné provádění záloh s ohledem na zmíněné skutečnosti. Často ani vhodně zvolena zálohovací strategie, pravidelné a pečlivé provádění záloh nestačí. Bohužel i zálohovací systémy mohou mít vadná media. Je vždy nutné počítat předem s nejhorší variantou a pojistit se i proti této situaci, například prováděním duplexních záloh, často do různých lokalit, využít cluster technologií a několikanásobného jištění. Je samozřejmě nezbytné zvolit adekvátní ochranu dat vzhledem k důležitosti databáze. Objem dat v databázových systémech prudce roste a správci serverů i databází musí na tuto situaci reagovat stálým zlepšováním zabezpečení dat a zaváděním nových technologií. Nakonec přichází na řadu člověk. Pokud není v problematice dostatečně zběhlý, sebelepší technologie mu nepomůže. Musí stále testovat validitu záloh a být připraven na různé scénáře obnovy. Dobrou příležitostí k získání zkušeností bývá pravidelné testování havarijních plánů aplikace. Řešit problematiku zálohování v okamžiku potřeby obnovy dat už bývá pozdě. V lepším případě organizace zaplatí vysokou částku za expertní služby, v horším případě přijde o část, nebo dokonce o všechna data, což pro odpovědného správce většinou znamená rozvázání pracovního poměru, často finanční pokutu a ztrátu profesní pověsti. Pro organizaci taková událost může znamenat i konec činnosti, v každém případě minimálně finanční ztráty a ztrátu prestiže u klientů a partnerů. Informace jsou v organizaci to nejcennější a proto by měla zajistit jejich maximální ochranu.
53
Seznam použité literatury [1]
BRYLA Bob; LONEY Kevin. DBA Handbook:Oracle Database 11g. The McGrawHill Companies, 2008. ISBN 978-0-07-149663-6
[2]
HART Matthew; FREEMAN Robert G. RMAN Backup&Recovery,The McGraw-Hill Companies, 2007. ISBN 0-07-226317-2
[3]
KUHL Darl; ALAPATI Sam; NANDA Arup. RMAN Recipes for Oracle Database 11g: Problem-Solution Approach. Apres, 2007. ISBN 978-1-59059-851-1
[4]
LONEY Kevin; BRYLA Bob. DBA Handbook:Oracle Database 10g. The McGrawHill/Osborne, 2005. ISBN 0-07-223145-9
[5]
LONEY Kevin; BRYLA Bob. Mistrovství v Oracle Database 10g. Computer Press, 2006. ISBN 80-251-1277-2
Internetové zdroje [6]
Wikipedia – Cluster (computing), Dostupná z http://en.wikipedia.org/wiki/Cluster_(computing) [cit. dne 10.02.2010]
[7]
Wikipedia - Clustered File Systems, Dostupná z http://en.wikipedia.org/wiki/Clustered_file_system [cit. dne 20.03.2010]
[8]
Wikipedia - RAID, Dostupná z http://cs.wikipedia.org/wiki/RAID [cit. dne 28.03.2010]
54
Definice, akronymy a zkratky Crontab - Plánovač úloh v unix prostředí ECC - Error Correcting Code je typ paměťových modulů využívající paritní bit EOD - End Of Day. Zpracování události Konec dne EOM - End Of Month. Zpracování události Konec měsíce EOY - End Of Year. Zpracování události Konec roku GRID - Grid technologie umožňuje spojovat servery do skupin sdružující zdroje a umožňující provozování více aplikací zároveň, opak dedikovaných serverů pro konkrétní aplikaci. GUI - Graphical User Interface. Grafické uživatelské rozhraní aplikace. IS - Informační systém MML - Media Management Layer. Jde o rozhraní mezi RMANem a zálohovacím systémem NAS - Network Attached Storage neboli „datové úložiště na síti“ je datové úložiště připojené k místní síti LAN. Partitioning - Oracle partitioning umožňuje rozdělení tabulek a indexu na menší logické části, především z výkonnostních důvodů. PVU - IBM Procesor Vaule Units je licenční veličina, podle kterého se přepočítávají licenční poplatky na výkon procesoru (core) RAID - Redundant Array of Independent Disks je typ diskových řadičů, které zabezpečují pomocí určitých speciálních funkcí koordinovanou práci dvou nebo více fyzických diskových jednotek. Zvyšuje se tak výkon a odolnost vůči chybám nebo ztrátě dat. RMAN - Recovery Manager. Jde o utilitu používanou pro zálohu databáze SAN - Storage area network je dedikovaná (oddělená od LAN, WAN, atd.) datová síť, která slouží pro připojení externích zařízení k serverům (disková pole, páskové knihovny a jiná zálohovací zařízení). SLA - Service Level Agreement. Smlouva o dostupnosti systémů mezi IT útvarem a zákazníkem SQL - Structured Query Language. Jedná se o strukturovaný dotazovací jazyk relačních databází SQL Loader - Oracle utilita pro nahrání textových dat do databáze 55
UPS - Uninterruptible Power Supply (Source) neboli „nepřerušitelný zdroj energie“ je zařízení nebo systém, který zajišťuje souvislou dodávku elektřiny. VTL - Virtual Tape Library je virtuální zálohovací zařízení, data nejsou ukládaná prvotně na páskové zařízení, ale do souborového systému.
56
Příloha č. 1 Příklad nastavení RMAN katalogu
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 18 DAYS; CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/uxx/app/oracle/product/10.2.0/dbs/snapcf_xxxxx.f'; # default Zdroj: vlastní úprava
1
Příloha č. 2 Záznamu v RMAN katalogu List of Backup Sets =================== BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------811522 Full 209.75M SBT_TAPE 00:00:06 08.06.09 BP Key: 811603 Status: AVAILABLE Compressed: NO Tag: TAG20090607T203026 Handle: xx_bck_db_online_ptkh1kj8_1_1.RBG Media: BAPOOL List of Datafiles in backup set 811522 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- -------- ---1 Full 39216712492 08.06.09 /oraxx_2/oradata/xx/data/system01.dbf Zdroj: vlastní úprava
1
Příloha č. 3 Ukázka RMAN skriptů rman target / catalog=rman_katalog/xxxxxxxxx@recovery_catalog msglog=/home/oracle/RMAN/LOG/backup_online_db_xxx.0.log resync catalog; sql 'alter system archive log current'; run { allocate channel ch1 type SBT_TAPE parms 'ENV=(TDPO_OPTFILE=/oraxx_1/rman_tsm/tdpo.opt)'; allocate channel ch2 type SBT_TAPE parms 'ENV=(TDPO_OPTFILE=/oraxx_1/rman_tsm/tdpo.opt)'; sql 'alter system archive log current'; backup format 'xx_bck_db_online_%U.RBG' check logical database include current controlfile filesperset 1; backup current controlfile; release channel ch1; release channel ch2; sql 'alter system archive log current'; } run { allocate channel ch1 type SBT_TAPE parms 'ENV=(TDPO_OPTFILE=/oraxx_1/rman_tsm/tdpo.opt)'; backup format 'xx_bck_redo_%U.RBG' archivelog all NOT BACKED UP 3 TIMES; release channel ch1; } run { allocate channel ch1 type SBT_TAPE parms 'ENV=(TDPO_OPTFILE=/home/oracle/rman/tdpo.opt)'; restore archivelog from logseq 36316 until logseq 36324 thread 1; release channel ch1; }
run { allocate channel ch1 type SBT_TAPE parms 'ENV=(TDPO_OPTFILE=/home/oracle/rman/tdpo.opt)'; set until time '2009-06-02:03:30:00'; restore controlfile; alter database mount; restore database; recover database; sql ´alter database open resetlogs´; release channel ch1; } Zdroj: vlastní úprava
1
