Univerzita Hradec Králové Fakulta informatiky a managementu katedra informatiky a kvantitativních metod

DIPLOMOVÁ PRÁCE

Analýza výkonnosti cloud computingové infrastruktury

Autor: Michael Kutý

Studijní obor: Aplikovaná informatika

Vedoucí práce: Ing. Vladimír Soběslav, Ph.D Hradec Králové, 2016 Prohlášení

Prohlašuji, že jsem diplomovou práci vypracoval samostatně a uvedl jsem všechny použité pra- meny a literaturu.

V Hradci Králové dne 29. srpna 2016 Michael Kutý

ii Poděkování

Rád bych zde poděkoval Ing. Vladimíru Soběslavovi, Ph.D za odborné vedení práce, podnětné rady a čas, který mi věnoval. Také bych rád poděkoval své rodině a přátelům za trpělivost a morální podporu během celého studia.

iii Anotace

Diplomová práce se zaměřuje na problematiku měření a porovnávání výkonnosti clou- dových platforem a poskytovatelů. Cílem této práce je představit základní kvantitativní znaky a charakteristiky cloudových služeb a následně navrhnout a implementovat soft- ware pro automatizované testování a sběr dat z libovolných platforem a poskytova- telů. Nástroj bude využit pro testování vybraných poskytovatelů veřejného cloudu a výsledná data budou použita pro následné srovnání.

Annotation

This master thesis focuses on performence measurement and comparison of various cloud platforms and providers. The goal of this master thesis is to introduce the prin- ciples and terminology for performence evaluation of cloud platforms on a theoretical level and in a real world examples. The first part of practical part focuses on the descrip- tion of the architecture designed solutions and in next part will be tested and compared selected cloud providers.

iv Obsah

1. Úvod 1 1.1. Cíl a metodika práce ...... 1 1.2. Definice a použité pojmy ...... 2

2. Cloud computingové služby 4 2.1. Definice cloud computingových služeb ...... 4 2.1.1. Distribuční modely cloudových služeb ...... 4 2.1.2. Modely nasazení cloudových služeb ...... 6 2.2. Výkon cloudových služeb ...... 7 2.2.1. Oblasti měření výkonu ...... 10 2.2.2. Problémy s měřením výkonu ...... 13 2.3. Testovací scénáře ...... 13 2.3.1. Poskytovatelé cloudu ...... 14 2.3.2. Uživatelé cloudu ...... 14 2.4. Poskytovatelé cloudových služeb ...... 15 2.4.1. Google Cloud Platform ...... 15 2.4.2. Amazon Web Services ...... 15 2.4.3. OpenStack ...... 16 2.4.4. Azure ...... 17

3. Hodnocení výkonu cloudových služeb 18 3.1. Měření výpočetního výkonu ...... 18 3.1.1. Testovací nástroje ...... 19 3.1.2. Významné charakteristiky ...... 20 3.2. Měření výkonu paměti ...... 20 3.2.1. Testovací nástroje ...... 20 3.2.2. Významné charakteristiky ...... 22 3.3. Měření diskového výkonu ...... 22 3.3.1. Testovací nástroje ...... 22 3.3.2. Významné charakteristiky ...... 23 3.4. Měření síťového výkonu ...... 23 3.4.1. Testovací nástroje ...... 23 3.4.2. Významné charakteristiky ...... 24 3.5. Doménově specifické ...... 24 3.5.1. Testovací nástroje ...... 25 3.5.2. Významné charakteristiky ...... 26

v Obsah

3.6. Orchestrátory testů ...... 26 3.6.1. PerfKit Benchmarker ...... 27 3.6.2. Cloud Rapid Experimentation and Analysis Toolkit ...... 27 3.6.3. Faban ...... 28

4. Architektura testovacího řešení 29 4.1. Modul sběru dat ...... 29 4.1.1. Jenkins ...... 31 4.1.2. Job builder ...... 32 4.1.3. Postup testování ...... 34 4.1.4. Konfigurace testů ...... 34 4.2. Modul analýzy dat ...... 36 4.2.1. Normalizace měřených dat ...... 37 4.3. Modul vizualizace dat ...... 38 4.3.1. Tabulkové zobrazení ...... 38 4.3.2. Zobrazení v grafu ...... 38

5. Test vybraných cloudových služeb 40 5.1. Výběr testovaných instancí ...... 40 5.2. Testovací prostředí ...... 41 5.3. Zpracování naměřených dat ...... 42 5.3.1. Výpočetní výkon ...... 42 5.3.2. Síťový výkon ...... 42 5.3.3. Diskový výkon ...... 44 5.3.4. Výkon paměti ...... 44 5.4. Srovnání pro vybrané scénáře ...... 45 5.4.1. Srovnání pro aplikační servery ...... 46 5.4.2. Srovnání pro databázové servery ...... 47

6. Závěr 49 6.1. Možnosti dalšího výzkumu ...... 50 6.1.1. Test více typů instancí ...... 50 6.1.2. Srovnávací algoritmy ...... 50 6.1.3. Podpora dalších nástrojů ...... 50

Literatura 51

PřílohyI

A. Celkový souhrn výsledků testů II

vi 1. Úvod

V současné době existuje na trhu velké množství cloudových platforem, poskytovatelů a nástrojů pro provoz aplikací ve virtualizovaném prostředí. Výběr vhodné platfromy z hlediska výkonu je pro softwarového inženýra nebo manažera proto velmi kompli- kovaný. Existuje množství vědeckých prací a postupů, které se zabývají problematikou srovnávání cloudových služeb [1], [7], [33]. Mnoho z nich je však založeno na složitých matematických modelech. To je také důvod, proč nejsou výrazně rozšířeny a většina z nich není používána v praxi. Výběr cloudové platformy pak ve společnostech neprobíhá systematicky a často při- pomíná spíše náhodný proces, který ve většině případů končí výběrem první možnosti z mnoha poskytovatelů, a to bez ohledu na analýzu kvalitativních znaků jednotlivých prvků výběru.

1.1. Cíl a metodika práce

Cílem této práce je představit základní kvalitativních znaky a charakteristiky cloudo- vých služeb. Hlavní oblastí výzkumu jsou infrastrukturní cloudové služby (IaaS), které přímo ovládají hardwarové prostředky a mají bezprostřední vliv na výkon provozo- vané aplikace, případně ostatních virtuálních cloudových služeb, které jsou na IaaS službách závislé. Praktická část práce je zaměřena na návrh a implementaci jednoduché aplikace pro běh automatizovaných testů výkonu, které jsou schopné otestovat velké množství cloudových platforem a získat data pro další zpracování. Výstupem běhu testovací aplikace jsou strukturovaná data, které budou dále využita pro systematický popis a výběr nejvhodnější cloudové platformy. Díky těmto přístu- pům jsme schopni automatizovaně a opakovaně testovat a měřit důležité charakteris- tiky IaaS služeb. Na základě těchto dat pak lze provádět kvalifikované výběry. Druhá kapitola detailně popisuje jednotlivé cloudové služby, jejich definice, rozdě- lení a modely použití. Třetí kapitola popisuje základní kvantitativní charakteristiky in- frastrukturních cloudových služeb a nástroje, které jsou vhodné pro měření dané cha- rakteristiky. Čtvrtá kapitola popisuje architekturu a způsob realizace navržené aplikace pro opakované pouštění definovaných testovacích scénářů. Pátá kapitola pak popisuje vybrané infrastrukturní služby, naměřené testovací hodnoty a jejich analýzu. Poslední

1 Definice a použité pojmy kapitola uzavírá tuto práci návrhem dalších možností výzkumu. Cloudové platformy nemají jednotné API a postup klientského přístupu. Každá clou- dová platforma je jedinečná, liší se možnostmi použité virtualizační platformy, topolo- gií sítě, použitým diskovým úložištěm. Pro každé testování systému je nutné vytvořit testovací scénář a jedinečný model, který detailně definuje potřebné servery, sítě a soft- warové služby pro běh testu. V souvislosti s tím pak vyvstávají otázky, které jsou cílem této práce.

∙ Jak identifikovat vhodný virtuální stroj od různých poskytovatelů cloudových služeb?

∙ Který typ virtuálního stroje dokáže obsloužit největší počet uživatelských poža- davků za nejnižší cenu?

Pro vypracování praktické části byl použit nástroj Jupyter, který umožňuje zápis funkcí v jazyce Python s možností okamžitého spuštění a úpravy kódu. Díky jednot- nému formátu zápisu kódu testovacích aplikací, je možné je snadno sdílet včetně kon- figurací, scénářů a ukázkových výsledků. Všechny použité skripty a výsledky jsoudo- stupné v přílohách.

1.2. Definice a použité pojmy

V současné době není terminologie měření cloudových služeb dobře definována. Různé zúčastněné strany z ICT oboru používají stejné pojmy s mírně odlišnými (někdy si od- porujícími nebo překrývajícími se) významy. Na vině může být široká škála oblastí, kde se informační a komunikační technologie (software, telekomunikace, průmysl) uplat- ňují. Každá oblast má svou vlastní historii a používá vlastní jazyk pro popis věcí. Ná- sledující výčet vysvětluje základní definice a pojmy, které jsou nezbytné k porozumění textu této práce.

Metrika Je pojem popisující vybranou kvantitativní charakteristiku. Spolu s vlastní nu- merickou hodnotou definuje potřebné metadata: jednotku měření, čas měření, místo sběru, informace o sběrovém agentu, transformačním agentu, atd.

Jednotka měření Je kvantitativní (číselné) zkoumání geometrických, fyzikálních a dal- ších vlastností předmětů (jevů, procesů), obvykle porovnáváním s obecně přija- tou jednotkou. Výsledkem měření je tedy číslo, které vyjadřuje poměr zkoumané veličiny k jednotce spolu s uvedením jednotky. Všechny jednotky jsou definovány co nejblíže SI standardům.

2 Definice a použité pojmy

Vlastnost cloudové služby Měřitelná a popsatelná vlastnost cloudové služby. Vlast- nost může být popsána kvalitativně nebo kvantitativně.

Test/Benchmark Běh jednoho nebo více programů či jiných operací za účelem zjištění relativního výkonu testovaného prostředí.

3 2. Cloud computingové služby

Poskytovatelé cloudů nabízejí své služby v několika základních modelech. Mezi hlavní modely patří následující: infrastruktura jako služba (IaaS), platforma jako služba (PaaS) a software jako služba (SaaS), container jako služba (CaaS) nebo databáze jako služba (DBaaS), obecně cokoliv jako služba (XaaS), kde jako službu můžeme považovat jakou- koliv službu s existujícím aplikačním rozhraním, kterou lze spravovat. IaaS model je na nejnižší úrovni, nejblíže k hardwaru a slouží jako základní vrstva pro poskytování ostatních cloudových služeb. Tato kapitola blíže popisuje rozdělení, modely a posky- tovatele cloudových služeb.

2.1. Definice cloud computingových služeb

V následující sekci jsou stručně popsány jednotlivé distribuční modely a typy nasazení, které jsou dalším předmětem zkoumání této práce. Cloud computingové služby mů- žeme dělit podle dvou základních charakteristik:

∙ podle distribučního modelu cloudových služeb,

∙ podle modelu nasazení cloudových služeb.

2.1.1. Distribuční modely cloudových služeb

Distribuční model vypovídá o tom, co je v rámci služby nabízeno, zda jde o software, hardware či jejich kombinaci. V této sekci jsou blíže rozebrány distribuční modely, které jsou dále předmětem této práce. Následuje stručné shrnutí hlavních distribučních mo- delů nejenom cloudových služeb, které mohou být předmětem dalšího srovnávání.

Infrastruktura jako služba (IaaS) Nejzákladnější model poskytování cloudových slu- žeb nabízí servery [12], fyzické nebo častěji virtuální a další virtualizované zdroje. Virtualizační hypervisor (Xen, KVM) provozuje virtuální stroje. Skupiny hyper- visorů v rámci cloudu mohou provozovat velké množství virtuálních strojů a mají schopnost škálovat poskytované služby v závislosti na měnících se požadavcích přicházejících od zákazníků. IaaS cloudové platformy nabízejí často i další služby

4 Definice cloud computingových služeb

jako jsou virtuální disky, blokové a souborové úložiště, virtuální sítě nebo ba- lancery pro rozložení zátěže. Poskytovatelé IaaS cloudových platforem provozují rozsáhlé datacentra, kde poskytují tyto zdroje. Je to virtualizace celé IT infrastruk- tury, kde IaaS kombinuje administraci virtualizace na úrovni operačních systémů a přidává navíc možnost spravovat síťové služby, diskové úložiště a další služby. Příklady: Amazon EC2, OpenStack, CloudStack

Platforma jako služba (PaaS) V modelu Platforma jako služba (PaaS) hostují posky- tovatelé cloudových služeb počítačovou platformu ve formě operačního systému [12], prostředí pro běh určitého programovacího jazyka, databáze a webového serveru. Vývojáři aplikací mohou provozovat a případně vyvíjet softwarová ře- šení bez výrazných nákladů, složitého nákupu, a to konfigurací potřebného hard- waru a softwaru. Některé PaaS platformy nastavují výpočetní a úložné prostředky aplikace automaticky tak, aby odpovídala aktuálním požadavkům aplikace bez nutnosti zásahu uživatele. Virtualizace na úrovní aplikační platformy PaaS [12] tvoří prostředí vhodné pro provoz webových aplikací vytvořených v moderních programovacích jazycích (např. Java, Python nebo Go). Příklady: OpenShift, Heroku, Google App Engine, Windows Azure

