Universitatea POLITEHNICA București

Facultatea Automatică şi Calculatoare

Departamentul Automatică şi Informatică Industrială

LUCRARE DE LICENŢĂ

Monitorizarea prin tehnologii cloud asupra unei ferme

de servere cu sistemul de operare Solaris 11

Coordonator Absolvent
Sl.dr.ing. Madalin Stefan Vlad Ana Raluca Constantin

2016
Cuprins
1 Introducere ..................................................................................................................... 4
1.1 Scopul şi obiectivele lucrării ................................................................................. 4
1.2 Descrierea domeniului evaluat .............................................................................. 5
1.3 Prezentare pe scurt a capitolelor ............................................................................ 6
2 Analiză şi modelare ........................................................................................................ 6
2.1 Specificarea cerinţelor ........................................................................................... 6
2.1.1 Formularea problemei şi identificarea actorilor .............................................. 7
2.1.2 Cerinţele Funcţionale ....................................................................................... 8
2.1.3 Cerinţele Nefuncţionale ................................................................................... 8
2.1.3.1 Utilizabilitate ............................................................................................ 8
2.1.3.2 Fiabilitate.................................................................................................. 9
2.1.3.3 Performanţă .............................................................................................. 9
2.1.3.4 Suportabilitate .......................................................................................... 9
2.1.3.5 Implementare ............................................................................................ 9
2.1.3.6 Interfaţa .................................................................................................. 10
2.1.3.7 Instalare .................................................................................................. 10
2.1.3.8 Operare ................................................................................................... 10
2.1.4 Data mining ................................................................................................... 10
2.2 Modelare .............................................................................................................. 10
2.2.1 Analiza sarcinii bazată pe scenarii................................................................. 11
2.2.2 Modelul cazurilor de utilizare........................................................................ 11
2.2.3 Modelul obiectual de analiză ......................................................................... 13
2.2.4 Modelul dinamic ............................................................................................ 14
3 Proiectarea aplicaţiei .................................................................................................... 15
3.1 Arhitectura sistemului de programe .................................................................... 15
3.2 Analiza metodelor de rezolvare a problemei şi selectarea soluţiei tehnice ......... 17
3.2.1 Cloud computing ........................................................................................... 17
3.2.2 Justificarea soluţiei Apache + PHP + MySQL .............................................. 18
3.2.3 PHP ................................................................................................................ 19
3.2.3.1 Yii PHP Framework ............................................................................... 20
3.2.4 MySQL .......................................................................................................... 21
3.2.5 Apache ........................................................................................................... 21
3.2.5.1 Modulul mod_ssl .................................................................................... 21
3.2.6 Dropbox ......................................................................................................... 22
3.2.6.1.1 Dropbox API, Dropbox-sdk-php şi Composer .................................. 22
3.2.7 Sistemul de operare Solaris ........................................................................... 23
3.2.8 Shell Scripting ............................................................................................... 24
4 Implementare ................................................................................................................ 24
4.1 Programare........................................................................................................... 24
4.2 Colectarea datelor de pe servere .......................................................................... 28
4.3 Analiza datelor ..................................................................................................... 33
5 Instalare şi utilizare ...................................................................................................... 35
5.1 Instalarea sistemului de monitorizare .................................................................. 35
5.2 Utilizarea aplicaţiei .............................................................................................. 36
6 Testare .......................................................................................................................... 50
7 Concluzii şi contribuţii personale ................................................................................. 53
7.1 Contribuţii............................................................................................................ 53

2
 7.2 Considerente legate de dezvoltarea ulterioară a aplicaţiei................................... 53
7.3 Concluzii.............................................................................................................. 54
8 Bibliografie................................................................................................................... 55

3
1 Introducere

1.1 Scopul şi obiectivele lucrării

Multe sarcini bazate pe gestionarea informaţiilor oferite de un sistem tehnic sunt greu de
asimilat şi manipulat de către o persoană. De multe ori aceste sarcini sunt abordate
utilizând aplicaţii. Fiecare aplicaţie oferă utilizatorului oportunitatea să lucreze cu un
anumit grup de informaţii ce au fost prelucrate pe baza unor operaţii şi au fost afişate într-o
interfaţă grafică. Într-un mediu dinamic, ce nu oferă posibilitatea unei accesări umane
continue şi conţine un set de date cu caracter confidenţial este necesară introducerea unui
sistem de gestionare a informaţiei automat. În general în cadrul marilor companii datele
sunt stocate şi gestionate în interiorul unei ferme de servere. O fermă de servere este un
grup de câteva sute de servere interconectate şi dispuse într-o anumită locaţie.
Monitorizarea acesteia este vitală pentru bunul demers al activităţii companiei, însă
efectuată manual de către o persoană sau mai multe poate devenii o activitate greoaie.
Făcând un studiu de piaţă asupra modului în care companiile tratează acest aspect, se poate
observa că accentul este pus mai mult pe repararea ulterioarelor probleme într-un timp cât
mai redus, decât pe prevenirea acestora în timp real. Acest comportament are însă aspecte
negative din punct de vedere al costului financiar şi temporar, multe dintre defectele şi
erorile întâmpinate putând fi prevenite. O întreagă fermă de servere poate să fie afectată
dacă performanţa uneia dintre componente începe să scadă, însă acest lucru să nu fie
observat decât în momentul în care una, mai multe componente sau chiar toate au de
suferit.

Lucrarea de fata îşi propune identificarea cerinţelor dezvoltării unui sistem de monitorizare
asupra unei ferme de servere şi implementarea sa.
Datorită optimizării sale mari pentru lucrul cu servele fizice de tip SPARC, sistemul de
operare Solaris a avut parte de o răspândire mare în mediul afacerilor. Sistemul de operare
are implementat un sistem propriu de identificare şi corecţie a erorilor tehnice ce s-au
produs la nivelul său, însă interpretarea informaţiile rezultate în urma acestor procedee cere
un nivel ridicat de expertiză din partea resursei umane responsabile. Interogarea mesajelor
generate de sistem şi a parametrilor săi poate devenii greoaie, iar omiterea informaţiilor
relevante poate surveni foarte uşor. Companiile ce oferă suport pentru serverele ce rulează
sistemul de operare Solaris au dezvoltat instrumente interne pentru analiza datelor
colectate de către client de pe servere în momentul apariţiei unui defect, însă procesul de
colectare a datelor este de multe ori costisitor din punct de vedere al timpului, iar datele nu
sunt evaluate în mod constant.

Sistemul de monitorizare ce se doreşte a fi dezvoltat în cadrul acestei lucrări se va

concentra pe fermele de servere cu sistemul de operare Solaris, luând în considerare
aspectele cele mai relevante pentru determinarea stării acestuia.
Se doreşte trecerea de conceptul de reparare la acela de prevenire dinamică în domeniul
descris, lucru ce poate să aducă mari diminuări ale costurilor.

4
1.2 Descrierea domeniului evaluat
În ultimii ani, nivelul de informaţie ce este zilnic stocat, accesat şi parsat a crescutmai ales
în cadrul marilor companii, de aceea necesitatea unei capacităţi de stocare şi procesare
mare a devenit foarte importantă. O soluţie des abordată este implementarea unei colecţii
de servere ce comunică între ele, numită şi fermă de servere.
O fermă de servere eficientizează procesele interne prin distribuirea sarcinilor de lucru
între componentele individuale ale fermei și a proceselor de calcul prin valorificarea puterii
de pe mai multe servere. Astfel de grupari de servere se bazează pe software-ul de
echilibrare a sarcinii care îndeplineşte sarcini, cum ar fi gestionarea puterii de procesare de
la mașini diferite, prioritizarea sarcinilor și utilizarea resurselor disponibile în funcţie de
prioritatea acestora, iar atunci când un server din fermă eșuează, altul poate interveni ca o
copie de rezervă.
Combinarea serverelor şi a puterii de procesare într-o singură entitate este o activitate
relativ comună de mai mulți ani în instituțiile de cercetare, academice sau de afaceri.
Astăzi, tot mai multe companii utilizează fermele de servere ca o modalitate de manipulare
a cantităţii enorme de informaţie, a sarcinilor și a serviciilor de care au nevoie.
Totodată, datorită răspândirii conexiunii permanente a utilizatorului la internet, s-au
realizat paşi semnificativi şi concreţi în impunerea conceptului de cloud computing în
domeniul IT.
O înţelegere a conceptului de "cloud computing" este în continuă evoluţie, iar terminologia
şi conceptele folosite pentru definirea sa necesită de cele mai multe ori o clarificare.
Această nouă tehnologie aduce o simplificare în ceea ce priveşte sincronizarea datelor
utilizatorului ce foloseşte mai multe dispozitive, viteză de calcul şi capacități de stocare
mari și o independenţă faţă de configuraţia dispozitivului propriu de unde este accesat prin
partajarea resurselor. Prezentând aceste avantaje, conceptul de cloud reprezintă soluţia
ideală pentru partajarea datelor independent de locaţie către utilizatorii aplicaţiei.
Serverele trebuie să efectueze un număr mare de operaţii într-un timp cât mai scurt.
SPARC (Scalable Processor Architecture) este o arhitectură de tip RISC (reduced
instruction computing) foarte utilizată în cadrul fermelor de servere. Pentru acest tip de
sisteme şi nu numai, sistemul de operare Solaris, bazat pe Unix, este o alegere des întâlnită
în cadrul organizaţiilor.
Aplicaţia pentru monitorizarea fermei de servere se poate preta la o gamă largă de sisteme
de operare, însă datorită utilizării mari, software-ul dezvoltat va evalua serverele ce rulează
sistemul de operare Solaris.
Buna funcţionare a serverelor este critică pentru organizaţia deţinătoare, de aceea o
monitorizare constantă şi în timp real este absolut necesară.
O gestiune defectuoasa asupra staţiilor de lucru poate duce la importante prejudicii pentru
companie, cum ar fi perioade mari de timp mort pentru productivitate, costuri ridicate şi
chiar probleme de securitate.
Problemele ce pot apărea sunt în general identificate doar când defecţiunea a survenit sau
performanţele sistemului sunt deja problematice.
Prezenţa unui sistem de monitorizare ce va alerta inginerul de sistem în timp real în
momentul apariţiei unei schimbări, partajarea acestei informaţii între mai multe persoane
autorizate indiferent de locaţie poate să protejeze organizaţia de astfel de probleme
costisitoare şi neplăcute.
Obiectivul acestei lucrări este dezvoltarea unei aplicaţii web de monitorizare a unei ferme
de servere în timp real ce poate să fie accesată independent de dispozitiv.

5
1.3 Prezentare pe scurt a capitolelor
Lucrarea de faţă este structurata pe 9 capitole, după cum urmează:
În Capitolul 1 - "Introducere" - sunt prezentate obiectivele şi scopul lucrării, descrierea
domeniului din care face parte sistemul de monitorizare creat și sunt prezentate pe scurt
capitolele.
În Capitolul 2 - "Analiza şi modelare" - În vederea procesului de analiză şi specificare a
cerinţelor s-au utilizat şi sunt descrise următoarele concepte: este formulată problemă de la
care s-a plecat, sunt identificate cerinţele funcţionale şi nefuncţionale ale sistemului, sunt
analizate cerinţele prinţ tehnica data mining, sunt identificate scenariile iniţiale şi finale
obţinute prin etnografie. Pentru modelarea sistemului s-au elaborat diagramele cazurilor de
utilizare, modelul obiectual de analiza exemplificat prin diagrama de clase şi modelul
dinamic descris cu ajutorul diagramei de activități.
În Capitolul 3 – „Proiectarea aplicaţiei” - este prezentată arhitectura aplicaţiei şi sunt
descrise tehnologiile utilizate în vederea realizării aplicaţiei de monitorizare motivând
alegerile făcute prin comparaţie cu serviciile şi tehnologiile curente ce oferă funcţionalităţi
similare.
În Capitolul 4 - "Implementare" - este prezentat modul prin care aplicaţia a fost
programată, datele au fost colectate şi parsate, instalarea sistemului de monitorizare şi
manualul de utilizare al aplicaţiei.
În Capitolul 5 - "Instalare şi utilizare" - sunt descrişi paşii pe care utilizatorul trebuie să îi
urmeze în vederea obţinerii rezultatelor propuse. Utilizarea reprezintă o exemplificare
concretă a cazurilor de utilizare ce stau la dispoziţia utilizatorului.
În Capitolul 6- "Testare" - sunt definite testele şi paşii ce au fost parcurşi în elaborarea
acestora, rezultatele şi modul în care au fost rezolvate eventualele defecte observate.
În Capitolul 7 - " Concluzii şi contribuţii personale " - sunt prezentate concluziile generale
asupra aplicaţiei dezvoltate, contribuţiile personale aduse în comparaţie cu produsele
similare deja existente şi modul în care se pot aduce dezvoltări ulterioare în vedere
îmbunatăţirii acesteia pentru a cuprinde o gamă cât mai largă de funcţionalităţi.
În ultimul capitol, Capitolul 8 - "Bibliografie" - este prezentă documentaţia ce a stat la baza
acestei lucrări.

2 Analiză şi modelare
2.1 Specificarea cerinţelor
În vederea proiectării unui sistem de monitorizare puternic este necesară o cunoaştere a
capacităţilor şi funcţionalităţilor ce trebuiesc îndeplinite de către acesta cât şi a restricţiilor
ce trebuiesc impuse.
Definirea cerinţelor reprezintă faza de analiză a problemei. Colectarea cerinţelor necesita
colaborarea între grupuri de participanţi cu background diferit. Aceste grupuri reprezintă
multitudinea actorilor ce intra în contact cu produsul dezvoltat (stakeholders): utilizatori,
clienţi, administratori, dezvoltatori. Pe lângă interacţiunea dintre aceştia, alte surse de
informaţie disponibile pentru identificarea cerinţelor sunt sistemele similare existente,
standardele, ontologii şi restricţiile domeniului din care produsul face parte.

6
Standardul IEEE 830 (IEEE recommended practice for software requirements
specifications) descrie conţinutul, calităţile şi avantajele unei bune specificaţii a cerinţelor
software. Specificaţiile cerinţelor software trebuie să fie corecte, complete, să nu lase loc
de interpretări, consistente şi verificabile.
În figură 2.1 este reprezentată diagrama UML de activităţi pentru identificarea cerinţelor ce
respectă standardul IEEE 830.

Fig. 2.1. Diagrama UML de activităţi pentru identificarea cerinţelor

2.1.1 Formularea problemei şi identificarea actorilor

Formularea problemei trebuie să fie precisă, semnificativă, să nu reprezinte o falsă

problemă, să fie verificabilă.
În lucrarea de fată se doreşte elaborarea unui sistem software pentru monitorizarea unei
ferme de servere ce prezintă sistemul de operare Solaris ce poate să fie accesat independent
de locaţie şi dispozitiv. Situația cauzală a acestui obiectiv se manifestă prin numarul mare
de erori și defecte ce apar in gestionarea informațiilor in cadrul unei astfel de grupări de
sisteme.
Identificarea actorilor este esenţială pentru construirea unor cerinţe şi specificaţii
consistente. Principalii beneficiarii ai unui sistem de monitorizare sunt companiile sau

7
instituţiile de cercetare ce utilizează sistemul de operare Soalris în interiorul unei ferme de
servere cât şi a inginerilor de sistem ce interacţionează cu acestea. Sistemul de
monitorizare va avea doi actori principali, utilizatorul administrator şi multiplii utilizatori
de tip client.

