Определение виртуальных организаций

Размещено на http://www.allbest.ru/

Белорусский государственный университет

Факультет радиофизики и компьютерных технологий

Реферат на тему:

«Определение виртуальных организаций»

Выполнила: Шевцова В.

Минск

2011

Оглавление

ВВЕДЕНИЕ

1. СУЩНОСТЬ ВИРТУАЛЬНЫХ ОРГАНИЗАЦИЙ

1.1 Интероперабельность

2. ОПИСАНИЕ АРХИТЕКТУРЫ ВИРТУАЛЬНЫХ ОРГАНИЗАЦИЙ

2.1 Фабрикаты: Интерфейсы локального управления

2.2 Связь: Лёгкое и безопасное общение

2.3 Ресурс: Разделение отдельных ресурсов

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

2.5 Приложения

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

4. ЛИТЕРАТУРА

ВВЕДЕНИЕ

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

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

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

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

* чрезвычайно гибкие отношения в широком диапазоне возможных сетевых решений: от схемы “клиент - сервер” до схемы “одноранговая сеть”;

* сложный и высокоуровневый контроль за тем, как используются разделяемые ресурсы, включая средства мелкоструктурного контроля доступа, делегирование и применение локальных и глобальных политик;

* возможности разделения разнообразных ресурсов: от программ, файлов и данных до компьютеров, датчиков и сетей;

* разнообразные по критериям производительности и стоимости пользовательские режимы, предусматривающие решение проблем обеспечения качества обслуживания, планирования, совместной загрузки и учёта использования ресурсов.

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

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

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

1. СУЩНОСТЬ ВИРТУАЛЬНЫХ ОРГАНИЗАЦИЙ

1.1 Интероперабельность

ВО должна позволить в корне отличным группам, организациям и/или отдельным пользователям контролируемо разделять ресурсы, так чтобы они могли сотрудничать при достижении некой общей цели. То есть для обеспечения эффективной деятельности ВО необходимо иметь возможность устанавливать отношения разделения между любыми потенциальными участниками. Таким образом, центральной проблемой, требующей разрешения, оказывается интероперабельность (взаимодействие различных программных и аппаратных средств - interoperability). В контексте рассмотрения сетевых технологий интероперабельность означает общность протоколов. Поэтому рассматриваемая система, прежде всего, является архитектурой протоколов, определяющих базовые механизмы, посредством которых пользователи и ресурсы ВО договариваются, устанавливают, управляют и используют отношения разделения. Основанная на стандартах открытая архитектура способствует расширяемости, интероперабельности, мобильности и совместному использованию общих программ; стандартные протоколы облегчают определение стандартных служб, которые обеспечивают усовершенствование возможностей. Необходимо также разработать, так называемые Интерфейсы Прикладного Программирования (Application Programming Interfaces - API) и Инструментарий Разработки Программного обеспечения (Software Development Kits - SDK). Вместе, эта технология и архитектура составляют то, что часто называется как промежуточное программное обеспечение (службы, необходимые для поддержки общего набора приложений в распределённой сетевой среде - “middleware”).

Почему интероперабельность является столь фундаментальной системной возможностью? Дело состоит в том, что мы должны гарантировать формирование отношений разделения между произвольными группами, вступление новых участников динамично и через различные платформы, языки и программные среды. В таком контексте механизмы приносят мало пользы, если они не определены и не реализованы так, чтобы их интероперабельность не лимитировалась границами организаций, политиками управления и типами ресурсов. Без интероперабельности ВО приложения и участники вынуждены устанавливать двусторонние договорённости о разделении, поскольку нет гарантии, что механизмы, используемые между любыми двумя группами могут быть расширены для любых других групп. Без такой гарантии динамичное создание ВО вовсе невозможно, а количество типов ВО, которые могут быть сформированы, строго ограничено. Точно также как Web революционизировала разделение информации, предоставив для целей информационного обмена универсальный протокол и синтаксис (HTTP и HTML), необходимы стандартные протоколы для повсеместного разделения ресурсов.

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

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

