Dezvoltarea Si Implementarea Centrului de Date al Departamentului Aii – Solutie de Cloud Hibrid

Capitolul 1. – INTRODUCERE

Cloud Computing reprezintă un nou model de calcul ce vizează exigent multe probleme de securitate la toate nivelurile – rețea, gazdă, aplicații și date. Varietatea de modele de livrare cloud, prezintă provocări de securitate diferite în funcție de model și nevoile consumatorilor. Integritatea, disponibilitatea, autenticitatea, și confidențialitatea sunt preocupările esențiale atât pentru furnizorii de cloud, cât și pentru consumatori. Infrastructura ca un serviciu (IaaS) servește drept element de bază pentru alte modele de livrare, chiar și pentru un centru de date.

Centrele de date constituie o parte cheie a infrastructurii pe care o varietate de servicii din tehnologia informatiei sunt construite. Centre de date continua sa creasca in dimensiune si complexitate, de aceea este de dorit sa se inteleaga aspectele legate de designul lor, care sunt implementate masurile de monitorizare si de reportare, precum si ce neajunsuri si provocari ar trebui sa fie abordate.

Intreprinderile, de la cele mai mici pana la cele aflate deja in ascensiune, doresc sa isi poata accesa resursele de la distanta si sa garanteze utilizatorilor produselor/serviciilor lor o inalta calitate, cerinta ce devine cu atat mai importanta, cu cat dimensiunea departamentului creste. Accesarea locatiilor la distanta cuprinde propriile servere ale departamentului, iar accesul la se face printr-o retea locala.

Aceasta solutie garanteaza performanta aplicatiilor si inalta disponibilitate a acestora, ceea ce inseamna ca este nevoie de cat mai multe dispozitive de gestionare, crescand implicit si costurile totale. De asemenea, trebuie avute in vedere respectarea reglementarilor de arhivare a datelor, precum si asigurarea permanenta a accesului la resurse.

Centrele de date formeaza coloana vertebrala a unei game largi de servicii oferite prin intermediul internetului, inclusiv Web-hosting, comert electronic, retele sociale, precum si o varietate mai generala de servicii, cum ar fi software-ul ca serviciu (SAAS), platforma ca un serviciu ( PaaS ), si grid/cloud computing, sunt cateva exemple dintre aceste platforme de servicii generice, cum sunt Microsoft Azure , Google App Engine , platforma de EC2 Amazon si Grid Engine Sun.

Virtualizarea este cheia acestor platforme, oferind multe dintre aceste servicii. Tot virtualizarea este din ce in ce utilizata in centrele de date pentru a obtine utilizarea mai buna a serverelor si pentru alocarea resurselor in mod cat mai flexibil . Cu toate acestea, virtualizarea face, de asemenea, multe aspecte ale managementului centrului de date, mai dificile. Odata cu cresterea complexitatii, varietatea si de metode de intruziune a acestor servicii creste, centrele de date continuand sa se dezvolte, iar necesitatea obtinerii unui centru de date cat mai sigur este un obiectiv din ce in ce mai greu de indeplinit, dar esential.

Modelarea peisajului centrului de date sau data center design, trebuie sa ia in calcul faptul ca odata cu cresterea data centerelor e nevoie de si mai multe dispositive, si trebuie sa ne asteptam ca centre de date in viitor sa fie versiuni mult mai mari ale celor existente astazi. Aflate in curs de dezvoltare. Tendintele in ceea ce priveste centrele de date se asteapta sa transforme centrele de date in centre de data distribuite, virtualizate, cu infrastructura multi- stratificata care prezinta o varietate de provocari dificile.

Situatia descrisa nu se aplica doar pentru companii, ci si la nivel de department al unei institutii, cum este si cazul departamentului Automatica si Informatica Industriala, din cadrul Facultatii de Automatica si Calculatoare.

Conținutul lucrării

O sinteză cu caracter de specificații funcționale a ceea ce se va implementa ca și suport practic al lucrării de față se poate formula astfel: ”Se dorește proiectarea unei platforme cloud cu rol de centru de date al departamentului de Automatică și Informatică Industrială al facultății de Automatică și Calculatoare, al Universității Politehnica din București. Soluția proiectă va beneficia de elemente de securitate, de management al utilizatorilor și de scalabilitate, putând asimila cu succes toate elementele ce fac posibilă funcționarea ca și centru de date securizat, scalabil și viabil”.

În acest sens, capitolul 2 al lucrării – Analiza de sistem, abordează aspecte teoretice cu privire la centrele de data, semnificația acestora, cum sunt utilizate și ce anume trebuie să conțină, care este relevanța planificării proiectării lor precum și noțiuni generale privind tehnologiile și uneltele de dezvoltare software/hardware de care un centru de data are nevoie pentru a funcționa, urmând astfel specificațiile minimale ale prezentei lucrări.

Capitolul 3 – Tehnologii și soluții cloud utilizate, descrie în manieră teoretică și totodată argumentativă necesitatea tehnologiilor prezente în aplicația software finală, precum și rolul fiecărei tehnologii în dezvoltarea și implementarea unei soluții de cloud hibridă, din cadrul departamentului AII. Capitolul începe cu studiul a două platforme distincte, ce au constituit suportul pentru demerarea temei, incluzând și noțiuni teoretice de management al utilizatorilor, de securizare și principii de dezvoltare ale unui centru de date, și servește drept suport teoretic fundamental în ceea ce privește noțiunile cu care se va opera în prezenta lucrare, și implicit ajută la obținerea soluției finale.

Capitolul 4 – Proiectarea centrului de date, structurează în manieră logică toate operațiile necesare dezvoltării și implementării unui centru de date pe platforma Microsoft Windows Azure, pornind cu un model de arhitectură pentru ceea ce se dorește a fi dezvoltat, și detaliind pașii prin care s-au configurat mașinile virtuale folosite.

Capitolul 5 – Implementarea centrului de date, oferă atât o imagine teoretică cât și preponderent practică asupra a ceea ce s-a realizat în lucrare și descrie în detaliu fiecare pas parcurs în vederea obținerii soluției finale. Se va ține cont de modul de funcționare al centrului de date, de elementele de arhitectură folosite, de modul în care se va face virtualizarea, cum anume comunică serverele, de managementul utilizatorilor, încercându-se interfațarea a mai multor tipuri de servere cu mașina virtuală centrală. Este important să analizăm în acest capitol, cum interacționează mașinile virtuale ca și părți funcționale independente cât și ca întreg. De aceea, este absolut necesară configurarea fiecărei mașini virtuale, prin respectarea unor reguli de securitate. Acesta este cu siguranță cel mai complex capitol al lucrării, deoarece acoperă pe lângă noțiunile teoretice din capitolele anterioare, și elemente de funcționare ale centrului de dte dezvoltat pe platforma Windows Azure, cât și capturi de ecran sugestive cu pașii urmați ăn configurare, rezultate ale implementării centrului de date dar și detalii asupra rezultatului final, găzduit în cloud, nefiind necesară astfel o infrastructură hardware costisitoare pentru departamentul AII.

Capitolul 6 – Testarea și integrarea serverelor, este structurat pe două subcapitole, anume subcapitolul de testare, și cel de integrare. Scopul fiecărui subcapitol este de a prezenta, la nivel exemplificativ, minimal, cum anume se realizează funcțiile fiecărei mașini virtuale, și se analizează în ce măsura s-a realizat un centru de date conform cu specificațiile inițiale prevăzute.

Capitolul 7 – Dezvoltări viitoare și concluzii, prezintă în maniera subiectivă a autorului rezultatele obținute, și oferă perspectivele de dezvoltare ale arhitecturii încercate. Se va ține cont de validarea rezultatelor disertației, și de un punct de vedere personal, argumentat, în ceea ce privește soluția prezentată de întreaga lucrare.

1.2. Motivatia alegerii temei

Implementarea unui centru de date într-o structură de tip cloud, a devenit și ea o soluție de afacere care oferă numeroase beneficii referitoare la funcțiile pe care centrul de date trebuie să le îndeplinească. Centrul de date găzduiește serverele și aplicațiile pe care clienții le utilizează. Structura de centru de date în cloud reduce cheltuielile de capital, deoarece soluția utilizării unui cloud private opensource a devenit din ce în ce mai accesibilă. Fiecare operator de cloud are propriile funcții hardware care permit executarea operațiunilor unui centru de date. Exemple ar fi XenServer, NetScaler și universalul Citrix. Însă, manipularea hardware poate deveni problematică în transferul datelor sau din cauza limbajelor de programare folosite.

Scopul temei este acela de a explora resursele software si hardware puse la dispozitie atat de produce outsource cat si de facultate, pentru a implementa un astfel de centru de date care sa asigure toate aspectele mentionate in paragrafele anterioare. Necesitatea implementarii si dezvoltarii unei politici de securitate intr-un data center, provine din necesitatea departamentului AII de a-si centraliza resursele astfel incat sa asigure centralizarea acestora si o mai buna administrare a resurselor. Proiectul de cercetare adreseaza in primul rand aspectele teoretice ale implementarii unui data center, propunand si cateva solutii software/hardware existente, ce ar putea fi valorificate in produsul final.

Obiectivul final al prezentei lucrari este de a oferi o solutie de implementare de tip cloud privat, de tipul Platforma ca și Serviciu (PaaS), pentru centrul de date al Departamentului de Automatica și Informatica Industriala al Facultatii de Automatica și Calculatoare, UPB, București.Solutia aleasa este cea oferita de Windows Azure Platform, dupa ce initial s-a incercat o implementare pe platforma Apache Cloud Stack. Atat asupra Apache cat si asupra solutiei Microsoft s-au analizat nevoile de proiectare și securizare a centrului de date, analizand resursele disponibile pe care fiecare dintre platforme le ofera pentru implementarea unui centru de date în cloud, secuizat.

Alegerea temei a reprezentat o provocare pentru mine, pe care am fost dispus să o înfrunt, convins fiind de capacitatea mea de a învața și de ambiția mea de a reuși.

Consider că tema pentru care am optat, deși nu mi s-a potrivit în totalitate, și deși au existat numeroase impedimente legate de buget, fiind necesară o licență adecvată de Windows Azure pentru unele elemente mai complexe ce s-ar fi putut realizat, am reușit să exemplific modul în care, o soluție de cloud hibrid poate fi adoptată pentru un centru de date personalizat, în raport cu nevoile de bază ale departamentului.

1.3. Istoricul activitatii de cercetare

1.3.1. Semestrul I

Inceperea activitatii de cercetare s-a axat in principal pe stabilirea unor linii directoare in cercetare, astfel incat sa se asigure o buna cunoastere a activitatii ce a urmat in proiectarea si securizarea unui centru de date. Printre aspectele studiate la nivel teoretic in incursiunea in cercetare, s-au vizat:

– Studiul implementarii unui centru de date

– Stabilirea obiectivelor, studiul domeniului și alegerea software-urilor ce vor fi utilizate in lucrare

– Organizarea unui centru de date si probleme identificate

– Principii de proiectare, componente ale unui centru de date

– Inalta disponibilitate, managementul de risc, audit, disaster recovery, virtualizare

1.3.2. Semestrul II

Semestrul al doilea al cercetarii s-a axat pe studiul modelului teoretic al sunor solutii de cloud computing care sa permita simularea virtualizata a unor masini care sa joace roluri atribuite in cadrul unui centru de date. S-a reusit instalarea partiala a solutiei Apache Cloudstack Solution, insa considerente legate de notiuni practice de linux, au impiedicat implementarea cu succes a stivei centrului de date. S-a obtinut la nivel de baza instalarea interfetei utilizator pe o masina virtuala de CentOS 6.4.

Aspecte vizate in cercetare:

– Studiul și alegerea utilitarelor ce vor fi folosite pentru dezvoltarea studiului de caz;

– Studiul platformei cloud open-source Apache Cloudstack;

– Instalarea si configurarea interfetei de management al utilizatorului pentru centrul de date pe o masina CentOS 6.4

1.3.3. Semestrul III

In semestrul al III-lea s-au studiat aspecte teoretice ale solutiei Windows Azure, ca solutie de cloud computing alternativa la Apache Cloudstack Solution. S-a incercat si reusit conectarea la platforma Azure, instalarea si configurarea prin intermediul platformei si la nivel local, al masinilor virtuale a centrului de date. S-au construit doua masini virtuale, AIIDC1 cu rol de data center si masina virtuala appsserver1 cu rol de server pentru aplicatiile web ale departamentului (site prezentare etc.), si s-au configurat prin intermediul Server Manager aceste masini virtuale, accesate printr-o conexiune remote. Nu s-a reusit comunicarea dintre masinile virtuale, contul folosit fiind unul trial subscription, si DNS-ul creat nefiind inregistrat.

Aspectele vizate in prezenta lucrare prin studiul platformei Windows Azure, sunt urmatoarele:

– Alegerea platformei Windows Azure pentru implementarea centrului de date;

– Instalarea si configurarea interfetei de management prin intermediul portalului web Windows Azure

– Construirea unei masini virtuale Windows Server 2012 R2 OS – instalarea si configurarea sa pentru acces remote

– Construirea unei retele virtuale prin intermediul masinii AIIDC1

– Crearea unei VM pentru a rula rolurile controler de domeniu și Server DNS

– Instalarea Windows Server Active Directory

– Setarea serverului DNS pentru reteaua virtuala Azure

– Crearea de masini virtuale pentru membrii de domeniu

1.3.4. Semestrul IV

Pentru finalizarea lucrarii, voi avea in vedere:

– implementarea functionalitatilor de server de aplicatii, mail, server stocare date

– crearea de servere virtualizate care sa se conecteze la data center

– implementarea unor politici de securitate cloud – firewall, managementul utilizatorilor, vpn

– rularea serverelor pe serverul DNS

Capitolul 2. – ANALIZA DE SISTEM

2.1 Analiza sistemelor de tip centru de date folosind arhitecturi cloud computing

Cloud Computing reprezinta un nou model de calcul ce vizeaza exigent multe probleme de securitate la toate nivelurile – retea, gazda, aplicatii si date. Varietatea de modele de livrare cloud, prezinta provocari de securitate diferite in functie de model si nevoile consumatorilor. Integritatea, disponibilitatea, autenticitatea, si confidentialitatea sunt preocuparile esentiale atat pentru furnizorii de cloud, cat si pentru consumatori. Infrastructura ca un serviciu (IaaS) serveste drept element de baza pentru alte modele de livrare, chiar si pentru un centru de date. Alegerea celui mai potrivit furnizor de servicii cloud nu este usoara. Vorbind in general despre serviciile de infrastructura, e clar ca deciziile de alegere a furnizorilor trebuie sa fie rezultatul unui lung si complex proces de analiza.

Implementarea unui centru de date intr-o structura de tip cloud, a devenit si ea o solutie de afacere care ofera numeroase beneficii referitoare la functiile pe care centrul de date trebuie sa le indeplineasca. Centrul de date gazduieste serverele si aplicatiile pe care clientii le utilizeaza. Structura de centru de date in cloud reduce cheltuielile de capital, deoarece solutia utilizarii unui cloud private opensource a devenit din ce in ce mai accesibila. Fiecare operator de cloud are propriile functii hardware care permit executarea operatiunilor unui centru de date. Exemple ar fi XenServer, NetScaler si universalul Citrix. Insa, manipularea hardware poate deveni problematica in transferul datelor sau din cauza limbajelor de programare folosite.

Mediile competitive de afaceri au pus presiune asupra managerilor firmelor de IT, care trebuie sa raspunda unor provocari din ce in ce mai mari, de-a lungul timpului. Bugetul fiind acelasi, nevoia de flexibilitate, competitivitate, si adaptabilitate la conditiile pietei, au fortat managerii sa gaseasca noi solutii mai eficiente si mai ieftine din punct de vedere al costurilor decat cele detinute. Odata cu aceasta evolutie, nu doar organizatiile sunt cele care trebuiesc sa se adapteze, ci si institutiile publice, in cazul nostru, un department al unei facultati sau un department al unei structuri din stat. Pe cand Amazon sau Google ofereau servicii de cloud, nimeni nu se gandea sa vanda cloud. Pe piata IT actuala, cloud-ul a devenit deja o tendinta, furnizorii de cloud fiind din ce in ce mai multi.

Centrele de date constituie o parte cheie a infrastructurii pe care o varietate de servicii din tehnologia informației sunt construite. Centre de date continuă să crească în dimensiune și complexitate, de aceea este de dorit să se înțeleagă aspectele legate de designul lor, care sunt implementate masurile de monitorizare si de reportare, precum și ce neajunsuri și provocări ar trebui să fie abordate.

Intreprinderile, de la cele mai mici pana la cele aflate deja in ascensiune, doresc sa isi poata accesa resursele de la distanta si sa garanteze utilizatorilor produselor/serviciilor lor o inalta calitate, cerinta ce devine cu atat mai importanta, cu cat dimensiunea departamentului creste. Accesarea locatiilor la distanta cuprinde propriile servere ale departamentului, iar accesul la se face printr-o retea locala.

Aceasta solutie garanteaza performanta aplicatiilor si inalta disponibilitate a acestora, ceea ce inseamna ca este nevoie de cat mai multe dispozitive de gestionare, crescand implicit si costurile totale. De asemenea, trebuie avute in vedere respectarea reglementarilor de arhivare a datelor, precum si asigurarea permanenta a accesului la resurse.

Centrele de date formează coloana vertebrală a unei game largi de servicii oferite prin intermediul internetului, inclusiv Web-hosting, comert electronic, rețele sociale, precum și o varietate mai generală de servicii, cum ar fi software-ul ca serviciu (SAAS), platforma ca un serviciu ( PAAS ), și grid/cloud computing, sunt câteva exemple dintre aceste platforme de servicii generice, cum sunt Microsoft Azure , Google App Engine , platforma de EC2 Amazon și Grid Engine Sun.

Virtualizarea este cheia acestor platforme, oferind multe dintre aceste servicii. Tot virtualizarea este din ce în ce utilizata în centrele de date pentru a obține utilizarea mai bună a serverelor și pentru alocarea resurselor in mod cat mai flexibil . Cu toate acestea, virtualizarea face, de asemenea, multe aspecte ale managementului centrului de date, mai dificile. Odata cu cresterea complexitatii, varietatea și de metode de intruziune a acestor servicii creste, centrele de date continuand sa se dezvolte, iar necesitatea obtinerii unui centru de date cat mai sigur este un obiectiv din ce in ce mai greu de indeplinit, dar esential.

Modelarea peisajului centrului de date sau data center design, trebuie sa ia in calcul faptul ca odata cu cresterea data centerelor e nevoie de si mai multe dispositive, și trebuie sa ne așteptăm ca centre de date în viitor să fie versiuni mult mai mari ale celor existente astăzi. Aflate in curs de dezvoltare. Tendințele in ceea ce priveste centrele de date se așteaptă să transforme centrele de date în centre de data distribuite, virtualizate, cu infrastructura multi- stratificata care prezintă o varietate de provocări dificile.

Situatia descrisa nu se aplica doar pentru companii, ci si la nivel de department al unei institutii, cum este si cazul departamentului Automatica si Informatica Industriala, din cadrul Facultatii de Automatica si Calculatoare.

2.2. Organizarea centrului de date și probleme identificate

2.2.1. Organizarea fizică la nivel de Rack

Un centru de date este, în general organizat în rânduri de rafturi, unde fiecare raft conține active modulare, cum ar fi servere, switch-uri, ''cărămizi de depozitare", sau dispozitive specializate.

Un suport standard este 78 inch inaltime, 23-25 ​​inch latime și 26-30 inch adâncime. De obicei, fiecare suport are un număr de suporturi modulare (active montate) introduse orizontal în rafturi. Grosimea activa este măsurată cu ajutorul unei unitati numita U, care este de 45 mm (sau aproximativ 1.8 inch). O majoritate covârșitoare de servere sau procesoare duble de socket se pot potrivi unui rand cu dimensiunea de 1U, dar cele mai mari pot solicita 2U sau mai multe.

