Deduplikační technologie zálohování dat

Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií

Deduplikační technologie zálohování dat Bakalářská práce

Autor:

Kristína Kyšová Informační technologie

Vedoucí práce:

Praha

Ing. Lubomír Jankových, CSc.

Duben, 2011

Prohlášení: Prohlašuji, že jsem bakalářskou práci zpracovala samostatně a v seznamu uvedla veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámena se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

............................. V Praze, dne

29.4.2011

Kristína Kyšová

Poděkování Tímto bych chtěla poděkovat vedoucímu své bakalářské práce, Ing. Lubomíru Jankovýchovi, CSc., za pomoc, veškerý čas, který mi věnoval, za hodnotné rady a odborné vedení během mé práce.

Anotace Bakalářská práce popisuje nové trendy v systémech zálohovaní dat. V první části popisuje tradiční zálohovací technologie. Ve druhé a je srovnává s moderní deduplikační technologií. Třetí část se věnuje měření. Sleduje účinnost deduplikační technologie v různých prostředích. Na základě těchto měření tato práce dokazuje, že deduplikační technologie je v oblasti zálohování dat technologií blízké budoucnosti. Klíčová slova: Avamar, deduplikace, deduplikační poměr, obnova dat, zálohování dat.

Annotation Bachelor thesis describes new trends in data backup systems. The first part describes the traditional backup technologies. The second part compares them with advanced deduplication technologies. The third part deals with the measurement. It monitors the effectiveness of deduplication technologies in different environments. Based on these measurements this work demonstrates that the deduplication technology is near future technology in data backup. Keywords: Avamar,

deduplication,

deduplication

ratio,

data

recovery,

data

backup.

Obsah: Úvod

7

1. Klasické technologie zálohování dat

8

1.1. Zálohování dat 1.1.1 Systém přímého zálohování

8 9

1.1.2 Zálohovací systém po LAN (LAN-based Backup)

10

1.1.3 Zálohovací systém bez LAN (LAN-free Backup)

14

1.1.4 Bezserverové zálohování

19

2. Deduplikační technologie zálohování dat 2.1. Parametry deduplikací

21 22

2.1.1 Soubor vs část souboru (File vs subfile)

22

2.1.2 Fixní délka bloku vs variabilní délka bloku

22

2.1.3 Deduplikace na zdroji vs na cíli (source vs target)

24

2.1.4 Globální deduplikace

25

2.1.5 Deduplikační poměr (Deduplication ratio)

26

2.2. Řešení zálohování EMC AVAMAR

28

2.2.1 Princip fungování systému AVAMAR

28

2.2.2 Tři edice softwaru AVAMAR

29

2.2.3 Ochrana RAIN technologií (Redundant Array of Independent Nodes)

31

2.2.4 Replikace AVAMAR řešení

32

3. Měření AVAMAR řešení v různých prostředích

33

3.1. AVAMAR v prostředí VMware (virtuální prostředí)

33

3.1.1 Zálohování VMware prostředí ve společnosti A

33

3.1.2 Zálohování VMware prostředí ve společnosti B

35

3.2. AVAMAR v prostředí SAP nad databází Oracle

37

3.3. AVAMAR v prostředí Exchange

39

3.4. Komplexní VMware prostředí ve společnosti C a návrh řešení

41

Závěr

45

Seznam použité literatury

47

Seznam použitých zkratek

49

Seznam obrázků

50

Seznam grafů

50

Seznam tabulek

51

Seznam příloh

51

Úvod Organizace produkují data (emaily, dokumenty, ERP systémy, video, audio, databáze...) a tato data jsou ukládána na interních discích PC, pracovních stanic, serverů či v lepším případě na externí disková pole. Každá společnost dříve nebo později dospěje k rozhodnutí, že většinu dat je potřeba zálohovat, protože jejich ztráta by mohla být pro organizaci devastující. Důvody, které k tomuto rozhodnutí vedou, bývají většinou dva. Prvním z nich je potřeba obnovení zhavarovaného IT systému v co možná nejkratším čase. Druhým z nich je potřeba obnovy dat, nebo části dat, do stavu k určitému bodu v historii. Dle studií společnosti IDC (11) množství dat na Zemi roste exponenciálním způsobem. Tato data jak bylo popsáno výše, mají vlastníci dat snahu systematicky zálohovat. Objem záloh těchto dat roste ještě dramatičtěji, protože při dodržení klasických zálohovacích schémat, se data v zálohách několikrát opakují. A protože čas, který máme k dispozici na zálohování, na rozdíl od množství zálohovaných dat nenarůstá, zvyšuje se tlak na rychlost zálohovacích technologií a jejich výkon. Jedním ze způsobů, jak čelit tomuto tlaku, je právě využití technologií deduplikace. Ty odstraňují ze zálohovaných dat duplicity, čímž se samotný objem zálohovaných dat zmenšuje a snižuje se náročnost na velikost zálohovacího prostoru. Tyto systémy můžou rovněž i zkracovat dobu času potřebnou na zálohování dat. Cílem práce je prezentovat moderní trendy v oblasti zálohováni dat a podrobně analyzovat deduplikační technologii. V této bakalářské práci je měřena a porovnávána účinnost deduplikačních zálohovacích technologií v různých prostředích. Pro tento účel byl vybrán produkt AVAMAR společnosti EMC.

7

1. Klasické technologie zálohování dat Každá organizace produkuje data (emaily, dokumenty, FTP protokoly, video, audio, databáze...) a všechna je někam ukládají (PC, externí média, servery, disková pole...). A každá společnost dříve nebo později dospěje k bodu, kdy si uvědomí, že většinu dat je potřeba zálohovat, protože jejich ztráta by byla nenahraditelná až devastující. První část práce se zabývá popisem klasických zálohovacích systémů, popisem výhod a nedostatků jednotlivých architektur.

1.1. Zálohování dat Ztráta dat může být způsobena několika aspekty. Chyba na hardwaru je nejčastější důvod ztráty dat. Často se stává, že pevný disk začne vydávat divné zvuky. Je to známkou problémů se čtením a zápisem dat na disk a je vysoce pravděpodobné, že disk brzy zkolabuje. Druhým nejčastějším důvodem je selhání lidského faktoru: nechtěné smazání dat, úmyslné smazání dat, náhodné přesunutí dat neznámo na které místo na disku, útok hackerů. Je dobré si uvědomovat, že s daty organizace nepracujete jen vy, ale také řada dalších uživatelů. Dalším důvodem ztráty dat může být chyba softwaru. Je možné, že programy neočekávaně reagují na dorazy uživatelů nebo se vyskytne interní chyba v programu. Napadení softwaru viry či spywarem je také důvod, proč uvažovat nad ochranou dat. V neposlední řadě je potřeba zmínit vyšší moc. Může se stát že vypukne požár, nastane zemětřesení, záplavy, chyby v elektroinstalaci, přijde k vloupání a další. Jsou to okolnosti méně pravděpodobné, ale je potřeba se zamyslet i nad těmito aspekty a zahrnout je do konceptu zálohování dat v podniku. Nejúčinnější způsob, jak chránit data před jejich ztrátou, je jejich pravidelné zálohování. Zálohování je vytvoření kopie dat a jejich přenos na zálohovací médium. V prostředí organizací se používají jako zálohovací zařízení páskové jednotky, páskové knihovny, disková pole, souborové úložiště - NAS (Network Attached Storage) a další. Každá organizace staví svůj zálohovací systém podle svých potřeb. Hodnotí, kolik a jaké data je potřeba zálohovat, jak rychle přibývají, jak jsou strukturována, jak je strukturován 8

podnikový systém (geografické rozmístění systémů), hodnotí ekonomické aspekty pořízení a implementace zálohovacího systému a mnoho dalších aspektů. V dnešní době jsou k dispozici hardwarová řešení, která značně snižují nebezpečí ztráty dat způsobené hardwarovou chybou (kupříkladu mirroring disků, replikace dat...). Nicméně neřeší zbylá možná nebezpečí, která jsou výše zmiňována.

Kategorizace zálohování dle architektury Tradiční zálohovací architektury jak uvádí společnost EMC (9): 1.1.1.

Systém přímého zálohování (Direct-attached backup)

1.1.2.

Zálohovací systém po LAN (LAN-based Backup)

Síťové modely pro ukládání dat (Storage Area Network Backup models) 1.1.3.

Zálohovací systém bez LAN (LAN-free Backup)

1.1.4.

Bezserverové zálohování (Serverless Backup)

1.1.1 Systém přímého zálohování Tento typ zálohování dle EMC (9) má jednoduchou infrastrukturu a často s ním podniky začínají. Každý klient (zálohovaný server) je identický se zálohovacím serverem (server, který řídí zálohovací systém) a proto má vlastní páskovou jednotku. Záloha je prováděna zálohovacím systémem (zálohovacím softwarem) přímo na ni. Metadata jsou data, která popisují zálohovaná data, jejich umístění na zálohovacím médiu a jsou vždy uložena na zálohovacím serveru.

Obrázek č.1: Systém přímého zálohování Zdroj: (3) EMC Corporation. Backup and Recovery Fundamentals, Student Resource Guide page 26

9

Výhodou přímého zálohování je rychlost jak zálohování dat, tak jejich obnova, vzhledem k tomu, že pásková jednotka a klient (v tomto případě identický se zálohovacím serverem) jsou umístěny v jednom místě (viz. obrázek č.1). Tím je možné využít maximální přenosové rychlosti mezi serverem, který je v tomto případě zároveň zálohovaným klientem a obsahuje páskovou jednotku. Na druhé straně zálohovací systém ovlivňuje datový server a jeho aplikace ve smyslu využívání zdrojů paměti a CPU (Central Processing Unit). Tím se může celý systém z pohledu běhu hlavní aplikace zpomalovat. S přibývajícím počtem serverů se stává systém přímého zálohování finančně neefektivním, vzhledem k tomu, že každý server musí být vybaven páskovou jednotkou. Pokud se jedná o externí pásková zařízení, je s tím spojena i otázka, kam fyzicky systémy umístit. Správa takto samostatných systémů je velice komplikovaná z důvodu jejich možné rozmanitosti. Každý server může být vybaven jiným zálohovacím systémem, který se liší výrobcem či verzí. Další komplikací může být rozdílná lokalita systémů (různé patro, geografická vzdálenost...). Všechny tyto aspekty značně komplikují kontrolu nad daty. Kontrola správnosti zazálohování dat v takových případech není jednoduchá. Samotná správa různých zálohovacích systémů je také náročná, a pokud to řekneme nadneseně, tak takřka nemožná. V takovémto případě je potřeba se zamyslet nad změnou zálohovacího řešení.

