Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky. Návrh a integrace privátního cloudu

Za´padoˇceska´ univerzita v Plzni Fakulta aplikovanyćh vˇed Katedra informatiky a vy´poˇcetn´ı techniky

Diplomov´ a pr´ ace N´ avrh a integrace priv´ atn´ıho cloudu ˇ do prostˇ red´ı ZCU

Plzeˇ n 2014

Václav Martinovsk´ y

Origin´ al zad´ an´ı pr´ ace

Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem diplomovou práci vypracoval samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u.

V Plzni dne 14. kvˇetna 2014 Václav Martinovsk´ y

Podˇ ekov´ an´ı T´ımto bych chtˇel podˇekovat vedouc´ımu práce, Ing. Jiˇr´ımu Siterovi, za poskytnuté odborné rady, vl´ıdn´ y pˇr´ıstup a vˇenovan´ y ˇcas. Dále dˇekuji zamˇestnanc˚ um ˇ Centra informatizace a v´ ypoˇcetn´ı techniky, Ing. Michalovi Svambergovi a Ing. Petru Grolmusovi, za pomoc pˇri realizaci vybran´ ych technick´ ych aspekt˚ u, Ing. Luboˇsi Matˇejkovi z Katedry informatiky a v´ ypoˇcetn´ı techniky za uˇziteˇcné komentáˇre a v neposledn´ı ˇradˇe také Bc. Miriam Sovové za podporu a pˇripom´ınky vedouc´ı k vylepˇsen´ı této práce.

Abstract Design and integration of private cloud into the UWB environment The aim of this work is to prepare a design for the implementation of a private cloud into the environment of University of West Bohemia. In order to achieve this objective is in the theoretical part an overview of current virtualization and cloud computing technologies. Follows an overview of software platforms that meet the requirements and it is selected one, that is used for implementation. The practical part deals with the design and description of the architecture of chosen solution. On the basis of this concept is prepared and launched a test run to confirm the feasibility of the concept. Keywords: virtualization, cloud computing, IaaS, OpenStack, KVM

Abstrakt ˇ N´ avrh a integrace priv´ atn´ıho cloudu do prostˇ red´ı ZCU C´ılem této práce je pˇripravit návrh implementace privátn´ıho cloudu do prostˇred´ı Západoˇceské univerzity v Plzni. Za u ´ˇcelem dosaˇzen´ı tohoto c´ıle je v teoretické ˇca´sti práce provedeno seznámen´ı s technologi´ı virtualizace a s oborem cloud computingu. Následnˇe je zpracován pˇrehled softwarov´ ych platforem, které vyhovuj´ı poˇzadavk˚ um a z nich je vybrána jedna, která je pouˇzita k realizaci. Praktická ˇca´st se zab´ yvá návrhem a popisem architektury zvoleného ˇreˇsen´ı. Na základˇe tohoto návrhu je pak pˇripraven a spuˇstˇen pilotn´ı provoz, kter´ y má za c´ıl potvrdit realizovatelnost konceptu. Kl´ıˇ cov´ a slova: virtualizace, cloud computing, IaaS, OpenStack, KVM

Obsah ´ 1 Uvod 1.1 Specifikace poˇzadavk˚ u . . . . . . . . . . . . . . . . . . . . . . 2 Virtualizace 2.1 Rozˇs´ıˇren´ı, pˇr´ınosy . . . . . . . . . 2.2 Pˇr´ıstupy k virtualizaci . . . . . . 2.2.1 Emulace . . . . . . . . . . 2.2.2 Plná virtualizace . . . . . 2.2.3 Paravirtualizace . . . . . . 2.2.4 Virtualizace na u ´rovni OS 2.3 Virtualizaˇcn´ı systémy . . . . . . . 2.3.1 KVM . . . . . . . . . . . . 2.3.2 XEN . . . . . . . . . . . . 2.3.3 VMware . . . . . . . . . . 2.3.4 Hyper-V . . . . . . . . . . 2.4 Porovnán´ı a v´ ybˇer . . . . . . . . 3 Cloud computing 3.1 Historie . . . . . . . . . . . . . . 3.2 Definice a charakteristika . . . . . 3.3 Dˇelen´ı podle modelu nasazen´ı . . 3.3.1 Public cloud . . . . . . . . 3.3.2 Private cloud . . . . . . . 3.3.3 Hybrid cloud . . . . . . . 3.3.4 Community cloud . . . . . 3.4 Dˇelen´ı podle typu sluˇzby . . . . . 3.4.1 Infrastructure as a Service 3.4.2 Platform as a Service . . . 3.4.3 Software as a Service . . . 3.5 V´ yhody . . . . . . . . . . . . . . 3.6 Obavy, pˇrekáˇzky . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . .

1 1

. . . . . . . . . . . .

3 4 5 6 6 6 7 7 7 8 9 10 10

. . . . . . . . . . . . .

12 12 13 14 15 16 17 17 18 18 19 19 20 21

3.7

Softwarové platformy pro IaaS 3.7.1 Apache CloudStack . . 3.7.2 Eucalyptus . . . . . . 3.7.3 OpenNebula . . . . . . 3.7.4 OpenStack . . . . . . . 3.7.5 Zhodnocen´ı a v´ ybˇer . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

4 Popis a n´ avrh architektury 4.1 Databáze . . . . . . . . . . . . . . . . . . . . . 4.1.1 Návrh a zd˚ uvodnˇen´ı . . . . . . . . . . . 4.2 Keystone: správce identity . . . . . . . . . . . . 4.2.1 Návrh a zd˚ uvodnˇen´ı . . . . . . . . . . . 4.3 Horizon: webov´ y portál . . . . . . . . . . . . . . 4.3.1 Návrh a zd˚ uvodnˇen´ı . . . . . . . . . . . 4.4 Nova: v´ ypoˇcetn´ı uzel . . . . . . . . . . . . . . . 4.4.1 Návrh a zd˚ uvodnˇen´ı . . . . . . . . . . . 4.5 Neutron: s´ıt’ován´ı . . . . . . . . . . . . . . . . . 4.5.1 Návrh a zd˚ uvodnˇen´ı . . . . . . . . . . . 4.6 Cinder: u ´loˇziˇstˇe dat . . . . . . . . . . . . . . . . 4.6.1 Návrh a zd˚ uvodnˇen´ı . . . . . . . . . . . 4.6.2 Tok poˇzadavk˚ u pˇri pˇripojován´ı jednotky 4.7 Glance: katalog obraz˚ u . . . . . . . . . . . . . . 4.7.1 Návrh a zd˚ uvodnˇen´ı . . . . . . . . . . . 4.8 Tok poˇzadavk˚ u pˇri zakládán´ı instance . . . . . . 4.9 Ceilometer: mˇeˇren´ı zdroj˚ u . . . . . . . . . . . . 4.10 Ostatn´ı komponenty . . . . . . . . . . . . . . . 4.10.1 Swift . . . . . . . . . . . . . . . . . . . . 4.10.2 Heat . . . . . . . . . . . . . . . . . . . . ˇ alovatelnost a High Availability . . . . . . . . 4.11 Sk´ 4.11.1 HA pro databázi . . . . . . . . . . . . . 4.11.2 HA pro frontu zpráv . . . . . . . . . . . 4.11.3 HA pro ostatn´ı sluˇzby . . . . . . . . . . 4.11.4 Schéma návrhu kompletn´ıho HA . . . . . 4.12 Zálohovac´ı schéma . . . . . . . . . . . . . . . . 4.12.1 Obnova . . . . . . . . . . . . . . . . . . 4.13 Logován´ı . . . . . . . . . . . . . . . . . . . . . . 4.13.1 Historie IP adres . . . . . . . . . . . . . 4.14 Monitoring . . . . . . . . . . . . . . . . . . . . . 4.14.1 Procesy . . . . . . . . . . . . . . . . . . 4.14.2 Provozn´ı veliˇciny . . . . . . . . . . . . . 4.15 Bezpeˇcnost, hesla . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . .

22 22 22 23 24 27

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30 31 31 31 32 32 32 33 33 33 35 36 37 39 39 40 41 44 45 45 45 46 47 48 49 49 51 52 53 53 54 54 55 56

4.16 Aktualizace systému . . . . . . . . . . . . . . . . . . . . . . . 57 4.17 Moˇznosti pˇr´ıstupu . . . . . . . . . . . . . . . . . . . . . . . . . 58 5 Realizace pilotn´ıho nasazen´ı 5.1 Testovac´ı hardware . . . . . . . . . . . . . . . 5.2 Software . . . . . . . . . . . . . . . . . . . . . 5.2.1 Základn´ı konfigurace . . . . . . . . . . 5.3 Rozloˇzen´ı komponent . . . . . . . . . . . . . . 5.4 Controller node . . . . . . . . . . . . . . . . . 5.4.1 Obrazy server˚ u . . . . . . . . . . . . . 5.5 Storage node . . . . . . . . . . . . . . . . . . 5.6 Networking node . . . . . . . . . . . . . . . . 5.7 Compute node . . . . . . . . . . . . . . . . . . 5.8 Ceilometer . . . . . . . . . . . . . . . . . . . . ´ 5.8.1 Upravy v komponentˇe Cinder . . . . . ´ 5.8.2 Upravy v komponentˇe Glance . . . . . ´ 5.8.3 Upravy v komponentˇe Nova . . . . . . ˇ 5.9 Integrace do prostˇred´ı ZCU . . . . . . . . . . 5.9.1 Digitáln´ı certifikát . . . . . . . . . . . 5.9.2 Kerberos a WebAuth . . . . . . . . . . 5.9.3 Uˇzivatelské u ´ˇcty . . . . . . . . . . . . . 5.10 Ovˇeˇren´ı . . . . . . . . . . . . . . . . . . . . . 5.10.1 Scénáˇr: zaloˇzen´ı a pˇrihláˇsen´ı uˇzivatele . 5.10.2 Scénáˇr: zaloˇzen´ı a spuˇstˇen´ı serveru . . 5.10.3 Scénáˇr: ovˇeˇren´ı funkˇcnosti kvót . . . . 5.10.4 Scénáˇr: spuˇstˇen´ı v´ıce server˚ u najednou 5.10.5 Naplnˇen´ı poˇzadavk˚ u . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

59 59 60 60 61 62 64 65 66 68 68 70 71 71 72 73 74 76 81 81 82 84 84 86

6 Z´ avˇ er

88

Seznam tabulek

89

Seznam obr´ azk˚ u

90

Literatura

92

A Obsah CD

98

´ 1 Uvod Cloud je pravdˇepodobnˇe jedno z nejv´ıce skloˇ novan´ ych slov dneˇsn´ıho svˇeta informaˇcn´ıch technologi´ı. At’ uˇz chceme nebo nechceme, obklopuje naˇse okol´ı a stále v´ıce organizac´ı, firem i jednotlivc˚ u vyuˇz´ıvá v nˇejaké podobˇe cloudov´ ych sluˇzeb. Tato práce si klade za c´ıl pˇripravit návrh infrastruktury privátn´ıho cloudu pro potˇreby Západoˇceské univerzity v Plzni, která chce umoˇznit student˚ um i zamˇestnanc˚ um spouˇstˇet virtuáln´ı stroje pro v´ yukové a v´ yzkumné u ´ˇcely. Prostˇredkem k dosaˇzen´ı tohoto c´ıle je nejprve seznámen´ı s histori´ı a aktua´ln´ım stavem odvˇetv´ı cloud computingu. Neménˇe d˚ uleˇzitou ˇcást´ı je pˇrehled virtualizaˇcn´ıch technologi´ı, na kter´ ych je odvˇetv´ı postaveno a bez kterého si lze tˇeˇzko pˇredstavit tak obrovsk´ y rozmach. Samostatná kapitola je vˇenována porovnán´ı softwaru, kter´ ym lze realizovat privátn´ı cloud. Z této kapitoly vzejde jeden produkt, kter´ y pak bude pouˇzit v návrhu i praktické realizaci. Ned´ılnou souˇcást´ı je i pilotn´ı provoz (Proof of Concept), kter´ ym je prakticky otestována a pˇredvedena realizovatelnost zvoleného ˇreˇsen´ı.

1.1

Specifikace poˇ zadavk˚ u

Tato diplomová práce je zpracovávána ve spolupráci s Centrem informatizace a v´ ypoˇcetn´ı techniky (dále jen CIV“ nebo zadavatel“). Souˇcást´ı je soupis ” ” poˇzadavk˚ u od zadavatele, které by mˇelo v´ ysledné ˇreˇsen´ı splnit. Primárn´ım c´ılem ˇreˇsen´ı je vytvoˇren´ı nové sluˇzby, kterou lze popsat jako samoobsluˇzné zˇrizován´ı virtuáln´ıch server˚ u pro potˇreby v´ yuky a v´ yzkumu. Jako typické pouˇzit´ı oˇcekáváme virtuáln´ı laboratoˇr, kde si uˇzivatel (student) spust´ı krátkodobˇe (hodiny) nˇekolik virtuáln´ıch poˇc´ıtaˇc˚ u propojen´ ych s´ıt´ı. • Uzly budou plnˇe v jeho správˇe a typicky nastartované z pˇripraveného obrazu (napˇr´ıklad klient-server architektura pro laboratorn´ı cviˇcen´ı konfigurace ˇci debugován´ı s´ıt’ového protokolu). ˇ sen´ı mus´ı splˇ • Reˇ novat provozn´ı poˇzadavky v´ ypoˇcetn´ıho prostˇred´ı Orion 1

´ Uvod

Specifikace poˇzadavk˚ u (monitoring, bezpeˇcnost, zálohován´ı) a b´ yt pˇrimˇeˇrenˇe napojené do existuj´ıc´ı infrastruktury (zejména AAI1 , diskov´ y systém, s´ıt’). Konkrétnˇe je tˇreba napojen´ı na bázi uˇzivatel˚ u a pˇr´ıstup vˇsech uˇzivatel˚ u k nové sluˇzbˇe.

• Realizované ˇreˇsen´ı mus´ı umoˇzn ˇovat stanoven´ı limit˚ u na vyuˇzit´ı zdroj˚ u a mˇeˇren´ı vyuˇz´ıván´ı tˇechto zdroj˚ u. • Souˇca´st´ı zadán´ı nen´ı pˇr´ıprava obraz˚ u virtuáln´ıch server˚ u, ale zvolené ˇreˇsen´ı mus´ı podporovat práci s obrazy (import z jin´ ych prostˇred´ı, podpora kontextualizace, podpora r˚ uzn´ ych operaˇcn´ıch systém˚ u). • Preferujeme otevˇrené ˇreˇsen´ı bez licenˇcn´ıch omezen´ı a poplatk˚ u, modulárn´ı a zaloˇzené na standardech. D˚ uleˇzit´ ym parametrem je malá provozn´ı nároˇcnost a moˇznost rozˇsiˇrován´ı (kapacita, vlastnosti). • V´ yhodou je pouˇzit´ı v souˇcasnosti uˇz´ıvan´ ych ˇreˇsen´ı a technologi´ı.

1

Authentication and Authorisation Infrastructure

2

2 Virtualizace Virtualizace pˇredstavuje mezivrstvu mezi hostitelsk´ ym systémem a hostovan´ ym systémem. Fyzické zdroje, mezi které patˇr´ı zejména pamˇet’, procesor, disk, s´ıt’ová karta jsou virtualizovány a dále poskytnuty hostovanému systému (obr. 2.1), na kterém bˇeˇz´ı samostatn´ y operaˇcn´ı systém (dále jen OS). Ten takto pˇridˇelené zdroje vn´ımá, jako by byly fyzické a vyhrazené. O správu se stará tzv. virtualizaˇcn´ı manager, ˇcasto také oznaˇcovan´ y jako hypervizor.

Obrázek 2.1: Znázornˇen´ı virtualizace hardware Zdroj: vlastn´ı zpracov´ an´ı

V roce 1974 publikovali Popel a Goldberg ˇclánek, ve kterém rozdˇelili hypervizory na 2 základn´ı typy, coˇz ilustruje obr. 2.2: [42] • Typ 1 (nativn´ı, bare-metal) – hypervizor je spuˇstˇen pˇr´ımo na hardware, kde tvoˇr´ı mezivrstvu mezi hostovan´ ymi operaˇcn´ımi systémy a fyzick´ ymi prostˇredky. • Typ 2 (hostovan´ y, hosted) – na hardware je spuˇstˇen klasick´ y operaˇcn´ı systém a hypervizor je nainstalován jako souˇcást tohoto OS. Oproti prvn´ımu typu je zde tedy nav´ıc jedna vrstva. 3

Virtualizace

Rozˇs´ıˇren´ı, pˇr´ınosy

Obrázek 2.2: Ilustrace hypervizor˚ u typu 1 a 2 Zdroj: vlastn´ı zpracov´ an´ı

Pˇr´ıkladem prvn´ıho typu je napˇr. VMware ESX, Microsoft Hyper-V ˇci Citrix XenServer. Do druhého typu ˇrad´ıme VMware Workstation a VirtualBox. Ne vˇzdy je ale klasifikace typu jasná. Napˇr´ıklad KVM i XEN potˇrebuj´ı pro sv˚ uj bˇeh operaˇcn´ı systém (coˇz by naznaˇcovalo, ˇze jsou typu 2), ale jsou povaˇzovány za hypervizory typu 1, protoˇze jejich kód pracuje s hardwarem na stejné u ´rovni jako jádro (kernel).

2.1

Rozˇ s´ıˇ ren´ı, pˇ r´ınosy

Aˇckoliv koncept virtualizace sahá do 60. let 20. stolet´ı k IBM a jeho operaˇcn´ımu systému CP-40, opravdov´ y rozmach a ˇsirˇs´ıho produkˇcn´ıho nasazen´ı se virtualizace doˇckala aˇz v novém tis´ıcilet´ı. Letoˇsn´ı rozsáhlá studie firmy Kapsch [47] s názvem Trendy a výzvy ICT ve stˇredn´ı a východn´ı Evropˇe ukázala, ˇze nˇejakou formu virtualizace vyuˇz´ıvá 58 % ˇcesk´ ych firem, pˇriˇcemˇz z této ˇcásti se jedná z 90 % o virtualizaci server˚ u a datov´ ych center. D˚ uvody rozˇs´ıˇren´ı jsou zejména:

4

Virtualizace

Pˇr´ıstupy k virtualizaci

• Konsolidace, pˇri které docház´ı ke sluˇcován´ı v´ıce fyzick´ ych server˚ u do virtuáln´ıho prostˇred´ı. C´ılem je zejména u ´spora, protoˇze zkuˇsenosti z praxe ukazuj´ı, ˇze v nevirtualizovaném prostˇred´ı jsou servery zat´ıˇzeny pouze na zlomek své kapacity. Pˇr´ıkladem je Amazon, kter´ y namˇeˇril pouze 10% pr˚ umˇernou zátˇeˇz. [25] Konsolidace vede k lepˇs´ımu vyuˇzit´ı zdroj˚ u a tedy u ´sporám jak pˇri nákupu hardware, tak pˇri provozu (servis, elektˇrina, chlazen´ı, . . . ). • Zv´ yˇ sen´ı dostupnosti pomoc´ı High Availability ˇreˇsen´ı, která vytváˇr´ı virtuáln´ı clustery s vyvaˇzován´ım zátˇeˇze. Vˇetˇsina virtualizaˇcn´ıch technologi´ı umoˇzn ˇuje provádˇet ˇzivou migraci1 , d´ıky ˇcemuˇz lze bezproblémovˇe stˇehovat servery po dostupné fyzické architektuˇre (napˇr. kv˚ uli plánované u ´drˇzbˇe hardware). • Izolace, d´ıky které lze provozovat na jednom fyzickém serveru i vzájemnˇe nekompatibiln´ı sluˇzby nebo sluˇzby vyˇzaduj´ıc´ı specifické prostˇred´ı, které by jinak ovlivnilo ostatn´ı aplikace. Dále pˇrisp´ıvá k vyˇsˇs´ı bezpeˇcnosti dat d´ıky d˚ uslednému oddˇelen´ı jednotliv´ ych prostˇred´ı. • Testov´ an´ı nov´ ych verz´ı aplikac´ı nebo sluˇzeb lze realizovat velmi snadno d´ıky moˇznosti naklonovat virtuáln´ı server a na nˇem naneˇcisto“ vy” zkouˇset, jak se bude chovat po aktualizaci. Dalˇs´ım scénáˇrem m˚ uˇze b´ yt situace, kdy potˇrebujeme otestovat aplikaci na velké ˇskále r˚ uzn´ ych operaˇcn´ıch systém˚ u, k ˇcemuˇz bychom jinak potˇrebovali velké mnoˇzstv´ı fyzick´ ych server˚ u. • Z´ alohov´ an´ı lze velmi snadno provádˇet pomoc´ı tzv. snapshot˚ u (binárn´ıch obraz˚ u souborového systému), d´ıky kter´ ym m˚ uˇzeme velmi rychle obnovit stav serveru k urˇcitému okamˇziku.

2.2

Pˇ r´ıstupy k virtualizaci

Tato podkapitola pˇredstav´ı základn´ı virtualizaˇcn´ı techniky od emulace aˇz po virtualizaci na u ´rovni operaˇcn´ıho systému. U kaˇzdého pˇr´ıstupu bude proveden krátk´ y popis a zm´ınˇen pˇr´ıklad konkrétn´ı technologie, kter´ y reprezentuje nasazen´ı dané techniky v praxi. 1ˇ

Ziv´ a migrace virtu´ aln´ıch server˚ u je základn´ı vlastnost virtualizace, která umoˇzn ˇuje pˇresun spuˇstˇeného virtu´ aln´ıho serveru z jednoho fyzického serveru na druh´ y bez pˇreruˇsen´ı. [9]

5

Virtualizace

2.2.1

Pˇr´ıstupy k virtualizaci

Emulace

Emulace umoˇzn ˇuje provozovat virtuáln´ı systém jiné architektury, neˇz je hostitelsk´ y systém (lze tak provozovat napˇr. Windows na PowerPC2 ). Je vˇsak nutné veˇskeré operace interpretovat, coˇz má velmi negativn´ı vliv na v´ ykon. I vzhledem k tomuto faktu je vyuˇz´ıvána sp´ıˇse okrajovˇe pro velmi specifické pˇr´ıpady. Pˇr´ıkladem je emulátor QEMU3 .

2.2.2

Pln´ a virtualizace

V pˇr´ıpadˇe plné virtualizace m˚ uˇzeme provozovat na hostiteli operaˇcn´ı systémy bez nutnosti je jakkoliv upravovat. Pro bˇeh je nutná hardwarová podpora procesoru, v pˇr´ıpadˇe Intelu se jedná o technologii Intel VT a u AMD jde o AMD-V. Ovˇeˇren´ı jestli procesor hardwarovˇe podporuje virtualizaci provedeme (pod Linuxem) pˇr´ıkazem: egrep ’(vmx|svm)’ /proc/cpuinfo Pokud je virtualizace podporována, v´ ystupem bude VMX (pro Intel) nebo SVM (pro AMD). Do této skupiny ˇrad´ıme vˇetˇsinu nejpouˇz´ıvanˇejˇs´ıch systém˚ u, zejména VMware, Hyper-V, KVM a také XEN (bliˇzˇs´ı popis v kap. 2.3).

2.2.3

Paravirtualizace

Pˇri paravirtualizaci je hostovanému systému poskytnuto jen ˇcásteˇcnˇe virtualizované prostˇred´ı. Je nezbytnˇe nutné, aby toto podporoval virtualizovan´ y OS. V´ yhodou je vyˇsˇs´ı rychlost neˇz u plné virtualizace (testovac´ı benchmark4 uvád´ı rozd´ıl cca. 3 %). Typick´ ym zástupcem je XEN5 , kter´ y umoˇzn ˇuje bud’ plnou virtualizaci nebo paravirtualizaci – proto je uveden v obou kategori´ıch. 2

Detaily na: http://www.microsoft.com/australia/office/mac/virtualpc7/ V´ıce informac´ı o emul´ atoru na: http://www.qemu.org/ 4 http://shortrecipes.blogspot.cz/2009/03/xen-performance-of-full-virtualization. html 5 V´ıce v samostatné kap. 2.3.2. 3

6

Virtualizace

2.2.4

Virtualizaˇcn´ı systémy

Virtualizace na u ´ rovni OS

Technika je postavena na sd´ılen´ı modifikovaného linuxového jádra mezi hostovan´ ym a hostitelsk´ ym systémem. Virtuáln´ı servery jsou oznaˇcovány jako kontejnery a nedocház´ı k virtualizaci hardware – nen´ı k dispozici vlastn´ı s´ıt’ová karta ani samostatná disková jednotka (souborov´ y systém je sd´ılen s hostitelsk´ ym systémem a ohraniˇcen kvótami), procesy vˇsech hostovan´ ych systém˚ u jsou vidˇet z hostitelského OS. Jednotlivé virtuáln´ı servery jsou ale od sebe oddˇeleny a nen´ı moˇzno se navzájem ovlivˇ novat. V´ yhodou je velmi n´ızká reˇzie a moˇznost server˚ um pˇridˇelit v´ıce zdroj˚ u, neˇz je fyzicky k dispozici. Nev´ yhodou je moˇznost takto provozovat pouze linuxové distribuce. Mezi zástupce patˇr´ı zejména OpenVZ6 a Linux-VServer.

