GridRPC

GridRPC i distribuerad datoranvändning är Remote Procedure Call över ett rutnät . Detta paradigm har föreslagits av GridRPC-arbetsgruppen för Open Grid Forum (OGF), och ett API har definierats för att klienter ska kunna komma åt fjärrservrar lika enkelt som ett funktionsanrop. Den används bland många Grid- mellanprogram för sin enkelhet i implementeringen och har standardiserats av OGF 2007. Av interoperabilitetsskäl mellan de olika befintliga mellanvarorna har API:et följts av ett dokument som beskriver bra användning och beteende hos de olika GridRPC API:erna implementeringar. Arbete har sedan bedrivits med GridRPC Data Management, som standardiserades 2011.

Omfattning

Omfattningen av denna standard är att erbjuda rekommendationer för implementering av middleware . Den behandlar följande ämnen:

  • Definition av en specifik datastruktur för argument i GridRPC-mellanprogramvara.
  • Definition av datatypen som ska användas tillsammans med argumentens datastruktur.
  • Definition av semantik för skapande, förstörelse, livslängd och kopiering för argumentens datastruktur.
  • Definition av möjliga introspektionsmöjligheter för anropsargument och attribut för fjärrfunktioner (t.ex. datatyper, räkningar).
  • Definition av mekanismer för att hantera beständiga data, t.ex. definition och användning av ett begrepp som "datahanterare" (vilket kan vara samma som eller liknar en grpc_data_t-datatyp). Detta kan också involvera begrepp som lazy copy- semantik och dataleasing eller time-out.
  • Definition av API-mekanismer för att möjliggöra arbetsflödeshantering .
  • Utvärdera kompatibiliteten och interoperabiliteten med andra system, t.ex. Web Services Resource Framework .
  • Önskvärda egenskaper – den föreslagna rekommendationen kommer inte nödvändigtvis att specificera några egenskaper, såsom gängsäkerhet, säkerhet och feltolerans, men den bör inte vara oförenlig med sådana användbara egenskaper.
  • Demonstrera implementerbarhet för alla delar av API:et.
  • Demonstrera och utvärdera minst två implementeringar av den kompletta GridRPC-rekommendationen för mellanprogram.

Sammanhang

Bland befintliga tillvägagångssätt för mellanprogram och applikationsprogrammering består ett enkelt, kraftfullt och flexibelt tillvägagångssätt i att använda servrar tillgängliga i olika administrativa domäner genom det klassiska klient-server- eller Remote Procedure Call- paradigmet (RPC). Network Enabled Servers (NES) implementerar denna modell, som också kallas GridRPC. Klienter skickar beräkningsförfrågningar till en resursmäklare vars mål är att hitta en server tillgänglig på Grid. Schemaläggning tillämpas ofta för att balansera arbetet mellan servrarna och en lista över tillgängliga servrar skickas tillbaka till klienten; klienten kan sedan skicka data och begäran till en av de föreslagna servrarna för att lösa sitt problem. Tack vare den ökade nätverksbandbredden och minskningen av nätverkslatens, kan små beräkningsförfrågningar nu skickas till servrar som är tillgängliga på Grid. För att effektivt kunna använda dagens skalbara resursplattformar är det viktigt att säkerställa skalbarhet även i mellanvaruskikten. Detta serviceinriktade synsätt är inte nytt.

Flera forskningsprojekt har tidigare inriktat sig på detta paradigm. Den huvudsakliga mellanvaran som implementerar API:t är DIET, NetSolve/GridSolve, Ninf, men vissa andra miljöer använder det som SAGA- gränssnittet från OGF och utan de standardiserade API-anropen, som OmmiRPC, XtremWeb. RPC-modellen över internet har också använts för flera applikationer. Genomskinligt via Internet kan stora optimeringsproblem lösas med hjälp av olika tillvägagångssätt genom att helt enkelt fylla en webbsida för fjärrbildbehandlingsberäkningar, användning av matematiska bibliotek eller studier om heuristik och upplösningsmetoder för gles linjär algebra som GridTLSE. Detta tillvägagångssätt att tillhandahålla beräkningstjänster via Internet ligger också mycket nära Service Oriented Computing) och är kärnan i molnberäkningen .

Standardisering och GridRPC API presentation

Ett enkelt men ändå effektivt sätt att utföra jobb på ett datorrutnät är att använda en GridRPC-mellanvara, som förlitar sig på GridRPC-paradigmet. För varje begäran hanterar GridRPC-mellanvaran hanteringen av inlämningen, av in- och utdata, av utförandet av jobbet på fjärrresursen, etc. För att göra en tjänst tillgänglig måste en programmerare implementera två koder: en klient, där data definieras och som körs av användaren när tjänsten begärs, och en server som innehåller implementeringen av tjänsten som exekveras på fjärrresursen.

Ett steg för att underlätta utvecklingen av sådana koder som utförs för att definiera ett GridRPC API, vilket har föreslagits som ett utkast i november 2002 och som är en Open Grid Forum (OGF)-standard sedan september 2007. Alltså en GridRPC-källkod som inte involverar specifik mellanprogramsdata kan kompileras och exekveras med vilken GridRPC-kompatibel mellanvara som helst.

