Utilizarea optimă a sistemelor distribuite eterogen

Şi în România, procesul de informatizare se caracteri zează prin apariţia şi dezvoltarea în interiorul diverselor organizaţii a unor reţele de calculatoare care, de cele mai multe ori, sunt sau devin eterogene. Diversitatea se manifestă fie la nivel hardware, fie al sistemului de operare, fie la ambele. Această evoluţie nu trebuie să sperie, pentru că este un proces natural, care ţine cont de evoluţia explozivă a domeniului, dominată la momente succesive de timp de tehnologii diferite (sparc, alpha, PII, ca procesor, UNIX, şi acum NT si LINUX ca sistem de operare).

După ce prin crearea reţelei s-a reuşit partajarea informaţiei şi comunicarea între utilizatori şi programe, următoarea întrebare logică a oricărui proprietar sau administrator de reţea este dacă resursele instalate nu pot fi folosite eficient şi la execuţia aplicaţii lor. Avem în vedere creşterea indicelui de utilizare, ca şi a numărului de aplicaţii executate în unitatea de timp (throughput). De multe ori, observăm într-o organizaţie următoarea situaţie paradoxală: unele calculatoare sunt neutilizate, în timp ce altele nu fac faţă prelucrărilor de date. Evident, nu este vorba de acele aplicaţii, cum sunt bazele de date, care fac apel la anumite resurse dedicate. În interiorul unei firme, colectivul de contabili tate foloseşte calculatoarele numai un interval limitat de timp, în timp ce colectivul de proiectare a unui produs nou are nevoie de resurse puternice până la realizarea obiectivului. La fel, într-o universitate, un colectiv foloseşte mai puţin resursele sale de calcul, în timp ce altul îşi pune problema achiziţionării unor resurse suplimentare.

Utilizarea resurselor este un aspect. Altul se referă la momentul deciderii cumpărării unor noi calculatoare. Orice evoluţie natu rală presupune întâi epuizarea posibilităţilor sistemelor instalate, cu eventuala amortizare a investiţiei, după care, apoi, se pune problema up-gradării.

În fine, există profiluri diferite de utilizatori şi de aplicaţii. Printr-o administrare inteligentă a acestora, se poate ajunge la un grad ridicat de satisfacere a cerinţelor lor, simultan cu un indice apropiat de maximum pentru utilizarea resurselor de calcul.

Pentru administrarea eficientă a resurselor eterogene ale unui sistem distribuit, este necesar un software adecvat, care să pună în practică strategii de gestiune a resurselor, ţinând cont, în acelaşi timp, de nivelele diferite de importanţă şi termene de execuţie ale aplicaţiilor din sistem. Eficienţa soft-ului de administrare este dictată de cele două componente ale sale:

• Resource tasking, care selectează job-urile ce urmează a fi lansate în execuţie, decide asupra resurselor ce vor fi folosite şi asupra procentului din resursele partajate care va fi alocat fiecărui job;

• Workload regulation, care decide alocarea de resurse, astfel încât resursele partajate să fie în concordanţă cu obiectivele de administrare a resurselor – aplicaţiile cele mai importante, sau cu termenele cele mai apropiate vor obţine un procent adecvat din resurse.

Componenta de resource tasking utilizează importanţa relativă a aplicaţiilor ce candidează pentru execuţie, corelează instanţe concurente ale aceloraşi utilizatori, aplicaţii şi proiecte în vederea implementării eficiente a strategiilor de partajare a resurselor. Sistemele care nu au atributele prezentate mai sus, vor suferi pe mai multe planuri:

• Aplicaţii importante /urgente pot fi întârziate sau "sufocate" din lipsa resurselor, în timp ce alte aplicaţii sunt iniţiate şi executate;

• Utilizatori neautorizaţi pot domina resursele partajate şi determină, în consecinţă, o scădere a productivităţii, prin lansarea în execuţie a celei mai mari cantităţi de programe;

• Un utilizator poate depăşi în timp nivelul de utilizare al resurselor, pe care şi l-a propus.