2.3

Virtualizaˇ cn´ı syst´ emy

Tato kapitola se zab´ yvá pˇrehledem nejv´ yznamnˇejˇs´ıch virtualizaˇcn´ıch systém˚ u dneˇska – KVM, XEN, VMware a Hyper-V. Tyto systémy budou podrobnˇeji pˇredstaveny a v závˇereˇcné podkapitole bude zvolen jeden systém, kter´ y bude pouˇzit pro praktickou ˇca´st.

2.3.1

KVM

KVM (Kernel-based Virtual Machine) je open-source7 virtualizaˇcn´ı ˇreˇsen´ı pro platformu Linux na architektuˇre x86, které poskytuje plnou virtualizaci (pomoc´ı modifikovaného emulátoru QEMU) a pracuje s rozˇs´ıˇren´ımi Intel VT a AMD-V. Ke svému bˇehu tedy potˇrebuje kromˇe Linuxu také procesor s danou instrukˇcn´ı sadou. [30] Pˇr´ımo linuxové jádro zajiˇst’uje sluˇzbu hypervizora, kter´ y poskytuje virtualizovan´ y hardware spuˇstˇen´ ym virtuáln´ım server˚ um. M˚ uˇzeme tak mluvit o hypervizoru typu 1 (bare-metal). 6 7

Detaily na: http://openvz.org/ Poˇc´ıtaˇcov´ y software s otevˇren´ ym zdrojov´ ym kódem.

7

Virtualizace


Nen´ı tˇreba modifikovat hostovan´ y operaˇcn´ı systém a d´ıky tomu lze spouˇstˇet r˚ uzné operaˇcn´ı systémy (Linux, Windows, ...), je podporována ˇzivá migrace virtuáln´ıch server˚ u. P˚ uvodnˇe byl vyv´ıjen firmou Qumranet, kterou ná8 slednˇe koupil Red Hat a na KVM postavil sv˚ uj produkt Red Hat Enterprise Virtualization9 . Vznikl v roce 2006 a je standardn´ı souˇca´st´ı linuxového jádra od roku 2007 (verze 2.6.20). V souˇcasné dobˇe se jedná o vyspˇelou technologii a je ˇcasto nasazovan´ ym open-source hypervizorem. D´ıky svému pozdn´ımu uveden´ı, kdy jiˇz byly dostupné instrukˇcn´ı sady procesor˚ u pro podporu virtualizace, je KVM koncepˇcnˇe velmi prost´ y. Zat´ımco hypervizor VMware obsahuje pˇres 6 milion˚ u ˇra´dk˚ u kódu a Xen okolo 500 tis´ıc, prvn´ı stabiln´ı verze KVM obsahovala jen nˇeco málo pˇres 10 000 rádk˚ u kódu. [17] Právˇe d´ıky této historii a velmi rychlému zaˇrazen´ı do linuxového jádra se ˇrada v´ yvojáˇr˚ u domn´ıvá, ˇze KVM pˇredstavuje budoucnost open-source virtualizace. Spoleˇcnosti jako Red Hat a SuSE daly pˇrednost KVM pˇred XENem.

2.3.2

XEN

P˚ uvodnˇe vznikl jako projekt na univeritˇe v Cambridge a v roce 2003 byla vydána prvn´ı veˇrejná verze. Dnes je vyv´ıjen jako open-source pod licenc´ı GPL2. Bˇehem roku 2011, tedy po v´ıce neˇz 8 letech, se s nástupem kernelu 3.0 doˇckal zaˇrazen´ı do linuxového jádra. Správu procesoru a pamˇeti zajiˇst’uje hypervizor, ostatn´ı zaˇr´ızen´ı spravuje prigilegovan´ y virtuáln´ı systém, kter´ y oznaˇcujeme jako Dom0. Podporuje ˇzivou migraci virtuáln´ıch server˚ u a um´ı pracovat ve dvou reˇzimech: • Paravirtualizace (PV) – pˇri paravirtualizaci nen´ı nutná podpora CPU, avˇsak virtualizovan´ y systém vyˇzaduje m´ıt jádro a ovladaˇce podporuj´ıc´ı PV. V praxi je jako hostovan´ y systém podporován kaˇzd´ y Linux s jádrem 2.6.24 a novˇejˇs´ım. • Pln´ a virtualizace (HVM) – dostupná od verze 3.0, vyˇzaduje podporu CPU, vyuˇz´ıvá QEMU (podobnˇe jako KVM) na emulaci hardware (BIOS, IDE, VGA, USB, s´ıt’ová karta, . . . ). Nen´ı vyˇzadována spolupráce hostitelského systému. 8 9

V´ıce informac´ı o slouˇcen´ı na: http://www.redhat.com/promo/qumranet/ Detaily: http://www.redhat.com/products/cloud-computing/virtualization/

8

Virtualizace

2.3.3


VMware

Spoleˇcnost VMware se virtualizac´ı zab´ yvá jiˇz od roku 1998, pˇriˇcemˇz prvn´ı verze hypervizoru ESX byla vydána v roce 2001. Skládá se z vlastn´ıho jádra vmkernel a servisn´ı konzole, pˇriˇcemˇz ovladaˇce ostatn´ıch zaˇr´ızen´ı, které jsou odvozeny z ovladaˇc˚ u pro OS Linux, jsou také souˇcást´ı hypervizoru. Jelikoˇz nepotˇrebuje k bˇehu jin´ y operaˇcn´ı systém, oznaˇcujeme ho jako typ 1. [41] Velkou v´ yhodou jsou pokroˇcilé funkce s pamˇet´ı RAM10 , kdy je vyuˇz´ıváno situace, ˇze virtuáln´ı servery málokdy alokuj´ı veˇskerou pˇridˇelenou RAM. Hypervizor ESX umoˇzn ˇuje pˇridˇelit server˚ um v souˇctu v´ıce pamˇeti, neˇz je na serveru dostupné. Obr. 2.3 ilustruje, jak hypervizor do 4 GB fyzické pamˇeti ukládá bloky pamˇeti z virtuáln´ıch server˚ u.

Obrázek 2.3: Práce s pamˇet´ı u VMware ESX Zdroj: [54]

V´ yˇse uvedené ˇreˇsen´ı je pak jeˇstˇe vylepˇseno technologi´ı Transparent Page Sharing (TPS), která vyuˇz´ıvá faktu, ˇze spuˇstˇené virtuáln´ı servery maj´ı ˇcasto v pamˇeti identické bloky (stejné aplikace, stejn´ y OS, . . . ). D´ıky této technologii jsou eliminovány duplicity a ve fyzické pamˇeti jsou uloˇzeny identické bloky jen jednou. [54] Jde o komerˇcn´ı software, jehoˇz cena se pohybuje v ˇrádech tis´ıcovek EUR. Vzhledem ke své historii a technické vyspˇelosti je velmi siln´ ym hráˇcem na trhu virtualizace. VMware je populárn´ı pˇredevˇs´ım mezi takov´ ymi zákazn´ıky, kter´ ym záleˇz´ı mnohem v´ıc na znaˇcce, záruce a komerˇcn´ı podpoˇre neˇz na cenˇe ˇreˇsen´ı. [17] VMware dává k dispozici zdarma vSphere Hypervisor11 , kter´ y umoˇzn ˇuje 10 11

Random-Access Memory Detaily zde: http://www.vmware.com/cz/products/vsphere-hypervisor/

9

Virtualizace

Porovnán´ı a výbˇer

provozovat virtualizaci v omezeném rozsahu (nefunkˇcn´ı ˇzivá migrace, omezen´ı na poˇcet jader CPU, omezen´ı na velikost pamˇeti RAM).

2.3.4

Hyper-V

Hyper-V je virtualizaˇcn´ı technologie Microsoftu s hypervizorem typu 1, která umoˇzn ˇuje plnou virtualizaci a paravirtualizaci. Prvn´ı verze byla vydána v roce 2008 (coˇz z n´ı ˇcin´ı nejmladˇs´ı srovnávanou technologii) a je k dispozici bud’ jako souˇca´st produktu Windows Server (2008 i 2012) nebo jako samostatn´ y OS Hyper-V Server (2008 i 2012). Jak je patrné, jde o komerˇcn´ı produkt a bˇeˇzná licence Windows Server 2012 R2 Datacenter stoj´ı 6155 USD12 (cena platná v dubnu 2014). Samotn´ y Hyper-V Server je dostupn´ y zdarma, avˇsak bez jak´ ychkoliv nástroj˚ u pro správu a bez uˇzivatelského rozhran´ı – je moˇzná pouze vzdálená správa, avˇsak nástroje pro správu od Microsoftu jsou placené.

2.4

Porovn´ an´ı a v´ ybˇ er

IBM publikovala studii o virtualizaci [27], ve které zjiˇst’uje náklady TCO13 na 3 roky provozu u enterprise ˇreˇsen´ı virtualizac´ı. Bylo srovnáváno KVM, VMware a Microsoft Hyper-V. V´ ysledkem je, ˇze aˇckoliv byla u KVM zahrnuta cena licenc´ı pro Red Hat Enterprise Linux a IBM Systems Director (kter´ y by se dal v naˇsem kontextu povaˇzovat za zbytn´ y), stále vycház´ı v celkovém TCO levnˇeji neˇz srovnatelná konkurence. Dá se oˇcekávat, ˇze náklady pro XEN budou na podobné u ´rovni jako pro KVM. Zadavatel ve sv´ ych poˇzadavc´ıch specifikoval pˇrań´ı, aby zvolené ˇreˇsen´ı nebylo zat´ıˇzeno licenˇcn´ımi poplatky a omezen´ımi. Pokud ho budeme respektovat, je nutné ze srovnán´ı vyˇradit VMware i Hyper-V (které sice maj´ı také verze zdarma, ale jsou omezené). I kdyby tento poˇzadavek neexistoval, na základˇe v´ yˇse uvedeného porovnán´ı vypl´ yvá, ˇze by tyto technologie nebyly ekonomicky v´ yhodné. 12

http://www.microsoft.com/en-us/server-cloud/products/ windows-server-2012-r2/buy.aspx 13 Total Cost of Ownership

10

Virtualizace

Porovnán´ı a výbˇer

Obrázek 2.4: Srovnán´ı 3letého TCO u zvolen´ ych virtualizaˇcn´ıch technologi´ı Zdroj: [27]

Zb´ yvá se tedy rozhodnout mezi KVM a XEN. V dneˇsn´ı dobˇe jsou obˇe technologie na velmi podobné technické u ´rovni, avˇsak pro KVM hovoˇr´ı fakt, ˇze je jiˇz 7 let standardn´ı souˇcást´ı linuxového jádra a to mu zaruˇcuje ˇsirokou podporu napˇr´ıˇc r˚ uzn´ ymi distribucemi. Komunity firem i uˇzivatel˚ u také dávaj´ı stále ˇcastˇeji pˇrednost KVM pˇred XENem. [17] Autor této práce doporuˇcuje zvolit KVM jako virtualizaˇcn´ı technologii pro pouˇzit´ı v praktické ˇcásti.

11

3 Cloud computing V této kapitole bude pˇredstavena historie a definovány základn´ı pojmy z oblasti cloud computingu. Budou zde také rozebrány modely nasazen´ı cloudu a popsány sluˇzby, které m˚ uˇze poskytovat. Samostatná podkapitola je pak vˇenována v´ yhodám, obavám a pˇrekáˇzkám pˇri vyuˇz´ıván´ı cloudu. Závˇereˇcná ˇcást podává pˇrehled softwarov´ ych platforem pro ˇr´ızen´ı cloudu, je provedeno jejich zhodnocen´ı a zvoleno ˇreˇsen´ı k implementaci v praktické ˇcásti.

3.1

Historie

Myˇslenka sd´ılen´ı v´ ypoˇcetn´ıch sluˇzeb pˇres poˇc´ıtaˇcovou s´ıt’ sahá aˇz do 60. let 20. stolet´ı, kdy byly v´ ypoˇcetn´ı sluˇzby poskytovány na sálov´ ych poˇc´ıtaˇc´ıch (mainframech) vybrané skupinˇe uˇzivatel˚ u, kteˇr´ı se dˇelili o v´ ypoˇcetn´ı ˇcas. Profesor John McCarthy v roce 1961 vyslovil na své pˇrednáˇsce názor, ˇze (poˇc´ıtaˇcové) v´ ypoˇcty mohou b´ yt v budoucnu poskytovány jako veˇrejná ” sluˇzba stejnˇe jako telefon“ [20] a také prvnˇe pouˇzil pojem utility computing. V roce 1966 publikoval Douglas F. Parkhill knihu The Challenge of the Computer Utility, ve které poskytován´ı v´ ypoˇcetn´ıho v´ ykonu pˇres s´ıt’ pˇrirovnává k poskytován´ı elektrické energie. Domácnosti a firmy potˇrebuj´ı elektrickou energii, avˇsak témˇeˇr nikdo si kv˚ uli této potˇrebˇe nebude poˇrizovat vlastn´ı elektrárnu. V této dobˇe vˇsak ˇslo vesmˇes o vizionáˇrské myˇslenky, které nebylo moˇzné vzhledem ke stavu infrastruktury realizovat. [40] Po vypuknut´ı internetové horeˇcky1 na pˇrelomu tis´ıcilet´ı sehrála kl´ıˇcovou roli ve v´ yvoji spoleˇcnost Amazon, která provedla zásadn´ı modernizaci sv´ ych datov´ ych center. Zjistila totiˇz, ˇze po vˇetˇsinu ˇcasu bylo vyuˇz´ıváno cca. jen 10 % instalované v´ ypoˇcetn´ı kapacity a zbytek z˚ ustával nevyuˇzit pro pokryt´ı ˇspiˇcek. [25] Vyvinula a v roce 2006 oficiálnˇe spustila platformu Amazon Web Services (AWS), která poskytuje v´ ypoˇcetn´ı v´ ykon ˇsiroké veˇrejnosti. [1] Cloud zaˇc´ıná nab´ızet stále v´ıce firem, v roce 2011 oznamuje IBM spuˇstˇen´ı 1

Oznaˇcen´ı pro obdob´ı hromadného rozkvˇetu internetov´ ych firem, které nemˇely promyˇslen´ y obchodn´ı model a brzy zkrachovaly. Toto obdob´ı prob´ıhalo pˇribliˇznˇe v letech 1996 aˇz 2001.

12

Cloud computing

Definice a charakteristika

IBM SmartCloud2 a o rok pozdˇeji Oracle spouˇst´ı sv˚ uj Oracle Cloud3 . V posledn´ıch letech roste odvˇetv´ı tempem pˇres 10 % p.a. [18]

3.2

Definice a charakteristika

Pojem cloud computing (dále jen CC) poprvé definoval v roce 1997 prof. Chellappa jako v´ ypoˇcetn´ı paradigma, jehoˇz hranice budou urˇceny sp´ıˇse eko” nomick´ ymi, neˇz technick´ ymi limity.“ [8] Inˇzen´ yˇri z Kalifornské univerzity v Berkeley pˇriˇsli v roce 2009 s mnohem obsáhlejˇs´ı definic´ı. Term´ın Cloud Computing odkazuje jak na aplikace po” skytované jako sluˇzby pˇres Internet, tak na hardware a systémov´ y software v datacentrech, které tyto sluˇzby poskytuj´ı. Samotné sluˇzby jsou oznaˇcovány jako Software jako sluˇzba (Software as a Service; SaaS), term´ınem Cloud oznaˇcujeme samotn´ y hardware a software v datacentrech. Pokud je Cloud nab´ızen v reˇzimu pay-as-you-go ˇsiroké veˇrejnosti, naz´ yváme ho Veˇrejným cloudem (Public cloud), pˇriˇcemˇz samotnou pronaj´ımanou sluˇzbu oznaˇcujeme jako Utility Computing. Term´ın Privátn´ı cloud (Private cloud) pouˇz´ıváme pro datacentra firem ˇci organizac´ı, které nejsou nab´ızena ˇsiroké veˇrejnosti. Cloud Computing se dá vyjádˇrit jako souˇcet SaaS a Utility Computing.“ [2] Zat´ımco definice utility computingu neobsahovala ˇzádnou zm´ınku o u ´platném provozu, témˇeˇr vˇsechny definice CC jiˇz zahrnuj´ı model plateb pay-asyou-go (ˇci pay-per-use). Tedy model, kdy uˇzivatel plat´ı pouze za skuteˇcnˇe spotˇrebované prostˇredky (v´ ypoˇcetn´ı v´ ykon, objem uloˇzen´ ych dat, . . . ). Finanˇcn´ı aspekt zd˚ urazˇ nuje Reese [44], kter´ y uvád´ı tyto parametry: • Sluˇzba je pˇr´ıstupná pˇres webov´ y prohl´ıˇzeˇc nebo webové API4 . • Pro spuˇstˇen´ı sluˇzby nen´ı nutné m´ıt poˇca´teˇcn´ı kapitál. • Plat´ı se pouze za spotˇrebované zdroje. Americk´ y NIST (National Institute of Standards and Technology), zavedl definici [32] cloud computingu, která je uznávána vládou USA: 2

Detaily na: http://www.ibm.com/cloud-computing/us/en/ V´ıce na: https://cloud.oracle.com 4 Application Programming Interface 3

13

Cloud computing

Dˇelen´ı podle modelu nasazen´ı

Cloud computing je model, kter´ y umoˇzn ˇuje v´ yhodn´ y s´ıt’ov´ y pˇr´ıstup ke ” sd´ılen´ ym v´ ypoˇcetn´ım prostˇredk˚ um (napˇr. s´ıt’, servery, datové sklady, aplikace a sluˇzby) a kter´ y m˚ uˇze b´ yt rychle zpˇr´ıstupnˇen s minimáln´ı spoluprac´ı poskytovatele sluˇzby.“ ˇ e republice, naraz´ıme Pokud se pod´ıváme na to, jak term´ın definuj´ı v Cesk´ ˇ na definici autor˚ u Burkonˇe a Sebesty z Katedry informaˇcn´ıch technologi´ı na ˇ VSE: Cloud computing zahrnuje dodávku virtualizovan´ ych IT zdroj˚ u jako ” sluˇzbu pˇres Internet. Sluˇzby CC jsou dodávány ˇskálovateln´ ym a bezpeˇcn´ ym zp˚ usobem ze vzdálen´ ych datov´ ych center a jsou zpoplatˇ novány modelem skuteˇcné spotˇreby pay-as-you-use. Dˇel´ıme je na sluˇzby infrastruktury (IaaS), sluˇzby platformy (PaaS) a sluˇzby softwaru (SaaS).“ [16] Tato definice obdobnˇe jako pˇredchoz´ı zmiˇ nuje zpoplatnˇen´ı podle skuteˇcné spotˇreby a pˇr´ıstup pˇres Internet. Nav´ıc ale zd˚ urazˇ nuje virtualizaci zdroj˚ u, coˇz je spoleˇcn´ ym znakem a podstatou cloudov´ ych sluˇzeb. Jak je patrné, nepanuje obecná shoda ohlednˇe pˇresné definice CC a ˇcasto jsou také velmi vágn´ı - napˇr. definice NIST uvád´ı (ekonomicky) v´ yhodn´ y ” pˇr´ıstup“, coˇz si lze vykládat r˚ uzn´ ymi zp˚ usoby. Pro u ´ˇcely této práce se rozhodl autor povaˇzovat za CC takovou sluˇzbu, která splˇ nuje tyto body: • Poskytuje virtualizované IT zdroje pˇres poˇc´ıtaˇcovou s´ıt’. • Je zpoplatnˇena za skuteˇcné vyuˇzit´ı zdroj˚ u. • Pˇridˇelené zdroje lze snadno mˇenit (navyˇsovat ˇci sniˇzovat). • Zˇr´ızen´ı je plnˇe automatické.

3.3

Dˇ elen´ı podle modelu nasazen´ı

Cloudy m˚ uˇzeme rozdˇelit podle toho, kdo ho vlastn´ı a spravuje. Toto rozdˇelen´ı vycház´ı z definice dle NIST [32] a ilustruje ho obr. 3.1: • Public (veˇrejn´ y) cloud • Private (privátn´ı) cloud 14

Cloud computing


• Hybrid (hybridn´ı) cloud • Community (komunitn´ı) cloud

Obrázek 3.1: Rozdˇelen´ı cloud˚ u podle modelu nasazen´ı Zdroj: [12]

3.3.1

Public cloud

Patrnˇe nejpouˇz´ıvanˇejˇs´ı variantu nasazen´ı pˇredstavuje veˇrejn´ y, nˇekdy také oznaˇcovan´ y jako extern´ı cloud. Koncov´ı uˇzivatelé (organizace) pˇristupuj´ı pˇres Internet ke vzdálenému poskytovateli, kter´ y poskytuje cloudové sluˇzby. Obvykle jde o sd´ılen´ y princip, kdy je sluˇzba poskytována vˇetˇs´ımu mnoˇzstv´ı uˇzivatel˚ u (multi-tenancy) a zpoplatnˇena podle skuteˇcného vyuˇzit´ı zdroj˚ u. Tento model je ˇsiroce akceptován a adaptován ˇradou firem. Velc´ı hráˇci jako Amazon, Microsoft5 nebo Google6 disponuj´ı silnou infrastrukturou s mnoha datov´ ymi centry, ˇc´ımˇz umoˇzn ˇuj´ı uˇzivatel˚ um flexibilnˇe ˇskálovat zdroje s n´ızk´ ymi náklady. [19] Nelze urˇcit, na jakém hardware a odkud je sluˇzba poskytována, coˇz je zejména pro firmy a organizace ˇcasto zásadn´ı problém zejména v návaznosti 5 6

http://www.microsoft.com/ http://www.google.com/

15

Cloud computing


ˇ a EU. Napˇr´ıklad Zákon o ochranˇe osobn´ıch u na legislativu CR ´daj˚ u pomˇernˇe striktnˇe specifikuje podm´ınky, pod kter´ ymi je moˇzné osobn´ı u ´daje zpracoˇ Nˇekteré z nich, napˇr´ıklad nutnost ohlásit Uˇ ´ radu pro vávat mimo u ´zem´ı CR. ochranu osobn´ıch u ´daj˚ u vˇsechna m´ısta, kde m˚ uˇze docházet ke zpracován´ı (ukládán´ı) citliv´ ych u ´daj˚ u, mohou pˇredstavovat pomˇernˇe zásadn´ı problém v pˇr´ıpadˇe vyuˇzit´ı velk´ ych cloud˚ u rozm´ıstˇen´ ych po celém svˇetˇe.

3.3.2

Private cloud

T´ımto term´ınem je oznaˇcován takov´ y cloud, kter´ y je pˇr´ıstupn´ y pouze danému uˇzivateli (organizaci). M˚ uˇze b´ yt fyzicky um´ıstˇen v prostorách uˇzivatele (inhouse) nebo externˇe (hosted), spravován internˇe nebo externˇe. Uˇzivatel je k nˇemu obvykle pˇripojen dostateˇcnˇe rychlou a nesd´ılenou linkou. Existuje názor, ˇze nejde o cloud jako takov´ y [19], protoˇze nedocház´ı ke sd´ılen´ı fyzické infrastruktury mezi v´ıce uˇzivateli a t´ım je sn´ıˇzena efektivita, které dosahuje veˇrejn´ y cloud. Vzhledem k tomu, ˇze je k dispozici pouze pˇredem objednaná kapacita, odpadá také v´ yhoda snadné ˇskálovatelnosti ve srovnán´ı s veˇrejn´ ym cloudem. Naopak d´ıky faktu ˇze nedocház´ı ke sd´ılen´ı s jin´ ymi uˇzivateli stoupá bezpeˇcnost ˇreˇsen´ı. Toto ˇreˇsen´ı je uˇziteˇcné pˇredevˇs´ım pro citlivé vnitrofiremn´ı aplikace, kde by bylo naruˇsen´ı bezpeˇcnosti nebo stability (napˇr. sousedn´ım uˇzivatelem) velk´ y problém. Lze pˇresnˇe urˇcit, na kterém konkrétn´ım hardware je sluˇzba poskytována a odkud je poskytována. V´ yznamovˇe má tedy velmi bl´ızko ke klasickému server hostingu, od kterého se ale odliˇsuje pouˇzit´ım virtualizace. Je vhodn´ y zejména pro velké organizace, které si mohou dovolit velké investice do IT a také tam, kde je nutné udrˇzet naprostou kontrolu nad vˇsemi prvky infrastruktury. Pro nˇekteré pˇr´ıpady uˇzit´ı (intentivn´ı v´ ypoˇcty, . . . ) se m˚ uˇze ukázat, ˇze je poˇr´ızen´ı privátn´ıho cloudu vyjde v uvaˇzovaném horizontu levnˇeji neˇz vyuˇzit´ı veˇrejného cloudu.

16

Cloud computing


Public cloud Poˇ c´ ateˇ cn´ı n´ aklady ˇzádné ´ vyuˇzité zdroje Uˇ ctov´ an´ı za Sd´ılen´ı infrastruktury ano Flexibilita ˇ sk´ alovatelnosti vysoká

Private cloud vysoké dostupnou kapacitu ne n´ızká

Tabulka 3.1: Shrnut´ı rozd´ıl˚ u mezi public a private cloudem Zdroj: vlastn´ı zpracov´ an´ı

3.3.3

Hybrid cloud

