Vysoká dostupnost a zotavení z katastrofy pro podnikové IS

Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování

Vysoká dostupnost a zotavení z katastrofy pro podnikové IS Diplomová práce

Autor:

Bc. Jan Suchý

Vedoucí práce:

Ing. Vladimír Beneš

Praha

Duben, 2009

Prohlášení Prohlašuji, že jsem diplomovou práci zpracoval samostatně a s použitím uvedené literatury.

V Praze dne 14. dubna 2009

Jan Suchý

Anotace práce Obsahem této práce je seznámení s problematikou nasazování informačních systémů a realizace potřebné IT infrastruktury pro jejich provozování s ohledem na vysokou dostupnost služby a zotavení z případné katastrofy. Tato diplomová práce porovnává možné návrhy realizace infrastruktury a analyzuje cenovou hladinu pro dosažení jednotlivých úrovní vysoké dostupnosti, včetně rozboru klíčových komponentů návrhu. Trend požadavků na výkonnost a dostupnost vede k instalaci dalších serverů, které jsou stejně tak, jako již instalované servery neefektivně využívané. V práci uvádím praktické příklady, jak by mělo být postupováno s ohledem na efektivní využívání zdrojů hardwaru směrem je konsolidaci IT infrastruktury. Konsolidace serverů s použitím virtualizace je jediným možným konceptem jak udržet IT infrastruktury v ekonomicky výhodném provozu.

The document contains introduction how to roll-out information systems and best practises with IT infrastructure solution as well as high availability and disaster recovery design. There is also included comparison among possible infrastructure designs and analyzes from price levels point of view by particular solutions and components. Current trend in performance requirements and availability will demand a new server’s installation. But all servers are typically underutilized in common operation. The examples of process how to effectively utilize hardware are based on real life experience. And trend towards IT consolidation is also shown. Server consolidation mostly based on virtualization technology is the only way how to run IT infrastructure effective from financial point of view. Helps as well significantly form manageability and facility point of view as well.

Obsah 1

2

PROBLEMATIKA ZAJIŠTĚNÍ DOSTUPNOSTI SLUŽBY 1.1

VYSOKÁ DOSTUPNOST PRO APLIKACE

7

1.2

VYSOKÁ DOSTUPNOST PRO DATA

8

1.3

VYSOKÁ DOSTUPNOST PRO IT INFRASTRUKTURU

8

PRINCIPY VYSOKÉ DOSTUPNOSTI VYSOKÁ DOSTUPNOST

2.2

PŘÍKLADY REALIZACÍ JEDNOTLIVÝCH SLA

10

SLA 99 %

10

2.2.2

SLA 99,9 %

11

2.2.3

SLA 99,99 %

15

2.2.4

SLA 99,999 %

21

2.2.5

Zhodnocení

26

ZOTAVENÍ Z KATASTROFY

27

2.3.1

Možné varianty DR řešení

29

2.3.2

Třída 7

30

2.3.3

Třída 6 – 4

32

2.3.4

Třída 3 – 1

34

EFEKTIVNÍ VYUŽÍVÁNÍ HARDWAROVÝCH ZDROJŮ VIRTUALIZACE SERVERŮ

35 36

3.1.1

Přehled vizualizačních technologií

37

3.1.2

Vhodnost jednotlivých konceptů

41

3.2

VIRTUALIZACE PRO DATA

42

3.2.1

Virtualizace pro disková úložiště

42

3.2.2

Virtualizace pásek

43

3.3

5

9

2.2.1

3.1

4

9

2.1

2.3

3

7

BEZPEČNOST VIRTUALIZACE PRO SERVERY A DATOVÁ ÚLOŽIŠTĚ

44

3.3.1

Nejdůležitější bezpečnostní úskalí u serverů

44

3.3.2

Bezpečnosti na úrovni virtuálních serverů

44

3.3.3

Bezpečnost při zálohování ve virtuálním prostředí

45

3.3.4

Kontinuita provozu na virtuálních serverech

45

APLIKAČNÍ HOSTING A OUTSOURCING

46

4.1

POSKYTOVANÉ SLUŽBY ICT

46

4.2

KOMPLETNÍ SLUŽBY ICT

46

4.3

NEPŘETRŽITÁ BYZNYS PODPORA

49

DATOVÁ CENTRA A IT KONSOLIDACE 5.1

STRATEGIE PROVOZOVÁNÍ APLIKACÍ A DAT V DATOVÉM CENTRU

4

50 50

5.1.1

Rozdělení aplikací

51

5.1.2

Profily pro nasazení aplikací

53

5.2

INFRASTRUKTURA

53

5.2.1

Řízení nákladů na energie

54

5.2.2

Užívání energií v DC

54

5.3

KONSOLIDACE

55

5.3.1

Centralizace systémů IT

56

5.3.2

Analýza klíčových aplikací

56

5.3.3

Standardizace aplikací

57

5.3.4

Infrastruktura společností

57

5.3.5

Konsolidace serverů

58

5.4

STRATEGIE NASAZENÍ APLIKACÍ

64

5.4.1

Kritické aplikace Třída 1 a 2

64

5.4.2

Licenční politika

65

5.4.3

Příklad nasazení aplikace SAP R/3

65

5.5

UKLÁDÁNÍ DAT A ZÁLOHOVÁNÍ

67

ZÁVĚRY A DOPORUČENÍ

70

SEZNAM POUŽITÉ LITERATURY

72

SEZNAM OBRÁZKŮ A TABULEK

73

5

Úvod Uživatelé ICT technologií dnes očekávají trvale dostupnou službu, kterou jsou zvyklí používat kdykoliv mají potřebu. Pokud některá služba není dostupná tak to vnímají jako určitou újmu. Představte si, že nebude fungovat síť mobilního operátora, nebo připojení k internetu v okamžiku, kdy je nejvíce budete potřebovat. Problematika dostupnosti služby je tedy nejdůležitější úkol ICT odborníků. Principy vysoké dostupnosti jsou závislé na požadavcích a možnostech, které jsme ochotni za vysokou dostupnost zaplatit. Pokud vyžadujeme nepřetržitý provoz, projeví se to s největší pravděpodobností v nákladech a ceně za danou službu. Je tedy na místě zvážit jaké jsou naše skutečné požadavky. Vysoký počet různých služeb, které vyžadují rozdílnou infrastrukturu pro vlastní provoz s ohledem na dostupnost a požadavky klientů, vede k rapidnímu nárůstu počtu komponentů, ze kterých je ICT infrastruktura sestavena. Efektivita využívání zdrojů je pro každý systém různá, ale v celkovém pohledu je velmi nízká. Množství různých málo vytěžovaných systémů pak vede uživatele k myšlence hostování aplikací v datovém centru, nebo se kloní k úplnému outsourcingu svých ICT služeb. Uživatelé služeb pak svoji aktivitu soustředí na oblast jejich hlavní obchodní činnosti. Vedlejším efektem je racionální využívání ICT infrastruktury, která je poskytovaná profesionální společností pro více zákazníků najednou. Datová centra s větším počtem různých systémů jsou potřeba navrhovat s myšlenkou dlouhodobého efektivního provozu. Správná strategie nasazování aplikací na konkrétní platformy pak umožní využívání virtualizačních konceptů a efektivně tak využívat hardwarové zdroje poskytované ICT infrastrukturou. Konsolidace ICT infrastruktury je současným

trendem

k získání

efektivního,

energeticky

úsporného

a

hlavně

ekonomického provozování ICT služeb. Vybudování „Green IT“ je cílem mnoha firem, které se více či méně stali úspěšné v konceptu nasazování špičkových technologií k dosažení energeticky efektivní infrastruktury.

6

1 Problematika zajištění dostupnosti služby Volbou správné strategie osazování datového centra vhodnou infrastrukturou a technologií pro aplikace lze předcházet značným problémům s vlastním provozem. Důležité pro vhodný návrh je dostatek informací o provozovaných aplikacích, jejich datech, požadavků na dostupnost – SLA1 a především další rozvoj po stránce nárůstu požadovaného výkonu a kapacity dat.

1.1 Vysoká dostupnost pro aplikace Celkový návrh splňuje prvky vysoké dostupnosti, pokud jsou zabezpečeny následující podmínky. Veškeré komponenty jsou zcela redundantní. Komunikace mezi jednotlivými částmi probíhá po dvou nezávislých cestách přičemž, pro případ havárie některého z funkčních celků nebo je vždy k dispozici druhý, který převezme jeho funkci. Aplikace jsou automaticky spouštěny na záložním hardware po vyhodnocení nedostupnosti služby na primárním systému. Rychlost přesunu je závislá na povaze aplikace a její schopnosti pracovat ve vysoko dostupném prostředí. Existují aplikace s vestavěnou funkčností, kdy se přesun na záložní hardware uskuteční okamžitě a bez výpadku. Dále jsou aplikace, které to dokážou v rekordně nízkém čase, řádově několik sekund a následuje největší skupina aplikací, které takové vlastnosti nemají a tak je nutné je zajistit náhradním softwarem. Hovoříme o cluster softwaru, který doplňuje operační systém hostující danou aplikaci. Cluster software monitoruje a kontroluje důležité komponenty na straně serveru tzv. Heart Beat2, tedy kontrola životních funkcí serveru a ověření funkce po společných komunikačních linkách na více úrovních (RS232, LAN, SAN, atd.), dále důležité části operačního systému a klíčové části samotné aplikace. Hlavní funkcí cluster softwaru je monitorování a provedení polo nebo plně automatické zásahů, tak abychom zajistili vysokou dostupnost pro aplikace.

1 2

SLA – Service Layer Agreemnet. Heart Beat – doslova srdeční pulz. 7

1.2 Vysoká dostupnost pro data Výběrem diskového pole určíme celkovou spolehlivost datové infrastruktury. Samotná disková pole jsou dnes navržena jako plně redundantní celek. Taková pole disponují dvojicí kontrolérů řídících komunikaci se servery na jedné straně a na druhé pak směrem k vlastním fyzickým diskům tvořícím kapacitu pole. Důležitou vlastností je bezvýpadkový přesun zátěže mezi kontroléry. Každý disk v diskovém poli je k serverům připojený pomocí duálních cest – tedy existují dvě cesty pro případ hardwarové poruchy některého z komponentů infrastruktury. Největším problémem je stav výpadku kontroléru a jak se diskové pole vyrovná s takovou událostí. Co se stane s daty, která ještě nebyla uložena na disky a byla v době výpadku kontroléru v jeho vyrovnávací paměti? Taková paměť je u dnešních diskových polí v kapacitě až desítek GB. Jednoznačně je potřeba vybrat správné zařízení, které pamatuje na tuto možnost a provádí synchronní zrcadlení vyrovnávací paměti na druhý kontrolér. Pokud toto neumožňuje je nutné pro zápisy na pole tuto paměť zakázat a používat ji jen pro čtení. Uvědomme si, že dojde k omezení výkonu pro operace zápisu na pole tedy především o potvrzení převzetí dat což je daň za levnější disková pole. Ačkoliv máme super spolehlivé pole, může nastat situace, kdy pole přestane odpovídat nebo je potřeba udělat servisní zásah a je nutný restart celého systému. Na základě vlastních zkušeností se jako jediné možné řešení, jak zajistit vysokou dostupnost pro data jeví nutnost instalace druhého diskového pole. Dále je potřeba zajistit replikaci nebo kopírování dat tak aby byly ve stejný čas identická data na obou diskových polích.

1.3 Vysoká dostupnost pro IT infrastrukturu Infrastruktura je důležitou součástí, bez které nelze IT technologie rozumě provozovat. Jedná se o sítě pro komunikace prostřednictvím běžně užívaných protokolů. V současně době se těmito sítěmi rozumí především LAN a SAN sítě. Důležitým požadavkem na tyto sítí je redundance připojení. Klientská pracoviště jsou sice připojena do LAN sítě jedním kabelem, tedy pouze do jednoho aktivního prvku ale v případě propojení serverů a diskových polí se vždy jedná o striktně duální propojení s eliminací možného výpadku vlivem, některé komponenty infrastruktury.

8

2 Principy vysoké dostupnosti 2.1 Vysoká dostupnost High Availability neboli HA je v současné době nezbytnou součástí každé firemní infrastruktury a zcela důležitou součástí efektivního fungování firmy. Tento stav je mnohdy managementem firem brán na lehkou váhu. Pro nasazení vysoké dostupnosti mnohdy hovoří ekonomické ukazatele. Zejména pak vyjádření ztráty při odstavení výrobního provozu, expedice nebo fakturace. V případě prvního výskytu problému s nedostupností požadované služby je ihned požadováno takové řešení, aby k podobným incidentům již nedocházelo. Základním parametrem je definování dostupnosti služby – SLA pro dané aplikace, služby, dostupnosti dat apod. Definicí potřebného SLA se zejména myslí povolený výpadek uváděný v procentech. Příkladem tedy mohou být následující definice SLA: •

Služba „e-mail“ musí dosahovat dostupnosti 99 % v režimu 7x24

•

Služba „fakturace“ musí dosahovat dostupnost 99,9 % v režimu 5x12

•

Služba „výroba“ musí dosahovat 99,99 % v režimu 7x24

Uvedené definice nám říkají, jak jsou jednotlivé systém pro uživatele kritické a jak je potřeba zajistit jejich provoz. Procenta dostupnosti definují, kolik času musí být systém v provozu a naopak kolik času zůstává na jeho opravy. Uvedené příklady nám tedy prozrazují tyto informace. Službu „e-mail“ potřebuje zákazník 24 hodin denně, 7 dní v týdnu a (ne)plánovaný výpadek nesmí překročit 3,65 dne za rok. Jinými slovy pokud služba „e-mail“ nebude funkční 1 den 3x za rok není to omezující pro fungování firmy. Z uvedené tabulky č. 1 je zřejmé, že SLA požadavky od 99,9% výše jsou již daleko kritičtější a vyžaduje zvláštní rozbor každé z nich. Následující tabulka nejlépe postihuje rovnováhu mezi definicí SLA, skutečnou dostupností v čase a patřičných nákladech spojených s vlastní realizací infrastruktury.

9

Tabulka 1: Přehled SLA podmínek a trend nákladů na jeho dosažení. Časové období 1 rok 365 dní 8 760 hodin 525 600 minut Náklady Kč

99 % 3,65 87,6 5256

SLA 99,9 % 99,99 % 0,365 0,0365 8,76 0,876 525,6 52,56

nízké

99,999 % 0,00365 0,0876 5,256 vysoké

Zdroj: Vlastní.

2.2 Příklady realizací jednotlivých SLA Pro příklad uvádím praktické zkušenosti s nasazováním aplikací, služeb pro jednotlivé SLA. Předpokládejme, že máme informační systém vyžadující aplikační a databázový server s připojením do lokální sítě 100 MB, diskový prostor pro data o velikosti 1,0 TB. Zálohování pro případ výpadku je realizováno nejvýkonnější zálohovací technologií LTO4. Zpravidla se SLA podmínky uvádění na dostupnost infrastruktury nikoliv na celek. Důvodem je poměrně těžko definovatelná garance pro dostupnost konkrétních částí. Dalším problémem je zajištění různých částí infrastruktury různými dodavateli. Garance za kvalitu aplikací lze jen obtížně definovat. Celkové SLA pak je možně jen v případech totálního outsourcingu. Dále jsem popsal pro názornost problematiku jednotlivých dostupností z pohledu infrastruktury, dat a zajištění opětovného provozu.

2.2.1 SLA 99 % Požadavek na dostupnost služby 99 % nám dává poměrně volnost ve volbě technologie, na které budeme IS provozovat. Výpadek téměř 88 hodin lze pokrýt následujícím hardware: Aplikační

(APP),

databázový

(DB)

server

s procesory

x86

operační

systém

Windows/Linux. Servery by měli mít redundantní klíčové komponenty (adaptery, disky, zdroje, atd.). Data lze umístit na lokální disky DB serveru s RAID3 redundancí. Pro případnou poruchu hardware je vhodné servery zajistit servisním pokrytím s garantovanou dobou opravy na místě u zákazníka. Tedy požadavek SLA přeneseme na dodavatele hardware, který bude schopen nejlépe zabezpečit servis v lokalitě datového centra.

3

RAID – Redundant Array of Inexpensive/Independent Disks – redundantní diskové pole z nezávislých disků. 10

Řekněme, že budeme požadovat opravu do 24 hodin z důvodu ceny za požadovanou službu. Pokud máme opravený hardware, nastává okamžik, kdy musíme obnovit systém, případně data. Uvažujme nejhorší možnou variantu, že musíme udělat kompletní obnovu dat ze zálohy. Doba kompletní obnovy bude teoreticky trvat 2,38 hodiny, což neovlivní výpadek přes požadované SLA. Rekapitulace celkového času obnovy - RTO4.

•

Nejzazší doba opravy serveru podle SLA dodavatele HW - 24 hodin

•

Teoretická obnova dat ze zálohovací mechaniky LTO4

- 2,38 hodiny

•

Reakce obsluhy na problém a zahájení opravy sytému

- 1 hodina

Celkově by měla RTO být maximálně 27 hodin při nejhorším možném scénáři. Což znamená, že je možné zopakovat podobný zásah 3x za rok. Náklady na pořízení jsou vyjádřeny v následující tabulce č. 2. Tabulka 2: Celkové náklady na pořízení infrastruktury pro SLA 99 %. Komponenty Popis Hardware Servery 2x x86 pro APP a DB + interní diskové pole Zálohování LTO4 mechanika Software Operační systém licence Podpora Servery HW SLA 24 hodin FIX 3 roky SW Operační systém 3 roky Celkové náklady za 3 roky

Cena v Kč 300 000 50 000 60 000 20 000 20 000 450 000

Zdroj: Vlastní

Celkové náklady na dosažení SLA po dobu 3 let budu pro tento případ cca 450 000 Kč.

2.2.2 SLA 99,9 % Výpadek necelých 9 hodin za rok je již podstatné zkrácení. Zde není prostor na úvahy co dělat v případě, že dojde k výpadku některé části infrastruktury. Pokud se podíváme na předchozí příklad s RTO = 27 hodin je zřejmé, že takové řešení nesplňuje požadavky

4

RTO – Recovery Time Objektive – celkový čas obnovy. 11

