Instalarea Si Optimizarea Veritas Cluster Server PE Sisteme Linux Critice

Informatica

Instalarea Si Optimizarea Veritas Cluster Server PE Sisteme Linux Critice

Byadmin ianuarie 1, 2024

INSTALAREA ȘI OPTIMIZAREA VERITAS CLUSTER SERVER PE SISTEME LINUX CRITICE

TEMA Instalarea și optimizarea Veritas Cluster Server pe sisteme Linux critice

Lucrare de Finalizare a studiilor a studentului Bobica Alexandru Florinel

1). Tema lucrării de finalizare a studiilor: Instalarea și optimizarea Veritas Cluster Server pe sisteme Linux critice

2). Termenul pentru predarea lucrării 31 Mai 2015

3). Elemente inițiale pentru elaborarea lucrării de finalizare a studiilor

Studiul bibliographic

Design-ul și conceputul platformei de test

Optimizarea membrilor din cluster

Conceperea și simularea unor situații reale și critice pe clustere Veritas

4). Conținutul lucrării de finalizare a studiilor: Lucrarea conține 5 capitole care descriu instalarea, configurarea și testarea unui Veritas Cluster Server productiv:

Capitolul 1 Introducere teoretică a Veritas Cluster Server

Capitolul 2 Instalarea mediului de test Veritas Cluster Server

Capitolul 3 Pregătirea și configurarea elemtentelor cluster-ului

Capitolul 4 Studiu și test de caz cu NFS Shares și Server Web

Capitolul 5 Concluzii

5). Material grafic: printscreen-uri, grafice, figuri

6). Locul de documentare pentru elaborarea lucrării:

Compania Dell Services Romania SRL

7). Data emiterii temei 10.11.2014

Cuprins

Capitolul 1 Introducere teoretică a Veritas Cluster Server

Un sistem cluster cuprinde un set de calculatoare (servere) care sunt conectate între ele și care lucrează împreună, astfel că ele sunt văzute ca un singur sistem. Spre deosebire de serverele grid, sistemele de cluster sunt configurate în așa fel încât fiecare nod deservește aceleași servicii sau aplicații, controlate și programate de către software-ul de cluster.

De obicei componentele unui sistem cluster sunt conectate între ele prin conexiune de rețea locale foarte rapide, iar fiecare nod al cluster-ului funcționând ca și o instanță individuală a sistemului de operare. De asemenea, în marea majoritate a situațiilor, toți membrii unui cluster au aceeași configurație hardware și același sistem de operare (versiune).

Scopul acestor sisteme de cluster este de a îmbunătăți performanța și disponibilitatea serviciilor/aplicațiilor critice către utilizatori.

Există mai multe tipuri de sisteme de cluster care se pot instala și configura în mediul Unix (Linux, Solaris, HP-UX, AIX):

– Veritas Cluster Server

– Red Hat Cluster

– Solaris Sun Cluster

– HP Serviceguard pentru HP-UX

– HACMP, soluția de cluster pentru AIX IBM

Despre Veritas Cluster Server

Veritas Cluster Server (VCS) dezvoltat de către compania Symantec conectează multiple sisteme independente într-un cadru de management propice astfel încât disponibilitatea resurselor oferite de către aceste sisteme să fie optimă. Fiecare sistem, sau nod, are instalat propriul sistem de operare și formează la nivel de aplicație software acest cluster. Această soluție de cluster combină echipament hardware ieftin cu un software inteligent având ca rezultat un control mai crescut asupra aplicațiilor și de asemenea o revenire a aplicațiilor înapoi în funcțiune în caz de defecțiune pe unul dintre membrii cluster-ului. Atunci când un nod sau o aplicație monitorizată se defectează, celălalt nod poate prelua și porni acele servicii afectate altundeva pe acel cluster.

Prin diferitele comenzi, teste sau scripturi prin care VCS-ul monitorizează buna funcționare a unei aplicații, acestea detectează atunci când apare vreo problemă cu vreun serviciu sau echipament hardware pe oricare dintre membrii cluster-ului. De asemenea cluster-ul de Veritas poate monitoriza și starea diferitelor elemente ca și sistemele de fișiere sau interfețele de rețea.

Veritas Cluster Server folosește o legătură de rețea redundantă de hearbeat (puls) astfel încât atunci când conexiunea între membrii cluster-ului dispare, programul de software să poată face diferența între o defecțiune a link-ului de rețea sau una a unui sistem hardware. De asemenea VCS-ul poate folosi o coordonare a nodurilor tip SCSI3 și o protecție a datelor pentru detectare defecțiunilor pe un nod anume și pentru fencing.

Atunci când VCS-ul detectează că o aplicație sau un nod nu mai răspund, le mută și pornește aplicațiile și serviciile respective pe un alt nod diferit din cluster. Figura 1.1 arată cum cluster-ul virtualizează adresele de IP și numele sistemelor membri în așa fel încât utilizatorii sau alți clienți nu iși dau seama ce server sau membru din cadrul cluster-ului folosesc.

Figura 1.1

De exemplu, dacă avem un sistem cluster format din două servere de baze de date server1-db și server2-db, vom avea o adresă de IP virtuală denumita ”server-db”. Clienții vor accesa server-db și nu vor ști pe care dintre serverre fizice membre ale clsuter-ului este în funcțiune baza de date.

Componentele fizice ale unui VCS

Un cluster VCS cuprinde sisteme care sunt interconectate printr-o infrastructură de comunicații dedicată. Atunci când vorbim despre ”un nod”, ne referim la un server ce face parte din cluster-ul VCS. Fiecare cluster are câte un ID unic iar legăturile care leagă toate sistemele într-un cluster sunt redundante.

Nodurile Veritas Cluster Server

Nodurile hostează grupurile de servicii (aplicații și resursele lor). Fiecare sistem este de obicei conectat la un echipament de rețea și de asemena la un sistem de stocare date extern (storage). Sistemul conține componente capabile să ofere un management al aplicațiilor și să pornească/oprească agenții.

Nodurile pot fi servere individuale, sau pot fi create ca și domenii sau partiții hadware pe servere de tip enterprise sau configurate ca si mașini virtuale. Membrii cluster-ului au fiecare sistemul de operare propriu și posedă fiecare device-ul său de pe care boot-ează. Este necesar ca aceste sisteme de operare de pe nodurile cluster-ului să fie aceleași. Putem avea maxim 64 de noduri într-un Veritas Cluster Server. Se pot configura aplicațiile să ruleze pe noduri specifice din cadrul unui VCS.

Shared Storage (sistem de stocare date share-uit)

SAN storage-ul este o resursă cheie pentru majoritatea aplicațiilor, serviciilor și de aceea pentru majoritatea grupurilor de servicii. Putem porni o anumită aplicație pe un nod numai dacă această aplicație are acces la fișierele și datele sale de configurare. De accea, un grup de servicii paote rula pe toate serverele dintr-un VCS numai dacă storage-ul este accesibil de pe toate nodurile. În cele mai multe dintre configurații se folosește SAN-ul (storage area networks). –un sistem/server dedicat care livrează capacitate de stocare de date remote pentru mai multe servere.

Pentru protecția datelor se poate folosi tehnologia de I/O Fencing. Această tehnologie blochează accesul către datele share-uite ale oricărui sistem care care nu este un membru curent și verificat al cluster-ului VCS.

Rețeaua

Parte de rețea în cluster este folosită pentru următoarele scopuri:

– comunicarea între nodurile cluster-ului și utilizatori sau serverele utilizatorilor;

– comunicarea între nodurile cluster-ului.

Componentele logice ale unui VCS

Veritas Cluster Server este alcătuit din mai multe componente care livrează infrastructura care face posibilă oferirea unei aplicații redundante.

Resursele pot fi entități hardware sau software care împreună alcătuiesc aplicația. Grupurile de disk-uri și sistemele de fișiere, plăcile de rețea, adresele de IP și aplicațiile sunt doar niște exemple de resurse.

Dependințele dintre resurse indică acele resurse care depind una de cealaltă din cauza cerințelor aplicației sau sistemului de operare. Aceste dependințe sunt reprezentate mai jos printr-o figură tip ierarhie Fig. 1.2, denumită și arbore (tree), acolo unde resursele plasate în vârful ierarhiei (părinți) depind de resursele aflate mai jos în arbore (copii).

