Архитектура и технология Grid

Следует отметить, что ПО промежуточного слоя нового поколения для grid-систем позволяет управлять некоторым классом нетривиальных параллельных вычислений – таких, зависимость подзадач в которых может быть представлена направленным графом без циклов (Direct Acyclic Graph), приведенным на рисунке Рис.  1.

Рис.  1 Направленный граф вычислений

Необходимо отметить, что  существуют гибридные проекты, целью  которых  является достижение максимальной скорости вычислений за счет глобального  распределения этих вычислений между  суперкомпьютерами – при этом grid координирует использование различных суперкомпьютеров, а собственно нетривиальное распараллеливание происходит внутри суперкомпьютера. Проект DEISA может служить примером этого направления, в котором предпринимается попытка объединения суперкомпьютерных центров.

Структура grid.

Правильно разработанная  и хорошо реализованная grid-среда характеризуется следующими основными функциональными возможностями:

• доступ к вычислительным ресурсам, данным, устройствам, измерительным инструментам должен быть простым, прозрачным, удаленным, и безопасным;
• доступ должен быть виртуальным (нужен доступ не к серверам, а к сервисам, поставляющим данные или вычислительные ресурсы — причем без необходимости знания аппаратной структуры, обеспечивающей эти сервисы);
• доступ должен осуществлять по требованию (с заданным качеством), а ресурсы должны предоставляться тогда, когда в них возникает нужда;
• доступ должен быть распределенным, обеспечивая возможность совместной коллективной работы виртуальных команд;
• доступ должен быть устойчив к сбоям, а при выходе из строя серверов приложения должны автоматически мигрировать на резервные серверы;
• доступ должен обеспечивать возможность работы в гетерогенной среде – с различными платформами.

Необходимо отметить, что  не все из этих требований в должной  мере реализованы в настоящее  время.

Общая структура глобального  grid-a описывается в виде стека (набора уровней или слоев) протоколов. В такой модели каждый уровень предназначен для решения узкого круга задач и используется для предоставления услуг для более высоких уровней. Верхние уровни ближе к пользователю и работают с наиболее абстрактными объектами, тогда как нижние уровни сильно зависят от физической реализации grid-ресурсов. Полезно иметь в виду, что эта структура аналогична сетевой модели OSI (Open Systems Interconnection Reference Model); Стек grid-протоколов включает:

• аппаратный уровень (Fabric Layer) составляют протоколы, по которым соответствующие службы непосредственно работают с ресурсами;
• связывающий уровень (Connectivity Layer) составляют протоколы,  которые обеспечивают обмен данными между компонентами базового уровня и протоколы аутентификации;
• ресурсный уровень (Resource Layer) – это ядро многоуровневой системы, протоколы которого взаимодействуют с ресурсами, используя унифицированный интерфейс и не различая архитектурные особенности конкретного ресурса;
• коллективный (Collective Layer) уровень отвечает за координацию использования имеющихся ресурсов;
• прикладной уровень (Application Layer) описывает пользовательские приложения, работающие в среде виртуальной организации; приложения функционируют, используя протоколы, определенные на нижележащих уровнях.

Аппаратный уровень.

Аппаратный уровень обеспечивает доступ к распределенным ресурсам, необходимый протоколам более высокого уровня. Как уже неоднократно отмечалось, спектр возможных ресурсов весьма широк - это могут быть компьютеры, устройства массовой хранения данных, каталоги, сетевые  ресурсы и т. п.  При этом ресурс может быть логической сущностью (например, распределенной файловой системой) или  физической (например, кластером компьютеров). Реализация такого ресурса может  включать внутренние протоколы (например, NFS (Network File System) или протокол управления кластером), однако подобные протоколы  не включаются в стек grid-a. Компоненты аппаратного уровня реализуют локальные операции, специфические для каждого данного ресурса (логического или физического). Этот уровень по своим функциям аналогичен канальному уровню модели OSI и, по существу, представляет собой набор интерфейсов для управления локальными ресурсами.

Связывающий уровень.

Коммуникационные протоколы  связывающего уровня (Connectivity) должны обеспечивать надежный транспорт и маршрутизацию сообщений, а также присвоение имен объектам сети, а протоколы аутентификации этого уровня, основываясь на коммуникационных, предоставляют криптографические механизмы для идентификации и проверки подлинности пользователей и ресурсов. Инфраструктура поддержки включает централизованную выдачу сертификатов, управление сертификатами и ключами и т. д.

