TECHNICKÁ UNIVERZITA V KOŠICIACH

FAKULTA ELEKTROTECHNIKY A INFORMATIKY

Dynamické prideľovanie zdrojov, ich automatizované

monitorovanie a optimalizácia procesov v Cloud

infraštruktúrach

DIPLOMOVÁ PRÁCA

2012 Michal DULOVIČ

TECHNICKÁ UNIVERZITA V KOŠICIACH

FAKULTA ELEKTROTECHNIKY A INFORMATIKY

Dynamické prideľovanie zdrojov, ich automatizované

monitorovanie a optimalizácia procesov v Cloud

infraštruktúrach

Diplomová Práca

Študijný program: Informatika

Študijný odbor: Informatika

Školiace pracovisko: Katedra Počítačov a Informatiky (KPI)

Školiteľ: Ing. Katarína Kleinová, PhD.

Konzultant: Ing. Katarína Kleinová, PhD.

2012 Michal DULOVIČ

Abstrakt v SJ

V tejto práci je bližšie rozanalyzovaná problematika Cloud Computingu

a niekoľko technológií s tým spojených. Diplomová práca približuje niektoré hlavné

technologické základy, ktoré sa používajú v Cloud Computingu, ako aj riešenia

niektorých problémov, ktoré sa môžu naskytnúť. Taktiež umožňuje si urobiť predstavu

o fungovaní niektorých súčastí Cloud Computingu a poukazuje na ich výhody či

nevýhody. Súčasťou práce je aj praktické riešenie a to webové rozhranie na objavenie

dostupných služieb v sieti a automatické nasadzovanie filtrov sieťovej prevádzky na

hraničné prvky.

Abstrakt v AJ

In this graduation thesis there is analysis of Cloud Computing as a concept and

some of it’s key technologies which are used in Cloud Computing. Also there are some

solutions for problems that may occur during usage of Cloud Computing. It also

contains enough information to provide a view on how Cloud computing and some of

it’s key components works. This thesis also provides some advantages and

disadvantages of Cloud Computing as a concept. In addition part of this thesis is a

practical solution, which is a web interface for discovering available network services in

a network segment and applying network traffic filters on border devices.

Zadanie práce

Čestné vyhlásenie

Vyhlasujem, že som celú diplomovú prácu vypracoval samostatne s použitím

uvedenej odbornej literatúry.

Košice, 27.apríl 2012

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

vlastnoručný podpis

Poďakovanie

Týmto by som rád poďakoval vedúcemu a konzultantovi práce a svojej rodine

a priateľom za príjemné prostredie na prácu.

Predhovor

Hlavný dôvodom výberu tejto práce bolo, že Cloud Computing je v čase písania

tejto práce v rozmachu a hovorí sa o ňom čoraz viac a viac. Je nielen dobrým riešením

na ušetrenie nákladov, ale aj ako platforma pre poskytovanie kvalitných a inovatívnych

riešení a služieb. Nasadzovanie cloud computingu ponúka nové možnosti, no zároveň

spôsobuje aj nové problémy, ktoré je nutné vyriešiť. V prvej časti sú rozanalyzované

niektoré vlastnosti Cloud Computingu, v druhej časti je praktická časť tejto diplomovej

práce a to webové rozhranie na objavenie dostupných služieb v sieti a automatické

nasadzovanie ACL na hraničné prvky. Výsledkom tohto systému je obmedzenie

dostupnosti služieb len na tie užívateľom povolené.

Obsah

Zoznam obrázkov ......................................................................................................... 10

Zoznam tabuliek ........................................................................................................... 11

Zoznam symbolov a skratiek ....................................................................................... 12

Slovník termínov ........................................................................................................... 13

Úvod ............................................................................................................................... 14

1 Cloud Computing a jeho charakteristika ............................................................. 16

1.1 Čo je to Cloud Computing a jeho stručná charakteristika................................... 16

1.2 Hlavné vlastnosti Cloud Computingu ................................................................. 16

1.3 História Cloud Computingu a jeho vývoj............................................................ 18

1.4 Ciele nasadzovania Cloud Computingu .............................................................. 18

1.5 Výhody a nevýhody Cloud Computingu............................................................. 18

2 Architektúra Cloud Computingu .......................................................................... 20

2.1 Jednotlivé typy Cloud Computingu podľa prístupu ............................................ 20

2.2 Služby poskytované Cloud Computingom.......................................................... 22

2.3 Komerční prevádzkovatelia Cloud Computingu a ich zameranie ....................... 23

2.4 Možnosti a techniky prístupu do cloudu ............................................................. 24

3 Čo je to High Availability ...................................................................................... 25

4 Mechanizmy dynamického prideľovania zdrojov a rozdeľovania záťaže ........ 27

4.1 Prideľovanie zdrojov na úrovni poskytnutej služby (Vmware vSphere) ............ 27

4.1.1 Detailná charakteristika Vmware v Sphere.................................................. 27

4.1.2 Služby infraštruktúry: Virtualizácia a agregácie hardvérových zdrojov ..... 29

4.1.3 Zabezpečenie: Služby zabezpečenia ............................................................ 31

4.1.4 Škálovateľnosť ............................................................................................. 32

4.2 Prideľovanie zdrojov na úrovni platformy .......................................................... 32

4.2.1 Cisco ACE Load Balancer ........................................................................... 33

4.2.2 HSRP............................................................................................................ 33

4.2.3 Heartbeat ...................................................................................................... 34

4.2.4 Network Load Balancing ............................................................................. 34

4.2.5 Server Load Balancing................................................................................. 34

4.2.6 Princíp fungovania Server Load Balancing (SLB) ...................................... 35

4.2.7 Algoritmus pre rozloženie záťaže v rámci SLB........................................... 36

4.2.8 Metóda odložených väzieb (práca s cookie) ................................................ 37

4.2.9 Mechanizmy kontroly dostupnosti reálnych serverov ................................. 38

4.2.10 Mechanizmy na zaradenie serveru do skupiny po výpadku ........................ 39

4.2.11 Možnosti redundancie v rámci SLB ............................................................ 39

4.2.12 SLB s cookie pre https ................................................................................. 40

4.2.13 Global Server Load Balancing..................................................................... 41

4.2.14 Geografická distribúcia v rámci GSLB........................................................ 41

4.2.15 Zálohovanie serverových fariem v rámci GSLB ......................................... 42

4.2.16 Princíp fungovania GSLB............................................................................ 42

5 Meranie efektivity cloud computingu.................................................................... 44

5.1 Aplikácie pre cloud a ich štruktúra...................................................................... 46

5.2 Meranie efektívnosti aplikácií v cloud computingu ............................................ 46

5.3 Nástroje pre meranie efektivity a výkonu Cloudu............................................... 48

6 Správa životného cyklu služby v Cloude............................................................... 52

6.1 Služby v cloude ................................................................................................... 52

6.1.1 Vytvorenie služby v cloude ......................................................................... 52

6.1.2 Testovanie služby v cloude.......................................................................... 52

6.1.3 Kompozícia služby v cloude........................................................................ 53

6.1.4 Konzumácia služby v cloude ....................................................................... 53

6.1.5 Údržba služby v cloude................................................................................ 53

6.2 Správa životného cyklu pomocou Vmware Lifecycle Manager ......................... 54

7 Analýza princípov Configuration-driven architektúry ....................................... 56

8 Zabezpečenie cloud služieb v cloud computingu.................................................. 57

8.1 Bezpečnostné slabiny cloud computingu ............................................................ 57

8.2 Dôležité kritéria bezpečnosti cloud computingu ................................................. 60

8.2.1 Dostupnosť ako kritérium bezpečnosti cloud computingu .......................... 60

8.2.2 Konfidentalita ako kritérium bezpečnosti cloud computingu...................... 60

8.2.3 Integrita ako kritérium bezpečnosti cloud computingu ............................... 61

8.3 Verejný cloud a jeho zabezpečenie ..................................................................... 61

8.4 Cisco ACL ako nástroj na aplikáciu bezpečnostných politík.............................. 63

8.5 Iné mechanizmy na zabezpečenie infraštruktúr okrem ACL .............................. 67

9 Webové rozhranie systému na dynamické prehľadávanie adresného

priestoru s identifikáciou služieb, ktoré sa v ňom nachádzajú a

dynamickú rekonfiguráciu hraničných prvkov.................................................... 70

10 Záver......................................................................................................................... 82

Zoznam použitej literatúry .......................................................................................... 83

Prílohy............................................................................................................................ 85

FEI KPI

10

Zoznam obrázkov

Obrázok 1 Architektúra cloud......................................................................................... 20

Obrázok 2 Typy cloud computingu ................................................................................ 21

Obrázok 3 Prístup ku Cloud službám ............................................................................. 24

Obrázok 4 Funkcia SLB prepínača................................................................................. 36

Obrázok 5 Redundantné riešenie postavené na použití dvoch SLB prepínačov ............ 40

Obrázok 6 Topológia zapojenia a priebeh spojenia SSL akcelerátora ........................... 41

Obrázok 7 Schéma testovacieho prostredia .................................................................... 71

Obrázok 8 Schéma toku dát v programe......................................................................... 74

Obrázok 9 Nastavenie manuálneho skenovania ............................................................. 75

Obrázok 10 Nastavenie automatického skenovania ....................................................... 76

Obrázok 11 Výstup po úspešnom skenovaní.................................................................. 77

Obrázok 12 Zobrazenie databázy ................................................................................... 78

Obrázok 13 Nastavenie ACL.......................................................................................... 79

Obrázok 14 Zobrazenie vygenerovaného Expect-Lite skriptu ....................................... 80

Obrázok 15 Zobrazenie výstupu Expect-Lite po dokončení .......................................... 81

FEI KPI

11

Zoznam tabuliek

Tabuľka 1 Príklad dostupností........................................................................................ 26

Tabuľka 2 Jednotlivé limity cloudu................................................................................ 45

FEI KPI

12

Zoznam symbolov a skratiek

CC Cloud Computing, viď slovník termínov

IT Informačné Technológie

IP Internet Protocol

HA High Availability, slovensky vysoká dostupnosť

HW Hardware, slovensky hardvér

SW Software, slovensky softvér

SLA Service Level Agreement, zmluva o minimálnej dosažiteľnosti služby

API Application Programming Interface, programové rozhranie, ktoré určuje

akým spôsobom sa majú volať určité funkcie

SSL Secure Sockets Layer Zabezpečovací protokol na šifrovanie a

autentizáciu

HTTP Hyper Text Transfer Protocol, protokol na prenášanie webových stránok

HTTP Hyper Text Transfer Protocol Secure, protokol na prenášanie webových

stránok so zabezpečením

FTP File Transfer Protocol, protokol na prenášanie súborov

DNS Domain Name System, služba na priradenie DNS mien ku IP adresám

VoIP Voice over IP, zbierka protokolov na prenášanie hlasových (aj video)

hovorov a ich dát cez IP sieť

SIP Session Initiation Protocol, protokol pre VoIP

RTSP Real Time Streaming Protocol, protokol pre VoIP

POP Post Office Protocol, protokol na získanie e-mailov zo servera

IMAP Internet Message Access Protocol, protokol na získanie e-mailov zo

servera

NAT Network Adress Translation, systém prekladu IP adries z verejných na

neverejné a opačne

DNAT Dynamic/Destination Network Adress Translation, viď NAT

TTL Time To Live, počet prechodov paketu cez smerovač, pred jeho

zahodením

TCP Transmission Control Protocol, jeden z protokolov sady IP

FEI KPI

13

Slovník termínov

Cloud Computing je schéma výpočtového systému zahŕňajúca všetky stupne od HW

až po aplikácie a koncového zákazníka.

High Availability je je systémový dizajn a naviazaná implementácia systému, ktorá

zabezpečuje dopredu dohodnutú úroveň dostupnosti a výkonu daného systému na dané

obdobie.

Router je zariadenie na smerovanie paketov v počítačovej sieti. Smerovač typicky spája

viacero sietí a smeruje tok paketov medzi nimi podľa smerovacej tabuľky. Slovenský

názov je smerovač.

Switch je zariadenie typicky na pripojenie jednotlivých zariadení do siete alebo na

spájanie viacerých segmentov siete. Typicky pracuje na 2. vrstve OSI modelu. Existujú

však aj prepínače pracujúce aj na 3. vrstve. Slovenský názov je prepínač.

Server je zariadenie, ktoré ponúka služby pre iné zariadenie, pre klientov.

Klient je zariadenie, ktoré používa služby ponúkané serverom.

Host je všeobecný názov pre aktívne zariadenie v sieti typicky počítač, tlačiareň, server

a podobne.

Downtime je čas počas, ktorého je služba nedostupná, typicky za určité obdobie.

Cookie je malé množstvo dát, ktoré si prehliadač ukladá a získava ich zo servera,

typicky v textovej podobe.

FEI KPI

14

Úvod

Daná tému na diplomovú prácu bola zvolené, pretože autora veľmi zaujala

a v dnešnej dobe je téma Cloud Computing veľmi populárna medzi IT odborníkmi. Za

celým pojmom Cloud Computing stoja už dlhšie známe technológie, ktoré boli len

spojené do vhodnej štruktúry. S niektorými z týchto technológii mal autor už skúsenosti

aj pred písaním tejto práce, takže bolo potrebné hlavne rozanalyzovať akým spôsobom

sú tieto technológie prepojené. Téma Cloud Computingu je aktuálna z dvoch hlavných

dôvodov. Vďaka tejto technológii je možné usporiť pomerne veľké náklady za

prevádzku a údržbu a naviac táto technológia ponúka šikovné skĺbenie technológií,

ktoré otvára nové možnosti. Typickým príkladom sú cloud aplikácie, či dokonca cloud

notebooky, ktoré nepotrebujú silný hardvér, nepotrebujú veľké lokálne úložisko dát,

stačí im internetové pripojenie. Všetky operácie sa vykonávajú v cloude a všetky dáta

sú tiež uložené v cloude.

Súčasťou tejto diplomovej práce okrem analýzy už dostupných problémov a tém,

je aj praktické riešenie problému. Konkrétne automatizovaný systém na dynamické

vyhľadávanie služieb v definovanom priestore a na vygenerovanie filtra sieťovej

prevádzky ACL a jeho aplikovania na hraničný prvok. Účelom takéhoto nástroja by

malo byť automatické vyhľadanie dostupných služieb a adresnom priestore, z ktorého si

užívateľ zvolí iba tie, ktoré potrebuje a ostatné sa pomocou ACL zakážu. Pri tvorení

tohto nástroja sa riešili problémy postupne a to teda ako prvé sa vyriešilo samotné

webové rozhranie pre NMAP, následne bolo vyriešené prevzatie výstupu NMAP-u do

programovo spracovateľnej formy, následne vyriešilo ako sa tieto hodnoty budú

transformovať a ukladať do databázy. Ďalším krokom bolo vytvorenie metodiky

tvorenia ACL, následne sa toto ACL zapracovalo do Expect-Lite skriptu a posledným

krokom bolo vyriešenie nasadzovania ACL pomocou programu Expect-Lite.

Aj keď tento nástroj je len malou časťou technológií, ktoré sa v Cloud Computingu

využívajú, je možné ho naďalej rozširovať pre prípadné ďalšie potreby. Jedným

z možností rozšírenia by bolo pridanie programu NetFlow, ktorý by dokázal sledovať

presný tok dát v sieti a na základe toho generovať aj ACL v smere od servera ku

klientom.

FEI KPI

15

Význam tejto práce je hlavne v ušetrení času administrátorom, ktorý pomocou

tohto nástroja môžu rýchlejšie nasadiť ACL na hraničné prvky v prípade potreby

obmedzenia služieb.

V 1. kapitole je všeobecná analýza Cloud Computingu ako skĺbenia jednotlivých

technológií, výhody, nevýhody, vlastnosti a ciele. Jedná sa o pohľad na Cloud

Computing ako celok.

V 2. kapitole je bližší pohľad na architektúru Cloud Computingu, jednotlivé typy

Cloud Computingu, služby poskytované Cloud Computingom.

V 3. kapitole je bližšie rozanalyzovaný pojem High Availability, teda vysoká

dostupnosť.

V 4. kapitole je priblížená problematika mechanizmov prideľovania zdrojov

a rozdeľovania záťaže. V tejto kapitole je priblížená konkrétna implemetnácia na

platforme VMware, virtualizácia a agregácia hardvérových zdrojov, zabezpečenie

služieb, škálovateľnosť. Ďalej je tu rozanalyzovaná aj problematika prideľovania

zdrojov na úrovni platformy s tým súvisiace technológie Cisco ACE Load Balancer,

HSRP, HeartBeat, Network Load Balancing, Server Load Balancing, mechanizmy

kontroly dostupnosti serverov, redundancia a zotavenie v prípade výpadku

a v neposlednom rade aj Global Server Load Balancing.

V 5. kapitole sú uvedené techniky merania efektivity Cloud Computingu.

V 6. kapitole je analýza životného cyklu služby v Cloud Computingu a jej správa.

Je tu popísané jej vytvorenie, testovanie, kompozícia, konzumácia a údržba.

V 7. kapitole je stručne priblížená architektúra založená na konfiguračných

súboroch (Configuration-driven architecture).

V 8. kapitole sú priblížené niektoré techniky zabezpečenia služieb v Cloud

Computingu.

V 9. kapitole je priblížené samotné praktické riešenie, ktoré je súčasťou tejto

diplomovej práce a to webové rozhranie systému na dynamické prehľadávanie

adresného priestoru s identifikáciou služieb, ktoré sa v ňom nachádzajú a dynamickú

rekonfiguráciu hraničných prvkov a aplikáciu ACL na nich.

FEI KPI

16

1 Cloud Computing a jeho charakteristika

1.1 Čo je to Cloud Computing a jeho stručná charakteristika

Cloud Computing (ďalej aj ako CC) je schéma výpočtového systému zahŕňajúca

všetky stupne od HW až po koncového zákazníka. Tento systém je nastavený tak aby

bolo čo najviac výpočtových a úložných prostriedkov centralizovaných v jednom

mieste, zväčša na serverovej farme, no samotný používatelia tohto systému sú na

vzdialenom mieste a pristupujú k danému systému iba diaľkovo. Tento prístup sa líši aj

tým, že je možné si určiť stupeň do akého je za chod systému zodpovedný používateľ

a do akého stupňa je zodpovedný prevádzkovateľ. V praxi to znamená, že zákazník si

vyberie akú kontrolu nad systémom požaduje jeho projekt a vyberie si iba tie časti

systému, ktoré potrebuje mať pod priamou kontrolou a o ostatné časti systému sa už

stará prevádzkovateľ. Týmto sa líši od klasického InHouse prístupu, kde si firma

postaví svoje vlastné serverové centrum niekde na svojom pozemku a chod tohto

zariadenia je už plne závislý na nej a to už odhliadnuc či sa o jeho chod stará samotná