På grund av skillnaden i valet av implementering av GridRPC API, har ett dokument som beskriver interoperabiliteten mellan GridRPC mellanprogram också skrivits. Dess huvudsakliga mål är att beskriva skillnaden i beteende hos GridRPC-mellanvaran och att föreslå ett gemensamt test som all GridRPC-mellanvara måste klara.

Diskussioner har sedan förts om datahanteringen inom GridRPC middleware. Ett utkast till ett API har föreslagits under OGF'21 i oktober 2007. Motivet för detta dokument är att tillhandahålla explicita funktioner för att manipulera datautbytet mellan en GridRPC-plattform och en klient eftersom (1) storleken på de data som används i nätapplikationer kan vara stora och värdelösa dataöverföringar måste undvikas; (2) data lagras inte alltid på klientsidan utan kan göras tillgänglig antingen på en lagringsresurs eller inom GridRPC-plattformen. En bieffekt är därför att en helt GridRPC-kompatibel kod kan skrivas och kompileras med vilken GridRPC-mellanvara som helst som implementerar GridRPC Data Management API.

GridRPC Paradigm

GridRPC paradigm

GridRPC-modellen visas i följande figur. Så här hanteras kommunikation: (1) servrar registrerar sina tjänster till ett register; (2) när en klient behöver utföra en tjänst kontaktar den registret och (3) registret returnerar ett handtag till klienten; (4) sedan använder klienten handtaget för att anropa tjänsten på servern och (5) får så småningom tillbaka resultaten.

GridRPC API

Mekanismer som är involverade i API:n måste tillhandahålla medel för att göra synkrona och/eller asynkrona anrop till en tjänst. Om det senare är så måste klienterna också kunna vänta på ett blockerande eller icke-blockerande sätt efter att en given tjänst har slutförts. Detta involverar naturligtvis vissa datastrukturer och leder till en rigorös definition av funktionerna hos API.

GridRPC-datatyper

Tre huvuddatatyper behövs för att implementera API:et: (1) grpc_function_handle_t är den typ av variabler som representerar en fjärrfunktion bunden till en given server. När den väl tilldelats av klienten kan en sådan variabel användas för att starta tjänsten så många gånger som önskas. Det ogiltigförklaras uttryckligen av användaren när det inte behövs längre; (2) grpc_session_t är den typ av variabler som används för att identifiera ett specifikt icke-blockerande GridRPC-anrop. En sådan variabel är obligatorisk för att få information om status för ett jobb, för att en klient ska vänta efter, avbryta eller veta felstatusen för ett samtal; (3) grpc_error_t grupperar alla typer av fel och returnerar statuskoder som är involverade i GridRPC API.

GridRPC-funktioner

grpc_initialize() och grpc_finalize() liknar MPI- initierings- och slutföranropen. Det är obligatoriskt att alla GridRPC-anrop utförs mellan dessa två samtal. De läser konfigurationsfiler, gör GridRPC-miljön redo och avslutar den.

För att initiera och förstöra ett funktionshandtag måste funktionerna grpc_function_handle_init() och grpc_function_handle_destruct() anropas. Eftersom ett funktionshandtag dynamiskt kan associeras med en server, på grund av resursupptäcktsmekanismer till exempel, kan ett anrop till grpc_function_handle_default() skjuta upp servervalet tills det faktiska anropet görs på handtaget.

grpc_get_handle() låter klienten hämta funktionshandtaget som motsvarar ett sessions-ID ( t.ex. ett icke-blockerande samtal) som tidigare har utförts.

Beroende på typen av samtal, blockering eller icke-blockering, kan klienten använda funktionen grpc_call() och grpc_call_async() . Om det sistnämnda, har klienten efter samtalet ett sessions-ID som kan användas för att avsöka respektive vänta på slutförande, avbryta samtalet och kontrollera felstatusen för ett icke-blockerande samtal.

Efter att ha utfärdat ett unikt eller många icke-blockerande samtal kan en klient använda: grpc_probe() för att veta om exekveringen av tjänsten har slutförts; grpc_probe_or() för att veta om ett av de tidigare icke-blockerande anropen har slutförts; grpc_cancel() för att avbryta ett samtal; grpc_wait() för att blockera tills slutförandet av den begärda tjänsten; grpc_wait_and() för att blockera tills alla tjänster som motsvarar sessions-ID:n som används som parametrar är klara; grpc_wait_or() för att blockera tills någon av tjänsterna som motsvarar sessions-ID:n som används som parametrar har avslutats; grpc_wait_all() för att blockera tills alla icke-blockerande samtal har slutförts; och grpc_wait_any() för att vänta tills någon tidigare utfärdad icke-blockerande begäran har slutförts.

GridRPC-kompatibel kod

Tala om lib (+länk) som en kod måste kompilera mot och ge ett grundläggande exempel

GridRPC-dokument

  • GridRPC-modell och API för slutanvändarapplikationer . OGF-referens: GFD-R.52 (2007)
  • Interoperabilitetstestning för GridRPC API-specifikationen . OGF-referens: GFD.102 (2007)
  • Data Management API inom GridRPC . OGF-referens: GFD-RP.186 (2011)

GridRPC implementeringar

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=GridRPC&oldid=1113888375 "