Hispanopedia Wiki
Articulo de referencia

GridRPC

GridRPC, en computación distribuida , es una llamada a procedimiento remoto sobre una cuadrícula . Este paradigma fue propuesto por el grupo de trabajo GridRPC [ 1 ] del Open Gr...

Hispanopedia WikiContenido en espanolLectura gratuita

GridRPC, en computación distribuida , es una llamada a procedimiento remoto sobre una cuadrícula . Este paradigma fue propuesto por el grupo de trabajo GridRPC [ 1 ] del Open Grid Forum (OGF), y se definió una API [ 2 ] para que los clientes accedan a servidores remotos con la misma sencillez que una llamada a una función. Se utiliza en numerosos middlewares de cuadrícula por su simplicidad de implementación y fue estandarizado por el OGF en 2007. Para garantizar la interoperabilidad entre los diferentes middlewares existentes, la API fue seguida por un documento [ 3 ] que describe el buen uso y el comportamiento de las distintas implementaciones de la API GridRPC. Posteriormente, se trabajó en la gestión de datos de GridRPC [ 4 ] , que fue estandarizada en 2011.

Alcance

El objetivo de esta norma es ofrecer recomendaciones para la implementación de middleware . Aborda los siguientes temas:

  • Definición de una estructura de datos específica para los argumentos en el middleware GridRPC.
  • Definición del tipo de datos que se utilizará junto con la estructura de datos de los argumentos.
  • Definición de la semántica de creación, destrucción, ciclo de vida y copia para la estructura de datos de los argumentos.
  • Definición de las posibles capacidades de introspección para los argumentos de llamada y los atributos de las funciones remotas (por ejemplo, tipos de datos, recuentos).
  • Definición de mecanismos para el manejo de datos persistentes, por ejemplo, definición y uso de un concepto como "manejadores de datos" (que podrían ser iguales o similares a un tipo de datos grpc_data_t). Esto también puede incluir conceptos como la semántica de copia diferida y los arrendamientos o tiempos de espera de datos.
  • Definición de mecanismos API para habilitar la gestión del flujo de trabajo .
  • Evaluar la compatibilidad e interoperabilidad con otros sistemas, por ejemplo, Web Services Resource Framework .
  • Propiedades deseables: la recomendación propuesta no especificará necesariamente ninguna propiedad, como la seguridad de subprocesos , la protección y la tolerancia a fallos , pero no debería ser incompatible con ninguna de esas propiedades útiles.
  • Demostrar la viabilidad de la implementación de todas las partes de la API.
  • Demostrar y evaluar al menos dos implementaciones de la recomendación completa del middleware GridRPC.

Contexto

Entre los enfoques de programación de aplicaciones y middleware existentes, un enfoque simple, potente y flexible consiste en utilizar servidores disponibles en diferentes dominios administrativos mediante el paradigma clásico cliente-servidor o Llamada a Procedimiento Remoto (RPC). Los Servidores Habilitados para Red (NES) implementan este modelo, también llamado GridRPC. Los clientes envían solicitudes de computación a un intermediario de recursos cuyo objetivo es encontrar un servidor disponible en la Grid. La planificación se aplica frecuentemente para equilibrar la carga de trabajo entre los servidores y se envía una lista de servidores disponibles al cliente; este puede entonces enviar los datos y la solicitud a uno de los servidores sugeridos para resolver su problema. Gracias al aumento del ancho de banda de la red y la reducción de la latencia, ahora se pueden enviar pequeñas solicitudes de computación a servidores disponibles en la Grid. Para aprovechar eficazmente las plataformas de recursos escalables actuales, es importante garantizar también la escalabilidad en las capas de middleware. Este enfoque orientado a servicios no es nuevo.

Varios proyectos de investigación se han centrado en este paradigma en el pasado. El principal middleware que implementa la API es DIET, NetSolve/GridSolve, Ninf, pero otros entornos la utilizan como la interfaz SAGA de OGF, y sin las llamadas API estandarizadas, como OmmiRPC, XtremWeb. El modelo RPC sobre 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 completando una página web para cálculos de procesamiento de imágenes remotos, el uso de bibliotecas matemáticas o estudios sobre heurísticas y métodos de resolución para álgebra lineal dispersa como GridTLSE. [ 5 ] Este enfoque de proporcionar servicios de computación a través de Internet también está muy cerca del paradigma de Computación Orientada a Servicios (SOA) y es el núcleo de la computación en la nube .