Aceste efecte sunt contrare politicilor de utilizare a resurselor, care urmăresc maximalizarea beneficiului întregii comunităţi de utilizatori ai sistemului distribuit.

Pentru a rezolva problemele prezentate, multe organizaţii se bazează pe intervenţia manuală, prin dedicarea resurselor unor funcţii selectate, sau prin păstrarea unor re zerve în utilizarea resurselor, mai mari decât este necesar.

O altă problemă importantă este echilibrarea sarcinilor de lucru între resursele partajate, prin luarea unor decizii inteligente de alocare, atunci când job-urile sunt trimise pentru execuţie. Practica curentă este de a folosi ca parametru încărcarea curentă a fiecărui calculator (de exemplu, numărul de procese aflate în coada proceselor gata de execuţie, sau numărul de utilizatori conectaţi), fără a se ţine cont de caracteristicile proceselor în execuţie (priorităţi, urgenţe, utilizatori). Utilizarea exclusivă a încărcării calculatorului poate fi sursa unor decizii ineficiente de alocare a aplicaţiilor la calculatoare, care determină dezechilibre între calculatoare şi, în consecinţă, timpi de execuţie mai mari. De exemplu, o aplicaţie urgentă poate fi alocată unui calculator mai slab ca performanţe, doar pentru că momentan acesta era slab utilizat (neîncărcat). Sau, resursele de calcul cele mai puternice sunt ignorate pentru că performanţele lor practice sunt ignorate.

Iniţial, o aplicaţie este alocată unui calculator dat, fără a se ţine cont de evoluţia sa dinamică şi, posibil, imprevizibilă. Aceasta înseamnă că utilizarea resurselor poate să difere în mod semnificativ, după un interval de timp. De aceea, componenta de workload regulation este esenţială pentru implemen tarea strategiilor necesare. Din păcate, cele mai multe sisteme au în vedere numai alocarea iniţială, ignorând evoluţia ulterioară a aplicaţiei şi a sistemului distribuit, în ansamblu.

Sistemele, care încearcă să trateze aspectul importanţei relative sau urgenţei unei aplicaţii, nu sunt eficiente deoarece folo sesc strategii de lansare în execuţie cu priori tate (nice), fără a urmări în continuare regularizarea sarcinii de lucru.

Pentru a îmbunătăţi gradul de utilizare al resurselor, se încearcă uneori modificarea manuală a priorităţilor job-urilor. Această operaţie poate fi dificilă, pentru că presupune că operatorul a identificat poziţia tuturor proceselor componente şi poate executa modificările pe toate calculatoarele gazdă. Mai mult, după toate aceste modificări, este posibil ca efectul să nu fie cel scontat – controlul priorităţii prin nice nu are efecte previzibile şi proporţionale cu utilizarea resurselor.

Unele aplicaţii, mari consumatoare de resurse, sunt amânate pentru intervale de timp când nu există o încărcare mare a sistemului (noaptea, la sfârşit de săptămână), deşi ele ar putea beneficia de perioadele de neutilizare din cadrul intervalului obişnuit de lucru.

Există mai multe produse academice sau comerciale care îşi propun administrarea optimă a unui sistem distribuit eterogen, cele mai importante dintre ele fiind recenzate în cadrul catalogului software publicat pe Internet de către NHSE, la capitolul instrumente de prelucrare distribuită (distributed processing tools).

În continuare, vom prezenta succint sistemul CODINE (COmputing in DIstributed NEtworks), realizat de GENIAS Software GmbH pentru administrarea aplicaţiilor într-un sistem distribuit UNIX eterogen. În momentul de faţă se lucrează şi la versiunea pentru Windows NT. Am selectat acest sistem datorită multiplelor sale posibilităţi, uşurinţei în instalare şi utilizare, a gradului înalt de interacţiune dintre utilizator şi sistem, ca şi a performanţelor sale remarcabile.

Prezentare generală CODINE

Arhitectura sistemului

