VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE FAKULTA INFORMATIKY A STATISTIKY KATEDRA INFORMAČNÍCH TECHNOLOGIÍ
Diplomová práce
Transformace aplikací na Windows Azure
Vypracoval: Bc. Martin David Vedoucí práce: Ing. Libor Gála Rok vypracování: 2011
Čestné prohlášení Prohlašuji, že diplomovou práci na téma „Transformace aplikací na Windows Azure“ jsem vypracoval samostatně. Použitou literaturu a podkladové materiály uvádím v přiloženém seznamu literatury. V Praze dne 28. června 2011
......................................... Bc. Martin David
Poděkování Rád bych na tomto místě poděkoval svému vedoucímu práce, panu Ing. Liboru Gálovi za odborné vedení diplomové práce, cenné náměty a rady při konzultacích. Dále bych rád poděkoval rodině za podporu při celém mém studiu.
Abstrakt Diplomová práce se zabývá problematikou Cloud computingu, konkrétně jeho implementací od Microsoftu, Windows Azure platform. Pro diplomovou práci byly definovány následující cíle, které jsou analyzování a identifikování základních vlastností Cloud computingu se zaměřením na Windows Azure platform, charakterizování klíčových odlišností aplikací v cloudu oproti on-premise aplikacím, formulování doporučení umožňující transformaci stávající aplikace do prostředí Cloud computingu za předpokladu využití platformy Microsoftu, která je dodána jako služba. Hlavním přínosem práce je identifikace klíčových odlišností Windows Azure oproti onpremise řešení. Vytvoření doporučení, jak minimalizovat negativní dopad těchto rozdílů a maximalizovat výhody spojené s využíváním Cloud computingu na platformě Windows Azure.
Klíčová slova Cloud computing, IaaS, PaaS, Windows Azure, SQL Azure, analýza, návrh, transformace, aplikace, best practices
Abstract This diploma thesis deals with Cloud computing, in particular its implementation of Microsoft's Windows Azure platform. The following objectives were defined for the thesis, which is analyzing and identifying the essential characteristics of Cloud computing with a focus on the Windows Azure platform, characterizing the key differences of applications in the cloud than on-premise applications, formulate recommendations for enabling transformation of existing applications into the Microsoft Cloud computing, which is delivered as a service. The main contribution of the work is to identify key differences between Windows Azure and on-premise solution. Creating recommendations to minimize the negative impact of these differences and maximize the benefits associated with the use of Windows Azure Cloud Computing platform.
Keywords Cloud computing, IaaS, PaaS, Windows Azure, SQL Azure, analysis, design, transformation, application, best practices
Citovaná literatura ........................................................................................................ 78
8.
Seznam tabulek ............................................................................................................ 83
9.
Seznam obrázků............................................................................................................ 84
1. Úvod Pro podniky všech velikostí představuje Cloud computing obrovskou příležitost. Jde o příležitost vymanit se z dlouholeté tradice, kdy vynakládáme až 80 procent *Kačmář, a další, 2010+ svého času a rozpočtu jen na udržování stávajícího řešení v chodu a kdy jen malý objem prostředků zbýval na inovace. Cloudové služby umožní zaměřit se více na inovace a běžné činnosti přitom svěřit spolehlivým a nákladově efektivním poskytovatelům. Ne náhodou analytici Gartneru řadí Cloud computing na první místo ve svém žebříčku top 10 strategických technologií pro rok 2011 [Gartner, Inc., 2010]. K dosažení maximální efektivity je ovšem potřeba hodnotit nejen možné přínosy, ale přichystat se na nástup tohoto fenoménu z co nejvíce možných úhlů. Platforma Microsoft Windows Azure je platformou velmi mladou, její služby se neustále vyvíjí. Během psaní diplomové práce vzniklo na této platformě mnoho nových služeb, které před začátkem práce ještě ani neexistovaly. Změny v této oblasti jsou velmi dynamické a vyžadují schopnost se velmi rychle učit, sledovat nové trendy, technologie a neustále se snažit čerpat nové znalosti. Toto tvrzení obecně platí pro celé IT a pro oblast Cloud computingu zvláště. Na oblast Cloud computingu a především platformy Windows Azure se zaměřím z důvodu, že jako Microsoft Certified Professional Developer vyvíjím již rok a půl webovou aplikaci na platformě .NET, která svým zaměřením a charakterem splňuje vlastnosti aplikací, jenž jsou výhodné provozovat na Windows Azure. Tato aplikace byla ve své iterační fázi vývoje úspěšně transformována na PaaS a přes Microsoft Platform Ready portál obdržela povolení nést označení „Powered by Windows Azure“. Důvodem migrace aplikace byla především snaha o nákladově efektivní společnost a možnost velmi rychlého růstu. Svoje teoretické i praktické znalosti z této činnosti se snažím ještě více zhodnotit studováním odborné literatury a převážně sledováním vývojářských blogů jednotlivých týmů Microsoftu, které mají za úkol přinášet nové služby na Windows Azure. Tyto nabyté znalosti se snažím předat v této diplomové práci. Cílem práce je na základě analýzy stanovit doporučení umožňující transformaci stávající aplikace do prostředí Cloud computingu za předpokladu využití platformy Microsoft, která je dodána jako služba. Práci člením do pěti kapitol. První kapitola je úvodní. Vymezuje základní problém a definuje cíle diplomové práce. Druhá kapitola se obecně zabývá Cloud computingem, přináší jeho definici, snaží se rozčlenit jeho služby a jednotlivé typy. Dále je v této kapitole analyzován a kategorizován původ Cloud computingu, který spatřuje mezi propojením mnoha historicky mladších technologií, zejména pro Cloud computing shledává značný význam virtualizace, o které je také zmínka v této kapitole. Dále zde najdeme stručný 7
přehled ostatních poskytovatelů cloud služeb. Třetí kapitola přináší teoretické poznatky o platformě Microsoft Windows Azure a všech jejich částí, které jsou Compute, Storage, AppFabric a SQL Azure. Ve čtvrté kapitole najdeme praktické poznatky o odlišnosti aplikací v cloudu oproti on-premise. Na základě ekonomické analýzy se podíváme, zda se vyplatí provozovat konkrétní aplikaci na Windows Azure. Pomocí technické analýzy zjistíme, zda je možné konkrétní aplikaci na zmíněné platformě provozovat. V kapitole se seznámíme se základními odlištnosmi při vývoji, nasazení a provozování aplikace. Tato kapitola obsahuje doporučení umožňující transformaci stávající aplikace do prostředí Cloud computingu za předpokladu využití PaaS Microsoft Windows Azure. V závěrečné páté kapitole práci shrnu a vyhodnotím, zda byly naplněny cíle práce, tak jak byly definovány. Jelikož se v uvedené problematice objevuje celá řada zkratek a anglosaských názvů, na konci práce uvádím terminologický slovník, který celou řadu pojmů objasňuje, pokud není daný termín vysvětlen již přímo v textu.
8
2. Cloud computing Cloud computing je sdílení hardwarových i softwarových prostředků pomocí internetu. Dříve buzzword, dnes již realita. Je to služba, která umožňuje outsoursovat podnikovou informatiku (HW, SW a lidé) *Pour, a další, 2009+ na základě SLA s dodavatelem, který si účtuje jen skutečně využité prostředky.
2.1. Kořeny Cloud computingu Cloud computing není technologie, která by se náhle samostatně objevila a zcela nezávisle vznikla. Bylo zapotřebí určité technologické podhoubí, které umožnilo vznik Cloud computingu. Technologie, jenž jsou nutné k jeho vzniku, jsou především tyto: HW virtualizace, vícejádrové procesory, Grid computing, SOA architektura, webové služby, Web 2.0 a inteligentní systémy. Tyto technologie byly rozděleny do čtyř základních skupin: hardware, distribuované výpočty, internetové technologie a řízení systémů *Buyya, a další, 2011], tak jak ilustruje následující obrázek.
Jelikož je Cloud computing vázán na více technologií a s těmito technologiemi je provázán, není možné zcela přesně říct, kde Cloud computing začíná a kde končí. Přesto je potřeba tento pojem uchopit, proto budeme vycházet z definice, která je uvedena v kapitole 2.2 Charakteristika a modely Cloud computingu. Podle mého názoru a především dle příspěvku více prezidenta společnosti Gartner Inc. [Bittman, 2009] je hlavním pilířem Cloud computingu ze zmiňovaných technologií především virtualizace, proto nalezneme o této technologii v následujících odstavcích několik základních informací. 9
Vzhledem ke stále se zvyšujícím výkonům serverů, ale i nárokům na služby a jejich dostupnost, stoupají nároky na správu systémů a narůstá počet serverů, které jsou jednoúčelové a zdaleka nevyužívají svůj výkon. Tento trend způsobil ohromné množství serverů, které jsou využívané jen na velmi malé procento svého potenciálu, jejich utilizace bývá zpravidla nižší než 20%. K řešení tohoto problému nastoupila virtualizace, která umožní na jeden server umístit mnoho operačních systémů a aplikací (konsolidace serverů), které jsou od sebe izolované, čímž se zvýší vytížení serverů a sníží jejich potřebný počet. Tímto je možné dosáhnout nejenom snížení nákladů na nákup HW, ale i nákladů na provoz. Další výhodou virtualizace je také snadnejší správa, zálohování a migrace z jednoho HW na druhý. Pro přiblížení pojmu virtualizace, uvádím sedm vrstev (aspektů) virtualizace, tak jak bylo publikováno v odborné literatuře *Ruest, a další, 2010+: 1. Serverová virtualizace – oddělení hardwaru a operačního systému umožňuje na jednom fyzickém zařízení (serveru) spouštět více logických zařízení. Na jednom serveru tak funguje více operačních systémů a více aplikací. Je tedy porušen dosavadní zvyk z dřívějška, kdy jeden fyzický server = jeden operační systém. 2. Virtualizace desktopů – oddělení uživatelských aplikací, dat a nastavení od jednoho konkrétního hardwaru (v tomto případě desktopu). 3. Virtualizace uložišť – prakticky se jedná o sloučení fyzických uložišť (zpravidla harddisků) do jednoho homogenního celku, někdy označovaného také jako fond uložišť. 4. Virtualizace aplikací – umožňuje oddělení konkrétní aplikace od operačního systému. Aplikaci je tak možné spouštět na libovolném typu i verzi operačního systému bez dopadu na funkčnost aplikace. Zároveň je zaručena ochrana operačního systému proti nekorektním činnostem aplikace, které by mohly zapříčinit poškození systému. 5. Virtualizace sítí – umožňuje například vytvářet virtuální lokální sítě (VLAN) a rozdělit šířku pásma na nezávislé kanály. Nejznámější formou tohoto typu virtualizace je bezesporu vytváření virtuálních privátních sítí (VPN). 6. Správa virtualizace – komplexní správa datového centra, všech jeho zdrojů a nabídky virtuálních služeb koncovým uživatelům. 7. Virtualizace prezentační vrstvy – dříve známa především v podobě terminálových služeb, které umožňují vzdálený přístup a správu virtuálních zátěží. Spíše než použití tohoto typu virtualizace je dnes upřednostňována virtualizace desktopů. Virtualizace umožňuje čtyři z pěti atributů poskytovatele tzv. Cloud computingu. Jeho činnost je založena na servisním přístupu, její výsledky jsou stupňovatelné, uživatelsky měřitelné, pružné, a sdílené. Virtualizace není jedinou cestou k tzv. Cloud computingu
10
(sdílení hardwaru a softwaru pomocí sítě), ale bude jednou z nejdůležitějších a běžných nástupišť k jeho zavedení. *Váša, 2010+ Virtualizace serverů je pro velké podniky jednou z priorit a během příštích několika let se stane prioritou i pro ty menší. Zpočátku se společnosti dívají na virtualizaci jako na efektivní technologii pro konsolidaci – zvyšující míry využití a snižující výdaje na kapitál, energii či chlazení. Pokud je dobře provedená, pak to platí. *Váša, 2010+ Dle společnosti Forrester *Staten, a další, 2009+ existují čtyři fáze virtualizační vyspělosti. 1. Fáze – aklimatizace
Zvyknutí si na virtualizaci jako na koncept a nástroj
Zavedení pro testování/vývoj
Zavedení v odděleních, která nejsou pro firmu klíčová
Částečné zavedení ve výrobě – ale takticky
Žádná změna provozních procesů
Limitované zavádění virtualizačních nástrojů
2. Fáze – strategická konsolidace
Komfortní s konceptem, používáním, vyspělostí, stabilitou
Myšlenkový posun od serverů k virtuálním strojům
Rozšíření nasazení do dalších výrobních oblastí
Začátek nasazení pro oddělení, která jsou pro firmu klíčová
Bolestivý přechod od rozpínajících se serverů k řízení životního cyklu virtuálního serveru
Experimenty s „živou“ migrací a nástroji správy zdrojů
3. Fáze – zlepšování procesů
Využívání „živé“ migrace, začíná důvěřovat nástrojům správy zdrojů
Může se zvýšit míra využití?
Nasazení do oblastí, které jsou pro firmu klíčové
Začína rozlišovat aplikace na prioritní a neprioritní
Vývoj nových provozních schopností 11
Další vylepšování procesů
4. Fáze – sdružování zdrojů a automatizace
Důvěra v nástroje správy zdrojů
Zavádění provozních postupů pro automatizaci
Občasné nasazení pro strategicky klíčová oddělení
Sdružování zdrojů a vývoj interních cloudů
Účtování nákladů/sledování využití
Zaměření na SLA a QoS
2.2. Charakteristika a modely Cloud computingu Definic Cloud computingu existuje celá řada, ale dle mého průzkumu většina společností cituje zejména definici, kterou vydal NIST (Národní institut standardů a technologie) *Mell, a další, 2011+ při ministerstvu obchodu USA. Následující definice a charakteristiky cloudu jsem uvedl přesně tak, jak byly vydány laboratoří měřících standardů v NIST, jsou však částečně doplněny o další informace z literatury. „Cloud computing je model umožňující pohodlný přístup ke sdíleným konfigurovatelným výpočetním prostředkům (sítě, servery, datová úložiště, aplikace a služby) odkudkoliv, tzv. on demand. Tyto prostředky mohou být využívány nebo opouštěny s minimálním úsilím v řízení a komunikaci s dodavatem služby. Model Cloud computingu zvyšuje dostupnost. Je tvořen pěti základními charakteristikami, třemi modely služeb a čtyřmi modely nasazení.“ *Mell, a další, 2011+
2.2.1. Charakteristika Cloud computingu Tyto následující charakteristiky Cloud computingu ještě lépe objasňují jeho definici:
Samoobslužný systém – zákazník může měnit úroveň poskytovaných služeb, např. výpočetní výkon kdykoliv bez nutnosti zásahu technika provozovatele služby.
Všestranný síťový přístup – služby jsou dostupné po internetu a přístupné skrz standardní mechanismy, které umožňují použití tlustých i tenkých klientů (mobilních telefonů, notebooků a PDA).
Sdílení zdrojů – poskytovatel služby sdílí zdroje cloudu mezi několika uživateli na bázi tzv. multi-tenancy modelu1. Odlišné fyzické a virtuální zdroje jsou dynamicky přidělovány a odebírány dle požadavku zákazníka. Pravidlem je neurčitost přesné
1
Multi-tenancy model je výpočetní prostředí, které je sdíleno více skupinami či uživateli (tzv. nájemníky), avšak zajišťuje jejich vzájemné oddělení a izolaci, aby si uživatelé nebyli vědomi ostatních nájemníků a neměli přístup k jejich informacím a prostředkům.
12
pozice virtuálního serveru v datovém centru poskytovatele. Zákazník si smí určit pouze nejvyšší úrovně pozice svého cloudu (světadíl, stát a v některých případech i datové centrum). Sdílí se procesorový čas, diskový prostor, operační paměť a síťová konektivita.
Okamžitá elasticita a škálovatelnost – zákazník může určit maximální výkon cloudu sám a omezit tak výdaje nebo ponechat služby nastavené na automatické škálování, které bude přizpůsobovat výkon dle aktuální zátěže. Tyto změny se projeví téměř okamžitě.
Naměřené služby – systém automaticky kontroluje a optimalizuje využívané zdroje, tyto zdroje obvykle účtuje metodou pay-as-you-go, Zdroje mohou být monitorovány, kontrolovány a reportovány tak, aby umožnily transparentnost, jak pro poskytovatele, tak i pro zákazníka využívaných služeb.
2.2.2. Modely poskytování služeb
Cloud Infrastructure as a Service (IaaS) – v modelu IaaS jsou zákazníkovi přímo poskytovány výpočetní zdroje, na které si může nasadit libovolný software, včetně operačního systému a aplikací. Jedinou věcí, kterou nemá pod kontrolou, ale o kterou se zároveň nemusí starat, je hardwarová infrastruktura. *Mell, a další, 2011]
Cloud Platform as a Service (PaaS) – v tomto modelu může zákazník nasadit a provozovat svoji aplikaci, vytvořenou v programovacím jazyce, který je podporován poskytovatelem služby, do cloudu. Zákazník nenastavuje ani nekontroluje infrastrukturu (síť, servery, operační systémy, datová úložiště), ale má kontrolu nad svojí nasazenou aplikací a také nad možnou konfigurací aplikačního prostředí. *Mell, a další, 2011+
Cloud Software as a Service (SaaS) – v modelu SaaS jsou zákazníkovi poskytovány již běžící aplikace nasazené v infrastruktuře cloudu poskytovatele služby. Tyto služby jsou dostupné z heterogenních klientských aplikací přes rozhraní běžícím na tlustém nebo tenkém klientovi. Zákazník nenastavuje ani nekontroluje infrastrukturu (síť, servery, operační systémy, datová úložiště, na které jsou aplikace provozovány. Jediné nastavení, které může měnit, je vlastní přizpůsobení těchto aplikací. *Mell, a další, 2011+
Následující obrázek č. 2 umožňuje lépe pochopit modely poskytování služeb (SaaS, PaaS a IaaS), ke kterým přidává ještě pohled na tradiční IT2. U jednotlivých pohledů je vyznačena míra vlastní zodpovědnosti (modrá barva) za jednotlivé vrstvy. Vrstvy poskytované jako služba jsou šedivé. 2
Tradiční IT je dále v práci označováno termínem on-premise. Pod tímto pojmem rozumíme aplikace nebo služby nasazené a řízené společností v jejich vlastních prostorách. [Redkar, 2010] Opakem jsou aplikace nebo služby provozované v cloudu.
13
Obrázek 2: Modely poskytování služeb [Chou, 2011]
2.2.3. Modely nasazení Cloud computing můžeme dále rozčlenit dle modelu nasazení na následující:
Privátní cloud – infrastruktura cloudu je čistě pod kontrolou vlastní organizace. Může být spravována buď samotnou organizací nebo jejím dodavatelem.
Komunitní cloud – infrastrutura cloudu je sdílena a spravována skupinou společností nebo komunitou, která má společné zájmy a cíle (mise, požadavky na bezpečnost, korporátní pravidla compliance, atd.). Tento cloud si mohou spravovat sami nebo je spravován za ně dodavatelem. Příkladem komunitního cloudu je např. Open Cirrus, který byl vytvořen k výzkumu a rozvoji Cloud computingu, společnostmi HP, Intel a Yahoo!.
Veřejný cloud – infrastruktura cloudu je vlastněna organizací, která jí dále prodává ostatním společnostem a tato služba bývá dostupná i široké veřejnosti.
Hybridní cloud – infrastruktura cloudu je složena ze dvou a více cloudů (privátním, komunitním nebo veřejným), tyto cloudy jsou vzájemně propojeny standardizovanou nebo proprietární technologií, která umožňuje vzájemnou přenositelnost a vyvažování zátěže (load balancing) mezi jednotlivými cloudy. Navenek se tento hybridní cloud tváří jako jedna entita (jeden cloud).
V případě společnosti Microsoft do privátního cloudu patří např. produkty Hyper-V. Díky této technologii bychom si mohli vytvořit privátní cloud. Dalším produktem je např. Windows Intune, díky kterému můžeme spravovat počítače. Windows Azure, na který je zaměřena tato diplomová práce patří do veřejného cloudu. 14
Hyper-V je nová generace virtualizační technologie přímo svázaná s operačním systémemem. Vyžaduje speciální hardware (procesor s HW podporou virtualizace). Jedná se tedy o opravdovou virtualizaci, nikoliv o emulaci. Technologie Hyper-V je součástí Windows Server 2008. Windows Intune je online služba pro správu počítačů, která běží v cloudu. Cílem Windows Intune je zjednodušit správu počítačů a snížit náklady. Představme si následující situaci: středně velká firma podnikající v libovolném odvětví spravuje IT vlastními prostředky, tzn. má vlastní IT oddělení, jehož úkolem je zajištění bezchybného chodu celé IT infrastruktury. Jejich náplní práce ve velmi zjednodušeném pohledu (na úrovni jednotlivých pracovních stanic) může být: přidávání nových pracovních stanic, instalování aktualizací OS, nastavování firewallu, nastavování přístupu do podnikové sítě a práv, kontrolování nainstalovaných aplikací a jejich aktualizace, kontrolování zbývajících dostupných licencí, řešení pádu aplikací, nastavení a kontrola automatického zálohování, konfigurace bezpečnostních politik, atd. Chod těchto služeb vyžaduje fyzicky provozování jednoho a více vlastních serverů, na kterých běží např. Windows Server Update Services a další služby, které jsou zapotřebí pro management pracovních stanic. Pokud tyto servery přesuneme z naší serverovny a umístíme do datacentra Microsoftu, dostáváme Windows Intune. Ve chvíli, kdy začneme využívat Windows Intune děláme důležitý krok k outsorsování managementu pracovních stanic i celé správy podnikového IT specializovanou firmou. Výhodou jsou predikovatelné náklady na provoz serverů zabezpečujících správu pracovních stanic. Zároveň se stává správa IT efektivnější tím, že velkou část servisních zásahů je možné dělat vzdáleně, bez nutnosti fyzické přítomnosti ve firmě, jejíž IT spravujeme. Základním požadavkem k fungování správy daného počítače přes Windows Intune je přítomnost nainstalovaného agenta, což je služba běžící na pozadí operačního systému, jejíž cílem je monitoring daného pc a vykonávání příkazů správcem IT. Windows Intune Agent může být instalován na Windows XP Professional SP3 a novějším OS od Microsoftu, vždy ale musí jít minimálně o edice určené pro podnikové použití, tedy Professional, případně Business edice u Windows Vista. Microsoft garantuje u Windows Intune dostupnost služby 99,9%. Značnou výhodou Windows Intune je fakt, že za každou licenci Windows Intune získáváme licenční právo na upgrade na Windows 7 Enterprise. Tímto lze velice jednoduše, bez vysokých finančních nároků, sjednotit celé firemní prostředí na nejnovější verzi Windows a využít tak dalších benefitů týkajících se bezpečnosti a uživatelského komfortu: intuitivní uživatelské rozhraní, pokročilé vyhledávání, šifrování BitLocker a další.
15
Windows Intune stojí 11 EUR na počítač za měsíc. Tato cena se může zdát na první pohled vysoká, ale při stanovení nákladů na nákup serverů, jejich provoz, serverových licencí, licencí pro antimalware a dalších nákladů vychází minimálně srovnatelná s tradičním řešením. Využití Windows Intune začíná být velmi relevantní ve chvíli, kdy potřebujeme spravovat počítače externích zaměstnanců firmy, případně zakládáme novou pobočku nebo integrujeme do stávajících procesů správy IT společnost po fůzi nebo akvizici. Výhody se uplatní i v dalších scénářích, kdy je potřeba velmi pružně a především rychle reagovat na situaci vyžadující správu klientských počítačů. Díky umístění Windows Intune v cloudu je služba k dispozici kdykoliv odkudkoliv, stačí běžné připojení k internetu. U firem s více pobočkami tak není nutné řešit serverovou topologii (v každé pobočce lokální WSUS).
2.3. Základní rysy aplikací vhodných pro provozování v cloudu Tato kapitola se snaží nastínit a obecně definovat charakteristiky aplikací, jenž jsou vhodné pro své vlastnosti, aby byly provozovány v cloudu. Tento model zjednodušuje realitu, aby umožnil rychlejší pohled na aplikace, jejichž základní rysy nasvědčují k optimalizaci při provozování těchto aplikací v cloudu. Stanovením, zda je vhodné konkrétní aplikaci provozovat v cloudu nebo ne, se zabývá praktická část této práce v kapitole 4.1 Ekonomická analýza výhodnosti přechodu na Windows Azure a v kapitole 4.2 Technická analýza kompatibility aplikace s Windows Azure. Zde jsou slibované základní rysy aplikací vhodných pro provozování v cloudu:
3
Aplikace s potřebou masivního škálování – webové aplikace obsluhující vysoké množství klientů, např. elektronické obchody, které v době sezónnosti (Vánoce, Valentýn, atp.) mohou potřebovat reagovat na velké množství http requestů
Aplikace vyžadující vysokou dostupnost – LOB aplikace3 pro mobilní zaměstnance
Aplikace s různým zatížením – rezervační systémy, účetní systémy, aplikace na tvorbu rozvrhu
Aplikace s krátkou nebo neznámou životností – aplikace určené pro marketingové kampaně
Aplikace vyžadující paralelní zpracování – aplikace pro finanční modelování
Aplikace s rychlým nárůstem a ústupem – startup projekty
Line of business aplikace jsou firemní aplikace zajišťující podporu konkrétních obchodních aktivit.
16
Aplikace, které nezapadají do firemního IT – aplikace vyžadující technologie, které jsou odlišné od stávajících provozovaných ve firmě
Aplikace benefitující z externího úložiště dat – archivace dat, aplikace distribuující velké objemy dat (mediální obsah, mapové podklady)
Aplikace s širokou geografickou dostupností – jednotné aplikace pro pobočky v různých regionech
Prodej a distribuce dat – aplikace v modelu Data as a service – statistické informace, podklady GIS, počasí
K ještě rychlejšímu pohledu a pochopení základních rysů aplikací vhodných pro provozování v cloudu slouží následující obrázek.
Vzory zátěží optimálních pro Cloud “Rychlý růst“ Zatížení
Zatížení
“Zapnuto a Vypnuto“ Perioda nečinno sti
Čas
Čas
“Nepředpokládané špičky“
“Předpokládané špičky“ Zatížení
Zatížení
Průměrné zatížení
využití
Průměrné
Průměrné zatížení
Čas
Průměrné zatížení
Čas
Obrázek 3: Vzory zátěží optimálních pro cloud *Juřek, a další, 2010+
2.4. Další poskytovatelé cloud služeb V této kapitole je velmi stručný přehled dalších významných poskytovatelů cloud služeb, které se dostali do TOP 5 dle Cloud computing Journal, [Depena, 2010] se zaměřením především na služby podobné Windows Azure, tedy PaaS, ale i služeb dalších.
17
V následujích kapitolách se dozvíme především o Cloud computingu od společností: Amazon, Google, SalesForce.com a Rackspace. Neznamená to však že by ostatní společnosti neposkytovali Cloud computing služby. V podstatě všechny významné IT společnosti, ať již zaměřené na SW nebo HW již Cloud computing služby nabízí nebo v blízké době nabízet budou. Je to především společnost Cisco [Cisco Systems, Inc, 2011], která je hlavním poskytovatelem síťových prvků, na kterých běží velká část Internetu. Další velkou společností je HP, která se chystá v brzké době spustit také služby v oblasti Cloud computingu, totéž platí i pro IBM. Samozřejmě nesmím zapomenout na jednoho z největších poskytovatelů ERP a dalších podnikových systémů, společnost SAP, která má svůj SW z velké části přepsán *Loo, a další, 2010+ tak, aby byl poskytován jako služba po Internetu, tedy počítá s tím, že bude „Cloud computing ready“.
2.4.1. Amazon Amazon Web Services bylo spuštěno již v červenci roku 2002 [Amazon.com Inc., 2011], ale hlavní služba Amazon EC2 byla spuštěna až o několik let později. Údajně Amazon tuto službu vytvořil kvůli velkému nadbytku své výpočetní síly, která musela být dimenzována na provoz vlastního celosvětově známého internetového businessu i ve špičce. Rozdíl mezi nejnižším a nejvyšším zatížením dělá až několik desítek procent, což při tak obrovské kapacitě HW prostředků, kterými Amazon disponuje, dělá desítky milionů korun ročně. Tento HW (peníze) jsou v podstatě neefektivně využity. Z tohoto důvodu Amazon začal nabízet svůj HW i ostatním společnostem jako službu. Amazon Elastic Compute Cloud (Amazon EC2) je služba, která patří do rodiny Amazon Web Services (AWS). Bývá řazena do kategorie cloud služeb IaaS. Často bývá konfrontována právě s Microsoft Windows Azure Compute a Google AppEngine. Vznikla však dříve a to na konci roku 2006. Má všechny znaky Cloud computingu, tak jak je definoval *Mell, a další, 2011+ NIST. Tato služba zákazníkovi umožňuje si pronajmout HW od Amazonu a nainstalovat předem předpřipravený OS (Windows Server, ale především různé distribuce Linuxu, Red Hat, Fedora, Suse, Ubuntu, Debian, atd.), který je mu účtován po hodině, tak jak je standardně u těchto služeb zvykem. Amazon Simple Storage Service (Amazon S3) je služba, která nabízí možnost ukládat a případně distribuovat data. Je velmi podobná službě Windows Azure Storage. Služba je účtována za uložený objem dat, za přenesená data do a ven z cloudu a za transakce. Samozřejmostí je Service Level Agreement a vysoká životnost dat 99,999999% dostupnost dat 99,99%. K datům je přistupováno přes REST, případně SOAP. Amazon Relational Database Service (Amazon RDS) je služba, která je podobná SQL Azure s rozdílem že místo SŘBD MS SQL Serveru je využito MySQL nebo Oracle.
18
2.4.2. Google AppEngine Google AppEngine je služba na bázi PaaS, kterou společnost Google spustila v roce 2008. Služba je orientována především na programátory v Pythonu, Ruby nebo Javě. Oproti Windows Azure nebo Amazonu Web Services mi přijde méně robustní, nabízí daleko menší množství služeb a škála projektů pro které se hodí, bude daleko užší. Na druhou stranu je výhodou, že pokud projekt nepřesahuje určité limity, které obvykle začínající a vyvíjející projekt nepřesáhne, pak je hostování na AppEngine s určitými omezeními zcela zdarma. Nevýhodou je zde nepřítomnost relační databáze. K datům se přistupuje nerelačně přes DataStore. Zde vidím určitou podobu s Windows Azure Storage Table. Dá se očekávat, že v budoucnu toto omezení bude odstraněno hostovaným SŘBD MySQL. Stejně tak i absence podpory jazyka PHP, který není bez určitých workaroundů možné využít.
2.4.3. SalesForce.com a Force.com SalesForce.com je internetová společnost známá především díky kvalitnímu a rychle se rozšiřujícímu systému pro řízení vztahů se zákazníky (CRM), jenž již delší dobu nabízí jako SaaS.
2.4.4. Rackspace Rackspace je společnost, která nabízí hostingové služby, dříve především web hosting, následně tzv. managed hosting4, dnes již přechází na poskytování služeb v cloudu. Na rozdíl od Windows Azure, Rackspace poskytuje sluby zejména z oblasti IaaS. V této oblasti patří mezi špičku, dle [Gartner, Inc., 2010] Gartner Magic Quadrantu. V oblasti cloudu Rackspace nabízí následující tři služby: Cloud Servers, Cloud Files a Cloud Sites. Cloud Servers je služba pronajímání serverů na bázi SLA, tedy standardní IaaS. Cloud Files je služba pronajímání úložiště dat a zároveň poskytování služby Content Delivery Network (CDN) po síti, kterou vlastní a spravuje společnost Akamai, která se na CDN specializuje. CDN od Akamai využívá celá řada velkých společností mezi nimi např. i Microsoft. V neposlední řadě Cloud Sites, který je nejblíž Windows Azure, jedná se tedy o PaaS.
4
Managed hosting je v podstatě dedikovaný server neboli server, který je celý výhradně určen jednomu zákazníkovi, ale na rozdíl od dedikovaného hostingu je spravován poskytovatelem služby.
19
3. Microsoft Windows Azure Platform Používání počítačových systémů v cloudu má mnoho dobrých důvodů. Proč bychom měli nakupovat vlastní počítače a starat se o ně, když můžeme plně využít množství serverů, které jsou k dispozici na Internetu? [Chappel, 2010] V mnoha případech jak kód, tak i data aplikací mohou existovat v cloudu a využívat tak systém, který spravuje a udržuje někdo jiný. V jiných případech může aplikace běžet v lokálních firemních počítačích, ale data ukládat do cloudu nebo využívat jiných služeb infrastruktury cloudu. Používání prostředků cloudu je rozmanité, ale v každém případě může pozitivním způsobem ovlivnit náš svět. Aplikace může běžet v cloudu, může používat služby poskytované cloudem, či obojí. V každém případě však potřebuje určitý druh aplikační platformy. Z širšího pohledu představuje aplikační platforma cokoli, co poskytuje vývojářům služby pro vytváření aplikací či ukládání dat. [Chappel, 2010] V lokálním světě s Windows jsou to technologie jako Windows Server nebo SQL Server. Mají-li aplikace využívat cloud, musí existovat rovněž aplikační platforma pro cloud. Takovouto platformu poskytuje Microsoft Windows Azure Platform. Jde o skupinu cloudových technologií, z nichž každá poskytuje vývojářům aplikací konkrétní sadu služeb. Na následujícím obrázku jsou znázorněny komponenty této platformy.
Obrázek 4: Architektura Windows Azure Platform [Microsoft Corp., 2011]
Obrázek č. 4 znázorňuje všechny stavební bloky Windows Azure Platform, tyto služby je možné spravovat přes Management portál. Obrázek můžeme číst dvěma způsoby, buď podle barev, nebo podle sloupců.
20
Barvy nám nabízejí pohled na části, které využívají stejné SDK5. Jsou to především části žluté barvy: Compute, Storage, Connect a CDN, na které je možné aplikace programovat přes Windows Azure SDK. Pokud bychom k těmto částem ještě přidali část s azurovou barvou, představující SQL Azure, dostali bychom dle mého názoru nejzákladnější a nejpoužívanější služby Windows Azure. K SQL Azure se přistupuje téměř shodně jako k MS SQL Serveru, tzn. např. přes ADO.NET6 nebo LINQ7. Části zelené barvy: AppFabric Service Bus, AppFabric Integration, AppFabric Caching a AppFabric Access Control jsou integrovány přes AppFabric SDK. V neposlední řadě barva šedivá představuje novou službu Windows Azure Marketplace, jehož SDK je ve vývojové fázi. Pokud budeme na schéma nahlížet po sloupcích, dostaneme pohled na Windows Azure po jednotlivých funkčních celcích: Compute, Storage, Networking, Identity management, Marketplace a jejich jednotlivé části. Práce je dále členěna především po těchto jednotlivých službách. Jedinou službou, kterou jsem bohužel vynechal v následujících kapitolách, bylo Windows Azure Connect. Důvodem vynechání bylo, že tato služba byla v beta verzi uvedena nově, až před těsným odevzdáním diplomové práce. Proto jsem ji bohužel nestačil vyzkoušet. Cílem této služby je propojení aplikací běžích na Windows Azure s on-premise aplikacemi.
3.1. Windows Azure Compute Windows Azure Compute je hostovaný virtuální operační systém pro provoz aplikací nabízený jako služba. Zároveň je to klíčový stavební blok platformy. Umožňuje běh a výpočet aplikací v cloudu. Je rozdělen na tři části: Web role, Worker role a VM role. Každá část je určena pro jiný způsob využití. Technicky je každá tato role hostována na Windows Serveru 2008 R2 64 bit s nainstalovaným .NET 4.0 frameworkem. Je možné hostovat i jiné aplikace než aplikace, které jsou vytvořeny pomocí technologií Microsoftu. Základním prvkem Cloud computingu je škálovatelnost, zde je škálovatelnost realizována způsobem, který uživateli služby umožňuje zvolit libovolný počet instancí již zmíněných rolí a jejich velikost. Velikostí se zde myslí viz Tabulka 1, velikost pevného disku a především výpočetní výkon, jež se skládá z výkonu procesoru, velikosti operační paměti a propustnosti. Uživatel služby samozřejmě může kdykoliv daný počet rolí (viz podkapitoly Web, Worker a VM role) a jejich velikost zvýšit či snížit. Zjednodušeně řečeno, zvolený celkový výpočetní výkon se rovná počtu instancí daných rolí a jejich velikostí. Microsoft garantuje vysokou dostupnost služby v případě, že je splněna podmínka minimálního počtu instancí dané role, rovna počtu dvou a vyšší. V případě výpadku je role automaticky 5
SDK je soubor základních nástrojů pro vývoj aplikací. Obvykle SDK představuje balík knihoven funkcí, ukázkových příkladů a dokumentace. 6 ADO.NET je základní část .NET Frameworku, již od verze 1.1, která umožňuje přistupovat konzistentním způsobem k datovým zdrojům a službám, které jsou dostupné přes OLE DB a XML. 7 LINQ je také základní součástí .NET Frameworku, ale až od verze 3.0. Je to integrovaný jazyk pro dotazování, který přistupuje k datům objektovým způsobem, na rozdíl od jazyka SQL. Výhodou je jeho obecnost, která umožňuje jeho rozšiřování. K základním funkcionalitám např. LINQ to Objects, LINQ to SQL, LINQ to XML, existuje ještě celá řada rozšíření, např. LINQ to Twitter, LINQ to Ebay, LINQ to Amazon, atd.
21
restartována. Pokud ani poté neodpovídá, aplikace je taktéž automaticky přesunuta na jiný server. Velikost instance Velmi malá (XS) Malá (S) Střední (M) Velká (L) Velmi velká (XL)
CPU
RAM
HDD
Propustnost8
1 GHz 1,6 GHz 2 x 1,6 GHz 4 x 1,6 GHz 8 x 1,6 GHz
768 MB 1,75 GB 3,5 GB 7 GB 14 GB
20 GB 225 GB 490 GB 1 TB 2 TB
Nízká Průměrná Vysoká Vysoká Vysoká
Tabulka 1: Velikost jednotlivých instancí Azure Compute
3.1.1. Web Role Web role slouží pro hostování webových aplikací (typicky ASP.NET WebForms nebo ASP.NET MVC9) a webových služeb (WCF10), které pro svůj běh vyžadují webový server, konkrétně se jedná o IIS7.5. V případě přítomnosti modulu FastCGI je možné provozovat i aplikace naprogramované v jazycích Java, PHP, Ruby on Rails a dalších. Také je možné doisntalovat DBMS (SŘBD) MySQL, aplikační server Tomcat. Je potřeba mít na paměti, že se jedná o tzv. nestavové servery tzn., že pro ukládání dat je potřeba zvolit některou z podporovaných metod hostovaných v cloudu, např. Windows Azure Storage nebo DBMS SQL Azure, či vlastní on-premise řešení.
3.1.2. Worker Role Worker role jsou využívány pro aplikace, které zpracovávají úlohy na pozadí. Worker role se velmi podobají Windows Service, službám, které běží na pozadí operačního systému Windows. Worker role má definovány tři základní metody: OnStart(), OnStop() a Run(). První metoda slouží pro inicializační příkazy, druhá pro uvolnění zdrojů (úklid po aplikaci) a třetí pro běh samotné aplikace – nachází se v ní aplikační logika, která je obvykle obsažena v nekonečném cyklu, např. while(true) cyklus. Ve chvíli kdy by tento cyklus skončil, dojde k recyklaci worker role neboli k jejímu ukončení. Pro ukládání dat je potřeba využít jedno z persistentních datových úložišť, tak jako u Web role Windows Azure Storage nebo SQL Azure.
3.1.3. VM Role VM role je novinka, kterou Microsoft nedávno uvedl v beta verzi. VM role se částečně vymyká z dosavadního modelu PaaS, pod který spadá Windows Azure Platform a spíše se blíží modelu IaaS. Jde o službu, která nabízí možnost provozovat v cloudu aplikace, které zatím nejsou transformovány a uzpůsobeny tak, aby běžely v jedné z předchozích dvou 8
Propustnost se skládá z garantované síťové konektivity, výkonnosti disků, rychlosti sběrnice, atd. Pokud je na daném fyzickém serveru nevyužitá kapacita, tato hodnota se může pozitivně lišit (platí zejména pro garantovanou síťovou konektivitu). 9 ASP.NET MVC je součástí .NET Frameworku, který umožňuje vytvářet webové aplikace dle návrhového vzoru model-view-controller. Více informací zde: [Mahtab, 2011] 10 WCF (Windows Communication Foundation) je API obsažené v .NET Frameworku, které umožňuje vytvářet servisně orientované aplikace.
22
rolí. Aplikace jsou nasazovány zároveň s operačním systémem v podobě virtuálního obrazu disku VHD. Cílem je urychlit přechod z on-premise řešení do cloudu. Je potřeba vidět tyto výhody současně i s jejich stránkami, které přinášejí výzvu. Uživatel VM role se musí sám starat o aktualizaci systému, zálohování a monitorování, což sebou přináší další náklady. V praxi se VM role využívá, pokud nastane alespoň jedna z následujících situací. Zaprvé potřebuje instalovat aplikaci, jejíž instalace trvá velmi dlouho. Zadruhé instalujeme aplikaci, která je náchylná k chybám, za třetí instalujeme aplikaci, jenž vyžaduje interakci uživatele nebo potřebujeme provozovat aplikaci, kterou nemůžeme nasadit na předchozí zmíněné role. Obvykle si vystačíme z Web nebo Worker rolí.
3.2. Windows Azure Storage Windows Azure Storage je jedním ze základních pilířů Windows Azure, který se stará o skladování dat. Nemá téměř žádné limity škálovatelnosti dat, na rozdíl od SQL Azure, ale oproti němu neobsahuje pokročilé nástroje relačních databází (relace mezi daty, sekundární indexy, uložené procedury, funkce, triggery, atp.). Můžeme do něj ukládat různorodé datové typy. Konkrétně je Azure Storage rozděleno do čtyř částí na Table, Blob, Drive a Queue. Každá tato část má svoje specifikum a je určena k odlišnému způsobu využití. Zároveň se liší i jejich aplikační rozhraní.
3.2.1. Azure Table Azure Table je strukturované úložiště dat podobné databázové relační tabulce v MS SQL, s tím rozdílem, že nemusí být zachována doménová integrita11 a pravoúhlost (stejný počet sloupců v každém řádku). K tabulkám se může přistupovat přes REST API nebo pomocí ADO.NET Data Services a LINQ. Při přístupu k Azure Table má URL adresa následující tvar: ://.table.core.windows.net/Tables(‘
’)
Account je účet vytvořený za účelem používání Windows Azure Storage a table je název příslušné tabulky, ke které chceme přistupovat. Název tabulky musí splňovat následující kritéria: musí to být validní DNS názvy, název musí být unikátní v daném uživatelském účtu, musí obsahovat pouze alfanumerické znaky, první znak musí být písmeno a délka názvu musí být v rozmezí 3 až 63 znaků. Zároveň je potřeba brát v potaz, že názvy jsou case sensitive. Entity jsou ukládány v tabulkách, existuje zde stejná analogie jako v případě relačních tabulek, tedy že jedna entita je představována konkrétním řádkem v tabulce. Entity se skládají z páru název-hodnota a říká se jim vlastnost. Vlastnosti jsou prezentovány sloupci v tabulce, což je zase shodné s relačními tabulkami. Entita musí mít povinně následující vlastnosti (sloupce): PartitionKey, RowKey a TimeStamp. PartitionKey a RowKey jsou datového typu string, zatímco Timestamp je datového typu DateTime, který je nastaven 11
Doménová integrita zajišťuje, že každá hodnota v daném sloupci má požadovaný datový typ.
23
jako read-only. PartitionKey a RowKey dohromady představují unikátní identifikátor (primární klíč) entity. V Azure Table jsou data organizována do několika storage uzlů na základě PartitionKey. Entity se stejným PartitionKey jsou ukládány ve stejném storage uzlu. Partition je kolekce entit se stejným PartitionKey. RowKey slouží jako unikátní identifikátor entity v partition. [Redkar, 2010]
3.2.2. Azure Blob Nestrukturované úložiště dat je srovnatelné se souborovým systémem, které se typicky používá pro ukládání velkých binárních souborů, typicky dokumentů (docx, xlsx, pptx a pdf), multimédií (audio, video), aj. Azure Blob se skládá z Block Blobu a Page Blobu. Block Blob využijeme především tam, kde bude daný obsah koncovému konzumentovi dat streamován. Tedy např. audio a video obsah. Každý blob se skládá ze sekvence bloků až do velikosti 4 MB. Maximální velikost jednoho Block Blobu je 200 GB. Page Blob využijeme v ostatních případech. Maximální velikost jednoho Page Blobu je 1 TB. Typ blobu musí být zvolen při jeho vytváření a nelze jej v průběhu času změnit. Manipulace s daty probíhá přes REST API, tzn., že každý blob je přístupný pod odpovídajícím URL, mající následující tvar: ://.blob.core.windows.net//
Account je účet vytvořený za účelem používání Windows Azure Storage, dále pak následuje defaultní url: .blob.core.windows.net/, za kterým je container, což je název kontejneru. Kontejner můžeme chápat jako složku (adresář). Za názvem příslušného kontejneru následuje: blob, což je daný blob, se kterým chceme pracovat. Pro názvy účtů, kontejnerů a blobů je potřeba brát ohled na to, že z nich budou vytvořena příslušná URL, tzn. tak aby nebyly používány specifické znaky národních abeced nebo tyto znaky patřičně zakódovat (dle standardizovaného protokolu HTTP/1.1). Další konvence v pojmenovávání jsou dostupné v dokumentaci na MSDN. Pokud vlastním doménu a zároveň se mi nelíbí výchozí tvar URL od Microsoftu, mám možnost vytvoření CNAME záznamu na doméně. Po přidání domény přes Windows Azure Management Portal a po validaci vlastnictví domény je již možné přistupovat k mým blobům přes tuto doménu. Bohužel však odpadá dle dokumentace možnost využít HTTPS protokol a zbývá tedy jen jeho nešifrovaná varianta. Všechny kontejnery a bloby obsahují následující metadata:
ETag – někdy označovaný jako entity tag, je otisk souboru sloužící v HTTP protokolu především ke cachování a mechanismu optimistic concurrency control.
Last-Modified – datum a čas poslední změny blobu, jakkákoliv operace zápisu, provede změnu v tomto atributu.
Content-Length – indikuje velikost těla zprávy v bytech.
Content-Type – určuje typ obsahu, např. text/html, viz. *Borenstein, a další, 1993+ 24
Content-MD5 – obsahuje otisk MD5 těla zprávy pro kontrolu integrity přenosu.
Content-Encoding – obsahuje typ kódování, např. gzip
Content-Language – definuje jazyk těla zprávy, např. „en“ pro angličtinu nebo „cs“ pro češtinu.
Cache-Control – definuje způsob použitého cachovacího algoritmu, např. nocache, max-age, atd.
Kompletní a zcela přesný popis získáme z RFC 2616: *Fielding, a další, 1999+ Přístup ke kontejnerům a blobům je závislý na nastavení ACL (systému řízení přístupu) a je vždy udělen jednotlivému kontejneru nebo blobu. Má pak jednu z následujících tří úrovní:
Full public read access – anonymní uživatelé mohou stahovat daný kontejner a jeho bloby, zároveň mohou procházet všechny bloby v daném kontejneru, nemohou však procházet všechny kontejnery uložené o úroveň výš
Public read acces for blobs only – anonymní uživatelé mohou stahovat bloby v daném kontejneru, ale údaje o daném kontejneru nejsou k dispozici a zároveň anonymní uživatelé nemohou procházet všechny bloby v daném kontejneru
No public read access – pouze majitel storage účtu může přistupovat k danému kontejneru a blobům v něm
Pokročilejším způsobem, jak řídit práva přístupu ke kontejnerům a blobům je Shared Access Signature (SAS). SAS umožňuje definovat pravidla přístupu k jednotlivým kontejnerům nebo blobům pro jednotlivé operace (Read, Write, Delete a List) s časově omezenou platností. Přístup je autentizován na základě vytvořeného otisku (signature), počítaného s použitím kryptografické hašovací funce (HMAC) v kombinaci s tajným šifrovacím klíčem 256 bitovou délkou šifrovacího klíče (algoritmus SHA256) dle RFC 2104. Bloby umožňují vytvářet tzv. snapshot. Snapshot je kopie blobu, vytvořená v určitém čase. Tuto možnost využijeme ve chvíli, kdy chceme verzovat12 obsah.
3.2.3. Azure Drive Windows Azure Drive je permanentní úložiště dat, které se snaží zjednodušit a časově zefektivnit migraci aplikací on-premise na cloud. Pro vývojáře představuje shodný princip práce s ukládáním dat, na který jsou zvyklí z dosavadních postupů. Azure Drive představuje permanentní disk se souborovým systémem NTFS, který je provozován v podobě VHD disku, známého z virtualizačních řešení Microsoftu.
12
Verzování je způsob uchovávání historie veškerých provedených změn obecně u jakékoliv digitální informace. Nejčastěji se tento pojem používá u zdrojových kódů software, kdy se evidují změny provedené v jednotlivých verzích během stádia vývoje softwarového projektu.
25
Pod operačním systémem Windows 7 je vytvoření VHD disku otázkou několika kliknutí. Do vyhledávání v nabídce Start napíšeme: „format“, měla by se objevit možnost Vytvořit a formátovat oddíly na pevném disku. Otevře se program Správa disků, v jejímž menu Akce je nabídka Vytvořit virtuální pevný disk, která spustí přehledného průvodce. V prvním kroku je potřeba zvolit možnost: „Pevná velikost“ a nastavit velikost mezi 16 MB a 1 TB dle potřeby. Pokud nepracujeme pod systémem Windows 7, je možné vytvořit VHD soubor v programu Microsoft Virtual PC, který je bezplatně ke stažení, případně v jiném programu podporující tento formát. Pravidla a vlastnosti použití Azure Drive:
Disk je technicky již zmíněný Page Blob, naformátováný na NTFS s pevnou velikostí mezi 16 MB a 1TB
Jedna Windows Azure VM role může mít přiřazeno (mounted) až 16 disků
Pokud jedna VM role má přiřazen disk v režimu read/write, žádná další role nemůže do tohoto disku zapisovat, pouze z něj číst (vytvořením snapshotu)
Pro dosažení maximálního výkonu při práci s Azure Drive je potřeba, aby Windows Azure Compute a Windows Azure Storage byla ve stejném regionu, což platí i ve všech ostatních případech
K diskům je přistupováno přes API Windows Azure Blob, do cloudu se nahrávají jako Page Blob ve formátu VHD a ve stejném formátu je můžeme stáhnout
Je možné vytvářet snapshoty, tudíž můžeme velmi snadno zálohovat
3.2.4. Azure Queue Azure Queue slouží pro ukládání zpráv, které umožňují komunikaci mezi Web a Worker rolemi. Velmi zjednodušeně řečeno, můžeme Azure Queue chápat, jako MOM (Message oriented middleware), v případě platformy Microsoft je to MSMQ (Microsoft Message Queuing), na platformě Java je to JMS (Java Message Service), fungující v cloudu, za účelem výměny zpráv při komunikaci mezi jednotlivými aplikacemi. Jelikož se jedná o cloud, tedy službu běžící na více serverech najednou, Azure Queue negarantuje model fronty FIFO (First in, First out). Stejně jako u služby Azure Blob se k této službě přistupuje přes Rest API. Při přístupu k Azure Queue má URL adresa následující tvar: ://.queue.core.windows.net
Account je účet vytvořený za účelem používání Windows Azure Storage. Azure Queue poskytuje škálovatelnou a vysoce dostoupnou infrastrukturu pro asynchronní komunikaci zpráv v cloudu, ale je třeba mít na paměti určitá omezení: 26
služba poskytuje prostor pro neomezený počet zpráv, avšak velikost jedné zprávy nesmí přesáhnout velikost 8 KB.
životnost zprávy je maximálně 7 dní, po této době se zpráva automaticky smaže
služba nemusí odbavovat frontu vždy podle principu FIFO (first in, first out)
zpráva může být zpracována vícekrát (může k tomu dojít v případě, že jedna instance Azure Compute zprávu zpracuje, a ještě před označením zprávy za již zpracovanou, havaruje. Následně další instance zprávu zpracovává znovu)
zprávy musí být buď v textovém, nebo v binárním formátu, ale vždy musí být zakódovány ve formátu Base64
Pro usnadnění práce s Windows Azure Storage existuje celkem příjemná a uživatelsky přívětivá desktopová aplikace s názvem Azure Storage Explorer, která je dostupná pod licencí svobodného softwaru. Tato aplikace pracuje s třemi základními typy (Table, Blob, Queue), nad nimiž umožňuje operace vytváření, prohlížení, kopírování, přejmenování, smazání, uploadování a stahování. Zároveň umí prohlížet a editovat jejich metadata.
Obrázek 5: Ukázka programu Azure Storage Explorer
Následující Tabulka 2 slouží k porovnání vlastností mezi Azure Storage a SQL Azure, (který je zpracován v podkapitole 3.3 SQL Azure). Na tuto tabulku okamžitě navazuje Tabulka 3, která slouží pro porovnání všech čtyř částí Azure Storage a SQL Azure. 27
Charakteristika Přístup k datům „Velikost“ dotazu
SQL Azure ADO.NET/ODBC + T-SQL Neomezená velikost, zpracování max. 5 minut
Azure Storage REST, LINQ Maximálně 1000 entit, zpracování max. 5 sekund, stránkování výsledku Zpracování na straně Uložené procedury, funkce, Ne serveru triggery, apod. Indexy 1 clustrovaný, až 999 Jediný podle primárního neclustrovaných klíče Transakce Nad jednou databází max. 5 Pouze nad daty ve stejném minut oddílu, max. 100 operací a 4MB dat 13 Izolace uživatelů Optimistický přístup Celá škála možností nabízených databází Škálovatelnost Omezena na 1 virtuální Prakticky neomezená server, případně možno zátěž dělit již v aplikaci Max. kapacita 50 GB 100 TB Max. velikost 1 položky 2 GB 1 TB Redundance a vysoká Ano Ano dostupnost Platba za uložení 9,99 USD/GB/měsíc (podle 0,15 USD/GB/měsíc (podle naalokované velikosti) skutečné spotřeby) Platba za používání GB přenesené z/do Azure GB přenesené z/do Azure serverovny serverovny + transakce nad daty Tabulka 2: Porovnání SQL Azure vs. Azure Storage *Juřek, a další, 2010+
Azure Blob
Azure Drive
Azure Queue
Strukturovaná data Relační data Zpracování na straně serveru Přímý přístup mimo Azure Messaging infrastruktura Perzistentní úložiště
Azure Table
SQL Azure
Ano
Ano Ano Ano
Ano
Ano
Ano
Ano
Ano
Ano
Ano Ano
Ano
1 týden
13
Optimistický přístup (Optimistic concurrency) je jeden ze dvou přístupů v Systému řízení báze dat (SŘBD či DBMS) v přístupu k datům. Umožňuje poskytovat data vícero transakcím bez uzamykání dat, kterých se to týká, s předpokladem, že se vzájemně neovlivňují. Pokud dojde ke konfliktu, transakce je vrácena zpět (rollback).
28
Velikostní limit
200 GB / 1 TB
1 TB
100 TB
100 TB
50 GB
Tabulka 3: Porovnání technologií Azure Storage *Juřek, a další, 2010+
3.3. SQL Azure SQL Azure je relační databáze, hostovaná v cloudu a nabízená jako služba. Konkrétně se jedná o nejnovější dostupnou verzi Microsoft SQL Serveru, tedy o SQL Server 2008 R2. SQL Azure zajišťuje vysoce dostupnou, škálovatelnou databázovou službu, která je na multitenantním principu. Je podporován jazyk Transact-SQL (T-SQL), díky tomu můžeme vyjít ze stávajících znalostí vývoje v T-SQL a relačním datovém modelu, který je shodný s on-premise řešením. Avšak oproti on-premise řešení, můžeme nalézt tyto výhody:
nižší náklady TCO – nulové pořizovací náklady za hardware a licence
predikovatelné provozní náklady
vysoká dostupnost – veškerá data jsou automaticky replikována ve třech kopiích, běžících minimálně na dvou serverech s rozdílnou geo lokací
zajištění vysoké odolnosti – pokud jeden server přestane reagovat, okamžitě je automaticky nahrazen jiným
servery jsou automaticky spravovány a aktualizovány na nejnovější verze – vše funguje takovým způsobem, aby nedošlo k žádnému výpadku
Microsoft poskytuje SQL Azure ve dvou edicích, které se technicky neliší, pouze maximální možnou velikostí jedné databáze. Ve verzi Web edition máme k dispozici databázi ve velikosti 1 GB nebo 5 GB dle potřeby. Ve verzi Business Edition je to od 10 GB do 50 GB odstupňováno po deseti gigabytech. Omezení jsou zde kvůli zajištění dostupnosti dat. Data jsou automaticky replikována a při vyšších velikostech by nemusela být zaručena včasná replikace na další server v případě výpadku jednoho ze serverů. Velikost je možné manuálně navyšovat, nikdy se nezvyšuje automaticky. Účtování probíhá v měsíčních cyklech. Platí se dle skutečně spotřebovaného místa zaokrouhleno nahoru na nejbližší možnou velikost (např. u Business edice mám alokováno 30 GB, databáze má skutečnou velikost 15 GB, bude mi účtováno 20 GB. V případě naplnění nadefinované velikosti se databáze přepne do režimu read only, tím pádem je možné data jen číst, nikoliv zapisovat. Cena je účtována za alokovanou velikost databáze (9,99 USD / GB / měsíc, respektive u Business edice je to 99,99 USD / 10 GB / měsíc), za přenesená příchozí data (0,10 USD / GB) a odchozí (0,15 USD / GB).
3.3.1. Topologie využití služby SQL Azure Existují dvě různé topologie, jak využívat SQL Azure. První možností je hostovat aplikaci i s databází na platformě Windows Azure, tzn. využívat službu SQL Azure zároveň se službou Windows Azure Compute. V tomto případě je dobré zvolit, jak pro Azure Compute, tak i pro SQL Azure stejnou geo lokaci, aby komunikace probíhala uvnitř 29
jednoho datového centra. Díky tomu snížíme dobu odezvy a především náklady (přenesená data se účtují pouze při přenosu mimo datové centrum, tedy pokud budeme mít obě služby ve stejné lokalitě, tak nám tento náklad za přenesená data nevznikne). Druhou možností je mít v cloudu pouze databázi a na výpočty využívat vlastní servery. Obě možnosti jsou zobrazeny v následujícím obrázku.
Obrázek 6: Topologie SQL Azure *Juřek, a další, 2011+
3.3.2. Model služby Službu SQL Azure můžeme rozdělit do tří vrstev, tak jak zobrazuje Obrázek 6. Vrstvy jdou postupně v takovém pořadí, v jakém jsou vytvářeny. V první vrstvě je účet. Účet je spravován přes Windows Azure Platform Management Portal. Účet je subjekt, kterému se účtují poplatky za využívané služby. Na účet můžeme vytvořit jeden nebo více serverů. Každý server může mít jednu nebo více databází. Vždy však má master databázi, která obsahuje metadata o ostatních databázích, uživatelské účty a další systémové věci. Za master databázi se nic neúčtuje. Server má vždy unikátní DNS jméno a můžeme ho chápat jako ekvivalent SQL instance. Polohu serveru je vždy dobré volit ve stejné lokalitě, jako je umístěno Windows Compute, případně, co nejblíže našemu on-premise řešení. Databáze má standardní SQL objekty, tak jak je známe z klasického SQL Serveru (tabulky, pohledy, indexy, uložené procedury, triggery, atd.). Za služby je účtováno na základě alokované velikosti databáze a přenesených dat putujících ven nebo dovnitř datacentra.
30
Obrázek 7: Model služby SQL Azure *Juřek, a další, 2011+
3.4. Azure AppFabric Význam aplikací spočívá v jejich obchodní logice. Ovšem tato logika je závislá na infrastruktuře, která umožňuje běh aplikací. Dobrá aplikační platforma by měla zajišťovat také vhodnou infrastrukturu; vývojáři by neměli být nuceni ji vytvářet sami. Windows Azure AppFabric poskytuje aplikacím služby infrastruktury. Tvůrcům aplikací se hodí různé druhy infrastruktury, a proto AppFabric obsahuje několik různých komponent. V této části dokumentu se podíváme na tři komponenty dnešního AppFabric, jimiž jsou servisní sběrnice (Service Bus), řízení přístupu (Access Control) a vyrovnávací paměť (Caching).
3.4.1. Servisní sběrnice (Sevice Bus) Řekněme, že v rámci své organizace provozujete aplikaci, která poskytuje webovou službu vytvořenou v prostředí Windows Communication Foundation (WCF). Tuto službu byste chtěli prostřednictvím Internetu propojit s klientským software, který běží vně organizace. Tento software může běžet na platformě cloudu jako Windows Azure nebo uvnitř jiné organizace. Na první pohled se může zdát, že úkol je jednoduchý. Aplikace nabízí své funkce jako webové služby (využívají konvence REST nebo protokolu SOAP), proto by mělo stačit, abyste tyto služby zviditelnili okolnímu světu. Ale když se o to pokusíte, zjistíte, že nastanou problémy. 31
Předně, jak uživatelé v jiných organizacích naleznou koncové body, ke kterým by se mohli připojit a které by jim umožnily používat služby vaší aplikace? Bylo by užitečné, kdyby existoval nějaký druh registru, ve kterém by mohli vaši aplikaci vyhledat. Za další, až službu najdou, jak se k ní dostanou požadavky software jiné organizace? Dnes se běžně používá překlad síťových adres (NAT), takže aplikace obvykle nemá pevnou IP adresu, se kterou by mohla být zveřejněna. A i kdyby nebyl použit NAT, jak se požadavek dostane přes váš firewall? Aplikaci je sice možné zpřístupnit tím, že otevřete porty firewallu, ale to síťoví administrátoři nemají rádi. Tyto problémy řeší servisní sběrnice. Způsob řešení je znázorněn na následujícím obrázku.
Obrázek 8: Postup ve vyhledávání a získávání přístupu ke službě prostřednictvím servisní sběrnice Azure AppFabric [Chappel, 2010]
Služba WCF nejdříve na servisní sběrnici zaregistruje své koncové body (krok 1). Servisní sběrnice potom všechny tyto zaregistrované body zpřístupní jako koncové body sběrnice (krok 2). Sběrnice přidělí organizaci kořenový identifikátor, s jehož pomocí může organizace vytvořit libovolnou požadovanou hierarchii názvů. Proto lze každému koncovému bodu přidělit jeho vlastní unikátní identifikátor URI. Chce-li klientská aplikace běžící v cloudu nebo lokálně v jiné organizaci použít vaši službu, požádá registr servisní sběrnice, aby nalezl koncový bod (krok 3), přičemž registru poskytne identifikátor URI koncového bodu. Tento požadavek používá protokol Atom Publishing a jako odpověď je vrácen dokument služby AtomPub s odkazy na koncové body servisní sběrnice, čili ty body, které pro vaši aplikaci poskytla servisní sběrnice. Když je má klient k dispozici, může volat operace služeb zpřístupněných pomocí těchto koncových bodů (krok 4). Obdrží-li servisní sběrnice takovýto požadavek, zavolá odpovídající operaci koncového bodu služby zveřejněného vaší službou WCF (krok 5). Na obrázku není 32
znázorněno, že pokud je to možné, vytvoří servisní sběrnice přímé spojení mezi aplikací a jejím klientem. Tím umožní zefektivnit jejich komunikaci. Jistě vás napadne otázka, jak přesně funguje krok 5? Jakým způsobem se požadavek servisní sběrnice vůči vaší službě vypořádá s překladem adres NAT a firewally? Odpověď je ta, že vaše služba v kroku 1 otevřela pro zpřístupněný koncový bod spojení TCP se servisní sběrnicí. Sběrnice udržuje toto spojení otevřené, což vyřeší dva problémy. Zaprvé, NAT již nepředstavuje problém, protože požadavky na otevřeném spojení se servisní sběrnicí budou vždy směrovány vaší aplikaci. Zadruhé, spojení bylo zahájeno uvnitř zóny chráněné firewallem, a proto není problém předat v rámci tohoto spojení informace zpět aplikaci. Firewall tuto komunikaci nezablokuje. Servisní sběrnice nejenom zjednodušuje komunikaci, ale i zvyšuje bezpečnost. Klienti vidí pouze ty IP adresy, které poskytne sběrnice. Není potřeba, aby vaše organizace zveřejnila jakoukoli vnitřní IP adresu. To znamená, že vaše aplikace není pro vnější svět viditelná a v důsledku toho je anonymní. Servisní sběrnice funguje jako externí zóna DMZ a poskytuje ochrannou vrstvu vůči útočníkům. Zatímco aplikace, která poskytuje své služby prostřednictvím sběrnice, je obvykle implementována v prostředí WCF, klientské aplikace je možné vytvořit rovněž pomocí jiných technologií například Java. Pro zadávání požadavků mají všichni klienti k dispozici protokoly TCP, HTTP nebo HTTPS. Aplikace mohou pro ochranu komunikace vůči útokům používat rovněž své vlastní bezpečnostní mechanizmy, například šifrování. Zpřístupnění aplikací okolnímu světu není tak snadné, jak se může zdát. Funkcí servisní sběrnice je realizaci této komunikace co nejvíce usnadnit.
3.4.2. Řízení přístupu (Access Control) Neodmyslitelnou součástí většiny distribuovaných aplikací je práce s identitou. Dnešní moderní přístup zvaný deklarovaná identita (claim-based identity) umožňuje, aby uživatelé odeslali známku (token) s několika deklaracemi identity (claim), které obsahují informace o identitách uživatele a jsou krytpograficky podepsány. Některé deklarace mohou obsahovat jméno uživatele, jiné například věk nebo skupinu, do které uživatel patří. Podle deklarací v tokenu aplikace zjistí, k čemu má uživatel oprávnění. Aplikace může tyto informace použít i jiným způsobem. V dnešním světě deklarované identity vydávají tokeny různí poskytovatelé identity. Někteří z nich například Active Directory Federation Services (AD FS) 2.0 působí uvnitř organizací. Jiné, jako Windows Live ID nebo Google, jsou prostřednictvím Internetu přístupny všem. Aplikace může rozhodnout, kterým poskytovatelům bude důvěřovat a tudíž, které tokeny bude akceptovat. Například aplikace, která běží ve firmě, může akceptovat pouze tokeny vydané službou AD FS firemního serveru, zatímco jiná aplikace běžící na Internetu může akceptovat tokeny vydané poskytovateli Google nebo Facebook. 33
Ovšem různí poskytovatelé identity používají různé formáty tokenů a tyto tokeny reprezentují deklarace různým způsobem. Aplikace, která by měla přímo akceptovat identity řekněme od poskytovatelů Google, Facebook a Yahoo, by musela všechny rozdíly zpracovat sama. Ale proč by to měla dělat? Proč by místo toho neměl existovat mezičlánek, který by generoval tokeny jediného formátu s jednotnou reprezentací deklarací? Tvůrcům aplikací by to zjednodušilo práci, protože by bylo potřeba zpracovat pouze jediný druh tokenu. Přesně tuto funkci má služba řízení přístupu. Je mezičlánkem, který usnadňuje práci s deklarovanou identitou v cloudu. Na následujícím obrázku je znázorněno, jakým způsobem služba funguje.
Obrázek 9: Schéma procesu přístupu ke službě pomocí Azure AppFabric Access control [Chappel, 2010]
Jak je na obrázku znázorněno, aplikace může běžet jak v cloudu, tak i lokálně. V obou případech začíná proces tím, že se uživatel pokusí o přístup k aplikaci prostřednictvím prohlížeče (krok 1). Aplikace přesměruje prohlížeč na poskytovatele identity, jehož token akceptuje. Tento poskytovatel uživatele ověří (uživatel zadá například jméno a heslo) a vrátí mu token s jeho deklaracemi (krok 2). Potom uživatel odešle tento token službě řízení přístupu (krok 3). Služba ověří, zda byl token vydán požadovaným poskytovatelem identity a osvědčí planost tokenu. Potom podle pravidel definovaných pro tuto aplikaci vytvoří nový token (krok 4). Služba řízení přístupu obsahuje modul pro pravidla. Pomocí něj může administrátor aplikace definovat, jakým způsobem se budou tokeny různých poskytovatelů identity transformovat na token služby řízení přístupu. Pokud různí poskytovatelé používají například různé formáty pro reprezentaci jména uživatele, modul transformuje všechny formáty na jednotný typ řetězce se jménem uživatele. Řadič 34
infrastruktury systému potom odešle tento nový token zpět prohlížeči (krok 5), který jej odešle aplikaci (krok 6). Aplikace po obdržení tokenu ověří, zda byl token opravdu vydán službou řízení přístupu, a potom použije deklarace v něm obsažené (krok 7). Ačkoli tento proces vypadá trochu komplikovaně, tvůrcům aplikací ve skutečnosti velice usnadňuje život. Nemusí zpracovávat rozličné tokeny s rozmanitými deklaracemi od nejrůznějších poskytovatelů identity. Aplikace bude sice přijímat pouze jediný typ tokenu s deklaracemi, ale i tak bude schopna akceptovat identity poskytnuté různými poskytovateli. Není potřeba konfigurovat každou aplikaci tak, aby věřila různým poskytovatelům identity. Udržování těchto vztahů řídí služba řízení přístupu a stačí, aby aplikace důvěřovala této službě. Jak bylo znázorněno na předešlém Obrázek 8, služba řízení přístupu podporuje několik poskytovatelů identity včetně poskytovatelů AD FS 2.0, Windows Live ID, Google a Facebook. Může rovněž spolupracovat s libovolným jiným poskytovatelem, který podporuje identitu podle standardu OpenID. Prohlížeče a jiní klienti mohou o tokeny služby řízení přístupu žádat pomocí protokolů OAuth 2 nebo WS-Trust. Tyto tokeny mohou být různého formátu například SAML 1.1, SAML 2.0, nebo Simple Web Token. K vytváření aplikací, které akceptují tokeny služby řízení přístupu, slouží vývojářům technologie Windows Identity Foundation. Stojí za zmínku, že nic, co se týká služby řízení přístupu, není vázáno na Windows. Tuto službu lze stejně dobře využít i v aplikaci pro Linux, která akceptuje pouze identity poskytovatelů Google nebo Facebook. Práce s identitami je velmi důležitá téměř ve všech distribuovaných aplikacích. Cílem služby řízení přístupu je usnadnit vývojářům vytváření bezpečných aplikací, které akceptují identity různých poskytovatelů. Microsoft zařadil tuto službu do cloudu a zpřístupnil ji tím všem aplikacím bez ohledu na platformu.
3.4.3. Vyrovnávací paměť (Caching) Jednou z nejefektivnějších metod pro zvýšení výkonnosti aplikací je ukládání často používaných dat do vyrovnávací paměti. Aplikace mají tendenci opakovaně používat stejná data a proto pokud usnadníme přístup k těmto datům, můžeme aplikace zrychlit. Toto je cílem služby ukládání do vyrovnávací paměti Windows Azure AppFabric. Ideu znázorňuje následující obrázek.
35
Obrázek 10: Schéma přístupu aplikací k datům prostřednictvím služby Azure AppFabric Caching [Chappel, 2010]
Služba ukládání do vyrovnávací paměti poskytuje aplikacím pro Windows Azure distribuovanou vyrovnávací paměť a knihovnu pro přístup k této paměti. Jak je naznačeno na obrázku, služba zahrnuje lokální vyrovnávací paměť, která udržuje pro každou instanci role kopie nedávno použitých datových prvků. Není-li požadovaný datový prvek nalezen v lokální vyrovnávací paměti, knihovna automaticky kontaktuje službu sdílené vyrovnávací paměti. Jak je na obrázku znázorněno, je tato paměť rozprostřena mezi několika instancemi Windows Azure, přičemž každá instance obsahuje jiná data. Ovšem aplikace, která vyrovnávací paměť používá, tuto diverzitu nevidí. Aplikace pouze požádá o datový prvek, a potom nechá službu, aby prvek vyhledala (pokud ve vyrovnávací paměti existuje) a z příslušné instance jej získala. Ovšem nedávno použitá data nejsou do vyrovnávací paměti uložena automaticky. Aplikace může explicitně vložit datové prvky do vyrovnávací paměti pomocí rozhraní API služby vyrovnávací paměti. Další variantou je možnost nakonfigurovat aplikaci ASP.NET běžící na platformě Windows Azure tak, aby ukládala do vyrovnávací paměti data objektu relace (session). Tím lze dosáhnout zrychlení běhu aplikace beze změny kódu. Windows Server AppFabric, lokální analogie komponenty Windows Azure AppFabric také poskytuje službu vyrovnávací paměti. Ve skutečnosti jsou si obě velmi podobné. Nejvíce se odlišují v tom, že vyrovnávací paměť Windows Azure AppFabric je na rozdíl od svého lokálního protějšku službou, čili není potřeba konfigurovat servery a administrovat vyrovnávací paměť. Toto vše obstará služba samotná. Služba vyrovnávací paměti v cloudu je typu multitenant, čili každá aplikace, která ji používá, dostane svoji vlastní instanci. Instance ověřuje identitu aplikace, a proto data této aplikace ve vyrovnávací paměti nejsou dostupná jiným aplikacím. 36
Vyrovnávací paměť může zrychlit běh aplikace a usnadnit změnu její kapacity, aniž by vývojáři museli vyvinout nějaké zvláštní úsilí. Proto se vyplatí ji používat. Situace je navíc usnadněna tím, že vyrovnávací paměť Windows Azure AppFabric je poskytována jako služba.
3.5. Azure CDN (Content Delivery Network) Obecně CDN (Content Delivery Network) je služba, která má za úkol distribuovat digitální obsah velkého objemu dat, typicky multimediální obsah (video, audio, foto ve vysokém rozlišení), nejrychlejším možným způsobem k uživateli a zároveň přenést zátěž hlavních serverů producenta obsahu na servery distributora (provozovatele sítě CDN). *Kačmář, 2011] Distribuce obsahu bez použití CDN se potýká s dvěma hlavními obecnými problémy: konzument se může nacházet geograficky velice daleko, což je spojeno s vysokou dobou odezvy. Zároveň se zatěžují všechny sítě od bodu umístění serveru až po koncového uživatele, výsledná rychlost závisí na nejslabším místě, problematika nejslabšího článku v řetězu (bottleneck). Druhým problémem je, že distribuční místo nemá dostatečnou rychlost připojení pro obsloužení většího množství konzumentů služby. Oba tyto problémy vedou jednoduše k neúnosně vysoké odezvě na požadavek stažení obsahu případně až nedostupnost služby. Ve výsledném efektu odchod klienta od služby. Azure CDN je tvořeno řadou tzv. hraničních serverů (edge server), které fungují jako transparentní cache. Servery jsou co nejvíce rovnoměrně rozmístěny po světě (jak znázorňuje Tabulka 4), aby byly nejblíž koncovým uživatelům. V současné chvíli jsou tyto hraniční servery rozmístěny v níže uvedených lokacích. *Kačmář, 2011+ Jejich počet však neustále průběžně narůstá. Region USA
Region EMEA
Ashburn, VA Bay Area, CA Chicago, IL San Antonio, TX Los Angeles, CA Miami, FL Newark, NU Seattle, WA
Amsterdam, NL Dublin, IE London, GB Moscow, RU Paris, FR Stockholm, SE Vienna, AT Zurich, CH
Region Asie, Pacifik a Jižní Amerika Hong Kong, HK São Paulo, BR Seoul, KR Singapore, SG Sydney, AU Taipei, TW Tokyo, JP Doha, QT
CDN následně funguje tak, že při prvním dotazu, který pochází nejblíže daného uzlu CDN, se obsah přenese přímo z datového centra a je zároveň uložen na daném hraničním serveru. Při dalším dotazu na stejný obsah jsou data přenesena z odpovídajícího uzlu CDN. To, který uzel CDN dotaz obslouží, je automaticky řízeno logikou CDN a pro všechny zúčastněné (klient, administrátor, programátor) je zcela transparentní. Fakticky ale nemusí jít o geograficky nejbližší uzel, neboť záleží na síťovém připojení klienta. Pokud 37
jsem např. v Praze připojen přes VPN do Irska, budu obsloužen uzlem v Dublinu. *Kačmář, 2011] Služba CDN od svého počátku funguje jako cache pro libovolná data uložená v Azure Storage, konkrétně v blob úložišti. Do blob úložiště můžeme v podstatě ukládat libovolná data. Často jsou jako příklady uváděny různá multimediální data, ale mohou zde být uloženy i jakékoli jiné soubory a CDN síť může dobře sloužit jako kvalitní distribuční síť pro novou verzi aplikace nebo update, který je v krátké době stažen velkým množstvím uživatelů. Použití CDN pro distribuci dat a Azure Storage je technicky velice triviální operace a vyžaduje následující kroky: 1. Uložení dat do Azure Blob Storage 2. Povolení CDN podpory pro Azure Blob Storage (na provisioning portálu) 3. Nahrazení původních odkazů na Azure Blob Storage odkazy do CDN URL adresa multimediálního souboru hostovaného na Windows Azure Blob bez zapnutého CDN: ://.blob.core.windows.net/video/
URL adresa multimediálního souboru hostovaného na Windows Azure Blob se zapnutým CDN: ://.vo.msecnd.net/video/
Obrázek 11 prezentuje měření, které provedla společnost Microsoft společně se společností Trask solutions pro jednoho ze zákazníků Microsoftu. Cílem bylo ověřit, jak bude ovlivněna latence při stahování bitmapového obrázku z různých geografických lokací při uložení zdroje na různých místech. Těmito místy byly:
Lokální web server umístěný na kvalitní datové lince v ČR (červeně)
Windows Azure Blob Storage služba v datovém centru v Evropě (modře)
Windows Azure Blob Storage služba v datovém centru v Evropě se zapnutou CDN službou (zeleně)
38
Obrázek 11: Porovnání latence na různých místech světa při použití on-premise, Windows Azure Blob a Windows Azure Blob s aktivním CDN *Kačmář, 2011+
Je zřejmé, že se zapnutou CDN dojde až k 10 násobnému snížení latence, která se pohybuje v průměrné hodnotě do 200 ms. Použití Azure CDN má smysl v následujících případech:
uživatelé naší služby se vyskytují po celém světě
data jsou statická s delší dobou života
data jsou objemná a jejich načítání trvá delší dobu
Defaultně má cache nastavenou životnost na 72 hodin, ale tato hodnota je samozřejmě konfigurovatelná. Další věcí, kterou je možné nastavit je vlastní url adresa, přeci jenom defaultní není moc uživatelsky přívětivá.
3.6. AppFabric Caching Service Windows Azure AppFabric Caching je službou, která umožňuje cachovat informace z Windows Azure a SQL Azure aplikací a zvýšit tak jejich výkonnost. Data jsou ukládána v paměti a nemusí být opakovaně čtena z Azure Storage nebo SQL Azure databáze. Služba AppFabric Caching je fyzicky realizována jako distribuovaná in-memory aplikační cache. S touto službou je možné cachovat různorodé typy dat (CLR objekty, XML soubory, binární data, atd.). Služba je velmi úzce zakomponována do ASP.NET, proto je její využívání velmi snadné a pohodlné.
3.7. SQL Azure Reporting Je služba technicky podobná SQL Server Reporting Services, která má srovnatelné možnosti jako verze SQL Express, avšak běží v cloudu. Tato služba umožňuje reportování nad daty z SQL Azure. Tyto reporty je následně možné vložit do webových nebo desktopových aplikací.
39
3.8. Azure Marketplace Platformy cloudu jsou sice důležité, ovšem představují pouze prostředky k dosažení cíle. Skutečným cílem je nabídnout uživatelům hodnotné aplikace a užitečná data. Platforma Windows Azure je základnou jak pro aplikace, tak i pro data. Proč by tedy neměla lidem nabídnout rovněž prostor pro jejich vyhledání? Pro tyto účely je navrženo tržiště Windows Azure (Windows Azure Marketplace). Má dvě komponenty, tržiště aplikací AppMarket a tržiště dat DataMarket, které dovolují uživatelům vyhledat, vyzkoušet a zakoupit aplikace nebo data. Obě komponenty jsou důležité, avšak v době psaní diplomové práce existovalo především více položek v katalogu u DataMarket. AppMarket se teprve pomalu rozjíždí. Proto se v následujícím textu zaměříme na DataMarket.
Obrázek 12: Windows Azure Marketplace [Chappel, 2010]
Aplikace dnes běžně nakupují téměř všechny organizace. Nákup dat není tak obvyklý, ale je neméně důležitý. Dnes existuje mnoho firem, které prodávají různé druhy dat včetně demografických, finančních, právních a jiných. Ovšem dříve než organizace nějaká data zakoupí, musí zjistit, zda data existují, musí najít firmu, která je nabízí a musí rozhodnout, zda data opravdu odpovídají jejím potřebám. Tento proces je však zbytečně složitý. Proč by nemělo existovat jedno místo, kde by zákazníci mohli najít různé druhy dat od nejrůznějších dodavatelů? Proč zákazníkům neposkytnout možnost, aby se seznámili s daty a přesvědčili se, zda odpovídají jejich požadavkům? A proč by si hned na místě nemohli data zakoupit? Pro tyto účely byla v rámci tržiště Windows Azure vytvořena komponenta DataMarket. Na následujícím obrázku jsou znázorněny hlavní stavební kameny.
40
Obrázek 13: Architektura Windows Azure Marketplace DataMarket [Chappel, 2010]
Jak je na obrázku naznačeno, prostřednictvím tržiště dat mohou k informacím získat přístup jak uživatelé, tak aplikace. Uživatelům slouží pro tyto účely služba platformy Windows Azure zvaná Service Explorer. Služba umožňuje zjistit, jaké sady dat jsou k dispozici, a umožňuje je rovněž zakoupit. Se zakoupenými daty mohou aplikace pracovat pomocí požadavků založených na konvenci REST nebo protokolu OData. Data dodavatelů mohou být uložena v rámci samotné platformy Windows Azure, čili v úložišti Windows Azure Storage, nebo v databázi SQL Azure. Rovněž mohou být uložena externě, například v datových centrech dodavatelů. Není nutné, aby byla všechna data uložena v cloudu. Tržiště dat poskytuje uživatelům jakési centrum pro vyhledávání a nákup dat a pro přístup k datům. Dodavatelům obsahu, čili vlastníkům těchto dat, poskytuje možnost nabídnout svá data více zákazníkům. Ceny dat stanovují sami dodavatelé, ale fakturační služby zajišťuje komponenta DataMarket. To znamená, že dodavatelé nemusí jednat přímo se zákazníky. Microsoft rovněž prověřuje kvalitu dodavatelů obsahu. V rámci tržiště dat zavedl počáteční omezení počtu dodavatelů v konkrétním odvětví na pět. Aplikace mohou zakoupená data používat libovolným způsobem, který není v rozporu s licenčním ujednáním dodavatele dat. Například uživatelé aplikace Microsoft Excel 2010 mohou pracovat s daty přímo pomocí doplňku. Pro účely datových analýz je k dispozici také nástroj PowerPivot for Excel, který podporuje protokol OData. Uživatelé mohou rovněž kombinovat data zakoupená v rámci tržiště se svými vlastními daty, například se sestavami služby SQL Server Reporting Services. 41
Mají-li být informační technologie přínosné, je potřeba mít k dispozici nejenom vhodné aplikace, ale také odpovídající data. Tržiště dat zjednodušuje práci spojenou s vyhledáváním, vyhodnocením a nákupem komerčně dostupných dat. Proto jsou tato data pro organizace mnohem přístupnější.
42
4. Odlišnosti aplikací v cloudu oproti on-premise Transformace aplikace na Windows Azure je proces, který vyžaduje určité znalosti a dovednosti, jež jsou nezbytné pro úspěšný přechod z on-premise řešení na PaaS. Tento proces nese všechny znaky projektu. Proto je možné ho také jako projekt řídit. Proto, aby tento proces byl pokud možno bezbolestný, vznikly doporučení ohledně ekonomické a technické analýzy, vývoje, nasazení a provozování, které jsem uvedl v následujících podkapitolách.
4.1. Ekonomická analýza výhodnosti přechodu na Windows Azure Pro podniky všech velikostí Cloud computing představuje obrovskou příležitost. Jde o příležitost vymanit se z dlouholeté tradice, kdy vynakládáme až 80 procent *Kačmář, a další, 2010+ svého času a rozpočtu jen na udržování stávajícího řešení v chodu a kdy jen malý objem prostředků zbýval na inovace. Cloudové služby umožní zaměřit se více na inovace a běžné činnosti přitom nechat na spolehlivé a nákladově efektivní poskytovatele. Jak jsem uvedl v teoretické části práce v kapitole 2.3, pro všechny scénáře nemusí být Cloud computing výhodným řešením. Proto než se pustíme do činností vedoucích k přechodu podnikových aplikací do cloudu, navrhuji nejdříve zanalyzovat aktuální stav IT, tak abychom věděli, jaké náklady vynakládáme na stávající provoz a následně stanovit, jaké náklady by byly po migraci do cloudu. K celkovému obrazu je ještě potřeba přibližně odhadnout náklady spojené s přechodem aplikace do cloudu. Pokud srovnáme stávající stav se stavem budoucím (modelovaným), dostaneme odpověď, zda je pro náš účel výhodné přejít na Windows Azure. Pro účely rozhodování nám mohou posloužit znalosti z oblasti Teorie omezení14 (Theory of Constraints, TOC) a jako nástroj využít Stromy současné reality15 (Current reality tree, CRT) a Stromy budoucí reality16 (Future reality tree, FRT). Abychom se rozhodovali na základě minimalizace rizika, je dále vhodné využít několik finančních výpočtů, např.: výpočet návratnosti investic (ROI), celkové náklady na vlastnictví (TCO), jednoduché vzory výpočtů najdeme v následujících kapitolách.
4.1.1. Výpočet návratnosti investic (ROI) ROI je ukazatel míry návratnosti (výnosnosti, rentability) investice. Je to velmi oblíbený ukazatel pro hodnocení jednotlivých investičních projektů, především díky své jednoduchosti. Vypočítává se jako výše příjmů z investice, zmenšených o výši nákladů na 14
Za otce teorie omezení je považován Dr. Eliyahu M. Goldratt. Pokud se chceme dozvědět více, kvalitní informace najdeme v jeho knihách: The goal: a process of ongoing improvement *Goldratt, a další, 2004+, Critical chain [Goldratt, 1997] nebo dostupné online: A Guide to Implementing the Theory of Constraints [Youngman, 2009] 15 Informace o Stromech současné reality (Current reality tree, CRT) jsou dostupné zde: [Youngman, 2009] 16 Informace o Stromech budoucí reality (Future reality tree, FRT) najdeme zde: [Youngman, 2009]
43
investici a to celé vydělíme výší nákladů na investici. Pokud ROI vyjde záporné nebo nižší než u jiné příležitosti, neměla by být tato investice učiněna. Stanovení nákladů na projekt je snadné. Problémem však bývá, zejména u projektů v oboru IT, stanovit výši přínosů. U těchto projektů bývá výsledek výpočtu ROI mírně diskutabilní, přesto je tato metoda velmi používaná a proto jí zde uvádím. Pro výpočet ROI u projektu, který by měl být transformován na Windows Azure, můžeme použít již hotovou kalkulačku, která nám výpočet velmi usnadní. Tato kalkulačka je dostupná zde: http://azureroi.cloudapp.net/ Kalkulačka se sestává ze dvou obrazovek. První vypočítává měsíční náklady na provoz aplikace na Windows Azure, kde jsou již zadané hodinové ceny všech služeb a my si jen navolíme jaké služby, v jakém objemu, využíváme a dostaneme celkové měsíční náklady, viz. Obrázek 14.
44
Obrázek 14: Výpočet měsíčních nákladů na provoz aplikace na Windows Azure
Druhá obrazovka vypočítává ROI. Měnou je zde americký dolar. Délka projektu je stanovena na 24 měsíců. Zadáváme tyto náklady: Enterprise Costs – náklady spojené s pořízením HW a SW
Monthly hosting expenses – měsíční náklady na hostování (umístění) serveru, tzn. serverhousing
Monthly facilities expenses – zde tomu rozumím jako náklady na provoz místnosti, kde je server umístěn (např. elektřina), v našem případě, jsou tyto náklady započtené již v hosting expenses
Monthly hardware expenses – celkové náklady na pořízení serverů přepočítané na 1 měsíc, zde se počítá s dvouletou životností (odpisováním), tzn. celkové náklady na pořízení serveru vydělíme 24.
Monthly Maintenance Expenses – měsíční náklady na údržbu serverů, v našem případě, pokud počítáme s dvouletou životností, náklady na údržbu jsou kryty zárukou, takže jsou nulové.
Monthly Labor Expenses – měsíční náklady na IT profesionály, kteří zajišťují bezproblémový chod serverů
Monthly Licensing Expenses – celkové náklady na pořízení licencí, které jsou nezbytně nutné k provozu serverů, zde se počítá opět s dvouletou životností (odpisováním), tzn. celkové náklady na pořízení licencí vydělíme 24. V našem případě to chápeme jako licenci na OS Microsoft Windows Server 2008 R2 a licenci pro SŘBD Microsoft SQL Server 2008 R2, jelikož jsme v BizSpark programu, tyto náklady jsou 100USD při vystoupení z programu, který trvá 3 roky. Pokud bychom nebyli v tomto programu, tato částka by v našem případě byla přibližně stejně vysoká jako pořízení samotného HW.
Migration Costs – náklady spojené s migrací stávající aplikace na Windows Azure
Software development – náklady spojené s migrací stávající aplikace za 1 měsíc
Months to migrate – doba potřebná pro migraci stávající aplikace v měsících
Cloud Costs – náklady v cloudu, které spočítáme v první obrazovce kalkulačky Výsledkem výpočtu jsou měsíční úspory, doba za jakou je investice splacena a tabulka znázorňující průběh v jednotlivých měsících. V našem příkladu, který reflektuje mou vlastní reálnou zkušenost migrace stávající webové aplikace na Windows Azure, kde se pro internetový projekt Moneybro.cz 45
pořizoval značkový rackový 1U server od firmy Dell, za cenu zhruba $5232 a později se prodával, protože po migraci na Windows Azure, již nebyl potřeba, vychází značné úspory ve výši 46%. Měsíčně ušetříme $141, což za dva roky činí $1692, tj. 28 500,-Kč. Pro objektivnost je třeba dodat, že u tohoto příkladu nedosahuje modelovaný výpočetní výkon, který je stanoven na 3 extra small instance (2 instance Web role pro webovou aplikaci a 1 instanci pro VM roli, na které je provozován SMTP server a bankovní aplikace), zdaleka výkonu serveru, který byl zpočátku pořízen. Ovšem původní výkon byl značně předimenzován, protože růst na on-premise řešení není téměř vůbec škálovatelný v porovnání s Windows Azure. Bylo potřeba přihlédnout na to, že potencionální potřeba narůstu výkonu, by mohla projekt ohrozit, v případě, že by nebylo možné, na tuto změnu dostatečně rychle reagovat. To, že je modelovaný výkon cloudu o hodně nižší než tomu bylo u on-premise řešení (a tedy i cena), vyrovnává však fakt, že by stouply náklady za SW na on-premise řešení, kdyby firma nebyla přijata do BizSpark programu. Pokud by po realizování všech skutečností, které jsem zde uvedl, vyšlo ROI nulové nebo mírně záporné, přesto by byla s velkou pravděpodobností uskutečněna migrace na Windows Azure. S ohledem především na okamžitou škálovatelnost (v řádu jednotek minut) a se sníženými nároky na údržbu a provoz webového serveru (aktualizace, nastavování zásad bezpečnosti a vše, co je již v PaaS řešení obsaženo). Také musíme přihlédnout k faktu, že Microsoft je daleko silnější a stabilnější partner než všechny serverhousingové společnosti působící v ČR, což snižuje riziko hostování webové aplikace s důrazem na kvalitu poskytovaných služeb a posiluje důvěru zákazníků v danou službu.
46
Obrázek 15: Výpočet ROI
Pokud by nebyly aktualizované ceny jednotlivých služeb Windows Azure, jelikož se jedná o neoficiální kalkulačku třetí strany, můžeme využít kalkulačku nákladů přímo od společnosti Microsoft s názvem Windows Azure Pricing Calculator, nacházející na této webové adrese: http://www.microsoft.com/windowsazure/pricing-calculator/
4.1.2. Výpočet celkových nákladů na vlastnictví (TCO) TCO je ukazatel, který zahrnuje veškeré náklady spojené s nákupem, vlastnictvím a používáním informačních systémů nebo jejich částí během všech fází životního cyklu systému. TCO může sloužit jako podklad pro rozhodování o výběru vhodné varianty mezi investičními projekty. Tento ukazatel by měl být použit se součiností s ostatními ukazateli. Neměl by být použit samostatně, protože zvýhodňuje projekty, které preferují nejnižší celkové náklady bez ohledu na jejich stránku přínosů. Pro usnadnění výpočtu TCO je k dispozici webová aplikace, která je o něco komplikovanější než u ROI. Je dělaná formou tabulky, jejíž buňky se mohou kliknutím editovat a automaticky se generují grafy, což je sice přehledné, ale začíná to být příliš 47
detailní, což aplikaci dělá o něco sofistikovanější než předchozí aplikaci pro výpočet ROI. Pokud poctivě a pravdivě vyplníme všechna příslušná pole, bude se výpočet velmi blížit realitě. Tato aplikace je také vhodná ke stanovení počtu instancí rolí na Windows Azure, tak aby výsledný výkon byl ekvivalentní stávajícímu on-premise řešení, což se nám hodí i k předcházejícímu výpočtu ukazatele ROI. Oproti ROI je možné pro výpočty volit z velkého množství měn, nechybí ani česká koruna. Zmiňovaná aplikace se nachází na adrese: http://www.microsoft.com/windowsazure/tools/#tcoCompare-LB
4.2. Technická analýza kompatibility aplikace s Windows Azure 4.2.1. Windows Azure Migration Assessment Tool (MAT) Windows Azure Migration Assessment Tool (MAT) je vynikající bezplatný nástroj, který bych doporučil zařadit na úplný začátek procesu migrace stávající aplikace na Windows Azure. V době psaní diplomové práce je nástroj dostupný pouze v angličtině, což není nikterak překvapující a nemělo by to činit problém. Díky tomuto nástroji se nám velmi snadno a rychle podaří identifikovat klíčové faktory, které mohou ovlivnit rozhodování, zda je vhodné naši aplikaci provozovat v cloudu na Windows Azure. Zároveň si vytvoříme specifikaci požadavků, které musí být splněny pro bezproblémový provoz aplikace i u jiných poskytovatelů PaaS služeb. MAT nás provede celou řadou jednoduchých otázek, na otázky se odpovídá ano nebo ne. Otázky jsou koncipovány do několika okruhů:
Business – v tomto okruhu se setkáme s otázkamim, které se týkají, jak ekonomické stránky věci, tak ale i otázek různých právních aspektů např. zda má aplikace geopolitické restrikce17
Communications – zde jsou otázky, týkající se oblasti síťových služeb, např. zda aplikace využívá UDP protokol, zda odesílá emaily po protokolu SMTP, atd.
Deployment, Setup, Versioning – otázky týkající se použitého programovacího jazyka, způsobu nasazení aplikace, atd.
Integrations – otázky na typ architektury, přítomnosti COM objektů a dalších
Local Access and Storage – zde nalezneme otázky o datovém úložišti a věcí s tím spojených
Security – především zda aplikace vyžaduje přítomnost Active Directory
17
Některé druhy aplikací mají ze zákona stanovené přesné podmínky, že se data aplikace nesmí nacházet mimo hranice státu. Pokud data nesmí opustit hranice ČR, může to být problém, protože Microsoft zatím nenabízí možnost hostovat aplikaci v datové centru umístěném v ČR. Pokud stačí, že data nesmí opustit EU, tak to není problém. Máme možnost zvolit západní Evropu (Dublin) nebo severní Evropu (Amsterdam).
48
SQL – otázky spojené s relačním úložištěm dat
Web Methodologies – otázky, které se týkají využití ostatních služeb, např. cachování dat, session state, streamování videa, atd.
Je samozřejmostí, že během vyplňování otázek si můžeme MAT uložit a vrátit se k uložené práci kdykoliv jindy. Ve chvíli, kdy jsme s odpověďmi spokojení, stiskneme tlačítko report a necháme si vygenerovat vyčerpávající až padesáti stránkový wordovský dokument. Přestože je vygenerovaný dokument rozsáhlý je velmi dobře strukturovaný. Je členěn do několika kapitol a díky tomu jsou informace prezentovány přehledně. Hned na začátku je obsah, kde je problematika rozdělena podle rozsahu dopadu, od těch nejzávažnějších až po ty méně závažné. U každého jednotlivého případu je i navrhované řešení. Vše je podrobně vysvětleno, proč se Windows Azure liší od on-premise řešení a z jakého důvodu k tomu došlo. Co je ovšem nejdůležitější, je jak negativní dopad zmenšit, případně zcela odstranit. Nástroj je dostupný z této adresy: http://matclickonce.blob.core.windows.net/app/publish.htm Příklad výstupu zde neuvádím z důvodu velkého počtu stránek výstupního dokumentu.
4.2.2. Windows Azure Migration Scanner (WAMS) Zatímco Windows Azure Migration Assessment Tool (MAT) nahlíží na problematiku spíše z teoretické roviny, tak Windows Azure Migration Scanner (WAMS) jde na to z druhé strany. Do programu se zadá cesta k projektu, který má být migrován na Windows Azure, nastaví se zda chceme výstup pouze na obrazovku nebo i do souboru. V druhém případě ještě musíme nastavit cestu výstupního souboru, viz Obrázek 16. Poté program spustíme. V tu chvíli začíná skenování všech souborů v projektu, především zdrojového kódu. Aplikace vyhledává příkazy nebo nastavení, které jsou nekompatibilní pod Windows Azure nebo vyžadují určitý zásah. Výstupem je tabulka, ve které jsou identifikovány čísla řádků, na kterých se nachází problém, jméno souboru, skupina do které problém spadá, úroveň dopadu a navrhované řešení, viz Obrázek 17. Vše je přehledné. Aplikace také nabízí práci v příkazové řádce, což se hodí zejména při skenování většího množství projektů.
49
Obrázek 16: Windows Azure Migration Scanner
Obrázek 17: Ukázkový výstup z aplikace WAMS
WAMS je dostupný ze stránek Codeplexu: http://wams.codeplex.com/ MAT i WAMS jsou nástroje, které se velmi dobře doplňují. MAT by měl přijít na řadu nejdříve. V době kdy probíhá rozhodovací proces o tom, zda je technicky vhodné aplikaci převézt na Windows Azure. WAMS přijde na řadu o něco později, ve chvíli kdy je již rozhodnuto o migraci aplikace na Windows Azure a chceme znát konkrétně, v jakých částech aplikace bude potřeba zasáhnout a kód pozměnit.
4.3. Vývoj aplikací Čím se liší Windows Azure oproti on-premise řešení:
SMTP server – na Windows Azure chybí služba k odesílání emailů. Máme několik možností, jakým způsobem se s tím vypořádáme. Zaprvé, vlastní provozování SMTP serveru na VM roli, ať již standardní SMTP služby pod Windows Serverem 2008 nebo hostovanou aplikací třetí strany. Tuto možnost dále detailně analyzuji a implementuji v kapitole o VM roli. Druhou možností je využití placené služby
50
v podobě SaaS, např. hostovaným Exchangem18, využitím specializovaného poskytovatele pro masivní odesílání emailů SendGrid nebo služby Amazon Simple Email Service (Amazon SES). Dle mého názoru zde Microsoftu utíkají zisky a očekával bych, že podobnou službu jakou má Amazon, začne nabízet i Microsoft.
Stavy aplikací – ASP.NET Web Form i MVC webové aplikace ukládají stavy aplikací běžících na Windows Azure (Session state a Cache) do paměti, případně do souborů na disku19. V případě více instancí Webových rolí, není tento standardní scénář přípustný. Nemůžeme si totiž být nikdy jisti, jak Load balancer rozloží zátěž na vstupu. Může dojít k situaci, kdy je uživatel obsloužen první instancí Web role, ta si uloží stav aplikace na svůj lokální disk. Další HTTP požadavek po několika vteřinách již obslouží druhá instance Web role, která ale samozřejmě nemá uložený stav aplikace tohoto uživatele, jelikož ho má uložený v lokálním souborovém systému instance první, která ovšem nemá právo do tohoto umístění přistupovat, ba dokonce ani sama nic neví o existenci jiné role. Řešení pro Windows Azure již existuje a je jím implementace již hotových Windows Azure Session State providerů, které jsou dostupné z ukázkových aplikací nebo na Codeplexu20. Informace o cachování pomocí AppFabric nalezneme zde: http://portal.appfabriclabs.com/
IIS 7 Integrated mode pipeline – webové aplikace hostované na Windows Azure musí zásadně běžet v tomto aplikačním poolu, starší aplikace programované pro IIS 6 v klasickém módu musíme transformovat. Složitost transformace závisí především na použitém počtu rozšiřujících HTTP modulů. Postup transformace je velmi dobře popsán v oficiální dokumentaci na MSDN [Microsoft Corp., 2010].
Ukládání dat – data aplikace neukládáme, jak jsme byli zvyklí do souborového systému, ale do specializovaného úložiště Windows Azure Storage, které je umístěné v cloudu, slouží nám k tomu REST aplikační rozhraní, které je dobře zdokumentované v MSDN [Microsoft Corp., 2011] nebo v ukázkovém příkladu [Pallman, 2011].
Práce s relačními daty – přestože SQL Azure je v podstatě SQL server portovaný do cloudu, několik odlišností zde najdeme. Dle mého názoru chybí nejvíce SQL Server Agent, který periodicky spouštěl naplánované úlohy. Tuto funkcionalitu můžeme nahradit např. skriptem běžícím pod Worker rolí. Další věci, které postrádám:
18
Společnost Microsoft nabízí službu Business Productivity Online Services (BPOS), spadajících do kategorie SaaS, jedná se o hostovaný Exchange server, SharePoint server, služby určené ke komunikaci (Office Communications Online, provozování online setkání a internetových seminářů (Office Live Meeting.) Je možné využívat jednotlivé služby nebo celý balík služeb. 19 Kam se budou ukládat stavy aplikace záleží na nastavení ve Web.Configu (App.Configu u Windows služby pod Worker rolí), stav aplikace se samozřejmě nemusí ukládat jen do paměti nebo do souborového systému, ukládat je možné i do databáze nebo na specializovaný, k tomu určený State server. 20 Codeplex je bezplatné hostování open source projektů převážně pro Microsoftí technologie. Modifikované providery pro Membership, role, profily a Session state nalezneme zde: [Henriksen, 2011]
51
Integration services, Analysis services. Na SQL Azure chybí podpora Full textu. Při migraci na SQL Azure jsem také zjistil, že nejsou podporovány všechny T-SQL příkazy21. Seznam všech rozdílů je dostupný z wiki TechNetu *Nethi, a další, 2010+.
IP adresa serveru – dokud nenasadíme aplikaci do cloudu, neznáme IP adresu serveru, pokud IP adresu potřebujeme, musíme si ji za běhu přes API zjistit sami22.
Web.Config (App.Config) – byli jsme zvyklý na to, že tento XML soubor, obsažený v projektu, slouží k definování klíčové konfigurace aplikace (nastavení zabezpečení, načítání přídavných modulů, session state providerů, lokalizačního nastavení, atd.) a zároveň obsahuje specifické nastavení aplikace (přístup do databáze, nastavení SMTP serveru, důležité konstanty, atd.), které je možné za běhu aplikace měnit bez nutnosti rekompilace kódu a znovu nasazení aplikace na server. Na Windows Azure toto neplatí. Web.Config již nadále nelze měnit za běhu, pro tyto účely slouží nové dva XML soubory: ServiceDefinition.csdef a ServiceConfiguration.cscfg. ServiceConfiguration .cscfg může obsahovat nastavení, které je možné za běhu editovat.
4.4. Odlišnosti v nasazení aplikací do cloudu 4.4.1. Prostředí produkční a stagingové Zcela jistě zřetelnou výhodu oproti on-premise řešení, bez nutnosti konfigurovat tuto funkcionalitu samostatně, nabízí Windows Azure v podobě přítomnosti dvou prostředí, do kterých je možné aplikaci nasadit. Production a Staging Environment. Výhodou je, že můžeme nasadit aplikaci do produkčního prostředí a další verzi do prostředí staging a až po otestování aplikace přejít ze staging prostředí do produkčního, viz Obrázek 18. Tento proces sebou nese výhodu, že nedojde k výpadku aplikace při migraci na novou verzi. Aplikace se nasazuje z volitelnou možností operačního systému Windows Server 2008 SP1 nebo Windows Server 2008 R2 a verzí Windows Azure.
21
Přehled nepodporovaných T-SQL příkazů nalezneme zde: [Microsoft Corp., 2011] Ke zjištění IP adresy nasazené aplikace můžeme využít následující příkaz: Microsoft.WindowsAzure.ServiceRuntime. RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["EndpointName"].IPEndpoint.Address.ToString(); EndpointName je název definovaného koncového bodu aplikace, který je definován v souboru ServiceDefinition.csdef 22
52
Obrázek 18: Windows Azure Management Portal přechod aplikace ze stagingového prostředí do produkčního
4.4.2. Troubleshooting a debugging Při testování a vývoji aplikace je možné z prostředí Visual Studia spustit aplikaci na lokálním počítači vývojáře. Spustí se tzv. Compute emulator zároveň i se Storage emulátorem, jenž zajišťují běh aplikace na lokálním desktopu. Díky těmto emulátorům je možné aplikaci krokovat a využívat výhod nástroje IntelliTrace. Více informací nalezneme v dokumentaci na MSDN [Microsoft Corp., 2010].
4.4.3. Požadavky a doporučení k VM Role Před samotným vytvářením VM Role, je potřeba si projít níže uvedené požadavky a udělat si tak představu, jaké kroky bude nutné udělat k nasazení softwaru hostovaného na Windows Azure VM roli.
Microsoft Windows Server 2008 R2 (Standard nebo Enterprise edice, EN-US, 64 bit) s SP1 a s nainstalovanými doporučenými aktualizacemi
instalované Windows Azure Integration komponenty
zakázaný Windows Update
povolený Remote Desktop včetně příslušného nastavení Windows Firewallu (konfigurace firewallu je provedena automaticky)
přidána role IIS
přidány .NET Framework 3.5.1 Features
nainstalovat vlastní SW 53
Vytváření VM Role znamená vytvořit nový virtuální počítač, na kterém bude nainstalován operační systém Microsoft Windows Server 2008 R2 64 bit. Z toho vyplývá hned několik podmínek. Hostitelský počítač, na kterém budeme vytvářet virtuální stroj, musí mít nainstalován 64 bitový operační systém. Další nutnou podmínkou je, aby procesor a základní deska podporovali HW virtualizaci. Pokud nevíme, zda náš procesor podporuje virtualizaci, můžeme se podívat do specifikace k procesoru, kterou najdeme na webových stránkách příslušného výrobce našeho procesoru. V případě procesorů od společnosti Intel je tato technologie pod položkou Advanced Technologies a jmenuje se Intel Virtualization Technology (VT-x). U společnosti AMD tato technologie nemá žádné marketingové označení a najdeme ji pod očekávanou položkou virtualization. U ostatních výrobců procesorů, zejména těch serverových, např. IBM POWER, Sun SPARC se dá očekávat, že tato technologie bude podporována. Výrobce procesoru Intel AMD
Název virtualizační technologie Advanced Technologies -> Virtualization Technology (VT-x) Virtualization
Intel
Tabulka 5: Virtualizační technologie
Z vlastní zkušenosti vím, že základní desky kompatibilní s procesory Intel, mívají virtualizaci v továrním nastavení vypnutou a je potřeba jí v BIOSu povolit. Dokonce je možné se setkat i s tím, že ve specifikaci je tato možnost podporována, ale v závislosti na verzi firmware základní desky, je tato možnost skrytá, tudíž se nedá virtualizace zapnout. Zbývá možnost aktualizace firmware, tzv. flash základní desky, což vzhledem k záručním podmínkám a možnosti rizika zničení základní desky není doporučovaná cesta. Service Level Agreement vyžaduje použití minimálně dvou instancí VM rolí a jejich nasazení do rozdílných fault domain23. Zároveň je potřeba si uvědomit, že je sledován stav operačního systému a jeho služeb (Windows Service), nikoliv nasazené aplikace. Pokud operační systém neodpovídá nebo pokud dojde k chybě, je tato instance automaticky restartována. Stav nasazené aplikace si musíme ohlídat sami, nejjednodušší způsobem je zřejmě vlastní Windows Service, běžící na pozadí operačního systému, která kontroluje stav nasazené aplikace a v případě potřeby, může systém restartovat. V případě, že dojde ke kritickému selhání systému nebo HW prostředků, automaticky je VM role vytvořena z virtuálního obrazu disku (VHD) na jiném stroji. Z tohoto důvodu je nutné mít na paměti, že VM role není v žádném případě datově persistentní, tzn. veškerá data, která mají být za všech okolností zachována musí být uloženy někde mimo VM roli. Relační data v SQL Azure nebo v Azure Storage Table. Ostatní data bývají ukládána do Azure Storage Blob nebo na on-premise datové úložiště. Dle mého názoru je častým a k tomuto účelu velmi elegantním řešením služba Azure Drive. Služba Azure Drive byla popisována v samostatné kapitole, zjednodušeně řečeno se jedná o namapovaný síťový disk, který je v podobě VHD
23
Fault domain více zde: [Chou, 2011]
54
obrazu disku a fyzicky uložen v Azure Storage Page Blobu. Ve chvíli, kdy je namapován k operačnímu systému, je s ním možné pracovat téměř jako s pevným diskem. Velikost instance Windows Azure VM Role Extra small Small Medium, Large a Extra Large
Maximální velikost namapovaného VHD disku 15 GB 35 GB 65 GB
Tabulka 6: Závislost velikosti instance VM Role a maximální velikosti namapovaného obrazu disku [Microsoft Corp., 2011]
4.4.4. Vytvoření VM Role Možných způsobů, jak vytvořit VM Role je v zásadě hned několik, především záleží na HW prostředcích a operačním systému, který máme k dispozici. Pokud pracujeme s operačním systémem Microsoft Windows XP a novějším (Vista, Windows 7) doporučuji bezplatnou aplikaci Microsoft Virtual PC. Pokud pracujeme se serverovým operačním systémem Microsoft Windows Server 2008 doporučuji vytvářet virtuální pc pod tzv. hypervizorem, Hyper-V24. Na ostatních platformách Mac OS X, Linux, Solaris je možné využít open-source virtualizačního nástroje VirtualBox25. V době psaní diplomové práce se VM Role nachází v beta verzi, proto je nejdříve nutné zažádat o aktivaci služby ve Windows Azure Platform Management Portalu v sekci Beta Programs, kde mimo jiné naleznete i ostatní připravované technologie, které jsou zatím označeny jako beta. Dle mé zkušenosti byla služba aktivována do 48 hodin a od té doby již byla plně přístupná. VM Role jsem vytvářel za pomoci Hyper-V na Windows Serveru 2008 R2. Hyper-V nebývá standardně aktivováno, proto je zapotřebí přejít ke Správě serveru a v části souhrnu rolí přidat roli s názvem Hyper-V. Po instalaci přejdeme do Správce technologie Hyper-V, kde nejdříve nakonfigurujeme virtuální síť, toto činíme proto, abychom měli ve virtuálním počítači připojení k internetu, kvůli aktualizacím systému. Tato možnost je v pravém menu pod položkou s názvem Správce virtuálních sítí. Přidáme externí virtuální síť, kterou si pojmenujeme. Vybereme síťovou kartu, která zprostředkovává připojení do internetu a zároveň zaškrtneme možnost: Povolit operačnímu systému správy sdílet tento síťový adaptér. Pokud budeme potřebovat sdílet soubory mezi virtuálním počítačem a hostujícím, vytvoříme ještě jednu virtuální síť, která bude nastavena jako interní s nezatrženou volbou Povolit identifikaci virtuální sítě LAN pro operační systém správy. Nyní přejdeme k samotnému vytváření virtuálního stroje. V nabídce Akce zvolíme menu Nová a podmenu Virtuální počítač. Spustí se nám přehledný průvodce novým virtuálním 24
Hyper-V je technologie od společnosti Microsoft a nedílná součást Windows Server 2008, která umožňuje více operačním systémům běžet na jednom fyzickém počítači jako virtuální počítače. Přesunutí málo vytížených serverů na menší počet fyzických počítačů snižuje náklady spojené se správou, nákupem hardware a platbami za energie. Navíc vzniká dynamičtější IT infrastruktura. [Microsoft Corp., 2011] 25 VirtualBox je multiplatformní open-source nástroj pro virtualizaci od společnosti Oracle, dříve Sun. Více na webové adrese: http://www.virtualbox.org/
55
počítačem. První krok je pouze informační, proto přejdeme na druhý krok, ve kterém se nastavuje název, který se bude zobrazovat v přehledu Virtuální počítače. Další volbou je umístění souborů nastavení virtuálního počítače, kromě VHD disku, tato cesta se nastavuje v samostatném kroku. Následující krok Přiřadit paměť neboli konfigurace velikosti RAM je velmi důležitý. Tato nabídka závisí na velikosti instance VM Role, na které budeme námi vytvářený virtuální počítač provozovat. Přidělená velikost RAM je shodná s ostatními dvěmi rolemi (Web a Worker) a můžeme ji najít v kapitole Windows Azure Compute. Já jsem zvolit extra small instance, tzn. budu chtít alokovat 768 MB RAM. Čtvrtým krokem je Konfigurace sítě, zde zvolíme připojení, které jsme si vytvořili konfigurací ve Správci virtuálních sítí. V následujícím kroku Připojit virtuální pevný disk, klikneme na nabídku Vytvořit virtuální disk, kde zapíšeme název, např. vmrole.vhd a zvolíme adresář, do kterého bude tento virtuální pevný disk vytvořen. Zbývá poslední nevyplněné textové polem Velikost, které musíme vyplňuje s ohledem na závislost velikosti instance VM Role dle dokumentace. Pro extra small instanci je maximální velikost 15 GB. V předposledním kroku volíme, zda chceme nainstalovat operační systém po dokončení průvodce nebo zda přiřazení obrazu instalačního disku provedeme sami. Zde volím Nainstalovat operační systém ze spouštěcího disku CD/DVD-ROM a vybírám možnost Soubor bitové kopie (ISO), kde zvolím cestu k obrazu instalačního disku Windows Server 2008 R2 64 bit EN s SP1, který je možné získat v některém ze zvýhodněných programů (DreamSpark, BizSpark, MSDN AA nebo MSDN Subscription). V posledním kroku můžeme všechny naše volby zkontrolovat a v případě, že jsou v pořádku, dokončit průvodce. Kliknutím vybereme námi vytvořený virtuální počítač a volbou vpravém menu Spustit a následně Připojit, spustíme a otevřeme okno virtuálního počítače. Pokud jsme vybrali možnost Nainstalovat operační systém, tak se spustí instalace Windows Serveru. Při instalaci neměníme lokální nastavení časového pásma a nastavení lokalizační (měny, čísla, atd.). Vše necháme, tak jak je a instalaci dokončíme. Jakmile je instalace dokončena vytvoříme si nový administrátorský účet, který si pojmenujeme. Důvodem je, že výchozí účet Administrátor bude po nasazení do cloudu z bezpečnostních důvodů automaticky vypnut. Povolíme vzdálenou plochu, abychom se v případě potřeby mohli k VM roli připojit. Přidáme roli s názvem IIS a funkce .NET Framework 3.5.1 Features a Windows Process Activation Service. Nainstalujeme vlastní software, který budeme chtít využívat na VM roli. V neposlední řadě nainstalujeme komponenty Windows Azure Integration a nastavíme spouštění služby Windows Azure Forwarder Service na opožděný start. Pokud jsme se vším hotovi, spustíme ze systémové složky operačního systému Windows, utilitu s názvem Sysprep, najdeme ji ve složce %windir%\System32\sysprep\sysprep.exe, která slouží k přípravě operačního systému na bitovou kopii na jinou stanici, v našem případě na Windows Azure Compute VM Role. Zvolíme možnosti dle následujícího obrázku:
56
Obrázek 19: System Preparation Tool (Sysprep)
4.4.5. Datová persistence V této části práce se snažím ukázat, jak konkrétně vypadá implementace Windows Azure Drive, který slouží například u VM role pro persistenci dat. Cílem je při naběhnutí VM role (při naběhnutí OS Windows Server, který je provozován virtualizovaný na VM roli), spustit službu, která se postará o namapování pevného disku, jehož fyzické úložiště je v podobě VHD souboru uloženém na Windows Azure Storage blobu. Ve chvíli, kdy je disk namapován, se služba snaží připojit databázi, která je uložena na tomto disku v podobě databázového MDF souboru. Jedině tímto způsobem je možné provozovat např. vlastní bezplatný SŘBD Microsoft SQL Server 2008 R2 Express a umožnit, aby data byla i po přesunutí na jiný fyzický server z důvodu HW výpadku nebo odstranění této VM role zachována. Toto řešení bylo konzultováno s komunitou vývojářů a IT profesionálů Windows Azure26 a je to jediný způsob, jak z pohledu best practice zajistit persistenci dat u VM role. Způsobem, že jsou data uložena v cloudu, nikoliv v souborovém systému VM role. Důvodem tohoto řešení je reálná potřeba provozovat bankovní systém, který umožňuje komunikaci s bankou a je hostován na Windows Azure VM roli z vynucené potřeby, že aktuální verze tohoto systému neumožňuje připojení k databázi hostované na SQL Azure. Podmínkou je tedy vlastní lokální databáze na stejném serveru jako je umístěna aplikace. using using using using using
Toto téma bylo probírané na komunitních stránkách Microsoftu a StackOverflow [Zeng, 2011]. V době vlastní potřeby řešení tohoto problému, jsem nenalezl jedinou reálnou implementaci, proto jsem ji sám vytvořil. Zdrojový kód bude dostupný komunitě vývojářů ze stránek CodeProject (http://www.codeproject.com/), pod některou z licencí open-source, pokud mě někdo jiný v pozitivním smyslu nepředběhne a nepublikuje vlastní řešení.
using Microsoft.WindowsAzure; using Microsoft.WindowsAzure.ServiceRuntime; using Microsoft.WindowsAzure.StorageClient; using Microsoft.SqlServer.Management.Common; using Microsoft.SqlServer.Management.Smo;
Kromě naimportovaných jmenných prostorů System.* jsou zajímavé zejména Microsoft.WindowsAzure.*, které najdeme v Azure SDK a Microsoft.SqlServer.*, které jsou součástí instalace SQL Serveru. namespace WindowsAzureDriveService { public partial class WindowsAzureDriveService : ServiceBase { private CloudDrive currentDrive;
Třída WindowAzureDriveService musí dědit ze třídy ServiceBase, protože vytváříme Windows Service. Proměnná currentDrive je jedna z nejdůležitějších proměnných v této službě. Slouží pro práci s Azure Drive. private readonly EventWaitHandle statusCheckWaitHandle = new ManualResetEvent(false); private volatile bool busy = true; private const int ThreadPollTimeInMilliseconds = 1000;
Všechny tyto tři datové atributy slouží pro zajištění případného prodloužení časového intervalu vypršení platnosti (timeout) služby u metody OnStart() služby Windows, která ve výchozím nastavení má interval vypršení 30 sekund. Metoda OnStart() by neměla sloužit pro provádění rozsáhlých příkazů. public WindowsAzureDriveService() { InitializeComponent(); RoleEnvironment.Changed += new EventHandler(RoleEnvironment_Changed); RoleEnvironment.StatusCheck += new EventHandler(RoleEnvironment_StatusChe ck); }
58
WindowsAzureDriveService() je konstruktor stejnojmenné třídy, ve kterém v prvním pořadí musíme zavolat metodu InitializeComponent(), která vytvoří instance objektů, které byly přidány pomocí návrháře (Designeru). Umožňuje vytvářet kód způsobem Drag&Drop z již vytvořených komponent. Tento konstruktor je automaticky vytvořen, pokud zvolíme vytvořit projekt ze šablony Windows Service. Další dva řádky kódu jsou tzv. delegáti, mající za úkol zachytávat události a reagovat na ně. RoleEnvironment.Changed reaguje na změnu vyvolanou za běhu VM role v souboru ServiceConfiguration.cscfg. RoleEnvironment.StatusCheck reaguje na změnu stavu VM role. Stavy jsou dva, Ready nebo Busy. private void RoleEnvironment_Changed(object sender, RoleEnvironmentChangedEventArgs e) { if (!e.Changes.OfType().Any(c => c.ConfigurationSettingName == "WindowsAzureDriveService.BlobPath")) return; try { var oldDrive = this.currentDrive; var newDrive = MountDrive(); try { AttachDatabase(newDrive.LocalPath); } catch (Exception) { UnmountDrive(newDrive); throw; } this.currentDrive = newDrive; UnmountDrive(oldDrive); } catch (Exception ex) { throw; } }
Obsah metody reagující na změnu nastavení v *.cscfg souboru. Kontroluje, zda nedošlo ke změně nastavení zdrojové cesty k obrazu disku VHD pro Azure Drive uloženém v Azure Storage Page Blobu. V případě, že ke změně došlo, pokusí se namapovat virtuální disk z nového umístění. Pokud se mu to povede, tak připojí k SQL Serveru databázi, která je na tomto disku přítomna. Dojde-li v první fázi k chybě, tuto chybu vypíše, dojde-li k chybě při připojení databáze, disk pouze odmapuje a chybu vypíše. 59
V prvním kroku metody MountDrive() je volána metoda GetStorageCredentials(), která vrátí přístupové údaje k Windows Azure Storage. V druhém kroku si načte pomocí další statické metody URI cestu k VHD souboru. Na třetím řádku dojde k vytvoření instance voláním konstruktoru třídy CloudDrive a předání dvou parametrů cesty k VHD souboru a přístupových údajů (jména a hesla, které je šifrované pomocí algoritmu RSA). Následuje namapování disku a uložení písmena jednotky, pod kterou je disk namapován (v případě prvního Azure Drive, je to písmeno B). Při namapování disku se předávají dva parametry, první z nich velikost cache a druhým je způsob namapování. Zajímavé možnosti jsou především tyto dvě: None a Force. Druhý jmenovaný má za úkol nejprve odmapovat disk u jiné instance VM Role. Návratovým typem je CloudDrive, který tato metoda na konci všech příkazů vrací. private Uri GetDriveUri() { return new Uri(string.Format(RoleEnvironment.GetConfigurationSettingValue("WindowsA zureDriveService.BlobPath"), RoleEnvironment.CurrentRoleInstance.Id)); }
Tato metoda vrací z nastavení *.cscfg URI adresu k VHD souboru uloženém v Azure Storage Page Blobu. private StorageCredentialsAccountAndKey GetStorageCredentials() { return new StorageCredentialsAccountAndKey(RoleEnvironment.GetConfigurationSettingV alue("WindowsAzureDriveService.AccountName"), RoleEnvironment.GetConfigurationSettingValue("WindowsAzureDriveService.A ccountKey")); }
Tato metoda vrací StorageCredentialsAccountAndKey, což jsou přístupové údaje k Azure Storage, které máme uložené v konfiguračním souboru *.cscfg. private void UnmountDrive(CloudDrive drive) { drive.Unmount(); }
60
Metoda UnmountDrive odmapuje virtuální disk, který je předán parametrem. private ServerConnection GetDatabaseConnection() { string sqlConnection = @"Server=.\SQLEXPRESS;User Id=UzivatelskeJmeno;Password=Heslo;Trusted_Connection=False;"; ServerConnection connection = new ServerConnection(new SqlConnection(sqlConnection)); return connection; }
Metoda sloužící pro získání informací o spojení do SQL Serveru27. Pokud chceme zjistit connection string do všemožných SŘBD, doporučuji web: http://www.connectionstrings.com/ private void AttachDatabase(string drivePath) { StringCollection databaseFilesPath = new StringCollection(); databaseFilesPath.Add(drivePath + "gemini.mdf"); Server server = new Server(GetDatabaseConnection()); server.AttachDatabase("gemini", databaseFilesPath); }
Metoda AttachDatabase slouží pro připojení databáze k databázovému systému. V parametru dostane cestu k jednotce již namapovaného Azure Drive, ke které je připojen název souboru s databází, v našem případě gemini.mdf. Při vytváření nové instance z třídy Server voláme již zmiňovanou metodu pro získání informací o připojení k SŘBD. private void DetachDatabase() { Server server = new Server(GetDatabaseConnection()); server.DetachDatabase("gemini", true); }
DetachDatabase je metoda pro odpojení databáze od databázového systému a volá se v případě ukončení činnosti služby, ať již z důvodu úmyslného zastavení služby nebo v případě výskytu chyby. protected override void OnStart(string[] args) { /// Windows Azure waits for auto-start services to be fully started /// before sending any traffic. Service Control Manager (SCM) does /// not impose a time limit on startup; the service need only /// request additional time. 27
Ukládání nešifrovaných přístupových údajů uvnitř zdrojového kódu, není doporučováná best practise. Přístupové údaje je možné skladovat v souboru Web.Config respektive App.Config a zároveň je nechat šifrovat např. pomocí metod ze třídy RSAProtectedConfigurationProvider nacházející se ve jmenném prostoru System.Configuration.
61
if (!RoleEnvironment.IsAvailable) { return; } else { OnStartInternal(); //// wait until a status check has occurred, so that Windows Azure //// knows we are working on something. WaitForHandle(statusCheckWaitHandle); } }
Při startu služby WindowsServiceAzureDrive se spustí první metoda OnStart(). Prvním příkazem zkontroluje, zda je kód prováděn pod některou z rolí Windows Azure, pokud ano spustí metodu OnStartInternal(). private void OnStartInternal() { try { LocalResource localCache = RoleEnvironment.GetLocalResource("vmRoleStorage"); CloudDrive.InitializeCache(localCache.RootPath, localCache.MaximumSizeInMegabytes / 2); this.currentDrive = MountDrive(); AttachDatabase(this.currentDrive.LocalPath); this.busy = false; } catch (Exception ex) { this.EventLog.WriteEntry(ex.ToString(), EventLogEntryType.Error); throw; } }
Metoda OnStartInternal() vykonává hlavní část služby. Nejdříve se pokusí inicializovat cache pro Azure Drive pomocí lokálního datového úložiště. Namapuje Azure Drive, následně připojí databázi k databázovému systému a ohlásí, že je již hotova. private void WaitForHandle(WaitHandle handle) { while (!handle.WaitOne(ThreadPollTimeInMilliseconds)) {
Metoda WaitForHandle se volá v případě, kdy je exekuován kód uvnitř metody OnStart(), aby v případě potřeby zažádala o více času na provedení kódu a nedošlo k přerušení startovací fáze služby. protected override void OnStop() { OnStopInternal(); } protected override void OnShutdown() { OnStopInternal(); }
Metoda OnStop() je volána v případě ukončení služby. Metoda OnShutdown() je volána v případě vypnutí operačního systému. Obě dvě metody zavolají metodu OnStopInternal(). private void OnStopInternal() { try { if (this.currentDrive != null) { DetachDatabase(); UnmountDrive(this.currentDrive); this.currentDrive = null; } } catch (Exception ex) { this.EventLog.WriteEntry(ex.ToString(), EventLogEntryType.Error); throw; } }
Metoda OnStopInternal() se nejdříve pokusí odpojit databázi od SŘBD a na závěr odmapuje virtuální disk Windows Azure.
4.4.6. Nasazení VM Role Po nasazení nebo restartu VM role není možné delší dobu použít nástroj Připojení ke vzdálené ploše (Remote Desktop, RDP) a komunikovat tak po protokolu RDP. Vlastním používáním jsem přišel na to, že po 2-3 dnech se tato vlastnost opět vrátí do normálu a je možné využít vzdáleného přístupu. Čekat takovouto dobu ovšem není pro administrátora možné. Naštěstí však existuje velmi jednoduché řešení tohoto problému. Je potřeba přenastavit způsob spouštění jedné konkrétní Windows Service z automatického startu na 63
start automatický se zpožděním. Spustíme Service Management Consoly (services.msc) a v ní najdeme službu s názvem Windows Azure Remote Forwarder Service a nastavíme ji typ spouštění na hodnotu automaticky (zpožděné spuštění).
Obrázek 20: Nastavení zpožděného spuštění služby Windows Azure Remote Forwarder
4.5. Odlišnosti v provozování aplikací na Windows Azure 4.5.1. Synchronizace on-premise SQL Serveru s SQL Azure Data uložená v databázi SQL Azure je možné poskytnout každé aplikaci, která má připojení k Internetu. Ale i tak je v mnoha případech výhodnější uložit kopii těchto dat na jiné místo. Vezměme si organizace, které potřebují lokální kopie dat například z výkonnostních důvodů nebo pro případ havárie sítě. V takovýchto případech je výhodné využívat možnosti synchronizace dat v databázi SQL Azure s daty na jiném místě. V prostředí Microsoft Sync Framework můžeme kód pro synchronizaci kdykoli napsat sami. Pro usnadnění práce nabízí Microsoft komponentu SQL Azure Data Sync. Abychom nemuseli psát kód sami, je tato technologie zcela řízena konfigurací (není překvapením, že vychází z prostředí Microsoft Sync Framework). Jak je znázorněno na následujícím obrázku, dnešní SQL Azure Data Sync podporuje dvě možnosti:
64
Obrázek 21: SQL Azure Data Sync [Chappel, 2010]
Jde o tyto dvě možnosti synchronizace:
Synchronizace dat mezi databází SQL Azure a lokální databází serveru SQL. Lokální kopie cloudových dat může být žádoucí z mnoha důvodů. V případě některých dat předpisy nařizují, aby byla jejich kopie nepřetržitě k dispozici na území státu. Někdy je potřeba, aby byla data přístupná nepřetržitě, a to i v případě výpadku sítě. Vestavěná replikace dat SQL Azure sice chrání data vůči poruchám hardware, ale vlastník dat se chce vyhnout administrativní chybě, například odstranění nesprávné tabulky, a proto dá přednost lokální kopii.
Synchronizace dat mezi databázemi SQL Azure v různých datových centrech společnosti Microsoft. Řekněme, že dodavatel software nebo podnik s celosvětovou působností vytvoří aplikaci, kterou používají uživatelé na různých místech světa. Aby byla aplikace dostatečně výkonná pro všechny uživatele, tvůrce rozhodl, že aplikace bude běžet ve třech různých datových centrech Windows Azure, v Severní Americe, v Evropě a v Asii. Ukládá-li aplikace data do databáze SQL Azure, může data v těchto třech centrech synchronizovat pomocí služby SQL Azure DataSync.
Služba SQL Azure Data Sync používá model „hub-and-spoke“ (v terminologii počítačových sítích jde o model hvězda). Všechny změny jsou zkopírovány nejdříve do centrální synchronizační databáze SQL Azure (hub), a potom do ostatních databází (spoke, označováno také jako člen). Členy mohou být jiné databáze SQL Azure nebo databáze lokálních serverů SQL. V obou případech umožňuje tato technologie synchronizaci buď celé databáze, nebo jen některých tabulek. Změna kterékoli kopie bude propagována všem ostatním prvkům hvězdy. Synchronizaci lze spustit ručně, ovšem SQL Azure Data Sync nabízí také službu plánování. Můžeme naplánovat například synchronizaci dvojice 65
databází s frekvencí jednou za hodinu. I když se způsoby využití služby synchronizace dat mohou lišit, její funkce je tatáž. Poskytuje možnost přímé synchronizace dat mezi databází SQL Azure v datovém centru společnosti Microsoft a dalšími databázemi na jiných místech.
4.5.2. Dynamické škálování Škálovatelnost je jedním ze základních pilířů Cloud computingu, přesto Windows Azure v té verzi, v jaké funguje v době psaní diplomové práce, nemá zabudovaný žádný sebeřídící mechanismus, jakým by bylo možné dosáhnout dynamického škálování. Tím pádem není možné výkon zvyšovat a snižovat dynamicky na základě již zabudovaného algoritmu měření zátěže, a tím tak snížit náklady nebo naopak zvýšit potřebný výkon. Proč tomu tak je? Na dané téma byla vedena celá řada diskuzí. Microsoft absenci dynamického škálování odůvodnil tím, že by nebylo možné předem predikovat měsíční náklady na provoz Windows Azure a tyto náklady účtovat zákazníkovi, ale že tato funkcionalita je zachována tím, že službu je možné velmi jednoduše škálovat pomocí konfiguračního XML souboru, případně prostřednictvím Windows Azure Platform Management Portalu. Máme tři možnosti, jak vyřešit absenci zabudovaného dynamického škálování ve Windows Azure. První možností je napsat si danou funkcionalitu sami, jelikož máme přímý přístup přes API, můžeme si vytvořit aplikaci, která bude vytvářet respektive rušit instance sama dle naměřených hodnot zátěže přímo z logovacích souborů stažených přes API [Fultz, 2010]. Tato možnost mi nepřijde příliš vhodná, protože již existují open source i placené projekty, které to již vyřešili za nás a jsou prověřené mnohými uživateli. V době psaní diplomové práce jsou dostupné dva následující open source projekty a dva komerční.
Windows Azure Hosted Services VM Manager je aplikace běžící na platformě Windows Azure, která sleduje jiné aplikace a na základě předem definovaných pravidel mění jejich počty instancí [Gipson, 2011]. Pomocí této aplikace je možné škálovat na základě zatížení procesoru, případně předem připraveného časového rozvrhu. Tato aplikace byla vyvinuta jako součást projektu pro Pracovní úřad státu Idaho a je poskytována jako open source.
Windows Azure Dynamic Scaling (AzureScale) je další hojně využívaná aplikace na dynamické škálování. Vytvořili ji dva SW architekti Grzegorz Gogolowicz a Trent Swanson, oba zaměstnanci Microsoftu, kteří jí vydali jako open source [Grzegorz, a další, 2010+. Má velmi podobné možnosti škálování jako předcházející popisovaná aplikace.
AzureWatch je aplikace od firmy Paraleap Technologies, která umožňuje dynamické škálování rozšířené oproti open source nástrojům o přehledný dashboard, dril-down reporty a grafy, emailové alerty a pokročilé nastavení pravidel. 66
ManageAxis je aplikace od firmy Cumulux, tato firma nabízí kromě této pokročilé aplikace na dynamické škálování i další nástroje provozované v cloudu a rovněž i školení, které se orientuje na aktuálně největší poskytovatele cloud řešení.
4.5.3. Monitoring aplikací v cloudu Proč bychom měli monitorovat Windows Azure, když má vlastní mechanismus pro automatické restartování role, případně jejich přesun na jiný hardware? Monitorování jednotlivých rolí ve Windows Azure je vhodné především k plánování a nastavování počtu těchto rolí. Jelikož jsem v teoretické části práce psal, že Windows Azure neobsahuje vnitřní algoritmus pro dynamické škálování, je potřeba škálovat ručně. Ruční škálování především vyžaduje kontinuální sledování jednotlivých rolí a jeho následné vyhodnocování a reagování na něj v podobě nastavování počtu instancí rolí a jejich velikostí. Případně změnu limitu velikosti databáze, apod. Zde platí ITILovské28: „co můžeme měřit, můžeme zlepšovat“. [Office of Government Commerce (OGC), 2007] Než přistoupíme k samotné problematice monitorování, je nezbytné provést nastavení na straně Windows Azure k jeho zprovoznění. Windows Azure Diagnostics umožňuje shromažďovat diagnostická data z aplikací běžících na Windows Azure. Tato data je možné využít pro ladění chyb, řešení problémů, měření výkonu a zátěže a také pro plánování a především k řízení škálování pronajatého cloudu. Data jsou shromažďována a ukládána v naplánovaných intervalech ve Windows Azure Storage kvůli jejich zachování a následném vyhodnocování. Výhodou tohoto přístupu je, že mohou být dostupné externím aplikacím, které s nimi mohou nakládat a zobrazovat je např. v populárních dashboardech.
Obrázek 22: Populární webová služba pro dashboardy GeckoBoard [GeckoBoard, 2011] 28
ITIL (Infrastructure library) je soubor konceptů a postupů, které umožňují efektivní řízení IT.
67
Existuje celá řada možností a zdrojů, ze kterých Windows Azure Diagnostics shromažďuje data. Následující tabulka tyto možnosti přehledně zobrazuje. Datový zdroj
Výchozí nastavení
Logování Windows Azure
Nastaveno (vyžaduje přidání trace listener do souboru web.config respektive app.config) Nastaveno Nastaveno
Logování IIS 7.0 Logování infrastruktury Windows Azure Diagnostics Logování Failed Request Logování událostí Windows
Nenastaveno Nenastaveno
Performance counters
Nenastaveno
Crash dumps
Nenastaveno
Logování
Nenastaveno
Typ podporované role Web i Worker role Web role Web i Worker role Web role Web i Worker role Web i Worker role Web i Worker role Web i Worker role
Tabulka 7: Výchozí nastavení datových zdrojů a podporované typy rolí pro monitorování Windows Azure [Microsoft Corp., 2010]
K zapnutí všech těchto monitorovacích možností je zapotřebí udělat následující kroky: 1. V souboru ServiceDefinition.csdef přidat následující řádky.
2. Také přidat konfigurační nastavení a doplnit skutečné přístupové údaje k Windows Azure Storage, tzn. nahradit AccountName a AccountKey z údajů ve Windows Azure Platform Management Portal. <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="DefaultEndpointsProtocol=https;AccountName=AccountName;AccountKey =AccountKey"/>
3. Do Web.config, respektive do App.config, přidat následující nastavení. <system.diagnostics> <listeners>
68
4. Ve Visual Studio dát pravé tlačítko na roli, kterou chceme monitorovat a zvolit vlastnosti. V zálozče Nastavení povolit diagnostiku, rozkliknout další možnosti a vyplnit přihlašovací údaje. Další důležitou věcí je mít nastaven .NET trust level na Full trust, což je výchozí nastavení.
Obrázek 23: Povolení monitoringu Web a VM role ve Visual Studio 2010 SP1
69
Microsoft System Center Operations Manager 2007 R229 je specializovaný nástroj pro komplexní monitoring různorodých systémů, serverů (aplikačních, databázových), podnikových aplikací, atd., které jsou vlastněny nebo mají dohodu o spolupráci se společností Microsoft. Já jsem si vybral tento nástroj pro monitorování Windows Azure. Spustíme MSCOM přes Operations Console. Přejdeme do sekce Administration tak, že v levém menu klikneme na záložku Administrace (Administration). Poté z pravého menu Akce (Actions) vybereme možnost importovat management balíček (Import Management Pack). Z průvodce Import Management Packs stiskneme tlačítko přidat (Add). Služba se připojí k online katalogu management balíčků. V dalším okně necháme nastaven filtr na zobrazování všech balíčků v katalogu a stiskneme tlačítko vyhledat. Rozklikneme Microsoft Corporation, dále Windows Azure Platform než se dostaneme na samotný balíček Windows Azure. Stisknutím tlačítka přidat ho přidáme, potvrdíme průvodce a dáme instalovat. V levém menu přejdeme na záložku Authoring a z pravého menu vybereme možnost Add monitoring Wizard, čímž spustíme průvodce přidáním monitoringu. Pokud jsme správně provedli konfiguraci aplikace provozovanou pod jednou s Windows Azure rolí, zmiňovanou na začátku této kapitoly, můžeme přejít do sekce Monitoring a sledovat níže uvedené hodnoty a atributy. Seznam vlastností a činností, které můžeme monitorovat:
29
Deployment State View – zobrazuje zdraví jednotlivých nasazení
Hosted Service State View – zobrazuje stav všech hostovaných služeb
Role State View – zobrazuje stav všech rolí
Role Instance State View – zobrazuje stav všech instancí
Active Alerts View – zobrazuje všechna upozornění Windows Azure
Zobrazení výkonu – zobrazení výkonu všech instancí rolí
Výkon ASP.NET
Kapacita disku
Využití paměti
Využití síťového adaptéru
Využití procesoru
Výkon instancí rolí
Více informací o Microsoft System Center Operations Manager najdeme zde: [Microsoft Corp., 2011]
70
Následující KPI pro Windows Azure dostupné pro každou roli jsou automaticky sledovány a ukládány každých 5 minut: •
Počet požadavků ASP.NET za sekundu
•
Počet přijatých bytů po síti za sekundu
•
Počet odeslaných bytů po síti za sekundu
•
Zatížení procesoru v %
•
Volné místo na disku v Mb
•
Volné místo na disku v %
•
Velikost dostupné paměti v Mb
Obrázek 24 zobrazuje celkové zatížení procesorů u Web rolí, tzv. performance counters. Máme nasazenou webovou aplikaci na dvě instance XS (extra small) Web rolí. Jak vidíme na ose X je čas a na ose Y je celková zátěž procesorů v %. Jak již bylo uvedeno zobrazení můžeme libovolně konfigurovat. Výpadek zhruba kolem půlnoci způsobilo opětovné nasazení aplikace bez využití přechodu ze stagingového prostředí do produkčního.
Obrázek 24: SCOM: měření zatížení všech procesorů u Web rolí
Kromě monitorování si můžeme nastavit automatická upozornění na určitou událost, např. že zatížení procesoru přesáhlo hodnotu 80% po dobu 5 minut, volné místo na disku je nižší než 1 GB, atd. Upozornění může přijít emailem, sms. Podmínkou je však nastavení SMTP brány respektive sms brány. Díky těmto automatickým upozorněním nemusíme 71
monitorovat stav Windows Azure rolí příliš často a můžeme se spolehnout na to, že pokud upozornění máme dobře nastavená tak, že vykonávají značnou část práce se správou sami. Jediným naším úkolem zůstává vykonání regulujícího zásahu, např. zvýšení / snížení počtu nebo velikostí instancí rolí. Podobné zásahy můžeme díky aplikačnímu rozhraní provádět přes Windows Azure Platform Management Tool (MMC)30 konzoly z OS Windows, podobně jako jsme například zvyklí spravovat Windows Server nebo i desktopový OS. Projekt je dostupný jako opensource, takže můžeme část kódu využít i u vlastní automatizace těchto procesů. Dovedu si představit situaci, že místo pouhého odesílání emailu s upozorněním, že zatížení procesoru rolí přesáhlo námi nastavený limit, necháme spustit kód, který automaticky navýší instanci role o jedna. Nebo situaci, že v případě, kdy celý minulý týden nepřesáhla zátěž procesoru hodnotu 20%, necháme jednu roli vypnout, zároveň si o tom necháme zaslat zprávu. Dle dostupných informací, které Microsoft prezentoval na konferenci Tech-Ed Berlin 2010 se již připravuje nová verze Microsoft System Center Operations Manager s označením 2012, nacházející se v době psaní dimplomové práce ve vývojovém stadiu CTP. Od této nové verze se očekává ještě lepší podpora Windows Azure a samozřejmě další vylepšení. Pokud se nám zdá nástroj MSCOM příliš komplexní, což se nám zdát může, protože zdaleka jeho možnosti monitoringu se neomezují pouze na Windows Azure, můžeme využít nástroj od společnosti Cerebrata, který je specializován pouze na Windows Azure a všechny jeho ovládací prvky jsou tomu uzpůsobené. Nástroj od firmy Cerebrata je samozřejmě i o hodně levnější, z důvodu jeho zaměření oproti SCOM. Výhodou SCOM je však, že pokud firma, která by ho chtěla využívat a je členem některého z programů Microsoftu, má slevu nebo tento SW zdarma, např. pokud je firma členen programu Microsoft BizSpark. Nástroj od firmy Cerebrata nese jméno Azure Diagnostics Manager, čímž je přesně vystihnuto, jaké služby tento nástroj nabízí. Další informace jsou dostupné zde: http://www.cerebrata.com/Products/AzureDiagnosticsManager/
30
Windows Azure Platform Management Tool je dostupný z Codeplexu: http://wapmmc.codeplex.com/
72
5. Závěr Diplomová práce se týkala problematiky Cloud computingu, konkrétně byla zaměřena na platformu Microsoft Windows Azure. Práce si kladla za cíle analyzovat Cloud computing, charakterizovat platformu Windows Azure, charakterizovat odlišnost aplikací v cloudu oproti on-premise aplikacím a na základě těchto charakteristik a analýz stanovit doporučení umožňující transformaci aplikace do prostředí Cloud computingu za předpokladu využití platformy Microsoft, která je dodána jako služba. Prvním cílem práce bylo analyzovat Cloud computing. Práce přináší vzory zátěže, které jsou typické pro aplikace efektivně provozované v Cloud computingu a nabádá, aby aplikace, které mají být hostovány v cloudu, měly tyto znaky. Případně, aby motivem hostování v cloudu byl některý z motivů popisovaný v kapitole. Pokud je tento požadavek dodržen, jsou aplikace v cloudu hostované efektivněji a přináší mnohé finanční i časové úspory. V teoretické části práce jsou analyzovány a charakterizovány služby Windows Azure, především Compute, Storage, AppFabric a SQL Azure, což je druhým cílem diplomové práce. Tato část přináší důležité informace pro správné pochopení, jaké služby využít při odlišných scénářích. V praktické části práce jsou předloženy poznatky, jak vytvořit ekonomickou a technickou analýzu aplikace, tak abychom zjistili, zda je výhodné a vůbec technicky možné danou aplikaci migrovat na Windows Azure. Z ekonomické analýzy vyplynulo, že provozování aplikace v cloudu na Windows Azure bude o 46% efektivnější z pohledu nákladů. Další přínos praktické části práce je analýza a charakteristika odlišností vývoje, nasazení a provozování aplikací, které umožňují transformaci aplikace do prostředí Cloud computingu za předpokladu využití platformy Microsoft Windows Azure. Na základě těchto znalostí byla reálná aplikace transformována do cloudu, aby tyto znalosti byly ověřeny a naplněn daný cíl práce. Reálná aplikace byla ve své iterační fázi vývoje úspěšně transformována na PaaS a přes Microsoft Platform Ready portál obdržela povolení nést označení „Powered by Windows Azure“.
73
Praktické znalosti jsem si ověřil při aktivní účasti na Microsoft Azure Akademii II.
74
Největší výzvou k ověření znalostí o Windows Azure byla programátorská soutěž Rock, Paper, Azure! od Microsoftu, která se konala v USA. Naštěstí bylo možné se zúčastnit na dálku pomocí Internetu. Soutěž spočívala v naprogramování autonomního bota, který měl za úkol bojovat proti ostatním botům v modifikované hře: kámen, nůžky, papír, dynamit a vodní balón. Vyhrál ten, jehož bot se dokázal sám „učit“ a přizpůsobovat strategii tak, aby porážel ostatní. V prvním týdnu soutěže můj bot dokázal porazit 52 soutěžících, kdy okusil pouze jedinou porážku a to ho předurčovalo k vítězství, kterého dosáhl.
75
6. Terminologický slovník Termín Amazon Elastic Compute Cloud Amazon Simple Storage Service Amazon Web Services Cloud computing
Data as a Service
Infrastructure as a Service
On-premise
Open Data Protocol
Platform as a Service
Zkratka Amazon EC2
Význam [zdroj] Cloud computing od společnosti Amazon. Služba poskytující výpočetní výkon, obdoba Windows Azure Compute u Microsoftu. Amazon S3 Služba na ukládání dat v cloudu od společnosti Amazon. Podobná Windows Azure Storage u Microsoftu. AWS Souhrnné označení pro cloud PaaS poskytovaný společností Amazon. CC „Cloud computing je model umožňující pohodlný přístup ke sdíleným konfigurovatelným výpočetním prostředkům (sítě, servery, datová úložiště, aplikace a služby) odkudkoliv, tzv. on demand. Tyto prostředky mohou být využívány nebo opouštěny s minimálním úsilím v řízení a komunikaci s dodavatem služby. Model Cloud computingu zvyšuje dostupnost. Je tvořen pěti základními charakteristikami, třemi modely služeb a čtyřmi modely nasazení.“ *Mell, a další, 2011+ DaaS Poskytování dat uložených v cloudu jako služba. V případě společnosti Microsoft se jedná o službu, která nesla kódové označení Dallas, dnes se jmenuje DataMarket a je součástí Windows Azure Marketplace. IaaS Jedinou věcí, kterou zákazník nemá pod kontrolou, ale o kterou se zároveň nemusí starat, je hardwarová infrastruktura. [Mell, a další, 2011+ Aplikace nebo služby nasazené a řízené společností v jejich vlastních prostorách [Redkar, 2010] OData OData je protokol pro publikování dat, který díky návrhovému vzoru REST, formátu ATOM (standard využívající jazyk XML pro publikování obsahu, nejčastěji používán pro kanál novinek RSS) a JSON (JavaScript Object Notation způsob zápisu dat) umožňuje interoperabilitu mezi jednotlivými platformami. PaaS Zákazník nenastavuje ani nekontroluje infrastrukturu (síť, servery, operační systémy, datová úložiště), ale má kontrolu nad svojí 76
Service Level Agreement
SLA
Software as a Service
SaaS
Virtualizace
Windows Azure
Windows Server Update Services
WSUS
nasazenou aplikací a také nad možnou konfigurací aplikačního prostředí. [Mell, a další, 2011+ Smlouvy o poskytování služeb vymezují relativně exaktně obchodní a kooperační vztahy mezi jednotlivými subjekty vstupujícími do provozu a rozvoje podnikové informatiky. *Pour, a další, 2009+ Zákazník nenastavuje ani nekontroluje infrastrukturu (síť, servery, operační systémy, datová úložiště, na které jsou aplikace provozovány. Jediné nastavení, které může měnit, je vlastní přizpůsobení těchto aplikací. *Mell, a další, 2011+ Virtualizace umožňuje na jeden server umístit mnoho operačních systémů a aplikací (konsolidace serverů), které jsou od sebe izolované, čímž se zvýší vytížení serverů a sníží jejich potřebný počet. Tímto je možné dosáhnout nejenom snížení nákladů na nákup HW, ale i nákladů na provoz. Cloud computing od společnosti Microsoft spadající převážně do kategorie PaaS, s výjimkou VM Role, u které převažují charakteristiky IaaS. Je služba běžící na Windows Serveru, jejímž úkolem je spravovat distribuci aktualizací vydávaných prostřednictvím služby Microsoft Update do počítačů v síti.
77
7. Citovaná literatura Amazon.com Inc. 2011. Timeline and History. Amazon.com. [Online] 2011. [Citace: 7. 6 2011.] http://phx.corporate-ir.net/phoenix.zhtml?c=176060&p=irol-corporateTimeline. Bittman, Thomas J. 2009. Virtualization Unlocks Cloud Computing. Gartner Inc. [Online] 11. 8 2009. [Citace: 23. 6 2011.] http://blogs.gartner.com/thomas_bittman/2009/08/11/virtualization-unlocks-cloudcomputing/. Borenstein, N., Bellcore a Freed, N. 1993. MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. *Online+ září 1993. *Citace: 27. 6 2011.+ http://tools.ietf.org/html/rfc1521. Buyya, Rajkumar, Broberg, James a Goscinski, Andrzej M. 2011. Cloud Computing: Principles and Paradigms. místo neznámé : Wiley, 2011. ISBN 9780470887998. Cisco Systems, Inc. 2011. Cloud Computing. [Online] 2011. [Citace: 7. 6 2011.] http://www.cisco.com/en/US/netsol/ns976/index.html. Depena, Ray. 2010. Top 30 Cloud Service Providers Gaining Mind Share in 3Q 2010. Cloud computing Journal. [Online] 29. 8 2010. [Citace: 7. 6 2011.] http://cloudcomputing.syscon.com/node/1513491. Erl, Thomas, a další. 2010. SOA with .NET & Windows Azure: Realizing Service-Orientation with the Microsoft Platform. New Jersey : Prentice Hall, 2010. str. 871. 9780131582316. Fielding, R., Irvine a Gettys, J. 1999. Hypertext Transfer Protocol -- HTTP/1.1. [Online] 1999. [Citace: 27. 6 2011.] http://www.w3.org/Protocols/rfc2616/rfc2616.html. Fultz, Joseph. 2010. Performance-Based Scaling in Windows Azure. MSDN Magazine. *Online+ Září 2010. *Citace: 27. 6 2011.+ http://msdn.microsoft.com/enus/magazine/gg232759.aspx. Gartner, Inc. 2010. Gartner Identifies the Top 10 Strategic Technologies for 2011. [Online] 19. 10 2010. [Citace: 14. 6 2011.] http://www.gartner.com/it/page.jsp?id=1454221. —. 2010. Magic Quadrant for Cloud Infrastructure as a Service and Web Hosting. [Online] 22. 12 2010. [Citace: 8. 6 2011.] http://c1776742.cdn.cloudfiles.rackspacecloud.com/downloads/pdfs/GartnerMagicQuad rant.pdf. GeckoBoard. 2011. Geckoboard - Realtime Business Status Board. [Online] 2011. [Citace: 24. 5 2011.] http://www.geckoboard.com/.
78
Gipson, Greg. 2011. Windows Azure Hosted Services VM Manager. CodePlex Open Source Community. [Online] 16. 2 2011. [Citace: 27. 6 2011.] http://azureinstancemanager.codeplex.com/. Goldratt, Eliyahu M. 1997. Critical chain. 1997. ISBN 9780884271536. Goldratt, Eliyahu M., Cox, Jeff a Whitford, David. 2004. The goal: a process of ongoing improvement. 2004. ISBN 9780566086649. Grzegorz, Gogolowicz a Swanson, Trent. 2010. Windows Azure Dynamic Scaling Sample. MSDN. [Online] 28. 4 2010. [Citace: 27. 6 2011.] http://archive.msdn.microsoft.com/azurescale. Henriksen, Inge. 2011. Azure Membership, Role, Profile, and Session-State Providers. CodePlex: Open Source Community. [Online] 2011. [Citace: 27. 6 2011.] http://azureproviders.codeplex.com/. Chappel, David. 2010. Introducing the Windows Azure Platform. [Online] 2010. [Citace: 24. 1. 2010.] http://go.microsoft.com/?linkid=9752185. Chou, David C. 2011. Rise of the cloud ecosystems. Architecture + Strategy. [Online] 16. 3 2011. [Citace: 17. 3 2011.] http://blogs.msdn.com/b/dachou/archive/2011/03/16/rise-ofthe-cloud-ecosystems.aspx. Chou, Yung. 2011. Window Azure Fault Domain and Upgrade Domain Explained for IT Pros. Yung Chou on Windows Technologies. *Online+ Květen 2011. *Citace: 27. 6 2011.+ http://blogs.technet.com/b/yungchou/archive/2011/05/16/window-azure-fault-domainand-update-domain-explained-for-it-pros.aspx. Juřek, Michael a Kačmář, Dalibor. 2010. Azure akademie – 1. LEKCE: Windows Azure Platform. Czech MSDN Blog. [Online] Microsoft s.r.o., 5. 10. 2010. [Citace: 22. 1 2010.] http://blogs.msdn.com/b/vyvojari/archive/2010/10/05/azure-akademie-1-lekcewindows-azure-platform.aspx. —. 2011. Azure akademie II – 3. LEKCE: Windows Azure Platform. Czech MSDN Blog. [Online] Microsoft s.r.o., 22. 3 2011. [Citace: 22. 3 2011.] http://blogs.msdn.com/b/vyvojari/archive/2011/03/22/materi-225-ly-praktick-253-250kol-ot-225-zky-a-odpov-di-ke-3-lekci-azure-akademie-ii.aspx. Kačmář, Dalibor a Juřek, Michael. 2010. Ekonomické výhody využívání cloudu. *Online+ Microsoft, s.r.o., Listopad 2010. [Citace: 13. 6 2011.] http://download.microsoft.com/download/2/D/0/2D0D53DF-7D41-4B0D-828E562AC4906762/Vyhody_vyuzivani_cloudu.pdf. Kačmář, Dalibor. 2011. Zrychlete přístup k obsahu pomocí Azure CDN. Kačiho platformový blog. [Online] 24. 3 2011. [Citace: 20. 4 2011.] 79
http://blogs.msdn.com/b/kaci/archive/2011/03/24/zrychlete-pristup-k-obsahu-pomociazure-cdn.aspx. Loo, Kaj van de a Wartenberg, Roland. 2010. Cloud computing and SAP: Where We Are and Where We're Going. SAP Insider. [Online] 2010. [Citace: 7. 6 2011.] http://specialfeatures.sapinsideronline.com/archive/spi_2010_3b_SAP.pdf. Mahtab, Ashic. 2011. Applied ASP.NET MVC 3 in Context. místo neznámé : Apress, 2011. ISBN 9781430234012. Mell, Petter a Grance, Timothy. 2011. The NIST Definition of Cloud Comptuing (Draft). [Online] National Institute of Standards and Technology, Leden 2011. [Citace: 16. 3 2011.] http://csrc.nist.gov/publications/drafts/800-145/Draft-SP-800-145_cloud-definition.pdf. Special Publication 800-145. Microsoft Corp. 2010. Debugging by Using Visual Studio. MSDN. [Online] 22. 11 2010. [Citace: 27. 6 2011.] http://msdn.microsoft.com/en-us/library/gg465388.aspx. —. 2011. How to Create the Base VHD for a VM Role in Windows Azure. Microsoft Developer Network. [Online] 8. 3 2011. [Citace: 17. 5 2011.] http://msdn.microsoft.com/en-us/library/gg465391.aspx. —. 2010. Initializing and Configuring Diagnostic Data Sources. MSDN Windows Azure Platform. [Online] 22. 11 2010. [Citace: 24. 5 2011.] http://msdn.microsoft.com/enus/library/gg433009.aspx. —. 2010. Moving an ASP.NET Application from IIS 6.0 to IIS 7.0. MSDN. [Online] 2010. [Citace: 27. 6 2011.] http://msdn.microsoft.com/en-us/library/bb515251.aspx. —. 2011. Operations Manager 2007 R2. Microsoft System Center. [Online] 2011. [Citace: 27. 6 2011.] http://www.microsoft.com/cze/systemcenter/operations-manager/. —. 2011. Storing and Accessing Data in Windows Azure. MSDN. [Online] 2011. [Citace: 27. 6 2011.] —. 2011. Unsupported Transact-SQL Statements (SQL Azure Database). MSDN. [Online] 2011. [Citace: 27. 6 2011.] http://msdn.microsoft.com/en-us/library/ee336253.aspx. —. 2011. Virtualizace s Hyper-V. [Online] 2011. [Citace: 17. 5 2011.] http://www.microsoft.com/cze/windowsserver2008/hyperv.mspx. —. 2011. Windows Azure. MSDN Windows Azure Platform. [Online] Microsoft Corp., 8. 3 2011. [Citace: 11. 4 2011.] http://msdn.microsoft.com/en-us/library/dd179367.aspx. —. 2010. Windows Azure Management Pack Guide for Operations Manager 2007 R2. [Online] 11 2010. [Citace: 23. 5 2011.] 80
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=acde41c6-153a-4181912e-78024fcc86da. MSV, Janakiram. 2010. Demystifying The Cloud: An introduction to Cloud Computing. 2010. http://www.janakiramm.net/blog/download-the-ebook-demystifying-the-cloud. Nethi, Dinakar, a další. 2010. Comparing SQL Server with SQL Azure. Microsoft TechNet Wiki. [Online] 2. 6 2010. [Citace: 27. 6 2011.] http://social.technet.microsoft.com/wiki/contents/articles/comparing-sql-server-withsql-azure.aspx. Office of Government Commerce (OGC). 2007. ITIL: Continual Service Improvement. místo neznámé : Stationery Office, 2007. 9780113310494. Pace, Eugenio, a další. 2010. Developing Applications for the Cloud on the Microsoft® Windows Azure™ Platform. patterns & practices. místo neznámé : Microsoft Press, 2010. str. 168. http://msdn.microsoft.com/en-us/library/ff966499.aspx. 978-0-7356-5606-2. —. 2010. Moving Applications to the Cloud on the Microsoft Azure™ Platform. patterns & practices. místo neznámé : Microsoft Press, 2010. str. 176. http://msdn.microsoft.com/en-us/library/ff728592.aspx. 978-0-7356-4967-5. Pallman, David. 2011. Azure Storage Samples. CodePlex Open Source Community. *Online+ Únor 2011. *Citace: 27. 6 2011.+ http://azurestoragesamples.codeplex.com/. Pour, Jan, Gála, Libor a Šedivá, Zuzana. 2009. Podniková informatika. 2. přepracované a aktualizované vydání. místo neznámé : Grada, 2009. str. 496. 978-80-247-2615-1. Redkar, Tejaswi. 2010. Windows Azure Platform. New York : Apress, 2010. str. 624. 9781430224792. Reese, George. 2009. Cloud Application Architectures: Building Applications and Infrastructure in the Cloud. místo neznámé : O'Reilly Media, 2009. str. 208. 9780596156367. Ruest, Danielle a Ruest, Nelson. 2010. Virtualizace - podrobný průvodce. místo neznámé : Computer press, a.s., 2010. str. 408. 9788025126769. Staten, James a Schreck, Galen. 2009. Assess Your Infrastructure Virtualization Maturity. místo neznámé : Forrester Research, Inc., 10. 7 2009. Staten, James, a další. 2008. Is Cloud Computing Ready For The Enterprise? Forrester Research. [Online] 28. 3 2008. [Citace: 22. 1. 2010.] http://www.forrester.com/rb/Research/is_cloud_computing_ready_for_enterprise/q/id/ 44229/t/2?src=46613pdf.
81
Váša, Petr. 2010. Od virtualizace ke cloud computingu. místo neznámé : Economia, Červen 2010. Windows Azure Team. 2010. Windows Azure Team Blog. Beta Release of Windows Azure Drive. [Online] Microsoft, 1. 2 2010. [Citace: 11. 4 2011.] http://blogs.msdn.com/b/windowsazure/archive/2010/02/02/beta-release-of-windowsazure-drive.aspx. Youngman, K. J. 2009. A Guide to Implementing the Theory of Constraints (TOC). [Online] 2009. [Citace: 27. 6 2011.] http://www.dbrmfg.co.nz/Overview%20Introduction.htm. Zeng, Wenchao. 2011. SQL Query from Azure Web Role to SQL Server 2008 R2 Express hosted on VM Role. MSDN Windows Azure. [Online] 16. 5 2011. [Citace: 27. 6 2011.] http://social.msdn.microsoft.com/Forums/enUS/windowsazureconnectivity/thread/c7124598-4894-4b6c-8987-709a9f788ea4.
82
8. Seznam tabulek Tabulka 1: Velikost jednotlivých instancí Azure Compute................................................... 22 Tabulka 2: Porovnání SQL Azure vs. Azure Storage *Juřek, a další, 2010+ ........................... 28 Tabulka 3: Porovnání technologií Azure Storage *Juřek, a další, 2010+ ............................... 29 Tabulka 4: Rozmístění serverů Azure CDN *Kačmář, 2011+ ................................................. 37 Tabulka 5: Virtualizační technologie .................................................................................... 54 Tabulka 6: Závislost velikosti instance VM Role a maximální velikosti namapovaného obrazu disku [Microsoft Corp., 2011] .................................................................................. 55 Tabulka 7: Výchozí nastavení datových zdrojů a podporované typy rolí pro monitorování Windows Azure [Microsoft Corp., 2010] ............................................................................. 68
83
9. Seznam obrázků Obrázek 1: Konvergence různorodých technologií umožňujících Cloud computing *Buyya, a další, 2011+ .......................................................................................................................... 9 Obrázek 2: Modely poskytování služeb *Chou, 2011+ ......................................................... 14 Obrázek 3: Vzory zátěží optimálních pro cloud *Juřek, a další, 2010+ ................................. 17 Obrázek 4: Architektura Windows Azure Platform [Microsoft Corp., 2011] ...................... 20 Obrázek 5: Ukázka programu Azure Storage Explorer ........................................................ 27 Obrázek 6: Topologie SQL Azure *Juřek, a další, 2011+........................................................ 30 Obrázek 7: Model služby SQL Azure *Juřek, a další, 2011+ .................................................. 31 Obrázek 8: Postup ve vyhledávání a získávání přístupu ke službě prostřednictvím servisní sběrnice Azure AppFabric *Chappel, 2010+ ......................................................................... 32 Obrázek 9: Schéma procesu přístupu ke službě pomocí Azure AppFabric Access control [Chappel, 2010] .................................................................................................................... 34 Obrázek 10: Schéma přístupu aplikací k datům prostřednictvím služby Azure AppFabric Caching [Chappel, 2010] ...................................................................................................... 36 Obrázek 11: Porovnání latence na různých místech světa při použití on-premise, Windows Azure Blob a Windows Azure Blob s aktivním CDN *Kačmář, 2011+ ................................... 39 Obrázek 12: Windows Azure Marketplace *Chappel, 2010+................................................ 40 Obrázek 13: Architektura Windows Azure Marketplace DataMarket [Chappel, 2010] ...... 41 Obrázek 14: Výpočet měsíčních nákladů na provoz aplikace na Windows Azure .............. 45 Obrázek 15: Výpočet ROI ..................................................................................................... 47 Obrázek 16: Windows Azure Migration Scanner ................................................................. 50 Obrázek 17: Ukázkový výstup z aplikace WAMS ................................................................. 50 Obrázek 18: Windows Azure Management Portal přechod aplikace ze stagingového prostředí do produkčního .................................................................................................... 53 Obrázek 19: System Preparation Tool (Sysprep) ................................................................. 57 Obrázek 20: Nastavení zpožděného spuštění služby Windows Azure Remote Forwarder . 64 Obrázek 21: SQL Azure Data Sync *Chappel, 2010+ ............................................................. 65 Obrázek 22: Populární webová služba pro dashboardy GeckoBoard *GeckoBoard, 2011+ 67 Obrázek 23: Povolení monitoringu Web a VM role ve Visual Studio 2010 SP1 .................. 69 Obrázek 24: SCOM: měření zatížení všech procesorů u Web rolí ....................................... 71
