Construirea unei arhitecturi private cloud de la microsoft

Există multe definiții ale cloud computing, dar cel mai amplu și mai recunoscut este Institutul Național de Standarde și Tehnologie (NIST). NIST a identificat cinci caracteristici principale, trei modele de servicii și patru modele de implementare. În ansamblu, cinci caracteristici constituie o definiție, adică doar o soluție cu următoarele caracteristici poate fi numită "nor":







  • self-service la cerere;
  • canal de rețea largă;
  • sprijin pentru bazine de resurse;
  • scalabilitate rapidă (elasticitate);
  • măsurabilitatea consumului de servicii.
    De asemenea, NIST a identificat trei modele de servicii sau, așa cum sunt uneori numite, niveluri arhitecturale:
  • infrastructura ca serviciu (Infrastructura ca serviciu, IaaS);
  • Software-ul ca serviciu (Software as a Service, SaaS);
  • platforma ca serviciu (platforma ca serviciu, PaaS).
    În cele din urmă, NIST a identificat patru modele de implementare:
  • privat nor;
  • norul general (Cloud Community);
  • nor public;
  • hibrid cloud (Cloud Hybrid).
    Cunoașterea cloud-ului

    În echipa Microsoft Services, a fost proiectată, dezvoltată și implementată o soluție privată Cloud / IaaS bazată pe Windows Server, Hyper-V și System Center. De-a lungul acestei serii de articole, vom arăta cum puteți integra și implementa fiecare produs component ca o soluție și, în același timp, pentru a oferi astfel de atribute nor de bază, cum ar fi elasticitatea, suport pentru bazine de resurse, și auto-service.

    Ca o definiție exhaustivă a norului, vom folosi modelele de implementare NIST. Termenul "cloud privat" va fi utilizat în contexte diferite fără a specifica modelul de serviciu în cauză.

    În plus față de caracteristicile descrise în definiția NIST, vom stabili câteva cerințe suplimentare pentru acest proiect:

  • prioritatea stabilității înainte de redundanță;
  • omogenitate și standardizare;
  • sprijin pentru bazine de resurse;
  • virtualizare;
  • Managementul structurii de țesături;
  • elasticitate;
  • împărțirea resurselor comune;
  • transparența calculării plății pentru utilizarea cloud-ului.
    Într-una dintre echipe, Microsoft a adunat și a definit aceste principii. Echipa a apreciat activitatea organizației Foundation Global Services (SFG), centrele noastre de date la nivel mondial sunt responsabile de, departamentul MSIT, care rulează infrastructura și aplicațiile Microsoft, precum și mai mulți clienți majori, au fost de acord să participe la studiu. Înarmat cu definițiile de mai sus și cerințele acceptate, am trecut la faza de proiectare a arhitecturii. Aici am definit cerințele și am creat modelul de arhitectură corespunzător.

    Arhitectura de baza Private Cloud / IaaS


    Fig. 1. Bazele arhitecturii de bază

    Nivelul echipamentului include echipamente de centre de date și sisteme mecanice, precum și subsistemul de stocare, infrastructura de rețea și de calcul. Pentru a interacționa cu straturile de arhitectură de mai sus, fiecare dintre aceste elemente trebuie să furnizeze interfețe de management. În Exemplele includ servere de sprijin interfețe Web Services-Management (WS-Management) și matricele de stocare, sunt furnizate pe baza interfeței Windows PowerShell, sau SMI-S (Inițiativa Storage Management - Specificații).

    În Microsoft susține că programul Hyper-V Cloud FastTrack este proiectat pentru a combina software-ul Microsoft, standardele unificate, derivate de la partenerii OEM, configurații validate pentru calcul, rețele și depozitare, precum și componente software suplimentare pentru a crea un nor de soluții particulare. Companiile precum Hewlett-Packard Co. Dell Inc. IBM Corp. Fujitsu, Hitachi Ltd. și NEC Corp. sunt parteneri ai FastTrack și oferă soluții integrate și dovedite la nivel de echipament.

    Nivelul de virtualizare urmează nivelul de automatizare (Figura 2). Nivelele de automatizare, management și orchestrație sunt construite de la mai mici la mai mari, în conformitate cu procesul de automatizare IT. Cel mai mic dintre acestea - nivelul de automatizare - include tehnologii precum Windows PowerShell 2.0, Windows Management Instrumentation (WMI) și WS-Management. Aceste tehnologii fundamentale oferă o interfață între nivelurile mai ridicate ale sistemelor de control și resursele fizice și virtuale.


    Fig. 2. Modelul de arhitectură folosit pentru a construi modelul cloud privat

    Într-o formă explicită, acest nivel nu este, de obicei, găsit în structurile IT tradiționale, dar este extrem de important pentru a furniza semnele unui nor. Conectează o mulțime de produse, tehnologii și procese care permit automatizarea proceselor IT. System Center Configuration Manager automatizează implementarea patch-uri, dar integrarea cu întreținerea și sistemul de management sau de produse suplimentare de la terți și soluții necesită o coordonare (orchestrație), prin procese în care a implicat o varietate de produse.

    Pentru a implementa acest nivel, utilizați System Center Opalis (numele său va fi în curând înlocuit de System Center Orchestrator). Opalis integrează suita System Center și facilitează integrarea cu o varietate de soluții terță parte și partener. Nivelul de orchestrare vă ajută să creați fluxuri de lucru sau sarcini pentru a automatiza sarcini complexe, cum ar fi implementarea clusterelor, patch-uri pe gazde și pregătirea mașinilor virtuale pentru lucru.

    Interfețe utilizator și administrator de interfață

    Pentru multe organizații IT, caracteristica de auto-service la cerere sau la serviciul de self-service definit în NIST este o noutate perfectă. În primul rând, vorbim despre eliminarea barierelor dintre nevoile utilizatorilor în resurse IT și posibilitatea de a le furniza. De exemplu, în anumite organizații, de la momentul în care trimiteți o cerere de instalare a unui nou server la disponibilitatea imediată de a lucra, durează până la șase luni. Limitările procesului și ale tehnologiei conduc la întârzieri.

    Caracteristica de auto-service necesită o nouă interfață care oferă utilizatorilor posibilitatea de a solicita resurse. De cele mai multe ori, acest lucru este implementat ca un portal IT self-service, unde utilizatorii pot găsi un catalog de servicii din care să aleagă cel potrivit, de exemplu, instalând o nouă mașină virtuală.







    În arhitectura noastră de bază am definit atât o interfață de auto-service, cât și o interfață centralizată de administrator IT. Pentru a crea o interfață de utilizator Microsoft sugerează folosind System Center Virtual Machine Manager de (VMM) Self-Service Portal 2.0, precum și pentru scripturi personalizate și Hosting - dinamic Datacenter Toolkit pentru Hosters (DDTK-H). Soluția noastră utilizează o versiune individuală a DDTK-H datorită nevoii de configurare și automatizare specială. Ne așteptăm ca în viitoarele produse Microsoft să existe soluții mai gata.

    Interfața administratorului este creată utilizând Managerul de servicii de sistem System Center (SCSM) și interfețele System Center. SCSM este cel mai nou produs al Microsoft. Oferă o bază de date pentru gestionarea configurației (CMDB), precum și o soluție robustă de gestionare a schimbărilor. În soluția noastră, toate operațiunile standard sunt formate ca cereri de modificări în SCSM. Ei inițiază fluxuri automate de lucru în Opalis. Așadar, asigurăm o gestionare corectă a schimbărilor, oferind capabilități avansate de automatizare.

    Modelul logic Private Cloud / IaaS

    Una dintre diferențele cheie dintre un cloud privat și centrele de date tradiționale și infrastructurile de servere este abstractizarea din resurse fizice, cum ar fi servere, rețele și resurse de disc. Ei se unesc la un nivel superior în bazine de resurse, domenii defecte, reînnoirea domeniului și așa mai departe .. Aceste asocieri sunt logice la infrastructura fizică și de a ajuta să ia decizii în cunoștință de cauză cu privire la pregătirea și gestionarea resurselor. Pentru arhitectura noastră de bază, am ales un model logic, bazat pe rezultatele lucrărilor efectuate de Microsoft Global Foundation Services, Windows Azure și MSIT (Figura 3).


    Fig. 3. Modelul logic al grupării Private Cloud / IaaS

    Definițiile obiectelor sunt după cum urmează.

    Structura infrastructurii IaaS Toate infrastructurile și sistemele din cadrul managementului arhitecturii de bază. Fabricul poate consta din multe site-uri și centre de date.

    Centrul de date / site-ul Locul sau locația fizică a unui site al uneia sau mai multor grupuri de resurse.

    Resursă de resurse Un pool de resurse care include un server, o rețea și un spațiu de stocare oferă echipamente partajate și parametri de configurare inițiali. Nu împărtășesc un singur punct de eșec cu niciun alt fond de resurse (cu excepția nevoilor proprii). Resursa de resurse poate fi împărțită în domenii defecte, definind un domeniu defect ca un grup de componente de infrastructură cu o configurație comună pentru toți, care nu împărtășește un singur punct de eșec cu niciun alt domeniu defect. Pentru simplitate în soluția noastră, grupul de resurse și domeniul defect sunt echivalente.

    Unitate de scalare Acesta este un set format dintr-un server, rețea și dispozitiv de stocare și implementat ca un singur modul. Acesta este cel mai mic modul care este implementat în structura centrului de date. În funcție de dimensiunea consumatorului, acesta poate fi un cluster cu patru noduri Hyper-V sau un rack complet de 64 de servere blade. Dimensiunea componentei este de obicei specificată pe baza cererii medii trimestriale pentru resurse noi. În loc să desfășurați un server separat ori de câte ori aveți nevoie de resurse suplimentare, puteți implementa componenta pentru a satisface nevoia și a păstra oportunitatea de creștere.

    Host Cluster Acesta este un grup care include două până la șaisprezece servere Hyper-V într-o configurație cluster failover și rețelele asociate și spațiul de stocare.

    Domeniul de actualizare Acesta este un set de elemente de infrastructură din bazinul de resurse care poate fi întreținut, dezactivat sau actualizat fără a provoca timpi de nefuncționare pentru mașinile virtuale sau fluxurile de lucru care rulează în grupul de resurse. În această arhitectură, fiecare nod din fiecare grup de baze de resurse formează un domeniu de actualizare. Din moment ce fiecare grup are un nod de rezervă (15 + 1), puteți păstra un nod în fiecare cluster fără perioade de nefuncționare (SMV migrează prin cluster-ul pentru a efectua operațiuni de întreținere). Deci, toate nodurile din aceeași grupă de resurse formează un domeniu de actualizare, nodurile următoare se află în al doilea domeniu de actualizare și așa mai departe (Figura 4).


    Fig. 4. Piscină de resurse cu unități de scalare a copilului

    Necesitatea identificării și implementării acestor containere se datorează faptului că acestea pot automatiza inițierea și gestionarea intelectuală. De exemplu, atunci când lucrați cu o fermă web de patru servere, trebuie să fiți sigur de disponibilitatea ridicată a cel puțin unuia dintre site-uri în caz de eșec. Trebuie doar să vă asigurați că cererea de inițiere este distribuită în două site-uri și două sau mai multe baze de resurse. Acest lucru este asigurat de definirea bazinelor de resurse și de legătura lor cu infrastructura fizică. Organizarea corectă a mașinilor virtuale vă permite să obțineți flexibilitatea serviciului.

    Implementarea de bază a Cloud-ului privat / IaaS

    Separarea logică și fizică a platformei de management de platforma de găzduire a mașinilor virtuale ajută la scalarea fiecăruia în mod independent (Figura 5). În centrul circuitului din Fig. Figura 5 prezintă resursele de resurse din cadrul sistemului de gestionare și întreaga soluție, care poate fi implementată într-un centru de date existent.


    Fig. 5. Diagrama logică a implementării arhitecturii

    Implementarea automată este unul din elementele cheie ale implementării de bază, care servește la îmbunătățirea și accelerarea implementării și implementării succesiunii. Acesta este cazul, deoarece Microsoft Services lucrează cu o gamă largă de parteneri și consumatori. Pentru a automatiza implementarea, implementarea de bază oferă un set gratuit de instrumente Microsoft Deployment Toolkit (MDT) și Microsoft Hydration Framework Services. MDT extinde automatizarea implementării.

    Definirea zonelor detaliate de proiecte obligatorii este următorul pas în procesul de proiectare. Iată următoarele domenii:

  • proiect detaliat al fiecărui produs de sistem Center;
  • Proiectare detaliată a infrastructurii de gestionare a structurilor Fabric;
  • Inițierea managementului structurii Fabric;
  • proiectarea unităților de scalare;
  • pregătirea unităților de scalare;
  • proiectarea proceselor de lucru.
    Arhitectura de bază oferă toate caracteristicile cloud-ului în conformitate cu definiția NIST și cu mecanismul de automatizare IT avansată. La alegerea scenariului de automatizare, ne-am concentrat pe o complexitate sporită, costuri mai mari și riscuri de erori ale utilizatorilor în scenarii. În acest scop, soluția automatizează următoarele procese:

    Instalarea controlului structurii de material:

  • implementarea gestiunii Hyper-V Host;
  • implementarea unui cluster virtual virtualizat;
  • Implementarea VMM;
  • implementarea SCSM;
  • Implementarea System Center Operations Manager (SCOM);
  • Implementați System Center Configuration Manager (SCCM);
  • implementarea System Center Opalis;
  • personalizare și personalizare;
    Pregătirea unității de scalare (cluster gazdă) pentru funcționare:
  • instalarea unui OS "curat";
  • Instalarea Hyper-V;
  • Configurați grupul;
    instalarea de fixări ale unităților scalare (cluster gazdă):
  • orchestreaza migrarea masinilor virtuale de la gazde pentru a instala patch-uri folosind modurile de suport VMM si SCOM pentru fiecare domeniu de actualizare;
  • Ochestrarea SCCM pentru a instala remedierile rapide pentru gazde și pentru a verifica instalarea cu succes a patch-urilor;
  • eliminați gazdele din modul de asistență și accesați următorul domeniu de actualizare;
    gazdă suport:
  • orchestrarea migrației live a mașinilor virtuale de la gazdele care necesită suport, utilizând modurile de suport VMM și SCOM;
  • eliminarea gazdei din modul de suport;
    Pregătirea unei mașini virtuale:
  • oferind posibilitatea de a iniția o mașină virtuală printr-o interfață de portal;
  • Opalis acceptă cereri de pregătire pentru muncă și efectuează orchestrarea pregătirii mașinilor virtuale prin șabloane preconfigurate;
  • Opalis verifică dacă a fost creată o mașină virtuală și vizibilitatea acesteia este vizibilă în toate produsele System Center;
  • Opalis instalează agentul SCOM pe mașinile virtuale necesare;
  • Mașinile virtuale devin disponibile și sunt gata de gestionare prin interfața portalului;
    anularea inițierii unei mașini virtuale:
  • Creați o solicitare de anulare a inițierii mașinii virtuale prin interfața portalului;
  • Opalis acceptă cereri de anulare a inițierii, șterge mașina virtuală din toate produsele System Center și apoi șterge automat mașina virtuală;
  • Opalis șterge contul Active Directory al mașinii virtuale și înregistrarea A în DNS.
    În următorul articol din această serie, vom studia structura de management de proiect detaliat arhitectura Fabric, inclusiv proiectul Hyper-V, structura de management de proiect de cluster Fabric de cluster SQL virtualizat și proiectarea fiecăruia dintre produsele System Center. În plus, vom vorbi despre unitatea de proiect de scalare ce conține Hyper-V grupuri de 16 noduri.






    Trimiteți-le prietenilor: