Laborator Virtual In Cloud

LABORATOR VIRTUAL IN CLOUD

CUPRINS

Introducere

Capitolul 1

1. Cloud Computing

1.1 Ce este cloud computing

1.2 Caracteristicile cloud computing

1.3 Modele de servicii cloud

1.4 Modele de deployment

Capitolul 2

2. Platforme Cloud Computing

2.1 Amazon cloud computing

2.2 Google cloud computing

2.3 Microsoft Windows Azure și serviciile online

2.4 Platforme software Open-source pentru private cloud

Capitolul 3

3. Specificațiile Tehnice ale Sistemelor Virtualizate

3.1 Virtualizarea

3.2 Layere virtualizare

3.3 Virtual machine monitors

3.4 Mașinile virtuale

3.5 Performanta și izolarea de securitate

3.6 Virtualizarea completa și Paravirtualizarea

3.7 Suportul hardware pentru virtualizare

Capitolul 4

4. Platforma Cloud Openstack

4.1 Arhitectura OpenStack

4.2 Serviciile Openstack

4.2.1 OpenStack Compute

4.2.2 OpenStack Storage

4.2.3 OpenStack Networking

4.2.4 OpenStack dashboard

4.2.5 OpenStack Identity

4.2.6 OpenStack Image service

4.2.7 OpenStack Telemetry

4.2.8 OpenStack Orchestration

4.2.9 OpenStack Database

4.2.10 OpenStack Data processing

Capitolul 5

5. Crearea unui laborator virtual in OpenStack

5.1 Creare proiect și utilizatori

5.2 Conectare proiect nou

5.3 Definire retea interna

5.4 Creare instante virtuale

5.5 Asociarea IP extern unei instante

5.6 Conectare instanta virtuala

5.7 Terminarea unei instante

Concluzii

Bibliografie

Introducere

Într-un climat economic dinamic așa cum este azi, supraviețuirea unei companii poate depinde de abilitatea de a de adapta rapid și de a se concentra pe activitatea sa de baza. Modelul de business folosit pana mai ieri nu îi mai poate asigura supraviețuirea pe termen lung și obținerea de profit. Pe măsura ce afacerile se adaptează schimbărilor guvernamentale și regulamentelor industriei din care fac parte, sunt evaluate noi parteneriate de afaceri și sunt anticipate noi amenințări, IT-ul trebuie sa ajute afacerea și sa găsească noi modalități de a răspunde provocărilor. În același timp, planurile pentru schimbare trebuie adesea făcute în contextul resurselor limitate din punct de vedere finanțare, oameni și tehnologie.

O soluție este folosirea cloud computing-ului care poate ajuta companiile sa folosească instrumente IT pe care in mod normal nu ar putea sa le implementeze datorita costurilor mari. Cloud Computing este un model de business și economic. In unele cazuri poate înlocui modelul tradițional de Datacenter iar in alte cazuri se poate integra cu infrastructura existenta și sa extindă capacitățile acesteia.

Cloud computing este mai mult decât un serviciu ce rulează într-unul din miile de datacentere. Este un set de abordări care pot ajuta organizațiile ca rapid și eficient sa adauge sau sa scadă resursele folosite aproape in timp real. Spre deosebire de alte abordări, cloud-ul este mult mai aproape de modelul de business decât de tehnologie. Companiile înțeleg foarte clar ca tehnologia este inima modului cum operează și fac business. Conducerea executiva a fost mult timp frustrata de complexitatea de a obține resursele de calcul de care au nevoie și costul efectiv. Într-un sens, cloud computing a început sa devina mainstream datorita faptului ca acea conducere executiva a forțat problema in prim plan și adoptarea cat mai rapida a acestuia.

Capitolul 1

Cloud Computing

1.1 Ce este cloud computing

„Cloud” se poate defini ca un set de echipamente hardware, rețea, stocare, servicii și interfața necesara accesări acesteia pentru a furniza putere de calcul ca un serviciu.

In concepția unui mare producător de soluții software și hardware (IBM), cloud computing (numit adesea simplu „Cloud”) este definit ca un model de prelucrare a datelor și furnizarea la cerere de resurse de procesare, indiferent ca este vorba de aplicații sau de un întreg Datacenter, accesarea acestuia prin internet și plata doar pentru folosirea acestui serviciu.

National Institute of Standards and Technology (NIST) din Statele Unite definește cloud computing ca un model ce oferă accesul convenabil, permanent și la cerere la resurse de procesare partajate (rețele, servere, stocare, aplicații și servicii) care pot fi rapid provizionate și lansate cu un minim de efort atât din partea clientului cat și a interacțiunii acestuia cu cel care oferă serviciile.

Caracteristicile cloud computing

Procesare resurse la cerere – Un consumator poate mari unilateral putere de calcul, cum ar resurse de tip server sau de stocare, după necesități, automat, fără a necesita interacțiunea umana cu fiecare furnizor de servicii.

Acces la rețeaua globala – Capabilități de procesare sunt disponibile în rețea și accesate prin intermediul mecanismelor standard de comunicare pentru a fi accesate de platformele thin sau thick ale clientului (de exemplu, telefoane mobile, tablete, laptop-uri, și stații de lucru).

Gruparea resurselor – resursele de calcul ale furnizorului sunt grupate pentru a deservi mai mulți consumatori folosind un model multi-client, cu diferite resurse fizice și virtuale dinamic alocate și distribuite conform cererii. Există un sentiment de locație independentă în care clientul nu are nici un control sau cunoștințe despre locația exacta a resurselor oferite, dar ar putea să specificați locația la un nivel superior de abstractizare (de exemplu, țara, stat sau Datacenter). Exemple de resurse includ stocare, prelucrare, memorie și lățime de bandă de rețea.

Elasticitate rapida – capabilitățile de procesare pot fi in mod automat sau manual, după caz, alocate unui utilizator și eliberate pentru a fi disponibile altor clienți

Servicii contorizate – sistemele de tip cloud in mod automat controlează și optimizează resursele folosite prin folosirea mecanismelor de măsurare a resurselor folosite oferind resurse corespunzătoare tipului de serviciu folosit (stocare, procesare, lățime de banda și conturi de utilizatori). Resursele pot fi măsurate, controlate și raportate oferind transparenta atât pentru furnizor cat și pentru consumator.

1.3 Modele de servicii cloud

Software as a Service (SaaS) – capabilitatea oferita consumatorului de către furnizor este de a oferi acces la aplicația care rulează pe infrastructura de cloud. Aplicațiile sunt accesibile de pe diverse dispozitive ale clientului printr-o interfața web(serviciul de mail) sau prin intermediul interfeței unui program. Consumatorul nu face managementul și nici nu controlează infrastructura cloud pe care rulează aceste aplicații (rețea, servere, stocare, sistem de operare) sau capabilitățile individuale cu câteva mici excepții referitoare la configurările specifice utilizatorului

Platform as a Service (PaaS) – capabilitatea oferita consumatorului de a rula in cloud aplicații dezvoltate de acesta sau achiziționate de la diverși furnizori, aplicații ce au fost create folosind limbaje de programare, librarii și servicii suportate de furnizorul de cloud. Consumatorul nu controlează și nici nu face managementul resurselor de procesare unde vor rula aceste aplicații și nici sistemul de operare

Infrastructure as a Service (IaaS) – capabilitatea oferita consumatorului este aceea de a aloca putere de procesare, stocare, rețea și alte resurse fundamentale și clientul este capabil sa ruleze orice software conform nevoilor acestuia atât din punct de vedere al aplicațiilor cat și al sistemului de operare. Consumatorul nu controlează și nici nu face managementul resurselor hardware dar controlează in schimb sistemul de operare, spațiul de stocare alocat, aplicațiile ce vor rula și capabilități limitate de modificare a rețelei.

Modele de deployment

Private cloud – infrastructura cloud este folosita exclusiv de o singura organizație și deservește mai multe departamente. Poate fi administrata și deținuta de organizație sau de către un furnizor extern sau poate fi un mixt al acestora

Community cloud – infrastructura cloud este folosita exclusiv de o comunitate specifica de clienți din organizații care au probleme comune (cerințe de securitate, politici de securitate, etc). Poate fi administrata și deținuta de una sau mai multe comunități, de un furnizor extern sau de un mixt al acestora.

Public cloud – infrastructura cloud este oferita publicului larg și poate fi folosita atât de organizații cat și de consumatori. Poate fi deținuta și administrata de către un furnizor, o instituție de învățământ, organizație guvernamentala sau un mixt al acestora.

Hybrid cloud – infrastructura cloud este o combinație a doua sau mai multe infrastructuri cloud distincte (private, community sau public) ce rămân entități unice dar sunt folosite împreuna utilizând tehnologii proprietare ce facilitează portabilitatea datelor

Capitolul 2

Platforme Cloud Computing

In acest capitol vom face o privire de ansamblu a serviciilor cloud de infrastructura oferite de Amazon, Google sau Microsoft. Acești furnizori de cloud oferă una sau mai multe modele de servicii de cloud discutate mai sus: IaaS, PaaS, SaaS. Amazon este pionier in IaaS, Google a dezvoltat mai mult partea de SaaS și PaaS, in timp ce Microsoft sa implicat n PaaS.

Cei trei furnizori oferă servicii de tip Public Cloud și ca și alternativa exista Private Cloud. Platformele open-source cloud computing cum ar fi Eucalyptus, OpenNebula, Nimbus sau OpenStack pot fi folosite pentru dezvoltarea de private cloud. Și alte companii sunt implicate in cloud computing. IBM oferă o platforma cloud computing numita IBM SmartCloud ce include servere, stocare și componente virtualizate pentru construirea infrastructurilor de tip private și hybrid cloud computing. Alți furnizori de cloud computing sunt HP, Oracle.

2.1 Amazon cloud computing

Amazon a introdus o platforma cloud ce a schimbat modul cum am privit resursele de calcul in ultima decada. Prima data au dezvoltat o infrastructura capabila sa susțină afacerile acestuia de comerț electronic prin intermediul căruia vând o varietate de produse de la cărți și CD-uri pana la haine și mâncare. Amazon a descoperit ca infrastructura sa poate fi extinsa și astfel sa ofere o platforma ușor de utilizat pentru publicul larg.

La mijlocul anilor 2000 Amazon introduce Amazon Web Service (AWS), bazat pe modelul IaaS. In acest model furnizorul de cloud oferă o infrastructura formata din servere și capacitate de stocare interconectate printr-o rețea de mare viteza ce suporta ca o serie de servicii sa acceseze aceste resurse.

Amazon a fost primul furnizor de cloud computing. A anunțat pentru prima data in August 2006 o versiune beta a platformei Elastic Computing numita EC2.

Elastic Compute Cloud (EC2) este un serviciu web cu o interfața simpla pentru lansarea de instanțe ale aplicațiilor ce folosesc ca sistem de operare Linux, Microsoft Windows, Solaris, FreeBSD și NetBSD.

O instanța este creata dintr-o mașina predefinita Amazon Machine Image (AMI) semnata digital și păstrata in S3 sau din mașini furnizate de utilizator. Imaginea predefinita include sistemul de operare, librăriile și aplicațiile dorite de utilizator. AMI creează o copie identica a imaginii dar fără informațiile care trebuie sa fie unice cum ar fi hostname, adresa de IP, MAC etc.

Ca și tehnologie EC2 se bazează pe XEN Virtualization. Fiecare mașina virtuala sau instanța ficționează ca un virtual private server. O instanța specifica resursele maxime alocate unei aplicații, interfața pentru acea aplicație și costul pe ora.

