DIETA
 | |
| Deweloperzy | INRIA , École Normale Supérieure de Lyon , SysFera , CNRS , Claude Bernard University Lyon 1 |
|---|---|
| Wersja stabilna | 2.8 / 11/14/11 |
| Napisane w | C++ , CORBA |
| System operacyjny | Międzyplatformowe |
| Typ | sieciowe i chmurowe |
| Licencja | CeCILL |
| Strona internetowa | |
DIET to oprogramowanie do obliczeń gridowych . Jako oprogramowanie pośrednie DIET znajduje się pomiędzy systemem operacyjnym (który obsługuje szczegóły sprzętu ) a oprogramowaniem aplikacyjnym (które zajmuje się konkretnym zadaniem obliczeniowym). DIET powstał w 2000 roku. Został zaprojektowany z myślą o obliczeniach o dużej wydajności. Obecnie jest rozwijany przez INRIA , École Normale Supérieure de Lyon , CNRS , Claude Bernard University Lyon 1 , SysFera. Jest to oprogramowanie typu open source wydane na licencji CeCILL .
Podobnie jak NetSolve/GridSolve i Ninf, DIET jest zgodny ze standardem GridRPC z Open Grid Forum .
Celem projektu DIET jest opracowanie zestawu narzędzi do budowy serwerów obliczeniowych. Rozproszone zasoby są zarządzane w przejrzysty sposób poprzez oprogramowanie pośredniczące. Może współpracować ze stacjami roboczymi, klastrami , siatkami i chmurami .
DIET służy do zarządzania siatką Décrypthon Grid zainstalowaną przez IBM na sześciu francuskich uniwersytetach ( Bordeaux 1 , Lille 1 , Paris 6 , ENS Lyon, Crihan w Rouen, Orsay ).
Architektura
Zazwyczaj środowiska GridRPC składają się z pięciu różnych komponentów: klientów zgłaszających problemy do serwerów, serwerów rozwiązujących problemy przesłane przez klientów, bazy danych zawierającej informacje o zasobach programowych i sprzętowych, harmonogramu, który wybiera odpowiedni serwer w zależności od przesłanego problemu oraz informacje zawarte w bazie danych oraz monitory, które uzyskują informacje o stanie zasobów obliczeniowych.
Architektura DIET ma inny projekt. Jest to złożone z:
- klient - aplikacja wykorzystująca DIET do rozwiązywania problemów. Klienci mogą łączyć się z DIET ze strony internetowej, interfejsu API lub skompilowanego programu.
- agent główny (MA), który odbiera żądania obliczeń od klientów. Następnie MA zbiera zdolności obliczeniowe z serwerów i wybiera jeden na podstawie kryteriów planowania. Referencja wybranego serwera jest zwracana klientowi. Klient może być połączony z MA przez określony serwer nazw lub stronę internetową, która przechowuje różne lokalizacje MA.
- lokalny agent (LA), którego celem jest przekazywanie żądań i informacji między MA a serwerami. Informacje przechowywane w LA to lista żądań i dla każdego z jego poddrzew liczba serwerów, które mogą rozwiązać dany problem oraz informacja o danych rozproszonych w tym poddrzewie. W zależności od podstawowej topologii sieci, hierarchia LA może zostać wdrożona między MA a serwerami.
- demon serwera (SeD), który jest punktem wejścia do serwera obliczeniowego. Zarządza procesorem lub klastrem. Informacje przechowywane na SeD to lista danych dostępnych na serwerze (ewentualnie wraz z ich rozmieszczeniem i sposobem dostępu do nich), lista problemów, które można na nim rozwiązać oraz wszelkie informacje dotyczące jego obciążenia (np. , pojemność procesora, dostępna pamięć).
Wielohierarchia
Opracowano dwa podejścia:
- rozszerzenie multi-MA zostało opracowane przez University of Franche-Comté . Ci agenci nadrzędni są połączeni grafem komunikacyjnym. Kilka platform DIET jest współużytkowanych przez połączenie ich odpowiednich głównych agentów (MA). Klienci jak zwykle zwracają się do swojego MA o dostępne SeD. Jeśli IZ znajdzie dostępne SeD zdolne do rozwiązania problemu, zwraca klientowi swoje referencje. Jeżeli nie znajdzie SeD, przekazuje wniosek do innych IZ, które mogą go również przekazać innym IZ itd. Gdy MA znajdzie SeD, który może rozwiązać żądanie klienta, zwraca swoje odwołanie do MA klienta, które zwraca odwołanie do klienta. Klient może następnie użyć tego SeD do rozwiązania swojego problemu.
- zaprojektowano również rozszerzenie P2P Multi-MA o nazwie DIET_j . Agregacją różnych niezależnych hierarchii DIET (architektura wielohierarchiczna) można zarządzać za pomocą paradygmatu P2P. Podejście to było oparte na JXTA - J2SE do wykrywania i łączenia MA na żądanie. Ten projekt nie jest już utrzymywany.
Zarządzanie przepływem pracy
Do zarządzania przepływem pracy DIET wykorzystuje dodatkową jednostkę o nazwie MA DAG . Ta jednostka może pracować w dwóch trybach: jednym, w którym definiuje pełne harmonogramowanie przepływu pracy (uporządkowanie i mapowanie), oraz drugim, w którym definiuje tylko kolejność wykonywania przepływu pracy. Mapowanie jest następnie wykonywane w kolejnym kroku przez klienta, przy użyciu agenta głównego w celu znalezienia serwera, na którym powinny zostać uruchomione usługi przepływu pracy.
Planowanie
DIET zapewnia pewien stopień kontroli nad podsystemem planowania za pomocą wtyczek do planowania. Kiedy żądanie usługi z aplikacji dociera do SeD, SeD tworzy wektor szacowania wydajności, zbiór wartości szacowania wydajności, które są istotne dla procesu planowania dla tej aplikacji. Wartości, które mają być przechowywane w tej strukturze, mogą być wartościami dostarczonymi przez CoRI (Collectors of Resource Information) lub wartościami niestandardowymi generowanymi przez samo SeD. Konstrukcja podsystemu wektora estymacji jest modułowa.
CoRI generuje podstawowy zestaw wartości oszacowania wydajności, które są przechowywane w wektorze oszacowania i identyfikowane przez znaczniki zdefiniowane przez system. Informacje takie jak liczba rdzeni, całkowita pamięć, liczba bogomipów, prędkość dysku twardego itp., które są statyczne, a także informacje dynamiczne, takie jak przewidywany czas rozwiązania problemu na danym zasobie, średni procesor obciążenie jest w ten sposób przesyłane z demona serwera do agenta programu planującego w celu dostarczenia odpowiednich informacji dla lepszego planowania. Jak wspomniano powyżej, są one używane w połączeniu z możliwością harmonogramu opartego na aplikacji w DIET: demon serwera, który lepiej rozumie potrzeby aplikacji, może zażądać określonego harmonogramu, przekazując informacje przechowywane w tym wektorze.
Zarządzanie danymi DIET
W DIET zintegrowano trzy różne menedżery danych:
- DTM z Uniwersytetu Franche-Comté (nieobsługiwany);
- JuxMEM z IRISA (nieobsługiwany);
- DAGDA z École Normale Supérieure de Lyon .
Zarządzanie DIETĄ LRMS
Zasoby równoległe są generalnie dostępne poprzez LRMS (Local Resource Management System), zwany także systemem wsadowym. DIET zapewnia interfejs z kilkoma istniejącymi LRMS do wykonywania zadań: LoadLeveler (na zasobach IBM), OpenPBS (rozwidlenie dobrze znanego systemu PBS ) i OAR (harmonogram wsadowy używany przez grid badawczy Grid'5000 , opracowany przez IMAG w Grenoble). Większość przesłanych zadań to zadania równoległe, zakodowane przy użyciu standardu MPI z instancjami, takimi jak MPICH lub LAM.
Zarządzanie zasobami w chmurze
Rozszerzenie Cloud dla DIET zostało utworzone w 2009 roku. Dzięki temu DIET może uzyskiwać dostęp do zasobów Cloud za pośrednictwem dwóch istniejących dostawców Cloud:
- Eucalyptus , oprogramowanie typu open source opracowane przez Uniwersytet Kalifornijski w Santa Barbara .
- Amazon Elastic Compute Cloud , które jest komercyjnym oprogramowaniem będącym częścią usług przetwarzania w chmurze firmy Amazon.com .