FACULTATEA DE AUTOMATIC I CALCULATOARE

CATEDRA DE CALCULATOARE

APLICAIE PENTRU MANAGEMENTUL I

MONITORIZAREA UNUI CENTRU DE DATE
PROIECT DE DIPLOM

Autor: Daniel GROZA

Coordonator : ef lucrri ing. Cosmina Ivan

2010
FACULTATEA DE AUTOMATIC I CALCULATOARE
CATEDRA DE CALCULATORE
1

FACULTATEA DE AUTOMATIC I CALCULATOARE

CATEDRA DE CALCULATOARE

SINTEZA
proiectului de diplom cu titlul:
APLICAIE PENTRU MANAGEMENTUL I MONITORIZAREA
UNUI CENTRU DE DATE
Autor: Daniel GROZA
Coordonator: ef lucrri Ing. Cosmina Ivan
1. Cerinele temei:
Proiectarea si implementarea unei aplicaii de management si monitorizare a unui centru
de date
2. Soluii alese:
Pentru implementarea aplicaiei s-a ales platforma Java i framework-ul JSF datele fiind
stocate intr-o baz de date MySQL. Comunicarea cu echipamentele de reea se face
folosind protocolul SNMP i Toolkit-ul oferit de proiectul open-source OpenDMK. Datele
primite de la echipamente sunt stocate n arhive de tip Round Robin iar pe baza acestora
se ntocmesc grafice folosind unealta RRDTool. Aplicaia trimite alerte pe email n cazul
apariiei anumitor evenimente n cadrul reelei.
3. Rezultate obinute:
Aplicaia a fost implementat si instalat, ruleaz pe un server din centrul de date i
monitorizeaz o parte din echipamente. Administratorul poate aduga echipamente noi,
terge sau modifica echipamente existente n baza de date n scopul monitorizrii acestora.
Utilizatorii pot vizualiza graficele cu traficul realizat de echipamentele proprii.
4. Testri i verificri:
Aplicaia a fost testat, verificat i mbuntit pe parcursul testarii. Testele realizate i
modificrile aduse n urma testrii sunt prezentate n capitolul 7 Testare i rezultate
experimentale
5. Contribuii personale:
Autorul a proiectat i implementat modulul de logic i control a aplicaiei, modulele ce
interactioneaz cu celelalte sisteme i interfaa grafic a aplicaiei.
6. Surse de documentare:
Biblioteca UTCN, Internet, cri procurate online, manualele de utilizare a uneltelor i
documentaia api-urilor i a librriilor folosite n cadrul aplicaiei.

Data:__________

Semntura autorului_________________
Semntura coordonatorului____________

Cuprins
1. Introducere...........................................................................................................................9
1.1 Context......................................................................................................... .................. 9
1.2 Motivaie...................................................................................................... .................. 9
1.3 Obiective...................................................................................................... .................. 9
1.4Prezentarea lucrrii..................................................................................... ................ 10
2. Studiu bibliografic..............................................................................................................12
2.1 Coninut bibliografic................................................................................... ................ 12
2.2 Evoluia centrelor de date........................................................................... ................ 13
2.3 Alte aplicaii de monitorizare...................................................................... ................ 13
2.3.1 Cacti..................................................................................................... ................ 14
2.3.2 Nagios.................................................................................................. ................ 15
2.3.3 OpManager.......................................................................................... ................ 16
2.3.4 Analiza comparativ............................................................................ ................ 17
3. Fundamentare teoretica......................................................................................................19
3.1 Gestionarea centrelor de date..................................................................... ................ 19
3.2 Monitorizarea echipamentelor.................................................................... ................ 19
3.3 Tehnologii, standarde, protocoale i unelte utilizate n
centre de date.................................................................................................... ................ 20
3.3.1 Standardul IEEE 802.3 ....................................................................... ................ 20
3.3.2 Standardul TIA-942............................................................................. ................ 21
3.3.3 Protocolul SNMP................................................................................. ................ 21
3.3.4 Java i JSF .......................................................................................... ................ 22
3.3.5 MySQL ................................................................................................ ................ 23
3.3.6 RRDTool ............................................................................................. ................ 23
3.4 Arhitecturi software multinivel................................................................... ................ 24
4. Specificaiile i arhitectura aplicaiei.................................................................................25
4.1 Gestionarea i monitorizarea centrelor de date.......................................... ................ 25
4.2 Schema bloc a sistemului............................................................................ ................ 25
4.3 Cerinele aplicaiei...................................................................................... .................26
4.3.1 Cerine funcionale.............................................................................. ................ 26
4.3.1 Cerine non funcionale....................................................................... ................ 26
4.4 Scenarii de utilizare..................................................................................... .................28
4.5 Arhitectura aplicaiei.................................................................................. .................34
5. Proiectarea de detaliu.........................................................................................................36
5.1 Structura aplicaiei...................................................................................... ................ 36
5.2 Interfaa cu utilizatorul............................................................................... ................ 41
5

5.3 Structura bazei de date................................................................................ ................ 41

5.4 Comunicarea cu alte sisteme....................................................................... ................ 42
5.4.1 Comunicarea cu serverul MySQL....................................................... ................ 42
5.4.2 Comunicarea cu serverul de email...................................................... ................ 43
5.4.3 Preluarea datelor folosind protocolul SNMP ..................................... ................ 44
5.4.4 Comunicarea cu RRDTool................................................................... ................ 45
6. Utilizarea aplicaiei............................................................................................................47
6.1 Echipamente necesare................................................................................. ................ 47
6.2 Software necesar......................................................................................... ................ 47
6.3 Utilizare....................................................................................................... ................ 47
6.3.1 Administrare ....................................................................................... ................ 48
6.3.2 Utilizare client .................................................................................... ................ 53
7. Testare i rezultate experimentale......................................................................................55
7.1 Tehnologia folosit...................................................................................... ................ 55
7.2 Probleme ntmpinate i modul de rezolvare.............................................. ................ 55
7.3 Rezultate experimentale.............................................................................. ................ 56
8. Concluzii ............................................................................................................................57
8.1 Realizri...................................................................................................... ................ 57
8.2 Avantaje aduse de soluie............................................................................ ................ 57
8.3 Direcii de dezvoltare.................................................................................. ................ 59

Bibliografie..............................................................................................................................60
Acronime..................................................................................................................................62

Lista Figurilor
Figura 1.1 Imagine centru de date........................................................................................... 10
Figura 2.1 Exemplu de grafice oferite de Cacti....................................................................... 14
Figura 2.2 Exemplu de interfa oferita de Nagios.................................................................. 15
Figura 2.3 Exemplu de interfa oferita de OpManager.......................................................... 16
Figura 3.1 Exemplu de etichet server..................................................................................... 19
Figura 3.2 Funcionare SNMP................................................................................................. 22
Figura 3.3 Exemplu de baz de date de tip round robin.......................................................... 24
Figura 3.2 Schema bloc a sistemului....................................................................................... 26
Figura 4.1 Diagrama Use Case pentru Administrator.............................................................. 28
Figura 4.2 Diagrama Use Case pentru Utilizator..................................................................... 29
Figura 4.3 Modelul arhitectural Three-tier.............................................................................. 34
Figura 5.1 Diagrama sistemului............................................................................................... 36
Figura 5.2 Diagrama de clase a aplicaiei................................................................................ 39
Figura 6.1 Pagina Login.jsf...................................................................................................... 48
Figura 6.2 Pagina Admin.jsf.................................................................................................... 48
Figura 6.3 Pagina Addswitch.jsf.............................................................................................. 49
Figura 6.4 Pagina Adduser.jsf.................................................................................................. 49
Figura 6.5 Pagina Addcompany.jsf.......................................................................................... 50
Figura 6.6 Pagina Adddevice.jsf.............................................................................................. 51
Figura 6.7 Pagina Settings.jsf.................................................................................................. 51
Figura 6.8 Pagina Graph.jsf..................................................................................................... 52
Figura 6.9 Exemplu de grafic................................................................................................... 53
Figura 6.10 Pagina User.jsf...................................................................................................... 54
Figura 8.1 Graficul unui server cu probleme........................................................................... 58

Lista Tabelelor
Tabel 2.1 Analiza comparativa a soluiilor existente descrise................................................. 17
Tabel 7.1 Rezultatul unui test de benchmark........................................................................... 56
Tabel 8.1 Avantajele aduse de soluie...................................................................................... 58

