Przejście z XEN na OpenVZ

[dan 2]

Witam,

 

wygląda na to, że będę miał w niedalekiej perspektywie przejście na OpenVZ. VPS mam aktualnie na wirtualizacji XEN, Debian 5 i DA.

Nigdy nie korzystałem z wirtualizacji OpenVZ - czym ona (pomijając kwestie innego podziału/udostępniania zasobów oraz kwestie innego podejścia do przyznawania pamięci i braku swapa) się różni od XENa?

 

Czy w codziennym użytkowaniu maszyny pod usługi zarządzane DA może mi czegoś brakować, coś może mnie ograniczać w jakim zakresie?

 

Ktoś przechodził podobne migracje i może się wypowiedzieć?

 

Aha, wstępnie wygląda, że ów OpenVZ będzie miał szybszy dysk i 2,5x więcej pamięci gwarantowanej niż mam dotychczas na XENie.

Edytowano Październik 6, 2011 przez dan (zobacz historię edycji)

[Biszkopcik 37]

Przechodziłem taką migracje tylko w odwrotnym kierunku. Nie wiem jak możesz chcieć przejść na OpenVZ gorszego wyboru chyba nie ma. A różni się to wieloma rzeczami, np. tym że nie ma swapu, NIE ma gwarantowanych zasobów (więc jak możesz mieć 2,5x więcej gwarantowanej pamięci?), nie masz dostępu do niektórych modułów jajka (iptables nie hula, kilka innych rzeczy pewnie też), nie masz dostępu do własnego jajka (tyczy się tylko xen z HVM nie PV), openvz pobiera ci znacznie więcej pamięci z racji tego że nie ma pełnej wirtualizacji oraz nie ma swapu (dla porównania taka sama konfiguracja na openvz zjadała mi 380 mb ramu a na XEN 240), nie masz też gwarantowanego cpu itd. Co do dysku , zapewne mówisz o SAS, ale co ci po tym? Jak i tak tam może być upchanych pełno userów i prędkość jeszcze gorsza od tego na XEN'ie. Na OpenVZ dużo łatwiej stosować overselling. Zapewne jest jeszcze kilka innych powodów które mógłbym wymienić ale obecnie już nic nie przychodzi mi do głowy. Myślę że tyle co napisałem wystarczy Ci aby nie robić takiej głupoty.

[malu 460]

Przechodziłem taką migracje tylko w odwrotnym kierunku. Nie wiem jak możesz chcieć przejść na OpenVZ gorszego wyboru chyba nie ma. A różni się to wieloma rzeczami, np. tym że nie ma swapu, NIE ma gwarantowanych zasobów (więc jak możesz mieć 2,5x więcej gwarantowanej pamięci?), nie masz dostępu do niektórych modułów jajka (iptables nie hula, kilka innych rzeczy pewnie też), nie masz dostępu do własnego jajka (tyczy się tylko xen z HVM nie PV), openvz pobiera ci znacznie więcej pamięci z racji tego że nie ma pełnej wirtualizacji oraz nie ma swapu (dla porównania taka sama konfiguracja na openvz zjadała mi 380 mb ramu a na XEN 240), nie masz też gwarantowanego cpu itd. Co do dysku , zapewne mówisz o SAS, ale co ci po tym? Jak i tak tam może być upchanych pełno userów i prędkość jeszcze gorsza od tego na XEN'ie. Na OpenVZ dużo łatwiej stosować overselling. Zapewne jest jeszcze kilka innych powodów które mógłbym wymienić ale obecnie już nic nie przychodzi mi do głowy. Myślę że tyle co napisałem wystarczy Ci aby nie robić takiej głupoty.

 

Dużo zależy od usługodawcy. Więc musiałbyś danego usługodawce o szereg rzeczy wypytać.

 

Co do SWAP, od nie dawna na RHEL6 dostępne jest "rozszerzenie" UB/UBC, które nazwano "vswap" ; )

Więc od tego momentu jest na serwerze swap, jednak jest on emulowany przez RAM, zapobiegając muleniu i/o dysku.

Dodatkowo model zliczania pamięci się zmienił, w zasadzie może nie tyle zliczania, co kontrolowania.

openVZ OpenVZ nie równy.

 

Przykładowy logi: free i meminfo

RHEL6: (2.6.32)

root@node1:/# free -m
        	total   	used   	free 	shared	buffers 	cached
Mem:      	8192    	498   	7693      	0      	0     	59
-/+ buffers/cache:    	438   	7753
Swap:     	4096      	0   	4096

