my personal page

Jakiś czas temu rozie na swoim blogu zwrócił uwagę na wydajność szyfrowania AESem w zależności od procesora, na którym taką operację przeprowadzamy. Z krótkiego wpisu rozwinęła się całkiem ciekawa dyskusja o akceleracji szyfrowania i implementacji tego mechanizmu dla konkretnych rozwiązań. Okazuje się, że temat jest zdecydowanie nietrywialny i że na wydajność szyfrowania, niezależnie od tego, czy szyfrujemy zawartość dysku, czy przesyłane przez sieć dane, wpływa wiele ciekawych czynników.

Na początku tego roku robiłem testy wydajnościowe na potrzeby szyfrowania dysków za pomocą LUKSa. Wyniki (jak znajdę czas, to je tutaj kiedyś wrzucę) pokazały, że bardzo duży przyrost wydajności możemy osiągnąć wykorzystując rozszerzenie procesora o nazwie AES-NI. Samo załadowanie modułu aesni_intel (bo taka platforma mnie wtedy interesowała) powodowało wydajnościowego kopa na poziomie 250% (cryptsetup dla algorytmu aes-128-cbc pokazał wzrost z 219MB/s do 620MB/s).

Dzisiaj chciałbym się skupić na tym samym zagadnieniu, ale w kontekście szyfrowania danych przesyłanych przez tunel OpenVPNa. Ponieważ takich testów raczej nie należy przeprowadzać na produkcji, skleciłem na kolanie „laba”, składającego się z mojego domowego pseudo-serwera (Intel Pentium G2130, 2 rdzenie, 3.2GHz, bez AES-NI) jako koncentratora i kilku klientów:

Najpierw warto by było przedstawić benchmark samych maszynek. Żeby być jako tako spójnym z wpisem roziego, test przeprowadziłem za pomocą polecenia 'openssl speed’ (ale bez opcji –multi). Odpowiednie cyferki możemy obejrzeć w poniższej tabelce:

Dodatkowo udało mi się zmierzyć wydajność OpenSSLa na innych procesorach. Niestety testy przeprowadzałem w warunkach jeszcze bardziej polowych i nie miałem możliwości przetestowania tunelu OpenVPNa. Wyniki poniżej:

W przypadku Atoma i ARMa z Raspberry Pi nie ma sensu przedstawiać wyników z wykorzystaniem EVP, bo te procesory niewiele umieją i wyniki są niemal identyczne (lub nawet słabsze).

Warto by było przedstawić jeszcze sposób przeprowadzania testów.
Konfiguracja serwera: (cipher i comp-lzo ustawiane zgodnie z odpowiednim testem)

local 10.0.0.2
proto udp
port 1194
dev tap0
ca /etc/openvpn/certs/ca.pem
cert /etc/openvpn/certs/server.crt
key /etc/openvpn/certs/server.key
dh /etc/openvpn/certs/dh1024.pem
server-bridge 10.0.99.1 255.255.255.0 10.0.99.2 10.0.99.20
keepalive 10 120
max-clients 10
persist-key
persist-tun
verb 3
cipher XXX               
comp-lzo

Konfiguracja klienta:

client
dev tap
proto udp
remote 10.0.99.1
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
verb 3
comp-lzo
cipher XXX

Wyniki pochodzą z iperfa (komendy odpowiednio dla serwera i klienta):

iperf -s
iperf -c adres_IP -t 600; uptime

Najwyższy czas na bohatera niniejszego wpisu, czyli tabelkę z wynikami:

Na koniec kilka ciekawostek.

• Laptop z Core i3 na pokładzie spędzał dużo więcej czasu na obsłudze karty sieciowej (Realtek 8169 – funkcje kernela rtl8169_poll oraz rtl8169_interrupt), niż na szyfrowaniu danych.

• Zgodnie z informacjami, które znalazłem na stronie OpenVPNa, problemy z osiągnięciem wysokich wartość na linkach gigabitowych nie wynika z braku zasobów do szyfrowania danych, a ze sposobu, w jaki pakiety z danymi podróżują przez system.

• Spotkałem się też z informacją, że aby włączyć EVP w OpenVPNie, trzeba dodać do konfiguracji komendę engine aes-ni.

Bardzo lubię routery Mikrotika (a dokładniej RouterOS zainstalowany na platformie RouterBoard). Konstrukcje te mają całkiem fajny stosunek możliwości do ceny i w miarę poukładany (jak dla mnie) interfejs. Za ich pomocą można stworzyć naprawdę rozbudowane konfiguracje (szczególnie na większych pudełkach typu CCR), zawierające kilka niekoniecznie zależnych od siebie mechanizmów. I tutaj pojawia się tytułowe zagadnienie: mając router z dopracowaną w najdrobniejszych szczegółach konfiguracją, dobrze byłoby zgrać ją gdzieś na bok, uodparniając nasze środowisko na awarię sprzętu. Co więcej, dobrze by było, gdyby kopia bezpieczeństwa wykonywała się okresowo sama, uwalniając nas od konieczności pamiętania o takim szczególe. Jest to szczególnie ważne wszędzie tam, gdzie konfiguracja dynamicznie się zmienia (choćby ze względu na wpisy w firewallu lub definicje adresów MAC w serwerze DHCP).

Okazuje się, że mając do dyspozycji komputer działający pod kontrolą Linuksa, możemy taki mechanizm w prosty sposób uruchomić. Co więcej, nie będzie nam potrzebne nic, poza klientem SSH i SCP.

Załóżmy, że nasz router znajduje się pod adresem 10.0.0.1 i mamy na nim poprawnie skonfigurowaną usługę SSH. Pierwszym krokiem jest wygenerowanie pary kluczy na komputerze, na który będziemy pobierać konfigurację routera:

[kbechler@waterfall ~]$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/kbechler/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/kbechler/.ssh/id_dsa.
Your public key has been saved in /home/kbechler/.ssh/id_dsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx kbechler@waterfall
The key's randomart image is:
+--[ DSA 1024]----+
[....]
+-----------------+
[kbechler@waterfall ~]$

