Laborator 5. Redundanță și load balancing

Cunoștințe și abilități ce vor fi dobândite

Laboratorul va explora diverse solutii folosite in clusterele de servicii:

  • Load balancing: Linux Virtual Server (LVS)
  • Redundanta si high availability: Linux-HA
  • Replicarea continutului: Distributed Replicated Block-Device (DRBD)

Pregătire infrastructură de laborator

Vom rula o masină virtuală în cloud-ul facultății. Pentru a porni o astfel de masină urmăriți tutorialul de la această adresă. Când creați instanța de mașină virtuală (în fereastra “Launch instance”):

  • La opțiunea Availability zone să alegeți CI sau hp.
  • La opțiunea Instance Boot Source să alegeți Boot from Image.
  • La opțiunea Image Name (apărută după ce efectuați pasul de mai sus) să alegeți imaginea SAISP Template v1.

Pentru Size alegeti m1.medium sau c1.medium

Pentru a pregăti configurația de laborator, pe mașina virtuală folosiți comenzile următoare din contul utilizatorului student:

  • student@mjolnir:~/saisp$ cd saisp/
    student@mjolnir:~/saisp$ wget --user=user-curs --ask-password http://repository.grid.pub.ro/cs/saisp/laboratoare/lab-05.zip
    student@mjolnir:~/saisp$ unzip lab-05.zip

În urma dezarhivării rezultă mai multe fișiere imagine KVM și un script de pornire a mașinilor virtuale:

  • Imaginea de bază base.qcow2 este deja în directorul saisp/ și este baza pentru celelalte.
  • Fișierele saisp-vm-1.qcow2, saisp-vm-2.qcow2 si saisp-vm-3.qcow2 sunt obținute din base.qcow2 și sunt folosite pentru pornirea masinilor virtuale.
  • Fișierele drdb-vm-2.qcow2 și drdb-vm-3.qcow2 sunt fișiere ce reprezintă discuri suplimentare folosite în configurația pentru DRBD.

Pentru a porni mașinile virtuale, vom folosi comanda

student@mjolnir:~/saisp$ ./lab05-start-kvm

După pornirea mașinilor virtuale KVM, le putem accesa prin folosirea SSH către adresele IP aferentă. Vom folosi comenzile:

student@mjolnir:~/saisp$ ssh root@10.0.0.10
student@mjolnir:~/saisp$ ssh root@10.0.0.20
student@mjolnir:~/saisp$ ssh root@10.0.0.30

Detalii rulare masina virtuala KVM local

Detalii rulare masina virtuala KVM local

Pentru a pregăti configurația de laborator va trebui să descărcați pe mașina fizică (mjolnir), în directorul saisp/, arhiva laboratorului (base.qcow2 există deja):

student@mjolnir:~/saisp$ wget --user=user-curs --ask-password http://repository.grid.pub.ro/cs/saisp/laboratoare/base.qcow2
student@mjolnir:~/saisp$ wget --user=user-curs --ask-password http://repository.grid.pub.ro/cs/saisp/laboratoare/lab-05.zip
student@mjolnir:~/saisp$ unzip lab-05.zip

Puteți urma pașii de mai sus pentru a descărca infrastructura KVM pentru laborator pentru lucru acasă.

Exerciții

00. Linux Virtual Server

Linux Virtual Server (LVS) este o soluție avansată de load balancing. Este open source, integrat în kernel-ul Linux.

Mașina care face load balancing se numește, în 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.

LVS are 3 moduri de funcționare:

  • 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.
  • 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.
  • 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.

Topologie

Masinile din topologie (3 masini virtuale KVM si masina fizica) au urmatoarele roluri:

  • masina saisp-vm-1 are rol de director (Virtual Server), facand load-balancing pentru saisp-vm-2 si saisp-vm-3;
  • masinile saisp-vm-2 si saisp-vm-3 au rol de realservere;
  • masina fizica are rol de client;

01. [20p] LVS-DR (direct routing)

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.

Pe director este deja instalat pachetul ipvsadm necesar configurării load balancing-ului.

Mai intai vom configura adresa virtuala pe director. Adaugam adresa 10.0.0.1/24 pe subinterfata eth0:1 de pe saisp-vm-1:

root@saisp-vm-1:~# ip addr add dev eth0 10.0.0.1/24 label eth0:1

Vom configura HTTP ca serviciu virtual. Trebuie să specificăm adresa si portul serverului virtual și protocolul de nivel transport (TCP, în cazul nostru).

root@saisp-vm-1:~# ipvsadm -A -t 10.0.0.1:80

