1 Wprowadzenie Czym jest i jak działa SureAliveD? Charakterystyka surealived Charakterystyka ipvssync... 4

Transkrypt

1 ver

2 Spis treści 1 Wprowadzenie Czym jest i jak działa SureAliveD? Charakterystyka surealived Charakterystyka ipvssync Instalacja Ze źródeł Uruchomienie Schemat działania Uruchamianie testera Uruchamianie synchronizatora Ogólne uwagi odnośnie uruchamiania Konfiguracja Głowny plik konfiguracyjny Zmienne konfiguracyjne surealived Zmienne konfiguracyjne ipvssync Wspólne zmienne konfiguracyjne Konfiguracja serwisów Ogólny zarys konfiguracji serwisów Tester HTTP Tester TCP Tester DNS Tester EXEC Pseudotester NO-TEST Interfejs CMD

3 1 Wprowadzenie Linux Virtual Server (LVS) jest jednym z najbardziej wydajnych serwerów balansowania ruchu. W środowiskach, gdzie istnieją setki (jak nie tysiące) usług wpiętych do LVS, prawdziwym wyzwaniem staje się ich przetestowanie i podjęcie właściwej akcji (wypięcie / wpięcie serwera). Problemem skalowania w tej materii jest także niewielki wybór aplikacji testujących, w szczegolności dla LVSów, gdzie wpiętych jest wiele serwerów a częstotliwość testu nie powinna być dłuższa niż kilka sekund. Takie założenie zdecydowanie ogranicza listę możliwych do zastosowania aplikacji, gdyż muszą one być oparte o multipleksowane IO (select/poll/epoll). Do tej pory jedyną aplikacją spełniającą te wymagania był keepalived. Ze względu na błędy i pewne braki funkcjonalne w keepalived zdecydowaliśmy się napisać od zera tester usług. Nazwaliśmy go dość przewrotnie SureAliveD, ze względu na to, iż chcemy być pewni, że wpięte do LVSa usługi działają. 1.1 Czym jest i jak działa SureAliveD? SureAliveD jest bardzo efektywnym testerem serwerów real wpiętych do LVSa. Zdecydowaliśmy się na odseparowanie warstwy testującej od modyfikującej zmiany w jądrze linuksa (w tablicy IPVS). Aplikację testującą dostępność reali nazwaliśmy surealived, natomiast synchronizator zmian w IPVS ipvssync. Podstawowym założeniem aplikacji było zastąpienie stosowanego do tej pory keepalived w części testującej. Keepalived świetnie sprawuje się tam, gdzie nie ma potrzeby częstego grzebania w konfiguracji. W dużych środowiskach, gdzie do LVSa wpięte są setki usług, problematyczna staje się każdorazowa konieczność przeładowania całości konfiguracji (nawet przy potrzebie zmiany wagi pojedynczego serwera). Przy częstym przeładowywaniu konfiguracji uwidaczniają się błędy 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 IPVS 1. 1 Istnieje owszem opcja uruchomienia keepalived z pozostawieniem starych wpisów, jednak od tego momentu przestaje się on interesować serwerami, których nie ma już w konfiguracji a pozostały w IPVS i zamiast usuwać pozostawia je nietknięte z uprzednio ustawioną wagą. 3

