LVS – Linux virtual server

Linux Virtual Server (LVS) este o solutie avansata de distributie a sarcinii (load balancing) pentru sistemele Linux. Este un proiect open source initiat de Wensong Zhang in mai 1998. Scopul de baza al proiectului Linux Virtual Server este acela de a construi un server de linux de inalta performanta si disponibilitate folosind arhitectura de tip cluster, care sa asigure scalabilitate si fiabilitate ridicate. Sistemul de cluster LVS este cunoscut si sub numele de load balancing server cluster.

Obiectivele LVS

Obiectivul major al momentului este dezvoltarea unei solutii software de distributie a incarcarii la nivel IP (IPVS), precum si a unei solutii software de distributie a incarcarii la nivel aplicatie (KTCPVS), si de administrare a componentelor cluster-ului.
• IPVS: este o solutie software avansata de distributie a incarcarii la nivel IP implementata in interiorul kernel-ului Linux. Codul IPVS este inclus deja in kernel-ele Linux standard 2.4 si 2.6.
• KTCPVS: software de distributie a incarcarii la nivel aplicatie, in lucru in acest moment.
Utilizatorii pot folosi solutia LVS pentru a oferi servicii scalabile de retea, precum serviciile web, servicii e-mail, servicii media si servicii VoIP, si pentru a integra servicii de retea scalabile in servicii extrem de stabile de tip aplicatii e-commerce sau e-government.

Arhitectura serverului este transparenta pentru utilizatorii finali, acestia interactionand cu clusterul ca si cum ar fi un server virtual de inalta-performanta.

Pentru figura 1, serverele reale si serverele de load balancer pot fi interconectate printr-o retea LAN de mare viteza sau printr-o retea WAN dispersata geografic. Serverele de load balancer pot trimite cereri la diferite servere si pot face ca serviciile paralele ale cluster-ului sa apara ca un serviciu virtual pe o singura adresa IP, iar pentru transmiterea cererilor poate folosi tehnologie de load balancing la nivel de IP sau tehnologii de load balancing la nivel de aplicatie. Scalabilitatea sistemului este atinsa prin adaugarea sau eliminarea transparenta a nodurilor in cluster. Inalta disponibilitate este asigurata prin detectarea nodurilor sau a daemon-urilor care nu functioneaza si reconfigurarea corespunzatoare a sistemului.

Figura 1. Serverul virtual

Solutiile LVS sunt folosite deja practic in multe aplicati reale din intreaga lume.

Motivarea folosirii serverelor virtuale

Odata cu cresterea exploziva a internetului si a rolului din ce in ce mai important in viata de zi cu zi, traficul pe internet a crescut si el considerabil, crescand cu peste 100% anual. Gradul de solicitare al serverelor este in crestere rapida, astfel incat supraincarcarea acestora pentru o perioada scurta de timp va putea fi produsa cu usurinta, mai ales pentru site-urile populare. Pentru a depasi problema impusa de supraincararea serverelor, exista doua solutii.

O prima solutie se refera la existenta unui singur server, adica serverul existent sa fie upgradat la un server care sa asigure performante mai mari, dar la care problema de supraincarcare va aparea in scurt timp, atunci cand cererile catre server vor creste si deci va fi nevoie de un nou upgrade si deci costuri suplimentare. A doua solutie implica servere multiple, adica de a construi un sistem scalabil de servicii de retea pe un cluster de servere. Atunci cand sarcina creste, unul sau mai multe servere poate fi adaugat la cluste pentru a satisface cererile in crestere. Prin urmare, este o solutie mai scalabila si mai eficienta din punctul de vedere al costurilor construirea unui sistem scalabil de servicii de retea pe un cluster de servere

Exista mai multe metode de construire a clusterului de servere.

Cluster de load balancing bazat pe DNS

Aceasta este probabil cea mai simpla metoda de construire a unui sistem de servicii bazat pe un cluster. Utilizeaza DNS-ul pentru a distribui cererile catre diverse servere prin asocierea numelui de domeniu diferitelor adrese IP. Cand o cerere DNS ajunge la serverul de DNS, acesta returneaza adresa IP corespunsatoare DNS-ului primit (de exemplu folosind modul round-robin), apoi cererile succesive de la clienti care au acelasi DNS sunt trimise la acelasi server.

