Metryki wydajnościowe

Definicje metryk opisujących wydajność rozproszonych środowisk obliczeniowych można podzielić na dwie grupy. Podział ten wynika z uwzględnienia różnych oczekiwań wzglę-dem infrastruktury z poziomu dwóch rozłącznych grup jej użytkowników. I tak parametry związane z czasem przetwarzania aplikacji (7.3), czyli czasem pomiędzy chwilą rozpoczęcia przetwarzania a momentem zakończenia obliczeń (zwrócenia rezultatów), są istotne głów-nie z punktu widzenia użytkowników Gridu. Natomiast parametry określające stopień wykorzystania infrastruktury (7.10) to ważne z punktu widzenia administratora czynniki charakteryzujące właściwości warstwy pośredniej (middleware).

Metryki klasyczne¹³ związane z przetwarzaniem aplikacji

Czas odpowiedzi infrastruktury R_A (7.3) dla aplikacji A (4.24) definiujemy jako różnicę czasów pomiędzy rozpoczęciem przetwarzania aplikacji a momentem jej zakończenia:

RA= ∆T := T_end− T_start (7.3)

W przypadku, gdy przetwarzana aplikacja składa się z kilku uruchomionych niezależ-nie komponentów (4.24) należy rozdzielić czas wykonania całości przetwarzania od czasu wykonania poszczególnych składowych. Czas odpowiedzi (7.4) mierzony jest wtedy jako czas pomiędzy rozpoczęciem wykonywania pierwszego komponentu a czasem zakończenia przetwarzania ostatniego komponentu tej samej aplikacji:

R^(i,j)_A := T^aj

end− T^ai

start i a_i, a_j ∈ A, (7.4) gdzie:

ai — komponent aplikacji A, którego wykonanie zostało rozpo-częte jako pierwsze,

a_j — komponent aplikacji A, który został zakończony jako ostatni, czyli:

R^(i,j)_A = R_A (7.5)

Możemy również określić sumaryczny czas wykonania wszystkich komponentów, który określa jak długo działałaby aplikacja, jeżeli całe jej przetwarzanie byłoby wykonane se-kwencyjnie¹⁴: RA:= ^X ai∈A Rai, gdzie: Rai = ∆T_ai := T^ai end− T^ai start (7.6)

Zysk zrównoleglenia (7.7) to z kolei parametr określający w jakim stopniu możliwe jest skrócenie czasu wykonania aplikacji przy jej współbieżnym wykonaniu:

Z_A:= ^RA

R^(i,j)_A

∗ 100 % (7.7)

Zdefiniowanie i wyznaczenie w/w parametrów pozwoli na oszacowanie właściwości sys-temu zarządzania zasobami widzianych z poziomu użytkowników. Parametry te opisują o ile zmieni się czas wykonania aplikacji w zależności od przyjętych parametrów pracy algorytmów zarządzania zasobami.

13

Proponowane w tej sekcji metryki odnoszą się do klasycznej interpretacji infrastruktury Grid, czyli nie uwzględniają wpływu żadnych technik związanych z wirtualizacją infrastruktury. Odniesienie do środowi-ska, w którym zasoby są wirtualizowane, wprowadzają metryki wydajnościowe zaproponowane w dalszej części sekcji.

14

Metryki obciążenia infrastruktury

Obciążenie infrastruktury, czyli efektywne wykorzystanie dostępnych zasobów jest kolej-nym istotkolej-nym parametrem. Parametr ten określa stopień wykorzystania infrastruktury lub ile jest jeszcze niewykorzystanej np. mocy obliczeniowej czy dostępnej przepustowości sieciowej.

Dla aplikacji A (4.24) składającej się z niezależnych komponentów uruchomionych w obrębie zbioru fizycznych maszyn PH (4.1) określamy następujące parametry¹⁵:

E^(cj)

ai — efektywny czas procesora c_j zużyty dla wykonania pojedyn-czego komponentu a_i aplikacji A,

p(h_k) — zbiór procesorów dostępnych w obrębie fizycznego węzła h_k,

h(ai) — funkcja (7.8) zwracająca fizyczny węzeł, na którym jest uru-chomiony komponent a_i.

h : A → PH,

h(a_i) := {h_j ∈ PH : a_i jest przetwarzane przez h_j} (7.8)

Wykorzystanie pojedynczego węzła h przez aplikację A określamy zatem jako:

u(h, A) :=

P

ai∈A^Pcj∈p(h)E^(cj)

ai

R_A ^{, (7.9)}

a współczynnik wykorzystania całej dostępnej infrastruktury PH przez aplikację A zosta-nie określony następująco:

U (PH, A) :=

P

hk∈PHu(hk, A)

#PH , (7.10)

gdzie:

#PH — liczba elementów zbioru PH (liczba dostępnych fizycznych węzłów).

Współczynnik ten możemy również obliczyć biorąc pod uwagę jedynie obciążenie węzłów wykorzystywanych przez aplikację. Parametr ten (7.11) będzie mógł lepiej charakteryzo-wać obciążenie generowane przez aplikacje, które nie korzystają z wszystkich dostępnych zasobów infrastruktury. U⁰(PH, A) := P hk∈H(A)u(hk, A) #H(A) , (7.11) gdzie: 15