2.1.2 Cerinţele Funcţionale

Cerinţele funcţionale descriu interacţiunile dintre sistem şi mediul acestuia, independent de

implementare. El sunt colectate pe baza observaţiei (etnografie) în mediul ţintă al
aplicaţiei.
În urma analizării necesităților pentru dezvoltarea sistemului propus s-au enunțat
urmatoarele cerințe:
Sistemul de monitorizare dezvoltat trebuie să permită autentificarea utilizatorilor. Datele
de autentificare sunt gestionate de către administratorul sistemului.
Datele trebuiesc preluate de pe serverele adăugate în aplicaţie şi urcate într-un mediu de
stocare în mod constant.
Accesul la mediul de stocare trebuie să fie independent de locaţie şi dispozitiv.
Administratorul aplicaţiei gestionează accesul la mediul de stocare.
Posibilitatea adăugării de servere în vederea monitorizării acestora atât de către
administrator cât şi de utilizator.
Administratorul trebuie să accepte adăugarea serverelor în aplicaţie.
Un utilizator va avea acces numai la setul propriu de servere, adăugate cu respectivul nume
de utilizator.
Datele din mediul de stocare trebuie preluate şi analizate de către aplicaţie. Sunt analizate
datele şi sunt semnalate eventualele probleme.
Aplicaţia trebuie să ofere o modalitate de evaluare a întregului set de servere.
Utilizatorul poate vizualiza grafice de performanţă, configuraţia sistemului, mesajele
generate de sistemul de operare, notificări despre versiunile noi apărute pentru diverse
pachete şi alertele identificate de aplicaţie.
Gestionarea versiunilor pachetelor în funcţie de care se va lua decizia recomandării unei
actualizări este efectuată de către administrator.
Sistemul trebuie să gestioneze şi să semnaleze ulterioarele probleme în colectarea şi
parsarea datelor.

2.1.3 Cerinţele Nefuncţionale

Cerinţele nefuncţionale descriu tipurile de constrângeri impuse asupra sistemului, raportate

la cerinţele funcţionale.
Categoriile de cerinţe nefuncţionale (de calitate) au fost enunţate în conformitate cu
modelul FURPS+ ([Grady 1992], [IEEE Std. 610.12-1990]).

2.1.3.1 Utilizabilitate

Implementarea unei pagini în care să fie descris ghidul de utilizare al aplicaţiei.

Fiecare utilizator îşi poate adăuga un logo pentru serverele sale.

8
2.1.3.2 Fiabilitate

Sistemul trebuie să fie fiabil, să poate face faţa atacurilor la nivelul securităţii, precum SQL
Injection sau Brute force attack.
Datele ce vor fi importate/exportate şi prelucrate nu trebuie să poată să fie interceptate, nu
sunt admisibile pierderile de date pe ruta dintre server şi aplicaţie.
În cazul în care, după trimiterea datelor serverului către mediul de stocare cloud, aceste
date sunt incomplete sau au o structură ce nu este suportată de către aplicaţie, parsarea lor
nu va fi efectuată. Pentru fişierele lipsă sau cu o structură eronată, se va genera un mesaj
într-un log ce ţine evidenţa tuturor erorilor ce apar în timpul parsarii datelor serverelor.
Mesajul de eroare specifică ora la care a apărut problema, cât şi host-ul pentru care a
apărut această.
Dacă datele pentru un host/server nu pot fi accesate pentru mai mult de o oră, se va genera
o alertă vizibilă de către administrator şi de către utilizatorul căruia îi corespunde serverul
ce îi va atenţiona în legătură cu această problemă. Aceştia vor fi avertizaţi de faptul că nu
s-a putut face achiziţia informaţiilor şi parsarea lor pentru un anumit sistem şi dată la care
s-au achiziţionat ultima oară acestea.

2.1.3.3 Performanţă

Datele sunt urcate în mediul de stocare la un interval de timp de 10 minute.

Colectarea datelor nu trebuie să dureze mai mult de 4 minute.
Timpul de actualizare al datelor nu trebuie să fie mai mare de 10 minute.
Timpul de analiza al datelor pentru un server nu trebuie să depăşească 3 minute.
Timpul de încărcare al interfeţelor grafice să nu depăşească 7 secunde.
Puterea de calcul cu care se va efectua analiza datelor trebuie să fie suficientă să parseze
datele de la 500 de servere.
Sistemul trebuie să fie operaţional şi accesibil în mod constant, disponibil oricând
utilizatorul doreşte să îl acceseze.
Depozitul de date trebuie să aibă o dimensiune minimă de 5GB.

2.1.3.4 Suportabilitate

Aplicaţia dezvoltată trebuie să fie adaptabila la modificările ce vor apărea în versiunile de

Solaris noi.
Aplicaţia trebuie să permită modificarea datelor de conectare la mediul de stocare.
Integrarea unei pagini unde se pot modifica versiunile curente în funcţie de care se face
analiza datelor.
Să existe posibilitatea creşterii dimensiunii mediului de stocare în vederea monitorizării
ulterioare a unui număr mai mare de servere.

2.1.3.5 Implementare

Administratorul va avea sarcina de a actualiza versiunile pachetelor integrate în sistemul de

operare cât şi versiunea acestuia în funcţie de noile actualizări de versiuni disponibile.

9
2.1.3.6 Interfaţa

Mediul de stocare trebuie să poată primi datele de la serverele cu sistemul de operare

Solaris.
Aplicaţia de colectare a datelor să poată rula independent de activitatea întreprinsă pe
server.

2.1.3.7 Instalare

Instalarea sistemului nu trebuie să necesite timp mort de activitate pentru sistem şi nu

trebuie să interfereze cu activitatea acestuia.

2.1.3.8 Operare

Sistemul în faza iniţială pune la dispoziţie doar utilizatorul administrator. Acesta va

gestiona utilizatori în funcţie de persoanele care au acces la datele prelucrate.

2.1.4 Data mining

Data mining este o tehnică de analiză bazată pe folosirea sistemelor existente pentru a
deduce cerinţele.
În urma efectuării unui studiu asupra realizărilor similare din domeniu, au fost identificate
mai multe unelte utilizate pentru evaluarea sistemului de operare Linux, pentru Solaris
nefiind nicio aplicaţie conturată până la momentul actual. În vederea analizei în scopul
deducerii unor cerinţe relevante pentru aplicaţia dezvoltată în lucrarea de faţă, a fost
evaluata uneltea GNOME System Administration. Aceasta este utilizată în vederea
gestionarii şi monitorizării resurselor sistemului şi are caracteristicile cele mai apropiate
faţă de sistemul ce se doreşte a fi dezvoltat.
Printre principalele funcţionalităţi ale acestei aplicaţii se evidenţiază monitorizarea şi
utilizarea procesoarelor, a memoriei RAM şi swap, utilizarea reţelei şi a discurilor şi o
evidenţă a spaţiului utilizat în sistemul monitorizat.
Aplicaţia monitorizează sisteme individuale nefiind pusă la dispoziţie o posibilitate de
concatenare a mai multor sisteme.
Chiar dacă este ușor de utilizat, GNOME este un sistem vast și complex, și, prin urmare,
este necesară o bună documentație pentru a-l putea utiliza la capacitatea maximă. În urma
evaluării documentaţiei puse la dispoziţie de către dezvoltatori acestei unele a fost
observată uşurinţă de identificare a erorilor de performanţă cu ajutorul graficelor.
Un alt aspect important este scalabilitatea interfeţei, ceea ce face posibilă utilizarea
sistemului indiferent de ecranul pe care urmează să fie afişată.
Aceste avantaje reprezintă un punct forte al uneltei şi vor fi luate în considerare pentru
proiectarea aplicaţiei dezvoltate în această lucrare.

2.2 Modelare
Modelarea presupune realizarea unui model al sistemului ce nu lasa loc de interpretări,
corect, complet şi consistent. Se urmăreşte structurarea şi formalizarea cerinţelor colectate
anterior.

10
2.2.1 Analiza sarcinii bazată pe scenarii

Etapa colectării cerinţelor ce pleacă de la premisa mai sus enunţata se va baza pe scenarii
formulate prin etnografie. În cadrul acestei colectări se vor ilustra două scenarii, scenariul
iniţial ce descrie modul curent de desfăşurare a procesului de lucru în mediul utilizatorului
şi scenariul ulterior ce ilustrează funcţionalităţile ce vor fi oferite de noul sistem.

Scenariul iniţial
Scenariul iniţial de la care s-a plecat presupune utilizarea sistemelor de calcul fără un
sistem de monitorizare care să indice apariţia în timp real a unei defecţiuni sau a unei
scăderi în performanţa. Erorile apărute ce afectează bunul demers al activităţilor
companiilor sunt semnalate în 90% din cazuri de membrii care utilizează sau gestionează
aplicaţiile ce rulează pe respectivele servere. Plecând de la problema semnalată, se începe
investigarea cauzei prin analiza atât a sistemului de operare, cât şi a aplicaţiei. Persoana
responsabilă cu administrarea sistemului de operare îşi începe analiză prin conectarea la
maşina pe care rula aplicaţia în cauză, analiza logourilor, configuraţiei şi interpretarea
parametrilor statici şi dinamici ai sistemului.

Scenariul ulterior
Scenariul ulterior presupune ca analistul de sistem să se autentifice cu ajutorul unui nume
de utilizator, a unei parole aferente şi a unei conexiunii la internet, în aplicaţia de
monitorizare. Datele de acces vor fi gestionate de administratorul aplicaţiei.
Utilizatorul va putea să verifice starea serverelor la care are acces, să verifice
performanţele acestora, modul în care sunt configurate, logurile şi alertele generate.
Astfel, analistul de sistem poate vedea în timp real dacă au fost semnalate erori în cadrul
sistemului de operare. Această abordare poate reduce semnificativ timpul de analiza
necesar identificării problemei. Totodată un sistem de alerte implementat în această
aplicaţie îi va semnala persoanei responsabile survenirea oricărei modificări cu aspect
negativ. Acest lucru poate ajuta la prevenirea problemelor la nivel de aplicaţie.

2.2.2 Modelul cazurilor de utilizare

Modelul cazurilor de utilizare este exemplificat cu ajutorul diagramei cazurilor de

utilizare. În această diagramă sunt descrise interacţiunile dintre actori şi sistem, drepturile
de acces (ce caz de utilizare poate accesa fiecare utilizator), funcţionalitatea comună şi ce
informaţie este manipulată de către sistem.
Figura 2.2 reprezintă diagrama cazurilor de utilizare aferentă sistemului de monitorizare
descris în această lucrare.
Actorii identificaţi sunt analistul de sistem care va fi utilizatorul de tip client şi
administratorul aplicaţiei.
Administratorul este un caz particular al analistului de sistem, acesta are acces la toate
cazurile de utilizare ale analistului de sistem şi la încă patru specifice lui.
Orice utilizator al sistemului, indiferent de tipul acestuia, va putea să se autentifice pe
sistem în cazul în care deţine o combinaţie nume utilizator-parola corectă. Va putea să
vizualizeze manualul de utilizare, să instaleze sistemul de monitorizare prin adăugarea
scripturilor de colectare a datelor pe server, să verifice alertele de servere şi să gestioneze
serverele.

11
Verificarea datelor serverelor include verificarea diagramelor de performanţă, verificare
mesaje generate de sistem şi verificarea configuraţiei.
Administratorul aplicaţiei poate să gestioneze utilizatorii, versiunile în funcţie de care se
face evaluarea pachetelor, să gestioneze accesul la mediul de stocare, să poată accepta
înscrierea serverelor în aplicaţie şi să vizualizeze informaţiile generate despre activitatea
aplicaţiei.

Fig. 2.2. Diagrama cazurilor de utilizare

12
2.2.3 Modelul obiectual de analiză

Modelul obiectual de analiză surprinde conceptele manipulate de sistem, proprietăţile şi

relaţiile acestora şi este reprezentat prin intermediul diagramei de clase.
În figură 2.3 este reprezentată diagrama de clase a sistemului de monitorizare dezvoltat.

Fig. 2.3. Diagrama de clase

Structura diagramei de clase a avut la baza modelul structural MVC. În diagrama sunt
descrise clasele ce urmează să fie implementate în aplicaţie. Intrare în aplicaţie se va face
prin controlerul principal, SiteController, care permite autentificarea utilizatorului şi crează
sesiunea. Din acest controler prin intermediul acţiunilor sale se face trecerea în controlerele
secundare, DropboxKeysController, UserServerController, UserSmController şi
VersionsController. Aceste controlere secundare au unul sau mai multe modele asociate ce
reprezintă modul de stocare al informaţiilor aferente controlerelor. Acestea încarcă
obiectele asociate lor în scopul generării unor vederi pe baza informaţiilor din obiecte.
Vederile reprezintă modul grafic de afişare al informaţiilor gestionate de către aplicaţie.

13
2.2.4 Modelul dinamic

Modelul dinamic este reprezentat de diagrama de activităţi (Figura 2.4).

Pentru accesarea aplicaţiei un utilizator face o cerere de autentificare către această. Ca
răspuns la această cerere se afişează formularul de autentificare. După introducerea datelor
în formular se face validarea acestora. Dacă datele de autentificare nu sunt valide, se va
reîncărca formularul de autentificare şi este necesară introducerea altor date. Dacă datele
de autentificare sunt valide se va verifica tipul de utilizator autentificat. în funcţie de tipul
acestuia, utilizatorul urmează să fie direcţionat. În cazul autentificării în sistem a unui
utilizator ce nu este admin, pagina pe care acesta va fi direcţionat va conţine o listă cu
serverele acestuia. Din această pagină utilizatorul poate alege un server pentru a vedea
informaţiile asociate lui. Dacă utilizatorul este admin, acesta va fi direcţionat către pagina
Home a interfeței. Starea actuală a utilizatorului permite acestuia să migreze către alte cinci
activităţi. Aceste activităţi permit administrarea utilizatorilor, administrarea spaţiului de
stocare cloud, administrarea versiunilor, administrarea serverelor şi accesarea unei liste cu
toate serverele monitorizate. Fiecare dintre aceste activităţi se pot reîntoarce în pagina
Home.

Fig. 2.4. Diagrama de activitate

14
3 Proiectarea aplicaţiei
3.1 Arhitectura sistemului de programe
Sistemul de monitorizare trebuie să ofere suport pentru un număr mare de clienți și un
număr mare de conexiuni concurente. Arhitectura bazată pe modelul N-tire client-server
oferă o serie de avantaje ce se pliază pe cerinţele aplicaţiei dezvoltate. Acest tip de
arhitectura oferă performanțe ridicate, scalabilitate, toleranţă la modificări şi
disponibilitate.
Structura N-tire implica un program bazat pe modelul client-server unde sunt prezente mai
mult de trei nivele de distribuţie implicate. Nivelul adiţional în aplicaţie este în general
asociat cu nivelul logic care este reprezentat de serverul ce conţine aplicaţia. Adăugat
avantajelor programării distribuite şi a datelor prin reţea, aplicaţiile n-tire au avantajul că
oricare nivel să poată să fie rulat pe o platformă cu sistem de operare şi să poată fi
modificat independent de celelalte nivele.
În figură 3.1 este prezentată structura unei arhitecturi de tip N-tire Client-Server în cazul
unei aplicaţii web.

Fig 3.1. Structura arhitecturii de tip N-tire Client-Server

