Srovnání serverových virtualizačních platforem pro potřeby MENDELU

Mendelova univerzita v Brně Provozně ekonomická fakulta

Srovnání serverových virtualizačních platforem pro potřeby MENDELU Diplomová práce

Vedoucí práce: Ing. Petr Zach, Ph.D.

Bc. Martin Šupola

Brno 2017

Poděkování Rád bych poděkoval panu Ing. Petru Zachovi, Ph.D. za odborné vedení práce, dále panu Ing. Jiřímu Passingerovi za konzultace a cenné rady, které mi během zpracování poskytoval. Také bych chtěl poděkovat Ústavu informačních technologií za poskytnutí síťové laboratoře a jejích hardwarových prostředků k provedení reálných testů. Dále bych chtěl poděkovat Ing. Jaromíru Salákovi za cenné rady a v neposlední řadě patří veliké díky i mým rodičům a bratrovi za trpělivost a shovívavost, kterou ke mně při zpracovávání této práce měli.

Čestné prohlášení Prohlašuji, že jsem tuto práci: Srovnání serverových virtualizačních platforem pro potřeby MENDELU vypracoval/a samostatně a veškeré použité prameny a informace jsou uvedeny v seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s § 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů, a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom/a, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užití této práce jako školního díla podle § 60 odst. 1 Autorského zákona. Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou (subjektem) si vyžádám písemné stanovisko univerzity o tom, že předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejich skutečné výše. V Brně dne 1. ledna 2017

_______________________________

Abstract Šupola, M. The comparison of server virtualization platforms for internal use at MENDELU. Diploma thesis. Brno: Mendel University, 2017. The thesis deals with comparison of server virtualization platforms with needs of Mendel University. Real tests of each selected virtualization platform are performed as required by the Department of Information Technology. Based on the test results, a suitable solution for the university is suggested and costs of deploying and operating of various virtualization platforms are economically evaluated. Keywords Virtualization, server, VMware, oVirt, Citrix XenServer, comparison

Abstrakt Šupola, M. Srovnání serverových virtualizačních platforem pro potřeby MENDELU. Diplomová práce. Brno: Mendelova univerzita v Brně, 2017. Diplomová práce se zabývá srovnáním serverových virtualizačních platforem pro potřeby Mendelovy univerzity v Brně. Jsou provedeny reálné testy jednotlivých vybraných virtualizačních platforem dle požadavků Ústavu informačních technologií. Na základě výsledků testů je navrženo vhodné řešení pro univerzitu a jsou ekonomicky zhodnoceny náklady na nasazení a provoz jednotlivých virtualizačních platforem. Klíčová slova Virtualizace, server, VMware, oVirt, Citrix XenServer, srovnání

Obsah

5

Obsah 1

2

3

4

5

6

Úvod a cíl práce

9

1.1

Úvod ................................................................................................................................................ 9

1.2

Cíl práce ......................................................................................................................................... 9

Přehled dostupné literatury

11

2.1

Odborná literatura a publikace ........................................................................................11

2.2

Závěrečné bakalářské, diplomové a disertační práce ...........................................12

2.3

Dokumentace výrobce virtualizační platformy........................................................15

2.4

Internetové zdroje a fóra ....................................................................................................15

Virtualizace

16

3.1

Typy virtualizací......................................................................................................................16

3.2

Základní vrstvy virtualizace ..............................................................................................18

3.3

Virtualizace serverů a její výhody a nevýhody .........................................................20

Infrastruktura

23

4.1

Redundance a agregace pasivních síťových prvků ................................................23

4.2

Redundance aktivních síťových prvků.........................................................................25

4.3

Load balancing síťových prvků ........................................................................................26

4.4

Redundance diskového pole a jeho HW ochrana ....................................................26

4.5

Základní dělení pevných disků .........................................................................................28

4.6

Správný výběr pevných disků...........................................................................................29

Analýza požadavků

31

5.1

Hardwarové vybavení univerzity ...................................................................................31

5.2

Síťová infrastruktura ............................................................................................................32

5.3

Software ......................................................................................................................................33

5.4

Virtualizování serverů ..........................................................................................................33

5.5

Zajištění spolehlivosti ...........................................................................................................34

5.6

Shrnutí..........................................................................................................................................34

Testovací metodika

35

Obsah

6

6.1

Finanční část .............................................................................................................................35

6.2

Implementační a provozní část ........................................................................................35

6.3

Testovací část ...........................................................................................................................35

6.4

Testovací prostředí ................................................................................................................43

7

8

9

Výběr technologií pro testování

47

7.1

VMware vSphere .....................................................................................................................49

7.2

Citrix XenServer ......................................................................................................................50

7.3

oVirt...............................................................................................................................................51

Náklady na pořízení a údržbu platformy

53

8.1

VMware........................................................................................................................................53

8.2

XenServer ...................................................................................................................................55

8.3

oVirt...............................................................................................................................................56

Nasazení platformy

57

9.1

VMware........................................................................................................................................57

9.2

XenServer ...................................................................................................................................58

9.3

oVirt...............................................................................................................................................59

10 Možnosti správy platforem a další nástroje

61

10.1 VMware........................................................................................................................................61 10.2 XenServer ...................................................................................................................................62 10.3 oVirt...............................................................................................................................................63 11 Testy výkonu procesoru

65

11.1 Testy výkonu procesoru 1vCPU.......................................................................................65 11.2 Testy výkonu procesoru 4vCPU.......................................................................................66 12 Testy výkonu operační paměti

68

12.1 Testy výkonu operační paměti RAM při 1vCPU .......................................................68 12.2 Testy výkonu operační paměti RAM při 4vCPU .......................................................68 13 Testy výkonu 2D grafické karty

70

14 Testy výkonu diskového úložiště

72

14.1 Test výkonu virtuálního disku na diskovém poli NAS ..........................................72

Obsah

7

14.2 Test výkonu virtuálního disku na lokálním úložišti...............................................72 15 Testy propustnosti síťové konektivity

75

16 Testy rychlosti sítě v oblasti kopírování

78

17 Testy síťových výpadků platforem

80

17.1 Výpadky diskového pole .....................................................................................................80 17.2 Výpadky celého hosta (hypervizoru) ............................................................................81 17.3 Výpadky uplinků .....................................................................................................................83 17.4 Výpadek switche .....................................................................................................................87 17.5 Dodatečné testy platformy oVirt .....................................................................................88 18 Zhodnocení platforem

90

18.1 Celkové shrnutí výsledků testů ........................................................................................90 18.2 Výběr virtualizační platformy na základě testů .......................................................91 19 Ekonomické zhodnocení

94

19.1 Ekonomické zhodnocení platformy VMware ............................................................94 19.2 Ekonomické zhodnocení platformy XenServer ........................................................95 19.3 Ekonomické zhodnocení platformy oVirt ...................................................................96 20 Diskuze

97

20.1 Přínos analýzy požadavků Mendelovy univerzity ..................................................97 20.2 Přínos výběru technologií pro testování .....................................................................97 20.3 Praktický přínos testovacích metodiky........................................................................97 20.4 Přínos kalkulace nákladů na pořízení a údržbu platformy ................................97 20.5 Praktický přínos srovnání jednotlivých platforem ................................................97 20.6 Praktický přínos testů sítových výpadků platforem..............................................98 20.7 Dopad na dění na univerzitě .............................................................................................98 20.8 Doporučení použití platforem ..........................................................................................98 21 Závěr

100

22 Literatura

101

A

106

Obsah CD

Úvod a cíl práce

9

1 Úvod a cíl práce 1.1

Úvod

Informační technologie jsou v současnosti jedny z nejrychleji se vyvíjející oblastí a bez nich by si snad žádný člověk nedokázal život představit. Prakticky se můžeme s těmito technologiemi setkat denně. Ať už v podobě nějakého počítače, telefonu, nebo tabletu a dalších chytrých zařízení, či v podobě nějakého informačního systému. Díky neustále rostoucímu počtu uživatelů a tím i častějšímu výskytu této techniky stoupá požadavek na vysokou dostupnost a spolehlivost jednotlivých služeb, jejichž provoz je stále častěji zajišťován externě v datových centrech (outsourcing). Ta se tak stávají stále složitějšími a náročnějšími pro správu a provoz. Právě díky virtualizaci je docíleno efektivního využití dostupných hardwarových prostředků, snížení energetické náročnosti a hlavně zefektivnění správy jednotlivých strojů. Díky ní je také zajištěna mnohem vyšší spolehlivost a tím i vyšší dostupnost jednotlivých služeb, které mohou být v některých oblastech, jako je například zdravotnictví nebo energetický průmysl, velmi kritické. Z výše uvedených důvodů v dnešní době nabývá virtualizace stále většího významu a najde uplatnění hlavně v datových centrech zajištující například hosting, v serverovnách firem a dalších institucí za účelem konsolidace serverů, poskytování potřebných služeb či ve vývojářské oblasti za účelem testování. Virtualizované v poslední době jsou nejen servery, ale i další síťová zařízení, například disková pole, díky čemuž se tak celá infrastruktura stává odolnější vůči nečekaným haváriím. Bohužel, samotnou virtualizací nelze stoprocentně zabránit samotným výpadkům jednotlivých služeb. Zde je zapotřebí brát v úvahu i možné potíže na úrovni samotného hardwaru a předejít jim pomocí redundance (zdvojení, ztrojení atp.) samotných prvků (směrovače, přepínače, servery a jednotlivé komponenty) či spojů (kabeláže). Tato diplomová práce se zabývá srovnáním serverových virtualizačních platforem pro potřeby Mendelovy univerzity v Brně. Bude vybráno několik nejznámějších virtualizačních platforem, na nichž budou provedeny na základě požadavků Ústavu informačních technologií reálné testy. Kromě provedení reálných testů také budou zohledněny náklady na nasazení dané platformy (například pořizovací cena za licenci) a její provoz (placená podpora, aktualizace…). Na základě získaných výsledků provedených testů a ekonomického zhodnocení bude pro Mendelovu univerzitu doporučena nejvíce vyhovující platforma.

1.2

Cíl práce

Hlavním cílem této diplomové práce je nalezení vhodné serverové virtualizace pro potřeby Mendelovy univerzity v Brně na základě požadavků (viz kapitola Analýza požadavků) Ústavu informačních technologií, který zajišťuje správu síťové infrastruktury na úrovni celouniverzitního pracoviště. Díky dotacím z EU, kraje

Úvod a cíl práce

10

a MŠMT je možné univerzitu vybavit kvalitním zařízením, nicméně čerpání těchto dotací je limitováno. Specifikace tedy musí být upravena tak, aby řešení bylo pokud možno nejefektivnější a nejvýhodnější po stránce finanční i z hlediska dlouholetého konceptu rozvoje a udržitelnosti. Kromě investice do rozvoje IT infrastruktury je jistě v zájmu univerzity snižovat například i náklady na režijní provoz těchto technologií. Je tedy zapotřebí nalézt pro Mendelovu univerzitu optimální řešení, které nebude na úkor kvality dané virtualizační technologie a bude pro potřeby univerzity plně dostačovat.


11

2 Přehled dostupné literatury Ohledně virtualizací již bylo napsáno nespočet knih a článků. Kromě této odborné literatury vzniklo mnoho závěrečných bakalářských, diplomových i disertačních prací, které se většinou zaobírají buď nasazením některé z platforem, nebo jejich porovnáním z hlediska funkcí, popřípadě je otestován jejich výkon. Další skupinou je samotná dokumentace, dostupná většinou na webových stránkách daného produktu. Nesmí se také opomenout internetové zdroje, fóra a poradny. Z hlediska kvality a aktuálnosti informací je vhodné čerpat spíše ze zahraniční literatury, která se oproti české literatuře podrobněji zaměřuje na tuto problematiku a mnohdy bývá aktuální. Literatura byla vyhledávána pomocí klíčových slov, která jsou úzce spojena s tématem této práce. Především byla pozornost věnována kombinaci slov virtualizace, VMware, oVirt, XenServer, Hyper-V, server, virtualizační platformy, porovnání, srovnání, test, benchmark a dalším podobným výrazům. Také byl brán ohled na stáří literatury, byla snaha čerpat z literatury, která nebyla starší 5 let, neboť starší literatura již nemusí být z důvodu rychlého vývoje IT průmyslu aktuální.

2.1

Odborná literatura a publikace

Tato literatura vznikla především na základě určité virtualizační platformy (technologie). Bývá dobrým vodítkem pro seznámení s jednotlivými technologiemi jak z hlediska architektury, tak z hlediska její implementace či nějakých doporučení či zkušeností autora. K dispozici je literatura v mnoha jazycích, především v jazyce anglickém. České literatury je nedostatek, bývá většinou pouhým překladem literatury anglické. Tuto literaturu je možné zakoupit v mnoha obchodech nebo zapůjčit v knihovně. Některé z knih je možné také nalézt na internetu v digitalizované podobě (většinou v podobě .pdf souboru). Mastering VMware vSphere 5.5 (Marshal, Lowe, 2013) – jedná se o knihu, která podrobně seznamuje s virtualizační platformou VMware ve verzi 5.5. Je dělena do 14 velkých kapitol a zabývá se architekturou, podrobným průvodem instalace, nasazení a správy dané platformy. Mistrovství ve VMware vSphere 5 - Kompletní průvodce profesionální virtualizací (Lowe, 2013) – Tato kniha je českou alternativou k předchozí, kde se opět zabývá instalací a konfigurací platformy VMware. Virtualization - A Beginner's Guide (Ruest, 2009) – Jedna z univerzální literatury, která se zaobírá virtualizací obecně a zaobírá se obecnými principy a způsoby virtualizace. Je možné se v ní seznámit se serverovou virtualizací a platformami Citrix, Microsoft Hyper-V i VMware. Virtualizace - Podrobný průvodce (Ruest, 2010) – tato kniha je českou alternativou k přechozí knize, je jejím překladem. Microsoft Windows server 2008 R2 Hyper-V: podrobný průvodce administrátora (Kelbley, Sterling, 2011) – oproti přechozí literatuře se tato kniha zaobírá výhradně


12

technologií Hyper-V od firmy Microsoft. Z počátku představuje obecně technologii Hyper-V v dalších kapitolách je řešena instalace, správa a zabezpečení. Mastering Hyper-V (Tender, 2015) – jedna z novější literatury která se zaobírá virtualizační platformou Hyper-V ve verzi Windows Hyper-V Server 2012 R2. Podrobně popisuje jednotlivé části platformy a dále se zabývá její instalací a správou. Jsou zde také uvedeny informace ohledně licencování. Mastering Citrix XenServer (Reed, 2014) – obdobně jako u Hyper-V a VMware i o Citrix XenServer existuje literatura, která se podrobně zaobírá jeho instalací a správou. Getting Started with oVirt 3.3 (Lesovsky, 2013) - tato kniha je praktickým průvodcem instalace a správou virtualizační platformy oVirt. Je zde představena architektura a komponenty platformy, dále provází instalací, konfigurací a následnou správou. Kromě samotné literatury ohledně virtualizačních technologií je třeba se také zaobírat síťovou problematikou. Především tématikou ohledně sítí jak z hlediska spolehlivosti (vysoká dostupnost) tak z hlediska jejího zabezpečení (síťová bezpečnost). TCP/IP v kostce (Pužmanová, 2009) – Je to kniha popisující obecně princip funkčnosti sítí, zejména protokolu TCP/IP. Autorka se zaobírá tímto protokolem na všech vrstvách ISO/OSI modelu. Také se zde zmiňuje o managementu sítě a jejím zabezpečení, kde řeší firewally, autentizaci a popisuje některé typy útoků. Kompletní průvodce síťového experta (Donahue, 2009) – Dle autora této knihy je tato kniha určena především pro ty, co již nějaké znalosti z této oblasti mají. Zaobírá se jednotlivými síťovými prvky a telekomunikací, návrhem sítí a jejího zabezpečení. Konfigurace směrovačů Cisco (Hucaby, McQuerry, 2004) – Tato kniha je autorizovaným průvodcem konfigurace síťových prvků Cisco. Zabývá se konfigurací prvků od základů až po pokročilejší nastavení, včetně různých směrovacích protokolů a zabezpečení samotných prvků.

2.2

Závěrečné bakalářské, diplomové a disertační práce

Tyto závěrečné práce jsou dostupné buď v univerzitních informačních systémech, nebo je lze najít na serveru theses.cz a podobných systémech. Nevýhodou však může být, že některé práce nejsou veřejně dostupné a mohou se značně lišit kvalitou. Samotné práce byly na serverech vyhledávány pomocí několika klíčových slov (v českém i anglickém jazyce), a to:  Virtualizace,  Windows Server,  VMware, vSphere, ESXi, vCenter,  Citrix, XenServer,  Hyper-V, Microsoft,  oVirt, KVM.  Předchozí klíčová slova v kombinaci se slovy „test“, „srovnání“, „porovnání“.


13

U jednotlivých prací byl zohledňován rok obhájení a také pod jakou fakultou daná práce byla vytvořena. Byly vybírány hlavně práce, které úzce souvisí s touto diplomovou prací. Každá z prací obsahuje nějaký teoretický výklad s odkazem na odbornou literaturu a praktickou část, ve které je řešen vymezený problém. 2.2.1

Bakalářské práce

Virtualizace – Vysoká dostupnost serverové infrastruktury (Oliva, 2013) – Autor v první části své práce uvádí teoretický výklad ohledně virtualizace obecně, dále porovnává jednotlivé virtualizační technologie, kde se zaobírá technologiemi firem Oracle, Citrix, Microsoft a VMware. V druhé části práce se zabývá technologií VMware, kde se zaobírá funkcemi pro vysokou dostupnost, především vMotion, Storage vMotion, High Availability, Fault Tolerance a Distributed Resource Scheduler. Práce je pojata teoreticky. Porovnání Microsoft Hyper-V a Citrix XenServer (Ferbr, 2010) – V této práci jsou porovnávány dvě virtualizační technologie Microsoft Hyper-V a Citrix XenServer. V první části práce jsou jednotlivé technologie představeny z hlediska architektury, v další části práce se autor zaobírá instalací platforem. Jako přínosnou část práce lze považovat praktickou část, kde autor otestoval výkon síťového spojení pomocí aplikace iPerf a rychlost disku pomocí aplikace Crystal Disk Mark. Poslední část práce obsahuje hodnocení pomocí vícekriteriálního hodnocení variant. Výkonnost síťové komunikace ve virtualizovaných prostředích (Hlaváček, 2010) – Autor se v této práci zaobírá problematikou síťové komunikace ve virtualizovaných prostředích Xen, VMware a KVM. Popisuje se zde síťová komunikace a faktory ovlivňující její výkon. Především je zde měřena propustnost sítě a ztrátovost paketů. Pro měření jsou zde uvedeny aplikace netperf, iPerf, nttcp. Autor měření nakonec provedl pomocí modulu pktgen a tcpdump. Testování bylo provedeno v prostředí dvou počítačů, z nichž jeden byl virtualizovaný a jeden bez virtualizace. Srovnání virtualizačních platforem společností Microsoft a VMware (Kos, 2015) – V první části práce je shrnuta teorie ohledně virtualizace. Dále autor popisuje virtualizační technologii společnosti Microsoft a VMware. U jednotlivých technologií porovnává jejich funkce, krátce popisuje instalaci a srovnává prostředí. V rámci praktické části porovnává výkon procesoru, grafické karty a diskového pole pomocí aplikace NovaBench. V práci ale chybí jakékoliv testy síťové konektivity a pokročilejších funkcí pro vysokou dostupnost. Porovnání virtualizačních technologií (Komínek, 2013) – tato práce se zaobírá srovnáním virtualizačních platforem VMware, Hyper-V, KVM a VirtualBox. Porovnává uvedené platformy mezi sebou především v testech výkonu procesoru, nároků na operační paměť, srovnává rychlosti disků a síťové konektivity. Nevýhodou je, že autor vše řeší pouze na jednom lokálním serveru bez redundance a bez externího diskového pole, které bývá v praxi často používáno. Porovnání technologií virtualizačních systémů (Sládek, 2012) – Stejně tak jako v přechozí práci i zde autor řeší srovnání jednotlivých technologií z hlediska výkonu procesoru, přenosové rychlosti pevného disku a síťové karty. Testy byly provedeny na obyčejném počítači a notebooku.


2.2.2

14

Diplomové práce

Virtualizace podnikového prostředí na platformě VMware (Kyšová, 2013) – Autorka se v této diplomové práci zaobírá obecným srovnáním virtualizačních platforem VMware, XenServer a Hyper-V. Porovnává jejich vlastnosti a architekturu. Následně je provedena analýza podniku a spotřeba jeho IT zdrojů. Následně podrobněji popisuje části platformy VMware a uvedení do provozu. Práce je však zaměřena spíše ekonomickým směrem. Serverová konsolidace a virtualizace (Hlaváč, 2014) – Tato práce se věnuje podrobněji virtualizační platformě Microsoft Hyper-V, popisuje její architekturu. Následně po provedení analýzy a návrhu je provedena realizace nové infrastruktury. V práci, ale chybí podrobnější informace o implementaci a nastavení. Virtualizační technologie (Patka, 2009) – Jedná se o starší práci, kde se autor věnuje principům virtualizačních technologií a jejich nástrojům. Je to práce spíše teoretického charakteru. Virtualizace a optimalizace IT v produkční společnosti (Popelka, 2013) – Autor se v první části práce věnuje analýze výchozího stavu podniku, následně popisuje virtualizaci a její principy. Následně uvádí hlavní představitele na trhu s virtualizacemi, jejichž platformy následně popisuje. V práci se také zmiňuje o virtualizaci datových úložišť, sítí a desktopů. V praktické části práce se autor věnuje implementaci virtualizační technologie Hyper-V. Chybí ale implementační detaily. Virtualizace desktopů v prostředí vysokých škol (Pejša, 2012) – Další z prací, která se zaobírá virtualizačními platformami předních hráčů VMware, Hyper-V a Citrix. Autor popisuje typy virtualizací a následně provádí implementaci virtualizace desktopů pomocí platformy VMware. Zajímavou částí práce je ekonomické zhodnocení. 2.2.3

Disertační práce

V oblasti disertačních prací existují práce, které se zaobírají virtualizací, ale autoři se přednostně zaměřují na konkrétní využití virtualizace, především cloud computing, zavedení distribuovaných sítí a další systémové integrace. 2.2.4

Obecné shrnutí závěrečných prací

V oblasti serverové virtualizace existuje nepřeberné množství závěrečných prací, které se zaobírají srovnáním jednotlivých platforem jak z hlediska teoretického, tak i po stránce srovnání výkonu. Nevýhodou je, že jednotlivé testy byly provedeny buď na obyčejném počítači s lokálním úložištěm, nebo byla implementována pouze jedna platforma. Testy samotných platforem sice existují, ale protože jsou prováděny na různorodém hardwaru, tak se výsledky testů stávají nejednoznačnými. Obecně však lze z prací čerpat cenné informace ohledně testovacích metodik, nebo problémů, se kterými se autoři museli sami potýkat.


2.3

15

Dokumentace výrobce virtualizační platformy.

Většina výrobců na svých webových stránkách produktu poskytuje dokumentaci, která mnohdy podrobně popisuje funkce, správu a nastavení dané technologie. Dokumentace je většinou psána v anglickém jazyce a je průběžně upravována dle verze dané platformy. Zajímavou částí je především dokumentace open source virtualizačních platforem, kdy je vyvíjena především komunitou, nebo se jednotlivé problémy řeší na různých webových fórech. Jedním z příkladů je online dokumentace pro platformu XenServer, která je dostupná na webových stránkách produktu. Obdobně je dostupná dokumentace i o platformě VMware, která je opět přístupná na jejich stránkách. Kromě dokumentace výrobce je například i na webovém portálu youtube.com spousta video návodů ohledně instalace a nastavení jednotlivých technologií a jejich funkcí.

2.4

Internetové zdroje a fóra

Poslední skupinou dostupných informací je internet. Vznikne-li nějaký specifický problém, jehož řešení není v literatuře uvedeno, má většina správců snahu tyto problémy řešit pomocí internetových diskuzí a fór, na kterých lze díky zkušenostem ostatních správců mnohdy nalézt řešení problémů, které již někdo v minulosti úspěšně vyřešil. Neocenitelné jsou i rady ostatních uživatelů. Mezi českými fóry je známý portál zive.cz, kde se v sekci poradna řeší různé problémy z oblasti počítačů a sítí. Na kladené dotazy většinou odpovídají jen běžní uživatelé. Problematika serverů se zde řeší sporadicky. Ekvivalentem předchozího portálu je fórum pc.poradna.net. Kromě fór existují i komunity a diskusní skupiny, které se zaobírají určitým produktem. Například pro platformu VMware existuje communities.vmware.com nebo v případě platformy XenServer discussions.citrix.com. Vzhledem k tomu, že jsou to přímo komunitní fóra provozovaná přímo pod servery daného produktu, zde často odpovídají na dotazy i certifikovaní správci, kteří mnohdy poradí správné řešení. Dalšími známými fóry jsou unix.stackexchange.com nebo stackoverflow.com kde nalezneme různé dotazy v sekci question (dotazy). Diskuzní fóra je však nutno brát s rezervou a danou problematiku kombinovat s odbornou literaturou. Mnohé návody na vyřešení daného problému nejsou oficiální, proto není na místě tyto návody z internetových zdrojů zkoušet v produkčním nasazení, neboť se nejedná o ověřené postupy.

Virtualizace

16

3 Virtualizace Virtualizace je technologie, pomocí níž můžeme provozovat na jednom počítači (či hardwaru) několik nezávislých počítačů (virtuálních strojů), které mohou podporovat různé operační systémy a aplikace, které běží současně (Ruest, 2010). Počátky virtualizačních technologií sahají až do přelomu 60. a 70. let, kdy se počátky připisují firmě IBM, kdy tato firma prováděla první pokusy se stránkovacím mechanismem v systému IBM M44/44X. (Kyšová, 2013, DP), (Bureš, 2009, DP) V současné době má virtualizace největší využití v serverové oblasti, postupně se začíná uplatňovat i v oblasti koncových zařízení, samotných desktopů. Virtualizovat však můžeme nejen samotné počítače a servery, ale i samotná síťová zařízení nebo běh aplikací. Virtualizace je velkým přínosem nejen pro ostré nasazení v provozu, ale i v oblasti vývoje a výzkumu, kdy díky ní dokážeme virtualizovat i samotný hardware, což je výhodné zejména pro vývoj aplikací, které na daném hardwaru mají být provozovány.

3.1

Typy virtualizací

Jednotlivé typy virtualizací se mezi sebou liší samotnou architekturou a způsobem samotného virtualizování. Nejčastěji se můžeme v literatuře setkat s rozdělením do čtyř základních skupin, a to:  Emulace,  plná virtualizace,  paravirtualizace,  virtualizace na úrovni operačního systému. 3.1.1

Emulace

Umožňuje provozování virtuálního stroje, který je svojí architekturou odlišný od hostujícího systému. Z toho důvodu jsou všechny operace prováděné v hostovaném systému interpretovány (není nutné jednotlivé aplikace modifikovat), což přináší vyšší provozní režii a tím i výrazné snížení výkonu. Proto je tento způsob virtualizace nejméně efektivní. Emulace neumí vyžívat hardwarovou podporu (virtualizační instrukce), kterou dnešní procesory nabízí. (Pejša, 2012, DP), (Patka, 2009, DP). Významnou vlastností emulace však je, že lze emulovat odlišnou platformu, než je ta fyzická. (Brych, 2016, DP). Typickými zástupci jsou DOSBox nebo QEMU. Mezi další zástupce patří například GameBoy emulátor, SNES emulátor nebo PlayStation emulátor. Příkladem emulace může být spouštění starých počítačových her, které lze provozovat pouze pod operačním systémem MS DOS. Někdy bývá emulace zaměňována s pojmem simulace, jedná se avšak o odlišné termíny. „Simulace je systém, který se chová podobně jako napodobovaný systém, ale nemusí se chovat nezbytně úplně stejně.“ (Poskočil, 2016, DP).

Virtualizace

3.1.2

17

Plná virtualizace

