Кооперация: Согласование множества ресурсов

 

В то время, как уровень Ресурсов нацелен на взаимодействие с одним ресурсом, расположенный выше уровень рассматриваемой архитектуры содержит протоколы и службы, (а также API's и SDK's), которые не ассоциированы с каким - либо одним заданным ресурсом, а скорее являются глобальными по природе и охвату взаимодействий на всём множестве ресурсов. По этой причине мы называем следующий слой архитектуры уровнем Кооперации (Collective layer). Поскольку компоненты уровня Кооперации согласно протоколу песочных часов построены на узком "горле" уровней Ресурсов и Связи, они могут реализовать широкое разнообразие режимов, не предъявляя новых требований к разделяемым ресурсам. Например:

Службы каталогов (directory services) позволяют членам ВО обнаруживать зарегистрированные обобществлённые и/или частные ресурсы. Служба каталогов даёт возможность её пользователям запрашивать ресурсы, указывая их имена и/или атрибуты такие как тип, доступность или загруженность. Для создания каталогов используются протоколы GRRP и GRIP уровня Ресурсов.

Службы совместного одновременного распределения, планирования и заказа ресурсов (co-allocation, scheduling and brokering services) позволяют участникам ВО запрашивать один или больше ресурсов для конкретной цели и планировать решение задач на соответствующих ресурсах. В качестве примеров можно указать системы AppLes, Condor-G, Nimrod-G и брокер DRM.

Службы мониторинга и диагностики (monitoring and diagnostics services) осуществляют мониторинг ресурсов ВО в для выявления отказов, вторжения ("intrusion detection"), перегрузки и т.д.

Службы репликации данных (data replication services) поддерживают управление ресурсами хранения ВО (также возможно, сетевыми и вычислительными) для достижения максимальной производительности при доступе к данным с учётом, например, таких показателей, как время ответа, надёжность и стоимость.

Системы программирования для грид (grid-enabled programming systems) дают возможность использовать в грид-среде известные модели программирования. При этом для решения вопросов, касающихся обнаружения и распределения ресурсов, безопасности и других используются различные грид-службы. Например, грид-реализации Интерфейса Передачи Данных (Message Passing Interface - MPI) и интегрированных сред разработки (manager-worker frameworks).

Системы управления заданиями (workload management systems) и инфраструктура взаимодействия (collaboration frameworks) - также известные, как среды решения задач (problem solving environments - "PSEs") - предназначены для описания, использования и управления многоэтапными, асинхронными и многокомпонентными потоками работ.

Службы обнаружения программного обеспечения (software discovery services), используя параметры решаемой задачи находят и выбирают наилучшие для этой задачи реализацию программного обеспечения и исполнительную платформу. Примерами могут служить системы NetSolve nNinf.

Серверы групповой авторизации (community authorization servers) проводят в жизнь политики группового доступа к ресурсам, выдавая мандаты, которые члены группы могут использовать для доступа к групповым ресурсам. Используя информацию о ресурсах и протоколы управления ресурсами (на уровне Ресурсов) и безопасности, эти серверы обеспечивают глобальную, жёсткую политику обслуживания. Akenti решает некоторые из этих проблем.

Службы учёта использования и оплаты ресурсов (community accounting and payment services) собирают вместе информацию о ресурсах для учёта их использования, платежах за ресурсы и/или ограничения на использование ресурсов членами группы.

Службы взаимодействия (collaboration services) поддерживают согласованный синхронный или асинхронный обмен информацией внутри потенциально больших групп пользователей. Примерами могут служить разработки CAVERNsoft, Access Grid, а также коммерческие системы программного обеспечения.

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

Набор функций может быть реализован либо в виде постоянно существующих служб соответствующими протоколами, либо в виде SDK's (с ассоциированными API's), спроектированными для использования в приложениях. В обоих случаях, их реализация может быть построена на протоколах уровня Ресурсов (или протоколах уровня Кооперации) и API's.

Компоненты Кооперации могут быть разработаны по заказу определённой группы пользователей, ВО или конкретного приложения. Например, в виде SDK, который реализует связанный со спецификой приложения протокол, или службы совместного резервирования для заданного комплекса сетевых ресурсов. Другие компоненты Кооперации могут быть более общецелевыми, например, служба репликации, которая управляет международным комплексом систем хранения для многих групп, или служба каталогов, сконструированная для обнаружения других ВО. Вообще, чем масштабней цель группы пользователей, тем важнее, чтобы протоколы компонент уровня Кооперации и API's базировались на стандартах.

Приложения

 

Последний уровень обсуждаемой грид-архитектуры - уровень Приложений (Applications layer) - содержит пользовательские программные приложения, которые применяются в среде ВО. Приложения конструируются в терминах обращений к службам, определённым на любом уровне архитектуры. На каждом уровне чётко определены протоколы, которые обеспечивают доступ к нескольким полезным службам: управлению ресурсами, доступа к данным, обнаружения ресурсов и так далее. Также на каждом уровне для интерфейсов API's может быть установлено, какая реализация (идеально, обеспеченная инструментариями SDK's от сторонних фирм) протокола обмена информацией посылает соответствующим службам сообщения для выполнения желаемых действий.