Ресурсный уровень.

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

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

Коллективный  уровень.

Протоколы коллективного  уровня отвечают за взаимодействие всех элементов пула ресурсов, что и  отражено в самом названии. В качестве примера глобальных функций и  сервисов, реализуемых протоколами  этого уровня, можно назвать службу каталогов, распределение ресурсов, планирование и брокерские услуги, службы мониторинга, диагностики, репликации данных, коллективной авторизации.

Прикладной уровень.

Этот высший уровень grid-архитектуры включает пользовательские приложения, которые исполняются в среде объединенных ресурсов. В процессе исполнения приложения используют протоколы нижележащих уровней, обеспечивающие доступ к необходимым службам, а также прикладные программные интерфейсы (Application Programming Interface – API), соответствующие данным протоколам. Приложения могут вызываться через достаточно сложные оболочки и библиотеки. Эти оболочки сами могут определять протоколы, сервисы и прикладные программные интерфейсы, однако подобные надстройки не относятся к фундаментальным протоколам и сервисам, определяющим архитектуру grid-систем.

Сервисы распределенных сетей.

Сервисно-ориентированная архитектура.

При рассмотрении термина  «сервисно-ориентированная архитектура», полезно предварительно определить ключевые термины: архитектура и  сервис.

Архитектура – это формальное описание системы, определяющее ее цели, функции, внешне видимые свойства, и интерфейсы. Она также включает описание внутренних компонентов системы и их отношений, наряду с принципами, управляющими ее дизайном, функционированием и возможной последующей эволюцией.

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

Сервисно-ориентированная  архитектура (service-oriented architecture, SOA) является основой построения надежных распределенных систем, которые в качестве услуг  предоставляют функциональные возможности, с  дополнительным акцентом на слабые связи между взаимодействующими сервисами.

Таким образом, SOA это архитектурный  стиль, который подчеркивает реализацию компонентов системы как модульных  сервисов, которые могут быть найдены  и использованы клиентами.

Сервисы имеют следующие  характеристики:

• Сервисы могут быть полезными каждый сам по себе, или они могут быть объединены, чтобы предоставить единый высокоуровневый сервис. Среди других достоинств, это позволяет многократно использовать уже существующие функциональные возможности.
• Сервис общаются со своими клиентами, обмениваясь сообщениями: фактически, сервисы и различаются и идентифицируются в соответствии с совокупностью сообщений, которые они могут принять и ответов, которые они могут направить запрашивающей стороне.
• Сервис может участвовать в таких процессах обработки запросов, при которых порядок, в котором сообщения посылаются и принимаются, влияет на результат операций, выполненных сервисом. Это называется "сервисной хореографией" (service choreography).
• Сервис может быть полностью независимым, или может зависеть от существования других сервисов, или каких-либо ресурсов, например, баз данных. Простейшим примером первого типа является сервис, осуществляющий возведение в квадрат числа, посланного в запросе; примером второго типа является сервис, осуществляющий конвертацию валют – для этого ему необходим текущий валютный курс.
• Сервисы предоставляют информацию о своих возможностях, интерфейсах, политике и поддерживаемых протоколах связи. Детали реализации, например, язык программирования и платформа, на которой он реализован, не нужны клиентам для направления запросов и не предоставляются.

Взаимодействие  сервисов в SOA-среде.

Потенциальный клиент, который  может быть другим сервисом (или  человеком), делает запрос в сервис регистрации (2), чтобы найти сервис, который удовлетворяет его потребностям. Регистрационный сервис возвращает (возможно, пустой) список подходящих сервисов; клиент выбирает один из них и передает ему запрос, используя любой взаимно распознаваемый протокол (3).

Рис.  2 Схема взаимодействия сервисов в SOA-среде

В этом примере, отображенном на Рис.  2, сервис отвечает (4), передавая или результат требуемой операции или сообщение об ошибке. На рисунке показан самый простой случай. В реальной установке процесс может быть значительно более сложным. Например, данный сервис может поддержать только HTTPS протокол, обслуживать только зарегистрированных пользователей, предлагать различные уровни сервиса различным пользователям, или требовать оплаты за использование.

Принцип слабой связи.