Wynikiem tego polecenia będą dwa pliki, zawierające nasz klucz prywatny (~/.ssh/id_dsa) oraz publiczny (~/.ssh/id_dsa.pub). Pamiętajmy, że klucz prywatny jest tajny i pod żadnym pozorem nie powinniśmy go udostępniać osobom trzecim!

Drugim krokiem jest skopiowanie klucza publicznego do routera. Najprościej jest to uczynić przez SSH, np. za pomocą takiego polecenia:

[kbechler@waterfall ~]$ scp ~/.ssh/id_dsa.pub kbechler@10.0.0.1:/
id_dsa.pub                                                                          100%  618     0.6KB/s   00:00
[kbechler@waterfall ~]$

Tak, wrzucam plik do głównego katalogu routera. Nie przeszkadza mi to specjalnie i nie wydaje się błędem.

Krok trzeci, to przypisanie klucza publicznego do odpowiedniego użytkownika na routerze. Za pomocą konsoli routera robi się to tak: user ssh-keys import public-key-file=id_dsa.pub user=kbechler

W tym momencie powinniśmy mieć możliwość zalogowania się na router bez podawania hasła (za pomocą kluczy SSH). Sprawdźmy, czy to na pewno działa:

[kbechler@waterfall ~]$ ssh kbechler@10.0.0.1 "/system health print"
      voltage: 23.8V
  temperature: 34C

[kbechler@waterfall ~]$

Jeżeli zadziałało, to ostatnim krokiem jest napisanie prostego skryptu, który będzie wykonywał na routerze kopię konfiguracji i pobierał ją na lokalny komputer. Można to zrobić na przykład tak (wersja dla kilku urządzeń, która zapisuje kopie zapasową w postaci pliku binarnego, jak i skrypt z poszczególnymi poleceniami konfigruacyjnymi):

#!/bin/bash

DEST="/data/backup"
TODAY=`date +%Y%m%d`

for r in 10.0.0.1 192.168.0.1; do
  echo "*** Zapisuje konfiguracje routera ${r}..."
  ssh -l kbechler ${r} "export compact file=backup; system backup save name=backup"
  echo "*** Kopiuje konfiguracje z routera ${r}..."
  scp kbechler@${r}:/backup.backup ${DEST}/mikrotik/${r}.${TODAY}.backup
  scp kbechler@${r}:/backup.rsc    ${DEST}/mikrotik/${r}.${TODAY}.rsc
done

UWAGA! W pobranych plikach znajdują się dane wrażliwe. Nie należy przechowywać ich w niezabezpieczonym miejscu. Co więcej, jeżeli do routera mają dostęp także inne osoby, to po pobraniu plików należy je usunąć z pamięci flash routera.

Zestaw nagłówków, które przeglądarka użytkownika dostaje od serwera WWW jest bardzo cennym źródłem informacji dla administratora takiego serwera. Bez takiej wiedzy trudno byłoby weryfikować, czy zmiany, jakie wprowadziliśmy w konfiguracji naszego systemu faktycznie mają wpływ na jego działanie.

Przykładem niech będzie NGINX i jego domyślna konfiguracja, która nie pozwala na zapisywanie serwowanych przez niego obrazków w pamięci podręcznej przeglądarki. Skąd to wiem? Po pierwsze z dokumentacji samego serwera, a po drugie właśnie z nagłówków, jakie mój NGINX serwuje użytkownikom:

[kbechler@s16931669 ~]$ curl -I cs4/tux.png
HTTP/1.1 200 OK
Server: nginx/1.0.15
Date: Fri, 04 Apr 2014 18:41:43 GMT
Content-Type: image/png
Content-Length: 11913
Last-Modified: Sun, 06 Oct 2013 18:26:00 GMT
Connection: keep-alive
Accept-Ranges: bytes

To właśnie curl jest bohaterem dzisiejszego wpisu. Za pomocą tego bardzo użytecznego narzędzia możemy nie tylko dokładnie obejrzeć odpowiedź serwera, ale również wygenerować niemalże dowolne zapytanie typu GET lub POST, bezproblemowo obsłużyć połączenia HTTPS (co bywa niekiedy bardzo użyteczne) albo własnoręcznie zbudować zapytanie składające się z dowolnego zestawu nagłówków.

Wracając do naszego przykładu, po dodaniu do konfiguracji NGINXa takiego oto wpisu:

location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
}

Nasz NGINX powinien zachować się odrobinę inaczej i przesłać przeglądarce dodatkowy nagłówek. Popatrzmy, czy na pewno tak jest:

[kbechler@s16931669 ~]$ curl -I cs4/tux.png
HTTP/1.1 200 OK
Server: nginx/1.0.15
Date: Fri, 04 Apr 2014 19:14:21 GMT
Content-Type: image/png
Content-Length: 11913
Last-Modified: Sun, 06 Oct 2013 18:26:00 GMT
Connection: keep-alive
Expires: Sun, 04 May 2014 19:14:21 GMT
Cache-Control: max-age=2592000
Accept-Ranges: bytes

ta-dam. Nie dość, że nauczyliśmy się podglądać nagłówki HTTP, to jeszcze przy okazji odkryliśmy, jak sterować pamięcią podręczną przeglądarki dla serwowanych przez nas obrazków.

Załóżmy, że używam w domu Linuksa. Do różnych celów. Jednym z nich jest pisanie podręczników dla mojego Klienta. Wprawdzie nie są to wiekopomne dzieła i nawet w drobnym procencie nie dorównują dokumentacji, jaką dawno temu stworzył Novell dla swojego systemu Netware, jednakże jestem z nimi związany (zarówno emocjonalnie, jak i finansowo) i bardzo bym nie chciał ich stracić. Mój domowy komputer ma tylko jeden dysk twardy, a ja – jako doświadczony użytkownik – wiem, że dyski takie ulegają awariom, w wyniku których dane potrafią wyparować szybciej, niż setka wódki. Na szczęście mam dostęp do super-bezpiecznego serwera, który sam w sobie posiada macierz dyskową zabezpieczającą przed utratą danych wskutek awarii jednego dysku. Dodatkowo dane z tego super-serwera są regularnie kopiowane na tasiemki w ramach wykonywania okresowych kopii bezpieczeństwa. Niestety, nie jestem jedynym użytkownikiem tego systemu (ba, nie mam nawet uprawnień administratora), a mój Klient byłby bardzo niezadowolony, gdyby ktoś przeczytał moją twórczość bez jego wiedzy. Ponieważ bardzo chcę mieć kopie zapasowe i bardzo nie chcę, aby ktoś miał dostęp do moich danych, postanowiłem je przed wysłaniem zaszyfrować.