4 1.2 Charakterystyka surealived Oto podstawowe cechy testera surealived: oparty na epollu, posiada rozszerzalną XMLową konfigurację (rozparsowywalną przez moduł), testery usług są w rzeczywistości ładowanymi dynamicznie modułami daje to możliwość łatwego dodawania nowych testerów kolejnych usług, obecnie zaimplementowane moduły testujące protokół TCP, HTTP, DNS, exec (uruchomienie zewnętrznego testera) oraz no-test (traktowanie serwera jako dostępnego) ma wbudowaną przezroczystą obsługę SSL (wystarczy ustawić atrybut SSL= 1 przy konfiguracji testera). zapisuje statystyki połączeń do poszczególnych serwerów (czas połączenia i czas odpowiedzi), trzyma tablicę stanów serwerów, których test się nie powiódł, a także tablicę przesłaniającą bieżącą konfigurację (stan serwera oraz wagi), stany te są honorowane po restarcie, na starcie następuje zapisanie stanu dla ipvssync i wymuszenie synchronizacji konfiguracji z tablicą IPVS, komunikacja z ipvssync odbywa się 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 obciąż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 zarządzania (domyślnie 1337), umożliwiając 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ęcie niezarządzanych przez niego wirtuali z IPVS, w przypadku reali pełna synchronizacja odbywa się zawsze, możliwe jest sprawdzenie składni konfiguracji (parametr -t), restart aplikacji nie jest problemem, podobnie jak w przypadku restartu surealived następuje wymuszenie pełnej synchronizacji z IPVS, wymaga działania z użytkownika root. 4

5 2 Instalacja 2.1 Ze źródeł Do skompilowania potrzebne są następujące aplikacje i biblioteki 2 : 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 znajdują się następujące 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ę + instalację 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 pojawią się 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 są nazwami pakietów Debiana. 5

6 Ponadto zostają 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 surealived 3 oraz konfiguracji ipvssync 4, /var/lib/surealived/diffs z konfiguracją różnicową dla ipvssync, /var/lib/surealived/stats dla statystyk testów reali. 3 Pliki offline.dump oraz override.dump. 4 Plik ipvsfull.cfg, pliki z konfiguracją różnicową są w katalogu diffs. 6

7 3 Uruchomienie 3.1 Schemat działania Na poniższym diagramie przedstawiony jest schemat przepływu danych pomiędzy testerem a synchronizatorem. Po lewej stronie diagramu znajduje się tester (surealived), złożony z dwóch procesów watchdoga i testera. Po prawej stronie jest jednoprocesowy synchronizator (ipvssync) wpięty do IPVS synchronizer. Na środku diagramu umieszczone zostały pliki i katalogi biorące udział w wymianie danych między aplikacjami. Kluczowym plikiem wspólnym dla testera i synchronizatora jest surealived.cfg, którego składnia opisana jest w następnym rozdziale. Jest to prosty plik typu klucz wartość opisujący parametry działania obu aplikacji. Tester definicję usług do przetestowania bierze z pliku services.xml 5. Widok reali, ich wag i to czy są wpięte 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ę poprawnie przetestować. Dzięki temu po starcie podejrzane serwery nie są wpinane lub wpinane z wagą = 0 do IPVS. Plik, który również przesłania konfigurację to override.dump. Może być on modyfikowany przez użytkownika poprzez interfejs cmd widoczny po lewej stronie diagramu. Jest to wystawiony nasłuchujący port umożliwiający wykonanie kilku interesujących poleceń na działającym testerze. Co dokładnie można wykonać zostało opisane w następnym 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łającym serwerze nie zapisywać od razu całej konfiguracji a jedynie różnicę. Stąd też plik ipvsfull.cfg zmienia się co 60 sek. a wszelkie zmiany w stosunku do głównej konfiguracji są w ostatnim, bieżącym pliku różnicowym. Dwa bardzo ważne zbiory biorące w tym udział to plik muteksujący dostęp 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 nową konfigurację, wprowadza zmiany do IPVS po czym usuwa zbiór ipvsfull.reload. Podczas działania ipvssync wie w którym pliku różnicowym się 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 stats 6. 5 Oczywiście plik ten może się nazywać zupełnie inaczej, my założyliśmy, że jest to akurat services.xml. 6 Można zapiąć w cronie usuwanie lub w ogóle nie włączać zapisu do tych zbiorów poprzez ustawienie log_stats false w pliku surealived.cfg. 7