Software jako služba (SaaS) V modelu SaaS provozují poskytovatelé cloudových slu- žeb aplikační software v cloudu [12] a uživatelé k tomuto softwaru přistupují po- mocí klientského software (např. webového prohlížeče). Uživatelé cloudu tedy nespravují infrastrukturu ani platformu, kde aplikace běží. Není proto třeba in- stalovat a spouštět cloudové aplikace na vlastních počítačích uživatele, což velmi zjednodušuje údržbu. Cloudové aplikace se liší od ostatních aplikací v možnos- tech škálování, kterého může být dosaženo díky distribuci úkolů na více virtuál- ních strojů, a tím je možno reagovat na měnící se poptávku. Tento proces je pro uživatele služby transparentní, uživatel vidí pouze jeden přístupový bod pro da- nou aplikaci. Příklady: SalesForce, Aldryn

Uložiště jako služba (STaaS) Správa existujících zařízení pro ukládání dat může být nepohodlná a časově náročná. Virtualizace úložiště umožňuje využívání fyzic- kého úložiště ve více zařízeních síťových úložišť a vytvoří tak dojem, že se jedná o jedno zařízení pro ukládání dat, které se ovládá z centrální konzoly. Toto ře- šení správcům značně usnadňuje a urychluje provádění úkolů rozšiřování, zá- lohování, archivování nebo obnovování díky tomu, že skryje složitost adminis- trace síťového úložiště (SAN). V základu jsou fyzické zdroje agregovány přes síť do souborů (poolů), které tvoří základ logického úložiště. Díky tomu je možné,

5 Definice cloud computingových služeb

aby více fyzických zdrojů vystupovalo pro koncové uživatele jako jedno mono- litické úložiště [8]. Hlavní výhodou diskové virtualizace je izolování aplikací od nižších hardwarových vrstev, kde a jak jsou disky fyzicky zapojeny, což zlepšuje dostupnost a zjednodušuje správu systému. Zkracuje se také čas, kdy je služba nedostupná, podporuje zálohy, migrace a možnost zvyšování kapacity[2]. Příklady: OpenStack Swift, S3

2.1.2. Modely nasazení cloudových služeb

Vlastní využití cloudů může probíhat několika způsoby [18]. Veřejné a komunitní cloudy může používat jeden nebo více zákazníků. Privátní cloudy slouží většinou pro po- třeby jednoho zákazníka a je většinou provozován na jeho vlastní infrastruktuře. Po- slední model kombinuje možnosti předchozích řešení a umožňuje propojovat cloudové služby různých poskytovatelů do jednoho řešení.

Veřejný cloud Veřejné cloudové aplikace [18], výpočetní výkon, úložiště a další služby jsou k dispozici široké veřejnosti poskytovatelem služby. Služby jsou poskyto- vány zdarma nebo podle modelu platby za množství použitých zdrolů. Je zvy- kem, že veřejní poskytovatelé cloudových služeb, jako je Amazon AWS, Microsoft nebo Google, vlastní a provozují hardwarovou infrastrukturu a nabízejí k ní pří- stup pouze přes Internet.

Komunitní cloud V rámci komunitního cloudu [18] sdílí infrastrukturu cloudu ně- kolik organizací, které mají společné zájmy (bezpečnost, legislativa, působnost, atd.). Komunitní cloud může být spravován interně nebo prostřednictvím třetí strany. Stejně tak může být hostovaný interně nebo externě. Náklady jsou rozlo- ženy mezi méně uživatelů než na veřejném cloudu.

Privátní cloud Privátní cloud [18] je infrastruktura provozována výhradně v rámci jedné organizace. Může být spravována interně nebo prostřednictvím třetí strany a hostována opět interně nebo externě. Aby mohl podnik využít privátní cloud, musí nejprve virtualizovat celé své podnikatelské prostředí. Vlastní přechod vy- volává řadu bezpečnostních otázek, které je třeba řešit, aby se zabránilo vážným zranitelnostem celého řešení.

Hybridní cloud Hybridní cloud [18] je spojení dvou nebo více typů cloudů (soukro- mých, komunitních nebo veřejných), které zůstávají samostatné, ale jsou propo- jeny. Toto složení rozšiřuje možnosti nasazení cloudových služeb, a tím umož- ňuje IT organizacím využít veřejné cloudové prostředky k uspokojení dočasných potřeb. Tato schopnost umožňuje hybridním cloudům škálovat přes více nezá- vislých cloudů.

6 Výkon cloudových služeb

2.2. Výkon cloudových služeb

Metriky jsou číselným vyjádřením kvalitativních charakteristik cloudových služeb a poskytují nám základní informace o cloudovém řešení prostřednictvím jejich definice (jednotka, pravidla) a výsledných hodnot z empirických testů. Různé metriky mouhou sloužit pro různé účely, například doba odezvy může ovlivňovat rychlost služby, za- tímco poměr obsloužených dotazů k zahozeným dotazům charakterizuje kvalitu služby. V tomto kontextu hrají metriky zásadní roli v následujících úlohách:

∙ výběr cloudové služby,

∙ definování úrovně služeb,

∙ monitorování cloudových služeb,

∙ účetnictví a audit.

Obrázek 2.1.: Vztah vlastnosti a metriky, převzato a upraveno z [10]

Obrázek2.1 popisuje vztah mezi vlastností a její metrikou. Cloudová služba má vlast- nosti, které reprezentují jednotlivé charakteristiky této služby. Pro definování možností této služby je velmi důležité správně porozumět těmto vlastnostem. Jednou z možností jak porozumět těmto vlastnostem je prostřednictvím metrik. Tímto způsobem clou- dové metriky pomáhají poskytovatelům prezentovat vlastnosti jejich cloudového ře- šení, které jsou měřitelné a pomáhají tak zákazníkům s výběrem toho nejvhodnějšího, co nejlépe vyhovuje jejich požadavkům. Tyto výsledky mohou sloužit k nejrůznějším účelům. Metriky mohou být sbírány na různých vrstvách (hardware, logické servery, vrstva správy nebo na úrovni služby) nebo v různých etapách životního cyklu cloudové služby (vytváření, operace, migrace, změna velikosti).

7 Výkon cloudových služeb

Tyto metriky pro cloudové systémy na úrovni služby mohou být dále rozděleny podle [10] do tří hlavních oblastí:

∙ výběr služby,

∙ dohoda o službě,

∙ verifikace služby.

Metriky jsou důležitou součástí nejenom pro porozumění každé z těchto oblastí, ale spojují tyto oblasti v době výběru cloudového řešení. Tyto oblasti jsou blíže rozebrány.

Výběr poskytovatele

Metriky jsou základním kamenem pro rozhodování, která cloudová platforma či po- skytovatel bude nejlepší pro obchodní a technické požadavky zákazníka. Zákazník cloudového řešení by měl být schopný vybrat a měřit metriky, které mu pomohou roz- hodnout, která nabídka či platforma bude pro jeho potřeby nejlepší.

Obrázek 2.2.: Výběr cloudové platformy z pohledu zákazníka

Na obrázku 2.2 je zobrazen vztah metrik a zákazníka při výběru poskytovatele clou- dových služeb. Nejdůležitějším faktorem je správné vyhodnocení potřeb zákazníka a následný popis požadavků v podobě metrik a kritérií. Řešení jako Service Measure- ment Index (SMI) [7], vyvinutý Cloud Services Measurement Initiative Consortium (CSMIC) může být použito pro rozhodování o tom, které metriky jsou relevantní pro výběr cloudové nabídky. Z obrázku 2.2 je patrné, jak mohou být metriky použity pro porovnání či výběr mezi dvěma a více cloudovými nabídkami. Metriky také mohou

8 Výkon cloudových služeb poskytovat přehled o cloudových operacích jako je (výkon, odezva, škálovatelnost, do- stupnost). Tato data mohou být poskytována z různých nezávislých zdrojů, ať už jde o auditovací či monitorovací nástroje a spolu s informacemi o bezpečnosti, podpoře či finanční flexibilitě mohou být stěžejní pro posouzení výhodnosti cloudového poskyto- vatele.

Service Agreements

Service Agreements (SA) reprezentuje vztah mezi poskytovatelem a uživatelem služby. Tato smlouva může nabývat různých podob, ale v základu definuje práva a povinnosti pro obě zainteresované strany. Poskytovatel se prostřednictvím takové smlouvy zava- zuje k dodání služby včetně kritérií a postihů, které může zákazník uplatit v případě, že poskytovatel dané kritéria nesplní. Smlouva může obsahovat základní informace pro měření obchodních aspektů nebo výkonnostních aspektů cloudové služby. Definice a využití těchto metrik včetně jejich verifikace je základem pro Service Level Agreement (SLA) a and Service Level Objectives (SLO), které jsou složkami SA. Reference [13] a [15] do detailu popisují důležitost potřeby mít metriky v SLA smlouvách. Využívání standardizovaného seznamu metrik nebo šablon pro nové metriky usnad- ňuje a zrychluje definování SLA a SLO včetně jejich porovnání. Obrázek 2.3 ilustruje využití metrik pro podporu SLA, která definuje očekávání zákazníka a poskytovatele. Metriky usnadňují porozumění charakteristikám specifické cloudové platformy či na- bídky.

Obrázek 2.3.: Service level agreement (SLA)1

Monitorování služeb

Jakmile dojde k zaplacení cloudové služby zákazníkem, je důležité sledovat, zda jsou splněny všechny předdefinované požadavky podle smlouvy o úrovni služeb. Pokud

9 Výkon cloudových služeb služba nesplňuje tyto předdefinované požadavky, může na to zákazník reagovat vhod- ným způsobem, např. v podobě vymáhání náhrady škod podle sjednaných podmínek. Obrázek 2.4 popisuje službu poskytovanou zákazníkovi. V tomto případě jsou met- riky využity pro definování a verifikaci SLO.

Další případy užití

Poskytovatelé cloudových služeb měří interní metriky celého řešení, které jim mohou pomoci lépe porozumět aspektům výkonu platformy. Metriky, které měří samotní po- skytovatelé pro vlastní účely bývají zpravidla více technické. Reference [19] a [20] po- pisuje možné přístupy reprezentace a využití konceptu měření pro cloudové systémy. Výsledky z interních měření však nemusí být dostupné. Kromě metrik popisujících vý- kon a dostupnost, lze pomocí metrik popsat další aspekty cloudových platforem jako je bezpečnost či účetnictví. V neposlední řadě mohou být metriky využity jako důkazní materiál při dokazování porušení smlouvy SLA ze strany poskytovatele.

Obrázek 2.4.: Monitoring cloudové platformy

2.2.1. Oblasti měření výkonu

Práce se dál bude zabývat jen metrikami důležitými pro analýzu výkonu cloudových platforem. Podle obrázku architektury cloudové platformy 2.5 nás bude zajímat pře- devším výkon služeb potřebných pro samotnou virtualizaci, tedy výpočetní jednotky, sítě a datového úložiště. Existuje spousta dalších služeb a zdrojů jako jsou například databáze, kontainery a další, které však nejsou předmětem této práce.

10 Výkon cloudových služeb

Obrázek 2.5.: Obecná architektura cloudové platformy

Výpočetní výkon

Díky výpočetnímu výkonu je počítač schopný zpracovávat nejrůznější matematické úlohy. Výpočetní výkon tak udává počet operací v plovoucí řádové čárce za sekundu anglicky Floating-point Operations per Second (FLOPS). Tato metrika obecně popisuje výpočetní výkon hypervizoru. Negarantuje však požadované výsledky u provozované aplikace. Pokud tedy bude běžící aplikace náročná na datový tok, hraje výpočetní vý- kon menší roli. Jedná se o nejjednodušší testy, které měří pouze surový výkon daného stroje. U toho typu testů sledujeme pouze počet operací za sekundu.

Síť

Síťová infrastruktura je klíčový prvek ve výkonu cloudových platforem. S rozmachem distribuovaných real-time webových aplikacích se stává stabilní a rychlá síťová infrastruk- tura nutností pro běh aplikací. Pojmy jako SDN2, NFV3 přináší nové koncepty do clou- dového odvětví, které s sebou nesou i možné problémy se stabilitou a výkonností. U sítě sledujeme několik klíčových parametrů:

2Software Defined Networks 3Network Function Virtualization

11 Výkon cloudových služeb

Spolehlivost Počet paketů, které jsou v pořádku doručeny.

Propustnost Kolik paketů jsme schopni přes tuto síť přenést.

Odezva Jak rychle jsme schopni přenášet pakety.

Diskové úložiště

Poslední nejčastěji měřenou veličinou je výkon datového úložiště, které může před- stavovat samotné disky nebo diskové pole. Z pohledu cloudové platformy jsou disky nejvíce vytěžovaným zdrojem, protože na pevných discích může pracovat až několik klientů (virtuálních strojů) zároveň. Dochází tak k mnohem větší činnosti a opotřebení něž v běžném provozu. Důležité je také brát v úvahu charakter projektu či aplikace, pro které bude disk sloužit, je tedy nutné testovat více scénářů podle jejich specifického za- měření, například databáze a souborové úložiště mají rozdílné nároky na parametry a nemusí se jednat jenom o rychlost ploten. V cloudovém prostředí se nejčastěji setkáme s diskovými poli, které poskytují fle- xibilní řešení pro ukládání dat s možností změny disků podle potřeb apod. Takové diskové pole je potom prostřednictvím cloudových služeb nabízeno zákazníkům a nej- častěji jsou sledovány následující metriky:

∙ průměrná odezva,

∙ průměrná odezva pro čtení,

∙ průměrná doba pro zápis.

Na základě těchto metrik lze pak vypočítat výkon, který se udává v IOPS4