Un suport standard poate să ia un total de 42 de unitati active de 1U atunci cand este complet umplut. Gradul de sofisticare al rackului în sine poate varia foarte mult – în cel mai simplu caz, nu este nimic mai mult mult de o carcasă metalică. Funcțiile suplimentare pot include rackul de distribuție a energiei electrice, built-in KVM (tastatură-video, mouse-ul) comutator, la nivel de rack sistem cu aer sau răcire cu lichid, și, probabil, chiar și o unitate de management la nivel de rack.

Pentru o si mai compacta funcționalitate, serverele pot fi găzduite într-un șasiu de sine stătător. care se depoziteaza în rack. Un șasiu vine cu propriile sale sisteme de alimentare, ventilatoare, cablurile de interconectare , și de gestionare a infrastructurii. Șasiul oferă dimensiuni standard pentru sloturi în cazul în care s-ar putea introduce active modulare (de obicei, cunoscute sub numele de lame). Un singur șasiu poate stoca până la 16X1U servere, oferind astfel o capacitate teoretică a raftului de 96 de active modulare.

Creșterea substanțială a densității serverului este realizabila prin utilizarea rezultatelor unei astfel de lame pentru creșterea corespunzătoare a consumulului de putere per rack, care la rândul său, poate impozita serios infrastructura de putere de livrare.

În special, mai multe centre de date mai vechi sunt proiectate sa suporte o putere de 7 KW per-rack, în timp ce rafturile încărcate cu servere blade s-ar putea apropia de 21 K.

Există o problemă similară în ceea ce privește densitatea termică -infrastructura de raciere ar putea fi în imposibilitatea de a gestiona asptectele termice oferite la încărcare. Rezultatul este ca rackurile nu pot fi incarcate corespunzator la deplina lor capacitate.

Figura 1 – Organizarea fizică a unui centru de date

2.2.2. Infrastructura de retea si stocarea datelor

Modulul de stocare al centrelor de date poate fi furnizat in mai multe moduri. De cele mai multe ori, inalta performanta a modulului de stocare este asigurata, cand modulul de stocare este gazduit in dispozitive de depozitare speciale, care permit accesul de la distanta, facand abstractie de dispozitivele de stocare utilizate. O alta varianta pentru modulul de stocare al datelor este sa fie inglobat in interiorul rack-ului si integrate direct cu serverele. In ambele cazuri, accesul eficient la retea este esential.

Un centru de date necesită de obicei, patru tipuri de accese de rețea, și ar putea folosi eventual patru tipuri diferite de rețele fizice. Rețeaua client-server oferă acces exterior in centrele de date, și în mod necesar foloseste o tehnologie, cum ar fi Ethernet, cu fir, sau wireless, LAN.

Rețea server-la-server oferă o mare viteză la comunicarea între servere și poate folosi Ethernet, InfiniBand (IBA) sau alte tehnologii. Accesul de modulul de stocare a fost în mod tradițional furnizat de fibra optica, dar ar putea folosi, de asemenea, o retea Ethernet sau InfiniBand. În cele din urmă, rețeaua folosită pentru management este, de asemenea, Ethernet, dar poate utiliza fie o cablare separate fata de reteaua de baza.

Ambele rețele de masă și de stocare urmează de obicei o configurație identică. Pentru serverele blade montate pe un șasiu, șasiul oferă un comutator prin care toate serverele din șasiu se pot conecta la serverele din afara. Switch-urile sunt duplex pentru fiabilitate și pot fi aranjate pentru schimbul de sarcină, atunci când ambele switch-uri sunt in lucru. Cu scopul de a menține rețeaua usor de gestionat, topologia generală este de fapt un copac cu conectivitate completă la nivel de rădăcină.

De exemplu, fiecare comutator de nivel șasiu (sau nivelul 1) are un uplink care duce la comutatorul de nivel 2, astfel încât comunicarea între cele două servere în diferite puncte ale șasiului trebuie să treacă prin cel puțin trei comutatoare.

În funcție de mărimea centrului de date, la nivel multiplu, 2 switch-uri pot fi fie conectate într-o plasă completa, sau pot trece prin una sau mai multe switch-uri de nivel 3. Cea mai mare problemă cu o astfel de structură este o potențiala nepotrivire a lățimii de bandă la niveluri mai ridicate. În general, uplink-urile sunt proiectate pentru un raport de suprasubscriere specific, deoarece oferă o lățime de bandă completă, împărțita în două, ceea ce nu este de obicei posibil.

De exemplu, 20 de servere, fiecare cu un GB/s Ethernet 1 poate partaja un singur uplink 10GB/s Ethernet pentru un raport de suprasubscriere de 2,0. Acest lucru poate fi supărător în cazul în care volumul de muncă creste, astfel că există o comunicare non-locala substanțiala.

Din moment ce modulul de stocare este prevăzut în mod tradițional într-un turn de depozitare separat, tot traficul de stocare trece, de obicei, de la uplink-ul șasiului pe rețeaua de stocare. Cu cat centrele de date cresc in dimensiuni, o arhitectură de rețea mai scalabilă devine necesară.

2.2.3. Infrastructura de management

Fiecare server are, de obicei, un controler de management numit BMC (controlor de gestiune baseboard). Rețeaua de management se termină la BMC pentru fiecare server. Când rețeaua de management este implementata ca o ''rețea laterală", nu sunt necesare switch-uri suplimentare pentru aceasta, în caz contrar, un comutator de management este necesar în fiecare șasiu/raft pentru a sprijini comunicarea externă.

Funcțiile de bază ale BMC includ monitorizarea diferitilor senzori hardware, gestionarea diverse alerte hardware și software, pornirea și oprirea serverului, menținerea datelor de configurare ale diverselor dispozitive și drivere, precum și furnizarea de capabilități de management de la distanță. Fiecare șasiu sau raft, isi poate însuși propriul controler de management de nivel superior care comunică cu controlerul de nivel inferior.

Gestionarea configurației este un termen destul de generic și se poate referi la managementul setărilor parametrilor a mai multor obiecte , care sunt de interes în utilizarea în mod eficient a infrastructurii sistemului informatic, de la dispozitivele individuale până la servicii complexe care rulează pe grupuri mari în rețea. Acest lucru este adesea cunoscut ca out-of -band management (OOB), deoarece aceasta se face fără implicarea procesorului principal sau fara implicarea sistemului de operare. Alte activități pot fi mai adecvate pentru gestionarea în- bandă și pot fi efectuate de către procesorul principal în hardware, SO, sau în middleware.

Managementul de nivel superior poate rula pe sisteme separate care au atât gestionare în bandă cat si interfețe OOB. Pe un server , funcțiile cele mai critice OOB aparțin etapei de pre-boot. O alta functie a OOB este evidenta în monitorizarea sănătății serverului în timp ce sistemul de operare se execută. Pe alte active modulare, cum ar fi switch-uri, routere, și brick-uri, este necesar un sistem de management OOB .

2.2.4. Infrastructura electrica si de racire

Chiar și centre de date mijlocii pot sporta consumul de putere de vârf de mai multi megawați sau mai mult. Pentru astfel de sarcini de putere, devine necesar sa furnizam putere electrica folosind linii de înaltă tensiune (de exemplu, 33 KV, 3 faze) in intervalul de 280-480 de rutare, prin sursa de alimentare neîntreruptă (UPS). Unitatea UPS are nevoie sa converteasca curentul alternative in current continuu pentru a-si încărca bateriile și apoi pentru a converti la curentul alternativ in current continuu, la capătul de ieșire.

Deoarece unitatea UPS stă direct în calea de alimentare, ea poate continua să furnizeze energie de ieșire neîntreruptă în cazul unei intreruperi de electricitate.

2.5. Planificarea implementarii unui centru de date in cloud

Centrele de date sunt medii de lucru specializate pe securitate, si totodata cele mai de pret proprietati intelectuale ale unor companii, departamente etc.

Un centru de date serveste drept camera de gazduire pentru procesele desfasurate in interiorul unui departament sau ale unei companii si are urmatoarele functii:

Proceseaza tranzactiile departamentului

Gazduieste website-ul si aplicatiile departamentului

Proceseaza si stocheaza proprietatea intelectuala

Mentine date financiare, date de natura legala sau de interes pentru persoanele din interior si din exterior care trebuiesc departajate pe fisiere la care sa existe un management de acces bazat pe drepturi sau pe grupuri de invivizi cu privilegii in functie de rolul ocupat in interiorul departamentului

Ruteaza emailurile personalului din organizatie/ departament

In esenta, un centru de date reprezinta creierul departamentului.

Printre obiectivele principale ale prezentului raport, se numara:

Alegerea unei politici de implementare, in raport cu cerintele departamentului

Construirea unui design corespunzator pentru centrul de date

Particularizarea mediului in raport cu cerintele departamentului

Organizarea si managementul centrului de date in maniera efectiva, astfel incat sa se asigure buna functionare a serverelor, a serviciilor si a aplicatiilor, iar evenimentele neprevazute de natura sa pericicliteze aceasta inalta disponibilitate, sa fie minimizate, iar timpul de reparare al intregii infrastructuri sa fie cat mai mic.

2.5.1. Determinarea cerintelor si atribuirea rolurilor

Necesar un centru de date care sa gazduiasca toate aplicatiile si serverele departamentului

Data center-ul trebuie sa asigure buna functionare a serviciilor si a serverelor in orice moment

Trebuie sa raspunda cerintelor de proiectare a unui data center, prin raportare la normele existente, la siguranta in functionare si la cerintele de proiectare

Ne intereseaza gazduirea de servere pentru serviciul de mail intern, pentru aplicatiile web ale departamentului, pentru stocarea datelor etc.

Ne intereseaza securizarea aplicatiilor astfel incat intregul centru de date sa fie rezistent intruziunilor de orice tip

Ne intereseaza principii legate de robustete, modularizare si flexibilitate a serviciilor, fiind totodata standardizate, conforme cu norme existente si aplicabile.

2.5.2. Robustețea centrului de date

Mai presus de toate, Data Center-ul trebuie să fie de încredere. Motivatia generala a acestei conditii este protejarea echipamentelor și aplicațiilor, conditie cea mai critică departamentului. Indiferent de ceea ce se întâmplă (catastrofe, dezastre) data center-ul trebuie sa continue să funcționeze.

Infrastructura Data Center trebuie să aibă profunzime: sursele de alimentare atunci când energia electrică comerciala nu reușește sa asigure un minim necesar, stațiile de rețea redundante trebuie sa faca față nevoilor de comunicare, reteaua trebuie sa funcționeze corespunzător.

Infrastructura trebuie să fie configurata astfel încât sa nu existe o singură componentă sau caracteristică care o poate face vulnerabilă. Cel mai bine este să aibă sisteme de putere de a asteptare mai multe în cazul în care sunt toate sursele cu fir dintr-un singur circuit nu mai functioneaza, sau sa aiba mai multe conexiuni de date redundante dacă cablu lor de alimentare intra în clădire printr-o singură locație.

În ambele exemple, o defecțiune la un singur punct poate aduce intreaga infrastructura a Data Center-ului la stadiul de deconectat.

2.5.3. Modularitatea centrului de date

Data center-ul nu trebuie sa aiba numai o infrastructura solida, dar trebuie avute in vedere separarea serverelor pe rack-uri astfel incat sa se asigure necesarul de putere, o racire corespunzatoare a tuturor serverelor, putere de operare a datelor, etc.

Sistemul trebuie construit avand in vedere un plan logic, pentru ca atunci cand orice eveniment inpredictibil apare, prizele suficiente, conexiunile existente si porturile de date sa poata sprijini arhitectura intreaga a centrului de date.

Pentru a realiza aceasta infrastructură uniformă, de design, se imparte camera în segmente interschimbabile.

Locatiile din interiorul fiecarui dulapior, au infrastructura identica, iar aranjarea serverelor se face in ordine, in randuri identice.

Modularitatea bazata pe aceasta partitionare, face ca infrastructura centrului de date sa fie simpla si scalabila. De asemenea, trebuie sa facem referire la principiul redundantei mentionate si la robustete, care face posibil ca extinderea data center-ului sa se desfasoare prin simpla conectate a modulelor suplimentare si sa nu se afecteza infrastructura existenta pana la acel moment.

2.5.4. Flexibilitatea centrului de date

Este sigur să se presupună că dispozitivele de stocare routere, switch-uri, servere, și datele vor avansa și se vor schimbara în anii următori. Ele pot deveni mai mici sau mai mari.

Centrele de date nu sunt statice, astfel incat infrastructura lor nu ar trebui să fie nici ea statica. Trebuie sa se execute o proiectare care sa permita flexibilitate, ceea ce presupune sa construim sisteme de infrastructură, folosind componente care sunt usor de schimbat sau mutat.

Infrastructura inflexibila duce in mod invariabil la mai multe cheltuieli ulterioare.

2.5.5. Standardizarea data centerului

Data Center-ul treubuie sa fie un mediu consistent. Aceast lucru oferă stabilitate pentru servere și echipamentele de retea pe care centrul de date le adaposteste, și crește posibilitățile de utilizare. Trebuie cautat un model de implementare standard care sa asigure functiile vizate prin construirea data centerului fara a fi tentati sa experimentam elemente de design sau prea inovative. Astfel evitam ca, in eventualitatea aparitiei unei defectiuni, cel care se ocupa de acest centru sa nu faca o greseala care cel mai probabil ar defecta si mai mult componentele decat sa le repare.

2.6. Principii de proiectare ale unui centru de date

Exista numeroase publicatii si politici care mentioneaza forme diverse de implementare a unui centru de date, fiecare dintre ele cautand un anume aspect pe care il doresc sa il asigure. Unele infrastructuri se orienteaza spre design, altele spre functionalitate, ramanand la decizia proiectantului modalitatea in care planifica infrastructura, mizand mai degraba pe functionalitate, sau mai degraba pe design.

Precum am mentionat si in capitolul anterior, este necesar ca centrul de date sa asigure functionalitatea, data de cerintele de proiectare.

Sintetizand aspectele esentiale de functionare a data centerului proiectat, enumar cateva principii de proiectare pe care le consider de luat in seama si anume:

Asigurarea accesibilitatii lucrurilor – Utilizatorii trebuie sa-si poata executa munca, si sa dispuna de toate elementele necesare muncii lor – inalta disponibilitate a serviciilor, serverelor, aplicatiilor etc..

Alegerea unei infrastructuri intuitive, simple – astfel incat lucrurile stau clar in viziunea oricarui administrator, iar greselile de administrare sau repararea unor defectiuni sa se asigure cu timp minim si mai ales corect.

Evitarea neclaritatilor/misterelor – Dacă există o șansă cineva s-ar putea să nu înțeleagă un element al unui centru de date, se adaugă o formă scris cu instrucțiuni – de exemplu se folosesc leduri de semnalizare, etichetarea rack-urilor, sau chiar hărți ale centrului de date.

In acest sens, proiectarea arhitecturii unui data center, ar trebui sa asigure:

Disponibilitatea centrului de date – Disponibilitatea este reprezentata ca un procent de timp. Câte zile, ore, minute este infrastructura operațională pe o anumită perioadă de timp. Cu cat disponibilitatea se doreste a fi mai mare, cu atat trebuie implementata o infrastructura ierarhizata, pe mai multe straturi. Capacitatea unei infrastructuri e considerata de capacitate maxima N, presupunand ca spatiul centrului de date este ocupat complet si ca toate dispozitivele functioneaza.

Ownership – se refera la persoana sau departamentul care administreaza data centerul si care dispun de control total asupra infrastructurii fizice, proceselor si serviciilor existente.

Responsability – principii precum separarea atributiilor, managementul utilizatorilor, privilegiile acordate (individuale si de grup) fac referire la responsabilitate

Access / Access Control – controlul accesului trebuie realizat permanent pentru a securiza centrul de date si a identifica posibile atacuri si este legata direct de responsabilitate.

Security & Privacy – securitatea si siguranta datelor sunt elemente critice ale data centerului. La asigurarea acestora, trebuie avute in vedere toate riscurile posibile, cat si asigurarea tuturor elementelor mentionate mai sus.

2.6.1. Componentele unui data center

Un centru de date de baza, ofera urmatoarele sisteme de facilitati:

Spatiu fizic – camera de lucru a serverelor

Partea electrica

Puterea de functionare in regim de standby

Cablarea

Sisteme de ventilatie si racire

Sisteme de preventie in caz de incendii

Rack-ul de servere

Vom analiza pe rand, fiecare dintre aceste elemente:

Spațiu fizic se referă la camera in care toate elementele constitutive ale centrului de date sunt amplasate. Spatiul fizic reprezinta în general suprafața totală a centrului de date și spațiile asociate , cum ar fi camerele electrice sau zonele de depozitare. Pe o scară mai mică, acest lucru s-ar putea referi la dimensiuni cheie în cadrul Centrului de date, cum ar fi măsurătorile externe ale unui dulap de servere sau la culoarele de patrundere printre acestea in cazul existentei a mai multor dulapuri.

Dulapul de servere trebuie sa nu fie fixat direct pe podeaua spatiului fizic. Sistemul de podele ridicate este un sistem grilă ridicat, care este frecvent instalat în marile centre de date. Racirea cu aer conditionat, prizele electrice, cablurile de date sunt rutate prin spatiul de sub podeaua ridicată. Astfel se realizeaza o mai buna aerisire a dulapului de servere, se gestioneaza mai usor alimentarea serverelor, se pot amplasa conducte de apă, cilindri pentru a suprima un eventual incendiu, detectoare de umiditate, și detectoare de fum de asemenea .

Partea electrica se referă la toate facilitățile legate de energie în cadrul centrului de date. Aceasta include în mod normal tablouri electrice , conducte, și mai multe tipuri de recipiente. Puterea de la acest sistem , de obicei, vine de la o sursă externă de energie comercială, și anume compania de utilități locale, și este probabil condiționata de furnizorul de energie electrica cu care departamentul lucreaza. Tensiune variază de la o țară la alta. In mod standardizat fibra optica va fi alimentate la 380V, in camera centrului de date folosindu-se prize de aimentare cu o tensiune de 220V.

Starea de repaus include toate sistemele de alimentare de rezervă responsabile pentru susținerea sarcinii electrice a centrului de date în cazul în care puterea de utilitate normală nu este disponibile dintr-un anume motiv. Acest sistem include în mod tradițional baterii de mari dimensiuni, cunoscute ca o sursă de alimentare neîntreruptibilă (UPS-uri) sau sursă de alimentare neîntreruptibilă, și unul sau mai multe generatoare.

Cabluri din cupru și fibra optica sunt elemente de cablare tipice și sunt terminate prin mai multe tipuri de conectori. Componente comune includ carcase de fibre, patch panel-uri, cutii multimedia, si fatete de date. Dulapurile, bazinele de creștere, și alte elemente sunt utilizate pentru a ruta cablarea si sunt considerate ca făcând parte din sistemul de cablare .

Sistemul de răcire se referă la agregatele de răcire și de stivuitoare de aer folosite pentru a regla temperatura ambiantă și umiditatea de control în cadrul centrului de date. Acest sistem ar putea integra sistemul de aer condiționat folosit pentru a răci spațiul de birouri din aceeași clădire, cunoscut sub numele de aer conditionat, dar poate fi si independent de acesta. Recomandabil este ca aerul conditionar sa fie pozitionat in fata dulapului de servere, astfel incat ventilarea sa se faca orizontal, prin spatiile lasate libere intre fiecare server in parte, pentru o cat mai buna racire a acestora. Dulapuri de servere individuale pot poseda, de asemenea, măsuri de răcire proprii, cum ar fi ventilatoare sau răcire cu apă. Este de preferat un sistem de ventilare al aerului eficient, in detrimentul unui sistem cu apa care ar putea periclita echipamentele electrice in cazul unor defectiuni.