1.1.2 Zálohovací systém po LAN (LAN-based Backup) Centrálním bodem pro zálohování je zálohovací server. Na zálohovacím serveru jsou uložena metadata a jsou nastavena pravidla zálohování. Metadaty rozumíme data sloužící k popisování a indexování uložených zazálohovaných dat. Serverům ovládajícím páskové jednotky nebo jiná úložná zařízení a umožňujícím zápis na zálohovací zařízení, říkáme „storage node“. Storage node je součástí zálohovacího serveru nicméně může existovat i jako separátní server (viz obrázek č.3). Hlavní výhodou centralizovaného zálohovacího systému po LAN je, že veškerá zálohovaná data jsou na jednom místě (9).

10

Obrázek č. 2 popisuje jednoduchou situaci zálohovacího systému po LAN. Zálohovací server vysílá pokyn klientovi pro zálohování dat, který data načte, pošle po LAN na zálohovací server a ten je zapíše na páskovou jednotku. Stejnou cestou se dostávají ze zálohovaného klienta metadata na zálohovací server, kde jsou uložena.

Obrázek č. 2: Zálohovací systém po LAN Zdroj: (3) EMC Corporation. Backup and Recovery Fundamentals, Student Resource Guide page 28

Na obrázku č. 3 je situace rozšířena o zálohování poštovního serveru v jiné lokalitě, který zálohovaná data posílá přes separátní storage node na jiné datové úložiště a metadata jsou poslána opět na zálohovací server, kde jsou uložena.

Obrázek č. 3: Zálohovací systém po LAN rozšířený o separátní storage node Zdroj: (3) EMC Corporation. Backup and Recovery Fundamentals, Student Resource Guide page 28

11

Proces zálohování zálohovacího systému po LAN: 1.

Zálohovací server vyvolá proces zálohování u zálohovaného klienta

2.

Server, který ovládá pásky, což je zálohovací server nebo storage node, vloží pásku do páskové jednotky

3.

Zálohovaný klient rozhodne, které soubory je potřeba zálohovat

4.

Zálohovaný klient přečte zálohovaná data z disku a pošle je k zazálohování

5.

Storage node přečte zálohovaná data a zapíše je na pásku

6.

Zálohovaný klient a storage node pošlou zálohovacímu serveru metadata, která obsahují to, co bylo zálohováno a na které pásce daná zálohovaná data jsou

7.

Zálohovací server uloží metadata na disk

Výhodou centralizovaného zálohovacího systému po LAN ve srovnání se systémem přímého zálohování je snížení nákladů centralizací páskových zařízení a jejich správy. Nižší počet páskových jednotek soustředěných v jednom místě snižuje náklady na jejich pořízení i na samotnou správu systému. Některé servery v podnicích jsou malé a jejich zálohování je finančně náročné. Zálohovací systém po LAN řeší tuto situaci centrálně, tudíž není nutno pořizovat drahé zálohovací systémy separátně. Z pohledu řízení zálohování podnikových dat je tento způsob zálohování jednodušší. Vylepšení funkčnosti centralizovaného zálohovacího systému je možné použitím automatizovaných, robotických páskových knihoven. Zálohovací systém po LAN je oproti systému přímého zálohování složitější o dva kroky. a) kdy klient posílá data k zazálohování b) kdy zálohovací server čte tato zálohovaná data Takovéto množství úkolů (viz navýšení kroků výše) systém zatěžuje, což můžeme chápat jako nevýhodu tohoto řešení. V porovnání s předešlým řešením, zálohovací systém po LAN vyžaduje víc kapacity CPU a paměti na straně klienta (zálohovaného serveru) v souvislosti se síťovými protokoly, formátováním dat a přenosem dat po síti. Zátěž sítě je tím ovlivněna taktéž a je zapotřebí počítat s dimenzováním sítě pro potřeby zálohování. Z uvedeného vyplývá, že nároky na systémové zdroje jsou v porovnání se systémem

12

přímého zálohování vyšší. Při pořizování zálohovacího systému po LAN je nutné počítat se servery dedikovanými pro takovéto řešení. Kapacita sítě do velké míry ovlivňuje rychlost zálohování. Pokud nejsou síťové prvky určeny k zálohování, výkonnost může být nedostatečná vzhledem k ostatním síťovým aktivitám (FTP protokoly, video, audio a emaily), což může způsobovat uživatelům výkonnostní problémy. Prostředí, které zálohuje velké množství logických disků na velké množství páskových knihoven, bude omezovat i ty nejrychlejší síťové technologie. Posílením LAN o další spojení nemusí být vždy technicky možné, kvůli technickému omezení na straně serverů, které jsou omezeny počtem slotů k připojení vysokorychlostních síťových karet (NICs - network interface cards). Zálohovací systém po LAN může vyžadovat speciálně dedikované servery pro kontrolu pásek, které kontrolují a řídí páskové jednotky a fungují jako centrální kontrolní bod. Mnoho velkých organizací implementuje metadata server bez pásek, spolu s dedikovaným serverem pro kontrolu páskových jednotek pro páskové úložiště. V případě údržby páskové jednotky (speciálně SCSI) se může stát, že je nutné odstavit server. Pokud je v řešení zálohování obsažen páskový robot, připojený k serveru pro kontrolu páskových jednotek a metadata server je separátní, procesy zálohování, případně obnova dat, může běžet dál souběžně s údržbou na páskové jednotce. Server pro kontrolu páskových jednotek není většinou vyžadován pro technické řešení, ale velmi často z důvodu bezpečného a plynulého provozu (9).

13

1.1.3 Zálohovací systém bez LAN (LAN-free Backup) Veškerá zálohovaná data ze zálohovaného klienta jsou přenášena po SAN (Storage Area Network) přímo na zálohovací zařízení. Po LAN se přenáší pouze metadata a tím se značně odlehčí její zátěži (viz. obrázek č.5). SAN byla primárně vyvinuta pro rychlé a vysoce spolehlivé spojení mezi zálohovacími body (zálohovaným klientem a zálohovací jednotkou). Využívá protokoly, které pracují s datovými bloky. Základním protokolem pro SAN je iSCSI (Internet Small Computer System Interface). Protokolem nejrozšířenějším je však Fibre Channel protokol (FC) a to díky jeho extrémní spolehlivosti, rychlosti a možnosti spojení klientů na velké vzdálenosti, nutné pro přenos dat při zálohování, obnově dat a pro obnovu dat po katastrofě (Disaster recovery). Pro propojení SAN

se využívá optických vedení Fibre Optics

(v současnosti o rychlosti až 10 Gbps) a protokolu FCP. V SAN se používají speciální Fibre Channel síťové prvky, které umožňují propojení v této specifické síti. Hub nebo Switch (přepínač) slouží k propojení segmentů v rámci jedné sítě a router (směrovač) spojuje alespoň dvě sítě a přenáší data mezi nimi. Servery musí mít Fibre Channel Host Bus Adapter (HBA). HBA zprostředkovává komunikaci mezi servery a diskovým polem. Optické vedení Fibre Channel poskytuje možnost připojení až do vzdálenosti 100km. Repeatery (opakovače) tuto vzdálenost prodlužují až na téměř neomezenou. To umožňuje budování geograficky vzdálených, bezpečných zálohovacích systémů odolných vůči katastrofám (1). Na obrázku č. 4 je příklad topologie SAN se zdvojeným spojením. Dojde-li k havárii adaptéru nebo switche, systém automaticky najde náhradní cestu pro přenos dat. SAN je ve srovnání s LAN téměř bezeztrátový protokol. LAN byla od počátku konstruována pro aplikace, které jsou vysoce tolerantní vůči ztrátám datových packetů a chybovosti při přenosu dat. SAN nesmí ztrácet data, musí být spolehlivá a rychlá. Model zálohování typu „LAN-free“ využívá SAN technologii ve spojení se zálohovacím softwarem, který podporuje sdílení páskových jednotek. Vysoká rychlost a schopnost Fibre Channelu přenášet data na velkou vzdálenost je důvod proč je používán na přenos dat v SAN zálohovacích prostředích. Metadata jsou i v tomto řešení přenášena přes LAN (Local Area Network) na zálohovací server neboli metadata server. Tento přenos 14

metadat většinou významně nezatěžuje LAN a z hlediska objemu přenášených dat je bezvýznamný ve srovnání s velkým množstvím přenášených dat během zálohování po SAN. I v tomto modelu zálohování je zálohovací server kontrolním bodem pro robotický mechanizmus páskových knihoven.

Obrázek č. 4: Příklad topologie SAN Zdroj: (2) DRAHOVZAL, Marek – SÁDOVSKÝ, Adam. Fibre Channel str. 6.

15

Obrázek č. 5: Zálohovací systém bez LAN (LAN-free backup) Zdroj: (3) EMC Corporation. Backup and Recovery Fundamentals, Student Resource Guide page.30

Proces zálohovací systém bez LAN (LAN-free Backup): 1.

Zálohovací server vyvolá proces zálohování u zálohovaného klienta

2.

Pokud je použito páskové úložiště dat, zálohovací server přidělí páskovou jednotku zálohovanému klientovi

3.

Zálohovací server instruuje robota páskové knihovny o vložení pásky do přiděleného driveru

4.

Zálohovaný klient (např. poštovní server) určí, které soubory je potřeba zálohovat

5.

Zálohovaný klient (totožný se serverem storage node) načte zálohovaná data z diskového pole přes SAN a zapíše je na páskovou jednotku taktéž přes SAN

6.

Zálohovaný klient pošle zálohovacímu serveru metadata, která obsahuje co bylo zálohováno a na které pásce dané zálohované data jsou

7.

Zálohovací server uloží metadata na disk

(pořadí kroků 2,3 a 4 se mohou lišit. Záleží na použitém zálohovacím nástroji) (9)

16

Podniky, které přecházejí ze systému přímého zálohování na řešení LAN-free Backup můžou navíc těžit ze systému sdílející páskové jednotky. Podniky, které přecházejí ze zálohovacího systému po LAN na LAN-free Backup již většinou mají v koncepci funkci sdílení páskových jednotek. Součástí řešení je software, který umožňuje řídit a využívat sdílení páskových jednotek.