Počet požadavků

V době webových aplikací je jednou z nejpoužívanějších metrik pro výkon počet odba- vených požadavků za vteřinu. Měření počtu požadavků lze rozdělit do dvou sledova- ných veličin:

∙ počet odbavených požadavků za vteřinu,

∙ rychlost s jakou jsou požadavky odbaveny.

Díky své specializaci a zároveň jednoduchosti lze pomocí této metriky snadno vy- počítat potřeby, a to jedním z hlavním kritérií při sledování výkonu aplikace. Lze z něj aproximovat počet klientů, kteří mohou současně dotazovat měřenou službu.

4I/O operací za sekundu

12 Testovací scénáře

2.2.2. Problémy s měřením výkonu

Vzhledem k možné komplexitě cloudové platformy, je někdy velmi obtížné najít přímý zdroj problémů s výkonem. Ten může být způsoben na mnoha vrstvách od autentifi- kace až po jedno uzké hrdlo v hardwaru. Z pohledu virtuálního stroje, na kterém běží aplikace, je potom skoro nemožné zjistit příčinu, pokud je tzv. v cloudu a prostředky jsou sdílené mezi více virtuálními stroji. Protože jsou všechny zdroje zpravidla sdílené, reálně hrozí, že se virtuální stroje mohou navzájem ovlivňovat. Podle [5] je možné, aby vysoce využívaná aplikace ovlivňovala jiné aplikace, i když běží v jiném virtuálním stroji obr. 2.6.

Obrázek 2.6.: Vysoké vytížení jedné aplikace může přímo ovlivňovat výkon jiné apli- kace i když běží na dvou virtuálních strojích, převzato z [5]

2.3. Testovací scénáře

Prostřednictvím scénáře definujeme role (stakeholders) a jednotlivé případy užití tzv. use-case. Díky tomu lze snadno popsat jednotlivé úlohy, které je třeba vykonat. Příkla- dem scénáře může být výběr cloudového řešení. Prostřednictvím scénáře tak definu- jeme sled úkonů, které jsou vykonány v rámci jednoho testování. Spolu se scénářem de- finujeme model (kontext), který popisuje běhové prostředí, tzn. počet virtuálních strojů, lokace, poskytovatel apod. Díky tomuto oddělení lze znovu použít stejné scénáře pro více platforem a poskytovatelů. Výsledky testů jsou pomocí metrik interpretovány a mapovány zpět na scénáře pro snadnou verifikaci výsledků.

13 Testovací scénáře

Obrázek 2.7.: Vztah scénáře, měření a metriky

2.3.1. Poskytovatelé cloudu

Z pohledu poskytovatele cloudové platformy je primárním cílem dosahovat co nejlep- ších výsledků pro každou cloudovou službu, kterou poskytuje, např. virtuální stroje, datové úložiště, síť a další, při co nejmenších nákladech. Služeb je zpravidla velké množ- ství, proto vznikl pojem Infrastructure Response Time (IRT) [14]. IRT je vyvíjeno s cí- lem co nejlépe popsat výkonnost cloudového prostředí. IRT je pak definován jako čas potřebný k přijmutí a vykonání jakéhokoliv výkonnostního požadavku na virtuální prostředí. Jako příklad může posloužit jednoduchá datová výměna mezi dvěma služ- bami zahrnující např. databázové a diskové operace. Poskytovatelé cloudových řešení si cloudových řešení si nejčastěji kladou následující otázky.

∙ Jak rychle může být virtuální zdroj připraven ?

∙ Jak inicializace nového zdroje ovlivní výkon celé platformy ?

∙ Jaká je minimální cena za výkon zdroje, který jsou uživatelé ochotni zaplatit ?

2.3.2. Uživatelé cloudu

Pro koncové uživatelé bývá zpravidla nejdůležitější výkon samotné aplikace provozo- vané v cloudovém prostředí. Podobně jako IRT existuje Aplikační čas dopovědí (ART) [14], který je vypočítáván na základě rychlosti odpovědi aplikace na požadavky uživa- telů. Pro uživatele cloudu (zákazník, uživatel) je nejdůležitější výkon (maximální/prů- měrný) samotné aplikace a cena, kterou za takový výkon musí platit. Důležité otázky které si musí zákazník před výběrem položit jsou:

14 Poskytovatelé cloudových služeb

∙ Jaké benefit-cost ratio (BCR) je důležité? Průměrný, maximální nebo minimální výkon?

∙ Mění se BCR v průběhu času a je sezónní?

2.4. Poskytovatelé cloudových služeb

Následuje stručný popis hlavních poskytovatelů cloud computingových služeb. Se- znam je omezený na poskytovatele, kteří byli vybráni pro vlastní testování výkonu.

2.4.1. Google Cloud Platform

Google Compute Platform (GCP) je poměrně nová IaaS platforma od společnosti Go- ogle, která byla spuštěna v roce 2012. Na rozdíl od existující a vývojáři hojně využí- vané PaaS službě Google App Engine, tak reflektuje potřeby zákazníků. GCP poskytuje nejen virtuální stroje, které jsou unikátní především díky způsobu účtovaní. Účtování začíná po desáté minutě života stroje s minutovou inkrementací. Google tuto platformu aktivně vyvíjí a doplňuje o nové služby, jako kontainerové klustery, biq query a mnoho dalších služeb, které lze poskytovat prostřednictvím cloudových modelů.

Obrázek 2.8.: Architektua Google Compute Engine, licence CCA

2.4.2. Amazon Web Services

Jednou z prvních platforem, která byla uvedena do provozu, byla Amazon Web Servi- ces (AWS). Společnost Amazon hledala možnosti, jak využít serverové kapacity, které sama využívala jen především přes vánoční svátky. AWS se stejně jako společnost Go- ogle nezaměřuje jen na poskytování virtuálních strojů prostřednictvím EC2 (Elastic

15 Poskytovatelé cloudových služeb

Computer Cloud). Amazon ve svých Web Services nabízí např. úložiště S3 (Simple Sto- rage Service), které nabízí relativně neomezený úložný prostor a službu CDN - Content Delivery Network, při níž jsou data kopírována do uzlových serverů po celém světě a uživatelům jsou vždy poskytována z nejbližšího uzlu. AWS dále poskytuje dvě data- bázové služby, „SimpleDB“ (jednoduchá key-value databáze) a nedávno spuštěná RDS (Relational Database Service). Pro všechny tyto služby existuje API (Application Pro- gramming Interface), neboli aplikační programové rozhraní, takže je možné jejich pro- voz řídit programově, např. podle potřeby spouštět další servery.

2.4.3. OpenStack

Obrázek 2.9.: Architektua OpenStack

V červnu roku 2010 vytvořili společnosti Rackspace Hosting a NASA novou open source cloudovou iniciativu s názvem OpenStack. Do té doby se inženýři z NASA sna- žili vytvořit platformu Nebula, která koncepčně vycházela z projektu Eucalyptus, ale vzhledem k některým návrhovým nedostatkům tohoto řešení a nové neveřejné licenci se rozhodli pro vytvoření platformy vlastní pod názvem Nebula. Tomu pomohlo spo- jení s firmou Rackspace, vyvíjející platformu Cloud Files, která byla komplementární k nově vznikající aplikaci Nebula. Uvolnění existujícího kódu z NASA pod svobod- nou licenci byl nejistý proces, který do jisté míry usnadnila geografická blízkost obou subjektů. RackSpace i NASA sídlí v Houstonu v Texasu. Díky tomu byla první verze

16 Poskytovatelé cloudových služeb

OpenStack systému uvolněna pod licencí Apache, která dovoluje téměř neomezené po- užití kódu. První vydání projektu pod označením Austin bylo vydáno po čtyřech mě- sících s plány na pravidelný cyklus nových verzí každých několik měsíců. K tomuto IaaS projektu se od té doby připojilo více než 150 subjektů včetně firem jako IBM, HP, Cisco, Dell, Intel nebo Red Hat. Projekt adoptovali brzy i populární Linuxové distribuce Ubuntu Linux a Red Hat Linux. První firma, která nabízela veřejně dostupný cloud na platformě OpenStack je RackSpace. Dnes využívá platformu OpenStack pro své clou- dové řešení stále více poskytovatelů, proto je tato platforma zahrnuta v této práci. Pro testování tak byl vybrán cloud od české firmy Technologické Centrum Písek. Která po- skytuje veřejný cloud na platformě OpenStack s využitím KVM virtualizace.

2.4.4. Azure

Microsoft Azure je otevřená cloudová platforma, která umožňuje vyvíjet, nasazovat a spravovat aplikace v rámci celosvětové sítě datových center spravovaných firmou Microsoft [11]. Prostřednictvím této platformy Microsoft poskytuje nejrůznější služby stejně jako ostatní firmy především IaaS, PaaS a SaaS. První verze byla spuštěna roku 2008, a od roku 2010 je veřejně dostupná pro koncové uživatele. Od té doby prošla velkým vývojem. Zajímavostí u této platformy jsou především upravené linuxové dis- tribuce, pro které poskytuje Microsoft automatické záplatování. Díky podpoře linuxu microsoft plně využívá potenciál technologie Hyper-V, na které běží virtuální stroje. Windows Azure podporuje širokou šálu serverových technologií jako ASP.NET, PHP nebo Java. Webové služby obslouží servery IIS 7.5 s .NET framework. Scripty PHP má naopak na starosti rozhraní FastCGI. V současné době podporuje Azure i platformy Python.

Obrázek 2.10.: Architektua Azure, převzdato z [11]

17 3. Hodnocení výkonu cloudových služeb

Hodnocení výkonnosti cloudových služeb se v mnohém neliší od standardního testo- vání systémových a aplikačních služeb. Liší se pouze variabilitou testovaného prostředí a s ohledem na počet platforem a poskytovatelů, se z takového testování stává nelehký úkol. Testované prostředí se může lišit komplexitou, hardwarem, logickým zapojením, druhem virtualizace a mnoha dalšími aspekty. Existuje spousta publikací a přístupů, které se zabývají měřením aspektů výkonu cloudových služeb [21], [24], [27]. Samotné testování je ale založeno na generických nástrojích, které lze použit i mimo cloudové prostředí. Těchto nástrojů existuje celá řada a dají se rozdělit do tří základních kategorií:

Doménově nebo aplikačně specifické Do této kategorie spadají nástroje, které byly vyvinuty pro testování specifických oblastí, jako je například rychlost webových aplikací, vyhledávání nebo strojové učení. Mezi tyto nástroje se řadí CloudStone, CloudSuite, HiBench.

Syntetické nástroje SPECjvm2008 [28], iperf [31], SciMark FFT, Crypto AES, Crypto RSA, Spec CPU 2006 [32], Unixbench [34], HPCC [33], bonnie [36], CoreMark [37], netperf [40]

Orchestrátory Nástroje pro automatizované pouštění testů z předchozích dvou kate- gorií. Tyto nástroje se starají o běh a parsování výsledků ze samotných testovacích nástrojů. Většinou podporují více platforem a poskytovatelů. Tyto nástroje jsou vhodnými kandidáty pro srovnání více cloudových nabídek, především kvůli své variabilitě. Nástroje dokáží srovnávat v závislosti na ceně a výkonnostních poža- davcích. To usnadňuje výběr platformy či poskytovatele.

Nástrojů je samozřejmě mnohem více, ale pro potřeby této práce budou dále roze- brány jenom některé.

3.1. Měření výpočetního výkonu

Výpočetní výkon je základní měřenou veličinou. Nástroje procházejí výkon stejně jako vývoj procesoru za poslední desítky let. Instrukční sady se rozšiřují a i testovací nástroje se zlepšují. Žádoucí je například, aby byly nezávislé na velikosti paměti.

18 Měření výpočetního výkonu

3.1.1. Testovací nástroje

CoreMark

CoreMark je testovací nástroj zaměřený na výkon procesoru. Byl vyvinut v roce 2009 Shay Gal-On, ze společnosti EEMBC s ambicemi stát se standardem, který by nahradil Dhrystone. Kód je psaný v jazyce C a obsahuje implementace následujících algoritmů: hledání a řazení, operace s maticemi, CRC součty.

CloudCmp

CloudCmp je sada nástrojů pro testování výkonu cloudových platforem především po- skytovatelů veřejného cloudu [16]. Samotný nástroj je webová aplikace, kde si uživatelé vybírají testovací scénáře, které CloudCmp pouští a zpracovává výsledky. Nástroj tes- tuje několik základních oblastí jako je výpočetní výkon, diskové úložiště a síť. Tento nástroj se již nevyvíjí, ale stále lze najít práce, které jej využívají.

SciMark 2.0

SciMark 2.0 je nástroj pro testování napsaný v jazyce Java, navržený speciálně pro vě- decké a výpočetní úlohy [17]. SciMark je založen na několika výpočetních úlohách, jejichž výsledky jsou dále aproximovány do Mflops1. Nástroj lze spustit přímo z webo- vého prohlížeče nebo je možné stáhnout sadu testů na server a pustit je přímo tam. Nástroj poskytuje databázi s výsledky, která usnadňuje srovnání s ostatními.

Tachyon benchmark

Tachyon benchmark je používaný pro testování výkonu virtuálních strojů [35]. Tachyon škáluje i s přibývajícím počtem procesorů a je rychlejší než ostatní nástroje v této kate- gorii. Tachyon byl vybrán jako součást sady testů zvané SPEC MPI2007 [30]. Tachyon funguje na principu rendrování raytracingového paprsku v 3D scéně. Nástroj je rela- tivně nezávislý na velikosti paměti.

SPEC CPU2006