Nivelul cel mai de sus este reprezentat de către interfaţa cu utilizatorul. Funcţia principală
a acestui nivel este să traducă cererile şi răspunsurile acestora pe înţelesul utilizatorului. Un
browser web poate să îndeplinească această funcţie.
Al doilea nivel al arhitecturii este reprezentat de către un server web ce găzduieşte paginile
web şi le pune la dispoziţia solicitanţilor prin protocolul HTTP.
Nivelul trei este nivelul logic al arhitecturii. Acesta este nivelul ce coordonează aplicaţia,
procesează comanda, face evaluări, calculează şi ia decizii logice. Totodată aici sunt
procesate datele şi sunt transmise între nivelurile vecine.
Ultimul nivel este nivelul de date unde informaţia este stocată în baze de date sau fişiere de
sistem. Informaţia este transmisă nivelului logic în vederea procesării, iar în final ajunge la
utilizator într-o formă procesată.

15
Comunicarea între niveluri este sincronă, aceasta fiind de tip cerere răspuns. Cererea este
transmisă de către utilizatorul final într-un singur sens.
În ceea ce priveşte modul în care aplicaţia urmează să fie instalată nu există restricţii,
nivelurile pot rula pe maşini diferite sau pe aceiaşi maşină. în acest mod se oferă un plus de
flexibilitate şi siguranţă.
În figură 3.2 este reprezentată arhitectura sistemului de monitorizare bazată pe structura
multi nivel client-server.

Fig 3.2. Arhitectura sistemului de monitorizare

Nivelul clienţilor este reprezentat de către utilizatorul final ce doreşte să acceseze aplicaţia
prin intermediul unui browser. Nivelul doi va prelua cererea de la client şi o va direcţiona
către nivelul logic. Acest nivel va prelua cererea de la utilizator, o va evalua şi va lua o
decizie. În funcţie de cererea, se vor face solicitări către baza de date sau către mediul de
stocare de tip cloud, acestea fiind componentele nivelului de date. Datele vor fi preluate,
analizate, iar răspunsul cererii se va trimite prin intermediul serverului web către utilizator.

16
Serverele monitorizate vor trimite informaţii către mediul de stocare cloud la un interval
constant de timp. Sistemul logic de analiza reprezentat de nivelul trei va face cereri
constante la acelaşi interval de timp către mediul de stocare cloud în vederea accesării
informaţiilor.
Sunt multiple avantaje ale arhitecturii N-tire Client-Server. Modelul N-tire face ca
aplicaţiile să fie mult mai uşor de înţeles şi le oferă un grad înalt de reutilizare. Luând în
considerare evoluţia afacerilor şi a traficului de informaţie, fiecare nivel al arhitecturii
poate să fie extins, lucru ce îmbunătăţeşte scalabilitatea.
Considerentele cu privire la dezvoltarea ulterioară a aplicaţiei se referă la modul în care
sistemul de monitorizare poate să fie extins în vederea monitorizării unui număr mai mare
de servere. Arhitectura aleasă va susţine evoluţia aplicaţiei. În cazul în care se doreşte
schimbarea furnizorilor de servicii de baze de date sau cloud, schimbările vor avea loc
numai la nivelul de date al arhitecturii.
S-a demonstrat ca arhitectura N-Tire aduce îmbunătăţiri tehnologiei standard Client-
Server, fiind utilizată pentru crearea de pagini web, aplicaţii dinamice web sau servicii.
Acest aspect oferă mari avantaje mai ales în cazul utilizării structurii MVC
(ModelViewController), ce separa interfaţa disponibilă utilizatorului, de logica
programului şi de modelul de date.

3.2 Analiza metodelor de rezolvare a problemei şi selectarea

soluţiei tehnice

3.2.1 Cloud computing

Odată cu dezvoltarea la nivel global a Internetului, afacerile au început să migreze din

mediul tradiţional către cloud.
Cloud computing este o nouă paradigmă importantă pentru furnizarea de servicii
computerizate, în cazul în care serviciile sunt accesate de la distanță prin Internet, mai
degrabă decât furnizate pe calculatoarele locale. Beneficiile cheie ale cloud computing-ul
sunt elasticitatea resurselor - cerințele dumneavoastră se pot scala la cerere și posibilitatea
de a avea acces la informații de oriunde, folosind orice dispozitiv. Cred că aceasta este una
dintre cele mai interesante noi dezvoltări în informatică cu mari oportunități pentru
cercetare și inovare.
Cloud Computing reprezintă un serviciu de închiriere a resurselor, atât hardware, cât şi
software, utilizatorul beneficiind de capacităţi virtuale de procesare şi stocare ce stau la
dispoziţia sa prin accesarea Internetului.
Trei aspecte puternice ce îi aduc o mare parte din popularitate acestui serviciu sunt
siguranţa datelor stocate, preţul redus raportat la puterea de procesare şi spaţiul utilizabil şi
portabilitatea fişierelor ce pot fi accesate de oriunde există o conexiune la Internet.
Necesitatea construirii încrederii în furnizorul de servicii cloud implica un factor
important, certificările de calitate precum ISO 20000. Aceste certificări îi permit
furnizorului să dovedească că serviciile sale oferă securitate, un management puternic
pentru gestiunea datelor şi asigură dinamica cerinţelor clientului.
Soluţia Cloud Computing este un concept global ce oferă acces la resurse nelimitate şi vine
în ajutorul afacerilor actuale ce sunt nevoite să adauge capacităţi noi în mod dinamic
Din punct de vedere topologic, un serviciu cloud computing are la bază următoarele
elemente: clienţi, servere distribuite şi centre de date. Aşa cum este prezentat şi în figură

17
3.3, aceste componente constituie elementele unei soluţii cloud computing. Fiecare
element are un scop bine determinat şi joacă un rol specific în livrarea funcţionalităţilor
unei aplicaţii bazate pe cloud.
Clienţii reprezintă în arhitectura cloud computing ceea ce reprezintă şi în cunoscutul LAN
(reţeaua locală), mai exact, un client este orice dispozitiv prin care utilizatorul îşi
gestionează datele din cloud.
Un centru de date este reprezentat de o colecţie de servere ce găzduieşte aplicaţia la care te
abonezi.
Însă serverele nu trebuie să fie în aceiaşi locaţie. În general serverele sunt divizate din
punct de vedere geografic, însă utilizatorul le vede ca fiind conectate. Aceste servere,
numite servere distribuite oferă mai multă flexibilitate şi siguranţă, deoarece dacă o locaţie
este afectată datele sunt recuperate cu ajutorul redundantei implementate.

Figura 3.3. Topologia Cloud Computing

Sursă: Toby Velte, Anthony Velte, Robert Elsenpeter, “Cloud Computing, A Practical
Approach”

3.2.2 Justificarea soluţiei Apache + PHP + MySQL

Pentru dezvoltarea şi implementarea sistemului de monitorizare am optat pentru grupul

Apache + MySQL + PHP. Folosirea serverului HTTP APACHE ca web server, a
limbajului de programare PHP şi a sistemului de gestionare a bazelor de date relaţionale
MySQL face ca aceasta triadă să fie una dintre cele mai populare soluţii pentru dezvoltarea
platformelor web.
Popularitatea sa vine în principal de la gratuitatea tehnologiilor, acestea fiind open source.

Fără îndoială simbioză dinte cele trei tehnologii a dus la creşterea popularităţii lor, datorată
uşurinţei de creare şi întreţinere a elementelor dinamice în paginile web. My SQL este un
sistem pentru baze de date rapid şi uşor de folosit ce oferă aproape tot ce este necesar
pentru un website în ordine să găsească şi să trimită datele către browser. Când PHP se

18
alătură sistemului de baze de date pentru achiziţionarea şi utilizarea datelor, putem să
spunem că avem părţile fundamentale necesare pentru dezvoltarea paginilor web.
Performanțe mari în crearea paginilor web dinamice, dimensiuni relativ reduse ale codului
sursă şi nivelul de documentaţie ce stă la dispoziţia dezvoltatorului sunt beneficii mari ce
justifică alegerea acestui grup de tehnologii pentru dezvoltarea sistemului de monitorizare.
Însă aspectul hotărâtor în vederea acestei decizii a fost compatibilitatea cu toate sistemele
de operare actuale. Evoluţia viitoare a aplicaţiei depinde de acest aspect deoarece aplicaţia
se poate modifica pentru a se preta la o gamă largă de sisteme de operare utilizate pentru
servere: sisteme bazate pe unix, precum Solaris, Linux sau Red Hat Enterprise Linux,
Windows Server sau Mac OS X Server.

Datorită fluxului mare şi caracterului sensibil al datelor ce sunt gestionate în cadrul

aplicaţiei dezvoltate, securitatea reprezintă un punct central îl adoptarea tehnologiilor şi
instrumentelor informatice folosite. Serverul Apache http, folosit în prezent în 65.2 % din
paginile web, joacă un rol cheie în problematica securităţii, satisfăcând cerinţele unui
server HTTP prin securitatea sporită şi eficiență în funcţionare. Totodată fiind open source
întreţinerea şi rezolvarea bug-urilor este foarte rapidă datorită comunităţii extinse.
Structura modulara a serverului Apache permite extensia funcţionalităţilor acestuia.
Modulul de securitate mod_ssl, este un modul de securitate pentru Serverul Apache HTTP.
Acesta foloseşte uneltele folosite de librăria OpenSSL pentru a aduce o caracteristică foarte
importantă serverului Apache, abilitatea de a cripta comunicaţiile. În comparaţie cu
utilizarea unui server HTTP fără această funcţionalitate, comunicaţiile dintre browser şi
serverul web se fac prin transmiterea unui text simplu, ce poate să fie interceptat pe ruta
dintre browser şi server, lucru nedorit în lucrul cu informaţii ce trebuie să rămână
confidenţiale deoarece sunt critice pentru securitate.

3.2.3 PHP

PHP este un limbaj de scripting orientat către partea de servere foarte potrivit pentru
paginile web dinamice. Datorită suportului integrat pentru lucrul cu bazele de date ca
MySQL, PHP este o unealtă ideală pentru crearea de aplicaţii complexe ce gestionează un
număr mare de date.
PHP reprezintă acronimul de la” PHP: Hypertext Preprocessor” şi a fost conceput de către
Rasmus Lerdorf în anul 1995 în scopul de a avea o modalitate uşoară de procesare a
datelor şi creare a paginilor web.
PHP este un puternic limbaj de scripting folosit pentru dezvoltarea paginilor şi aplicaţiilor
web ce nu necesită compilare, acesta poate rula pe orice dispozitiv ce are PHP instalat.
Însă, PHP nu este suficient de puternic singur pentru a construi pagini web dinamice.
Pentru a utiliza PHP într-o pagină web avem nevoie de un server ce poate procesa scripturi
PHP. [11]
Deoarece nu este nevoie de compilare, codul este foarte uşor de modificat şi testat.
Procesul de compilare al fişierelor în cod maşină este costisitor din punct de vedere al
timpului, absenţa acestui proces reprezentând un mare avantaj.
În comparaţie cu HTML, care este parsat de către browser atunci când este încărcată
pagină web, PHP este procesat de către server înainte să fie trimis către browser.

O alternativă la alegerea limbajului de programare PHP o constituie limbajul orientat

obiect C# integrat în ASP.NET. Comparând cele două limbaje se pot evidenţia următoarele
aspecte:

19
În comparaţie cu PHP, limbajul C# prezintă două puncte forţe: este un limbaj orientat
obiect şi poate utiliza paralelismul ceea ce îi aduce un plus de performanţă, dar codul scris
în PHP este mult mai rapid în lucrul cu procesorul şi este mult mai bine integrat în
sistemele bazate pe UNIX.
În aplicaţia dezvoltată pentru monitorizarea serverelor, se evaluează servere ce rulează
sistemul de operare Solaris, bazat pe UNIX. Luând în calcul aceste factor limbajul de
programare PHP este mult mai compatibil în cazul de faţă.

3.2.3.1 Yii PHP Framework

Limbajul de scripting PHP beneficiază de o gamă largă de frameworkuri dezvoltate. Un

framework reprezintă o colecţie de clase ce vine în ajutorul dezvoltatorului în vederea
creării unei aplicaţii.
Yii PHP este un framework open source ce se evidenţiază prin performanta ridicată, fiind o
componentă importantă pentru dezvoltarea aplicaţiilor Web 2.0.
Yii a fost dezvoltat de către Qiang Xue, în decursul anului 2008 şi vine cu o serie de
caracteristici importante precum MVC, DAO/ActiveRecord, controlul accesului bazat pe
rol, I18N/L10N, autentificarea utilizatorilor, un sistem de caching, control complet asupra
configuraţiilor, scalabilitate şi fiabilitate. Toate aceste trăsături reduc semnificativ timpul
necesar pentru dezvoltarea aplicaţiilor web şi API.
Datorită caracterului său extensibil şi a optimizării performanţei, acest framework este
ideal pentru proiectele mari ce vor avea dezvoltări ulterioare.
Totodată un alt aspect hotărâtor în decizia utilizării acestui framework este pachetul de
unelte puternice pentru debuging şi testare cu care YII vine în ajutorul dezvoltatorilor.
Comparând YII cu celelalte frameworkuri disponibile la momentul actual se poate observa
superioritatea acestuia.

Fig. 3.4. Comparaţie a performanţelor frameworkurilor PHP

Sursă: http://www.yiiframework.com

20
3.2.4 MySQL

În stadiul incipient al utilizărilor paginilor web, erau foarte utilizate fişierele text simple
pentru stocarea datelor precum nume de utilizatori şi parole. Această practică era foarte
sensibilă şi putea deveni uşor problematica când era accesata simultan de mai mulţi
utilizatori. Totodată un astfel de fişier poate deveni uşor foarte mare şi greu de gestionat.
În prezent bazele de date relaţionale ce au la baza interogări bine structurate devin
esenţiale, fiind o alternativ mult superioară. MySQL este un sistem de gestiune al bazelor
de date relaţional (SGBD) ce îşi câştigă rapid popularitatea deoarece este gratuit, fiabil,
robust, foarte rapid şi uşor de instalat în interiorul unui web server.
Iniţial a fost dezvoltat pentru gestiunea bazelor de date de dimensiuni mari într-o manieră
mai uşoară şi mai rapidă faţă de SGBD-urile similare existente.
MySQL este compatibil cu o multitudine de platforme, este stabil, beneficiază de
mentenanţă şi actualizare constantă, iar documentaţia excelentă disponibilă îl face uşor de
învăţat.
Utilizarea sa este foarte des în pereche cu limbajul de programare PHP şi permite
dezvoltatorilor să stocheze datele în tabele în vederea organizării informaţiei.
My SQL este un server de baze de date SQL multi-utilizator, permiţând accesul simultan la
date.
În componentă cu PHP şi serverul web Apache formează un instrument puternic pentru
crearea paginilor web dinamice.

3.2.5 Apache

Serverul Apache HTTP, ce se face prezent încă din jurul anului 1995, este o tehnologie
robustă, modulară, fiabila, iar datorită regimului open source în care este lansată, gratuită şi
actualizata în mod constant.
Aceste trăsături fac acest instrument informatic să fie unul de referinţă pentru toate
serverele web de pe piaţă, fiind considerat cel mai popular server web la momentul actual.
O altă caracteristică importantă este compatibilitatea cu o gamă largă de sisteme de
operare: Unix, Linux, Windows.
Datorită simbiozei cu limbajul de programare PHP este o alegere naturală în vederea
elaborării aplicaţiei descrisă în această lucrare.

