Spotkałem się już setki razy z pytaniami typu “czy warto jest wirtualizować” albo “co to właściwie daje” czy “a czemu po prostu nie odpalić paru usług na jednej maszynie”. To tak w skrócie:

Zalety:

Lepsze wykorzystanie maszyny

Gdy masz parę maszyn które przez większość czasu nic nie robią np. maszyny devowskie z testową aplikacją, wewnętrzne aplikacjie (CRM, wiki), repozytorium ze żródłami itp. itd. zastąpienie paru maszyn maszyną z wirtualkami serwującymi te usługi zwolni trochę miejsca i zużyje mniej prądu.

Łatwe tworzenie środowiska developerskiego

Wczytaj snapshoty z backupu, odpal, pozmieniaj parę rzeczy i wrzuć wersję developerską aplikacji, umożliwia to testy na środowisku prawie identycznym jak “produkcja” a samo odtworzenie z backupów zajmuje niewiele. Oraz umożliwia testowanie do woli, bez obawy że “ooo bo posuje serwer devowski i będę musiał zrobić reinstalkę” ;]

Czy druga opcja, test jak aplikacja bedzie się zachowywała na x maszynach. Tworzymy jedną, potem klonujemy i można przeprowadzać testy. Użyteczne przy np. zabawach/testach rozproszonych systemów plików czy baz danych.

Oraz można wziąć potem taką “developerską” maszynę na laptop i potem zrobić prezentację naszej aplikacji klientowi ;]

Szybki/wygodny backup/restore

Backupowanie snapshotu maszyny praktycznie jest nieinwazyjne (zatrzymuje maszynę na max. sekundę) a odtworzony snapshot to właściwie gotowa do działania maszyna i będzie działać nawet gdy snapshot zostanie odtworzony na maszynie z zupełnie innym sprzętem.

Łatwy upgrade sprzętu

Jako że wszystkie urządzenia widziane przez maszyny wirtualne są emulowane, nie potrzeba żadnej zmiany driverów w wypadku zmiany sprzętu hosta. Czasami przydaje się gdy jakaś stara-ale-absolutnie-niezbędna-i-nie-nie-ma-upgradu wymaga koniecznie Windows 2000 a akurat nie ma do niego driverów do naszego kontrolera SATA.

Wady

Gorsza wydajność

Ale tylko gdy aplikacja obciąża maszynę w więcej niż 70-80% – wtedy straty zaczynają być widoczne. Przy czym najmniej “boli” CPU – tu strata wydajności jest prawie niezauważalna, większe są straty przy korzystaniu z dysku, chociaż to można ograniczyć dając maszyną wirtualnym bezpośrednie przypisanie do “fizycznych” dysków lub volumenów w LVM zamiast użycia “plikopartycji”. Tylko znowu “plikopartycje” są wygodniejsze i zajmują mniej miejsca gdy nie są pełne, coś za coś ;]. W skrócie, jeżeli masz pare “webheads” (serwer tylko z  aplikacją + ew. jakiś memcached, czy jakiś proxy cache) które są obciążone, to prawdopodobnie nie są dobrymi kandydatami do wirtualizacji, tak samo jak obciążony serwer MySQL. Takie maszyny łatwo jest odzyskać nawet bez snapshotu.

Większa awaryjność

Gdy pada host, wszystkie wirtualki padają. Są rozwiązania HA pozwalające temu zapobiec (chociażby dzielenie dysku między dwoma maszynami przez DRBD) ale generalnie dobrze mieć backup snapshotów gotowy do odtworzenia na innej maszynie  (oraz ofc. zapasową maszynę) jeżeli uruchomione usługi są krytyczne.

Chociaż to samo można powiedzieć o konfiguracji “jeden OS, wiele usług”, ale w porównaniu do trzymania każdej usługi na innej maszynie jest to jednak trochę bardziej awaryjne. Czyli trzeba implementować z głową ;)

Ale ejst jeszcze jedna rzecz, związana z tym jak działa fsync. Otóż bazy danych polegają na tym że po wywołaniu fsync() dane znajdują się na fizycznym dysku a nie obijają się gdzieś w RAMie. I wszystko jest w porządku gdy to jest fizyczna maszyna, ale w wypadku wirtualizacji takie żądanie “propagowane jest” tylko do wirtualnego dysku maszyny, a gdy “dociera” do hosta ten nie ma informacji że te dane muszą natychmiast wylądować na dysku i są cachowane. A gdy ma się odpowiednio dużo pecha coś takiego może skończyć się uszkodzeniem bazy. Chociaż akutalnie część systemów implementuje to poprawnie (wiem że KVM tak robi) więc to przestaje być zmartwieniem.

O czym pamiętać przy implementacji?

… żeby nie ponieść porażki i nie zyskać paru siwych włosów ;]

• Backup! – Backup snapshotów zajmuje więcej niż backup samych danych ale jest dużo szybszy w wypadku recovery (nie trzeba niczego reinstalować/konfigurować), gdy jest miejsce zalecam codzienny snapshot, ale gdy chcemy oszczędzać to co tydzień + dzienny backup danych (baza/aplikacja/maile itp.)
• Więcej niż jedna maszyna – Jeżeli jest to tylko możliwe, wtedy nawet jak jedna padnie to odpalenie usług z niej an drugiej to kwestia paru komend. Gdy mamy już dwie możemy zapisywać snapshoty z jednej na drugiej i vice versa (jeżeli nie są zbyt wielkie), wtedy możemy zrobić szybkie recovery bez sięgania do backupu. Albo DRBD.
• RAM, RAM, RAM – Im więcej tym lepiej, w końcu uruchamiasz parę “maszyn” na jednej
• **Wydajność dysków **– Nie ma aż takiego znaczenia gdy użycie maszyn jest niewielkie, ale gdy parę maszyn korzysta intensywnie z dysku, muszą być one odpowiednio szybkie
• Poznaj dobrzer narzedzie zanim pójdzie na produkcję – ale to się tyczy wszystkiego ;]
• Wirtualizowanie niektórych rzeczy nie ma sensu – Serwer MySQL dociążony w szczycie do 80% po przeniesieniu na wirtualkę zyska jakies 15% loadu, bez żadnych widocznych korzyści, z racji tego że nowy serwer to praktycznie przegranie my.cf +  restore z dumpa. Generalnie rzeczy łatwe do odtworzenia i bardzo obciążone lepiej pozostawić na maszynach fizycznych.

Jak coś pominałem, comment, dopiszę :)