kladené v SLA. Co je tedy potřeba zlepšit? V prvé řadě je potřeba zvážit kolikrát si můžeme dovolit výpadek, kdy opravdu dojde k totálnímu výpadku. Návrhů, jak řešit vzniklou situaci je mnoho v závislosti na finančních možnostech. Varianta A - ideální se zdá být automatický fail-over5, který zajistí běh aplikace na druhém serveru. Pro úspěšné přesunutí je zapotřebí umístit data na externí diskové pole a zajistit sdílený přístup z obou serverů. Diskové pole musí podporovat možnost automatického přesunu logických svazků na druhý server. Opět platí nutnost redundance všech klíčových komponentů návrhu včetně redundance přístupu k datům na diskovém poli. Nevýhodou tohoto řešení je možný SPOF6 na diskovém poli. V tomto případě lze eliminovat možný SPOF přidáním diskového pole nebo uzavřením SLA na opravu diskového pole s garantovanou dobou opravy do 4 hodin. Obě varianty jsou nákladné investice, přičemž druhé pole je vhodnější volbou. Obrázek 1: Obecné zapojení pro HA cluster se dvěma poli.

Zdroj: Vlastní.

Varianta B - vhodnou alternativou je využití replikačních vlastností některých databází. Pokud máme kvalitní databázový stroj, je možné používat online synchronní replikace mezi DB7 stroji na obou serverech. Případný fail-over proces je pak v režii manažeru DB, který zajistí přesun zátěže na druhý server. V tomto případě není nutné používat externí diskové pole. Každý server má vlastní diskový prostor pro data. Další výhodou oproti předchozímu řešení je pak duplicitní ukládání dat.

5

Fail-over – jedná se o zásah cluster nadstavby operačního systému. SPOF – Single Point Of Failure – případný výpadek vlivem chyby jedné komponenty. 7 DB – Databáze. 6

12

Obrázek 2: Databázové replikace.

Zdroj: Vlastní.

Jaké jsou tedy skutečné možnosti výpadku a jaký bude RTO pro obě varianty? V prvním případě, kdy dojde k výpadku diskového vlivem hardwarové poruchy a s následnou chybou servisního technika, při které bude navíc nutné obnovit data na poli je výpočet následující: Rekapitulace celkového času obnovy – RTO: Varianta A - automatický cluster s diskovým polem:

•

Nejzazší doba opravy serveru podle SLA dodavatele HW

- 4 hodin.

•

Teoretická obnova dat ze zálohovací mechaniky LTO4

- 2,38 hodiny.

•

Reakce obsluhy na problém a zahájení opravy sytému

- 1 hodina.

Celkový čas RTO je cca 8 hodin což nám dovoluje jediný možný výpadek za celý rok. Doporučení je instalace druhého diskového pole a zrcadlení dat na obě pole. Tím se eliminuje nutnost kritického SLA na opravu HW s dobou 4 hodiny. Dále můžeme předpokládat, že nebude potřeba obnovovat data v důsledku výpadku diskového pole. Tedy dobu kdy automatický fail-over cluster software převede aplikace a nastolí opětovný běh systému. Celkový čas RTO by se pak snížil na jednotky minut. Pro další porovnání variantu s dvojicí diskových polí označím jako Varianta A1. Varianta B - databázové replikace:

•

Nejzazší doba opravy serveru podle SLA dodavatele HW

- 24 hodin.

•

Teoretická obnova dat ze zálohovací mechaniky LTO4

- 2,38 hodiny.

•

Reakce obsluhy na problém a zahájení opravy sytému

- 1 hodina.

Celkový čas RTO je závislý od reakce databázového systému a automatické reakce cluster systému. Prakticky se tato hodnota pohybuje v řádu jednotek minut. 13

Náklady na pořízení jsou vyjádřeny v následující tabulce č. 3 pro všechny varianty, kde je patrný nárůst nákladů na vlastnictví infrastruktury pro aplikace v uvedeném SLA pokrytí. Při realizaci jednotlivých variant musíme vhodně volit technologie, abychom dosáhli požadovaného výsledku. Pro všechny varianty platí, že klíčovým parametrem bude spolehlivost každé komponenty, abychom udrželi co nejlepší hodnotu MTBF8 a tím i reálnou možnost úspěšného splnění SLA podmínek. Tabulka 3: Celkové náklady na pořízení infrastruktury pro SLA 99,9 %. Komponenty Popis Hardware Servery 2x x86 pro APP a DB Diskové pole (2x Varianta A1) Zálohování LTO4 mechanika Software Operační systém licence Cluster software Podpora Servery HW SLA 24 hodin FIX 3 roky Disková pole HW SLA 4 hodin FIX 3 roky Disková pole HW SLA 24 hodin FIX 3 roky SW Operační systém 3 roky SW Cluster 3 roky Celkové náklady za 3 roky

Varianta A Cena v Kč

Varianta A1 Cena v Kč

Varianta B Cena v Kč

250 000 200 000 50 000

250 000 400 000 50 000

350 000

60 000 50 000

60 000 50 000

60 000 50 000

20 000 160 000

20 000

20 000

69 000 20 000 20 000 939 000

20 000 20 000 570 000

20 000 20 000 830 000

50 000

Zdroj: Vlastní.

Volba operačního systému je důležitá z několika hledisek. Musí být bezpečný, spolehlivý, stabilní a navíc poskytovat funkcionalitu, kterou potřebujeme. Další důležitou informací pro výběr je vzájemná podpora mezi výrobcem operačního systému a aplikací. U varianty A je nejen potřeba dbát na kvalitu produktů ale hlavně na kvalitu servisního pokrytí hardware diskového pole. Klíčovou úlohu zde bude hrát i spolehlivost dodavatele zda je schopen dostát SLA podmínek. Naopak u varianty A1 je nejdůležitější schopnost OS synchronně zapisovat data na obě pole současně. Zde jsou nejlepší zkušenosti s LVM9 Linux a Unix operačních systémů. Pro MS Windows existuje vhodná alternativa v podobě Veritas LVM, který je ovšem za poplatek nicméně jedná se o výborný produkt.

8

MTBF - Mean Time Between Failures – střední doba mezi poruchami. Vyšší hodnota = vyšší spolehlivost. 9 LVM - Logical Volume Manager – manažer disků. 14

Oproti předchozím variantám je varianta B jednodušší z pohledu hardwarové infrastruktury. Klíčovou úlohu zde hraje především kvalita DB stroje a jeho replikačních schopností. Mnoho zákazníků dává přednost právě replikaci na úrovni DB stroje, protože je tím zajištěna kontinuálnost provozu s minimálními požadavky na hardware. Ovšem i zde existují úskalí. Je vždy potřeba se seznámit s licenčními podmínkami výrobce DB stroje. Některé produkty jsou vybaveny replikačními funkcemi a není potřeba je dokupovat, jiné jsou naopak zpoplatněné. Dále záleží na náhledu výrobce DB stroje, jak hodnotí celou infrastrukturu z pohledu licenční náročnosti. V některých případech je rozdíl i v tom, zda je DB uložena na jednom či více diskových polích. Pro všechny varianty ovšem platí, že pokud chceme zajistit automatický fail-over je potřeba integraci s cluster softwarem, který zajistí všechna potřebná nastavení. Jedná se o operace, jako jsou namontování disků, změny IP10 adres a pojmenování LAN adapterů tak, aby dotazy byly správně směrovány na nový server.

2.2.3 SLA 99,99 % Výpadek necelou hodinu za rok znamená, že nemůžeme již podcenit žádnou část běhu systému. Ideální technologie pro takovou dostupnost je ta, která umožňuje online správu. Operační systém by měl být opravitelný za běhu, stejně tak i hardware, který by měl mít co nejvíce za chodu opravitelných komponentů. Uvažujeme o hardware pro servery s následujícími vlastnostmi:

10

•

Prediktivní kontrola a samo-opravné reakce u klíčových komponent, jako jsou procesory, paměti, sběrnice. Interní systém serveru musí monitorovat provoz serveru a reagovat preventivně na potenciální problematické chování tak aby nedošlo k totálnímu výpadku serveru. Kontrolní systém dokáže de-alokovat potenciálně vadný procesor nebo paměťový čip, který by vykazoval podezřelé chování.

•

Redundantní architektura serveru v oblastech jako jsou paritní informace na sběrnicích a pamětech nebo princip dvojitého osazování komunikačních adapterů, napájecích zdrojů a ventilátorů.

IP – Internet Protocol – všeobecně používaný protokol ke komunikaci v LAN sítích. 15

•

Spolupráce s operačním systémem musí zajišťovat online provoz i v případě výskytu kritických poruch. Tedy výpadek procesoru nesmí způsobit pád operačního systému a aplikací které hostuje.

Jaký hardware takovými vlastnostmi disponuje? Většinou se jedná o servery s RISC procesory a operačním systémem UNIX od IBM, HP nebo SUN Microsystems. Další možností je zajistit více početný cluster systém pro x86 servery, které nemají zdaleka tak propracovanou prediktivní a samo-opravnou architekturu jako zmíněné RISC servery. Zde je potřeba vhodně volit management a cluster software k zajištění dostupnosti. Jak budou vypadat řešení infrastruktur? V podstatě se příliš nezmění od předchozí varianty s dvojicí diskových polí. Jen servery je potřeba upravit ve smyslu spolehlivější hardwarové architektury. Aplikační servery by bylo vhodné nasadit na dvojici oddělených serverů ideálně propojených do aplikačního clusteru. To znamená, že aplikace jsou online aktivní na obou serverech a kontrolují vzájemnou utilizaci a zajišťují distribuci zátěže mezi sebou. Pro databáze bude ideální DB cluster dvou RISC serverů a dvou diskových polí. Co je potřeba detailně zvážit je princip replikace dat na disková úložiště. Ne všechny možnosti budou vyhovovat pro případné výpadky. Následně uvádím klady a zápory jednotlivých možností.

2.2.3.1 Zrcadlení dat prostředky operačního systému – LVM Jedná se o zrcadlení dvou logických disku, každý z jiného pole a jejich propagování do operačního systému jako jeden disk pro databázi, která na takový disk zapisuje data. Veškerá režie při zrcadlení dat mezi diskovými poli je na serveru a operačním systému.

•

Pozitiva:

o Jednoznačně nejsnazší synchronizace dat mezi dvě disková pole. o Výpadek jednoho pole neovlivní funkci druhého. o Cenově výhodné řešení. •

Negativa:

o Výkonová režie je na operačním systému serveru. o Špatný zápis způsobený chybou operačního sytému nebo DB stroje se provede na obě pole najednou. o Případný fail-over databáze z primárního na záložní server bude provádět kontrolu souborového systému a následnou kontrolu DB, což může trvat i 16

několik minut u velkých DB v řádech TB je možné očekávat i desítky minut!

o Obě pole by měla být shodná, aby nedocházelo k výkonnostním rozdílům při zápisu dat.

2.2.3.2 Zrcadlení prostředky diskových polí Zrcadelní často známé pod označením „Mirroring“ nebo „Remote Mirroring“ – vzdálené zrcadlení. Princip je na replikaci dat prostředky, kterými disponují disková pole. Jedná se o vlastnost diskových polí střední až vysoké třídy. Komunikační rozhraní je FC11a připojují se do SAN12 sítí. Jedno pole je vždy určeno jako primární a druhé záložní. Primární pole zasílá blokové změny dat druhému poli a po potvrzení přijetí je teprve poté potvrzen zápis operačnímu systému zapisujícímu data. Tedy replikace se provádí jen u změn nikoliv pro celá data Díky vysoko propustné síti SAN a blízké vzdálenosti je toto provedeno okamžitě bez zpoždění.

•

Pozitiva:

o Nemá vliv na výkon serveru, režie je na diskovém poli, které replikuje jen malé změny. o Funguje na velké vzdálenosti. Používá se DR13 řešení. •

Negativa:

o Špatný zápis způsobený chybou OS nebo DB stroje se provede na obě pole najednou po potvrzení zápisu na vzdáleném poli. o Záložní pole je vždy v módu „target“ – cíl. To znamená, že v případě výpadku primárního pole je potřeba zajistit změnu stavu na „source“ – zdroj. Pak teprve můžeme začít fail-over operaci. Tuto většinou provádí automaticky cluster software. o Případný fail-over databáze z primárního na záložní server bude provádět kontrolu souborového systému a následnou kontrolu DB, což může trvat i několik minut u velkých DB v řádech TB je možné očekávat i desítky minut!

11

FC – Fibre Channel – protokol pro přenos dat mezi zařízeními infrastruktury. SAN – Storage Area Network – Obdoba LAN sítě jen určena pro komunikaci FC protokolem zejména použitých v infrastruktuře pro disková pole, servery a zálohovací knihovny. 13 DR – Disaster Recovery – zotavení z katastrofy. Více samostatná kapitola v této práci. 12

17

o Obě pole by měla být technologicky stejná, aby fungovala vzájemná komunikace. o Cena řešení je nejvyšší ze všech uvedených - licence RM funkcionality diskových polí.

2.2.3.3 Databázové replikace a online databázový cluster Jak již bylo popsáno výše. Jedná se o replikaci dat prostřednictvím DB strojů a jejich replikačního manažeru. Požadavky na zápisy dat jsou posílány primárním DB serverem prostřednictvím „redo14“ nebo podobných logů na vzdálený server. Při potvrzení záložním serverem o přečtení a aplikování těchto logů na vlastní data je teprve odesláno potvrzení aplikaci, že byl požadavek o zápis proveden. Existuje i možnost online DB clusteru, kde oba DB servery jsou online a případný pád jednoho z nich nemá vliv na funkci DB vrstvy.

•

Pozitiva:

o Jednoznačným pozitivem tohoto řešení je nezávislost diskových polí navzájem jako v předchozích řešeních. o Data, respektive popis změn dat, jsou velmi rychle přenášena na druhý server. o Funguje na velké vzdálenosti. Používá se DR řešení. o Chyby zápisu vlivem OS nebo DB stroje nemají vliv na záložní server! o Případný fail-over je u některých DB systémů do jednotek sekund! •

Negativa:

o Cena licencí za replikační nástroje může být vysoká. Záleží na výrobci a typu řešení. Rekapitulace celkového času obnovy – RTO: Zrcadlení dat prostředky operačního systému – LVM je nejčastěji používaným řešením běžně užívaným pro dosažení vysoké dostupnosti. Dobré praktické zkušenosti jsou zaznamenány i na diskových polích třídy „Enterprise“ určené pro kritické podnikové aplikace. Jak bylo již popsáno, hlavní nevýhodou tohoto řešení je zápis na obě pole

14

Redo log – především v terminologii Oracle DB. Znamená logování všech změn v DB, které provádí DB stroj a ukládá vše do unikátního souboru. 18

najednou, kdy může nastat zápis špatných dat vlivem chyby OS nebo DB stroje. Pak nemáme data ani na jednom poli. Jediným vhodným řešením jak zabránit nutnosti obnovy dat z pomalé zálohovací knihovny je pořizovat okamžité kopie dat na diskových polích. Tato operace proběhne v řádu několika sekund a umožní nám návrat k datům z doby, kdy jsme kopii vytvořili. Celkový čas na obnovu funkční infrastruktury bude tedy nejvíce závislý na obsluze, jak dokáže aplikovat návrat do konzistentního stavu a uvést systém zpět do produkce. Rozdíl mezi dobou vytvoření kopie a dobou poruchy je potřeba rekonstruovat z logů, které tvoří databáze. V případě, že dojde k překročení požadované doby obnovy je potřeba zkrátit čas mezi jednotlivými kopiemi dat na potřebnou dobu. Zrcadlení prostředky diskových polí – remote mirroring je alternativním řešením k předchozímu se stejnými problémy. Z pohledu RTO jsou tyto řešení poměrně shodná. Databázové replikace – online databázový cluster je zcela jiné koncepce a vlastní data mohou být ukládána na zcela jiná disková pole od jiného výrobce nebo jiné technologické architektury. Vlastní chyba zápisu způsobená OS nebo DB strojem se nepřenáší na vzdálenou lokalitu. Což nám zajišťuje větší míru bezpečnosti než předchozí dvě řešení. Z těchto známých skutečností lze tuto variantu hodnotit jako nejvýhodnější řešení s nejlepší hodnotou RTO. Možnost využití okamžitých kopií je možným doplňkem pro zajištění duplikace dat pro možnost obnovy. Obecně platí, že pro případy poruchy musí mít obsluha připravený a ověřený postup pro obnovu chodu. Dále je velmi vhodné provozovat i testovací prostředí na ověření postupu obnovy a aplikaci změn a jejich pravidelném ověřování. Zejména je potřeba mít na zřeteli chybný zásah uživatele a to nejen běžných pracovníků ale i odborných administrátorů a servisních techniků. V případě modifikace dat způsobené uživatelem je většinou nutné obnovit data ze záloh a to buď na kopiích, uložených na diskových polích nebo na páskových zařízeních. Náklady na pořízení pro jednotlivé varianty se v praxi od sebe příliš neliší nebo minimálně. Důvodem je skutečnost, že danou dostupnost požadují firmy s větším investičními rozpočty pro IT oddělení. Následně uvádím potřebné součásti infrastruktury, které je potřeba zohlednit při návrhu:

19

•

Dostatečně spolehlivý hardware podle MTBF nebo MTBHI15. Výrobce hardwaru by měl takové nebo podobné hodnoty uvádět pro svá zařízení na požádání.

•

Požadovaná servisní podpora s garantovanou dobou opravy alespoň 8 hodin.

•

Kopírovací funkce diskových polí pro zajištění průběžné duplikace dat.

•

Operační systém serverů s podporou LVM.

•

Databázové replikační prostředky.

•

Cluster software pro automatizaci reakcí na chybové stavy.

•

Redundantní infrastruktura SAN a LAN.

Z uvedené tabulky č. 4 je zřejmý rozdíl v pořizovací ceně jednotlivých řešení. Vzhledem k ceně a vlastnostem ukládání dat se zdá být nejvýhodnější varianta DB replikací. Nicméně opět upozorňuji na licenční politiku výrobce, která může výrazně změnit cenovou výhodnost této varianty. Tabulka 4: Celkové náklady na pořízení infrastruktury pro SLA 99,99 %. Komponenty Popis Hardware Servery 2x RISC pro APP a DB Disková pole 2x 1TB dat Replikační spužby diskových polí Kopírovací služby diskových polí Zálohování LTO4 mechanika Software Operační systém licence Cluster software Podpora Servery HW SLA 8 hodin FIX 3 roky Disková pole HW SLA 8 hodin FIX 3 roky SW Operační systém 3 roky SW Cluster 3 roky Celkové náklady za 3 roky