3.2.5.1 Modulul mod_ssl

Companiile Netcraft şi E-Soft oferă statistici lunare, analizând un set reprezentativ de

servere web pe internet. Din acestea putem observa că serverul Apache acoperă 60% din
piaţă. Totodată din 1999 aceleaşi două companii au început să ofere detalii suplimentare în
care să diferenţieze statisticile în funcţie de module. Modulul mod_ssl se bucura în ultimii
doi ani de o popularitate de aproximativ 60% în comparaţie cu tehnologiile asemănătoare
concurente.

Modulul mod_ssl combina flexibilitatea serverului Apache cu securitatea librăriei

OpenSSL.
Modulul oferă capacitatea puternică de a criptografia serverul Apache prin intermediul
Secure Sockets Layer (SSL) şi a protocoalelor Transport Layer Security (TLS).

21
Librăria OpenSSL ne oferă o comunicare securizată între client, aplicaţia dezvoltată şi
server, permiţând o autentificare reciprocă, utilizând semnături digitale pentru integritate şi
criptare pentru protecţia datelor.

3.2.6 Dropbox

Dropbox este un serviciu de cloud fondat în toamna anului 2008 ce oferă spaţiu de stocare
pentru poze, documente, filmări şi fişiere. Tot ceea ce este adăugat în Dropbox este partajat
către toate dispozitivele de unde contul aferent este accesat, datorită sincronizării fişierelor,
acest lucru permiţând accesarea datelor indiferent de locaţie.
Deoarece protecţia datelor a reprezentat o prioritate pentru dezvoltatorii acestui serviciu,
utilizatorii beneficiază de o securitate bine pusă la punct.
O integrare puternică în aproape toate sistemele de operare, dispunerea unui istoric ce
conţine toate acţiunile efectuate pe durata unei luni şi uşurinţa în instalare şi utilizare fac
din Dropbox un serviciu utilizat cu încredere de peste 500 de milioane de utilizatori.
Prin comparaţie cu alte servicii de cloud prezente, spre exemplu Google Drive, Dropbox
prezintă, din punct de vedere al costului, vitezei şi securităţii, beneficii suplimentare.
Securitatea bazată pe Secure Sockets Layer (SSL) şi criptarea AES pe 25 de biţi, viteza de
sincronizare şi accesibilitatea fişierelor independentă de locaţie şi platforma sunt aspecte ce
sunt urmărite în dezvoltarea aplicaţiei de monitorizare a serverelor. Toate acestea se
regăsesc în acest serviciu de cloud.

3.2.6.1.1 Dropbox API, Dropbox-sdk-php şi Composer

Un mare beneficiu al utilizării serviciului de cloud Dropbox este reprezentat de propriul

SDK compatibil cu o gamă mare de limbaje de programare, ce stă la dispoziţia
dezvoltatorului de aplicaţii.
Dropbox ne oferă posibilitatea de creare a aplicaţiilor cu interfaţa programabila (API) în
vederea integrării acestui serviciu în propria aplicaţie. Kitul de dezvoltare Dropbox-sdk-
php ne permite să facem legătura dintre aplicaţia dezvoltată şi aplicaţia API din cadrul
Dropbox.
Dropbox are integrat OAuth 2.0 pentru autorizarea cererilor de acces către aplicaţia API.
Autentificarea are la bază un token, o cheie de securitate şi un App Secret. Aceste trei
componente sunt generate la crearea aplicaţiei şi constituie modul securizat prin care se
poate face comunicarea cu aplicaţia.
Totodată oferă posibilitatea gestionarii utilizatorilor ce au acces la dosarele prevăzute în
aplicaţie, statistici pe o durată de 90 de zile şi a modului de autentificare permis.

Integrarea bibliotecilor din kitul de dezvoltare ce face legătura între aplicaţia API şi cea
dezvoltată concomitent cu framworkul YII poate să devină greu de gestionat. Fiecare
librărie poate avea dependenţele sale proprii şi poate duce la îngreunarea modului de
dezvoltare în special în lucrul în echipă. O soluţionare la acesta problemă o reprezintă
Composer. Composer reprezintă un manager pentru dependenţele utilizate în PHP ce va
gestiona bibliotecile şi dependenţele acestora.
O alternativă pentru Composer o reprezintă PEAR, însă acesta a fost abandonat de un
număr mare de dezvoltatori de aplicaţii datorită necesităţii instalării de pachete la nivel de
sistem în comparaţie cu Composer care necesită instalarea acestora la nivel de proiect.

22
3.2.7 Sistemul de operare Solaris

Solaris este un sistem de operare dezvoltat de Sun Microsystems bazat pe UNIX. Cu toate
că Solaris rămâne o proprietate a companiei Oracle, multe dintre componentele sale au fost
integrate într-o versiune open source numită OpenSolaris.
Capacităţile dinamice de urmărire (DTrace), procesul de management al drepturilor şi
capacitatea de autodiagnosticare ale acestui sistem de operare ajuta la obţinerea ratei mari
de utilizare fără compromiterea nivelului de servicii, securităţii şi confidenţialităţii.

Funcţionalitatea Solaris Containers integrată în sistemul de operare începând cu versiunea

10 aduce mari îmbunătăţiri în utilizarea sistemului datorită posibilităţii de rulare a mai
multor aplicaţii şi servicii izolate pe un singur sistem, ceea ce permite o consolidare mult
mai uşoară a serverelor.
Solaris ne permite într-un mod uşor şi sigur construirea de containere personalizate,
izolate, fiecare cu propriile adrese IP, sisteme de fişiere, utilizatori şi resurse alocate.

Fig. 3.5. Exemplu de consolidare a zonelor

Performanţele acestui sistem de operare sunt date de garanţia alocării suficiente de CPU şi
memorie către aplicaţii, păstrând în acelaşi timp capacitatea de utilizare a resurselor
inactive în funcţie de necesitate.
Îşi rezervă şi îşi alocă un CPU sau un grup de CPU specific în exclusivitate pentru
utilizarea containerului.
Solaris este proiectat să ruleze aplicaţii chiar şi în decursul mentenanţei de rutină sau în
cazul apariţiei unor defecţiuni software sau hardware. Acest lucru îl face ideal pentru
serverele dintr-un centru de date sau o fermă de servere.

23
Are integrat un sistem de recuperare automată în cazul în care apar anumite defecţiuni,
această funcţionalitate ajută la menţinerea unui timp mort de funcţionare aproape de zero,
în special când este utilizat cu serverele SunFire cu care acest sistem de operare a
dezvoltată o simbioză.
Solaris oferă caracteristici avansate ce permit securizarea sistemelor şi consolidarea
serviciilor.
Restartarea automată a componentelor sale, administrarea de servicii simplificată pentru a
ajuta la reducerea volumului de muncă şi a erorilor, reparări şi actualizări de software
online, protecţie împotriva defectelor la nivelul datelor şi recuperarea lor rapidă sunt doar
câteva dintre beneficiile sistemului de operare Solaris.
În timpul de execuţie al sistemului de operare, diverse contoare sunt incrementate în
vederea urmăririi anumitor activităţi de sistem.
Sunt urmărite cu precădere utilizarea unităţii centrale de procesare (CPU), utilizarea
bufferelor, activităţile de scriere şi citere pe disc, accesul la fişiere, comunicaţia dintre
procesoare, lucrul cu reţelele, spaţiul de swap şi memoria RAM.
Sistemul de operare Solaris pune la dispoziţia utilizatorului o serie de unelte ce pot fi
utilizate în vederea depistării nivelului de performanţă aferent, după cum urmează:
Pentru monitorizarea comportamentului sistemului din punct de vedere al utilizării unităţii
centrale de procesare avem la dispoziţie comenzile cpustat şi cputrack.
Pentru evaluarea lucrului cu reţelele se evidenţiază comenzile netstat şi nfsstat.

3.2.8 Shell Scripting

Termenul "Shell Scripting"este menţionat des în comunităţile de Linux, deoarece această

metodă puternică de programare poate salva timp, să ajute la învăţarea mai bună a
comenzilor utilizate în terminale şi să optimizeze gestionarea fişierelor.
Fiind un utilizator al sistemelor de operare bazate pe UNIX ajungi să lucrezi foarte mult în
linie de comandă. Aşa numita linie de comandă este ea însăşi un program, numit shell ce
acceptă comenzi de la utilizator şi le execută. Dacă se doreşte utilizarea unei secvenţe de 'n'
comenzi, această secvenţă se poate stoca în interiorul unui fişier text. Acest fişier poartă
numele de shell scripting şi este trimis spre execuţie către shell în locul tuturor comenzilor
din care este alcătuit. Mai exact, shell scripingul reprezintă o serie de comenzi de BASH
scrise într-un fişier text simplu.
Este foarte util în crearea propriilor comenzi, iar administrarea sistemului se poate face
automat. Poate apela prin intermediul comenzilor din interior alte scripturi şi poate să fie
programat să ruleze la un anumit moment de timp.
În vederea interogării sistemului printr-un set de comenzi succesive ce duc la colectarea
setului de date necesar analizei serverelor shell scriptingul reprezintă metoda ideală.

4 Implementare
4.1 Programare
Frameworkul YII se bazează pe o structură MVC (Model-View-Controller).
Subsistemele acestei structuri sunt încadrate într-una dintre următoarele categorii:
controler, model sau vedere.
Acesta structura permite adăugarea de vederi noi fără a se modifica sistemul în alt fel.

24
Controlerele reprezintă un element al arhitecturii MVC prin care se controlează accesul în
aplicaţie. Acesta acceptă date de intrare (cereri) ce sunt convertite în comenzi ce urmează a
fi trimise către model în vederea modificării stării acestuia. Controlerele sunt compuse din
acţiuni care reprezintă unitatea cea mai de bază pe care utilizatorul o poate accesa şi căreia
îi poate solicita executarea. Modelele stochează informaţii achiziţionate conform
comenzilor de la controlator, informaţii ce urmează a fi afişate în vederi. O vedere
generează o interfaţă către utilizator bazată pe modificările ce s-au produs în modelul
asociat.
Aplicaţia dezvoltată prezintă un controlor principal denumit SiteController ce extinde clasa
frameworkului YII 2.0 Controller. Prin intermediul acţiunilor prezente în controlerul
SiteController sunt trimise comenzi către alte patru controlere: DropboxKeysController,
UserSmController, UserServerController şi VersionsController.
Controlerul SiteController prezintă următoarele acţiuni:
- ActionIndex () - această acţiune verifica dacă un utilizator este logat. În cazul unui
răspuns negativ este afişată pagina de autentificare, altfel este randată pagina principală a
aplicaţiei.
- ActionLogin () - distruge sesiunea curentă, crează un nou obiect de tip utilizator şi este
randata pagina de autentificare. În cazul unei autentificări valide este creată o nouă sesiune,
userul este salvat în sesiune şi se redirecţionează către pagina principală.
- ActionLogout () - este eliminat utilizatorul din sesiunea curentă şi se face redirecţionare
către pagina de autentificare.
- ActionAdminPage () - această acţiune verifica dacă un utilizator admin este logat. În
cazul unui răspuns negativ este afişată pagina de autentificare, altfel este randata pagina
principală a aplicaţiei asociată utilizatorului admin.
- ActionServers () - este achiziţionată lista de servere asociate utilizatorului înscris în
sesiunea curentă şi este randată pagina cu serverele utilizatorului curent. În cazul în care
utilizatorul este admin, pagina va conţine o lista a tuturor serverelor monitorizate,
indiferent de utilizatorul de care aparţin.
- ActionVersions () - se verifică dacă utilizatorul este înscris în sesiunea curentă. Dacă
răspunsul este afirmativ se face trimitere către acţiunea actionView () din controllerul
VersionsController. Un răspuns negativ al verificării întoarce pagina de autentificare.
- ActionAddUsers - se verifică dacă utilizatorul este înscris în sesiunea curentă. Dacă
răspunsul este afirmativ se face trimitere către acţiunea actionIndex () din controllerul
UserSmController. Un răspuns negativ al verificării întoarce pagina de autentificare.
- ActionManageDropbox - se verifică dacă utilizatorul este înscris în sesiunea curentă.
Dacă răspunsul este afirmativ se face trimitere către acţiunea actionView () din controllerul
DropboxKeysController. Un răspuns negativ al verificării întoarce pagina de autentificare.
- ActionAddServer () - se verifică dacă utilizatorul este înscris în sesiunea curentă. Dacă
răspunsul este afirmativ se face trimitere către acţiunea actionIndex () din controllerul
UserServerController. Un răspuns negativ al verificării întoarce pagina de autentificare.
- ActionViewServer () - se face trimitere către acţiunea actionDashboard () din controlerul
ServerController.
- ActionHelp () - este returnat manualul de utilizare al aplicaţiei în format PDF în funcţie
de tipul utilizatorului.
Controlerul UserSmController face legătura între modelul UserSm şi vederile sale,
permiţând crearea de utilizatori noi, vizualizarea utilizatorilor deja existenţi, ştergerea
acestora şi actualizarea informaţiilor asociate lor.
Acest controller conţine următoarele acţiuni:
- ActionIndex () - este încărcată pagina index a modelului userSm.

25
- ActionCreate () - se crează un obiect nou de tip UserSm, este încărcată pagina Create a
modelului UserSm, ce la rândul ei apelează formularul _form.php al aceluiaşi model.
- ActionUpdate () - este încărcată pagina Update a modelului UserSm, care apelează
formularul _form.php al aceluiaşi model. Obiectul de tip UserSm este deja existent.
- ActionView () - este randata pagina View a modelului UserSm, ce afişează informaţii
legate de obiectul selectat.
- ActionDelete () - şterge lista de servere asociate utilizatorului selectat. Caută în baza de
date utilizatorul selectat şi îl şterge. Întoarce pagina Index a modelului UserSm.
În interiorul controllerului UserSmController este definită şi funcţia findModel () ce caută
un obiect de tip UserSm în baza de date în funcţie de id şi îl returnează. Această funcţie
este de tip protected şi poate să fie accesata numai în interiorul controlerului.

Controlerul VersionsController permite utilizatorului admin să vizualizeze sau să modifice

versiunile pachetelor şi a sistemului de operare. în acest controler sunt definite următoarele
acţiuni:
- ActionView () - este randata pagina View a modelului Versions, ce afişează informaţii
legate de obiectul selectat.
- ActionUpdate () - este încărcată pagina Update a modelului Versions, care apelează
formularul _form.php al aceluiaşi model.
În interiorul controlerului VersionsController este definită şi funcţia protected care prezintă
aceiaşi funcţionalitate ca şi în cazul controlerului UserSmController.

Controlerul DropboxKeysController permite utilizatorului admin să gestioneze datele de

autentificare la mediul de stocare Dropbox.
Acţiunile definite în acest controller, alături de funcţia findModel ce prezintă acelaşi
comportament ca şi la celelalte controlere, sunt următoarele:
- ActionView () - este randata pagina View a modelului DropboxKeys, ce afişează
informaţii legate de obiectul selectat.
- ActionUpdate () - este încărcată pagina Update a modelului DropboxKeys, care apelează
formularul _form.php al aceluiaşi model.

Controlerul UserServerController este responsabil de acţiunile ce gestionează şi returnează