Výhody SAN v této infrastruktuře jak je uvádí EMC společnost (9) jsou: a)

Průchodnost Fibre Channel, spolehlivost a možnost přenosu dat na větší vzdálenost

b)

Méně procesů a méně zahlcení systému

c)

Pro přenos dat se nepoužívá LAN

d)

Eliminuje se nebo redukuje se počet dedikovaných serverů

e)

Zvyšuje se rychlost zálohování a obnovy dat

a) Fibre Channel Výkonnost Fibre Channelu umožňuje zálohovacím aplikacím přenos dat rychlostí, kterou vyžadují zálohovací okna v současné době. Spolehlivost přenosu dat Fibre Channelem na větší vzdálenost umožňuje spravovat centralizovanou architekturu podnikům s geograficky vzdálenými lokalitami. LAN-free Backup umožňuje vytvořit řešení, které poskytuje možnost centralizace dat a sdílení páskových jednotek i když je provozní rychlost na úrovni řešení systému přímého zálohování.

b) Méně procesů a méně zahlcení systému LAN-free Backup zahrnuje dva kroky při zálohování 1.

Klient načte data z disku

2.

Klient zapíše data na pásku.

17

Centralizovaný zálohovací systém vyžaduje kroky čtyři. Redukce potřebných operací k přenosu dat taktéž redukuje zátěž CPU, jejich počet a paměťové zdroje, tudíž redukuje systémové nároky na zálohování. Protože se obnova dat drží stejných kroků, ale v opačném pořadí, bude tento proces tedy rychlejší s nižšími nároky na zdroje.

c) Pro přenos dat se nepoužívá LAN S využitím technologie SAN umožníme páskovým knihovnám pracovat na plný výkon. Snížením zatížení sítě, budou také uvolněny kapacity CPU a pamětí, protože data nemusí být formátována pro přenos po síti a síťové protokoly nemusí být řízeny zálohovacím systémem. Výkonnost ostatních systémů se zlepší, protože se na LAN zredukuje provoz o zálohovací procesy.

d) Eliminuje se nebo redukuje počet dedikovaných serverů SAN eliminuje nebo redukuje počet dedikovaných serverů. Potřeba CPU kapacity pro zálohování je přímo související s počtem kroků potřebných k záloze dat. S vypuštěním dvou kroků je spotřeba CPU výkonu nižší. Organizace, které přecházejí z centralizovaného zálohovacího systému na LAN-free řešení mají dvě možnosti. Snížit počet dedikovaných serverů nebo snížit výkonost serverů (downgrade) kvůli přebytku CPU výkonu.

e) Zlepšení výkonnosti zálohování a obnovy dat Již zmíněné snížení počtu kroků při zálohování, ovlivňuje také počet kroků při obnově dat. Kapacita sítě je posílena Fibre Channelem, což je rychlejší a spolehlivější. Tím se eliminuje i možnost přetížení sítě. Toto jsou faktory, které zlepšují výkonnost zálohování i obnovy dat (9).

18

1.1.4 Bezserverové zálohování Tento způsob zálohování využívá SAN pro přenos dat z diskového pole na páskovou jednotku nebo z diskového pole na diskové zálohovací zařízení. Nazýváme ho Bezserverovým zálohováním (někdy mluvíme taky o Server-free Backupu), protože klient (zálohovaný server) je nezávislý na serverových zdrojích nebo na kapacitě sítě pro přenos zálohovaných dat. Serverless Backup je dalším vývojovým krokem po LAN-free Backupu. Bezserverové zálohování využívá funkcionalitu kopírovacích a replikovacích služeb třetích stran, které umožňují kopírovat data mezi body v SAN. Zařízení, které vykonává kopírovací služby třetích stran je možné pojmenovat i jako kopírovací nástroj. Kopírovací úkol je spuštěn a kontrolován klientem (zálohovaným serverem), který instruuje kopírovací nástroj ke kopírování specifického objemu bloků dat ze zdrojového zařízení na cílové zařízení. Kopírovací nástroj pak zkopíruje data blok po bloku až do kompletního zazálohování. Celý proces probíhá uvnitř SAN infrastruktury bez využití jiných zdrojů.

Typický proces zálohování bezserverového zálohování: 1.

Zálohovací server vyvolá proces zálohování u zálohovaného klienta

2.

Pokud je v řešení použito páskové úložiště dat, zálohovací server přidělí páskovou jednotku zálohovanému klientovi

3.

Zálohovací server instruuje robota páskové knihovny o vložení pásky do přidělené páskové mechaniky

4.

Zálohovací server pošle zprávu zálohovanému klientovi, která pásková mechanika se může použít

5.

Zálohovaný klient určí, které soubory je potřeba zálohovat

6.

Zálohovaný klient instruuje kopírovací nástroj, že má kopírovat data, blok po bloku z datového úložiště přímo přes SAN na páskovou jednotku

7.

Jakmile je zálohování úplné, zálohovaný klient pošle zálohovacímu serveru metadata, která obsahují to, co bylo zálohováno a na které pásce daná zálohovaná data jsou

8.

Zálohovací server uloží metadata na disk

19

Vůči předešlým řešením, přináší bezserverové zálohování několik výhod: 

Plně využívá technologie Fibre Channel (rychlost, spolehlivost, možnost přenosu dat na větší vzdálenost).



Nejsou využívané žádné host zdroje pro přenos dat. Data jsou zálohována vně host CPU, zdroje klienta nejsou zatěžovány. Velké organizace můžou vidět značné úspory na zátěži CPU během zálohování.



Redukuje se vliv na aplikace organizací.



Není použita LAN pro přenos dat a tím se odstraní síťové problémy. SAN umožňuje páskovým knihovnám pracovat na plný výkon. Snížením zátěže na síti budou taky CPU a kapacita pamětí uvolněny, protože data nemusí být formátována pro přenos po síti a síťové protokoly nemusí být řízeny zálohovacím systémem.



Zlepšení výkonnosti zálohování a obnovy dat. Tato architektura je navržena tak, aby udržela co nejvyšší průtok dat směrem k páskovým zařízením, takže pracuje na maximální výkon.



Zlepšení výkonnosti je způsobeno redukcí procesních kroků a využitím připojení přes Fibre Channel (9).

20

2. Deduplikační technologie zálohování dat V dnešní době je nárůst dat enormní. Telefonní hovory, SMS zprávy, hudba, filmy, dokumenty, fotky, podnikové informační systémy, elektronické bankovnictví, oběh dokumentů... to vše je v digitální podobě, to vše jsou data uložená na serverech počítačích, pracovních stanicích. Všechny tato data je potřeba zálohovat. V předchozí kapitole byly popsány tradiční způsoby zálohování. Vzhledem k tempu růstu objemu dat ve společnostech na celém světě se tato řešení stávají nedostačujícími. Čím dál tím víc je nutné řešit délku zálohovacích oken (tj. čas, který je nutný pro zálohování systému), které se s nárůstem objemu dat zvětšují a negativně ovlivňují zatížení sítě. Síť je primárně využívána pro přenos dat. Pokud se zálohovací okno prodlouží, zákonitě se musí zpomalit rychlost odezvy aplikací z důvodu zahlcení kapacity sítě. Často se proto volí kompromisy. Aby se uvolnilo zatížení sítě pro běžný provoz, zkrátí se zálohovací okno, ale je zde riziko, že se nestihnou zazálohovat všechna data, čímž je ohrožena jejich bezpečnost. Pokud se zvolí druhá možnost a zálohovací okno se prodlouží a „zasáhne“ do provozní doby, je síť, vzhledem k objemu přenášených dat, pomalejší, odezva aplikací delší a produktivita práce nižší. Ani jedno z těchto řešení nepřináší společnosti užitek. Administrace takového systému je náročná finančně, časově i personálně. A požadovaná kapacita úložného prostoru stále narůstá. Daný problém je možné řešit nárůstem výkonu, rychlosti, kapacity zálohovacího systému, ale tyto možnosti jsou omezené. Pojem zálohování a důvody, proč firmy zálohují svoje data, jsme již popsali. Teď se podívejme na samotná zálohovaná data. Tradičním způsobem se periodicky kopírují data na datové úložiště. Nejprve plné zálohy (full backup neboli iniciální záloha) jsou průběžně doplňovány přírůstkovými zálohami, tzn. novými nebo změněnými soubory (incremental backup). Přírůstkové zálohy se dělají denně, plné zálohy týdně. Některá prostředí (např. databáze) se zálohují plnými zálohami každý den. Tím periodicky vznikají nová a nová duplicitní data, tedy zbytečně zálohovaná data. Inteligentní deduplikační systémy řeší tuto problematiku duplicitních dat v zálohování. Můžeme říct, že zálohují jen unikátní data. Všechna data mají jen jednu kopii.

21

2.1. Parametry deduplikací Deduplikační systémy jsou inteligentní zálohovací systémy, které zálohují jen jedinečná, unikátní data. Tím snižují objem zálohovaných dat, výrazně šetří kapacitu zálohovacích zařízení. Přenos menšího objemu dat po síti, snižuje její zatížení. Menší objem záloh zkracuje čas potřebný k zazálohování systémů (délku zálohovacího okna). V následující části jsou popsány parametry deduplikačních systémů a rozdíly mezi nimi. Jsou přiblíženy technologie, kterými disponují tyto systémy, jak fungují a co deduplikační technologie přináší oproti klasickým způsobům zálohování.

2.1.1 Soubor vs část souboru (File vs subfile) Pro vysvětlení rozdílu mezi deduplikací na úrovni souboru vs části souboru uveďme příklad: Ve firmách se často stává, že se používají šablony na různé dokumenty: prezentace, faktury, nabídky, kalkulace... Můžeme říct, že se většinou jedná o tentýž dokument, ve kterém jsou pozměněny jen části dat (přidané odstavce, změna jména, odstranění položky...). V případě klasického zálohování by systém při každé záloze zazálohoval daný dokument u každého uživatele znovu jako nový soubor. Na úrovni souborové deduplikace se však každý změněný dokument či soubor, zálohuje jako jedinečný (nový přírůstek), tudíž celý. Tak vzniká velké množství duplicit, protože deduplikační systém nezachytí změny v již existujícím souboru. Deduplikace na úrovni části souboru se v první záloze zkopíruje celý soubor a v každé další jen změna, která se v daném dokumentu odehrála. Pokud se například v již existující prezentaci, změní datum, jméno prezentátora, doplní stránka nebo odstavec, v záloze se promítnou jen tyto změny.

