Wybór dostawcy
Jedną z usług które dostarczam moim klientom są serwery wirtualne (VPS) na potrzeby różnych systemów (głównie opartych o protokół HTTP). VPS to jest wirtualna maszyna posiadająca własne IP i dostęp do root-a, ale współdzieląca sprzęt (CPU, pamięć, dysk) z innymi VPS-ami. Podział pozwala ograniczyć cenę usługi przy zachowaniu dość dobrego poziomu izolacji i bezpieczeństwa (lepszego niż przy współdzielonym hostingu).
Zwykle wynajmuję maszyny w USA ze względu na niską cenę za transfer. Jednak ze względu na potrzebę uzyskania niskich czasów dostępu zdecydowałem się na założenie konta u polskiego dostawcy VPS. Nie potrzebuję wyśrubowanych parametrów, więc wycelowałem w segment budżetowy (poniżej 40 PLN brutto za miesiąc).
hitme.net.pl/budgetvps.pl odpadło w przedbiegach ze względu na bardzo słaby poziom supportu. W webh.pl nie miałem wcześniej okazji wcześniej stawiać maszyn wirtualnych, ale znalazłem kilka negatywnych opinii na temat problemów z dostępnością maszyn.
Na początku vpsinn.pl odrzuciłem ze względu na niską gwarantowaną dostępność serwera (tylko 99%). Oznacza to możliwość niedziałania serwera 7 godzin w miesiącu. Uzyskałem jednak od nich linki do rzeczywistych statystyk dostępności serwerów w Polsce i w Niemczech i tam parametry nie wyglądają tak źle (około 99,7 %). Przynajmniej stawiają sprawę uczciwie i nie obiecują gruszek na wierzbie.
Domena jest względnie świeża, ale firma stojąca za tą marką operuje jeszcze w kilku serwisach:
$ whois vpsinn.pl | grep -i 'creat\|compa' created: 2009.02.19 10:59:40 company: Statnet Biuro Uslug Informatycznych Maciej Dolny $ whois statnet.pl | grep -i 'creat' created: 2001.04.20 13:00:00
Obie marki VPS oferują lokalizacje w Polsce (Łódź, IWACOM) lub w Niemczech (Hetzner). O ile o IWACOM nie mam wyrobionej opinii to o Hetzner słyszałem wiele pozytywnych opinii. Obie lokalizacje oferują atrakcyjne czasy dostępu z Polski (poniżej 30 ms). W stosunku do serwerów w stanach (ponad 120 ms) wynik jest bardzo dobry.
Plany
Tańsza marka vpsinn.pl operuje na serwerach w Polsce. Oferuje dwa tryby wirtualizacji: OpenVZ (współdzielony kernel, dostępna pamięć "burst") oraz Xen (własny kernel, dostępny swap). Generalnie Xen jest bardziej przewidywalny jeśli chodzi o pamięć, a tym zbliżony do serwera dedykowanego (ograniczana jest pamięć RSZ a nie VSZ). Każdy z planów ma opcję zarówno w OpenVZ jak i w Xen.
Podstawowa różnica jest taka, że opcja OpenVZ ma dwukrotnie więcej dostępnej przestrzeni dyskowej niż Xen. Dzieje się tak dlatego, że maszyny wirtualne OpenVZ współdzielą przestrzeń dyskową (w Xen zakłada się własny system plików), w związku z czym w OpenVZ łatwiejszy jest tzw. overselling.
Podobnie dzieje się z przydziałem pamięci RAM. Host OpenVZ może wejść w SWAP nie z twojej winy, w Xen masz jawnie przydzielany RAM + SWAP i fakt "swapowania" wynika bezpośrednio z aktywności uruchomionych procesów na wirtualce.
Zdecydowałem się na opcję "OpenVZ VPS S" (256 MB RAM, 20 GB przestrzeni na dysku, transfer 50 GB/mc). Wybrałem "Debian Lenny 5.0" jako system operacyjny.
Panel
Po masakrze spowodowanej (najprawdopodobniej) przez HyperVM w firmie a2b2 pozytywną cechą u dostawcy serwerów wirtualnych stało się udostępnienie własnego panelu zarządzającego. Firma którą jest stać na napisanie własnego softu zapewne ma więcej kompetencji technicznych niż ta która korzysta z gotowców takich jak HyperVM.
Statnet dysponuje własnym autorskim panelem.
Z jego poziomu można:
- Obejrzeć wystawione Faktury
- Uiścić opłatę za serwer (panel integruje się z dotpay.pl)
- Skontaktować się z supportem (system ticketów)
- Zatrzymać / uruchomić serwer
- Obejrzeć statystyki zużytego transferu
Miłym zaskoczeniem była zwiększona gwarantowana pamięć RAM (384 MB, w ofercie mieli 256 MB). Czyżby ktoś zapomniał dodać informacji o promocji na stronie WWW?
Wygląd i funckjonalność panelu nie budzi zastrzeżeń (układ menu jest czytelny) z kilkoma wyjątkami:
- Panel nie wspiera połączenia szyfrowanego HTTPS. Oznacza to, że hasło do logowania do panelu idzie jawnym tekstem po HTTP. Jeśli nie jesteś w zaufanej sieci powinieneś tunelować ruch do panelu po SSH do zaudanej maszyny
- Od aktywacji konta nie ma możliwości samodzielnej pełnej reinstalacji systemu operacyjnego (trzeba kontaktować się z supportem).
Panel do zarządzania kontem jest napisany w Javie (najprawdopodobniej oparto się na bibliotece Struts), pracuje pod Apache Tomcat/5.0.28 + Lighttpd. Nie jest to więc typowa "dłubanina" w PHP (Java wymaga większych kompetencji programistycznych).
Dostępny jest także panel ze statusem dostępności hostów i z informacjami o planowanych pracach. Bardzo przydatna rzecz kiedy występują problemy - można sprawdzić czy nie są one spowodowane planowanymi pracami (mniejsze obciążenie supportu). Panel napisany jest w Django :-) i działa pod mod_python + Apache, korzysta z MySQL-a jako systemu bazodanowego.
Serwer
Po opłaceniu konta dane serwer został założony w ciągu kilku minut, a na podany adres e-mail przyszły dane do logowania poprzez SSH. Pomimo, że hasło wydawało się dość mocne w pierwszym kroku zestawiłem połączenie po kluczu publicznym i zablokowałem logowanie po haśle.
Wylądowałem na maszynie openvz-02.statnet.pl. Znajdują się tu aktualnie około 20 VPS-ów (info wyciągnięte ze statystyk zużycia łącza).
Polecenie free wskazuje pamięć "burst", czyli potencjalnie dostępną, ale nie gwarantowaną przez kontener VPS.
# free -m
total used free shared buffers cached
Mem: 768 36 731 0 0 0
-/+ buffers/cache: 36 731
Swap: 0 0 0
Kontener OpenVZ może ubić największe procesy jeśli suma zużytej pamięci przekroczy pamięc gwarantowaną. Chwilowy (nie gwarantowany) "burst" może pomóc jeśli np. instalujemy oprogramowanie (aptitude może potrzebować nawet 80 MB pamięci wirtualnej).
Dostępna przestrzeń dyskowa jest zgodna ze specyfikacją:
# df -h Filesystem Size Used Avail Use% Mounted on simfs 20G 409M 20G 2% / tmpfs 3.9G 0 3.9G 0% /lib/init/rw tmpfs 3.9G 0 3.9G 0% /dev/shm
Co ciekawe wygląda na to, że cztery rdzenie procesora są dostępne:
# cat /proc/cpuinfo | grep 'cpu MHz' cpu MHz : 1995.001 cpu MHz : 1995.001 cpu MHz : 1995.001 cpu MHz : 1995.001
(w ofercie był wymieniony jeden rdzeń: "procesor: 2 GHz (fair scheduler)").
UPDATE 2010-01-13: Cztery rdzenie są widoczne, ale VPS jest wyraźnie ograniczany do około 25% mocy procesora (widać to pod obciążeniem). Czyli efektywnie jest dostępny jeden rdzeń 2Ghz.
Oto wynik parsowania informacji o dostępnych zasobach w VPS-ie OpenVZ uzyskanych z pliku /proc/user_beancounters przy pomocy specjalnego skryptu:
****** vmguarpages and oomguarpages limits are unspecified
****** each VE privvmpages limit should be <= 0.6 * RAM (=1228 MB), probably [much] lower.
816 MB Allocation Limit [privvmpages limit]
****** only high value processes have a chance in this range
****** having this safety range is important to permit critical processes
768 MB Allocation Barrier [privvmpages barrier]
****** allocation requests in this range have a chance
768 MB Allocation Guarantee [vmguarpages barrier]
****** allocation will succeed in this range
768 MB Memory Guarantee [oomguarpages barrier]
37 MB ( 128 MB Max) page memory allocated [privvmpages held]
16 MB ( 87 MB Max) memory + swap used [oomguarpages held]
16 MB ( 87 MB Max) page memory used [physpages held]
8796093022207 MB (9007199254740991 KB) kernel memory limit [kmemsize limit]
****** a safety range here, between limit and barrier, is important
8796093022207 MB (9007199254740991 KB) kernel memory barrier [kmemsize barrier]
3 MB ( 3169 KB) kernel memory used [kmemsize held]
0 MB ( 434 KB) buffer memory used [*buf held]
-----------------------------------------------
Used : Max_Used : Limit for Other Resources
4739 5019 9223372036854775807 numfile
5 13 9223372036854775807 numflock
10 10 9223372036854775807 numiptent
99 116 9223372036854775807 numothersock
24 42 1024 numproc
2 3 255 numpty
0 8 1024 numsiginfo
8 91 9223372036854775807 numtcpsock
-----------------------------------------------
Co ciekawe gwarantowany RAM okazał się większy od zadeklarowanego w ofercie (768 MB). Jak widać VPS nie jest poprawnie skonfigurowany :-( Nie da się każdemu z 20 VPS-ów na tej maszynie zagwarantować takiej samej dostępnej pamięci (host wejdzie w SWAP kiedy wszyscy zaalokują i użyją całą pamięć). To jest potencjalne zagrożenie stabilności serwera.
UPDATE (2010-01-04): administrator skorygował konfigurację maszyny, teraz jest już prawidłowa:
560 MB Allocation Limit [privvmpages limit] 512 MB Allocation Barrier [privvmpages barrier] 256 MB Allocation Guarantee [vmguarpages barrier] 256 MB Memory Guarantee [oomguarpages barrier] 37 MB ( 128 MB Max) page memory allocated [privvmpages held] 16 MB ( 87 MB Max) memory + swap used [oomguarpages held] 16 MB ( 87 MB Max) page memory used [physpages held]
Pomiar dostępności oparty o statyczną stronę HTTP opisuje jak serwer odpowiada zasobem statycznym (plik html). Widać dość dużą wariancję czasu odpowiedzi:
Co ciekawe pomiar z Niemiec pokazuje dużo lepsze czasy odpowiedzi serwera:
Czyżby jakaś dziwna trasa pakietów pomiędzy Krakowem a Łodzią? Sprawdźmy to:
Host Loss% Snt Last Avg Best Wrst StDev 1. ip-91-205-74-95.iwacom.net.pl 0.0% 37 0.0 0.0 0.0 0.0 0.0 2. bgp.teredo.pl 0.0% 37 0.6 0.6 0.4 2.9 0.4 3. z-atman-acx.iwacom.pl 21.6% 37 4.0 3.9 3.0 13.3 2.0 4. ??? 5. host9.kei.pl 0.0% 36 12.8 9.1 7.0 30.8 4.3
Jak widać problem stanowi router z-atman-acx.iwacom.pl - łącze to nie jest najlepszej jakości. Zobaczymy jak idzie ruch z Niemiec:
Host Loss% Snt Last Avg Best Wrst StDev 1. ip-91-205-74-95.iwacom.net.pl 0.0% 36 0.0 0.0 0.0 0.1 0.0 2. bgp.teredo.pl 0.0% 36 0.7 0.8 0.4 3.0 0.6 3. z-atman-iwacom2.pl 20.6% 35 4.6 3.3 2.9 6.8 0.8 4. tge-4-0-0-0a.cr1.fra.routeserver.net 0.0% 35 25.9 28.8 25.5 69.3 8.2 5. static-ip-85-25-225-138.inaddr.intergenia.de 0.0% 35 26.1 26.7 25.8 28.8 0.8 6. s28.linuxpl.com 0.0% 35 26.8 26.3 25.5 27.5 0.5
Do Niemiec mamy znacznie mniejszy rozrzut pomiarów.
Przeprowadziłem "test restartu": uruchomiłem polecenie "reboot" z wnętrza VPS-a i sprawdziłem czy system automatycznie wstanie. Zdarzało mi się często na źle skonfigurowanych hostach OpenVZ że polecenie takie było interpretowane jako "halt", czyli system automatycznie nie uruchamiał się po restarcie. W tym przypadku maszyna pojawiła się po chwili ponownie w sieci.
Podsumowanie
Plusy:
- bliska lokalizacja (PL/DE)
- sensowny cennik
- dostępne statystyki uptime
Minusy:
- brak połączenia HTTPS do panelu
- brak samodzielnej reinstalacji OS-a
- błędy (świadome?) w konfiguracji VPS-ów