GridRPC en informática distribuida , es una llamada a procedimiento remoto sobre un grid . Este paradigma ha sido propuesto por el grupo de trabajo GridRPC [1] del Open Grid Forum (OGF), y se ha definido una API [2] para que los clientes accedan a servidores remotos tan simplemente como una llamada a función. Se utiliza entre numerosos middleware Grid por su sencillez de implementación, y ha sido estandarizado por la OGF en 2007. Por motivos de interoperabilidad entre los diferentes middleware existentes, a la API le ha seguido un documento [3] que describe el buen uso y comportamiento del mismo. diferentes implementaciones de API GridRPC. Posteriormente se trabajó en el sistema de gestión de datos GridRPC, [4] que fue estandarizado en 2011.
El alcance de este estándar es ofrecer recomendaciones para la implementación de middleware . Se trata de los siguientes temas:
Entre los enfoques existentes de programación de aplicaciones y middleware, un enfoque simple, potente y flexible consiste en utilizar servidores disponibles en diferentes dominios administrativos a través del paradigma clásico cliente-servidor o Llamada a procedimiento remoto (RPC). Los servidores habilitados para red (NES) implementan este modelo, que también se llama GridRPC. Los clientes envían solicitudes de cálculo a un intermediario de recursos cuyo objetivo es encontrar un servidor disponible en Grid. La programación se aplica con frecuencia para equilibrar el trabajo entre los servidores y se envía una lista de servidores disponibles al cliente; Luego, el cliente puede enviar los datos y la solicitud a uno de los servidores sugeridos para resolver su problema. Gracias al crecimiento del ancho de banda de la red y la reducción de la latencia de la red, ahora se pueden enviar pequeñas solicitudes de cálculo a los servidores disponibles en Grid. Para hacer un uso eficaz de las plataformas de recursos escalables actuales, es importante garantizar también la escalabilidad en las capas de middleware. Este enfoque orientado al servicio no es nuevo.
Varios proyectos de investigación se han centrado en este paradigma en el pasado. Los principales middleware que implementan la API son DIET, NetSolve/GridSolve, Ninf, pero algunos otros entornos la utilizan como la interfaz SAGA de OGF y sin las llamadas API estandarizadas, como OmmiRPC, XtremWeb. El modelo RPC en Internet también se ha utilizado para varias aplicaciones. De forma transparente a través de Internet, se pueden resolver grandes problemas de optimización utilizando diferentes enfoques, simplemente llenando una página web para cálculos de procesamiento remoto de imágenes, el uso de bibliotecas matemáticas o estudios sobre heurística y métodos de resolución para álgebra lineal dispersa como GridTLSE. [5] Este enfoque de proporcionar servicios informáticos a través de Internet también está muy cerca del paradigma de la Computación Orientada a Servicios (SOA) y es el núcleo de la computación en la nube .
Una forma simple, pero efectiva, de ejecutar trabajos en una red informática es utilizar un middleware GridRPC, que se basa en el paradigma GridRPC. Para cada solicitud, el middleware GridRPC gestiona la gestión del envío, de los datos de entrada y salida, de la ejecución del trabajo en el recurso remoto, etc. Para poner a disposición un servicio, un programador debe implementar dos códigos: un cliente, donde se definen los datos y que ejecuta el usuario al solicitar el servicio, y un servidor, que contiene la implementación del servicio que se ejecuta en el recurso remoto.
Un paso para facilitar el desarrollo de dichos códigos fue definir una API de GridRPC, que se propuso como borrador en noviembre de 2002 [6] y que es un estándar del Open Grid Forum (OGF) desde septiembre de 2007. Por lo tanto, se creó un código fuente de GridRPC que no implica middleware específico, los datos se pueden compilar y ejecutar con cualquier middleware compatible con GridRPC.
Debido a la diferencia en la elección de implementación de la API GridRPC, también se ha escrito un documento que describe la interoperabilidad entre el middleware GridRPC. Sus principales objetivos son describir la diferencia en el comportamiento del middleware GridRPC y proponer una prueba común que todo el middleware GridRPC debe pasar.
Luego se llevaron a cabo discusiones sobre la gestión de datos dentro del middleware GridRPC. Se propuso un borrador de una API durante el OGF'21 en octubre de 2007. La motivación de este documento es proporcionar funciones explícitas para manipular el intercambio de datos entre una plataforma GridRPC y un cliente desde (1) el tamaño de los datos utilizados en las aplicaciones grid pueden ser grandes y deben evitarse transferencias de datos inútiles; (2) los datos no siempre se almacenan en el lado del cliente, pero pueden estar disponibles en un recurso de almacenamiento o dentro de la plataforma GridRPC. Por lo tanto, un efecto secundario es que se puede escribir y compilar un código totalmente compatible con GridRPC con cualquier middleware GridRPC que implemente la API de administración de datos GridRPC.
El modelo GridRPC se muestra en la siguiente figura. Así es como se manejan las comunicaciones: (1) los servidores registran sus servicios en un registro; (2) cuando un cliente necesita la ejecución de un servicio, se comunica con el registro y (3) el registro devuelve un identificador al cliente; (4) luego el cliente usa el identificador para invocar el servicio en el servidor y (5) finalmente recibe los resultados.
Los mecanismos involucrados en la API deben proporcionar medios para realizar llamadas sincrónicas y/o asincrónicas a un servicio. En este último caso, los clientes también deben poder esperar de forma bloqueante o sin bloqueo después de completar un servicio determinado. Naturalmente, esto implica algunas estructuras de datos y conduce a una definición rigurosa de las funciones de la API.
Tipos de datos GridRPC
Se necesitan tres tipos de datos principales para implementar la API: (1) grpc_function_handle_t es el tipo de variables que representan una función remota vinculada a un servidor determinado. Una vez asignada por el cliente, dicha variable se puede utilizar para iniciar el servicio tantas veces como se desee. El usuario lo invalida explícitamente cuando ya no es necesario; (2) grpc_session_t es el tipo de variables utilizadas para identificar una llamada GridRPC sin bloqueo específica. Dicha variable es obligatoria para obtener información sobre el estado de un trabajo, para que un cliente pueda esperar, cancelar o conocer el estado de error de una llamada; (3) grpc_error_t agrupa todo tipo de errores y devuelve códigos de estado involucrados en la API GridRPC.
Funciones GridRPC
Las funciones grpc_initialize() y grpc_finalize() son similares a las llamadas de inicialización y finalización de MPI . Es obligatorio que cualquier llamada a GridRPC se realice entre estas dos llamadas. Leen los archivos de configuración, preparan el entorno GridRPC y lo finalizan.
Para inicializar y destruir un identificador de función, se deben llamar las funciones grpc_function_handle_init() y grpc_function_handle_destruct() . Debido a que un identificador de función se puede asociar dinámicamente a un servidor, debido a mecanismos de descubrimiento de recursos, por ejemplo, una llamada a grpc_function_handle_default() permite posponer la selección del servidor hasta que se realice la llamada real en el identificador.
grpc_get_handle() permite al cliente recuperar el identificador de función correspondiente a una ID de sesión ( por ejemplo, a una llamada sin bloqueo) que se ha realizado previamente.
Dependiendo del tipo de llamada, con o sin bloqueo, el cliente puede utilizar las funciones grpc_call() y grpc_call_async() . En este último caso, el cliente posee después de la llamada un ID de sesión que puede usarse para sondear o esperar a que se complete, cancelar la llamada y verificar el estado de error de una llamada sin bloqueo, respectivamente.
Después de emitir una o numerosas llamadas sin bloqueo, un cliente puede usar: grpc_probe() para saber si la ejecución del servicio se ha completado; grpc_probe_or() para saber si una de las llamadas sin bloqueo anteriores se ha completado; grpc_cancel() para cancelar una llamada; grpc_wait() para bloquear hasta la finalización del servicio solicitado; grpc_wait_and() para bloquear hasta que finalicen todos los servicios correspondientes a los ID de sesión utilizados como parámetros; grpc_wait_or() para bloquear hasta que finalice cualquiera de los servicios correspondientes a los ID de sesión utilizados como parámetros; grpc_wait_all() para bloquear hasta que se hayan completado todas las llamadas sin bloqueo; y grpc_wait_any() para esperar hasta que se haya completado cualquier solicitud sin bloqueo emitida previamente.
Hable sobre la biblioteca (+enlace) con la que se debe compilar un código y dé un ejemplo básico.
{{cite web}}: Mantenimiento CS1: copia archivada como título ( enlace ){{cite web}}: Mantenimiento CS1: copia archivada como título ( enlace )