LVM Cena v Kč

Rem. Mirr. Cena v Kč

DB Repl. Cena v Kč

250 000 1 000 000

250 000 1 000 000

200 000 50 000

250 000 1 000 000 1 100 000 200 000 50 000

60 000 50 000

60 000 50 000

60 000 50 000

50 000 240 000 20 000 20 000 1 940 000

50 000 240 000 20 000 20 000 3 040 000

50 000 240 000 20 000 20 000 1 940 000

200 000 50 000

Zdroj: Vlastní.

Předpokladem je využití serverů s RISC procesory a operačním systémem Linux / UNIX. Zde je záruka splnění kritických požadavků na chování serveru v případě chyby nějaké komponenty.

15

MTBHI - Mean Time Between High Impact – obdoba MTBF. Hodnotí se jen totální výpadek systému nebo takový výpadek, který způsobí vážné ochromení běhu aplikací. 20

Disková pole budou standardní FC zařízení disponující kopírovacími a replikačními funkcemi.

2.2.4 SLA 99,999 % Výpadek 5 minut za rok znamená, že máme zcela bezchybné řešení, které můžeme online spravovat, aniž bychom potřebovali plánovanou odstávku. Jednotlivé výskyty chyb v infrastruktuře musí být opravitelné bez ztráty dostupnosti služby. Data jsou ukládána rovněž duplicitně na více diskových polí. V podstatě lze říci, že již není k metodám vysoké dostupnosti co dodat. Veškeré možnosti byly popsány v předchozí kapitole. Pro „pěti devítkovou“ dostupnost budeme jen vybírat spolehlivější produkty a dbát na celkovou dostupnost celého řešení tak, aby se dosáhlo očekávaného výsledku. Pravdou je, že existuje online cluster systém, který je schopen přesouvat zátěž mezi jednotlivými uzly clusteru tak, že uživatel nepozná, že se přesunul na jiný server. Je neustále připojený a jeho aktivní operace se „stěhují“ dle potřeby ze serveru na server. Taková řešení nabízí například společnost IBM na produktech s označením IBM zSeries16 také známé jako „Mainframe“ nebo „S/390“. Servery této třídy mají unikátní vlastnost pro vysokou dostupnost. Dva takové servery můžeme spojit do „Paralell Sysplex“ zjednodušeně řečeno, servery mohou pracovat jako jeden, ačkoliv jsou odděleny i na větší vzdálenost. Duplikují, replikují vše důležité a umožňují okamžitý fail-over na druhý uzel v rámci HA clusteru. Další možností jsou Non-Stop servery od společnosti HP dříve produkty společnosti Tandem. Aplikace volíme tedy tak, aby umožňovaly automatické přesouvání zátěže bez nutnosti instalace dalšího obslužného softwaru, jakým je cluster. Tato vlastnost je již posunuta do vlastních aplikací. Aplikační servery všech předních firem mají takovou funkcionalitu. Aplikační servery jsou většinou napojeny na databáze a zde je asi největší problém. Databáze je tedy klíčovou částí návrhu a je potřeba zajistit co nejoptimálnější nasazení a vhodný výběr DB stroje v závislosti na hardwarové platformě. Jak tedy zajistit aby DB stroj byl aktivní jako více uzlový cluster a byl schopen odpovídat z jiného uzlu? Existují v podstatě jen dvě možná řešení. Společnost Oracle nabízí produkt

16

zSeries – „z“ znamená zero downtime, tedy bez výpadkový provoz. 21

RAC17, který disponuje logikou, kdy na dva a více serverů instalujeme DB stroj a propojíme je navzájem do online clusteru. Toto řešení pracuje s jedním datovým prostorem, který je možné pomocí LVM nebo RM distribuovat na další, fyzicky oddělené pole. Poškození dat špatným zápisem je tedy opět fatální problém. Druhou možností je replikace a rychlý fail-over na záložní server. Tuto technologií disponují produkty IBM DB2 HARD, Informix Enterpise Replication, Sybase Replication Server, Progress DB Replication a další. V případě IBM DB2 je například fail-over možné zajistit za 11 sekund. To je velmi krátký čas, po který uživatel může narazit na problém zápisu dat. Pokud se tak opravdu stane je poslední nepotvrzená transakce vrácena zpět a uživatel je vyrozuměn, že došlo k chybě. Pokud operaci zopakuje tak s největší pravděpodobností úspěšně projde bez problémů na druhém serveru, který nahradí v mezičase primární server. Výhody a nevýhody obou řešení jsou zřejmé. Pro Oracle RAC především hovoří teoreticky bezvýpadkový provoz a neustálá online služba. Pravdou je, že i toto řešením má svá úskalí. Podívejme se na následující porovnání z mnoha pohledů, které nejlépe vypovídají o jednotlivých vlastnostech řešení.

17

Oracle RAC – Real Application Cluster – online cluster více uzlů DB strojů. 22

Tabulka 5: Porovnání dostupnosti DB řešení pro vysokou dostupnost. Vlastnost Oracle RAC Diskový prostor Jeden pro všechny RAC DB uzly Čas fail- over Teoreticky 0s. Praxe ukazuje „zmrazení“ celého clusteru po dobu re-konfigurace v řádech sekund. Výkon clusteru Výkon všech uzlů se sčítá. Režie clusteru je cca do 7 % a závisí na počtu uzlů. Tedy cluster 2 serverů disponuje výkonem cca 193 %.

DB Replication Hodnocení Fyzicky oddělené nezávislé Výhoda DB Replication diskové prostory Jednotky sekund Shodné

Plánovaný servis Upgrade OS + DB, které mají vliv na kompatibilitu dat je nutné provést najednou na všech uzlech. Pak rozběhnout službu. Nelze udělat bez výpadku. Vzdálenost mezi Většinou LAN/SAN do uzly vzdálenosti v jednotkách km, v závislosti na latenci interní komunikace clusteru.

U IBM DB2 je možné udělat Výhoda DB Replication upgrade jednoho serveru a pak druhého. Replikace jsou kompatibilní na různých verzích DB. Lze udělat bez výpadku. Většinou LAN/SAN do Shodné vzdálenosti v jednotkách km, v závislosti na latenci interní komunikace clusteru.

Celkové hodnocení

Replikace disponují nezávislostí na diskovém úložišti vynikají delší vzdáleností a jsou v některých případech nezávislé na plánovaných odstávkách z důvodu upgrade.

RAC disponuje větším výkonem součtem všech serverů. Naopak zásadní nevýhodou je nutnost plánované odstávky pro případ upgrade a závislost na jednom datovém úložišti i když duplikovaném.

Pouze jeden server na 100 %. Výhoda Oracle RAC Režie pro replikační službu je zanedbatelná. Maximální výkon je vždy jen 100 % jednoho serveru pro zápis. Čtení je možné realizovat i ze záložního serveru.

Oracle RAC: + vyšší výkon - dostupnost DB Replication: + dostupnost - výkon proti RAC

Zdroj: Vlastní.

Náklady na pořízení infrastruktury budou nesrovnatelně vyšší oproti předchozím variantám. Z uvedených informací a eliminace rizik je vhodné infrastrukturu budovat na prověřených a spolehlivých technologiích. Praxí ověřená infrastruktura by měla vypadat takto. Servery s operačním systémem UNIX s garantovanou vlastní dostupností alespoň 99,99 %. Jedná se tedy o spolehlivost hardwarových a všech komponent. Pro příklad uvádím informaci dostupnosti získaný pro server IBM PowerSystems 570. Uvedené výsledky neobalují vliv operačního systému a ignorují možné externí vlivy, jako mohou být výpadek elektrické energie, chlazení nebo jiné cizí zavinění s přímým vlivem na výpadek serveru. Je to tedy posouzení pouze vlastního hardwaru serveru. 23

Tabulka 6: Příklad dostupnosti pro server IBM pSeries 570. Server IBM pSeries 570 - 16CPU, 128GB Memory, 12 I/O Adapters, 8 X 73,4 GB Stabilita 0,914 výpadků / rok Stabilita 0,079 neplánovaný výpadek / rok MTTR 4 hodiny Dostupnost 0,99996 (99,669 %) MTBF 1,094 roků MTBUIRA 12,65 roků

Zdroj: Interní IBM dokument „Letter 116“ zhotovený na požadavek získání dostupnosti pro server IBM pSeries 570. Důležité jsou především hodnoty pro dostupnost, MTTR18 a MTBUIRA19.

Disková pole je vhodné volit z třídy High-end. Do kalkulace jsem použil pole DS8100 s propracovanou technologií monitoringu. Pro náš příklad je toto pole poněkud zbytečně naddimenzované s ohledem na požadovanou kapacitu pouze 1 TB. Disková pole této třídy jsou většinou určena pro desítky TB. Infrastruktura pro vzájemné propojení je potřeba dvojice SAN přepínačů. Ideálním produktem pak bude přepínače od společností Brocade nebo Cisco. V kalkulaci jsem použit prvky Brocade z důvodu přítomnosti 8 Gb Fibre Channel technologie. Operační systém a cluster software je potřeba použít spolehlivý systém tedy UNIX. Pro návrh jsem využil nabídku operačního sytému AIX 6.1 a jeho podporu pro clustering – software PowerHA. Aplikace a databáze při návrhu již musíme uvažovat o všech scénářích možných příčin výpadku a následné obnovy. Ideální je vždy použít aplikační a databázový server od jednoho softwarového dodavatele jakou jsou IBM, Oracle, Sybase. Pečlivě projdeme vlastnosti jednotlivých produktů a vybereme nevhodnější kombinaci, tak aby vše fungovalo správně. Výběr nám také musí umožnit nasazovaná aplikace. Mnohdy jsou dodavatelé aplikací svázáni s jedním dodavatelem a nelze výběr provézt, v horším případě je omezení i na serverovou platformu a potřebný operační systém. Zde je pak řešení dané možnostmi aplikací. Tedy pozor při výběru aplikace zda nejde o produkt těsně svázaný s platformou, která nemusí zcela vyhovovat. Kvalitní produkty se vyznačují používáním

18 19

MTTR - The Mean Time to Repair – průměrná doba opravy techniků IBM. MTBUIRA - Mean Time Between Unscheduled Interrupt Action – střední doba mezi neplánovanými akcemi vedoucí k přerušení provozu. Pokud takový incident nastane, dojde k restartu a systém naběhne v degradovaném módu. Uživatel zaznamená výpadek. 24

obecných technologií a podporou více DB strojů. Pro vyjasnění uvádím dva příklady, které by měli ukázat rozdílnou možnost nasazení:

•

Příklad 1: aplikace vyvíjená v prostředí Microsoft .Net s možností připojení na Microsoft SQL server.

•

Příklad 2: aplikace vyvíjená v C, C++, Java s možností napojení na DB stroje DB/2, Oracle, Informix nebo Sybase.

Obě aplikace mohou disponovat stejnou funkčností ale jejich nasazení je zásadně rozdílné. Podmínka v příkladu 1 nám přímo diktuje, jak bude vypadat požadavek na platformu hardwaru a použitelného operačního systému. Produkty společnosti Microsoft nelze instalovat na RISC servery s operačním systémem UNIX. Je tedy jednoznačně daná platforma pro nasazení. Tedy x86 servery s Windows 2xxx Servere operačním systémem. A je vybráno! Tento neutěšený stav lze změnit už jen produkty „třetí“ strany. Tedy vylepšeními nebo nadstavbou pro Windows operační systém od jiných dodavatelů jakou jsou Veritas Foundation, Double-Take a mnoho dalších. Příklad 2 je naprosto odlišný od předchozího. Hlavní výhodou je možnost rekompilace nebo úpravy aplikačního kódu pro cílovou platformu. Tedy pokud víme, že cílový operační systém bude Linux, IBM AIX, SUN Solaris nebo HP-UX můžeme docílit ideální funkčnosti a využít vlastností operačních systémů a také hardware na kterém bude provozován. DB vrstva orientovaná na produkty podporující více platforem je také velmi vhodná. Umožní nám opět volbu cílové platformy s ohledem na licenční výhodnost nebo výkonnostní parametry hardware. Do infrastruktury jsem navrhl možnost použití jazyků Java / C++ pro aplikační server s podporou online clusteringu na aplikační úrovni. Vhodné produkty jsou v nabídce firem IBM, Oracle, Sybase, BEA, Progress a další. Pro DB vrstvu je vhodné použití buď online cluster Oracle RAC nebo IBM DB/2 případně jiný DB stroj s podobnými replikačními vlastnostmi. Podle DB vrstvy je pak vhodné použít i aplikační server, Oracle Application Server, IBM WebSphere Application Server nebo jiné inteligentní aplikační servery.

25

Tabulka 7: Celkové náklady na infrastrukturu 99,999 %. Komponenty Popis Hardware Servery 2x PWR570 pro APP a DB Disková pole 2x DS8100 1TB dat Kopírovací služby diskových polí PTC SAN přepínač 2x Boracade 8(24)port 8Gb Zálohování LTO4 mechanika Software Operační systém licence Cluster software Podpora Servery HW SLA 8 hodin FIX 3 roky Disková pole HW SLA 8 hodin FIX 3 roky SW Operační systém 3 roky SW Cluster 3 roky Celkové náklady za 3 roky

DB + WAS Cena v Kč 2 800 000 4 480 000 1 040 000 120 000 50 000 112 000 156 000 1 152 000 1 454 400 232 000 52 800 11 649 200

Zdroj: Vlastní.

Celkové náklady jsou vyčísleny v tabulce č. 7. Návrh nezahrnuje volbu aplikační a DB vrstvy. K ceně je tedy potřeba připočíst cenu za licence softwaru.

2.2.5 Zhodnocení Z uvedených údajů je patrné, jak je potřeba přistupovat ke tvorbě infrastruktury pro hostování aplikací s rozdílným požadavkem na dostupnost. V praxi při určování infrastruktury se většinou postupuje v několika iteracích, kdy nejprve zákazník definuje nejpřísnější SLA – tedy požadavek na 99,999 % a po předložení ceny za řešení ustoupí od tohoto požadavku na úměrnou mez damou finančními možnostmi a rozpočtem. Ovšem jsou i případy, kdy pravdu hodinový výpadek znamená značné finanční ztráty a pokud už zákazník má podobnou negativní zkušenost s nedostupností služby je svolný k vyšším investicím do infrastruktury a tedy i realizaci podobného řešení jak bylo mnou vtrženo. Pro porovnání jsem připravil tabulku č. 8 nákladů na infrastrukturu pro jednotlivé SLA podmínky.

26

Tabulka 8: Závislost požadavku na dostupnost a ceny za pořízení infrastruktury. Časové období 1 rok 365 dní 8 760 hodin 525 600 minut Náklady Kč

SLA 99,9 % 99,99 % 99,999 % 0,365 0,0365 0,00365 8,76 0,876 0,0876 525,6 52,56 5,256 780 000 2 300 000 12 000 000

99 % 3,65 87,6 5 256 450 000

Zdroj: Vlastní.

Z uvedené tabulky č. 8 vyplývá náročnost investice vzhledem k požadovanému stupni dostupnosti. Pro ilustraci jsem doplnil obrázek č. 3 znázorňující graf závislosti požadavků na SLA a nákladů spojených s realizací potřebné infrastruktury. Obrázek 3: Graf závislosti nákladů, možného výpadku pro různé SLA podmínky.

14 12 10 8 6 4 2 0

100 80 60 40 20 99 %

99,9 %

Cena za řešení

450 000

780 000

Možný výpadek

87,6

8,76

99,99 %

99,999 %

Možný výpadek (h)

Náklady na relizaci (Mil. Kč)

Náklady na dostupnost infrastruktury

0

2 300 000 12 000 000 0,876

0,0876

Zdroj: Vlastní.

2.3 Zotavení z katastrofy DR je všeobecně používanou zkratkou pro „Disaster Recovery“ tedy zotavení z katastrofy, která zničila primární datové centrum. Stupňů řešení DR je mnoho a jsou zpracovany do kategorií podle následujících požadavků:

•

Čas obnovy data centra a opětovný chod infrastruktury. Jedná se o definici času, za kterou je potřeba zajistit opětovný chod infrastruktury ze záložní lokality. Předpokládá se přítomnost minimální hardware konfigurace pro dostatečný chod firmy v krizových podmínkách.

•

Akceptovatelná velikost dat, která budou ztracena důsledkem katastrofy. Množství dat, která nebyla přenesena do záložní lokality. Zpravidla se jedná o časové období mezi provedenými zálohami dat a přenesením na záložní lokalitu. 27

Technologie užívané pro DR jsou obdobné technologiím užívaným při návrhu HA řešení. Následující obrázek č. 4 vypovídá o základním principu, jak DR vypadá v praxi. Obrázek 4: Schéma architektury DR.

Zdroj: Vlastní.

Produkční lokalita je hlavní data centrum, kde je vybudovaná veškerá infrastruktura s požadavky na vysokou dostupnost pro aplikace i data. Lokalita DR je záložní data centrum vzdálené od produkční lokality tak, aby byl eliminován vliv možné katastrofy. Při definici katastrofy a jejího vlivu na chod infrastruktury je potřeba dbát na následující body:

•

Chyby infrastruktury a obsluhy. Hardware, software, komunikace sítě LAN, SAN, WAN, pracovní podmínky, zdravotní nebezpečí a další, legislativní omezení.

•

Násilné činy. Teroristický útok, sabotáž, epidemie, lidská chyba, hacking a další.

•

Povětrnostní vlivy. Zemětřesení, povodně, požár, tornáda, větrné bouře, sopečná činnost a další.

Každý zákazník podle regionu, politické situace a mnoha dalších podmínek definuje možná rizika výpadku infrastruktury. Dále definuje vliv výpadku na jeho klíčový business a dopad na hospodářský výsledek firmy. Otázka rozpočtu a velikosti investice pro vybudování DR lokality je důležitým ukazatelem, jak bude vypadat stupeň DR řešení.

28

2.3.1 Možné varianty DR řešení IBM definuje DR koncept v 7mi stupních podle požadavku na kontinuálnost provozu – „Business continuity“. Ke každému stupni navrhuje řešení, jak by měla vypadat infrastruktura a přenos dat. Následující obrázek č. 5 nejlépe vystihuje změny návrhu obnovy dat při zvyšování stupně, tedy zkrácení času obnovy. Tyto třídy jsou dále rozděleny do těchto segmentů:

•

Kontinuální dostupnost pro třídu

