Modelarea Sistemelor Raid Si Masurarea Performantelor

Modelarea sistemelor RAID și măsurarea performanțelor

Lucrare de licență

Cuprins

CAPITOLUL 1

Specificații RAID

1.1 Noțiuni generale

1.2 Tehnologia RAID

1.3 Implementarea tehnologiei RAID

1.3.1 Implementare software

1.3.2 Implementare hardware

1.3.3 Implementare hibridă

CAPITOLUL 2

Niveluri RAID Standard

2.1 RAID 0 – Disk Stripping

2.2 RAID 1 – Disk Mirroring

2.3 RAID 2 – Parallel Array with Error Corection Code

2.4 RAID 3 – Parallel Array With Parity

2.5 RAID 4 – Striped Array with Parity

2.6 RAID 5 – Striped Array with Distributed Parity

2.7 RAID 6 – Striped Array with Dual Distributed Parity

Niveluri RAID Hibrid

2.8 RAID 01 (0+1)

2.9 RAID 10 (1+0)

2.10 RAID 100 (10+0)

2.11 RAID 51 (5+1)

2.12 RAID 50 (5+0)

Avantaje și dezavantaje

CAPITOLUL 3

Rebuilding

3.1 Noțiuni Generale

3.2 Functionarea matricilor RAID 5

3.3 Proceduri de rebuilding

CAPITOLUL 4

Simulatorul DiskSim

4.1 Prezentarea simulatorului DiskSim 4.0

4.2 Utilizarea mediului de simulare DiskSim 4.0

4.3 Fișierele de parametri

4.4 Planificarea accesului la datele de pe disc

4.5 Specificațiile componentelor subsistemului I/O

4.6 Parametrii pentru organizarea datelor în matrici de discuri

CAPITOLUL 5

Simulatorul de arhitecturi RAID. Rezultate experimentale

5.1 Simulatorul pentru arhitecturi RAID

5.1.1 Interfața principală

5.1.2 Configurarea simulatorului

5.2 Rezultate experimentale

INTRODUCERE

RAID (Redundant Arrays of Inexpensive Disks sau Redundant Arrays of Independent Disks) este o tehnologie dezvoltata pentru utilizarea simultana a doua sau mai multe unitati HDD intr-o o configurație (matrice), in scopul obtinerii de performante crescute alaturi de o crestere a nivelului de siguranta a datelor.

În ultimii 25 de ani, standardul RAID s-a schimbat pentru a deveni o caracteristică indispensabila pentru metodele de stocare ale claselor enterprise, dar in acelasi timp și o varianta de stocare orientata către consumator. RAID imprastie datele pe mai multe discuri dure pentru a crește toleranța la erori si pentru a îmbunătăți performanța disc-ului.

RAID trebuie privit ca un instrument ce furnizeaza diferite nivele de stocare si care creste performanța și disponibilitatea sistemelor clasice. Unitatile de disc continuă să devină mai fiabile si cu capacități mai mari. Cu toate acestea, din ce in ce mai multe date sunt stocate, expunandu-le la riscuri atunci când unul dintre discuri se defectează. În plus, față de aspectul de disponibilitate a RAID și tehnologiile de protecție a datelor, inclusiv oglindire locală și la distanță sau de replicare pentru alte sisteme de stocare, RAID oferă, de asemenea, îmbunătățiri ale performanței pentru a ajuta la restabilirea balanței între capacitate și rezultate excepționale. [12]

RAID reprezinta un acronim pentru Redundant Array of Independent Disks – matrice redundantă de discuri independente si este realizat prin combinarea mai multor discuri într-o unitate logică, unde datele sunt distribuite în unități în diferite moduri numite "niveluri RAID".

Tehnologia RAID se imparte în mai multe scheme de stocare, care pot diviza și reproduce datele între mai multe discuri fizice. Discurile fizice funcționează ca un singur disc într-o matrice RAID ce este accesată de sistemul de operare. Diferitele scheme sau arhitecturi sunt numerotate cu o cifra dupa cuvântul RAID (spre exemplu: RAID 0, RAID 1 etc.). Fiecare schemă furnizează un raport diferit între două obiective principale: creșterea fiabilității datelor și creșterea performanței intrare/ieșire. [4]

CAPITOLUL 1

Specificații RAID

1.1 Noțiuni generale

Norman Ken Ouchi reușește să obțină în anul 1978 o licență ce se intituleză „Sistem pentru recuperarea datelor stocate de pe unități de memorie”. Continutullicenței sale descria ceea ce mai târziu urma să fie cunoscut sub termenul de “RAID 5 cu scrieri în fâșii pline”. Această licență, din 1978, avea să inoveze prin oglindiriea și/sau duplicitatea discurilor (mai târziu denumită RAID1) precum și protecția datelor prin paritate dedicată (ulterior denumită RAID 4).

Cu toate acestea, ideea de RAID a fost introdusă ca atare pentru prima dată în 1987, de către David A. Petterson, Garth A. Gibson și Randy Katz, o echipă de cercetători de la Universitatea Berkley din California. Tehnologia RAID a fost prezentată la acea vreme ca fiind o metodă ieftină și eficientă de backup. Aceștia au studiat posibilitatea utilizări a două sau mai multe unități ca una singură pentru sistemul gazdă și au publicat o lucrare intitulată: „Un caz de matrice redundantă de discuri ieftine (RAID)”. Lucrarea lor specifica un număr de niveluri RAID”, fiecare având avantaje și dezavantaje teoretice.

De-a lungul anilor au apărut diverse implementări ale conceptului RAID. Singurul aspect care a rămas la fel este numerotarea. Majoritatea diferă de nivelul original RAID. Acest lucru poate crea confuzie, deoarece, de exemplu, una dintre implementările RAID 5poate fi complet diferită de cealalta. RAID 3 și RAID 4 sunt adesea confundate și chiar folosite interschimbat.

În lucrarea „Un caz de matrice redundantă de discuri ieftine (RAID)” autorii defineau formal nivelele RAID de la 1 la 5 în secțiunile 7 – 11:

„Primul nivel RAID: Discuri Oglindite”

„Nivelul doi RAID: Coduri Hamming pentru Corectarea Erorilor”

„Nivel trei RAID: Un Singur Disc De Verificare Per Grup”

„Nivelul patru RAID: Citiri și Scrieri Independente”

„Nivelul cinci RAID: Date împărțite/paritate pentru toate discurile(nu este un disc unic de redundanță)”

„Nivelul șase RAID: Redundanță P+Q”. Aici matricea RAID necesită accesarea a șase discuri datorită necesități de a reînnoi ambele informații: P și Q

„Nivelul zece RAID: striped mirrors (oglinzi întrețesute)”. Termenul este acum folosit pentru a exprima combinația dintre RAID 0 (întrețesut) și RAID 1 (oglindit).[2]

1.2 Tehnologia RAID

O singură unitate logică formată din mai multe hard discuri fizice ce folosește o componentă hardware sau o aplicație software poartă numele de tehnologie RAID.

Principale tipuri în RAID sunt:

mirroring (oglindirea) – se bazează pe copierea aceluiași set de date pe mai multe discuri. Oglindirea poate crește viteza de citire a datelor deoarece sistemul poate accesa date diferite de pe cele două discuri. În aceași timp însă, scrierea va fi mai lenta dacă sistemul insistă ca ambele discuri să confirme corectitudinea datelor scrise.

striping (întrețesute) – constă în împărțirea datelor pe mai multe discuri; Formatul întrețesut este folosit in mod special pentru mărirea performanței, deoarece citirea secvențelor de date se face de pe mai multe discuri in mod simultan.

error correction (cu corectarea erorilor) – unde discurile redundante de verificare stochează datele pentru a fi detectate și corectate eventualele erori. Verificarea erorilor în mod obișnuit va încetini sistemul deoarece datele vor fi citite din mai multe locații și apoi comparate. [6]

Diferitele configurații afectează in mod diferit stabilitatea și performanța (viteza de acces). Folosirea mai multor discuri în paralel crește probabilitatea ca unul dintre ele să se defecteze; dar utilizand funcții automate de detectare si corectare a erorilor, sistemul poate deveni mai stabil și poate repara in mod automat(„din mers”) anumite erori. Gamele de discuri moderne oferă posibilitatea de a alege și a schimba configurația RAID după dorință.

Sistemele RAID au fost proiectate să ruleze in continuare chiar și în caz de defectare completă a unui disc– discurile pot fi schimbate „la cald” iar datele pot fi recuperate in mod automat, în timp ce sistemul rulează în continuare (eventual un pic mai lent, până la terminarea recuperării datelor). Prin comparație, sistemele de discuri normale trebuie oprite până când datele sunt recuperate.

RAID este adesea folosit in sistemele ce necesita o rata de acces cat mai ridicată si unde este important ca sistemul să ruleze cât mai multă vreme cu putință. In general, RAID este folosit la servere, dar poate fi folosit și în cazul stațiilor de lucru (workstation). [2]

1.3 Implementarea tehnologiei RAID

RAID combină hard discuri fizice într-o singură unitate logică folosind o component hardware sau o aplicație software. Soluțiile hardware prezintă sistemului RAID atașat ca un singur hard disc, fără ca sistemul de operare să cunoască arhitectura fizică. Soluțiile software sunt implementate în sistemul de operare, dar aplicațiile utilizează arhitectura RAID ca o singură unitate.

Distribuția de date intre mai multe unități poate fi realizată atât hardware cât și software. Pe langa aceste doua modalitati exista și un mod hibrid, format atat dintr-o pare hardware, cat si dintr-o parte software.

1.3.1 Implementare software

Majoritatea sistemelor de operare furnizeaza implementări software. Acest layer sesitueaza deasupra driverelor discurilor și oferă un strat de abstractizare între discurile logice și discurile fizice. În mod normal RAID-ul software se limiteaza la RAID 0, 1 și 5. În sistemele de operare multi-thread (Linux, Mac OS X, Novell,Windows NT, 2000.. ) sistemul de operare poate executa mai multe procese I/O (permite scrieri și citiri multiple). Această caracteristica permite, în plus, realizarea RAID 0/1 în implementare software cu toate că nimeni nu folosește această practică. Acest lucru se realizeaza deoarece calcularea paritatii (datele redundant) necesita o putere de procesare ridicata. Implementările software necesită timpi redusi de prelucrare si consuma foarte puține resurse. În anul 2007 calculatoarele personale, obișnuite, ofereau puterea de calcul necesară crescând folosirea procesorului cu doar un procent în plus.Ele erau eficiente ca și cost până într-un punct neoferind însă același grad de performanță ca și RAID-ul bazat pe hardware. RAID-ul software foloseste resursele unui server legat la spațiul de stocare, CPU-ul acestuia fiind doar partial ocupat cu procesarea datelor. În cazul unei defecțiuni a serverului, datele aflate in spațiul de stocare nu pot fi accesate atâta timp cât defecțiunea persistă. În hardware matricea de HDD-uri poate fi atașată ușor altei gazde astfel timpul de recuperare se reduce simțitor .Totuși acest sistem este la fel de eficient ca și cel software în cazul în care nu există un sistem de backup al hostului pe care să se facă trecerea rapid.

Implementarea software permite si crearea de matrici RAID din partiții ale unui HDD.

1.3.2 Implementare hardware

RAID-ul hardware are solicita minim un controller RAID. Într-un calculator personal

