1. LEKSIONE PER SISTEMET E
SHPERNDARA DHE
PARALELE
Pjesa e Dyte
Sistemet e Shperndara
DEGA INFORMATIKE EKONOMIKE
Neki Frasheri
Tirane, 2012
1

2. Table of Contents
HYRJE..................................................................................................................................................3
Sistemet e shperndara......................................................................................................................3
Protokollet e komunikimit ne sistemet e shperndara.......................................................................4
Protokolli HTTP..............................................................................................................................5
CGI - Common Gateway Interface..................................................................................................8
PROGRAMIMI ME SOCKET...........................................................................................................11
Kuptimi i Socket............................................................................................................................11
Procedurat e Punes me Socket.......................................................................................................12
Shembull Klient - Server...............................................................................................................14
SISTEMET E SHPERNDARA..........................................................................................................17
Karakteristikat e Sistemeve te Shperndara....................................................................................17
Arkitektura e Sistemeve te Shperndara..........................................................................................19
Akritekturat Klient – Server .........................................................................................................21
Modeli Klient – Server Dy Palesh............................................................................................21
Modeli Klient – Server Tre Palesh............................................................................................22
Modeli Klient – Server Kater Palesh........................................................................................23
Modeli Peer – To – Peer ...........................................................................................................24
Agjentet e Levizshem................................................................................................................24
Nderlikueshmeria e Klient – Server..........................................................................................25
MBI PROJEKTIMIN E SISTEMEVE TE SHPERNDARA.............................................................28
Sfidat e Sistemeve te Shperndara...................................................................................................28
Kuptimi i transaksionit...................................................................................................................30
SISTEMET GRID DHE CLOUD......................................................................................................32
Sistemet Grid.................................................................................................................................32
Sistemet Cloud...............................................................................................................................35
2

3. HYRJE
Sistemet e shperndara
Sistemet paralele ishin te nevojshem per te zvogeluar kohen e ekzekutimit ne rastet kur kemi:
– vellim te madh llogaritjesh
– vellim te madh te dhenash
– vellim te madh kerkesash
Paralelizimi realizohej duke ndare algoritmin ne copa qe ekzekutoheshin ne nje bashlesi
procesoresh.
Sistemet e shperndara jane sisteme te perbere nga copa aplikimesh qe ekzekutohen ne CPU te
ndryshme te lidhura ne rrjet, tipikisht te shperndara gjeografikisht, per te zgjidhur nje detyre te
caktuar. “paralelizimi” ne kete rast kushtezohet nga ndarja gjeografike. Aplikimet e shperndara
pergjithesisht mund te ekzekutohen edhe ne nje CPU te vetme me kusht qe copat e aplikimit te
bashkeveprojne nepermjet shtreses TCP te rrjetit.
Shembuj tipike:
– World Wide Web
– sistemi i emrave te Inetrnetit DNS (Domain Name System)
– sistemi i postes elektronike
Shperndarja gjeografike e copave te aplikimit sjell probleme shtese ne teresine e zhvillimit dhe
administrimit te aplikimit. Ne kete kurs do te shikohen:
– modele konkrete aplikimesh te shperndara
– elemente te programimit te komunikimit ne rrjet
– problematika e sistemeve te shperndara
– modelet teorike te sistemeve te sheprndara
– siguria ne sistemet e shperndara (ne vecanti certifikatat elektronike)
3

4. Protokollet e komunikimit ne sistemet e shperndara
Ne sistemin reference OSI percaktohen protokollet e shtresave te vecanta:
Sistemi A komunikim virtual / real Sistemi B
Application protokoll aplikimi Application
Presentation protokoll prezantimi Presentation
Session protokoll sesioni Session
Transport protokoll transporti Transport
Network protokoll rrjeti Network
Data Link protokoll data Data Link
Physical protokoll fizik hardueri Physical
Te dhenat qarkullojne midis shtreses te aplikimit dhe asaj fizike (kjo e fundit realizon transmetimin
e tyre ne distance) duke kaluar midis shtresave – cdo shtrese perdor procedurat e shtreses se
meposhtme per te shkembyer te dhenat. Ne rastin e protokollit dominant ne Internet TCP/IP kemi
“shkrirjen” e protokolleve te aplikimit, prezantimit dhe sesionit ne nje te vetme:
Sistemi A komunikim virtual / real Sistemi B
Application protokoll aplikimi Application
Transport TCP protokoll transporti Transport TCP
Network IP protokoll rrjeti Network IP
Data Link protokoll data Data Link
Physical protokoll fizik hardueri Physical
Ne kete kurs vemendja do te perqendrohet ne komunikimet e shtreses te aplikimit.
4

5. Protokolli i komunikimit midis dy entiteteve percakton dy elemente:
– radhen e dialogut
– strukturen e mesazheve
Shembull tipik eshte protokolli HTTP (Hyper Texh Transport Protocol) i komunikimit midis
brouser dhe ueb-server.
Protokolli HTTP
Dialogu midis brouser dhe ueb-server realizohet si cift kerkese-pergjigje:
Brouser Ueb-Server
kerkese
pergjigje
Kerkesa permban adresen e objektit qe kerkohet, dhe ndoshta te dhena qe duhet ti kalohen objektit.
Pergjigja permban objektin e kerkoar ose mesazh qe serveri i dergon brouserit (pergjigja mund te
jete ne nje ose disa mesazhe)
Objektet ne WWW identifikohen me ndimen e URL (Unified Resource Locator):
URL = <skema>:<identifikuesi>
Skema = <tipi i identifikuesit dhe i protokollit>
HTTP ~ path ne server Ueb
FTP ~ path ne server FTP
FILE ~ path lokal
MAILTO ~ adrese email
…
<tipi i identifikuesit dhe i protokollit> = <adresa e objektit (specifike e skemes)>
<skedar> = //<hostname>[:<port>]/<path>[?<query>]
<adrese email>= <username>@<hostname>
…
5

6. Perdoruesi i jep brouserit URL e objektit te kerkuar. Brouser vecon emrin (ose numrin IP)
hostname te serverit (perfshi port nese eshte specifikuar) dhe e perdor ate per te komunikuar me
shtresen TCP, qe kjo e fundit te hape nje kanal komunikimi me aplikimin server. Me hapjen e ketij
kanali brouser i dergon serverit kerkesen, ku specifikohet adresa ne server e objektit te kerkuar.
Objektet ne server identifikohen nga URI (Unified Resource Identifier):
URI = <path>[?<query>]
<path> ~ percakton skedarin objekt
<query> ~ percakton te dhena qe duhet ti kalohen objektit (nqs. ka)
Formati i mesazhit te kerkeses eshte:
KERKESA KOMENT
<funksioni> <URI> <protokolli>
[<header>] Koka e kerkeses
[…]
<CR><LF> Rrjesht bosh
[<trupi kerkeses>] Opsional
Ku:
<funksioni> = GET ~ kerkese objekti, te dhenat dergohen ne URI
POST ~ kerkese objekti, te dhenat dergohen tek <trupi kerkeses>
HEAD ~ kerkohet vetem <koka e pergjigjes>
<protokolli> = HTTP/1.0 | HTTP/1.1
<header> = <metadata>: <vlere>
<metadata> = From | User_Agent | Date | …
<vlere> ~ string me format ne varesi te llojit te metadata
6