8 3.2 Uruchamianie testera Przed uruchomieniem synchronizatora po raz pierwszy, konieczne jest uruchomienie testera, związane jest to z utworzeniem konfiguracji ipvsfull.cfg By uzyskać listę możliwych opcji przy uruchamianiu testera wystarczy użyć opcji -h. wegorz@zaphod:~$ surealived -h === SureAliveD v === Usage: surealived [options] <xml_config_file> Ex : surealived -c /root/sd_new.conf -vv -d test_http.xml Options: --help -h This help info --test-config -t Test configuration and exit --config -c <path> Use <path> as config file --verbose -v Increase verbosity level --daemonize -d Run in background (daemonize) --no-sync -n Do not write sync info --no-dumpfile -k Do not load and create offline.dump --version -V Show Version information Bardzo użyteczną opcją jest -t, pozwalająca przetestować poprawność xmlowego pliku konfiguracyjnego serwisów. Standardowo kody wyjścia z programu oznaczają: 0 ok, różny od 0 błąd. W normalnym produkcyjnym środowisku zazwyczaj tester będzie uruchamiany jako demon: wegorz@zaphod:~$ surealived -d /etc/surealived/services.xml Należy pamiętać, że w przypadku uruchamiania testera jako demona wszelkie komunikaty o błędach pojawią się 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ę 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ę możliwych opcji przy uruchamianiu synchronizatora wystarczy użyć opcji -h. zaphod:~# ipvssync -h === IPVSSync v === Usage: ipvssync [options] Ex : ipvssync -c /home/surealived/surealived.cfg Options: --help -h This help info --test-config -t Test ipvsfull.cfg configuration and exit --config -c Config file (default /etc/surealived/surealived.cfg) --verbose -v Increase verbosity level --daemonize -d Run in background (daemonize) --del-umanaged -u Delete unmanaged virtuals from IPVS table --keep-diffs -k Don t remove processed diff files --version -V Show Version information 8

9 Zanim jednak uruchomimy synchronizator możemy przetestować poprawność pliku ipvsfull.cfg wykorzystując opcję -t. Standardowo kody wyjścia z programu oznaczają: 0 ok, różny od 0 błąd. Opcje które zmieniają 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ęc zostanie coś dodane z ręki do IPVS przy przeładowaniu konfiguracji synchronizator usunie to z tablicy. Druga wspomniana opcja wyłącza usuwanie plików różnicowych w katalogu diffs. 3.4 Ogólne uwagi odnośnie uruchamiania Obie aplikacje zaleca się uruchomić produkcyjnie z logowaniem typu info. W logach obu aplikacji pojawią się najbardziej użyteczne informacje związane z pracą zarówno testera jak i synchronizatora. W przypadku testowania konfiguracji najlepiej jest aplikacje uruchomić z parametrem -vvv, bez wprowadzenia ich w tryb demona. 9

10 4 Konfiguracja 4.1 Głowny plik konfiguracyjny Domyślnie główny plik konfiguracyjny surealived.cfg rezyduje w /etc/surealived. Zawiera on podstawową konfigurację 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ę uchronić przed dziwnymi błędami związanymi z tym, że oba programy będą miały różne wartości tych wspólnych zmiennych lepiej jest je zostawić w tym zbiorze Zmienne konfiguracyjne surealived Oto lista zmiennych wykorzystywanych przez tester: maxfd maksymalna ilość (domyślnie 1024) otwartych deskryptorów procesu 7. log ścieżka do logu lub stderr. Wartość ta jest nadpisywana na stderr jeśli program nie będzie uruchamiany w trybie demona. logging poziom szczegółowości logowania w kolejności rosnącej: 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ększa 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 mają być rozpoczęte (czasy startu testów będa rozłożone w tym okresie) (domyślnie: 1000) debug_comm flaga 0/1 określająca możliwość zrzucania przebiegu komunikacji z realami w danym wirtualu. Przełączenie jej na 1 jest warunkiem koniecznym (niewystarczającym) do zapisu komunikacji przez tester 8. debug_comm_path ścieżka, gdzie zapisywane będą zrzuty z komunikacji. memlimit limit pamięci 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ęcie/wypięcie (ON- LINE/OFFLINE/DOWN), domyślnie Jeśli uruchamiasz aplikację z roota sprawa jest prosta, w przeciwnym wypadku upewnij się, że użytkownik może przestawić tą wartość. 8 Należy jeszcze w konfiguracji xmlowej w tagu <tester> ustawić atrybut debugcomm= 1. 10