CODINE poate administra mai multe tipuri de job-uri: batch (scripturi shell), interactive, paralele şi cu puncte de verificare (checkpointing). Acestea sunt introduse în cozi de aşteptare de unde sunt apoi lansate în execuţie pe calculatoare care sunt neutilizate, sau care au o încărcare mică. Activităţile de calcul sunt distribuite calculatoarelor sistemului, în funcţie de starea de încărcare a fiecărei maşini şi de necesităţile lor de resurse. Pentru job-urile cu puncte de verificare, se asigură migrarea acestora de la o staţie la alta, fără intervenţia utilizatorului, ca urmare a evoluţiei parametrului de încărcare.

Sistemul administrat de CODINE, care mai este cunoscut şi cu denumirea de cluster sau celulă, este format din calculatoare care au o variantă de UNIX ca sistem de operare (IRIX, Solaris, Linux, etc.) şi sunt interconectate. Un calculator administrat de CODINE este o gazdă (host).

CODINE foloseşte mai multe tipuri de demoni, dintre care cei mai importanţi sunt demonul master (cod_qmaster), demonul planificator (cod_schedd), demonii pentru comunicaţii (cod_commd) şi demonii pentru execuţie (cod_execd).

Demonul master este administratorul ansamblului, folosind în acest scop o bază de date. Baza de date conţine informaţii despre cozi, job-urile în execuţie sau în aşteptare, ca şi despre resursele disponibile în cluster. În mod periodic, demonul master primeşte de la d emonii de execuţie informaţii privind parametrii de încărcare ai gazdelor din cluster si actualizează, în mod corespunzător, baza de date. Tot el preia în numele sistemului CODINE job-urile care sunt primi te pentru execuţie, după care solicită planificatorului luarea deciziilor de alocare a resurselor.

Deoarece funcţionarea sa continuă şi corectă este esenţială, demonul master este multiplicat sub forma unor demoni master de rezervă (shadow). Într-o situaţie critică, când acesta nu mai funcţionează, se selectează o nouă gazdă, unde este pornit automat un demon master nou. În acest interval de timp, nu se pierde nici o informaţie si nici un job.

Planificatorul asigură introducerea job-urilor în cozile de aşteptare cele mai adecvate. Când soseşte în sistem, un job este însoţit de lista de resurse cerute. Astfel, planificatorul poate decide dacă necesarul de resurse poate fi satisfăcut imediat, sau job-ul trebuie să aştepte în coadă până ce acele resurse vor deveni disponibile. Decizia luată este comunicată demonului master, care actualizează baza de date. Apoi, demonul master transmite demonului de execuţie de pe gazda aleasă să lanseze în execuţie job-ul respectiv.

Pe fiecare maşină CODINE există un demon de execuţie, care startează şi opreşte job-uri. El comunică starea maşinii şi, deci, modul de evoluţie locală al activităţilor de calcul, demonului master.

În fiecare cluster se execută unul sau mai mulţi demoni de comunicaţie. Ei asigură comunicaţia asincronă între ceilalţi demoni CODINE, ceea ce conduce la creşterea eficienţei sistemului. Toate comunicaţiile se realizează cu un singur port TCP.

Cozile CODINE

O coadă CODINE este definită pentru o maşină şi poate "executa" mai multe job-uri simultan (concurent dacă sistemul are un singur procesor). Aceasta înseamnă că fiind o coadă pentru job-uri gata de execuţie, numărul ei de sloturi defineşte gradul de concurenţă. Are sens ca atunci când maşina are o singură unitate centrală, coada să aibă 1-2 sloturi, iar dacă maşina este bi-procesor, să aibă 2-4 sloturi. Bineînţeles, o maşină poate găzdui mai multe cozi. Cozi speciale pot fi definite pentru calculatoare paralele.

Fiecare coadă de pe o maşină este o reprezentare a clasei de aplicaţii care poate fi executată pe maşina respectivă. Ea este configurată pe baza unor atribute diverse, cum ar fi, de exemplu, proprietarul cozii, limita superioară a încărcării, nivelul de prioritate.

Există o coadă generală, administrată de demonul master, unde sunt primite job-urile de către sistemul CODINE – pending queue, si cozi de execuţie, administrate de demonii de execuţie.