Presentación sobre la estandarización y la API de GridRPC

Una forma sencilla pero eficaz de ejecutar tareas en una red de computación distribuida es mediante el middleware GridRPC, que se basa en el paradigma GridRPC. Para cada solicitud, el middleware GridRPC gestiona el envío, los datos de entrada y salida, la ejecución de la tarea en el recurso remoto, etc. Para que un servicio esté disponible, un programador debe implementar dos códigos: un cliente, donde se definen los datos y que el usuario ejecuta 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 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. De esta manera, un código fuente GridRPC que no involucre datos de middleware específicos puede compilarse y ejecutarse con cualquier middleware compatible con GridRPC.

Debido a las diferencias en la implementación de la API GridRPC, también se ha elaborado un documento que describe la interoperabilidad entre los middlewares de GridRPC. Sus principales objetivos son describir las diferencias de comportamiento de los middlewares de GridRPC y proponer una prueba común que todos ellos deben superar.

Posteriormente, se llevaron a cabo debates sobre la gestión de datos dentro del middleware de GridRPC. Durante el OGF'21, en octubre de 2007, se propuso un borrador de API. El objetivo de este documento es proporcionar funciones explícitas para manipular el intercambio de datos entre una plataforma GridRPC y un cliente, dado que (1) el volumen de datos utilizados en las aplicaciones de cuadrícula puede ser grande y deben evitarse las transferencias de datos innecesarias; (2) los datos no siempre se almacenan en el lado del cliente, sino que pueden estar disponibles en un recurso de almacenamiento o dentro de la plataforma GridRPC. Por lo tanto, como efecto secundario, se puede escribir y compilar código totalmente compatible con GridRPC con cualquier middleware de GridRPC que implemente la API de gestión de datos de GridRPC.

Paradigma GridRPC

paradigma GridRPC

El modelo GridRPC se muestra en la siguiente figura. Así es como se gestionan las comunicaciones: (1) los servidores registran sus servicios en un registro; (2) cuando un cliente necesita ejecutar un servicio, se comunica con el registro y (3) el registro devuelve un identificador al cliente; (4) el cliente utiliza el identificador para invocar el servicio en el servidor y (5) finalmente recibe los resultados.

API GridRPC

Los mecanismos de la API deben permitir realizar llamadas síncronas y/o asíncronas a un servicio. En este último caso, los clientes también deben poder esperar, de forma bloqueante o asíncrona, tras la finalización del servicio. Esto implica, naturalmente, ciertas estructuras de datos y requiere una definición rigurosa de las funciones de la API.

Tipos de datos de GridRPC

Se necesitan tres tipos de datos principales para implementar la API: (1) grpc_function_handle_t es el tipo de variable que representa una función remota vinculada a un servidor determinado. Una vez asignada por el cliente, dicha variable puede usarse para iniciar el servicio tantas veces como se desee. El usuario la invalida explícitamente cuando ya no es necesaria; (2) grpc_session_t es el tipo de variable que se utiliza para identificar una llamada GridRPC no bloqueante específica. Dicha variable es obligatoria para obtener información sobre el estado de un trabajo, de modo 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 de 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. Estas leen los archivos de configuración, preparan el entorno GridRPC y finalizan el proceso.

Para inicializar y destruir un identificador de función, es necesario llamar a las funciones grpc_function_handle_init() y grpc_function_handle_destruct() . Dado que un identificador de función puede asociarse dinámicamente a un servidor, por ejemplo, debido a mecanismos de detección de recursos, una llamada a grpc_function_handle_default() permite posponer la selección del servidor hasta que se realice la llamada real al identificador.

La función grpc_get_handle() permite al cliente recuperar el identificador de función correspondiente a un ID de sesión ( por ejemplo, a una llamada no bloqueante) que se haya realizado previamente.

