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ę :)
24 ResponsesLeave a comment ?
“maszyny devowskie z testową aplikacją, wewnętrzne aplikacjie (CRM, wiki), repozytorium ze żródłami itp. itd. ”
O ile to wszystko nie zajeżdża fizycznych maszyn aktualnie.
U mnie pod wirtualizacje nadają się jedynie krótkie małe projekty, które nie wiadomo czy wypalą i w zasadzie nie ma sensu kupowanie pod nich maszyn.
Reszta leci na fizyczne maszyny, bo nigdy nie zdarza się tak, żeby baza, aplikacja, crony itd leżały na jednej maszynie.
Nie wydaje mi się, aby miejsce na snapshoty było aż taką wielką inwestycją skoro 1 tera kosztuje ~500zł.
Jeśli chodzi o te 15% loadu po przeniesieniu mySQL’a. Wydaje mi się, że to może się i tak opłacać jeśli zyskasz po prostu spójne środowisko łatwiejsze do zarządzania.
Gdzie kupujesz dyski 1TB za 500zł vendora DELL, HP, IBM whatever ? SATA/SAS ?
15% na LOAD to dużo jeżeli w szczycie może to przełożyć się na wzrost load-u np. x2.
Nie no chyba na zapisywanie snapshotów nie potrzeba jakiejś rewelacji?
Nawet jeżeli jest to maszyna tylko do trzymania snapshotów to nie włożysz do tego nie firmowych dysków, bo jak vendor sobie nagle zmieni politykę jak chodźby ostatnio Dell i przestanie obsługiwać nie vendorowe dyski to można mieć ostrego zonka.
A trudno uznać, że się już update-u FW nie zrobi na maszynie, bo różne kwiatki wychodzą w różnych okresach użytkowania.
Mała uwaga – snapshoty nie służą do backupów i nie jest zalecane opierać systemu backupowego właśnie snapshopty :)
@Maciek – wszystko zależy, jak np. kupiłeś dedyka z OVH z 2x dyskiem SSD to już tak łatwo tam nie można dołozyć.No ale tam akurat można dokupić “Dysk USB” więc to aż takim problemem nie jest. Głównie chodzi o przypadki gdy serwer ma pareset giga danych, wtedy trzeba backupować dane oddzielnie
@Łukasz – serio ? Jak włożysz dysk SATA “własny” to tracisz gwarancję na cały serwer ?
@bns – zależy czy tylko snapshotujesz zawartość dysku czy używany system wirtualizacji oferuje “prawdziwy snapshot”, razem ze stanem RAMu i CPU, w tym pierwszym przypadku z punktu widzenia maszyny wyglada to jakby ktoś jej wcisnął przycisk reset. Ale można to obejść po prostu zamykając maszynę na snapshot (jeżeli jest to możliwe) albo przełączając aplikację “w środku” w “tryb backupu” (np posgres ma pg_start_backup, inne można po prostu zamknąć na te 2 sekundy)
Nie tracisz gwarancji, tylko nie będą działać, np. kontroler przestanie je widzieć. Dell zrobił to wyjątkowo fajnie bo w połowie życia generacji 11 zrobił upgrade FW i dyski nie ventora przestały działać. Można złapać zdziwko, a dyski zazwyczaj kupujesz razem z serwerem.
Dlatego uważam, że ktoś kto kupuje nie firmowe dyski do serwerów ma niezłe jaja. Ja niestety wolę dopłacić i mieć pełen support na to, szczególnie że jest to jeden z najczęściej padających elementów.
Heh zaczynam coraz mniej lubić Della, takie tricki to cios poniżej pasa ;/
Kilka luźnych spostrzeżeń, nie zawsze związanych z tematem.
1. 1T za 500PLN: pecety to pół biedy. Serwery to 3/4. Problemem może być macierz. 1T za 15-20kE? :)
2. wirtualizacja: wirtualizacja ma pewną wadę: x wirtualnych maszyn jest tak bezpiecznych jak bezpieczny jest system wirtualizujący.
3. jedna maszyna: do poważniejszych zastosowań wirtualizacja ma tylko sens wtedy, gdy system wirtualizujący może pracować w sposób rozproszony na wielu maszynach. Ale to kosztuje.
4. Do łatwego, seryjnego tworzenia środowisk wystarczy dobrze napisany kickstart. Wirtualizacja rozwiązuje nam inne problemy :)
5. Padanie Delli: ogólnie jakość Della ostatnimi laty poleciała na ryj: 2550 i 2650 nam chodzą jak złoto, 2850 w ostatnim czasie zdechło co najmniej kilka (dyski, pamięć, backplane).
@r:
R610, R710 – chodzą ładnie, nie narzekam, serial 2900 też chodzi, padł jeden dysk z 14 w 2 maszynach, ale to już sprawa losowa, support w 4h dosraczył nowy.
@1 – właśnie, wszystko zależy od zastosowania ;]
@2 – w porównaniu do podobnego rozwiązania, czyli parę usług odpalonych na jednym OSie bezpieczeństwo jest podobne. Ofc w wypadku gdy zastępujemy parę maszyn jedną trzeba zadbać by była ona NAPRAWDĘ bezpieczna ;]
@3 – wszystko zależy ile downtime jesteśmy w stanie tolerować, proste rozwiązanie typu 2 maszyny + DRBD sprawują się ludziom dobrze ;]
@4 – ja po prostu robię debianowe paczki, instalacja 1 paczki = konfiguracja systemu, instalacja drugiej = docelowa aplikacja jest zainstalowana. Póki dbasz żeby wszystkie zmiany szły do paczek (przydaje się repo dla “produkcji” i “dev”) działa idealnie i w razie problemów można się cofnąć w wersji.
@5 – widocznie tną koszty na czymś ;]
@Xani: ad. 5. koszty tną oczywiście na jakości :)
ad. 4. Debian na tym polu leży. Kickstart daje mi możliwość zainstalowania maszyny od ,,gołego metalu” do gotowego, skonfigurowanego serwera za pomocą ,,linux ks=” (plus oczywiście praca na przygotowanie pliku) i za parę minut serwer jest gotowy do pracy. Dodatkowo KS w RHEL5 (nowszych jeszcze nie oglądałem) pozwala zrobić wiele rzeczy, które wcześniej wymagały pisania skryptów postinstalacyjnych (np. flagi na FS-ach, zakładanie użytkowników). Debian niby ma podobny mechanizm, tylko że panowie np. jeszcze nie doszli do tego, że nienadzorowana instalacja na LVM-ie to nie jest fanaberia (o ile pamiętam, można sobie założyć partycję pod LVM, ale to by było na tyle — taki LVM dla samego posiadania partycji LVM-a), a składnia narzędzia powinna zapewnić możliwość szybkiego nauczenia się i użycia go, a nie doktoryzowania się z ,,overengineered solutions” :)
@Łukasz: Delli mamy grubo ponad 60 sztuk. R i M dopiero po kilka, reszta to starsze PE zarówno rackowe, jak i kasetowe. Blade’y chodzą, 2650 chodzą, 2550 gdzieś się wydarzy i wciąż żyje. Mamy mnóstwo 2850, które zaczęły nam się sypać seriami — głównie pamięci, ale w jednym coś się pochrzaniło z backplane (przestał widzieć dysk, pomogło przełożenie go w inny slot), a i parę dysków też zdążyło zejść. Mamy też sporo 2950 i trochę się o nie boimy. Trzeba obowiązkowo przedłużać support tak długo, jak się da, a potem wymieniać krytyczne maszyny na nowe.
Co do kickstarta, ja po prostu używałem prekonfigurowanego obrazu wirtualki (z wrzuconymi kluczami ssh i odpowiednimi repo), do instalowania maszyn fizycznych może i lepszy :). Tylko gdy chcesz “cofnąć wersję” to w grę wchodzi cała reinstalka a w przypadku paczek tylko cofasz wersję paczki (ofc musi być odpowiednio napisana). Oraz łatwiej jest w taki sposób później akutalizować serwer a to się robi znacznie częściej niż instalacja od zera ;]
@XANi: nie musisz nic reinstlować, base system leci z kickstarta, a później już normalne paczki z własnego repozytorium w takich wersjach jak się chce. Instalacja takiego base systemu zajmuje na średniej klasy maszynie około 3-4min do pełnego zabootowania się. Później chwila z puppetem i około 10min masz gotową maszynę (o ile odpowiednio szybko zmieniasz sobie vlan-y ;-D)
@r: To ja mam podobne przemyślenia co do HP, dlatego zaczęliśmy mieszać to z Dell-em który odpukać jak na razie jest mało awaryjny. A w HP to przerabiałem już pady wszystkiego zasilacze, wentylatory, backplainy, płyty, pamięci dokładnie jak twoje przygody z Dell-em ;-D Pocieszające jest, że znajomy posiada akurat dużo SUNów i ma dokładnie tak samo, więc jak widać każdy vendor jest z dupy.
@Łukasz – muszę w końcu zapoznać się z puppetem albo czymś podobnym (myślałem o cfengine), tylko odstarsza mnie ilość rzeczy do opanowania zanim się odpali podstawę
@XANi: pobieżnie obejrzałem cfengine i przyznam, że nie wyobrażam sobie zrobienia tego co mam puppecie.
Pewnie by się dało po dokładniejszym zapoznaniu, każde z tych tooli (Chef, Puppet, Cfengine) jest bardzo potężne ale wymaga też sporo nauki. Dla moich potrzeb są overkillem, wystarczyłoby mi proste “wsadź wartości do templata według typu hosta” ale czegoś sensownego nie znalazłem jeszcze.
file { “/etc/php.ini”:
owner => root,
group => root,
mode => 644,
source => [
"puppet:///www/$hostname/php.ini",
"puppet:///www/$hostgroup/php.ini",
"puppet:///www/default/php.ini",
]
}
Przykład z brzegu, dopasowuje pliki w powyższej kolejności, najpierw sprawdza czy istnieje katalog odpowiadający zmiennej $hostname, później $hostgroup, a jak nie ma żadnego bierze default.
I właśnie o coś takiego mi NIE chodzi ;p, raczej o coś typu:
if ($hostname =~ /dev/) {
php.memory_limit = 32M
} elsif {$hostname =~ /prod/} {
php.memory_limit = 48M
} else {
php.memory_limit = 16M
}
tak, wiem że pewnie się da w każdym z tych 3 systemów ale trzeba się trochę w to wgryżć a nie administruje tyloma maszynami żeby warto było w tym grzebać, więc na razie po prostu wrzucam config do paczek.
To też się da zrobić dość banalnie.
Ustawiasz sobie zmienna na jakąś wartość, a później wrzucasz taką do config-a.
http://projects.reductivelabs.com/projects/puppet/wiki/Puppet_Templating
—–BEGIN PGP SIGNED MESSAGE—–
Hash: SHA1
“Backupowanie snapshotu maszyny praktycznie jest nieinwazyjne (zatrzymuje maszynę na max. sekundę)”
To chyba w VBoxie ;) VMware backupuje maszynę w locie – bez potrzeby wstrzymywania jej pracy. Bardzo wygodne rozwiązanie.
—–BEGIN PGP SIGNATURE—–
Version: GnuPG v1.4.10 (MingW32)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.8)
iEYEARECAAYFAkwcmGMACgkQHrUFeOTlcqteIwCfW05cZ1+OQvJFjlofR0faSKYZ
XcUAoMTPW5dqpIbrzE7J4nMcVZ/9G+CK
=l0hh
—–END PGP SIGNATURE—–
Kickstart to bardzo fajna idea, aczkolwiek w porównaniu z autoyastem w SUSE to widać dopiero iż panowie z RedHata za późno zabrali się za ten projekt.
Aczkolwiek bardzo mi się podoba, więcej w nim NIE można zrobić niż można zrobić.
Konfiguracji z paczek debiana zupełnie sobie nie wypbrażami – może jakiś mały wykładzik z tego tematu?
A co do serwerów – jako stary inżynier serwisowy (i przy okazji HP Cert) mogę powiedzieć: uciekajcie od Della ;)
HP/IBM WSZYSTKO będzie lepsze od tego plastiku :)
Przy wirtualkach się sprawdza, przy serwerach “fizycznych” pewnie bym skorzystał z czegoś innego a paczek używał jako uzupełnienie (dodanie własnych tooli itp.).
A o samym stawianiu prostego repa dla własnych tooli i duperelek w stylu kustomizacji shella (takie małe tweaki się przydają, ja mam shella zmieniającego kolor w zależności od tego czy to produkcja/dev/host dla wirtualek) skrobne w końcu, jak na razie upał odbiera mi chęć do życia ;]