LEKSIONE PER SISTEMET E SHPERNDARA DHE

PARALELE

Pjesa e DyteSistemet e Shperndara

DEGA INFORMATIKE EKONOMIKE

Neki Frasheri

Tirane, 2012

1

Table of ContentsHYRJE..................................................................................................................................................3

Sistemet e shperndara......................................................................................................................3Protokollet e komunikimit ne sistemet e shperndara.......................................................................4Protokolli HTTP..............................................................................................................................5CGI - Common Gateway Interface..................................................................................................8

PROGRAMIMI ME SOCKET...........................................................................................................11Kuptimi i Socket............................................................................................................................11Procedurat e Punes me Socket.......................................................................................................12Shembull Klient - Server...............................................................................................................14

SISTEMET E SHPERNDARA..........................................................................................................17Karakteristikat e Sistemeve te Shperndara....................................................................................17Arkitektura e Sistemeve te Shperndara..........................................................................................19Akritekturat Klient – Server .........................................................................................................21

Modeli Klient – Server Dy Palesh............................................................................................21Modeli Klient – Server Tre Palesh............................................................................................22Modeli Klient – Server Kater Palesh........................................................................................23Modeli Peer – To – Peer ...........................................................................................................24Agjentet e Levizshem................................................................................................................24Nderlikueshmeria e Klient – Server..........................................................................................25

MBI PROJEKTIMIN E SISTEMEVE TE SHPERNDARA.............................................................28Sfidat e Sistemeve te Shperndara...................................................................................................28Kuptimi i transaksionit...................................................................................................................30

SISTEMET GRID DHE CLOUD......................................................................................................32Sistemet Grid.................................................................................................................................32Sistemet Cloud...............................................................................................................................35

2

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

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

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

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>

Koka e kerkeses[<header>]

[…]

<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

Formati i mesazhit te pergjigjes eshte i ngjashem me ate te kerkeses:

Pergjigje KOMENT

<protokolli> <status code>

Koka e kerkeses[<header>]

[…]

<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

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

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

BROUSER

<html>…</html>

Content_Type: …<html>…</html>

UEB SERVER

/cgi-bin/cgi

“get /cgi-bin/cgi?<parameters>”

<parameters> Content_Type: …

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 “\r\n”.

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:

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

<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>

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 \r\n\r\n");

printf("<TITLE>Failure</TITLE>\n"); printf("<P><EM>Unable to open data file!</EM>");}

else { printf("Content-Type: text/plain \r\n\r\n"); while((ch=getc(f)) != EOF) putchar(ch);fclose(f); }

return 0;}

PROGRAMIMI ME SOCKETProgramimi 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:derguesi (a1.a2.a3.a4, port_A)marresi (b1.b2.b3.b4, port_B)

TCPderguesi (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

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

◦ Adresa IP e serverit

◦ Numri i portes te aplikimit ne server

• Krijohet kopje e TCP socket e serverit

• Lidhet [connect] socket me serverin

◦ Serveri duhet te jete ne degjim

• Send / Receive me server socket

• Mbyllet lidhja

12

KLIENTI

socket lokale

kopjesocketserver

connect

server

Ne menyre te ngjashme akgoritmi perkates per socket TCP ne server eshte:

• Gjendet

◦ Adresa IP e serverit

◦ Numri i portes te aplikimit ne server

• Krijohet socket TCP e serverit

• Lidhet [bind] socket e serverit me TCP

• Kalohet ne pritje degjimi (listen)

• Pranohet lidhja [connect] nga klienti

• Merret kopje e socket te klientit

• Send / Receive data me socket klient

• Mbyllet lidhja me klientin

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

Server

kopje socket klient

socketserver

bind

connect

klienti

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

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 port\n",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 portesserver = gethostbyname(argv[1]); portno = atoi(argv[2]); if (server==NULL) error("ERROR host not found\n");serv_addr.sin_family = AF_INET;    serv_addr.sin_port = htons(portno);    // kopjohet strukturabcopy(  (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 connected\n”); 

/* get & send message ne socket te serverit */// merret mesazhi nga tastiera dhe dergohetfgets(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("%s\n",buffer); 

 /* mbyllet socket */

close(sockfd);  return 0;

}

