Dariusz on Software

I believed dedicated server / VPS (Virtual Private Server) always requires dedicated IP adress. Until today.

I found (thanks, LowEndBox) interesting option where you can build your VPS totally custom parameters including shared IP address.How can it work? With shared IP? Youre joking! - you may ask. It works.

TOCICI offers "Nginx Accelerated Shared IP" wchich mean:

• Your VPS will be hidden behind NAT like typical workstation
• External Ngnix HTTP server will redirect HTTP traffic to your box based on URL domain
• You can define custom ports to be forwarded to your box (SSH incoming traffic)

Pros:

• Very cheap option (no cost of dedicated IP required, you can start VPS from 1-2 USD)
• Security (by default no ports visible to external world)

Cons:

• Standard ports except 80 (HTTP) unavailable: no DNS services
• No HTTPS available (requires separate IP)
• SSH login requires custom port (your local network may block high ports to prevent P2P)

The service fills gap between shared hosting and classic VPS. The only problem from my point of view is the distance between Europe and Portland, Oregon in the USA. 220 ms from Warsaw.

It's very important to know about server problems before they have impart on overall system performance and stability. Typical problem with server that may occur:

• missing disk space
• high server load (caused by CPU/IO)

In past I had problems with web applications failing to operate because lack of free disk space used for session storage. From this time I used to install monitoring on every resource that may be a problem for system.

The easiest way (Keep It Simple Stupid) to be monitored is to redirect email from root@localhost and install checks on root's crontab. Output written to stdout/stderr (if present) is send to crontab owner after script execution. Our srcipts will only generate output when problem is found. For example:

Notify high (>4) load on server:

*/5 * * * *  cat /proc/loadavg | awk '$2 > 4 { print "High 5-minute load", $2 }'

Notify when used disk space is above 90%:

00 21 * * *  df | awk '/^\// && $5 > 90 { print $0 }'

Many additional checks could be configured that way.

In addition I used to install munin. It produces graphs that shows various resources levels (day, week, month and year perspective). You can see in one place your overall system. It's sample graph showing month VPS instance load:

Do you have similar tools to monitor your server performance?

Pytanie nie jest wbrew pozorom takie głupie jak się może wydawać. Serwisy WWW działają w trybie 24/7, dzięki czemu my (jako odbiorcy usług) nie musimy dopasowywać się do narzuconego z góry harmonogramu dostępności usługi (jak np. w urzędach). Ograniczenia dostępności usług wynikają z ograniczeń podsystemów je realizujących. W przypadku urzędu  jest to człowiek, którego praca jest regulowana przez kodeks pracy i wewnętrzny regulamin. W przypadku usługi WWW ograniczeniem są niezbędne operacje administracyjne jak np. backup bazy danych.

Obserwując statystyki działania usług WWW można zaobserwować pewne schematy zachowania czasu odpowiedzi systemu które mogą wynikać z:

• aktualnej liczby użytkowników serwisu (która się zmienia w ciągu doby)
• chwilowego obciążenia maszyn realizującej usługę (skorelowane z liczbą użytkowników)
• czynników leżących poza serwerem jak np. obciążenie sieci
• regularnych automatycznych operacji administracyjnych (tzw. okno serwisowe)

Wykres pomiaru czasu odpowiedzi strony http://onet.pl za 8 dni wskazuje na ten ostatni czynnik:

Podpowiedź do pytania z tematu postu podkreśliłem na czerwono. Onet.pl wykonuje automatycznie jakiś proces który pomiędzy 5:00 a 5:15 odłącza mechanizm generujący stronę WWW. 15 minut to czas kiedy serwis może sobie raz na dobę "odpocząć". Kondycja godna pozazdroszczenia :-)

site-uptime.net jest usługą która pozwala ocenić jakość działania serwera na podstawie regularnych pomiarów czasu odpowiedzi HTTP. Problemy mogą być raportowane na wskazany adres e-mail lub SMS-em. Pozwala to na szybką reakcję w przypadku kiedy występuje problem i ocenę wydajności infrastruktury na podstawie danych historycznych.

Miło mi ogłosić, że site-uptime.net (usługa monitorowania serwisów WWW) obsługuje od dziś płatności przez DotPay, co pozwala korzystać z wielu kanałów płatności dostępnych w Polsce takich jak mTransfer czy MultiTransfer.

Obsługa PayPal oczywiście nadal będzie dostępna równolegle z DotPay.

OpenVZ is operating system-level virtualization technology that allows to run multiple virtual machines (with dedicated IP addresses) on one box (with shared filesystem). It's like a dedicated server but it's not the one. You have to overcome many limitations:

• Limits on VSZ memory size (virtual, allocated but no necessary used) memory (dedicated servers and Xen have limits on used memory: RSS)
• Fixed kernel with modules (no custom compilations here)
• Limits on inodes allocated etc.

