WikiDer > GridRPC

GridRPC

GridRPC является Удаленный вызов процедур через сетка. Этот парадигма был предложен рабочей группой GridRPC [1] из Open Grid Forum (OGF) и API был определен[2] чтобы клиенты могли получить доступ к удаленным серверам так же просто, как вызов функции. Используется среди множества Grid промежуточное ПО из-за простоты реализации и был стандартизирован OGF в 2007 г. Из соображений совместимости между различным существующим промежуточным программным обеспечением API сопровождался документом[3] описание правильного использования и поведения различных реализаций GridRPC API. Затем были проведены работы на Управление данными GridRPC,[4] который был стандартизирован в 2011 году.

Объем

Целью настоящего стандарта является предложение рекомендаций по реализации промежуточное ПО. В нем рассматриваются следующие темы:

  • Определение конкретной структуры данных для аргументов в промежуточном программном обеспечении GridRPC.
  • Определение типа данных, который будет использоваться вместе со структурой данных аргументов.
  • Определение семантики создания, уничтожения, времени жизни и копирования для структуры данных аргументов.
  • Определение возможных возможностей самоанализа для аргументов вызова и атрибутов удаленных функций (например, типов данных, счетчиков).
  • Определение механизмов для обработки постоянных данных, например определение и использование такого понятия, как «дескрипторы данных» (которые могут быть такими же или похожими на тип данных grpc_data_t). Это также может включать такие концепции, как ленивая копия семантика и аренда данных или тайм-ауты.
  • Определение механизмов API для включения рабочий процесс управление.
  • Оценить совместимость и взаимодействие с другими системами, например, Структура ресурсов веб-служб.
  • Желаемые свойства - Предлагаемая рекомендация не обязательно будет определять какие-либо свойства, такие как безопасность потоков, безопасность и отказоустойчивость, но она не должна быть несовместима с такими полезными свойствами.
  • Продемонстрируйте реализуемость всех частей API.
  • Продемонстрируйте и оцените как минимум две реализации полной рекомендации по промежуточному программному обеспечению GridRPC.

Контекст

Среди существующих подходов к программированию промежуточного программного обеспечения и приложений один простой, мощный и гибкий подход состоит в использовании серверов, доступных в разных административных доменах через классический клиент-сервер или Удаленный вызов процедур (RPC) парадигма. Серверы с поддержкой сети (NES) реализуют эту модель, которая также называется GridRPC. Клиенты отправляют запросы на вычисления брокеру ресурсов, цель которого - найти сервер, доступный в сети. Планирование часто применяется для балансировки работы между серверами, и список доступных серверов отправляется обратно клиенту; затем клиент может отправить данные и запрос на один из предложенных серверов для решения своей проблемы. Благодаря увеличению пропускной способности сети и сокращению задержки сети теперь небольшие вычислительные запросы можно отправлять на серверы, доступные в Grid. Чтобы эффективно использовать современные платформы масштабируемых ресурсов, важно также обеспечить масштабируемость на уровнях промежуточного программного обеспечения. Этот сервис-ориентированный подход не нов.

В прошлом эта парадигма рассматривалась в нескольких исследовательских проектах. Основным промежуточным программным обеспечением, реализующим API, являются DIET, NetSolve / GridSolve, Ninf, но в некоторых других средах его используют, например САГА интерфейс из OGF и без стандартных вызовов API, таких как OmmiRPC, XtremWeb. Модель RPC через Интернет также использовалась для нескольких приложений. Прозрачно через Интернет большие проблемы оптимизации могут быть решены с использованием различных подходов путем простого заполнения веб-страницы для вычислений удаленной обработки изображений, использования математических библиотек или исследований эвристики и методов разрешения для разреженной линейной алгебры, такой как GridTLSE.[5] Такой подход к предоставлению вычислительных услуг через Интернет также очень близок к Сервисно-ориентированные вычисления (SOA) и является ядром Облачные вычисления.

Стандартизация и представление API GridRPC

