Universitatea Politehnica București. Facultatea de Electronică, Telecomunicații și Tehnologia Informației

Transcription

1 Universitatea Politehnica București Facultatea de Electronică, Telecomunicații și Tehnologia Informației Proiect Sisteme de Operare Avansate Mașini Virtuale Procesul de virtualizare și accesul la resurse Student: Iosif Cătălin IISC București 2013

2 Cuprins Indroducere... 3 Necesitatea virtualizării... 5 Virtualizarea... 8 Abordări pentru virtualizare Accesul la hardware a mașinilor virtuale Decizii constructive pentru SHI Concluzii Bibliografie... 23

3 Indroducere În ultima perioada interesul fața de soluții pentru virtualizare în industria IT a crescut exponential datorita multitudinii de beneficii oferite, precum: o utilizare mai bună a resurselor, și ușurința managementului sistemelor implicate. Experimentarea cu, și utilizarea virtualizării a devenit foarte populară în numeroase instituții de învățământ, cercetare, și chiar întreprinderi comerciale. În cadrul acestei lucrări se studiază potențialele avantaje ale soluțiilor de virtualizare în reproducerea și analiza scenariilor a căror implementare este dificilă pe infrastructura oferită de mașinile fizice disponibile. Conceptul de mașină virtuală a fost dezvoltat prima dată de catre compania IBM în anii 60 pentru a permite acces interactiv simultan la o unitate de tip mainframe. În această situație, fiecare mașină virtuală este o replică a mașinii fizice, și astfel, fiecarui utilizator i se creeează iluzia lucrului direct pe unitatea fizică. Mașinile virtuale oferă deasemenea numeroase beneficii, precum izolarea, partajarea resurselor, și abilitatea de a rula diferite sisteme de operare, în variante diferite, și configurații unice pe aceleași resurse fizice. 3 Mașini virtuale noțiuni generale Definitia: O mașină virtuală reprezintă o simulare a unei mașini, fie reală, fie abstractă ce se diferențiază de mașina pe care se implementează simularea respectivă. În fucnție de destinație o masină virtuală poate fi bazată pe anumite specificații ipotetice, sau poate avea la bază arhitectura unui calculator real. O definiție mai specifică ar fi că o mașină virtuală este o implementare software a unei mașini (calculator) ce execută programe sau instrucțiuni asemănător unei mașini fizice. Mașinile virtuale pot fi clasificate în urmatoarele două mari categorii [1]: 1. Masini virtuale tip sistem acestea permit executia uni sistem de operare complet. În acest caz se emulează o arhitectură deja existentă, oferind o platformă pentru rularea aplicațiilor unde hadware-ul necesar nu este prezent (cum ar fi rularea unui soft depașit), sau posibilitatea de a rula mai multe instanțe de mașini virtuale, fapt ce poate conduce la utilizarea mai bună a resurselor (virtualizare hardware), fie din punct de veredere al costului, sau energetic. 2. Masinile virtuale tip proces (sau de tip limbaj) sunt facute pentru a rula un singur program. Acest mașini sunt construite pentru a permite rularea instrucțiunilor din unul sau mai multe limbaje de programare, oferind portabilitate și flexibilitate respectivului limbaj. Probabil cea mai cunoscută mașină virtuală de acesti tip este mașina virtuală Java (Java Virtual Machine),

4 ce permite executarea instrucțiunilor java pe numeroase configurații, pornind de la toate tipurile de calculatoare, și ajungând pâna la bancomate, imprimante, dispozitive portabile, etc. Mașinile virtuale tip sistem permit existența mediilor cu sisteme de operare multiple, pe același calculator, izoalate unul de celalalt. Datorită gradului de izolare, administrarea sistemelor de operare este foarte usoară, resursele pot fi întreținute și accesate ușor, și se poate reveni ușor de la un eveniment nociv. În plus pe o MV se poate executa un set de instrucțiuni incompatibil cu hardware-ul folosit. Din păcate, o mașina virtuală este mai putin eficientă decât o mașina reala, cand resursele hardware sunt accesate direct. Datorită acestui fapt, când rulează mai multe MV concomitent pe același hardware, fiecare din MV este predispusă la o anume instabilitate a perfomanței. Implementarea cu mai multe MV virtuale, fiecare cu sistemul de operare propriu (guest OS) este folosită frecvent în cazul serverelor, deoarece împățirea proceselor pe mașini individuale conduce la un grad foarte ridicat de stabilitate și fiabilitate. Dorința de a rula mai multe sisteme de operare pe același hardware a reprezentat motivația inițială pentru dezvoltarea MV. Sistemul de operare oaspete nu trebuie să fie compatibil cu hardware-ul folosit. Utilizarea MV a devenit tot mai populară în cazul sistemelor de tip embedded, pentru a permite rularea sistemului de operare propriu în același timp cu un sistem de operare tip Windows sau Linux. O altă utilizare des întâlnită a MV tip sistem este izolarea unui sistem de operare ce este considerat instabil, sau se află încă în dezvoltare. Mașinile virtuale tip proces, sunt create în momentul cand este inițializat procesul, și distruse cand acesta se incheie. Scopul acestora este de a furniza posibilitatea programării independente de platformă, ce abstractizează detaliile referitoare la hardware. Astfel un program scris într-un anumit limbaj de programare poate funcționa corespunzător pe orice configurație hardware. O mașină virtuală tip proces oferă abstractizare la nivel înalt, spre deosebire de MV tip sistem. MV tip proces sunt implementate utilizând un interpretor de limbaj. Cum am precizat puțin mai inainte, acest tip de mașină virtuală a devenit foarte popular datorită limbajului de programare Java. Din cauza implementării pe mașină virtuală, limbajul Java, la început avea performanțe scazute în comparație cu alte limbaje populare, precum C++. Între timp, performanțele limbajului Java au crescut, ajungând, prin utilizarea compilării JIT (Just In Time) foarte aproape de performațele limbajului C. 4

