Warstwa ekspozycji

Funkcjonalność warstwy wirtualizacji jest na tyle złożona, iż obsługa jej bezpośrednio przez warstwę zarządzania byłaby skomplikowana. Dlatego w projektowanym systemie wyróżniono elementy, które dodane zostały w celu przystosowania i ujednolicenia mecha-nizmów warstwy wirtualizacji, tak aby uprościć interfejs dla realizacji podstawowej funkcji systemu VGRMS jaką jest zarządzanie zasobami. Komponenty te w przedstawionym opisie

zostały umieszczone w warstwie ekspozycji, której nazwa wynika z funkcjonalności jaką jest udostępnienie możliwości wirtualizacji w postaci umożliwiającej realizację zarządzania zasobami.

Do głównych zadań komponentów wchodzących w skład warstwy ekspozycji zalicza się: • umożliwienie zarządzania zasobami poprzez wykorzystanie możliwości

udostępnio-nych przez warstwę wirtualizacji,

• udostępnienie usługi wyszukiwania i lokalizacji zasobów (a dokładniej komponentów systemu VGRMS realizujących zarządzanie zasobami), oraz rejestrację i wyszukiwa-nie pozostałych komponentów,

• monitorowanie poziomu wykorzystania zasobów oraz stanu infrastruktury,

• zarządzanie cyklem życia komponentów należących do pozostałych warstw systemu (takich jak np. komponenty warstwy zarządzania czy prezentacji),

Warstwa ekspozycji jest najbardziej złożoną z wszystkich warstw funkcjonalnych wy-odrębnionych w architekturze systemu VGRMS. Dlatego przedstawienie właściwości kom-ponentów należących do tej warstwy zostało podzielone na następujące komponenty:

• repozytorium agentów — czyli rejestr agentów dostarczający możliwość wyszu-kiwania komponentów systemu VGRMS. Każdy host używany przez system VGRMS musi posiadać uruchomiony komponent AgentVGRMS. Funkcją AgentVGRMS jest reje-stracja referencji do siebie oraz informacji o innych komponentach uruchomionych w obrębie węzła systemu VGRMS.

• komponenty fizycznego węzła — elementy których działanie konieczne jest aby system mógł wykorzystać zasoby hosta,

• komponent obsługi maszyny wirtualnej — element dzięki funkcjonalności któ-rego system może zarządzać instancjami maszyn wirtualnych,

• komponent obsługi wirtualnej sieci — element dzięki funkcjonalności którego system może tworzyć wirtualne topologie sieciowe dla komunikacji wirtualnych ma-szyn.

Repozytorium agentów

W projektowanym systemie zakłada się istnienie repozytorium agentów, z którego klient (czyli dowolny inny komponent systemu) będzie mógł otrzymać informacje o tym na ja-kich fizycznych węzłach zainstalowane zostały komponenty wchodzące w skład VGRMS (zgodnie z zasadą, że jeśli na danym węźle występuje agent VGRMS, to węzeł ten zawiera komponenty budujące system VGRMS). Uzyskana w ten sposób informacja pozwoli na odpytanie węzła o to jakie komponenty zarządzania zostały na nim zainstalowane. Za-letą istnienia repozytorium jest brak potrzeby posiadania wiedzy na temat rozmieszczenia komponentów w danym wirtualnym Gridzie a metoda ich automatycznego wyszukania i lo-kalizacji jest skalowalna. Na rysunku 5.10 przedstawiono kroki jakie klient systemu musi wykonać aby móc korzystać z komponentów VGRMS zainstalowanych na poszczególnych węzłach.

Rysunek 5.10. Proces wyszukiwania komponentów systemu VGRMS

Pożądane jest aby repozytorium agentów było łatwo lokalizowane. Najlepiej jeśli wy-szukiwanie repozytorium odbywać się będzie w sposób dynamiczny, tak aby klienciVGRMS nie byli świadomi miejsca, w którym zostało ono zainstalowane. Dodatkowe cechy jakimi powinno się ono odznaczać to:

• możliwość opisu agenta poprzez dodatkowe atrybuty, wg. których klienci będą mogli przeszukiwać repozytorium. Atrybuty takie będą opisywały właściwości sprzętowe węzła (np. ilość dostępnej pamięci RAM, parametry CPU, liczba kart sieciowych, itp), na którym agent jest uruchomiony. Znajomość tych parametrów pozwoli klientowi na efektywniejsze wyszukanie węzła o zadanych parametrach,