Según el tipo de llamada, bloqueante o asíncrona, el cliente puede usar las funciones grpc_call() y grpc_call_async() . En el caso de esta última, tras la llamada, el cliente dispone de un ID de sesión que puede usar para comprobar o esperar a que finalice la llamada, cancelarla o verificar el estado de error de una llamada asíncrona.

Después de emitir una o varias llamadas no bloqueantes, un cliente puede usar: grpc_probe() para saber si la ejecución del servicio ha finalizado; grpc_probe_or() para saber si alguna de las llamadas no bloqueantes anteriores ha finalizado; grpc_cancel() para cancelar una llamada; grpc_wait() para bloquear hasta que finalice el 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 finalicen todas las llamadas no bloqueantes; y grpc_wait_any() para esperar hasta que finalice cualquier solicitud no bloqueante emitida previamente.

Código compatible con GridRPC

Habla sobre la biblioteca (+enlace) con la que debe compilarse un código y da un ejemplo básico.

Documentos de GridRPC

  • Modelo y API de GridRPC para aplicaciones de usuario final . Referencia OGF: GFD-R.52 (2007)
  • Pruebas de interoperabilidad para la especificación de la API GridRPC . Referencia OGF: GFD.102 (2007)
  • API de gestión de datos dentro de GridRPC . Referencia OGF: GFD-RP.186 (2011)

Implementaciones de GridRPC

Referencias

  1. ↑ "Áreas y grupos del foro Open Grid" . Archivado del original el 11 de agosto de 2011. Consultado el 23 de mayo de 2011 .
  2. ↑ "Un modelo y API GridRPC para aplicaciones de usuario final" (PDF) . Archivado del original (PDF) el 28 de septiembre de 2011. Consultado el 23 de mayo de 2011 .
  3. ↑ "Pruebas de interoperabilidad para la especificación de la API GridRPC" (PDF) . Archivado del original (PDF) el 10 de agosto de 2007.
  4. ↑ "API de gestión de datos dentro de GridRPC" (PDF) . Archivado del original (PDF) el 26 de junio de 2011.
  5. ↑ "¿Qué es GRID-TLSE ?" . Archivado del original el 13-07-2011 . Consultado el 23-05-2011 . 
  6. ↑ Seymour, Keyth; Nakada, Hidemoto; Matsuoka, S.; Dongarra, Jack; Lee, Craig; Casanova, Henri (noviembre de 2002). "Descripción general de GridRPC: una API de llamada a procedimiento remoto para computación en malla". Computación en malla — GRID 2002. Notas de clase en ciencias de la computación. Vol. 2536. págs. 274–278 . doi : 10.1007/3-540-36133-2_25 . ISBN   978-3-540-00133-1.
  7. ↑ Caron, Eddy; Desprez, Frédéric (2006). "DIET: Una caja de herramientas escalable para construir servidores habilitados para red en la cuadrícula". International Journal of High Performance Computing Applications . 20 (3): 335– 352. CiteSeerX 10.1.1.126.236 . doi : 10.1177/1094342006067472 . S2CID 1050715 .  
  8. ↑ Yarkhan, A.; K. Seymour; K. Sagi; Z. Shi; J. Dongarra (2006). "Desarrollos recientes en Gridsolve". International Journal of High Performance Computing Applications . 20 (1): 131– 141. CiteSeerX 10.1.1.62.3205 . doi : 10.1177/1094342006061893 . S2CID 3019675 .  
  9. ↑ Nakada, Hidemoto; Sato, Mitsuhisa; Sekiguchi, S (1999). "Diseño e implementaciones de Ninf: hacia una infraestructura informática global". Future Generation Computing Systems, Metacomputing Issue . 15 ( 5– 6): 649– 658. CiteSeerX 10.1.1.177.2195 . doi : 10.1016/s0167-739x(99)00016-3 . 
  10. ↑ Sato, M; Hirano, M; Tanaka, Y; Sekiguchi, S (2001). "OmniRPC: Una herramienta RPC para computación en clúster y global en OpenMP". OpenMP Shared Memory Parallel Programming . Lecture Notes in Computer Science. Vol. 2104. pp. 130–136 . CiteSeerX 10.1.1.28.7334 . doi : 10.1007/3-540-44587-0_12 . ISBN    978-3-540-42346-1.
  • El Grupo de Trabajo GridRPC