Serviciul virtual a fost configurat, dar trebuie să adăugăm și servere reale:

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

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, 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.
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

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:

root@saisp-vm-1:~# ipvsadm -l

Pentru a afisa detalii despre conexiunile gestionate de VS, adaugati si parametrul -c:

root@saisp-vm-1:~# ipvsadm -l -c

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:

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

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:

root@saisp-vm-1:~# ipvsadm -D -t 10.0.0.1:80

In plus, pe realservere vom sterge regulile iptables definite:

root@saisp-vm-2:~# iptables -t nat -F
root@saisp-vm-3:~# iptables -t nat -F

02. [20p] LVS-TUN (tunneling)

In continuare, vom configura directorul pentru a folosi modul LVS-TUN. Apoi, vom observa diferentele fata de LVS-DR.

Analog punctului anterior, definiti serviciul HTTP pe director, apoi cele doua realservere in modul tunneling (folositi parametrul -i).

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.

Interfata tunel trebuie sa aiba aceeasi adresa IP cu adresa virtuala a directorului.

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
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

Porniti, din nou, Wireshark si realizati o captura pe interfata br0 a masinii fizice. Observati pachetele incapsulate si diferentele fata de LVS-DR.

Stergeti resursa HTTP definita anterior pe director.

Stergeti interfetele tunel create pe realservere:

root@saisp-vm-2:~# ip tunnel del tun0
root@saisp-vm-3:~# ip tunnel del tun0

03. [20p] Linux-HA

Linux-HA este o solutie de clustering. Vom configura un cluster simplu, format din două noduri.

Topologia conceptuala este cea din figura de mai sus. Observatii:

  • Cele două realservere din topologia LVS vor fi configurate ca un cluster.
  • Directorul din topologia LVS nu mai are nici un rol aici. Inchideti masina virtuala respectiva, pentru a nu consuma resurse inutil.
  • Adresa IP prin care va fi accesibil serviciul HTTP este 10.0.0.50.

Pachetul heartbeat este deja instalat pe saisp-vm-2 si saisp-vm-3.

Este necesar ca stațiile să se poată adresa una pe cealaltă folosind doar hostname-ul. Adăugați liniile corespunzătoare în /etc/hosts:

saisp-vm-2# echo "10.0.0.30 saisp-vm-3" >> /etc/hosts
saisp-vm-3# echo "10.0.0.20 saisp-vm-2" >> /etc/hosts

Fișierele de configurare pentru heartbeat se găsesc în directorul /etc/ha.d/. Creați, pe ambele stații, fișierul ha.cf.

  • Dezactivați auto-discovery (Nodurile vor fi specificate manual)
autojoin none
  • Specificați modul de comunicare (unicast), interfața pe care se comunică (eth0) și adresa celuilalt nod (Linux-HA poate folosi, de asemenea, broadcast sau multicast)
ucast eth0 10.0.0.30
  • Specificați nodurile care participă la cluster. Va trebui să specificați inclusiv nodul local - numele unui nod trebuie întotdeauna să coincidă cu hostname-ul masinii:
node saisp-vm-2 saisp-vm-3

Linux-HA oferă suport pentru autentificarea conexiunii. Să configurăm folosirea SHA1:

  • Fișierul de configurare corespunzător este authkeys:
auth 1
1 sha1 42ade27dad9045964fab10a395ffe4e0f726a80b
  • Puteți genera un digest SHA1 folosind echo “my secret” | openssl sha1.
  • Fișierul authkeys trebuie să poată fi citit numai de root: chmod 600 /etc/ha.d/authkeys.

Nu în ultimul rând, trebuie să configurăm serviciile oferite de cluster. În acest exemplu, vom configura HTTP.

  • Creați fișierul de configurare /etc/ha.d/haresources:
saisp-vm-2 10.0.0.50 apache2
  • Linia de mai sus configurează serviciile apache2 să ruleze inițial pe nodul saisp-vm-2. Dacă acest nod pică, serviciile vor fi oferite de saisp-vm-3.
  • Atentie: Folositi aceeasi linie si pe saisp-vm-3 (resursa trebuie detinuta de un singur owner).
  • Este important de observat că, în acest exemplu, serviciile rulează pe ambele noduri tot timpul. Ceea ce se schimbă este nodul cu care este asociată adresa IP.

Reporniți serviciul heartbeat pe ambele mașini și observați adresele lor IP.

Folosind un browser, accesati adresa http://10.0.0.50/

Experimentați oprind serviciul heartbeat de pe saisp-vm-2. După un timeout, saisp-vm-3 va avea configurată adresa serviciului pe interfața sa eth0.

