Po co mi to?
Wiele razy miałem do czynienia z serwerami na których działało kilka/kilkanaście usług równocześnie, np. Apache (kilka stronek, webmail, phpmyadmin, itp), Postfix/Exim (poczta i żeby było fajnie to na kontach systemowych), Samba (jakieś zasoby dla pracowników), MySQL (baza dla stronek), PostgreSQL (bo jedna stronka potrzebowała), itd…. Przy takiej konfiguracji pomijane są kwestie separacji usług zewnętrznych/wewnętrznych - no ale firma/instytucja mała nie ma sensu kasy na 3 kolejne serwery wydawać skoro działa….
Taka konfiguracja nie jest zbyt bezpieczna i ma wiele wad:
- ciężko backupować tak duży system w postaci obrazów, a odzyskiwanie z backupów całości będzie trwać wieki,
- słaba separacja usług ułatwia ataki na zasoby wewnętrzne (np. dziura w stronie może pozwolić na dostęp do plików z Samby),
- trudno rozgraniczyć zasoby sprzętowe (procesor, pamięć) konkretnym usługom,
- trudno jest migrować usługi na inne serwery.
Wirtualizacja pozwala na zminimalizowanie tych problemów:
- backupować można pojedyncze usługi (działające na różnych maszynach wirtualnych) np. z pomocą snapshotów z minimalnym czasem przerwy w działaniu,
- oddzielenie usług w osobnych maszynach wirtualnych pozwala “zamknąć” napastnika w przypadku kompromitacji którejś z usług (choć zdarzały się błędy w implementacji maszyn wirtualnych pozwalające “wyskoczyć” z wirtualki),
- możemy przydzielać pamięć i konkretne rdzenie procesora danym maszynom wirtualnym,
- live migration pozwala w locie przenieść maszynę wirtualną na inny serwer.
Xen jest szczególnie dobrym wyborem jeżeli zamierzamy wirtualizować systemy Linux’owe. Można je uruchamiać w trybie para-wirtualizacji, która w mniejszym stopniu niż pełna wirtualizacja obciąża CPU.
W trybie pełnej wirtualizacji można zainstalować praktycznie dowolny system (również Windows) choć jest to tryb mniej wydajny.
Uwaga
Post ten jest próbą zebrania w jednym miejscu różnych moich doświadczeń z Xen’em ale nie miałem czasu na testową instalację według poniższego tekstu, więc mogłem gdzieś coś zamieszać. Dlatego proszę o komentowanie jeśli coś nie zadziała.
Konfiguracja hypervisor’a (Dom0)
Jeżeli zastanawiasz się czy stawiać Xen’a na 32 czy 64-bitowym systemie to wybierz 64-bit. Na systemie 64-bitowym można uruchamiać systemy gości 32 i 64-bitowe (w przeciwieństwie do hypervisora 32-bitowego) i nie będzie problemów z obsługą dużej ilości pamięci.
Zaczynamy od instalacji hypervisor’a, zmodyfikowanej do działania z Xen wersji jądra i pakietu podstawowych narzędzi. Wszystko co potrzebne jest w jednym metapakiecie (xen-linux-system ale gdyby nie chciał iść to lepiej wskazać konkretną wersję):
apt-get install xen-linux-system-2.6-xen-amd64
By mieć dostęp do pełnej wirtualizacji (np. by uruchamiać systemy Windows) należy doinstalować jeszcze jedną paczkę (jeśli nie potrzebujemy to zawsze można doinstalować później):
apt-get install xen-qemu-dm-4.0
Squeeze domyślnie korzysta z GRUB’a 2 i niezbyt przeze mnie lubianej metody wykrywania systemów, która po zainstalowaniu jajka dla Xen’a nadal będzie domyślnie startować podstawowy kernel. By to zmienić proponuję przenieść wykrywanie domyślnego systemu na pozycję późniejszą niż Xen’a - zmieniamy nazwę pliku:
mv /etc/grub.d/10_linux /etc/grub.d/21_linux
Ponadto jeżeli zamierzamy instalować DomU na LVM’ie to na pewno zainteresuje nas wyłączenie opcji OS prober by DomU nie były wykrywane jako zainstalowane lokalnie systemy (wyłączy to też wykrywanie Windowsa jeśli jest zainstalowany na tej samej maszynie).
By wyłączyć OS prober’a otwórz plik /etc/default/grub i dodaj na końcu:
# Wylaczenie OS prober'a by nie wykrywac maszyn wirtualnych na
# logicznych wolumenach LVM i nie pokazywac ich w menu grub'a
GRUB_DISABLE_OS_PROBER=true
Jeżeli chcesz dodać jakieś dodatkowe parametry przy bootowaniu Xen’a dodaj poniższe zmienne w /etc/default/grub (przypisane wartości nie są prawidłowe i jeśli nic nie potrzebujesz dodawać to pomiń ten krok):
# parametry dla wszystkich opcji startowych Xen'a (rowniez recovery)
GRUB_CMDLINE_XEN="something"
# dodatkowe parametry dla opcji non-recovery
GRUB_CMDLINE_XEN_DEFAULT="something else"
Po modyfikacji opcji gruba musimy wykonać aktualizację poleceniem:
update-grub
Domyślnym zachowaniem dom0 Xen’a przy wyłączaniu bądź restartowaniu jest próba zahibernowania wszystkich działających domU. Gdy nie przewidzimy takiej sytuacji i nie mamy wystarczającej ilości wolnego miejsca w /var często proces ten kończy się błędami. Zdarzają się też problemy z prawidłową obsługą hibernacji po stronie systemów działających w domU, wtedy po uruchomieniu dom0 i próbie załadowania zapisanych stanów maszyn kończymy z wiszącymi wirtualkami.
Na dobrą sprawę równie dobrym zachowaniem byłoby wyłączenie wszystkich domU i zaczekanie aż to nastąpi a po starcie dom0 uruchomienie ich od zera. Może cały proces będzie trwać chwilę dłużej ale mamy za to większą pewność że przejdzie bez niespodzianek. By ustawić takie zachowanie Xen’a edytujemy /etc/default/xendomains:
XENDOMAINS_RESTORE=false
XENDOMAINS_SAVE=
Aby systemy domU miały dostęp do sieci należy w pliku /etc/xen/xend-config.sxp upewnić się że network-script ustawione jest na network-bridge.
(network-script 'network-bridge antispoof=yes')
Przy takim ustawieniu systemu domU będą korzystać z głównego interfejsu dom0 aby uzyskać dostęp do sieci. Dla wielu będzie to niezbyt optymalne rozwiązanie ale na początek wystarczy (niecierpliwi mogą zerknąć do dokumentacji Xen’a aby sprawdzić inne opcje XenNetworking ).
Dodatkowa opcja antispoof=yes aktywuje firewall, który uniemożliwi systemom domU przypisywanie sobie adresów innych systemów domU. By to działało w konfiguracji maszyny wirtualnej w definicji interfejsu (vif) należy przypisać adres IP danemu systemowi domU.
Na moim systemie nie wszystkie skrypty dla konfiguracji sieci miały atrybut do wykonywania co skutkowało błędami przy uruchamianiu domU (np. “missing vif-script, or network-script, in the Xen configuration file”). By temu zapobiec ustawmy wszystkim skryptom odpowiednie uprawnienia:
chmod +x /etc/xen/scripts/*
W pliku /etc/xen/xend-config.sxp można ponadto ustawić jak dużo pamięci i procesorów rezerwujemy dla systemu dom0. Ilość pamięci dla dom0 można ograniczyć dodając opcję dom0_mem dla kernela w zmiennej GRUB_CMDLINE_XEN w konfiguracji gruba.
Niektórzy zalecają wyłączenie dom0-balloning (czyli zajmowania przez dom0 całej pozostałej pamięci po uruchomieniu systemów domU), a zamiast tego przydzielenie minimalnej ilości pamięci, np. tak:
(dom0-min-mem 1024)
(enable-dom0-ballooning no)
Ja osobiście wolę pozostawić balloning włączony - po co blokować ram skoro nikt inny z niego nie skorzysta, a tak to przynajmniej jest więcej na bufory dyskowe 😉
Ustawienie konsoli
By mieć dostęp do wyjścia z GRUB’a, Xen hypervisor’a, kernela i getty poprzez VGA i konsolę należy dokonać zmian w pliku /etc/default/grub jak poniżej:
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1"
GRUB_TERMINAL="console serial"
GRUB_TIMEOUT=5
GRUB_CMDLINE_XEN="com1=9600,8n1 console=com1,vga"
GRUB_CMDLINE_LINUX="console=tty0 console=hvc0"
A następnie w /etc/inittab aktualizujemy linijki:
1:2345:respawn:/sbin/getty 38400 hvc0
2:23:respawn:/sbin/getty 38400 tty1
# NO getty on ttyS0!
W ten sposób tty1 pokazuje wyjście VGA, a hvc0 kosolę. Standardowo po modyfikacji opcji gruba musimy wykonać aktualizację poleceniem:
update-grub
Jeśli nic nie skopaliśmy to po restarcie powinniśmy otrzymać hypervisora gotowego do uruchamiania DomU.