Cozile pot fi de tipul: batch, interactiv, cu punct de verificare paralel. Acest atribut defineşte tipul aplicaţiilor care pot fi introduse pentru execuţie în această coadă. Alte atribute importante sunt:
• Numărul job-urilor /coadă;
• Maşina gazdă;
• Proprietarul cozii şi lista cu utilizatorii care au acces la această coadă;
• Procesoarele unei maşini multi-procesor ce vor fi folosite de job-urile care se execută în această coadă;
• Complexele cozii.

Conceptul de complex permite transmiterea unor informaţii importante, cum ar fi, de exemplu, atributele resurselor pe care un utilizator le cere pentru un job, valorile de încărcare ale gazdei, dar şi ale sistemului în ansamblu. Mai multe cozi pot fi grupate prin atribuirea unui complex particular în comun. Apoi, ele vor putea fi adresate în comun prin atributele acelui complex. Există trei tipuri de complexe:
• Implicit (default), care conţine toate atributele pre-definite, cum ar fi numele cozii, gazda, prioritatea, limitele cozii;
• De încărcare (load). Există două tipuri de complexe de încărcare, încărcarea gazdei (host load) care reflectă starea unei maşini particulare din cluster, şi încărcarea globala (global load) care se referă la resursele clusterului, cum ar fi numărul de licenţe al unui anumit software, spaţiul liber de pe disc, sau traficul din reţea. Atât complexul local, cât şi cel global pot fi extinse sau modi ficate de către administratorul sistemului.
• Utilizator (user defined), care reprezintă o colecţie de atribute şi definiţia privind modul lor de utilizare de către CODINE. Şi în acest caz, mai multe cozi pot fi grupate cu un complex definit pentru ele de utilizator.

Un job poate avea acces la resursele sistemului, în interiorul unor limite, care sunt definite tot ca atribute ale cozilor. O posibilitate ar fi să se definească cozi pentru job-uri cu o durată de execuţie mică, medie şi mare. Există şi alte limite definite prin intermediul cozilor:
• Timpul WallClock;
• Timpul CPU;
• Dimensiunea datelor şi a fişierelor;
• Dimensiunea stivei, a memoriei centrale şi a spaţiului pe disc.

Cozile pot fi organizate ierarhic. O coadă subordonată altei cozi va fi considerată ca un dispozitiv cu o prioritate scăzută – ea va fi suspendată atunci când este atins un număr pre-definit de job-uri în coada părinte. Nu există decât un singur nivel de subordonare, deşi o coadă poate fi subordonată la mai multe cozi simultan.

Ce este interesant, componenta de interfaţare cu alte sisteme de cozi (Queuing System Interface – QSI) permite transferul unor job-uri din sistemul CODINE către alte sisteme, cum ar fi NQS de la CRAY. În felul acesta, se pot integra într-o structură unică diverse sisteme de cozi, care interfaţează în fond sisteme de calcul diferite ca putere de calcul.

Planificarea job-urilor

Planificatorul CODINE implementează mai multe strategii:

First-in-first-out, primele job-uri sosite sunt primele lansate în execuţie, dacă solici tarea lor de resurse poate fi satisfăcută;
• Equale-share, dacă mai mulţi utilizatori trimit simultan mai multe job-uri, acestea vor fi astfel planificate încât fiecare utilizator să aibă în execuţie aproximativ acelaşi număr de job-uri;
• Limited-job-count, la fel ca mai înainte, doar că numărul de job-uri în execuţie este limitat pentru fiecare utilizator;
• Priority poate fi folosită adiţional faţă de una din celelalte strategii. Întâi se execută job-urile cu prioritatea cea mai mare, iar la prioritate egală se foloseşte una din celelalte strategii.

Dacă cererea de resurse a unui job poate fi satisfăcută de mai multe cozi, sau job-ul nu are cereri exprese, pentru introducerea job-ului într-o coadă se pot folosi variante diferite:
• Job-ul este trimis gazdei cu încărcarea cea mai mică. Parametrul de încărcare poate fi definit astfel încât să ţină cont de performanţele gazdei;
• Administratorul defineşte ordinea în care vor fi selectate cozile.