Необходимо подчеркнуть, что "Приложения” на практике обращаются к очень сложным средам и библиотекам высокого уровня и могут обеспечивать функции, которые непосредственно не отражаются в конкретном протоколе, но могут объединять операции протокола с обращениями к дополнительным API's, а также осуществлять локальную реализацию функций.

 

 

ВЫВОДЫ И ПЕРСПЕКТИВЫ

 

Представленная перспектива грид и ВО, разумеется, не является единственно приемлемой. Ниже мы кратко рассмотрим (с критическими репликами) несколько альтернативных перспектив (указаны курсивом).

Грид - это следующая генерация Интернет. Грид не является альтернативой интернет: это скорее всего набор дополнительных протоколов и служб, построенных на базе протоколов и служб интернет, для поддержки разработки и использования приложений в крупномасштабной среде обработке данных и вычислений. Любой ресурс, который "является частью грид", также, по определению, "является частью Сети".

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

Грид требует распределённой операционной системы. С этой точки зрения программное обеспечение грид должно предусматривать такие службы операционной системы, инсталлируемые на каждой используемой в ВО системе, которые обеспечивают для грид, те же возможности, какие предоставляет операционная система отдельного компьютера: а именно, прозрачность в отношении размещения, именования, безопасности и т.д. Другими словами, с этой точки зрения программное обеспечение грид рассматривается как средство создания некой виртуальной машины. Тем не менее, мы считаем, что такой взгляд противоречит нашим основным целям: широкому распространению и интероперабельности. Мы убеждены, что подходящая модель - это просто набор интернет-протоколов, который обеспечивает широкий спектр ортогональных служб, направленных на уникальные проблемы, возникающие в сетевой среде. Высокая степень физической и административной гетерогенности, имеющей место в среде грид, означает, что традиционная прозрачность недостижима; с другой стороны, это открывает возможность достижения соглашения о стандартных протоколах. Архитектура, предлагаемая в данной работе, преднамеренно открыта, а не зафиксирована: она определяет компактный и минимальный набор протоколов, который должен понимать ресурс, для того, чтобы быть включённым в грид; вне этого набора он воспринимается только для обеспечения инфраструктуры, внутри которой может быть задано много способов его использования.

Грид требует новых моделей программирования. Программирование в грид-среде порождает проблемы, которые не встречаются при использовании последовательных или параллельных компьютеров, например такие, как множество административных доменов, новые виды отказов и большие разбросы в производительности. Тем не менее, мы убеждены, что эти проблемы не главные и что базовая модель программирования при этом фундаментально не изменяется. Так в одних рабочих контекстах абстракция и инкапсуляция могут уменьшить сложность и повысить надёжность. А в других случаях желательно разрешить возможность конструирования широкого разнообразия высокоуровневых абстракций и не сосредотачиваться на частном подходе. Так, например, разработчику, который верит, что универсальная модель распределённой разделяемой памяти поможет упростить создание грид-приложения, следует реализовать эту модель в терминах грид-протоколов, расширив или заменив эти протоколы, если они действительно неадекватны поставленной цели. Аналогично, разработчику, который полагает, что все грид-ресурсы должны представляться пользователям в виде объектов, потребуется просто создать "объектно-ориентированный API" в терминах грид-протоколов.

Грид делает ненужными высокопроизводительные компьютеры. Сотни, тысячи и даже миллионы процессоров, которые могут быть объединены внутри ВО, представляют собой источник исключительной вычислительной мощности, если их удаётся использовать в некой удобной форме. Это вовсе не означает, что традиционные высокопроизводительные компьютеры устарели. Для решения многих проблем необходимы сильно связанные компьютерные конфигурации с низкими временами ожидания и высокой пропускной способностью; грид-компьютинг может значительно увеличить, а не уменьшить спрос на такие системы, облегчая доступ к ним.

 

 

ЛИТЕРАТУРА

 

1. Бережнов Г.В. Виртуальная организация. Неравновесный принцип управления развитием предприятия. Российское предпринимательство.// Журнал, 2003. - №12
2. Вютрих Х. А., Филипп А. Ф. Виртуализация как возможный путь развития управления//Проблемы теории и практики управления, N5, 1999.
3. Гольдштейн Г.Я. Стратегический инновационный менеджмент: тенденции, технологии, практика. Таганрог: Изд-во ТРТУ, 2002
4. Пономарев И.П. Виртуальная организация: предпосылки возникновения новой организационной формы. Менеджмент в России и за рубежом// Журнал, 2001. - №5
5. Санкова Л. HR-менеджмент в виртуальных организациях: проблемы и перспективы. Управление персоналом.// Журнал, 2007. - №5
6. Сердюк В.А. Сердюк В.А. Сетевые и виртуальные организации: состояние и перспективы развития // Менеджмент в России и за рубежом. 2004. №2.