7

•

Rychlá obnova dat pro třídy

6–4

•

Záloha – obnova pro třídy

3–1

Jednotlivé segmenty jsou především určeny dobou, za kterou potřebujeme obnovu provést. Obrázek 5 Třídy business kontinuity a vliv doby obnovy dat na použité technologii.

Zdroj: IBM System Storage Business Continuity Solutions Overview dostupný na www.redbooks.ibm.com.

Z obrázku je zřejmé, že data budou v závislosti na třídě a tedy na požadavku doby obnovy zálohována a obnovována různými technologiemi. Pro kratší čas bude nutné obnovu provádět z disků a naopak pro delší časové období je možné využívat záloh na páskových systémech. Projděme si tedy jednotlivé třídy z pohledu technologie pro infrastrukturu. Jaké jsou jejich rozdíly a dopady na cenu řešení.

29

2.3.2 Třída 7 Nejvyšší třída, kdy očekáváme obnovu data centra v řádech několika minut. Pro splnění těchto požadavků je nutné, aby obě lokality tedy produkční a DR byly v synchronním stavu. Ideální by bylo, kdyby DR lokalita byla navržena tak, aby byla také produkční. To znamená, že infrastruktura mezi centry bude na takové úrovni, aby bylo možné provozovat aplikace a ukládat data na obě lokality najednou – tedy aktiv / aktiv provoz. Požadavky jsou v tomto případě především na průchodnost sítí LAN a SAN, které propojují datová centra. V dnešní době je již možné propojit datová centra v rozumné vzdálenosti na velmi rychlém spojení. Pro sítě LAN je postačující 1 GB Ethernet propojení. Na SAN sítích se bez problémů dosahuje rychlosti 4 GB na vzdálenost až 10tky km. Což je dostačující pro vybudování vhodné DR lokality s ohledem na lokální rizika. Po tento příklad uvádím nejběžnější příklad z praxe, který je užíván pro zajištění DR stupně 7. Obrázek 6: Příklad DR infrastruktury pro třídu 7.

Lokalita Produkce

Lokalita DR Server APP/DB

Server DB/APP

HA cluster (LAN, SAN) DB Replikace (LAN)

LW 4Gb SAN Infrastruktura LW 4Gb

Diskové pole

Remote Copy (SAN)

Diskové pole

Zdroj: Vlastní.

Z obrázku č. 6 je zřejmé propojení obou lokalit na vzdálenost, kdy jsme schopni udržet přenosové rychlosti. To je důležité především pro zajištění synchronních dat v obou lokalitách. Navržené řešení by mělo splňovat následující požadavky. Přístup klientů je balancovaný mezi obě data centra tak, aby byla zátěž rovnoměrně rozložena podle potřeby. K tomu je potřeba vybudovat LAN síť s inteligentními směrovači

30

disponující funkcí „Load Balancing“, tedy rozklad zátěže přicházející od klientských počítačů. Aplikace musí být rozděleny podle potřeby opět rovnoměrně, aby bylo možné odpovídat na dotazy klientů nezávisle na tom, do kterého datového centra je dotaz směřován. V případě inteligentních aplikací a aplikačních serverů je řešení poměrně snadné. Provede se instalace aplikace na více nezávislých serverů v obou lokalitách a zajistí se jen vlastní cluster podpora samotnými aplikačními servery. Inteligentní LAN prvky už zajistí, aby se rozložila zátěž na všechny servery disponující danou aplikací. Pro databáze platí v tomto případě stejná pravidla jako pro HA řešení. Tedy je možné použít Oracle RAC cluster nebo Replikace DB v případě ostatních produktů od IBM, Sybase a dalších. Vždy ovšem platí, že při dotazování aplikačních serverů směrem k DB nastává poměrně intenzivní komunikace a proto je potřeba vhodně dimenzovat propojení mezi lokalitami. Řešení Oracle RAC sice eliminuje tuto komunikaci mezi aplikačními a DB servery na společnou lokalitu, ale za to vyžaduje speciální linku mezi servery, po které probíhá intenzivní komunikace pro zajištění provozu. Infrastruktura je tedy klíčovým prostředkem jak vůbec zajistit aktiv/aktiv fungování obou data center. Je zřejmé, že se nevyhneme vyšším investicím nejen do vlastních LAN a SAN aktivních prvků, ale také do vybudování nebo pronajmutí komunikačních linek mezi lokalitami. Obecně platí, čím větší vzdálenost a požadavek na propustnost, tím komplikovanější a samozřejmě nákladnější konfigurace potřebných prvků. Konfigurace LAN i SAN sítě by měla z pohledu serverů vypadat tak, že se jedná v každém případě o jednu redundantní síť. V praxi to znamená, že použijeme redundantní produkty, které jsou již vyrobeny tak aby poskytovaly potřebnou redundanci. Druhou možností je použít fyzicky oddělené boxy – tedy místo jednoho redundantního přepínače dva. Jak je patrno z předcházejícího obrázku č. 6 do každé lokality je umístěna dvojice SAN přepínačů. Ty jsou pak propojeny vždy každý zvlášť s přepínačem ve druhé lokalitě pomocí LW20 technologie. Tím je zajištěna plná propustnost mezi lokalitami pro data po dvou oddělených vláknech.

20

LW – Long Wave je technologie jak propojit Fibre Channel zařízení na větší vzdálenosti. 31

Data jsou obdobně jako v případě HA synchronizována mezi lokalitami pomocí všech dostupných technologií se všemi vlastnostmi, které s sebou nesou. Fail-over je zcela automatický a využívá se pro něj automatické funkce cluster podpory operačních systémů. V tomto případě se DR od HA řešení neliší ničím, až na větší vzdálenost a rozdělení infrastruktury do dvou datových center a tím větší investice právě do jejich propojení.

2.3.3 Třída 6 – 4 V těchto třídách je výpadek již v jednotkách hodin. Zde je nejčastěji vyžadována asistence administrátora, který rozhodne, zda se má udělat fail-over na záložní lokalitu či nikoliv. Administrátor zjistí, zda nejde jen o planý poplach a teprve po vyhodnocení situace udělá manuálně zásah, fail-over operaci. Infrastruktura pro tyto stupně je již poněkud jednodušší a předpokládá se možný výpadek několika hodin, během kterých je dostatek času pro plánované nastartování záložní lokality. Nejdůležitější pro obnovu provozu je opět přítomnost dat v DR lokalitě. Jejich kvalita v porovnání s produkční lokalitou je daná zvolenou technologií přesunu dat. Nejčastěji je využívána DB replikace. Požadavek na infrastrukturu je omezen jen na LAN/WAN síť, protože DB replikace využívají pouze tuto cestou. Navíc není potřeba používat technologicky kompatibilní pole jako v lokalitě produkční pro ukládání dat. Druhá možnost je Remote Mirroring. Zde je ale vyžadováno technologicky kompatibilní diskové pole a SAN infrastruktura potřebné propustnosti pro synchronní spojení diskových polí. Alternativně je možné pro nižší požadavky na časové obnovení použít okamžitých kopií dat, které se pak přesunou do záložní lokality kopírováním prostřednictvím například GLVM21 nebo vystavení kopie dat jako NFS22. Data je pak možné kopírovat prostřednictvím LAN sítě a není potřeba budovat náročnou SAN infrastrukturu. To ovšem platí tehdy, pokud jsme schopni data přesunout v požadovaném časovém okně, které nám vyplývá z požadavku na obnovu. Pokud jsou data kopírována na DR lokalitu, je možné v případě katastrofy rozhodnutí administrátora o přesunu produkce do DR lokality, pokud to bude nezbytně nutné.

21 22

GLVM – Geographic LVM – rozšíření LVM o možnost vzdálené správy a zrcadlení dat. NFS – Network File Systém – souborový systém přístupný po síti LAN/WAN. 32

Takto se postupovalo u firem, které měly primární datová centra v Praze Holešovicích při záplavách v roce 2002 a měly vybudované DR lokality na jiných místech v Praze a okolí. Následující tabulka č. 9 zhodnocuje jednotlivé řešení podle vlastností replikací dat, kterými disponují. Nelze jednoznačně říci, které z řešení je lepší a které je horší. Vždy se musí řešet případ od případu. Argumenty pro konkrétní řešení budou ovlivňovat mnohé parametry, o kterých jsem se již zmínil v této kapitole. Především je to velikost dat, možnost jejich ztráty definovaná v DR konceptu, požadavky na vzdálenost lokalit a

času potřebného na fail-over. Pokud máme tyto informace, můžeme vybrat správné a také dostatečné řešení DR konceptu s ohledem na rozpočet, který nakonec ovlivní celkový návrh nejvíce. Tabulka 9: Přehled vlastností replikace dat pro jednotlivé DR řešení. Řešení replikace DAT Vzdálenost

Náklady

Rozšíření

Infrastruktura

Hodnocení

OS LVM, GLVM 4Gb do 150m, 2 Gb/s do 250m a 1 Gb/s do 500m. Pro větší vzdálenosti je potřeba LW propojení. Na větší vzdálenost LW komponenty (Gbic) v aktivních prvcích a FC linka mezi lokalitami.

Nad 500m je potřeba LW Gbic potřebného výkonu například 10km a vhodné linky. Nutné pořídit LW Gbic do SAN switchů a dimenzovat propojení včetně počtu FC vláken. Nejjednodušší řešení a cenově nejpříznivější. Vzdálenost lokalit je závislá na výkonu infrastruktury a její latenci. Pro větší datové objemy je toto řešení nevhodné. V případě re-synchronizaci zrcadlení disků LVM manažerem by nastala dlouhodobá utilizace

Remote Mirroring diskových polí 4Gb do 150m, 2 Gb/s do 250m a 1 Gb/s do 500m. Pro větší vzdálenosti je potřeba LW propojení. Aktivace funkcionality na diskových polí. Většinou za oplatek. Dále na větší vzdálenost LW komponenty (Gbic) v aktivních prvcích a FC linka mezi lokalitami. Nad 500m je potřeba LW Gbic potřebného výkonu například 10km a vhodné linky. Nutné pořídit LW Gbic do SAN switchů a dimenzovat propojení včetně počtu FC vláken. Vyžaduje pokročilé funkce diskových polí a dokáže eliminovat problémy předchozí varianty (LVM). Není závislá na velikosti dat. Spíše je toto řešení zvoleno pro velké datové objemy. Replikace na pozadí diskových polí navíc nezatěžuje servery a poskytuje ma

Zdroj: Vlastní. 33

DB Replikace Omezená propustností LAN/WAN – až 100ky km

DB replikační nástroje. Buďto obsažené v DB stroji nebo nadstavbový produkt. Existuje i možnost využití produktu třetích stran pro náš DB stroj. Propustnost LAN/WAN

Pronájem větší propustnosti. Většinou levnější a dostupnější než u FC linek. DB Replikace jsou nejpoužívanější řešení pro prostředí, kde potřebujeme do DR lokality kopírovat pouze DB data. Ostatní data musíme zajišťovat jiným způsobem. Často je v Enterprise prostředí doplněno o RM nebo LVM pokud je to možné. Pokud je doplněno o RM

2.3.4 Třída 3 – 1 V těchto třídách se předpokládá vytvoření off-site23 kopií zálohovaných dat, které jsou uchovávány na bezpečných místech. Ideálně pokud jsou převáženy do DR lokality, kde jsou ukládány do trezoru pro potřebu obnovy dat v případě zničení produkčního datového centra. V lepším případě jsou použity pro kopírování dat na diskové pole DR lokality a tím je zároveň ověřeno, zda zálohovací systém pracuje správně a máme data skutečně aktivně zálohována. Při použití této metody pro zálohování datového centra je jasné, že naše poslední data jsou ta, která máme na posledních zálohovacích médiích. Proto je potřeba s nimi podle toho zacházet. Obnova provozu z DR lokality je pak dána množstvím dat, která přenášíme a stavem infrastruktury, kterou máme v DR lokalitě připravenou. Z praxe jsou známé i příklady, kdy zákazník má přesně definovaný seznam potřebného hardware pro obnovu a ten mu zajišťuje smluvní partner pro případ obnovy data centra. Osobně nevlastní žádný hardware, jen má za poplatek ošetřený servis typu „Business Continuity Service“. Tento systém zajištění dostupnosti vlastní služby cizím subjektem již přechází v částečný outsourcing.

23

Off-site – kopie, zálohy dat, které jsou uchovávány mimo hlavní datové centrum. 34

3

Efektivní využívání hardwarových zdrojů

Důvod, proč je virtualizace citována téměř v každém článku, který je dnes publikován, je celkem zřejmý. Počty serverů rapidně narůstají a je potřeba řešit jejich efektivní využívání. Z vlastní zkušenosti mohu potvrdit, že průměrná utilizace serveru s architekturou x86 je cca 15 % a pro RISC architekturu cca 25 %. Na první pohled to může vypadat nereálně, protože každý z nás má pocit, že server, na kterém právě pracuje, je málo výkonný a potřeboval by přidat nějaký ten výkon navíc nebo rovnou vyměnit. Jak to tedy je s průměrným využitím výkonu serveru. Pro zajímavost jsem použil výkonový snímek serveru, používaného ve společnosti, kde slouží pro výrobu, fakturaci, expedici atd. Obrázek 7: Snímek utilizace procesorů serveru IBM System p 560. CPU Total a00 30.1.2007 User%

Sys%

Wait%

100 90 80 70 60 50 40 30 20 10

21:11

20:41

20:11

19:41

19:11

18:41

18:11

17:41

17:11

16:41

16:11

15:41

15:11

14:40

14:10

13:40

13:10

12:40

12:10

11:40

11:10

10:40

10:10

09:40

09:10

08:40

08:10

07:40

07:10

06:40

06:10

05:40

05:10

04:40

04:10

03:40

03:10

02:40

02:10

01:40

01:10

00:40

00:10

0

Zdroj: IBM Global Services – monitoring serveru zákazníka v ČR.

Z uvedeného obrázku č. 7 je patrné, že server je ve špičce vytížen na maximálně na 50 %, ale v průměru je vytížení podstatně menší. Tento příklad je poněkud odlišný, než je běžná praxe. Většinou se projevují v klasické obchodní firmě 3 špičky za den. Jedná se o příchod pracovníků do kanceláří a dopolední agenda. Druhá špička nastává odpoledne po obědě a končí odchodem zaměstnanců domů. Třetí fáze je servisní, která nastává po odchodu pracovníků. Systémy začínají zpracovávat dávkově data, replikovat je do jiných systémů a nakonec proběhne denní záloha. Tyto činnosti musí být hotové před příchodem zaměstnanců další den. Pokud si představíme, že takto vypadá normální běh všech serverů ve všech společnostech tak je zde otevřená otázka co s výkonem serverů po dobu, kdy je nikdo nepotřebuje.

35

Odpovědí na mnoho podobných otázek je serverová virtualizace.

3.1 Virtualizace serverů Virtualizace je technologie, která je jednoznačně přináší největší úspory nejen při konsolidačních projektech, ale také při nasazování aplikací v malých a středních firmách. Existuje mnoho systémů pro virtualizaci hardware zdrojů. Nejefektivnější jsou koncepty pracující přímo na úrovni samotného hardware. Existují i software nadstavby, které emulují virtualizační vrstvu jako nadstavbu hardware, který nedisponuje vlastní virtualizační technologií. Na obrázku č. 8 je znázorněný princip virtualizace. Větší množství malých nebo málo výkonných serverů je konsolidováno do virtuálních serverů nad jedním nebo více výkonnými servery. Předpokladem úspěchu je vyřešení nízké vytíženosti malých serverů a naopak zajištění daleko vyšší vytíženosti větších serverů.

Virtuální server 6

Virtuální server 5

Virtuální server 4

Virtuální server 3

Virtuální server 2

Virtuální server 1

Obrázek 8: Blokové schéma konsolidace a virtualizace serverů.

Zdroj: Vlastní.

Důležitou vlastností operačních a vizualizačních systémů je oddělení jednotlivých aplikací s nejvyšší možnou bezpečností tak, aby nebyly vzájemně ovlivnitelné. Pro certifikaci

36

bezpečnosti je certifikát CAPP/EAL24 s nejvyšší dosažitelnou úrovní 4+. Mezi vlastnosti každé virtualizace je úroveň schopnosti sdílet hardware zdroje (procesory, paměť, adaptéry) a jejich přesun pokud možno dynamicky bez případných restartů. Nedílnou součástí je provozní režie samotného virtualizačního systému. Systémy s nejnižšími nároky na hardware pro vlastní běh jsou pro použití nejefektivnější. Zde je preference na hardware orientované systémy.

3.1.1 Přehled vizualizačních technologií Virtualizační technologie jsou dnes poměrně rozšířené a existuje mnoho konceptů jak více

či měně efektivně dokážeme dostupné hardware zdroje virtualizovat a za jakou cenu toho dosáhneme. Přičemž cenou je v tomto případě uvažována režie systému, tedy jaký výkon ztratíme, pokud budeme server virtualizovat. Pro ilustraci jsem doložil tabulku č. 10 všech typů dostupných virtualizačních technologií a jejich rozdělení do kategorií podle vlastností.

24

CAPP/EAL - Secured Environment for Mission Critical Applications. Certifikovaná bezpečnost pro operační systémy. 37

Tabulka 10: Rozdělení virtualizačních technologií podle vlastností Virtualizační Hardwarově dělený princip server na fyzické nebo logické oddíly Popis Server je dělený do principu segmentů s vlastní verzí operačního systému Dělení je po procesorových kartách nebo logicky po jednotlivých celcích

Dostupné technologie

Hypervizor firmware hardware

Hypervizor je instalován na operační systém serveru Hypervizor poskytuje Hypervisor používá jemné sdílení všech služeb operačního zdrojů jako firmware systému pro sdílení serveru všech zdrojů Další možností je instalace hypervizoru přímo místo operačního systému na vlastní hardware Dělení na úrovní CPU System z PR/SM and VMware GSX karty z/VM Microsoft Virtual S/370 SI->PP & PP- PowerVM hypervisor Server >SI, VMware ESX Server HP Integrity VM Sun Domains, HP Xen Hypervisor User Mode Linux Microsoft Hyper-V Linux KVM nPartitions Dělení na úrovní CPU SUN Containers IBM WPAR jádra/vlákna IBM POWER4 LPAR HP vPartitions Sun Logical Domains

Zdroj: Vlastní.