2.1.2 Fixní délka bloku vs variabilní délka bloku V případě deduplikace na úrovni části souboru můžeme dále mluvit o technologii, která rozděluje soubory na bloky (části) a dále s nimi pracuje. Při první záloze si deduplikační systém rozdělí zálohované soubory na bloky dat a pokud v druhé a dalších

22

zálohách zjistí, že byly soubory změněné, zálohuje jen bloky dat, kterých se změna týká, tudíž jsou pro systém nové. Toto rozdělování zálohovaného souboru na části se může dít dvěmi způsoby. a) dělení na části s tzv. fixním blokem - tj. soubor se dělí na části se stejnou velikostí b) dělení na části s tzv. variabilním blokem - tj. na části s nestejnou velikostí. Tato velikost se dokáže inteligentně přizpůsobit rozdělení bloků s ohledem na již existující dělení z předchozích záloh, což umožňuje nalézt více stejných bloků dat napříč historií záloh. Deduplikační systém využívající variabilní délku bloku je tedy efektivnější v deduplikaci, což se projevuje vyšším deduplikačním poměrem (viz. kapitola „Deduplikační poměr“ 2.1.5). Na obrázku č. 6 je znázorněn rozdíl mezi deduplikačním systémem s fixní délkou bloku a variabilní délkou bloku. U příkladu a) systém neidentifikoval změny v souboru, které byly provedeny, a tím vznikli „nové“ bloky dat (E,F,G,H). Na rozdíl od případu b), kde systém tyto změny rozeznává díky variabilní délce bloku a vznikl jen jeden „nový“ blok (E).

Obrázek č.6: Fixní vs. variabilní délka bloku Zdroj: autor

23

2.1.3 Deduplikace na zdroji vs na cíli (source vs target) Deduplikace na cíli probíhá za zálohovacím serverem (server, který řídí zálohovací proces a zapisuje na zálohovací zařízení), tj. na vlastním deduplikačním zálohovacím zařízení. Všechna data se musí přenést ze zálohovaných klientů přes síť na zálohovací server a dál na zálohovací datové úložiště kde jsou deduplikována. Tento způsob deduplikace je znázorněn na obrázku č. 7.

Obrázek č. 7: Deduplikace na cíli Zdroj: autor

Deduplikace na zdroji proběhne již na zálohovaných klientech a deduplikovaná data se přenesou přes síť na zálohovací server a uloží se na zálohovací datové úložiště (obrázek č. 8). U tohoto systému se značně redukuje nejen kapacita zálohovacího úložiště (datového úložiště), což předpokládáme u každého deduplikačního zálohovacího zařízení, ale i objem dat, který je přes síť přenášen je taktéž značně redukován (až o 99%). To má za následek mnohem nižší zatížení sítě. Dalším výrazným efektem je zkrácení zálohovacího okna.

Obrázek č.8: Deduplikace na zdroji Zdroj: autor

24

2.1.4 Globální deduplikace Doposud jsme vysvětlovali, jak funguje deduplikce v rámci jednoho klienta. Převážná většina organizací však má desítky klientů (zálohovaných serverů), některé až stovky. Technologie, která umožňuje deduplikaci napříč všemi těmito klienty se označuje jako globální deduplikace. Je to deduplikace napříč všemi zálohovanými klienty, nezávislá na operačních systémech a aplikacích, která zálohovaná data vytvořila. Obrazně řečeno, zálohovací systém umí rozeznat a odstranit stejné bloky dat, vyskytující se například ve fotce modré oblohy na jednom klientovi, oproti faktuře zanesené v SAPu na jiném klientovi a oproti emailům na Vašem mail serveru. Odstraněné bloky jsou nahrazeny pointerem, který poukazuje na již uložený (zazálohovaný) stavební blok. Lokální deduplikace je deduplikace napříč všemi soubory v rámci jednoho zálohovaného klienta (pracovní stanice, počítač). Globální deduplikace, kterou jsme popsali výše, deduplikuje data napříč všemi soubory a napříč všemi zálohovanými klienty. S řešením globální deduplikace výrazně roste deduplikační poměr viz kapitola 2.3. Na obrázku č.9 je znázorněna globální deduplikace napříč všemi klienty nezávisle na geografické vzdálenosti poboček a nezávisle na aplikacích, které vytvořila data.

Obrázek č.9: Globální deduplikace v zálohování Zdroj: autor

25

2.1.5 Deduplikační poměr (Deduplication ratio) Jedná se o poměr součtu objemů záloh klasického zálohovacího systému a součtu objemů záloh deduplikační technologie, přičemž se jedná o stejný vzorek dat. Zjednodušeně řečeno, je to poměr zálohovaného objemu dat před deduplikací a po deduplikaci.

Obrázek č.10: Deduplikační poměr vs úspora úložného prostoru Zdroj: (10) EMC Corporation. Setting the Table for Next Generation Data Protection 2.0 page 1

Obrázek č.10 zobrazuje velikost úspory místa na zálohovacím úložišti v závislosti na rostoucím deduplikačním poměru. Například při deduplikačním poměru 2:1 šetří uživatel 50% úložního prostoru. Pokud tento údaj srovnáme s deduplikačním poměrem pět krát vyšším tedy 10:1, šetření na úložném zařízení je až 90% úložného prostoru, což je dramatická úspora. Pokud je však deduplikační poměr dvojnásobný, t.j. 20:1 šetří uživatel pouze o 5% úložního prostoru více a to není velký rozdíl proti předchozímu poměru. Parametry, které ovlivňují deduplikační poměr: 

Typ zálohovaných dat, které mohou být například: - Databáze - Souborové systémy - Multimediální data - VMware či jiné virtualizované prostředí 26



Retenční období (období po, které jsou udržovány zálohy). Čím delší retenční období je, tím je deduplikační poměr vyšší.



Frekvence změny dat (menší počet změn v datech vede k vyššímu deduplikačnímu poměru a naopak)



Kryptovaná data a již komprimovaná data nejsou vhodná pro deduplikaci.

Zmiňované parametry deduplikací uvádí ve svých zdrojích i EMC (5).

27

2.2. Řešení zálohování EMC AVAMAR Avamar je řešení pro zálohování dat od společnosti EMC, které je unikátní tím, že nabízí deduplikační systém na zdroji (klientovi). Deduplikace se děje na úrovni dělení souboru s variabilní délkou bloku. Avamar podporuje funkcionalitu globální deduplikace. Jedná se o zálohovací software s datovým úložištěm. Avamar existuje ve dvou provedeních. Jako fyzické zálohovací zařízení (Avamar Data Store) a jako řešení implementovatelné do virtuálního prostředí VMware (Avamar Virtual Edition). Avamar identifikuje nadbytečné segmenty dat přímo na zdroji tj. dříve, než jsou přenášeny přes síť na zálohovací zařízení. Tím šetří kapacitu sítě, která může být využita pro přenos jiných dat. To může být například vhodné pro prostředí s větším počtem geograficky vzdálených lokalit nebo velkým počtem uživatelských stanic. Tím, že zálohuje jen unikátní blok souboru v rámci celého systému (přes všechny klienty), Avamar výrazně pomáhá snížit kapacitu zálohovacího systému a nabízí možnost nahradit ho kapacitně nenáročnějším řešením.

2.2.1 Princip fungování systému AVAMAR Klienti jsou pro potřeby deduplikace vybaveni deduplikačními algoritmy. Na začátku zálohovaní jsou do RAM paměti klienta nahrány dva typy cache (vyrovnávací paměti). První vyrovnávací paměť se nazývá file cache (souborová vyrovnávací paměť). V souborové vyrovnávací paměti jsou uloženy 20-bytové hashe (otisky) souborových atributů (hlaviček), které označují místa uložení, jména souboru a velikost souboru. Tato souborová vyrovnávací paměť je určena pro rychlou identifikaci, který soubor byl již AVAMARem zálohován. Tohle je důvod, proč je AVAMAR při zálohování souborových systémů velice rychlý a dokáže odfiltrovat až 98% souborů, které již byly zálohovány. U zálohování databází se souborová vyrovnávací paměť neuplatňuje, protože v databázích se jeví všechny soubory každý den změněné. Druhá vyrovnávací paměť je hash cache. Hash cache ukládá hashe (otisky) bloků dat, které již byly zálohovány a slouží pro rychlou identifikaci těchto bloků dat. Je důležitá právě v případě zálohování databází a změněných souborů. 28

Pro jednodušší představu si uveďme příklady. V prostředí souborových systémů je typické následovné chování. Řekněme, že systém obsahuje 1 TB file systémových dat. Po spuštění zálohovacího procesu se při druhé a každé další záloze pomocí souborové vyrovnávací paměti odfiltruje v průměru 98% dat (tj. 980 GB), protože jsou identifikována, jako již zálohována a není potřeba je zálohovat. Pouze 20 GB je rozdělených na datové bloky. Ty jsou nahashovány, hashe porovnány s obsahem hashe cache a pouze 0,3% (3 GB) jsou poslány na AVAMAR server, jako unikátní bloky dat v rámci celého systému. V Databázovém řešení využití souborové vyrovnávací paměti nemá svoje opodstatnění. Neodfiltrují se žádné data (0%), protože se všechny soubory změní. 100% dat je rozdělených na bloky a jsou nahashovány, hashe porovnány a v průměru pouze 3% tj. 3 GB (záleží na změnovosti databází) jsou poslána na AVAMAR sever jako unikátní. Velikost

vyrovnávací

paměti

je

možné

manuálně

nastavovat

a

proto

je doporučováno zvážit u implementace deduplikačního řešení AVAMAR o jaký typ dat se bude jednat a dle toho přizpůsobit velikost vyrovnávacích pamětí (8).

2.2.2 Tři edice softwaru AVAMAR Tak jako každé zálohovací řešení, tak i AVAMAR je postaven na technologii klient – server, t.j. má svoji klientskou a serverovou část. Pod pojmem klient rozumíme zálohovaný server, PC nebo notebook a pod pojmem server rozumíme zařízení, které řídí zálohování, ukládá metadata a zapisuje data na zálohovací úložiště. AVAMAR existuje ve třech provedeních: a) AVAMAR Virtual Edition b) AVAMAR Single Node c) AVAMAR Multi Node