Одним из простых, но эффективных способов выполнения заданий в вычислительной сети является использование промежуточного программного обеспечения GridRPC, основанного на GridRPCparadigm. Для каждого запроса промежуточное программное обеспечение GridRPC управляет управлением отправкой, входными и выходными данными, выполнением задания, удаленного ресурса и т. Д. Чтобы сделать службу доступной, программист должен реализовать два кода: клиент, в котором хранятся данные. определяется и запускается пользователем при запросе службы, а также сервером, который содержит реализацию службы, которая выполняется на удаленном ресурсе.

Один шаг для облегчения разработки таких кодов, проведенный для определения API GridRPC, который был предложен в качестве проекта в ноябре 2002 г.[6] и который является стандартом Open Grid Forum (OGF) с сентября 2007 года. Таким образом, исходный код GridRPC, который не включает определенные данные промежуточного программного обеспечения, может быть скомпилирован и выполнен с любым промежуточным программным обеспечением, совместимым с GridRPC.

Из-за разницы в выборе реализации GridRPCAPI был также написан документ, описывающий взаимодействие между GridRPCmiddleware. Его основная задача - описать разницу в поведении промежуточного программного обеспечения GridRPC и предложить общий тест, который должно пройти все промежуточное программное обеспечение GridRPC.

Затем были проведены обсуждения по управлению данными в промежуточном программном обеспечении GridRPC. Черновик API был предложен на конференции OGF'21 в октябре 2007 года. Мотивом для этого документа является предоставление явных функций для управления обменом данными между платформой GridRPC и клиентом, поскольку (1) размер данных, используемых в приложениях Grid, может быть следует избегать передачи больших и бесполезных данных; (2) данные не всегда хранятся на стороне клиента, но могут быть доступны либо на ресурсе хранения, либо на платформе GridRPC. Следовательно, побочным эффектом является то, что полностью совместимый с GridRPC код может быть написан и скомпилирован с любым промежуточным программным обеспечением GridRPC, реализующим GridRPC Data Management API.

Парадигма GridRPC

Парадигма GridRPC

Модель GridRPC изображена на следующем рисунке. Вот как обрабатываются коммуникации: (1) серверы регистрируют свои службы в реестре; (2) когда клиенту требуется выполнение услуги, он обращается к реестру и (3) реестр возвращает дескриптор клиенту; (4) затем клиент использует дескриптор для вызова службы на сервере и (5) в конечном итоге получает обратно результаты.

GridRPC API

Механизмы, задействованные в API, должны предоставлять средства для выполнения синхронных / или асинхронных вызовов службы. В последнем случае клиенты также должны иметь возможность ожидать блокирующим или неблокирующим образом после завершения данной услуги. Это, естественно, включает в себя некоторые структуры данных и ведет к строгому определению функций API.

Типы данных GridRPC

Для реализации API необходимы три основных типа данных: (1) grpc_function_handle_t - это тип переменных, представляющих удаленную функцию, привязанную к данному серверу. После выделения клиентом такая переменная может использоваться для запуска службы столько раз, сколько необходимо. Он явно аннулируется пользователем, когда больше не нужен; (2) grpc_session_t - это тип переменных, используемых для идентификации конкретного неблокирующего вызова GridRPC. Такая переменная является обязательной для получения информации о статусе задания, чтобы клиент мог ждать после, отменить или узнать статус ошибки вызова; (3)grpc_error_t группирует все виды ошибок и возвращает коды состояния, задействованные в GridRPC API.

Функции GridRPC

grpc_initialize () и grpc_finalize () функции аналогичны MPI инициализировать и завершить вызовы. Обязательно, чтобы любой вызов GridRPC выполнялся между этими двумя вызовами. Они читают файлы конфигурации, подготавливают среду GridRPC и завершают ее.

Чтобы инициализировать и разрушить дескриптор функции, grpc_function_handle_init () и grpc_function_handle_destruct () функции должны быть вызваны. Поскольку дескриптор функции может быть динамически связан с сервером, из-за механизмов обнаружения ресурсов, например, callto grpc_function_handle_default () позвольте отложить выбор сервера до фактического вызова дескриптора.

grpc_get_handle () позволить клиенту получить дескриптор функции, соответствующий идентификатору сеанса (например., на неблокирующий вызов), который был выполнен ранее.