V předchozí tabulce č. 10 jsou virtualizační technologie rozděleny do tří základních skupin podle vlastností. Jak je zřejmé, ke konceptu virtualizace je možné přistoupit mnoha způsoby.

3.1.1.1 Hardwarové dělení serveru Hardwarové dělení serveru na úrovni CPU karty, je koncept dělení serverů podle základních stavebních komponent. Nejčastěji se prezentuje jako fyzické dělení serverů od společností HP a SUN. Servery připomínají architekturou nezávislé procesorové karty (SUN Uniboard, HP Cellboard) s vlastní I/O25 adaptery a propojením na centrální propojovací sběrnice. Pomocí této sběrnice je pak možné navyšovat počty procesorových karet až na několik desítek. Pro dělení serveru je pak většinou použito dělení po těchto jednotlivých procesorových kartách. V případě SUN Dynamic Domains26 je možné

25 26

I/O – Input / output – vstupně výstupní adaptery a sběrnice. Dynamic Domains – technologie společnosti SUN Microsystems pro dělení HW zdrojů. 38

dosáhnout dělení na ¼ procesorové karty, což odpovídá, 1 CPU a 8 DIMM27. U společnosti HP disponuje technologie nPar pouze jedinou možností dělení na celé Cellboard procesorové karty, což představuje, 4 CPU socket28 a 16 DIMM.

3.1.1.2 Hardwarové dělení serveru na úrovni CPU jádra nebo vlákna je schopnost dělení na jednotlivá procesorová jádra nebo dokonce vlákna, která procesorová jádra zpracovávají. Prvotní technologii LPAR29 uvedla IBM v roce 2001 a tím odstartovala novou éru dělení hardware zdrojů na menší díly. Byl představen koncept Hypervizoru30, který poskytuje všechny hardwarové zdroje dále do serverů. Ačkoliv je zmíněna již technologie Hypervizoru je jeho úroveň ještě nevyzrálá natolik abychom ji mohli zařadit do vyšší kategorie. Dělení serveru probíhalo na úrovni celého procesorového jádra, 256 MB RAM a 1x I/O PCI slot. Daleko pokročilejší je dnešní technologie společnosti SUN Logical Domains (LDom). Jedná se o logické dělení serveru. Tedy mnohem pokročilejší technologie s větší flexibilitou. Technologie LDom je používaná na T1 a T2 čipech a dokáže logicky rozdělovat jednotlivá vlákna těchto procesorů. Na následujícím obrázku č. 9 uvádím příklad, jak by bylo možné takový server rozdělit. Základní podmínkou je přítomnost řídící domény, která by podle doporučení měla mít přidělená 4 vlákna 1 GB RAM a ½ I/O kapacity celého serveru. Ostatní LDom mohou mít minimálně jedno procesorové vlákno a přidělenou minimální RAM. Pokud přidělujeme I/O kapacitu, pak můžeme využit jak přímý přístup prostřednictvím I/O adapterů - viz LDom A na obrázku č. 9 nebo používat virtuální adaptéry a využívat fyzické adaptery v řídící doméně jak je patrné u LDom B a C. Tato technologie již umožňuje přesouvání volných procesorových vláken mezi LDom zcela dynamicky a nevyžaduje restart žádné z LDom.

27

DIMM – slot pro RAM paměťový modul. Socket – patice pro procesory. Je osazována jedno nebo více jádrovými procesory. 29 LPAR – IBM Logical Partitioning – logické dělení serveru. 30 Hypervizor – vrstva firmware serveru, která poskytuje virtualizační vlastnosti pro další zpracování. 28

39

Obrázek 9: Blokové schéma rozdělení serveru SUN s procesory T1/T2.

Zdroj: Vlastní.

Další dostupnou technologií jsou HP vPar. Jedná se o přibližně stejnou technologii srovnatelnou s IBM POWER4 LPAR. Tedy dělení serveru je zde omezeno na dělení v rámci jedné nPar běžící na jedné nebo více Cellboard procesorové karty a minimální možnost dělení hardwarových zdrojů je na 1 CPU a 64 MB.

3.1.1.3 Hypervizor software nebo firmware běží přímo na serveru Jedná se z pohledu správy zdrojů o nejefektivnější řešení. Virtualizační technologie ještě rozdělujeme na dvě podle způsobu provedení, kdy hypervizor je přímo spojený s hardwarem serveru (IBM PowerVM) a je součástí firmware nebo je součástí operačního systému (VMware ESX) instalovaného na holý hardware. První zmíněný koncept virtualizace má mnohaletou historii a vývoj spojený s platformou IBM Mainframe. Postupem času byla tato technologie implementovaná do dalších produktových řad serverů společnosti IBM. Základem pro všechny produkty je virtualizační vrstva hypervizoru. Ten zprostředkuje abstrakci hardwarových komponent a zajišťuje veškerou potřenou flexibilitu, kterou dnes od takového systému očekáváme. Dělení procesorového výkonu mezi logické nebo virtuální servery a sdílení poskytovaného výkonu na základě přidělených priorit. Stejnou funkcionalitu je již možné zajistit i pro operační paměť RAM, což bylo do nedávna nemožné. Sdílení I/O adapterů je další důležitou vlastností při redukování jejich počtu a tím i požadavků na propojovací infrastrukturu LAN a SAN sítí. 40

Druhý koncept je poněkud odlišný a vychází z neschopnosti samotného hardwaru takové služby poskytovat. Masivně používaným konceptem, který dále popisuji, je VMware. Jedná se v podstatě o stejný systém co do funkčnosti jako předchozí IBM PowerVM s drobnými odlišnostmi. Jako nosnou hardwarovou platformu využívá VMware jedině x86 servery. Což je asi jedinou vážnější nevýhodou tohoto konceptu. Není tedy odolný proti některým výpadkům hardware, i když světoví výrobci se snaží tento nedostatek eliminovat v co možná nejvyšší možné míře. VMware se tedy instaluje přímo na hardware místo operačního systému. Zde zastává pozici hypervizoru. Do této vrstvy jsou poté instalovány virtuální servery s operačními systémy běžně používanými na x86 platformě. Na rozdíl od konceptu IBM PowerVM, zde není možnost přidělování fyzických adapterů přímo do virtuálních serverů. Hypervizor vlastní veškeré dostupné zdroje, což může vést k nemožnosti nasazení některých serverů s požadavky na fyzické adaptery do virtuálního prostředí. Většinou se ale jedná o infrastrukturní servery, které beztak není vhodné integrovat do virtuálního prostředí.

3.1.1.4 Hypervizor jako nadstavba operačního systému Koncept, ve kterém se hypervizor, tedy virtualizační vrstva instaluje na operační systém, který mu zajišťuje potřebné zdroje, služby a komunikaci s okolním prostředím. Tento koncept je vhodné používat zejména pro testovací nebo vývojové prostředí. Stabilita systému je ovlivněna právě operačním systémem pod vlastním Hypervizorem. V případě, že používáme unixové operační systémy, je možné zajistit celkem rozumnou dostupnost, ale i tak je tento koncept považován za méně bezpečný. Naopak velkou výhodou je redukce administrativních úkonů spojených s administrací více prostředí což je přínosem zejména pro administrátory SUN Solaris a IBM AIX operačních systémů, kde se právě očekává nasazování velkého počtu virtuálních serverů.

3.1.2 Vhodnost jednotlivých konceptů Z pohledu bezpečnosti oddělení jsou jednotlivé koncepty rozděleny podle charakteru fyzické a logické architektury. Nejvyšší možná bezpečnost souběžného běhu dvou serverů je jejich fyzické oddělení. Což je na úkor flexibility, kterou potřebujeme. Ideálním konceptem, který je již prakticky ověřený se ukazuje princip hypervizoru přítomného přímo v hardwaru nebo instalovaný přímo na server. Získáme tím výbornou flexibilitu, dostatečnou bezpečnost a oddělení jednotlivých virtuálních serverů. 41

3.2 Virtualizace pro data Základním principem je konsolidace několika datových systémů pod jednotný interface včetně managementu. Výsledkem je sdružení těchto zařízení úplně nebo částečně do jednoho prostředí, které disponuje celkovou virtualizovanou kapacitou. Jednoznačnou výhodou virtualizace diskových úložišť je, že odděluje host servery od fyzické vrstvy SCSI LUNů na diskových polích a jejich případných změn. Kopírovací a migrační služby mohou probíhat mezi diskovými poli různých dodavatelů a data lze snadno transparentně migrovat bez vědomí serverů. Není neobvyklé, že datová centra používají disková pole od různých výrobců, kdy každé z nich disponuje určitými schopnostmi kopírovacích funkcí, vzájemně však nekompatibilních. Společným prvkem všech tu je FC protokol, po kterém disková pole poskytují data host serverům s nejrůznějšími operačními systémy. Možným řešením je včlenění virtualizační části infrastruktury mezi diskové pole a host server a tím zajistit potřebnou kompatibilitu. Vhodným zařízením pro tyto účely je IBM SVC (SAN Volume Controller). Jedná se o inteligentní zařízení, které disponuje veškerou potřebnou funkcionalitou a virtualizuje SAN prostředí, v němž je možné kopírovat, replikovat data mezi jednotlivými nekompatibilními zařízeními, provádět okamžité kopie, migrace dat apod. Tento způsob virtualizace řeší statickou vazba serveru a diskového pole, neefektivní využívání diskových zdrojů, výpadková migrace dat, nekompatibilní kopírovací služby i nejednotnou správu.

3.2.1 Virtualizace pro disková úložiště Virtualizace diskových systémů je možná prostřednictvím samostatných zařízení nebo jako součást jiných diskových systémů. Zde je potřeba zohlednit možnosti výkonového upgrade nebo bezvýpadkový provoz. Dalším sporným bodem je celková dostupnost navrženého prostředí a nezávislost na konkrétní implementaci, kde by měla být preference na oddělený systém s vlastní logikou, managementem a bezvýpadkovým upgrade na vyšší výkon. Celková propustnost virtualizačního prostředí nesmí mít vliv na výkonnost infrastruktury pro data. Cílem diskové virtualizace je zejména:

•

Zefektivnění kapacitní využitelnosti jednotlivých storage zařízení (hardwarové konsolidace). 42

•

Rozmístění a migrace dat mezi jednotlivými systémy vyšší a nižší třídy podle kategorie/třída (tier) dat (fáze životního cyklu dat, charakter dat dle aplikace apod.), přičemž velkou výhodou je možnost migrovat data za provozu bez nutnosti odstávky aplikace.

•

Zrcadlení dat v rámci lokality nebo mezi lokalitami za účelem ochrany dat před výpadkem systémů.

3.2.2 Virtualizace pásek Principem virtualizace pásek je zjednodušeně řešeno emulace virtuálních páskových mechanik a jejich výměna za rychlejší disky v diskových polích. Produktem pro virtualizaci pásek připojitelný k otevřeným platformám je virtuální knihovna, Virtual Tape Library - VTL. VTL umožňuje vytvářet komponenty fyzických páskových mechanik až knihoven ve velmi vysokém počtu. Mezi hlavní výhody VTL v porovnání s fyzickými páskami patří:

•

Zkrácení času potřebného k zálohování a obnově dat – zrychlení transferu dat při zálohování na disky prostřednictvím velmi výkonného interface (rychlost zálohování až několik Gb/s).

•

Zefektivnění plánování a využitelnosti – VTL umožňuje emulovat v řádech stovek virtuálních knihoven, tisíců virtuálních mechanik a stovek tisíců pásek. Odpadá tedy složitý proces plánování počtu jednotlivých komponent fyzických páskových zařízení, od kterého se odvíjí výkonnost zálohování. Současně nehrozí, že by zařízení nebylo optimálně využito, neboť jej lze konfigurovat přesně podle aktuálních požadavků na výkonnost a kapacitu.

VTL lze aplikovat jako samotný software, který může být implementován na nové nebo i stávající podporované zařízení (server-diskové pole). Další způsob aplikace VTL je samostatné zařízení, které již obsahuje veškeré potřebné komponenty (software-servery-disková pole). Tento způsob však neumožňuje využití stávajících komponent v řešení VTL. Další zajímavostí spojenou s VTL je možnost „deduplikce“ dat. Jedná se o proces, při kterém jsou zálohovaná data indexována a následně analyzována. Duplikace dat jsou pak odstraněny ze zálohování. Tím se podstatně snižuje množství dat ukládaných na VTL.

43

3.3 Bezpečnost virtualizace pro servery a datová úložiště 3.3.1 Nejdůležitější bezpečnostní úskalí u serverů Na prvním místě především ochrana proti virům a útokům na slabá místa daného operačního systému serveru přicházející z externí sítě, ale i ze strany samotných uživatelů uvnitř firmy. Volba prostředí s sebou nese riziko možného útoku na data a služby, které server poskytuje. Operační systémy s bezpečnější architekturou je samozřejmě těžší prolomit. Do velké míry záleží na administrátorech, jaké prvky bezpečnosti nastaví, nicméně zde platí doporučení, že klíčová data a aplikace by měly být nasazovány na prověřené systémy bez každodenní nutnosti aplikovat bezpečnostní opravné balíčky. Jinou možností, jak eliminovat útoky na extranet / internet servery, je využití virtuálních serverů jako IBM WPAR (Workload Partition) SUN Solaris Container. Jedná se o jeden nebo několik virtuálních serverů, které jsou hostované v rámci jedné instance operačního systému AIX nebo Solaris. Každý WPAR, Container pak disponuje vlastním prostředím, které prezentuje směrem k uživatelům. Pokud by u takového virtuálního serveru došlo k výpadku, nemá to žádny vliv na ostatní virtuální servery a je možné ho opět nastartovat v původní konfiguraci nebo okamžitě vytvořit jiný bez nutnosti složité instalace či obnovy ze zálohy. Toto prostředí je pro útočníka natolik specifické, že eliminuje pokusy o útoky běžné u plnohodnotných operačních systémů se všemi systémovými soubory.

3.3.2 Bezpečnosti na úrovni virtuálních serverů Bezpečnost lze posuzovat v rovině útoku na vlastní virtuální server, jak již bylo popsáno. Lze k ní však přistupovat i z pohledu vlastní bezpečnosti na virtualizační vrstvě, tedy jak se virtuální servery mohou navzájem ovlivňovat nebo zdali pád jednoho virtuálního serveru ohrozí ostatní či nikoliv. Virtualizační technologie by měla splňovat mezinárodně uznávané obecné standardy pro informační bezpečnost (Common Criteria for Information Security), a to alespoň na úrovni CAPP/EAL4. Za účelem dosažení vyššího zabezpečení je ideální kombinovat více způsobů virtualizace, jako například virtualizace pomocí hypervizoru a operačního systému.

44

3.3.3 Bezpečnost při zálohování ve virtuálním prostředí Návrh zálohovací strategie by měl dělat odborník, který dokáže kombinovat dostupné technologie v oblasti zálohování. V případě, kdy máte virtuální server s daty, která chcete uložit na zálohovací zařízení, je možné využít agenty zálohovacího systému a posílat data prostřednictvím LAN sítě. Jedná se o bezpečnou cestu vhodnou pro menší datové objemy. Pokud se řídíte kontrolními mechanizmy, nehrozí zde riziko ztráty dat. Dále je možné používat vyspělé technologie diskových polí, která umožňují vytvoření okamžité kopie dat.

Řízení této funkce je většinou iniciované z prostředí, které chcete zálohovat.

3.3.4 Kontinuita provozu na virtuálních serverech Bezvýpadkový provoz je možné řešit takovými prostředky, které jsou schopny přesměrovat uživatelské požadavky na jiný server. Většinou jde o vysoce dostupná cluster

řešení, kde je více serverů se stejnou aplikací a v případě potřeby je zátěž přesměrována na jiný server. Tuto možnost poskytují aplikační servery a některé databáze běžící ve virtuálních prostředích. Zcela jinou otázkou může být, jak přesunout virtuální server jako celek s běžícími aplikacemi a připojenými SAN disky. Důvody pro to mohou být různé - například plánovaná údržba nebo migrace na hardware s jinými vlastnostmi, které v danou chvíli vyhovují (zvýšení/snížení výkonu, příkonu atd.). Technologií se tu opět nabízí několik. IBM například používá IBM PowerVM - Partition Mobility na serverech s procesory POWER6. Logický oddíl serveru či virtuální server je za běhu odsunut na jiný fyzický server bez vlivu na uživatele. Původní server je pak možné opravit, vypnout nebo na něj přesunout jiný logický oddíl či virtuální server. Celá operace probíhá ve virtualizovaném prostředí tak, aby servery byly ve stejných VLAN31 a SAN zónách. Obsah paměti je pak na pozadí kopírován mezi zdrojovým a cílovým serverem a v okamžiku synchronního stavu je možně provést rychlou záměnu při plné funkčnosti.

31

VLAN – Virtual LAN – Virtuální LAN síť ve které spolu mohou komunikovat pouze zařízení se stejným nastavením. 45

4

Aplikační hosting a outsourcing

Aplikační hosting nebo celkový outsourcing je pro mnoho firem řešení, jak se elegantně zbavit náročných příprav na provozování infrastruktury. IT oddělení se jen zeštíhlí na potřebné minimum k zajištění podpory uživatelů. Otázkou je, jak se rozhodnout zda vlastnit IT prostředí a evidovat v majetku zařízení zajišťující provoz klíčových aplikací a zajistit kvalifikovanou správu a dohled profesionální firmou tzv. outtasking, nebo se rozhodnout k totálnímu outsourcingu a pronajmout si kompletní infrastrukturu a dostupnost služby podle SLA kritérií. V současné době jsou využívány obě varianty a na výhodnosti se podílejí především způsoby vykazování hospodářských výsledků danou firmou. Tam kde je tlak na omezování kapitálových výdajů (CAPEX) a přednost je dávána operačním nákladům (OPEX) je jednoznačně preferován outsourcing.

4.1 Poskytované služby ICT Známe pod označením outtasking. Principem je zajištění ICT služeb zákazníkům, kteří chtějí redukovat náklady spojené s budováním rozsáhlého IT oddělení. Investice do kvalitní technické úrovně vlastního personálu jsou nemalé a vyžadují neustálou obnovu díky velmi dynamickému vývoji v IT odvětví. Negativní stránkou je možnost fluktuace kvalitním zaměstnanců díky nedostatku skutečných odborníků. Řešením pro eliminaci těchto negativních jevů může být právě outtasking. Hlavní kritéria jsou:

•

Orientace na konkrétní služby definované zákazníkem.

•