Sistemul de stingere al incendiilor include toate dispozitivele asociate cu detectarea sau stingerea unui incendiu în centrul de date. Cele mai evidente componente sunt sprinkler-ele pe baza de apa , sisteme de stingere a incendiilor, sistemele cu gaz – halogen și extinctoare portabile. Altele pot include dispozitive care detecteaza fum sau calitatea aerului măsură. Un sistem de detectare al fumului asigura adesea o mai buna eficienta in cazul unui incendiu, acesta fiind primul care da un semnal de alarma in cazul unui incendiu. Nu sunt de preferat sistemele pe baza de gaz halogen, fiind adesea periculoase pentru oamenii care administreaza data centerul dar si pentru cladire. De asemenea, stingatoarele montate in perete pe baza de apa, pot afecta instalatia electrica a centrului de date.

Există, de asemenea, unele elemente de infrastructură care nu se încadrează strict în categoriile anterioare, dar sunt de obicei găsite în mediile de servere. Acestea includ dispozitive de detectare a scurgerilor, atenuare seismică, și controalele de securitate fizice, cum ar fi cititoare de carduri și camere de securitate. Echipamente de control al accesului sunt foarte importante in procesul de patrundere in camera serverelor, pentru depistarea intruziunilor si a persoanelor responsabile. In mod uzual, doar persoanele care se ocupa de data centerul departamentului au acces in camera serverelor.

2.7. Cresterea eficientei si a disponibilitatii unui data center

Cresterea eficientei si a inaltei disponibilitati a unui centru de date, prin intermediul monitorizarii infrastructurii, include dezvoltarea unui sistem de management al data centerului ce trebuie sa aiba in vedere:

Temperaturile de detectare a unor incidente

Putere de monitorizare

Monitorizarea condițiilor de rack

Detectarea scurgerilor de lichid

Controlul inteligent al sistemului de racire si de ventilatie

Controlul inteligent al puterii critice

Alerte de Management și alarme

Monitorizarea eficienței energetice

Monitorizarea și gestionarea de la distanță

Modul in care se efectueaza efectiv monitorizarea data centerului, va fi descris intr-un capitol dedicat acestui proces de monitorizare.

2.8. Inalta disponibilitate

Clustere HA (de inaltă disponibilitate – en. high availability), sunt de obicei realizate din doua servere. Un singur server rapunde cererilor clientului, in timp ce alt server monitorizeaza serverul principal pentru a prelua activitatea dacacel primar se opreste. Cand clusterul este format din doua servere, monitorizare se facepe un cablu dedicat care interconecteaza cele doua masini, sau in retea. Din punct de vedere al clientului, aplicatia este accesibil prin intermediul unui nume (de exemplu, un nume DNS), care, la randul sau, mapeaza catre o adresa IP virtuala, care poate fi accesata cand de o masina, cand de alta,in functie de care masina este activa.

Solutia pe care am folosit-o pentru asigurarea inaltei disponibilitati apartine Evidian. Solutiile Evidian (IAM) pentru pentru managementul identitatii si al accesului sunt folosite in toata lumea de companii de productie , servicii si utilitati pentru a asigura accesul la informatie si pentru a respecta legile si reglementarile , cum ar fi Sarbanes – Oxley si ISO 27001.

Folosind solutiile de la Evidian, utilizatorii aplicatiilor oferite de departament vor putea sa le acceseze in fiecare zi, prin intermediul sistemului de autentificareal acestuia. Accesul la computere si la aplicatii se face folosind identificarea pe baza de smart card, biometrie si parole ce pot fi folosite o singura data.

2.9. Virtualizare

In zilele noastre, conceptul de virtualizare este adânc înrădăcinat în instalațiile centrelor de date prin tehnologii noi, cum ar fi memoria virtuală, gateway-uri virtuale, VLAN-uri, VRFs, contexte virtuale, mașini virtuale, profile de servicii, crearea de rețele virtuale, serviciile de rețele virtuale, și multe altele. Toate aceste tehnici de succes au o caracteristică comună: au fost create pentru a oferi optimizarea resurselor. Și pentru acest motiv, examinarea lor se deschide posibilitatea de a analiza urmatoarele aspecte:

Implementări tradiționale de centre de date și limitarile acestora

Beneficiile fiecarei tehnologii de virtualizare și comportamentul lor

Schimbările acestpr tehnologii oferă în o varietate de modele de centre de date si arhitecturi

Cererea pentru virtualizarea retelelor, serverelor, modulelor de stocare, desktop-urilor și aplicațiilor continuă să crească. Virtualizarea optimizează resursele și se aplică în toate domeniile de activitate ale unei rețele din centrul de date. Utilizarea de virtualizare a serverelor în mediile de producție a crescut . În mod corespunzător, organizatiile axate pe garantarea performanței și disponibilității mediilor virtuale din perspectiva end-to-end . Privind dincolo de granițele mașinii virtuale în sine, există numerose provocări operaționale pentru a se asigura că politicile de rețea și de configurare sau de stocare sunt respectate. Toate acestea, vor fi reluate în detaliu, în prezentarea soluției de cloud hibrid și în prezentarea mijloacelor pe care Microsoft Windows Azure le pune la dispoziție în vederea obținerii unui centru de date în cloud.

3. TEHNOLOGII ȘI SOLUȚII CLOUD UTILIZATE

3.1. CLOUD COMPUTING

Cu un centru de date local (on-premises), trebuie să ne ocupăm de gestionarea centrului, inclusiv de cumpărarea și instalarea de hardware, de virtualizare, de instalarea sistemului de operare și orice alte aplicații necesare, de înființarea rețelei (inclusiv fire de funcționare), de configurarea firewall-ul, și de înființarea spațiului de stocare pentru date. După ce s-au făcut toate astea, administratorul devine apoi responsabil de menținerea centrului de date, pe întreg ciclu său de viață. Aceasta impune atât un cost semnificativ de capital pentru hardware, cât și costuri operaționale semnificative pentru întreținere. Există posibilitatea de a alege elementele de hardware și software, dar de asemenea, trebuie să se plătească pentru centrul de date, indiferent dacă echipamentele alese se folosesc sau nu.

Cloud computing oferă o alternativă modernă la tradiționalul centru de date local. Un furnizor de cloud public este complet responsabil pentru achiziționarea de hardware și de întreținerea lui, și de obicei oferă o mare varietate de servicii de platformă pe care le putem folosi. Administratorul subcontractează serviciul de cloud public, indiferent de hardware-ul și software-ul pe care centrul de date le solicita, transformând astfel ceea ce a fost o cheltuială de capital pentru cumpărarea hardware-ului într-o cheltuială operațională. De asemenea, se permite închirierea accesului la hardware și la resurse software care ar putea fi prea scumpe pentru a se cumpăra. Cu toate că posibilitățile de achiziție de hardware sunt limitate de vânzătorul serviciului de cloud, cumpărătorul trebuie să plătească doar pentru ceea ce este utilizat.

Mediile de cloud oferă de obicei o experiență a utilizatorului de tip portal online, ceea ce face mai ușoară munca utilizatorilor în a gestiona, calcula și depozita resursele. De exemplu, un utilizator poate utiliza portalul pentru a crea o configurație de mașină virtuală (VM) pentru care se precizează următoarele: dimensiunea nodului de calcul (CPU, RAM, și discurile locale), sistemul de operare, orice software pre-deployed (preinstalat), rețeaua internet cu tot cu configurare și amplasarea punctului de acces la rețea. Utilizatorul poate implementa apoi mașina virtuală configurată și în câteva minute poate accesa nodul de calcul utilizat. Această implementare rapidă este favorabilă mecanismului anterior pentru implementare a unei VM, care ar putea dura săptămâni doar pentru ciclului de achiziție.

Microsoft oferă suport pentru soluții de cloud public, privat și hibrid. Microsoft Windows Azure, punctul central al acestei lucrări, este o soluție de cloud public. Azure Pack pentru Windows este un add-on gratuit pentru Microsoft System Center care ne permite să găzduim multe dintre serviciile de bază Azure în propriul datacenter al departamentului și ne oferă un self-service (serviciu singular). Cu ajutorul soluției Windows Azure, putem integra toate funcționalitățile de tip centru de date, într-un cloud hibrid prin utilizarea unui rețele virtuale privată.

Soluția de cloud hibrid aleasă prin utilizarea platformei Windows Azure, este de tipul IaaS: Infrastructure as a Service – Infrastructură ca și serviciu. Un furnizor cloud IaaS rulează și administrează servere care rulează software-ul de virtualizare, permițând să creem mașini virtuale care rulează direct pe infrastructura furnizorului. În funcție de furnizor, putem crea o VM care rulează Windows sau Linux și să instalați ceea ce dorim pe acea mașină. Azure oferă, de asemenea posibilitatea de a configura rețele virtuale, echilibrul de încărcare (load balancer-ul) și spațiul de depozitare și permite să utilizăm multe alte servicii care rulează pe infrastructura Microsoft. Spre deosebire de tipul unei arhitecturi cloud de tipul PaaS – platformă ca și serviciu, suntem complet responsabili de soluția cloud pe care o implementăm.

Mașini virtuale Azure din cadrul IaaS, sunt mai degrabă o alegere populară, atunci când se face migrarea de servicii în sau din Azure. Putem configura o mașină virtuală, în mod similar cu infrastructura care rulează în prezent serviciile din centrul de date și să migrăm ulterior software-ul pe mașinile virtuale descărcate direct de pe platformă. S-ar putea să fie nevoie să facem anumite trucuri, cum ar fi URL-uri către alte servicii sau spații de depozitare, dar multe aplicații pot fi migrate în acest mod.

Înainte de alegerea unei soluții de cloud hibrid de la Microsoft, am încercat implementarea și dezvoltarea unei soluții, de asemenea hibridă, folosind un software open-source de la Apache. Dezvoltarea serverelor, interfațarea cu mediul exclusiv virtualizat cu care s-a început proiectarea, cât și limitarea platformei Apache la sistemul de operare Linux, au făcut dificil demersul de a elabora o soluție viabilă folosind software-ul Apache.

Ca și etapă premergătoare prezentării soluției de cloud finale pe care prezenta lucrare se axează, voi prezenta câteva noțiuni teoretice asupra Apache Cloudstack 4.3, cât și câteva rezultate minimale obținute în tentativa de-a dezvolta centrul de date cu această metodă.

3.2. Apache CloudStack 4.3

Apache CloudStack este software open source, conceput pentru a implementa si gestiona retele mari de masini virtuale, ca o infrastructura de cloud computing, foarte scalabila extrem de disponibila sub forma de platforma ca si serviciu (IaaS). CloudStack este utilizat de un numar de mare de furnizori de servicii pentru a oferi servicii de cloud public, si de multe companii pentru a oferi un cloud local (privat), sau ca parte a unei solutii de cloud hibrid.

CloudStack este o solutie la cheie, care include intreaga "stiva", pe care cele mai multe organizatii o doresc cu un cloud IaaSm cu urmatoarele caracteristici: putere de calcul, retea ca si serviciu, management al conturilor de utilizatori, un API nativ, cu arhitectura completa si deschisa, resurse contabile si Graphical User Interface de prima clasa (GUI).

CloudStack accepta in prezent cele mai populare arhitecturi de masini virtuale: VMware, KVM, XenServer, Xen Cloud Platform (XCP) si Hyper-V.

Utilizatorii isi pot gestiona resursele din cloud, cu o interfata Web usor de utilizat, instrumente din linie de comanda sau cu un API. In plus, CloudStack ofera un API care este compatibil cu AWS EC2 si S3 pentru organizatiile care doresc sa implementeze solutii de cloud hibrid.

Alegerea infrastructurii de implementare – solutie de arhitectura folosind Apache Cloudstack

Arhitectura utilizata intr-o implementare de cloud. va varia in functie de marimea si scopul dezvoltarii unui centru de date.

Aceasta diagrama ilustreaza arhitectura retelei cu dislocare la scara larga implementata de CloudStack.

Un strat de comutatoare (layere-3) reprezinta nucleul centrului de date. Un protocol de redundanta este folosit ca router. De obicei switch-urile high-end de baza includ module de firewall. Firewall separat pe aparate poate fi utilizat in cazul in care switchurile de layer-3 nu au capabilitati de firewall deja integrate. Firewall-uri sunt configurate in modul NAT. Firewall-urile ofera urmatoarele functii:

Transmit cereri HTTP si apeluri la API, de pe Internet pentru operatia de Server Management. Serverul de administrare isi are resedinta in reteaua de gestionare.

Cand cloudul se intinde pe mai multe zone, firewall-urile ar trebui sa permita configurarea unei retele private virtuale, de la site la site, astfel incat serverele din zone diferite sa poata ajunge sa comunice direct si reciproc.

Un switch de strat-2, permite accesul pentru fiecare pod. Mai multe switch-uri pot fi aranjate pentru a creste numarul de porturi. In orice caz, ar trebui sa fie implementate comutatoare de layer 2.

Cluster Management Server (inclusiv front-endul – sarcina load balancerilor, Managementul Serverului si al nodurilor precum si baza de date MySQL) sunt conectate la reteaua de conducere printr-o pereche de load balanceri.

Servere secundare de stocare sunt conectate la reteaua de gestionare a cloudului implementat.

Fiecare nivel contine putere de stocare si servere de calcul. Fiecare server de stocare si server de calcul ar trebui sa aiba NIC-uri redundante conectate la switch-uri separate de layer-2 ca sa permita accesul.

CloudStack Management Server este implementat pe una sau mai multe servere de front-end, conectate la o singura baza de date MySql. Optional, o pereche de load balanceri distribuiti, fac solicitari la servere prin intermediul retelei. Un server pentru managementul datelor, inclusive backup, poate fi implementat utilizand o replicare MySql pe un site aflat la distanta, pentru a adauga astfel abilitati ale centrului de date de recuperare in caz de dezastru.

Este asadar, atributia administratorului de retea sa decida:

Daca va folosi sau nu load balancers

Cate servere de management vor fi folosite

Daca va implementa o replicare a bazei de date MySql si cat de necesar e un plan de Disaster Recovery.

Bune practici in configurarea Apache CloudStack

Fiecare gazda ar trebui sa fie configurata pentru a accepta conexiuni numai de la bine-cunoscutele entitati din CloudStack Management Server sau din reteaua de monitorizare a software-ului.

Este mult mai bine sa avem mai multe elemente mai mici primare de stocare pe cluster, decat un singur element mai mare.

Atunci cand exportam datele de pe un server primar pe capacitatea de stocare, pentru a evita pierderea datelor se recomanda limitarea intervalului de adrese IP care pot accesa serverul de stocare.

NIC (Network Interface Cards) sau interfata de logare este simplu de configurat si poate sa puna in aplicare o fiabilitate sporita a stivei. Retele 10G sunt, in general, recomandate pentru stocare si acces, atunci cand servere mai mari pot sprijini masini virtuale de mare dimensiune.

Capacitatea serverului gazda ar trebui sa fie, in general, modelata in RAM pentru client sau oaspeti. Depozitarea si CPU-ul pot fi livrare impreuna cu solutia de CloudStack si pot fi configurate incat sa poate fi si ele accesate. Memoria RAM este, de obicei, factorul de limitare in modele de capacitate alese.

Configurarea setarilor de dom0 pe XenServer trebuie sa aloce mai multa memorie pentru dom0. Aceasta poate permite XenServer sa se ocupe de un numar mai mare de masini virtuale. Recomand 2940 MB de RAM pentru XenServer dom0. Pentru instructiuni despre cum sa se faca acest lucru, se poate vedea http://support.citrix.com/article/CTX126531. Articolul se refera la XenServer 5.6, dar aceleasi informatii se aplica si pentru XenServer 6.0.

Instalarea si configurarea CloudStack pentru CentOS 6

Cloud-urile de tipul Infrastructura ca si serviciu pot fi un lucru greu de construit, si prin definitie, greoaie de configurat, chiar si pentru administratorii experimentati, care aplica la solutia prezentata.

Scopul este sa construim un CloudStack utilizand o masina virtuala cu kernel de Linux KVM, si o masina virtuala de ContOS 6.4, impreuna cu un server de stocare NFS pe o retea neierarhizata, de layer 2, care sa contina si grupuri de Securitate, sis a permita toate acestea, pe o singura platform hardware.

KVM, sau Kernel-based Virtual Machine este o tehnologie de virtualizare kernelul de Linux. KVM suporta virtualizarea nativa deasupra procesoarelor cu extensii de virtualizare Hardware. Grupurile de Securitate, sunt practic solutii de firewall distribuite, care ofera un control al accesului utilizatorilor sau unui grup de utilizatori pe masinile virtuale.

Preconditii de instalare, sunt:

Utilizarea a cel putin un computer care suporta virtualizarea hardware

Instalarea CentOS 6.4 x86_64 minimal install CD

O retea /24 cu gateway setat la xxx.xxx.xxx.1, fara DHCP setat si niciun computer ce utilizeaza CloudStack nu ar trebui sa foloseasca adrese dinamice. Astfel solutia se simplifica.

Folosind imaginea ISO x86_64 CentOS 6.4 minimal instalall, instalam CentOS pe hardware-ul existent. Setarile implicite de CentOS sunt suficiente pentru aceasta instalare.

Dupa ce instalarea este completa, trebuie sa ne conectezam la computerul cu CentOS proaspat instalat, prin SSH, ca utilizator root. Trebuie sa retinem ca ar trebui sa nu permitem conectari ale utilizatorului root intr-un mediu de productie, astfel incat trebuie sa ne asiguram ca este dezactivata conectarea la distanta, odata ce am terminat de instalat si configurat computerul pe care lucram.

In mod implicit reteaua nu va fi disponibila pe hardware si va trebui sa configuram setarile de retea. Din moment ce am specificat ca nu va fi nici un server DHCP in acest mediu, configurarea interfatei de retea se va face manual, din linia de comanda. Vom presupune, ca eth0 este singura interfata de retea, care poate fi conectata si utilizata. Conectarea prin consola ar trebui sa fie cu login ca root.

Verificam fisierul /etc/sysconfig/network-scripts/ifcfg-eth0, care va arata in mod implicit astfel:

DEVICE="eth0"

HWADDR="52:54:00:B9:A6:C0"

NM_CONTROLLED="yes"

ONBOOT="no"

Din pacate, aceasta configuratie nu va permite sa ne conectam la retea, si este, de asemenea, nepotrivita pentru scopurile noastre cu CloudStack. Vrem sa configuram acel fisier, astfel incat se se specifice adresa IP, netmask, etc, asa cum se arata in exemplul de mai jos:

DEVICE=eth0

HWADDR=52:54:00:B9:A6:C0

NM_CONTROLLED=no

ONBOOT=yes

BOOTPROTO=none

IPADDR=172.16.10.2

NETMASK=255.255.255.0

GATEWAY=172.16.10.1

DNS1=8.8.8.8

DNS2=8.8.4.4

Pentru pornirea retelei, se folosesc comenzile

# chkconfig network on

# service network start

CloudStack presupune ca numele masinii gazda sa fie setat corect. Daca am utilizat optiunile implicite in instalare, atunci hostname este setat in prezent in localhost.localdomain. Pentru a testa acest lucru vom rula:

# hostname–fqdn

In acest moment probabil raspunsul consolei va fi:

Localhost

Pentru a remedia aceasta situatie – vom stabili numele masinii gazda prin editarea fisierului/etc/hosts, astfel incat acesta sa aiba un format similar cu:

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4

