DIET
 | |
| Utvecklare | INRIA , École Normale Supérieure de Lyon , SysFera , CNRS , Claude Bernard University Lyon 1 |
|---|---|
| Stabil frisättning | 2,8 / 14/11/11 |
| Skrivet i | C++ , CORBA |
| Operativ system | Cross-plattform |
| Typ | Grid och Cloud computing |
| Licens | CeCILL |
| Hemsida | |
DIET är en programvara för grid-computing . Som mellanprogram sitter DIET mellan operativsystemet (som hanterar detaljerna i hårdvaran ) och applikationsmjukvaran (som hanterar den specifika beräkningsuppgiften). DIET skapades 2000. Den designades för högpresterande datoranvändning. Den är för närvarande utvecklad av INRIA , École Normale Supérieure de Lyon , CNRS , Claude Bernard University Lyon 1, SysFera. Det är programvara med öppen källkod som släpps under CeCILL -licensen.
Precis som NetSolve/GridSolve och Ninf är DIET kompatibel med GridRPC- standarden från Open Grid Forum .
Målet med DIET-projektet är att utveckla en uppsättning verktyg för att bygga beräkningsservrar. De distribuerade resurserna hanteras på ett transparent sätt genom mellanvaran. Det kan fungera med arbetsstationer, kluster , rutnät och moln .
DIET används för att hantera Décrypthon Grid installerat av IBM vid sex franska universitet ( Bordeaux 1 , Lille 1 , Paris 6 , ENS Lyon, Crihan i Rouen, Orsay ).
Arkitektur
Vanligtvis har GridRPC-miljöer fem olika komponenter: klienter som skickar problem till servrar, servrar som löser problemen som skickas av klienter, en databas som innehåller information om mjukvaru- och hårdvaruresurser, en schemaläggare som väljer en lämplig server beroende på vilket problem som skickas och information som finns i databasen, och monitorer som får information om status för beräkningsresurserna.
DIETs arkitektur följer en annan design. Den består av:
- en klient - applikationen som använder DIET för att lösa problem. Klienter kan ansluta till DIET från en webbsida eller via ett API eller kompilerat program.
- en Master Agent (MA) som tar emot beräkningsförfrågningar från klienter. MA samlar sedan in beräkningsförmåga från servrarna och väljer en baserat på schemaläggningskriterier. Referensen för den valda servern returneras till klienten. En klient kan anslutas till en MA via en specifik namnserver eller en webbsida som lagrar de olika MA-platserna.
- en lokal agent (LA) som syftar till att överföra förfrågningar och information mellan MA och servrar. Informationen som lagras på en LA är listan över förfrågningar och, för vart och ett av dess underträd, antalet servrar som kan lösa ett givet problem och information om data som distribueras i detta underträd. Beroende på den underliggande nätverkstopologin kan en hierarki av LA:er distribueras mellan en MA och servrarna.
- en Server Daemon (SeD) som är ingångspunkten för en beräkningsserver. Den hanterar en processor eller ett kluster. Informationen som lagras på en SeD är listan över de data som finns tillgängliga på en server (eventuellt med deras distribution och sättet att komma åt dem), listan över problem som kan lösas på den, och all information om dess belastning (t.ex. , CPU-kapacitet, tillgängligt minne).
Multi-hierarki
Två tillvägagångssätt utvecklades:
- en multi-MA-förlängning utvecklades av University of Franche-Comté . Dessa masteragenter är sammankopplade med en kommunikationsgraf. Flera DIET-plattformar delas genom att sammankoppla deras respektive Master Agent (MA). Kunder begär tillgängliga SeDs från sin MA som vanligt. Om MA hittar en tillgänglig SeD som kan lösa problemet, returnerar den sin referens till klienten. Om den inte hittar en SeD, vidarebefordrar den förfrågan till andra MA som också kan vidarebefordra den till andra, och så vidare. När en MA hittar en SeD som kan lösa klientens begäran, returnerar den sin referens till klientens MA som returnerar referensen till klienten. Klienten kan sedan använda den SeD för att lösa sitt problem.
- en P2P Multi-MA-tillägg kallad DIET_j designades också. Aggregeringen av olika oberoende DIET-hierarkier (en multi-hierarki-arkitektur) skulle kunna hanteras med hjälp av P2P-paradigmet. Detta tillvägagångssätt baserades på JXTA - J2SE -verktygslådan för upptäckt och anslutning av MAs på begäran. Detta projekt underhålls inte längre.
Arbetsflödeshantering
För arbetsflödeshantering använder DIET ytterligare en enhet som kallas MA DAG . Denna entitet kan arbeta i två lägen: en där den definierar en fullständig schemaläggning av arbetsflödet (beställning och mappning), och en där den endast definierar en beställning för arbetsflödets exekvering. Mappningen görs sedan i nästa steg av klienten, med hjälp av Master Agent för att hitta servern där arbetsflödestjänsterna ska köras.
Schemaläggning
DIET ger en viss grad av kontroll över schemaläggningsundersystemet via plug-in schemaläggare. När en tjänsteförfrågan från en applikation anländer till en SeD, skapar SeD:n en prestationsuppskattningsvektor, en samling prestandauppskattningsvärden som är relevanta för schemaläggningsprocessen för den applikationen. Värdena som ska lagras i denna struktur kan antingen vara värden som tillhandahålls av CoRI (Collectors of Resource Information) eller anpassade värden som genereras av SeD själv. Utformningen av uppskattningsvektorns delsystem är modulär.
CoRI genererar en grundläggande uppsättning prestandauppskattningsvärden som lagras i uppskattningsvektorn och identifieras av systemdefinierade taggar. Information som antalet kärnor, det totala minnet, antalet bogomips och hårddiskhastighet, etc., som är statiska, såväl som dynamisk information som den förutsagda tiden för att lösa ett problem på den givna resursen, den genomsnittliga CPU:n load, överförs således från Server Daemon till schemaläggningsagenten för att tillhandahålla relevant information för en bättre schemaläggning. Som nämnts ovan används dessa i samband med den applikationsdrivna schemaläggningsmöjligheten i DIET: Server Daemon, som har en bättre förståelse för applikationsbehoven, kan begära ett specifikt schemaläggningsförmedling av informationen som lagras i denna vektor.
DIET datahantering
Tre olika datahanterare har integrerats i DIET:
- DTM från University of Franche-Comté (upprätthålls ej);
- JuxMEM från IRISA (upprätthålls ej);
- DAGDA från École Normale Supérieure de Lyon .
DIET LRMS-hantering
Parallella resurser är generellt tillgängliga via ett LRMS (Local Resource Management System), även kallat ett batchsystem. DIET tillhandahåller ett gränssnitt med flera befintliga LRMS för att utföra jobb: LoadLeveler (på IBM-resurser), OpenPBS (en gaffel av det välkända PBS- systemet) och OAR (batchschemaläggaren som används av Grid'5000 -forskningsnätet, utvecklat av IMAG i Grenoble). De flesta av de inlämnade jobben är parallella jobb, kodade med MPI-standarden med en instansiering som MPICH eller LAM.
Cloud-resurshantering
En molntillägg för DIET skapades 2009. DIET kan alltså komma åt molnresurser genom två befintliga molnleverantörer:
- Eucalyptus , som är öppen källkod som utvecklats av University of California, Santa Barbara .
- Amazon Elastic Compute Cloud , som är en kommersiell mjukvarudel av Amazon.com:s cloud computing-tjänster.