Introducere
1. INTRODUCERE
1.1 Context
Internetul este n continu expansiune serviciile web fiind folosite din ce n ce mai
mult. Pentru gzduirea echipamentelor pe care ruleaz site-urile, aplicaiile i alte servicii
online sunt necesare reele special amenajate care ofer conexiuni redundante la internet,
surse nentreruptibile de curent att pentru servere ct i pentru echipamentele de reea
precum i alimentare de la reeaua electric din mai multe puncte sau de la un generator
propriu. Spaiul n care se afl trebuie rcit i bine ventilat pentru a asigura condiii optime de
funcionare tuturor echipamentelor. Acest spaiu, mpreun cu echipamentele, poart numele
de data center sau centru de date i impune existenta unor msuri de securitate suplimentare
pentru protecia datelor.
Centrele de date, n prima parte a existenei lor, nu constau dect n nite ncperi mari
coninnd calculatoarele primilor ani ai erei informatice. Odat cu explozia industriei
microprocesoarelor i a dezvoltrii microcalculaoarelor aceste calculatoare au devenit tot mai
simple, nemaifiind nevoie de echipe complexe de specialiti pentru a le opera. Apariia pe
pia a echipamentelor de reea tot mai ieftine i a standardelor pentru cablarea reelelor a
fcut posibil ca unele companii s i poat ine serverele n spaiul propriu. Pentru multe alte
companii soluia nu a fost practic sau eficient, astfel a aprut migrarea ctre centre de date
private[11].
Figura 1.1 prezint o imagine a unui centru de date. Se poate observa aezarea i
organizarea rack-urilor n rnduri i coloane. Echipamentele din rack-uri au carcase speciale,
rack-mountable, fiind clasificate n funcie de dimensiuni. Dimensiunea celor mai nguste
servere este 1U, o unitate de aproximativ 5 centimetri. Pentru a se pute fixa n rack,
dimensiunile serverelor mai voluminoase sunt multiple ale acestora (2U, 3U, 4U).
Serviciile oferite clienilor sunt colocarea echipamentelor proprii sau nchirierea acestora de la
centrul de date[8]. Pentru clienii care au un numr mai mare de echipamente, inclusiv
propriile echipamente de reea, se poate oferi un rack ntreg sau un grup de rack-uri.
Majoritatea companiilor ce opteaz pentru aceste soluii sunt fie companii de web hosting, fie
companii care au dezvoltat aplicaii web distribuite.
1.2 Motivaie
Pe msur ce se extinde, ca urmare a solicitrilor de servicii din partea unui numr
crescut de clienti, un centru de date trebuie foarte bine organizat i monitorizat. O bun
organizare ajut att extinderea ct i localizarea serverelor i a problemelor hardware.
Monitorizarea are un rol important, buna funcionare i meninerea online a serverelor i
serviciilor depinznd de intervenii ct mai rapide asupra problemelor de orice natur ce pot
apare.
Avnd n vedere faptul c soluiile tradiionale pentru managementul i monitorizarea
unui centru de date folosesc mai multe aplicaii independente iar soluiile Enterprise sunt de
multe ori prea costisitoare, a fost propus proiectarea i implementarea unei aplicaii care s
conin att partea de management ct i partea de monitorizare a echipamentelor din centru
de date.
1.3 Obiective
Organizarea unui centru de date trebuie realizat pe mai multe nivele:
La nivelul fizic, serverele, cablurile i porturile din switch-uri i routere trebuie
etichetate, iar cablurile de reea i de alimentare aranjate n paturi de cablu speciale.
10

Introducere
Serverele sunt puse n rack-uri iar rack-urile sunt numerotate pentru localizarea ct
mai rapid. De obicei rack-urile sunt aezate n rnduri uurnd astfel accesul la
echipamente[18].
La nivelul logic, exist o diagram a centrului de date cu locaia rack-urilor, exist
o baz de date care conine pentru fiecare server cel puin locaia sa exact(rndul i
rack-ul), adresele IP alocate, datele de access (parola de root sau administrator),
numele i datele de contact ale utilizatorului sau a proprietarului, dup caz.

Figura 1.1 Imagine centru de date

Lucrarea i propune proiectarea unei aplicaii personalizate de management i
monitorizare al centrului de date, soluiile actuale existente pe pia fiind fie incomplete, un
sistem complet ar nsemna instalarea mai multor aplicaii independente, fie cu mai multe
faciliti dect ar fi nevoie dar foarte costisitoare.
Partea de management va facilita localizarea rapid a serverelor i va dezvlui
administratorului toate detalile relevante legate de un anumit server i utilizatorul sau
proprietarul su. Se vor monitoriza att limea benzii folosite de servere la un moment dat ct
i traficul total fcut de acestea ntr-o anumit perioad de timp.
Monitorizarea const n ntocmirea de grafice pentru toate porturile switch-urilor iar n
cazul unor defeciuni, funcionri anormale sau alte evenimente nedorite detectate se vor
timite alerte sub form de email. Sistemul va fi scalabil permitnd adugarea de noi
echipamente, modificarea sau tergerea celor existente fr a aduce modificri codului
aplicaiei, toate datele inndu-se ntr-o baz de date.
1.4 Prezentarea lucrrii
Lucrarea conine specificaiile, detaliile de proiectare i utilizare a sistemului de
management i monitorizare al centrului de date. Aceasta este mprita n 8 capitole dup
cum urmeaz:
Introducerea este capitolul n care sunt prezentate contextul i motivaia care au
determinat dezvoltarea acestui sistem precum i obiectivele acestuia.
11

Introducere
Capitolul 2, Studiul bibliografic prezint o scurt descriere a referinelor bibliografice
i evoluia centrelor de date care a determinat apariia acestor sisteme. Tot n acest capitol
sunt descrise cteva din actualele sisteme care ndeplinesc total sau parial cerintele, mpreun
cu avantajele i dezavantajele acestora.
n capitolul 3, Fundamentare teoretic sunt prezentate aspecte despre gestionarea
centrelor de date i monitorizarea echipamentelor subliniindu-se importana acestora. Aici
sunt prezentate i tehnologiile folosite n implementarea sistemului, standardele principale
utilizate ntr-un centru de date, protocoalele i aplicaiile pe care se bazeaz sistemul.
Specificaiile i arhitectura sistemului este capitolul n care se prezint arhitectura
general i o schem bloc a sistemului. Tot aici sunt descrise cerinele detaliate att n ceea ce
privete gestionarea ct i monitorizarea echipamentelor mpreun cu motivaia acestor
cerine.
Proiectarea de detaliu prezint detaliile de implementare ale aplicaiei. Sunt descrise
structura sistemului i a bazei de date mpreun cu diagramele modulelor i modelele
arhitecturale folosite. Se descrie deasemenea realizarea interfeei cu utilizatorul i alte detalii
de implementare.
n capitolul 6, Utilizarea sistemului sunt prezentate cerinele hardware/software ale
echipamentelor monitorizate i ale serverului pe care va rula aplicaia mpreun cu condiiile
de funcionare. Se prezint i un scurt manual de utilizare a aplicaiei.
Testare i rezultate experimentale este un capitol destinat testrii aplicaiei i a
modulelor din care este compus. Tot n acest capitol sunt descrise cateva din probleme
ntlnite pe parcurs i soluionarea acestora.
Capitolul 8, Concluzii i dezvoltare, descrie realizrile i avantajele aduse de sistem,
direcii de dezvoltare i posibile imbuntiri.

12