firma alebo externá firma. Medzistupňom medzi Cloud Computingom a klasickým

InHouse (On Premises) serverovým centrom je virtualizácia serverov. V takomto

prípade prevádzkovateľ poskytuje HW na ktorom sú emulované virtuálne servery, za

tieto servery je plne zodpovedný používateľ a to v každom ohľade, či už je to operačný

systém, aplikácie, prerozdelenie záťaže, záplatovanie systému a podobne. Podstatou je,

že pri Cloud Computingu používate a platíte iba za to čo potrebujete a spotrebujete resp.

k takémuto bodu sa celá idea Cloud Computingu blíži. Vo svete sú aj názory, že celý

Cloud Computing je vlastne len viacero už existujúciach a fungujúcich služieb, a preto

vlastne celý tento systém je len akousi marketingovou bublinou s pekným názvom.

Faktom ostáva, že systém Cloud Computing má nesporné výhody, no aj nevýhody

a samotné rozhodnutie či ho využiť alebo nie je už na používateľovi. Veľkou výhodou

je aj presadzovanie Cloud Computingu v podobe Cloud aplikácií pre koncových

používateľov a to aj pre mobilné zariadenia, čo uľahčuje synchronizáciu, vzdialený

prístup, zdieľanie dát, prístup k dátam odkiaľkoľvek a podobne.

1.2 Hlavné vlastnosti Cloud Computingu

Architektúra Cloud Computingu je autonómny systém a teda je schopný

samoriadenia, samozotavenia sa v prípade chyby, dokáže automaticky škálovať výkon

FEI KPI

17

a distribuovať zaťaženie podľa aktuálneho stavu, relatívne samostatne zriadiť ďalšiu

výpočtovú jednotku (server), kontrolovať výskyt chyby pri behu a pod.

Cloud Computing funguje zväčša ako Client-server model. Majoritná časť sa

vykonáva na strane servera (výpočtové úlohy aj ukladanie dát), zvyšná časť na strane

klienta (záleží od implementácie), kde na strane klienta ide väčšinou len o zobrazovanie

grafického výstupu, ktorý poskytuje server prípadne jednoduchej kontroly vstupu.

Samotná architektúra výpočtového centra pre Cloud Computing je obdobou Grid

(Data Center) computingu. Grid Computing je forma distribuovaného a paralelného

výpočtového systému, ktorý je tvorený zoskupením sieťou (alebo optickými vláknami,

či iným) prepojených, voľne viazaných počítačov. V takomto systéme je pomerne silno

presadzovaná paralelizácia výpočtových úloh. V týchto centrách sa skladujú aj samotné

dáta používateľov, pričom na samotných koncových zariadeniach používateľov kópie

dát môžu ale nemusia existovať. Tieto centrá majú zväčša rozlohu malého mesta, sú

často sebestačné po viacerých stránkach ako je elektrina a podobne. Preto sú často

stavané pri zdrojoch energie ako sú rieky a podobne. V týchto centrách je vysoký stupeň

ochrany a bezpečnosti, keďže sa na jednom mieste často nachádzajú obrovské množstvá

dát veľkého počtu klientov.

Pri Cloud Computingu sa spomína aj výraz Utility computing. Tento výraz hovorí

o pohľade kde sa výpočtový výkon a/alebo úložný priestor, zohľadňuje ako konzumná,

ľahko dostupná komodita. Počíta sa na časové úseky. Tento pohľad umožňuje čo

najefektívnejšie využitie výpočtového výkonu a úložného priestoru, kde sa platí len za

to čo sa spotrebujete. Ak aj prekročíte svoj predobjednaný objem (dátového priestoru

a/alebo výpočtovej kapacity) tak sa vám podľa typu zmluvy môže automaticky priradiť

ďalší objem nad rámec objednaného objemu, pričom zaplatíte len toľko koľko ste

spotrebovali naviac.

Výhodou Cloud Computingu je aj to, že každý užívateľ si zvolí do akej miery chce

mať priamu kontrolu nad systémom a ostatné starosti prenechá prevádzkovateľovi

systému. Ak na projekt postačuje len prostredie kde sa dá spustiť aplikácia, je nepotrené

mať pod kontrolou HW, operačný systém alebo iné záležitosti. Takýto prístup umožňuje

nasadenie projektov aj bez potrebného personálu, ktorý by spravoval nižšie stupne

systému, ktoré v skutočnosti slúžia len ako základňa pre beh aplikácie.

Medzi širokou verejnosťou je asi najviac známa vlastnosť Cloud Computingu to,

že je možné ku dátam pristupovať z akéhokoľvek miesta kde je pripojenie na Internet

FEI KPI

18

a z akéhokoľvek zariadenia, ktoré podporuje prístupové rozhranie, čo je vo väčšine

prípadov internetový prehliadač.

1.3 História Cloud Computingu a jeho vývoj

1.4 Ciele nasadzovania Cloud Computingu

Cloud riešenie zabezpečuje, že všetky dáta a vykonávanie sa presúva na stranu

Cloud-u, pričom užívateľský počítač slúži iba ako terminál pre zobrazenie výstupu

Cloud odbremeňuje užívateľov od zložitého spravovania, záplatovania, inštalácie,

znižuje nároky na hardware na strane užívateľa, a zároveň poskytuje efektívnejšie

využívanie a prerozdelenie dostupných zdrojov

Cloud zabezpečuje prístupnosť a funkčnosť aplikácie aj nad rámec štandardných

riešení ako sú lokálne systémy, server housing, či virtualizácia. Cloud stojí obrazne

povedané nad všetkými týmito riešeniami

Cloud spojuje výhody dostupnosti Internetu, serverových fariem, virtualizácie v

jeden funkčný a výhodný celok.

Cloud znižuje náklady na zriadenie a prevádzku, a zároveň znižuje čas na

zriadenie systému.

Cloud zvyšuje bezpečnosť a zvyšuje spoľahlivosť systému a zároveň poskytuje

prístup k systéme z akéhokoľvek miesta s prístupom na Internet

Cloud umožňuje zjednotiť trh a rozširovať hranice uplatnenia, tým že jednotlivé

riešenia môžu byť dostupne a replikované po celom svete, prípadne môžu byť naviazané

na iné už existujúce Cloud riešenia

1.5 Výhody a nevýhody Cloud Computingu

Výhody:

Nižšie zriaďovacie aj prevádzkové náklady

Jednoduchosť rozširovania aplikácií

Platí sa iba za spotrebované prostriedky

SLA – zmluvné podmienky zaručujú vybraný štandard

Celkove lepšie využívanie zdrojov, menšie plytvanie elektrinou, nižšia

produkcia CO2.

Bezpečnosť je na strane poskytovateľa riešená profesionálnym prístupom

FEI KPI

19

Nevýhody:

Zo začiatku komplikovanejšie nasadzovanie riešenia v niektorých prípadoch .

Potreba stáleho (a rýchleho) pripojenia na Internet .

Výlučná závislosť na poskytovateľovi .

Riziko nemožnosti alebo komplikácií pri prípadnej migrácií riešenia .

Bezpečnosť – väčší poskytovateľ je väčším lákadlom pre hrozby a útoky, pri

úspešnom útoku útočník kompromituje viacero systémov naraz .

Súkromie – dáta sú uložené na neznámom (alebo neprístupnom) mieste u tretej

strany, bez možnosti priamej interakcie.

FEI KPI

20

2 Architektúra Cloud Computingu

Architektúra Cloud-u sa skladá z viacerých samostatných modulov, ktoré spolu

komunikujú a spolupracujú pomocou štandardizovaných a univerzálnych API

(application programming interfaces)

Väčšina Cloud-ov má voľne prístupné a zdokumentované API pre použitie Cloud

prostriedkov v aplikáciách tretích strán

Pri architektúre Cloud sa zvykne hovoriť o tzv. back-end a front-end

Back-End je časť Cloud-u, ktorú užívateľ priamo nevidí a nemá možnosť ju

ovplyvniť, zahřňa hardware aj software na strane poskytovateľa

Front-End je časť Cloud-u, cez ktorú užívateľ komunikuje s Cloud-om a zahŕňa aj

prístupový hardware a software užívateľa

Cloud sa delí do týchto vrstiev: Klient, Aplikácia, Platforma, Infraštruktúra, Server

Architektúra Cloud je zobrazená na obrázku 1

Obrázok 1 Architektúra cloud

2.1 Jednotlivé typy Cloud Computingu podľa prístupu

Typy Cloud sú zobrazené na obrázku 2

FEI KPI

21

Obrázok 2 Typy cloud computingu

Public:

Public Cloud – typ Cloud-u, kde sú dáta spracované v jednom cloude spolu s

dátami iných organizácií (samozrejme v oddelených inštanciách), zväčša poskytuje

najväčší výpočtový výkon a úložnú kapacitu za najnižšiu cenu. Nevýhodou je väčšinou

negarantovaný výkon a pre isté systémy malá bezpečnosť.

Community:

Community Cloud – Obdoba Public Cloud-u kde však Cloud zdieľajú iba isté

organizácie so spoločnými záujmami a odbornými doménami. Zaručuje relatívne

vysokú bezpečnosť a výkon pri nízkej cene a dobre efektivite

Hybrid:

Hybrid Cloud – spája public a private Cloud spolu s klasickým lokálnym

vyčleneným prístupom, ako napr. záloha na pásky a zároveň do Cloud-u.

Combined:

Combined Cloud – označuje spojenie dvoch a viacerých Cloud-ov zväčša od

rôznych poskytovateľov

FEI KPI

22

Private:

Private Cloud – označuje variantu keď si organizácia prenajme svoj vlastný Cloud,

zväčša aj na vlastnom pozemku, ktorý spracováva iba jej dáta a celý výkon je určený

iba pre túto organizáciu. Táto varianta Cloud-u vlastne nie je Cloud-om, je to iba mierne

pozmenený koncept virtualizácie na serveroch

2.2 Služby poskytované Cloud Computingom

Typy služieb ponúkané Cloudom sú:

Software as Service:

Software as a Service (SaaS) – znamená, že používateľ iba používa (konzumuje)

aplikáciu, ktorú už niekto pred ním vytvoril, pričom táto aplikácia beží u poskytovateľa.

Užívateľ si vie prispôsobiť aplikáciu len v rámci možností, ktoré mu povolil výrobca

aplikácie a poskytovateľ. Webový email, Microsoft Live, Google Documents sú veľmi

známymi príkladmi SaaS.

Infrastructure as Service:

Infrastructure as a Service (IaaS) – zahŕňa prístup ku výpočtovým prostriedkom na

úrovni hardwaru ako servery a dátové centály cez Internet, čo znamená, že k nim

nemáte fyzický prístup a môžu sa nachádzať kdekoľvek na svete. Platí sa iba za to čo sa

využije. Web hosting je príkladom IaaS Cloud-u, kde platíte za istý čas istú čiastku a

poskytovateľ za to poskytuje vaše dáta a aplikácie na svojich serveroch v dohodnutých

podmienkach.

Platform as Service:

Platform as a Service (PaaS) – umožňuje vývoj užívateľskej aplikácie pomocou

webových nástrojov a následne nasadenie tejto aplikácie na software a hardware

poskytovateľa. Takže užívateľ spravuje iba svoju aplikácia ostatné ma na starosti

poskytovateľ. Príkladom PaaS je Google App Engine.

FEI KPI

23

Communication as Service – umožňuje implementovať komunikačné služby ako

VoIP a Unified Communications (UC), bez potreby nákupu, prevádzkovania a údržby

zariadení k tomu potrebných. Tento typ sa ešte len rozmáha v sektore väčších firiem

pretože, umožňuje využívať VoIP a UC aj bez vysokých poplatkov.

Monitoring as Service – umožňuje monitorovať jednotlivé komponenty, alebo celé

časti riešenia pomocou služieb, ktoré sú riadené a prevádzkované poskytovateľom

služby. Výhodou je, že nie je potrebné vlastné riešenia na monitorovanie dostupnosti.

2.3 Komerční prevádzkovatelia Cloud Computingu a ich

zameranie

Google sa zameriava ako na súkromných užívateľov a koncových zákazníkov,

ktorým ponúka cloud veľké množstvo produktov, aplikácií, operačné systémy, netbooky

a podobne, tak aj na business sféru, kde ponúka robustné riešenia aj pre najrozsiahlejšie

projekty.

Microsoft sa primárne zameriava na business sektor so svojimi produktmi ako

Microsoft 365, Windows Azure, Windows Server Hyper-V, Windows Intune

a podobne. Pre súkromných užívateľov ponúka svoju radu Windows Live. Nový

operačný systém Windows 8, bude taktiež do značnej miery podporovať Cloud služby.

Amazon sa zameriava takmer výlučne na business sektor a zákazníkov, ktorý si

u neho nechávajú prevádzkovať svoje projekty. Najznámejší produkt je Elastic

Compute Cloud (Amazon EC2).

IBM sa taktiež zameriava na business sektor so svojim produktom IBM Smart

Business, ktorý dokáže pracovať aj ako súkromné riešenie vo vnútri firmy, alebo ako

Cloud riešenie. Známym produktom je aj IBM LotusLive.

Salesforce ponúka cloud riešenia pre svojich zákazníkov na mieru. Zameriava sa

najmä na reklamné a sociálne projekty.

FEI KPI

24

Hewlett Packard ponúka viacero produktov primárne zameraných na firemných

zákazníkov, no v pláne má aj produkty pre súkromné osoby a koncových užívateľov.

Oracle ponúka produkty zamerané na firmy a jeho paleta produktov je naozaj

pestrá. Oracle vychádza aj zo svojich už etablovaných technológií.

NetApp sa primárne zameriava na Cloud aplikácie a ponúka produkty širokému

spektru zákazníkov.

2.4 Možnosti a techniky prístupu do cloudu

Prístup ku Cloud službám je zobrazený na obrázku 3

Obrázok 3 Prístup ku Cloud službám

Cloud aplikácie sú veľmi podobné klasickým aplikáciám, s rozdielom, že ako

úložisko dát používajú cloud úložisko. Môžu byť však aj úplne presunuté do cloudu,

a teda aj ich vykonávanie sa odohráva v cloude.

Webové API. Pomocou rozhraní API je možné pristupovať ku verejným alebo aj

súkromným funkciám, ktoré sú poskytované ako rozhrania a je ich teda možné využívať

v množstve iných riešení. Príkladom je napr. Google Maps API.

Webové prehliadače. Štandardným prístupovým prvkom ku webovým aplikáciám

sú moderné webové prehliadače. Prehliadač tak slúži len ako zobrazovacie zariadenie,

všetky výpočty a dáta sú situované v cloude.

FEI KPI

25

3 Čo je to High Availability

High Availability (ďalej iba HA) je systémový dizajn a naviazaná implementácia

systému, ktorá zabezpečuje dopredu dohodnutú úroveň dostupnosti a výkonu daného

systému na dané obdobie.

Je snaha aby niektoré systémy ako napr. atómové elektrárne, letiská, lietadlá,

nemocnice, lekárske prístroje a podobne, boli vždy dosiahnuteľné. Teda aby ich bolo

možné využívať v každom momente, a aby ich prevádzku neohrozil nedostatok

výpočtového výkonu, pri špičke využívania, prípadne výpadok časti systému, výpadok

sieťového pripojenia a podobne.

Pod pojmom dostupnosť sa myslí možnosť užívateľov v plnej miere (bez

obmedzení) pristupovať ku systému za účelom jeho používania. Prístupné musia byť

všetky jeho časti, ktoré užívateľ potrebuje ku práci a prípadné oneskorenie nesmie

prekročiť akceptovateľnú hodnotu.

V prípade, že je systém nedostupný, takýto stav (resp. čas počas ktorého je systém

nedostupný) sa nazýva downtime. Tu sa ešte rozdeľuje, či je tento výpadok

v dostupnosti plánovaný, teda napr. dopredu plánovaná údržba, alebo neplánovaný,

napr. výpadok sieťového pripojenia.

Dostupnosť systému sa vyjadruje v percentách a toto percento vyjadruje

dostupnosť systému počas jedného roka (365 dní). Dostupnosť sa počíta tak ako je

uvedené v nasledujúcej tabuľke na konkrétnych prípadoch.

Dostupnosť % Downtime za rok Downtime za

mesiac

Downtime za

týždeň