Definice SLA a následné měření výkonnosti.

•

Možnost přechodu na kompletní outsourcing.

•

Možnosti flexibilní změny rozsahu pokrytí služeb.

•

Procesní řízení a přístup ke správě.

•

Komunikace s dodavateli zůstává plně v režii objednatele služeb.

4.2 Kompletní služby ICT Neboli outsourcing je ideální pro zákazníky, kteří se soustředí plně na vlastní byznys a infrastrukturu kompletně přenechávají na odborné firmě specializující se na konkrétní služby. Jedná se většinou o start-up projekty na krátkou dobu, kde se nevyplatí pořizování 46

vlastní infrastruktury. Ze zkušenosti jsou známé krátkodobé projekty na „zkoušku“ nebo naopak dlouhodobé, kde se zákazníci rozhodli přesunout celé IT oddělení mimo firmu a dochází tedy k totálnímu outsourcingu. Hlavní kritéria jsou:

•

Orientace na konkrétní služby definované zákazníkem.

•

Definice SLA a následné měření výkonnosti.

•

Možnost přechodu na kompletní outsourcing.

•

Možnosti flexibilní změny rozsahu pokrytí služeb.

•

Procesní řízení a přístup ke správě.

•

Komunikace s dodavateli přechází plně na poskytovatele služeb. Poskytovatel služeb volí optimální platformu pro provozování aplikací.

Přechodem na strategický (komplexní) outsourcing se stává z vlastníka a provozovatele informačních technologií příjemce IT služeb, které mají jasné určení pro podporu jeho hlavní podnikatelské činnosti. Pojem “strategičnosti“ obchodního vztahu je přitom vnímán v horizontu 5-7 i více roků. Znamená to zejména převedení přímo souvisejících rizik na obchodního partnera prostřednictvím smlouvy o poskytování outsourcingových služeb. Smlouva definuje mimo služeb a cen také garance za parametry a kvalitu. Převod zpravidla zahrnuje:

•

Převedení pracovníků od zákazníka k poskytovateli a ponechání pouze nezbytného množství koordinačních a řídících funkcí (zpravidla IT manažer na provozní úkoly a CIO na strategický vztah mezi IT a oborem podnikání).

•

Převod/odprodej techniky poskytovateli.

•

Uvolnění prostorů (někdy proběhne zpětný pronájem poskytovateli).

Typické přínosy pro zákazníka jsou:

•

Zlepšená kontrola a lepší „vymahatelnost“ úrovně služeb pro uživatele.

•

Komplexní rozkrytí nákladů, s dopadem na snížení nebo zafixování nákladů za správu a rozvoj.

•

Předvídatelnost nákladů.

•

Zlepšení kvality IT služeb.

•

Zvýšení efektivity využití IT prostředků.

•

Náhrada/doplnění vlastních IT pracovních kapacit.

•

Neklesající technická úroveň poskytnuté techniky. 47

•

Vyšší spolehlivost techniky a bezpečnost řešení.

•

Zvýšení hodnoty společnosti (podle prestiže poskytovatele služeb).

Obor IT je pro zákazníka v drtivé většině případů vedlejší, podpůrnou činností. Ale pro poskytovatele je to obor hlavní činnosti, který optimalizuje a při tom dosahuje přínosů pro zákazníka:

•

Konsolidace IT zdrojů a prostředků.

•

Cílené investice do rozvoje dovedností převzatých pracovníků.

•

Standardizace postupů a prostředků.

•

Integrace nových komponent do systému a služeb.

Ve fungování společnosti zákazníka jsou přitom viditelné následující dopady do majetku a hospodaření:

•

Odlehčení majetku o související základní prostředky a odpisy.

•

Převedení IT nákladů do provozních nákladů; v případě převodu pracovníků také souvisejících mezd.

•

Převedení části provozních nákladů související s administrativou a řízením IT oblasti z přímých nákladů do nakupovaných (např. část práce majetkové účtárny, část práce HR pro IT pracovníky, a další).

•

Snížení prostředků pro správu majetku a pracovníků a uvolněný objem převeden do příjmů za pronájem prostorů (buď pronájem poskytovateli IT služeb, nebo tržnímu zájemci).

•

Předvídatelný provozních).

•

Snížení počtu pracovníků podpůrné oblasti (a tím zvýšení produktivity na pracovníka).

průběh

nákladů

v dlouhodobém

horizontu