Studiu bibliografic
2. STUDIU BIBLIOGRAFIC
Pentru documentarea necesar aspectelor teoretice specifice domeniului abordat au
fost consultate o serie de surse bibliografice pe care le menionez in cele ce urmeaz. Acestea
s-au constituit ca punct de plecare absolut necesar fundamentrii teoretice a proiectului, unele
reprezentnd surse reale de inspiraie pentru abordarea propus.
2.1 Coninut bibliografic
Cartea core JavaServer Faces[1] prezint avantajele tehnologiei JSF, n mod special
rapiditatea cu care se face dezvoltarea interfetei cu utilizatorul. n carte sunt prezentate toate
tag-urile JSF si raspunsuri la foarte multe ntrebri.
n lucrarea Essential SNMP[2] este descris protocolul SNMP i utilizarea sa n
managementul i monitorizarea reelelor. Sunt prezentate arhitecturile sistemelor de
monitorizare i o parte din aplicaiile de monitorizare existente.
Lucrarea Retele Locale de Calculatoare de la cablare la interconectare[3] trateaz
primele trei nivele arhitecturale ale modelului de referin OSI i abordeaz toate problemele
teoretice i practice legate de reelele de calculatoare.
n cartea Cascading Style Sheets, 2nd Edition[4] se prezint n mod detaliat
tehnicile pentru integrarea CSS n aplicatiile web, alctuind un mic ghid ce acoper
standardele CSS1 i CSS2.
Lucrrile Windows Admin Scripting Little Black Book, Second Edition[5] i Linux
Shell Scripting with Bash[6] prezint metode de creare a scripturilor si comenzile disponibile
pentru crearea lor pentru sistemele de operare Windows i Linux.
Metodele prin care aplicaiile Java acceseaz date de pe un server MySQL folosind
standardul JDBC sunt prezentate in cartea MySQL and Java Developers Guide[7].
Data Center Fundamentals[8] descrie conceptele care stau la baza organizrii
infrastructurii unui centru de date.
n crile Designing Enterprise Applications with the JavaTM 2 Platform, Enterprise
Edition[9] i J2EE Design Patterns[10] sunt descrise amnunit tehnologiile, modelele
arhitecturale i componentele arhitecturilor utilizate n proiectarea aplicaiilor Enterprise pe
platforma Java.
Articolul History of the data center[11] prezint istoria centrelor de date, de la
primele forme de existen pn n prezent.
Pagina web http://httpd.apache.org/docs/2.0/programs/ab.html[12] descrie utilitarul
de benchmark ab si manualul su de utilizare.
Documentul MySQL 5.0 Reference Manual[13] este manualul de referin al
utilizrii serverului de baze de date MySQL.
Sursele librriilor proiectului OpenDMK i documentaia sa complet sunt disponibile
la adresa web https://opendmk.dev.java.net[14]
Aplicaia OpManager este descris amnunit mpreun cu toate feature-urile la adresa
web [15] unde exist i un demo al acesteia.
Documentaia complet i sursele proiectului RRDJTool se gasesc pe pagina web
http://www.dnseurope.net/opensource/rrdjtool[16].
La adresa web http://oss.oetiker.ch/rrdtool/doc[17] se gsete documentaia
utilitarului RRDTool, descrierea detaliat a fiecrei funcii i exemple demonstrative pentru
fiecare din acestea.
Descrierea standardului TIA-942 este rezumat in documentul TIA-942 Data Center
Standards Overview[18].
Pagina web http://jcp.org/en/home/index[19] prezint descrierea mecanismelor
pentru dezvoltarea specificaiilor tehnice standard n tehnologiile Java.
13

Studiu bibliografic
Articolul
http://www.eweek.com/c/a/Application-Development/OpenSourceFramework-Means-Happy-Trails-for-Java-Developers[20] descrie framework-ul Trails i
avantajele acestuia.

2.2 Evolutia centrelor de date

Dei centrele de date existente sub forma cunoacut acum pe piaa serviciilor de profil
au fost mediatizate i perfecionate n perioada exploziei dot com, spre sfritul anilor 90,
ideea unzor astfel de soluii i are rdcinile la nceputul erei calculatoarelor. Primele
calculatoare erau imense, maini ce aveau dimensiunile unor camere, aveau nevoie de foarte
mult spaiu i de un mediu controlat. Consumnd mult energie se nclzeau iar pentru a putea
menine temperatura n parametri de funcionare a fost nevoie s fie mutate n ncperi
dedicate lor.
Aceste sisteme erau foarte scumpe i multe dintre ele erau folosite n scopuri militare
sau proiecte civile cu o importan major[11], securitatea lor devenind foarte importatnt.
Camerele speciale n care se aflau facilitau sigurana sistemelor i permiteau un control strict
al accesului la maini.
Complexitatea calculatoarelor vechi necesita interconectarea multor componente
folosind cablurice trebuiau s fie foarte bine organizate. Acest lucru a dus la apariia
standardelor care se folosesc i n zilele noastre, evident mbuntite i adaptate.
n anii 1980, odat cu apariia microcalculatoarelor, acestea se instalau n diverse
locaii, comapniile i utilizatorii nu ineau cont de cerinele de mediu i condiiile de
funcionare, astfel n scurt timp s-a ajuns la pierderi de date iar organizarea informaiei nu mai
era posibil. n ciuda apariiei echipelor de specialiti care instalau, configurau i menineau
aceste calculatoare, pentru industrie era nevoie de o soluie.
Acest context a dus la apariia centrelor de date private, cu att mai mult cu ct n anii
1990 complexitatea sistemelor informationale a crescut iar aplicaiile de tip client-server au
devenit tot mai utilizate[11]. Serverele au nceput s ocupe locul vechilor calculatoare iar
apariia echipamentelor de reea tot mai ieftine au dus la apariia standardelor de cablare.
Pe msur ce internetul devenea din ce n ce mai folosit, companiile au ineles
necesitatea prezenei lor n internet, prezen ce presupunea conexiuni sigure i rapide i
capabilitatea de a opera 24 de ore pe zi att pentru mentenan ct i pentru activarea
sistemelor noi. Aceste noi cerine au dus la apariia altor centre de date care la rndul lor au
revoluionat tehnologiile i practicile de operare n industria IT.
Nu toate companiile i-au permis s investeasc n asemenea centre de date fie din
cauza costurilor fie datorit faptului c necesitile lor nu se ridicau la acest nivel i astfel au
aprut centrele de date private. Aceste centre de date au adus soluii noi, pe care majoritatea
companiilor i le pot permite.

2.3 Alte aplicatii de monitorizare

Datorit faptului c monitorizarea serverelor a fost necesar nc de la apariia
primelor calculatoare folosite n acest scop, au fost create mai multe aplicaii care ndeplineau
cerinele administratorilor de sistem. n prim faz se monitorizau caracteristicile mediului
ambiant i ale sistemului pentru ca ncperea s ndeplineasc toate condiiile de funcionare,
apoi s-a nceput monitorizarea traficului, a pachetolr i a altor caracteristici de reea i sistem,
urmnd ca odat cu apariia centrelor de date de dimensiuni mari i diversificrii
echipamentelor s fie nevoie i de soluii de management.

14

Studiu bibliografic
Pentru familiarizarea cu domeniul temei abordate au fost identificate o serie de
instrumente i aplicaii similare existente pe pia i au fost studiate. Au fost instalate i
analizate sub aspectul funcionalitii oferite ct i a raportului pre performan, criteriu
necesar pentru centrele de date de dimensiuni medii. Cele mai reprzentative solutii dintre cele
identificate vor fi descrise succint in continuare.
2.3.1

Cacti

Cacti reprezint un frontend pentru RRDtool, prima versiune a fost lansat n anul
2001, urmnd ca pe parcursul anilor s fie mbuntit, adus la zi cu noutile i s se adauge
capabiliti noi. Este scris n PHP, cu ajutorul lui se pot crea, menine i actualiza grafice i
baze de date de tip RRA(Round Robin Archive).
Se pot seta ci ctre scripturi externe pentru colectarea datelor, sau se pot folosi
scripturi interne. Se pot crea grafice fr a fi nevoie s se cunoasc sintaxa comenzilor pentru
RRDTool acestea putnd fi afiate n mai multe moduri. Deasemenea se pot crea template-uri
pentru sursele de date i grafice, acestea putnd fi aplicate pentru mainile nou adugate n
sistem.
Avantajele sistemului sunt interfaa intuitiv, uor de folosit, posibilitatea aplicrii de
template-uri i metode diferite de afiare a graficelor. Echipamentele sunt aezate structurat i
exist posibilitatea de cutare dup nume.

Figura 2.1 Exemplu de grafice oferite de Cacti

15

Studiu bibliografic

Dezavantajele sunt evidente: nu este un sistem complet de monitorizare, ci doar o

component a unui sistem clasic alctuit din mai multe aplicaii idividuale; nu este capabil s
trimit alerte n cazul unui incident i i lipsete partea de management a dispozitivelor i a
clienilor.

2.3.2

Nagios

Nagios este o aplicaie open source pentru monitorizarea serverelor i a serviciilor,

capabil s trimit alerte n cazul apariiei unei probleme. A fost iniiat de ctre Ethan Galstad
mpreun cu o echip de programatori i lansat n luna martie a anului 1999.
Pe lng monitorizarea serviciilor online (SMTP, POP3, HTTP, FTP, SSH i altele)
mai monitorizeaz i starea i resursele serverelor (ncrcarea procesorului, consumul de
memorie, utilizarea discurilor) i log-urile de sistem.
Exist o muime de plugin-uri pentru monitorizarea temperaturii sau a alarmelor
externe, monitorizarea de la distan prin SSH sau tuneluri encriptate, crearea de grafice pe
baza datelor existente, se pot crea handlere ce intervin pentru rezolvarea proactiv a
problemelor aprute i se poate implementa un sistem redundant de monitorizare. Alertele pot
fi trimise prin email, pager, SMS sau alte metode, n funcie de plugin-ul ales.

Figura 2.2 Exemplu de interfata oferita de Nagios