:: 1 localhost localhost.localdomain localhost6 localhost6.localdomain6

172.16.10.2 srvr1.cloud.priv

Dupa ce am modificat fisierul respectiv, mergem mai departe si repornim reteaua utilizand comanda:

# service network restart

Verificam din nou cu comanda – fqdn hostname pentru a asigura ca se returneaza un raspuns corespunzator parametrilor setati anterior.

In acest moment, pentru ca, CloudStack sa functioneze corect SELinux trebuie setat pe permisiv. Ne dorim ca setarea sa se salveze si pentru pornirile ulterioare ale masinii pe care lucram, astfel incat modificam setarile in sistemul actual de functionare. Pentru a configura SELinux sa fie permisiv in sistemul de functionare, trebuie sa executam urmatoarea comanda:

# setenforce 0

Trebuie apoi sa ne asiguram ca acesta ramane in acea stare, astfel incat avem nevoie sa configuram si fisierul /etc/selinux/config ca in acest exemplu:

# This file controls the state of SELinux on the system.

# SELINUX= can take one of these three values:

# enforcing – SELinux security policy is enforced.

# permissive – SELinux prints warnings instead of enforcing.

# disabled – No SELinux policy is loaded.

SELINUX=permissive

# SELINUXTYPE= can take one of these two values:

# targeted – Targeted processes are protected,

# mls – Multi Level Security protection.

SELINUXTYPE=targeted

Configurarea NTP (Network time protocol) este o necesitate pentru pastrarea sincronizata a tuturor ceasurilor de pe serverele din cloud. Cu toate acestea, NTP nu este instalat in mod implicit. Asa ca vom instala si configurara NTP dupa cum urmeaza:

# yum -y install ntp

# chkconfig ntpd on

# service ntpd start

Pentru a adauga repozitoriul de CloudStack, cream fisierul /etc/yum.repos.d/cloudstack.repo , cu urmatorul continut:

[cloudstack]

name=cloudstack

baseurl=http://cloudstack.apt-get.eu/rhel/4.3/

enabled=1

gpgcheck=0

Configurarea sistemului de fisiere, NFS, este necasara atat pentru serverele primare cat si cele secundare folosite la stocare. Trebuie sa cream doua partitii ale sistemului NFS din instalare, pentru aceste scopuri. Vom incepe prin instalarea nfs-utils.

# yum install nfs-utils

Avem nevoie sa configuram NFS pentru a servi celor doua actiuni diferite. Acest lucru este manipulat relativ usor in fisierul /etc/exports. Trebuie sa se asigure urmatorul continut:

/secondary *(rw,async,no_root_squash)

/primary *(rw,async,no_root_squash)

Am specificat doua directoare care nu exista (inca) pe sistem. Trebuie sa creem aceste directoare si sa setam permisiunile in mod corespunzator pe ele, cu urmatoarele comenzi:

# mkdir /primary

# mkdir /secondary

CentOS 6.x utilizeaza NFSv4 in mod implicit. NFSv4 presupune setarea domeniului pe toti clientii. In cazul nostru, cloudul folosit este un cloud de tip privat, deci trebuie sa ne asiguram ca setarea domeniului in fisierul /etc/idmapd.conf este necomentat si corect stabilit dupa cum urmeaza:

Domain = cloud.priv

Trebuie de asemenea, sa decomentam parametri de configurare din fisierul /etc/sysconfig/nfs:

LOCKD_TCPPORT=32803

LOCKD_UDPPORT=32769

MOUNTD_PORT=892

RQUOTAD_PORT=875

STATD_PORT=662

STATD_OUTGOING_PORT=2020

Trebuie sa configuram firewall-ul pentru a permite conexiunile NFS. Editam asadar fisierul /etc/sysconfig/iptables

-A INPUT -s 172.16.10.0/24 -m state –state NEW -p udp –dport 111 -j ACCEPT

-A INPUT -s 172.16.10.0/24 -m state –state NEW -p tcp –dport 111 -j ACCEPT

-A INPUT -s 172.16.10.0/24 -m state –state NEW -p tcp –dport 2049 -j ACCEPT

-A INPUT -s 172.16.10.0/24 -m state –state NEW -p tcp –dport 32803 -j ACCEPT

-A INPUT -s 172.16.10.0/24 -m state –state NEW -p udp –dport 32769 -j ACCEPT

-A INPUT -s 172.16.10.0/24 -m state –state NEW -p tcp –dport 892 -j ACCEPT

-A INPUT -s 172.16.10.0/24 -m state –state NEW -p udp –dport 892 -j ACCEPT

-A INPUT -s 172.16.10.0/24 -m state –state NEW -p tcp –dport 875 -j ACCEPT

-A INPUT -s 172.16.10.0/24 -m state –state NEW -p udp –dport 875 -j ACCEPT

-A INPUT -s 172.16.10.0/24 -m state –state NEW -p tcp –dport 662 -j ACCEPT

-A INPUT -s 172.16.10.0/24 -m state –state NEW -p udp –dport 662 -j ACCEPT

Repornim serviciul iptables cu urmatoarea comanda:

# service iptables restart

Configura serviciul nfs pentru a incepe sa booteze odata cu pornirea masinii si pornim executia sa pe masina gazda cu urmatoarele comenzi:

# service rpcbind start

# service nfs start

# chkconfig rpcbind on

# chkconfig nfs on

Instalarea serverului de gestionare

Vom incepe cu instalarea serverului pentru baza de date MySQL si configurarea optiunilor, pentru a ne asigura ca ruleaza bine cu CloudStack.

# yum -y install mysql-server

Cu MySQL instalat, trebuie sa facem cateva modificari de configurare in fisierul /etc/my.cnf. In mod special, adaugam urmatoarele optiuni in sectiunea [mysqld]:

innodb_rollback_on_timeout=1

innodb_lock_wait_timeout=600

max_connections=350

log-bin=mysql-bin

binlog-format = 'ROW'

Repornim serviciul si il configuram sa booteze cu masina gazda, astfel:

# service mysqld start

# chkconfig mysqld on

Instalarea serverului de management al cloudului se face cu comanda:

# yum -y install cloud-client

Setarea bazei de date se face cu:

# cloudstack-setup-databases cloud:password@localhost –deploy-as=root

Iar setare parametrilor cloudstack se face cu comanda:

# cloudstack-setup-management

CloudStack foloseste un numar mare de sisteme de VMs pentru a oferi functionalitati de accesare a masinilor virtuale, oferind diverse servicii de retele si gestionare a diverselor aspecte legate de stocare. Este nevoie sa descarcam sablonul de sistem pentru masina virtuala si sa implementam cloudul. Gestionarea serverului include un script pentru a manipula in mod corespunzator imaginile cu masinile virtuale.

# /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /secondary -u http://download.cloud.com/templates/4.3/systemvm64template-2014-01-14-master-kvm.qcow2.bz2 -h kvm -F

KVM este hypervisorul cu care se va recupera instalarea initiala care a fost deja facuta pe hypervisorul masinii gazda si care acopera instalarea de agenti software utilizati, pentru a adauga noduri suplimentare la mediul de CloudStack.

# yum -y install cloud-agent

Configurarea KVM este relativ simpla. Avem nevoie sa editam QEMU VNC. Acest lucru se face prin editarea /etc/libvirt/qemu.conf si asigurarea ca urmatoarea linie este prezenta si necomentata.

vnc_listen = 0.0.0.0

CloudStack foloseste libvirt pentru gestionarea masinilor virtuale. De aceea este vital ca libvirt sa fie configurat corect. Libvirt este o dependenta de agent cloud si ar trebui sa fie deja instalat.

In /etc/libvirt/libvirtd.conf, mai sunt necesare urmatoarele ajustari ale parametrilor:

listen_tls = 0

listen_tcp = 1

tcp_port = "16059"

auth_tcp = "none"

mdns_adv = 0

Porninea "listen_tcp" in libvirtd.conf nu este suficienta, avem nevoie pentru a modifica /etc/sysconfig/libvirtd.

#LIBVIRTD_ARGS="–listen"

Decomentati linia urmatoare:

# service libvirtd restart

Pentru a obtine acces la interfata web de CloudStack, pur si simplu accesam in browser http://172.16.10.2:8080/client, in care implicit numele de utilizator este "admin" si parola este "parola". Ar trebui sa vedem un ecran care ne permite sa selectam mai multe optiuni pentru configurarea CloudStack. Ar trebui sa alegem sa continuam cu optiune de setare elementare. Este de asemenea necesara schimbarea parolei la urmatorul pas.

Setarea zonelor de timp este necesara pentru sincronizarea masinilor virtuale care servesc drept servere cloud. Pentru setarea unei zone de timp este necesar sa configuram 5 informatii pe care interfata de Apache CloudStack ni le solicita.

Nume – ex. ‘Zone1’

Public DNS 1 – ‘8.8.8.8’

Public DNS 2 – ‘8.8.4.4’

Internal DNS1 – ‘8.8.8.8’

Internal DNS2 – ‘8.8.4.4’

Configurarea pod-ului solicita setarea urmatorilor parametri astfel:

Name – Pod1.

Gateway – 172.16.10.1

Netmask – 255.255.255.0

Start/end reserved system IPs – 172.16.10.10-172.16.10.20

Guest gateway – 172.16.10.1

Guest netmask – 255.255.255.0

Guest start/end IP – 172.16.10.30-172.16.10.200

Configurarea cluster-ului se face prin setarea:

Name – Cluster1

Hypervisor – KVM

Setarea nodului primar de pe cluster se face prin setarea parametrilor:

Hostname – 172.16.10.2, deoarece nu am setat un DNS server.

Username – ‘root’

Password – ‘<la alegere>’

Discul primar de stocare – se alege NFS ca tip de stocare si se introduce valorile parametrilor, cum precizez mai jos:

Name – ‘Primary1’

Server – 172.16.10.2

Path – /primary

Discul secundar de stocare

NFS server – 172.16.10.2

Path – /secondary

Apasati Launch si cloudul privat s-a setat.

Conectarea la UI

CloudStack ofera o interfata web pentru interactiunea cu utilizatorul, ce poate fi folosita atat de administratori, cat si de utilizatorii comuni. Versiunea de UI depinde de credentialele folosite la logare. Interfata este disponibila pentru majoritatea browserelor (IE7, IE8, IE9, Firefox 3.5+, Firefox 4, Safari 4, and Safari 5).

Exemplu de URL : http://<adresa-ip-a-serverului-de-management>:8080/client

La o prima instalare pe server, sunt afisate pe ecran o serie de instructiuni (ca un tur ajutator). La logari ulterioare, va fi afisat un ecran de logare, care contine:

Username -> Numele utilizatorului. Implicit este “admin”.

Password -> Parola asociata acestui nume de utilizator. Parola implicita pentru “admin” este “password”.

Domain -> Pentru logarea cu utilizatorul root, acest camp nu trebuie completat.

Daca sunteti un utilizator al unui subdomeniu, este necesar sa scrieti intreaga cale a domeniului, incluzand domeniul radacina.

Spre exemplu, sa presupunem ca sunt create mai multe niveluri in domeniul radacina, cum ar fi Comp1/hr. Utilizatorii din domeniul Comp1 ar trebui sa completeze cu Comp1, iar utilizatorii din Comp1/vanzari ar trebui sa completeze cu Comp1/sales.

Interfata cu utilizatorul – aspecte generale

Interfata din cadrul CloudStack ajuta utilizatorii infrastructurii cloud sa viziulizeze si sa foloseasca resursele din cloud, incluzand masinile virtuale, template-urile si imaginile ISO, volumele de date si snapshoturile, retelele si adresele IP. Daca un utilizator este un membru sau un administrator al mai multor proiecte CloudStack, interfata UI poate sa ofere o imagine orientata pe proiect.

Interfata corespunzatoare logarii cu admin – aspecte generale

CloudStack UI ajuta administratorul de CloudStack sa vizualizeze, sa gestioneze infrastructura cloud, domeniile, conturile utilizatorilor, proiectele si setarile de configurare. Administratorul poate sa foloseasca interfata si pentru a efectua sarcini prezente in interfetele utilizatorilor comuni.

Logarea cu Root

Deschideti un browser si introduceti adresa urmatoare. Inlocuiti adresa IP a propriului server.

http://<adresa-ip-a-serverului-de-management>:8080/client

Pentru cazul primei logari, alegeti una dintre urmatoarele:

Continuati cu setarile de baza. Alegeti aceasta optiune daca este prima oara cand folositi CloudStack, si daca vreti sa fiti ghidat in a alege cea mai simpla configuratie. Aici va fi instalata un singur calculator pe care ruleaza diverse programe si care foloseste NFS pentru asigurarea unei locatii de stocare a datelor; un singur calculator pe care ruleaza mai multe masini virtuale si o retea publica comuna.

Am mai folosit CloudStack. Alegeti aceasta optiune daca ati mai trecut prin faza de proiectare si planificare, sau daca sunteti pregatit sa incepeti un proces de extindere a cloud-ului pe care l-ati setat intr-o faza anterioara cu setarile de baza. Optiuni avansate: inalta disponibilitate, retea VLAN, elemente de retea aditionale (load balancers si firewall), suport pentru supervizare ca Citrix XenServer, KVM, and VMware vSphere.

Odata ajuns la panoul de administrare, vi se cere sa va schimbati parola.

Schimbarea parolei

Deschideti un browser si introduceti adresa urmatoare. Inlocuiti adresa IP a propriului server.

http://<adresa-ip-a-serverului-de-management>:8080/client

Logati-va folosind contul de root (admin, password)

Selectati Accounts

Selectati contul de administrator

Selectati View Users

Selectati admin

Selectati butonul Change Password

Apache CloudStack este un software open source care formeaza fundatia pentru infrastructura de cloud pe care dorim s-o implementam. Operatorii centrului de date pot construi rapid si usor, servicii de cloud in infrastructura lor pentru a oferi servicii la cerere, cloud-ul obtinut fiind extensibil.

Intreprinderile pot folosi CloudStack ca si solutie de cloud hibrid, ceea ce face mai usoara gestionarea modelului de cloud.

Utilizatorii de CloudStack pot profita plin de puterea de calcul pentru a oferi cresterea eficientei, la scara nelimitata si pentru o implementare mai rapida de noi servicii si sisteme pentru utilizatorul final.

CloudStack permite utilizatorului sa coordoneze servere virtualizate, sa creeze retele si servere de stocare pentru a furniza infrastructura ca si serviciu (IaaS), precum si gazduirea datelor stocate si implicit a serverelor pe masinile lor.

CloudStack este un sistem de operare de tip cloud public open-source care livreaza dispozitive de calcul similare cu Amazon EC2, dar foloseste hardware-ul propriu al clientului. CloudStack ofera caracteristici puternice pentru a permite acces la cloudul implementat multiplilor clienti. Cu un singur clic, serverele virtuale pot fi configurate de la un sablon pre-definit la setarile dorite.

Concluziile si directiile de dezvotare sintetizeaza ceea ce s-a prezentat schematic pana in acest moment, si reprezinta obiectivele lucrarii in sine, fiind formulate astfel:

Este necesara implementarea unei arhitecturi de centru de date securizate, care sa asigure obtinerea unor performante conforme cu cerintele departamentului;

Se va tine cont de nivelul de siguranta al datelor si la rularea serverelor si implicit a aplicatiilor/serviciilor in functionare, astfel incat sa avem o inalta disponibilitate;

Politicile de securitate sunt generice insa alegerea unei arhitecturi este adesea problema de baza a dezvoltarii unui data center;

Trebuie avute in vedere, inca din start, aspectele hardware si arhitectura de retea, si in acest sens se va propune o arhitectura ierarhizata, cu imbunatatirea nivelelor 2 si 3 pentru elementele folosite

Desfasurarea proiectului va viza intai implementarea arhitecturii prin intermediul masinilor virtuale care sa emuleze functionalitatea corecta a serverelor;

In acest sens solutia practica prezentata, reprezinta un punct de start fiabil.

Urmatoarea etapa va fi cea de montare a dulapului de servere si conectarea lor;

Notiunile teoretice de securitate precum si implementarea securitatii se va face direct pe servere, unde se vor instala aplicatii pentru web, stocare datelor serviciu de comunicare interna si e-mail etc.

Procesul de implementare si dezvoltare a securitatii data centerului va fi finalizat in prima faza prin virtualizarea mediului, vizand ca data centerul sa fie in viitor independent si sa asigure toate functionalitatile departamentului.

In ceea ce priveste solutia practica de implementare a stivei centrului de date cu Apache CloudStack, noi imbunatatiri si dezvoltari includ: imbunatatirea sistemului de management, implementarea politicilor de retea, securizare, stocare si management al utilizatorilor

Limitarea în dezvoltarea unei soluții a reprezentat-o însăși soluția Apache, care este nativă unui sistem de operare Linux, motiv pentru care s-a renunțat la utilizarea acesteia, în detrimentul Platformei Windows Azure, prezentată ulterior.

Microsoft Windows Azure

Windows Azure este platforma de cloud computing a Microsoft, care permite dezvoltatorilor sa se dezvolte rapid, sa implementeze și sa gestione aplicatiile gazduite într-un centru de date Microsoft. Ca un furnizor de IaaS, Windows Azure are grija nu numai de infrastructura, dar ne ajuta, de asemenea, sa gestionăm componente de nivel superior, inclusiv sisteme de operare, cele de runtime, și de middleware.

Microsoft a investit masiv în Windows Azure în ultimii ani. 19 centre de date de pe trei continente au fost dezvoltate pentru a servi milioane de clienti. Ele au fost construite cu un mecanism optimizat din punct de vedere al eficientei energetice, cu containere de auto-racire, și omogenitate hardware, ceea ce le diferentiaza de celelalte centre de date.

Centrele de date sunt situate în urmatoarele orașe:

US North Central – Chicago, IL

US South Central – San Antonio, TX

Europa de Vest – Amsterdam

Europa de Nord – Dublin

Asia de Est – Hong Kong

Sud-Est Asia – Singapore

Microsoft a clasificat anterior platforma Azure în trei componente principale: Windows Azure, SQL Azure și Windows Azure AppFabric. Cu toate acestea, cu recenta lansare a Metro-stilului portalului Windows Azure, exista unele mici modificari de branding, dar functionalitatea a ramas similara. Urmatoarea diagrama ilustreaza suita completa de servicii pentru Windows Azure disponibile astazi.

Figura 2. a. – Suita Servicii Azure

Figura 2.b – Azure privire generală

O succintă prezentare a elementelor de bază din suita de servicii pusă la dispoziție de Windows Azure, este făcută în paragrafele următoare ale lucrării.

A. Core Services

1- Compute

Serviciul Compute se refera la puterea de calcul, de obicei sub forma de masini virtuale prevazute (VMS). În Windows Azure, containerele de calcul sunt adesea denumite "roluri". În momentul de fata, exista trei tipuri de roluri:

(i) Roluri Web

Rolurile Web ofera un mediu predefinit, set-up pentru a permite dezvoltatorilor de a implementa cu ușurinta aplicatii web. Server Web IIS (Internet Information Services) a fost preinstalat și preconfigurat pentru a gazdui cu ușurinta aplicatia web.

(ii) Roluri de taskuri

Roluri de taskuri permit dezvoltatorului sa ruleze procesul de fundal unei aplicatii care nu necesita interactiunea de interfata cu utilizatorul. Rolurile de taskuri sunt perfect potrivite pentru a rula procese, cum ar fi loturi de taskuri programate si prelucrare de date asincrone.

(iii) Roluri de VM

VM Roles permit dezvoltatorilor sa aduca masini virtualizare cu Windows Server 2008 R2 in cloud, și sa le configureze. Rolurile VM sunt potrivite pentru cazurile în care software-ul necesita instalarea pe o lunga durata, manuala.