Nie chcę używać żadnych haseł, bo łatwo je zapomnieć, a zapisane tracą pewną część swojej tajemniczości. Postanowiłem użyć kryptografii asymetrycznej, a dokładniej swojej pary kluczy SSH. Klucz prywatny i tak staram się chronić na wszystkie możliwe sposoby, więc dlaczego nie miałbym go wykorzystać także do szyfrowania moich kopii bezpieczeństwa?

Założenie jest takie, że chcę wykonać kopię zapasową katalogu ~/dane w taki sposób, aby możliwe było jej odczytanie jedynie przy użyciu prywatnej części mojego klucza SSH. Niestety, klucz SSH, którego używam (a także większość, jeżeli nie wszystkie klucze asymetryczne) nadaje się do zaszyfrowania wiadomości krótszej, niż on sam, czyli 2048 bitów (a nawet jeszcze mniej, co wynika z budowy samego klucza). Przy okazji, długość klucza sprawdza się w taki oto sposób (pierwsza liczba odpowiada właśnie długości klucza w bitach):

[kbechler@s16931669 ~]$ ssh-keygen -l -f ~/.ssh/id_rsa.pub
2048 09:d7:31:b7:12:3b:d3:3d:ce:ff:02:c7:19:82:54:c2 /home/kbechler/.ssh/id_rsa.pub (RSA)

Sytuacja nie jest jednak taka zła. Możemy przecież za pomocą SSH zaszyfrować sobie jakieś zamotane hasło, które następnie posłuży to zaszyfrowania naszych (a dokładniej moich ;-) danych).

Do dzieła. Pierwsze, co musimy zrobić, to przerobić format klucza tak, żeby był zrozumiały przez polecenie openssl. Robi się to w taki oto sposób:

[kbechler@s16931669 ~]$ openssl rsa -in ~/.ssh/id_rsa -outform pem > backup.key.pem
writing RSA key
[kbechler@s16931669 ~]$ openssl rsa -in ~/.ssh/id_rsa -outform pem -pubout > backup.pub.pem
writing RSA key

W wyniku działania tych dwóch radosnych komend otrzymaliśmy dwa pliki, zawierające – odpowiednio – prywatną oraz publiczną część naszego klucza w formacie PEM. Z kronikarskiego obowiązku napiszę jeszcze, że dane szyfrujemy za pomocą części publicznej, a odszyfrowujemy za pomocą prywatnej.

Do zaszyfrowania i wysłania moich cennych danych używam takiego oto, niezbyt rozbudowanego, skryptu:

#!/bin/bash

# aktualna data przyda sie do utworzenia nazwy pliku na serwerze docelowym
data=`date +%Y-%m-%d_%H:%M:%S`

# stworz archiwum zawierajace nasze cenne dane (oczywiscie w formie skompresowanej)
tar -czf ./backup.tgz ./dane

# wygeneruj klucz sesji i za jego pomoca zaszyfruj (szyfrowanie symetryczne) dane
openssl rand 64 |
  tee >(openssl enc -aes-256-cbc -pass stdin -in ./backup.tgz -out ./backup.enc) |
  openssl rsautl -encrypt -pubin -inkey ./backup.pub.pem -out ./backup.key

# na wszelki wypadek wygeneruj sumy kontrolne plikow
md5sum ./backup.enc ./backup.key > ./backup.md5

# wrzuc wszystko do jednego pliku .tar (tym razem juz bez kompresji) i wyslij na serwer docelowy
tar -c ./backup.enc ./backup.key ./backup.md5 | ssh flame "cat > ~/backup-${data}.tar"

# trzeba jeszcze po sobie posprzatac
rm ./backup.{tgz,enc,key,md5,tar}

Skoro tak dobrze nam idzie i udało się wysłać dane do innego serwera, to warto by jeszcze było poznać metodę, za pomocą której możemy te dane przywrócić. Ponieważ jestem leniwy i mam kiepską pamięć, do tego zadania również napisałem sobie krótki skrypt:

#!/bin/bash

# jezeli wszystko sie uda, to tutaj znajda sie dane odzyskane z kopii zapasowej
KATALOG_DOCELOWY="/home/kbechler/dane_z_backupu"

# wylistujmy nazwy plikow przechowywanych na serwerze
echo "Lista plikow dostepnych na serwerze:"
ssh flame 'ls backup*.tar'
echo

# popros uzytkonika o nazwe pliku, ktora chce odtworzyc
echo "Podaj nazwe pliku do odtworzenia:"
read plik
echo

# pobierz plik z serwera
echo "Pobieram plik..."
ssh flame "cat ${plik}" > ./${plik}
if [ $? -ne 0 ]; then
  echo "BLAD!"
  exit 1
fi

echo "Wypakowuje zawartosc archiwum..."
tar -xf ./${plik}
if [ $? -ne 0 ]; then
  echo "BLAD!"
  exit 1
fi

echo "Sprawdzam sumy kontrolne..."
md5sum -c ./backup.md5 >/dev/null 2>&1
if [ $? -ne 0 ]; then
  echo "BLAD!"
  exit 1
fi

echo "Odszyfrowuje dane..."
openssl rsautl -decrypt -inkey ./backup.key.pem -in ./backup.key |
openssl enc -aes-256-cbc -pass stdin -d -in ./backup.enc -out ./backup.tgz

if [ ! -d ${KATALOG_DOCELOWY} ]; then
  echo "Tworze katalog ${KATALOG_DOCELOWY}..."
  mkdir -p ${KATALOG_DOCELOWY}
fi

echo "Wypakowuje dane..."
tar xzf ./backup.tgz -C ${KATALOG_DOCELOWY}

# sprzatamy po sobie
rm ./${plik}
rm ./backup.{md5,enc,key,tgz}

