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

Transkript

1 Č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

2 iv

3 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.

4 vi

5 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

6 viii

7 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

8 x

9 Obsah 1 Úvod 1 2 Specifikace cíle Popis řešeného problému Popis struktury práce ve vztahu k vytyčeným cílům I Teoretická část 5 3 Virtualizace Definice a základní pojmy Host, guest, hypervisor Druhy virtualizace Emulace Virtualizace na úrovni operačního systému Úplná virtualizace Paravirtualizace Virtualizační technologie XEN KVM ESXi z/vm PowerVM Hyper-V Shrnutí Cloud Computing Definice a vymezení pojmu Obecné vlastnosti Služba na vyžádání a standardizace Dostupnost služby Sdružování prostředků Pružnost Flexibilní cena Virtualizace Multi-tenancy xi

10 xii OBSAH Dynamická infrastruktura Automatizace Provisioning Porovnání přístupů Cluster Computing Grid Computing Celkový pohled Cloud Computing z pohledu koncového uživatele Modely nasazení cloudu Private Cloud Managed Private Cloud Hosted Private Cloud Public Cloud Shared Cloud Hybrid Cloud Modely cloudových služeb IaaS PaaS SaaS DaaS, BaaS, II Analytická část 35 5 Cloudové technologie IBM Pokrytí služeb IBM LotusLive IBM SmartCloud Entry IBM SmartCloud Enterprise Tivoli Service Automation Manager Způsob implementace IBM Service Delivery Manager Architektura softwarových komponent Vrstevnatost systému a obsluha požadavků TPM implementační schéma Tivoli Provisioning Manager Logická zařízení a jejich operace Vazba logické operace a workflow Ovladač zařízení Automation package TPM Workflow Workflow Language Definice workflow Výpisy a logování Jazyk Jython

11 OBSAH xiii Práce s datovým modelem DCM Volání skriptů a Java tříd III Implementační část 53 7 Automatické nasazení serverů IBM_Prague_Cloud_Core Souborová úložiště Koncová zařízení Implementace přístupového bodu RXA CST_Prague_Cloud_Core IBM_Prague_Schtasks Automatické nasazení aplikací Uživatelský kontext Automatické nasazení Microsoft SQL Serveru Obecné řešení Příprava instalačních skriptů Implementace TPM workflow Definice DCM modelu Předávání parametrů ze samoobslužného portálu Implementace měření služeb Definice pravidel měření služeb Možnosti ISDM cloudu Mapování procesů a subprocesů Využití TPM workflow CST_Server_Metering.jar CSV soubory Prohlížeč Data Center Model (DCM) objektů Motivace Specifikace cílů Implementace TPM SOAP API Připojení TPM serveru Datový model a generování DCM dotazu Architektura DCM Object Browseru Konfigurační soubory a logování IBM Integrated Service Management Library Testování Automatické nasazení serverů Automatické nasazení aplikací Implementace měření služeb Prohlížeč Data Center Model (DCM) objektů

12 xiv OBSAH 12 Závěr Vlastní přínos práce 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 Environment (APDE) 105 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 109

13 Seznam obrázků 1.1 Logo firmy IBM 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 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 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 Základní komponenty provisioning workflow Základní struktura jednoduchého automation package Symbol jazyka Jython kombinující prvky jazyka Java a Python Configuration Template s defaultními parametry Konfigurace parametrů instalace databáze Microsoft SQL Server Modifikovaný diagram aktivit znázorňující základní posloupnost procesů workflow CST_MSSQL2005_Windows_x64_Installable_Install.wkf xv

14 xvi SEZNAM OBRÁZKŮ 9.1 Subproces zajišťující mapování vstupních parametrů do TPM workflow Přehledová architektura základních komponent implementovaného modulu měření služeb 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 umístěný v IBM ISM Library DCM Object Browser načítání atributů objektu HostPlatform Ukázka části logu testovací instalace databáze Microsoft SQL Server 2005 v APDE pohledu Execution Results Nastavení rámce (Executing Node Scope) při mapování vstupních a výstupních parametrů C.1 CST_Servers_Metering projekt C.2 IBM_Prague_Cloud_Core projekt C.3 CST_Prague_Cloud_Core projekt C.4 IBM_Prague_Schtasks projekt C.5 CST_MSSQL2005_Windows_x64 projekt

15 Seznam tabulek 7.1 Automation package IBM_Prague_Cloud_Core Automation package CST_Prague_Cloud_Core Automation package IBM_Prague_Schtasks Automation package CST_MSSQL2005_Windows_x Mapování subprocesů a standardních runbooků Automation package CST_Servers_Metering D.1 Přehled podporovaných operačních systémů xvii

16 xviii SEZNAM TABULEK

17 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

18 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

19 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 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 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

20 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 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).

21 Část I Teoretická část 5

22

23 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/ [3] 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

24 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] 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].

25 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 ,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] 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 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].

26 10 KAPITOLA 3. VIRTUALIZACE Obrázek 3.2: Virtualizace na úrovni operačního systému Ú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.

27 3.2. DRUHY VIRTUALIZACE 11 Obrázek 3.3: Úplná virtualizace Nevýhody Pomalejší I/O. Hypervisor konzumuje zdroje celého systému 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 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

28 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 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 Xen- Server [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

29 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 Obrázek 3.5: Schéma jednoduché XEN architektury 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).