Atât timp cât un job nu a fost încă alocat unei cozi (se află în pending queue), utilizatorul poate modifica cererea privind necesarul de resurse, iar administratorul poate modifica prioritatea sa.

Prezentarea necesarului de resurse

CODINE presupune că un job poate fi executat pe orice gazdă. În practică, cele mai multe job-uri impun îndeplinirea anumitor condiţii, înainte de a fi executate: memorie suficientă, un anumit software, sau un anumit sistem de operare – acestea sunt cereri hard. Există şi cereri soft, a căror îndeplinire nu condiţionează lansarea în execuţie a job-ului. De asemenea, şi administratorul sistemului (clusterului) poate să impună anumite restricţii în utilizarea maşinilor. De exemplu, se poate restricţiona timpul CPU.

Tot ceea ce trebuie să facă utilizatorul este să specifice, în general, necesităţile job-ului, lăsând sistemului CODINE sarcina să identifice o gazdă potrivită.

Cererea de resurse se completează printr-un dialog REQUESTED RESOURCES, în fereastra Job Submission. O cerere echivalentă se poate lansa şi cu o linie de comandă:

%qsub –l natran, arch=irx6, h_cpu=6:0:0 –soft –l h_rss=80M nastran.sh

Cum procesează sistemul cererea de resurse şi cum sunt acestea alocate ?

După ce s-au colectat toate cererile, acestea sunt evaluate. Se începe cu cererile hard, care sunt alocate. Dacă o cerere nu este validă, introducerea job-ului în sistem este anulată. Dacă o cerere nu poate fi satisfăcută, job-ul este trecut în aşteptare, urmând ca cere rea sa să fie reanalizată ulterior. Dacă toate cererile hard pot fi îndeplinite, resursele sunt alocate şi job-ul poate fi lansat în execuţie.

Resursele soft sunt numai verificate, deoarece un job poate fi executat chiar şi atunci când o parte din ele, sau toate, nu poate (pot) fi satisfăcută (-e). Dacă există mai multe cozi care satisfac cerinţele hard, se va alege cea care îndeplineşte un număr mai mare de cerinţe soft.

Pentru executarea job-urilor paralele, CODINE foloseşte medii de tip message passing ca PVM, sau MPI. Se pot configura mai multe medii paralele (PE – Parallel Environment).

Este important să se aleagă o interfaţă PE potrivită pentru un job paralel. Acestea pot să nu utilizeze sisteme cu transfer de mesaje, sau sisteme diferite, pot aloca procesele pe o singură gazdă sau pe mai multe. De asemenea, accesul la PE poate fi interzis anumitor utilizatori, numai un anumit set de cozi poate fi folosit de un PE şi numai un anumit număr de sloturi poate fi ocupat în orice moment.

GRD – Global Resource Director

GRD a fost realizat prin integrarea unor produse de la trei firme diferite, Raytheon E-Systems care a contribuit cu un nou planificator şi o componentă pentru echilibrarea dinami că a încărcării (Global Dynamic Scheduler), Genias Sofware cu Codine şi Instrumental cu un colector dinamic de informaţii privind performanţele sistemului. Putem spune că, în acest caz, Codine este nucleul GRD. De aceea, sistemul îşi păstrează arhitectura, ca şi conceptele de bază. Noutatea constă în actualizarea continuă a datelor, privind performanţele sistemului şi replanificarea dinamică a job-urilor (un mod de echilibrare dinamică).

Planificarea job-urilor se execută la intervale fixe de timp ( de la 15 sec până la 2 min., funcţie de configuraţie). Atunci, planificatorul determină importanţa relativă a job-urilor din cozile de aşteptare şi a celor în execuţie, ca şi necesarul lor de resurse. De asemenea, clasifică gazdele pentru a determina care gazdă va primi, în acest interval, primul job, care al doilea ş.a.m.d. Un factor important în ordonarea maşinilor este încărcarea lor. Apoi, GRD lansează în execuţie job-uri noi, suspendă unele job-uri, creşte sau scade cantitatea de resurse alocate job-urilor în execuţie, sau menţine status quo-ul.