SPEC CPU2006[23] je standardizovaná sada nástrojů pro testování procesorů, paměti a kompilátorů. Sada obsahuje dvanáct různých nástrojů. Tento nástroj je placený a po- slední verze je z roku 2011.

1Milion operací s plovou řádovou čárkou za sekundu

19 Měření výkonu paměti

Tabulka 3.1.: Charakteristiky výpočetního výkonu

Test Metrika Jednotka Typ coremark coremark-score - delta scimark 2.0 composite-score Mflops delta

3.1.2. Významné charakteristiky

Vzhledem k licencím byly z výše popsaných nástrojů pro testování výpočetního vý- konu vybrány následující nástroje:

∙ CoreMark

∙ SciMark 2.0

Nástroj CoreMark poskytuje jenom jednu metriku a tou je naměřené skóre. Skóre se pak dá snadno porovnat s veřejně dostupnou databází výsledků.

3.2. Měření výkonu paměti

Nástroje pro testování výkonu paměti jsou často postavené na testování bufferů či uni- xové pajpy. Rychlost paměti může ovlivňovat několik faktorů mezi tyto faktory patří například počet procesorů nebo verze operačního systému.

3.2.1. Testovací nástroje

Stream benchmark

Nástroj Stream je jednoduchý nástroj, navržený pro měření rychlosti zápisu do paměti (v MB/s) pro čtyři jednoduché vektorové operace (kopírování, zvětšování, sčítání a sou- čin) [25]. Pro zkrácení času běhu tohoto testu lze podle Ramana [29] využít jenom me- todu součinu.

HPC Challenge Benchmark

HPC Challenge je kolekce testů zaměřených na výkon paměti a sítě. Zdrojový kód lze nalézt na HPCC SourceForge a HPCC Bitbucket stránkách. Tato kolekce obsahuje ná- sledujících 7 testů:

HPL test založený na řešení lineárních algebraických rovnic,

20 Měření výkonu paměti

DGEMM měří operace s plovoucí řádovou čárkou s dvojnásobnou přesností pro náso- bení dvou matic,

Stream měření rychlosti paměti, více v kapitole 3.2.1 ,

PTRANS (parallel matrix transpose) úloha, při které komunikují dva procesory záro- veň,

RandomAccess měří rychlost náhodného přístupu do paměti,

FFT měří rychlost operací při Discrete Fourier Transform (DFT),

Communication bandwidth and latency sada nástrojů pro měření odezvy a rych- losti sítě.

Unixbench

UnixBench s původním názvem BYTE UNIX benchmark suite je aktualizovanou open- source komunitou již dlouhé roky. Hlavní úlohou tohoto nástroje je poskytnout zá- kladní indikátory pro výkon unixových systémů. Nástroj je složen z několika dalších měřících nástrojů, díky čemu podává obrázek o mnoha výkonnostních aspektech da- ného systému, které lze následně porovnat s databází výsledků. Testy obsahují několik jednoduchých 2D a 3D úloh. Zajímavostí tohoto nástroje je fakt, že výsledek není zá- vislý pouze na výkonu hardwaru, ale i na verzích instalovaných balíčků. UnixBench obsahuje několik nástrojů, které jsou zaměřeny na konkrétní problémy:

Dhrystone Byl vyvinut Reinholdem Weickerem v roce 1984. Test je zaměřen na rych- lost operací s textem. V tomto testu nejsou obsaženy žádné operace s plovoucí řádovou čárkou.

Whetstone Nástroj pro testování výkonu operací s plovoucí řádovou čárkou. Nástroj obsahuje řadu úloh, které reprezentují typicky věděcké funkce jako sin, cos, sqrt, exp a log.

File Copy Tento jednoduchý test měří rychlost přenesení obsahu jednoho souboru do jiného s použitím různých bufferů.

Pipe Throughput Pajpa (PIPE) je nejjednodušší forma komunikace mezi unixovými procesy. Propustnost pajpy se měří přenášením 512 bajtů přes pajpu a zpět.

Pipe-based Context Switching Tento nástroj měří kromě rychlosti komunikace přes pajpu také rychlost změny kontextu mezi dvěma procesy. Nástroj vytvoří po- tomka, s kterým komunikuje přes pajpu. Tím dochází z pohledu procesoru ke změnám kontextu (context switchning).

21 Měření diskového výkonu

Process Creation Jak již název napovídá, nástroj měří rychlost vytváření procesů v unixových systémech. Postup vytvoření procesu s sebou nese další operace jako alokace paměti a další.

Shell Scripts Tento test sleduje rychlost pouštění shell skriptů.

Graphical Tests Sada 2D a 3D testů.

3.2.2. Významné charakteristiky

Z nabízených možností pro výkon paměti byly vybrány následující testy a metriky.

Tabulka 3.2.: Charakteristiky výkonu paměti

Test Metrika Jednotka Typ hpcc propustnost (součin) Mbits/sec delta hpcc propustnost náhodných přístupů Mbits/sec delta unixbench propustnost pajpy Kb/sec delta unixbench skóre - delta

3.3. Měření diskového výkonu

V této kapitole jsou blíže popsány nástroje, které jsou zaměřené pouze na testování výkonu diskového úložiště.

3.3.1. Testovací nástroje

IOZone

IOZone benchmark [26] se používá pro měření rychlosti operací čtení a zápis. IOZone produkuje přijatelnější výsledky v kratším čase než DFSIO benchmark, (který je častěji využívaný).

Fio

Fio [39] je nástroj pro testování I/O operací. Tento nástroj lze využít pro měření nebo stresování hardwaru. Podporuje devatenáct typů I/O nástrojů jako (sync, mmap, li- bio, posixio, guasi, solarisio). Fio podporuje většinu linuxových distribucí Ubuntu, Fre- eBSD, OS X, OpenSolaris.

22 Měření síťového výkonu

Bonnie++

Bonnie++ je kolekce testů, která je postavená na množství jednodušších nástrojů pro měření výkonu souborového systému. Samotný program testuje přístupy k velkému množství malých souborů. Tento test simuluje služby jako Squid nebo mailového ser- veru.

3.3.2. Významné charakteristiky

V tabulce jsou shrnuty jednotlivé charakteristiky diskového výkonu.

Tabulka 3.3.: Charakteristiky diskového výkonu

Test Metrika Jednotka Typ fio počet I/O operací - čtení IOPS delta fio počet I/O operací - zápis IOPS delta fio odezva - zápis ms delta fio odezva - čtení ms delta bonnie++ rychlost náhodného mazání Kb/s delta bonnie++ rychlost náhodného vytváření Kb/s delta bonnie++ rychlost náhodného přepisování Kb/s delta

3.4. Měření síťového výkonu

S rozšiřujícím se trendem softwarově definovaných sítí přibývá také počet řešení, které se snaží maximálně využít velikost datových paketů. Snahou je také, aby šíře datové linky měla co nejmenší nároky na výpočetní výkon. Měření výkonu sítě je tak jednou z hlavních oblastí cloud computingu současnosti. Spolu s flexibilitou s sebou přináší také režii, která se často projevuje sníženým výkonem a velkou nestabilitou řešení. Pro měření sítě se nejčastěji využívají standardní nástroje jako ping, iperf a netperf.

3.4.1. Testovací nástroje

Charakteristika jednotlivých testovacích nástrojů:

Ping

Program ping (anglicky Packet InterNet Groper) je jeden z nejjednodušších nástrojů pro měření sítě, který umožňuje prověřit funkčnost spojení mezi dvěma síťovými roz-

23 Doménově specifické hraními v počítačové síti, která používá protokoly TCP/IP. Test probíhá odesláním po- žadavku na protistranu a následným očekáváním odpovědi. Jakmile se odpověď vrátí, je spočítána délka zpoždění v milisekundách.

Iperf

Iperf je možné nazvat jednoduchým nástrojem, který slouží k testování rychlosti sítě. Měření probíhá tak, že iperf je spuštěn na jedné straně jako server, druhou stranu tvoří klient, který se k serveru připojuje. Velikou výhodou tohoto nástroje je, že existují verze pro systémy Windows i Linux.

Netperf

Netperf je nástroj pro měření různých aspektů výkonu sítě [47]. V současné době je za- měřený na přenos dat a měření výkonu požadavek/odpověď na TCP a UDP na IPv4 a IPv6. Tento test se liší od iperfu především v tom, že iperf se měří mezi dvěma instan- cemi v jedné síti u jednoho poskytovatele, naproti tomu netperf je měřen z internetu. Netperf navíc na rozdíl od iperfu je schopen měřit více metrik, lze se tak dozvědět mnohem více o jednotlivých charakteristikách výkonu sítě. Například počet CRR2 a RR3 operací za sekundu.

Socketperf

Socketperf je nástroj pro testování unixových socketů. Byl navržen pro testování výkonu (odezva a šířka) a pokrývá tak většinu socketových operací pro sítově náročně systémy. Socketperf testuje rychlost posílání paketů pod velkým vytížením sítě (miliony paketů za sekundu).

3.4.2. Významné charakteristiky

Pro síť jsou typické parametry jako doba odezvy a propustnost. Jednotlivé vybrané charakteristiky jsou přehledně uspořádány do tabulky 3.4 .

3.5. Doménově specifické

Doménově nebo aplikačně specifické jsou nástroje, které se specializují pouze nates- tování jedné konkrétní úlohy. Do této kategorie patří například nástroje pro testování databází, služeb a nejrůznějších aplikací.

2spojení, požadavek, odpověď angl. connection, request, response 3požadavek a odpověď angl. request, response 4OPS - operací za vteřinu

24 Doménově specifické

Tabulka 3.4.: Charakteristiky sítě

Test Metrika Jednotka Typ ping odezva ms delta iperf propustnost Mbits/sec delta netperf propustnost streamu TCP Mbits/sec delta netperf odezva TCP ms delta netperf odezva UDP ms delta netperf počet RR transakcí TCP ops4 delta netperf počet RR transakcí UDP ops delta

3.5.1. Testovací nástroje

Níže je uvedena charakteristika jednotlivých testovacích nástrojů:

Cassandra stress

Cassaandra Stress Tool, nástroj byl vyvinut společností DataStax pro testování výkonu databáze Cassandra[45]. Tento test je vhodný zejména pokud je potřeba:

∙ zjistit rychlost práce s databázovým schématem,

∙ zjistit jak databáze škáluje,

∙ optimalizovat model a nastavení,

∙ zjistit produkční kapacitu.

Yahoo Cloud Serving Benchmark

Yahoo Cloud Serving Benchmark zkráceně YCSB je nástrojem od společnosti Yahoo, psaný v jazyce Java a je specializovaný na testování databázových serverů. Nástroj ob- sahuje implementované scénáře pro většinu dnes používaných databází jako je Cassan- dra, MonoDB, Redis, Elasticsearch.

Hadoop terasort

Nástrojem pro testování výkonu Hadoopového clusteru s možností běhu od pár strojů až po tisícovky je Hadoop terasort. Tento nástroj se hodí pro testování velkých nasazení.

25 Orchestrátory testů

Tabulka 3.5.: Testy doménově specifické

test metrika jednotka typ metriky cloudsuite web serving odezva ms delta cloudsuite web search počet požadavků rps6 delta cloudsuite web search odezva ms delta cassandra stress počet operací ops delta cassandra stress doba odezvy ms delta

Cloudsuite

CloudSuite je sada nástrojů vyvinutých pro testování cloudových služeb. Sada obsahuje osm aplikací vybraných podle popularity a množství nasazení. Testy jsou postavené na reálných softwarových architekturách, které reprezentují reálné nasazení a jsou to tyto:

Web serving Scénář, složený ze tří instancí, které představují typ nejčastěji nasaze- ných webových aplikací, které mají podobu databázového a webového serveru a jedné instance jako klienta. Měří se sto konkurentních uživatelů na operace za sekundu (ops).

Data serving Hostování velkých dat.

Media streaming Streamování mediálního obsahu.

In memory analytics Běh analytických funkcí nad velkými daty, které jsou uchová- vány v paměti.

Webové vyhledávání Indexace a vyhledávání nad velkým počtem dat.

3.5.2. Významné charakteristiky

V této kategorii záleží především na konkrétním zaměření a na potřebách uživatele. Častou jednotkou u měření webových aplikací je RPS 5 . V tabulce 3.5 jsou shrnuty vybrané testy.

3.6. Orchestrátory testů

V této kapitole jsou blíže popsány nejpoužívanější orchestrátory běhu testů. Tyto ná- stroje jsou zodpovědné za konfiguraci, běh a parsování následných výsledků včetně

5počet požadavků za sekundu (requests per second)

26 Orchestrátory testů odeslání či vizualizace a interpretace výsledků. Některé nástroje umí výsledky srovná- vat nebo přepočítat výsledky na cenu za jednu úlohu apod.

3.6.1. PerfKit Benchmarker

PerfKit Benchmarker (PKB) je open source nástroj, který slouží pro měření a porovná- vání cloudových nabídek. Byl vyvinut společností Google s přispěním dobrovolníků. PerfKit Benchmarker je nástroj pro konzistentní a opakované měření výkonu cloudu. Podporuje Amazon Web Services, CloudStack, DigitalOcean, Google Cloud Platform, Kubernetes, Microsoft Azure, OpenStack a Rackspace. Kromě samotných cloudových platforem podporuje orchestrátory kontainerů Kubernetes a Mesos včetně lokálního/- fyzického serveru. Testy většinou dodávají a udržují samotné firmy nebo dobrovolníci. Architektura nástroje je postavena na modulárním systému, který je jednoduše rozší- řitelný o nové testy či poskytovatele a je názorně prezentována na obrázku ??.