В определение SOA входит понятие  слабой связи сервисов. Этот термин подразумевает, что взаимодействующие  программные компоненты имеет минимальное  знание друг о друге: они находят  информацию, которая им нужна для  взаимодействия непосредственно перед  взаимодействием. Например, узнав о  существовании сервиса, клиент может  выяснить его возможности, условия предоставления услуг, его местоположение, его интерфейсы и поддерживаемые протоколы. Как только эти сведения получены, клиент может сразу же обратиться к сервису, используя любой взаимоприемлемый протокол.

Достоинствами слабой связи  являются:

• Гибкость: сервис может быть расположен на любом сервере, а при необходимости – перемещен. Пока ссылка на этот сервис есть в службе регистрации, предполагаемые клиенты будут в состоянии найти и использовать его.
• Масштабируемость: функциональные возможности сервиса могут быть расширены или сужены, поскольку при этом описание сервиса динамически меняется, и, соответственно, изменяются и запросы.
• Возможность модификации реализации: при условии, что оригинальные интерфейсы сохраняются, реализация сервиса может быть обновлена без сбоев в обслуживании клиентов.
• Отказоустойчивость: Если возникают проблемы в работе сервера, программного компонента или сегмента сети, или сервис становится недоступным по любой другой причине, клиенты могут сделать запрос к службе регистрации для обнаружения другого сервиса, который предоставляет требуемые услуги.

Веб-сервисы  и SOA.

SOA и веб-сервисы являются  «ортогональными» понятиями: сервисная  ориентация – это архитектурный  стиль, а веб-сервисы - технология  выполнения. Они, конечно, могут  использоваться совместно – как  это часто и случается, но  они взаимно независимы.

Например, хотя принято считать, что SOA предназначена для распределенных систем, она может использоваться и для одиночных компьютеров, когда сервис соответствует индивидуальным процессам с четкими интерфейсами, которые взаимодействуют, используя  внутренние каналы связи, или для  кластера персональных компьютеров, где  они могли бы общаться посредством  высокоскоростной локальной сети. Аналогично, веб-сервисы хорошо подходят в качестве строительных блоков SOA-среды, но в их определении нет ничего, что обязательно требует воплощение принципов SOA.

Хотя отсутствие состояний  зачастую рассматривается как ключевая характеристика веб-сервис, нет никаких  технических причин, по которым они  обязательно должны быть без состояний  – это определяется выбором разработчика и архитектурным стилем среды, в  которой сервис должен работать.

Легкость, с которой веб-сервисы  могут быть реализованы и возможность  обращаться к ним независимо от платформы  клиента, привела к тому, что они  были широко приняты администраторами систем как «агенты виртуализации», которые обеспечивают общие интерфейсы управления к различным ресурсам. Например, веб-сервис может быть спроектирован  так, чтобы "представлять" специфическое  устройство или обычное приложение, принимая запросы управления и контроля через стандартизированные интерфейсы, с ресурсом общаясь посредством  его «родного» интерфейса, и возвращая  результат запрашивающей стороне  опять в стандартном формате. Данный рисунок Рис.  3 иллюстрирует, каким образом единая консоль может управлять совокупностью разнообразных ресурсов посредством уровня виртуализации на основе веб-сервиса. Каждая совокупность предоставляет консоли стандартизированных интерфейсов для взаимодействия со связанным с ней ресурсом.

Рис.  3 Виртуализация ресурсов с помощью Веб-сервисов

Сервисно-ориентированный  grid и OpenGrid.

Работа grid-систем опирается на программное обеспечение промежуточного уровня: программные компоненты и протоколы, которые обеспечивают требуемый контролируемый доступ к ресурсам. На первом этапе своего существования grid-системы строились или на основе специально разработанных общедоступных компонент или на основе закрытых (проприетарных) технологий. Хотя различные общественные и коммерческие решения были успешны в своих областях применения grid-a, каждое со своими сильными и слабыми сторонами, они имели ограниченный потенциал как основы для grid нового поколения, который должен быть масштабируемым и интероперабельным, чтобы удовлетворять потребности широкомасштабных научных и производственных проектов.

В последние годы стало  ясно, что есть значительное перекрытие между целями вычислительного grid-a и преимуществ сред, основанных на SOA и веб-сервисах. Быстрый прогресс в технологии веб-сервисов и разработке соответствующих стандартов обеспечили эволюционный путь от жесткой и узконаправленной архитектуры grid-систем первого поколения к стандартизированным, сервис-ориентированным grid-ам, гарантирующим стабильно-высокое качество обслуживания пользователей (grid промышленного уровня).