Hybridn´ı cloud pˇredstavuje spojen´ı veˇrejného a privátn´ıho cloudu. Uˇzivatel vyuˇzit´ım tohoto modelu spojuje v´ yhody obou ˇreˇsen´ı. Citlivé vnitrofiremn´ı aplikace s kritick´ ymi daty budou provozovány na privátn´ım cloudu, aby nad nimi organizace udrˇzela plnou kontrolu a ménˇe citlivé ˇca´sti aplikace pˇresune na veˇrejn´ y cloud, kde vyuˇzije zejména v´ yhody niˇzˇs´ı ceny a lepˇs´ı celosvˇetové dostupnosti. [53] Dalˇs´ım pˇr´ıpadem uˇzit´ı je situace, kdy bˇeˇzn´ y provoz je odbaven privátn´ım cloudem a veˇrejn´ y je vyuˇzit pro pokryt´ı ˇspiˇcek, kv˚ uli kter´ ym by bylo nutné navyˇsovat kapacitu privátn´ıho cloudu. Obrázek 3.2 ilustruje pˇr´ıklad hybridn´ıho cloudu, kde podnik vyuˇz´ıvá jeden privátn´ı cloud a tˇri veˇrejné, pˇriˇcemˇz kaˇzd´ y cloud obsluhuje jinou ˇcást aplikac´ı.

3.3.4

Community cloud

O komunitn´ım cloudu lze uvaˇzovat jako o mezistupni mezi veˇrejn´ ym a privátn´ım cloudem. Je urˇcen k v´ yhradn´ımu uˇz´ıván´ı pˇredem dané skupinˇe organizac´ı, které maj´ı podobné zájmy a poˇzadavky (napˇr. v otázce zabezpeˇcen´ı). ˇ Casto jde o firmy nˇejak´ ym zp˚ usobem propojené ˇci spˇr´ıznˇené. M˚ uˇze b´ yt spravován externˇe, jednou z firem v komunitˇe nebo spoleˇcn´ ymi silami. V´ yhodou je sn´ıˇzen´ı náklad˚ u oproti privátn´ımu cloudu.

17

Cloud computing

Dˇelen´ı podle typu sluˇzby

Obrázek 3.2: Rozdˇelen´ı cloud˚ u podle modelu nasazen´ı Zdroj: [19]

3.4

Dˇ elen´ı podle typu sluˇ zby

Na CC m˚ uˇzeme nahl´ıˇzet jako na kolekci sluˇzeb, kterou lze znázornit vrstvenou architekturou, jak ilustruje obrázek 3.3.

3.4.1

Infrastructure as a Service

Pojmem IaaS7 oznaˇcujeme pronájem v´ ypoˇcetn´ıch prostˇredk˚ u, tedy garantovaného v´ ykonu procesoru, operaˇcn´ı pamˇeti, diskového prostoru a pˇripojen´ı k internetu. Zákazn´ıkovi je k dispozici virtualizovaná IT infrastruktura bez nutnosti zakupovat vlastn´ı hardware. V´ yhodou je snadná ˇskálovatelnost a platba pouze za vyuˇzité zdroje. V praxi si lze pod t´ımto pojmem pˇredstavit napˇr´ıklad veˇrejnou sluˇzbu Amazon EC28 , Windows Azure9 ˇci Google Compute Engine10 . Kapitola 3.7 7

Infrastructure as a Service https://aws.amazon.com/ec2/ 9 http://azure.microsoft.com/ 10 https://cloud.google.com/products/compute-engine/ 8

18

Cloud computing

Dˇelen´ı podle typu sluˇzby

Obrázek 3.3: Vrstvy cloud computingu Zdroj: [43]

se podrobnˇeji zab´ yvá softwarem pro realizaci IaaS v rámci privátn´ıho cloudu.

3.4.2

Platform as a Service

PaaS11 je souhrn v´ yvojov´ ych nástroj˚ u, databáz´ı a v´ ypoˇcetn´ıch prostˇredk˚ u speciálnˇe pˇripraven´ ych pro v´ yvoj a bˇeh cloudov´ ych aplikac´ı. Lze si ho pˇredstavit jako IaaS + specifická softwarová platforma a primárnˇe je urˇcen pro softwarové v´ yvojáˇre. Pˇr´ıkladem jsou sluˇzby jako Heroku, Salesforce ˇci Google App Engine.

3.4.3

Software as a Service

Nad ostatn´ımi vrstvami (viz obr. 3.3) se nacház´ı SaaS12 . Tento term´ın byl pouˇz´ıván jeˇstˇe pˇred nástupem CC a oznaˇcuje pronájem aplikac´ı, které jsou 11 12

Platform as a Service Software as a Service

19

Cloud computing

Výhody

poskytovány vzdálenˇe uˇzivateli. Pro jejich vyuˇz´ıván´ı nen´ı nutné, aby mˇel uˇzivatel nainstalován nˇejak´ y specifick´ y software, obvykle si vystaˇc´ı s bˇeˇzn´ ym internetov´ ym prohl´ıˇzeˇcem. Jako pˇr´ıklad lze uvést webové rozhran´ı pro práci s poˇstou (WebMail), kdy nen´ı nutné instalovat samostatn´ y poˇstovn´ı program a je moˇzné pracovat s e-mailovou schránkou. Dále lze zm´ınit r˚ uzné CRM13 systémy ˇci kanceláˇrské bal´ıky (Google Docs, Office 365). S nástupem CC se jako základ pro SaaS jev´ı virtuáln´ı infrastruktura a niˇzˇs´ı vrstvy cloudu. [53]

3.5

V´ yhody

V této kapitole rozebereme v´ yhody plynouc´ı ze zaveden´ı cloud computingu.

Finanˇ cn´ı u ´ spory Jak jiˇz bylo uvádˇeno na pˇr´ıkladu firmy Amazon [25], v pˇr´ıpadˇe konvenˇcn´ıch datov´ ych center existuje nezanedbatelné mnoˇzstv´ı nevyuˇzitého v´ ykonu. Nasazen´ım CC a virtualizace se zvyˇsuje efektivita vyuˇzit´ı zdroj˚ u. ˇ alovatelnost Sk´ CC poskytuje velkou flexibilitu, kdy je moˇzné snadno upravovat mnoˇzstv´ı dostupn´ ych zdroj˚ u s ˇzádn´ ym nebo minimáln´ım v´ ypadkem sluˇzby. D´ıky modelu plateb za vyuˇzité zdroje také odpadaj´ı fixn´ı náklady a nutnost plánovat v´ ykon na dlouhou dobu dopˇredu.

Sn´ıˇ zen´ı rizika Pouˇzit´ım CC lze také pˇrenést ˇcást rizika od zákazn´ıka smˇerem k poskytovateli. Nejde jen o podcenˇen´ı plánován´ı, kdy v pˇr´ıpadˇe tradiˇcn´ıch server˚ u nen´ı moˇzné flexibilnˇe nav´ yˇsit kapacitu a t´ım pádem riskovat nedostupnost ˇci v´ ypadky sluˇzby. Je tu také bezpeˇcnostn´ı riziko, kdy lze oˇcekávat, ˇze velc´ı poskytovatelé 13

Customer relationship management

20

Cloud computing

Obavy, pˇrekáˇzky

cloudu maj´ı technologie zabezpeˇceny v´ yraznˇe lépe neˇz bˇeˇzná menˇs´ı firma a podstupuj´ı také pravidelnˇe bezpeˇcnostn´ı audity. Nemus´ı to samozˇrejmˇe platit ve vˇsech pˇr´ıpadech.

Sn´ıˇ zen´ı z´ atˇ eˇ ze Outsourcován´ım IT sluˇzeb je sn´ıˇzena zátˇeˇz zamˇestnanc˚ u firmy, kteˇr´ı se pak mohou specializovat na hlavn´ı pˇredmˇet svého podnikán´ı.

3.6

Obavy, pˇ rek´ aˇ zky

Nasazen´ı CC sebou pˇrináˇs´ı také obavy a nˇekdy také pˇrekáˇzky, se kter´ ymi je tˇreba poˇc´ıtat a minimalizovat je.

Bezpeˇ cnost a riziko Pravdˇepodobnˇe nejvˇetˇs´ı obavu pˇredstavuje fakt, ˇze citlivá data jsou v rukou poskytovatele sluˇzby a to ˇcasto v prostˇred´ı, které je sd´ıleno s nˇekolika (nˇekdy i tis´ıci) dalˇs´ımi klienty. Je tˇreba zváˇzit, jestli je zvolen´ y poskytovatel dostateˇcnˇe d˚ uvˇeryhodn´ y, aby u ´myslnˇe ˇci ne´ umyslnˇe nezneuˇzil svˇeˇrená data. [46]

Z´ avislost a dostupnost Uˇzivatel je plnˇe závisl´ y na vybraném poskytovateli a v pˇr´ıpadˇe problém˚ u na jeho stranˇe se to projev´ı i v dostupnosti a kvalitˇe vyuˇz´ıvan´ ych sluˇzeb. Aˇckoliv se cloudové sluˇzby obecnˇe povaˇzuj´ı za velmi stabiln´ı, jiˇz existuj´ı pˇr´ıpady, kdy i velc´ı poskytovatelé mˇeli závaˇzné problémy s provozem.

Z´ akonn´ e poˇ zadavky V kapitole 3.3.1 jsme podrobnˇeji rozebrali situaci, kdy je ze zákona vyˇzadována urˇcitá moˇznost kontroly nad m´ıstem, kde jsou data uloˇzena. To v pˇr´ıpadˇe velk´ ych geograficky rozdˇelen´ ych cloud˚ u pˇredstavuje problém. 21

Cloud computing

3.7

Softwarové platformy pro IaaS

Softwarov´ e platformy pro IaaS

V této podkapitole postupnˇe rozebereme nˇekolik platforem pro poskytován´ı IaaS. Kl´ıˇcem k jejich zaˇrazen´ı do tohoto pˇrehledu byla v prvn´ı ˇradˇe podpora KVM, protoˇze vycház´ıme z kapitoly 2.4, kde jsme zvolili KVM jako virtualizaˇcn´ı infrastrukturu pro náˇs návrh.

3.7.1

Apache CloudStack

Vznikl v roce 2008, tehdy jeˇstˇe pod firmou VMOps (pozdˇeji pˇrejmenovanou na Cloud.com). V roce 2010 byla vˇetˇsina kódu uvolnˇena pod licenc´ı GPLv3. O nˇeco pozdˇeji doˇslo k odkoupen´ı firmou Citrix, která uvolnila zbytek kódu pod stejnou licenc´ı. V dubnu 2012 pak cel´ y bal´ık zmˇenil licenci na ASLv2 a byl vˇenován do správy Apache, kde je dodnes. [10] Tento krok mˇel za c´ıl vˇetˇs´ı rozˇs´ıˇren´ı a zrychlen´ı v´ yvoje, na kterém se Citrix nadále pod´ıl´ı a na základech CloudStacku postavil sv˚ uj produkt Citrix CloudPlatform. CloudStack podporuje hypervizory VMware, KVM, XenServer, Xen Cloud Platform (XCP) a Hyper-V. Skládá se ze dvou hlavn´ıch ˇcást´ı: • Management Server, kter´ y se stará o správu zdroj˚ u (´ uloˇziˇstˇe, IP adresy, hostitelské servery, . . . ). • Computing Server, kter´ y pˇredstavuje v´ ypoˇcetn´ı ˇca´st cloudové infrastruktury a kter´ y je ˇr´ızen management serverem.

3.7.2

Eucalyptus

Eucalyptus je open-source platforma, která si klade za c´ıl sluˇcovat existuj´ıc´ı virtualizovanou infrastrukturu k vytváˇren´ı cloudov´ ych zdroj˚ u pro poskytován´ı sluˇzeb pˇres poˇc´ıtaˇcovou s´ıt’. [15] Byl zaloˇzen na University of California, Santa Barbara a v roce 2009 se transformoval do firmy Eucalyptus Systems. V roce 2012 doˇslo k podpisu dohody s Amazon Web Services, která umoˇzn ˇuje pˇresouvat virtuáln´ı servery 22

Cloud computing


mezi privátn´ım cloudem Eucalyptus a veˇrejn´ ym cloudem Amazon EC2, coˇz usnadˇ nuje vytvoˇren´ı, správu a vyuˇz´ıván´ı hybridn´ıho cloudu. [24] Je kompatibiln´ı s Amazon Web Services (AWS) a Amazon S3, jeho API je kompatibiln´ı s Amazon EC2 a umoˇzn ˇuje vyuˇz´ıvat hypervizory VMware, XEN a KVM. Skládá se z pˇeti hlavn´ıch komponent, které zachycuje obr. 3.4: [14] • Cloud Controller – zajiˇst’uje rozhran´ı pro komunikaci ve formˇe API i webového portálu, plánován´ı a u ´ˇctován´ı zdroj˚ u. • Cluster Controller – komunikuje se Storage a Node controllerem, spravuje instance virtuáln´ıch stroj˚ u a stará se o dodrˇzován´ı SLA. • Node Controller – hostuje virtuáln´ı stroje a zajiˇst’uje jejich vytváˇren´ı, spravuje s´ıt’ové rozhran´ı. • Storage Controller – spravuje bloková zaˇr´ızen´ı a snapshoty v rámci cloudu. • Walrus – ekvivalent k Amazon S3, zajiˇst’uje perzistentn´ı u ´loˇziˇstˇe. Aˇz do roku 2011 Eucalyptus pohánˇel Ubuntu Enterprise Cloud (UEC), kdy byl nahrazen OpenStackem.

3.7.3

OpenNebula

OpenNebula je nástroj, kter´ y pomáhá virtualizovan´ ym datov´ ym centr˚ um dohl´ıˇzet na privátn´ı, veˇrejné a hybridn´ı cloudy. Nen´ı závisl´ y na konkrétn´ı technologii, platformˇe nebo API - umoˇzn ˇuje pouˇz´ıvat hypervizory KVM, XEN nebo VMware. [24] Obr. 3.5 zobrazuje jeho architekturu. M. Llorente a Rubén S. Montero zapoˇcali jeho v´ yvoj v roce 2005 na University of Madrid, nyn´ı je projekt spravován jako open-source. Prvn´ı veˇrejná verze byla uvolnˇena v roce 2008 a jde tak o nejstarˇs´ı open-source software na správu cloudu. Podobnˇe jako CloudStack je tvoˇren dvˇema ˇcástmi – ˇr´ıd´ıc´ım serverem (frontend) a v´ ypoˇcetn´ımi uzly.

23

Cloud computing


Obrázek 3.4: Architektura Eucalyptu Zdroj: [14]

Podporuje sd´ılené (NFS spuˇstˇené na SAN/NAS serveru) i nesd´ılené (lokáln´ı) u ´loˇziˇstˇe, stejnˇe jako distribuované souborové systémy jako GlusterFS14 a MooseFS15 . Umoˇzn ˇuje realizovat podobnˇe jako OpenStack virtuáln´ı s´ıtˇe s fixn´ımi a plovouc´ımi IP adresami. Nab´ız´ı integrovan´ y firewall a podporu Open vSwitch. Jeho API je kompabitiln´ı s Amazonem. OpenNebula c´ıl´ı pˇredevˇs´ım na uˇzivatele vCloudu od VMware, kteˇr´ı nyn´ı tvoˇr´ı aˇz 70 % uˇzivatel˚ u. Verze 4.0 se pyˇsn´ı prohláˇsen´ım, ˇze nab´ız´ı okamˇzitou náhradu vCloudu, která umoˇzn ˇuje kromˇe sn´ıˇzen´ı náklad˚ u také podporu jin´ ych hypervizor˚ u. [34]

3.7.4

OpenStack

Ze zpracovaného pˇrehledu se jedná o nejmladˇs´ı platformu, kterou v roce 2010 spoleˇcnˇe zaloˇzili Rackspace a NASA. V souˇcasné dobˇe ji spravuje OpenStack Foundation a je pod licenc´ı Apache. Klade si za c´ıl poskytnout ˇreˇsen´ı pro 14 15

Detaily na: http://www.gluster.org/ V´ıce informac´ı na: http://www.moosefs.org/

24

Cloud computing


Obrázek 3.5: Architektura OpenNebuly Zdroj: [36]

vˇsechny typy cloud˚ u d´ıky snadné implementaci, vysoké ˇskálovatelnosti a velkému mnoˇzstv´ı funkc´ı. [39] Aktuálnˇe se na v´ yvoji pod´ıl´ı pˇres 9000 jednotlivc˚ u a 200 firem jako je Cisco, Dell, HP, IBM, Intel, Red Hat, SuSE, VMware ˇci Oracle a jejich poˇcet stále nar˚ ustá. Ve srovnán´ı s ostatn´ımi zm´ınˇen´ ymi systémy pro IaaS ˇc´ıtá OpenStack nejvˇetˇs´ı komunitu pˇrispˇevatel˚ u, v´ yvojáˇr˚ u a uˇzivatel˚ u. [28] Skládá se z nˇekolika samostatn´ ych modul˚ u, pˇriˇcemˇz kaˇzd´ y z nich pln´ı jinou funkci a spoleˇcnˇe propojené pˇres otevˇrené API tvoˇr´ı komplexn´ı ˇreˇsen´ı. Umoˇzn ˇuje se napojit a ˇr´ıdit ˇradu hardwarov´ ych prvk˚ u, od switche aˇz po disková u ´loˇziˇstˇe, pˇriˇcemˇz pokud takové prvky nemáme k dispozici nebo je nechceme pouˇz´ıt, lze vytvoˇrit enterprise ˇreˇsen´ı pouze pomoc´ı OpenStacku, kter´ y podporuje SDN (Open vSwich s OpenFlow) i softwarov´ y storage (iSCSI). Komponenty tvoˇr´ıc´ı jádro (ve verzi Havana): • Horizon (dashboard, webov´ y portál) 25

Cloud computing


• Nova (v´ ypoˇcetn´ı uzel) • Neutron (s´ıt’ov´ y uzel) • Swift (objektové u ´loˇziˇstˇe) • Cinder (blokové u ´loˇziˇstˇe) • Keystone (správce identit) • Glance (správce obraz˚ u server˚ u) • Celiometer (vy´ uˇctován´ı zdroj˚ u) • Heat (automatizovaná pˇr´ıprava instanc´ı) Aˇckoliv je KVM v´ ychoz´ım hypervizorem pro OpenStack [45], je jich podporováno mnohem v´ıce. Podpora je rozdˇelena do nˇekolika u ´rovn´ı: [38] • Skupina A: plnˇe podporované, proˇslo unit testy a testován´ım funkˇcnosti, pˇr´ıpadné chyby jsou prioritnˇe opravovány. Patˇr´ı sem libvirt (qemu/KVM na architektuˇre x86). • Skupina B: podporované, proˇslo unit testy a testován´ım funkˇcnosti, chyby jsou hláˇseny autor˚ um a nen´ı záruka jejich oprav. Patˇr´ı sem Hyper-V, VMware a XenServer. • Skupina C: zastaralé, budou brzy vyˇrazeny. Patˇr´ı sem baremetal, docker, Xen pˇres libvirt a LXC pˇres libvirt. Zaˇcátkem roku 2014 se objevila oficiáln´ı podpora OpenStacku ze strany VMware16 , kdy byla provedena plná integrace do jejich infrastruktury. D´ıky této oficiáln´ı podpoˇre a pˇred pˇripravenému obrazu pro nasazen´ı lze velmi snadno ovládat VMware cluster i pˇres OpenStack. Platforma se neustále rozv´ıj´ı s c´ılem nab´ıdnout v´ yhledovˇe i PaaS sluˇzby. Od verze Icehouse bude dostupná nová komponenta Trove, která poskytne uˇzivatel˚ um databázové sluˇzby (relaˇcn´ı i nerelaˇcn´ı databáze) bez nutnosti instalovat a spravovat vlastn´ı databázov´ y server. V pˇr´ıpravˇe je také komponenta Sahara zajiˇst’uj´ıc´ı jednoduchou pˇr´ıpravu Hadoop17 clusteru. 16

V´ıce informaci na: http://www.vmware.com/files/pdf/techpaper/ VMWare-Getting-Started-with-OpenStack-and-vSphere.pdf 17 http://hadoop.apache.org/

26

Cloud computing


Dalˇs´ı vyv´ıjenou komponentou je Ironic, která poskytne automatizaci správy server˚ u bez virtualizace (bare metal), ˇc´ımˇz bude moˇzné zaˇclenit pod OpenStack i nevirtualizované servery.

3.7.5

Zhodnocen´ı a v´ ybˇ er

Ze specifikace poˇzadavk˚ u je patrné, ˇze zvolené ˇreˇsen´ı mus´ı b´ yt otevˇrené a modulárn´ı ˇreˇsen´ı bez licenˇcn´ıch omezen´ı, jehoˇz provoz lze automatizovat, snadno ˇskálovat a pˇr´ıpadnˇe upravit pro zaˇclenˇen´ı do infrastruktury Západoˇceské univerzity v Plzni. ˇ neexistuje ˇza´dn´ Jelikoˇz v souˇcasné dobˇe na ZCU y management cloudu, nejsme svázáni existuj´ıc´ım ˇreˇsen´ım. Zároveˇ n se jedná v prvn´ı ˇradˇe o provoz pro v´ yukové a v´ yzkumné u ´ˇcely, pro které chceme vyuˇz´ıt modern´ı a aktivnˇe vyv´ıjenou platformu, která disponuje nejnovˇejˇs´ı technologi´ı. Pokud se zamˇeˇr´ıme na aktuáln´ı dˇen´ı v oblasti IaaS platforem pro privátn´ı cloud, nejv´ıce zmiˇ novan´ y pojem je OpenStack. Aˇc je historicky nejmladˇs´ı, za velmi krátk´ y ˇcas z´ıskal obrovskou popularitu a ˇsirokou základnu uˇzivatel˚ ui v´ yvojáˇr˚ u. OpenStack vyuˇz´ıvaj´ı nejznámˇejˇs´ı firmy v oboru, je základem ˇrady enterprise distribuc´ı jako SUSE Cloud, HP Public Cloud, IBM SmartCloud, Oracle Solaris ˇci Dell Red Hat Cloud. Evropská organizace pro jadern´ y v´ yzkum CERN nedávno oznámila [33], ˇze sv˚ uj obˇr´ı privátn´ı cloud (500 hypervizor˚ u, 11 000 virtuáln´ıch server˚ u) pˇresunula z OpenNebuly právˇe na OpenStack. Jako d˚ uvody pˇrechodu zm´ınila, ˇze chce systém s velkou ˇskálovatelnost´ı a nechce vyuˇz´ıvat OpenNebuly, kde by byli prvn´ı s takto velk´ ym cloudem. Dalˇs´ımi argumenty bylo vyuˇzit´ı ˇsirokého ekosystému – podpory load balancingu a moˇznost vyuˇzit´ı automatizované pˇr´ıpravy instanc´ı (obdoba sluˇzby Orchestration v OpenStacku, viz kap. 4.10.2), kter´ ymi OpenNebula nedisponuje. K OpenStacku se hlás´ı také biomedic´ınská v´ yzkumná instituce Broad Institute of Harvard and MIT, která nedávno oznámila [5], ˇze na OpenStacku postavila sv˚ uj privátn´ı cloud pro v´ yzkumné u ´ˇcely – jedn´ım z projekt˚ u je v´ yzkum rakoviny, kde analyzuj´ı des´ıtky TB dat. Porovnáván´ım vybran´ ych platforem se jiˇz zab´ yvala ˇrada studi´ı a prac´ı, jmenovitˇe napˇr´ıklad Klepáˇc, 2013 [29] nebo Jiang, 2014 [28]. Právˇe druhá zm´ınˇená studie se dlouhodobˇe zab´ yvá sledován´ım velikosti a aktivity komunity v´ yvojáˇr˚ u u vybran´ ych projekt˚ u. V´ ysledkem je, ˇze OpenStack je nejvˇetˇs´ı a nejv´ıce aktivn´ı open-source projekt pro cloud computing. [6] Jedn´ım z mnoha 27

Cloud computing


sledovan´ ych faktor˚ u v jeho studii je poˇcet aktivn´ıch ˇclen˚ u komunity (kter´ y je v´ıce neˇz dvojnásobn´ y oproti ostatn´ım ˇreˇsen´ım) a mˇes´ıˇcn´ı poˇcet commit˚ u do zdrojového kódu (obr. 3.6). 3000

OpenStack OpenNebula Eucalyptus CloudStack

Figure 10 -- Monthly Git Commits 2500

2000

1500

1000

500

0 2009-04 2009-10 2010-04 2010-10 2011-04 2011-10 2012-04 2012-10 2013-04 2013-10 2009-01 2009-07 2010-01 2010-07 2011-01 2011-07 2012-01 2012-07 2013-01 2013-07 2013-12

Obrázek 3.6: Poˇcet commit˚ u za mˇes´ıc Zdroj: [28]