Princip plné virtualizace spočívá ve vytvoření kompletního identického obrazu fyzické architektury. U jednotlivých virtuálních strojů tak nelze poznat, že jsou provozovány ve virtualizovaném prostředí, tváří se jako fyzický stroj. Přístup ke skutečnému fyzickému hardwaru je pouze zprostředkováván s výjimkou procesoru, ke kterému hostovaný systém přistupuje přímo, proto je zde požadavek, aby byla architektura virtuálního stroje s fyzickým hardwarem jednotná. Výhodou je snadná přenositelnost mezi systémy. Nevýhodou je vysoká zátěž systému. (Pejša, 2012, DP), (Patka, 2009, DP). Plná virtualizace se dělí na:  Hostovanou architekturu – hypervizor (též Virtual Machine Monitor) je hostován pomocí operačního systému a nemá přímý přístup k fyzickému hardwaru. Mezi zástupce této architektury patří například VMware Workstation, VirtualBox, Parallels Desktop (Hlaváč, 2014, DP) (Brynch, 2016, DP),  Bare-Metal (nativní) architekturu – v případě této virtualizace je hypervizor nainstalován přímo na fyzický hardware a sám si kontroluje přístup k samotnému hardwaru. Tato architektura je v serverové oblasti hojně užívána a typickými zástupci jsou právě VMware vSphere a XenServer. (Hlaváč, 2014, DP), (Intertech.cz, 2016, online). Rozdíl mezi hostovanou a bare-metal architekturou je znázorněn na obrázku č. 1.

Obr. 1

Rozdíl mezi hostovanou a Bare-Metal architekturou (Hlaváč, 2014, DP; vlastní úprava)

3.1.3

Paravirtualizace

V případě paravirtualizace není emulován žádný hardware, část instrukcí je zpracovávána přímo pomocí reálného prostředí. (Hlaváček, 2010, BP) Oproti plné virtualizaci zde nemusí být splněný předpoklad, kdy virtuální prostředí vytvořené hypervizorem musí mít identické rozhraní a fyzické prostředí. Při zavádění paravirtualizace je nutnost modifikovat hostovaný operační systém, aby dokázal s hypervizorem spolupracovat. Hostované systémy si tak jsou vědomy toho, že jsou

Virtualizace

18

provozovány ve virtualizovaném prostředí. Nové systémy jsou pro virtualizovaný běh připraveny a jejich modifikace tak je relativně snadná. Problém nastává se systémy, u kterých není zveřejněný kód. (Patka, 2009, DP) Samotný hardware je pro hostovaný systém k dispozici přes rozhraní, které provádí volání služeb hypervizoru. Výhodou paravirtualizace je lepší výkon než v případě plné virtualizace. Tato výhoda je však právě vykoupena nutností modifikace systému. Typickým zástupcem paravirtualizace je Xen. (Pejša, 2012, DP) (Patka, 2009, DP) 3.1.4

Virtualizace na úrovni OS (Kontejnerová virtualizace)

Jak uvádí Bureš (2009), tento typ virtualizace patří spolu s paravirtualizací k nejefektivnějším formám virtualizace. Jedná se o virtualizaci na úrovni samotného jádra operačního systému. To umožňuje spuštění více virtuálních serverů na jednom fyzickém serveru. Díky tomu lze provozovat více instancí identického OS. Lze tak říci, že všechny servery sdílejí jeden operační systém. Tento typ virtualizace je znám také pod pojmem „kontejnerová virtualizace“. Typickým zástupcem je například OpenVZ, Parallels Virtuozzo Containers či Docker. Nevýhodou tohoto řešení je nemožnost používat různé operační systémy, je zde vazba na konkrétní operační systém. (Dušek, 2011, DP)

3.2

Základní vrstvy virtualizace

Jak uvádí Ruest (2010), kromě jednotlivých skupin lze virtualizaci dynamického datového centra rozdělit do alespoň sedmi základních vrstev, a to:  Serverová virtualizace (SerV),  virtualizace úložišť (StoreV),  virtualizace sítí (NetV),  správa virtualizace (ManageV),  virtualizace desktopů (DeskV),  virtualizace prezentační vrstvy (PresentV),  virtualizace aplikací (AppV). 3.2.1

Serverová virtualizace (SerV)

Serverová virtualizace se zaměřuje na rozdělení fyzické instance na několik virtuálních instancí či virtuálních počítačů a umožňuje provozovat libovolný virtuální systém založený na x86 nebo x64 platformě. Tato virtualizace se dle Ruesta (2010) dělí dále na:  Softwarovou virtualizaci (SoftV), kdy je virtualizovaný operační systém provozovaný nad virtualizační platformou běžící na existujícím operačním systému. (Ruest, 2010) Principem softwarové virtualizace je simulace virtuálního stroje, kdy jsou všechna hardwarová zařízení pomocí metody binárního překladu instrukcí simulována. Není vyžadován procesor s virtualizačními instrukcemi. (Ferbr, 2010, BP)

Virtualizace

19

 Hardwarová virtualizaci (HardV), kdy oproti softwarové virtualizaci jsou jednotlivé virtuální systémy provozovány nad softwarovou platformou bez existujícího operačního systému pomocí enginu označovaného jako hypervizor, který nabízí hardwarové zdroje jednotlivým virtualizovaným systémům. (Ruest, 2010). 3.2.2

Virtualizace úložišť (StoreV)

Díky ní můžeme několik fyzických zařízení sloučit tak, že se v systému tváří jako jeden fond úložišť. Takovéto úložiště může nabývat několika podob, a to:  Přímo připojené úložiště (DAS – Direct Access Storage),  síťové připojené úložiště (NAS – Network Attached Storage),  storage area network (SAN – Storage Area Network). Pro propojení virtuálních úložišť se využívá několika protokolů, z nichž nejznámější jsou Fiber Channel, iSCSI (Internet Small Computer Systém Interface), FCoE (Fibre Channel over Ethernet) nebo pomocí systému souboru NFS (Network File System). (Ruest, 2010) Virtualizace síťových úložišť tak poskytuje větší ochranu před haváriemi a přináší možnosti vytváření snapshotů (snímky nebo obrazy disků), umožňuje spojování diskových polí za účelem získání větší kapacity. Dále je přínosem možnost provádění migrací bez nutnosti odstavení běžícího serveru, synchronizace (možnost vytváření kopií), replikace (možnost vytváření opožděných kopií) a zálohování. V neposlední řadě je přínosem i vysoká dostupnost (HA – High Availability) a možnost thin provisioningu, kdy je serverům prezentován větší diskový prostor, než je ve skutečnosti potřeba (například 80 GB virtuální disk ve skutečnosti zabere pouhých 20 GB diskového prostoru). (Bureš, 2009, DP). 3.2.3

Virtualizace sítí (NetV)

Je hojně používaným způsobem dělení fyzické sítě na několik virtuálních instancí. Tento způsob virtualizace je známý také jako VLAN (Virtual Local Area Network). (RUEST, 2010) Využití VLAN sítí přináší snížení broadcastů v síti, umožní omezení počtu kolizních domén. Dále umožňuje seskupování prvků v síti a oddělení komunikace mezi nimi. V neposlední řadě je přínosem zjednodušená správa sítě díky snadné změně v konfiguraci (odpadá nutnost přepojování kabeláže), snížení počtu nutného hardware, kdy může být na jednom přepínači více podsítí. Důležitým faktorem je také vyšší bezpečnost. (Bureš, 2009, DP) Kromě VLAN sítí do kategorie virtualizace spadají i sítě VPN (Virtual Private Network). Jde o technologii virtuálních sítí, která se používá například pro bezpečnou komunikaci přes síť internet například mezi dvěma pobočkami nějaké organizace. VPN umožňují šifrování, autentizaci a integritu dat. Typickým zástupcem je OpenVPN server. (Bureš, 2009, DP)

Virtualizace

3.2.4

20

Správa virtualizace (ManageV)

„Zaměřuje se na technologie, které spravují celé datové centrum, jak fyzické tak i virtuální, a které prezentují jedinou a sjednocenou infrastrukturu pro poskytování služeb.“ (RUEST, 2010) Dle Ruesta správa virtualizace obsahuje dvě vrstvy, a to:  Fondy zdrojů – množina hardwarových prostředků,  nabídka virtuálních služeb – služby poskytované koncovým uživatelům a tvoří je virtuální stroje. Dle Popelky (2013) je to soubor nástrojů, které umožňují spravovat toto virtuální i fyzické prostředí. Typickými zástupci předních platforem jsou VMware vCenter, Citrix XenCenter a MS System Center VMM. (Popelka, 2013, DP) 3.2.5

Virtualizace desktopů (DeskV)

Umožňuje centralizaci nasazení desktopů a tím i snížení nákladů na distribuovanou správu. K těmto systémům se přistupuje pomocí tzv. terminálů, nebo také tenkých klientů. (RUEST, 2010) Jak uvádí Bureš (2009), virtualizace desktopů (pracovních stanic) s sebou přináší větší flexibilitu správy počítačů a umožnuje rychleji reagovat na požadavky samotných uživatelů. 3.2.6

Virtualizace prezentační vrstvy (PresentV)

Nabízí pouze virtualizaci prezentační vrstvy, bývá označována také jako terminálové služby. Díky virtualizaci aplikací, virtualizaci desktopů a serverové virtualizaci však potřeba virtualizace prezentační vrstvy klesá. (Ruest, 2010) Díky této technologii lze například k serverům přistupovat i vzdáleně například pomocí protokolu RDP (Remote Desktop Protocol), který navíc umožňuje šifrovat provoz mezi serverem a koncovým zařízením. Přínosem je vyšší bezpečnost, jednoduchá správa a odstranění hrozeb nekompatibility. (Bureš, 2009, DP) 3.2.7

Virtualizace aplikací (AppV)

„Používá stejné principy jako softwarově založená serverová virtualizace, ovšem místo poskytování enginu ke spouštění celého operačního systému odděluje virtualizace aplikací provozní aplikace od operačního systému“ (Ruest, 2010) Hlavními výhodami je snížení nutnosti správy a instalace aktualizací na jednotlivých stanicích, nezávislost na operačním systému, je také omezena nutnost mít administrátorská práva. Hlavními představiteli jsou Citrix XenApp, Microsoft App-V nebo VMware Horizon (Popelka, 2013, DP)

3.3

Virtualizace serverů a její výhody a nevýhody

Jednou z výhod virtualizace serverů je zjednodušení a zefektivnění správy celé síťové infrastruktury. Zjednodušení správy samotných serverů a tím i snížení nákladů na pořízení drahého hardwaru. Jak uvádí Ruest (2010), mezi jedny

Virtualizace

21

z nejčastějších stimulů, kvůli kterým se většina institucí sáhne po virtualizaci, patří:  Snížení nákladů na pořízení hardwaru,  efektivnější využití serverů,  snížení počtu fyzických serverů,  snížení nákladů na jejich údržbu,  snížení mzdových náklady (např. placená práce technika),  snížení doby odstávek (např. z důvodu servisních zásahů),  snížení výdajových režií (náklady na elektrický proud),  zachování zastaralých systémů,  jednotná správa softwaru,  vzdálené testovací prostředí,  možnost konsolidace,  možnost migrace serverů,  zjednodušení zálohování, Hlavním přínosem virtualizace je tedy efektivní využití dostupných hardwarových prostředků. Samotný server pro svůj provoz vyžaduje i určitý prostor, provozní podmínky (například chlazení) a spotřebovává elektrickou energii. Je neefektivní, pokud je většina serverů vytížena na 10 procent či dokonce méně. To vše při větším počtu serverů zbytečně prodražuje náklady na provoz a celkovou údržbu datového centra i z důvodu vyšších vynaložených nákladů za nákup drahého hardwaru. (Ruest, 2010), (Salák, 2016, DP), (Kyšová, 2013, DP) Při zavedení virtualizace můžeme snížit počet samotných fyzických serverů (minimalizace počtu fyzického hardwaru), u kterých můžeme díky souběžnému provozu několika virtuálních strojů docílit 80 procentního nebo vyššího využití hardwaru, a to při zachování stejné zátěže. (Ruest, 2010) Dále jsme schopni díky virtualizování snížit spotřebu elektrické energie celého datového centra a rovněž snížit objem odpadního tepla, které servery produkují. (Salák, 2016, DP) Kromě eliminace počtu fyzických serverů je pomocí virtualizace mnohem jednodušší i jejich samotná správa. Díky provozu serverů ve virtuálním prostředí můžeme omezit počet odstávek, které je občas nutné udělat z důvodu servisního zásahu do hardwaru serverů. Zjednodušilo se i případné stěhování serverů díky možnosti živé migrace na jiný stroj, čímž můžeme zajistit neustálý běh dané služby (vysoká dostupnost – high availability, fault tolerance). Jednou z dalších výhod je i možnost centralizované vzdálené správy bez nutnosti fyzické přítomnosti u serveru a zároveň možnosti provádět zásah na několika serverech najednou. Volbou vhodné formy virtualizace jsme schopni také dosáhnout i vyšší spolehlivosti a dostupnosti služeb. V tomto ohledu nelze spoléhat na samotnou virtualizaci, která nám umožní efektivnější využití hardwaru, ale je nutné brát v potaz i redundanci (duplikaci) samotných serverů a dalších síťových prvků zajištující síťovou konektivitu. V případě výpadku některého ze síťových prvků nám redundance zajistí minimální délku možného výpadku. (Pejša, 2012, DP)

Virtualizace

Obr. 2

Rozdíl mezi virtualizovaným a nevirtualizovaným řešením (Siebert, 2009, online)

22

Infrastruktura

23

4 Infrastruktura Součástí každé počítačové sítě je i vlastní síťová infrastruktura, na které je celá síť postavena. Je složena z aktivních a pasivních prvků. Aktivní prvky jsou především samotné servery, různé přepínače (switche), směrovače (routery) a další doplňující síťové prvky. Mezi pasivní prvky se především řadí síťová kabeláž, která jednotlivé aktivní prvky mezi sebou propojuje. Pro upřesnění, přepínač (switch) je aktivní síťový prvek v počítačové síti, který na základě MAC adresy a CAM tabulky přeposílá rámce na konkrétní port. Pracuje na L2 vrstvě ISO/OSI modelu. Směrovač (router) je též aktivní síťový prvek, pracující na L3 vrstvě ISO/OSI modelu, který přeposílá packety mezi sítěmi na základě IP adresy. Součástí směrovače většinou bývá i firewall, pomocí jehož pravidel jsme schopni řídit tok dat v síti. Aby byla zachována vysoká dostupnost a spolehlivost jednotlivých služeb poskytovanými jednotlivými servery, je zapotřebí zajistit i vysokou spolehlivost na úrovni síťové infrastruktury. Proto se i v této oblasti zavádí redundance, neboli duplikování jednotlivých spojů a síťových prvků. Právě díky redundanci je zajištěna při výpadku některého z prvků minimální délka možného výpadku.

4.1

Redundance a agregace pasivních síťových prvků

Jedním ze způsobů, jak zajistit vysokou spolehlivost a dostupnost síťových služeb (High availability) je redundance síťových rozhraní. Jedná se o zdvojení síťové konektivity mezi jednotlivými síťovými uzly. Dle důležitosti daného spoje může být využito i více než dvou spojů. Páry síťových rozhraní pak fungují v tzv. „bondu“. Rendundace je typicky využívána spíše v distribuční a core vrstvě počítačové sítě (viz obrázek č. 3). Tedy tam, kde by výpadek konektivity jednoho ze spojů způsobil odstavení větší části sítě. Naopak u přístupové access vrstvy se redundance nepoužívá, protože při výpadku konektivity jednoho uživatele nedojde k ohrožení funkčnosti celé sítě jako celku, navíc by to celou počítačovou síť zbytečně prodražilo. Výjimkou jsou samotné servery, případně disková pole a další kritické síťové prvky, u kterých je redundantní připojení nutností. Na obrázku č. 3 je znázorněn tradiční design počítačové sítě včetně redundance, doporučený společností Cisco Systems.

Infrastruktura

24

Obr. 3 Tradiční design počítačové sítě s redundancí distribuční a core vrstvy (Cisco Systems, Inc, online, 2016, upraveno)

Díky redundanci se v počítačové síti využívá i agregovaných spojů, kdy bývají jednotlivé skupiny kabeláže agregovány (spojeny) a tváří se tak jako jeden spoj schopný vyšších přenosových rychlostí (to v závislosti na způsobu implementace). Bývá implementována na nižších vrstvách ISO/OSI (fyzická L1 a linková L2) modelu a je specifikována ve specifikacích IEEE. (Šoun, 2012, DP) Můžeme se však v praxi setkat i s dalšími termíny, jako jsou linková agregace (link agregation), EtherChannel, NIC Teaming, Port Teaming či bonding. (samuraj-cz.com, 2016, online) Bonded link komunikuje přes více síťových rozhraní. Jeho vytvoření však obnáší několik podmínek. Jednotlivé spoje musí být stejného typu a rychlosti, dále musí být zařazeny do stejné VLAN sítě, popřípadě trunk portu. Trunk port je takový port, přes který komunikuje více VLAN sítí. Využíváním bonded linků tak získáme vyvažování zátěže (Load Balancing) a zároveň i redundantní ochranu, protože při pádu jednoho uplinku zůstávají další uplinky aktivní. (samuraj-cz.com, 2016, online) Podstatou NIC Teamingu je spolupráce více síťových rozhraní. Zatímco například LACP režim musí být podporován oběma stranami, mezi kterými je tento režim aplikován, NIC Teaming stačí nakonfigurovat pouze na straně zařízení. (samuraj-cz.com, online) Dle dokumentace kernelu (jádra Linuxu) existuje celkem 7 základních režimů, které lze pro spolupráci síťových karet použít (Davis, 2011, online):  Režim 0 – Balance-RR (Round-Robin),  režim 1 – Active-backup,  režim 2 – Balance-XOR,

Infrastruktura

25

   

režim 3 – Broadcast policy, režim 4 – 802.3ad, režim 5 – Balance-TLB, a Režim 6 – Balance-ALB. Existují i modifikace těchto režimů, které obsahují různá vylepšení nebo proprietární funkci. Například u společnosti Citrix se lze setkat s režimem Balance-SLB (uváděný jako režim 7), což je vylepšená modifikace režimu Balance-ALB (OpenStack, 2016, online). NIC teaming kromě redundance přináší možnost vyvažování zátěže. Na obrázku č. 4 je ukázka použití EtherChannelu a NIC teamingu u síťových prvků společnosti Cisco Systems.

Obr. 4

4.2

Ukázka použití EtherChannelu a NIC teamingu (Samuraj.cz, 2009, online, upraveno)

Redundance aktivních síťových prvků

Stejně tak, jak můžeme zavádět redundanci pasivních prvků, můžeme zavádět redundancí i prvků aktivních. V praxi může být provedena redundance jak switchů, routerů, tak i celých serverů nebo diskových polí. Jedná se o zdvojování celé síťové topologie. Dle typu zařízení, u kterého je zaváděna redundance, existuje několik způsobů, jak takovou redundanci provést. V případě serverů, diskových polí a jiných obdobných zařízení je redundance prováděna například pomocí replikace (vytváření kopii), nebo v případě virtualizace provozování serverů v High availability clusteru. High Availability cluster je takový cluster ve kterém jsou implementovány ochrany pro vysokou dostupnost (využívání redundance, replikace, RAID polí apod.). Cluster je skupina serverů/počítačů, které mezi sebou spolupracují. Existuje několik typů clusterů, například výpočetní cluster, u kterého dosáhneme vyššího výpočetního výkonu, High availability cluster pro zajištění nepřetržitého chodu služeb. Příkladem může být i Load balancing cluster, kde je vytížení hardwaru rozloženo mezi několik serverů. (technet.idnes.cz, 2010, online) V neposlední řadě je redundance prováděna i na úrovni samotného hardwaru, kdy například servery mají dva zdroje, sadu ventilátorů, pevné disky pracují v poli RAID a jiné. (Šoun, 2012, DP)

Infrastruktura

4.3

26

Load balancing síťových prvků

Díky NIC Teamingu, bondingu a dalším protokolům, případně redundanci síťových zařízení získáváme kromě ochrany vůči výpadkům v síti i možnost vyvažování zátěže (load balancing). Load balancing je založen na aktivní spolupráci více prvků, například síťových karet, kde je síťová zátěž mezi tyto prvky rozložena. Řízení vyvažování zátěže je především dáno ovladači daného zařízení, použitým protokolem nebo jinou softwarovou utilitou. V případě load balancingu síťových karet záleží na použitém režimu teamingu. Jedním z příkladů může být režim Balance-ALB (Adaptive Load Balancing) u kterého je vyvažování zátěže prováděno na základě vytížení (utilizace) jednotlivých linků. Je třeba si dát pozor na to, že ne všechny režimy load balancing zajišťují. Například u režimu Active-Backup je aktivní pouze jedna síťová karta a druhá je v režimu standby (režim spánku) a aktivuje se v případě pádu aktivního uplinku (zajištění vysoké dostupnosti). Popis principu funkčnosti jednotlivých režimů můžeme nalézt například na internetových stránkách OpenStacku (OpenStack.org, 2019, online) V případě load balancingu síťových prvků (typicky switchů) je vyvažování zátěže řízeno síťovými protokoly. Příkladem může být na platformě Cisco Systems protokol PVST (Per VLAN Spanning Tree), kdy pro každou VLAN síť je vytvořena separátní instance protokolu STP a je určen primární a sekundární root switch. V případě vyvažování zátěže samotných serverů je load balancing řízen například samotnou virtualizační platformou na základě nastavené politiky. Jako příklad můžeme uvést cluster dvou serverů, na kterých běží několik virtuálních strojů. Pokud bude například na serveru A utilizace procesoru vyšší, jak 80 % a na serveru B bude utilizace procesoru 20 %, virtuální platforma přemigruje (přesune) některé virtuální stroje ze serveru A na server B. Vytížení serverů se tak vyváží.

4.4

Redundance diskového pole a jeho HW ochrana

Zabezpečovací technologie, která je známá napříč serverovými i desktopovými platformami je pole RAID (Redundant Array of Independent Disks). Je to pole nezávislých disků, které zajišťuje vyšší spolehlivost a vyšší odolnost vůči náhodné ztrátě dat. Existuje v několika režimech, které je možné mezi sebou kombinovat. (Sládek, 2013, DP) Především je možné se setkat s režimy 0, 1, 5, 6 a jejich kombinacemi 1+0 (10) nebo 5+0 (50). Existují i pole RAID 2, 3, 4 a 7, s těmi je ale možné se setkat sporadicky, nejsou v praxi tak hojně užívány. RAID však neplní funkci zálohy, pouze zvyšuje bezpečnost dat a při použití některých režimů zvyšuje i rychlost diskového pole. Níže jsou popsány nejčastěji používaná pole RAID. 4.4.1

RAID 0 – Striping

Režim RAID 0 je to pole, ve kterém jsou jednotlivé disky spojeny (stripe) a tváří se jako jeden logický celek o kapacitě, která je rovna součtu kapacit samotných disků. Tento režim zvyšuje rychlost celého diskového pole díky prokládanému ukládání

Infrastruktura

27

dat na jednotlivé disky, kdy je zátěž mezi disky rozložena. Celé pole je ale náchylné na ztrátu dat, pokud dojde k selhání kteréhokoliv z disků. (Sládek, 2012, DP) 4.4.2

RAID 1 – Mirroring

RAID 1 je opakem režimu RAID 0, oproti kterému jsou data na jednotlivých discích zrcadlena (mirror). Nevýhodou RAIDu 1 je ztráta 50 % celkové kapacity pole, kterou můžeme využít pro data. Na jednotlivé disky jsou ukládána totožná data (disky jsou kopií), docílíme tak vysoké spolehlivosti a zamezíme ztrátě dat, selže-li kterýkoliv disk. Pokud selžou všechny disky, přicházíme tak o veškerá data. (Sládek, 2012, DP) 4.4.3

RAID 5

K provozu tohoto pole jsou zapotřebí minimálně tři pevné disky. Princip činnosti spočívá v dopočítávání parity dat, která je uložena střídavě na všech discích. Celková kapacita pole je n-1 disků, kdy v poli může díky dopočítané paritě dat selhat jeden z kterýchkoliv disků, aniž by data byla nějak dotčena. V případě selhání více disků dochází ke ztrátě dat. Výhodou tohoto diskového pole jsou vyšší rychlosti čtení a široká podpora v softwarových i hardwarových řadičích. (Sládek, 2012, DP), (Salák, 2016, DP) 4.4.4

RAID 6

RAID 6 je svým principem funkčnosti obdobný předchozímu poli RAID 5. Liší se jen potřebou minimálně čtyř disků. Pole obsahuje dva paritní bloky dat, které jsou střídavě rozprostřeny na jednotlivých discích. Je odolné vůči selhání současně kterýchkoliv dvou disků, čímž je zajištěna vyšší spolehlivost oproti poli RAID 5. Výpočet parity dat ale vyžaduje více systémových výpočetních prostředků. (Sládek, 2012, DP) (Salák, 2016, DP) 4.4.5

RAID 1+0 (10) a 0+1 (01)

Oba režimy RAID 10 a RAID 01 jsou kombinací polí RAID 0 a RAID 1. Toto pole přináší spojení kapacit disků v jeden a zároveň jsou data zrcadlena na další disky. V případě implementace pole RAID 10 se jedná o dvojice disků, které běží v poli RAID 1 a nad nimi by byl implementován režim RAID 0. V případě pole RAID 01 je implementace opačná. V případě této implementace je možné selhání po jednom disku z každého poskládaného pole RAID 1. (Salák, 2016, DP) 4.4.6

Redundance celých polí

Samotná hardwarová ochrana RAID však v praxi není dostačující. V případě selhání celého pole, budeme-li brát v potaz nejhorší scénář, kdy díky vadnému zdroji shoří všechny disky, přijdeme o všechna data, která byla v poli uložená. Zdvojením takového pole dosáhneme vysoké dostupnosti a dále v závislosti na implementaci můžeme využít možnosti zálohování, replikace či cloudových úložišť. V případě repli-

Infrastruktura

28

kace diskových polí dochází k replikaci obsahu mezi několika poli (data jsou na obou polích duplicitní), v případě zálohování mohou být zálohovány jen určité adresáře, které mají pro daný subjekt kritický obsah.

4.5

Základní dělení pevných disků

Pevné disky jsou základním prvkem diskových polí. Pokud je takové diskové pole složeno z pomalých pevných disků o nízkých výkonech, bude i celková propustnost při práci s diskovým polem nízká. Pro pochopení principů, uvedených v práci je nutné vnímat rozdíl mezi SSD diskem, běžným HDD harddiskem a SSHD diskem, který je kombinací obou předchozích. 4.5.1

Plotnové pevné disky (HDD)

Nejčastější médium, se kterým se můžeme setkat napříč všemi zařízeními, je plotnový pevný disk. Data jsou zapisována pomocí magnetického pole na jednotlivé plotny do jednotlivých sektorů, ten je nejmenší adresovatelná jednotka disku. Plotnové disky se vyznačují nízkou cenou za jeden gigabyte a jsou tak vhodné pro běžné použití a ukládání dat. Díky přítomnosti mechanických částí mají vyšší poruchovost a oproti SSD diskům malé rychlosti, které se v současné době pohybují až kolem 220 MB/s. Bývají také zdrojem tepla a mají vyšší spotřebu elektrické energie, která se pohybuje řádově od 5 do max. 10 W v závislosti na modelu disku. 4.5.2

Solid State Disky (SSD)

Fungují na principu zápisu dat do flash pamětí pomocí elektrického signálu. Jednotlivé flash paměti se však liší technologií uchování samotných dat a prací s nimi. Mezi nejznámější technologie patří TLC, MLC a SLC.  TLC (Triple-Level Cell) – Paměťové buňky této technologie mohou nabývat celkem osmi stavů, kde každý stav uchovává informaci o hodnotě 3 bitů (Hána, 2014, DP) Tento typ buněk je nejlevnější, nabízejí nejmenší výdrž při častých přepisech.  MLC (Multi-Level Cell) – Tato technologie používá multiúrovňové buňky, které mohou nabývat čtyř dvoubitových stavů (Hána, 2014, DP)  SLC (Sigle-Level Cell) – Jednotlivé paměťové buňky jsou schopny uchovávat pouze jeden bit. (Hána, 2014, DP). Tento typ buněk je nejodolnější, tato vlastnost je však vykoupena vysokou cenou. Mezi přední výhody těchto disků patří vysoké rychlostí, extrémní odezva, mizivá fragmentace, nízká energetická náročnost a díky absenci mechanických částí i menší riziko poruchy. 4.5.3

