Automatizace úloh v cloudovém prostředí. Bc. Jiří Pětník

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Diplomová práce

Automatizace úloh v cloudovém prostředí Bc. Jiří Pětník

Vedoucí práce: Ing. Miroslav Čepek

Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika 4. května 2012

iv

v

Poděkování Rád bych tímto poděkoval svému vedoucímu Ing. Miroslavu Čepkovi především za cenné rady a trpělivost. Velký dík patří firmě IBM Česká republika, spol. s r.o., která mi umožnila přístup k potřebným informacím a mimo jiné také ke cloudovému prostředí v rámci IBM Inovačního centra v Praze. Rovněž děkuji samotným zaměstnancům a kolegům. Bez jejich pomoci a především důvěry by tato práce nevznikla. V neposlední řadě nesmím zapomenout poděkovat svým rodičům za velkou podporu během celé doby mého studia.

vi

vii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 4. 5. 2012

.............................................................

viii

Abstract The aim of this work is to design and implement Tivoli Provisioning Manager (TPM) workflows for automatic provisioning of Microsoft SQL Server 2005 database in private cloud environment – IBM Service Delivery Manager (ISDM). The master thesis itself also describes the implementation of workflows for Windowsbased server deployment into the real environment, the creation of new module for special service metering and finally mentions the design and the implementation of DCM Object Browser application. Next main parts of this work are the small recherche of virtualization in the cloud environments and the basic cloud concepts description including top-down analysis of the main ISDM components.

Abstrakt Cílem této práce je navrhnout a implementovat sadu Tivoli Provisioning Manager (TPM) workflow pro automatické nasazení databáze Microsoft SQL Server 2005 v privátním cloudovém prostředí IBM Service Delivery Manager (ISDM). Samotná práce dále popisuje implementaci workflow pro automatický provisioning serverů do reálného prostředí, zabývá se vytvořením nového modulu, který zajišťuje speciální způsob měření služeb a na závěr zmiňuje návrh a implementaci prohlížeče DCM objektů. Součástí práce je také malá rešerše týkající se virtualizace, jejíž zaměření je orientováno především na cloudová prostředí. Dále je zde rozebírán základní koncept cloudu a jeho vlastností, na což navazuje top-down analýza hlavních komponent systému ISDM.

ix

x

Obsah 1 Úvod

1

2 Specifikace cíle 2.1 Popis řešeného problému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Popis struktury práce ve vztahu k vytyčeným cílům . . . . . . . . . . . . . .

3 3 4

I

5

Teoretická část

3 Virtualizace 3.1 Definice a základní pojmy . . . . . . . . . . . . . . 3.1.1 Host, guest, hypervisor . . . . . . . . . . . . 3.2 Druhy virtualizace . . . . . . . . . . . . . . . . . . 3.2.1 Emulace . . . . . . . . . . . . . . . . . . . . 3.2.2 Virtualizace na úrovni operačního systému 3.2.3 Úplná virtualizace . . . . . . . . . . . . . . 3.2.4 Paravirtualizace . . . . . . . . . . . . . . . 3.3 Virtualizační technologie . . . . . . . . . . . . . . . 3.3.1 XEN . . . . . . . . . . . . . . . . . . . . . . 3.3.2 KVM . . . . . . . . . . . . . . . . . . . . . 3.3.3 ESXi . . . . . . . . . . . . . . . . . . . . . . 3.3.4 z/VM . . . . . . . . . . . . . . . . . . . . . 3.3.5 PowerVM . . . . . . . . . . . . . . . . . . . 3.3.6 Hyper-V . . . . . . . . . . . . . . . . . . . . 3.4 Shrnutí . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

4 Cloud Computing 4.1 Definice a vymezení pojmu . . . . . . . . . . . . . . 4.1.1 Obecné vlastnosti . . . . . . . . . . . . . . . 4.1.1.1 Služba na vyžádání a standardizace 4.1.1.2 Dostupnost služby . . . . . . . . . . 4.1.1.3 Sdružování prostředků . . . . . . . . 4.1.1.4 Pružnost . . . . . . . . . . . . . . . 4.1.1.5 Flexibilní cena . . . . . . . . . . . . 4.1.1.6 Virtualizace . . . . . . . . . . . . . 4.1.1.7 Multi-tenancy . . . . . . . . . . . .

xi

. . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . .

7 7 7 8 8 9 10 11 12 12 13 14 16 16 18 20

. . . . . . . . .

21 21 22 22 22 23 23 23 24 24

xii

OBSAH

4.2

4.3

II

4.1.1.8 Dynamická infrastruktura . . . . . . . . 4.1.1.9 Automatizace . . . . . . . . . . . . . . . 4.1.1.10 Provisioning . . . . . . . . . . . . . . . 4.1.2 Porovnání přístupů . . . . . . . . . . . . . . . . . 4.1.2.1 Cluster Computing . . . . . . . . . . . 4.1.2.2 Grid Computing . . . . . . . . . . . . . 4.1.2.3 Celkový pohled . . . . . . . . . . . . . . 4.1.3 Cloud Computing z pohledu koncového uživatele Modely nasazení cloudu . . . . . . . . . . . . . . . . . . 4.2.1 Private Cloud . . . . . . . . . . . . . . . . . . . . 4.2.1.1 Managed Private Cloud . . . . . . . . . 4.2.1.2 Hosted Private Cloud . . . . . . . . . . 4.2.2 Public Cloud . . . . . . . . . . . . . . . . . . . . 4.2.2.1 Shared Cloud . . . . . . . . . . . . . . . 4.2.3 Hybrid Cloud . . . . . . . . . . . . . . . . . . . . Modely cloudových služeb . . . . . . . . . . . . . . . . . 4.3.1 IaaS . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 PaaS . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3 SaaS . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.4 DaaS, BaaS,. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

Analytická část

25 25 26 26 26 27 28 28 29 30 30 30 31 31 31 31 32 32 33 33

35

5 Cloudové technologie IBM 5.1 Pokrytí služeb . . . . . . . . . . . . . . . . . . . . . 5.2 IBM LotusLive . . . . . . . . . . . . . . . . . . . . 5.3 IBM SmartCloud Entry . . . . . . . . . . . . . . . 5.4 IBM SmartCloud Enterprise . . . . . . . . . . . . . 5.5 Tivoli Service Automation Manager . . . . . . . . 5.5.1 Způsob implementace . . . . . . . . . . . . 5.6 IBM Service Delivery Manager . . . . . . . . . . . 5.6.1 Architektura softwarových komponent . . . 5.6.2 Vrstevnatost systému a obsluha požadavků

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

37 37 38 38 38 39 39 40 40 41

6 TPM implementační schéma 6.1 Tivoli Provisioning Manager . . . . . . . 6.2 Logická zařízení a jejich operace . . . . 6.2.1 Vazba logické operace a workflow 6.3 Ovladač zařízení . . . . . . . . . . . . . 6.3.1 Automation package . . . . . . . 6.4 TPM Workflow . . . . . . . . . . . . . . 6.4.1 Workflow Language . . . . . . . 6.4.1.1 Definice workflow . . . 6.4.1.2 Výpisy a logování . . . 6.4.1.3 Jazyk Jython . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

45 45 45 47 47 47 49 49 49 50 50

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

OBSAH

xiii

6.4.1.4 6.4.1.5

III

Práce s datovým modelem DCM . . . . . . . . . . . . . . . . 51 Volání skriptů a Java tříd . . . . . . . . . . . . . . . . . . . . 52

Implementační část

53

7 Automatické nasazení serverů 7.1 IBM_Prague_Cloud_Core . . . . . . . 7.1.1 Souborová úložiště . . . . . . . . 7.1.2 Koncová zařízení . . . . . . . . . 7.1.3 Implementace přístupového bodu 7.2 CST_Prague_Cloud_Core . . . . . . . 7.3 IBM_Prague_Schtasks . . . . . . . . .

. . . . . . . . . . . . RXA . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

8 Automatické nasazení aplikací 8.1 Uživatelský kontext . . . . . . . . . . . . . . . . . . . . . 8.2 Automatické nasazení Microsoft SQL Serveru 2005 . . . 8.2.1 Obecné řešení . . . . . . . . . . . . . . . . . . . . 8.2.2 Příprava instalačních skriptů . . . . . . . . . . . 8.2.3 Implementace TPM workflow . . . . . . . . . . . 8.2.4 Definice DCM modelu . . . . . . . . . . . . . . . 8.2.5 Předávání parametrů ze samoobslužného portálu 9 Implementace měření služeb 9.1 Definice pravidel měření služeb 9.2 Možnosti ISDM cloudu . . . . . 9.3 Mapování procesů a subprocesů 9.4 Využití TPM workflow . . . . . 9.5 CST_Server_Metering.jar . . . 9.6 CSV soubory . . . . . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

55 55 55 56 57 57 58

. . . . . . .

61 61 62 62 63 63 64 65

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

67 67 67 67 68 70 70

10 Prohlížeč Data Center Model (DCM) objektů 10.1 Motivace . . . . . . . . . . . . . . . . . . . . . . . 10.2 Specifikace cílů . . . . . . . . . . . . . . . . . . . 10.3 Implementace . . . . . . . . . . . . . . . . . . . . 10.3.1 TPM SOAP API . . . . . . . . . . . . . . 10.3.2 Připojení TPM serveru . . . . . . . . . . 10.3.3 Datový model a generování DCM dotazu 10.3.4 Architektura DCM Object Browseru . . . 10.3.5 Konfigurační soubory a logování . . . . . 10.4 IBM Integrated Service Management Library . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

73 73 73 74 74 76 76 77 78 78

. . . .

81 81 82 83 84

. . . . . .

. . . . . .

. . . . . .

11 Testování 11.1 Automatické nasazení serverů . . . . 11.2 Automatické nasazení aplikací . . . . 11.3 Implementace měření služeb . . . . . 11.4 Prohlížeč Data Center Model (DCM)

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . . . . . . . . . objektů

. . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

xiv

OBSAH

12 Závěr 85 12.1 Vlastní přínos práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Literatura

87

A Seznam použitých zkratek

95

B Zkratky adresářů, cest a proměnných prostředí

101

C Přehled implementovaných TPM workflow

103

D Instalace Automation Package Developer D.1 Požadavky . . . . . . . . . . . . . . . . . . D.2 Průběh instalace . . . . . . . . . . . . . . D.3 Parametry skriptu . . . . . . . . . . . . . D.3.1 Příklad spuštění . . . . . . . . . . E Obsah přiloženého CD