В зависимости от типа звонка, блокирующий или неблокирующий, клиент может использовать grpc_call () и grpc_call_async ()функция. В последнем случае клиент получает после вызова идентификатор сеанса, который можно использовать для проверки или ожидания завершения, отмены вызова и проверки состояния ошибки неблокирующего вызова.

После выдачи уникального или множества неблокирующих вызовов клиент может использовать: grpc_probe () узнать, завершено ли выполнение услуги; grpc_probe_or () узнать, завершился ли один из предыдущих неблокирующих вызовов; grpc_cancel () отменить звонок; grpc_wait () заблокировать до завершения запрошенной услуги; grpc_wait_and () блокировать, пока не будут завершены все службы, соответствующие идентификаторам сеанса, используемым в качестве параметров; grpc_wait_or () блокировать до тех пор, пока не завершится любая из услуг, соответствующих идентификаторам сеанса, используемым в качестве параметров; grpc_wait_all () блокировать, пока не завершатся все неблокирующие вызовы; и grpc_wait_any () чтобы дождаться завершения любого ранее выданного неблокирующего запроса.

Код, совместимый с GridRPC

Поговорите о библиотеке (+ ссылка), с которой должен компилироваться код, и приведите базовый пример

Документы GridRPC

  • Модель GridRPC и API для приложений конечных пользователей. Ссылка OGF: GFD-R.52 (2007)
  • Тестирование совместимости для спецификации GridRPC API. Ссылка OGF: GFD.102 (2007)
  • API управления данными в GridRPC. Ссылка OGF: GFD-R-P.186 (2011)

Реализации GridRPC

Рекомендации

  1. ^ «Архивная копия». Архивировано из оригинал на 2011-08-11. Получено 2011-05-23.CS1 maint: заархивированная копия как заголовок (связь)
  2. ^ «Архивная копия» (PDF). Архивировано из оригинал (PDF) на 2011-09-28. Получено 2011-05-23.CS1 maint: заархивированная копия как заголовок (связь)
  3. ^ http://www.ogf.org/documents/GFD.102.pdf
  4. ^ http://www.ogf.org/documents/GFD.186.pdf
  5. ^ «Архивная копия». Архивировано из оригинал на 2011-07-13. Получено 2011-05-23.CS1 maint: заархивированная копия как заголовок (связь)
  6. ^ Сеймур, Кейт; Накада, Хидэмото; Matsuoka, S .; Донгарра, Джек; Ли, Крейг; Казанова, Анри (ноябрь 2002 г.). «Обзор GridRPC: API удаленного вызова процедур для грид-вычислений». Грид-вычисления - GRID 2002, третий международный семинар. Конспект лекций по информатике. 2536: 274–278. Дои:10.1007/3-540-36133-2_25. ISBN 978-3-540-00133-1.
  7. ^ Кэрон, Эдди; Деспре, Фредерик (2006). «ДИЕТА: Масштабируемый набор инструментов для создания сетевых серверов в сети». Международный журнал приложений высокопроизводительных вычислений. 20 (3): 335–352. CiteSeerX 10.1.1.126.236. Дои:10.1177/1094342006067472.
  8. ^ Ярхан А .; К. Сеймур; К. Саги; З. Ши; Дж. Донгарра (2006). «Последние разработки в Gridsolve». Международный журнал приложений высокопроизводительных вычислений. 20 (1): 131–141. CiteSeerX 10.1.1.62.3205. Дои:10.1177/1094342006061893.
  9. ^ Накада, Хидэмото; Сато, Мицухиса; Секигучи, S (1999). «Дизайн и реализация Ninf: к глобальной вычислительной инфраструктуре». Вычислительные системы будущего поколения, проблема метакомпьютинга. 15 (5–6): 649–658. CiteSeerX 10.1.1.177.2195. Дои:10.1016 / s0167-739x (99) 00016-3.
  10. ^ Сато, М; Хирано, М; Танака, Y; Секигучи, S (2001). «OmniRPC: сетевое RPC-средство для кластерных и глобальных вычислений в OpenMP». Конспект лекций по информатике. 2104 (Параллельное программирование с общей памятью OpenMP, Протоколы): 130–136. CiteSeerX 10.1.1.28.7334. Дои:10.1007/3-540-44587-0_12.

внешняя ссылка