Folosind Roluri de VM, platforma Azure are un dezavantaj substantial. Spre deosebire de celelalte roluri prin care Windows Azure vor gestiona automat sistemul de operare, gestiunea masinilor virtuale necesita dezvoltatori pentru a gestiona în mod activ sistemul de operare.

În afara de "roluri", exista alti doi termeni esentiali, și anume "dimensiunea unei VM" și "instanta de masina virtuala". O vedere generală asupra modulului de Compute / Calcul, este prezentată în Anexa 2 – Compute Overview.

Storage

Windows Azure Storage este un serviciu de stocare cloud, care vine cu urmatoarele caracteristici:

Disponibilitate cu 99,9% lunara, Service Level Agreement

Scalabilitate cu partitionarea echilibrata a sarcinii automate

Datele sunt replicate pentru rezilienta și pentru protectie in 3 copii din același centru de date, precum și alte 3 exemplare geo-replicate într-un alt centru de date

Accesibil prin mai multe biblioteci, inclusiv .NET, Java, PHP, Ruby, etc. pe baza de REST API

Pana la limita de dimensiune 100TB per cont depozitare

Capacitatea de stocare: 0.14 dolari per GB pe luna

Tranzactie de depozitare: 0.01 dolari la 10.000 tranzactii

Exista patru tipuri de obiecte de abstractizare pentru depozitare care sunt disponibile astazi:

(i) BLOB (Binary Large Object) – Blob Storage ofera un sistem de fișiere foarte scalabil, durabil, și sunt disponibile în cloud. Blob de stocare permite clientilor sa stocheze orice tip de fișier, cum ar fi video, audio, poze sau text.

(ii) Tabelul de depozitare – Tabelul de depozitare prevede depozitarea structurata, care poate fi folosita pentru a stoca datele tabelare non-relationale. Un tabelul este un set de entitati, care contin un set de proprietati. O cerere poate manipula entitati și interogarea pe oricare dintre proprietatile stocate într-un tabel.

(iii) Coada de stocare – Coada de stocare este o livrare de mesaje de încredere și persistenta, care poate fi utilizata pentru transferul de aplicatii. Cozile sunt adesea folosite pentru a expedia în mod fiabil taskurile asincrone.

(iv) Unitati Azure – X-Drive ofera posibilitatea de a stoca datele durabile prin utilizarea API-urile Windows NTFS existente. Azure Drive este, în esenta, un blob VHD Page montat ca o unitate NTFS de o instanta de Windows Azure.

Database / Storage

Baze de date SQL Azure este un serviciu baza de date extrem de disponibil, construit pe tehnologia existenta de SQL Server. Dezvoltatorii nu trebuie sa configureze, instalaeze, sau sa administreze orice infrastructura a bazei de date. Tot ceea ce dezvoltatorii trebuie sa faca, este sa defineasca numele bazei de date, editia, și dimensiunea.

Aplicatiile și serviciile implementate pe platforma Azure pot utiliza Azure pentru depozitarea si persistenta continutului nestructurat și semi-structurat.

Azure Storage cuprinde trei capacitati fundamentale necesare pentru construirea de aplicatii industriale, rezistenta și servicii: Mese, Blobs și cozi. Azure Storage este un mecanism de persistenta masiv, scalabil și extrem de fiabil, care este, de asemenea, accesibil pentru aplicatiile gazduite local, prin interfata standard de servicii web REST. Pentru asigurarea unui mediu privat, Azure Storage sustine SSL (HTTPS) ca acces pe baza, de pe langa protocolul HTTP standard.

Accesul la depozitare este în mod automat pe un set de noduri, pentru scalabilitate și disponibilitate echilibrata de sarcina. Fiecare nod este responsabil pentru o cantitate finita de depozitare fizica. Accesul la depozitare din afara domeniului de aplicare un nod se realizeaza printr-o interfata peer-to-peer. Fiabilitatea se realizeaza prin redundanta entitatilor depozitate pe mai multe noduri. Software-ul de stocare trimite mai multe replici a datelor în mod automat, odata ce are loc o scriere. Depozitarea suporta scrierile tranzactionale atomice, iar tranzactia se va finaliza abia dupa ce toate replicile sunt scrise pentru toate unitatile.

Azure Storage se bazeaza pe un Mesaj de autentificare cu Hash Code (HMAC) pentru autentificarea cererilor Web REST. Comun, cheia secreta asociata cu Azure Storage este combinata cu cererea HTTP, care ia în calcul un hash de 256 de octeti ca o "autorizatie" suplimentara, în afara de cererea serviciului web. Același proces se repeta pe server pentru a verifica autenticitatea cererii.

Figura 3 – Serviciu de stocare Azure

4 – Diagnosticare

Azure Cloud Services furnizeaza metode de dignosticare extinse, iar aceasta caracteristica a fost acum extinsa la site-uri web Azure și la masini virtuale. Odata configurata diagnosticarea pe VM, toate jurnalele, urmele și contoarele de performanta pot fi colectate de la mai multe masini virtuale într-un singur loc pentru gestionarea ușoara. Acest lucru este usor vizibil la nivelul portalului Azure, in sectiunea de monitoring a unei masini virtuale.

Unul dintre beneficiile cele mai mari ale cloud computing este scalabilitatea; posibilitatea de a muta rapid de la cateva masini virtuale pana sute și cereri de servicii multiple, atunci cand este necesar.

B. Sistemele de operare Windows Azure

Windows Azure este un mediu virtualizat care ruleaza pe o platforma personalizata Hyper-V. În loc cheltuiasca o mare parte din bani pe echipamente specializate, designul centrului de date se bazeaza pe utilizarea hardware-ului, împreuna cu o platforma de auto-vindecare, astfel încat sa creeze un sistem elastic. Ca atare, serverele fizice care sunt utilizate în cadrul Azure al centrului de date pentru Windows variaza foarte putin în configuratia lor.

Mașinile virtuale la care se implementeaza Cloud Services și Windows Azure Virtual Machines, pot rula pe o partitie de pe una dintre aceste servere fizice.

Compartimentarea principala a nodului radacina al serverului ruleaza un sistem de operare care este cunoscut ca sistemul de operare gazda și este întretinut de Microsoft. Acest sistem de operare gazda este responsabil de gestionarea resurselor serverului, precum și de rularea Windows Azure VM Agent, care este folosit pentru a comunica cu Windows Azure Fabric controller.

Controlorii Fabric monitorizeaza și controleaza segmente largi ale centrelor de date. Pe masura ce sunt efectuate implementari, restul resurselor de pe serverele fizice sunt mutate în sus, în una sau mai multe partitii copii. Aceste partitii copil ruleaza propriul lor sistem de operare, denumit în continuare sistemul de operare oaspete. Avand în vedere caracterul multi-chiriaș al platformei virtualizate care serveste mai multi clienti în același timp, partitiile OS oaspete nu au acces la la sistemul de operare gazda direct. Sistemul de operare gazda gestioneaza partitiile de oaspete și controleaza o parte dintre interactiunile pe care mașinile virtuale oaspete le au cu alte sisteme din cadrul centrului de date.

Pentru Cloud Services, mașinile virtuale pot rula o configuratie usor modificata a sistemului de operare Windows Server, care este optimizat pentru a rula în mediul Windows Azure.

O reprezentare schematică a obiectivelor lucrării, integrând elementele constitutive Azure, deja prezentate, ar arăta ca în Fig. 3, astfel:

Figura 4 – Suita de servicii Azure – exemplu de implementare

Windows Azure Pack Overview

Windows Azure Pack este o colecție de tehnologii Windows Azure, disponibil pentru clienții Microsoft, fără costuri suplimentare pentru instalare în centrul de date. Se rulează pe partea de sus a Windows Server 2012 R2 și System Center 2012 R2 și, prin utilizarea tehnologiilor Windows Azure, vă permite să oferim un bogat, self-service, multi-chiriaș nor, în concordanță cu experiența publică Windows Azure.

Windows Azure Pack include urmatoarele capacitati:

Portal de Management pentru chiriasi – un portal self-service personalizabil pentru provizionarea, monitorizarea, iar gestionarea serviciilor, cum ar fi site-ului web cloud, masini virtuale cloud si magistrale de comunicatie cloud.

Portal de management pentru administratorii – un portal pentru administratori pentru a configura și administra resurse cloud, conturi de utilizator si preturi pentru masinile gazda.

Serviciul API pentru management – un API REST.

Site-uri Web cloud- un serviciu care ajuta la furnizarea de o mare densitate, scalabila platforma web hosting pentru aplicatii web ASP.NET, PHP, și Node.js. Serviciul web nori site-ului include o galerie de personalizabil aplicatie web de aplicatii open source web și integrare cu sisteme de control sursa de site-uri web dezvoltate personalizate și aplicatii.

Virtual Machines- un serviciu care ofera o infrastructura-ca-si-serviciu (IaaS) cu capabilitati pentru mașinile virtuale Windows și Linux. Virtual Machines Service include o galerie VM șablon, optiuni de scalare, și capabilitati de intocmire de retea virtuala.

SQL si MySQL – servicii care furnizeaza instante de baze de date. Aceste baze de date pot fi folosite în conjunctie cu serviciul web site-urilor.

Automatizari – capacitatea de a automatiza și integra servicii suplimentare vamale în cadrul serviciilor, inclusiv un editor runbook și mediu de executie.

Portalul de management este considerat extrem de important, deoarece acesta ofera capabilitati critice de administrare a operatiunilor care au un impact asupra tuturor chiriașilor. Acesta este implementat într-o configuratie "activ/activ" pentru utilizarea politicii de performanta de trafic si pentru ca portalul de management sa distribuie traficul intre centrele de date. Datele sunt reprodus între centrele de date folosind SQL Data Sync. Pentru aceasta optiune de implementare, cererile trebuie sa fie proiectate sa functioneze peste centre de date. O provocare majora este de a asigura coerenta datelor. Exista mai multe posibilitati de a realiza acest lucru, care depind în mare masura de specificul app și volumul de munca.

Ar trebui sa ia în considerare potentialele conflicte și de manipulare solutionarea conflictelor bazate pe logica aplicare.

Serviciul de provizionare – se executa în doua centre de date – si este responsabil pentru implementarea cererilor în sine. Acest lucru se întampla în unitati de scara, astfel serviciul nu este folosit numai pentru implementare initiala, dar și pentru scalare.

Platforma Azure dispune de o scalabilitate destul de buna. Putem adauga sau elimina instante la cerere ori de cate ori simtim nevoia. Se poate sa se elimine si instante create, daca nu mai este nevoie de acestea. Din punct de vedere al disponibilitatii, Windows Azure utilizeaza un acord de tip Service Level Agreement (SLA), care asigura obtinerea a 99,95% timp de functionare, pentru orice aplicatie care ruleaza Microsoft în numele nostru. Designul Windows Azure permite pozitia controalelor Fabric in trei locatii care asigura backup datelor si recuperabilitatea lor. Controlerul Fabric are grija de gestionarea aplicatiilor. Acesta face primul decizii cu privire la cazul în care masinile virtuale nu pot rula. Apoi, monitorizeaza performanta lor. Controlerul Fabric salveaza informatiile colectate și dezvoltatorii pot scrie cod cu privire la modul de a utiliza aceste informatii. În cazul în care o instanta se blocheaza, controlorul Fabric aduce unul nou. De asemenea, este responsabil pentru patching sistemului de operare al mașinii virtuale pe care ruleaza instanta. Toate aceste sarcini de gestionare întampla în fundal, fara preocuparea clientului.

Sarcina controllerului Fabric echilibreaza cererile utilizatorilor dintre 2 masini virtuale care comunica – in cazul meu, DC si serverul de aplicatii. Ce înseamna acest lucru este ca nu exista nici o garantie doua cereri de la acelasi user va merge la aceeași instanta. Acest lucru poate fi o problema cu unele aplicatii care au nevoie de o conexiune dinamica cu utilizatorul. O conexiune dinamica este una în care unele informatii despre o legatura între doua sisteme este retinut pentru o utilizare viitoare.

Aspecte legate de modelul de arhitectură ales, și detaliile pe proiectare și implementare, vor fi discutate în capitolele 4 și 5 ale prezentei lucrări.

PROIECTAREA CENTRULUI DE DATE

Utilizarea platformei Windows Azure în versiune de bază sau extinsă, este o decizie care ar trebui să fundamentată pe motive bine definite. Un val de tehnologie la fel de mare ca tehnologia cloud computing poate fi un factor care să influențeze și în mod negativ un departament sau o organizație, și are valoare de instrument strategic de evaluare. În acest capitol voi lua în considerare posibilitățile de revizuire a modurilor diferite în care Windows Azure poate fi folosit strategic de către departament.

Pentru multe organizații, ca și în cazul departamentului AII, de cele mai multe ori, probleme legate de tehnologia informației (IT) și de capacitatea de utilizare a resurselor de către angajații/membrii lor este asigurată de propriul departament IT.

Departamentul AII deține spațiul fizic al centrului de date, deține serverele fizice, deține licențe software, și membrii departamentului pot asigura competențe IT cu care se gestionează și operează toate aceste resurse menționate anterior. Cu toate acestea, în timp departamentul poatesă rămână fără spațiu de stocare disponibil, sau hardware-ul poate eșua, sau elementele constitutive ale centrului de data devin depășite și trebuie să fie înlocuite, versiuni de software devin depășite și trebuie să fie modernizate, iar personalul său trebuie să gestioneze tot spațiul de datacenter, hardware și software.

Pentru a începe scăderea necesității de a adăuga mai mult spațiu la datacenter, să înlocuim hardware-ul, să adăugăm mereu extensii și să upgradăm software, și de a gestiona cât mai mult din toate astea, pentru departamentul AII, ca și în majoritatea organizațiilor, am optat pentru hardware existent și infrastructură de rețea subsontractată de la Microsoft, prin serviciul său de cloud Azure. Astfel, prin utilizarea echipamentelor proprii, și prin interfațarea acestor sisteme la mecanismele puse la dispoziție de Windows Azure, se va putea obține în viitor, o soluție completă în cloud. Combinarea elementelor puse la dispoziție atât de departament, cât și de Windows Azure, va îmbina elemente de arhitectura PaaS și IaaS, rezultând astfel o soluție finală de cloud hibrid.

Funcționalitățile pe care departamentul AII le poate consuma de la furnizorul de cloud computing public, Windows Azure sunt:

1 – Servicii software care furnizează capacitatea de comunicație directă de la client. Exemple de astfel de servicii sunt Microsoft Office 365, Microsoft Dynamics CRM Online, si altele de la furnizorii non-Microsoft

2- Servicii platformă pe care dezvoltatorii de aplicații le pot integra în aplicațiile ce vor fi găzduite ulterior pe serverele departamentului. Exemple de astfel de servicii sunt Windows Azure Service Bus, Windows Azure SQL Service, iar altele de la furnizori non-Microsoft

3- Servicii de infrastructură, care permit departamentului să ruleze pe mașini virtuale infrastructura furnizorului de cloud public. Exemple de astfel de servicii sunt Windows Azure Services ca și infrastructură, iar altele de la furnizorii non-Microsoft, unul dintre acestea fiind și Apache Cloud Stack, analizat anterior.

Ideea adoptării unui cloud hibrid nu trebuie să pună probleme de funcționare corectă a centrului de date. Departamentul AII va putea integra capabilități de cloud computing public ale furnizorului Azure, cu propriile sale capacități de:

Integrare a unui mecanism de autentificare între propriile sisteme și sisteme de la furnizorul de cloud, și se va oferi capacitatea de conectare unică pentru utilizatorii din departament.

Integrarea rețelei proprii cu rețeaua furnizorului cu posibilitatea de a oferi comunicație securizată între cele două medii – furnizor și departament.

Integrarea instrumentelor de management a sistemelor, astfel încât departamentul să poată gestiona sistemul pus la dispoziție de furnizor și să reușească să ruleze aplicații pe sistemele locale proprii

Trebuie menționat faptul că centrul de date al departamentului AII nu este deocamdată funcțional, și prin urmare, întreaga dezbatere asupra unei soluții de cloud hibrid pentru centrul de date al departamentului, se desfășoară la un nivel abstract, teoretic.

Lucrarea de față își propune să analizeze cum anume se poate devolta o arhitectură convenabilă pentru cerințele departamentului unei facultăți, și neoferind o soluție concretă. Partea de implementare și dezvoltare a arhitecturii soluție de cloud hibrid folosind platforma Windows Azure pentru departamentul AII, se desfășoară la nivel online, pe infrastructura furnizorului și va reprezenta părți de exemplificare a unor etape ce trebuiesc parcurse în vederea obținerii unei soluții concrete.

Așadar, în cazul lucrării de față, pentru departamentul AII se implementează o soluție de infrastructură cloud hibrid.

Partea de proiectare detaliază mediu actual al departamentului, obiectivele de proiectare și cerințele și politicile existente de mediu și constrângerile care conduc la designulde implementare. Cazul departamentului AII poate fi privit la nivel restrîns ca și cazul unei micro-organizații. Această parte de proiectare este de altfel, cea mai utilă pentru obținerea unei soluții hibride de infrastructură cloud în cadrul departamentului, deoarece conținutul său conduce la dezvoltarea infrastructurii de cloud hibrid.

Pentru a definitiva proiectarea centrului de date, trebuie să pornim în primul rând de la partea de design. Această parte de design, ne arată de ce au fost selectate produse specifice, tehnologii și opțiuni de configurare, din sute de opțiuni individuale disponibile, pentru a satisface cerințele unice pentru departament. Suntem interesați de analiza motivelor pentru care s-au luat decizii de proiectare specifice. Designul propus poate ajuta la reducerea timpului de implementare și la scăderea riscului de punere în aplicare a unei soluții de infrastructură cloud hibrid personalizate care eșuează.

Înțelegerea unui exemplu de design de infrastructură de cloud hibrid, și motivația pentru opțiunile de proiectare selectate pentru el, permit înțelegerea tuturor opțiunilor individuale relevante de configurare, de design, de soluții de infrastructurî de cloud hibrid, și astfel poate determina ce opțiuni sunt cele mai potrivite pentru propriile cerințe, unice. Vom dezbate pe larg acest subiect, în secțiunea Considerații de infrastructură, din cadrul prezentului capitol.

Considerații de proiectare a infrastructurii de cloud hibrid

Cele mai multe intreprinderi (IT) sau organizații au centre de date limitate de personal, spațiul centrului de date, hardware, și buget.Pentru a evita adăugarea de mai multe din aceste resurse, sau de a folosi mai eficient resursele pe care le au deja, multe organizații folosesc acum servicii IT externe pentru a spori capacitățile și serviciile lor interne. Exemple de astfel de servicii sunt Microsoft Office 365 și Microsoft Dynamics CRM Online. Servicii care sunt furnizate de furnizori externi prezintă în mod obișnuit cinci caracteristici esențiale ale cloud computing (self-service la cerere, acces larg rețea, în comun a resurselor, elasticitate rapidă, și de servicii măsurat), care sunt definite în NIST (United States National Institute of Standards and Technology).

Capacitățile tehnice sunt reprezentate de funcționalitatea care este furnizată de hardware sau software, precum și atunci când sunt utilizate împreună în configurații specifice, ele oferă un serviciu, sau chiar un serviciu de cloud.

Chiar dacă multe persoane consumă o serie de servicii de cloud de la furnizori externi, în mod independent, de obicei, un departament în cadrul unei organizații IT stabilește o relație cu un furnizor extern de la nivel organizațional. Acest departament consumă serviciul la nivel organizațional, integrează serviciul cu unele dintre propriile capacități și / sau servicii tehnice interne, iar apoi furnizează serviciul integrat hibrid consumatorilor din propria organizație. Consumatorii din cadrul organizației sunt adesea conștienți de dacă serviciul este deținut și administrat de propria lor organizație IT sau deținut și gestionat de un furnizor extern. Și nu trebuie să ne pase cine deține ce, atâta timp cât serviciul îndeplinește cerințele organizației, sau în caz similar al departamentului.