Hybridní pevné disky (SSHD)

Zvláštním případem pevných disků jsou hybridní, tzv. SSHD disky. Jde o kombinaci klasického plotnového pevného disku, který má na elektronice přidanou „část“ SSD disku. Tyto disky mají kompromis výkonu mezi běžnými HDD a SSD.

Infrastruktura

4.5.4

29

Sběrnice pevných disků

Důležité je také zmínit jednotlivé sběrnice pevných disků. Nebudeme se zde zaobírat technickými detaily, ty jsou dohledatelné v manuálech či jiných referenčních dokumentech.  IDE (ATA) – starší rozhraní používané především v počítačích,  SCSI – starší rozhraní používané v serverech a některých pracovních stanicích,  SATA – moderní, hojně používané rozhraní,  SAS – moderní rozhraní používané v serverové oblasti,  M.2 – rozhraní určené pro SSD disky,  mSATA – rozhraní určené pro SSD disky,  PCI-express – slot určen primárně pro grafické a jiné rozšiřující karty, nyní však využíván i pro připojení rychlých SSD disků.

4.6

Správný výběr pevných disků

Správný výběr disku je důležitý neboť jeho špatná volba může silně ovlivnit jeho životnost. Typickým příkladem špatné volby pevného disku je použití datového disku, který je určený pro občasné ukládání dat v serveru, kde je přetěžován, čímž se zkracuje jeho životnost. Opačným případem je použití serverového disku v obyčejném počítači, kde je vyšší výskyt start/stop cyklů, na které nejsou tyto disky přizpůsobeny. Existují statistiky poruchovosti pevných disků. Jednu z nich vede server Blackblaze.com, který již několik let vede na základě vlastního sběru dat statistiky poruchovosti jednotlivých modelů disků čtyř největších výrobců (Hitachi, Seagate, Toshiba a Western Digital). Podrobnější statistiku ohledně poruchovosti jednotlivých modelů je možné najít na výše zmiňovaném serveru. V následujícím grafu je znázorněna průměrná poruchovost pevných disků za poslední 3 roky.

Obr. 5

Statistika poruchovosti pevných disků (Blackblaze, 2016, online, upraveno)

Infrastruktura

4.6.1

30

Datové pevné disky

První skupinou jsou pevné disky, které jsou určeny do koncových stanic pro ukládání statických dat (fotky, videa, dokumenty). Většinou se u těchto disků počítá, že budou doplňkem pro rychlý SSD disk a tudíž na nich nebude nainstalován operační systém. Oproti běžným diskům se vyznačují nižšími otáčkami ploten, standardně 5400 otáček za minutu (dále jen RPM) nebo 5900 RPM. Mívají větší vyrovnávací cache paměť, různé šetřící funkce. Oproti běžným pevným diskům se 7200 RPM bývají obecně pomalejší. Nejsou vhodné pro serverové nasazení. 4.6.2

Systémové pevné disky

Jde o pevné disky pro běžné použití, v koncových stanicích využívají jako systémové (je na nich nainstalován operační systém). Standardně mívají 7200 otáček za minutu a velikost cache paměti v rozmezí od 16 MB do 128 MB v závislosti na modelu disku. Jsou ošizeny o šetřící funkce a nepředpokládá se u nich náročný, nepřetržitý provoz. Tyto disky nejsou primárně určeny pro práci v RAIDovém poli. Zástupci disků této kategorie jsou například WD Blue, nebo Seagate Barracuda. (Western Digital Corporation, 2016, online), (Seagate Technology LLC, 2016, online) 4.6.3

Serverové pevné disky

Typické serverové disky mají menší plotny, 7200, 10000 nebo 15000 otáček. Mají většinou upravený firmware a jsou přizpůsobeny pro běh v RAID poli. Výrobci na ně poskytují i delší záruku (většinou 5 let). Vyrábí se sběrnicí SATA i SAS. Do této skupiny spadají například disky řady WD RE (RAID Edition) od firmy Western Digital, nebo řada Surveillance od firmy Seagate. (Western Digital Corporation, 2016, online), (Seagate Technology LLC, 2016, online) 4.6.4

Pevné disky pro ostatní použití

Spolu se vznikem jednotlivých skupin disků začaly vnikat i řady, které jsou určené do kamerových systémů, do DVD rekordérů nebo pro použití v další domácí elektronice. Tyto disky většinou vychází z výše uvedených řad, případně jsou různými způsoby upraveny. Patří sem například řada Purple od WD nebo Video HDD od Seagate. (Western Digital Corporation, 2016, online), (Seagate Technology LLC, 2016, online) 4.6.5

SSD Disky

SSD disky nejsou oproti pevným diskům děleny do žádných skupin. Všechny disky pracují na stejném způsobu, liší se pouze typem použitých buněk (TLC, MLC, SLC), použitím různých modelů řadiče a sběrnice, ke které se připojují. Zejména u dražších disků se můžeme setkat i s dodatečnými ochranami, například použitím přídavných SMD kondenzátorů, které v případě náhlého výpadku napájení ještě „podrží“ napětí v disku pro dokončení zápisu aktuálně zapisovaných dat.


31

5 Analýza požadavků „Analýza požadavku je nezbytnou součástí procesu vývoje, realizace a následné implementace většiny softwarových řešení, například právě informačního systému. Na základě analýzy požadavku jsme schopni určit a vyhodnotit, jaké softwarové řešení zákazník potřebuje a co vše by měl požadovaný software umět.“ (SovaNet, 2016, online) Lze tedy říci, že pomocí analýzy požadavků se provádí zkoumání a identifikace potřeb a nároků daného subjektu na software či nějaký jiný systém za účelem jasného vymezení funkcionality. Výstupem pak je specifikace požadavků, která obsahuje výsledný seznam požadavků na daný systém. Mendelova univerzita se nachází v několika areálech. Kromě samotného kampusu univerzity a areálu FRRMS (budova Z) jsou součástí počítačové sítě i koleje Akademie, koleje Jana Ámose Komenského a Tauferovy koleje. Dále pak Zahradnická fakulta v Lednici a menší odloučená pracoviště, například statek ve Křtinách, Žabčicích a jiné. Univerzitní počítačová síť by se tak dala díky analýze a sledování provozu srovnat se středně velkou společností, neboť se k ní dle informací ÚIT připojuje denně kolem 12 tisíc aktivních uživatelů (platné k 1. 9. 2016), kteří využívají nabízené služby. Analýza a sběr požadavků byly provedeny formou konzultace s vedoucím Ústavu informačních technologií, s Ing. Jiřím Passingerem.

5.1

Hardwarové vybavení univerzity

V současnosti má největší význam nová serverovna v objektu X, pak menší serverovna v objektu Q a dosluhující serverovna v objektu E, ze které jsou jednotlivé servery postupně přesouvány do nově vybudovaného datového centra v objektu X. V serverovnách se nachází v provozu celkem cca 150 serverů včetně fakultních, které nespadají pod správu Ústavu informačních technologií. Z tohoto celkového počtu je zhruba:  10 serverů fyzických (hypervizory),  100 serverů virtualizovaných (jsou hostované jednotlivými hypervizory),  40 serverů, které nejsou virtualizované (fyzické stroje). Hardwarová konfigurace samotných serverů je různorodá a průměrné stáří hardwaru se pohybuje kolem 5 let. Univerzita nemá stanovený cyklus obměny hardwaru, ta probíhá kontinuálně dle možností a dostupnosti finančních prostředků. Následující tabulce č. 1 jsou uvedeny parametry nejstarší a nejnovější hardwarové konfigurace serverů, které jsou aktuálně v aktivním provozu.

Analýza požadavků Tab. 1

32

Porovnání nejstarší a nejnovější konfigurace serverů

Komponenta Procesor Operační paměť Pevné disky Síťové karty

Nejstarší Intel Pentium 4 (1 jádro, 1 vlákno) 512 MB DDR1 160 GB 100Mbps

Nejnovější Intel Xeon (8 jader, 16 vláken) 256 GB DDR3 500 GB SATA + Diskové pole 10 Gbps

Výběr nových serverů a dalšího hardware je prováděn dle nejnižší nabídnuté ceny, kdy hardware musí splňovat technické zadání, které je dané svým účelem použití. K tomuto hardwaru je zároveň v posledních několika letech dokupována záruka NBD (Next Bussiness Day), ve které se dodavatel zavazuje vzniklou závadu odstranit následující pracovní den. Tento typ záruky nabízí například společnost DELL. V případě dodatečného nákupu hardwaru (například do existujícího clusteru) je většinou požadován identický kus HW jako ten, který je již v provozu. V současné době se v serverovnách nachází pouze „rackmount“ servery (servery určené pro montáž výhradně do RACK skříní, značené někdy jako 1U, 2U, 4U a podobně). Modulární blade servery univerzita z důvodu příliš vysokých pořizovacích nákladů nepoužívá. Dle informací ÚIT bude univerzita potřebovat z hlediska dlouholetého konceptu rozvoje spíše více virtualizovaných serverů. Pro skladování produkčních dat univerzita používá značková disková pole (typicky od HP, DELL, SUN, Synology, QNAP nebo Quanta Computeru), která jsou prodávána jako hotová řešení a ke každému diskovému poli má univerzita zakoupenou podporu. V těchto diskových polích jsou použity SSD disky i klasické plotnové disky různých značek a jsou většinou součástí již kupovaného pole, není-li uvedeno jinak. Disky v diskových polích jsou provozovány v RAIDovém poli typu RAID 5, přičemž již bylo uvažováno o nasazení odolnějšího pole RAID 6. Disková pole jsou k síti připojena pomocí dvou 10 Gbps uplinků a každé z polí je společné v průměru pro 4 hypervizory. Disková pole pracují v páru. Dle informací ÚIT se replikace nepoužívá.

5.2

Síťová infrastruktura

Všechny důležité servery jsou umístěny v datovém centru univerzity, které se dá považovat za srdce celé infrastruktury, neboť se v něm nachází i centrální (core) switche a routery celé univerzitní sítě. Univerzitní servery disponují několika síťovými kartami, z nichž:  100 Mbps spoje používá naprosté minimum serverů (dosluhující stroje),  1 Gbps spoje používá cca 85 % serverů, z toho 30 % spojů je bondovaných (pracujících v párech),  10 Gbps spoje používá cca 15 % serverů, z toho je téměř 100 % spojů bondovaných (pracujících v párech).


33

Pro tyto spoje je používána převážně metalická kabeláž a preference metalické vs. optické kabeláže se v nejbližší době spíše měnit nebudou. Optické spoje jsou v současné době nasazovány pouze na páteřním vedení. Většina síťových spojů a aktivních síťových prvků je redundantní, takže v případě výpadku některého ze spojů či prvku nedojde k výpadku.

5.3

Software

Univerzita používá pro serverové nasazení několik operačních systému. Největší zastoupení však má OS Linux, který tvoří cca 80 %. Zbylých 20 % tvoří OS Microsoft Windows Server. Systémy společnosti Apple (OS X) univerzita v produkci nepoužívá. V případě linuxových distribucí je nasazován OS CentOS a Ubuntu Server. Operační systém Linux je poskytován zdarma, tudíž zde odpadají náklady na licence. U operačních systémů společnosti Microsoft se nakupují individuální licence pro jednotlivé systémy. U jednotlivých systémů se používají spíše „stable“ verze operačních systémů, což jsou verze, které jsou odladěné a mají minimum chyb. Aktualizace jsou z větší části instalovány ručně jednotlivými správci. Co se týče jednotlivých aplikací, ústav informačních technologií uvedl, že jednotlivé aplikace a služby jsou v současné době náročné zejména na diskový úložný prostor. Aplikace náročné na procesorové výpočty (aplikace pro fyzikální či chemické výpočty kapalin počítané procesorem) sice provozovány jsou, ale pouze na fakultních serverech v rámci nějakého projektu, které si spravují samotní fakultní správci. Grafické výpočty (CUDA výpočty, výpočty při kterých jsou používány stream procesory na grafických kartách) provozovány na serverech nejsou.

5.4

Virtualizování serverů

Univerzita již v současné době pro provoz serverů používá různá virtualizovaná řešení. Především se jedná o řešení VMware vSphere, KVM, Xen a oVirt. V provozu jsou aktuálně cca 4 clustery. Přičemž v případě velkého clusteru připadne na jeden hypervizor 50 virtuálních serverů. V případě malých clusterů jsou jednotlivé VM provozovány na lokálním diskovém úložišti. Naprostá většina virtuálních serverů se nachází v HA clusteru (High Availability, též vysoká dostupnost) clusteru. U virtuálních strojů, které se v HA clusteru nenachází, je převod do něj plánován. V současné době univerzita na virtualizované řešení nemá žádné specifické požadavky. V případě výběru mezi placenými a open source platformami vybírá na základě toho, co platforma umí, jaká je spolehlivost jednotlivých funkcí či jaké funkce která platforma přinese navíc. Rozhodující jsou i samotné finanční náklady na pořízení případných licencí a provoz.


5.5

34

Zajištění spolehlivosti

Celá univerzitní síť je spravována Ústavem informačních technologií. Většina sítě je spravována přes univerzitní informační systém. Servery jsou spravovány jednotlivými správci, popřípadě zástupci správců. Ústav informačních technologií (dále jen UIT) uvedl, že v současné době eviduje cca 75 % služeb jako mission critical. Při výpadku mission critical služeb by mohlo dojít k výraznému ovlivnění chodu fungování univerzity. Do kategorie mission critical spadá například univerzitní firewall, při jehož pádu by byl ochromen chod celé univerzitní sítě. Dále uvedl, že jednoznačně nelze určit, u kolika služeb může univerzita tolerovat výpadky ať už v minutách, nebo v hodinách. V současné době univerzita provozuje 20 % služeb v nevirtualizovaném prostředí (OS je instalován fyzicky na hardware serveru), 80 % služeb provozuje ve virtualizovaném prostředí. Téměř všechny služby ve virtualizovaném prostředí jsou provozovány v HA (High Availability) clusteru, u kterého se do budoucna počet služeb plánuje zvyšovat.

5.6

Shrnutí

Na základě provedené analýzy je patrné, že se na univerzitě nachází velice různorodé prostředí. To z hlediska hardwaru, který se průběžně dle dostupných finančních prostředků obměňuje, i z hlediska softwaru, kde jsou používány různé verze operačních systémů i celých virtualizačních platforem. Z hlediska dlouhodobého konceptu rozvoje je patrné, že by bylo vhodné v zájmu univerzity celou infrastrukturu sjednotit takovým způsobem, aby byla do budoucna rozšiřitelná, modulární a zbytečně nezatěžovala univerzitní rozpočet. Na základě analýzy stávajícího virtualizačního řešení univerzity vyplývá, že v případě výběru virtualizační platformy je důležité, aby uměla virtualizační platforma následující:  hostovat operační systémy Windows i Linux,  zvládala hostovat několik desítek virtuálních strojů (dáno i samotným HW),  umožňovala vytváření serverových clusterů,  zvládala funkce vysoké dostupnosti (High Availability),  aby měla podporu VLAN sítí,  zvládala nastavení teamingu/bondingu síťových karet (LACP, Active-Backup),  byla schopna provozu virtuálních strojů na iSCSI/NFS diskových polích,  byla schopna provozu na stávajícím hardwaru, který je v datových centrech provozován,  možnost ovladatelnosti přes SSH, GUI ovládání (web-management popřípadě externí aplikace)  byla pokud možno poskytována v základu jako freeware či open source. Ze strany UIT nebyly stanoveny ani požadovány žádné další specifické požadavky, které by platforma měla umět. Dle konzultace je hlavní prioritou použitelnost, spolehlivost.

Testovací metodika

35

6 Testovací metodika V slovníku cizích slov je uvedeno, že metodika je „nauka o metodě vyučování v určitém oboru, nauka o metodě vědecké práce; pracovní postup“ (Klimeš, 1998) Metodika by se tedy dala považovat za soubor postupů či činností, které jsou voleny na základě stanovených kritérií, která jsou většinou získána na základě analýzy požadavků. Pro srovnání jednotlivých virtualizačních platforem je zapotřebí jednotného testovacího scénáře, který bude pro všechny platformy společný, čímž docílíme objektivity výsledků provedených testů. Testovací metodiku můžeme rozdělit do několika skupin v závislosti na tom, co testujeme nebo hodnotíme. V našem případě do tří skupin, a to:  Finanční část,  implementační a provozní část,  testovací část.

6.1

Finanční část

V rámci finanční části testovací metodiky jsou hodnoceny finanční náklady, spojené s nasazením a následným provozem virtualizační platformy. Především se jedná o:  Cenu za licenci dané platformy a způsob licencování,  cenu za dokupování upgradů a aktualizací,  cenu technické podpory,  cenu normohodin zaměstnance a další náklady spojené s případným proškolením jednotlivých správců (školení).

6.2

Implementační a provozní část

V této části metodiky jsou hodnoceny implementační a provozní vlastnosti virtualizačních platforem.  Hodnocení časové náročnosti instalace,  hodnocení způsobů managementu,  dostupnost požadované funkcionality (živá migrace, vysoká dostupnost, atd.),  softwarové požadavky (například u VMwaru je potřeba vCenteru a k němu licence OS Windows Server, zatímco u platformy oVirt stačí Linux, který je zdarma.).

6.3

Testovací část

V rámci testovací části metodiky jsou porovnány jednotlivé platformy po výkonnostní stránce, kdy je napříč virtualizačními platformami srovnáván výkon kritických komponent. Primárně je tato část zaměřena na:  Test výkonu procesoru,

Testovací metodika

36

 test výkonu operační paměti,  test výkonu 2D grafické karty,  test rychlosti diskového pole (lokální disky, NAS),  test propustnosti síťové konektivity,  test rychlosti kopírování sady dat mezi virtuálními stroji,  výpadky síťové konektivity hosta, diskového pole, jednotlivých spojů a switche. Testování výkonu HW komponent je testováno pomocí benchmarkovacích aplikací k tomu určených. Výběr aplikací je velmi široký a pro testovací metodiku jsou zvoleny aplikace, které jsou nejčastěji používány v oborných recenzích a testech počítačových komponent, například testy na internetových portálech zive.cz, pctuning.cz, extrahardware.cz, nebo v tištěných publikacích, například časopisy Computer, Chip nebo Počítač pro každého. S mnoha aplikacemi se lze setkat i v jiných závěrečných bakalářských, diplomových či jiných pracích. Pomocí vybraných aplikací je provedeno celkem šest měření (testů) a z dosažených výsledků je vypočítána průměrná výsledná hodnota, která je následně porovnávána s výsledky jiných platforem. Šest měření je zvoleno proto, že v případě velkého výkyvu (nebo nesmyslných výsledků) naměřených hodnot zůstanou po vyřazení nejlepšího a nejhoršího výsledku stále 4 hodnoty, ze kterých lze vypočítat průměrný výsledek testu. Ve většině prací není buď počet měření uveden, nebo jsou provedena většinou tři měření. Měření je prováděno na virtuálním stroji s čistou instalaci OS Windows Server 2012 R2 s aktuálními aktualizacemi. Tomuto virtuálnímu stroji je přiděleno jedno procesorové jádro. Pro porovnání výkonu procesoru, paměti a disku jsou provedeny i testy se 4 přidělenými jádry procesoru. Dále jsou přiděleny 4 GB operační paměti RAM a 80 GB diskového prostoru. Každý z virtuálních strojů má přidělenu jednu virtuální síťovou kartu. V rámci objektivity výsledků je na hostovi v provozu pouze jeden virtuální stroj a to ten, na kterém jsou prováděny rychlostní testy s výjimkou testů síťové konektivity (propustnost sítě, kopírování dat mezi virtuálními stroji) a testů síťových výpadků. Předejde se tak situaci, kdy by výkon testované VM mohl být degradován jinou VM. První testy jsou provedeny až po pětiminutovém ustálení operačního systému, protože při náběhu operačního systému Windows se na pozadí načítají další služby, které by mohly test ovlivnit. OS Windows byl vybrán z důvodu mnohem širšího spektra benchmarkovacích aplikací. Kromě testování výkonnostních rozdílů jsou do porovnání také zařazeny testy síťových výpadků, pomocí kterých je otestováno, jak si jednotlivé platformy se síťovými výpadky poradí a zda zafungují funkce vysoké dostupnosti. V některých případech je třeba provést test v zátěži daného virtuálního stroje, proto bude zatížení virtuálního stroje provedeno pomocí aplikace AIDA64, která obsahuje nástroj pro plné vytížení procesoru, operační paměti i pevného disku. Co se týče nastavení jednotlivých VM či platforem, byly ponechány výchozí hodnoty (default) nastavení.

Testovací metodika

6.3.1

37

Testování výkonu procesoru

Cílem tohoto testu není otestovat výkon samotného procesoru ale srovnat výkonnostní rozdíly mezi jednotlivými platformami. Pro tento účel bylo vybíráno mezi aplikacemi SuperPI, MaxxPI, Prime Benchmark, PassMark, AIDA64 a WinRAR. Aplikace SuperPI je založena na jednovláknovém výpočtu čísla PI až na 32 milionů desetinných míst. Výsledkem jsou časové hodnoty, za jak dlouho bylo číslo vypočteno. Aplikace MaxxPI2 je založena na podobném principu jako předchozí aplikace. Výsledkem jsou časové hodnoty, za jak dlouho bylo číslo vypočteno a také bodové hodnocení. PrimeBenchmark je testovací program založený na hledání prvočísel. Samotný hrubý test trvá jednu minutu a výsledkem je bodové hodnocení výkonu procesoru. Výhodou je, že aplikace podporuje i multithreading (práci s více procesorovými vlákny). PassMark je jeden z komplexních testovacích nástrojů, který umí otestovat výkon hned několika komponent. V případě procesoru provádí několik testů z různých oblastí použití, například výkon v kompresi dat, výkon v šifrování, využití SSE instrukcí, rychlost řazení a podobně. Výsledná hodnota je uváděna v milionech operací za sekundu nebo rychlosti zpracovaných dat za sekundu. Záleží na typu testu. Krom výsledu jednotlivých testů je uvedeno také bodové score. AIDA64 je považována ze benchmarkovací i testovací nástroj. Dokáže zobrazit podrobné informace o konfiguraci daného počítače. Kromě informací je schopna provést testy výkonu komponent a kromě toho danou komponentu dokáže za účelem otestování stability vytížit. WinRAR je primárně komprimovací nástroj, který kromě komprimace či dekomprimace dat umožňuje také provést benchmark rychlostí zpracování. Pro testovací účely je nakonec vybrán nástroj PassMark, protože z uvedených nástrojů je nejkomplexnější a dokáže procesor otestovat hned v několika ohledech. Ostatní nástroje jsou zaměřeny pouze na jeden test, což nemusí mít v oblasti srovnávání vypovídající hodnotu. PassMark provádí testy procesoru v desíti kategoriích, mezi něž patří:  Celkové hodnocení v testu [v bodech],  operace s celými čísly [milion operací za sekundu],  operace s desetinnou čárkou [milion operací za sekundu],  operace s prvočísly [milion prvočísel za sekundu],  využití SSE instrukcí [milion matic za sekundu],  komprese [KB/s],  šifrování [MB/s],  práce s fyzickými výpočty (Physics) [FPS],  řazení [tisíc řetězců za sekundu],  a práce s jedním vláknem [milion operací za sekundu].

Testovací metodika

6.3.2

38

Testování výkonu operační paměti

Cílem testování výkonu operační paměti je zjistit výkonnostní rozdíly mezi jednotlivými platformami. Především jde o rozdíly výkonu čtení či zápisu dat v MB/s, dále pak samotná latence operační paměti. Pro tyto testy bylo vybíráno mezi aplikacemi AIDA64, MaxxMEM a PassMark. AIDA64 umí otestovat operační paměť z hlediska rychlosti čtení, zápisu a kopírování vzorku dat a samotné latence paměti. Zároveň umí otestovat i rychlost vyrovnávací paměti procesoru, tzv. cache. Výsledkem jsou rychlosti uvedené v MB/s, latence je uvedena v ns (nanosekundách) Aplikace MaxxMEM pracuje na obdobném principu jako AIDA64, měří rychlost operační paměti RAM v oblasti čtení, zápisu, kopírování a latence. Navíc také zobrazuje score paměti v MB/s a score latence. Benchmarkovacím programem PassMark je operační paměť otestována hned v několika testech. Výsledné hodnoty jsou uváděny v MB za sekundu, v počtu operací za sekundu nebo v nanosekundách. Test je dělen celkem do osmi kategorií:  Celkové hodnocení v testu [body],  test databázových operací [tisíc operací za sekundu],  test čtení s vyrovnávací pamětí [MB/s],  test čtení bez vyrovnávací paměti [MB/s],  zápis [MB/s],  celková dostupná kapacita RAM [dostupných MB],  latence paměti [ns],  a práce s vlákny [MB/s]. Pro testy operační paměti je nakonec vybrán testovací nástroj PassMark protože oproti ostatním nástrojům testuje operační paměť opět v několika ohledech a je to nejkomplexnější testovací nástroj. 6.3.3

Testování výkonu 2D grafické karty

V serverové oblasti nemá výkon grafické karty žádný zásadní význam. Servery obsahují integrovanou grafickou kartu v čipsetu základní desky, popřípadě u nových serverů v procesoru. Pokud se nejedná o server, který provádí náročné grafické výpočty (renderování) a neobsahuje výkonnější grafickou kartu, je integrovaná grafická karta používána pouze jako základní „zobrazovadlo“ a 3D benchmarkovací testy tak nemají žádný smysl. Pro úplnost však byl zařazen test 2D grafického výkonu pomocí aplikace PassMark, která testuje kartu v několika ohledech:  Celkové hodnocení grafického výkonu [body],  práce s jednoduchými vektory [tisíc vykreslených vektorů za sekundu],  práce s komplexními vektory [celkový počet vykreslených vektorů za sec.],  práce s textem [operací za sekundu],  simulace Windows rozhraní [operací za sekundu],  práce s filtry obrázků [filtrů za sekundu],  renderování obrazu [počet snímků za sekundu],  využití Direct2D [FPS].

Testovací metodika

6.3.4

39

Testování výkonu diskového pole.

Výkonnostní testy diskového pole je v oblasti serverové virtualizace jeden z nejdůležitějších testů, neboť jsou servery na práci s diskovými poli náročné. Pro testy diskového pole bylo vybíráno mezi aplikacemi Crystal Disk Mark, ATTO Disk Benchmark, AnvilBenchmark a PassMark. Crystal Disk Mark je poměrně známý testovací nástroj, který je schopen otestovat výkon jakéhokoliv úložiště v oblasti sekvenčního a náhodného čtení i zápisu. Aplikace umožňuje volit testovací sadu o velikosti 50 MB, 100 MB, 500 MB, 1 GB, 2 GB, 4 GB, 8 GB, 16 GB a 32 GB dat. Kromě velikosti dat je možné také volit počet opakování testu, přičemž je do výsledku započtena vždy nejvyšší dosažená rychlost. ATTO Disk Benchmark je také známá testovací aplikace umožňující měřit výkon disků včetně RAIDových polí. Testy této aplikace jsou primárně zaměřeny na přenos malých souboru s velikostí od 512 B do 64 MB. AIDA64 je sice placený benchmarkovací nástroj, lze jej ale použít jako 30 denní trial verzi. Umožňuje testování několika komponent. V případě pevného disku je testování založeno na měření rychlosti čtení, náhodného čtení, lineárního čtení a čtení s využitím vyrovnávacího bufferu. Aplikace PassMark je schopna změřit výkon disku v rychlosti sekvenčního čtení, sekvenčního zápisu a náhodného čtení v MB/s. Ze zmíněných aplikací je nakonec vybrán nástroj PassMark, který kromě rychlostí čtení a zápisu zobrazí i celkové hodnocení disku. V rámci testů rychlostí disku je otestován:  Výkon virtuálního disku umístěného na NAS při 1 vCPU,  výkon virtuálního disku umístěného na NAS při 4 vCPU,  výkon virtuálního disku umístěného na lokálním úložišti daného hypervizoru při 1 vCPU,  výkon virtuálního disku umístěného na lokálním úložišti daného hypervizoru při 4 vCPU. Co se týče nastavení samotných disků a pole, v případě testů na lokálním hostovi běží pevný disk v režimu AHCI bez RAID pole, neboť server disponuje pouze jedním 500 GB diskem. V případě NAS diskového pole jsou použity čtyři pevné disky s rozhraním SATA zapojené v RAID poli 5 a k hostům jsou připojeny přes iSCSI rozhraní. 6.3.5

