Wirtualizacja to temat będący w IT "na topie" od lat - może nawet dekad! Ilość dostępnych rozwiązań jest spora, wertowanie dokumentacji czy testowanie ich działania w praktyce możne wciągnąć na kilka długich zimowych wieczorów, bądź nawet na kilka długich zim. ;) W tym wpisie chciałbym pokrótce podzielić się moimi doświadczeniami w pracy ze środowiskami wirtualnymi, głównie w kontekście zarysowania kilku typów „wirtualizacji” z których możemy skorzystać. Tekst traktuje temat dość ogólnie (skupiając się tylko bardziej szczegółowo na LXC), mam nadzieję, że będzie interesujący zarówno dla osób zastanawiających się nad wykorzystaniem wirtualizacji, jak i już weteranów tematu. Wszelkie uwagi mile widziane! :)
Pełna wirtualizacja
Pierwsze moje zetknięcie z wirtualizacją to kontakt z VMWare (w wersji 1.x, ale czy to było Workstation, czy Desktop? - Już nie pamiętam). Używałem na domowym PC i laptopie, i bardzo mile wspominam - łatwe w obsłudze, działało bez zarzutu. Wykorzystywałem VMWare do tzw. wirtualizacji "pełnej", szczerze mówiąc wtedy nie miałem jeszcze pojęcia o istnieniu jakiejś "innej" wirtualizacji, zresztą VMWare, podobnie jak wiele innych narzędzi do wirtualizacji (np. VirtualBox), wspiera chyba tylko ten jeden jej typ (choć poniżej wrócę jeszcze do tego zagadnienia). "Pełna" wirtualizacja nie jest zła - nie o to chodzi, często to jedyna możliwość wirtualizacji jakiegoś środowiska - np. w przypadku wirtualizacji systemu X w środowisku systemu Y, czy inaczej mówiąc: gdy system operacyjny gościa jest inny niż system operacyjny maszyny hostującej, i po ludzku: gdy np. wirtualizujemy Windows na GNU/Linuksie bądź na odwrót (choć w przypadku "uruchamiania" GNU/Linuksa na systemie Windows mamy ciekawą alternatywę w postaci coLinuksa - http://www.colinux.org - warte przemyślenia, używałem kilka lat temu i działało całkiem dobrze, czy popularnego Cygwina https://www.cygwin.com - jednak ani coLinux, ani Cygwin nie są hypervisorami - http://en.wikipedia.org/wiki/Hypervisor - więc dziś ani słowa więcej o nich :)). Moim zdaniem, w kontekście zastosowań domowych w 90% przypadków będziemy myśleli o wirtualizacji pełnej (ze względu na główny cel prywatnego wykorzystania wirtualizacji, którym jest "sprawdzenie" innych systemów, czy korzystanie okazjonalne z innego systemu na domowym PC), natomiast w przypadku wykorzystania wirtualizacji w biznesie (również w przypadku wykorzystania wirtualizacji przy wspomaganiu np. pracy dewelopera) wskaźnik ten może być dużo niższy - być może nawet tylko 10% przypadków korzystania z wirtualizacji w zastosowaniach profesjonalnych wymaga tzw. "pełnej" wirtualizacji! Oczywiście to tylko moje szacunki, jednak jeżeli choć tylko w jakiejś części są one prawdziwe, i jeżeli zauważymy, że „pełna” wirtualizacja to wirtualizacja najbardziej ze wszystkich typów wirtualizacji kosztowna, to wynika z tego, że w 90% wykorzystania wirtualizacji w zastosowaniach profesjonalnych przepłacamy (bądź też nazywając rzeczy bardziej po imieniu – marnotrawimy nasze zasoby sprzętowe)! W zastosowaniach „domowych” być może ten odsetek jest dużo niższy, ale jestem przekonany, że również tutaj znajdą zastosowanie alternatywne metody wirtualizacji – szczególnie stawiałbym na LXC, ze względu na prostotę instalacji i konfiguracji. Koszt pełnej wirtualizacji może być "do zniesienia" na PC czy laptopie jeżeli uruchamiamy jedną wirtualną maszynę (bądź ich mniejszą ilość, w zależności od sprzętu) - w przypadku jednak gdy chcielibyśmy "zasymulować" pracę bardziej złożonej infrastruktury, koszt może być zbyt wysoki - nie oznacza to jednak, że musimy zrezygnować z prób lokalnego odwzorowania takiej infrastruktury! Musimy tylko zrezygnować z "pełnej" wirtualizacji! :) - przy LXC może to być zupełnie wykonalne, bo choć oczywiście nie przybędzie nam RAMu czy rdzeni procesora, to jednak dużo mniej zasobów (praktycznie wcale) zużyjemy na samą obsługę wirtualizacji.
Wracając do moich doświadczeń z VMWare – mimo, iż były one całkiem pozytywne, to jak w przypadku każdego programu komercyjnego, w pewnym momencie pojawił się "problem" licencji (tym bardziej, że oprócz wykorzystania prywatnego, poszukiwałem czegoś do wykorzystania w pracy, w wersji "serwerowej"). Ponieważ koszty zakupu licencji okazały się zbyt duże, rozpocząłem poszukiwania jakiegoś innego rozwiązania i tak trafiłem na stronę projektu Xen (czytaj "Zen"), i mimo iż z VMWare spotykałem się jeszcze (i pewnie będę spotykał) wiele razy (szczególnie w wersji ESX(i)) to jednak Xen hypervisorem najlepszym jest – bez dwóch zdań. Mniejsza o benchmarki! To oczywiście zupełnie subiektywna opinia :) Xen (choć nie tylko) implementuje nowy rodzaj wirtualizacji - parawirtualizację,
Parawirtualizacja
W mojej 10 letniej karierze Administratora Xen nigdy mnie nie zawiódł. Wiele środowisk które postawiłem z wykorzystaniem Xena pracuje do dziś - oczywiście Xen to nie "pempek świata", każdy może wybrać co mu pasuje (kvm na przykład), po prostu w moim przypadku był to właśnie ten hypervisor. Nie chcę tutaj rozpisywać się na temat różnic pomiędzy np. Xenem a VMWare - w sumie nie jestem nawet pewien czy te środowiska w ogóle można porównywać, tzn. oczywiście można robić różnego rodzaju benchmarki itp., ale musimy pamiętać o jednym - VMWare to rozwiązanie komercyjne, a „świat rozwiązań komercyjnych” mocno wpływa na każdy swój produkt, zmieniając nawet najprostszy program w jakiegoś wielkiego i przerośniętego potwora (bo liczy się, że TEN produkt ma to, to i to, i to czego nie mają inni, i w ogóle ma najwięcej). Z tego powodu trudno jest porównywać takie produkty jak MS Exchange i np. Postfix, MS SQL Server i np. Postgres czy również VMWare i Xen. Postfix i Xen cechuje uniksowa zasada: "skup się na jednej rzeczy i wykonaj ją dobrze" – komercyjne firmy podchodzą do tematu trochę inaczej :) Efekt jest taki, że np. Xen nie dysponuje funkcjonalnościami związanymi z systemem plików (tworzenie „wirtualnych dysków”), czy narzędziami do zarządzania „wirtualnymi” sieciami... To po prostu nie jest jego zadanie, tymi funkcjonalnościami zajmują się inne narzędzia, pochodzące z innych projektów (np. lvm jako narzędzie do zarządzania „wirtualnymi” dyskami, czy vswitch, bądź ip + brctl + vconfig, jako narzędzia do zarządzania „wirtualnymi” sieciami) – niestety, to co w komercyjnych rozwiązaniach często dostępne jest pod jednym przyciskiem, w rozwiązaniach typu Xen = nieprzespane noce, morza kawy i wertowanie setek stron dokumentacji - coś za coś. Pozytywną stroną jest fakt, że oczywiście przekłada się to na wiedzę - to jest na plus, ale trzeba mieć mocne nerwy i dużo samozaparcia! Dlatego, mimo iż prawirtualizacja to na pewno krok w dobrą stronę, to jednak „pod strzechy”, w aktualnej formie, raczej nie trafi. Również deweloperowi konfiguracja i zarządzanie środowiskiem wykorzystującym parawirtualizację może sprawić sporo kłopotów. Oczywiście w rozwiązaniach biznesowych, kiedy nie możemy sobie pozwolić na błędy, a brakuje nam doświadczenia, również Xen może być wspierany przez firmy zewnętrzne (możemy otrzymać wsparcie, szkolenia, itp...) - wystarczy poszukać firm oferujących rozwiązania typu Citrix czy XenServer (Citrix to komercyjna wersja Xena oferowana przez IBM, nie namawiam tutaj do zakupu Citrixa jako takiego - chcę jedynie wskazać adres gdzie można spytać o cenę wsparcia dla OpenSourcowego Xena - powinna być o ofercie :)) Tak więc pomimo, iż z parawirtualizacji raczej w domu / na firmowym laptopie nie skorzystamy, to jednak podrążę jeszcze trochę temat – po pierwsze Xen to mój ulubiony hypervisor, po drugie – parawirtualizacja to jakby stan przejściowy pomiędzy „pełną” wirtualizacją a LXC, o którym poniżej napiszę więcej, i który „dla domu” już w mojej ocenie, nadaje się jak najbardziej.
Wracając więc do samego Xena – działa on trochę inaczej niż opisywane wcześniej VMWare (ESX być może wykorzystuje podobny mechanizm - brak mi jednak wiedzy w tym temacie) czy VirtualBox - w przypadku Xena nie uruchamiamy aplikacji wirtualizującej w naszym OSie, to nasz OS (GNU/Linux) jest uruchomiony "na" Xenie (który jest pomiędzy OSem a sprzętem) i stanowi niejako "interfejs" do komunikacji z hypervisorem – na załączonym z wikipedi obrazku Xen to hypervisor „natywny” (type 1) a VMWare czy VirtualBox to hypervisory „hostowane” (type 2).
Jak już pisałem Xen umożliwia parawirtualizację. Parawirtualizacja to nic innego jak próba wirtualizacji mniejszym kosztem niż przy jej "pełnym" odpowiedniku - w przypadku parawirtualizacji system gościa (wirtualny, DomU) korzysta z tego samego jądra systemu co system hosta (Dom0) - pozwala to na zaoszczędzenie zarówno pamięci RAM jaki i mocy przerobowych systemu hosta, co oczywiście przekłada się na ogólnie lepszą wydajność takiego rozwiązania w stosunku do wirtualizacji pełnej. Jednak coś za coś - system "parawirtualizowany" musi wykorzystywać ten sam kernel co system hosta (choć to nie do końca prawda, o czym za chwilę), nie może to być więc dowolny system - musi to być system "bazujący" również na Linuksie, co w oczywisty sposób odrzuca możliwość wykorzystania tego mechanizmy do wirtualizacji np. system Windows. Zysk jest jednak opłacalny i zawsze wart rozważenia - jeżeli chociaż 50% naszych "wirtualek" stanowić będą GNU/Linuksy moim zdaniem warto rozważyć wykorzystanie hypervisora wspierającego parawirtualizację. Oczywiście wykorzystując Xena można wirtualizować również inne systemy operacyjne (jak Windows) w trybie wirtualizacji pełnej (oba typy – parawirtualizacja i pełna wirtualizacjia – mogą być wykorzystywane równolegle).
Kiedyś rozmawiałem z administratorem jednej z dużych platform cyfrowych w kraju i usłyszałem od niego, że ESX również posiada parawirtualizację (w ogóle ESX posiada wszystko!) - nie wiem, nie robiłem żadnego researcha w tej sprawie, całkiem jednak możliwe że tak jest – po pierwsze ESX to przecież również Linux, po drugie, ogólnie istnieje możliwość parawirtualizacji z innym kernelem niż kernel hosta – co w Xenie można osiągnąć poprzez wykorzystanie PyGruba w parawirtualizowanej maszynie... Nie zagłębiałem się w szczegóły techniczne, PyGruba używałem w kilku przypadkach – działał, tak więc również na platformie ESX teoretycznie możliwym wydaje się hostowanie np. debiana z dystrybucyjnym kernelem przy wykorzystaniu parawirtualizacji – nie mówię nie, ale czy rzeczywiście ESX posiada parawirtualizację i jak ona ewentualnie działa – nie wiem.
Mógłbym napisać jeszcze naprawdę dużo o wirtualizacji z wykorzystaniem Xena, ale i tak chyba rozpisałem się już zbytnio - najważniejszy przekaz to sama parawirtualizacja - jest coś takiego i warto o tym pamiętać. Co prawda na desktopie może być ciężko, ale nie ma rzeczy niemożliwych – zysk ze zwiększenia ogólnej wydajności systemu będzie na pewno, pytanie czy jesteśmy gotowi zainwestować swój czas w przygotowanie takiego środowiska.
LXC
Prarawirtualizacja to krok w dobrą stronę - możemy zaoszczędzić trochę zasobów i ciągle cieszyć się wirtualizacją. Okazuje się jednak, że możemy pójść jeszcze dalej - zaoszczędzić jeszcze więcej zasobów i cieszyć się prostszą (łatwiejszą w konfiguracji) wirtualizacją! Niemożliwe? Uwadze wszystkich niedowiarków polecam projekt LXC - "linux containers". Pierwszy raz spotkałem się z koncepcją kontenerów kilka lat temu - projekt wtedy raczkował i konfiguracja była trochę skomplikowana. Później na jakiś czas zapomniałem o tym pomyśle, na szczęście jednak ostatnio postanowiłem sprawdzić "co słychać" w projekcie - okazało się, że całkiem sporo :) Projekt zyskał mocne wsparcie Ubuntu i rozwija się w najlepsze - aktualna wersja jest wręcz banalna w instalacji i użytkowaniu, o czym za chwilę. Korzystając z LXC jesteśmy jeszcze bliżej systemu hosta, niż w przypadku parawirtualizacji. W sumie parawirtualizacja, poza technicznymi aspektami działania, nie różni się wiele od pełnej wirtualizacji, a w przypadku LXC różnice są już znaczne. Przede wszystkim – kontener (nasza „wirtualka”) rezyduje w zwykłym katalogu, w systemie plików hosta (rezyduje – tzn. cały system plików kontenera - maszyny wirtualnej - znajduje się w jednym katalogu na naszym dysku, w formie... zwykłego drzewa katalogów). Nie ma tutaj żadnych „wirtualnych” dysków itp., co mocno upraszcza dostęp do naszych projektów – np. z poziomy IDE, czy po prostu jakiegoś edytora. W kontenerze, jak przy wykorzystaniu „normalnej” wirtualki, instalujemy środowisko wykonawcze projektu (np. serwer http, serwer bazy danych, itd..), którym zarządzać możemy tylko z „wnętrza” kontenera logując się np. z wykorzystaniem ssh, jednak dostęp do wszystkich plików kontenera jest równie prosty jak dostęp do plików w naszym katalogu domowym – nie musimy korzystać z nfs/smb/sshfs czy innych "zdalnych" systemów plików jak na przykład vboxfs ("share folders" z VirtualBoxa) - do systemu plików kontenera możemy "zaglądać" bez żadnych ograniczeń również w chwili gdy kontener (nasza wirtualka) pracuje - nirvana :) Ograniczenia konfiguracyjne kontenerów są trochę większe niż przy prarawirtualizacji – nie tylko musimy zrezygnować z instalacji Windowsa (nie da rady w kontenerze), ale również jesteśmy „skazani” na ten sam system plików (w sensie typu) co w systemie hosta – jednak, to chyba akurat w zdecydowanej większości projektów nie ma zupełnie znaczenia :) Zyskujemy znów na wydajności i to jest najważniejsze – możemy korzystać z wirtualizacji prawie za darmo, co czyni ją dostępną nawet na starszym sprzęcie.
Ok, to teraz trochę konkretów - szybki kurs używania LXC (w moim przypadku z wykorzystaniem dystrybucji Ubuntu) ;)
Instalacja kontenera:
sudo aptitude install lxc
i już! - Zainstalowane i gotowe do użycia. Możemy teraz utworzyć pierwszy kontener. Na stronie https://linuxcontainers.org/lxc/getting-started/ przedstawione zostały procedury "tworzenia" kontenerów nieuprzywilejowanych i uprzywilejowanych. Kontenery nieuprzywilejowany wymagają trochę więcej pracy, jednak w warunkach developersko domowych możemy chyba skupić się jedynie na wersji "uprzywilejowanej" (zbytnia dbałość o bezpieczeństwo nie jest nam w takim przypadku specjalnie potrzebna) - "postawienie" kontenera uprzywilejowanego sprowadza się do wydania komendy:
sudo lxc-create -t download -n NAZWA
zostanie nam przedstawiona lista dostępnych dystrybucji które możemy zbudować w kontenerze (debian, centOS, ubuntu, itd....), wybieramy dystrybucję, wersję oraz architekturę (32 czy 64 bity) i instalator pobiera i instaluje potrzebne oprogramowanie. Kiedy skończy możemy sprawdzić czy nasz kontener jest na liście dostępnych do uruchomienia:
sudo lxc-ls
oraz sprawdzić jego stan / status:
sudo lxc-info -n NAZWA
Status powinien być: "STOPPED". Przed pierwszym uruchomieniem musimy przygotować sobie już tylko konto w nowym systemie (instalator nie tworzy żadnego domyślnego). W celu ustawienia hasła użytkownika root przechodzimy do katalogu z filesystemem naszego kontenera, w Ubuntu oznacza to ścieżkę:
cd /var/lib/lxc/NAZWA/rootfs
UWAGA - domyślnie uprawnienia do katalogu /var/lib/lxc są bardzo rygorystyczne i musimy albo je zmienić, albo wykorzystać użytkownika root. Ponieważ swobodny dostęp do systemów plików naszych kontenerów i tak się nam przyda (i ponieważ opisuję tu sytuację w której wykorzystujemy LXC na "naszym" komputerze - nie ważne czy w domu, czy w pracy), polecam zmianę uprawnień - 777 zadziała, ale to już będzie przesada :), warto postarać się o coś bardziej "dopasowanego" i mniej "bijącego po oczach", np.: 775 i zmianę grupy na np. "staff" dla tych katalogów w których chcemy mieć prawa zapisu (oczywiście jeżeli sami jesteśmy członkiem grupy staff, jeżeli nie, to polecam się do takiej grupy dodać :))
Jeżeli jesteśmy już w katalogu /var/lib/lxc/NAZWA/rootfs to wykonujemy:
sudo chroot .
Teraz "działamy" w danej konsoli już w systemie plików kontenera (choć nie w wirtualnym środowisku) - możemy wiec zmienić hasło dla użytkownika root wykonując komendę:
passwd
po ustawieniu hasła możemy wrócić do naszego głównego systemu plików:
exit
i wystartować kontener poprzez:
sudo lxc-start -n NAZWA
Kiedy kontener zostanie już uruchomiony pojawi się standardowy ekran logowania, możemy się zalogowań i rozpocząć konfigurowanie naszego nowego systemu. Przy kolejnych uruchomieniach systemu warto już korzystać z polecenia:
sudo lxc-start -d -n NAZWA
Zwróć uwagę na "-d" - to uruchomi kontener w trybie „demona” (daemon) i nie zablokuje aktualnej konsoli, do takiego kontenera możemy się zalogować wykorzystując konsolę poprzez:
sudo lxc-console -n NAZWA
bądź ssh - adres ip kontenera po uruchomieniu, jeżeli go nie znamy, można sprawdzić poprzez (dla kontenera uruchomionego):
sudo lxc-info -n NAZWA
Ponieważ przygotowanie konfiguracji "czystego" systemu może trochę zająć (ustawienie hasła, instalacja podstawowych pakietów, itd....) dlatego po przygotowaniu "wzorcowego" systemu (kontenera) proponuję korzystać z polecenia:
sudo lxc-clone NAZWA NOWA-NAZWA
i dopiero tak otrzymanego klona konfigurować pod specyficzny projekt / wykorzystanie - to zaoszczędzi nam trochę pracy :)
W przypadku LXC (tak jak Xena) w konfiguracji połączenia sieciowego korzystamy ze standardowych mechanizmów GNU/Linuksa (o ile nie korzystamy z open vswitcha – http://openvswitch.org/, którego ja jednak nie miałem jeszcze okazji wypróbować) – domyślnie kontenerom przyznawane są adresy ip po dhcp (nie musimy instalować i konfigurować serwera dhcp, LXC to za nas zrobi), wszystkie kontenery podłączone są do mostku sieciowego w systemie hosta (masquerade i forward pakietów ip też zostaną ustawione przez LXC) – po uruchomieniu kontenera, powinien on mieć dostęp do Interneru bez konieczności konfiguracji żadnych dodatkowych elementów.
Czyż to nie jest proste?
Podsumowując – każdy z rodzajów wirtualizacji ma swoje plusy i minusy, w tym artykule nie chodziło mi o wskazanie żadnego „jedynego słusznego” sposobu – wszystko zależy od naszych potrzeb. Decydując się na skorzystanie z dobrodziejstw wirtualizacji, wobec mnogości dostępnych rozwiązań, warto przemyśleć czy aby na pewno „pełna” wirtualizacja jest dla nas najlepsza w danym przypadku (bo w 95% będziemy właśnie taką wirtualizację rozważać w pierwszej chwili). Jeżeli tylko możemy, korzystajmy z wirtualizacji „tańszej” - np. w GNU/Linuksie z LXC – to pozwoli nam pracować szybciej i uczyni nasze życie znacznie prostszym :)
linki:
hypervisor: http://en.wikipedia.org/wiki/Hypervisor
vmware: http://www.vmware.com
virtualbox: https://www.virtualbox.org
xen: http://www.xenproject.org
lxc: https://linuxcontainers.org