Un utilizator poate interacționa cu EC2 folosind un set de instrucțiuni și poate lista imaginile AMI disponibile, porni și opri o instanța, listarea imaginilor sau a instanțelor pornite. Utilizatorul are acces root la mașini. Instanțele pot rula in locații multiple in regiuni diferite și zone de disponibilitate.

EC2 permite importul de imagini din mediul clientului folosind o facilitate numita VM Import. In mod automat poate distribui traficul către aplicațiile din cloud către mai multe instanțe folosind funcția elastic load-balancing.

Simple Storage System (S3) este un serviastic Compute Cloud (EC2) este un serviciu web cu o interfața simpla pentru lansarea de instanțe ale aplicațiilor ce folosesc ca sistem de operare Linux, Microsoft Windows, Solaris, FreeBSD și NetBSD.

O instanța este creata dintr-o mașina predefinita Amazon Machine Image (AMI) semnata digital și păstrata in S3 sau din mașini furnizate de utilizator. Imaginea predefinita include sistemul de operare, librăriile și aplicațiile dorite de utilizator. AMI creează o copie identica a imaginii dar fără informațiile care trebuie sa fie unice cum ar fi hostname, adresa de IP, MAC etc.

Ca și tehnologie EC2 se bazează pe XEN Virtualization. Fiecare mașina virtuala sau instanța ficționează ca un virtual private server. O instanța specifica resursele maxime alocate unei aplicații, interfața pentru acea aplicație și costul pe ora.

Un utilizator poate interacționa cu EC2 folosind un set de instrucțiuni și poate lista imaginile AMI disponibile, porni și opri o instanța, listarea imaginilor sau a instanțelor pornite. Utilizatorul are acces root la mașini. Instanțele pot rula in locații multiple in regiuni diferite și zone de disponibilitate.

EC2 permite importul de imagini din mediul clientului folosind o facilitate numita VM Import. In mod automat poate distribui traficul către aplicațiile din cloud către mai multe instanțe folosind funcția elastic load-balancing.

Simple Storage System (S3) este un serviciu de stocare folosit pentru obiecte de mari dimensiuni și suporta un set minim de funcții (write, read, delete). S3 permite unei aplicații manipuleze un număr nelimitat de obiecte de diferite dimensiuni, de la 1 byte la 5 TB. Un obiect este ținut într-un bucket și este obținut cu ajutorul unei cheie unice. Bucket este menținuta într-o regiune indicata de utilizator.

Figura1: serviciile oferite de către AWS sunt accesibile prin intermediul AWS Managemet Console. Aplicații ce rulează sub o varietate de sisteme de operare pot fi lansate folosind EC2. Instanțele EC2 comunica folosind SQS. Câteva servicii de stocare disponibile sunt S#, Simple DB și EBS. Cu ajutorul Cloud Watch se poate face monitorizarea performantelor. Virtual Private Cloud permite migrarea directa a aplicațiilor paralele.

Sursa: Cloud Computing – Theory and Practice – Dan C. Marinescu

Elastic Block Store (EBS) oferă volume de tip persistent block-level storage pentru a fi utilizate cu Amazon EC2. Un volum este prezentat unei aplicații ca in format raw, neformatat. Dimensiunea unui volum poate fi de la 1 GB la 1 TB. Volumele sunt grupate in zone de disponibilitate și sunt automat menținute copii in diferite zone pentru o înaltă disponibilitate. O instanță EC2 poate avea mai multe volume, dar același volum nu pot fi împărțite la mai multe instanțe.

Simple DB este o baza de date non relaționala ce permite dezvoltatorilor sa stocheze și sa interogheze articole de date prin intermediul cererilor web. Suporta funcția store-and-query specifica numai bazelor de date relaționale. Simple DB creează copii multiple răspândite geografic pentru fiecare articol in parte și suporta aplicații ce necesita performanta ridicata.

Simple Queue Service (SQS) reprezintă o coada de mesaje și este un sistem destinat creării de procese automate. Permite ca mai multe instanțe EC2 sa-și coordoneze activitatea trimițând și primind mesaje SQS. Un computer conectat la internet poate citi mesaje fără a foloși un software instalat sau modificări speciale in firewall.

CloudWatch este un sistem de monitorizare folosit de către dezvoltatori, utilizatori sau administratori pentru a colecta și identifica parametrii importanți pentru optimizarea performantei aplicațiilor și pentru a mari eficienta utilizării resurselor.

Virtual Private Cloud (VPC) oferă o punte intre infrastructura IT existenta a unei organizații și AWS cloud. Infrastructura existenta este conectata cu ajutorul unei rețele private criptate (VPN – virtual private network) la o zona izolata de resurse din AWS.

Auto Scaling exploatează elasticitatea cloud și oferă scalabilitate automata a instanțelor EC2. Serviciul suporta gruparea instanțelor, monitorizarea instanțelor dintr-un grup și definirea de alarme și politici ce permit ca dimensiunea grupului sa fie mărita sau micșorata.

Regions and Availability Zones – Amazon oferă serviciile cloud printr-o rețea de data centre localizata pe câteva continente. In fiecare regiune sunt câteva zone de disponibilitate interconectate cu rețele de mare viteza. Regiunile comunica prin internet și nu au resurse comune. O zona de disponibilitate este constituita dintr-un Datacenter ce conține un număr mare de servere. Un server poate rula mai multe mașini virtuale sau instanțe, pornite de unul sau mai mulți utilizatori. Instanțele pot foloși serviciul de stocare, S3, EBS, și Simple DB și alte servicii oferite de AWS. Interconectare cloud permite ca toate sistemele dintr-o zona de disponibilitate sa comunice cu o alte sisteme din zone aflate in aceeași regiune.

Storage-ul este automat replicat in aceeași regiune. S3 buckets sunt replicate in zona de disponibilitate și in alte zone ale regiunii, pe când EBS sunt replicate doar in aceeași zona. Se recomanda ca aplicațiile critice sa replice informațiile importante in multiple regiuni pentru a permite funcționarea aplicațiilor când serverele dintr-o regiune nu sunt disponibile.

Figura 2: configurația unei zone de disponibilitate ce rulează serviciile AWS

Sursa: Cloud Computing – Theory and Practice – Dan C. Marinescu

Un utilizator poate cere serverele virtuale și stocare localizate într-una din regiuni. Utilizatorul poate cere și ca serverele virtuale sa fi in una din zonele de disponibilitate din regiune. EC2 service permite ca utilizatorul sa interacționeze și sa facă managementul serverelor virtuale.

2.2 Google cloud computing

Eforturile Google se concentrează mai mult pe zona de Software-as-a –Service (SaaS). Se estimează ca la nivelul anului 2012 Google avea 1,8 milioane de servere iar in 2013 aproximativ 2,4 milioane și numărul creste in continuare.

Serviciile Google cum ar fi Gmail, Drive, Calendar, Picasa și Google Groups sunt oferite gratis pentru utilizatorii individuali dar și pentru organizații. Aceste servicii rulează in cloud și pot fi accesate de pe un număr foarte mare de dispozitive. Datele acestor servicii sunt stocate in cloud.

Serviciul Gmail stochează email-urile pe serverele Google și oferă o interfața web pentru accesarea acestora și diverse instrumente pentru migrarea mail-urilor din serverele existente utilizate de clienți. Google Docs este o interfața web pentru crearea de documente text, excel și prezentări. Sunt disponibile funcții cum ar fi tabele, bullet points, fonturi de baza și dimensiunea textului. Permite mail multor utilizatori sa modifice același document și sa vadă istoria schimbărilor. Serviciul permite utilizatorilor sa importe și exporte documente in format Microsoft Office, PDF, text și Open Office.

Google Calendar este un serviciu web based ce oferă funcția de calendar și de programare a evenimentelor. Permite utilizatorilor sa aibă mai multe calendare și sa permită accesul și altor utilizatori la calendarul personal. Se poate sincroniza cu Microsoft Outlook și cu dispozitivele mobile. Picasa este un tool pentru upload, colaborare și editare poze. Oferă spațiu de stocare pentru poze utilizatorilor fără un cost suplimentar.

Google base este un serviciu ce permite utilizatorilor sa încarce date din diferite surse într-un depozit central (repository) care este foarte mare, self-describing, semi-structured, heterogeneous database. Este self-describing pentru ca fiecare articol urmează o schema simpla (tip, nume). Google base nu este un serviciu așa cunoscut pentru publicul larg cum sunt celelalte servicii ale Google și poate fi accesat utilizând anumite interogări de cuvinte cheie pe Google.com

Google Drive este un serviciu online de stocare date și este disponibil din Aprilie 2012. Oferă utilizatorilor 15 GB spațiu și posibilitatea de a cumpăra spațiu adițional, 1,99$/luna pentru 100GB și 9,99$/luna pentru 1TB. Este disponibil pe PC, MacBooks și dispozitive mobile.

2.3 Microsoft Windows Azure și serviciile online

Azure și serviciile online sunt PaaS și SaaS cloud de la Microsoft. Windows Azure este un sistem de operare, SQL Azure este varianta cloud a SQL Server și Azure AppFabric este o colecție de servicii pentru aplicațiile din cloud

Windows Azure are trei componente de baza: compute, care oferă mediul de procesare, storage pentru partea de stocare, și fabric controller, care lansează, administrează și monitorizează aplicații. Nodurile de procesare sunt interconectate folosind conexiuni de mare viteza.

Figura 3: componentele Windows Azure

Sursa: Cloud Computing – Theory and Practice – Dan C. Marinescu

Content Delivery Network (CDN) menține in cache copii ale datelor pentru a marii puterea de procesare. Componenta Conect suporta conexiuni IP intre utilizatori și aplicațiile ce rulează in Azure/ API interface a fost construita pe baza REST, HTTP și XML. Platforma include 5 servicii Live Services, SQL Azure, AppFabric, SharePoint, și Dynamics CRM. De asemenea este oferita și o librărie client și tool-uri pentru dezvoltarea de aplicații Cloud in Visual Studio.

Scalabilitatea, balansarea încărcării, managementul memoriei și siguranța datelor este asigurata de fabric controller, ce reprezintă o aplicație distribuita replicata peste un grup de mașini ce dețin toate resursele din mediul de procesare: computers, switch, load balancers și este conștient de existența aplicațiilor Windows Azure. Fabric Controller decide unde sa ruleze noile aplicații, alege serverele fizice pentru optimizarea utilizării resurselor folosind informațiile de configurare încărcate cu fiecare noua aplicație Azure. Informația de configurare este descrisa de un XML ce are informația legata de cate instanțe web, cate instanțe worker și ce alte resurse are nevoie aplicația pentru a rula. Fabric controller utilizează fișierul de configurare pentru a determina cate mașini virtuale sa creeze.

Blobs, tabele, cozi, și drivere sunt folosite ca spațiu de stocare scalabil. Blob conține date binare; un container este format din unul sau mai multe blobs. Blob-urile pot fi de până la un terabyte și ei poate au asociat metadate (de exemplu, informații despre unde s-a luat o fotografie JPEG). Blob-urile permit Windows Azure să interacționeze cu mediu de stocare persistent, ca și cum ar fi fost un volum NTFS local. Cozile permite rolului Web să comunice asincron cu rolul worker.

2.4 Platforme software Open-source pentru private cloud

Private Cloud oferă o alternativă eficientă pentru organizații foarte mari. Un private cloud are în esență, aceleași componente structurale ca unul comercial: servere, rețea, virtual machine monitor (VMM) care rulează pe sisteme individuale, o arhiva ce conține imagini de disc pentru mașini virtuale (VM), un front-end pentru comunicare cu utilizatorul și un modul de control infrastructurii cloud. Platformele OpenSource de cloud computing cum ar fi Eucalipt, OpenNebula și Nimbus poate fi folosit ca o infrastructură de control pentru un nor privat.