Dezavantajele solutiei sunt multitudinea de pluginuri ce trebuiesc instalate,
configurate, testate si analizate pentru a le alege pe cele care corespund cerintelor, (fara a avea

16

Studiu bibliografic
experienta in utilizarea sa urmarea acestor pasi consumand mult timp) precum si lipsa partii
de management sau pretul in cazul variantelor enterprise.
2.3.3

OpManager

OpManager este o aplicaie complex pentru managementul i monitorizarea reelelor,

serverelor i aplicaiilor dezvoltat de compania ManageEngine. Printre funciile oferite de
partea de monitorizare a reelelor se numr: monitorizarea traficului, utilizrii la un momnet
dat i a uptime-ului, descoperirea i maparea automat a reelei, precum i monitorizarea strii
echipamentelor de reea. Deasemenea poate monitoriza serverele virtuale bazate pe Wmware
i starea serverelor fizice(utilizarea procesorului, a memoriei, a discurilor precum i starea
componentelor hardware)
Pentru monitorizarea aplicaiilor ce ruleaz pe servere, aplicaia poate monitoriza
servere SQL, Active Directory, Servere de email bazate pe Exchange, servicii i procese
definite de administrator precum i log-uri de sistem, website-uri, anumite fiiere sau
directoare.[15]

Figura 2.3 Exemplu de interfata oferita de OpManager

17

Studiu bibliografic
Alertele se pot trimite prin SMS sau email. Se pot seta valori minime sau maxime ale
diferitelor variabile care atunci cnd sunt atinse sau depite se genereaz alertele[15]. Odat
cu trimiterea alertelor, se pot lansa automat scripturi pentru remedierea problemei
semnalate(dac exist aceast posibilitate).
Soluia este cea mai complet, partea de management a clienilor este oferit ca un
plugin, singura problem o reprezint preul pachetului care n funcie de numrul serverelor
monitorizate poate ajunge la zeci de mii de dolari americani.

2.3.4

Analiza comparativa

n tabelul de mai jos sunt prezentate prin comparaie principalele caracterisitci ale
celor trei aplicaii. Au fost stabilite un set de caracteristici necesare realizrii comparaiei i
anume: monitorizarea echipamentelor(a traficului realizat, a strii serverelor sau a serviciilor
ce ruleaz pe servere) i crearea de grafice, trimiterea de alerte sub orice form (email, sms,
internet messenger), managementul echipamentelor i al bazei de date cu clienilor.
Comparaia este generic ntru identificarea unor aspecte importante i necesare a fi incluse
intr-un produs de monitorizare si management util unui centru de date.

Caracteristici

Cacti

Nagios

OpManager

Creare grafice

DA

DA

DA

Monitorizare
echipamente

NU

DA

DA

Trimitere
Alerte

NU

DA

DA

Management
echipamente

NU

Partial

DA

Management clienti

NU

NU

DA

Pret

gratuit

gratuit/mediu

mare

Tabel 2.1 Analiza comparativa a solutiilor existente descrise

Cacti este doar o interfa pentru rrdtool, dar este gratuit i foarte uor de instalat,
configurat i folosit este o soluie parial fiind utilizat doar n combinaie cu alte aplicaii.
Nagios, dei are mai multe faciliti dect Cacti, este destul de greu de configurat, dar poate fi
o soluie pentru un administrator experimentat. OpManager este de departe cea mai complet
aplicaie, dar preul este foarte mare i n licen sunt incluse unele faciliti care nu sunt
ntotdeauna necesare.
n urma analizei aplicaiilor prezentate anterior, a facilitilor puse la dispoziie de
acestea i a funcionalitilor folosite de un administrator n majoritatea interveniilor sale, am
putut identifica un set minimal de elemente necesare unei aplicaii de management i

18

Studiu bibliografic
monitorizare a unui centru de date de dimensiuni medii. Setul cuprinde n mod obligatoriu
crearea de grafice pentru traficul realizat de echipamente, monitorizarea cel puin a existenei
conexiunii pe porturile echipamentelor, trimiterea de alerte n cazul apariiei anumitor
evenimente precum i managementul echipamentelor pentru identificarea i localizarea
rapid a acestora i managementul bazei de date cu clieni.

19

Fundamentare teoretica

3. FUNDAMENTARE TEORETIC
3.1 Gestionarea centrelor de date
Gestionarea centrelor de date este o component foarte important pentru buna
funcionare a sa. Aceasta trebuie bine indeplinit att la nivel fizic ct i virtual. Odat cu
creterea numrului echipamentelor, ele trebuie bine organizate i etichetate, deasemenea
trebuie inut o eviden clar a tuturor componentelor rezervate schimburilor(n cazul
defectrii) sau mbuntirilor sistemelor.
La nivel fizic aceasta se realizeaz n prima faz prin aezarea echipamentelor n
rack-uri, organizate pe rnduri i numerotarea sau atribuirea de nume pentru fiecare rnd i
coloan. Echipamentele se eticheteaz ct mai sugestiv pentru a ajuta la localizarea i
identificarea ct mai rapid a acestora. Deasemenea cablurile de reea sunt organizate i
aezate n paturi speciale, avnd la rndul lor etichete cu numrul porturilor n care sunt
introduse celelalte capete. De exemplu, o etichet a unui server poate conine urmtoarele
elemente:

ID numr sau expresie unic pentru fiecare echipament

Hostname numele efectiv al ecchipamentului
Client date de identificare a clientului

Figura 3.1 Exemplu de eticheta server

Imaginea reprezint un exemplu de etichet pentru un server. ID-ul este compus dintro liter i un numr, n cazul de fa D nseamn c serverul este dedicat, adic este n
proprietatea centrului de date. n cazul echipamentelor colocate, aduse de clieni, se folosete
litera C iar I se folosete n ID-ul serverelor interne, cum ar fi un server de DNS, de email
sau un nod de servere virtuale. Hostname-ul este indicat s se rezolve la adresa IP a
serverului, acest lucru implic crearea unei nregistrri de tip A n zona de DNS a domeniului
respectiv care s pointeze ctre adresa IP principal. Pentru identificarea clientului se
folosete numele companiei care l deine.
Pe de alt parte, este nevoie de o aplicaie care s conin toate aceste date i s ofere
suport pentru adugarea, modificarea, tergerea i extragerea lor. n momentul cnd sistemul
de monitorizare sau clientul semnaleaz o problem la unul din echipamente, identificarea
locaiei acestuia trebuie s se fac ct mai repede pentru a se interveni.
3.2 Monitorizarea echipamentelor
Monitorizarea este important din mai multe considerente. n primul rnd, pentru buna
funcionare a echipamentelor, att individual, prin detectarea problemelor legate de
componentele hardware i software ct i colectiv deoarece printr-un comportament
neadecvat un echipament influeneaz funcionarea celorlalte.
20

Fundamentare teoretica
Problemele hardware intervin datorit uzurii i a defectelor de fabricaie a
componentelor, fiind nevoie s se intervin pentru nlocuirea acestora. Un HDD defect poate
duce la pierderi de date, pe cnd alte componente precum memoria sau plcile de reea pot
provoca perioade de downtime neprogramat. Problemele software, aprute de multe ori n
urma configurrii defectuoase sau a update-urilor automate pot provoca la rndul lor
ntreruperi ale serviciilor, sau, mai rar pierderi de date. O problem detectat la timp i
rezolvat ct mai eficient minimizeaz pagubele ce pot fi cauzate clienilor.
Serverele compromise sunt deasemenea un risc deoarece de cele mai multe ori de pe
acestea se iniiaz activiti ilegale de tip DOS, flood, port scaning sau spam, care pot afecta
buna funcionare a celorlalte servere sau pot incomoda utilizatorii acestora.
n al doilea rnd, monitorizarea traficului este important deoarece limea de band
este limitat i taxat. Astfel, pentru acoperirea cheltuielilor centrului de date, exist pachete
oferite spre vnzare clienilor, pachete ce au cantiti de trafic exacte, incluse n abonament.
Deasemenea, n cazul mainilor virtuale, care de cele mai multe ori mpart o singur plac de
reea, monitorizarea i limitarea traficului duce la buna funcionare a tuturor serverelor de pe
un nod.
3.3 Tehnologii, standarde, protocoale si unelte utilizate in centre de date
Au fost identificate mai multe standarde, tehnologii i protocoale utilizate ntr-un
centru de date de dimensiuni mici i medii, printre acestea amintim standardul IEEE 802.3,
standard ce definete Ethernet-ul, TIA-942, satandard care descrie infrastructura unui centru
de date i protocolul SNMP, utilizat n comunicarea cu echipamentele de reea n scopul
monitorizrii acestora. Pentru dezvoltarea aplicaiei am folosit un set de tehnologii i tool-uri
care cuprinde Java Enterprise Edition mpreun cu framework-ul JSF, utilizate n dezvoltarea
aplicaiilor web, MySQL, un sistem de gestiune a bazelor de date foarte cunoscut i des
utilizat i RRDTool, o unealt folosit pentru a stoca date i a genera grafice folosind aceste
date stocate.
3.3.1