Daca se foloseşte algoritmul de planificare cu partajare, calculul ţine cont de utilizarea consumată a resurselor de către acel job, utilizator sau departament. Dacă nu, se clasifică toate job-urile în execuţie sau aşteptare şi se execută în ordinea priorităţilor.

Strategia de planificare a job-urilor, folosită de GRD, se exprimă ca o combinaţie ponderată a patru algoritmi, dintre care primii doi sunt de rutină:
• Pe baza partajării;
• Funcţional;
• Cu termen de încheiere;
• Override.

Algoritmul, care se bazează pe conceptul de partajare, încearcă să aloce fiecărui utilizator partea de resurse la care este îndreptăţit, în cursul unui interval de timp prestabilit. Realizează acest lucru prin ajustarea continuă a cantităţii de resurse alocată pentru intervalul care urmează. Acest mod de planificare, cu feed-back, se defineşte la ni vel de utilizator, sau proiect, dar niciodată simultan.

Planificarea funcţională, sau cu priorităţi, asociază importanţa unui job cu utilizatorul său, proiectul, departamentul sau clasa din care face parte. În cadrul acestei politici se foloseşte şi partajarea. Astfel, dacă un utilizator X are 200 părţi, iar Y are numai 100, job-ul lansat de X va avea un număr dublu de bilete faţă de job-ul lansat de Y.

GRD este setat să folosească fie o politică bazată pe partajare, fie funcţională, fie amândouă. Ele pot fi combinate în orice proporţie, cu ponderi de la 0 la 1. În afara acestor poli tici de rutină, se pot lansa în execuţie job-uri cu termene de încheiere. Administratorii şi operatorii pot creşte (override) în mod temporar importanţa unui job, proiect sau utilizator, fără a influenţa configuraţia de ansamblu a sistemului. În plus, un utilizator îşi poate stabili el priorităţile între job-urile sale. El poate stabili că, de exemplu, job-ul 5 este cel mai important, iar celelalte 4 sunt de aceeaşi importanţă, mai mică decât a job-ului 5.

Politicile de planificare se implementează cu bilete. Fiecare algoritm are un pool de bilete, de unde alocă bilete job-urilor sosite în sistem. De exemplu, dacă pentru algoritmul cu partajare sunt alocate 1000 bilete şi nu există un istoric al execuţiei, job-ul unui utilizator, care are alocat 1% din sistem, va primi 10 bilete. Pentru un utilizator cu 5%, se vor aloca 50 bilete. Fiecare politică activă alocă un număr de bilete fiecărui job nou. Prin bilete se măsoară ponderea fiecărei politici. De exemplu, dacă algoritmii funcţional şi pe baza partajării au un număr egal de bilete, ambii vor determina în mod egal importanţa unui job. Apoi, unui job i se pot aloca noi bilete pentru a indica un termen apropiat sau o importanţă sporită. Fiecare job în execuţie poate câştiga bilete, în situaţia expusă anterior, pierde bilete, de exemplu, deoarece a folosit mai mult decât îi este partea, sau poate păstra acelaşi număr de bilete în cursul fiecărui interval de planificare. Când un job părăseşte sistemul, biletele sale acordate de politicile de partajare şi funcţională sunt returnate în mod cores punzător, în timp ce biletele alocate pentru override sau îndeplinirea unui termen sunt pur şi simplu eliminate – încă o expresie a caracterului dinamic al sistemului de planificare.

SPINEware

SPINEware a fost realizat la Laboratorul naţional aero-spaţial olandez (NRL) cu scopul principal de a crea un software distribuit care să adapteze infrastructura de calcul nevoilor unui inginer proiectant. Evident, necesitatea sa a fost impusă de situaţia actuală, când inginerul trebuie să se adapteze el la o structură de calcul în permanentă evoluţie şi din care nu foloseşte decât un anumit procentaj.