(investičních

i

Pro odběratele outsourcingových služeb je tedy přechodem na outsourcing dosaženo přenesení komplexních rizik spjatých s IT na smluvního partnera. Přenesení rizik je zajištěno prostřednictvím Smlouvy o poskytování služeb, rozšířené o zakotvení sledovaných parametrů služeb do například „Dohody o úrovni služeb“ (SLA). Uvážíme-li, že v tradičním uspořádání končí zodpovědnost za vlastní IT systém zpravidla v mezích Zákoníku práce a tedy rizika jsou plně na zákazníkovi - zaměstnavateli, při outsourcingu se zodpovědnost posouvá na podstatně širší pole působnosti Obchodního zákoníku. 48

Navíc IT servisní společnost jako outsourcingový partner poskytuje vhodnou platformu i pro spolupráci na definování a realizaci IT strategie, vzhledem k tomu, jak je rozsáhle spjatý s podporou hlavních činností obsluhovaného zákazníka.

4.3 Nepřetržitá byznys podpora Jedná se o službu známou pod označením Business Continuity and Recovery Services. V podstatě se jistou formou jedná také o outsourcing, který poskytují profesionální firmy jako zálohu klíčových komponent IT infrastruktury pro své zákazníky. Tato možnost je pro zákazníky zajímavou alternativou pro budování určitého stupně dostupnosti. Pro objasnění uvádím modelový příklad, ve kterém se zákazník rozhodl k zajištění záložního serveru v jiné lokalitě, na kterou jsou pravidelně přenášena data z primárních produkčních systémů. Zmíněné zařízení a jeho správa je plně v kompetenci poskytovatele služby. Tedy jedná se o částečný outsourcing DR systému s garantovanou dobou náběhu a smluvně podchycenou odezvou na požadavky zákazníka. Kvalita dat a jejich aktualizace je rovněž definovaná kontraktem a navazuje na architekturu řešení. Definice přípustné ztráty dat je pak daná možnostmi propojené lokalit.

49

5

Datová centra a IT konsolidace

Dnešní datová centra, která byla vybudována před pěti a více lety jsou již pro současné potřeby zcela nevyhovující. Potřeba pořizování a ukládání dat přerostla všechny odhady a i při trendu zvyšování kapacity na jeden fyzický disk je stále citelná potřeba fyzického místa, napájení, chlazení a nosnosti podlah. Rovněž tak rostoucí množství serverů, které disponují obrovským celkovým výkonem, který není dostatečně efektivně využíván. V následující kapitole se věnuji rozboru důležitých parametrů a strategii jejich užití pro datová centra s použitím dnešních technologií, zejména s důrazem na jejich efektivní využívání. Následující obrázek č. 10 nejlépe vystihuje trendy v rostoucím prodeji serverů. Ačkoliv finanční obrat za prodané servery stagnuje, zatímco náklady na správu a energie rostou. Obrázek 10: Trend prodeje Serverů a nákladů na vlastnictví. Spending (US$B) Vynaložené prostředky (US$B)

Instalované servery (M Units)

$300 $250 $200

50

Náklady na napájení a chlazení x8

45

Náklady na management serverů x4

40

Obrat z prodeje serverů

35 30

$150

25 20

$100

15 10

$50

5 $0

19 96 19 97 19 98 19 99 20 00 20 01 20 02 20 03 20 04 20 05 20 06 20 07 20 08 20 09 20 10

0

Zdroj: IDC, Virtualization 2.0: The Next Phase in Customer Adoption

Z toho logicky vyplývá mnoho otázek. Kam servery umístit? Jak je napájet a chladit? Zda dokážeme efektivně využívat jejich výkon? Správnou strategií můžeme eliminovat mnoho problémů, které nás mohou v budoucnu potkat.

5.1 Strategie provozování aplikací a dat v datovém centru Volbou vhodné strategie osazování datového centra vhodnou infrastrukturou a technologií pro aplikace lze předcházet značným problémům s vlastním provozem. Důležité pro vhodný návrh je dostatek informací o provozovaných aplikacích, jejich datech, požadavky 50

na dostupnost – SLA a především další rozvoj po stránce nárůstu požadovaného výkonu a kapacity dat.

5.1.1 Rozdělení aplikací Jednotlivé aplikace a jich data je potřeba rozdělit podle klasifikace do jednotlivých tříd. Jednotlivé třídy pak popisují dopad na fungování společnosti v případě nedostupnosti nebo špatné funkci dané aplikace. Jednotlivé třídy pak mohou být pokryty popisem požadované dostupnosti – SLA smlouvou. Pro příklad je zde uvedena tabulka č. 11 s možným rozdělením aplikací a dat podle závislosti na běh společnosti: Tabulka 11: Rozdělení aplikací podle míry kritičnosti Třída dostupnosti Třída 1

Třída 2

Třída 3

Třída 4

Popis komplikace Aplikace a data ovlivňují chod společnosti zásadním způsobem - jsou evidentní dopady na fungování společnosti. Není k dispozici alternativní postup pro zajištění kontinuálního provozu. Aplikace a data ovlivňují chod konkrétních procesů - jsou evidentní dopady na fungování postižené části společnosti. Není k dispozici alternativní postup pro zajištění kontinuálního provozu. Aplikace a data ovlivňují chod společnosti nebo konkrétních procesů - jsou evidentní dopady na fungování celé nebo postižené části společnosti. Existuje však alternativní postup pro zajištění kontinuálního provozu. Aplikace a data neovlivňují chod společnosti nebo konkrétních procesů - nejsou evidentní dopady na fungování celé nebo postižené části společnosti.

Hodnocení Mission Critical životně důležité, kritické

Business Critical - kritické pro vlastní byznys

Critical - kritické

Non Critical - ne kritické

Zdroj: Vlastní.

Pro správné rozdělení aplikací je potřeba analyzovat dopad každé aplikace na funkci společnosti. Pak je teprve možné zvolit návrh infrastruktury pro provoz těchto aplikací včetně scénářů HA/DR, zálohování dat a jejich obnovy.

51

5.1.1.1 Třída 1 Pro aplikace a data ve Třídě 1 se předpokládá nasazení lokálních cluster řešení v PDC32 ideálně podpořené záložním systémem i ne clusterovém řešením v BDC33, kam jsou buď synchronně, pokud to umožní infrastruktura, nebo asynchronně kopírována data aplikace a to buď prostředky aplikace, nebo systémy pro ukládání dat, nebo infrastrukturou s replikační datovou schopností.

5.1.1.2 Třída 2 Pro aplikace a data ve Třídě 2 se předpokládá nasazení lokálních cluster řešení v PDC ideálně podpořené záložním systémem i ne clusterovém řešením v BDC obdobně jako pro aplikace ve Třídě 1. Pokud nebudou aplikace ve Třídě 2 potřebovat maximální dobu nedostupnosti v řádu minut, je možné vytvořit pouze ne clusterové řešení v PDC s replikacemi dat na BDC. Nicméně z provozního hlediska správa lokálního cluster řešení je jednodušší a méně komplikovaná. Přechod na vzdálenou lokalitu a návrat zpět je daleko náročnější operace. Z tohoto důvodu je vhodnější použít lepší utilizaci zdrojů v PDC a použít obdobné řešení jako je pro Třídu 1.

5.1.1.3 Třída 3 Pro aplikace a data ve Třídě 3 se předpokládá nasazení lokálních cluster řešení v PDC, pokud k tomu povedou požadavky na dostupnost aplikace a dat. Pokud ne, je možné využít ne clusterové řešení na systému bez SPOF34. Replikace dat do BDC není požadována.

5.1.1.4 Třída 4 Pro aplikace a data ve Třídě 4 se předpokládá nasazení lokálních cluster řešení v PDC nebo BDC podle vhodnosti nasazení v kombinaci s ostatními systémy. Pro lepší utilizaci zdrojů je vhodnější použít BDC, kde se předpokládá minimální běh systémů pro replikace dat a tím je zde dostatek zdrojů pro provoz aplikací Třídy 4.

32

PDC – Primary Data Center - Primární datové centru. BDC - Backup Data Centre někdy záložní nebo sekundární datové centrum. 34 SPOF – Single Point of Failure, redundantní systém odolný proti výpadku jedné komponenty. 33

52

5.1.2 Profily pro nasazení aplikací Ideálním výsledkem je tabulka - matrice, kde budou zaneseny informace o kritičnosti aplikace a rozhodnutí o nasazení na konkrétní platformu hardwaru a softwaru. Následující příklad ukazuje možnost jak postupovat při rozdělování aplikací a jejich nasazování na systémy infrastruktury. Tabulka 12: Profily hardware pro nasazení aplikací. Infrastruktura HW/OS Virtualizace Cluster Lokalita HA/DR DATA sync

Aplikace Třída 2 Třída 3 Třída 4 RISC/UNIX, RISC/UNIX, RISC/UNIX, x86/Lin/Win x86/Lin/Win x86/Lin/Win Vysoká Vysoká Nízká priorita Nízká priorita priorita priorita Ano Ano Ano Ne PDC PDC BDC BDC Lokální PDC Lokální PDC Lokální PDC Ne + DR BDC + DR BDC Ano Ano Ne Ne Třída 1 RISC/UNIX

Zdroj: Vlastní.

Uvedená tabulka č. 12 pak zohledňuje nasazení aplikací a požadavky na kriteria definovaná v daném profilu. HW/OS (hardware/operační systém) navrhuje technologii na kterou je možné aplikace nasadit. Virtualizace určuje prioritu přístupu k přiděleným zdrojům. Lokalita určuje primární nasazení aplikace. Cluster je požadavek na vysokou dostupnost a pokud možno bezvýpadkový provoz. HA/DR vyjadřuje vysokou dostupnost prezentovanou lokalitou primárního clusteru a případnou zálohou v BDC. DATA sync vyjadřuje nutnost zajistit replikaci dat do záložní lokality.

5.2 Infrastruktura Většina dnešních DC35 se potýká s problémy, jako jsou nedostatek elektřiny, chlazení nebo prostoru. Ze zkušeností je potvrzeno, že se alespoň v jedné oblasti dosáhlo kritického limitu. Hlavním přínosem budování DC by mělo být podchycení kritických faktorů, které vyřazují současná DC z provozu. Při strategii budování DC je vhodné se opřít o doporučení jak stavit „green“ DC, které by pomohlo společnosti dále růst bez komplikací.

35

Data Center – datové centrum. 53

5.2.1 Řízení nákladů na energie Náklady na energie konstantně rostou. Podle studie Data Center Energy Efficiency and Productivity vydanou The Uptime Institute, jsou náklady za tříleté období dosahující až jeden a půl krát pořizovací hodnoty běžného serveru. To znamená, že bychom měli uvažovat o nákupu každého dalšího komponentu do infrastruktury. Každá dnešní investice bude znovu zaplacena.

5.2.1.1 Energie mimo limity Používání především starších typů a technologicky zaostalých byť aktuálních systémů vede

často k překročení limitu napájecí soustavy. Je tedy potřeba zvážit použití konkrétní technologie s ohledem na poměr spotřebované energie a užitečného výkonu.

5.2.1.2 Chlazení mimo limity Návrh DC v posledních 10 až 15 letech pracoval s energetickou hodnotou 2 – 3 kW na jeden 42U rack. Dnešní požadavky jsou cca 20 – 30 kW na jeden rack. Chlazení je tedy téměř vždy zcela nedostatečné a vyžaduje zcela nový přístup k návrhu jak efektivně DC chladit. Ideální je při návrhu nechat zpracovat termální analýzu a zajistit optimalizaci rozmístění všech systémů v prostorách DC. Na základě dynamického modelu je pak možno lépe definovat podmínky pro chlazení.

5.2.1.3 Prostory mimo limity Není myslitelné, aby plocha DC rostla podle požadavků na výkon společnosti. Ačkoliv je tento požadavek častým nejsnadnějším řešením jak získat další prostor pro infrastrukturu. Je tedy potřeba zhodnotit efektivnost jednotlivých komponent infrastruktury i z pohledy zastavěné plochy.

5.2.2 Užívání energií v DC Abychom pochopili, jak ušetřit energii v DC musíme nejdříve pochopit jak je používaná. Na použití můžeme nahlížet třemi způsoby:

•

Jak je energie distribuovaná mezi jednotlivé komponenty infrastruktury (servery, storage, network) a další podpůrné zařízení (napájení, chlazení a osvětlení). 54

•

Jak je energie distribuovaná mezi jednotlivé komponenty IT systémů (procesory, paměť atd.).

•

Jak je energie užívaná pro skutečný byznys přínos. Zda není příliš mnoho systémů čekajících na vytížení uživateli.

Provedené studie potvrzují následující data o využívání energie v DC. Z pohledu DC je 55 % použito na napájení a chlazení a 45 % na IT zátěž. Z pohledu samotných serverů je 70 % použito na paměti, adaptery, disky, ventilátory a 30 % na procesory. Z pohledu vytížení vlastních serverů je 80 % ve stavu čekajícím a 20 % ve stavu vytížení. Tyto závěry vedou k zamyšlení, jak maximálně efektivně využívat IT prostředky. Použitím technologicky vyspělých systémů disponující virtualizací zdrojů je možné zefektivnit provoz DC a redukovat náklady na provoz.

5.3 Konsolidace Koncept konsolidace s využitím virtualizace je dosud nejefektivnějším způsobem jak prokazatelně redukovat množství serverů, energie na jejich napájení a chlazení, prostoru a tím i celkových nákladů na provoz. Nicméně je při analýze IT prostředí potřeba postupovat od centralizace infrastruktur přes fyzickou konsolidaci směrem k virtualizaci a sjednocení aplikační vrstvy, jak je naznačeno na obrázku č. 11. Pokud je společnost působící po celém území daného státu nebo je dokonce rozprostřena přes více států, bude zřejmě existovat celá řada DC v různých lokalitách. Jejich správa a propojení bude velmi nákladné. V prvé řadě je tady nutné eliminovat potřebu používání menších lokalit a začít centralizovat infrastruktury do menšího počtu větších DC, nebo si pronajmout odpovídající DC pro naše potřeby s patřičným napojením na komunikační sítě. Předpokládejme, že jsme vytvořili koncept strategických DC pro naši firmu a můžeme začít s fyzickým přesunem klíčových komponent na jednotlivé lokality. Teprve tehdy můžeme přistoupit ke tvorbě vizualizovaného konceptu a následnému nasazení aplikací do virtuálního prostředí.

55

Obrázek 11: Strategie trendu směrem k energetické efektivitě.

Zdroj: The Green Data Center, Steps for the Journey

5.3.1 Centralizace systémů IT U větších společností vzniklých spojením několika menších organizací se často musí řešit centralizace IT a to prostřednictvím fyzického přesunu všech důležitých systémů do jedné centrální, případně dále jedné záložní lokality. Tedy princip DR mezi PDC a BDC. Vlastní fyzické přesuny IT systémů nejsou logicky řešením pro všechny problémy, které je potřeba vyřešit. Zejména lze předpokládat problémy v těchto oblastech:

•

Rozdílná hardwarová infrastruktura – servery + OS, storage, network.

•

Rozdílná softwarová platforma – OS, aplikace.

•

Rozdílná úroveň technického vybavení a kvality technického personálu.

•

Rozdílné požadavky na SLA.

Z těchto bodů je zřejmé, že pokud budeme centralizovat IT systémy jen dvou společností, bude potřeba provést důkladnou analýzu prostředí obou firem a následně určit priority pro výsledné centrální systémy, které budou poskytovat IT služby pro obě společnosti.

5.3.2 Analýza klíčových aplikací V dnešním světě globalizace je naprosto běžnou praxí obchodní fůze více obchodních společností. Předpokládejme, že společnosti provozují strategické IS, jako jsou ERP, CRM, BW a další. Po důkladné analýze zjistíme skutečné potřeby obou společností a úroveň nasazení jednotlivých aplikací v prostředí každé společnosti. Výsledkem

56

centralizace je přechod do jednotného prostředí, tedy nastolení „Globální IT strategie“ pro aplikační úroveň.

•

Analýza aplikačního prostředí.

•

Definice vazeb a poskytování služeb pro business.

5.3.3 Standardizace aplikací Globální strategie určuje výsledné aplikační prostředí. Řekněme, že globální strategií se stane přesun aplikací a migrace dat všech centralizovaných subjektů do SAP prostředí. Pak bude nutné provézt migrace rozdílných systémů směrem do cílové SAP platformy. Postup bude vypadat podle následujících bodů:

•

Převzetí jedné z aplikací pro všechny subjekty.

o Kontrola funkčnosti pro nové subjekty. o Optimalizace aplikace pro nové subjekty. o Nasazování otestované aplikace pro všechny subjekty (pilot > go-live). •

Vývoj nové aplikace v případě nevyhovující žádné z používaných, nebo nesouladu s globální strategií.

o Definice projektu + analýza potřeb. o Vývoj + test nové aplikace. o Optimalizace aplikace. o Nasazování otestované aplikace pro všechny subjekty (pilot > go-live).

5.3.4 Infrastruktura společností Infrastruktury jednotlivých společností budou s největší pravděpodobností zcela odlišné a tím i znalosti technického personálu. Výběr vhodné platformy je na zvážení mnoha hledisek viz kapitola „Strategie nasazení aplikací“ dále v tomto dokumentu. Porovnáním jednotlivých infrastruktur by měl být vybrán ekonomicky a strategicky nejvýhodnější koncept. Jednoznačně by měl splňovat kriteria, jako jsou schopnost virtualizace hardwarových zdrojů s důrazem na hospodárnost provozu, nejvyšší možnou dostupnost pro klíčové aplikace ovlivňující vážným způsobem chod společnosti a snadnou správu.

57

5.3.5 Konsolidace serverů Společnost IBM například pro konsolidaci serverů používá vlastní nástroj Zodiac, který je pro potřeby konsolidace vyvíjen řadu let. Nástroj disponuje znalostní databází o všech serverech předních světových výrobců se všemi podstatnými údaji o výkonu, příkonu, tepelné ztrátě a fyzických rozměrech. Dokáže propočítat náklady na vlastnictví stávajících serverů, náklady na energie, servisní náklady za hardware a software a licenční náročnost podle používaného softwaru. Výsledkem analýzy je ucelený report obsahující všechny potřebné informace pro zákazníka za plánované časové období. Například zákazník získá celkový přehled o budoucích nákladech za období 3 roky. Prakticky

se

konsolidace

provádí

následujícím

způsobem.

Nejdůležitější

je

zdokumentování stavu všech aplikací, serverů a jejich požadavků na výkon, propojení, bezpečnost a dostupnost. Celkový požadovaný výkon aplikací na stávajících serverech se sečte a vyčíslíme požadavky na napájení, chlazení a celkový prostor, který potřebujeme pro umístění systémů. Nově navržené systémy musí splňovat požadavky všech konsolidovaných systémů s ohledem na výkonnost a dostupnost. Výsledkem pozitivní konsolidace je pak úspora nákladů na provoz IT infrastruktury a ušetření plochy DC pro další rozvoj IT infrastruktury.

5.3.5.1 Konsolidační studie Konsolidační studie slouží k celkové analýza IT prostředí společností. Postupuje se cílevědomě ke konceptu nové infrastruktury. Porovnávají se stávající systémy s novými v oblastech, jako jsou celková výkonnost, spotřeba elektrické energie, požadavky na klimatizaci a fyzický prostor pro vlastní umístění. Následující obrázky č. 12 a 13 ukazují výsledky rychlé konsolidační studie provedené pro servery s operačními systémy UNIX a převedené na nejefektivnější dostupnou platformu. Při postupu se postupuje kontrolou všech systémů a získání následujících dat. Výkonnost, spotřeba, tepelné ztráta, fyzické rozměry. Dále pak je potřeba zajistit informace o aplikaci jako jsou licenční ujednání a servisní poplatky za údržbu software i hardware pokud jsou k dispozici. Příklad požadavků na zpracování studie: 58

•

Počet DC obsahující servery

cca 20.

•

Celková plocha DC

cca 1000 m2.

•

Celkový příkon serverů

cca 250kW.

•

Počet UNIX serverů všech typů

cca 76.

•

Počet 42 RACK stojanů při centralizaci

cca 22.

Nyní provedeme výpočet pomocí konsolidační metodiky. Celkový výkon serverů by mohl být v našem příkladu cca 192 000 RPE236 jednotek. Předpokládejme, že jsou servery vytěžovány na 50 %, což je velmi optimistický údaj. Provedeme porovnání výkonu proti nejefektivnější serverové platformě při vytížení na 60 % požadavku na možnost růst o 50 % a režii virtualizace cca 10 %. Servery rozdělíme na High-end (32 procesorové a větší SMP) systémy s možností virtualizace a sdílení zdrojů. Dále pak na malé aplikační servery, celkem tedy 32 serverů (28x Blade a 4x High-end). Obrázek 12: Porovnání výkonu instalovaných a nových serverů.

Zdroj: Interní IBM nástroj pro rychlé konsolidační přehledy.

Pokud máme zadané server a provedli jsme porovnání výkonu instalovaných serverů proti novému prostředí na efektivnější platformě, zároveň získáme i pohled na spotřebu energie, tepelnou ztrátu a úzké místo potřebné pro uložení serverů. Na obrázku č. 13 je patrný rozdíl po v potřebě energie na napájení a chlazení serverů. Úspora 70 % na vynaložené energie umožní instalaci dalších zařízení vyžadující napájení a chlazení.

36

RPE2 – Relative Performance – jednotka pro stanovení výkonnosti daného typu serveru. 59

Obrázek 13: Porovnání fyzických rozměrů, spotřeby energie a tepelné ztráty.

Zdroj: Interní IBM nástroj pro rychlé konsolidační přehledy.

Další zajímavé hodnoty jsou počty pozic ve standardním 42U RACK systému, kterých bychom po centralizaci do jednoho až dvou DC celkem potřebovali. Nové systémy bychom pak dokázali dodat do DC v maximálně 5 stejných rack systémech. Tedy ušetříme cca 70 % místa v DC. Jiný pohled může být po přepočtení vypočtených čísel na skutečné náklady na energie vyjádřené v Kč, a hodnoty mohou dosahovat zajímavých hodnot, jak je uvedeno v tabulce č. 13. Celková úspora nákladů na energie spojené s napájením a chlazením UNIX/RISC serverů může dosáhnout za období 4 roky až 3 miliony Kč. Tabulka 13: Porovnání nákladů na energie Energy consumption and costs Model Electric energy (kW/h) Electric energy costs (Kč/y) Electric energy costs (Kč/4y)

Installed Target var. 1 Target var. 2 p690 32way p570 12way p570 16way 15,4 4,2 5,6 539 616 147 168 196 224 2 158 464 588 672 784 896

Thermal energy cons. (kW/h) Thermal energy costs (Kč/y) Thermal energy costs (Kč/4y)

51200 512 585 2 050 341

14334 143 504 574 015

19112 191 338 765 354

Total energy costs (Kč/y) Total energy costs (Kč/4y)

1 052 201 4 208 805

290 672 1 162 687

387 562 1 550 250

761 529 3 046 117

664 639 2 658 555

Total saving (Kč/y) Total saving (Kč/4y)

Zdroj: Vlastní ze studie pro společnost RWE Energy Czech.

Z pohledu uspořeného místa a energií se jedná vždy o úspory menšího rázu. I když tato úspora může znamenat vedlejší úsporu v podobě pořizování nového DC pro rozšiřování IT

60

infrastruktury. Tuto úsporu je potřeba vyjádřit z nákladů na fyzickou údržbu stávajících DC v porovnání s možností eliminace těchto prostor na pouhá 2 DC! Hlavní úspora konsolidace je především v nákladech na software licence a poplatky za software a hardware údržbu. Porovnáme-li počty procesorů, kdy stávající systémy mají celkem 832 procesorů a nové pouhých 304 je jasné, že úspory za licence a údržbu software budou nemalé. Tedy minimálně o 60 % u všech aplikací licencovaných na jeden procesor. Náklady na údržbu hardware lze vyjádřit zjednodušeným odhadem. Předpokládejme, že cena za údržbu hardware na 3 roky se rovná pořizovací ceně. Pokud hodnota instalovaného hardware byla například 600 milionů Kč, je možné očekávat roční náklady cca 200 milionů jako náklady na údržbu. Cena nového hardware by mohla být cca 160 milionů Kč s roční údržbou cca 55 milionů Kč. Investice do konsolidace se vyplatí již první rok. Celkově bychom za 3 roky mohli ušetřit až 300 milionů Kč na provozu a údržbě.

5.3.5.2 Případové studie konsolidace serverů Ekonomické a provozní důvody jsou hlavní argumenty pro konsolidaci v každé společnosti. Omezení provozních nákladů, nedostatek výkonu a potřeba jeho dalšího navyšování, nedostatek místa, nosnost podlah v datovém centru anebo vyčerpané možnosti napájení a chlazení dané lokality. Pro ilustraci uvádím praktické zkušenosti z konsolidačních studií, které byly realizovány v praxi. Jedná se o společnosti, u kterých se princip konsolidace a zefektivnění nákladů na provoz IT infrastruktury staly nutností pro další fungování a možnost růstu ve stejném datovém centru.

Konsolidace datového centra ve společnosti RWE Společnost RWE provozuje SAP informační systém na platformě IBM PowerSystems. Servery využívají efektivního sdílení výkonu PowerVM pro jednotlivé virtuální servery. Dále je požadována vysoká dostupnost a možnost DR do druhé lokality. Důvodem ke konsolidaci byly především vysoké náklady na provoz a již vyčerpané možnosti dalšího růstu instalovaných serverů. Proto jsem v roce 2007 vypracoval konsolidační studii podle IBM metodiky, která zohlednila náklady na provoz IT infrastruktury. 61

Následující tabulka č. 14 porovnává stávající řešení serverů IBM pSeries 690 proti navrhované náhradě za servery IBM PowerSystems 570. Technologicky se jednalo o 2 generace novější servery s procesory POWER6. Tabulka 14: Porovnání nákladů na vlastnictví IT infrastruktury Model Nákup nového hardware Nabídnutá odkupová cena za starý hardware Náklady údržby hardware Náklady údržby a licencí software Náklady na energie Náklady celkem za 4 roky Úspora za 4 roky

2x p690 32way 2x p570 16way 31 601 293 10 000 000 34 351 314 7 802 006 60 096 821 22 070 448 8 417 609 2 325 375 102 865 745 73 799 121 Kč 29 066 624

Zdroj: Vlastní ze studie pro společnost RWE Energy Czech.

Z uvedené tabulky je patrná velká úspora především na licencích za software a jeho údržbu a dále na nákladech na údržbu hardwaru. Při celkové kalkulaci jsem zjistil, že celková úspora za období 4 roky bude cca 29 milionů Kč. To vedlo zákazníka k realizaci tohoto projektu. V současné době je systém provozován bez dalšího navyšování výkonu k plné spokojenosti zákazníka. Další přínosy pro datové centrum byly zejména:

•

Redukce požadavků na napájení a chlazení. Ačkoliv výkon serverů byl o 50 % vyšší než u původních serverů.

•

Požadavky na napájení se 4x zmenšily a navíc se ustoupilo od 3 fázových napájení k jednofázovému.

•

Potřeba fyzického místa byla redukována cca 4 x, hmotnost serveru cca 5 x.

S ohledem na úspory, které byly dosažené, může zákazník výkonově vyrůst cca 4 x, aby dosáhl původních požadavků na napájení a fyzický prostor. Tím se zajistila možnost dalšího chodu datového centra na několik let dopředu. Vzhledem k požadavkům na nárůst výkonu a tempu vývoje v oblasti procesorové technologie bude nadále schopen využívat své datové centrum pro provoz IT infrastruktury.

Konsolidace datového centra ve společnosti ČEZ Společnost ČEZ provozuje SAP informační systém na platformě IBM PowerSystems. Servery využívají efektivního sdílení výkonu PowerVM pro jednotlivé virtuální servery.

62

Dále je požadována vysoká dostupnost a možnost replikace dat do záložní lokality, která je určena především pro vývojové a testovací prostředí. Důvodem ke konsolidaci byly především požadavky na rozšíření výkonu z důvodů rozšiřování agendy a také plánovaný upgrade SAP systému, který bude požadovat nárůst výkonu. Pro dosažení nárůstu výkonu na požadovanou mez bylo potřeba vytvořit konsolidační projekt, který by zahrnul i fyzická omezení datového centra, které již mělo problémy s kapacitou volného místa a možnostmi napájení před konsolidací. Dalšími argumenty byly vysoké náklady na provoz a již vyčerpané možnosti dalšího růstu instalovaných serverů. V roce 2008 jsem vypracoval projekt konsolidace datového centra pro klíčové aplikace SAP ve spolupráci s technickým týmem ČEZ ICT. Jeho realizace začala v roce na konci roku 2008 a nyní se dokončuje poslední migrace na nové systémy. Konsolidační studie je podle IBM metodiky, která počítá náklady na provoz IT infrastruktury. Následující tabulka č. 15 porovnává stávající řešení serverů IBM pSeries 570 a 595 proti navrhované náhradě za servery IBM PowerSystems 595. Technologicky se jednalo o 1 generaci novější servery s procesory POWER6. Tabulka 15: Porovnání nákladů na vlastnictví IT infrastruktury Model Nákup nového hardware Nabídnutá odkupová cena za starý hardware Náklady údržby hardware Náklady údržby a licencí software Náklady na energie Náklady celkem za 3 roky Úspora za 3 roky

6x p570 3x p595

93 076 848 46 968 336 8 447 107 148 492 291 Kč

4x p595 55 341 185 2 000 000 48 808 836 28 640 781 8 296 431 143 087 233 5 405 058

Zdroj: Vlastní ze studie pro společnost ČEZ ICT.

Z uvedené tabulky jsou opět patrné úspory za údržbu hardware a software. Oproti předchozímu případu jsou úspory menší. To je dáno především dobou, na kterou byl případ spočítaný a dále je zde zachována možnost in-box upgrade pro servery v navrhovaném

řešení cca o 100 % bez nutnosti obsazení dalšího prostoru v DC. To bylo hlavní podmínkou, aby bylo možné dále udržet systémy v běhu včetně dalších požadavků na výkon bez nutnosti nakupovat další servery. Další přínosy pro datové centrum byly zejména:

63

•

Zachování požadavků na napájení a chlazení s možností růstu výkonu serverů až o 100 %.

•

Potřeba fyzického místa byla redukována o 3x 42U Rack. Toto místo bude dále možné využít pro jiné servery nebo disková pole.

Ačkoliv jsou úspory na první pohled zanedbatelné, zákazník získal novější technologii, která mu umožňuje další růst výkonu a navíc redukci poplatků za údržbu staršího hardware a snížení počtu licencí softwaru.

Strategie nasazení aplikací

5.4

Nasazování aplikací podléhá několika hlediskům, ke kterým se musí při vlastním návrhu umístění aplikací přihlédnout. Je potřeba dopředu znát odpovědi na takové otázky jakou jsou:

•

Vliv licenční politiky výrobce software na pořizovací náklady a následnou údržbu (licence + softwarová podpora) na konkrétní hardwarovou platformu.

•

Vlastní schopnost vysoké dostupnosti a možnosti zotavení z katastrofy (HA + DR prvky jako jsou online rozklad zátěže mezi více serverů nebo (a)synchronní replikace.

•

Rozdělení aplikací podle třídy kritičnosti pro chod společnosti.

S ohledem na předcházející body je potřeba zvolit adekvátní hardware platformu pro provozování vlastních aplikací a systémy pro ukládání dat. S ohledem na úspěšné projekty, které postupovaly podle pravidel konsolidace aplikací s použitím virtualizačních technologií, lze zvolit strategii rozdělení aplikací do následujících serverových tříd.

5.4.1 Kritické aplikace Třída 1 a 2 Jedná se o aplikace, které výrazným způsobem ovlivňují chod společnosti. Je doporučeno, aby aplikace byly nasazovány na serverové systémy úrovně „Midrange“ a „High-end“ a výlučně „High-end“ disková zařízení pro data. Tímto je zajištěn první předpoklad kvality platformy pro vlastní provoz. Předpokládejme, že nasazujeme moderní aplikace, které udržují data v databázích a datových skladech opět založených na databázových strojích. Vlastní aplikace je oddělena

64

a běží na vlastním odděleném hardware. Ideálním příkladem je třívrstvá architektura klient server, jako jsou například SAP a další systémy.

•

Data a databáze jsou centrem a tedy nejkritičtější částí aplikace. Zajištění trvalé dostupnosti pro data z databáze je potřeba vytvořit HA koncept a to buď prostředky operačních systémů, nebo vlastní funkcí databázového stroje. Vlastní data je nutno rovněž ukládat s myšlenkou HA a to buď na dvě disková pole prostřednictví online zápisu, prostředky operačního systému hostujícího vlastní databázový stroj, nebo prostředky diskového pole případně virtualizační vrstvy SAN sítě.

•

Aplikační logika je dnes většinou až na výjimky tvořena vždy více systémy, na které je uživatelská zátěž rozkládána. Pokud jsou aplikační servery schopny spolupracovat tímto způsobem, je vytvořen požadovaný koncept HA. Dalším přidáním serveru se nejen navyšuje výkonnost, ale i dostupnost prostředí. Aplikační logika neřeší ukládání dat jako předchozí vrstva.

Výběr správného hardware je závislý na vlastnostech aplikace a licenční politice. Nelze jednoznačně říci, které licenční ujednání je pro použití vhodnější. Následující možnosti vyjadřují vlastnosti, které mají jednotlivá ujednání.

5.4.2 Licenční politika Licenční ujednání zohledňující počet přihlášených uživatelů do systému nebo aplikace. Pokud jsou aplikace licencovány podle počtu uživatelů, je volba hardware snazší. Takové aplikace je možné bez problémů integrovat do virtualizovaných konceptů, kde je možné efektivně sdílet hardware zdroje, především procesory. Licenční ujednání zohledňující počet použitých procesorů pro systém nebo aplikace je další možnost licencování použitých procesorů pro běh aplikace. Zde je jednoznačně definován počet procesorů a nelze tedy zcela maximalizovat efektivnost využití virtualizačních schopností hardware. Další komplikací může být další podmínka na maximální výkonnost serveru limitovanou maximálním počtem procesorů, nebo patic pro osazení procesory. Vždy je potřeba detailně prostudovat vlastní licenční ujednání každé aplikace!

5.4.3 Příklad nasazení aplikace SAP R/3 Uvedený příklad předpokládá nasazení SAP aplikací ve třídě 1 a 2 a využitím efektivního sdílení výkonu serverů. Standardně se SAP aplikace nasazují v prostředí 3 systémů, kde počet všech serverů čítá značné množství. V některých případech dokonce až desítky 65

serverů. Tlak na efektivnost vedl k zavedení virtualizace jako jediného efektivního nástroje ke snížení počtu fyzických serverů. Následující tabulka č. 16 nejlépe vystihuje, jak vypadá takové SAP prostředí v praxi. Uvedený návrh již zpracovává koncept s využitím virtualizace na snížení počtu fyzických serverů na minimální nutný počet. Předpoklady pro návrh:

•

Architektura vysoké dostupnosti pro produkční aplikace.

•

Prostředí 3 systémů – produkční, testovací a vývojové prostředí.

•

Maximální využití virtualizace ke zmenšení počtu serverů a adapterů. Tabulka 16: Příklad rozložení SAP aplikací na serverech

2 2 2

2 2 4 4

6 6 6 2 3 3 3 2 2

CLS

#LAN

#FC

PROD PROD PROD DEV PROD TEST TEST HIGH HIGH

RAM (GB)

APP2 SAP+ISU APP3 SAP+ISU XI XI APP5 SAP+ISU BW APP SAP+ISU VIOS VIOS

#CPU

L1 L2 L3 L4 L5 L6 L7 L8 L9

16

B

Prostředí

CLS

#LAN

2 A 2

Aplikace

2

Oddíl

8 3 3 3 2 3 10 2 2

#FC

PROD PROD DEV TEST TEST PROD PROD HIGH HIGH

RAM (GB)

Prostředí

DB SAP+ISU APP1 SAP+ISU BW APP SAP+ISU XI APP4 SAP+ISU BW DB VIOS VIOS

#CPU

Aplikace

L1 L2 L3 L4 L5 L6 L7 L8 L9

Server B

16

Oddíl

Server A

2

2 A 2 2 B

2 2

4 4

Zdroj: vlastní.

Celá architektura je postavena na dvou stejných serverech aktivně využívající virtualizaci k dosažení efektivního využití přidělených zdrojů. Servery jsou tedy rozděleny na jednotlivé části - oddíly, které disponující bezpečně odděleným prostředím s vlastním operačním systémem. Priority používání zdrojů jsou přiděleny podle důležitosti provozované aplikace. Tedy, produkční prostředí bude mít přednost vždy před testovacím a vývojovým. Oddíly VIOS mají nejvyšší prioritu. Jedná se o I/O server, který sdílí I/O operace u těch oddílů, které nemají přidělené žádné fyzické I/O adaptéry. Přidělené procesory jsou navrženy pro společné užívaní na základě priorit, jak vyplývá z tabulky č. 16. Výkonnost přidělením virtuálního výkonu aktivních procesorů pro jednotlivé oddíly je možné měnit dle potřeby. Ideálně bez zásahu administrátorů podle nastavených politik a priorit. Databáze jsou pro dosažení HA úrovně doplněny o cluster nadstavbu operačního systému a jsou křížem zálohovány na druhém serveru. 66

Aplikační servery již disponují vlastností HA, a tedy není žádná nadstavba operačního systému potřeba. Plně postačuje jejich vyšší počet, N+1. U aplikačních serverů je možné využít i koncept výkonných malých serverů s vysokou hustotou nasazení. Jedná se o koncept Blade37 serverů. Jejich počtem je opět vhodné navyšovat výkonnost a dostupnost

řešení.

5.4.3.1 Testovací a vývojové prostředí Testovací a vývojové prostředí je velmi vhodné začlenit vedle produkčních systémů, jak je naznačeno v tabulce č. 16. Důvodem je především jejich nízká priorita používání přidělených, nebo sdílených zdrojů. Tento fakt hraje důležitou roli při špičkovém vytížení některého z produkčních systémů, který si dokáže na úkor testovacího a vývojového prostředí operativně přidělit jejich zdroje a tím překlenout náhlou výkonovou špičku. Další důvodem může být rezerva na každém serveru pro případ havárie nebo plánované údržby.

5.4.3.2 Binární kompatibilita a jednotný management. V případě oddělení aplikační a databázové vrstvy je vhodné použít stejné verze operačních systémů a stejných verzí aplikačního software. Tím se redukuje nákladnost správy celkového prostředí.

5.5 Ukládání dat a zálohování Pokud se podíváme na infrastrukturu z pohledu jednotlivých funkčních částí a datových bloků, tak lze posoudit míru kritičnosti pro jednotlivé části. Podle následujícího obrázku č. 14 jsou v soustředných kruzích seskupeny jednotlivé stupně architektury. Zcela zásadní a nejdůležitější jsou data, která jsou vytvářena a jsou zcela nenahraditelná na rozdíl od ostatních systémů.

37

Blade – žiletka, server minimálních rozměru avšak vysokého výkonu. Ideální poměr výkonu, ceny a rozměru. 67

Obrázek 14: Kritické části infrastruktury.

Míra kritičnosti infrastruktury pro obnovu z havárie

Zdroj: vlastní.

Míra kritičnosti je tedy ve směru šipky. Klientská pracoviště disponují pouze osobními daty uživatele a ty jsou z pohledu informačního systému zcela nedůležité. Rovněž vrstva aplikační nedisponuje žádnými důležitými daty. Tato vrstva pouze interpretuje požadavky klientů směrem k databázím. Data jsou spravována clusterem databázových serverů, které již mají přímý vliv na kvalitu dat v databázi. Nejdůležitější částí z pohledu informačního systému jsou data uložená na diskových polích. Pro fungování společnosti a zotavení po výpadku je nejdůležitější zajistit, aby data byla co nejlépe ochráněna před možným zničením a to buď poruchou systému, lidskou chybou anebo vyšší mocí (přírodní katastrofy apod.) Data lze třídit rovněž do skupin. Pokud jsme již provedli rozdělení aplikací do skupin Tříd, rovněž data těchto aplikací odpovídají patřičným třídám. Řekněme, že aplikace Třídy 1 a 2, budou rozhodně umístěna na disková úložiště třídy „Enterprise“. Zatím co ostatní mající nižší Třídu 3 a 4 mohou spolehlivě fungovat na diskovém úložišti třídy „Midrange“. Další neméně důležitým parametrem pro data je jejich dostupnost. Pokud určíme, že nedostupnost dat pro aplikace Třídy 1 a 2 může být maximálně několik hodina za rok je nutné ke zvolené třídě diskového pole zajistit ještě další parametr a to čas obnovy.

68

Obrázek 15: Data a jejich stupně důležitosti.

Zdroj: Vlastní.

Čas obnovy je velmi důležitý pro funkci celého systému. Důvodem je především sice malá, ale možná pravděpodobnost výpadku diskového úložiště vlivem poruchy nebo potřebné údržby. V případě údržby se jedná o hodiny plánované odstávky a může se tedy naplánovat tak, aby byla dodržena SLA podmínka pro dostupnost aplikace. V případě výpadku vlivem poruchy může nastat nutnost obnovy ze zálohy, pokud existuje! Předpokládejme, že náhlý výpadek je vždy překvapením a může nastat v nejméně vhodnou dobu. Počítejme takto: reakce obsluhy + identifikace problému + nutnost řešení podporou výrobce nebo servisním partnerem + rozhodnutí o řešení + schválení postupu řešení + postup výrobce nebo servisního partnera podle SLA od doby nahlášení problému + realizace schváleného řešení = obnova provozu. Celkový čas se může vyšplhat na několik jednotek až desítek hodin. A to je zcela vážný problém.

Řešením je vybudování rychlé synchronní replikace dat. Obecné doporučení je pro data aplikací Třídy 1 a 2 ukládat současně na dvojici diskových polí stejné třídy v PDC a dále zajistit replikaci dat do BDC jak je zobrazeno na obrázku č. 15.

69

Závěry a doporučení Závěrem této diplomové práce provedu shrnutí informací zde obsažených a také jejich zhodnocení včetně vyvození závěru. Hlavním úkolem kolem bylo přiblížit problematiku zajištění dostupnosti ICT služeb s ohledem na možná rizika spojená s vlastním provozováním. Následně vysvětlit pojmy vysoká dostupnost a plán obnovy ICT infrastruktury, protože je nedílnou součástí ICT strategie většiny společností stejně tak, jako hostování aplikací nebo outsourcing ICT infrastruktury. Dalším úkolem bylo zamyšlení nad efektivním využíváním ICT prostředků, jejich konsolidace a provoz v datových centrech. Obsah této práce navazuje na vlastní mnohaleté zkušenosti s praktickým provozem a nasazováním ICT infrastruktur pro zákazníky společnosti IBM v ČR a v zahraničí. Uvedené informační zdroje jsou základním zdrojem informací pro většinu problematik ICT. Problematika dostupnosti služby je v zásadě problematika všech firem vlastnících ICT infrastrukturu pro provoz aplikací. Dle zkušeností jsem provedl porovnání jednotlivých definic SLA a požadavků na dostupnost řešení. Analýzou nákladů na vybudování řešení jsem vytvořil rychlý přehled pro orientaci v dané problematice a tím usnadnil výběr

řešení. Některé z firem uvažují po zkušenostech s přírodními pohromami o vybudování další ICT lokality pro zajištění provozu v případě katastrofy, která by vyřadila jejich primární datové centrum. Zde jsem provedl výčet možností řešení jak vybudovat vhodnou infrastrukturu s použitím běžných ICT prostředků. Poznatky z realizace ukazují nutnost individuálního přístupu ke každému případu s využitím poznatků z předchozích řešení. Jednou z možností je hostování aplikací v datovém centru, které provozuje profesionální poskytovatel služeb. Zde je možné se smluvně zavázat k odběru služeb ICT technologií a vyžadovat jejich potřebnou dostupnost. Hovoříme o outsourcingu jako alternativě k vlastnímu provozu ICT infrastruktury včetně aplikací. Zkušenosti ukazují, že tento koncept je určitě vhodné zvážit. 70

Při studiu materiálů k této práci a zejména ve vlastní praxi jsem se setkal s problémem efektivního využívání dostupných hardwarových zdrojů. Jedná se především o nedostatečné vytěžování serverů, které jsou zbytečně napájeny a čerpají velké množství energií jen pro svoji režii. Proto jsem uvedl některé z konsolidačních projektů, ve kterých byla dosažena nemalá úspora na energiích. Koncepty „Green IT“ jsou hlavními trendy v rozvoji nové ICT infrastruktury. Také jsem v této práci uvedl několik možností, jak realizovat efektivní ICT infrastrukturu pomocí virtualizačních technik a nástrojů pro jejich návrh směrem ke konsolidaci. Výsledkem této práce je tedy stručný, ale ucelený pohled na problematiku nasazování informačních systémů a hlubší analýza dopadu na vlastní infrastrukturu. Je vhodné, aby při návrhu bylo postupováno s obecně platnými doporučeními. K tomu je samozřejmě nutné definovat ICT strategii každé konkrétní firmy s plánem na rozvoj ICT. S politováním musím konstatovat, že toto je zatím největší problém u mnoha společností v ČR. Z výše uvedeného plynou i závěrečná doporučení. Nejdříve je vhodné vypracovat ICT strategii, která v globálním pohledu postihne vytyčené cíle společnosti. Následně je možné postupovat k výběru aplikací jejich požadavku na ICT infrastrukturu a nakonec se zamyslet nad efektivním provozem všech aplikací, nad jednotnou konsolidovanou ICT infrastrukturou, kterou dokážeme minimalizovat na potřeby dosažení obchodních cílů společnosti. Staňte se také „Green IT“ společností!

71

Seznam použité literatury IBM Rebooks [online]. IBM Redbooks [cit. 2009-01-15]. Dostupný z WWW: < http://www.redbooks.ibm.com/>. Sun Microsystems Documentation [online]. Sun Microsystems Documentation [cit. 200901-25]. Dostupný z WWW: . HP Technical Documentation [online]. HP Technical Documentation [cit. 2009-02-02]. Dostupný z WWW: < http://docs.hp.com/>. BROOKS Charlotte; LEUNG Clem; MIRZA Aslam; NEAL Curtis; LEI Yin Qiu; SING John; WONG Francis TH; WRIGHT Ian R. IBM Redbooks : IBM System Storage Business Continuity Solutions Overview [online]. [cit. 2009-02-20]. Dostupný z WWW: < http://www.redbooks.ibm.com/abstracts/sg246684.html?Open>. EBBERS Mike; GALEA Alvin; KHIEM Marc; SCHAEFER Michael. IBM Redbooks : The Green Data Center: Steps for the Journey. [online]. [cit. 2009-02-25]. Dostupný z WWW: . KENNETH Brill G. The Uptime Institute, Inc. : Data Center Energy Efficiency and Produktivity [online]. [cit. 2009-02-23]. Dostupný z WWW: < http://www.uptimeinstitute.org/symp_pdf/(TUI3004C)DataCenterEnergyEfficiency.pdf>. HUMPHREYS John. IDC : Virtualization 2.0: The Next Phase in Customer Adoption [online]. [cit. 2009-02-27]. Dostupný z WWW: . SCHEIHING Paul. Creating Energy-Efficient Data Centers : Data Center Facilities and Engineering Conference, May 18, 2007 [online]. Washington, DC [2007] [cit. 2009-0229]. Dostupný z WWW: < http://apps1.eere.energy.gov/industry/saveenergynow/docs/doe_data_centers_presentation. ppt>.

72

Seznam obrázků a tabulek Obrázky Obrázek 1: Obecné zapojení pro HA cluster se dvěma poli................................................ 12 Obrázek 2: Databázové replikace. ....................................................................................... 13 Obrázek 3: Graf závislosti nákladů, možného výpadku pro různé SLA podmínky. ........... 27 Obrázek 4: Schéma architektury DR. .................................................................................. 28 Obrázek 5 Třídy business kontinuity a vliv doby obnovy dat na použité technologii. ....... 29 Obrázek 6: Příklad DR infrastruktury pro třídu 7................................................................ 30 Obrázek 7: Snímek utilizace procesorů serveru IBM System p 560................................... 35 Obrázek 8: Blokové schéma konsolidace a virtualizace serverů......................................... 36 Obrázek 9: Blokové schéma rozdělení serveru SUN s procesory T1/T2. ........................... 40 Obrázek 10: Trend prodeje Serverů a nákladů na vlastnictví.............................................. 50 Obrázek 11: Strategie trendu směrem k energetické efektivitě. .......................................... 56 Obrázek 12: Porovnání výkonu instalovaných a nových serverů. ...................................... 59 Obrázek 13: Porovnání fyzických rozměrů, spotřeby energie a tepelné ztráty. .................. 60 Obrázek 14: Kritické části infrastruktury. ........................................................................... 68 Obrázek 15: Data a jejich stupně důležitosti. ...................................................................... 69

Tabulky Tabulka 1: Přehled SLA podmínek a trend nákladů na jeho dosažení................................ 10 Tabulka 2: Celkové náklady na pořízení infrastruktury pro SLA 99 %.............................. 11 Tabulka 3: Celkové náklady na pořízení infrastruktury pro SLA 99,9 %........................... 14 Tabulka 4: Celkové náklady na pořízení infrastruktury pro SLA 99,99 %......................... 20 Tabulka 5: Porovnání dostupnosti DB řešení pro vysokou dostupnost............................... 23 Tabulka 6: Příklad dostupnosti pro server IBM pSeries 570. ............................................. 24 Tabulka 7: Celkové náklady na infrastrukturu 99,999 %.................................................... 26 Tabulka 8: Závislost požadavku na dostupnost a ceny za pořízení infrastruktury.............. 27 Tabulka 9: Přehled vlastností replikace dat pro jednotlivé DR řešení. ............................... 33 73

Tabulka 10: Rozdělení virtualizačních technologií podle vlastností................................... 38 Tabulka 11: Rozdělení aplikací podle míry kritičnosti ....................................................... 51 Tabulka 12: Profily hardware pro nasazení aplikací. .......................................................... 53 Tabulka 13: Porovnání nákladů na energie ......................................................................... 60 Tabulka 14: Porovnání nákladů na vlastnictví IT infrastruktury......................................... 62 Tabulka 15: Porovnání nákladů na vlastnictví IT infrastruktury......................................... 63 Tabulka 16: Příklad rozložení SAP aplikací na serverech .................................................. 66

74