• wsparcie dla notyfikacji o rejestracji bądź wyrejestrowaniu się agenta. Poza prostymi zdarzeniami o tym, że nowy węzeł jest osiągalny (bądź zniknął), w systemie powinna istnieć możliwość definiowania wzorców, które muszą być spełnione aby zdarzenie zostało wygenerowane jeśli dopasowanie do wzorca zostanie spełnione. Zaletą takiej cechy będzie odciążenie klienta od konieczności periodycznego sprawdzania dostęp-ności interesującego go agenta.

Komponenty fizycznego węzła

Rysunek 5.11 przedstawia komponenty składowe warstwy ekspozycji systemu VGRMS uru-chamiane na fizycznych węzłach. Liniami przerywanymi zaznaczono elementy opcjonalne. Na komponenty hosta z warstwy ekspozycji składają się:

Rysunek 5.11. Komponenty składowe warstwy ekspozycji działające na hoście fizycznym w

sys-temie VGRMS

• AgentVGRMS — umożliwia uzyskanie referencji do środowiska VGRMS zainstalowa-nego na danym węźle, przez co klient będzie miał dostęp do pozostałych komponen-tów znajdujących się na danym hoście.

• NodeMaster — odpowiedzialny za zarządzanie tworzeniem i usuwaniem komponen-tów warstwy ekspozycji VM-M i VNetBuilder oraz (opcjonalnych) komponenkomponen-tów war-stwy zarządzania znajdujących się na danym węźle.

• NotificationThread — odpowiedzialny za odbiór zdarzeń z warstwy wirtualizacji i propagowanie ich do odpowiednich komponentów.

• VMChecker — komponent odpowiedzialny za periodyczne sprawdzanie stanu wirtual-nych maszyn na danym węźle fizycznym i ewentualną weryfikację tego stanu z odpo-wiadającymi im komponentami warstwy ekspozycji (czyli sprawdzenie poprawności odwzorowania instancji VM do odpowiadającego jej komponentu ekspozycji). Ist-nienie takiego komponentu podyktowane jest faktem, iż VM mogą być tworzone (usuwane) również narzędziami zewnętrznymi (jak np. za pomocą tekstowej konsoli zarządzania systemu Xen) lub mogą wystąpić sytuacje awaryjne (powodujące usunię-cie VM bez wygenerowania odpowiedniego zdarzenia). W przypadkach tych nie zo-staną dla nich automatycznie stworzone (usunięte) komponenty z warstwy ekspozy-cji, a zatem dodatkowy mechanizm musi wykryć taką sytuację i podjąć odpowiednie działania. Sytuacja taka może również wystąpić gdy zdarzenie pochodzące z warstwy wirtualizacji nie zostanie odebrane przez komponent NotificationThread, dlatego zapewnienie redundantnego sposobu weryfikacji¹² jest tutaj uzasadnione.

12

• VNetBuilder — komponent, którego zadaniem jest tworzenie topologii sieciowej umożliwiającej (najczęściej odseparowaną) komunikację wirtualnych maszyn.¹³ • VM-M — (element opcjonalny) oznacza komponent ekspozycji dedykowany do obsługi

maszyny wirtualnej. Komponent ten występuje na danym węźle fizycznym jedynie w przypadku gdy w jego obrębie działa maszyna wirtualna. Dzięki obecności tego elementu możliwe jest wykonywanie operacji na danej instancji VM w sposób auto-nomiczny przez pozostałe elementy warstwy zarządzania systemu VGRMS.

Zgodnie z rysunkiem 5.11 w skład komponentów zarządzania stanem i konfiguracją fizycznego węzła wchodzą trzy obowiązkowe elementy: NodeMaster, NotificationThread oraz VMChecker. Zależności pomiędzy nimi pokazano na rysunku 5.12.

Rysunek 5.12. Relacje pomiędzy głównymi komponentami zarządzania stanem i konfiguracją

fizycznego węzła

W trakcie inicjalizacji węzła VGRMS14 jest uruchomiony komponent NodeMaster, któ-rego zadaniami, istotnymi z punktu widzenia klienta korzystającego z usług warstwy eks-pozycji, są:

