Pentru a pregăti configurația de laborator va trebui să descărcați pe mașina fizică (mjolnir
), în directorul saisp/
, arhiva laboratorului:
student@mjolnir:~/saisp$ wget --user=user-curs --ask-password http://repository.grid.pub.ro/cs/saisp/laboratoare/lab-09.zip student@mjolnir:~/saisp$ unzip lab-09.zip
În urma dezarhivării rezultă două fișiere imagine KVM (format qcow2
, web.qcow2
și varnish.qcow2
) și un script de pornire a mașinilor virtuale (xlr8-start-kvm
). Fișierul imagine de bază base.qcow2
este deja în directorul saisp/
și este baza pentru celelalte două fișiere imagine: web.qcow2
și varnish.qcow2
.
Puteți urma pașii de mai sus pentru a descărca infrastructura KVM pentru laborator pentru lucru acasă.
Pentru pornirea celor două mașini virtuale (una cu serverul web, alta cu instanța Varnish) rulați scriptul de pornire:
student@mjolnir:~/saisp$ ./xlr8-start-kvm
Vor porni cele două mașini virtuale KVM pentru laborator.
Pentru accesarea celor două mașini folosiți SSH către adresele IP aferente fiecăreia. Pentru conectarea la mașina virtuală pentru serverul web folosiți comanda
student@mjolnir:~/saisp$ ssh -l root 192.168.0.2
iar pentru conectarea la instanța Varnish folosiți comanda
student@mjolnir:~/saisp$ ssh -l root 192.168.0.3
Parola pe cele două mașini virtuale este student
atât pentru utilizatorul root
cât și pentru utilizatorul student
.
Dorim să urmărim efectul folosirii Varnish față de accesarea directă a unui server web. Vom folosi utilitarul httperf
pentru a evalua comportamentul accesului web folosind Varnish sau fără Varnish.
Pe mașina virtuală varnish
(accesibilă folosind ssh -l root 192.168.0.3
) este instalat Varnish. Este configurat să asculte conexiuni pe portul 80, lucru pe care îl putem verifica folosind comanda:
root@varnish:~# netstat -tlpn | grep varnish tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 2366/varnishd tcp 0 0 127.0.0.1:6082 0.0.0.0:* LISTEN 2364/varnishd tcp6 0 0 :::80 :::* LISTEN 2366/varnishd tcp6 0 0 ::1:6082 :::* LISTEN 2364/varnishd
Portul 6082
este portul de administrare. Configurația aferentă se găsește în fișierul /etc/default/varnish
. Putem folosi un editor/viewer sau comanda de mai jos pentru a investiga configurația:
root@varnish:~# grep -A 4 DAEMON_OPTS /etc/default/varnish | grep -v '^#' -- -- DAEMON_OPTS="-a :80 \ -T localhost:6082 \ -f /etc/varnish/default.vcl \ -S /etc/varnish/secret \ -s malloc,256m" -- --
Pentru a urmări utilitatea folosirii Varnish, vrem să ne conectăm la un server pe legătură directă și prin intermediul Varnish. Alegem serverul ocw.cs.pub.ro
. Pentru aceasta, serviciul Varnish a fost configurat să folosească pe post de back end ocw.cs.pub.ro
. Putem consulta această configurație în fișierul /etc/varnish/default.vcl
folosind un editor/viewer sau comanda de mai jos:
root@varnish:~# grep -A 3 'backend default' /etc/varnish/default.vcl backend default { .host = "ocw.cs.pub.ro"; .port = "80"; }
Configurația de mai sus înseamnă că pentru cererile venite către serviciul Varnish se vor realiza cereri mai departe către serverul ocw.cs.pub.ro
. Cererile vor fi cache-urite astfel încât viitoare cereri vor fi servite direct din cache.
Evaluarea o vom face de pe sistemul gazdă (mjolnir
). Pentru acesta va trebui să configurăm sistemul astfel încât cererile către ocw.cs.pub.ro
să ajungă la mașina virtuală varnish
. Pentru aceasta, folosiți un editor și adăugați în fișierul /etc/hosts
linia:
192.168.0.3 ocw.cs.pub.ro
Cu linia de mai sus, cererile către ocw.cs.pub.ro
vor ajunge la mașina virtulă varnish
. Putem verifica acest lucru folosind comanda:
student@mjolnir:~$ ping ocw.cs.pub.ro PING ocw.cs.pub.ro (192.168.0.3) 56(84) bytes of data. 64 bytes from ocw.cs.pub.ro (192.168.0.3): icmp_seq=1 ttl=64 time=0.361 ms ^C
Pentru început puteți să vă conectați din browserul de pe stația gazdă (mjolnir
) și să accesați URL-ul aferent: http://ocw.cs.pub.ro
. O să vedeți că primul acces durează mai mult dar viitoarele accese ale aceleiași pagini sunt mai rapide.
Pentru a evalua acest lucru, instalați utilitarul httperf
pe stația gazdă folosind comanda:
student@mjolnir:~$ sudo apt-get install httperf
Apoi măsurați conexiunile realizate pentru pagina de la URL-ul http://ocw.cs.pub.ro
folosidn comanda:
student@mjolnir:~$ httperf --server=ocw.cs.pub.ro --wsess=2000,10,2 --rate 300 --timeout 5
Observați în output informații precum Connection rate
, Request rate
, Net I/O
.
Ca să comparăm trebuie să ne conectăm în mod direct la serverul ocw.cs.pub.ro
. Pentru acesta ștergeți (sau comentați) linia adăugată anterior în fișierul /etc/hosts
și rulați din nou comanda httperf
de mai sus. Observați diferențele parametrilor și, astfel, utilitatea folosirii Varnish ca accelerator pentru conexiuni web.
Ne propunem să configurăm Varnish ca front-end pentru un server web configurat de noi. Pentru aceasta vom configura instanța Varnish de pe mașina virtuală varnish
ca front end pentru serverul web de pe mașina virtuală web
și apoi vom face măsurători.
Pentru început, configurați instanța Varnish de pe mașina virtuală varnish
să folosească pe post de back end serviciul web de pe mașina virtuală web.
80
la adresa IP 192.168.0.2
.
După configurarea Varnish serviciul trebuie repornit folosind comanda
root@varnish:~# service varnish restart
Pentru a testa conectați-vă din browser-ul de pe stația gazdă la adresa serverului Varnish: http://192.168.0.3/. Dacă totul a mers cum trebuie va apărea o pagină cu mesajul Say hello to my little friend!.
Același mesaj poate fi accesat direct de la serverul web: http://192.168.0.2/, doar că nu va mai trece prin serverul Varnish.
Pentru a măsura durata transferului cu și fără Varnish, folosiți httperf
pe stația gazdă (mjolnir
) pentru a descărca un fișier dintre cele accesibile la adresa http://192.168.0.3/data/ (sau http://192.168.0.2/data/); de indicat este să folosiți fișierul 10M.dat
de dimesiunea cea mai mare. Folosiți conectarea la ambele servere (cu și fără suport Varnish) pentru a face diferența.
În timpul în care rulați httperf
urmăriți folosind htop
încărcarea pe cele două mașini virtuale. Observați încărcarea serverului Varnish atunci când acesta este folosit, sau a serverului Apache la conexiunile directe.
--uri
la httperf
ca să precizați pagina care să fie accesată. În cazul nostru ar fi vorba de http://192.168.0.2/data/10M.dat sau http://192.168.0.3/data/10M.dat.
Observati diferența de Request rate
între conexiunea directă la serverul web și conexiunea prin intermediul serverului Varnish.
Ca să urmărim starea serviciului Varnish dispunem de câteva utilitare de analiză și monitorizare a acestuia. Acestea sunt, respectiv, varnishlog
, varnishstat
și varnishhist
.
Toate afișează informații despre serviciul Varnish din momentul rulării comenzii, nu și dinainte.
Comanda varnishlog
afișează informații despre conexiunile realizate la serviciul Varnish. Rulați comanda varnishlog
și apoi realizați conexiuni la serviciu. Urmăriți informații despre aceste conexiuni în output-ul comenzii. Informațiile afișate sunt bogate; putem să filtrăm din acestea. De exemplu, dacă rulăm comanda
# varnishlog -O -i RxURL
va fi afișat doar URL de receive (ceea ce i-a fost solicitat serviciului Varnish).
Comanda varnishstat
afișează informații despre starea serviciului. Output-ul ocupă un ecran și este actualizat periodic. Porniți comanda, realizați conexiuni către serviciul Varnish și urmăriți actualizarea output-ului. Urmăriți linia Hitrate ratio
.
Comanda varnishhist
afișează o histogramă a timpului de servire a cererilor. Pe partea orizontală sunt prezentați timpii de servire, la scară logaritmică. Accesele care nu ajung în cache apar cu #
(diez) iar cele care ajung în cache apar cu |
(pipe). Realizați mai multe conexiuni diferite (de exemplu la cele trei fișiere de dimensiuni diferite) și observați output-ul afișat de comandă. Observați că este foarte mic timpul de servire din cache față de cel de servire inițială, prin interogarea serverului web.
Folosiți comanda varnishlog
pentru a afișa doar cererile către fișierul /data/100k.dat
.
-m
a varnishlog
. Urmăriți și exemplele din pagina de manual a comenzii varnishlog
.
Vrem să vedem cum se comportă cache-ul în Varnish. Intrările în Varnish sunt cache-uite pentru o perioadă de timp înainte să expire. După expirarea timpului respectiv, se realizează o nouă cerere către serverul web pentru obținerea din nou a paginii.
Timpul de viață al cache-ului este dat de o variabilă TTL internă a Varnish. Valoarea sa este în mod implicit configurată la 120
de secunde. Putem determina acest lucru prin intermediul comenzii:
root@varnish:~# varnishadm param.show default_ttl
Valorea implicită, afișată de comanda de mai sus este 120
de secunde. Această valoare poate fi configurată în fișierul /etc/default/varnish
; este vorba de directiva VARNISH_TTL
.
Ca să urmărim expirarea cache-ului, vom folosi comanda varnishlog
în forma de mai jos:
root@varnish:~# varnishlog -i VCL_Call
Apoi facem cereri către fișierele cu extensia .dat
menționate în exercițiul anterior.
Observăm că apare un mesaj ce conține cuvântul miss
atunci când informația nu se găsește în cache, și apoi un mesaj ce conține cuvântul hit
când informația este în cache. După 120
de secunde cache-ul va expira și atunci un acces va genera un miss
.
După ce ați generat un mesaj miss
pe fișierul 100k.dat
, adică informația nu era, dar acum este, în cache, rescrieți fișierul pe serverul web, în directorul /var/www/data/100k.dat
folosind comanda:
root@web:/var/www/html/data# dd if=/dev/urandom of=100k.dat bs=100k count=1
Apoi accesați din nou fișierul și urmăriți output-ul comenzii varnishlog
. Veți observa că fișierul a fost obținut din cache. Până când cache-ul nu expiră orice modificare a fișierului nu va fi vizibilă în cache.
Pentru a preveni rămânerea în cache a unui obiect dat, se poate folosi purging sau banning. După ce au ajuns în cache fișierele cu extensia .dat
, faceți ban acelor fișiere pentru a fi recitite de pe server.
varnishadm
pentru a accesa CLI-ul de configurare Varnish.
Pentru a realiza configurări în Varnish se folosește sintaxa VCL (Varnish Configuration Language). Aceasta permite încărcarea dinamică de configurații într-o instanța Varnish în rulare.
Folosind fișierul de configurare /etc/varnish/default.vcl
, configurați un TTL de 1 oră pentru fișierele din directorul /data/
servite de Varnish. Celelalte fișiere/pagini servite vor folosi valoarea implicită a TTL-ului (de 120
de secunde).
Reporniți serviciul varnish
după realizarea configurației.
Așteptați 3-4 minute după primul acces la o pagină din directorul /data/
și apoi reaccesați-o. O configurație corectă va înseamna un hit
în pagină (cache-ul de o oră nu va fi expirat).
Dorim ca serviciul Varnish să accelereze accesul web atât către serverul web din mașina virtuală web
cât și către ocw.cs.pub.ro
. Pentru aceasta trebuie să fie configurate două back end-uri.
Configurați cele două back end-uri astfel încât dacă URL-ul începe cu /courses/
să fie servit de back end-ul de ocw.cs.pub.ro
, altfel să fie servit de back end-ul mașinii virtuale web
.
Dorim să facem load balancing (denumit și directors în Varnish). Înainte de această configurare, opriți mașina virtuală web
și creați o copie a imaginii web.qcow2
într-un alt fișier, de exemplu web-copy.qcow2
. Apoi editați scriptul xlr8-start-kvm
pentru a porni o nouă mașina web
, cu altă adresă IP. Această mașină web este al doilea back end.
192.168.0.4
în fișierul /etc/network/interfaces
.
Schimbați adresa MAC a copiei mașinii virtuale în scriptul xlr8-start-kvm
ca să fie diferită de adresele MAC ale celorlalte mașini virtuale.
În scriptul xlr8-start-kvm
folosiți o nouă interfață TAP, de exemplu tap3
, și stabiliți un nou port VNC, de exemplu :3
.
Configurați Varnish pe mașina virtuală varnish
să folosească cele două servere web de pe celelalte două mașini virtuale în load balancing de tip round robin.
set req.backend …
. Urmăriți și exemplul de aici.
Nginx este un server web care poate îndeplini un rol de reverse proxy and cache server la fel ca Varnish. Instalați și configurați Nginx pe stația varnish
.
80
. Cel mai bine configurați serviciul Varnish să asculte conexiuni pe alt port (8080
de exemplu).
Urmăriți și indicațiile de aici. Trebuie să folosiți directiva listen
pentru a configura portul pe care ascultă conexiuni Nginx.
De pe stația gazdă (mjolnir
) folosiți utilitarul httperf
pentru a măsură performanța Nginx ca reverse proxy față de Varnish.
Configurați Squid ca forward proxy pe mașina virtuală web
și apoi configurați browserul local să folosească Squid ca proxy.
squid3
.
Urmăriți și indicațiile de aici.
Pentru verificare, accesați din browser anumite adrese și urmăriți fișierul de jurnalizare al Squid: /var/log/squid3/access.log
.