Schematic, o infrastructură de nori efectuează pașii următori pentru a rula o aplicație:

Preia datele introduse de utilizator in interfața de management.

Preia imaginea de disc de un VM dintr-un depozit (repository).

Localizează un sistem cere VMM ce rulează pe acest sistem pentru a configura un VM.

Invocă DHCP și software-ul IP bridging pentru a configura o adresă MAC și IP pentru VM.

Vom discuta in continuare despre trei software open source ce ofera solutii de cloud computing: Eucalyptus, OpenNebula, and Nimbus.

Eucalyptus (www.eucalyptus.com) este echivalentul opensource pentru Amazon EC2. Suporta câteva sisteme de operare ce include CentOS, RedHat, Ubuntu

Componentele Eucalyptus sunt:

Mașină virtuală. Rulează pe mai multe VMMs, inclusiv Xen, KVM , și VMware.

Controler de nod. Rulează pe fiecare server sau nod desemnate pentru a găzdui un VM și controlează activitatea nodului. Raportează la un controler de cluster.

Controler de cluster. Controlează o serie de servere. Interacționează cu controlerul de nod pe fiecare server pentru a programa cereri pe acel nod. Cluster controller-ele sunt gestionate de către controlorul de cloud.

Controllerul de cloud. Oferă acces cloud pentru utilizatorii finali, dezvoltatori și administratori. Este accesibil printr-o interfața web sau linie de comanda. Face managementul resurselor cloud, face programarea la nivel înalt a deciziilor și interacționează cu controlere cluster-ului.

Controler de stocare. Oferă disk-uri virtuale persistente pentru aplicații. Este corespondentul EBS . Utilizatorii pot crea snapshots la volumele EBS. Snapshot-urile sunt stocate în Walrus și făcute disponibile pentru zonele de disponibilitate.

Serviciu de stocare (Walrus). Prevede stocare persistentă și, în mod similar la S3, permite utilizatorilor pentru a stoca obiecte în buckets.

Sistemul suportă o separare puternică între spațiul utilizatorului și spațiul administratorului; utilizatorii accesează sistemul printr-o interfața Web, întrucât administratorii nevoie de root acces. Sistemul suporta un management de resurse descentralizate pe mai multe grupuri, cu mai multe controllere cluster, dar un singur nod central de management a interfețelor utilizatorilor. El pune în aplicare un sistem de stocare distribuite analog sistemului Amazon S3, numit Walrus. Procedura de creare a unei mașini virtuale este descrisa mai jos:

euca2ools front-end este utilizat pentru a solicita un nou VM.

Imaginea de disc folosita pentru VM este transferata la un nod de calcul.

Imaginea de disc este modificata pentru utilizarea de VMM pe nodul de calcul.

Nodul de calcul setează un bridge de rețea pentru a oferi interfață de rețea virtuală (NIC) cu o adresa virtuala Media Acces Control (MAC).

În nodul head DHCP-ul este configurat cu o pereche de MAC/IP.

VMM activează VM.

Utilizatorul poate acum sa folosească ssh pentru a se conecta direct la VM.

Sistemul poate suporta un număr mare de utilizatori într-un mediu Enterprise. Utilizatorii sunt protejați de complexitatea configurațiilor disk-urilor și pot alege configuratia VM dintr-un set de 5 configurații disponibile procesoare, memorie și spațiu de hard disk setat de către administratorii de sistem.

Open-Nebula (www.opennebula.org) este un private cloud cu utilizatori ce se loghează în nodul head pentru a accesa funcțiile de cloud. Sistemul este centralizat și configurația implicită utilizează NFS (Network file system). Procedura pentru a construi o mașină virtuală este format din mai multe etape:

utilizator se loghează pe nodul head prin SSH

sistemul folosește comanda onevm pentru a solicita un VM

imaginea discului VM este transformat pentru a se potrivi dimensiunea corectă și de configurare în directorul NFS pe nodul cap

daemon-ul oned pe nodul head utilizează SSH pentru a se loga pe nodul de calcul

nodul de calcul setează bridge-ul de rețea pentru a oferi un NIC virtual cu un MAC virtual

fișierele necesare VMM sunt transferate la nodul de calcul prin NFS

VMM pe nodul de calcul pornește VM

utilizatorul poate porni o sesiune SSH direct la VM ce rulează nodul de calcul.

Conform unei analize acest sistemul este cel mai potrivit pentru o operațiune care implică un grup mic sau mijlociu de utilizatori, care sunt în măsură să configureze acest sistem versatil bazat pe nevoile lor.

Nimbus (www.nimbusproject.org) este o soluție cloud pentru aplicații științifice bazata pe software-ul Globus. Sistemul moștenește de la Globus stocarea imaginilor, credentialele pentru autentificarea utilizatorului, și cerința ca un proces Nimbus ce rulează sa poate face SSH în toate nodurile de calcul. Personalizările în acest sistem poate fi realizat numai de către administratorii de sistem.

Comparație intre cele trei sisteme Private Cloud:

Tabel 1: comparatie intre Eucalyptus, OpenNebula, and Nimbus

Sursa: Cloud Computing – Theory and Practice – Dan C. Marinescu

OpenStack este un proiect open-source început de către National Aeronautics și Space Administration (NASA) in colaborare cu Rackspace (www.rackspace.com) ce avea ca scop dezvoltarea unui sistem cloud pentru ferme de servere ce rulează pe hardware standard. După abandonarea proiectului de către NASA care si-a mutat infrastructura cloud pe AWS alte companii s-au implicat, printre care și HP, Cisco, IBM, RedHat, VMware pentru continuarea proiectului. Versiunea curenta are o gama larga de caracteristici cum ar fi programming interfaces (APIs) reboot, suspend, terminate, live VM management pentru instanțele ce rulează pe OpenStack. Administratorii și utilizatorii pot accesa resursele printr-o interfața web numita Dashboard. Platforma OpenStack o vom discuta in detaliu in capitolul 4.

Capitolul 3

Specificațiile Tehnice ale Sistemelor Virtualizate

Trei clase de abstracțiuni fundamentale – interpreți, memorie și link-uri de comunicație -sunt necesare pentru a descrie funcționarea unui sistem de calcul. Realizarea fizică a fiecăruia dintre aceste abstracțiuni, cum ar fi procesoare care prelucrează informații, memoria primara și secundara pentru stocarea de informații și canale de comunicare care să permită diferitelor sisteme sa comunica cu unul altul, poate varia în lățime de bandă, latenta, fiabilitate și alte caracteristici fizice. Sisteme software, cum ar fi sistemele de operare sunt responsabile pentru managementul resurselor de sistem – implementări fizice a celor trei abstracțiuni.

Soluția tradițională pentru un centru de date este de a instala sisteme de operare standard pe sisteme individuale și se bazează pe tehnici de OS convenționale pentru a asigura partajarea resurselor, protecția aplicațiilor, și izolarea de performanță. Administrarea sistemelor, securitatea și managementul resurselor sunt o adevărată provocare pentru furnizorii de servicii; dezvoltarea de aplicații și optimizarea performanței sunt o provocare la fel de mare pentru utilizatori.

Alternativa este virtualizarea resurselor, o tehnica analizate în acest capitol. Virtualizarea este un principiu de bază pentru cloud computing – care simplifică unele dintre sarcinile de management de resurse. De exemplu, starea unei mașini virtuale (VM) care rulează sub un Virtual Mchine Monitor (VMM) poate fi salvata și migrata pe un alt server pentru a echilibra încărcarea. În același timp, virtualizarea permite utilizatorilor să operează în medii cu care sunt familiarizați.

Partajarea resurselor într-un mediu cu mașini virtuale necesită nu numai suport hardware amplu, în special, procesoare puternice, ci și o arhitectura cu suport pentru mai multe niveluri de control. Într-adevăr, resurse ca ciclurile CPU, memorie, secundara de stocare și lățime de bandă I/O și comunicare sunt partajate între mai multe mașini virtuale; pentru fiecare VM, resursele trebuie să fie partajate între mai multe instanțe ale unei aplicații.

3.1 Virtualizarea

Virtualizarea simulează interfața la un obiect fizic prin oricare dintre următoarele patru mijloace:

multiplexare. Creați mai multe obiecte virtuale la o instanță a unui obiect fizic. De exemplu, procesorul este multiplexate printre o serie de procese sau threads.

agregare. Creați un obiect virtuale din mai multe obiecte fizice. De exemplu, un număr de
discuri fizice sunt agregate într-un disc RAID.

emulația. Construirea unui obiect virtual din mai multe obiecte fizice . De exemplu un disk fizic emulează o emulează o memorie cu acces aleator.

multiplexare și emulație. Exemple: memorie virtuală cu paginare multiplexează memorie reala și disc, și o adresă de Virtual emulează o adresă reală; TCP emulează o legătura de biți și multiplexează un canal de comunicare fizic și un procesor.

Virtualizarea rezuma resursele care stau la baza și simplifică utilizarea lor, izolează utilizatorii unul de altul, și sprijină replicarea, care, la rândul său, creste elasticitatea sistemului. Virtualizarea este un aspect critic in cloud computing, la fel de important la furnizori cat și la consumatori de servicii de cloud, și joacă un rol important în:

Securitatea sistemului deoarece permite izolarea de servicii care rulează pe același hardware.

Performanta și fiabilitate pentru că permite aplicațiilor sa migreze de la o platformă la alta.

Dezvoltarea și managementul serviciilor oferite de un furnizor.

Izolarea de performanță.

Virtualizare a fost folosita cu succes încă de la sfârșitul anilor 1950. O memorie virtuală bazată pe paginare a fost primul implementat pe calculatorul Atlas la Universitatea din Manchester din Marea Britanie în 1959. într-un mediu de calcul cloud VMM rulează pe hardware-ul fizic și exporta resursele hardware la una sau mai multe sisteme de operare ce rulează in mașini virtuale. Un guest OS interacționează cu hardware-ul virtual în același mod in care ar interacționa cu hardware-ul fizic, dar sub ochiul atent al VMM care mediază toate interacțiunile OS guest cu hardware-ul. De exemplu, un VMM poate controla operațiuni I/O la două discuri virtuale implementate ca două seturi diferite de sectoare de pe un disc fizic. Servicii noi pot fi adăugate fără necesitatea de a modifica un sistem de operare. Confortul utilizatorului este o condiție necesară pentru succesul de utilitatea sistemului de calcul. Unul
de mai multe fațete ale comodității utilizatorului este abilitatea de a rula la distanță, utilizând software-ul sistemului și biblioteci necesare aplicațiilor. Confortul utilizatorilor este un avantaj major al unei arhitecturi VM fata de un sistem de operare tradițional. De exemplu, un utilizator al Amazon Web Services(AWS) ar putea încarcă o imagine in Amazon Machine Image (AMI) care conține aplicații, biblioteci, date și configurația asociata. Utilizatorul ar putea alege sistemul de operare pentru aplicație, apoi porni, termina, și monitoriza cât mai multe instanțe de AMI după cum este necesar, folosind servicii Web API-uri și instrumente de monitorizare a performantei și management oferite de AWS. Există efecte secundare ale virtualizării, în special penalizare de performanță și costurile de hardware-ul. Cum vom vedea în scurt timp, toate operațiunile privilegiate ale VM trebuie să fie prinse și validate de VMM, care în cele din urmă controlează comportamentul sistemului; overhead crescut are impact negativ asupra performanței. Costul de hardware pentru un VM este mai mare decât costul unui sistem care rulează un sistem de operare tradițional pentru că hardware-ul fizic este împărțit un set de sisteme de operare de tip guest și acesta este de obicei configurat cu procesoare mai rapide si/sau multicore, mai multă memorie, discuri mai mari, și interfețe suplimentare de rețea în comparație cu un sistem rulează un sistem de operare tradițional.