acest controller poate consta intr-un card PCI sau poate fi inclus în chipset-ul plăcii de bază. În aplicațiile industriale controllerul lucrează ca și unitate separată. HDD-urile pot fi SATA, IDE/ATA, SSA, SCSI, canal optic sau combinații ale acestora. Sistemul ce utilizeaza acest sistem de stocare poate fi conectat in mod direct la controller sau printr-o rețea SAN (StorageArea Netork). SAN-ul este o rețea ce utilizeaza un protocol de comunicare asemănător cu SCSI. Acest protocol se poate suprapune peste o rețea Ethernet. Controlerul se ocupa de managementul discurilor și calculează datele redundante caracteristice nivelului RAID ales. Majoritatea acestor sisteme au implementata o memorie cache nevolatilă, ce inbunatațeste performanțele. Implementarea hardware prezintă performanțe garantate, fără utilizarea procesorului gazdei, controllerul prezentând sistemului de operare un simplu disc logic. De asemenea, sistemele industriale prezintă suport pentru "hot swapping" (schimbarea HDD-urilor defecte fără a fi necesară oprirea sistemului ).

1.3.3 Implementare hibridă

Sistemele hibride RAID si-au facut aparitia odată cu introducerea controllerelor ieftine RAID implementate în controlere HDD și ca extensii de BIOS reprezentate de drivere de sistem. Din pacate aceste controllere efectueaza toate calculele necesare în regim software. Ele aduna majoritatea dezavantajelor implementării software și hardware. Ca și implementările hale industriale controllerul lucrează ca și unitate separată. HDD-urile pot fi SATA, IDE/ATA, SSA, SCSI, canal optic sau combinații ale acestora. Sistemul ce utilizeaza acest sistem de stocare poate fi conectat in mod direct la controller sau printr-o rețea SAN (StorageArea Netork). SAN-ul este o rețea ce utilizeaza un protocol de comunicare asemănător cu SCSI. Acest protocol se poate suprapune peste o rețea Ethernet. Controlerul se ocupa de managementul discurilor și calculează datele redundante caracteristice nivelului RAID ales. Majoritatea acestor sisteme au implementata o memorie cache nevolatilă, ce inbunatațeste performanțele. Implementarea hardware prezintă performanțe garantate, fără utilizarea procesorului gazdei, controllerul prezentând sistemului de operare un simplu disc logic. De asemenea, sistemele industriale prezintă suport pentru "hot swapping" (schimbarea HDD-urilor defecte fără a fi necesară oprirea sistemului ).

1.3.3 Implementare hibridă

Sistemele hibride RAID si-au facut aparitia odată cu introducerea controllerelor ieftine RAID implementate în controlere HDD și ca extensii de BIOS reprezentate de drivere de sistem. Din pacate aceste controllere efectueaza toate calculele necesare în regim software. Ele aduna majoritatea dezavantajelor implementării software și hardware. Ca și implementările hardware ele sunt proprietare unui fabricant de controllere RAID și nu se pot face combinări între mai multe controllere. Avantajele constau în abilitatea de a boot-a de pe discul logic și integrarea mai strânsă cu driverul device-ului ce oferă o manipulare mai bună a erorilor.

CAPITOLUL 2

Niveluri RAID Standard

Inițial au fost concepute 5 niveluri RAID, dar pe măsură ce tehnica a evoluat au apărut mai multe variații ale acestora, cum ar fi nivelurile hibrid și mai multe niveluri non-standard. Acestea niveluri RAID (inclusiv formatele de date asociate lor) sunt standardizate de către SNIA în standardul DDF – Common RAID Disk Drive Format.

Diferitele niveluri RAID folosesc unul sau mai multe dintre tipurile enumerate la punctul 1.2 în funcție de cerințele sistemulu. Principalele obiective ale arhitecturilor RAID sunt: mărirea siguranței datelor și creșterea vitezei de acces. Stabilitatea și performanța sunt afectate în mod diferit de către diferitele configurații ce pot fi folosite.

2.1 RAID 0 – Disk Stripping

RAID 0 nu este o arhitectură RAID în adevăratul sens al cuvântului deoarece nu asigură nicio redundanță a datelor. RAID 0 este folosit strict pentru maximizarea performanțelor în lucrul cu harddisk-urile. După cum spune și denumirea, datele sunt întrețesute (stripping) în mod secvențial pe mai multe discuri, ce sunt tratate ca un singur disc (sau volum) virtual. De obicei 4 discuri formează un volum. Implementările RAID 0 divizează volumele în felii și scriu datele în felii consecutive, localizate fizic pe fiecare disc din cadrul ariei de discuri.

Operațiile de scriere și citire au loc în paralel fiind executate pe toate discurile aflate în volum. Mărimea feliilor este definită de către utilizator și poate fi de 512 sectoare ,spre exemplu, dimensiunea uzuală a sectoarelor putând fi de 512 octeți. Utilizâ nd această tehnica de intretesere se obtine o rata de atransfer a datelor foarte ridicata, imbunatantindu+se in felul acesta si performanta efectiva a sistemului.

În eventualitatea defectării chiar și a unui singur disc al ariei, RAID 0 nu oferă redundanță datelor. În lipsa posibilității de regenerare a discului, d atele ce se găsesc pe acesta se vor pierde.

Din acest motiv, RAID 0 nu este folosit în aplicațiile de înaltă disponibilitate.

Fig. 2.1

Repartiția blocurilor de date în RAID 0

2.2 RAID 1 – Disk Mirroring

RAID 1 asigură redundanța datelor prin oglindirea acestora (mirroring). Metoda aceasta creează două sau mai multe copii ale aceluiași volum de date și le plasează pe discuri separate. Fiecare copie este o imagine oglindită a celeilalte.

RAID 1 poate scădea performanța generală a sistemului deoarce trebuie să efectueze tot atâtea scrieri câte copii. Performanța citirilor este însă mult îmbunătățită deoarece cererile sunt trimise simultan controlerelor de discuri ale tuturor copiilor. Discul care răspunde primul cererii de citire va returna datele sistemului.

Această metodă este mai puțin sigură comparativ cu scrierea secvențială, dar realizează o creștere semnificativă a performanțelor la scriere. RAID 1 este cea mai scumpăi implementare deoarece asigură redundanța datelor în proporție de 100% și totodată asigură cea mai mare disponibilitate a datelor prin utilizarea celui mai mic număr de discuri din configurație.

Anumite sisteme de operare de tip UNIX ale unor sisteme de calcul tolerante la defectări oferă prin intermediul unei componente software numită “Logical Volume Manager” un alt tip de RAID 1. Această componentă crește performanța sistemului oferind posibilitatea scrierii în paralel pe toate copiile, fără a se mai aștepta ca scrierea pe o copie să se efectuze cu success și apoi să se altereze conținutul altei copii. Comparativ cu scrierea secvențială, această metodă este mai puțin sigură, dar oferă o creștere semnificativă a vitezei de scriere. Întrucât RAID 1 asigură redundanța datelor în proporție de 100%, ea este cea mai scumpă implementare dintre toate tipurile de arii de discuri, dar asigură și cea mai mare disponibilitate a datelor prin utilizarea celui mai mic număr posibil de discuri în configurație. [1][3]

Fig. 2.2

Repartiția blocurilor de date în RAID 1

2.3 RAID 2 – Parallel Array with Error Corection Code

Acest model presupune că discurile în paralel distribuie datele pe mai multe discuri efectuând o întrețesere la nivel de bit, iar în cadrul ariei de discuri sunt utilizate și discuri de verificare. Citirea și scrierea datelor se face utilizând tehnici de codificare bazate pe coduri corectoare de erori de tip Hamming pentru a asigura detecția și corecția erorilor.

Din păcate RAID 2 vine cu mai multe dezavantaje decât avantaje. Printre acestea trebuie amintit faptul că utilizarea tehnicilor de codare bazate pe coduri corectoare de erori de tip Hamming necesită utilizarea unor grupuri mari de discuri pentru a asigura consistența (ex: 4 discuri de verificare pentru 10 discuri de date, 5 discuri de verificare pentru 25 de discuri de date). Din cauză că această tehnică de codificare este foarte complexă și scump de realizat, RAID 2 nu prezintă un real interes pentru mediul comercial.

Fig. 2.3

Repartiția blocurilor de date în RAID 2

2.4 RAID 3 – Parallel Array With Parity

RAID 3 folosește doar un singur disk dedicat pentru memorarea informațiilor de paritate, celelalte discuri din cadrul ariei de discuri fiind folosite pentru memorarea informației utile ce este împrăștiată pe toate discurile ariei. (exact ca și în cazul RAID 2).

Acesta efectuează un SAU EXCLUSIV asupra datelor și nu un cod corector de erori.

Cantitatea minimă de date care este scrisă sau citită într-o operație de intrare sau de ieșire este egală cu numărul de discuri din arie înmulțit cu numărul de octeți ai sectorului discului. Aceasta este cunoscută ca unitate de transfer. La un moment de timp dat nu poate fi activă decât o singura cerere de intrare sau de iesire deoarece capetele de acces se misca in paralel in aria de discuri. Acest lucru ne asigura o rata buna de transfer a datelor atunc cand datele accesate sunt dispuse secvential pe disc, dar face ca RAID 3 sa nu fie suficient de practic pentru aplicatii cu date dispuse aleator in aria de discuri. O rata de transfer foarte buna se obtine atunci cand unitatea de transfer are aceasi marime cu dimensiunea blocurilor de date care se scriu sau se citesc. Cu cat blocurile transferate sunt de dimensiuni mai mici, cu atat rata de transfer scade.

RAID 3 ofera si posibilitatea inlocuirii la cald a unui disc si recuperarea datelor.

2.5 RAID 4 – Striped Array with Parity

In cazul RAID 4 datele sunt distribuite la fel ca si in cazul RAID 3 pe mai multe discuri de date si pe un disc de paritate. Diferenta consta in faptul ca un bloc de date se afla pe un singur disc, astfel incat citirea se face accesand un singur disc si nu pe ambele. Astfel aria de discuri poate prelucra mai multe cereri deodata intrucat discurile nu se mai utilizeaza in paralel.

Discul de paritate devine un element de scadere a performantei intrucat este implicat in toate operatiile de scriere. Acest lucru se intampla deoarece paritatea, pentru fiecare operatie de scriere, se calculeaza avand in vedere si informatia de pe celelalte discuri, in sectoarele de date asociate. Aceasta procedura face ca RAID 4 sa fie considerat nepractic.

Fig. 2.4

Repartiția blocurilor de date și de paritate în RAID 4

2.6 RAID 5 – Striped Array with Distributed Parity

In cazul RAID 5 datele sunt distribuite pe mai multe discuri de date si pe un disc de paritate. RAID 5 nu are insa un disc dedicat special numai pentru informatia de paritate, ci distribuie informatiile de tip date si informatiile de tip paritate pe toate discurile ariei.

RAID 5 permite mai multe accese concurente la dispozitivele din cadrul ariei de discuri, fiind satisfacute astfel multiple cereri concurente de intrare sau iesire. Astfel, performanta transferurilor pentru aceste arii de discuri creste semnificativ, acestea devenind cele mai potrivite si utile in cazul operarii cu blocuri de dimensiune mica, sau cu datele dispuse in mod aleator pe discuri.

Ciclul de scriere se realizeaza in 3 pasi:

Pasul 1 – Este citita paritatea existenta si data ce urmeaza a fi schimbata

Pasul 2 – Vechea data din valoarea paritatii existente este scazuta si apoi se memoreaza paritatea corecta intr-un buffer

Pasul 3 – Este calculata noua paritate pe baza valorii din buffer si a valorii noii date de memorat si se scriu pe discurile corespunzatoare noua data si paritatea actualizata

Implementarile software ale RAID 5 sunt suportate de catre multe sisteme moderne de operare (Linux, Windows Server etc.). Procesorul efectueaza toate calculele pentru paritate, iar in cazul unei defectiuni, operatiunile de intrare sau de iesire sunt de pana la de 3 ori mai consumatoare de resurse. Avand un cost relativ scazut per GB utili si o performanta medie foarte buna, RAID 5 este utilizat cu succes pentru toate tipurile de transfer (servere pentru baze de date rationale, servere de fisiere) [1][3]

Fig. 2.5a

Repartiția blocurilor de date și de paritate în RAID 5

2.7 RAID 6 – Striped Array with Dual Distributed Parity

Ceea ce diferentiaza nivelul RAID 6 de nivelu RAID 5 este faptul ca se calculeaza si se stocheaza paritate dubla pentru date. In consecinta sunt necesare minim 4 discuri, performanta scazand datorita calculului dublu de paritate. Redundanta creste insa, aria suportand doua discuri defecte. Reconstructia datelor poate fi un mare consumator de resurse, performanta fiind puternic afectata, dar redundanta dubla compenseaza prin posibilitatea de amanare a procesului de rebuilding pentru un plus de viteza.

Pentru a crea nivele etajate de RAID, oricare nivel poate fi combinat cu alt nivel, dar cel mai des sunt folosite nivelele 0 si 1.

Fig. 2.5b

Repartiția blocurilor de date și de paritate în RAID 6

Niveluri RAID Hibrid

Nivelurile RAID hibride combină două sau mai multe niveluri standard de RAID pentru a obține performanță și redundanță suplimentară. Atunci când combinăm nivelurile RAID, un tip de RAID care oferă redundanță este de obicei unit cu un tip de RAID 0 ce mărește performanța. Cu aceste configurații, este de preferat să existe RAID 0 pe partea de sus și matrici redundante în partea de jos, deoarece mai puține discuri vor trebui să fie regenerate atunci când un disc se defectează. Prin urmare, RAID 1+0 este preferabil lui RAID 0+1, dar avantajele administrative ale "oglinzii împărțite" de RAID 1 ar fi pierdute. Trebuie remarcat, cu toate acestea, faptul că aspectul blocurilor pe disc pentru configurațiile RAID 1+0 și RAID 0+1 sunt oarecum identice, deci aceste limitări apar doar în software. [5]

2.8 RAID 01 (0+1)

Acest nivel dispune minim 4 discuri grupate în fâșii (oglindite), înlătură neajunsurile și îmbunătățește performanțele, însă crește complexitatea. RAID 0+1 creează un al doilea set de fâșii oglindite cu un set primar de fâșii de discuri. Matricea continuă să funcționeze cu unul sau mai multe unități de stocare afectate în aceeași oglindă stabilită, dar dacă driverul cedează de pe ambele părți ale oglinzii, datele de pe sistemul RAID sunt pierdute.

Fig. 2.6

Repartiția blocurilor de date: RAID 0+1

2.9 RAID 10 (1+0)

Acest nivel dispune minim 4 discuri grupate în fâșii (oglindite), înlătură neajunsurile și îmbunătățește performanțele, însă crește complexitatea. Diferența față de RAID 0+1 este că RAID 1+0 creează discuri cu date întrețesute de la o serie de unități de stocare în oglindă. Într-o situație de eșuare, RAID 1+0 funcționează mai bine, deoarece toate celelalte discuri continuă să fie utilizate. Matricea poate susține mai multe discuri pierdute, atât timp cât oglinda nu pierde toate unitățile sale.

Fig. 2.7a

Repartiția blocurilor de date: RAID 1+0

2.10 RAID 100 (10+0)

Un raid 100, numit uneori și RAID 10+0, este o felie de tipuri RAID 10. Din punct de vedere logic el este de fapt o matrice RAID 10 implementată cu ajutorul software-ului RAID 0 peste hardware-ul de RAID 10.

Principalul avantaj al RAID 100 față de un singur nivel RAID este răspândirea încărcării pe mai multe controllere, obținându-se astfel performanță mai bună la citiri aleatoare și atenuarea riscurilor pe matrice. Tocmai din acest motiv, RAID 100 reprezintă cea mai bună alegere când vine vorba de baze de date foarte mari, unde controllerele hardware de RAID limitează numărul de discuri fizice permise în fiecare matrice standard.

Fig. 2.7b

Repartiția blocurilor de date: RAID 10+0

2.11 RAID 51 (5+1)

Acest nivel hibrid este o matrice formată din două matrice RAID 5, care sunt oglindite una față de cealaltă. În general această configurație este folosită astfel încât fiecare set de RAID 5 se află pe un controller separat. Astfel, scrierile și citirile sunt echilibrate în ambele matrice RAID 5. Unele controllere suportă RAID 51 pe mai multe canale pentru a ține sincronizate părțile diferite. În această configurație, cele două seturi de RAID 5 nu șiu că reprezintă oglindirea celuilalt, iar RAID 1 nu știe că discurile sale de bază sunt RAID 5.

Această configurație poate susține eșecul oricărui disc din orice matrice, plus încă un disc suplimentar din cealaltă matrice înainte să existe pierderi de date. Spațiul maxim ce se poate găsi pe un RAID 51 este egal cu dimensiunea unui set individual RAID 5. [5]

2.12 RAID 50 (5+0)

RAID50 combină feliile de blocuri de la nivelul RAID0 cu paritatea distribuită de RAID5

Aceasta este de fapt o matrice RAID 0 întrețesută de-a lungul elementelor RAID 5. Pentru a realiza un nivel hibrid RAID 50 avem nevoie de cel putin 6 discuri.

Avantajul acestei configurații este că ca pot eșua câte un drive din fiecare set, fără să se piardă date. Cu toate acestea, unitățile rămase în acel set devin un punct slab pentru întreaga matrice până când discul defect este înlocuit. Este suficient să se mai defecteze un singur disc (pe lângă cel inițial) și întreg sistemul cedează, datele stocate în întreaga matrice fiind pierdute. Timpul petrecut în procesul de rebuilding reprezintă o perioadă de vulnerabilitate a setului RAID. [5]

Fig. 2.8

Repartiția blocurilor de date și de paritate: RAID 5+0

Avantaje și dezavantaje

CAPITOLUL 3

Rebuilding

3.1 Noțiuni Generale

Notiunea de rebuilding se refera la reconstructia sistematica a datelor de pe discul defect, pe un disc de rezerva. Aceasta procedura incepe imediat ce discul de rezerva devine disponibil.

Matricile RAID folosesc discuri de rezerva pentru a minimiza pierderea datelor. Astfel dupa ce un disc se defecteaza, datele de pe acesta pot fi reconstruite imediat pe discul de rezerva (rezerva dedicata – “dedicated sparing”). Rezerva distribuita – “distributed sparing” si rezerva de paritate – “parity sparing” reprezinta doua alternative de rezerva. In cazul rezervei de paritate sistemul porneste fara rezerva, dar daca un disc pica, atunci grupurile de paritate aflate in matrici diferite sunt combinate pentru a forma matrici si grupuri de paritate mai mari.

O matrice RAID poate functiona in unul din urmatoarele 3 moduri:

Modul Normal – Discurile principale sunt operationale, iar discul de rezerva poate fi atat

functional cat si defect sau in reparatie.

Modul Deteriorat – Presupune deteriorarea unuia din cele N+1 discuri primare. In continuare, pentru a recrea blocul de date pierdut, cererea pentru citirea datelor de pe discul defect presupune accesul la blocurile corespunzatoare de pe discurile functionale. O cerere de scriere pe discul eșuat rezulta în citirea celor N blocuri de date corespunzătoare pentru a calcula blocul de paritate (folosind noua versiune a blocului de date), urmată de o simplă scriere a blocului de paritate. Astfel, rata de cereri pentru discurile funcționale aproape se dublează.

Modul Rebuild – Operatia de rebuilding porneste dupa ce unul din discuri iese din functiune, ne mai fiind capabil sa reintre in modul normal de lucru al sistemului. În modul de rebuild sistemul citește trasee consecutive de date de la toate discurile funcționale în paralel, calculează conținuturile traseelor discului defect (prin aplicarea operației XOR asupra celor N trasee coresupunzatoare din discurile funcționale), și scrie traseele reconstruite pe discul de rezervă. (În scrierea pe discul de rezervă nu luăm în considerare opțiunea de a verifica, conform căreia blocurile de date abia scrise sunt recitite pentru a verifica scrierea. Această opțiune aproape dublează încărcarea pe discul de rezervă, astfel încât timpul de rebuild este de așteptat să fie dominat de timpul de scriere pe acest disc când această opțiune este activă). Sistemul este predispus la pierderea datelor în cazul în care unul din discurile funcționale cedează înainte ca reconstrucția să fie completă.

Cea mai mica unitate de date ce poate fi reconstruita se numeste Unitate de Rebuild (UR) si este de obicei o unitate intretesuta sau o parte a acesteia.

Trebuild reprezinta timpul necesar reconstruirii discului defect, iar Traspuns reprezinta timpul de raspuns la cererile utilizatorului. Aceste doua marimi sunt principalele repere pentru masurarea performantei sistemului.

Rebuildingul se imparte in 2 categorii: orientat pe fâșii si orientat pe disc. In cazul rebuildingului orientat pe disc se dedica un proces pentru fiecare disc care citeste UR in mod asincron de pe discurile ce au supravietuit. In rebuildingul orientat pe fasii, fiecare UR este reconstruita printr-un proces dedicate care citeste UR de pe discurile supravietuitoare, executa intre ele operatia logica XOR si scrie UR rezultata pe discul de rezerva.

Rebuildingul orientat pe disc necesita un buffer mai mare fata de rebuildingul orientat pe fasii atunci cand se considera un numar mic de procese, insa rebuildingul orientat pe disc este mai performant.

Din punct de vedere al spatiilor tampon se poate afirma ca exista 2 categorii: spatii

tampon temporare si spatii tampon dedicate scrierii.

Spatiile tampon temporare sunt dedicate citirilor de pe fiecare disc, in timp ce spatiile

tampon dedicate scrierii sunt dedicate scrierii pe discul de rezerva.

Spatiile tampon sunt interschimbabile si au ca unitate de masura tot o unitate de reconstructive (UR). Imediat ce o UR este citita in spatial tampon, i se aplica o operatie logica XOE cu unitatile UR corespunzatoare si rezultatul este stocat in zona tampon de pe discul de rezerva. Spatiile tampon nu se epuizeaza niciodata deoarece operatia XOR este foarte rapida. Datorita acestui fapt, citirea unitatilor de UR de pe discuri, in timpul unui rebuild orientat pe disc, nu este oprita din cauza limitarilor de memorie. Totusi, spatiul tampon pentru discul de rezerva, are un efect asupra performantei de reconstructie. Toate trimiterile viitoare la spatiul tampon implica memoria tampon a discului de rezerva.