Accesati din nou adresa http://10.0.0.50/ dar observati ca de aceasta data va raspunde statia saisp-vm-3.

Atenție: acest setup oferă redundanță la nivelul serviciilor, dar nu asigură și replicare. Într-o situație concretă, trebuie să ne asigurăm că ambele servere oferă aceleași informații.

04. [20p] DRBD

Dorim sa asiguram replicarea continutului pentru clusterul configurat la punctul anterior. Vom folosi DRBD.

Vom folosi o legatura directa intre intefetele eth1 ale nodurilor. Aceasta legatura va fi folosita pentru traficul de sincronizare si replicare al DRBD.

Configurati adresele IP pe legatura dedicata:

saisp-vm-2# ip addr add 10.0.23.2/24 dev eth1
saisp-vm-2# ip link set eth1 up
saisp-vm-3# ip addr add 10.0.23.3/24 dev eth1
saisp-vm-3# ip link set eth1 up

Pachetul drbd8-utils este deja instalat.

Observati faptul ca fisierele /etc/drbd.conf si /etc/drbd.d/global_common.conf sunt deja create. Noi vom defini o noua resursa, in fisierul /etc/drbd.d/r0.res. Resursa va avea urmatoarele caracteristici:

  • numele resursei: r0;
  • device-ul DRBD: /dev/drbd0;
  • partitia de pe disc: /dev/sdb1;
  • metadate stocate intern.

ATENTIE! Urmatoarele task-uri trebuie efectuate pe ambele noduri.

Creati fisierul /etc/drbd.d/r0.res, cu urmatorul continut:

resource r0 {
  on saisp-vm-2 {
    device    /dev/drbd0;
    disk      /dev/sdb1;
    address   10.0.23.2:7788;
    meta-disk internal;
  }
  on saisp-vm-3 {
    device    /dev/drbd0;
    disk      /dev/sdb1;
    address   10.0.23.3:7788;
    meta-disk internal;
  }
}

Restartati serviciul drbd:

/etc/init.d/drbd restart

Initializati cu zero partitia /dev/sdb1:

dd if=/dev/zero of=/dev/sdb1 bs=64K

Creati metadatele DRBD pentru resursa r0:

drbdadm create-md r0

Atasati resursa la block-device:

drbdadm attach r0

Verificati starea DRBD:

cat /proc/drbd
drbd-overview

ATENTIE! Sincronizarea initiala trebuie pornita doar pe unul dintre noduri! Pe nodul care este activ in cluster (are adresa 10.0.0.50 pe interfata eth0:0), porniti sincronizarea initiala:

drbdadm -- --overwrite-data-of-peer primary r0

Verificati ca sincronizarea a inceput:

drbd-overview

In timp ce sincronizarea se efectueaza:

Creati un sistem de fisiere ext4 pe device-ul /dev/drbd0. Acest lucru poate fi efectuat doar pe nodul de pe care ati pornit sincronizarea:

mkfs.ext4 /dev/drbd0

05. [20p] Integrare DRBD cu Linux-HA

Modificati fisierul /etc/ha.d/haresources pe ambele noduri astfel incat daemon-ul Linux-HA sa monteze device-ul /dev/drbd0 in /var/www atunci cand nodul devine activ:

saisp-vm-2 drbddisk::r0 Filesystem::/dev/drbd0::/var/www::ext4 10.0.0.50 apache2

Restartati serviciul heartbeat pe ambele noduri.

Verificati ca sistemul de fisiere a fost montat corect.

Dupa ce s-a incheiat sincronizarea, creati un fisier index.html in /var/www/html/ pe nodul activ si verificati functionalitatea din browser, la adresa http://10.0.0.50/

mkdir /var/www/html/
echo "DRBD Storage" > /var/www/html/index.html

Inchideti serviciul heartbeat pe masina virtuala care este nod primar si asteptati ca celalalt nod sa devina activ. Verificati ca storage-ul functioneaza in continuare corect.

06. [BONUS - 10p] Verificare online pentru DRBD

In configuratia actuala, DRBD nu permite verificare consistentei block-device-urilor fara ca acestea sa fie demontate.

Consultati documentatia de aici: https://docs.linbit.com/doc/users-guide-84/s-use-online-verify/ Activati verificarea online pentru resursa definita, apoi porniti o verificare online.

Dupa activarea verificarii online, s-ar putea sa declansati o situatie de tip “split-brain”. Pentru a o remedia, consultati documentatia de aici: https://docs.linbit.com/doc/users-guide-84/s-resolve-split-brain/

saisp/labs/05.txt · Last modified: 2016/03/28 16:24 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