Differences

This shows you the differences between two versions of the page.

Link to this comparison view

saisp:labs:05:contents:02 [2014/03/02 18:42]
alexandru.carp
saisp:labs:05:contents:02 [2014/03/23 21:48] (current)
Line 1: Line 1:
-==== 01. LVS-DR (direct routing) ====+==== 02[20p] LVS-TUN (tunneling) ====
  
-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.+In continuare, ​vom configura directorul pentru a folosi modul LVS-TUNApoi, vom observa diferentele fata de LVS-DR.
  
-Mai intai vom configura adresa virtuala ​pe director. ​Adaugam adresa **10.0.0.1/​24** pe subinterfata **eth0:1** de pe **saisp-vm-1**:​ +Analog punctului anterior, definiti serviciul HTTP pe director, apoi cele doua realservere in modul tunneling (folositi parametrul ''​-i''​)
-<code> +<solution ​-hidden>
-root@saisp-vm-1:~# ip addr add dev eth0 10.0.0.1/24 label eth0:1 +
-</code> +
- +
-Vom configura HTTP ca serviciu virtual. Trebuie să specificăm adresa si portul server-ului virtual și protocolul de nivel transport (TCP, în cazul nostru):+
 <​code>​ <​code>​
 root@saisp-vm-1:​~#​ ipvsadm -A -t 10.0.0.1:80 root@saisp-vm-1:​~#​ ipvsadm -A -t 10.0.0.1:80
 +root@saisp-vm-1:​~#​ ipvsadm -a -t 10.0.0.1:80 -r 10.0.0.20:​80 -i
 +root@saisp-vm-1:​~#​ ipvsadm -a -t 10.0.0.1:80 -r 10.0.0.30:​80 -i
 </​code>​ </​code>​
 +</​solution>​
  
-Serviciul virtual a fost configuratdar trebuie ​să adăugăm și servere reale: +Pentru ca realserverele sa poata interpreta corect pachetele primite de la director, trebuie ​sa configuram cate o interfata tunel, de tip **ipip**, pe fiecare dintre acestea.
-<​code>​ +
-root@saisp-vm-1:​~#​ ipvsadm -a -t 10.0.0.1:80 -r 10.0.0.20:​80 -g +
-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. +Interfata tunel trebuie sa aiba aceeasi ​adresa ​IP cu adresa virtuala ​directorului.
- +
-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 ​RSAceastă 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 +
-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. +
- +
-Pentru a vizualiza starea VS-ului, folositi parametrul **-l**:+
 <​code>​ <​code>​
-root@saisp-vm-1:~# ipvsadm ​-l+root@saisp-vm-2:~# ip tunnel add tun0 mode ipip local 10.0.0.20 
 +root@saisp-vm-2:~# ip addr add 10.0.0.1/24 dev tun0 
 +root@saisp-vm-2:​~#​ ip link set tun0 up
 </​code>​ </​code>​
  
-Pentru a afisa detalii despre conexiunile gestionate de VS, adaugati si parametrul **-c**: 
 <​code>​ <​code>​
-root@saisp-vm-1:~# ipvsadm ​--c+root@saisp-vm-3:~# ip tunnel add tun0 mode ipip local 10.0.0.30 
 +root@saisp-vm-3:~# ip addr add 10.0.0.1/24 dev tun0 
 +root@saisp-vm-3:​~#​ ip link set tun0 up
 </​code>​ </​code>​
  
-Pe langa configuratia de baza pe care am realizat-o, putem seta parametri aditionali.+Porniti, din nou, Wireshark si realizati o captura ​pe interfata **br0** a masinii fizice. Observati pachetele incapsulate si diferentele fata de LVS-DR.
  
-De exemplu, vom activa scheduler-ul de tip round-robin,​ apoi vom configura un maxim de 4 conexiuni simultane pentru fiecare RS:+Stergeti resursa HTTP definita anterior pe director. 
 + 
 +Stergeti interfetele tunel create pe realservere:
 <​code>​ <​code>​
-root@saisp-vm-1:~# ipvsadm -E -t 10.0.0.1:80 -s rr +root@saisp-vm-2:~# ip tunnel del tun0
-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>​ </​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>​ <​code>​
-root@saisp-vm-1:~# ipvsadm -D -t 10.0.0.1:80+root@saisp-vm-3:~# ip tunnel del tun0
 </​code>​ </​code>​
saisp/labs/05/contents/02.1393778564.txt.gz · Last modified: 2014/03/02 18:42 by alexandru.carp
CC Attribution-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0