Standardul IEEE 802.3

IEEE(Institute of Electrical and Electronics Engineers) este o organizaie

internaional, non-profit nfiinat n 1963 orein reuniunea IRE(Institute of Radio Engineers)
i a AIEE(American Institute of Electrical Engineers). Organizaia, mpreun cu IEEE
Standards Association dezvolt standarde legate de tehnologia bazat pe electricitate. Printre
domeniile care utilizeaz aceste standarde se numar: energia electric, tehnologia
informaiei, telecomunicaiile, transportul, nanotehnologia i multe altele.
IEEE 802 este standardul ce acoper reelele locale(LAN) i metropolitane(MAN)
acestea fiind compuse din Familia Ethernet, Token ring, Wireless LAN/MAN i altele.
Ethernet-ul este o familie de tehnologii ce se aplic n reelele locale(LAN) [3].
IEEE 802.3 este colecia de standarde ce definesc Ethernet-ul, mai precis standarde
pentru cablajul i semnalele nivelului fizic al Modelului de Referint OSI i pentru
MAC(Media Access Control) i formatul de adresare al nivelului 2(nivelul legturilor de
date) al stivei. Acest standard st la baza arhitecturii reelei n centrul de date, reea compus
dintr-o colecie de VLAN-uri.

21

Fundamentare teoretica
3.3.2

Standardul TIA-942

TIA(Telecommunications Industry Association) este o asociaie organizaie fondat n

anul 1988 ce are domeniul de activitate format din oportuniti de afaceri, evoluia pieelor,
certificri i dezvoltarea de standarde.
TIA-942 este standardul ce definete infrastructura unui centru de date, n mod
special din privina sistemului de cablare i al design-ului reelei, dar acoper i locaia,
rcirea, alimentarea cu energie electric i amenajarea sa precum i considerente legate de
mediu.
Standardul mparte centrele de date n 4 categorii:[18]
Tier1 Disponibilitatea 99.671%
- Pasibil de ntreruperi datorate activitilor att plnuite ct i neplnuite
- Circuit unic pentru rcire i alimentare cu energie electric
- Fr componente redundante
- Downtime anual 28.8 ore
Tier2 Disponibilitatea 99.741%
- Mai puin pasibil de ntreruperi datorate activitilor plnuite i neplnuite
- Circuit unic pentru rcire i alimentare cu energie electric
- Include componente redundante N+1
- Include podea nlat, UPS i generator
- Downtime anual 22 ore
Tier3 Disponibilitatea 99.982%
- Activitile plnuite nu provoac ntreruperi, dar cele plnuite vor provoca
- Mai multe circuite pentru rcire, unul singur activ
- Include componente redundante N+1
- Include podea nlat, UPS i generator
- Downtime anual 1.6 ore
Tier4 Disponibilitatea
- Activitile plnuite nu provoac ntreruperi, iar centru de date poate
susine cel puin un eveniment neplnuit grav fr aprea ntreruperi
- Mai multe circuite active pentru rcire i alimentare cu energie electric
- Include componente redundante 2(N+1)
- Include podea nlat, UPS i generator
- Downtime anual 0.4 ore
3.3.3

Protocolul SNMP

Simple Network Management Protocol este o parte a suitei de protocoale TCP/IP i

este folosit de sistemele de management ale reelelor pentru a monitoriza dispozitivele active
i a adunce n atenia administratorilor anumite condiii ale echipamentelor sau evenimente
aprute n reea. Acest protocol este o dezvoltare a Simple Gateway Monitoring
Protocol(SGMP). Variabilele accesibile prin SNMP sunt organizate ierarhic ntr-o structur
numit Management Information Base(MIB) i se numesc Object Identifiers(OID). Fiecare
OID reprezint o variabil a dispozitivului care poate fi citit sau dup caz scris[2].
Exemple de OID specificat n RFC 1213:
1.3.6.1.2.1.1.3 sysUpTime reprezint perioada de timp de la ultima
restartare a dispozitivului.
1.3.6.1.2.1.2.1 ifNumber este un ntreg ce reprezint numrul tututor
intrfeelor dispozitivului.

22

Fundamentare teoretica

1.3.6.1.2.1.2.2.1.14 ifInErrors este un ntreg pstrat ntr-un numrtor pe 32

de bii ce contorizeaz erorile de intrare pe interfee.
Versiunea 1 a protocolului a fost definit n RFC 1155 i RFC 1157, urmnd ca n
1992 s apara versiunea 2c care prezint o securitate primitiv i performane crescute. V2c
este definit n RFC 1901-1908, 1909 i 1910. Ultima versiune, v3, conine opiuni avansate
de securitate oferite de un mecanism de control al accesului numit View-based Access
Control Model(VACM). Protocolul SNMP este construit peste UDP, care este un protocol de
transport fr conexiune.[2] Formatul datelor (PDU) pentru SNMP este definit n acord cu
sintaxa ASN.1
Cinci tipuri de PDU-uri SNMP sunt definite astfel: GetRequest, GetNextRequest,
SetRequest, Response i Trap. GetRequest i GetNextRequest sunt folosite pentru a aduce
informaie de administrat de la agent, SetRequest este folosit pentru a stoca sau modifica
informaia de administrat.
Comanda GetRequest este folosit pentru a citi date, variabila solicitat trebuie s fie
specificat prin OID-ul ei. GetNextRequest se folosete pentru a citi valori consecutive aflate
ntr-un tabel. SetRequest este comanda cu ajutorul creia se pot seta variabile ale obiectului
gestionat, comanda se poate utiliza doar dac cel ce o lanseaz are drepturi de scriere. Dac
toate cele trei comenzi de mai sus sunt folosite doar de managerul SNMP, comanda
GetResponse este folosit de ageni, fiind comanda care returneaz valoarea solicitat sau un
mesaj de eroare. Trap-urile sunt folosite tot de ctre agent, acestea fiind trimise spre manager
fr a fi solicitate, dnd agentului abilitatea de a notifica staia de gestiune la apariia
evenimentelor semnificative.

Figura 3.2 Functionare SNMP

Protocolul SNMP a fost standardizat pentru managemenul echipamentelor din reelele
bazate pe IP. Tot mai multe echipamente prezente n aceste reele ofer suport pentru
comunicarea pe SNMP, printre acestea se numr echipamentele specifice precum routere,
switch-uri sau servere, dar i dispozitive ca imprimante, modem rack-uri sau surse
neintreruptibile de curent(UPS)[2].
3.3.4

Java si JSF

Tehnologia Java a devenit un sistem software complet ce reprezint diferite valori

pentru diverse tipuri de utilizatori oferind dezvoltatorilor alegerea platformei n funcie de
necesiti: pentru dispozitive mici i mobile (Java Micro Edition), pentru aplicaii destinate
calculatoarelor personale (Java Standard Edition) sau pentru aplicaii Enterprise i WEB (Java
Enterprise Edition).
Cnd majoritatea aplicaiilor au trecut pe arhitecturi de tipul client-server,
programatorii au nceput s caute metode pentru a simplifica dezvoltarea de proiecte ce
folosesc tehnologii similare i au structuri asemntoare, punndu-se astfel bazele framework23

Fundamentare teoretica
urilor software moderne. Unele organizaii au construit propriile framework-uri care satisfac
cerinele specifice domeniului n care lucreaz, dar au aprut i framework-uri open source
precum Struts, Spring, JSF, Tapestry, Makumba, Seam sau Trails, care a fost numit de ctre
fondatorul su, Chris Nelson, un metaframework sau framework de framework-uri (utilizeaz
Hibernate pentru persistena, Tapestry pentru componente web, Spring pentru rezolvarea
dependinelor i Acegi pentru securitate)[20].
JSF este un framework dezvoltat folosind Java Community Process, un mecanism de
dezvoltare a specificaiilor standard tehnice pentru Java.[19] Pentru a introduce o specificaie
nou se folosesc documente formale care descriu specificaiile i tehnologiile respective.
Aceste documente se numesc Java Specification Requests (JRSs). De exemplu JSF versiunile
1.0 i 1.1 sunt descrise n JSR 127, versiunea 1.2 n JSR 252 iar versiunea 2.0 n JSR 314.
Printre avantajele oferite de JSF se numra: uurina n a crea interfaa cu utilizatorul,
separarea clar ntre nivelul de logic i cel de prezentare al aplicaiei, arhitectura
extensibil(componentele i funcionalitile se pot customiza), cicluri de dezvoltare mai
scurte datorit separrii ntre logic i prezentare, suport pentru limbaje internationale i
existena aplicaiilor care ofer unelte pentru a crea interfaa cu utilizatorul[1]. Aceste
avantaje au condus la alegerea tehnologiei pentru implementarea aplicaiei.