11 listen_port port interfejsu poleceń (cmd), domyślnie stats_dir ścieżka, gdzie zapisywane będą statystyki testów 9. log_stats ustawienie wartości na true spowoduje, że do stats_dir będą zapisywane statystyki testów w sposób indywidualny, tj <zbiór>.<timestamp> per test wirtuala 10. log_stats_combined wartość true oznacza, że do jednego zbioru będą dopisywane wszystkie statystyki testów 11. no_sync jeśli true nie będą tworzone pliki dla synchronizatora. use_offline_dump czy zapisywać stan reali, których nie udało się 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 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ędzie uruchamiany w trybie demona. ipvssync_logging poziom szczegółowości logowania w kolejności rosnącej: error, warn, info, debug, debdt. Wartość ta jest nadpisywana przez parametr -v Wspólne zmienne konfiguracyjne Oto lista zmiennych wykorzystywanych zarówno przez tester jak i synchronizator: lock_sync_file plik służący do synchronizacji pomiędzy 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ę wymusza przeładowanie konfiguracji synchronizatora. diff_sync_dir katalog, gdzie zapisywane będą pliki różnicowe (zawierające zmiany w stosunku do pełnego pliku konfiguracji). 9 Można je wykorzystać do analizy czasów odpowiedzi poszczególnych serwerów, zbalansowania wirtuali, itp. 10 Jeśli włączysz tą opcję zadbaj o czyszczenie katalogu ze starych zbiorów, gdyż bardzo szybko będziesz tam miał miliony zbiorów. 11 Zbiór można przycinać, gdyż aplikacja dopisuje na koniec (tworząc wcześniej zbiór jeśli nie istnieje). 11

12 4.2 Konfiguracja serwisów XMLowy plik konfigurujący testowane przez surealived serwisy jest jego argumentem w momencie uruchomienia. Może się więc znajdować w dowolnym miejscu, załóżmy więc, że konfiguracja ta jest w pliku /etc/surealived/services.xml Ogólny zarys konfiguracji serwisów Plik konfigurujący serwisy ma składnię 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ędzie użyty adres ], 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łączeń persistent to jest wartość timeoutu. Atrybuty taga <tester>: loopdelay= int [opcjonalny, domyślnie 3] określa opóźnienie w sekundach pomiędzy pętlami testującymi 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ę powieść by real był potraktowany jako online, retries2fail= int [opcjonalny, domyślnie 1] ile testów musi się zakończyć niepowodzeniem by real był potraktowany jako offline, 12

