Differences
This shows you the differences between two versions of the page.
|
saisp:labs:05:contents:01 [2014/03/02 17:43] alexandru.carp [Linux Virtual Server] |
saisp:labs:05:contents:01 [2014/04/04 11:38] (current) razvan.deaconescu [01. [20p] LVS-DR (direct routing)] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ==== Linux Virtual Server ==== | + | ==== 01. [20p] LVS-DR (direct routing) ==== |
| - | [[http://www.linuxvirtualserver.org/|Linux Virtual Server]] (LVS) este o soluție avansată de load balancing. Este open source, integrat în kernel-ul Linux. | + | Serviciul pentru care vom face load-balancing este **HTTP**. Serverul de web Apache2 este deja instalat pe realservere. Directorul va imparti cererile venite din partea clientului catre cele 2 realservere. |
| - | Mașina care face load balancing se numește, în [[http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.introduction.html#nomenclature|terminologia]] LVS, //virtual server// (VS), iar serverele reale, care oferă servicii, se numesc //real servers// (RS). Un client accesează serviciul exclusiv pe baza adresei virtual server-ului. | + | Pe director este deja instalat pachetul ''ipvsadm'' necesar configurării load balancing-ului. |
| - | LVS are 3 [[http://www.linuxvirtualserver.org/how.html|moduri de funcționare]]: | + | Mai intai vom configura adresa virtuala pe director. Adaugam adresa **10.0.0.1/24** pe subinterfata **eth0:1** de pe **saisp-vm-1**: |
| - | * **LVS-NAT** -- VS face NAT pentru RS-uri. Util când RS-urile nu au adresă publică și când sunt în aceeași rețea. Scalează slab, pentru că tot traficul trece prin VS. | + | <code> |
| - | * **LVS-TUN** -- VS face tunelare pentru pachetele care vin de la client, iar RS-urile răspund direct clientului. Scalează mai bine, pentru că doar traficul dintr-un singur sens (cererile) trece prin VS, dar necesită suport pentru tunelare pe RS-uri. | + | root@saisp-vm-1:~# ip addr add dev eth0 10.0.0.1/24 label eth0:1 |
| - | * **LVS-DR** (Direct Routing) -- VS rutează pachetele către RS-uri fără tunelare. RS-urile răspund direct clientului. Elimină necesitatea suportului pentru tunelare, dar trebuie ca VS-ul și fiecare RS să aibă cate o interfața în același segment de rețea. În plus, trebuie ca RS-urile să poată răspunde la cereri adresate VS-ului, pentru că nu se suprascriu adresele destinație ale request-urilor. | + | </code> |
| - | ===== Topologie ===== | + | Vom configura HTTP ca serviciu virtual. Trebuie să specificăm adresa si portul serverului virtual și protocolul de nivel transport (TCP, în cazul nostru). |
| + | <code> | ||
| + | root@saisp-vm-1:~# ipvsadm -A -t 10.0.0.1:80 | ||
| + | </code> | ||
| - | Masinile din topologie (3 masini virtuale KVM si masina fizica) au urmatoarele roluri: | + | Serviciul virtual a fost configurat, dar trebuie să adăugăm și servere reale: |
| - | * masina **saisp-vm-1** are rol de **director (Virtual Server)**, facand load-balancing pentru saisp-vm-2 si saisp-vm-3; | + | <code> |
| - | * masinile **saisp-vm-2** si **saisp-vm-3** au rol de realservere; | + | root@saisp-vm-1:~# ipvsadm -a -t 10.0.0.1:80 -r 10.0.0.20:80 -g |
| - | * masina **fizica** are rol de client; | + | root@saisp-vm-1:~# ipvsadm -a -t 10.0.0.1:80 -r 10.0.0.30:80 -g |
| + | </code> | ||
| + | Parametrul **-g** semnifică folosirea LVS-DR. | ||
| + | |||
| + | Trebuie, de asemenea, să "convingem" RS-urile să răspundă la cereri pe adresa VS-ului. Există cel puțin două posibilități pentru acest lucru: | ||
| + | * configurarea adresei VS pe o interfață de loopback a RS. Această metodă are neajunsul că un RS ar putea răspunde unei cereri ARP pentru VS. Problema astfel creată se numește, în LVS, //[[http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.arp_problem.html|The ARP Problem]]//. | ||
| + | * utilizarea unei reguli iptables care face RS-ul să accepte pachete, chiar dacă adresa VS-ului nu este configurată pe nicio interfață. **Vom folosi această abordare**. | ||
| + | <code> | ||
| + | root@saisp-vm-2:~# iptables -t nat -A PREROUTING -d 10.0.0.1 -j REDIRECT | ||
| + | </code> | ||
| + | <code> | ||
| + | root@saisp-vm-3:~# iptables -t nat -A PREROUTING -d 10.0.0.1 -j REDIRECT | ||
| + | </code> | ||
| + | |||
| + | Acum puteți utiliza serviciul configurat. | ||
| + | |||
| + | Verificati functionarea deschizand in browser adresa http://10.0.0.1 Folosind **CTRL+F5**, faceti refresh de cateva ori si observati cum apar, pe rand, paginile de pe cele 2 realservere. | ||
| + | |||
| + | Folosind Wireshark, porniti o captura pe interfata **br0** de pe masina fizica. Observati adresele IP si MAC din: | ||
| + | * pachetele care circula de la client spre director; | ||
| + | * pachetele care circula de la director spre realservere; | ||
| + | * pachetele care se intorc de la realservere catre client. | ||
| + | |||
| + | Pentru a vizualiza starea VS-ului, folositi parametrul **-l**: | ||
| + | <code> | ||
| + | root@saisp-vm-1:~# ipvsadm -l | ||
| + | </code> | ||
| + | |||
| + | Pentru a afisa detalii despre conexiunile gestionate de VS, adaugati si parametrul **-c**: | ||
| + | <code> | ||
| + | root@saisp-vm-1:~# ipvsadm -l -c | ||
| + | </code> | ||
| + | |||
| + | Pe langa configuratia de baza pe care am realizat-o, putem seta parametri aditionali. | ||
| + | |||
| + | De exemplu, vom activa scheduler-ul de tip round-robin, apoi vom configura un maxim de 4 conexiuni simultane pentru fiecare RS: | ||
| + | <code> | ||
| + | root@saisp-vm-1:~# ipvsadm -E -t 10.0.0.1:80 -s rr | ||
| + | root@saisp-vm-1:~# ipvsadm -e -t 10.0.0.1:80 -r 10.0.0.20:80 -x 4 | ||
| + | root@saisp-vm-1:~# ipvsadm -e -t 10.0.0.1:80 -r 10.0.0.30:80 -x 4 | ||
| + | </code> | ||
| + | |||
| + | Parametrul **-E** desemneaza editarea serviciului (in cazul nostru, s-a modificat scheduler-ul). | ||
| + | |||
| + | Parametrul **-e** desemneaza editarea realserverului (in cazul nostru, s-a modificat limita maxima de conexiuni). | ||
| + | |||
| + | In browser, faceti refresh de cateva ori si observati cum dupa 8 refresh-uri, directorul nu va mai trimite cererile catre realservere. | ||
| + | |||
| + | Pentru RS-uri cu configurație hardware diferită, se pot folosi valori diferite ale numărului maxim de conexiuni. Alternativ, se poate defini o pondere (weight) diferită pentru fiecare server și se poate folosi un scheduler ponderat (de exemplu, wrr) pe VS. | ||
| + | |||
| + | Pentru a sterge serviciul definit, folosim parametrul **-D**: | ||
| + | <code> | ||
| + | root@saisp-vm-1:~# ipvsadm -D -t 10.0.0.1:80 | ||
| + | </code> | ||
| + | |||
| + | In plus, pe realservere vom sterge regulile iptables definite: | ||
| + | <code> | ||
| + | root@saisp-vm-2:~# iptables -t nat -F | ||
| + | </code> | ||
| + | <code> | ||
| + | root@saisp-vm-3:~# iptables -t nat -F | ||
| + | </code> | ||