Ad. a) AVAMAR Virtual Edition Tato edice umožňuje instalovat deduplikační technologii Avamar do virtuálního serveru v prostředí VMware ESX (viz. obrázek č.11). AVAMAR virtuální edice podporuje 0,5 / 1 / 2 TB deduplikované zálohovací kapacity. Pokud již v IT řešení existuje VMware

29

prostředí, je možné ho využít a tím snížit náklady na infrastrukturu. Toto řešení je chápáno jako jednoduché řešení pro malé firmy, případně pro pobočky větších firem.

Obrázek č.11: AVAMAR Virtual Edition v již existujícím VMware prostředí Zdroj: autor

Ad. b) AVAMAR Single Node

Jde o předinstalovaný a předkonfigurovaný hardware (2U Rack server s interními disky) a software (AVAMAR) dodávaný zákazníkům pro rychlou implementaci. AVAMAR Single Node je možné si implementovat i na certifikované konfiguraci výrobců serverů s OS Linux Red Heat Enterprise. Single Node slouží jak pro běh AVAMAR serveru, tak pro ukládání deduplikovaných dat. V současné době existují varianty o kapacitách 1 / 2 / 3 / 7,8 TB deduplikovaných dat.

Ad. c) AVAMAR Multi Node V případě požadavku na vyšší kapacitu nebo vyšší zabezpečení se doporučuje použití AVAMAR Multi Node řešení. Jedná se o GRID technologii, která umožňuje doplnění dalšího nodu po dosažení kapacity stávajícího deduplikačního řešení. Jednoduše řešeno, pokud by deduplikační systém dosáhl naplnění své zálohovací kapacity, grid technologie umožňuje „doplnění“ dalšího nodu a tím se kapacita systému zvýší o kapacitu doplněného nodu. Jde o vrstvení jednotlivých Single nodů (uzlů), doplněných o řídící Utility node a Spare node. Řídící Utility node má za úkol řídit proces zálohování a Spare

30

node slouží jako náhradní v případě poruchy. Pokud dojde k havárii jednoho z uzlů, jsou na něj přepočítaná data z porušeného (viz. obrázek č. 12).

Obrázek č.12: Avamar server Multi node Zdroj: (5) EMC Corporation. Efficient Data Protection with EMC AVAMAR Global Deduplication Software page 15

2.2.3 Ochrana RAIN technologií (Redundant Array of Independent Nodes) Když tradiční zálohovací řešení selže, společnosti jsou potenciálně vystaveny ztrátě dat. AVAMAR přišel na trh s RAIN technologií (U.S. Patent: 6,826,711). Jde o řešení zabezpečující systém před selháním přes všechny uzly v AVAMAR Grid řešení, které je popsáno výše. AVAMAR může fungovat dál i v případě výpadku nebo při ztrátě dostupnosti jednoho nodu, protože data uložena na kterémkoliv uzlu můžou být rekonstruována z ostatních nodů, protože jsou jednotlivá data uložena redundantně napříč nody. Navíc k ochraně systému AVAMAR vytváří dvakrát denně checkpointy. Ty umožňují chránit systém před provozními problémy, jako například pokus o zazálohování 31

klienta s větší zálohovanou kapacitou než je kapacita zálohovacího prostoru na systému, nebo nahodile smazání klienta a jeho zálohy. Jsou to body (značky), ke kterým je možné se bezpečně vrátit „v čase“, pokud dojde k havárii systému nebo ke ztrátě dat. Na obrázku č. 12 je zobrazen systém AVAMAR Multi node s RAIN ochranou. V případě výpadku jednoho disku je systém chráněn RAID (Redundant Array of Independent Disks) ochranou. RAID je technologii zabezpečující zvýšení kapacity úložného systému, výkonnosti systému a zvýšení ochrany dat. Jde o seskupení pevných disků do jednoho diskového pole. Vůči systému vystupuje jako jeden velký rychlý disk. RAID technologií je dosažena vysoká stabilita systému. Data jsou na jednotlivé disky zapisována a řazena dle typu diskového pole. Pokud dojde k poruše nebo ztrátě jednoho z disků data z porušeného disku můžou být rekonstruována z ostatních disků a systém funguje dál (5). V případě výpadku více disků, či celého nodu je systém chráněn RAIN ochranou. Jednoduše řečeno RAIN je RAID přes všechny nody. V tomto případě by byla data přepočítána na SPARE node (viz. obrázek č. 12). Nejmenší konfigurace AVAMAR Multi node s RAIN ochranou se skládá ze 3 datových nodů stejné kapacity, 1 Spare nodu a 1 Utility nodu.

2.2.4 Replikace AVAMAR řešení Jednou z dalších výhod řešení AVAMAR je možná replikace mezi AVAMAR servery. Replikace je přenášení dat mezi dvěma a vícero servery tak, aby na každém z nich byla stejná data. Tato funkcionalita je automatickou součástí AVAMARu. Řešení Virtual Edition, Single Node a Multi Node je možné libovolným způsobem mezi sebou replikovat, což umožňuje vytvořit libovolné topologie zálohovacích řešení. Při replikaci se replikují pouze unikátní, deduplikovaná data. Je možné replikovat buď celý datový objem AVAMAR severu nebo jen vybrané zálohy.

32

3. Měření AVAMAR řešení v různých prostředích Měření (evaluace prostředí) se provádí za účelem odhadu velikosti řešení pro nasazení deduplikačního systému na produkční řešení. Provádí se na vybraném vzorku dat na 1TB demo zařízení, které má předinstalované AVAMAR prostředí. V této práci jsou evaluována tři různá prostředí VMware (data souborového serveru), prostředí SAP nad Oracle databází a prostředí Exchange. Příklady logů AVAMAR serveru jsou v přílohách 1 - 3.

3.1. AVAMAR v prostředí VMware (virtuální prostředí) Pro prostředí VMware (data souborového serveru) budou popsány tři případy měření. U společnosti A (viz. kapitola 3.1.1.) půjde o prostředí s jedním virtuálním serverem. V případě společnosti B (viz. kapitola 3.1.2.) se bude jednat o prostředí s větším počtem virtuálních serverů a u společnosti C (viz. kapitola 3.4.) bude na základě měření navržena velikost řešení deduplikačního systému AVAMAR.

3.1.1 Zálohování VMware prostředí ve společnosti A Jedná se o zálohování jednoho virtuálního serveru (data souborového charakteru) o velikosti objemu dat 16 GB po dobu 10 dnů. V tabulce č. 1. jsou zobrazeny výsledky tohoto měření včetně vývoje deduplikačního poměru po jednotlivých dnech. Všechny zálohy jsou zálohy plné. První řádek reprezentuje první plnou zálohu prostředí, kdy se prázdný AVAMAR server začíná plnit unikátními daty. Již na této první záloze vidíme úbytek objemu dat o 41%. V druhé a každé další záloze (které jsou také plné) je úbytek objemu zálohovaných dat ještě dramatičtější, zálohuje se pouze 1,51% dat při udržení plné zálohy každý den. Pro názornější představu popišme případ pětidenního retenčního období. U klasického zálohování bychom potřebovali 81 GB úložného prostoru na zálohovacím zařízení, zatím co při použití deduplikační technologie jen 11 GB. Když prodloužíme retenční období na dvojnásobek tj. na 10 dnů, nárok na úložný prostor u klasického zálohování vzroste také na dvojnásobek, tj. na 171 GB, ale v případě deduplikačního

33

prostředí jde pouze o nárůst pouze o 10%, což na kapacitu úložného prostoru nemá významný vliv. Uvedený příklad je znázorněn na grafu č. 1. Každý den se v průměru chrání 17,19 GB dat (průměr chráněných záloh 2. - 10. záloha), přičemž je průměrně zazálohováno jen 0,26 GB dat (průměr objemu unikátních deduplikovaných dat 2. – 10. záloha) deduplikované kapacity což činí jen 1,51% průměrné původní kapacity (stejný objem dat jaký by bylo nutné zálohovat klasickým zálohovacím systémem).

Tabulka č. 1: Výsledky měření VMware prostředí (data souborového charakteru) ve společnosti A Zdroj: autor

Graf č. 1 : Objem dat v čase v prostředí VMware (data souborového charakteru) společnosti A Zdroj: autor

34

Graf č. 2:

Závislost deduplikačního poměru v čase v prostředí VMware (data souborového charakteru) společnosti A

Zdroj: autor

Graf č. 2 znázorňuje vývoj deduplikačního poměru v závislosti na délce retenčního období evaluovaného prostředí. Čím je retenční období delší, tím vyšší je deduplikační poměr.

3.1.2 Zálohování VMware prostředí ve společnosti B Jedná se o zálohování prostředí s více virtuálními servery (opět data souborového charakteru) o celkové velikosti objemu dat 36,1 GB po dobu 13 dnů. Po prvním dnu bylo z produkčního prostředí odebráno 2/3 dat a následně bylo prostředí zálohováno po dalších 12 dnů, což nemá vliv na deduplikované úložiště, protože tato data jsou a musí být stále v záloze. V tabulce č. 2 jsou zobrazeny výsledky tohoto měření po jednotlivých dnech. Při první záloze byla deduplikace účinnější než v případě společnosti A, protože zde jde o prostředí se čtyřmi virtuálními servery, které jsou instalovány z totožné image. Projevilo se to ve vyšším deduplikačním poměru první zálohy (1: 6,56). Ostatní zálohy jsou v průměru 2,94%, což je způsobeno vyšší změnovostí dat na serverech.

35

Tabulka č. 2: Výsledky měření VMware (data souborového charakteru) prostředí ve společnosti B Zdroj: autor

Graf č.3: Objem dat v čase prostředí VMware (data souborového charakteru) společnosti B Zdroj: autor

36

Graf č. 4:

Závislost deduplikačního poměru v čase prostředí VMware (data souborového charakteru) společnosti B

Zdroj: autor

3.2. AVAMAR v prostředí SAP nad databází Oracle Jedná se o zálohování prostředí o celkové velikosti objemu dat 100,2 GB po dobu 11 dnů. Po prvním dnu se díky deduplikační technologii snížil objem dat na zálohovacím systému o 2/3 při plné záloze. Je to výrazný rozdíl oproti VMware prostředí, které jsou popsány v předešlé části. Průměrný objem deduplikovaných dat je o 6,78% což znamená větší změnovost dat v databázi a odpovídá to tradičnímu chování AVAMARu. V tabulce č. 3 jsou zobrazeny výsledky celého měření po jednotlivých dnech.