7. Formati i mesazhit te pergjigjes eshte i ngjashem me ate te kerkeses:
Pergjigje KOMENT
<protokolli> <status code>
[<header>] Koka e kerkeses
[…]
<CR><LF> Rrjesht bosh
[<trupi kerkeses>] Opsional:
objekti i kerkuar
ose mesazh HTML i serverit
Ku:
<protokolli> = HTTP/1.0 | HTTP/1.1
<status code> = 1xx ~ information
2xx ~ gjendja e objektit
3xx ~ ridrejtim ne URL tjeter
4xx ~ gabim ne pjesen e klientit
5xx ~ gabim ne server
<header> = <metadata>: <vlere>
<metadata> = Server | Last­Modified | Content_Type | …
<vlere> ~ string me format ne varesi te llojit te metadata
Detaje mbi Status Codes (HTTP/1.1)
200 ~ OK
304 ~ Not Modified
404 ~ Not Found
412 ~ Precondition Failed
501 ~ Method Not Implemented
Metadata Content_Type ka rendesi te vecante pasi informon boruserin se ne cfare gjuhe
prezantimi jane te dhenat qe ndodhen ne trupin e pergjigjes – text/html, text/ascii, …
Shembull:
telnet www.yahoo.com 80
7

8. CGI - Common Gateway Interface
CGI kryen tre funksione, duke mundesuar perdorimin e ciftit brouser ~ ueb-serber si nderfaqes
midis perdoruesit dhe nje programi ne distance.:
• Dergimi i parametrave te hyrjes per programin ne server
• Ekzekutimi i programit ne server
• Marja e daljes te programit nga serveri ne brouser
“get /cgi-bin/cgi?<parameters>”
BROUSER UEB SERVER
Content_Type: …
<html>
…
</html> <parameters> Content_Type: …
<html>
… /cgi-bin/cgi
</html>
Ne ueb-server programet duhet te jene ne nje direktori si …/cgi­bin/ , qe percaktohet ne
konfigurimin e daemonit httpd.
Te dhenat qe duhet te perpunoje programi dergohen nga brouser ne dy menyra:
– me kerkesen GET,
te dhenat vendosen ne vazhdim te URI te ndare nga kjo e fundit me “?”
programi i gjen te dhenat ne stringun e sistemit QUERY_STRING
programisti duhet te parashikoje leximin e te dhenave nga ky string
– me kerkesen POST,
te dhenat vendosen ne trupin e kerkeses
programi i gjen te dhenat ne hyrjen standarte stdin
programisti duhet te parashikoje leximin e te dhenave nga stdin
8