Cererile de rebuild pot fi procesate in doua feluri: cu aceasi prioritate ca si cererile utilizatorului si la o prioritate mai mica decat cererile utilizatorului. Modelul Clientului Permanent (PCM) presupune o prioritate egala a cererilor de rebuild cu cererile de utilizator. In acest model o singura cerere este procesata la un moment dat intr-un sistem de tip coada de asteptare. Imediat ce o cerere a fost servita, ii vine randul urmatoarei, iar la sfarsitul cozii de asteptare vine o alta noua.

Fig. 3.2

Modelul PCM de procesare a cererilor

Modelul Serverului de Eliberare (VSM) reprezinta o alternativa mai buna pentru PCM, oferind timpi de raspuns si reconstructie mai mici. Acesta efectueaza reconstructia atunci cand nu se afla nicio cerere de utilizator in asteptare (adica imediat ce discul devine inactive). Imediat ce soseste o cerere de utilizator reconstructia este oprita.

Fig. 3.3

Modelul VSM de procesare a cererilor

3.2 Functionarea matricilor RAID 5

Un sistem RAID 5 este format din N+1 discuri primare care contin blocuri de date, blocuri de paritate si un disc de rezerva dedicat. Un sir de biti asociati pe blocurile de date folosind operatia logica XOR formeaza un bloc de paritate. Blocurile de paritate sunt distribuite uniform in discurile primare pentru a preveni o posibila strangulare.

Pentru a scrie un bloc de date, matricele RAID 5 necesita 4 accesari ale discului pentru ca paritatea trebuie alterata de fiecare data cand blocurile de date sunt modificate.

Cele 4 accesari ale discului sunt:

1. Citire date vechi

2. Citire paritate veche

3. Scrierea noilor date

4. Scrierea noii paritati

Inainte de a incepe recuperarea datelor de pe o matrice RAID 5 trebuie sa determinam configuratia si parametrii. Configuratia unei matrice RAID 5 consta in cunoasterea urmatorilor parametrii:

Cate discuri sunt in configuratia RAID 5

Care este secventa discurilor

Ce valoare s-a folosit pentru marimea blocurilor

Care este pattern-ul de paritate folosit

Toti acesti parametrii pot fi determinati manual sau automat. Pentru a determina pozitia

paritatii trebuie sa stim faptul ca rotatia acesteia decurge dupa cum este ilustrat in figura urmatoare:

Fig. 3.4

Rotația parității

Pentru a determina pozitia trebuie sa privim blocurile de memorie din matrice. Blocul care arata cel mai putin ca un bloc de date, este blocul de paritate.

Determinarea ordinii discurilor se realizeaza prin urmarirea fisierelor text foarte lungi. Se prefer acele fisiere care au si timestamps. Pentru a gasi astfel de fisiere pe discuri se folosesc tool-uri special, cum ar fi WinHex. Cand s-a gasit un fragment dintr-un astfel de fisier pe unul din discuri, este nevoie sa gasim discul ce contine urmatorul fragment si asa mai departe. In acest fel se poate determina ordinea discurilor, desi este imposibil de afirmat care disc a fost primul.

Pentru a determina care disc a fost primul, trebuie sa folosim din nou un tool de vizualizare a discurilor si sa cautam urmatoarele 2 lucruri, in functie de tipul de RAID pe care il avem:

MBR-ul (Master Boot Record) – in cazul unui RAID realizat hardware

Sectorul de boot – in cazul unui RAID realizat prin mijloace software

In cazul unui RAID realizat hardware, discul care contine MBR-ul este primul disc din acel RAID. Master Boot Record este un tip special de sector de boot aflat la inceputul partitiilor unui element masiv de stocare (mass storage device). MBR-ul retine informatii cu privire la organizarea partitiilor logice pe acel mediu de stocare. Partitiile logice contin fisierele de sistem.

In cazul unui RAID realizat software, discul ce contine Sectorul de Boot la inceput este primul disc. [123]

3.3 Proceduri de rebuilding

Un hard poate intampina 2 tipuri de probleme, si anume:

probleme logice: problemele apar la nivelul partitiilor si pot fi caracterizate prin: coruperea sistemului de fisiere din cauza atacului cu virusi, stergerea accidentala a unui folder sau chiar a intregii partitii, formatarea accidentala si blocarea sistemului de operare prin intermediul sectoarelor bad. Recuperarea datelor in acest caz nu ridica mari probleme si presupune utilizarea unor soft-uri concepute special pentu a putea accesa datele corupte. Mai trebuie mentionat faptul ca recuperarea datelor cu ajutorul unui soft este valabila atata timp cat hard disk-ul este functional.

probleme fizice: se produc atunci cand cel putin una dintre componentele hardului se defecteaza.

Problemele fizice includ:

probleme de natura firmware: nu tine de partea electrica si poate fi definit drept imposibilitatea de a accesa o informatie aflata pe suprafata hardului utila in citirea datelor existente pe acesta.

Recuperarea datelor se face cu echipament specializat dar si cu o vasta experienta in domeniu.

probleme mecanice: apar datorita utilizarii indelungate a produsului, fluctuatiilor de curent electric sau a diferitelor probleme legate de fabricatia acestuia. Cand apare un defect mecanic urmatoarele componente pot fi afectate: stricarea totala sau partiala a capetelor de citire sau scriere, deteriorarea motorului, zgarierea suprafetelor.

probleme electrice: apare mai ales datorita fluctuatiilor de curent. Numai cu ajutorul procesului de reconstructie a zonelor afectate se poate ajunge la recuperarea datelor aparent pierdute. [456]

Sistemele RAID pot fi concepute să ruleze mai departe chiar și în caz de defectare

completă a unui disc dur din RAID – discurile pot fi înlocuite „la cald” și datele recuperate automat, în timp ce sistemul rulează în continuare (eventual ceva mai lent, până la terminarea recuperării datelor).

In procesul de rebuild exista 3 proceduri de copiere:

Rebuild folosind procedura de baza – Actualizările de blocuri de date sau paritate vizate pentru discul defect sunt utilizate pentru a actualiza blocurile discului de rezervă dacă blocul este deja reconstituit. Pentru a reconstrui un bloc de date, cererile de citire adresate discurilor defecte conduc la citirea blocurilor corespunzatoare din toate discurile inca functionale, chiar daca blocul de date a fost deja recreat in prealabil pe discul de rezerva.

Rebuild cu citire redirectionata – In cazul procedurii de baza, blocurile de date sunt recreate. In aceasta a doua procedura, blocurile de date reconstruite pe discul de rezerva sunt citite direct de pe el. Acest lucru ajuta la scurtarea timpului de rebuild si la reducerea utilizarii discurilor functionale. Chiar daca citirile redirectionate interfereaza cu scrierile de rebuild pe discul de rezerva, atata timp cat discul de rezerva nu constituie o strangulare, incheierea procesului de rebuilding depinde in timp de citirea discurilor functionale.

Rebuild Piggy-backing pe un workload normal – “Ideea aici este de a "captura" un bloc de date de pe discul defect, care este reconstruit datorită unei cereri de citire, ce a fost emisă ca parte din workload-ul normal. O implementare relativ simplă este posibilă presupunând doar o ușoară modificare a unui spațiu tampon convențional. Atunci când o citire de pe discul defect este satisfăcută de reconstrucția blocului, conținuturile blocului vor fi stocate într-un spațiu tampon. În acest moment copia tampon poate fi marcată ca fiind "modificată", adresa discului asociată cu pagina de tampon poate fi schimbată pentru a referi discul în așteptare, iar harta de bit pentru reconstrucție poate fi schimbată pentru a afișa această pagină ca fiind copiată. Înlocuirea normală a spațiului tampon va copia în cele din urmă conținutul la blocul corespunzător pe discul în așteptare. (La sfârșitul reconstrucției orice bloc rămas în cache poate fi aruncat la discul în așteptare). Piggy-backing și citirea redirecționată pot ajuta la reducerea încărcării pe discurile funcționale într-o matrice care are un disc defect. Măsura în care acest lucru poate aduce un beneficiu depinde de mai mulți factori. Pentru aceeași rată de reconstrucție și aceeași rata minimă de acces pentru workload-ul normal, atât citirea redirecționata cât și piggy-backing pot fi utilizate pentru a reduce sarcina pe discurile funcționale. Așadar, capacitatea de acces I/O fiind disponibilă pe discurile funcționale, poate fi folosită pentru a susține fie un workload mai mare în timpul reconstrucției sau un rebuild mai rapid.” [11-Marcu Andrei]

“Comparația timpului de rebuild pentru diferite astfel de scheme se bazează pe utilizarea valorilor medii în estimarea timpului necesar de dispozitivul de strangulare (discurile funcționale sau discul de rezervă) pentru a finaliza procesul de rebuild. Un sistem RAID cu clustere(grupuri) are mărimea grupului G ≤ N + 1 și o rată de declustering α = (G – 1) / N ≤ 1. Performanța sistemului în modul deteriorat este mai bună pentru valori mai mici ale lui , din moment ce un număr mai mic de discuri va fi implicat în prelucrarea cererilor fork-join. Una din concluziile studiului care tratează acest aspect este că unele dintre optimizările propuse au ca rezultat o creștere, și nu o scădere a timpului de rebuild. Acest lucru se datorează faptului că studiul de simulare în ia în considerare caracteristicile detaliate de disc, cum ar fi necesitatea de a invoca o urmărire înainte de unele accesări de disc.” [10-Andrei Marcu]

CAPITOLUL 4

Simulatorul DiskSim

4.1 Prezentarea simulatorului DiskSim 4.0

Programul DiskSim este un software de simulare efficient, exact si extrem de configurabil al sistemelor cu discuri. Acest program a fost conceput pentru a fi de folos celor care lucreaza in cercetare oferind detalii cu privire la numeroase aspecte din arhitectura subsistemelor de stocare. DiskSim (ajuns la versiunea 4.0) a fost creat de către John S.Bucy, Jiri Schindler, Steven W. Schlosser, Gregoiy R. Ganger, Bruce R. Worthington și Yale N. Patt la "University of Michigan". Aceasta ultima versiune (4.0) vine cu îmbunătățiri aduse variantei precedente (3.0), unele deficiențe fiind rezolvate, precum si unele librarii fiind restructurate pentru o mai mare eficiență și pentru a face simulatorul mult mai ușor de utilizat. In particular, modulul de discuri poate simula in mare detaliu configuratii moderne de discuri fiind recunoscut pentru multitudinea de detalii oferite precum si pentru fidelitatea acestora.

La nivel structural, simulatorul este compus din mai multe module ce permit configurarea diverselor componente ale unui sistem de stocare. Astfel, au fost făcute configurabile în simulator, discurile, controller-ul, buss-urile, cache-urile precum și componentele software care dirijează activitatea acestora: driverele, algoritmii de planificare a transferului, organizarea structurilor RAID etc. Simulatorul include de asemenea si un modul micro-electro-mecanic (MEMS – based module).