3.2 Layere virtualizare

O abordare comună pentru gestionarea complexității sistemului este de a identifica un set de starturi cu interfețe bine definite printre ele. Interfețe separate de diferite nivele de abstractizare. Stratificarea minimizează interacțiunile dintre subsisteme și simplifică descrierea subsistemelor. Fiecare subsistem este abstractizat prin interfețe cu celelalte subsisteme. Astfel, suntem capabili de a proiecta, implementa și modifica subsisteme individuale în mod independent.

Instruction set architecture (ISA) definește un set de instrucțiuni din procesor. De exemplu, arhitectura Intel este reprezentat de x 86 -32 și x 86 -64 instrucțiuni pentru sisteme ce suporta adresare pe 32-bit și respectiv 64-bit. Hardware-ul suportă două moduri de execuție, privilegiată, sau mod kernel și user mod. Setul de instrucțiuni constă din două seturi de instrucțiuni, privilegiat care pot fi executate numai în modul kernel și non-privileged instrucțiuni care pot fi executate în modul utilizator. Există, de asemenea instrucțiunile senzitive care pot fi executate în kernel și în modul utilizator dar care se comportă diferit. Sistemele informatice sunt destul de complexe, și funcționarea lor este cel mai bine înțeleasă atunci când luăm în considerare un model similar cu cel din figura 4, care prezinta interfețele printre componentele software-ul și hardware. Hardware-ul este format din unul sau mai multe procesoare multi-core, interconectare sistemului (de exemplu, una sau mai multe bus-uri), o unitate de traducere de memorie, memoria principală și dispozitive I/O, inclusiv una sau mai multe interfețe de rețea. Cererile scrise în limbaje de nivel înalt (HLL) adesea numite module de bibliotecă și sunt elaborate în codul obiect. Operațiuni privilegiate, cum ar fi solicitările de I/O, nu pot fi executate în modul utilizator; în schimb, modulele aplicației și biblioteca apelează sistemul operare ce determină dacă operațiunile privilegiate ale aplicației nu încalcă securitatea sistemului sau integritatea sa, dacă nu, le execută în numele utilizatorului. Binare care rezultă din translatarea programelor HLL sunt orientate spre o arhitectura specifica hardware.

Prima interfața despre care vom discuta este instruction set architecture (ISA) aflata la limita dintre hardware și software. Interfața următoare este application binary interface (ABI), care permite ansamblul ce constă din aplicații și modulele librarii sa acceseze hardware-ul. ABI nu include instrucțiunile de sistem privilegiat; în schimb se invocă apeluri de sistem. În cele din urmă, application program interface (API) definește setul de instrucțiuni de hardware ce a fost conceput pentru a executa și dă aplicației accesul la ISA. Acesta include HLL librăria de apeluri, care deseori invoca apeluri de sistem. Un proces este abstractizarea pentru codul unei aplicații la momentul execuției; un thread este un proces ușor . ABI este proiecția sistemului informatic văzut de proces, și API este proiecția de sistem din perspectiva programului HLL.

Figura 4: Layerele și interfețele dintre acestea într-un computer

Sursa: Cloud Computing – Theory and Practice – Dan C. Marinescu

În mod evident, binarele create de un compilator pentru o interfața ISA și un sistem de operare specific nu sunt portabile. Astfel de cod nu poate rula pe un computer cu o interfața ISA diferita sau pe computere cu aceeași ISA dar sisteme de operare diferite. Cu toate acestea, este posibil pentru a compila un program HLL pentru un mediu VM, așa cum se arată în figura 5, unde codul portabil este produs și distribuit și apoi convertit de traducători binare pentru ISA de pe sistemul gazdă. Dynamic binary translation convertește blocuri de instrucțiuni ale guest-ului de la cod portabil la instrucțiunile gazdei și conduce la o semnificativă îmbunătățirea a performanței datorita faptului ca aceste blocuri sunt în cache și reutilizate.

Figura 5: High-level language (HLL)

Sursa: Cloud Computing – Theory and Practice – Dan C. Marinescu

3.3 Virtual machine monitors

Virtual machine monitor (VMM), numit și Hypervisor, este un software care partiționează in mod protejat resursele unui sistem informatic într-unul sau mai multe mașini virtuale. Un sistem de operare guest este un sistem de operare care rulează sub controlul VMM și nu direct pe hardware. VMM se execută în modul kernel, iar un guest OS se execută în modul utilizator. Uneori, hardware-ul suportă un al trei-lea mod de execuție pentru OS de tip guest. VMMs permite mai multor sisteme de operare sa ruleze simultan pe o platformă hardware singulara in același timp. VMM impune izolarea intre aceste sisteme, sporind astfel securitatea. VMM controlează cum sistemul de operare guest folosește resursele hardware. Evenimentele care au loc într-un VM nu afecta alte VM care rulează sub același VMM.

In același timp, VMM permite:

Mai multe servicii împărtășesc aceeași platformă.

migrarea unui server de la o platformă la alta, așa numita live-migration.

Modificarea sistemului păstrând compatibilitatea cu sistemul original.

Atunci când un guest OS încearcă să execute o instrucțiune privilegiata, VMM oprește operațiunea și impune operațiunea corecta și siguranța în exploatare. VMM garantează izolarea individuala a unui VM și asigura izolarea și securitatea, ce reprezintă o îngrijorare majora in cloud computing. În același timp VMM monitorizează performanța sistemului și ia măsuri corective pentru a evita degradarea performanței; de exemplu, VMM poate face swap unei VM (copiază toate paginile din acest VM din memoria reala pe disc și memoria fizica devine disponibila pentru paginare de către alte VMs) pentru a evita degradarea performantei.

VMM virtualizează procesor și memorie. De exemplu, VMM capturează cicli de procesor le aloca pe sistemele de operare guest. În cazul în care un guest OS dezactivează întreruperile, VMM pune in memoria tampon aceste întreruperi până când guest OS le executa. VMM păstrează o tabela de tip shadow page pentru fiecare guest OS și replici pentru orice modificare făcută de guest OS în propria tabela shadow page. Această tabela shadow page indica pagina reală de memorie și este utilizat de componenta hardware numita memory management unit (MMU) pentru dynamic address translation.

Virtualizarea memoriei are implicații importante asupra performanței. VMMs foloși o serie de tehnici de optimizare; de exemplu, sistemele VMware evita duplicarea de pagini de memorie între diferite mașini virtuale; acestea să mențin doar o copie a paginii partajate și de a foloși politici copy-on-write întrucât Xen impune izolarea totala a VM și nu permite schimbul de pagini de memorie. VMM controlează gestionarea memoriei virtuale și decide ce pagini să trimită in swap; de exemplu, atunci când VMware ESX server dorește să facă swap, se folosește un procesul de balloon în interiorul un guest OS și cerere acestuia să aloce mai multe pagini în pentru sine, astfel muta in swap unele dintre procesele care rulează sub acest VM. Apoi forțează procesul de balloon să renunțe la controlul paginilor.

3.4 Mașinile virtuale

O mașină virtuală (VM) este un mediu izolat, care pare a fi un întreg computer dar de fapt doar are acces la o parte din resursele acestuia. Fiecare VM pare a rula direct pe hardware, dând aspectul mai multor instanțe de același computer, deși toate sunt acceptate de un singur sistem fizic. Mașinile virtuale au apărut încă de la începutul anilor 1970, când IBM a lansat sistemul de operare VM/370.

Figura 6: (a) taxonomia procesului și sistemului VMs pentru același ISA și pentru diferite ISA. Tradițional, hibrid și găzduit sunt trei clase de VM pentru sisteme cu același ISA. (b) VM tradiționale. VMM suportă multiple VM și rulează pe același hardware. (c) un VM hibrid. VMM împarte hardware-ul cu un sistem de operare gazdă și acceptă mai multe mașini virtuale. (d) hosted VM. VMM rulează sub un sistem de operare gazdă.

Sursa: Cloud Computing – Theory and Practice – Dan C. Marinescu

Putem distinge două tipuri de VM: proces și sistem VM (a se vedea figura 6(a)). Procesul VM este o platforma virtuala creata pentru un proces individual și distrus odată ce procesul se încheie. Practic toate sistemele de operare furnizează un proces VM pentru fiecare dintre aplicațiile care rulează, dar mult mai interesant procesul VM sunt cele care acceptă binare compilate pe un set de instrucțiuni diferite. Un sistem VM suportă sistem de operare cu multe procese de utilizator. Când VM rulează sub controlul de un sistem de operare normal și oferă o platforma independenta pentru o singură aplicație, avem o aplicație mașina virtuala (de exemplu, Java Virtual Machine (JVM)).

Tabel 2: Tipuri de hipervizoare

Sursa: Cloud Computing – Theory and Practice – Dan C. Marinescu

O căutare in literatură relevă existența a 60 mașini virtuale diferite, multe create de mari companii de software; Tabelul de mai sus prezinta un subset al acestora.

Un sistem mașina virtuala oferă un sistem complet; fiecare VM poate rula propriul sistem de operare, care la rândul său poate rula mai multe aplicații. Sisteme cum ar fi Linux-Vserver, OpenVZ (Open Virtualization), Jails în FreeBSD și Zonele in Solaris, bazat pe Linux, FreeBSD și respectiv Solaris, implementează tehnologii de virtualizare la nivel de sistem de operare.

Virtualizarea la nivelul sistemului de operare permite unui server fizic sa ruleze mai multe instanțe ale sistemului de operare izolat, sunt obiectul mai multor constrângeri; instanțele sunt cunoscute ca containers, virtual private servers (VPSs), or virtual environments (VEs). De exemplu, OpenVZ necesită atât gazdă cat și guest OS sa fie o distribuție linux. Aceste sisteme pretind performanțe mai mari față de sistemele bazate pe VMM cum ar fi Xen sau VMware , există doar o penalizare de performanță 1-3% pentru OpenVZ în comparație cu un stand-alone Linux server. OpenVZeste licențiat sub GPL versiunea 2.

Reamintind faptul că VMM permite rularea mai multor mașini virtuale pentru a partaja un sistem.

Mai multe organizări ale stack-ului de software sunt posibile:

Tradițional. VM, de asemenea, numit și "bare metal" VMM. Un software de mici dimensiuni care rulează direct de pe hardware-ul mașinii gazdă; avantajul său principal este de performanță. exemple:VMWare ESX, ESXi, Xen , OS370 , și Denali.

Hibrid. VMM împarte hardware-ul cu sistemul de operare existent. Exemplu:VMWare Workstation

Găzduit. VM rulează pe un sistem de operare existent. principalul avantaj al acestei abordări este că VM este mai ușor de a construit și a instalat. Un alt avantaj al acestei soluții este că VMM ar putea foloși mai multe componente din OS ca scheduler, pager și drivere I/O, mai degrabă decât furnizarea de propriile sale componente. Un preț plătit pentru această simplitate este overhead crescut și penalizare de performanță; într-adevăr, operațiuni I/O, page faults și planificare cereri la un guest OS nu sunt gestionate direct de VMM. În schimb, ei sunt trecuți la OS gazdă. Performanță, precum și provocări pentru a sprijini izolarea completă de mașini virtuale să facă această soluție mai puțin atractive pentru servere într-un cloud computing. Exemplu: User-mode Linux.

O diferență semantică există între serviciile adăugate și mașinile virtuale. Serviciile oferite de mașina virtuală "operează abstracțiuni furnizate de sistemul de operare guest . . . . Este dificil de a oferi un serviciu care verifică integritatea sistemului de fișiere fără cunoștințele structurii de pe disc.

3.5 Performanta și izolarea de securitate

