ver. 0.8.9 - SureAlived

ver. 0.8.9
Spis treści
1 Wprowadzenie
1.1 Czym jest i jak działa SureAliveD? . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Charakterystyka surealived . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Charakterystyka ipvssync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3
4
4
2 Instalacja
2.1 Ze źródeł . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5
3 Uruchomienie
3.1 Schemat działania . . . . . . . . . . .
3.2 Uruchamianie testera . . . . . . . . .
3.3 Uruchamianie synchronizatora . . . .
3.4 Ogólne uwagi odnośnie uruchamiania
.
.
.
.
7
7
8
8
9
.
.
.
.
.
.
.
.
.
.
.
.
10
10
10
11
11
12
12
13
14
14
14
15
15
.
.
.
.
.
.
.
.
.
.
.
.
4 Konfiguracja
4.1 Głowny plik konfiguracyjny . . . . . . . .
4.1.1 Zmienne konfiguracyjne surealived
4.1.2 Zmienne konfiguracyjne ipvssync .
4.1.3 Wspólne zmienne konfiguracyjne .
4.2 Konfiguracja serwisów . . . . . . . . . . .
4.2.1 Ogólny zarys konfiguracji serwisów
4.2.2 Tester HTTP . . . . . . . . . . . .
4.2.3 Tester TCP . . . . . . . . . . . . .
4.2.4 Tester DNS . . . . . . . . . . . . .
4.2.5 Tester EXEC . . . . . . . . . . . .
4.2.6 Pseudotester NO-TEST . . . . . . .
4.3 Interfejs CMD . . . . . . . . . . . . . . . .
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1 Wprowadzenie
Linux Virtual Server (LVS) jest jednym z najbardziej wydajnych serwerów balansowania ruchu. W
środowiskach, gdzie istnieja˛ setki (jak nie tysiace)
˛ usług wpi˛etych do LVS, prawdziwym wyzwaniem
staje si˛e ich przetestowanie i podj˛ecie właściwej akcji (wypi˛ecie / wpi˛ecie serwera). Problemem skalowania w tej materii jest także niewielki wybór aplikacji testujacych,
˛
w szczegolności dla LVSów, gdzie
wpi˛etych jest wiele serwerów a cz˛estotliwość testu nie powinna być dłuższa niż kilka sekund. Takie założenie zdecydowanie ogranicza list˛e możliwych do zastosowania aplikacji, gdyż musza˛ one być oparte
o multipleksowane IO (select/poll/epoll). Do tej pory jedyna˛ aplikacja˛ spełniajac
˛ a˛ te wymagania był
keepalived. Ze wzgl˛edu na bł˛edy i pewne braki funkcjonalne w keepalived zdecydowaliśmy si˛e napisać
od zera tester usług. Nazwaliśmy go dość przewrotnie SureAliveD, ze wzgl˛edu na to, iż chcemy być
pewni, że wpi˛ete do LVSa usługi działaja.˛
1.1
Czym jest i jak działa SureAliveD?
SureAliveD jest bardzo efektywnym testerem serwerów real wpi˛etych do LVSa. Zdecydowaliśmy si˛e na
odseparowanie warstwy testujacej
˛ od modyfikujacej
˛ zmiany w jadrze
˛
linuksa (w tablicy IPVS). Aplikacj˛e
testujac
˛ a˛ dost˛epność reali nazwaliśmy surealived, natomiast synchronizator zmian w IPVS ipvssync.
Podstawowym założeniem aplikacji było zastapienie
˛
stosowanego do tej pory keepalived w cz˛eści
testujacej.
˛
Keepalived świetnie sprawuje si˛e tam, gdzie nie ma potrzeby cz˛estego grzebania w konfiguracji. W dużych środowiskach, gdzie do LVSa wpi˛ete sa˛ setki usług, problematyczna staje si˛e każdorazowa konieczność przeładowania całości konfiguracji (nawet przy potrzebie zmiany wagi pojedynczego
serwera). Przy cz˛estym przeładowywaniu konfiguracji uwidaczniaja˛ si˛e bł˛edy takie jak:
• zaniechanie testowania niektórych usług
• segfaultowanie testera
• pozostawienie otwartych deskryptorów
• brak możliwości przetestowania poprawności składni pliku konfiguracyjnego
• czyszczenie tablicy IPVS1 .
1 Istnieje
owszem opcja uruchomienia keepalived z pozostawieniem starych wpisów, jednak od tego momentu przestaje si˛e
on ”interesować” serwerami, których nie ma już w konfiguracji a pozostały w IPVS – i zamiast usuwać pozostawia je nietkni˛ete
z uprzednio ustawiona˛ waga.˛
3
1.2
Charakterystyka surealived
Oto podstawowe cechy testera – surealived:
• oparty na epollu,
• posiada rozszerzalna˛ XMLowa˛ konfiguracj˛e (rozparsowywalna˛ przez moduł),
• testery usług sa˛ w rzeczywistości ładowanymi dynamicznie modułami – daje to możliwość łatwego
dodawania nowych testerów kolejnych usług,
• obecnie zaimplementowane moduły testujace
˛ protokół TCP, HTTP, DNS, exec (uruchomienie
zewn˛etrznego testera) oraz no-test (traktowanie serwera jako dost˛epnego)
• ma wbudowana˛ przezroczysta˛ obsług˛e SSL (wystarczy ustawić atrybut SSL=”1” przy konfiguracji
testera).
• zapisuje statystyki połaczeń
˛
do poszczególnych serwerów (czas połaczenia
˛
i czas odpowiedzi),
• trzyma tablic˛e stanów serwerów, których test si˛e nie powiódł, a także tablic˛e przesłaniajac
˛ a˛ bieżac
˛ a˛
konfiguracj˛e (stan serwera oraz wagi), stany te sa˛ honorowane po restarcie,
• na starcie nast˛epuje zapisanie stanu dla ipvssync i wymuszenie synchronizacji konfiguracji z
tablica˛ IPVS,
• komunikacja z ipvssync odbywa si˛e poprzez plik konfiguracji dla ipvssync (zapisywany co 60 sek.)
oraz pliki różnicowe, zapisywane przy każdej zmianie,
• start testów rozłożony jest w czasie (1 sek.), co zmniejsza obcia˛żenie CPU w przypadku równoczesnego uruchomienia testów dla setek reali,
• umożliwia sprawdzenie składni konfiguracji (parametr -t),
• restart aplikacji nie stanowi problemu,
• możliwa jest praca surealived tylko jako testera usług, bez synchronizacji do IPVS,
• wystawia port do zarzadzania
˛
(domyślnie 1337), umożliwiajac
˛ wykonywanie pewnych akcji bez
restartowania aplikacji.
1.3
Charakterystyka ipvssync
Oto cechy synchronizatora ipvssync:
• używa konfiguracji generowanej przez surealived (ipvsfull.cfg) oraz plików różnicowych
• pozwala na pozostawienie/usuni˛ecie niezarzadzanych
˛
przez niego wirtuali z IPVS, w przypadku
reali pełna synchronizacja odbywa si˛e zawsze,
• możliwe jest sprawdzenie składni konfiguracji (parametr -t),
• restart aplikacji nie jest problemem, podobnie jak w przypadku restartu surealived nast˛epuje
wymuszenie pełnej synchronizacji z IPVS,
• wymaga działania z użytkownika root.
4
2 Instalacja
2.1
Ze źródeł
Do skompilowania potrzebne sa˛ nast˛epujace
˛ aplikacje i biblioteki2 :
• gcc
• cmake
• make
• glib2-dev
• libxml2-dev
• libssl-dev
• źródła kernela (lub pakiet linux-headers)
Po rozpakowaniu surealived-x.y.z.tar.gz w katalogu znajduja˛ si˛e nast˛epujace
˛ podkatalogi:
• common – katalog z plikami źródłowymi wykorzystywanymi zarówno przez surealived jak i
ipvssync
• doc – dokumentacja
• examples – przykładowe xmlowe pliki konfiguracyjne surealived
• ipvssync – katalog ze źródłami synchronizatora
• libipvs – biblioteka do komunikacji z IPVS, autorstwa Wensong Zhanga, wykorzystywana przez
synchronizator
• surealived – katalog ze źródłami testera
Kompilacj˛e + instalacj˛e należy wykonać z konta root:
#
#
#
#
#
tar xzvf surealived-x.y.z.tar.gz
cd surealived-x.y.z
cmake .
make
make install
Po instalacji w systemie pojawia˛ si˛e binarki:
• /usr/sbin/ipvssync
• /usr/bin/surealived
Głowny plik konfiguracyjny surealived.cfg wykorzystywany przez obie aplikacje zostaje przekopiowany
do katalogu /etc/surealived.
2 Podane
aplikacje i biblioteki sa˛ nazwami pakietów Debiana.
5
Ponadto zostaja˛ utworzone katalogi:
• /var/log/surealived – dla logów testera i synchronizatora,
• /var/log/surealived/comm – dla wirtuali z ustawionym atrybutem debugcomm=”1”,
• /var/lib/surealived – dla dynamicznej konfiguracji testowanych usług surealived3 oraz konfiguracji ipvssync4 ,
• /var/lib/surealived/diffs – z konfiguracja˛ różnicowa˛ dla ipvssync,
• /var/lib/surealived/stats – dla statystyk testów reali.
3 Pliki
4 Plik
offline.dump oraz override.dump.
ipvsfull.cfg, pliki z konfiguracja˛ różnicowa˛ sa˛ w katalogu diffs.
6
3 Uruchomienie
3.1
Schemat działania
Na poniższym diagramie przedstawiony jest schemat przepływu danych pomi˛edzy testerem a synchronizatorem.
Po lewej stronie diagramu znajduje si˛e tester (surealived), złożony z dwóch procesów – watchdoga
i testera. Po prawej stronie jest jednoprocesowy synchronizator (ipvssync) wpi˛ety do IPVS – synchronizer. Na środku diagramu umieszczone zostały pliki i katalogi biorace
˛ udział w wymianie danych
mi˛edzy aplikacjami.
Kluczowym plikiem wspólnym dla testera i synchronizatora jest surealived.cfg, którego składnia
opisana jest w nast˛epnym rozdziale. Jest to prosty plik typu ”klucz wartość” opisujacy
˛ parametry działania obu aplikacji.
Tester definicj˛e usług do przetestowania bierze z pliku services.xml5 . Widok reali, ich wag i to czy
sa˛ wpi˛ete przesłaniane jest przez dwa pliki – offline.dump oraz override.dump. Plik offline.dump jest
zapisywany przez tester i zawiera reale, których nie udało si˛e poprawnie przetestować. Dzi˛eki temu
po starcie podejrzane serwery nie sa˛ wpinane lub wpinane z waga˛ = 0 do IPVS. Plik, który również
przesłania konfiguracj˛e to override.dump. Może być on modyfikowany przez użytkownika poprzez interfejs cmd widoczny po lewej stronie diagramu. Jest to wystawiony nasłuchujacy
˛ port umożliwiajacy
˛
wykonanie kilku interesujacych
˛
poleceń na działajacym
˛
testerze. Co dokładnie można wykonać zostało
opisane w nast˛epnym rozdziale.
Podczas startu tester wymusza zbudowanie konfiguracji synchronizatora ipvsfull.cfg i inicjuje zapisywanie plików różnicowych w katalogu diffs. Chodzi o to, by przy każdym wykrytym nieprawidłowo działajacym
˛
serwerze nie zapisywać od razu całej konfiguracji a jedynie różnic˛e. Stad
˛ też plik ipvsfull.cfg
zmienia si˛e co 60 sek. a wszelkie zmiany w stosunku do głównej konfiguracji sa˛ w ostatnim, bieża˛
cym pliku różnicowym. Dwa bardzo ważne zbiory biorace
˛ w tym udział to plik muteksujacy
˛ dost˛ep do
konfiguracji synchronizatora – ipvsfull.lock oraz flaga konieczności przeładowania konfiguracji – ipvsfull.reload. Po restarcie testera stan IPVS z jego punktu widzenia jest nieznany, dlatego też po zbudowaniu konfiguracji ipvsfull.cfg wskazuje on konieczność pełnej modyfikacji IPVS poprzez założenie pliku
ipvsfull.reload. Tego pliku regularnie poszukuje ipvssync i w przypadku znalezienia czyta nowa˛ konfiguracj˛e, wprowadza zmiany do IPVS po czym usuwa zbiór ipvsfull.reload. Podczas działania ipvssync
wie w którym pliku różnicowym si˛e znajduje i usuwa z katalogu diffs wszystkie stare zbiory.
Tester daje możliwość zapisu statystyk w katalogu stats. Może zapisywać zarówno do jednego
wspólnego zbioru sd_fullstats.log a także zbiorów z pojedynczego testu – sd_virtstats*.TIMESTAMP.
W przypadku zapisu do pojedynczych zbiórów należy zadbać o usuwanie tych zbiorów z katalogu stats6 .
5 Oczywiście
plik ten może si˛e nazywać zupełnie inaczej, my założyliśmy, że jest to akurat services.xml.
zapiać
˛ w cronie usuwanie lub w ogóle nie właczać
˛
zapisu do tych zbiorów poprzez ustawienie ”log_stats false”
w pliku surealived.cfg.
6 Można
7
3.2
Uruchamianie testera
Przed uruchomieniem synchronizatora po raz pierwszy, konieczne jest uruchomienie testera, zwiazane
˛
jest to z utworzeniem konfiguracji ipvsfull.cfg
By uzyskać list˛e możliwych opcji przy uruchamianiu testera wystarczy użyć opcji -h.
wegorz@zaphod:~$ surealived -h
=== SureAliveD v.0.8.9 ===
Usage: surealived [options] <xml_config_file>
Ex
: surealived -c /root/sd_new.conf -vv -d test_http.xml
Options:
--help
--test-config
--config
--verbose
--daemonize
--no-sync
--no-dumpfile
--version
-h
-t
-c <path>
-v
-d
-n
-k
-V
This help info
Test configuration and exit
Use <path> as config file
Increase verbosity level
Run in background (daemonize)
Do not write sync info
Do not load and create offline.dump
Show Version information
Bardzo użyteczna˛ opcja˛ jest -t, pozwalajaca
˛ przetestować poprawność xmlowego pliku konfiguracyjnego
serwisów. Standardowo kody wyjścia z programu oznaczaja:
˛ 0 – ok, różny od 0 – bład.
˛
W normalnym produkcyjnym środowisku zazwyczaj tester b˛edzie uruchamiany jako demon:
wegorz@zaphod:~$ surealived -d /etc/surealived/services.xml
Należy pami˛etać, że w przypadku uruchamiania testera jako demona wszelkie komunikaty o bł˛edach
pojawia˛ si˛e w /var/log/surealived/surealived.log o ile istnieje możliwość zapisu do takiego zbioru. Dlatego przed produkcyjnym uruchomieniem najlepiej jest przetestować czy tester bez problemu podniesie
si˛e jako proces pierwszoplanowy:
wegorz@zaphod:~$ surealived -vvv /etc/surealived/services.xml
3.3
Uruchamianie synchronizatora
Jeśli istnieje plik konfiguracyjny dla synchronizatora możemy go (synchronizator) uruchomić – koniecznie
z uprawnieniami roota, gdyż modyfikuje on IPVS.
By uzyskać list˛e możliwych opcji przy uruchamianiu synchronizatora wystarczy użyć opcji -h.
zaphod:~# ipvssync -h
=== IPVSSync v.0.8.9 ===
Usage: ipvssync [options]
Ex
: ipvssync -c /home/surealived/surealived.cfg
Options:
--help
--test-config
--config
--verbose
--daemonize
--del-umanaged
--keep-diffs
--version
-h
-t
-c
-v
-d
-u
-k
-V
This help info
Test ipvsfull.cfg configuration and exit
Config file (default /etc/surealived/surealived.cfg)
Increase verbosity level
Run in background (daemonize)
Delete unmanaged virtuals from IPVS table
Don’t remove processed diff files
Show Version information
8
Zanim jednak uruchomimy synchronizator możemy przetestować poprawność pliku ipvsfull.cfg wykorzystujac
˛ opcj˛e -t. Standardowo kody wyjścia z programu oznaczaja:
˛ 0 – ok, różny od 0 – bład.
˛
Opcje które zmieniaja˛ zachowanie synchronizatora to -u oraz -k. Pierwsza z nich powoduje, że
ipvssync działa trybie usuwania wszystkich niezdefiniowanych w pliku ipvsfull.cfg wirtuali. Jeśli wi˛ec
zostanie coś dodane ”z r˛eki” do IPVS przy przeładowaniu konfiguracji synchronizator usunie to z tablicy.
Druga wspomniana opcja wyłacza
˛ usuwanie plików różnicowych w katalogu diffs.
3.4
Ogólne uwagi odnośnie uruchamiania
Obie aplikacje zaleca si˛e uruchomić produkcyjnie z logowaniem typu info. W logach obu aplikacji
pojawia˛ si˛e najbardziej użyteczne informacje zwiazane
˛
z praca˛ zarówno testera jak i synchronizatora.
W przypadku testowania konfiguracji najlepiej jest aplikacje uruchomić z parametrem ’-vvv’, bez wprowadzenia
ich w tryb demona.
9
4 Konfiguracja
4.1
Głowny plik konfiguracyjny
Domyślnie główny plik konfiguracyjny surealived.cfg rezyduje w /etc/surealived. Zawiera on podstawowa˛ konfiguracj˛e zarówno dla surealived jak i ipvssync. Konfiguracja ta może być w oddzielnych
zbiorach, zwłaszcza, że synchronizator korzysta tylko z kilku zmiennych z tego zbioru. Jednakże, jeśli
chcemy si˛e uchronić przed dziwnymi bł˛edami zwiazanymi
˛
z tym, że oba programy b˛eda˛ miały różne
wartości tych wspólnych zmiennych lepiej jest je zostawić w tym zbiorze.
4.1.1 Zmienne konfiguracyjne surealived
Oto lista zmiennych wykorzystywanych przez tester:
• maxfd – maksymalna ilość (domyślnie 1024) otwartych deskryptorów procesu7 .
• log – ścieżka do logu lub stderr. Wartość ta jest nadpisywana na stderr jeśli program nie b˛edzie
uruchamiany w trybie demona.
• logging – poziom szczegółowości logowania w kolejności rosnacej:
˛
error, warn, info, debug,
debdt. Wartość ta jest nadpisywana przez parametr -v.
• modules_path – ścieżka do binarnych modułów (testera).
• modules – lista modułów do załadowania oddzielona przecinkami (UWAGA – nie może być spacji
po przecinku) lub all, co spowoduje załadowanie wszystkich modułów ze ścieżki modules_path.
• epoll_size – minimalny rozmiar epolla, jeśli ilość testowanych usług jest wi˛eksza od tej wartości
zostanie ona nadpisana.
• loop_interval_ms – określa co ile milisekund tester powinien sprawdzać czy czas testów virtuala
dobiegł końca lub też należy go wystartować (domyślnie: 100)
• epoll_interval_ms – maksymalny czas (w milisekundach) jaki epoll ma czekać na zdarzenie
(domyślnie: 10)
• startup_delay_ms – tzw. rozbiegówka – określa okres w którym testy maja˛ być rozpocz˛ete (czasy
startu testów b˛eda rozłożone w tym okresie) (domyślnie: 1000)
• debug_comm – flaga 0/1 określajaca
˛ możliwość zrzucania przebiegu komunikacji z realami w
danym wirtualu. Przełaczenie
˛
jej na 1 jest warunkiem koniecznym (niewystarczajacym)
˛
do zapisu
komunikacji przez tester8 .
• debug_comm_path – ścieżka, gdzie zapisywane b˛eda˛ zrzuty z komunikacji.
• memlimit – limit pami˛eci w MB, w przypadku przekroczenia limitu watchdog zresetuje surealived, wartość ta jest ignorowana gdy program nie jest uruchomiony jako demon.
• listen_addr – adres interfejsu poleceń (cmd) na którym można pobrać statystyki działania testera
a także wykonać aktywne operacje takie jak zmiana wagi reala oraz jego wpi˛ecie/wypi˛ecie (ONLINE/OFFLINE/DOWN), domyślnie 127.0.0.1.
7 Jeśli
uruchamiasz aplikacj˛e z roota sprawa jest prosta, w przeciwnym wypadku upewnij si˛e, że użytkownik może
przestawić ta˛ wartość.
8 Należy jeszcze w konfiguracji xmlowej w tagu <tester> ustawić atrybut debugcomm=”1”.
10
• listen_port – port interfejsu poleceń (cmd), domyślnie 1337.
• stats_dir – ścieżka, gdzie zapisywane b˛eda˛ statystyki testów9 .
• log_stats – ustawienie wartości na true spowoduje, że do stats_dir b˛eda˛ zapisywane statystyki
testów w sposób indywidualny, tj <zbiór>.<timestamp> per test wirtuala10 .
• log_stats_combined – wartość true oznacza, że do jednego zbioru b˛eda˛ dopisywane wszystkie
statystyki testów11 .
• no_sync – jeśli true nie b˛eda˛ tworzone pliki dla synchronizatora.
• use_offline_dump – czy zapisywać stan reali, których nie udało si˛e poprawnie przetestować (plik
stanów negatywnych).
• offline_dump – ścieżka do pliku offline.dump – wartość ta jest ignorowana gdy use_offline_dump
jest ustawione na false
• override_dump – ścieżka do pliku override.dump
4.1.2 Zmienne konfiguracyjne ipvssync
Oto lista zmiennych wykorzystywanych przez synchronizator:
• ipvssync_log – ścieżka do pliku logu synchronizatora lub stderr. Wartość ta jest nadpisywana na
stderr jeśli program nie b˛edzie uruchamiany w trybie demona.
• ipvssync_logging – poziom szczegółowości logowania w kolejności rosnacej:
˛
error, warn, info,
debug, debdt. Wartość ta jest nadpisywana przez parametr -v.
4.1.3 Wspólne zmienne konfiguracyjne
Oto lista zmiennych wykorzystywanych zarówno przez tester jak i synchronizator:
• lock_sync_file – plik służacy
˛ do synchronizacji pomi˛edzy testerem a synchronizatorem (flock).
• full_sync_file – plik pełnej konfiguracji tablicy IPVS dla synchronizatora (generowany co 60 sek.
przez tester).
• full_reload_file – plik (flaga), którego pojawienie si˛e wymusza przeładowanie konfiguracji synchronizatora.
• diff_sync_dir – katalog, gdzie zapisywane b˛eda˛ pliki różnicowe (zawierajace
˛ zmiany w stosunku
do pełnego pliku konfiguracji).
9 Można
10 Jeśli
je wykorzystać do analizy czasów odpowiedzi poszczególnych serwerów, zbalansowania wirtuali, itp.
właczysz
˛
ta˛ opcj˛e zadbaj o czyszczenie katalogu ze starych zbiorów, gdyż bardzo szybko b˛edziesz tam miał miliony
zbiorów.
11 Zbiór można przycinać, gdyż aplikacja dopisuje na koniec (tworzac
˛ wcześniej zbiór jeśli nie istnieje).
11
4.2
Konfiguracja serwisów
XMLowy plik konfigurujacy
˛ testowane przez surealived serwisy jest jego argumentem w momencie
uruchomienia. Może si˛e wi˛ec znajdować w dowolnym miejscu, załóżmy wi˛ec, że konfiguracja ta jest w
pliku /etc/surealived/services.xml.
4.2.1 Ogólny zarys konfiguracji serwisów
Plik konfigurujacy
˛ serwisy ma składni˛e typu:
<surealived>
<virtual ...>
<tester ... />
<real ... />
<real ... />
...
</virtual>
<virtual ...>
<tester ... />
<real ... />
...
</virtual>
</surealived>
Atrybuty taga <virtual>:
• name=”string” [obligatoryjny] – (max 31 znaków, z zakresu [a-zA-Z0-9_-]),
• addr=”ip” [obligatoryjny jeśli atrybut fwmark nie jest ustawiony, w przeciwnym wypadku b˛edzie
użyty adres ”0.0.0.0”],
• port=”int16” [0<=port<=65535, obligatoryjny jeśli nie jest ustawiony fwmark, w przeciwnym
wypadku ”0”],
• proto=”tcp|udp|fwmark” [obligatoryjny],
• sched=”string” [obligatoryjny] – zostanie wykorzystany taki scheduler,
• rt=”dr|masq|tun” [obligatoryjny], typ rutingu w IPVS
• fwmark=”int” [opcjonalny, jeśli > 0 proto=”fwmark” powinien być ustawiony],
• pers=”int” [opcjonalny] – dla połaczeń
˛
persistent to jest wartość timeoutu.
Atrybuty taga <tester>:
• loopdelay=”int” [opcjonalny, domyślnie 3] – określa opóźnienie w sekundach pomi˛edzy p˛etlami testujacymi
˛
ten wirtual,
• timeout=”int” [opcjonalny, domyślnie 5] – czas w sekundach podczas którego każdy real musi
zwrócić odpowiedź,
• retries2ok=”int” [opcjonalny, domyślnie 1] – ile testów musi si˛e powieść by real był potraktowany jako online,
• retries2fail=”int” [opcjonalny, domyślnie 1] – ile testów musi si˛e zakończyć niepowodzeniem by real był potraktowany jako offline,
12
• remove_on_fail=”0|1” [opcjonalnie, domyślnie 0 (fałsz)] – jeśli ”prawda” real b˛edacy
˛ offline
jest usuwany z IPVS,
• logmicro=”0|1” [opcjonalny, domyślnie 0 (fałsz)] – zapisywać statystyki z mikrosekundowa˛
dokładnościa˛ do plików statystyk (dla ”prawda”),
• proto=”string” [obligatoryjny] – który moduł zostanie użyty do testowania,
• testport=”int” [obligatoryjny] – który port ma być testowany (real może nadpisać ta˛ wartość
u siebie),
• SSL=”0|1” [opcjonalnie, domyślnie 0] – użyć SSL czy też nie.
Atrybuty taga <real>:
• name=”string” [obligatoryjny] (max 31 znaków, z zakresu [a-zA-Z0-9_-]),
• addr=”ip” [obligatoryjny] – adres IP reala,
• port=”int16” [obligatoryjny] – port IP reala w IPVS,
• weight=”int” [obligatoryjny] – waga reala w IPVS,
• uthresh=”int” [opcjonalny, domyślnie 0 (brak limitu)] – górny limit połaczeń
˛
reala w IPVS,
• lthresh=”int” [opcjonalny, domyślnie 0 (brak limitu)] – dolny limit połaczeń
˛
reala w IPVS,
• testport=”int16” [opcjonalny] – nadpisuje atrybut testera ”testport” dla danego reala,
• rt=”string” [opcjonalny] – nadpisuje atrybut testera ”rt” dla danego reala.
4.2.2 Tester HTTP
Gdy chcemy użyć testera HTTP do przetestowania konkretnego reala, należy ustawić proto=”http”
w tagu tester oraz atrybuty:
˛ odpytywany obiekt na serwerze,
• url=”string” [obligatoryjny, max 4095 znaków] – określajacy
• host=”string” [obligatoryjny, max 255 znaków] – określa nagłowek ”Host”,
• retcode=”string” [opcjonalny, domyślnie ”200”] – kod powrotu określajacy,
˛ że test si˛e powiódł,
• naive=”True|False” [opcjonalny, domyślnie ”False” (fałsz) – określa czy należy sciagać
˛
obiekt
do końca, czy wystarczy otrzymać kod powrotu.
Przykładowy plik XML:
<surealived>
<virtual name="onet" addr="192.168.0.1" port="80" proto="tcp" sched="wrr" rt="dr">
<tester loopdelay="1" timeout="2" retries2fail="1" retries2ok="1"
proto="http" testport="80" url="/" host="www.onet.pl"/>
<real name="sg" addr="213.180.146.27" port="80" weight="10"/>
</virtual>
</surealived>
13
4.2.3 Tester TCP
Najprostszy tester, sprawdza tylko otwartość portu TCP. Wymaga proto=”tcp” w tagu tester. Nie
wykorzystuje żadnych dodatkowych atrybutów.
Przykładowy plik XML:
<surealived>
<virtual name="onet" addr="192.168.0.1" port="22" proto="tcp" sched="wrr" rt="dr">
<tester loopdelay="1" timeout="2" retries2fail="1" retries2ok="1"
proto="tcp" testport="22" />
<real name="sg" addr="213.180.146.27" port="22" weight="10"/>
</virtual>
</surealived>
4.2.4 Tester DNS
Tester UDP sprawdzacy
˛ SOA dla podanej domeny. Wymaga proto=”dns” w tagu tester. Wykorzystuje tylko jeden dodatkowy atrybut:
• request=”string” [obligatoryjny, max 255 znaków] – określa domen˛e dla której tester odpyta
o SOA.
Przykładowy plik XML:
<surealived>
<virtual name="onetdns1" addr="192.168.0.1" port="53" proto="udp" sched="wrr" rt="dr">
<tester loopdelay="1" timeout="2" retries2fail="1" retries2ok="1"
proto="dns" testport="53" request="onet.pl" logmicro="1"/>
<real name="dns1" addr="213.180.128.240" port="53" weight="10"/>
<real name="dns2" addr="217.97.201.240" port="53" weight="11"/>
</virtual>
</surealived>
4.2.5 Tester EXEC
Tester który wywołuje dowolny zewn˛etrzny program. Wymaga proto=”exec” w tagu tester. Wykorzystuje dodatkowe atrybuty:
• exec=”string” [obligatoryjny, max MAXPATHLEN-1 znaków czyli 1023] – nazwa programu
do uruchomienia,
• params=”string” [opcjonalny, max 1023 znaki] – dodatkowe argumenty przekazywane programowi separowane spacjami.
W momencie wywołania lista argumentów z jaka˛ wywoływany jest program to:
• arg0 – adres IP reala,
• arg1 – port (testport) dla reala,
• arg2 – params[0],
• arg. – params[...],
• argn – params[n].
14
Oczywiście jeśli nie zostanie podany atrybut params aplikacja testujaca
˛ zostanie wywołana tylko z dwoma
argumentami.
Kod powrotu == 0 oznacza, że test si˛e powiódł. Dowolny inny kod powrotu traktowany jest jako
bład
˛ testu.
Przykładowy plik XML:
<surealived>
<virtual name="onetexec" proto="tcp"
addr="192.168.0.1" port="80" sched="wrr" rt="dr">
<tester loopdelay="1" timeout="5" retries2fail="1" retries2ok="1" testport="80"
proto="exec" exec="/usr/lib/surealived/scripts/testexec.pl"
params="www.onet.pl /0" />
<real name="sg" addr="213.180.146.27" port="80" weight="10" rt="dr"/>
</virtual>
</surealived>
4.2.6 Pseudotester NO-TEST
Pseudotester traktujacy
˛ serwer jako zawsze online. Wymaga proto=”no-test” w tagu tester.
Przykładowy plik XML:
<surealived>
<virtual name="onet" addr="192.168.0.1" port="80" proto="tcp" sched="wrr" rt="dr">
<tester loopdelay="1" timeout="2" retries2fail="1" retries2ok="1"
proto="no-test" testport="80" />
<real name="sg" addr="213.180.146.27" port="80" weight="10"/>
</virtual>
</surealived>
4.3
Interfejs CMD
Aplikacja surealived umożliwia odczyt pewnych parametrów pracy programu oraz nadpisywanie niektórych ustawień serwerów real w locie bez konieczności modyfikacji pliku services.xml. Domyślnie na
loopbacku (127.0.0.1) i porcie 1337 nasłuchuje interfejs cmd. Obecnie można wykonać nast˛epujace
˛
akcje:
• vlist [pasywny] – wylistowuje wirtuale zdefiniowane w pami˛eci testera,
• rlist [pasywny] – wylistowuje reale zdefiniowane dla konkretnego wirtuala w pami˛eci testera,
• stats [pasywny] – pokazuje statystyki działania aplikacji, ilość zdefioniowanych wirtuali, reali i
wiele innych,
• rset [aktywny] – umożliwia dynamiczne zarzadzanie
˛
wagami oraz ustawiania serwera w stan OFFLINE (waga = 0) lub DOWN (serwer jest usuwany z IPVS).
Przykłady:
> printf "vlist\n" | nc -q 1 localhost 1337
0. vname=onet vproto=tcp vaddr=192.168.0.1 vport=80 vfwmark=0 vrt=dr vsched=wrr
1. vname=wp vproto=tcp vaddr=192.168.0.2 vport=80 vfwmark=0 vrt=dr vsched=wrr
> printf "rlist vproto=tcp vaddr=192.168.0.2 vport=80\n" | nc -q 1 localhost 1337
1. raddr=212.77.100.101 rport=80 currwgt=11 confwgt=11 ronline=TRUE rstate=ONLINE
> printf "rset vproto=tcp vaddr=192.168.0.2 vport=80 raddr=212.77.100.101 rport=80 rweight=1\%\%\n" \
| nc -q 1 localhost 1337
15
Set: rstate=ONLINE, weight=1, inpercent=TRUE
> printf "rset vproto=tcp vaddr=192.168.0.2 vport=80 raddr=212.77.100.101 rport=80 rstate=OFFLINE\n" \
| nc -q 1 localhost 1337
Set: rstate=OFFLINE, weight=-1, inpercent=FALSE
> printf "rlist vproto=tcp vaddr=192.168.0.2 vport=80\n" | nc -q 1 localhost 1337
1. raddr=212.77.100.101 rport=80 currwgt=0 confwgt=11 ronline=TRUE rstate=OFFLINE
> printf "stats\n" | nc -q 1 localhost 1337
... statistics here ...
Polecenie aktywne rset umożliwia zmian˛e wagi również jako procent domyślnie skonfigurowanej
wartości. Trzeba pami˛etać, że dla 1% zostanie ustawiona waga minimum równa 112 .
Wszelkie zmiany modyfikowane z wykorzystaniem cmd zapisywane sa˛ w pliku override.dump.
Takie podejście umożliwia przetrwanie nadpisanych przez nas ustawień w przypadku modyfikacji konfiguracji xml lub zrestartowaniu surealived.
12 Zakładajac,
˛
że wagi sa˛ ustawiane w zależności od wypełnienia cache, przy wadze ustawionej na 10 i pustym cache 1%
zawsze równałby si˛e 0 i nigdy do takiego reala nie poszedłby ruch.
16