3.3.5

MySQL

MySQL este un sistem de gestiune a bazelor de date(SGBD) relaional distribuit sub

GNU General Public License. n prezent este cel mai popular SGBD open-source, fiind o
component a stivei Linux, Apache, MySQL, Php(LAMP). Programul ruleaz ca un server
oferind acces la bazele de date mai multor utilizatori simultan.
Dei este folosit foarte des mpreun cu limbajul de programare PHP, cu MySQL se
pot construi aplicaii n aproape orice limbaj. Exist multe scheme API disponibile pentru
MySQL ce permit scrierea aplicaiilor n numeroase limbaje de programare pentru accesarea
bazelor de date din MySQL, cum are fi: C, C++, C#, Borland Delphi, Java, Perl, Python,
FreeBasic, Lua, etc. De foarte multe ori, aplicaii relativ simple nu au nevoie dect de
comenzile standard SQL (Select, Insert, Update, Delete, Create i Drop) pentru a opera cu
bazele de date.
S-a optat pentru folosirea acestui SGBD datorit avantajelor sale. Cteva din
principalele avantaje sunt: MySQL este un sistem open-source i gratuit, portabil ruleaz pe
majoritatea sistemelor de operare, rapid algoritmii i tehnicile de indexare sunt foarte
eficiente, flexibil se pot alege tipurile de structuri de date folosite, uor de folosit i
configurat sintaxa este simpl i bine documentat i nu n cele din urm este accesibil din
alte limbaje i sisteme prin intermediul API-urilor[7].

3.3.6

RRDtool

RRDtool a fost scris de ctre Tobi Oetiker ca un nlocuitor pentru Multi Router Traffic
Grapher (MRTG o aplicaie monitorizare a traficului scris n perl), software-ul este liber i
disponibil n termenii licenei GNU General Public License. Numele este un acronim pentru
Round Robin Database Tool.
Round robin este o tehnic ce lucreaz cu cantiti fixe de date i un pointer le
elementul curent. Pentru ilustrare se poate considera c datele sunt aranjate ntr-un cerc iar o
sgeat ndreptat dinspre centru spre margine este pointerul. Cnd o dat este citit sau scris
se trece la urmtorul element. Datele fiind aezate sub forma unui cerc nu exist nceput sau
sfrit, astfel pointerul se poate deplasa ctre urmtorul element la infinit, refolosind locaia
24

Fundamentare teoretica
cea mai veche. n acest fel dimensiunea bazei de date va rmne constant evident n
detrimentul pierderii datelor vechi. ntr-o baza de date round robin se pot stoca date de orice
fel, cu condiia ca acestea s fie numerice i s fie msurabile n timp, adic s reprezinte serii
de timp[17].

Figura 3.3 Exemplu de baz de date de tip round robin

RRDtool are funcii cu ajutorul crora se pot crea, modifica, actualiza, exporta baze de
date de tip round robin, funcii de preluare a anumitor informaii legate de acestea sau de
datele stocate. Programul mai are si o alt facilitate prin care recupereaz datele stocate i le
afieaz sub form de grafice.[17]
Cele mai importante funcii sunt:
create creaz o nou baz de date de tip round robin
update reine o nou valoare n baza de date, aceasta fiind scris n locaia valorii
celei mai vechi
graph creeaz un grafic pornind de la datele uneia sau a mai multor baze de date
transmise ca parametri
dump export datele din baza de date n format ASCII.
restore reface o baz de date dintr-un fiier n format XML, mpreun cu dump,
ajut la migrarea unor baze de date de pe o arhitectur pe alta.
fetch returneaz datele dintr-o anumit perioad de timp
Funciile utilizate n cadrul aplicaiei sunt create, update i graph
3.4 Arhitecturi software multinivel
Exist trei modele de dezvoltare a unei aplicaii de tip client-server:

25

Fundamentare teoretica
Arhitectura pe un nivel (one tier architecture) apare cnd serverul i clientul sunt una
i aceeai aplicaie. Acest model descrie aplicaii relativ simple dezvoltate n ntregime ntr-un
singur mediu de programare. Datele, formularele folosite pentru introducerea lor (interfaa
grafic) i regulile care guverneaz controlul corectitudinii datelor sunt scrise toate ntr-un
singur loc.
Arhitectura pe dou nivele (two layer architecture) apare cnd datele se gsesc ntr-un
alt mediu i sunt accesate prin intermediul primului nivel. Aceast arhitectur descrie unele
aplicaiile client-server. Datele sunt stocate ntr-un server de baze de date primul nivel fiind
responsabil pentru interfaa utilizator i logica programului.
Arhitectura pe trei nivele (three tier architecture) regulile de validare sunt stocate
ntr-un mediu propriu (de multe ori pe echipamente dedicate), astfel nct aplicaiile client le
pot folosi independent una de alta i independent de datele existente. n acest fel, aplicaia
client ofer interfaa, serverul de baze de date ofer datele, iar al doilea nivel se ocup de
validarea datelor[9]. Acest lucru nseamn c exist dou comunicaii client-server: una ntre
aplicaiile client i nivelul al doilea, iar cealalt intre nivelul al doilea i serverul de baze de
date. Aplicaiile client nu comunic niciodat direct cu serverul de baze de date.
Aplicaia prezentat n lucrare este dezvoltat pe trei nivele astfel: nivelul nti
reprezentat de interfaa aplicaiei web accesat prin intermediul unui browser, nivelul doi
compus din agentul snmp, logica de control i validare a datelor i nivelul trei reprezentat de
serverul de baze de date(MySQL) i bazele de date de tip round robin.

26

Specificatiile si arhitectura aplicatiei

4. SPECIFICAIILE I ARHITECTURA APLICAIEI

4.1 Gestionarea i monitorizarea centrelor de date
Un sistem de gestionare i monitorizare a unui centru de date are rolul de a uura
munca administratorilor, punnd la dispoziia acestora toate informaiile necesare pentru
intervenii asupra echipamentelor. Datele din sistem ajut la identificarea rapid a locaiei
unui echipament, pentru mentenana, s a proprietarului acestuia, pentru notificarea sa.
Deasemenea un astfel de sistem este necesar pentru observarea strii reelei i echipamentelor
i pentru contorizarea traficului fcut de ctre server.
4.2 Schema bloc a sistemului
Sistemul este alctuit din trei componente:
Utilizatorii
Aplicaia
Centrul de date
Utilizatorii sau administratorii (utilizatori cu drepturi depline) se pot afla n orice
locaie, condiia pentru a putea utiliza aplicaia este ca acetia s dispun de un calculator
conectat la internet.

Figura 3.2 Schema bloc a sistemului

Aplicaia compus din serverul web mpreun cu logica de control i serverul de baze
de date se poate afla n orice locaie, dar pentru fiabilitate i din considerente de securitate este
indicat s se afle ct mai aproape, chiar n acelai LAN cu cea de a treia component, centrul
de date. Din punct de vedere al sistemului centrul de date reprezint colecia de echipamente
ce sunt monitorizate.

4.3 Cerinele aplicaiei

Sistemul a fost proiectat s rspund urmatoarelor cerine:

27

Specificatiile si arhitectura aplicatiei