Pod mrożącym krew w żyłach określeniem, które widnieje w tytule niniejszego wpisu kryje się całkiem prosty mechanizm. Często pojawia się on w opcjach konfiguracyjnych przeróżnego sprzętu sieciowego i niejednokrotnie traktowany jest na zasadzie „jeżeli działa, nie dotykaj”. Tak naprawdę nie ma w takim podejściu do sprawy nic złego, ale czasami warto wiedzieć, co można osiągnąć, świadomie zmieniając tego typu opcje. Mechanizm ten nie jest niczym więcej, jak elementem umożliwiającym zestawienie tunelu VPN przechodzącego przez translację adresów (czyli popularny NAT). W zależności od konkretnych protokołów, które wykorzystywane są przez nasz tunel VPN, mechanizm ma mniej lub więcej zadań do wykonania. Popatrzmy na trzy konfiguracje:

• Najprościej jest w przypadku bardzo popularnego ostatnio OpenVPNa. Wykorzystuje on tylko pojedynczy port TCP lub UDP, wobec czego nie potrzebuje żadnego wsparcia ze strony routerów ani ścian ogniowych, przez które ruch jest przesyłany. Co więcej, port ten może być niemal dowolnie zmieniany, a jedyne ograniczenia narzucane są przez konkretne implementacje protokołu (przykładowo routery Mikrotik obsługują konfiguracje OpenVPNa jedynie za pośrednictwem portów TCP).

• Z zupełnie inną sytuacją mamy do czynienia w przypadku tuneli wykorzystujących protokół GRE (np. PPTP). Ponieważ GRE jest jednym z protokołów IP (podobnie jak TCP lub UDP) i w dodatku nie wykorzystuje pojęcia „portu”, mechanizmy translacji adresów nie są w stanie poprawnie obsłużyć takiego połączenia, ponieważ nie mają sposobu, aby odróżnić pakiety przynależące do różnych sesji. Jak więc routery radzą sobie z takim problemem i co kryje się pod hasłem „passthrough”? Okazuje się, że istnieje coś takiego, jak rozszerzony nagłówek GRE, który zawiera pole „Call ID”. I właśnie to pole wykorzystywane jest w roli wyznacznika konkretnego połączenia (zupełnie jak porty w przypadku TCP lub UDP). Zawartość wspomnianego pola wybierana jest przez klienta VPN dość losowo, a samo połączenie zapamiętywane jest przez NATownicę jako para „Call ID” + adres IP systemu docelowego.

• Trzecim scenariuszem, który warto opisać jest konfiguracja tunelu z udziałem protokołu IPSEC (np. tandem L2TP/IPSEC). IPSEC, podobnie jak ma to miejsce w przypadku PPTP, także używa protokołów IP innych, niż TCP i UDP. Są to m.in AH (protokół numer 0x33) oraz ESP (0x32). Ponieważ nie istnieje „rozszerzony nagłówek ESP”, trzeba było opracować inną metodę na połączenie IPSECa i NATa. Rozwiązaniem okazał się mechanizm nazwany „NAT Traversal”, który działa dwuetapowo. Jeszcze przed zaszyfrowaniem danych mechanizm określa, czy oba urządzenia zestawiające tunel obsługują NAT-T. Jeżeli odpowiedź jest pozytywna, to wyszukiwane są routery „robiące NAT” pomiędzy naszymi urządzeniami (proces nazwany został „NAT Discovery”). Jeżeli także i tutaj uzyskamy pozytywną odpowiedź, to… cały ruch pomiędzy końcami tunelu opakowywany jest w datagramy UDP, unikając w ten sposób konieczności przesyłania czegokolwiek innego, niż ruch na portach udp/500 (IKE) oraz udp/4500 (NAT-T). Cały mechanizm bardzo ładnie opisany został TUTAJ.

Odwiedził mnie ostatnio stary znajomy. Ma na imię OOM killer i jest wyjątkowo uciążliwym typem. Jakiś czas temu zostaliśmy sobie przedstawieni przez kolegę Kernela i od tego momentu nie mogę się od tej nieciekawej znajomości uwolnić. Wspomniany gość nawiedza mnie w bardzo losowych i nieoczekiwanych momentach, wypowiada kilka zdań (które najczęściej są skrupulatnie logowane przez nadwornego skrybę – sysloga), a następnie sieje zniszczenie wśród znajdujących się w pobliżu procesów. Pół biedy, jeżeli za cel obierze jakieś testowe miejsce, do którego nikt poza mną nie zagląda i które nie jest źródłem dochodów dla moich Klientów. Wtedy bawimy się w kotka i myszkę (czasami nawet dość długo), aż w końcu któremuś z nas ta zabawa się nudzi i rozstajemy się w stanie zawieszenia broni. Ale czasami zdarza się tak, że kiler zaczyna majstrować przy produkcyjnych systemach. Oj, tego to ja bardzo nie lubię (głównie chyba dlatego, że lubię ciszę i spokój, a nerwowe maile i telefony związane z niedziałaniem systemu ten spokój skutecznie zaburzają) i w takich sytuacjach podejmuję aktywną walkę ze złem. A jak wiadomo, żeby pokonać wroga, trzeba go najpierw poznać…

Jądro Linuksa domyślnie skonfigurowane jest tak, aby być bardzo optymistycznie nastawionym do świata. Jeżeli jakiś proces chce zarezerwować dla siebie trochę pamięci, to bardzo często ją dostanie. Nawet wtedy, gdy system fizycznie aż takich możliwości nie ma. Dzieje się tak dzięki założeniu, że procesy alokują więcej pamięci, niż faktycznie wykorzystują, co z kolei prowadzi do marnowania cennych bajtów. A przecież wszyscy wiedzą, że bajtów marnować nie należy. Niestety, w pewnym momencie może nastąpić sytuacja, w której wspomniane procesy zaczynają używać całej przydzielonej im pamięci (dlaczego nie? przecież jądro im na to pozwoliło), a system nie ma gdzie tego wszystkiego pomieścić. I tu powstaje bardzo duży problem, któremu Linux stara się zaradzić wywołując proces OOM killera. Ten ostatni w sposób losowy(*) wybiera jakiś inny proces i go ubija, mając jednocześnie nadzieję, że taka operacja zwolni na tyle dużo pamięci, aby system mógł kontynuować pracę. Jednak nie zawsze się to udaje, a nawet jak się uda, to okazuje się, że trafiło na serwer SSH, a maszyna stoi kilkaset kilometrów od naszego aktualnego miejsca pobytu. Niezależnie od wyboru OOM killera, jego obecność zawsze jest niepokojąca i należy zrobić wszystko, aby jej zapobiec w przyszłości.