paginile cu informaţiile legate de servere.
În interiorul acestui controler este definită funcţia findModel () şi deasemenea următoarele
acţiuni:
- ActionIndex () - este încărcată pagina index a modelului UserServer.
- ActionView () - este randată pagina View a modelului UserServer, ce afişează informaţii
legate de obiectul selectat.
- ActionCreate () - se crează un obiect nou de tip UserServer, este încărcată pagina Create
a modelului UserServer, ce la rândul ei apelează formularul _form.php al aceluiaşi model.
- ActionUpdate() - este încărcată pagina Update a modelului UserServer, care apelează
formularul _form.php al aceluiaşi model.
- Action Delete () - Caută în baza de date serverul selectat şi îl şterge. Întoarce pagina
Index a modelului UserServer.
- ActionDashboard() - este returnată vederea ce conţine pagina Dashboard a serverului
selectat.
- ActionConfig () - este returnată vederea ce conţine pagina Configuration.
- ActionMentenance () - este returnată vederea ce conţine pagina Mentenance.
- ActionPerformance () - este returnată vederea ce conţine pagina Performace.

26
Modelele ce primesc comenzi de la controllerele definite în cadrul aplicaţiei reprezintă o
extensie a clasei frameworkului YII 2.0\yii\db\ActiveRecord.

Modelul Dropbox Keys primeşte comenzi de la controllerul DropboxKeysController şi are

definite următoarele funcţii în interiorul său:
- Tablename () - este o funcţie de tip public static ce întoarce numele tabelei pe care este
bazat modelul.
- Rules () - funcţia întoarce către vedere coloanele din tabela modelului şi restricţiile
acestora. Restricţiile sunt utilizate pentru validarea formularului de create/update.
- AttributeLabels() - funcţia întoarce denumirea formatată a coloanelor. Se introduc şiruri
de caractere ce urmează să reprezinte denumirea coloanelor. Aceste denumiri urmează să
fie folosite în interiorul vederilor asociate modelului.
- Connect () - este o funcţie de tip public static care crează o conexiune către mediul de
stocare Dropbox. Sunt folosite informaţiile din obiectul Dropbox Keys şi din obiectul de
tip Users.

Modelul UploadForm este utilizat pentru încărcarea, de către utilizatori, a imaginilor ce

urmează să simbolizeze logo-ul companiei. Este definit un parametru de tip şir de caractere
şi următoarele funcţii:
- Rules () - funcţia prezintă aceeaşi funcţionalitate ca şi în cazul modelului DropboxKeys.
- Upload ($id) - $id reprezintă numărul de identificare al utilizatorului ce face încărcarea
imaginii şi este folosit ca parametru de intrare în această funcţie. Se salvează imaginea cu
numele $id, fiind asociată astfel cu utilizatorul.
În interiorul modelelor UserServers, UserSm, Users şi Versions sunt definite următoarele
trei funcţii:
- Tabelname () - funcţie ce întoarce numele tabelei asociate modelului din care este
executată.
- Rules () - funcţia prezintă aceiaşi funcţionalitate ca şi în caul modelului DropboxKeys.
- AttributeLabels () - funcţia prezintă aceiaşi funcţionalitate ca şi în caul modelului
DropboxKeys.

S-a utilizat o bază de date pentru aplicaţie, întrucât este o metodă rapidă de stocare şi citire
de informaţii, şi în acelaşi timp şi o metodă mai sigură decât stocarea manuală în sisteme
de fişiere. În această bază de date sunt stocate cheile necesare conectării cu mediul de
stocare cloud, userii aplicaţiei, serverele monitorizate, versiunile pentru sistemul de
operare Solaris şi pachetele pentru care acestea sunt monitorizate şi numărul de
notificări,erori,avertismente şi eşecuri pentru fiecare server, de la ultima analiză a datelor
acestora.
Baza de date este de tip InnoDB, şi are următoarele tabele:
Tabelul dropbox_keys, ce conţine o singură intrare ce are un id şi trei coloane ce reprezintă
cheia de acces pentru Dropbox (dropbox_key), cheia secretă de acces la Dropbox
(dropbox_secret), şi numele Dropboxului (app_name).
Tabelul users, cu o singură intrare ce are un id, numele userului admin (username) şi
token-ul de conectare la Dropbox (dropbox_token).
Tabelul user_sm, ce conţine utilizatorii aplicaţiei, ce au un id, un nume (username), o
parolă criptata cu md5 (password), o coloană ce specifică dacă utilizatorul este admin sau
nu (isAdmin), numele clientului (customer_name), ce este gol pentru admin, email-ul
clienţilor (email), gol pentru admin, şi numărul maxim de servere ce poate un user să şi le
adauge spre monitorizare (server_ limit).

27
Tabelul user_server conţine serverele ce sunt monitorizate ce au cheie de identificare (id),
id-ul userului de care aparţin (user_id), numele serverului (hostname), locaţia serverului
(location), două câmpuri în care sunt salvate data la care s-a făcut ultima oară analiza
datelor de pe server (last_update) şi data la care s-a încercat ultima analiză a datelor şi
aceasta nu a reuşit (no_update). O ultimă coloană (new), specifică dacă serverul a fost
adăugat dar nu a fost încă acceptat de către admin pentru a fi monitorizat.
Tabelul versions, ce conţine o singură intrare cu o cheie de identificare (id) şi câte o
coloană pentru fiecare versiune monitorizată.
Tabelul messages ce conţine numărul de mesaje ale serverelor. Fiecare intrare are o cheie
de identificare (id), cheia de identificare a serverului de care aparţin (host_id), tipul intrării
(type), ce poate fi de tip Messages, Performance sau Configuration, şi câte o coloană
pentru numărul de erori, avertismente, eşecuri şi notificări de acel tip pentru server.

4.2 Colectarea datelor de pe servere

În vederea colectării datelor de pe servere a fost realizat un shell script cu numele
SM_collect.sh.
Scriptul verifică dacă există suficient spaţiu pe sistem pentru a putea crea un director
temporar în vederea stocării datelor ce urmează a fi trimise către mediul de stocare.
Pentru a evita problemele ce pot apărea din cauza spaţiului lipsă pentru copierea datelor
iniţial scriptul verifică dacă în directorul rădăcină al utilizatorului exista cel puţin 1 GB
liber. În cazul în care spaţiul necesar nu exista pe disc se afişează următorul mesaj de
eroare: "You do not have enough space to collect the data needed! Execution aborted!" şi
se va iniţia întreruperea scriptului.
Dacă există suficient spaţiu de stocare pe sistemul monitorizat va începe procedura de
colectare a datelor.
Se va crea o variabilă cu numele "now" în care se va stoca data şi ora curentă. Cu ajutorul
acestei variabile este iniţializata o a doua variabilă denumită directory. Variabilă directory
este iniţializata cu "SM_$now", acest lucru generând un şir de caractere cu prefixul SM şi
prefixul datei şi orei curente.
Se crează directorul temporar cu numele conţinutului variabilei directory.
Se începe interogarea sistemului în vederea obţinerii datelor generale despre configuraţia
acestuia.
În directorul temporar se crează un fişier denumit date.txt în care se vor scrie ziua, dată,
oră şi fusul orar asociat locaţiei serverului. Fişierul este creat cu ajutorul comenzii date ce
afişează data şi ora sistemului.
Comanda uname -a este utilizată în vederea creării fişierului OS_version.txt. Comanda
returnează informaţiile despre sistem precum ce sistem de operare rulează, ce versiune a
sistemului de operare rulează şi numele gazdei (sistemului).
Pentru a returna data şi ora de când sistemul este pornit se va apela comanda last. Comanda
last va afişa toate datele la care sistemul a fost oprit şi pornit. Prima linie a tabelei returnate
este reprezentată de ultima pornire a sistemului. Pentru a selecta scrierea în fişier doar a
datei respective se va aplica comenzii last comanda grep ce va selecta linia ce conţine doar
parametrul precizat. Funcţia grep primeşte ca parametrul şirul de caractere "still" deoarece
ultima linie are precizat still up în dreptul ultimei coloane. Coloanele 4,5,6 şi 7 reprezintă
ziua, data şi ora de pornire a sistemului. Pentru a izola doar cele patru coloane pentru
înscrierea în fişier alături de comenzile last şi grep se utilizează o a treia comandă ce vă
primii ca parametru numărul coloanelor dorite.

28
Last |grep still | awk ' {prinţ $4, $5, $6, $7} ' >
$directory/uptime.txt

Fişierul system_type.txt conţine informaţii despre numărul de biţi pe care rulează sistemul,
64 sau 32. În vederea obţinerii acestei informaţii este utilizată funcţia isainfo -kv.
Pentru a afla numărul de procesoare ce sunt disponibile sistemului monitorizat se crează
fişierul nr_of_cpu.txt ce va conţine rezultatul comenzii psrinfo-p. Comanda returnează un
număr întreg ce reprezintă numărul de procesoare.
Fiecare sistem are un identificator unic cunoscut ca id-ul gazdei. Acesta este înscris într-o
variabilă de sistem denumită hostid. Conţinutul variabilei respective este scris în fişierul
hostid. Tx.
Pentru a afla memoria RAM disponibilă pe sistem se va rula comanda prtconf. Comanda
returnează informaţii despre configuraţia sistemului. Rezultatul include memoria totală şi
configuraţia perifericelor formatate ale sistemului. Pentru a izola informaţiile despre
memorie de celelalte se utilizează comanda grep ce primeşte ca parametru şirul de
caractere "Memory" în paralel cu comanda prtconf. Rezultatul este înscris în fişierul
totalMemory.txt.
SRU reprezintă abrevierea de la Support Repository Update şi este pachetul ce conţine
actualizările pentru versiunea de sistem. Pentru obţinerea versiunii de SRU ce este instalată
pe sistem este utilizată comanda pkg info entire în paralel cu comanda grep ce primeşte ca
parametru şirul de caractere "Branch". Rezultatul este salvat în fişierul sru.txt.
Urmează colectarea mesajelor de sistem. Sistemul crează fişiere denumite messages în
directorul/var/adm unde stochează informaţii despre operaţiile desfăşurate pe server.
Aceste fişiere vor fi colectate în directorul temporar şi li se va schimba extensia în txt
pentru a putea fi citite din mediul de stocare. Fişierelor li se aplică comanda grep cu
parametrii error, ERROR, WARNING, fail şi NOTICE. Cu ajutorul fiecărui parametru se
va genera câte un fişier ce va izola pe rând erorile, avertizările şi notificările generate de
către sistem. Acestea urmează să fie ulterior trimise către utilizatorul final. Deoarece sunt
mesaje gestionate pe înţelesul omului nu necesită o formatare ulterioară.
Pentru a putea evalua performanta sistemului sunt necesare cunoştinţe despre modul în
care procesorul, memoria şi resursele sunt folosite. Comenzile utilizate pentru obţinerea
acestor informaţii sunt comenzi dinamice ce primesc ca parametru timpul de rulare. În
cazul în care timpul nu este specificat rezultatul va coincide cu informaţiile din sistem în
momentul execuţiei comenzii.
Deoarece datele urmează a fi transpune în grafice de performanţă în interiorul aplicaţiei
pentru a putea fi mai uşor înţelese de către om este necesar ca rezultatul comenzilor să fie
concatenat cu timpul ce coincide cu momentul preluării informaţiilor.
Pentru a putea adăuga timpul în fişierele rezultate din aceste comenzi de performanţă a fost
creat un scurt script de perl auxiliar.
#! /usr/bin/perl
While (<>) {prinţ localtime (). ": $_";}
Scriptul va concatena fiecare linie returnată de către comanda ce va fi pusă în execuţie în
paralel cu el cu timpul local al sistemului.
Comenzile utilizate pentru obţinerea datelor despre performanta sistemului se vor rula în
paralel cu acest script ce este apelat cu următoarea expresie: perl numele_fişierului.pl.
Comanda vmstat raportează statistici despre memoria virtuală cu privire la firul de execuţie
al kernelului, activitatea procesorului, memoria RAM, memoria swap. Prima linie a
rezultatului comenzii reprezintă un sumar a informaţiei achiziţionate de la momentul
pornirii sistemului. Pentru a obţine statistici utile în timp real este indicat să se ruleze
comanda vmstat cu un parametru de timp (ex: vmstat 30).

29
Comanda returnează linii cu următoarele coloane:
- Coloana kthr cu subcoloana r reprezintă lungimea cozii de execuţie.
- Coloana kthr cu subcoloana b reprezintă procesele blocate în timp ce aşteptau date de
intrare sau ieşire.
- Coloana kthr cu subcoloana w reprezintă procesele ce erau în aşteptare şi au fost
schimbate.
- Coloana memory cu subcoloana swap oferă informaţii despre spaţiul memoriei swap
nerezervat în Kb.
- Subcoloana free a memorie swap oferă informaţii afişate în Kb despre memoria RAM
liberă disponibilă pe sistem.
- Subcoloana re a coloanei page reprezintă paginile recuperate de pe lista liberă. Dacă o
pagină pe lista liberă conține în continuare datele necesare pentru o nouă cerere, acestea
poate fi remapate.
- Subcoloana mf a coloanei page reprezintă numărul de defecte minore de la un anumit
moment de timp ce au survenit pe sistem.
- Subcoloana pi a coloanei page reprezintă numărul de pagini ce au fost aduse memoria
swap. Acest lucru opreşte din execuţie procesul şi îl pune în aşteptare ceea ce poate să ducă
la scăderi ale performanţei.
- Subcoloana po a coloanei page reprezintă numărul de pagini ce au ieşit din memoria
swap. Pagina a fost scrisă şi eliberată. Acest lucru poate fi rezultatul unei închideri de
fişier.
- Subcoloana fr a coloanei page raportează activitatea scanării paginilor eliberate sau
distruse.
- Page/de - raportează numărul de pagini eliberate după accesarea şi scrierea lor.
- Page/sr - reprezintă numărul total de pagini scanate.
- Disk - oferă informaţii despre activitatea de pe discuri (I/O pe secundă).
- Faults/în - reprezintă întreruperile pe secundă
- Faults/sy - apelurile către sistem pe secundă.
- Faults/cs - întreruperile de context pe secundă.
- Cpu/us - timpul în procente faţă de timpul total activităţii procesorului iniţiat de către
utilizator.
- Cpu/sy - timpul în procente faţă de timpul total în care kernelul utilizează procesorul.
- Cpu/id reprezintă timpul în procente în care procesoarele au fost în aşteptare.
Informaţiile comenzii vmstat au fost rulate pe durata a 60 de secunde şi au fost salvate în
fişierul vmstat.txt.
Comanda mpstat raportează informații utile pentru înțelegerea problemelor de blocare a
procesorului.
Coloanele rezultate din execuţia comenzii sunt următoarele:
- CPU - reprezintă identificatorul unic al procesorului.
- Minf - numărul defectelor minore ce apar în utilizarea procesorului
- Mjf- numărul defectelor majore ce apar în utilizarea procesorului.
- Xcal - apelurile cross ale procesorului. Când un procesor întrerupe un alt procesor. În
cazul în care există mai mult de 200 de întreruperi într-o secundă sistemul trebuie examinat
cu atenţie, acesta fiind un comportament problematic al sistemului.
- Intr- numărul total de întreruperi ale procesorului respectiv.
- Ithr - numărul total de întreruperi ca fir de execuţie, întreruperile ceasului sunt excepţii.
- Csw- interschimbarile de context
- Icsw - interschimbarile de context involuntare. O schimbare de context involuntară poate
să ridice probleme mari la nivelul performanţei.