Figura 1.2

Dependințele dintre resurse determină în care ordine vor fi pornite sau oprite aceste resurse. De exemplu, trebuie să importăm un grup de discuri înainte de a putea porni volumele din acele grupuri, și bineînțeles acele volume trebuie pornite pentru a putea monta sistemele de fișiere. În sens invers, trebuie să demontăm întâi sistemele de fișiere pentru a putea opri volume pentru a putea în sfârșit a putea deporta grupurile de discuri.

Un părinte este adus online după ce fiecare dintre copii este adus la rândul lui online, și această procedură continuă pâna la vârful arborelui, până când și ultima dintre aplicații pornește. În mod invers, pentru a opri o aplicație, cluster-ul VCS începe să oprească resursele din vârful arborelui.

Avem următoarele categorii de resurse:

– On-Off : Veritas Cluster Server-ul pornește și oprește atunci când este necesar;

– On-Only : VCS-ul pornește aceste resurse, dar nu le și oprește;

– Persistent: Aceste resurse nu pot fi pornite sau oprite. De exemplu, o placă de rețea. O resursă persistentă are o valoare operațională ”None”.

Pentru fiecare resursă în parte, Veritas Cluster Server-ul definește un tip de resursă. De exemplu, putem configura ca tipul resursei placă de rețea să administreze plăcile de rețea. În mod similar, putem configura o adresă de IP folosind tipul resursei adresă de IP. Veritas Cluster Server include un set de tipuri de resurse predefinite. Pentru fiecare tip de resursă, VCS-ul are un agent predefinit care oferă logica ce controlează aceste resurse.

Un grup de servicii este un container virtual care conține toate resursele hardware și software necesare rulării unei aplicații. Grupurile de servicii permit VCS-ului să controleze toate resursele hardware și software ale unei aplicații administrate ca și o singură unitate. Atunci când o mutare a resurselor apare din cauza unei defecțiuni, resursele nu se mută individual, ci întreg grupul de servicii se mută. Dacă avem mai mult de un grup de servicii pe un sistem, mutarea unuia dintre ele nu afectează buna funcționare a celorlalte.

Un singur nod poate găzdui oricâte grupuri de servicii, fiecare dintre ele oferind clienților din rețea funcționarea discretă a aplicațiilor. Dacă acest server cedează, toate grupurile de servicii de pe acesta trebuie mutate în altă parte.

Grupurile de servicii pot fi dependente unul de altul. De exemplu, o aplicație financiară este dependentă de o aplicație bază de date. Deoarece, aplicațiile administrate sunt alcătuite din toate componentele care sunt necesare pentru oferirea serviciului, dependințele între grupurile de servicii crează niste aplicații administrate mai complexe. Atunci când folosim grupuri de servicii dependente între ele, aplicația administrată este întregul arbore al dependințelor.

Grupurile de servicii ale Veritas Cluster Server-ului intră în 3 mari categorii: failover (mutat/basculat), parallel (paralel) și hybrid (hibrid).

Un grup de servicii failover rulează doar pe un singur sistem o dată din cluster-ul respectiv. Grupurile de failover sunt folosite pentru majoritatea aplicațiilor care nu suportă ca datele acestora să fie accesate în mod simultan de mai multe sisteme.

Un grup de servicii paralel rulează pe mai mult de un sistem din același cluster. Acestea sunt mai complexe decât grupurile failover. Grupurile de servicii paralele sunt mai potrivite pentru aplicații care administrează multiple instanțe de programe care merg simultan fără ca să apară coruperi ale datelor.

Grupurile de servicii hibride sunt folosite pentru clustere de date replicate și sunt o combinație între grupurile de servicii failover și paralele. Se comportă ca și un grup de failover în cadrul unei zone de sistem sau ca un grup paralel în cadrul mai multor zone de sistem.

Un grup de servicii hibrid nu se poate muta între mai multe zone de sistem. VCS-ul permite o operație de schimbare a unui grup hibrid doar dacă ambele sisteme sunt în aceeași zonă sistem. Dacă într-o zonă nu există niciun sistem desemnat pentru failover, Veritas Cluster-ul va declanșa alarma ”nofailover” pe nodul cu cel mai mic ID.

Grupul ClusterService este un grup de servicii special care conține resurse necesare comesare componentelor VCS-ului. Grupul conține resurse pentru următoarele item-uri:

– Notificări

– Procesul conector Wide-area (WAC), care este folosit în clusterele globale.

Implicit, grupul ClusterService se poate muta pe orice nod indiferent de restricții, chiar și dacă un nod este înghețat. Grupul ClusterService este primul grup de servicii care pornește la start și nu poate fi inactivat în mod automat. Motorul Veritas Cluster Server descurajează oprirea manuală a acestui grup de către administratorii cluster-ului.

Alt element logic al cluster-ului este UUID-ul. Atunci când instalăm pentru prima dată VCS-ul, programul de instalare generează un identificator universal unic pentru cluster, acesta numindu-se UUID. Valoarea acestuia este aceeași pe orice nod și este definită în atributele ClusterUUID sau CID. Dacă pentru instalare nu folosim programul default, va trebui să rulăm mai târziu utilitarul uuidconfig.pl în așa fel încât să putem seta UUID-ul pentru cluster.

Agenții Veritas Cluster Server-ului sunt niște procese multi-theaded care oferă logica care administrează resursele. VCS-ul are câte un agent pentru fiecare tip de resursă. Agentul monitorizează toate resursele de același tip. De exemplu, un singur agent de IP administrează toate resursele IP.

Atunci când agentul pornește, obține informațiile de configurare necesare de la motorul VCS-ului. Apoi monitorizează periodic resursele și actualizează motorul VCS-ului cu stările resurselor. Agenții care deservesc IMF-ul (Intelligent Monitoring Framework) monitorizează de asemenea resursele asincron. Activând IMF-ul pentru agenții corespounzători stării proceselor și cei ai stării montării sistemelor de fișiere, pot crește performanța cluster-ului atunci când vine vorba de utilizare a resurselor sistemului.

Mai jos putem găsi funcțiile agenților:

– Online: aduce o anume resursă din stare offline în starea online;

– Offline: aduce o anume resursă din starea online în starea offline;

– Monitor: testează statusul unei resurse astfel încât să determine dacă respectiva resursă este online sau pffline. Această funcție rulează la următoarele momente:

În timpul procesului de pornire al primului nod, să verifice și să determine statusul tuturor resurselor din sistem;

După fiecare operațiune de oprire sau pornire;

Periodic ca să verifice resursele sunt și rămân în starea corectă;

De fiecare dată când inițializăm o resursă cu comanda următoare:

#hares –probe res_name –sys system_name

– imf_init: inițializează agentul să interacționeze cu modulul de notificare al IMF;

– imf_getnotification: obține notificări legate de schimbările de stare are resurselor:

– imf_register: înregistrează sau de-înregistrează resursele din modulul de notificări al IMF;

– Clean: curăță după ce o resursă nu poate fi adusă online, sau offline, ori statusul ei nu este ONLINE, deși resursa chiar este ONLINE.

– Action: îndeplinesc diverse acțiuni care pot fi completate în timp scurt și care sunt diferite de acțiunile tradiționale de oprire și pornire;

– Info: obține informații specifice legate de o anumită resursă online.

Topologii de bază ale cluster-ului

În acest subcapitol vom descrie principalele configurații failover, inclusiv pe cea asimetrică, pe cea simetrică și N-to-1.

Într-o configurație asimetrică, o aplicație rulează pe un server primar sau master. Un server dedicat este prezent ca să preia această aplicație în cazul unei defecțiuni. Serverul redundant nu este configurat să îndeplinească nicio altă operațiune. Figura 1.3 reprezintă o mutare în cadrul unei configurații a cluster-ului asimetrică, unde o replicare a unei baze de date este mutată pe serverul redundant.

Figura 1.3

Această configurație este cea mai simplă și cea mai fiabilă. Serverul redundant stă în stand-by pregătit să preia aplicațiile de pe serverul primar în caz de defecțiuni.

În cadrul configurației simetrice fiecare server este configurat ca pe el să ruleze o anumită aplicație sau serviciu și să asigure redundanță pentru aplicația pereche. În exemplul de mai jos, fiecare server găzduiește câte un grup de servicii pentru fiecare aplicație. Când o defecțiune se întâmplă, serverul redundant va găzdui ambele groupuri ale aplicației. In figura 1.4 este ilustrată o astfel de configurație.