Szczęśliwie dla nas, nastąpił w historii rozwoju jądra moment, w którym kilku programistom się trochę nudziło i zaczęli kombinować, co można by było w zarządzaniu pamięcią zmienić. Wpadli oni na bardzo słuszny pomysł, że nie wszystkie systemy dobrze radzą sobie z wyrafinowanymi algorytmami przewidującymi rzeczywiste zużycie pamięci. Konsekwencją tego pomysłu było umożliwienie administratorowi zmiany domyślnego zachowania Linuksa za pomocą parametrów jądra. Wprawdzie do dyspozycji mamy tylko dwa takie parametry, jednak do większości zastosowań powinno to wystarczyć. Oto nasi bohaterowie:

• vm.overcommit_memory – parametr przyjmujący wartości 0, 1 lub 2. Wartość zerowa jest wartością domyślną i oznacza, że system będzie próbował oszacować ilość wolnej pamięci i na tej podstawie przydzielać ją procesom, które o to proszą. Jeżeli zmienimy ten parametr na jeden, to system będzie udawał, że ma nieskończoną ilość pamięci i rozdawał ją na lewo i prawo… aż wszystko padnie :-) Ostatnią możliwością jest wartość 2, określana jako „never overcommit”, która jest bezpośrednio związana z drugim parametrem:

• vm.overcommit_ratio – jeżeli poprzedni parametr ustawiliśmy na „2”, to tutaj definiujemy jak dużo pamięci system może przydzielić procesom. Jeżeli np. ustawimy tutaj wartość „80”, to procesy dostaną pamięć o rozmiarze partycji swap + 80% fizycznej pamięci RAM zainstalowanej w maszynie. Aha, można tu ustawić wielkości większe od 100, dzięki czemu system będzie w stanie zrobić overcommit, ale na naszych zasadach.

Najczęściej polecanymi ustawieniami tych parametrów, które mają nas zabezpieczyć przez szaleńczymi działaniami OOM killera są takie:

[root@ns ~]# sysctl -a | grep overcommit
vm.overcommit_memory = 2
vm.overcommit_ratio = 80
[root@ns ~]#

I faktycznie – jeżeli w systemie zaczyna buszować OOM killer i nie jest to sytuacja jednorazowa, takie zabezpieczenie wydaje się być niezłym rozwiązaniem. Należy jednak pamiętać, że nasze aplikacje nie są zbyt przewidywalne dla jądra systemu, co może być pierwszą oznaką tego, że zostały źle napisane i będzie z nimi więcej problemów. Na szczęście nie zawsze tak jest :-)

(*) – Tak naprawdę nie jest to zdarzenie losowe, a OOM killer ma dość zagmatwane algorytmy, za pomocą których wybiera swoją ofiarę. Jednak nie są one idealne, wobec czego wybór często okazuje się bardzo problematyczny.

I jeszcze jedno. Ponieważ każdy poważny artykuł albo wpis na blogu powinien mieć mnóstwo odnośników do źródeł wiedzy, a ja jakoś w treści mało linkowałem, to tutaj kilka ciekawych pozycji związanych z tematem:

• Zestawienie parametrów jądra Linuksa dla pamięci wirtualnej
• Opis mechanizmów zarządzania pamięcią w Linuksie
• Fajny artykuł z testami i ciekawymi komentarzami

Każdy, kto ma pod opieką jakiś serwer lub urządzenie sieciowe lubi wiedzieć, co się z owym sprzętem dzieje. Owszem, można codziennie logować się na każdą maszynę, odczytywać jej parametry życiowe i skrzętnie zapisywać w notesie. Ale chyba nie jest to zbyt dobre rozwiązanie i nawet najbardziej wytrwały administrator po pewnym, zapewne niezbyt długim czasie, da sobie z taką metodą spokój. A brak kontroli nad sprzętem prowadzi w prostej linii do katastrofy. No dobra, mam nadzieję, że do potrzeby monitorowania zasobów nikogo specjalnie przekonywać nie muszę. Ale natychmiast pojawia się seria pytań: co?, jak?, gdzie?, czym? jak często?…

Na początek warto określić, które urządzenia chcemy otoczyć kontrolą. Z dużym prawdopodobieństwem będą to wszystkie serwery (w szczególności te produkcyjne, czyli zarabiające kasę). Równie ważnymi elementami są macierze dyskowe, bez których serwerom raczej trudno byłoby wypełniać ich zadania. W drugim rzędzie routery i inteligentny sprzęt sieciowy (np. zarządzalne przełączniki zainstalowane w centralnych miejscach sieci). Kolejnym elementem, na który czasami warto zwrócić uwagę są urządzenia drukujące (użytkownicy na pewno się ucieszą, jak z wyprzedzeniem zamówimy toner do drukarki i nie będą musieli biegać na inne piętro, żeby wydrukować ważny list dla Klienta). Na samym końcu są stacje robocze użytkowników i wszelki drobny sprzęt, który włączyliśmy do naszej sieci. Nie zawsze (a właściwie to całkiem rzadko) będziemy potrzebowali monitorować wszystko. Czasami okaże się, że w zupełności wystarcza nam wiedza o stanie dwóch serwerów i jednego routera pomimo posiadania całej szafy wypchanej sprzętem.

Jeżeli wykonaliśmy już listę urządzeń, które będziemy monitorować to możemy chwilę odpocząć przed następnym zadaniem, bo będzie ono niezwykle ważne i męczące. Drugim bowiem krokiem do sprawnego systemu monitoringu jest odpowiedzenie sobie na pytanie: co tak naprawdę chcemy monitorować? I – wbrew pozorom – odpowiedź typu „wszystko, co się da” nie jest najlepsza. Zagadnienie monitoringu możemy podzielić na dwa elementy.