Почему мы также обсуждаем здесь возможности API и SDK? Конечно, есть нечто более значимое для ВО чем интероперабельность, протоколы и службы. Разработчики должны иметь возможность создавать изощрённые приложения в сложной и динамичной исполнительной среде. Пользователи должны иметь возможность работать с этими приложениями. Работоспособность приложений, их исправность, стоимость разработки и сопровождения - всё это чрезвычайно важные факторы. Стандартные абстракции, API's и SDK's помогают ускорить разработку программ приложений, обеспечивают совместное использование общих программ и улучшают переносимость приложений. API's и SDK's являются дополнением, а не альтернативой протоколам. Без стандартных протоколов интероперабельность может быть достигнута на уровне API только путём использования всюду единой реализации приложения, что невыполнимо во многих заинтересованных ВО, или на основе знания каждой реализацией деталей каждой другой реализации.

2. ОПИСАНИЕ АРХИТЕКТУРЫ ВИРТУАЛЬНЫХ ОРГАНИЗАЦИЙ

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

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

При определении различных уровней грид-архитектуры мы будем следовать принципам “модели песочных часов” (“hourglass model”). Узкое горло песочных часов устанавливает небольшой базовый набор абстракций и протоколов (например, таких как TCP и HTPP в интернет), на основе которых могут быть отображены многие различные дисциплины (режимы) верхнего уровня (вершина песочных часов), и которые сами могут быть отображены на основе многих различных нижележащих технологий (основание песочных часов). По определению, количество протоколов, установленных горлом должно быть небольшим. В нашей архитектуре горло песочных часов состоит из протоколов Ресурсов и протоколов Связи, которые облегчают разделение отдельных ресурсов. Протоколы этих уровней сконструированы так, что могут быть реализованы поверх разнообразного ряда типов ресурсов, определённых на уровне Фабрикатов, в свою очередь, они могут быть использованы для разработки широкого ряда глобальных служб и специфических прикладных режимов на уровне Кооперации, названном так, потому, что именно здесь достигается согласованное (совместное) использование множества ресурсов.

Рис. 1. Многоуровневая грид-архитектура и её соотношение с Интернет-архитектурой протоколов

2.1 Фабрикаты: Интерфейсы локального управления

Грид-уровень Фабрикатов (Fabric layer) предоставляет ресурсы, при разделяемом доступе к которым грид-протоколы работают в качестве связующих механизмов: например, вычислительные ресурсы, системы хранения, каталоги, сетевые ресурсы и сенсоры. “Ресурс” может быть логической сущностью, например такой, как распределённая файловая система, кластер компьютеров или распределённый пул компьютеров; в таких случаях применение ресурса может повлечь использование внутренних протоколов (например, протоколов сетевой файловой системы NFS или протоколов управления системными процессами сопровождения кластерного ресурса), но они не имеют отношения к грид-архитектуре.

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

Практика подсказывает, что, как минимум, ресурсы должны, с одной стороны, обладать справочными (enquiry) механизмами, которые разрешают раскрывать их структуру, состояние и возможности н(апример, поддерживают ли ресурсы предварительное резервирование), и с другой - механизмами управления ресурсами (resource management), осуществляющими некоторый контроль предоставляемого качества обслуживания.

2.2 Связь: Лёгкое и безопасное общение

Уровень Связи (Connectivity layer) устанавливает базовый набор коммуникационных и аутентификационных протоколов, необходимых для выполнения грид-специфических сетевых транзакций. Коммуникационные протоколы обеспечивают возможность обмена данными между ресурсами уровня Фабрикатов. Для обеспечения безопасных криптографических механизмов, используемых при верификации идентичности пользователей и ресурсов, протоколы аутентификации основываются на коммуникационных службах.

Требования, предъявляемые к протоколам уровня Связи, включают решение вопросов передачи информации, её маршрутизации и присваивания имён. Несмотря на существование определённых альтернатив, всё же почти во всех практических ситуациях эти протоколы будут почерпнуты из стека протоколов TCP/IP: конкретно, из уровня интернет (протоколы IP и ICMP), уровня передачи данных (протоколы TCP, UDP), и уровня приложений (протоколы DNS, OSPF, RSVP и др.) многоуровневой архитектуры протоколов интернет. Это, конечно, не означает, что в будущем грид-связи не потребуют новых протоколов, которые будут учитывать конкретные типы сетевых механизмов.

