Eucalyptus System for Clouds Andrzej Szczepański http://fatcat.ftj.agh.edu.pl/ i7szczep/koala.pdf R3IS2 1 Wstęp Streszczenie Cloud Computing, czyli przetwarzanie chmurowe, umożliwia udostępnianie dużych ilości danych i zasobów obliczeniowych poprzez elastyczne systemy oparte o podobny schemat działania jak popularne w High Performance Computing systemy gridowe. Idea ta mocno zyskała na popularności w przeciągu kilku ostatnich lat, a oparte na niej usługi biznesowe odniosły komercyjny sukces. Obecnie większość z systemów tego rodzaju jest własnościowa. Posiadając zamknięte źródła i nieprzejrzystą strukturę nie są one dostosowane do zastosowań akademickich. Niniejszy dokument opisuje projekt frameworku open source EUCA- LYPTUS, który stanowi odpowiedź na wspomnianą niedogodność. Przedstawione zostaną elementy składające się na architekturę systemu i sposób w jaki zaimplementowano doktrynę IaaS (infrastruktura jako usługa). Zaznaczona zostanie rola jaką projekt EUCALYPTUS zamierza osiągnąć, poprzez porównanie z istniejącymi rozwiązaniami chmurowymi i gridowymi. Postęp prac rozwojowych EUCALYPTUS a można prześledzić instalując system chociażby na pojedynczej stacji roboczej PC i/lub łącząc się z publiczną chmurą udostępnianą i zarządzaną przez twórców systemu. Kroki, które należy w tym celu uczynić przedstawione będą na końcu prezentacji. Ostanie lata przyniosły wzrost zainteresowania usługami współdzielenia zasobów dużych systemów obliczeniowych i przechowujących dane. Dużą rolę odgrywa w tym przypadku kierunek w jakim rozwija się tzw. High Performance Computing. Na całym świecie powstają systemy Gridowe łączące zasoby będące pod kontrolą różnych domen w jeden potężny system umożliwiający dostarczanie usług obliczeniowych odpowiedniej jakości. Przetwarzanie chmurowe(cloud Computing) idzie krok dalej udostępniając zasoby na życzenie, celując w maksymalną elastyczność i prostotę obsługi dla klienta.([2]) W przetwarzaniu chmurowym jako usługę nie oferuje się samego oprogramowania czy platform programistycznych lecz całą infrastrukturę umożliwiając użytkownikom tworzenie instancji maszyn wirtualnych o wybranych przez siebie parametrach. Uwalnia to użytkownika z problemu radzenia sobie ze zróżnicowanymi zasobami uzyskanymi z różnych źródeł i stanowi fundament na którym usługi wyższego poziomu, jak wspomniane SaaS czy PaaS, mogą być budowane.
Pionierskie systemy takie jak Amazon EC2 zdążyły już odnieść sukces komercyjny([2]) i wszystko wskazuje, że popyt na tego rodzaju usługi będzie wzrastał, gdyż umożliwiają one znaczące oszczędności dla wielu firm które chcą przeprowadzić outsourcing swoich systemów informatycznych. Sukcesy komercyjne nie czynią jednak tego typu rozwiązań atrakcyjnymi dla zastosowań naukowych i akademickich ponieważ zamknięte źródła i niedostępne infrastruktury przodujących obecnie systemów nie dają wystarczającej wolności modyfikacji i eksperymentowania. Istnieje kilka wolnych projektów takich jak np. Usher, Enomalism, Virtual Workspaces, Cluster On Demand czy Virt. Nie posiadają one jednak wystarczającej funkcjonalności i uniwersalności. Aby wypełnić powstałą niszę powstało Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems (EUCALYPTUS). Twórcy przedstawiają w ten sposób swoje odpowiedzi na pytania, które pojawiają się mimowolnie gdy rozpatrujemy ideę Cloud Computnigu: Jaka jest odpowiednia architektura dla systemu? Jakie maszyny wirtualne powinne być tworzone? Jak izolować sesje w sieciach wirtualnych aby zapewnić wystarczającą elastyczność, osiągi i bezpieczeństwo? 2 Budowa Założenia projektowe EUCALYPTUSa, będące jednocześnie uzasadnieniem kreacji kolejnego, po wspomnianych, otwartego frameworku chmurowego opierały się na kilku ważnych elementach. Po pierwsze, EUCALYPTUS od początku pomyślany był jako prosty w instalacji i tak mało inwazyjny jak to tylko możliwe. Łatwo i wygodnie powinno się pracować klientom. Zarządzanie systemem również miało być uproszczone zgodnie z zasadą administrator też człowiek. Po drugie, modułowa budowa systemu ma zwiększyć jego uniwersalność i dać możliwość na rosnącą wraz z rozwojem projektu funkcjonalność. Planowane jest np. wspieranie wielu interfejsów klienckich oraz wielu systemów kontroli maszyn wirtualnych(vm hypervisor). EUCALYPTUS od najwcześniejszych stadiów był planowany jako wykorzystujący API systemu Amazon EC2. Zostało ono wybrane ze względu na największy sukces komercyjny Amazona, jego popularność, dostępność wielu narzędzi i prostotę obsługi. W przyszłości planuje się włączenie obsługi innych interfejsów. Na koniec, EUCALYPTUS posiada własne podejście do problemu sieci VPN,
które w założeniu mają być bardzo elastyczne i jednocześnie bezpieczne. Architektura systemu opiera się na hierarchii popularnej wśród obecnie istniejących struktur akademickich([1]). Cztery główne komponenty posiadają własne interfejsy typu Web Service. Plusy takiego rozwiązania to wspomniana modułowość. Każda z usług sieciowych posiada dokładnie określone za pomocą plików WSDL komendy i postacie zwracanych wartości. Wspomniane komponenty to: kontroler węzła(node controller - NC), kontroler klastra(cluster controller - CC), kontroler magazynowania(storage controller/walrus) i kontroler chmury(cloud controler - CLC). Każdy komponent posiada swoje miejsce w hierarchii i reprezentacji fizycznej systemu, zakres odpowiedzialności oraz zestaw realizowanych poleceń.
2.1 Kontroler węzła Kontroler węzła (NC) jest uruchamiany na każdej jednostce przeznaczonej do uruchamiania instancji maszyny wirtualnej. Jego zwierzchnikiem jest kontroler klastra, który może wydawać komendy typu runinstance czy terminateinstance. Kontroler węzła sprawdza autoryzację odgórnych poleceń i w przypadku zgodności kontaktuje się z nadzorcą VM Xen(obecnie jedyny wspierany) aby je wykonać. Wcześniej NC uzyskuje od węzła informacje na temat dostępnej liczby zasobów: rdzenie, pamięć itd. a także o stanie w jakim znajdują się utworzone wcześniej instancje VM. 2.2 Kontroler klastra Kontroler klastra(cc) może być uruchamiany na każdej maszynie mającej połączenie zarówno z węzłami z działającymi NC jak i z maszyną, na której działa kontroler chmury. CC ma trzy główne zadania. Rozdzielanie przychodzących zapytań o zasoby pomiędzy kontrolowane NC. Kontrolowanie utworzonych sieci
wirtualnych VPN. Zbieranie informacji o podporządkowanych węzłach. CC może dostać od kontrolera chmury zestaw instancji, które mają zostać uruchomione. Wówczas CC zapytuje kolejno podporządkowane NC o zasoby zapytaniem describeresources i uzyskawszy pierwszą odpowiedź spełniającą zapotrzebowanie, kieruje tam odpowiednie rozkazy. CLC może też wydać zapytanie o możliwości, wówczas CC oblicza ilość możliwych do utworzenia instancji VM o podanych parametrach dla wszystkich NC i zwraca wynik. 2.3 Kontroler magazynowania Usługa składowania danych Walrus wprowadzona w EUCALYPTUS ie jest interfejsowo kompatybilna z Amazon S3 Simple Storage Service. Obsługuje zapytania HTTP (Query) oraz SOAP. Dane autoryzacyjne użytkowników są współdzielone z kontrolerem chmury. Użytkownik, którego uprawnienia zostały potwierdzone uzyskuje możliwość zapisu i odczytu danych przesyłanych poprzez HTTP. Oprócz przechowywania danych użytkowników, Walrus zajmuje się też przechowywaniem obrazów dysków i ram-dysków maszyn wirtualnych. Ważną cechą Walrusa jest podobnie jak w S3 gwarancja obecności kopii bezpieczeństwa danych, chroniącej przed ich nadpisywaniem przez kilka równoległych procesów. Obrazy składowane przez Walrusa na potrzeby węzłów są szyfrowane.
2.4 Kontroler chmury Zadania pełnione przez CLC można podzielić na 3 rodzaje: Usługi związane z zasobami - ocena alokacji zasobów całego systemu, pozwala użytkownikom manipulować własnościami wirtualnych maszyn i sieci, monitoruje komponenty systemu. usługi związane z danymi - zarządza wykorzystaniem danych użytkowników jak i systemowych. usługi związane z interfejsem - prezentowanie jednego z dostępnych interfejsów, autoryzacja dostępu. 2.5 Sieci wirtualne Jedno z największych wyzwań w projektowaniu systemów chmurowych stanowią sieci wirtualne obsługujące instancje maszyn wirtualnych uruchomione przez użytkowników. Problematyczne jest zapewnienie im możliwości wzajemnego kontaktu. Twórcy EUCALYPTUS a przedsięwzięli następujące 3 wymagania projektowe: konektywność, izolacja i osiągi. Każda maszyna wirtualna powinna mieć połączenie sieciowe z pozostałymi oraz, przynajmniej częściowe, połączenie z internetem. Następuje tu ryzyko komplikacji, gdyż każdy użytkownik posiada prawa super-użytkownika na użytkowanych przez siebie maszynach wirtualnych i ingerując w ich interfejsy sieciowe może zdobyć wiedzę o adresach IP i MAC co pozwoliłoby mu na sabotowanie systemu lub innych(cudzych) maszyn wirtualnych działających na tym samym fizycznym węźle. Rozwiązaniem są sieci wirtualne izolujące od siebie zespoły VM różnych użytkowników. Kontroler klastra tworzy takie sieci korzystając z wybranego przez administratora jednego z trzech możliwych sposobów. W pierwszej konfiguracji interfejsy maszyny wirtualnej są podłączane bezpośrednio do programowego mostu ethernetowego, tak że zapytania DHCP pochodzące z VM są traktowane tak jak z fizycznych komponentów. Druga konfiguracja pozwala administratorowi zdefiniować statyczne sekwencje adresów MAC i IP. Każda nowa instancja dostaje wolny adres z tej puli. W tym trybie niemożliwa jest pełna izolacja, ale za to osiągi sieci są bardzo bliskie do natywnej. W konfiguracji trzeciej EUCALYPTUS w całości zarządza i kontroluje sieci VM zapewniając izolację, filtrowanie(firewalle) i dynamiczne przydzielanie publicznych adresów IP.
3 Porównanie z innymi rozwiązaniami Problem scalenia dużej ilości rozproszonych zasobów obliczeniowych i pamięciowych w jeden system a następnie rozdzielania tychże zasobów według potrzeb zachowując odpowiednią jakość usług(qos) jest rozwiązywany przy pomocy systemów Gridowych, których elementy są wykorzystywane także przez systemy chmurowe. Grid computing i Cloud computing różnią się zasadniczo w podejściu do kilku spraw: Po pierwsze w systemach gridowych zakłada się, że pojedynczy użytkownik będzie pobierał dużą część ze wszystkich dostępnych zasobów. Natomiast w systemach chmurowych często ogranicza się ilość zasobów, o które użytkownik może poprosić do drobnego procenta całej puli. Drugą z najważniejszych różnic jest fakt, że w przypadku gridów jednoczy się rozproszone systemy administrowane przez różne podmioty/domeny. W przypadku chmur, zasoby są również rozproszone, lecz zarządza nimi jedna organizacja lub firma. Warto zwrócić uwagę na różnicę w tym co system informatyczny oferuje jako usługę. Problemy pojawiają się gdy użytkownik w poszukiwaniu odpowiedniej jakości i ilości zasobów kontaktuje się z kilkoma podmiotami oferującymi usługi. Gdy systemy oferują klientowi oprogramowanie lub platformę programistyczną to dostanie on najczęściej od każdego systemu inne zasoby(inny system operacyjny, inna platforma). W takiej sytuacji dużo kłopotu sprawi dostosowanie się do niespójnych warunków. Dlatego pomysł wykorzystania całej infrastruktury jako udostępnianej usługi stanowi bardzo atrakcyjne rozwiązanie. Popularne własnościowe frameworki do cloud computing to: Amazon EC2/S3, Google AppEngine czy Salesforce.com Wspomniany już wcześniej wielokrotnie Amazon EC2 dowiódł swej skuteczności i zebrał pozytywne opinie prostotą obsługi. Powstało wiele narzędzi klienckich wykorzystujących interfejs SOAP tego systemu. Niestety, jak już było powiedziane, komercyjny charakter Amazona czyni go mało atrakcyjnym dla zastosowań badawczych. EUCALYPTUS posiada zaimplementowany interfejs zgodny z Amazonem, co pozwala na używanie tych samych narzędzi. 4 Testowanie Według twórców elastyczność i skalowalność EUCALYPTUS a pozwala na przetestowanie tego systemu poprzez zainstalowanie go nawet na pojedynczej maszynie roboczej(np. laptop). Instrukcje na ten temat, jak i cała dokumentacja
zawarte są na stronie projektu: http://open.eucalyptus.com Niektóre dystrybucje Linuksa posiadają repozytoria z EUCALYPTUS em są to m.in Debian, SuSe i Ubuntu, można więc ominąć kompilowanie ze źródeł. Jako przygotowanie do instalacji należy: 1.Zsynchronizować zegary wszystkich maszyn, które mają należeć do systemu. 2.Udostępnić połączenia między maszynami. Węzły powinny mieć otwarty port 8775 a serwery porty 8443, 8773, 8774. 3.skonfigurować most na komputerze-węźle i ustawić go jako główny interfejs sieciowy. Następnie na odpowiednich maszynach należy zainstalować odpowiednie pakiety: eucalyptus-common; eucalyptus-nc - kontroler węzła; eucalyptus-sc eucalyptus-walrus - storage; eucalyptus-cc - kontroler klastra; eucalyptus-cloud - kontroler chmury; Dalsza praca wymaga skonfigurowania wszystkich elementów tj: 1.Należy zarejestrować komponenty systemu na maszynie z CLC; 2.Należy przeprowadzić konfigurację wstępną przez interfejs przeglądarkowy, zmienić hasło administratora, utworzyć certyfikat; 3.Należy skonfigurować zarządcę maszyn wirtualnych (VM hypervisor), obecnie jest to Xen; 4.Należy skonfigurować sieć ustalając jaki tryb (wspomniane wcześniej) będzie używany; Istnieje prostszy sposób na zapoznanie się z charakterystyką działania systemu, zakładający podejście ze strony klienta. Na stronie https://mayhem9.cs.ucsb.edu:8443/ znajduje się utworzona przez twórców systemu chmura publiczna o dostęp do której może się ubiegać każdy zainteresowany wypełniając prosty formularz. Uzyskawszy konto i klucze można tworzyć i zarządzać swoimi instancjami maszyn wirtualnych korzystając z narzędzi konsolowych euca2ools lub jakichkolwiek dostępnych dla systemu Amazon EC2. Interaktywny interfejs www nie jest na razie dostępny.
Powyżej, panel www użytkownika publicznej chmury UCSB z listą dostępnych obrazów. 5 Podsumowanie Korzystając z dostępnych prezentacji i referatów dotyczących systemu EU- CALYPTUS oraz z możliwości jego przetestowania można odnieść pozytywne wrażenie na temat tego projektu. Mógłby on wypełnić wolną do tej pory niszę w systemach informatycznych dużej skali open source. W oparciu o EUCALYPTU- SA można by tworzyć akademickie systemy obliczeniowe, nadawałby się również
dla zastosowań komercyjnych. EUCALYPTUS zbudowany jest na hierarchii odwzorowującej tą jaką często spotyka się w ośrodkach obliczeniowych, klastrach i farmach serwerów. Posiada unikalne podejście do izolowania pracujących na wspólnych zasobach maszyn wirtualnych, dając jednocześnie swobodę administratorom odnośnie wyglądu sieci wirtualnych. Jeśli rozwój projektu będzie następował zgodnie z planami deweloperów, EUCALYPTUS będzie mógł obsługiwać wiele interfejsów oraz korzystać z maszyn wirtualnych pracujących pod nadzorem Qemu czy VMware(obecnie tylko Xen). Obecnie ciężko byłoby dokonać rzetelnego porównania pomiędzy wydajnością i możliwościami EUCALYPTUS a oraz najważniejszych systemów własnościowych z Amazon EC2 na czele. Projekt zapoczątkowany na Uniwersytecie Santa Barbara wciąż się jednak rozwija i według założeń projektowych ma w pełni dorównywać komercyjnym konkurentom pod względem funkcjonalności oraz przewyższać ich dzięki swojej otwartej i przejrzystej architekturze. W dużym stopniu cele te zostały już osiągnięte. References.The Eucalyptus Open-source Cloud-computing System. Daniel Nurmi, Rich Wolski, Chris Grzegorczyk Graziano Obertelli, Sunil Soman, Lamia Youseff, Dmitrii Zagorodnov 2.Cloud computing versus grid computing. Judith Myerson http://www.ibm.com/developerworks/web/library/wa-cloudgrid/ 3.Slajdy ze spotkania Cloud Computing Group (Listopad 2008). Rich Wolski 4.Materiały dostępne na stronie http://open.eucalyptus.com