Inteligentna chmura obliczeniowa 1 Podstawowe definicje

Inteligentna chmura obliczeniowa 1 Podstawowe definicje

Inteligentna chmura obliczeniowa
Henryk Krawczyk
Streszczenie
Przedstawiono koncepcje chmury obliczeniowej, której istotnym elementem jest rekomender zasobów dla wykonania dowolnej aplikacji czy
usªugi. Wªa±nie budowa takiego rekomendera byªa gªównym celem projektu numer INNOTECH-K3/IN3/20/227103/NCBR/14 . Poni»ej przedstawiono gªówne zaªo»enia tego przykªadu oraz metodologi¦ bada« zwi¡zanych z zaproponowanym rekomenderem.
1 Podstawowe denicje
Wykorzystanie chmur obliczeniowych (ang. cloud computing), jako ±rodowiska
uruchomieniowego ró»norodnych klas usªug jest obecnie jednym z wiod¡cych
trendów w informatyce. Infrastruktura sprz¦towa chmury skªada si¦ z du»ej
liczby komputerów (tzw. w¦zªów obliczeniowych) o homogenicznej lub heterogenicznej architekturze. Prac¡ chmury obliczeniowej zawiaduje system zarz¡dzania, który odpowiada za przydzielanie zasobów sprz¦towych (infrastruktury) do
usªug (ang. IaaS - Infrastructure as a Service). Dzi¦ki zastosowaniu technologii
maszyn wirtualnych (ang. Virtual Machine, VM) mo»liwe jest ªatwe i bezpieczne
wspóªdzielenie zasobów sprz¦towych przez ró»nych u»ytkowników, gwarantuj¡ce
ich peªn¡ separacj¦ [1], [2].
Celem fazy badawczej jest rozwój technologii inteligentnych chmur obliczeniowych adaptuj¡cych si¦ do efektywnego wykonania ró»nych klas usªug. Podstaw¡ dla tej technologii b¦dzie opracowanie komponentu rekomendacji oferuj¡cego zaawansowane metody wspomagania mechanizmów zarz¡dzania zasobami
w heterogenicznych chmurach obliczeniowych. Komponent rekomendacji oferowa¢ b¦dzie trzy podstawowe funkcjonalno±ci:
1. klasykacj¦ usªug uruchamianych w ±rodowisku heterogenicznej chmury
obliczeniowej w oparciu o ich zapotrzebowanie na zasoby sprz¦towe,
2. estymacj¦ wykorzystania zasobów sprz¦towych przez usªugi wyznaczan¡
przy pomocy modeli obliczeniowych opracowanych dla poszczególnych klas
usªug,
3. automatyczn¡ kalibracj¦, pozwalaj¡c¡ zwi¦kszy¢ dokªadno±¢ przeprowadzanych estymacji na podstawie monitorowania wykonania usªug.
1
Dzi¦ki takiej funkcjonalno±ci, komponent rekomendacji umo»liwi zwi¦kszenie efektywno±ci alokacji zasobów w chmurze obliczeniowej, dostarczaj¡c rekomendacji w procesie doboru optymalnych w¦zªów obliczeniowych chmury dla
wykonania usªug uruchamianych przez u»ytkowników. Technologia ta stanowi¢ b¦dzie znacz¡cy krok w kierunku wdro»enia koncepcji tzw. inteligentnych
chmur obliczeniowych (ang. smart cloud computing), cechuj¡cej si¦ m.in. efektywnym wykorzystaniem dost¦pnych zasobów. Rys. 1. przedstawia schemat procesu decyzyjnego, wykorzystuj¡cego komponent rekomendacji, prowadz¡cego do
dostarczenia systemowi zarz¡dzania chmur¡ obliczeniow¡ rekomendacji najlepszego w¦zªa obliczeniowego do uruchomienia usªugi.
Rysunek 1: Schemat ekosystemu inteligentnej chmury obliczeniowej wykorzystuj¡cego komponent rekomendacji
W celu usystematyzowania problematyki przedstawiono denicje podstawowych wykorzystywanych poj¦¢, dotycz¡cych wykonywania zada« w chmurze obliczeniowej typu
IaaS.
Zale»no±ci mi¦dzy opisywanymi poj¦ciami zobrazowano
na rys. 2.
2
aplikacja użytkowa
user applica�on
obraz maszyny
VM image
specyfikacja zadania
workload specifica�on
wykonanie zadania
workload execu�on
programy
wykonywalne
programy
wykonywalne
zwirtualizowany
system
operacyjny
konfiguracja
bazowa
programy
wykonywalne
zwirtualizowany
system
operacyjny
konfiguracja
szczegółowa
oczekiwane
dane
wejściowe
wymagane
zasoby
programy
wykonywalne
zwirtualizowany
system
operacyjny
konfiguracja
szczegółowa
rzeczywiste
dane
wejściowe
wykorzystane
zasoby
system
wirtualizacji
zasoby
sprzętowe
Rysunek 2: Podstawowe poj¦cia dotycz¡ce zada« w chmurze obliczeniowej typu
IaaS
(na oletowo oznaczono elementy opisuj¡ce zadanie niezale»ne od ±rodo-
wiska uruchomieniowego, a na niebiesko te, które dotycz¡ wykonania zadania w
konkretnym ±rodowisku)
Aplikacja u»ytkowa
(ang.
user application ) zestaw programów wykonywal-
nych i powi¡zanych bibliotek realizuj¡cy pewn¡ funkcjonalno±¢. Przykªadami aplikacji w chmurze obliczeniowej mog¡ by¢ serwer
danych
MongoDB.
Obraz maszyny
(ang.
Nginx
czy baza
VM image ) gotowy do uruchomienia obraz maszyny
wirtualnej, skªadaj¡cy si¦ zazwyczaj z jednej lub wi¦cej aplikacji zainstalowanych na wybranym systemie operacyjnym (np.
dows Server ).
CentOS, Microsoft Win-
Obrazy maszyn posiadaj¡ zazwyczaj pewn¡ bazow¡ kon-
guracj¦, która mo»e zosta¢ zmieniona przez u»ytkownika. Obrazy przechowywane s¡ przewa»nie w dedykowanym repozytorium (np. komponent
Glance
w ±rodowisku
Specykacja zadania
OpenStack ).
(ang.
workload specication ) wybrany obraz maszyny
wirtualnej skongurowany do wykonania konkretnej pracy, charakteryzowanej przez pewne oczekiwane dane wej±ciowe i przewidywane zapotrzebo-
Apache
Red Hat Enterprise Linux, który ma obsªugiwa¢
wanie na zasoby sprz¦towe. Przykªadem zadania mo»e by¢ serwer
zainstalowany na systemie
±rednio 100 unikalnych klientów na minut¦, do czego potrzebnych b¦dzie 5
wirtualnych CPU, 12 GB pami¦ci RAM i 50 GB pami¦ci masowej. Zªo»one
zadania chmurowe mog¡ skªada¢ si¦ z wielu zada« prostych (np. serwer
WWW, serwer podr¦cznej pami¦ci tymczasowej, baza danych).
Wykonanie zadania
(ang.
workload execution ) uruchomienia zadania w kon-
kretnym ±rodowisku, dysponuj¡cym pewnymi zasobami sprz¦towymi i dziaªaj¡cym pod kontrol¡ pewnego systemu wirtualizacji, np. na w¦¹le chmury
wyposa»onym w dwa procesory
Intel Xeon,
3 TB, z zainstalowanym oprogramowaniem
3
128 GB RAM i dysk twardy
QEMU/KVM.
2 Problemy alokacji usªug
Twórcy systemów zarz¡dzania chmur¡ obliczeniow¡, jak równie» ich pó¹niejsi
u»ytkownicy, czyli dostawcy usªug, bardzo du»¡ wag¦ przykªadaj¡ do optymalnego wykorzystania posiadanej infrastruktury informatycznej. Brak mo»liwo±ci
dokªadnego oszacowania zapotrzebowania na zasoby powoduje, »e rezerwowane
s¡ dodatkowe zasoby sprz¦towe, które cz¦sto pozostaj¡ niewykorzystane. W
konsekwencji powoduje to nieuzasadniony wzrost wydatków na infrastruktur¦.
Zwi¦kszenie liczby usªug realizowanych na tej samej infrastrukturze sprz¦towej
przekªada si¦ bezpo±rednio na lepsze wyniki nansowe. Efektywniejsze wykorzystanie zasobów sprz¦towych nie tylko zmniejsza koszt budowy i utrzymania
caªego systemu, ale powoduje tak»e redukcj¦ zu»ycia energii elektrycznej oraz
ogranicza ilo±ci traconej energii cieplnej, (co jest istotnym problemem w przypadku rozlegªych infrastruktur informatycznych o du»ej mocy obliczeniowej),
wpisuj¡c si¦ tym samym w trend zwi¡zany z ochron¡ ±rodowiska naturalnego
(tzw. green computing). Obecnie najpowszechniejszymi sposobami doboru w¦zªa obliczeniowego, na podstawie danych o obci¡»eniu ka»dego z w¦zªów, s¡:
•
rozlokowanie usªug losowo,
•
d¡»enie do rozlokowania usªug tak aby wszystkie w¦zªy byªy obci¡»one
mo»liwie równomiernie. Z reguªy oznacz to, »e nowa usªuga jest umieszczane na najmniej obci¡»onym w¦¹le chmury obliczeniowej,
•
rozlokowanie usªug, które maksymalizuje wykorzystanie w¦zªów. Najcz¦±ciej nowa usªuga jest umieszczana na najbardziej obci¡»onym w¦¹le, który
speªnia jeszcze wymagania wydajno±ciowe, aby t¦ usªug¦ uruchomi¢.
Kilka rm, w tym znacz¡cych graczy na rynku IT, prowadzi badania i wprowadza produktu maj¡ce na celu maksymalizacj¦ wykorzystania zasobów chmur
obliczeniowych. Jest to przykªadowo rozwi¡zanie DRS (ang. Distributed Resource Scheduling) rmy VMware [7], b¡d¹ rozwi¡zanie rmy HP o nazwie Service
Health Optimizer.
Tematyka modelowania obci¡»enia komponentów sprz¦towych przez ró»ne
klasy oprogramowania jest szeroko zbadana i opisana. Liczne publikacje zajmuj¡
si¦ w szczególno±ci zagadnieniami takimi jak okre±lanie szacowanego stopnia wykorzystania zasobów obliczeniowych, np. w kontek±cie problemu optymalnego
szeregowania zada« [9], [10], równie» dla systemów czasu rzeczywistego [11], [12].
Badane s¡ tak»e relacje mi¦dzy poszczególnymi komponentami w istniej¡cych
architekturach sprz¦towych, np. zjawisko ograniczenia wykorzystania procesora
przez oczekiwanie na dost¦p do pami¦ci operacyjnej. W ramach prowadzonych
prac tworzone s¡ modele pozwalaj¡ce na przewidywanie mo»liwej do osi¡gni¦cia
wydajno±ci, np. w oparciu o symulacje [13], analiz¦ ogranicze« wydajno±ciowych [14] czy algorytmy sztucznej inteligencji [15]. Poza optymalizacj¡ wydajno±ci sprz¦tu i oprogramowania, odpowiednie modele opracowywane s¡ tak»e
w celu estymacji zu»ycia energii elektrycznej [16], okre±lenia granic wydajno±ci
przyszªych generacji sprz¦tu [17] czy projektowania efektywnych algorytmów
równolegªych [18].
4
Opisywane s¡ tak»e próby wykorzystania technik modelowania obci¡»enia
do alokacji zasobów sprz¦towych, w tym w ±rodowisku chmury obliczeniowej.
Proponowane s¡ ró»norodne podej±cia do tego zagadnienia, zakªadaj¡ce ró»ne
ograniczenia i zastosowania docelowe. Wykorzystywany jest przy tym caªy zbiór
metod modelowania, cz¦sto ª¡czonych ze sob¡ w rozwi¡zania hybrydowe. W±ród
interesuj¡cych propozycji mo»na wymieni¢: model infrastruktury chmury obliczeniowej zbudowany w oparciu o model kolejkowy G/G/N dla dynamicznego
przydzielania zasobów (maszyn wirtualnych) [19], model oparty o ªa«cuchy Markowa dla szeregowania zada« w ±rodowisku wieloprocesorowym [20], tworzenie
empirycznych modeli usªug pozwalaj¡cych na przewidywanie zmian zapotrzebowania na zasoby na podstawie monitorowania aktualnego obci¡»enia [21],
meta-model (poª¡czenie modelu empirycznego i modeli teoretycznych) wspomagaj¡cy alokacj¦ maszyn wirtualnych dla aplikacji warstwowych w chmurze
obliczeniowej [22] oraz dokonywanie estymacji zapotrzebowania na zasoby generowanego przez usªugi w chmurze w oparciu o: (a) transformat¦ Fouriera i model
sko«czonego ªa«cucha Markowa [23], (b) metody statystyczne [24], (c) sztuczne
sieci neuronowe [25] i (d) techniki wzmocnionego uczenia (ang. reinforcement
learning) poª¡czone z modelem kolejkowym [26].
Prowadzone s¡ równie» badania maj¡ce na celu okre±lenie zapotrzebowania na zasoby sprz¦towe dla specycznych klas usªug, np. udost¦pniaj¡cych i
przetwarzaj¡cych dane multimedialne [27], [28] czy serwerów wymiany komunikatów [29]. Wa»nym problemem jest tu zdeniowanie podziaªu usªug na klasy o
podobnych charakterystykach. Równie» dla tego zagadnienia istnieje wiele proponowanych rozwi¡za« [30], [31], [32], [33], [34].
Prace prowadzone w ramach fazy badawczej opiera¢ si¦ b¦d¡ zarówno na
osi¡gni¦ciach ±wiatowych, jak i na wiedzy i do±wiadczeniu zdobytych podczas
budowy platformy KASKADA, w ramach projektu Mayday Euro 2012. Platforma ta stanowi superkomputerowe ±rodowisko wykonania usªug, ze szczególnym naciskiem na usªugi przetwarzaj¡ce strumienie danych multimedialnych w
czasie rzeczywistym [35], [36]. W celu zapewnienia wysokiej jako±ci i efektywno±ci dziaªania tej klasy usªug, konieczne byªo opracowanie odpowiedniego modelu obci¡»enia i algorytmu alokacji zasobów, uwzgl¦dniaj¡cych czynniki takie
jak nieliniowy wzrost wykorzystania zasobów sprz¦towych czy problem straty
danych [37], [38].
3 Koncepcja rekomendera usªug
Formuªowanie optymalnych rekomendacji dla uruchamiania usªug w chmurze
obliczeniowej jest skomplikowanym procesem, gªównie ze wzgl¦du na liczb¦ czynników, które musz¡ by¢ brane pod uwag¦ przy wyborze najlepszego w¦zªa obliczeniowego. Gªówne czynniki wpªywaj¡ce na proces ustalania rekomendacji
ukazane s¡ na Rys. 3.
5
Rysunek 3: Czynniki wpªywaj¡ce na rekomendacje dostarczane przez opisywany
komponent
Pierwszym czynnikiem determinuj¡cym dostarczane rekomendacje s¡ kryteria dziaªania chmury obliczeniowej. System zarz¡dzania chmur¡ posiada okre±lon¡ polityk¦ alokacji w¦zªów obliczeniowych, której celem mo»e by¢:
•
zrównowa»enie obci¡»enie na wszystkich w¦zªach chmury obliczeniowej,
•
maksymalizacja wykorzystania zasobów sprz¦towych,
•
minimalizacja zu»ycia energii.
Dla ka»dego z tych typów alokacji mo»emy deniowa¢ ró»ne kryteria jako±ciowe, np.:
•
minimalizacja czas wykonania usªugi,
•
minimalizacja kosztu,
•
maksymalizacja liczby u»ytkowników, którzy mog¡ korzysta¢ z usªugi.
Drugim czynnikiem wpªywaj¡cym na proces rekomendacji jest stan w¦zªów
chmury obliczeniowej. Ka»dy z w¦zªów mo»e znajdowa¢ si¦ w jednym z kilku
mo»liwych stanów, np.:
•
aktywny,
•
nieaktywny,
6
•
przeci¡»ony,
•
wyª¡czony.
Trzecim elementem branym pod uwag¦ w procesie rekomendacji jest klasa,
do której nale»¡ uruchamiane usªugi. W±ród usªug wykonywanych w chmurach
obliczeniowych wyró»ni¢ mo»na pewne klasy ró»ni¡ce si¦ charakterystyk¡ zapotrzebowania na zasoby sprz¦towe. Mog¡ to by¢ np.:
•
usªugi internetowe i mobilne,
•
usªugi gromadzenia i przetwarzania danych (bazy danych, big data),
•
usªugi multimedialne (np. streaming video),
•
obliczenia naukowe.
Ka»da klasa usªug charakteryzuje si¦ innym zapotrzebowaniem na zasoby
sprz¦towe takie jak moc obliczeniowa procesorów, rozmiar pami¦ci czy te» pasmo dost¦pu do sieci. Zaªo»eniem technologii budowanej w oparciu o komponent
rekomendacji jest identykacja takich klas, a nast¦pnie stworzenie modeli obliczeniowych opisuj¡cych ka»d¡ z nich. Modele te maj¡ pozwoli¢ na algorytmiczne
okre±lanie charakterystyki obci¡»enia w¦zªów obliczeniowych chmury generowanego przez usªugi z danej klasy. Podstaw¡ dla dziaªania komponentu rekomendacji b¦d¡ dwa rodzaje modeli: model w¦zªa obliczeniowego i modele klas usªug.
Model w¦zªa, typu biaªa skrzynka (ang. white box), b¦dzie uwzgl¦dniaª szczegóªy budowy wewn¦trznej w¦zªa, takie jak architektura, parametry techniczne
i sposób wspóªpracy poszczególnych elementów sprz¦towych. Model obejmowaª
b¦dzie przede wszystkim charakterystyki uniwersalnych, niespecjalizowanych zasobów sprz¦towych (podstawowych komponentów sprz¦towych w¦zªa chmury
obliczeniowej), takie jak:
•
liczba i moc obliczeniowa zainstalowanych procesorów,
•
rodzaj i rozmiar pami¦ci podr¦cznej (ang. cache) ka»dego procesora,
•
rozmiar i przepustowo±¢ pami¦ci operacyjnej,
•
pr¦dko±¢ zapisu i odczytu danych zarchiwizowanych w zainstalowanej pami¦ci masowej (np. macierzy dysków),
•
maksymalna przepustowo±¢ dost¦pnego interfejsu sieciowego.
Dodatkowo uwzgl¦dniona zostanie tak»e mo»liwo±¢ wykorzystywania przez
w¦zeª opcjonalnych komponentów, tj. specjalizowanych akceleratorów sprz¦towych, takich jak moduªy szyfruj¡ce, sprz¦towe dekodery multimedialne czy karty
GPGPU (ang. General-Purpose Graphics Processing Units). Dla ka»dej z wyró»nionych klas usªug zostanie przygotowany opisuj¡cy j¡ model obliczeniowy. B¦d¡
to modele typu okre±lanego jako tzw. szara skrzynka (ang. gray box): szczegóªowe procedury dziaªania konkretnych usªug s¡ niemo»liwe do dokªadnego
7
okre±lenia i przeanalizowania, jednak usªugi nale»¡ce do jednej klasy b¦d¡ charakteryzowaªy si¦ pewnymi wspólnymi cechami i parametrami, pozwalaj¡cymi
na zamodelowanie cyklu ich dziaªania. Gªówn¡ funkcj¡ modeli obliczeniowych
usªug b¦dzie okre±lenie przewidywanego obci¡»enia generowanego przez usªugi w
dziedzinie zidentykowanych charakterystyk w¦zªa. Przez obci¡»enie rozumiany
jest stopie« wykorzystania poszczególnych zasobów sprz¦towych przez dziaªaj¡c¡ na w¦¹le usªug¦. Do skªadowych obci¡»enia mo»na zaliczy¢ na przykªad:
•
czas procesora wykorzystywany na obsªug¦ dziaªania usªugi,
•
intensywno±¢ wykorzystania pami¦ci podr¦cznej procesora,
•
rozmiar pami¦ci operacyjnej wykorzystywanej przez usªug¦ i intensywno±¢
dost¦pu do niej,
•
ilo±¢ danych odczytywanych i zapisywanych z/do pami¦ci masowej w jednostce czasu,
•
ilo±¢ danych transmitowanych przez usªug¦ poprzez interfejs sieciowy.
Obci¡»enie komponentów sprz¦towych generowane przez ró»ne typy opera-
?
cji/usªug mo»e by¢ symulowane przy pomocy tzw. benchmarków [ ], [3], [4], [5], [6].
Proponowane benchmarki s¡ przeznaczone dla klastrów obliczeniowych, jednak z
uwagi na modelowanie i monitorowanie pojedynczych w¦zªów zostan¡ one u»yte
do symulowania obci¡»enia w w¦zªach chmury obliczeniowej. Dodatkowo, zakªada si¦ równie» mo»liwo±¢ ª¡czenia i wspóªpracy przygotowanych modeli. Pozwoli to komponentowi rekomendacji na przewidywanie obci¡»enia komponentów sprz¦towych generowanych przez usªugi o zªo»onej charakterystyce, ª¡cz¡cej
cechy kilku wyró»nionych i zamodelowanych klas podstawowych. Docelowo, proces wykorzystania przygotowanych modeli b¦dzie przebiegaª w nast¦puj¡cych
krokach (Rys. 4):
1. Zgªoszenie przez u»ytkownika ch¦ci uruchomienia nowej usªugi (o znanej
charakterystyce) w ±rodowisku chmury obliczeniowej.
2. Wybranie klasy, do której nale»y dana usªuga, np. baza danych.
3. Okre±lenie parametrów wej±ciowych modelu wybranej klasy, np. maksymalna liczba u»ytkowników, rozmiar skªadowanych danych.
4. Na podstawie modelu klasy, wprowadzonych parametrów i modelu w¦zªa
obliczeniowego, obliczane jest przewidywane zapotrzebowanie na zasoby
sprz¦towe. Dane te mog¡ zosta¢ wykorzystane przez system zarz¡dzaj¡cy
heterogeniczn¡ chmur¡ do wyboru odpowiedniego w¦zªa dla uruchomienia
zgªoszonej przez u»ytkownika usªugi.
8
Rysunek 4: Koncepcja estymacji obci¡»enia w¦zªów chmury przez usªugi przy
wykorzystaniu modeli usªug
4 Koncepcja klasykacji
Kolejnym elementem skªadowym komponentu rekomendacji rozszerzaj¡cym funkcjonalno±¢ przygotowanych modeli b¦dzie algorytm automatycznej klasykacji
nowych usªug o nieznanej charakterystyce. Scenariusz takiego wykorzystania
modeli, przedstawiony na Rys. 5, skªada si¦ z nast¦puj¡cych kroków:
1. Zgªoszenie przez u»ytkownika ch¦ci uruchomienia nowej usªugi (o nieznanej charakterystyce) w ±rodowisku chmury obliczeniowej.
2. Uruchomienie usªugi i pomiar generowanego przez ni¡ obci¡»enia komponentów sprz¦towych.
3. Porównanie wyników pomiarów z dost¦pnymi modelami teoretycznymi.
4. Wybranie modelu najlepiej opisuj¡cego wymagania sprz¦towe usªugi i przypisanie jej do odpowiedniej klasy.
Przy nast¦pnych uruchomieniach usªugi, system zarz¡dzaj¡cy chmur¡ obliczeniow¡ b¦dzie mógª dokona¢ przydziaªu odpowiedniego w¦zªa wedªug procedury przewidzianej dla usªug o znanej charakterystyce.
9
Rysunek 5: Koncepcja automatycznej klasykacji usªug przy wykorzystaniu modeli
Ze wzgl¦du na ró»norodno±¢ i zªo»ono±¢ usªug wykorzystywanych w chmurach obliczeniowych, dokªadne wyznaczenie zapotrzebowania na zasoby sprz¦towe przy pomocy modelu mo»e by¢ niekiedy bardzo utrudnione. Nawet usªugi
oferuj¡ce podobny zbiór funkcjonalno±ci mog¡ generowa¢ inne warto±ci obci¡»enia w¦zªa obliczeniowego, ze wzgl¦du na ukryte ró»nice w ich wewn¦trznej implementacji. Z tego powodu opracowane modele usªug zostan¡ uzupeªnione o przygotowany w tym celu algorytm kalibracji. Proces kalibracji przeprowadzany b¦dzie na zasadzie sprz¦»enia zwrotnego mi¦dzy kolejnymi uruchomieniami usªugi
a odpowiadaj¡cym jej modelem (patrz Rys. 6). Podczas dziaªania usªugi, system
zarz¡dzaj¡cy chmur¡ obliczeniow¡ b¦dzie na bie»¡co dokonywaª pomiarów obci¡»enia zasobów sprz¦towych odpowiedniego w¦zªa. Zmierzone warto±ci b¦d¡
nast¦pnie porównywane z wielko±ciami oszacowanymi przy u»yciu modelu. W
przypadku rozbie»no±ci, algorytm dokona kalibracji wewn¦trznych parametrów
modelu, tak, aby polepszy¢ jako±¢ predykcji obci¡»enia przy kolejnych uruchomieniach usªugi. Kalibracja b¦dzie mogªa przebiega¢ na dwóch poziomach:
1. kalibracja indywidualna korekta parametrów modelu przeprowadzona
zostanie tylko dla jednej, konkretnej usªugi, której charakterystyka obci¡»enia odbiega znacz¡co od charakterystyk typowych usªug z danej klasy,
2. kalibracja uniwersalna je±li zauwa»one zostan¡ ogólne rozbie»no±ci mi¦dzy modelem teoretycznym a du»¡ liczb¡ usªug rzeczywistych, korekta
parametrów modelu dotyczy¢ b¦dzie wszystkich usªug z danej klasy.
10
Rysunek 6: Koncepcja kalibracji modeli usªug w komponencie rekomendacji
Dzi¦ki metodom klasykacji uruchamianych usªug w poª¡czeniu z modelowaniem klas oraz automatyczn¡ klasykacj¡ i kalibracj¡ w oparciu o monitorowanie
bie»¡ce obci¡»enie w¦zªów obliczeniowych chmury, mo»liwe b¦dzie lepsze wykorzystanie dost¦pnych zasobów sprz¦towych i optymalizacja zu»ycia energii, przy
jednoczesnym zagwarantowaniu jako±ci ±wiadczonych usªug.
5 Przyj¦ta metodyka bada«
Rys. 7 przedstawia kolejne etapy przyj¦tej metodyki badawczej wraz z zadaniami. W pierwszym etapie konieczne jest wyspecykowanie wymaga« dotycz¡cych opracowywanej technologii. Spo±ród usªug uruchamianych w chmurach
obliczeniowych zostan¡ wyró»nione klasy o podobnym zapotrzebowaniu na zasoby sprz¦towe. Podstaw¡ przeprowadzenia tej klasykacji b¦d¡ dane pozyskane
z produkcyjnych i testowych ±rodowisk chmur obliczeniowych, np. z chmury
wykorzystywanej przez rm¦ Intel Technology Poland czy klastra znajduj¡cego
si¦ w Centrum Informatycznym TASK. Nast¦pnie zostan¡ opracowane modele
obliczeniowe, pozwalaj¡ce klasykowa¢ usªugi uruchamiane na maszynach wirtualnych oraz ucz¡ce si¦ i klasykuj¡ce nieznany dot¡d rodzaj obci¡»enia do
danej klasy. Dzi¦ki mo»liwo±ci automatycznej kalibracji, modele te b¦d¡ mogªy
dostosowywa¢ si¦ zarówno do cech poszczególnych usªug, jak i te» do potencjalnych przyszªych zmian w charakterystykach obci¡»enia generowanego przez
nowe usªugi. Przygotowane zostanie laboratorium chmury obliczeniowej, które
pozwoli na prowadzenie prac i eksperymentów w trakcie trwania Projektu.
Kolejnym krokiem b¦dzie przygotowanie prototypu komponentu rekomendacji. Zostanie tak»e opracowana metodyka jego werykacji w zastosowaniach
biznesowych, poprzez naªo»enie na opracowane modele klas usªug stosowane w
praktyce. Po serii eksperymentów i dopracowaniu modeli obliczeniowych b¦-
11
dzie mo»na przyst¡pi¢ do testów zarówno w ±rodowisku laboratoryjnym, jak
i uwzgl¦dniaj¡cym aspekty i usªugi biznesowe. Po fazie optymalizacji modeli
nast¡pi¡ testy systemowe kªad¡ce szczególny nacisk na normy oceny jako±ci
oprogramowania.
Rysunek 7: Schemat przyj¦tej metodyki badawczej. Zadania: zielony Politechnika Gda«ska, niebieski Intel Technology Poland
Gªównym celem eksperymentów b¦dzie sprawdzenie poprawno±ci dziaªania
globalnego komponentu logicznego systemu tj. opracowanej klasykacji, zwi¡zanej bezpo±rednio z systemem a nie indywidualn¡ usªug¡ uruchamian¡ w obr¦bie
chmury obliczeniowej. Klasykacja na podstawie parametrów ruchu przychodz¡cego i danych z monitoringu b¦dzie okre±laªa przydziaª usªugi do danej klasy
usªug. Nast¦pnie skategoryzowana usªuga b¦dzie przeznaczane do wykonania
w chmurze obliczeniowej, gdzie b¦d¡ zbierane rzeczywiste dane, które ponownie tra¡ do moduªu klasykacji usªug pozwalaj¡c na dostrojenie pracy systemu. Walidacja tego elementu sytemu b¦dzie polegaªa na okre±leniu klas usªug,
które b¦d¡ wspierane przez komponent rekomendacji (np. baza danych, serwer
HTTP), a nast¦pnie wybór konkretnych usªug w ramach tych klas (np. MySQL,
Apache). Nast¦pnie konkretne usªugi b¦d¡ ponownie uruchamiane w ±rodowisku
chmury obliczeniowej.
Pomiarom podlega¢ b¦dzie stopie« skorelowania rekomendacji dostarczanej
12
przez model z rzeczywistym wykorzystaniem zasobów sprz¦towych raportowanym przez system monitoruj¡cy chmur¦ obliczeniow¡. Innymi sªowy model obliczeniowy dostarczaj¡c rekomendacj¦ b¦dzie estymowaª, »e do wykonania zadania b¦dzie potrzebna okre±lona ilo±¢ zasobów sprz¦towych i ta warto±¢ b¦dzie
porównywana z warto±ciami odczytanymi ze stanu systemu (chmury obliczeniowej) w momencie przetwarzania zadania, czyli z ilo±ci¡ zu»ywanych zasobów
sprz¦towych.
Docelow¡ architektur¡, na której b¦dzie bazowaª Projekt, b¦dzie architektura Romley (nazwa kodowa dla platform wieloprocesorowych serwerów w latach
2010/2011). Architektura skªada si¦ z procesorów Sandy Bridge (dwu- lub czterordzeniowych znanych równie» jako procesory Jaketown) oraz chipsetów Patsburg lub Cougar Point. Przewiduje si¦ równie» kompatybilno±¢ wsteczn¡ z architektur¡ Stoutland (platforma dla rynku wieloprocesorowych serwerów 2009)
opart¡ o procesory z rodziny Beckton i Eagleton (maksymalnie do 4 procesorów)
i chipsetów Boxboro. Dodatkowo technologia b¦dzie mo»liwa do zastosowania
z now¡ wieloprocesorow¡ architektur¡ serwerow¡ Grantley (przewidywany rok
pojawienia si¦ na rynku 2015). B¦dzie ona oparta o procesory z rodziny Haswell i Broadwell oraz chipsety Wellsburg. Poniewa» podczas trwania Projektu
u»ywane b¦d¡ nowatorskie rozwi¡zania sprz¦towe niedost¦pne jeszcze na rynku
globalnym i w zwi¡zku z ograniczeniami co do udost¦pniania tej technologii, ±rodowisko testowe zostanie zorganizowane przez rm¦ Intel Technology Poland.
Nast¦pnie ±rodowisko to zostanie udost¦pnione partnerowi naukowemu i przez
czas trwania fazy A b¦dzie zarz¡dzane przez partnera biznesowego.
Literatura
[1] Lenk A., Klems M., Nimis J., Tai S., Sandholm T.,
An architectural map of the Cloud landscape.
What's inside the Cloud?
, In Proceedings of the 2009
ICSE Workshop on Software Engineering Challenges of Cloud Computing
(CLOUD '09). IEEE Computer Society, Washington, DC, USA, 23-31.
[2] Armbrust M., Fox A., Grith R., Joseph A.D., Katz R., Konwinski A.,
Lee G., Patterson D., Rabkin A., Stoica I., Zaharia M. (2009), ,
the Clouds: A Berkeley View of Cloud Computing
Above
Technical Report No.
UCB/EECS-2009-28, Electrical Engineering and Computer Sciences, University of California at Berkeley, USA.
[3] IBM, dbench,
[4] Transaction
http://pic.dhe.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=%2Fliaag%2Fjournaling
Processing
http://www.tpc.org/tpcc/
Performance
Council
(TPC),
TPC-C, San Francisco, CA, USA.
[5] Standard Performance Evaluation Company (SPEC), SPEC's Benchmarks
and Published Results,
http://www.spec.org/benchmarks.html
VA.
13
Gainesville,
[6] Cooper B.F., Silberstein A., Tam E., Ramakrishnan R., Sears R. (2010),
Benchmarking cloud serving systems with YCSB
Proceedings of the 1st
ACM symposium on Cloud computing (SoCC '10), ACM, New York, NY,
USA, 143-154.
[7] VMware,
Scheduler
Inc.,
(DRS),
VMware
vSphere:
Distributed
Power
Distributed
Resources
Management
(DPM)
http://www.vmware.com/products/datacenter-virtualization/vsphere/drsdpm.html
[8] Hewlett-Packard
Company,
HP
Service
He-
http://www8.hp.com/us/en/softwaresolutions/software.html?compURI=1173036# .Uej2xW1c1nU
alth
Optimizer,
Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment Journal of the Association for
[9] Liu C. L., Layland J.W. (1973),
Computing Machinery, vol. 20(1), ACM, New York, NY, USA, 46-61
[10] Deji Chen, Mok A. K., Tei-Wei Kuo (2003),
Utilization bound revisited
IEEE Transactions on Computers, vol. 52(3), IEEE Computer Society, 351361.
Utilization Bounds for EDF
Scheduling on Real-Time Multiprocessor Systems Real-Time Syst. 28, 1,
[11] López J. M., Díaz J. L., García D. F. (2004),
Kluwer Academic Publishers Norwell, MA, USA, 39-68.
Cluster scheduling for real-time systems:
utilization bounds and run-time overhead Real-Time Systems, vol. 47(3),
[12] Qi X., Zhu D., Aydin H., (2011),
Kluwer Academic Publishers Norwell, MA, USA, 253-284.
[13] Snavely A., Carrington L., Wolter N., Labarta J., Badia R., Purkayastha A.
(2002),
A framework for performance modeling and prediction
Proceedings
of the 2002 ACM/IEEE conference on Supercomputing (Supercomputing
'02), IEEE Computer Society Press, Los Alamitos, CA, USA, 1-17.
Rooine: an insightful
visual performance model for multicore architectures Communications of
[14] Williams S., Waterman A., Patterson D. (2009),
the ACM, vol. 52(4), ACM New York, NY, USA, 65-76.
A genetic algorithms approach to modeling the performance of memory-bound computations Proceedings of the 2007 ACM/IEEE conference on Supercomputing
[15] Tikir M., Carrington L., Strohmaier E., Snavely A. (2007),
(SC '07), ACM, New York, NY, USA.
[16] Witkowski M., Oleksiak A., Piontek T., W¦glarz J. (2013),
consumption estimation for real life HPC applications
Computer Systems, vol. 29(1), 208-217
14
Practical power
Future Generation
[17] Esmaeilzadeh H., Blem E., St. Amant R., Sankaralingam K., Burger D
(2012),
core
Power Limitations and Dark Silicon Challenge the Future of Multi-
ACM Transactions on Computer Systems, vol. 30(3), ACM New York,
NY, USA.
[18] Valiant L.G. (2008),
A Bridging Model for Multi-core Computing
Proce-
edings of the 16th annual European symposium on Algorithms (ESA '08),
Dan Halperin and Kurt Mehlhorn (Eds.), Springer-Verlag, Berlin, Heidelberg, 13-28.
Ecient provisioning of bursty scientic workloads on the cloud using adaptive elasticity
control Proceedings of the 3rd workshop on Scientic Cloud Computing
[19] Ali-Eldin A., Kihl M., Tordsson J., Elmroth E. (2012) ,
Date (ScienceCloud '12), ACM, New York, NY, USA, 31-40.
[20] Krampe A., Lepping J., Sieben W. (2010),
for workload on parallel computers
A hybrid Markov chain model
In Proceedings of the 19th ACM Inter-
national Symposium on High Performance Distributed Computing (HPDC
'10). ACM, New York, NY, USA, 589-596.
Empirical prediction models
for adaptive resource provisioning in the cloud Future Generation Compu-
[21] Islam S., Keung J., Lee K., Liu A. (2012),
ter Systems vol. 28(1), Elsevier Science Publishers B. V. Amsterdam, The
Netherlands, 155-162.
Automated
control for elastic n-tier workloads based on empirical modeling Proceedings
[22] Malkowski S.J., Hedwig M., Li J., Pu C., Neumann D. (2011),
of the 8th ACM international conference on Autonomic computing (ICAC
'11), ACM, New York, NY, USA, 131-140.
PRESS: PRedictive Elastic ReSource Scaling for cloud systems 2010 International Conference on Network
[23] Zhenhuan G., Xiaohui G., Wilkes J. (2010),
and Service Management (CNSM), Niagara Falls, ON, USA, 9-16.
[24] Ganapathi A., Yanpei Chen, Fox A., Katz R., Patterson D. (2010),
Statistics-driven workload modeling for the Cloud
2010 IEEE 26th Interna-
tional Conference on Data Engineering Workshops (ICDEW), Long Beach,
CA, USA,87-92.
[25] Kousiouris G., Menychtas A., Kyriazis D., Gogouvitis S., Varvarigou T.
Dynamic, behavioral-based estimation of resource provisioning based on high-level application terms in Cloud platforms Future Generation
(2012),
Computer Systems, Elsevier Science Publishers B. V. Amsterdam, The Netherlands
On the use of hybrid
reinforcement learning for autonomic resource allocation Cluster Compu-
[26] Tesauro G., Jong N.K., Das R., Bennani M.N. (2007),
ting vol. 10(3), Kluwer Academic Publishers Hingham, MA, USA, 287-299.
15
[27] Tang W., Fu Y., Cherkasova L., Vahdat A. (2007),
ting realistic streaming media server workloads
Modeling and genera-
Computer Networks: The
International Journal of Computer and Telecommunications Networking,
vol. 51(1), Elsevier North-Holland, Inc., New York, NY, USA, 336-356.
A workload prediction model for
decoding mpeg video and its application to workload-scalable transcoding
[28] Huang Y., Tran A.V., Wang Y. (2007),
Proceedings of the 15th international conference on Multimedia (MULTIMEDIA '07), ACM, New York, NY, USA, 952-961.
[29] Singhera Z. U. (2008),
systems
A workload model for topic-based publish/subscribe
Companion to the 23rd ACM SIGPLAN conference on Object-
oriented programming systems languages and applications (OOPSLA Companion '08), ACM, New York, NY, USA, 703-712.
A Co-Plot analysis of logs and
models of parallel workloads. ACM Transactions on Modeling and Compu-
[30] Talby D., Feitelson D. G., Raveh A. (2007),
ter Simulation, vol. 17(3), ACM New York, NY, USA.
Towards characterizing cloud backend workloads: insights from Google compute clusters
[31] Mishra A. K., Hellerstein J. L., Cirne W., Das C. R. (2010),
SIGMETRICS Perform. Eval. Rev. 37, 4 (March 2010), 34-41.
Application classication through monitoring and learning of resource consumption patterns In Proceedings of
[32] Zhang J., Figueiredo R. J. (2006),
the 20th international conference on Parallel and distributed processing
(IPDPS'06). IEEE Computer Society, Washington, DC, USA, 144-144.
[33] Chen Y. K., Chhugani J., Dubey, P., Hughes C.J., Kim D., Kumar S., Lee
Convergence of Recognition,
Mining, and Synthesis Workloads and Its Implications. Proceedings of the
V.W., Nguyen A.D., Smelyanskiy M. (2008),
IEEE, vol. 96(5), 790-807.
[34] Raatikainen K. E. E. (1993),
Cluster analysis and workload classication
SIGMETRICS Perform. Eval. Rev. 20, 4, 24-30.
[35] Krawczyk H., Procz J. (2010),
form architecture
KASKADA - Multimedia processing plat-
Proceedings of the 2010 International Conference on Si-
gnal Processing and Multimedia Applications (SIGMAP), 26-31.
Real-Time Multimedia Stream Data Processing in a Supercomputer Environment Interactive Multimedia, Ioannis
[36] Krawczyk H., Procz J. (2012),
Deliyannis (Ed.), InTech.
Prediction of Processor Utilization
for Real-Time Multimedia Stream Processing Tasks Proceedings of 9th In-
[37] Krawczyk H., Procz J., Daca B. (2013),
ternational Conference on Distributed Computing and Internet Technology
ICDCIT 2013, Bhubaneswar, India, 278-289.
16
Zarz¡dzanie zasobami obliczeniowymi w klastrowym ±rodowisku przetwarzania strumieni multimedialnych Katedra Architektury
[38] Procz J. (2012),
Systemów Komputerowych, Politechnika Gda«ska.
17