Pokud budeme zkoumat vyuˇzit´ı cloudu na akademick´ ych instituc´ıch v ˇ CR, pak kromˇe velmi rozˇs´ıˇreného VMware (kter´ y ale nesplˇ nuje námi poˇzadované parametry, viz kap. 2.4) uˇz naraz´ıme pouze na OpenNebulu, která je pouˇzita napˇr´ıklad v brnˇenském MetaCentru. Co se t´ yˇce produkˇcn´ıho nasaˇ zen´ı OpenStacku v CR, jedná se zat´ım pouze o nepatrné náznaky, coˇz m˚ uˇze b´ yt zapˇr´ıˇcinˇeno relativn´ı mladost´ı technologie a omezen´ ym poˇctem instituc´ı, které si ˇreˇsen´ı privátn´ıho cloudu poˇrizuj´ı. ˇ e Radiokomunikace, které v bˇreznu 2014 Jedn´ım z pˇredstavitel˚ u jsou Cesk´ oznámily, ˇze bˇehem téhoˇz roku postav´ı sv˚ uj cloud právˇe na OpenStacku. Generáln´ı ˇreditel firmy rozhodnut´ı zd˚ uvodnil slovy: OpenStack se nám l´ıb´ı ” d´ıky jeho skuteˇcné ˇskálovatelnosti. Kdyˇz kus hardwaru vypadne, nic se nedˇeje 28

Cloud computing


a pˇridá se dalˇs´ı. Je to skuteˇcn´ y cloud se vˇsemi jeho vlastnostmi.“ [48] Vznikla také ˇceská komunita uˇzivatel˚ u18 , coˇz je v´ıtan´ y impuls pro dalˇs´ı rozˇsiˇrován´ı v ˇ CR. Tato práce nab´ız´ı kromˇe jiného pˇr´ınos v tom, ˇze nab´ıdne hlubˇs´ı pohled na implementaci ˇreˇsen´ı, které v ˇcesk´ ych akademick´ ych kruz´ıch zat´ım nikdo neprovozuje a dosud neexistuje ˇza´dná studie proveditelnosti. Jak jiˇz ale bylo uvedeno v´ yˇse, nen´ı to d˚ uvod jedin´ y a samo´ uˇceln´ y. Ve svˇetˇe open-source produkt˚ u se aktuálnˇe tˇeˇs´ı nejvˇetˇs´ı pˇr´ızni právˇe OpenStack a kdyˇz na nˇej vsadili i ti nejvˇetˇs´ı a nej´ uspˇeˇsnˇejˇs´ı, je to nejen známka souˇcasné kvality, ale i pˇr´ıslib dobré budoucnosti. V dalˇs´ı ˇcásti této práce se budeme zab´ yvat návrhem ˇreˇsen´ı na platformˇe OpenStack.

18

Dostupné na: http://openstack.cz/

29

4 Popis a návrh architektury OpenStack je tvoˇren sadou komponent, které jsou mezi sebou propojeny pomoc´ı otevˇren´ ych rozhran´ı (API).

Obrázek 4.1: Konceptuáln´ı pohled na architekturu Zdroj: [51]

V následuj´ıc´ıch kapitolách postupnˇe rozebereme fungován´ı jednotliv´ ych komponent, jejich zapojen´ı do celkové infrastruktury a provedeme návrh arˇ chitektury pro potˇreby ZCU.

30

Popis a návrh architektury

4.1

Databáze

Datab´ aze

Databáze je zcela zásadn´ı komponentou OpenStacku. V souˇcasné dobˇe jsou podporovány tyto databáze: • MySQL • PostgreSQL • sqlite3

4.1.1

N´ avrh a zd˚ uvodnˇ en´ı

V praxi se rozhodujeme mezi pouˇzit´ım MySQL a PostgreSQL, tˇret´ı zm´ınˇen´ y sqlite3 je vhodn´ y sp´ıˇse pro testovac´ı a v´ yvojáˇrské u ´ˇcely. Jelikoˇz CIV provoznˇe podporuje Oracle (kter´ y zde ale nelze pouˇz´ıt) a MySQL, pro náˇs návrh vol´ıme MySQL. Pro toto rozhodnut´ı dále hovoˇr´ı fakt, ˇze jde o ˇsiroce pouˇz´ıvan´ y software pro vˇetˇsinu instalac´ı OpenStacku s velkou podporou komunity a oficiáln´ı dokumentace poˇc´ıtá s MySQL jako s primárn´ı databáz´ı. [39] Ostr´ y provoz: databáze bude nasazena na samostatn´ y virtuáln´ı server a 1 bude zajiˇstˇena HA . Pilotn´ı provoz: databáze bude nasazena na virtuáln´ı server ˇr´ıd´ıc´ıho uzlu.

4.2

Keystone: spr´ avce identity

Keystone tvoˇr´ı centráln´ı bod, kter´ y zajiˇst’uje ovˇeˇrován´ı uˇzivatel˚ u, vystavován´ı, správu a ovˇeˇrován´ı token˚ u pro pˇrihláˇsené uˇzivatele a katalog vˇsech komponent vˇc. adres jejich rozhran´ı API. Souˇca´st´ı témˇeˇr kaˇzdého poˇzadavku na rozhran´ı (API) libovolné sluˇzby je token vystaven´ y Keystonem. Dotyˇcná sluˇzba jeˇstˇe pˇred zaˇcátkem vyˇrizován´ı poˇzadavku ovˇeˇr´ı jeho validitu a platnost, teprve pak pokraˇcuje ve vyˇrizován´ı samotného poˇzadavku. 1

High Availability, vysok´ a dostupnost; bl´ıˇze v kap. 4.11.

31


4.2.1

Horizon: webový portál


Z podstaty vˇeci tvoˇr´ı stejnˇe jako databáze kritické m´ısto (Single Point of Failure, SPOF), které je nutné oˇsetˇrit návrhem pro zachován´ı vysoké dostupnosti. Touto problematikou se podrobnˇeji zab´ yvá samostatná kapitola 4.11. Ostr´ y provoz: Keystone bude nasazen na virtuáln´ı server ˇr´ıd´ıc´ıho uzlu a bude zajiˇstˇena HA. Pilotn´ı provoz: Keystone bude nasazen na virtuáln´ı server ˇr´ıd´ıc´ıho uzlu.

4.3

Horizon: webov´ y port´ al

Obˇcas naz´ yvan´ y také jako Dashboard tvoˇr´ı webové rozhran´ı pro pohodln´ y pˇr´ıstup k poskytovan´ ym sluˇzbám. Je jako doplnˇek ke konzolov´ ym klient˚ um, které jsou naprogramovány jazyce Python. Vyuˇz´ıvá dostupná API jednotliv´ ych komponent, nen´ı nijak tˇesnˇeji svázán s jakoukoliv dalˇs´ı sluˇzbou.

4.3.1


Portál pˇredstavuje u ´stˇredn´ı bod, pˇres kter´ y budou uˇzivatelé provádˇet veˇskerou správu. Lze tedy oˇcekávat vyˇsˇs´ı nároky na v´ ykon a navrhuji ho um´ıstit na samostatn´ y server. Horizon standardnˇe nepodporuje Single-Sign-On pro zaˇclenˇen´ı do systému ˇ jednotného pˇrihlaˇsován´ı na ZCU, takˇze je nutné provést u ´pravu softwaru. T´ımto se podrobnˇeji zab´ yvá kapitola 5.9.3. Ostr´ y provoz: Horizon bude nasazen na samostatn´ y virtuáln´ı server a bude zajiˇstˇena HA. Pilotn´ı provoz: Horizon bude nasazen na virtuáln´ı server ˇr´ıd´ıc´ıho uzlu.

32


4.4

Nova: výpoˇcetn´ı uzel

Nova: v´ ypoˇ cetn´ı uzel

V´ ypoˇcetn´ı uzel má na starosti spuˇstˇen´ı a provoz samotn´ ych virtuáln´ıch server˚ u. V navrˇzené konfiguraci se nestará o diskové jednotky (o samostatné komponentˇe podrobnˇeji v kapitole 4.6) ani o s´ıt’ován´ı.

4.4.1


Aˇckoliv lze OS vyuˇz´ıvat s v´ıce hypervizory a to dokonce soubˇeˇznˇe, v naˇsem návrhu se dále budeme zab´ yvat implementac´ı KVM z d˚ uvod˚ u uveden´ ych v kapitole 2.4. V´ ypoˇcetn´ı uzly lze bez problém˚ u ˇskálovat a z povahy funkce je zˇrejmé, ˇze se instaluj´ı na samostatné hardwarové (nikoliv virtuáln´ı) servery. Ostr´ y i pilotn´ı provoz: V´ ypoˇcetn´ı uzly (Nova-compute) budou instalovány na samostatné fyzické servery.

4.5

Neutron: s´ıt’ov´ an´ı

Návrh a konfigurace s´ıtˇe je nejkomplikovanˇejˇs´ı záleˇzitost´ı v OS, zejména kv˚ uli velkému mnoˇzstv´ı variant, jak lze s´ıt’ ˇreˇsit. Neutron se skládá z nˇekolika ˇca´st´ı: • ML2 Framework (viz n´ıˇze). • Agent pro zvolenou technologii networkingu, tedy napˇr. Open vSwitch agent. • Firewall pro centralizované poskytován´ı Firewall as a Service. • DHCP agent zajiˇst’uje pˇridˇelován´ı IP adres. • L3-agent umoˇzn ˇuje uˇzivatelsky vytváˇret routery nad L2 vrstvou. Vyuˇz´ıvá Linuxov´ y IP stack a iptables k provádˇen´ı L3 forwardingu a NATu. Podporuje network namespaces2 , aby bylo moˇzné pˇridˇelit napˇr. dvˇema 2

V´ıce informac´ı o namespaces na: http://www.opencloudblog.com/?p=42

33


Neutron: s´ıt’ován´ı

Obrázek 4.2: Schéma s´ıtˇe s Neutronem Zdroj: [50]

server˚ um stejnou s´ıt’ a tyto byly pˇri routingu oddˇeleny. V kaˇzdém definovaném namespace je také router a DHCP server. Od verze Havana je souˇcást´ı Neutronu framework ML2 (Modular Layer 2), kter´ y umoˇzn ˇuje soubˇeˇznˇe pouˇz´ıvat ˇradu existuj´ıc´ıch technologi´ı pro L2 networking. Podporuje napˇr´ıklad Linux Bridge, Open vSwitch a ˇradu extern´ıch prvk˚ u (Cisco Nexus, Arista, Tail-f NCS). Jsou moˇzné následuj´ıc´ı typy segmentace: [3] • Flat • VLAN • GRE • VxLAN Neutron rozliˇsuje dva typy IP adres, které je moˇzné server˚ um pˇridˇelit. Prvn´ı z nich jsou fixed (pevné) IP, které jsou serveru pˇriˇrazeny napevno a 34


Neutron: s´ıt’ován´ı

nepoˇc´ıtá se s jejich zmˇenou. Tyto adresy jsou vˇetˇsinou neveˇrejné. Druh´ ym typem jsou floating (plovouc´ı) IP, které jsou namapované na fixn´ı. Tyto IP b´ yvaj´ı obvykle veˇrejné a jsou pˇridˇelovány na ˇzádost. Poˇc´ıtá se s t´ım, ˇze mohou b´ yt v pr˚ ubˇehu ˇcasu pˇridˇelovány r˚ uzn´ ym server˚ um dle aktuáln´ı potˇreby.

4.5.1


V reakci na zadávac´ı poˇzadavky návrh poˇc´ıtá s realizac´ı pomoc´ı softwarového ˇreˇsen´ı s´ıtˇe (SDN, Software-defined networking). Pro nejv´ıce izolovan´ y provoz bez nutnosti HW podpory na switchi navrhuji realizovat variantu s VLANy a GRE tunely. Mezi s´ıt’ov´ ym uzlem a v´ ypoˇcetn´ımi uzly jsou sestaveny GRE tunely po samostatné fyzické s´ıti a na vˇsech stranách je nainstalován Open vSwitch (s OpenFlow) ˇreˇs´ıc´ı oznaˇcován´ı paket˚ u podle VLAN. Na obr. 4.3 je pˇr´ıklad takového návrhu. Mezi rozhran´ımi eth1 na serverech (192.168.10.0/24) jsou realizovány GRE tunely.

Obrázek 4.3: Detail implementace Open vSwitche s GRE Zdroj: [50]

Ostr´ y provoz: Neutron bude nasazen na samostatn´ y virtuáln´ı server a bude 35


Cinder: u ´loˇziˇstˇe dat

zajiˇstˇena HA. Vzhledem k oˇcekávané zátˇeˇzi doporuˇceno zváˇzit instalaci na fyzick´ y server. Bude realizována varianta s Open vSwitchem, VLANy a GRE tunely a pouze v pˇr´ıpadˇe pot´ıˇz´ı s v´ ykonem nasadit HW ˇreˇsen´ı spoˇc´ıvaj´ıc´ı v zakládán´ı VLAN pˇr´ımo na switchi pˇres dostupné ovladaˇce. Pilotn´ı provoz: Neutron bude nasazen na samostatn´ y virtuáln´ı server. Bude realizována varianta FLAT s´ıtˇe.

4.6

Cinder: u ´ loˇ ziˇ stˇ e dat

OpenStack disponuje dvˇema základn´ımi typy u ´loˇziˇst’. Prvn´ım z nich je doˇcasné u ´loˇziˇstˇe (ephemeral storage), které je svázané s instanc´ı virtuáln´ıho serveru a zanikne spolu se smazán´ım dotyˇcné instance. Fyzicky je um´ıstˇeno na v´ ypoˇcetn´ım uzlu a je to standardn´ı u ´loˇziˇstˇe OpenStacku. Druh´ ym z nich je tzv. perzistentn´ı u ´loˇziˇstˇe (persistent storage), které m˚ uˇze b´ yt bud’ objektové (komponenta Swift, obdoba Amazon S3) nebo blokové (Cinder). Takto definované u ´loˇziˇstˇe nen´ı závislé na existenci konkrétn´ı instance, lze ho podle potˇreby pˇripojovat k libovolné instanci v cloudu. Jak je patrné, data jsou v tomto pˇr´ıpadˇe fyzicky um´ıstˇena mimo v´ ypoˇcetn´ı uzel, coˇz umoˇzn ˇuje dosáhnout vyˇsˇs´ıho v´ ykonu i kapacity a dovoluje integraci s high-endov´ ymi extern´ımi u ´loˇziˇsti. Cinder se stará o správu perzistentn´ıho diskového u ´loˇziˇstˇe a jeho hlavn´ı funkc´ı je zprostˇredkovat pˇripojen´ı diskov´ ych jednotek k virtuáln´ım server˚ um. Sestává se ze tˇr´ı hlavn´ıch komponent: • API – slouˇz´ı pro komunikaci s ostatn´ımi komponentami Cinderu a potaˇzmo i OpenStacku. • Volume – spravuje databázi jednotek, má pˇrehled o jejich stavu a napˇr´ımo komunikuje s hardwarov´ ymi nebo softwarov´ ymi u ´loˇziˇsti pomoc´ı ovladaˇc˚ u. • Scheduler – vyb´ırá optimáln´ı u ´loˇziˇstˇe, na kterém bude vytvoˇrena nová jednotka. Cinder je d´ıky ovladaˇc˚ um schopen komunikovat s velkou ˇskálou softwaro36



v´ ych (Linux LVM3 , distribuované souborové systémy) i hardwarov´ ych (HP, IBM, NetApp, . . . ) u ´loˇziˇst’. Je podporována práce s v´ıce u ´loˇziˇsti naráz a pˇri vytváˇren´ı nové jednotky se vyb´ırá filtrován´ım (dle uˇzivatelsky definovan´ ych poˇzadavk˚ u) a ˇrazen´ım (napˇr. dle obsazenosti) nejvhodnˇejˇs´ı u ´loˇziˇstˇe obdobnˇe, jako kdyˇz Nova hledá optimáln´ı hostitelsk´ y server pˇri vytváˇren´ı nové instance. Od verze Havana je podporována ˇrada uˇziteˇcn´ ych vlastnost´ı: ˇ • Sifrov´ an´ı – pouˇz´ıvá dm-crypt. • Migrace jednotek – i mezi r˚ uzn´ ymi typy u ´loˇziˇst’ (Cinder je v roli proxy serveru, kter´ y spust´ı pˇr´ıkaz dd). • Omezov´ an´ı datov´ eho toku – limituje I/O poˇzadavky (oddˇelenˇe pro ˇcten´ı a zápis). Pro náˇs návrh je d˚ uleˇzit´ y zejména I/O limit, d´ıky kterému m˚ uˇzeme zabránit situaci, kdy jedna instance zcela zahlt´ı pˇripojené u ´loˇziˇstˇe I/O poˇzadavky.

4.6.1


Pokud chceme k server˚ um pˇripojovat bloková zaˇr´ızen´ı, je nutné vybrat takov´ y protokol, kter´ y to umoˇzn ˇuje. V praxi se nejˇcastˇeji setkáváme s rozhodován´ım mezi iSCSI a FC (Fibre Channel). Jsou sice podporovány i distribuované souborové systémy jako NFS, AFS ˇci GlusterFS, ale technicky to funguje tak, ˇze je na daném souborovém systému vytvoˇren soubor, kter´ y je následnˇe namapován jako samostatná jednotka s vlastn´ım souborov´ ym systémem. To ale nen´ı z hlediska v´ ykonu a uspoˇrádán´ı optimáln´ı, proto o této variantˇe nebudeme uvaˇzovat. V naˇsem návrhu se budeme dále zab´ yvat implementac´ı iSCSI, coˇz je protokol zaloˇzen´ y na IP, kter´ y umoˇzn ˇuje klient˚ um (initiators) komunikovat s I/O zaˇr´ızen´ımi pro ukládán´ı dat (targets) pomoc´ı paket˚ u TCP/IP. [26] V´ yhodou iSCSI oproti FC je zejména cena, nebot’ pro FC je tˇreba poˇr´ıdit speciáln´ı a drah´ y hardware (karty, pˇrep´ınaˇce, kabeláˇz) a iSCSI si vystaˇc´ı s 3

Logical Volume Management, detaily na: https://sourceware.org/lvm2/

37



Nova

Cinder

VM instance /dev/vda

KVM

Storage Controller

iSCSI initiator

iSCSI target

Obrázek 4.4: Storage node s extern´ım uloˇziˇstˇem Zdroj: [52]

obyˇcejn´ ym Ethernetem. Lze ho dokonce provozovat na existuj´ıc´ı s´ıti, aˇckoliv to nen´ı s ohledem na v´ ykon doporuˇcováno. Nav´ıc s nástupem 10 GbE pˇrestává b´ yt problém rychlost rozhran´ı ve srovnán´ı s FC. Studie Andrewa Reichmana [31] ukazuje, ˇze pˇri bˇeˇzném nasazen´ı je FC 3.8× nákladnˇejˇs´ı neˇz iSCSI. Pro iSCSI také hovoˇr´ı ˇsiroká implementace napˇr´ıˇc operaˇcn´ımi systémy a fakt, ˇze nen´ı omezen lokalitou (LAN), ale m˚ uˇze fungovat po bˇeˇzné s´ıti na libovolnou vzdálenost. Obr. 4.4 ukazuje navrˇzen´ y model, kdy Cider komunikuje s extern´ım u ´loˇziˇstˇem tak, aby doˇslo k nastaven´ı potˇrebn´ ych parametr˚ u pro novˇe vznikaj´ıc´ı diskovou jednotku. Ta je pak propojena na pˇr´ımo mezi extern´ım u ´loˇziˇstˇem a virtuáln´ım serverem – datové toky neprocház´ı pˇres Cinder, coˇz by bylo neˇza´douc´ı a mˇelo by to vliv na pokles I/O. V´ıce informac´ı o zp˚ usobu fungován´ı podává kap. 4.6.2. Ostr´ y provoz: Cinder bude nasazen na samostatn´ y virtuáln´ı server a bude 38


Glance: katalog obraz˚ u

zajiˇstˇena HA. Bude ovládat externˇe pˇripojené diskové u ´loˇziˇstˇe. Pilotn´ı provoz: Cinder bude nasazen na samostatn´ y virtuáln´ı server. Cloudu bude poskytovat lokáln´ı diskov´ y prostor, napojen´ı na extern´ı u ´loˇziˇstˇe nebude ˇreˇseno.

4.6.2

Tok poˇ zadavk˚ u pˇ ri pˇ ripojov´ an´ı jednotky

1. Nova zavolá pˇres API Cinder a pˇredá mu poˇzadavek s parametry (hostitel, jméno iSCSI initiatoru, . . . ). 2. Cinder-api pˇredá zprávu do cinder-volume. 3. Probˇehne kontrola chyb a zavolá se ovladaˇc zaˇr´ızen´ı, na kterém se bude jednotka vytváˇret. 4. Ovladaˇ c zaˇ r´ızen´ı provede pˇr´ıpravu jednotky vˇc. nastaven´ı práv pro pˇripojen´ı. 5. Ovladaˇ c zaˇ r´ızen´ı navrát´ı informace pro pˇripojen´ı, tyto jsou pak pˇredány do nova. 6. Nova vytvoˇr´ı spojen´ı na u ´loˇziˇstˇe podle dodan´ ych parametr˚ u. 7. Nova pˇredá pˇripojenou jednotku hypervizoru virtualizace.

4.7


Glance zajiˇst’uje centralizovanou správu katalogu obraz˚ u virtuáln´ıch server˚ u. Má nˇekolik funkc´ı: • Ukládá obrazy (images), které jsou pouˇz´ıvány pˇri vytváˇren´ı instanc´ı. • Poskytuje uˇzivatel˚ um katalog dostupn´ ych obraz˚ u. • Pro komponentu Nova zajiˇst’uje dodávku obraz˚ u. • Zajiˇst’uje vytváˇren´ı snapshot˚ u bˇeˇz´ıc´ıch server˚ u pro zálohovac´ı u ´ˇcely.

39


openstack-glance


openstack-nova VM libvirt base

libvirt instance disks VM

Obrázek 4.5: Proces pˇrenosu a pouˇzit´ı obrazu Zdroj: [4]

Samotné obrazy mohou b´ yt fyzicky uloˇzeny bud’ na lokáln´ım souborovém systému, objektovém u ´loˇziˇsti (Swift, Amazon S3) nebo pˇr´ıstupné pˇres HTTP. Pˇri vytváˇren´ı nové instance z existuj´ıc´ıho obrazu funguje proces tak, jak je zachyceno na obrázku 4.5. V´ ypoˇcetn´ı uzel (openstack-nova) si z Glance stáhne obraz zvoleného operaˇcn´ıho systému. Ten je uloˇzen v nekomprimované podobˇe do tzv. base adresáˇre na v´ ypoˇcetn´ım uzlu a z nˇej je následnˇe vytvoˇren disk pro novˇe vznikaj´ıc´ı instanci. V pˇr´ıpadˇe opakovaného vytváˇren´ı instance ze stejného obrazu je tedy uplatnˇen vliv lokáln´ı mezipamˇeti (cache) a minimalizován ˇcas nutn´ y pro vytvoˇren´ı.

4.7.1


Ostr´ y provoz: Glance bude nasazen na samostatn´ y virtuáln´ı server a bude zajiˇstˇena HA. Pilotn´ı provoz: Glance bude nasazen na samostatn´ y virtuáln´ı server. Obrazy server˚ u budou v obou pˇr´ıpadech uloˇzeny lokálnˇe, vzhledem k tomu ˇze souˇca´st´ı návrhu nen´ı objektové u ´loˇziˇstˇe Swift (detaily a zd˚ uvodnˇen´ı v kap. 4.10.1).

40


4.8

Tok poˇzadavk˚ u pˇri zakládán´ı instance

Tok poˇ zadavk˚ u pˇ ri zakl´ ad´ an´ı instance

Obrázek 4.6 znázorˇ nuje pro lepˇs´ı pˇredstavu proces vytváˇren´ı nové instance virtuáln´ıho serveru v OpenStacku. Docház´ı tam k interakci mezi jednotliv´ ymi komponentami a v´ ysledkem je start virtuáln´ıho serveru. V kroc´ıch 3–12 docház´ı k plánován´ı, v kroc´ıch 22–24 je pˇripravována s´ıt’ a diskové u ´loˇziˇstˇe se pˇriprav´ı v kroku 25–27. N´ıˇze následuje kompletn´ı popis vˇsech krok˚ u: [22] Kaˇzdá komponenta (Nova, Glance, . . . ) je tvoˇrena nˇekolika souvisej´ıc´ımi sluˇzbami (nova-api, nova-scheduler, . . . ), které mezi sebou komunikuj´ı pˇres RPC. Komponenty mezi sebou vyuˇz´ıvaj´ı komunikaci pˇres REST API. 1. Dashboard nebo CLI obdrˇz´ı pˇrihlaˇsovac´ı u ´daje a poˇzádá Keystone, aby je ovˇeˇril. 2. Keystone ovˇeˇr´ı, jestli jsou obdrˇzené u ´daje platné a pokud ano, tak zaˇsle zpˇet token, kter´ ym se bude Dashboard/CLI nadále prokazovat. 3. Dashboard/CLI zpracuje zadané parametry pro novou instanci a poˇsle je pˇres REST do nova-api spoleˇcnˇe s tokenem. 4. Nova-api obdrˇz´ı poˇzadavek a poˇza´dá Keystone o ovˇeˇren´ı pˇrihlaˇsovac´ıho tokenu a zaslán´ı pˇr´ıstupov´ ych práv uˇzivatele. 5. Keystone ovˇeˇr´ı token a zaˇsle role i práva uˇzivatele zpˇet. 6. Nova-api provád´ı interakci s nova-database. 7. Je vytvoˇren inicializaˇcn´ı záznam v DB pro novou instanci. 8. Nova-api zaˇsle rpc.call poˇzadavek do nova-scheduler a ˇceká na doplnˇen´ı ID hostitelského serveru. 9. Nova-scheduler vyzvedne poˇzadavek z fronty (queue). 10. Nova-scheduler se dotazuje nova-database a pokud nen´ı uˇzivatelsky specifikován konkrétn´ı hostitelsk´ y server, hledá se pomoc´ı filtrován´ı a vah ideáln´ı hostitelsk´ y server, kde bude nová instance zaloˇzena. 11. Je navráceno ID hostitelského serveru.