Environment (APDE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

105 105 105 107 107 109

Seznam obrázků 1.1

Logo firmy IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10

Emulace . . . . . . . . . . . . . . . . . . . . Virtualizace na úrovni operačního systému . Úplná virtualizace . . . . . . . . . . . . . . Paravirtualizace . . . . . . . . . . . . . . . . Schéma jednoduché XEN architektury . . . Schéma jednoduché KVM architektury . . . Schéma jednoduché ESXi architektury . . . Schéma jednoduché z/VM architektury . . Schéma jednoduché PowerVM architektury Schéma jednoduché Hyper-V architektury .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

9 10 11 11 13 14 15 17 18 19

4.1 4.2 4.3 4.4 4.5

Multi-tenancy architektura . . . . . . . . . . . . . . . . . . . . Grid Computing . . . . . . . . . . . . . . . . . . . . . . . . . . Cloud Computing v porovnání s předešlými vývojovými modely Modely nasazení . . . . . . . . . . . . . . . . . . . . . . . . . . Základní modely cloudových služeb . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

25 27 29 30 32

5.1 5.2 5.3 5.4 5.5 5.6 5.7

Logo vize IBM SmartCloud . . . . . . . . . . . . . . . . . . . . . . . . . . . Způsob implementace řešení Tivoli Service Automation Manager . . . . . . Architektura softwarových komponent ISDM . . . . . . . . . . . . . . . . . Architektura cloudového systému ISDM . . . . . . . . . . . . . . . . . . . . Runbook PMRDPRUSMI (Save Image Runbook) . . . . . . . . . . . . . . . TSAM samoobslužný portál . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifikace přidělených zdrojů novému serveru v rámci TSAM samoobslužném portálu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

37 40 40 42 43 44

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

2

. 44

6.1 6.2 6.3

Základní komponenty provisioning workflow . . . . . . . . . . . . . . . . . . . 46 Základní struktura jednoduchého automation package . . . . . . . . . . . . . 48 Symbol jazyka Jython kombinující prvky jazyka Java a Python . . . . . . . . 51

8.1 8.2 8.3

Configuration Template s defaultními parametry . . . . . . . . . . . . . . . . 65 Konfigurace parametrů instalace databáze Microsoft SQL Server 2005 . . . . 65 Modifikovaný diagram aktivit znázorňující základní posloupnost procesů workflow CST_MSSQL2005_Windows_x64_Installable_Install.wkf . . . . . . . . 66

xv

xvi

SEZNAM OBRÁZKŮ

9.1 9.2

Subproces zajišťující mapování vstupních parametrů do TPM workflow . . . . 68 Přehledová architektura základních komponent implementovaného modulu měření služeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

10.1 10.2 10.3 10.4 10.5 10.6

Pohled Data Center Model . . . . . . . . . . . . . . . . . . . . . . . . . Pohled Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connection Settings DCM Object Browseru na operačním systému Mac Úvodní startovací obrazovka (splash screen) . . . . . . . . . . . . . . . . DCM Object Browser verze 1.1.46 umístěný v IBM ISM Library . . . . DCM Object Browser – načítání atributů objektu HostPlatform . . . . .

. . . . . .

. . . . . .

. . . . . .

74 74 76 77 79 79

11.1 Ukázka části logu testovací instalace databáze Microsoft SQL Server 2005 v APDE pohledu Execution Results . . . . . . . . . . . . . . . . . . . . . . . . 82 11.2 Nastavení rámce (Executing Node Scope) při mapování vstupních a výstupních parametrů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 C.1 C.2 C.3 C.4 C.5

CST_Servers_Metering projekt . . . . . . IBM_Prague_Cloud_Core projekt . . . . CST_Prague_Cloud_Core projekt . . . . IBM_Prague_Schtasks projekt . . . . . . CST_MSSQL2005_Windows_x64 projekt

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

103 104 104 104 104

Seznam tabulek 7.1 7.2 7.3

Automation package IBM_Prague_Cloud_Core . . . . . . . . . . . . . . . . 56 Automation package CST_Prague_Cloud_Core . . . . . . . . . . . . . . . . 58 Automation package IBM_Prague_Schtasks . . . . . . . . . . . . . . . . . . . 59

8.1

Automation package CST_MSSQL2005_Windows_x64 . . . . . . . . . . . . 64

9.1 9.2

Mapování subprocesů a standardních runbooků . . . . . . . . . . . . . . . . . 68 Automation package CST_Servers_Metering . . . . . . . . . . . . . . . . . . 69

D.1 Přehled podporovaných operačních systémů . . . . . . . . . . . . . . . . . . . 105

xvii

xviii

SEZNAM TABULEK

Kapitola 1

Úvod Cloud Computing lze s jistotou označit za jeden z nejčastěji zmiňovaných termínů poslední doby. K jeho samotnému rozšíření do podvědomí různých skupin lidí přispívají především velké a známé firmy, které nabídkou svých produktů a služeb zájem o cloud ještě navyšují. Pro příklad uveďme službu iCloud firmy Apple. Zvýšený zájem o cloud computing s sebou mimo jeho reálného využití také přináší různé spekulace o tom, co všechno lze tímto termínem označit, a co musí dané prostředí splňovat, aby bylo opravdu cloudovým. Spíše tedy než o skutečném a ryze technickém charakteru tohoto termínu se lze v některých případech domnívat, že se jedná pouze o marketingový tah, jehož cílem je oslovit novou skupinu zákazníků. Z historického hlediska je možné cloud computing označit za jednu z posledních vývojových etap v oblasti vývoje IT a poskytování služeb, a to i přesto, že někteří lidé o jeho přínosu stále polemizují. Hlavním důvodem je fakt, že samotné principy tzv. utility computingu, jak je také cloud computing někdy označován – tedy princip užívání počítačových zdrojů podobně jako je tomu dnes např. s elektrickou energií či pitnou vodou, jsou známy již delší dobu. Prvním, kdo o zmíněném modelu takovýmto způsobem uvažoval a veřejně s ním vystoupil, byl v roce 1961 John McCarthy, profesor z prestižní americké univerzity MIT. Stalo se tak při jeho projevu na oslavě stého výročí této univerzity. Zajímavé je na této myšlence především doba, kdy byla vyřčena, neboť se jednalo o období, kdy nebyla známa hardwarová ani softwarová virtualizace, které jsou dnes pro fungování všech cloudových prostředí nezbytné. Rozvoj cloud computingu včetně definice samotného pojmu můžeme zařadit tak do druhé poloviny 90. let 20. století, či spíše až na začátek 21. století. Hlavním důvodem byl především masivní rozvoj vysokorychlostního internetu, ale také první reálný projekt v podobě vzniku firmy Salesforce.com, která se zaměřila čistě na poskytování softwaru jako služby – Software as a Service (SaaS). Dnes se jedná o jednu z předních světových firem poskytující komplexní cloudové služby. Znám je především její CRM systém. Za další významný zlomový okamžik ve vývoji cloudu považuji rok 2006, kdy firma Amazon uvedla do provozu její veřejné cloudové služby Amazon Elastic Compute Cloud (EC2). Od té doby se také každá z velkých IT firem snaží zaměřit na tuto oblast a vyvinout si vlastní cloudové řešení, aby byla na trhu konkurenceschopná. Jen jako příklad uvedu Google, Microsoft, HP, VMware, Oracle, Dell apod. U některých velkých firem se však spíše

1

2

KAPITOLA 1. ÚVOD

než o nabídku cloudových služeb či samotného produktu jedná o poskytnutí svého knowhow při budování cloudových prostředí s částečným využitím jejich vlastního softwaru, či hardwaru. Významnou pozici na poli cloudových služeb dnes zaujímá samozřejmě i firma IBM (viz logo na obr. 1.1), která v dubnu roku 2011 oznámila, že její cloudové služby využívá 80% firem ze známého žebříčku Fortune 500 [30]. Jako jedna z mála také dokáže nabídnou cloud složený čistě z vlastních produktů – hardwaru, virtualizace i řídícího softwaru.

Tato práce se bude zabývat především privátním cloudovým řešením posledně jmenované firmy, a to IBM. Hlavní náplní zde bude návrh a implementace Tivoli Provisioning Manager (TPM) workflow pro účely provisioningu serverů a aplikací v rámci řešení IBM Service Delivery Manager (ISDM).

Obrázek 1.1: Logo firmy IBM

Kapitola 2

Specifikace cíle V této kapitole se blíže zaměřím na popis řešeného problému. Rozeberu zde samotné zadání, vytyčím body, které ze zadání plynou a pro úplnost také uvedu jednotlivé cíle, jenž byly vydefinovány až v průběhu práce. Nakonec uvedu krátký popis celkové struktury práce, její textové podoby.

2.1

Popis řešeného problému

Cílem práce je seznámit se s konceptem cloudových řešení, kde bude především diskutován IBM Service Delivery Manager (ISDM). Z hlediska samotné realizace a tvorby potřebných workflow pro automatickou instalaci Microsoft SQL Serveru 2005 na Windows Server 2008 pak bude předmětem studia IBM Tivoli Provisioning Manager (TPM). Jelikož byla celá práce realizována v reálném prostředí, bylo zároveň nutné zaměřit se také na další problémy, které se staly základem pro úspěšné dokončení celého projektu a především zmíněnou instalaci databáze Microsoft SQL Server 2005. V následujícím výčtu je uveden seznam vytyčených cílů a jejich stručný popis: • Virtualizační vrstvy cloudových prostředí. Důležitým předpokladem existence cloudových prostředí jsou různé druhy virtualizace, které vytvářejí základní vrstvu všech cloudových systémů. Úkolem bude se s těmito platformami alespoň v krátkosti seznámit. • Obecný cloudový koncept a řešení ISDM a TPM. O tom, co je to cloud a jaká je jeho skutečná definice, či přínos pro současné systémy se již delší dobu vedou spory. Cílem bude popsat základní obecné vlastnosti a soustředit se především na ISDM a TPM a jejich funkcionality v rámci cloudového prostředí. • Provisioning serverů. Před nasazením Microsoft SQL Serveru 2005 bude nutné začlenit samotný Microsoft Windows Server 2008 do existujícího cílového prostředí, což vyžaduje implementaci specifické sady workflow. • Instalace databáze Microsoft SQL Server 2005. Tento úkol bude vyžadovat především využití vlastností TPM serveru a metodik pro provisioning aplikací, ale bez použití TCA agenta.

3

4

KAPITOLA 2. SPECIFIKACE CÍLE

• Měření služeb. Z důvodu specifických požadavků na způsob měření poskytovaných služeb, bude nutné navrhnout a implementovat nové mechanismy pro jejich zaznamenávání. • Prohlížení DCM objektů. TPM server využívá pro ukládání všech entit ve spravovaném systému specifický Data Center Model (DCM), jehož procházení a především tvorba DCM dotazů je kvůli špatnému popisu jednotlivých vazeb poměrně složitá. Cílem je tedy implementovat nástroj, který by tyto procedury dokázat zjednodušit.

2.2

Popis struktury práce ve vztahu k vytyčeným cílům

Struktura práce téměř shodně odpovídá výše vydefinovaným cílům. Tedy v následující teoretické části se v kapitole 3 budu věnovat virtualizaci, a to jednotlivým druhům, klíčovým pojmům, které s danou oblastí souvisí, a hlubším popisem vybraných zástupců. Kapitola 4 se pak zaměřuje na obecný koncept cloudu, především popisuje jeho základní vlastnosti, porovnání s přístupy grid a cluster computingu a také uvádí jednotlivé modely nasazení a modely cloudových služeb. V analytické části práce se v kapitole 5 zaměřím na cloudové technologie firmy IBM, kde zmíním pouze základní představitele vybraných modelů služeb. Klíčový je zde především popis struktury a hlavních komponent ISDM cloudu pomocí top-down analýzy celého systému. Na popis obecných částí a základních vnitřních konceptů včetně pár procesů plynule navazuje kapitola 6, ve které jsou hlouběji rozebírány vnitřní vrstvy již samotného řešení TPM. Jsou zde zmiňovány vazby mezi jednotlivými prvky systému, logické operace, ovladače zařízení, ale také popis samotného jazyka TPM workflow. V implementační části práce jsem pak využil všech znalostí k realizaci vydefinovaných cílů, kde se prvnímu ze čtyř témat, a to automatickému nasazení serverů, věnuje kapitola 7. Následující kapitola 8 pak řeší hlavní úlohu této práce, tedy provisioning databáze Microsoft SQL Server 2005. Cílem je zde také uvést několik vzniklých problémů a jejich řešení. Návrhu a implementaci specifického konceptu měření služeb v cloudovém prostředí se zabývá kapitola 9, která popisuje základní funkcionalitu nového modulu a jeho napojení do existujících struktur. Poslední kapitolou týkající se implementace je kapitola 10, jež řeší zmiňované problémy se strukturou DCM modelu a vývoj prohlížeče, který pracuje nad reálnými daty TPM serveru a dokáže jednoduchým procházením objektů automaticky generovat DCM dotaz. V kapitole 11 rozdělené opět do čtyř částí dle jednotlivých oblastí implementace jsou následně rozebrány postupy a vůbec možnosti testování nově vytvořených položek. Na závěrečnou kapitolu 12, kde je shrnuto splnění cílů, celkové zhodnocení, ale také vlastní přínos práce, následně navazuje literatura a přílohy – především seznam použitých zkratek a popis instalace prostředí Automation Package Developer Environment (APDE).

Část I

Teoretická část

5

Kapitola 3

Virtualizace Zahájit popis libovolné cloudové infrastruktury a nevěnovat se alespoň základním pojmům virtualizace to by byla zásadní chyba a nedostatek celé práce. Virtualizace je v dnešní době nedílnou součástí každého cloudového řešení a pokud bychom ji měli zařadit do širšího kontextu, jedná se obecně o tu nejnižší vrstvu nad samotným hardwarem. V následujících odstavcích shrnu, co to virtualizace je a zaměřím se na některé vybrané zástupce.

3.1

Definice a základní pojmy

Definovat virtualizaci jako takovou je poměrně obtížný úkol. V dnešní době jsme tímto slovem schopni popsat poměrně širokou škálu věcí. Zaměříme-li se však pouze na oblast IT, můžeme zde hovořit o nástroji pomocí něhož provozujeme, simulujeme (virtualizujeme) jiná prostředí, komponenty systémů apod. Co se týče úrovní počítačových systémů, jsme schopni simulovat v podstatě libovolnou součást. Tedy například samotný hardware, část hardwaru, operační systém, běhové prostředí, aplikaci apod. Z pohledu historie první kdo začal s virtualizací experimentovat a provedl první implementace byla v 60. letech 20. století společnost IBM. V tu dobu byl také prvně použit pojem „virtuální stroj“ (VM), a to v projektu pokusného stránkovacího mechanismu systému IBM M44/44X, na který bylo později navázáno projektem IBM CP-40/CP-67. Právě zde byla poprvé implementována funkční virtualizace (schopnost spustit OS z jiného OS). Termín pseudo machine byl nahrazen pro nás dnes známým virtual machine. Na celý koncept pak navázalo známé komerční řešení v podobě mainframu IBM System/360-67 [3].

3.1.1

Host, guest, hypervisor

Před samotným uvedením různých druhů virtualizace je potřeba si nejprve vyjasnit alespoň pár základních pojmů. Jedněmi z nich jsou „hostitelský“ (host) a „hostovaný“ (guest). Obecně řečeno při libovolné úrovni virtualizace vždy existuje jeden element (stroj), který má přístup k fyzickému hardwaru, ten je nazýván jako hostitel (hostitelský stroj,. . . ). Všechny

7

8

KAPITOLA 3. VIRTUALIZACE

zbylé systémy, které přistupují k reálnému hardwaru přes onen zmíněný hostitelský stroj, se nazývají hostované a jsou více či méně podřízené [89]. Z hlediska hostitelského stroje často hovoříme o tzv. hypervisoru. Zjednodušeně řečeno se jedná o specializovaný software (dle typu virtualizace může být i součástí kernelu), který umí rozdělovat hardwarové prostředky tak, abychom byli schopni v jednou okamžiku provozovat několik izolovaných guest instancí (například operačních systémů). V obecném pojetí bychom tento software mohli charakterizovat jako Virtual Machine Monitor (VMM), či také jako Resource Manager (RM) [10]. VMM jsme často schopni spustit nad hostitelským operačním systémem a nechat ho hostovat více virtuálních strojů, nebo ho umístit jako specifický druh hostitelského operačního systému na samotný hardware a nad touto vrstvou přímo spouštět hostované operační systémy (VMs) – v takovém případě o této vrstvě hovoříme právě jako o hypervisoru. Důležitou činností, kterou hypervisor provádí, je odstínění jednotlivých virtuálních strojů od fyzického hardwaru a zároveň od dalších virtuálních instancí. Jednoduše řečeno ani s rootovskými (administrátorskými) oprávněními nejsme žádným způsobem schopni přistupovat do paralelně běžících virtuálních instancí (myšleno skrze hypervisor). V některých případech nemáme ani možnost zjistit, zda běžíme v nativním, či virtualizovaném prostředí.

3.2

Druhy virtualizace

Níže jsou rozebrány jednotlivé druhy virtualizace, jejich výhody a nevýhody. Všechen obrazový materiál, který byl použit v této sekci 3.2, byl převzat z [51]. Rád bych zde také poukázal na vynikajícím způsobem zpracovaný a řádně ocitovaný přehled virtualizačních nástrojů uvedených v internetové encyklopedii Wikipedia. Rozcestník nalezneme zde [79].

3.2.1

Emulace

Hovoříme-li o emulaci, viz obr. 3.1, jedná se obecně o napodobení činnosti jednoho zařízení pomocí jiného zařízení, nebo-li je to překlad strojových instrukcí hostovaného systému na strojové instrukce hostitelského stroje, emulace pamětí cílové platformy a celého zbylého hardware. Jedná se tedy o typ hardwarové virtualizace, kdy nám simulační nástroj poskytuje rozhraní jiného (hostovaného) systému. Cílová platforma (hostitelský stroj), kde simulaci provádíme, není sama o sobě schopna provádět běh simulovaného prostředí, a to například z důvodu odlišných instrukčních sad apod. I přes různé optimalizace (např. jednou přeložené úseky aplikace se ukládají do paměti, takže je není třeba při příštím volání znovu překládat) se jedná o nejméně efektivní způsob virtualizace. Na druhou stranu je to jediný způsob, jak virtualizovat jinou architekturu a také emulovat mnohaprocesorový stroj na počítači s jedním procesorem [89]. K nejznámějším emulátorům patři BOCHS [21], PearPC [50] a QEMU [52]. Jako další příklady uveďme představitele virtualizace mobilních zařízení Android Emulator [18] a operačního systému DOS [24].

3.2. DRUHY VIRTUALIZACE

9

Obrázek 3.1: Emulace

Výhody Výhodou je jistě možnost na libovolné platformě spustit systém a aplikace libovolné jiné (danou aplikací vyžadované) platformy. Virtualizační software je obyčejnou aplikací, běží i bez administrátorských práv. Hostitelský ani hostovaný systém nemusí být nijak upraven [89]. Nevýhody Nevýhody jsou především extrémně nízký výkon (například pro emulaci Amigy 500 s procesorem Motorola 68000 7,16 MHz + koprocesory bylo zapotřebí 200MHz Pentium). Každá instrukce virtuálního CPU musí být simulována na skutečném hardwaru. Dále jsou zde pak problémy s kompatibilitou emulovaného hardwaru [89].

3.2.2

Virtualizace na úrovni operačního systému

Koncepcí této metody virtualizace je využití jediného jádra operačního hostitelského systému několika izolovanými virtuálními stroji, viz obr. 3.2. Je tedy zřejmé, že hostitelské i hostované systémy musí být stejné (dokonce ve stejné verzi). Jedinou výhodou hostitelského stroje je, že má možnost přidělovat fyzické zdroje hostovaným systémům. V ostatních ohledech jsou stroje rovnoprávné, tzn. že při přístupu k hardwaru využívají týž kernel. Díky tomu je výkonnostní režie tohoto řešení prakticky nulová. Příkladem může být Jails ve FreeBSD [29] a Containers (Zones) v Oracle Solaris [47]. Tento způsob virtualizace byl v enterprise prostředí používán asi nejčastěji [89]. Výhody Nabízí nejlepší výkon (v podstatě nativní rychlost). Nevýhody Hostitelské a hostované platformy i operační systémy musí být stejné. Pád jednoho stroje způsobí pád všech ostatních [89].

10


Obrázek 3.2: Virtualizace na úrovni operačního systému

3.2.3

Úplná virtualizace

Na desktopech, ale především také na virtualizačních serverech, se setkáme nejčastěji s úplnou virtualizací, viz obr 3.3. Hostovaný stroj je emulován pomocí virtualizačního hardwaru, což je zajištěno pomocí hypervisora, který je instalován přímo na fyzický hardware. Procesor se neemuluje (z toho plyne, že platformy musí být shodné) a hostované operační systémy i aplikace běží v nativním režimu a tedy s plným výkonem. Problém nastane jen v situaci, kdy se hostovaný systém pokusí přistoupit k hardwaru. Jednoduše řečeno je pak v takovém případě požadavek odchycen, upraven (např. čtení z virtuálního disku je třeba převést na čtení určitého místa na disku fyzickém) a následně předán ke zpracování hostitelskému systému. Výsledek putuje stejně strastiplným způsobem zpět do hostovaného systému. Toto je největší slabinou úplné virtualizace – veškeré vstupně-výstupní operace jsou obtěžkány značnou režií. Procesory Intel VT-x (Vanderpool) a AMD-V (Pacifica) mají například speciální technologie, které v tomto směru usnadňují programování virtualizačního software, ale nepřinášejí téměř žádný nárůst výkonu [89]. Nejznámější aplikace využívající plné virtualizace jsou od VMware [70], Oracle VirtualBox [68], Microsoft Virtual PC [69], Citrix XEN [22]. Jak již bylo jednou zmíněno, izolace v podobě běhu virtuálních strojů jsou použity především z důvodu bezpečnosti. Vytvoříme tak prostředí, kde běžící instance stroje nemůžou ovládnout hostitelský počítač ani jeho další komponenty (operační systém apod.). Tato metoda odstínění je použita dokonce i na úrovni některých programovacích jazyků, kdy například Java či C# využívají pro běh svých aplikací instance virtuálních strojů (tedy JVM a CLI).

Výhody Hrubý výpočetní výkon. Hostitelský ani hostovaný operační systém nemusí být nijak modifikován. Logické oddělení adresních prostorů a izolace celých systémů, které na sobě nijak nezávisí. Bezpečnost.

3.2. DRUHY VIRTUALIZACE

11

Obrázek 3.3: Úplná virtualizace

Nevýhody Pomalejší I/O. Hypervisor konzumuje zdroje celého systému.

3.2.4

Paravirtualizace

Základem je speciálně upravené jádro hostitelského operačního systému s hypervisorem, který poskytuje hostovaným systémům přístup k hardwaru. Hostované operační systémy jsou taktéž upraveny – např. ví, že nemají přístup k fyzickému hardwaru, takže všechny jejich přístupy jsou převedeny na volání zmíněného hypervisora. Tímto způsobem je odstraněna značná část režie spojená se vstupně-výstupními operacemi. Aplikace i samotný systém běží nativně na procesoru stejně jako v případě úplné virtualizace [89]. Jednodušeji řečeno, hlavní rozdíl mezi úplnou virtualizací a paravirtualizací je v tom, zda hostovaný systém ví, že běží na hypervisoru a ne na skutečném hardwaru. Paravirtualizace sdílí procesy s guest OS a jednotlivé instance musí být pro takový běh modifikovány, viz obr. 3.4. V případě úplné virtualizace operační systém nerozezná, že na samotný fyzický hardware přistupuje skrze hypervisor a nemusí být nijak modifikován. V takovémto případě je ale pro samotný běh vyžadován hardware s podporou virtualizace (Intel VT, AMD-V, apod.), tzv. Hardware Virtual Machine (HVM) [87]. Nejznámějším softwarem s možnosti paravirtualizace je již zmíněný XEN [81]. V dnešní době lze však paravirtualizaci provozovat i pomocí VMware [27].

Obrázek 3.4: Paravirtualizace

12


Výhody Lepší výkon než v případě úplné virtualizace. Výkon prostředí se téměř blíží nevirtualizovaným systémům. Souběžný provoz různých OS v jednom okamžiku. Lze použít i u staršího hardwaru, který nepodporuje virtualizaci. Nevýhody Hostitelský i hostovaný systém musí být upraven.

3.3

Virtualizační technologie

Ve zbytku této kapitoly se budu věnovat popisu vybraných virtualizačních technologií. Zaměřím se především na známá řešení, v krátkosti popíši jejich koncept, jak přistupují ke tvorbě virtuálních prostředí, a jejich architektury.

3.3.1

XEN

Virtualizační platforma XEN [81] je jednou z nejznámějších virtualizačních technologií současnosti, a to i především z důvodu, že je stále vyvíjena jako open source (GNU GPL). Její počátky pocházejí z Univerzity v Cambridge, kde celý nápad vznikl – tento projekt byl podporován firmou XenSource, Inc. V roce 2007 firma Citrix provedla velkou akvizici a za bezmála 500 milionů dolarů XenSource koupila [83]. Tímto krokem pronikl Citrix na pole virtualizace a začlenil tak XEN mezi svůj nabízený software. Na této virtualizační platformě staví produkty jako Citrix XenApp [82] (dříve známý jako Presentation Server), Citrix XenServer [86], Citrix XenDesktop [84] – zástupce virtuální infrastruktury desktopů, anglicky Virtual Desktop Infrastructure (VDI), ale i například Oracle VM [48] apod. XEN je robustní, bezpečný a výkonný hypervisor, který se instaluje přímo na hardware (tzv. bare-metal hypervisor) a také VMM běžící jako druh softwaru nad OS. Z hlediska schopnosti virtualizovat nemá problémy například s architekturami x86, x64, IA64, ARM (Advanced RISC Machines) [14]. Z pohledu operačních systémů si poradí s Windows, Linux, Solaris, různými druhy BSD OS (FreeBSD, NetBSD,. . . ), apod. Podporuje úplnou virtualizaci i paravirtualizaci. Architektura Bare-metal hypervisor je program, který se jako první načte po spuštění BIOSu. Běží v privilegovaném módu nazývaném Domain-0, zkráceně dom0. Dom0 má speciální práva mezi něž patří přístup k fyzickému hardwaru – tedy je schopen načíst a používat ovladače diskových kontrolérů a síťových adaptérů. Z toho plyne, že zajišťuje správu virtuálních disků a sítí pro jednotlivé hostované instance, které zde nazýváme domUs (z anglického unprivileged domains). V rámci dom0 dále běží Xen management toolstack jehož úkolem je spravovat Xen hypervisor [85]. XenStore je databáze informací, které mezi sebou sdílí hypervisor, jádra (kernels), drivery a Xen daemon (Xend). Xen daemon dohlíží na řízení a provádění sady hostovaných

3.3. VIRTUALIZAČNÍ TECHNOLOGIE

13

domén. Celková komunikace probíhá přes sdílenou sběrnici XenBus [41]. Grafický náhled na architekturu je možné vidět na obr. 3.5.

Obrázek 3.5: Schéma jednoduché XEN architektury

3.3.2

KVM

Tato všeobecně známá zkratka pochází z anglického Kernel-based Virtual Machine. Podobně jako předešlá virtualizační technologie – XEN, je i KVM vyvíjena jako open source (GNU GPL, LGPL). Vznik KVM a velká podpora je spojován s firmou Qumranet. Tato firma na sebe upozornila především virtualizací desktopů postavených na KVM. Ještě v roce 2007 to bylo jediné řešení svého druhu [53]. Produkt s názvem Solid ICE využíval tenkého klienta se speciálním protokolem SPICE (Simple Protocol for Independent Computing). V roce 2008 byla tato firma koupena Red Hat, Inc. za 107 milionů dolarů. KVM podporuje architektury x86 a x64, pracuje se na IA64, PowerPC, či ARM [40]. Z pohledu operačních systémů si poradí s Windows, mnoha druhy Linux systémů [39], Solaris, Haiku, ReactOS, AROS Research Operating System [11] a dokonce i s Mac OSX [45]. Hovoříme-li o KVM, většinou se vždy jedná o úplnou virtualizaci. Architektura Přístup, který KVM volí je ten, že je schopno přepnout jádro OS na hypervisora, a to jednoduše nahráním modulu do kernelu. Tento modul exportuje zařízeni /dev/kvm, které poskytuje hostovaný mód jádra. Zařízení /dev/kvm má svůj vlastní adresní prostor oddělený jak od samotného jádra, tak také dalších virtuálních instancí (VM). Ve chvíli, kdy se kernel hostujícího operačního systému začne chovat jako hypervisor, je možné spouštět další operační systémy – ať již Linuxová jádra, Windows, apod. Každý hostovaný OS je pak chápán jako jeden proces v hostujícím OS (hypervisoru).

14


Na obr. 3.6 můžeme vidět náhled na celou architekturu. Na nejnižší vrstvě se nachází hardware, který podporuje virtualizaci. Přímo nad touto vrstvou nalezneme bare-metal hypervisora – linuxové jádro s KVM modulem. Hypervisor připomíná běžný linuxový kernel, na kterém jsme schopni spouštět další aplikace. Zároveň ale umožňuje běh hostovaných (guest) operačních systémů natažených pomocí utilitky kvm [6].

Obrázek 3.6: Schéma jednoduché KVM architektury

Pro ucelený pohled tedy uveďme, že procesory jednotlivých virtuálních instancí jsou virtualizovány samotným fyzickým procesorem (procesor s vnitřní podporou virtualizace), paměti jsou simulovány pomocí zmíněného zařízení /dev/kvm a nakonec I/O operace jsou virtualizovány modifikovaným QEMU procesem [52] u každého VM [6].

3.3.3

ESXi

Americká společnost VMware, Inc. [70], která byla založena v roce 1998, je jedním ze známých představitelů virtualizační technologie založené na architektuře x86. Samotné jméno vzniklo spojením několika klíčových slov, a to „VM“ (jako Virtual Machine) a hardware. Rád bych zde zmínil především enterprise řešení v podobě bare-metal hypervisora, kterým je VMware vSphere Hypervisor, častěji označovaný jako ESXi. VMware ESXi byl původně pouze jako „odlehčená“ verze VMware ESX Serveru pro embedded řešení. Celková velikost, která dosahovala několika desítek MB, se tedy mohla vejít přímo na interní flash paměti serverů značkových výrobců (jako IBM Blade Server apod.). Příznak v podobě písmene „i“ zde pravděpodobně znamená „integrated“ [8]. Postupem času se právě toto řešení stalo nejvíce prosazovaným. Vývoj a podpora VMware ESX Serveru byla ukončena v průběhu roku 2010 a závěrečný update poslední verze (VMware ESX 4.1) se objevil začátkem roku 2011. Současná verze VMware ESXi je 5.0 (září 2011). VMware vSphere Hypervisor je možné zdarma stáhnout a otestovat [28]. V enterprise prostředí tento hypervisor málokdy nalezneme jako samostatné řešení. Většinou se kombinuje s VMware vCenter Serverem, který je schopen současně spravovat více hypervisorů na různých fyzicky oddělených serverech a obohacuje celé prostředí o další funkcionality, mezi něž například patří:


15

• VMotion [77] – technologie umožňující přenášení běžících virtuálních strojů mezi jednotlivými ESXi hosty, • Storage VMotion [75] – schopnost přenášet běžící virtuální stroje z jednoho diskového úložiště na jiné, • DRS [71] – nebo-li Distributed Resource Scheduler, což je automatický load balancing ESXi clusteru pomocí VMotion, • HA [73] – nebo-li High Availability, umožňuje v případě pádu fyzického serveru automaticky restartovat jednotlivé instance na jiném hostu (v rámci definovaného clusteru). Pomocí ESXi hypervisora jsme schopni virtualizovat architekturu x86 i x64. Z pohledu operačních systémů zde nalezneme podporu pro různé verze OS Windows, Linux, FreeBSD, Solaris,. . . více viz zde [72]. Podrobnější popis úplné virtualizace, ale i paravirtualizace firmy VMware nalezneme zde [74].

Architektura Na obr. 3.7 [76] vidíme náhled na ESXi architekturu, která na rozdíl od původního modelu ESX Serveru již neobsahuje servisní konzoli (Service console), která byla umístěna na samostatné virtuální instanci a sloužila k instalaci, konfiguraci a administraci celého serveru [13]. Můžeme zde vidět VMware virtualizační vrstvu (VMware Virtualization Layer) známou také jako VMkernel, která zajišťuje požadovaný resource management – přidělování a alokaci hardwarových prostředků. Neméně důležitá je zde virtuální síťová vrstva (Virtual Networking Layer), jež umožňuje tvorbu virtuálních síťových adaptérů a také virtuálních switchů s podporou IEEE 802.1q VLAN. Na samotných virtuálních strojích pak běží jednotlivé operační systémy.

Obrázek 3.7: Schéma jednoduché ESXi architektury

16


3.3.4

z/VM

Virtualizační technologie z/VM je zde uvedena jako další ze zástupců již komerčních řešení, v tomto případě společnosti IBM. Jak již název sám napovídá podle znaku „z“, jedná se o technologii svázanou s mainframovými systémy, tedy IBM System z (dříve zSeries), což je v dnešní době (podzim roku 2011) poslední řešení v této oblasti navazující například na System/390 apod. z/VM je současná verze rodiny virtuálních operačních systémů (IBM’s VM family), které se chovají jako virtualizační software a umožňují souběžnou činnost stovek až tisíců linuxových serverů na jednom fyzickém hardwaru (mainframu). z/VM může běžet v samostatném LPARu1 a je schopno virtualizovat všechny systémové zdroje včetně procesorů, pamětí, datových úložišť a komunikačních zařízení (síťových karet) apod. Díky LPARům jsme schopni spustit několik instancí z/VM, zatímco v dalších logických jednotkách můžeme provozovat jiné mainframové operační systémy. Každý z/VM umožňuje dále virtualizovat velké množství instancí mainframových operačních systému (samozřejmě limitem jsou zde prostředky přidělené jednotlivými LPARům, ve kterých se daný z/VM nachází) [31]. z/VM je tedy druh hypervisora (OS) založeného na 64-bit z/Architektuře. Z pohledu operačních systémů podporuje například Linux, z/OS, z/OS.e, z/TPF (Transaction Processing Facility) nebo z/VSE (Virtual Storage Extended). Mimo to také podporuje další z/VM běžící jako hostovaný operační systém [15]. Aktuální poslední verze v říjnu roku 2011 je z/VM 6.2 [33]. Architektura Pouze jako příklad si ukažme zjednodušený náhled na architekturu z/VM členěnou pomocí LPARů. Následující obrázek, viz obr. 3.8, ukazuje dva logické celky (LPARy), kde na každém běží z/VM OS. Každá z/VM instance dále spravuje tři samostatné logicky oddělené instance koncových operačních systémů s vlastními aplikacemi. Důležité je také upozornit, že všechny jednotky zde sdílejí jedny a ty samé fyzické hardwarové prostředky. Počty současně běžících virtuálních stanic jsou omezeny jen a pouze těmito prostředky [91]. Vrstva „PR/SM hypervisor“, nebo-li Processor Resource/System Manager hypervisor, je typ hypervisora, který běží pouze na System z architektuře. Jeho úkolem je transformovat fyzické zdroje na virtuální zdroje – mnoho logických celků tak může sdílet shodný fyzický hardware. Rozdělené fyzické zdroje je schopen přidělovat jako sdílené, či dedikované pouze jednotlivý logickým celkům. Umožňuje také celou konfiguraci dynamicky měnit podle potřeby [90].

3.3.5

PowerVM

Jedná se o další komerční druh virtualizační technologie, kterou vytvořila firma IBM. V souvislosti s touto virtualizací byl v poslední době často slýchán termín POWER7, což je nová 1

LPAR je rovněž virtualizační technologie zabudovaná do hardwaru IBM System z. Pomocí LPAR hypervisora můžeme rozdělit System z mainframe do logických celků (LPARů). Každému LPARu přidělíme část volné fyzické paměti (centrální paměti). Disková pole, I/O kanály a procesory mohou být sdílené více LPARy nebo mohou být dedikovány samostatným jednotkám.


17

Obrázek 3.8: Schéma jednoduché z/VM architektury

řada procesorů, jež mohou obsahovat až osm jader, kde každé jádro je schopno obsluhovat až čtyři vlákna současné. Tento vysoký výkon byl například využit u počítače Waston, který porazil i ty nejúspěšnější hráče ve vědomostní soutěži Jeopardy! [32]. Podobně jako předchozí virtualizace z/VM i PowerVM vyžaduje speciální hardware pro svoji činnost. Tím je IBM Power Systems – například s procesory POWER5, POWER6 a POWER7. Dále byla také zachována integrace s předešlými systémy, tedy IBM System i a IBM System p. PowerVM se především používá k vytvoření velmi dynamické infrastruktury, kde je možné konsolidovat zátěž na jeden a více samostatných serverů, což např. snižuje celkové náklady. PowerVM podporuje pokročilé metody virtualizace, jako je Dynamic resource movement, kdy lze bez jakéhokoliv pozastavení činnosti jednotlivých operací migrovat zátěž z jednoho fyzického stroje na druhý. Tato funkcionalita může být využita při údržbě fyzických zařízení, neboť lze s nulovým dopadem na funkčnost přemigrovat zátěž na jiný stroj, provést údržbu a opět vše vrátit do původního stavu. S tímto souvisí i metoda Live Partition Mobility, kdy jsme schopni přenášet celé běžící virtuální stroje, aniž by je bylo nutné dočasně pozastavovat, či omezovat chod jejich aplikací. Micro-Partitioning zase například umožňuje snižovat náklady lepším a především jemnějším ladění výkonu, kdy lze jednotlivá procesorová jádra rozdělit až na deset samostatných oddílů a tyto výkonové jednotky přiřazovat různým nezávislým logickým jednotkám. Z pohledu operačních systémů podporuje například AIX, IBM i OS, Red Hat Enterprise Linux a SUSE Linux Enterprise Server [12]. Architektura Na obr. 3.9 vidíme jednoduchý náhled na architekturu systému s virtualizací PowerVM a třemi logickými jednotkami. V každé logické jednotce běží různá operační prostředí (AIX,

18


Virtual I/O Server a Linux) se svými příslušnými na sobě nezávislými aplikacemi, zatímco všechny jednotky sdílí stejné fyzické zdroje. Hypervisor je schopen přidělovat procesory, I/O zařízení, disková úložiště i paměť a dynamicky je přenastavovat podle potřeby jednotlivých logických celků. Nezávisle na logickém členění umí dále vytvořit sdílený procesorový pool, ze kterého následně přiděluje virtuální procesory logickým jednotkám – tato technologie se nazývá Micro-Partitioning. Z toho tedy plyne, že jeden fyzický procesor může být využit více logickými oddíly, zatímco pro každý z nich vykonává odlišnou (a na sobě nezávislou) operaci [34].

Obrázek 3.9: Schéma jednoduché PowerVM architektury

3.3.6

Hyper-V

Na rozdíl od předešlých zástupců virtualizačních technologií, kde můžeme jejich počátky nalézt již někdy v 60. letech 20. století, hypervisor Hyper-V je nejmladší ze všech. Poprvé byl uveřejněn jako (volitelná) součást Windows Serveru 2008, a to jak ve Standardní, Enterprise, tak také DataCenter verzi. V průběhu vývoje byl tento hypervisor znám pod kódovým označením „Viridian“ [2]. Hyper-V je technologie pro virtualizaci architektur x86-64, která vyžaduje hardwarovou podporu virtualizace, tedy v podobě speciálních procesorů s podporou virtualizace (již zmiňované Intel VT a AMD-V) [61]. Lze ji nalézt jakou instalovatelnou součást (roli) Windows Serveru 2008 nebo jako stand-alone verzi v podobě Microsoft Hyper-V Server 2008 [78]. Stand-alone verze obsahuje základní jádro systému a má povolenu pouze roli Hyper-V, ostatní jsou zakázány. Omezeny jsou i další funkcionality, služby (Services) apod. Z těchto důvodů zde k ovládání nalezneme pouze příkazovou řádku (CLI) – podobně jako u předešlých druhů virtualizace. Pokud se neobejdeme bez grafického rozhraní můžeme pro ovládání využít klasickou Microsoft Management Consoli (MMC) s příslušným snap-inem (podporovány jsou ale pouze OS Windows 7 a Windows 2008). Z pohledu podporovaných operačních systémů zde nalezneme především různé druhy OS Windows, dále pouze některé druhy Linux – např. Red Hat Enterprise Linux, SUSE Linux Enterprise Server a CentOS [60].


19

Architektura Podobně jako ostatní druhy virtualizačních technologií i Hyper-V vytváří logicky oddělené celky, které sdílí společný hardware s ostatními virtuálními instancemi, viz obr. 3.10. Zde tyto celky nazýváme oddíly (z anglického „partition“). Každé prostředí musí mít minimálně tzv. root, nebo také parent oddíl, kde běží Windows Server 2008 (nebo alespoň jádro s Hyper-V rolí). V této části je umístěna hlavní virtualizační vrstva, která má přímý přístup k fyzickému hardwaru. Pomocí volání tzv. Hypercall API vytváří požadované virtuální instance (Child Partitions).

Obrázek 3.10: Schéma jednoduché Hyper-V architektury

Jednotlivé virtuální instance nemají přímý přístup k fyzickému hardwaru, ani neobsluhují přerušení od procesorů. Mají pouze virtuální procesor a operují ve virtuálním adresním prostoru, který je pro každou instanci oddělen. Hypervisor obsluhuje všechna přerušení a přesměrovává je příslušným oddílům. Podobně jsou řešeny i zbylé hardwarové zdroje, a to pomocí tzv. virtuálních zařízení – virtual devices (VDevs). Požadavky na tato zařízení jsou přesměrovávány přes logickou sběrnici (kanál) VMBus, nebo přímo skrze hypervisor do parent partition, kde dochází opět k obsluze těchto požadavků. Zmíněná VMBus je v podstatě takový logický vnitřní mezi-oddílový (inter-partition) komunikační kanál (podobně jako XenBus). Na straně parent partition nalezneme servisní poskytovatele – Virtualization Service Providers (VSPs), kteří komunikují přes VMBus a obsluhují příchozí volání od servisních konzumentů – Virtualization Service Consumers (VSCs) na straně child partitions. Celý tento proces je samozřejmě transparentní všem hostovaným OS.

20


Podrobné vysvětlení pokročilých technologií Hyper-V, jako je například Enlightened I/O (zahrnuje speciální implementace komunikačních protokolů, jako je např. SCSI), včetně vysvětlení dalších vnitřních procesů a jednotlivých zkratek lze nalézt zde [46].

3.4

Shrnutí

V této kapitole jsem se zaměřil na pojem virtualizace, rozebral jsem základní druhy a uvedl jsem přehled vybraných technologií. Nezabýval jsem se zde z pohledu koncového uživatele často používanými virtualizačními prostředí, jako je například VMware Workstation, Oracle VirtualBox nebo Microsoft Virtual PC. Přehled technologií byl spíše orientován na enterprise prostředí, např. oblast datových center s vysokou koncentrací virtualizovaných strojů – tedy jedno z míst, kde lze uplatnit funkcionality cloudových systémů. Zmíněné virtualizační technologie jsou jedny z nejvíce používaných a ověřených. O jednotlivých systémech lze říci, přestože jsou více či méně odlišné, že volí obdobné přístupy při vytváření virtuálních strojů. Tedy na nejnižší vrstvě se nachází hardware s podporou virtualizace (např. schopný akcelerovat překlad adres). Na něm je umístěna softwarová vrstva (hypervisor) založená většinou na jádrech linuxových systémů. Ta umožňuje tvorbu virtuálních strojů a stará se o přidělování a management zdrojů jednotlivých virtuálních instancí.

Kapitola 4

Cloud Computing V této kapitole se zaměřím na předmět samotné práce, cloud computing. Budu se zabývat definicí pojmu a především vymezením jednotlivých vlastností. Z historického hlediska zařadím cloud computing do příslušné hierarchie a krátce popíši, co toto řešení přináší nového. V závěru také shrnu modely nasazení a modely služeb.

4.1

Definice a vymezení pojmu

Pokusit se zde v krátkosti definovat, co je cloud computing, považuji za zcela nemožné. I přesto, že je tento princip znám již nějakou dobu, každý si jeho užití vykládá především pro své potřeby – většinou marketingové. Řekl bych, že v mnoha případech je cloud computing spojován i s věcmi, se kterými nemá vůbec nic společného. O pokusech jednoznačně definovat cloud computing se dočteme v nejednom vědeckém článku, jako je například A break in the clouds: towards a cloud definition [16], který rozebírá více jak 20 definic. Vznikají dokonce články s cílem oslovit přední experty, aby se pokusili o svoji definici [5]. Právě z těchto podkladů je poměrně krásně vidět, že každý chápe cloud computing odlišným způsobem. Pro příklad bych rád uvedl tvrzeni Trevora Doerksena, které zní [5]: „Cloud computing is. . . the user-friendly version of grid computing.1 “ Cílem této práce není hledat samotnou definici, ale soustředit se na cloud computing jako takový. Tedy používat obecně chápané principy a vycházet z nich. Rád bych zde uvedl jednu z prvních, ale zároveň často upřednostňovaných, definic cloud computingu Národního institutu standardů a technologie při Ministerstvu obchodu USA (NIST). Jejími autory jsou Peter Mell a Tim Grance [7]. „Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, 1

Volně přeloženo jako: „Cloud computing je. . . uživatelsky přívětivá verze grid computingu.“

21

22

KAPITOLA 4. CLOUD COMPUTING

applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.2 “ Z této definice již poměrně jasněji vyplývá samotný význam cloud computingu. Především ho lze chápat jako nové paradigma poskytování počítačových služeb, přístup při poskytování služeb, služeb na vyžádání – on-demand. Dále tato definice hovoří o jednoduchosti přístupu k poskytovaným zdrojům služby, v dnešní době povětšinou chápáno skrze internetový prohlížeč a internet jako takový. Přesněji nespecifikuje daný typ služby – může se jednat např. pouze o jednoduchou aplikaci, datové úložiště, nebo také vysoce komplexní a strukturovanou výpočetní síť mnoha počítačů. Neméně důležitým bodem je fakt, že vytvoření požadované služby by se mělo dít bez vetší účasti samotného poskytovatele služby (SP – Service Provider), tedy automatizovaně.

4.1.1

Obecné vlastnosti

Na základě výše uvedené definice si nyní více podtrhneme a rozebereme jednotlivé obecné vlastnosti, které od cloud computingu lze očekávat, a seznámíme se s pojmy, se kterými se v této oblasti můžeme setkat. 4.1.1.1

Služba na vyžádání a standardizace

Jak již bylo řečeno, hovoříme-li o cloud computingu, vždy musíme mít na paměti, že se jedná o druh služby. Co více, jedná se o takový druh služby, při které bychom neměli přijít do kontaktu se samotným providerem, který nám službu poskytuje. Lépe řečeno jsme schopni službu získat sami bez jeho aktivní součinnosti. Nejlépe tuto vlastnost vystihuje spojení anglických slov „On-demand self-service“. Zároveň je nutné zmínit, že nabízená služba je v rámci cloudového prostředí standardizována. Nelze ji jednoduše měnit. Je ji možné objednat z poskytované nabídky (katalogu) služeb, kde jsme ale schopni ovlivnit většinou jen základní nastavení. Příkladem budiž služba, kdy je nám pronajímán předem definovaný virtuální stroj a my máme možnost upravit pouze jeho velikost RAM, a to v rámci mezí definovaných samotným poskytovatelem. 4.1.1.2

Dostupnost služby

Zaměříme-li se na dostupnost služby, kterou požadujeme, měl by cloud computing splňovat fakt, že všechny jeho funkce jsou dostupné skrze síť (internet/intranet), a samotný přístup že lze zrealizovat pomocí standardních mechanismů, které podporují použití různorodých platforem tenkých nebo tlustých klientů (např. mobilních telefonů, notebooků a PDA). Ve většině případů se při požadování samotné služby setkáme vždy s webovým rozhraním, pro přenosy dat se standardními protokoly jako FTP, NFS či CIFS (SMB), nejinak tomu je i pro případné vzdálené přístupy apod. 2

Volně přeloženo jako: „Cloud computing je model umožňující pohodlný a na požádání dostupný síťový přístup ke sdílenému souboru konfigurovatelných výpočetních zdrojů (např. sítím, serverům, datovým úložištím, aplikacím a službám), které mohou být rychle zprovozněny a uvolňovány s minimálním úsilím nebo interakcí poskytovatele služeb.“

4.1. DEFINICE A VYMEZENÍ POJMU

4.1.1.3

23

Sdružování prostředků

Výpočetní zdroje poskytovatele jsou sdružovány, aby byl schopen obsloužit více zákazníků (uživatelů služeb) pomocí tzv. multi-tenant modelu (viz dále 4.1.1.7). Různé fyzické i virtuální prostředky tak mohou být na základě požadavků jednotlivých uživatelů dynamicky přidělovány, odebírány a znovu používány. Z důvodu nutnosti konsolidovat výpočetní zdroje nemá koncový uživatel služby možnost blíže ovlivnit přesnou polohu umístění jeho užívaných prostředků. V několika málo případech může vše ovlivnit maximálně na vyšší úrovni abstrakce (např. volbou země, státu, nebo datového centra). Celou dobu ale užívá službu, která je jakoby „na umístění nezávislá“. S tím samozřejmě souvisí otázka bezpečnosti dat3 . Jako příklad poskytovaných zdrojů uveďme datová úložiště, procesorový výkon, paměť, šířku pásma síťové komunikace nebo samotný virtuální stroj. 4.1.1.4

Pružnost

Pružnost je schopnost rychle reagovat na potřeby uživatele, tedy např. pokud u své služby vyžaduje vyšší výkon, je jí přidělen. Stejně tak v opačném případě, kdy jí může být odebrán. Nutno podotknout, že od celého procesu se očekává co možná nejkratší doba provedení požadovaných změn. Pro porovnání uveďme příklad, kdy u poskytovatele provozujeme vlastní počítač ovládaný přes vzdálenou plochu. V případě, že je cílový stroj fyzický, bude poskytovateli služby nějakou dobu trvat, než Vám zajistí novou RAM, kterou požadujete, nainstaluje ji atd. Pokud je ale koncový stroj virtuální a poskytovatel má dostatečné hardwarové (sdružené) prostředky je celý proces zvýšení RAM otázkou pár minut a jednoho restartu Vašeho počítače. Jak již bylo řečeno, v prostředí cloudu bychom neměli být příliš závislí na součinnosti s osobou poskytovatele služby, a tím pádem celý proces navýšení výkonu (RAM) jsme schopni provést sami a je otázkou několika minut. 4.1.1.5

Flexibilní cena

Neméně důležitou věcí spojenou se zmíněnými cloudovými službami je jejich cena. Cloudové systémy by měly být schopny automaticky kontrolovat a optimalizovat využívání zdrojů pomocí schopnosti měřit jejich používání, a to v závislosti na typu služby, na příslušné úrovni abstrakce (např. množství I/O operací diskových úložišť, spotřebovaný procesorový čas a počet aktivních uživatelských účtů). Používání zdrojů by mělo být samozřejmě monitorováno, kontrolováno a reportováno, a to jak poskytovateli služby, tak také uživateli, který má danou službu zakoupenu. Důležité je zde dokázat od sebe odlišit jednotlivé uživatele a pouze jejich příslušné spotřebované prostředky. 3

Otázka fyzického uložení dat je v některých zemích omezena jejími státními hranicemi, tedy nelze využívat služeb, při kterých neznáme přesné umístění našich dat. V této souvislosti je potřeba si také uvědomit nutnost redundance ukládaných dat – zajištění vysoké dostupnosti (HA). Ta je v některých případech řešena i mezikontinentálními uzly, které jsou navzájem synchronizovány.

24


Na rozdíl od klasického prostředí poskytovatele služeb v prostředí cloud computingu by se mělo platit pouze za to, co bylo spotřebováno. Podobně jako je tomu v běžném životě např. za elektřinu, či za pitnou vodu. Tento model užívání služeb, kdy platíme pouze za to, co spotřebujeme, se nazýván „Payper-use“, či také „utility model“. 4.1.1.6

Virtualizace

Jedním z důvodů, proč jsem se na začátku této práce zaměřil na pojem virtualizace a soustředil jsem se pouze na řešení schopná provozu v enterprise prostředí (viz kap. 3) je fakt, že k uspokojování požadavků a nabízení jednotlivých služeb v prostředí cloudu hraje virtualizace klíčovou roli. Virtualizace nám umožňuje částečně se oprostit od fyzické infrastruktury, sdílet fyzické prostředky a maximálně tak využívat fyzický hardware, jehož výkon používáme jako poskytovanou službu. Především nám ale také umožňuje konsolidovat prostředky, o kterých jsem se zmínil výše, viz kapitola 4.1.1.3. 4.1.1.7

Multi-tenancy

Anglický termín, který jsem se rozhodl do češtiny nepřekládat (znamenalo by „více nájemců“). V podstatě se jedná o princip softwarové architektury, kde je jediná instance daného softwaru nasazena na server a je zároveň provozována více uživateli. Tento termín je většinou spojován s úsporou nákladů na provoz, a to díky jednodušší škálovatelnosti při provozu na sdružených prostředcích. Další výhodou tohoto řešení je možnost jakéhosi vzájemného propůjčování a přelévání výkonu, kdy lze dočasně využívat fyzické zdroje přidělené jednomu uživateli, který je dočasně nevyužívá, a opět mu je vracet. Nasazení tohoto modelu v prostředí cloud computingu je více než logické, neboť jak jsem již zmínil výše, platíme pouze za to, co spotřebujeme. Tedy toto dočasné pronajímání výkonu nám, jako poskytovateli služby, může maximálně ušetřit celkové náklady, nijak neovlivní paralelní chod více uživatelů a uživatel služby zaplatí za to, co spotřeboval. S tímto modelem je ale také spojeno několik problémů. Tím nejkritičtějším je opět bezpečnost, a to především dat jednotlivých uživatelů. Na úrovni logiky aplikace (služby) musíme jednotlivým uživatelům zajistit přístup pouze k datům, která opravdu vlastní. V databázi mohou být všechna data ukládána do společných tabulek, či mohou být pro každého uživatele dané služby vytvořeny samostatné databáze. Dalším specifickým požadavkem je také možnost přizpůsobit prostředí na míru zákazníka, tedy je potřeba, aby existovala jakási nová vrstva sdružující potřebná meta data, kde lze příslušné parametry měnit (např. specifická nastavení pro daného zákazníka, grafické rozložení základních komponent systému a vzhled uživatelského portálu – např. pomocí kaskádových stylů (CSS), různá loga apod.). Na obr. 4.1 vidíme konkrétní příklad popisovaného prostředí [49] – roli poskytovatele služby (ASP – Application Service Provider), několik koncových zákazníků, data, která jím přísluší, a nakonec zmiňovaná meta data (CSR – Customer Service Representatives), která se váží k vrstvě zajišťující samotné logické oddělení (OAAM – Oracle Adaptive Access Manager).


25

Obrázek 4.1: Multi-tenancy architektura

Podobnými a zde blíže nespecifikovanými softwarovými architekturami jsou single-tenancy, kde uživatel (zákazník) používá aplikaci sám, bez sdílení s ostatními uživateli, a multiinstance, kde je každá instance aplikace samostatně usazena na odděleném fyzickém hardwaru. 4.1.1.8

Dynamická infrastruktura

Dynamická infrastruktura je dalším paradigmatem informačních technologií týkajících se návrhu datových center tak, aby základní hardware a software mohl dynamicky reagovat na měnící se úroveň poptávky služeb, a to především účinnějším způsobem než dříve. Cloud computing je jedním z nástrojů jak daných požadavků dosáhnout, především pomocí virtualizace. Dynamická infrastruktura jednotlivým poskytovatelům služeb umožňuje především lépe využívat všechny jejich nabízené prostředky, tedy servery, datová úložiště, síťovou infrastrukturu či aplikace, což vede opět k již zmiňované úspoře nákladů. 4.1.1.9

Automatizace

Automatizace, jak již z předešlých sekcí více či méně vyplynulo, je jedním z hlavních základů cloud computingu. Samotné jádro služby ji přímo z definice vyžaduje, kdy je tedy především cílem snížit spoluúčast poskytovatele služby při procesu jejího vytvoření, poskytnutí přístupu a informování o úspěšnosti, či chybě celého procesu. Z toho všeho tedy vyplývá, že automatizace především snižuje chyby, které by mohly být vytvořeny manuálními zásahy (lidským přičiněním). V případě, že jsou procesy správně

26


nastaveny a dokáží samy řešit případné problémy, či alespoň o nich informovat, lze z tohoto nastavení vytěžit maximum. 4.1.1.10

Provisioning

Posledním znakem, který bych rád uvedl k samotné definici cloud computingu jako služby a jeho vlastností, je provisioning. Z důvodu oblasti, ve které se pohybujeme, jsem se rozhodl toto slovo opět do češtiny nepřekládat, neboť se s ním zde běžně setkáváme a bereme ho již jako počeštělý výraz. Pokud hovoříme o provisioningu míníme tím samotné obstarání, vytvoření, nasazení a zprovoznění požadované služby. Například v případě poskytování počítačové platformy jako služby (viz kapitola 4.3.2) je provisioning spojován s vytvořením požadované virtuální instance dle předem daného modelu (šablony), nastavením prostředí, začleněním do síťové infrastruktury a případnou instalací aplikací vzdálené správy, monitoringu či aplikací třetích stran. Pro zachování modelu cloud computingu je tento proces samozřejmě automatizovaný.

4.1.2

Porovnání přístupů

Jak jsem již zmínil v úvodu této kapitoly (viz 4.1), každý nahlíží na cloud computing z jiného pohledu. Pro celkové vymezení pojmů tedy považuji za nutné krátce se věnovat porovnání cloud computingu s dosud užívanými počítačovými přístupy v oblasti zpracování dat a poskytování služeb. 4.1.2.1

Cluster Computing

Hovoříme-li o cluster computingu, míníme tím skupinu serverů a jiných zdrojů, které fungují jako jednotný systém umožňující vysokou dostupnost, v některých případech vyvažování zátěže a paralelní zpracování. Důležité je zde poznamenat, že na rozdíl od grid computingu (viz kapitola 4.1.2.2) jsou jednotlivé počítače v clusteru poměrně pevně svázány. Každý počítač může např. vykonávat samostatnou operaci pro dosažení vysoké škálovatelnosti, ale ve chvíli, kdy by byla činnost jednoho uzlu třeba přerušena, je schopen jiný uzel clusteru bez celkového přerušení v činnosti pokračovat (v oblasti webových služeb můžeme využít principů session managementu apod.). Z pohledu členění můžeme clustery dělit na: • vertikální – kdy máme více logických uzlů nasazených na společném hardware, obsluhují je společné procesory, jednotlivá vlákna, • horizontální – které volíme především pro zajištění vysoké dostupnosti nasazených služeb, kdy jsou jednotlivé uzly umístěny na fyzicky (v některých případech především i geograficky) odděleném hardwaru. Cloud a cluster computing nejsou jednoznačné protiklady a tedy lze nalézt jejich společné znaky a vzájemné překrývání funkcionalit. Jednou z nich může být sdílena infrastruktura, virtualizace, ale také podpora pro více vzájemných provozovatelů služby (multi-tenancy). Na


27

druhou stranu je ale potřeba si uvědomit, že cluster většinou vytváříme pro účely realizace jediného sytému především z důvodu požadavku vysokého výkonu, dobré škálovatelnosti a k dosažení jednotného cíle (určitého úkolu). Cloud computing je především prostředí, kde každý jeho člen pracuje nezávisle na ostatních, bez společného cíle (ve smyslu různorodosti poskytovaných služeb). Konkrétní příklad kdy se oba systémy mohou doplňovat je architektura, kde je cluster využit pro zajištění vysoké dostupnosti (HA) management vrstvy cloudových služeb. Jednodušeji řečeno můžeme strukturu cloudových aplikací vytvářející samotnou funkcionalitu prostředí cloudu nasadit na cluster – především z důvodu bezpečnosti a odolnosti proti pádu.

4.1.2.2

Grid Computing

Z definice [1] grid computing vymezuje rozsáhlou distribuovanou geografickou síť hardwarové a softwarové infrastruktury složené z různorodých síťových zdrojů vlastněných a sdílených více správními organizacemi, které jsou koordinovány poskytovat transparentní, spolehlivou, všudypřítomnou a konzistentní výpočetní podporu pro širokou škálu aplikací. Tyto aplikace mohou provádět buď distribuované výpočty, simulovat výkonné počítače s vysokou propustností, datově náročné výpočty, kolaborativní výpočty nebo multimediální výpočty. Jedná se tedy o paralelní a distribuovaný systém založený na volném spojení vysokého počtu samostatně operujících jednotek (počítačů), které dohromady řeší rozsáhlý problém, jak je vidět na obr. 4.2. Příkladem může být projekt SETI [54], či World Community Grid [80].

Obrázek 4.2: Grid Computing

28


Hlavním rozdílem mezi cloud a grid computingem je fakt, že zatímco grid computing se skládá z mnoha samostatných počítačů spolupracujících na dosažení jednoho cíle, cílem cloud computingu je poskytnout výpočetní prostředky pro tyto nezávislé úkoly, tedy vytvořit požadovanou infrastrukturu a také sdružit jednotlivé sítě (gridy) dohromady. Lépe bude rozdíl vysvětlen v následující části, která vytvoří celkový náhled na danou problematiku. 4.1.2.3

Celkový pohled

Z historického hlediska lze o cloud computingu hovořit jako o vývojovém stádiu distribuovaných počítačových architektur. Na počátku byly výkonné superpočítače s vysokou paralelizací na mnoha procesorech, jejichž výpočetní výkon byl úzce soustředěn na specifickou oblast zájmu. Tyto stroje byly ovládány pouze pomocí lokálních terminálů a díky jejich složitosti si je mohl dovolit málokdo. Postupem času (během 90. let) začala být tato řešení pomalu nahrazována počítačovými clustery, které byly spravovány jediným vlastníkem. Důležité je zde především zmínit, že clustery sloužily pouze pro vlastní (privátní) použití a na rozdíl od superpočítačů byly orientovány na širší oblast použití, samotné aplikace. Na konci 90. let se objevil nový koncept v podobě grid computingu, který přinesl především větší distribuovanost. Na rozdíl od předešlých stupňů je zde důraz kladen již na veřejnou doménu, tedy vše je propojeno pomocí internetu nezávisle na tom, kým jsou koncové stanice spravovány. Z hlediska cílového použití nelze jednoznačně rozlišit, pro kterou oblast je tento výpočetní výkon použit. Grid computing může být chápán jako síť clusterů a koncových stanic. Cloud computing reprezentuje prozatím poslední vývojový článek. I přesto že může být částečně chápán jako krok zpět – především v podobě návratu ke konceptu superpočítačů, tedy jednotnému systému (zde ale v podobě virtualizované infrastruktury), přináší a rozšiřuje myšlenku výpočetních zdrojů jako služby, která se prvně objevila již v oblasti grid computingu. Na rozdíl od grid computingu ale věnuje větší pozornost samotným možnostem použití, nerozlišuje typ služby, poskytuje např. hardware, operační systém, aplikace a ne pouze výpočetní výkon. Tento nový vývojový stupeň může být chápán jako síť sítí (gridů). Výše popsaná vývojová stádia jsou přehledně zakreslena do grafu na obr. 4.3 [4], kde na ose X nalezneme jakým směrem je systém orientován a na ose Y měřítko použití. Vidíme, že jednotlivé systémy se v použití vzájemně překrývají.

4.1.3

Cloud Computing z pohledu koncového uživatele

Na základě doposud popisovaných vlastností a vymezení jednotlivých funkcionalit si nyní vyspecifikujeme, jak by služba cloud computingu měla vypadat z pohledu koncového uživatele. • První důležitou věcí je jednoduchá dostupnost služby, tedy v dnešní době s využitím internetových technologií bez nutnosti cokoliv dodatečně instalovat.

4.2. MODELY NASAZENÍ CLOUDU

29

Obrázek 4.3: Cloud Computing v porovnání s předešlými vývojovými modely

• Jak také bylo zmíněno, měli bychom si býti schopni službu objednat (vyžádat) sami, bez nutnosti jakékoliv spoluúčasti poskytovatele. Potřebujeme tedy jednoduchý samoobslužný portál. • Abychom měli z čeho vybírat je současně požadována existence nějaké poskytované nabídky (katalogu) služeb. V tomto směru bychom také měli být schopni si službu dále přizpůsobit vlastním potřebám, tedy možnost vlastní customizace služby. • Od cloudu se následně očekává, že provede provisioning – příslušné kroky, které vedou k vytvoření požadované služby. Vše opět automaticky bez zásahů poskytovatele služby. • Jako koncový uživatel jsme informováni o stavu našeho požadavku a v případě úspěšného vytvoření služby obdržíme zároveň i informace, jakým způsobem můžeme službu začít využívat, např. jak se k ní připojit. • Dle poskytnuté služby následně platíme za její užívání, a to podle modelu „pay-peruse“ pouze za to, co jsme spotřebovali (někdy se tento princip také označuje jako „utility model“).

4.2

Modely nasazení cloudu

Modely nasazení cloud computingu nám definují místo použití, odpovědnost za správu a přístupy k prostředím. Dle těchto předpokladů rozlišujeme tří základní modely, viz obr. 4.4.

30


Obrázek 4.4: Modely nasazení

4.2.1

Private Cloud

Nasazení v podobě privátního cloudu (někdy také označováno jako interní cloud) nám především zdůrazňuje, že celá služba je využívána pro interní účely (myšleno např. jedinou společností), v rámci interní sítě (intranetu), za firemním firewallem. Samotné prostředí managementu a správy fyzického hardwaru zajišťuje rovněž vlastník. Celkové služby a vlastnosti cloudu jsou tedy využívány pouze jednotlivými uživateli dané organizace. Podstatnou výhodou takovéhoto nasazení je jednoznačný přehled o tom, kde se poskytované služby, virtuální stroje a především jakákoliv interní data nacházejí. Jelikož není fyzická infrastruktura a její výkon sdílen s více uživateli (např. různými firmami), je toto řešení bezpečnější z pohledu nutnosti zajistit jednoznačné oddělení prostředí a vícenásobný přístup ke sdíleným prostředkům různých uživatelů (multi-tenancy). U organizací pracujících s citlivými daty, jako jsou např. banky, je toto jeden z nejvíce upřednostňovaných modelů. 4.2.1.1

Managed Private Cloud

Z pohledu umístění jednotlivých poskytovaných služeb a správy dané infrastruktury hovoříme o tzv. Managed Private Cloudu, kdy je opět celá fyzická infrastruktura umístěna u koncového uživatele (společnosti), ale starost o poskytování služeb, správu hardwaru a s tím spojené operace jsou spravovány pro tuto činnost specializovanou firmou třetí strany. 4.2.1.2

Hosted Private Cloud

Druhým typem privátních cloudů je model Hosted Private Cloud, který nám zachovává všechny vlastnosti privátních cloudů, ale v tomto případě je celková starost o hardware (fyzická infrastruktura) včetně veškerých služeb týkajících se správy prostředí atd. přenesena na stranu jiné firmy (poskytovatele). Tato firma musí pro své klienty zajistit dedikovaný hardware jen a pouze pro jejich vlastní potřeby. V mnoha literaturách lze tento koncept nalézt zároveň pod pojmem Virtual Private Cloud. Samotné použití tohoto konceptu můžeme nalézt především u společností, které požadují krátkodobě překlenout potřebu vyšší výpočetní kapacity, nebo např. dočasně rozšířit vlastní interní prostředí. Na rozdíl od následujícího konceptu (viz kapitola 4.2.2) zde musíme neustále zajišťovat vysokou míru izolace od okolního prostředí.

4.3. MODELY CLOUDOVÝCH SLUŽEB

4.2.2

31

Public Cloud

Public cloud, nebo-li veřejný (externí) cloud, je klasický model, který je obecně znám a chápán jako počátek cloudových služeb. Jakékoliv zdroje, ať již v podobě virtuálních strojů, aplikací, či výpočetního výkonu jsou spojeny především s možností kdykoliv si je vyžádat pomocí samoobslužného portálu u poskytovatele třetí strany (běžně přes internet, ne v rámci intranetu), který nám tím dává k dispozici jeho vlastní prostředky jako službu. Stejně jako u všech modelů i zde platíme pouze za to, co spotřebujeme (tzv. Pay-per-use). Public cloud nás obecně odstiňuje od jakékoliv nutnosti spravovat námi využívanou službu, provádět zálohování, či starat se o bezpečnost. Vše zajišťuje poskytovatel dané služby. Tento model umožňuje snížit celkové investice do požadované služby, což může být nejen aplikace (např. email, kalendář, webová konference) a virtuální stroje, ale i sdílení dat, bandwidth (šířka pásma), či výpočetní výkon. To, co dělá tento model veřejným a zároveň odlišným od interních cloudů provozovaných třetí stranou (viz kapitola 4.2.1.2) je fakt, že hardwarové prostředky (např. pro virtuální stroje) jsou sdílené. V případě čistě softwarových služeb mohou býti sdílené i databáze s našimi daty. Zde je tedy nutné zajistit vyšší míru odstínění a zabezpečení pro jednotlivé uživatele. 4.2.2.1

Shared Cloud

Shared cloud, někdy také často označováný jako Community cloud, je veřejný cloud, který sdružuje více různých uživatelů organizací (firem) do jedné komunity se společným zájmem jako jsou společné cíle (např. výzkum), bezpečnostní požadavky či politiky. V porovnání s klasickým modelem veřejného cloudu zde nalezneme menší spektrum různých uživatelů. Obecně lze říci, že pro organizace, které jsou součástí dané komunity, se tento model nasazení tváří jako veřejný cloud. Navenek však tento model vytváří jistou formu privátního cloudu.

4.2.3

Hybrid Cloud

Posledním z modelů nasazení cloudu je Hybrid cloud, který kombinuje vlastnosti obou předchozích – privátního a veřejného cloudu. Tento model je převážně využíván poskytovateli služeb, kteří se nesoustředí např. pouze na sektor veřejných cloudů, ale zároveň nabízejí i služby privátních cloudů. Další z možností je použití především u firem, které pro vlastní použití provozují model privátního cloudu. Prostředky, které prozatím nevyužívají jsou dále schopni prodávat jako službu v rámci nabídky veřejného cloudu.

4.3

Modely cloudových služeb

V této sekci krátce shrnu základní typy poskytovaných cloudových služeb, a to pouze v obecné rovině. Z hlediska výsledného nasazení lze samozřejmě oba modely (modely nasazení a modely služeb) libovolně kombinovat. Platí zde jakési pravidlo, že vše je poskytováno jako služba „...aaS“ (z anglického „asa-service“). Na obr. 4.5 [37] vidíme základní hierarchii, kde každá vyšší úroveň již obsahuje

32


všechny vrstvy nižší úrovně. Zajímavé je také soustředit se na to, komu je každý z modelů především určen.

Obrázek 4.5: Základní modely cloudových služeb

4.3.1

IaaS

IaaS, nebo-li Infrastructure as a Service, je základním modelem v rámci něhož získáváme k dispozici nejnižší možnou vrstvu výpočetních prostředků – samotný hardware, infrastrukturu. Hovoříme zde především o diskových úložištích, procesorovém výpočetním výkonu, síťové infrastruktuře, obecně o serverech a síťových komponentách. Samotný uživatel má možnost si na tyto zdroje nasadit vlastní software, především operační systém a aplikace. Nestará se o správu samotné infrastruktury. Tento model je především určen pro systémové či databázové administrátory, kteří budují základní platformu pro další použití.

4.3.2

PaaS

Dalším modelem (vrstvou), kterou lze v cloudu poskytovat je již zmíněná platforma, nebo-li PaaS – Platform as a Service. Samozřejmě zde hovoříme o výpočetní platformě tedy o hardwarových prostředcích (architekturách), softwarových frameworcích a samozřejmě aplikačních frameworcích, které nám umožňují nasazení, běh a vývoj naších aplikací. Konkrétně zde můžeme hovořit o aplikačních serverech, databázích, vývojových rozhraních, běhových a vývojových prostředí apod. Součástí této služby je běžně operační systém, na kterém jsou požadované komponenty již umístěny. Tato služba nám tedy usnadňuje nasazení aplikací bez nákladů a složitosti řízení nákupu a souvisejících procesů s přípravou hardwarových a softwarových vrstev.

4.3. MODELY CLOUDOVÝCH SLUŽEB

33

Vidíme, že model PaaS je především orientován na návrh, vývoj a provoz aplikací, tedy pro oblast uživatelů jako jsou aplikační vývojáři, vývojové týmy či deployment administrátoři.

4.3.3

SaaS

Poslední službou, kterou nalezneme v mnoha odborných článcích a definicích, je SaaS, známá jako Software as a Service. Tato vrstva rozšiřuje PaaS a jak její název napovídá, jejím cílem je poskytnout samotný software, a to bez naší nutnosti ho předtím instalovat a jakkoliv konfigurovat. Výhodou tohoto modelu je především jednoduchý přístup (přes internet) a tedy možnost poskytnout službu širokému spektru uživatelů. Na straně providera je celková správa systému, a to jak samotné aplikace, tak platformy (aplikačních serverů, databází), operačního systému a samozřejmě hardwaru. Součástí je i starost o odstínění profilů jednotlivých uživatelů (multi-tenancy) a jejich dat. Elegantně je v tomto prostředí řešen jakýkoliv upgrade poskytované aplikace, neboť tato činnost je provedena pouze jednou a změny se projeví automaticky u všech uživatelů. Nejjednodušším příkladem budiž např. emailové služby. Nejvyšší vrstva modelu je tedy jedna z nejobtížněji poskytovaných, co se týče aktivit nutných ze strany providera, ale z pohledu koncového uživatele, pro kterého je tato služba především určena, se naopak jedná o službu nejjednodušší.

4.3.4

DaaS, BaaS,. . .

V poslední době s postupným rozšiřováním a „boomem“ cloudových technologií se začínají objevovat i méně standardní termíny, které se pojí s poskytováním služeb. Jedním z nich je např. DaaS4 , nebo-li Desktop as a Service, označení pro službu, kdy celý náš osobní počítač („desktop“) běží „někde“ v prostředí cloudu (tzv. Desktop Cloud) a my se k němu připojujeme pouze vzdáleně, a to buď přes klasická rozhraní jako je např. RDP (Remote Desktop Protokol), nebo používáme speciálního tenkého klienta (terminál) v podobě jednoúčelového specializovaného hardwaru. Dalším termínem může být i BaaS (Business as a Service), což lze považovat za jakýsi abstraktní model SaaS, kdy si se službou nekupujeme pouze celkové firemní prostředí (software, nástroje), ale také procesy mezi jednotlivými moduly (business řešení), někdy se dokonce hovoří i o „know-how“, bohatých znalostí a zkušeností z reálného světa. Získáváme tím tedy jakýsi nástroj (službu), který by měl zjednodušovat rozhodování a vést firmu správným směrem k dosažení požadovaných obchodních cílů. Samotný dodavatel služby, který nejen poskytuje samotné řešení, se tedy v podstatě podílí na částečném řízení a strategii společnosti [20]. Osobně bych tento model přirovnal k určité formě outsourcingu. Bez dalšího popisování vlastností uvedu termíny, se kterými se dnes můžeme také setkat, a to např. BPaaS (Business process as a Service), PraaS (Process as a Service), BPMaaS (Business Process Management (BPM) as a Service), EaaS (Enterprise as a Service), MaaS (Management as a Service, nebo také Modeling as a Service) atd. 4

V některých literaturách nalezneme tuto zkratku pro vyjádření termínu Data as a Service, což lze částečně považovat za předchůdce modelu SaaS, se kterým je tento termín často spojován.

34


Část II

Analytická část

35

Kapitola 5

Cloudové technologie IBM Tato práce si nedává za cíl vytvořit kompletní přehled či rešerši všech cloudových řešení na trhu, a proto jsem se ve výsledku rozhodl zaměřit se pouze na uvedení stručného přehledu základních konceptů, které nabízí firma IBM, a více se věnovat především samotnému řešení IBM Service Delivery Manager (viz kapitola 5.6).

5.1

Pokrytí služeb

IBM se jako jedna z technologicky nejvyspělejších firem na světě nesoustředí pouze na úzké specifické místo na trhu, ale snaží se pokrývat většinu konceptů a aktuálních trendů. Příkladem může být speciální hardware v podobě známých serverových řešení a moderních diskových polí – jako je IBM Storwize V7000 Unified [59], které dokáže zároveň ukládat data souborového, ale i blokového typu. Dále zde již byly zmíněny virtualizační platformy (viz výše z/VM a PowerVM v kapitolách 3.3.4 a 3.3.5). Současně také nabízí širokou škálu softwaru pro různorodé použití. Firma IBM se obecně se svým konceptem Smarter Planet [56] snaží zároveň obsáhnout širokou oblast služeb a jednou z nich je samozřejmě i cloud computing, s nímž se váže pojem IBM SmartCloud [55]. Tento termín by měl ve své podstatě obecně zastřešovat všechny základní zmíněné vlastnosti cloudu uvedené v kapitole 4 a také podporovat současnou vizi a směr vývoje firmy – vytvářet „chytřejší planetu“, viz obr. 5.1.

Obrázek 5.1: Logo vize IBM SmartCloud

37

38

5.2

KAPITOLA 5. CLOUDOVÉ TECHNOLOGIE IBM

IBM LotusLive

IBM LotusLive [44] je jedním z klasickým představitelů modelu SaaS (software jako služba – Software as a Service), který se zaměřuje především na oblast podpory spolupráce. Softwarové komponenty jsou zde poskytovány jako služba provozované nad cloudovou infrastrukturou. Přístup k nim je zajištěn skrze webový prohlížeč. Tyto služby mohou být použity kýmkoliv bez nutnosti instalace jakýchkoliv dalších IBM produktů na lokální počítač. Mezi základními softwarovými službami zde nalezneme elektronickou poštu, možnost pořádání webových a hlasových konferencí a videokonferencí, integrovanou sadu řešení podpory spolupráce ve víceúrovňově zabezpečeném prostředí, sdílení dokumentů i systém správy událostí a schůzek.

5.3

IBM SmartCloud Entry

IBM SmartCloud Entry [58] dodávaný jako IBM Starter Kit for Cloud je základní rychle nasaditelné řešení především pro privátní cloudy. Z pohledu modelu služeb ho lze zařadit mezi IaaS a PaaS. Jedná se o zástupce portfolia IBM SmartCloud Foundation (rodiny privátních cloudových řešení) do níž také patří např. řešení IBM SmartCloud Provisioning, které umožňuje vytvářet stovky virtuálních strojů během několika minut. Předností systému IBM Starter Kit for Cloud je rychlost nasazení a intuitivní ovládání přes webový samoobslužný portál. Samozřejmostí je existence servisního katalogu, kde uživatel volí z nabízených služeb, i reportovacího modulu pro účely účtování služeb. Pod samotnou cloudovou vrstvou se nachází vrstva virtualizační, kde je prozatím podporován vždy jen jeden hypervisor – pro System x je to VMware a pro System p PowerVM.

5.4

IBM SmartCloud Enterprise

IBM SmartCloud Enterprise [57] je označení pro IBM implementaci veřejného cloudu, která nabízí především modely služeb IaaS a PaaS. V nabídce servisního katalogu můžeme volit mezi několika předpřipravenými konfiguracemi virtuálních (Intel) serverů především s OS Windows 2003 a 2008, Red Hat i Novell SUSE, ale významnou část zde zastupují také předkonfigurované softwarové image s IBM produkty a produkty třetích stran. Tyto image nám poskytují např. možnost jednoduše a rychle vytvářet dočasná vývojová a testovací prostředí. Virtuální stroje (VMs) mohou být poskytovány jako stand-alone servery, nebo v kombinacích složitějších konfigurací, včetně load-balancingu a odolných infrastruktur. Přístup do veřejného cloudu je zajištěn pomocí samoobslužného webového portálu, který slouží jako místo pro volbu požadované služby. Nabízí přehled užívaných služeb a samozřejmě i náhled na cenovou bilanci. Volitelně je možné využít i VPN. IBM SmartCloud Enterprise nabízí několik modelů účtování, které probíhá v hodinových intervalech, např. Pay-as-you-go, kdy potvrzením licenčních podmínek daného software platíme pouze za jeho dočasné užívání, nebo také BYOL (Bring-Your-Own-License), kdy před zahájením provisioningu instance vložíme vlastní licenci daného software, a další.

5.5. TIVOLI SERVICE AUTOMATION MANAGER

39

Díky poměrně dobrému geografickému rozložení datových center je tato služba dostupná i z České republiky. Nám nejbližší datové centrum se nachází v Ehningenu (Německo). Co se týče veřejných cloudových služeb nabízí IBM nově také robustní sdílené prostředí s garantovaným SLA v podobě IBM SmartCloud Enterprise+. Jedná se o služby orientované na komplexní produkční prostředí a provoz aplikací s vysokou dostupností, kde nalezneme podporu i pro proprietární Unixový operační systém firmy IBM – AIX, účtování dle skutečného použití, vysokou dostupnost (99,9%) a víceúrovňovou bezpečnost.

5.5

Tivoli Service Automation Manager

Tivoli Service Automation Manager (TSAM) [67] je jedním z hlavních řešení IBM pro rychlou tvorbu, nasazení a customizaci privátních, hybridních ale i veřejných cloudů, a to v oblasti IaaS a PaaS. Jedná se o komplexní produkt, jehož unikátní předností je především široká podpora virtualizačních platforem – VMware, KVM, Power VM, Citrix Xen, z/VM a Hyper-V. V porovnání s výše zmíněným IBM Starter Kitem for Cloud (viz kapitola 5.3) však tyto různé virtualizační platformy dokáže obsluhovat zároveň. Větší možnosti využití tedy nabízí pro odlišnou oblast zákazníků, především největší klienty (enterprise). Toto řešení nabízí různorodé možnosti přizpůsobení a úprav, kterým lze samotný cloud poměrně dobře začlenit do infrastruktury objednavatele. A to nejen z hlediska vizuálního vzhledu samoobslužného portálu, ale také co se technické stránky týče. Zavedením specifických schvalovacích workflow tedy můžeme například uzpůsobit proces tvorby jednotlivých virtuálních strojů přímo dle předepsaných vnitřních procesů. Pokročilé funkce měření zdrojů, reportovací nástroje či vnitřní účtovací systémy (součástí ISDM) mohou být integrovány přímo s již existujícími systémy zákazníka apod.

5.5.1

Způsob implementace

Tivoli Service Automation Manager se skládá z několika samostatných IBM produktů, především z oblasti Tivoli, a jako každý jiný software je nutné před jeho používáním provést instalaci. Bohužel z důvodu poměrně vyšší složitosti celého systému a obsáhlosti použitých různorodých řešení, včetně nutnosti provedení příslušných konfigurací, je jeho instalace komplikovaná. Na druhou stranu ale tento přístup umožňuje mít kompletní kontrolu nad celým vytvářeným systémem. Z důvodu zjednodušení celého procesu nasazení tedy IBM nabízí IBM Service Delivery Manager [35], což je již předkonfigurované prostředí cloudu, které se skládá ze čtyř virtuálních image – například VMware image určených pro ESX/ESXi servery. Výhodou tohoto přístupu je především rychlejší nasazení, a to i na ne-IBM hardware. Bližší struktura bude objasněna v následující samostatné částí, viz kapitola 5.6. Nejucelenější způsob nasazení spočívá v použití řešení IBM CloudBurst, který je nabízen jako ready-to-go „box“ (osazený rack) včetně síťových prvků, diskových polí, pamětí a CPU, kde je celý softwarový balík již předinstalován. Tento přístup je vhodný především pro vytvoření privátního cloudu. Nevýhodou zde může být nutnost použití IBM hardwaru. Celkový přehled možností implementace je k vidění na obr. 5.2.

40


Obrázek 5.2: Způsob implementace řešení Tivoli Service Automation Manager

5.6

IBM Service Delivery Manager

Z výše popsaných způsobů nasazení (viz kapitola 5.5.1) považuji řešení IBM Service Delivery Manager (ISDM) za vůbec nejvýhodnější, neboť ulehčuje komplikovanou a zdlouhavou instalaci, ale zase na druhou stranu poskytuje možnost vlastní volby z hlediska nasazení na fyzický hardware a použití hardwarových zdrojů, které již vlastníme. Oproti samotnému TSAMu zde nalezneme navíc monitorovací nástroj IBM Tivoli Monitoring (ITM) a reportovací nástroj pro účtování za využívané služby IBM Tivoli Usage and Accounting Manager (TUAM).

5.6.1

Architektura softwarových komponent

Jak bylo zmíněno již výše, IBM Service Delivery Manager (verze 7.2.2) je dodáván jako čtyři virtuální image, a to buď určené do prostředí VMware nebo pro platformu PowerVM. Na obr. 5.3 [36] vidíme náhled na softwarové komponenty jednotlivých strojů, kde každý plní specifickou funkci.

Obrázek 5.3: Architektura softwarových komponent ISDM

5.6. IBM SERVICE DELIVERY MANAGER

41

• TSAM server. Tivoli Service Automation Manager, který je hlavním jádrem celého cloudu, běží nad databází DB2 v rámci aplikačního serveru WebSphere Application Server. Součástí tohoto serveru je také Tivoli Service Request Manager (TSRM) pro správu požadavků (např. o provisioning nového serveru) vytvořených ze samoobslužného portálu a Tivoli Provisioning Manager (TPM), jehož hlavním úkolem je správa samotných zdrojů a jejich alokace – tedy např. tvorba a konfigurace virtuálních strojů dle vytvořeného servisního požadavku. • NFS server. Tento server slouží především jako vstupní bod do celého systému. Nachází se zde HTTP server přesměrovávající jednotlivé požadavky na příslušné porty aplikačního serveru apod. Dále NFS server a SAMBA server (implementace síťového protokolu SMB), které slouží jako sdílená úložiště pro vnitřní potřeby cloudového systému – např. pro instalační balíčky. • ITM server. IBM Tivoli Monitoring (ITM) dokáže v reálném čase sledovat výkonnostní parametry a dostupnost jednotlivých virtuálních, ale také fyzických strojů v cloudové infrastruktuře. Díky integraci se speciálními agenty lze monitorovat nejen systémové parametry jako užívání CPU či RAM, ale také parametry aplikací spouštěných jako služby apod. • TUAM server. IBM Tivoli Usage and Accounting Manager (TUAM) je univerzální reportovací nástroj zpracovávající údaje o provozu a používání zdrojů, a to díky integraci se servery TSAM a ITM, jejichž vybrané informace si importuje do vlastní databáze. Nad těmito údaji jsou poté vytvářeny příslušné reporty či účtování služeb s ohledem na jednotlivé zákazníky a uživatele.

5.6.2

Vrstevnatost systému a obsluha požadavků

Cloudový systém ISDM lze z architektonického hlediska rozdělit na několik vrstev. Tou nejnižší je samotný fyzický hardware se síťovými prvky, diskovými poli apod. na němž je dle serverové architektury umístěna příslušná vrstva virtualizace s vlastní řídící vrstvou – pro System x tedy například virtualizované prostředí VMware ESX/ESXi s řídící vrstvou VMware Virtual Center (vCenter), nebo pro System p virtualizace PowerVM s řídící vrstvou IBM Systems Director VMControl. Obecně o této úrovni hovoříme jako o spravovaném prostředí (Managed environment), což je právě to místo, kde se dynamicky (a zároveň automaticky) alokují a dealokují zdroje dle požadavků přicházejících ze samoobslužného portálu, viz obr. 5.4. Nad touto řízenou vrstvou se nachází vrstva řídící (Managing environment), kde nalezneme výše zmíněné softwarové komponenty, které spolu vzájemně spolupracují. Uživatel, který je ověřen např. pomocí Tivoli Directory Serveru, což je systém správy identit – Lightweight Directory Access Protocol (LDAP), přistupuje k samoobslužnému portálu (Services portal). Zde, v servisním katalogu, volí z jednotlivých servisních nabídek (service offerings). Po ověření dostupnosti zdrojů vzniká příslušný servisní požadavek (service request), který putuje do TSRM. Ve chvíli, kdy je do cloudu vložen nový servisní požadavek, dochází obecně ke spuštění tzv. management plánu, jež se od ISDM verze 7.2 nazývá Runbook. Jednoduše se jedná

42


Obrázek 5.4: Architektura cloudového systému ISDM

o definované procesní workflow nejvyšší úrovně, které je řízeno základní procesní vrstvou ISDM cloudu – Tivoli Process Automation Enginem (TPAE), dříve Maximo. Runbook se skládá z předem definovaných procesních uzlů a je vždy specifický pro jednotlivé servisní definice. Tedy například runbook pro přidání serveru do existujícího projektu se nazývá PMRDPRUADD1 (Add Server Runbook) nebo PMRDPRUSMI1 (Save Image Runbook) je runbook pro vytvoření backupu existujícího serveru v cloudu. Naposledy zmíněný runbook díky jeho poměrné jednoduchosti uvádím na obr. 5.5. Mezi základními uzly (sadami procesů) daného runbooku nalezneme uzly speciální, které začínají písmeny „EXT“. Jedná se o tzv. Extension points (rozšiřující body), na které můžeme zavěšovat naše vlastní definice procesů (včetně kompletních sad procesních workflow). Jako příklad uvedu extension point s názvem EXTCSUCC, což je rozšiřující bod (u většiny runbooků), který je umístěn jako úplně poslední uzel, a je volán v případě úspěšného ukončení všech předchozích kroků. Obecně lze říci, že u předpřipravených runbooků jsou extension pointy umístěny téměř před a po každém důležitém kroku, tedy příslušná workflow 1

Samotné názvy procesů včetně zde zmíněných runbooků, které lze identifikovat pomocí klíčových písmen RU, jsou odvozeny od základu PMRDP (Process Management Resource Driven Provisioning).

5.6. IBM SERVICE DELIVERY MANAGER

43

Obrázek 5.5: Runbook PMRDPRUSMI (Save Image Runbook)

a výsledné chování lze poměrně dobře customizovat dle potřeb. V rámci runbooku dochází např. k volání a vykonávání schvalovacího workflow, nebo také k volání speciálních workflow (ale teď již na jiné procesní úrovní – konkrétně se jedná a wokflow definovaná na úrovní TPM serveru), která popisují příslušné kroky pro účely provisioningu serverů, modifikaci přidělených zdrojů, instalace softwaru k již existujícím virtuálním strojům apod. V této úrovni sehrávají důležitou roli především definované logické operace LDO (Logical Device Operations) a jejich implementace – tato problematika bude více objasněna v následující kapitole 6.2. Tivoli Provisioning Manager dle příchozího servisního požadavku a spuštěného servisního plánu provádí samotnou alokaci zdrojů. Například pro přidání serveru do existujícího projektu nad virtualizací VMware ESX/ESXi dochází ke vzdálenému volání vCentra, které zajistí kopírování správné template. Dále následuje vzdálená konfigurace vytvořené instance pomocí volání TPM workflow (nastavení IP adres, přihlašovacích oprávnění, inicializace OS, instalace softwaru atd.). Na závěr je odpovídajícím způsobem upraven datový model TPM serveru, který se nazývá DCM (Data Center Model) – jsou vytvářeny nové DCM objekty, navazovány nové relace mezi nimi a upravovány některé vlastnosti a proměnné. V závěru většiny runbooků jsou volána workflow zajišťující notifikaci žadatele servisního požadavku o úspěšném či neúspěšném provedení příslušných kroků (např. zasláním emailu s přihlašovacími informacemi), nebo jsou volány Java třídy, které zajišťují integraci s komponentou Tivoli Usage and Accounting Manager (TUAM) pro účely měření služeb a generování finančních reportů apod. Koncový uživatel cloudu má možnost v rámci samoobslužného portálu sledovat základní stavy svého požadavku, viz obr. 5.6.

44


Obrázek 5.6: TSAM samoobslužný portál

Obrázek 5.7: Specifikace přidělených zdrojů novému serveru v rámci TSAM samoobslužném portálu

Kapitola 6

TPM implementační schéma V této kapitole se zaměřím na charakteristiku aplikace Tivoli Provisioning Manager, a to především na způsob, jakým lze vytvářet nový obsah a funkcionality do cloudového řešení ISDM.

6.1

Tivoli Provisioning Manager

Tivoli Provisioning Manager (TPM) je IBM řešení pro automatizaci manuálních procesů a správu různorodých zdrojů v rámci řízené infrastruktury, a to operačních systémů, aplikací, patchů, ale také fyzického hardwaru, diskových polí, síťových jednotek, včetně virtuálních prostředí či řízení hypervisorů. V rámci řídící vrstvy ISDM cloudu zodpovídá především za samotné provedení požadovaných servisních úkonů a změn, discovery (vyhledávání zdrojů – například předpřipravených template pro provisioning serverů) a úpravu a aktualizaci datového modelu spravovaného i řídícího prostředí.

6.2

Logická zařízení a jejich operace

Tivoli Provisioning Manager využívá několika základních vrstev k popisu a správě různorodých zdrojů. Na nejvyšší úrovni jsou definována logická zařízení (Logical Devices), což jsou v podstatě abstrakce objektů reálného světa. Mezi logická zařízení řadíme servery, switche, clustery, instalovatelné softwarové moduly, soubory či souborová úložiště atd. Ke každému logickému zařízení jsou definovány příslušné logické operace LDO (Logical Device Operations), které se skládají z popisného jména zařízení a jména příslušné operace, tedy např. Device.PowerOn, SoftwareInstallable.Install, SoftwareInstance.Start nebo HostPlatform.CreateVirtualServer. Na obr. 6.1 vidíme například model zařízení – operační systém RedHat Linux, které je uloženo na úrovni TPM serveru jako odpovídající záznam se všemi jeho parametry (jméno, popis, verze, hardwarové požadavky apod.). Z pohledu nižší úrovně správy a manipulace s daným objektem se jedná o logický objekt OperatingSystem, kterému odpovídají příslušné logické operace jako např. OperatingSystem.AddNetworkInterface. Pro

45

46

KAPITOLA 6. TPM IMPLEMENTAČNÍ SCHÉMA

Obrázek 6.1: Základní komponenty provisioning workflow

tuto logickou operaci existuje její implementace v podobě provisioning workflow se jménem RedHat_Add_Network_Interface, jenž je součástí předpřipraveného balíku (Automation package) s názvem redhat-linux-operating-system. Na úrovni fyzického hardware následně existuje instalace operačního systému RadHat Linux, kterou reprezentuje model zařízení v TPM serveru – tedy nějaký DCM objekt, a která je ovládána a spravována příslušnými workflow. Z pohledu tvorby nového obsahu a customizace nemáme možnost změnit stávající či vytvořit novou definici logického zařízení či jeho logické operace i přesto, že jejich popis je vytvořen pomocí standardního jazyka workflow (Workflow language), viz následující kapitola 6.4.1. Máme pouze možnost založit nové workflow, které implementuje příslušnou logickou operaci, a tím ovlivnit samotný způsob provedení. Každá logická operace má definované rozhraní, které zároveň musí převzít workflow, jenž ji implementuje, a to včetně pořadí a jmen vstupních/výstupních parametrů.

6.3. OVLADAČ ZAŘÍZENÍ

47

Na následujícím příkladu je vidět hlavička workflow, která je definována logickou operací SoftwareInstallable.InstallPost: workflow MyApplication_PostInstall(in SoftwareID, in DeviceID, in SoftwareResourceTemplateID, inout SoftwareResourceID) implements SoftwareInstallable.InstallPost LocaleInsensitive .

6.2.1

Vazba logické operace a workflow

LDO nám vytváří abstraktní vrstvu, tedy při vyvolání jakékoliv operace (instalace softwaru, vytvoření virtuálního serveru apod.) nemusíme přemýšlet o technických detailech implementace a různě pojmenovaných workflow, která příslušné operace vykonávají. I přesto je však nutné, aby se TPM server dozvěděl, kterou implementaci logické operace má zvolit. Každá logická operace je volána proti nějakému DCM objektu, což je záznam v datovém modelu TPM serveru. Pokud u daného objektu existuje vazba na workflow s požadovaným rozhraním, bude při volání logické operace toto workflow použito. Samotný proces, kdy dochází k vyhledávání vhodného workflow, je v kódu LDO reprezentován klíčovým termínem invokeimplementation. U některých DCM objektů také existuje defaultní implementace LDO, která je použita, pokud k objektu není přidělena explicitní implementace. Tyto workflow většinou začínají klíčovým slovem „Default“ a jsou uloženy v balíku default-device-model.tcdriver.

6.3

Ovladač zařízení

Ze základních vlastností a vztahů mezi logickými operacemi a samotnou implementací popsanou výše jasně plyne, že k jednotlivým DCM objektům (případně skupinám objektů dle typu logického zařízení) v podstatě přiřazujeme jakési ovladače (device drivers), které jsou s daným objektem schopny manipulovat. Obecně lze říci, že za ovladač lze považovat již jediné workflow, které implementuje logickou operaci, a které je explicitně a samostatně přiděleno k DCM objektu, ale dle doporučení by se tento postup neměl používat. Vhodným řešením je použití zkompilovaného balíku s koncovkou .tcdriver (vytvoříme device driver), který nabízí možnost zabalení libovolného množství workflow ovládajících příslušné zařízení (objekt) do jediného uceleného souboru.

6.3.1

Automation package

Automation package je označení pro ovladač zařízení (device driver) používané ve vývojovém prostředí APDE (Automation Package Developer Environment), viz popis instalace v příloze D. Toto vývojové prostředí, dostupné jako plug-in do Eclipse [25], slouží k vývoji a testování workflow pomocí speciálního jazyka (Workflow language) a jejich kompletaci do jednotlivých balíků (výše zmíněných automation packages), viz obr. 6.2.

48


Obrázek 6.2: Základní struktura jednoduchého automation package

Z níže popsané struktury jednoduchého balíku jsou částečně patrné i možnosti jeho použití. Základními částmi jsou [66]: • bin Tato složka může obsahovat libovolné skripty, které jsou spouštěny na samotném řídícím serveru, tzv. deployment engine device. Skripty se nekopírují na ovládané zařízení. • doc Tato složka obsahuje dokumentaci, která byla vygenerována pomocí nástroje workflowdoc. • src Tato složka může obsahovat zdrojové třídy jazyka Java, pokud je v rámci balíčku zároveň vyvíjen nějaký Java plug-in. • doc-src Tato složka obsahuje jakoukoliv dodatečnou dokumentaci v HTML formátu, která je částečně automaticky předpřipravena při založení nového balíčku. • META-INF Tato složka obsahuje standardní konfigurační soubor OSGi balíku – MANIFEST.MF. • repository Tato složka obsahuje skripty, které jsou kopírovány a zároveň spouštěny na cílových zařízeních. • TC-INF Tato složka obsahuje manifest soubor pro celý automation package – tento soubor je vždy nazýván jako tc-driver.xml.

6.4. TPM WORKFLOW

49

• workflow Tato složka obsahuje soubory příslušných provisioning workflow (*.wkf), které byly vyvinuty za účelem ovládat definované zařízení, pro které je daný automation package (device drive) určen. • xml Tato složka obsahuje xml soubor, kterým lze při samotném nasazení zkompilovaného ovladače ovlivnit a pozměnit informace v datovém modelu DCM (Data Center Model). • build.xml Tento soubor v sobě nese ANTový skript, který je použit při kompletaci všech částí do jediného .tcdriver souboru, jenž reprezentuje výsledný ovladač. Obecně lze říci, že automation package je poměrně dosti komplexní struktura, která v sobě kombinuje vlastnosti standardního OSGi balíku, jako známe u projektů jazyka Java, ale navíc obsahuje specifické prvky v podobě možností rozšíření různými plug-iny, vlastními skripty – ať již pro řídící vrstvu cloudu, tak i pro spravované prostředí, ale především speciálními workflow.

6.4

TPM Workflow

Nejnižší úroveň, na které definujeme nový obsah a logické provádění operací, volání samostatných skriptů apod. jsou tzv. TPM workflow. TPM workflow vytváříme jako samostatné funkční jednotky v rámci automation package, které mohou mít pomocí jasně daného rozhraní (díky implementaci existující logické operace) již předdefinovanou funkcionalitu – např. slouží ke spuštění, či vypnutí nějaké služby atd., nebo se jedná o obecná workflow, jež slouží jako logické členění v rámci vývoje složitějších úloh. TPM workflow se vytváří pomocí speciálního jazyka Workflow Language a jsou samostatně ukládána do ASCII souborů s koncovkou .wkf.

6.4.1

Workflow Language

TPM Workflow Language je standardizovaný jazyk, který je v TPM serveru vyhodnocován a prováděn v modulu nazývaném Deployment Engine, což je v podstatě běhové prostředí, jehož součástí je zároveň interpretr jazyka Jython. Cílem následující sekce je zaměřit se na tento speciální jazyk a vybrat a popsat několik základních příkladů, kterými se od běžně používaných jazyků odlišuje. Základní použitá syntaxe a typové struktury byly převzaty a zkombinovány z jazyků Basic, Perl, Java a C. Kompletní popis a vlastnosti Workflow Language lze nalézt v Tivoli Provisioning Manager 5.1 – Advanced Development Guide [17], nebo v Tivoli Provisioning Manager 7.2 – Provisioning workflows and automation packages [66]. 6.4.1.1

Definice workflow

Obecně lze říci, že tento speciální jazyk je procedurálně orientován, tedy každé workflow lze chápat jako samostatnou proceduru, která má parametry vstupní (definované klíčovým slovem in), výstupní (out), ale i vstupně-výstupní (inout). Jako vstupní a výstupní entitou

50


může také být pole označené pomocí slova array, nebo lze použít klíčové slovo encrypted, jenž nám zajistí, že skutečné hodnoty předávaných parametrů nelze přečíst ve výsledných výpisech (jsou šifrovány). Jak můžeme vidět na následujícím příkladu syntaxe hlavičky, každé workflow je uvozeno klíčovým slovem workflow: workflow <WkfName> (<parameters>) [implements ] LocaleInsensitive | CheckDeviceLocale, kde <WkfName> značí povinné jméno workflow, <parameters> nepovinné parametry, jméno logické operace a na závěr musí být uvedeno LocaleInsensitive nebo CheckDeviceLocale v závislosti na tom, zda je workflow na lokálním nastavení cílového zařízení nezávislé, či má být provedena jeho kontrola. Jednoduché tři příklady, včetně toho úplně nejjednoduššího (theSimplestWkf), lze vidět níže: workflow theSimplestWkf LocaleInsensitive, workflow sum (in array Numbers, out Result) LocaleInsensitive, workflow MyExecuteCommand (in DeviceId, in encrypted ExecuteCommand, in WorkingDirectory, in CredentialsKey, in TimeoutInSeconds, in TreatTimeoutAs, out ReturnCode, out ReturnErrorString, out ReturnResult) implements Device.ExecuteCommand LocaleInsensitive. 6.4.1.2

Výpisy a logování

Vývoj v jazyce Workflow Language vyžaduje aktivní připojení k TPM serveru, kde jsou příslušná workflow spouštěna v rámci běhového prostředí Deployment Engine. Z tohoto důvodu jazyk neobsahuje standardní metody pro výpis na konzoli či do souboru a všechny výstupy jsou zaznamenávány přímo do logů, které vznikají při spuštění samotného workflow. Podle použité úrovně tedy rozlišujeme čtyři možnosti výpisů, a to: log log log log 6.4.1.3

debug <debug message>, info , warning <warning message>, error <error message>. Jazyk Jython

Jak již bylo zmíněno výše, běhové prostředí Deployment Engine obsahuje interpret jazyka Jython [38], který pro účely TPM serveru slouží jako nástroj pro spouštění automatizovaných úloh. Obecně se ale jedná o samostatný skriptovací jazyk, který kombinuje prvky jazyka Python a Java, což je patrné i ze samotného symbolu tohoto jazyka, viz obr. 6.3. Jelikož jsou všechny jednoduché proměnné v rámci workflow typu String(1) , je Jython použit jako nástroj pro základní i pokročilé operace s řetězci – od obyčejného slučování(2) , volání funkcí(3) , ale i podmíněného vyhodnocování(4) , dále také jako způsob kterým lze

6.4. TPM WORKFLOW

51

provádět matematické operace(5) a převody na číselné typy. V neposlední řadě slouží jako podmiňující prvek(6) u příkazů if-else, případně while. Ne všechny funkcionality z tohoto jazyka však lze použit v TPM workflow, jako například celé Jython skripty či objektově orientované programy. Dovoleny jsou pouze jednořádkové příkazy a omezené množství vnitřních funkcí. Sekce jazyka Jython je ohraničena hranatými, případně kulatými závorkami a uvozena klíčovým slovem Jython. Na následujícím příkladu jsou ukázány vlastnosti jazyka, které byly zmíněny v předešlých odstavcích – rozlišujícím prvkem jsou zde výše použité indexy v kulatých závorkách. var flag var myArrayStr = "1,2,3,4" array myArray = Jython[myArrayStr.split(",")] var size = Jython[len(myArray)]

#(1) #(1) #(3) #(3)

if Jython[int(size) > 0] then flag = Jython[int(size) * 2] log info Jython["Array size is: " + size] endif

#(6) #(5) #(2)

log info Jython["Flag value is: " + (flag OR "null")]

#(4)

Obrázek 6.3: Symbol jazyka Jython kombinující prvky jazyka Java a Python

6.4.1.4

Práce s datovým modelem DCM

Elementární nutností při vytváření workflow a prací s jakýmkoliv zařízením (serverem, softwarovým instalovatelným balíkem, instancí aplikace atd.), je znalost datového modelu TPM serveru – Data Center Model. Pro práci s tímto modelem existují čtyři funkce, které reprezentují základní CRUD operace: • DCMInsert – zápis, • DCMQuery – čtení,

52


• DCMUpdate – modifikace, • DCMDelete – mazání. Samotný výběr a odkazování mezi jednotlivými entitami systému (DCM objekty) se provádí pomocí jazyka DCM, který svojí syntaxí silně připomíná jazyk XPath. Jedná se o lomítky oddělený zápis, který je samotným lomítkem současně uvozen. I přesto, že by vývojové prostředí APDE mělo přes kombinaci kláves [Ctrl]+[Space] nabízet nápovědu, co se týče struktury objektů a vztahů mezi nimi, a která by ulehčila orientaci a zápis dotazu v požadovaném tvaru, není tomu tak. Tato funkcionalita se chová poměrně nestandardně a její spuštění uvedenou kombinací je velice obtížné, nemluvě o faktu, že samotná navigace tímto způsobem není moc uživatelsky přívětivá. Jak bylo zjištěno, definice objektů, jejich struktur a vztahů mezi nimi se nachází v souboru $TIO_HOME/xml/DcmObjectMappingsDocument.xml, s jehož pomocí lze vnitřní strukturu datového modelu lépe pochopit. Následující příklad ukazuje jednoduché použití tří CRUD operací, kdy je získán seznam vlastností (properties) vybraného serveru, následně je vytvořen nový záznam a nakonec je smazán. Jak můžeme vidět, jedná se o kombinaci dotazovacího jazyka DCM a xml struktur. array serverProperties = DCMQuery(/server[@name="ABC"]/property/@key) DCMInsert parent = DCMQuery(/server[@name="ABC"]) <<EOI <property component="USER_DEFINED" name="P1" value="my value" /> EOI DCMDelete(/server[@name="ABC"]/property[@key="P1"]) 6.4.1.5

Volání skriptů a Java tříd

Na závěr pouze krátce zmíním, že workflow language do sebe také umožňuje začleňovat celé skripty vytvořené v unixových shellech (bash a ksh) a jiných skriptovacích jazycích (Perl, Expect a Visual Basic), a to pomocí tzv. Scriptletů. Poměrně ojedinělou vlastností je možnost do takto vytvořených skriptů integrovat specifická volání z úrovně jazyka workflow, různá logování apod. Poměrně silným nástrojem je také volání tříd jazyka Java, např. vlastních plug-inů či již existujících knihoven v TPM serveru. Níže uvádím elementární příklady obou zmíněných funkcionalit. var result = Java[cz.package.MyJavaClass#sumNumbers(myArray)] scriptlet language=bash target=DCMQuery(/Server[@name="ABC"]) <<EOF if [ -f /tmp/file.log ]; then rm -f /tmp/file.log echo "Log file was deleted!" fi EOF

Část III

Implementační část

53

Kapitola 7

Automatické nasazení serverů Implementovaná řešení, která jsem vytvořil na základě provedené analýzy, zde uvádím rozdělena do čtyř základních oblastí. V rámci prvního tématu se budu zabývat možnostmi a způsobem automatizace tvorby a nasazení virtuálních serverů a jejich zavedením do reálné infrastruktury zákazníka. Cílem této kapitoly je především krátce popsat balíček IBM_Prague_Cloud_Core, o němž lze hovořit jako o malé knihovně, která svými nově implementovanými součástmi rozšiřuje základní sadu workflow určených pro cloudové prostředí, a nakonec rozebrat vytvořenou sadu workflow (v balíčku CST_Prague_Cloud_Core) přímo pro specifické prostředí zákazníka. Pro účely této práce a z důvodu dodržení standardních konvencí (především pojmenování workflow) budu uvažovat imaginárního zákazníka CST Prague 1 .

7.1

IBM_Prague_Cloud_Core

Jak jsem zmínil v předešlých odstavcích balíček IBM_Prague_Cloud_Core slouží jako malá knihovna, která svými workflow rozšiřuje základní vrstvu TPM serveru, především balík Cloud, o nové postupy a funkcionality, ale také se snaží některá konkretní workflow úplně nahradit. V tab. 7.1 vidíme výčet workflow ve zmiňovaném balíčku, která jsou rozdělena do čtyř sekcí dle jejich konkrétního použití.

7.1.1

Souborová úložiště

Workflow s prefixy IBM_Prague_NFS a IBM_Prague_SMB byly vytvořeny pro správu souborových úložišť – konkrétně se jedná o NFS a Samba. Obě tato úložiště jsou standardní součástí NFS image (viz popis architektury softwarových komponent, kapitola 5.6.1), kde jsou dle doporučení ukládány např. instalační soubory aplikací určených pro provisioning apod. 1

Uvažujme „CST“ jako zkratku pro klíčové slovo „customer“.

55

56

KAPITOLA 7. AUTOMATICKÉ NASAZENÍ SERVERŮ

Tabulka 7.1: Automation package IBM_Prague_Cloud_Core IBM_Prague_Cloud_Core IBM_Prague_Device_Get_Decrypted_Password.wkf IBM_Prague_Device_Reboot_Sync.wkf IBM_Prague_NFS_Repository_Mount.wkf IBM_Prague_NFS_Repository_Unmount.wkf IBM_Prague_SAP_RXA_Credentials_Add.wkf IBM_Prague_SAP_RXA_Credentials_Remove.wkf IBM_Prague_SMB_Repository_Create_MountCMD.wkf IBM_Prague_SMB_Repository_Create_MountCMDv2.wkf IBM_Prague_SMB_Repository_Create_UnmountCMD.wkf IBM_Prague_SMB_Repository_Get_Username_Password.wkf IBM_Prague_SMB_Repository_Mount.wkf IBM_Prague_SMB_Repository_Mounted_Drives.wkf IBM_Prague_SMB_Repository_Unmount.wkf

Vytvořená workflow zajišťují management připojení/odpojení, dále také tvorbu jednotlivých příkazů pro tyto funkcionality, či zjišťují a dešifrují uživatelská jména a hesla. Důležitou vlastností je zjednodušení většiny rozhraní, kde jsou jako vstupní parametry užity např. DCM ID jednotlivých balíků s implementovanou logickou operací SoftwareInstallable.Install, což zjednodušuje jejich nasazení na požadovaných místech. Na první pohled jednoduché operace zde ale vyžadují poměrně hlubokou znalost DCM modelu, neboť je potřeba přes vnitřní vztahy vyčítat požadované informace, které spolu na první pohled nesouvisí. Důležité je také použití speciálních Java tříd pro šifrování a dešifrování hesel apod. TPM workflow nepodporují přetěžování metod (workflow), jako tomu je u běžných programovacích jazyků (Java, C++ atd.), tedy pokud máji existovat dvě workflow se shodnou funkcionalitou, ale rozdílnými vstupními parametry, je potřeba je rozlišit jejich názvem, viz workflow pro vytvoření příkazu mount.

7.1.2

Koncová zařízení

Z důvodu nutnosti spouštění některých skriptů a služeb na koncových zařízení s explicitními právy privilegovaného uživatele, bylo vytvořeno workflow pro dešifrování příslušných hesel, které požadovanou sadu kroků sdružuje. Dále bylo reimplementováno workflow pro restart koncových serverů, neboť bylo zjištěno, že při volání logické operace Device.Reboot je spouštěno wokflow, které tuto funkcionalitu provádí s použitím API VMware Virtual Centera (vCenter), což v některých případech způsobovalo nepředvídatelné chování serverů v doméně a aplikovaní příslušných skupinových politik (Group Policies). Také docházelo k mizení přidaných datových disků apod. Centrální smyčku zajišťující synchronní čekání na restartovaný server, je možné vidět na následující ukázce:

7.2. CST_PRAGUE_CLOUD_CORE

57

var status = "offline" var counter = "0" while Jython[status == "offline" and int(counter) <= 20] do try counter = Jython[int(counter) + 1] java:java.lang.Thread#sleep(30000) scriptlet(status) language=bash target=DCMQuery(/Server[@id=$DeviceID]) <<EOF TIOsetVar status "‘hostname‘" EOF log info "Status: " + status + " is responding." catchall endtry done

7.1.3

Implementace přístupového bodu RXA

Z důvodu nalezených problémů s požadavkem spustit instalaci softwaru pod administrátorským účtem byla jako jedna z možností implementována sada dvou workflow, která zajišťují přidání a odebrání IBM proprietárního protokolu Remote eXecution and Access (RXA). Více se touto problematikou zabývá kapitola 8.1.

7.2

CST_Prague_Cloud_Core

Tento balíček sdružuje kompletní sadu workflow (viz tab. 7.1) určených pro provisioning serverů do prostředí koncového zákazníka a zároveň zajišťuje zavedení serverů s Windows OS do domény, včetně potřebných konfigurací uživatelů apod. Při implementaci byly použity příslušné postupy zmíněné v analýze IBM cloudového prostředí ISDM, především části týkající se TPM serveru (viz kapitola 6). Jedná se o využití vlastností logických operací a jejich automatického spouštění pomocí modulu Deployment Engine – pokud existuje vazba mezi cílovým zařízením a workflow implementujícím potřebné rozhraní, a úpravy odpovídajících runbooků a jejich rozšiřujících bodů (extesion points). U workflow, která využívají nativních vlastností TPM serveru, je implementovaná LDO součástí jejich názvu, viz workflow s prefixem CST_VMware, která byla přidělena k příslušným template OS určených pro provisioning. Ze zbylých workflow některá reprezentují často používané funkcionality, ale také slouží jako uzly pro procesní rozšíření využívajících extension pointů v rámci jednotlivých runbooků. V této souvislosti se předmětem úprav staly především runbooky pro vytvoření a odstranění VMware serverů – PMRDPRUADD a PMRDPRURMS, dále také runbooky pro vytvoření a odstranění projektů – PMRDPRUCRT a PMRDPRUCAN. V rámci tohoto přehledu je uveden pouze seznam workflow, na jejichž vývoji jsem se osobně podílel. Součástí nejsou skripty, které jsou majetkem cílového zákazníka, případně je vlastnictví konkretních částí uvedeno v kódu (kdo se na vývoji příslušné části TPM workflow podílel).

58


Tabulka 7.2: Automation package CST_Prague_Cloud_Core CST_Prague_Cloud_Core CST_ServerCredentials.wkf CST_ServerLayout.wkf CST_ServerPostProvisioning.wkf CST_ServerPreRemove.wkf CST_VMware_CloudSoftwareInstallable_PostInstall.wkf CST_VMware_Windows_CloudSoftwareInstallable_PostInstall.wkf CST_Windows_JoinDomain.wkf CST_Windows_RemoveFromDomain.wkf CST_Windows_UserPrivilegedAccount.wkf

Zmíněná workflow řeší především přidání a odebrání windows serverů do domény, správu uživatelů – např. speciální uživatelský účet žadatele je přidán do lokální skupiny Administrators u vyprosionovaného serveru, pojmenování datových disků, úpravy registrů, spouštění speciálních skriptů pro zavedení a nakonfigurování serveru dle požadovaných standardů apod. U většiny nestandardních požadavků bylo nutné provést změny jak v grafickém rozhraní uživatelského portálu, tak v několika případech i v databázovém modelu, což vyžadovalo koordinovanou spolupráci všech členů týmu, kteří se na tomto projektu podíleli. Až poté mohly být všechny potřebné informace zpracovány a využity v TPM workflow.

7.3

IBM_Prague_Schtasks

V průběhu práce bylo řešeno několik zásadních problémů, kde jeden z těch hlavních byla nutnost spouštění skriptů a instalačních souborů v rámci explicitního kontextu požadovaného uživatele na platformě Windows. Jelikož tento požadavek nelze v cloudovém prostředí, ve kterém se pohybujeme, řešit podobně, jako mezi samostatně nasazeným TPM serverem a jeho spravovanými koncovými body (díky chybějícímu TCA agentovi na straně řízené stanice), bylo nutné nalézt způsob vhodný pro toto prostředí. Jednou z implementovaných variant je sada workflow (viz tab. 7.3), která na koncovém serveru zajišťuje management operací windows utility schtasks zajišťující správu naplánovaných úloh (scheduled tasks). Důvodem pro volbu této utility byl především fakt, že pro spuštění vybrané úlohy lze explicitně uvést uživatelské jméno a příslušné heslo. Implementaci řídící vrstvy TPM workflow předcházela analýza potřebných parametrů a možností použití samotného nástroje schtasks. Tato sada workflow na základě vstupních parametrů vytvoří na spravovaném serveru příslušnou naplánovanou úlohu (scheduled task), jejíž opakování nastaví na jeden měsíc. Předmětem zahájení úlohy je nově vytvořený skript, do kterého je vložen vstupní příkaz. V dalším kroku je provedeno explicitní spuštění naplánované úlohy, jejíž standardní i chybový výstup je přesměrováván do pomocných souborů, které jsou na závěr načítány jako návratová hodnota úlohy. Důležité je zde poznamenat, že spuštěná úloha běží v kontextu požadovaného uživatele. Celý proces je synchronní, tedy pomocí speciální čekací smyčky je

7.3. IBM_PRAGUE_SCHTASKS

59

Tabulka 7.3: Automation package IBM_Prague_Schtasks IBM_Prague_Schtasks IBM_Prague_Schtasks_Create.wkf IBM_Prague_Schtasks_DeleteTask.wkf IBM_Prague_Schtasks_RunCommand_Sync.wkf IBM_Prague_Schtasks_Wait.wkf

ověřován stav dokončení spuštěné úlohy, případně je ověřováno překročení vyhrazeného časového limitu, který je jedním ze vstupních parametrů. Na závěr je vytvořená naplánovaná úloha z koncového systému odstraněna.

Popis vstupního rozhraní Vstupní rozhraní zde reprezentuje workflow IBM_Prague_Schtasks_RunCommand_Sync, jehož parametry jsou: jméno úlohy, ID zařízení, požadovaný příkaz, uživatelský kontext s příslušným heslem, časový limit (timeout) a návratová hodnota příkazu. Zmíněnou hlavičku příslušného workflow můžeme vidět níže: workflow IBM_Prague_Schtasks_RunCommand_Sync(in TaskName, in DeviceID, in Command, in Username, in encrypted Password, in TimeOut, out ReturnResult) LocaleInsensitive

Příklady použití V následující ukázce uvádím tři příklady spuštění, a to klasického batch souboru (.bat) v rámci kontextu doménového uživatele, skriptu v jazyce Visual Basic (VBScript) a nakonec samostatného příkazu hostname. IBM_Prague_Schtasks_RunCommand_Sync("MyBatchTask", 12345, "D:\inst\script.bat", "domain\User1", "password", "300") IBM_Prague_Schtasks_RunCommand_Sync("MyVBScriptTask", 12345, "cscript C:\temp\script.vbs", "Admin", "password", "200") IBM_Prague_Schtasks_RunCommand_Sync("MySimpleTask", 12345, "hostname", "user", "password", "100")

60


Kapitola 8

Automatické nasazení aplikací Před samotným popisem vlastního provedení automatického nasazení aplikací v rámci cloudového prostředí ISDM, které zde budu demonstrovat na provisioningu databáze Microsoft SQL Server 2005, rád bych se v krátkosti zmínil o nalezeném problému integrace ISDM cloudu a Windows OS serverů.

8.1

Uživatelský kontext

Jak již bylo řečeno, ISDM cloud využívá funkcionalit TPM serveru pro vlastní správu a řízení virtualizačních platforem, stejně tak jako operačních systémů, aplikací a jednotlivých entit řídící i řízené infrastruktury. Zásadní odlišnost od samostatného nasazení TPM serveru je ale především to, že zde chybí Tivoli Common Agent (TCA) na straně ovládaného stroje, kterým jsou jednotlivé požadavky od TPM serveru prováděny. Pro ovládání linuxových serverů je zde použita kombinace RSA klíčů pro ověření přístupu a SSH a SCP protokoly pro příslušné operace. Podobně je tomu také pro operační systém Windows, kde je nutné v této souvislosti využít nainstalovaného prostředí Cygwin. Jak bylo ale zjištěno u OS Windows Server 2008 64-bit, jenž byl použit jako jedna z platforem pro provisioning, instalované prostředí Cygwin si stále nedokáže odpovídajícím způsobem poradit se 64-bit architekturou, což mělo za následek problém nekorektního svázání uživatelských účtů v prostředí Cygwin s uživatelskými účty v OS Windows. Pozorovány byly i nedostatky s nastavením proměnných prostředí (environment variables) při vzdáleném volání přes SSH protokol apod. Díky tomu nebylo možné provést (pouze v omezené míře) požadované instalace aplikací, přístupy do registrů atd. Analýzou problému byly vydefinovány tři možné způsoby řešení. • Reinstalace a odstranění chyb v prostředí Cygwin. Jelikož se však jednalo o známou chybu, byl tento přístup zamítnut. Daný problém může být odstraněn použitím budoucích novějších verzí apod. • Využití aplikací a utilit, které jsou schopny požadovaný kontext uživatele explicitně nastavit. V rámci této možnosti byly uvažovány např. runas, psexec,

61

62

KAPITOLA 8. AUTOMATICKÉ NASAZENÍ APLIKACÍ

schtasks apod. U utility runas nelze jednoduše vložit heslo uživatele (vyžaduje použití předuložených oprávnění), díky čemuž byla tato možnost zamítnuta. Testovací a zároveň úspěšné implementace byly provedeny pro psexec, ale použití tohoto nástroje od Sysinternals je v některých produkčních prostředí zakázáno. Realizace spouštění skriptů a aplikací s použitím naplánovaných úloh (pomocí schtasks) byla již diskutována v předešlé kapitole 7.3. • Použití IBM proprietárního protokolu RXA, který byl vytvořen pro vzdálenou správu Windows serverů v prostředí TPM. Remote eXecution and Access protokol je implementací protokolu NetBIOS přes TCP/IP využívající port TCP 139. U existujících workflow pro management provisioningu serverů, přidávání dodatečných datových disků apod., existuje poměrně silná vazba na SSH protokol, tedy nebylo možné provést úplné nahrazení tohoto protokolu protokolem RXA a tím pádem bylo nutné vytvořit workflow pro dočasné přidání požadovaného Service Access Pointu (SAP), viz workflow v balíčku IBM_Prague_Cloud_Core, tab. 7.1. Tento SAP byl ve výsledku použit pouze k samotnému spuštění instalačních procedur, či různých skriptů, u nichž byl vyžadován korektní kontext uživatele. Nasazení tohoto protokolu bylo řešením většiny problémů, ale jak bylo zjištěno, existují jistá omezení v podobě použití některých objektů v rámci skriptů jazyka Visual Basic, která byla vyřešena pomocí zmíněné implementace workflow pro management utility schtasks, viz popis balíčku BM_Prague_Schtasks, kapitola 7.3.

8.2

Automatické nasazení Microsoft SQL Serveru 2005

Výčtem implementovaných workflow v předešlých kapitolách jsem si připravil odpovídající nástroje pro popis nasazení Microsoft SQL Serveru 2005 na Windows Server 2008 64-bit v prostředí ISDM cloudu. Samotný koncept nasazení aplikací vychází z vlastností TPM serveru a distribuce softwaru, kdy rozlišujícím prvkem je zde především rozdílný komunikační protokol a pak prvky specifické pro prostředí cloudu, jako například definování proměnné pro účely označení vytvořeného balíku jako zdroje pro provisioning ze samoobslužného portálu.

8.2.1

Obecné řešení

Základní kroky, které je nutné provést, jsou: • vytvoření softwarové definice v aplikaci Software Products a nastavení požadavků (Requirements), • vytvoření konfigurační šablony (Configuration template) a nadefinování vstupních parametrů, • uspořádání instalačního procesu aplikace nejlépe pomocí silent instalace, bez nutnosti interakce v rámci grafického rozhraní,

8.2. AUTOMATICKÉ NASAZENÍ MICROSOFT SQL SERVERU 2005

63

• umístění instalačních souborů ideálně do jednoho z předpřipravených souborových úložišť v rámci NFS image, • vytvoření definice „instalovatelného software“ (Software Installable), která obsahuje vazbu na souborové úložiště a přesné umístění instalačních souborů, a přiřazení k softwarové definici v aplikaci Software Products, • pomocí vývojového nástroje Automation Package Developer Environment (APDE) je nutné vytvořit nový ovladač (automation package) s workflow, které musí implementovat logickou operaci SoftwareInstallable.Install, a u vytvořené definice „instalovatelného software“ (viz předešlý krok) nadefinovat vztah na tento driver, • v rámci vývoje workflow v nejjednodušším případě dochází pouze ke spouštění předpřipravených instalačních procedur a kontrole úspěšnosti všech operací, • na závěr je nutné u softwarové definice vytvořit proměnou exposetotivsam a její hodnotu nastavit na „1“, což nám vystaví instalovatelnou aplikaci do samoobslužného portálu. U tohoto závěrečného kroku zároveň dochází k explicitnímu přiřazování softwaru k vybraným template virtuálních strojů, jednotlivým zákazníkům (na úrovni definic TSAM serveru) apod.

8.2.2

Příprava instalačních skriptů

Základní sada instalačních skriptů byla poskytnuta samotným zákazníkem, díky čemuž se vývoj potřebných částí o trochu zjednodušil. Získané instalační skripty však bylo nutné obohatit o prvky týkající se úprav registrů – např. z důvodu oficiální nekompatibility databáze Microsoft SQL Server 2005 na Windows Server 2008 64-bit1 je nutné nastavit potřebný flag v registrech apod. Z důvodů požadavku na možnost částečné parametrizace instalace – jména instance, způsobu autentikace, místa instalace a způsobu porovnávání (collation), byl roztržen příslušný konfigurační ini soubor, který je těsně přes spuštěním instalačního procesu obohacen o příchozí parametry a opětovně složen. Sada skriptů byla ve výsledku rozdělena na dvě základní části, mezi nimiž bylo nutné provést restart celého systému, což je z důvodu nutnosti udržení relace připojení ke koncovému serveru nutné řídit pomocí TPM workflow.

8.2.3

Implementace TPM workflow

Pro účely provisioningu databáze MS SQL Server 2005 na Windows Server 2008 64-bit byl vytvořen automation package s příslušným workflow, které implementuje zmíněnou LDO SoftwareInstallable.Install, viz tab. 8.1 V rámci uvedeného driveru jsou využívána workflow vytvořená v rámci výše popsaného balíku IBM_Prague_Cloud_Core, a to konkrétně pro připojení a odpojením souborového úložiště s instalačními soubory a skripty, synchronní restart operačního systému, přidání 1

Z důvodu nekompatibility standardní verze MS SQL Serveru 2005 na zmíněný operační systém je nutné na základní instalaci aplikovat potřebné fix packy, které případné problémy odstraňují.

64


Tabulka 8.1: Automation package CST_MSSQL2005_Windows_x64 CST_MSSQL2005_Windows_x64 CST_MSSQL2005_Windows_x64_Installable_Install.wkf

a odebrání servisního přístupového bodu (SAP) k samotnému serveru a také Java tříd pro šifrování a dešifrování hesel. V rámci jednotlivých kroků při běhu workflow dochází nejprve k ověření vstupních parametrů přicházejících do samotnému workflow. Dále jsou DCM dotazy načítány a zpracovávány vstupní hodnoty z konfigurační šablony (Configuration template), které pocházejí ze samoobslužného portálu. Probíhá dvojnásobný synchronní restart operačního systému – z důvodu potřeby aplikování skupinových politik v rámci domény. Dochází k přidání servisního přístupového bodu RXA a definice přístupových práv (Password Credentials). Vytvářejí se skripty pro připojení a odpojení souborového úložiště na základě definovaného „instalovatelného software“ (Software Installable). Pomocí defaultního SAP (protokolem SSH) dochází k vytvoření požadovaných struktur na koncovém serveru a nakonec pomocí dočasně přidaného SAP (protokolem RXA) dochází v rámci scriptletu ke spuštění skriptu, který zahájí připojení souborového úložiště, zkopírování souborů a spuštění první části instalačních procedur v kontextu uživatele s administrátorskými oprávněními. Po načtení logů a ověření průběhu instalace dochází na základě návratových hodnot instalace k restartu systému, upravení nezbytných parametrů a načtení nových hodnot z DCM modelu, spuštění druhé části instalačních kroků pomocí RXA, které doinstalují potřebné fix packy a nadefinují instanci MS SQL Serveru dle požadovaných standardů. Po opětovném načtení a ověření logů dochází k vyčistění serveru od přebytečných a pomocných souborů a k závěrečnému restartu celého serveru. Posledním krokem je odstranění RXA SAP a logování úspěšné instalace. Modifikovaný UML diagram aktivit, kde byly vynechány rozhodovací uzly a přímo z konstruktu aktivity vychází dvojice šipek podle úspěšnosti provedení daného uzlu (zelená pro úspěšné dokončení aktivity a červená pro neúspěšné dokončení), je na obr. 8.3. Tento diagram reprezentuje základní posloupnost procesů, která je vykonávána při běhu workflow CST_MSSQL2005_Windows_x64_Installable_Install.wkf.

8.2.4

Definice DCM modelu

Implementovaný driver byl vytvořen takovým způsobem, že je jednoduše přenosný. Pro integraci s jiným ISDM cloudovým prostředím je potřeba na definované místo standardního souborového úložiště v NFS image uložit instalační soubory (v řádu jednotek GB) a pomocí nástroje $TIO_HOME/tools/tc-driver-manager.sh naimportovat vytvořený driver do TPM serveru. Tímto postupem zároveň vzniknou nové entity v DCM datovém modelu, a to díky vytvořenému XML souboru, který obsahuje definice příslušných objektů. Část XML kódu, kde dochází ke svázání „instalovatelného software“ s workflow, které provádí cílovou instalaci, uvádím v následující ukázce:

8.2. AUTOMATICKÉ NASAZENÍ MICROSOFT SQL SERVERU 2005

65

<device-model name="CSTMSSQL2005Winx64_Installable" category="Software"> <workflow name="CST_MSSQL2005_Windows_x64_Installable_Install" />

8.2.5

Předávání parametrů ze samoobslužného portálu

Vytvořené workflow získává pro potřeby instalace softwaru několik druhů parametrů. Jedná se např. o jméno uživatele (jeho speciálního účtu) žádajícího o vytvoření služby ze samoobslužného portálu, které se načítá z parametrů DCM objektů vzniklých v průběhu samotné tvorby virtuálního stroje. Parametry jež může koncový uživatel sám ovlivnit lze editovat v průběhu žádosti o instalaci příslušného serveru (pokud však u softwarového produktu existují definice v Configuration template). Na základě vytvořené šablony skrze administrativní konzoli ISDM cloudu, či pomocí XML popisu příslušného objektu pak v samoobslužném portálu automaticky vznikají požadované vstupní boxy, jimiž lze poměrně jednoduše (voláním DCM dotazů proti datovému modelu) v samotných workflow použít zadané hodnoty. Pro porovnání uvádím na obr. 8.1 definici samotné šablony s defaultními parametry a výsledné zobrazení v grafickém rozhraní cloudu, viz obr. 8.2.

Obrázek 8.1: Configuration Template s defaultními parametry

Obrázek 8.2: Konfigurace parametrů instalace databáze Microsoft SQL Server 2005

66


Obrázek 8.3: Modifikovaný diagram aktivit znázorňující základní posloupnost procesů workflow CST_MSSQL2005_Windows_x64_Installable_Install.wkf

Kapitola 9

Implementace měření služeb Cílem této kapitoly je v krátkosti popsat návrh realizovaného konceptu specifického měření služeb, který spíše než cloudovému prostředí odpovídá tradičnímu modelu poskytování služeb většiny SP.

9.1

Definice pravidel měření služeb

Od metodiky měření služeb, jež je uplatňována ve většině cloudových prostředí – tedy tzv. utility model (platíme pouze za to, co opravdu spotřebujeme), se zde navrhovaný koncept liší především v pravidelných denních intervalech, ve kterých dochází k rozhodnutí, zda bude daná služba koncovému uživateli účtována či nikoliv. Zároveň je důležité v průběhu zmíněného denního intervalu identifikovat maximální použité zdroje, které budou podkladem pro další zpracování účetními systémy apod. Předmětem měření služeb je současně potřeba samostatně detekovat zálohování jednotlivých virtuálních strojů v podobě backupů zabírajících místo na diskových polích a také přítomnost dodatečného datového disku.

9.2

Možnosti ISDM cloudu

ISDM cloud pracuje po vzoru zmíněného utility modelu, tedy výše definovaných pravidel nelze docílit jednoduchou úpravou stávajícího řešení. Samostatné měření služeb zálohovaných virtuálních strojů navíc také není standardně podporováno. Z tohoto důvodu bylo nutné navrhnout nový systém měření služeb a realizovat požadované funkcionality s ohledem na zajištění integrity všech procesů. Provedená implementace sestává z kombinace využití extension points v rámci příslušných runbooků, TPM workflow jako nástroje pro shromáždění potřebných informací a práci s DCM datovým model a nakonec implementace Java plug-inu pro účely jednotného uzlu zajišťujícího přístup k exportovaným datům v CSV souborech.

9.3

Mapování procesů a subprocesů

Mapování jednotlivých procesů v rámci ISDM cloudu je zajišťováno pomocí vhodných runbooků a jejich závěrečných „úspěšných“ rozšiřujících bodů (extension points) zmíněných

67

68

KAPITOLA 9. IMPLEMENTACE MĚŘENÍ SLUŽEB

v tab. 9.1 níže. Tabulka 9.1: Mapování subprocesů a standardních runbooků Proces PMRDPRUADD PMRDPRUCAN PMRDPRUCRT PMRDPRUISW PMRDPRUMSR PMRDPRURMS PMRDPRUSMI

Popis Add Server Runbook Cancel Project Runbook Create Project Runbook Install Software Runbook Modify Server Runbook Remove Server Runbook Save Image Runbook

Extension point EXTCSUCC EXTCSUCC EXTCSUCC EXTSUCCESS EXTCSUCC EXTCSUCC EXTCSUCC

Subproces CSTMETNEW CSTMETSEL CSTMETNEW CSTMETSEL CSTMETSEL CSTMETSEL CSTMETSEL

Do těchto bodů byly přidány nově vytvořené definice dvou druhů jednoduchých procesů, viz ukázka na obr. 9.1. Hlavní úlohou těchto procesů je mapování vstupních parametrů (Input Parameter Mappings) do TPM workflow nejvyšší úrovně (CST_Metering.wkf). Mezi předávanými parametry je potřeba především zmínit typ operace – jako je např. přidání serveru, odstranění serveru apod., kterou zde reprezentuje použitá klasifikace (Classification) v rámci servisní definice.

Obrázek 9.1: Subproces zajišťující mapování vstupních parametrů do TPM workflow

9.4

Využití TPM workflow

Automation package CST_Servers_Metering, viz tab. 9.2, je základní sadou workflow, která tvoří samotné jádro realizovaného měření služeb. Vstupním uzlem do celé vnitřní logiky je workflow CST_Metering.wkf, jehož úlohou je úprava části příchozích parametrů a na základě typu operace spouštění odpovídajících workflow nižší úrovně. Jak bylo zjištěno, jednou z nezbytností při realizaci celého systému je požadavek na výlučný přístup ke stavu DCM modelu v době zaznamenávání každé operace. Pro tento účel byl tedy již na této úrovni realizován vhodný zamykací mechanismus, jehož základní část je možné vidět na následující ukázce. Předmětem zamykání je zde DCM objekt reprezentující server, na který se do CSV souborů ukládají naměřená data. Lock_DCM_Object(MeteringDeviceID, , ) try <> finally Unlock_DCM_Object(MeteringDeviceID, , ) endtry

9.4. VYUŽITÍ TPM WORKFLOW

69

Pro zjednodušení jednotlivých kroků a zachování přehlednosti bylo pro každou měřenou operaci implementováno jedno workflow. Názvy těchto workflow s prefixem CST_Metering_ vždy obsahují jméno odpovídající operace. Pro ukázku činností, které tato workflow realizují, si více rozebereme např. CST_Metering_AddServer.wkf reprezentující operaci přidání nového serveru do již existujícího projektu. Po obdržení části požadovaných informací o nově vytvářeném serveru ze vstupních parametrů je potřebná sada doplněna pomocí souboru volání DCM dotazů v rámci workflow CST_Metering_GetServerProperties.wkf. Druhým významným krokem je uložení těchto informací v odpovídajícím tvaru mezi vlastnosti nově vytvářeného stroje – konkrétně jako nové DCM objekty (typu Property) k objektu příslušného serveru, což je realizováno pomocí CST_Metering_SaveServerProperties.wkf. Následně se vytvoří textová definice serveru v CSV formátu a spolu s typem operace, jež je získána z volání statické metody Java třídy OperationType, jsou tyto informace předány nejnižší vrstvě této sady workflow, a to CST_Metering_Sync.wkf. CST_Metering_Sync.wkf slouží především jako jednotné místo pro volání Java třídy MeteringHelper a její metody meteringCSVFileHandler. Dále také na základě definice proměnných v cloudu a aktuálního datumu na serveru vytváří jméno CSV souboru, do kterého by měly být příchozí změny synchronizovány. Toto jméno včetně definice nového serveru (případně backupu) a výčtu všech aktuálních položek v cloudu předává jako parametry při volání zmíněné třídy, viz kapitola 9.5. Tabulka 9.2: Automation package CST_Servers_Metering CST_Servers_Metering CST_Metering.wkf CST_Metering_AddServer.wkf CST_Metering_BackupServer.wkf CST_Metering_CancelProject.wkf CST_Metering_CreateProject.wkf CST_Metering_getDate.wkf CST_Metering_GetServerProperties.wkf CST_Metering_InstallSoftware.wkf CST_Metering_ListAll.wkf CST_Metering_ModifyServer.wkf CST_Metering_RemoveServer.wkf CST_Metering_SaveBackupProperties.wkf CST_Metering_SaveServerProperties.wkf CST_Metering_Scheduled.wkf CST_Metering_Sync.wkf

V závěru této kapitoly se nachází UML diagram komponent zobrazující celkový náhled na realizované řešení, viz obr. 9.2. U některých workflow bylo především z důvodu ušetření místa a přehlednosti diagramu nahrazen prefix CST_Metering třemi tečkami.

70


9.5

CST_Server_Metering.jar

CST_Server_Metering.jar je samostatný Java plug-in, který byl vytvořen v rámci vývoje automation package CST_Server_Metering. Požadovaná integrace příslušných Java tříd a následně možné volání z TPM workflow vyžaduje úpravu ANTového skriptu a modifikaci souboru MANIFEST.MF. Hlavními částmi, které zajišťuji funkcionality celého plug-inu, jsou především již zmíněná výčtová třída OperationType.java, která udržuje sadu potřebných konstant a definuje jednotlivé logické operace. Dále je důležité zmínit třídu CSVFileLine.java, jež reprezentuje záznam v CSV souboru a zároveň slouží jako parser s kontrolním mechanismem korektnosti jednotlivých záznamů. Nejdůležitější komponentou celého balíku je však třída MeteringHelper.java, jejíž statická metoda meteringCSVFileHandler vytváří vstupní rozhraní do celého systému synchronizace naměřených dat do CSV souborů. Pro zajištění vstupu pouze jednoho aktivního vlákna do kritické sekce přístupu k obsahu CSV souborů je tato metoda typu synchronized. Na základě vstupní operace jsou zde, podobně jako je tomu u TPM workflow na vyšší vrstvě modelu, volány jednotlivé metody, jež následně konkrétní úlohu realizují. Např. pro operaci přidání nového serveru do existujícího projektu je tedy volána metoda addServer, kde dochází nejprve k načtení obsahu příslušného CSV souboru do paměti (pokud již existuje) a převedení dat do jednotlivých Java objektů – pro účely kontroly struktury a snadnější práce s jednotlivými záznamy a jejich případnou úpravou. Dále je provedeno začlenění nového záznamu do načtené množiny včetně kontroly duplicity dat atd. a všechny naměřené hodnoty jsou zpětně uloženy do CSV souboru. Samotná třída je z TPM workflow volána následujícím příkazem: Java[com.ibm.prague.cst.metering.MeteringHelper#meteringCSVFileHandler( operationType, serverDefinition, allServers, fileName)], jehož návratovou hodnotou je textový řetězec obsahující klíčové slovo SUCCESS, případně ERROR. Dle existence klíčového slova je následně rozhodnuto u úspěšnosti provedení celé operace.

9.6

CSV soubory

Výstupem z vytvořeného modulu měření služeb jsou samostatné CSV soubory, jenž jsou vytvářeny pro každý den běhu cloudového prostředí. V administrativním prostředí cloudu, konkrétně v aplikace Service Automation → Configuration → Cloud Properties, lze změnou nově vytvořené vnitřní proměnné Cloud.CST_METERING_REPOSITORY definovat adresář na TSAM serveru, do kterého jsou tyto soubory ukládány. Vnitřní struktura každého souboru se skládá z hlavičky popisující jednotlivé sloupce, která je vždy umístěna na první řádce. Na dalších řádkách se pak následně zaznamenává stav a změny jednotlivých serverů či záloh. Samotná struktura záznamu vznikla z požadavků na měřené entity, které lze rozdělit do tří logických skupin:

9.6. CSV SOUBORY

71

• Identifikace žadatele služby. Do této skupiny lze zařadit jméno zákazníka, týmu a projektu. • Identifikace služby. Sem patří samotné měřené hodnoty, tedy: jméno serveru (zálohy), OS, počet virtuálních CPU, velikosti RAM, systémového disku a dodatečných datových disků, nainstalovaný software a jméno původního serveru, které je vyplněno pouze v případě, že se jedná o záznam zálohy serveru. Dále také datum existence služby. • Pomocné informace, které slouží pro jednoznačnou identifikaci záznamu (hodnota ID příslušného DCM objektu) a identifikaci stavu (zda byla např. daná položka z cloudu již odstraněna apod.). Jelikož lze o celém systému měření služeb hovořit jako o událostmi řízené architektuře – Event-driven architecture (EDA), bylo nutné vytvořit naplánovanou úlohu realizovanou TPM workflow CST_Metering_Scheduled.wkf, které je spouštěno pravidelně každý den po půlnoci, a jehož úkolem je do nového CSV souboru zaznamenat aktuální stav všech měřených entit v rámci cloudu. Tímto postupem jsou odstraňovány stavy, které by nastaly v případě, že by daný den neproběhla operace vyžadující spuštění procesů měření, což by mělo za následek neexistenci příslušného CSV souboru. Příklad jednoduchého záznamu linuxového stroje a stroje s OS Windows s instalací databáze Microsoft SQL Server 2005 je možné vidět na následující ukázce: 2012/04/14,CUST1,TEAM1,ACCOUNT1,server001,Linux,1,2048,20,10,,,,21362 2012/04/14,CUST1,TEAM1,ACCOUNT1,server002,Windows,2,4096,30,20, MSSQL2005 Windows x64,,D,21820

72


Obrázek 9.2: Přehledová architektura základních komponent implementovaného modulu měření služeb

Kapitola 10

Prohlížeč Data Center Model (DCM) objektů Důvody požadavku na vznik této aplikace (DCM Object Browser) jsou zřejmé a přímo i nepřímo plynou z předchozího textu a zmíněných problémů. Jak jsem již uvedl dříve, struktura Data Center Model (DCM) objektů je jednou z vrstev, kde jsou uložena základní data pro provisioning samotných serverů, aplikací, jejich nastavení, vlastností a základních parametrů pro celý cloud. Konkrétně se jedná o datovou vrstvu řešení Tivoli Provisioning Manager (TPM). V rámci této kapitoly bych rád krátce popsat částečný návrh, ale především samotnou implementaci celého prohlížeče.

10.1

Motivace

Podnět pro vznik a inspirace prohlížeče pochází přímo z vývojového nástroj Automation Package Developer Environment (APDE), který je určen pro tvorbu workflow a jejich kompletaci do jednotlivých balíčků. Jedná se o plug-in do nástroje Eclipse [25], v rámci něhož se nachází pohled Data Center Model a Queries, které můžeme vidět na obr. 10.1 a obr. 10.2. Pohled Queries osobně považuji za jednu z nejužitečnějších a nejpoužívanějších součástí plug-inu, neboť slouží k testování a vyhodnocování DCM dotazů. Naopak pohled Data Center Model je nefunkční a bohužel nedodělaný, což jsem si ověřil pro verze TPM 7.1 i 7.2, kdy bylo v obou případech generováno nové vývojové prostředí, viz příloha D.

10.2

Specifikace cílů

Na základě vlastních zkušeností se strukturou DCM objektů získaných při tvorbě této práce a výše popsanou motivací jsem se rozhodl vytvořit: • vlastní lokální aplikaci, která bude sloužit k prohlížení DCM objektů. Důvodem volby samostatné lokální aplikace je především fakt, že zdrojové kódy prostředí APDE nejsou volně dostupné, aby bylo například možné doimplementovat má vlastní rozšíření přímo do samotného plug-inu.

73

74

KAPITOLA 10. PROHLÍŽEČ DATA CENTER MODEL (DCM) OBJEKTŮ

Obrázek 10.1: Pohled Data Center Model

Obrázek 10.2: Pohled Queries

• Implementace bude provedena v jazyce Java a prohlížeč by měl využívat standardní rozhraní, a to z důvodu zachování co možná nejširší kompatibility (ať již zpětné, tak i případně budoucí) s různými verzemi TPM serveru. • Hlavním cílem prohlížeče je navrhnout takové řešení, které bude umožňovat prohlížet a především zlehčovat navigaci a vztahy mezi DCM objekty, které jsou pro začínajícího programátora bohužel ukryty poměrně hluboko v konfiguraci TPM serveru a není možné je jednoduše vyčítat ani z datového modelu na úrovni databáze. • DCM Object Browser bude pracovat nad reálnými daty připojeného TPM serveru, což výrazně zjednoduší ovládání a přispěje k pochopení souvislostí mezi skutečnými daty a datovým modelem DCM objektů. • Pomocí prohlížeče bude možné spouštět a vyhodnocovat libovolný DCM dotaz, podobně jako to umožňuje pohled Queries v APDE plug-inu. • Zároveň bude prohlížeč automaticky generovat DCM dotaz při prohledávání dané větve DCM objektů.

10.3

Implementace

Na základě předešlé analýzy, která zde nebude dopodrobna rozebírána, se v této podkapitole zaměřím pouze na pár důležitých bodů implementace.

10.3.1

TPM SOAP API

Standardní Tivoli Provisioning Manager Server poskytuje několik webových služeb, díky čemuž je například možné provádět integraci do nástrojů třetích stran. Jelikož pro potřeby

10.3. IMPLEMENTACE

75

ISDM cloudu je používán TPM verze 7.2, byla implementace cílena především tímto směrem. TPM verze 7.2 (podobně jako předchozí verze) poskytuje několik specializovaných SOAP proxy – například pro správu zdrojů, pověření („credentials“) či událostí a pomocí Web Services Resource Frameworku (WSRF) lze zároveň jednoduše přistupovat k omezenému počtu „stateful“ webových služeb, které reprezentují jednotlivé (ale pouze vybrané) DCM objekty. WSDL dokument webové služby spravující například přístup k DCM objektu Server je vystavený na příslušném TPM serveru na adrese:

http://<server hostname>:8777/ws/pid/Server?wsdl.

Ukázalo se, že výše zmíněný přístup není pro implementaci DCM Object Browseru vhodný, neboť jak bylo zmíněno výše, ne každý DCM objekt má vlastní definici webové služby. Poskytovaná rozhraní dále nenabízí přístup ke všem atributům DCM objektů a zároveň neumožňují přistupovat k existujícím vztahům DCM objektů. V rámci testovací implementace bylo také nutné vytvořit mezivrstvu, která odstiňovala přístup ke specifickým metodám jednotlivých služeb. Pro účely výsledné implementace tedy byla nakonec zvolena proxy QLServiceProxy, která poskytuje rozhraní pro volání libovolného DCM dotazu. S použitím konfiguračního dokumentu (DcmObjectMappingsDocument.xml), který definuje strukturu DCM objektů daného serveru a nalezneme ho na cestě:

$TIO_HOME\xml\DcmObjectMappingsDocument.xml,

jsme tedy ve výsledku schopni odpovídajícími dotazy vyzískat potřebné informace o vztazích a struktuře DCM objektů a existujících datových záznamech. Příklad volání QLServiceProxy: QLServiceProxy proxy = new QLServiceProxy(:<port>, <username>, <password>); Map<String, String> paramMap = new TreeMap<String, String>(); String dcmQuery = "/server/@name"; String[] data = proxy.dcmSelect(dcmQuery, paramMap); Kompletní dokumentaci nalezneme v infocentru pro TPM 7.2 [64], případně pro TPM 7.1 [63], neboť QLServiceProxy je zároveň zpětně kompatibilní. Pro budoucí účely může být zajímavé i REST API TPM 8.1 [65], které by mohlo ulehčit práci se vzdáleným voláním, neboť struktura REST dotazu svou formou velice připomíná DCM dotaz. V současné době (březen 2012) je ale TPM 8.1 dostupný pouze jako BETA a zatím se neobjevil v žádné IBM cloudové implementaci.

76


Obrázek 10.3: Connection Settings DCM Object Browseru na operačním systému Mac

10.3.2

Připojení TPM serveru

Pro připojení TPM serveru skrze SOAP API je vyžadováno hostname nebo IP adresa, dále SOAP port, který je defaultně nastaven na 8777 a dále jméno uživatele s příslušnými oprávněními (maxadmin) a jeho heslem. Vzhled okna pro navázání připojení je možné vidět na obr. 10.3. Úspěšně navázaná spojení jsou automaticky ukládána do konfiguračních souborů, ze kterých jsou později znovu načítána a lze je jednoduše zvolit z nabídky combo boxu. Po navázání úspěšného spojení nedochází automaticky k mapování obsahu připojeného server, a to především z důvodu velikosti databáze, ale také kvůli rekurzivním vztahům mezi objekty, kdy by nebylo zřejmé až do jaké úrovně má být obsah zmapován. Prohledávání DCM objekty tedy probíhá na podnět uživatele, kdy se prochází pouze vybraná větev DCM objektů. Načítání aktuálních dat, částečně také včetně struktur, je prováděno příslušnými DCM dotazy s použitím vzdáleného SOAP volání.

10.3.3

Datový model a generování DCM dotazu

Po analýze struktur DCM dotazů, které jsou velice podobné jazyku XPath [88], byl vytvořen speciální datový model, který umožňuje poměrně dobře mapovat jednotlivé fáze tvorby DCM dotazu, a ze kterého lze později příslušný dotaz jednoduše generovat pouhým projitím prvků. Datový model byl navržen tak, aby pokryl co možná nejširší spektrum možností DCM jazyka a tomu byly také přizpůsobeny možnosti grafického rozhraní – například dvouúrovňová volba atributů, kdy v závislosti na výběru může atribut sloužit jako podmínka pro volbu DCM objektu, nebo také jako koncová hodnota, která je předmětem volání DCM dotazu. Jedinou oblastí, kterou datový model nepokrývá, je pouze vícenásobná podmíněná selekce na úrovni atributů jednotlivých DCM objektů, jejíž zavedení by ale především vyžadovalo změnit základní část grafického návrhu. Osobně se domnívám, že by to celý navržený koncept zbytečně zesložitilo, tedy jsem od této možnosti ustoupil. Navíc takováto volání nejsou až tolik používaná, tedy jsem raději zachoval přímočarost při prohledávání mezi DCM objekty a tvorbě dotazu.

10.3. IMPLEMENTACE

77

Základní prvky datového modelu dědí od abstraktní třídy DCMEntity a implementují abstraktní metodu getQueryPart. Vytvoření celého DCM dotazu pak spočívá pouze v zavolání této metody pro každý příslušný uzel na cestě do kořene stromu.

10.3.4

Architektura DCM Object Browseru

Z důvodu velikosti aplikace byla pro implementaci zvolena jednoduchá architektura s centrálním řídícím prvkem (instance vlastní třídy Facade), který byl vytvořen dle návrhového vzoru Facade a tudíž sjednocuje přístup k jednotlivým komponentám na nižších vrstvách a vytváří jednotný interface celého prohlížeče. Implementace tohoto uzlu byla dále provedena s použitím návrhového vzoru Singleton a zároveň byl aplikován pattern Observer, který slouží k notifikaci registrovaných prvků. Zde byly využity pro tento účel již předpřipravené třídy a rozhraní jazyka Java: java.unil.Observable a java.util.Observer. Pro vytvoření větší uživatelské přívětivosti byly základní operace související s voláním DCM dotazů přes SOAP API vyčleněny do samostatných vláken (odděděním od třídy SwingWorker) a jejich průběh je zobrazován v samostatném progress baru. Pomocí Java Action jsou vytvořeny základní akce jako připojení k serveru, odpojení od serveru a refresh náhledu, což je umožňuje umisťovat na různá místa v grafickém rozhraní. Co se dalších grafických prvků týče, byla převážná většina z nich implementována odděděním standardních grafických komponent a dospecifikováním podrobnějšího chování. Příkladem budiž například třída DCMObjectTree s vlastním rendererem (v podobě třídy TreeRenderer), či speciálně upravená základní komponenta JTextPane, která zajišťuje formátování výsledku volání DCM dotazu. Ukázku grafického prostředí aplikace, které je provedeno s použitím standardní grafické knihovny SWING, je možné vidět na obr. 10.6 na konci této kapitoly. Jednou z dalších základních částí celého prohlížeče je implementace SAX parseru – tedy event-based aplikačního rozhraní, v podobě třídy DCMParser, jejíž hlavním úkolem je při spouštění aplikace načíst, zkontrolovat a jednorázově rozebrat konfigurační soubor DcmObjectMappingsDocument.xml a vytvořit vnitřní definici základních struktur. Samotné provádění, včetně inicializace základních grafických komponent při startu je navenek reprezentováno jednoduchou úvodní startovací obrazovkou (splash screen), viz obr. 10.4.

Obrázek 10.4: Úvodní startovací obrazovka (splash screen)

78


10.3.5

Konfigurační soubory a logování

DCM Object Browser je nastavován konfiguračními soubory, které jsou uložený v adresáři config. Jedná se o tyto soubory: • config.properties slouží k uchovávání posledního stavu aplikace – především velikosti okna, umístění na obrazovce a rozložení komponent. • connection.properties definuje automaticky uložená úspěšná připojení k serverům, která se při opětovném spuštění formuláře pro připojení (Connection Settings) načtou do příslušného combo boxu. • log4j.properties je konfigurační soubor logovacího nástroje log4j, který slouží k definici použitého loggeru a pro koncového uživatele především jako místo, kde se definuje úroveň logování. Jak bylo již částečně zmíněno výše, DCM Object Browser využívá knihovnu Apache log4j 1.2 [43] pro účely logování celé aplikace. Samotný přístup a práce s knihovnou je prováděn pomocí vlastní třídy DCMObjectBrowserLogger implementované v návrhovém vzoru Singleton. Na většině důležitých místech a prakticky v každém try-catch bloku je tak umístěno volání s příslušnou úrovní, což by mělo ve výsledném záznamu v logu poukázat na případné chyby, které nebyly objeveny v průběhu testování a odhalit jakákoliv nestandardní chování celé aplikace. Aplikace využívá logovacích úrovní: • DEBUG, • INFO, • ERROR, • FATAL. Vzhledem k nastavené úrovni logování v konfiguračním souboru jsou příslušné záznamy s definovanou úrovní (včetně všech nižších) zaznamenávány do souboru logs/DCMBrowser.log a díky použitému appenderu DailyRollingFileAppender je každý uplynulý den tento soubor označen patternem ’.’yyyy-MM-dd.

10.4

IBM Integrated Service Management Library

Po úspěšném testování, které je blíže popsáno v kapitole 11.4, a hodnocení nezávislými osobami, které mají zkušenosti s nasazením řešení TPM jsem podal návrh na vložení DCM Object Browseru do Integrated Service Management Library (ISM Library). Jelikož byl tento návrh schválen, je nyní možné tuto aplikaci v současné verzi 1.1.46 stáhnout z oficiálních IBM stránek, konkrétně zde [9]. Hlavičku zmíněných stránek lze vidět na následujícím obrázku, viz obr. 10.5.

10.4. IBM INTEGRATED SERVICE MANAGEMENT LIBRARY

Obrázek 10.5: DCM Object Browser verze 1.1.46 umístěný v IBM ISM Library

Obrázek 10.6: DCM Object Browser – načítání atributů objektu HostPlatform

79

80


Kapitola 11

Testování V této kapitole se zaměřím na možnosti testování vyvíjeného prostředí a popíši problémy, které s tím vznikají. Tím největším, který bych rád zmínil hned na začátku, je fakt, že pro kontrolu funkcí TPM workflow žádný nástroj – např. podobný Unit testům v jazyce Java, neexistuje. Z toho pro mě plyne hned několik problémů, a to především nutnost neustálé manuální kontroly prováděných činností a současně alespoň minimální kontrola již implementovaných věcí, abych si byl jist, že nově přidané změny nijak neovlivnily již implementovaná řešení. Neexistenci automatického kontrolního nástroje bych zde zdůvodnil např. tím, že TPM workflow provádějí různé velice komplexní operace, jejichž kontrola by vyžadovala poměrně složité kontrolní mechanismy. Dalším problémem je fakt, že jednotlivé úkony jsou většinou prováděny na vzdálených serverech.

11.1

Automatické nasazení serverů

Neexistence kontrolního mechanismu se především projevila při testování automatického nasazení serverů. I přesto, že všechna workflow, která byla přidána k základní sadě určené pro provisioning, byla vyvíjena v Automation Package Development Environment (APDE), kde lze běh samotných workflow poměrně pěkně sledovat, otestování všech funkcionalit dohromady je poměrně časově náročné. Jediný možný způsob otestování totiž spočívá ve spuštění samotného provisioningu serveru a počkání potřebné doby, než jsou ve správném pořadí pospouštěna příslušná workflow. Dalším důvodem proč bylo v tomto případě nutné postupovat pouze tímto způsobem je fakt, že některá nastavení, která je nutné provést pro správné nakonfigurování celého systému dle pravidel a standardů cílového prostředí, obsahují velké zásahy do operačního systému. Pro jistotu, že běh workflow probíhá korektně především proti nově vytvářenému stroji a ne pouze proti stroji, kde byly příslušné hodnoty simulovány opakovanou změnou parametrů a nastavení, bohužel nebylo možné testovat jiným způsobem. Problémovým se zde stalo především množství změn, které bylo nutné v rámci vytváření serverů provést. Doba testování se zde prodlužovala také tím, že pro samotné vytvoření serverů existují dvě možnosti – v rámci tvorby nového projektu a pak také přidáním nových serverů do

81

82

KAPITOLA 11. TESTOVÁNÍ

již existujícího projektu. Rozdíly mezi oběma přístupy jsou sice minimální (např. co se samotných runbooků týče), ale i přesto bylo nutné provedené změny ověřit pro obě možnosti. Podobně jako tvorbu serverů bylo nutné kontrolovat i jejich korektní odstranění, kde byl kladen důraz především na vliv operací na další systémy, jako např. odstranění definice serveru z domény AD apod. Ve výsledném součtu, který ovlivnilo zároveň testování vytvoření serveru včetně vybrané aplikace, bylo provedeno téměř přes dvě stě testovacích nasazení.

11.2

Automatické nasazení aplikací

Problém testování automatického nasazení aplikací se oproti testování nasazení serverů podstatně zjednodušil. Vývojové prostředí APDE nabízí poměrně dobře propracovaný pohled Execution Results určený pro přehled běhu spuštěného workflow. Tento pohled nabízí také postupné rozbalování logů dle spouštěných workflow apod. Část běhu testovací instalace v tomto pohledu je možné vidět na obr. 11.1.

Obrázek 11.1: Ukázka části logu testovací instalace databáze Microsoft SQL Server 2005 v APDE pohledu Execution Results

Doba testování se zde zkrátila. Především díky tomu, že základní část testování instalace softwaru lze ve většině případů provádět opakovaně proti jedné instanci existujícího serveru.

11.3. IMPLEMENTACE MĚŘENÍ SLUŽEB

83

Návrat do původního stavu serveru pomocí odinstalování software je většinou dostačující. Pomocí APDE lze zároveň testovat i rozpracovaná workflow, není tedy nutné všechny operace provádět ze samoobslužného portálu, kam bude ve výsledku nabídka instalace softwaru umístěna. Na základně navržených kroků a postupů, v podstatě tedy jakési pomyslné šablony, pro instalaci softwarových balíčků byly dále úspěšně vytvořeny a testovány další aplikace, např. instalace databáze Oracle pro linuxové stroje.

11.3

Implementace měření služeb

Hlavním předmětem testování balíku CST_Servers_Metering se stalo především workflow CST_Metering_ListAll, jehož úlohou je v cloudu nalézt všechny existující servery a zálohy (backups), jenž byly vytvořeny na základě požadavku ze samoobslužného portálu. Zmíněné workflow prošlo několika zásadními úpravami, než byl nalezen efektivní finální přístup správy informací pro měření služeb. Toto testování bylo možné provádět s využitím APDE. Podrobnému testování bylo také podrobeno předávání parametrů na úrovni runbooků při mapování procesů na rozhraní TPM workflow. Významný počet vstupních parametrů byl totiž vytvořen pomocí nově definovaných vztahů (relationships) na úrovni databázového modelu (s využitím standardních postupů typických pro Maximo). Provedení této kontroly bohužel nelze provést jinak, než samotným spuštěním nastaveného procesu, což vyžaduje opět provedení testovacího provisioningu apod. přímo ze samoobslužného portálu. Jednou z klíčových věcí se především pro účely měření služeb (ale také pro aplikování různých změn na existující sadu virtuálních strojů) stalo nastavení Executing Node Scope u procesů, které zajišťují zmíněné mapování vstupních parametrů na TPM workflow, viz obr. 11.2. Jedná se o volbu, která nastavuje určitý rámec – např. pro množinu existujících serverů, kde bude proces spuštěn. Tímto parametrem lze třeba definovat, že pouze pro nové servery v existujícím projektu se mají spustit procesy pro zaznamenání nové služby, nebo např. že pouze pro označené servery v rámci existujícího projektu se má spustit proces odebrání z domény apod. Chybná nastavení se projevovala jako inkonzistence ve výsledných CSV souborech, ale také v celkovém cloudovém prostředí, kdy seznam serverů v rámci domény nereflektoval počet existujících virtuálních strojů apod. Obecně lze říci, že nalézt takovouto chyby je poměrně obtížné.

Obrázek 11.2: Nastavení rámce (Executing Node Scope) při mapování vstupních a výstupních parametrů

Díky paralelnímu testování několikanásobného provisioningu byla zároveň odhalena kritická sekce navrženého modulu pro měření služeb, a to vzájemný přístup k DCM datovému

84

KAPITOLA 11. TESTOVÁNÍ

modelu. Byly např. odhaleny poměrně výjimečné, ale i přesto možné, stavy, kdy docházelo k zaznamenávání neúplných definic serverů, a to z toho důvodu, že paralelně běžící vlákno ještě nedokončilo přidání všech potřebných parametrů k serveru, a nebo byl server v rané fázi samotného provisioningu – kopírování šablony (template) virtuálního stroje apod. Pro odstranění nalezených problémů byl implementován jednoduchý kontrolní mechanismus spočívající v testování úplnosti záznamu jednotlivých serverů a nakonec vytvoření zamykacího mechanismus, jenž byl krátce zmíněn v kapitole 9.4.

11.4

Prohlížeč Data Center Model (DCM) objektů

I přesto, že implementované řešení DCM Object Browseru je aplikace napsané čistě v jazyce Java, nebyly pro testování použity Unit testy, jak je u většiny takovýchto programů zvykem. Důvodem byly především časté a téměř kompletní reimplementace většiny tříd, či výrazné změny návrhů aplikace. Velice užitečným nástrojem pro odhalování chyb se ale stala integrace se standardní knihovnou pro logování – log4j [43]. Vnitřní funkce pro tvorbu příslušných výpisů do log souborů jsou umístěny v každém try-catch bloku, kde lze chybu předpokládat, ale taká na různých místech celé aplikace, kde slouží především jako kontrolní výpisy. Jelikož vytvořená aplikace nedosahuje nijak enormních rozměrů, bylo možné z chybových výpisů poměrně jednoduše vyčíst příčinu každé nalezené chyby. Základem pro testování se staly především celosvětové IBM interní komunity zabývající se problematikou řešení TPM a TSAM, kam byla aplikace v průběhu vývoje několikrát zaslána. Na základě obdržených názorů, rad i požadavků byly měněny některé funkcionality, ale také klíčové části aplikace – jako např. použitá SOAP proxy, která nebyla schopna poskytnout všechny potřebné informace apod. Realizovanou a především řádně otestovanou verzi prohlížeče DCM objektů lze stáhnout z oficiálních stránek IBM – Integrated Service Management Library (ISML) [9].

Kapitola 12

Závěr Cílem této práce bylo seznámit se s konceptem cloudových řešení – především s IBM Service Delivery Managerem (ISDM), zaměřit se také na Tivoli Provisioning Manager (TPM) a vyvinout sadu workflow pro automatický provisioning databáze Microsoft SQL Server 2005. Především z důvodu, že tento problém byl řešen v reálném prostředí, bylo zároveň nutné soustředit se současně na úspěšné dokončení dalších bodů práce, a to provisioning serverů a měření služeb. Dle definovaných cílů z kapitoly 2 jsem se nejprve soustředil na získání potřebných teoretických základů nutných pro pochopení konceptů, fungování a vlastností cloudových prostředí. Poměrně do hloubky jsem se seznámil s řešením ISDM a TPM a i přesto, že jsem v rámci jejich popis částečně vynechal technické detaily, které by bylo potřeba zmínit pro hlubší pochopení všech souvislostí, domnívám se, že jsem vytvořil text, který svým rozsahem dostatečně pokrývá danou problematiku. Popisem především klíčových bodů tak umožňuje vytvořit si představu o procesech prováděných v rámci zprovoznění jednoduché služby. Všechny získané informace shrnuté v teoretické části práce jsem následně využil v části praktické, kde jsem řešil především tato čtyři hlavní témata: • Provisioning serverů. V první řadě jsem se zabýval možnostmi a procesy jakým způsobem obohatit základní postupy při vytváření virtuálních strojů s OS Microsoft Windows Server 2008. Automatický proces začlenění nově vytvořených serverů do již existujícího prostředí tak, aby splňovaly definované vnitřní politiky, jsem vyřešil implementací několika balíků (automation packages) s příslušnými workflow. V rámci tohoto úkolu jsem především navrhl a vytvořil malou knihovnu, která obohacuje základní sadu workflow pro správu serverů v cloudu a dále také knihovnu workflow specifickou pro prostředí koncového zákazníka. • Instalace Microsoft SQL Serveru 2005. Po úspěšné integraci nově vytvářených serverů do existujícího prostředí jsem se věnoval klíčovému cíli této práce, a to automatickému nasazení databáze Microsoft SQL Server 2005. Navrhl jsem a implementoval příslušný ovladač, který je díky vlastní definici DCM vrstvy plně přenositelný do dalších cloudových prostředí. Pro úspěšné dokončení tohoto úkolu jsem zároveň implementoval další sady pomocných workflow řešících především problémy se spouštěním operací na vzdálených systémech v kontextu libovolného uživatele.

85

86

KAPITOLA 12. ZÁVĚR

• Měření služeb. Z důvodu požadavku zachovat v nově vytvářeném cloudovém prostředí stávající způsob účtování za poskytované zdroje navrhl jsem a úspěšně implementoval speciální modul, který zajišťuje měření služeb. Realizované řešení zároveň umožňuje nově rozlišovat a měřit služby, které nám nejsou schopny standardní nástroje v ISDM cloudu zaznamenávat – jedná se např. o uchovávání záloh serverů, či použití dodatečných datových disků. • DCM Object Browser. Posledním tématem, kterým jsem se úspěšně zabýval v této práci byla snaha zjednodušit proces tvorby TPM workflow – především tedy DCM dotazů. Díky praktickým zkušenostem se způsobem vývoje těchto workflow, znalostem datového modelu DCM, struktur DCM objektů a možnostem jejich dotazování jsem byl schopen implementovat samostatnou Java aplikaci v podobě DCM Object Browseru. Tento nástroj umožňuje s použitím SOAP API TPM Serveru automaticky generovat DCM dotaz pouhým procházením DCM objektů. Vývoj posledně zmíněného nástroje jsem v průběhu samotné implementace konzultoval s předními IBM odborníky na TPM Server a cloudová prostředí. Díky propracovanosti a unikátnosti tohoto řešení byl schválen návrh na umístění DCM Object Browseru do IBM Integrated Service Management Library (ISM Library), odkud je nyní ve verzi 1.1.46 volně ke stažení, konkrétně zde [9]. Tento nástroj zaznamenal během jednoho měsíce přes padesát stažení, což považuji, vzhledem k jeho poměrně dosti specificky zaměřené oblasti použití, za úspěch. Osobně jsem se zatím setkal pouze s pochvalnými ohlasy a několika návrhy na vylepšení – především z Německa, ale také např. z Číny.

12.1

Vlastní přínos práce

Za největší osobní přínos této práce považuji především nabyté teoretické informace o virtualizačních vrstvách a základních konceptech cloudových prostředí, které lze později uplatnit nezávisle na samotné implementaci. Praktických dovedností s realizací nových procesů pomocí TPM workflow a pochopení vnitřních závislostí ISDM cloudu lze nyní využít pro implementace složitějších služeb, jako např. automatické vytváření multi-serverových architektur s multi-tierovými aplikacemi apod. Zmíněné nabyté zkušenosti lze podložit získanými IBM certifikáty.

Cloud Computing

IBM Certified Solution Advisor – Cloud Computing Architecture V1

technology

IBM Certified Solution Architect – Cloud Computing Infrastructure V1 IBM Certified Deployment Professional – Tivoli Provisioning Manager V7.2.0.2

Literatura [1] M. L. Bote-Lorenzo, Y. A. Dimitriadis, and E. Gomez-Sanchez. Grid Characteristics and Uses: a Grid Definition. http://www.springerlink.com/content/ xaewgn73bg77phga/fulltext.pdf, stav z 8. 11. 2011. [2] M. J. Foley. Microsoft to ship Windows Server 2008, over time, in eight flavors. http://www.zdnet.com/blog/microsoft/microsoft-to-ship-windows-server2008-over-time-in-eight-flavors/935, stav z 30. 10. 2011. [3] M. Frič. Virtualizace v Linuxu. http://hippo.feld.cvut.cz/vrbata/gopas/virtualizace-uvod.pdf, stav z 16. 10. 2011. [4] M. Gagnaire. Optical Ethernet for Cloud computing. Week intensive course of Advanced Technology Higher Education Network, Socrates (ATHENS) program, November 2011, Paris. http://www.athensprogramme.com/, stav z 20. 11. 2011. [5] J. Geelan. Twenty-One Experts Define Cloud Computing. http://virtualization.sys-con.com/node/612375, stav z 6. 11. 2011. [6] M. T. Jones. Discover the Linux Kernel Virtual Machine. http://www.ibm.com/developerworks/linux/library/l-linux-kvm/, stav z 22. 10. 2011. [7] P. Mell and T. Grance. The NIST Definition of Cloud Computing. http://www.nist.gov/itl/cloud/upload/cloud-def-v15.pdf, stav z 6. 11. 2011. [8] R. Šíp. 5 důvodů proč dát přednost VMware Serveru před ESXi. http://netmania.cz/5-duvodu-proc-dat-prednost-vmware-serveru-pred-esxi, stav z 29. 10. 2011. [9] J. Pětník. IBM Integrated Service Management Library – DCM Object Browser. https://www-304.ibm.com/software/brandcatalog/ismlibrary/details? catalog.label=1TW101099#, stav z 17. 4. 2012. [10] J. Stokes. Ars Technica Guide to Virtualization. http://arstechnica.com/hardware/news/2008/08/virtualization-guide1.ars/1, stav z 17. 10. 2011.

87

88

LITERATURA

[11] B. P. Tholeti. Hypervisors, virtualization, and the cloud: Dive into the KVM hypervisor. http://www.ibm.com/developerworks/cloud/library/clhypervisorcompare-kvm/index.html, stav z 23. 10. 2011. [12] B. P. Tholeti. Hypervisors, virtualization, and the cloud: Dive into the PowerVM hypervisor. http://www.ibm.com/developerworks/cloud/library/clhypervisorcompare-powervm/, stav z 22. 10. 2011. [13] B. P. Tholeti. Hypervisors, virtualization, and the cloud: Dive into the VMware ESX Server hypervisor. http://www.ibm.com/developerworks/cloud/library/clhypervisorcompare-vmwareesx/index.html, stav z 29. 10. 2011. [14] B. P. Tholeti. Hypervisors, virtualization, and the cloud: Dive into the XEN hypervisor. http://www.ibm.com/developerworks/cloud/library/clhypervisorcompare-xen/index.html, stav z 23. 10. 2011. [15] B. P. Tholeti. Hypervisors, virtualization, and the cloud: Dive into the z/VM hypervisor. http://www.ibm.com/developerworks/cloud/library/clhypervisorcompare-zvm/index.html, stav z 22. 10. 2011. [16] L. M. Vaquero, L. Rodero-Merino, J. Caceres, and M. Lindner. A break in the clouds: towards a cloud definition. http://dl.acm.org/citation.cfm?id=1496100&bnc=1, stav z 6. 11. 2011. [17] TPM 5.1 Advanced Development Guide – Part 2: Workflow Language and Best Practices. https://www-304.ibm.com/software/brandcatalog/ismlibrary/details? catalog.label=1TW10107G, stav z 28. 3. 2012. [18] Android Emulator. http://developer.android.com/guide/developing/tools/emulator.html, stav z 16. 10. 2011. [19] Automation Package Developer Environment plugin for eclipse 3.6. https://www-304.ibm.com/software/brandcatalog/ismlibrary/details? catalog.label=1TW10103L, stav z 8. 10. 2011. [20] What is a Business-as-a-Service (BaaS) Model? http://kurteus.com/2011/11/15/business-as-a-service/, stav z 22. 11. 2011. [21] Bochs IA-32 Emulator Project. http://bochs.sourceforge.net/, stav z 16. 10. 2011. [22] Citrix. http://www.citrix.com/, stav z 16. 10. 2011. [23] Cygwin. http://www.cygwin.com/, stav z 8. 10. 2011. [24] DOSBox. http://www.dosbox.com/, stav z 16. 10. 2011.

LITERATURA

89

[25] Eclipse. http://www.eclipse.org/, stav z 8. 10. 2011. [26] Eclipse Downloads. http://www.eclipse.org/downloads/, stav z 8. 10. 2011. [27] How to Enable VMI (Paravirtualization) in VMware ESX Virtual machines. http://www.techiesweb.com/how-to-enable-vmi-paravirtualizationin-vmware-esx-virtual-machines/, stav z 16. 10. 2011. [28] Download VMware vSphere Hypervisor (ESXi). http://downloads.vmware.com/d/info/datacenter_cloud_infrastructure/ vmware_vsphere_hypervisor_esxi/5_0, stav z 29. 10. 2011. [29] FreeBSD Handbook – Jails. http://www.freebsd.org/doc/handbook/jails.html, stav z 16. 10. 2011. [30] Industry Leaders Worldwide Embrace IBM Clouds to Transform Business Processes. http://www.prnewswire.com/news-releases/industry-leaders-worldwideembrace-ibm-clouds-to-transform-business-processes-119388749.html, stav z 17. 4. 2012. [31] IBM Systems Software Information Center – System z virtualization. http://publib.boulder.ibm.com/infocenter/eserver/v1r2/index.jsp?topic= %2Fdiricinfo%2Fvsd0_c_zseries_virtualization.html, stav z 22. 10. 2011. [32] IBM Watson. http://www-03.ibm.com/innovation/us/watson/index.html, stav z 23. 10. 2011. [33] IBM z/VM. http://www.vm.ibm.com/, stav z 22. 10. 2011. [34] IBM Systems Hardware information – POWER hypervisor. http://publib.boulder.ibm.com/infocenter/powersys/v3r1m5/index.jsp? topic=/p7ha2/vetviewingsettingsfor.htm, stav z 20. 10. 2011. [35] IBM Service Delivery Manager. http://www-01.ibm.com/software/tivoli/products/service-deliverymanager/, stav z 24. 3. 2012. [36] IBM Service Delivery Manager – Software stack. http://publib.boulder.ibm.com/infocenter/tivihelp/v10r1/topic/com.ibm. isdm_7.2.2.doc/c_tsameesoftwarestack.html, stav z 24. 3. 2012. [37] Cloud Computing Exploited! http://javacloud9.blogspot.com/2011/01/cloud-computing-exploitted.html, stav z 22. 11. 2011. [38] Jython: Python for the Java Platform. http://www.jython.org/, stav z 30. 3. 2012.

90

LITERATURA

[39] KVM Guest Support Status. http://www.linux-kvm.org/page/Guest_Support_Status, stav z 22. 10. 2011. [40] KVM Status. http://www.linux-kvm.org/page/Status, stav z 22. 10. 2011. [41] libvirt Architecture. http://libvirt.org/architecture.html, stav z 20. 10. 2011. [42] IBM Java (OS Linux) Download. http://www.ibm.com/developerworks/java/jdk/linux/download.html, stav z 8. 10. 2011. [43] Apache log4j 1.2. http://logging.apache.org/log4j/1.2/, stav z 20. 3. 2012. [44] IBM LotusLive. http://www-01.ibm.com/software/cz/lotus/category/saas/, stav z 23. 3. 2012. [45] Mac OSX on KVM. http://d4wiki.goddamm.it/index.php?title=Howto:_Mac_OSX_on_KVM, stav z 22. 10. 2011. [46] MSDN – Hyper-V Architecture. http://msdn.microsoft.com/en-us/library/cc768520(v=bts.10).aspx, stav z 30. 10. 2011. [47] Oracle Solaris Containers. http://www.oracle.com/technetwork/server-storage/solaris/ containers-169727.html, stav z 16. 10. 2011. [48] Oracle VM. http://www.oracle.com/us/technologies/virtualization/ oraclevm/index.html, stav z 20. 10. 2011. R Fusion Middleware Administrator’s Guide for Oracle Adaptive Access Ma[49] Oracle nager Release 11g (11.1.1) – Chapter 24 Multitenancy. http://download.oracle.com/ docs/cd/E14571_01/doc.1111/e14568/multitenant.htm, stav z 7. 11. 2011.

[50] PearPC – PowerPC Architecture Emulator. http://pearpc.sourceforge.net/, stav z 16. 10. 2011. [51] Co je virtualizace? http://www.psaxf.net/virtualizace/, stav z 16. 10. 2011. [52] QEMU. http://qemu.org/, stav z 16. 10. 2011. [53] Qumranet Solid ICE. http://www.zdnet.com/blog/virtualization/qumranet-solid-ice/242, stav z 22. 10. 2011.

LITERATURA

91

[54] SETI@home. http://setiathome.berkeley.edu/, stav z 8. 11. 2011. [55] IBM SmartCloud. http://www.ibm.com/cloud-computing/us/en/, stav z 21. 3. 2012. [56] IBM Smarter Planet. http://www.ibm.com/smarterplanet/us/en/index.html?re=sph, stav z 21. 3. 2012. [57] IBM SmartCloud Enterprise. http://www-935.ibm.com/services/us/en/cloud-enterprise/index.html, stav z 23. 3. 2012. [58] IBM SmartCloud Entry (delivered as IBM Starter Kit for Cloud). https://www.ibm.com/developerworks/mydeveloperworks/groups/service/ html/communityview?communityUuid=889bf8c7-5890-4314-814b-588edd606644, stav z 23. 3. 2012. [59] IBM Storwize V7000 Unified Storage. http://www-03.ibm.com/systems/storage/disk/storwize_v7000/, stav z 21. 3. 2012. [60] Microsoft TechNet – About Virtual Machines and Guest Operating Systems. http://technet.microsoft.com/en-us/library/cc794868(WS.10).aspx, stav z 30. 10. 2011. [61] Microsoft TechNet – Hardware Considerations. http://technet.microsoft.com/en-us/library/cc816844(WS.10).aspx, stav z 30. 10. 2011. R Provisioning Manager Provisioning Workflows and Automation Packages [62] Tivoli - PDF version. http://publib.boulder.ibm.com/infocenter/tivihelp/v45r1/ topic/com.ibm.tivoli.tpm.wkf.doc/tpm_workflow_guide.pdf, stav z 8. 10. 2011.

[63] IBM Tivoli Provisioning Manager Information Center, Version 7.1.1. http://publib.boulder.ibm.com/infocenter/tivihelp/v28r1/index.jsp, stav z 19. 3. 2012. [64] IBM Tivoli Provisioning Manager Information Center, Version 7.2.1. http://publib.boulder.ibm.com/infocenter/tivihelp/v45r1/index.jsp, stav z 19. 3. 2012. [65] IBM Tivoli Provisioning Manager Information Center, Version 8.1 BETA. http://publib.boulder.ibm.com/infocenter/tivihelp/v23r1/index.jsp, stav z 19. 3. 2012. [66] IBM Tivoli Provisioning Manager Version 7.2 – Provisioning workflows and automation packages guide. http://publib.boulder.ibm.com/infocenter/tivihelp/v45r1/ topic/com.ibm.tivoli.tpm.wkf.doc/tpm_workflow_guide.pdf, stav z 29. 3. 2012.

92

LITERATURA

[67] Tivoli Service Automation Manager. http://www-01.ibm.com/software/tivoli/products/service-auto-mgr/, stav z 24. 3. 2012. [68] Oracle VirtualBox. https://www.virtualbox.org/, stav z 16. 10. 2011. [69] Windows Virtual PC. http://www.microsoft.com/windows/virtual-pc/, stav z 16. 10. 2011. [70] VMware. http://www.vmware.com/, stav z 16. 10. 2011. [71] VMware vSphere Distributed Resource Scheduler (DRS). http://www.vmware.com/products/drs/overview.html, stav z 29. 10. 2011. [72] VMware Guest Operating System Installation Guide. http://www.vmware.com/files/pdf/GuestOS_guide.pdf, stav z 29. 10. 2011. [73] VMware vSphere High Availability (HA). http://www.vmware.com/products/high-availability/overview.html, stav z 29. 10. 2011. [74] VMware – Understanding Full Virtualization, Paravirtualization, and Hardware Assist. http://www.vmware.com/files/pdf/VMware_paravirtualization.pdf, stav z 29. 10. 2011. [75] VMware vSphere Storage VMotion. http://www.vmware.com/products/storage-vmotion/overview.html, stav z 29. 10. 2011. [76] VMware vSphere 4 – ESXi Installable and vCenter Server Documentation Center. http://pubs.vmware.com/vsphere-4-esxi-installable-vcenter/index.jsp, stav z 29. 10. 2011. [77] VMware vSphere VMotion. http://www.vmware.com/products/vmotion/overview.html, stav z 29. 10. 2011. [78] Microsoft Hyper-V Server 2008 R2. http://www.microsoft.com/en-us/server-cloud/hyper-v-server/default.aspx, stav z 30. 10. 2011. [79] Comparison of virtual machines. http://en.wikipedia.org/wiki/Comparison_of_virtual_machines, stav z 17. 10. 2011. [80] World community grid. http://www.worldcommunitygrid.org/, stav z 8. 11. 2011. [81] XEN Open Source Project. http://www.xen.org/, stav z 16. 10. 2011.

LITERATURA

93

[82] Citrix XenApp Overview. http://www.citrix.com/xenapp/overview, stav z 17. 10. 2011. [83] Citrix Completes Acquisition of XenSource. http://www.citrix.com/English/NE/news/news.asp?newsID=683171, stav z 17. 10. 2011. [84] Citrix XenDesktop Overview. http://www.citrix.com/xendesktop/overview, stav z 17. 10. 2011. [85] Xen Overview. http://wiki.xensource.com/xenwiki/XenOverview, stav z 20. 10. 2011. [86] Citrix XenServer Overview. http://www.citrix.com/xenserver/overview, stav z 17. 10. 2011. [87] What is Xen Hypervisor? http://www.xen.org/files/Marketing/WhatisXen.pdf, stav z 22. 10. 2011. [88] XML Path Language (XPath), Version 1.0. http://www.w3.org/TR/xpath/, stav z 20. 3. 2012. [89] Typy virtualizace. http://miho.blog.zive.cz/2008/07/typy-virtualizace/, stav z 16. 10. 2011. [90] IBM Systems Software Information Center – System z PR/SM. http://publib.boulder.ibm.com/infocenter/eserver/v1r2/index.jsp?topic= %2Feicaz%2Feicazzlpar.htm, stav z 22. 10. 2011. [91] IBM Systems Software Information Center – z/VM. http://publib.boulder.ibm.com/infocenter/eserver/v1r2/index.jsp?topic= %2Feicaz%2Feicazzvm.htm, stav z 22. 10. 2011.

94

LITERATURA

Příloha A

Seznam použitých zkratek

Zkratka

Význam

AD

Active Directory

AIX

Advanced Interactive eXecutive

APDE

Automation Package Development Environment

API

Application Programming Interface

ARM

Advanced RISC Machines

ASCII

American Standard Code for Information Interchange

ASP

Application Service Provider

BaaS

Business as a Service

bash

Bourne-again shell

BIOS

Basic Input/Output System

BPaaS

Business process as a Service

BPMaaS

Business Process Management (BPM) as a Service

BSD

Berkeley Software Distribution

BYOL

Bring-Your-Own-License

CIFS

Common Internet File System

95

96

PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK Zkratka

Význam

CLI

Common Language Infrastructure

CLI

Command-line Interface

CPU

Central Processing Unit

CRM

Customer Relationship Management

CRUD

Create, Read, Update and Delete

CSR

Customer Service Representatives

CSV

Comma-Separated Values

DaaS

Desktop as a Service

DCM

Data Center Model

DRS

Distributed Resource Scheduler

EaaS

Enterprise as a Service

EDA

Event-driven architecture

ERP

Enterprise Resource Planning

EXT

Extension point

FTP

File Transfer Protocol

GNU

GNU’s Not Unix

GPL

General Public License

HA

High Availability

HTTP

Hypertext Transfer Protocol

HVM

Hardware Virtual Machine

IA64

Intel Itanium Architecture

IaaS

Infrastructure as a Service

IBM

International Business Machines Corporation

97 Zkratka

Význam

IEEE

Institute of Electrical and Electronics Engineers

IP

Internet Protocol

ISML

Integrated Service Management Library

IT

Information Technology

ITM

IBM Tivoli Monitoring

JRE

Java Runtime Environment

JVM

Java Virtual Machine

ksh

Korn shell

KVM

Kernel-based Virtual Machine

LDAP

Lightweight Directory Access Protocol

LDO

Logical Device Operations

LGPL

Lesser General Public License

LPAR

Logical Partition

MaaS

Management as a Service

MaaS

Modeling as a Service

MIT

Massachusetts Institute of Technology

MMC

Microsoft Management Console

MS

Microsoft

MSDN

Microsoft Developer Network

MSR

Memory Service Routine

NFS

Network File System

NIST

National Institute of Standards and Technology

OAAM

Oracle Adaptive Access Manager

98


Význam

OS

Operating System

OSGi

Open Services Gateway initiative framework

PaaS

Platform as a Service

PDA

Personal Digital Assistant

PMRDP

Process Management Resource Driven Provisioning

PR

Processor Resource

PraaS

Process as a Service

RAM

Random-Access Memory

RDP

Remote Desktop Protokol

REST

Representational State Transfer

RISC

Reduced Instruction Set Computing

RM

Resource Manager

RSA

iniciály autorů Rivest, Shamir, Adleman

RU

Runbook

RXA

Remote eXecution and Access protocol

SaaS

Software as a Service

SAP

Service Access Point

SAP

Systeme, Anwendungen, Produkte in der Datenverarbeitung

SAX

Simple API for XML

SCP

Secure Copy

SCSI

Small Computer System Interface

SETI

Search for Extraterrestrial Intelligence

SLA

Service Level Agreement

99 Zkratka

Význam

SM

System Manager

SMB

Server Message Block

SOAP

Simple Object Access Protocol

SP

Service Provider

SPE

Software Package Editor

SPICE

Simple Protocol for Independent Computing

SQL

Structured Query Language

SSH

Secure Shell

TCA

Tivoli Common Agent

TPF

Transaction Processing Facility

TPM

Tivoli Provisioning Manager

TSAM

Tivoli Service Automation Manager

TSRM

Tivoli Service Request Manager

TUAM

Tivoli Usage and Accounting Manager

UML

Unified Modeling Language

VBScript

Visual Basic Scripting

VDI

Virtual Desktop Infrastructure

VID

Virtualization Infrastructure Driver

VLAN

Virtual Local Area Network

VM

Virtual Machine

VMM

Virtual Machine Monitor

VPN

Virtual Private Network

VSC

Virtualization Service Consumer

100


Význam

VSE

Virtual Storage Extended

VSP

Virtualization Service Provider

WMI

Windows Management Instrumentation

WSDL

Web Service Definition Language

WSRF

Web Services Resource Framework

XML

Extensible Markup Language

Příloha B

Zkratky adresářů, cest a proměnných prostředí Tabulka níže uvádí přehled použitých zástupných zkratek pro popis defaultních cílových adresářů a instalačních cest pro jednotlivé druhy operačních systémů a jejich proměnných prostředí (Environment Variables). Pokud není uvedeno jinak, jedná se vždy o proměnné důležité pro bezproblémový chod vývojového prostředí APDE.

Zkratka

Microsoft

Unix/Linux

TIO_HOME

C:Program Files\IBM\tivoli\tpm

/opt/IBM/tivoli/tpm

APDE_HOME

C:\APDE

/home/<username>/APDE

JAVA_HOME

APDE_HOME\java

APDE_HOME/java

101

102

PŘÍLOHA B. ZKRATKY ADRESÁŘŮ, CEST A PROMĚNNÝCH PROSTŘEDÍ

Příloha C

Přehled implementovaných TPM workflow

Obrázek C.1: CST_Servers_Metering projekt

103

104

PŘÍLOHA C. PŘEHLED IMPLEMENTOVANÝCH TPM WORKFLOW

Obrázek C.2: IBM_Prague_Cloud_Core projekt

Obrázek C.4: IBM_Prague_Schtasks projekt

Obrázek C.3: CST_Prague_Cloud_Core projekt

Obrázek C.5: CST_MSSQL2005_Windows_x64 projekt

Příloha D

Instalace Automation Package Developer Environment (APDE) D.1

Požadavky

Z pohledu hardwarových nároků vyžaduje instalace prostředí minimálně 2GB RAM. Co se týče nároků na software, je podporován operační systém Windows a Linux běžící na platformě Intel. Kompletní přehled pro obě prostředí Eclipse je shrnut v tab. D.1 níže. Software Package Editor (SPE), který je součástí APDE (opět v podobě plug-inu do Eclipse) je podporován pouze pro operační systém Windows. Tabulka D.1: Přehled podporovaných operačních systémů Verze Eclipse

D.2

Windows 32-bit 64-bit

Linux 32-bit 64-bit

Eclipse 3.2.2

Ano

Ne

Ano

Ne

Eclipse 3.6

Ano

Ano

Ano

Ano

Průběh instalace

Samotnou instalaci vývojového prostředí Automation Package Developer Environment, které je dostupné jako plug-in do nástroje Eclipse [25], je možné provést dvěma způsoby. V obou případech je zapotřebí mít připraveno: • instalační soubory vývojového prostředí Eclipse ve verzi 3.2.2, nebo 3.6 [26], R Java 1.5 (pro OS Linux dostupná například zde [42]), • IBM

• samotný plug-in APDE (soubor apde.zip, nebo apde_3.6.zip).

105

106PŘÍLOHA D. INSTALACE AUTOMATION PACKAGE DEVELOPER ENVIRONMENT (APDE)

Instalační balík prostředí Eclipse je vyžadován jako soubor typu .zip, případně .tar, R který obsahuje složku eclipse. Podobné omezení je kladeno i na balík obsahující IBM Javu 1.5, kde musí být uvnitř umístěna souborová hierarchie java/bin. Počítače s operačním systémem Windows vyžadují instalaci prostředí Cygwin [23]. První ze zmiňovaných způsobů instalace je čistě manuální a spočívá v kompletním shromáždění potřebných plug-inů a konfiguračních souborů z TPM serveru včetně dodatečných úprav, vytváření .ini souborů, .bat či .sh skriptů apod. Tento postup je poměrně nepřehledný a lehce se v něm provede chyba. Na druhou stranu ale dobře vypovídá o jednotlivých komponentách a dává do podvědomí hlubší souvislosti jednotlivých závislostí a nastavení. Jednodušším postupem jak provést instalaci je využití předpřipraveného shell skriptu Configure_APDE.sh [19], který na základě předložených parametrů zkompletuje potřebné soubory a nakonfiguruje celé prostředí. Tento skript je nutné spustit na TPM serveru1 ve složce TIO_HOME/apde, kde se zároveň nachází potřebný plug-in apde.zip. Po úspěšném provedení skriptu je vytvořen archiv obsahující nakonfigurované prostředí, který lze buďto manuálně, nebo automaticky (vložením parametrů uživatelského jména a IP adresy počítače) přenést na cílové místo2 . V případě konfigurace prostředí Eclipse 3.6 je na závěr nutné nahradit složku s plug-inem: com.ibm.tivoli.orchestrator.tcdriverdevelopment_5.1.0 v cestě APDE_HOME/eclipse/plugins/ za novou: com.ibm.tivoli.orchestrator.tcdriverdevelopment_7.2.0, která je přiložena u daného skriptu, a inicializovat prostředí spuštěním s parametrem -clean, například eclipse.exe -clean.

Důležité Jednou z nejdůležitějších věcí před samotným spuštěním je kontrola nastavení proměnné ke správné Javě (JAVA_HOME) a přiřazení do PATH. Vše závisí na tom, zda byl dodržen tvar balíčků s Javou, který se předložil skriptu Configure_APDE.sh. Ve spouštěcím skriptu eclipseLauncher.bat případně eclipseLauncher.sh bychom měli nalézt podobný zápis (viz níže) a zkontrolovat ho se skutečností: set JAVA_HOME=C:\APDE\java set PATH=%JAVA_HOME%\bin;%PATH% 1

V případě, že je TPM server instalován na operačním systému Windows, je nutné ke spuštění skriptu využít prostředí Cygwin. 2 Jelikož je automatický přenos prováděn pomocí SCP protokolu, musí mít koncové pc využívající operační systém Windows instalován Cygwin s SSH deamonem.

D.3. PARAMETRY SKRIPTU

D.3

107

Parametry skriptu

Pro správné spuštění skriptu je dobré postupovat dle přiloženého souboru ReadMe.txt. Základní parametry skriptu vypadají následovně: Configure_APDE.sh <APDE_install_location> <MACHINE_NAME> "[ECLIPSE_PATH]" "[JRE_PATH]" kde: lin|win definuje, zda bude výsledný archiv používán na operačním systému Windows nebo Linux, APDE_install_location je místo, kde bude APDE nainstalován, MACHINE_NAME identifikuje cílový počítač (IP adresa, nebo hostname). Pokud nemá být archiv přímo přenesen na cílové místo pomocí scp, použije se none. USER_NAME je uživatelské jméno na cílovém počítači (opět použijeme none pro případ ignorování přenosu). complete|partial Při použití complete dojde ke kompletnímu zabalení archivu s Eclipse a Java JRE. V opačném případě (partial) se předpokládá, že jsou oba balíčky již na cílovém pc nainstalovány. ECLIPSE_PATH Cesta k balíčku Eclipse. JRE_PATH Cesta k balíčku Java JRE.

D.3.1

Příklad spuštění

Jako konkrétní ukázku syntaxe spuštění uveďme příklad pro operační systém Windows, ve kterém bude vytvořen kompletní archiv, který nebude přenesen na cílový počítač, ale uloží se lokálně v adresáři TIO_HOME/apde. Jméno zkompletovaného a nakonfigurovaného archivu, který stačí pouze manuálně přenést do instalačního adresáře (C:\APDE) cílového počítače a rozbalit, bude APDE_InstallPackage_win.zip. ./Configure_APDE.sh win C:\APDE none none complete eclipse-x86-win32.zip java-sdk-50-x86-win32.zip Spuštěním skriptu eclipseLauncher.exe zahájíme práci s vývojovým prostředím Eclipse, ve kterém přes Window → Open Perspective → Automation Package přepneme na samotný plug-in APDE.

Poznámka Od TPM 7.2.0.2 je upravená verze tohoto skriptu již součástí instalace serveru a spolu s oběma balíčky apde.zip a apde_3.6.zip je umístěna ve složce TIO_HOME/apde [62].

108PŘÍLOHA D. INSTALACE AUTOMATION PACKAGE DEVELOPER ENVIRONMENT (APDE)

Příloha E

Obsah přiloženého CD |-| |-| | | | | |-| | | | | | | | | | | | | |-| | | | | |--

dist/ – Zkompilované TPM ovladače a DCM Object Browser 1.1.46. doc/ – Dokumentace všech projektů. | |-- javadoc/ – Javadoc DCM Object Browseru a Java vrstvy modulu měření služeb. | |-- workflow/ – Dokumentace jednotlivých workflow. src/ | |-| |-| |-| |-| |-| |--

– Zdrojové kódy všech projektů. CST_MSSQL2005_Windows_x64/ – Ovladač databáze MS SQL Server 2005. CST_Prague_Cloud_Core/ – Knihovna workflow pro koncového zákazníka. CST_Servers_Metering/ – Modul měření služeb. DCM_ObjectBrowser/ – DCM Object Browser 1.1.46. IBM_Prague_Cloud_Core/ – Knihovna rozšiřující standardní sadu workflow. IBM_Prague_Schtasks/ – Ovladač nástroje schtasks.

thesis/ – Text diplomové práce. | |-- src/ – LATEX zdrojové soubory. | |-- petnijir_2012dip.pdf – Diplomová práce ve formátu PDF. README.txt – Popis obsahu jednotlivých adresářů.

109

Automatizace úloh v cloudovém prostředí. Bc. Jiří Pětník

Recommend Documents