Obciążenie serwera VPN wyjaśnione: użytkownicy, CPU czy łącze wysyłania?

Brama z obciążeniem 0.4 nadal może się wlec dla każdego użytkownika za nią. Średnie obciążenie liczy zadania, które można uruchomić lub które utknęły w nieprzerwalnym śnie, a na hoście z czterema rdzeniami jeden nasycony proces wystarczy, by zbliżyć je do 1.0, podczas gdy trzy rdzenie siedzą bezczynnie. Czytanie tej liczby jako zapasu to najczęstszy błąd przy wyborze punktu końcowego. To, co naprawdę ogranicza tunel, to zwykle jedna z czterech rzeczy: jeden zajęty rdzeń, łącze wysyłania, kolejka przed nim lub polityka na sesję, której nikt nie udokumentował.

Średnie obciążenie liczy zadania, nie przepustowość

Jądro próbkuje kolejkę zadań do uruchomienia i liczbę zadań czekających na wejście i wyjście, a następnie wygładza oba w oknach jednej, pięciu i piętnastu minut. Nic w tej definicji nie wspomina bajtów, pakietów ani tuneli. Host z zablokowanym magazynem może zgłosić wysokie obciążenie przy prawie zerowym ruchu, a host przepychający gigabit przez ścieżkę danych jądra może zgłosić wygodne.

Korelowanie obciążenia z wydajnością tunelu wymaga więc spojrzenia na każdy rdzeń. Jeśli jeden rdzeń jest zajęty w całości, łączny procent na pulpicie nadal będzie wyglądał dobrze:

cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20

Trzecie polecenie jest najważniejsze na hostach VPN. Przetwarzanie pakietów w przestrzeni użytkownika w OpenVPN 2.x jest w dużej mierze szeregowane na proces, więc jeden zajęty wątek może stać się sufitem, podczas gdy pulpit raportuje obfitość wolnych zasobów. Jeśli w wolnym okresie jeden wątek zajmuje większość rdzenia, host nie jest ogólnie niedowymiarowany; jest ograniczony w wymiarze, który akurat ma znaczenie.

Zwróć uwagę także na czas. Średnie z piętnastu minut ukrywają skok, który zepsuł rozmowę, więc zrzut ekranu zrobiony po skardze jest słabym dowodem. Próbkuj w trakcie problemu i zachowaj znacznik czasu razem z wynikiem.

Łącze wysyłania i kolejka przed nim

Liczniki interfejsu odpowiadają na pytanie o pasmo, na które liczby CPU nie potrafią. Oddzielają też pojemność od strat, a to różne awarie z różnymi naprawami:

ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

Łącze zbliżone w trakcie testu do przypisanej mu prędkości jest wyjaśnieniem i żadna ilość wolnego CPU tego nie zmieni. Wiersz qdisc dodaje szczegół istotny dla ruchu interaktywnego: zaległości i odrzucenia mówią, czy pakiety czekają w kolejce przed wyjściem. Kolejka, która zapełnia się przy dużym wysyłaniu, daje dokładnie ten objaw, który ludzie zrzucają na zdalny serwer, czyli wolne rozmowy na połączeniu, które w testach nadal wypada dobrze.

Liczniki retransmisji wychwytują przypadek, w którym pakiety wychodzą, ale nigdy nie docierają czysto. Jeśli retransmisje rosną w wolnym oknie, a interfejs jest daleko od pojemności, problem leży na ścieżce, a nie na hoście, i przeniesienie do innego punktu końcowego w tym samym mieście nie pomoże.

Liczby sesji opisują popyt, nie zapas

Każdy publiczny katalog pokazuje jakąś liczbę połączonych użytkowników i prawie żaden nie mówi, co ci użytkownicy robią. Dwadzieścia sesji wykonujących pracę interaktywną i cztery sesje ściągające duże pliki dają bardzo różne obciążenia na tym samym sprzęcie. Drugi wzorzec jest niewidoczny w liczbie użytkowników i to on psuje wieczór. Dlatego liczbę sesji czyta się najlepiej jako wskazówkę o popycie, nigdy jako stwierdzenie o wolnym zapasie.

Na hoście, który kontrolujesz, plik stanu daje brakujący wymiar. OpenVPN zapisuje okresowy zrzut zawierający liczniki bajtów dla każdego klienta, a to wystarcza, by zobaczyć, czy jedna sesja odpowiada za całe łącze wysyłania:

status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.status

Dwie próbki dziesięć sekund od siebie zamieniają te narastające liczniki na szybkość dla klienta. To pomiar, którego rolę odgrywa liczba użytkowników, i w ten sposób odkrywasz, że jeden źle skonfigurowany klient nasyca łącze każdej nocy o tej samej godzinie.

Limity na sesję kryją się w polityce

Serwer może być bezczynny i nadal odmawiać ci pasma. Limity prędkości, pułapy pasma na klienta i kształtowanie ruchu są często stosowane według wspólnej nazwy lub puli, więc dwóch użytkowników na tej samej bramie może dostać zupełnie różne wyniki. Mechanizm nie jest subtelny, ale jest niewidoczny z zewnątrz, bo tunel w obu przypadkach wstaje normalnie.

Szukaj kształtowania na interfejsie tunelu, a nie na fizycznym. Sprawdź, czy limit podąża za użytkownikiem, certyfikatem czy pulą adresów. Jeśli twoje konto testowe trafi do puli bez limitu, dojdziesz do wniosku, że serwer jest w porządku, a skarżący się użytkownik się myli. Taki wniosek jest gorszy niż żaden, bo zamyka zgłoszenie.

Porównaj dwa punkty końcowe jednym ustalonym zadaniem

Eksperyment po stronie klienta nadal warto przeprowadzić, ale tylko przy ustalonych zmiennych. Użyj tego samego urządzenia, tej samej sieci dostępowej, tego samego protokołu i tego samego pliku docelowego, a potem powtórz wobec drugiego punktu końcowego w podobnej odległości. Wszystko, co zmienia się między przebiegami, w tym pora dnia, zanieczyszcza wynik.

Zapisuj porażki równie starannie jak sukcesy. Seria, w której trzy punkty końcowe działają, a jeden kończy się przekroczeniem czasu, jest bardziej pouczająca niż cztery liczby prędkości, bo wskazuje na problem ścieżki lub polityki, a nie pojemności. Uruchamiaj każdy przypadek co najmniej dwa razy; jedna wolna próbka niczego nie dowodzi w sieci współdzielonej.

Na koniec trzymaj zebrane liczby razem z twierdzeniem, które wspierają. "Ten punkt końcowy wykonał transfer w tym samym oknie, w którym drugi utknął" jest do obrony, natomiast "ten punkt końcowy jest szybszy" zaprasza do sporu, którego nie wygrasz wynikiem ze strony głównej. Podręcznik OpenVPN 2.6 dokumentuje plik stanu i opcje kształtowania, jeśli potrzebujesz dokładnych dyrektyw dla strony hosta.