41



Obrázek 4.6: Tok poˇzadavk˚ u Zdroj: [22]

42



12. Nova-scheduler zaˇsle rpc.cast poˇzadavek na Nova-compute k zaloˇzen´ı nové instance na vybraném hostiteli. 13. Nova-compute vyzvedne poˇzadavek z fronty. 14. Nova-compute zaˇsle rpc.call poˇzadavek na nova-conductor k vyˇza´dán´ı podrobnˇejˇs´ıch informac´ı o hostiteli a parametrech (RAM, CPU, disk) nové instance. 15. Nova-conductor vyzvedne poˇzadavek z fronty. 16. Nova-conductor se dotazuje nova-database. 17. Jsou navráceny informace o instanci. 18. Nova-compute si vyzvedne informace o instanci z fronty. 19. Nova-compute provede REST volán´ı s tokenem uˇzivatele do Glance (sluˇzba databáze obraz˚ u) ke zjiˇstˇen´ı URL obrazu a nahrán´ı obrazu z u ´loˇziˇstˇe obraz˚ u. 20. Glance-api poˇza´dá Keystone o ovˇeˇren´ı uˇzivatelského tokenu a provede zadané u ´koly. 21. Nova-compute z´ıská metadata o obrazu (image) instance. 22. Nova-compute provede REST volán´ı s tokenem uˇzivatele do Neutron (s´ıt’ová sluˇzba) k alokaci a konfiguraci s´ıt’ov´ ych zdroj˚ u tak, aby instance z´ıskala IP adresu. 23. Neutron-server (dˇr´ıve quantum-server) poˇza´dá Keystone o ovˇeˇren´ı uˇzivatelského tokenu a provede alokaci zdroj˚ u. 24. Nova-compute obdrˇz´ı informace o s´ıti pro novou instanci. 25. Nova-compute provede REST volán´ı s tokenem uˇzivatele do Cinder (storage) k pˇripojen´ı svazku nové instanci. 26. Cinder-api poˇza´dá Keystone o ovˇeˇren´ı uˇzivatelského tokenu a provede alokaci svazku (disku). 27. Nova-compute obdrˇz´ı informace o blokovém zaˇr´ızen´ı (storage). 28. Nova-compute vygeneruje data pro ovladaˇc hypervisora a spust´ı poˇzadavek na vytvoˇren´ı instance (pˇres libvirt nebo API).

43


4.9

Ceilometer: mˇeˇren´ı zdroj˚ u

Ceilometer: mˇ eˇ ren´ı zdroj˚ u

Slouˇz´ı pro sbˇeru informac´ı o vyuˇz´ıván´ı zdroj˚ u v cloudu a tvorbu podklad˚ u pro vy´ uˇctován´ı. Architekturu ilustruje obr. 4.7.

Obrázek 4.7: Architektura Ceilometeru Zdroj: [11]

Ceilometer sb´ırá data o vyuˇz´ıván´ı zdroj˚ u od komponent v cloudu pro kaˇzdého uˇzivatele/projekt, zpracovává je a ukládá do své databáze. Následnˇe poskytuje v´ ystupy ve formˇe REST API pro pouˇzit´ı v dalˇs´ıch aplikac´ıch – jednou z takov´ ych aplikac´ı je i portál Horizon, kde je moˇzné pohodlnˇe prohl´ıˇzet v´ ystupy mˇeˇren´ı. Zaznamenává tˇri typy hodnot: 1. Kumulativn´ı (cumulative), rostou v ˇcase (napˇr. poˇcet hodin, po kterou je instance spuˇstˇena). 2. Diskr´ etn´ı hodnoty (gauge), napˇr. poˇcet pˇridˇelen´ ych plovouc´ıch IP adres. 3. Zmˇ enov´ e (delta), napˇr. pˇrenos dat po s´ıti.

44


Ostatn´ı komponenty

Jsou sledovány tyto parametry: 1. Nova: poˇcet instanc´ı, vyuˇzit´ı CPU, vyuˇzit´ı diskového I/O 2. Neutron: virtuáln´ı s´ıtˇe, routery, porty, IP adresy 3. Glance: velikost obraz˚ u, nahráván´ı a stahován´ı obraz˚ u 4. Cinder: poˇcet a velikost diskov´ ych jednotek

4.10

Ostatn´ı komponenty

Souˇca´st´ı OS Havana jsou jeˇstˇe dalˇs´ı komponenty, které nebyly souˇcást´ı poˇzadavk˚ u a proto nejsou zahrnuty do návrhu.

4.10.1

Swift

Swift je objektové u ´loˇziˇstˇe (obdoba Amazon S3), které je navrˇzeno pro bezpeˇcné ukládán´ı velkého mnoˇzstv´ı dat. Data jsou pˇr´ıstupná pˇres API a jsou ´ uloˇzena ve v´ıce kopi´ıch na r˚ uzn´ ych serverech pro maximáln´ı bezpeˇcnost. Uloˇziˇstˇe je kompletnˇe distribuované a velmi snadno ˇskálovatelné. Pro samotn´ y provoz navrˇzeného cloudu vˇsak nen´ı Swift vyˇzadován, data virtuáln´ıch server˚ u budou um´ıstˇena na existuj´ıc´ıch extern´ıch u ´loˇziˇst´ıch.

4.10.2

Heat

Obdoba AWS CloudFormation má za u ´kol pˇr´ıpravu spouˇstˇen´ı aplikac´ı na OpenStacku. Lze ji vyuˇz´ıt ke spuˇstˇen´ı pˇreddefinovan´ ych scénáˇr˚ u, tedy napˇr. spustit sadu webserver˚ u s nastaven´ ym load-balancerem a Drupalem. RedHat tuto komponentu vyuˇz´ıvá napˇr. pro nasazován´ı svého projektu OpenShift. V návrhu nen´ı zaˇrazen, nebot’ nejde o nezbytnou sluˇzbu.

45

ˇ alovatelnost a High Availability Sk´


4.11


Pro zajiˇstˇen´ı maximáln´ı dostupnosti a moˇznosti rozˇsiˇrován´ı sluˇzeb je nutné jiˇz v návrhu reflektovat tento poˇzadavek. Systémy vysoké dostupnosti HA se snaˇz´ı minimalizovat tato rizika: [23] 1. V´ ypadek syst´ emu: nastává, kdyˇz je poskytovaná sluˇzba nedostupná. 2. Ztr´ ata dat: zniˇcen´ı nebo poˇskozen´ı dat. D˚ uleˇzit´ ym aspektem projektován´ı HA systém˚ u je prevence rizikov´ ych m´ıst, které mohou zp˚ usobit pád celého systému (Single Points Of Failure, SPOFs). Tato m´ısta jsou zejména: 1. S´ıt’ov´ e komponenty, jako routery, switche 2. Aplikace 3. Datov´ au ´ loˇ ziˇ stˇ e 4. Sluˇ zby jako napájen´ı, klimatizace, poˇza´rn´ı systém Tato práce bude pokr´ yvat zejména zajiˇstˇen´ı vysoké dostupnosti u jednotliv´ ych komponent OpenStacku. Zajiˇstˇen´ı HA pro jednotlivé aplikace se liˇs´ı podle toho, jestli jde o stavovou nebo bezstavovou sluˇzbu. Bezstavová sluˇzba je taková, která po vyˇr´ızen´ı dotazu neprovád´ı ˇzádnou dalˇs´ı akci. Typick´ ym pˇr´ıkladem je protokol HTTP. V architektuˇre OS se jedná o sluˇzby: nova-api, nova-conductor, glance-api, keystone-api, neutron-api a nova-scheduler. U tˇechto sluˇzeb se HA zajiˇst’uje spuˇstˇen´ım v´ıce instanc´ı na r˚ uzn´ ych serverech, mezi kter´ ymi se provád´ı load-balancing, neboli vyvaˇzován´ı zátˇeˇze. Pro stavovou sluˇzbu je typické, ˇze následuj´ıc´ı poˇzadavek je závisl´ y na prvotn´ım poˇzadavku, takˇze nelze HA ˇreˇsit spuˇstˇen´ım v´ıce instanc´ı s vyvaˇzován´ım zátˇeˇze. Stavové sluˇzby v OS jsou centráln´ı databáze a fronta zpráv.

46



4.11.1

HA pro datab´ azi

Jako hlavn´ı databázov´ y server je pouˇzita MySQL. V n´ı lze HA ˇreˇsit v´ıce zp˚ usoby: Active/Passive – struktura poˇc´ıtá s nasazen´ım dvou server˚ u, pˇriˇcemˇz jeden je jako hlavn´ı (Active) a druh´ y jako záloˇzn´ı (Passive). Za bˇeˇzného provozu vˇsechny poˇzadavky vyˇr´ızuje hlavn´ı server a v pˇr´ıpadˇe v´ ypadku hlavn´ıho je provoz pˇrepnut na záloˇzn´ı.

Obrázek 4.8: Realizace HA pro MySQL pˇres DRBD a Pacemaker Zdroj: vlastn´ı zpracov´ an´ı na z´ akladˇ e [35]

Technicky je to ˇreˇseno tak, ˇze se databáze ukládaj´ı na DRBD4 , coˇz je blokové zaˇr´ızen´ı synchronizované pˇres s´ıt’ (obdoba RAID5 ). Oba servery maj´ı své IP adresy a krom toho jeˇstˇe jednu virtuáln´ı (Virtual IP, VIP), kterou si 4 5

Distributed Replicated Block Device, detaily na: http://www.drbd.org/ Redundant Array of Inexpensive/Independent Disks

47



mezi sebou pˇredávaj´ı podle toho, kter´ y server je v provozu. Právˇe na tuto IP se pˇripojuj´ı ostatn´ı sluˇzby. Na obou serverech je nainstalován Pacemaker, kter´ y kontroluje dostupnost druhého serveru a podle potˇreby provád´ı nastavené akce (spuˇstˇen´ı sluˇzby na záloˇzn´ım serveru v pˇr´ıpadˇe v´ ypadku, pˇrevzet´ı virtuáln´ı IP, . . . ). Proces je znázornˇen na obr. 4.8. Tento zp˚ usob nicménˇe neumoˇzn ˇuje rozkládán´ı zátˇeˇze a proto se nehod´ı pro systémy, kde potˇreba ˇskálován´ı. Active/Active – tento zp˚ usob poˇc´ıtá s vybudován´ım MySQL clusteru, kter´ y provád´ı synchronn´ı replikaci InnoDB databáz´ı, jak naznaˇcuje obr. 4.9. Lze pouˇz´ıt MySQL cluster6 nebo Galera cluster7 , pˇriˇcemˇz druh´ y zmiˇ novan´ y nab´ız´ı témˇeˇr dvojnásobnou propustnost oproti MySQL clusteru [7]; vol´ıme tedy ˇreˇsen´ı pomoc´ı Galera clusteru. V´ yhodou tohoto ˇreˇsen´ı je, ˇze lze pouˇz´ıt v´ıce server˚ u, vˇsechny jsou v provozu a vˇsechny vyˇrizuj´ı poˇzadavky. Kromˇe zajiˇstˇen´ı vysoké dostupnosti lze pomoc´ı takto vytvoˇreného clusteru i ˇskálovat. Je ale nutné vyuˇz´ıt loadbalancer, at’ uˇz hardwarov´ y nebo softwarov´ y (HAproxy + Keepalived). Pro zajiˇstˇen´ı HA a snadné ˇskálovatelnosti autor práce doporuˇcuje realizaci formou databázového clusteru Galera.

4.11.2

HA pro frontu zpr´ av

Pro správu fronty (Advanced Message Queuing Protocol, AMQP) OpenStack vyuˇz´ıvá program RabbitMQ. Ten má podporu pro implementaci clusteru jiˇz zabudovanou, takˇze staˇc´ı provést instalaci na vybran´ y poˇcet uzl˚ u a provést 8 drobnou u ´pravu nastaven´ı . Nen´ı tˇreba vyuˇz´ıvat load-balancer, postaˇc´ı upravit konfiguraci sluˇzeb OpenStacku, které s frontou pracuj´ı: rabbit_hosts=rabbit1:5672,rabbit2:5672 6

http://www.mysql.com/products/cluster/ http://galeracluster.com/ 8 Detaily lze nalézt na: http://docs.openstack.org/high-availability-guide/ content/_configure_rabbitmq.html 7

48



Obrázek 4.9: Realizace HA pro MySQL pˇres Galera a HAproxy. Zdroj: [49]

4.11.3

HA pro ostatn´ı sluˇ zby

Zajiˇstˇen´ı vysoké dostupnosti ostatn´ıch sluˇzeb je ˇreˇseno instalac´ı na dva servery v reˇzimu Active/Passive. Pˇres HAproxy procház´ı veˇskerá komunikace na dané sluˇzby. Ta se stará o správnˇe nasmˇerován´ı poˇzadavk˚ u podle toho, kter´ y server je v provozu. HAproxy by mˇel b´ yt replikovan´ y, aby netvoˇril SPOF.

4.11.4

Sch´ ema n´ avrhu kompletn´ıho HA

Obrázek 4.10 shrnuje návrh HA ˇreˇsen´ı. Obsahuje dva ˇr´ıd´ıc´ı uzly (Controller node 1 a 2), na kter´ ych bˇeˇz´ı sluˇzby, u nichˇz chceme zajistit HA. Jak jiˇz v´ıme z pˇredchoz´ıch kapitol, MySQL a RabbitMQ nemus´ı b´ yt v reˇzimu Active/Passive, ale pro zjednoduˇsen´ı jsou zahrnuty do naˇcrtnut´ ych ˇr´ıd´ıc´ıch uzl˚ u, pˇriˇcemˇz replikace je u nich Active/Active. Pro pˇrep´ınán´ı Active/Passive sluˇzeb je nainstalován HAproxy. V návrhu je zdvojen´ y, pˇriˇcemˇz v pˇr´ıpadˇe nedostatku hardware je moˇzné jednotlivé instance nainstalovat pˇr´ımo na ˇr´ıd´ıc´ı uzly. Vˇsechny sluˇzby, které se k HA 49



MySQL Cluster

MySQL Cluster

Virtual IP (10.1.1.111)

Obrázek 4.10: Návrh HA architektury OpenStacku Zdroj: vlastn´ı zpracov´ an´ı

OpenStacku pˇripojuj´ı vyuˇz´ıvaj´ı virtuáln´ı IP (VIP) HAproxy, tedy 10.1.1.111.

50


Zálohovac´ı schéma

MySQL a RabbitMQ cluster lze vyuˇz´ıt bud’ napˇr´ımo (napˇr. pˇres roundrobin DNS) nebo také pˇres HAproxy. Autor doporuˇcuje pouˇz´ıt HAproxy, protoˇze jiˇz vyuˇzita i pro ostatn´ı komponenty návrhu.

4.12

Z´ alohovac´ı sch´ ema

Pˇri zálohován´ı komponent OpenStacku je tˇreba provést zálohu centráln´ı databáze a pak také vˇsech konfiguraˇcn´ıch soubor˚ u jednotliv´ ych sluˇzeb. Zálohu zvolené databáze MySQL lze provést pˇres konzolov´ y program mysqldump, kter´ y je souˇca´st´ı distribuce. V tomto pˇr´ıpadˇe vˇsak dojde k doˇcasnému uzamknut´ı tabulek po dobu provádˇen´ı zálohy. Zálohu pˇres mysqldump provedeme následuj´ıc´ım pˇr´ıkazem, v´ ystupem bude soubor openstack.sql obsahuj´ıc´ı data vˇsech databáz´ı: # mysqldump --all-databases > openstack.sql Pokud potˇrebujeme zajistit dostupnost i pˇri prob´ıhaj´ıc´ı záloze, je moˇzné vyuˇz´ıt open-source software Percona XtraBackup9 , kter´ y umoˇzn ˇuje provádˇet zálohy MySQL InnoDB bez pˇreruˇsen´ı provozu. Pro proveden´ı zálohy vˇsech databáz´ı ze standardn´ıho datového adresáˇre (je uveden v konfiguraˇcn´ım souboru /etc/my.cnf) do sloˇzky /data/backups spust´ıme pˇr´ıkaz: # innobackupex /data/backups

Nova Na v´ ypoˇcetn´ım i ˇr´ıd´ıc´ım uzlu je nutné provádˇet zálohu adresáˇr˚ u /etc/nova a /var/lib/nova s v´ yjimkou /var/lib/nova/instances na v´ ypoˇcetn´ım uzlu, kde jsou uloˇzeny obrazy virtuáln´ıch server˚ u (pokud nen´ı vyuˇzit Cinder) – nen´ı doporuˇceno takto zálohovat bˇeˇz´ıc´ı servery, protoˇze hroz´ı riziko, ˇze bude záloha poˇskozena. Pro zálohován´ı samotn´ ych server˚ u je vhodné vyuˇz´ıt LVM snapshoty, které lze provést i u bˇeˇz´ıc´ı instance. 9

Detaily lze nalézt na: http://www.percona.com/software/percona-xtrabackup

51


Zálohovac´ı schéma

Snapshoty lze vytvoˇrit pˇres portál (Project → Instances → Create Snapshot), nebo pˇres pˇr´ıkazovou ˇra´dku: # cinder snapshot-create --display-name N´ AZEV ID_JEDNOTKY

Glance Na uzlu obsahuj´ıc´ım obrazy server˚ u je nutné zálohovat adresáˇre /etc/glance a /var/lib/glance.

Keystone Pro sluˇzbu identity staˇc´ı zálohovat adresáˇr /etc/keystone.

Cinder Blokové u ´loˇziˇstˇe má uloˇzenou konfiguraci v adresáˇri /etc/cinder, kter´ y je tedy nutn´ y zálohovat.

Horizon Konfiguraˇcn´ı soubor portálu je ve sloˇzce /etc/openstack-dashboard.

4.12.1

Obnova

V pˇr´ıpadˇe obnovy databáze je nutné nejprve zastavit vˇsechny sluˇzby, které ji vyuˇz´ıvaj´ı (tedy pro databázi nova vˇsechny procesy nova-* ) a poté provést obnovu: # mysql nova < nova.sql Pokud je tˇreba obnovit ze zálohy cel´ y server, je nutné ho znovu nainstalovat a ze zálohy obnovit potˇrebné konfiguraˇcn´ı soubory nebo databázi (záleˇz´ı na tom, jak´ y mˇel dotyˇcn´ y server roli, tedy co na nˇem bylo nainstalováno). 52


4.13

Logován´ı

Logov´ an´ı

OpenStack standardnˇe zapisuje logy do adresáˇre /var/log. Pˇri vzr˚ ustaj´ıc´ım poˇctu server˚ u ale nen´ı vhodné m´ıt logy uchované na kaˇzdém serveru zvláˇst’, ale zapnout centráln´ı logován´ı. Kromˇe snadnˇejˇs´ı anal´ yzy je t´ım zajiˇstˇena i vˇetˇs´ı bezpeˇcnost log˚ u (napˇr. pˇri kompromitaci konkrétn´ıho serveru). Autor doporuˇcuje vyuˇz´ıvat centráln´ıho logován´ı. Syslog, kter´ y OpenStack podporuje, umoˇzn ˇuje zapnout logován´ı pˇres s´ıt’. Pro jeho aktivaci je nutné v konfiguraci (napˇr. /etc/nova/nova.conf) zapnout pouˇzit´ı syslogu: use_syslog=True syslog_log_facility=LOG_LOCAL0 Dále je nutné nakonfigurovat syslog, aby komunikoval pˇres s´ıt’ se serverem. Provedeme to vytvoˇren´ım souboru /etc/rsyslog.d/client.conf s t´ımto obsahem: *.* @192.168.1.1 Nam´ısto IP 192.168.1.1 vloˇz´ıme adresu centráln´ıho syslog serveru.

4.13.1

Historie IP adres

Jedn´ım z poˇzadavk˚ u zadavatele bylo znát historii pˇridˇelovan´ ych IP adres, aby bylo moˇzné vystopovat konkrétn´ıho uˇzivatele (server), kter´ y mˇel pˇridˇelenou urˇcitou IP v daném ˇcase (napˇr. kv˚ uli pˇr´ıpadn´ ym st´ıˇznostem na nelegáln´ı aktivitu). Databáze OpenStacku nedisponuje histori´ı pˇridˇelen´ ych adres, proto je nutné situaci ˇreˇsit jinak. Jsou k dispozici dva zp˚ usoby. Prvn´ım z nich je obyˇcejné ruˇcn´ı (pˇr´ıpadnˇe skriptem zautomatizované) procházen´ı textov´ ych log˚ u, kam se zapisuje pˇri vytváˇren´ı serveru pˇridˇelená IP adresa. Jde o ménˇe pohodln´ y zp˚ usob, ale je velmi snadno technicky realizovateln´ y a nevyˇzaduje ˇzádné dalˇs´ı u ´pravy. 53


Monitoring

Druh´ ym zp˚ usobem je odchytáván´ı AMQP zpráv z fronty OpenStacku, coˇz umoˇzn ˇuje napˇr´ıklad program yagi10 . Takto z´ıskané informace je nutné dále zpracovat a uloˇzit si je do vlastn´ı datové struktury, ve které se bude uchovávat poˇzadovaná historie. Tento pˇr´ıstup je v´ıce pracnˇejˇs´ı, nebot’ vyˇzaduje instalaci dodateˇcného software, jeho konfiguraci a navrˇzen´ı vlastn´ı datové struktury na ukládán´ı dat vˇcetnˇe obsluˇzn´ ych skript˚ u prot vyhledáván´ı dat.

4.14

Monitoring

Pro zajiˇstˇen´ı bezproblémového bˇehu je d˚ uleˇzité monitorovat jak provozn´ı veliˇ ˇciny, tak stav sluˇzeb. Na ZCU je vyuˇz´ıván monitorovac´ı systém Nagios, proto budou v tomto návrhu zm´ınˇeny základn´ı postupy pro tento systém. Kromˇe n´ıˇze naznaˇcen´ ych postup˚ u existuje také bal´ık nagios-plugins-openstack pro Debian, kter´ y obsahuje skripty pro testován´ı nˇekter´ ych komponent (Glance, Keystone, Nova-API a Swift). Dalˇs´ı informace poskytne také ˇclánek Some practical considerations for monitoring in OpenStack cloud 11 .

4.14.1

Procesy

Bˇeh sluˇzeb lze monitorovat základn´ım zp˚ usobem tak, ˇze se zkontroluje tabulka proces˚ u systému. N´ıˇze uveden´ y pˇr´ıklad zkontroluje, zda na v´ ypoˇcetn´ım uzlu bˇeˇz´ı sluˇzba nova-compute. Do konfigurace Nagios serveru se pˇridá následuj´ıc´ı: define service { host_name cloud-102.civ.zcu.cz check_command check_nrpe_1arg!check_nova-compute use generic-service notification_period 24x7 contact_groups sysadmins service_description nova-compute } 10 11

Detaily lze nalézt na: https://github.com/rackerlabs/yagi http://www.mirantis.com/blog/openstack-monitoring/

54


Monitoring

Na v´ ypoˇcetn´ı uzel (cloud-102.civ.zcu.cz) je nainstalován NRPE12 a pˇridána tato ˇra´dka do konfigurace: command[check_nova-compute]=/usr/lib/nagios/plugins/check_procs -c 1: -a nova-compute Uveden´ y postup se zopakuje pro vˇsechny monitorované procesy.

4.14.2

Provozn´ı veliˇ ciny

Dále je vhodné monitorovat vyuˇzit´ı zdroj˚ u na serverech, zejména zátˇeˇz, obsazenost disku, vyuˇzit´ı pamˇeti RAM ˇci s´ıt’ové I/O. Toto lze monitorovat napˇr. pˇres SNMP nebo pˇres jiˇz zm´ınˇen´ y Nagios. Pˇr´ıklad konfigurace Nagiosu pro varován´ı o docházej´ıc´ım m´ıstu na disku: define service { host_name cloud-102.civ.zcu.cz check_command check_nrpe!check_all_disks!20% 10% use generic-service contact_groups sysadmins service_description Disk } Na monitorovaném serveru je do konfigurace NRPE pˇridána tato ˇrádka: command[check_all_disks]=/usr/lib/nagios/plugins/check_disk -w $ARG1$ -c $ARG2$ -e Pˇri poklesu volného m´ısta pod 20 % se v Nagiosu zobraz´ı varován´ı a pˇri poklesu pod 10 % chyba. 12

NRPE - Nagios Remote Plugin Executor

55


4.15

Bezpeˇcnost, hesla

Bezpeˇ cnost, hesla

Otázka bezpeˇcnosti OpenStacku je velmi rozsáhlá a je k tomuto tématu vydána samostatná pˇr´ıruˇcka13 . Tato kapitola se tedy bude vˇenovat jen základn´ımu popisu toho, jak je zabezpeˇcen´ı ˇreˇseno a zm´ın´ı nˇekolik doporuˇcen´ı.