Izolarea performanței este o condiție critică pentru garantarea calității serviciului (QoS) in medii de calcul shared. Într-adevăr, dacă comportamentul run-time al unei aplicații este afectat de alte aplicații care rulează concomitent și, astfel, este concurenta pentru cicluri de CPU, cache, memorie principală, disc și rețea, este destul de dificil de prezis momentul finalizării unui task. De asemenea, este la fel de dificil optimizarea aplicațiilor. Mai multe sisteme de operare, inclusiv Linux /RK, QLinux, și SILK, au suport pentru unele izolări de performanță, dar probleme încă exista pentru că trebuie să țină seama de toate resursele folosite și pentru a distribui overhead pentru diferite activități din sistem, inclusiv contextului de comutare și paginare, pentru utilizatori individuali – o problemă deseori descrisă ca QoS crosstalk.

Virtualizare procesorului prezintă mai multe copii de același procesor sau core pe sistemele multi-core. Codul este executat direct de hardware, întrucât procesorul emulat prezintă un model de un alt sistem hardware în care instrucțiunile sunt emulate de software-ul mai lent decât virtualizarea. Un exemplu este Microsoft VirtualPC, care ar putea rula pe alte chip set de decât x86. Acesta a fost folosit pe hardware-ul Mac până când Apple a adoptat cipuri Intel.

Sistemele de operare tradiționale multiplexează procese multiple sau threads, întrucât o virtualizare susținută de un VMM multiplexează sisteme de operare complete. Evident, există o penalizare de performanță, deoarece un sistem de operare este mai mare consumator de resurse decât un proces și overhead-ul este mai mare. VMM execută direct pe hardware un subset de instrucțiuni utilizate frecvent pe mașină generate de aplicație și emulează privilegiat aceste instrucțiuni, inclusiv cererile către dispozitivul I/O. Subsetul de instrucțiuni executate direct de hardware include instrucțiuni aritmetice, accesul la memorie, și instrucțiunile de ramificare.

Sistemele de operare utilizează procesul preparării nu numai pentru schimbul de resurse, dar, de asemenea și să sprijine izolare. Din păcate, acest lucru nu este suficient dintr-o perspectivă de securitate. Odată ce un proces este compromis, este destul de ușor pentru un atacator sa pătrunde întregul sistem. Pe de altă parte, software-ul care rulează pe o mașină virtuală are constrângerile date de propriul sau hardware dedicat; se poate sa acceseze numai dispozitivele virtuale imitate de software. Acest layer de software-ul are potențialul de a asigura un nivel de izolare aproape echivalent cu izolarea prezentata intre două sisteme fizice diferite. Astfel, virtualizarea poate fi folosita pentru a îmbunătăți securitatea într-un cloud computing.

Un VMM este un sistem mult mai simplu și mai bine determinat decât un sistem de operare tradițional. De exemplu, Xen VMM are aproximativ 60.000 de linii de cod, iar Denali VMM a numai jumătate că, sau 30.000 de linii de cod. Breșele de securitate in VMM se reduce considerabil deoarece sistemele expune un număr mult mai mic de funcții privilegiate. De exemplu, Xen VMM pot fi accesate prin intermediul a 28 de apeluri de sistem, iar un Linux standard permite sute (de exemplu, Linux««2.6.11 permite 289 apeluri de sistem). Pe lângă o serie de apeluri de sistem, un sistem de operare tradițional acceptă dispozitive speciale (de exemplu, / dev/kmem) și multe programe privilegiate de o terță parte (de exemplu, sendmail și sshd).

3.6 Virtualizarea completa și Paravirtualizarea

În 1974 Gerald J. Popek și Robert P. Goldberg au dat un set de condiții suficiente pentru ca o arhitectura de calculator sa suporte virtualizarea și sa permite unui VMM să opereze eficient:

• Un program care rulează sub VMM ar trebui să prezinte un comportament, în esență, identic cu cel demonstrat atunci când programul se execută direct pe o mașină echivalenta.

• VMM ar trebui să controleze complet resursele virtualizate.

• O fracțiune semnificativă statistic de instrucțiuni mașină trebuie să fie executat fără intervenția VMM.

Un alt mod de a identifica o arhitectură potrivita pentru o mașină virtuală este de a distinge două clase de mașină de instrucțiuni: instrucțiuni sensibile, care necesita precauții speciale in timpul execuției, și instrucțiuni inofensive, care nu sunt sensibile. La rândul său, pot fi instrucțiuni sensibile:

• Controlul sensibil, sunt instrucțiuni care încearcă să schimbe fie alocarea de memorie sau modul privilegiat.

• Mod sensibil, care sunt instrucțiuni al cărui comportament este diferit în modul de privilegiat.

O formulare echivalentă a condițiilor pentru o virtualizare eficienta se poate baza pe această clasificare de instrucțiuni mașină. Un computer VMM pentru un a treia-generatie (sau ulterior) pot fi construite dacă setul de instrucțiuni sensibile este un subset din instrucțiunile privilegiate din mașină. Să se ocupe de instrucțiuni non virtualizabile, ar putea recurge la două strategii:

• traducere binara. VMM monitorizează executarea sistemelor de operare guest; non virtualizabile instrucțiuni de executate de un sistem de operare guest sunt înlocuite cu alte instrucțiuni.

• Paravirtualization. sistemul de operare guest este modificat pentru a utiliza numai instrucțiuni care pot fi virtualizate.

Există două abordări de bază pentru un procesor folosit la virtualizare: full virtualization, în care fiecare mașina virtuala rulează pe o copie exactă a hardware-ul real și paravirtualization, în care fiecare mașina virtuala rulează pe o copie ușor modificata de hardware reale (a se vedea figura 7). Motivele pentru care paravirtualization este adesea adoptata sunt (i) nu poate fi virtualizate unele aspecte ale hardware-ului; (ii) pentru a îmbunătăți performanța; și (iii) să prezinte o interfață simplă. VMware VMM sunt exemple de full virtualization. Xen și Denali sunt bazate pe paravirtualization;

Full virtualization necesită o arhitectură virtualizabila; hardware-ul este complet expus la guest OS, care se execută neschimbate, iar acest lucru asigură că acest mod de execuție directă este eficient. Pe de altă parte, paravirtualization se face pe unele arhitecturi cum ar fi x86 ce nu sunt ușor de virtualizat. Paravirtualization cere ca guest OS sa fie modificat pentru a rula sub VMM; în plus, codul de OS guest trebuie să fie portat pentru platforme hardware individuale.

Sisteme cum ar fi VMware ESX server suporta virtualizarea completa a arhitecturii x86. Virtualizarea unității de management a memoriei (MMU) și faptul că instrucțiunile privilegiate executate de un guest OS eșuează și prezintă unele provocări; de exemplu, pentru a aborda problema din urmă, trebuie să introduceți traps ori de câte ori sunt executate instrucțiuni privilegiate de către un guest OS. Sistemul trebuie să mențină de asemenea, copii de siguranța ale sistemului de structuri, cum ar fi page table, traps pentru fiecare eveniment care afectează starea acestei structuri de control; overhead-ul multora din aceste operații este substanțial.

Performanța aplicațiilor sub o mașină virtuală este critică; în general, virtualizarea adaugă unele niveluri de overhead care afectează în mod negativ performanțele. În unele cazuri, o aplicație care rulează sub un VM performează mai bine decât una care rulează pe un sistem clasic.

Figura 7: (a) Full virtualization necesită abstractizarea layer-ului hardware pentru ca guest OS sa aibă unele cunoștințe despre hardware-ul pe care rulează. (b) Paravirtualization evită această cerință și permite compatibilitatea deplină la interfața binara a aplicației (ABI).

Sursa: Cloud Computing – Theory and Practice – Dan C. Marinescu

Acest lucru este valabil în cazul politicii numită izolarea cache-ul. Cache-ul, în general, nu este împărțit la fel intre procesele care rulează sub un OS clasic, din moment ce un proces poate foloși mai mult spațiu de memorie cache decât celelalte. De exemplu, în cazul de două procese, unul scrie intensiv și altul citește intensiv, cache-ul poate fi agresiv umplut de prima. Sub politica de izolare cache, cache-ul este împărțit între VM și este benefic pentru a executa sarcini de lucru concurente în două VM diferite. Performanței aplicațiilor I/O ce rulează in VM depinde de factori precum partiția de disc folosita de VM, utilizarea CPU, de performanță I/O pentru VM concurente și mărimea blocului I/O. Pe platforma Xen, discrepanțele între alegerea optimă și cea implicita sunt la fel de mare ca de la 8% la 35%.

3.7 Suportul hardware pentru virtualizare

La începutul anului 2000, a devenit evident că suportul hardware pentru virtualizare este necesar, și Intel și AMD au început activitatea pe extensii de virtualizare prima generație de arhitectura x86. În anul 2005 Intel a lansat două model Pentium 4 ce suportau VT-x , iar în 2006 AMD a anunțat Pacifica și apoi mai multe modele Athlon 64.

In 2006 un document analizează provocările pentru virtualizarea arhitecturile Intel și apoi prezintă arhitecturile de virtualizare VT-x și VT-i pentru x86 și Itanium. Soluțiile software din acel moment au adresat câteva provocări, dar soluția hardware-ul ar putea îmbunătăți nu numai performanță, dar, de asemenea, securitate și, în același timp, simplificarea sistemelor software. Vom examina mai întâi problemele cu care se confruntă virtualizarea arhitecturii x86:

Ring deprivileging. Acest lucru înseamnă că un VMM forțează software-ul, sistemul de operare și aplicațiile din guest să ruleze la un nivel de privilegiu mai mare decât 0. Reamintim faptul că arhitectura x86 oferă patru inele de protecție nivelul 0-3. Două soluții sunt apoi posibile: (a) modul (0/1/3), în care VMM, OS și aplicațiile rulează la nivelurile privilegiate 0, 1 și 3; sau (b) modul de (0,3,3)în care VMM, un guest OS, și aplicațiile rulează la nivelurile privilegiate 0, 3, și 3. Primul mod nu este fezabilă pentru procesoarele x86 în modul 64 de biți.

Ring aliasing. Problemele create atunci când un guest OS este forțat să ruleze la un nivel de privilegiu altul decât cel pentru care a a fost inițial conceput. De exemplu, când registrul CR este împins, nivelul privilegiat curent este, de asemenea, stocate in stiva.

Address space compression. VMM folosește părți din spațiul de adrese guest pentru a stoca mai multe structuri de date sistem, cum ar fi tabela interrupt-descriptor și tabela global-descriptor. Astfel de structuri de date trebuie să fie protejate, dar software-ul guest trebuie să aibă acces la ele.

Nonfaulting access to privileged state. Mai multe instrucțiuni, LGDT, SIDT, SLDT , și LTR care încarcă registrele GDTR, IDTR, LDTR , și TR, pot fi executate doar de software care rulează la nivelul privilegiat 0, deoarece aceste instrucțiuni indica structuri de date, care controlează operațiunile de CPU.

Figura 8: (a) cele două moduri de funcționare a VT-x și cele două operațiuni de tranzit de la unul la altul. (b) VMCS
include zonele host-state și guest-state care controlează tranzițiile de intrare și ieșire ale unui VM.

Sursa: Cloud Computing – Theory and Practice – Dan C. Marinescu

Cu toate acestea, instrucțiuni care provin din aceste registre eșuează fără a returna o eroare, atunci când sunt executate la un nivel privilegiat altul decât 0. Acest lucru implică faptul că un guest OS executa una dintre aceste instrucțiuni și nu își da seama că instrucțiunea nu a reușit.