30
- Migr - migrările firelor de execuţie către un alt procesor. Dacă numărul migrărilor este
mai mare de 500, valoarea parametrului de kernel, rechoose_interval, trebuie să fie
crescută.
- Smtx - reprezintă de câte ori un procesor a eşuat în obţinerea unui mutex. Mutex
reprezintă un obiect de excludere reciprocă ce permite multiple fire de execuţie să
sincronizeze accesul la o anumită resursa comună. O dată ce o resursă este blocată de către
un fir de execuţie, este blocat accesul altor fire de execuţie către acea resursă.
- Srw- reprezintă numărul de eşecuri ale procesorului în obţinerea unei blocări de tip
scriere/citire.
- Syscl - numărul de apeluri către sistem
- Usr/sys/wt/idl - procentul în care un procesor este utilizat de către utilizator/sistem sau
este în aşteptare.
Datele obţinute din execuţia comenzii mpsat sunt salvate în fişierul mpstat_ouţ.txt.
Comanda prstat -mL oferă statistici despre procesele active din sistem. Datele sunt salvate
în fişierul prstat_-mL.txt.
Comanda sar -u oferă informaţii despre timpul da lucru al procesoarelor. Informaţiile
obţinute cu ajutorul acestei comenzi sunt utilizate în interiorul aplicaţiei pentru crearea
graficului de activitate al procesoarelor.

Date despre modul în care a fost configurat sistemul au fost colectate cu următoarele
comenzi.
Rezultatul comenzii psrinfo -pv se salvează în fişierul psrinfo-pv_ouţ.txt şi oferă informaţii
despre modul în care au fost configurate procesoarele în interiorul sistemului evaluat.
Comanda eeprom al cărui rezultat este salvat în fişierul eeprom.txt oferă informaţii despre
parametrii memoriei nevolatile EEPROM a sistemului.
Se copiază în interiorul directorului temporar fişierul resolv.conf al sistemului ce oferă
informaţii despre modul în care a fost configurat DNS-ul.
Fişierul hosts.txt este copiat din directorul sistemului/etc şi ne oferă numele şi ip-urile
tuturor gazdelor sistemului.
Pentru monitorizarea numărului de servicii online şi offline ale sistemului cât şi detalii
despre acestea este utilizată comanda svcs -av. Pentru a putea număra serviciile online şi
offline se rulează în paralel cu această comandă, comanda wc -l. Paralelismul dintre cele
două comenzi ne oferă numărul de servicii. Pentru delimitarea serviciilor online de către
cele offline este folosită comanda grep.
Pentru salvarea datelor despre memoria swap a sistemului este utilizată comanda swap -l
iar rezultatul este salvat în swap_-l.txt.
Pentru obţinerea mai multor informaţii despre apariţia unor probleme grave la nivelul
sistemului se recomanda configurarea crash dump-ului pe sistem. Datele despre modul în
care acesta este configurat, inclusiv directorul în care se vor salva datele în cazul generării
lor sunt specificate în interiorul fişierului dumpadm.conf din directorul/etc al sistemului.
Fişierul este copiat în directorul temporar al sistemului.
Următoarea categorie de date colectate sunt despre sistemul de fişiere numit ZFS. ZFS
reprezintă un sistem de fişiere combinat cu managerul logic de volum dezvoltat de către
Sun Microsystems. Caracteristicile ZFS-ului includ protecţia împotriva coruperii datelor,
suport pentru capacităţii mari de stocare, o compresie eficientă a datelor, o verificare
continuă a integrităţii datelor, un sistem automat de reparare a datelor, RAID-Z ce este
cunoscut ca cel mai bun tip de oglindire a datelor şi nativul NFSv4.
Comanda zfs list interoghează sistemul în vederea obţinerii informaţiilor despre pool-urile
de stocare de tip ZFS. Datele sunt salvate în fişierul zfs_list_output.txt. Sunt oferite
informaţii despre numele fişierelor, cât sunt utilizate, şi locaţia în care sunt montate.

31
Pentru mentenanţa pool-urilor de stocare ZFS este utilizată comanda zpool history.
Pentru accesare istoricului pool-ului principal denumit rpool s-a utilizat comanda zpool
history rpool, iar rezultatul a fost salvat în fişierul zpool_history_rpool_output.txt.
Comanda zpool list a fost utilizată pentru obţinerea unei liste cu toate pool-urile de tip ZFS
utilizate pentru stocare. Lista rezultată a fost salvată în fişierul zpool_list_output.txt.
Comanda zpool status -x oferă informaţii despre starea pool-urilor create pe sistemul
monitorizat. În urma evaluării acestor comanda returnează un mesaj cu erorile acestora în
cazul apariţiei unor probleme sau mesajul "all pools are healthy" dacă nu este detectată
nicio problemă la nivelul acestora.
În vederea interogării sistemului despre ce versiune este rulata de către pool-urile ZFS este
utilizată comanda zpool upgrade -v. Versiunea este afişată în prima linie a rezultatului
returnat de către comandă. Pentru a izola şi salva doar prima linie, comandă este rulata în
paralel cu comanda head -1. Rezultatul este salvat în fişierul zfs_version.txt.
Datele despre reţeaua sistemului relevante pentru monitorizarea sistemului au fost colectate
cu următoarele comenzi:
Comanda dladm show-phys returnează o listă cu toate interfeţele de reţea configurate pe
sistem. Lista este salvată în fişierul dladm_phys_out.txt.
Comanda dladm show-link returnează linkurile datelor interfeţelor de reţea ale sistemului.
Numărul datalink-uri unui sistem coincide cu numărul de NICs instalate pe acel sistem.
Rezultatul este salvat în fişierul dladm_link_out.txt
Comanda netstat -rn, al cărui rezultat este salvat în fişierul netstat-rn_ouţ, returnează
conexiunile reţelei, tabela de rutare şi statistici despre interfeţele de reţea.
În vederea analizei discurilor sistemului s-a folosit comanda iostat -xtc care a fost rulata pe
durata a 60 de secunde. Comandă este utilizată pentru monitorizarea intrărilor şi ieşirilor
discurilor sistemului şi generează rapoarte ce pot să fie folosite pentru modificarea
ulterioară a configuraţiei sistemului pentru obţinerea unei balanţe de intrări/ieşiri mai bună
între discurile sistemului. Coloanele returnate de către comandă sunt următoarele:

- Disk- reprezintă numele discului analizat

- R/s, w/s - reprezintă numărul mediu de citiri/scrieri pe secundă.
- Kr/s, Kw/s - reprezintă media Kb-lor citiţi/scrişi pe secundă.
- Wait - timpul în care un procesor a fost în aşteptarea unui bloc de date.
- Actv - numărul de cereri active în coada de aşteptare
- %w - procentul de ocupare al cozii de aşteptare
- %b - Procentul de ocupare al cozii active când dispozitivul a fost ocupat
- Svc_t - tipul de lucru în milisecunde. Include timpul de aşteptare, timpul în care a fost
utilizată coada activa şi timpul de transfer.
- Us/sy - Procentul de utilizare al procesorului de care utilizator/sistem.
- Wt - procentul de aşteptare pentru I/O
- Id - procentul de timp în care discurile au fost inactive.
Rezultatul rulării comenzii iostat -xtc este salvat în fişierul iostat_-xtc_out.txt.
Comanda iostat -iE ne oferă informaţii despre numărul de erori detectate pe fiecare
dispozitiv asociat cu sistemul monitorizat. Rezultatul conţine numărul de erori hardware,
numărul de erori de transport şi de erori media, dacă dispozitivul nu este configurat, dacă
sistemul nu vede dispozitivul şi dacă este recuperabil. Fişierul iostat-iE_output.txt conţine
informaţiile generate de execuţia acestei comenzi.
Comanda df -h este utilizată pentru obţinerea informaţiilor despre spaţiului de pe discuri în
Kb. Sunt returnate numele sistemului de fişiere, numărul de Kb utilizaţi şi disponibili,
procentul în care capacitatea acestuia este ocupată şi locaţia în care acesta este montat.
Rezultatul este salvat în fişierul df_-h_output.txt.

32
Urcarea fişierelor în mediul de stocare este realizată cu ajutorul comenzii curl. Comanda
curl este utilizată pentru a trimite şi primi fişiere de la un server utilizând unul dintre
următoarele protocoale: HTTP, HTTPS, FTP, GOPHER, DICT, TELNET, LDAP sau
FILE.
Comandă este rulata cu opţiunile -s, ceea ce face ca aceasta să se execute în modul
silenţios (utilizatorul nu va vedea desfăşurarea datelor de transmitere/primire în terminal)
şi -H ce permite adăugarea unui antet pentru accesarea unei pagini web.
Pentru fiecare fişier din directorul temporar se va iniţializa o variabilă denumită
path_to_file cu calea către fişier. Aceasta variabilă este dată ca parametru comenzii curl. În
interiorul comenzii curl este specificat codul de acces generat de către aplicaţia API creată
în Dropbox, calea către directorul în care urmează să fie salvate datele în mediul de stocare
cloud şi variabilă ce conţine calea fişierului.

Curl -s -H "Authorization: Bearer

vrevPzguZFAAAAAAAAAAFwVkCi4fo_BOjv-MComjJm8QcCy-ZV1k___QPKd33wpZ"
https://api-content.dropbox.com/1/files_put/auto/serverdata/$
(hostname)/-T $path_of_file >/dev/null

În cazul în care comanda nu a returnat erori este incrementata variabilă files_sub. Aceasta
variabilă este utilizată în mesajul returnat la sfârşitul execuţiei comenzii curl şi specifică
câte fişiere au fost trimise cu succes către mediul de stocare.
În cazul în care comanda curl întâmpina erori la transmiterea unuia dintre fişiere este
returnat mesajul "$file " file failed to be sent!"", unde $file reprezintă fişierul ce nu a putut
să fie trimis către mediul de stocare cloud.
Directorul temporar este şters şi scriptul îşi termina execuţia.

Pentru a putea colecta datele în mod constant la un interval de timp de 10 minute a fost
realizat scriptul cu numele SM_cron.sh.
Execuţia acestui script va adăugă în crontab-ul sistemului de operare Soalris o intrare ce va
specifică execuţia scriptului SM_collect.sh la un interval de timp de 10 minute. În cazul în
care intrarea nu a putut să fie adăugată se va genera un mesaj de eroare. Dacă configurarea
crontab-ului a fost efectuată cu succes se afişează mesajul " Cron Job has been successfully
configured!", iar scriptul îşi termina execuţia.

4.3 Analiza datelor

Datorită cantităţii mari de informaţii ce trebuie parsata şi a timpului mare de accesare a
unui fişier din cadrul dropbox-ului, scriptul pentru analiza datelor este nevoit să modifice
timpul maxim de execuţie al configuraţiei php-ului.
Acest lucru este realizat prin intermediul funcţiei php max_execution_time, ce primeşte ca
parametru durata maximă de execuţie, în secunde:
Set_time_limit (600 * count ($servers));
Scriptul cere o conexiune la dropbox, deschide fişierul de log pentru erori şi pe cel pentru
activitatea sa.
După aceasta se preiau toate serverele ce sunt monitorizate din baza de date, şi pentru
fiecare dintre acestea se începe analiza datelor.
Se actualizează dată la care s-au analizat ultima oară datele serverului, şi se preiau fişierele
ce urmează a fi analizate din dropbox.

33
Pentru pagina 'Dashboard' a serverului se preiau fişierele ce conţin dată la care s-a făcut
achiziţia de date pe server, id-ul serverului, versiunea sistemului de operare de pe server,
versiunea SRU-ului, numărul de unităţi centrale de programare, arhitectura sistemului de
operare (32/64 de biţi), volumul de memorie RAM, durata de timp de când serverul este
pornit.
Pentru pagina 'Performance' se preiau:
Fişierul ce conţine procentajele de utilizare ale unităţilor centrale de programare de către
sistem şi de către utilizator, pe baza cărora se crează setul de date pentru graficul de
utilizare a unităţilor centrale de programare.
Fişierul ce conţine informaţii legate de cantitatea de memorie folosită de fiecare sistem de
fişiere în parte, pe baza cărora se creează graficul de utilizare a memoriei de stocare şi setul
de date pentru afişarea detaliilor cu privire la acesta. Se preiau numele sistemului de
fişiere, dimensiunea acestora, cantitatea de memorie folosită, cantitatea de memorie
disponibilă, capacitatea sistemului de fişiere (% liber), şi locaţia în care a fost montat. Pe
baza acestor informaţii se crează alerte în legătură cu sistemele de fişiere. Dacă un sistem
de fişiere este ocupat mai mult de 80% se salvează o notificare şi dacă este ocupat mai
mult de 90% se salvează un avertisment. Se actualizează numărul de avertismente şi
notificări ale serverului în baza de date.
Fişierul (iostat) ce conţine date cu privire la numărul de pachete scrise şi citite pe secundă,
cantitatea de informaţii (kb) scrisă şi citită de server, activitatea pe disk şi timpul de
utilizare. Pe baza acestora se crează seturile de date necesare creării graficelor aferente. Se
crează notificări şi avertismente în cazul în care timpul de utilizare depăşeşte 30ms în timp
ce serverul este ocupat mai mult de 5% şi se actualizează numărul de notificări şi
avertismente în baza de date. Graficele conţin informaţii pentru fiecare dispozitiv al
serverului. Notificările sunt pentru fiecare dispozitiv.
Fişierul ce conţine informaţii legate de coada de aşteptare a discului (vmstat) şi procentul
de utilizare al memoriei RAM, pe baza căruia se crează setul de date pentru graficul de
utilizare a memoriei RAM şi notificări şi avertismente în cazul în care coada de aşteptare a
discului are o medie mai mare de 0.1. Numărul de notificări şi avertismente este actualizat
în baza de date.
Fişierul mpstat, pe baza căruia se crează setul de date necesar graficelor ce prezintă:
CPU fails to gain mutex (smtx), CPU interrupts (într), CPU interrupts aş threads (ithr),
Processor cross-calls (xcal), Thread migrations (migr). Conţin date pentru fiecare CPU al
serverului
Notificări dacă:
Smtx>500 când sys>usr şi sys+usr>20 (sys, usr -> cpu utilizat de sistem şi user)
Media srw > 0.1
Xcal>200
Migr>200
Notificările se fac pentru fiecare CPU în parte.

Informaţiile preluate din fişiere în vederea parsarii ce urmează să fie afişate în pagina
"Configuration" sunt date despre CPU, Parametrul OBP, atributele fizice ale serverului,
configuraţia rutării, DNS, numărul de servicii online şi numărul de servicii offline, cât şi
detaliile acestora (se crează liste ce conţin toate serviciile online şi toate serviciile offline),
configurarea memoriei swap, configurarea crash dumpului, lista sistemului de fişiere ZFS,
informaţii despre starea şi modul de configurare al pool-urilor ZFS.
Pe baza acestor informaţii se crează tabele, pentru fiecare. Tabelele se salvează într-un
fişier, într-o structură uşor de analizat şi afişat.

34
În vederea formatării datelor ce urmează a fi afişate în pagina 'Maintenance' se preiau din
fişiere mesajele de eroare ale serverului, eşecurile serverului, avertismentele serverului şi
notificările serverului. Pentru acestea se crează tabele ce sunt legate de către un table ce
conţine toate mesajele serverului, pentru a vedea contextul în care au apărut mesajele.
Se preiau toate mesajele serverului şi se crează un tabel cu acestea.
Se preiau erorile dispozitivelor serverului şi se crează un tabel cu acestea.