5 Necesitatea virtualizării Sistemele de calcul sunt compuse din următoarele componente: hardware, sistemul de operare și suita de aplicații. Structura este prezentă în figura 1. Se poate observa cum sistemul de operare are privilegii speciale în cea ce privește managementul și protecția resurselor hardware partajate (memoria, dispozitivele I/O), iar aplicațiile apelează aceste resuse indirect, facând apeluri la sistemul de operare. fig.1 Structura unui sistem clasic [1] După cum se poate observa există numeroase avantaje pentru arhitectura convenționala cu o interfața bine definită. Lucrul la dezvoltarea unui asemenea sistem de operare se poate face oarecum decuplat. Acesta se dezvoltă pe numeroase componente, uneori cu diferențe de timp de ani intre ele. Dezvoltatorii de aplicații nu sunt obligați sa fie la curent cu orice schimbarea ce apare la nivelul sistemului de operare. Software-ul poate funcționa fara probleme pe diferite platforme hardware ce implementează același set de instruțiuni, fie în aceeași generație hardware, sau nu. Datorită numeroaselor avantaje, acest model arhitectural a fost folosit pentru decenii, și s- au efectuate multe investiții pentru a-l susține. Din păcate, această abordare conduce și la destule dezavantaje, ce au devenit din ce în ce mai pregnante odată cu creșterea complexității sistemelor de calcul, și largirea spectrului de arhitecturi hardware utilizate. Limitările apar datorită faptului că cele trei componente funcționează corespunzător în anumite combinații. Se pot observa în figura 2 câteva din arhitecturile populare pentru PC-uri. fig. 2 Arhitecturi clasice [1] 5

6 Componentele acestor sisteme de calcul nu sunt interoperabile. Chiar dacă hardware-ul poate fi asemănător, programele și sistemule de operare dezvoltate pentru anumite seturi de instrucțiuni nu vor putea rula pe arhitecturi ce folosesc alt set de instrucțiuni. Nu putem rula aplicații Macintosh pe un procesor Intel, și nici invers. Sistemul Linux implementează același set de instrucțiuni ca și Windows, dar se folosesc apeluri la sistem diferite, si astfel, nici în acest caz nu există interoperabilitate (fig 3). fig.3 Incompatibilitați între sisteme [1] În sistemele de calcul izolate, lipsa compatibilității software poate fi un lucru deranjant, dar în cazul mediilor precum rețele de dimensiuni mari, aceasta problemă devine extrem de serioasă. Există și numeroase avantaje pentru această abordare, dar în cazul în care un anumit software necesar este restricționat la a funcționa numai pe anumite noduri ale rețelei, se reduce considerabil transparența și gradul de flexibilitate. O altă problema este faptul că de obicei, majoritatea inovațiilor ce apar în domeniul software sunt limitate de necesitate de a fi compatibile cu interfețe mai vechi. De exemplu, un software nou poate sa fie limitat de un set de instrucțiuni mai vechi. Chiar si cand setul de instrucțiuni este extins pentru a permite funcționalitați noi, software-ul trebuie sa rămână compatibil cu facilitați mai vechi ale setul de instrucțiuni, ce pot încărca sistemul. O a treia problemă ar fi dificultatea optimizării. Interfețele permit dezvoltarea separată a componentelor, fapt ce se poate dovedi relativ problematic. Dezvoltatorii diferitelor componente, în general comunică destul de rar, și astfel, multe programe ajung să nu fie optimizate pentru hardware-ul pe care vor rula. Deasemenea, procesul de compilare rămâne în urma, și astfel programele ajung sa fie compilate pentru o generație mai veche de procesor. În final, pe un sistem de calcul tradițional, un sistem de operare este corelat cu platforma hardware, și toate aplicațiile co-există sub protecția și management-ul unui singur sistem de operare. Acest fapt constrange toți utilizatorii calculatorului la acel SO, și deschide multe posibilitați de a abuza anumite carențe din securitatea sistemului. Acest fapt este problematic în situația în care un numar mai mare de utilizatori au nevoie de acces securizat la un sistem hardware de dimensiuni mari, precum un server. 6