root@node1:/# cat /proc/meminfo
MemTotal:    	8388608 kB
MemFree:     	7879364 kB
Cached:        	60736 kB
Active:       	463072 kB
Inactive:      	17492 kB
Active(anon): 	406116 kB
Inactive(anon):	13712 kB
Active(file):  	56956 kB
Inactive(file): 	3780 kB
Unevictable:       	0 kB
Mlocked:           	0 kB
SwapTotal:   	4194304 kB
SwapFree:    	4194304 kB
Dirty:            	12 kB
AnonPages:    	419828 kB
Shmem:          	7956 kB
Slab:          	17452 kB
SReclaimable:   	4500 kB
SUnreclaim:    	12952 kB

 

RHEL5: (2.6.18)

-bash-4.1# free -m
        	total   	used   	free 	shared	buffers 	cached
Mem:      	3072    	412   	2659      	0      	0      	0
-/+ buffers/cache:    	412   	2659
Swap:        	0      	0      	0
-bash-4.1# cat /proc/meminfo
MemTotal:  	3145728 kB
MemFree:   	2723228 kB
Buffers:         	0 kB
Cached:          	0 kB
SwapCached:      	0 kB
Active:          	0 kB
Inactive:        	0 kB
HighTotal:       	0 kB
HighFree:        	0 kB
LowTotal:  	3145728 kB
LowFree:   	2723228 kB
SwapTotal:       	0 kB
SwapFree:        	0 kB
Dirty:           	0 kB
Writeback:       	0 kB
AnonPages:       	0 kB
Mapped:          	0 kB
Slab:            	0 kB
PageTables:      	0 kB
NFS_Unstable:    	0 kB
Bounce:          	0 kB
CommitLimit:     	0 kB
Committed_AS:    	0 kB
VmallocTotal:    	0 kB
VmallocUsed:     	0 kB
VmallocChunk:    	0 kB
HugePages_Total: 	0
HugePages_Free:  	0
HugePages_Rsvd:  	0
Hugepagesize: 	2048 kB

 

 

Widać, że mamy już tutaj zróżnicowanie co do cache. Mamy SWAP.

[dan 2]

Przechodziłem taką migracje tylko w odwrotnym kierunku. Nie wiem jak możesz chcieć przejść na OpenVZ gorszego wyboru chyba nie ma. A różni się to wieloma rzeczami, np. tym że nie ma swapu, NIE ma gwarantowanych zasobów (więc jak możesz mieć 2,5x więcej gwarantowanej pamięci?), nie masz dostępu do niektórych modułów jajka (iptables nie hula, kilka innych rzeczy pewnie też), nie masz dostępu do własnego jajka (tyczy się tylko xen z HVM nie PV), openvz pobiera ci znacznie więcej pamięci z racji tego że nie ma pełnej wirtualizacji oraz nie ma swapu (dla porównania taka sama konfiguracja na openvz zjadała mi 380 mb ramu a na XEN 240), nie masz też gwarantowanego cpu itd. Co do dysku , zapewne mówisz o SAS, ale co ci po tym? Jak i tak tam może być upchanych pełno userów i prędkość jeszcze gorsza od tego na XEN'ie. Na OpenVZ dużo łatwiej stosować overselling. Zapewne jest jeszcze kilka innych powodów które mógłbym wymienić ale obecnie już nic nie przychodzi mi do głowy. Myślę że tyle co napisałem wystarczy Ci aby nie robić takiej głupoty.

Swap, jak swap to taka wydmuszka - jak system na niego wejdzie to i tak kicha gdyż wydajność spada dramatycznie.

 

W ofercie OpenVZ mam podane RAM gwarantowany 2048MB i RAM dostępny 3072 MB. Czy - bazując na tym, co napisałeś - RAM gwarantowany to przy OpenVZ ściema?

 

Głównym powodem myślenia o migracji jest dla mnie słaba wydajność dysku na XENie - co jest podstawową przyczyną zwalniania mojego VPS. iowait ostatnio coraz częściej idzie w jakieś kosmiczne wartości bez jakiejś radykalnej zmiany w ilościach zapytań do mojego VPS - co by oznaczało, że maszyna matka ma problemy. Szczególnie jest to widoczne na serwisach, które bazują na robudowanych aplikacjach PHP inkludujących wiele plików przy uruchomieniu.

 

Teoria mówi, że w takim przypadku SSD powinien się sprawdzić wyśmienicie + 2,5x więcej RAMu... Chyba, że ten gwarantowany w przypadku OpenVZ to ściema - może ktoś potwierdzić?

 

