Развитие Грид перешло в стадию реализации проектов, направленных на развертывание действующих инфраструктур и постановку на них больших прикладных задач. К наиболее крупным проектам можно отнести: EGEE (www.eu-egee.org), NorduGrid (www.nordugrid.org), CrossGrid (www.eucrossgrid.org), Grid2003(www.ivdgl.org/grid2003), TeraGrid (www.teragrid.org). Масштаб проектов проиллюстрируем на двух примерах: европейского EGEE и американского Grid2003.
Проектируемая инфраструктура первого объединит 70 институтов в 27 странах (вих числе и российские институты) и должна дать круглосуточный доступ к вычислительным ресурсам с суммарной мощностью эквивалентной 20000 процессорам. Это позволит в распределенном режиме обрабатывать потоки данных с ускорителя LHC, вырабатываемые со скоростью до 100 Mбайт/сек. и общим объемом несколько петабайтов в год.
Grid2003 [1], введенный в строй с ноября 2003 года, включает 27 узлов и 2800 процессоров. На Grid2003 поставлено 10 разных приложений (ядерная физика, астрофизика, вычислительная химия и биология), средняя загрузка составляет 1300 одновременно выполняющихся заданий при объеме сетевой передачи данных свыше 2 Tбайтов в день.
Переход от экспериментальных стендов к инфраструктурам,
работающим в производственном режиме, стал возможен благодаря появлению целого
ряда программных средств поддержки функционирования Грид. Сыгравший
исключительную роль на начальном этапе развития Globus Toolkit перестал быть
средством для построения Грид, хотя по-прежнему сохраняет значение как стандарт
дистанционного взаимодействия и инструментально-базовый комплекс. Большая часть
программных систем для Грид, хотя и разрабатывалась различными коллективами,
основывалась на стандартах Globus Toolkit (эволюционировавших в архитектуру
Грид-служб OGSA), и вследствие этого они оказалась хорошо совместимыми друг с
другом. Реалистичный путь создания Грид сегодня – использование пакетов
программного обеспечения (ПО) Грид, таких, например, как Virtual Data Toolkit
(VDT, www.cs.wisc.edu/vdt). VDT включает три группы ПО:
Как показал опыт проекта
Grid2003, помимо прочего, благодаря наличию средств установки, VDT существенно
упрощает конфигурирование узлов Грид.
Следующее важное продвижение состоит в появлении программных платформ, то есть взаимосогласованных наборов средств, которые, исходя из сложившегося на сегодня представления о формах компьютинга в Грид, со значительно большей полнотой по сравнению с пакетами ПО поддерживают развертывание и обслуживание Грид, а также организуют его функционирование как единой операционной среды. Характерные отличия платформ проявляются в том, что в них в рамках единой архитектуры начинают реально решаться задачи обеспечения надежности, детерминированности, качества обслуживания, управляемости Грид с помощью механизмов планирования, мониторинга заданий и устройств, учета и протоколирования.
К складывающемуся классу платформ можно отнести два европейских комплекса средств: DataGrid (www.datagrid.org) и Unicore (www.unicore.org). Первый из этих комплексов, разработанный в течение 2000 - 2003 годов, представляет для нас особый интерес, поскольку он становится стартовой программной базой проекта EGEE, в котором принимает участие и ИПМ РАН. Рассмотрение ПО DataGrid (v2.0) позволяет сделать заключение, что оно способно обеспечить функционирование Грид большого масштаба, но с определенными ограничениями по способу организации ресурсов и режиму их использования.
Функциональные возможности. Ядро ПО DataGrid составляет
система WMS (Workload Management System) [2], в которую входят следующие
основные компоненты.
- User Interface. Пользовательский интерфейс на основе
языка JDL;
- Resource Broker. Выполняет подбор ресурсов для исполнения
запросов.
- CondorG. Выполняет удаленные операции по управлению заданиями на
ресурсах.
- Logging and Bookkeeping. Службы протоколирования событий,
генерируемых компонентами WMS, и учета использования ресурсов.
- MyProxy [3].
Служба, поддерживающая обновление доверительных сертификатов, используется для
заданий с длительным выполнением.
- DataGrid Accounting System. Поддерживает
экономические отношения между поставщиками и потребителями
ресурсов.
Как видно из этого списка, DataGrid решает важнейшие для распределенной среды задачи, обеспечивая виртуализацию ресурсов, протоколирование, учет, поддержку отношений предоставления/потребления ресурсов в рамках общей архитектуры взаимодействующих между собой служб.
Обслуживаемый класс приложений. Основной класс - однопроцессорные вычислительные задания с большим временем счета. Поскольку в DataGrid помимо WMS интегрированы служба GridFTP и служба репликации файлов Replica Location Service [4], платформа способна обеспечивать работу с файлами большого объема.
Характеристика ресурсов. DataGrid рассчитана на кластеризованные ресурсы с любыми системами управления, с которыми имеет интерфейс Globus Toolkit. Способ выбора ресурсов для заданий основан на информации о количестве заданий в очередях кластерных систем управления и способен дать хорошие результаты при условии, что ресурсы функционируют в выделенном режиме, то есть полностью отчуждаются от владельцев. DataGrid использует информационную службу Globus Toolkit для распределенного мониторинга ресурсов.
Надежность обработки. Гарантируется завершение обработки запущенных заданий. Мониторинг задания и перезапуск в аварийных ситуациях осуществляется из точки запуска с помощью системы CondorG. Имеется аппарат прикладных контрольных точек, однако автоматический рестарт не поддерживается.
Качество обслуживания. Способ планирования в DataGrid не позволяет получить точную оценку времени обработки заданий и, тем самым, качество обслуживания не регулируется. Масштабируемость. Распределение заданий производится по централизованной схеме, оценки производительности серверов пока отсутствуют.
Заслуживает внимания появление, наряду со свободно распространяемыми платформами, целого ряда коммерческих продуктов для глобально распределенных вычислений: DCGrid, LiveCluster, GridMP, Frontier, выпущенных, соответственно,компаниями Entropia, DataSynapse, United Devices и Parabon Computation. Эти продукты квалифицируются производителями как платформы для Грид, и с этим, в общем, трудно не согласиться, поскольку они направлены на решение задач Грид: обеспечения скоординированного доступа к глобально распределенным ресурсам в рамках виртуальной организации, и поддерживают полный цикл обработки заданий в распределенной инфраструктуре.
Применяемый в коммерческих платформах подход имеет ряд особенностей.Прежде всего это касается организации ресурсной составляющей Грид. В платформах,основанных на Globus Toolkit, узлы Грид являются многомашинными комплексами, которые находятся в автономном административном домене, связаны локальной сетью и управляются системой пакетной обработки, играющей роль менеджера ресурсов (МР). В коммерческих же платформах узлы могут быть элементарными, то есть каждый узел – это компьютер, на который для подключения в Грид устанавливается компактный Агент, выполняющий функции запуска заданий, мониторинга, защиты и контактов с управляющим центром (Грид-сервером).
Различие в типах ресурсов сказывается на архитектуре поддерживаемых Грид. Коммерческие платформы можно назвать вертикально интегрированными, из-за того, что в них узлы - глобально распределенные компьютеры – недоступны для прямого запуска заданий, а интегрируются через управляющий центр, который, с одной стороны, представляет собой точку доступа ко всем ресурсам, и, с другой стороны, выполняет функции МР, управляя ресурсами и виртуализируя их. Можно провести аналогию вертикально интегрированного Грид с кластерной архитектурой, но со следующим важным отличием: обрабатывающие узлы могут быть глобально распределены и принадлежать разным владельцам.
В коммерческих платформах предложен ряд новых программных решений, направленных на поддержку такого режима использования ресурсов, когда они не отчуждаются от владельцев. В этих условиях задачи Грид усложняются, так как ресурсная составляющая не является ни надежной (машины могут выключаться и перезагружаться), ни безопасной (посторонние лица могут иметь дистанционный или прямой доступ к машине), ни предсказуемой (в любой момент машина может быть полностью занята владельцем). В связи с этими проблемами разработаны специальные методы. Безопасность, например, рассматривается в трех аспектах: защиты владельца ресурса, защита конфигурации машины, защита приложения Грид, и обеспечивается механизмами “изоляции” приложений в виртуальной исполнительной среде [5].
Два вида платформ: с вертикальной интеграцией (коммерческие платформы) и с горизонтальной интеграцией на основе стандартов дистанционного взаимодействия в архитектуре Грид-служб OGSA, можно, наверное, рассматривать как несводимые альтернативы. Однако, более продуктивным представляется взаимное сближение на основе как межплатформенной интероперабельности, так и интеграции конкретных механизмов и функций. Фактически сближение уже началось, это проявляется, например, в том, что перечисленные выше компании-разработчики в той или иной степени принимали участие в подготовке стандарта OGSA и имеют планы перевести свои частные протоколы взаимодействия в архитектуру Грид-служб.
Вряд ли в ближайшее время можно ожидать появления общемирового Грид, работающего на одной платформе. Однако, свойство интероперабельности может все же обеспечить, правда при меньшем уровне интеграции, возможность разделения ресурсов, служб и кодов между разными Грид и виртуальными организациями. С другой стороны, отсутствие интероперабельности может серьезно скомпроментировать подход Грид, если для участия в каждом новом проекте пользователи будут вынуждены менять программное обеспечение рабочего места, переходя на новый интерфейс.
Проблема интероперабельности не осталась без внимания - работы в этом направлении ведутся в рамках Global Grid Forum (рабочая группа GPA), известен также проект Grid Interoperability Project (IST-2001-32257, www.grid-interoperability.org), финансировавшийся Европейской комиссией. Хорошую базу обеспечения интероперабельности дает архитектура OGSA, стандартизируя протоколы распределенных служб и способ описания их интерфейсов, однако все проблемы только унификация взаимодействия решить, по-видимому, не сможет.
В связи с разработкой комплекса Грид-диспетчер [6], нами рассматривался вопрос о возможности его интеграции в платформу DataGrid. Как оказалось, сделать это невозможно по причине того, что некоторые службы текущей версии DataGrid жестко связаны с тем способом диспетчеризации заданий, который реализован в брокере GRB. Причина состоит в следующем. Для мониторинга заданий в DataGrid применяется CondorG, который с машины пользователя периодически опрашивает состояние задания на исполнительном узле Грид (через интерфейс службы управления заданиями узла). Если команда опроса не получает ответа (сбой исполнительной машины или управляющих программ), выполняется попытка повторного запуска.
Недостаток такой реализации мониторинга заключается в том, что способ рассчитан только на один шаг обработки задания – исполнение. Поэтому, применимость этой схемы ограничена таким типом брокера, который не поддерживает очередь заданий, что имеет место в варианте брокера GRB. В случае же Грид-диспетчера, задание может в течение продолжительного времени храниться в его глобальной очереди, в результате чего возникает новое состояние, которое должно фиксироваться мониторингом и использоваться при выполнении таких операций как, например, удаление задания.
Исходя из этого примера, можно сформулировать требования
к способу реализации служб управления заданиями, удовлетворение которых
необходимо для достижения интероперабельности платформ и взаимозаменяемости их
компонентов:
Сравнивая первые два из этих требований с современным положением дел, можно отметить, что реализованный в Globus Toolkit механизм поддержки контекста безопасности, основанный на доверительной передаче прав доступа, рассчитан на произвольное количество шагов обработки задания. Оправданность и предусмотрительность такого решения была доказана при реализации всех систем серверного обслуживания, основанных на Globus Toolkit.