7 Toate problemele enumerate mai sus pot fi rezolvate prin implementarea unui strat software ce furnizează un mediu de tip mașină virtuală pentru execuția software-ului. În figura 4 se poate observa cazul în care o mașină virtuală este inserată intre stratul hardware, și soft-ul convențional. În acet caz mașina virtuală traduce setul de instrucțiuni astfel încât stratul software vede alt set de instrucțiuni. Se va observa mai departe în lucrare că virtualizarea setului de instrucțiuni este doar una din multitudinea de opțiuni disponibile. Procesul de virtualizare implică: fig.4 Implementarea mașinii virtuale [1] 1) maparea resurselor virtuale (regiștri, memorie, dispozitive hardware) 2) utilizarea setului de instrucțiuni a mașinii reale pentru efectuata instrucțiunile date de către mașina virtuală. Terminologia consacrata denumește platforma hardware ca gazdă (host) și software-ul ce lucrează in mediul virtual ca oaspete (guest). Software-ul utilizat pentru virtualizare se va numi de obicei VMM (Virtual Machine Monitor) Software-ul de virtualizare poate fi aplicat în mai multe moduri. O primă variantă, prezentată în figura 5a, emularea adaugă un grad considerabil de flexibilitate, datorită faptului ca permite portabilitate intre diferite platforme. Software-ul de virtualizare poate îmbunătați emularea folosind optimizare (luarea în calcul a detaliilor specifice unei implementări) în conjuncție cu aceasta, sau poate implementa doar tehnici de optimizare (figura 5b). O altă tehnică ce se poate folosi este replicarea, în cazul căreia o platforma hardware este facută să apară ca mai multe platforme independente, fiecare capabila de a rula sistem de operare și / sau aplicații proprii. (figura 5c). Aceste tehnici pot fi folosite în diferite combinații la diferite nivele. (figura 5d). 7

8 a) b) c) d) fig.5 Opțiuni pentru virtualizare [1] Virtualizarea În linii mari, virtualizarea reprezintă simularea sistemelor software, și/sau a hardwareului pe care rulează acestea. Mediul simulat va fi desigur, o mașină virtuală. Există mai multe forme de virtualizare, ce se deosebesc în primul rând prin arhitectura sistemului de calcul, sau a procesului emulat, și prin componentele virtualizate (platforme, siseme de operare, dispozitive I/O, etc). În general, starea unui sistem informatic este definită de condiții în nivelul software (memorie, regiștri, si instrucțiuni ce cauzează schimbari), și de condiții la nivelul hardware ( RAM, bistabile, etc). În orice moment există o mapare între cele două nivele. Schimbările la nivelul software afectează starea nivelului hardware si vice-versa. Una dintre diferențele practice intre mașina reală și mașina virtuală este faptul că mașina reală este dezvoltată ținând cont de o anumită arhitectură a setului de instrucțiuni (ISA). În cazul mașinii virtuale maparea starii fizice nu mai este eficentă în orice situație deoarece pot exista numeroase diferențe arhitecturale (numărul de regiștri, spațiul de adresă, etc). Eficiența virtualizării depinde de tipul MV implementate. Se va prezenta în continuare, procesul de virtualizare (maparea între oaspete și gazdă) pentru mașinile virtuale de tip proces, și pentru cele de tip sistem. Ne vom concentra pe trei mari aspecte ale procesului de virtualizare: maparea stării mașinii, maparea instrucțiunilor (emularea) și materializarea exactă a stărilor în situația in care apar întreruperi. Virtualizarea în cazul MV de tip proces Una dintre cele mai accesibile MV de tip proces este mediul multiprogramat, deoarece aproape toate sistemele de calcul au fost proiectate să permită și să utilizeze tehnica multiprogramarii. Starea procesului este mapată printr-o relație 1:1 cu starea mașinii reale. Instrucțiunile sunt executate în mod nativ, neavand nevoie de emulare, sau alte procedee. 8

9 Datorită implementării hardware se poate salva cu ușurința starea când apar întreruperi. Tabelul 1 sumarizează aspectele virtualizării pentru mașinile virtuale de tip proces. Tabelul 1 [1] 1. Stare Instrucțiuni Precizie Regiștri Memorie Multiprogramare Mapată 1:1 Mapată 1:1 native datorită hardware-ului Traducere dinamică Mapați către regiștrii gazdei ca fiind disponibili Mapată la memoria disponibilă emulate datorită software-ului MV Optimizare dinamică Mapată 1:1 Mapată 1:1 transmise la nivel de bloc datorită software-ului MV MV HLL (high level language) Mapați către regiștrii gazdei ca fiind disponibili Mapată la memoria disponibilă emulate / compilate just in time datorită software-ului MV MV de tip proces pot oferi posibilitatea traducerii dinamice, pentru compatibilitate între platforme. Pentru acestea, starea oaspete ese mapata la starea gazdei ca fiind disponibilă. În particular, toți regiștrii mașinei oaspete pot fi mapați la regiștrii gazdei, cât timp sunt destui regiștrii disponibili. Pentru cazul în care această condiție nu se respectă, ex: PowerPC (32 de regiștri de uz general) virtualizat pe arhitectura x86 (doar 8regiștrii de uz general), o parte din acești regiștrii vor fi mapați la spațiul de memorie al gazdei. La fel se întâmplă și în cazul memoriei, daca spațiul adresabil al oaspetelui este mai mare decât cel al gazdei, atunci MV va trebui să gestioneze aceasta problemă (o parte din starea mașinii va fi salvată pe disc). Deoarece setul de instrucțiuni al gazdei diferă de cel al oaspetelui, va trebui utilizată emularea. Tipul emulării va fi ales în funcție de performanțele cerute, și se va face prin inerpretare și / sau traducere. În cazul optimizării dinamice, arhitectura oaspetelui este identică cu cea a gazdei, și astfel, similar multiprogramarii, starea regiștrilor și a memoriei poate fi mapată 1:1. Uneori, datorită faptului că optimizarea poate crește gradul de utilizare al regiștrilor, este posibil ca unii dintre aceștia sa fie stocați temporar în memorie. Chiar dacă seturile de instrucțiuni sunt identice pentru gazdă și oaspete, o mare parte din tehnicile folosite pentru sunt folosite și pentru 9