Jeśli założymy, że SSD jest wydajniejszy jakieś 10-20x to - pospekulujmy - jaki overselling stosuje się przy OpenVZ? Bo jak 5-10x to TEORETYCZNIE i w odniesieniu do dysku i tak jestem 2x do przodu. Zaznaczam, że zużycie procka na XEN mam w granicach 10-20%, a to dysk mnie w tej chwili limituje.

 

Piszesz, że OpenVZ pobiera więcej RAMu bo to niepełna wirtualizacja - ja spotkałem się z opiniami, że wręcz przeciwnie - rzekomo to w przypadku XEN idzie więcej RAMu na system.

 

Co do dostępu do jądra - świadomie nigdy nie korzystałem, z iptables też nie (czyli widocznie nie miałem potrzeby). Czy w zwykłym utrzymaniu serwera pod aplikacje webowe PHP, MySQL, PostgreSQL, Apache dostęp do jądra jest przydatny? Albo do czegoś co jest niedostępne w OpenVZ? (svn, git, ngix tym podobne mogę zainstalować, czy będą jakieś problemy?)

 

W OpenVZ mam dostęp do roota, czyli mogę instalować DA, ISPConfig itp bez problemów, tak?

Jak wygląda struktura plików na dziewiczym OpenVZ? To jest tak jakbym miał goły system powiedzmy wybrany Debian na XEN czy jakoś inaczej to wygląda?

 

Dużo zależy od usługodawcy. Więc musiałbyś danego usługodawce o szereg rzeczy wypytać.

 

Czyli np. o co konkretnie? O co Ty byś wypytał i na co zwracał uwagę, co by Cię zachęciło a co odstraszyło?

Edytowano Październik 6, 2011 przez dan (zobacz historię edycji)

[Biszkopcik 37]

Oczywiście masz dostęp do roota na OpenVZ i możesz wszystko instalować. Iptables przydaje się do ograniczania ataków i blokowania ich (jak ktoś cię zacznie atakować to przekonasz się), natomiast dostęp do jajka jest bardzo przydatny, przy własnym skompilowanym jądrze możesz podnieść wydajność aplikacji (ale sądzę że to już dla większych projektów).

 

Tak jak powiedział malu, raz masz tą gwarancje a raz nie ( w większości nie ), moim zdaniem hostingi biorą openvz najczęsciej dlatego żeby robić overselling. Z racji tego że jest to dość łatwe.

 

Trafiłeś na kijową maszynę, może po prostu poproś o przeniesienie na jakąś mniej obciążoną? A co do SAS możesz mieć tak samo jak teraz z tym VPS, jeżeli będzie mocno obciążone I/O to różnica będzie znikoma albo i nawet gorsza (choć nie wykluczam że może być i lepiej).

 

Zdania co do wyboru wirtualizacji są bardzo podzielone. Wszystko zależy jakie praktyki stosuję dana firma.

[dan 2]

Trafiłeś na kijową maszynę, może po prostu poproś o przeniesienie na jakąś mniej obciążoną? A co do SAS możesz mieć tak samo jak teraz z tym VPS, jeżeli będzie mocno obciążone I/O to różnica będzie znikoma albo i nawet gorsza (choć nie wykluczam że może być i lepiej).

 

Źle napisałem (już poprawione w poście wyżej). Na OpenVZ, który rozważam są dyski SSD a nie SAS. Stąd moje zainteresowanie.

[d.v 1409]

XENa też da się nadsprzedawać, też można naściemniać, OpenVZ to nie jest zło całego świata skupione w kontenerze wirtualizacyjnym. A przy projektach wykorzystujących ilość pamięci większą od "gwarantowanej" OpenVZ będzie zdecydowanie wydajniejszy od XENa, "burst" na pamięci operacyjnej a swap na dysku to jednak dwie zupełnie inne ligi. Sam mam w tej chwili dwa VPSy na OpenVZ i opiekuję się trzecim i wszystkie są cholernie wydajne. I nawet brak iptables nie boli, w końcu to nie jedyne rozwiązanie. Też obawiałem się przy jednym projekcie (wykorzystującym JBoss) czy OpenVZ się sprawdzi, ale przy zaufanym dostawcy możesz być spokojny - OpenVZ potrafi być świetnym rozwiązaniem, jeśli nie ma oversellingu lub jest on niewielki.

A co do SSD, to zauważyłem w porównaniu z dyskami SATA i SAS olbrzymie przyspieszenie, szczególnie w przypadku działania baz danych.

