{"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\/sl\/blog\/administrirovanie\/admin-bez-ruk-giperkonvergentsiya","title":{"rendered":"Admin brez rok = hiper-konvergenca?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Admin
\n\"Admin
\n
\nTo je mit, precej raz\u0161irjen na podro\u010dju stre\u017eni\u0161kega strojne opreme. V praksi pa so hiper-konvergentne re\u0161itve (ko je vse v enem) potrebne za mnoge namene. Zgodovinsko gledano, prve arhitekture so razvile podjetja Amazon in Google za svoje storitve. Takrat je bila ideja ustvariti ra\u010dunalni\u0161ko farmo iz enakih enot, pri \u010demer ima vsaka svoje diske. Vse to je zdru\u017eil nek software (hipervizor) in razdelil na virtualne stroje. Glavna naloga je minimalna potrebna skrb za eno enoto in minimalni problemi pri \u0161iritvi: preprosto kupite \u0161e tiso\u010d ali dva enakih stre\u017enikov in jih priklju\u010dite ob strani. V praksi so to enkratni primeri, pogosteje pa gre za manj\u0161o \u0161tevilo enot in nekoliko druga\u010dno arhitekturo. <\/p>\n

A prednost ostaja enaka \u2013 neverjetna enostavnost pri \u0161irjenju in upravljanju. Slabost pa je, da razli\u010dne naloge porabijo vire razli\u010dno, in kje bo lokalnih diskov preve\u010d, bo drugje premalo RAM-a in tako naprej; torej, pri razli\u010dnih vrstah nalog bo izkori\u0161\u010denost virov padla. <\/p>\n

Izkazalo se je, da pla\u010dujete 10\u201315% ve\u010d za udobje nastavitve. To je pravzaprav povzro\u010dilo mit iz naslova. Dolgo smo iskali, kje bi bila tehnologija optimalna, in jo na\u0161li. Gre za to, da Cisco ni imel svojih podatkovnih shrambe, a so \u017eeleli popoln stre\u017eni\u0161ki trg. In so naredili Cisco Hyperflex \u2013 re\u0161itev z lokalnimi skladi\u0161\u010di na enotah. <\/p>\n

In iz tega je nenadoma nastala zelo dobra re\u0161itev za rezervne podatkovne centre (Disaster Recovery). Zakaj in kako \u2013 to vam bom zdaj povedal. In pokazal bom testiranje klasterja. <\/a><\/noindex><\/p>\n

Kjer je potrebno<\/h3>\n

\nHiper-konvergenca je: <\/p>\n

    \n
  1. Prenos diskov v ra\u010dunalni\u0161ke enote.<\/li>\n
  2. Popolna integracija pod-sistema shranjevanja podatkov s pod-sistemom virtualizacije.<\/li>\n
  3. Prenos\/integracija s mre\u017enim pod-sistemom.<\/li>\n<\/ol>\n

    \nTak\u0161na povezava omogo\u010da uresni\u010devanje mnogih funkcij shranjevanja podatkov na ravni virtualizacije in vse iz enega okna za upravljanje.<\/p>\n

    V na\u0161em podjetju so projekti za na\u010drtovanje rezervnih podatkovnih centrov zelo iskani, in pogosto se izbere prav hiper-konvergentna re\u0161itev zaradi \u0161tevilnih mo\u017enosti replikacije (do metroklastrov) \u017ee iz \u0161katle. <\/p>\n

    V primeru rezervnih podatkovnih centrov obi\u010dajno govorimo o oddaljenem objektu na lokaciji na drugem koncu mesta ali celo v drugem mestu. To omogo\u010da obnovitev kriti\u010dnih sistemov v primeru delne ali popolne okvare glavnega podatkovnega centra. Podatki se nenehno replicirajo s prodajnega mesta, ta replikacija pa je lahko na ravni aplikacije ali na ravni blokovnega naprave (SAN).<\/p>\n

    Zato zdaj bom predstavil zasnovo sistema in teste, nato pa \u0161e nekaj scenarijev dejanske uporabe z podatki o prihrankih. <\/p>\n

    Testovi<\/h3>\n

    \nNa\u0161 primer se sestoji iz \u0161tirih stre\u017enikov, pri \u010demer ima vsak po 10 SSD-diskov s kapaciteto 960 GB. Obstaja lo\u010den disk za shranjevanje pisanja in ohranjanje servisne virtualne naprave. Samo re\u0161itev predstavlja \u010detrto razli\u010dico. Prva je bila o\u010ditno nedodelana (sodnik po mnenjih), druga je bila \u0161e vedno nedodelana, tretja pa je \u017ee dokaj stabilna, to pa lahko imenujemo izid po koncu beta-testiranja za \u0161ir\u0161o javnost. Med testiranjem nisem naletel na te\u017eave, vse deluje kot ura.<\/p>\n

    Spremembe v v4<\/b>Odpravljeno je bilo veliko napak. <\/p>\n

    Sprva je platforma lahko delovala le s hipervizorjem VMware ESXi in je podpirala majhno \u0161tevilo vozli\u0161\u010d. Postopek uvajanja tudi ni vedno uspe\u0161no zaklju\u010dil, v\u010dasih je bilo potrebno znova zagnati dolo\u010dene korake, nastajale so te\u017eave pri posodabljanju iz starih razli\u010dic, podatki v GUI-ju se niso vedno pravilno prikazovali (\u010deprav trenutno \u0161e vedno nisem navdu\u0161en nad prikazovanjem grafikonov zmogljivosti), ob\u010dasno so se pojavile te\u017eave pri virtualizaciji.<\/p>\n

    Zdaj so vse otro\u0161ke bolezni odpravljene, HyperFlex podpira tako ESXi kot Hyper-V, poleg tega je mo\u017eno:<\/p>\n

      \n
    1. Ustvarjanje raztegnjenega klasterja. <\/li>\n
    2. Ustvarjanje klasterja za pisarne brez uporabe Fabric Interconnect, od dveh do \u0161tirih vozli\u0161\u010d (kupimo le stre\u017enike).<\/li>\n
    3. Mo\u017enost delovanja z zunanjimi SAN-ji.<\/li>\n
    4. Podpora za kontejnerje in Kubernetes.<\/li>\n
    5. Ustvarjanje obmo\u010dij dosega.<\/li>\n
    6. Integracija z VMware SRM, \u010de vgrajena funkcionalnost ni zadostna.<\/li>\n<\/ol>\n

      Arhitektura se ne razlikuje zna\u010dajno od re\u0161enja glavnih konkurenata, nisu se trudili da izume bicikl. Sve to funkcioni\u0161e na platformi virtualizacije VMware ili Hyper-V. Hardverski se sme\u0161ta na serverima vlastitog dizajna Cisco UCS. Ima onih koji mrze platformu zbog relativne slo\u017eenosti po\u010detnog pode\u0161avanja, mno\u0161tva dugmi\u0107a, nesvakida\u0161njeg sistema \u0161ablona i zavisnosti, ali ima i onih koji su otkrili zen, u\u0161li u ideju i vi\u0161e ne \u017eele da rade sa drugim serverima. <\/p>\n

      Razmotri\u0107emo re\u0161enje za VMware, jer je re\u0161enje prvobitno razvijeno za njega i ima ve\u0107u funkcionalnost, dok je Hyper-V dora\u0111ivan usput da ne zaostaje za konkurencijom i odgovara tr\u017ei\u0161nim o\u010dekivanjima.<\/p>\n

      Postoji klaster servera opremljenih diskovima. Ima diskove za skladi\u0161tenje podataka (SSD ili HDD \u2014 po va\u0161em izboru i potrebama), kao i jedan SSD disk za ke\u0161iranje. Kada se podaci zapisuju na datastor, oni se \u010duvaju na ke\u0161iranoj sloju (posve\u0107eni SSD disk i RAM servisne VM). Paralelno, blok podataka se \u0161alje \u010dvorovima unutar klastera (broj \u010dvorova zavisi od faktora replikacije klastera). Nakon potvrde od svih \u010dvorova o uspe\u0161nom zapisu, potvrda se \u0161alje hipervizoru, a zatim \u2014 VM. Zapisani podaci se u pozadini deduplikuju, kompresuju i zapisuju na skladi\u0161ne diskove. Pri tome se na skladi\u0161ne diskove uvek zapisuje veliki blok i sekvencijalno, \u0161to smanjuje optere\u0107enje na skladi\u0161nim diskovima.<\/p>\n

      Deduplikaacija i kompresija su trajno uklju\u010dene i ne mogu se isklju\u010diti. \u010citanje podataka se vr\u0161i direktno sa skladi\u0161nih diskova ili iz RAM ke\u0161a. Ako se koristi hibridna konfiguracija, \u010ditanje se tako\u0111e ke\u0161ira na SSD disku.<\/p>\n

      Podaci nisu vezani za trenutno mesto fizi\u010dke ma\u0161ine i ravnomerno se raspore\u0111uju izme\u0111u \u010dvorova. Ovaj pristup omogu\u0107ava ravnomerno optere\u0107enje svih diskova i mre\u017enih interfejsa. Logi\u010dan nedostatak se name\u0107e: ne mo\u017eemo maksimalno smanjiti latenciju \u010ditanja, jer nema garancije da su podaci lokalno dostupni. Ali smatram da je to bezna\u010dajna \u017ertva u pore\u0111enju sa dobijenim prednostima. Tim vi\u0161e \u0161to su latencije u mre\u017ei dostigle takve vrednosti da prakti\u010dno ne uti\u010du na ukupni rezultat.<\/p>\n

      Za celotno logiko delovanja diskovnega podsistema je odgovorna posebna storitvena VM Cisco HyperFlex Data Platform controller, ki se ustvari na vsakem vozli\u0161\u010du shranjevanja. V na\u0161i konfiguraciji je storitveni VM imel dodeljenih osem vCPU in 72 GB RAM, kar ni zanemarljivo. Spomnim, da ima sam gostitelj na voljo 28 fizi\u010dnih jeder in 512 GB RAM.<\/p>\n

      Storitev VM ima dostop do fizi\u010dnih diskov neposredno s pomo\u010djo pretvornika SAS, ki je usmerjen v VM. Komunikacija z hiperizvozniki poteka skozi poseben modul IOVisor, ki zajame operacije vnosa in izhoda, ter s pomo\u010djo agenta, ki omogo\u010da po\u0161iljanje ukazov v API hiperizvoznika. Agent je odgovoren za delo s HyperFlex posnetki in kloni.<\/p>\n

      V hiperizvoznika so diskovni viri montirani kot NFS ali SMB deljenje (odvisno od vrste hiperizvoznika, ugibajte, kateri je kateri). Pod pokrovom pa je to razdeljen datote\u010dni sistem, ki omogo\u010da dodajanje funkcij odraslih celovitih SKD: tanke dodelitve volumov, stiskanje in deduplikacijo, posnetke s tehnologijo Redirect-on-Write, sinhrono\/asinhrono replikacijo.<\/p>\n

      Storitev VM zagotavlja dostop do spletnega vmesnika za upravljanje podsistema HyperFlex. Obstaja integracija z vCenter, in ve\u010dina vsakodnevnih nalog se lahko izvede iz njega, vendar je za datastore, na primer, la\u017eje razdeliti skozi lo\u010deno spletno stran, \u010de ste \u017ee pre\u0161li na hiter HTML5 vmesnik, ali uporabiti poln Flash odjemalec z polno integracijo. V storitveni spletni aplikaciji lahko pregledate zmogljivost in podroben status sistema.<\/p>\n

      \"Admin
      \n
      \nObstaja tudi drugi tip vozli\u0161\u010d v klastru - ra\u010dunska vozli\u0161\u010da. To so lahko rack-mount ali blade stre\u017eniki brez vgrajenih diskov. Na teh stre\u017enikih lahko za\u017eenete VM, katerih podatki se shranjujejo na stre\u017enikih z diski. Z vidika dostopa do podatkov ni razlike med tipi vozli\u0161\u010d, saj arhitektura predvideva abstrakcijo fizi\u010dne lokacije podatkov. Najve\u010dje razmerje med ra\u010dunalni\u0161kimi vozli\u0161\u010di in vozli\u0161\u010di shranjevanja je 2:1.<\/p>\n

      Uporaba ra\u010dunalni\u0161kih vozli\u0161\u010d pove\u010duje prilagodljivost pri raz\u0161irjanju virov klastrske: ni nam treba kupiti vozli\u0161\u010d z diski, \u010de potrebujemo samo CPU\/RAM. Poleg tega lahko dodamo blade ko\u0161aro in dose\u017eemo prihranke pri namestitvi stre\u017enikov v omarici.<\/p>\n

      Kot rezultat imamo hiper-konvergentno platformo z naslednjimi funkcijami:<\/p>\n