10 optimizarea dinamică. Mai specific, blocurile de cod sunt scanate și optimizate, stocandu-se in memoria cache pentru reutilizare. În final, MV de limbaj (HLL) se aseamană în multe moduri mașinilor virtuale cu traducere dinamică. O diferență importantă între acestea este faptul că mașinile virtuale HLL sunt proiectate pentru a fi cât mai portabile. În consecință, deși problemele vor fi similare celor din cazul traducerii dinamice, rezolvarile sunt de obicei mult mai simple. De exemplu, multe MV HLL folosesc o stivă pentru a specifica operanzii instrucțiunilor către regiștri, și ca urmare nu apar probleme în cazul mapării regiștrilor, și regiștrii ce rămân disponibili pot fi folosiți pentru diverse optimizări. Memoria în modelul HLL este de regula mult mai abstractă decât în cazul unei arhitecturi bazate pe set de instrucțiouni convențional, și astfel maparea stării este simplificată. Referitor la maparea instrucțiunilor, MV HLL sunt gândite în așa fel pentru a permite ușurința interpretării. Drept urmare, acest aspect este aorecum standardizat, acest tip de mașina virtuală fiind proiectată pentru a fi compilată (tradusă) la nivelul procedural. De obicei se folosește compilarea JIT (just in time). Virtualizarea în cazul mașinilor Virtuale de tip sistem. Pentru MV de tip sistem, codul ce provine de la utilizator, cât și cel ce provine de la sistem rulează intr-un mediu virtual, și tehnicile de virtualizare depind de tipul codului rulat. În consecința, când se face trecerea în revistă a aspectelor importante ale virtualizării, se face distincție intre cele două tipuri de cod. Tabelul 2 sumarizeaza elementele importante privind virtualizarea MV tip sistem. Tabelul 2 [1] 2. Stare Instrucțiuni Precizie Regiștri Memorie folosind Mașini sistem clasica user Mapată 1:1 Mapată 1:1 native hardware-ul sistem În memorie Mapată 1:1 native (câteva emulate) hardware-ul Mașini tip sistem intreg user Mapați la regiștrii gazdei Mapată la memoria disponibilă transmise la nivel de bloc software-ul MV sistem În memorie Mapată la memoria disponibilă emulate software-ul MV Mașini coproiectate user Mapată 1:1 Mapată 1:1 traduse la nivel de bloc hardware sau software 10

11 sistem Mapată 1:1 Mapată 1:1 traduse la nivel de bloc Hardware sau software Mașinile virtuale ce implementează sisteme clasice, rulează software oaspete ce este dezvoltat pentru hardware ce folosește aceași arhitectură a setului de instrucțiuni ca și platforma gazdă, ca atare, când se execută cod de la utilizator, memoria și regiștrii pot fi mapați 1:1, și în majoritatea implementărilor, instrucțiunile pot fi executate nativ. Există și multe excepții, în funcție de tipul instrucțiunilor executate. Codul apelat de către sistem trebuie gestionat special, deoarece, pe mașina virtuală, acesta nu poate rula cu privilegii. Doar software-ul de tip VMM (virtual machine monitor) poate rula in modul sistem, deoarece acesta gestionează utilizarea și partajarea resurselor intre mașinile virtuale. Ca urmare, regiștrii de sistem sunt stocați în memorie și gestionați de VMM. Regiștrii reali ai sistemului sunt utilizați de VMM pentru gestionarea resurselor hardware. MV tip sistem întreg au multe dintre caracteristicele MV ce folosesc traducere dinamică. Diferența majoră este faptul ca și instrucțiunile de la utilizator, cât și cele de la sistem trebuie emulate. Astfel, interfața ISA este mult mai importantă decât cea ABI. Și registrele și memoria oaspetelui sunt mapate ca fiind disponibile. Orice regiștrii în plus sunt mapați la memorie. Regiștrii de sistem, folosiți pentru managementul resurselor hardware sunt mapate la memorie și sunt menținute de VMM. Pentru acest tip de mașini virtuale, software-ul VMM rulează și în modul de utilizator și se bazează pe sistemul de operare gazdă pentru gestionarea memoriei. Mașinile virtuale co-proiectate reprezintă un caz foarte interesant deoarece hardware-ul utilizat este proiectat specific pentru a implementa setul de instrucțiuni al oaspetelui. Ca urmare, cel mai probabil, vor fi destui regiștrii și memorie disponibilă pentru mapare 1:1. Instrucțiunile sunt emulate prin traducere binară dinamică și sunt optimizate pentru pentru performanțe ridicate. Daorită faptului ca infrastructura hardware este proiectată special pentru această situație, se poate reface ușor orice stare a mașinii. În cazul acestui tip de mașini virtuale, există de obicei un singur sistem de operare oaspete, ce poate opera în modul de utilizator sau de sistem. Au fost descrise mai multe tipuri de mașini virtuale, cu diferite destinații și moduri de imlementare. În figura 6 se află o schemă ce sumarizează diferitele tipuri de mașini virtuale discutate în această lucrare. În primul rând, mașinile virtuale sunt împarțite în două mari categorii MV tip proces, și MV tip sistem. Primul tip oferă o interfață ABI (Application Binary Interface), în timp ce al doilea tip ofera un set de instrucțiuni complet (interfața ISA). Mai există o împarțire pe categorii în funcție de faptul ca sistemul oaspete are același set de instrucțiuni ca și sistemul gazdă, sau nu. În partea stângă a figurii se află MV tip proces, desigur imparțite pe categorii în funcție de setul de instrucțiuni folosit. Sistemele multiprogramate, unde virtualizarea reprezintă o parte naturală a procesului de multiprogramare, se regasesc pe majoritatea sistemelor de calcul. Mai observăm și optimizatorii dinamici, ce transforma setul de instrucțiuni al sistemului oaspete în procesul de optimizare, după care execută instrucțiunile în mod nativ. MV de tip translator dinamic și HLL ofera posibilitatea de emulare. 11 În partea dreaptă a figurii se află MV tip sistem. Acestea pot fi de tip clasic, sau găzduite,