One of important limitations is limit of size of unswapped memory allocated to kernel. In this area resides tcpsndbuf.It's summary size of buffers that are used to send data. If the value is low your download speed may be limited and sometimes you are getting error:

105 No buffer space available

You can check your limits by executing the following command:

# grep tcpsndbuf /proc/user_beancounters
tcpsndbuf  174336   1735168   1720320   2703360  2801251

Current buffer usage is 174336 bytes, limit is 1720320 bytes and limit was exceeded 2801251 times (ops!). Why send buffer is the problem here instead of receive buffer? Most of the time HTTP server is sending data - requests are much smaller than HTTP responses.

Solutions for this error:

• Limit concurrent connections server handles
• Check if unused connections are closed as soon as possible

I got this error ("550 Relaying denied. Please use SMTP Authentication") during e-mail sending. Other error that is visible: "553 sorry, that domain isn't in my list of allowed rcpthosts".

My configuration had the following entries in DNS records:

• SOA (Start of Authority)
• A (server's address)
• NS (nameservers that handle this domain)
• Additionaly reverse DNS was set properly
• Hostname used by server was the same as DNS name

Above records (in theory) should be sufficient to safely send an email. But it not worked for some recipients.

I have to add the following records to make sending e-mail pass:

• TXT "v=spf1 a -all" (Sender Policy Framework implementation)

Above TXT record defines IP from A record as the only allowed IP that can send emails from your DNS domain ("-all" flag is important when many conditions are defined, not the case here).

Agile methodologies prefer working code and direct communication over documentation. But in distributed teams it's impossible to rely only on direct conversations. Sometimes a bit of written specification is very helpful.

Informal specification

Primary documentation format for our projects is HTML (optionally connected with CmsWiki). Important benefits:

• simple
• known by web applications developers
• portable (scales well from full-featured web browsers to simple handhelds)
• many WYSIWYG editors available (including OpenOffice)

Alternate documentation format is RST (ReStructuredText). Important benefits:

• simple like ASCII documents (minimal markup)
• easy embedding of software code listings
• easy convertable to other formats
• mergable (two persons working on one file)

Sample of RST syntax:

Section title
=============

This is paragraph with some text *bolded out*. It's a link: http://aplikacja.info

 - A list
 - Another list item

Accepted variation of RST is use of Wiki. Benefits of this option:

• document can be developed and inspected on-line (possibly in real-time with customer)
• it's very easy to add changes (no need to update/checkin cycle to version control system)

Another very useful documentation format is spreadsheet. It's very easy to create (I recomment Google Docs for this task) and could be exported to CSV format in order to be parsed (testing/code generation purposes).

Formal specifications

For documenting existing software interfaces it's best to use automatically generated from source docs (Java Doc for Java, PyDoc for Python). They are always up-to-date because are regenerated automatically. JavaDoc example:

/**
 * Function description
 * @author DCI
 * @see AnotherClass.anotherMethod()
 **/
void loadTransactions(String filePath);

At more formalized level one can specify system using models (UML/OCL for instance). Those models can describe formally requirements and could be checked internally for consistency. I prefer open source tool called USE (A UML-based Specification Environment).

Writing system that will meet user requirements is as important as writing system correctly (with minimal bug rate). Transferring specification from users to development team is very important part of any project. Proper tools used for documentation may help here.

Sometimes your server responds very slowly. If you are sure it's not a networking problem (no packet loss on traceroute) you have to check other resources that may influence performance: CPU and IO.

CPU is pretty easy to check: simply run top and sort list by CPU usage (P key):

IO bottlenecks are harder to find. You can install tool names iotop (apt-get install iotop) and see which processes consume your IO. In my case (old stable kernel) I got the following error on iotop run:

# iotop
Could not run iotop as some of the requirements are not met:
- Python >= 2.5 for AF_NETLINK support: Found
- Linux >= 2.6.20 with I/O accounting support: Not found
# uname -r
2.6.18.8-linode19

Ops. There's alternative and more portable way to see which processes may be our suspects. It's D state:

# man ps
(...)
D    Uninterruptible sleep (usually IO)

Simply watch output of this command:

watch -n 1 "(ps aux | awk '\$8 ~ /D|R/  { print \$0 }')"

and your suspects (processes in D state) will be visible. Also you will see current process in R state (running, use CPU).

Happy hunting!

site-uptime.net, network monitoring service was extended today by HTTP method selection option. You can choose to use HEAD (smaller network overhead) or GET (maximum 10 kB is downloaded in one measurement). Get option allow to download and analyse HTML content for specific keywords (required, like static text on webpage or undesirable, like IFRAME viruses).

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