Simulatorul primeste ca parametru de intrare un fișier cu înregistrări (trace-uri) ale activității pe magistrala I/O. Aceste trace-uri provin de la un sistem real sau pot fi create de un generator intern de sarcini de lucru (workload). Modulul de generare a trace-urilor (generatorul de workload) este foarte flexibil, permițând modelarea cu acuratețe a diverselor rate de sosire a cererilor. DiskSim 4.0 simulează și raportează numai aspectele legate de performanța sistemelor de stocare și nu modelează comportamentul restului de componente ale unui sistem de calcul sau interacțiunea dintre acestea și sistemul de stocare pe discuri. Cu toate că simulează aspectele legate de stocarea datelor pe discuri, DiskSim nu salvează sau reface efectiv datele provenite de la o cerere. Partea de cod a simulatorului este scrisă în limbajul C și necesită pentru compilare compilatorul GCC al sistemului de operare Linux.

Pentru alte aspecte legate de compilarea programului în Linux se va citi fișierul README situat în directorul cu fișiere de cod DiskSim de pe CD-ul anexat prezentei lucrări. Libparam unifică parametrii de intrare ai DiskSim-ului. Acest lucru face mai ușoară simularea utilizând fișierele de input ale modelul de disc dorit fără a mai copia cod de intrare pentru a putea rula simulatorul. [8]

4.2 Utilizarea mediului de simulare DiskSim 4.0

Mediul de simulare DiskSim poate fi incarcat si compilat pe orice sistem ce ruleaza Linux, distributia acestuia nefiind importanta. Se remarca o usurinta mai mare la instalarea acestuia pe o distributie bazata pe Debian.

Pentru a putea rula, DiskSim solicita in linia de comanda 5 parametrii. Fisierul curent trebuie stabilit ca fiind “valid”.

unde:

diskSim – este numele fișierului executabil

parfile – reprezintă numele fișierului cu parametrii

outfile – este numele fișierului de la ieșire. Dacă în locul acestui parametru se aplică “stdout ” rezultatele vor fi afișate pe monitor

tracetype – specifică tipul de trace care se află în fișierul de trace-uri (ascii, validate etc.)

tracefile – este numele fișierului de trace-uri ce va fi folosit la intrare. Pentru ca în loc să

folosim un fișier cu trace-uri, putem introduce datele de la tastatură folosind comanda “stdin”

synthgen – setează generatorul de workload-uri în stare activă sau pasivă (valoarea 0 dezactivează generatorul, în timp ce orice altă valoare îl activează).

par_override – permite ca o serie de parametrii implici_i ai simulatorului sau o parte din

parametrii transmiși prin fișierul de parametri să fie înlocuiți cu valori transmise prin linia de comandă.

Sintaxa exactă este precizată mai jos:

unde:

component – este numele unei componente ai cărei parametri se doresc a fi

modificați;

parameter – este un șir de caractere ce identifică parametrul care va fi înlocuit; Dacă numele conține spații libere el trebuie pus între ghilimele, astfel ca shell-ul să-l considere un singur argument. Pentru a referenția un parametru al unei subcomponente, cum ar fi de exemplu planificatorul unui disc, se folosește scrierea Scheduler parameter:

newvalue – este noua valoare a modulului instanțiat.

4.3 Fișierele de parametri

Pentru a insera fișierul de parametrii, DiskSim folosește libparam. Libparam unifică parametrii de intrare ai DiskSim-ului. Intr-un astfel de fișier cu parametrii găsim:

blocuri – delimitate de accolade {}, ce constă într-un număr de asignări de tipul “name = value”

instanțieri

specificații topologice

În exemplu de mai jos este ilustrat un exemplu concret de linie de comandă:

Această comandă realizează următoarele acțiuni:

citește parametrii inițiali din fișierul parms.1B. Specificațiile sunt stocate în fișiere separate și incluse apoi în fișierul principal de parametri, fiind de obicei foarte detaliate.

exportă rezultatele pe monitor (din cauza comenzii stdout)

citește din fișierul t.Jan6 fluxul de intrare ASCII

nu generează activitate sintetică

se alege planificatorul de disc (în acest caz 2 = Elevator SCAN) pentru discul instanțiat cu numele ‘disc0’ și pentru driverul acestuia (‘driver0’)

În fișierul parms.1B există câteva caracteristici ale discului cum ar fi: statistica blocurilor,

specificațiile driverelor, magistralelor și ale controllerelor precum și instanțierea acestora sub diferite denumiri. Tot în cadrul acestui fișier, prin comanda “source” este ales fișierul .discspecs și este descrisă topologia sistemului. În fișierul .discspecs este inclus fișierul .model tot prin comanda „source” apoi sunt enumerați parametrii ce se referă la organizarea internă a harddisk-ului (planificator de disc, condiții de scriere / citire etc.). În fișierul .model este descrisă partea cea mai jos a hard disc-ului (suprafețe, cilindri, numărul de blocuri, împărțirea pe zone, piste, sectoare). În ultima parte a acestui fișier se poate alege un fișier .seek din care simulatorul își calculează curba de distanțe de căutare. Fișierul .seek ajută la modelarea matematică a harddisk-ului. Specificațiile sunt de obicei foarte detaliate și de aceea ele sunt stocate în fișiere separate și incluse apoi în fișierul principal de parametri.

Fișierul principal de parametri pentru un disc simplu conține:

Max queue length – numărul maxim de cereri ce pot fi găsite în coadă la un moment dat;

Scheduler – o coadă de I/O;

Bus transaction latency – întârzierea pe care o implică transferul fiecărui mesaj de către disc;

Acces time – sinonim pentru "Constant acces time";

Bulk sector transfer time – timpul necesar discului să transfere pe magistrală un bloc de 512 biți;

Print stats – specifică dacă statisticile discului sunt sau nu scoase în fișierul de ieșire;

Block count – capacitatea discului exprimată în blocuri;

Command overhead – specifică o întârziere de procesare care are loc imediat ce o cerere a sosit către disc;

Constant acces time – specifică valoarea fixată pentru timpul de acces;

Never disconnect – specifică dacă discul ține întreg controlul discului pe toată perioada îndeplinirii cererii sau nu (0/1);

4.4 Planificarea accesului la datele de pe disc

Un calculator utilizează cel mai frecvent dispozitivele de I/O, adică discurile. Acest subcapitol prezintă câteva moduri de planificare a accesului la discuri. Un HDD este compus din mai multe platane. Fiecare platan utilizează două capete pentru scrierea și citirea datelor. Unul dintre capete este folosit pentru partea de sus a platanului, iar celălalt pentru partea de jos. Ambele părți ale platanului sunt alcătuite din mai multe piste. Fiecare pistă este împărțită la rândul ei în mai multe sectoare.

Un ansamblu de brațe cuprinde capetele ce accesează platanele. Un braț se poate deplasa doar în două direcții: înspre ax sau în direcția opusă axului. Toate capetele de scriere / citire se mișcă înainte și înapoi împreună, astfel încât fiecare cap este întotdeauna situat la aceeași pistă. Nu se poate să avem un cap la pista 0 și altul la pista 1000. În afară de deplasarea capetelor, axul permite rotirea astfel încât capetele să poată accesa sectorul de pe pista pe care se situează. Și din cauza acestui aranjament, de multe ori locația pistei nu este menționată ca un număr de pistă, ci mai degrabă ca un număr de cilindru. Un cilindru este în esență un set al tuturor pistelor. Referirea la sectoare individuale ale discului se face în mod tradițional prin trimitere la cilindri, capete și sectoare (CHS). [13-Andrei Marcu]

Fig. 4.5

Geometria fizică a hard disk-ului

Atunci când unitatea de disc este în operare, discul se rotește la viteză constantă. Astfel, o dată ce capul este poziționat la pista dorită, aceasta pur și simplu așteaptă până când sectorul dorit se afla sub el. Timpul necesar pentru a muta capul este cunoscut sub numele de timp de căutare și timpul necesar pentru că sectorul dorit să devină disponibil la nivelul capului este cunoscut sub numele de întârziere de rotație sau latenta de rotație. Odată ce capul este în poziție, operația de citire sau scriere pot fi efectuate, fapt care reprezintă porțiunea de transfer de date. De asemenea, o cerere de I/O s-ar putea să aibe de așteptat într-o coadă de cereri I/O până când discul devine disponibil. Diagrama generală a transferului I/O de disc este prezentată în figură 3.2 [13-Andrei Marcu]

Algoritmii de planificare a accesului la disc sunt:

First Come First Served (FCFS) – este cel mai simplu și direct algoritm de planificare, încare cererile sunt prelucrate în aceeași ordine în care acestea sunt primite. Această strategie are avantajul de a fi corectă în sensul formal, însă se comportă într-o măsură asemănătoare cu planificarea aleatoare deoarece cererile I/O vin în într-un mod aleatoriu și cel mai probabil nu vor accesa pistele de pe suprafața disc-ului în ordinea potrivită. Mai este cunoscut sub numele de “First In First Out” (FIFO), “Run To Completion” sau “Run Until Done”.

SCAN (Elevator) – Cu excepția FCFS, aproape toate politicile pot lăsa unele cereri neprelucrate până când întreaga coada s-a golit. Cu alte cuvine, pot sosi mereu noi cereri care vor fi alese înainte de o cerere existentă. În cazul SCAN, brațul se mișcă în ambele direcții, satisface toate cererile, până când ajunge la ultima pistă într-o direcție sau până când nu mai există cereri în acea direcție, dupa care porneste in sens opus. Se observa faptul că favorizează pistele din centru deoarece brațul trece prin regiunea de mijloc mai des față de extremitățile discului.

Circular SCAN (C-SCAN) – este similar cu SCAN dar restrânge scanarea într-o singură direcție. Astfel, atunci când ultima pistă a fost vizitată într-o direcție, brațul se întoarce la capătul opus de disc și scanarea o ia de la început. Acesta reduce întârzierea maximă experimentată de cererile noi.

Shortest Seek Time First (SSTF) – selectează cererea I/O de disc care necesită cea mai puțină mișcare a brațului de la poziția sa actuală. Deși o serie de decizii optime, fiecare la câte un pas nu garantează o soluție optimă de ansamblu, această politică va avea o performanță mai bună decât FCFS.

VSCAN – combină algoritmul SSTF (Shortest Seek Time) și algoritmul SCAN (Elevator). VSCAN deservește cererile folosind algoritmul SSTF atunci când nu este necesară schimbarea direcției de deplasare a capului de citire/scriere. Furnizează un echilibru bun intre timpul mediu de răspuns și rezistența la “înfometare” (fenomenul de întârziere a unor cereri).

Shortest Positioning Time First (SPTF) – Ca și la SSTF la SPTF apare problema "înfometării", cererile care necesită mai mult timp pentru poziționare fiind amânate pe o perioadă lungă de timp. Pentru a reduce variația răspunsului în timp, se dă prioritate cererilor care sunt în așteptare în coadă de o perioadă prea lungă de timp. Prioritatea crește pe măsură ce cererea așteaptă mai mult în codă, sau se poate stabili o limită de timp, după care cererilor în așteptare să li se dea prioritatea maximă. O variantă a acestui algoritm este SATF (Shortest Access Time First) care se referă la reducerea timpului de poziționare împreună cu reducerea timpului de transfer.

LOOK – similar lui SCAN, capul circula de-a lungul suprafeței de disc satisfăcând cereri în direcții alternante. Capul de citire/scriere își schimbă direcția de parcurgere dacă nu mai există cereri în acea direcție, rezultând o reducere a numărului de cilindri parcurși.

Circular LOOK (C-LOOK) – Algoritmul C-LOOK reprezintă o combinație între C-SCAN și LOOK. Capul de citire/scriere se mișcă la fel ca la algoritmul SCAN cu deosebirea că aici se mișcă doar până la ultima cerere în fiecare sens, după care inversează direcția de deplasare imediat, iar pe calea de întoarcere , capul de citire al discului se oprește. [13][14]-Andrei Marcu