Testování propustnosti sítě mezi VM

V serverové sféře jsou také důležité rychlosti sítové konektivity, neboť pro většinu síťových služeb je rychlá síť nezbytně nutná. Vzhledem k tomu, že servery disponují 1 Gbps porty lze předpokládat, že síť rychlejší než rychlost samotných portů nebude. Cílem testování je však změřit výkonnostní rozdíly mezi platformami. Pro testování výkonu síťové konektivity bylo vybíráno mezi nástroji LAN SpeedTest Lite, iPerf, NetIO GUI a PassMark, které se pro tento účel jeví jako schopné nástroje. Podmínkou pro zachování objektivity testů je, aby všechny použité prvky, na kte-

Testovací metodika

40

rých jsou testy prováděny, zvládaly rychlost sítě 1 Gbps. V případě použití nějakého prvku s nižší rychlostí by testy postrádaly smysl. LAN SpeedTest Lite je nástroj, který umí otestovat rychlost sítě v Mbps při kopírování souboru na jiné úložiště v síti. Výsledkem jsou hodnoty rychlosti sítě pro čtení a zápis uvedení v bytech za sekundu, bitech za sekundu a Mbps. Aplikace NetIO GUI je klient-server benchmarkovací nástroj. V případě testování rychlosti konektivity mezi dvěma zařízeními běží tato aplikace na jednom z nich v režimu klienta, na druhém zařízení v režimu serveru. Měří rychlost komunikace v KB/s. iPerf je konzolový nástroj poskytovaný zdarma, kterým můžeme také změřit rychlost sítě pomocí datových toků. Podobně jako přechozí aplikace běží v režimu klient-server. Výhodou je, že existuje jak pro linuxové operační systémy, tak i pro operační systém Windows. Grafickou alternativou je nástroj jPerf, který právě z iPerf vychází, iPerf je jeho jádrem. Tento nástroj umožňuje změřit propustnost sítě v daném časovém intervalu. Pro otestování propustnosti sítě je nakonec vybrána aplikace iPerf, protože je schopna testovat maximální rychlost sítě, ztrátovost packetů a více paralelních streamů přenosu, běží jak na OS Windows, tak na OS Linux a používá se běžně k testování v případě řešení problémů na síti. Pro otestování propustnosti síťové konektivity byl vytvořen script, který cyklicky 6x změří pomocí aplikace iperf propustnost sítě po dobu 300 sekund a mezi každým testem nechá prodlevu po dobu 10 sekund z důvodu ukončení a navázání spojení. Při testu po dobu 300 sekund získáme dlouhodobý průměr výsledků. echo Zadej nazev souboru: set /p name= FOR /L %%A IN (1,1,6) DO ( echo Prave probiha test c.%%A, prosim vyckejte. iperf3.exe -c 192.168.100.101 -t 300 > %name%_%%A.txt echo Test c.%%A ukoncen a vysledek ulozen do logu. timeout 10 )

Otestováno bylo celkem 8 možných kombinací, které mohou při komunikaci mezi dvěma virtuálními servery nastat. Scénáře jsou identické s testováním rychlosti kopírování dat, viz obrázek 6 na straně 42. 6.3.6

Testování rychlosti sítě v oblasti kopírování sady dat

Kromě využití benchmarkovacích nástrojů budou také provedeny testy kopírování dat mezi virtuálními stroji, kde bude měřena rychlost přenosu malých a velkých souborů mezi virtuálními disky. Tento test je do testovací metodiky zařazen proto, že kopírováním souborů do procesu kopírování vstupují i procesy nad souboro-

Testovací metodika

41

vým systémem, tudíž se neměří pouze dlouhodobý datový tok, ale i celková rychlost a odezva systému. Pro tyto účely byly vytvořeny dvě sady souborů. Jedna sada obsahuje 3 ISO obrazy operačních systémů o celkové kapacitě 13 GB. Druhá sada obsahuje směs MP3 písniček, fotek a dokumentů o celkové velikosti 12,9 GB. První sadou lze simulovat například přenos nějakých záloh, druhou sadou lze simulovat například kopírování nějakých souborů studentů. Sady souborů o velikostech 12,9 a 13 GB byly voleny proto, že při větších objemech dat lze lépe rozpoznat jednotlivé rozdíly v rychlostech kopírování lépe, nežli tomu je kopírování malého objemu dat, kde by mohly být výsledky hodně podobné. Tento test je proveden pomocí vlastního scriptu, který pomocí Windows utility XCOPY zkopíruje data z jedné VM do sdílené složky druhé VM a současně zaeviduje start a konec kopírování. Na základě rozdílu těchto dvou časů je následně vypočtena celková doba nutná ke zkopírování těchto dat. Vzhledem k tomu, že XCOPY je pomalejší, je to testování zařazen ještě jeden identický test pomocí aplikace FastCopy. for /l %%x in (1,1,6) do ( mkdir Z:\Sada1_%%x echo Zacatek testu velkych souboru c.%%x: >> log.txt call time.bat xcopy /E C:\SHARED\Sada1 Z:\Sada1_%%x echo Konec testu c.%%x: >> log.txt call time.bat rmdir /Q /S Z:\Sada1_%%x echo. >> log.txt mkdir Z:\Sada2_%%x echo Zacatek testu malych souboru c.%%x: >> log.txt call time.bat xcopy /E C:\SHARED\Sada2 Z:\Sada2_%%x echo Konec testu c.%%x: >> log.txt call time.bat rmdir /Q /S Z:\Sada2_%%x echo. >> log.txt )

Protože však výpis času v cyklu z neznámých důvodů zobrazoval vždy stejný čas jak na začátku, tak i na konci testu. Musel být nakonec vytvořen ještě jeden nový .bat soubor vypisující aktuální čas pomocí echo %time%, který je ve výše uvedeném scriptu v potřebnou chvíli zavolán pomocí call time.bat Následující obrázek zachycuje testované varianty. Červeně je vyznačena vazba mezi virtuálním strojem a jeho virtuálním diskem, zeleně pak tok testovacích dat.

Testovací metodika Obr. 6

Varianty testovacích scénářů propustnosti sítě a kopírování dat mezi VM

6.3.7

Testování výpadků síťové konektivity

42

V reálném provozu se často můžeme setkat se síťovými výpadky, které mohou být způsobeny buď chybou lidského faktoru, závadou hardwaru nebo chybou v softwaru. V této kapitole je cílem zjistit, jak si jednotlivé virtualizační platformy se síťovými výpadky poradí, která z technologií je schopna se vrátit do konzistentního stavu, pokud možno za co nejkratší čas a za jakých podmínek. Cílem tedy je otestovat:  Zda je platforma schopna detekovat výpadek v síti,  zda zafungují ochranné funkce vysoké dostupnosti,  zda je platforma schopna se uvést zpět do konzistentního stavu, kdy jsou všechny její prvky opět aktivní. Výpadky sítě budou simulovány na L3 switchi, na kterém pomocí scriptu budou v určitý okamžik shazovány a nahazovány definované porty, do kterých jsou zapojena zařízení, na kterých je výpadek simulován. Pro jednotlivé testy byly vybrány dva časové intervaly výpadku v podobě 5 sekund, pomocí kterého lze simulovat například vypojení a opětovné zapojení síťového kabelu a 60 sekund, kdy by měly zafungovat funkce vysoké dostupnosti (HA).

Testovací metodika

43

L3 switch Juniper umožňuje provést blokaci portů dvěma způsoby. Jedním z nich je přímo změna konfigurace switche. To je ale nevýhodné, protože každá změna se musí potvrdit (pomocí commit) a mezi potvrzením a aplikací daného nastavení je prodleva v řádu několika sekund, která navíc nemusí být stejná. Druhou možností je využití linuxového shell režimu, který Juniper nabízí, a při kterém je možné používat linuxové příkazy, při kterých lze porty shazovat téměř okamžitě. Následující obrázek znázorňuje typy síťových výpadků. Obr. 7

6.4

Typy síťových výpadků

Testovací prostředí

V rámci této diplomové práce jsou jednotlivé platformy testovány v univerzitní laboratoři, kde je pro ně vytvořena separátní síťová infrastruktura, která je oddělena od univerzitní produkční sítě. Svojí strukturou bude odpovídat reálné topologii bez redundance, která je pro ostrý provoz obvyklá. 6.4.1

Testovací hardware

Pro testovací účely byl univerzitou zapůjčen starší serverový hardware, který již není v ostré produkci. Především se jedná o:  Jeden router Mikrotik,  Jeden 1 Gbps L3 switch Juniper EX2200,  tři 1U servery SUN SunFire 2200, plnící funkci hostů, jeden z nich bude plnit funkci management serveru (například vCenter),

Testovací metodika

44

 dvě NAS disková pole, na kterých budou uloženy virtuální disky jednotlivých virtuálních strojů. Dva servery SUN disponují dvěma procesory AMD Opteron, kde každý z procesorů má 4 fyzická jádra a nepodporuje Hyperthreading. Celkem tedy servery zvládnou zpracovat až 8 vláken. Dále je k dispozici 16 GB operační paměti RAM DDR2 s podporou opravy jednobitových chyb (ECC). Úložný prostor serverů má kapacitu 500 GB a jsou použity serverové pevné disky WD Enterprise Storage v provedení SATA3. Pro připojení k síti LAN servery obsahují čtyři 1 Gbps síťové karty. Třetí server je sice modelově stejný, ale starší revize a mírně se liší parametry. Disponuje dvěma procesory AMD Opteron, kde každý procesor má jen 2 fyzická jádra a nepodporuje funkci Hyperthreading. Server tak je schopen zpracovat až 4 vlákna. K dispozici je dále 20 GB operační paměti RAM DDR2 s podporou opravy jednobitových chyb (ECC). Úložný prostor serverů má kapacitu 250 GB a jsou použit pevné disky Hitachi v provedení SATA3. Pro připojení k síti LAN servery obsahují čtyři 1 Gbps síťové karty. Dále jsou použita dvě disková pole Synology DS412+, disponující čtyřmi hotswap pozicemi pro pevné disky. Každé z polí obsahuje čtyři 1 TB disky WD Red, což jsou disky určené přímo do NAS diskových polí. Pole umožňuje několik režimů pole RAID, je však nastaven režim RAID 5. Dále jsou k dispozici dvě 1 Gbps síťová rozhraní. V následujících tabulkách jsou uvedeny klíčové parametry jednotlivých použitých prvků. Tab. 2

Výpis parametrů serveru 1

Server 1 a 2 Model SUN SunFire X2200 Procesor 1 AMD Opteron 2354 @ 2.2 GHz, 4 jádra, 4 vlákna Procesor 2 AMD Opteron 2354 @ 2.2 GHz, 4 jádra, 4 vlákna Operační paměť 16 GB RAM DDR2 ECC Pevný disk 500 GB HDD WD RE4 SATA3 (Hotswap) Grafická karta integrovaná Síťová karta 2x 1 Gbit Broadcom, 2x 1 Gbit nVidia

Testovací metodika Tab. 3

45

Výpis parametrů serveru 3

Server 3 Model SUN SunFire X2200 Procesor 1 AMD Opteron 2200 @ 2.8 GHz, 2 jádra, 2 vlákna Procesor 2 AMD Opteron 2200 @ 2.8 GHz, 2 jádra, 2 vlákna Operační paměť 20 GB RAM DDR2 ECC Pevný disk 250 GB HDD Hitachi SATA3 (Hotswap) Grafická karta integrovaná Síťová karta 2x 1 Gbit Broadcom, 2x 1 Gbit nVidia Tab. 4

Výpis parametrů diskového pole NAS

Model Konektivita

Pevné disky RAID Pole Tab. 5

Diskové pole NAS Synology DS412+ 2x 1 Gbit porty 2x USB 3.0 1x eSATA 4x Western Digital RED 1 TB, WD10EFRX 0, 1, 5, 6, 10 (1+0)

Výpis parametrů síťových prvků

Síťové prvky Model L3 switch Juniper EX2200 Router Mikrotik 6.4.2

Parametry 24x 1 Gbps LAN 5x 100 Mbps LAN

Testovací síťová infrastruktura

Jednotlivé testy nelze provádět v produkční síti, protože by to mohlo ohrozit provoz celé univerzitní sítě. Proto je v síťové laboratoři vytvořena zjednodušená síťová infrastruktura, která částečně odpovídá reálnému nasazení a lze tedy na ní provádět testy bez rizika ohrožení reálného provozu. Vzhledem k tomu, že cílem této práce není testování redundance sítě, ale testování virtualizačních platforem, nebyla redundance v experimentální síti aplikována.

Testovací metodika

Obr. 8

Testovací infrastruktura – L2

Obr. 9

Testovací infrastruktura – L3

46


47

7 Výběr technologií pro testování Vzhledem k popsaným potřebám univerzity, které vyplývají na základě analýzy a konzultace s UIT, není potřeba se zaobírat kontejnerovou virtualizací, virtualizací na úrovni operačního systému a emulací. Existuje několik desítek virtualizačních platforem, které si navzájem snaží konkurovat. Některé jsou poskytovány jako placené řešení (typicky známý VMware ESXi) nebo jako open source (například KVM). Některé z platforem jsou však poskytovány jako placené i jako volně dostupné. Placená a neplacená verze se mnohdy mezi sebou liší například jistým omezením funkcionality, hardwarovým omezením nebo dostupnosti podpory. Univerzita v současné době používá pro virtualizaci serverů placené řešení virtualizačních platforem (VMware) i open source řešení virtualizace (Xen, KVM). Mezi několik nejznámějších platforem, se kterými se lze často setkat patří (abecedně):  Citrix XenServer,  KVM,  Microsoft Hyper-V,  OpenStack,  oVirt,  Parallels Virtuozzo,  Promox,  Redhat Enterprise Virtualization (RHEV),  VMware vSphere (ESXi). Většina z virtualizačních platforem se neustále vyvíjí a každá další nová vydaná verze většinou přinese nějaké nové funkce či další vylepšení navíc. Při průzkumu internetu můžeme narazit na několik portálů, které přináší pomyslné žebříčky nejlepších virtualizačních technologií. Jedním z příkladů jsou například portály virtualizationsoftware.com a serverwatch.com. V následující tabulce je uvedeno TOP 5 virtualizačních platforem z roku 2013. Tab. 6

TOP 5 virtualizačních platforem

Pořadí 1. 2. 3. 4. 5.

Virtualizační platforma VMware Microsoft Hyper-V Xen / Citrix XenServer Redhat Enterprise Virtualization (RHEV) KVM

Zdroj: virtualizationsoftware.com, online

Jak je z výše uvedené tabulky patrné, na prvních příčkách se umístily komerční platformy VMware, Microsoft Hyper-V a XenServer, které jsou poskytovány za jistých podmínek (různá HW a SW omezení) i zdarma. V tabulce č. 7 je zobrazeno


48

TOP 10 společností poskytující virtualizační řešení pro rok 2016. Při porovnání obou žebříčků je patrné, že se žebříček oproti roku 2013 téměř nezměnil a první příčky zůstaly identické. Tab. 7

TOP 10 společností poskytující virtualizační platformy pro rok 2016

Pořadí 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Virtualizační platforma VMware (vSphere, ESXi) Microsoft (Hyper-V) Citrix (XenServer) Redhat (RHEV, oVirt) Oracle (OracleVirtualization) Amazon (EC2, Elastic Compute Cloud) Google (Google Ganeti) Parallels / Odin (OpenVZ) Huawei (FusionSphere) Verde VDI (Nimboxx Acquired)

Zdroj: serverwatch.com, 2016, online

Vzhledem k tabulkám č. 6 a 7 (TOP 5 a TOP 10 společností…) již výběr nejlepších variant virtualizačních technologií není nutné provádět, protože ji autoři výše uvedených webových portálů provedli za nás. Co je však nutné provést, je výběr vhodných platforem z uvedeného TOP 10/TOP 5 listu na základě požadavků daných UIT. Z tohoto výběru můžeme již na začátku vyřadit všechny zástupce kontejnerových virtualizací a cloudové poskytovatele virtuálních strojů, protože univerzita potřebuje mít data na svém území, nebo v zájmu CESNET sítě. Zůstanou nám tedy technologie VMware ESXi, Microsoft Hyper-V, Citrix XenServer a Redhat oVirt (RHEV). Z těchto technologií můžeme vyřadit i virtualizační platformu Microsoft Hyper-V, neboť má omezenou podporu Linuxových distribucí. K provozu Linuxové distribuce v rámci VM vyžaduje instalaci dodatečných integračních služeb (známe jako Integration Components, dále jako IC). Jestliže není Linuxová distribuce podporovaná a není pro ni IC dostupný, pak většina zařízení virtuálního stroje je emulována, což způsobuje značnou degradaci výkonu VM (Hlaváč, 2014, DP), (technet.microsoft.com, 2016, online) Další nežádoucí vlastností je, že v případě HyperV Serveru, který je poskytovaný zdarma, probíhá jeho správa pouze přes Power Shell nebo přes placené aplikace společnosti Microsoft MSCVMM (Microsoft System Center Virtual Machine Manager) a aplikace třetích stran, u kterých nemusí být zajištěna plná kompatibilita. Pokud by univerzitní správci chtěli platformu Hyper-V spravovat přes grafické rozhraní, obnášelo by to navíc i nákup licence pro operační systém Windows Server 2012 R2. U VMware ESXi pro vCenter je sice rovněž potřeba licence pro Windows server 2012 R2, na rozdíl od Hyper-V však VMware nabízí lepší možnosti správy zdarma, web management a mnohem větší nabídku linuxových i BSD distribucí.


49

V tomto okamžiku můžeme hovořit pouze o 3 vhodných virtualizačních technologiích, které lze použít k otestování, tedy o VMware vSphere, Citrix XenServer a Red Hat oVirt. V tabulce č. 8 je uveden výčet funkcí platforem z hlediska potřeb univerzity. Tab. 8

Porovnání funkcionality vybraných platforem na základě požadavků ÚIT.

Vhodná pro serverové nasazení open source Je ve vývoji? Typ virtualizace Platforma Podpora virtualizačních instrukcí Intel VT-X a AMD-V Podpora OS Windows / Linux Dostupnost ovladačů pro VM

Nástroje pro správu

Možnost provozu v clusteru Funkce vysoké dostupnosti (HA) Možnost migrace VM Možnost migrace storage Možnost VLAN sítí Podpora NIC teamingu, LACP Podpora Snapshotů

7.1

VMware vSphere 6 Standard

XenServer 7 free

oVirt 4.0

ANO

ANO

ANO

NE ANO bare-metal x86 / x64

ANO ANO bare-metal x86 / x64

ANO ANO hostovaná x86 / x64

ANO

ANO

ANO

ANO/ANO

ANO/ANO

ANO/ANO Guest agent a VirtIO drivers

web management, SSH, vCenter, aplikace třetích stran ANO

XenServer Tools XenOrchestra (placený), XenCenter, SSH, aplikace třetích stran ANO

ANO

ANO

ANO

ANO ANO ANO

ANO ANO ANO

ANO ANO ANO

ANO

ANO

ANO

ANO

ANO

ANO

VMware Tools

web management, SSH, aplikace třetích stran ANO

VMware vSphere

Jednou z nejstarších společností, která se zabývá virtualizacemi je společnost VMware, která byla založena v roce 1998 a v současné době je lídrem na trhu s virtualizačním řešením. Nabízí široké spektrum produktů různých odvětví virtua-


50

lizace, mezi něž patří například VMware Workstation, VMware ESXi, VMware Horizon a spousta dalších produktů (Kos, 2015, BP) V oblasti serverové virtualizace je nejznámější technologie VMware vSphere. Ta je založena na hypervizoru ESX, který zajištuje správu přidělovaných zdrojů včetně vCPU, vRAM, ukládání dat a síťových zdrojů. (Kyšová, 2013, DP) Celá platforma vSphere je složena ze dvou základní částí, z hypervizoru ESXi nainstalovaného přímo na fyzický hardware, který je pro virtualizaci optimalizován a vCenteru serveru, který celou platformu řídí a přes který je spravována. Součástí je i vSphere Client, pomocí kterého lze hypervizor ESXi a vCenter spravovat. V současné době je nejnovější verzí VMware vSphere verze 6.0. VMware vSphere je placenou virtualizační platformou, která existuje v několika edicích, které se mezi sebou liší dostupnými funkcemi. V současné době jsou k dispozici placené edice VMware vSphere Standard, vSphere Enterprise Plus a vSphere with Operation Management Enterprise Plus. Ke každé edici je navíc třeba zakoupit vCenter Server, který je prodáván jako separátní produkt. Společnost VMware však nabízí samotný hypervizor ESXi zdarma, ten je však funkčně omezen, umožní virtuálnímu stroji přidělit maximálně 8 vCPU.

Obr. 10

7.2

Architektura virtualizační platformy VMware (Trenton Systems Inc., 2010, online)

Citrix XenServer

XenSever je enteprise virtualizační platforma založená na XenProject hypervizoru, který se řadí mezi bare-metal virtualizační platformy. Platforma je určená pro nasazení na serverech v datových centrech. Je to open source projekt spravovaný společností Citrix. První zmínky o této společnosti se datují k roku 2003, většího významu však tato společnost nabrala až v roce 2007, kdy dokončila akvizici firmy XenSource. Tato platforma běží na modifikovaném operačním systému CentOS. Celý projekt je složený z několika stovek komponent, které jsou na zakázku vytvořeny speciálně pro XenServer. (Hinkle, 2013, online) V současné době společnost Citrix nabízí několik možností virtualizačních řešení, mezi něž patří například serverová virtualizace XenServer, virtualizace aplikací XenAPP nebo desktopová virtu-


51

alizace XenDesktop. (Hinkle, 2013, online) Aktuální verze, která byla vydaná je Citrix XenServer 7.0. Platforma Citrix XenServer je složena z hypervizoru XenServer a management konzole XenCenter, která se instaluje jako aplikace na jakýkoliv PC s OS Windows. Hypervizor se instaluje na fyzický hardware (podobně jako platforma VMware). Citrix XenServer je primárně placenou virtualizační platformou, která je poskytována i jako open source projekt zdarma. Rozdíl mezi placenou a neplacenou distribucí je v poskytované podpoře, která u neplacené verze chybí. V případě placené verze jsou nabízeny dvě edice, a to Standard Edition a Enterprise Edition. Mezi těmito verzemi jsou drobné rozdíly ve funkcionalitě (například chybějící workload balancing, možnost virtualizace grafické karty), základ je však stejný.

Obr. 11 online)

7.3