90% ("jedna

deviatka")

36,5 dní 72 hodín 16,8 hodín

95% 18,25 dní 36 hodín 8,4 hodín

97% 10,96 dní 21,6 hodín 5,04 hodín

98% 7,30 dní 14,4 hodín 3,36 hodín

99%("dve

deviatky")

3,65 dní 7,20 hodín 1,68 hodín

FEI KPI

26

99,5% 1,83 dní 3,60 hodín 50,4 minút

99,8% 17,52 hodín 86,23 minút 20,16 minút

99,9%("tri

deviatky")

8,76 hodín 43,2 minút 10,1 minút

99,95% 4,38 hodín 21,56 minút 5,04 minút

99,99%("štyri

deviatky")

52,56 minút 4,32 minút 1,01 minút

99,999%("päť

deviatok")

5,26 minút 25,9 sekúnd 6,05 sekúnd

99,9999%("šesť

deviatok")

31,5 sekúnd 2,59 sekúnd 0,605 sekúnd

Tabuľka 1 Príklad dostupností

Daná percentuálna hodnota hovorí akú má systém dostupnosť. Pri objednávaní

systému sa u poskytovateľa služby dohodne tzv. SLA (Service Level Agreement), čo je

poskytovateľom garantovaná kvalita služieb, ktorá okrem iného môže obsahovať aj

klauzulu aká je garantovaná dostupnosť. V prípade, že poskytovateľ túto hodnotu

nedodrží, typicky je možné od neho vymáhať sankciu za nedodržanie.

FEI KPI

27

4 Mechanizmy dynamického prideľovania zdrojov

a rozdeľovania záťaže

4.1 Prideľovanie zdrojov na úrovni poskytnutej služby

(Vmware vSphere)

VMware je ideálna platforma pre výstavbu cloud infraštruktúry. Poskytuje

efektivitu a nízke náklady cloud computingu s podrobnou kontrolou nad úrovňami

služieb.

VMware vSphere, je prvý cloud operačný systém, využíva možnosti virtualizácie

na transformovanie dátových centier na výrazne zjednodušené infraštruktúry cloud

computingu. Umožňuje tak IT organizáciám ponúkať flexibilné a spoľahlivé IT služby

novej generácie za použitia interných i externých zdrojov, to všetko v zabezpečenej

forme a s nízkym rizikom. Výkon platformy VMware Infrastructure, je základom

riešenia VMware vSphere, ktoré podstatne redukuje kapitálové aj prevádzkové náklady,

posilňuje kontrolu nad poskytovaním IT služieb a zachováva flexibilitu vo výbere

operačného systému, aplikácií i hardvéru, či už v internej, či externej podobe. Riešenie

VMware vSphere ponúka základňu pre interné i externé cloudy, umožňuje ich

prepojenie štandardizovaným spôsobom a organizáciám všetkých veľkostí prináša

všetky výhody cloud computingu.

4.1.1 Detailná charakteristika Vmware v Sphere

Riešenie VMware vSphere odbremeňuje aplikácie a informačné zdroje od zložitej

základnej infraštruktúry a vytvára internú cloud infraštruktúru. Informačné technológie

potom môžu byť využité pre podporu a zvyšovanie hodnoty podniku. Nižšie náklady a

maximálna efektivita informačných technológií eliminuje zbytočné investície a znižuje

náklady a zložitosť súvisiace so správou a údržbou IT infraštruktúry. Organizáciám sa

tak otvára cesta k efektívnejšiemu poskytovaniu IT služieb. Výrazne tak klesajú celkové

náklady na vlastníctvo a prevádzku podnikových aplikácií. Vďaka automatickej správe

a dynamickému prideľovanie zdrojov aplikáciám v rámci interných aj externých cloud

infraštruktúry môžu organizácie využívajúce toto riešenie dosahovať vysoké

konsolidačné pomery. Výsledkom je opustenie drahého modelu poskytovania aplikácií

FEI KPI

28

a informácií, ktorý je zviazaný s konkrétnymi systémami a architektúrami, a plynulý

prechod k dynamicky optimalizovanému IT prostredia s automatickou správou, ktoré

ponúka maximálnu efektivitu pri poskytovaní podnikových služieb. Vzhľadom na

zvyšujúce sa závislosti podnikov na IT službách môže efektívne poskytovanie aplikácií

predstavovať rozdiel medzi rastom a poklesom, úspechom a neúspechom. Pri

poskytovaní aplikácií a zodpovedajúcej kvality služieb sa podniky plne spoliehajú na

informačné technológie. VMware vSphere automatizuje poskytovanie zmlúv pre úrovne

služieb (SLA - service-level agreement) a pokrýva dostupnosť, zabezpečenie i

prispôsobiteľnosť. Model správy dátových centier sa tak presúva z infraštruktúry do

oblasti poskytovania služieb. Vlastníci aplikácií, ktorí potrebujú vydávať nové

podnikové služby, sú odbremenení od zložitosti serverov, úložísk a sietí a môžu sa

sústrediť iba na poskytovanie vlastnej hodnoty. Výsledkom je automatizované, riadené

prostredie, ktoré je odolné proti zlyhaniu a prispôsobivé meniacim sa požiadavkám, bez

toho aby dochádzalo k nárastu operačnej réžie či zložitosti. VMware poskytuje slobodu

vo voľbe hardvéru, aplikačnej architektúry, operačného systému a interné či externé

infraštruktúry pre meniace sa požiadavky podniku. Vďaka tomuto riešeniu si zákazníci

zachovajú flexibilitu voľby a zostanú nezávislí na hardvéri, operačnom systéme,

aplikáciách a poskytovateľoch služieb. To znamená, že zákazníci môžu podporovať

svoje existujúce aplikácie a pritom byť pripravení na príchod aplikácií budúcich. To

všetko pri zachovaní flexibility, ktorá umožňuje nasadenie v interných či externých

cloud infraštruktúrach. Súčasťou je aj skutočnosť, že aplikácie sú spúšťané na

virtuálnych strojoch, ktoré bežia na menšom počte serverov a efektívnejšie využívajú

úložné a sieťové zdroje. Organizácie využívajúce takéto riešenie môžu vďaka jeho

unikátnym schopnostiam v oblasti dynamickej optimalizácie a správy pamäte dosiahnuť

maximálnych konsolidačných pomerov na server. VMware vSphere zjednodušuje

správu hardvéru prostredníctvom kompletnej vizualizácie serverového, úložného i

sieťového hardvéru. Vylepšenie kontinuity činnosti prostredníctvom jednoduchých a

cenovo úsporných systémov vysokej dostupnosti a obnovy po havárii pomáha vytvárať

zabezpečenú, vysoko odolnú infraštruktúru, ktorá udržuje podnik v chode bez ohľadu na

poruchy hardvéru alebo výpadky celých dátových centier. Takéto riešenie eliminuje

odstávky aplikácií vďaka plánovanej údržbe serverov, úložísk a sietí, a navyše

poskytuje jednoduchý, cenovo úsporný systém vysokej dostupnosti, ktorý rieši

neplánované výpadky, spôsobené napríklad poruchami serverov. Takéto riešenie tiež

zjednodušuje obnovu po výpadkoch celých dátových centier, a to bez potreby drahého

FEI KPI

29

redundantného hardvéru. Riešenie VMware vSphere zjednodušuje správu prevádzky

testovacích, vývojových a výrobných prostredí bez ohľadu na použité aplikácie,

operačné systémy a konkrétne fyzické umiestnenie a taktiež umožňuje jednoduché

zdieľanie a náhradu hardvéru a zjednodušuje správy prostredníctvom spoločných zásad,

prevádzkových postupov a automatizovaných správ naprieč rôznorodým spektrom

aplikácií a podnikových užívateľov. Taktiež zjednodušuje zabezpečovanie podnikových

služieb a konzistentne chráni jednotlivé úrovne služieb bez ohľadu na fyzickú

infraštruktúru a skutočné umiestnenie služieb. Klesá tak prevádzková réžia, a navyše je

možné prenášať aplikácie medzi internými a externými cloud infraštruktúrami bez

dodatočných úprav a straty úrovňou služieb.

VMware vSphere je cloud operačným systémom, tvoreným nasledovnými

skupinami súčastí:

Služby infraštruktúry - sada súčasťou, ktoré plne virtualizuje serverové, úložné a

sieťové zdroje, zlučujú je a presne podľa potreby je prideľujú aplikáciám v závislosti od

priorít podniku.

Aplikačné služby - sada súčasťou, ktoré majú prístup k vstavanému riadenie

úrovní služieb a toto konanie poskytujú všetkým aplikáciám spusteným na platforme

VMware vSphere bez ohľadu na typ aplikácie alebo operačný systém.

Správa služieb infraštruktúry i aplikačných služieb je k dispozícii prostredníctvom

serveru VMware vCenter Server1, ktorý ďalej ponúka automatizáciu každodenných

prevádzkových úkonov a podrobné sledovanie všetkých aspektov malých i veľkých

prostredie VMware vSphere.

4.1.2 Služby infraštruktúry: Virtualizácia a agregácie hardvérových

zdrojov

Služby infraštruktúry transformujú oddelené hardvérové zdroje na zdieľanú

výpočtovú platformu, ktorá je neuveriteľne odolná a výpočtovo náročným aplikáciám

poskytuje výkon blížiaci sa natívnemu prostredia. Riešenie VMware vSphere poskytuje

nasledovné typy služieb infraštruktúry:

FEI KPI

30

VMware vCompute: Služby infraštruktúry, ktoré efektívne virtualizujú serverové

zdroje a zlučujú ich do logických celkov, ktoré môžu byť presne prideľované

aplikáciám.

Systémy VMware ESX a VMware ESXi poskytujú robustnú, overenú a vysoko

výkonnú virtualizačnú vrstvu, ktorá abstrahuje hardvérové zdroje serverov a umožňuje

ich zdieľanie medzi viacerými virtuálnymi strojmi. Unikátna správa pamäte a pokročilé

plánovanie v systémoch VMware ESX a ESXi umožňujú dosahovať maximálnych

konsolidačných pomerov a vynikajúceho aplikačného výkonu, ktorý v mnohých

prípadoch prevyšuje fyzické servery.

Plánovač VMware Distributed Resource Scheduler (DRS) zlučuje výpočtové

zdroje naprieč mnohými klastrami a dynamicky ich prideľuje virtuálnym strojom v

závislosti od priorít podniku. Samozrejmosťou je automatizácia, ktorá znižuje zložitosť

správy. Technológia VMware Distributed Power Management (DPM), ktorá je

súčasťou plánovača VMware DRS, zabezpečuje nepretržitú a automatickú

optimalizáciu energetickej spotreby serverov v rámci každého klastra.

VMware vStorage: Služby infraštruktúry, ktoré abstrahujú úložné zdroje od

zložitosti základných hardvérových systémov, a umožňujú tak maximálne efektívne

využitie úložnej kapacity vo virtualizovaných prostrediach.

VMware vStorage Virtual Machine File System (VMFS) je vysoko výkonný

súborový systém pre prácu s klastrami, ktorý umožňuje efektívne zdieľanie a riadi

súčasné prístupy virtualizovaných serverov k úložisku.

Systém VMware vStorage Thin Provisioning ponúka dynamické prideľovanie

úložnej kapacity a umožňuje odkladať nákupy úložného priestoru tak dlho, kým nie sú

skutočne potrebné. Výdavky súvisiace s úložným priestorom sa tak znížia.

VMware vNetwork: Služby infraštruktúry, ktoré umožňujú optimálne riadenie sietí

vo virtuálnych prostrediach.

Nástroj VMware vNetwork Distributed Prepínač zjednodušuje a vylepšuje

zabezpečovanie, správu a ovládanie sieťovej komunikácie medzi virtuálnymi strojmi v

prostredí VMware vSphere. Rovnako v prostredí VMware vSphere umožňuje používať

distribuované virtuálne prepínače tretích strán (napr. Cisco Nexus 1000V). Správcovia

sietí tak majú k dispozícii známa rozhranie, pomocou ktorých môžu ovládať kvalitu

služieb na úrovni virtuálnych strojov.

FEI KPI

31

Aplikačné služby VMware vSphere sprístupňujú vstavané prvky, ktorými možno

riadiť úrovne aplikačných služieb, ako je dostupnosť, zabezpečenie a prispôsobiteľnosť.

Tieto služby možno povoliť jednoduchým a jednotným spôsobom pre ľubovoľnú

aplikáciu spustenú vo virtuálnom stroji VMware.

Služby dostupnosti poskytujú aplikáciám podľa ich priority a potrieb rôzne úrovne

vysokej dostupnosti. Odpadá pritom potreba zložitého redundantného hardvéru a

softvéru pre prácu s klastrami.

Nástroj VMware Storage VMotion zabezpečuje plynulý chod aplikácií, ktorý nie

je narušovaný plánovanou údržbou úložiska ani prenosom úložiska. Využíva pritom

migráciu diskov spustených virtuálnych strojov, bez toho aby dochádzalo k prerušeniu

práce užívateľov alebo strate služieb.

Nástroj VMware High Availability (HA) predstavuje cenovo efektívny spôsob,

ako automaticky a rýchlo (niekoľko minút) reštartovať aplikácie v prípade poruchy

hardvéru alebo zlyhania operačného systému.

Nástroj VMware Fault Tolerance poskytuje trvalú dostupnosť akejkoľvek

aplikácie, bez straty dát alebo prerušenia prevádzky v prípade poruchy hardvéru.

Nástroj VMware Data Recovery poskytuje zálohu a obnovu bez potreby agenta.

Toto jednoduché a cenovo efektívne riešenie je určené pre virtuálne stroje v menších

prostrediach.

4.1.3 Zabezpečenie: Služby zabezpečenia

Služby zabezpečenia poskytujú aplikáciám možnosť využívať a vyžadovať

bezpečnostné zásady prevádzkovo efektívnym spôsobom.

Nástroj VMware vShield Zones dohliada na dodržiavanie podnikových

bezpečnostných zásad na aplikačnej úrovni v zdieľanom prostredí. Zjednodušuje tak

zabezpečenie aplikácií a zachováva pritom dôveryhodné zóny a sieťovú segmentáciu

užívateľov a citlivých dát.

Nástroj VMware VMsafe umožňuje použitie bezpečnostných produktov, ktoré

spolupracujú s virtualizačnou vrstvou a poskytujú virtuálnym strojom vyššiu úroveň

zabezpečenia než fyzické servery.

FEI KPI

32

4.1.4 Škálovateľnosť

Služby škálovateľnosti umožňujú poskytovať každej aplikácii správne množstvo

výpočtových zdrojov v závislosti na jej potrebách.

Plánovač VMware DRS dynamicky načítava serverové zdroje a podľa priorít

podniku ich priraďuje jednotlivým aplikáciám. Záber aplikácií tak môže požadovaným

spôsobom rásť alebo klesať.

Pridávanie za prevádzky (HOT ADD) umožňuje podľa potreby pridávať do

virtuálnych strojov procesory a pamäť bez prerušenia činnosti.

Pripájanie za prevádzky (HOT PLUG) umožňuje do virtuálnych strojov pridávať

alebo z nich odoberať virtuálne úložné a sieťové zariadenia bez prerušenia činnosti.

Rozširovanie virtuálnych diskov za prevádzky umožňuje do spustených

virtuálnych strojov pridávať virtuálne úložisko bez prerušenia činnosti.

Aplikácia VAPP: Zabezpečenie plynulého prechodu aplikácií medzi cloudmi a ich

výber. Systém VAPP - logická entitu zahŕňajúca jeden alebo viac virtuálnych strojov,

ktorá využíva štandardný formát OVF (Open Virtualization Format) na špecifikáciu a

zapuzdrenie všetkých súčastí viacstupňovej aplikácie a všetkých prevádzkových zásad a

úrovne služieb, ktoré sú k tejto aplikáciu priradené. Systém VAPP umožňuje vlastníkom

aplikácií popísať prevádzkové zásady konkrétnej aplikácie tak, aby ich mohol cloud

operačný systém automaticky interpretovať a vykonávať. Systém VAPP môže

obsahovať ľubovoľné aplikácie, spustené v ľubovoľnom operačnom systéme, a ponúka

zákazníkom mechanizmus, ako prevádzať aplikácie medzi internými a externými

cloudmi pri zachovaní úrovne služieb.

4.2 Prideľovanie zdrojov na úrovni platformy

Pre dynamické prideľovanie zdrojov a zabezpečenie rozdelenia zdrojov sa na

úrovni infraštruktúry používa viacero techník medzi inými napríklad, LoadBalancer,

HSRP, Heartbeat, Network load balancing, (Global) Server Load Balancing a podobne.

Zabezpečenie prideľovania zdrojov na platformovej vrstve má výhody hlavne kvôli

tomu, že je nezávislé na aplikácii alebo službe, no zároveň pridáva konfiguračnú

a údržbovú zložitosť, a zároveň môže zvýšiť cenu celého systému.

FEI KPI

33

4.2.1 Cisco ACE Load Balancer

Princíp load-balancing Cisco ACE distribuuje traffic medzi viac serverov alebo

virtuálnych strojov vnútri virtuálneho racku. Jedná sa o hardvérové riešenie, ktoré

zaručuje plnú dostupnosť a uľahčí škálovateľnosť webových stránok, služieb alebo

aplikácií. Cisco ACE load balancer detekuje chybné servery alebo VM a vylúči ich

automaticky z okruhu serverov a zároveň presmeruje prevádzku na iné, funkčné servery

alebo VM. Vďaka systému "sticky groups", môže load-balancer ACE pripojiť užívateľa

k serveru / VM, čím všetko výrazne zjednodušuje. Sieť založená na Cisco ACE bude

úplne izolovaná a zdroje budú garantované úplne a len v rámci vybraného kontextu.

Hardvér je spravovaný väčšinou u poskytovateľ a konfigurácia rozdelenia záťaže sa

nastavuju pomocou vzdialeného prístupu napr. SSH. Pomocou Cisco ACE Load

balancingu je možné rozdeliť traffic HTTP, FTP, DNS, SIP, RTSP, POP / IMAP,

rozdeliť traffic SSL, definovať "záťaž" každého svojho serveru alebo VM, konfigurovať

monitoring, spravujte NAT / DNAT pre Váš virtuálny rack, vizualizovať stavy a

výkony v SNMP a podobne. Tento princíp zároveň zachováva pokročilé funkcie ACE

ako ochrana pred DoS, podpora ACL (Access Control List) a podobne. Fyzické riešenie

je v tvare, že sú dané 2 a viac ACE modulov a konfigurácia sa duplikuje na všetky

zariadenia.

4.2.2 HSRP

HSRP (Hot Standby Router Protocol) je Cisco proprietárny protokol, ktorý slúži

na zvolenie resp. zabezpečenie štandardnej brány, ktorá by bola odolná voči chybám

a výpadkom. Pri použití tejto technológie je v sieti určené primárna brána (smerovač),

ktorá sa používa na komunikáciu do internetu, prípadne teda mimo lokálnej siete.

V prípade výpadku či preťaženia tohto primárneho smerovača je určený záložný

smerovač, ktorý zastúpi funkciu primárneho. Už s funkcie je jasné, že sa jedná primárne

o systém pre redundanciu, no je možné ho na sieťovej vrstve použiť aj na jednoduché

rozkladanie záťaže. Tento systém zväčša funguje nezávisle na samotnom cloud riešení

a je súčasťou sieťovej infraštruktúry ako takej.

FEI KPI

34

4.2.3 Heartbeat

VMware vCenter Server Heartbeat zabezpečuje vysokú dostupnosť (HA) pre

VMware vCenter Server, ochraňujúc virtuálnu a cloud infraštruktúru pred chybnými

aplikáciami, konfiguráciou, operačným systémom, sieťovým a hardwarovými

problémami. Jedná sa o systém na monitorovanie a vyhodnocovanie dostupnosti,

výkonu, zaťaženia a podobných vlastností jednotlivých serverov v rámci cloud

architektúry.

4.2.4 Network Load Balancing

Princíp rozdeľovania záťaže Network Load Balancing umožňuje rozdeľovanie

záťaže na sieťovej vrstve, bežne na smerovačoch alebo prepínačoch. V tomto prípade sa

o rozdeľovanie stará špeciálny protokol na sieťových zariadeniach ako napr. Load

balancing pri použití smerovacieho protokolu EIGRP. Používa sa iba

v špecializovaných prípadoch a bežne sa nahradzuje inými metódami, resp. je už

použitá v sieťovej infraštruktúre bez ohľadu na iné systémy.

4.2.5 Server Load Balancing

Zvyšovanie výkonu serverových fariem, najmä u webových aplikácií, je možné

zabezpečiť minimálne dvoma spôsobmi. Buď posilňovaním výkonu jedného stroja,

alebo rozložením záťaže na viac slabších strojov – tzv. Server Load Balancing. Pri

tomto spôsobe je však potrebné zaviesť nový prvok, zaisťujúce rozkladanie záťaže, jeho

názov je napr. load balancing prepínač, aplikačný prepínač, L7 prepínač, Web prepínač

atď.

Zvyšovanie výkonu serverových fariem, najmä u webových aplikácií, je možné

zabezpečiť minimálne dvoma spôsobmi:

Posilňovanie výkonu jedného stroja, čo má niekoľko nevýhod (napr. obmedzenie

príslušného hardvéru alebo OS; občas je nutné stroj odstaviť a vykonať údržbu).

FEI KPI

35

Rozložením záťaže na viac slabších strojov, čím sa vyššie uvedené nevýhody

eliminujú (pri potrebe zvýšenia výkonu sa pridá ďalší server; odstavenie časti serverov

má vplyv maximálne na výkon), navyše sa do systému vnáša redundancia.

V súčasnosti sú k dispozícii aj iné technológie pre optimalizáciu rozloženia záťaže

na servery (serverové riešenia založené na tom, že jeden zo serverov je akýmsi

arbitrom, ktorý zaisťuje rozkladanie záťaže medzi ostatné servery v skupine), avšak

load balancing prepínače majú niektoré vlastnosti, ktorými tieto iné technológie

predbehnú.

Load balancing prepínače sú L2/L3 prepínače, ktoré navyše zaisťujú rôzne funkcie:

Rozkladanie záťaže pre aplikácie na viac serverov, teda vlastnosť SLB.

Globálny server load balancing (GSLB) - teda rozkladanie záťaže medzi

geograficky oddelenými serverovými farmami.

V závislosti na technológii môžu zariadenia zabezpečovať aj ďalšie funkcie (napr.

Intelligent Traffic Management - teda riadenie prevádzky, Firewall Load Balancing,

ochranu pred DOS útoky, optimalizácia využívania Internet liniek atď.). Ak je v texte

uvedené "rozkladanie záťaže", automaticky to znamená aj zabezpečenie redundancie.

4.2.6 Princíp fungovania Server Load Balancing (SLB)

Celá myšlienka rozkladanie záťaže je založená na tom, že používateľ pristupuje k

web serveru na základe jeho verejnej IP adresy. Napr. pre www.google.com je touto

adresou adresa 209.85.148.94. Táto adresa je nakonfigurovaná ako virtuálna IP adresa

na SLB prepínači. Za prepínačom sa spravidla skrýva farma niekoľkých serverov s tzv.

reálnymi IP adresami, ktoré aktívne komunikujú s užívateľmi. Používateľ nevie, na

ktorý z reálnych serverov sa pripojil, ale ak je aplikácia dobre napísaná, ani ho to

nemusí trápiť.

Na obrázku 4 je popísaná funkcia SLB prepínača.

FEI KPI

36

Obrázok 4 Funkcia SLB prepínača

Ku každému verejnému (webovému) serveru existuje skupina fyzických serverov, ktoré

sú skryté za SLB prepínačom.

SLB prepínač pre rozkladanie záťaže a redundanciu serverov zabezpečuje tieto funkcie:

algoritmus pre rozkladanie záťaže;

mechanizmus pre kontrolu dostupnosti reálnych serverov;

mechanizmus pre návrat reálneho servera do skupiny po jeho výpadku (napr.

reštartu).

4.2.7 Algoritmus pre rozloženie záťaže v rámci SLB

Používajú sa napr. tieto metódy:

najmenej spojenia;

round robin (cyklická obsluha), teda rovnomerné delenie (prípadne vážené

delenie);

čas odpovede (sleduje rýchlosť odozvy od reálnych serverov);

využité pásmo (sleduje množstvo dát prichádzajúcich od jednotlivých reálnych

serverov).

FEI KPI

37

Pre zachovanie konkrétneho spojenia medzi užívateľom a konkrétnym fyzickým

serverom je používaný identifikátor spojenia (session ID), ktorý je určený z IP adresy

klienta a náhodne generovaného zdrojového portu (ten istý port je používaný v priebehu

celej životnosti TCP spojenia).

Uvedené mechanizmy zaisťujú rozkladanie záťaže tak, ako požiadavky (jednotlivé

spojenia) prichádzajú. Ak si uvedomíme, že v protokole http verzia 1.0 sa pre každú

časť webovej stránky (gif, jpg, tlačidlá na stránke ...) vytvára samostatné TCP spojenia,

potom to v kombinácii s vyššie uvedenými mechanizmami môže spôsobiť, že na

prezretie jednej stránky sú použité všetky servery v skupine.

V prípade, že je nutné zachovať trvalosť spojenie užívateľa na konkrétny server (napr.

pri obchodných portáloch), možno nastaviť aj niektorý zo spôsobov zabezpečujúcich

tzv. persistency-based algorithms. Sú to napr. metódy okamžitej väzby (immediate

binding) ktoré môžu byť založené napríklad na:

kontrolnom súčte (hash);

IP adrese.

Inou možnosťou sú metódy odložených väzieb (ID SSL session, práca s cookie).

Optimálnym spôsobom pre rozkladanie záťaže so zachovaním spojenia pre konkrétneho

užívateľa je kontrola cookie. Algoritmy založené na cookie sú všeobecne tri:

pasívny mód; prepínač kontroluje cookie v http paketoch;

prepisovanie cookie; prepínač prepisuje cookie tak, aby obsahoval špecifické

informácie o serveri;

vkladanie cookie; prepínač vkladá cookie do odpovede serverov klientom

4.2.8 Metóda odložených väzieb (práca s cookie)

Cookies sú všeobecne používaným mechanizmom pre udržiavanie jednoznačnosti

spojenia medzi klientom a serverom. Umožňujú serveru vystaviť pre klienta "odznak",

ktorým sa klient serveru preukazuje pri všetkých nasledujúcich požiadavkách. Serveru

FEI KPI

38

to pri nich umožňuje vynechať znovu overovanie klienta a ďalšie časovo náročné

procesy potvrdzujúce, že ide stále o rovnakého klienta.

V najjednoduchšom prípade môže byť cookie identifikátorom priradeným

užívateľovi (customer ID). Môže to byť znak dôvery, umožňujúce klientovi preskočiť

overovanie ak je jeho cookie platná. Môže to ale byť aj kľúč, ktorý spája stavové dáta

užívateľa, ktoré sú udržiavané na serveri. Tými sú napr nákupný košík a jeho obsah. V

oveľa zložitejších aplikáciách môže byť cookie zašifrované a obsahovať viac dát než

jednoduchý kľúč alebo identifikačné číslo. Cookie môže obsahovať užívateľské voľby

na konkrétnom serveri, čo umožňuje prispôsobiť stránky pre konkrétneho užívateľa.

Mechanizmus používania cookie je definovaný v RFC2109. Hlavička cookie

obsahuje pár "Name" = Value "a ďalšie parametre. Cookies môžu byť trvalé (zostávajú

uskladnené v adresári klientskeho prehliadača) alebo dočasné (sú platné len pre

konkrétnu reláciu). Podľa definície v RFC2109 sú cookie bez dátumu vypršania iba

dočasné. príklad cookie je:

Cookie: ASP_SESSIONID = YTGGFEGHJKO

Cookie: name = john_doe

Prvý príklad predstavuje identifikátor ASP relácie a druhý je cookie určitej

aplikácie zahŕňajúce meno klienta.

Treba zdôrazniť, že algoritmy založené na cookie sú použiteľné iba pre protokol

HTTP. Protokol HTTPS je možné v tomto režime použiť za predpokladu, že HTTPS

spojenie nebude ukončené na serveri, ale na SSL akcelerátory , čo je už však mimo

zamerania tejto práce.

4.2.9 Mechanizmy kontroly dostupnosti reálnych serverov

Používané mechanizmy sú závislé na konkrétnej službe bežiacej na serveroch

(http, radius, ftp ...). V závislosti na tejto službe je možné voliť napríklad medzi týmito

typmi kontroly:

kontrola fyzickej vrstvy - portu, na ktorom je pripojený server; najjednoduchší

spôsob, ale s najhoršou informáciou o skutočnom stave služby;

FEI KPI

39

ICMP echo (ping) - kontrola dostupnosti IP služby, opäť s obmedzenou

informačnou hodnotou;

požiadavky na TCP spojenia (dokončenie 3way handshake a ukončenie spojenia) -

to je kontrola s podstatne lepšou informačnou hodnotou o schopnostiach služby;

kontrola obsahu alebo dostupnosti služby – napr. pre HTTP, POP3, FTP, SMTP,

DNS, NNTP, IMAP, RADIUS ...

4.2.10 Mechanizmy na zaradenie serveru do skupiny po výpadku

SLB prepínač pokračuje v kontrole služby aj na serveroch, ktoré sú aktuálne

nedostupné. Možno konfigurovať po akej dobe od obnovenia dostupnosti má prepínač

zaradiť server do prevádzkového zoznamu a začať ho používať. To má význam najmä

pri kontrole fyzickej vrstvy alebo kontrole pingom (od okamihu, kedy je linka v stave

zapnutá alebo server začne odpovedať na ping, môže do plnej funkčnosti služby

uplynúť pomerne dlhá doba).

4.2.11 Možnosti redundancie v rámci SLB

Z vyššie uvedeného môže vyplývať, že SLB prepínač je jednoduchým bodom

zlyhania systému. Samozrejme ide konfigurovať aj redundantné riešenie postavené na

použití dvoch a viacerých SLB prepínačov. Ich zapojenie potom môže byť napr. podľa

obrázku 5:

FEI KPI

40

Obrázok 5 Redundantné riešenie postavené na použití dvoch SLB prepínačov

K redundanciu je používaná technológia redundancie IP adresy (VRRP). V

závislosti na technológii môže byť záložný prvok v aktívnom stave (tzn. prechádzajú

cez neho dáta) alebo v stave standby (čaká na výpadok primárneho prvku).

Redundancia môže byť na úrovni IP adries pre smerovanie, ale (a to je dôležité) aj

pre virtuálne IP adresy serverov. Pomocou toho je možné zabezpečiť režim Active -

Active, kedy obaja SLB prepínače sú aktívne používané, každý však pre určitú skupinu

virtuálnych serverov.

4.2.12 SLB s cookie pre https

V texte bolo uvedené, že load balancing pomocou cookie je použiteľný len pre http

protokol. Použitie SLB s cookie v prípade protokolu https predpokladá, že https

spojenie nie je ukončené na serveri, ale na tzv. SSL akcelerátory.

SSL akcelerátor je hardvérové zariadenie, ktoré ukončuje SSL spojenie (napr.

https) a prostredníctvom nezabezpečeného protokolu (v danom prípade http)

komunikuje so serverom. Z toho je zrejmé, že v tomto prípade už možno s cookie

pracovať.

FEI KPI

41

Obrázok 6 Topológia zapojenia a priebeh spojenia SSL akcelerátora

Opäť je uvedený pomerne jednoduchý spôsob zapojenia, ktorý môže byť

redundantný. Pre zvýšenie výkonu a redundanciu SSL akcelerácie je možné viac

jednotiek zapojiť do klastra. V rámci klastra sa potom konfigurácia vykonáva na jednej

(master) jednotke. Na ňu sa napr. inštalujú aj certifikáty. SSL akcelerátory je možné

prevádzkovať i bez SLB prepínačov (prínosy potom sú najmä tie, že pre skupinu

serverov sú certifikáty ukladané na jedno miesto - na SSL akcelerátor). Pre niektoré

lokality bez požiadavky na vysoké výkony alebo rozširovanie je použiteľný SLB

prepínač s integrovaným SSL akcelerátorom.

4.2.13 Global Server Load Balancing

Global Server Load Balancing (GSLB), je rozšírenie funkcie na rozkladanie

záťaže medzi serverovými farmami. Dôvodom je zavedenie geografickej distribúcie

serverových fariem v planetárnom rozsahu a zálohovanie serverových fariem.

4.2.14 Geografická distribúcia v rámci GSLB

V planetárnom meradle nemá veľký význam, aby používatelia z Austrálie, Európy

či Japonska, nakupujúci cez portál eBay komunikovali so serverovou farmou v USA a

FEI KPI

42

zaťažovali tak chrbticovú linky Internetu. Namiesto toho sú ich požiadavky

presmerované k najbližšej serverovej farme portálu a záťaž tak prebieha len po

nevyhnutne dlhej trase.

Geografická distribúcia je založená na alokáciu IP adries IANA. Táto alokácia

bohužiaľ nie je optimálna. Preto majú SLB prepínače možnosť vytvoriť vlastnú

tabuľku, pomocou ktorej vykonávajú optimalizáciu.

4.2.15 Zálohovanie serverových fariem v rámci GSLB

Môže sa stať, že niektorá serverová farma je z akéhokoľvek dôvodu nedostupná

(útok, odstávka z dôvodu údržby atď.). V tomto prípade prevádzkovateľovi vznikajú

straty nerealizovaním obchodov, ale v krajnom prípade aj stratou dôvery zákazníkov. Z

tohto dôvodu je vhodné mať záložnú serverovú farmu (farmy) na inom mieste.

4.2.16 Princíp fungovania GSLB

GSLB je rozšírením funkčnosti SLB o niekoľko funkcií:

kontrola stavu ostatných fariem;

zavedenie autoritatívneho name servera na SLB prepínačoch;

presmerovanie záznamu z DNS serverov domény na SLB prepínače.

SLB prepínač v každej farme vykonáva kontrolu dostupnosti a výkonnosti lokálnych

serverov a informuje pomocou špeciálneho protokolu ostatné SLB servery v GSLB

skupine. Každý SLB prepínač v GSLB skupine má rovnakú informáciu o výkone a

dostupnosti jednotlivých fariem. Na základe konfigurovateľných parametrov potom

vracia informáciu o konkrétnom virtuálnom serveri, s ktorým by mal konkrétny klient

komunikovať.

Pri zavedení GSLB je potrebné:

na všetkých zúčastnených SLB prepínačoch nastaviť:

väzby na SLB prepínače v GSLB skupine;

záznam domény, mená a príslušnú IP adresy (lokálne virtuálne adresa);

FEI KPI

43

na doménových serveroch domény je potrebné nastaviť informáciu, že name

serverom pre dané mená sú SLB prepínače.

A teraz si spojíme informácie o stave dostupnosti služieb v jednotlivých farmách a

DNS záznamov.

klient pošle DNS požiadavka na www.google.com;

po sérii otázok a presmerovania sa požiadavka dostane až na prepínač v

konkrétnej GSLB lokalite;

prepínač vyhodnotí zemepisné hľadisko vrátane stavu serverových fariem a

odošle DNS odpoveď; tá obsahuje zoznam IP adries a hodnotu TTL;

klient otvorí TCP spojenia na odovzdanú IP adresu.

Technológiu GSLB je možné používať pre rozkladanie záťaže medzi viac serverových

fariem, ale pri vhodnom nastavení metrík aj pre zabezpečenie tzv. failover redundancie,

keď za normálneho stavu je v prevádzke len jedna farma a druhá je záložná, používaná

sa len v prípade nedostupnosti prvej farmy.

FEI KPI

44

5 Meranie efektivity cloud computingu

Vo svete cloud computingu, každá akcia niečo stojí. Každá http požiadavka spustí

reťazec udalostí, ktoré spotrebujú isté množstvo zdrojov a teda v konečnom dôsledku sú

nejako spoplatnené. Časy keď boli zdroje na serveroch nevyužívané sú už preč.

V aktuálnom období sú služby ponúkané v cloude spoplatňované za každý kúsok

spotrebovaných zdrojov (výpočtový čas cpu, zabratá RAM, zabratý úložný priestor

atď.) a teda zameranie sa na efektivitu a úspornosť je dôležitejšie ako inokedy. Je teda

nutné minimalizovať náklady ale zároveň udržať dostatočnú kvalitu a dostupnosť

ponúkaných služieb.

V tom najjednoduchšom ponímaní je cloud computing z pohľadu efektivity

a nákladov istý počet spotrebovaných zdrojov a to hlavne procesorového času, zabratie

pamäte RAM, zabratie úložného diskového priestoru a spotrebovanie sieťových

zdrojov. Pri cloud computingu sú tieto merania spotrebovaných zdrojov pomerne presné

a merajú sa všetky procesy a ich závislé systémové API. Neefektívne programy,

procesy, knižnice teda spôsobujú merateľnú spotrebu naviac, ktorá zvyšuje cenu. Je teda

nutné používať stabilné, prípadne vyladené verzie programov a aplikácií aby sa ušetrilo.

Je dokonca možné zaviesť kritérium efektivity ako kritérium pri výbere softwaru.

Napríklad Google App Engine meria každú http metódu, rozlišuje medzi databázovými

požiadavkami na zobrazenie a na uloženie/zmenu dát, dokonca meria systémovú cenu

každej e-mailovej správy. Štatistika vyťaženia cloud systému na isté obdobie (napr. 1

deň v prípade Google App Engine), resp. konkrétne povolené limity zo strany

poskytovateľa cloud služby môžu vyzerať napr. takto:

Komodita Povolený limit

Manažment požiadavok

CPU čas 6:30

HTTP požiadavky 1333328

Odchádzajúca komunikácia 1GB

Prichádzajúca komunikácia 1GB

HTTPS požiadavky 1333328

Zabezpečená odchádzajúca komunikácia 1GB

Zabezpečená prichádzajúca komunikácia 1GB

FEI KPI

45

Databázy

Databázové požiadavky 10368000

CPU čas databázového servera 62:07

Veľkosť databázy 1GB

Uloženie/Zmena dát 12GB

Výber dát 116GB

Memcache

Volania 8640000

add, set 10GB

fetch 50GB

Email

V rámci Google 5000

Mimo Google 2000

Veľkosť tela správy 61,4MB

Počet príloh 2000

Veľkosť prílohy 102MB

Externé požiadavky

HTTP požiadavky 657084

POST, PUT 4GB

GET 4GB

Dynamické obrázky

Transformácie 2592000

Zdrojové obrázky 1GB

Manipulácie 5GB

Tabuľka 2 Jednotlivé limity cloudu

Vyššie spomenuté hodnoty sú platné len za určitých podmienok, nie sú uvedené

všetky hodnoty a samozrejme všetko závisí od konkrétnych zmluvných podmienok.

FEI KPI

46

Výhodou takéhoto presného merania v cloud systémoch je, že ak nevyčerpáte nejaký

limit, resp. ušetríte na niektorej komodite automaticky sa znižuje cena, ktorú platíte

a tým pádom môžete ušetrené prostriedky investovať do iných komodít prípadne na

niečo iné.

5.1 Aplikácie pre cloud a ich štruktúra

Špecializovaný cloud stack, teda štruktúra cloud systémov, odhaľuje neefektivity v

aplikáciách oveľa výraznejšie ako bežné lokálne (desktopové) aplikácie prípadné

aplikácie, ktoré bežia na dedikovanom hostingu. Programátori, ktorí sú si vedomí a

dobre poznajú charakteristiky virtuálnych serverov a ich funkcie dokážu napísať pre

tieto virtuálne servery efektívnejší kód. Príkladom sú Java programátori, ktorí sú

zvyknutí písať aplikácie pre zariadenia s obmedzenými prostriedkami a teda pri písaní

aplikácií pre cloud sú s takýmto konceptom úspory prostriedkov oboznámení. Zároveň

ak sa programátor naučí písať optimalizované a efektívne aplikácie pre cloud tieto

vedomosti a skúsenosti zužitkuje aj pri programovaní aplikácií mimo cloud.

5.2 Meranie efektívnosti aplikácií v cloud computingu

Je všeobecne známe, že veľa domácich elektronických zariadení má

štandardizované hodnotenie energetickej úspornosti resp. efektivity označované ako

Energy Star. Podobné hodnotenie sa zavádza aj v rámci hardwarového vybavenia

jednotlivých výrobcov. Takéto hodnotenie nám umožňuje priamo porovnávať

energetickú efektivitu jednotlivých zariadení. Podobné hodnotenie je možné aplikovať

aj na softvér inštalovaný na cloud systémoch, prípadne na knižnice a podporné rutiny na

ktorých softvér závisí. Takéto hodnotenie by umožňovalo záujemcom o softvér

zohľadniť aj efektivity programu a podľa toho si vybrať softvér, ktorý im najviac

vyhovuje. Zároveň to motivuje autorov softvéru vyvíjať efektívne programy, aby uspeli

v boji proti konkurencii. Google, Microsoft a Amazon prenajímajú svoje výpočtové

farmy a reklamné platformy aby získali naspäť počiatočné investície. Reklamné

platformy ponúkajú zľavy pre zákazníkov, ktorí vyrábajú zisk v rámci tej istej

spoločnosti, resp. ktorí majú prevádzkovanie svojho systému v rámci tej istej

FEI KPI

47

spoločnosti, pretože požiadavky na takýto systém nemusia opustiť internú sieťovú

infraštruktúru danej spoločnosti. Pri meraní efektivity cloud systému sa však

nezohľadňujú len prevádzkové náklady, ale aj náklady na nasadenie, údržbu,

zabezpečenie a podobne. Medzi tieto jednotlivé hodnoty patria aj:

Čas na nasadenie

Hustota

Možnosť rozšírenia (Elasticita)

Stabilita (Zabezpečenie a Izolácia)

Prevádzkový výkon

Čas na vývoj

Dostupnosť

Čas na nasadenie:

Táto hodnotu zaujíma hlavne vývojárov. Je to čas na nasadenie riešenia do

funkčného stavu tak, že je pripravené na produkčný chod. Toto zahŕňa proces od

inštalácie OS až po sprevádzkovanie samotného softvéru. Čím je tento proces zložitejší

a zdĺhavejší, tým je efektivita systému a taktiež produktivita vývojárov nižšia.

Hustota:

Táto hodnota zaujíma hlavne CIO/CTO (hlavný manažér informácií/technológií)

a manažment prevádzky. Táto metrika sa môže aplikovať na rôzne objekty, napríklad na

počet virtuálnych strojov (operačných systémov) prevádzkovaných na jednom fyzickom

serveri, počet procesov v rámci jedného virtuálneho stroja, počet užívateľov na

aplikáciu a podobne. Poskytovatelia cloud riešení sa o túto hodnotu zaujímajú tiež,

pretože môže naznačiť akú hodnotu môžu získať z daných IT prostriedkov.

Možnosť rozšírenia (Elasticita):

Táto hodnota zaujíma hlavne majiteľov, poskytovateľov cloud riešení a

manažment prevádzky. Táto hodnota udáva ako rýchlo (a ako komplikovane) je možné

pridať do už bežiaceho systému ďalšie zdroje naviac aby sa tak navŕšila celková

kapacita zdrojov. Majitelia sponzorujú vývoj aplikácií a zároveň platia poplatky za

FEI KPI

48

prevádzkovanie u poskytovateľov. Preto požadujú aby bola aplikácia dostupná a aby

bolo možné ju prispôsobiť počtu užívateľov. Poskytovatelia služieb zasa túto hodnotu

používajú ako ukážku ich skvelej infraštruktúry a služieb.

Stabilita (Zabezpečenie a Izolácia):

Táto hodnota zaujíma každého v reťazci cloud systémov. Táto hodnota je takmer

vždy istým kompromisom podľa konkrétneho systému. Prakticky sa je nutné

rozhodnúť, či sa budú prevádzkovať robustné zdieľané virtuálne stroje pre mnoho

užívateľov, ktoré však so sebou nesú vyššie bezpečnostné riziko alebo naopak sa budú

prevádzkovať mnoho menších virtuálnych strojov, ktoré budú navzájom iba nepriamo

previazané. Univerzálna odpoveď pri tejto otázke neexistuje. V tejto otázke sa vždy

zvolí kompromis medzi spoľahlivosťou, bezpečnosťou a výkonom.

Prevádzkový výkon:

Táto hodnota už bola rozobraná skôr v texte, ale v jednoduchosti sa jedná

o optimalizáciu aplikácií a architektúry pre daný účel. Problémom je zvoliť si kľúčové

body, ktoré sú najdôležitejšie a tie optimalizovať čo najviac.

Čas na vývoj:

Táto hodnota predstavuje kompletný čas na vývoj, nasadenie, údržbu, a rozšírenie

kompletného systému.

Dostupnosť:

Táto hodnota bola už širšie rozobraná v predchádzajúcich textoch.

5.3 Nástroje pre meranie efektivity a výkonu Cloudu

CloudSleuth Cloud Performance Analyzer:

CloudSleuth Cloud Performance Analyzer je systém na meranie efektivity

a výkonu cloud služieb. Tento systém sa viac zameriava na cloud aplikácie ako na iné

aspekty a komponenty cloud služieb. Moderné aplikácie, a pri cloud aplikáciách to platí

ešte viac, už zďaleka nie sú iba záležitosťou lokálneho počítača, ale na prácu používaju

vzdialené databázy, úložiská dát, kontroléry, konfiguračné servery, server

FEI KPI

49

bezpečnostných pravidiel a podobne. Klasické merania efektivity a výkonu sú predsa

v takomto prípade už nevhodné a môžu byť zavádzajúce. Takéto aplikácie sa nazývajú

„border-less“, teda bez hraníc. To znamená, že využívajú aj zdroje, ktoré sú umiestnené

mimo správy vlastníka (prevádzkovateľa) týchto aplikácií. V takomto prípade stačí, že

čo i len jeden z týchto zdrojov nie je dostupný, alebo má vysoké hodnoty odozvy

a môže to znefunkčniť celú aplikáciu. Preto je ešte viac potrebné podrobné testovanie aj

pri vysokých záťažiach. V prípade aj najjednoduchšej cloud aplikácie sa musí testovať

napríklad aj:

Statický obsah (text, obrázky, ...)

Dynamický obsah (napr. mapy)

Reklamný systém

Analytický a štatistický systém (štatistiky návštevnosti, klikania, štatistiky

prehliadačov, ...)

Servery poskytovateľa a ich odozva a priradený výkon

Sieťová infraštruktúra medzi zdrojom a cieľom

A podobne

Cloud Sleuth na testovanie používa viacero metodík napr.:

Gomez Last Mile Peers (viacero klasických klientov)

Gomez Active Backbone Nodes (vysokovýkonné uzly, ktoré vygenerujú veľkú

záťaž)

Gestalt World View (testovanie pomocou centier umiestnených po celom svete)

(Regional) End-User (testovanie iba z hľadiska jedného klienta)

Širšiu problematiku testovania cloud aplikácií a metódy testovania je možné získať

v dokumentácii výrobcu.

CloudHarmony:

CloudHarmony ponúka testovanie cloudu na rôznych úrovniach. Testovanie

prebieha na objednávku v prípade ak chce zákazník zmerať efektivitu a výkon svojho

riešenia, no CloudHarmony taktiež pravidelne nezávisle testuje aj riešenia najväčších

poskytovateľov cloud produktov, a tieto výsledky potom zverejňuje na svojej webovej

stránke. Je tak pomerne jednoduché si urobiť obraz o tom aké výsledky majú

FEI KPI

50

poskytovatelia služieb a vybrať si toho najvhodnejšieho. CloudHarmony testuje cloud

služby na 3 hlavných úrovniach a to z hľadiska výkonu, siete a dostupnosti.

Hľadisko výkonu je jednoducho povedané ako rýchlo sa dáta spracúvajú. Merajú

sa charakteristiky ako výkon CPU, diskové operácie, zabratá pamäť a podobne. Taktiež

sa testuje aj škálovanie zo strany spokytovateľa. Pri testovaní sa používajú syntetické aj

reálne testy ako Unixbench, Iozone, SPECjvm2008 a podobne.

Hľadisko sieťové, hovorí o odozve jednotlivých cloud služieb, priepustnosti,

prenosovej rýchlosti a šírke pásma atď., a to ako v rámci cloud infraštruktúry ako aj až

po koncového konzumenta služby. Na testovanie sa používajú serverové minifarmy po

celom svete, čím sa dosiahne celosvetový priemer výsledkov.

Hľadisko dostupnosti jednoducho hovorí aká je priemerná dostupnosť cloud

služby a aké dlhé a aké časté sú výpadky, či už plánované alebo neplánované.

CloudStone:

CloudStone je multi-platformový nástroj na testovanie Web 2.0 a Cloud

Computingu. Cieľom projektu je vytvoriť benchmark (test), ktorý by dokázal

produkovať opakovateľné a konzistentné výsledky. Pomocou tohto nástroja by bolo

možné nahliadnuť do fungovania služby a prípadne navrhnúť spôsoby optimalizácie.

Výsledky sa dosahujú pomocou flexibilného generátora záťaže, ktorý simuluje reálne

požiadavky. Architektúru CloudStone je možné rozdeliť na tri komponenty:

Webová aplikácia

Databáza

Generátor záťaže

CloudCmp:

CloudCmp je nástroj na porovnávanie jednotlivých poskytovateľov cloud služieb.

Primárne sa tento nástroj zameriava na poskytovateľov hostingových (prevádzkových)

služieb. Projekt je zatiaľ vo fáze vývoja. Na projekte sa podieľajú výskumníci z Duke-

ovej univerzity a z výskumného centra Microsoftu.

CloudCmp funguje v 2 krokoch:

FEI KPI

51

Použitím štandardných nástrojov na meranie výkonu a efektivity ponúkaných

cloud služieb jednotlivých poskytovateľov, zahŕňajúc výpočtový výkon, úložný

priestor a sieťové služby.

Použitím výsledkov týchto testov na odhad efektivity a výkonu v prípade

nasadenia danej aplikácie na jednotlivých poskytovateľov cloud služieb.

FEI KPI

52

6 Správa životného cyklu služby v Cloude

6.1 Služby v cloude

Prostriedky IT každej organizácie zahŕňajú dáta, prevádzkované systémy, rôzne

druhy

špecializovaných aplikácií a informácie o obchodných partneroch. Všetky tieto zdroje

vystupujú ako služby (SOA – Service Oriented Architecture) produkujúce celú škálu

výstupných dát. Servisná architektúra zoskupuje tieto odlišné zdroje informácií spolu s

operačnými systémami, technológiami a komunikačnými protokolmi. Toto

zoskupovanie prebieha iteratívne v troch krokoch:

Vytvorenie (dizajn a vývoj)

Testovanie

Kompozícia

Konzumácia

Údržba

Najprv sú vytvorené nové služby (vytvorenie), potom sú tieto služby

zakomponované do väčších aplikácií (kompozícia) a nakoniec sú výstupy služieb

odovzdané na spracovanie koncovým užívateľom (konzumácia).

6.1.1 Vytvorenie služby v cloude

V prvej fáze je potrebné navrhnúť, aké služby je potrebné vytvoriť nad

existujúcimi aplikáciami a dátami. Návrh týchto služieb môže byť ako jemnozrnný (1

služba = 1 business proces), tak hrubozrnný (viac služieb zodpovedá určitej skupine

podnikových funkcií). V tejto fáze je potrebné zvážiť ich implementáciu - buď priamo

pomocou webových aplikácií, alebo nepriamo pomocou nejakého rozhrania.

6.1.2 Testovanie služby v cloude

Kvalitatívne atribúty cloud služby sú otestované počas tejto fázy. Počas tejto fázy

sa testuje ako na strane programátora tak na strane poskytovateľa. Úlohou testovania je

FEI KPI

53

zabezpečiť kvalitu a dohodnuté atribúty od jedného konca ku druhému, zabezpečiť, že

služba pobeží u poskytovateľa cloud hostingu a taktiež odhaliť prípadné chyby.

6.1.3 Kompozícia služby v cloude

Po vytvorení jednotlivých služieb je ich možné skombinovať do väčších celkov. Vďaka

tomu, že sú tieto služby na sebe i na platforme nezávislé, je možné ich navzájom

kombinovať a znovu používať s maximálnou flexibilitou. Súčasne pri ďalšom vývoji

business aplikácií je možné ich ľahko upravovať bez obmedzenia, vyplývajúce z

existujúcich aplikácií a systémov.

6.1.4 Konzumácia služby v cloude

Ako náhle sú nové aplikácie alebo business procesy vytvorené, ich funkcionalita

musí byť poskytnutá pre iné IT systémy a koncovým užívateľov. Cieľom tohto procesu

je dodať nové dynamické aplikácie, ktoré umožnia zvýšenie produktivity a lepšiu

možnosť nazerať do fungovania a výkonnosti biznisu. Užívatelia môžu tieto služby

využívať mnohými spôsobmi vrátane webových portálov, kancelárskych aplikácií,

mobilných zariadení a pod. Jedná o hľadanie ciest, ako za pomoci najmodernejších

technológií zabezpečiť uspokojovanie nových potrieb a požiadaviek neustále sa

meniaceho trhu.

Termíny SOA a webové služby bývajú často zamieňané. Hoci s pomocou

webových služieb sa implementácie SOA stáva jednoduchšie, tieto termíny nemožno

voľne zamieňať. SOA je spôsob navrhovania systémov, zatiaľ čo webové služby sú

implementačné technológie, ktoré používajú špecifické štandardy a protokoly k

dosiahnutiu riešenia založeného na princípoch SOA.

6.1.5 Údržba služby v cloude

Každá služba, ktorá sa nachádzala na uzle, ktorý je z nejakej príčiny nefunkčný je

samozrejme nedostupná. Riešením je buď záložný uzol, pokus o automatickú opravu

uzla alebo migrácia služby na iný uzol alebo kombinácia týchto spomenutých. Toto

všetko sa deje automaticky a čo najrýchlejšie. Patrí tu aj pridávanie nových zdrojov

FEI KPI

54

a ich zahrnutie do už fungujúcej architektúry bez obmedzenia prevádzky alebo

dostupnosti služby.

6.2 Správa životného cyklu pomocou Vmware Lifecycle

Manager

V prípade riešenia Vmware má správu životného cyklu na starosti VMware

Lifecycle Manager. Produkt zabezpečuje ucelenú kontrolu naprieč virtuálnym

prostredím celej IT infraštruktúry - ukazuje totiž vlastníka virtuálneho stroja, kedy bolo

o pridelenie virtuálneho stroja požiadané, kto k tomu udelil súhlas, kde bol virtuálny

stroj nasadený, ako dlho bol v prevádzke a na kedy je naplánované jeho odstavenie .

Vďaka produktu VMware Lifecycle Manager môžu vedúci IT oddelenia okrem iného

merať a spätne účtovať využívanie virtuálnych strojov príslušným oddeleniam alebo

úsekom v spoločnosti. Na základe automatizácie a riadenia celého životného cyklu

virtuálnych strojov odpadá potreba ručne opakovať úkony, kvôli ktorým sú do systému

často zanášanie chyby. Ďalšou výhodou pre podniky je možnosť striktného

dodržiavania stanovených zásad a štandardov v oblasti IT.

Virtuálne stroje VMware zapuzdrujú aplikácie a operačné systémy vo forme

prenosných "kontajnerov" s jednoduchou správou, vďaka ktorým sa výrazne zvyšuje

miera zabezpečenia, dostupnosti i výkonnosti, a to na úrovni aplikácií aj samotného

operačného systému. Virtuálne stroje sú pre svoju prenositeľnosť a jednoduchú správu

ideálnym riešením pre zvládnutie a automatizáciu procesov IT, ako je napríklad

poskytovanie služieb. Stále viac firiem stavia na štandardoch VMware Infrastructure a

nasadzuje virtuálne stroje ako najlepšie riešenie na prevádzkovanie aplikácií,

zabezpečenie dát, zabezpečenie kontinuity prevádzky aj zníženie spotreby energie. Na

zvládnutie stále rastúceho počtu virtuálnych strojov firmy preto potrebujú účinné

nástroje na manažment životného cyklu. VMware Lifecycle Manager umožňuje

podnikom implementovať konzistentné a automatické procesy zahŕňajúce zadávanie

požiadaviek, schvaľovanie, implementáciu, aktualizáciu a vyraďovanie virtuálnych

strojov.

Základné charakteristiky:

Vytváranie katalógov štandardných služieb IT. Užívatelia si môžu vyberať z

vopred danej ponuky virtuálnych strojov líšiacich sa napríklad veľkosťou pamäte alebo

FEI KPI

55

rýchlosti procesora. Vďaka tejto štandardizácii môžu správcovia infraštruktúry lepšie

udržať kontrolu nad celým prostredím IT, a minimalizovať tak možné riziká.

Racionalizácia požiadaviek a schvaľovania. VMware Lifecycle Manager zavádza

konzistentné a výkonovo prispôsobiteľný mechanizmus pre smerovanie a schvaľovanie

všetkých požiadaviek na virtuálne stroje so zárukou dodržiavania interných zásad

spoločnosti.

Sledovanie a kontrola nad virtuálnymi strojmi. VMware Lifecycle Manager

ponúka intuitívne webové rozhranie pre sledovanie jednotlivých prípadov nasadenie

virtuálnych strojov, a tak správca IT môže ľahko zistiť, kedy presne bol na virtuálny

stroj vznesená požiadavka, kedy bol takáto požiadavka schválený alebo zamietnutý,

kedy a kde boli virtuálne stroje nasadené, prípadne ako dlho boli v prevádzke.

Vylúčenie ručne vykonávaných úloh, ktoré sa často opakujú a vnášajú do systému

chyby. Virtuálne prostredie sa neustále rozširujú, a tak je pre oddelenie IT dôležité

činnosti automatizovať, aby dokázala viac, zato s menšími prostriedkami. VMware

Lifecycle Manager automatizuje všetky kroky životného cyklu virtuálnych strojov na

základe vopred definovaných zásad.

Priraďovanie metrík pre účtovanie virtualizácie. VMware Lifecycle Manager

umožňuje, aby pracovníci IT do všetkých metriky účtovanie ku konkrétnym inštaláciám

virtuálnych strojov alebo fondom dynamicky prideľovaných virtuálnych prostriedkov.

Takéto metriky účtovanie možné priradiť konkrétnym skupinám používateľov vo firme

a previazať ich s existujúcimi finančnými systémami.

Integrácia s existujúcimi nástrojmi pre správu. VMware Lifecycle Manager

poskytuje aplikačné programové rozhranie pre integráciu s ďalšími nástrojmi IT, ako sú

napríklad systémy pre správu riešení porúch (tzv. "trouble ticketing"), riadenie zmien

alebo správa aktív.

FEI KPI

56

7 Analýza princípov Configuration-driven architektúry

Configuration-driven architektúra je založená na základnom predpoklade, že

„nový systém musí robiť to, čo teraz robí starý“. Takýto prístup sa používa v prípade

keď jednoducho potrebujeme novú verziu systému, pretože stará verzia sa blíži koncu

životnosti, alebo používa nejakú komponentu, ktorá sa blíži koncu životnosti. Najlepšie

je začať s tým, čo už je známe o starom systéme a od tohto základu sa odraziť. V

takomto prípade sa vytvárajú konfiguračné súbory, od ktorých sa odvádza ďalší návrh

systému. Systém je tak závislý na konfiguračných súboroch, no zároveň sa zmena v

konfiguračnom súbore automaticky prenáša do celého systému. Takýmto ošetrením sa

redukuje alebo dokonca eliminuje možnosť duplicít a zjednodušuje sa prípadné ďalšie

rozširovanie programu. Nevýhodou je, že takéto konfiguračné súbory, môžu často

naberať na objeme v počte záznamov, s čím neskôr súvisí ich neprehľadnosť. Práve

preto je dôležité takéto súbory dobre organizovať a rozširovať ich podľa potreby, no

vždy podľa dopredu stanovených pravidiel. Je preto nutné si ešte na začiatku projektu

zvoliť stratégiu rozširovania systému. Nevýhodami takéhoto prístupu môže byť aj

limitovanosť konfiguračnými súbormi, v špecifických prípadoch, keď iný štýl prístupu

by bol vhodnejší. Takýmto spôsobom ale je možné dosiahnuť veľkú univerzálnosť

systému, keďže sa nespolieha na vnútorne nastavené hodnoty, ale na hodnoty, ktoré su v

konfiguračných súboroch. Veľkou výhodou je aj prenositeľnosť, keďže na identické

nastavenie systému stačí preniesť konfiguračné súbory.

FEI KPI

57

8 Zabezpečenie cloud služieb v cloud computingu

8.1 Bezpečnostné slabiny cloud computingu

Rovnako ako v iných výpočtových modeloch je vhodné sa aj pri zabezpečení

cloud computingu spoľahnúť predovšetkým na svoj zdravý úsudok. V niektorých

prípadoch možno tiež odporučiť určité osvedčené postupy. Myšlienka cloud

computingu navrhnutého okolo architektúry, ktorej prirodzený stav je zdieľaný priestor

mimo podniku získala v poslednom období obľubu ako spôsob znižovania nákladov a

zlepšenie flexibility IT. Použitie cloud computingu však so sebou tiež prináša

bezpečnostné riziká, vrátane nebezpečenstva súvisiaceho s nedodržaním zákonov,

dostupnosťou a integritou dát. Veľa spoločností si tieto riziká doteraz dopredu

nepremyslí.

Napríklad použitie vhodnej technológie pre zvýšenie odolnosti proti zlyhaniu (failover)

je často zanedbávanou súčasťou zabezpečenie cloudu. Pritom rovnaké spoločnosti sa

starostlivo zaisťujú proti výpadku iných kľúčových služieb, ako je napríklad dodávka

elektriny. V niektorých prípadoch je riziko príliš vysoké na to, aby bolo možné sa

spoliehať na cloud. V prípade, že je rozhodnuté o presune niektorých služieb a aplikácií

do cloudu, musia sa firmy pýtať na spôsob správy rizík.

Zavádzanie limitov pre technológiu cloud computingu predstavuje len jeden z

problémov, ktoré musia spoločnosti dôkladne preskúmať a porovnať riziká voči tomu,

kedy a kde môže byť cloud computing efektívny. Napríklad ak sa vzdajú určitej

kontroly nad dátami, môžu výmenou získať hospodárnejšie náklady. Oddelenie IT s

ďalšími vrcholovými manažérmi však musí rozhodnúť, či za to táto výmena stojí. V

podstate čokoľvek môže byť dnes dostupné formou služby cloud computnigu, ale v

žiadnom podniku nebude z cloudu prístupné všetko. V zdieľanom priestore mimo

podniku neexistuje exaktná kontrola nad tým, kde sa prostriedky nachádzajú. Ak teda

napríklad sú obavy o umiestnení dát, môže to byť dôvod túto technológiu nepoužiť.

Existuje veľká skupina štandardov, vrátane služieb ako napríklad SAS Interaction

Management, ktoré sa týkajú zabezpečenia IT a dodržiavanie smerníc. Sú rozhodujúce

pre väčšinu odborových interakcií, ktoré časom budú musieť byť prevedené pre potreby

cloud computingu. Ale medzitým, kým sa neobjavia pre architektúru cloud computingu

štandardy a modely zabezpečenia, väčšina rizík a zodpovednosti v prípade, že sa niečo

pokazí, padá priamo na plecia oddelenia IT a nie na konkrétneho poskytovateľa služieb

FEI KPI

58

cloud computingu. Takéto riešenie zo strany poskytovateľov neponúka druh

mechanizmov pre riadenie, obmedzenie rizík a dodržiavanie smerníc, ktoré sú

vyžadované legislatívou.

V prípade činností firmy sa rozlišuje medzi základnými (core) a kontextovými

(context) činnosťami. Základné firemné činnosti predstavujú konkurenčnú odlišnosť.

Tie kontextové naopak znamenajú tie firemné aktivity, ktoré sa týkajú interných aktív,

ako napríklad služby personálneho oddelenia či mzdové riešenie. Základné aj

kontextové však možno rozdeliť na dôležité a nedôležité činnosti. Ak nastane výpadok

tej nedôležitej, môže spoločnosť aj naďalej fungovať. Ak sa teda jedná o kontextovú

činnosť, ktorá zároveň nie je pre podnik kriticky dôležitá, možno ju vždy zabezpečiť

pomocou cloud computingu. Ak ide o kontextový výkon, ktorý je pre podnik dôležitý,

je pravdepodobné, že by ho bolo možné zaistiť a zabezpečiť prostredníctvom cloud

computingu ale nemusí to byť vždy možné alebo vhodné. Ak ide však o základnú

činnosť, tak aj keď nie je hlavná, je vhodné veľmi dobre premyslieť, či ju predsa len

neponechať vo vnútri za firemným firewallom. Ak je základná a dôležitá, potom by

mala zostať vnútri za firewallom v každom prípade.

Použitie cloud computingu nezodpovedá svojou prirodzenou povahou návrhu dobrého

zabezpečenia. Oblasťou, ktorá je najviac znepokojujúca, je rýchlosť aktualizácie a

zmien služieb založených na cloud computingu. Niektoré postupy životného cyklu

konvenčných aplikácii a služieb sú navrhnuté tak, že u dôležitého softvéru

predpokladajú periódy troch až piatich rokov, počas ktorých by nemalo dochádzať k

významným zmenám. V cloud computingu sa pridávajú nové funkcie aj každé dva

týždne a aplikácie sa neustále menia. Bezpečnosť, ktorú definujú tieto postupy pre

konvenčné služby, k tomu teda nie sú vôbec určené. Nastáva teda éra keď sú nové

funkcie vydávané skutočne rýchlo, pričom nikto nemá nastavený cyklus zabezpečenia,

ktorý by bol tak flexibilný a rýchly aby stíhal takéto tempo. Situáciu ešte viac zhoršuje

fakt, že podnikoví používatelia nemôžu povedať, že chcú zostať pri starej verzii. V

cloud computingu sa musí prijať ďalšia verzia, bez toho aby bolo na výber, a možnosť

si ponechať akéhokoľvek zabezpečenie, ktoré bolo v pôvodnej verzii aplikácie

obsiahnuté alebo bolo implementované na strane zákazníka ako interné riešenie.

V krátkom čase, tam, kde je zabezpečenie veľmi dôležité (teda najvýznamnejšie

podniky, finančné inštitúcie či vládne organizácie), budú musieť informačné

technológie pridať svoju vlastnú vrstvu zabezpečenia. To znamená, že cloud computing

nebude pre tieto subjekty lacnejší ako interná prevádzka príslušnej aplikácie. Za

FEI KPI

59

niekoľko rokov bude vytvorená vrstva silného zabezpečenia a ochrana bude dostatočne

zrelá na všetky účely, teda možno s výnimkou špeciálnych prípadov keď interné

riešenie je jediné možné. Hoci veľké podniky zatiaľ nemôžu spoliehať na zabezpečenie

implementované priamo v cloud computingu, malé spoločnosti môžu vďaka cloud

computingu získať lepšiu ochranu. Jedným z dôvodov je to, že poskytovateľ cloud

computingu môže do bezpečnosti investovať viac než ktorákoľvek malá firma, lebo

náklady sa rozložia medzi väčšie množstvo zákazníkov. Ďalším dôvodom je potom to,

že akonáhle poskytovateľ cloud computingu opraví nejakú chybu v zabezpečení, sú

okamžite chránení všetci zákazníci, na rozdiel od situácie, keď IT pracovníci musia

stiahnuť a inštalovať opravné balíčky manuálne a urobia tak iba na svojej aplikácii

alebo službe.

Ďalším problémom, ktorý sa dotýka veľkých i malých zákazníkov je umiestnenie

klientskych. To je obzvlášť dôležité pre spoločnosti, ktoré podnikajú v medzinárodnom

meradle, pretože v rôznych krajinách platia rozličné zákony pre ochranu osobných

údajov a správu dát. Napríklad Európska únia stanovila prísne obmedzenia pre

informácie, ktoré môžu byť o jej občanoch ukladané. To sa týka aj doby povoleného

ukladania. Mnoho orgánov na dohľad, ktoré sú súčasťou bánk zasa vyžaduje, aby

finančné dáta zákazníkov zostali v ich domovskej krajine. Mnoho ďalších predpisov tiež

vyžaduje, aby určité citlivé informácie neboli premiešané s ostatnými dátami, napríklad

na zdieľaných serveroch či v databázach aby v prípade útoku na takýto zdieľaný systém

nebola ohrozená dôvernosť týchto dát. V cloud computingu je veľmi ťažké vedieť kde

sú dáta vlastne uložené. Táto skutočnosť potom prináša všetky druhy problémov pri

dodržiavaní smerníc ohľadom súkromia dát, ich segregácie a zabezpečenia. Táto

neurčitosť umiestnenia sa však začína meniť. Spoločnosť Google napríklad dovoľuje

zákazníkom určiť, kde sú uložené dáta aplikácií Google Apps. Švajčiarska banka zase

napríklad chce, aby súbory informácií jej zákazníkov zostali uložené vo Švajčiarsku

a neboli uložené v inej krajine. Dôležitou oblasťou je schopnosť fyzicky oddeliť dáta

jednej organizácie od informácií iných zákazníkov v architektúre cloud computingu.

Predpovedá sa však, že táto separácia bude možná vďaka rozvíjajúcej sa a stále

schopnejšej technológii virtualizácie, ktorá začína zohľadňovať aj predtým prehliadané

požiadavky.

Je všeobecne prijímané, že nezávisle od prísnosti zmlúv SLA (zmluvy o úrovni kvality

poskytovaných služieb) dodávateľov či sile použitej bezpečnostnej technológie závisí

zníženie rizika v akomkoľvek prostredí na snahe konkrétnej spoločnosti preverovať

FEI KPI

60

funkčnosť zabezpečenia. Je preto potrebné mať istú dávku paranoje a preverovať aj

poskytovateľa cloud služieb a hostingu.

8.2 Dôležité kritéria bezpečnosti cloud computingu

A ak máme hovoriť o rizikách, ktoré na nás v cloude číhajú, musíme vykonať

analýzu rizík. A začať by sme mali ako inak než identifikáciou a kvantifikáciou

komodít. V tomto prípade budeme za komodity považovať dáta, ktoré klient

poskytovateľovi cloudu zveruje. V tomto prípade sa za tri najdôležitejšie kritéria

považujú:

Dostupnosť

Dôvernosť

Integrita

8.2.1 Dostupnosť ako kritérium bezpečnosti cloud computingu

Pre business procesy dostupnosť dát je zvyčajne kritická. Cloud poskytovateľ však

nemôže dostupnosť dát uložených v cloude sto percentne garantovať, pretože prístup k

dátam je realizovaný cez internet, ktorý nie je pod jeho správou. Je možné zaistiť, že

kvôli rýchlej odozve je žiaduce, aby bol cloud relatívne blízko k užívateľom. Bohužiaľ

v prípade globálneho riešenia je potrebné mať potom geograficky rozložené zrkadlené

farmy aby bolo riešenie relatívne blízko k užívateľom z celého sveta. Tiež dostupnosť

sieťovej infraštruktúry je v najrôznejších krajinách sveta rôzna, takže je dosť podstatné,

kde sa poskytovateľ, ktorému sú zverené svoje dáta, nachádza. Je teda možné, že

lokálna situácia ako prírodné katastrofy, porucha dôležitej linky a podobne, môže

ovplyvniť váš systém.

8.2.2 Konfidentalita ako kritérium bezpečnosti cloud computingu

Keď svoje dáta umiestnite do cloudu, tak k nim poskytovateľ síce získa prístup, ale

bývajú to rovnako vlastní zamestnanci, ktorí majú na svedomí únik väčšiny informácií,

FEI KPI

61

pretože majú k týmto dátam úplne legitímne prístup bez ohľadu na to, kde sú

umiestnené. K dátam by preto mal byť riadený prístup, v úložisku aj pri prenose by mali

byť šifrované a mal by sa vytvárať log o činnostiach používateľov v systéme. Problém

nastáva, čo sa s dátami stane v okamihu, keď zruší zmluva o poskytovaní služieb. Dáta

ktoré prislúchajú zákazníkovi, ktorý zrušil poskytovanie hostingu musia byť

garantovane a bezpečne zničené aby sa predišlo ich zneužitiu. Tu sa natíska otázka, či

dáta, ktoré majú vysoký stupeň utajenia, alebo sú veľmi citlivé majú vôbec ukladať do

cloudu.

8.2.3 Integrita ako kritérium bezpečnosti cloud computingu

Aplikácie v cloude a/alebo dáta samotné môžu byť pozmenené neoprávnenou osobou a

rovnako tak môže dôjsť k nežiaducej modifikáciu dát v dôsledku zlyhania hardvéru

alebo softvéru. Je preto potrebné vytvoriť systém na zachovanie integrity dát aj na

strane prenajímateľa aj na strane poskytovateľa cloud služieb aby sa redukovalo riziko

straty alebo pozmenenia dát. Stále tu vyplýva otázka či majú byť životne dôležité dáta

uložené iba v cloude alebo majú byť v cloude iba zálohované alebo zrkadlené.

8.3 Verejný cloud a jeho zabezpečenie

Kritickou súčasťou prechodu k verejnému cloudu je presun jeho zabezpečenia

mimo kontrolu podniku smerom k poskytovateľovi daného cloudu, čo vedie k potrebám

zmien v poňatí informačnej bezpečnosti. Jedná sa o zdieľanie riadenia bezpečnosti,

ktoré je absolútne nevyhnutné pre ďalší rozvoj dôveryhodných vzťahov medzi

prenajímateľmi a poskytovateľmi cloudových služieb. Tými najdôležitejšími procesmi

sú z pohľadu bezpečnosti najmä riadenie prístupu, ochrana dát a zhoda s predpismi a

zákonmi. Správa identít a autentizačné služby hrajú v bezpečnosti cloudu kľúčovú

úlohu. Ochrana identít zabezpečuje integritu a dôvernosť dát aj aplikácií a sprístupňuje

ich autorizovaným používateľom. Podpora vyššie uvedených funkcií je neoddeliteľnou

súčasťou všetkých typov cloudu vrátane toho verejného.

Z pohľadu riadenia prístupu do cloudu je potrebné sa sústrediť najmä na silnú

autentizáciu. Ak má verejný cloud slúžiť na prevádzku podnikových aplikácií, je

FEI KPI

62

bezpodmienečne nutné využiť silnejšiu autentizáciu používateľov, než je bežne

zaužívane no už prekonané užívateľské meno a heslo. Štandardom v tejto oblasti je

použitie overených technológií pre silnú autentizáciu napr. autentizácia na báze

jednorazového hesla, federatívne / delegované identity pre dôveryhodné zdieľanie

identít medzi rôznymi subjektmi, a autentizáciu založenú na správaní užívateľa,

kontextu a mnohých ďalších faktoroch . Vhodnou kombináciou a vrstvením týchto

autentizačných metód možno zabezpečiť ako dodržanie bezpečnostných SLA, tak

jednoduchosť použitia pre všetky typy užívateľov. V tradičnom dátovom centre je

bezpečnosť riešená nielen IT prostriedkami, ale súčasne fyzickým zabezpečením

prístupu k hardvérovej infraštruktúre. Táto bariéra ale s príchodom verejného cloudu

mizne. Namiesto stavania bariér je potrebné sa sústrediť na riadenie bezpečnosti

konkrétnych informácií. Dáta putujúce v cloudw aj mimo neho tak majú vlastné

zabezpečenie, ktoré ich po celú dobu chráni. Na dosiahnutie tejto bezpečnosti je

potrebné vyriešiť niekoľko oblastí a to najmä:

Oddelenie dát: Vo verejných cloudoch, kde sa spracovávajú dáta mnohých

nájomcov, musia byť dáta izolované. Virtualizácia, šifrovanie a granulárne riadenie

prístupu významne pomôžu v izolácii dát medzi nájomcami, jednotlivými skupinami

alebo užívateľmi.

Granulárna bezpečnosť dát: So zvyšujúcou sa citlivosťou informácií a ich počtom

sa musí prehĺbiť aj klasifikácia dát a dôslednosť v presadzovaní ich výhradne

oprávneného použitia. Vo verejnom cloude je bezpečnosť dát tak kritická, že jej hĺbku

musíme riešiť už na úrovni súboru, tabuľky alebo stĺpca v databáze. S tým tiež

prichádza inšpekcia dát, sledovanie obsahu, či šifrovanie a bezpečná správa šifrovacích

kľúčov po celý životný cyklus dát.

Klasifikácia dát: Nájsť v cloude ideálny pomer medzi užívateľským komfortom a

požiadavkami na jeho zabezpečenie nie je jednoduché. Dôležitými krokmi k nájdeniu

toho správneho pomeru je klasifikácia dát a fungujúce procesy pre ich vyhľadávanie a

monitoring toku a použitia. V tejto oblasti významne pomáhajú systémy pre

vyhľadávanie a ochranu citlivých dát.

Monitoring a audit: Prostredie všetkých systémov, v ktorých sa pracuje s citlivými

informáciami, musí byť z pohľadu bezpečnosti kompletne monitorované a pravidelne

auditované. Ideálnym riešením tejto oblasti je systém na zber a analýzu logov z

FEI KPI

63

kľúčových systémov s ohlasovaním do podnikového riešenia pre riadenie podnikových

procesov a rizík.

Infraštruktúra: Celá infraštruktúra cloudu musí byť už v jadre bezpečná, nezávisle

na tom, či sa stavia privátny alebo verejný cloud.

Komplexná bezpečnosť: Cloud musí už byť navrhnutý ako bezpečný, postavený z

bezpečných komponentov, implementovaný podľa zodpovedajúcich bezpečnostných

princípov, bezpečne komunikujúci s okolím, a podporujúcim potrebné bezpečnostné

SLA zmluvy a princípy.

Bezpečná integrácia: Tam, kde dochádza ku komunikácii medzi jednotlivými

časťami cloudu, je potrebné vynucovať dodržiavanie bezpečnostných politík pre

zdieľanie dát, aby bola zaistená ich integrita a dôvernosť a aby sa predišlo slabému

miestu na prípadný útok.

8.4 Cisco ACL ako nástroj na aplikáciu bezpečnostných politík

Cisco ACL je nástroj na zavádzanie bezpečnostných pravidiel a zahŕňa v sebe

nástroj na tvorbu pravidiel, tak aj samotný nástroj uplatňovania týchto pravidiel. Delí sa

na dva typy, Port ACL a VLAN ACL, pre túto prácu sú dôležité Port ACL. Port ACL sa

ďalej delia na IPv4 ACL, IPv6 ACL a Ethernet (MAC) ACL. IPv4 a IPv6 ACL sa

používajú na tvorbu pravidiel na sieťovej vrstve (IP adresy), Ethernet (MAC) ACL sa

používajú na tvorbu pravidiel na spojovej vrstve (MAC adresy). Pre potrebu tejto práce

budú bližšie rozobraté IPv4 ACL. IPv4 ACL filtrujú prevádzku IPv4 (IPv6 teda filtrujú

prevádzku IPv6). ACL sa používajú predovšetkým ako základná sieťová bezpečnosť, k

blokovaniu alebo povoleniu prevádzky na rozhraní smerovača.

Poznáme viacero typov ACL a to:

IP ACL - filtruje IPv4 prevádzka - IP, TCP, UDP, IGMP (multicast), ICMP

Port ACL - pre fyzický L2 interface (aplikujeme na port), len prichádzajúci

smer

o Numbered Standard - číslované, len zdrojová adresa

o Numbered Extended - číslované, zdrojová aj cieľová adresa a

voliteľne port

FEI KPI

64

o Named Standard - pomenované štandard

o Named Extended - pomenované extended

Router ACL - pre L3 rozhranie - SVI (switch virtual interface, virtuálne

rozhranie prepínača - L3 rozhranie pre VLAN), fyzické L3 rozhranie

(port), L3 EtherChannel (spojenie viac portov); kontrolujú smerovanie

prevádzky, odchádzajúci alebo prichádzajúci smer

o Standard

o Extended

o Named

VLAN mapa - kontroluje všetky pakety (smerované aj bridgované =

switchované), môžeme kontrolovať prevádzku medzi zariadeniami v rámci

jednej VLAN. Neriešia sa smer (odchádzajúce, prichádzajúce)., Aplikuje

sa na VLAN.

o Standard

o Extended

o Named

MAC ACL (Ethernet ACL) - non-IP prevádzku

Port ACL

o Standard

o Extended

o Named Extended

VLAN mapa

o Named Extended

Hlavné delenie je teda podľa typu adries, ktoré používame v pravidlách.

Najčastejšie sú IP a MAC ACL, ale už aj IPv6 ACL, ktoré môžu byť Port alebo Router

a iba Named. Existujú aj už takmer nepoužívané IPX ACL.

Ďalšie delenie je podľa toho, kam dané ACL aplikujeme. Môžeme na L2

rozhranie, L3 rozhranie alebo špeciálny prípad sú VLAN mapy. Následne sa delia

samotné typy ACL, buď štandardné, rozšírené alebo pomenované.

FEI KPI

65

ACL je sekvenčný (zoradený) zoznam pravidiel permit (povoliť) a deny (zakázať),

týmto pravidlám sa hovorí ACE (Access Control Entries). ACL môžeme identifikovať

číslom (číslované ACL) alebo menom (pomenované ACL). Nové pravidlá sa pridávajú

na koniec zoznamu alebo na konkrétny riadok. Používa sa pravidlo, že zoznam sa

prechádza od začiatku do koncu, a ak dôjde k zhode paket sa buď zablokuje alebo

povolí a ďalej sa zoznam už neprechádza. Na konci každého IPv4 ACL je implicitné

„deny ip any any“, teda implicitné pravidlo, ktoré zakáže každý paket, ktorý nevyhovel

ani jednému z predchádzajúcich pravidiel. Je dobré umiestňovať viac špecifické

pravidlá na začiatok a všeobecné pravidlá na koniec, čím sa zabezpečí že pakety ktoré

vyhovujú aj niektorému všeobecnému pravidlu budú najprv otestované voči

detailnejším pravidlám, a až v prípade že žiadne z detailnejších nie je v zhode až vtedy

sa použijú všeobecnejšie pravidlá. Ak sa v ACL vyhodnotí zhoda paketu s deny

pravidlom, tak sa odošle správa ICMP host nedosiahnuteľný (unreachable). Filtrovanie

(používanie ACL) spomaľuje zariadenie (stojí výpočtový výkon). Odchádzajúce

pravidlá (outbound filters) neovplyvňujú prevádzku, ktorý pochádza lokálne z

smerovaču ,filtrujú iba prechádzajúcu prevádzku, ktorá pochádza mimo smerovača. U

ACL sa nepoužívajú klasické sieťové masky, ale tzv. wildcard masky. Jedná sa o

inverznú masku, teda opačná maska voči tradičnej maske. Výpočet inverznej masky je

jednoduchý, vezmeme postupne všetky štyri oktety (8bitové časti) masky a spočítame

255 - oktet. Napríklad pre masku 255.255.255.0 je to 0.0.0.255 pretože 255-255=0

a 255-0=255. Inak povedané ak spočítame klasickú masku podsiete s inverznou maskou

dostaneme 255.255.255.255, pretože napríklad ku sieti 192.168.1.0/24, kde je teda

maska 255.255.255.0 je inverzná maska 0.0.0.255. Ak teda spočítame tradičnú a

inverznú masku dostaneme 255.255.255.255.

Standard ACL je staršia a jednoduchšia verzia, má menej možností konfigurácie.

Používajú sa číselné označenia 1-99 a 1300-1999. Filtruje iba zdrojové adresy, väčšinou

sa používa ako odchádzajúci filter, teda na filtrovanie odchádzajúcej prevádzky.

Extended ACL používa označenie 100-199 a 2000-2699. Dokáže filtrovať IP adresu

zdroja aj cieľu, kontroluje položky v hlavičke 3. a 4.sieťovej vrstvy (protokol, ToS

(Type of Service), TCP porty a protokoly, UDP porty, ...).

Syntax vytvárania pravidiel:

Standard ACL:

FEI KPI

66

# access-list cislo {deny | permit} {host | source source-wildcard | any} [log]

Extended ACL:

# access-list cislo {deny | permit} protokol {host | source source-wildcard | any} [port]

{host | destination destination-wildcar | any} [port]

Vytvorený ACL sa aplikuje na zvolené rozhranie a smer. ACL sa dá aplikovať iba na

smer dovnútra (in) alebo von (out)

Syntax: # ip access-group cislo {in | out}

ACL slúžia hlavne na:

ako základná sieťová bezpečnosť na blokovanie alebo povolenie (smerovanej)

prevádzky

ku kontrole šírky pásma

Policy Based Routing (smerovanie podľa pravidiel)

vynútenia sieťových politík

identifikáciu alebo klasifikáciu prevádzky (pre QoS, NAT, apod)

V nasledujúcich riadkoch je priblížené problematika použitia a aplikácie ACL.

Tým, že aplikujeme ACL na rozhranie, tak riadime prístup paketov k tomuto

rozhraniu. ACL môžeme aplikovať na nejaké rozhranie, ktorým môže byť port, sériová

linka, VLAN, apod. Môžeme aplikovať iba jeden ACL na jedno rozhranie, smer a

protokol. Protokolom je myslené IP, IPX, Apple Talk apod. Takže napríklad pre jeden

port v TCP / IP sieti môžeme aplikovať maximálne dve ACL (jedno vstupné - inbound a

jedno výstupné - outbound). Pri umiestňovaní ACL je nutné si premyslieť ich

umiestnenie pre dosiahnutie dobrej efektivity. Pokiaľ to je možné, tak je dobré voliť

nasadenie čo najbližšie ku zdroju, aby nebola zaťažovaná sieť. ACL však môžeme

umiestňovať iba na zariadenia, ktoré kontrolujeme, takže často je potrebné nastaviť

ACL blízko cieľa.

Určenie smeru, v ktorom má ACL pôsobiť nie je zložité. Treba sa pozrieť na

prepínač, kde ho aplikujeme a rozhodnúť, či je potrebné obmedziť pakety, ktoré z neho

odchádzajú (out) alebo filtrovať hneď na vstupe, teda tie ktoré prichádza (in). Standard

ACL sa umiestňuje blízko cieľa a mal by teda byť vždy v smere von teda out. Extended

ACL sa väčšinou snažíme umiestniť čo najbližšie k zdroju a v tom prípade je filter

vstupný teda in.

FEI KPI

67

8.5 Iné mechanizmy na zabezpečenie infraštruktúr okrem ACL

CBAC

Context-Based Access Control (CBAC) je jedna z funkcií Cisco IOS Firewall

funkcií. CBAC aktívne kontroluje aktivitu za firewallom (bezpečnostný mechanizmus

na povolenie alebo zakázanie komunikácie do/z chránenej siete). CBAC špecifikuje aká

dátová prevádzka má byť prepustená dovnútra a aká prevádzka má byť prepustená von

pomocou prístupových zoznamov ACL (rovnakým spôsobom ako IOS používa ACL).

CBAC záznamy, ale obsahujú aj pravidlá pre ip inšpekciu, ktoré umožňujú aj hlbšiu

kontrolu protokolov pre prípad, že by sa s nimi nepovolene manipulovalo, alebo bol

pozmenený ich obsah, ešte predtým ako sa dostanú za firewall. CBAC v podstate

kontroluje pakety s ohľadom aj na aplikačnú vrstvu a teda sleduje a povolí len

komunikáciu, ktorá bola vyžiadaná alebo je potrebná v chránenej oblasti, ostatnú

prichádzajúcu komunikáciu zakáže, aj keď vyhovie ACL. Takáto funkčnosť sa dá

označiť ako základy SPI (Stateful Inspection) Firewall.

V prvom kroku sa klasicky vytvoria a ACL, podľa toho akú prevádzku je nutné

prepustiť a akú zakázať. Používajú sa Extended (rozšírené) ACL. Následne sa vytvárajú

pravidlá pre prevádzky, ktorú je potrebné sledovať aj pomocou CBAC. Zapnutie

inšpekcie sa robí príkazom v tvare „ip inspect name mysite ftp“, kde tento príkaz zapína

inšpekciu ftp protokolu. Posledným krokom je nasadenie už vytvorených ACL na

jednotlivé rozhrania.

ZBPF

Zone Based Policy Firewall (ZBPF) má veľmi podobnú funkčnosť ako CBAC, no

hlavnýcm rozdielom je, že kde CBAC sa aplikuje na jednotlivé rozhrania, pri ZBPF sa

vytvoria zóny, ktoré obsahujú jedno alebo viac rozhraní podľa toho, do ktorej zóny má

dané rozhranie patriť. Takéto zóny môžu byť napríklad zóna internetu, zóna intranetu,

zóna privátna s minimálnym prístupom, zóna verejne dostupných serverov, zóna

serverov dostupných iba pre intranet a podobne. Pravidlá povolenia alebo zakázania sa

potom aplikujú pri prechode dát medzi jednotlivými zónami.

Pre použitie ZBPF je nutné najprv vytvoriť zóny. Teda napríklad :

zone security OUTSIDE

zone security INSIDE

FEI KPI

68

Následne je nutné priradiť jednotlivé rozhrania ku jednotlivým zónam, teda

napríklad:

interface FastEthernet0 zone-member security OUTSIDE

interface FastEthernet1 zone-member security INSIDE

interface Vlan13 zone-member security INSIDE

Následne je nutné vytvoriť pravidlá pre povolenú prevádzku. Ak teda chceme

napríklad povoliť prevádzku telnet-u zo zóny INSIDE do zóny OUTSIDE potrebujeme

vytvoriť tzv. class-map môže teda vyzerať takto:

class-map type inspect match-any class-INSIDE-TO-OUTSIDE match protocol

telnet

Tento príkaz nám zaistí, že ZBPF bude sledovať telnet komunkáciu no ešte

nemáme definované, čo s touto komunikáciou má spraviť. Na toto potrebujeme vytvoriť

tzv. policy-map, teda súbor pravidiel , ktorý sa bude aplikovať na class-map. Je nutné

podotknúť, že na každú funkciu, v tomto prípade smer z INSIDE do OUTSIDE je

možné aplikovať iba jednu class-map a iba jednu policy-map. Policy-map je

vyhodnocovaná podobne ako ACL, teda od vrchu po spodok a na konci je štandarnde

pravidlo, ktoré zahodí všetku prevádzku, ktorá nevyhovuje inému predchádzajúcemu

pravidlu. Policy-map teda môže v našom prípade vyzerať nasledovne:

policy-map type inspect policy-INSIDE-TO-OUTSIDE class type inspect class-

INSIDE-TO-OUTSIDE inspect class class-default drop

Posledným krokom je aplikovať túto konfiguráciu. Máme teda zóny, ale je nutné

ich spárovať. Ako už bolo povedané jedna skupina ZBPF pravidiel riadi iba prevádzku

z jednej zóny do druhej a to iba v jednom smere. V tomto prípade sa teda jedná

o prevádzku zo zóny INSIDE do zóny OUTSIDE. Pre iné smery alebo iné zóny je nutné

vytvoriť ďalšiu sadu ZBPF pravidiel. Sada pravidiel aj s párovaním pre rozoberaný

prípad teda vyzerá nasledovne:

zone security OUTSIDE

zone security INSIDE

zone-pair security INSIDE-TO-OUTSIDE source INSIDE destination OUTSIDE

service-policy type inspect policy-INSIDE-TO-OUTSIDE

FEI KPI

69

FEI KPI

70

9 Webové rozhranie systému na dynamické

prehľadávanie adresného priestoru s identifikáciou

služieb, ktoré sa v ňom nachádzajú a dynamickú

rekonfiguráciu hraničných prvkov

Praktickou úlohou tejto diplomovej práce, bolo navrhnúť mechanizmus pre

dynamické prehľadávanie adresného priestoru s identifikáciou služieb, ktoré sa v ňom

nachádzajú. Za týmto účelom môže byť použitý aj jednoduchý port-scan (nmap).

Následne bolo úlohou programovo realizovať výpis objavených služieb s dynamického

objavovania prostredníctvom webového rozhrania. Pri každej službe malo byť uvedené

tlačidlo na odobratie služby (potvrdenie zo strany administrátora, že ide o zánik služby).

Následne bolo úlohou navrhnúť spôsob dynamickej rekonfigurácie sieťových zariadení

(napr. automatizovaným vzdialeným prístupom cez telnet,ssh) za účelom nasadenia

bezpečnostnej politiky (aplikácie ACL). Bolo nutné navrhnúť spôsob dynamického

generovania filtra sieťovej prevádzky (ACL) pre aktívne (objavené a potvrdené) služby.

Cieľom by malo byť povolenie iba administrátorom akceptovaných (dynamicky

objavených) služieb. Následne bolo úlohou Implementovať nástroj na dynamickú

rekonfiguráciu hraničných prvkov na ktoré sa aplikuje vygenerovaná konfigurácia.

Schéma testovacieho prostredia, ktorá bola použitá na vytvorenie tohto riešenia je

zobrazená na obrázku X.

FEI KPI

71

Obrázok 7 Schéma testovacieho prostredia

Pre praktické uskutočnenie týchto úloh bolo nutné si najprv celú problematiku

rozanalyzovať a určiť si dôležité body a celkový koncept riešenia. Keďže riešenie malo

byť implementované ako webové rozhranie, bola ako platforma zvolený webový server

Apache, programovací jazyk PHP a ako databáze pre ukladanie záznamov o objavených

službách bola zvolená MySQL databáza. Pre celkovú funkčnosť systému je nutné ku

týmto požiadavkám pridať aj program NMAP, konkrétne bola použitá verzia 5.0, ktorý

je využívaný ako skenovací prvok pre dynamické objavovanie služieb v danom

adresnom priestore. NMAP bol vybratý kvôli širokej škále funkcií, ktoré ponúka no

zároveň je práca s ním a jeho výstup relatívne jednoduchá. Inou alternatívou bolo

používanie skenovania portov priamo pomocou PHP jazyka a jeho knižníc a funkcií no

táto alternatíva bola zavrhnutá s odôvodnením, že dané možnosti a funkcie jazyka PHP

nie sú dostatočne široké a to hlavne pre prípadné ďalšie potreby v prípade ak by sa toto

riešenie ďalej vyvíjalo aj po obhajobe diplomovej práce v praxi. Možnosti jazyka PHP

neposkytujú funkcie ako zvolenia skenovacej metódy, možnosť vyhodnocovania typu

zariadenia a operačného systému cieľa a podobne. Aj keď tieto funkcie v cieľovom

riešení nie sú potrebné a teda ani nie sú implementované. S dôrazom na prípadný ďalší

vývoj systému sa toto riešenie pomocou PHP zavrhlo. Inou alternatívou bolo použitie

nástroja NetFlow, ktorý poskytuje ešte širšie možnosti ako NMAP, ako napríklad

obojsmerné vyhodnocovanie dátového toku a podobne. Táto alternatíva, ale vysoko

FEI KPI

72

presahovala určený cieľ tejto diplomovej práce, a integrovanie nástroja NetFlow tak

autor necháva ako otvorenú otázku pre iné diplomové práce, prípadne pre ďalší vývoj

tohto nástroja.

Ďalšou potrebnou súčasťou tohto riešenia je nástroj CRON, ktorý je používaný na

zautomatizovanie skenovania daného adresného priestoru pomocou tohto nástroja.

V zásade boli dve možnosti. Buď samotné riešenie, ktoré je cieľom tejto diplomovej

práce bude mať možnosť vytvoriť samotný CRON záznam (job), alebo bude toto

riešenie poskytovať iba rozhranie na automatický sken adresného priestoru

a zautomatizovanie pomocou nástroja CRON (prípadne iného nástroja) bude ponechané

na užívateľovi. Prvá možnosť by ponúkala jednoduchosť, keďže všetko by bolo v rámci

jedného webového rozhrania, no zároveň predstavuje bezpečnostné riziko, keďže už

samotný program NMAP predstavuje bezpečnostné riziko, pretože ho je možné

jednoducho zneužiť na skenovanie cieľa aj mimo určené ciele. Zvolená bola preto

alternatíva, keď pomocou webového rozhrania je možné iba zmeniť nastavenia pre

automatický sken, ktoré sa uložia do konfiguračného súboru. Následne iba autorizovaný

administrátor jednoducho jedným príkazom vyrobí CRON záznam, ktorý bude spúšťať

na to určený skript riešenia, ktorý prevedie automatický sken podľa konfiguračného

súboru a uloží výsledky do databázy. Takýto CRON záznam vyrobíme pomocou

príkazu „crontab“. Pre bližší pohľad na možnosti obsluhy tohto nástroja je potrebné si

preštudovať oficiálne príručky pre používanie. Príklad takéhoto záznamu je napríklad:

1 1 * * * php /home/dulus/public_html/nmapUI_development/scan_auto.php

>/dev/null 2>&1 >/dev/null 2>&1 >/dev/null 2>&1 # JOB_ID_4

Tento skript sa bude automaticky spúšťať každý deň o 01:01 a jeho výstup bude

potlačený. Na spustenie automatického skenovania je teda nutné zavolať php súbor

„scan_auto.php“, ktorý je súčasťou tohto riešenia pomocou konzolového interpretéra

jazyka PHP (príkaz „php“).

Pre zvýšenú bezpečnosť môže administrátor ešte aj zamknúť konfiguračný súbor

pred zmenami, aby nemohol niekto zmeniť nastavenia automatického skenovania už po

vyrobení CRON záznamu. Autor tejto diplomovej práce nabáda užívateľov tohto

riešenia aby tieto bezpečnostné princípy dodržiavali a odporúča aby aj samotné webové

rozhranie, či už pre manuálne skenovanie, alebo pre zmenu nastavení automatického

skenovania bolo chránené nejakým autorizačným systémom, minimálne pomocou

FEI KPI

73

zabudovanej ochrany heslom HTACCESS, ktoré ponúka samotný webový server

Apache.

Ďalšou nutnosťou pre spustenie CRON záznamu je nainštalovaný intepretér PHP

pre konzolu (príkazový riadok) a nainštalované aj MySQL rozhranie pre tento

intepretér. Tento intepretér je nutný na spustenie php skriptu pomocou príkazového

riadku, keďže CRON dokáže spustiť iba príkaz pomocou príkazového riadku.

Súčasťou tohto riešenia je aj nástroj Expect-Lite pomocou, ktorého sa automaticky

aplikuje generovaný ACL na hraničný prvok siete. Je preto nutné mať tento nástroj

nainštalovaný na zariadení odkiaľ sa ACL aplikuje.

Poslednou dôležitou súčasťou tohto riešenia sú konfiguračné súbory a skripty. Je

nutné aby bol vytvorený konfiguračný súbor „scan.cfg“, kde sa ukladajú nstavenia pre

automatický sken a aby tento súbor mal také prístupové práva aby PHP skript bol

schopný do neho zapisovať. Ďalej je nutné vytvoriť v podpriečinku „generated_acl“ aj

súbor, do ktorého php skript bude zapisovať skript pre nástroj Expect-Lite. Takisto aj

tento súbor musí mať také prístupové práva aby PHP skript bol schopný do neho

zapisovať.

Schéma toku dát v programe je znázornená na obrázku 8.

FEI KPI

74

Obrázok 8 Schéma toku dát v programe

Samotné skenovanie adresného priestoru je založené na TCP a ICMP ping funkcii

NMAP-u. NMAP pomocou týchto funkcií zistí dostupnosť jednotlivých zariadení

v danom adresnom priestore a potom na týchto zariadeniach zistí dostupné služby, ktoré

sú indikované otvoreným portom na danom zariadení. Užívateľ pri manuálnom

skenovaní, alebo aj automatickom skenovaní môže vybrať akú adresu (napr.

192.168.70.25), alebo celý adresný priestor (napr. 192.168.70.0/24) sa má skenovať

a aký rozsah portov sa má skenovať (napr. 1-1024). Je nutné uviesť, že skenovanie trvá

určitú dlhšiu dobu a čím viac zariadení sa v sieti nachádza tým dlhšie trvá celý proces

skenovania. Ďalšou premenou, ktorá môže značne predĺžiť čas skenovania je rozsah

portov, ktorý sa má skenovať. Čím je tento rozsah väčší tým je aj čas skenovania dlhší.

FEI KPI

75

Ďalšou vlastnosťou, ktorá môže ovplyvniť čas skenovania je samotná sieťová linka,

ktorá vedie od zdroja skenovania ku cieľu skenovania. Čas skenovania môže ovplyvniť

prenosová rýchlosť, šírka pásma, počet skokov (smerovačov) na ceste, filtrovacie

zariadenia a podobne. Je možné, že ak skenovanie prebieha cez neznámu sieť, tak budú

niektoré skenovacie funkcie zablokované niektorým z bezpečnostných prvkov na ceste.

Autor tejto diplomovej práce vyzýva aby toto riešenie nebolo zneužívané na skenovanie

cieľov, na ktoré nemá užívateľ priame povolenie ich skenovať. Takáto aktivita na cieľ,

ktorý o tom nie je informovaný môže byť vyhodnotená jeho správcom ako útok.

Nastavenie manuálneho skenu je zobrazené na obrázku č. 7

Obrázok 9 Nastavenie manuálneho skenovania

Nastavenie automatického skenu je zobrezené na obrázku č. 8

FEI KPI

76

Obrázok 10 Nastavenie automatického skenovania

Po prevedení skenovania, je výsledkom zoznam IP adries a k nim prislúchajúce

otvorené alebo filtrované porty s prislúchajúcim protokolom a niekedy aj názvom

služby. Príklad takéhoto výstupu je napr. nejaká IP adresa napr. 192.168.70.25 a k nej

prislúchajúci riadok „22/tcp open ssh“. Teda z takéhoto výstupu vieme usúdiť , že na

danej adrese je otvorený port 22 na protokole tcp, a názov služby je SSH, teda vzdialený

FEI KPI

77

šifrovaný prístup. Ako to vyzerá je zobrazené na obrázku č. 9

Obrázok 11 Výstup po úspešnom skenovaní

Všetky tieto údaje sa ukladajú aj do databázy. Do databázy sa ukladá aj čas

skenovania, v prípade manuálneho skenovania IP adresa odkiaľ prišla požiadavka na

skenovanie, v prípade automatického skenovania je tam uvedené iba (cron). Pri

skenovaní, či už manuálnom, alebo automatickom, sa vždy zanecháva iba posledný

výsledok skenovania. To znamená, že ak príde požiadavka na skenovanie nejakej IP

adresy a v databáze už existuje záznam o skenovaní tejto IP adresy, tento záznam sa

najprv vymaže a až následne sa tam uložia výsledky najnovšieho skenovania. Takýmto

spôsobom je zaistené, že po aplikácií ACL, sa pri ďalšom skenovaní, už zobrazia iba

služby, ktoré boli povolené aplikovaným ACL. Ako vyzerá výstup z databázy je

zobrazené na obrázku č. 10

FEI KPI

78

Obrázok 12 Zobrazenie databázy

Dôležitým prvkom tohto riešenia je aj zobrazenie databázy výsledkov skenovania.

Pomocou webového rozhrania si užívateľ zobrazí obsah databázy, kde zistí aké služby

sú povolené na ktorých zariadeniach. Pri každom zázname je tlačidlo zmazania, čím sa

zmaže daný záznam z databázy, čo značí, že užívateľ potvrdil, že danú službu chce

zakázať. V ďalšom kroku sa totiž podľa obsahu databázy vytvorí ACL, ktorý povoľuje

iba služby, ktoré ostali v databáze a následne sa tento ACL aplikuje na hraničné

zariadenie siete. ACL sa vygeneruje na základe informácií z databázy. Keďže každé

ACL obsahuje štandardne na konci „deny any any“ , ktoré by na hraničnom zariadení

zakázalo všetku prevádzku, a tým by mohlo znefunkčniť aj iné služby generované ACL

majú tvar, v ktorom najprv povolia konkrétne služby podľa záznamov v databáze,

potom zakážu inú prevádzku ktorá smeruje na IP adresy, ktoré sú obsiahnuté v databáze

a na konci povolia každú inú prevádzku cez hraničné zariadenie. Takýmto spôsobom sa

docieli, že na IP adresy obsiahnuté v databáze sa vzťahujú pravidlá v ACL, a teda sa

povolia iba dané služby ale ostatné služby na tieto IP adresy sú zakázané a zároveň toto

ACL neovplyvní inú sieťovú prevádzku cez hraničné zariadenie.

Na aplikáciu tohto ACL je však nutný zistiť IP adresu hraničného prvku,

prístupové meno na hraničný prvok a heslá na pripojenie sa cez SSH (je nutné aby

hraničné zariadenie bolo dostupné cez SSH) a na vstup do privilegovaného (a

konfiguračného) módu, taktiež, interface (rozhranie) hraničného prvku kam sa má

aplikovať ACL (ACL sa aplikuje v smere in, teda dovnútra, toto rozhranie musí byť

hraničné rozhranie medzi hraničným zariadením a ostanou sieťou, nie rozhranie medzi

zariadením a skenovanou sieťou) a taktiež číslo ACL (používajú sa rozšírené [extended]

ACL), ktoré má byť použité na zápis generovaného ACL. Tento generovaný ACL bude

FEI KPI

79

v prípade existencie ACL s rovnakým čislom na zariadení prepísaný cez už existujúci

ACL. Všetky tieto informácie si webové rozhranie vypýta od užívateľa. Ako vyzerá

formulár na zistenie týchto informácií je uvedené na obrázku č. 11

Obrázok 13 Nastavenie ACL

Výsledkom takéhoto procesu je skript pre nástroj Expect-Lite, ktorý sa pripojí pomocou

SSH na hraničné zariadenie, a následne zruší prípadný existujúci ACL s rovnakým

číslom, zruší aplikáciu daného ACL na vybraté rozhranie a následne vytvorý

vygenerovaný ACL s vybratým číslom a následne aplikuje tento ACL na vybrané

rozhranie v smere in. Takýmto spôsobom sa podľa údajov v databáze povolia iba služby

ktoré užívateľ výslovne povolil. Toto riešenie automaticky povoľuje aj vzdialený

prístup na zariadenia za hraničným prvkom a ICMP pakety, no v prípade potreby je

možné toto chovanie jednoducho ovplyvniť zakomentovaním príslušných riadkov časti

kódu ktorý generuje ACL. Takýto skript môže vyzerať napríklad nasledujúco: ; ==== Apply generated ACL ==== # @3 >>ssh $host -l $user >yes >yes <$user@$host\'s password >>$password <> >>Enable <Password >>$enablePassword #+$myvar=(*) @3 >configure terminal <(config) >no access-list 105 #< >interface FastEthernet 0/0 <(config-if) >no ip access-group 105 in >exit <(config) >access-list 105 permit icmp any any #< >access-list 105 permit tcp any host 192.168.70.6 eq 22 #< >access-list 105 permit tcp any host 192.168.70.6 eq 23 #< >access-list 105 permit tcp any host 192.168.70.25 eq 21

FEI KPI

80

#< >access-list 105 permit tcp any host 192.168.70.25 eq 80 #< >access-list 105 permit tcp any host 192.168.70.25 eq 443 #< >access-list 105 deny ip any host 192.168.70.6 #< >access-list 105 deny ip any host 192.168.70.25 #< >access-list 105 permit ip any any #< >interface FastEthernet 0/0 <(config-if) >ip access-group 105 in #+$myvar=(*) >>exit >>^C <#

Takýto skript neobsahuje premenné meno užívateľa, heslá, ip adresy a podobne,

ktoré sa nikde neukladajú do súboru, ale sú ako argumenty skriptu pri spúšťaní skriptu

pomocou expect-lite. Takýmto spôsobom sa zvyšuje bezpečnosť, keďže heslá nie sú

nikde uložené vo formáte obyčajného textu. Výstup webového rozhrania po aplikácii

tohto skriptu je uvedený na nasledujúcich obrázkoch.

Obrázok 14 Zobrazenie vygenerovaného Expect-Lite skriptu

FEI KPI

81

Obrázok 15 Zobrazenie výstupu Expect-Lite po dokončení

FEI KPI

82

10 Záver

Na záver by bolo vhodné zhodnotiť systém Cloud Computing ako veľmi

komplexný a zložitý systém, ktorý prináša ako výhody tak aj nevýhody. V poslednej

dobe je téma Cloud Computing pomerne na vzostupe a o túto technológiu sa javí čoraz

väčší záujem. Ako bolo uvedené v tejto diplomovej práci, je nutné si vybrať správny

typ Cloud Computingu, prípadne si ho prispôsobiť podľa potrieb. Je nutné podotknúť,

že aj napriek tomu sa môžu nájsť projekty pre, ktoré Cloud Computing nie je vhodný.

Praktické riešenie v tejto diplomovej práci síce používa iba niektoré z technológií,

používaných v Cloud Computingu no to je len dôkaz aká široká a obsiahla táto téma je.

Praktické riešenie je možné ďalej rozširovať ako už bolo spomenuté skôr v diplomovej

práci, a môže sa uberať mnohými smermi. Na základe aj v tejto diplomovej práci

získaných poznatkov je možné predpokladať, že téma Cloud Computing sa ešte bude

vyvíjať a je možné, že postupne nahradí dlhoročne zaužívané praktiky a technológie.

FEI KPI

83

Zoznam použitej literatúry

[1] IBM Global Services: Improving Systems Availability IBM Global Services, Information Development Center 3200 Windy Hill Road, Atlanta, GA 30339 U.S.A., 1999

[2] CA: Replication and High Availability for VMware Cloud Operating Systems,

[3] VCE Company, LLC: VBLOCK™ POWERED SOLUTION FOR SAP: HIGH AVAILABILITY FOR THE PRIVATE CLOUD , 2010. P/N H7157.

[4] Vladimír Bálint: Cloud computing, jeho využitie a dopad na korporačné prostredie, Bakalárska práca, Unicorn College 2011.

[5] OVH Load Balancer Cisco ACE: Rozdělení zátěže a vysoké dostupnosti pro Váš virtuální rack.

[6] TwinStrata, Inc. : Decrease Downtime for Data Protection and Cloud Storage SANs with CloudArray® , 2011

[7] AUSWEB.COM.AU Pty/Ltd : VMware High Availability Hosting : , 2011

[8] VMware, Inc. : VMware High Availability : ENSURE SIMPLE, COST-EFFECTIVE AVAILABILITY FOR ALL YOUR APPLICATIONS, 2011.

[9] Marian Kuna, Virtualizácia serverov – základný kameň pri budovaní cloudu, Infoware, Digital Visions, spol. s r.o, 2011

[10] VMware, Inc. : VMware vSphere™ : High Availability (HA) - Decrease Downtime and Reduce Risk, 2011.

[11] VMware, Inc. : Hosting Providers, 2011.

[12] VMware, Inc. : SharePoint Server and the Private Cloud, 2011.

[13] VMware, Inc. : VMware vCenter Server Heartbeat, Ensure Availability for the VMware vCenter Server Management Platform, 2011.

[14] TechTarget : VMware HA (High Availability)

[15] DevCentral : Load balancing is key to successful cloud-based (dynamic) architectures, F5 Networks, Inc., 2009.

[16] Vern Burke : Cloud computing, load balancing, and extending the data center into a cloud., SwiftWater Telecom, Biddeford, ME, 2010.

[17] Lori MacVittie : Nobody Puts "Load Balancing" Baby in "Cloud Computing" Corner, Cloud Computing jaournal, Ulitzer, Inc., 2010.

[18] Michal Illich : Cloud je někdy také předražená hračka, Lupa.cz, Internet Info, s.r.o., 2011

[19] Nethemba : Cloud Computing řešení, Nethemba

[20] Greg Dixon : 15 Important Things about cloud for providers and customers, ScanSource, Sro, CatConf11, 2011

FEI KPI

84

[21] Cisco : Cisco ACE Application Control Engine Module for Cisco Catalyst 6500 Series Prepínačes and Cisco 7600 Series Routers, Cisco

[22] Volker Schmeisser : Breaking clouds above cloud computing, Citrix Systems, 2010

[23] Martin Malý : Představení cloudových služeb: Amazon Web Services, Lupa.cz, Internet Info, s.r.o., 2011

[24] Cisco : How Does Load Balancing Work?, Cisco Document ID: 5212, 2005

[25] GigeNET Cloud : Web Load Balancing and Scalability, GigeNET Cloud, Cloud Communications LLC.

[26] A10 Networks : AX Series: Virtualization For Cloud Computing, A10 Networks, Inc.

[27] Amazon: Amazon Elastic Compute Cloud (Amazon EC2), Amazon Web Services LLC, 2011

[28] Martin Klubeck : Measuring the Cloud, EDUCASE Quarterly Magazine, Volume 33, Number 2, 2010

[29] Annie Shum : A Measured Approach To Cloud Computing: Capacity Planning and Performance Assurance, BSMReview.com

[30] Paul Pocatilu, Felician Alecu, Marius Vetrici : Measuring the efficiency of cloud computing for e-learning systems, Journal WSEAS Transactions on Computers archive Volume 9 Issue 1, January 2010 World Scientific and Engineering Academy and Society (WSEAS) Stevens Point, Wisconsin, USA, 2010

[31] Gcuomo : Measuring the Performance of Your Cloud, Gcuomo Blog

[32] Niall Kennedy : Measuring efficiency in the cloud, Ignite at Etech, 2009

[33] Hogstrom : Measuring Clouds: Managing Efficiency and Expectations, Hogstrom blog, 2011

[34] SMBWorld Asia Editors : Use SLA to measure effectiveness of cloud service providers, Questex Asia Ltd, 2011

[35] Cloud Security Alliance : Security Guidance for Critical Areas of Focus in Cloud Computing, Cloud Security Alliance, 2011

[36] Cisco : Creating Business Value with Effective, Pervasive Cloud Security and Cloud Enablement Services, Cisco Systems, Inc. White Paper C11-649815-00, 2011

[37] Joe McKendrick : SOA and cloud governance: the 11 stages of a service lifecycle, ZDNet, CBS Interactive, 2011

[38] Geva Perry : The Importance of Customer Engagement For Cloud Companies, Thinking Out Cloud,2012

[39]

FEI KPI

85

Prílohy

Príloha A: DVD médium – diplomová práca v elektronickej podobe, prílohy v

elektronickej podobe.

Príloha B: Používateľská príručka

Príloha C: Systémová príručka