În continuare voi prezenta o listă cu algoritmii puși la dispoziție de mediu de simulare DiskSim 4.0

FCFS

ELEVATOR LBN

CYCLE LBN

SSTF LBN

ELEVATOR CYL

CYCLE CYL

SSTF CYL

SPTF OPT

SPCTF OPT

SATF OPT

WPTF OPT

WPCTF OPT

WATF OPT

ASPTF OPT

ASPCTF OPT

ASATF OPT

VSCAN LBN

SDF APPROX

SDF EXACT

SPTF ROT OPT

SPTF ROT WEIGHT

SPTF SEEK WEIGHT

TSPS

4.5 Specificațiile componentelor subsistemului I/O

Scheduling policy – specifică algoritmul de planificare folosit pentru selectarea următoarei cereri ce va fi îndeplinită

Cylinder mapping strategy – specifică nivelul de cunoaștere a dispunerii datelor pe disc

0 → înseamnă că singura informație disponibilă este cea cu privire la numărul blocurilor logice ale fiecărei cereri

1 → indică faptul că planificatorul mai cunoaște și frontierele zonelor, numărul de sectoare / zonă și numărul de sectoare fizice / pistă pentru fiecare zonă

2 → planificatorul are de asemenea acces la informațiile despre dispunerea sectoarelor și

pistelor de rezervă din fiecare zonă

3 → planificatorul are acces și la lista cu sectoarele și pistele "adormite";

4 → planificatorul are acces la lista sectoarelor și pistelor remapate, asigurând astfel o

mapare LBN corectă

5 → planificatorul folosește numărul de cilindru dat împreună cu cererea, admițând

experimente cu diverse mapări

6 → planificatorul are acces numai la numărul mediu de sectoare/cilindru

Write initiation delay – reprezintă o aproximare a întârzierilor de procesare la scrierea cererilor, ce au loc înaintea oricăror întârzieri de poziționare. Această valoare este folosită de algoritmii de planificare care selectează cererile m funcție de întârzierea de poziționare

Read initiation delay – reprezintă o aproximare a întârzierilor de procesare la citirea cererilor, ce au loc înaintea oricăror întârzieri de poziționare. Această valoare este folosită de algoritmii de planificare care selectează cererile în funcție de întârzierea de poziționare

Sequential stream scheme – o valoare întreagă, interpretată ca un câmp de date boolean. Aceasta fumizează informațiile despre concatenarea cererilor:

bitul 0 → specifică dacă cererile de citire secvențiale sunt sau nu concatenate de

planificator

bitul 1 → specifică dacă cererile de scriere secvențiale sunt sau nu concatenate de planificator

bitul 2 → specifică dacă cererile de citire sunt sau nu planificate împreună

bitul 3 → specifică dacă cererile de scriere sunt sau nu planificate împreună

bitul 4 → specifică dacă cererile de citire / scriere sunt planificate într-o ordine aleatoare,

împreună, pentru a fî îndeplinite de disc

Maximum concat size – lungimea maximă a unei cereri, rezultată din concatenarea a mai multe cereri secvențiale;

Overlapping request scheme – specifică politica de planificare folosită pentru tratarea cererilor suprapuse (suprascrise):

1 → indică faptul că cererile care sunt complet suprascrise de alte cereri care au sosit după

ele sunt incluse în acestea;

2 → adaugă la cele de mai sus și posibilitatea ca cererile sosite după suprascriere să fie adăugate, dacă sunt disponibile datele necesare;

Sequential stream diff maximum – specifică distanța maximă dintre două cereri secvențiale dintr-un șir secvențial;

Scheduling timeout scheme – acest parametru specifică schema de întârzieri a unei cozi multiple:

0 → indică faptul că cererile nu sunt mutate din coada de bază într-o coadă cu prioritate mai

mare datorită întârzierilor excesive din cauza parcurgerii cozilor;

1 → cererile din coada de bază, care au depășit un anume timp de așteptare în coadă sunt

mutate în una din cele două cozi de mare prioritate (coada pentru cererile foarte vechi sau cea

pentru cererile eu prioritate ridicată);

2 → cererile din coada de bază care au așteptat cel puțin jumătate din timpul limită sunt

mutate în coada pentru cereri vechi, căpătând o prioritate puțin mai mare.

4.6 Parametrii pentru organizarea datelor în matrici de discuri

Parametrii utilizați pentru organizarea datelor în matrici de discuri sunt configurați în blocurile „logorg” și sunt următorii:

Addresing mode – specifică cum este adresată organizarea logică a datelor. Array indică faptul că există un singur dispozitiv logic pentru întreaga organizarea logică. Parts indică faptul că dispozitivele de stocare back-end sunt tratate ca și cum nu au nici o organizație logică, și cererile sunt re-mapate în mod corespunzător.

Distribution scheme – aceasta arată schema de distribuție de date (care este necesară la sistemul de redundanță). Asis indică faptul că nu apare nicio re-mapare. Striped indică faptul că datele sunt împărțite la dispozitivele din matrice. Random indică faptul că un disc aleator este selectat pentru fiecare cerere. Ideal indică faptul că o distribuție ideală de date ar trebui să fie simulata prin alocarea cererilor de disc folosind algoritmul round robin.

Redundancy scheme – aceasta precizează sistemul de redundanță. Noredun (RAID0) indică faptul că nu exista nici o redundanță. Shadowed (RAID1) indică faptul că una sau mai multe copii ale fiecărui disc de date sunt menținute. Parity_disk indică faptul că un singur disc de paritate este menținut pentru a proteja datele din celelalte discuri ale matricii. Parity_rotated (RAID5) indică faptul că blocurile de paritate sunt împărțite de-a lungul tuturor discurilor din matrice.

Devices – lista cu numele dispozitivelor care vor face parte din organizație.

Stripe unit – specifică dimensiunea unității de întrețesere.

Synch writes for safety – specifică dacă scrierile celor N+1 discuri ale unei matrici vor fi procesate în același timp cu cererile de citire-modificare-scriere (RMW) pentru calculul parității. Dacă este adevărat (1), atunci toate citirile valorilor vechi trebuie sa fie completate înainte sa fie emise scrierile. Dacă este fals (0), fiecare scriere back-end este emisă imediat după completarea citirilor corespunzatoare.

Number of copies – specifică numărul de exemplare ale fiecărui disc de date dacă organizarea logică prezintă redundanța Shadowed. Altfel , parametrul este ignorat.

Copy choice on read – specifică politica folosită pentru selectarea unui disc dintr-un set de discuri Shadowed care se va ocupa de cererile de citire sosite din moment ce oricare dintre ele poate face acest lucru. Acest parametru este ignorat dacă redundanța Shadowed nu este selectată.

RMW vs. reconstruct – precizează punctul de întrerupere în selectarea actualizărilor de paritate ca raport al discurilor de date care sunt actualizate. În cazul în care numărul de discuri actualizate de cererile de scriere este mai mic decât punctul de întrerupere, atunci blocul "vechi" de date, blocul "vechi" de paritate, și blocul "nou" de date sunt folosite pentru a calcula paritatea nouă.

Parity stripe unit – specifică dimensiunea unității de întrețesere pentru sistemul de redundanță Parity_Rotated. Nu este obligatoriu să fie egală cu „stripe unit” , dar una trebuie să fie multiplul celeilalte.

Parity rotation type – specifică cum este rotită paritatea de-a lungul discurilor din matrice:

1 →simetric la stânga,

2 → asimetric la stânga,

3 → asimetric la dreapta,

4 → simetric la dreapta. [8]-Andrei Marcu

CAPITOLUL 5

Simulatorul de arhitecturi RAID – DiskSim. Rezultate experimentale

5.1 Simulatorul pentru arhitecturi RAID

Pentru partea practică a acestei lucrări a fost realizată o aplicație JAVA ce incorporează simulatorul DiskSim 4.0 și un generator de workload-uri. Aplicația poate fi rulată atât pe sistemele de operare Windows cât și pe platformele Linux.

Aplicația realizează comunicarea între utilizator, generatorul de workload-uri și simulatorul DiskSim prin intermediul unei interfețe grafice ce va fi prezentată în subcapitolul 5.1.1. Generatorul de workload-uri crează fișiere speciale ce sunt necesare simulatorului DiskSim pentru generarea rezultatelor.

5.1.1 Interfața principală

Interfața principală a aplicației este împărțită în 2 tab-uri. Primul tab este dedicat generatorului de workload-uri și tipului de disc folosit. Cele două tipuri de disk ce pot fi folosite sunt: Seagate Cheetah 146GB 15000RPM și Quantum Tornado 9GB 10000RPM.

Figura ,……………

Generatorul de workload-uri generează workload-uri în folder-ul “simulationfiles/workloads” sub numele “trace…..”. Programul nu poate selecta în vederea realizării unei simulări un workload din cele anterioare, ci îl folosește doar pe cel în curs. O dată ce s-a generat un workload nou, cel vechi nu mai poate fi folosit. În partea de jos a ecranului este afișat workload-ul curent.

Generatorul de Workload-uri permite configurarea anumitor parametrii ai workload-ului cum ar fi:

Numărul de cereri

Timpul între cereri

Tipul de distribuție a cererilor

Fig. 5.2

Interfața aplicației – Generatorul de Workload-uri

Parametrii configurabili ai distribuției gaussiene sunt media și varianța acesteia. Atunci când se selectează și o a doua gaussiană, se utilizează un cursor de poziționare pe disk. Cea de-a doua gaussiană va avea aceași varianță ca și prima.

Cele două gaussiene alternează în funcție de valoarea unei variabile aleatoare cu distribuție uniformă ce ia valori între [0, 1]. Dacă variabila este mai mică decât 0.5 atunci se alege prima gaussiană, altfel se alege cea de-a doua. Parametrii de control ai distribuției uniforme sunt capetele intervalului în care se vor poziționa cererile pe disk.

În partea superioară a căsuței există un câmp dedicat, scris cu font roșu, ce specifică intervalul în care cererile pe disk pot fi poziționate Unitatea de măsură este blocul de date și are 512 bytes. !!!! nu merge pe noua interfata facuta

Pentru a genera workload-ul final este nevoie ca butonul “Generează Workload” din josul căsuței să fie apăsat. Fișierul cu workload-uri va conține cereri generate sub un format standard.

Formatul fișierului de workload

Prima coloană reprezintă timpul la care sosește cererea față de momentul 0.

A 2-a coloană reprezintă numărul organizării de disk-uri care se simulează

A 3-a coloană indică numărul blocului accesat

A 4-a coloană indică numărul de blocuri accesate în acea etapă

Ultima coloană reprezintă tipul cererii. 1 pentru citire și 0 pentru scriere

Cadrul din mijloc este destinat selecției arhitecturii de discuri ce dorim a fi folosită și rulării efective a simulării. Putem alege între un Disk Simplu sau o matrice RAID 0, RAID 1, RAID 5 sau RAID 10. Dacă vom alege o matrice RAID 0 aceasta vine cu un număr presetat de 4 discuri. RAID 1 este presetat pe 2 discuri, RAID 5 are 5 discuri, iar RAID 10 are 4 discuri.