12 unde scopul final reprezintă rularea mai multor instanțe în medii puternic izolate. Pentru MV de tip sistem întreg, performanța se află pe plan secundar, prioritatea fiind funcționalitatea și fiabilitatea sistemului. MV co-proiectate se află în contrast cu cazul menționat înainte, performanța aflandu-se pe primul plan. fig.6 Clasificarea mașinilor virtuale Abordări pentru virtualizare Există trei abordari pentru virtualizare, ce au in comun necesitatea existenței unui program de tip hypervisor ce alocă resursele uzuale precum memoria și accesul la procesor. În toate cazurile scopul este de a păcăli sistemul de operare ca acesta conduce toata partea hardware. Abordarea 1: Virtualizarea completă Această metodă face ca software-ul hypervisor să încapsuleze operațiile pe care sistemul de operare le execută pentru a citi sau modifica starea sistemului, sau pentru a rula operații de I/O [4]. După ce acestea sunt încapsulate, hypervisorul emulează aceste operații folosind software, și returnează coduri consistente cu cele returnate de mașina fizică (fig 7). 12

13 Avantajul acestei abordări este faptul că funcționează transparent pentru sistemul oaspete, și astfel orice software vechi, sau care nu a fost proiectat pentru a fi virtualizat (MSDOS, Windows 3.1) poate fi instalat ca sistem de operare oaspete. Problema este ca acestă metodă reduce semnificativ performanțele în mediile ce folosesc intensiv operațiile I/O. Software-ul de emulare creează un strat de traducere și emulare, prin care toate operațiile trebuie să treacă. În funcție de sarcina de lucru, pot aparea întarzieri destul de mari. fig. 7 Virtualizarea completă Abordarea 2: Paravirtualizarea Paravirtualizarea, uneori cunoscută și ca virtualizarea parțială elimină multe din operațiile de încapsulare și emulare asociate cu implementarea software a virtualizării prin implicarea sistemul de operare oaspete în procesul de virtualizare. Putem spune ca sistemul de operare guest se lasă pacalit [4]. Abordarea aceasta poate fi observată în figura 8. Paravirtualizarea are potențialul de a fi o metodă mai rapidă decât celelalte. În schimb, aceasta necesită utilizarea unui sistem de operare oaspete modificat, astfel încat să coopereze la creeare iluziei. fig.8 Para-virtualizarea 13

14 Abordarea 3: Virtualizarea asistata hardware Această metodă se bazează pe extensii hardware pentru arhitectura de sistem x86 pentru a elimina o mare parte din operațiile efectuate de hypervisor pentru încapsulare și emularea operațiilor I/O [4]. Abordarea aceasta poate fi observată în figura 9. Din fericire, această tehnologie devine din ce în ce mai populară, și multe companii au inclus-o in ciclul de producție. Această abordare este în continuă dezvoltare, existând multe posibilitați de optimizare. Problema care apare este costul și timpul de producție mai ridicat fața de celelalte abordări. fig. 9 Virtualizarea asistată Accesul la hardware a mașinilor virtuale Acest aspect se va studia pentru monitorul de mașină virtuala de tip Xen (fig. 10), care permitea rularea mai multor soluții virtualizate concurente pe sistemele de tipul x86. În continuare se va prezenta arhitectura SHI (Safe Hardware Interface), ce se bazează pe izolare pentru a permite partajarea driverelor între instanțe izolate a sistemelor de operare, în timp ce protejează fiecare sistem de operare individual și întregul sistem de un eventual eșec al driverului. Arhitectura Xen este destinată două tipuri de medii informaționale [6]: 1. Centre de date, unde o mare parte a mașinilor fizice pot fi împarțite între diferite unități administrative 2. Utilități de calcul la nivel global, precum inițiativa Xenoservers, unde diferiți clienți pot folosi resurse distribuite pentru a-și furniza propriile servicii. Indiferent de situație, arhitectura Xen trebuie să ofere execuția fiabila a multiple instanțe de sisteme de operare, izolare hardware, și managementul resurselor fizice din spate. Se va analiza dependența sistemelor virtualizate de anumite componente hardware, și tratarea depențelor prin izolarea codului pentru drivere, dar în același timp păstrând abilitatea de a partaja o compentă fizică între diversele sisteme de operare. Driverele reprezintă o sursă comună de 14