37

Tabulka č. 3:Výsledky měření nasazení AVAMAR řešení v prostředí SAP nad databází Oracle Zdroj: autor

Graf č. 5: Objem dat v čase s použitím deduplikačního řešení AVAMAR v prostředí SAP nad databází Oracle Zdroj: autor

38

Graf č. 6: Závislost deduplikačního poměru v čase s řešením AVAMAR v prostředí SAP nad databází Oracle Zdroj: autor

3.3. AVAMAR v prostředí Exchange Jedná se o zálohování prostředí o celkové velikosti objemu dat 11,27 GB po dobu 11 dnů. Konkrétně jde o PST soubory. První den byla deduplikace manuálně přerušena, což znamená, že systém nestihl deduplikovat všechna data a projevilo se to na výsledcích v druhém dnu měření, kdy systém musel deduplikovat ještě velké množství „nezpracovaných“ dat z prvního dne. Z výsledků měření je vidět značný rozdíl mezi objemem zálohovaných dat v případě klasického zálohování (154,37 GB) oproti objemu deduplikovaných dat (8,61 GB), což znamená 94,4% redukci objemu dat po 11 dnech měření. V tabulce č. 4 jsou zobrazeny výsledky celého měření po jednotlivých dnech.

39

Tabulka č. 4: Výsledky měření řešení AVAMAR v prostředí Exchange (PST soubory) Zdroj: autor

Graf č. 7: Objem dat v čase řešení VAMAR v prostředí Exchange (PST soubory) Zdroj: autor

40

Graf č. 8: Závislost deduplikačního poměru v čase řešení AVAMAR v prostředí Exchange (PST soubory) Zdroj: autor

3.4. Komplexní VMware prostředí ve společnosti C a návrh řešení V této části je popsán finální výstup zálohování AVAMAR nasazeného v rámci evaluace pro zálohování farmy VMware prostředí. Evaluace byla provedena na testovací VMware farmě. Jednalo se o 3 x server HP DL580G5. Farma byla připojena prostřednictvím SAN na dvě disková pole, každý v jiné geografické lokalitě. LAN konektivita - 4 x 1000Base - T ethernet. Na farmě byl VMware vSphere 4.0, update pack 1.

Seznam zálohovaných serverů v evaluovaném prostředí Avamar klient a Avamar Virtual Edition byly nasazeny na testovací prostředí 52 virtuálních serverů. Seznam virtuálních serverů je v tabulce č. 5.

41

Tabulka č. 5: Seznam virtuálních serverů Zdroj: autor

Výsledky měření evaluovaného prostředí ve společnosti C. Celková kapacita dat na produkčním úložišti byla 1070GB. Průměrný počet denních plných záloh byl cca 21 per server. Velikost první zálohy po nasazení řešení AVAMAR byla 120 GB a průměrný denní přírůstek byl následně 11,23 GB. Celkový deduplikační poměr je tedy takřka 112 : 1. Průměrná denní změnovost byla 1,73%. V tabulce č. 6 jsou uvedeny výsledky měření na testovací farmě evaluovaného prostředí.

42

Tabulka č.6: Výsledky měření VMware prostředí ve společnosti C Zdroj: autor

Návrh finálního systému Pro návrh cílového řešení přicházejí do úvahy 2 varianty. Obě varianty počítají s farmou, která bude desetinásobně větší než testovacího prostředí, tj. na produkčním prostředí bude celkem 10700GB dat. Pro variantu 1 je brána do úvahy denní změnovost dat shodná s testovacím prostředím, tj. 112,3 GB. Ve druhé variantě se předpokládá denní změnovost navýšenou o 100%, tj. na 224,6GB. Kvůli zachování vysoké dostupnosti a replikaci zálohovacího systému je uvažováno o následujícím návrhu: 2 x AVAMAR Multi node přičemž každý z nich bude kapacitně pokrývat 6TB (3 x 2TB AVAMAR datový node). Přestože produkčnímu prostředí by kapacitně stačil 2 TB AVAMAR Single node vzhledem k povaze společnosti a předpokladu růstu objemu dat se musí uvažovat o snadné

43

rozšiřitelnosti kapacity zálohovacího systému a AVAMAR Multi node takovéto řešení nabízí. Toto řešení obsahuje Spare node a Utility node z důvodu RAIN ochrany. V řešení je uvažováno o dvou geografických lokalitách a replikaci AVAMAR řešení z důvodu DR (Disaster Recovery).

44

Závěr Tato bakalářská práce se zabývá porovnáním klasických zálohovacích technologií s novými trendy v zálohování. Tyto trendy jsou především reprezentovány odklonem od technologie zálohování na páskové jednotky k uplatňování technologie zálohování na disk (backup to disk), což dále umožňuje využití deduplikačních technologií, které jsou obzvláště vhodné v zálohovacích systémech. V práci byl popsán obecný pohled na deduplikační technologie a jejich kategorizace. Dále byl detailně vysvětlen princip fungování zálohovacího deduplikačního řešení EMC Avamar, které patří mezi přední řešení tohoto druhu na trhu. Společnost EMC je celosvětově respektovaným dodavatelem systémů pro ukládání a zálohování dat. AVAMAR reprezentuje kategorii zálohování s deduplikací na klientovi, což umožňuje nejen snižování objemu zálohovaných dat, ale i zkracování zálohovacích oken. Tato práce se soustřeďuje pouze na měření parametru úspory objemu dat. Dalším zajímavým aspektem, který je možné sledovat u tohoto systému, je zkracování zálohovacích oken (doba provedení zálohy). V praktické části je prezentován efekt úspory místa s využitím deduplikační technologie Avamar v jednotlivých prostředích a srovnáván s klasickou zálohovací technologií. To je vyjádřeno deduplikačním poměrem. Z měření vyplývá, že deduplikační poměr závisí především na dvou faktorech. Prvním z nich je prostředí, ve kterém byla data produkována. Druhým je retenční období. Z grafů č. 2, 4, 6 a 8 je patrné, že čím je retenční období delší, tím vyšší je deduplikační poměr. Pro objektivní srovnání jednotlivých měřených prostředí bylo zvoleno období 10 dnů (viz. tabulka č.7). Z výsledků vyplývá, že všechna měřená prostředí jsou vhodná pro použití deduplikační technologie v zálohování. Úspora na zálohovacím prostoru byla 93% – 96%, což jsou výborné výsledky.

45

Sumarizace naměřených výsledků: Deduplikační poměr

Úspora zálohovacího prostoru v %

VMware

prostředí

(data

souborového

14 : 1

92,9%

souborového

16,5 : 1

93,9%

Prostředí SAP nad databází Oracle

27 : 1

96,3%

Prostředí Exchange (PST soubory)

16 : 1

93,8%

charakteru) ve společnosti A VMware

prostředí

(data

charakteru) ve společnosti B

Tabulka č. 7:

Deduplikační poměr a úspora zálohovacího prostoru jednotlivých měřených prostředí po 10 dnech

Zdroj: autor

V případě komplexního řešení VMware prostředí (52 virtuálních serverů) ve společnosti C, se díky globální deduplikaci, dosáhlo mnohem vyššího deduplikačního poměru 112 : 1, což je úspora až 99% zálohovacího prostoru. Tento výsledek je obdivuhodný. Na základě tohoto měření reprezentativního vzorku dat a na základě požadavků na rozšiřitelnost a bezpečnost řešení byla pro tuto společnost navržena konfigurace 2 x AVAMAR Multi node 6TB. Technologie deduplikace je jedním z nástrojů, jak úspěšně čelit exponenciálnímu růstu množství dat. Je to technologie, která v oblasti zálohování dat, již začala mít svoje opodstatněné místo a věřme, že to bude za pár let běžný pojem jako je dnes například virtualizace. Všechny cíle zadané v této bakalářské práci byly dosaženy a upřímně řečeno, výsledky měření jsou výborné až překvapivé.

46

Seznam použité literatury [1]

JUDD, Josch - KRUGER, Dan. Principles of SAN Design. First Edition. West Conhohocken, PA : Infinity Publishing, 2006. 509 s. ISBN 0741428245, ISBN 9780741428240

[2]

DRAHOVZAL, Marek – SÁDOVSKÝ, Adam. Fibre Channel. [s.l.], 22.10.2006. 15 s. Seminární práce. Česká zemědělská univerzita v Praze, Provozně ekonomická fakulta, Katedra informačního inženýrství, Počítačové síte. Dostupné na internet:

[3]

EMC Corporation. Backup and Recovery Fundamentals, Student Resource Guide [online].

July,

2007,

[cit.

2011-02-12].

Dostupné

na

internetu:



[4]

EMC Corporation. Data Sheet – EMC Avamar and VMware [online]. July, 2010, [cit. 2011-02-12]. Dostupné na internetu:

[5]

EMC Corporation. Efficient Data Protection with EMC Avamar Global Deduplication Software [online]. January, 2010, [cit. 2011-02-12]. Dostupné na internetu:

[6]

EMC Corporation. EMC Avamar Backup and Recovery for VMware Environments [online].

August,

2010,

[cit.

2011-02-12].

Dostupné

na

internetu:



47

[7]

EMC Corporation. EMC Avamar, Data Store Site Prep Technical Specifications, 300-007-104 A05 [online]. April 13, 2010, [cit. 2011-02-12]. Dostupné na internetu:

[8]

EMC Corporation. EMC AVAMAR 4.1 OPERATIONAL BEST PRACTICES, P/N 300007-035 REV A01 [online]. December 1, 2008, [cit. 2011-02-12]. Dostupné na internetu: < http://powerlink.emc.com:80/km/live1/en_US/Offering_Technical/Technical_Documentatio n/300-007035.pdf?mtcs=ZXZlbnRUeXBlPUttQ2xpY2tTZWFyY2hSZXN1bHRzRXZlbnQsZG9jdW1lbnRJZD0wOTAxN DA2NjgwM2JjYTUyLGRhdGFTb3VyY2U9RENUTV9lbl9VU18w>

[9]

EMC Corporation. EMC Networked Storage. Topology Guide, P/N 300-004-456 REV A42 [online]. February, 2010, [cit. 2011-02-12]. Dostupné na internetu: < http://powerlink.emc.com:80/km/live1/en_US/Offering_Technical/Technical_Documentation/300-004456.pdf?mtcs=ZXZlbnRUeXBlPUttQ2xpY2tTZWFyY2hSZXN1bHRzRXZlbnQsZG9jdW1lbnRJZD0wOTAxN DA2NjgwNTZlOTc5LGRhdGFTb3VyY2U9RENUTV9lbl9VU18w>