Cu toate acestea, datorita sistemului de caching intalnit la nivelul utilizatorului si a caracterului ierahizat al sistemului de DNS, se poate ajunge cu usurinta la un dezechilibru de incarcare dinamica a serverelor, prin urmare nu este usor pentru un server de a manipula incarcatura maxima. Valoarea TTL (time-to-live) a unui nume mapat nu poate fi aleasa corect pentru un server DNS – algand o valoare mica, traficul DNS-ului este mare iar serverul de DNS va fi „gatuit”, iar cu o valoare mare a TTL-ului, dezechilibrul incarcarii dinamice a serverului va fi si mai mare.

Chiar daca valoarea TTL este setata la 0, modelul de acces al diferitilor utilizatori poate duce la dezechilibru in incarcarea serverelor, deoarece unii useri pot incarca mai multe pagini ale unui site pe cand altii pot incarca decat cateva pagini ca apoi sa paraseasca site-ul. Mai mult, nu este asigurata fiabilitatea, atunci cand un nod al serverului nu mai functioneaza, clientul care mapeaza DNS-ul la adresa IP a serverului va primi ca raspuns ca serverul este nefunctional iar problema va persista chiar daca utilizatorul va apasa butonul de „refresh” al browserului.

Cluster de load balancing bazat pe dispecer

Dispecerul, cunoscut ca si load balancer, poate fi folosit pentru a distribui sarcina intre serverele din cadrul unui cluster, astfel incat servicii paralele ale serverelor pot aparea ca un singur serviciu virtual pe o singura adresa IP, utilizatorul final avand impresia ca interactioneaza cu un singur server, fara a avea idee de toate serverele din cadrul clusterului.

In comparatie cu prima metoda, dispecerul poate programa solicitarile, asigurand o granularitate ridicata pentru un mai bun echilibru intre servere. Nefunctionarea unuia sau mai multor server poate fi cu usurinta mascata. Managementul serverelor se simplifica, iar administratorul poate deconecta de la sistem unul sau mai multe servere la orice moment de timp fara a afecta activitatea userilor.

Distributia sarcinii poate fi realizata in doua feluri, la nivel de IP si la nivel de aplicatie. De exemplu, Reverse-proxy si pWEB este o metoda de distributie a sarcinii la nivel de aplicatie utilizata in construirea serverelor web scalabile. Cererile HTTP sunt transmise catre diferite servere din cluster, acestea returneaza rezultatul, ca apoi rezultatul final sa fie returnat utilizatorului.

Principiile de functionare ale unui LVS

Serverele virtuale sunt implementate in trei moduri. Exista trei tehnici de distrbutie a sarcinii bazate pe IP existente in LinuxDirector. Acestea sunt: servere virtuale via NAT, servere virtuale via IP tunneling si servere virtuale realizate prin rutare directa.

Server virtual via NAT

Avantajul unui astfel de server virtual este acela ca serverele pot avea orice sistem de operare care sa suporte protocolul TCP/IP, serverele reale pot folosi adrese de internet private si numai o singura adresa de IP este necesara pentru distributia sarcinii.

Dezavantajul unui astfel de server este legat de scalabilitatea limitata. Load balancer-ul poate duce la „gatuirea” intregului sistem atunci cand numarul de noduri server ajunge in jurul valorii de 20, deoarece atat pachetele de cerere cat si pachetele de raspuns trebuiesc rescrise de load balancer. Presupunand ca lungimea medie a pachetelor TCP este de 536 Bytes, intarzierea medie pentru rescrierea unui pachet poate ajunge la 60 us, capacitatea maxima a load balancer-ului fiind de 8.93 Mbytes/s. Presupunand ca viteza unui server real este de 400 kbytes/s, load balancer-ul poate programa maxim 22 de servere reale.

Modul de functionare: cand un utilizator acceseaza serviciul virtual oferit de cluster, pachetul corespunzator cererii ajunge la load balancer. Acesta examineaza adresa de destinatie a pachetului si portul. Daca acestea corespund unui serviciu oferit de un server real conform tabelei de rutare, un server este ales din cluster prin intermediul unui algoritm iar conexiunea este adaugata tabelei hash care retina conexiunile stabilite. In acest caz, adresa destinatiei si portul pachetului sunt rescrise pentru a corespunde serverului ales iar pachetul este transmis mai departe.