Figura 1.4

Configurațiile simetrice sunt mai eficiente din punct de vedere al utilizării hardware. În exemplul configurației asimetrice, serverul redundant necesită la fel de multă putere de procesare ca și perechea sa. Atunci când se întâmplă failover-ul performanța rămâne aceeași. În cazul configurației simetrice, serverul redundant necesită destulă putere de procesare astfel încât să facă față aplicației existente cât și celei pe care o va prelua.

O configurație N-to-1 reduce costurile redundanței hardware livrând încă potențial spațiu dedicat mutării resurselor. În configurația asimetrică nu există nicio penalizare a performanței. Nu există nicio problemă când aplicații multiple rulează pe același sistem, dar minusul aceste configurații este costul. În figura 1.5 este descrisă o configurație N-to-1.

Figura 1.5

O configurație N-to-1 are la bază conceptul că sunt imposibile defecțiuni multiple și simultane pe mai multe servere; de aceea un singur server redundant poate proteja mai multe servere active. Atunci când un server se defectează, aplicațiile sale se mută pe serverul redundant.

Configurații de storage și topologii aferente VCS-ului

Configurația de bază storage partajat este atunci când un singur cluster împart accesul către un echipament de stocare de date, prin intermediul SAN-ului. Putem porni o aplicație pe un nod doar dacă acesta are acces la storage-ul necesar. De exemplu, într-un cluster cu mai multe noduri, orice nod pe care trebuie să ruleze o anumită instanță a unei baze de date trebuie să aibă acces la storage-ul unde se păstrează tabelele, logurile redo, fișierele de control necesare bazei de date. O astfel de arhitectură de discuri partajate este cel mai ușor de implementat și menținut. În figura 1.6 avem un exemplu de o arhitectură de discuri partajată pentru un cluster de bază.

Figura 1.6

Într-o configurație de tip campus cluster cu storage partajat, putem folosi VCS-ul și managerul de volume Veritas pentru a crea un cluster ce se poate întinde pe mai multe centre de date sau clădiri. În locul folosirii unui singur array de stocare a datelor, acestea vor fi ținute în oglindă pe două array-uri cu ajutorul managerului de volume Veritas. Această configurație oferă copii sincronizate ale datelor în ambele situri. Această procedură este identică cu cea a copierii datelor între două array-uri din același datacenter, numai că de data asta aceste array-uri sunt despărțite de o distanță considerabilă.

Clusterele de date replicate nu conțin discuri partajate. În schimb, un produs de replicare al datelor sincronizează copii ale datelor între cele două noduri. Replicarea poate avea loc la nivel de aplicație, de server sau de storage. Ca și exemple de produse care sincronizează la nivel de aplicație se găsește Oracle DataGuard. La nivel de sistem putem folosi Replicatorul de Volume Veritas, iar la nivel de storage toată această sincronizare a datelor se întâmplă în spate pe sistemele de stocare de date la nivel de RAID LUN-uri si discuri.

În figura 1.7 avem descris un cluster hibrid cu storage partajat și cluster de date în care avem priorități diferite împărțite pe noduri în funcție de un anumit grup de servicii.

Figura 1.7

Clusterele globale leagă clustere aflate în locații diferite și activează circuitele wide-are pentru mutarea diverselor resurse cât și pentru revenirea din situații de calamități sau forță majoră (disater recovery).

Clustering-ul local asigură redundanța locală pentru fiecare site sau clădire. Configurațiile cluster-ului de date replicate oferă protecție împotriva situațiilor grave care afectează zone geografice limitate. Dezastrele la scară mare gen inundații majore, uragane și cutremurele pot provoca întreruperi are serviciilor pentru un întreg oraș sau regiune. În astfel de situații putem asigura dispoziția datelor prin migrarea aplicațiilor către situri localizate la distanțe mari față de locul dezastrelor.

Figura 1.8

Capitolul 2 Instalarea mediului de test Veritas Cluster Server

În subcapitolele ce urmează vom prezenta elementele ce alcătuiesc mediul de test Veritas Cluster Server. Environment-ul de test va conține 4 servere mașini virtuale: un server SuSe Linux ce va prezenta LUN-uri de test prin ISCSI către clusterul Veritas, un server Red Hat Linux ce va avea rol de NFS sharing server și 2 servere instalate cu Linux Red Hat, ele reprezentând cele două noduri ce vor face parte din Cluster Veritas.

2.1 Instalare server SuSe Linux

Ca și sistem de operare vom alege pentru acest server openSUSE versiunea 13.1

Figura 2.1

Întregul mediu de test a fost gândit și configurat ca un mediu virtual format din mașini virtuale instalate pe platforma VMware Workstation.

Pentru început prin intermediul VMware Workstation creăm un nou container virtual în care specificăm resursele hardware pe care dorim să le aibă serverul de ISCSI. Vom alege pentru acest server următoarea configurație: 2 procesoare, 768 MB RAM, 3 hard disk-uri a câte 20 GB, 1 GB și respectiv 1 GB, un CD/DVD, o placă de rețea configurată în modul ”bridged”.

Figura 2.2

Pentru a putea porni instalarea serverului SuSe Linux, vom monta în unitatea virtuala CD/DVD imaginea de instalare a sistemului de operare și restartăm mașina virtuală. După testul de pornire (POST test – power-on self test) meniul aferent ecranului de boot apare. Folosind tastele de direcție selectăm opțiunea ”Installation” și apăsăm tasta enter.

Figura 2.3

Va începe încărcarea kernel-ului în memorie și ar putea apărea și câteva mesaje de diagnoză. De obicei acestea pot fi ignorate atâta timp cât procesul de instalare a pornit și decurge fără nico problemă.

Urmează pe rând ecranele de ”Bun venit”, ”Mod de instalare”, ”Ora și Fus Orar” și ”Selecție Desktop”. Toate aceste ecrane vor fi parcurse cu facil facând click pe butonul ”Next” atât timp cât avem de a face cu o instalare absolut nouă.

Următorul ecran va fi cel corespunzător partiționării disk-urilor. În mod implicit, programul de instalare va sugera un anumit mod de partiționare. Această partiționare trebuie făcută cu mare atenție atunci când selectăm disk-urile și le partiționăm. Pierderea anumitor date pe aceste disk-uri în caz că ele există este permanentă.

”Create LVM Based Proposal” va crea un Linux Volume Manager grup pentru instalarea open SUSE. Aceasta ne va ajuta să modificăm mărimea, să mutăm sau să adăugăm disk-uri la un volum mult mai ușor. Dacă aceste opțiuni nu sunt importante pentru instalarea noastră, nu vom bifa această opțoine.

”Encrypt Volume Group” – această opțiune necesită crearea unui volum și va cripta toate datele de pe el cu o parolă care trebui introdusă atunci când serverul pornește. Fără această parola, toate datele vor inaccesibile.

”Propose Separate Home Partition” va păstra fișierele personale (/home) pe o partiție diferită de cea pe care va fi instalat sistemul de operare openSUSE. Acesta va conține majoritatea fișierelor utilizatorilor cât și a setărilor personale chiar dacă partiția principală root(/) va fi ștearsă.

”Use Btrfs as Default File System” folosește noul sistem de fișiere Btrfs, care are mai multe opțiuni ca și sistemul de fișiere ext4. Acesta este încă în perioada de dezvoltare așa că majoritatea utilizatorilor aleg să folosească ext4.

”Enlarge Swap for Suspend” redimensionează partiția de swap a disk-ului în așa fel încât să permită stocarea conținutului memoriei RAM pe disk. Aceasta permite serverului să salveze sesiunea curentă și să fie oprit complet. Această opțiune este asemănătoare celei de ”Hibernate” din sistemul de operare Windows. Folosind acest feature este posibil ca spațiul de stocare al disk-urilor să scadă.

Selectând opțiunea ”Create Partition Setup” ne va ghida prin procesur creării unei partiții necesare instalării openSUSE.

”Edit Partition Setup” va deschide opțiunea Partiționării ăn modul expert unde instalarea poate fi customizată pentru cazul nostru particular.