30 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] 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 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ří:

31 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

32 16 KAPITOLA 3. VIRTUALIZACE 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 LPARu 1 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] 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.

33 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,

34 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 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].

35 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 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.

36 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í.

37 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

38 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ě 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 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 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.

39 4.1. DEFINICE A VYMEZENÍ POJMU 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 ). 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 dat 3. 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 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 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.

40 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 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 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).

41 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 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ů 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ě

42 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 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ý 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 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 ) 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

43 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 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 Příkladem může být projekt SETI [54], či World Community Grid [80]. Obrázek 4.2: Grid Computing

44 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 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í 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.

45 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.

46 30 KAPITOLA 4. CLOUD COMPUTING Obrázek 4.4: Modely nasazení 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ů 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 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í.

47 4.3. MODELY CLOUDOVÝCH SLUŽEB 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ř. , 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 ) 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 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 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

48 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 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í 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.

49 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 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ř. ové 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šší 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ř. DaaS 4, 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.

50 34 KAPITOLA 4. CLOUD COMPUTING

51 Část II Analytická část 35

52

53 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 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 Obrázek 5.1: Logo vize IBM SmartCloud 37

54 38 KAPITOLA 5. CLOUDOVÉ TECHNOLOGIE IBM 5.2 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ší.

55 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 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.

56 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) 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

57 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 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 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á

58 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á PMRDPRUADD 1 (Add Server Runbook) nebo PMRDPRUSMI 1 (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 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).

59 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 u 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.

60 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

61 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

62 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 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ů.

63 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 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 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.

64 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.

65 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 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] 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

66 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 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 debug <debug message>, log info <info message>, log warning <warning message>, log 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 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

67 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 #(1) var myarraystr = "1,2,3,4" #(1) array myarray = Jython[myArrayStr.split(",")] #(3) var size = Jython[len(myArray)] #(3) if Jython[int(size) > 0] then #(6) flag = Jython[int(size) * 2] #(5) log info Jython["Array size is: " + size] #(2) endif log info Jython["Flag value is: " + (flag OR "null")] #(4) Obrázek 6.3: Symbol jazyka Jython kombinující prvky jazyka Java a Python 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í,

68 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"]/property/@key) DCMInsert parent = DCMQuery(/server[@name="ABC"]) <<EOI <property component="user_defined" name="p1" value="my value" /> EOI DCMDelete(/server[@name="ABC"]/property[@key="P1"]) 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

69 Část III Implementační část 53

70

71 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 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í 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

72 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 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:

73 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 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 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).

74 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

75 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")

76 60 KAPITOLA 7. AUTOMATICKÉ NASAZENÍ SERVERŮ

77 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 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

78 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 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 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 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 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í,

79 8.2. AUTOMATICKÉ NASAZENÍ MICROSOFT SQL SERVERU 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 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 bit 1 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 Implementace TPM workflow Pro účely provisioningu databáze MS SQL Server 2005 na Windows Server 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í.

80 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 Tento diagram reprezentuje základní posloupnost procesů, která je vykonávána při běhu workflow CST_MSSQL2005_Windows_x64_Installable_Install.wkf 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:

81 8.2. AUTOMATICKÉ NASAZENÍ MICROSOFT SQL SERVERU <device-model name="cstmssql2005winx64_installable" category="software"> <workflow name="cst_mssql2005_windows_x64_installable_install" /> </device-model> 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 Obrázek 8.1: Configuration Template s defaultními parametry Obrázek 8.2: Konfigurace parametrů instalace databáze Microsoft SQL Server 2005

82 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

83 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

84 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 Popis Extension point Subproces PMRDPRUADD Add Server Runbook EXTCSUCC CSTMETNEW PMRDPRUCAN Cancel Project Runbook EXTCSUCC CSTMETSEL PMRDPRUCRT Create Project Runbook EXTCSUCC CSTMETNEW PMRDPRUISW Install Software Runbook EXTSUCCESS CSTMETSEL PMRDPRUMSR Modify Server Runbook EXTCSUCC CSTMETSEL PMRDPRURMS Remove Server Runbook EXTCSUCC CSTMETSEL PMRDPRUSMI Save Image Runbook EXTCSUCC CSTMETSEL Do těchto bodů byly přidány nově vytvořené definice dvou druhů jednoduchých procesů, viz ukázka na obr 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

85 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 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.

86 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:

87 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,,,, /04/14,CUST1,TEAM1,ACCOUNT1,server002,Windows,2,4096,30,20, MSSQL2005 Windows x64,,d,21820

88 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

89 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 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 a obr 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 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

90 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ů 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 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

91 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: 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 = "/server/@name"; String[] data = proxy.dcmselect(dcmquery, parammap); Kompletní dokumentaci nalezneme v infocentru pro TPM 7.2 [64], případně pro TPM 7.1 [63], neboť QLServiceProxy je zároveň zpětně kompatibilní. Pro budoucí účely může být zajímavé i REST API TPM 8.1 [65], které by mohlo ulehčit práci se vzdáleným voláním, neboť struktura REST dotazu svou formou velice připomíná DCM dotaz. V současné době (březen 2012) je ale TPM 8.1 dostupný pouze jako BETA a zatím se neobjevil v žádné IBM cloudové implementaci.

92 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 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 Ú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í 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.

93 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 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 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 Obrázek 10.4: Úvodní startovací obrazovka (splash screen)