Guest system calls. Două instrucțiuni, SYSENTER și SYSEXIT, acceptă apeluri de sistem low-latenta. Primul provoacă o tranziție la nivelul privilegiat 0, întrucât a doua provoacă o tranziție de la nivelul privilegiat 0 și eșuează dacă este executat la un nivel mai mare decât 0. VMM trebuie să emuleze atunci fiecare execuție guest a oricăreia dintre aceste instrucțiuni, care are un impact negativ asupra performanței.

Interrupt virtualization. Ca răspuns la întreruperile fizice, VMM generează o întrerupere virtuala și o livrează mai târziu către guest OS. Dar fiecare OS are abilitatea de a masca întreruperile; astfel întrerupe virtuale ar putea fi livrate doar la guest OS atunci când întreruperea nu este mascata. Urmărirea tuturor guest OS care încearcă să mascheze întreruperile complica foarte mult VMM și crește overhead-ul.

Access to hidden state. Elemente de starea sistemului (de exemplu, descriptor de cache pentru registrele de segment) sunt ascunse; nu există nici un mecanism pentru salvarea și restaurarea componentelor ascunse atunci când există in contextul trecerii de la VM unul la altul.

Ring compression. Paginarea și segmentare sunt două mecanisme pentru a proteja codul VMM de fi suprascrise de un guest OS și aplicații. Sisteme care rulează în modul 64 de biți pot foloși doar paginare, dar paginare nu distinge între nivelurile privilegiate 0, 1 și 2, deci guest OS trebuie să execute la nivel privilegiat 3, așa-numitele (0 / 3 / 3). Nivelurile privilegiate 1 și 2 nu pot fi utilizate; astfel numele de Ring compression.

Accesul constant la resursele privilegiate crește VMM overhead. Registrul task-priority (TPR) este folosit frecvent de un guest OS. VMM trebuie să protejeze accesul la acest registru și sa oprească toate încercările să-l acceseze. Acest lucru poate provoca o degradare semnificativă a performanței.

O facilitate arhitecturala majora oferita de VT-x este suportul pentru două moduri de operațiuni și o nouă structură de date numit structura de control mașină virtuală (VMCS), inclusiv host-state și guest-state (a se vedea figura 8):

VMX root. Destinat operațiunilor VMM și foarte aproape de x86 fără VT-x.

VMX nonroot. Destinat să suporte un VM.

Atunci când se executa o operațiune de intrare a VM, starea procesorului este încărcata de guest-state a VM programată să se execute; apoi controlul este transferat de la VMM la VM. O ieșire a unui VM salvează starea procesorului in zona guest-state a VM care rulează; apoi se încarcă starea procesorului in zona host-state și în cele din urmă transfera controlul la VMM. Rețineți că toate operațiunile de ieșire ale VM utilizează un punct de intrare comun in VMM.

Fiecare operațiune de ieșire a unui VM salvează motivul pentru ieșire și, în cele din urmă, unele se califica în VMCS. Unele dintre aceste informații sunt stocate ca bitmap-uri. De exemplu, excepție bitmap precizează care dintre cele 32 de posibilele excepții cauzate la ieșire. The I/O bitmap conține o intrare pentru fiecare port în un 16-bit in spațiul I/O.

Zona VMCS se refera la o adresă fizică și aspectul său nu este fixat de arhitectura dar poate fi optimizata de o implementare speciala. VMCS include biții de control care să faciliteze punerea în aplicare a întreruperilor virtuale. De exemplu, external-interrupt exiting, când este setat, cauzează executarea unei operațiuni VM exit; în plus, guest-ului nu ii este permis sa mascheze aceasta întrerupere. Atunci când interrupt window exiting este setata, o operațiune VM exit este declanșată în cazul în care guest-ul este gata să primească întreruperea.

Procesoare bazate pe două noi arhitecturi de virtualizare, VT-d 6 și VT-c, au fost dezvoltate. Primul sprijină unitatea de managementul a memoriei I/O virtualizarea (I/O MMU) și a doua de virtualizarea rețelei.

Cunoscuta ca PCI pass-through, virtualizarea I/O MMU oferă acces direct pentru VMs la dispozitive periferice. VT-d suporta:

• remapare adresa DMA, care este adresa de translatare pentru transferuri de dispozitive DMA.

• remapare întrerupere, care este de izolarea întreruperilor dispozitivelor și rutarea VM.

• asignare device I/O, in care un administrator poate asigna dispozitive la un VM in orice configurație.

• caracteristici fiabilitate, care raportează și înregistrează DMA și întrerupe erori care altfel poate afecta memoriei și sa aibă impact asupra izolării VM.

Capitolul 4

Platforma Cloud Openstack

Proiectul OpenStack este o platformă open source de cloud computing pentru privat, public și hibrid cloud care este simplu de implementat, scalabilitate masiva și foarte multe facilitați. OpenStack oferă o soluție Infrastructure as a Service (IaaS) printr-un set de servicii interdependente.

OpenStack a început în 2010 ca un joint-venture între RackSpace Hosting și National Aeronautics and Space Administration (NASA). Astăzi mai mult de 200 de companii s-au alăturat proiectului, inclusiv AMD, Canonical (Ubuntu), Cisco, Dell, EMC, Ericsson, Groupe Bull, HP, IBM, Inktank, Intel, NEC, RedHat, SUSE Linux, VMware și Yahoo!

Proiectul este in prezent gestionat de către Fundația OpenStack, o entitate corporativă non-profit înființata in septembrie 2012 pentru a promova software-ul OpenStack și a comunității sale. Comunitatea lansează noi versiuni software in cicluri cu o frecventa de aproximativ 6 luni.

OpenStack crede în open source, open design, open development, toate într-o comunitate deschisa care încurajează participarea oricui. Viziunea pe termen lung pentru OpenStack este de a produce un open-source care să răspundă nevoilor de public și private cloud indiferent de dimensiunea furnizorilor de servicii. Serviciile OpenStack pot controla un pool foarte mare de resurse dintr-un centru de date.

Tehnologia din spatele OpenStack constă dintr-o serie de proiecte interdependente ce livrează diverse componente pentru o soluție de infrastructura cloud. Fiecare serviciu oferă o interfața API deschisă pentru ca toate aceste resurse sa poată fi gestionate printr-o interfața de management, care oferă administratorilor control în timp ce utilizatorilor le pune la dispoziție o interfața web pentru a proviziona resurse, un client pentru linie de comandă sau kituri de dezvoltare software care acceptă API. Multe din API-urile OpenStack sunt extensibile, in sensul ca se poate păstra compatibilitate cu un set de bază de apeluri în timp ce oferă acces la mai multe resurse și inovează prin intermediul extensiilor API. Proiectul OpenStack este o colaborare globală de dezvoltatori și specialiști in cloud computing. Proiectul produce un standard deschis de cloud computing pentru ambele platforme public și private cloud. Concentrându-se pe ușurința de implementare, scalabilitate foarte mare, o varietate bogata de caracteristici și extensibilitate enormă, proiectul își propune să ofere o soluție cloud practică și de încredere pentru toate tipurile de organizații.

Versiuni software Openstack:

Tabel 3: Versiunile OpenStack

Sursa: www.openstack.org

4.1 Arhitectura OpenStack

Proiectarea unui cloud bazat OpenStack este o mare realizare. Acesta necesită o înțelegere robustă a cerințelor și nevoilor utilizatorilor de cloud pentru a determina cea mai buna configurație posibila pentru a îndeplini nevoile acestora. OpenStack oferă o mare flexibilitate pentru a atinge aceste nevoi.

Modulele OpenStack sunt de următoarele tipuri:

Daemon – rulează ca proces in background, pe platformele linux de obicei este instalat ca un serviciu

Script – instalează un mediu virtual și rulează teste

Command-line interface (CLI) – permite utilizatorilor sa facă apeluri API către serviciile OpenStack prin intermediul comenzilor

Utilizatorii finali pot interacționa prin interfața web, CLI și API-uri. Toate serviciile se autentifica printr-un serviciu de identitate comună, și servicii individuale să interacționeze cu reciproc prin intermediul API-urilor publice, cu excepția cazului când administratorul are nevoie sa execute comenzi in mod privilegiat. Figura 9, "OpenStack (arhitectura logică)". Arată cele mai comune, dar nu numai, componente din arhitectura logica a unui cloud OpenStack.

Figura 9: OpenStack (arhitectura logică) Sursa: www.openstack.org

OpenStack oferă o soluție Infrastructure-as-a-Service (IaaS) printr-un set de servicii interdependente. Fiecare serviciu oferă o interfață de programare aplicatie (API) care facilitează integrarea acestora. În funcție de nevoile fiecarei organizatii, se pot instala unele sau toate serviciile.

Următorul tabel descrie serviciile OpenStack care alcatuiesc arhitectura OpenStack:

Tabel 4: Componentele OpenStack

Sursa: www.openstack.org

Legăturile dintre serviciile Openstack sunt reprezentate in arhitectura conceptuală prezentata in figura 10.

Figura 10 Arhitectura conceptuală OpenStack Sursa: www.openstack.org

4.2 Serviciile Openstack

In continuare vom descrie in detaliu serviciile OpenStack și legăturile dintre acestea

4.2.1 OpenStack Compute

Openstack Compute este folosit pentru a găzdui și face managementul resurselor de procesare din cloud. Este o componenta majora a sistemului Infrastructure-as-a-Service (IaaS). Modulele principale sunt implementate in Python.

Openstack Compute interacționează cu serviciul Openstack Identity pentru autentificare, Openstack Image service pentru disk și imagini de servere, și Openstack Dashboard pentru interfața user și administrativa. Accesul la imagini este limitat de proiecte și useri, cotele resurselor folosite sunt limitate per proiect. OpenStack Compute se poate extinde pe orizontala pe hardware standard și downloada imagini pentru lansarea instanțelor.

OpenStack Compute este format din următoarele componente:

API

nova-api service – accepta și răspunde apelurilor API inițiate de utilizatori. Serviciul are suport pentru OpenStack Compute API, Amazon EC2 API și un admin API special pentru userii cu drepturi extinse pentru rularea acțiunilor administrative. Impune anumite politici și inițiază cele mai multe activități de orchestrare, cum ar fi rularea unei instanțe

nova-api-metadata service – accepta cereri metadata de la instanțe. Este in general utilizat atunci când se rulează într-un mediu multi-host împreuna cu serviciul nova-network

Compute core

nova-compute service – un serviciu de tip worker ce creează și termina instanțe virtuale prin intermediul API-ului hypervisor. De exemplu:

XenAPI for XenServer/XCP

libvirt for KVM or QEMU

VMwareAPI for VMware

Procesarea este foarte complexa. Serviciul accepta acțiuni într-o coada și executa o serie de comenzi de sistem cum ar fi lansarea de instanțe KVM și updatarea stării acestora in baza de date

nova-scheduler service – primește o cerere pentru o instanță din coada de execuție și determina pe ce server sa ruleze

nova-conductor module – mediază interacțiunile dintre nova-compute și baza de date. Elimina accesul direct la baza de date cloud inițiata de către nova-compute

nova-cert module – un serviciu ce servește generarea de certificate digitale X509. Este necesar doar pentru EC2 API

Networking pentru mașini virtuale (VM)

nova-network worker daemon – similar cu serviciul nova-compute, accepta task-uri de networking din coada și manipulează rețeaua. Executa task-uri cum ar fi lan bridging sau schimbarea regulilor IP Tables

Console interface

nova-consoleauth – autorizează tokens pentru utilizatorii proveniți din console proxy

nova-novncproxy – oferă un proxy pentru accesarea instanțelor ce rulează in cloud prin intermediul unei conexiuni VNC

nova-spicehtml5proxy – oferă un proxy pentru accesarea instanțelor ce rulează in cloud prin intermediul unei conexiuni SPICE

