Wirtualne serwery na bazie oprogramowania VMware GSX/ESX wspomaganego przez VMware VirtualCenter Dariusz Daniluk <dariusz.daniluk@gmail.com> Warszawa, czerwiec 2006r.
Streszczenie Praca zawiera obszerne wprowadzenie do technologii maszyn wirtualnych, które obejmuje ponad czterdziestoletnią historię ich rozwoju oraz charakteryzuje najnowsze rozwiązania stosowane obecnie przez firmę VMware. Nowe technologie stwarzają dla przedsiębiorstw możliwość obniżenia kosztów utrzymania infrastruktury informatycznej, a także podnoszą jakość świadczonych usług. Obniżenie kosztów możliwe jest dzięki konsolidacji ośrodków przetwarzania danych. Przedstawione badania dokładnie pokazują, jak firmy postrzegają cały proces, jakich dodatkowych korzyści się spodziewają oraz charakteryzują największe obawy związane z konsolidacją. W dalszej części pracy został zawarty dokładny opis głównych obszarów, których dotyczy konsolidacja. Głębsza analiza metodyk Virtual Infrastructure Methodology (VIM), ALIGN, ALIGN-lite oraz Scorpion pozwoliła na przyjrzenie się poszczególnym fazom trwania projektu. Szczególny nacisk został położony na zastosowanie oprogramowania VMware GSX/ESX oraz VMware VirtualCenter w budowie wirtualnej infrastruktury. Ostatnie rozdziały zostały poświęcone stworzonej aplikacji vclient, której zadaniem jest wspomaganie ostatniego etapu konsolidacji, czyli zarządzania wirtualną infrastrukturą. Program współpracuje z serwerem VMware VirtualCenter i umożliwia zarządzanie serwerami wirtualnymi działającymi w oparciu o VMware GSX/ESX. Praca zawiera opis wymagań, budowę aplikacji oraz szczegółowy przegląd wszystkich dostępnych funkcji. i
Spis treści Streszczenie... i Spis treści... ii Spis tabel, rysunków, przykładów kodu oraz wzorów... iv 1. Wstęp... 1 1.1. Tematyka pracy... 1 1.2. Cel pracy... 1 1.3. Zadania cząstkowe... 1 2. Wprowadzenie do wirtualizacji... 2 2.1. Istota wirtualizacji...2 2.2. Wirtualizacja jako kierunek na rynku informatycznym... 5 2.3. Konsolidacja infrastruktury informatycznej... 6 2.4. Historia maszyn wirtualnych... 13 2.4.1. CTSS... 13 2.4.2. IBM System/360... 13 2.4.3. IBM System/370... 15 2.4.4. Zmierzch technologii maszyn wirtualnych... 16 2.4.5. Renesans technologii maszyn wirtualnych... 17 2.5. Podsumowanie... 20 3. Rozwiązania wspomagające budowę wirtualnej infrastruktury... 21 3.1. VMware GSX... 21 3.2. VMware ESX... 24 3.3. VMware VirtualCenter... 28 3.4. Budowa klastrów z wykorzystaniem maszyn wirtualnych... 29 3.5. Wykonywanie i odtwarzanie kopii zapasowych... 34 3.6. Migracja maszyn wirtualnych... 35 3.7. Podsumowanie... 37 4. Optymalizacja infrastruktury przedsiębiorstwa... 38 4.1. Wstęp... 38 4.2. Typy konsolidacji... 40 4.2.1. Konsolidacja serwerów... 41 4.2.2. Konsolidacja aplikacji... 43 4.2.3. Konsolidacja systemów pamięci masowych... 45 4.2.4. Konsolidacja usług... 48 4.2.5. Konsolidacja sieci... 48 4.2.6. Konsolidacja ośrodków przetwarzania danych... 49 4.2.7. Konsolidacja zasobów ludzkich oraz procesów... 49 4.3. Analiza infrastruktury... 50 4.4. Planowanie... 56 4.5. Implementacja... 62 4.6. Zarządzanie... 67 4.7. Podsumowanie... 70 5. Założenia projektowe... 71 5.1. Założenia programowe... 71 5.2. Założenia sprzętowe... 73 5.3. Koncepcja rozwiązania... 74 6. Aplikacja vclient... 75 6.1. Budowa aplikacji... 75 6.1.1. Opis głównych pakietów oraz klas... 75 6.1.2. Logowanie do serwera VirtualCenter... 81 6.1.3. Synchronizacja z serwerem VirtualCenter... 86 6.2. Praca z aplikacją vclient... 87 6.2.1. Logowanie oraz obsługa aplikacji... 87 6.2.2. Praca z grupami farm serwerów, farmami oraz grupami maszyn wirtualnych... 90 6.2.3. Praca z hostami... 93 6.2.4. Praca z maszynami wirtualnymi... 97 ii
6.2.5. Klonowanie maszyn wirtualnych oraz praca z szablonami... 100 6.2.6. Śledzenie wykorzystania zasobów... 104 6.2.7. Zarządzanie prawami dostępu... 106 7. Weryfikacja działania aplikacji vclient... 108 8. Wnioski oraz plany rozwoju... 109 9. Bibliografia... 110 iii
Spis tabel, rysunków, przykładów kodu oraz wzorów Rysunek 2.1. Umiejscowienie serwerów wirtualnych... 2 Tabela 2.2. Prowadzone prace nad konsolidacją serwerów - Gartner Group [9]... 7 Tabela 2.3. Zainteresowanie konsolidacją serwerów - Gartner Group [9]... 7 Tabela 2.4. Obszary spodziewanego ograniczenie kosztów - Gartner Group [9]... 8 Tabela 2.5. Ograniczenie kosztów/zasobów ludzkich - Gartner Group [9]... 10 Tabela 2.6. Problemy związane z konsolidacją serwerów - Gartner Group [9]... 11 Rysunek 3.1. Architektura VMware GSX/VMware Server [1]... 23 Rysunek 3.2. Budowa komputera mainframe z systemem VM/370 [1]... 24 Rysunek 3.3. Budowa platformy VMware ESX [1]... 24 Rysunek 3.4. Komponenty VMware ESX [13]... 25 Rysunek 3.5. VMware ESX - wirtualizacja procesorów [10]... 26 Rysunek 3.6. VMware ESX - wirtualizacja pamięci operacyjnej [10]... 26 Rysunek 3.7. VMware ESX - wirtualizacja dysków oraz sieci [13]... 27 Rysunek 3.8. Wirtualna infrastruktura [15]... 29 Rysunek 3.9. "Cluster in a Box" - klaster złożony z dwóch węzłów [2]... 31 Rysunek 3.10. "Cluster in a Box" - klaster złożony z dwóch węzłów (szczegóły) [14]... 32 Rysunek 3.11. "Cluster across Boxes" - klaster złożony z czterech węzłów [14]... 33 Rysunek 3.12. Konsolidacja środowisk klastrowych [14]... 33 Rysunek 3.13. Migracja maszyn wirtualnych z wykorzystaniem VMotion [16]... 35 Rysunek 3.14. Migracja maszyn wirtualnych [16]... 36 Rysunek 4.1. VMware ESX + xseries 445 [3]... 42 Rysunek 4.2. VMware ESX + serwery typu Blade [3]... 42 Rysunek 4.3. Metoda "scale-up" i "scale-out" - wady oraz zalety [3]... 43 Rysunek 4.4. Konsolidacja systemów pamięci masowej - DAS [5]... 46 Rysunek 4.5. Konsolidacja systemów pamięci masowej - środowiska heterogeniczne [5]... 47 Rysunek 4.6. Konsolidacja systemów pamięci masowej - SAN [5]... 48 Rysunek 4.7. Total Cost of Ownership (TCO) - według Gartner Group [5]... 55 Rysunek 4.8. Kandydaci - serwery oraz aplikacje [8]... 59 Rysunek 4.9. Wykorzystanie procesora przez potencjalnych kandydatów [8]... 60 Wzór 4.10. Przyszłe wykorzystanie procesora na serwerze VMware ESX [8]... 60 Rysunek 4.11. Przyczyny awarii w ośrodkach data center [5]... 67 Przykład 5.1. Modyfikacja pliku vmaconfig.xml... 72 Rysunek 5.2. Schemat sieci komputerowej... 73 Tabela 5.3. Główne komputery w sieci - specyfikacja... 74 Tabela 6.1. Zawartość pakietu data.core... 78 Tabela 6.2. Zawartość pozostałych pakietów data.core.*... 80 Tabela 6.3. Zawartość pakietów data.gui.*... 81 Przykład 6.4. Konstruktor klasy data.starter.start... 82 Przykład 6.5. Logowanie do serwera (data.core.connectionvc)... 83 Rysunek 6.6. Drzewo obiektów na serwerze VirtualCenter [12]... 83 Przykład 6.7. Inicjalizacja głównych obiektów (data.core.inventory)... 84 Przykład 6.8. Inicjalizacja pozostałych obiektów (data.core.bufferedcoreitem)... 85 Przykład 6.9. Uruchomienie wątku synchronizującego (data.core.connectionvc)... 86 Przykład 6.10. Główna funkcja synchronizująca (data.core.events.virtualcenterupdates)... 87 Przykład 6.11. Delegowanie obiektów zmian (data.core.events.virtualcenterupdates)... 87 Rysunek 6.12. Logowanie do serwera VirtualCenter... 88 Rysunek 6.13. Błędne logowanie do serwera VirtualCenter... 88 Rysunek 6.14. Główny ekran aplikacji vclient... 89 Rysunek 6.15. Menu wyboru operacji... 90 Rysunek 6.16. Dodatkowe moduły aplikacji vclient... 90 Rysunek 6.17. Tworzenie grupy farm serwerów... 91 Rysunek 6.18. Zmiana nazwy grupy farm serwerów... 91 Rysunek 6.19. Kasowanie grupy farm serwerów... 91 Rysunek 6.20. Przeniesienie grupy farm serwerów... 92 Rysunek 6.21. Obsługa panelu grupy farm serwerów... 92 iv
Rysunek 6.22. Podłączenie maszyny fizycznej do serwera VirtualCenter (krok 1)... 93 Rysunek 6.23. Podłączenie maszyny fizycznej do serwera VirtualCenter (krok 2)... 94 Rysunek 6.24. Identyfikacja maszyn wirtualnych... 94 Rysunek 6.25. Szczegółowe informacje o maszynie fizycznej... 95 Rysunek 6.26. Menu wyboru operacji dla maszyny fizycznej... 95 Rysunek 6.27. Zmiany stanów maszyn przy odłączaniu oraz usuwaniu hosta z serwera... 96 Rysunek 6.28. Identyfikacja maszyn przy podłączaniu hosta do serwera... 97 Rysunek 6.29. Główne okno maszyny wirtualnej... 97 Rysunek 6.30. Zmiana ilości pamięci operacyjnej dla maszyny wirtualnej... 98 Rysunek 6.31. Menu wyboru operacji dla maszyny wirtualnej... 99 Rysunek 6.32. Klonowanie maszyny wirtualnej... 100 Rysunek 6.33. Tworzenie szablonu maszyny wirtualnej... 101 Rysunek 6.34. Panel śledzenia wykonywanych zadań... 101 Rysunek 6.35. Repozytorium szablonów maszyn wirtualnych... 101 Rysunek 6.36. Wdrożenie szablonu (sposób 1, krok 1)... 102 Rysunek 6.37. Wdrożenie szablonu (sposób 1, krok 2)... 103 Rysunek 6.38. Wdrożenie szablonu (sposób 2)... 103 Rysunek 6.39. Grupa maszyn zawierająca ostatnio wdrożone serwery... 104 Rysunek 6.40. Wykorzystanie zasobów przez maszyny fizyczne... 104 Rysunek 6.41. Wykorzystanie zasobów - panel hosta... 105 Rysunek 6.42. Wykorzystanie zasobów przez serwery wirtualne... 105 Rysunek 6.43. Nadanie uprawnień grupie farm... 106 Rysunek 6.44. Zdefiniowane uprawnienia "Read Only User"... 107 Rysunek 6.45. Zdefiniowane uprawnienia "Virtual Machine Administrator"... 107 v
1. Wstęp 1.1. Tematyka pracy Praca obejmuje szereg zagadnień związanych z serwerami wirtualnymi oraz korzyściami płynącymi z zastosowania tej technologii w ośrodkach przetwarzania danych. Zasadniczo praca odnosi się do problemu optymalizacji infrastruktury informatycznej i dotyczy zagadnienia konsolidacji serwerów, aplikacji oraz systemów pamięci masowych przy wykorzystaniu maszyn wirtualnych. Głównym powodem powstania tego opracowania jest rosnące zainteresowanie technologią wirtualizacji, która odgrywa obecnie ważną rolę w procesie konsolidacji infrastruktury informatycznej. 1.2. Cel pracy Celem pracy jest przedstawienie technologii maszyn wirtualnych oraz możliwości jej wykorzystania w procesie konsolidacji korporacyjnych ośrodków przetwarzania danych. Efektem realizacji pracy jest aplikacja wspomagająca zarządzanie serwerami wirtualnymi, działającymi pod kontrolą oprogramowania VMware GSX/ESX oraz VMware VirtualCenter. 1.3. Zadania cząstkowe 1. Przegląd technologii maszyn wirtualnych. 2. Analiza wymagań projektowych. 3. Aplikacja wspomagająca zarządzanie serwerami wirtualnymi. 4. Opis zasad korzystania z aplikacji. 5. Weryfikacja działania vclienta. 1
2. Wprowadzenie do wirtualizacji 2.1. Istota wirtualizacji Wirtualizacja jest zbiorem metod pozwalających na podział zasobów komputera, mających na celu utworzenie wielu w pełni funkcjonalnych środowisk przy zastosowaniu technik partycjonowania, podziału czasu, symulacji, emulacji, kolejkowania oraz innych dostępnych [18]. Przedstawiona definicja jest jedną z wielu dostępnych, jednak najbardziej odpowiada tematyce pracy. Szukanie jedynego słusznego rozwinięcia, które nie straciłoby na aktualności przez ostatnie dziesięciolecia, może okazać się niemożliwym zadaniem. "Wirtualizacja" jest na tyle szerokim pojęciem, że bezpieczniej jest traktować ją jako paradygmat. W razie wątpliwości można odwołać się do najnowszych produktów i zastosowanych w nich technologii, a na bok odłożyć definicje słownikowe. Z wirtualizacją ściśle związane jest pojęcie "maszyny wirtualnej". Najogólniej mówiąc maszyna wirtualna jest oprogramowaniem znajdującym się pomiędzy użytkownikiem a architekturą komputera, które uniezależnia pisane aplikacje od implementacji, konfiguracji oraz wykorzystywanych zasobów. Obecnie maszyną wirtualną nazywa się w pełni funkcjonalny serwer wirtualny, który posiada własne zasoby, system operacyjny, aplikacje i jest w stanie dostarczyć określonych usług. Na rysunku 2.1 serwer wirtualny tworzy "System operacyjny #1" oraz "Aplikacja 1". Aplikacja 1 Aplikacja 2 System operacyjny #1 System operacyjny #2 Warstwa wirtualizacyjna System operacyjny Architektura Rysunek 2.1. Umiejscowienie serwerów wirtualnych 2
Warstwa wirtualizacyjna wprowadza dodatkowy poziom abstrakcji, który uniezależnia maszyny wirtualne od zastosowanego systemu operacyjnego oraz architektury maszyny fizycznej. Dodatkowo zapewnia dostęp do takich zasobów jak procesor, pamięć operacyjna oraz urządzeń wejścia/wyjścia. Opisana warstwa może być ściśle związana z systemem operacyjnym. Takie połączenie przedstawiają rysunki znajdujące się w dalszej części pracy (rysunek 3.2 oraz 3.3). Wirtualizacja została wcześniej przedstawiona jako zbiór metod, które dodatkowo można podzielić na następujące grupy: emulację (ang. emulation, full system simulation), parawirtualizację (ang. paravirtualization), pełną wirtualizację (ang. native virtualization, full virtualization), wirtualizację na poziomie systemu operacyjnego (ang. OS-level virtualization). Emulacja programowa polega na umożliwieniu działania aplikacji w innym środowisku niż to, pod które została domyślnie napisana. W tym wypadku maszyna wirtualna w pełni symuluje poszczególne zasoby (procesor, pamięć, urządzenia wejścia/wyjścia). Utworzona w ten sposób architektura istnieje tylko w pamięci komputera, ale stwarza możliwość uruchomienia aplikacji przeznaczonych dla innych urządzeń. Przykładem emulatorów są programy symulujące działanie komputerów ZX Spectrum (emulator Z80Stealth), Atari XL/XE (Atari800), IBM Mainframe (Hercules). Emulatory działają na komputerach klasy PC opartych na architekturze x86 (Intel). Parawirtualizacja polega na dostarczeniu interfejsów, dzięki którym maszyna wirtualna może korzystać z dowolnych zasobów maszyny fizycznej. Dzięki wykorzystaniu bibliotek API (ang. Application Programming Interface) nie ma konieczności symulowania sprzętu. Wszystkie odwołania do urządzeń przechwytywane są przez nadzorcę (ang. supervisor, hypervisor), który przydziela wymagane zasoby. Ta metoda wirtualizacji jest trudna w implementacji i wymaga zmodyfikowania jądra systemu. Przykładem tego typu oprogramowania jest Xen, o którym mowa będzie w dalszej części pracy. Wirtualizacja pełna nie wymaga modyfikacji systemu, jednak występuje tu pewne ograniczenie związane zapewnieniem kompatybilności systemu gościa (ang. Guest Operating System). Ograniczenie spowodowane jest tym, że wirtualizacja dotyczy tylko części zasobów np. pamięci operacyjnej i urządzeń wejścia/wyjścia. Natomiast w celu przyspieszenia 3
wykonywania operacji, nie obejmuje procesora. We wszystkich przypadkach wykorzystywany jest ten sam fizyczny procesora hosta. Oprogramowanie wykorzystujące ten typ wirtualizacji zostanie przedstawione w dalszej części pracy. Wirtualizacja na poziomie systemu operacyjnego nie jest związana z żadnym rodzajem emulacji. Istotą tej metody jest partycjonowanie, które prowadzi do izolacji poszczególnych maszyn wirtualnych. We wszystkich przypadkach używane jest to samo jądro systemu hosta, natomiast różnice występują w aplikacjach oraz stosowanych bibliotekach. Z punktu widzenia użytkownika każda z maszyn wirtualnych zachowuje się jak oddzielny komputer. Ten typ wirtualizacji wykonywany jest przez podzielenie zasobów hosta na osobne partycje, które nazywane są również wirtualnymi środowiskami (ang. virtual environment), wirtualnymi serwerami (ang. Virtual Private Server, VPS) lub strefami (ang. zone). Przykładem zastosowania partycjonowania zasobów jest LPAR (IBM). Na powyższych przykładach została przedstawiona inna definicja maszyny wirtualnej, w której sama maszyna jest tożsama z serwerem wirtualnym i umożliwia świadczenie tych samych usług co tradycyjne serwery. Wracając do rozwinięcia definicji przedstawionej na samym początku, najbardziej znanym przykładem maszyny wirtualnej jest JVM (ang. Java Virtual Machine) firmy Sun Microsystems. JVM tworzy dodatkowy poziom abstrakcji, który uniezależnia aplikację od platformy. Przy uruchamianiu programu wykonywana jest kompilacja (ang. just-in-time compilation), a następnie interpreter wykonuje uzyskany kod. Przyszłość maszyn wirtualnych wygląda dziś lepiej niż kiedykolwiek. Wirtualizacja stwarza szereg nowych możliwości: zapewnienie uniwersalnego środowiska uruchomieniowego, tworzenie, testowanie i poprawianie wstępnych wersji systemów operacyjnych, uruchomienie wielu serwerów wirtualnych na jednej maszynie pozwala na zaoszczędzenie kosztów związanych ze sprzętem, administracją oraz zarządzeniem całą infrastrukturą, tworzenie specyficznych środowisk, których wirtualne zasoby są większe niż dostępne fizycznie (np. emulacja urządzeń SCSI lub większa ilość pamięci operacyjnej), możliwość uruchomienia starszych programów, które nie są kompatybilne z najnowszymi platformami, duża szybkość wykonywania oraz odtwarzania kopii zapasowych, uruchomienie aplikacji klient-serwer na jednym komputerze, 4
możliwość migracji serwerów wirtualnych z jednej maszyny na drugą bez przerywania ich pracy, nowe techniki tworzenia klastrów. 2.2. Wirtualizacja jako kierunek na rynku informatycznym Wirtualizacja staje się powoli kluczowym wymaganiem dla przedsiębiorstw, które chcą "uprzątnąć serwerowy bałagan" w swoich ośrodkach przetwarzania danych. Rozwiązania idące w parze z całym procesem wirtualizacji wymagają długiego okresu przygotowań oraz wielu nakładów finansowych. Pomimo wszystkich wydatków przeznaczonych na projekty tego typu, jednym z kluczowych celów, jaki stawiają sobie organizacje jest zmniejszenie łącznych kosztów utrzymania całej infrastruktury informatycznej. Badania pokazują, że średni koszt utrzymania jednego serwera wynosi około 10 000 dolarów rocznie [22]. Suma ta zawiera wszelkie nakłady poniesione na licencje, konserwację, administrację a nawet energię elektryczną, czy miejsce w serwerowni. Obecnie większość serwerów wykorzystywana jest w zaledwie 10-15 % co oznacza, że ich olbrzymi potencjał jest w większości marnowany. Podobnie zresztą jak fundusze ponoszone na wdrożenia oraz utrzymanie infrastruktury. Rozwiązanie narastającego dziś problemu pojawiło się już w 1966 roku w postaci komputera mainframe System 360/67. W tym produkcie po raz pierwszy zastosowano technologię maszyn wirtualnych, która była bardzo zbliżona do używanej dzisiaj. Pomysł zastosowania maszyn wirtualnych i jego implementacje zmieniały się na przestrzeni lat, jednak niezmienna pozostała możliwość lepszego wykorzystania mocy serwerów oraz ich poszczególnych komponentów. Jeśli fizyczna maszyna jest w stanie umożliwić działanie kilku lub kilkunastu serwerów wirtualnych, to koszt utrzymania takiego środowiska jest znacznie niższy niż w przypadku tradycyjnego podejścia. Wirtualizacja wiąże się z dodatkowymi korzyściami, które obejmują tworzenie rozbudowanych środowisk deweloperskich oraz testowych, a także budowanie infrastruktury nastawionej na niezawodność połączoną z wysoką osiągalnością serwisów. Obecnie stosowane rozwiązania ukierunkowane są przede wszystkim na osiągnięcie maksymalnej wydajności, zapewnienie bezpieczeństwa oraz izolację poszczególnych platform. 5
Odrodzenie się technologii maszyn wirtualnych, której początki sięgają drugiej połowy lat 60-tych [11] jest wynikiem nałożenia się kilku czynników. Po pierwsze, aplikacje wdrażane w przedsiębiorstwach stały się bardziej rozbudowane. Zazwyczaj są to projekty oparte na wielowarstwowej architekturze działające jako wieloprocesowe programy, których konfiguracja i administracja staje się bardzo złożona. Po drugie, względnie niskie koszty zakupu nowych maszyn opartych na architekturze x86 w naturalny sposób doprowadziły do bałaganu w ośrodkach przetwarzania danych. W celu zapewnienia bezpieczeństwa i odizolowania poszczególnych aplikacji, personel IT skłania się ku rozwiązaniu jeden serwer - jedna aplikacja. Taka droga prowadzi do znacznego rozbudowania infrastruktury, która z czasem staje coraz trudniejsza w utrzymaniu i zarządzaniu. 2.3. Konsolidacja infrastruktury informatycznej Konsolidacja infrastruktury jest szerokim pojęciem obejmującym nie tylko zmniejszenie liczby serwerów i zastosowanie wspomnianej wcześniej technologii wirtualizacji. Konsolidacja dotyczy również weryfikacji procesów oraz procedur, które wpływają na optymalne funkcjonowanie i zarządzanie infrastrukturą informatyczną. W kolejnych rozdziałach dokładniej zostaną przedstawione typy oraz kolejne etapy całego procesu. Badania przeprowadzone przez Gartner Group rzucają odrobinę światła na sposób, w jaki firmy postrzegają konsolidację i jakich korzyści spodziewają się po zakończeniu projektu. Uczestnicy 23-ciej corocznej konferencji Data Center, która odbyła się na przełomie listopada i grudnia 2004, wzięli udział w badaniach mających na celu sprawdzenie planów poszczególnych przedsiębiorstw oraz ich oczekiwań związanych z całym procesem konsolidacji. Pomimo tego, że w konferencji uczestniczyło stosunkowo niewiele osób, a odpowiadający nie musieli reprezentować ogółu, to jednak z przedstawionych badań można wyciągnąć szereg istotnych wniosków. 6
Czy prowadzony jest aktualnie projekt polegający na konsolidacji serwerów? 1998 2001 2002 2003 2004 1. Brak planów związanych z tego typu projektem 25% 6% 8% 6% 7% 2. Istnieją plany związane z takim projektem 45% 25% 25% 28% 28% 3. Tak, aktualnie wdrażane jest to rozwiązanie 30% 69% 67% 61% 60% 4. Projekt został zakończony i nie ma dalszych planów 5% 5% Ilość odpowiedzi 100+ 116 475 518 592 Tabela 2.2. Prowadzone prace nad konsolidacją serwerów - Gartner Group [9] W tabeli 2.2 przedstawiono wyniki pokazujące rosnące zainteresowanie oraz prace nad projektami dotyczącymi konsolidacji serwerów. Od roku 2001 wiele przedsiębiorstw zdecydowało się na podjęcie starań mających na celu uporządkowanie swoich ośrodków data center. Około 60-69 % badanych aktualnie pracowało nad wdrożeniem projektu konsolidacji, a dodatkowo 25-28 % wyraziło chęć i zainteresowanie całym procesem. W sumie wyniki pokazały, że w latach 2001-2004 od 88 do 94 procent badanych było w różnych stadiach zaawansowania prac nad projektem. Jedynie 6-7 % nie wyraziło chęci przeprowadzenia u siebie konsolidacji. Kolejne istotne pytanie dotyczyło powodów zainteresowania się konsolidacją serwerów. Dlaczego Państwa organizacja jest zainteresowana konsolidacją serwerów? 2003 2004 1. Jedynym powodem jest ograniczenie kosztów utrzymania (Total Cost of Ownership) 2. Głównym powodem jest ograniczenie kosztów utrzymania, ale spodziewane są też inne korzyści 4. Głównym powodem jest usprawnienie zarządzania systemami (bezpieczeństwo, osiągalność, przywracanie systemów w razie katastrof) 11% 5% 45% 43% 42% 51% 5. Inne 2% 2% Ilość odpowiedzi 175 103 Tabela 2.3. Zainteresowanie konsolidacją serwerów - Gartner Group [9] 7
Wyniki pokazują, że chociaż ograniczenie kosztów utrzymania całej infrastruktury informatycznej jest istotnym czynnikiem wpływającym na wdrożenie projektu (tabela 2.4), to jednak widoczna jest zmiana oczekiwań w roku kolejnym. W 2004 roku dla większości badanych usprawnienie procesu zarządzania systemami stało się kluczowym wymaganiem. Położenie nacisku na budowę uproszczonych ośrodków przetwarzania danych stało się możliwe dzięki rozwinięciu oprogramowania do zarządzania wirtualną infrastrukturą. Gdzie przewidywane są największe oszczędności po przeprowadzonej konsolidacji serwów? 2002 2003 2004 1. Personel IT 42% 36% 31% 2. Sprzęt 27% 38% 40% 3. Oprogramowanie 19% 13% 15% 4. Inne 12% 13% 14% Ilość odpowiedzi 188 197 108 Tabela 2.4. Obszary spodziewanego ograniczenie kosztów - Gartner Group [9] Poprzednie badania pokazały, że jednym z głównych powodów wdrażania projektów konsolidacji serwerów jest ograniczenie kosztów utrzymania infrastruktury. W tabeli 2.4 pokazano obszary spodziewanej redukcji kosztów. Widać tutaj jak na przestrzeni lat zmieniały się oczekiwania w stosunku do prowadzonego projektu. Od roku 2002 do 2004 spadła z 42 % do 31 % ilość osób deklarujących chęć zaoszczędzenia na personelu obsługującym infrastrukturę informatyczną. Tendencja spadkowa jest dobrym znakiem dla operatorów oraz administratorów systemów, którzy zdają sobie sprawę, że technologia wirtualizacji teoretycznie może pozbawić ich pracy. W tabeli 2.5 zostaną dokładniej przedstawione kwestie dotyczące redukcji w zatrudnieniu wyżej wymienionych osób. Na przestrzeni dwóch lat całkowicie zmieniło się spojrzenie na oszczędności związane z zakupami i utrzymaniem sprzętu. W 2004 roku już 40 % zapytanych dostrzegło możliwość ograniczenia wydatków na serwery. Przyczyny nagłego zwrotu sytuacji należy przede wszystkim dopatrywać się w ofertach producentów sprzętu komputerowego. Wieloprocesorowe serwery o dużej mocy obliczeniowej dostępne po relatywnie niskich cenach w pełni wykorzystują możliwości oprogramowania przeznaczonego do wirtualizacji. Takie firmy jak VMware, Microsoft, XenSource na przestrzeni kilku ostatnich lat znacznie 8
rozbudowały swoje oferty dotyczące oprogramowania. Walka jaka toczy się obecnie w tym sektorze, powoduje, że szybciej niż kiedykolwiek ulepszane są starsze wersje produktów oraz tworzone są zupełnie nowe, z których każdy jest małą rewolucją w tej dziedzinie. Więcej informacji na ten temat znajduje się w kolejnym podrozdziale poświęconym historii maszyn wirtualnych. W tym miejscu więcej miejsca wypada poświęcić kwestii redukcji kosztów związanych z oprogramowaniem. Przedstawione wyniki pokazują, że w latach 2002-2004 zmniejszyły się oczekiwania związane z oszczędnościami w tym obszarze. Wirtualizacja rzeczywiście pozwala znacznie ograniczyć koszty utrzymania serwerów, jednak sama w sobie nie jest receptą na zmniejszenie ilości potrzebnego oprogramowania do obsłużenia wirtualnych platform. Można nawet powiedzieć, że firmy będą potrzebować większej ilości licencji na systemy operacyjne oraz wydadzą więcej na oprogramowanie do obsługi platform np. VMware GSX, ESX czy VirtualCenter. Wirtualizacja serwerów powoduje, że potrzebne jest inne spojrzenie na platformy tego typu. Kolejne rozdziały tej pracy będą pokazywać, że system operacyjny nie jest już bezpośrednio związany z architekturą serwera. Możliwe jest swobodne "przepływanie" całych systemów z jednej maszyny np. z 2 - procesorowej na 4 - procesorową, a moduły SMP umożliwiają dodatkowe zastosowanie wirtualnych procesorów. W tym momencie pojawia się szereg wątpliwości związanych z licencjami na tego typu serwerach. Czy wirtualny serwer działający na maszynie 4-procesorowej opartej dodatkowo na 2 wirtualnych procesorach, potrzebuje licencji na 2, 4 czy 6 procesorów? Co zrobić z systemami przechowanymi w repozytoriach jako szablony utworzone z działających systemów? Odpowiedzi na te pytania ciągle nie są oczywiste i potrzebne są zmiany w sposobie licencjonowania systemów operacyjnych. Jako pierwszy kwestię te poruszył Microsoft, który w październiku 2005 roku wprowadził szereg zmian w swoich ofertach [19]. Od tego czasu klient będzie jedynie musiał zapłacić za maksymalną ilość instancji Windows Server uruchomioną w danym momencie. Z opłat zostaną zwolnione kopie zapasowe całych serwerów oraz szablony przechowywane w repozytoriach. Dodatkowo migracja serwerów z jednej maszyny na drugą może odbywać się bez ograniczeń, pod warunkiem, że obie maszyny posiadają ważne licencje. Kolejnym udogodnieniem są zmiany dotyczące liczby procesorów. Obecnie klient będzie musiał zapłacić za ilość wirtualnych procesorów danego serwera, a nie za fizyczne procesory na danej maszynie. Oprócz tych głównych zmian Microsoft pozwala na przykład na 9
uruchomienie 4 wirtualnych instancji jednego Windows Server 2003 R2 Enterprise Edition bez dodatkowych opłat. Pozytywnym znakiem są obietnice związane z kolejnymi systemami operacyjnymi i możliwością uruchomienia dowolnej liczby wirtualnych serwerów posiadając tylko jedną licencję. Wszystkie zmiany wprowadzane przez Microsoft nie mogą pozostać bez znaczenia dla ich klientów. Być może inne firmy uczynią krok w kierunku zmian w opłatach za swoje produkty i uwzględnią nie tylko systemy operacyjne, ale również inne aplikacje. Odpowiedzi osób aktualnie pracujących nad wdrożeniem projektu konsolidacji serwerów Tak Nie Czy osiągnięto redukcję kosztów? 60% 40% Ilość odpowiedzi 80 Czy zredukowano personel IT? 25% 75% Ilość odpowiedzi 89 Tabela 2.5. Ograniczenie kosztów/zasobów ludzkich - Gartner Group [9] Kolejne badanie dotyczyło osób odpowiedzialnych za wdrożenie projektu konsolidacji serwerów, które jeszcze nie zakończyły całego procesu. Bez względu na etap projektu 60 % pytanych już teraz zauważyło redukcję kosztów związanych z personelem, sprzętem lub oprogramowaniem. Gartner przewiduje, że liczba firm, w których osiągnięta zostanie redukcja kosztów wzrośnie do 85-90 procent. Natomiast pozostałe nie odnotują korzyści finansowych, jednak to wcale nie musi oznaczać, że projekt nie zakończył się powodzeniem lub jego wdrożenie było bezcelowe. Warto przypomnieć, że konsolidacja infrastruktury w ostatnich latach wykonywana jest w celu osiągnięcia lepszej kontroli nad zarządzanymi systemami (tabela 2.3). Kolejne istotne pytanie dotyczyło redukcji personelu. Proces konsolidacji sprawia, że mniejsza ilość inżynierów jest potrzebna do obsłużenia działających systemów. Nowe technologie podcinają skrzydła informatykom i potrafią skutecznie pozbawić ich pracy. Jednak okazuje się, że w większości przypadków firmy niechętnie zwalniają swoich pracowników. Pomimo tego, że do obsługi systemów nie są potrzebni wszyscy inżynierowie. Po zakończonym projekcie pracownicy często oddelegowani zostają do innych zadań. Czasami może się to wiązać ze zmianą obszaru działalności i przekwalifikowaniem 10
personelu. Należy jednak pamiętać, że jest to najbardziej optymistyczny scenariusz dla pracowników i nie ma tutaj jednoznacznej odpowiedzi na pytanie dotyczące ich przyszłości w danej organizacji. Tabela 2.4 wyraźnie pokazuje zainteresowanie redukcją kosztów utrzymania infrastruktury uzyskane w drodze cięć personelu działającego w tym obszarze. Jakie problemy napotkano realizując projekt konsolidacji serwerów? 2003 2004 1. Wewnętrzna polityka firmy 35% 43% 2. Brak odpowiednich narzędzi wspomagających zarządzanie 15% 9% 3. Brak odpowiednich narzędzi wspomagających proces konsolidacji 9% 5% 4. Zbyt wysokie ceny oprogramowania 7% 6% 5. Brak wsparcia ze strony producentów oprogramowania w skonsolidowanych środowiskach 6. Problemy z oprogramowaniem działającym w nowym środowisku 5% 9% 28% 25% 7. Inne problemy 2% Ilość odpowiedzi 195 106 Tabela 2.6. Problemy związane z konsolidacją serwerów - Gartner Group [9] W tabeli 2.6 zostały przedstawione typowe problemy, z którymi musiały się uporać firmy wdrażające projekt konsolidacji serwerów. Okazuje się, że przeszkody nie dotyczą wyłącznie technicznych aspektów przedsięwzięcia. Większość ankietowanych osób stwierdziła, że najpoważniejszym problemem była kwestia wewnętrznej polityki firmy. Należy przez to rozumieć wszystkie obawy, jakie wiążą się z utratą kontroli nad systemami, kwestiami bezpieczeństwa czy zapewnieniem wystarczającej wydajności nowych rozwiązań. Problemem, który również zalicza się do tej grupy jest utrzymanie dostępności serwisów na określonym poziomie. Poziom ten może zostać zmniejszony w procesie migracji serwerów. Kwestia ciągle pozostaje nierozwiązana pomimo istnienia wygodnych i szybkich narzędzi umożliwiających tworzenie serwerów wirtualnych na podstawie fizycznych odpowiedników. Ciągle jednak te operacje wiążą się z wyłączeniem maszyn fizycznych z użycia i wykonaniem obrazów partycji wykorzystywanych przez serwery. Wzrost obaw związanych ze zapewnieniem zgodności z polityką wewnętrzną firmy jest widoczny w roku 2004, kiedy dla 11
43 % ankietowanych rozwiązanie tych problemów stało się kluczowym czynnikiem w powodzeniu całej operacji. Na drugim miejscu postawiono wszelkie problemy, jakie wiązały się z działaniem aplikacji w nowym środowisku. Często ich rozwiązanie polega na przeprowadzeniu zmian w samym oprogramowaniu. Zmiany obejmują zastosowanie nowych rozwiązań w komunikacji między procesami i przekompilowanie całego kodu. Modyfikacje nie zawsze są możliwe do przeprowadzenia. Dodatkowo mogą również generować duże koszty. Wówczas powodzenie całego procesu konsolidacji staje pod znakiem zapytania. Inną istotną kwestią, która bezpośrednio dotyczy używanego oprogramowania, jest odcięcie od pomocy technicznej. Firmy produkujące oprogramowanie nie zawsze mogą zapewnić pomoc w przypadku, kiedy dana aplikacja uruchomiona jest w innym środowisku niż przewidywane. Najmniej problemów stwarza obecnie oprogramowanie do zarządzania nową infrastrukturą. Dobrym przykładem jest np. VMware VirtualCenter. Produkt jest w stanie ułatwić zarządzanie całymi farmami wirtualnych serwerów. VirtualCenter oraz darmowe biblioteki VMware SDK zostały wykorzystane w tej pracy i na ich podstawie napisano nowy produkt obejmujący większość operacji możliwych do wykonania na maszynach fizycznych czy serwerach wirtualnych. Na uwagę zasługuje złożoność samego procesu konsolidacji obejmującego szereg zagrożeń z nim związanych. W 2003 roku 9 % ankietowanych zwróciło na to uwagę wytykając brak narzędzi wspomagających przeprowadzenie operacji. Obecnie największe możliwości oferuje IBM Corporation udostępniając swoim klientów szereg metodyk ułatwiających konsolidację. Na przykład grupa SCON SWAT Team bazująca na doświadczeniu swoich ekspertów jest w stanie przeanalizować dowolne środowisko i wdrożyć rozwiązanie satysfakcjonujące każdego klienta, opierając się na jednej ze swoich metodyk (ALIGN, ALIGN-lite, Scorpion). Warto również wspomnieć, że metodyki oferowane przez IBM dotyczą nie tylko produktów tej firmy, ale również wspomagają tworzenie rozwiązań opartych na oprogramowaniu lidera w branży serwerów wirtualnych - firmy VMware. Więcej informacji o tych metodykach i oprogramowaniu wspomagającym cały proces znajdzie się dalszej części pracy. 12
2.4. Historia maszyn wirtualnych 2.4.1. CTSS W 1961 grupa programistów 1 z Massachusetts Institute of Technology w Cambridge pod kierunkiem profesora Fernando Corbató wydała na świat Compatible Time-Sharing System. W CTSS 2 wykorzystano pomysł stworzenia systemu operacyjnego opartego na podziale czasu, w którym zasadniczą funkcję pełnił nadzorca. Nadzorca był programem, odpowiedzialnym za planowanie, przydział i kontrolę zasobów. Od chwili pierwszej oficjalnej prezentacji w listopadzie 1961 roku, CTSS wyznaczał drogę innym programistom. Pokazał w jaki sposób powinien być zaimplementowany podział czasu w systemie. Warto również wspomnieć o ścisłej współpracy firmy IBM oraz MIT 3 przez cały okres prowadzenia badań IBM w tym czasie tworzył kolejne wersje szybszych, bardziej wydajnych procesorów, dostarczając je instytutowi i modyfikując komputery mainframe 4. Dzięki wsparciu ze strony IBM badania postępowały naprzód. Stworzenie systemu z podziałem czasu nie stanowiło już kłopotu. Programiści skupili się na poprawie procesu przydzielania zasobów przez program nadzorcy. Jesienią 1963 roku inżynierowie z MIT zadecydowali o stworzeniu nowego systemu bazującego na prototypie CTSS, ale będącego jego udoskonaloną wersją. Projekt MAC 5, miał na celu stworzenie systemu Multics. Multics stał się później wzorcowym modelem dla przyszłych projektantów systemów operacyjnych. 2.4.2. IBM System/360 7 kwietnia 1964 IBM pokazał światu System/360, jednak rozwiązania techniczne zaimplementowane w tym produkcie wywołały falę nieporozumień pomiędzy IBM oraz MIT. Twórcy tego komputera doszli do wniosku, że przyszłość nie leży w efektywnym podziale czasu, ale w szybkim przetwarzaniu zadań. Kilka miesięcy później Fernando Corbató opublikował pracę, w której odsłonił wszystkie słabe strony maszyny S/360 raport ten oceniał niewielką przydatność tej platformy do implementacji systemów z podziałem czasu. 1 Wszystkie nazwiska, daty oraz wydarzenia opisane w tym rozdziale pochodzą z opracowania Melindy Varian [11] 2 CTSS Compatible Time-Sharing System 3 MIT Massachusetts Institute of Technology 4 Kolejne wersje: IBM 704, 709, 7090 i 7094 5 Projekt MAC Machine-Aided Cognition, Multiple-Access Computing lub Man and Computer 13
IBM otrzymał również wiele niepochlebnych opinii na temat swojego produktu, które pochodziły z innych środowisk zrzeszających programistów. Z czasem IBM zdał sobie jednak sprawę, że będzie potrzebował dobrego system z podziałem czasu i w tym właśnie celu powstał projekt CP-40 6. Stworzenie takiego systemu stało się nowym wyzwaniem dla programistów, którego trudność potęgowały ograniczenia narzucane przez architekturę komputera S/360. W grudniu 1964 roku inżynierowie, starali się obrać odpowiedni kierunek przy tworzeniu nowego systemu. Ta grupa programistów podjęła wówczas śmiałe i ryzykowne kroki określając wymagania CP-40. Nowy system miał korzystać z pamięci wirtualnej 7 oraz maszyn wirtualnych. Nowa technika miała zwiększyć izolację poszczególnych użytkowników i stworzyć iluzję korzystania z systemu, jakby był to system jednego użytkownika. Control Program miał zarządzać oraz izolować poszczególne maszyny wirtualne w podobny sposób, w jaki robi się to obecnie. Programiści szybko dostrzegli potrzebę stworzenia jeszcze jednego systemu (CMS 8 ), który miał przede wszystkim umożliwić uruchomienie kilku maszyn wirtualnych. Programiści dążyli do maksymalnego uproszczenia swojego projektu i z tego powodu CMS miał stać się nieskomplikowanym systemem przeznaczonym dla jednego użytkownika. W styczniu 1967 roku systemy CP-40 oraz CMS trafiły do seryjnej produkcji i nie obyło się wtedy bez kłopotów użytkownicy zaczęli zauważać błędy w obsłudze pamięci wirtualnej (ang. page trashing), jak się okazało były to te same kłopoty, jakie napotkano przy realizacji systemu Ferranti Atlas. Warto w tym momencie wspomnieć również o poważnych problemach ze stabilnością oraz wydajnością, jakie napotkano w System/360 Model 67 działającym pod kontrolą TSS (ang. Time Sharing System). Mniej lub bardziej udane próby stworzenia nowatorskich systemów operacyjnych dla komputerów typu mainframe wniosły więcej w rozwój maszyn wirtualnych niż można by przypuszczać. Pojawiły się ciekawe pomysły chociaż gorzej było z ich wykonaniem. Prawdopodobnie nikt wtedy nie przypuszczał, że za około 40 lat proporcje zupełnie się odwrócą wykształci się mnóstwo wykwalifikowanych programistów, powstanie wiele użytecznych narzędzi, natomiast zabraknie pomysłów na nowe produkty i technologie. 6 CP-40 Control Program 7 Pamięć wirtualna miała w tym przypadku przyspieszyć przełączanie się pomiędzy programami użytkowników; jedynym systemem, który używał tej techniki był dotychczas Ferranti Atlas (działał z dużymi problemami) 8 CMS początkowo był skrótem od Control Monitor System, potem Cambridge Monitor System, a ostatecznie, kiedy powstał system VM/370 - Conversational Monitor System 14