4.3.1 Cerine funcionale
Managementul echipamentelor
Prin intermediul aplicaiei administratorul va putea aduga echipamente noi n sistem.
Acesta va putea terge un echipament sau actualiza datele echipamentelor existente dac
intervin modificri. Utilizatorul va putea la rndul su s modifice datele echipamentelor care
ii aparin.
Managementul utilizatorilor
Tot administratorul va aduga n sitem companiile sau persoanele care dein aceste
echipamente, mpreun cu un nume de utilizator i o parol. Acesta va face i maparea ntre
proprietar i echipament, un proprietar va putea deine mai multe echipamente. Datele
utilizatorilor pot fi actualizate dac intervin modificri.
Preluarea i stocarea datelor
Sistemul preia la intervale regulate date pe care le stocheaz n baza de date i arhivele
de tip RRA. Intervalul stabilit este de 1 minut, timp suficient de mare pentru ca prelurile s
nu se suprapun i suficient de mic pentru ca rezultatele s aib o rezoluie ct mai mare
indiferent de perioad.
Trimiterea de alerte
n cazul apariiei unor evenimente cum ar fi indisponibilitatea unui serviciu
monitorizat, defectarea unei componente sau pierderea conectivitii unui echipament,
sistemul trimite alerte pe email specificnd problema i echipamentul pentrua a se putea
verifica i interveni ct mai repede.
Crearea i afiarea graficelor
Pe baza datelor stocate n RRA-uri se creeaz grafice cu traficul total fcut de servere
n anumite perioade (zilnic, sptmnal, lunar sau anual). Utilizatorul sau administratorul va
putea alege perioada pe care s fie generat graficul. Pe aceste grafice se va observa i limea
de band folosit n medie n ultimul minut de funcionare(cu o marj de eroare de maximum
un minut).
Vizualizarea datelor
Utilizatorii sau administratorul vor putea vizualiza n orice moment datele i graficele.
Administratorul va avea acces la toate datele iar utilizatorii doar la datele echipamentelor care
le dein.
4.3.2

Cerine non funcionale

Accesibilitate
Sistemul va fi disponibil att din punct de vedere al locaiei utilizatorilor, fiind o
aplicaie web acetia vor avea nevoie doar de conectivitate la internet i un browser, ct i din
puctul de vedere al cunotinelor necesare, interfaa fiind intuitiv, prietenoas i uor de
utilizat.
Scalabilitate
Administratorul va putea aduga noi echipamente fr a se face vreo modificare
asupra aplicaiei, acestea, odat introduse n baza de date vor fi monitorizate automat de ctre
sistem. Scalabilitatea este necesar deoarece centrul de date este ntr-o continu dezvoltare i
extindere.

28

Specificatiile si arhitectura aplicatiei

Disponibilitate

Sistemul va fi disponibil 24 de ore pe zi, 7 zile pe sptmn pentru ca utilizatorii s poat

accesa datele n orice moment. Acest lucru este uor realizabil, locaia sa fiind chiar n centrul
de date, avnd la dispoziie conexiuni redundante la internet, UPS-uri de capacitate mare i
generator de tensiune propriu.
4.4 Scenarii de utilizare
Utilizatorii sunt mprtii n dou categorii, administratorul, cu drepturi depline, i
utilizatori obinuii(clienii). Att administratorul ct i restul utilizatorilor vor trebui s se
autentifice folosind nume de utilizator i parola pentru a putea accesa aplicaia. Dup
autentificare, fiecare rol are anumite drepturi, acces la diferite zone ale aplicaiei i
funcionaliti specifice.
Funcionalitatile corespunztoare rolurilor sunt:
Administrator:
o Adugarea, editarea i tergerea utilizatorilor
o Adugarea, editarea i tergerea switch-urilor
o Adugarea, editarea i tergerea companiilor
o Adugarea, editarea i tergerea echipamentelor
o Atribuirea echipamentelor ctre utilizatorii ce le dein
o Vizualizarea graficelor
o Editarea setrilor i variabilelor aplicaiei

Figura 4.1 Diagrama Use Case pentru Administrator

29

Specificatiile si arhitectura aplicatiei

Utilizator:
o Editarea datelor echipamentelor proprii
o Vizualizarea graficelor echipamentelor proprii

Figura 4.2 Diagrama Use Case pentru Utilizator

n paginile urmtoare sunt prezentate cteva dintre cele mai importante sau cele mai
utilizate cazuri de utilizare.
Caz de utilizare nr 1: Log in
Descriere:
Autentificarea utilizatorului i redirectarea sa n zona aplicaiei
specific rolului indeplinit
Actori:
Administrator, Utilizator
Precondiie: Aplicaia trebuie s ruleze, utilizatorul are nevoie de un browser web i
conexiune la internet. n browser trebuie introdus adresa web a aplicaiei.
Postcondiie: Utilizatorul este autentificat i n funcie de rolul sau are acces la
funcionalitile specifice.
Scenariu de succes:
1. La accesarea adresei se afieaz pagina de login n care se cere
introducerea numelui de utilizator i a parolei.
2. Sistemul verific datele furnizate i redirecioneaz utilizatorul spre zona
aplicaiei ce corespunde rolului acestuia.
Extensie:
*. Din motive tehnice(conectivitate la internet, eroare de DNS) pagina nu
poate fi afiat: apare pagina default a browserului cu mesajul corespunztor(n
funcie de browser i eroarea ntlnit)
2. Datele de autentificare sunt incorecte: apare un mesaj de eroare i se
revine la punctul 1.

30

Specificatiile si arhitectura aplicatiei

Caz de utilizare nr 2: Adugarea unui utilizator n sistem

Descriere:
Adugarea unui utilizator n baza de date a sistemului, acestuia i se vor
atribui un nume de utilizator i o parol pentru log in.
Actori:
Administrator
Precondiie: Aplicaia trebuie s ruleze i utilizatorul trebuie s fie logat n sistem cu
drepturi de administrator
Postcondiie: Un nou utilizator a fost adugat n sistem, mpreun cu datele sale sau
ale companiei
Scenariu de succes:
1. Administratorul navigheaz la pagina de adugare a unui utilizator.
2. Administratorul introduce datele untilizatorului n cmpurile din pagin i
apas butonul Submit.
3. Noul utilizator este adugat n sistem.
4. Se deschide pagina iniial a administratorului.
Extensie:
*. Din motive tehnice(conectivitate la internet, eroare de DNS) pagina nu
poate fi afiat: apare pagina default a browserului cu mesajul corespunzator(n
funcie de browser i eroarea ntlnit)
2a. Administratorul nu a completat toate cmpurile obligatorii de pe pagin:
apare un mesaj care cere completarea tuturor cmpurilor obligatorii
2b. Numele de utilizator exist deja n sistem: apare un mesaj care cere
introducerea unui al nume de utilizator
Caz de utilizare nr 3: Adugarea unui switch n sistem
Descriere:
Adugarea unui switch n baza de date a sistemului, acesta va putea fi
folosit de echipamente noi
Actori:
Administrator
Precondiie: Aplicaia trebuie s ruleze i utilizatorul trebuie s fie logat n sistem cu
drepturi de administrator
Postcondiie: n sistem a fost introdus un nou switch
Scenariu de succes:
1. Administratorul navigheaz la pagina de adugare a unui switch
2. Administratorul introduce datele switch-ului n cmpurile din pagina i
apas butonul Submit.
3. Noul switch este adugat n sistem.
4. Se deschide pagina iniiala a administratorului.
Extensie:
*. Din motive tehnice(conectivitate la internet, eroare de DNS) pagina nu
poate fi afiat: apare pagina default a browserului cu mesajul corespunztor(n
funcie de browser i eroarea ntlnit)
2. Administratorul nu a completat toate cmpurile obligatorii de pe pagin:
apare un mesaj care cere completarea tuturor cmpurilor obligatorii
Caz de utilizare nr 4: Adugarea unui echipament n sistem
Descriere:
Adugarea unui echipament n baza de date a sistemului
Actori:
Administrator

31

Specificatiile si arhitectura aplicatiei

Precondiie: Aplicaia trebuie s ruleze i utilizatorul trebuie s fie logat n sistem cu
drepturi de administrator.
Postcondiie: n sistem a fost introdus un nou echipament care va fi monitorizat i
pentru care se vor crea grafice.
Scenariu de succes:
1. Administratorul navigheaz la pagina de adugare a unui echipament
2. Administratorul introduce datele echipamentului n cmpurile din pagina i
apas butonul Submit.
3. Noul echipament este adugat n sistemul de monitorizare.
4. Se deschide pagina iniial a administratorului.
Extensie:
*. Din motive tehnice(conectivitate la internet, eroare de DNS) pagina nu
poate fi afiat: apare pagina default a browserului cu mesajul corespunztor(n
funcie de browser i eroarea ntlnit)
3. Administratorul nu a completat toate cmpurile obligatorii de pe pagin:
apare un mesaj care cere completarea tuturor cmpurilor obligatorii
Caz de utilizare nr 5: Cutarea
Descriere:
Cutarea dup un cuvnt cheie n baza de date a sistemului
Actori:
Administrator, Utilizator
Precondiie: Aplicaia trebuie s ruleze i utilizatorul trebuie s fie logat n sistem.
Postcondiie: Se afieaz lista cu rezultatele cutrii.
Scenariu de succes:
1. Utilizatorul introduce cuvntul cheie n rubrica destinat i apas butonul
Search.
2. Se afieaz un tabel cu rezultatele cutrii, cuvntul cheie este comparat cu
numele, prenumele i adresa de email a utilizatorului, hostname-ul, adresa
ip i cmpul cu detalii suplimentare ale echipamentului
Extensie:
*. Din motive tehnice(conectivitate la internet, eroare de DNS) pagina nu
poate fi afiat: apare pagina default a browserului cu mesajul corespunztor(n
funcie de browser i eroarea ntlnit)
1. Cmpul destinat cuvantului cheie este gol: apare un mesaj care informeaz
utilizatorul despre acest lucru
2. n urma cutrii nu s-a gsit nici un rezultat valid: apare un mesaj care
informeaz utilizatorul despre acest lucru