15 bug-uri și probleme de sistem, și partajarea driverelor dau o anvergură și mai mare acestei probleme. Fig. 10 Arhitectura Xen Diversitatea actuală a soluțiilor hardware a condus la o arhitectură în care executam driverele fară a le modifica în domenii izolate pentru acestea, sau mai bine zis, mașini virtuale specifice unui driver. Interfața SHI a fost dezvoltată pentru a obține o partajare robustă a driverelor. Orice problema poate fi conținută în domeniul particular al driverului, prin limitarea accesului acestuia la resursele dorite. Astfel, folosind acest model, driverele se pot defecta, sau pot fi restartate intenționat fară a afecta major sistemele de operare în lucru. Totodată, datorită acestei interfețe unificate, partajarea driverelor între diferitele sisteme de operare devine foarte ușoară. Este necesară doar o implementare de nivel mic al driverului pentru a permite diferite sisteme para-virtualizate. Eforturile pentru evoluția în această direcție s-au împarțit în două categorii mari: dezvoltarea izolarii sigure și îmbunătațirea interfețelor dintre drivere și soluțiile software și sistemele de operare cu care interacționează Conceptul de izolarea sigură Până în prezent au fost studiate numeroase modalități de a încorpora în mod fiabil cod strain într-un sistem de operare deja existent. Implementarea studiată folosește un strat de 15

16 vitualizare pentru a obține izolarea între drivere și sistemele de operare ce le forosesc. În figura 11 se poate observa modelul acestei arhitecturi. Figura 11 Arhitectura SHI [6] Punctul de interes este tratarea problemei arhitecturale la nivel înalt și nu asupra efectuarii de modificări particulare pentru diferite tipuri de sisteme de operare. Interfețele Obiectivul dezvoltării de interfețe mai rigide între dispozitive și sistemul de operare nu este deloc nouă. Au existat initiative comerciale precum UDI (Uniform Driver Interface) care încercau sa adreseze fix această chestiune. Spre deosebire de arhitectura SHI, driverele compatibile UDI nu sunt izolate, acestea rulând în același domeniu ca si sistemul de operare. Din păcate aceasta abordare nu trateaza diversele defecțiuni posibile ale driverelor. Arhitectura SHI se mai deosebește de UDI prin faptul ca în loc sa ofere o interfața agregata pentru toate driverele utilizate, se folosește o interfața idealizată, cu o destinație mult mai îngustă. Arhitecturile noi pentru sistemele de operare mereu au avut probleme de tratat cand venea vorba de drivere. Aceasta problema apare datorită diversitații de dispozitive disponibile pe piața. Sistemele cu microkernel au investigat posibilitatea construirii unor interfețe 16

17 particularizate pentru dispozitivele Linux. Arhitectura SHI se bazează pe principii de funcționare asemanătoare cu cele din cazul microkernelului, dar are în vederea dezvoltarea unei interfețe pentru o multitudine de sisteme de operare, și nu doar modificarea unui set de drivere pentru un anumit SO. Design-ul la nivel înalt După cum se observă în figura 10, arhitectura se compune din 3 părți mari. Mai întâi avem mai multe spații pentru operații I/O, în care driverele își desfașoara activitatea separat de sistem. Această alegere rezultă în mai multă fiabilitate prin limitarea daunelor cauzate de eșecurile driverelor.în al doilea rand se de definește un set de interfețe unificate clasificate. Astfel, toate dispozitivele de același tip vor folosi aceeași versiune a interfeței. Acest fapt permite un nivel amre de portabilitate, evitând necesitatea implementării aceluiaș tip de funcționalitate din nou pentru diferite instanțe virtualizate. Și nu in ultimul rând, se folosește un manager pentru dispozitive, simplificând operații precum configurarea sistemului, si diagnosticul, urmat de tratarea problemelor. Obținerea izolării Pentru a obține nivelul de izolare propus, trebuie respectate următoarele cerințe: - operațiile în memorie trebuie executate în domenii separate -procesorul trebuie sa folosească planificare pentru a evita încarcarea excesivă -accesul la setul de instrucțiuni trebuie sa se facă privilegiat -regiștrii I/O trebuie sa restricționeze accesul la unele zone -accesul DMA la memoria gazdei trebuie sa fie restricționat. -în general, dispozitivele trebuie sa restricționeze accesul la alte dispozitive arbitrare. Implementarea discutată folosește un VMM pentru a obține izolarea între drivere și codul sistemului de operare. Prin monitorizarea și controlul asupra utilizării de putere de procesare și memorie a fiecărui driver, VMM-uloferă același nivel de izolare ca în cazul unui singur sistem de operare cu mai multe procese. De exemplu, daca un driver încearcă sa scrie la o locașie de memorie greșită, înafara spațiului alocat, daunele cauzate sunt conținute în mașina virtuală ce rulează respectivul driver. Izolarea completa a dispozitivelor este destul de problematică în cazul arhitecturii x86, ce nu oferă facilități pentru limitarea accesului la dispozitive specifice, sau la memoria de sistem. Spațiul I/O reprezintă cheia rezolvării acestei probleme. Acestă reprezintă un domeniu de protecție caruia îi pot fi asignate resurse fizice pentru un anumit driver precum memorie, 17