Atunci cand pachetele cu raspunsurile ajung la load balancer, acesta rescrie adresa si portul pachetelor pentru a corespunde cu cele ale serviciului virtual. Dupa ce conexiunea expira sau a fost inchisa, inregistrarea legata de conexiunea este stearsa din tabele de hash.
Serverul virtual via NAT poate satisface cererile de performanta a multor servere. Chiar si atunci cand load balancer-ul devine sursa de „gatuire” a intregului sistem, exista doua metode de rezolvare a problemei: o solutie se refera la abordarea hibrida, iar cea de-a doua se refera la server virtual via IP tunneling sau server virtual bazat pe rutarea directa.

Server virtual via IP tunneling

In cazul primului tip de server virtual, cererile si raspunsurile trebuiau sa treaca prin load balancer, acesta putand cauza o „gatuire” a sistemului atunci cand numarul de noduri depaseste valoarea de 20, deoarece tranzitul prin interfata de retea este limitat. Se poate observa la multe servicii de internet (cum sunt serviciile web), pachetele de cereri sunt de obicei mici pe cand pachetele de raspuns de obicei contin cantitati mari de informatie.
In cadrul unui server virtual via IP tunneling, load balancerul distribuie cererile catre diferite servere reale, iar acestea transmit raspunsurile direct catre userul final. Deci, load balancer-ul poate manipula multe solicitari, poate programa peste 100 de servere reale, iar situatia de „gatuire” nu va fi intalnita in acest caz.

Utilizand aceasta metoda numarul maxim de servere nod va creste considerabil pentru un load balancer. Capacitatea maxima a unui server virtual poate ajunge la peste 1Gbps, chiar daca load balancerul are decat un adaptor de retea de 100 Mbps full duplex.

Caracteristicile tunelurilor IP pot fi folosite pentru a construi un server virtual de inalta performanta. Este recomandata construirea unui server proxy virtual, deoarece atunci cand serverul proxy primeste solicitarea, poate accesa direct internetul pentru a cauta obiectele si pentru a le returna direct utilizatorilor. Totusi, toate serverele trebuie sa aiba protocolul de encapsulare IP activat.

Server virtual bazat pe rutarea directa

Asemanator serverelor virtuale construite pe baza tunelurilor IP, LinuxDirector proceseaza numai partea client-server a unei conexiuni din cadrul serverului virtual bazat pe rutarea directa, iar pachetele ce contin raspunsul la solicitari pot ajunge la utilizatori pe diferite rute de retele. Acest lucru poate creste foarte mult scalabilitatea unui server virtual.

In comparatie cu serverul virtual bazat pe tunelurile IP, la aceasta abordare nu se va mai intalni „tunneling overhead” ( de fapt, efortul va fi minimal in majoritatea situatiilor), dar este necesar ca una din interfetele load balancer-ului si una din interfetele fiecarui server real sa fie in acelasi segment fizic (retea).

Arhitectura clusterelor LVS

Pentru transparenta, scalabilitate si disponibilitate a intregului sistem, am abordat in acest proiect arhitectura pe 3 niveluri in cadrul unui cluster LVS, ca in figura 2.

Aceasta arhitectura pe trei niveluri consta din:
• Load balancer (distribuitor de sarcina) – este partea de front-end al intregului cluster, care distribuie solicitarile de la clienti catre un set de servere, astfel incat clientii au impresia ca toate serviciile sunt asigurate de o singura adresa IP.
• Serverele cluster-ului – reprezentate printr-un set de servere reale pe care ruleaza servicii de retea, cum ar fi: internet, mail, FTP, DNS si servicii media.
• Storage-ul comun – care asigura un spatiu de stocare comun pentru toate serverele, astfel incat este destul de usor pentru servere sa aiba acelasi continut si sa ofere aceleasi servicii.

Figura 2. Arhitectura generala a unui LVS

Load balancer-ul este singurul punct de intrare in cluster, poate rula IPVS, care implementeaza tehnici de load balancing bazate pe IP in interiorul kernelului de linux, sau KTCPVS, care implementeaza tehnici de load balancing la nivel de aplicatie in interiorul kernelului de linux. Cand IPVS este utilizat, toate serverele cluster-ului sunt obligate sa ofere aceleasi servicii si acelasi continut, load balancer-ul directioneaza clientii noi catre un server in functie de algoritmii de distribuire a solicitarilor si in functie de gradul de ocupare al fiecarui server.