Obrázek 3.1.: Architektura perfKit Benchmarku převzato z [22]

3.6.2. Cloud Rapid Experimentation and Analysis Toolkit

Cloud Rapid Experimentation and Analysis Toolkit (CBTOOL) je nástrojem pro testo- vání IaaS infrastruktury od společnosti IBM a je napsaný v jazyce Python. Nástroj stejně jako PerfKit podporuje AWS, DigitalOcean, OpenStack, CloudStack a další. Nástroj je dimenzován pro uživatele a poskytovatele cloudových řešení. Architekutra CBTOOL, která je znázorněna na obrázku ?? se velmi podobá ostatním řešením.

27 Orchestrátory testů

Obrázek 3.2.: Architektura CBTOOL převzato z [38]

3.6.3. Faban

Faban je nástroj pro vytváření a běh vlastních testů. Poskytuje nástroje pro běhy testů na více serverech. Nástroj obsahuje dvě základní komponenty. Komponenta Harness je nástrojem pro automatizovaný běh uživatelských testů a Faban Driver poskytuje API pro implementaci těchto testů. Faban se tak stává součástí jiných nástrojů, kdy např. CloudSuite je implementován pomocí Fabanu.

28 4. Architektura testovacího řešení

Vzhledem k množství cloudových platforem, poskytovatelů, ale i nabízených služeb včetně jejich možných kombinací, je velmi náročné navrhnout a implementovat univer- zální řešení, které by obsáhlo všechny možné testovací scénáře a cloudové platformy. Cloudové platformy jsou masivně distribuované, většinou ve více geograficky od- dělených datacentrech, na více typech serverů, síťových a diskových prvků, někdy i běžících na rozdílných verzích operačního softwaru. Testovací řešení je nutně empi- rické, opírá se o opakované a neustálé testování a měření významných charakteristik vybraných platforem. Pro dosažení statisticky významných výsledků je třeba běh apli- kace po dlouhou dobu a s velkým počtem opakování. Využitím jednoho konkrétního nástroje tak nejde docílit plného pokrytí všech platforem a služeb. Testovací řešení automatizuje měření výkonosti cloudových služeb pomocí řízených testů. Testy jsou prováděny na virtuální serverech spuštěných na vybraných platfor- mách. Experimenty mohou být provedeny interaktivně, s uživatelskou interakcí přes uživatelské rozhraní nebo jako sled příkazů v textovém formátu. Nástroj pro automatizované testování výkonu pomáhá řešit typické úlohy jako jsou:

∙ automatizované měření, profilování zaměřené na výkon jednotlivých zdrojů,

∙ detekování problémů s výkonem,

∙ porovnávání více platforem, více poskytovatelů i typů instalace,

∙ sběr dat a jejich interpretace včetně vizualizace.

4.1. Modul sběru dat

Modul sběru dat je nejdůležitější a nejkomplexnější komponentou celého řešení. Obecně lze proces běhu testů a sběru nashromážděných dat shrnout do čtyř kroků, shrnutých v následujícím seznamu, ale i na obrázku:

1. vytvoření a příprava prostředí,

2. běh testů,

29 Modul sběru dat

Obrázek 4.1.: Průběh testování výkonu

3. odeslání výsledků testů,

4. uvolnění zdrojů.

Jednotlivé kroky je možné pro lepší představivost graficky znázornit na obrázku 4.1. Základem pro běh testů je scénář, který přesně definuje jaké testy se provedou a jed- notlivé kroky daných testů, které je nutné provést. Scénáře spolu s konfigurací určenou pro dané poskytovatele Cloudových služeb je možné definovat prostřednictvím mo- delu pro běhové prostředí, který podle scénáře obsahuje určený počet strojů s před- nastaveným operačním systémem a nainstalovaným software, který je nutný pro běh testů. Dále následuje běh testů na připraveném prostředí. Po ukončení běhu testů jsou výsledky publikovány do analytického modulu pro další zpracování. Posledním kro- kem je uvolnění použitých zdrojů pro testy. Na obrázku 4.2 je možné vidět roli orchestrátora testů, který se stará o průběh jed- notlivých fází testovacího procesu. Testovací nástroj má přiřazeny potřebné zdroje jen po nezbytně dlouhou dobu. Hlavním důvodem je úspora finančních prostředků, které je nutno vynaložit na samotné testování. Aby bylo možné vyvodit staticky významné závěry, je nutné mít dostatečné množství testovaných vzorků. Výše zmíněné nástroje, i přes velké množství testů a platforem, stále vyžadují vstupy od lidských operátorů. Proto je v systému použitý nástroj Jenkins, který automatizuje běh a návaznost jed- notlivých kroků. Tento přístup ve výsledku snižuje potřebu manuálních kroků, a tím i snižuje cenu jednoho měření.

30 Modul sběru dat

Obrázek 4.2.: Obecná architektura testovacího řešení

4.1.1. Jenkins

Navrhovaná architektura je postavena na platformě Jenkins CI 1. Jenkins je dlouho vy- víjeným nástrojem, který je velmi oblíben především kvůli open-source licenci, ale také díky řadě modulů, které usnadňují vytváření samotných scénářů (jobů). Jenkins usnad- ňuje automatizaci procesů, které je nutno provádět manuálně. S využitím znalostí, které jsem získal během praxe v nejrůznějších společnostech, navrhuji architekturu, která je znázorněna na obrázku 4.4. Navržená architektura modulární a podporuje po- užití jakéhokoliv testovacího nástroje. A to hlavně díky obecnosti samotných scénářů. Výhodou je pak znovupoužitelnost scénářů a možnost spouštění úloh paralelně. Lze tak běžet stejný scénář u více poskytovatelů zároveň. Nástroj Jenkins byl vybrán na základě zkušeností z praxe a několika vědeckých zdrojích ze současnosti [41], [42]. Mezi hlavní výhody nástroje se podle Jenkins wiki stránky [43] řadí:

∙ Jednoduchá instalace, která nepotřebuje další služby, například databáze.

∙ Jednoduchá konfigurace prostřednictvím Jenkins Job Builderu nebo grafického rozhraní (GUI).

∙ Mnoho veřejně dostupných modulů.

∙ Jednoduchá rozšiřitelnost prostřednictvím nových modulů.

∙ Distribuovaný běh úloh. Jenkins podporuje běh úloh na více strojích současně.

1kontinuální integrace

31 Modul sběru dat

Obrázek 4.3.: Ukázka Jenkins Workflow GUI

4.1.2. Job builder

Job builder je nástroj pro správu velkého množství scénářů, vyvinutý pod projektem OpenStack. Jenkins job builder umožňuje snadnou deklaraci scénářů a projektů ve formátu YAML2 (angl. Ain’t Markup Language). Mezi hlavní výhody tohoto formátu patří: čitelnost, struktura, hierarchie a neomezené vnořování. Job builder umožňuje navrhovat a upravovat scénáře v textovém formátu, který pod- poruje systémy pro správu verzí, jakým je např. GIT. Jenkins Job Builder poskytuje jed- noduchý šablonovací systém, který nám zjednodušuje vytváření podobných scénářů a podporuje deklarativní popis pro většinu typů scénářů, tzn. multijob, triggered jobs, pipeline a další.

Ukázka konfigurace 4.1: Scénář - příprava prostředí - job-template: name: prepare-environment-{cloud} concurrent: false builders:

2je formát pro serializaci strukturovaných dat

32 Modul sběru dat

Obrázek 4.4.: Architektura nového testovacího řešení

- shell: !include-raw-escape scripts/prepare-environment.sh parameters: - string: name: ENGINE - string: name: CLOUD - string: name: TEST

Ukázka konfigurace 4.2: Skupina scénářů pro běh testů - job-group: name: {engine}-tests engine: perfkit test: ping,netperf,iperf,coremark,fio jobs: - prepare-environment-{cloud} - run-tests-{cloud} - publish-results-{cloud} - cleanup-environment-{cloud}

Proces sběru dat, který je zobrazen na obrázku 4.4 , je spouštěn pomocí nástroje Jen- kins. Běh testů je konfigurovatelný prostřednictvím volitelných parametrů, které jsou nadefinovány v jednotlivých scénářích, které jsou následně pomocí nástroje Jenkins job builderu vygenerovány a nahrány do Jenkinse. Díky vhodné parametrizaci scénářů lze

33 Modul sběru dat docílit podpory i pro více testovacích nástrojů 4.1. Vhodnou kombinací testovacích nástrojů je možné dosáhnout pokrytí více platforem a poskytovatelů než umožňují jednotlivé nástroje a platformy. V ukázce konfigurace 4.3 je projekt, který definuje sadu scénářů s předem danými parametry (cloud, engine, testy).

Ukázka konfigurace 4.3: Projekt - project: name: openstack-cloud engine: perfkit cloud: OpenStack test: ping,netperf,iperf,coremark,fio jobs: - {engine}-tests

- project: name: amazon-web-services engine: perfkit cloud: AWS test: ping,netperf,iperf,coremark,fio jobs: - {engine}-tests

4.1.3. Postup testování

Modul sběru dat využívá ve výchozí konfiguraci PerfKit Benchmarker, který obsahuje velké množství veřejně dostupných testů. Testy jsou spouštěny ve stejné konfiguraci napříč spektrem všech poskytovatelů cloudových služeb. Tento přístup poskytuje způ- sob jak testovat rozdílné platformy a navíc přidává možnost transparentně srovnávat jednotlivé platformy prostřednictvím dobře definovaných metrik. Konfigurace jednot- livých testů pak spravují ve velké většině sami tvůrci testovacích nástrojů, případně dobrovolní přispěvatelé.

4.1.4. Konfigurace testů

Pro lepší představu a znázornění následují ukázkové konfigurace testovacího nástroje pro sběr dat z OpenStack cloudové plaformy, ale také konfigurace pro více poskytova- telů.

Ukázka konfigurace 4.4: Kofigurace CloudSuite cloudsuite_web_serving:

34 Modul sběru dat

Obrázek 4.5.: Postup běhu testů

description: > Run Cloudsuite web serving benchmark. vm_groups: backend: vm_spec: *default_single_core vm_count: 1 frontend: vm_spec: *default_single_core vm_count: 1 client: vm_spec: *default_single_core vm_count: 1

Ukázka konfigurace 4.5: Konfigurace více poskytovatelů my_static_vms: - &vm1 user_name: perfkit ssh_private_key: /absolute/path/to/key ip_address: 1.1.1.1 disk_specs: - mount_point: /scratch - &vm2 user_name: perfkit

35 Modul analýzy dat

ssh_private_key: /absolute/path/to/key ip_address: 2.2.2.2 disk_specs: - device_path: /dev/sdb benchmarks: - fio: {vm_groups: {default: {static_vms: [*vm1]}}, flags: {against_device: False}} - fio: {vm_groups: {default: {static_vms: [*vm2]}}, flags: {against_device: True}}

4.2. Modul analýzy dat