18 regiștrii, întreruperi, etc. Rolul acestui spațiu este de a face ca un set de căi de acces între un driver și dispozitivele fizice sa reprezinte o entitate particulară în sistem. O realizare completă a spațiilor I/O necesită și un set de facilități incluse in hardware-ul disponibil. Protejarea împotriva accesului direct la memorie eronat nu se poate face fara facilități hardware. Totuși s epoate ajunge la un grad foarte mare de izolare și fara modificari hard. Interfețe unificate Interfața unificată studiată se bazează pe interfețele oferite de VMM-ul Xen. Trasaturile esențiale necesare pentru comunicarea eficientă sunt: evitarea copiilor și utilizarea unui sistem flexibil si asincron pentru notificări. Pentru aceasta se utilizează canale de dispozitiv, ce fac legătura între interfețele unificate exportate de driverele dispozitivelor și sistemul de operare ce le folosește. Desi se consideră ca interfețele unificate oferă un set mare de beneficii, trebuie recunoscut faptul ca modelarea eficientă a fiecărui dispozitiv este imposibilă. Există numeroase situații cand trebuie luate țn considerare dispozitive mai noi, sau aplicații cu destinație specială. În aceste situații dispozitivele trebuie expuse accesului direct. Driverele pentru video și sunet sunt tratate în acest fel. Este important de menționat faptul că organizațiile mari continuă să se îndrepte către virtualizare, pentru a utiliza mai eficient resursele hardware ale unui server. Interfețele unificate sunt foarte avantajoase datorită faptului că permit partajarea ușoară a resurselor. Un exemplu al interfețelor unificate poate fi observat în figura 10, prezentată anterior. În acest exemplu, două ssieme de operare și trei dispozitive rulează pe o singură mașină fizică. Primele două drivere din stânga utilizează o interfața unificată ce înglobează codul deja existent al driverelor. Utilizarea acestei interfețe permite programarea temporala (scheduling) a fiecărui dispozitiv în parte, partajare între sisteme de operare și restartarea făra mari probleme în cazul unei defecțiuni. Elemente de control și gestiune Pe parcursul evoluției PC-ului, controlul și gestiunea dispozitivelor a fost o zonă ușor neglijată. Lipsa de interfețe standarddizate pentru platforme a condus la implementarea unei ocnfigurații unice pentru fiecare sistem de operare și dispozitiv. Un dezavantaj foarte mare al acestei abordări este faptul ca persoanele ce se ocupă de administrarea sistemelor au nevoie de pregătire pentru fiecare tip de arhitectură folosită. Traziția de la platforma PC la server conduce la o importanța și mai mare a ușurinței gestiunii. Multitudinea de unelte de configurare existente în prezent nu este deloc eficientă în cazul sitemelor distribuite. Uneletele cu interfața de tip consolă se potrivesc unui număr mic de stații de lucru,d ar au dificultăți mari cand o modificare trebuie aplicată unui set mare de mașini. 18

19 Unul din aspectele cele mai importante ale acestei arhitecturi este reprezentat de managerul pentru dispozitive. Acesta este o extensie a BIOS-ului sistemului ce oferă un set de interfețe pentru gestionarea tuturor dispozitivelor. Decizii constructive pentru SHI Spațiile I/O Interfața SHI creează izolarea între driverele dispozitivelor prin restricționarea resurselor hardware pe care le pot accesa. Vom denumi acest mediu restricționat: spațiul I/O. Pentru realizarea acestei implementări se folosește restricționarea accesului la regiștrii I/O și la liniile de întrerupere. Unde este posibil, pentru a evita împotriva defectării dispozitivelor prin izolarea interacțiunilor între dispozitiv si sistemul gazdă. Spațiul de configurare al sistemului se virtualizează, pentru a permite controller-ului sistemului acces la resursele driverelor, în același timp cu restricționarea capacității driverelor de a detecta resursele la care nu au acces. Regiștrii I/O Arhitectura Xen asigură izolarea memoriei între domenii prin verificarea validitații schimbărilor spațiului de adresă. Accesul la un dispozitiv mapat la memorie se face prin permiterea accesului la o pagină non-ram ce conține regiștrii mapați la memorie ai dispozitivului. Protecția la nivel de pagină este suficientă pentru a asigurarea izolării. Intreruperile Atunci când se face apel la linia de întrerupere a unui dispozitiv, în VMM-ul Xen se execută o subrutină, spre deosebire de cazul clasic, în care se intra imediat în domeniul ce controla dispozitivul. În acest mod, arhitectura Xen menține controlul asupra sistemului, prin programarea temporală a execuției serviciului de întreruperi (ISR interrupt service routine) pentru fiecare domeniu în parte. Gestiunea întreruperilor în Xen permite trimiterea confirmarea din timp către controllerul de întreruperi (care de asemenea este gestionat de Xen). Astfel, va exista destul timp pentru pregătirea spațiului necesar execuției. VMM-ul Xen trimite notificări fiecarei domeniu asupra evenimentelor asincrone ce au loc, printre care și întreruperile hardware folosind un mecanism numit canal pentru evenimente. Fiecare domeniu poate avea alocate 1024 de canale pentru evenimente, fiecare conținând o pereche de fanioane într-o pagină de memorie partajată între Xen și domeniul respectiv. Un fanion este folosit pentru marcarea evenimentelor în curs de desfășurare, iar celălalt pentru mascare. 19