Caz de utilizare nr 6: Vizualizarea graficelor

Descriere:
Vizualizarea graficelor de trafic ale unui echipament din baza de date a
sistemului
Actori:
Administrator, Utilizator
Precondiie: Aplicaia trebuie s ruleze i utilizatorul trebuie s fie logat n sistem
Postcondiie: Utilizatorul vizuaizeaza graficele create de aplicaie
Scenariu de succes:
1. Utilizatorul caut echipamentul al crui grafic dorete s l vad i apas
link-ul View Graph
2. Se deschide pagina ce conine graficele echipamentului respectiv
Extensie:
*. Din motive tehnice(conectivitate la internet, eroare de DNS) pagina nu
32

Specificatiile si arhitectura aplicatiei

poate fi afiat: apare pagina default a browserului cu mesajul corespunztor(n
funcie de browser i eroarea intlnit)
Caz de utilizare nr 7: Editarea datelor unui utilizator
Descriere:
Modificarea numelui, companiei sau a altor detalii ale unui utilizator
din baza de date a sistemului
Actori:
Administrator
Precondiie: Aplicaia trebuie s ruleze i utilizatorul trebuie s fie logat n sistem cu
drepturi de administrator.
Postcondiie: Datele utilizatorului au fost modificate.
Scenariu de succes:
1. Administratorul caut utilizatorul ale crui date dorete s le modifice.
2. Administratorul modific datele untilizatorului n cmpurile din pagin i
apas butonul Update.
3. Datele utilizatorului sunt modificate.
4. Se deschide pagina iniial a administratorului.
Extensie:
*. Din motive tehnice(conectivitate la internet, eroare de DNS) pagina nu
poate fi afiat: apare pagina default a browserului cu mesajul corespunztor(n
funcie de browser i eroarea ntlnit)
2a. Administratorul nu a completat toate cmpurile obligatorii de pe pagin:
apare un mesaj care cere completarea tuturor cmpurilor obligatorii
2b. Numele de utilizator exist deja n sistem: apare un mesaj care cere
introducerea unui al nume de utilizator

Caz de utilizare nr 8: Editarea datelor unui echipament

Descriere:
Modificarea datelor unui echipament din baza de date a sistemului
Actori:
Administrator
Precondiie: Aplicaia trebuie s ruleze i utilizatorul trebuie s fie logat n sistem cu
drepturi de administrator
Postcondiie: Datele echipamentului au fost modificate
Scenariu de succes:
1. Administratorul caut echipamentul ale crui date dorete s le modifice.
2. Administratorul modific datele echipamentului n cmpurile din pagina i
apas butonul Update.
3. Datele utilizatorului sunt modificate.
4. Se deschide pagina iniial a administratorului.
Extensie:
*. Din motive tehnice(conectivitate la internet, eroare de DNS) pagina nu
poate fi afiat: apare pagina default a browserului cu mesajul corespunztor(n
funcie de browser i eroarea ntlnit)
2. Administratorul nu a completat toate cmpurile obligatorii de pe pagin:
apare un mesaj care cere completarea tuturor cmpurilor obligatorii

Caz de utilizare nr 9: Reamintirea parolei

Descriere:
Reamintirea parolei n cazul n care aceasta a fost uitat
Actori:
Utilizator
Precondiie: Aplicaia trebuie s ruleze iar utilizatorul nu se poate loga n sistem

33

Specificatiile si arhitectura aplicatiei

Postcondiie: Utilizatorul primete un email ce conine numele de utilizator i parola
pentru a se putea loga n sistem.
Scenariu de succes:
1. Utilizatorul urmeaz link-ul Forgot password de pe pagina de login a
aplicaiei
2. Utilizatorul introduce numele de utilizator i adresa de email n cmpurile
de pe pagina de reamintire a parolei i apas butonul Submit
3. Email-ul cu datele de logare este trimis la adresa utilizatorului
4. Se deschide pagina de login
Extensie:
*. Din motive tehnice(conectivitate la internet, eroare de DNS) pagina nu
poate fi afiat: apare pagina default a browserului cu mesajul corespunztor(n
funcie de browser i eroarea ntlnit)
2. Adresa de email sau numele de utilizator nu exist n sistem: se afieaz un
mesaj de eroare i se revine la punctul 2.
Caz de utilizare nr 10: tergerea unui echipament
Descriere:
tergerea unui echipament din baza de date a sistemului
Actori:
Administrator
Precondiie: Aplicaia trebuie s ruleze i utilizatorul trebuie s fie logat n sistem cu
drepturi de administrator
Postcondiie: Echipamentul a fost ters din baza de date acesta nu mai este
monitorizat i nu se mai creeaz grafice
Scenariu de succes:
1. Administratorul caut echipamentul care dorete s fie sters.
2. Administratorul apas butonul Remove device din dreptul
echipamentului care trebuie ters.
3. Echipamentul mpreun cu graficele acestuia sunt terse din sistem
4. Se deschide pagina iniiala a administratorului.
Extensie:
*. Din motive tehnice(conectivitate la internet, eroare de DNS) pagina nu
poate fi afiat: apare pagina default a browserului cu mesajul corespunztor(n
funcie de browser i eroarea ntlnit)
Caz de utilizare nr 11: tergerea unui utilizator
Descriere:
tergerea unui utilizator din baza de date a sistemului
Actori:
Administrator
Precondiie: Aplicaia trebuie s ruleze i utilizatorul trebuie s fie logat n sistem cu
drepturi de administrator
Postcondiie: Utilizatorul a fost ters din baza de date mpreun cu toate
echipamentele ce le deine
Scenariu de succes:
1. Administratorul caut utilizatorul care dorete s fie ters.
2. Administratorul apas butonul Remove user din dreptul
utilizatorului care trebuie ters.
3. Utilizatorul mpreun cu tote echipamentele pe care acesta le deine sunt
terse din sistem
4. Se deschide pagina iniiala a administratorului.
Extensie:
34

Specificatiile si arhitectura aplicatiei

*. Din motive tehnice(conectivitate la internet, eroare de DNS) pagina nu
poate fi afiat: apare pagina default a browserului cu mesajul corespunztor(n
funcie de browser i eroarea ntlnit)
4.5 Arhitectura aplicaiei
Arhitectura aplicaiei este una de tipul three-tier: nivelul superior fiind reprezentat de
interfaa cu utilizatorul, nivelul de mijloc de ctre managerul SNMP i celelalte componente
de logic i control, iar nivelul cel mai de jos fiind alctuit din bazele de date MySQL i
RRDtool.

Figura 4.3 Modelul arhitectural Three-tier

Printre avantajele arhitecturii pe trei nivele se numr[10]:

Flexibilitate se pot modifica sau nlocui oricare dintre cele trei nivele fr a le
afecta pe celelalte.

35

Specificatiile si arhitectura aplicatiei

Load Balancing separarea logicii i controlului de bazele de date ajut la

distribuirea ncrcrii serverelor, o ncrcare mai mare a serverului web, datorat
unui numr mare de requesturi nu va ngreuna ntreaga aplicaie.

Securitate nivelul de prezentare neavnd acces direct la nivelul de date, toate

operaiunile efectuate asupra datelor sunt sigure i verificate, deasemenea se pot
lua msuri suplimentare de siguran pentru date n cazul n care nivelul de mijloc
este compromis.

Scalabilitate nivelele 2 i 3 pot fi gzduite pe acelai server, pe servere diferite

sau pe sisteme tip cluster, n funcie de necesiti

Am optat pentru utilizarea acestei arhitecturi n cadrul aplicaiei pentru c dezvoltarea

ulterioar a centrului de date i eventualele modificri minimale s nu necesite modificarea
ntregii aplicaii. Deasemenea arhitectura folosit simplific i dezvoltarea ulterioar a
aplicaiei, adugarea de noi funcionaliti putndu-se face pe etape, nivel cu nivel, ncepnd
de la nivleul bazelor de date, continund cu nivelul de logic i control, urmnd ca n final s
se creeze i partea de interfa pentru a accesa noile feature-uri.

36