SPINEware permite dezvoltarea şi utilizarea operaţională a unor medii de lucru ce pot fi atât generale, cât şi specifice, plasate pe reţele de calculatoare. Utilizatorul primeşte din reţea instrumente (tools), programe, date şi documentaţie, ca şi cum ar fi furnizate de un singur calculator. El creează, într-o fereastră grafică, prin drag-and-drop aplicaţia sa, o lansează în execuţie, o salvează, o poate relua, fără a şti sau avea nevoie să cunoască pe ce maşini se află plasate componentele aplicaţiei sale. Primul mediu de lucru creat a fost pentru simularea numerică a curgerii fluidelor (CFD), într-o reţea formată dintr-un supercalculator (NEC SX4), mainframes, servere şi mai mult de 1000 staţii de lucru, PC-uri şi terminale

SPINEware permite utilizarea instrumentelor native (specifice sistemului de opera re), comerciale împreună cu cele create de către utilizator. Există un editor gra fic care permite scrierea de tools wrappers, fără a fi deci nevoie de a scrie scripturi shell. Aceste interfeţe sunt utile la mascarea detalii lor specifice privind activarea instrumentelor native şi permit utilizatorului activarea instrumentelor într-un mod uniform.

De asemenea, produsul are o componentă puternică pentru gestiunea informaţiei la nivel de directoare şi fişiere, organizarea şi manipularea fişierelor de date, a formelor electronice cât şi verificarea versiunii soft-ului.

Toate componentele enumerate sunt conectate prin middleware cu resursele de calcul şi de informaţie disponibile în reţea, formând astfel un tot unitar, care ar putea fi considerat sistemul de operare al "metacalculatorului". Sarcina principală a middleware-ului este de a gestiona resursele disponibile, astfel încât să se asigure un mo del de calculator unic, ale cărui resurse (în reţea) sunt exploatate la maximum.

La acest sistem nu este vorba numai despre o gestiune omogenă şi unică a resurselor unei reţele eterogene, ci de o filozofie nouă care încearcă să realizeze o adaptare a organizaţiei la realităţile vieţii [4].

Pentru a face faţă competiţiei globale, o întreprindere trebuie să-şi crească în permanenţă know-how-ul, capacitatea de a utiliza această cunoaştere într-un mod flexibil în procesul de producţie şi, la un nivel superior, dobândirea de know-why pentru a asigura posibilitatea întreprinderii de a se adapta unui mediu în schimbare.

Combinaţia dintre know-how, know-why şi aplicarea acestora reprezintă competenţa întreprinderii. Adaptarea rapidă la schimbare înseamnă:
• Atragerea persoanelor potrivite;
• Instruirea şi perfecţionarea forţei de muncă;
• Introducerea unui stil de lucru în întreprindere, orientat spre competenţă şi crearea unor instrumente specifice.

În timp ce întreprinderile caută continuu ingineri competenţi, aceştia caută şi ei locuri de muncă, care să le crească valoarea de piaţă. Situaţia care se obţine este una a unei fluctuaţii permanente a forţei de muncă. Poziţia întreprinderii este dictată de sinergia dintre competenţa individuală a inginerilor şi competenţa acumulată în întreprindere. Dacă mai de mult, competenţa întreprinderii era conservată prin stabilitatea forţei de muncă, acum ea trebuie conservată prin mijloace informatice – software, date, documente, organizate în mod corespunzător. Iată una din aplicaţiile posibile ale unui produs ca SPINEware, crearea, conservarea şi dezvoltarea competenţei întreprinderii. Rezultatul este oarecum neaşteptat, dacă ţinem cont că s-a plecat din domeniul calculului de înaltă performanţă (paralel şi distribuit) şi s-a ajuns şi la gestiunea calităţii.

Bibliografie

[1] Codine User’s Guide

[2] GRD User’s Guide

[3] E. Baalberg, SPINEware: a practical and holistic approach to metacomputing, in P.Sloot, M.Bubak, B.Hertzberger (editori), High-Performance Computing and Networking, HPCN Europe 1998, Springer verlag 1998, p.1008-1011.

[4] W.Loeve si M.E.S. Vogels, Competence management in engineering environments with HPCN, in P.Sloot, M.Bubak, B.Hertzberger (editori), High-Performance Computing and Networking, HPCN Europe 1998, Springer verlag 1998, p.13-22.