UNIVERSITETI POLITEKNIK – TIRANË Fakulteti i Teknologjisë së Informacionit Sheshi Nënë Tereza, 1 – Tiranë Tel/Fax : +355 4 2278 159
PROJEKT – DIPLOMË Cikli i Dytë i Studimeve Master i Shkencave në Inxhinieri Elektronike TEMA : Java Grid Computing Computing , krahasimi i performancës performancës së librarive Hazelcast dhe Hadoop me anë të një implementimi të tyre
DEKANI PËRGJEGJËSI I DEPARTAMENTIT DEPARTAMENTIT UDHËHEQËSI DIPLOMANTI
Prof. Rozeta Miho Mitrushi Prof. Asoc. Bexhet Kamo Prof. Asoc. Bexhet Kamo Arvit Varfaj
Tiranë 2011-2012
REPUBLIKA E SHQIPËRISË UNIVERSITETI POLITEKNIK I TIRANËS FAKULTETI I TEKNOLOGJISË TEKNOLOGJISË SË INFORMACIONIT INFORMACIONIT DEPARTAMENTI I ELEKTRONIKËS DHE TELEKOMUNIKACIONIT Sheshi ―Nënë Tereza‖, Nr. 1, Tiranë Tel. dhe Fax : (+355) 4 2278 159 DEKANI
Prof. Rozeta Miho Mitrushi
FLETË – DETYRË mbi PROJEKT – DIPLOMËN Cikli i Dytë i Studimeve Master i Shkencave në Inxhinieri Elektronike Studenti :___ _Arvit Gëzim Varfaj_________________ Nr. i Regj. POTINB 010037 (emri, atësia, mbiemri) Departamenti i Elektronikës dhe Telekomunikacionit
I.
Tema e Projekt – Diplomës
Java Grid Computing Computing , krahasimi i performancës së librarive Hazelcast dhe Hadoop me anë të një implementimi implementimi të tyre
II. Afati i dorëzimit të Projekt- Diplomës Tetor 2012
III. Të dhëna mbi Projekt- Diplomën 1. Njohja me infrastrukturën e një rrjeti grid. 2. Llojet e grid dhe ndarja e tyre sipas funksionit. 2
3. Libraritë e krijimit te rrjeteve grid Hazelcast dhe Hadoop.
IV. Përmbajtja e Projekt- Diplomës A. Relacioni 1. Njohja me konceptet themelore të grid. 2. Pjesët përbërëse te një grid dhe ndërveprimi ndërmjet tyre. 3. Elementët kryesore qe duhen pasur parasysh për implementimin e një arkitekture grid. 4. Koncepti i programimit ―MapReduce‖ dhe përdorimi p ërdorimi i tij tek Hadoop dhe Hazelcast. 5. Zgjidhja e problemit te numërimit te funksioneve monotone boolean-e me ane te dy librarive dhe krahasimi i rezultateve.
V. Kontrolloi në Departament (studenti është i detyruar që me materialet e përgatitura në atë kohë të paraqitet në Departament) 1.
Mars
Kontrolloi
Parë
2.
Shtator
Kontrolloi
Dytë
3.
Tetor
Kontrolloi
Tretë
Udhëheqësi
Prof. Asoc. Bexhet Kamo_________ (titulli, emri, mbiemri)
Data e miratimit të temës
_20.03.2012___________ _20.03.2012_________ __
Përgjegjësi i Departamentit Prof. Asoc. Bexhet Kamo _____ _______________________________
3
TABELA PËRMBLEDHËSE
1.
Hyrje: Rrjeti kompjuterik nga këndvështrimi i GRID ........................ ................................. .................. .................. .................. ............ ... 6 1.1 Shfrytëzimi i burimeve të nënshfrytëzuara ................. .......................... ................... ................... .................. .................. .................. ............ ... 8 1.2 Kapaciteti paralel i CPU ......................................................................................................... 9 1.3 Burimet virtuale dhe organizatat virtuale për bashkëpunim .................. ........................... .................. .................. ........... 10 10 1.4 Aksesi tek burimet shtese.................................................................................................... 12 1.5 Balancimi i burimeve ........................................................................................................... 12 1.6 Besueshmëria ...................................................................................................................... 14 1.7 Menaxhimi ........................................................................................................................... 16 1.8 Përmbledhje ........................................................................................................................ 17
2.
Termat dhe konceptet e GRID ............................................................................................... 19 2.1 Tipet e burimeve ................................................................................................................. 19 2.1.1 Llogaritje ....................................................................................................................... 19 2.1.2 Memorja ....................................................................................................................... 19 2.1.3 Komunikimi ................................................................................................................... 22 2.1.4 Software dhe liçencat ................................................................................................... 22 2.1.5 Pajisje, kapacitete, arkitektura dhe policime të veçanta .................. ........................... ................... .................. ........ 23 2.2 Aplikimet dhe punët ............................................................................................................ 23 2.3 Skedulimi, rezervimi dhe pasiviteti ................... ............................ .................. .................. .................. ................... ................... .................. ........... .. 24 2.4 Përbërësit e programit të grid .................. ........................... .................. .................. .................. .................. .................. .................. .................. ............ ... 26 2.4.1 Përbërësit e menaxhimit .............................................................................................. 26 2.4.2 Menaxhimi i një grid të shpërndarë .................... ............................. .................. .................. .................. ................... ................... ........... .. 26 2.5 Intragrid and intergrid ......................................................................................................... 27 2.6 Përmbledhje ........................................................................................................................ 29
3.
Projektimi i arkitekturës grid ................................................................................................. 30 3.1 Ndërtimi i një arkitekture rrjeti ......................... .................................. .................. .................. .................. .................. .................. .................. ............ ... 30 3.1.1 Objektivat e zgjidhjes ................................................................................................... 31 3.1.2 Siguria ........................................................................................................................... 32 3.1.3 Disponueshmëria .......................................................................................................... 33
4
3.1.4 Performanca ................................................................................................................. 35 3.2 Modelet e arkitekturës grid ................................................................................................. 35 3.2.1 Grid llogaritës ............................................................................................................... 35 3.2.2 Grid të dhënash ............................................................................................................ 36 3.3 Topologjitë grid ................................................................................................................... 37 3.3.1 Intragrid ........................................................................................................................ 39 3.3.2 Extragrid ....................................................................................................................... 40 3.3.3 Intergrid ........................................................................................................................ 41 3.3.4 e-Utilitetet (e-Utilities) ................................................................................................. 41 4.
Hadoop i Apache dhe Ekosistemi Hadoop ............................................................................ 43 4.1 MapReduce .......................................................................................................................... 44 4.1.1 Java MapReduce MapReduc e e re API .................................. ................ ................................... ................................... .................................... ....................... ..... 44 4.2 Rrjedhja e të dhënave ......................................................................................................... 45 4.2.1 Fuksionet kombinuese.................................................................................................. 48 4.3 File sistemet e shpërndarë Hadoop................ Hadoop......................... .................. .................. .................. .................. ................... ................... .............. ..... 50 4.3.1 Konstruksioni i HDFS ..................................................................................................... 51 4.3.2 Konceptet HDFS ............................................................................................................ 52
5.
Pjesa eksperimentale ............................................................................................................ 55 5.1 Ambjenti i testimit ............................................................................................................... 55 5.1.1 Problemi ....................................................................................................................... 55 5.2 Instalimi i Hadoop ne sistemin e shfrytëzimit Ubuntu ................. .......................... .................. .................. .................. ............ ... 56 56 5.3 Kodi Hadoop ........................................................................................................................ 73 5.4 Rezultatet per Hadoop ........................................................................................................ 74 5.5 Instalimi i Hazelcast ............................................................................................................. 77 5.6 Kodi Hazelcast...................................................................................................................... 81 5.7 Rezulatet per Hazelcast ....................................................................................................... 82 5.8 Përfundime .......................................................................................................................... 85 5.9 Punime për te ardhmen ...................................................................................................... 86
5
1. Hyrje: Rrjeti kompjuterik nga këndvështrimi këndvështrimi i GRID Rrjet kompjuterik mund të ketë kuptime të ndryshme për individë të ndryshëm. Në një vizion më të gjerë shpesh është i paraqitur si një analogji e rrjeteve të ushqimit, ku përdoruesit ( ose pajisjet elektrike) kane akses tek rryma elektrike përmes prizave të murit pa u interesuar fare, apo pa asnjë konsiderate se ku apo si kjo rryme rryme elektrike gjenerohet. Në ketë vizion të rrjetit kompjuterik, kompjuterimi (computing) behet depërtues dhe përdoruesit individuale (ose aplikimet e klientëve) marrin akses në burimet kompjuterike (procesorët, magazinimi, të dhënat,aplikimet dhe kështu me radhe) sipas nevojës me pak ose aspak njohuri se ku këto burime janë të vendosura, ose çfarë janë teknologjitë e nënvizuara, hardwaret, sistemet operative e me radhe. Megjithëse ky vizion i rrjetit kompjuterik mund të rroke imagjinatën e ndokujt dhe mundet që ndonjë dite, me të vërtetë, të behet një realitet, ka shume çështje teknike, biznesi, politike dhe sociale që kane nevoje të adresohen. Nëse në e konsiderojmë ketë vizion si një qellim final, atëherë ka shume hapa të vegjël për tu bere që të mund ta realizojmë atë. Secili prej këtyre hapave të vegjël ka përfitimet e veta. Megjithatë, rrjeti kompjuterik mund të shihet si një udhëtim përmes një shtegu të teknologjive të ndryshme të integruara dhe të zgjidhjeve që na afrojnë neve me pranë qëllimit final. Vlerat e tija baze janë në teknologjitë infrastrukturore, kompjuterike të shpërndara veçanërisht. që janë të përfshira në mbështetjen e aplikimeve nderorganizacionale dhe ndarjen e burimeve — me një fjale, virtualizim — virtualizim ermes teknologjive, platformave dhe organizatave. Ky lloj virtualizimi është i realizueshëm vetëm përmes përdorimit të standarteve të hapura. Standartet e hapura ndihmojnë në sigurimin se këto aplikime, në mënyre transparente kane një avantazh ndaj çdo lloj burimi të përshtatshëm që mund të jete i disponueshëm për to .Një mjedis, që ofron aftësinë për të ndare dhe një akses transparent në burimet, përmes një mjedisi të shpërndarë dhe heterogjen, jo vetëm që kërkon teknologji për virtualizimin e disa burimeve, por dhe teknologji e standarte në fushat e skedulimit, sigurimit, llogaritjes, menaxhimit të sistemeve e kështu me radhe. Rrjeti kompjuterik mund të përcaktohet si një nga teresite e niveleve të virtualizimit përgjatë vazhdimësisë. Me saktësisht, përgjatë kësaj vazhdimësie kur dikush mund të thotë se një zgjidhje e veçante është një implementim i rrjetit kompjuterik përkundër një implementimi implementim i relativisht të thjeshte me përdorim të burimeve virtuale, kjo është një çështje opinioni. Por edhe në nivelet me të thjeshta të virtualizimit çdokush mund të thotë ketë se janë përdorur teknologjitë që mundësojnë rrjetin. 6
Kjo vazhdimësi është ilustruar në Figurën 1-1 në faqen 5. Duke nisur nga pjesa poshtë, majtas ju shihni një sistem të vetëm copëzimi. Virtualizimi fillon me aftësinë për të krijuar një aparat brenda aparateve virtuale. Duke ecur para me ketë spektër ju filloni të bëheni të afte të virtualizoni burime të ngjashme apo homogjene. Virtualizimi aplikohet jo vetëm tek serverat dhe CPU-të, por edhe tek magazinimi, rrjetet, madje edhe aplikimet. Duke ecur para ju filloni të virtualizoni burimet e padëshiruara. Hapi tjetër është virtualizimi i ndërmarrjes, jo vetëm në një qendër të dhënash apo brenda një departamenti , por përmes një organizate të shpërndarë, dhe me në fund në finale, virtualizimi jashtë ndërmarrjes, përmes Internetit, ku ju mund të keni akses burimesh në një set të e të furnizuesve të tyre, ose ju mund të integroni informacionin përmes një rrjeti bashkëpunëtoresh.
Figura 1-1 Virtualizimi pandërprerë
Implementimi i hershem i rrjetit të kompjuterëve ka patur tendencën të jete i brendshëm për vetëm një kompani apo organizate. Megjithatë rrjete nder-organizatash gjithashtu janë implementuar implementuar dhe do të jene një pjese e rëndësishme rëndësishme e kompjuterëve kompjuterëve dhe e optimizimit të biznesit në të ardhmen. Dallimet mes rrjeteve intra-organizacionale dhe inter-organizacionale nuk janë të mbështetura në diferencat teknologjike. Në të kundërt ato janë të bazuara në përzgjedhjet 7
e konfigurimit të dhëna: Sigurimi domain-ve, shkallet e izolimit të dëshiruara, tipi i politikave dhe qëllimi i tyre, si dh detyrimet kontraktuake në mes përdoruesve dhe ofruesve të infrastrukturave. infrastruktur ave. Këto çështje nuk janë me natyre tërësisht arkitekturore Është në interesin me të madh të industrisë që të sigurohet se nuk kanë një ndarje artificiale ndërmjet paradigmave kompjuterike të shpërndara dhe modeleve përmes kufijve organizacionale dhe infrastrukturave të brendshme të IT.. Rrjeti i kompjuterëve përfshin një set tërësor të standarteve të hapura për shërbimet Web dhe ndërfaqet që bëjnë shërbimet, ose burimet kompjuterike të gjëndëshme në Internet. Shume shpesh teknologjitë e rrjeteve përdoren në cluster homogjene dhe ato mund t`u shtojnë vlere këtyre cluster-ve duke i asistuar, p.sh me skedulime apo ofrime të burimeve në këtë cluster. Termi rrjet ( grid) dhe teknologjitë që lidhen me të, aplikohen përgjatë gjithë këtij spektri. Nëse në fokusojmë vëmendjen tone mbi zgjidhjet kompjuterike të shpërndara, atëherë në mund të konsiderojmë njërin definicion të rrjetit kompjuterik shpërndarjen e kompjuterëve përmes burimeve të virtualizuara. Qëllimi është të krijohet iluzioni i një kompjuteri virtual të thjeshte, të madh e të fuqishëm, jashtë një koleksioni të sistemeve të lidhura (edhe mundësisht heterogjene), të cilat ndajnë kombinacione të ndryshme burimesh.
1.1 Shfrytëzimi i burimeve të nënshfrytëzuara Kur ju zhvilloni një rrjet, kjo do të thotë se ndesheni me një set kërkesash të biznesit. Për të përshtatur sa me mire aftësitë e rrjetit kompjuterik me Këto kërkesa, është e dobishme të mbani në mendje disa motivime të përgjithshme të përdorimit të rrjetit kompjuterik. Një nga përdorimet baze të rrjetit të kompjuterëve është përdorimi i një aplikimi tashme ekzistues në një aparat të ndryshëm. Aparati,në të cilin aplikimi ka punuar normalisht, mund të jete i zëne për shkak të një piku aktiviteti. Puna, për të cilën behet fjale, duhet të behet në një makine tjetër e papune, në rrjet. Se paku ka dy parakushte për këtë skenar. E para, aplikimi duhet të ekzekutohet në distance dhe pa një overhead (të sipërm) të panevojshme.. E dyta , aparati në distance duhet të plotësoje ndonjë kërkese speciale të hardware, software, apo kërkese burimi të imponuar nga aplikimi. P.sh, një grumbull punësh që kërkon goxha kohe si futja e një seti të dhënash për të prodhuar një set rezultatesh do të ishte, ndoshta, rasti i përdorimit me ideal e i thjeshte i një rrjeti. Nëse sasia e të dhënave që jepen e që dalin është e madhe, mund të kërkohet me shume mendim e planifikim për një përdorim efikas të një rrjeti në një pune të tille. Zakonisht, nuk ka kuptim përdorimi i një ―word procesori ‖ në distance në rrjet, sepse ka shume të ngjare se do të këtë vonesa me të mëdha e me shume pika potenciale dështimi. Në shume organizata, ka sasi të mëdha të burimeve kompjuterike të papërdorura. Pjesa me e madhe e desktop-ve janë të zëne vetëm 5% të kohës se një dite pune. Në disa 8
organizata edhe aparatet e serverit shpesh mund të jene papune. Rrjeti kompjuterik ofron një kornize për shfrytëzimin e këtyre burimeve të nënshfrytëzuara dhe kështu ka mundësinë të rrisë thellësisht efiçencen e përdorimit të burimeve. Burimet e proçesimit nuk janë të vetmet që mund të jene të nënshfrytëzuara. Shpesh kompjuteri mund të këtë një kapacitet tejet të madh të diskut të papërdorur. Rrjeti kompjuterik (specifikisht, data grid ) mund të përdoret për të grumbulluar këtë magazinim të papërdorur në një magazine virtuale të të dhënave të mëdha, mundësisht të konfiguruar për arritjen e një performancë më të mirë e besueshmërinë me të madhe se çdo pajisje të veçante. Nëse një grumbull punësh kërkon leximin e një numri të madh të dhënash, Këto të dhëna automatikisht mund të përsëriten në disa pika strategjike të ndryshme të rrjetit. Kështu, nëse puna duhet të kryhet në një aparat në distance në rrjet, e dhëna është tashme atje dhe nuk do të duhet të lëvizë tek ajo pika në distance. . Kjo ofron përfitime të një performancë të qarte. Gjithashtu çdo kopje e të dhënave mund të përdoret si rezerve kur kopjet e para janë dëmtuar ose nuk janë të disponueshme. Një tjetër përfitim i rrjetit është balancimi me i mire i përdorimit të burimit. Një organizate mund të këtë ngarkesa rastësore, të paparashikueshme të aktivitetit, gjë që kërkon me tepër burime. Nëse aplikimet janë me aftësim rrjeti, ato mund të çohen tek aparatet e nënshfrytëzuara përgjatë këtyre ngarkesave pik. Në fakt disa implementime rrjeti mund të migrojnë pjesërisht punët e përfunduara. Në përgjithësi një rrjet mund të ofroje një rruge konsistonte për balancimin e peshës në një federate burimesh mete gjere. Kjo aplikohet tek CPU, magazinimi dhe ndonjë tip tjetër burimi që mund të jete i disponueshëm në një rrjet.
1.2 Kapaciteti paralel i CPU Potenciali për një kapacitet paralel e masiv të CPU është një vizionet me të përgjithshme e tiparet me atraktive të një rrjeti. Për me tepër, për shkaqe të pastra shkencore, një fuqi e tille e kompjuterit po i jep rruge një evolucioni në industri të tilla si në fushën e boimjekësisë, modelimit financiar, shfrytëzimit të naftës, të animacionit të filmave dhe shume të tjera. Atributi i përgjithshëm në mes të gjitha këtyre përdorimeve është se aplikimet janë shkruar që të përdorin algoritme, të cilat mund të ndahen në pjese operative të pavarura. Një aplikim rrjeti intensiv i CPU mund të mendohet si një tërësi nënpunësh me të vogla, ku secila ekzekutohet në një aparat të ndryshëm në rrjet. Për ta shtrire këtë, Këto nënpunë (grupe të vogla punësh) nuk kane nevoje të komunikojnë njëra me tjetrën sado i shkallëzuar që të behet aplikimi. Një aplikim i shkallëzuar në mënyrë perfekte, p.sh. do ta përfundoje në 1/10 e kohës nëse ai përdor dhjete here numrin e procesorëve. 9
Barrierat shpesh ekzistojnë për të perfeksionuar shkallëzimin. Barriera e pare varet nga algoritmet e përdorura për ndarjen e aplikimit në mes shume CPU-ve. Nëse algoritmi mund të ndahet vetëm në një numër të kufizuar të pjesëve operative të pavarura, atëherë kjo formon një barriere të shkallëzuar. Barriera e dyte shfaqet nëse pjesët nuk janë tërësisht të pavarura; kjo mund të shkaktoje pretendim, gjë që mund të kufizoje shkallëzimin. P.sh. nëse të gjitha nenpunet kane nevoje të lexohen e të shkruhen nga një skedar ose databaze të përbashkët, limitet e aksesit të këtij skedari apo databaze do të bëhen faktorë kufizues të shkallëzimit të aplikimit. Burimet e tjera të këtyre grindjeve ndërmjet-punësh në një rrjet aplikimi paralel përfshijnë mesazhe të komunikimeve të fshehta ndërmjet punëve, kapacitete komunikuese në rrjet, protokolle sinkronizimi, gjerësi brezi për hyrjedalje për magazinim ose pajisje të tjera, si dhe vonesa të tjera që interferojne me kërkesat në kohe reale. Ka shume faktorë që duhen marre në konsiderate në një aplikim me mundësi rrjeti. Çdokush duhet ta kuptoje se jo të gjitha aplikimet mund të transformohen për të operuar në paralel në një rrjet e të realizojnë shkallëzimin. Për me tepër nuk ka mjete praktike për transformim arbitrar të aplikimeve për të shfrytëzuar kapacitetet paralele të një rrjeti. Ka disa mjete praktike që programuesit e aftë të aplikimeve mund të përdorin për të shkruar një aplikim në rrjet paralel. Megjithatë, transformimi automatik i aplikimit është një shkence në fillimet e saj. Kjo mund të jete një pune e vështire dhe shpesh kërkon talente matematikore e programimi, nëse është e mundur në një situate të dhëne. Aplikimet e reja kompjuterike intensive të shkruara sot janë dizenjuar për ekzekutim paralel dhe ato do të jene lehtësisht të aftësuar për rrjet nëse ato tashme nuk ndjekin protokolle rrjet emergjente dhe standarte.
1.3 Burimet virtuale dhe organizatat virtuale për bashkëpunim Një aftësi tjetër e mundësuar nga rrjeti kompjuterik është ofrimi i një mjedisi bashkëpunimi në mes një audience me të gjere. në të kaluarën shpërndarja e kompjuterit e premtonte këtë bashkëpunim dhe deri në njëfarë shtrirje e realizonte atë. Rrjeti kompjuterik mund ti shtrije Këto aftësi tek një audiencë edhe me e gjere, ndërkohe që ofron standarte të rëndësishme që aftësojnë sisteme shume heterogjene për të punuar sebashku për formimin e imazhit të një sistemi të gjere, virtual, kompjuterik, i cili ofron një game burimesh siç jepet në ilustrimin në Figurën 1-2. Përdoruesit e rrjetit mund të organizohen, në mënyre dinamike, në një seri organizatash virtuale, ku secila të këtë një politike të ndryshme kërkesash. Këto organizata virtuale mund të ndajnë burimet e tyre në mënyre kolektive si një rrjet me i gjere. Ndarja fillon me të dhëna në formën e skedarëve apo databaze. Një rrjet të dhënash mund të shtrijnë aftësitë e të dhënave në disa mënyra. Se pari, skedarët apo databazat mund të 10
kenë si hapësire shume sisteme e kështu të kenë kapacitete me të gjera se në çdo sistem të veçante. Një hapësire e tille mund të përmirësoje normat e transferimit të të dhënave përmes përdorimit të teknikave të ndarjes në vija-vija. E dhëna mund të duplikohet përmes rrjetit për të shërbyer si backup e mund të vendoset në ose pranë aparateve, që e me shume gjasa mund të kenë nevoje për të dhënën, në lidhje me teknikat e avancuara të skedulimit. Ndarja nuk është e kufizuar vetëm për skedarët, por gjithashtu përfshin edhe burimet e tjera të tilla si pajisjet e specializuara, software-ët, shërbimet, licencat dhe kështu me radhe. Këto burime janë të virtualizuara për tu dhëne atyre një ndërveprim me uniform në mes pjesëmarrësve heterogjene të rrjetit. Pjesëmarrësit dhe përdoruesit e rrjetit mund të jene anëtare të disa organizatave reale e virtuale. Rrjeti mund të ndihmoje në forcimin e rregullave të sigurisë ndërmjet tyre si dhe implementimin e politikave që mund të zgjidhin prioritetet për të dyja palët burimet e përdoruesit.
Figura 1-2 Rrjeti virtualizon burimet gjeografike të shpërndara në mënyre heterogjene 11
1.4 Aksesi tek burimet shtese Siç edhe e kemi thëne, për me tepër si burime magazinimi të CPU , një rrjet mund të ofroje akses edhe ndaj burimeve të tjera.. Burimet shtese mund të ofrohen në numra dhe/ose kapacitete shtese. P.sh. nëse një përdorues ka nevoje të rrisë gjerësinë gjerësinë e tyre totale të brezit në Internet, që të implementojë një të dhëne të lidhur me makine kërkimi, puna mund të ndahet ndërmjet aparateve të rrjetit, të cilat kane lidhje të pavarura në Internet. Në këtë mënyre, kapaciteti total i kërkimit është shumëfishuar për sa kohe që çdo aparat ka një lidhje të veçante me Internetin. Nëse aparatet kane ndare lidhjen me Internetin, nuk do të këtë një rritje efektive në gjerësinë e bandës. Disa aparate mund të kenë software me të shtrenjta, të licencuara, sesa kërkesat e përdoruesve. Punët e përdoruesve mund të dërgohen tek Këto aparate duke shfrytëzuar në mënyre me të plote licencat e software-ve. Disa aparate në rrjet mund të kenë pajisje speciale. Pjesa me e madhe e jona përdorin printerë në distance, ndoshta me aftësi ngjyrash me të avancuara ose shume me të shpejte. Në mënyre të ngjashme, një rrjet mund të përdoret edhe si mundësi përdorimi e pajisjeve të tjera speciale. P.sh. një aparat mund të këtë një DVD-writer vete-ushqyese me shpejtësi të madhe, që mund të përdoret për publikim me të shpejte të një sasie të dhënash. Disa aparate në rrjet mund të lidhen me mikroskopë elektronike, skaner, të cilët mund të veprojnë në distance. Në këtë rast skedulimi dhe rezervimi janë të rëndësishëm. Një kampion mund të dërgohet më përpara tek pajisja që mban mikroskopin. Atëherë, përdoruesi mundet të përdore aparatin në distance(me telekomande), duke ndryshuar pamjet perspektive deri sa të përftojmë imazhin e dëshiruar. Rrjeti mund të aftësoje një akses me të përpunuar potencialisht të diagnozës mjekësore në distance e të veglave të kirurgjisë robotike në dy rruge ndërveprimi në distance. Variacionet limitohen vetëm nga imagjinata e çdokujt. Sot në kemi pajisje driver-ësh në distance për printerë. Eventualisht, do të shohim standartet për pajisje driver-ësh të aftësuara në rrjet për shume pajisje e burime jo të zakonshme. të gjitha Këto do të bëjnë që rrjeti të shihet si një sistem i gjere me një koleksion burimesh përtej asaj që mund të jete e disponueshme disponueshme në një aparat aparat të vetëm konvencion konvencional. al.
1.5 Balancimi i burimeve Një rrjet përfshin një numër të madh burimesh që janë kontribut i pajisjeve individuale dhe jep idenë e sistemit të gjere të vetëm. Për aplikimet që i aftëson rrjeti, ai mund të ofroje një efekt balancues burimi duke skeduluar punimet në rrjet të aparateve me përdorim të paket, siç ilustrohet në Figurën 2-2 në faqen 13. Ky tipar mund të provoje 12
vlerën e paçmueshme për menaxhimin e ngarkesave pik të rastësishme në pjese , të një organizate me të gjere. kjo mund të ndodhe në dy mënyra: Një ngarkese e papritur mund të adresohet tek një aparat, relativisht i papune, në rrjet. Nëse rrjeti është tashme duke u përdorur komplet, puna me prioritetin me të vogël, që është duke u bere në rrjet, përkohësisht mund të ndërpritet, ose të anullohet, dhe të realizohet me vone përsëri, në mënyre që të lere hapësire për punën me prioritet me të madh. ●
●
Pa një infrastrukture rrjeti, vendime të tilla balancuese, janë të vështira për tu marre edhe për tu ekzekutuar. Rastësisht, një projekt mund të marre befas një rendësi të madhe e të këtë një afat specifik. Një rrjet nuk mund të beje një mrekulli e të plotësoje një afat kur ai është tashme shume afër. Megjithatë , nëse përmasa e punës është e njohur, nëse ajo është një lloj pune që mund të ndahet në nenpune të vogla, edhe nëse kemi burime të disponueshme të mjaftueshme pas ndërprerjes se punës me prioritet të ulet, rrjeti mund të sjelle një fuqi mjaft të madhe procesimi për zgjidhjen e problemit.
13
Figura 1-3 Punët dërgohen në pjesët me pak të ngarkuara të rrjetit për të balancuar peshat
Përfitime të tjera me fine mund të ndodhin gjate përdorimit të rrjetit për balancimin e peshës. Kur punët komunikojnë me njëra-tjetrën, me Internetin, apo me magazinat e burimeve, një skedulim i avancuar mund të ndihmoje në minimizimin e trafikut të komunikimit apo në minimizimin e distancës se komunikimeve. Potencialisht, kjo redukton komunikimin si dhe format e tjera të përplasjeve në rrjet. Me në fund, një rrjet ofron një infrastrukture të shkëlqyer për burime të ndërmjetësuara. Burime individuale mund të profilizohen për përcaktimin e disponibilitetit e kapacitetit të tyre dhe kjo gjë mund të faktorizohet në skedulimin e rrjetit. Në vartësi të realizueshmërisë së llogaritjeve në vend, organizata të ndryshme pjesëmarrëse në rrjet, mund të ngrenë kreditet e rrjeteve dhe ti përdorin ato në kohet kur ju duhen burime shtese. Kjo mund të formoje bazat për llogaritjen e rrjetit si dhe aftësinë për shpërndarjen me të mire të punës ( e të kostos) se rrjetit.
1.6 Besueshmëria 14
Sistemet kompjuterike, konvencionale, ―high-end ‖ përdorin hardware të shtrenjte për të rritur besueshmërinë e tyre. Ata janë ndërtuar duke përdorur çipe me qarqe të tepërta, që ―votojnë‖ mbi rezultatet dhe përmbajnë logjike për realizimin e riaftësimit (recover) nga disa lloje dështimesh të hardware-ve. Aparatet, gjithashtu, përdorin procesorë dublikate me priza të ngrohta, në mënyre që kur ata të dështojnë, njëra mund të zëvendësohet pa u fikur të tjerat. Pajisjet e ushqimit dhe sistemet e ftohjes janë të duplikuara. Sistemet operojnë me burime speciale ushqimi, që mund të ndezin gjeneratorët nëse ushqimi i pajisjes ndërpritet. të gjitha Këto ngrenë një sistem të besueshëm, por me një kosto të madhe për shkak të duplikimeve të komponentëve të shtrenjte. Në të ardhmen në do të shohim një trajtim plotësues të besueshmërisë, që mbështetet në software dhe hardware. Një rrjet është pikërisht fillimi i një teknologjie të tille. Sistemet në një rrjet mund të jene, relativisht, jo të shtrenjte dhe të shpërndarë gjeografikisht. Kështu, nëse ka një dështim ushqimi apo të ndonjë lloji tjetër tek ndonjë zone, pjesët e tjera të rrjetit nuk duhet të jene të ndikuara. Software i menaxhimit të rrjetit automatikisht duhet të kaloje punët nga ato pajisje tek të tjerat nëse në rrjet ka një dëmtim. Në situata kritike, reale, kopje të shumta të punëve të rëndësishme mund të realizohen në aparate të ndryshme në të gjithë gjithë rrjetin, siç edhe ilustrohet në Figurën 2-3 të faqes 15. Rezultatet e tyre mund të kontrollohen për çdo lloj pasaktësie si p.sh dështime kompjuterike, korruptim i të dhënave, apo ngatërrime.
15
Figura 1-4 Konfiguracioni 1-4 Konfiguracioni i tepruar i rrjetit
Sisteme të tilla rrjeti do të përdorin kompjuterim autonom . Ky është një tip software i cili automatikisht shëron problemet në rrjet, bile edhe përpara se një operator apo menaxher të këtë dijeni për to. Në parim, pjesa me e madhe e atributeve të besueshmërisë, që realizohet duke përdorur hardware në sistemet e sotme me disponibilitet të larte, mund të realizohen duke përdorur software në një rrjet të se ardhmes.
1.7 Menaxhimi Qëllimi, për të virtualizuar burimet në rrjet dhe në mënyre me uniforme të menaxhohen sistemet heterogjene, do të krijoje oportunitete të reja për një menaxhim me të mire, me të gjere, me të shpërndarë të infrastrukturës se IT. Do të jete me e lehte të shikoje kapacitet dhe përdorimin , duke e bere me të lehte për departamentet e IT të kontrolloje shpenzimet për burimet kompjuterike në një organizate me të madhe. Rrjeti ofron menaxhim të prioriteteve ndërmjet projekteve të ndryshme. Në të kaluarën, çdo projekt mund të këtë qene përgjegjës vetëm për burimet e veta të IT si dhe shpenzimet e lidhura me to. Shpesh Këto burime mund të kenë qene të nënshfrytëzuara, 16
ndërkohe që një projekt tjetër është në vështirësi dhe ka nevoje për me tepër burime për shkak të ngjarjeve të papritura. Me një pamje me të gjere që një rrjet të ofron, mund të behet me e lehte të kontrollosh e të menaxhosh situata të tilla. Siç edhe ilustrohet në Figurën 2-4, administratoret mund të ndryshojnë çdo lloj numri politikash që ndikojnë në atë se si organizata të ndryshme mund të ndajnë apo të konkurrojnë për burime. Përdorimi i të dhënave të përmbledhura mbi një set të gjere projektesh mund të shtoje aftësinë e organizatës në projektimin e nevojave në të ardhmen. Kur kërkohet mirëmbajtje puna e rrjetit mund të riadresohet tek aparatet e tjera pa dëmtuar projektet e përfshira. Një kompjuterim autonom mund të këtë vend këtu, gjithashtu. Mjete të ndryshme mund të jene të afta të identifikojnë drejtimet e rëndësishme nëpërmjet rrjetit, duke e informuar menaxhimin e atyre që kërkojnë vëmendje.
Figura 1-5 Administratoret mund të rregullojnë politikat për të alokuar me mire burimet
1.8 Përmbledhje 17
Rrjeti kompjuterik u mundëson organizatave (reale dhe virtuale), të kenë një avantazh në burimet e ndryshme kompjuterike, në atë mënyre që me përpara nuk ka qene e mundur. Ato mund të kenë avantazh në burimet e nënshfrytëzuara për plotësimin e kërkesave të biznesit duke ulur kostot shtese. Natyra e një rrjeti kompjuterik u jep organizatave avantazh në një procesim paralel, gjate bërjes së aplikimeve financiarisht me të studiuara si dhe duke i bere ato të realizueshme sa me pare. Rrjeti kompjuterik bën me të disponueshme me shume burime për me shume njerëz e organizata, si dhe lejon ata që janë përgjegjës për infrastrukturën e IT, të rrisin balancimin e burimeve, besueshmërinë dhe aftësinë menaxheriale.
18
2. Termat dhe konceptet e GRID Në këtë kapitull në do ju prezantojmë me disa terma dhe koncepte kyç rreth grid të cilat do ti përdorim gjatë kapitullit.
2.1 Tipet e burimeve Një grid është një koleksion mjetesh, shpesh referuar si nyje, burime, anëtarë, donator, klientë, hostet, dhe shumë terma të tjerë. Ata të gjithë kontribuojnë në çdo kombinim të burimeve të grid-it si një i tërë. Disa burime mund të përdoren nga të gjithë përdoruesit e grid, ndërkohë që të tjerët mund të kenë kufizime të veçanta.
2.1.1 Llogaritje Burimi më i zakonshëm është llogaritja e cikleve të siguruara nga procesorët e mjeteve të grid. Procesorët variojnë në shpejtësi, arkitekturë dhe platformën e sotware-ve, dhe në disa faktorë të tjerë të lidhur të tilla si, memorja, hapësira e ruajtjes dhe lidhja. Ka tre mënyra kryesore për të shfrytëzuar burimet e llogaritjes së grid. E para dhe më e thjeshta është që të ekzekutojmë një aplikacion ekzistues në një makine të vlefshme në grid sesa në nivel lokal. E dyta është që të përdorim një aplikim të dizenjuar për ndarjen e punës në mënyrë të tillë që pjesët e ndara mund të ekzekutohen në paralel në secilin nga pronësoret në grid. E treta është që të ekzekutomë aplikimin të cilin duhet ta riekzekutojmë disa here në pajisjet anëtare të grid. Shkallëzueshmëria është një matës për efektshmërine e përdorimit të shume procesorëve në grid. Nëse shtojmë numrin e procesorëve me dyfish, dhe nqs marrim që aplikimit i duhet gjysma e kohës për të mbaruar ekzekutimin, atëherë thuhet se aplikimi është tërësisht i shkallëzueshëm. Megjithatë, mund të ketë limite në shkallëzueshmërine, kur aplikimet munden të ndahen vetëm në numër të kufizuar pjesësh ekzekutimi , ose kur këto pjese shfaqin ndërvarësi si p.sh përplasjet për burime të disa llojeve.
2.1.2 Memorja Burimi i dyte me i përdorur në grid është memorja e të dhënave. Një grid, që ofron një pamje të integruar të memorjes se të dhënave, në disa raste quhet data grid .
19
Çdo makine në grid zakonisht ofron një sasi të memorjes për përdorim në grid , edhe nëse është e përkohshme. Memorja mund të jete e atashuar në procesor, ose mund të jete një memorje sekondare gjate përdorimit të hardiskut, ose në memorje të tjera permanente. Memorja e atashuar tek procesori zakonisht është ka një akses shume të shpejte, por është e përkohshme. Do të ishte me mire që të përdornim cache për të dhëna, ose të shërbejë si një memorje e përkohshme për aplikimet në ekzekutim. Memorja sekondare në grid mund të përdoret në mënyrën që të intereson për rritjen e kapacitetit, performances, shpërndarjen dhe besueshmërinë e të dhënave. Shume sisteme grid përdorin sisteme shfrytëzimi të montueshme në rrjet, si p.sh Andrew File System (AFS®), Network File System (NFS), Distributed Distributed File System (DFS™), ose
General Parallel File System (GPFS). Këto ofrojnë shkalle të ndryshme performancë, karakteristika sigurie e besueshmërie të ndryshme. Kapaciteti mund të rritet duke përdorur memorjen e disa pajisjeve dhe një sistemi shfrytëzimi unifikues. Çdo skedar i veçante, ose të dhëna baze, mund të përhapen në disa memorje , të cilat i përkasin disa pajisjeve të grid, gjë që eliminon kufizimin në madhësi të imponuar nga sistemi i shfrytëzimit, që ndodhet në secilën nga këto pajisje. Një sistem shfrytëzimi unifikues mund të ofroje gjithashtu, një emër të veçante për të gjithë grid-in. Kjo e bën me të thjeshte për përdoruesin, që ti referohet një të dhëne në grid pa ditur vendodhjen e saktë të të dhënës. Në një mënyrë të ngjashme programi i veçante i të dhënave baze mund të federoje një sasi të dhënash baze, ose skedar, për të formuar një tjetër të dhëne baze me të madhe dhe me gjithëpërfshirëse, e aksesueshme nëpërmjet përdorimit të funksioneve ―query‖.
20
Figura 2-1 Ndarja e të dhënave
Sistemet me të avancuara në grid mund të dublojnë, automatikisht, setin e të dhënave për të ofruar rezerve, për një besueshmëri dhe performancë me të larte. Një skedulim grid inteligjent mund të ndihmoje për të zgjedhur memorjen e përshtatshme (nyjën) e cila do të ruaje të dhënën, të bazuar në modele përdorimi. Atëherë punët mund të skedulohen me afër të dhënave, mundësisht, në nyjën direkt të lidhur me memorjen, e cila mban të dhënën e kërkuar. Ndarja e të dhënave mundet gjithashtu të implementohet nga sistemet e shfrytëzimit grid, ilustruar si në figuren 2-1. Kur kemi të dhëna sekuenciale ose struktura aksesi të parashikueshme (të korreluara), kjo teknike krijon efektin virtual të një memorjeje me të shpejte sesa aksesimi nga një hardisk të veçante. Kjo teknike është e rëndësishme sidomos në rastin kur kemi të bëjmë me vargje të dhënash multimediale ose gjate grumbullimit të sasive të mëdha të të dhënave nga skanimet me frekuence të larte CAT apo eksperimenteve me thërrmijat fizike. gjithashtu të implementojë ditarin (―journaling‖) Një sistem shfrytëzimi grid mundet gjithashtu kështu që të dhënat mund të rikuperohen në mënyrë të besueshme në rast të dështimeve të ndryshme. Për me shume disa sisteme implementojnë një mekanizëm të avancuar sinkronizimi për të reduktuar përplasjet gjate modifikimit të të dhënave të shpërndara nga shume përdorues njëkohësisht.
21
2.1.3 Komunikimi Rritja e kapacitet (gjerësi brezi) të komunikimit ndërmjet kompjuterëve ka bere që përdorimi i grid të jete akoma me praktik, krahasuar me gjerësinë e kufizuar të brezit të disponueshëm në fillimet e krijimit të sistemeve të shpërndara. Kështu që nuk është një surprize që një tjetër burim shume i rëndësishëm i grid është kapaciteti i transferimit të të dhënave. Kjo nënkupton komunikimin brenda grid dhe gjithashtu edhe atë me grid të tjerë. Komunikimet brenda grid janë të rëndësishme rëndësishme për dërgimin e punëve dhe të të dhënave që kërkohen nga këto pune brenda grid. Disa pune kërkojnë një procesim të madh të dhënash të cilat mund të mos ndodhen në të njëjtën pajisje ku po ekzekutohet puna. Gjerësia e brezit e disponueshme për këto lloj komunikimesh, në shume raste është një burim kritik që mund të kufizoje përdorimin e grid. Komunikimet me jashtë që aksesojnë internetin, mund të jene shume të vlefshme si p.sh. në rastin e një makine kërkimi. Pra pajisjet në ketë rast përveç lidhjes ndërmjet tyre kane edhe lidhjen për aksesim në internet. Kur këto lidhje nuk kryhen në të njëjtën rruge komunikimi, pajisjet mund të shfrytëzojnë plotësisht gjerësinë e brezit të ofruar nga interneti. Rrugët e komunikimeve rezerve janë në disa raste të domosdoshme për të reaguar me mire ndaj dështimeve potenciale të rrjetit ose trafikut të madh të të dhënave. Në disa raste duhet të parashikohen rrjete me shpejtësi të larte për të përmbushur kërkesat e punëve që kërkojnë transmetim të madh të dhënash. Një sistem menaxhimi i grid shfaq me mire topologjinë e rrjetit dhe nxjerr në pah vendet ku mund të kemi efektin ―grykë shisheje‖. Ky informacion me pas përdoret për të planifikuar përmirësimet fizike të rrjetit.
2.1.4 Software dhe liçencat Në grid mund të instalohen software të cilët mund të jenë shumë të shtrenjte që të instalohen në çdo pajisje të veçante të grid. Gjate përdorimit të një grid, punët që kërkojnë ketë software, dërgohen në ato nyje të grid në të cilat ky software është i instaluar. Kur pagesat e licencimit të software janë të larta, kjo qasje mund të jetë shume e preferueshme për të ulur shpenzimet e organizatës. Disa licenca ose marrëveshje për software lejojnë instalimin në të gjitha nyjet e grid por mund të kufizojnë numrin e nyjeve që mund të përdorin programin njëkohësisht në të njëjtën kohe. Një program menaxhimi licence kontrollon numrin e kopjeve të njëkohshme të software të përdorura në një kohe të caktuar. Skeduluesit të grid mund të marrin në konsiderate edhe ketë kufizim që i imponon licenca, kështu pra duke bere balancimin, policimin dhe prioritet edhe në varësi të liçencës se programit.
22
2.1.5 Pajisje, kapacitete, arkitektura dhe policime të veçanta Platformat në grid janë zakonisht të arkitekturave, sistemeve të shfrytëzimit dhe pajisjeve të ndryshme. Secila prej këtyre veçorive shfaqet si një burim i ndryshëm që grid mund të përdorë për skeduluar pune në këto nyje. Ndërsa disa programe janë të disponueshëm në disa arkitektura si p.sh. PowerPC dhe x86, shumica e tyre janë dizenjuar vetëm për një tip hardware ose sistemi shfrytëzimi. Këto atribute duhen të merren në konsiderate gjate caktimit të punëve tek burimet e grid. Në disa raste, administratori i grid mund të krijoje disa burime artificiale të cilat mund të përdoren nga skeduluesi për caktimin e punëve në varësi të rregullave të policimit ose kushteve të tjera. P.sh. disa nyje mund të projektohen që të përdoren vetëm për kërkime mjekësore. Këto nyje mund të identifikohen nëpërmjet atributit të kërkimeve mjekësore. Pra këto nyje identifikohen me atributin kërkim mjekësor dhe në ketë mënyre skeduluesi mund të konfigurohet që të caktoje punë që kërkojnë që nyjet të kenë burime për kërkime mjekësore. Gjithashtu edhe nyje me atribute të tjera mund të përfshihen në grid, përveç atyre për qëllime ushtarake. Në rastet kur disa pune kërkojnë burime ushtarake nyjeve me ketë atribut nuk do t’i caktohen pune. Natyrisht administratori do të duhet të vendose disa rregulla klasifikimi për punët gjë që mund të arrihet nëpërmjet një procedure certifikimi.
2.2 Aplikimet dhe punët Edhe pse një shumëllojshmëri burimesh mund të ndahen dhe përdoren në grid, ato zakonisht aksesohen nëpërmjet të ekzekutimit të aplikimit apo punëve. Zakonisht termi aplikim përdoret për njësinë me të larte të punës në grid, sidoqoftë disa here edhe termi pune përdoret si ekuivalent. Aplikimet mund të ndahen në një numër punësh si në figurën e mëposhtme. Këto pune nga ana e tyre mund të ndahen në disa nenpune. Në industrinë e grid terma të tjerë si transaksion ose njësi pune nënkuptohen me termin pune. Punët janë programe që ekzekutohen në një pike të caktuar të grid. Ato mund të llogarisin diçka, ekzekutojnë disa komanda sistemi, zhvendosin ose mbledhin të dhëna ose komandojnë makineri. Një aplikim i dizenjuar për grid organizohet në një koleksion punësh të cilat zakonisht ekzekutohen paralelisht në nyje të ndryshme të grid.
23
Figura 2-2 Një aplikim që ndahet në disa pune që skedulohen për tu ekzekutuar në grid
Punët mund të kenë ndërvarësi specifike gjë që nuk mundëson gjithmonë ekzekutimin në paralel të tyre. P.sh. disa pune mund të kërkojnë në hyrje disa të dhëna specifike për ekzekutimin e tyre. Disa pune mund të kërkojnë në hyrje të dhëna të cilat janë rezultat (dalje) e disa punëve të tjera. Disa pune mund të ndahen në disa nënpunë, në varësi të të dhënave që do të procesohen. Kjo mënyre ekzekutimi krijon një hierarki punësh dhe nënpunësh. Si përfundim, rezultati i të gjitha punëve duhet të mblidhet dhe duhet bashkuar në një mënyre të përshtatshme për të prodhuar rezultatin përfundimtar të aplikimit.
2.3 Skedulimi, rezervimi dhe pasiviteti Sistemi i grid është përgjegjës për dërgimin e punëve drejt një nyjeje të caktuar për ekzekutim. Në sistemet grid me të thjeshte, një përdorues mund të zgjedhe manualisht një nyje të përshtatshme për punën e tij dhe me pas të ekzekutoje një komande në grid për dërgimin e punës drejt nyjes se zgjedhur. Sistemet grid me të avancuar përbehen nga një 24
skeduluesi punësh i cili automatikisht gjen nyjen me të përshtatshme për të ekzekutuar
një pune të caktuar. Skeduluesi reagon ndaj disponueshmërisë disponueshmëris ë aktuale të burimeve të grid. Termi skedulim nuk duhet të ngatërrohet me termin rezervim paraprak të burimeve për të përmirësuar cilësinë e shërbimit. Në një sistem grid që merr në konsiderate pasivitetin, pasivitetin, çdo nyje e cila mbas mbarimit të punës behet inaktive, ketë status të vetin nyja e raporton drejt nyjes menaxhuese. Kjo nyje menaxhuese mund t’i caktoje një pune kësaj nyje pasive n.q.s. përmbush kërkesat
për burime të punës se radhës. Pasiviteti zakonisht implementohet në mënyre të tille që të mos pengoje punën normale të një përdoruesi në nyjen e tij. Nëse nyja edhe njëherë ngarkohet nga përdoruesi, puna e grid zakonisht ndërpritet ose shtyhet për me vone. Kjo situate shkakton pa parashikime të kohës se përfundimit të punës, megjithëse nuk pengon nyjet të cilat vullnetarisht japin burimet e tyre në grid. Aplikimet grid të cilat ekzekutohen me mënyrën pasive zakonisht i vendosin shërbimeve të tyre prioritetin me të ulet në sistemin e shfrytëzimit. Në ketë mënyre, këto pune ekzekutohen vetëm asnjë pune tjetër nuk ngarkohet në sistemin e nyjes. Si pasoje e performancës se procesorëve të sotshëm dhe algoritmeve të skedulimit të sistemeve të shfrytëzimit, aplikimi i grid në një nyje mund të ekzekutohet për pak milisekonda ose ndermet shtypjes se dy butonave në tastiere. Për arritjen e një sjelljeje me të parashikueshme, nyjet në grid janë të dedikuara vetëm për punët e grid. Kjo i mundëson skeduluesit që me afërsi të llogarisë kohen e përfundimit të një grupi punësh, kur dihen karakteristikat e tyre të ekzekutimit. Për një përmirësim të mëtejshëm, burimet e grid mund të rezervohen paraprakisht për një grup punësh të paracaktuara. Këto rezervime veprojnë në mënyre të tille si një axhende për rezervimin e dhomave të konferencave për takimet. Kjo behet për të arritur afatet dhe për të garantuar cilësinë e shërbimit. Kur policimi e lejon, burimet e rezervuara paraprakisht mund të përdorin pasivitetin për të ekzekutuar pune me prioritet të ulet, kur nyjet nuk janë të ngarkuara gjate kohës se rezervimit. Pra kombinime të ndryshme të të skedulimit, rezervimit dhe pasivitetit mund të përdoren për një përdorim me të madh të grid. Skedulimi dhe rezervimi është mjaft i drejtpërdrejt kur merret parasysh vetëm një burim, zakonisht CPU. Sidoqoftë, optimizim me i madh mund të arrihet duke marre në konsiderate me shume burime në procesin e skedulimit dhe rezervimit. P.sh. në rastin kur kërkohet t’i caktohen pune nyjeve që ndodhen me afër të dhënave të
cilat do të përdoren për këto pune. Kjo do të reduktonte trafikun në rrjet dhe në shume raste edhe të reduktoje kufizimet në shkallëzueshmëri të grid. Skedulimi optimal duke marre parasysh disa burime është një problem i vështire matematik. Kështu që, këto lloj skeduluesish përdorin disa rregulla të dizenjuara për të rritur probabilitetin e gjetjes se kombinimit me të mire të skedulimit të punëve, rezervimit të burimeve, optimizimit të throughput dhe metrikave të tjera. 25
2.4 Përbërësit e programit të grid Shume aspekte të llogaritjeve në grid kontrollohen nëpërmjet software. Këto funksione mund të arrihen me ane të një numri të madh procedurash manuale ose të mundësohen automatikisht nëpërmjet një software të sofistikuar. Programi që kryen këto funksione gjithashtu varion në kapacitet dhe disponueshmëri. Me kalimin e kohës software me të sofistikuar do të jene të disponueshem, por në shume sisteme grid të mëparshëm, me suport të një numri të kufizuar burimesh, ishte e arsyeshme që jo të gjithë proceset të implementohen me program. Sidoqoftë mëposhtë do të përshkruajmë çfarë duhet të merret në konsiderate gjate projektimit dhe implementimit të një sistemi grid
2.4.1 Përbërësit e menaxhimit Çdo sistem grid ka disa përbërës menaxhues. E para, është një përbërëse që mban shënim burimet e disponueshme të grid dhe cilat nyje janë anëtare të grid. Ky informacion përdoret kryesisht gjate vendimeve të caktimit të punëve në grid. E dyta, janë disa përbërëse matjeje që përcaktojnë, kapacitetin e nyjes në grid dhe herët e përdorimin të tyre aktual në çdo kohe. Ky informacion përdoret gjate skedulimit të punëve. Ky informacion gjithashtu përdoret për të përcaktuar ―shëndetin‖ e grid, për të lajmëruar administratoret për probleme si p.sh. ndërprerjet, kongjestion (grumbullimet) ose angazhimet e tepërta. Ky informacion gjithashtu përdoret për të përcaktuar modelet dhe statistikat e përdorimit të përgjithshëm të grid, njëherazi mund të përdoren për raportime ose përllogaritje të përdorimit të burimeve të grid. E treta, software të avancuar menaxhimi mund të menaxhojne shumë aspekte të grid. Kjo njihet me emrin llogaritje autonome ose llogaritje të orientuar drejt rikuperimit. Ky lloj programi mund të rikuperoje në mënyre automatike grid ndaj disa dështimeve apo ndërprerjeve, duke gjetur mënyra alternative që ―ngarkesa‖ të përpunohet.
2.4.2 Menaxhimi i një grid të shpërndarë Grid me shume nyje mund të kenë hierarki ose ndonjë tjetër organizim topologjie por zakonisht nënkuptohet që kemi të bëjmë me rastin e topologjisë se rrjetit të lidhur. Pra kur nyjet janë lokalist të lidhura nëpërmjet një LAN thuhet se formojnë një grupim (cluster ). ). Grid mund të organizohet në hierarki që konsiston në cluster të cluster. Menaxhimi i një grid me shume nyje behet i shpërndarë në mënyre që të rritet shkallëzueshmëria e tij. Mbledhja e informacionit, veprimet në grid, të dhënat e burimeve dhe skedulimi i punëve behet në mënyrë të shpërndarë në mënyrë që t’i përafrohet sa me
shume topologjisë fizike të grid. P.sh. një skedulues qendror punësh nuk i dërgon punët
26
drejtpërdrejt tek nyja ekzekutuese, por puna dërgohet drejt një skeduluesi të një rendi me të ulet dhe ky i fundit e dërgon punën në nyjen ekzekutuese. Në mënyrë të ngjashme, mbledhja e informacionit statistik behet në mënyrë të shpërndarë. Një nyje menaxhuese e cluster mbledh informacion rreth aktivitetit të nyjeve anëtare dhe e dërgon atë drejt një nyje menaxhuese të një rendi me të larte në hierarki
2.5 Intragrid and intergrid Siç është përmendur tashmë, përkufizimi i një rrjeti është disi subjektiv. Prandaj, përshkrimet e mëposhtme të llojeve të ndryshme të rrjeteve duhet të merren me afërsi. Rrjetet mund të ndërtohet te të gjitha madhësive, duke filluar nga vetëm disa makina në një departament deri te grupet e organizuara të makinave si një hierarki që përfshin botën. Në këtë seksion, ne përshkruajmë disa shembuj në këtë varg të topologjive të sistemit të rrjetit .
Figure 2-3 Një grid i thjeshtë
27
Siç është paraqitur në figurën 2-3, rrjeti i thjeshtë përbëhet prej vetëm disa makinave, të gjitha të arkitekturës se njëjtë hardware dhe të sistemit operativ të njëjtë, të lidhura në një rrjet lokal. Ky lloj rrjeti përdor sistemet homogjene kështu që nuk janë pak konsiderata dhe mund të përdoret për aplikime të specializuara. Makinat janë zakonisht në një departament të një organizate, si dhe përdorimin e tyre si një rrjet mund të mos kërkoje ndonjë politike të veçante apo shqetësime të sigurisë. Sepse makinat kanë arkitekturë dhe sistem operativ te njëjte , te zgjedhësh software të aplikacionit për këto makina është zakonisht e thjeshtë. Disa njerëz do ta quanin këtë , implementimin e një cluster ne vend te fjalës rrjet. Progresi i ardhshëm do të jetë për të përfshirë makinat heterogjene. Në këtë konfigurim, më shumë lloje të burimeve janë në dispozicion. Sistemi i rrjetit ka gjasa të përfshijë disa komponentë skedulimi. ―File sharing ‖ ende mund të realizohet duke përdorur file sistemet e rrjetit. Makinat që marrin pjesë në rrjet mund të përfshijnë sisteme nga departamente te shumta, por brenda të njëjtën organizatë. Një rrjet I tille është referuar edhe si një intragrid. Si rrjeti të zgjerohet në shumë departamente, mund të jenë te nevojshme politika për mënyrën se si rrjeti duhet të përdoret. Për shembull, mund të ketë politika për çfarë lloj pune është e lejuar në rrjet dhe në çfarë kohesh. Mund të jetë një prioritizim nga departamenti ose nga llojet e kërkesave që duhet të kenë akses në burimet e rrjetit. Gjithashtu, siguria bëhet më e rëndësishme sa më shumë organizata janë të përfshira Të dhënat e ndjeshme në një departament mund të kenë nevojë për t'u mbrojtur nga aksesi nga punët që konkurrojnë për departamentet e tjera. Makinat e dedikuara te rrjetit mund të shtohen për të rritur cilësinë e shërbimit për informatizimin e rrjetit, në vend se te varen tërësisht në burimet pasive. Rrjeti mund të rritet gjeografikisht në një organizatë që ka objekte në qytete të ndryshme. Lidhjet Komunikimet e dedikuar 'mund të përdoren në mesin e këtyre objekteve dhe rrjetit. Në disa raste, lidhjet VPN apo teknologjitë e tjera mund të përdoren në internet për të lidhur pjesë të ndryshme të organizatës. Siguria rritet në rëndësinë herë kufijve të çdo objekti të caktuar janë përshkuar. Rrjeti mund të rritet për të organizuar hierarkike për të reduktuar grindjen nënkuptohet nga kontrolli qendror, duke rritur shkallëzueshmërine. Me kalimin e kohës, siç ilustrohet në figurën 3-4 në faqen 32, një rrjet mund të rritet për të kaluar kufijtë organizatë, dhe mund të përdoret për të bashkëpunuar në projekte me interes të përbashkët. Kjo është e njohur si një intergrid. Nivelet më të larta të sigurisë janë zakonisht zakonisht kërkohet në këtë konfiguracion. konfiguracion. Intragrid Intragrid ofron perspektivën perspektivën për tregti ose burimeve ndërmjetësuese për një audiencë më të gjerë. Burimet mund të blihen si një dobi nga furnizuesit besuar.
28
Figure 2-4 Një intergrid kompleks
2.6 Përmbledhje Ky kapitull ka dhënë një pasqyrë të disa kushteve kryesore dhe konceptet që lidhen me informatizimin e rrjetit. Ky informacion mund të ndihmojë që ju të lexoni këtë diplomë apo literaturë tjetër për informatizimin informatiz imin e rrjetit.
29
3. Projektimi i arkitekturës grid Ky kapitull ofron konsideratat arkitektonike te projektimit për informatizimin e rrjetit. Tema të tjera të projektimit që do të diskutohen janë topologjitë e ndryshme te rrjetit , infrastruktura dizenjative e rrjetit, dhe modelet e arkitekturës se rrjetit. Në një shikim, temat e mëposhtme janë diskutuar: ● Koncepte të projektimit të arkitekturës se rrjetit ● Topologjitë e ndryshme te rrjetit ● Modelet e arkitekturës se rrjetit ● Ndërtimi i një arkitekture të rrjetit ● Modeli konceptual i arkitekturës se rrjetit
3.1 Ndërtimi i një arkitekture rrjeti Themeli i zgjidhjes se një dizenjoje të rrjetit është ndërtuar në mënyrë tipike me një investim infrastrukture ekzistuese. Megjithatë, një zgjidhje të rrjetit nuk ka ardhur për tu realizuar nga thjesht instalimi i software për shpërndarjen e burimeve në kërkesë. Duke pasur parasysh se zgjidhjet të rrjetit janë të adaptueshëm për të plotësuar nevojat e problemeve të ndryshme të biznesit, llojet e ndryshme të rrjeteve janë të dizajnuara për të përmbushur kërkesat specifike të përdorimit dhe kufizimet. Përveç kësaj, topologjive ndryshme janë të dizajnuara për të përmbushur kufizimet e ndryshme gjeografike dhe kërkesat lidhjes të rrjetit. Suksesi i një zgjidhje të rrjetit është i varur nga sasia e te menduarit qe arkitekti IT përdor në hartimin e zgjidhjes. Pasi kërkesat funksionale dhe jo-funksionale janë të njohura, arkitekti arkitekti duhet të jetë në gjendje të gatshme për të zgjedhur llojin e të rrjetit dhe topologjinë me te mire të nevojshme për të kënaqur shumicën e kërkesave të biznesit. Kur të armatosur me këtë informacion, të nivelit të lartë të projektimit të rrjetit do të jetë më e lehtë për të përfunduar, dhe nga përmirësimi i përdorimit të llojeve të rrjetit të njohur dhe topologjive të tyre, artikulimi i zgjidhjes së projektimit do të kërkojë shumë më pak përpjekje. Është e rëndësishme që të përqendrohet në fillimin e vogël dhe për të filluar ndërtimin e kornizës themelore të projektimit. projektimit . Në vend që te përcaktohen, për të ndërtuar fundin e dëshiruar të gjithin përnjëherë, e konsiderojnë ndërtimin e rrjetit zgjidhje në faza. Moment historik për fazën fillestare është që të ofrojë një zgjidhje intragrid, e cila është në thelb një ―sandbox ‖ e rrjetit që mbështet një grup bazë të shërbimeve të rrjetit. Kjo zgjidhje do të mbështesë një lokacion të vetëm të ndërtuar mbi komponentët e rrjetit kryesor, të tilla si një model të sigurisë, shërbimet e informacionit, menaxhimin e 30
ngarkesës, dhe pajisje pritëse. Për aq kohë sa ky model mbështet protokollet dhe standardet e njëjta, ky dizajn mund të zgjerohet sipas nevojës. Hapi i parë i procesit të projektimit është për të ndërtuar një përfaqësim grafik te komponentëve te rrjetit. Fazat pasuese të projektimit do të fokusohet në nivelin e ardhshëm të arkitekturës. Kjo fazë e projektimit është një pikë fillimi për arkitektët, menaxherët dhe drejtuesit teknike, për të kuptuar strukturën e përgjithshme të arkitekturës. Në një shikim, projektimi i arkitekturës se rrjetit duhet të ofrojë si më poshtë: ● "Propozimi" për projektin e detajuar konceptual ● Përdorimi i standardeve të hapura te parapara pa rapara nga kuadri rrjetit
multi-dimensionale nale e niveleve niveleve dhe shtresave shtresave te infrastrukturës infrastrukturës të rrjetit, rrjetit, i cili ● Një pamje multi-dimensio tregon aftësinë për të ndare logjikisht burimet e rrjetit në mënyrë që konsumi i shërbimit te tyre nuk ndikojnë vende të tjera te rrjetit ● Komponentët middleware dhe nënsisteme për një integrim të infrastrukturës të rrjetit ● Një dizajn për komunikim të personelit të biznesit dhe teknikes, për buxhetin dhe për p ër qëllime të planifikimit, dhe për të siguruar zhvillimin e aplikimit një ilustrim se si infrastruktura e përbashkët do të ndikojë rrjetit ne zgjidhjen middleware të projektimit ● Shpërndarja e aplikacioneve dhe nënsistemeve ● Një mjet për identifikimin e komponentëve te nevojshme teknike, infrastrukturore, dhe të tjera Middleware dhe nënsistemeve për një infrastrukturë të rrjetit
3.1.1 Objektivat e zgjidhjes Objektivat e projektimit sigurojnë një kornizë themelore për ndërtimin e infrastrukturës së rrjetit. Përparësia e përdorimit të objektivave te zgjidhjes së projektimit është për të filluar dokumentimin ne zona të caktuara që mund të ndikojnë në dizajnin e përgjithshëm. Brenda dizajnit tuaj, ju do të duhet të siguroheni që rrjeti mund të sigurojë një sasi të caktuar të sigurisë, disponueshmërinë dhe të performancës. Duke dokumentuar këto objektiva të ndryshme ose kërkesa, ajo do të bëjë dizajnin tuaj një shumë më e lehtë për t'u ndjekur. Ju gjithashtu do të jetë në gjendje për të justifikuar disa nga vendimet tuaja gjatë rrjedhës së projektimit duke qenë në gjendje të kthehen në objektiva të caktuara dhe duke u siguruar në plotësimin e tyre.
31
Pasi objektivat e projektimit janë përcaktuar, ju mund ti ndani ato në nënsisteme individuale. Kjo i lejon çdo objektivi dizenjimi të punoje në paralel, ndërsa në të njëjtën kohë duke siguruar një unitet për arkitekturën e përgjithshme. Pasi të keni dokumentuar nënsistemet kryesore të projektimit, ju mund të përqendroheni në kërkesat e ndryshme se dizajni juaj do të përbëjnë rrjetin. Kur ju filloni ndërtimin copa fillestare të dizajnit tuaj, ju duhet të bëni të sigurt që objektivat objektivat tuaja zgjidhje vijë me kërkesat kërkesat e konsumatorit. Për një dizajn të rrjetit, kjo është veçanërisht e rëndësishme, pasi ka jo vetëm komponentët standarde të infrastrukturës që marrin në konsideratë, por middleware te specializuar si dhe integrimin e aplikimit, duke u siguruar që objektivat tuaja te zgjidhjes të kënaqin kërkesat do t’u lejojnë për të hartuar një rrjet pune.
3.1.2 Siguria Brenda çfarëdo mjedisi të rrjetit, nuk do të jetë një rrezik dhe ekspozimi i përfshirë me sigurimin e infrastrukturës tuaj. Përveç nëse kompjuterët janë te palidhur në një dhomë të mbyllur, nuk është e mundshme që dikush mund të anashkalojë sigurinë për të marrë akses në burime të mbrojtura. Nëse janë shfrytëzuar dobësitë në infrastrukturë, aplikimi, konfigurimi, ose administratën, ka pak nivel rreziku. Objektivat e sigurisë janë vënë në vend për të ndihmuar e për të zvogëluar rrezikun në një nivel të pranueshëm. Ndërkohë që asnjë projektim nuk është 100 për qind i sigurt, niveli i rrezikut është reduktuar dhe kontrollohet nëpërmjet përdorimit të kontrolleve të sigurisë. Qëllimi i objektivave të sigurisë janë të shqyrtojë kërkesat e sigurisë dhe të zbatojnë mjetet e nevojshme dhe proceset për të reduktuar rrezikun e përfshirë. Shkalla e sigurisë se përfshire, është e bazuar në llojin e topologjisë se rrjetit dhe të dhënat e sigurisë do të mbrojnë. Kërkesat e sigurisë për një dizajn të rrjetit brenda një bankë do të jetë krejtësisht ndryshe nga ato të një institucioni akademik qe bën hulumtime. Sido qe te jete kërkesat e sigurisë mund të jenë, objektivat e projektimit të sigurisë për projektimin e rrjetit duhet të jenë një fokus qendror për arkitekturën e konceptuale. Duke pasur parasysh se modeli themelor i sigurisë se rrjetit është i bazuar në PKI, është e domosdoshme që komponentët e sigurisë te jenë të dizajnuara dhe të menduar me kujdes. Ndërsa PKI ka qenë rreth e rrotull për një kohë, janë komponentë të ndryshme dhe proceset e nevojshme që duhet të identifikohen. Nxitimi i këtij procesi mund të çojë në shumë probleme në të ardhmen. Me arkitekturë PKI te qenit fokusi i projektimit fillestar, ka ende zona që kanë nevojë për vëmendje. Komponentët e infrastrukturës (firewallet, IDS, anti-virus, dhe enkriptimi) dhe proceset për të menaxhuar këto pjesë janë të gjitha pjesë e objektivave të sigurisë. Duke e ditur se cilat fusha përputhen me mjedisin tuaj ekzistues është hapi i parë për pasur sigurinë të fuqishme. Pikat e mëposhtme janë një shembull i disa pyetjeve të sigurisë që duan përgjigjet gjatë rrjedhës së projektimit. Tre te parat supozojnë se ndërmarrja do të sigurojë vetë certifikatën e autoritetit te saj , e cila nuk është e rekomanduar zakonisht: 32
● Ku do të të vendosen CA e mia dhe se si do ta menaxhojë atë? ● A kam proceset e nevojshme në mënyrë për të administruar CA tim? ● Cilat janë përgjegjësitë për menaxhimin CA tim? ● Si do ta administrojë sigurinë në serverat lokale? serverat e mia të ndërtuar ndërtuar në uniforme apo apo mjedisin e përbashk përbashkët ët operativ? operativ? ● A janë serverat ● A kam unë një software të qëndrueshëm ndërtuar në të gjithë rrjetet kritike të
infrastrukturës se sistemit ? ● Cilat janë proceset në ekzekutim në serverat e mi? ● Do krijoje ndonjë nga aplikimet ekzistues konflikt ose te ekspozojnë rrjetit tim për ndonjë dobësi?
3.1.3 Disponueshmëria Disponueshmëria në termat e saj më të thjeshtë zakonisht i referohet përqindjes së kohës që një vend është dhe kërkesat e punës për shërbim. Përcaktimi se sa disponueshmëri duhet të ndërtohen në dizajn është pjesë e objektivave te disponibilitetit. Kjo çon poshtë rrugën për të zbuluar se sa shumë pika të mundshme të vetme të dështimit të ekzistojnë dhe sa tepricë duhet të jetë ndërtuar në dizajn. Është e pashmangshme që disa komponentë do të dështojë gjatë jetës së përdorimit, por kjo mund të menaxhohet duke përdorur komponentë të tepërt ku është e mundur. Kurdo që ju të shqyrtoni skenarë të ndryshme në dispozicion, nuk janë gjithmonë diskutime rreth shumës së disponueshmërisë që është e nevojshme. Në këtë drejtim, një dizajn rrjeti nuk është i ndryshëm nga çdo infrastrukturë tjetër. Një fillim i mirë është në listën e komponentëve të mundshme në kuadër të projektimit që duhet të jetë elastik ndaj dështimit. Pasi këto komponentë janë identifikuar, ju mund të kërkoni nga opsionet specifike disponibilitetin për ato komponentë. Në shembujt e mëposhtëm, janë përshkruar disa opsione të ndryshme infrastrukturore. Një pikë e rëndësishme që duhet të diskutohet është disponueshmëria e burimeve dinamike brenda një mjedis të rrjetit. Rrjeti nuk është si një mjedis standart ku burimet janë të fiksuara dhe nuk ndryshojnë ndryshojnë rregullisht. rregullisht. Brenda rrjetit mjediset, burimet janë vazhdimisht në ndryshim në përputhje me anëtarësimin dhe pjesëmarrjen në rrjet. Kur burimet e rrjetit janë aktive, ato mund të regjistrohen me shërbimet informative në kuadër të rrjetit për të njoftuar sistemin e shtetit të tyre. Është e rëndësishme për t'u siguruar se kur ju dizenjoni rrjetin tuaj, duhet ta mbani këtë në mend. Përveç komponentëve të rrjetit middleware, komponentët e ndryshme të infrastrukturës do të kërkojnë gjithashtu nivele të ndryshme të disponueshmërisë. Disa komponentë do të jetë më kritik se të tjerët, dhe kjo kjo do të jetë deri në hartimin tuaj për të bërë bërë të sigurt që ju llogarisni për këtë. Kur shkojnë përmes kërkesave për disponueshmëri te ndryshme, sigurohuni që ju të llogarisni për te dy, rrjetin dhe komponentëve të infrastrukturës. Listat e mëposhtme janë disa shembuj të burimeve te disponibilitetit që duhet të llogariten për: 33
● Rrjetit Middleware ○ Menaxhimi i ngarkesës ○ Direktoria e rrjetit dhe shërbimi i indeksimit ○ Shërbimet e sigurisë ○ Ruajtja e të dhënave ○ ―Clustering ‖ të softuer te rrjetit ● Rjetet ○ Balancimi i ngarkesave ○ Protokollet e rutimit me disponueshmëri të lartë ○ Rrugët e tepërta dhe të ndryshme të rrjetit ● Siguria ○ Firewallet e tepërta ● Sistemet e të dhënave ○ Mirroring ○ Replikimi i të dhënave ○ Përpunimet paralele ● Sistemet e Menaxhimit ○ Backup dhe rekuperim ○ Kopje LDAP ○ Sinjalizimi dhe monitorimi për të sinjalizuar një dështim brenda mjedisit
Shumë shpesh, komponentë të ndryshme të nevojshme për procesin e punës dështojnë në mënyrë periodike dhe prishin disponueshmërinë e sistemit. Ju mund të ndihmoni të zbusni rrezikun e përfshirë duke eliminuar pikat e vetme të dështimit në mjedisin tuaj nëpërmjet përdorimit të softuer të tepërta ose të komponentëve hardware. Për t’u dhënë një ide më të mirë të disa objektivave të disponueshmërive të ndryshme, lista e mëposhtme paraqet një shembull të disponueshmërisë së sistemit në një vit të tërë: ● Disponueshmëria Normale tregtare (nyje e vetme): 99-99,5 për qind, 87,6-43,8 orë e
sistemit poshtë ● Disponueshmëria e Lartë: 99,9 për qind, 8 ,8 orë e sistemit poshtë ● Elastik ndaj dështimeve: 99,99 për qind, 53 minuta e sistemit poshtë ● Tolerant ndaj dështimeve: 99,999 për qind, 5 minuta e sistemit poshtë ● Procesim i vazhdueshëm: 100 për pë r qind, 0 minuta e sistemit poshtë
Mbani në mend, megjithëse, se teprica që është shtuar në infrastrukturën e rrjetit normalisht do të rrisë kostot e infrastrukturës brenda, kjo është në varësi të biznesit për të ndihmuar të justifikojë shpenzimet që do të sjellë një ambient prej 99,9 për qind në dispozicion për një vit deri në 99,99 për qind në vit. Ndërsa dallimi në kohën mes këtyre 34
dy numrave është rreth tetë orë, shpenzimet që lidhen mund të jetë shumë për të justifikuar justifikuar rritjen në dispozicion.
3.1.4 Performanca Objektivi performancës për një mjedis të rrjetit është më efikas të shfrytëzojë burime të ndryshme brenda rrjetit. Nëse kjo përfshin cikle CPU rezervë, akses në bazat e të dhënave të federuar, ose përpunimin e aplikimit, varet nga ju të përputhen qëllimet e performancës të biznesit dhe dizenjimit ne përputhje me rrethanat. Nëse kërkesa juaj mund të përfitojnë nga burime të shumta, ju mund te dizenjoni rrjetin tuaj të jetë i prishur deri në instancat më të vogla dhe te ketë punën e shpërndarë në të gjithë rrjetin. Qëllimi është që të përfitojmë rrjetin si një të tërë, në mënyrë për të rritur performancën e aplikimit. Nëpërmjet menaxhimit inteligjent të ngarkesës së punës dhe caktimin, kërkesa juaj mund të përfitojë nga çdo gjë që burimet brenda rrjetit kanë në dispozicion. Pjesë e performancës është e bazuar në formën e menaxhimit të ngarkesës së punës për të siguruar që të gjitha burimet brenda rrjetit te jenë punë aktive apo kërkesa brenda rrjetit.
3.2 Modelet e arkitekturës grid Ka lloje të ndryshme të arkitekturave të rrjetit që i përshtaten llojeve të ndryshme të problemeve të biznesit. Disa rrjete janë të dizejnuara për të përfituar nga burimet e shtesë të proçesimit, ndërsa disa arkitektura të tjera të rrjetit janë të dizajnuara për të mbështetur bashkëpunimin midis organizatave të ndryshme. Lloji i rrjetit të përzgjedhur është i bazuar kryesisht në problemin e biznesit që është duke u zgjidhur. Duke marrë në konsideratë qëllimet e biznesit do të ju ndihmojë të zgjidhni llojin e duhur të strukturës së rrjetit. Një biznes që dëshiron të aksesojë në burime të pashfrytëzuara për llogaritjen e analizës së riskut brenda qendrës së të dhënave të korporatës do të ketë një dizajn shumë të ndryshme se sa një kompani që dëshiron të hapë rrjetin e tyre të shpërndarjes për të krijuar një bazë të dhënash të konsoliduar me një ose dy nga furnizuesit e tyre kryesorë. Lloje të tilla të ndryshme të aplikacioneve të rrjetit do të kërkojë dizajne të ndryshme, bazuar në kërkesat e tyre përkatësisht unike. Zgjedhja e një lloji të veçantë të rrjetit do të ketë një ndikim të drejtpërdrejtë në hartimin e rrjetit. Përveç kësaj, ajo që duhet të përmendet është se teknologjitë e rrjetit janë ende në zhvillim dhe modifikime taktike në një arkitekturë të rrjetit mund të jetë e nevojshme për të kënaqur një kërkesë të veçantë të biznesit.
3.2.1 Grid llogaritës 35
Një rrjet kompjuterikë grumbullon fuqinë e përpunimit nga një sasi e shpërndarë e sistemeve. Një shembull i njohur i një rrjet kompjuterike është rrjeti SETI@home. Ky lloj i rrjetit është i përbërë kryesisht nga kompjuter me fuqi të ulet dhe me logjikën minimale të aplikimeve si dhe kapacitet ruajtje minimale. Në vend të pikturave të thjeshta të imazheve të rrjedhjeve se informacioneve në rrjeta, ciklet e papunë të kompjuterëve personal në rrjetin SETI@home janë të kombinuara për të krijuar një rrjet kompjuterike të përdorur për të analizuar transmetimet radio marra nga hapësira kozmike në kërkimin për Inteligjencën Jashtë Tokësore. Shumica e bizneseve të interesuar në rrjetet kompjuterike do të ketë të ngjarë të kenë iniciativa të ngjashme IT. Ndërsa ata ndoshta nuk do të duan të kërkojnë për jashtëtokësorët, jashtëtokësorët, por do të jetë një nismë e biznesit për të zgjeruar aftësitë dhe maksimizuar përdorimin e kompjuterit dhe burimeve ekzistuese përmes bashkimit dhe ndarjes. Biznesi mund të kërkojë më shumë kapacitet kompjuterik se sa është në dispozicion. Biznesi është e interesuar në modifikimin e aplikacioneve të veçanta për mundësitë e informatizimit paralel. Përdorimet shtesë për një rrjet kompjuterike përfshijnë ekuacionet matematikore, derivatet, çmimi, vlerësimin e portofolit dhe imitimi (matja sidomos rreziku). Vini re se jo të gjitha algoritmet algoritmet janë në gjendje gjendje të bëjnë proçesime proçesime paralele, paralele, të dhënat intensive intensive dhe llogaritje me rezultate të larta, renditje dhe përpunimin e transaksioneve,shpërndarjen e informacioneve të tregut dhe rrezikun e ndërmarrjeve të menaxhimit. Në shumë raste, arkitekturat e rrjetit nuk janë (ende) të përshtatshme për aplikimet në kohë reale. Rrjetet kompjuterike mund të njihet nga këto karakteristika kryesore: ● Bërë nga grupe grupimesh ● Mundëson CPU që të shfrytëzoj më mire burimet ● Siguron fuqinë kompjuterike për procesin në shkallë të gjerë punë ● përmbush kërkesat e biznesit për qasje të menjëhershme në burimet në bazë të kërkesën
Përfitimet kryesore të rrjeteve kompjuterike janë një kosto të reduktuar totale e pronësisë (TCO) dhe me ciklet shpërndarje të shkurtër. Përveç SETI@home, Komuniteti Botërore Grid ™, Distributed Terascale Facility (TeraGrid), dhe rrjetet e Bri tanisë së Madhe dhe Holandës janë të gjitha shembuj të ndryshme të rrjeteve kompjuterike. Gjenerata e ardhshme të rrjetit informatikë kompjuterike do të përqendrohet drejt zgjidhjes në kohë reale të problemeve kompjuterike.
3.2.2 Grid të dhënash
36
Ndërsa rrjetet kompjuterike janë më të përshtatshme për të grumbulluar burimet, rrjetet e të dhënave fokusohen në sigurimin e aksesit të sigurt në shpërndarje, lidhjet heterogjene të të dhënave. Nëpërmjet bashkëpunimit, rrjetet e të dhënave gjithashtu mund të përfshijë burime të tilla si një bazë të dhënash e federuar. Brenda një bazë të dhënash të federuar, siç ilustrohet në figurën 8-1 në faqen 103, një rrjet i të dhënave e bën një grup i bazave të të dhënave në dispozicion që funksionojnë si një bazë të dhënash e vetme virtuale. Nëpërmjet kësaj ndërfaqe të vetme, baza e të thënave e federuar siguron një pikë të vetme raporti, modelimin e të dhënave dhe qëndrueshmërinë e të dhënave. Rrjetet e të dhënave gjithashtu shfrytëzojnë të dhënat, magazinimin dhe burimet e rrjetit të vendosura në fusha të ndryshme administrative, të respektojnë politikat lokale dhe globale duke vendosur se si të dhënat mund të përdoren, të skedulojnë në mënyrë efikase burimet (përsëri subjekt i kufizimeve lokale dhe globale) dhe të ofrojnë shpejtësi të lartë dhe qasje të besueshëm për të dhënat. Bizneset e interesuar në rrjetet e të dhënave në mënyrë tipike kanë nisma nga IT për të zgjeruar aftësitë e nxjerrjes së të dhënave dhe nga ana tjetër maksimizimin e përdorimit të infrastrukturës ekzistuese të ruajtjes dhe për të reduktuar kompleksitetin kompleksiteti n e menaxhimit të të dhënave.
Figure 3-1 Arkitekturë e unifikuar DBMS
3.3 Topologjitë grid Një pikëpamje e topologji (shih Figurën 8-2 në faqen 104), mbulon spektrin e mëposhtme të rrjetit: ● Intragrids ○ Një organizëm 37
○ Pa partner të integruar ○ Një grup i vetme ● Extragrids ○ organizma të shumëfishtë ○ Partner të integruar ○ grupime të shumëfishta ● Intergrids
o Shumë organizma Partner të shumëfishtë o Shumë grupimeve të mëdha
Figure 3-2 Intragrids, extragrids dhe intergrids
Më e thjeshta e tre topologjive është intragrid, e cila është e përbërë thjesht nga një grup bazik i shërbimeve Grid brenda një organizimit të vetëm. Kompleksiteti i projektimit të rrjetit është në proporcion me numrin e organizmave që rrjeti është projektuar për të mbështetur, parametrave gjeografikë dhe kufizimeve. Sa më shumë organizma ti bashkohen rrjetit, kërkesat jo-funksionale apo operative për sigurinë, shërbimet në direktori, disponueshmëria dhe performancë e bëjnë atë më komplekse. Ndarjen e burimeve tërthore nuk është shkëmbimin parësor i të dhënave, por as qasja e drejtpërdrejtë në kompjuter, software, të dhënat dhe burimeve të tjera, siç është kërkuar 38
nga një varg i strategjive për bashkëpunimin për zgjidhjen e problemeve dhe të burimeve të ndërmjetësimin në shkencë, industri dhe inxhinieri. Kjo ndarja është e domosdoshme, e mirë mbrojtur, me ofruesit e burimeve dhe konsumatorët që përcaktojnë në mënyrë të qartë dhe me kujdes vetëm atë që është e përbashkët, që është e lejuar për të ndarë si dhe kushtet nën të cilat ndodh ndarja.
3.3.1 Intragrid Një topologji tipik intragrid, siç ilustrohet në figurën 8-3 në faqen 105, ekziston brenda një organizmi të vetëm duke siguruar një grup bazë të shërbimeve të rrjetit. Organizma të vetëm mund të jenë të përbërë nga një numër kompjuterësh që ndajnë një zone të përbashkët të sigurisë dhe që shkëmbejnë të dhëna brenda në një rrjet privat. Karakteristikat kryesore të një intragrid janë; një ofrues i vetëm i sigurisë, bandwidth-i në rrjetin privat është i lartë, gjithmonë në dispozicion dhe ka një ambient të vetëm brenda një rrjet të vetëm. Me një intragrid është më e lehtë për të hartuar dhe për të operuar rrjetet kompjuterike dhe të dhënat. Një intragrid ofron një sërë burimeve të informatizimit relativisht statike dhe aftësinë për të ndarë lehtë të dhënave në mes të sistemeve të rrjetit. Biznesi mund të gjykojmë një intragrid të përshtatshme nëse biznesi ka një iniciativë për të fituar shkallës e ekonomisë në menaxhimin e punëve të brendshme ose dëshiron të fillojë të eksplorojë përdorimin e një rrjeti të brendshëm së pari duke mundësuar aplikimet vertikale.
Figura 3-3 Një intragrid 39
3.3.2 Extragrid Bazuar në një organizëm të vetme extragrid zgjerohet në koncept duke sjellë së bashku dy ose më shumë intragrid. Një extragrid, siç ilustrohet në figurën 8-4 në faqen 106, zakonisht përfshin më shumë se një ofrues të sigurisë, si dhe rritjen e nivelit të kompleksitetit të menaxhimit. Karakteristikat kryesore të një extragrid janë të shpërndajë sigurinë, organizma të shumta dhe lidhje WAN. Brenda një extragrid, burimet bëhen më dinamike dhe rrjeti juaj ka nevojë të jetë më reagues të burimeve të dështuara dhe komponentëve të dështuar. Dizajni bëhet më i komplikuar dhe shërbimet e informacionit bëhet relevante për të siguruar që burimet e rrjetit të kenë qasje në menaxhimin e ngarkesës së punës në kohën punës. Një biznes do të përfitojnë nga një extragrid nëse ka pasur një iniciativë që të integrohen me partnerët e jashtëm të besueshëm e biznesit. Një extragrid gjithashtu mund të përdoret në një kapacitet B2B ose për të krijuar marrëdhënie të besueshme.
Figura 3-4 Extragrids mund të ekzistojnë në disa organizata dhe ofrues të sigurisë
40
3.3.3 Intergrid Një intergrid kërkon integrimin dinamik të aplikimeve, burimeve dhe shërbimeve të modeluara, konsumatorëve dhe çdo organizmi tjetër të autorizuar që do të marrin qasje në rrjetin përmes internetit ose WAN-it. Një topologji intergrid, siç ilustrohet në figurën 8-5 në faqen 107, është përdorur kryesisht nga firmat inxhinierike, industritë e shkencave mbi jetën, prodhuesit, prodhuesit, dhe nga bizneset bizneset në industritë industritë financiare. financiare. Karakteristikat Karakteristikat kryesore kryesore të një intergrid përfshijnë sigurinë e shpërndarë, organizma të shumëfishtë dhe lidhje WAN. Të dhënat në një intergrid janë të dhëna globale dhe publike si dhe aplikacionet (të dy vertikale dhe horizontale) duhet të modifikohet për një audiencë globale. Një biznes mund të gjykojë të nevojshme një intergrid nëse ka nevojë për procesim për-to-për, një komunitet bashkëpunues procesimi apo për të thjeshtuar proceset fundore me organizmat që do të përdorin intergrid.
Figure 3-5 Intergrid
3.3.4 e-Utilitetet (e-Utilities) 41
Një lloj tjetër i rrjetit që duhet diskutuar para mbylljes së këtij seksioni është ajo që ne do ta quajmë procesimet e-utility. Në vend që të blejmë dhe të mirëmbajmë hardware dhe software më të fundit dhe më të mirë, me këtë lloje rrjeti konsumatorët do të kenë fleksibilitetin e aksesimit në fuqinë e procesimit dhe programimit si mbas nevojës ashtu si ata aksesojnë karburantin ose energjisë elektrike. Por ndërmarrjet po vijnë gjithnjë e më shumë për të parë prirjen e e-utility si një vazhdueshmëri për të arritur përtej burimeve të zakonshme të IT në kërkesën për dorëzimin e procesimit të biznesit dhe funksioneve të menaxhimit në mënyrë integrale siç punon organizata. Modeli i biznesit e-utility është i bazuar në ofrimin komponentët funksionalë të IT që janë (kryesisht) (kryesisht) të standardizuara standardizuara dhe të dorëzuara përmes një modeli ofrimit të shërbimit. Atributet e këtij modeli përfshijnë një mjedis të shpërndarë dhe në përgjithësi të standardizuara dhe me proceset e biznesit jo-thelbësore. E-utility është përdorur nga ana e konsumatorëve të shërbimeve si zgjidhje thelbësore për zhvillimin ne tërësi të ebiznesit. Karakteristikat më të mëdha të mjediseve së e-burimeve janë zgjidhjet standarde që kërkon konfigurimin minimale; burimet e përdorura për të shërbyer klientëve të shumtë, kapaciteti mbi kërkesën, shkallëzueshmëria, 24x7, gjithmonë në disponueshmëri të lartë, me shpejtësi të lartë dërgimi, operacione minimale; sistemet e menaxhimit të shpërndara si dhe çmime dhe faturime fleksibël bazuar në të dyja përdorimet aktuale ose konsumuese të burimeve, ose një abonim të sheshtë të llogaritur.
42
4. Hadoop i Apache dhe Ekosistemi Hadoop Megjithëse Hadoop është njohur me mirë për Reduktimin e Hartës (MapReduce) dhe për skedarët e sistemit (filesystem) të tij të shpërndarë (HDFS, e riemërtuar nga NDFS), termi është përdorur gjithashtu për një familje të projekteve të lidhura që bien nën suportin e infrastrukturës infrastruktur ës për kompjuterizimin kompjuterizi min e shpërndarë dhe procesimin në shkallë të lartë të të dhënave. Shumica e projekteve bazë të mbuluara në këtë libër janë drejtuar nga Fondacioni i Programit Apache, i cili siguron mbështetje për një komunitet të projekteve të programeve të lirë për të gjithë, duke përfshirë HTTP Server origjinal nga i cili ai merr dhe emrin e tij. Ndërsa ekosistemi Hadoop rritet, më shumë projekte janë duke u shfaqur, jo domosdoshmërisht domosdoshmërisht të drejtuar nga Apache, i cili siguron shërbimet plotësuese plotësuese për Hadoop, ose të ndërtuara në bërthamen për të shtuar abstraksione të nivelit të lartë. Teknologjitë Hadoop që janë mbuluar në këtë diplomë janë përshkruar shkurtimisht më poshtë: 1) Bërthama (Common) Një bashkësi komponentesh dhe ndërfaqesh për filesystem-et të shpërndarë dhe I/O e përgjithshme (serializimet (serialization), Java RPC, strukturat e përhershme të të dhënave). 2) Reduktimi i Hartës (MapReduce) Një model i shpërndarë procesimi të dhënash dhe mjedisi ekzekutimi që vepron në grupe (cluster) të mëdhenj të makinave të thjeshta. 3) HDFS 43
Një filesystem I shpërndarë që vepron në clusters të mëdhenj të makinave të thjeshta.
4.1 MapReduce MapReduce është një model programimi për procesimin e të dhënave. Modeli është I thjeshtë, akoma jo shumë I thjeshtë për të shprehur programe të dobishme në të. Hadopp mund të ekzekutoj programet MapReduce të shkruara në gjuhë të ndryshme; në këtë kapitull, ne do të shikojmë programin e shprehur në Java, Ruby, Python, dhe C++. Më e rëndësishmja, programet janë në thelb paralele, duke mundësuar kështu analizë të dhënash në shkallë shumë të madhe në duart e kujtdo me makina të mjaftueshme në dispozicionin e tyre. MapReduce perfomon mirë për procesim të madh të tërësisë së të dhënave, le të shikojmë njërën.
4.1.1 Java MapReduce e re API Publikimi 0.20.0 e Hadoop përfshin një Java MapReduce e re API, ndonjëherë i referua si ―Context Objects‖, i dizenjuar për të bërë API më të thjeshtë për të zhvilluar në të
ardhmen. API e re është tip- i papajtueshëm me të vjetrin, mirëpo, kështu aplikacionet kanë nevojë të rishkruhen për të përfituar nga ai. Ka disa ndryshime të dukshme midis dy API-ve: -
API e re favorizon klasat abstrakte kundrejt ndërfaqeve, meqënëse këto janë më të thjeshta për t’u zhvilluar. Për shembull, ju mund të shtoni një metodë ( me një
implementim të paracaktuar) në një klasë abstrakte pa prishur implementimet e vjetra të klasës. Në API-në e re ndërfaqet Mapper dhe Reducer janë tashmë klasat abstrakte. -
API e re është në paketën org.apache.hadoop.mapreduce (dhe nënpaketat). API e vjetër mund të gjendet akoma në org.apache.hadoop.mapred.
-
API e re bën përdorim të gjerë të objekteve kontekts që lejojnë kodin e përdoruesit të komunikojë me sistemin MapReduce. MapContext, për shembull, unifikon në thelb rolin e JobConf, OutputCollector, dhe Reporter.
-
API e re suporton të dyja stilet ―push‖ dhe ―pull‖ për përsëritjen. Në të dyja API-
të çiftet e rregjistruar celës-vlerë janë shtyrë në mapper, por veç kësaj, API e re lejon një mapper të tërheq rregjistrimet nga Brenda metodës map(). E njëjta ndodh për reducer. Një shembull se si stili ―pull‖ mund të jetë i dobishëm është
procesimi i rregjistrimeve në grumbuj, në vend të një nga një. 44
-
Konfigurimi është unifikuar. API e vjetër ka një object special JobConf për konfigurimin e punës, e cila është një zgjerim i objektit te Konfigurimit vanilla të Hadoop. Në API e re, ky ndryshim nuk merret parasysh, kështu puna e konfigurimit bëhet nëpërmjet një Konfigurimi.
-
Kontrolli I punës performohet nëpërmjet klasa Job, në vend të JobClient, e cila tashmë nuk egziston në API e re.
-
File-t e daljes janë emërtuar pak më ndryshe: part-m-nnnnn part-m-nnnnn për daljet map, dhe part-r-nnnnn part-r-nnnnn për daljet reduce (ku nnnnn është një numër I plotë që përcakton numrin e pjesës, që fillon nga zero).
4.2 Rrjedhja e të dhënave Së pari, përmendim disa terminologji. Një punë MapReduce është një njësi pune që klienti dëshiron të jetë kryer: ajo konsiston në të dhënat hyrëse, programin MapReduce, dhe informacionin e konfigurimit. Hadoop e kryen punën duke e ndarë në tasks (detyra), të cilat janë të dy tipeve map tasks dhe reduce tasks . Ka dy tipe nyjesh që kontrollojnë procesin e ekzekutimit të punës: një jobtracker jobtracker (ndjekës pune) dhe një numër të tasktrackers (ndjekësit e detyrës). Jobtracker koordinon të gjitha punët që ekzekutohen në system duke skeduluar detyrat që do të ekzekutohen në tasktrackers. Tasktracker ekzekuton detyrat dhe dërgon raportet e progresit tek jobtracker, I cili mban një rregjistrim (record) për të gjithë progresin të secilës punë. Në qoftë se një detyre dështon, jobtracker mund ta riskedulojë atë në një tasktracker tjetër. Hadoop ndan hyrjen në një punë MapReduce në pjesë me madhësi fikse të quajtuar input splits, ose thjesht splits . Hadoop krijon një detyrë harte ( map task) për cdo split, e cila ekzekuton fuksionin map të përcaktuar nga përdoruesi për cdo rregjistrim (record) në split. Të pasurit shumë split-e nënkupton se koha që harxhohet për të përpunuar çdo split është e vogël krahasuar me kohën për të përpunuar të gjithë hyrjen. Kështu në qoftë se në jemi duke përpunuar split-et në parallel, përpunimi është më mirë I balancuar-në ngarkesë në qofte se split-et janë të vegjel, derisa një makinë më e shpejtë do të jetë e aftë për të përpunuar proporcionalisht më shumë split-e gjatë serisë së punës se sa një makinë e ngadaltë. Edhe në qoftë se makinat janë identike, përpunimet e dështuara ose punët e tjera 45
që ekzekutohen njëkohësisht e bëjnë balancimin në ngarkesë të dëshirueshme, dhe kualiteti i balancimit të ngarkesës rritet kur split-et bëhen më të vegjël. Nga ana tjetër, në qoftë se split-et janë shumë të vogla, atëherë overhead-i i menaxhimit të split-eve dhe të krijimit të map task fillon të dominojë kohën totale të ekzekutimit të punës. Për shumicën e punëve, një madhësi e mirë split ka tendencë të jetë madhësia e blokut HDFS, zakonisht 64MB, megjithëse kjo mund të ndryshohet për cluster-in ( për të gjithë file-et më të reja të krijuar), ose specifikuar kur çdo file është krijuar. Hadoop bën më të mirën e tij për të ekzekutuar map task në një nyje ku të dhënat hyrëse qëndrojnë në HDFS. Kjo quhet optimizimi i vendndodhjes së të dhënave (data locality optimization). Tashmë është e qartë pse madhësia optimale split është e njëjtë si madhësia e bllokut: ajo është madhësia më e madhe e hyrjes që mund të sigurohet për t’u
ruajtur në një nyje të vetme. Në qoftë se split shtrihet në dy blloqe, do të ishte e padëshiruar që çdo nyje HDFS të ruaj të dyja blloqet, kështu një pjesë nga split duhet të transferohet nëpërmjet rrjetit tek nyja që po ekzekuton map task, e cila është qartësisht më pak eficiente se sa ekzekutimi i të gjithë map task duke përdorur të dhënat lokale. Map task-et shkruajnë daljet e tyre në diskun lokal, jo tek HDFS. Pse është kështu? Dalja map është dalje e ndërmjetjme: ajo përpunohet nga reduktimi i task-eve për të prodhuar daljen përfundimtare, dhe kur puna është përfunduar dalja map mund të hiqet. Kështu ruajtja e saj në HDFS, me përsëritje, do të ishte mbivrasje. Në qoftë se nyja që po ekzekuton map task dështon përpara së dalja map është konsumuar nga reduce task, atëherë Hadoop do të riekzekutojë automatikisht map task në një nyje tjetër për të rikrijuar daljen map. Reduce task-et nuk kanë avantazhin e vendndodhjes së të dhënave- hyrja në një reduce task të vetëm është normalisht dalja nga të gjitha mapper-at. Në shembullin e tanishëm, ne kemi një reduce task të vetëm që është ushqyer nga të gjithë map task-et. Prandaj, daljet e rendituara map duhet të transferohen përmes rrjetit në nyjen ku reduce task është duke u ekzekutuar, ku ata janë bashkuar dhe kaluar në funksionin reduce të përcaktuar nga- përdoruesi. Dalja e reduce është ruajtur normalisht në HDFS për siguri. Për çdo bllok HDFS të daljes reduce, kopja e parë është ruajtur në nyjen lokale, me kopjet e tjera të ruajtura në nyjet off-rack. Kështu, shkrimi i daljes reduce konsumon gjerësibrezi ne rrjet, por vetëm sa një shkrim normal pipeline HDFS konsumon. E gjithë rrjedhja e të dhënave me një reduce task të vetëm është përshkruar ne Figurën 41. Kutijat me pika tregojnë nyjet, shigjetat e ndriçuara tregojnë trensferimin e të dhënave, dhe shigjetat e trasha tregojnë transferimin e të dhënave midis nyjeve.
46
Figura 4-1. Rrjedhja e të dhenave MapReduce me një reduce task të vetëm.
Numri i task-eve reduce nuk është drejtuar nga madhësia e hyrjes, por është specifikuar në mënyrë të pavarur. Kur ka reducer-a të shumtë, map task-et ndajnë daljen e tyre, secila duke krijuar secili një ndarje për çdo reduce task. Ka shumë çelsa (dhe vlerat shoqëruese te tyre) në çdo ndarje, por rregjistrimet për çdo çelës të dhënë janë të gjitha në një ndarje të vetme. Ndashmëria mund të kontrollohet nga një përdorues- duke përcaktuar funksionin e ndashmërisë, por normalisht ndarësi i paracaktuar- i cili mbledh çelsat duke përdorur një funksion hashfunksionon shumë mirë. Kjo diagramë e tregon qartë pse rrjedhja e të dhënave midis map dhe reduce task-eve është e njohur si ―përzierje‖, duke qënë se reduce task është e përbërë nga shumë map task-eve. Përzierja është më e ndërlikuar se sygjerimi i këtij diagram, dhe rregullimi i tij mund të ketë një ndikim të madh në kohën e ekzekutimit të punës.
47
Figura 4-2. Rrjedhja e të dhënave MapReduce me reduce task të shumtë
Së fundmi, është gjithashtu e mundur për të pasur reduce task-e zero. Kjo mund të jetë e përshtatshme kur ju nuk ju nevojitet të përzieni derisa procesimi mund të kryhet i gjithi në parallel. Në këtë rast, e vetmja transferim të dhëne off-node është kur map task-et shkruajnë në HDFS (shiko Figura 4-3).
4.2.1 Fuksionet kombinuese Shumë detyra MapReduce janë limituar nga gjerësia e brezit e disponueshme në cluster, kështu ai paguan për të minimizuar transferimin e të dhënave midis map dhe reduce taskeve. Hadoop lejon përdoruesin të specifikojë një funksion kombinues që të ekzekutohet në daljen map- dalja e fuksionit kombinues formon hyrjen në funksionin reduce. Përderisa funksioni kombinues është një optimizim, Hadoop nuk siguron një garanci për sa herë ai do e thërrasë atë për një rregjistrim dalje map të veçantë, por mund edhe te mos e therrase fare. Me fjalë të tjera, thërritja e funksionit kombinues zero, një ose shumë herë do të prodhojë të njëjtën dalje nga reducer-i.
48
Figura 4-3. Rrjedhja e të dhënave MapReduce me asnje reduce task
Kontrata për funksionin kombinues kufizon tipin e fuksionit që mund të përdoret. Kjo është ilustruar më së miri me një shembull. Supozojmë që për shembullin e temperaturës maksimale, të lexuara për vitin 1950 janë procesuar nga dy map-e (sepse ato ishin në split-e të ndryshëm). Imagjinoni që map-i i parë prodhon daljen: (1950,0) (1950,20) (1950,10) Dhe i dyti prodhon: (1950,25) (1950,15) Funksioni reduce do të thërritet me një list të të gjithë vlerave: (1950, [0, 20, 10, 25, 15]) me dalje: (1950,25)
49
derisa 25 është vlera maksimale në list. Ne mund të përdorim një funksion kombinues që, ashtu si funksioni reduce, gjen temperaturen maksimale për çdo dalje map. Reduce mund të thërritet pastaj me: (1950, [20,25]) dhe reduce do të prodhojë të njëjtën dalje si përpara. Më shkurtimisht, ne mund ta shprehim funksionin që thërret vlerat e temperaturës në këtë rast si mëposhtë: max(0, 20, 10, 25, 15)=max(max(0, 20, 10), max(25,15))=max(20, 25)=25 Jo të gjitha funksionet zotërojnë këtë tipar. Për shembull, në qoftë se ne llogarisim temperaturat mesatare, më pas ne nuk mund të përdorim mesataren si funksionin tonë kombinues, përderisa: mean(0, 20, 10, 25, 15)=14 por: mean(mean(0, 20, 10), mean(25, 15))=mean(10, 20)=15 funksioni kombinues nuk zëvendëson funksionin reduce. (Si mund ta bëj ai? Funksioni reduce nevojitet akoma për të procesuar record-et me çelës të njëjtë nga map-et e ndryshme.) Por ky mund të ndihmoj të shkurtojë sasinë e të dhënave të përziera midis map-eve dhe reduce-eve, dhe për këtë arsye të vetme është gjithmonë më mirë të konsiderojnë nëse ju mund të përdorni një funksion kombinues në punën tuaj MapReduce.
4.3 File sistemet e shpërndarë Hadoop Kur një dataset rritet më shpejt se kapaciteti i ruajtjes të një makine të vetme fizike, bëhet e nevojshme të të ndajnë atë përmes një numri të makinave të ndara. Filesystem-et që menaxhojnë ruajtjen përmes një rrjeti makinash janë quajtur filestystem-et e shpërndara. Derisa ata janë bazuar ne rrjet, të gjitha ndërlikimet e programimit në rrjet merren parasysh, duke i bërë filesystem-et e shpërndara më komplekse se sa filesystem-et e rregullta disk. Për shembull, një nga sfidat më të mëdha është ta bësh filesystem-in të tolerojë dështimin e nyjes pa lejuar humbjen e të dhënave. Hadoop vjen më një filesystem të shpërndarë të quajtur HDFS, e cila përfaqësohet nga Hadoop Distributed Filesystem. ( Ju mund ta shihni ndonjëherë të referuar si ―DFS‖ jozyrtarisht jozyrtarisht ose në dokumentimet dokumentimet ose konfigurimet konfigurimet e vjetra- e cila është e njëjta gjë.) HDFS është filesystem flagship i Hadoop-it dhe është fokusi I këtij kapitulli, por Hadoop aktualisht ka një abstraksion filesystem me qëllim të përgjithshëm, kështu ne do ta 50
shohim gjatë rrugës se si Hadoop integrohet me sistemet ruajtëse të tjera (siç është local filesystem dhe AmazonS3).
4.3.1 Konstruksioni i HDFS HDFS është një filesystem i dizenjuar për ruajtjen e file-eve shumë të mëdha me modelet e aksesimit të vargjeve të të dhënave, që veprojnë në cluster-at me hardware të thjeshtë. Le ta ekzaminojmë këtë gjendje në më shumë detaje:
File-at shumë të mëdha ―Shumë të mëdha‖ në këtë konteks nënkupton file-at që janë qindra megabytes,
gigabytes, ose terabytes në madhësi. Ka cluster-a Hadoop që veprojnë sot që mund të ruajnë të dhëna në disa petabytes
Aksesimi i vargjeve të të dhënave HDFS është ndërtuar përgjatë një ideje që modeli më efiçent i procesimit të të dhënave është një model shkrim-një herë, lexim-shumë- herë. Një dataset është gjeneruar ose kopjuar zakonisht nga burimi, më pas analiza të ndryshme janë kryer në atë dataset çdo herë. Çdo analizë do të përfshijë një proporcion të madh, ose jo, të datset, kështu koha për të lexuar të gjithë dataset-in është më e rëndësishme se sa vonesa në leximin e record-it të parë.
Hardware të thjeshtë Hadoop nuk kërkon hard ware shumë të shtrenjtë, me besueshmëri të lartë për të vepruar. Ai është dizenjuar për të vepruar në cluster-at me hardware të thjeshtë (zakonisht hardware-et e disponueshme mundësohen nga shitës të shumtë) për të cilën mundësia për dështim të nyjes nëpër cluster është e lartë, më e pakta për cluster-at e mëdhenj. HDFS është dizenjuar të vazhdojë funksionimin pa një ndërprerje njoftuese për përdoruesin pa marrë parasysh disa dështime. Është gjithashtu më mirë të ekzaminohen aplikacionet për të cilat përdorimi i HDFS nuk funksionon dhe aq mirë. Ndërkohë që kjo mund të ndryshojë në të ardhmen, këto janë zonat ku HDFS nuk është një përshtatje e mirë sot:
Akses të dhënash me vonesë të ulët Aplikacionet që kërkojnë akses me vonesë të ulët të të dhënave, në të dhjetën e milisekondit, nuk do të punojnë mirë me HDFS. Kujto, HDFS është e optimizuar për dërgimin e një throughput të lartë të dhënash, dhe kjo mund të jetë në kurriz të vonesës.
Shumë file-a të vegjel 51
Përderisa namenode mban filesystem metadata në memorje, limiti i numrit të file-eve në një filesystem është drejtuar nga sasia e memories në namenode. Si një rregull i pranuar, çdo file, direktori, dhe bllok merr rreth 150 bytes. Kështu, për shembull, në qoftë se ju keni një million file, secila zë një bllok, ju ju duhet më e pakta 300 MB të memories. Ndërsa ruajtja e milionave file-eve është e realizueshme, billiona file janë përtej kapacitetit të hardware-it actual.
Shkruesit e shumtë, modifikimet e paarsyeshme të file-it File-et në HDFS mund të shkruhen nga një shkrues i vetëm. Shkrimet janë bërë zakonisht në fund të file-it. Nuk ka mbështetje për shkruesit e shumtë, ose për modifikimet në offset-et arbritare në file. (Kjo mund të mbështetet në të ardhme, por ka të ngjarë që mund të jenë përkatësisht jo eficiente).
4.3.2 Konceptet HDFS Blloqet Një disk ka një madhësi blloku, e cila është sasia minimale e të dhënave që aim und të lexojë ose shkruaj. Filesystem-et për një disk të vetëm organizojnë të dhënat në blloqe, të cilat janë një shumfish integral të madhësisë së bllokut të diskut. Blloqet e filesystem-eve janë zakonisht zakonisht pak kilobytes kilobytes në madhësi, ndërsa blloqet e diskut janë normalisht normalisht 512 bytes. Kjo është zakonisht është transparente kundrejt përdoruesit të filesystem-it i cili është thjesht duke shkruar ose lexuar një file- me çfarëdo gjatësie. Megjithatë ka mjete për të kryer mirëmbajtjen e filesystem-it, si df dhe fsck , që vepron në nivelin e bllokut filesystem. HDFS, gjithashtu, ka konceptin e një blloku, por është një njësi pak më e madhe- 64MB të paracaktuar. Si në një filesystem për një disk të vetë, file-et në HDFS janë ndarë në pjesë me madhësi blloku, të cilat janë ruajtur si njësi të pavaruara. Ndyshe nga një filesystem për një disk të vetëm, një file në HDFS që është më e vogël se sa një bllok i vetëm nuk zë një bllok të tërë me vlerë të storage (depozitë të dhënash) themelor. Kur nuk përcaktohet, termi ―bllok‖ në këtë libër i referohet një blloku në HDFS. Pse është një Bllok në HDFS kaq I madh? Blloqet HDFS janë më të mëdhenj krahasuar me blloqet e disk-ut, dhe arsyeja është për të minimizuar koston e kërkimeve. Duke bërë një bllok mjaftueshëm të madh, koha për të transferuar të dhënat nga disk-u mund të bëhet në mënyrë të konsiderueshme më e madhe se sa koha për të kërkuar për të nisur me bllokun. Kështu koha për të transferuar një file të madh të përbërë nga blloqe të shumtë vepron në shpejtësinë e transferimit të disk-ut. Një llogaritje e shpejtë tregon që në qoftë se koha e kërkimit është përafërsisht 10 ms, dhe shpejtësia e transferimit është 100 MB/s, më pas për të bërë kohën e kërkimit 1% të 52
kohës së transferimit, ne na nevojitet të bëjmë madhësinë e bllokut rreth 100 MB. E paracaktuar është aktualisht 64 MB, megjithëse shumë instalime HDFS përdorin blloqe 128 MB. Kjo figurë do të vazhdojë të korrigjohet më lart ndërsa shpejtësia e transferimit rritet me gjeneratat e reja të disk drives. Megjithatë, ky argument nuk duhet të merret shumë larg. Detyra Map në MapReduce normalisht vepron në një bllok në një kohë, kështu në qoftë se ju keni pak detyra (më pak se nyjet në cluster), punët e juaja do të ekzekutohen më ngadalë se sa në rastin e kundërt. Duke pasur një abstraksion blloku për një filesystem të shpërndarë sjell disa të mira. E mira e parë është më e dukshme: një file mund të jetë më e madhe se sa çdo disk i vetëm në rrjet. Nuk ka asgjë që kërkon që blloqet nga një file të ruhen në të njëjtin disk, kështu ato mund të përfitojnë nga çdo disk në cluster. Në fakt, mund të jetë e mundur, në qoftë se është e pazakontë, për të ruajtur një file të vetëm në një cluster HDFS blloqet e të cilit plotësojnë të gjithë disk-qet në cluster. Së dyti, të bësh njësinë e abstraksionit një bllok në vend të një file thjeshton hapsirën ruajtëse në nënsistem. Thjeshtësia është diçka për t’u përpjekur për të gjithë në të gjithë
sistemet, por është veçanërisht e rëndësishme për një sistem të shpërndarë në të cilën mënyrat e dështimit janë të variushme. Nënsistemet ruajtëse ndahet në blloqe, duke thjeshtuar menaxhimin e vendit ruajtës (derisa blloqet janë me madhësi fikse, është e thjeshtë të llogaritet se sa shumë mund të ruhen në një disk të dhënë) dhe duke eleminuar problemet metadata (blloqet janë thjesht një copëz e të dhënave që do ruhen- file metadata si informacioni i të drejtave nuk nevojiten të ruhen me blloqe, kështu një sistem tjetër mund të mbajë metadata të ndara). Gjithashtu, blloqet përshtaten mirë me replikimin për të siguruar tolerancën e gabimit dhe disponueshmërinë. Për të marrë masa kundrejt blloqeve të korruptuar dhe dështimit të disk-ut dhe makinës, çdo bllok është replikuar me një numër të vogël të makinave fizik të ndarë (zakonisht tre). Në qoftë se një bllok bëhet i disponueshëm, një kopje mund të lexohet nga një vendndodhje tjetër në një mënyrë që është transparente tek klienti. Një bllok që nuk është më i disponueshëm për shkak të korruptimit ose dështimit të makinës mund të replikohet nga vendndodhjet e tij alternative në makinat e tjera aktive për të çuar faktorin e replikimit në nivelin normal. Ngjashmërisht, disa aplikacione mund të zgjedhin të vendosin një faktor të lartë replikimi për blloqet në një file të përhapur për të përhapur ngarkesën e leximit në cluster. Si ―kushuriri‖ i tij disk filesystem, komanda fsck e HDFS kupton blloqet. Për shembull, duke ekzekutuar: %hadoop fsck /-files – blocks blocks do të listojë blloqet që përmbajnë çdo file në filesystem.
Namenodes dhe Datanodes
53
Një cluster HDFS ka dy tipe nyjesh që veprojnë në një model master-ëorker: një namenode (the master) dhe një numër të datanodes (ëorkers). Namenode menaxhon emrin e hapsirës së filesystem-it. Ai përmban pemën e filesystem-it dhe metadata për të gjithë file-et dhe direktoritë në pemë. Ky informacion është ruajtur vazhdimisht në diskun local në formën e dy file-ave: imazhi i emrit të hapsirës dhe editimi i log-eve. Namenode gjithashtu njeh nyjet e të dhënave në të cilin çdo bllok për një file të dhënë janë vendosur, vendosur, megjithëse, megjithëse, ai nuk e ruan vendndodhjet e bllokut vazhdimisht, derisa ky informacion është rikonstruktuar nga nyjet e të dhënaven kur sistemi fillon. Një klient akseson filesystem në interest të user-it nga komunikimi me namenode dhe datanodes. Klienti paraqet një POSIX- si ndërfaqje filesystem-I, kështu kodi i user-it nuk ka nevojë të dijë rreth namenode dhe datanode për të funksionuar. Nyjet e të dhënave janë mbajtëse të filesystem-it. Ato ruajnë dhe rigjejnë blloqet kur ata janë treguar (nga klientët ose namenode), namenode), dhe ato raportojnë raportojnë mbrapsht në namenode periodikisht me listat e blloqeve që ata ruajnë. Pa namenode, filesystem-i nuk mund të përdoret. Në fakt, në qoftë se makina që ekzekuton namenode është fshirë, të gjithë file-et në filesystem do të humbasin derisa nuk ka mënyrë që dihet se si t’i rikonstruktojnë file -et nga blloqet ne nyjet e të dhënave. Për këtë arsye, është e rëndësishme të bëjmë namenode elastik nga dështimet, dhe Hadoop siguron dy mekanizma për këtë. Mënyra e parë është të ruajmë file-at që bëjnë gjendjen të qëndrueshme të metadata të filesystem-it. Hadoop mund të konfigurohet që namenode shkruajnë gjendjen e tij të qëndrueshme në filesystem-et e shumtë. Këto shkrime janë sinkrone dhe atomike. Zgjedhja e konfigurimit të zakonshëm është të shkruajë në disk-un local njësoj si një direktori e montuar NFS. Është gjithashtu e disponueshme për të ekzekutuar një namenode dekondare, e cila pavarësisht nga emir i tij nuk vepron si një namenode. Roli i tij kryesor është të bashkojë periodikisht imazhin namespace me edit log për të parandaluar që edit log të bëhet shumë i madh. Namenode sekondar zakonisht vepron në një makinëfizikisht të ndarë, derisa ajo kërkon shumë CPU dhe aq shumë memoria si namenode për të performuar bashkimin. Ai mban një kopje të imazhit namespace të bashkuar, i cili mund të përdoret në eventin e dështimit të namenode. Gjithsesi, gjendja e namenode-it sekondar mban të gjithë informacionin e paresorit, kështu në rastin e dështimit total të parësorit, humbja e të dhënave është tashmë e sigurt. Orientimi i zakonshëm i veprimit në këtë rast është të kopjojë file-et metadata të namanode-eve që janë në NFS në sekondarin dhe e ekzekuton atë si primarin e ri.
54
5. Pjesa eksperimentale eksperimentale 5.1 Ambjenti i testimit Ambjenti i testimit konsiston ne 4 nyje (kompjuterë ne ketë rast) me 1 GB RAM, 20 GB memorie dhe nje procesor secili, qe bëjnë 4 njësi llogaritëse. Numërimi i njësive llogaritëse është i rëndësishëm per te përcaktuar maksimumin e punëve reduce ne çdo nyje.
Figura 5-1 Cluster i eksperimentit
5.1.1 Problemi Testet qe do te zhvillojmë do te konsistojnë ne zgjidhjen e problemit te quajtur ―Numërimi i funksioneve monotone Boolean-e‖ (i njohur edhe si Problemi i Dedekind). Me shume informacion per këtë problem gjendet ne faqen http://www.mathpages.com/home/kmath030.htm . Pse zgjedhja e nje problemi kaq abstrakt:
Kërkon fuqi te larte përpunuese nga ana e CPU (nje CPU- je te vetme do t’i duhej afërsisht 800 ore per numërimin e funksioneve monotone boolean-e per N=8)
55
Ne këtë eksperiment nuk do te gjendet zgjidhja, por do te zgjidhim vetëm nje pjese te tij qe nuk merr me shume se tre ore Mund te ndahet thjeshtë ne një numër te pacaktuar nënpunësh Nënpunët e gjenruara kane nevoja te ndryshme përpunimi (kjo është e volitshme per te pare performancën e balancuesit te ngarkesës)
Me një problem kaq fleksibël, do te vendosim te marrim kushtet e mëposhtme
problemi i llogaritjes ndahet ne 33700 nënpunë problemi i llogaritjes ndahet ne 2705 nënpunë problemi i llogaritjes ndahet ne 341 nënpunë
5.2 Instalimi i Hadoop ne sistemin e shfrytëzimit Ubuntu Për te kryer këtë eksperiment kërkohet : 1) 2) 3) 4) 5) 6) 7)
Instalimi i sistemit të shfrytëzimit Ubuntu 10.04 LTS (ose versioni 8.04) Instalimi i Sun Java 6 Krijimi i nje përdoruesi te dedikuar per Hadoop Konfigurimi Konfigurimi i SSH Instalimi i Hadoop 1.0.3 i lëshuar në Maj 2012 Konfigurimi i Hadoop (single node) Konfigurimi i Hadoop (multi node)
1. Instalimi i Ubuntu mund te behet ne një mjedis virtual si VMware me ane të ―EasyInstall‖
56
Figura 5-2 Instalimi i sistemit të shfrytëzimit Ubuntu
Gjate instalimit të vetmet të dhëna qe duhet të japim janë, emri i përdoruesit dhe fjalëkalimi. Mbas instalimit do te shohim pamjen e mëposhtme te shfaqur ne Figurën 5-3.
57
Figura 5-3 Pamja kryesore mbas hapjes së Ubuntu
2. Instalimi i Sun Java 6 Hadoop ne menyre qe te punojë kërkon Java 1.5.x por rekomandohet përdorimi i Java 1.6.x (gjithashtu e njohur edhe si Java 6) per ekzekutimin e programeve ne Hadoop. Per kryerjen e instalimit hapim Terminalin nepermjet menus Applications->Accessories>Terminal dhe me pas japim komandat per instalim: 1) sudo apt-get install python-software-properties 2) sudo add-apt-repository ppa:ferramroberto/java 3) sudo apt-get update 4) sudo apt-get install sun-java6-jdk 5) sudo update-java-alternatives – s java-6-sun Dy komandat e para sherbejne per instalimin e nje burimi te ri te dhenash (repository) nga i cili do te marrim paketat e instalimit te Java 6.
58
xxx@ubuntu:~$ sudo add-apt-repository ppa:ferramroberto/java Executing: gpg --ignore-time-conflict --no-options --no-default-keyring -secret-keyring /etc/apt/secring.gpg --trustdb-name /etc/apt/trustdb.gpg -keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg -keyserver keyserver.ubuntu.com --recv 3E756CF119B127D4DA40A186B725097B3ACC3965 gpg: requesting key 3ACC3965 from hkp server keyserver.ubuntu.com gpg: key 3ACC3965: public key "Launchpad lffl" imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1)
Dy komandat e dyta sherbejne per instalimin e Java 6 nga repository i shtuar si meposhte
xxx@ubuntu:~$ sudo apt-get install sun-java6-jdk Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: gsfonts-x11 java-common odbcinst odbcinst1debian1 sun-java6-bin sun-java6jre unixodbc Suggested packages: default-jre equivs sun-java6-demo default-jdk-doc sun-java6-source sunjava6-plugin ia32-sun-java6-plugin sun-java6-fonts ttf-kochi-gothic ttf-sazanami-gothic ttf-kochi-mincho ttf-sazanami-mincho ttf-arphic-uming libmyodbc odbc-postgresql tdsodbc unixodbc-bin The following NEW packages will be installed: gsfonts-x11 java-common odbcinst odbcinst1debian1 sun-java6-bin sun-java6jdk sun-java6-jre unixodbc 0 upgraded, 8 newly installed, 0 to remove and 336 not upgraded. Need to get 57.2MB of archives. After this operation, 169MB of additional disk space will be used. Do ou want to continue [Y/n]?
Ne fund mbas instalimit instalimit kontrollojme kontrollojme nqs eshte eshte instaluar instaluar sakte Java 6 me me komanden komanden java version si meposhte
xxx@ubuntu:~$ java -version java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)
3. Krijimi i nje përdoruesi te dedikuar per Hadoop 59
Per krijimin e perdoruesit ne sistemin Ubuntu rekomandohet qe ne fillim te krijohet nje grup perdoruesish dhe me pas ketij grupi t’i shtojme perdoruesin tone.
xxx@ubuntu:~$ sudo addgroup hadoop Adding group `hadoop' (GID 1001) ... Done. xxx@ubuntu:~$ sudo adduser --ingroup hadoop hduser Adding user `hduser' ... Adding new user `hduser' (1001) with group `hadoop' ... Creating home directory `/home/hduser' ... Copying files from `/etc/skel' ... Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully Changing the user information for hduser Enter the new value, or press ENTER for the default Full Name []: Room Number []: Work Phone []: Home Phone []: Other []: Is the information correct? [Y/n] y
4. Konfigurimi Konfigurimi i SSH Hadoop perdor SSH per aksesim gjate menaxhimit te nyjeve anetare te grid. Nqs duam qe edhe nyja kryesore ( namenode ) te perdoret per procesim te dhenash, si cdo datanode , atehere duhet qe te konfigurojme qe hduser te aksesoje me SSH edhe localhost. Instalimi i serverit dhe klientit SSH behet si meposhte.
root@ubuntu:~# sudo apt-get install openssh-client openssh-server Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: libpam-ssh keychain openssh-blacklist openssh-blacklist-extra rssh mollyguard The following NEW packages will be installed: openssh-server The following packages will be upgraded: openssh-client 1 upgraded, 1 newly installed, 0 to remove and 335 not upgraded. Need to get 1,047kB of archives. After this operation, 782kB of additional disk space will be used.
60
Get:1 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main openssh-client 1:5.3p1-3ubuntu7 [762kB] Get:2 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/main openssh-server 1:5.3p1-3ubuntu7 [285kB] Fetched 1,047kB in 9s (114kB/s) Preconfiguring packages ... Preparing to replace openssh-client 1:5.3p1-3ubuntu5 (using .../opensshclient_1%3a5.3p1-3ubuntu7_i386.deb) ... Unpacking replacement openssh-client ... Selecting previously deselected package openssh-server. Unpacking openssh-server (from .../openssh-server_1%3a5.3p13ubuntu7_i386.deb) ... Processing triggers for man-db ... Processing triggers for ureadahead ... ureadahead will be reprofiled on next reboot Processing triggers for ufw ... Setting up openssh-client (1:5.3p1-3ubuntu7) ... Setting up openssh-server (1:5.3p1-3ubuntu7) ... Creating SSH2 RSA key; this may take some time ... Creating SSH2 DSA key; this may take some time ... ssh start/running, process 3763
Rreshti i fundit ―ssh start/running, process 3763‖ tregon qe sherbimi SSH ka filluar dhe
numri 3763 eshte id e procesit. Mbas kryerjes me sukses te instalimit, duhet te bejme konfigurimin per perdoruesin ―hduser‖
xxx@ubuntu:~$ su - hduser Password: hduser@ubuntu:~$ ssh-keygen -t rsa -P "" Generating public/private rsa key pair. Enter file in which to save the key (/home/hduser/.ssh/id_rsa): Created directory '/home/hduser/.ssh'. Your identification has been saved in /home/hduser/.ssh/id_rsa. Your public key has been saved in /home/hduser/.ssh/id_rsa.pub. The key fingerprint is: 4b:b1:8e:16:10:b6:ef:ee:e4:37:80:60:02:f9:00:d9 hduser@ubuntu The key's randomart image is: +--[ RSA 2048]----+ |o+ o | |= E. o | |.o o . | |. + o o | | o . .o S | | ...= . | | =.o | | = o | | .+. . | +-----------------+
61
Mbas logimit si hduser me komanden ―su – hduser‖, – hduser‖, vendosim fjalekalimin (ate qe vendosem gjate hapit te trete). Me pas komanda ―ssh-keygen – t rsa –P ―‖‖ sherben per gjenerimin e nje celesi te tipit RSA me fjalekalim ―‖ bosh. Normalisht aksesimi nga nyja
menaxhuese drejt nyjeve anetare do te behet pa nderhyrjen e nje perdoruesi, keshtu qe duhet te perdoret fjalekalimi bosh. Se dyti,duhet te mundesojme aksesin SSH te localhost me celesin publik te sapokrijuar.
hduser@ubuntu:~$ cat $HOME/.ssh/id_rsa.pub >> $HOME/.ssh/authorized_keys hduser@ubuntu:~$ nano $HOME/.ssh/authorized_keys GNU nano 2.2.2
File: /home/hduser/.ssh/authori zed_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAtLieSZNCdKwWuIzsFjOrilrwW3dfYC+H0OAGifJwLkK/uEx6M wuqNUf63zqYskdjQv2+XP7SJ5xP9w3EX0xR6g7Z$
Hapi perfundimtar eshte qe te aksesojme localhost me ane te SSH nga hduser si meposhte.
hduser@ubuntu:~$ ssh localhost The authenticity of host 'localhost (::1)' can't be established. RSA key fingerprint is 00:c4:46:d0:97:12:ac:55:f0:6a:5b:12:07:b5:90:0f. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'localhost' (RSA) to the list of known hosts. Linux ubuntu 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 21:21:01 UTC 2011 i686 GNU/Linux Ubuntu 10.04.2 LTS...
5. Shkarkimi i Hadoop 1.0.3 i lëshuar në Maj 2012 dhe instalimi i tij Shkarkimi i Hadoop mund te behet direkt nga faqja zyrtare e mundës uar nga ―Apache Foundation‖, http://www.apache.org/dyn/closer.cgi/hadoop/core . Mbas shkarkimit duhet te kemi nje file te tille ―hadoop-1.0.3.tar.gz ‖ . Instalimi kryhet si meposhte.
$ $ $ $
cd /usr/local sudo tar xzf hadoop-1.0.3.tar.gz sudo mv hadoop-1.0.3 hadoop sudo chown -R hduser:hadoop hadoop
62
Si rezult at do te kemi nje direktori me emrin ―hadoop‖ Brenda direktorise /usr/local. Me pas percaktojme variablat e sistemit. Tre jane variblat kryesore ―HADOOP_HOME‖ ―HADOOP_HOME‖ , / .bashrc ―JAVA_HOME‖ dhe ―PATH‖ ne file $HOME .bashrc si meposhte.
export HADOOP_HOME=/usr/local/hadoop export JAVA_HOME=/usr/lib/jvm/java-6-sun export PATH=$PATH:$HADOOP_HOME/bin
6. Konfigurimi i Hadoop (single node) Variabli i vetem qe duhet te konfigurojme ne menyre qe hadoop te punoje eshte ―JAVA_HOME‖, per kete do te modifikojme file hadoop-env.sh.
$ cd /usr/local/hadoop $ nano /conf/hadoop-env.sh
Ne file do te shikojme rreshtat e meposhtem
# The java implementation to use. Required. # export JAVA_HOME=/usr/lib/j2sdk1.5-sun
… dhe do t’i modifikojme si meposhte
# The java implementation to use. Required. export JAVA_HOME=/usr/lib/jvm/java-6-sun
Mbas modifikimit te file hadoop-env.sh jane tre file kryesor te konfigurimit te Hadoop. a) core-site.xml b) mapred-site.xml c) hdfs-site.xml Ne kete paragraph do te konfigurojme direktorine ne te cilen Hadoop do te ruaj te dhenat, portat ne te cilat hadoop do te preset e dhenat etj. Ne kete hap Hadoop do te perdore HDFS vetem ne nje nyje dhe konfigurimi i meposhtem percakton direktorine qe HDFS do te perdore per ruajtjen e te dhenave. 63
$ sudo mkdir -p /app/hadoop/tmp $ sudo chown hduser:hadoop /app/hadoop/tmp
Direktoria e krijuar mesiper duhet te vendoset ne file core-site.xml si meposhte
hadoop.tmp.dir /app/hadoop/tmp A base for other temporary directories. fs.default.name hdfs://localhost:54310 The name of the default file system. A URI whose scheme and authority determine the FileSystem implementation. The uri's scheme determines the config property (fs.SCHEME.impl) naming the FileSystem implementation class. The uri's authority is used to determine the host, port, etc. for a filesystem.
Ndersa file mapred-site.xml duhet te jete si meposhte
mapred.job.tracker localhost:54311 The host and port that the MapReduce job tracker runs at. If "local", then jobs are run in-process as a single map and reduce task.
Se fundi ne konfigurimin e file hdfs-site.xml duhet te kemi
dfs.replication 1 Default block replication. The actual number of replications can be specified when the file is created. The default is used if replication is not specified in create time.
64
Perpara se te nisim te gjitha sherbimet e Hadoop ne nyjen, duhet bere formatimi i HDFS analog me formatimin e cdo file sistemi tjeter perpara perdorimit per here te pare. hduser@ubuntu:/usr/local/hadoop/bin$ hadoop namenode -format 12/09/27 07:53:15 INFO namenode.NameNode: STARTUP_MSG: /************************************************************ STARTUP_MSG: Starting NameNode STARTUP_MSG: host = ubuntu/127.0.1.1 STARTUP_MSG: args = [-format] STARTUP_MSG: version = 1.0.3 STARTUP_MSG: build = https://svn.apache.org/repos/asf/hadoop/common/branches/branch-1.0 -r 1335192; compiled by 'hortonfo' on Tue May 8 20:31:25 UTC 2012 ************************************************************/ 12/09/27 07:53:16 INFO util.GSet: VM type = 32-bit 12/09/27 07:53:16 INFO util.GSet: 2% max memory = 19.33375 MB 12/09/27 07:53:16 INFO util.GSet: capacity = 2^22 = 4194304 entries 12/09/27 07:53:16 INFO util.GSet: recommended=4194304, actual=4194304 12/09/27 07:53:16 INFO namenode.FSNamesystem: fsOwner=hduser 12/09/27 07:53:16 INFO namenode.FSNamesystem: supergroup=supergroup 12/09/27 07:53:16 INFO namenode.FSNamesystem: isPermissionEnabled=true 12/09/27 07:53:16 INFO namenode.FSNamesystem: dfs.block.invalidate.limit=100 12/09/27 07:53:16 INFO namenode.FSNamesystem: isAccessTokenEnabled=false accessKeyUpdateInterval=0 min(s), accessTokenLifetime=0 min(s) 12/09/27 07:53:17 INFO namenode.NameNode: Caching file names occuring more than 10 times 12/09/27 07:53:18 INFO common.Storage: Image file of size 112 saved in 0 seconds. 12/09/27 07:53:18 INFO common.Storage: Storage directory /app/hadoop/tmp/dfs/name has been successfully formatted. 12/09/27 07:53:18 INFO namenode.NameNode: SHUTDOWN_MSG: /************************************************************ SHUTDOWN_MSG: Shutting down NameNode at ubuntu/127.0.1.1 ************************************************************
Me pas hapi i fundit eshte ndezja e sherbimeve te Hadoop ne nyjen tone te vetme. hduser@ubuntu:/usr/local/hadoop/bin$ ./start-all.sh starting namenode, logging to /usr/local/hadoop/libexec/../logs/hadoophduser-namenode-ubuntu.out localhost: starting datanode, logging to /usr/local/hadoop/libexec/../logs/hadoop-hduser-datanode-ubuntu.out localhost: starting secondarynamenode, logging to /usr/local/hadoop/libexec/../logs/hadoop-hduser-secondarynamenode-ubuntu.out starting jobtracker, logging to /usr/local/hadoop/libexec/../logs/hadoophduser-jobtracker-ubuntu.out localhost: starting tasktracker, logging to /usr/lo /usr/local/ cal/hado hadoo o /libexe /libexec/.. c/../lo /lo s/hadoo s/hadoo -hduser -hduser-tas -tasktra ktracker cker-ubu -ubuntu ntu.out .out
65
Ka dy menyra per te pare nese sherbimet jane ndezur ne menyre te sakte. Menyra e pare eshte me jps qe eshte nje miniprogram i java. hduser@ubuntu:/usr/local/hadoop/bin$ jps 6271 JobTracker 5851 NameNode 6201 SecondaryNameNode 6444 TaskTracker 6040 DataNode 6627 Jps
Ndersa menyra tjeter eshte me ane te komandes se Ubuntu netstat si meposhte.
hduser@ubuntu:/usr/local/hadoop/bin$ netstat -plten |grep java (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp 0 0 0.0.0.0:50030 0.0.0.0:* 1001 28138 8077/java tcp 0 0 0.0.0.0:54324 0.0.0.0:* 1001 27699 7998/java tcp 0 0 0.0.0.0:50070 0.0.0.0:* 1001 28264 7683/java tcp 0 0 127.0.0.1:56535 0.0.0.0:* 1001 28178 8247/java tcp 0 0 0.0.0.0:50010 0.0.0.0:* 1001 28451 7830/java tcp 0 0 0.0.0.0:50075 0.0.0.0:* 1001 28460 7830/java tcp 0 0 0.0.0.0:45149 0.0.0.0:* 1001 27707 7683/java tcp 0 0 0.0.0.0:59265 0.0.0.0:* 1001 27703 8077/java tcp 0 0 0.0.0.0:50020 0.0.0.0:* 1001 28472 7830/java tcp 0 0 127.0.0.1:54310 0.0.0.0:* 1001 28248 7683/java tcp 0 0 127.0.0.1:54311 0.0.0.0:* 1001 27965 8077/java tcp 0 0 0.0.0.0:50090 0.0.0.0:* 1001 28455 7998/java tcp 0 0 0.0.0.0:42093 0.0.0.0:* 1001 27950 7830/java
66
LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN
Analoge me komanden e ndezjes se sherbimeve kemi komanden e fikjes se tyre.
hduser@ubuntu:/usr/local/hadoop/bin$ ./stop-all.sh stopping jobtracker localhost: stopping tasktracker stopping namenode localhost: stopping datanode localhost: stopping secondarynamenode
7. Konfigurimi i Hadoop (multi node) Pasi kemi konfiguruar nje nyje, fikim makinen virtuale dhe e klonojme ate. Ne rastin e VMware duhet thjeshte te bejme nje tjeter kopje te direktorise ku ndodhet makina virtuale. Pra do kemi dy nyje te vecanta dhe te konfiguruara si master (dmth dy cluster), duam qe te arrijme te kemi nje cluster me nje nyje master dhe nje nyje slave. Para se te fillojme krijimin e cluster shume nyjesh duhet qe te sigurohemi qe sherbimet e Hadoop jane te fikura se perndryshe bejne konflikt me konfigurimet e reja.
67
Figura 5-4 Krijimi i cluster me shume nyje
Hapi i pare eshte qe te konfigurojme karten e rrjetit. Nenkuptohet qe ted y nyjet duhet te aksesojnë njera-tjetren nepermjet rrejtit, keshtu qe ka shume kuptim qe te jene ne te njejtin LAN te lidhur me nje switch. Gjithashtu edhe IP e tyre duhet te jene ato te LAN te cilat per thjeshtesi do ti percaktojme 192.168.0.1 per masterin dhe 192.168.0.2 per slave, pra jemi ne LAN 192.168.0.x.
xxx@ubuntu:~$ sudo nano /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.0.1 netmask 255.255.255.0
Me pas duhet te rinisim edhe njehere sherbimin e rrjetit ne menyre qe te reflektoje ndryshimet e bera ne konfigurim. Per kete perdorim skriptin networking ne direktorine e skripteve te inicializimit init.d si meposhte.
68
xxx@ubuntu:~$ sudo /etc/init.d/networking restart * Reconfiguring network interfaces... ssh stop/waiting ssh start/running, process 3175 [ OK ]
dhe kontrollojme nese eshte kryer me sukses konfigurimi me komanden ifconfig xxx@ubuntu:~$ ifconfig eth0 Link encap:Ethernet HWaddr 00:0c:29:94:28:61 inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe94:2861/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:166 errors:0 dropped:0 overruns:0 frame:0 TX packets:214 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:27532 (27.5 KB) TX bytes:29692 (29.6 KB) Interrupt:19 Base address:0x2024 lo
Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:70 errors:0 dropped:0 overruns:0 frame:0 TX packets:70 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:10014 (10.0 KB) TX bytes:10014 (10.0 KB)
Hapi i dyte eshte konfigurimi i SSH, por kesaj here hduser i master duhet te jete ne gjendje aksesoje veten por nepermjet emrit, dmth ssh master (mos te ngaterrohet me ssh localhost)
hduser@ubuntu:/usr/local/hadoop/conf$ ssh master The authenticity of host 'master (192.168.0.1)' can't be established. RSA key fingerprint is 00:c4:46:d0:97:12:ac:55:f0:6a:5b:12:07:b5:90:0f. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'master,192.168.0.1' (RSA) to the list of known hosts. Linux ubuntu 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 21:21:01 UTC 2011 i686 GNU/Linux Ubuntu 10.04.2 LTS Welcome to Ubuntu! * Documentation: https://help.ubuntu.com/ Last login: Tue Sep 25 03:12:40 2012 from localhost
69
Githashtu hduser duhet te aksesoje nyjen slave me ane te SSH
hduser@ubuntu:/usr/local/hadoop/conf$ ssh slave The authenticity of host 'slave (192.168.0.2)' can't be established. RSA key fingerprint is 00:c4:46:d0:97:12:ac:55:f0:6a:5b:12:07:b5:90:0f. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'slave,192.168.0.2' (RSA) to the list of known hosts. Linux ubuntu 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 21:21:01 UTC 2011 i686 GNU/Linux Ubuntu 10.04.2 LTS Welcome to Ubuntu! * Documentation: https://help.ubuntu.com/ 340 packages can be updated. 251 updates are security updates. New release 'precise' available. Run 'do-release-upgrade' to upgrade to it. Last login: Tue Sep 25 03:12:40 2012 from localhost
Hapi i fundit eshte konfigurimi i vete Hadoop qe te punoje si nje cluster shume-nyjesh. Meposhte do te japim konfigurimet respektive te master dhe slave.
Figura 5-4 Cluster shumenyjesh i detajuar 70
Nuk duhet te harrojmë qe nyja jona master do te shërbejë edhe si slave, dmth kjo nyje përveç menaxhimit te luster do beje edhe procesim te dhënash, megjithëse kjo nuk është gjithmonë e këshillueshme, sidomos ne rastin e një luster me shume nyje. Konfigurimi për file conf/masters (ky konfigurim duhet te behet vetem tek nyja master) behet per te përcaktuar secondary namenode qe ne rastin tone eshte vete nyja master. Gjithashtu automatikisht do te përcaktohet primary namenode qe do te jete nyja ku ekzekutohen skriptet bin/start-dfs.sh dhe bin/start-mapred.sh . Ne file conf/masters pra do te kemi vetem informacionin e meposhtem master
Konfigurimi për file conf/slaves (vetem per nyjen master) përcakton listën e nyjeve punëtore.( datanode dhe tasktracker ).
master slave
Nqs do te kemi shtimin e nyjeve slave ne file conf/sllaves duhet bere shtimi i emrit te tyre si p.sh master slave slave01 slave02 slave03
Konfigurimi per file te Hadoop : a) core-site.xml b) mapred-site.xml c) hdfs-site.xml Ne hapat e mësipërm ne bëmë disa modifikime këtyre file, por ato shërbejnë vetëm ne rastin e nje cluster me nje nyje. Konfigurimet e këtyre file do te ndryshojnë per te gjitha nyjet (master dhe slave). File core-site.xml duhet te modifikohet si meposhte.
71
fs.default.name hdfs://master:54310 The name of the default file system. A URI whose scheme and authority determine the FileSystem implementation. The uri's scheme determines the config property (fs.SCHEME.impl) naming the FileSystem implementation class. The uri's authority is used to determine the host, port, etc. for a filesystem.
File mapred-site.xml duhet te modifikohet si meposhte.
mapred.job.tracker master:54311 The host and port that the MapReduce job tracker runs at. If "local", then jobs are run in-process as a single map and reduce task.
File dfs-site.xml duhet te modifikohet si meposhte.
dfs.replication 2 Default block replication. The actual number of replications can be specified when the file is created. The default is used if replication is not specified in create time.
Por per rastin tone rekomandohet qe te përcaktojmë paraprakisht map dhe reduce maksimal.
mapred.map.tasks 50 Ne sa map task ndahet
72
mapred.reduce.tasks 80 Ne sa reduce task ndahet mapred.tasktracker.reduce.tasks.maximum 1 Ne sa reduce task ndahet puna ne nyjet punetore
5.3 Kodi Hadoop Hadoop perpunon informacionin e njesive llogaritëse te quajtura pune. Punet gjate
public static class CMBFMapper extends Mapper
{ @Override public void map map(IntWritable (IntWritable i, IntWritable lvl, Context context) throws IOException, InterruptedException { for ( final String[] imageDesc : new Worker().generateImages Worker().generateImages(i. (i.get get(), (), lvl.get lvl.get())) ())) { StringBuilder buffer = new StringBuilder(imageDesc[0]); for (int j = 1; j < imageDesc.length imageDesc.length; ; ++j) { buffer.append buffer.append("^"); ("^"); buffer.append buffer.append(imageDesc[j]); (imageDesc[j]); } context.write context.write( (new Text(buffer.toString Text(buffer. toString()), ()), new FastBigInt128()); } } }
73
ekzekutimit perdorin disa klasa te quajtura Mapper dhe Reducer. Keto klasa perdoren per ndarjen e problemit ne disa njesi me te vogla te quajtura detyre. Pas kesaj faze kemi mbledhjen e te gjithe rezultateve te detyrave map ne reducer dhe llogaritjen e rezultatit final.
public static class CMBFReducer extends Reducer, Writable> { @Override public void reduce reduce(Text (Text imageDesc, Iterable values, Context context) throws IOException, InterruptedException { FastBigInt128 res = new Worker().countInImage Worker().countInImage(imageDesc. (imageDesc.toString toString(). ().split split("\\^")); ("\\^")); context.write context.write(imageDesc, (imageDesc, res); } }
5.4 Rezultatet per Hadoop Meposhte do te japim rezultatet e eksperimentit te kryer vetem me ane te librarise Hadoop. Rezultatet e tabeles se meposhtme jane koha e ekzekutimit te aplikimit
Nr. punë
Mesatare
CPU 74
341
2705
33700
482
388
363
466
376
368
468
391
364
463
382
363
479
379
367
469.7
383.2
365
ne sekonda, per rastet kur puna ndahet ne 341, 2705 dhe 33700 nenpune.
Tabela 5-1 Rezultatet e aplikimit ne Hadoop
Performanca e CPU ne aplikimin e perdoruesit dhe te sistemit ne nyjen master.
Figura 5-5 Shfrytëzimi i CPU
Memorja Perdorimi i memorjes RAM (1 GB) ne nyjen master.
75
Figura 5-6 Shfrytezimi i memorjes RAM
Rrjeti Perdorimi i kartes se rrjetit gjate ekzekutimit te aplikimit ne nyjen master.
76
Figura 5-7 Perdorimi i rrjetit
5.5 Instalimi i Hazelcast Edhe ne kete rast kemi te njejtin ambjent testimi dhe te njejtin problem, problemin Dedekind per te zgjidhur si ne rastin e Hadoop.
77
Figura 5-8 Cluster i testimit
Fillimisht duhet te shkarkojme Hazelcast 1.9.4 i cili vjen si nje file i kompresuar zip. Dekompresojme kete file ne nje direktori te caktuar sipas deshires me komanden unzip. Duhet te jeni te kujdesshem qe te keni te drejta administrative (shkrim-lexim-ekzekutim) qe perdoruesi juaj te mund te ekzekutoje skriptet e Hazelcast.
zzz@ubuntu:~$ cd /home/zzz/Downloads zzz@ubuntu:~/Downloads$ ls hadoop-1.0.3 hadoop-1.0.3.tar.gz hazelcast-1.9.4.8.zip zzz@ubuntu:~/Downloads$ unzip hazelcast-1.9.4.8.zip Archive: hazelcast-1.9.4.8.zip creating: hazelcast-1.9.4.8/ creating: hazelcast-1.9.4.8/lib/ inflating: hazelcast-1.9.4.8/lib/hazelcast-ra-1.9.4.8.rar inflating: hazelcast-1.9.4.8/lib/hazelcast-wm-1.9.4.8.jar inflating: hazelcast-1.9.4.8/lib/hazelcast-hibernate-1.9.4.8.jar inflating: hazelcast-1.9.4.8/lib/hazelcast-spring-1.9.4.8.jar inflating: hazelcast-1.9.4.8/lib/hazelcast-cloud-1.9.4.8.jar inflating: hazelcast-1.9.4.8/lib/hazelcast-client-1.9.4.8.jar inflating: hazelcast-1.9.4.8/lib/hazelcast-1.9.4.8.jar inflating: hazelcast-1.9.4.8/lib/hazelcast-all-1.9.4.8.jar creating: hazelcast-1.9.4.8/docs/ creating: hazelcast-1.9.4.8/docs/manual/ creating: hazelcast-1.9.4.8/docs/manual/multi_html/ creating: hazelcast-1.9.4.8/docs/manual/single_html/ inflating: hazelcast-1.9.4.8/docs/manual/multi_html/ch01.html inflating: hazelcast-1.9.4.8/docs/manual/multi_html/ch02.html inflatin inflatin : hazelca hazelcast-1 st-1.9.4 .9.4.8/d .8/docs/ ocs/manu manual/ al/mult multi i html/ch html/ch02s0 02s02.ht 2.html ml
78
...
Me pas krijojme nje variabel mjedisi ―CLASSPATH‖ analoge me ate te krijuar si ne rastin e Hadoop. Ne kete variabel vendosim direktorine e Hazelcast, kjo sherben qe te importohen klasat e Hazelcast ne aplikimin tone.
zzz@ubuntu:~/Downloads$ cd ~/ zzz@ubuntu:~$ nano .bashrc
GNU nano 2.2.2
File: .bashrc
Modified
fi # enable programmable completion features (you don't need to enable # this, if it's already enabled in /etc/bash.bashrc and /etc/profile # sources /etc/bash.bashrc). if [ -f /etc/bash_completion ] && ! shopt -oq posix; then . /etc/bash_completion fi export CLASSPATH=/home/zzz/Hazelcast
Procesi Hazelcast eshte i shumefishte (multi-threaded), per kete arsye duhet vetem qe te ekzekutojme nga nje process ne cdo nyje dhe grid Hazelcast formohet automatikisht. Ne rast se procesi ndizet ne menyre te suksesshme do te shikojme pamjen e meposhtme, ne brendesi do te shikojme disa te dhena te dobishme si p.sh. adresa IP : 192.168.145.162 ose porta 5701.
79
zzz@ubuntu:~/hazelcast/bin$ sh run.sh Oct 8, 2012 3:34:18 AM com.hazelcast.config.XmlConfigBuilder INFO: Using configuration file at /home/zzz/hazelcast/bin/hazelcast.xml Oct 8, 2012 3:34:20 AM com.hazelcast.system INFO: /192.168.145.162:5701 [dev] Hazelcast 1.9.4.8 (20120209) starting at Address[192.168.145.162:5701] Oct 8, 2012 3:34:20 AM com.hazelcast.system INFO: /192.168.145.162:5701 [dev] Copyright (C) 2008-2011 Hazelcast.com Oct 8, 2012 3:34:20 AM com.hazelcast.impl.LifecycleServiceImpl INFO: /192.168.145.162:5701 [dev] Address[192.168.145.162:5701] is STARTING Oct 8, 2012 3:34:21 AM com.hazelcast.impl.base.VersionCheck WARNING: /192.168.145.162:5701 [dev] Newer version of Hazelcast is available. ====================================== You are running 1.9.4.8 [20120209] Newer version 2.0.2 [20120321] ====================================== Oct 8, 2012 3:34:24 AM com.hazelcast.impl.MulticastJoiner INFO: /192.168.145.162:5701 [dev]
Members [1] { Member [192.168.145.162:5701] this } Oct 8, 2012 3:34:24 AM com.hazelcast.impl.management.ManagementCenterService INFO: /192.168.145.162:5701 [dev] Hazelcast Management Center started at port 5801. Oct 8, 2012 3:34:24 AM com.hazelcast.impl.LifecycleServiceImpl INFO: INFO: /192.168 /192.168.145 .145.16 .162:57 2:5701 01 dev Address Address 192.168 192.168.145 .145.162 .162:570 :5701 1 is STARTED STARTED
Ne rastin tone do te kemi 4 nyje te ndezura, mbas ndezjes se Hazelcast ne nyjen e fundit do te shikojme pamjen e meposhtme.
zzz@ubuntu:~/hazelcast/bin$ sh run.sh Oct 8, 2012 4:02:37 AM com.hazelcast.config.XmlConfigBuilder INFO: Using configuration file at /home/zzz/hazelcast/bin/hazelcast.xml Oct 8, 2012 4:02:39 AM com.hazelcast.system INFO: /192.168.145.162:5704 [dev] Hazelcast 1.9.4.8 (20120209) starting at Address[192.168.145.162:5704] Oct 8, 2012 4:02:39 AM com.hazelcast.system INFO: /192.168.145.162:5704 [dev] Copyright (C) 2008-2011 Hazelcast.com Oct 8, 2012 4:02:39 AM com.hazelcast.impl.LifecycleServiceImpl INFO: /192.168.145.162:5704 [dev] Address[192.168.145.162:5704] is STARTING Oct 8, 2012 4:02:43 AM com.hazelcast.impl.base.VersionCheck WARNING: /192.168.145.162:5704 [dev] Newer version of Hazelcast is available. ====================================== You are running 1.9.4.8 [20120209] Newer version 2.0.2 [20120321]
80
...
====================================== Oct 8, 2012 4:02:45 AM com.hazelcast.cluster.ClusterManager INFO: /192.168.145.162:5704 [dev] Members [4] { Member Member Member Member }
[192.168.145.162:5701] [192.168.145.163:5701] [192.168.145.164:5701] [192.168.145.165:5701] this
Oct 8, 2012 4:02:47 AM com.hazelcast.impl.management.ManagementCenterService INFO: /192.168.145.162:5704 [dev] Hazelcast Management Center started at port 5804. Oct 8, 2012 4:02:47 AM com.hazelcast.impl.LifecycleServiceImpl INFO: /192.168.145.162:5704 [dev] Address[192.168.145.162:5704] is STARTED ====================================== Oct 8, 2012 3:34:24 AM com.hazelcast.impl.MulticastJoiner INFO: /192.168.145.162:5701 [dev]
5.6 Kodi Hazelcast Ekzekutuesi i shperndare i sherbimeve ne nje aplikim Hazelcast operon ne nderfaqe te public class Agent implements Callable, Serializable { private static final long serialVersionUID = 1L; private String[] imageDesc; private int z; public Agent Agent(String[] (String[] imageDesc, int z) { this.imageDesc this .imageDesc = imageDesc; this.z this .z = z; } public FastBigInt128 call call() () { Worker cmbfWorker = new Worker(); FastBigInt128 result = cmbfWorker.countInImage cmbfWorker.countInImage(imageDesc); (imageDesc); System.out.println System.out.println("\tResult ("\tResult from task #" + z + ", " + "\tvalue: " + result); return result; }}
81
tipit Callable/Runnable , kështu qe detyra kryesore e klasës Agent te mësipërme është te implementojë njërën nga këto ndërfaqe, përkatësisht atë Callable. Me pas behet ndarja e problemit ne pjese me te vogla te cilat i kalojnë ekzekutuesit te shpërndarë. for (int i = 1; i <= n; i++) { for (final String String[] [] imageDesc : cmbfWorker.generateImages cmbfWorker.generateImages(i, (i, level)) { Future future = executorService.submit executorService.submit( (new Agent(imageDesc, ++count)); tasks.add tasks.add(future); (future); } }
Se fundi mbledhim te gjithë rezultatet for (Future w : tasks) { results.add results.add(w. (w.get get()); ()); }
5.7 Rezulatet per Hazelcast Mëposhtë do te japim rezultatet e eksperimentit te kryer vetëm me ane te librarisë Hazelcast. Rezultatet e tabelës se mëposhtme janë koha e ekzekutimit te aplikimit
Nr. punë
Mesatare
82
341
2705
33700
366
320
333
362
318
332
356
326
336
346
326
334
361
319
332
358.2
321.8
333.4
ne sekonda, per rastet kur puna ndahet ne 341, 2705 dhe 33700 nënpunë.
Tabela 5-2 Rezultatet e aplikimit ne Hazelcast
CPU Performanca e CPU ne aplikimin e përdoruesit dhe te sistemit ne nyjen master.
Figura 5-9 Shfrytëzimi i CPU
Memorja Përdorimi i memorjes RAM (1 GB) ne nyjen master.
83
Figura 5-10 Përdorimi i memorjes RAM
Rrjeti Përdorimi i kartës se rrjetit gjate ekzekutimit te aplikimit ne nyjen master.
84
Figura 5-11 Përdorimi i kartës se rrjetit
5.8 Përfundime Ne grafikun e mëposhtëm do te përmbledhim te dhënat nga tabelat 5-1 dhe 5-2. Arrijmë ne dy përfundime te rëndësishme nga grafiku i mëposhtëm: 1) Ne përgjithësi Hazelcast performon me mirë se Hadoop, por performanca e te parës bie ne mënyrë te ndjeshme me rritjen e ndarjes se punëve, ndërsa Hadoop me vazhdon te zbresë kohen e ekzekutimit, pavarësisht nga rritja e ndarjes se punëve. 2) Mund te shihet se rezultatet e marra kur kemi ndarjen e punës ne copëza me te imëta, gabimi standard kuadratik është me i ulët ne krahasim me ndarjen ne 341 apo 2705 nënpunë. Ky rezultat qëndron per te dyja libraritë. Ky rezultat duhet te jete si shkak shkak i përdorimit përdorimit me te mire te balancuesit balancuesit te ngarkesës ngarkesës kur punët punët ndahen ndahen ne mënyrë me te imët. 3) Nga grafikët e shfrytëzimit te memorjes dhe rrjetit Figura 5-6, 5-7, 5-11 dhe 5-12 vihet re nje përdorim me i mire i këtyre burimeve nga ana e librarisë Hazelcast ne krahasim me atë Hadoop.
85
Figura 5-12 Krahasimi i performancës se librarive
5.9 Punime për te ardhmen Mëposhtë do te japim disa ide për zgjerimin e këtij punimi: 1. Një skenar i njëjtë por qe do te studiojë sjelljen e dy librarive ne varësi te numrit te nyjeve, pra performanca e tyre me rritjen e numrit te nyjeve anëtare. 2. Një skenar i njëjtë por me futjen ne studim edhe te disa librarive te tjera te rëndësishme si p.sh. Gridgain per gjuhën e programimit Java, ose Alchemi për gjuhën e programimit C#. 3. Një ide ambicioze do te ishte krijimi i cluster pa ndihmën e librarive te paracaktuara por me ane te shërbimeve te Web te quajtura ―Restful‖ dhe me pas
krahasimi i kësaj zgjidhjeje me ato te librarive te mësipërme.
86
Referenca [1] http://www.redbooks.ibm.com/redbooks/SG246895/wwhelp/wwhimpl/js/html/ wwhelp.htm [2] http://www.redbooks.ibm.com/redbooks/SG246778/wwhelp/wwhimpl/js/html/ wwhelp.htm [3] White, T. & Loukides, M. (2010) Hadoop: The Definitive Guide 2nd Edition Edition [4] http://www.mathpages.com/home/kmath030.htm [5] http://www.hazelcast.com/docs/1.9.4/manual/multi_html [6] http://www.michael-noll.com/tutorials/running-hadoop-on-ubuntu-linux-single-nodecluster [7] http://www.michael-noll.com/tutorials/running-hadoop-on-ubuntu-linux-multi-nodecluster [8] http://hadoop.apache.org/docs/r1.0.3 [9] http://en.wikipedia.org/wiki/Dedekind_number
87
Fjalor
88