A doua setare ce poate fi făcută este legată de algoritmul de planificare a accesului la disc. Pornind de la cei 27 de algoritmi implementați în DiskSim se poate alege dintr-o listă simplificată ce include algoritmii FCFS, ELEVATOR LBN, CYCLE LBN, SSTF LBN sau SPTF OPT.

După ce am ales parametrii simulării putem face simularea apăsând butonul Start Simulare. În acest fel, folosind workload-ul generat se va genera o simulare, iar rezultatele vor fi afișate în consolă. La ieșire simulatorul va returna o serie de paramtrii. Aceșia sunt: “IOdriver Response time average” , “IOdriver Requests per second” , “IOdriver Number of reads” , “IOdriver Number of writes” , “IOdriver Request size average”. Aceste date vor fi salvate in fisierul “Rezultate.out” din folder-ul “simulationfiles”.

Cel de-al treilea bloc poate fi folosit independent de celelalte două și realizează o simulare automată. La apăsarea butonului “Generare simulari automate” se va deschide o fereastră în care putem seta parametrii simulărilor. Simularea va fi realizată, pe rând, pentru fiecare tip de arhitectură și pentru fiecare tip de algoritm de planificare a accesului la disc. Simularea va fi efectuată doar asupra tipului de disc selectat. !!! Noua interfata nu mai deschide fereastra asta !!! poate o face popa ca sa nu sterg din licenta. !!!

Fig. 5.4

Setările generatorului de Workload

Simularea automată va crea o serie de fișiere workload și apoi va apela simulatorul pentru fiecare tip de arhitectură și pentru fiecare tip de algoritm disponibil pe fiecare workload. Workload-urile reprezintă o înșiruire de cereri de citire sau scriere aplicate prin intermediul a două gaussiene. Una dintre ele este fixă, iar cealaltă se deplasează de la un capăt la celălalt al intervalului disk-ului folosit. Aceasta se deplasează cu un pas setat de parametrul “Rezoluție parcurgere”. La apăsarea butonului “Start Simulare” se vor crea toate workload-urile și apoi se va începe seria de simulări pe aceste workload-uri. Rezultatele sunt afișate în consolă sub forma unor perechi de numere (poziția blocului mediei celei de-a doua gaussiene și timpul mediu de răspuns la cereri măsurat în milisecunde). Aceste date se salvează și în fișierele “RezultateAuto…” din folder-ul “simulationfiles”.

5.1.2 Configurarea simulatorului

Integrarea simulatorului în programul JAVA, precum și realizarea legăturilor dintre simulator și interfața JAVA s-au realizat prin folosirea comenzii de consolă a simulatorului cu înlocuirea după caz a parametrilor:

Exemplu:

disksim raid1.1.parv trace1sim1.out ascii trace1.trace 0 "disc*" "scheduler: scheduling policy" 2

Pentru execuția simularilor, DiskSim folosește o serie de parametri specifici cum ar fi:

Fișierul de parametri – ce are extensia .parv

Fișierul cu specificațiile disk-ului – ce are extensia .diskspecs

Fișierul de workload – ce are extensia .trace

Alte fișiere de descriere a informațiilor (opționale sau nu)

Pentru că DiskSim nu permite creare de discuri noi în interiorul său s-a folosit utilitarul Dixtrac, special creat pentru a extrage parametrii de pe un disk existent. Utilitarul extrage toate trăsăturile unui disk real și le transformă în fișiere necesare simulatorului DiskSim. Acest program nu poate extrage date decât de pe un disk cu magistrală SCSI, pe o platformă Linux. După extragerea caracteristicilor discului, toate datele memorate pe acesta vor fi pierdute.

Comanda pentru apelarea utilitarului Dixtrac este “ ./new_disk.pl” și trebuie dată având setat ca director curent, folder-ul “/dixtrac”.

Pentru mai multe detalii privind implementarea simulatorului în program, se poate consulta codul sursă al aplicație, ce a fost anexat la sfârșitul lucrării în Anexa XXX ?!?!?.

5.2 Rezultate experimentale

Pentru realizarea simulărilor s-a folosit o configurație ce specifică următorii parametrii:

Număr de cereri – 3.000

Timp între cereri – 0.5

Medie – 100 × 106

Varianță – 2 × 106

Rezoluție parcurgere – 5 × 106

Folosind generatorul de workload-uri au fost realizate 50 de fișiere workload. Au fost generate atât sarcini doar de scriere sau citire cât și sarcini mixte, ce din punct de vedere matematic simulează evoluția unui proces de rebuilding.

Workload-urile ce simulează doar scrieri au coloana responsabilă formată strict din valoarea 0, iar cele responsabile doar cu citiri au coloana respectivă formată doar din valoarea 1.

Am constatat experimental că din punct de vedere matematic pentru a simula o procedură de rebuilding este nevoie ca (în cazul unei matrice RAID 5, spre exemplu, cu 5 discuri – în care cade un disc) după o secvență de 4 citiri consecutive (care simulează citirea de pe discurile rămase “în picioare”) să avem o scriere, care să simuleze reconstrucția datelor abia culese pe discul ce este reconstruit. Desigur aceste procese pot fi intercalate cu citiri și / sau scrieri aleatoare ce simulează faptul că celelalte discuri sunt folosite în timp ce se reconstruiește discul căzut.

Pentru a simula cât mai multe situații s-a folosit funcția de simulare automată a simulatorului. Au fost generate simulări care să includă toate combinațiile posibile între algoritmi de planificare a accesului la disc, tipul de matrice RAID folosită și cele 50 de workload-uri.

Rezultatele se găsesc pe CD-ul atașat lucrării, precum și în anexă. Folosind aceste date s-au construit graficele de performanță ale structurilor RAID. Aceste grafice au fost realizate folosind mediul de dezvoltare Microsoft Excel.

În continuare vor fi prezentate o serie de grafice care ilustrează rezultatele experimentelor realizate asupra matricelor RAID. Acestea demonstrează anumite caracteristici prezentate în partea teoretică a lucrării. Aceste grafice sunt grupate în funcție de:

Latența rotațională – acest parametru reprezintă timpul necesar suprafeței (unde se face operația de citire sau scriere) să se rotească până la poziția capului de citire

Timpul de acces – acest parametru reprezintă intervalul de timp dintre momentul în care discul primește o cerere și momentul soluționării cererii respective împreună cu returnarea rezultatului.

Timpul de căutare – acest parametru reprezintă unul din cele 3 tipuri de întârzieri associate cu citirea sau scrierea datelor pe un disc. Pentru a putea scrie sau citi (de) pe un disc, capul de citire trebuie mutat fizic la poziția cu pricina. Acest procedeu se numește “căutare”. Distanța variază în funcție de cât de departe de destinație este capul de citire și de timpul necesar fiecărei instrucțiuni de citire sau scriere. Se va considera timpul mediu.

Timpul de transfer – acest parametru reprezintă timpul necesar unui disc pentru a transfera un singur bloc de 512bytes pe magistrală.

Rezultatele generate de simulator au fost prelucrate cu ajutorul unui manager de text, realizat în limbaj JAVA. Acesta analizează fișierele .outv și extrage parametrii necesari aranjându-i într-un tabel pentru a se putea construe graficul de performanță.

Pentru algoritmul de acces FCFS s-au obținut următoarele rezultate:

Din punct de vedere al Latenței Rotaționale

Fig. 5.7

Rotational Latency Average

Observând graficul de mai sus, unde sunt suprapuse cele 4 rezultate grafice aferente sistemelor RAID 0, RAID 1, RAID 5 și RAID 10 putem observa faptul că latențele rotaționale ale acestora nu variază în limite foarte mari, dar sunt totuși diferite. RAID 10 înregistrează minime ale latenței rotaționale ce se situează undeva în jurul valorii de 1.88ms, în timp ce valorile cele mai mari sunt atinse de către RAID 1 (2ms).

Din punct de vedere al timpului de căutare:

Fig. 5.8a

Disk Seek Time Average

Timpii de căutare pe disk variază în funcție de sistemul RAID folosit conform prezentărilor teoretice realizate în capitolele anterioare. Se poate observa că timpul cel mai scurt de acces la disk este deținut de RAID 0 și RAID 5, în timp ce timpul cel mai lent îi aparține lui RAID 1.

Din punct de vedere al Timpului Mediu de Răspuns

Fig. 5.8b

Response Time Average

Din punct de vedere al timpului mediu de acces la disk

Fig. 5.9

Disk Access Time Average

Timpul de acces la disk variază proporțional între cele 4 tipuri de RAID analizate. Conform datelor prezentate teoretic, se observă că RAID 0 și RAID 5 împart locul întâi la capitolul timp de accesare al discului.

Pe mijlocul graficului, undeva aproape de mijlocul numărului de blocuri de date se poate observa un minim al timpului măsurat. Acesta se produce (în toate graficele) datorită faptului că seek-ul este făcut aleator, fiind favorizate pistele de pe mijlocul discului. Căutarea pe diverse piste pleacă din orice pistă și ajunge pe orice pistă.

Pentru a evidenția rezultatele diferite obținute în cazul folosirii unui alt algoritm de acces la disk în continuare sunt prezentate aceleași analize asupra discului, dar folosind algoritmul SSTF LBN.

Pentru algoritmul de acces la disc SSTF LBN s-au obținut rezultatele:

Fig. 5.10a

Rotational Latency Average

Pentru algoritmul de acces la disc SSTF LBN s-au obținut rezultatele:

Fig. 5.10b

Disk Seek Time Average

Pentru algoritmul de acces la disc SSTF LBN s-au obținut rezultatele:

Fig. 5.11a

Response Time Average

Fig. 5.11b

Disk Acces Time Average

5.3 Concluzii

Rularea simulărilor prezentate anterior ne-au permis conturarea următoarelor concluzii:

În primul rând, aruncând o privire de ansamblu asupra graficelor observăm faptul că RAID 5 oferă performanțe mai bune decât RAID 0, RAID 1 și RAID 1+0 la aproape toate capitolele. În cazul Latenței Rotaționale se observă rezultate ce diferă nesemnificativ, iar în cazul Timpului de Căutare se observă performanțe similare între RAID 5 și RAID 0.

Performanțele unui RAID privind timpii de căutare nu pot fi îmbunătățite prin legarea HDD-urilor într-un RAID anume. Singura metodă viabilă de imbunătățire a timpului de căutare rămâne procurarea unui harddisk ce oferă nativ un timp de căutare mai bun, cum ar fi spre exemplu SSD-urile. (Solid State Disk) Nici o matrice mecanică nu va reuși să atingă performanțele obținute de un SSD. Performanța citirilor în RAID 5 crește cu numărul de discuri, deoarece cu cât sunt mai multe discuri, cu atât sunt mai multe capete de citire/scriere iar matricile RAID 5 au capacitatea de a citi simultan de pe toate discurile.

Este adevărat totuși că un RAID poate îmbunătăți ușor timpul de căutare atunci când are un număr mare de “queue depths” (QD). Un utilizator de rând poate atinge un QD de 3-10 cereri, în timp ce un server are peste 20. Totodată RAID mărește de asemenea și latența întrucât procesarea cererilor necesită un overhead mai mare. Pentru home useri, în esență, timpul de căutare va scădea în urma folosirii unui sistem RAID față de un singur disk mai rapid.