nova-xvpvncproxy – oferă un proxy pentru accesarea instanțelor ce rulează in cloud prin intermediul unei conexiuni VNC. Suporta un client java specific OpenStack

nova-cert – certificate x509

Image management (EC2 scenario)

nova-objectstore – o interfața S3 pentru înregistrarea imaginilor folosind serviciul de imagini OpenStack. Folosit in principal pentru instalări care trebuie sa suporte euca2ools. Euca2ools discuta cu nova-ojectstore in limbaj S3 iar nova-objectstore translatează cererile S3 in cereri către serviciul de imagini

euca2ools client – un set de comenzi pentru managementul resurselor cloud. Nu este un modul OpenStack, se poate configura nova-api pentru rularea acestei interfețe

Command-line clients și alte interfețe

nova client – permite utilizatorilor și administratorilor sa introducă comenzi

Alte componente

The queue – un hub central pentru trecerea mesajelor de la un serviciu la altul. Este implementat folosind RabbitMQ. Ca și alternativa se poate implementa și folosind cozi de mesaje AMQP, cum ar fi Apache Qpid sau Zero MQ

SQL database – stochează stările build-time și run-time pentru infrastructura cloud, ce include:

Tipul de instanțe disponibile

Instanțe folosite

Rețele disponibile

Proiecte

In teorie OpenStack poate foloși orice tip de baza de date ce are suport pentru SQLAlchemy. Bazele de date comune sunt SQLite3 folosita pentru test și dezvoltare, MySQL și PostgreSQL.

4.2.2 OpenStack Storage

OpenStack folosește următoarele tipuri de storage:

Tabel 5: Tipuri de storage in OpenStack

Sursa: www.openstack.org

In OpenStack legat de storage trebuie luate următoarele in considerare:

Nu se poate foloși Opject Storage ca un disk de date tradițional. Object storage relaxează anumite constrângeri ale sistemului de fișiere POSIX-style pentru a obține alte avantaje. Toate obiectele pot fi accesate prin intermediul unui API ce folosește HTTP

Openstack Image este folosit pentru managementul imaginilor mașinilor virtuale într-un cluster, nu sa le stocheze. Oferă o abstractizare a diferitelor metode pentru crearea unei punți intre storage, nu și storage-ul in sine

OpenStack Object storage poate funcționa independent. Object Storage (swift) poate fi folosit independent de componenta Compute (nova)

Command-line clients și alte interfețe

Swift client – permite userilor sa execute comenzi in REST API prin intermediul unui client command-line autorizat fie ca administrator, user sau swift user

Swift-init – script care inițializează crearea unui fișier de tip inel

Swift-recon

Swift-ring-builder

OpenStack Object Storage

OpenStack Object Storage este un sistem de storage multi-tenant(chirias). Este foarte scalabil și poate face management unor cantități foarte mari de date nestructurate la un cost redus prin intermediul unui API RESTful HTTP

Include următoarele componente:

Proxy servers (swift-proxyserver) – accepta cereri OpenStack Object Storage API și HTTP in format raw pentru upload-ul fișierelor, modificare metadata și crearea containerelor. oferă și posibilitatea de a lista containerele și fișierele in browser-ul web

Account servers (swift-account-server) – face managementul utilizatorilor definiți in Object Storage

Container servers (swiftcontainer-server) – face managementul mapărilor pentru foldere și containere

Object servers (swift-object-server) – face managementul obiectului in sine, pe nodurile de stocare

Various periodic processes – executa task-uri de mentenanța pe storage. Serviciul de replicare asigura consistenta și disponibilitatea într-un cluster. Alte procese includ auditori, updaters și repetatori

WSGI middleware – este responsabil cu autentificarea

OpenStack Block Storage

OpenStack Block Storage service (cinder) adaugă storage persistent la o mașina virtuala. Furnizează o infrastructura pentru managementul mașinilor virtuale și interacționează cu OpenStack Compute pentru a oferi volume instanțelor. Serviciul permite de asemenea managementul snapshot-urilor pentru un volum și al tipului de volum.

Serviciul Block Storage este constituit din următoarele elemente:

Cinder-api – accepta cereri API și le trimite către cinder-volume pentru executare

Cinder-volume – interacționează cu serviciul Block Storage și procese cum ar fi cinder-scheduler prin intermediul unei cozi de mesaje. Serviciul răspunde operațiunilor de scriere și citire trimise către Block Storage

cinder-scheduler – selectează furnizorul de storage optim pe care sa creeze un volum. O componenta similara este nova-scheduler

cinder-backup – oferă servicii de backup pentru orice tip de volum într-un furnizor de storage pentru backup

Messaging queue – rutează informația intre procesele din Block Storage

4.2.3 OpenStack Networking

Serviciul de rețea OpenStack permite utilizatorilor crearea și atașamentul de interfețe gestionate de alte procese OpenStack la o rețea. Plug-ins pot fi implementate pentru a integra diverse echipamente de rețea și software, oferind flexibilitate pentru arhitectura și implementarea OpenStack.

Include următoarele componente:

neutron-server – accepta și ruteaza cereri API către plugin-ul OpenStack Networking potrivit sa execute o acțiune

OpenStack Networking plug-ins and agents conectează și deconectează porturi, creează rețele sau subretele și opera adresare IP. Acești agenți și plug-ins diferă intre ei și depind de furnizor și tehnologia folosita într-un cloud particular. OpenStack Networking vine cu plug-ins și agenți pentru switch-uri Cisco virtuale și fizice, produse NEC OpenFlow, Open vSwitch, Linux bridging și VMware NSX.

Agenți des întâlniți sunt L3 (layer 3), DHCP și plug-in agent

Messaging queue – folosit pentru a ruta informația intre neutron-server și diverși agenți și o baza de date unde sa stocheze starea rețelei pentru plug-ins particulare

OpenStack Networking in principal interacționează cu OpenStack Compute pentru a oferi conectivitate la rețea instanțelor ce rulează pe acestea.

4.2.4 OpenStack dashboard

OpenStack dashboard este o aplicație web modulara Django ce oferă o interfața grafica pentru serviciile OpenStack.

Figura 11: OpenStack dashboard

Sursa: www.openstack.org

De obicei dashboard este implementata folosind mod_wsgi in Apache. Se poate modifica codul sursa făcând-o astfel potrivita pentru anumite implementări.

Din punct de vedere al arhitecturii rețelei, acest serviciu trebuie sa fie accesibil utilizatorilor și API-urilor publice pentru fiecare serviciu OpenStack. Pentru a foloși funcționalitatea de administrare trebuie sa se conecteze și la Admin API, care nu trebuie sa fie accesibile utilizatorilor obișnuiți.

4.2.5 OpenStack Identity

Serviciul Openstack Identity oferă următoarele funcționalități:

Urmărirea utilizatorilor și a permisiunilor acestora

Oferirea unui catalog cu serviciile disponibile cu componenta API

Când se instalează serviciul Identity, trebuie instalat fiecare serviciu din instalarea OpenStack. Serviciul Identity poate apoi urmării ce serviciu este instalat și unde este localizat in rețea.

Pentru a înțelege serviciul Identity trebuie înțelese prima data următoarele concepte:

User – reprezentare digitala a unei persoane, sistem sau serviciu ce folosește serviciile cloud OpenStack. Serviciul Identity validează cererile primite de la useri care pretind ca fac acea cerere.

Credentials – date ce confirma identitatea unui utilizator. Ex: user și parola, user și API key

Authentication – procesul prin care se confirma identitatea unui user. OpenStack Identity confirma o cerere primita prin validarea unui set de credențele primite de la user. Inițial aceste credențiale sunt user name și parola sau cheie API. Când credentialele sunt validate, Identity lanseaza un token de autentificare pe care utilizatorul îl oferă in următoarea cerere.

Token – un string text alpha-numeric folosit pentru a accesa API-urile OpenStack și resursele. Un token poate fi revocat in orice moment și este valid pentru o durata finita.

Tenant – un container folosit pentru gruparea sau izolarea resurselor. Tenant grupează sau izolează de asemenea și obiecte de identitate.

Service – un serviciu OpenStack cum ar fi Compute (nova), Object Storage (swift) sau Image (glance). Furnizează unul sau mai multe obiective (Endpoint) pe care utilizatorii le pot accesa și executa operațiuni.

Endpoint – o adresa accesibila din rețea când folosita pentru accesarea unui serviciu, de obicei o adresa URL.

Role – o personalitate cu un set definit de drepturi și privilegii sa execute un set specific de operațiuni.

Keystone Client – o interfața command line pentru API-ul Identity (ex: keystone service-create și keystone endpoint-create).

Figura 11: OpenStack Identity process flow Sursa: www.openstack.org

4.2.6 OpenStack Image service

OpenStack Image service este componenta centrala a Infrastructure-as-a-Service (IaaS) cum este arătat și in Figura 10: Arhitectura Conceptuala. Accepta cereri API pentru disk sau server image și image metadata de la useri sau componentele OpenStack Compute. Suporta de asemenea disk-uri sau imagini server din repositoare diverse, incluzând Object Storage.

Un număr de procese periodice rulează pe OpenStack Image service pentru a oferi funcția de cache. Serviciul de replicare asigura consistenta și disponibilitatea într-un cluster. Alte servicii periodice sunt auditori, updaters și reapers.

Openstack Image service include următoarele componente:

glance-api – accepta cereri API pentru descoperirea de imagini, obținerea și stocare

glance-registry – stochează, procesează și obține metadata despre imagini. Metadata include articole cum ar fi mărimea și tipul

Database – stochează metadata imaginilor și se poate alege tipul de baza de date. Cele mai folosite sunt MySQL și SQLite.

Storage repository for image files – diverse tipuri de repository sunt suportate incluzând sistemul de fișiere normal, Object Storage, RADOS block devices, HTTP și Aazon S3. A se nota ca din unele repository se poate doar citi, nu și scrie.

4.2.7 OpenStack Telemetry

Modulul Telemetry efectuează următoarele funcții:

Sondaje eficiente de contorizare a datelor referitoare la serviciile OpenStack

Colectează evenimente și contorizează date monitorizând notificările trimise de către servicii

Publica datele colectate in diverse ținte incluzând data stores și cozi de mesaje

Creează alarme când datele colectate ies din regulile stabilite

Modulul Telemetry este compus din următoarele componente:

A compute agent (ceilometer-agent-compute) – rulează pe fiecare nod Compute și sondează statisticile de utilizare a resurselor

A central agent (ceilometer-agent-central) – rulează pe serverul central de management pentru a sonda statisticile de utilizare a resurselor ce nu sunt legate de instanțe și noduri Compute. Mai mulți agenți pot fi porniți pentru a obține scalabilitate pe orizontala.

A notification agent (ceilometer-agent-notification) – rulează pe serverul central de management și consuma mesajele din coada de mesaje pentru a construi evenimente și contorizarea datelor.

A collector (ceilometer-collector) – rulează pe serverul central de management și trimite telemetia colectata la un data store sau consumator extern fără notificare

An alarm evaluator (ceilometer-alarm-evaluator) – rulează pe serverul central de management și determina când alarmele trec de un prag setat într-un interval de timp

An alarm notifier (ceilometer-alarm-notifier) – rulează pe unul sau mai multe servere centrale și permite alarmelor sa fie setate pe baza unui prag

An API server (ceilometer-api) – rulează pe unul sau mai multe servere centrale pentru a permite acces dintr-un data store

Aceste servicii comunica utilizând OpenStack messaging bus. Numai colectorul și serverul API are acces pe data store.

4.2.8 OpenStack Orchestration