Vom crea o partiție de 20GB ce ne va servi instalării sistemului de operare plus încă două de câte 2 GB ce ne vor servi ca și spațiu de stocare pentru LUN-urile oferite Veritas Cluster-ului. Ca manager de disk-uri vom volosi LVM-ul și vom crea un volum logic pentru /home utilizatorilor, un volum logic pentru sistemul de fișiere root, un volum logic pentru memoria swap și două volume logice pentru LUN-urile de ISCSI.

Toate acestea vor fi grupate în două grupuri de volume: system și vgiscsi, acestea fiind create pe partițiile mai sus create /dev/sda2, /dev/sdb/ și /dev/sdc.

Figura 2.4 afișează meniul de partiționare, iar Figura 2.5 afișează structura de managerului de volume logice (LVM) și cea de partiționare de pe serverul de ISCSI openSUSE Linux.

Figura 2.4

Figura 2.5

Softul de instalare va începe partiționarea disk-urilor și instalarea openSUSE pe drive-ul specificat de către noi. Acest proces va dura câteva minute. Veți putea urmări statusul instalării în bara de progres.

2.2 Instalare server Red Hat pentru NFS sharing

Creăm un nou container virtual în care specificăm resursele hardware pe care dorim să le aibă serverul de ISCSI. Vom alege pentru acest server următoarea configurație: 2 procesoare, 512 MB RAM, 2 hard disk-uri a câte 32 GB si 2 GB, un CD/DVD, o placă de rețea configurată în modul ”bridged”.

Ca și sistem de operare vom alege Red Hat Enterprise Linux Server 6.5 (Santiago). Pentru a putea porni instalarea serverului de NFS, vom monta în unitatea virtuala CD/DVD imaginea de instalare a sistemului de operare și restartăm mașina virtuală.

După ce sistemul a trecut POST-ul se va afișa pe ecran meniul grafic de boot cu mai multe opțiuni. Dacă nu apăsăm nicio tastă timp de 60 secunde, programul de instalare va folosi opțiunea default.

Figura 2.6

Opțiunile de boot sunt următoarele:

”Install or upgrade an existing system” – aceasta este opțiunea default. În mod normal vom alege această opțiune pentru instalarea serverului nostru folosind interfața grafică de instalare.

”Install system with basic video driver” – această opțiune ne permite instalarea Red Hat Linux în interfață grafică chiar dacă programul de instalare nu poate încărca driver-ul corect al plăcii video.

”Rescue installed system” – alegem această opțiune pentru a repara orice anomalie ce nu permite pornirea corectă a unui server Linux. Mediul de salvare (rescue) conține utilitare care ne permit repararea unei game largi de probleme.

”Boot from loca drive” – această opțiune pornește serverul de pe primul disk instalat.

Urmează câteva meniuri prin care vom seta limba sistemului de operare, fusul orar, data si ora și bineînțeles partiționarea disk-urilor interne. La fel ca și în subcapitolul anterior acest pas necesită cea mai mare atenție din partea noastră. Mai jos în Figura 2.7 avem ca exemplu meniul de partiționare in Red Hat Linux.

Figura 2.7

La fel ca și pe serverul openSUSE vom folosi LVM-ul și vom crea sisteme de fișiere diferite pentru /home, /opt/, /var/ și /tmp. Softul de instalare va începe partiționarea disk-urilor și instalarea Red Hat Linux pe drive-ul specificat de către noi. Acest proces va dura câteva minute. Veți putea urmări statusul instalării în bara de progres.

2.3 Instalarea nodurilor din Veritas Cluster

Pentru Veritas Cluster vom folosi doua mașini virtuale instalate cu Red Hat Linux 5.10 (Tikanga). Instalarea sistemelor de operare pentru cele două servere se face în același fel ca în subcapitolul 2.2 pentru serverul de NFS sharing.

Înaintea începerii instalării softului de cluster vom crea cele două containere virtuale cu următoarele specificații tehnice: 4 procesoare, 1 GB memorie RAM, 1 hard disk de 32 GB si 4 hard disk-uri de câte 1 GB și două plăci de rețea configurate în modul bridged.

Pentru a putea porni instalarea nodurilor Veritas Cluster-ului, vom monta în unitatea virtuala CD/DVD imaginea de instalare a sistemului de operare și restartăm mașinile virtuale.

După ce sistemele au trecut POST-ul se va afișa pe ecran meniul grafic de boot cu mai multe opțiuni. Dacă nu apăsăm nicio tastă timp de 60 secunde, programul de instalare va folosi opțiunea default. Urmează câteva meniuri prin care vom seta limba sistemului de operare, fusul orar, data si ora și bineînțeles partiționarea disk-urilor interne. La fel ca și în subcapitolul anterior acest pas necesită cea mai mare atenție din partea noastră.

La fel ca și pe serverul openSUSE, sau serverul de NFS sharing vom folosi LVM-ul și vom crea sisteme de fișiere necesare pentru instalarea sistemelor de operare. De obicei procesul de instalare pe sisteme noi decurge fără probleme și nu ar trebui să dureze mai mult de câteva zeci de minute.

Înainte de putea porni instalarea cluster-ului de Veritas este necesar ca să configurăm o rețea privată între cele două noduri care formează sistemul de cluster. În figura 2.8 se observă rolul rețelei private pentru acest cluster, și anume acela de veghea la status online sau offline al membrilor cluster-ului.

Figura 2.8

În situațiile productive este recomandabil să fie configurate 2 rețele independente între membrii cluster-ului cu un switch prezent pentru fiecare rețea în parte. Se pot interconecta de asemenea multipe switch-uri de layer 2 pentru o mai bună protecție.

Pașii configurării rețelei private:

Instalarea plăcilor de rețea (NICs) – în cazul nostru acestea sunt niște interfețe virtuale pentru că lucram într-un mediu de test virtual;

Conectarea NIC-urilor private pe fiecare dintre membrii cluster-ului;

Asignăm temporar niște adrese IP acestor plăci de rețea și verificăm conexiunea între noduri cu telnet sau ping. Aceste interfețe sunt folosite doar pentru LLT (Low Latency Transport), acesta fiind un protocol special folosit pentru comunciarea între serverele ce rulează software-ul de Veritas Cluster. Deci pe aceste canale de comunicare nu se folosește protocolul TCP/IP, și din această cauză trebuie să ne asigurăm că pe ele nu se face trafic TCP/IP.

Capitolul 3 Pregătirea și configurarea elementelor cluster-ului

Pentru a putea pune în scenă acest mediu de test cu Cluster de Veritas va trebui să configurăm serverul openSUSE în așa fel încât el va livra LUN-urile de storage cluster-ului nostru, va trebui să creăm și să oferim spre share un sistem de fișiere de pe serverul de NFS, iar mai apoi pe cele două noduri să instalăm și să configurăm software-ul de Veritas Cluster.

3.1 Crearea și oferirea spațiului de stocare pentru Veritas Cluster

Pentru a configura țintele ISCSI (ISCSI targets), adică LUN-urile de spațiu de stocare pentru a fi prezentate către Veritas Cluster, vom rula pe serverul openSUSE linux-ko34 utilitarul iSCSI Target. Configurația este împărțită în 3 tab-uri. În tab-ul ”Service” trebuie să selectăm modul start și setările de firewall. Din cauză că va trebui să permitem accesul la aceste LUN-uri de pe un sistem cluster remote vom selecta ”Open Port in Firewall”.

Tab-ul ”Global” conține setările pentru serverul de iSCSI. Autentificarea de aici este folosită pentru descoperirea serviciilor, și nu pentru accesarea LUN-urilor țintă. Dacă nu dorim restricționarea accesului, folosim ”No Authentication”. În cazul nostru vom folosi această opțiune.

LUN-urile țintă sunt definite în tab-ul ”Targets”. Ca să creăm un nou LUN iSCSI țintă folosim ”Add”. În prima căsuță de dialog ne vor fi cerute informații despre device-ul care va fi exportat. Sintaxa pentru definirea LUN-ului exportat este de forma:

iqn.yyyy-mm.<nume domeniu inversat>:id_unic

Unde, iqn.yyyy-mm este formatul datei la care LUN-ul țintă a fost activat. După adăugarea target-ului va trebui să introducem și calea spre block device sau către sistemul de fișiere pe care vrem să îl exportăm.

Pentru a crea un nou device țintă urmăm umrătorii pași:

Pornim utilitarul YaST.

Selectăm Network Services > iSCSI Target.

În dreptul opțiunii ”Service Start” selectăm ”When booting”, adică la pornirea serverului.

Deschidem porturile din firewall pentru a permite accesul la server de la serverele care fac parte din clusterul de Veritas. Trebuie specificat aici de asemenea interfața de rețea pe care vrem să deschidem porturile respective.

Configurăm device-urile țintă:

Selectăm tab-ul ”Targets”.

Facem click pe ”Add” pentru a adăuga un nou device.

În tab-ul ”Service” facem click pe Save pentru a exporta configurația făcută într-un fișier.

Facem Click pe ”Finish” pentru a crea device-urile.

În Figura 3.1 sunt ilustrate LUN-urile exportate de către serverul nostru openSUSE.

Figura 3.1 LUN-uri exportate către Veritas Cluster Server

Toți pașii de mai sus se pot efectua și manual din linie de comandă, dar nu reprezintă scopul acestui subcapitol.

3.2 Configurare NFS server

Pentru instalarea și configurarea serverului de NFS trebuie mai întâi să instalăm pachetele de NFS.

yum install nfs-utils nfs-utils-lib

yum install portmap

După instalarea acestor pachete, trebuie pornite serviciile de mai sus:

/etc/init.d/portmap start

/etc/init.d/nfs start

chkconfig – -level 35 portmap on

chkconfig – -level 35 nfs on

Există 3 posibilitați de configurare a unui NFS server: folosind tool-ul de configurare NFS Server (redhat-config-nfs), editarea manuală a fișierelor de configurare (/etc/exports), sau folosind comanda /usr/sbin/exportfs.

Pentru serverul din cadrul proiectului, nfs-server, am folosit metoda editării manuale a fișierelor de configurare.

Pentru început, am configurat placa de rețea cu adresă de IP din aceeși clasă de rețea ca și serverul de iSCSI și Veritas Cluster Server. Vom configura pe acest server adresa de IP 192.168.1.102. Pentru a păstra setările de rețea permanente vom edita și salva fișsierul /etc/sysconfig/network-scripts/ifcfg-eth0:

DEVICE=”eth0”

BOOTPROTO=”none”

HWADDR=”00:0C:29:A8:B7:EF”

IPV6INIT=”no”

ONBOOT=”yes”

TYPE=”Ethernet”

UUID=”7fcdeac4-1a40-4ffc-a79d-bda66dfd0eab”

IPADDR=192.168.1.102

NETMASK=255.255.255.0

GATEWAY=192.168.1.1