Un aspect important atunci când se proiectează o infrastructură cloud hibridă, este că în timp ce departamentul va fi văzută ca un furnizor de servicii de cloud pentru consumatorii din interiorul său, departamentul în sine este și un consumator de servicii cloud. Asta înseamnă că există mai multe niveluri de consumatori. Consumatorul membru al departamentului ar putea fi considerat un consumator de-al doilea nivel al serviciilor de cloud public, în timp ce departamentul ar putea fi considerat un consumator prim nivel al serviciului de cloud.

Primul scop al etapei de proiectare este acela de a oferi celui ce proiectează soluția de cloud hibrid, o colecție de probleme și întrebări, la care trebuie să se răspundă pentru construirea unei infrastructuri cloud hibrid. Al doilea scop este de a oferi arhitectului o colecție de opțiuni care pot fi evaluate și alese în funcție de răspunsurile la întrebări. În timp ce întrebările și opțiunile pot fi utilizate cu o soluție orice furnizor de servicii cloud public, exemplele de opțiuni disponibile se va concentra pe platforma Windows Azure. O serie de întrebări la care ar trebui să se răspundă în procesul de adoptare a unei soluții de cloud hibrid, se regăsesc grupate pe secțiuni, într-un studiu al unor dezvoltatori de la Microsoft, asupra adoptării unei soluții hibride de cloud.

Pe lângă seriile de întrebări și răspunsuri cu privire la adoptarea unei arhitecturi, etapa de proiectare a constat și în culegerea unor informații referitoare la:

Cerințele de proiectare relevante și constrângerile de mediu care trebuie să fie colectate înainte de integrarea Windows Azure Services infrastructură într-un mediu.

Considerații de proiectare conceptuală pentru integrarea serviciilor de cloud din infrastructură într-un mediu existent, indiferent de cine este furnizorul extern de servicii cloud.

Considerații de proiectare fizice pentru a evalua integrarea Windows Azure Services ca infrastructură într-un mediu existent.

Prefigurarea soluției de cloud hibrid

Considerațiile de design din acest document sunt pentru o soluție hibridă, care permite departamentului:

Configurarea unui cont de nivelul de organizare și de facturare cu un prestator extern de servicii de infrastructură cloud, astfel încât consumatorii să nu facă acest lucru la nivel individual.

Permite consumatorilor utilizarea de mașini virtuale cu capacități similare mașinilor virtuale de la furnizor.

Permite consumatorilor accesarea aplicațiilor existente care rulează pe rețeaua locală a departamentului într-o infrastructură de tip cloud public

Permite consumatorilor de aplicații din cadrul departamentului,să se autentifice la resurse

Permite activarea securității de bază, a controalelor de acces la date, continuitatea afacerii, recuperarea în caz de dezastru, disponibilitatea și scalabilitatea infrstructurii.

Înainte de integrarea serviciilor de infrastructură cloud cu capacități existente infrastructurii tehnice și/sau servicii locale, trebuie să definim mai întâi o serie de cerințe și constrângerile de integrare a serviciilor. Unele dintre cerințe și constrângeri sunt definite de către consumatori, în timp ce altele sunt definite de mediul existent, în ceea ce privește capacitățile existente tehnice, servicii, politicile și procesele. În acest sens, pe parcursul proiectării s-au constatat numeroase impedimente de implementare a unor funcționalități arhitecturii propuse, fapt datorat în primul rând politicilor de costuri pentru Windows Azure, care este este destul de limitată în cazul utilizării unui cont de test.

Considerații de design conceptual

Un model de referință este o reprezentare a componentelor la nivel ridicat pentru o soluție. Un model de referință poate oferi terminologii comune la evaluarea capacităților de produs diferite furnizori. Un model de referință, de asemenea, ajută la adoptarea unei arhitecturi conceptuale de bază, pentru scopul problemei noastre, anume dezvoltarea politicilor de securitate în cadrul departamentului AII. Ca un punct de plecare, putem folosi modelul de referință Cloud Foundation Services, menționat anterior ca și CSFRM.

Nu voi include o explicație detaliată a modelului CSFRM în acest document. Deși este de la Microsoft, acest model de referință poate servi ca fundament pentru hosting de servicii cloud si poate fi extins, după caz, de către oricine. Decizia folosirii acestui model de arhitectură în mediul departamentului, presupune adoptarea sa în mod corespunzător.

Modelul CSFRM este reprezentat ca în ansamblu în figura de mai jos.

Figura 5 – Modelul CSFRM

O altă soluție pentru arhitectura dorită o poate reprezenta arhitectura de referință Private Cloud Microsoft (PCRA), care oferă o serie de principii, modele și concepte care trebuie să se ia în considerare înainte de proiectarea un cloud privat.

Figura 6 – Modelul de arhitectură PCRA

Implementarea unei arhitecturi de tipul PCRA are drept scop final obținerea unui cloud hibrid ca și model Health (sănătos), în care să se asigure totodată și înalta disponibilitate a serverelor, și backup-ul datelor, și comunicația cu succes între mașinile virtuale, în cadrul rețelei private. Modelul este reprezentat în figura 6.

Figura 7 – Health Model PCRA

O infrastructură cloud hibrid introduce noi variabile, deoarece chiar dacă gazda este în prezent o infrastructură cloud privat la sediul departamentului. Cu toate acestea, adoptarea soluției de la Windows Azure, permite ca echipamentele să fie deținute pe serverele Microsoft și accesate remote, după ce au fost în prealabil corect configurate.

Alegerea unei arhitecturi în procesul de implementare al centrului de date, trebuie să țină cont de următoarele variabile:

Virtualizarea sau împărțirea componentelor hardware în entități logice. Deși virtualizarea apare diferit în fiecare componentă de infrastructură (server, rețea și spațiu de stocare), beneficiile sunt în general aceleași și anume: timpi mici de downtime în timpul sarcini de gestionare a resurselor, portabilitate sporită, gestionarea simplificată a resurselor, precum și capacitatea de a partaja resurse. În acest sens, pentru soluția de cloud hibrid propusă, virtualizarea componentelor infrastructurii trebuie să fie perfect integrată, pentru a oferi o infrastructură lichidă, capabilă de extensibilitate, la cerere.

La proiectarea servicii de cloud hibride, este posibil să aveți pool-uri de resurse pe spațiul centrului de date care pot trata resursele de la furnizorul de cloud ca un pool separat al resurselor. În acest sens, se recomandă folosirea a două portofolii distincte de resurse, compartimentate, un set în cloud privat, care ar putea găzdui informații de impact mediu și înalt asupra departamentului, și un set să fie găzduit pe un cloud public, care ar putea găzdui doar informații cu impact redus pentru departament

La proiectarea infrastructurii fizice, aplicarea acestui model, de obicei, cuprinde achiziționarea de colecții pre-configurate de mai multe servere fizice și de depozitare. Extensibilitatea modelului de cloud poate varia prin introducerea sau scoaterea din centrul de date a mașinilor virtuale cu rol de server care mai trebuiesc sau nu mai folosesc.

Considerații de design la nivel fizic

Așadar, după luarea în calcul a acestor considerente conceptuale, și prin studiul resurselor pe care Windows Azure le oferă, în soluția de cloud hibrid am convenit să folosesc următoarele elemente, grupate pe rolul sau funcționalitatea pe care ar trebui s-o asigure în cadrul centrului de date:

Tabel 1. – Servicii, tehnologii Microsoft Azure integrate în soluția de cloud hibrid propusă

Toate modelele entitate de referință de tipul rețea, putere de calcul și stocare, se aplică la nivelul proiectării centrului de date al departamentului AII, peste resursele on-premises (existente deja) în centrul de date – rack de servere, cablaje etc.

Atunci când se analizează infrastructura de tip cloud hibrid din perspectiva fizică, problemele principale de care trebuie să ne preocupăm, includ:

Considerente legate de costuri de achiziție și de facturare pentru serviciul de infrastructură

Considerente de autentificare și de autorizare la un server de infrastructură cloud public

Considerente de proiectare pentru rețea

Considerente de proiectare pentru spațiul de depozitare

Considerente de proiectare a mașinilor virtuale

Considerente de aplicare a proceselor de autentificare și autorizare

Considerente de management și suport

Vom discuta fiecare dintre aceste subiecte în detaliu și va discuta despre avantajele și dezavantajele fiecărei opțiuni.

Considerente legate de plată, achiziție și utilizare

La proiectarea unei infrastructuri hibride de cloud, prima misiune este de a obține și de pune la dispoziție conturile de acces de la furnizorul de servicii pentru o infrastructură de tip cloud public. În n cazul în care furnizorul de servicii acceptă mai multe opțiuni de plată, va trebui determinat care opțiune de plată se potrivește cel mai bine nevoilor din centrul de date.

Windows Azure oferă mai multe planuri de plată:

Pay as you go, este un angajament în timp și putem anula subscripția în orice moment

Plata pe 6 luni în avans

Plata pe 12 luni în avans

Subscripție de evaluare – Gratis 1 lună de zile

Pay as you go este cel mai scump plan. Reducerile sunt oferite pentru fiecare dintre celelalte 2 planuri. Serviciul este facturat pe cardul de credit sau direct către departament.

Pentru exemplificarea utilizării Microsoft Windows Azure în cadrul proiectului de disertație actual, am utilizat o subscripție de 1 lună, gratis, cu ajutor căreia am exemplificat sumar ceea ce Azure pune la dispoziție pentru construirea unei infrastructuri de cloud hibrid.

Considerente legate de proiectarea rețelei

În cele mai multe cazuri, o infrastructură cloud hibrid necesită extinderea rețelei la rețeaua furnizorului de servicii de infrastructură cloud, astfel încât sunt posibile comunicații între componentele de pe spațiul local și în afara spațiului local. Există mai multe aspecte principale pe care trebuie să le luăm în considerare la proiectarea componentei de rețea, pentru a sprijini infrastructura de cloud hibrid. Acestea includ:

Local de proiectare rețea fizică

Conectivitate Inbound la rețeaua de servicii de infrastructură publică

Echilibrarea încărcării de gestiune la conexiuni de intrare la masini virtuale

Rezolvarea conflictelor de nume pentru rețeaua de infrastructură cloud publică

Windows Azure permite conectarea mașinilor virtuale la o rețea virtuală care este conținută în infrastructura Windows Azure. Rețele Virtuale Private (VPN) permit crearea unei rețele virtuale și asocierea mașinilor virtuale la rețeaua virtuală creată. Când mașinile virtuale sunt plasate într-o rețea virtuală Azure, acestora li se vor atribui automat adrese IP de Windows Azure, astfel încât toate mașinile virtuale trebuie să fie configurate în calitate de clienți DHCP. Cu toate acestea, chiar dacă mașinile virtuale sunt configurate în calitate de clienți DHCP, ele vor păstra informațiile de adresare IP pe toată durata de viață a mașinii virtuale.

În cadrul experimentării practice cu Windows Azure, am lucrat atât cu rețele virtuale de tipul Site-To-Site, cât și cu rețele virtuale de tipul Point-To-Site.

O conexiune Site-to-Site VPN permite conectarea rețelelor întregi împreună. Fiecare parte a conexiunii găzduiește cel puțin o poartă de acces VPN, care, în esență, acționează ca un router între rețelele on-premise și în rețelele externe. Infrastructura de rutare în rețeaua centrului de date trebuie configurată să utilizeze adresa IP a gateway-ului local rețelei VPN, pentru a accesa ID-urile de rețea, care se află în rețeaua furnizorului de cloud public, pe care se găzduiesc mașinile virtuale, care fac parte din soluția hibridă de cloud.

Un motiv pentru care în am experimentat și utilizarea de subrețele este din punct de vedere contabil. În cazul în care mașinile virtuale au anumite roluri în infrastructura cloud hibridă, acestea sunt plasate pe subrețele specifice, cărora le sunt atribuite aceste roluri. Cu toate acestea, putem utiliza în rețea, liste de control acces (ACL), pentru a controla traficul între mașinile virtuale într-o rețea virtuală Azure, și putem seta endpoint-uri pentru rețea și pentru listele de acces.

O conexiune Point-to-Site (de obicei menționată ca un instrument de acces de la distanță în VPN), permite conectarea dispozitivelor individuale la rețeaua furnizorului de servicii de cloud public. Accesul la mașinile din cloud-ul public al furnizorului, în cazul de față Microsoft, se face prin descărcarea unui fișier .rdp, de conexiune remote, direct de pe interfața Azure. Conectarea Point-To-Site presupune existența unui certificat pe mașina clientului.

Windows Azure suportă conectivitatea Point-To-Site care folosește un Secure Socket Tunneling Protocol (SSTP) bazat pe conexiunea la distanță a clientului prin acces VPN. Această conexiune VPN client se face cu ajutorul Windows VPN. Atunci când se stabilește conexiunea, clientul VPN poate accesa oricare dintre mașinile virtuale prin conectarea la rețea. Acest lucru permite administratorilor să se conecteze la mașinile virtuale folosind orice interfețe web administrative care sunt găzduite pe mașinile virtuale, sau prin stabilirea unei conexiuni Remote Desktop Protocol (RDP) pentru mașinile virtuale. Acest lucru permite administratorilor de infrastructură cloud hibrid să gestioneze mașinile virtuale la nivelul mașinii, fără a le cere acestora să își deschidă porturile RDP publice, accesibile mașinile virtuale.

În scopul de a autentifica clientii VPN, certificatele trebuie să fie create și exportate. Dacă aveți un PKI, puteți utiliza un certificat X.509 emis CA (autoritatea de certificare a calculatorului gazdă). Dacă nu aveți un PKI, trebuie să se genereze un certificat root și un certificat client auto-semnat și legat de certificatul root auto-semnat. Putem instala apoi certificatele clientului cu cheie privată pe fiecare computer client care necesită conectivitatea la rețea.

Definirea scenariului pentru soluția de infrastructură de tip cloud hibrid

Pentru a proiecta întreaga soluție de cloud hirid, trebuie să ne raportăm în permanență la cerințele funcționale ale departamentului.

Vom analiza pe rând cerințele conturate. Toate cerințele din următoarele secțiuni sunt aliniate la subdomeniile aplicabile și membre componente ale modelului de arhitectură CSFRM.

Livrarea serviciului de cloud

4.2.1.1 Cerințe Public Cloud Provider – furnizorului de cloud public – Azure

Capabil să susțină scalare la un număr aproape infinit de mașini virtuale ca și creșteri a cererii

Capabil să susțină până la 100 Mbps lățime de bandă pentru servere conectate la internet

Capabil să susțină până la 100 Mbps lățime de bandă peste legătura dintre rețeaua furnizorului și rețeaua locală

Disponibilitate și continuitate a managementului

Abilitatea de a asigura timp de funcționare de cel puțin 99,9% pentru componentele de servicii, desfășurate la nivelul furnizorului de cloud public

Oferirea unui acord privind nivelul serviciilor (Service Level Agreement – SLA), care include sancțiuni financiare în cazul în care cerința de funcționare continuă nu este îndeplinită în fiecare lună

Furnizează un mecanism pentru a asigura legătura între orice client conectat la Internet și orice componentă de servicii din rețeaua furnizorului care acceptă aceste conexiuni

Furnizează un mecanism pentru a asigura legătura între rețeaua furnizorului și rețeaua locală

Furnizează o capacitate de facturare bazată pe consum

4.2.1.2. Cerințe legate de infrastructura Azure

Compute (Virtual Machine)

Nu se percep taxe pentru mașinile virtuale care nu sunt pornite

Se furnizează imagini pentru sistemele de operare

Se oferă suport pentru încărcarea de imagini care au fost create local și care pot fi folosite pentru a crea noi mașini virtuale pe rețeaua publică a furnizorului

Suport de auto-scalare de mașini virtuale

Network (Rețea)

Se susține o conexiune criptată între rețeaua locală și cea publică

Se susține un mecanism care permite conectivitatea între rețeaua locală și rețeaua furnizorului, care conține mașinile virtuale

Se furnizează soluții integrate de load balancing din serviciile front-end găzduite în rețeaua furnizorului serverului

Storage (Spațiul de stocare)

Se oferă sprijin pentru fiecare disc de mașină virtuală să permită/restricționeze scrierea pe disc

Suport în menținerea de mai multe copii ale drive-urilor virtuale în locații dispersate geografic

Nu șterge fișierele de pe un disc al unei mașini virtuale din stocarea automată

Suportă dimensiuni virtuale de disc, cerute de componentele de servicii migrate pe infrastructura furnizorului de cloud public

Soluție de arhitectură de cloud hibrid pentru Departamentul AII

În problemele de securitate adresate de arhitectura Hybrid Cloud trebuie precizat că "atunci când se dorește asigurarea unei imagini de arhitectură hibridă pentru sistem cloud, ar trebui să ia în considerare toți factoriide securitate,atât pentru cloud-ul public cât și pentru cloud-ul privat."

În timp ce acest afirmație este încă adevărată, abordarea asigurării unui mediu hibrid ar putea să nu fie la fel ca atunci când suntem în etape de planificare a securitatății unui cloud privat. Într-un scenariu de cloud hibrid putem utiliza în continuare cele mai importante considerații de securitate de cloud privat, combinate cu considerente de securitate de cloud public. O modalitate de a aborda preocupările de securitate într-un mediu mixt, este de durată și foarte importantă ca și etapă, în obținerea unei soluții securizate.

O diagramă de rețea simplă pentru un mediu cloud hibrid și elemente din domenii-cheie care ar trebui să fie adoptate prin folosirea unor elemente de apărare a sistemului și pentru a spori securitatea de ansamblu a acestei soluții, sunt prezentate în figura de mai jos:

Figura 8 – Elemente identificate pentru o arhitectură de cloud hibrid

Zonele mapate pe diagrama de mai sus, reflectă componentele de bază într-un scenariu de cloud hibrid. Fiecare zonă centrală trebuie să fie extinsă pentru a identifica amenințările și vulnerabilitățile care sunt aplicabile acelei zone. Numerele de pe această diagramă nu reflectă o ordine de prioritate, ci doar organizează numai șase componente majore, care vor fi acoperite în secțiunea care urmează.

Clienții conectați de la distanță

Clienții la distanță sunt cunoscuți ca punct final (endpoint) sau ca și calculatoare mobile. Ei vor avea acces la resurse, care sunt situate în ambele locuri: în cloud-ul public Azure și la rețeaua on-premise. Uneori calea pentru accesarea resurselor cloud trebuie executată prin conectivitate on-premise. În funcție de modul în care departamentul dorește să pună în aplicare politica de securitate, s-ar putea decide ca un client final să se poată conecta la un server VPN (on-premise) și să treacă printr-o serie de validări de securitate înainte de a permite accesul la resurse (on-premise și asupra cloud-ului public). Există mai multe opțiuni de design de luat în considerare atunci când se planifică o protecție a endpoint-urilor pe un scenariu de cloud hibrid.

Protecția endpoint-urilor ar trebui să respecte cerințele minime de securitate pentru stațiile de lucru, care vor fi accesarea datelor centrului de date al departamentului. Indiferent dacă datele se află pe cloud sau on-premise, cerințe minime de securitate includ:

Criptarea unităților

Sistem de operare actualizat complet

Antivirus instalat și actualizat

Firewall personal activat și configurat corect

Furnizorul de cloud public

La evaluarea cărui furnizor de cloud public va fi utilizat pentru a găzdui aplicațiile, trebuie înțelegem strategia lor de securitate, care cuprinde:

Controale de securitate și protecție.

SLA (Service Level Agreement)