20 Interacțiunile între dispozitive și sistemul gazdă. Pe lângă problemele cauzate de drivere, trebuie tratate și cele cauzate de hardware în sine. Există două tipuri de interacțiuni ce trebuie luate în considerare: validarea liniilor de întrerupere și accesul la spațiul de memorie al gazdei. Pentru întreruperi, nu apar în general probleme, datorită faptului că sunt foarte puține linii de întrerupere partajate. Majoritatea dispozitivelor au propria linie de întrerupere, și toate întreruperile sunt gestionate în Xen. Astfel, cea mai mare problemă în cazul dispozitivelor este accesul la locații arbitrare de memorie în sistemul gazdă. De exemplu, chiar dacă un driver nu poate folosi procesorul pentru a scrie într-o anumită pagină a sistemului, acestă poate programa dispozitivul hardware controlat sa facă acces DMA către pagină. Din păcate, pe hardware=ul actual, nu există o soluție foarte fiabilă pentru tratarea acestei probleme. Se vizează pentru viitor, când chipset-urile vor avea dispoztive IOMMU (Input Output Memory Management Unit), programarea acestor dispozitive de către VMM-ul Xen, pentru a raspunde diverselor cereri de întrerupere ce vin de la domenii. Configurarea hardware-ului VMM-ul Xen restricționează accesul fiecărui domeniu la spațiul de configurație, astfel încât poate citi din sau scrie doar în regiștrii dispozitivului deținut. Astfel, se elimină interferențele între configurații, și fiecare domeniu are informații doar asupra dispozitivului cu care lucrează. Domeniilor nu li se permite acces direct la spațiul de configurare, ci sunt forțate sa folosească o interfața virtualizată oferită de Xen. Canalele pentru dispozitive Deși interfața SHI poate fi configurată pentru a permite unui sistem de opera sa iși ruleze propriile drivere, se pierd multe posibilități de optimizare. Abordarea prezentată preferă sa ruleze fiecare driver intr-un domeniu izolat al driverului (IDD isolated driver domain), ce limitează daunele cauzate de defecțiuni. Sistemele de operare oaspete accesează dispozitivele prin legatura între IDD și canalul de date. Canalul este o legatură de comunicare punct la punct prin care fiecare pare poate trimite mesaje în mod asincron către cealaltă. Canalele sunt realizate când se introduce un IDD sistemului de operare oaspete și viceversa. VMM-ul Xen nu are o noțiune concretă de canal de control sau canal de dispozitiv. Mesajele sunt transmise prin intermediul paginilor de memorie partajate alocate de SO dar în același timp mapate în spațiul de adresă al IDD-ului sau a controller-ului de sistem. 20

21 Partajarea memoriei Mecanismul de partajare oferit de Xen diferă de cel tradițonal prin faptul că fiecare pagină de memorie este deținută de cel mult un domeniu la un moment dat, și prin asistența VMM-ului Xen sau a controller-ului de sistem, poate recăpăta maparea de la domenii cu funcționare defectuoasă. Pentru a adauga mapări străine spațiului sau de adresă, un domeniu, trebuie sa prezinte o referința valida VMM-ului Xen. O referința este compusă din identitatea domeniului ce oferă permisiunea, și un index pentru tabela de permisiuni a unui domeniu. Tuplul va fi de forma (grant, D, P, R, U) și va permite domeniului D sa mapeze pagina P la spațiul său de adresă. Fanionul R permite accesul doar la citire, iar U este scris de Xen pentru a indic dacă în mod curent domeniul D mapează pagina P. VMM-ul Xen asociază un contor de utilizări fiecarei intrări din tabelă. Când se mapează pagini străine, contorul crește. Referința de grant nu poate fi realocată sau refolosită de către domeniul ce oferă permisiunea, până domeniul străin nu distruge toate mapările cu referința catre acesta. Partajarea dispozitivelor Datorită multitudinii de sisteme ce rulează în paralel, problema partajării dispozitivelor devine foarte importantă. Pentru arhitectura discutată, grupurile de cereri concurente către dispozitive sunt tratate folosind tehnici de time-sharing. Se folosesc felii de tip proporționale ce vor trata cererile într-o maniera circulară, fara a acorda o prioritate mai mare unui proces. După această etapă se folosește si un scheduler pentru disc. Astfel se obține un echilibru între o viteză de transfer bună și timpi de acces acceptabili. O tehnică asemănătoare este folosită pentru transmisia pe rețea. Scheduler-ul este bazat pe credite, acesta alocand x bytes unui dispozitiv la fiecare y microsecunde. Alegerea pachetelo pentru transmisie se face tot în mod circular, dintre procesele ce au suficient credit. Concluzii În incheiere, putem spune ca de-alungul ultimei perioade au fost dezvoltate numeroase implementări ale mașinilor virtuale, și desigur, diverse modele experimentale. MV au evoluat în mai multe direcții în funcție de scopul final al acestora. Putem fi siguri ca acestă tehnologie se va dezvolta rapid în continuare, mai ales în prezența a unor asemenea catalizatori precum creșterea popularității aplicațiilor server-based și a cloud computing-ului. De asemenea, necesitatea utilizării mai multor soluții software, fie recente, sau depașite din anumite puncte de vedere, împreună cu aspectele menționate anterior, va asigura longevitatea soluțiilor de virtualizare. 21

22 Deasemenea, după cum am putut observa din studiul interfeței SHI, tehnologiile noi ce permit utilizarea resurselor fizice într-un mod cât mai eficient pentru soluțiile de virtualizare se dezvoltă intr-un ritm accelerat, urmând ca în curând să fie disponibile pe scară largă. 22

23 Bibliografie [1]. J.E. Smith & R. Nair An overview of Virtual Machines [2]. R.P. Goldberg Architecture of Virtual Machines. [3]. M. Eisen Introduction to Virtualization [4]. C. Scheffy Virtualization for dummies [5]. [6]. K. Fraser, S. Hand - Safe Hadware Access with the Xen Virtual Machine Monitor 23