Proiect ECIP High Availability Clusters -Linux HA Hearbeat-

Masterand: Ogilia Dinca, MPI, an I

Introducere
Clusterele definesc o colectie de servere care functioneaza ca si cum ar fi o singura instanta (masina). Scopul principal al clusterelor de inalta disponibilitate este acela de a oferi acces neintrerupt la date, in cazul in care un server pierde conectivitatea la retea sau la mediul de stocare, sau in cazul in care aplicatia care ruleaza pe server pica. Clusterele de inalta disponibilitate sunt utilizate in principal pentru servere de baze de date si e-mail, precum si pentru partajarea fisierelor. In implementarea de baza, clusterele de inalta disponibilitate consta in doua masini server (noduri) care impart spatiu de stocare comun. Datele sunt salvate in acest spatiu de stocare, si daca un nod nu poate oferi acces la acesta, celalalt nod poate primi cererile de la client. Figura 1-1 prezinta un cluster de inalta disponibilitate tipic cu doua noduri, cu serverele conectate la un spatiu de stocare partajat. In timplul functionarii normale, doar un singur server proceseaza cererile clientilor si are acces la spatial de stocare; acest lucru poate varia in functie de diferiti furnizori, in functie de modul de implementare al clusterelor. Clusterele de inalta disponibilitate pot fi implementate intr-o ferma de servere intr-o singura unitate fizica, in diferite faciliati la diferite distante. Ultimul tip de grup este numit si geocluster.

Fig 1-1

Clusterele de inalta disponibilitate pot fi clasificate in functie de diversi parametric, cum ar fi: Cum este partajat hardware-ul La ce nivel sistemul este clusterizat ( la nivelul sistemului de operare, la nivelul de aplicatie) Aplicatii care pot fi clusterizate Abordarea Quorum Interconctarea necesara

Una dintre modalitatile cele mai relevante pentru a clasifica clusterele de inalta disponibilitate este modul in care este impartit hardware-ul, si mai prcis, modul in care spatiu de stocare este impartit. Exista trei categorii de clustere: Clustere ce folosesc discuri oglinda software-ul de management este folosit pentru a crea discuri in oglinda pe toate masinile din cluster. Fiecare server scrie pe discurile pe care le detine si pe discurile serverelor ce fac parte din acelasi cluster. Clustere care nu impart nimic la un anumit moment doar un singur nod detine un disc. Cand acel nod esueaza, alt nod din cluster are acces la acel disc. Exemple pentru aceasta categorie de clustere include IBM High Avaiabilitu Cluster Multiprocessing (HACMP) si Microsoft Cluster Server (MSCS) Disc partajat toate nodurile au acces la acelasi spatiu de stocare. Un mecanism de blocare previne coruperea datelor. Exemple tipice include IMB Mainframe Sysplex si Oracle Real Application Cluster. Clusterele de inalta disponibilitate sunt realizate de obicei din doua servere, asa cum este aratat in exemplul din figura 1-1. Un server proceseaza cererile clientilor, in timp ce celalalt server monitorizeaza serverul principal pentru a prelua responsabilitatile acestuia in cazul in care acesta esueaza. Cand clusterul este alcatuit din doua servere, monitorizarea se poate intampla pe un link dedicat, care interconecteaza cele doua masini. Din perspectiva clientului, aplicatia este acesibila prin intermediul unui nume (de exemplu, un nume DNS), care la randul lui ii

corespunde unei adrese ip virtuale care poate sa sara de la o masina la alta, in functie de care server este activ.

Linux High-Availability Heartbeat

Linux-HA (High-Availability Linux) este cel mai cunoscut proiect care ofera solutii de inalta disponibilitate pentru Linux, FreeBSD, OpenBSD, Solaris i Mac OS X .Acesta promoveaz trei idei principale: Siguranta Disponibilitate Suportabilitate.

Produsul principal se numeste Heartbeat, un program de management al clusterelor de inalta disponibilitate. In scopul de a fi util pentru utilizatori, demonul Heartbeat trebuie s fie combinat cu un manager de resurse de cluster (CRM), care are sarcina de a porni i opri serviciile (adrese IP, servere de web, etc), pe care clusterul va face extrem de disponibil. Pacemaker este managerul preferat de resurse de cluster pentru clustere bazate Heartbeat. Mecanismul Heartbeat este folosit pentru a monitoriza disponibilitatea nodurilor clusterului. Fiecare server schimba mesaje (heartbeats) pentru a informa celalalta masina ca este functionabil. In general, daca mesajele de tip heartbeat nu sunt receptionate intr-un anumit interval de timp stabilit, nodul de rezerva presupune ca nodul principal este mort. Cand nodul principal se defecteaza, nodul de rezerva preia rolul nodului primar. Caracteristici ale programului Heartbeat: Fara numar fix de noduri; Monitorizarea resurselor; Mecanisme de inlaturare a unui nod din cluster in momentul aparitiei unei erori; Gestionare sofisticata a resurselor (independente, constrangeri); Script-uri pentru resurse incluse;