15

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 port\n",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: %s\n",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

SISTEMET E SHPERNDARAMe 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

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:

– Sistemi i postes elektronike

– 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

ICANN

.gov .com .org .al .bg .gr

yahoo.com google.com upt.al gov.al

fti.upt.al complab.upt.almail.yahoo.com www.yahoo.com

klient klient

server

server

INTERNET

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.

Fig. Arkitekture Sistemi i Perqendruar

19

Procedura A

Te Dhena Private

Procedura B

Te Dhena Private

Te Dhena Globale

Procedura C

Te Dhena Private

Programi A

Te Dhena Private

Programi B

Te Dhena Private

Te Dhena Globale

(network file system)

Programi C

Te Dhena Private

RRJET

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):

Fig. Roli i Midleuerit ne Sistemet e Shperndara

Middleueri siguron:

20

Aplikime

Middleueri

Sistemi Shfrytezimit

[i rrjetit]

Hardueri

Sistemi Shfrytezimit

[i rrjetit]

Niveli / kerkesat e perdoruesit

Platforma heterogjene

Niveli / specifikat e sistemit te shperndare

• 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

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

Klient

Klient

Server

Server

kerkese

pergjigje

platforma

Procesi middleuer

• ballancon ngarkesen ne “ferme / klaster” serverash heterogjene

• sherben si negociator / broker midis klientit dhe bashkesise te serverave heterogjene

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:

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

BrouserWeb

Server

Faqe statike

Server baze te

dhenash

http

html

html

sql

Te dhena dinamike

tier1 tier2 tier3

Klient

cache

Klient

cache

Klient

cache

Server

Server

Server

Server

Server

PROXY

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:

Ne fakt kemi te bejme me disa procese ne cdo njesi:

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

Brouser Agjent Ueb Agjent komponent

Server

User tier1 Prezantim tier2

Aplikim tier3 Te dhena tier4

Objekte te ndashem

RRJETIPeer 1server

Klient Peer 1

server

Klient

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

– 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:

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

1

connect listen

send (msg.1) recv (msg.1)

recv (...)

2connect listen

send (msg.2) recv (msg.2)

3recv (msg.3) send (msg.3)

close close

check (msg.3)

negative? positive?

4

connect listen

send (msg.4)

recv (msg.4)

5recv

(msg.5)send (msg.5)

close close

6recv (msg.7) send (msg.7)

close close

26

brouser ueb server

s. autentikimi

s. database

1

2

3

4

56

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

1

user_name string 16

kerkesa e klientit per ueb serverin

pass_string string 32

query_string string 256

2

user_name string 16 kerkesa e ueb serverit per autentikimpass_string string 32

3 user_rights string 32rezultati i autentikimit

4

user_rights string 32kerkesa per 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

MBI PROJEKTIMIN E SISTEMEVE TE SHPERNDARAProjektimi 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

‐ 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

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

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:

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

ServiceClient

ServiceClient Resource

lock

unlock

TPR

TPR

routine). Rendesi ka programimi i TPR-ve ne menyre te tille qe te zvogelohet sa me shume intervali

i kohes te bllokimit te burimit:

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):

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

ServiceClient Resource

lock

unlock

lock

unlockTPR

TPR

ServiceClient

TPR

TPR

TPR

ABORT

Checkpoint A

Checkpoint C

Checkpoint B

RIMARJE

SISTEMET GRID DHE CLOUDSistemet 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

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

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).

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

INTERNET

CE SE MONWN ...

CE SE MONWN ...

CE SE MONWN ...

CE SE MONWN ...

WM

MON BDII

CA

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