{"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\/sq\/blog\/administrirovanie\/admin-bez-ruk-giperkonvergentsiya","title":{"rendered":"Admin pa duar = hiper-konvergjenc\u00eb?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Admin
\n\"Admin
\n
\nKy \u00ebsht\u00eb nj\u00eb mit, mjaft i p\u00ebrhapur n\u00eb fush\u00ebn e harduerit t\u00eb serverit. N\u00eb praktik\u00eb, megjithat\u00eb, zgjidhjet hiperkonvergjente (kur gjith\u00e7ka \u00ebsht\u00eb n\u00eb nj\u00eb) jan\u00eb t\u00eb nevojshme p\u00ebr shum\u00eb arsye. Historikisht, arkitekturat e para u zhvilluan nga Amazon dhe Google p\u00ebr sh\u00ebrbimet e tyre. At\u00ebher\u00eb, ideja ishte t\u00eb krijohej nj\u00eb ferm\u00eb llogarit\u00ebse nga nyje t\u00eb ngjashme, t\u00eb \u00e7do nj\u00ebra prej t\u00eb cilave kishte hard disk\u00ebt e saj. T\u00eb gjitha k\u00ebto bashkoheshin me nj\u00eb softuer sistemor (hipervizor) dhe ndaheshin m\u00eb tej n\u00eb makina virtuale. Q\u00ebllimi kryesor \u2014 minimumi i p\u00ebrpjekjeve p\u00ebr mir\u00ebmbajtjen e nj\u00eb nyje dhe minimumi i problemeve gjat\u00eb shkall\u00ebzimit: thjesht blen\u00eb nj\u00eb mij\u00eb ose dy t\u00eb tjera t\u00eb tilla dhe i lidhnin ngjitur. N\u00eb praktik\u00eb, kjo \u00ebsht\u00eb nj\u00ebndjike, dhe m\u00eb shpesh flitet p\u00ebr nj\u00eb num\u00ebr m\u00eb t\u00eb vog\u00ebl nyjesh dhe nj\u00eb arkitektur\u00eb pak m\u00eb ndryshe. <\/p>\n

Por p\u00ebrfitimi mbetet i nj\u00ebjt\u00eb \u2014 thjesht\u00ebsia e jasht\u00ebzakonshme e shkall\u00ebzimit dhe menaxhimit. Mang\u00ebsia \u2014 detyra t\u00eb ndryshme konsumojn\u00eb burime n\u00eb m\u00ebnyr\u00eb t\u00eb ndryshme, dhe ndonj\u00ebher\u00eb disa disqe lokale do t\u00eb jen\u00eb t\u00eb shumt\u00eb, nd\u00ebrsa n\u00eb vende t\u00eb tjera do t\u00eb ket\u00eb pak RAM dhe k\u00ebshtu me radh\u00eb, pra, n\u00eb var\u00ebsi t\u00eb llojit t\u00eb detyrave, do t\u00eb ket\u00eb r\u00ebnie t\u00eb shfryt\u00ebzimit t\u00eb burimeve. <\/p>\n

K\u00ebshtu doli q\u00eb po paguanit 10-15% m\u00eb shum\u00eb p\u00ebr leht\u00ebsin\u00eb e konfigurimit. Ky \u00ebsht\u00eb edhe miti nga titulli. Kemi k\u00ebrkuar p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb se ku do t\u00eb aplikohej shk\u00eblqyesh\u00ebm teknologjia dhe e gjet\u00ebm. Problemi \u00ebsht\u00eb se Cisco nuk kishte sistemet e tij t\u00eb ruajtjes, por ata donin t\u00eb ishin t\u00eb pranish\u00ebm n\u00eb t\u00ebr\u00eb tregun e server\u00ebve. Prandaj krijuan Cisco Hyperflex \u2014 nj\u00eb zgjidhje me depozita lokale n\u00eb nyje. <\/p>\n

Dhe nga kjo papritur doli nj\u00eb zgjidhje shum\u00eb e mir\u00eb p\u00ebr qendrat e t\u00eb dh\u00ebnave rezerv\u00eb (Disaster Recovery). Pse dhe si \u2014 tani do t'ju tregoj. Dhe do t\u00eb tregoj testet e klasterit. <\/a><\/noindex><\/p>\n

Ku \u00ebsht\u00eb e nevojshme<\/h3>\n

\nHiperkonvergenca \u00ebsht\u00eb: <\/p>\n

    \n
  1. Transferimi i disqeve n\u00eb nyjet kompjuterike.<\/li>\n
  2. Integrimi i plot\u00eb i sistemit t\u00eb ruajtjes s\u00eb t\u00eb dh\u00ebnave me sistemin e virtualizimit.<\/li>\n
  3. Transferimi\/integrimi me sistemin rrjetor.<\/li>\n<\/ol>\n

    \nKjo lidhje lejon realizimin e shum\u00eb funksioneve t\u00eb sistemit t\u00eb ruajtjes n\u00eb nivelin e virtualizimit dhe gjith\u00e7ka nga nj\u00eb dritare menaxhimi.<\/p>\n

    N\u00eb kompanin\u00eb ton\u00eb, projektet p\u00ebr projektimin e qendrave t\u00eb t\u00eb dh\u00ebnave rezerv\u00eb jan\u00eb shum\u00eb t\u00eb k\u00ebrkuara, dhe shpesh zgjidhet pik\u00ebrisht zgjidhja hiperkonvergente p\u00ebr shkak t\u00eb shum\u00eb mund\u00ebsive p\u00ebr replikim (deri n\u00eb metroklauster) nga kutia. <\/p>\n

    N\u00eb rastin e qendrave t\u00eb t\u00eb dh\u00ebnave rezerv\u00eb, zakonisht flitet p\u00ebr nj\u00eb objekt t\u00eb larg\u00ebt n\u00eb nj\u00eb vend tjet\u00ebr n\u00eb qytet ose madje n\u00eb nj\u00eb qytet tjet\u00ebr. Ai lejon rikthimin e sistemeve kritike n\u00eb rast t\u00eb d\u00ebshtimit t\u00eb pjessh\u00ebm ose t\u00eb plot\u00eb t\u00eb qendr\u00ebs kryesore t\u00eb t\u00eb dh\u00ebnave. T\u00eb dh\u00ebnat nga prodhimi replikohen vazhdimisht aty, dhe kjo replikim mund t\u00eb jet\u00eb n\u00eb nivelin e aplikacionit ose n\u00eb nivelin e nj\u00eb pajisjeje bllokuese (SHTD).<\/p>\n

    Prandaj, tani do t\u00eb flas p\u00ebr struktur\u00ebn e sistemit dhe testet, dhe pastaj p\u00ebr disa skenar\u00eb t\u00eb aplikimit t\u00eb v\u00ebrtet\u00eb me t\u00eb dh\u00ebna mbi kursimet. <\/p>\n

    Testet<\/h3>\n

    \nEksemplari yn\u00eb p\u00ebrb\u00ebhet nga kat\u00ebr server\u00eb, t\u00eb cil\u00ebt kan\u00eb nga 10 disqe SSD me kapacitet 960 GB secili. Ka nj\u00eb disk t\u00eb dedikuar p\u00ebr keshimin e operacioneve t\u00eb shkruara dhe ruajtjen e makin\u00ebs virtuale sh\u00ebrbyese. Zgjidhja \u00ebsht\u00eb versioni i kat\u00ebrt. Versioni i par\u00eb ishte hapur (sipas komenteve), i dyti ishte i papjekur, i treti ishte mjaft stabil, dhe k\u00ebt\u00eb mund ta quajm\u00eb l\u00ebshim pas p\u00ebrfundimit t\u00eb testit beta me nj\u00eb audienc\u00eb t\u00eb gjer\u00eb. Gjat\u00eb testimit nuk kam par\u00eb probleme, gjith\u00e7ka funksionon si\u00e7 duhet.<\/p>\n

    Ndryshimet n\u00eb v4<\/b>P\u00ebrmir\u00ebsuar nj\u00eb grumbull gabimesh. <\/p>\n

    N\u00eb fillim, plataforma mund t\u00eb funksiononte vet\u00ebm me hipervizorin VMware ESXi dhe mb\u00ebshteste nj\u00eb num\u00ebr t\u00eb vog\u00ebl nodash. Gjithashtu, procesi i vendosjes nuk p\u00ebrfundonte gjithmon\u00eb me sukses, duke detyruar ri-fillimin e disa hapave, kishim probleme me azhurnimet nga versionet e vjetra, dhe t\u00eb dh\u00ebnat n\u00eb GUI shpesh nuk shfaqeshin sakt\u00eb (ndon\u00ebse edhe tani nuk jam i k\u00ebnaqur me vizatimet e performanc\u00ebs), ndonj\u00ebher\u00eb ishin probleme n\u00eb prehjen me virtualizimin.<\/p>\n

    Tani t\u00eb gjitha dob\u00ebsit\u00eb e f\u00ebmij\u00ebris\u00eb jan\u00eb korrigjuar, HyperFlex mb\u00ebshtet dhe ESXi, dhe Hyper-V, plus \u00ebsht\u00eb e mundur:<\/p>\n

      \n
    1. Krijimi i nj\u00eb klasteri t\u00eb shtrir\u00eb. <\/li>\n
    2. Krijimi i nj\u00eb klasteri p\u00ebr zyra pa p\u00ebrdorur Fabric Interconnect, nga dy n\u00eb kat\u00ebr nod\u00eb (blejm\u00eb vet\u00ebm server\u00eb).<\/li>\n
    3. Mund\u00ebsia p\u00ebr t\u00eb punuar me ruajt\u00ebse t\u00eb jashtme t\u00eb t\u00eb dh\u00ebnave.<\/li>\n
    4. Mb\u00ebshtetje p\u00ebr kontejner\u00ebt dhe Kubernetes.<\/li>\n
    5. Krijimi i zonave t\u00eb aksesit.<\/li>\n
    6. Integrimi me VMware SRM, n\u00ebse funksionaliteti i integruar nuk \u00ebsht\u00eb i mjaftuesh\u00ebm.<\/li>\n<\/ol>\n

      Arkitektura nuk ndryshon ndjesh\u00ebm nga zgjidhjet e konkurrent\u00ebve kryesor\u00eb; nuk kemi rikrijuar rulet\u00ebn. T\u00eb gjitha funksionon n\u00eb platform\u00ebn e virtualizimit VMware ose Hyper-V. Hardware vendoset n\u00eb server\u00ebt e zhvilluar vet\u00eb nga Cisco UCS. Ka ata q\u00eb e urrejn\u00eb k\u00ebt\u00eb platform\u00eb p\u00ebr kompleksitetin e saj fillestar, numrin e madh t\u00eb butonave, sistemin e nd\u00ebrlikuar t\u00eb shablloneve dhe var\u00ebsive, por ka edhe ata q\u00eb kan\u00eb arritur zenin, jan\u00eb p\u00ebrthithur nga ideja dhe nuk duan t\u00eb punojn\u00eb m\u00eb me servera t\u00eb tjer\u00eb. <\/p>\n

      Ne do t\u00eb shqyrtojm\u00eb zgjidhjen p\u00ebr VMware, sepse zgjidhja \u00ebsht\u00eb krijuar fillimisht p\u00ebr t\u00eb dhe ka funksionalitet m\u00eb t\u00eb madh; Hyper-V \u00ebsht\u00eb p\u00ebrmir\u00ebsuar gjat\u00eb rrug\u00ebs n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb mos mbetet pas konkurrent\u00ebve dhe p\u00ebr t'u p\u00ebrputhur me pritjet e tregut.<\/p>\n

      Ka nj\u00eb klaster serverash t\u00eb mbushura me disqe. Ka disqe p\u00ebr ruajtjen e t\u00eb dh\u00ebnave (SSD ose HDD - sipas d\u00ebshir\u00ebs dhe nevojave tuaja), dhe ka nj\u00eb disq t\u00eb vet\u00ebm SSD p\u00ebr keqstrimin. Kur shkruhen t\u00eb dh\u00ebnat n\u00eb datastore, ndodh ruajtja e t\u00eb dh\u00ebnave n\u00eb slojin e keqstrimit (disku SSD i dedikuar dhe RAM e VM-s\u00eb sh\u00ebrbimit). Paralelisht, blloku i t\u00eb dh\u00ebnave d\u00ebrgohet n\u00eb node-t n\u00eb klaster (numri i node-ve varet nga faktor\u00ebt e replikimit t\u00eb klasterit). Pasi t\u00eb konfirmohet nga t\u00eb gjitha node-t p\u00ebr shkruan e suksesshme, konfirmimi i shkruan d\u00ebrgohet n\u00eb hipervizor dhe m\u00eb pas - n\u00eb VM. T\u00eb dh\u00ebnat e shkruara n\u00eb sfond dedupplikohen, kompresohen dhe shkruhen n\u00eb disqet e ruajtjes. N\u00eb k\u00ebt\u00eb proces, gjithmon\u00eb shkruhet nj\u00eb bllok i madh n\u00eb m\u00ebnyr\u00eb sekondare, duke reduktuar ngarkes\u00ebn mbi disqet e ruajtjes.<\/p>\n

      Deduplication dhe kompresimi jan\u00eb gjithmon\u00eb aktiv, dhe nuk mund t\u00eb \u00e7aktivizohen. Leximi i t\u00eb dh\u00ebnave b\u00ebhet drejtp\u00ebrdrejt nga disqet e ruajtjes ose nga cache RAM. N\u00ebse p\u00ebrdoret nj\u00eb konfigurim hibrid, leximi gjithashtu ruhet n\u00eb diskun SSD.<\/p>\n

      T\u00eb dh\u00ebnat nuk jan\u00eb t\u00eb lidhura me lokacionin aktual t\u00eb makin\u00ebs virtuelle dhe shp\u00ebrndahen nj\u00eblloj midis nodave. Ky qasje lejon ngarkimin e nj\u00ebjt\u00eb t\u00eb t\u00eb gjitha disqeve dhe nd\u00ebrfaqeve rrjet. Nj\u00eb disavantazh i duksh\u00ebm \u00ebsht\u00eb se nuk mund t\u00eb minimizojm\u00eb vonesat n\u00eb lexim, p\u00ebr shkak se nuk ka garanci p\u00ebr pranin\u00eb e t\u00eb dh\u00ebnave lokal. Megjithat\u00eb, un\u00eb mendoj se kjo \u00ebsht\u00eb nj\u00eb sakrifice e vog\u00ebl krahasuar me avantazhet q\u00eb marrim. M\u00eb shum\u00eb, vonesat n\u00eb rrjet kan\u00eb arritur nivele t\u00eb tilla sa q\u00eb praktikisht nuk ndikojn\u00eb n\u00eb rezultatet e p\u00ebrgjithshme.<\/p>\n

      E gjith\u00eb logjika e funksionimit t\u00eb n\u00ebnstruktur\u00ebs s\u00eb disk\u00ebve \u00ebsht\u00eb menaxhuar nga nj\u00eb VM sh\u00ebrbimi speciale Cisco HyperFlex Data Platform controller, e cila krijohet n\u00eb \u00e7do nod t\u00eb ruajtjes. N\u00eb konfigurimin ton\u00eb, VM sh\u00ebrbimi mori tet\u00eb vCPU dhe 72 GB RAM, q\u00eb s\u2019\u00ebsht\u00eb aspak pak. T\u00eb rikujtoj se vet\u00eb host-i ka 28 b\u00ebrthama fizike dhe 512 GB RAM.<\/p>\n

      Makin\u00eb Virtuale Sh\u00ebrbimi ka qasje n\u00eb disqet fizike direkt p\u00ebrmes kalimit t\u00eb kontroluesit SAS n\u00eb VM. Komunikimi me hipervizorin ndodh p\u00ebrmes nj\u00eb moduli t\u00eb ve\u00e7ant\u00eb IOVisor, i cili kap operacionet e hyrjes dhe daljes, si dhe p\u00ebrmes nj\u00eb agjenti q\u00eb lejon d\u00ebrgimin e komandave n\u00eb API-n\u00eb e hipervizorit. Agjenti \u00ebsht\u00eb p\u00ebrgjegj\u00ebs p\u00ebr pun\u00ebn me snapshotet dhe klon\u00ebt HyperFlex.<\/p>\n

      N\u00eb hipervizor, burimet diskore montohen si ndar\u00ebse NFS ose SMB (varet nga tipi i hipervizorit, tregoni se cila \u00ebsht\u00eb cila). Por n\u00ebn kapak \u00ebsht\u00eb nj\u00eb sistem i shp\u00ebrndar\u00eb skedar\u00ebsh, i cili lejon shtimin e karakteristikave t\u00eb plota t\u00eb depove t\u00eb dh\u00ebnash: alokim t\u00eb holl\u00eb t\u00eb volumeve, kompresim dhe deduplikim, snapshotet me teknologjin\u00eb Redirect-on-Write, replikim sinkron\/asinchron.<\/p>\n

      Makin\u00eb Virtuale Sh\u00ebrbimi ofron qasje n\u00eb nd\u00ebrfaqen WEB p\u00ebr menaxhimin e sistemit HyperFlex. Ka integrim me vCenter, dhe shumica e detyrave t\u00eb p\u00ebrditshme mund t\u00eb kryhen prej tij, por datastoret, p\u00ebr shembull, \u00ebsht\u00eb m\u00eb e leht\u00eb t\u2019i ndajm\u00eb nga nj\u00eb nd\u00ebrfaqe e ve\u00e7ant\u00eb web n\u00ebse keni kaluar n\u00eb nd\u00ebrfaqen e shpejt\u00eb HTML5, ose t\u00eb p\u00ebrdorni nj\u00eb klient t\u00eb plot\u00eb Flash me integrim t\u00eb plot\u00eb. N\u00eb nd\u00ebrfaqen e sh\u00ebrbimit mund t\u00eb shihni performanc\u00ebn dhe statusin e detajuar t\u00eb sistemit.<\/p>\n

      \"Admin
      \n
      \nEkziston edhe nj\u00eb lloj tjet\u00ebr nod n\u00eb klaster \u2014 nodet p\u00ebrpunuese. K\u00ebto mund t\u00eb jen\u00eb server\u00eb regjistrues ose server\u00eb blade pa disqe t\u00eb integruar. N\u00eb k\u00ebto server\u00eb mund t\u00eb startojm\u00eb VM, t\u00eb dh\u00ebnat e t\u00eb cilave ruhen n\u00eb server\u00ebt me disqe. Nga pik\u00ebpamja e aksesit n\u00eb t\u00eb dh\u00ebna, nuk ka asnj\u00eb ndryshim nd\u00ebrmjet llojeve t\u00eb nodit, pasi arkitektura parashikon abstragimin nga vendndodhja fizike e t\u00eb dh\u00ebnave. Raporti maksimal midis nodit p\u00ebrpunues dhe nodit t\u00eb ruajtjes \u00ebsht\u00eb 2:1.<\/p>\n

      P\u00ebrdorimi i nod\u00ebve p\u00ebrpunuese rrit fleksibilitetin gjat\u00eb zgjerimit t\u00eb burimeve t\u00eb klasterit: nuk \u00ebsht\u00eb e nevojshme t\u00eb blejm\u00eb nod\u00eb me disqe n\u00ebse kemi nevoj\u00eb vet\u00ebm p\u00ebr CPU\/RAM. Madje, ne mund t\u00eb shtojm\u00eb nj\u00eb sistem rack dhe t\u00eb fitojm\u00eb kursim n\u00eb vendosjen e server\u00ebve n\u00eb raft.<\/p>\n

      Si rezultati, kemi nj\u00eb platform\u00eb hiper-konvergjente me funksionalitetet e m\u00ebposhtme:<\/p>\n