Modulul Orchestration oferă o orchestrație bazata pe template-uri pentru a descrie o aplicație cloud, rulând apeluri API pentru a genera aplicații ce rulează in cloud. Softul se integrează alte componente ale OpenStack într-un sistem one-file template. Template-urile permit utilizatorului sa creeze majoritatea componentelor OpenStack cum ar fi Instanțe, floating IPs, volume, grupuri de securitate și useri. Oferă și funcții avansate cum ar fi înalta disponibilitate pentru instanțe, auto-scaling

Serviciul permite administratorilor sa integreze direct împreuna cu modulul de orchestrare plugin-uri custom.

Modulul Orchestration are următoarele componente:

heat command-line client – un CLI ce comunica cu heat-api pentru a rula AWS CloudFormation APIs. Dezvoltatorii pot foloși direct REST API

heat-api component – o componenta nativa Openstack REST API ce procesează cererile API trimițând-le la motorul heeat prin Remote Procedure Call (RPC).

heat-api-cfn component – AWS Query API compatibil cu AWS Cloud-Formation. Procesează cererile API trimițându-le la motorul heeat prin Remote Procedure Call (RPC).

heat-engine – orchestrează lansarea template-urilor și returnează evenimente utilizatorului API

4.2.9 OpenStack Database

Serviciul database oferă o funcționalitate de provizionare cloud scalabila și eficienta pentru bazele de date relaționale și non-relaționale. Userii pot beneficia ușor și rapid de bazele de date fără a executa task-uri administrative complexe. Userii cloud și administratorii de baze de date pot proviziona baze de date multiple in funcție de nevoi.

Serviciul Database oferă izolarea resurselor și performanta de nivel înalt și automatizează task-uri complexe cum ar fi deployment, configurare, aplicare de patch-uri, backup, restore și monitorizare.

Serviciul Database include următoarele componente:

python-troveclient command-line client – un CLI ce comunica cu componenta trove-api

trove-api – oferă OpenStack-native RESTful API ce are suport pentru JSON pentru a proviziona și administra instanțele Trove

trove-conductor – rulează pe host și primește mesaje de la instanțele guest ce vor sa actualizeze informațiile pe host

trove-taskmanager – instrumentează sistemul de fluxuri complexe ce permite provizionarea instanțelor, administra ciclul de viată al acestora și executarea de operațiuni asupra instanțelor.

trove-guestagent – rulează in instanța guest. Administrează și executa operațiuni in baza de date.

4.2.10 OpenStack Data processing

Serviciul Data processing pentru OpenStack (sahara) are obiectivul de a oferi userilor o cale simpla de a proviziona clustere data processing (Hadoop, Spark) specificând câțiva parametrii cum ar fi versiunea Hadoop, topologie cluster, detalii hardware nod și alte câteva informații. După ce un user completează informațiile, Data processing implementează clusterul in câteva minute. Sahara oferă mijloace pentru a dezvolta clustere deja provizionate adăugând sau ștergând un nod worker la cerere.

Soluția se adresează următoarelor cazuri:

provizionarea rapida a clusterului Hadoop in OpenStack pentru dezvoltare și QA

utilizarea a puterii de calcul neconsumata de cloud-ul de uz general OpenStack IaaS

Analytics-as-a-Service pentru a utiliza ad-hoc sau bursty analytic workloads

Facilitați cheie sunt:

Proiectat ca o componenta OpenStack

Administrat prin intermediul REST API cu UI și parte a OpenStack Dashboard

Suport pentru diferite distribuții Hadoop:

System pluggable al instalarii Hadoop engine

Integrarea cu instrumente specifice de management, cum ar fi Apache Ambari sau Cloudera Management Console

Template-uri predefinite pentru configurațiile Hadoop cu abilitatea de a modifica parametrii

UI user-frendly pentru ad-hoc analytics querie bazate pe Hive sau Pig

Capitolul 5

Crearea unui laborator virtual in OpenStack

5.1 Creare proiect și utilizatori

În platforma OpenStack instanțele virtuale pot fi grupate în entitati numite „Projects”. Definirea unui laborator nou este sinonima cu crearea unui nou proiect.

Definirea unui laborator in platforma cloud Openstack se face astfel:

Ne logam in interfata web (dashboard) cu userul „admin” ce are rol de administrator

In sectiunea „Identity” alegem tab-ul „Projects” și apoi obtiunea din dreapta consolei „Create Project”

Apare fereastra de creare a unui nou proiect și completam cu numele proiectului și o scurta descriere a acestuia

Din tab-ul „Quota” se pot defini limitele pentru noul laborator, cum ar fi limita totala de procesoare virtuale, numarul de instante virtuale, numarul de volume, etc.

Dupa definirea proiectului vom crea userii ce au nevoie de acces la acest laborator. In sectiunea „Users” din „Identity” apasam butonul „Create User”

Apare fereastra de creare utilizator in care ii definim parola, numele de utilizator, adresa de email, proiectul la care este asignat și rolul in acesta

5.2 Conectare proiect nou

Dupa crearea utilizatorului și a proiectului putem face log in cu utilizatorul recent creat pentru accesarea noului laborator

Dupa logarea in aplicatie este afisat un panou cu o prezentare generala a resurselor disponibile

5.3 Definire retea interna

Primul pas in crearea unui laborator este definirea retelei interne. Mergem in sectiunea „Network Topology” din tab-ul Network pentru observa retelele definite deja. Dupa cum observam in imaginea de mai jos este definita doar reteaua externa care ne asigura comunicarea cu lumea exterioara

In pasul urmator vom defini o retea interna care va asigura comunicatia intre instantele virtuale din laborator. Pentru acest lucru apasam butonul „Create Network”

In fereastra nou aparuta alegem un nume pentru reteaua ce urmeaza a fi creata

Vom completa in fereastra următoare numele clasei și spatiul de adresare IP alocata acestei retele

In fereastra urmatoare vom defini ip-urile alocate prin DHCP și serverele DNS

Mergem din nou in sectiunea „Network Topology” unde observam aparitia retelei nou definita dar momentan este doar interna și nu comunica cu exteriorul. Pasul urmator il reprezinta definirea unui router virtual care va asigura aceasta legatura

In sectiunea „Routers” alegem optiunea „Create Router”

In fereastra de creare a unui router nou completam cu numele acestuia, alegem starea care in cele mai multe cazuri va fi UP și specificam rețeaua prin care va comunica cu exteriorul

Pasul urmator il reprezinta conectarea retelei interne la acest router. Click pe numele router-ului pentru editarea setarilor acestuia

In sectiunea „interfaces” click pe butonul „Add Interface”

Din fereastra „Add interface” specificam reteaua pe care dorim sa o conectam la router. Adresa IP se va completa automat cu gateway-ul retetelei

In sectiunea „Network Topology” putem observa legatura asigurata de noul router intre reteaua interna și cea externa

5.4 Creare instante virtuale

Pasul urmator in crearea unui laborator virtual il reprezinta crearea instantelor virtuale in sectiunea „Instances” din tab-ul „Compute”

Se apasa butonul „Launch Instance” pentru crearea unei instante virtuale noi. Se completeaza fereastra urmatoare cu numele, „Flavor” – ce defineste resursele de procesor, memorie și disk alocate masinii virtuale, numarul instantelor ce urmeaza a fi create cu aceleași setari, setarile de boot și imaginea ce va sta la baza instantei nou create

In zona tab-ul „Access & Security” se definesc cheile ssh necesare conectarii la o instanta. Imaginile importate direct de pe site-ul producatorului nu au o parola definita și este nevoie de definirea unei key publice pentru a ne putea conecta fara parola folosind protocolul ssh

Una din metodele pentru obtinerea acestor key publice este sa ne conectam la o masina ce are linux instalat. Daca nu exista folderul .ssh in directorul „home” al utilizatorului vom crea o noua cheie folosind utilitarul „ssh-keygen”. Vom lasa setarile implicite și este obtionala setarea unei parole pentru cheia publica

Vom copia cheia publica aflata in fisierul /home/ilie.ion/.ssh/id_rsa.pub și o vom importa in OpenStack apasand butonul + din dreptul „Key Pair” completam cu numele acesteia și cheia de mai sus in sectiunea „Public Key”, apoi apasam butonul „Import Key Pair”

Ne asiguram ca noua cheie a fost selectata

In tab-ul „Networking” setam reteaua interna in casuta „Selected networks”

In sectiunea „Post-Creation” se pot adauga script-uri ce pot fi executate dupa parcursul procesul de creare a unei instante

Iar in sectiunea „Advanced Options” se poate configura partitionarea disk-urilor virtuale

Dupa apasarea butonului „Launch” incepe procesul de creare a instantei

Dupa finalizarea procesului de creare se poate observa adresa de IP alocata și starea de „Running” a instantei

5.5 Asociarea IP extern unei instante

In acest moment masina virtuala are acces la exterior dar urilizatorii nu se pot conecta la aceasta, IP-ul alocat fiind dintr-o clasa izolata și este necesara alocarea unui ip extern numit „Floating IP”

Se alege optiunea „Associate Floating IP” și se aloca un nou ip apasand butonul „+” din fereastra

Se alege reteaua din care vom aloca IP

Se apasa butonul „Associate” pentru a aloca noul IP masinii virtuale

Se observa noul ip in coloana „IP Address”

Userii nu se pot conecta inca pentru ca regulile de securitate nu permit acest lucru. Se modifica „Security Group” implicit sau se creaza unul nou

se permite functia „ping” adaugand o regula „icmp” care sa permita sa raspunda cererilor din orice retea.

se adauga o regula pentru conectarea ssh

Se pot observa noile reguli create in grupul de securitate

5.6 Conectare instanta virtuala

Se testeaza faptul ca masina raspunde la ping și ne putem conecta prin ssh

Pe masina virtuala nou creata userii pot crea noi utilizatori pentru administrare

Se testeaza conectarea cu noul utilizator

O alta metoda de conectare o reprezinta sesiunea vnc din sectiunea „Console” a intantei

5.7 Terminarea unei instante

Terminarea unei instante se poate face in doua moduri, fie selectand instanta și apasand butonul „Terminate Instances” din coltul dreapta sus, fie din meniul „Actions” al masinii virtuale și alegand ultima optiune „Terminate Instance”.

Concluzii

Cloud Computing este din ce in ce mai prezent in viețile noastre, indiferent ca este vorba de salvarea unui fișier în Google Drive sau Microsoft OneDrive sau citirea unui email oferit de un serviciu public sau o companie provizioneaza un nou server in Amazon AWS sau iși instaleaza un nou private cloud bazat pe OpenStack. Cloud Computing a schimbat modul in care departamentele IT cumpara IT, acest lucru a fost incurajat și de conducerea companiilor care au inclinat catre costurile mai reduse fata de construirea de la zero a unei infrastructuri.

OpenStack este o platforma robusta, ajunsă la maturitate și capabilă să satisfacă aproape toate nevoile unei organizatii. Faptul că devine din ce in ce mai ușor de implementat datorită marilor furnizori care ofera tool-uri automate de deployment cum ar fi RDO de la RedHat, juju de la Ubuntu și ca beneficiaza de suportul marilor vendori din tehnologie propulseaza OpenStack in linia intai sa solutiilor de Cloud.

Bibliografie

Cloud Computing For Dummies – Judith Hurwitz, Robin Bloor, Marcia Kaufman, Fern Halper

Cloud Computing – Theory and Practice – Dan C. Marinescu

www.openstack.org

www.ibm.com

http://csrc.nist.gov – National Institute of standards and technology (Statele Unite)

http://blog.flux7.com

Bibliografie

Cloud Computing For Dummies – Judith Hurwitz, Robin Bloor, Marcia Kaufman, Fern Halper

Cloud Computing – Theory and Practice – Dan C. Marinescu

www.openstack.org

www.ibm.com

http://csrc.nist.gov – National Institute of standards and technology (Statele Unite)

http://blog.flux7.com