Fișierul /etc/exports conține sistemele de fișiere care vor fi exportate către serverele remote cât și opțiuni specifice. Liniile goale sunt ignorate, comentariile pot fi făcute începând linia cu (#). Fiecare sistem de fișiere ar trebui să fie pus pe o singură linie, și lista de servere autorizate să acceseze share-urile NFS trebuiesc despărțite cu câte un spațiu.. O linie pentru un sistem de fișiere exportat este de următoarea formă:

<export> <host1> (<options>) <hostN> (<options>) . . .

Luând exemplul de mai sus trebuie să înlocuim <export> cu directorul pe care vrem să îl exportăm, <host1> cu numele serverului sau rețeaua pentru care oferim accesul spre share, iar <options> îl înlocuim cu opțiunile pe care le dorim.

În cazul serverului nostru de NFS vom adăuga în /etc/exports următoarele sisteme de fișiere:

/home 192.168.1.0/24(rw)

/home2 192.168.1.0/24(rw)

După cum am văzut mai sus, vom exporta directoarele /home și /home2 către întreaga rețea 192.168.1.0 cu netmask 255.255.255.0 și cu opțiunea rw, care va permite clienților ce montează aceste share-uri să scrie și să citească de pe respectivele sisteme de fișiere.

Mai există și alte opțiuni pe care le putem folosi atunci când exportăm share-uri prin intermediul unui server de NFS:

ro: cu această opțiune oferim doar dreptul de citire pe respectivul sistem de fișiere.

sync: sync-ul confirmă cererile către directorul împărțit doar după ce schimbările au fost implementate.

no_subtree_check: această opțiune previne verificarea sub-arborelui. Când un director share-uit este de fapt un subdirector al unui sistem de fișiere mai mare, nfs-ul va scana fiecare director de deasupra directorului nostru.

no_root_squash: permite conectarea root-ului în directorul respectiv.

În Figura 3.2 este ilustrată configurația de pe serverul NFS din cadrul proiectului nostru.

Figura 3.2 Configurația plăcii de rețea și a serverului de NFS

3.3 Pregătirea instalării Veritas Cluster Server

Veritas Cluster-ul este format din două servere Red Hat Enterprise Linux Server 5.10 (Tikanga): veritas1 și veritas2.

Există mai multe metode de instalare a Veritas Cluster Server:

Instalarea interactivă folosind scriptul de instalare – putem folosi ori programul de instalare oferit de Veritas pentru a instala diverse produse, sau putem folosi scriptul installvcs pentru a instala doar Veritas Cluster Server.

Instalare interactivă folosind interfața web – putem folosi o interfață web prin intermediul căreia instalăm și configurăm VCS-ul.

Instalare automată folosind fișierele de răspuns VCS – aceste fișiere răspuns conțin toate informațiile necesare pentru ca Veritas Cluster-ul să se instaleze în mod automat.

Instalare manuală folosind comenzile și utilitarele din Linux – putem instala VCS-ul folosind comenzi din Linux (rpm –i) și apoi configurând manual Veritas Cluster Server-ul.

În subcapitolul 2.3 am dezbătut necesitate configurării unei rețele private între cele două noduri înainte de a da drumul instalării propriu-zise a Veritas Cluster-ului. În situațiile productive este recomandabil să fie configurate 2 rețele independente între membrii cluster-ului cu un switch prezent pentru fiecare rețea în parte. Se pot interconecta de asemenea multipe switch-uri de layer 2 pentru o mai bună protecție.

Pe lângă această rețea privată, trebuiesc configurate de asemenea și restul de interfețe de rețea de pe cei doi membri ai cluster-ului. În figurile 3.3 și 3.4 sunt ilustrate configurațiile plăcilor de rețea de pe cei doi membri ai cluster-ului.

Figura 3.3 Configurație rețea pe serverul veritas1

Figura 3.4 Configurație rețea pe serverul veritas2

Pentru a obține aceste configurări de rețea va trebui să edităm fișierele de configurare următoare, pe cele două servere.

[root@veritas1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0

# Intel Corporation 82545EM Gigabit Ethernet Controller (Copper)

DEVICE=eth0

BOOTPROTO=static

BROADCAST=192.168.1.255

HWADDR=00:0C:29:4D:3A:29

IPADDR=192.168.1.51

NETMASK=255.255.255.0

NETWORK=192.168.1.0

ONBOOT=yes

[root@veritas1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1

# Intel Corporation 82545EM Gigabit Ethernet Controller (Copper)

DEVICE=eth1

BOOTPROTO=none

ONBOOT=yes

IPADDR=192.168.1.53

NETMASK=255.255.255.0

HWADDR=00:0c:29:4d:3a:33

[root@veritas2 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0

# Intel Corporation 82545EM Gigabit Ethernet Controller (Copper)

DEVICE=eth0

BOOTPROTO=static

BROADCAST=192.168.1.255

IPADDR=192.168.1.52

NETMASK=255.255.255.0

NETWORK=192.168.1.0

ONBOOT=yes

[root@veritas2 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1

# Intel Corporation 82545EM Gigabit Ethernet Controller (Copper)

DEVICE=eth1

BOOTPROTO=none

ONBOOT=yes

IPADDR=192.168.1.54

NETMASK=255.255.255.0

HWADDR=00:0c:29:04:07:e0

După ce configurăm persistent plăcile de rețea va trebui să declarăm numele serverelor în fișierul /etc/hosts.

[root@veritas1 ~]# cat /etc/hosts

# Do not remove the following line, or various programs

# that require network functionality will fail.

127.0.0.1 localhost.localdomain localhost

::1 localhost6.localdomain6 localhost6

192.168.1.51 veritas1

192.168.1.52 veritas2

De asemenea pe fiecare dintre cele două mașini virtuale va trebui să configurăm default gateway-ul, punctul prin care se ruteaza pachetele.

[root@veritas1 ~]# cat /etc/sysconfig/network

NETWORKING=yes

NETWORKING_IPV6=no

HOSTNAME=veritas1

GATEWAY=192.168.1.1

[root@veritas2 ~]# cat /etc/sysconfig/network

NETWORKING=yes

NETWORKING_IPV6=no

HOSTNAME=veritas2

GATEWAY=192.168.1.1

Veritas Cluster Server necesită ca interfețele de rețea să folosească același nume tot timpul. De obicei incepând cu SLES10 și RHEL 5, versiunile de Linux folosesc udev pentru a avea nume persistente pentru interfețele de rețea.

Programul de instalare folosește ssh sau shell-ul remote (rsh) între membrii cluster-ului. În timpul instalării, alegi tipul de protocol dorit. Apoi trebuie introdusă parola de root pentru sistemul pe care facem instalarea.

Comenzile de instalare cât și alte comenzi se află în directorul /opt/VRTS/bin. Acest director va trebui adăugat ca și variabilă de mediu PATH. Dacă vom crea scripturi personalizate în directorul /opt/VRTSvcs/bin, atunci va trebui adăugat și acesta în PATH-ul global. Pentru a seta vairabila PATH putem folosi următoarele comenzi, depinzând de shell-ul folosit:

Pentru Bourne shell (sh), bash, ksh (Korn shell):

# PATH=/opt/VRTS/bin:$PATH; export PATH

Pentru C Shell (csh) sau tcsh:

$ setenv PATH :/opt/VRTS/bin:$PATH

De asemena pentru a putea folosi paginile de manual pentru comenzi, va trebui să setăm și variabila MANPATH. La fel ca și pentru variabila PATH în funcție de shell-ul pe care îl folosim, vom avea următoarele posibilități de a seta această variabilă:

Pentru sh,bash sau ksh:

# MANPATH=/opt/VRTS/man:$MANPATH; export MANPATH

Pentru csh sau tcsh:

% setenv MANPATH /usr/share/man:/opt/VRTS/man

După ce am setat cele două variabile de mediu, va trebui să modificăm și parametrul de kernel kernel.panic. Implicit, kernel.panic este setat pe 0, adică, dacă un nod intră în modul panică, acesta nu se resetează. Pentru a ne asigura că nodul se resetează automat în caz de panică, acest parametru va trebui configurat cu o valoare diferită de 0. Trebuie urmați pașii următori:

Setăm parametrul kernel.panic cu valoarea dorită în fișierul /etc/sysctl.conf.

Rulăm comanda:

sysctl –w kernel.panic=10 – în caz de panică, nodul se va reseta după 10 secunde.

Urmează acum optimizarea comunicării prin protocolul LLT între nodurile cluster-ului. Plăcile de rețea pe fiecare nod vor trebui configurate cu aceeași viteză. De asemenea setările folosite pe switch-urile care deservesc comunicarea LLT trebuie să fie la fel cu cele de pe plăcile de rețea.

3.4 Instalarea Veritas Cluster Server

Pentru a putea instala VCS-ul va trebui să avem drepturi de root pe noduri. Vom urma pașii următori:

Ne conectăm ca și root pe nodul pe care vrem să instalăm VCS-ul. Acest nod va trebui să facă parte din cluster, iar cei doi membri trebuie să se afle în același subnet.

Montăm ISO-ul produsului în unitatea virtuală DVD a serverului nostru și îl facem disponibil pe server:

mkdir /mnt/cdrom

mount –o ro /dev/cdrom /mnt/cdrom

Navigăm în locația care conține RPM-urile necesare instalării.

#cd /mnt/cdrom/dist_arch/rpms

Înainte de a porni instalarea propriu-zisă, putem verifica stare membrilor clusterului, pentru a fi siguri că îndeplinesc condițiile necesare Veritas Cluster Server.

installvcs –precheck veritas1 veritas2

Pornim instalarea propriu-zisă:

Navigăm în locația care conține scriptul installvcs.

# cd cdrom_root/rhel5_x86_64/cluster_server

Pornim programul de instalare

#./installvcs

Alegem RPM-urile pe care vrem să le instalăm. În cazul nostru am ales, RPM-urile minime necesare, cele care oferă funcționalitățile de bază ale VCS-ului.

Introducem numele sistemelor pe care vrem să instalăm produsul:

Enter the 64 bit operating system system names separated by spaces:

[q,?] veritas1 veritas2

Reanalizăm lista de RPM-uri care vor fi instalate pe fiecare dintre cele două noduri.

Va trebui să introducem tipul de licență folosit. În cazul nostru vom folosi licența de încercare gratuită.

1) Enter a valid license key

2) Enable keyless licensing and complete system licensing later

How would you like to license the systems? [1-2,q]

Pentru a porni instalarea ”Global Cluster Option” introducem ”y” la prompt.

Configurarea VCS-ului o vom face mai târziu.

Would you like to configure VCS on sys1 sys2 [y,n,q] (n) n

3.5 Configurarea I/O fencing pentru integritatea datelor

I/O fencing este un mecanism care previne accesul necoordonat la storage-ul folosit în comun de către membrii clusterului. Această caracteristică funcționează chiar dacă comunicarea între noduri devine dificitară cauzând condiția de ”split-brain”.

Pentru a oferi disponibilitate maximă în termeni de oferire de servicii, cluster-ul trebuie să fie capabil să acționeze corect atunci când unul dintre noduri se defectează. În modul de operare normal al Veritas Cluster Server, nodurile vor avea conexiunea de test privată (așa numita heart beat) și fiecare dintre ele va trimite pachete ICMP ca să se asigure că fiecare dintre nodurile din cluster sunt online iar grupurile de servicii sunt online.

Figura 3.5 Modul de operare normal al Veritas Cluster Server

I/O fencing-ul se comportă în aelași fel ca și în cazul conexiunilor heart beat. Singura diferență este că va căuta confirmarea defecțiunii de la disk-urile de coordonare. Nodurile care au fost scoase din cluster nu vor mai putea accesa diskurile cu date până când defecțiunea nu a fost reparată și vor reveni în GAB, iar grupurile de servicii vor fi re-pornite pe ele.

În cazul funcționării pe bază de heart beat, o dată ce această comunicare a fost oprită, VCS-ul va iniția grupul de servicii pe mașina care funcționează corect.

Figura 3.6 Defecțiunea unui dintre noduri și preluarea sarcinilor de către cel funcțional

Deși în cazul nostru configurarea I/O fencing nu a fost posibilă din cauza mediului virtual de test configurat, vom prezenta mai jos o posibilitate de configurare a acestuia în mediu productiv cu echipamente fizice și storage dedicat.

Inițializăm disk-urile pentru I/O fencing. Minimul de disk-uri necesare pentru acest feature este 3. Vom folosi 3 disk-uri a cate 500 MB fiecare pentru un cluster cu 2 noduri.

# vxdisk -eo alldgs list

# vxdisksetup -i disck01

# vxdisksetup -i disck02

# vxdisksetup -i disck03

Va trebui să cream un grup de disk-uri pentru fencing:

# vxdg -o coordinator=on init fendg disk01

# vxdg -g fendg adddisk disck02

# vxdg -g fendg adddisk disck03

Creăm fișierul de configurare în /etc/vxfendg

# vxdg deport vxfendg

# vxdg -t import fendg

# vxdg deport fendg

# echo "fendg" > /etc/vxfendg (pe ambele noduri)

Activăm fencing-ul pe ambele noduri

# haconf -dump -makero

# hastop -all

# /etc/init.d/vxfen stop

# vi /etc/VRTSvcs/conf/config/main.cf ( adăugăm intrarea SCSI3)

cluster geekdiary (

UserNames = { admin = "ass76asishmHajsh9S." }

Administrators = { admin }

HacliUserLevel = COMMANDROOT

CounterInterval = 5

UseFence = SCSI3

)

# hacf -verify /etc/VRTSvcs/conf/config

# cp /etc/vxfen.d/vxfenmode_scsi3_dmp /etc/vxfenmode (în cazul în care folosim dmp-ul )

Pornim fencing-ul

# /etc/init.d/vxfen start

# /opt/VRTS/bin/hastart

Testarea fencing-ului

# vxfenadm -d

Fencing Protocol Version: 201

Fencing Mode: SCSI3

Fencing Mechanism: dmp

Cluster Members:

* 0 (node01)

1 (node02)

RSM State Information

node 0 in state 8 (running)

node 1 in state 8 (running)

Verificăm starea porturilor GAB (Group membership and atomic broadcast)

# gabconfig -a

GAB Port Memberships

==================================

Port a gen 24ec04 membership 01

Port b gen 24ec07 membership 01

Port h gen 24ec08 membership 01

Verificăm fișierele de configurare

# grep SCSI3 /etc/VRTSvcs/conf/config/main.cf

UseFence = SCSI3

# cat /etc/vxfenmode

…

vxfen_mode=scsi3

…

scsi3_disk_policy=dmp

# cat /etc/vxfendg

fendg

cat /etc/vxfentab

…

/dev/vx/rdmp/emc_dsck01

/dev/vx/rdmp/emc_dsck02

/dev/vx/rdmp/emc_dsck03

Verificăm cheile de rezervare pentru SCSI pe toate discurile de coordonare. În cazul de față având 2 noduri cu 2 căi pe fiecare disk, ar trebui săa vem 4 chei pe disk

# vxfenadm -s all -f /etc/vxfentab

Reading SCSI Registration Keys…

Device Name: /dev/vx/rdmp/emc_dsc01 Total Number Of Keys: 4

key[0]:

[Numeric Format]: 33,75,93,79,22,29,17,66

[Character Format]: VF000701

* [Node Format]: Cluster ID: 5 Node ID: 1 Node Name: node02

key[1]:

[Numeric Format]: 33,75,93,79,22,29,17,66 [Character Format]: VF0000701

* [Node Format]: Cluster ID: 5 Node ID: 1 Node Name: node02

key[2]:

[Numeric Format]: 33,75,93,79,22,29,17,66 [Character Format]: VF0000700

* [Node Format]: Cluster ID: 5 Node ID: 0 Node Name: node01

key[3]:

[Numeric Format]: 33,75,93,79,22,29,17,66 [Character Format]: VF0000700

* [Node Format]: Cluster ID: 5 Node ID: 0 Node Name: node01

Figura 3.7 Algoritmul de configurare al I/O fencing

3.6 Configurarea Veritas Cluster Server-ului

Putem configura Veritas Cluster Server-ul fie folosind installer-ul produsului, sau folosind comanda installvcs.

În cazul nostru am folosit prima opțiune. Ne conectăm pe nod ca și root și navigăm în directorul ce conține pachetele de instalare. Următorii pași reprezintă startul configurării VCS-ului:

# ./installer – această comandă pornește programul de instalare în timp ce specifică directorul unde fișierele cu loguri se salvează.

Din meniul de selecție alegem (c) pentru ”Configurarea unui produs deja instalat”.

Din lista de produse alegem VCS-ul

Installer-ul ne va cere numele membrilor cluster-ului pe care vrem să configurăm VCS-ul și acesta va începe o verificare inițială pe sistemele sepcificate de noi.

Enter the operating_system system names separated

by spaces: [q,?] (sys1) veritas1 veritas2

Revizuiți și verificați output-ul oferit de către installer atunci când analizează sistemele membru ale clusterului.

Introducem un nume unic pentru clusterul nostru.

Enter the unique cluster name: [q,?] alex

La acest moment va trebui să configurăm link-urile de heartbeat pe care le folosește LLT-ul. VCS-ul oferă posibilitatea de a folosi protocolul LLT pe Ethernet sau pe UDP (User Datagram Protocol). Recomandabil este să folosim LLT pe Ethernet din motive de performanță și să folosim UDP-ul doar din motive de hardware.

În cazul proiectului nostru am ales folosirea LLT peste Ethernet, așa că atunci când installer-ul ne-a cerut să specificăm ce vrem să folosim, am ales LLT over Ethernet. În continuare va trebui să introducem detaliile pentru link-ul de heartbeat. Vom alege interfețele de rețea private, pe cele care le-am configurat anterior.

Enter the NIC for the first private heartbeat link on veritas1:

[b,q,?] eth1

eth1 has an IP address configured on it. It could be a

public NIC on veritas1.

Are you sure you want to use eth1 for the first private

heartbeat link? [y,n,q,b,?] (n) y

Would you like to configure a second private heartbeat link?

[y,n,q,b,?] (n)

Enter the NIC for the first private heartbeat link on veritas2:

[b,q,?] eth1

eth1 has an IP address configured on it. It could be a

public NIC on veritas2.

Are you sure you want to use eth1 for the first private

heartbeat link? [y,n,q,b,?] (n) y

Would you like to configure a second private heartbeat link?

[y,n,q,b,?] (n)

Do you want to configure an additional low priority heartbeat

link? [y,n,q,b,?] (n)

În continuare configurăm adresa IP virtuală pentru întreg cluster-ul. Aceasta poate fi folosită pentru conectarea prin intermediul Cluster Manager (Java Console) sau Veritas Operation Manager (VOM) la cluster. În cazul nostru de studiu, vom instala și folosi VOM-ul.

Când installer-ul ne va întreba dacă dorim configurarea IP-ului virtual al cluster-ului vom răspunde cu opțiunea (y). În mod automat acesta va descoperi interfețele atașsate serverului nostru și ne va întreba dacă dorim să le folosim pe acestea.

Dacă interfața descoperită este cea pe care vrem să o folosim, apăsăm ENTER.

Dacă dorim să folosim altă interfață, introducem numele acesteia și apăsăm ENTER.

Active NIC devices discovered on veritas1: eth0

Enter the NIC for Virtual IP of the Cluster to use on veritas1:

[b,q,?](eth0)

Confirmăm dacă vrem să folosim aceeși interfață publică pe toate nodurile.

Is eth0 to be the public NIC used by all systems

[y,n,q,b,?] (y)

Introducem adresa IP virtuală pentru cluster. Putem folosi o adresă IPv4 sau una IPv6. În cazul nostru vom folosi una de tipul IPv4.

Enter the Virtual IP address for the Cluster:

[b,q,?] 192.168.1.55

Enter the netmask for IP 192.168.1.55: [b,q,?]

(255.255.255.0)

Cluster Virtual IP verification:

NIC: eth0

IP: 192.168.1.55

Netmask: 255.255.255.0

Is this information correct? [y,n,q] (y)

După ce introducem toate informațiile cerute pentru configurare, installer-ul ne intreabă dacă poate opri toate procesele pentru a finaliza configurarea. Confirmăm oprirea, iar programul de instalare continuă să creeze și să copieze fișierele de configurare pe ambele noduri din cluster. De asemenea installer-ul configureaza un UUID unic pentru cluster la finalul configurării.

După ce programul de instalare termină cu succes configurarea, va restarta Vertias Cluster Server-ul împreună cu toate procesele sale aferente.

Do you want to stop VCS processes now? [y,n,q,?] (y)

Would you like to send the information about this installation

to Symantec to help improve installation in the future?

[y,n,q,?] (y) y

3.7 Instalarea Veritas Operations Manager (VOM)

Veritas Operations Manager ne oferă o consolă de management centralizată pentru produsele de software din familiile Storage Foundation și High Availability. Îl putem folosi pentru monitorizarea, vizualizarea și administrarea resurselor de storage și pentru a genera rapoarte pentru acestea. Cu ajutorul VOM putem administra central diferite centre de date.

O topologie tipică de VOM conține serverul de management și host-urile care sunt administrate. Acestea pot fi instalate pe orice sistem de operare care este suportat de VOM. Serverul de management primește informații despre toate resursele din domeniul său. Când ne conectăm pe management server, primim acces asupra tuturor resurselor de pe serverele administrate de către acesta.

Pe serverul de management am instalat pachetele VRTSsfmcs (Management Server) și VRTSsfmh (managed host). Cel de-al doilea pachet conține componenta XPRTL cea care facilitează comunicarea între host-urile administrate și serverul de management și are următoarele componente:

Componeneta XPRTLD, care este un server web in genere.

Componenta XPRTLC, care este un client HTTP bazat pe instrucțiuni în linie de comandă. Ea poate trimite informații către serverele web.

Componentele XPRTLD și XPRTLC sunt integrate în Veritas Authentication Services pentru comunicarea prin SSL securizat cu protocolul HTTP.

Comunicarea între host-urile administrate și serverul de management folosește de asemenea protocolul HTTP. Serverul web XPRTLD rulează atât pe serverul de management cât și pe host-urile administrate și suportă standardele CGI – Common Gateway Interface.

În cazul nostru, cazul Veritas Cluster Server-ului, informațiile despre host-urile administrate se trimit o dată la 60 de minute. Dar, de fiecare dată când inițiem o schimbare în configurarea cluster-ului, update-urile cu noile informații ajung pe serverul central de management.

Procedura de instalare este destul de directă și simplă. Se copiază pe serverul de management arhiva Veritas_Operations_Manager_MS_6.0_Linux.bin, după care o dezarhivăm. Ne deplasăm în directorul în care am făcut dezarhivarea și rulăm următoarele comenzi:

chmod +x Veritas_Operations_Manager_MS_6.0_Linux.bin

./ Veritas_Operations_Manager_MS_6.0_Linux.bin

Pentru a instala VOM-ul pe host-urile care vor fi administrate, va trebui să instalăm pachetul VRTSsfmh. Descărcăm arhiva cu pachetul necesar și o copiem pe serverul în cauză. Rulăm următoare comandă:

Rpm –ivh VRTSsfmh_6.0.0.0_Linux.rpm

Înainte de a putea accesa interfața web pentru Veritas Operations Manager pe browser-ul Firefox trebuie să parcurgem următorii pași:

În pagina web ce ne atenționează în legătură cu o excepție de la securitate va trebui să adăugăm o excepție pentru următoarele 2 link-uri web:

https://hostname:5634/ – URL pentru configurarea VOM-ului

https://hostname:14161/ – URL pentru lansarea Veritas Operations Manager

Facem click pe ”Get Certificate”

Selectăm ”Permanently store this exception”.

Confirmăm ”Confirm Security Exception”.

Înainte de a ilustra mai jos prin două figuri cum arată interfața web pentru VOM, trebuie să specificăm cum putem opri și porni interfața web pentru Veritas Operations Manager. Aceasta se face prin comanda următoare:

/opt/VRTSsfmcs/cweb/sfmw restart

Figura 3.8 Interfața web pentru Veritas Operations Manager

Figura 3.9 Nodurile Veritas Cluster Server din proiect prezente în VOM

Pe primul nod al clusterului nostrum atunci când verificăm existența pachetelor necesare pentru VOM obținem următoarele rezultate:

[root@veritas1 ~]# rpm -q VRTSsfmcs

VRTSsfmcs-6.1.0.0-0

[root@veritas1 ~]# rpm -q VRTSsfmh

VRTSsfmh-6.1.0.0-0

În Veritas Operation Manager avem următoarele 3 metode care măresc procentul de accesibilitate al serverului de management:

Putem configura mai mult de un server ca și server de management în datacenter-ul nostru. VOM permite ca serverele administrate să raporteze la mai mult de un server de management.

Configurăm Veritas Operation Manager într-un mediu puternic redundant, adică vom configura chiar management server-ul intr-un cluster.

Configurăm opțiunea de disaster recovery în VOM. Se replică baza de date a Veritas Operation Manager cât și toate informațiile aferente domeniului ce sunt păstrate în storage-ul partajat într-un alt site/locație.

Ca și metode de alertare și monitorizare VOM ne asigură capabilitățile de a ține sub control și atentă observație infrastructuri întregi de servere, aplicații și baze de date. Capacitatea și utilizarea sistemelor de fișiere sunt foarte importante din cauză că afectează direct performanța aplicațiilor care folosesc aceste sisteme de fișiere. Veritas Operations Manager oferă posibilitatea de a seta limite maxime pentru utilizarea acestor sisteme de fișiere și de a planifica măsuri preventive astfel încât să se evite situațiile de criză în care se rămâne fără spațiu suficient ca aplicațiile să rule la parametri optimi.

Figura 3.10 Alerte de monitorizare în VOM

Capitolul 4 Studiu și test de caz cu NFS Shares și Server Web

În acest capitol vom configura storage-ul oferit de către serverul iSCSI (configurat în capitolul 3) pe Veritas Cluster Server. Vom configura de asemenea o aplicație web pe unul dintre nodurile cluster-ului. La final vom demonstra cum chiar dacă unul dintre noduri devine indisponibil, share-urile NFS și aplicația web vor continua să ruleze pe cel de-al doilea membru al VCS-ului.

4.1 Prezentarea și configurare storage iSCSI pe VCS

În subcapitolul 3.1 am configurat serverul openSUSE și am creat LUN-uri de storage pe care le vom prezenta spre atașare și configurare pe Veritas Cluster Server-ul nostru. Pentru a descoperi aceste device-uri exportate de către serverul linux-ko34 vom rula pe primul nod al VCS, veritas1, următoarele comenzi:

iscsiadm -m discovery -t st -p 192.168.1.100:3260

iscsiadm -m discovery -t st -p 192.168.1.101:3260

iscsiadm -m node –l

De asemenea vom scana bus-urile serverului pentru a face aceste LUN-uri vizibile pe VM-ul nostru.

echo "- – -" > /sys/class/scsi_host/host*/scan

În această configurație am folosit sistemul de fișiere VxFS (VeritasFile System). Înainte de a putea folosi acest system de fișiere, am instalat de asemenea și softul de management al mai multor căi spre LUN-urile de storage oferit de către Veritas, și anume DMP – dynamic multipathing.

./installdmp

cd /etc/init.d/

./vxconfigd start

vxconfigd -m enable

vxdiskadd /dev/sda

vxdiskadd /dev/sdb

vxdg init group sdb cds=off

vxdg init cuc disk=sdb

fdisk /dev/sdc

vxdiskadd sdc

vxdg -g cuc adddisk sdc

vxassist -g cuc make cucvolum 500M sdc layout=stripe-mirror

vxassist -g cuc make cucvolum 500M sdb sdc layout=mirror

vxassist -g cuc make cucvolum 500M disk sdc layout=mirror

vxvol -g cuc enable cucvolum

mkfs.vxfs /dev/vx/dsk/cuc/cucvolum

mount.vxfs /dev/vx/dsk/cuc/cucvolum /mnt

fdisk /dev/sdd

fdisk /dev/sde

vxdiskadd sdd

vxdiskadd sde

vxdg init bla diskex1=sdd

vxdg -g bla adddisk diskex1=sdd

vxdg -g bla adddisk diskex2=sde

vxassist -g bla make epic 500M diskex1 diskex2 layout=mirror

mkfs.vxfs /dev/vx/dsk/bla/epic

vxdiskadd /dev/sdf

vxdisk /dev/sdf

vxdisk -g cluster sdf

vxdisk list

vxdiskadd disk_0

vxdiskadd disk_1

vxdisk list

vxdg init cluster lun0=disk_0

vxdiskad disk_0

vxdiskadd disk_0

fdisk /dev/sdf

fdisk /dev/sdg

vxdiskadd disk_0

vxdiskadd disk_1

vxdisk list

vxdg init cluster lun0=disk_0

vxdg -g cluster adddisk lun1=disk_1

Prin succesiunea de mai sus am adăugat și configurat storage-ul iSCSI prezentat de către serverul openSUSE linux-ko34. Am reușit să obținem următoarea structură de storage Veritas:

[root@veritas1 ~]# vxdisk -o alldgs list

DEVICE TYPE DISK GROUP STATUS

disk_0 auto:cdsdisk lun0 cluster online

disk_1 auto:cdsdisk lun1 cluster online

disk_2 auto:none – – online invalid

disk_3 auto:LVM – – LVM

disk_4 auto:cdsdisk lun10 increase online

sda auto:none – – online invalid

sdb auto:cdsdisk disk cuc online

sdc auto:cdsdisk sdc cuc online

sdd auto:cdsdisk diskex1 bla online

sde auto:cdsdisk diskex2 bla online

– – increase01 increase failed was:disk_5

– – lun12 increase failed was:disk_6

– – lun13 increase failed was:disk_7

În acest moment vom avea următoarele căi către storage-ul atașat.

[root@veritas1 ~]# multipath -ll

mpath2 (149455400000000003479557422415f0b1fd3e90c92d1e499) dm-5 IET,VIRTUAL-DISK

[size=900M][features=0][hwhandler=0][rw]