• tworzenie, usuwanie i migracja VM, pobranie aktualnej listy i parametrów wirtual-nych maszyn¹⁵,

• tworzenie i usuwanie komponentów warstwy zarządzania, pobranie aktualnej listy i parametrów komponentów warstwy zarządzania.

Komponenty NotificationThread oraz VMChecker spełniają zadania pomocnicze (omówione na początku sekcji) w stosunku do NodeMaster i mają charakter uzupełniający.

Komponent obsługi maszyny wirtualnej VM-M

Komponent obsługi VM-M jest to komponent powiązany z maszyną wirtualną, który udo-stępnia interfejs, dzięki czemu możliwe jest zdalne wpływanie na stan i parametry VM. mimo przesyłania potwierdzeń komunikacji o zmianach w topologii, występują również pełne okresowe weryfikacje zgodności informacji o stanie połączeń [69].

13

Działanie tego komponentu zostanie przedstawione w dalszej części niniejszej sekcji.

14

Np. podczas startu systemu operacyjnego.

15Operacji tych ze względu na konieczność obsługi propagacji zdarzeń nie może realizować kompo-nent VM-M.

Podstawową funkcjonalnością, której posiadanie wymusiło dodanie tego komponentu jest konieczność dostosowania specyficznego interfejsu zarządzania daną implementacją wirtu-alizacji do sposobu zarządzania wynikającego z przyjętej koncepcji reprezentacji zasobów (obliczeniowych i komunikacyjnych) w systemie VGRMS.

Parametry, których obsługę implementuje komponent zarządzaniaVM można podzielić na dwie grupy:

• parametry obsługiwane przez implementację wirtualizacji — których obsługa przez komponent VM-M jest konieczna ze względu, iż parametry te nie są zachowywane przy operacjach takich jak restart systemu operacyjnego VM czy migracja VM (np. ograniczenia czasu dostępu do procesora lub pamięci),

• parametry i metody specyficzne dla systemu VGRMS — obsługa funkcjonalności koniecznej do realizacji przyjętego dla systemu sposobu regulacji przydziału zasobów (np. typ VM, powiązanie z wirtualnym Gridem).

W funkcjonalności przedstawianego komponentu wymagane są również procedury mo-nitorowania stanu oraz parametrów opisujących konsumpcję zasobów przez daną maszynę wirtualną. Metody te pozwalają na dostęp do takich parametrów jak np. typ danej instan-cji VM, rodzaj i wersja systemu operacyjnego, ilość i obciążenie wirtualnych procesorów w systemie, itp. Parametry te są używane w większości przypadków przez komponenty zarządzania do realizacji polityki przydziału zasobów.

Komponent VNetBuilder

Na potrzeby niniejszego systemu konieczne było opracowanie mechanizmów umożliwiają-cych budowanie i zarządzanie siecią komputerową wirtualnych maszyn. Mechanizm ten obsługiwany jest przez komponent VNetBuilder. Odpowiedzialny on jest za stworzenie (i ewentualne aktualizacje) topologii sieciowej, której opis przechowywany jest przez ele-ment VG-M. Proces ten wymaga modyfikacji parametrów interfejsów sieciowych fizycznych węzłów, dlatego element ten musi być uruchomiony na każdym węźle, którego zasoby są wykorzystywane w wirtualnym Gridzie dla którego tworzona jest topologia sieciowa.

Komponent VNetBuilder odpowiedzialny jest również za modyfikację topologii siecio-wej wirtualnego Gridu. Modyfikacje te mogą wynikać ze zmiany kształtu topologii logicz-nej (modyfikacja przez administratora) lub ze zmiany kształtu topologii fizyczlogicz-nej łączącej fizyczne węzły (np. przez migrację wirtualnych maszyn).

Realizacja funkcjonalności komponentu VNetBuilder opiera się na modyfikacji konfi-guracji mechanizmów sieciowych dla fizycznego hosta. Zmieniana jest konfiguracja zarówno parametrów interfejsów (za pomocą poleceń systemowych) oraz topologia wirtualnej sieci (modyfikacja konfiguracji oprogramowania dokonującego tunelowania, enkapsulacji komu-nikacji wirtualnych maszyn).