O alternativă ar putea consta în folosirea unei curse scurte (short – stroking). În acest fel se forțează harddiskul să folosească doar partea exterioară a platanului, unde viteza liniară este mai mare.

Din punct de vedere al timpului mediu de acces la disk putem afirma că se evidențiază din nou RAID 5 și RAID 0. Aceste două tipuri de RAID prezintă timpi de acces similari, cu o constantă fixă adăugată în funcție de latența dorită a rotației platanului.

Timpul mediu de acces reprezintă suma dintre timpul mediu de căutare (variabil) și latența rotațională medie (stabilită de viteza platanului).

Timpul de căutare este bazat pe durata medie necesară deplasării între piste aleatoare, iar latența rotațională reprezintă timpul necesar platanului pentru a efectua o jumătate de rotație. O jumătate de rotație pentru că acesta este timpul mediu necesar pentru a aduce bit-ul căutat sub capul de citire.

RAID 0 stochează sau citește o parte din informații de pe un harddrive și cealaltă parte de pe celălalt harddrive beneficiind de viteză sporită tocmai datorită faptului că are nevoie să acceseze doar jumătate din date per harddrive fizic. Performanțele vor crește o dată cu numărul de harddisk-uri implicate, întrucât secțiunile de date sunt distribuite egal pe ambele HDD-uri ale matricei, oferind fiecărui HDD mai puțin de făcut pentru fiecare bucată de dată în parte.

Un alt factor ce influențează destul de mult performanțele discurilor este algoritmul de acces la disc ales. Primul set de rezultate este bazat pe algoritmul FCFS care din cauza simplității sale furnizează rezultatele cele mai slabe. Al doilea set de rezultate este obținut folosind algoritmul SSTF LBN observându-se rezultate mai bune.

CAPITOLUL 6

Simulatorul de arhitecturi RAID – Iometer. Rezultate experimentale

6.1 Prezentarea mediului de simulare Iometer

Pentru a putea observa comportarea sistemelor RAID într-un mediu real de funcționare am efectuat o testare a unei matrice RAID 5 cu discuri conectate printr-un controller Smart Array 5300, folosind mediul de simulare Iometer.

Iometer este un tool de măsurare și caracterizare a subsistemelor I/O ce fac parte din sisteme single sau cluster ce poate măsura performanțele sub un load controlat. Acesta este în același timp un generator de workload-uri și un tool de măsurare, putând genera operații de I/O asupra sistemului și să măsoare răspunsul acestuia. Iometer poate fi folosit pentru a emula load-ul de pe un disk sau de pe o rețea sau poate fi folosit pentru a genera load-uri I/O complet sintetice.

Programul poate măsura:

Performanța disk-urilor și a controllerelor de rețea

Lățimea de bandă și capabilitățile de latență ale magistralelor

Performanțele magistralelor share-uite

Performanțele hard-drive-urilor la nivel de sistem

6.2 Interfața programului

Iometer este compus din două programe separate: Iometer și Dynamo.

Iometer este programul de control. Folosind interfața grafică a Iometer-ului se poate configura workload-ul, se pot seta parametrii de operare și se pot începe sau se pot opri testele. Iometer îi transmite programului Dynamo ce să facă, colectează datele și apoi exportează într-un fișier de ieșire rezultatele obținute.

Dynamo este generatorul de workload-uri. Acesta nu are o interfață grafică. La comanda programului Iometer acesta efectuează operații I/O și înregistrează informațiile cu privire la performanțe, apoi le returnează programului Iometer. Generatorul de workload-uri Dynamo este de tip multithread și fiecare copie a acestuia, ce poate fi rulată în paralel, poate simula workload-ul mai multor programe. Fiecare copie a programului Dynamo care lucrează poartă numele de manager, iar fiecare thread al fiecărei copii Dynamo este numită generic worker.

Interfața grafică a programului Iometer este prezentată în figura următoare

Fig. 6.2

Iometer – Interfața grafică

Opțiunile de configurare ale acestui program constă în stabilirea numărului de sectoare, stabilirea sectorului de unde va începe testarea, stabilirea modului de scriere sau citire asupra discului și împărțirea acestor sarcini pe thread-uri.

Rezultatele obținute sunt afișate parțial în interfața grafică și exportate în totalitate într-un fișier excel.

6.3 Rezultate experimentale

În urma testelor efectuate s-a obținut un set de rezultate ce sunt anexate lucrării, pe CD, în formatul original, excel.

S-au efectuat mai multe teste asupra matricei RAID 5, începând cu generarea de workload-uri pe un singur thread asupra configurației aflate în regim normal de funcționare și asupra configurației ce ulterior a fost introdusă în Recovery Mode. S-a continuat prin testarea configurației folosind 4 thread-uri și respectiv 1 thread atunci când aceasta efectuează Rebuilding în condiții de prio Normal, Low și High (pentru Rebuilding).

Primul test efectuat s-a realizat folosind un singur worker. Ca și specificații de acces la disk s-a folosit opțiunea globală “All-in-One” care înglobează un mix realizat automat între toate opțiunile posibile oferite de Iometer. Al 2-lea test efectuat s-a realizat introducând diskul în Recovery Mode.

Fig. 6.3a

Analiza 1 – RAID 5 – 1 worker – Algoritm All-in-One

Fig. 6.3b

Analiza 2 – RAID 5 – 1 worker – Recovery Mode

Pentru a nu distruge un disk am simulat producerea unui eveniment nefericit asupra acestuia prin scoatera manuală, reconectarea la un alt sistem și ștergerea manuală a datelor de pe acesta. Ulterior pentru a o induce disk-ul în starea de Rebuilding, acesta a fost introdus la loc în sistemul inițial.

Rezultatele obținute pot fi observate în figura de mai jos.

Fig. 6.4

Analiza 2 – RAID 5 – 1 worker – Recovery Mode

Se observă o încărcare mult mai puternică a procesorului (7.15% față de 2.43%) precum și o scădere a vitezei medii totale. (10.85MBPS atunci când diskul este în Recovery Mode față de 11.87MBPS atunci când diskul funcționează în parametrii normali). Numărul de operații de I/O pe secundă este și el în scădere, de la 320.16 în condiții normale de funcționare până la 284.63 atunci când diskul se află în Recovery Mode. Timpul maxim de răspuns la operațiile de I/O scade de la 101.9353 ms în cazul funcționării în parametrii normali la 96.9961ms în cazul funcționării în regim de Recovery Mode. De asemenea atunci când disk-ul intră în Recovery Mode, timpul de răspuns mediu la operațiile I/O crește de la 3.1183ms la 3.5083ms.

Testarea performanțelor în condiții de rebuilding a produs următoarele rezultate:

Fig. 6.5a

RAID 5 în procesul de rebuild

Fig. 6.5b

Rezultate experimentale – RAID 5 – Rebuilding

Față de rezultatele obținute în urma rulării în parametrii normali, se observă din nou o creștere semenificativă la nivelul de încărcare al procesorului. (6.02% în timpul rebuilding-ului față de 2.43% în condiții normale de rulare)

Întrucât în timpul efectuării operației de rebuild sistemul este mai încărcat se observă o creștere considerabilă a timpului mediu de răspuns la operațiile de I/O. Creșterea are loc de la 3.1183ms pentru sistemul folosit în parametrii normali de funcționare până la 8.6032ms pentru folosirea acestuia în timpul operației de rebuild.

Totodată se observă că traficul făcut scade de la 11.87 MBPS în condiții normale de utilizare până la 4.32 MBPS atunci când are loc procesul de rebuild.

De asemenea numărul total de IOps scade de la 320.16 în condiții normale de utilizare la 116.02 în timpul realizării rebuilding-ului.

Paralelizând cererile furnizate de către generatorul de workload-uri dar păstrând prioritatea acordată rebuilding-ului observăm câteva schimbări semnificative. Aceste schimbări sunt extrem de importante pentru performanța procesului de rebuilding, evident existând anumite soluții de rebuilding mai bune decât altele.

Paralelizarea workloadurilor aduce un plus la nivelul tuturor parametrilor măsurați. Numărul total de IOps crește de la 116.02 (pentru 1 worker) la 346.38 (pentru 4workeri), viteza de transfer crește de la 4.32 MBPS la 12.83 MBPS, timpul mediu de răspuns crește și el din nefericire de la 8.6032ms la 11.4990 însă nu este o creștere la fel de semnificativă ca cea a tuturor parametrilor “pozitivi”. Toate aceste creșteri semnificative ale performanțelor vin cu un cost ce se observă la nivelul procesorului. Încărcarea acestuia crește considerent de la 6.02% până la 16.05%.

Fig. 6.6

Rezultate experimentale – RAID 5 – Rebuilding – 4 workeri

Următorul test a fost făcut folosind aceiași parametrii (1 worker) și în timpul aceluiași proces de rebuilding dar prioritatea procesului de reconstrucție a fost trecută pe „Low”.

Se observă cum load-ul procesorului scade de la 16.05% la 3.98% dar o dată cu acesta și restul indicilor de performanță raportează valori mai scăzute. Acest rezultat se datorează faptului că oferind o prioritate scăzută procesului de rebuilding, controllerul se poate concentra pe operațiile efectuate asupra discurilor rămase în stare de funcționare.

Această metodă este preferată dacă se urmărește folosirea discurilor rămase, dar nu este indicată atunci când scopul principal este de a realiza un rebuilding cât mai rapid.

Numărul total de IOps scade de la 346.38 (în cazul priorității normale și 4 workeri) până la 277.56 (în cazul priorității scăzute cu 1 worker). Rezultatul obținut este totuși mai bun decât cel rezultat pentru prioritatea normală cu 1 worker și anume 116.02 IOps. Totodată viteza de transfer scade de la 12.83 MBPS (în cazul priorității normale și 4 workeri) până la 10.65 MBPS. Scorul obținut este oricum mai bun decât cel pentru prioritatea normală cu 1 worker și anume 4.32 MBPS.

La nivelul timpilor de răspuns medii respectiv maximi la operațiile I/O se observă o coborâre a valorilor de la 11.4990ms la 3.5992ms și respectiv de la 204.7565ms la 169.8599ms. Aceste rezultate sunt bune dacă ne dorim lucrul cu discurile rămase, dar nu se apropie de calitatea celor rezultate în cazul procesului de rebuilding realizat cu prioritate normală și anume 8.6032ms pentru timpul mediu de răspuns și respectiv 97.8493ms pentru timpul maxim de răspuns.

Fig.6.7

Rezultate experimentale – RAID 5 – Rebuilding – 1 worker – Low Prio

Ultimul experiment realizat folosește o aceași configurație asupra căreia s-a realizat rebuilding cu prioritate ridicată (High). Workloadul a fost realizat de către un singur worker.

Se observă cum întrucât toate resursele sunt canalizate pentrea realizarea cât mai rapidă a rebuildingului, numărul de IOps scade dramatic de la 277.56 (pentru Low Priority) și 346.38 (pentru Normal Priority) până la 81.53.

De asemenea transferul de date se face la viteze mult mai mici. Vechile performanțe atinse (10.65 MBPS – pentru Low Prio și respectiv 4.32 MBPS – pentru Normal Prio ; ambele cu 1 worker) depășesc cei 3.10 MBPS posibili în cazul High Prio cu 1 worker.

Încărcarea procesorului crește până la 5.30%.

Fig. 6.8

Rezultate experimentale – RAID 5 – Rebuilding – 1 worker – High Prio