Pentru fiecare dintre cele patru pagini se crează câte un fişier local, în care sunt salvate
informaţiile analizate. După terminarea analizei, aceste fişiere sunt urcate în mediul de
stocare cloud şi sunt şterse de pe serverul de aplicaţii.

În cazul în care nu se poate accesa un fişier de pe Dropbox sau nu se poate scrie rezultatul
analizei acelui fişier, va fi scrisă o linie în log-ul de erori ce conţine data şi ora apariţiei
erorii, serverul pentru care a apărut şi un mesaj ce explica eroarea apărută.
În log-ul de activitate se scriu paşii prin care trece scriptul de analiza, cu dată, oră şi
serverul pentru care se face analiza datelor.

Pentru generarea datelor s-a folosit un sistem de generare automată de culori, întrucât
numărul de elemente ce apar într-un grafic poate varia:

Function random_color_part () {
Return str_pad (dechex (mt_rând (0, 255)), 2, '0',
STR_PAD_LEFT);
}
Function random_color () {
Return random_color_part (). Random_color_part ().
Random_color_part ();
}

Apelând funcţia random_color (), se obţine o culoare în format hash (ex: #392a5).
La finalul execuţiei scriptului de analiza, timpul maxim de execuţie este întors la valoarea
iniţială.

5 Instalare şi utilizare
5.1 Instalarea sistemului de monitorizare
Instalarea sistemului de monitorizare se face în trei paşi.
Primul pas este copierea scripturilor SM_collect.sh, SM_cron.sh şi timestamp.pl în
directorul/usr/sbin al sistemului ce se doreşte a fi monitorizat.
Se rulează logat cu utilizatorul root scriptul SM_cron.sh utilizând comanda sh SM_cron.sh.
Pentru a putea primi datele utilizatorul trebuie să adauge în aplicaţie datele despre serverul
pe care au fost adăugate cele trei scripturi.
Al doilea pas consta în instalarea aplicaţiei. Fişierele ce conţin codul sursă al aplicaţiei web
sunt copiate pe serverul de aplicaţii împreună cu scriptul PHP dezvoltat în vederea
analizării datelor.
Ultimul pas consta în configurarea manuală a unei întări în crontab în cazul în care serverul
de aplicaţii rulează un sistem de operare bazat pe Unix sau în Windows scheduler în cazul

35
în care sistemul de operare este Windows. Intrarea trebuie să indice rularea scriptului PHP
la intervalul de 10 minute.

5.2 Utilizarea aplicaţiei

În momentul accesări linkului cu care este configurata aplicaţia, este deschisă pagina de
autentificare. Dacă utilizatorul nu este autentificat, acesta va fi redirecţionat către
formularul de logare indiferent de pagina pe care încearcă să o acceseze.
Logarea este necesară la fiecare accesare a aplicaţiei, întrucât sesiunea se crează după
finalizarea autentificării şi este încheiată când aplicaţia este închisă sau utilizatorul
deloghează.
Există două tipuri de utilizatori: clienţi şi admin, fiecare dintre aceştia având alte
permisiuni şi alte posibilităţi de accesare în cadrul interfeţei.
În figură 5.1 este reprezentată pagina cu formularul de autentificare.

Fig. 5.1. Formularul de autentificare

Pagina Login permite autentificarea utilizatorilor.

Evenimentul apăsării butonului Login din pagina de autentificare verifica dacă numele de
utilizator şi parola sunt valide. În cazul în care informaţiile introduse sunt corecte se crează
o nouă sesiune, se salvează utilizatorul în sesiune şi se face redirecţionare către pagina
principală. În caz contrar, pagina de autentificare este reîncărcată şi se afişează mesaje de
eroare.

În funcţie de tipul utilizatorului (admin sau client), sunt disponibile alte informaţii şi
pagina pe care se direcţionează utilizatorul diferă.
În cazul utilizatorilor clienţi, pagina ce se încarcă în urma autentificării este cea a
serverelor clientului logat, ce prezintă o reţea a serverelor monitorizate ce aparţin acestuia,
cu informaţii generale legate de ele (numărul de erori, avertizări, notificări şi statusul
serverului). Figura 5.2 reprezintă pagina Servers în care utilizatorul client este
redirecţionat.
În cazul utilizatorului admin, acesta este redirecţionat în urma autentificării către pagina
Home.

36
 Fig. 5.2. Pagina Servers a utilizatorului client

Pentru fiecare server sunt afişate logo-ul clientului, dacă acesta exista, sau logo-ul
aplicaţiei de monitorizare, urmat de către numele clientului şi denumirea serverului
(hostname).
După acestea sunt afişate numărul de erori, eşecuri, avertizări şi notificări ale serverului şi
starea generală a acestuia.
Prin apăsare butonului 'Details' se deschide un pop-up ce prezintă mai multe detalii despre
starea serverului.
Selectând numele serverului se accesează pagina generală a detaliilor serverului numită
"Dashboard" (Fig.5.3).

Fig 5.3. Pagina Dashboard a serverului Test0

37
În prima parte a acestei pagini sunt afişate datele generale cu privire la server, şi anume:
- Dată la care acesta a fost ultima oară analizat ('Analysis Date');
- Denumirea serverului ('Hostname');
- Id-ul serverului ('Host ID');
- Numele clientului ('Customer Name');
- Adresa de email a clientului ('Customer Email');
- Locaţia în care se afla serverul, aşa cum a fost introdusă la momentul adăugării acestuia
în vederea monitorizării ('Location');
- Versiunile sistemului de operare şi ale pachetelor monitorizate ('Version');
- Numărul de unităţi centrale de procesare ('Number of CPU's');
- Numărul de biţi pe care este arhitectura sistemului ('System Info');
- Memoria RAM disponibilă pe server ('Total Memory');
- Timpul care a trecut de la ultima pornire a serverului, şi dată la care acesta a fost pornit
('Uptime').

Fig 5.4 Notificări generale detectate

După informaţiile generale urmează o listă de notificări cu privire la server. Acestea sunt
detalii cu privire la monitorizarea sistemului, la starea versiunilor acestuia (Dacă pe sistem
se afla versiunile cele mai noi ale sistemului de operare şi ale pachetelor monitorizate), şi
detalii ce specifică dacă analiza a putut fi realizată sau nu.
În funcţie de severitate, alertele se împart în următoarele categorii:
- Notices - această categorie cuprinde uşoarele schimbări ce deviază de la comportamentul
normal al sistemului de operare, însă care nu crează probleme.
Warnings - Sunt avertizări ce identifică schimbările ce au un caracter periculos.
Fails - Specifică numărul de acţiuni/procese ce nu au putut fi îndeplinite cu succes.
Errors - Erori sau probleme ce necesită implicarea cât mai rapidă.

Fig.5.5 Tabela de alerte

Ultima parte a paginii este reprezentată de un tabel ce conţine toate alertele serverului
împărţite pe categoria din care fac parte. Apăsând pe alertele respective, utilizatorul este
redirecţionat către pagina corespunzătoare sau către mesajul corespunzător erorii
respective.

38
Odată accesata pagina ce prezintă detalii cu privire la server, se deschid mai multe opţiuni
în bară de navigare din lateralul paginii, ce permit utilizatorului să navigheze prin mai
multe pagini ce conţin informaţii detaliate cu privire la server.
Pagina de performanţă asociată serverului selectat prezintă grafice despre modul în care
sunt utilizate resursele disponibile.
În primul grafic (Fig. 5.6) este prezentat procentul în care procesorul sau procesoarele sunt
utilizate de către utilizator, de către sistem şi timpul total de utilizare.
În cazul în care sistemul detectează o utilizare e totală a sistemului de peste 80% este
generat un avertisment.

Fig.5.6 Graficul de utilizare al procesorului

Al doilea grafic (Fig. 5.7) reprezintă utilizarea sistemului de fişiere. Deoarece în cazul
utilizării rpool-ului peste 80% pot apărea grave de performanţă, sistemul generează alerte
dacă acest prag este depăşit. Prin apăsarea butonului "View Detailes" se afişează un pop-up
ce oferă informaţii suplimentare despre capacitatea sistemelor de fişiere, locul în care
acesta a fost montat şi cât spaţiu liber mai este disponibil.
Figura 5.8 reprezintă utilizarea memoriei RAM, eşantionata pe unitatea de timp. Dacă
memoria RAM este utilizată la capacitate maximă mai mult de 10% din timp este generat
un mesaj de avertizare. Datele pentru generarea graficului sunt preluate din execuţia
dinamică a comenzii vmstat.

Fig 5.7 Graficul utilizării sistemului de fişiere

39
 Fig.5.8. Utilizarea memoriei RAM

Utilizând comanda iostat serverul este interogat pentru numărul de blocuri şi Kb citiţi şi
scrişi pe secundă. Analizând aceste date se pot identifica factorii ce au generat problemele
de performanţă. În cazul unui număr de scriere şi citire mare se pot lua decizii cu privire la
îmbunătăţirea echipamentului fizic pentru a avea o activitate mai rapidă. În figurile 5.9,
5.10. 5.11, 5.12 sunt exemple de reprezentări grafice generate de aplicaţia dezvoltată ce
oferă informaţii despre acest aspect.

Fig.5.9 Reprezentarea grafică a numărului de blocuri de date citite pe secundă

40
Fig.5.10 Reprezentarea grafică a numărului de blocuri de date scrise pe secundă

Fig.5.11 Reprezentarea grafică a numărului de kb de date citite pe secundă

Fig.5.12 Reprezentarea grafică a numărului de kb de date scrise pe secundă

41
 Fig.5.13 Activitatea dispozitivului

În rezultatul returnat de execuţia comenzii iostat, coloana "actv" reprezintă numărul mediu
de tranzacţii ce sunt servite în mod activ (eliminate din coadă de aşteptare, dar nu sunt încă
complete). Acesta este numărul de operaţii I/O acceptate, dar nefinalizate de către
dispozitiv. în figură 5.13 este prezentat un exemplu al reprezentării grafice al activităţii
discurilor din sistemul analizat.

Fig.5.14 Exemplu de grafic pentru timpul de serviciu al discului

În rezultatul returnat de execuţia comenzii iostat, coloana "wsvc_t" reprezintă numărul

mediu în milisecunde petrecut de operaţiile de I/O în coada de aşteptare. Figura 5.14
reprezintă un exemplu de grafic al acestui parametru în funcţie de timp.

42
 Fig.5.15 Blocajele de la nivelul kernelului

În figură 5.15 este reprezentarea grafică a blocărilor de la nivelul kernelului.

Blocările sunt utilizate pentru a proteja structura de date a kernelului când este accesata
simultan. Întotdeauna este nevoie de o astfel de blocare pentru a împărţirea zonei de
scriere. Comanda mpstat raportează statusul curent prin datele coloanei smtx. Blocările de
tip mutex sunt utilizate în kernelul sistemului de operare Solaris pentru a proteja structurile
critice de date. Parametrul smtx indica dacă un fir de execuţie este în aşteptarea unui
mutex.
În figurile 5.16 şi 5.17 sunt afişate întreruperile procesorului.
Întreruperile sunt o parte a mecanismului utilizat de dispozitiv pentru a semnaliza o
activitate de I/O finalizată/Întreruperile determină procesorul să întrerupă execuţia unui fir
de execuţie ce rulează, deoarece este necesară alocarea de resurse imediată.
Un număr mare de întreruperi pe un anumit procesor poate să fie datorat unui
comportament defectuos al echipamentului fizic ce nu gestionează corect alocarea
resurselor procesoarelor. Comanda mpstat achiziţionează doi parametri pentru întreruperi
într şi ithr.

Fig.5.16 Întreruperile la nivelul procesorului

43
 Fig.5.17 Întreruperile la nivelul procesorului ca fir de execuţie

În figură 5.18 sunt reprezentate apelurile încrucişate. Parametrul xcal indica numărul de
apeluri încrucişate ale procesorului ce au fost detectate pe sistem. Aceste apeluri
încrucişate semnifica apelare resurselor unui procesor de către un altul prin întreruperea
acestuia. Dacă parametrul xcal depăşeşte limita de 200/secundă aplicaţia trebuie
examinată, deoarece acesta este un comportament defectuos al sistemului şi poate genera
importante probleme de performanţă.

Fig.5.18 Exemplu reprezentare grafică a apelurilor încrucişate

44
 Fig.5.19 Numărul de migrări al firelor de execuţie reprezentat grafic

Parametrul migr indica de câte ori un fir de execuţie a fost migrat către un alt procesor
decât cel apelat iniţial. Dacă parametrul migr înregistrat de execuţia comenzii mpstat
atinge valori mai mari de 500, se recomanda creşterea parametrului de sistem
rechoose_interval. Această operaţie de migrare este costisitoare pentru sistem şi poate
afecta întreaga fermă de servere. În figură 5.19 este evidenţiat un exemplu de grafic unde
este reprezentat numărul de migrări pe secundă.

Utilizatorul poate vizualiza configuraţia sistemului accesând pagina "Configuration".

Parametrii sunt evaluaţi de aplicaţie, iar în cazul detecţiei unor neconcordante sunt afişate
mesaje de notificare în interfaţa.
În prima parte a paginii utilizatorul poate vedea informaţii despre modul în care sunt
configurate procesoarele şi parametrii configuraţi la iniţializarea sistemului.
Sunt colectate datele de configurare de la interfeţele de reţea, domeniul, gatewayul şi ip-ul
configurate sistemului, informaţii despre numărul de servicii active şi inactive şi care sunt
acestea, modul de configurare al sistemelor de fişiere şi starea acestora, parametrii ce
intervin în crearea unui dump la nivelul sistemului şi modul în care este configurata
memoria.
Datele sunt dispuse tabelar în pagina "Configuration" şi sub fiecare tabelă sunt afişate
mesaje în cazul detecţiei unor probleme.

45
 Fig.5.20 Configuraţia procesoarelor şi a parametrilor de iniţializare

În pagina de mentenanţa utilizatorul poate vedea mesajele generate de sistem. Aceste

mesaje sunt sortate în funcţie de gravitatea lor. Tot în cadrul acestei pagini este
reprezentată o tabelă cu toate erorile dispozitivelor ce fac parte din serverul accesat.

Fig.5.21 Exemplu de tabele din pagina de mentenanţa

După acest tabel urmează liste cu toate erorile, eşecurile, avertismentele şi notificările pe
care le-a primit serverul din momentul pornirii acestuia.
Fiecare linie din aceste tabele poate fi selectată, utilizatorul fiind astfel redirecţionat către o
listă completă a mesajelor pe care serverul le-a trimis, pentru a putea analiza în ce
circumstanţe acea problemă a fost detectată.

46
 Fig.5.22 Listele de notificări şi mesaje generate de aplicaţie

Aceste liste pot fi ascunse prin apăsarea butonului "Show Notices/Warnings/Fails/Errors")

pentru a uşura navigarea în pagina, întrucât poate exista un număr foarte mare al mesajelor
generate de sistem.

Un utilizator îşi poate adăuga noi servere în vederea monitorizării de pe pagina 'Server
Management'.
În această pagină pot fi de asemenea actualizate informaţiile serverelor existente şi
Eliminarea de servere din aplicaţie. Eliminarea unui server din aplicaţie va duce la oprirea
monitorizării acestuia.
Dacă utilizatorul este admin, acesta va putea adăuga servere pentru orice utilizator.

Fig.5.23 Gestionarea serverelor

Monitorizarea pentru aceste servere nu va începe atâta timp cât un administrator nu va lua
la cunoştinţa faptul că au fost adăugate şi le va accepta în sistem.

Dacă utilizatorul logat este admin, pagina încărcată nu este cea ce prezintă serverele, ci o
pagină ce prezintă un rezumat al activităţii serverelor şi aplicaţiei.

47
 Fig.5.24 Starea sistemelor văzută de către utilizatorul administrator

În această pagină administratorul poate vedea starea achiziţiei de date de la serverele

monitorizate, cât şi o evidenţă a activităţii acestei achiziţii şi a erorilor apărute.

Fig.5.25 Evidenta erorilor în colectarea şi utilizarea datelor de către aplicaţie

Se afişează deasemenea o listă a tuturor serverelor ce au fost adăugate de către clienţi.

Fig.5.26 Adăugarea serverelor în sistemul de monitorizare de către administrator

48
Pentru a determina ca administratorul a luat la cunoştinţa faptul că aceste servere au fost
adăugate, şi pentru a permite începerea monitorizării acestora, administratorul va trebui să
închidă notificările apăsând butonul 'Accept' aflat la dreapta fiecărui server nou adăugat.

Fig.5.28 Evidenta alertelor fermei de servere

Ultima parte a paginii prezintă numărul total de erori, eşecuri, avertismente şi notificări
apărute pe servere.
Administratorul poate accesa informaţiile tuturor serverelor. Are deasemenea acces la
următoarele pagini pe care un utilizator de tip client nu le poate accesa:

Fig.5.29 Pagina de administrare a versiunilor

În pagina de gestionare a versiunilor un administrator poate actualiza versiunile sistemului

de operare solaris şi a altor pachete monitorizate. Pe baza acestor versiuni vor fi create
notificări cu privire la necesitatea actualizării lor pe server.

Fig.5.30 Pagina de administrare a utilizatorilor

Permite administratorului adăugarea de noi utilizatori şi actualizarea informaţiilor celor

existenţi, cât şi eliminarea acestora.
În momentul în care un utilizator este eliminat din aplicaţie, toate serverele ce aparţin
acestuia sunt eliminate deasemenea.

49
 Fig.5.31 Pagina de administrare a conexiunii cu dropbox-ul

În această pagină un administrator are posibilitatea de a modifica cheile de acces pentru

dropbox-ul folosit. Aceste chei sunt necesare pentru crearea unei conexiuni cu mediul de
stocare cloud şi accesarea informaţiilor de pe acesta.

6 Testare
Pentru a valida şi verifica buna funcţionare a sistemului de monitorizare dezvoltat au fost
iniţiate trei teste. Testele au fost de tipul black box şi au urmărit evaluarea gradului de
îndeplinire al cerinţelor nefuncţionale definite. În urma rezultatului obţinut s-a propus şi
implementat o metodă de corectare a erorilor detectate în cazul observării acestora.

I. În vederea testării cerinţei nefuncţionale de performanţă "Colectarea datelor nu trebuie să

dureze mai mult de 4 minute." s-a efectuat o testare de tip black-box asupra scriptului de
colectare a datelor.
În mediul de test se rulează manual scriptul de colectare. Se utilizează comanda Unix time
asupra comenzi sh de rulare a scriptului. Comanda time returnează la sfârşitul rulării
scriptului statistici legate de rularea programului. Aceste statistici constau în timpul real de
la invocarea până la terminarea rulării scriptului şi timpul în care utilizatorul şi sistemul au
utilizat procesorul în vederea realizării acestei sarcini.
Rezultatul aşteptat ce ar îndeplinii criteriul de performanţă propus presupune obţinerea în
urma execuţiei testelor un timp real mai mic de 4 minute.

Paşii în vederea realizării testului:

1. Se introduce comanda de execuţie a scriptului utilizându-se comanda time.

root@test0: ~# time sh test1.sh

2.Se aşteaptă finalizarea execuţiei scriptului.

Checking space..
Start collecting..
Creating temporary directory
Get system information..
Collecting logs..
## (10%)
Collect Performance dată
######## (40%)
Collecting configuration dată
Getting services information
Get swap information

50
Get dump information
Get ZFS INFO
Collecting network dată
Get disk dată
40 files ouţ of 40 has been successfully submitted!
####################### (100%)
Done

Real 5m28.464s
Uşer 0m6.033s
Sys 0m10.275s

3. Se analizează datele de ieşire şi se compară cu datele propuse.

Timpul real de execuţie a scriptului de colectare în mediul de test este de 5m28.464s.
Deoarece timpul maxim de execuţie propus este de 4 minute, cu 1m28.464s mai mic decât
rezultatul real se poate observa un eşec în vederea îndeplinirii cu succes a cerinţei.
Comenzile de colectare ale scriptului sunt verificate în ceea ce priveşte timpul de execuţie
pe rând şi se verifică unde sunt cele mai mari intervale de timp.

Soluţia propusă este utilizarea comenzilor de colectare a datelor de performanţă ce

trebuiesc rulate în paralel.

vmstat 1 60 | perl timestamp.pl> $directory/vmstat_out.txt |

mpstat 1 60 | perl timestamp.pl> $directory/mpstat_out.txt |
prstat -mL 1 60 > $directory/prstat_-mL_out.txt |sar -u 1 60 >
$directory/sar_-u_out.txt

Durata de timp necesară rulării acestor secvenţial este de 60x4=240 de secunde. Rulate în
paralel timpul se reduce la 60 de secunde ceea ce va reduce şi timpul real de execuţie al
scriptului.

Rezultatul obţinut în urma realizării paralelismului dintre comenzile de colectare a datelor

de performanţă:

Real 3m5.650s
Uşer 0m6.912s
Sys 0m11.317s

Timpul real este redus la 3m5.6.50s, acesta îndeplinind cerinţa nefuncţională propusă.

II. În vederea testării îndeplinirii condiţiei nefuncţionale " Timpul de analiza al datelor
pentru un server nu trebuie să depăşească 3 minute" a fost propusă rularea scriptului PHP
de analiză a datelor şi a fost contorizat timpul de execuţie. Rezultatul aşteptat este că
timpul de execuţie să nu depăşească 3 minute.
În sistemele unix şi Windows se poate utiliza funcţia getrusage () ce returnează un vector
ce conţine timpul de utilizare în secunde şi respectiv în milisecunde.
Funcţia se apelează de două ori în cadrul scriptului PHP, o dată la început şi o dată la
finalul acestuia.
Primul pas a fost introducerea funcţiei getrusage () în scriptul de analiza al datelor creat.
Al doilea pas a constat în execuţia scriptului şi aşteptarea finalizării acestuia.
Rezultatul testului a fost următorul:
This process used 151 s for its computations

51
În urma testării s-a determinat un timp de execuţie pentru analiza datelor unui server a fost
151 de secunde.
Timpul rezultat se încadrează şi respecta cerinţa nefuncţională propusă. Nicio acţiune nu a
fost luată.

III. Testul cu numărul trei presupune analiza timpului maxim de încărcare a paginilor ce
prezinta datele analizate ale serverelor în interiorul aplicaţiei. În cadrul cerinţelor
nefuncţionale s-a propus ca acesta să nu depăşească 7 secunde.
A fost utilizată funcţia PHP microtime () care returnează timpul curent.
Paşii utilizaţi în vederea implementării testului sunt următorii:

Amplasarea următoarei secvenţe de cod la începutul paginii PHP ce urmează a fi afişată de

către browser.

<? Php
$time = microtime ();
$time = explode (' ', $time);
$time = $time [1] + $time [0];
$start = $time;?
>

Următoarea secvenţă de cod urmează să fie pusă la finalul paginii web.

<? Php
$time = microtime ();
$time = explode (' ', $time);
$time = $time [1] + $time [0];
$finish = $time;
$total_time = round (($finish - $start), 4);
Echo 'Page generated în '. $total_time.' seconds.';?
>

În urma accesări paginii web în care au fost introduse cele două secvenţe de cod se va afişa
timpul în care aceasta a fost afişată.
Rezultatul acestui test a returnat următorul mesaj: "Page generated în 32.0031 seconds."

În urma analizei motivelor pentru care timpul de încărcare a fost atât de mare, s-a observat
că accesarea fişierelor din mediul de stocare cloud necesita un cost din punct de vedere al
timpului mare. Dropbox are restricţionat accesul la un fişier la un interval de 5 secunde.
A fost propusă şi implementata o rezolvare prin intermediul unui script PHP auxiliar de
analiză a datelor ce va rula independent de aplicaţie. Scriptul va prelua informaţiile din
toate fişierele urcate în mediul de stocare şi le va concatena într-un fişier pentru fiecare
pagină ce urmează a fi afişată. Astfel timpul de accesare al unei pagini web din cadrul
aplicaţiei se reduce considerabil.
După implementarea soluţiei propuse, testul a fost reluat, iar rezultatul a fost "Page
generated în 5.7231 seconds."
Timpul returnat este în limita timpului propus iniţial.

52
7 Concluzii şi contribuţii personale
7.1 Contribuţii
În lucrarea de fața s-a propus conceperea unei soluţii noi de monitorizare a unei ferme de
servere într-un mod automat faţă de modul tradiţional, ce presupune interogarea resurselor
sistemului de operare manual.
Datorită numărului mare de incidente ce pot surveni la nivelul unei ferme de servere s-a
urmărit un mod dinamic de prevenire a sistemelor prin evaluarea parametrilor ce decid
starea acestora.
Cerinţele propuse şi implementate în sistemul de monitorizare dezvoltat au fost concepute
pentru a oferi performanţă, siguranţă şi scalabilitate. Acestea fiind trei concepte importante
în domeniul utilizării şi analizei de servere.
S-a realizat o sinteză a informaţiilor cu privire la comenzile disponibile ale sistemului de
operare Solaris şi a modului de funcţionare al acestuia. În urma acestui proces au fost
extrase cele mai relevante componente interne ce influenţează starea sistemului.
S-a urmărit implementarea unui mod de colectare a datelor care să nu interfereze cu
activitatea uzuală a sistemului monitorizat şi care să poată redirecţiona datele sale într-un
mod dinamic şi constant către mediul de stocare.
Luând în considerare structura unei ferme de servere şi modul de interconectare al acestora
a fost concepută o interfaţă ce să poată să reunească în timp real datele de la acestea.
Utilizatorul administrator are accesul la toate modificările şi alertele ce au loc la nivelul
întregului grup de servere.
A fost creată o interfaţă ce să reunească toate aspectele relevante ale stării sistemelor în
vederea reducerii numărului actual de defecte, erori şi costurile acestora întâmpinate în
cadrul unei ferme de servere.

7.2 Considerente legate de dezvoltarea ulterioară a aplicaţiei.

În dezvoltarea ulterioară a aplicaţiei se propune extinderea numărului de servere suportate
prin îmbunătăţirea performanţelor. Datorită arhitecturii de tip N-Tire Client-Server utilizată
este permisă modificarea nivelului logic şi a celui de date fără afectarea întregului sistem.
Totodată se poate creşte numărul de parametrii monitorizaţi pentru a îmbunătăţii
rezultatele oferite.
O altă opţiune ce va fi luată în calcul este conectarea cu depozitul de pachete oficial al
distribuţiilor Solaris în vederea păstrării unei evidente despre necesitatea actualizării
pachetelor. În prezent utilizatorului administrator îi revine sarcina de a fi la curent cu noile
actualizări şi gestionarea versiunilor în aplicaţie. Creând o cale de acces directă către
depozitul de pachete oficial actualizarea versiunilor curente se vor face automat şi în timp
real. Datorită identificării şi corectării bug-urilor din versiunile mai noi, acest lucru poate
ajuta utilizatorul să ia o decizie în vederea rezolvării anumitor defecte.
Există cazuri când în interiorul unor ferme de servere exista mai mult de un tip de sistem
de operare. Întrucât sistemul de monitorizare urmăreşte doar serverele ce rulează Solaris, în
cazul utilizării sistemului în cadrul unei ferme de servere cu mai multe sisteme de operare
nu se vor putea monitoriza toate serverele. Adăugarea unor module pentru diferite versiuni
de Linux şi Windows poate rezolva această problemă, neafectând funcţionalitatea curentă a
sistemului dezvoltat.

53
7.3 Concluzii
În această lucrare, am propus o abordare interactivă şi dinamică a monitorizării unei ferme
de servere ce rulează sistemul de operare Solaris care evita rigiditatea specifică domeniului
aplicaţiei. Datorită evoluţiei din ultimii ani a tehnologiei cloud, aceasta era o alegere
naturală în vederea stocării datelor ce urmează a fi analizate. În plus, am încercat să
identific ingredientele primare ale sistemului de operare ce ne oferă informaţii despre
starea sistemului monitorizat. S-a dorit trecerea de la reparare la prevenire prin
automatizarea modului de interogare a sistemelor de operare din cadrul fermei de servere.
Deşi tehnicile de implementare nu au fost noi, când au fost aplicate sistemului de
monitorizare dezvoltat s-a urmărit o îmbinare a acestora în scopul construirii unei noi
tehnologii ce să aducă îmbunătăţiri noi în domeniul fermelor de servere. Obiectivele
propuse au fost atinse, aplicaţia dezvoltată este funcţională şi reuneşte toate cazurile de
utilizare propuse cu caracteristicile aferente. Scenariul ulterior a fost atins, utilizatorul
având la dispoziţie un sistem de monitorizare automat ce îi va oferi informaţii în timp real
în vederea identificării defectelor ce pot surveni în cadrul unei ferme de servere.

54
8 Bibliografie
[1] Anca Daniela Ioniţă, Alexandra Cernian, Noţiuni aplicate de inginerie a sistemelor de
programe, Bucureşti, România, MatrixRom, 2009
[2] B. Bruegge and A.H. Dutoit: Object-Oriented Software Engineering using UML,
Patterns, and Java Third Edition, Prentice Hall, 2010
[3] Charles R. Portwood ÎI: Mastering Yii, Packt Publishing (January 2016)
[4] GNOME System Administration Guide, https://help.gnome.org/users/gnome-system-
monitor, accesat la data 22.02.2016
[5] http://www.php.net/, accesat în Aprilie 2016
[6] Ian Gorton: Essential Software Architecture. Editura Springer. 2006.
[7] Jason Lengstorf: PHP for Absolute Beginners, Apress, New York, 2009.
[8] Price, Daniel, Andrew Tucker. "Solaris zones: Operating system support for
consolidating commercial workloads." Proceedings of the 18th USENIX conference on
System administration. USENIX Association, 2004.
[9] Scott Cromar: The Solaris Troubleshooting Handbook, Cromar & Cromar, 2008
[10] Silberschatz, Abraham, et al. Operating system concepts. Vol. 4. Addison-Wesley,
1998.
[11] Steven Holzner: Php - The Complete Reference, Mcgraw-Hill Education - Europe,
2008
[12] Steve Suehring: MySQL Bible, Wiley Publishing Inc, New York, 2002
[13] The Definitive Guide to Yii 2.0, http://www.yiiframework.com/, accesat în Aprilie
2016
[14] Toby Velte, Anthony Velte, Robert Elsenpeter, “Cloud Computing, A Practical
Approach”, The McGraw-Hill Companies, 2010
[15] Yue, Kelvin K., and David J. Lilja. "Dynamic processor

55