Indiferent de care server este ales, clientul trebuie sa primeasca acelasi rezultat. Atunci cand metoda KTCPVS este utilizata, serverele pot avea continut diferit, load balancer-ul poate directiona o solicitare catre un server in functie de continutul solicitarii. Din moment ce KTCPVS este implementat in interiorul kernelului de linux, varful de realocari de date este minim, astfel incat el sa poata avea in continuare un grad ridicat de tranzitare.

Codul IPVS ruleaza pe directorul LVS. Acest director:
• este un switch de nivel 4. In retea el este vazut ca un router ale carui reguli sunt putin diferite de cele ale unui router obisnuit;
• directorul primeste cererea de conectare de la un client si alege unul dintre serverele reale pentru a servi clientul;
• serverele reale pot oferi oricare dintre serviciile oferite de un server pe internet;
• servere reale individuale pot fi adaugate sau eliminate ulterior din LVS, fara ca utilizatorii sa fie constienti de modificare, prin comenzi date directorului. Acest lucru permite serverelor reale sa poata fi indisponibile pentru realizarea de mentenanta sau imbunatatiri sau chiar in cazul defectarii.

Numarul nodurilor server din cadrul clusterului poate varia in functie de sarcina primita de sistem. Atunci cand toate serverele sunt supraincarcate, servere suplimentare pot fi adaugate pentru a manipula fluxul crescut de cereri. Pentru majoritatea serviciilor de internet, de obicei cererile nu sunt strans legate si ca urmare ele pot fi rulate in paralel pe diferite servere. Prin urmare, crescand numarul de noduri server din cadrul unui cluster, performantele intregului sistem cresc liniar.

Storage-ul comun poate fi reprezentat prin sisteme de baze de date, sisteme locale de fisiere sau sisteme distribuite de fisiere. Informatia care trebuie actualizata in mod dinamic de nodurile server trebuie stocata in baze de date, unde nodurile citesc sau scriu datele paralel, baza de date asigurand consistenta in cazul accesului concurent la informatiile stocate. Informatiile statice de obicei sunt stocate in sisteme locale de fisiere cum sunt NFS sau CIFS, astfel incat datele sa poata fi share-uite de toate nodurile. Totusi, scalabilitatea unui singur network file system este limitata, de exemplu un singur NFS/CIFS poate suporta accesul a 4 pana la 8 servere.

Load balancer-ul, serverele clusterului si sistemul de storage sunt de obicei conectate prin retele de mare viteza, cum ar fi retele Ethernet de 100Mbps sau Gigabit Ethernet, astfel incat reteaua sa nu devina cauza de „gatuire” a intregului sistem, atunci cand acesta e in crestere.

Inalta disponibilitate

Pe masura ce din ce in ce mai multe aplicatii critice sunt puse pe internet, asigurarea disponibilitatii serviciilor devine din ce in ce mai importanta. Unul dintre avantajele unui sistem bazat pe clustere este acela ca dispune de redundanta atat software cat si hardware deoarece sistemul de cluster este alcatuit dintr-un numar de noduri independente, iar fiecare nod dispune de o copie a sistemului de operare si a aplicatiei software. Inalta disponibilitate poate fi asigurata prin detectarea nodurilor sau daemon-urilor nefunctionali si prin reconfigurarea corespunzatoare a sistemului, astfel incat sarcinile sa fie preluate de restul nodurilor din cluster.

De fapt, inalta disponibilitate defineste un domeniu vast. Un sistem avansat de asigurare a disponibilitatii poate dispune de sisteme de comunicatie intre sub-sisteme, managementul membrilor sistemului, sub-sisteme de control concurente s.a.m.d.

Principiul de functionare al unui LVS

In mod normal, pe load balancer ruleaza daemoni pentru monitorizarea serviciilor prin care se verifica periodic starea sistemului, asa cum este afisat in figura 3.
Load balancerul poate deveni single point of failure al intregului sistem. Pentru a preveni ca intregul sistem sa devina indisponibil din cauza load balancer-ului nefunctional, este necesar setarea unuia sau mai multor backup-uri a load balancer-ului. Doi daemoni heartbeat ruleaza pe load balancer-ul primar si respectiv pe cei de backup, transmitand mesaje de genul „i’m alive” intre ei serial sau pe retea in mod periodic.