• Pierwszym jest okresowe zbieranie informacji i na ich podstawie rysowanie wykresów, dzięki którym będziemy mogli określić długoterminowe trendy oraz z wyprzedzeniem zapobiegać np. wykorzystaniu całej przestrzeni na dyskach macierzy. Dane takie przydają się także przy profilowaniu połączeń sieciowych. Jeżeli wykresów takich będzie bardzo dużo, to będziemy musieli poświęcić sporo czasu, żeby się przez nie wszystkie przekopać. Oczywiście można je poukładać w jakąś przemyślaną hierarchię, ale nie spowoduje to, że wykres obrazujący ilość danych przesyłanych przez interfejs sieciowy drukarki prezesa stanie się w jakikolwiek sposób pożyteczny.

• Drugim zadaniem systemu monitorowania zasobów jest odpytywanie urządzeń o ich stan i – na bieżąco – zgłaszanie wszelkich nieprawidłowości administratorowi. I tutaj możemy wpaść w pułapkę – złotą zasadą jest utrzymywanie prawidłowych wartości wszystkich monitorowanych parametrów (tzw. stan „all green”). Zbyt duża ilość monitorowanych elementów powoduje, że „alarmy” (które mogą być spowodowane np. wyłączeniem przez użytkownika drukarki) staną się codziennością i po pewnym czasie administrator przyzwyczai się do nich na tyle, że nie będzie w stanie z właściwą uwagą zareagować na rzeczywiste problemy. Sam problem możemy rozszerzyć na odpowiedni dobór wartości progowych monitorowanych parametrów, które to wartości powodują zgłoszenie alarmu.

Co więc powinniśmy monitorować? Tutaj niestety nie ma uniwersalnej odpowiedzi, można jedynie nakreślić kilka ogólnych zasad, którymi będziemy się kierować przy konfiguracji naszego super systemu monitorującego.

• Po pierwsze, zawsze warto znać „zajętość systemu”. W przypadku serwerów Linuksowych będzie to parametr „load average” oraz zużycie pamięci (najlepiej z rozdzieleniem na pamięć zużytą przez procesy i na cache). Dla urządzeń sieciowych jak routery i switche oraz dla systemów opartych na systemie Windows oraz dla macierzy dyskowych będzie to najprawdopodobniej obciążenie procesora/ów i (jeżeli to możliwe) wykorzystanie pamięci. Czasami warto dorzucić do tego zestawu ilość procesów uruchomionych w systemie.

• Drugim istotnym elementem jest kontrola interfejsów sieciowych, ale tylko tych, które są dla nas istotne. Zupełnie pozbawione sensu jest monitorowanie interfejsów typu loopback na serwerach oraz portów na switchach w warstwie access, do których podłączone są poszczególne stacje robocze. Wprawdzie zdarzają się przypadki, w których warto posiadać takie informacje, jednak w każdym momencie możemy sobie taką tymczasową sondę skonfigurować, a długoterminowe trendy tego typu są raczej mało użyteczne.

• Kolejną rzeczą jest zajętość dysków w serwerach i macierzach dyskowych. Właśnie tutaj najbardziej przydają się zestawienia obejmujące długie czasy (rzędu miesięcy), za pomocą których możemy przewidzieć konieczność rozbudowy swojej infrastruktury sieciowej. Dzięki wyznaczonym na podstawie takiego zestawu danych trendów możemy z odpowiednim wyprzedzeniem poczynić odpowiednie zakupy i przemigrować nasze pliki na bardziej pojemne rozwiązania, unikając jednocześnie niepochlebnych opinii ze strony użytkowników i nerwowego kupowania przypadkowych dysków, bo nagle odkryliśmy, że na serwerze plików skończyło się miejsce.

• Czwarta grupa dotyczy parametrów specyficznych dla pełnionych przez urządzenia zadań. I tak, dla systemu Linuksowego pełniącego rolę tzw. NATownicy, warto wiedzieć, jak dużo wpisów znajduje się w tablicy conntrack. W przypadku routera „spinającego” sesje BGP, istotnymi informacjami okazują się ilość prefiksów, które dostajemy od poszczególnych peerów. Warto też znać długość kolejki oczekujących do przetworzenia wiadomości dla serwera pocztowego, ilość zestawionych sesji dla koncentratora VPN, zestawienie pokazujące „jakość” wiadomości dla filtrów antySPAMowych, rodzaje zapytań do bazy danych…

Wymieniać można długo i z każdą chwilą robi się tego więcej. W którym momencie należy powiedzieć „dość”? Spróbujmy do problemu podejść od drugiej strony: dla każdego wymyślonego parametru znajdźmy jakieś zastosowanie. Czy ten konkretny wykres pomoże nam przewidzieć zużycie zasobów? Czy skonfigurowana właśnie sonda ułatwi rozwiązanie jednego ze standardowych problemów, z którymi spotykamy się z naszej pracy? A może dzięki kolorowemu obrazkowi prezes będzie mniej marudził przy podpisywaniu budżetu na kolejny rok? Jeżeli na wszystkie powyższe pytania odpowiedzieliśmy negatywnie i nie jesteśmy w stanie wykombinować żadnego zastosowania, to może jednak z takiego parametru zrezygnować? Warto monitorować 10% parametrów za dużo, niż za mało. Jednak z drugiej strony lepiej dokładać sondy w miarę potrzeb, niż monitorować setki parametrów niepotrzebnie. Powtórzę to z resztą jeszcze raz: Przy wdrażaniu nowego rozwiązania naprawdę warto dobrze przemyśleć, które dane będziemy mogli wykorzystać do diagnostyki działania infrastruktury i tylko takie zbierać. Z czasem zaprocentuje to mniejszych chaosem i większą przejrzystością całego systemu.

No dobra, skoro udało nam się odpowiedzieć na pytanie „co i o czym chcemy mieć informacje?”, to przyszedł czas na pytanie „czym będziemy zbierali informacje?”. Istnieje wiele, bardzo różniących się od siebie, rozwiązań, które pomogą nam w ukończeniu tego zadania i zanim dokonamy wyboru, warto kilka z nich przetestować. Postaram się poniżej przedstawić króciutki opis rozwiązań najczęściej wykorzystywanych.