Edytowano Październik 6, 2011 przez d.v (zobacz historię edycji)

[dan 2]

XENa też da się nadsprzedawać, też można naściemniać, OpenVZ to nie jest zło całego świata skupione w kontenerze wirtualizacyjnym. A przy projektach wykorzystujących ilość pamięci większą od "gwarantowanej" OpenVZ będzie zdecydowanie wydajniejszy od XENa, "burst" na pamięci operacyjnej a swap na dysku to jednak dwie zupełnie inne ligi. Sam mam w tej chwili dwa VPSy na OpenVZ i opiekuję się trzecim i wszystkie są cholernie wydajne. I nawet brak iptables nie boli, w końcu to nie jedyne rozwiązanie. Też obawiałem się przy jednym projekcie (wykorzystującym JBoss) czy OpenVZ się sprawdzi, ale przy zaufanym dostawcy możesz być spokojny - OpenVZ potrafi być świetnym rozwiązaniem, jeśli nie ma oversellingu lub jest on niewielki.

A co do SSD, to zauważyłem w porównaniu z dyskami SATA i SAS olbrzymie przyspieszenie, szczególnie w przypadku działania baz danych.

 

Jak wygląda Twój prywatny, subiektywny ranking wydajności VPS firm, które masz w stopce? Jeśli można z podaniem pakietów owych firm?

[d.v 1409]

Najwydajniejszy sprzętowo oczywiście jest ten z Ultimahost, mam pakiet ovz.2048 z dyskiem SSD. Rewelacyjnie szybki, gdyby było tam szybsze łącze, to byłaby naprawdę genialna maszyna. Ale nawet z limitami na łączu robi świetne wrażenie, szczególnie jeśli wziąć pod uwagę lokalizację w Polsce.

Na drugim miejscu postawię ex aequo MZone (pakiet zarządzany VPS20M na projekt mojej klientki) i Alvotech (lokalizacja niemiecka), pierwszy to OpenVZ w Hetzner, ale maszyna-matka jest prawie w ogóle nie obciążona, drugi korzysta z wirtualizacji Linux-VServer, która jest moim zdaniem bardzo niedoceniana, a do tego matka ma 1-gigowe łącze co też w pewien sposób przekłada się na ogólną wydajność. No i uptime w Alvotech bije rekordy, serwer mam od 139 dni, 2 dni się bawiłem, po instalacji wszystkiego od 137 dni nie było nawet sekundy przerwy (to chyba mój osobisty rekord, żaden inny serwer tyle nie wytrzymał).

Na ostatnim miejscu VolumeDrive (pakiet 1, ma niby 1GB RAMu + 1GB burst, ale u nich zawsze są jakieś błędy, u mnie jest ok. 7GB RAM i ok. 800MB burst). To jest taka typowa amerykańska budżetówka - pamięci i miejsca na dysku dużo i za grosze, ale łącze i dyski w godzinach szczytu nie dają rady, wydajność potrafi spaść dość drastycznie. No i zapomnij o supporcie. Ja wykorzystuję to wyłącznie na backupy.

We wszystkich tych serwerach są raczej mocne 4-rdzeniowe procki (i7 w MZone, Xeony w pozostałych), sporo RAMu. Co do dysków, to tylko w Ultimahost są SSD, pozostali korzystają z SATA i SAS. I to niestety momentami widać - SSD w oczywisty sposób miażdżą konkurencję w operacjach dyskowych, jak masz sporo includów czy ostro korzystasz z SQLa, to zobaczysz prawdziwą silną stronę tych dysków. No i po paru miesiącach użytkowania nie stwierdziłem typowych dla oversellingu objawów, serwer spisuje się tak samo wydajnie i stabilnie jak na początku (a byłem jednym z pierwszych klientów na tej maszynie).

Edytowano Październik 7, 2011 przez Gość (zobacz historię edycji)

[tym 205]

XENa też da się nadsprzedawać, też można naściemniać.

 

Z tego co wiem, to jednak nie da się zrobić oversellu z prostej przyczyny - ram masz gwarantowany...

[malu 460]

Z tego co wiem, to jednak nie da się zrobić oversellu z prostej przyczyny - ram masz gwarantowany...

 

Zapoznaj się z dość starym terminem "ballooning xen"

Pewnie są jakieś jeszcze lepsze techniki na overcommiting w xen

[kafi 2425]

Z tego co wiem, to jednak nie da się zrobić oversellu z prostej przyczyny - ram masz gwarantowany...

To widać mało wiesz...