9. Formati i te dhenave eshte:
<parameters> = <variabel>=<vlere>[&<parameters>]
Ueb-server i kerkon rezultatet e programit ne daljen standarte stdout. Dhe ja dergon brouserit pa
ndonje perpunim te vendosura ne trupin e pergjigjes. Programisti duhet te parshikoje rezultatet e
programit te fillojne me metadata Content_Type, e pasuar nga rrjesht bosh (CR+LF).
Kujtese: ne C rrjeshti bosh ne print realizohet me formatin “rn”.
Brouser i mer te dhenat nga perdoruesi nepermjet strukturave [Form] te gjuhes HTML:
<Form Action=“URL” [Method=“{GET|POST}”>
<input name=“...” [size=“_”…] … >
<input name=“...” [type=“submit”…] … >
…
</Form>
Shembull:
Pamja e faqes ne brouser:
Kodi HTML:
<html>
<FORM ACTION="http://127.0.0.1/cgi-bin/view_get.cgi" Method="GET">
File Name <INPUT NAME="filename" SIZE="32" Value="enter file name">
<INPUT TYPE="SUBMIT" VALUE="View">
</FORM>
</html>
Koka e kerkeses:
GET /cgi­bin/view_get.cgi?filename=data.txt HTTP/1.1
Gjendja e stringut te sistemit QUERY_STRING ne server:
QUERY_STRING = "filename=data.txt"
Programi CGI ne gjuhen C:
9

10. #include <stdio.h>
#include <stdlib.h>
int main(void){
int ch; file *f; char *data; char datafile[256];
data=getenv("QUERY_STRING");
sscanf(data,"filename=%s",datafile);
f = fopen(datafile,"r");
if(f==NULL){ printf("Content-Type:text/html rnrn");
printf("<TITLE>Failure</TITLE>n");
printf("<P><EM>Unable to open data file!</EM>");}
else { printf("Content-Type: text/plain rnrn");
while((ch=getc(f)) != EOF) putchar(ch);
fclose(f); }
return 0;
}
10

11. PROGRAMIMI ME SOCKET
Programimi me “socket” ka te beje me perdorimin e procedurave te shtreses TCP per komunikim
midis proceseve nepermjet rrjetit.
Kuptimi i Socket
Formalisht “socket” eshte cifti
(<numer_IP>, <numer_porte>)
ku: <numer_IP> ~ numri IP i nderfaqesit me te cilin hardueri eshte i lidhur ne rrjet
<numer_porte> ~ numri i “portes” ne te cilen procesi / aplikimi eshte ne pritje te mare
mesazhe nepermjet rrjetit
proces aplikim
[port_A] [port_B]
TCP: TCP
derguesi (a1.a2.a3.a4, port_A) derguesi (b1.b2.b3.b4, port_B)
marresi (b1.b2.b3.b4, port_B) marresi (a1.a2.a3.a4, port_A)
IP: [a1.a2.a3.a4] IP: [b1.b2.b3.b4]
Host A Host B
NET
Pa hyre ne detaje, sistemi qe fillon komunikimin eshte “klienti” dhe ai qe pret thirrjen eshte
“serveri”. Ne secilin sistem komunikimi behet duke perdorur dy “kanale” per dhenie dhe marje. Te
dy aplikimet klient dhe server duhet te perdorin nga nje cift socket per dhenie-marje. Si rregull
numri i portes pritese i serverit eshte i paracaktuar me mareveshje nderkombetare (grupi i pare i
numrave ne segmentin [1:65535], shiko skedarin /etc/services) por mund te ripercaktohet
nga programisti. Numri i portes pritese te klientit mund te zgjidhet i rastit nder numrat e mbetur ne
segmentin [1:65535], automatikisht nga TCP ose i percaktuar nga programisti.
Numrat IP si per klientin dhe serverin duhet te jepen nga perdoruesi (klienti) dhe administratori
(serveri). Ne rastin e sistemeve me nje nderfaqes rrjeti, TCP mund ta gjeje numrin lokal IP, ndersa
ne sistemet me disa nderfaqes duhet nderhyrja e perdoruesit/administratorit (duke supozuar qe kjo
mundesi eshte mare ne konsiderate nga programisti). Si rregull klienti mund te dije emrin e domenit
te serverit, dhe programisti i aplikimit klient duhet te parashikoje gjetjen e numrit IP nga emri
11

12. nepermjet sistemit DNS. Ndersa serveri e gjen numrin IP te klientit ne koken e paketes te pare me te
cilen klienti ekrkon hapjen e sesionit te komunikimit me serverin.
Puna me socket eshte e ngjashme me punen me skedaret – si rregull per komunikimin me periferiket
sistemi i shfrytezimit perdor te njejten logjike. Behet fjale per:
– gjetje te numrit IP nga emri i domenit (nese duhet)
– hapje te socket
– lexim (marrje) dhe / ose shkrim (dergim) ne socket
– mbyllje te socket
duke perdorur strukturat e te dhenave qe disponon TCP per kete qellim.
Ne protokollin TCP/IP jane percaktuar disa lloje socket:
• Stream – protokolli TCP standard
• Datagram – protokolli UDP i thjeshtezuar
• Raw – raw data transfer over IP
• Unicast – destination i vetem – IP = A.B.C.D
• Multicast – grup destinacion – IP = 224.x.x.x
• Broadcast – direkt lokal – IP = x.x.x.255
• Loopback – loopback – IP = 127.x.x.x
Procedurat e Punes me Socket
Algoritmi principal per punen me socket TCP ne klient eshte:
• Gjendet KLIENTI
◦ Adresa IP e serverit
◦ Numri i portes te aplikimit ne server
• Krijohet kopje e TCP socket e serverit kopje
socket
• Lidhet [connect] socket me serverin server
◦ Serveri duhet te jete ne degjim
socket
• Send / Receive me server socket lokale
• Mbyllet lidhja
connect
server
12

13. Ne menyre te ngjashme akgoritmi perkates per socket TCP ne server eshte:
• Gjendet Server
◦ Adresa IP e serverit
◦ Numri i portes te aplikimit ne server
• Krijohet socket TCP e serverit
• Lidhet [bind] socket e serverit me TCP socket
server
• Kalohet ne pritje degjimi (listen)
kopje bind
• Pranohet lidhja [connect] nga klienti socket
klient
• Merret kopje e socket te klientit
• Send / Receive data me socket klient connect
• Mbyllet lidhja me klientin klienti
Procedurat kryesore TCP qe perdoren ne aplikimin klient jane:
• Krijohet socket ~ int socket()
• Lidhet socket me serverin ~ connect()
• Send / receive data ~ send() / recv()
• Mbyllet socket ~ close()
Procedurat kryesore TCP qe perdoren ne aplikimin server jane:
• Krijohet socket ~ int socket()
• Lidhet socket me serverin ~ bind()
• Kalohet ne regjim degjimi ~ listen()
• Pranohet lidhja me klientin ~ accept()
• Send / receive data ~ send() / recv()
• Mbyllet socket ~ close()
Strukturat e te dhenave qe perdor TCP jane te percaktuara ne headers:
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
13

14. Strukturat kryesore jane dy:
struct sockaddr_in
{
…
sin_family ~ AF_INET, …
sin_addr.s_addr ~ INADDR_ANY, …
sin_port ~ <numer porte>
…
}
struct hostent
{
…
h_addr ~ <numer IP>
h_length ~ <gjatesi numri IP>
…
}
Shembull: Klient – server minimal me perdorimin e socket TCP.
Disa specifikime mbi programin:
• Klienti
◦ Ekzekutohet <klient> <host> <port>
◦ Hap socket me serverin
◦ Kap mesazhin nga tastiera dhe e dergon
◦ Pret pergjigje nga serveri
◦ Fund
• Serveri
◦ Ekzekutohet <server> <port>
◦ Krijon socket te serverit
◦ Kalon ne gjendje “listen”
◦ Pranon mesah nga klienti dhe e afishon
◦ Dergon pergjigje klientit
◦ Fund
Shembull Klient - Server
Kodi ne gjuhen C (sistem Linux) per aplikimin klient dhe server eshte si me poshte:
14

15. Programi minimal Klient
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
void error (char *msg) { perror(msg); exit(1); }
int main (int argc, char *argv[ ]) {
struct sockaddr_in serv_addr;
struct hostent *server;
int sockfd, portno, rc;
char buffer[256];
if (argc<3) { printf("usage %s host portn",argv[0]); exit(0); }
/* krijohet kopje e socket te serverit */
sockfd=socket(AF_INET,SOCK_STREAM,IPPROTO_TCP);
if (sockfd<0) error("ERROR opening socket");
/* inicializohet kopje e socket te serverit */
// gjendet IP e serverit dhe numri portes
server = gethostbyname(argv[1]);
portno = atoi(argv[2]);
if (server==NULL) error("ERROR host not foundn");
serv_addr.sin_family = AF_INET;
serv_addr.sin_port = htons(portno);
// kopjohet struktura
bcopy( (char *) server­>h_addr,
(char *) &serv_addr.sin_addr.s_addr,
server­>h_length
);
/* lidhet socket me serverin ~ socket lokale automatike */
if (connect(sockfd, &serv_addr, sizeof(serv_addr)) < 0)
error("ERROR while connecting");
else printf(“Server connectedn”);
/* get & send message ne socket te serverit */
// merret mesazhi nga tastiera dhe dergohet
fgets(buffer,255,stdin);
rc = send(sockfd,buffer,strlen(buffer),0);
if (rc < 0) error("ERROR writing to socket");
/* receive & print message ne socket te serverit */
rc = recv(sockfd,buffer,255,0);
if (rc < 0) error("ERROR reading from socket");
printf("%sn",buffer);
/* mbyllet socket */
close(sockfd);
return 0;
}
15

16. Programi minimal Server
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
void error(char *msg){ perror(msg); exit(1);}
int main(int argc, char *argv[]){
int sockfd, newsockfd, portno, clilen, rc;
struct sockaddr_in serv_addr, cli_addr;
char buffer[256];
if (argc<2) { printf("usage %s portn",argv[0]); exit(0); }
/* krijohet socket e serverit */
sockfd = socket(AF_INET, SOCK_STREAM, 0);
if (sockfd < 0) error("ERROR opening socket");
/* inicializohet socket e serverit */
portno = atoi(argv[1]);
serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = INADDR_ANY;
serv_addr.sin_port = htons(portno);
/* lidhet socket me protokollin TCP */
if ( bind( sockfd,
(struct sockaddr *) &serv_addr,
sizeof(serv_addr)
) < 0) error("ERROR on binding");
/* regjim degjimi ne socket te serverit */
listen(sockfd,5);
/* pritet kerkesa e klientit & lidhet socket e serverit me kopjen e socket te klientit */
clilen = sizeof(cli_addr);
newsockfd = accept( sockfd,
(struct sockaddr *) &cli_addr,
&clilen
);
if (newsockfd < 0) error("ERROR cannot accept");
/* receive & print message */
n = recv(newsockfd,buffer,255,0);
if (n < 0) error("ERROR reading from socket");
printf("Here is the message: %sn",buffer);
/* send message */
n = send(newsockfd,"I got your message",18,0);
if (n < 0) error("ERROR writing to socket");
/* mbyllen socket */
close(newsockfd);
close(sockfd);
return 0;
}
16

17. SISTEMET E SHPERNDARA
Me termin “sisteme te shperndara” kuptojme nje bashkesi hardueri dhe softueri te coptuar
“shperndare” gjeografikisht por qe punon si nje e vetme per zgjidhjen e nje detyre te caktuar. Ne
kete kuptim kompjuterat e lidhur ne nje rrjet perbejne nje sistem hardueri te shperndare, nje ueb-
brouser dhe brouserat qe komunikojne me te perbejne nje sistem softueri te shperndare, nje mail
server dhe klientet qe komunikojne me te perbejne nje sistem te shperndare, etj. Me poshte do te
perqendrohemi ne sistemet softuer te shperndare, e thene ndryshe aplikimet e shkerndara.
Sistemt paralele te trajtuara ne pejsen e pare te kursit perbejne nje rast te vecante te sistemeve te
shperndara.
Synimi i ndertimit te sistemeve te sheprndara ka te beje me ceshtje si:
– realiteti fizik “i shperndare” i veprimtarise njerezore
‐ kudo ndodhja e paisjeve qe komunikojne me njera tjetren
‐ puna ne ekipe te shperndara gjeografikisht
‐ nevoja e kapjes te burimeve informatike ne distance
– shfrytezimi i burimeve kompjuterike te shperndara / ndarja e burimeve
‐ ulja e kostos te sistemeve informatike
‐ rritja e efektivitetit te kapaciteteve informatike
Karakteristikat e Sistemeve te Shperndara
Ne varesi te platformes harduer dallohen disa grupe sistemesh te shperndara:
– Sistemet e bazuara ne rrjetat kabllore (baker, optike, radio-rele)
Perberesit e ketyre sistemeve jane te palevizshem, dhe si te tille relativisht te
parashikueshem. Topologjia e rrjetit eshte e pa ndryshueshme.
– Sistemet e bazuara ne teknologjite pa tel
Perberesit e ketyre sistemeve jane te levizshem, dhe te pa parashikueshem. Topologjia e
rrjetit mund te ndryshoje (kercimi i nje klienti nga nje pike aksesi tek tjetra). Ketu futen
sistemet e bazuara ne WiFi, telefoni celulare dhe bluetooth.
– Sistemet “ubiquous”1
1 Ubiquitous computing (ubicomp) is a post-desktop model of human-computer interaction in which information
processing has been thoroughly integrated into everyday objects and activities. This paradigm is also described as
pervasive computing, ambient intelligence, everyware. When primarily concerning the objects involved, it is also
physical computing, the Internet of Things, haptic computing, and things that think ...
[wikipedia.org/wiki/Ubiquitous_computing]
17

18. Keto sisteme te shperndara permbledhin kompjuter, PDA (Personal Device Appliance),
sisteme “embed” te integruar ne paisje nga me te ndryshmet, te cilet kudo-ndodhen, levizin
dhe komunikojne midis tyre.
Ne Internet funksionojne shume sisteme te shperndara, si me tipiket mund te permenden:
– Sistemi i emrave te domeneve DNS, qe “lidh” numrat IP me emrat perkates te kompjuterave
ne Internet. Sistemi i emrave te Internetit eshte organizuar ne forme peme (Fig.) dhe DNS
funksionon si nje “numrator” i shperndare, ne parim nje server i vecante per cdo nyje
ndermjetese te pemes:
ICANN
.gov .com .org .al .bg .gr
yahoo.com google.com upt.al gov.al
mail.yahoo.com www.yahoo.com fti.upt.al complab.upt.al
– Sistemi i postes elektronike
server
klient INTERNET klient
server
– WWW ~ World Wide Web ...
Tim Berners-Lee, CERN 1989, konsorciumi W3 (www.w3.org)
– Sherbimet si Yahoo, Google, Twitter, Facebook, Linkedin jane sisteme te shperndara qe
ngrihen mbi WWW (i bashkuar me sisteme bazash te dhenash)
18

19. Arkitektura e Sistemeve te Shperndara
Sistemet e perqendruara karaketrizohen nga perparesi dhe probleme:
Perparesi: Thjeshtesi / Qendrueshmeri / Optimizim
Probleme: Mbrojtja e hapesires te adresimit / Kapacitet perpunimi i ulet / Kerkesa per kontakt fizik.
Pjeserisht keto probleme jane trajtuar nga Programimi i Orientuar Objekt, ndertimi i CPU multi-
procesor dhe multi-core, dhe rrjetat. Sistemet e shperndara synojne te plotesojne zgjidhjen e ketyre
problemeve duke ofruar izolime te hapesirave te adresimit, kapacitete perpunimi te larta dhe
shmangie e kerkeses per kontakte fizike. Sistemet e shperndara i vene ne dispozicion perdoruesit te
dhena dhe kapacitete qe ndodhen gjeografikisht larg. Ne kushtet e Internetit keto burime jane ne
parim te pakufizuara.
Procedura A Procedura B Procedura C
Te Dhena Te Dhena Te Dhena
Private Private Private
Te Dhena Globale
Fig. Arkitekture Sistemi i Perqendruar
Programi B
Te Dhena
Private
Programi A
Programi C
Te Dhena
Private RRJET Te Dhena
Private
Te Dhena Globale
(network file system)
19

20. Fig. Arkitekture Sistemi i Shperndare
Arkitekturat e shperndara ofrojne perparesi:
• Kapacitet perpunimi i larte – shume CPU
• Zgjerueshmeri – lehtesia e shtimit te CPU
• Mbrojtje e hapesires te adresimit nje platforma te vecanta
• Kapje nepermjet rrjetit – pa kontakt fizik me serverat
• Funksionim ne mjedise heterogjene
dhe njekohesisht probleme:
• Kompleksiteti i programimit
◦ Komunikimi midis programeve
◦ Formatet e te dhenave
◦ Protokollet e komunikimit
◦ Sinkronizimi i proceseve
• Qendrueshmeria
◦ Nje pjese e sistemit mund te dale nga puna pa u vene re
• Optimizimi
◦ Mungon vizioni global mbi sistemin
Realizimi i sistemeve te shperndara behet nepermjet plotesimit te Sistemit te Shfrytezimit me
“midleuerin” (middleware):
Aplikime Niveli / kerkesat e perdoruesit
Middleueri Niveli / specifikat e sistemit te shperndare
Sistemi
Shfrytezimit Platforma heterogjene
[i rrjetit]
Hardueri
Fig. Roli i Midleuerit ne Sistemet e Shperndara
Middleueri siguron:
20

21. • Fshehjen e heterogjenitetit duke ofruar modele programimi uniforme per aplikimet
• Blloqet per ndertimin e perberesve te sistemit te shperndare
• Abstragimin e proceseve te komunikimit midis aplikimeve
• Shembuj standardesh: SUN RPC, CORBA, Java RMI, etj.
Aplikimi mbetet programi specifik i perdoruesit dhe realizohet si nje bashkesi procesesh qe
ekzekutohen ne makina te ndryshme: procese klient, procese server, dhe procese peer.
Akritekturat Klient – Server
Modelimi i sistemeve te shperndara behet me ndihmen e ciftit klient – server. Rasti me i thjeshte i
nje sistemi te shperndare eshte ai i perbere nga dy procese qe mund te eksekutohen ne makina te
vecanta, njeri nga proceset – klienti – ben nje kerkese dhe procesi tjeter – serveri – i pergjigjet
kerkeses te klientit.
Duhet theksuar se cifti klient – server mund te funksionoje dhe brenda nje makine (pra pa qene
gjeografikisht i shperndare), me kusht qe komunikimi midis tyre te behet nepermjet sistemit te
shfrytezimit te rrjetit (TCP/IP). Shembull – Apache dhe Firefox ne nje PC duke perdorur si URL
http://127.0.0.1/... Nje aplikim i projektuar dhe realizuar si i shperndare mund te funksionoje si i
tille dhe brenda nje makine.
Dallohen dy tipe arkitekturash klient – server:
• Klasike klient server – Asimetrike – Serveri i percaktuar
• Peer-to-peer (p2p) – Simetrike – Cdo nyje punon si klient dhe server
Modeli Klient – Server Dy Palesh
Modeli klient – server dy palesh (2-tier) permban nje server dhe disa kliente:
21

22. platforma
kerkese
Klient Server
Procesi middleue r
pergjigje
Klient Server
Ne kete model kemi komunikim direkt midis klientit dhe serverit. Modeli rezulton i pershtatshem
per numer te vogel klientesh (50-100 kliente njekohesisht), duke patur problem zgjerueshmerine.
Dallohen dy nenlloje te ketij modeli:
• Klienti i “trashe” & serveri i “holle” (fat/thin)
◦ Klienti = UI + llogjika
◦ Serveri = te dhenat
• Klienti i “holle” & serveri i “trashe”
◦ Klienti = UI
◦ Serveri = llogjika + te dhenat
Veshtiresia e zgjerimit te ketij modeli eshte tejkaluar duke perdorur modele klient – server me
komplekse.
Modeli Klient – Server Tre Palesh
Modeli klient – server tre palesh perfshin dhe nje “Agjent” midis klientit dhe serverit. Roli i ketij
agjenti mund te jete:
• Filter i trafikut (per rritjen e sigurise)
• Ballancues i ngarkeses (mundeson shperndarjen e kerkeses midis disa serverave)
• Sherbime inteligjente (autentikim, perpunime te dhenash etj.)
Shembull – sistemet proxy, ku agjenti
22

23. • ballancon ngarkesen ne “ferme / klaster” serverash heterogjene
• sherben si negociator / broker midis klientit dhe bashkesise te serverave heterogjene
Faqe
statike
html
http sql
Server
Web
Brouser baze te
Server
Te dhena dhenash
html
dinamike
tier1 tier2 tier3
Rast i vesante i sistemeve tre palesh eshte agjenti proxy, roli i te cilit eshte ndermjetesimi midis
brouserit dhe uebserverit, duke mbajtur nje “baze te dhenash [cache]” me faqet e kerkuara, per te
shmangur ringarkimin e tyre nga Interneti:
Klient Server
cache
Server
Klient PROXY
cache Server
Server
Klient
cache Server
Modeli Klient – Server Kater Palesh
Ne modelet kater – palesh gjenden dy agjente, roli i te cileve mund te jete:
• Agjent Ueb: trajton prezantimin e te dhenave
• Agjent komponent: trajton llogjiken e aplikimit
Sistemet per e-biznes jane, zakonisht, kater – palesh:
23

24. Brouser Agjent Ueb Agjent Server
komponent
User tier1 Prezantim Aplikim tier3 Te dhena
tier2 tier4
Komunikimi midis brouserit dhe agjentit ueb ne kete rast duhet te jete i sigurte, dhe ky i fundit
duhet te trajtoje dhe autentikimin.
Modeli Peer – To – Peer
Ne kete model cdo njesi perberese e sistemit funksionon edhe si klient edhe si server:
Objekte te
ndashem
Ne fakt kemi te bejme me disa procese ne cdo njesi:
server
Peer 1 RRJETI Klient Peer 1
server
Klient
Sistemet peer-2-peer perdoren shume per ndarjen e skedareve. Realizimi i ketij funskionaliteti
kerkon qe brenda komunitetit te peers te qarkulloje informacion se ku ndodhen skedaret, gje qe
realizohet duke perfshire ne sistem nje “indeksues [broker]”, nje server te vecante qe ndihmon
peers te gjejne vendndodhjen e skedareve dhe te hapin sesionet e komunikimit midis tyre (kjo e
fundit kur peers perdorin adresa IP private).
Agjentet e Levizshem
Modeli i agjenteve te levizshem perben nje vecanti ne kompleksin e modeleve te sistemeve te
sheprndara. Agjentet e levizshem jane kode qe nga nje njesi e sistemit te shprendare transferohen
dhe ekzekutohen ne nje njesi tjeter. Si shembull mund te eprmenden kodet ne Java Script ose Java
Applet qe dergohen nga ueb server per tu ekzekutuar ne brouser. Interesi i perdorimit te agjenteve te
levizshem mund te qendroje ne optimizimin e funskionimit te sistemit te shperndare, por mbart me
vete kompleksitetin e kontrollit dhe te sigurise
24

25. Nje nga aplikimet negative te ketij koncepti jane krimbat si nje nga mjetet e thyerjes te sigurise te
sistemeve informatike (krahaso: viruset – aktivizohen kur perdoruesi ekzekuton kodin e infektuar;
krimbat futen ne nje sistem duke shfrytezuar sherbimet e pambrojtura te ketij sistemi pa nderhyrjen
e perdoruesit). Shembull – krimbi i Internetit i Robert Morris Jr. ne 1988
[wikipedia.org/wiki/Morris_worm].
Nderlikueshmeria e Klient – Server
Aplikimet e shperndara mund te realizojne funksione teper komplekse duke kryer nje numer te
madh dialogesh midis tyre. Per thejshtesimin e konceptimit te sistemit eshte e nevojshme qe
bashkesia e komunikimeve midis proceseve perberes te aplikimit, qe mund te ekzekutohen ne
makina te ndryshme, te coptohet ne cifte elementare klient – server. Ky coptim do te ndihmonte
programistin ne perdorimin e socket gjate zhvillimit dhe testimit te aplikimit. Coptimi i
komunikimit midis perberesve te nje aplikimi ne cifte elementare klient – server behet duke
saktesuar protokollin e komunikimit me perdorimin e dy perberesve – kerkese dhe pergjigje.
Si rregull, nje cift elementar klient – server nenkupton nje kerkese dhe nje pergjigje, por ne raste te
vecanta ose kerkesa ose pergjigja edhe mund te mungojne. Per te qartesuar problemin duhet te
meren parasysh tre nivele te protokollit te komunikimit midis perberesve te sistemit te shperndare,
ne nivelet e ndryshme dy palet komunikuese mund te ndrojne rolet::
– niveli i perdoruesit klient '===> server
– niveli i aplikimit server '<=== klient
– niveli TCP klient '===> server
Ku:
• perdoruesi i kerkon serverit realizimin e nje detyre
• serveri i kerkon klientit te autentikohet (ndrojne rolet)
• sesionin e komunikimit e hap klienti (ndrojne rolet)
◦ ne kete sesion: kush dergon mesazh dhe kush duhet te pergjigjet ???
Shembull:
Kerkohet ndertimi i nje sistemi te shperndare ku (protokolli i perdoruesit):
– persoruesi kerkon te kape nje baze te dhenash
‐ perdor aplikimin klient (jo brouser)
‐ dergon kerkesen ne portal (ueb server)
25

26. – portali ueb server mer kerkesen nga kilenti dhe, duke perdorur CGI
‐ komunikon me nje server autentikimi per verifikimin e perdoruesit,
‐ nese autentikimi eshte pozitive dergon kerkesen bazes te te dhenave
‐ i kthen pergjigjen brouserit (negative ose plotesim kerkese)
Skema e komunikimit eshte si ne figure:
s. autentikimi
2
1 3
brouser ueb server
6 5
4
s. database
Ne baze te protokollit te perdoruesit percaktohen detajet e protokolleve ne nivel aplikimi (zgjidhja
nuk eshte e vetme). Protokollet e komunikimit ne nivel aplikimi, te thjeshtezuar, mund te ishin:
Nr. klienti ueb server s. autentikimi s. baze te dhenash
protokolli klient – usebserver
protokolli uebserver s.autentikimi
protokolli uebserver s. baze te dhenash
connect listen
1 send (msg.1) recv (msg.1)
recv (...)
connect listen
2
send (msg.2) recv (msg.2)
recv (msg.3) send (msg.3)
3
close close
check (msg.3)
negative? positive?
connect listen
4 send recv (msg.4)
(msg.4)
recv send (msg.5)
5 (msg.5)
close close
recv (msg.7) send (msg.7)
6
close close
26

27. Thjeshtezimi qendron ne mosperfshirjen e elementeve si:
– shkembimi i metadata te serverave midis tyre
– dallimi midis nen-versioneve te mesazheve
– shkembimi i metadata te protokolleve
– shkembimi i metadata te sesioneve
– autentikimi midis serverave
– perdorimi i multi - thread
– perdorimi i kriptografise
– etj.
Formati i mesazheve mund te percaktohet si me poshte ((i thjeshtezuar, ne varesi te kerkesave te
detyres dhe specifikimit te protokolleve):
msg.# emri i fushes tipi gjatesia koment
user_name string 16
kerkesa e klientit per
1 pass_string string 32
ueb serverin
query_string string 256
user_name string 16 kerkesa e ueb
2 serverit per
pass_string string 32 autentikim
rezultati i
3 user_rights string 32
autentikimit
user_rights string 32
kerkesa per
4
databazen
query_string string 256
5 answer_string string 256 pergjigja e databazes
6 answer_string string 256 pergjigja per klientin
Bazuar ne formatet e mesazheve dhe detajet e protokolleve mund te kryhet programimi i klientit
dhe serverave.
27

28. MBI PROJEKTIMIN E SISTEMEVE TE SHPERNDARA
Projektimi i sistemeve te shperndara ka kerkesa shtese, ne krahasim me sistemet e perqendruara.
Sfidat e Sistemeve te Shperndara
Ne sfidat e te qenurit i shperndare mund te futen:
– Heterogjeniteti
‐ teknologjia dhe topologjia e rrjetave
‐ ndryshimet ne perberesit e harduerit
‐ ndryshimet ne perberesit e softuerit
‐ ndryshimet ne sistemet e operimit / gjuhet e programimit
‐ perdoruesit (edukimi / kultura / mentaliteti)
‐ roli i middleware (shtrese softueri midis sistemit dhe aplikimeve per model uniform
programimi dhe fshehjen e heterogjeniteteve)
– Hapja (sistemi eshte i hapur kur eshte e mundur te ndryshohet dhe zgjerohet nga kushdo)
‐ shkalla e hapjes percaktohet nga lehtesia per shtimin e perberesve te rinj
‐ hapja e sistemit behet duke publikuar specifikimet e nderfaqesve (formati i mesazheve
dhe protokollet e dialogut)
Shembull – protokolli SMTP:
>>> MAIL from: <sender@sender>
<<< 250 2.1.0 <sender@sender>... Sender ok
>>> RCPT To:<receiver@receiver>
<<< 250 2.1.5 < receiver@receiver>... Recipient ok
>>> DATA
<<< 554 5.7.1 Bounce address not SRS signed!
>>> QUIT
‐ problem perben nderfaqimi i perberesve te zhvilluar nga persona te ndryshem
– Zgjerueshmeria (ruajtja e efektivitetit kur rritet vellimi i burimeve dhe/ose i perdoruesve)
‐ sistemi duhet konceptuar i tille qe te lehtesoje zgjerimin e kapaciteteve
‐ duhet parandalimi i “shterimit” te burimeve
‐ duhet parandalimi i dukurise “gryka e shishes” (bottleneck)
‐ duhet mbajtja nen kontroll e humbjes te performances
‐ duhet mbajtja nen kontroll e kostos te burimeve fizike
– Transparenca (fshehja e perberesve te vecante duke krijuar pershtypjen e nje sistemi unik)
‐ menyrat e kapjes te burimeve
‐ vendodhja dhe / ose levizshmeria e burimeve
28

29. ‐ njekohshmeri (konkurenca) e proceseve
‐ shumefishimi (replication) e te dhenave
‐ identifikimi dhe trajtimi i problemeve
‐ levizshmeria e perberesve te sistemit
‐ ndikimi i performances te sistemit
‐ zgjerueshmeria e sistemit
– Konkurenca ne kapjen e burimeve te perbashketa
‐ problemi klasik i sistemeve te operimit te para ne nje mjedis te ri te shperndare
‐ koncepti i transaksionit per shmangien e bllokimeve
‐ ekzekutimi paralel ne mjedis te shperndare
‐ shkembimi i informacionit dhe i mesazheve (MPI)
‐ ndarja e skedareve
– Trajtimi i problemeve dhe veshtiresite ne sistemet e shperndara
‐ copezimi i perberesve te sistemit
‐ pavaresia teknike dhe administrative e perberesve
‐ teknikat e trajtimit te problemeve per perberes te ndryshem
‐ detektimi i problemeve ne distance
‐ maskimi i problemeve per transparence
‐ tolerimi i problemeve per shmangien e ndalimeve
‐ riaftesimi i funksionaliteteve / perberesve te sistemit
‐ perdorimi i “bollekut” (redundancy) per trajtimi e problemeve
– Siguria
‐ siguria midis sistemeve
‐ siguria midis perdoruesve
‐ siguria e burimeve (kosto, integriteti, besueshmeria)
‐ realizimi i sigurise (kriptografia, verifikimi i identitetit (authentication))
– Mekanizmat e Sigurise
‐ kriptimi i mesazheve
‐ algoritmat e njeanshem (pa dekriptim)
‐ sistemet e kriptimit me ciftin e celesave privat & publik
‐ identifikimi me <perdorues> & <fjalekalimi> dhe certifikata elektronike
‐ probleme (sulmet per mohim sherbimi (DoS), siguria ne sistemet e levizshem)
‐ shembull: EDUROAM – sistemi i identifikimit per sistemin akademik pan-evropian
29

30. Kuptimi i transaksionit
Zhvilluesi i nje sistemi te shperndare klient – server duhet te mare parasysh se:
– mund te mbahet ne kontroll funksionimi i serverit, por
– nuk mund te kontrollohen
‐ veprimet e klientit
‐ qarkullimi i te dhenave ne rrjet
Client Service
Ne keto kushte duhen ritheksuar problemet:
– Toleranca
‐ Veprimet jo te rregullta te perdoruesit
‐ Deshtimi i protokolleve te lomunikimit
– Siguria
‐ Veprimet jo te rregullta te perdoruesit
‐ Nderhyrjet ne linjat e komunikimit
‐ Deshtimet (injorimi dhe / ose rimarja)
Konceptimi i struktures te ”transaksionit” ka te beje me shmagjen e bllokimit te burimeve ne server
gjate shftytezimit te tyre nga klienti. Burimet ne server kapen dhe lirohen sipas kerkesave te
perdoruesit:
lock
TPR
Client Service Resource
TPR
unlock
Ne protokollin e dialogut midis klientit dhe serverit dallohen ciftet elementare kerkese – pergjigje,
qe ne rastin tone realizohen nga proceduratt e njohutra me emrin TPR (transaction processing
30

31. routine). Rendesi ka programimi i TPR-ve ne menyre te tille qe te zvogelohet sa me shume intervali
i kohes te bllokimit te burimit:
lock
TP
R unlock
Client Service Resource
lock
TP
R unlock
Rendesi ka gjithashtu rimarja ne rast problemesh ne anen e klientit. Perdorimi i timer per te matur
kohen e reagimit te klientit dhe per te nderprere transaksionin ne rast tej-vonese eshte vendimtar por
dhe problematik per shmangien e humbjes te punes te realizuar deri ne momentin e shfaqjes te
vonesave dhe gabimeve. Per kete qellim perdoren “pikat e rimarjes” (checkpoint) ne fillim dhe fund
te TPR (atje ku eshte e mundshme):
Client Service
TPR
R Checkpoint A
I Checkpoint B
M TPR
A
R Checkpoint C
J ABORT
E
TPR
Pika e rimarjes perfaqeson evndin ne program ku gjendja e variablave kritike regjistrohet ne nje
skedar historik, qe mund te elxohet ne rast perseritjeje te programit per te shmangur rifillimin e
punes nga e para. Duhet kujtuar se perdorimi i pikave te rimarjes keshillohet pergjithesisht per
aplikimet komplekse dhe jo vetem ne sistemet e shperndara.
31

32. SISTEMET GRID DHE CLOUD
Sistemet grid dhe cloud synojne te ofrojne, nepermjet rrjetit, kapacitete perpunuese ne menyre
transparente per perdoruesit. Vete termi “grid” eshte nga rrjetat e shperndarjes te energjise elektrike,
ku perdoruesi mer energji nepermjet nje prize pa u interesuar per burimin e energjise dhe rruget e
saj. Grid doli si zgjidhje e perballimit te kerkesave per kapacitete te larta perpunuese me ndihmen e
shume kompjuterave te lidhur ne rrjet (cluster), tipike per komunitetet shkencore. Cloud perben nje
nivel me te larte te konceptit – ofrimin e harduerit dhe softuerit si sherbim.
Sistemet Grid
Rasti me i thjeshte i sistemeve grid eshte klasteri (cluster) me PC ne nje rrjet lokal. Problemet
llogaritese qe mund te paralelizohen mund te “coptohen” dhe copat te ekzekutohen ne PC te
vecanta, me pas copat e rezultateve integrohen ne nje. Paralelizmi mund te behet ne shume menyra
(kur eshte e mundur, ne varesi te natyres te problemit):
– coptimi i te dhenave dhe perpunimi ne menyre te pavarur i tyre ne PC te vecanta
– coptimi i algoritmit ne copa te pavarura dhe ekzekutimi i tyre ne PC te vecanta
– “klonimi” i algoritmit ne procese paralele qe nder-komunikojme me MPI
Coptimi i detyres llogaritese ne copa te pavarura ne PC te ndryshme mund te behet manualisht ose i
automatizuar me ndihmen e nje midleueri (middleware), si GLOBUS dhe CONDOR.
Roli i midleuerit eshte ndarja e detyres ne copa sipas specifikimeve te perdoruesit ne PC te vecanta
dhe integrimi me pas i rezultateve. Sepcifikimi i ndarjes te detyres ne copa behet nepermjet gjuheve
JDL (Job Description Language).
Perberesit tipike te middleuerit ne nje klaster jane:
– nderfaqesi i perdoruesit (UI – User Interface), me komandat e gjuhes JDL
– nyjet e punes (WN – Work Nodes), PC ne rrjetin lokal qe kryejne detyrat llogaritese
– manaxheri / dispeceri i puneve (CE – Computer Element), qe monitoron WN dhe ndan
detyrat llogaritese
– kujtesa e jashtme e perbashket (SE – Storage Element), e realizuar nepermjet sistemit te
skedareve te ndare ne rrjet (NFS – Network File System), qe u ofron tere nyjeve te klasterit
nje hapesire disku te perbashket
– monitoruesi (MON), qe mban nen vezhgim dhe regjistron punen e nyjeve te klasterit.
– Eventualisht modulet e MPI per komunikimin midis proceseve ne rrjet lokal
32

33. Pamja e nje klasteri te tille eshte si ne figure:
WN1 WN2 WN3 WN4 WN5
UI MON CE SE
Ne shume raste rrjeti i nje organizate konfigurohet ne menyre te tille qe gjate dites te punoje ne
regjim te zakonshem, ndersa gjate nates te punoje si grid.
Ne menyre qe PC e ndryshme et mund te komunikojne me njera tjetren pa nderhyrjen e perdoruesit
(transferime skedaresh dhe ekzekutime programesh), mund te jete e nevojshme te rregullohet skema
e mbrojtjes e rrjetit ne menyre te pershtatshme, ne varesi te llojit te midleuerit qe perdoret, per
shembull:
– Ne mjediset Linux perdoret ssh dhe scp per komunikim te sigurte me fjale kalimi. Ne
rastin konkret per hir te automatizimit duhet qe komunikimi te behet pa fjale kalimi, cka
kerkon rikonfigurimin e sistemit ssh / scp (ssh passwordless authentication)
– Makinat me detyra kritike (CE, SE, MON, UI) mund te paisen me certifikata elektronike per
te njohur njera tjetren. Ne keto raste cifti i celsit privat / publik regjistrohet ne direktorine
perkatese, celsi privat i pa kriptuar ndersa ai publik ne formen e certifikates.
Ne kuadrin e bashkepunimit midis organizatave te ndryshme, vecanerisht ne mjediset universitare
dhe shkencore, perfshihet dhe perdorimi reciprok i kapaciteteve perpunuese te sistemeve
informatike – klasterave. Kjo presupozon qe secila organizate te kete sistemin grid lokal, dhe keto
sisteme te vecanta grid integrohen ne nje sistem grid nder-institucional, qe mund te zgejrohet ne
shkalle kombetare ne “grid kombetar”, dhe me tej ne “grid nderkombetar”.
Kritike ne realizimin e nje sistemi shume-grid eshte qenia e disa funksioneve te perqendruara:
– manaxheri / dispeceri i puneve (WM – Work Manager)
– baza e te dhenave informative (BDII – Berkeley Database Information Index)
– monitoruesi / kontabilizuesi (MON)
– Autoriteti i certifikatave elektronike (CA – Certificate Authority)
Roli i manaxherit te puneve eshte i ngjashem me ate te CE, dallimi konsiston ne faktin qe CE
komunikon me WN brenda klasterit, ndersa WM komunikon nepermjet Internetit me CE dhe SE e
33

34. klasterave te ndryshem. BDII mban informacion mbi gjendjen e bashkesise te klasterave, duke
ndihmuar WN ne shperndarjen e puneve ne klastera te vecante. Monitoruesi regjistron kohen e
punes dhe perdorimin e burimeve te klasterave, per te mundesuar edhe faturimin e shpenzimeve kur
kjo gje zbatohet). Komunikimi midis WM – CE – SE – MON – BDII mbahet i sigurte nepermjet
certifikatave elektronike. Roli i CA nuk eshte vetem regjistrimi i certifikatave, por dhe shperndarja
periodikisht e certifikatave te zhvleresuara (CRL – Certificate Revocation List).
MON BDII
WM CA
INTERNET
CE SE MON
CE SE MON WN ...
WN ...
CE SE MON
CE SE MON WN ...
WN ...
Ekzistojne shume lloje midleueri per sisteme grid me shume klastera dhe emertimi i nyjeve mund te
ndryshoje ne rastet e ndryshme.
Aktualisht ne Evrope fondacioni EGI (European Grid Initiative – http://www.egi.eu/) administron
projektin evropian EGI-InSPIRE (Integrated Sustainable Pan-European Infrastructure for
Researchers in Europe) qe mundeson lidhjen e sistemeve grid kerkimore kombetare ne nje grid pan-
evropian duke perdorur midleuerin EMI (European Middleware Initiative – http://www.eu-
emi.eu/).
34

35. Sistemet Cloud
Sistemet cloud jane nje nivel mbi ato grid dhe ofrojne kapcitete harduer dhe softuer sipas kerkeses,
te kapshme nepermjet Internetit. Prej shume vitesh kompani si Google dhe Yahoo kane ofruar
kapacitete per posten elektronike, perdoruesi mer sherbimin pa e ditur ne ke server konkret ndodhen
te dhenat. Ky koncept eshte zgjeruar duke ofruar mjedise pune te tipit “Office”, dhe me tej akoma
duke ofruar “harduer” ku perdoruesi mund te instaloje sistemet e veta.
Fizikisht cloud eshte nje klaster qe administrohet nga nje “manaxher / dispecer”. Ne rastin e nje
mjedisi pune cloud funskionon si grid i specializuar – dispeceri shperndan kerkesat ne nyjet e
ndryshme te klasterit. Ne rastin e ofrimit te “harduerit” perdoren makinat virtuale mbi te cilat
perdoruesi instalon sistemet e veta. Vendi i makinave virtuale eshte si ne figure:
aplikime aplikime aplikime aplikime
sistem shfrytezimi sistem shfrytezimi sistem shfrytezimi sistem shfrytezimi
Makina Virtuale
Sistemi baze i Shfrytezimit
CPU
HDD
disk virtual disk virtual disk virtual disk virtual
Duke qene se sistemet e shfrytezimit te perdoruesve mbahen ne disqe virtuale – skedare ne diskun
real, mund ti zhvendosim nga nje nyje e klasterit ne nje tjeter duke mundesuar si optimizimin e
shperndarjes te ngarkeses (me pasoje rritjen e shpejtesise te punes per gjithe perdoruesit) dhe
shmangien e nderprerjeve ne raste difektesh (skedari i makines virtuale kopjohet / duplikohet nga
nje nyje ne tjetren).
aplikim aplikim
sistem shfrytezimi sistem shfrytezimi
makina virtuale makina virtuale
sistem baze shfrytezimi sistem baze shfrytezimi
CPU CPU
HDD HDD virtual HDD virtual HDD
LAN
35