Architektura virtualizační platformy XenServer (Precedence Technologies Ltd, 2016,

oVirt

oVirt je open source virtualizační platforma, která postavena na virtualizační platformě KVM a vychází z komerční distribuce společnosti Red Hat, Red Hat Enterprise Virtualization (dále jako RHEV). Rozdíl mezi dvěma zmiňovanými platformami je ten, že RHEV je placenou platformou a společnost Red Hat k ní nabízí placenou podporu, která není volně přístupná. (Salák, 2016, DP). Základem této platformy je operační systém Linux, do kterého se tato platforma instaluje pomocí balíčků. Základem je oVirtu je řídící server zvaný engine a hypervizor, známý též jako node. Ačkoliv je oVirt poskytovaný jako open source, nabízí spoustu funkcí již v základu. Mezi tyto funkce patří především high availability, možnost správy serverů v clusteru, možnost spolupráce s VLAN sítěmi, ovladatelnost přes webové rozhraní, případně přes SSH. Dalšími vlastnostmi je možnost spolupráce s diskovými poli přes iSCSI či NFS. Hlavní odlišností od ostatních platforem je i souborový systém GlusterFS. (Salák, 2016, DP).


52

Virtualizační platforma RHEV (RedHat Enterprise Virtualization) je placenou edicí, kterou vyvíjí společnost RedHat. U této distribuce je poskytována buď základní podpora (Standard support) nebo prémiová podpora (Premium Support). Edice oVirt, která z RHEV vychází je spravována komunitou a není k ní poskytována žádná podpora, existuje však k ní dokumentace a různé komunity na internetu.

Obr. 12

Architektura virtualizační platformy oVirt (oVirt, 2016c, online)

Obr. 13

Architektura KVM, které je součásti platformy oVirt (Brendan Gregg, 2013, online)


53

8 Náklady na pořízení a údržbu platformy Nasazování virtualizační platformy do provozu s sebou také nese určité investice do nákupu licencí, které jsou potřeba jednak pro provoz celé virtualizační platformy, i pro provoz samotných hostů. Převedení existujících serverů do virtualizačního řešení však s sebou nepřináší úsporu licencí, jak by se mohlo zdát. Pro jednotlivé virtuální stroje je třeba vlastnit licenci stejně tak, jako by byly provozovány na fyzickém stroji. V případě open source řešení však lze danou infrastrukturu provozovat i zdarma, pomineme-li režijní náklady na provoz. (Kopl, 2013, BP)

8.1

VMware

Platforma VMware vSphere 6 je primárně placenou platformou, která je poskytovaná ve třech základních edicích, které se mezi sebou liší jednotlivými funkcemi a účelem použití. Hypervizor platformy VMware vSphere je licencovaný formou jedné licence na jeden fyzický procesor, přičemž je jedno, kolik má procesor jader či vláken. V případě dvouprocesorového serveru je tedy potřeba zakoupit dvě licence hypervizoru. Kromě licencí hypervizoru je také potřeba zakoupit licenci pro vCenter Server, ke kterému se dokupuje licence zvlášť. Jednotlivé ceny licencí se liší v závislosti na edici dané platformy a na tom, jestli jsou zakoupeny jako komerční nebo akademická licence. Licence mohou být poskytovány i za individuální ceny, to za předpokladu, jsou-li nakupovány v rámci nějakého výběrového řízení. V následujících tabulkách č. 9 a 10 jsou uvedeny licencí hypervizoru a vCenter Serveru, které jsou uváděny jako ceny doporučené, dále pak ceny společnosti Senetic s.r.o., která poskytuje i akademické licence. Tab. 9

Ceník hypervizoru platformy VMware vSphere 6

Edice VMware vSphere Standard (per CPU) VMware vSphere Enterprise Plus (per CPU) VMware vSphere with Operation Management Enterprise Plus (per CPU)

Doporučené ceny

Senetic Koncový Akademická zákazník licence

939,50 €

28 879,00 Kč

17 321,00 Kč

3 305,00 €

101 590,00 Kč

61 015,00 Kč

4 155,00 €

125 000,00 Kč

75 061,00 Kč

Zdroj: Senetic, 2016, online; VMware, 2016, online

Náklady na pořízení a údržbu platformy Tab. 10

54

Ceník vCenter Serveru platformy VMware vSphere 6

Senetic Koncový Akademická zákazník licence

Doporučené ceny

Edice vCenter Standard for vSphere 6 (per instance) vCenter Foundation for vSphere 6 (per instance)

8 430,26 €

174 132,00 Kč

104 356,00 Kč

2 373,49 €

43 495,00 Kč

26 051,00 Kč

Zdroj: Senetic, 2016, online; VMware, 2016, online

V případě, že je třeba založit úplně novou virtualizační infrastrukturu, společnost VMware nabízí i jednotlivé balíčky, které v základu obsahují 6 procesorových licencí (vhodné například pro 3 hosty o dvou CPU) a jednu licenci pro vCenter Server. Tyto balíčky by měly být obecně cenově výhodnější. V tabulce č. 11 jsou uvedeny ceny podpory, kterou je u platformy VMware vyžadováno zakoupit. Tab. 11

Ceník podpory platformy VMware vSphere 6

Koncový zákazník Základní Rozšířená

Univerzitní licence Základní Rozšířená

1

8 091,00 Kč

9 574,00 Kč

3 705,00 Kč

9 574,00 Kč

3

21 361,00 Kč

25 273,00 Kč

9 782,00 Kč

25 273,00 Kč

1

17 980,00 Kč

25 905,00 Kč

13 041,00 Kč

25 905,00 Kč

3

57 433,00 Kč

68 387,00 Kč

34 428,00 Kč

68 387,00 Kč

1

37 314,00 Kč

44 420,00 Kč

22 389,00 Kč

44 420,00 Kč

3

98 507,00 Kč 117 270,00 Kč

59 105,00 Kč

117 270,00 Kč

Edice

doba

Basic Support VMware vSphere 6 Standard Basic Support VMware vSphere 6 Enterprise Plus Basic Support VMware vCenter Server 6 Standard

Zdroj: Senetic, 2016, online

K této virtualizační platformě je vyžadováno zakoupení placené podpory (support) v délce trvání minimálně 1 rok. Cena podpory se liší v závislosti na edici platformy, ke které ji chceme zakoupit a v závislosti na tom, jestli je kupovaná pro hypervizory nebo vCenter Server. Podporu je možné zakoupit ke všem nabízeným edicím a to na dobu 2 měsíců, 1 nebo 3 let. K dispozici je možnost používat zdarma i samotný hypervizor ESXi, který má však jedno omezení, umožní virtuálním serverům přidělit maximálně 8 virtuálních jader, samozřejmě lze tento hypervizor provozovat i samostatně bez vCenter Serveru, přijdeme tím ale tak o možnost vysoké dostupnosti a jiné funkce které jsou dostupné pouze v clusteru. Toto řešení je vhodné pro lokální nasazení bez redundance a funkcí vysoké dostupnosti. Kromě samotné licence pro virtualizační platformu VMware je také nezbytné zakoupit jednu licenci pro operační systém Windows Server 2012 R2 Standard,


55

který je potřebný jako základní systém pro provozování vCenteru Serveru. Cena licence za tento operační systém se pohybuje v rozmezí 18.000 – 23.000 korun. Levnější licence jsou určeny většinou přímo pro určitou značku serveru (například DELL). Univerzální licence tohoto systému vychází na 23.000 korun včetně DPH (pro 2 CPU). (TSBohemia a.s., 2016, online)

8.2

XenServer

XenServer je poskytovaný v základu ve dvou placených edicích (Standard a Enterprise) a jedné edici zdarma jako open source. V případě placeného řešení je způsob licencování této platformy stejný jako u konkurenčního VMwaru, je nutno zakoupit jednu licenci na jeden fyzický procesor. Rozdíl mezi oběma edicemi je minimální, edice Enterprise přináší navíc možnost vyvažování zátěže (Work Load Balancing), možnost instalace ovladačů operačních systémů Windows přes Windows update a možnost virtualizace grafické karty vGPU. Edice XenServeru, která je poskytována zdarma je identická s edicí Standard, pouze k ní není poskytována žádná podpora. V tabulce č. 12 je uveden ceník platformy XenServer zveřejněný společností Citrix Systems, Inc. Tab. 12

Ceník platformy XenServer

Edice XenServer 7.0 Standard Edition - OnPremises Subscription License per CPU Socket, with 1 year Software Maintenance XenServer 7.0 Standard Edition Perpetual License per CPU Socket, with 1 year Software Maintenance XenServer 7.0 Enterprise Edition - OnPremises Subscription License per CPU Socket, with 1 year Software Maintenance XenServer 7.0 Enterprise Edition Perpetual License per CPU Socket, with 1 year Software Maintenance XenServer Free (no support, no warranty)

Cena

Poznámka

$345.00

8 829,00 Kč

$763.00

19 527,00 Kč

$695.00

17 787,00 Kč

$1,525.00

39 029,00 Kč

$0,00.00

0,00 Kč

Zdroj: Citrix Systems, Inc., 2016 Online

Během zakoupení licence pro tuto platformu je možnost volby dočasné licence na jeden rok (On-Premises) nebo trvalé licence (Perpetual), přičemž k zakoupené licenci je poskytována podpora po dobu 1 nebo 3 let a liší se i svojí cenou.


8.3

56

oVirt

Tato virtualizační platforma je odvozena od komerční virtualizační platformy RedHat Enterprise Virtualization (RHEV) společnosti RedHat, která je platformou placenou. V případě RHEV existuje jedna edice, ke které je poskytována standardní, nebo rozšířená podpora po dobu 1 nebo 3 let. Samotná virtualizační platforma oVirt, která z RHEV vychází a je tak spravována komunitou je poskytována jako open source zdarma bez jakékoliv podpory a nejsou potřeba žádné dodatečné náklady kromě zaplacení normohodin zaměstnance, který platformu nasazuje a nákup samotného hardwaru, na kterém bude platforma provozována. Tab. 13

Ceník platformy RHEV a oVirt

Cena

Poznámka

Red Hat Virtualization (2-sockets), Premium + 1y support

$1498.00

38 675,00 Kč

Red Hat Virtualization (2-sockets), Standard + 1y support

$998.00

25 766,00 Kč

$0.00

0,00 Kč

Edice

oVirt Zdroj: RedHat Inc., 2016, online

Nasazení platformy

57

9 Nasazení platformy 9.1

VMware

Celá infrastruktura platformy VMware vSphere 6 je složena celkem z 2 základních prvků, mezi něž patří hypervizory ESXi, vCenter Server a pak aplikace vSphere klient pro správu. Každá ze součástí se instaluje samostatně. Nasazení celé platformy trvalo celkem přes 3 hodiny (cca 187 minut) včetně instalace OS Windows Server 2012 R2 i s aktualizacemi. V případě, budeme-li mít již připravený server s OS Windows Server, měli bychom se se základní instalací infrastruktury vejít do 60 - 90 minut. Do tohoto času není započítáno vytvoření clusteru, připojení diskových polí, vytvoření virtuálních strojů a další případná nastavení. Pokud do času instalace započítáme i dobu nastavení infrastruktury, měli bychom se na použitém testovacím hardwaru vejít do 4 hodin. Nasazení celé platformy se obešlo bez větších problémů. Doba instalace se však může v závislosti na výkonu HW a sítě lišit. Na webových stránkách produktu VMware je v sekci podpory k nalezení kompletní instalační průvodce včetně kompatibility listu a dalších poznámek (VMware, Inc., 2016b, online) 9.1.1

Instalace hypervizoru ESXi

Zdrojové instalační soubory hypervizoru jsou dostupné jako instalační ISO obraz. Celá instalace bez prvotního nastavení na testovacím serveru trvala cca 6,5 minut. Po úspěšné instalaci je třeba nastavit výchozí management rozhraní hypervizoru, zařadit hypervizor do správné VLAN sítě a nastavit jeho IP adresu včetně masky a výchozí brány. Další nastavení jsou prováděna buď přes webové rozhraní hypervizoru, přes vSphere Clienta nebo přes SSH. Během instalace na laboratorním hardwaru instalace hypervizoru pravidelně zamrzala. Příčinou byla kolize režimu Headless, díky kterému lze provozovat server bez monitoru či klávesnice. (Wigmore, online) Jednou z možností je v BIOSu režim Headless vypnout. V případě, že to BIOS neumožňuje, je potřeba během instalace hypervizoru vstoupit do konzole a pomocí příkazu ignoreHeadless=TRUE režim headless ignorovat. Po dokončení instalace je potřeba příkazem esxcfgadvcfg --set-kernel "TRUE" ignoreHeadless režim headless ignorovat permanentně. Je třeba brát ohled, že instalace byla prováděna na nepodporovaném hardwaru. Podporu je možné si ověřit přímo na webových stránkách dané platformy (VMware Inc., 2016, online), kde je volně stažitelný přímo i .pdf soubor. Při pokusu instalace hypervizoru na novém hardwaru proběhla instalace korektně bez chyb. 9.1.2

Instalace vCenter serveru.

vCenter server je nástroj, pomocí kterého je spravována celá platforma VMware vSphere. Pro provoz vCenter serveru je zapotřebí server s nainstalovaným operačním systémem Windows serverové edice.

Nasazení platformy

58

Instalace operačního systému Windows Server trvá delší dobu, protože kromě samotného systému se po instalaci instalují i dodatečné aktualizace, které nejsou součástí čisté instalace. Windows Server 2012 R2 byl nainstalovaný cca za 20 minut bez aktualizací. Po instalaci se pomocí služby Windows update začaly stahovat aktualizace, kdy balík aktualizací měl velikost cca 1800 MB (v době instalace). Instalace a následně i konfigurace zmíněných aktualizací zabrala kolem 2 hodin času. Kromě samotného systému a aktualizací bylo ještě zapotřebí nainstalovat balíčky .NET Framework verze 2.0 a 3.0, které také nebyly součástí základní instalace OS. Instalace samotného balíku vCenter serveru trvala cca 40 minut. Po nainstalování vCenter Serveru a jeho základním nastavení je cela platforma prakticky připravena k používání. Celková doba nutná k nasazení instalace vCenter Serveru byla kolem 2,5 – 3 hodin. 9.1.3

Instalace vSphere Clienta

vSphere Client je nástroj, kterým je možné spravovat jak samotný hypervizor, tak i vCenter server, pomocí kterého lze pak spravovat i celý serverový cluster. Celou platformu lze ovládat i pomocí webového prostředí, nicméně ovládání pomocí tohoto nástroje se jeví jako přívětivější. Samotná instalace zabrala pouhé 3 minuty.

9.2

XenServer

Celá platforma je složena z hypervizoru XenServer a managementu XenCenter. Základní instalace platformy trvala 30 minut. Jestliže do instalace započítáme prvotní konfiguraci a vytvoření clusteru je potřeba cca 1 hodina času. Doba instalace se může lišit v závislosti na použitém hardwaru a rychlosti sítě. Stejně jako u platformy VMware lze na stránkách produktu v sekci software-dokumentace nalézt kompletní průvodce instalací včetně konfiguračních limitů a poznámek k vydání dané platformy (Citrix Systems, Inc, 2016b, online) 9.2.1

Instalace hypervizoru XenServer

Instalace hypervizoru XenServer je obdobná jako instalace hypervizoru ESXi. Zdrojové soubory jsou k dispozici v podobě instalačního ISO obrazu. Po dokončení instalace je potřeba provést základní nastavení, nastavit IP adresu, masku, bránu a DNS servery. Celá instalace hypervizoru trvala 15 minut včetně nastavení. Nevýhodou je, že management rozhraní hypervizoru XenServer neumí komunikovat přes tagované VLAN sítě (tagovaná VLAN síť je opatřena identifikátorem dané VLANy). Přímo na stránkách společnosti Citrix je uvedeno, že management serveru musí být připojen na netagovaný port na switchi (management VLAN je nastavena na portu jako nativní). (Citrix Systems, Inc, 2016a, online) 9.2.2

Instalace XenCenteru

XenCenter je management konzole pomocí které lze spravovat celou virtualizační platformu. XenCenter je dostupný jako instalační .exe soubor. Během instalace se

Nasazení platformy

59

zvolí cílové umístění, kam se má nainstalovat a po dokončení instalace je prakticky konzole připravena k používání. Hlavním rozdílem oproti vCenteru je, že XenCenter neobsahuje žádnou databázi, všechny informace získává z XenServer hypervizorů. V případě instalace XenCenteru na jiném PC si tak XenCenter po přidání jednoho hypervizoru přidá do konzole celý serverový cluster. Instalace XenCenteru trvala 1 minutu. Bohužel, XenCenter je ve výchozím stavu určen pouze pro provozování pod operačním systémem Windows jakékoliv edice. Existuje ale open source alternativa OpenXen Manager, která má identické ovládání a tedy splní stejnou užitnou hodnotu.

9.3

oVirt

Základem instalace virtualizační platformy oVirt je operační systém Linux, typicky CentOS nebo Fedora, do kterého jsou nainstalovány jednotlivé balíčky platformy oVirt. Celá platforma se skládá ze dvou základních funkčních prvků, enginu a nodu. Engine je řídícím členem celé platformy. Node je host (obdoba hypervizoru jiných platforem) poskytující systémové prostředky jednotlivým virtuálním serverům. Celková doba potřebná pro nasazení a prvotní nastavení platformy oVirt v případě instalace na laboratorním hardwaru zabrala cca 1 hodinu času, pomineme-li počáteční problémy s nekompatibilitou OS a balíčků (v tomto případě by byla doba samotné instalace této platformy delší). Na webových stránkách platformy oVirt je taktéž dostupný průvode instalací včetně dokumentace (oVirt, 2016, online) 9.3.1

Příprava OS Linux

Pro nasazení virtualizační platformy oVirt je potřeba připravit základní instalaci operačního systému Linux. Před samotnou instalací platformy oVirt je vhodné nainstalovat poslední dostupné aktualizace. Dále je třeba nastavit IP adresy, masky, brány, name servery jednotlivých prvků. Pro lepší orientaci a snadnou identifikaci je vhodné nastavit i hostname serverů. Celková doba instalace operačního systému Fedora verze 23 trvala cca 10 minut, do tohoto času je potřeba také započítat základní konfiguraci, která trvala také 10 minut. Systém byl tedy s rezervou nainstalován do 30 minut. 9.3.2

Instalace oVirt engine

oVirt engine se instaluje pod operačním systémem Linux v podobě balíčků. Je jich celkem 200-250 v závislosti na verzi platformy a aktuálnosti operačního systému. Pro nainstalování je třeba přidat repozitář platformy, následně nainstalovat engine a spustit průvodce prvotním nastavením. To lze v případě verze oVirt 4.0 provést následujícím způsobem: sudo dnf install http://resources.ovirt.org/pub/yumrepo/ovirt-release40.rpm

Nasazení platformy

60

sudo dnf install ovirt-engine sudo engine-setup

Po zadání posledního výše uvedeného příkazu se spustí průvodce instalací, který správce provede instalací. Instalace je prováděna v terminálu v několika krocích, kdy se instalátor ptá na specifické věci ohledně instalace. Všechny hodnoty však byly ponechány na hodnotách výchozích. Celková doba instalace enginu trvala včetně stahování balíčku cca 15 minut. 9.3.3

Instalace oVirt Node

Existují dva typy instalace. Prvním z nich je nainstalování již připraveného operačního systému, který je upravený pro použití v oVirtu a obsahuje potřebné balíčky, který je se nazývá jako NODE. Instalační soubor je dostupný v podobě ISO obrazu na webových stránkách oVirtu. Druhou možností je nainstalování dodatečných balíčků do minimální instalace operačního systému Linux. Přidání instalačních balíčků je možné pomocí: yum localinstall http://plain.resources.ovirt.org/pub/yumrepo/ovirt-release40.rpm

Jednotlivé odkazy na balíčky jsou dostupně v aktuální formě na webových stránkách platformy oVirt. Oproti předchozím dvěma platformám je zde při instalaci zásadní rozdíl v tom, že v případě instalace platformy pomocí balíčků nad operačním systémem Linux se samotná instalace NODE provede až v okamžiku přidávání hosta do clusteru. V tomto okamžiku se stahují i podpůrné balíčky. Přidání hosta do clusteru se provádí pomocí webové administrační konzoly, která běží na Enginu. V první fázi nasazování platformy oVirt byl jako základ použit operační systém CentOS 7 v posledním dostupném buildu 1511. Vzhledem k nekompatibilitě staršího hardwaru se CentOS 7 v kombinaci s oVirtem nepodařilo zcela bez problémů zprovoznit. Z toho důvodu byla zvolena instalace v podobě zcela kompatibilní Linuxové distribuce Fedora Server verze 23, jejíž instalace už proběhla bez problému. Během instalace byla ponechána výchozí nastavení. V případě distribucí, kde není k dispozici instalační balíček platformy oVirt, lze využít možnosti si oVirt zkompilovat. Primárně jsou však podporovány jen Linuxové distribuce vývojové větve Red Hatu, což je distribuce CentOS, Fedora, RHEL (oVirt Quick Start Guide, 2016, online)

Možnosti správy platforem a další nástroje

61

10 Možnosti správy platforem a další nástroje Každá z virtualizačních platforem nabízí hned několik možností, jak ji spravovat. V první řadě se jedná o nástroje, které jsou dodávány spolu danou platformou. Kromě těchto nástrojů existují i další možnosti správy a řízení těchto platforem, ať už v podobě open source aplikací nebo placených aplikací třetích stran.

10.1 VMware Platformu VMware vSphere 6 lze v základu spravovat pomocí několika nástrojů, mezi něž patří SSH, web management hosta (i vCenteru) a správa pomocí vSphere Clienta. Následující obrázek ukazuje web management vCenteru. Samotný webový management i vSphere Client je propracovaný a umožní spoustu nastavení včetně podrobných grafů vytížení jednotlivých klíčových prvků, logů či dalších upozornění.

Obr. 14

Ukázka web managementu platformy VMware vSphere 6 (vlastní práce)

Kromě standardních produktů existují i například i mobilní aplikace, přes které lze celou platformu ovládat například z mobilního telefonu či tabletu vzdáleně. Jedním z povedených zástupců je aplikace VMware vSphere Mobile Watchlist, pomocí které lze ovládat jednotlivé virtuální stroje, prohlížet logy, grafy vytížení a další možnosti. Aplikace je také plně lokalizovaná do českého jazyka. Následující obrázky znázorňují ukázky grafického prostředí.


Obr. 15 online)

62