Что касается вопросов безопасности на уровне Связи, отметим, что из-за сложности проблемы безопасности важно, чтобы любые решения, по возможности основывались на существующих стандартах. Для решения вопросов связи применимы многие из стандартов безопасности, разработанные в контексте пакета протоколов интернет.

Механизмы аутентификации для среды ВО должны обладать следующими свойствами:

* Однократная регистрация: Пользователи должны иметь возможность регистрироваться (“log on”) в системе только однажды и затем иметь доступ к множеству грид-ресурсов, определённых на уровне Фабрикатов, без дополнительного вмешательства со стороны пользователя.

* Делегирование: Пользователь должен иметь возможность наделять программу способностью выполняться от имени этого пользователя так, что программа может иметь доступ к ресурсам, на которых данный пользователь авторизован. Программа также должна (дополнительно) иметь возможность обусловлено делегировать подмножество своих полномочий другой программе (иногда это называется ограниченным делегированием).

* Интеграция с различными локальными механизмами безопасности: Каждый сайт или провайдер ресурсов может применять самые разнообразные локальные механизмы безопасности, включая Kerberos и средства безопасности Unix. грид-службы безопасности должны уметь взаимодействовать с этими разнообразными локальными механизмами. Практически невозможно требовать единообразия локальных механизмов безопасности, а скорее необходимо обеспечить возможность отображения грид-механизмов безопасности на аппарат локальной среды.

* Отношения доверия, опирающиеся на пользователя: Для того, чтобы пользователь мог работать с пулом ресурсов, предоставленных многими провайдерами, как с единым целым, система безопасности не должна требовать от каждого провайдера ресурсов согласования или взаимодействия с каждым другим провайдером при конфигурировании среды безопасности. Например, если пользователь обладает правом использования сайтов A и B, то он должен иметь возможность работать с сайтами A и B вместе, не требуя, чтобы администраторы этих сайтов взаимодействовали по данному поводу.

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

2.3 Ресурс: Разделение отдельных ресурсов

Уровень Ресурсов (Resource layer) основывается на протоколах коммуникации и аутентификации уровня Связи и определяет протоколы (а также API's и SDK's), обеспечивающие для отдельных ресурсов возможности безопасной инициализации, мониторинга и управления операциями разделения на отдельных ресурсах. Для осуществления доступа и контроля локальных ресурсов процедуры уровня Ресурсов, реализующие эти протоколы, обращаются к функциям уровня Фабрикатов. Протоколы уровня Ресурсов касаются исключительно отдельных ресурсов и поэтому игнорируют вопросы глобального состояния и неделимых операций, применяемых к множеству распределённых ресурсов; такого рода проблемы касаются обсуждаемого ниже уровня Кооперации.

Можно выделить два основных класса протоколов уровня Ресурсов:

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

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

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

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

В то время, как уровень Ресурсов нацелен на взаимодействие с одним ресурсом, расположенный выше уровень рассматриваемой архитектуры содержит протоколы и службы, (а также 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 базировались на стандартах.

2.5 Приложения

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

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

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

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

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

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

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

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

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

4. ЛИТЕРАТУРА

1. Ian Foster, Carl Kesselman, Steven Tuecke (May 10, 2001). "The Anatomy of the Grid: Enabling Scalable Virtual Organizations" (PDF). International Journal of Supercomputer Applications. Retrieved October 15, 2011.

2. M. Coppola, Y. Jйgou, B. Matthews, C. Morin, L. P. Prieto, У. D. Sбnchez, E. Y. Yang, H. Yu. (March/April 2008). "Virtual Organization Support within a Grid-Wide Operating System". Internet Computing 12 (2): 69-76. doi:10.1109/MIC.2008.47.

Размещено на Allbest.ru