[10] EMC Corporation. Setting the Table for Next Generation Data Protection 2.0 [online].

January,

2011,

[cit.

2011-02-12].

Dostupné

na

internetu:



[11] GRANTZ, John F. - REINSEL, David - CHUTE, Christopher. An IDC White Paper sponsored by EMC, A Forecast of Worldwide Information Growth Through [online]. March,

2007,

[cit.

2011-02-12].

Dostupné



48

na

internetu:

Seznam použitých zkratek CPU

-

Central Processing Unit

ERP

-

Enterprise resource planning

FCoE

-

Fibre Channel over Ethernet

FCP

-

Fibre Channel Protocol

FTP

-

File Transfer Protocol

GB

-

Gigabyte

HBA

-

Host Bus Adapter

iSCSI

-

Internet Small Computer System Interface

LAN

-

Local Area Network

NAS

-

Network Attached Storage

NICs

-

Network Interface Cards

OS

-

Operating system

PC

-

Personal computer

RAID

-

Redundant Array of Independent Disks

RAIN

-

Redundant Array of Independent Nodes

RAM

-

Random-Access Memory

SAN

-

Storage Area Network

SCSI

-

Small Computer System Interface

TB

-

Terabyte

49

Seznam obrázků Obrázek č. 1:

Systém přímého zálohování

8

Obrázek č. 2:

Zálohovací systém po LAN

10

Obrázek č. 3:

Zálohovací systém po LAN rozšířený o separátní storage node

10

Obrázek č. 4:

Příklad topologie SAN

14

Obrázek č. 5:

Zálohovací systém bez LAN (LAN-free backup)

15

Obrázek č. 6:

Fixní vs. variabilní délka bloku

22

Obrázek č. 7:

Deduplikace na cíli

23

Obrázek č. 8:

Deduplikace na zdroji

23

Obrázek č. 9:

Globální deduplikace v zálohování

24

Obrázek č. 10: Deduplikační poměr vs úspora úložného prostoru

25

Obrázek č. 11: AVAMAR Virtual Edition

29

Obrázek č. 12: Avamar server Multi node

30

Seznam grafů Graf č. 1:

Objem dat v čase v prostředí VMware (data souborového charakteru) společnosti A

Graf č. 2:

33

Závislost deduplikačního poměru v čase v prostředí VMware (data souborového charakteru) společnosti A

Graf č. 3:

Objem dat v čase prostředí VMware (data souborového charakteru) společnosti B

Graf č. 4:

35

Závislost deduplikačního poměru v čase prostředí VMware (data souborového charakteru) společnosti B

Graf č. 5:

36

Objem dat v čase s použitím deduplikačního řešení AVAMAR v prostředí SAP nad databází Oracle

Graf č. 6:

34

37

Závislost deduplikačního poměru v čase s řešením AVAMAR v prostředí SAP nad databází Oracle

38

Graf č. 7:

Objem dat v čase řešení VAMAR v prostředí Exchange (PST soubory) 39

Graf č. 8:

Závislost deduplikačního poměru v čase řešení AVAMAR v prostředí Exchange (PST soubory)

40 50

Seznam tabulek Tabulka č. 1:

Výsledky měření VMware prostředí (data souborového charakteru) ve společnosti A

Tabulka č. 2:

33

Výsledky měření VMware (data souborového charakteru) prostředí ve společnosti B

Tabulka č. 3:

35

Výsledky měření nasazení AVAMAR řešení v prostředí SAP nad databází Oracle

Tabulka č. 4:

37

Výsledky měření řešení AVAMAR v prostředí Exchange (PST soubory)

39

Tabulka č. 5:

Seznam virtuálních serverů

41

Tabulka č. 6:

Výsledky měření VMware prostředí (data souborového charakteru) ve společnosti C

42

Seznam příloh Příloha č. 1:

Záznam logů VMware prostředí

50

Příloha č. 2:

Záznam logů prostředí SAP nad Oracle databází

51

Příloha č. 3:

Záznam logů prostředí Exchange

52

Příloha č. 4:

Výsledky měření VMware farmy

53

51

Příloha č. 1: Záznam logů VMware prostředí 2010-11-16 14:32:14 avtar Info <5156>: Backup #1 timestamp 2010-11-16 14:29:34, 42 files, 16.06 GB (42 files, 9.521 GB, 59.28% new) 2010-11-16 14:32:14 avtar Info <6083>: Backed-up 16.06 GB in 12.94 minutes: 74 GB/hour (195 files/hour) 2010-11-17 11:18:23 avtar Info <5156>: Backup #2 timestamp 2010-11-17 11:15:31, 42 files, 16.07 GB (42 files, 209.5 MB, 1.27% new) 2010-11-17 11:18:23 avtar Info <6083>: Backed-up 16.07 GB in 9.12 minutes: 106 GB/hour (276 files/hour) 2010-11-18 11:16:19 avtar Info <5156>: Backup #3 timestamp 2010-11-18 11:13:13, 42 files, 16.21 GB (42 files, 406.7 MB, 2.45% new) 2010-11-18 11:16:19 avtar Info <6083>: Backed-up 16.21 GB in 7.87 minutes: 124 GB/hour (320 files/hour) 2010-11-19 11:21:29 avtar Info <5156>: Backup #4 timestamp 2010-11-19 11:18:09, 42 files, 16.29 GB (42 files, 348.0 MB, 2.09% new) 2010-11-19 11:21:29 avtar Info <6083>: Backed-up 16.29 GB in 7.40 minutes: 132 GB/hour (341 files/hour) 2010-11-20 11:17:40 avtar Info <5156>: Backup #5 timestamp 2010-11-20 11:13:37, 42 files, 16.33 GB (42 files, 288.6 MB, 1.73% new) 2010-11-20 11:17:40 avtar Info <6083>: Backed-up 16.33 GB in 7.33 minutes: 134 GB/hour (344 files/hour) 2010-11-21 11:12:08 avtar Info <5156>: Backup #7 timestamp 2010-11-21 11:07:36, 42 files, 17.96 GB (42 files, 217.8 MB, 1.18% new) 2010-11-21 11:12:08 avtar Info <6083>: Backed-up 17.96 GB in 8.15 minutes: 132 GB/hour (309 files/hour) 2010-11-22 11:17:40 avtar Info <5156>: Backup #8 timestamp 2010-11-22 11:12:54, 42 files, 17.95 GB (42 files, 228.3 MB, 1.24% new) 2010-11-22 11:17:40 avtar Info <6083>: Backed-up 17.95 GB in 8.10 minutes: 133 GB/hour (311 files/hour) 2010-11-23 11:20:09 avtar Info <5156>: Backup #9 timestamp 2010-11-23 11:15:09, 42 files, 17.95 GB (42 files, 200.4 MB, 1.09% new) 2010-11-23 11:20:09 avtar Info <6083>: Backed-up 17.95 GB in 7.87 minutes: 137 GB/hour (320 files/hour) 2010-11-24 11:16:45 avtar Info <5156>: Backup #10 timestamp 2010-11-24 11:11:02, 42 files, 17.95 GB (42 files, 257.6 MB, 1.40% new) 2010-11-24 11:16:45 avtar Info <6083>: Backed-up 17.95 GB in 8.18 minutes: 132 GB/hour (308 files/hour) 2010-11-25 11:15:41 avtar Info <5156>: Backup #11 timestamp 2010-11-25 11:09:44, 42 files, 17.96 GB (42 files, 238.6 MB, 1.30% new) 2010-11-25 11:15:41 avtar Info <6083>: Backed-up 17.96 GB in 8.03 minutes: 134 GB/hour (314 files/hour)

52

Příloha č. 2: Záznam logů prostředí SAP nad Oracle databází 2011-01-09 13:57:13 avtar Info <5156>: Backup #1 timestamp 2011-01-09 13:54:44, 21 files, 100.2 GB (21 files, 32.85 GB, 32.79% new) 2011-01-10 21:55:30 avtar Info <5156>: Backup #4 timestamp 2011-01-10 21:52:57, 21 files, 100.2 GB (21 files, 208.2 MB, 0.20% new) 2011-01-11 21:19:56 avtar Info <5156>: Backup #11 timestamp 2011-01-11 21:17:20, 21 files, 100.2 GB (21 files, 167.6 MB, 0.16% new) 2011-01-12 21:14:36 avtar Info <5156>: Backup #18 timestamp 2011-01-12 21:11:57, 21 files, 100.2 GB (21 files, 405.2 MB, 0.39% new) 2011-01-13 21:33:56 avtar Info <5156>: Backup #25 timestamp 2011-01-13 21:31:14, 21 files, 100.2 GB (21 files, 610.1 MB, 0.59% new) 2011-01-14 21:26:36 avtar Info <5156>: Backup #32 timestamp 2011-01-12 21:24:47, 21 files, 100.2 GB (21 files, 475.2 MB, 0.43% new) 2011-01-15 21:20:28 avtar Info <5156>: Backup #38 timestamp 2011-01-12 21:18:28, 21 files, 100.2 GB (21 files, 534.2 MB, 0.49% new) 2011-01-16 21:49:36 avtar Info <5156>: Backup #41 timestamp 2011-01-12 21:46:42, 21 files, 100.2 GB (21 files, 613.2 MB, 0.59% new) 2011-01-17 21:19:34 avtar Info <5156>: Backup #47 timestamp 2011-01-11 21:17:36, 21 files, 100.2 GB (21 files, 557.6 MB, 0.48% new) 2011-01-18 21:26:20 avtar Info <5156>: Backup #52 timestamp 2011-01-11 21:23:54, 21 files, 100.2 GB (21 files, 450.6 MB, 0.40% new) 2011-01-19 21:19:30 avtar Info <5156>: Backup #4 timestamp 2011-01-10 21:16:33, 21 files, 100.2 GB (21 files, 418.3 MB, 0.39% new)

53