Analytický modul obsahuje několik nástrojů pro práci s daty, které produkují jednotlivé testovací nástroje. Modul poskytuje základní ETL3 funkčnost pro práci s daty. Kdy v první fázi jsou data transformována do jednotného formátu. V dalším kroku jsou data podrobena statistickým metodám pro získání základních charakteristik (medián, 10, 90 percentily). V posledním kroku jsou zpracovaná data uložena v databázi, kde jsou dostupná pro následující vizualizaci a interpretaci. Pro uložení metrických údajů je využívána databáze InfluxDB. InfluxDB je databáze pro časové řady, která podporuje ukládání událostí a metadat ve formátu Metrics 2.0 [http://metrics20.org]. Tento formát byl vybrán, protože podporuje unifikovaný zápis nejrůznějších metrik včetně metadat, které jsou často nezbytné pro úplný popis dané charakteristiky. Dalším formátem, který se jevil jako vhodný je SenML od IEEE, ten však ještě nemá hotovou implementaci. Následující výpis je ukázkový formát metadat jedné metriky ve formátu Metrics 2.0.

Ukázka konfigurace 4.6: Ukázka formátu Metrics 2.0 { host: dfs1 what: diskspace mountpoint: srv/node/dfs10 unit: B type: used metric_type: gauge } meta: { agent: diamond, processed_by: statsd2

3extrakce, transformace, načtení (load)

36 Modul analýzy dat

}

4.2.1. Normalizace měřených dat

Pro normalizaci a práci s daty byl použit jazyk Python a s ním potřebné balíčky pro práci se statistickými funkcemi NumPy, SciPy a matplotlib. Data z jednotlivých testo- vacích nástrojů se upravují do jednotného formátu. Použitý nástroj PerfKit produkuje data ve formátu Newline Delimited JSON zkráceně NDJSON[46], který je vhodný práci s velkým objemem záznamů, protože podporuje přidávání nových záznamů bez na- čtení těch původních. To má za následek rapidní zrychlení zpracování aktuálních dat s minimálními nároky na paměť. V následujícím kroku je provedena základní statistická analýza naměřených hodnot. Pro analytické funkce je použitý python modul stats, který poskytuje implementaci většiny základních statistických funkcí, například test distribuce pomocí Kolmogorova- Smirnova testu, test mediánu a další.

Ukázka konfigurace 4.7: Ukázka implementace testu normality import scipy.stats as stats data = [openstack, gcp, aws] def test_data(data): """test normal distribution and raise exception :param:data:array of arrays """ for datum in data:

normality_test = stats.normaltest(datum)

if(normality_test[1] < 0.05): Exception("Not␣normal␣distribution␣{}".format(datum))

ks = stats.kstest(x,’norm’)

if(normality_test[1] < 0.05): Exception("KS␣test␣fail␣{}".format(datum)) test_data(data)

37 Modul vizualizace dat

4.3. Modul vizualizace dat

Modul vizualizace je posledním modulem v rámci životního cyklu testovaných dat. Modul obsahuje jednoduché funkce pro vykreslování tabulek a krabicových grafů. Pro pokročilé vizualizace je využíván nástroj Grafana, který podporuje mnoho datových zdrojů, včetně vybrané databáze InfluxDB a mnoha metod zobrazení. Grafana bohužel v současné verzi nepodporuje krabicové grafy, proto je součástí modulu jednoduchá implementace v jazyce Python, která je využívána pro jejich rendrování.

4.3.1. Tabulkové zobrazení

Základní způsob zobrazení dat je pomocí tabulky. Tabulky můžeme zobrazit přímo v CLI4 nebo na webovém rozhraní. Z následujícího příkladu tabulky je zřejmé, že test iperf běžel celkem čtyřikrát na platformě GCP.

Ukázka konfigurace 4.8: Iperf na Google Cloud +------+------+------+------+------+ | cloud | test | metric | value | unit | +------+------+------+------+------+ | GCP | iperf | Throughput | 867.0 | Mbits/sec | | GCP | iperf | Throughput | 1000.0 | Mbits/sec | | GCP | iperf | Throughput | 950.0 | Mbits/sec | | GCP | iperf | Throughput | 1000.0 | Mbits/sec | | GCP | iperf | End to End Runtime | 543.026502848 | seconds | +------+------+------+------+------+

4.3.2. Zobrazení v grafu

Ukázka kódu 4.9: Ukázka vykreslení krabicového grafu import matplotlib.pyplot as plt data = [openstack, gcp, aws] def boxplot(data): """plot box graph """

fig = plt.figure() ax = fig.add_subplot(111)

4Command Line Interface

38 Modul vizualizace dat

plt.ylabel(’Odezva’) plt.xlabel(’Poskytovatelé’) ax.boxplot(data, labels=[’OpenStack’,’GCP’,’AWS’]) plt.show() test_normal_distribution(data) boxplot(data)

Pro další vizualizaci naměřených dat je možné použít mnoho nástrojů, které podpo- rují InfluxDB. Lze využít nástroje Kibanu a Grafanu, které jsou vyvíjeny jen zatímto účelem. Pro kreslení krabicových grafů byla využita knihovna matplotlib.

Obrázek 4.6.: Ukázka krabicového grafu pro odezvy

Obrázek 4.7.: Ukázka vizualizace v nástroji Kibana

39 5. Test vybraných cloudových služeb

Obsahem této kapitoly jsou námi zpracované výsledky testovacích scénářů pro vybrané typy virtuálních serverů. V první řadě byl proveden výběr testovaných serverů, které jsou v obdobných konfiguracích poskytované různými poskytovateli cloudových slu- žeb. Všechny naměřené testovací výsledky jsme sjednotili, spočítali základní statistické parametry výběru a graficky jsme je znázornili v přehledných grafech.

5.1. Výběr testovaných instancí

Existuje široká škála velikostí a parametrů nabízených virtuálních serverů, které kom- plikují výběr obdobných konfigurací, které by bylo vhodné srovnávat. Za tímto účelem vzniklo několik publikací a přístupů. Podle [1] je možné sestavit vektor hodnot, které popisují danou konfiguraci a implementují funkci s(i, j), která pro dané servery vypo- čítá vektor shodnosti. Výsledek je znázorněn v korelační matici na obr. 5.1.

Obrázek 5.1.: Korelační matice typů virtualních strojů od AWS a GCP, převzato z [1]

Vlastnosti jednotlivých typů virtuálních serverů se projevily až v průběhu experi- mentů, kdybylo možné pozorovat závislost počtu obsloužených dotazů za sekundu na velikosti paměti nebo rychlosti datového úložiště. Pro potřeby testů byly zvoleny podobné servery podle velikosti vektoru shodnosti s(i, j). Velikost vektoru přímo kore-

40 Testovací prostředí luje s koeficienty jednotlivých instancí. S rostoucí shodností se blíží koeficient hodnotě jedna. Pro testování byly vybrány virtuální servery popsané v tabulce 5.1. Jedná se o větší velikosti instancí, které mají největší hodnotu vektoru shodnosti.

Tabulka 5.1.: Výběr testovacích instancí od čtyř hlavních poskytovatelů

Poskytovatel Typ vCPU RAM (GB) Openstack m1.xlarge 8 16 GCP n1-standard-4 4 15 AWS m4.xlarge 4 16 Azure A-4 8 14

5.2. Testovací prostředí

Pro testovací prostředí byl využitt virtuální stroj v prostředí VirtualBox s operačním systémem Ubuntu 14.04. Instalace a konfigurace aplikace proběhla pomocí konfigurač- ního managementu SaltStack. Nainstaloval se Jenkins master server a příslušné slave servery, na kterých probíhala orchestrace testů.

Test a metrika Jednotka Průměr [GCP] Průměr [AWS] Průměr [OpenStack] Průměr [Azure] ping - Průměrná odezva ms 0.41 0.44 0.47 0.53 iperf - Propustnost Mbits/sec 6750.6 6202.64 5668.73 4655.07 netperf - CRR transkace ops 2285.55 2099.5 1946.31 1556.49 netperf - Propustnost Mbits/sec 6966.34 6437.93 5874.48 4809.22 cloudsuite-web-serving - Doba odezvy ms 113.41 121.7 130.42 147.14 cloudsuite-in-memory-analytics - Doba běhu s 32.79 35.28 37.45 42.72 cloudsuite-web-search - Počet operací operací/s 23.09 21.23 19.63 15.8 cassandra-stress - Počet operací operací/s 5422.5 5009.79 4558.45 3764.03 cassandra-stress - Odezva ms 27.44 29.46 31.33 35.59 coremark - Coremark skóre - 43922.35 40397.94 36698.11 30705.02 scimark2 - Skóre Mflops 1251.66 1152.37 1053.01 871.06 hpcc - Propustnost streamu Mbits/sec 11.77 10.98 9.94 8.09 hpcc - Propustnost náhodných přístupů Mbits/sec 0.03 0.03 0.03 0.02 unixbench - Propustnost pajpy Mbits/sec 4826547.44 4478302.66 4088074.45 3336586.21 unixbench - Skóre - 3364.94 3111.18 2858.41 2300.71 fio - Počet I/O operací - čtení IOPS 111.16 103.03 94.01 76.09 fio - Počet I/O operací - zápis IOPS 1481.43 1373.52 1249.42 1001.98 fio - Odezva - zápis ms 648.39 696.95 743.62 839.45 fio - Odezva - čtení ms 8888.12 9543.13 10251.84 11584.95 bonnie++ - Rychlost náhodného mazání Kb/sec 121897.74 111633.99 103315.63 84342.62 bonnie++ - Rychlost vytváření souborů Kb/sec 2811.1 2587.73 2369.85 1969.39 bonnie++ - Rychlost přepisování souborů Kb/sec 59144.9 54423.94 49351.44 41375.03

Tabulka 5.2.: Zprůměrované výsledky pro sto měření

41 Zpracování naměřených dat

5.3. Zpracování naměřených dat

Zpracování naměřených dat realizoval analytický modul testovacího řešení automa- ticky v krocích popsaných v kapitole 4. Data z testů byla načtena a otestována základ- ními statistickými metodami. Z výsledků se vygenerovaly tabulky a krabicové grafy, které zobrazují jednotlivé kvartily a mediány naměřených hodnot. Všechna data a vý- sledky testovacích měření jsou dostupná v přílohách.

Coremark skóre (více je lépe) Skóre (více je lépe) 50000 1300

1200 45000

1100 40000

1000 35000 900 Skóre [Mflops] Coremark skóre 30000 800

25000 700

20000 600 AWS Azure GCP OpenStack AWS Azure GCP OpenStack Poskytovatelé Poskytovatelé

Obrázek 5.2.: Coremark skóre Obrázek 5.3.: Scimark 2.0 skóre

5.3.1. Výpočetní výkon

Test výpočetního výkonu ukázal, že nejlépe si vedla platforma GCP, která je postavená na KVM virtualizaci. Na grafech 5.2 a 5.3 lze vidět srovnání výkonu jednotlivých plat- forem. Z grafů je patrné, že nejhorších výsledků dosáhla platforma Azure postavená na Hyper-V virtualizaci.

5.3.2. Síťový výkon

V oblasti sítí je možné sledovat mnohem více parametrů než v případě výpočetního výkonu. A proto byly vybrány jen ty zásadní. Z výsledků iperfu 5.5 a netperfu 5.4 je patrné, že propustnost lokální sítě je skoro čtyřikrát větší než propustnost do inter- netu. Zatímco výkon mezi dvěma instancemi v jedné zóně u jednoho poskytovatele dosahuje řádově 1Gb/s, propustnost do internetu nepřekročila u žádného poskytova- tele 300Mb/s. Následující grafy zobrazují výsledky měření propustnosti sítě pomocí dvou různých nástrojů iperf a netperf.

42 Zpracování naměřených dat

Propustnost (více je lépe) Propustnost (více je lépe) 7500 7500

7000 7000

6500 6500

6000 6000

5500 5500

5000 5000 Propustnost [Mbits/sec] Propustnost [Mbits/sec] 4500 4500

4000 4000

3500 3500 AWS Azure GCP OpenStack AWS Azure GCP OpenStack Poskytovatelé Poskytovatelé

Obrázek 5.4.: Propustnost TCP (netperf) Obrázek 5.5.: Propustnost TCP (iperf)

Propustnost je doplněna o další dva grafy. První graf 5.6 reprezentuje odezvu mezi dvěma instancemi v rámci jedné sítě a obrázek 5.7 znázorňuje počet provedených CRR operací za sekundu. Naměřené odezvy se liší jen minimálně. U počtu CRR operací jsou rozdíly znatelnější.

Průměrná odezva (méně je lépe) Počet CRR transkací (více je lépe) 0.60 2400

2200 0.55

2000 0.50

1800

0.45 1600 CRR transkace [ops] Průměrná odezva [ms]

0.40 1400

0.35 1200 AWS Azure GCP OpenStack AWS Azure GCP OpenStack Poskytovatelé Poskytovatelé

Obrázek 5.6.: Doba odezvy (ping) Obrázek 5.7.: Stream rate TCP (netperf)

43 Zpracování naměřených dat

5.3.3. Diskový výkon

Z výsledků testů charakteristik disků je patrné, že AWS poskytuje lehce výkonnější diskové úložiště než ostatní poskytovatelé. Hlavně v počtu operací za sekundu 5.8, 5.9 (IOPS) je o pár operací rychlejší než GCP. Nutno říci, že v odezvě 5.10, 5.11 je ovšem GCP rychlejší.

Počet I/O operací - čtení (více je lépe) Počet I/O operací - zápis (více je lépe) 140 2000

130 1800 120 1600 110

100 1400

90 1200

80 1000 70 Počet I/O operací - čtení [IOPS] Počet I/O operací - zápis [IOPS] 800 60

50 600 AWS Azure GCP OpenStack AWS Azure GCP OpenStack Poskytovatelé Poskytovatelé

Obrázek 5.8.: Rychlost náhodného čtení Obrázek 5.9.: Rychlost náhodného zápisu

Odezva - zápis (méně je lépe) 950 Odezva - čtení (méně je lépe) 13000 900 12500

12000 850

11500 800 11000 750 10500

10000 Odezva - zápis [usec]

Odezva - čtení [usec] 700

9500 650 9000

8500 600 AWS Azure GCP OpenStack AWS Azure GCP OpenStack Poskytovatelé Poskytovatelé

Obrázek 5.10.: Odezva náhodného čtení Obrázek 5.11.: Odezva náhodného zápisu

5.3.4. Výkon paměti

Podle [1] lze u více typů instancí sledovat podobné výsledky. A to i přes to, že posky- tovatelé nabízejí typy optimalizované pro výkon paměti (AWS, r3.*) nebo ”highmem”

44 Srovnání pro vybrané scénáře

Rychlost vytváření souborů (více je lépe) Rychlost náhodného mazání (více je lépe) 3500 150000

140000

3000 130000

120000 2500 110000

100000 2000 90000

1500 80000 Rychlost vytváření souborů [Kb/sec] Rychlost náhodného mazání [Kb/sec] 70000

1000 60000 AWS Azure GCP OpenStack AWS Azure GCP OpenStack Poskytovatelé Poskytovatelé

Obrázek 5.12.: Rychlost náhodného vytvá- Obrázek 5.13.: Rychlost náhodného ma- ření souborů zání souborů (Kb/s)

(GCP). Výsledky ukázaly, že výkon paměti je ohraničen výkonem procesorů. Na vý- sledných grafech 5.14, 5.15, 5.16, 5.17 tak lze vidět stejné pořadí jako u výkonu proce- sorů, kterými je výkon paměti limitován. Pozorný čtenář si může povšimnout zmenše- ného rozptylu hodnot, tedy kromě platformy Azure.

Propustnost náhodných přístupů (více je lépe) Propusnost (více je lépe) 0.036 13

0.034 12 0.032 11 0.030

0.028 10

0.026 9

0.024 8 0.022 Propustnost streamu [Mbits/sec] 7 0.020 Propustnost náhodných přístupů [Mbits/sec]

0.018 6 AWS Azure GCP OpenStack AWS Azure GCP OpenStack Poskytovatelé Poskytovatelé

Obrázek 5.14.: Propustnost paměti Obrázek 5.15.: Propustnost při součinu

5.4. Srovnání pro vybrané scénáře

S dostatečným počtem měření je možné začít pracovat se získanými daty na teore- tické úrovni a můžeme získat praktické výsledky. Například podle modelů předpovědí

45 Srovnání pro vybrané scénáře

Propusnost pajpy (více je lépe) Skóre (více je lépe) 5500000 4000

5000000 3500

4500000 3000

4000000 Skóre 2500 3500000

Propustnost pajpy [Mbits/sec] 2000 3000000

2500000 1500 AWS Azure GCP OpenStack AWS Azure GCP OpenStack Poskytovatelé Poskytovatelé

Obrázek 5.16.: Propustnost pajpy (Kb/s) Obrázek 5.17.: Celkové skóre

Počet operací (více je lépe) Doba běhu (méně je lépe) 26 48

46 24 44 22 42

20 40

18 38 Doba běhu [s] 36

Počet operací16 [operací/s] 34 14 32

12 30 AWS Azure GCP OpenStack AWS Azure GCP OpenStack Poskytovatelé Poskytovatelé

Obrázek 5.18.: Rychlost vyhledávání Obrázek 5.19.: In-memory analytika

požadavků, můžeme vidět optimalizaci škálování infrastruktury a dlouhodobě tak je možné šetřit náklady na provoz.

5.4.1. Srovnání pro aplikační servery

Jednou z nejdůležitějších metrik pro aplikační servery je počet zpracovaných uživatel- ských požadavků za sekundu. Z výsledků běhu testů můžeme pak snadno vypočítat cenu na jeden požadavek. Lze pak optimalizovat potřebnou velikost virtuálního ser- veru a je možné ušetřit nemalé peníze. Pro výpočet srovnávací tabulky byly použity průměrné hodnoty výsledků z testu webového vyhledávání a pro počet dní v měsíci byl použit průměrný počet dní 30,436875 dnů. Cena je počítána v dolarech.

46 Srovnání pro vybrané scénáře

Ukázka kódu 5.1: Funkce pro výpočet ceny za jeden požadavek def get_price_per_request(price_per_month, requests_per_second): """Returns price per request """

requests_per_month = requests_per_second * 60 * 60 * 24 * 30.4368

return price_per_month / requests_per_month

Tabulka 5.3.: Tabulka cen požadavků

Poskytovatel Cena / měsíc Požadavků / sekundu Cena požadavku $ GCE 105 $ 23 1.735 996 039 373 644 × 10−6 OpenStack 150 $ 20 2.851 993 493 256 700 5 × 10−6 AWS 190 $ 21 3.440 500 087 103 322 × 10−6 Azure 280 $ 15 7.098 294 916 550 011 × 10−6

Průměrná doba odezvy (méně je lépe) 170

160

150

140

130 Doba odezvy [ms] 120

110

100 AWS Azure GCP OpenStack Poskytovatelé

Obrázek 5.20.: Odezva webového serveru

5.4.2. Srovnání pro databázové servery

Z nabízených možností databází byla vybrána databáze Cassandra. Z výsledků na 5.22 můžeme vidět, že počet operací za sekundu se pohybuje od třech do šesti tisíc za sekundu.

47 Srovnání pro vybrané scénáře

Odezva (méně je lépe) Počet operací (více je lépe) 40 6000

38 5500

36 5000

34 4500

32 4000 Odezva [ms]

30 Počet operací3500 [operací/s]

28 3000

26 2500 AWS Azure GCP OpenStack AWS Azure GCP OpenStack Poskytovatelé Poskytovatelé

Obrázek 5.21.: Cassandra - odezva Obrázek 5.22.: Cassandra - počet operací

Pozorný čtenář si jistě všimne velkého rozptylu hodnot u platformy Azure. Na obrázku 5.21 je pak možné porovnat průměrnou latenci, která je u všech platforem pod čtyřicet milisekund.

48 6. Závěr

Má práce představila základní parametry cloudových služeb a jejich kvantitativní cha- rakteristiky. V práci jsme srovnali několik základních typů virtuálních strojů od hlav- ních poskytovatelů veřejného cloudu. V testech výkonů se dle mého názoru ukázalo, že v poměru cena/výkon jsou na tom testované platformy podobně s vyjímkou platformy Azure od společnosti Microsoft, kde byl výkon srovnatelný, ale kvůli ceně byl celkový užitek nižší. Za pomyslného vítěze lze považovat platformu GCP, která se umístila, kromě výkonu disků, ve většině testů na prvním místě. V praktické části jsem představil návrh a implementoval platformu pro běh auto- matizovaných testů výkonu postavenou na platformě Jenkins. Díky vhodně zvoleným komponentám, jako je Job Builder, lze snadno implementovat a znovu použít jednot- livé části testovacích scénářů. Jenkins podporuje zápis scénářů v mnoha jazycích, což zvyšuje bus faktor1 a použitelnost celého řešení. Výhodou je, že v platformě je možné kombinovat více testovacích nástrojů. Díky tomu lze zvednout počet testovaných met- rik, ale i platforem a poskytovatelů. Platforma využívá volně šiřitelný software, který je ve většině případů špičkové úrovně. V rámci praktické části jsem implementoval ně- kolik funkcí pro práci s výslednými daty, které jsem volně poskytl prostřednictvím veřejné dostupného gitového adresáře. Výstupem testování jsou strukturovaná data, které jsou dále použita pro systema- tický popis a výběr nejvhodnější platformy nebo poskytovatele. Díky těmto přístupům jsme schopni automatizovat jinak manuální úlohy a opakovaně testovat a měřit důle- žité metriky na základě kterých lze provést kvalifikovaný výběr nejlepšího řešení. Z práce vyplývá, že testovat a měřit výkon cloudového prostředí je netriviální úloha s mnoha komplexními kroky. Díky originálnímu spojení několika klíčových komponent jsem docílil vysoké míry univerzálnosti, škálovatelnosti a rozšiřitelnosti, která se mi jeví v mnohém pružnější než zmíněné nástroje. Věřím, že má diplomová práce bude pro okruh uživatelů cloudu přínosem a její vý- sledky budou dále rozvíjeny.

1označuje počet vývojářů, kteří jsou schopni projekt spravovat a dále rozvíjet

49 Možnosti dalšího výzkumu

6.1. Možnosti dalšího výzkumu

Tak rozsáhlé téma jako je kvantifikace a evaluace cloudových řešení rozhodně není možné podrobně popsat v rámci jedné diplomové práce. Na tuto práci proto mohou navazovat kolegové z fakulty či jiných vysokých škol. V závěru si dovoluji pro ně na- vrhnout dvě zajímavá témata, na které již v této práci nezbyl prostor, a která si rozhodně zaslouží podrobnější analýzu.

6.1.1. Test více typů instancí

Tuto diplomovou práci jsem zaměřil především na srovnání nabízených možností jed- notlivých poskytovatelů. Zajímavé by bylo jistě i srovnání více typů instancí od stejného poskytovatele. Je možné, že bychom došli ke zjištění, že v některých případech dosáh- nou menší a levnější typy stejného či lepšího výsledku než typy větší a dražší.

6.1.2. Srovnávací algoritmy

V dnešní době „cloudů“ jsou investovány nemalé peníze do migrace zastaralých in- frastruktur a do virtuálního prostředí. Jen zřídka však dojde ke kvalitní analýze a vý- běru daného řešení. Proto zde navrhuji analýzu a implementaci algoritmu pro porov- nání konkurenčních platforem, především pak porovnání shodnosti více typů virtuál- ních strojů a jejich výkonnostních parametrů.

6.1.3. Podpora dalších nástrojů

Prostor vidím také v implementaci dalších nástrojů, statistických testů a vizualizačních metod, které by přispěly k většímu pokrytí platforem, poskytovatelů a dalších metrik.

50 Literatura

[1] Nane Kratzke1, Peter-Christian Quint About Automatic Benchmarking of IaaS Cloud Service Providers for a World of Container Clusters 2015 [online]. [cit. 2016-03-28]. Do- stupný z WWW: http://paper.uscip.us/jccr/JCCR.2015.1002.pdf

[2] Mallikarjun B Chadalpaka, System and Method for Storage Virtualization Computer and Network Technology (ICCNT), U. S. pat. 6, 845, 403B2, 01 18, 2005.

[3] S. Newman, Building Microservices, Designing Fine-Grained Systems O’Reilly, 2015.

[4] N. Kratzke. Lightweight virtualization cluster-how to overcome cloud vendor lock-in (JCC), 2(12), září 2014.

[5] Dynatrace. Virtualization’s Impact on Performance Management [online]. [cit. 2016- 03-28]. Dostupný z WWW: http://www.dynatrace.com/en/javabook/ why-virtualization-has-impact-on-performance-management. html

[6] N. Kratzke. A lightweight virtualization cluster reference architecture derived from open- source paas platforms. Open Journal of Mobile Computing and Cloud Computing (MCCC), 1(2):17–30, 2014.

[7] Siegel, J., Perdue, J., Cloud Services Measures for Global Use: The Service Measurement Index (SMI) Service Research Innovation Institute (SRII) Global Conference, IEEE, strany 24-27, 2012.

[8] Sahoo, J. ; Mohapatra, S. ; Lath, R., Virtualization: A Survey on Concepts, Taxonomy and Associated Security Issues Computer and Network Technology (ICCNT) Second International Conference, strany 222-226, 23-25 2010.

[9] B. Hindman, A. Konwinski, M. Zaharia, A. Ghodsi, A. D. Joseph, R. Katz, S. Shen- ker, and I. Stoica. Mesos: A platform for ine-grained resource sharing in the data center. In Proceedings of the 8th USENIX Confer- ence on Networked Systems Design and Imple- mentation NSDI’11, pages 295–308, Berkeley, CA, USA, 2011. USENIX Association.

51 Literatura

[10] NIST, Cloud Computing Service Metrics Description NIST Cloud Computing Refe- rence Architecture and Taxonomy Working Group NIST Cloud Computing Pro- gram Information Technology Laboratory, 2015.

[11] SMĚTÁK, Roman. Microsoft Azure výhody a nevýhody služby [online]. Zlín, 2014 [cit. 2016-08-28]. Bakalářská práce. Univerzita Tomáše Bati ve Zlíně, Fakulta apli- kované informatiky. Vedoucí práce Ing. Petr Šilhavý, Ph.D. Dostupné z: http: //theses.cz/id/cwbuph/.

[12] Mell Peter, The NIST Definition of Cloud Computing. NIST [online]. [cit. 2016-07-09]. Dostupný z WWW: http://csrc.nist.gov/publications/nistpubs/ 800-145/SP800-145.pdf

[13] NIST, Cloud Computing Reference Architecture Contract and SLA (Draft) NIST [online]. [cit. 2016-07-08]. Dostupný z WWW: http://collaborate.nist. gov/twiki-cloud-computing/pub/CloudComputing/RATax_Jan20_ 2012/NIST_CC_WG_ContractSLA_Deliverable_Draft_v1_7.pdf

[14] Mark Houghtlin. White Paper: Assessing Performance and Response Time Requirements CSCC, [online]. [cit. 2016-08-01]. Dostupný z WWW: http: //www.cloud-council.org/CSCC-Webinar-Assessing-Performance- and-Response-Time-Requirements-Webinar-11-21-14.pdf

[15] CSCC, Practical Guide to Service Level Agreements Version 1.0 www.cloudstandardscustomercouncil.org [online]. [cit. 2016-07-08]. Do- stupný z WWW: http://www.cloudstandardscustomercouncil.org/ 2012_Practical_Guide_to_Cloud_SLAs.pdf

[16] Ang Li Xiaowei Yang, Srikanth Kandula Ming Zhang, CloudCmp: Comparing Pu- blic Cloud Providers www.conferences.sigcomm.org [online]. [cit. 2016-07-08]. Do- stupný z WWW: http://conferences.sigcomm.org/imc/2010/papers/ p1.pdf

[17] R. Pozo and B. Miller, Java scimark 2.0. www.conferences.sigcomm.org [online]. [cit. 2016-07-08]. Dostupný z WWW: http://math.nist.gov/scimark2/

[18] FDCCI, What are the Deployment Models ? Info.apps.gov. [online]. 2012 [cit. 2016- 07-08].

[19] DMTF DSP026, Cloud infrastructure Management Interface (CIMI) Model and RESTful HTTP-based Protocol, 2012.

[20] Mach, R., et al., Usage Record - Format Recommendation, GFD. 98, 2006.

52 Literatura

[21] G. Atas and V. C. Gungor. Performance evaluation of cloud computing platforms using statistical methods, Comput. Electr., 2014.

[22] Google. Perkit benchmarker. [online]. [cit. 2016-07-08]. Dostupný z WWW: https: //github.com/GoogleCloudPlatform/PerfKitBenchmarker

[23] Standard Performance Evaluation Corporation SPEC CPU2006 [online]. [cit. 2016- 07-08]. Dostupný z WWW: https://www.spec.org/cpu2006/

[24] W. Sobel, S. Subramanyam, A. Sucharitakul, J. Nguyen, H. Wong, A. Klepchukov, S. Patil, A. Fox, D. Patterson. Cloudstone: Multi-platform, multi-language benchmark and measurement tools for web 2.0. CCA, 2008.

[25] J. D. McCalpin. Memory bandwidth and machine balance in current high performance computers. IEEE Computer Society Technical Committee on Computer Architecture TCCA, strany 19-25, 1995.

[26] W. D. Norcott and D. Capps. Iozone filesystem benchmark www.iozone.org, strana 55, 2003.

[27] C. Vazquez, R. Krishnan, E. John. Cloudcomputing benchmarking: Asurvey. In Procee- dings of International Conference on Grid and Cloud Computing and Applications GCA, 2014.

[28] K. Shiv, K. Chow, Y. Wang a D. Petrochenko. Cloudcomputing benchmarking: Asur- vey. Specjvm2008 performance characterization. In Computer Performance Evaluation and Benchmarking str. 17-35. Springer, 2009.

[29] K. Raman. Optimizing memory bandwidth on stream triad. 2013 [online]. [cit. 2016-07- 08]. Dostupný z WWW: https://software.intel.com/en-us/articles/ optimizing-memory-bandwidth-on-stream-triad

[30] M.S. Muller, M. vanWaveren, R. Lieberman, B. Whitney, H. Saito, K. Kumaran, J. Baron, W.C. Brantley, C. Parrott, T. Elken.Spec mpi2007—an application benchmark suite for parallel systems using mpi. Con- currency and Computation: Practice and Expe- rience str. 191-205, 2010.

[31] Mark Gates, Alex Warshavsky. Iperf. [online]. [cit. 2016-07-08]. Dostupný z WWW: https://iperf.fr/

[32] J. L. Henning. Spec cpu2006 benchmark descriptions. ACM SIGARCH Computer Ar- chitecture News str. 1-17, 2006 [online]. [cit. 2016-07-08]. Dostupný z WWW: http: //www.spec.org/cpu2006/

53 Literatura

[33] P. R. Luszczek, D. H. Bailey, J. J. Dongarra, J. Kepner, R. F. Lucas, R. Rabenseif- ner, D. Takahashi. The hpc challenge (hpcc) benchmark suite. In Proceedings of the 2006 ACM/IEEE conference on Supercomputing str. 213. Springer, 2006.

[34] Smith, Ben, Grehan, Rick, Yager, Tom, Niemi. DC. byte-unixbench - a unix benchmark suite. [online]. [cit. 2016-07-08]. Dostupný z WWW: https:// code.google.com/p/byte-unixbench

[35] Stone. Tachyon parallel / multiprocessor ray tracing system. 1995, [online]. [cit. 2016-07- 08]. Dostupný z WWW: http://jedi.ks.uiuc.edu/~johns/raytracer

[36] T. Bray. Bonnie benchmark, 1996 [online]. [cit. 2016-07-08]. Dostupný z WWW: http://www.textuality.com/bonnie/

[37] E. M. B. C. (EEMBC). Eembc – the embedded microprocessor benchmark consor- tium [online]. [cit. 2016-07-08]. Dostupný z WWW: https://www.eembc.org/ coremark/

[38] Yahoo. CBTOOL Architecture [online]. [cit. 2016-07-08]. Dostupný z WWW: https://github.com/ibmcb/cbtool/wiki

[39] Jens Axboe. Flexible I/O Tester [online]. [cit. 2016-07-08]. Dostupný z WWW: https://github.com/axboe/fio

[40] Rick Jones. Network performance benchmark netperf. [online]. [cit. 2016-07-11]. Do- stupný z WWW: http://www.netperf.org/netperf/

[41] KAČMARČÍK, Martin. Případy užití automatizace sestavení projektů v metodice prů- běžné integrace [online]. Brno, 2016 [cit. 2016-08-25]. Bakalářská práce. Vysoké učení technické v Brně. Vedoucí práce Ing. Aleš Smrčka, Ph.D. Dostupné z: dspace.vutbr.cz/bitstream/handle/11012/61815/18216.pdf.

[42] Karlsson, Ture. Automated build service to facilitate Continuous Delivery [online]. 2015 [cit. 2016-08-25]. Dostupné z: dspace.vutbr.cz/bitstream/handle/ 11012/61815/18216.pdf.

[43] Kohsuke, K. Meet Jenkins - Features, revize: 07, Leden, 2016 [online]. [cit. 2016-07- 11]. Dostupný z WWW: http://lup.lub.lu.se/luur/download?func= downloadFile&recordOId=7449594&fileOId=7449613

[44] CloudSuite group CloudSuite [online]. [cit. 2016-07-11]. Dostupný z WWW: http: //cloudsuite.ch

54 Literatura

[45] Datastax Cassandra Stress Tool [online]. [cit. 2016-07-11]. Dostupný z WWW: http://docs.datastax.com/en/cassandra/2.1/cassandra/tools/ toolsCStress_t.html

[46] Jason Long. Newline Delimited JSON [online]. [cit. 2016-07-08]. Dostupný z WWW: http://ndjson.org

[47] Rick Jones. Care and Feeding of Netperf [online]. [cit. 2016-07-08]. Dostupný z WWW: http://www.netperf.org/svn/netperf2/trunk/doc/ netperf.pdf

55 Přílohy

I A. Celkový souhrn výsledků testů

Test - Metrika Jednotka Medián [GCP] Medián [AWS] Medián [OpenStack] Medián [Azure] ping - Průměrná odezva ms 0.41 0.44 0.47 0.54 iperf - Propustnost Mbits/sec 6751.35 6215.71 5689.32 4698.67 netperf - CRR transkace ops 2290.24 2110.99 1955.72 1555.69 netperf - Propustnost Mbits/sec 6993.36 6494.33 5901.77 4861.75 cloudsuite-web-serving - Doba odezvy ms 112.92 120.93 130.53 147.53 cloudsuite-in-memory-analytics - Doba běhu s 32.76 35.21 37.39 42.65 cloudsuite-web-search - Počet operací operací/s 23.16 21.28 19.81 15.7 cassandra-stress - Počet operací operací/s 5431.51 5041.19 4553.76 3772.22 cassandra-stress - Odezva ms 27.38 29.32 31.27 35.5 coremark - Coremark skóre - 43938.29 40604.81 36524.57 30578.69 scimark2 - Skóre Mflops 1252.83 1158.14 1061.75 866.71 hpcc - Propustnost streamu Mbits/sec 11.76 11.03 10.03 8.17 hpcc - Propustnost náhodných přístupů Mbits/sec 0.03 0.03 0.03 0.02 unixbench - Propustnost pajpy Mbits/sec 4817696.38 4501818.56 4067858.11 3373553.23 unixbench - Skóre - 3381.53 3116.35 2879.68 2275.08 fio - Počet I/O operací - čtení IOPS 111.74 103.88 94.34 75.74 fio - Počet I/O operací - zápis IOPS 1483.9 1380.53 1257.38 1001.76 fio - Odezva - zápis ms 645.54 697.36 738.5 841.42 fio - Odezva - čtení ms 8902.65 9485.39 10244.62 11646.21 bonnie++ - Rychlost náhodného mazání Kb/sec 122184.3 112214.76 104286.48 84405.23 bonnie++ - Rychlost vytváření souborů Kb/sec 2822.75 2599.72 2377.52 1978.83 bonnie++ - Rychlost přepisování souborů Kb/sec 59187.14 54541.55 49439.88 41459.82

Tabulka A.1.: Mediány výsledků pro sto měření

II Seznam obrázků

2.1. Vztah vlastnosti a metriky, převzato a upraveno z [10] ...... 7 2.2. Výběr cloudové platformy z pohledu zákazníka ...... 8 2.3. Service level agreement (SLA) ...... 9 2.4. Monitoring cloudové platformy ...... 10 2.5. Obecná architektura cloudové platformy ...... 11 2.6. Vysoké vytížení jedné aplikace může přímo ovlivňovat výkon jiné apli- kace i když běží na dvou virtuálních strojích, převzato z [5] ...... 13 2.7. Vztah scénáře, měření a metriky ...... 14 2.8. Architektua Google Compute Engine, licence CCA ...... 15 2.9. Architektua OpenStack ...... 16 2.10. Architektua Azure, převzdato z [11] ...... 17

3.1. Architektura perfKit Benchmarku převzato z [22] ...... 27 3.2. Architektura CBTOOL převzato z [38] ...... 28

4.1. Průběh testování výkonu ...... 30 4.2. Obecná architektura testovacího řešení ...... 31 4.3. Ukázka Jenkins Workflow GUI ...... 32 4.4. Architektura nového testovacího řešení ...... 33 4.5. Postup běhu testů ...... 35 4.6. Ukázka krabicového grafu pro odezvy ...... 39 4.7. Ukázka vizualizace v nástroji Kibana ...... 39

5.1. Korelační matice typů virtualních strojů od AWS a GCP, převzato z [1] . 40 5.2. Coremark skóre ...... 42 5.3. Scimark 2.0 skóre ...... 42 5.4. Propustnost TCP (netperf) ...... 43 5.5. Propustnost TCP (iperf) ...... 43 5.6. Doba odezvy (ping) ...... 43 5.7. Stream rate TCP (netperf) ...... 43 5.8. Rychlost náhodného čtení ...... 44 5.9. Rychlost náhodného zápisu ...... 44

III Seznam obrázků

5.10. Odezva náhodného čtení ...... 44 5.11. Odezva náhodného zápisu ...... 44 5.12. Rychlost náhodného vytváření souborů ...... 45 5.13. Rychlost náhodného mazání souborů (Kb/s) ...... 45 5.14. Propustnost paměti ...... 45 5.15. Propustnost při součinu ...... 45 5.16. Propustnost pajpy (Kb/s) ...... 46 5.17. Celkové skóre ...... 46 5.18. Rychlost vyhledávání ...... 46 5.19. In-memory analytika ...... 46 5.20. Odezva webového serveru ...... 47 5.21. Cassandra - odezva ...... 48 5.22. Cassandra - počet operací ...... 48

IV Seznam tabulek

3.1. Charakteristiky výpočetního výkonu ...... 20 3.2. Charakteristiky výkonu paměti ...... 22 3.3. Charakteristiky diskového výkonu ...... 23 3.4. Charakteristiky sítě ...... 25 3.5. Testy doménově specifické ...... 26

5.1. Výběr testovacích instancí od čtyř hlavních poskytovatelů ...... 41 5.2. Zprůměrované výsledky pro sto měření ...... 41 5.3. Tabulka cen požadavků ...... 47

A.1. Mediány výsledků pro sto měření ...... II

V Seznam ukázek

4.1. Scénář - příprava prostředí ...... 32 4.2. Skupina scénářů pro běh testů ...... 33 4.3. Projekt ...... 34 4.4. Kofigurace CloudSuite ...... 34 4.5. Konfigurace více poskytovatelů ...... 35 4.6. Ukázka formátu Metrics 2.0 ...... 36 4.7. Ukázka implementace testu normality ...... 37 4.8. Iperf na Google Cloud ...... 38 4.9. Ukázka vykreslení krabicového grafu ...... 38

5.1. Funkce pro výpočet ceny za jeden požadavek ...... 47

VI Univerzita Hradec Králové Studijní program: Applied Informatics Faculty of Informatics and Management Forma: Full-time Akademický rok: 2014/2015 Obor/komb.: Aplikovaná informatika (ai2-p)

Podklad pro zadání DIPLOMOVÉ práce studenta

PŘEDKLÁDÁ: ADRESA OSOBNÍ ČÍSLO Kutý Michael Braunerova 3177, Kroměříž I14769

TÉMA ČESKY: Analýza výkonnosti cloud computingové infrastruktury

TÉMA ANGLICKY: Performance analysis of cloud computing infrastructure

VEDOUCÍ PRÁCE: Ing. Vladimír Soběslav, Ph.D. - KIT

ZÁSADY PRO VYPRACOVÁNÍ:

Cílem diplomové práce je analyzovat požadavky pro optimální nasazení cloud computingové infrastruktury. V praktické části proběhne měření HW infrastruktury a doporučení pro nasazení v produkčním prostředí OpenStack.

Osnova:

1. Úvod 2. Cíl a metodika práce 3. Virtualizace a cloud computing 4. Požadavky na hardware 5. Aspekty sítě 6. Údržba, správa a administrace 7. Realizace OpenStack platformy 8. Komplexní testování OpenStack platformy 9. Závěr

SEZNAM DOPORUČENÉ LITERATURY: Gartner.com. Gartner it glossary - cloud computing. http://www.gartner.com/it-glossary/cloud-computing/, February 2014. [2] Wang, S., Liu, Z., Sun, Q., Zou, H. and Yang, F. 2012. Towards an accurate evaluation of quality of cloud service in service- oriented cloud computing. Journal of Intelligent Manufacturing, pp. 1--9. [3] Furht, B. and Escalante, A. 2010. Handbook of cloud computing. New York: Springer. [4] Mell, P. and Grance, T. 2011. The NIST definition of cloud computing. NIST special publication, 800 (145), p. 7. [5] Stantchev, V. 2009. Performance evaluation of cloud computing offerings. pp. 187--192. [6] Bauer, E. and Adams, R. 2012. Reliability and availability of cloud computing. Hoboken, N.J.: Wiley-IEEE Press. [7] Rady, M. 2013. Formal Definition of Service Availability in Cloud Computing Using OWL. Springer, pp. 189--194. [8] Nie, G., E., X. and Chen, D. 2012. Research on Service Level Agreement in Cloud Computing. pp. 39-43. Available from: doi: 10.1007/978-3-642-28744-2_5. [9] Paschke, A. 2014. rbsla - RBSLA: Rule Based Service Level Agreements Project. [online] Available at: http://ibis.in.tum.de/projects/rbsla/ [Accessed: 19 Mar 2014]. [10] Paschke, A., Bichler, M. and Dietrich, J. 2005. ContractLog: An Approach to Rule Based Monitoring and Execution of Service Level Agreements. pp. 209-217. Available from: doi: 10.1007/11580072_19.

(c) IS/STAG , Portál - Podklad kvalifikační práce , I14769 , 28.08.2016 17:57