Концепция grid
Сегодня все чаще при организации вычислений применяется разделение работ, данных и процессорных мощностей, а также иные режимы взаимодействия, предусматривающие использование распределенных ресурсов. Такой подход предъявляет новые требования к разработке и развертыванию распределенных приложений. Необходимы новые концепции, способные обеспечить доступ к приложениям и совместное использование ресурсов распределенных глобальных сетей, и в то же время поддерживающие общую логику обеспечения безопасности, эффективное управление распределенными ресурсами, координированное восстановление после сбоев, выявление проблем и иные ключевые параметры.
Работа в этом направлении привела к появлению концепции Grid, ставшей популярной при организации научных и технических вычислений. Технологии и инфраструктуры Grid поддерживают совместное и скоординированное использование разнородных ресурсов в динамических, распределенных виртуальных организациях, позволяя из географически рассредоточенных компонентов, применяемых в разных организациях с различными правилами работы создавать виртуальные вычислительные системы, способные совместно поддерживать требуемый уровень обслуживания.
В частности, свободно распространяемый инструментарий Globus Toolkit стал фактическим стандартом конструирования Grid-систем. На его основе созданы самые разные проекты: от систем обеспечения работы научных групп, которым требуется удаленный доступ к специализированными экспериментальным лабораториям, например, Network for Earthquake Engineering Simulation (NEESgrid, www.neesgrid.org), до систем распределенной аналитической обработки больших объемов информации, таких как Grid Physics Network, EU DataGrid Project (www.griphyn.org) и Particle Physics Data Grid (www.ppdg.net).
Эволюция технологии Grid привела к возникновению архитектуры Open Grid Services Architecture. В ней Grid-система предоставляет обширный набор служб, которые виртуальные организации могут объединять различными способами. Архитектура OGSA, созданная на концепциях и технологиях, разработанных специалистами в области Grid и Web-служб, определяет единообразную семантику предоставления служб, стандартные механизмы для создания, именования и обнаружения экземпляров Grid-служб, обеспечивает прозрачность местонахождения и связывание различных протоколов и поддерживает интеграцию с базовыми механизмами нижележащих платформ.
Разработка технических спецификаций OGSA ведется в рамках форума Global Grid Forum, разрабатывающего стандарты для Grid-сообщества и в качестве свободно распространяемой эталонной реализации предлагающего Globus Project. Инструментарий Globus Toolkit на базе OGSA и коммерческие продукты в этой архитектуре появились в конце 2002 года.
WWW изначально создавалась как технология совместных научных исследований, а позже была адаптирована к задачам электронного бизнеса. Аналогичная судьба ожидает и Grid. Программные инструменты для совместного использования научных ресурсов, ставшие стимулом для разработки первых Grid-сред, предусматривают объединение опыта за счет совместной визуализации больших наборов научных данных, а также объединения вычислительных ресурсов и ресурсов хранения для анализа данных, которые требуют больших объемов расчетов и серьезной функциональности. Предполагается, что подобные механизмы будут играть все более важную роль и в бизнес среде, сначала для научных и инженерных задач, а затем и для организации распределенных вычислений в коммерческих приложениях.
Однако самая важная роль концепции Grid в коммерческих вычислениях состоит не в том, чтобы увеличить производительность саму по себе, а в том, чтобы предложить решения новых задач, связанных с созданием надежных, масштабируемых и защищенных распределенных систем. Эти задачи возникают в связи с явной тенденцией к декомпозиции и распределению по сети ранее монолитных, централизованных служб.
Виртуализация Grid-служб позволяет легко отображать общее семантическое поведение служб на оригинальные механизмы платформы. Такая виртуализация становится проще, если выразить функции службы в стандартной форме, чтобы любые реализации службы вызывались одинаковым образом. Для этой цели выбран WSDL, язык описания Web-служб. WSDL проводит различие между определением интерфейсов служб и связываниями протоколов, используемых для вызова служб; один интерфейс может иметь несколько вариантов связываний, в том числе и распределенные протоколы (такие, как HTTP), и локальные связывания (например, средства межпроцессного взаимодействия, предусмотренные локальной ОС).
Возможность виртуализировать и комбинировать службы зависит не только от определения стандартных интерфейсов; необходима также стандартная семантика для взаимодействия служб, например, единые механизмы обнаружения свойств служб. С этой точки зрения, OGSA определяет Grid-службу как Web-службу, предоставляющую множество специфицированных интерфейсов и поддерживающую специфицированные соглашения. Интерфейсы касаются вопросов, связанных с обнаружением службы, ее динамическим созданием, управлением жизненным циклом, уведомлением и управляемостью; соглашения касаются также именования и модернизируемости. Grid-службы охватывают вопросы авторизации и контроля одновременного использования. Этот базовый набор согласованных интерфейсов, на основе которого реализуются все службы, поддерживает создание иерархических служб более высокого порядка, которые могут одинаковым образом восприниматься на всех уровнях абстракции.
Каждую Grid-службу определяет набор интерфейсов, сконфигурированный как WSDL portType (рис. 11).
Служба должна поддерживать интерфейс GridService; кроме того, OGSA определяет множество других интерфейсов для уведомления и создания экземпляров. Конечно, пользователи также определяют произвольные, ориентированные на конкретное приложение интерфейсы. serviceType (элемент расширения WSDL) определяют множество типов port-Type, которое поддерживает службы Grid вместе с некоторой дополнительной информацией, касающейся отслеживания версий.
Рис. 11. Grid-служба OCSA.
С каждым интерфейсом связан потенциально меняющийся набор элементов данных службы - элементов XML, имеющих имя и тип и инкапсулированных в стандартный формат контейнеров. Элементы данных службы определяют стандартное представление для информирования об экземплярах Grid-служб. Этот важный аспект модели OGSA формирует основу для обнаружения и управления потенциально меняющимися свойствами служб. Наконец, пользователи могут самыми разными способами реализовать конкретную службу, как определено ее интерфейсами и связанными элементами, и размещать ее в различных средах. Главное для виртуализации ресурсов - возможность адаптироваться к особенностям операционных систем на конкретных хостах.
Поскольку Grid-службы динамические и сохраняют свое состояние, необходим способ, позволяющий отличать один динамически создаваемый экземпляр службы от другого. В силу чего, каждый экземпляр службы получает глобально уникальное имя - дескриптор.
WSDL позволяет определять несколько связываний протоколов для конкретного интерфейса. От варианта связывания может зависеть такое свойство, как надежность. Службы взаимодействуют друг с другом путем обмена сообщениями. В распределенных системах, в которых случаются сбои отдельных компонентов, однако никогда не удастся гарантировать доставку отправленного приложения. Поддержка внутреннего состояния может стать гарантией того, что служба получает сообщение лишь однажды или не получает его вовсе, даже при использовании таких механизмов, как повторная передача. В подобных ситуациях может потребоваться использование протокола, который гарантирует одноразовую доставку или аналогичную семантику, точно так же, как и поддержка связывания протокола для взаимной аутентификации при соединении.
OGSA определяет стандартное поведение и соответствующие интерфейсы.
Обнаружение. Приложениям необходим механизм для обнаружения доступных служб, определения их характеристик и конфигурирования своих запросов к этим службам. Помимо элементов данных службы, определяющих стандартное представление информации об экземплярах службы, OGSA предлагает стандартную операцию FindServiceData, которая извлекает информацию о службе из конкретных экземпляров Grid-службы, и стандартный интерфейс для информации о регистрации экземпляров службы.
Динамическое создание службы. Возможность динамического создания новых экземпляров службы и управления ими требует использования средств создания службы. OGSA устанавливает стандартный интерфейс Factory и стандартную семантику службы.
Управление жизненным циклом. Службы OGSA могут создаваться и уничтожаться динамически. Их можно удалять явно; они также могут быть удалены или стать недоступными из-за возникновения системной ошибки, например, в случае сбоя в операционной системе. Интерфейсы определяются для управления жизненным циклом службы и, в частности, для восстановления служб и состояния, связанных с неудавшимися операциями. Например, окончание сеанса видеоконференции может также потребовать завершения служб, созданных в промежуточных точках для управления потоками. OGSA выполняет это требования, определяя стандартную операцию Set-TerminationTime в интерфейсе GridService, необходимом для поддержки состояния при управлении жизненным циклом экземпляров службы. Протоколы с поддержкой состояния позволяют OGSA в конце концов аннулировать состояние, установленное в удаленной системе, если поток последовательных восстанавливающих сообщений не обновит его. Интерфейс GridService также определяет операцию ЕхplicitDestruction.
Уведомление. Набор динамических, распределенных служб должен иметь возможность асинхронно уведомлять друг друга о серьезных изменениях своего состояния. OGSA определяет общие абстракции и интерфейсы служб для подписки на такие уведомления и для их доставки. Благодаря этому службы, созданные как композиция более простых служб, могут стандартным образом работать с уведомлениями, к примеру, с уведомлениями об ошибках. Специализированные связывания протоколов позволяют уведомлениям OGSA использовать различные (в том числе, коммерчески доступные) системы передачи сообщений для доставки сообщений с уведомлениями в соответствии с определенным QoS.
Управляемость. В производственных средах, возможно, потребуется выполнять мониторинг больших наборов экземпляров Grid-служб и управлять ими. Соответствующие операции определяет интерфейс управляемости.
На практике, Grid-службы выполняются конкретной средой исполнения. Эта среда определяет не только программную модель реализации, язык, средства разработки и отладки, но также и то, каким именно образом реализуется семантика службы.
Часто приложения Grid-служб используют набор процессов операционной системы в качестве среды исполнения. Скажем, создание нового экземпляра службы предусматривает создание нового процесса. Такая среда позволяет реализовать службу на различных языках (Си, C++, Java, Fortran, Python и т.д.). Семантика Grid может быть реализована непосредственно как часть службы или предоставлена посредством библиотеки, связанной с приложением.
Реализовывать Web-службы могут и более сложные среды исполнения на базе контейнеров или компонентов: J2EE, IBM WebSphere, .Net и Sun ONE. Внутри таких сред определяется оболочка, которая используется для реализации и создания компонентов, соответствующих устанавливаемым средой интерфейсам для создания сложных приложений. По сравнению с низкоуровневой функциональностью, которую предлагают базовые среды исполнения, контейнерные или компонентные среды, как правило, предлагают значительную программируемость, управляемость, гибкость и безопасность. Как следствие, они весьма популярны для создания служб электронной коммерции.
В контексте OGSA контейнер гарантирует, что службы, которые он поддерживает, соответствуют семантике Grid-служб, а также берет на себя некоторые служебные функции, освобождая от заботы о них того, кто реализует службу.
Определяя семантику службы, OGSA указывает взаимодействия между службами независимо от среды исполнения. Однако определение базовых характеристик, которые должны поддерживать все среды исполнения может помочь созданию служб:
отображение общих для Grid имен, или дескрипторов служб, на элементы, специфические для реализации, такие как указатели Си и ссылки на объекты Java;
диспетчеризация вызовов Grid и уведомлений в специфические для реализации действия, такие как события и вызовы процедур;
обработка протоколов и форматирование данных для передачи по сети;
управление жизненным циклом экземпляров служб;
аутентификация между службами. Важное следствие поддержки виртуализации в OGSA заключается в том, что пользователь не должен знать о том, как конкретная среда исполнения реализует поведение и интерфейсы OGSA. Простая среда исполнения, виртуальная среда исполнения и коллективные службы могут реализовывать одни и те же интерфейсы.
Простая среда исполнения. Простая среда исполнения предоставляет набор ресурсов, размещенных внутри одной организации. Он поддерживает базовые механизмы управления службами, такие как сервер приложений на базе J2EE, .Net или Linux-кластер. В OGSA интерфейс такой среды, как правило, будет структурирован - реестр, одна или несколько «фабрик» (factory) и модуль handleMapper, отвечающий за определение соответствия между глобально уникальным дескриптором Grid-службы и информацией о связывании. Каждая фабрика занесена в реестр, что позволяет клиентам обнаруживать имеющиеся фабрики.
Виртуальная среда исполнения. В более сложных средах ресурсы, связанные с виртуальными организациями (VO), будут охватывать гетерогенные, географически распределенные среды исполнения. Например, ресурсы принадлежат двум простым средам. Тем не менее, виртуальная среда исполнения, которая может, к примеру, соответствовать набору ресурсов, предоставляемых в рамках В2В-взаимодействия, может быть открыта клиенту для доступа через точно такие же интерфейсы, как и для простой среды исполнения.
Коллективные службы. Можно также создать виртуальную среду исполнения, которая предоставляет участникам виртуальных организаций более сложные виртуальные, коллективные или комплексные (сквозные) службы. В этом случае реестр отслеживает и «рекламирует» фабрики, которые создают экземпляры служб более высокого уровня. Такие экземпляры реализуются путем обращения к фабрикам более низкого уровня для создания множества экземпляров служб и за счет объединения поведения этих экземпляров в единый экземпляр службы более высокого уровня.
Рис. 12. Пример службы добычи данных.
Рис. 12 иллюстрирует некоторые аспекты использования OGSA. Представлена ситуация, в которой пользователь хочет обнаружить, приобрести и развернуть удаленным образом средства для создания новой базы данных путем добычи данных из нескольких источников данных в Internet. На рисунке представлены следующие шаги.
Пользователь (или, более вероятно, программа или служба, действующая от имени пользователя) обращается к реестру, который поддерживает соответствующее VO, для поиска провайдеров служб, способных предоставить требуемые возможности добычи и хранения данных. В запросе пользователя могут указываться такие требования, как стоимость, местонахождение или производительность. Реестр возвращает дескрипторы, указывающие фабрику добычи данных и фабрику базы данных, поддерживаемых провайдерами, которые соответствуют требованиям пользователя (или, возможно, несколько дескрипторов, представляющих службы-кандидаты). Пользователь указывает службы, приемлемые для него.
Пользователь инициирует запросы к фабрике добычи и базы данных, специфицируя ряд деталей, например, те операции по добыче данных, которые будут выполняться, вид базы данных, в которой будут храниться результаты, и время жизни для создаваемых экземпляров служб. Если этот процесс переговоров завершается успешно, создаются два новых экземпляра служб с требуемым начальным состоянием, ресурсами и временем жизни. Служба добычи данных инициирует запросы к соответствующим удаленным базам данных, по существу, действуя в качестве клиента от имени пользователя, когда он выполняет еще более удаленные операции. Механизмы защиты OGSA решают возникающие вопросы делегирования.
Результаты запросов возвращаются либо модулю добычи данных (рис. 12), либо вновь создаваемой базе данных. Вместе с тем, в зависимости от первоначально оговоренного времени жизни пользователь может периодически направлять сообщения о продлении этого времени, чтобы показать, что ему еще нужна данная служба.
Успешный результат выполнения этого процесса состоит в том, что экземпляр службы добычи данных уведомляет пользователя о выполнении и завершении работы. Затем пользователь сохраняет дескриптор для вновь созданной базы данных, которая может использоваться до тех пор, пока это необходимо, и, возможно, периодически сигнализирует о том, что данная служба нужна по-прежнему. С другой стороны, ошибка в вычислениях пользователя приведет к окончательному высвобождению ресурсов провайдеров по истечении срока существования службы.
Технологии и концепции Grid быстро набирают популярность, выходя за рамки научных сообществ. Open Grid Services Architecture ускоряет этот процесс, преобразуя технологии, которые предлагает Globus Toolkit, в единообразную, ориентированную на службы архитектуру и интегрируя их со стандартами на Web-службы. Таким образом, OGSA представляет естественную эволюцию технологий Grid и Web-служб.
Поддерживая временные, сохраняющие состояния экземпляры служб, наряду с традиционными технологиями Web-служб, OGSA значительно расширяет их возможности, в то же время требуя минимальной доработки имеющихся технологий. OGSA обеспечивает реализацию концепций Grid в производственных условиях за счет адаптации стандартных средств определения интерфейсов, позволяя при этом использовать инструментарий Web-служб.
Службы и абстракции OGSA предлагают строительные блоки, которые разработчики могут применять для реализации множества Grid-служб более высокого уровня, например, для управления данными и ресурсами. Global Grid Forum работает с отраслевыми и научными организациями и сообществом сторонников свободно распространяемого программного обеспечения над формированием набора служб, которые при их совместном использовании будут в состоянии удовлетворить разнообразные требования приложений электронного бизнеса и электронной науки.