Příloha č. 3: Záznam logů prostředí Exchange 2010-11-19 11:31:00 avtar Info <5156>: PARTIAL Backup #1 timestamp 2010-11-19 11:27:40, 3,909 files, 11.27 GB (3,909 files, 6.894 GB, 61.18% new) 2010-11-19 11:31:00 avtar Info <6083>: Backed-up 11.27 GB in 22.12 minutes: 31 GB/hour (10,602 files/hour) 2010-11-20 11:41:25 avtar Info <5156>: Backup #2 timestamp 2010-11-20 11:38:04, 3,909 files, 14.18 GB (6 files, 1.658 GB, 11.70% new) 2010-11-20 11:41:25 avtar Info <6083>: Backed-up 14.18 GB in 9.51 minutes: 89 GB/hour (24,659 files/hour) 2010-11-21 11:50:51 avtar Info <5156>: Backup #3 timestamp 2010-11-21 11:47:30, 3,909 files, 14.18 GB (5 files, 38.80 KB, 0.00% new) 2010-11-21 11:50:51 avtar Info <6083>: Backed-up 14.18 GB in 7.38 minutes: 115 GB/hour (31,790 files/hour) 2010-11-22 13:34:24 avtar Info <5156>: Backup #5 timestamp 2010-11-22 13:31:02, 3,910 files, 14.19 GB (6 files, 12.41 MB, 0.09% new) 2010-11-22 13:34:24 avtar Info <6083>: Backed-up 14.19 GB in 8.91 minutes: 96 GB/hour (26,324 files/hour) 2010-11-23 09:30:01 avtar Info <5156>: Backup #6 timestamp 2010-11-23 09:25:59, 3,914 files, 14.24 GB (10 files, 717.5 KB, 0.00% new) 2010-11-23 09:30:01 avtar Info <6083>: Backed-up 14.24 GB in 12.90 minutes: 66 GB/hour (18,203 files/hour) 2010-11-24 09:12:44 avtar Info <5156>: Backup #7 timestamp 2010-11-24 09:08:27, 3,915 files, 14.29 GB (11 files, 12.72 MB, 0.09% new) 2010-11-24 09:12:44 avtar Info <6083>: Backed-up 14.29 GB in 8.46 minutes: 101 GB/hour (27,766 files/hour) 2010-11-25 09:30:12 avtar Info <5156>: Backup #8 timestamp 2010-11-25 09:25:41, 3,911 files, 14.34 GB (7 files, 14.27 MB, 0.10% new) 2010-11-25 09:30:12 avtar Info <6083>: Backed-up 14.34 GB in 7.64 minutes: 113 GB/hour (30,722 files/hour) 2010-11-26 09:20:28 avtar Info <5156>: Backup #9 timestamp 2010-11-26 09:15:43, 3,911 files, 14.40 GB (6 files, 1.077 MB, 0.01% new) 2010-11-26 09:20:28 avtar Info <6083>: Backed-up 14.40 GB in 15.72 minutes: 55 GB/hour (14,929 files/hour) 2010-11-27 09:12:10 avtar Info <5156>: Backup #10 timestamp 2010-11-27 09:07:10, 3,917 files, 14.41 GB (11 files, 357.6 KB, 0.00% new) 2010-11-27 09:12:10 avtar Info <6083>: Backed-up 14.41 GB in 7.18 minutes: 120 GB/hour (32,737 files/hour) 2010-11-28 09:13:39 avtar Info <5156>: Backup #11 timestamp 2010-11-28 09:07:57, 3,917 files, 14.43 GB (10 files, 8.919 MB, 0.06% new) 2010-11-28 09:13:39 avtar Info <6083>: Backed-up 14.43 GB in 7.95 minutes: 109 GB/hour (29,565 files/hour) 2010-11-29 09:13:44 avtar Info <5156>: Backup #12 timestamp 2010-11-29 09:07:47, 3,912 files, 14.44 GB (5 files, 5.485 MB, 0.04% new) 2010-11-29 09:13:44 avtar Info <6083>: Backed-up 14.44 GB in 7.80 minutes: 111 GB/hour (30,108 files/hour)

54

Příloha č. 4: Výsledky měření VMware farmy První den ClientName SK4TMBD00000 SK4TMBD00001 SK4TMBD00002 SK4TMBSCAPRC C SK4TMBSMTP01 SK5TMBD00000 SK5TMBD00001 sk5tmbdc0backup sk5tmbdc0backup sk5tmbdc1backup sk5tmbdc1backup SK5TMBSCCM SK5TMBSCOMM S SK5TMBSCOMR MS SK5TMBSEBOX SK5TMBSEX00 SK5TMBSEXF1 SK5TMBSEXF1 SK5TMBSEXR1 SK5TMBSEXR1 SK5TMBSFS00 SK5TMBSFS01N0 1 SK5TMBSKMS SK5TMBSKONET SK5TMBSMSCA SK5TMBSMSCA0 1 SK5TMBSMTP SK5TMBSNIES

Dataset

PlugInName

/VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /Client OnDemand Data /VMware Image Dataset /Client OnDemand Data /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /Client OnDemand Data /VMware Image Dataset /VMware Image Dataset /Client OnDemand Data /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset

Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Linux VMware Image

AvgPcntComm on

Backups

55

GBProtected

GBNew

28

100

10.01

0.00

27

100

6.00

0.00

23

97.91

10.08

0.21

22

99.43

20.03

0.11

27

100

20.00

0.00

22

98.33

10.07

0.17

23

98.59

10.07

0.14

1

85.57

10.00

1.44

25

100

10.00

0.00

1

97.19

10.00

0.28

27

100

10.00

0.00

24

99.49

40.04

0.20

23

99.47

20.03

0.11

24

99.43

20.03

0.12

24

99.37

40.03

0.25

23

99.25

30.05

0.22

2

84.05

10.01

1.60

24

99.15

10.03

0.09

23

98.74

10.04

0.13

1

89.33

10.00

1.07

21

98.66

10.03

0.13

1

98.85

40.00

0.46

23

99.29

20.02

0.14

24

98.54

20.06

0.29

23

99.68

20.02

0.07

25

99.41

30.02

0.18

23

99.66

20.02

0.07

20

99.73

30.00

0.08

SK5TMBSPS SK5TMBSQL2K8 SK5TMBSUMS5T SK5TMBSUMSA SK5TMBSUMSI SK5TMBSW2K8R 2 SK5TMBSWINS0 1 SK5TMBSWRMS SK5TMBWVIEN1 SK5TMBWVIEN2 SK5TMBWXPCZ1 SK5TMBWXPDE1 SK5TMBWXPEN1 SK5TMBWXPEN2 testtsm TEST_TSM TEST_TSM test-w2k3-1 test-w2k3-2 test-w2k8-1 test-w2k8-1 test-w2k8-2 test-w2k8-3 test-w2k8-4

/VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /clustered VM /Client OnDemand Data /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /Client OnDemand Data /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset

Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows File System Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image Windows VMware Image

56

23

99.77

40.02

0.09

22

99.08

70.10

0.64

22

99.51

20.03

0.10

24

99.64

35.02

0.13

23

99.46

20.05

0.11

23

99.96

40.02

0.02

24

99.04

10.03

0.10

24

99.23

20.03

0.15

23

99.35

30.00

0.20

23

98.47

30.07

0.46

24

97.7

15.06

0.30

25

98.29

9.97

0.17

23

98.39

20.07

0.32

23

84.97

4.14

0.62

21

99.55

11.55

0.05

1

99.79

26.00

0.06

27

100

26.00

0.00

28

99.63

10.03

0.04

28

99.07

10.00

0.09

3

100

23.00

0.00

29

99.99

23.01

0.00

29

99.98

23.01

0.00

29

100

23.00

0.00

29

99.86

23.02

0.03

1069.90

11.23

Druhý den Host SK4TMBD00000 SK4TMBD00001 SK4TMBD00002 SK4TMBSCAPRCC SK4TMBSMTP01 SK5TMBD00000 SK5TMBD00001 sk5tmbdc0-backup sk5tmbdc1-backup SK5TMBSCCM SK5TMBSCOMMS SK5TMBSCOMRMS SK5TMBSEBOX SK5TMBSEV01N01backup SK5TMBSEX00 SK5TMBSEXF1 SK5TMBSEXR1 SK5TMBSFS00 SK5TMBSKMS SK5TMBSKONET SK5TMBSMSCA SK5TMBSMSCA01 SK5TMBSMTP SK5TMBSNIES SK5TMBSPS SK5TMBSQL2K8 SK5TMBSUMS5T SK5TMBSUMSA SK5TMBSUMSI SK5TMBSW2K8R2

Root /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset

Backups

AvgPcntCommon

GBProtected

GBNew

8

100

10.01

0.00

8

100

6.00

0.00

7

99

10.08

0.00

10

100

20.00

0.00

8

100

20.00

0.00

7

97

10.00

0.00

7

99

10.05

0.00

8

100

10.00

0.00

8

100

10.00

0.00

10

100

40.03

0.00

8

100

20.00

0.00

7

100

20.01

0.00

10

100

40.02

0.00

0

100

0.00

0.00

11

100

30.04

0.00

7

99

10.02

0.00

7

98

10.04

0.00

7

98

10.00

0.00

7

99

20.02

0.00

7

99

20.03

0.00

7

100

20.02

0.00

7

100

30.02

0.00

7

99

20.02

0.00

7

100

30.00

0.00

10

100

40.01

0.00

11

99

70.00

0.01

7

99

20.00

0.00

10

100

35.01

0.00

8

100

20.02

0.00

7

100

40.01

0.00

57

SK5TMBSWINS01 SK5TMBSWRMS SK5TMBWVIEN1 SK5TMBWVIEN2 SK5TMBWXPCZ1 SK5TMBWXPDE1 SK5TMBWXPEN1 SK5TMBWXPEN2 testtsm TEST_TSM test-w2k3-1 test-w2k3-1 test-w2k3-2 test-w2k8-1 test-w2k8-2 test-w2k8-3 test-w2k8-4

/VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /clustered VM /VMware Image Dataset //?/MOD1276167867512 /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset /VMware Image Dataset

7

99

10.02

0.00

7

99

20.02

0.00

7

100

30.00

0.00

7

99

30.02

0.00

8

98

15.06

0.00

8

100

9.97

0.00

10

99

20.07

0.00

7

87

4.14

0.01

63501

100

11.53

0.00

11

100

26.00

0.00

7

66

10.00

0.01

7

100

10.01

0.00

8

100

10.00

0.00

8

100

23.00

0.00

8

100

23.00

0.00

8

100

23.00

0.00

7

100

23.01

0.00

950.30

0.08

58