Č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
KAPITOLA 3. VIRTUALIZACE
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
KAPITOLA 3. VIRTUALIZACE
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
KAPITOLA 3. VIRTUALIZACE
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ří:
3.3. VIRTUALIZAČNÍ TECHNOLOGIE
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
KAPITOLA 3. VIRTUALIZACE
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.
3.3. VIRTUALIZAČNÍ TECHNOLOGIE
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
KAPITOLA 3. VIRTUALIZACE
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].
3.3. VIRTUALIZAČNÍ TECHNOLOGIE
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
KAPITOLA 3. VIRTUALIZACE
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
KAPITOLA 4. CLOUD COMPUTING
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).
4.1. DEFINICE A VYMEZENÍ POJMU
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
KAPITOLA 4. CLOUD COMPUTING
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
4.1. DEFINICE A VYMEZENÍ POJMU
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
KAPITOLA 4. CLOUD COMPUTING
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
KAPITOLA 4. CLOUD COMPUTING
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
KAPITOLA 4. CLOUD COMPUTING
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
KAPITOLA 4. CLOUD COMPUTING
Čá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
KAPITOLA 5. CLOUDOVÉ TECHNOLOGIE IBM
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
KAPITOLA 5. CLOUDOVÉ TECHNOLOGIE IBM
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
KAPITOLA 5. CLOUDOVÉ TECHNOLOGIE IBM
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
KAPITOLA 6. TPM IMPLEMENTAČNÍ SCHÉMA
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
KAPITOLA 6. TPM IMPLEMENTAČNÍ SCHÉMA
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 <LDO_name>]
LocaleInsensitive | CheckDeviceLocale,
kde <WkfName> značí povinné jméno workflow, <parameters> nepovinné parametry,
<LDO_name> 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 <info message>,
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
KAPITOLA 6. TPM IMPLEMENTAČNÍ SCHÉMA
• 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"][email protected])
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
KAPITOLA 7. AUTOMATICKÉ NASAZENÍ SERVERŮ
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 7. AUTOMATICKÉ NASAZENÍ SERVERŮ
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
KAPITOLA 8. AUTOMATICKÉ NASAZENÍ APLIKACÍ
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" />
</device-model>
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
KAPITOLA 8. AUTOMATICKÉ NASAZENÍ APLIKACÍ
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, <null>, <null>)
try
<<volání workflow nižší úrovně>>
finally
Unlock_DCM_Object(MeteringDeviceID, <null>, <null>)
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
KAPITOLA 9. IMPLEMENTACE MĚŘENÍ SLUŽEB
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
KAPITOLA 9. IMPLEMENTACE MĚŘENÍ SLUŽEB
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(<hostname>:<port>,
<username>, <password>);
Map<String, String> paramMap = new TreeMap<String, String>();
String dcmQuery = "[email protected]";
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
KAPITOLA 10. PROHLÍŽEČ DATA CENTER MODEL (DCM) OBJEKTŮ
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
KAPITOLA 10. PROHLÍŽEČ DATA CENTER MODEL (DCM) OBJEKTŮ
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 10. PROHLÍŽEČ DATA CENTER MODEL (DCM) OBJEKTŮ
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] [email protected] 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
PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK
Zkratka
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
PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK
Zkratka
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 <lin|win> <APDE_install_location> <MACHINE_NAME>
<USER_NAME> <complete|partial> "[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
Download

Automatizace úloh v cloudovém prostředí