{"id":38966,"date":"2019-10-31T22:27:03","date_gmt":"2019-10-31T19:27:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/admin-bez-ruk-giperkonvergentsiya\/"},"modified":"2019-10-31T22:27:03","modified_gmt":"2019-10-31T19:27:03","slug":"admin-bez-ruk-giperkonvergentsiya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/admin-bez-ruk-giperkonvergentsiya","title":{"rendered":"Admin f\u0103r\u0103 m\u00e2ini = hiperconvergen\u021b\u0103?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Admin
\n\"Admin
\n
\nAcesta este un mit destul de r\u0103sp\u00e2ndit \u00een domeniul echipamentului server. \u00cen practic\u0103, solu\u021biile hiperconvergente (c\u00e2nd totul este integrat) sunt necesare din multe puncte de vedere. Istoric, primele arhitecturi au fost dezvoltate de Amazon \u0219i Google pentru serviciile lor. Atunci ideea era s\u0103 se creeze o ferm\u0103 de calcul din noduri identice, fiecare av\u00e2nd propriile discuri. Totul era integrat printr-un software sistemic (hypervisor) \u0219i fragmentat \u00een ma\u0219ini virtuale. Principala sarcin\u0103 era minimizarea eforturilor pentru \u00eentre\u021binerea unui nod \u0219i minimizarea problemelor la scalare: pur \u0219i simplu se mai ad\u0103ugau \u00eenc\u0103 o mie-dou\u0103 de servere asem\u0103n\u0103toare \u0219i se conectau al\u0103turi. \u00cen practic\u0103, acestea sunt cazuri rare, iar mai des se vorbe\u0219te despre un num\u0103r mai mic de noduri \u0219i o arhitectur\u0103 pu\u021bin diferit\u0103. <\/p>\n

Dar avantajul r\u0103m\u00e2ne acela\u0219i \u2013 o scalare \u0219i o gestionare incredibil de simpl\u0103. Dezavantajul \u2013 diferitele sarcini consum\u0103 resurse \u00een mod diferit \u0219i, \u00een unele locuri, pot fi multe discuri locale, \u00een altele, pu\u021bin\u0103 memorie RAM \u0219i a\u0219a mai departe, deci, \u00een func\u021bie de tipul sarcinii, utilizarea resurselor va sc\u0103dea. <\/p>\n

Se dovedea c\u0103 pl\u0103ti\u021bi cu 10\u201315% mai mult pentru confortul configur\u0103rii. Aceasta a generat mitul din titlu. Am c\u0103utat mult timp unde ar putea fi utilizat\u0103 tehnologia optim, \u0219i am g\u0103sit. Problema era c\u0103 Cisco nu avea propriile solu\u021bii de stocare, dar vroiau s\u0103 acopere \u00eentreaga pia\u021b\u0103 a serverelor. \u0218i au creat Cisco Hyperflex \u2013 o solu\u021bie cu stocare local\u0103 pe noduri. <\/p>\n

\u0218i din aceasta a rezultat o solu\u021bie foarte bun\u0103 pentru centrele de date de rezerv\u0103 (Disaster Recovery). De ce \u0219i cum \u2013 voi explica acum. \u0218i voi ar\u0103ta teste ale clusterului. <\/a><\/noindex><\/p>\n

Acolo unde este nevoie<\/h3>\n

\nHiperconvergen\u021ba este: <\/p>\n

    \n
  1. Transferul discurilor \u00een nodurile de calcul.<\/li>\n
  2. Integrarea complet\u0103 a subsistemului de stocare cu subsistemul de virtualizare.<\/li>\n
  3. Transferul\/integrarea cu subsistemul de re\u021bea.<\/li>\n<\/ol>\n

    \nAceast\u0103 leg\u0103tur\u0103 permite implementarea multor func\u021bii ale solu\u021biilor de stocare la nivelul virtualiz\u0103rii, totul dintr-o singur\u0103 interfa\u021b\u0103 de gestionare.<\/p>\n

    \u00cen compania noastr\u0103, proiectele de proiectare a centrelor de date de rezerv\u0103 sunt foarte solicitate, iar solu\u021biile hiperconvergente sunt adesea alese datorit\u0103 numeroaselor op\u021biuni de replicare (p\u00e2n\u0103 la metrokluster) din cutie. <\/p>\n

    \u00cen cazul centrelor de date de rezerv\u0103, de obicei, ne referim la o loca\u021bie \u00eendep\u0103rtat\u0103 situat\u0103 la marginea ora\u0219ului sau chiar \u00eentr-un alt ora\u0219. Aceasta permite restaurarea sistemelor critice \u00een cazul unei defec\u021biuni par\u021biale sau complete a centrului de date principal. Datele sunt repliocate constant de la v\u00e2nzare, iar aceast\u0103 replicare poate fi efectuat\u0103 la nivel de aplica\u021bie sau la nivel de dispozitiv de stocare (SDS).<\/p>\n

    Prin urmare, voi discuta acum despre structura sistemului \u0219i teste, iar apoi \u2014 despre c\u00e2teva scenarii reale de aplicare cu date despre economii. <\/p>\n

    Teste<\/h3>\n

    \nInstan\u021ba noastr\u0103 const\u0103 din patru servere, fiecare av\u00e2nd 10 SSD-uri de 960 GB. Exist\u0103 un disc dedicat pentru cache-ul opera\u021biunilor de scriere \u0219i stocarea unei ma\u0219ini virtuale de servicii. Solu\u021bia \u00een sine este a patra versiune. Prima a fost evident nefinisat\u0103 (conform recenziilor), a doua era \u00eenc\u0103 pu\u021bin lipsit\u0103 de rafinament, a treia este deja suficient de stabil\u0103, iar aceasta poate fi considerat\u0103 o versiune de lansare dup\u0103 \u00eencheierea test\u0103rii beta pe scar\u0103 larg\u0103. \u00cen timpul test\u0103rii, nu am \u00eent\u00e2mpinat probleme, totul func\u021bioneaz\u0103 ca un ceas.<\/p>\n

    Modific\u0103ri \u00een v4<\/b>O mul\u021bime de erori au fost corectate. <\/p>\n

    Ini\u021bial, platforma putea lucra doar cu hypervisorul VMware ESXi \u0219i sus\u021binea un num\u0103r mic de noduri. De asemenea, procesul de implementare nu se \u00eencheia \u00eentotdeauna cu succes, trebuia s\u0103 repornesc anumite etape, erau probleme cu actualizarea de la versiuni mai vechi, datele din GUI nu se afi\u0219au \u00eentotdeauna corect (de\u0219i nici acum nu sunt pe deplin mul\u021bumit de afi\u0219area graficelor de performan\u021b\u0103), uneori ap\u0103reau probleme la interfa\u021ba cu virtualizarea.<\/p>\n

    Acum toate problemele ini\u021biale au fost corectate, HyperFlex suport\u0103 at\u00e2t ESXi, c\u00e2t \u0219i Hyper-V, plus c\u0103 este posibil:<\/p>\n

      \n
    1. Crearea unui cluster extins. <\/li>\n
    2. Crearea unui cluster pentru birouri f\u0103r\u0103 utilizarea Fabric Interconnect, de la dou\u0103 la patru noduri (cump\u0103r\u0103m doar serverele).<\/li>\n
    3. Posibilitatea de a lucra cu SDS externe.<\/li>\n
    4. Suport pentru containere \u0219i Kubernetes.<\/li>\n
    5. Crearea zonelor de disponibilitate.<\/li>\n
    6. Integrarea cu VMware SRM, dac\u0103 func\u021bionalitatea \u00eencorporat\u0103 nu este satisf\u0103c\u0103toare.<\/li>\n<\/ol>\n

      Arhitectura nu se deosebe\u0219te mult de solu\u021biile principalelor competitori, nu s-a reinventat roata. Toate acestea func\u021bioneaz\u0103 pe platforma de virtualizare VMware sau Hyper-V. Tehnologia este implementat\u0103 pe servere dezvoltate intern de Cisco UCS. Exist\u0103 persoane care ur\u0103sc platforma din cauza complexit\u0103\u021bii ini\u021biale a configur\u0103rii, a numeroaselor butoane, a sistemului de \u0219abloane \u0219i dependen\u021be neintuitive, dar exist\u0103 \u0219i cei care au \u00eenv\u0103\u021bat s\u0103 o aprecieze, s-au ata\u0219at de idee \u0219i nu mai doresc s\u0103 lucreze cu alte servere. <\/p>\n

      Vom examina exact solu\u021bia pentru VMware, deoarece aceasta a fost dezvoltat\u0103 ini\u021bial pentru acesta \u0219i ofer\u0103 un func\u021bionalitate mai mare, \u00een timp ce Hyper-V a fost adaptat pe parcurs pentru a nu r\u0103m\u00e2ne \u00een urm\u0103 fa\u021b\u0103 de competitori \u0219i pentru a r\u0103spunde a\u0219tept\u0103rilor pie\u021bei.<\/p>\n

      Exist\u0103 un cluster de servere echipate cu discuri. Exist\u0103 discuri pentru stocarea datelor (SSD sau HDD \u2014 alegerea este a dumneavoastr\u0103, \u00een func\u021bie de necesit\u0103\u021bi), plus un disc SSD pentru caching. Atunci c\u00e2nd se scriu date pe datastore, acestea sunt salvate pe stratul de caching (disc SSD dedicat \u0219i RAM-ul ma\u0219inii virtuale de serviciu). \u00cen paralel, un bloc de date este trimis c\u0103tre nodurile din cluster (num\u0103rul de noduri depinde de factorul de replicare al clusterului). Dup\u0103 confirmarea scrierii reu\u0219ite de c\u0103tre toate nodurile, confirmarea este trimis\u0103 hiper-vizorului \u0219i mai departe c\u0103tre ma\u0219ina virtual\u0103. Datele scrise sunt deduplicat, compresate \u0219i stocate pe discurile de stocare \u00een fundal. \u00cen acest mod, pe discurile de stocare se scrie \u00eentotdeauna un bloc mare de date, consecutiv, ceea ce reduce sarcina pe discurile de stocare.<\/p>\n

      Deduplicarea \u0219i compresia sunt activate constant \u0219i nu pot fi dezactivate. Citirea datelor se face direct de pe discurile de stocare sau din cache-ul RAM. Dac\u0103 se folose\u0219te o configura\u021bie hibrid\u0103, citirea este, de asemenea, stocat\u0103 \u00een cache pe discul SSD.<\/p>\n

      Datele nu sunt legate de loca\u021bia actual\u0103 a ma\u0219inii virtuale \u0219i sunt distribuite uniform \u00eentre noduri. Aceast\u0103 abordare permite o \u00eenc\u0103rcare uniform\u0103 a tuturor discurilor \u0219i interfe\u021belor de re\u021bea. Un dezavantaj evident este c\u0103 nu putem minimiza la maxim \u00eent\u00e2rzierea citirii, deoarece nu exist\u0103 nicio garan\u021bie c\u0103 datele sunt disponibile local. Dar consider c\u0103 este o renun\u021bare nesemnificativ\u0103 \u00een compara\u021bie cu avantajele ob\u021binute. Mai ales c\u0103 \u00eent\u00e2rzierea \u00een re\u021bea a atins valori astfel \u00eenc\u00e2t s\u0103 nu influen\u021beze semnificativ rezultatul total.<\/p>\n

      Toat\u0103 logica de func\u021bionare a subsistemului de stocare este gestionat\u0103 de o ma\u0219in\u0103 virtual\u0103 de serviciu special\u0103, Cisco HyperFlex Data Platform controller, care este creat\u0103 pe fiecare nod de stocare. \u00cen configura\u021bia noastr\u0103, ma\u0219inii virtuale de serviciu i-au fost alocate opt vCPU \u0219i 72 GB RAM, ceea ce nu este deloc pu\u021bin. Amintesc c\u0103 hostul are disponibili 28 de nuclee fizice \u0219i 512 GB RAM.<\/p>\n

      Ma\u0219ina virtual\u0103 de serviciu are acces direct la discurile fizice prin intermediul controller-ului SAS. Comunica\u021bia cu hypervisorul se realizeaz\u0103 printr-un modul special, IOVisor, care intercepta opera\u021biile de intrare-ie\u0219ire, \u0219i printr-un agent care permite transmiterea comenzilor c\u0103tre API-ul hypervisorului. Agentul se ocup\u0103 de gestionarea snapshot-urilor \u0219i clonelor HyperFlex.<\/p>\n

      \u00cen hypervisor, resursele de disc sunt montate ca share-uri NFS sau SMB (\u00een func\u021bie de tipul hypervisorului, ghici\u021bi care este care). Sub capot\u0103, aceasta este un sistem de fi\u0219iere distribuit care permite ad\u0103ugarea de func\u021bionalit\u0103\u021bi pentru sisteme de stocare complete: rezervarea fin\u0103 a volumelor, comprimare \u0219i deduplicare, snapshot-uri prin tehnologia Redirect-on-Write, replicare sincron\u0103\/asincron\u0103.<\/p>\n

      Ma\u0219ina virtual\u0103 de serviciu ofer\u0103 acces la interfa\u021ba WEB de gestionare a subsistemului HyperFlex. Exist\u0103 integrare cu vCenter, iar cea mai mare parte a sarcinilor de zi cu zi pot fi realizate din acesta, dar datastor-urile, de exemplu, sunt mai u\u0219or de gestionat dintr-o interfa\u021b\u0103 web separat\u0103, dac\u0103 a\u021bi trecut deja la interfa\u021ba rapid\u0103 HTML5, sau pute\u021bi folosi clientul Flash complet integrat. \u00cen interfa\u021ba web de serviciu pute\u021bi verifica performan\u021ba \u0219i starea detaliat\u0103 a sistemului.<\/p>\n

      \"Admin
      \n
      \nExist\u0103 \u0219i un alt tip de noduri \u00een cluster \u2014 noduri de calcul. Acestea pot fi servere rack sau blade f\u0103r\u0103 discuri \u00eencorporate. Pe aceste servere pot fi rulate ma\u0219ini virtuale ale c\u0103ror date sunt stocate pe serverele cu discuri. Din punct de vedere al accesului la date, nu exist\u0103 nicio diferen\u021b\u0103 \u00eentre tipurile de noduri, deoarece arhitectura presupune abstractizarea de la loca\u021bia fizic\u0103 a datelor. Raportul maxim \u00eentre nodurile de calcul \u0219i nodurile de stocare este 2:1.<\/p>\n

      Utilizarea nodurilor de calcul cre\u0219te flexibilitatea la scalarea resurselor cluster-ului: nu trebuie neap\u0103rat s\u0103 achizi\u021bion\u0103m noduri cu discuri dac\u0103 avem nevoie doar de CPU\/RAM. \u00cen plus, putem ad\u0103uga un chassis blade \u0219i ob\u021bine economii la amplasarea serverelor \u00een rack.<\/p>\n

      Ca rezultat, avem o platform\u0103 hiperconvergent\u0103 cu urm\u0103toarele caracteristici:<\/p>\n