Nie oszukujmy się - wirtualizuje infrastrukturę się właśnie po to, żeby wykorzystać optymalnie dostępne zasoby.

A nie jest optymalnym leżenie odłogiem 3,99GB pamięci, bo bogaty klient wziął usługę z 4GB i o niej zapomniał

 

Obecnie wszystkie systemy dążą do posiadania technicznych mechanizmów jak najmocniejszej kompresji zasobów.

Bo tak naprawdę w dzisiejszych czasach to istotny jest zasób, a nie przeciętny klient.

 

Wszystko oczywiście kwestia skali, w jakiej stosuje dane opcje usługodawca.

Stosowane z umiarem są akceptowalne - bo dzięki temu klient ma tańszą usługę, o w miarę wysokiej jakości.

Bez umiaru... ... Ale to przecież i połykając bez umiaru apap można sobie solidnych szkód narobić

[tym 205]

Zapoznaj się z dość starym terminem "ballooning xen"

Pewnie są jakieś jeszcze lepsze techniki na overcommiting w xen

 

Zapoznałem się i generalnie prosto jest wykryć gdy balloning jest stosowany - zużyta pamięć do odpalonych procesów... Także weryfikacja jest dość prosta i na dzień dobry można podziękować usługodawcy.

http://www.lowendbox.com/blog/how-to-tell-your-xen-vps-is-overselling-memory/

[d.v 1409]

Tak samo można łatwo wykryć zbyt duży overselling w OpenVZ. Na siłę próbujesz nas przekonać, że czarne jest zielone, mimo argumentów przeczących tej tezie. Ale niech Ci będzie, Ty wiesz swoje, my swoje.

[tym 205]

Tak samo można łatwo wykryć zbyt duży overselling w OpenVZ. Na siłę próbujesz nas przekonać, że czarne jest zielone, mimo argumentów przeczących tej tezie. Ale niech Ci będzie, Ty wiesz swoje, my swoje.

 

Może inaczej. Dla serwerów Xen, ballooning polega na 'zapożyczeniu' pamięci RAM od domU (VPS) dla dom0 (serwer główny) w przypadku gdy z jakiś przyczyn 'zabraknie' pamięci podczas np. dodawania nowego serwera czy większego obciążenia. Dom0 ma ustawiony RAM na sztywno w bootloaderze, by mieć jak najwięcej wolnego RAMu dla domU. Także oversell jest tu zupełnie innego rodzaju. Dla serwerów HVM w związku z tym że VPSy (kernel, wirtualizacja sprzętowa QEMU), są całkowicie niezależne, nie współpracują w żaden sposób z ballooningiem, więc nie ma możliwości oversellingu.

[dan 2]

Wracając nieco do ograniczeń wirtualizacji OpenVZ - aktualnie na XEN mam DirectAdmina z CSF do zabezpieczenia. Czy taka konfiguracja zabezpieczeń pójdzie na OpenVZ? Jeśli nie, to co stosować? Jakieś wskazówki, gdzie szukać informacji?

 

A tak w ogóle dziękuję wszystkim za informacje - jesteście bardzo pomocni :-)

Edytowano Październik 7, 2011 przez dan (zobacz historię edycji)

[malu 460]

Wracając nieco do ograniczeń wirtualizacji OpenVZ - aktualnie na XEN mam DirectAdmina z CSF do zabezpieczenia. Czy taka konfiguracja zabezpieczeń pójdzie na OpenVZ? Jeśli nie, to co stosować? Jakieś wskazówki, gdzie szukać informacji?

 

A tak w ogóle dziękuję wszystkim za informacje - jesteście bardzo pomocni :-)

 

Witaj,

 

DirectAdmin oczywiście pójdzie, nawet z quotą nie będzie problemu. (W większości przypadków).

Co do csf, pewnie, gdzie nie gdzie może brakować jakichś modułów w kernelu, ale raczej nikt nie będzie robił problemów, aby je dograć.

[Sebak 298]

Nie rozumiem czemu tak "podniecacie" się możliwościami oversellingu;).

 

W dzisiejszych czasach przy koszcie ramu na poziomie 4GB poniżej 100 zł i możliwości wrzucenia do zwykłego PC'ta 16-24GB ramu overselling ramu ma małe znaczenie. Bo dużo wcześniej zabraknie innych zasobów jak wydajności dyskowej czy mocy CPU...

 

Właśnie wydajność dyskowa obecnie jest parametrem który najbardziej niedomaga w rozwiązaniach typu VPS, a mimo to mało kto zwraca na to uwagę ...