• Zacznijmy od rzeczy najprostszych, czyli od pakietu RRDtool, napisanego przez Tobiasa Oetikera. Umożliwia on zbieranie danych z bazie typu round robin i rysować na ich podstawie wykresy. Nic nie stoi na przeszkodzie, abyśmy własnoręcznie napisali skrypty wykorzystujące to narzędzie i dostosowali wszystko do własnych potrzeb. Będzie pięknie i kolorowo. Kiedyś tak nawet robiłem, jednak wymaga to bardzo dużo pracy i – wobec mnogości innych rozwiązań – jest niezbyt atrakcyjne (w szczególności dla rozwiązań standardowych). O genialności RRDtool świadczy fakt, iż spora część dostępnych pakietów do monitorowania jest oparta właśnie o to narzędzie.

• Drugim, trochę bardziej rozbudowanym programem jest MRTG tego samego autora. To narzędzie umożliwia rysowanie wykresów na podstawie danych, które MRTG samo sobie zbierze za pomocą protokołu SNMP. Wystarczy tylko skonfigurować agenty SNMP na maszynach, które chcemy monitorować, utworzyć prosty plik konfiguracyjny dla MRTG i możemy się cieszyć zestawem kolorowych wykresów. Jednak autor pisał ten program z myślą o monitorowaniu głównie (wyłącznie?) routerów, co powoduje, że na dłuższą metę jest to rozwiązanie dość mocno ograniczone i niezbyt wygodne.

• Teraz będzie jedno z moich ulubionych narzędzi: Cacti. Ulubione dlatego, że jest łatwe w instalacji i konfiguracji prostych scenariuszy. Z drugiej strony – w przypadku bardziej rozbudowanych instalacji jest wyjątkowo uciążliwe :-) Ale wracając do samego produktu, Cacti, podobnie jak MRTG, umożliwia rysowanie wykresów na podstawie zebranych danych. Jednak w tym przypadku wykresy mogą być wielokolorowe, z rozbudowanymi opisami i poukładane w funkcjonalne drzewa. Także zbieranie danych nie jest ograniczone wyłącznie do SNMP. W każdym momencie możemy dopisać własny skrypt, który dostarczy kaktusowi odpowiednio obrobionych danych. Warto także wspomnieć, że istnieje bardzo dużo tzw. template’ów, umożliwiających zbieranie danych z wielu, nieraz dość egzotycznych, urządzeń. Jeżeli nie ma gotowego rozwiązania, to nic nie stoi na przeszkodzie, abyśmy sami taki template napisali (i oczywiście udostępnili go innym). Kaktusa używam na co dzień i sprawdza się całkiem nieźle, nawet pomimo swoich niedoskonałości.

• Opisane przed chwilą rozwiązania służą do zbierania danych i tworzenia na ich podstawie wykresów. Ale co z monitoringiem „na bieżąco”? Takim, który będzie na nas wrzeszczał, jak padnie nam router albo któryś z administratorów potknie się o kabel i odłączy połowę użytkowników od sieci? Do takich zadań możemy użyć na przykład Nagiosa. Jest to narzędzie przeznaczone do monitorowania infrastruktury IT, umożliwiające ocenę bieżącego stanu wszystkich podłączonych do niego urządzeń. Napisany w PERLu produkt ma dość toporną, ale nieźle opisaną konfigurację, wobec czego musimy się odrobinę natrudzić, zanim stanie się wygodny i naprawdę użyteczny. Jednak moim zdaniem warto, ponieważ zyskujemy bardzo potężne narzędzie, które pomoże nam w codziennej pracy i bardzo skróci czas poszukiwania źródeł awarii.

• Zabbixa niektórzy określają jako „złoty środek” pomiędzy Cacti a Nagiosem. Ten produkt umożliwia tworzenie statystyk oraz monitoring bieżący w jednym miejscu. Ma jednak zupełnie odmienną od Nagiosa politykę. O ile w tym pierwszym musimy skonfigurować wszystkie testy, które wydają nam się potrzebne, to Zabbix „z pudełka” próbuje monitorować wszystko, co tylko autorom przyszło do głowy, a nasza rola sprowadza się do powyłączania rzeczy zbędnych. Szczerze pisząc, niezbyt mnie to przekonało i na swoim podwórku używam głównie duetu Cacti+Nagios, który – jak do tej pory – sprawdza się świetnie.

Poza wymienionymi powyżej rozwiązaniami istnieją jeszcze dość popularne narzędzia, o których istnieniu wiem, ale ich nie testowałem (kolejność przypadkowa):

• collectd
• AdRem NetCrunch
• Open NMS
• Zenoss

A potężną tabelkę z porównaniem wielu podobnych programów można znaleźć TUTAJ.

I to chyba tyle w tym odrobinę przydługim wstępie do monitorowania. Cała reszta to już instalowanie, konfigurowanie, poprawianie błędów w konfiguracjach oraz… patrzenie na statystyki i uciecha z zielonych wskaźników na naszych ekranach.

Niedawno w moje łapy wpadł RouterBoard RB1200, dokładnie taki, jaki widnieje obok i jaki opisano na TEJ stronie. Zgodnie z oczekiwaniami, instalacja przebiegła bez większych problemów. Konfiguracja u Klienta jest dość prosta, więc jej przeniesienie z dotychczasowego urządzenia także nie nastręczyło kłopotów. Jednak, pomimo że pozornie wszystko zadziałało poprawnie, to jednak okazało się, że połączenie ze światem zostało w magiczny sposób ograniczone do 20Mbps. Jak na 150Mbps łącze, to zaskakująco mało. Zacząłem kombinować z ustawieniami routera, zdjąłem wszystkie reguły firewalla, porozpinałem NAT. Nic. Procesor routera się nudził, a transfer nie rósł. Postanowiłem zacząć szukać informacji o problemach sprzętowych tego konkretnego modelu…