Ukázka grafického prostředí aplikace vSphere Mobile Watchlist (148apps.com, 2016,

Mezi dalšími povedenými nástroji, které slouží pro management i správu lze jmenovat:  Veeam ONE – nástroj pro monitoring platformy, obsahuje přehledný dashboard, umožňuje procházet logy. Tato aplikace je poskytována zdarma i jako placená.  Veeam Backup – aplikace pro zálohování virtuálních strojů.  VMware vCenter converter – převádí fyzické stroje do virtuálních disků, zvládá i formáty třetích stran.

10.2 XenServer Tato platforma je v základu spravována pomocí SSH nebo XenCenter managera. Samotný XenServer je však svým ovládáním hodně podobný ovládání platformy VMware, kterému se snaží konkurovat. V základu XenServer bohužel nenabízí webovou správu je však možné ji doinstalovat. Je nabízena kromě placeného řešení i ve velmi omezené verzi zdarma. XenCenter stejně tak jako VMware umožňuje provádět akce s jednotlivými hosty i virtuálními stroji. Umožňuje procházet logy, zobrazit alarmy, upozornění a grafy vytížení jednotlivých prvků. Mezi nástroji, které zefektivní práci s touto platformou, patří:  XenOrchestra – webový management pro platformu XenServer (v základu zdarma), pokročilejší funkce placené,  opManager – pokročilejší správa celé platformy (placená aplikace). Vzhledem k tomu, že u platformy XenServer bylo uvolněné XAPI, lze očekávat, že nárůst aplikací bude narůstat. Ať už v podobě placených aplikací, tak v podobě open source řešení. Kromě aplikací je možnost provázání XenServeru s monitorovacími nástroji MUNIN či NAGIOS.


Obr. 16

63

Ukázka managementu platormy XenServer (vlastní práce)

Obr. 17 Ukázka web managementu platformy XenServer pomocí XenOrchestra (Ryan Morris, 2016, (online)

10.3 oVirt Management této platformy je možný v základu přes SSH nebo webovou administrativu. Nevýhodou webové administrace však může být rychlost ovládání, zejména na starších počítačích. Webová administrace umožňuje spravovat kompletně celou platformu včetně zobrazení logů, upozornění a dalších systémových informací, nevýhodou však může být chybějící podrobnější zobrazení grafů vytížení (není-li brán v úvahu úvodní dashboard). Kromě výše dvou zmiňovaných nástrojů se objevují podobně jako u platformy VMware i mobilní aplikace, pomocí které lze platformy spravovat. Jedním ze zástupců je mobilní aplikace moVirt, která nabízí přehledné rozhraní obsahující i samotný dashboard. Mezi další možnosti, které aplikace nabízí je možnost zásahu do chodu jednotlivých virtuálních strojů.


64

Vzhledem k tomu, že platforma oVirt běží nad Linuxovým operačním systémem, lze do ní oproti ostatním platformám doinstalovat mnoho dalších balíčků, pomocí kterých lze zefektivnit celou správu a monitoring celé platformy. Jedním z příkladů jsou monitorovací nástroje HTOP, GLANCES, MUNIN, NAGIOS či Cockpit.

Obr. 18

Ukázka managementu virtualizační platformy oVirt (vlastní práce)

Obr. 19

Ukázka rozhraní mobilní aplikace moVirt (Google Play, 2016, online)

Testy výkonu procesoru

65

11 Testy výkonu procesoru 11.1 Testy výkonu procesoru 1vCPU Prvním provedeným testem byl test procesorového výkonu virtuálního stroje s jedním přiděleným procesorovým jádrem (1 vCPU). Výsledky jsou znázorněny v následující tabulce č. 14, kde je pro lepší přehlednost zvýrazněn zeleně nejlepší výsledek a červeně výsledek nejhorší. Dále je uveden procentuální rozdíl výkonu mezi nejlepším a nejhorším průměrným výsledkem platforem v daném testu. Celkově v testu s jedním přiděleným jádrem podala nejlepší výkon platforma VMware, která si dobře vedla v operacích s celými čísly a v operacích s desetinnou čárkou. Nejlepší výsledek podala i ve využití SSE instrukcí, řazení a testu výkonu na jedno jádro (Single Threaded). Na druhém místě se dle celkového hodnocení umístila platforma oVirt, která oproti platformě VMware vynikala v operacích s prvočísly a výpočtu fyziky. Na druhou stranu oproti VMware měla nejhorší výsledky při operacích s celými čísly, kde oproti vítězi ztratila 5,4 % výkonu a při řazení, kde byl rozdíl výkonu pouhých 1,5 %, což lze považovat za běžnou odchylku. Na třetím místě se umístila platforma XenServer i přesto, že podala nejlepší výsledky v kompresi a šifrování. Oproti platformě oVirt měla náskok jen v podobě 1,8 %, což lze opět považovat za běžnou odchylku. V celkovém hodnocení testu procesoru VM s jedním přiděleným jádrem byl rozdíl výkonu v průměru 2,44 %, což je zanedbatelný rozdíl výkonu. Tab. 14

Výsledky výkonu procesoru při 1vCPU

1vCPU CPU Mark Integer Math Floating Point Math Prime Numbers SSE Instruction Compression Encryption Physics Sorting Single Threaded

VMware XenServer 803,5 783,833 1028,167 993,833 814,667 706,167 2,152 2,087 3,04 2,992 798 802,167 143,2 143,383 44,85 44,967 601 599,5 809,333 748,833

oVirt Rozdíl v % 791,333 2,448 972,667 5,398 731,667 13,318 2,283 8,585 2,972 2,237 787,667 1,808 141,583 1,255 46,883 4,336 591,667 1,553 756,333 7,475

Výsledky testů, které zahrnují i minimální a maximální naměřené hodnoty včetně směrodatné odchylky jsou k nalezení v příloze. V následující tabulce je uvedeno, v jakých jednotkách jsou jednotlivé výsledky v tabulkách č. 14 a 16 uváděny.

Testy výkonu procesoru Tab. 15

66

Měrné jednotky testů CPU

Test CPU Mark Integer Math Floating Point Math Prime Numbers SSE Instruction Compression Encryption Physics Sorting Single Threaded

Jednotka body milion operací za sekundu milion operací za sekundu milion prvočísel za sekundu milion matic za sekundu KB/s MB/s FPS tisíc řetězců za sekundu milion operací za sekundu

11.2 Testy výkonu procesoru 4vCPU Pro virtuální stroj se čtyřmi přidělenými jádry byl provedený stejný test. Výsledky testu jsou zobrazeny v následující tabulce č. 16. Zeleně jsou vyznačeny nejlepší výsledky, červeně nejhorší. Dle těchto výsledků je patrné, že většina výsledků oproti testu VM s jedním jádrem je více či méně čtyřnásobná, což odpovídalo čtyřem přiděleným vláknům. V tomto testu podala nejlepší výsledky v drtivé většině testů platforma Citrix XenServer s celkovým rozdílem 7,344 % oproti oVirtu (který podal horší výsledek než VMware) a v žádném z testů neskončila na posledním místě. Na druhém místě se umístila platforma VMware, která propadla v testech výpočtů prvočísel a při výpočtech fyziky. Na posledním místě se umístila platforma oVirt, která většinou podala nejhorší dosažený výsledek. Zvláštností však je, že v případě operací s plovoucí desetinnou čárkou podal oVirt značně slabší výsledek, jehož rozdíl oproti platformě VMware činí 29,5 %. Abychom se ujistili, že se nejedná o výkyvy hodnot, vyřadíme z testu nejlepší a nejhorší výsledek, výkonnostní rozdíl se téměř nezmění, zůstane obdobný. Z tabulky je také patrné, že kromě operací s plovoucí desetinnou čárkou jsou velké rozdíly výkonu i v oblasti práci s fyzikou, operacemi s celými čísly a operacemi s prvočísly. Celkový rozdíl v celkovém hodnocení výkonu mezi platformami byl až 7,3 %, což jsou mnohem větší výkonnostní rozdíly, než u testu s jedním přiděleným vláknem.

Testy výkonu procesoru Tab. 16

67

Výsledky výkonu procesoru při 4vCPU

4vCPU CPU Mark Integer Math Floating Point Math Prime Numbers SSE Instruction Compression Encryption Physics Sorting Single Threaded

VMware XenServer 2735,667 2884,333 4116,167 4131,167 3255,000 3240,000 6,483 7,417 12,200 12,033 3174,500 3206,667 555,333 576,500 143,167 180,933 2400,333 2434,000 799,167 813,500

oVirt Rozdíl v % 2672,500 7,344 3705,667 10,300 2292,500 29,570 7,267 12,584 11,850 2,869 3139,667 2,089 548,333 4,886 166,233 20,873 2367,833 2,718 762,333 6,290

V následujícím grafu jsou zobrazeny rozdíly celkového výkonu jednotlivých platforem pro 1 i 4 procesorová jádra.

Obr. 20

Srovnání výkonu procesoru pro 1 vCPU a 4 vCPU

Jak je z grafu patrné, rozdíly procesorového výkonu VM s jedním přiděleným jádrem jsou minimální (cca 2,5 %), oproti tomu rozdíly procesorového výkonu VM se 4 jádry jsou větší (cca 7 %). Celkové rozdíly procesorového výkonu jednotlivých platforem mezi VM s 1 vCPU a VM s 4 vCPU byly až 3,5 násobné.

Testy výkonu operační paměti

68

12 Testy výkonu operační paměti 12.1 Testy výkonu operační paměti RAM při 1vCPU V celkovém hodnocení získala nejvíce bodů v testu rychlosti operační paměti platforma oVirt s rozdílem 11,9 % oproti platformě XenServer. Ta podala nejhorší výsledek skoro ve všech testech kromě rychlosti čtení s vyrovnávací pamětí. Zde byla naopak nejhorší platforma oVirt s rozdílem 3,4 %. V rychlosti čtení bez vyrovnávací paměti byla situace opačná, zde podala nejlepší výkon platforma oVirt s rozdílem 10,07 % oproti XenServeru. V testu zápisu podala nejlepší výkon platforma VMware. Test dostupné paměti lze pominout, neboť tento test pouze zohledňuje, kolik volné paměti má daný virtuální stroj k dispozici. V případě latence paměti (její odezvy) podala nejlepší výkon platforma oVirt, nejhorší výkon naopak XenServer. V oblasti databázových operacích jednoznačně vedl oVirt s rozdílem téměř 25,8 % oproti platformám VMware i XenServer, jejichž výkon je srovnatelný. V následující tabulce jsou uvedeny výsledky testů pro VM s 1 vCPU. V tabulce č. 18 jsou uvedeny měrné jednotky provedených testů. Tab. 17

Výsledky výkonu operační paměti RAM při 1vCPU

1vCPU Memory Mark Database Operation Read Cached Read Uncached Write Avaiable RAM Latency Threaded Tab. 18

VMware XenServer oVirt Rozdíl v % 516,167 483,183 548,667 11,935 14,583 14,567 19,650 25,869 8296,833 8313,000 8029,000 3,416 2650,833 2450,833 2725,500 10,078 2620,667 2374,333 2593,333 9,400 3400,833 3336,167 3391,167 1,901 103,400 120,883 100,750 16,655 2641,333 2454,333 2720,000 9,767

Měrné jednotky testů RAM

Test Memory Mark Database Operation Read Cached, Read Uncached, Write, Threaded Avaiable RAM Latency

Jednotky body tisíc operací za sekundu MB/s dostupných MB ns

12.2 Testy výkonu operační paměti RAM při 4vCPU V testech na virtuálním stroji s přidělenými 4 vCPU byla situace jiná. V celkovém hodnocení získala opět nejlepší výsledek platforma oVirt, na druhém místě plat-

Testy výkonu operační paměti

69

forma XenServer a na posledním místě VMware s propadem výkonu o 8 % oproti platformě oVirt. Platforma oVirt si především vedla v databázových operacích, ve čtení bez vyrovnávací paměti, v zápisu a v nízké latenci. Naopak nejhorší výsledek měla ve čtení s vyrovnávací paměti, kde naopak vyhrál XenServer, který podal o 1,3 % lepší výkon i přesto, že tento rozdíl výkonu lze považovat za odchylku. Následující tabulka č. 19 zobrazuje naměřené výsledky pro virtuální stroj s 4 vCPU. V celkovém hodnocení byly rozdíly výkonu menší (8,67 %) než u VM s jedním přiděleným jádrem (11,93 %). Tab. 19

Výsledky výkonu operační paměti RAM při 4vCPU

4vCPU Memory Mark Database Operation Read Cached Read Uncached Write Avaiable RAM Latency Threaded

VMware XenServer oVirt Rozdíl v % 579,167 605,500 634,167 8,673 13,800 19,217 19,533 29,352 8332,167 8396,833 8280,167 1,389 2477,833 2561,500 2740,167 9,574 2393,000 2483,667 2600,833 7,991 3390,833 3415,500 3466,500 2,183 107,117 118,167 101,033 14,499 7867,167 6554,167 6173,500 21,528

Následující graf zobrazuje celkový rozdíl výkonu operační paměti virtuálního stroje při jednom přiděleném procesorovém jádře a při čtyřech jádrech. Jak je z grafu patrné, v obou testech vyhrála platforma oVirt. Následující graf také dokazuje, že na výkon operační paměti má nepřímý vliv i výkon samotného procesoru. Rozdíl výkonu v případě platformy oVirt byl mezi VM s 1 vCPU a VM s 4 vCPU necelých 13,5 %. V případě platformy XenServer necelých 20 %, v případě poslední platformy VMware byl rozdíl výkonu nejmenší, necelých 10,8 %.

Obr. 21

Srovnání výkonu operační paměti RAM pro 1 vCPU a 4 vCPU

Testy výkonu 2D grafické karty

70

13 Testy výkonu 2D grafické karty Jak je možné vidět v tabulce č. 20, v naprosté většině případů podala největší výkon platforma VMware, která oproti platformě oVirt (která naopak ve většině případů prohrála) měla rozdíl výkonu až o 43 % (práce s textem a fonty). Platforma XenServer v naprosté většině testů podala oproti ostatním platformám průměrný výsledek s výjimkou renderování obrázků, kde podala nejlepší výkon. Nejslabší grafický výkon podala, jak je z tabulky patrné, platforma oVirt. Pokud by server obsahoval dedikovanou (přídavnou) grafickou kartu, lze očekávat, že výkon bude mnohem vyšší, zejména ve 3D grafice. V tabulce č. 21 jsou pak uvedeny měrné jednotky jednotlivých testů. Tab. 20

Výsledky výkonu 2D grafické karty

1vCPU VMware XenServer Graphics Mark 180,283 176,717 Simple Vectors 11,433 10,967 Complex Vectors 46,350 45,883 Fonts and Text 53,550 51,167 Windows Interface 46,200 45,050 Image Filters 261,017 245,350 Image Rendering 157,367 164,950 Direct 2D 2,363 2,322 Tab. 21

oVirt 148,900 9,000 42,450 30,200

Rozdíl v % 17,408 21,283 8,414 43,604

44,817 163,583 138,017 2,372

2,994 37,328 16,328 2,108

Měrné jednotky testů grafické karty

1vCPU Graphics Mark Simple Vectors Complex Vectors Fonts and Text Windows Interface Image Filters Image Rendering Direct 2D

Jednotky body tisíc vykreslených vektorů za sekundu počet vykreslených vektorů za sekundu operací za sekundu operací za sekundu filtrů za sekundu počet snímků za sekundu FPS

V následujícím grafu jsou zachyceny celkové rozdíly výkonu jednotlivých platforem. Jak je z grafu patrné, platformy XenServer a VMware dosáhly ve výkonu 2D grafické karty velmi podobných výsledků. Platforma oVirt byla mnohem pomalejší.

Testy výkonu 2D grafické karty

Obr. 22

Rozdíly výkonu grafické karty v rámci jednotlivých platforem

71

Testy výkonu diskového úložiště

72

14 Testy výkonu diskového úložiště 14.1 Test výkonu virtuálního disku na diskovém poli NAS V případě testu rychlostí virtuálního pevného disku, který je uložen na diskovém poli NAS podala nejlepší výkon platforma XenServer, která vyhrála ve všech testech v aplikaci PassMark. Na druhém místě se umístila platforma oVirt, která podala nejhorší výsledek pouze v testu sekvenčního čtení. Na třetím místě se umístila platforma VMware, která tratila oproti vítězné platformě až 28 % svého výkonu. Budeme-li brát v potaz pouze čtení a zápis na disk, tak tratila jen 13,8 % výkonu. Veliké rozdíly výkonu však lze pozorovat v testu náhodného čtení (random seek), který byl až 28,1 %. Následující tabulka č. 22 zobrazuje výsledky testů na virtuálním stroji s přiděleným 1 vCPU. Tab. 22

Výsledky výkonu virtuálního disku umístěného na NAS pro 1 vCPU (PassMark)

NAS Disk Mark [body] Sequential Read [MB/s] Sequential Write [MB/s] Random Seek [MB/s]

VMware XenServer 895,833 1024,000 108,317 108,833 85,233 98,967 54,117 75,350

oVirt Rozdíl v % 927,833 12,516 104,667 3,828 95,117 13,877 56,800 28,180

Protože v současnosti mají jednotlivé stroje častěji přidělena 4 jádra, byly ty samé testy provedeny s přidělenými 4 vCPU, viz následující tabulka. Tab. 23

Výsledky výkonu virtuálního disku umístěného na NAS pro 4 vCPU (PassMark)

NAS Disk Mark [body] Sequential Read [MB/s] Sequential Write [MB/s] Random Seek [MB/s]


oVirt Rozdíl v % 935,500 12,694 106,317 3,069 96,100 16,989 56,250 23,400

Jak je patrné z tabulky výše (č. 23), opět nejlepší výsledky podala platforma XenServer, která si vedla ve všech testech. Nejhorší celkový výsledek opět podala platforma VMware, která tratila v případě testu sekvenčního zápisu 16,98 % výkonu oproti vítězi. Platforma oVirt propadla v testu sekvenčního čtení oproti vítězi o 3,06 %. Celkový rozdíl výkonu mezi platformou VMware a oVirt byl 12,7 %.

14.2 Test výkonu virtuálního disku na lokálním úložišti V případě testu výkonu virtuálního pevného disku na lokálním úložišti byly otestovány pouze platformy VMware a XenServer. Bylo tak učiněno z toho důvodu, že platforma oVirt patrně neumí provozovat v jednom serverovém clusteru hosta


73

s lokálním úložištěm i úložištěm na diskovém poli současně. Při pokusu vytvořit v existujícím clusteru lokální úložiště, se automaticky vytvořil cluster nový, který se automaticky pojmenoval na „local“. Vzhledem k tomu, že v současné praxi se v serverové sféře využívají z důvodu vysoké dostupnosti pro ukládání dat disková pole, byly testy platformy oVirt s VM na lokálním úložišti vypuštěny. Případným řešením by bylo použít souborový systém GlusterFS, který je založený na principu replikace dat mezi servery. Nicméně, při použití tohoto řešení by byly provedené testy z důvodu rozdílné infrastruktury neobjektivní. Jak je vidět v tabulce níže, v rychlostních testech disku VM umístěné na lokálním úložišti podala nejlepší výkon platforma XenServer. Rozdíl mezi XenServerem a VMwarem činil v případě sekvenčního čtení necelých 9,77 %, v případě sekvenčního zápisu 17,72 %. Tab. 24 Výsledky výkonu virtuálního disku umístěného na lokálním úložišti hypervizoru. (1 vCPU)

LOCAL Disk Mark [body] Sequential Read [MB/s] Sequential Write [MB/s] Random Seek [MB/s]


oVirt -

Rozdíl v % 13,729 9,773 17,728 15,369

V případě testu rychlosti disku VM s přidělenými 4 vCPU opět podala nejlepší výkon platforma XenServer, kde byl disk oproti VM s 1 vCPU mírně rychlejší, VMware byl naopak mírně pomalejší. Rozdíl v rychlostech však byl mezi platformami až 20,6 %, jak je uvedeno v tabulce č. 25. Tab. 25 Výsledky výkonu virtuálního disku umístěného na lokálním úložišti hypervizoru (4 vCPU)

LOCAL Disk Mark [body] Sequential Read [MB/s] Sequential Write [MB/s] Random Seek [MB/s]


oVirt -

Rozdíl v % 19,088 17,843 20,626 15,261

Je však nutné zohlednit, že jednotlivé testy byly prováděny na starém hardwaru, který nebyl uveden v support listu jednotlivých platforem. V případě testů na nových strojích by se výsledky mohly lišit. Následující grafy zachycují rozdíl výkonu pevných disků dle jeho typu (obrázek č. 23) a rozdíl výkonu disků dle platforem (obrázek č. 24).


74

Obr. 23

Rozdíl výkonu diskového úložiště v závislosti na jeho typu (vlastní práce)

Obr. 24

Rozdíl výkonu diskového úložiště v závislosti na virtualizační platformě (vlastní práce)

Testy propustnosti síťové konektivity

75

15 Testy propustnosti síťové konektivity V tabulce č. 26 jsou uvedeny průměrné výsledky jednotlivých testů v Mbps. V naprosté většině testů podala nejlepší výkon platforma XenServer, naopak nejhorší výsledky podala platforma VMware. Vzhledem k tomu, že platforma oVirt patrně neumí v jednom clusteru pracovat současně s diskovým polem NAS a lokálním úložištěm, nebylo možné v případě platformy oVirt provést testy, kdy VM měl virtuální disk uložen lokálně na hostovi. Protože všechny prvky, které jsou v testovací infrastruktuře použity, zvládají rychlost síťové konektivity maximálně 1 Gbps, lze předpokládat, že síť rychlejší jak 1 Gbps nebude. Je zajímavé, že v případě komunikace mezi dvěma virtuálními stroji, které byly hostované jedním hostem (běžely na jednom hypervizoru) a zároveň komunikovali v rámci stejné VLAN sítě, přesahovala komunikace rychlost 1 Gbps. V případě VMwaru byla rychlost v rozmezí mezi 1146 -1176 Gbps. V případě XenServeru byla komunikace oproti VMwaru rychlejší, rychlost se pohybovala mezi 2083 – 2133 Gbps. Avšak velmi překvapivý výsledek podala platforma oVirt, kde komunikace probíhala v rozmezí mezi 3296 – 3343 Gbps. Jestliže se zaměříme na výsledky testů propustnosti VM v rámci různých hostů, byly rozdíly výkonu maximálně kolem 4 %, což by v běžném provozu nemělo být poznat. V případě výsledků testů propustnosti VM v rámci jednoho hosta byly rozdíly mnohonásobně větší. Rychlostní rozdíly byly až 65 %. Tab. 26

Výsledky rychlosti síťové komunikace mezi dvěma VM v rámci jedné VLAN

Situace H1N1 to H2N2 H1N1 to H1N1 H1Local1 to H2Local2 H1Local1 to H1N1 H1Local1 to H1Local1 H1Local1 to H2N2 H1N1 to H1N2 H1N1 to H2N1

VMware XenServer [Mbps] [Mbps] 923,667 937,000 1151,667 2120,000 925,500 936,167 1146,667 2133,333 1176,667 2128,333 910,833 938,667 1156,667 2083,333 923,000 937,167

oVirt [Mbps] 898,667 3296,667 3343,333 903,167

Rozdíl v % 4,091 65,066 1,139 46,250 44,714 2,965 65,404 3,628

V následující tabulce č. 27 pak vysvětlivky jednotlivých zkratek udávajících pozici jednotlivých VM. Jako příklad je možné uvést zkratku „H1N1 to H2N2“. To znamená, že komunikace probíhala mezi VM hostovanou hostem 1 s diskem umístěným na NAS1 a VM hostovanou hostem 2 s diskem umístěným na NAS2. Stejné zkratky platí i pro kapitolu 16 – Testy rychlosti sítě v oblasti kopírování.

Testy propustnosti síťové konektivity Tab. 27

76

Vysvětlivky zkratek a umístění virtuálního stroje

Legenda H1N1 to H2N2 H1N1 to H1N2 H1N1 to H1N1 H1Loc1 to H1N1 H1Loc1 to H2N2 H1Loc1 to H2Loc2 H1Loc1 to H1Loc1 H1NAS1 to H2NAS1

VM1 Host1 Host1 Host1 Host1 Host1 Host1 Host1 Host1

VM2 NAS1 NAS1 NAS1 Local1 Local1 Local1 Local1 NAS1

Host2 Host1 Host1 Host1 Host2 Host2 Host1 Host2

NAS2 NAS2 NAS1 NAS1 NAS2 Local2 Local1 NAS1

Vzhledem k tomu, že propustnost sítě mezi VM v rámci jednoho hosta a stejné VLAN sítě (v našem případě VLAN100) přesahovala rychlost 1 Gbps, byl ten stejný test proveden i pro komunikaci v rámci odlišných VLAN sítí. V tomto případě však rychlost komunikace byla do 1 Gbps, jak je možné vidět v tabulce č. 28 (výsledky jsou opět uvedeny v Mbps. Vysvětlením tohoto jevu je, že komunikace v rámci různých VLAN sítí probíhá přes distribuční switch Juniper, na kterém jsou packety směrovány mezi sítěmi. V případě síťové komunikace v rámci jednoho hosta a jedné VLAN sítě (stejné sítě) packety neopouští síťové rozhraní. Opět podala nejlepší výsledky platforma XenServer. Rychlostní rozdíly mezi nejhorším a nejlepším výsledkem byly v tomto případě maximálně 3 %, což je zanedbatelné. Tab. 28

Výsledky rychlosti síťové komunikace mezi dvěma VM v rámci různých VLAN sítí

Situace Host1Nas1 to Host1Nas2 Host1Local1 to Host1Local1

VMware XenServer [Mbps] [Mbps] 928,167 931,667 908,500 933,333

oVirt [Mbps] 903,667 -

Rozdíl v % 3,005 2,661

V následujícím grafu jsou zachyceny výkonnostní rozdíly propustnosti sítě mezi virtuálními servery hostovanými jedním hypervizorem, to v rámci jedné VLAN sítě (modrá) i různých VLAN sítí (oranžová). Jak je možné si v grafu všimnout, rozdíly propustnosti v rámci různých VLAN sítí jsou minimální. V případě, že komunikace probíhala v rámci stejné VLAN sítě, platforma oVirt měla oproti platformě VMware téměř trojnásobný nárůst propustnosti.

Testy propustnosti síťové konektivity

77

Obr. 25 Rozdíly výkonu propustnosti VM hostované jedním hypervizorem v rámci stejné VLAN a různých VLAN sítí (vlastní práce)

Graf č. 26 znázorňuje stejnou situaci jako graf přechozí s tím rozdílem, že jsou v něm porovnány rozdíly výkonu mezi jednotlivými virtualizačními platformami.

Obr. 26

Rozdíly výkonu propustnosti sítě v rámci jednotlivých platforem

Testy rychlosti sítě v oblasti kopírování

78

16 Testy rychlosti sítě v oblasti kopírování Prvním provedeným testem bylo měření doby kopírování malých a velkých souborů mezi virtuálními stroji za pomocí Windows utility XCOPY. Jak je z tabulky č. 29 patrné, v naprosté většině testů sady souborů nejrychleji zkopírovala platforma XenServer. V některých případech však nejlepší výsledky podala i platforma oVirt, zejména v testech, kde byly oba virtuální stroje hostované jedním hypervizorem. Nejhorší výsledky však podal VMware u kterého byly výkonnostní rozdíly až 29 % oproti vítězné platformě. Je však nutné podotknout, že výsledky těchto testů nejsou závislé pouze na rychlosti sítě, ale i na kompatibilitě samotného hardwaru. Testy byly prováděny na starém hardwaru, který není uveden v support listu výrobce, což by mohlo mít vliv na výkon například z důvodu nekompatibilních ovladačů. Do jisté míry rychlost kopírování může ovlivňovat i samotný operační systém. V testech rychlosti diskového úložiště a propustnosti sítě nemohly být na platformě oVirt provedeny všechny testy, neboť jak bylo v přechozích testech zmíněno, oVirt pravděpodobně neumožňuje souběžný provoz lokálního úložiště a diskového pole. Sada 1 obsahuje 3 ISO obrazy, sada 2 obsahuje malé soubory. Tab. 29

Výsledku rychlosti kopírování mezi VM pomocí utility XCOPY

Windows XCOPY H1N1 to H2N2 H1N1 to H1N2 H1N1 to H1N1 H1Local1 to H1N1 H1Local1 to H2N2 H1Local1 to H2Local2 H1Local1 to H1Local1 H1N1 to H2N1

SADA1 SADA2 SADA1 SADA2 SADA1 SADA2 SADA1 SADA2 SADA1 SADA2 SADA1 SADA2 SADA1 SADA2 SADA1 SADA2

VMware XenServer oVirt Rozdíl v % 0:03:29 0:02:54 0:02:53 17,34 0:08:19 0:07:03 0:07:07 15,17 0:03:06 0:03:03 0:02:53 7,25 0:07:32 0:06:23 0:06:00 20,43 0:04:45 0:04:38 0:04:57 6,26 0:09:36 0:07:54 0:07:50 18,41 0:03:10 0:02:15 29,06 0:05:46 0:04:32 21,31 0:03:15 0:02:21 27,44 0:06:16 0:05:56 5,52 0:03:19 0:02:45 17,38 0:06:08 0:06:16 2,14 0:05:21 0:04:43 12,00 0:06:58 0:06:52 1,34 0:05:18 0:03:48 0:04:11 28,32 0:08:52 0:08:28 0:08:33 4,55

Pokud bychom se zaměřili na jednotlivé výsledky detailněji, můžeme si všimnout, že v případě testů pomocí XCOPY byly rozdíly mezi zkopírováním sady malých souborů a velkých souborů téměř dvojnásobné. V případě, kde virtuální stroje měly jejich virtuální disk uložený na stejném úložišti (některý z NAS nebo lokálních disků), byla doba potřebná ke zkopírování sady souborů delší. Je to dáno tím, že

Testy rychlosti sítě v oblasti kopírování

79

v těchto případech pevný disk provádí současně čtení i zápis dat, což způsobuje jeho větší vytížení a tím i zpomalení kopírování dat. Pokud se podíváme na výsledky testů provedených pomocí aplikace FastCOPY (viz tabulka č. 30), zjistíme, že v některých případech byly časy nutné ke zkopírování sad souborů kratší. Týká se to především doby kopírování sady malých souborů, kde se rozdíly rychlosti oproti XCOPY lišily až o 45 %. V tomto testu opět nejlepší výsledky podala platforma XenServer, která byla oproti platformě VMware rychlejší až o 25 %. Platforma oVirt podala průměrné výsledky, ve dvou však případech (kopírování dat v rámci jednoho hosta a odlišných NAS polí a kopírování dat v rámci různých hostů a identického NAS pole) podala nejlepší výkon. I v tomto testu se ukázalo, že v případě, kopírování dat mezi virtuálními stroji, které mají disk uložený na jednom stejném úložišti (NAS nebo lokální disk) je doba kopírování dat z důvodu většího vytížení disku delší. Zároveň se ukázalo, že na rychlost kopírování dat má především vliv kromě rychlosti sítě i samotná použitá aplikace, která může používat odlišný algoritmus. Celkovou rychlost diskového pole ovlivňuje i samotný diskový řadič, jeho ovladač i disk jako takový. Budeme-li brát v potaz klasické plotnové disky, jejich maximální teoretická rychlost je dle modelu uváděna v rozmezí 140 – 220 MB/s. Přes 1 Gbps síť lze teoreticky maximálně přenášet data rychlostí 125 MB/s. Pokud ale budeme mít na diskovém poli 10 Gbps síťová rozhraní, jako lepší možnost se jeví použití SSD disků, jejichž rychlost je mnohonásobně rychlejší, tyto disky zvládají rychlosti přes 500 MB/s (odpovídá teoretickým 4 Gbps). Tab. 30

Výsledky rychlosti kopírování pomocí utility FastCOPY

FastCopy H1N1 to H2N2 H1N1 to H1N2 H1N1 to H1N1 H1Local1 to H1N1 H1Local1 to H2N2 H1Local1 to H2Local2 H1Local1 to H1Local1 H1N1 to H2N1

SADA1 SADA2 SADA1 SADA2 SADA1 SADA2 SADA1 SADA2 SADA1 SADA2 SADA1 SADA2 SADA1 SADA2 SADA1 SADA2

VMware XenServer oVirt 0:03:08 0:02:32 0:03:27 0:04:40 0:03:31 0:04:04 0:02:46 0:02:30 0:02:20 0:04:06 0:03:05 0:03:21 0:04:43 0:04:20 0:04:42 0:06:05 0:05:00 0:05:36 0:03:00 0:02:29 0:03:35 0:02:40 0:03:03 0:02:22 0:04:21 0:03:31 0:03:01 0:02:36 0:03:56 0:03:42 0:05:30 0:04:07 0:06:14 0:04:56 0:05:52 0:03:33 0:03:18 0:05:42 0:04:43 0:06:04

Rozdíl v % 26,39 24,84 16,12 24,81 8,12 17,90 17,36 25,17 22,75 18,91 13,71 6,14 25,19 20,78 43,87 22,34

Testy síťových výpadků platforem

80

17 Testy síťových výpadků platforem V této kapitole je popsáno, jak se jednotlivé virtualizační platformy a její prvky chovaly. Důvod, proč nelze shrnout výsledky testů výpadků do tabulky či grafu je ten, že v případě výpadku a opětovného obnovení konektivity kteréhokoliv prvku všechny technologie zvládly obnovit svoji dostupnost do původního stavu. Nemá tedy smysl porovnávat výpadky jednotlivých technologií formou tabulky, kde by bylo zaznačeno, že výpadek zvládly všechny technologie. Další možností, jak technologie porovnat je měření času od opětovného zapojení odpojené kabeláže k plnému obnovení dostupnosti, tak jak tomu bylo před výpadkem. I zde postrádá smysl srovnávání jednotlivých technologií, protože je zcela irelevantní, pokud vypadnou všechny 3 technologie na dobu jedné minuty s odchylkou měření např. 2 vteřin a všechny technologie obnoví svou plnou dostupnost s rozdílem několika vteřin. Lze tedy usoudit, že do finálního porovnání platforem formou metody vícekriteriálního rozhodování nelze test výpadků objektivně zahrnout a je zde tedy uveden pouze slovně popsaný výsledek pozorování chování jednotlivých technologií, což je mnohem užitečnější výstup s lepší podrobností a názorností, než se o totéž pokoušet v tabulkové či grafové podobě. V níže uvedených tabulkách č. 31 – 38 jsou uvedeny doby výpadků jednotlivých prvků platforem z pohledu management počítače, na kterém byly spouštěny scripty.

17.1 Výpadky diskového pole 17.1.1

Výpadek celého diskového pole po dobu 5 sekund

V případě 5sekundového výpadku diskového pole ani jedna z testovaných platforem nezaregistrovala potíže s diskovým polem, nezobrazil se žádný alarm ani upozornění kromě platformy oVirt, která upozornila na zvýšenou latenci diskového pole. Všechny tři platformy síťový výpadek pole ustály a zůstaly v plně konzistentním stavu. Tab. 31

Testy síťových výpadků diskového pole po dobu 5 sekund

Sledovaný prvek Host

VMware

XenServer

oVirt

žádný síťový výpadek



Virtuální server




Diskové pole

ztráta konektivity po dobu 7 sekund




17.1.2

81

Výpadek celého diskového pole po dobu 60 sekund

V případě 60sekundového výpadku se u jednotlivých platforem vyskytnuly potíže s diskovým polem a každá z platforem určitým způsobem zasáhnula:  V případě platformy VMware vCenter po 38 sekundách zobrazil alarm, že ztratil konektivitu k jednomu diskovému poli. Virtuální stroje, které byly vypnuté, byly označeny jako nepřipojitelné (inaccessible). Ve 45. sekundě bylo celé diskové pole označeno jako nedostupné, jeho činnost byla obnovena po 1 minutě a 8 sekundách od počátku výpadku. Síťová konektivita k VM zůstala zachována. Funkce vysoké dostupnosti nebyly aktivovány. Platforma se uvedla do konzistentního stavu po 1 minutě a 8 sekundách.  V případě platformy XenServer bylo diskové pole označeno po 26 sekundách jako nedostupné a po 41 sekundách se objevilo hlášení „Heartbeat lost“. Konektivita diskového pole byla obnovena po 1 minutě a 40 sekundách, kdy zároveň byla celá platforma uvedena do plně funkčního stavu. Funkce vysoké dostupnosti nebyly aktivovány.  V případě platformy oVirt byly jednotlivé virtuální stroje po cca 23 sekundách od výpadku diskového pole pozastaveny (VM has been paused) a jejich provoz byl obnoven po 1 minutě a 7 sekundách (VM has recovered from paused back to up). Platforma se uvedla do konzistentního stavu po 1 minutě a 8 sekundách, kdy byly všechny prvky opět funkční. Tab. 32

Testy síťových výpadků diskového pole po dobu 60 sekund

Sledovaný prvek Host

VMware

XenServer

oVirt




Virtuální server




Diskové pole




17.2 Výpadky celého hosta (hypervizoru) 17.2.1

Výpadek hosta po dobu 5 sekund

 V případě platformy VMware se po 3 sekundách ve vCenteru spustil alarm „Network connectivity lost“ avšak host, u kterého došlo k výpadku konektivity, nebyl označen jako nefunkční. Byl zaznamenán 6sekundový výpadek virtuálních strojů. Funkce vysoké dostupnosti do chodu platformy nezasahovaly, platforma se do konzistentního stavu uvedla po 7 sekundách, kdy všechny prvky byly označeny opět jako aktivní.  U platformy XenServer došlo stejně tak jako u konkurenčního VMwaru k síťovému výpadku hosta po dobu 6 sekund. V XenCenteru se obrazilo hlášení o změně stavu bond připojení, funkce vysoké dostupnosti ale nezasahovaly. XenServer se uvedl do konzistentního stavu po 6 sekundách.


82

 Kromě 8sekundového výpadku konektivity k VM a 7sekundového výpadku hosta nebyly registrovány žádné další výpadky. Engine zobrazil hlášení o změně stavu uplinků, funkce vysoké dostupnosti do chodu nezasáhly, platforma se uvedla do konzistentního stavu po 8 sekundách. Tab. 33

Testy síťových výpadků hosta po dobu 5 sekund

Sledovaný prvek Host Virtuální server Diskové pole

17.2.2

VMware

XenServer

oVirt

ztráta konektivity po dobu 6 sekund ztráta konektivity po dobu 6 sekund






Výpadek hosta po dobu 60 sekund

 vCenter platformy VMware zobrazil po 19 sekundách alarm „HA failover“ a po 32 sekundách se inkriminovaný host označil jako nefunkční. Ve 32. sekundě byla VM C běžící na hostovi, který vypadnul, označena jako „failover“ a zároveň zafungovala funkce vysoké dostupnosti. V 51. sekundě se ostatní VM s virtuálním diskem umístěným na diskovém poli začaly spouštět na druhém hostovi. Platforma se uvedla do konzistentního stavu po 1 minutě a 12 sekundách.  V případě výpadků platformy XenServer záleží na tom, jakou roli daný host, který vypadnul, měl. Za předpokladu, že byl v roli master, došlo na úrovni XenCenteru po 57 sekundách k odpojení celého clusteru, po 63 sekundách k restartování celého hosta. V 2. minutě se cluster opět připojil, host B byl označen jako nový master. Ve 2:45 se začaly na hostu B spouštět virtuální stroje, jejichž konektivita byla obnovena po 3 minutách a 22 sekundách. Pokud byl host v roli slave, došlo po 57 sekundách k restartování hosta, který byl následně v 1:24 označen jako nedostupný a v 1 minutě a 40 sekundách se VM začaly spouštět na druhém hostovi a jejich konektivita byla obnovena po 2 minutách a 14 sekundách. Platforma byla uvedena do konzistentního stavu po 3:35 minutách v případě pádu master hosta, po 3:16 v případě pádu slave hosta, kdy byly všechny prvky označeny jako aktivní.  V případě virtualizační platformy oVirt došlo k 65sekundovému výpadku hosta a 67sekundovému výpadku virtuálních strojů. Engine po 33 sekundách zobrazil varování „VDSM heartbeat exceed“ a oznámil 81sekundovou čekací dobu, než označí hosta jako nedostupného. Konektivita k hostovi však byla po 1 minutě a 5 sekundách obnovena a celá platforma se uvedla do konzistentního stavu po 1 minutě a 43 sekundách, kdy byl odpojený host označen opět jako aktivní. Funkce vysoké dostupnosti nezafungovaly.

Testy síťových výpadků platforem Tab. 34

83

Testy síťových výpadků hosta po dobu 60 sekund

Sledovaný prvek

VMware

Host


Virtuální server


Diskové pole


XenServer ztráta konektivity po dobu 2:33 při pádu slave h. 2:41 při pádu master h. ztráta konektivity po dobu 2:14 při pádu slave h. 3:22 při pádu master h. žádný síťový výpadek

oVirt ztráta konektivity po dobu 65 sekund

ztráta konektivity po dobu 67 sekund žádný síťový výpadek

17.3 Výpadky uplinků 17.3.1

Výpadek jednoho uplinku managementu po dobu 5 sekund

V případě výpadku uplinků management sítě lze předpokládat, že se síťový výpadek neobjeví, neboť bylo v tomto případě využito za pomocí NIC teamingu redundantního připojení, kterého se v praxi hojně užívá.  V případě platformy VMware nebyl zaregistrován žádný síťový výpadek, vCenter však zobrazil hlášení „Network uplink redundancy lost“ o ztrátě redundantního připojení, které následně bylo odstraněno.  Platforma XenServer se zachovala podobně jako VMware, objevilo se hlášení o pádu redundantního připojení „Bond status has been changed“. Platforma však zůstala funkční.  V případě platformy VMware nebylo testy výpadku jednoho uplinku managementu možné provést, neboť pro správnou funkci HA (high availability) bylo nutné jednu síťovou kartu obětovat pro připojení hardwarového IPMI management serveru, který je pro správnou funkci HA nezbytně nutný. Lze ale předpokládat, že se platforma zachová obdobně jako předchozí dvě. 17.3.2

Výpadek druhého uplinku managementu po dobu 5 sekund

Při těchto výpadcích se platformy zachovaly téměř identicky stejně tak jako při testech výpadků prvního uplinku. Lišily se pouze mírně časy zobrazení jednotlivých alarmů, chod platforem však nebyl narušen. 17.3.3

Výpadek jednoho uplinku managementu po dobu 60 sekund

V případě výpadku jednoho uplinků po dobu 60 sekund se jednotlivé platformy zachovaly totožně, jako při 5sekundovém výpadku. Jediné rozdíly byly v časové prodlevě v zobrazení jednotlivých alarmů, přičemž chod celé platformy i VM nebyl nijak narušen.


17.3.4

84

Výpadek druhého uplinku managementu po dobu 60 sekund

Při testů výpadků druhého uplinku se jednotlivé platformy chovaly identicky jako v případě výpadku prvního uplinku. Mírně se však lišily časy zobrazení jednotlivých alarmů, chod platforem i VM však nebyl narušen. 17.3.5

Výpadek obou uplinků managementu po dobu 5 sekund

 V případě platformy VMware byl zaregistrován cca 7sekundový výpadek hosta. vCenter zobrazil alarmy o ztrátě redundantního připojení k síti i o ztrátě celého připojení k síti, nicméně do chodu jednotlivých virtuálních strojů žádným způsobem nezasáhnul. Platforma se uvedla do plně funkčního stavu po 8 sekundách. Funkce vysoké dostupnosti do chodu nezasáhly.  U platformy XenServer byl zaregistrován výpadek hosta po dobu 6 sekund. XenCenter po 3 sekundách od výpadku zobrazil alarm ohledně ztráty konektivity, avšak síťová konektivita k jednotlivým virtuálním strojům nebyla ovlivněna. XenServer se do konzistentního stavu uvedl po 10 sekundách a funkce vysoké dostupnosti do chodu nezasáhly.  V případě platformy oVirt byla registrována ztráta síťové konektivity po dobu 7 sekund, u ostatních prvků zůstala konektivita zachována. Engine zobrazil upozornění o změně stavu uplinku (down / up), platforma ale zůstala v konzistentním stavu a funkce vysoké dostupnosti do chodu nezasáhly. Tab. 35

Testy výpadků obou uplinků managementu po dobu 5 sekund

Sledovaný prvek

VMware

XenServer

oVirt

Virtuální server




Diskové pole




Host

17.3.6

Výpadek obou uplinků managementu po dobu 60 sekund

 V případě platformy VMware byl evidován 63sekundový výpadek hosta. vCenter po 19 sekundách zobrazil alarm ohledně funkce vysoké dostupnosti. Ve 32. sekundě byl virtuální server C, který měl jeho virtuální disk uložen na lokálním úložišti daného hosta, označen jako nedostupný (failover). Zároveň zafungovala funkce vysoké dostupnosti a jednotlivé VM se v 51. sekundě spustily na druhém hostovi. Celá platforma se včetně plné konektivity uvedla do konzistentního stavu po 1 minutě a 11 sekundách.  Platforma XenServer se při pádu uplinků managementu zachovala obdobně jako při pádu celého hosta. V případě výpadku uplinku managementu master hosta se v XenCenteru odpojil celý cluster, který byl ve 2. minutě od výpadku opět připojen a ve 2:26 začaly VM startovat na novém hostovi a jejich konekti-


85

vita byla obnovena ve 3:05 minutě. V případě výpadku uplinku slave hosta byl po 1:31 host označen jako nedostupný a v 1:37 se začaly VM spouštět na novém hostovi a jejich konektivita se obnovila ve 2:10 minutě. Do konzistentního stavu se platforma uvedla v případě výpadku uplinku master hosta po 3:47 minutách, v případě výpadku uplinku slave hosta po 3:29 minutách.  U platformy oVirt engine po 22 sekundách označil hosta, na kterém vypadla síťová konektivita managementu, jako nedostupného a spustil 61sekundový čekací interval. Vzhledem k tomu, že síťová konektivita byla obnovena dříve, jak po 61 sekundách, HA nezafungovalo a po 1:37 minutě byl host označen jako aktivní a platforma byla opět v plně funkčním stavu. Konektivita k VM zůstala zachována, konektivita k hostovi vypadla po dobu 64 sekund. Funkce vysoké dostupnosti nezafungovaly. Tab. 36

Testy výpadků obou uplinků managementu po dobu 60 sekund

Sledovaný prvek

VMware

Host


Virtuální server


Diskové pole


17.3.7

XenServer ztráta konektivity po dobu 2:24 při pádu slave h. 2:22 při pádu master h. ztráta konektivity po dobu 1:09 při pádu slave h. 2:05 při pádu master h. žádný síťový výpadek

oVirt ztráta konektivity po dobu 64 sekund



Výpadek jednoho uplinku provozní sítě po dobu 5 sekund

 Platforma VMware umožňuje celkem tři režimy NIC Teamingu. V případě že byly oba uplinky nastaveny jako aktivní, nedošlo k žádnému výpadku. V případě, že byl jeden uplink nastaven jako aktivní a druhý unused, došlo při pádu aktivního uplinku k výpadku 6 sekund. Pokud byl jeden uplink nastaven jako aktivní a druhý jako standby, pak došlo k drobnému sekundovému výpadku. vCenter zobrazil upozornění o ztrátě konektivity. Funkce HA do chodu platformy nezasahovaly. V případě výpadku nevyužitých linků platforma zůstala v plně funkčním stavu, v případě výpadku aktivních uplinků se uvedla do konzistentního stavu ihned po obnovení konektivity.  Platforma XenServer umožňuje dva režimy síťové karty (Active-Active a Active-Backup). V obou případech nebyly zaznamenány žádné ztráty konektivity. XenCenter sice zobrazil upozornění o změně stavu uplinku, ale platforma zůstala v konzistentním stavu.


86

 Platforma oVirt se zachovala identicky jako platforma XenServer, nebyly zaznamenány žádné výpadky síťové konektivity a platforma zůstala v konzistentním stavu. 17.3.8

Výpadek jednoho uplinku provozní sítě po dobu 60 sekund

 Platforma VMware se zachovala podobně jako v případě 5sekundového výpadku. vCenter zobrazil po 5 sekundách alarm ohledně potíží s uplinkem. V případě pádu nevyužitých uplinků zůstala platforma v plně funkčním stavu, v případě pádu aktivního uplinku byl zaznamenán výpadek po dobu 63 sekund. Pokud vypadnul záložní uplink došlo ke ztrátě dvou pingů.  V případě platformy XenServer nebyla zaznamenána žádná ztráta konektivity a platforma zůstala v konzistentním stavu. XenServer jen pomocí alarmu upozornil na potíže s uplinkem.  Platforma oVirt se zachovala identicky jako platforma XenServer a zůstala v konzistentním stavu. 17.3.9

Výpadek obou uplinků provozní sítě po dobu 5 sekund

 V případě platformy VMware byl zaznamenán 6sekundový výpadek konektivity VM. vCenter zobrazil alarm o ztrátě redundantní konektivity. Byl narušen pouze provoz VM. Po obnovení konektivity se alarmy odstranily a platforma se uvedla do konzistentního stavu.  U platformy XenServer byla zaznamenán 7sekundový výpadek konektivity VM sítě, XenServer zobrazil varování o změně stavu připojení, funkce vysoké dostupnosti nezafungovaly. Platforma se uvedla po 7 sekundách opět do konzistentního stavu. Funkce vysoké dostupnosti do chodu nezasáhly.  Platforma oVirt se zachovala obdobně jako předchozí dvě platformy. Byl zaznamenán síťový výpadek VM po dobu 7 sekund. Engine zobrazil upozornění o změně stavu linku (down/up). Platforma se uvedla do konzistentního stavu hned po 7 sekundách. Funkce vysoké dostupnosti do chodu nezasáhly. Tab. 37

Testy výpadků obou uplinků provozní sítě po dobu 5 sekund

Sledovaný prvek

VMware

XenServer

oVirt

Host




Virtuální server


ztráta konektivity po dobu 7 sekund.

ztráta konektivity po dobu 8 sekund.

Diskové pole





87

17.3.10 Výpadek obou uplinků provozní sítě po dobu 60 sekund  U platformy VMware došlo k 63sekundovému výpadku VM sítě, funkce vysoké dostupnosti nezasáhly. vCenter zobrazil upozornění o ztrátě konektivity a konektivita byla po 63 sekundách obnovena. Platforma se zároveň ihned uvedla do konzistentního stavu.  XenCenter platformy XenServer zobrazil po 3 sekundách alarm ohledně změny stavu připojení. Funkce HA do chodu platformy nezasahovala. Konektivita k VM byla obnovena po 64 sekundách a platforma se tak uvedla do konzistentního stavu.  V případě platformy oVirt byl zaznamenán výpadek VM sítě po dobu 1 minuty a 3 sekund. Engine zobrazil po 21 sekundách hlášení o změně stavu připojení na „down“ a po 1:15 minutě se stav připojení změnil opět na „up“. Platforma se do konzistentního stavu uvedla po 1:15 minutě. Funkce vysoké dostupnosti nezafungovaly. Tab. 38

Testy výpadků provozní sítě po dobu 60 sekund

Sledovaný prvek Host Virtuální server Diskové pole

VMware

XenServer

oVirt

žádný síťový výpadek ztráta konektivity po dobu 63 sekund

žádný síťový výpadek ztráta konektivity po dobu 64 sekund.

žádný síťový výpadek ztráta konektivity po dobu 63 sekund.




17.4 Výpadek switche 17.4.1

Výpadek switche po dobu 5 sekund

 U platformy VMware byla zaregistrována v 5. sekundě ztráta konektivity u všech sledovaných síťových prvků. Plná konektivita byla obnovena po 15 sekundách od spuštění scriptu, a síťová infrastruktura zůstala funkční.  V případě tohoto XenServeru byla zaregistrována po 2 sekundách ztráta konektivity u všech sledovaných síťových prvků. Plná konektivita byla obnovena po 15 sekundách od spuštění scriptu, a síťová infrastruktura zůstala funkční. VM zůstaly spuštěné, po obnovení konektivity XenCenter zobrazil celkem 7 alarmů ohledně problémů se síťovou konektivitou.  Ztráta konektivity na všechna zařízení ihned. Konektivita obnovena po cca 14 sekundách. Engine se zachoval tak, všechny prvky označil jako nedostupné a začal se k nim postupně připojovat. Zobrazoval i změny stavů linků, všechny prvky byly označeny jako aktivní po cca 55 sekundách.


17.4.2

88

Výpadek switche po dobu 60 sekund

 platforma VMware se zachovala obdobně, jako u 5sekundového výpadku s tím rozdílem, že časová prodleva výpadku byla delší. Ztráta konektivity byla zaregistrována po 3 sekundách a plná konektivita byla obnovena po 1 minutě a 7 sekundách. vCenter po obnovení konektivity zobrazil alarmy o ztrátě redundance a celkové konektivity, tyto alarmy ale ihned byly vypnuty. Neproběhla migrace VM a platforma se uvedla opět do konzistentního stavu.  U platformy XenServer došlo po 58 sekundách k restartování obou hostů. Po 3:27 minutách došlo v XenCenteru k obnovení clusteru a připojení všech aktivních serverů. Teprve až v cca 4:15 minutě se spustily jednotlivé VM a síťová konektivita byla obnovena v 4:49 minutě. 60sekundový výpadek měl tedy bohužel za následek restartu celého clusteru a jeho obnova trvala cca 5 minut.  U platformy oVirt proběhla okamžitá ztráta konektivity po dobu 69 sekund, následně se postupně začala konektivita obnovovat, engine označil všechna zařízení jako nedostupná, začal zobrazovat chybové hlášení ohledně VDSM, ohledně power managementu a IPMI, zkoušel se na hosty opakovaně připojit, což se po 2:01 min povedlo a platforma byla konzistentní.

17.5 Dodatečné testy platformy oVirt Virtualizační platforma oVirt s sebou přináší jednu specifickou věc. Pro správnou funkci vysoké dostupnosti (HA) je nezbytně nutné, aby byl u jednotlivých hypervizorů funkční fyzický management serveru, známý též jako IPMI nebo DRAC. IPMI, známý jako Intelligent Platform Management Interface je rozhraní serveru, pomocí kterého lze k němu přistupovat a nastavovat jej, jako bychom byli fyzicky u něj. Přes toto rozhraní se můžeme dostat do BIOSu (Basic Input Output System) samotného serveru a patřičně jej nastavovat, či ovládat. Jestliže platforma oVirt zjistí, že je některý z hostů offline (nedostupný), začne se pokoušet daného hosta přes zmiňovaný management restartovat, což nemůže v případě nefunkčního managementu provést. Důležitým faktem je, že jednotlivé virtuální stroje se v rámci HA spustí na druhém hostu pouze v případě, zadaří-li se nedostupného hosta přes management restartovat. Tuto skutečnost lze považovat za jakousi pomyslnou ochranu, aby v jednu chvíli neexistovaly na síti funkční dva identické virtuální stroje. (Visakh, 2015, online) Jak je možné si na základě výše provedených testů všimnou, ve většině případů u platformy oVirt funkce vysoké dostupnosti nezasáhly. Z toho důvodu byly provedeny nad rámec testovací metodiky testy výpadků po dobu 180 sekund. Tento čas je volen proto, že dle dokumentace platformy oVirt existuje časový interval 180 sekund pro dokončení VDSM operací (VDSM je daemon, který řídí správu disků, paměti a sítě shromažďuje také logy a statistiky). Dále je v dokumentaci uvedeno, že pokud celý host neodpovídá, trvá nejméně 6 minut, než je daný host odstaven. (oVirt, 2016d, online) V rámci testů bylo vyzkoušeno, jestli funkce vysoké dostupnosti budou v případě nezapojeného IPMI managementu aktivovány. Bohužel, není známo, jest-


89

li je to vlastnost platformy nebo chyba, ale jednotlivé virtuální stroje se nebyly schopny na druhém hostu spustit ani po 10 minutách. Bylo vypozorováno, že engine se opakovaně pokoušel přes IPMI power management problémového hosta opakovaně restartovat avšak neúspěšně. 17.5.1

Výpadek celého hosta po dobu 180 sekund

Engine platformy oVirt po 13 sekundách zobrazil hlášení „heartbeat exceeded“ a 61sekundovou čekací dobu, než se označí jako nedostupný. V 1:23 minutě byl spuštěn IPMI power management a host byl v 1:43 restartován. Následně po potvrzení úspěšného restartování hosta power managementem se jednotlivé VM začaly v 2. minutě spouštět na druhém hostovi. Celá platforma se do konzistentního stavu uvedla cca po 4:03 minutách. Potvrdila se tak výše uvedená informace, že virtuální stroje se nespustí dříve, než je proveden fyzický restart hosta, na němž původně běžely. 17.5.2

Výpadek uplinku managementu po dobu 180 sekund

V tomto případě engine označil problémového hosta jako nedostupného a čekal 61 sekund, jestli se opět nepřipojí. Engine se pokoušel k hostovi několikrát neúspěšně připojit. Ve 2:33 se aktivoval power management a ve 2:47 se host restartoval. VM se začaly na druhém hostovi spouštět ve 3:05 a konektivita k VM se obnovila po 3:33 minutách. Celkově se platforma uvedla do původního, plně funkčního stavu po 5:13 minutách. 17.5.3

Výpadek uplinku VM sítě po dobu 180 sekund

V případě, že vypadla celá „zákaznická“ síť, engine zobrazil po 20 sekundách hlášku o změně stavu linků a celý host se přepnul do non-operational režimu. V 1:26 se jednotlivé VM začaly spouštět na druhém hostovi. Ve 3:37 se inkriminovaný host označil opět jako funkční a platforma se uvedla do plně funkčního stavu po 3 minutách a 37 sekundách.

Zhodnocení platforem

90

18 Zhodnocení platforem 18.1 Celkové shrnutí výsledků testů Na jednotlivých vybraných virtualizačních platformách bylo provedeno několik desítek testů. Především byl měřen výkon procesoru, operační paměti, grafické karty a pevného disku. Mimo tyto komponenty také byla otestována propustnost síťové konektivity i rychlost sítě, kdy byla testována rychlost přenosu sady souborů mezi dvěma VM. Bylo také testováno, jak si jednotlivé platformy poradí se síťovými výpadky. Budeme-li brát v úvahu testy výkonu procesoru, zde si především dobře vedla platforma VMware (pro 1vCPU) a platforma XenServer (pro 4vCPU). Rozdíly výkonu v rámci celkového hodnocení byly 7,3 %. V rámci testů operační paměti si pro změnu nejlépe vedla platforma oVirt, která měla výkonnostní náskok až 12 %. Zejména však výkon této platformy překvapil v testu databázových operací, kde měla oproti virtualizačním platformám VMware a XenServer téměř o čtvrtinu vyšší výkon. Test výkonu grafické karty byl zařazen pro úplnost a v serverovém nasazení má tak úplně minimální váhu. V případě, je-li potřeba provádět nějaké grafické (CUDA) výpočty, byly by provedeny na serverech nebo pracovních stanicích, které obsahují výkonnou dedikovanou grafickou kartu a v tomto případě by byly jednotlivé výsledky mnohem lepší. Zde však podala nejlepší výkon platforma VMware. Jedním z důležitých testů je rychlost samotných disků. Zde si vedla dobře platforma XenServer, která podala nejlepší výsledek ve všech testech provedených aplikací PassMark, to jak při testech VM umístěných na diskovém poli NAS, tak i na lokálním úložišti daného hosta. Výkonnostní rozdíly oproti nejhoršímu dosaženému výsledku v testu byly až 28 %, to v případě latence. Pokud bychom brali v úvahu rozdíly výkonu pouze pro sekvenční čtení a sekvenční zápis dat byly zde rozdíly výkonu maximálně 20 %. Velikým překvapením byly testy propustnosti síťové konektivity, kde byla propustnost sítě v případě síťové komunikace virtuálních strojů umístěných na stejném hostovi (hypervizoru) a ve stejné VLAN síti rychlejší, než je samotná rychlost síťových rozhraní. V případě platformy VMware byla průměrná rychlost 1,15 Gbps, v případě platformy XenServer 2,12 Gbps a překvapila platforma oVirt s rychlostí 3,5 Gbps. Výkonnostní rozdíly tak byly až 65 %. V ostatních testech byla rychlost téměř identická, pohybovala se v rozmezí 900 – 930 Mbps, což by odpovídalo reálnému provozu na 1 Gbps síti. Při testech kopírování sady soborů mezi jednotlivými virtuálními stroji podala opět nejlepší výsledky platforma XenServer, která testovací sadu dat dokázala ve většině případů zkopírovat nejrychleji. Platforma oVirt podala oproti platformě XenServer slabší výsledky, nejslabší výsledky však měla platforma VMware. Výkonnostní rozdíly mezi nejlepším a nejhorším dosaženým výsledkem byly v rozmezí 1 – 43 %.


91

18.2 Výběr virtualizační platformy na základě testů Výběr nejvhodnější virtualizační platformy si můžeme usnadnit pomocí metody vícekriteriálního rozhodování. Každému z testů je určena váha, která udává v celkovém hodnocení jeho důležitost. Výstupem této metody je výsledné hodnocení, které nám pomůže při výběru nejvhodnější platformy. V následující tabulce č. 39 jsou shrnuty celkové výsledky jednotlivých testů. Pro výkonnostní testy procesoru, operační paměti a pevného disku bylo bráno v úvahu celkové hodnocení testů virtuálního stroje s přidělenými 4 vCPU, neboť jednotlivé virtuální stroje v praxi mají přiděleno více, než jedno procesorové jádro. Pro test pevného disku byly brány v úvahu jen výsledky testu rychlosti virtuálního disku umístěného na diskovém poli NAS, neboť v serverovém nasazení se disková pole používají mnohem častěji, než lokální úložiště. V případě testů propustnosti sítě a rychlosti kopírování byl u jednotlivých platforem průměrný výsledek, kterého dosáhly ve všech scénářích daného testu. Do tohoto průměru byly započítány pouze výsledky testů, které byly provedeny na všech třech testovaných platformách, neboť v případě platformy oVirt nebylo možné v rámci jednoho clusteru provést testy s virtuálním diskem umístěným na lokálním úložišti daného hosta. Pro přehlednost je opět nejlepší výsledek vyznačen zelenou barvou, nejslabší výsledek barvou červenou. Tab. 39

Celkové shrnutí výsledků testu CPU, RAM, HDD, GK a LAN

Platforma VMware XenServer oVirt

Test RAM (body) 2735,667 579,167 2884,333 605,500 2672,500 634,167 Test CPU (body)

Test Test Test Test GPU HDD propustnosti kopírování (body) (body) (Mbps) (sec) 180,283 890,667 1038,750 278,000 176,717 1020,167 1519,375 219,000 148,900 935,500 2110,459 247,000

Vzhledem k tomu, že vícekriteriální hodnocení variant metodou váhy kritérií vyžaduje, aby jednotlivá kritéria byla maximalizačního typu, je nutné určit typ jednotlivých kritérií. Je zřejmé, že v případě testů procesoru, operační paměti, grafické karty, rychlosti HDD a propustnosti sítě nás zajímá nejlepší dosažený výsledek, proto jsou kritéria těchto testů maximalizačního typu. Naopak u testu kopírování je pro nás důležitá nejkratší doba zkopírování dat, proto je toto kritérium minimalizačního typu. Minimalizační kritéria je však nutno převést na maximalizační. Převedení minimalizačních kritérií na kritéria maximalizační je provedeno odečtením jednotlivých hodnot daného testu od maximální dosažené hodnoty v daném testu. V následující tabulce č. 40 jsou uvedeny výsledky testů, kde jsou všechna minimalizační kritéria převedena na maximalizační.

Zhodnocení platforem Tab. 40

92

Výsledky jednotlivých testů převedeny na maximalizační kritéria


Test RAM (body) 2735,667 579,167 2884,333 605,500 2672,500 634,167 Test CPU (body)

Test Test Test Test GPU HDD propustnosti kopírování (body) (body) (Mbps) (sec) 180,283 890,667 1038,750 0,000 176,717 1020,167 1519,375 59,000 148,900 935,500 2110,459 31,000

Poslední úpravou je převedení kritérií do normalizační matice, což je provedeno podle vztahu

, kde H je nová hodnota, PH je původní hodnota, MinH je minimální hodnota v daném testu, MaxH je maximální hodnota v daném testu. Minimální a maximální hodnoty dosažené v daném testu jsou uvedeny v následující tabulce. Tab. 41

Minimální a maximální naměřené průměrné hodnoty v daném testu

Platforma MAX MIN

Test Test Test Test Test RAM GPU HDD propustnosti kopírování (body) (body) (body) (Mbps) (sec) 2884,333 634,167 180,283 1020,167 2110,459 59,000 2672,500 579,167 148,900 890,667 1038,750 0,000 Test CPU (body)

V tabulce č. 42 jsou uvedeny vypočtené vektory normalizační matice. Tab. 42

Výpis vektorů normalizační matice

Platforma Test CPU VMware XenServer oVirt

0,298 1,000 0,000

Test RAM 0,000 0,479 1,000

Test GPU 1,000 0,886 0,000

Test HDD 0,000 1,000 0,346

Test Test propustnosti kopírování 0,000 0,000 0,448 1,000 1,000 0,525

V případě, že by jednotlivé provedené testy měly stejnou váhu, součtem kritérií (testů) jednotlivých variant (platforem) získáme celkové hodnocení, na jehož základě získáme pořadí variant, na základě kterého můžeme vybrat tu nejlepší. Jelikož má pro nás každý test jinou váhu, je třeba jednotlivá kritéria ohodnotit váhovým vektorem. Součet jednotlivých vah by měl být v součtu roven jedné. Na základě informaci ÚIT, který sdělil, že současné služby jsou náročné na diskový prostor a jejich využití je plánováno v oblasti serverů, mají pro nás největší


93

váhu testy výkonu pevných disků, testy síťové propustnosti a testy kopírování sady souborů. Těmto testům je tedy přidělena váha 0,25. Naopak nejméně důležitým testem je pro nás výkon grafické karty, proto je ohodnocen váhou 0,05. Test procesoru a operační paměti byl ohodnocen váhou 0,1. V následující tabulce jsou uvedeny jednotlivé testy a jejich váhy. Tab. 43

Váhy jednotlivých testů

Platforma VÁHA

Test CPU 0,1

Test RAM 0,1

Test GPU 0,05

Test HDD 0,25

Test propustnosti 0,25

Test kopírování 0,25

Po provedení ohodnocení jednotlivých vektorů váhovým vektorem získáme nové hodnoty, které jsou uvedeny v tabulce č. 44, jejichž součtem získáme celkové hodnocení dané platformy. Tab. 44

Ohodnocené testy váhovým vektorem


Test CPU 0,030 0,100 0,000

Test RAM 0,000 0,048 0,100

Test GPU 0,050 0,044 0,000

Test Test Test HDD propustnosti kopírování 0,000 0,000 0,000 0,250 0,112 0,250 0,087 0,250 0,131

Σ 0,080 0,804 0,568

Na základě celkového hodnocení v tabulce č. 44 je patrné, že jako nejlepší variantou se jeví platforma XenServer (získala nejvyšší celkový počet bodů). I přesto, že platforma oVirt v případě testů síťové konektivity v některých testech podala až trojnásobný výkon, se umístila na druhém místě. Na posledním místě se umístila platforma VMware. Je však nutné zopakovat skutečnost, že jednotlivé platformy byly testovány na nepodporovaném hardwaru z roku 2007. Pokud by testy byly provedeny na novém hardwaru, mohly by se jednotlivé výsledky lišit, tím i celkové hodnocení testu. Do metody vícekriteriálního rozhodování nebyly zařazeny testy síťových výpadků, neboť se nejedná o přímo měřitelné testy. Výsledky těchto testů jsou získány sledováním a následným popisem chování jednotlivých platforem. Do vícekriteriálního hodnocení také nebyla zahrnuta cena, neboť existuje několik možností způsobů licencování, konečnou cenu v neposlední řadě ovlivňuje i cena podpory a další faktory, jako náklady na zaplacení normohodin daného technika. Z hlediska testů je tedy patrné, že vzhledem k uvedené testovací metodice podala nejlepší výsledky platforma XenServer. Samotné testy také ukázaly, jak si jednotlivé platformy poradí se starším hardwarem, zejména platformy XenServer a oVirt z čehož plyne, že je tyto platformy možné provozovat i na několik let starém hardwaru.

Ekonomické zhodnocení

94

19 Ekonomické zhodnocení Zavádění nové serverové virtualizační infrastruktury je spojeno také s finančními prostředky, které je třeba pro zavedení vynaložit. Především je potřeba nakoupit jednotlivé licence, případně podporu či další aktualizace. Dále je potřeba zaplatit práci technika, který platformy nasazuje. V neposlední řadě je také potřeba jednotlivým správcům zaplatit například školení. V rámci ekonomického zhodnocení budeme předpokládat nasazení virtualizační platformy do serverového clusteru, který parametrově odpovídá nejnovějšímu hardwaru a který je na univerzitě aktuálně v provozu. Tento cluster obsahuje 2 servery použité jako hosty a 1 server použitý jako management server. Jednotlivé servery pak obsahují dva osmijádrové procesory, 256 GB RAM, 512 GB SSD disk a 4 kusy 10 Gbps síťových rozhraní.

19.1 Ekonomické zhodnocení platformy VMware Jak již bylo zmíněno, platforma VMware je placenou platformou, která je nabízena v několika edicích a je potřeba k ní dokupovat podporu a další placené upgrady. Na základě analýzy potřeb Mendelovy univerzity je pro školu plně dostačující platforma vSphere 6 Standard (obsahuje všechny požadované funkce), kde cena jedné licence hypervizoru vyjde na 17 321 Kč a cena jedné licence pro vCenter vyjde na 104 356 Kč. Kromě nákupu licencí pro virtualizační platformu VMware je třeba také zakoupit licenci pro operační systém Windows Server 2012 R2 Standard, který je nezbytně nutný pro provozování vCenter Serveru. Cena licence tohoto operačního systému vychází na 22 599 Kč včetně DPH. (TSBohemia a.s., 2016, online) Mezi další náklady patří zakoupení podpory. Pro platformu vSphere 6 je nutné zakoupení podpory v délce trvání minimálně 1 rok, kdy je třeba zakoupit podporu zvlášť pro hypervizory (jedna licence na jeden procesor) a zvlášť pro vCenter Server (licence na jednu instanci). V neposlední řadě je nutno také započítat náklady za odvedenou práci zaměstnance, který platformu instaluje (normohodiny). Ceny normohodin zaměstnance se v oblasti IT pohybuji v rozmezí 500 – 1000 Kč (ITpartner.cz, 2016, online),(Hardware & Software Services, 2016, online). Vzhledem k odlišným cenám těchto normohodin je brána v úvahu průměrná cena 750 Kč/hod. V následující tabulce je uvedeno ekonomické zhodnocení nasazení platformy VMware. Je potřeba zmínit, že uvedené ceny jsou za akademické licence společnosti Senetic s.r.o. V tabulce č. 45 jsou uvedeny celkové náklady na nasazení platformy VMware vSphere 6 Standard včetně podpory na 1 rok.

Ekonomické zhodnocení Tab. 45

95

Celkové finanční náklady na nasazení platformy VMware včetně podpory na 1 rok

Produkt Licence pro ESXi hypervizor Licence pro vCenter Server Licence pro Windows Server 2012 R2 Práce technika Základní podpora ESXi na 1 rok Základní podpora vCenter na 1 rok

Poč Cena/kus Celkem 4 17 321,00 Kč 69 284,00 Kč 1 104 356,00 Kč 104 356,00 Kč 1 22 599,00 Kč 22 599,00 Kč 4 750,00 Kč 3 000,00 Kč 4 3 705,00 Kč 14 820,00 Kč 1 22 389,00 Kč 22 389,00 Kč

Celková cena

236 448,00 Kč

Za předpokladu, že by univerzita měla zájem zaplatit danému zaměstnanci i základní kurz instalace a konfigurace, je potřeba k celkovým nákladům přičíst 49 000 Kč za 5 denní kurz počítačové školy Gopas (Gopas, a.s., 2016, online). Pak by celkové nasazení platformy VMware včetně proškolení zaměstnance vyšlo na 285.448 Kč. Výše uvedené ekonomické zhodnocení platí pouze v případě zakoupení akademických licencí. V případě, že by škola byla korporací, celková cena by byla mnohem vyšší. Pro zajímavost, celé nasazení v této platformy v nějaké firmě vyšlo na 384 925 Kč bez školení zaměstnance. Pro školu je to tak úspora 148 477 Kč.

19.2 Ekonomické zhodnocení platformy XenServer V případě nasazení platformy XenServer v edici poskytované zdarma jsou veškeré náklady na nasazení této virtualizační platformy spojeny pouze s prací daného technika a zakoupení jedné licence pro jakoukoliv edici operačního systému Windows, který je potřeba pro provozování management aplikace XenCenter. Nákup této licence není nezbytně nutný, neboť XenCenter je možné nainstalovat na jakýkoliv dostupný počítač. Pokud ale univerzita má předplacený program Microsoft MSDNAA, má přístup k licencím v rámci tohoto programu „zdarma“. Tabulce č. 46 jsou uvedeny náklady spojené s nasazením platformy XenServer v edici zdarma. Tab. 46

Celkové finanční náklady na nasazení platformy XenServer

Produkt Licence pro XenServer hypervizor Licence pro XenCenter Licence pro OS Windows 7/8/10 Práce technika Celková cena

Poč 4 1 1 2

Cena/kus - Kč - Kč 3 790,00 Kč 750,00 Kč

Celkem - Kč - Kč 3 790,00 Kč 1 500,00 Kč 5 290,00 Kč

Ekonomické zhodnocení

96

Pokud by univerzita měla zájem danému zaměstnanci zaplatit školení, je nutné připočíst k těmto nákladům 68 970 Kč za 5 denní školení v počítačové škole Gopas (Gopas, a.s., 2016, online). Jiné náklady nejsou s nasazením této platformy spojeny. Pokud by měla univerzita zájem provozovat virtualizační platformu XenServer včetně podpory, bylo by třeba kromě výše uvedených nákladů ještě vynaložit finanční náklady za 4 licence XenServer hypervizoru verze Standard, což by rozpočet navýšilo o 35 316 Kč (4x 8 829 Kč). Celkové nasazení platformy XenServer by tak v případě zakoupení licence s roční podporou vyšlo na 40 606 Kč bez školení zaměstnance.

19.3 Ekonomické zhodnocení platformy oVirt Ze všech tří testovaných virtualizačních platforem jsou náklady spojené s instalací virtualizační platformy oVirt nejnižší. V tomto jsou náklady spojeny pouze se zaplacením normohodin zaměstnance za odvedenou práci. Pro nasazení platformy oVirt je sice potřeba 1 hodina času, nicméně je nutné také počítat s časovou rezervou. Budeme-li brát v úvahu ještě čas pro přípravu hardwaru, instalaci samotné platformy a její následné odladění, z toho důvodu jsou započítány 2 hodiny. V následující tabulce je uvedeno ekonomické zhodnocení nasazení platformy oVirt. Tab. 47

Celkové finanční náklady na nasazení platformy oVirt

Produkt Licence pro oVirt NODE Licence pro oVirt Engine Práce technika Celková cena

Poč 4 1 2

Cena/kus - Kč - Kč 750,00 Kč

Celkem - Kč - Kč 1 500,00 Kč 1 500,00 Kč

Stejně tak jako u přechozích platforem i u platformy oVirt je možné zaplatit zaměstnanci školení. V tomto případě se ale jedná o 4 denní kurz instalace a správy zajišťovaný počítačovou školou Gopas. Tento kurz vychází včetně DPH na 63.000 Kč (Gopas, a.s., 2016, online). Jiné další náklady nejsou pro nasazení platformy oVirt potřeba. Stejně jako v případě platformy XenServer je možnost provozování platformy oVirt v podobně placeného řešení RHEV společnosti RedHat, ke kterému je poskytována podpora. V tomto případě by bylo nutné zakoupit 2 licence (1 licence je určená pro 2 procesorové sockety), kde by v případě verze se standardní podporou 12/5 bylo nutné přičíst náklady ve výši 51 532 Kč (2x 25 766 Kč).

Diskuze

97

20 Diskuze 20.1 Přínos analýzy požadavků Mendelovy univerzity Vzhledem k tomu, že počítačová síť Mendelovy univerzity by se dala srovnat s korporátní sítí, je obtížné jednoduchým způsobem identifikovat samotné požadavky, které jsou počítačovou síť a tím i jednotlivé virtualizační technologie kladeny. Přínosem tedy je úspora času, který by univerzita musela vynaložit pro vykonání analýzy i samotné výstupy z ní. Výstupy samotné analýzy je možné využít pro plánování dalšího konceptu rozvoje síťové virtualizační infrastruktury na univerzitě.

20.2 Přínos výběru technologií pro testování Přínosem výběru virtualizačních platforem pro univerzitu je skutečnost, že i k placeným virtualizačním platformám existuje použitelná open source alternativa, což se ukázalo na základě provedených testů. Open source alternativa dokáže vzhledem ke kladeným požadavkům ze strany univerzity zastat užitnou hodnotu stejně dobře, jako nabízená placená řešení.

20.3 Praktický přínos testovacích metodiky V rámci této diplomové práce byla vytvořena testovací metodika, na základě níž byl u jednotlivých virtualizačních platforem otestován výkon jednotlivých komponent i sítě. Pro testy výkonu sítě a diskového úložiště bylo navrženo několik možných variant, jak mohou být jednotlivé virtuální stroje provozovány a na základě těchto variant byly provedeny rychlostní testy. Tato testovací metodika může být i inspirací pro další testy či jiné práce.

20.4 Přínos kalkulace nákladů na pořízení a údržbu platformy Pokud by univerzita plánovala kompletní zřízení nového virtualizačního clusteru, je ekonomické zhodnocení nákladů pro nasazení jednotlivých platforem jistě přínosem, neboť každá z platforem je jiným způsobem licencovaná, ke každé z platforem je třeba dokupovat například podporu nebo další upgrady. Jedním z přínosů je i důkaz, že provozování virtualizované serverové infrastruktury je možné i s minimální finanční zátěží. Zároveň univerzita ušetří finanční prostředky za analýzu a tím i rozhodovací proces.

20.5 Praktický přínos srovnání jednotlivých platforem Hlavním přínosem srovnání jednotlivých virtualizačních platforem je jejich vzájemné porovnání schopností po výkonnostní i funkční stránce. Každá z platforem

Diskuze

98

disponuje různými technologiemi a tím se i může lišit způsobem využití. Na internetu je možné dohledat spoustu testů, které však byly provedeny mimo serverový hardware. Jednotlivé platformy byly v rámci této diplomové práce otestovány na jednotném serverovém hardwaru v rámci skutečné (byť testovací) serverové infrastruktury. Vzhledem k tomu, že byly platformy testovány na identickém hardwaru, je tím zaručena objektivnost jednotlivých naměřených výsledků. Zároveň tato diplomová práce přináší i testy síťových výpadků a následný popis chování jednotlivých platforem v čase po jejich výpadku.

20.6 Praktický přínos testů sítových výpadků platforem Jestliže si nastudujeme dokumentaci jednotlivých platforem, můžeme zjistit, že u každé z nich je uveden výčet jednotlivých funkcí, které platforma umí, či neumí. V rámci síťových funkcí je uvedeno, zda daná platforma umožňuje funkce vysoké dostupnosti (high availability) či zda umí funkce nepřetržitého chodu (fault tolerance). Nikde už ale není uvedeno, jak se daná platforma při výpadku skutečně zachová. Nepodařilo se dohledat žádný zdroj, ve kterém by byla tato problematika testována. Hlavním přínosem testů síťových výpadků je tedy popis skutečného chování, jak si jednotlivé platformy s výpadky poradily a zda výpadky ustály.

20.7 Dopad na dění na univerzitě Na základě vyjádření vedoucího Ústavu informačních technologií Mendelovy univerzity, Ing. Jiřího Passingera, bylo shledáno závěru, že by bylo pro univerzitu vhodné provozovat současně dvě virtualizační technologie pro případ selhání jedné z nich. Příkladem selhání mohou být například systémové, bezpečnostní a jiné softwarové chyby.

20.8 Doporučení použití platforem Vzhledem k tomu, že platforma VMware na zastaralém nekompatibilním hardwaru nepodala z testovaných virtualizačních platforem nejlepší výsledky, je důležité zdůraznit, že firma typu bankovní instituce nebo burzovní systém si koupí VMware zejména kvůli podpoře Fault Tolerance (FT), kde při výpadku fyzického stroje nedojde k výpadku služby, ale pouze zakolísání v latencích, nedojde ke ztrátě jediného packetu. Přestože je tedy v testech diplomové práce VMware po výkonnostní stránce nejslabší, je to právě kvůli nekompatibilnímu starému hardwaru, který škola měla k dispozici v době psaní diplomové práce na testování, a lepší hardware bohužel k dispozici nebyl. Pokud je cílovou skupinou provozu virtualizační technologie školní instituce, pro kterou výpadek na několik minut v případě ztráty jednoho fyzického stroje téměř nehraje roli a nelze ani kalkulovat, jaký finanční dopad by na výpadek služeb po dobu několika minut měl, lze tedy předpokládat, že je tolerovatelné, aby pro

Diskuze

99

školní instituci mohla služba vypadnout na několik minut bez žádných finančních následků typu „ušlý zisk" nebo „ztráta důvěry u klientů“ a jiné. Nasazovat tedy jakkoliv placenou formu VMware ve školní instituci tedy nemá smysl, zejména z hlediska dlouhodobé udržitelnosti a rozvoje. Z hlediska dlouhodobé udržitelnosti proto dává smysl využít buď XenServer nebo oVirt. Vzhledem k intenzivnímu vývoji oVirtu lze oVirt doporučit spíše za pár let, kdy dojde k ustálení vývoje této platformy, protože zejména instalace základního operačního systému a v něm instalace balíčků oVirtu byla problematická a dokonce i při běžném provozu došlo k několika nepříjemným problémům, které se na jiných platformách nevyskytovaly.

Závěr

100

21 Závěr Cílem této diplomové práce bylo provést porovnání virtualizačních platforem pro potřeby Mendelovy univerzity v Brně. V první části práce je provedena rešerše existující odborné literatury a vzniklých závěrečných prací či dalších publikací ohledně tohoto tématu. Nastudováním této literatury bylo možné získat nové informace z hlediska teorie i praktických věcí. Teoretická část diplomové práce se zaobírá popisem existujících způsobů virtualizace, jejich typů i samotných výhod, kromě samotné virtualizace je zmíněna i problematika pevných disků a samotné síťové infrastruktury. V rámci praktické části byla provedena analýza současného HW i SW vybavení Mendelovy univerzity, na základě které byly vybrány tři virtualizační platformy, které odpovídají její potřebám. Následně byla navržena testovací metodika, pomocí níž byly jednotlivé platformy podrobeny testům výkonu procesoru, operační paměti, grafické karty, diskového úložiště, dále pak byly provedeny testy síťové propustnosti a doby kopírování sady dat. Součástí testovací metodiky jsou i testy síťových výpadků jednotlivých prvků celé virtualizační infrastruktury. Mimo provedení testů je byla také porovnána náročnost nasazení jednotlivých platforem, možnosti jejich správy a ekonomické zhodnocení finančních nákladů, které je potřeba pro jejich nasazení vynaložit. Na základě jednotlivých provedených testů bylo zjištěno, že jednotlivé platformy jsou funkčně velmi podobné a každá z nich má své výhody a nevýhody. Na základě vícekriteriálního hodnocení a zohlednění funkcionality platforem, síťových výpadků a pořizovací ceny byla vybrána nejvhodnější varianta, která nejvíce vyhovuje potřebám univerzity.

Literatura

101

22 Literatura 148APPS.COM: VMware vSphere Mobile Watchlist | Apps | 148Apps [online]. [cit. 2016-12-18]. Dostupné z: http://www.148apps.com/app/792869677/ BOUD, R. Hyper-V network virtualization cookbook : over 20 recipes to ease the creation of new virtual machines in the networing layer using Hyper-V network virtualization. Birmingham: Packt Publishing, 2014. 214 s. ISBN 978-1-78217780-7. BRENDAN GREGG: Brendan´s blog > Virtualization Performance: Zones, KVM, Xen [online]. [cit. 2016-12-28]. Dostupné z: https://www.ovirt.org/document ation/architecture/architecture/ BRYCH, DAVID. Virtualizace serverů. Plzeň, 2016. Diplomová práce. Západočeská univerzita v Plzni. BUREŠ, MICHAL. Testování výkonnosti virtualizačního prostředí Hyper-V. Praha, 2009. Diplomová práce. Bankovní institut vysoká škola Praha. CISCO SYSTEMS, INC.: High Availability Campus Network Design— Routed Access Layer using EIGRP or OSPF [online]. [cit. 2016-12-16]. Dostupné z: http://www.cisco.com/application/pdf/en/us/guest/netsol/ns432/c649/cc migration_09186a00805fccbf.pdf CITRIX SYSTEMS, INC: Documentation [online]. 2016b [cit. 2016-12-28]. Dostupné z: http://xenserver.org/overview-xenserver-open-sourcevirtualization/documentation.html CITRIX SYSTEMS, INC: XenServer VLAN Networking [online]. 2016a [cit. 2016-12-13]. Dostupné z: https://support.citrix.com/article/CTX123489 CNEWS.CZ: Statistika poruchovosti HDD. Toshiba či Seagate odchází méně, WD Red častěji | Cnews.cz [online]. [cit. 2016-12-13]. Dostupné z: http://www.cnews.cz/statistika-poruchovosti-hdd-toshiba-ci-seagateodchazi-mene-wd-red-casteji DUŠEK, LIBOR. Testování výkonnosti virtualizačního prostředí Hyper-V. Brno, 2011. Diplomová práce. Masarykova univerzita. FERBR, DAVID. Porovnání Microsoft Hyper-V a Citrix XenServer. Praha, 2010. Bakalářská práce. Vysoká škola ekonomická v Praze. GOOGLE PLAY: moVirt – Aplikace pro Android ve službě Google Play [online]. 2016 [cit. 2016-12-28]. Dostupné z: https://play.google.com/store/apps/details?id=org .ovirt.mobile.movirt HÁNA, JAN. Vnější paměti a principy jejich činnosti. Brno, 2014. Diplomová práce. Masarykova univerzita. HARDWARE & SOFTWARE SERVICES: Správa počítačových sítí [online]. [cit. 2016-12-28]. Dostupné z: http://www.hsservices.eu/sprava_siti.php HINKLE, MARK. Source Code. In: XenServer | Open Source Virtualization [online]. Fort Lauderdale: Citrix Systems, 2013 [cit. 2016-12-12]. Dostupné z:

Literatura

102

http://xenserver.org/overview-xenserver-open-sourcevirtualization/sourcecode.html HLAVÁČ, MAREK. Serverová konsolidace a virtualizace. Praha, 2014. Diplomová práce. Bankovní institut vysoká škola Praha. HLAVÁČEK, MARTIN. Výkonnost síťové komunikace ve virtuálních prostředích. Brno, 2010. Diplomová práce. Vysoké učení technické v Brně. INTERTECH.CZ: Virtualizace | DATA Intertech s.r.o. [online]. [cit. 2016-12-17]. Dostupné z: http://www.intertech.cz/virtualizace/ ITPARTNER: Ceník [online]. [cit. 2016-12-28]. Dostupné z: http://itpa.cz/ IVY WIGMORE: What is headless server? - Definition from WhatIs.com [online]. [cit. 2016-12-18]. Dostupné z: http://whatis.techtarget.com/definition/headlessserver KLIMEŠ, LUMÍR. Slovník cizích slov. 6., přeprac. a dopl. vyd. Praha: Státní pedagogické nakladatelství, 1998. Odborné slovníky. ISBN 80-7235-023-4. KOPL, FRANTIŠEK. Virtualizace. Praha, 2013. Bakalářská práce. Bankovní institut vysoká škola Praha. KUROSE, J F., ROSS, K W. Počítačové sítě. 1. vyd. Brno: Computer Press, 2014. 622 s. ISBN 978-80-251-3825-0 KYŠOVÁ, KRISTÍNA. Virtualizace podnikového prostředí na platformě VMware. Praha, 2013. Diplomová práce. Bankovní institut vysoká škola Praha. LESOVSKY, A. Getting started with oVirt 3.3 : a practical guide to successfully implementing and calibrating oVirt 3.3, a feature-rich open source server virtualization platform. Birmingham, UK: Packt Publishing, 2013. 123 s. ISBN 978-178328-007-0. LOWE, S., MARSHALL, N. Mastering VMware vSphere 5.5. Sybex, 2013. ISBN 978-1118-66114-7 MICROSOFT.COM: Licencování a ceny systému Windows Server 2016 | Microsoft [online]. [cit. 2016-12-12]. Dostupné z: https://www.microsoft.com/cscz/cloud-platform/windows-server-pricing OPENSTACK.ORG: OpenStack Docs: Configure network bonding [online]. [cit. 2016-1214]. Dostupné z: http://docs.openstack.org/developer/fueldocs/userdocs/fuel-user-guide/configure-environment/nic-bonding-ui.html OVIRT: Architecture - oVirt [online]. 2016c [cit. 2016-12-28]. Dostupné z: https://www.ovirt.org/documentation/architecture/architecture/ OVIRT: Documentation [online]. 2016a [cit. 2016-12-28]. Dostupné z: http://www.ovirt.org/documentation/ OVIRT: ha-timeouts - oVirt [online]. 2016d [cit. 2016-12-29]. Dostupné z: http://www.ovirt.org/documentation/sla/ha-timeouts/ OVIRT: Quick Start Guide [online]. 2016b [cit. 2016-12-09]. Dostupné z: http://www.ovirt.org/documentation/quickstart/quickstart-guide/

Literatura

103

PATKA, LUKÁŠ. Virtualizační technologie. Brno, 2009. Diplomová práce. Masarykova univerzita. PEJŠA, PETR. Virtualizace desktopů v prostředí vysokých škol. Praha, 2012. Diplomová práce. Bankovní institut vysoká škola Praha. POPELKA, DAVID. Virtualizace a optimalizace IT v produkční společnosti. Brno, 2013. Diplomová práce. Vysoké učení technické. POSKOČIL, RADEK. Virtuální prostředí pro potřeby multiplatformního testování. Hradec Králové, 2016. Diplomová práce. Univerzita Hradec Králové. PRECEDENCE TECHNOLOGIES LTD: Precedence Technologies - XenServer [online]. [cit. 2016-12-28]. Dostupné z: https://www.precedence.co.uk/products/citrix/xe nserver/ RED HAT, INC.: MSRP-pricing ~ Red Hat Connect for Business Partners [online]. [cit. 2016-12-19]. Dostupné z: https://partnercenter.force.com/s/MSRPpricing#rhev RUEST, D., RUEST, N. Virtualizace: podrobný průvodce. 1. vyd. Brno: Computer Press, 2010. 408 s. ISBN 978-80-251-2676-9. RUEST, D., RUEST, N. Virtualization: a beginner's guide. New York: McGraw Hill, 2009. Network professional's library. ISBN 007161401X. RYAN MORRIS: Why you should be using Xen Orchestra [online]. [cit. 2016-12-18]. Dostupné z: http://zxcv.us/195/why-you-should-be-using-xen-orchestra/ SALÁK, JAROMÍR. Konsolidace výpočetní techniky na LDF MENDELU. Brno, 2016. Diplomová práce. Mendelova univerzita v Brně. SAMURAJ-CZ.COM: Cisco IOS 21 - EtherChannel, Link Agregation, PAgP, LACP, NIC Teaming < články -> SAMURAJ-cz.com [online]. [cit. 2016-12-14]. Dostupné z: http://www.samuraj-cz.com/clanek/cisco-ios-21-etherchannel-linkagregation-pagp-lacp-nic-teaming/ SEAGATE TECHNOLOGY LLC: BarraCuda and BarraCuda Pro| Seagate [online]. [cit. 2016-12-14]. Dostupné z: http://www.seagate.com/gb/en/internal-harddrives/hdd/barracuda/#specs-3-5 SERVERWATCH.COM: Top 10 Virtualization Technology Companies for 2016 [online]. [cit. 2016-12-12]. Dostupné z: view-source:http://www.serverwatch.com/ser ver-trends/slideshows/top-10-virtualization-technology-companies-for2016.html SIEBERT, ERIC.: What is virtualization?: - Virtualization Pro [online]. [cit. 2016-1214]. Dostupné z: http://itknowledgeexchange.techtarget.com/virtualizationpro/what-is-virtualization/ SLÁDEK, PETR. Disková pole RAID a jejich budoucnost v éře SSD. Praha, 2012. Diplomová práce. Vysoká škola ekonomická v Praze. SOVANET.CZ: Analýza požadavku | Internetová agentura SOVA NET [online]. [cit. 2016-12-17]. Dostupné z: https://www.sovanet.cz/analyza-pozadavku/

Literatura

104

ŠOUN, JAN. Redundance v datových sítích. 2012. Diplomová práce. Vysoká škola ekonomická v Praze. TECHNET.IDNES.CZ: Je řešení cluster pro každého? - iDNES.cz [online]. 2010 [cit. 201701-01]. Dostupné z: http://sdeleni.idnes.cz/je-reseni-cluster-pro-kazdehod2e-/tec_sdeleni.aspx?c=A100517_105452_tec_sdeleni_ahr TECHNET.MICROSOFT.COM: Supported Linux and FreeBSD virtual machines for Hyper-V on Windows [online]. [cit. 2016-12-13]. Dostupné z: https://technet.microsoft.com/en-us/windows-server-docs/compute/hyperv/supported-linux-and-freebsd-virtual-machines-for-hyper-v-on-windows THOMAS DAVIS: Linux Ethernet Bonding Driver HOWTO [online]. 2011 [cit. 2016-1226]. Dostupné z: https://www.kernel.org/doc/Documentation/networking/b onding.txt TRENTON SYSTEMS INC.: Virtualization Replaces Client-Server With Virtual Machines | Trenton Systems Inc. [online]. [cit. 2016-12-28]. Dostupné z: https://www.trentonsystems.com/news/virtualization-replaces-clientserver-with VIRTUALIZATIONSOFTWARE.COM: The Top 5 Enterprise Type 1 Hypervisors You Must Know [online]. [cit. 2016-12-12]. Dostupné z: http://www.virtualizationsoftware.com/top-5-enterprise-type-1hypervisors/ VISAKH S.: How we setup high availability in oVirt cloud system [online]. 2015 [cit. 2016-12-29]. Dostupné z: https://bobcares.com/blog/how-we-setup-highavailability-in-ovirt-cloud-system/ VMWARE, INC.: VMware Compatibility Guide - System Search [online]. 2016a [cit. 2016-1213]. Dostupné z: http://www.vmware.com/resources/compatibility/search.p hp VMWARE, INC: vSphere Installation and Setup [online]. 2016b [cit. 2016-12-28]. Dostupné z: http://pubs.vmware.com/vsphere60/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-60installation-setup-guide.pdf WESTERN DIGITAL CORPORATION: Internal Storage Hard Disk Drives (HDDs) and Solid State Drives (SSDs) | Western Digital (WD) [online]. [cit. 2016-12-14]. Dostupné z: https://www.wdc.com/products/internal-storage.html

Přílohy

105

Přílohy

Obsah CD

A Obsah CD  oVirt

 screeny  testy  VMware  screeny  testy  XenServer  screeny  testy  scripty  sitove_vypadky  kopirovani  propustnost_site

106

Srovnání serverových virtualizačních platforem pro potřeby MENDELU

Recommend Documents