RabbitMQ Po instalaci serveru pro v´ ymˇenu zpráv RabbitMQ je vytvoˇren automaticky uˇzivatel guest s heslem guest, proto je nutné toto heslo pˇred prvn´ım pouˇzit´ım zmˇenit: rabbitmqctl change_password guest NOV´ E_HESLO V´ yˇse nastavené heslo se pak mus´ı uvádˇet v konfiguraˇcn´ım souboru kaˇzdé komponenty, která se k serveru pˇripojuje (parametr rabbit_password).

Webov´ e sluˇ zby Jak webov´ y portál Horizon, tak vˇsechna REST14 API jednotliv´ ych kompo15 nent pracuj´ı na protokolu HTTP , kter´ y je standardnˇe nezabezpeˇcen´ y a pro vyˇsˇs´ı bezpeˇcnost je doporuˇceno vyuˇz´ıt SSL16 u veˇskeré komunikace. Jelikoˇz u API nen´ı SSL nativnˇe podporováno OpenStackem, je nutné vyuˇz´ıt libovolnou SSL proxy (Pound, Stud, Apache, nginx, . . . ).

Datab´ aze Jednotlivé komponenty se pˇripojuj´ı k centráln´ı databázi MySQL. Standardnˇe je komunikace neˇsifrovaná, tud´ıˇz je doporuˇceno nakonfigurovat MySQL server 13

Kompletn´ı verze k dispozici na: http://docs.openstack.org/security-guide/ content/ 14 Representational State Transfer 15 Hypertext Transfer Protocol 16 Secure Sockets Layer

56


Aktualizace systému

na podporu SSL nebo vyuˇz´ıt pro spojen´ı komponent s databáz´ı oddˇelenou privátn´ı s´ıt’ (pˇr´ıpadnˇe VPN17 ). Pro zapnut´ı SSL na MySQL je nutné m´ıt vygenerován certifikát (veˇrejn´ y i privátn´ı kl´ıˇc) a v souboru /etc/my.cnf nastavit cesty k tomuto certifikátu: [mysqld] ssl-cert=/path/to/ssl/server-cert.pem ssl-key=/path/to/ssl/server-key.pem Kaˇzdá komponenta je registrována v Keystone a má vlastn´ı uˇzivatelské jméno a heslo, kter´ ym se k nˇemu pˇripojuje. Toto heslo je (zaˇsifrovanˇe) uloˇzeno v databázi Keystone a v ˇcisté podobˇe v konfiguraˇcn´ım souboru dané komponenty. Kromˇe toho vˇetˇsina z nich pouˇz´ıvá databázi MySQL, ke které má vlastn´ı uˇzivatelské jméno, heslo i databázi.

4.16

Aktualizace syst´ emu

Jak bylo naznaˇceno v pˇredchoz´ıch kapitolách, OpenStack je velmi ˇzivˇe vyv´ıjen´ y projekt. V´ yvojov´ y plán zahrnuje kaˇzd´ ych 6 mˇes´ıc˚ u vydán´ı nové hlavn´ı (major) verze. Krom toho vycház´ı také drobné aktualizace v rámci aktuáln´ı verze, které je nutné instalovat. Drobné aktualizace nejsou problémem a jejich instalace je moˇzná s minimáln´ım pˇreruˇsen´ım sluˇzeb, coˇz si autor ovˇeˇril v pr˚ ubˇehu prac´ı na praktické ˇcásti. Vˇetˇs´ım problémem je pˇrechod následuj´ıc´ı hlavn´ı (major) verzi, která kromˇe pˇridáván´ı nov´ ych vlastnost´ı ˇcasto zasahuje do souˇcasné struktury. To má za následek nutnost u ´pravy konfiguraˇcn´ıch soubor˚ u apod. Vzhledem ke sloˇzitost´ı celého systému je velmi d˚ uraznˇe doporuˇceno [37], aby si administrátor cloudu pˇripravil kopii ostrého prostˇred´ı, na nˇem otestoval proveditelnost aktualizace a teprve poté provedl aktualizaci provozn´ıho cloudu s odstávkou sluˇzeb. 17

Virtual Private Network

57


4.17

Moˇznosti pˇr´ıstupu

Moˇ znosti pˇ r´ıstupu

OpenStack poskytuje nˇekolik zp˚ usob˚ u, jak ho spravovat: • Webov´ y portál Horizon. • REST API jednotliv´ ych sluˇzeb, které je moˇzné vyuˇz´ıvat v´ıce zp˚ usoby: – Pˇr´ıstup z libovolné vlastn´ı aplikace. – Konzolové programy v Pythonu, které jsou souˇca´st´ı distribuce. – Knihovny v Pythonu, které jsou souˇca´st´ı distribuce a které lze pouˇz´ıt pro usnadnˇen´ı pˇr´ıstupu z vlastn´ıch Python program˚ u. Pˇredpokladem pro vˇsechny metody pˇr´ıstupu je platn´ y uˇzivatelsk´ yu ´ˇcet v Keystone.

58

5 Realizace pilotn´ıho nasazen´ı Pro ovˇeˇren´ı realizovatelnosti navrˇzené architektury bylo uskuteˇcnˇeno pilotn´ı nasazen´ı, bˇehem kterého byla ovˇeˇrena jak funkˇcnost navrˇzeného celku, tak i ˇ kompatibilita s existuj´ıc´ım prostˇred´ım na ZCU. Pilotn´ı nasazen´ı si neklade za c´ıl b´ yt pˇresnou a kompletn´ı realizac´ı návrhu, n´ ybrˇz sp´ıˇse konceptem, kter´ y se bude dále rozv´ıjet. I vzhledem k omezen´ ym moˇznostem z hlediska dostupného hardwarového vybaven´ı bylo nutné pˇri nasazen´ı pˇristoupit k nˇekter´ ym kompromis˚ um. Vˇsechny odchylky od návrhu jsou v textu práce zm´ınˇeny a zd˚ uvodnˇeny.

5.1

Testovac´ı hardware

Pro pilotn´ı nasazen´ı OpenStacku byly ze zdroj˚ u CIV poskytnuty tˇri servery. Prvn´ı fyzick´ y server (cloud-101) byl pouˇzit na um´ıstˇen´ı vˇsech kontroln´ıch souˇcást´ı OpenStacku. Dalˇs´ı dva servery (cloud-102 a cloud-001) poslouˇzily pro hostován´ı vytvoˇren´ ych virtuáln´ıch stroj˚ u. Kaˇzd´ y server má dvˇe s´ıt’ové karty, prvn´ı je pˇripojen do Internetu a druhá slouˇz´ı pro vnitˇrn´ı komunikaci mezi servery. Obˇe rozhran´ı jsou pˇripojeny na gigabitov´ y switch. ´ cel Uˇ Veˇ rejn´ a IP Priv´ atn´ı IP Procesor J´ adra/vl´ akna Pamˇ et’ RAM Disk

cloud-101 Controller 147.228.253.111 192.168.1.111 1× Intel E5-2420 6/12 16 GB 2× 300 GB

cloud-102 Compute 147.228.253.112 192.168.1.112 2× Intel X5560 4/8 32 GB 2× 300 GB

cloud-001 Compute 147.228.253.11 192.168.1.11 2× Intel 5150 2/2 8 GB 2× 250 GB

Tabulka 5.1: Parametry hardware pro pilotn´ı nasazen´ı Zdroj: vlastn´ı zpracov´ an´ı

59

Realizace pilotn´ıho nasazen´ı

5.2

Software

Software

Pro provoz je vyuˇzita standardn´ı provozn´ı instalace operaˇcn´ıho systému na CIV, která je zaloˇzena na Debian 7. Aˇckoliv je jako doporuˇcená distribuce pro nasazen´ı OpenStacku oznaˇcováno Ubuntu LTS, pouˇzit´ y Debian patˇr´ı rovnˇeˇz mezi podporovan´ y a pˇri nasazen´ı nenastaly ˇza´dné pot´ıˇze pramen´ıc´ı z volby této distribuce. Pro pilotn´ı nasazen´ı byl pouˇzit OpenStack ve verzi Havana, která byla v dobˇe nasazen´ı (listopad 2013) aktuáln´ı.

5.2.1

Z´ akladn´ı konfigurace

Vˇsechny servery, na kter´ ych budou provozovány komponenty OpenStacku, mus´ı b´ yt pˇripraveny identick´ ym v´ ychoz´ım zp˚ usobem. Zahrnuje to pˇredevˇs´ım 1 instalaci NTP , d´ıky kterému se bude ˇcas v rámci clusteru správnˇe synchronizovat. Je doporuˇceno, aby ˇcas zvenˇc´ı pˇreb´ıral pouze jeden centráln´ı server a vˇsechny ostatn´ı pˇreb´ıraly ˇcas od nˇej. Toho lze doc´ılit u ´pravou souboru /etc/ntp.conf: server Ostatn´ı servery z konfigurace odstran´ıme. Dalˇs´ım krokem je pˇridán´ı oficiáln´ıch repozitáˇr˚ u do /etc/apt/sources.list: deb http://archive.gplhost.com/debian havana-backports main deb http://archive.gplhost.com/debian havana main Poté je nutné aktualizovat lokáln´ı databázi a nainstalovat kl´ıˇc repozitáˇre: # apt-get update && apt-get install gplhost-archive-keyring Dále je nutné nainstalovat bal´ıky python-mysqldb a python-argparse. 1

Network Time Protocol

60


5.3

Rozloˇzen´ı komponent

Rozloˇ zen´ı komponent

Jak jiˇz bylo zm´ınˇeno dˇr´ıve, OpenStack je tvoˇren nˇekolika samostatn´ ymi komponentami. Tyto je vhodné v ostrém provozu um´ıstit na samostatné servery, nicménˇe vzhledem k omezenému mnoˇzstv´ı fyzick´ ych server˚ u pro pilotn´ı provoz bylo nutné ˇr´ıd´ıc´ı servery virtualizovat, jak ilustruje obr. 5.1.

Virtualizace KVM Nova-compute MySQL Keystone (identita) Nova (řízení) Horizon (webgui) Glance (obrazy)

...

Virtualizace KVM Nova-compute

Neutron (síť)

...

Cinder (ukládání)

Obrázek 5.1: Rozloˇzen´ı sluˇzeb v realizované architektuˇre Zdroj: vlastn´ı zpracov´ an´ı

Technicky by sice bylo moˇzné vˇsechny sluˇzby nainstalovat na jeden server, avˇsak realizované ˇreˇsen´ı je praktiˇctˇejˇs´ı z hlediska budouc´ıho rozvoje – jednotlivé virtualizované servery lze snadno pˇresunout na vlastn´ı fyzick´ y server nebo jim dle potˇreby nav´ yˇsit zdroje (pamˇet’ ˇci CPU). 61


Controller node

V pilotn´ım provozu bylo upuˇstˇeno od ˇreˇsen´ı vysoké dostupnosti, jehoˇz návrh byl detailnˇe popsán v kap. 4.11. Autor doporuˇcuje zváˇzit implementaci HA v ostrém provozu, aˇckoliv vzhledem k projektovanému vyuˇzit´ı je moˇzné se spokojit se souˇcasn´ ym modelem typu best-effort2 .

5.4

Controller node

ˇ ıd´ıc´ı uzel tvoˇr´ı zásadn´ı ˇca´st celé infrastruktury. Jako prvn´ı byla na server R´ nainstalována centráln´ı databáze MySQL, na které závis´ı vˇsechny ostatn´ı sluˇzby: # apt-get install python-mysqldb mysql-server Instalace bal´ıˇcku neprovede inicializaci databáze, coˇz je nutné provést ruˇcnˇe. Zároveˇ n je vhodné ihned nastavit heslo správce (root), coˇz se realizuje programem mysql_secure_installation: # mysql_install_db # mysql_secure_installation Druh´ y v poˇrad´ı byl následoval server pro v´ ymˇenu zpráv v rámci clusteru RabbitMQ, kterému je vhodné ihned po instalaci zmˇenit uˇzivatelské heslo: # apt-get install rabbitmq-server # rabbitmqctl change_password guest NOV´ E_HESLO Hned poté následoval správce identit Keystone vˇc. konzolového klienta: # apt-get install keystone python-keystoneclient Postinstalaˇcn´ı proces konfigurace prob´ıhá pˇres program debconf, kter´ y nás postupnˇe vyzve k zadán´ı ˇrady potˇrebn´ ych promˇenn´ ych – napˇr. vlastn´ı

62


Controller node

Obrázek 5.2: Prostˇred´ı debconf pro konfiguraci Zdroj: [39]

administraˇcn´ı token, jak ukazuje obr. 5.2. Debconf také zajist´ı napojen´ı jednotliv´ ych komponent OpenStacku do registru v Keystone, ˇc´ımˇz usnadn´ı ˇca´st konfigurace. Následnˇe byl na server nainstalován Glance, kter´ y spravuje databázi obraz˚ u (images) virtuáln´ıch server˚ u. Glance vyuˇz´ıvá v pilotn´ım provozu pro ukládán´ı obraz˚ u virtuáln´ıch server˚ u lokáln´ı u ´loˇziˇstˇe, ale pro ostr´ y provoz by bylo vhodnˇejˇs´ı vyuˇz´ıt extern´ıho. V aktuáln´ı verzi OpenStacku (Havana) vˇsak nen´ı plnˇe dokonˇcena podpora Cinderu jako u ´loˇziˇstˇe dat pro Glance3 . # apt-get install glance python-glanceclient ˇ ıd´ıc´ı komponentu v´ R´ ypoˇcetn´ıho clusteru (Nova) nainstalujeme vˇcetnˇe vˇsech podp˚ urn´ ych ˇcást´ı pˇr´ıkazem: # apt-get install nova-consoleproxy nova-api \ nova-cert nova-conductor nova-consoleauth \ nova-scheduler python-novaclient Posledn´ı nainstalovanou komponentou je webov´ y portál Horizon: # apt-get install memcached libapache2-mod-wsgi \ openstack-dashboard openstack-dashboard-apache 2

Nen´ı garantov´ ana spolehlivost sluˇzby. V´ıce informac´ı o (ne)podpoˇre: http://docs.openstack.org/developer/glance/ configuring.html#configuring-the-cinder-storage-backend 3

63


Controller node

Konfiguraˇcn´ı soubory pro vˇsechny instalované komponenty jsou vzhledem ke svému rozsahu um´ıstˇeny na pˇriloˇzeném CD v adresáˇri /config.

5.4.1

Obrazy server˚ u

Jak jiˇz bylo zm´ınˇeno, komponenta Glance spravuje obrazy virtuáln´ıch server˚ u. V základn´ı instalaci nen´ı obsaˇzen ˇza´dn´ y obraz a je nutné si obrazy nejprve naimportovat. Jsou podporovány následuj´ıc´ı formáty obraz˚ u: • raw • vhd (VMWare, Xen, Microsoft, VirtualBox, . . . ) • vmdk • vdi (VirtualBox, QEMU) • iso • qcow2 (QEMU, KVM) • aki, ari, ami (Amazon kernel, ramdisk, machine) V rámci testovac´ıho provozu byly na cloud nahrány následuj´ıc´ı obrazy: • CirrOS 0.3.1, kter´ y slouˇz´ı jako minimáln´ı distribuce pˇredevˇs´ım pro otestován´ı správné funkˇcnosti. • CentOS 6.5 • Ubuntu 12.04 LTS Obrazy pro dalˇs´ı operaˇcn´ı systémy lze bud’ stáhnout, k ˇcemuˇz nab´ız´ı dokumentace OpenStacku ˇradu odkaz˚ u4 , nebo vytvoˇrit svépomoc´ı podle velmi podrobného návodu z dokumentace OS5 . Import m˚ uˇze prob´ıhat bud’ pˇres portál nebo pomoc´ı konzolového klienta: 4

Detaily na: http://docs.openstack.org/image-guide/content/ch_obtaining_ images.html 5 V´ıce informac´ı na: http://docs.openstack.org/image-guide/content/ch_ creating_images_manually.html

64


Storage node

# wget -O cirros.img http://download.cirros-cloud.net/0.3.2/\ cirros-0.3.2-x86_64-disk.img # glance image-create --name=CirrOS --disk-format=qcow2 \ --container-format=bare --is-public=true < cirros.img Glance pˇres v´ yˇse uvedené formáty podporuje ˇsirokou paletu operaˇcn´ıch systému – Linux, Windows, FreeBSD, . . . Je dostupná kontextualizace obraz˚ u ve formˇe nahrán´ı uˇzivatelsk´ ych SSH kl´ıˇc˚ u pˇri vytváˇren´ı. Je nutné, aby mˇel uˇzivatel pˇredem pˇripraven´ y sv˚ uj kl´ıˇc a veˇrejnou ˇca´st nahrál pˇres portál nebo API.

5.5

Storage node

Uzel s diskov´ ym u ´loˇziˇstˇem byl realizován jako samostatn´ y virtuáln´ı server. Cinder pracuje pˇr´ımo s intern´ım u ´loˇziˇstˇem (v obrázku 5.3 /dev/hda), které dále rozdˇeluje pomoc´ı LVM a tyto svazky propojuje s compute node (Nova) pomoc´ı iSCSI. Prvn´ım krokem bylo vytvoˇren´ı LVM na serveru (/dev/xvdb je lokáln´ı disk) a vytvoˇren´ı svazku (VG) se jménem cinder-volumes, na kterém pak bude Cinder vytváˇret logické svazky (LV): # pvcreate /dev/xvdb # vgcreate cinder-volumes /dev/xvdb Po základn´ı instalaci (viz kap. 5.2.1) byly na server nainstalovány potˇrebné bal´ıky: # apt-get install cinder-api cinder-scheduler cinder-volume Konfiguraˇcn´ı soubor je vzhledem ke svému rozsahu um´ıstˇen na pˇriloˇzeném CD v adresáˇri /config.

65


Networking node

Nova

Cinder

VM instance /dev/vda

KVM

Linux Volume Manager

iSCSI initiator

iSCSI target

/dev/hda

Obrázek 5.3: Storage server s intern´ım uloˇziˇstˇem Zdroj: [52]

5.6

Networking node

S´ıt’ov´ y uzel tvoˇr´ı rozhran´ı mezi internetem a privátn´ı s´ıt´ı, na kterou jsou um´ıstˇené (nejen) samotné virtuáln´ı servery. Procház´ı j´ım tedy veˇskerá komunikace virtuáln´ıch server˚ u s vnˇejˇs´ım svˇetem. Je um´ıstˇen na samostatném virtuáln´ım serveru, protoˇze jde o komponentu, kde se oˇcekává vyˇsˇs´ı zátˇeˇz pˇri provozu. Obrázek 5.4 zachycuje navrˇzené schéma s´ıtˇe. Veˇsker´ y datov´ y tok z virtua´ln´ıho serveru procház´ı pˇres intern´ı s´ıt’ a s´ıt’ov´ y uzel (IP 192.168.1.114). Pˇri pilotn´ım nasazen´ı bylo upuˇstˇeno od realizace varianty s GRE tunely a VLANy. Realizavn´ y pilotn´ı provoz pracuje s FLAT modelem s´ıtˇe, kde nejsou jednotlivé virtuáln´ı servery izolovány. Po u ´vodn´ı pˇr´ıpravˇe serveru (kap. 5.2.1) nainstalujeme bal´ıky komponenty

66


Networking node

eth1 192.168.1.114

eth0 147.228.253.114

eth1 192.168.1.11

Networking

Compute node 1 eth1 192.168.1.113

eth0 147.228.253.113

Public network

eth1 192.168.1.112

Private network Controller

Compute node 2

eth1 192.168.1.115

Storage

Obrázek 5.4: Schéma s´ıtˇe a zakreslen´ı toku dat z virtuáln´ıho serveru Zdroj: vlastn´ı zpracov´ an´ı

Neutron: # apt-get install neutron-server neutron-dhcp-agent \ neutron-plugin-openvswitch-agent neutron-l3-agent Dále je nutné upravit soubor /etc/sysctl.conf, aby s´ıt’ov´ y uzel mohl ˇr´ıdit provoz jednotliv´ ych instanc´ı: net.ipv4.ip_forward=1 net.ipv4.conf.all.rp_filter=0 net.ipv4.conf.default.rp_filter=0 67


Compute node

K propagaci zmˇen v souboru pouˇzijeme pˇr´ıkaz sysctl -p. Konfiguraˇcn´ı soubor je vzhledem ke svému rozsahu um´ıstˇen na pˇriloˇzeném CD v adresáˇri /config.

5.7

Compute node

V rámci pilotn´ıho provozu byly nainstalovány a pˇripraveny dva v´ ypoˇcetn´ı uzly (cloud-102 a cloud-001, viz. tabulka 5.1), oba s identickou softwarovou konfigurac´ı. Po základn´ı pˇr´ıpravˇe (kap. 5.2.1) provedeme instalaci potˇrebn´ ych bal´ık˚ u: # apt-get install nova-compute-kvm python-guestfs \ openstack-compute-node Kaˇzd´ y dalˇs´ı v´ ypoˇcetn´ı uzel se pˇridá tak, ˇze po proveden´ı v´ yˇse uvedeného postupu z libovolného existuj´ıc´ıho v´ ypoˇcetn´ıho nebo ˇr´ıd´ıc´ıho uzlu pˇrekop´ırujeme soubor /etc/nova/nova.conf, ve kterém uprav´ıme IP adresu u poloˇzek my_ip, vncserver_listen a vncserver_proxyclient_address. Konfiguraˇcn´ı soubor je vzhledem ke svému rozsahu um´ıstˇen na pˇriloˇzeném CD v adresáˇri /config.

5.8

Ceilometer

Instalaci komponenty pro mˇeˇren´ı vyuˇz´ıván´ı zdroj˚ u je nutné provést ve v´ıce kroc´ıch. Hlavn´ı ˇca´st komponenty bude um´ıstˇena na Controller node. Ceilometer nepodporuje v souˇcasné dobˇe relaˇcn´ı databáz´ı MySQL a proto je nutné nainstalovat MongoDB6 , coˇz je jediná podporovaná databáze. Standardn´ı repozitáˇre Debianu obsahuj´ı velmi zastaralou verzi a proto je nutné pˇred instalac´ı do systému pˇridat oficiáln´ı repozitáˇr MongoDB: # apt-key adv --keyserver keyserver.ubuntu.com --recv 7F0CEB10 6

http://www.mongodb.org/

68


Ceilometer

# echo ’deb http://downloads-distro.mongodb.org/repo/debian-sysvinit \ dist 10gen’ | sudo tee /etc/apt/sources.list.d/mongodb.list # apt-get update # apt-get install mongodb-org V konfiguraˇcn´ım souboru /etc/mongod.conf uprav´ıme tyto hodnoty, zbytek necháme v´ ychoz´ı: bind_ip = 127.0.0.1 smallfiles = true Server spust´ıme pˇr´ıkazem /etc/init.d/mongod start, pˇripoj´ıme se k nˇemu a zaloˇz´ıme uˇzivatele: # mongo > use ceilometer > db.addUser( { user: "ceilometer", pwd: "CEILOMETER_DB_HESLO", roles: [ "readWrite", "dbAdmin" ] } ) Dále jiˇz m˚ uˇzeme nainstalovat samotn´ y Ceilometer: # apt-get install ceilometer-api ceilometer-collector \ ceilometer-agent-central python-ceilometerclient Jeho konfigurace jiˇz nen´ı automatická jako u ostatn´ıch komponent. Budeme potˇrebovat vygenerovat TAJN´ Y_KL´ Iˇ C, kter´ y slouˇz´ı pro podepisován´ı komunikace mezi uzly Ceilometeru a také vytvoˇrit nov´ y servisn´ı u ´ˇcet v Keystone (uˇzivatel ceilometer, tenant service a náhodné heslo). Poté ruˇcnˇe uprav´ıme soubor /etc/ceilometer/ceilometer.conf: [database] connection = mongodb://ceilometer:CEILOMETER_DB_HESLO@ \ 127.0.0.1:27017/ceilometer 69


Ceilometer

[publisher_rpc] metering_secret = TAJN´ Y_KL´ Iˇ C [keystone_authtoken] auth_host = controller auth_port = 35357 auth_protocol = http auth_uri = http://controller:5000 admin_tenant_name = service admin_user = ceilometer admin_password = CEILOMETER_SERVICE_HESLO [service_credentials] os_username = ceilometer os_tenant_name = service os_password = CEILOMETER_SERVICE_HESLO Pro aplikaci nového nastaven´ı sluˇzby restartujeme: # service ceilometer-agent-central restart # service ceilometer-api restart # service ceilometer-collector restart

5.8.1

´ Upravy v komponentˇ e Cinder

Do souboru /etc/cinder/cinder.conf pˇridáme následuj´ıc´ı ˇra´dky: [DEFAULT] ... control_exchange = cinder notification_driver = cinder.openstack.common.notifier.rpc_notifier Pro naˇcten´ı zmˇen je nutn´ y restart sluˇzeb: # service cinder-volume restart # service cinder-api restart 70


5.8.2

Ceilometer

´ Upravy v komponentˇ e Glance