Pech chciał, że WAN wpiąłem w port eth10. I okazało się to poważnym błędem. Wprawdzie dokumentacja do routera jasno mówi, że poszczególne porty są popodpinane do procesora routera w różny sposób, to jednak żadne oficjalny dokument (a przynajmniej ja takiego nie znalazłem) nie informuje, że porty eth9 oraz eth10 mają poważne problemy z wydajnością. Co ciekawe, jak się wie, czego szukać, to nawet na forum Mikrotika jest dyskusja na ten temat.

Ale tego typu historie często kończą się szczęśliwie i ta nie okazała się wyjątkiem. Ponieważ w tej konkretnej konfiguracji wykorzystane są raptem trzy porty, wystarczyło połączenie z Internetem wpiąć do innego portu, i wszystko zaczęło działa zgodnie z założeniami. Jakbym miał magiczną różdżkę czy coś…

Z technicznego punktu widzenia taką operację da się nawet przeprowadzić zdalnie, mając na miejscu kogoś, kto nam tą wtyczkę fizycznie przełoży. Żeby nie stracić połączenia z routerem zrobiłem tak:

• Zdefiniowałem bridge’a złożonego z portów eth10 oraz eth7,
• Do skonfigurowanego adresu WAN, zamiast eth10, przypisałem nowo utworzony bridge,
• Pozmieniałem wszystkie wystąpienia eth10, które występowały w firewallu,
• Poprosiłem osobę na miejscu o przełożenie wtyczki w jej nowe miejsce.

Tym razem będzie jeszcze morał: W obecnych czasach nawet dokładne przeczytania instrukcji do instalowanego sprzętu nie gwarantuje sukcesu, a wujek google zna odpowiedzi na wszystkie pytania, tylko my mamy problemy, żeby je poprawnie sformułować :-)

Ponieważ ostatnio udało mi się „udusić” Mikrotika za pomocą laptopa podłączonego przez WiFi (obciążenie CPU routera wskazywało 100%, a urządzenie nie odpowiadało nawet na porcie SSH), postanowiłem dorzucić do Cacti wykres obrazujący obciążenie procesora mojego routerka. Najpierw zacząłem szukać odpowiednich schematów (ang. template), ale znalazłem tylko rozbudowane do granic możliwości kombajny albo rozwiązania, które nie działały. Przyszło mi nawet do głowy, że będę musiał utworzyć własny template, na co zupełnie nie miałem ochoty. Szczęśliwie trafiłem na TEN wpis, dzięki któremu udało mi się rozwiązać mój problem w ciągu 5 minut.

Aby wpis ten był odrobinę chociaż kształcący, popatrzmy, jak zaaplikować taki mechanizm krok po kroku.

Najpierw trzeba określić, co tak właściwie chcemy mierzyć. Mi aktualnie potrzebne jest obciążenie procesora i właśnie ten parametr posłuży nam za przykład. W RouterOS takie coś oczywiście istnieje i jest dostępne w bardzo prosty sposób (przy okazji obrazek pokazuje też wersję systemu):

Ale jak się do tych danych dostać z poziomu Cacti? Najpierw należy zidentyfikować OID, co też okazało się rzeczą niezbyt skomplikowaną:

[kbechler@zgoda-router] > /system resource cpu print oid
 0 load=.1.3.6.1.2.1.25.3.3.1.2.1
[kbechler@zgoda-router] >

Mając już upragniony ciąg znaków (składający się wprawdzie tylko z cyferek i kropek, ale nadal w danym momencie upragniony), możemy przystąpić do konfigurowania Cacti na podstawie wpisu z bloga, do którego wyżej linkowałem. W tym celu logujemy się do konsoli Cacti, klikamy na „Create”=>”New graphs” i w sekcji „Graph Templates” wybieramy „SNMP – Generic OID Tables” (jak na obrazku poniżej).

Teraz klimay na dole strony „Create” i w następnym formularzu wpisujemy pozyskany kilka chwil wcześniej ciąg znaków w pole „OID”.

I to wszystko – za kilka minut Cacti pobierze sobie z routera odpowiednie dane i zacznie rysować śliczny wykresik, na którym będziemy mogli pooglądać, jak bardzo zapracowany jest nasz router.

Podczas normalnej pracy z serwerami często zdarza mi się uruchomić zadania, które trwają dość długo. Niestety, czasami są to procesy działające głęboko w systemie programy, które nie raportują na bieżąco, co się z nimi dzieje. A człowiek jest zwierzęciem z natury niecierpliwym i chciałby wiedzieć, jak długo będzie jeszcze musiał czekać na wyniki polecenia, które wpisał całe wieki (czyli jakieś 5 minut) temu. Dobrym przykładem jest budowanie programowych macierzy za pomocą systemowego mdadm. Samo narzędzie definiuje tylko parametry nowej macierzy, zaś jej budowaniem zajmuje się proces systemowy, który nie jest specjalnie rozmowny. Szczęśliwie można podejrzeć stan zaawansowania poprzez wyświetlenie zawartości pliku /proc/mdstat:

[kbechler@flame ~]$ cat /proc/mdstat
Personalities : [raid1]
md127 : active raid1 cciss/c0d1p3[1] cciss/c0d0p3[0]
      383789078 blocks super 1.2 [2/2] [UU]

md0 : active raid1 cciss/c0d1p1[1] cciss/c0d0p1[0]
      102502328 blocks super 1.0 [2/2] [UU]
      bitmap: 1/1 pages [4KB], 65536KB chunk

unused devices: 
[kbechler@flame ~]$

Wielokrotne wpisywanie tej samej komendy może być trochę nużące, więc ktoś kiedyś wymyślił komendę watch, dzięki której możemy sobie życie trochę ułatwić. Niestety, świat idealny nie jest i w niektórych systemach (np. w konsoli administracyjnej macierzy QNAP) takiego narzędzia po prostu nie ma. I tutaj z pomocą przychodzi znajomość kilku innych komend (których na szczęście nikt QNAPowych urządzeń nie pozbawił). Jednym z prostszych „zamienników” wspomnianego watch’a jest taka oto konstrukcja:

[kbechler@flame ~]$ while [ 1 ]; do clear; cat /proc/mdstat; sleep 2; done

Warto zauważyć, że nie tylko ja miewam takie problemy, bo identyczną konstrukcję znalazłem na TEJ stronie :-)