Replicarea datelor

Soluții de audit

Modelul de implementare al securității fizice

Microsoft oferă un ghid de negociere a contractelor de cloud care pot ajuta, cu această selecție.

Servere virtuale ale furnizorului de cloud public

Într-un scenariu hibrid pentru o IaaS (Infrastructure as a Service), serverele se vor menține de pe platforma furnizorului de cloud. Prin urmare, furnizorul va fi responsabil pentru mentinerea acestor servere securizate. Unele recomandări de securitate sunt:

Platforma de cloud a furnizorului oferă capabilități de izolarea a rețelei. Izolarea trebuie să fie, de asemenea, disponibilă pentru: Hypervisor, rădăcina sistemului de operare, mașinile virtuale gazdă, controller-i Fabric.

Păstrarea serverelor up-to-date (antivirus, actualizări de sistem de operare și aplicarea de actualizări)

Securizare server în funcție de rolul serverului

Datele sunt criptate în timp ce serverele sunt în repaus

Platforma de cloud furnizor permite să se monitorizeze cu ușurință și precizie starea serverelor care au fost dislocate din nor. Monitorizarea și disponibilitatea sunt cerințele esențiale ale oricărui plan de securitate.

Spațiul de stocare din cloud-ul folosit de aceste servere are capacilități de control al accesului, care permit să definim ACL-uri (liste de control acces) corespunzătoare.

Protecția Edge-urilor

Într-un cloud hibrid protecția muchiilor devine și mai importantă, deoarece unele soluții vor necesita un tunel de conectivitate Site-To-Site între resursele on-premise și furnizorul de cloud public. Atunci când se planifică protecția marginilor de apărare în profunzime pentru o abordare hibridă de cloud se va ține cont de:

Conformitatea soluției cu posibilitățile oferite și de furnizorul de cloud.

Soluția Edge poate efectua URL Filtering (utilizarea serviciilor de reputație), inspecție de malware, inspecția porturilor HTTPS.

Resursele locale

Nivelul de securitate on-premise ar trebui să fie la același nivel sau chiar mai mare decât alt nivel din soluția prezentată prin figura 7. Amenințările interne sunt încă o realitate și ingineria socială din interior este o amenințare în creștere. Abordarea subiectului de securitate la nivel local trebuie făcut nu numai din perspectiva serverelor, ci pentru toate straturile: de la ciclul de viață de dezvoltare a aplicatiilor interne, care trece prin protecția rețelei, stații de lucru, servere, politicile și practicile generale de securitate.

Conectarea tuturor elemente prezentate mai sus într-o rețea virtuală Azure, cu extensibilitate ulterioară a rețelei prin adăugarea de mașini virtuale, este prezentată în figura 9.

Figura 9 – Arhitectură de rețea virtuală Azure prin adăugare de VM

Figura 8, aduce o soluție cu un mare avantaj pentru migrarea aplicațiilor existente în Microsoft Azure. Putem gestiona astfel propriile rețele virtuale din cadrul Microsoft Azure și poarta de acces prin VPN-ul găzduit pentru a stabili conectivitatea între resursele locale și cele din cloud.

După cum se vede în diagramă, în Microsoft Azure Virtual Network putem rula un server DNS Active Directory Domain activat într-o mașină virtuală în timp ce gazduieste o bază de date SQL Server într-o altă mașină virtuală; și codul aplicație poate rula prin intermediul unui web role (rol de web server) administrat de Microsoft Azure.

Conform posibilităților Windows Azure și în raport cu soluția dorită, se propune următorul model de arhitectură de infrastructură de cloud hibrid:

Figura 10 – Exemplu de arhitectură cloud Azure hibridă

Figura face diferența între partea de cloud public și partea de cloud privat a centrului de date. Utilizatorul are acces la elementele din interiorul rețelei virtuale private prin conexiune la internet. Toate elementele și clauzele de conectare, autorizare, utilizare a serviciilor de cloud hibrid, se vor aplica respectând toate considerentele din acest capitol.

Un model de autentificare cu replicarea resurselor din modelul de arhitectură de mai sus, este reprezentat în figura 11.

Figura 11 – Autentificare cu replicarea resurselor în Azure cloud hibrid

Ca și decizii de implementare a arhitecturii prezentate, voi utilizare, per fiecare componentă Azure, următoarele:

Plan de subscripție și plată – 1 singur cont gratis, de evaluare a serviciului de cloud Microsoft Azure (valabilitate 1 lună)

Conectivitatea între rețeaua locală și cea externă se face printr-o conexiune Site-To-Site VPN pentru a conecta rețelele. Motivul pentru aceasta este faptul că departamentul necesită o conexiune bidirectională de a sprijini conexiuni de la serverele de web front-end pe rețeaua virtuală Azure, la serverele de baze de date back-end, care sunt situate pe local. Conectivitatea între controlerele de domeniu existente pe rețeaua virtuală Azure și controlerele de domeniu de pe local este realizată cu succes de acest tip de conexiune.

Accesul clienților, membri ai departamentului la toate resursele aflate pe rețeaua virtuală se face prin intermediul unei conexiuni la Internet, în timp ce operațiile de management al resurselor se face pe rețeaua locală, de către un administrator al centrului de date.

Rețeua virtuală Azure realizează mecanismul de load-balacing (echilibrarea sarcinilor) și astfel permite o disponibilitate ridicată și echilibrarea încărcării pentru serverele web de front-end. Acest lucru se va realiza prin implementarea unui manager de trafic.

Rezolvarea numelor pentru infrastructura publică de servicii de rețea – autentificare prin DNS dinamic, cu un server DNS – Au fost create înregistrări de DNS-publice pentru a permite accesul prin internet al clientului la resurse din rețea virtuală găzduită de Azure

Au fost create înregistrări DNS private pentru a permite accesul pentru management al resurselor din Azures

Stocare – SQL Server 2012 Windows si fibre optice

Mașini virtuale – create direct în interfața Windows Azure, pe rețeaua virtuală și accesate prin VPN – accesul se face rapid, găzduirea se face pe spații aproapiate geografic de locația rețelei locale, iar toate mașinile virtuale fac parte din același grup de entități afiliate. Fiecărei mașini virtuale i se vor adăuga discuri, pentru care se vor folosi formate existente în Windows Azure.

Există și varianta uploadării unor mașini virtuale deja salvate, în format VHD. Totuși, unele distribuții de mașini virtuale suportă doar formatul VHDx, iar varianta aceasta poate impune probleme la importul mașinilor de pe rețeaua locală în cloud-ul hibrid.

Serviciile din infrastructura Azure creează automat o regulă de redirecționare a porturilor care permit conexiunea prin PowerShell sau RDP pentru sistemele de operare Windows și accesul SSH pentru sistemele de operare Linux, prin Internet la mașini virtuale create pe o rețea virtuală Azure. Pentru a reduce suprafața de atac pentru servere conectate la Internet, politica de securitate a departamentului, interzice accesul la Internet la sistemele de operare aflate la distanță, pentru PowerShell, RDP și SSH. Din acest motiv, am decis să dezactivez regula de port forwarding, implicit creată de infrastructura Azure Services, pentru toate mașinile virtuale conectate la Internet.

Se crează doar o singură regulă de port forwarding pentru TCP port 443, care să permită accesul la serverele web de front-end.

Toate mașinile virtuale care fac parte din același serviciu de cloud hibrid, vor fi introduse în același set de disponibilitate (availability set)

Se propune ca parametrii de auto-scalare să fie stabiliți la un interval de două până la patru servere, cu un interval de utilizare a procesorului setat între 60% -80%

Toate serverele web trebuie să fie plasate în același serviciu de cloud

Autentificare – sincronizare între Active Directory-ul local și Windows Azure Active Directory folosind DirSync

Numai conturile din Active Directory-ul local trebuie să aibă permis accesul administrativ la servicii de infrastructură Azure găzduite de management

În ceea ce privește figura 8 – autentificare cu replicare, se recomandă folosirea a două controlere de domeniu pe fiecare rețea virtuală Azure pentru a sprijini autentificarea utilizatorului pentru aplicații. Domain Controllerul se crează direct în rețeaua de cloud Azure, folosind imaginile disponibile Windows. Toate controlere de domeniu aflate pe rețeaua virtuală Azure, trebuie configurate ca serverele DNS cu AD integrat

Update-urile mașinilor virtuale trebuie setate astfel încât să se întâmple în afara orelor de program ale departamentului.

Autentificarea și autorizarea – suport – Windows Azure Active Directory

Mecanism de backup oferit de Windows Azure Backup Services

Implementarea câtorva din elementele prezentate și detalii legate de cum s-a făcut implementare, împreună cu capturi de ecran reprezentative, se regăsesc în capitolul 5 al prezentei lucrări.

IMPLEMENTAREA CENTRULUI DE DATE

Acest capitol oferă o abordare bazată pe etape, pentru punerea în aplicare a designului detaliat în capitolul 4 al lucrării. Se listează pașii de implementare pentru a instala și configura soluția. Acest articol este exemplificativ pentru soluția de cloud hibrid propusă.

Implementarea retelei virtuale a centrului de date

Detalii de implementare

Pașii de implementare la nivel înalt pentru rezolvarea infrastructurii hibrid cloud sunt detaliati în capitolul 4 al lucrarii si sunt cuprinsi în tabelul de mai jos. Fiecare pas de implementare la nivel înalt include etapele de punere în aplicare a mai multor nivel inferiore, care sunt detaliate în restul acestui capitol.

Configurarea retelei site-to-siteVPN cu Windows Azure

Implementarea masinilor virtuale in Windows Azure

Implementarea unei aplicații într-un nor de infrastructură

Configurare Windows Azure Active Directory

Configurare Windows Azure Load Balancing

După ce s-au facut toate deciziile de design, este timpul să se pună în aplicare infrastructura cloud hibrid.

În timpul acestei implementari, primul pas este să ne abonam la Windows Azure. Când accesam pagina de Preturi Windows Azure, vom vedea opțiunile de Incercati acum sau să cumpărați acum.

Vom folosi versiunea de test, pentru o perioada de 30 zile cu 150 Eur credit initial, pentru dezvoltarea scenariului nostrum.

Înainte de a ne abona la Windows Azure, este important să se definească ce cont va fi contul de abonament și ce alte conturi se vor folosi, cum vor fi autorizate să administreze Windows Azure sau Management Portal contul initial, sau celelalte conturi legate. Contul de abonament include informațiile cardului de credit, care este folosit pentru a plăti abonamentul, care nu este neapărat același cont care va fi folosit pentru a administra mediul.

După abonamentul este complet,departamentul va crea conturi de co-administrator, pentru a permite utilizatorilor autorizați să gestioneze portalul.

Pentru implementare s-a folosit un cont de utilizator Microsoft, si o inscriere gratuita de evaluare a platformei.

Pentru accesul pe platforma cloud a Microsoft Azure, se vor folosi legaturile:

https://manage.windowsazure.com – Portalul de management admin

Figura 12 – Portalul de management al Windows Azure

Implementarea a pornit de la crearea unei masini virtuale si setarea acesteia cu un serviciu cloud asociat, unei retele virtuale si a un DNS care va fi apoi mostenit de masinile gazda ce se vor lega la centrul de date. Masina virtuala creata ca si suport al centrului de date se numeste AIIDC si foloseste o distributie de Microsoft Server 2012 R2 OS, si pe aceasta s-a setat reteaua virtuala, Active Directory, serviciul de cloud asociat masinii si apoi s-a promovat aceasta masina ca si data center. Toate celelalte servere ce urmeaza a fi dezvoltate se vor monta pe masina gazda.

Pana la momentul prezentarii acestei parti, luand in calcul utilizarea unui cont de evaluare a platformei, care e free, nu s-a reusit montarea serverului de aplicatii appsserver1, pe masina gazda.

Crearea retelei virtuale Azure

Crearea unei retele virtuale Azure se face din portalul de management al administratorului, explorand optiunile puse la dispozitie de Microsoft.

Pasii pentru crearea retelei, precum si capturi de ecran aferente procesului, sunt redate mai jos.

Procedura:

Logare cu contul de Microsoft pentru care s-a efectuat subscrierea la serviciul de Microsoft Azure, pe site-ul: https://manage.windowsazure.com/

Pentru crearea unei retele virtuale, se face clic pe Retele -> Crearea unei retele virtuale. Se vor utiliza valorile din tabelul de mai jos pentru a finaliza expertul de configurare:

S-a experimentat crearea unei rețele virtuale Point-To-Site, în primă fază a dezvoltării.

Crearea unei rețele virtuale Point-To-Site

Se alege din Portalul de Management al Azure , colțul din stânga jos, New-Network Services – Virtual Network –Custom Create

Figura 13 – Creare rețea virtuală Windows Azure

Se ține cont de faptul că dorim o rețea cu două subrețele pentru care se vor configura IP-uri corespunzătoare. cele două subrețele vor fi împărțite în FronEndSubnet si BackEndSubnet, și resursele din centrul de date se vor partaja, în funcție de destinația/rolul mașinii virtuale pe una dintre aceste două dimensiuni. Rețeaua creată se va numi aii.pub.network.

Figura 14 – Preconfigurarea rețelei virtuale P2S

În secțiunea următoare, se atribuie adresa 192.168.10.139 pentru serverul DNS ți se selectează o conexiune de tipul P2S (Point-To-Site) pentru rețeaua nou creată.

Figura 15 – Configurarea conexiunii P2S

Pe pagina ce urmează, de conectivitate Point-to-Site, se specifică intervalul de adrese IP de la care clientii VPN vor primi o adresă IP atunci când sunt conectați. Există câteva reguli referitoare la intervalele de adrese pe care trebuie să le specificăm. Este foarte important ca domeniul pe care îl specificîm să nu se suprapună cu oricare dintre intervalele situate pe rețeaua locală a centrului de date.

Figura 16 – Adăugarea unui spațiu de adrese la conexiunea creată

Pentru spațiul de adrese se vor folosi următoarele valori:

Figura 17 – Configurarea spațiului de adrese ale conexiunii P2S

După setarea valorilor și a plajelor de adrese IP pentru conexiune, rețeaua este creată și va fi accesibilă din portalul de management al Azure.

Pentru rețeaua setată trebuie să configurăm și Gateway-ul corespunzător. Accesând rețeaua, în secțiunea Dashboard, se face click pe Create Gateway și Azure va crea automat serverul de Gateway atașat rețelei, generând IP corespunzător al acestuia.

Figura 18 – Configurarea gateway-ului pentru conexiunea P2S

Este important să specificăm Dynamic Routing la crearea Gateway-ului și trebuie știut că în funcție de regiunea setată la crearea rețelei, și crearea Gateway-ului poate varia între 5 și 20 minute.

Figura 19 – Gateway creat

După finalizarea Gateway-ului pentru rețeaua P2S, trebuie generate o pereche de certificate pentru client și pentru rețea. Certificatele sunt utilizate pentru a autentifica clienții VPN la VPN-ul P2S. Această procedură are mai multe etape.

O modalitate de a crea un certificat X.509 este cu ajutorul instrumentului de creare al certificatului (makecert.exe). Pentru a utiliza makecert, trebuie să descărcăm și să instalăm Microsoft Visual Studio Express 2013 pentru Windows Desktop, care este gratuit.

Navigăm în folderul Visual Studio Tools și lansăm linia de comandă ca administrator.

Comanda din exemplul de mai jos va crea și a instala un certificat rădăcină în depozitul de certificate personale de pe computer și va a crea, de asemenea, un fișier .cer corespunzător, pe care îl voi încărca mai târziu pe portalul de management.

Fișierul makecert.exe se regasește la C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\Shortcuts.

Comanda de generare a fișierului root, este următoarea:

makecert -sky exchange -r -n "CN=RootCertificateName" -pe -a sha1 -len 2048 -ss My "RootCertificateName.cer"

Se schimbă directorul în locația în care dorim ca fișierul .cer să fie situat și rulăm comanda de mai jos, în cazul în care RootCertificateName este numele pe care dorim să îl utilizăm pentru certificat. Dacă executăm, fără modificări, rezultatul va fi un certificat rădăcină numit RootCertificateName.cer.

Certificatul client se generează după ce, îîn prealabil s-a încărcat certificatul Root pe platforma de management Azure și s-a generat o cheie privată pentru client.

Figura 20 – Autorizarea instalării clientului VPN pentru conexiunea de tipul P2S

Cheia generată se va descărca direct de pe platformă, apoi se va da comanda:

care va genera certficatul client.

Certificatele generate sunt vizibile apoi în Active Directory-ul computerului pe care se lucreză, dând comanda certmgr în consola VS 2013 Express.

Figura 21 – Generarea certificatelor root și client

Ulterior, este nevoie ca certificatul client să fie exportat, pentru a fi folosit de o mașină virtuală, care se va conecte la rețeaua virtuală P2P creată.

Pentru acesta, se dă comanda certmgr.msc în consola VS 2013 Express și se exportă certificatul client, precum în imaginile de mai jos.

Cu click dreapta pe certificatul client, se alege All Tasks –Export.

Figura 22.a – Export certificat client

Figura 22 – b. Export certificat client, c. Conexiune finalizată

Pentru export se alege PKCS#12, incluzând și certificate path-ul corespunzător.

După ce certificatul client s-a exportat și s-a instalat pe computerul pe care se lucrează, se va descărca de pe portalul de management al Azure pachetul de configurare VPN client, din Dashboard, partea dreaptă a rețelei și se instalează pe computerul pe care lucrăm. Ulterior, ne și putem conecta la rețeaua creată, care e vizibilă în conexiunile de rețea. Testarea conexiunii existente se poate face în Command Prompt, ipconfig/all.

Figura 23 – Verificarea conexiunii în ipconfig

Pașii următori vizează o distribuție a serverelor, ca în figura de mai jos:

Figura 24 – Distribuția serverelor în rețea

Legătura dintre utilizatorii finali cu resursele din centrul de date se va face printr-un Load Balancer (LB), aceștia având acces la serverele web, de aplicații și de baze de date, toate situate pe același serviciu cloud, creat din portalul de management al utilizatorului administrator. Serviciul 2 de cloud, creat în aceiași manieră, cuprinde Active Directory-urile, Domain Controllerul și serverul DNS. Conexiunea dintre resursele din cloudul public susținut de Azure și mașinile on-premises, adică serverele centrului de date, se realizează printr-un sistem de tunneling VPN.

Crearea unei conexiuni Site-To-Site (S2S)

Cerințele preliminare de implementare ale unei rețele cu conectivitate S2S, prevăd ca dispozitivul VPN care va fi utilizat pentru conectarea la Windows Azure Gateway să aibă următoarea abilitate:

Suport complet pentru protocolul IPsec și suport complet pentru IKEv2 dacă alegerea de proiectare pentru conectivitate VPN S2S, este de a folosi rutarea dinamică (recomandat). În cazul implementării acestei rețele cu conectivitate S2S s-a folosit o rutare dinamică la configurarea Gateway-ului Azure.

Trebuie să ne conectați la portalul de management pentru a efectua această sarcină. În portal, se va crea o rețea virtuală personalizată care utilizează următorii parametri:

Grupul de afinitate al rețelei

Regiune: cea mai apropiată de rack-ul de servere al departamentului.

Server DNS: adresa IP a serverului DNS care va fi utilizat pentru această conectivitate. Deoarece serverele din Windows Azure au nevoie de această adresă pentru a efectua rezolvarea conflictelor de nume pentru a face parte din domeniu, acest lucru ar trebui să fie adresa IP a serverului local de DNS.

Conectivitatea S2S: Introducem adresa IP publică a dispozitivului local VPN selectat anterior.

Spațiu virtual de adrese de rețea: Se utilizează notația Classless Interdomain Routing (CIDR) pentru a specifica adresa privată (de exemplu, 0.0.0.0/8, 172.16.0.0/12, sau 192.168.0.0/16) în rețeaua de la Windows Azure.