Do souboru /etc/glance/glance-api.conf pˇridáme následuj´ıc´ı ˇrádky (za RABBIT_HESLO dosad´ıme heslo, které jsme nastavili v kap. 5.4): [DEFAULT] ... notifier_strategy = rabbit rabbit_host = controller rabbit_password = RABBIT_HESLO Pro naˇcten´ı zmˇen je nutn´ y restart sluˇzeb: # service glance-registry restart # service glance-api restart

5.8.3

´ Upravy v komponentˇ e Nova

Pro mˇeˇren´ı zdroj˚ u na v´ ypoˇcetn´ım uzlu mus´ıme nejprve nainstalovat sluˇzbu, která ho zprostˇredkuje: # apt-get install ceilometer-agent-compute Soubor /etc/nova/nova.conf uprav´ıme následovnˇe: [DEFAULT] ... instance_usage_audit = True instance_usage_audit_period = hour notify_on_state_change = vm_and_task_state notification_driver = nova.openstack.common.notifier.rpc_notifier notification_driver = ceilometer.compute.nova_notifier Uprav´ıme také soubor /etc/ceilometer/ceilometer.conf: 71

ˇ Integrace do prostˇred´ı ZCU

Realizace pilotn´ıho nasazen´ı [publisher_rpc] metering_secret = TAJN´ Y_KL´ Iˇ C

[keystone_authtoken] auth_host = controller auth_port = 35357 auth_protocol = http auth_uri = http://controller:5000 admin_tenant_name = service admin_user = ceilometer admin_password = CEILOMETER_SERVICE_HESLO [service_credentials] os_username = ceilometer os_tenant_name = service os_password = CEILOMETER_SERVICE_HESLO Pro naˇcten´ı zmˇen sluˇzbu restartujeme: # service ceilometer-agent-compute restart V´ ysledkem je funkˇcn´ı komponenta, která sb´ırá data o vyuˇzit´ı uveden´ ych sluˇzeb. Pˇr´ıkladem je obr. 5.5, kter´ y zachycuje zobrazen´ı v´ ystup˚ u v portálu Horizon.

5.9

ˇ Integrace do prostˇ red´ı ZCU

ˇ bylo nutné se vypoˇra´dat pˇrePˇri zapojen´ı do existuj´ıc´ı infrastruktury ZCU devˇs´ım se správou uˇzivatelsk´ ych u ´ˇct˚ u a pˇrihlaˇsován´ım ke sluˇzbˇe. Jak uvád´ı [21], doba, kdy kaˇzdá aplikace pˇrináˇs´ı sv˚ uj vlastn´ı zp˚ usob ovˇeˇrován´ı, se jiˇz pomalu stává minulost´ı. Bylo tedy nutné provést u ´pravy vedouc´ı k zapojen´ı systému do Single-Sign-On architektury, aby bylo zajiˇstˇeno pohodlné vyuˇz´ıván´ı uˇzivateli bez nutnosti pamatovat si dalˇs´ı hesla.

72



Obrázek 5.5: V´ ystup mˇeˇren´ı zátˇeˇze CPU v portálu Horizon Zdroj: vlastn´ı zpracov´ an´ı

5.9.1

Digit´ aln´ı certifik´ at

Aby bylo moˇzné k webovému portálu a ostatn´ım sluˇzbám pˇristupovat zabezpeˇcenˇe, je pouˇzit protokol TLS7 , coˇz je kryptografick´ y protokol zajiˇst’uj´ıc´ı ˇsifrovanou komunikaci po poˇc´ıtaˇcové s´ıti. Tento protokol umoˇzn ˇuje aplikac´ım typu klient/server komunikovat takov´ ym zp˚ usobem, kter´ y zabraˇ nuje odposlechu nebo padˇelán´ı zpráv. [13] Protokol vyuˇz´ıvá asymetrickou kryptografii, pˇriˇcemˇz ale nen´ı zaruˇcena identita druhé strany. Z tohoto d˚ uvodu existuje infrastruktura veˇrejného kl´ıˇce (Public Key Infrastructure, PKI), která pro zajiˇstˇen´ı d˚ uvˇeryhodnosti vyuˇz´ıvá certifikaˇcn´ı autority (CA). PKI je struktura, která se skládá z hardwaru, softwaru, osob, politik a procedur potˇrebn´ ych pro vytváˇren´ı, správu, ukládán´ı, distribuci a zneplatˇ nován´ı digitáln´ıch certifikát˚ u. [55] Pro vydán´ı vlastn´ıho digitáln´ıho certifikátu je nutné vygenerovat privátn´ı 7

Transport Layer Security

73



kl´ıˇc (z˚ ustává utajen) a ˇza´dost (Certificate signing request, CSR). Tuto ˇza´dost poté pˇredáme námi zvolené CA, která po ovˇeˇren´ı identity subjektu, pro kter´ y má b´ yt certifikát vystaven, vydá digitáln´ı certifikát. Certifikaˇcn´ıch autorit je celá ˇrada, pˇriˇcemˇz pro bezproblémov´ y zabezpeˇcen´ y pˇr´ıstup z klientsk´ ych poˇc´ıtaˇc´ıch je nutné, aby byl koˇrenov´ y certifikát zvolené CA um´ıstˇen mezi d˚ uvˇeryhodn´ ymi na daném poˇc´ıtaˇci. Pro projektované akademické vyuˇzit´ı bylo moˇzné vyuˇz´ıt serverové certifikáty TERENA Certificate Service (TCS), které jsou vydávány pod hlaviˇckou d˚ uvˇeryhodné CA COMODO pro akademické insitituce zapojené do s´ıtˇe CESNET2. 8 V rámci této práce byl vydán certifikát pro https://cloud.civ.zcu.cz.

5.9.2

Kerberos a WebAuth

ˇ je Jelikoˇz je pˇr´ıstup k aplikaci podm´ınˇen existenc´ı Orion konta v rámci ZCU, pro ovˇeˇren´ı identity uˇzivatele vyuˇzit systém WebAuth zaloˇzen´ y na autentizaˇcn´ım systému Kerberos. Tento pˇr´ıstup eliminuje nutnost zakládat samostatné u ´ˇcty pouze pro u ´ˇcel OpenStacku s vlastn´ım heslem a tak jde návrh v duchu Single-Sign-On (SSO), kde si uˇzivatel vystaˇc´ı s pˇrihláˇsen´ım k v´ıce sluˇzbám na jednom m´ıstˇe. Princip fungován´ı zachycuje obr. 5.6. Technicky je fungován´ı zajiˇstˇeno pˇres modul mod webauth do webového serveru Apache, kter´ y je vyv´ıjen na Stanfordovˇe univerzitˇe9 . Pro Debian existuje pˇripraven´ y bal´ıˇcek, instalace je tedy triviáln´ı a nainstaluj´ı se i vˇsechny potˇrebné závislosti (zejména knihovny pro Kerberos): apt-get install libapache2-webauth Modul (/etc/apache2/mods-available/webauth.conf) je nakonfigurován následuj´ıc´ım zp˚ usobem: WebAuthLoginURL "https://webkdc.zcu.cz/login.fcgi" 8

http://support.zcu.cz/index.php/Z\%C3\%ADsk\%C3\%A1n\%C3\%AD_serverov\ %C3\%A9ho_certifik\%C3\%A1tu_TCS_COMODO_pro_webov\%C3\%BD_server 9 http://webauth.stanford.edu/

74



Obrázek 5.6: Prvotn´ı pˇrihláˇsen´ı uˇzivatele Zdroj: [21]

WebAuthWebKdcURL "https://webkdc.zcu.cz/webkdc-service/" WebAuthWebKdcPrincipal webkdc/webkdc WebAuthKeyring /etc/webauth/keyring WebAuthKeyringAutoUpdate on WebAuthKeyringKeyLifetime 30d WebAuthKeytab /etc/webauth/keytab WebAuthServiceTokenCache /etc/webauth/service_token.cache V souboru /etc/webauth/keyring se nacház´ı kl´ıˇc Kerberos principalu aplikaˇcn´ıho serveru. Dále je nutné vyˇza´dat autentizaci pro portál, coˇz provedeme pˇridán´ım tˇechto ˇra´dk˚ u do souboru openstack-dashboard-ssl.conf, kter´ y najdeme v 75


Realizace pilotn´ıho nasazen´ı adresáˇri /etc/apache2/sites-available/: AuthType WebAuth Require valid-user

T´ımto je povolen pˇr´ıstup vˇsem autentizovan´ ym drˇzitel˚ um Orion konta.

5.9.3

Uˇ zivatelsk´ eu ´ˇ cty

Základn´ı identitou sytému oprávnˇen´ı v OpenStacku je uˇzivatel (user), kter´ y má pˇridˇelené heslo. Uˇzivatel m˚ uˇze patˇrit do jednoho nebo v´ıce projekt˚ u (tenants) v definované roli (uˇzivatel, administrátor, . . . ).

Kv´ oty Pro kaˇzd´ y projekt se definuj´ı kvóty, zejména pro: • Velikost diskov´ ych jednotek v GB. • Poˇcet vytvoˇren´ ych diskov´ ych jednotek. • Poˇcet spuˇstˇen´ ych instanc´ı server˚ u. • Poˇcet alokovan´ ych jader procesoru. • Poˇcet alokovan´ ych IP adres. Na novˇe zaloˇzen´ y projekt se aplikuj´ı defaultn´ı kvóty, které m˚ uˇze upravit administrátor bud’ pˇres portál (Admin → Defaults → Update Defaults) nebo pˇres konzolov´ y pˇr´ıkaz: nova quota-class-update --instances 2 default

76



V´ yˇse uveden´ ym pˇr´ıkazem nastav´ıme defaultn´ı limit na 2 vytvoˇrené instance serveru. V´ ypis vˇsech kvót provedeme pˇr´ıkazem: nova quota-defaults Pˇridˇelené kvóty lze projekt˚ um kdykoliv upravit bud’ pˇres portál (Admin → Projects → More → Modify Quotas) nebo konzolov´ ym programem. Je moˇzné také sledovat vyuˇzit´ı kvót a z´ıskat základn´ı pˇredstavu o vyuˇz´ıván´ı zdroj˚ u konkrétn´ım projektem. V´ ypis bˇeˇz´ıc´ıch instanc´ı a souhrnné statistiky (poˇcet instanc´ı, celková velikost RAM a poˇcet alokovan´ ych procesorohodin“ ” za zvolen´ y ˇcasov´ yu ´sek) je dostupn´ y také pˇres web (Admin → Projects → More → View Usage), pˇr´ıklad v´ ypisu ilustruje obr. 5.7.

Obrázek 5.7: Zobrazen´ı vyuˇzit´ı zdroj˚ u projektem Zdroj: vlastn´ı zpracov´ an´ı

ˇ Uˇ zivatel´ e na ZCU Pro ˇr´ızen´ı uˇzivatelsk´ ych u ´ˇct˚ u máme k dispozici dvˇe moˇznosti. Prvn´ı moˇznost´ı je vytvoˇrit pro kaˇzdého uˇzivatele vlastn´ı projekt, kterému nastav´ıme limity. 77



Druh´ ym pˇr´ıstupem je uˇzivateli nezakládat automaticky vlastn´ı projekt, ale zaˇradit ho do existuj´ıc´ıch vˇetˇs´ıch celk˚ u. Typick´ ym scénáˇrem m˚ uˇze b´ yt situace, kdy budeme cht´ıt uˇzivatele sdruˇzovat do projekt˚ u podle fakulty a katedry. M˚ uˇzeme k tomu vyuˇz´ıt univerzitn´ı 10 LDAP databázi, která poskytuje základn´ı informace o studentovi: # ldapsearch -x -H ldap://ldap.zcu.cz uid=martv ...(vynechan´ e r ˇ´ adky)... memberof: cn=stud-kat-kiv,ou=Groups,ou=rfc2307,o=zcu,c=cz memberof: cn=students-fav,ou=Groups,ou=rfc2307,o=zcu,c=cz y O uˇzivateli martv jsme schopni zjistit, ˇze studuje na FAV11 a má zapsan´ 12 libovoln´ y pˇredmˇet z KIV . V´ıce informac´ı nám LDAP bohuˇzel neposkytne a pokud bychom chtˇeli sdruˇzovat uˇzivatele podle pˇresnˇejˇs´ıch kritéri´ı, napˇr´ıklad podle pˇredmˇet˚ u, které aktuálnˇe studuje, mus´ıme vyuˇz´ıt webovou sluˇzbu univerzitn´ıho systému IS/STAG13 . Pro zjiˇstˇen´ı aktuálnˇe zapsan´ ych pˇredmˇet˚ u uˇzivatele potˇrebujeme nejprve zjistit jeho osobn´ı ˇc´ıslo. To provedeme zavolán´ım webové sluˇzby a pˇredán´ım uˇzivatelského jména jako parametr: https://stag-ws.zcu.cz/ws/services/rest/orion/ getOsobniCislaByOrionLogin?login=martv Webová sluˇzba nám vrát´ı osobn´ı ˇc´ıslo (A11N0016K), se kter´ ym m˚ uˇzeme dále pracovat a vyˇza´dat si seznam pˇredmˇet˚ u, které má student v aktuáln´ım semestru zapsané: https://stag-ws.zcu.cz/ws/services/rest/predmety/ getPredmetyByStudent?osCislo=A11N0016K&semestr=ZS 10

Lightweight Directory Access Protocol Fakulta aplikovan´ ych vˇed 12 Katedra informatiky a v´ ypoˇcetn´ı techniky 13 Kompletn´ı dokumentace k dispozici na: https://stag-ws.zcu.cz/ws/help/ 11

78


Realizace pilotn´ıho nasazen´ı Realizace napojen´ı

Jak jiˇz bylo zm´ınˇeno, Keystone podporuje i extern´ı autentizaˇcn´ı sluˇzby a bylo ˇ vyuˇz´ıván. by moˇzné ho pˇr´ımo napojit na Kerberos, kter´ y je na ZCU Tento postup by vˇsak znamenal, ˇze by uˇzivatelé museli zadávat své pˇrihlaˇsovac´ı u ´daje pˇr´ımo do rozhran´ı OpenStacku, coˇz nen´ı povaˇzováno zadavatelem za ideáln´ı v tom smˇeru, ˇze si nepˇreje, aby se takto citlivé u ´daje zadávaly na pˇr´ımo do aplikac´ı tˇret´ıch stran. Bylo tedy nutné vyuˇz´ıt jiˇz zm´ınˇen´ y WebAuth. Na stranˇe Keystone ale vznikl problém, protoˇze jeho uˇzivatelská databáze nen´ı nijak napojena na univerzitn´ı seznam uˇzivatel˚ u. Takˇze i pˇres u ´spˇeˇsnou WebAuth autentizaci nebyl uˇzivatel pˇrihláˇsen, protoˇze v databázi Keystone neexistoval jeho u ´ˇcet. Tento problém je ˇreˇsiteln´ y nˇekolika zp˚ usoby. Jedn´ım z nich je periodická hromadná aktualizace databáze Keystone tak, aby obsahovala vˇsechny Orion ˇ Vzhledem k pˇredpokladu, ˇze OpenStack bude vyuˇz´ıvat pouze u ´ˇcty na ZCU. mal´ y zlomek drˇzitel˚ u Orion konta (kter´ ych je nyn´ı cca. 20 tis´ıc), nen´ı idea´ln´ı m´ıt v databázi vˇsechny oprávnˇené uˇzivatele kv˚ uli vyˇsˇs´ı pˇrehlednosti a jednoduchosti správy. Autor práce navrhl a realizoval vlastn´ı zp˚ usob spoˇc´ıvaj´ıc´ı ve vytvoˇren´ı skriptu, kter´ y po u ´spˇeˇsném pˇrihláˇsen´ı pˇres WebAuth pˇriprav´ı v Keystone uˇzivatelsk´ y u ´ˇcet a uˇzivatele automaticky pˇrihlás´ı na Horizon portál, kter´ y nativnˇe neum´ı pracovat s WebAuthem. V´ yhodou je, ˇze uˇzivatelská databáze Keystone bude obsahovat jen osoby, které se k OpenStacku alespoˇ n jednou pˇrihlásily a odpadá nutnost synchronizace databáz´ı uˇzivatel˚ u. Postup fungován´ı skriptu je následuj´ıc´ı: 1. Uˇzivatel OrionUser se u ´spˇeˇsnˇe pˇrihlás´ı pˇres WebAuth. 2. Skript ovˇeˇr´ı, jestli uˇzivatel jiˇz existuje v databázi Keystone a vygeneruje jednorázové heslo pro vstup (toto heslo je pouze intern´ı, uˇzivatel ho nikde nevid´ı ani ho nezná). (a) Uˇzivatel neexistuje: skript zaloˇz´ı nov´ y projekt OrionUser a uˇzivatele OrionUser s vygenerovan´ ym jednorázov´ ym heslem. (b) Uˇzivatel jiˇz existuje: skript nastav´ı existuj´ıc´ımu uˇzivateli vygenerované jednorázové heslo. 79



3. Skript si z LDAP zjist´ı, jak´ ych skupin je uˇzivatel OrionUser ˇclenem. Z databáze Keystone zjist´ı, jaké projekty (tenants) jsou v OpenStacku zaloˇzeny. Pokud je nalezena shoda (napˇr. uˇzivatel OrionUser je ˇclenem LDAP skupiny students-fav a v OpenStacku existuje tento projekt), je uˇzivateli pˇridána role v tomto projektu. 4. Uˇzivatel je automaticky pˇrihláˇsen a pˇresmˇerován na hlavn´ı stránku portálu. Uˇzivatel má tedy kromˇe primárn´ıho projektu automaticky ˇclenstv´ı ve vˇsech existuj´ıc´ıch projektech, které se jménem shoduj´ı se skupinami, jej´ıchˇz je v LDAP ˇclenem. Pro správné fungován´ı je nutné, aby byly projekty odpov´ıdaj´ıc´ı skupinám v LDAP nejprve ruˇcnˇe zaloˇzeny. Pokud budeme cht´ıt povolit zakládán´ı virtuáln´ıch stroj˚ u jen vybran´ ym uˇzivatel˚ um, lze to realizovat v´ıce zp˚ usoby. Jedn´ım z nich je nastavit nulové v´ ychoz´ı kvóty (dle kap. 5.9.3) a potˇrebné kvóty nastavit aˇz projekt˚ um, do kter´ ych budou uˇzivatelé automaticky pˇridáni na základˇe svého ˇclenstv´ı v LDAP. Druhou variantou je omezen´ı pˇr´ıstupu k portálu na u ´rovni WebAuth, které lze realizovat u ´pravou souboru openstack-dashboard-ssl.conf v adresáˇri /etc/apache2/sites-available/ (podrobnˇejˇs´ı popis v kap. 5.9.2): AuthType WebAuth #Require valid-user Require privgroup civ V´ yˇse uveden´ y pˇr´ıklad povol´ı pˇr´ıstup jen Orion uˇzivatel˚ um ve skupinˇe CIV. Vytvoˇren´ y skript je napsán v jazyce Python, takˇze pro bˇeh nevyˇzaduje ˇzádné dalˇs´ı softwarové vybaven´ı neˇz je nutné pro bˇeh OpenStacku (kter´ y je také naprogramován v Pythonu). Pro funkˇcnost nicménˇe vyˇzaduje dva drobné zásahy do rozhran´ı portálu Horizon, pro které je vytvoˇren patch um´ıstˇen´ y na CD v pˇr´ıloze této práce. Patche pouˇzijeme tak, ˇze je nahrajeme na ˇr´ıd´ıc´ı uzel do adresáˇre /tmp/horizon_patch a spust´ıme: # patch /usr/share/pyshared/horizon/templates/auth/_login.html < \ 80


Ovˇeˇren´ı

/tmp/horizon_patch/_login.html.patch # patch /usr/share/pyshared/openstack_auth/views.py < \ /root/horizon_patch/views.py.patch

5.10

Ovˇ eˇ ren´ı

C´ılem ovˇeˇren´ı je prokázat, ˇze realizovan´ y pilotn´ı provoz splˇ nuje definované poˇzadavky a pˇredstavuje základ, d´ıky kterému je moˇzné dále rozv´ıjet realizovan´ y projekt.

5.10.1

Sc´ en´ aˇ r: zaloˇ zen´ı a pˇ rihl´ aˇ sen´ı uˇ zivatele