Interfata grafica pentru configurare, controlul si monitorizarea resurselor si nodurilor. Suporta mai multe tipuri de protocoale de comunicatie, inclusiv protocoale non-IP Raporteaza cand un link nu este activ, chiar si atunci cand exista linkuri redundante active. Trimite mesajele la toate nodurile, tot timpul Suporta multicast

Principalele canale folosite pentru a transfera mesajele de tip heartbeat sunt Ethernet si liniile seriale. Fibre Channel reprezinta o a treia optiune. Un mesaj de tip heartbeat poate fi transmis folosind protocolul IP peste Fibre Channel, care, in plus fata de furnizarea de pachete heartbeats, permite unui nod cluster sa realizeze in mod rapid daca a pierdut conexiunea cu spatiul de stocare partajat. Figura de mai jos ilustreaza posibila conectivitate intre noduri.

Heartbeat trimite o datagrama UDP la adresa de multicast 225.0.0.1 la fiecare secunda pentru a anunta ca este active. Daca masina care este in starea activa se opreste, fluxul de pachete de la nodul primar se opreste si dupa un timp prestabilit, nodul secundar devine primar si isi asuma adresa IP virtuala. Programul Heartbeat poate fi mult mai complex de atat: poate fi configurat sa monitorizeze anumite resurse de pe masina activa, astfel incat in cazul in care sunt

indeplinite anumite conditii o alta masina poate deveni activa. In acest caz doua daemon-uri negociaza transferal adresei de la o masina la cealalta, a doua masina devenind activa.

Ghid de implementare
1. Cerinte pentru a implementa un cluster de inalta disponibilitate Configuratia este realizata pentru un cluster cu doua noduri. Pentru acest exemplu s-a folosit doua Fedora Core 9 configurate pe WM Workstation 6.0.1 Ace Edition ce ruleaza pe Windows XP. Configuratiile pe amble masini Fedora Core se fac dupa cum urmeaza: Memorie RAM: 512 MB Hard Disk: 8 GB Procesor: Intel Core 2 Duo 2.0 GHz Adaptor Ethernet CD-Rom sau USB

Configuratiile de retea s-au facut dupa cum urmeaza: Pentru a asigna adresa IP: system-config-network Se selecteaza adaptorul de retea potrivit si se selecteaza optiunea de asignare adresa IP. Configuratiile IP folosite pentru acest proiect sunt : Masina primara IP: 192.168.1.20/24 Hostname:primary.net Masina secundara IP: 192.168.1.119/24 Hostname:secondary.net

2. Instalare Heartbeart Exista proceduri separate pentru a instala heartbeat pe diferite distributii de Linux. Pentru acest proiect s-a folosit Fedora Core 9. Pentru instalare trebuie deschisa o fereastra terminal si trebuie tastat urmatoarele: $ yum install heartbeat Nota: Trebuie sa ne asiguram ca avem yum deja instalat. Aceasta comanda va folosi conexiunea la internet pentru a descarca pachetul de heartbeat. Dupa ce pachetul este descarcat, acesta va fi instalat automat in folderol /etc sub directorul ha.d. 3. Configurare Heartbeat Exista 3 fisiere necesare pentru a configura Heartbeat. ha.cf haresources authkeys

Nota: La instalare, aceste fisiere nu se gasesc in directorul ha.d. Acestea trebuie sa fie copiate din /usr/share/doc/hearbeat in directorul ha.d. Configurarea fisierului ha.cf (1/3) In acest fisier vom specifica parametrii critici de operare pentru functionarea serviciului Hearbeat. Sunt specificate tipurile de cai media ce vor fi folosite si cum vor fi configurate acestea. Parametrii de configurare in acest fisier sunt: bcast eth1 specifica folosirea mesajelor heartbeat de tip broadcast pe interfata eth1 (se poate inlocui cu eth0 sau eth2) keepalive 2 seteaza intervalul intre doua heartbeats de 2 secunde

warntime 10 intervalul in secunde inainte de a transmite un mesaj de advertisement de tip late heartbeat deadtime 30 daca trec 30 de secunde fara sa se receptioneze un heartbeat, nodul este declarat mort initdead 120 in unele configuratii, retelei ii ia ceva timp ca sa functioneze dupa reboot. Acesta este un deadtime separate care se ocupa in acest sens. Trebuie sa fie de cel putin 2 ori mai mare decat intervalul deadtime.

udpport 694 se foloseste portul 694 pentru comunicatiile de tip unicast sau broadcast. Acesta este implicit, fiind inregistrat de catre IANA. auto_failback on nodul principal listat in fisierul haresources detine toate resursele pana la un failover, moment in care nodul secundar preia functiile celui primar. Cand auto-failback este setat on si nodul primar revine on-line, acesta va lua inapoi responsabilitatile de la nodul secundar. Cand auto_failback este setat off, aceasta optiune va impiedica nodul primar sa-si redobandeasca drepturile dupa un failover.

node linuxha1.linux-ha.org obligatoriu. Numele masinii primare din cluster node linuxha2.linux-ha.org obligatoriu. Numele masinii secundare din cluster. debugfile /var/log/ha-debug specifica locul unde vor fi stocate jurnalele de debug logfile /var/log/ha-log specifica locul unde vor fi stocate jurnalele generale

