Основу для построения любой grid-инфраструктуры составляет программное обеспечение промежуточного слоя, например gLite (EGEE, Enabling Grids for E-sciencE, public.eu-egee.org) и Globus, основанные на архитектуре SOA. Стандартными для таких систем являются сервисы, отвечающие за безопасность, управление данными и задачами, а также за предоставление информации.
Однако в стандартом наборе нет сервиса, отвечающего за управление другими сервисами или grid в целом, хотя и имеются сервисы мониторинга, но мониторинг – это всего лишь средство предоставления данных для принятия управленческих решений. Для поддержания работоспособности даже небольшой grid-инфраструктуры требуется приложить значительные усилия по установке, настройке и управлению grid-сервисов. Некоторые шаги для улучшения сделаны, и тем не менее управление grid-инфраструктурами остается открытым и очень сложным вопросом, решение которого может быть найдено в области адаптивных компьютерных систем.
Еще в 2001 году корпорация IBM выпустила манифест, главной темой для которого послужил кризис в ИТ-индустрии, связанный со все увеличивающейся сложностью приложений, а в качестве выхода предлагалось развивать адаптивные компьютерные системы. Основная черта таких систем – самоорганизация. Подобная система может постоянно отслеживать использование ее ресурсов, возникновение неполадок или, например, наличие обновлений для ее компонентов. При появлении нового компонента система сама установит его, произведет свою перенастройку, если это необходимо, и выполнит ряд тестов, чтобы убедиться, что все работает, как предполагалось. Если же после установки и настройки будет обнаружена ошибка, система «откатится» к предыдущей версии, в то время как алгоритмы, ответственные за разрешение проблемных ситуаций, постараются изолировать проблемную область. Основные характеристики автономных систем: Самонастройка (Self-configuration), Самолечение (Self-healing), Самооптимизация (Self-optimization) и Самозащита (Self-protection).
Адаптивность – мощная концепция, и не вызывает сомнений, что ее применение к grid способно принести значительную пользу.
Сегодня имеется два направления автоматизации grid. Основной задачей первого является разработка отдельных адаптивных компонентов, приложений или grid-сегментов. Задача второго – расширение функциями автоматизации уже существующих систем мониторинга. В последние годы появилось много систем мониторинга для grid, функции аналитики и автоматизации в них встречаются крайне редко. Как правило, они ограничиваются автоматическими средствами перезапуска сервисов или задач, оповещения ИТ-администраторов или восстановления при сбоях. Большинство подходов заключается в попытке управлять grid без прямого воздействия на него и интеграции с ним, что гораздо легче, чем вносить изменения во все grid-сервисы. Однако представляется очевидным, что для получения всех выгод от адаптивных компьютерных систем часть инфраструктуры, предназначенная для управления grid, должна быть полностью в него интегрирована, должна иметь такую же природу, как и сервисы, которые она собирается контролировать.
Создание специализированного сервиса управления grid – Grid Management Service (GMS) – будет способствовать улучшению производительности, надежности и удобству работы grid-инфраструктур. GMS основан на сервисной архитектуре, что позволяет воздействовать на другие сервисы. Несмотря на то что придется несколько изменить другие сервисы, чтобы добавить необходимые «точки доступа», подход, при котором мы пытаемся управлять сервисами, не изменяя их, зачастую очень сложен, сталкивается с множеством проблем и требует больших усилий на развитие.
Каждый grid-сервис имеет собственные механизмы мониторинга и управления, причем здесь пока нет единых стандартов. Механизмы управления довольно сложны в своей работе, а информация, предоставляемая внутренними средствами мониторинга, зачастую недостаточна для принятия эффективных управленческих решений. Одним из принципов адаптивных компьютерных систем является наличие у ресурсов нижнего уровня единых интерфейсов для мониторинга и управления. В случае grid это потребует слаженного сотрудничества всех разработчиков.
Сейчас еще неясно, какую именно архитектуру будет иметь GMS: строгая иерархия, основанная на «выборах», или полностью децентрализованная система. Для gLite предпочтительнее первый вариант, а для Globus – второй. Другое перспективное направление исследований в данной области – использование «свободных узлов» (free node), которые могут быть полезны в случае адаптивных grid-сред. При подобном подходе у определенного множества машин функциональные задачи строго не прописываются и сервисы на них могут быть переустановлены в зависимости от изменяющихся требований. Если для эффективной работы системе понадобится больше вычислительных мощностей, дополнительный менеджер ресурсов и т.д., то для решения этих текущих задач будут использованы свободные узлы. Перечислим задачи, которые мог бы решить сервис управления.
Отключение сервиса. Если GMS обнаружит, что один из доверенных ему сервисов недоступен, он инициализирует перезапуск, перенастройку или переустановку. Он также может перенастроить окружение, чтобы избежать попыток использования недоступного сервиса, либо попытаться установить новую версию сервиса на одном из свободных узлов. В случае когда больше не остается возможных вариантов действий либо ни одно из них не принесло желаемого результата, он может обратиться за помощью к вышестоящему сервису либо ИТ-администратору.
Обнаружение ошибок. Сервис может обрабатывать любые проблемы, связанные с безопасностью, вычислительными либо транспортными задачами. В качестве первого шага GMS будет определять симптомы и сравнивать их с уже известными шаблонами ошибок. Затем, в соответствии с типом проблем и внутренними политиками, будет определен план действий, который потом будет выполнен специальными функциями исполнения. Конечно, определение всего спектра возможных ошибок и разработка действий при их возникновении – это очень сложная работа, но представляется логичным, что рано или поздно она в любом случае должна быть сделана. В данном направлении могут оказаться очень полезными функции обучения.
Обучение. В случае обнаружения неполадок GMS может попробовать использовать один из стандартных алгоритмов для их устранения. Могут быть применены и более сложные механизмы, например выбор алгоритма, опираясь на степень связанности сбоев. Естественно, при довольно серьезных сбоях он будет обращаться за помощью к ИТ-администратору. Как только у GMS возникнет решение, он будет распространять свои знания о симптоматике и методах исправления проблемы между другими GMS либо направлять их в базу знаний, чтобы они были доступны всем сервисам.
Оптимизация. GMS может пробовать различные сочетания настроек для улучшения производительности. Очевидно, что данная возможность будет сильно ограничена внутренними политиками, но даже при этом она сможет принести значительные выгоды. GMS может использовать различные функции оптимизации либо наборы правил для определения наилучшей конфигурации для текущей ситуации. Другой путь оптимизации – использование свободных узлов для уменьшения нагрузки либо увеличения производительности.
Установка и обновление. GMS может стать полезным инструментом при включении в инфраструктуру новых узлов. Например, при подключении нового сегмента оператору будет необходимо лишь описать его ресурсы и выбрать одну из стандартных схем либо создать свою схему установки и настройки оборудования. Возможно, будут существовать функции, способные вычислять оптимальную конфигурацию сегмента для решения определенных задач. Другой обязанностью GMS будет контроль версий его ресурсов. Если станет доступно новое обновление, оно сразу же будет установлено на всех узлах инфраструктуры. Это решит проблему существования различных версий (иногда очень старых) одного и того же сервиса.
Глобальный контроль. Использование GMS позволит операторам получать полную информацию о состоянии, производительности, конфигурации и настройках grid, но самое главное – они будут иметь удобную возможность управления как отдельными компонентами, так и всей инфраструктурой в целом.
***
Вряд ли стоит ожидать появления подобного сервиса в ближайшее время, возможно, потребуется несколько лет, чтобы приблизиться к его реализации. Создание GMS в рамках gLite или Globus – это в первую очередь административная задача, которая потребует серьезных организационных решений и скоординированных действий разработчиков всех grid-сервисов. Однако отработка различных методов и средств может происходить и локально, например, в качестве первого шага на пути автоматизации работы операторов сервиса передачи файлов и апробации идей GMS можно назвать прототип экспертной системы, интегрированный в систему мониторинга FTS. Данный прототип позволяет интерпретировать состояние системы в понятных пользователям терминах, при необходимости объяснять, вследствие каких причин тот или иной объект находится в определенном состоянии и какие действия необходимо предпринять для исправления сложившейся ситуации. С развитием адаптивных технологий и увеличением доверия к ним подобным системам можно будет поручать действия на самом нижнем уровне, а с течением времени ИТ-администраторы будут принимать только управленческие решения.
Владимир Кореньков (korenkov@cv.jinr.ru) – заместитель директора Лаборатории информационных технологий ОИЯИ, Александр Ужинский (zalexandr@list.ru) – инженер-программист ОИЯИ (Дубна).
Архитектура сервиса передачи данных в grid
Наиболее сложная часть проектов в области datagrid – обеспечение гарантированно надежной и эффективной передачи огромных массивов данных между региональными центрами, осуществляемой в grid через сервис передачи данных (FTS). Система мониторинга для этого сервиса была разработана в рамках сотрудничества ОИЯИ, НИИЯФ МГУ и ЦЕРН.