Poˇ zadavky: uˇzivatel s platn´ ym univerzitn´ım Orion kontem, internetov´ y prohl´ıˇzeˇc. C´ıl: prokázat, ˇze je funkˇcn´ı autentizace pˇres WebAuth a skript zajiˇst’uj´ıc´ı propagaci uˇzivatelsk´ ych kont v Keystone pracuje správnˇe. 1. Uˇzivatel pˇristoup´ı na adresu Horizon portálu (https://cloud.civ. zcu.cz). 2. Modul mod webauth detekuje, ˇze uˇzivatel nen´ı pˇrihláˇsen a pˇresmˇeruje ho na stránku Orion WebAuth (obr. 5.8). 3. Uˇzivatel zadá sv˚ uj Orion login a heslo. 4. Po u ´spˇeˇsném ovˇeˇren´ı identity je uˇzivatel pˇresmˇerován zpˇet na Horizon. 5. Je spuˇstˇen námi vytvoˇren´ y skript, kter´ y zjist´ı Orion login pˇrihláˇseného uˇzivatele. 6. Skript se spoj´ı s Keystone a ovˇeˇr´ı, jestli jiˇz uˇzivatel v jeho databázi existuje. Pokud v databázi jeˇstˇe nen´ı, zaloˇz´ı se. Dále si z LDAP vyˇzádá seznam skupin, kter´ ych je uˇzivatel ˇclenem. Pokud taková skupina existuje jako projekt v OpenStacku, obdrˇz´ı k n´ı uˇzivatel pˇr´ıstupová práva. 7. Uˇzivatel je automaticky pˇrihláˇsen a zobraz´ı se mu hlavn´ı stránka portálu (obr. 5.9). Pokud je ˇclenem v´ıce projekt˚ u, m˚ uˇze mezi nimi pˇrep´ınat. 81


Ovˇeˇren´ı

Obrázek 5.8: Pˇrihláˇsen´ı pˇres WebAuth Zdroj: vlastn´ı zpracov´ an´ı

Po odhláˇsen´ı z portálu jsou korektnˇe vymazány cookies v prohl´ıˇzeˇci14 a uˇzivateli se zobraz´ı stránka WebAuth informuj´ıc´ı o u ´spˇeˇsném odhláˇsen´ı. Z´ avˇ er: bylo prokázáno, ˇze funguje uˇzivatelsk´ y pˇr´ıstup k portálu a do databáze se korektnˇe propaguj´ı informace o ˇclenstv´ı ve skupinách.

5.10.2

Sc´ en´ aˇ r: zaloˇ zen´ı a spuˇ stˇ en´ı serveru

Poˇ zadavky: autentizovan´ y uˇzivatel OpenStacku, internetov´ y prohl´ıˇzeˇc, zaloˇzená s´ıt’ v databázi OpenStacku. C´ıl: prokázat, ˇze je moˇzné zaloˇzit a spustit virtuáln´ı server v cloudu. 1. Uˇzivatel se pˇrihlás´ı dle kap. 5.10.1. V menu se pˇrepne na projekt, ve kte14

malé mnoˇzstv´ı dat, kter´ a WWW server poˇsle prohl´ıˇzeˇci, kter´ y je uloˇz´ı na poˇc´ıtaˇci uˇzivatele

82


Ovˇeˇren´ı

Obrázek 5.9: Hlavn´ı strana portálu Horizon, uˇzivatel se m˚ uˇze pˇrep´ınat mezi projekty Zdroj: vlastn´ı zpracov´ an´ı

rém chce pracovat (pokud je ˇclenem pouze jednoho projektu, pˇrepnut´ı nen´ı moˇzné). 2. V levém menu zvol´ı poloˇzku INSTANCES a poté stiskne tlaˇc´ıtko LAUNCH INSTANCE. 3. V zobrazeném oknˇe (obr. 5.10) vypln´ı detaily novˇe zˇrizovaného serveru. Je nutné zvolit název, vybrat jednu z pˇripraven´ ych ˇsablon parametr˚ u (urˇcuje poˇcet CPU, velikost RAM a disku) a dále vybrat obraz, ze kterého bude server vytvoˇren. Je také moˇzné volit mezi lokáln´ım u ´loˇziˇstˇem (pˇr´ımo na hostitelském serveru, nedoporuˇceno) a centráln´ım s´ıt’ov´ ym u ´loˇziˇstˇem (Cinder, doporuˇceno). 4. Uˇzivatel vol´ı vytvoˇren´ı nové diskové jednotky na s´ıt’ovém u ´loˇziˇsti z existuj´ıc´ı ˇsablony (Ubuntu 12.04 LTS). 5. Po stisku tlaˇc´ıtka LAUNCH se spust´ı proces popsan´ y v kap. 4.8 a pokud jsou splnˇeny vˇsechny podm´ınky (uˇzivatel vyplnil vˇsechna povinná pole, 83


Ovˇeˇren´ı

nenarazil na horn´ı hranici nˇekteré kvóty, . . . ), v´ ysledkem je start nového serveru v cloudu. Z´ avˇ er: bylo prokázáno, ˇze uˇzivatel m˚ uˇze samostatnˇe vytvoˇrit a spustit virtuáln´ı server. Testem bylo zároveˇ n ovˇeˇreno, ˇze funguje centráln´ı s´ıt’ové u ´loˇziˇstˇe pˇres iSCSI a virtuáln´ı server je z nˇej schopen nastartovat.

5.10.3

Sc´ en´ aˇ r: ovˇ eˇ ren´ı funkˇ cnosti kv´ ot

Poˇ zadavky: autentizovan´ y uˇzivatel OpenStacku, internetov´ y prohl´ıˇzeˇc, zaloˇzená s´ıt’ v databázi OpenStacku. C´ıl: ovˇeˇrit, ˇze funguje systém kvót. V tomto scénáˇri bylo postupováno obdobnˇe jako v kap. 5.10.2. Uˇzivatel zakládal virtuáln´ı servery aˇz do okamˇziku, kdy narazil na definované limity zdroj˚ u. Pˇri pokusu pˇridˇelit serveru v´ıce pamˇeti RAM neˇz je dovoleno systém odm´ıtl virtuáln´ı server zaloˇzit, coˇz dokládá obr. 5.11. Pokud je vyˇcerpán limit na poˇcet instanc´ı, nen´ı uˇzivateli umoˇznˇeno v˚ ubec otevˇr´ıt dialogové okno pro zaloˇzen´ı serveru. Z´ avˇ er: testem bylo ovˇeˇreno, ˇze nastavené limity v praxi funguj´ı.

5.10.4

Sc´ en´ aˇ r: spuˇ stˇ en´ı v´ıce server˚ u najednou

Poˇ zadavky: autentizovan´ y uˇzivatel OpenStacku, internetov´ y prohl´ıˇzeˇc, zaloˇzená s´ıt’ v databázi OpenStacku. C´ıl: ovˇeˇrit, jak se bude chovat cloud v pˇr´ıpadˇe soubˇehu v´ıce nároˇcn´ ych poˇzadavk˚ u. V tomto scénáˇri bylo postupováno obdobnˇe jako v kap. 5.10.2, pouze s t´ım rozd´ılem, ˇze bylo vytvoˇreno najednou 20 virtuáln´ıch server˚ u. Z´ avˇ er: testem bylo ovˇeˇreno vytvoˇren´ı a spuˇstˇen´ı velkého poˇctu instanc´ı najednou. Test dopadl u ´spˇeˇsnˇe; nejvˇetˇs´ı zátˇeˇz byla pozorována na uzlu, kter´ y 84


Ovˇeˇren´ı

Obrázek 5.10: Volby pˇri zakládán´ı nového serveru Zdroj: vlastn´ı zpracov´ an´ı

mˇel na starost diskové u ´loˇziˇstˇe. Nejv´ıce v´ ykonu vyˇzadovaly operace spojené s pˇr´ıpravou a kontextualizac´ı obrazu serveru, vytvoˇren´ım diskové jednotky a nakop´ırován´ım obrazu do novˇe vytvoˇrené jednotky. Z v´ ysledk˚ u testu plyne doporuˇcen´ı, ˇze je tˇreba dostateˇcnˇe dimenzovat v´ ykon serveru s Glance a také samotného diskového u ´loˇziˇstˇe. 85


Ovˇeˇren´ı

Obrázek 5.11: Chybové hláˇsen´ı pˇri pˇrekroˇcen´ı kvót Zdroj: vlastn´ı zpracov´ an´ı

5.10.5

Naplnˇ en´ı poˇ zadavk˚ u

V rámci této kapitoly je proveden rozbor poˇzadavk˚ u ze zadán´ı a komentováno jejich splnˇen´ı. • Poˇ zadavek: Uzly budou plnˇe ve správˇe uˇzivatele a typicky nastartované z pˇripraveného obrazu. Koment´ aˇ r: Splnˇeno a prokázáno v kap. 5.10.2. ˇ sen´ı mus´ı splˇ • Poˇ zadavek: Reˇ novat provozn´ı poˇzadavky v´ ypoˇcetn´ıho prostˇred´ı Orion (monitoring, bezpeˇcnost, zálohován´ı, . . . ). Koment´ aˇ r: Splnˇeno, provozn´ı ˇca´st´ı se zab´ yvaj´ı kapitoly 4.12 aˇz 4.15. • Poˇ zadavek: Je tˇreba napojen´ı na bázi uˇzivatel˚ u a pˇr´ıstup vˇsech uˇzivatel˚ u k nové sluˇzbˇe. Koment´ aˇ r: Splnˇeno, napojen´ım na bázi uˇzivatel˚ u se zab´ yvaj´ı kapitoly 5.9.3 a 5.9.3, prakticky je to ovˇeˇreno scénáˇrem v kap. 5.10.1. • Poˇ zadavek: Realizované ˇreˇsen´ı mus´ı umoˇzn ˇovat stanoven´ı limit˚ u na vyuˇzit´ı zdroj˚ u a mˇeˇren´ı vyuˇz´ıván´ı tˇechto zdroj˚ u.

86


Ovˇeˇren´ı

Koment´ aˇ r: Splnˇeno, pro kaˇzd´ y projekt jsou definovány v´ ychoz´ı kvóty (viz kap. 5.9.3), které je moˇzné individuálnˇe upravit. Dále je nainstalována telemetrická komponenta Ceilometer (viz kap. 5.8) umoˇzn ˇuj´ıc´ı mˇeˇren´ı, sbˇer, zpracován´ı a vyhodnocován´ı u ´daj˚ u o vyuˇzit´ı zdroj˚ u. • Poˇ zadavek: Souˇca´st´ı zadán´ı nen´ı pˇr´ıprava obraz˚ u virtuáln´ıch server˚ u, ale mus´ı pro to b´ yt odpov´ıdaj´ıc´ı podpora (import z jin´ ych prostˇred´ı, podpora kontextualizace, podpora r˚ uzn´ ych OS). Koment´ aˇ r: Splnˇeno, moˇznostmi obraz˚ u se zab´ yvá kap. 5.4.1. • Poˇ zadavek: Preferujeme otevˇrené ˇreˇsen´ı bez licenˇcn´ıch omezen´ı a poplatk˚ u, modulárn´ı a zaloˇzené na standardech. D˚ uleˇzit´ ym parametrem je malá provozn´ı nároˇcnost a moˇznost rozˇsiˇrován´ı (kapacita, vlastnosti). Koment´ aˇ r: Splnˇeno, navrˇzené ˇreˇsen´ı je svobodnˇe dostupné pod licenc´ı Apache 2.0. Disponuje znaˇcnou modularitou a je moˇzno ho bez problém˚ u rozˇsiˇrovat jak z hlediska kapacity, tak z hlediska v´ ykonu.

87

6 Závˇer C´ılem této práce bylo kromˇe seznámen´ı s v´ yvojem a pˇrehledem technologi´ı v oblasti virtualizace a cloud computingu také pˇripravit návrh infrastruktury privátn´ıho cloudu pro potˇreby Západoˇceské univerzity v Plzni a formou pilotn´ıho provozu ovˇeˇrit jeho realizovatelnost. Jednotlivé body ze zadán´ı byly splnˇeny, konkrétnˇe byl ve spolupráci se zadavatelem vytvoˇren soupis poˇzadavk˚ u, které mus´ı navrˇzené ˇreˇsen´ı splˇ novat. Byla poˇzadována sluˇzba umoˇzn ˇuj´ıc´ı samoobsluˇzné zˇrizován´ı virtuáln´ıch server˚ u pro potˇreby v´ yuky a v´ yzkumu, která nebude m´ıt licenˇcn´ı omezen´ı, bude vyuˇz´ıvat souˇcasné technologie a bude zapojena do prostˇred´ı Orion. V teoretické ˇca´sti práce je kromˇe historického v´ yvoje a pˇrehledu dneˇsn´ıch technologick´ ych trend˚ u a moˇznost´ı v oblastech virtualizace a cloud computingu také pˇrehled konkrétn´ıch softwarov´ ych platforem, které lze vyuˇz´ıt pro realizaci infrastruktury privátn´ıho cloudu. Na základˇe zadan´ ych kritéri´ı jsou tyto platformy porovnány a je zvoleno vhodné ˇreˇsen´ı pro virtualizaci a také pro správu privátn´ıho cloudu. V´ ystupem praktické ˇca´sti je popis a implementaˇcn´ı návrh privátn´ıho cloudu na platformˇe OpenStack. Tento návrh je posléze realizován ve formˇe pilotn´ıho provozu, kter´ y prob´ıhal od listopadu 2013 a bˇehem kterého bylo praktick´ ymi scénáˇri ovˇeˇreno, ˇze je navrˇzené ˇreˇsen´ı provozuschopné. Je vˇenována pozornost aspekt˚ um bˇeˇzného provozn´ıho nasazen´ı, kdy jsou nast´ınˇeny otázky bezpeˇcnosti, zálohován´ı, monitorován´ı, logován´ı a zajiˇstˇen´ı vysoké dostupnosti. Pro splnˇen´ı definovan´ ych poˇzadavk˚ u byly provedeny také u ´pravy zdrojov´ ych kód˚ u na m´ıru, které stejnˇe jako vˇsechny konfiguraˇcn´ı soubory tvoˇr´ı pˇr´ılohu této práce ve formˇe CD. Pˇri realizaci pilotn´ıho provozu se vyskytla celá ˇrada problém˚ u, které souvisely pˇredevˇs´ım se sloˇzitost´ı OpenStacku. Ten je tvoˇren skupinou vzájemnˇe kooperuj´ıc´ıch samostatn´ ych celk˚ u, které jsou mezi sebou propojené pomoc´ı API a serveru pro frontu zpráv. Orientaci neulehˇcila ani dokumentace, která byla ˇcasto roztˇr´ıˇstˇená a d´ıky rychlému v´ yvojovému cyklu plná zastaral´ ych informac´ı. Typicky je OpenStack nasazován v podobˇe komplexn´ıch komerˇcn´ıch distribuc´ı nebo s podporou velk´ ych firem, které si vytváˇr´ı vlastn´ı nástroje pro nasazen´ı a správu. Bylo tedy velkou v´ yzvou se o totéˇz pokusit vlastn´ımi silami v rámci této diplomové práce. 88

Seznam tabulek

3.1

Shrnut´ı rozd´ıl˚ u mezi public a private cloudem . . . . . . . . . 17

5.1

Parametry hardware pro pilotn´ı nasazen´ı . . . . . . . . . . . . 59

89

Seznam obr´ azk˚ u

2.1

Znázornˇen´ı virtualizace hardware . . . . . . . . . . . . . . . .

3

2.2

Ilustrace hypervizor˚ u typu 1 a 2 . . . . . . . . . . . . . . . . .

4

2.3

Práce s pamˇet´ı u VMware ESX . . . . . . . . . . . . . . . . .

9

2.4

Srovnán´ı 3letého TCO u zvolen´ ych virtualizaˇcn´ıch technologi´ı

11

3.1

Rozdˇelen´ı cloud˚ u podle modelu nasazen´ı . . . . . . . . . . . . 15

3.2

Rozdˇelen´ı cloud˚ u podle modelu nasazen´ı . . . . . . . . . . . . 18

3.3

Vrstvy cloud computingu . . . . . . . . . . . . . . . . . . . . . 19

3.4

Architektura Eucalyptu

3.5

Architektura OpenNebuly . . . . . . . . . . . . . . . . . . . . 25

3.6

Poˇcet commit˚ u za mˇes´ıc . . . . . . . . . . . . . . . . . . . . . 28

4.1

Konceptuáln´ı pohled na architekturu . . . . . . . . . . . . . . 30

4.2

Schéma s´ıtˇe s Neutronem . . . . . . . . . . . . . . . . . . . . . 34

4.3

Detail implementace Open vSwitche s GRE . . . . . . . . . . 35

4.4

Storage node s extern´ım uloˇziˇstˇem . . . . . . . . . . . . . . . . 38

4.5

Proces pˇrenosu a pouˇzit´ı obrazu . . . . . . . . . . . . . . . . . 40

. . . . . . . . . . . . . . . . . . . . . 24

90

´ ˚ SEZNAM OBRAZK U

´ ˚ SEZNAM OBRAZK U

4.6

Tok poˇzadavk˚ u . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.7

Architektura Ceilometeru

4.8

Realizace HA pro MySQL pˇres DRBD a Pacemaker . . . . . . 47

4.9

Realizace HA pro MySQL pˇres Galera a HAproxy. . . . . . . . 49

. . . . . . . . . . . . . . . . . . . . 44

4.10 Návrh HA architektury OpenStacku . . . . . . . . . . . . . . . 50 5.1

Rozloˇzen´ı sluˇzeb v realizované architektuˇre . . . . . . . . . . . 61

5.2

Prostˇred´ı debconf pro konfiguraci . . . . . . . . . . . . . . . . 63

5.3

Storage server s intern´ım uloˇziˇstˇem . . . . . . . . . . . . . . . 66

5.4

Schéma s´ıtˇe a zakreslen´ı toku dat z virtuáln´ıho serveru . . . . 67

5.5

V´ ystup mˇeˇren´ı zátˇeˇze CPU v portálu Horizon . . . . . . . . . 73

5.6

Prvotn´ı pˇrihláˇsen´ı uˇzivatele . . . . . . . . . . . . . . . . . . . 75

5.7

Zobrazen´ı vyuˇzit´ı zdroj˚ u projektem . . . . . . . . . . . . . . . 77

5.8

Pˇrihláˇsen´ı pˇres WebAuth . . . . . . . . . . . . . . . . . . . . . 82

5.9

Hlavn´ı strana portálu Horizon, uˇzivatel se m˚ uˇze pˇrep´ınat mezi projekty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.10 Volby pˇri zakládán´ı nového serveru . . . . . . . . . . . . . . . 85 5.11 Chybové hláˇsen´ı pˇri pˇrekroˇcen´ı kvót . . . . . . . . . . . . . . . 86

91

Literatura [1] Amazon: Web Services - About AWS. [cit. 2014-02-10]. URL http://aws.amazon.com/about-aws/ [2] Armbrust, M.: Above the Clouds: A Berkeley View of Cloud Computing. 02 2009 [cit. 2014-03-03]. URL http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/ EECS-2009-28.pdf [3] Bowen, B.; Gessau, H.; LeBlanc, D.; aj.: What’s new in Neutron for OpenStack Havana. 10 2013 [cit. 2014-01-29]. URL http://www.slideshare.net/kamesh001/ whats-new-in-neutron-for-open-stack-havana [4] Brady, P.: The life of an OpenStack libvirt image. 02 2013 [cit. 2014-0318]. URL http://www.pixelbeat.org/docs/openstack_libvirt_ images/ [5] Brandon, J.: Harvard, MIT Broad Institute deploys OpenStack for private cloud. 04 2014 [cit. 2014-04-20]. URL http://www.businesscloudnews.com/2014/04/22/ harvard-mit-broad-institute-deploys-openstack-for-private-cloud/ [6] Butler, B.: Open source cloud battles: OpenStack leveling off as CloudStack interest gains. 01 2013 [cit. 2014-02-28]. URL http://www.networkworld.com/news/2013/ 010713-openstack-cloudstack-265556.html [7] Cannao, R.: Benchmarking NDB vs Galera. 10 2012 [cit. 2014-05-03]. URL http://www.palominodb.com/blog/2012/12/10/ benchmarking-ndb-vs-galera

92

LITERATURA

LITERATURA

[8] Chellappa, R. K.: Intermediaries in Cloud-Computing: A New Computing Paradigm. In INFORMS Annual Meeting, 1997. [9] Clark, C.; Fraser, K.; Hand, S.; aj.: Live Migration of Virtual Machines. In NSDI, USENIX, 2005. URL http://dblp.uni-trier.de/db/conf/nsdi/nsdi2005.html# ClarkFHHJLPW05 [10] CloudStack: History. 2013 [cit. 2014-04-25]. URL https://cloudstack.apache.org/history.html [11] Danjou, J.: Ceilometer, the OpenStack metering project. 07 2012 [cit. 2014-05-02]. URL https://julien.danjou.info/blog/2012/ openstack-metering-ceilometer [12] Dialogic: Introduction to Cloud Computing. 07 2010 [cit. 2014-01-19]. URL http://www.dialogic.com/~/media/products/docs/ whitepapers/12023-cloud-computing-wp.pdf [13] Dierks, T.; Rescorla, E.: RFC 5246: The Transport Layer Security (TLS) Protocol. 08 2008 [cit. 2014-04-12]. URL http://tools.ietf.org/html/rfc5246 [14] Eucalyptus: Cloud Computing Architecture. [cit. 2014-03-08]. URL https://www.eucalyptus.com/eucalyptus-cloud/iaas/ architecture [15] Eucalyptus: Datasheet. [cit. 2014-03-08]. URL https://www.eucalyptus.com/sites/all/files/ ds-eucalyptus-iaas.en.pdf [16] Feuerlicht, G.; Burkon, L.; Sebesta, M.: Cloud Computing Adoption: What are the Issues. Systémová integrace, roˇcn´ık 18, ˇc. 2, 2011: s. 187– 192. [17] Flexiant: Common considerations when selecting your hypervisor. 02 2014 [cit. 2014-03-01]. URL http://www.flexiant.com/2014/02/12/ hypervisor-comparison-kvm-xen-vmware-hyper-v/ [18] FSN: The economy is flat so why are financials Cloud vendors growing at more than 90 percent per annum. 03 2013 [cit. 2014-02-25]. URL http://www.fsn.co.uk 93

LITERATURA

LITERATURA

[19] Furht, B.; Escalante, A. (editoˇri): Handbook of Cloud Computing. Springer New York Dordrecht Heidelberg London, 2010, ISBN 978-1-44196523-3. [20] Garfinkel, S.: The Cloud Imperative. 10 2011 [cit. 2014-01-13]. URL http://www.technologyreview.com/news/425623/ the-cloud-imperative/ ˇ [21] Grolmus, P.; Svamberg, M.: Single Sign-On ˇreˇsen´ı pro webové aplikace. Vyˇslo ve sborn´ıku XXVII. konference EurOpen, 2005: s. 87–100. [22] Gupta, R.: Request Flow for Provisioning Instance in Openstack. 04 2013 [cit. 2014-04-12]. URL http://ilearnstack.com/2013/04/26/ request-flow-for-provisioning-instance-in-openstack/ comment-page-1/ [23] Haas, F.: OpenStack High Availability Guide. 04 2014 [cit. 2014-05-03]. URL http://docs.openstack.org/high-availability-guide/ content/index.html [24] Hefner, K.: Definition OpenNebula. 11 2013 [cit. 2014-01-25]. URL http://searchcloudstorage.techtarget.com/definition/ OpenNebula [25] Hof, R. D.: Jeff Bezos’ Risky Bet. 11 2006 [cit. 2014-02-12]. URL http://www.businessweek.com/stories/2006-11-12/ jeff-bezos-risky-bet [26] Hufferd, J. L.: ISCSI: The Universal Storage Connection. AddisonWesley Professional, 2003, ISBN 978-0201784190. [27] IBM: Taking the Sting Out of Virtualization Licensing Costs with KVM. 09 2012 [cit. 2014-03-25]. URL https://www.ibm.com/developerworks/community/ blogs/ibmvirtualization/entry/taking_the_sting_out_of_ virtualization_licensing_costs_with_kvm?lang=en [28] Jiang, Q.: CY13-Q4 Open Source IaaS Community Analysis. 01 2014 [cit. 2014-03-01]. URL http://www.qyjohn.net/?p=3432 [29] Klepáˇc, M.: Private IaaS cloud comparison. Diplomová práce, Czech Technical University in Prague. 94

LITERATURA

LITERATURA

[30] KVM: Main Page. [cit. 2014-02-25]. URL http://www.linux-kvm.org/page/Main_Page [31] Marko, K.: iSCSI vs. Fibre Channel: A Cost Comparison. [cit. 2014-0215]. URL http://www.processor.com/editorial/article.asp? article=articles/p3014/31p14/31p14.asp [32] Mell, P.; Grance, T.: The NIST Definition of Cloud Computing. 09 2011 [cit. 2014-01-25]. URL http://csrc.nist.gov/publications/nistpubs/800-145/ SP800-145.pdf [33] Meyer, D.: Here’s why CERN ditched OpenNebula for OpenStack. 05 2013 [cit. 2014-03-13]. URL https://gigaom.com/2013/05/31/ heres-why-cern-ditched-opennebula-for-openstack/ [34] Meyer, D.: OpenNebula 4.0 guns for the vCloud crowd. 05 2013 [cit. 2014-03-15]. URL https://gigaom.com/2013/05/08/ opennebula-4-0-guns-for-the-vcloud-crowd/ [35] MySQL: Overview of MySQL with DRBD/Pacemaker/Corosync/Oracle Linux. [cit. 2014-03-12]. URL https://dev.mysql.com/doc/refman/5.0/en/ha-drbd.html [36] OpenNebula: An Overview of OpenNebula. [cit. 2014-04-02]. URL http://docs.opennebula.org/4.6/design_and_ installation/building_your_cloud/intro.html [37] OpenStack: How to Perform an Upgrade from Grizzly to Havana. 12 2013 [cit. 2014-03-25]. URL http://docs.openstack.org/trunk/openstack-ops/content/ ops_upgrades_grizzly_havana-ubuntu.html [38] OpenStack: Hypervisor Support Matrix. [cit. 2014-01-25]. URL https://wiki.openstack.org/wiki/ HypervisorSupportMatrix [39] OpenStack: Documentation. [cit. 2014-03-20]. URL http://docs.openstack.org/

95

LITERATURA

LITERATURA

[40] Parkhill, D.: The Challenge of the Computer Utility. Addison-Wesley Educational Publishers Inc., 1966, ISBN 9782017700593. [41] Patka, L.: Virtualizaˇcn´ı technologie. Diplomová práce, Masarykova univerzita, 2009. [42] Popek, G. J.; Goldberg, R. P.: Formal Requirements for Virtualizable Third Generation Architectures. Communications of the ACM, 1974. URL http://www.logos.ic.i.u-tokyo.ac.jp/~tau/lecture/ operating_systems/gen/papers/p412-popek.pdf [43] QArea: Cloud Computing Outlook: IaaS, PaaS and SaaS. [cit. 2014-0301]. URL http://www.qarea.com/articles/ cloud-computing-outlook-iaas-paas-and-saas [44] Reese, G.: Cloud Application Architectures. O’Reilly Media, Inc., 2009, ISBN 9780596555481. [45] Renski, B.: VMware Vs. KVM: OpenStack Hypervisor Race Heats Up. 12 2013 [cit. 2014-02-27]. URL http://www.mirantis.com/blog/ vmware-vs-kvm-openstack-hypervisor-race-heats-2/ [46] Rhoton, J.: Cloud Computing Explained: Implementation Handbook for Enterprises. 2009, ISBN 978-0956355607. ˇ vede v zavádˇen´ı ICT ve stˇredn´ı a v´ [47] Ryba, A.: CR ychodn´ı Evropˇe. 03 2014 [cit. 2014-04-10]. URL http://www.ictmanazer.cz/2014/03/ cr-vede-v-zavadeni-ict-ve-stredni-a-vychodni-evrope/ [48] Sedlák, J.: Radiokomunikace stav´ı druh´ y cloud, pobˇeˇz´ı na otevˇreném OpenStacku. 03 2014 [cit. 2014-04-30]. URL http://connect.zive.cz/bleskovky/ radiokomunikace-stavi-druhy-cloud-pobezi-na-otevrenem-openstacku/ sc-321-a-172912 [49] Severalnines: Clustering MySQL Backend in OpenStack. 08 2013 [cit. 2014-05-01]. URL http://www.severalnines.com/blog/ clustering-mysql-backend-openstack

96

LITERATURA

LITERATURA

[50] Sim, P.: OpenStack Networking - with Open vSwitch VLAN, GRE. 12 2013 [cit. 2014-01-12]. URL http://www.slideshare.net/janghoonsim/ open-stack-networking-vlan-gre [51] Solinea: OpenStack Grizzly Architecture (revisited). 06 2013 [cit. 2014-03-29]. URL http://www.solinea.com/blog/openstack-grizzly-architecture-revisited [52] Traeger, A.: OpenStack Cinder Deep Dive. 2013 [cit. 2014-02-20]. URL https://wiki.openstack.org/w/images/3/3b/ Cinder-grizzly-deep-dive-pub.pdf ˇ e republice [online]. Disertaˇcn´ı [53] Veber, J.: Sluˇzby cloud computing v Cesk´ práce, Vysoká ˇskola ekonomická v Praze, 2009 [cit. 2014-04-10]. URL http://theses.cz/id/58ov2m/ R [54] VMware: Understanding Memory Resource Management in VMware ESXTM Server. 2009 [cit. 2014-04-05]. URL http://www.vmware.com/files/pdf/perf-vsphere-memory_ management.pdf

[55] William, S.; Stallings, W.: Cryptography And Network Security, 4/E. Pearson Education, 2006, ISBN 9788177587746. URL http://books.google.cz/books?id=qKcrce0x\_2YC

97

A Obsah CD config ... Obsahuje konfiguraˇ cn´ ı soubory OpenStacku z pilotn´ ıho nasazen´ ı. doc ... Obsahuje PDF verzi t´ eto diplomov´ e pr´ ace. script ... Obsahuje skript pro zakl´ ad´ an´ ı uˇ zivatel˚ u z WebAuth/Orion.

98

Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky. Návrh a integrace privátního cloudu

Recommend Documents