Configurarile pentru acest proiect Primary machine keepalive 2 warntime 10 deadtime 25 initdead 50 udpport 694 auto_failback on bcast eth0 node primary.net node secondary.net debugfile /var/log/ha-debug logfile /var/log/ha-log Secondary machine keepalive 2 warntime 10 deadtime 25 initdead 50 udpport 694 auto_failback on bcast eth1 node primary.net node secondary.net debugfile /var/log/ha-debug logfile /var/log/ha-log

Configurarea fisierului haresources (2/3) In fisierul haresources se gaseste o lista de resurse care ii este alocata masinii active din cluster. Nota: Acest fisier trebuie sa fie acelasi pe amblele noduri. Sintaxa: nume-nod adresa-ip/subnet/interfata Numele nodului afisat in partea din fata a informatiilor despre resursele de grup este numele nodului preferat pentru a executa serviciul. Acesta nu este neaparat numele masinii curente. Daca se executa auto_failback on, aceste servicii vor fi startate pe nodurile preferate, odata ce acestea sunt active. Daca se alege auto_failback off, atunci informatia nodului va fi folosita in caz de startare simultana. Adresa IP este configurata pe interfata care are o ruta catre o adresa data. Asta inseamna ca trebuie sa avem setata o tabela de rutare in afara structurii clusterului.

In acest proiect: primary.net 192.168.1.20/24/eth0 Configurarea fisierului authkeys(3/3) Fisierul authkeys trebuie sa fie detinut de catre root si sa aiba drepturi de scriere si de citire (chmod 600). Formatul actual al fisierului authkeys este foarte simplu, fiind alcatuit din doua linii. Prima linie contine o directiva auth careia ii este asociat numarul de identifcare a unei metode, iar in a doua linie este specificata metoda de autentificare si cheia corspunzatoare numarului de identificare din directiva auth. Exista trei metode de autentificare suportate: CRC, MD5 si SHA1. Daca Heartbeat functioneaza peste o retea securizata, se poate folosi CRC. Aceasta metoda nu consuma foarte multe resurse. Daca reteaua peste care functioneaza Heartbeat este nesigura se poate folosi md5. SHA1 foloseste mai multe resurse CPU, dar este mai greu de spart. Sintaxa: auth <number> <number><authmethod>[<authkey>] Configurarile pentru acest proiect: auth 1 1 md5 Hello!

4. Pornirea serviciului Heartbeat Odata ce sunt realizate configurarile pe ambele masini, se utilizeaza urmatoarele comenzi pentru a porni deamon-ul Heartbeat: $ /etc/init.d/heartbeat start aceasta comanda trebuie tastata pe ambele masini. Urmatoarele comenzi pot fi folosite atunci cand este nevoie: $ /etc/init.d/heartbeat stop $ /etc/init.d/heartbeat restart Odata ce serviciile Heartbeat sunt executate correct, pe ecran va aparea:

Urmatoarea figura reprezinta un screenshot al fisierului ha-log

5. Testarea serviciului Dupa ce serviciul starteaza pe ambele masini, acestea se vor monitoriza reciproc. Programul este lasat sa functioneze un timp. O a treia masina da ping la adresa IP a nodului primar. Dupa un timp nodul primar este izolat fizic de la retea (se deconecteaza cablul Ethernet). De indata ce nodul primar este deconectat, pe masina pe care a fost initiat ping-ul apar mesaje de genul: Request timed out. Dupa un anumit interval de timp (definit de warntime, deadtime, initdead) a treia masina incepe sa primeasca raspunsuri (icmp reply) de la ip-ul nodului primar. Ceea ce s-a intamplat de fapt in acest interval de timp este ca nodul secundar a observat ca nodul primar nu mai trimite mesaje heartbeat si prin urmare a concluzionat ca acesta este mort. Asfel nodul secundar dobandeste resursele nodului primar si incepe sa serveasca cereri pentru adresa ip a nodului primar.

Concluzii
Clusterele de inalta disponibilitate reprezinta o modalitate buna de a gestiona si furniza reduntanda. Acestea furnizeaza servicii de mare disponibilitate. Cluster-ele furnizeaza infrastructura care permite ca resursele reziliente, cum ar fi datele, dispozitivele si aplicatiile, sa fie comutate automat sau manual intre sisteme. Asigura detectarea defectelor si tratarea acestora, astfel ca, in cazul unei intreruperi, serviciul de resurse in cluster raspunde corespunzator, pastrand datele in siguranta si mentinand afacerea operationala.

Bibliografie
1. Heartbeat A Step by Step Configuration Guide to High Availability Linux Clusters:
http://theitaxis.wordpress.com/?s=heartbeat

2. Linux HA Heartbeat: http://linux-ha.org/wiki/Heartbeat 3. Simple IP Failover with Heartbeat

https://wiki.archlinux.org/index.php/Simple_IP_Failover_with_Heartbeat

4. High Availability Clusters :

http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/HA_Clusters/HAOver_1.ht ml