Voi face o trecere prin pașii din portalul de management Azure pentru a crea un exemplu de cloud Azure rețea virtuală care conține două subrețele. Rețeaua virtuală rezultată va arata astfel:

Figura 25.a – Separarea rețelei în 2 subrețele

Figura 25.b – Detalierea conxiunii S2S

De exemplu, FrontEndSubnet ar putea fi utilizate pentru servere web și BackEndSubnet ar putea fi utilizate pentru servere SQL sau controlerele de domeniu, la fel ca în cazul configurării rețelei cu conectivitate P2P. Scenariul de configurare al rețelei S2S este asemănător celei P2P.

Selectarea ID-ului de rețea, trebuie să se facă diferit de ID-ul de rețea on-premise (de la nivelul local al departamentului). Acest lucru este necesar pentru a evita problemele de rutare între mașinile virtuale care se află în Windows Azure și computerele care se află la sediu departamentului.

Se va selecta o rețea pentru gateway, care este în același spațiu de adrese ca și subrețeaua în care mașinile virtuale vor locui. În această configurație, departamentul va gazdui toate mașinile virtuale pe o subrețea, și poarta de acces pentru Gateway-ul VPN S2S, va fi amplasată în rețeaua Gateway.

Figura 26 – Configurare gateway pentru conexiunea S2S

Rețeaua VPN cu conectivitate S2S creată este aii-dc-virtualnetwork și i s-a dăugat serverul de Gateway, a cărui adresă este vizibilă după adăugarea din portal.

Rețeaua aii-dc-hq, este rețeaua locală. Datorită lipsei unei interacțiuni cu serverele departamentului, nefuncționale în acest moment, datorită unor detalii legate de amenajare spațiului conform cerințelor unui centru de date, rețeaua aii-dc-hq va fi una fictivă, careia i se atribuie un IP de forma 3.2.1.1.

Pentru spațiul virtual al adreselor IP al rețelei configurate, s-au folosit următoarele setări :

Figura 27 a & b – Setarea spațiului de adrese pentru conexiunea S2S

La fel ca o rețea reală, rețeaua virtuală are nevoie de o serie de adrese IP (cunoscute ca spațiu de adrese) pentru a le atribui mașinilor virtuale pe care găzduiesc. Rețeaua virtuală cuprinde, de asemenea subrețele, care au nevoie de propriile spații de adrese, derivate din spatiul de adrese al rețelei virtuală. Vom crea BackEndSubnet și FrontEndSubnet. Pe pagina spațiilor de adrese de rețea virtuală, se configurează următoarele:

Pentru Adress Space IP/16 (65535) în notație CIDR

Pentru subrețele, în primul rând, tastăm BackEndSubnet pe numele existent și 10.0.1.0 pentru adresa de pornire, apoi selectăm / 24 (256), în CIDR. Facem clic pentru a adăuga o nouă subrețea, apoi tastăm FrontEndSubnet pentru adresa și 10.0.2.0 etc.

Deși s-a incercat crearea și unei rețele de tipul Point-To-Point pentru mediul de lucru, e recomandata folosirea unei tip de conexiuni Site-To-Site, mai ales că soluția finală este una de tip hibrid.

Pentru configurarea adresei IP de gateway vom folosi o rutare dinamică ca și în cazul unei conexiuni P2S.

Figura 28 – Creare Gateway pentru conexiunea S2S

Dispozitivul VPN local trebuie să fie configurat prin utilizarea unui set de parametri care se potrivește cu Windows Azure Gateway. Conexiunea IPsec trebuie să aibă setările care sunt descrise în tabelul de mai jos.

Tabelul 2 – Setarea dispozitivului VPN local conform Gateway-ul rețelei Azure

Generare adresei de IP alocate gateway-ului în rețeaua de conectivitate S2S ne furnizează și elemente necesare pentru conectarea la serverele locale, precum cheia comună și scriptul de configurare pe local.

Figura 29 – Managementul Gateway-ului al conexiunii S2S

Pentru a descărca scriptul de configurare VPN: Pe tabloul de bord, faceți clic pe Descărcare VPN Script dispozitiv.

Se alege tipul dispozitivului pe care dorim sa-l configuram din lista furnizata in portalul Azure.

Dupa descarcarea scriptului de configurare, se pot seta :

– politicile de securitate

– incoming tunnel

– outcoming tunnel

Rularea scriptului modificat va seta dispozitivul VPN corespunzator cerintelor.

Tabelul 3 – Rularea scriptului de configurare Gateway pe routerul on-premise

Crearea unei VM pentru a rula rolurile de controller de domeniu și Server DNS

Se vor repeta pașii următori pentru a crea masini virtuale pentru a găzdui rolul de Data Center, după cum este necesar. Este indicat să se aloce cel putin două domenii controller (DC) virtuale pentru a oferi toleranță la erori și redundanță. Daca reteaua virtuala Azure include cel putin doua DC, care sunt configurate în mod similar, atunci se seteaza VM Service care ruleaza aceste masini, într-un set de disponibilitate, pentru îmbunatatirea toleranta la erori.

În interiorul portalului Azure, se face clic pe Nou-Compute-Virtual Machine-Din galerie

Se utilizeaza urmatoarele valori pentru a finaliza expertul. Se accepta valoarea implicita pentru o setare, cu exceptia cazului în care o alta valoare este sugerata sau absolut necesar de a fi schimbata.

Figura 30 – a. Crearea VM, b. Configurarea VM

Mașina virtuală nou creată va avea configurațiile din figura din partea dreaptă. Se atribuie mașinii nou create o subrețea – cea de FrontEnd, configurată la setarea rețelei virtuale VPN P2S.

După ce mașina virtuală a fost creată, se va descărca fișierul de conectare Remote Desktop Protocol (RDP), direct din portalul de management și se va realiza conexiunea la mașina virtuală, utilizând utilizatorul și parola aferente contului setat la crearea mașinii. Se va observa că la intrarea pe server, conexiunea FrontEndSubnet atribuită este prezentă în rețelele disponibile ale serverului.

Figura 31 – Conectarea la mașina virtuală prin RDP

Următorul pas este să adăugăm un nou disc mașinii nou create, astfel încât acesta să servească drept spațiul de stocare pe server. Adăugarea unui nou disc la mașina virtuală se face tot din portalul de management al Azure, ca în figurile de mai jos.

Figura 32 – Atașarea unui disc de stocare la mașina creată

Este necesară formatarea discului nou adăugat, direct pe mașina virtuală setată, din Server Manager – Disks – Server and Disk. Discul se va numi F: după formatare și va servi drept spațiul de stocare auxiliar pe server.

Figura 33 – Prezența discului de stocare pe server în MyComputer

Din expertul de configurare din se observa alegerea configuratiei de sistem de operare Windows Server 2012 R2 Datacenter. Masina virtuala asociata data centerului va fi vizibila in tabloul general al portalului, si va fi denumita AIIDC.

Vom atasa un disc pentru fiecare VM care va rula pe serverul cu rol de DC. Este necesara crearea unui disc suplimentar pentru a stoca baza de date Active Directory, fisierele de loguri și Sysvol. Se specifica o dimensiune pentru disc (am atribuit 10 GB pentru masina virtuala a DC) și se lasa Preference Cache-Host setat la Niciunul.

La prima conectare a masinii virtuale AIIDC prin remote desktop connection, se seteaza din Server Manager-> Servicii de depozitare, un volum pe acest disc, folosind formatul de fisiere NTFS.

Figura 34– Prezența discului de stocare pe server în Server Manager

Se va rezerva o adresa IP statica pentru masini virtuale care va rula rolul Domain Controller. Pentru a rezerva o adresa IP statica, se va descarca Microsoft Web Platform Installer și se va instala Azure PowerShell și se va executa cmdlet-ul Set-AzureStaticVNetIP. Se va atribui IP-ul 198.162.10.27.

Instalarea Windows Active Directory Domain Server

Windows Active Directory Server se poate instala urmand indicatiile de la Microsoft, sau folosind aceeași rutina de pe masina virtuala locala . Estenevoie de a oferi acreditarile necesare de administrator pentru a instala acest forest.

Pentru a specifica locatia pentru baza de date Active Directory, forests, sysvol, se schimba locul de depozitare implicit de unitatea de sistem de operare pe discul de date suplimentar pe care îl avem atașat la VM. Dupa ce se termina instalarea serverului, se conecteaza la VM din nou și la implicit la Domain Controller.

Figura 35 – Instalarea WADS și crearea unui nou forest Azure

Pentru salvarea logurilor in configurarea Active Directory-ului, DNS-ului si Domain controllerului reprezentat de mașina virtuală abia creată se folosesc setările implicite din Server Manager-Manage-Add Roles and Features Wizard-Azdive Directory Install.

Adăugarea unei noi mașini virtuale și configurarea ei ca DNS server. Adăugarea Active Directory Domain Services

Pentru conectarea unei mașini virtuale noi la rețeaua dezvoltată cu conectivitate S2S, se procedează similar etapelor de mai sus.

Vom folosi o conexiune inițială la mașina nou creată de tipul Remote Desktop Protocol (RDP), pentru a testa accesibilitatea din tunelul VPN, care face legătura dintre centrul de date local și cel din cloud. Dezactivarea ulterioară a conexiunii RDP este recomandată, aceasta fiind o măsură de siguranță pentru a se asigura că mașinile virtuale sunt funcționle înainte de dezactivarea conexiunii RDP.

Figura 36 – Crearea unei noi mașini

Înainte de a promova serverul nou creat la un controler de domeniu, este important să efectuăm unele verificări de validare pentru a asigura că conectivitatea cu serverul local de resurse funcționează corect. Câteva teste care ar trebui să funcționeze în acest moment sunt:

Mașină virtuală a primit adresa IP a serverului DNS pe care l-am creat odată cu rețeaua virtuală cu conectvitate S2S.

Se poate testa conectivitatea de bază cu controlerul de domeniu local prin simpla tastare a unui ping la adresa IP a controlerului de domeniu, de pe serverul local.

După validarea configurației inițiale, se alăture acest server la domeniul local și se promovează mașina virtuala la stadiul de controller de domeniu. Pentru aceasta este necesară instalarea Active Directory Domain Services (AD DS), direct pe serverul dezvoltat anterior.

Configurarea AD DS pe mașina nou creată se face parcurgând următoarele etape:

La nivelul mașinii virtuale, în Server Manager, facem clic pe Manage-Adăugați roluri și caracteristici pentru a porni expertul de configurare.

Se alege tipul de instalare de bază

Selectarea serverului destinație, este selectarea serverului nou creat. Pe acest server se instalează instanța de AD DS.

Pentru a selecta servere la distanță, trebuie să cream mai întâi un bazin de servere (server pool) și să adăugăm serverele de la distanță

Pe pagina de selectare roluri pentru server, facem clic pe Active Directory Domain Services, apoi pe Adăugare Roluri și Caracteristici din caseta de dialog a expertului de configurare

Pe pagina de selectare a caracteristicilor, vom selecta orice caracteristici suplimentare pe care dorim să le instalați și facem clic pe Următorul. Aici putem alege diversele funcționalități pe care serverul să le îndeplinească. Azure nu permite implementarea unui server de sine stătător, din platforma pentru mail, însă putem folosi o soluție de SMTP Server pe care o putem selecta la acest pas al instalării. Se poate atribui serverului un rol de Web Server, caz în care putem selecta instanțe de Visual Studio sau de .NET Framework.

După instalarea AD DS, pe pagina de rezultate, se verifică dacă instalarea a reușit, și facem clic pe acest server pentru a-l promova drept un controler de domeniu și pentru a începe un nou expert de configurare.

Figura 37 – Promovarea mașinii ca și controller de domeniu

La promovarea serverului ca DomainController (DC), trebuie adăugat un forest la mașina creată. Se va atribuit ca și domeniu principal pentru acest forest aii.dc.pub.ro.

Figura 38 – Adăugarea unui nou forest la server.

La adăugarea unui nou Azure Forest în instanța de AD DS creată pe mașina virtuală, se va folosi setările predefinite Azure pentru configurare. Există posibilitatea definirii unei parole în cazul unei resetări ale serviciilor Active Directory pe mașina creată, caz în care se va efectua un backup pe acea mașină, iar setările proprii vor fi restaurate, odată cu restaurarea Active Directory Services.

Figura 39 – Setarea unei parole pentru DSRM

Figura 40 – Prezența AD DS și a serverului DNS pe serverul creat

5.4.1.2. Configurarea Active Directory Sites and Services

În mod implicit, site-urile Active Directory și serviciile au un singur site numit Default-First-Site-Name. Deși acest lucru nu este un pas obligatoriu, în mod ideal, ar trebui să creăn un alt site pentru a găzdui serverele care se află în Windows Azure. Ar trebui să se creeze și o nouă subrețea care se potrivește cu subrețeaua pe care am creat în Windows Azure rețeaua virtuală. Acest lucru devine foarte important atunci când avem un mediu de lucru mare și avem nevoie de a optimiza replicarea între controlerele de domeniu. După ce s-a creat o nouă subrețea și site-ul care se aliniază cu serverele situate în Windows Azure, trebuie să mutăm controlerul de domeniu care se află în Windows Azure pe noul site pe care l-ați creat pentru Windows Azure.

Secțiunea Active Directory Sites and Services va arăta precum în figura 41, din dreapta paginii.

Trebuie precizat că toate aceste operații asupra mașinii virtuale s-au efectuat de fapt pe mașina virtuală AIIDC, conectată la o rețea cu conectivitate P2P, din lispa posibilității de accesare a mașinii virtuale aiidc1, cu o conectivitate S2S și la care o rețea locală nu este existentă, astfel încât să permită rularea serviciilor.

La crearea mașinilor virtuale rămase din arhitectura pe care dorim s-o adoptăm pentru centrul de date al departamentului AII în Windows Azure, trebuie să se asigure celelalte mașini care se vom mai proviziona, sunt legate de mașina virtuală existentă și că au aceeași regiune, același grup de afinitate, și setările de rețea virtuală sunt identice cu mașina virtuală inițială. De asemenea, trebuie ca mașinile să facă parte din același serviciu de cloud ca și celelalte mașini virtuale. Reamintesc faptul că, la crearea unei mașini virtuale se poate crea totodată și un serviciu de cloud pe portalul de management, sau se poate atribui la o mașină în mod manual sau automat, un serviciu cloud existent.

Prin urmare, noua mașină virtuală nu poate avea conectivitate cu alte mașini virtuale care vor fi instanțiate. Pentru scenariul soluției de cloud hibrid pe care prezenta lucrare o adresează, următoarele mașini virtuale trebuie prevazute în acest moment:

Un controler de domeniu suplimentar de a replica DC inițial

Două servere de web front-end

Toate acestea menționate sunt servere sau mașini virtuale cu aceiași configurație ca și mașina aiidc1, și pentru a le construi vom folosi aceleași etape ca și cele descrise în secțiunea de crearea a unei mașini virtuale cu Windows Azure, prin urmare, nefiind necesară detalierea pașilor. Toate serverele nou create se regăsesc pe contul propriu de Windows Azure, însă pentru acestea nu s-a făcut nicio altă configurare decât cea inițială.

Figura 42 – Adăugare de servere suplimentare, prezente în Windows Azure Portal

Până în acest moment s-a reușit adăugarea de mașini virtuale Azure, configurarea unui controller domain pentru o rețea virtuală creată și adăugarea de alte mașini la aceiași rețea. Limitări legate de funcționalitatea on-premise a departamentului sau de costuri de implementare Azure nu au permis obținerea decât a unei soluții de cloud hibrid mai degrabă teoretică. Partea finală a lucrării, cea de dezvoltări ulterioare și concluzii cuprinde pași pe care i-am prevăzut în dezvoltare și care deși nerealizați au fost studiați în raport cu ceea ce platforma de cloud pusă la dispoziție de Windows oferă. Trebuie și este foarte important de precizat, că pentru moment, soluția de cloud hibridă fiind găzduită pe un cont de trial, mașinile virtuale tebuie oprite pe durata nefuncționării, deoarece sunt taxate conform planului de taxe și costuri Azure, pentru găzduire.

Dezvoltări viitoare și concluzii

Tehnologiile de virtualizare au depasit de mult stadiul de experiment, fiind folosite pe scara larga in zilele noastre pentru o gama larga de servicii. Dar cea mai spectaculoasa utilizare a virtualizarii se dovedeste a fi in data center pentru eficientizarea utilizarii resurselor si asigurarea flexibilitatii cerute de implementarea proiectelor noi.

In acceptiunea de baza, tehnologia de virtualizare inseamna utilizarea resurselor unui server fizic (procesoare, memorie, discuri, placa de retea) de catre mai multe masini virtuale, prin multiplexarea acestor resurse de catre un sistem software numit hypervizor. Astfel fiecare masina virtuala are impresia ca ruleaza pe un sistem dedicat, putandu-se astfel inghesui mai multe masini virtuale pe un server fizic, in functie de cat de puternica este aceasta si de resursele consumate de masinile virtuale.

Din studiul platformei Azure, am remarcat o serie de avantaje si dezavantaje ca solutie practica de implementare la nivel de data center.

De exemplu, ca și în alte servicii cloud, Windows Azure faciliteaza abonarea pe baza de utilizare. Ce înseamna acest lucru este ca, daca aplicam doar pentru doua cazuri de servicii achizitionate la început, vom plati doar pentru aceste doua cazuri. Taxarea se face in plus pentru cazuri suplimentare. Acest model de tarifare face Windows Azure o platforma mare pentru aplicatii care necesita uneori mult mai multe resurse decat in mod normal. Se elimina complet necesitatea de a achizitiona hardware și software scump pentru construirea de aplicatii.

Cunoașterea avantajele și dezavantajele de Windows Azure este importanta, mai ales din punct de vedere al costurilor si ceea ce se are in vedere la dezvoltarea unui centru de date pe aceasta platforma. Trebuie analizate costurile pentru implementarea unor servicii in plus fata de cele minim necesare in proiectarea unui data center, cu cerintele departamentului.

Desfasurarea proiectului a vizat intai implementarea arhitecturii prin intermediul masinilor virtuale care sa emuleze functionalitatea corecta a serverelor. In acest sens solutia practica prezentata, reprezinta un punct de start fiabil. Urmatoarea etapa ar fi trebuit sa fie cea de montare a dulapului de servere si conectarea lor; Notiunile teoretice de securitate precum si implementarea securitatii se va face direct pe servere, unde se vor instala aplicatii pentru web, stocare datelor serviciu de comunicare interna si e-mail etc.

Procesul de implementare si dezvoltare a securitatii data centerului va fi finalizat in prima faza prin virtualizarea mediului, vizand ca data centerul sa fie in viitor independent si sa asigure toate functionalitatile departamentului. Până în acel moment, am vizat abordarea unei soluții de cloud hibrid, care să constituie baza de așezare a serverelor fizice, prin imbinarea tehologiei Azure de cloud public cu rețeaua locală, de cloud public. Deși abordarea din perspectiva dualității cloud public – privat poate fi privită cu suspiciune, față de abordarea unei soluții de cloud tradiționale sau a uneia de cloud exclusiv public, este mai avantajoasă. Astfel, deși mai costisitoare, infrastructura ca și serviciu pusă la dispoziție de Microsoft prin platforma Windows Azure deleagă în mod clar responsabilități arhitectului de platformă, ale administratorului de rețea și cele de suport privind cloud-ul public. Este mai ușoară așadar gestiunea resurselor, iar SLA-ul Microsoft garantează disponibilitatea și securitatea serverelor, precum și continua lor funcționare 99.99% din timpul în care sunt găzduite pe platformă.