„Czas efektywny” rozumiany jest jako czas procesora przydzielony przez system operacyjny do obsługi aplikacji jedynie w tzw. trybie użytkownika. Wartość ta nie uwzględnia czasu spędzonego przez procesor w trybie systemowym, czyli czasu poświęconego na obsługę przez system operacyjny zdarzeń generowanych przez aplikację.

H(A) — funkcja (7.12) zwracająca zbiór fizycznych węzłów h_k, które używane są podczas wykonania aplikacji A,

#H(A) — liczba elementów zbioru H(A) (liczba węzłów fizycznych używanych przez aplikację A).

H : A → 2^PH, H(A) :=    [ ai∈A h(a_i)    (7.12)

Analogicznie do obciążenia zasobów obliczeniowych, możemy zdefiniować zestaw para-metrów określających wykorzystanie infrastruktury komunikacyjnej. Dla aplikacji A na-leży określić zbiór jednokierunkowych transmisji sieciowych¹⁶ FA (7.13) poszczególnych jej komponentów a_i, czyli:

F_A:= {f_i,j : a_i i a_j komunikowały się ∧ a_i, a_j ∈ A ∧ h(a_i) 6= h(a_j)} , (7.13) gdzie:

fi,j — element oznaczający jednokierunkową komunikację kompo-nentów a_i oraz a_j, dokonaną w trakcie działania aplikacji A. Pasmo zajęte przez komunikację komponentów a_i i a_j określamy zatem następująco:

B_i,j := ^{b(fi,j) + b(fj,i)}

R_A ^{dla: fi,j, fj,i ∈ FA, (7.14)}

gdzie:

b(f_i,j) — liczba bitów informacji przesłanych od komponentu a_i do a_j.

Dla topologii fizycznej PN (7.15), składającej się z zestawu połączeń pomiędzy fizycz-nymi węzłami PH określone zostały następujące funkcje:

p⁽ⁿ⁾(h_i, hj) — funkcja (7.16) zwracająca zbiór połączeń sieciowych dla n-tej ścieżki łączącej fizyczne elementy infrastruktury h_i i h_j, e

b⁽ⁿ⁾(h_i, h_j) — przepustowość (7.17) n-tego połączenia pomiędzy h_i a h_j — czyli przepustowość najwolniejszego odcinka na danej ścieżce,

e

B(h_i, h_j) — efektywna przepustowość (7.18) infrastruktury sieciowej łą-czącej węzły h_i i h_j.

PN ⊆ {l_i,j = (h_i, h_j) : h_i, h_j ∈ PH} (7.15)

p : PH × PH → 2^L,

p⁽ⁿ⁾(h_i, h_j) = {l_m,n : l_m,n∈ n-tej ścieżki pomiędzy h_i a h_j} (7.16)

16Komunikacja sieciowa komponentów aplikacji uruchomionych w obrębie jednego fizycznego węzła nie jest uwzględniana, gdyż nie powoduje ona obciążenia zasobów topologii komunikacyjnej.

eb⁽ⁿ⁾(h_i, h_j) := min lm,n∈p(n)(hi,hj) b(l_m,n) (7.17) e B(hi, hj) := N X n=1 e b⁽ⁿ⁾(h_i, hj) (7.18)

A zatem obciążenie generowane podczas komunikacji dwóch niezależnych komponen-tów aplikacji A będzie ilorazem wykorzystanego pasma i szerokości pasma dostępnego dla komunikacji fizycznych węzłów, na których odbywa się wykonanie tych komponentów.

N_A:= ¹ #F_A X fi,j∈F_A Bfi,j e B(hi, hj) ^oraz ^ ai∈A h_i = h(a_i) (7.19)

Efektywna komunikacja sieciowa przesłana podczas wykonania aplikacji będzie wyra-żona następująco:

X_A:= R_A ^X

fi,j∈F_A

B_fi,j (7.20)

7.2. Ocena zastosowanych technologii

Działanie systemu VGRMS, jego możliwości oraz ograniczenia silnie wynikają z właściwo-ści techniki wirtualizacji, która zastosowana była jako mechanizm umożliwiający regula-cję dostępu do zasobów. Technika parawirtualizacji której implementacja stanowi projekt Xen była głównie testowana [5, 6] pod kątem poziomu wprowadzanego narzutu na wyko-nanie aplikacji uruchomionej w obrębie maszyny wirtualnej Xen. W literaturze tematu, niedostatecznie szczegółowo były przedstawiane aspekty związane z właściwościami mi-gracji, kluczowej zdaniem autora z punktu widzenia możliwości oferowanych przez system VGRMS. Dlatego autor postanowił zamieścić przed wynikami pomiarów działania systemu VGRMS także informacje o możliwościach i narzutach związanych z wykonywaniem pro-cesu przeniesienia wykonania VM pomiędzy dwoma fizycznymi hostami.