{"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 pajisjeve serverike. N\u00eb praktik\u00eb, megjithat\u00eb, zgjidhjet hiper-konverguese (kur gjith\u00e7ka \u00ebsht\u00eb n\u00eb nj\u00eb) jan\u00eb t\u00eb nevojshme p\u00ebr shum\u00eb arsye. Historikisht, arkitektur\u00ebn e par\u00eb e zhvilluan Amazon dhe Google p\u00ebr sh\u00ebrbimet e tyre. N\u00eb at\u00eb koh\u00eb, ideja ishte t\u00eb krijohej nj\u00eb ferm\u00eb kompjuterike nga nyje t\u00eb nj\u00ebjta, ku secila kishte disqe t\u00eb saj. T\u00eb gjitha k\u00ebto u bashkuan me ndihm\u00ebn e nj\u00eb programi sistemor (hipervizori) dhe u ndan\u00eb n\u00eb makina virtuale. Detyra kryesore \u2014 minimumi i p\u00ebrpjekjeve p\u00ebr mir\u00ebmbajtjen e nj\u00eb nyje dhe minimumi i problemeve gjat\u00eb shkall\u00ebzimit: thjesht blen\u00eb edhe nj\u00eb mij\u00eb ose dy t\u00eb tilla servera dhe i lidh\u00ebn p\u00ebrkrah. N\u00eb praktik\u00eb, kjo ndodh rrall\u00eb, dhe m\u00eb shpesh flitet p\u00ebr numra m\u00eb t\u00eb vogla nyjesh dhe nj\u00eb arkitektur\u00eb pak 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 detyrat e ndryshme konsumojn\u00eb burime n\u00eb m\u00ebnyr\u00eb t\u00eb ndryshme, dhe diku do t\u00eb ket\u00eb shum\u00eb disqe lokale, diku pak RAM dhe k\u00ebshtu me radh\u00eb, q\u00eb do t\u00eb thot\u00eb se me tipe t\u00eb ndryshme detyrash do t\u00eb bie p\u00ebrdorimi i burimeve. <\/p>\n

Doli q\u00eb paguani 10-15% m\u00eb shum\u00eb p\u00ebr komoditetin e konfigurimit. Kjo shkaktoi mitin nga titulli. Ne k\u00ebrkuam gjat\u00eb p\u00ebr m\u00ebnyr\u00ebn se si do t\u00eb aplikohej teknologjia optimalisht, dhe e gjet\u00ebm. \u00c7\u00ebshtja \u00ebsht\u00eb se Cisco nuk kishte sistemet e saj t\u00eb ruajtjes, por ata donin t\u00eb p\u00ebrfshinin tregun e plot\u00eb t\u00eb server\u00ebve. Dhe ata krijuan Cisco Hyperflex \u2014 nj\u00eb zgjidhje me ruajtje lokale n\u00eb nyje. <\/p>\n

Dhe nga kjo papritmas doli nj\u00eb zgjidhje shum\u00eb e mir\u00eb p\u00ebr qendrat e 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

Aty ku nevojitet<\/h3>\n

\nHiper-konvergjenca p\u00ebrfshin: <\/p>\n

    \n
  1. Kalon disqet n\u00eb nyje kompjuterike.<\/li>\n
  2. Integrim i plot\u00eb i sistemit t\u00eb ruajtjes s\u00eb t\u00eb dh\u00ebnave me sistemin e virtualizimit.<\/li>\n
  3. Kalon\/integrimi me sistemin rrjet\u00eb.<\/li>\n<\/ol>\n

    \nKy lidhje mund\u00ebson realizimin e shum\u00eb ve\u00e7orive 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 hiper-konverge p\u00ebr shkak t\u00eb numrit t\u00eb madh t\u00eb opsioneve p\u00ebr replikim (deri n\u00eb metrokast) nga kutia. <\/p>\n

    N\u00eb rastin e Qendrave t\u00eb t\u00eb Dh\u00ebnave rezerv\u00eb, zakonisht b\u00ebhet fjal\u00eb p\u00ebr nj\u00eb objekt t\u00eb larg\u00ebt n\u00eb nj\u00eb lokacion t\u00eb ndrysh\u00ebm n\u00eb qytet apo mbase edhe n\u00eb nj\u00eb qytet krejt\u00ebsisht tjet\u00ebr. Ai lejon rikthimin e sistemeve kritike n\u00eb rast d\u00ebshtimi 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 prodhuesi repikohen vazhdimisht aty, dhe kjo replikim mund t\u00eb ndodhi n\u00eb nivel aplikacioni ose n\u00eb nivel t\u00eb pajisjes bllokuese (SHTD).<\/p>\n

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

    Testet<\/h3>\n

    \nEkzemplari yn\u00eb p\u00ebrb\u00ebhet nga kat\u00ebr servera, \u00e7do nj\u00ebri prej t\u00eb cil\u00ebve ka 10 disqe SSD me kapacitet 960 GB. Ka nj\u00eb disk t\u00eb dedikuar p\u00ebr t\u00eb ndihmuar operacionet e shkruarjes dhe ruajtjen e makin\u00ebs virtuale sh\u00ebrbyese. Zgjidhja vet\u00eb \u00ebsht\u00eb versioni i kat\u00ebrt. Versioni i par\u00eb ishte qart\u00ebsisht i pap\u00ebrfunduara (sipas komenteve), versioni i dyt\u00eb gjithashtu ishte disi i pap\u00ebrfunduar, versioni i tret\u00eb tashm\u00eb \u00ebsht\u00eb mjaft i q\u00ebndruesh\u00ebm, dhe ky mund t\u00eb quhet nj\u00eb version q\u00eb ka p\u00ebrfunduar beta-testimin p\u00ebr publikun. Gjat\u00eb testimit nuk pash\u00eb probleme, gjith\u00e7ka funkcjonon si\u00e7 duhet.<\/p>\n

    Ndryshimet n\u00eb v4<\/b>Shum\u00eb bugs jan\u00eb rregulluar. <\/p>\n

    Fillimisht, platforma mund t\u00eb punoj\u00eb vet\u00ebm me hipervizorin VMware ESXi dhe mb\u00ebshteste nj\u00eb num\u00ebr t\u00eb vog\u00ebl nodesh. Po ashtu, procesi i instalimit nuk p\u00ebrfundonte gjithmon\u00eb me sukses, shpesh duhej t\u00eb rillevoj disa hapa, kishte probleme me p\u00ebrdit\u00ebsimin nga versionet e vjetra, dhe t\u00eb dh\u00ebnat n\u00eb GUI nuk shfaqeshin gjithmon\u00eb sakt\u00eb (edhe tani nuk jam i k\u00ebnaqur me shfaqjen e grafik\u00ebve t\u00eb performanc\u00ebs), ndonj\u00ebher\u00eb shfaqeshin probleme n\u00eb k\u00ebsulimin me virtualizimin.<\/p>\n

    Tani t\u00eb gjitha problemet fillestare jan\u00eb rregulluar, HyperFlex mb\u00ebshtet si ESXi ashtu edhe Hyper-V, plus k\u00ebshtu \u00ebsht\u00eb e mundur:<\/p>\n

      \n
    1. Krijimi i nj\u00eb klasteri t\u00eb shp\u00ebrndar\u00eb. <\/li>\n
    2. Krijimi i nj\u00eb klasteri p\u00ebr zyrat pa p\u00ebrdorur Fabric Interconnect, nga dy n\u00eb kat\u00ebr node (blejm\u00eb vet\u00ebm serverat).<\/li>\n
    3. Mund\u00ebsia p\u00ebr t\u00eb punuar me SHTD t\u00eb jashtme.<\/li>\n
    4. Mb\u00ebshtetja p\u00ebr kontejner\u00ebt dhe Kubernetes.<\/li>\n
    5. Krijimi i zonave t\u00eb disponueshm\u00ebris\u00eb.<\/li>\n
    6. Integrimi me VMware SRM, n\u00ebse funksionaliteti i integruar nuk \u00ebsht\u00eb i k\u00ebnaqsh\u00ebm.<\/li>\n<\/ol>\n

      Arkitektura nuk e dallon shum\u00eb nga zgjidhjet e konkurent\u00ebve kryesor\u00eb, nuk kan\u00eb krijuar nj\u00eb bi\u00e7iklet\u00eb. Kjo funksionon n\u00eb platform\u00ebn e virtualizimit VMware ose Hyper-V. Ka nj\u00eb vendosje harduerike n\u00eb server\u00ebt e zhvilluar vet\u00eb nga Cisco UCS. Ka ata q\u00eb e urrejn\u00eb platform\u00ebn p\u00ebr v\u00ebshtir\u00ebsin\u00eb e saj relativisht t\u00eb konfigurimit fillestar, shum\u00eb butona, nj\u00eb sistem t\u00eb nd\u00ebrlikuar t\u00eb shablloneve dhe var\u00ebsive, por ka edhe ata q\u00eb e kan\u00eb p\u00ebrjetuar zen-in, e kan\u00eb kuptuar iden\u00eb dhe nuk duan m\u00eb t\u00eb punojn\u00eb me servera t\u00eb tjer\u00eb. <\/p>\n

      Ne do t\u00eb shqyrtojm\u00eb zgjidhjen p\u00ebr VMware, pasi kjo zgjidhje fillimisht u krijua p\u00ebr t\u00eb dhe ka m\u00eb shum\u00eb funksionalitet, nd\u00ebrsa Hyper-V u p\u00ebrmir\u00ebsua gjat\u00eb rrug\u00ebs p\u00ebr t\u00eb mos ngecur pas konkurent\u00ebve dhe p\u00ebr t'iu p\u00ebrmbajtur pritshm\u00ebrive t\u00eb tregut.<\/p>\n

      Ekziston nj\u00eb klaster i server\u00ebve t\u00eb ngarkuar me disqe. Ka disqe p\u00ebr ruajtjen e t\u00eb dh\u00ebnave (SSD ose HDD \u2014 sipas shijes dhe nevojave tuaja), si dhe nj\u00eb SSD-disk p\u00ebr keqshfryt\u00ebzimin. Kur t\u00eb dh\u00ebnat shkruhen n\u00eb datastore, ato ruhen n\u00eb shtres\u00ebn e keqshfryt\u00ebzimit (SSD-disk i dedikuar dhe RAM e VM-s\u00eb sh\u00ebrbyese). Paralelisht, blloku i t\u00eb dh\u00ebnave d\u00ebrgohet n\u00eb nodet e klasterit (numri i nodave varet nga faktori i replikimit t\u00eb klasterit). Pas konfirmimit nga t\u00eb gjitha nodet p\u00ebr shkrimin e suksessh\u00ebm, konfirmimi i shkrimit d\u00ebrgohet n\u00eb hipervizor dhe m\u00eb pas \u2014 n\u00eb VM. T\u00eb dh\u00ebnat e shkruara deduplikohen, kompresohen dhe ruhen n\u00eb disqet e ruajtjes n\u00eb sfond. N\u00eb k\u00ebt\u00eb m\u00ebnyr\u00eb, nj\u00eb bllok i madh gjithmon\u00eb shkruhet n\u00eb disqet e ruajtjes dhe rend\u00ebsisht, \u00e7ka ul ngarkes\u00ebn n\u00eb disqet e ruajtjes.<\/p>\n

      Deduplikimi dhe kompresimi jan\u00eb aktivizuar gjithmon\u00eb, dhe nuk mund t\u00eb \u00e7aktivizohen. Leximi i t\u00eb dh\u00ebnave ndodh direkt nga disqet e ruajtjes ose nga RAM-i i keqshfryt\u00ebzimit. N\u00ebse p\u00ebrdoret nj\u00eb konfigurim hibrid, at\u00ebher\u00eb leximi gjithashtu keqshfryt\u00ebzohet n\u00eb SSD-disk.<\/p>\n

      T\u00eb dh\u00ebnat nuk lidh\u00ebn me vendndodhjen aktuale t\u00eb makin\u00ebs virtuale dhe shp\u00ebrndahen n\u00eb m\u00ebnyr\u00eb t\u00eb barabart\u00eb mes nodave. Ky qasje lejon q\u00eb t\u00eb gjitha disqet dhe interfecet rrjet\u00ebsore t\u00eb ngarkohet nj\u00ebsoj. Dalin n\u00eb pah nj\u00eb mang\u00ebsi e dukshme: nuk mund t\u00eb minimizohet maksimalisht vonesa e leximit, pasi nuk ka garanci p\u00ebr disponueshm\u00ebrin\u00eb e t\u00eb dh\u00ebnave lokal. Por un\u00eb besoj se kjo \u00ebsht\u00eb nj\u00eb sakrifice e vog\u00ebl krahasuar me p\u00ebrfitimet q\u00eb merrni. P\u00ebr m\u00eb tep\u00ebr, vonesat n\u00eb rrjet kan\u00eb arritur n\u00eb nivele t\u00eb tilla sa q\u00eb praktikisht nuk ndikojn\u00eb n\u00eb rezultatin p\u00ebrfundimtar.<\/p>\n

      T\u00eb gjitha logjika e pun\u00ebs s\u00eb sistemit t\u00eb depozitimit t\u00eb diskut \u00ebsht\u00eb p\u00ebrgjegj\u00ebsi e nj\u00eb VM sh\u00ebrbimi t\u00eb ve\u00e7ant\u00eb, Cisco HyperFlex Data Platform controller, e cila krijohet n\u00eb secil\u00ebn nod\u00eb ruajtjeje. N\u00eb konfigurimin ton\u00eb, VM sh\u00ebrbimi kishte t\u00eb ndara tet\u00eb vCPU dhe 72 GB RAM, q\u00eb nuk \u00ebsht\u00eb pak. Kujtoj se vet\u00eb hosti ka 28 b\u00ebrtha fizike dhe 512 GB RAM.<\/p>\n

      VM sh\u00ebrbimi ka qasje n\u00eb disk\u00ebt fizik\u00eb direkt p\u00ebrmes kalimit t\u00eb SAS-kontrollerit 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, dhe me an\u00eb t\u00eb nj\u00eb agjenti q\u00eb lejon d\u00ebrgimin e komandave n\u00eb API t\u00eb hipervizorit. Agjenti \u00ebsht\u00eb p\u00ebrgjegj\u00ebs p\u00ebr pun\u00ebn me snapshot-at dhe klon\u00ebt e HyperFlex.<\/p>\n

      N\u00eb hipervizor, burimet diskore montohen si nj\u00eb NFS- ose SMB-share (varet nga tipi i hipervizorit, e guessoni se cili \u00ebsht\u00eb cili). Dhe posht\u00eb kapakut, kjo \u00ebsht\u00eb nj\u00eb sistem i shp\u00ebrndar\u00eb dosjesh q\u00eb lejon shtimin e tipar\u00ebve t\u00eb plot\u00eb t\u00eb sistemeve t\u00eb ruajtjes: ndarje e holl\u00eb e volumeve, kompresim dhe deduplication, snapshot-e me teknologjin\u00eb Redirect-on-Write, replikim sinkron\/asinkron.<\/p>\n

      VM sh\u00ebrbimi ofron qasje n\u00eb nd\u00ebrfaqen WEB t\u00eb menaxhimit t\u00eb sistemit HyperFlex. Ka integrim me vCenter, dhe pjesa m\u00eb e madhe e detyrave p\u00ebrditshme mund t\u00eb kryhen nga aty, por datastoret, p\u00ebr shembull, jan\u00eb m\u00eb t\u00eb lehta p\u00ebr t\u2019i krijuar nga nj\u00eb nd\u00ebrfaqe e ve\u00e7ant\u00eb webi, n\u00ebse keni kaluar tashm\u00eb n\u00eb nd\u00ebrfaqen HTML5 t\u00eb shpejt\u00eb, ose duke p\u00ebrdorur nj\u00eb klient t\u00eb plot\u00eb Flash me integrim t\u00eb plot\u00eb. N\u00eb webin 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 nodi n\u00eb klaster \u2014 nodet llogarit\u00ebse. K\u00ebto mund t\u00eb jen\u00eb server\u00eb rack ose blade pa disqe t\u00eb instaluara. N\u00eb k\u00ebta server\u00eb mund t\u00eb ekzekutoni VM, t\u00eb dh\u00ebnat e t\u00eb cilave ruhen n\u00eb server\u00ebt me disqe. N\u00eb aspektin e aksesit n\u00eb t\u00eb dh\u00ebna, nuk ka dallim mes typave t\u00eb nodave, sepse arkitektura parashikon abstraksionin nga vendndodhja fizike e t\u00eb dh\u00ebnave. Marr\u00ebdh\u00ebnia maksimale nd\u00ebrmjet nodave llogarit\u00ebse dhe nodave t\u00eb depozitimit \u00ebsht\u00eb 2:1.<\/p>\n

      P\u00ebrdorimi i nodave llogarit\u00ebse rrit fleksibilitetin n\u00eb shkall\u00ebzimin e burimeve t\u00eb klasterit: nuk \u00ebsht\u00eb e nevojshme t\u00eb blejm\u00eb nodet me disqe, n\u00ebse kemi nevoj\u00eb vet\u00ebm p\u00ebr CPU\/RAM. P\u00ebr m\u00eb tep\u00ebr, mund t\u00eb shtojm\u00eb nj\u00eb kosh blade dhe t\u00eb arrijm\u00eb kursim n\u00eb vendosjen e server\u00ebve n\u00eb raft.<\/p>\n

      Si rezultat, kemi nj\u00eb platform\u00eb hiper-konvergjente me k\u00ebto tipare:<\/p>\n