13 remove_on_fail= 0 1 [opcjonalnie, domyślnie 0 (fałsz)] jeśli prawda real będący offline jest usuwany z IPVS, logmicro= 0 1 [opcjonalny, domyślnie 0 (fałsz)] zapisywać statystyki z mikrosekundową dokładnością 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ć tą 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łączeń reala w IPVS, lthresh= int [opcjonalny, domyślnie 0 (brak limitu)] dolny limit połączeń reala w IPVS, testport= int16 [opcjonalny] nadpisuje atrybut testera testport dla danego reala, rt= string [opcjonalny] nadpisuje atrybut testera rt dla danego reala Tester HTTP Gdy chcemy użyć testera HTTP do przetestowania konkretnego reala, należy ustawić proto= http w tagu tester oraz atrybuty: url= string [obligatoryjny, max 4095 znaków] określający odpytywany obiekt na serwerze, host= string [obligatoryjny, max 255 znaków] określa nagłowek Host, retcode= string [opcjonalny, domyślnie 200 ] kod powrotu określający, że test się powiódł, naive= True False [opcjonalny, domyślnie False (fałsz) określa czy należy sciągać obiekt do końca, czy wystarczy otrzymać kod powrotu. Przykładowy plik XML: <surealived> <virtual name="onet" addr=" " port="80" proto="tcp" sched="wrr" rt="dr"> <tester loopdelay="1" timeout="2" retries2fail="1" retries2ok="1" proto="http" testport="80" url="/" host=" <real name="sg" addr=" " port="80" weight="10"/> </virtual> </surealived> 13

14 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=" " 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=" " port="22" weight="10"/> </virtual> </surealived> Tester DNS Tester UDP sprawdzący 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ę dla której tester odpyta o SOA. Przykładowy plik XML: <surealived> <virtual name="onetdns1" addr=" " 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=" " port="53" weight="10"/> <real name="dns2" addr=" " port="53" weight="11"/> </virtual> </surealived> Tester EXEC Tester który wywołuje dowolny zewnętrzny 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 jaką wywoływany jest program to: arg0 adres IP reala, arg1 port (testport) dla reala, arg2 params[0], arg. params[...], argn params[n]. 14

15 Oczywiście jeśli nie zostanie podany atrybut params aplikacja testująca zostanie wywołana tylko z dwoma argumentami. Kod powrotu == 0 oznacza, że test się powiódł. Dowolny inny kod powrotu traktowany jest jako błąd testu. Przykładowy plik XML: <surealived> <virtual name="onetexec" proto="tcp" addr=" " 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=" /0" /> <real name="sg" addr=" " port="80" weight="10" rt="dr"/> </virtual> </surealived> Pseudotester NO-TEST Pseudotester traktujący serwer jako zawsze online. Wymaga proto= no-test w tagu tester. Przykładowy plik XML: <surealived> <virtual name="onet" addr=" " 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=" " 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 ( ) i porcie 1337 nasłuchuje interfejs cmd. Obecnie można wykonać następujące akcje: vlist [pasywny] wylistowuje wirtuale zdefiniowane w pamięci testera, rlist [pasywny] wylistowuje reale zdefiniowane dla konkretnego wirtuala w pamięci testera, stats [pasywny] pokazuje statystyki działania aplikacji, ilość zdefioniowanych wirtuali, reali i wiele innych, rset [aktywny] umożliwia dynamiczne zarządzanie wagami oraz ustawiania serwera w stan OF- FLINE (waga = 0) lub DOWN (serwer jest usuwany z IPVS). Przykłady: > printf "vlist\n" nc -q 1 localhost vname=onet vproto=tcp vaddr= vport=80 vfwmark=0 vrt=dr vsched=wrr 1. vname=wp vproto=tcp vaddr= vport=80 vfwmark=0 vrt=dr vsched=wrr > printf "rlist vproto=tcp vaddr= vport=80\n" nc -q 1 localhost raddr= rport=80 currwgt=11 confwgt=11 ronline=true rstate=online > printf "rset vproto=tcp vaddr= vport=80 raddr= rport=80 rweight=1\%\%\n" \ nc -q 1 localhost

16 Set: rstate=online, weight=1, inpercent=true > printf "rset vproto=tcp vaddr= vport=80 raddr= rport=80 rstate=offline\n" \ nc -q 1 localhost 1337 Set: rstate=offline, weight=-1, inpercent=false > printf "rlist vproto=tcp vaddr= vport=80\n" nc -q 1 localhost raddr= rport=80 currwgt=0 confwgt=11 ronline=true rstate=offline > printf "stats\n" nc -q 1 localhost statistics here... Polecenie aktywne rset umożliwia zmianę wagi również jako procent domyślnie skonfigurowanej wartości. Trzeba pamiętać, że dla 1% zostanie ustawiona waga minimum równa Wszelkie zmiany modyfikowane z wykorzystaniem cmd zapisywane są w pliku override.dump. Takie podejście umożliwia przetrwanie nadpisanych przez nas ustawień w przypadku modyfikacji konfiguracji xml lub zrestartowaniu surealived. 12 Zakładając, że wagi są ustawiane w zależności od wypełnienia cache, przy wadze ustawionej na 10 i pustym cache 1% zawsze równałby się 0 i nigdy do takiego reala nie poszedłby ruch. 16