Atunci cand daemon-ul de heartbeat al backup-ului nu primeste mesaj de la load balancer-ul primar in timpul specificat, va prelua adresa de IP virtuala pentru a asigura serviciul de load balancing al sistemului. Atunci cand load balancer-ul primar reintra in functiune, exista doua solutii: fie devine backup-ul celui care este functional, fie load balancer-ul activ elibereaza adresa IP virtuala, devenind din nou backup-ul celui primar.

Figura 3. Inalta disponibilitate a sistemelor LVS

Load balancerul primar retine informatiile legate de conexiunile existente si care spune carui server sa ii fie transmisa cererea. Daca load balancer-ul de backup preia controlul fara aceste informatii de conectare, clientii sunt nevoiti sa retransmita solicitarile pentru a avea acces la servicii. Pentru a face transparenta nefunctionarea load balancer-ului, este implementata in IPVS functia de sincronizare a conexiunii, astfel incat load balancer-ul primar al IPVS-ului sincronizeaza informatiile conexiunilor existente cu load balancer-ul de backup prin intermediul comunicarii UDP multicast. Atunci cand load balancer-ul de backup preia controlul in cazul nefunctionarii load balancer-ului primar, acesta va avea starea majoritatii conexiunilor, astfel incat acestea sa poata continua sa acceseze serviciile oferite de cluster prin intermesiul load balancer-ului de backup.

Exemple functionale Linux Virtual Server

Exista mai multe pachete de software in conjuctie cu LVS pentru a oferi o disponibilitate ridicata a intregului sistem, cum ar fi Red Hat Piranha, Keepalived, UltraMonkey s.a.m.d. Exemplul prezentat in acest proiect se refera la utilizarea tool-ului Pirahna pentru a construi un sistem LVS de inalta disponibilitate.

UltraMonkey este unul din produsele software cu ajutorul carora se pot construi servicii de retea echilibrate din punctul de vedere al sarcinii si de inalta disponibilitate. UltraMonkey utilizeaza sistemul de operare linux pentru a asigura solutii flexibile care pot fi customizate pentru o gama larga de nevoi: de la clustere de dimensiuni mici formate din numai doua noduri la sisteme largi care deservesc mii de conexiuni pe secunda.

Exemplu de configurare

Folosind tool-ul UltraMonkey pentru a construi un cluster web NAT de inalta disponibilitate cu doua load balancer-uri si trei servere web. Topologia este ilustrata in figura 3. In acest exemplu, adresa IP virtuala si adresa IP de gateway sunt 10.23.8.80 respectiv 172.18.1.254, fiind folosite de cele doua load balancer-uri, iar adresele IP a celor trei servere reale sunt 172.18.1.11, 172.18.1.12 si 172.18.1.13.

Figura 4. Topologia LSV considerat

Fisierul de configurare a Pirahna este acelasi pentru cele doua load balancer-uri si anume:
/etc/ha.d/ha.cf:
logfacility local0
keepalive 2
deadtime 10
warntime 10
initdead 10
nice_failback on
udpport 694
bcast eth1
node ld1
node ld2
/etc/ha.d/haresources:
ld1 IPaddr::10.23.8.80/24/eth1 IPaddr::172.18.1.254/24/\
eth1 ldirectord::ldirectord.cf
/etc/ha.d/ldirectord.cf:
checktimeout=10
checkinterval=2
autoreload=no
logfile=”local0″
quiescent=yes

# serviciu virtual pentru HTTP
virtual=10.23.8.80:80
fallback=127.0.0.1:80
real=172.18.1.11:80 masq
real=172.18.1.12:80 masq
real=172.18.1.13:80 masq
service=http
request=”index.html”
receive=”Test Page”
scheduler=wlc
persistent=600
protocol=tcp
checktype=negotiate

Se seteaza permisiunile in fisierul authkeys: chmod 600 /etc/ha.d/authkeys. Se porneste serverul httpd: httpd -k start si se creaza fisierul index.html in folderul /var/www/html cu textul dorit.