|
UP:
4.7 Прикладные сети Интернет |
|
UP:
4.7 Прикладные сети Интернет |
4.7.1 Сети GRID
Семенов Ю.А. (ГНЦ ИТЭФ)
(Обзор подготовлен по заказу ИАЭ им Курчатова)
Прогресс в области разаботки новых вычислительных устройств и сетевых технологий впечатляет. Только за последние 15 лет тактовая частота персональных машин выросла с 10 МГц до 5ГГц (500 раз), а пропускная способность сетей с 10 Мбит/с до 100 Гбит/с (10000 раз).
Но не за горами некоторые принципиальные ограничения, например, постоянная времени поляризации диэлектрика равна 10-13сек, что устанавливает верхний предел на тактовую частоту любых операций на уровне ~1013 Гц. (ТГц).
Трудно себе представить, что человечество смирится с ограничениями вычислительных возможностей. Одним из путей решения проблемы – параллельное выполнение большого числа операций и распределенная структура вычислительной системы. Такие технологии уже используются, например, при построении Ethernet-интерфейса для скорости 10 Гбит/сек (смотри Fast Ethernet).
Связь между производительностью вычислителя и потребной пропускной способностью каналов обмена устанавливает эмпирический закон Amdahl, который утверждает, что каждому миллиону операций в секунду процессора должна соответствовать пропускная способность ввода/вывода, равная мегабиту в секунду.
В какой-то мере техника WWDM (Wide Wavelength Division Multiplexing) может быть отнесена к методике распараллеливания операций.
Технология GRID полностью укладывается в эти рамки. Она позволила существенно снизить стоимость выполнения вычислительных операций.
GRID позволяет выявить и использовать свободные вычислительные ресурсы. Эта система для передачи программ и данных использует стандартные каналы и протоколы (Ethernet, SDH, ATM, TCP/IP, MPLS и т.д.). Преимущества GRID особенно значимы для задач, где допускается распараллеливание расчетов. Пока не сложилось точное определение того, что следует считать GRID. К этому классу относят и системы со специализированными шинами или сетевыми сегментами (область супер-ЭВМ) и системы объединенные через Интернет (слабо связанные GRID). Технология GRID, решая свои проблемы, сама становится движущей силой при разработке новых сетевых технологий (напр. GRIDFTP и др.).
Широкое внедрение в телекоммуникации оптоволоконики (смотри оптоволокно) открывает дополнительные возможности, в том числе и для систем GRID. Так как для получения требуемой полосы пропускания достаточно 2нм в окне прозрачности волокна, открываются возможности мультиплексирования десятков потоков в пределах одного волокна.
При современных скоростях обмена (более 1 Гбит/с) транспортный протокол ТСР (L4) стал ограничивать эффективность обмена (см. модели реализации и модификации протокола в модели). Проблемы возникают при больших произведениях полосы пропускания B и RTT.
В последние годы в связи с мультимедиа разработаны методы и протоколы гарантии качества обслуживания QoS. Это, прежде всего, RSVP-TE (см. IntServ) и MPLS-TE (см. DiffServ). Для динамического формирования приоритетных потоков более привлекателен MPLS-TE (разделение потоков по флагам DSCP) особенно в случае единого сервис-провайдера. Но при соединениях точка-точка это не существенно.
Техника гарантии QoS позволяет разделить информационные потоки по приоритетам, а это в свою очередь позволяет оптимизировать вычислительный процесс в распределенной среде. Одной из проблем в этом случае оказывается отсутствие совместимой техники гарантии QoS в LAN и WAN.
Для обеспечения QoS может использоваться протокол IEEE 802.17 (RPR - Resilient Packet Ring, смотри 802.17).
Появление протокола (GMPLS) открывает дополнительные возможности в сфере передаче программ и данных. Поскольку протокол GMPLS практически работает на уровне L1, значение RTT оказывается минимизированным.
По своей природе GMPLS в некоторых случаях имеет проблемы с поддержкой динамической маршрутизации, да и время реконфигурации из-за механической перенастройки зеркал достаточно велико.
Здесь соединение происходит по схеме Е2Е и по этой причине не возникает необходимости в буферизации (отсюда следует минимизация RTT).
Сети на основе GRID могут быть использованы для:
Некоторые из более ранних коммерческих версий нашли применение в следующих отраслях промышленности:
Центр Развертывания и Поддержки Интеграции Исследования GRID, предлагает обширный список проектов GRID, www.grids-center.org/news/news_deployment.asp. Сопоставим плюсы и минусы технологии GRID.
Минусы
Плюсы
В настоящее время существует три типа GRID:
Технология GRID возникла в результате стандартизации оборудования и программного обеспечения. Одним из важных аспектов технологии явилась виртуализация систем и процессов, включая процессы управления. Наиболее важные стандарты, которые стоит рассмотреть, относятся к GRID/SOA и включают в себя:
Есть множества определений "вычислительной архитектуры GRID". Некоторые определения очень широки и рассматривают кластеры серверов, которые используют общий источник данных. Другие определения описывают GRID, как распределенную сетевую среду, которая использует тысячи информационных систем и других субсистем памяти. Остальные определения лежат где-то между этими двумя. С нашей точки зрения, GRID’ы состоят из:
| GRID – архитектура, позволяющая распределенным системам обмениваться ресурсами, совместно производить вычисления и хранить информацию. |
| Важным стимулом внедрения GRID явилось и то, что большинство информационных центров используют свои ресурсы не более чем на 30% (Forrester Research). Побочным стимулом к развитию данной технологии был и тот факт, что в существовавших центрах до 75% стоимости стало составлять питание, охлаждение и управление. |
Ресурсы, которые могут быть доступными, для выполнения вычислительных задач, называются виртуальными (нереальными до тех пор, пока они не понадобятся). На рис. 1 показана виртуализация в качестве уровня, относящегося к инфраструктуре SOA. Если требуются дополнительные ресурсы вычисления или хранения, SOA посылает этому слою запрос о необходимости увеличения вычислительной мощности, оперативной или дисковой памяти слою виртуализации, задачей которого является нахождение дополнительных ресурсов (локально или во внешней сети).
Рис. 1. Виртуализационный слой (см. Clabby_GRID_Report)
Многие из самых емких вычислительных приложений исследовались и разрабатывались различными научными сообществами, и не должно удивлять то, что эти сообщества были ранними создателями технологии GRID, которые могли использовать незадействованные вычислительные возможности. Вычислительные GRID’ы, использовались в течение более чем десятилетия в этих сообществах для того, чтобы соединить мощности тысяч PC и серверов для создания среды, которая может обеспечить супервычислительные возможности (по цене, которая много ниже стоимости суперкомпьютера).
Некоторые из самых известных научных проектов GRID:
Наибольшие усилия в области GRID прикладываются для развития научно-исследовательского проекта “TeraGRID”. TeraGRID был начат национальным научным фондом (NSF) США в августе 2001. Проект рассчитан на многие годы и предполагает создание крупнейшей в мире инфраструктуры GRID для научных вычислений. В 2004, TeraGRID будет включать в себя 20 терафлоп вычислительной мощности, почти один петабайт данных, и среду для визуализации с высоким разрешением для моделирования и симуляции. Поддерживающая GRID сеть будет работать со скоростью 40 гбит/c.
Информационные GRID являются GRID, которые обеспечивают компьютерные ресурсы для углубленного анализа используемых совместно больших баз данных (часто разнородных).
Коллаборационные GRID используются для обработки и интерпретации данных. Эти данные могут иметь визуальную форму, размещены географически рассредоточено, например, это могут быть группы, работающие над проектами по дизайну и моделированию.
Правительства используют распределенное программирование дольше, чем какой-либо бизнес. Использование правительствами распределенных сетей для обороны и разведки, началось задолго до прихода ученых в эту область. Сегодня правительства используют технологию GRID, чтобы понизить эксплуатационные расходы, улучшить использование ресурсов, и стимулирования научные исследований и открытий.
Доклад, подготовленный в прошлом году (его можно найти по адресу www.saugatech.com) компанией Connecticut-based Saugatuck Technology из Коннектикута отмечает, что менеджеры информационных систем плохо понимают различие между вычислительными и прикладными GRID. Так же там сказано, что, хотя 48 % - рассмотренных менеджеров, знакомы со термином "utility computing ", только 2 % действительно понимают, что это такое, Так же там сказано что только 19 % менеджеров, знают и понимают, что такое "GRID computing".
Рис. 2. Различия между вычислительными и прикладными GRID (GRID Computing и Utility Computing) (см. Clabby_GRID_Report))
Существует несколько стандартов, используемых для построения архитектуры, ориентированной на сервисы, и нижележащей архитектуры GRID, которая может поддерживать управление бизнес-процессами. Эти стандарты образуют базовые блоки, которые позволяют посылать запросы приложениям и базам данных.Эти стандарты также позволяют развернуть программное обеспечение, позволяющее упростить управление бизнес-процессом.
К числу стандартов GRID и сопряженных с ними стандартов следует отнести:
Горизонтальная и вертикальная инфраструктура программного обеспечения, которая необходима для обеспечения безопасности, почты, обмена сообщениями, рабочего потока, коллаборации, обменов программа-программа, а также среды совместного использования данных может быть найдена в инфраструктурных предложениях таких компаний как IBM (WebSphere), Microsoft (.NET), BEA (WebLogic) и Sun (ONE). Web-сервисы и XML реализации содержатся в предложениях других поставщиков.
Где найти компоненты SOA?
Пользователи GRID могут:
Для покупателей информационных систем, желающих строить GRID и GRID приложений самостоятельно, существует несколько бесплатных загрузочных модулей GRID, доступных по http://www.GRID-center.org/downloads/down_Home.asp, существует также много компонентов GRID, для которых имеются общедоступные тексты программ.
Есть также несколько открытых источников, где можно найти средства для разработки и развития Веб-служб. Они включают:
Есть множества других инструментов для XML, WSDL, и сред UDDI, которые также доступны.
Есть множество независимых поставщиков ПО GRID, которые строили, собирали, и объединяли ресурс-менеджеров, промежуточное ПО, и компоненты синхронизации данных, описанные выше. Эти решения для GRID обеспечивают интегрированные инструменты развития GRID, управления GRID, промежуточного ПО GRID и средства обслуживания синхронизации данных. Среди этих компаний - разработчиков программного обеспечения грид: AVAKI, DataSynapse, Entropia, Platform и United Devices.
При более детальном рассмотрении продуктов независимых разработчиков видно, что:
Рис. 3. Что обычно предлагают независимые поставщики ПО GRID (см. Clabby_GRID_Report))
Программное обеспечение независимых поставщиков GRID, описанное в предыдущем подразделе, может использоваться для обращения к требуемой прикладной программе в пределах отдела, или решить более широкие проблемы обеспечения предприятия вычислительными ресурсами. Для того, чтобы развернуть такую систему, предприятию не нужно выстраивать сложную архитектуру SOA. Но, для того чтобы желание предприятия использовать технологию GRID, для решения проблем обеспечения, реализовалось, необходимо дополнительное ПО.
В долгосрочной перспективе, первичная цель предприятия должна состоять в том, чтобы найти способ эксплуатировать информационные системы и инфраструктуру и упростить управление бизнес-процессами. Если это будет достигнуто, предприятие будет в состоянии работать более эффективно, быстро отвечать на изменяющиеся условия, уменьшить риски, снизить затраты на ИТ, и открыть новые деловые возможности (приводящие к увеличению прибыли). Способ приспособить информационные системы к управлению бизнес-процессом состоит в том, чтобы построить архитектуру SOA
| Если первичная цель предприятия состоит в том, чтобы найти способ строить сервисную архитектуру, которая облегчает интеграцию бизнес-процессов и их управление, то первичные критерии оценки выбора поставщика должны быть основанными на том, как хорошо поставщик может помочь организации достичь ее цели, используя SOA. |
Рис. 4. Как работает GRID MP (см. Clabby_GRID_Report))
Вследствие высоких достижений в вычислении, хранении данных, и коммуникаций, мы на пороге достижения уровня Peta (1015) - объемов памяти, скорости связи и быстродействия вычислений. Несколько лабораторий Министерства (DOE), создали системы хранения, рассчитанные на петабайты и существуют некоторые научные базы данных, которые превысили размер в один петабайт.
Закон [3] Мура предсказывает удваивание плотности элементов на кристалле каждые 18 месяцев. Эндрю Одлизко и Керри Коффман [4] доказали, что это не так. Они продемонстрировали, что удваивание происходит каждые 12 месяцев. Закон [5] Джилдера предсказывает, что полная емкость оптических транспортных систем удваивается каждые шесть месяцев. Это различие между прогнозами Мура и Одлизко может показаться незначительным. Однако, если посмотреть на рис. 5, можно увидеть, что промежуток между вычислительной мощностью и трафиком - x4 через шесть лет, x16 через 12 лет, и x32 через 15 лет.
Рис. 5. Эволюция разрыва между вычислительной мощностью и ростом трафика за 15 лет. (см. Lambda Data Grid: Communications Architecture in Support of Grid Computing)
Недавние достижения в оптических транспортных технологиях создали некое несоответствие между оптическим миром передачи и электрическим миром переадресации/маршрутизации. Сегодня, одно оптическоое волокно может передать больше трафика, чем все интернет-ядро. Однако оконечные системы с «приложеними интенсивной обработки данных» не имеют доступа к этой полосе пропускания. Кроме того, даже при том, что дисковые затраты относительно невелики, передача огромного количества данных ограничена. Связано это с ограниченной способностью слоя L3. В модели OSI [6], L3 обеспечивает технологию переключения и управления, главным образом в виде пакетной коммутации, создавая логические пути, известные как виртуальные схемы для передачи данных от узла к узлу. L3 не может эффективно передать петабайт или сотни Терабайт, и имеет ограничения в обеспечении обслуживания E-science (см. http://book/itep/ru/4/44/tcp.htm). Дисковая скорость передачи существенно медленнее, чем сеть. Для очень больших наборов данных, время доступа не является существенным, и удаленный доступ к памяти быстрее, чем местный дисковый доступ.
Существенные противоречия между требованиями приложений E-science и доступными ресурсами, мотивирует нас, на то, чтобы создать архитектуру гармонического сочетания ресурсов, объединяющую вычислительные grid и оптические сети.
Есть три фундаментальных технологий выбора, к которым можно обратиться, при поиске решения для «приложений с интенсивным обменом данными».
Очевидным решением будет использование таких существующих технологии как L3, механизмов маршрутизации и Интернет для больших объемов данных в исследованиях E-science. Однако, ограничения, в этих технологиях делают эти решения менее эффективными. В вопросе использования пакетной коммутации против коммутации каналов, исторически победила пакетная коммутация. В пределах контекста больших объемов данных, этот вопрос должен быть исследован снова [7]. В нашей области, канальная коммутация L1 при ограниченном адресном пим адресным пространством. Маршрутизайия и использование L3 удобно для маленьких пакетов и коротких продолжительностей, но для больших объемов данных и больших продолжительностей она теряет свою эффективность. В механизмах L3, просмотр маршрутных таблиц рассчитан для большие потоки данных. Когда получатель известен заранее, в этом больше нет необходимости, экономя миллиарды идентичных принимаемых решений для больших объемов данных. В Интернете, равнодоступность важна и поэтому продумана в организации сетевых протоколов. В частной сети, равнодоступность не проблема.
Совет National Science Foundation (NSF) работает над “Исследованием киберинфраструктуры 21го века. [8]". На рис. 6 представлена выдержка из этого документа.
| Как сворачивается белок? Что случается с пространством и временем, когда две черных дыры соприкасаются? Какое воздействие оказывает геннгенное многообразие на экологическое сообщество? Каковы ключевые факторы, влияющие на изменение климата? Может ли одно из триллионов столкновений в Большой адронном коллайдере привести к возникновению черной дыры? Можем ли мы создать систему контроля здоровья для каждого индивида? На какие вопросы, которые будут возникать при обработке больших объемов данных, поступающих от телескопов, сетей датчиков и т.д. в будущем, мы сможем найти ответы? Ответы на эти вопросы только сейчас можно начинать получать из-за существенных успехов в области информационных технологий.. |
Рис. 6. Выдержка из Исследования киберинфраструктуры 21-го века.
Для иллюстрации масштаба объемов данных рассмотрим некоторые проекты из области e-Science.
| Физика высоких энергий (HEP) | 1 петабайт/год - 1экзабайт/год. |
| Астрофизика | 250-500 терабайт/год. |
| Наука об окружающей среде | от 330 терабайт до 1,5 петабайт. |
| Наука о жизни | Национальный институт здоровья (NIH) [21] помогает финансировать эксперименты, данные,полученные от которых, будет лежать в пределах от сотен терабайт к десяткам петабайт. Исследование в области биоинформатики требует интенсивных вычислений, приблизительно на уровне сотен петафлоп в секунду. Вычисления, необходимые в генной инженерии только для одного гена, требует приблизительно 800 компьютеров на протяжении года |
Задача #1: Пакетное переключение - не подходящее решение для приложений интенсивной передачи данных
Задача #2: Вычислительный GRID с управлнием сетевыми ресурсами
Задача #3: Управление большим трафиком данных для e-Science
Чтобы работа исследователей E-science была более эффективной, они должны получить удаленный доступ к большим объемам данных. Исследователи должны получить возможность фильтровать данные, поступающие отдаленных источников в реальном масштабе времени, или из огромного отдаленного хранилища, и отбирать лишь небольшую долю этих данных. Проблема здесь связана с получение доступа к нужной информации, размещенной в определенном месте, в нужное время.
Если бы коннективность сети обеспечивала доступ, к нужным данным, в нужном место, в нужное время, то не возникало бы проблем с управлением экспериментом с рабочего места исследователя. Это привело бы модификации экспериментальной установки, значительно сократив время обработки, и увеличив эффективность специализированных средств обслуживания.
Одно из основных способов оценки изображения и интеграции данных является визуализация с привлечением дисплея с высоким разрешением и возможности интерактивного управления в реальном масштабе времени . Эти дисплеи могут управляться несколькими специализированнвми компьютерами, функционирующими параллельно и посылающими свои данные на несколько дисплеев, работающих совместно для получения изображения большого размера (например, типа CAVE). Каковы скорости передачи данных необходимы для этого, даже в пределах одной лаборатории? Рассмотрим 100 мегапиксельный дисплей. Полоса пропускания для этого устройства составляет 72 Gbps для кластера из 8 узлов OptIPuter, или 576Gbps для кластера из 64 узлов. Это составляет более половины терабит в секунду.
Физика высоких энергий (HEP) – главный направление исследований, спонсируемое Министерством энергетики Соединенных Штатов (DoE). Сообщество HEP поддерживает большое количество прикладных и фундаментальных исследований в физике, так же НИР и ОКР в смежных областях . Планирование, выполнение и анализ этих программ исследования требуют координации больших, распределенных команд людей и учреждений.
Таблица 1: Теоретические и экспериментальные области исследований спонсируемые DoE
| Отрасль | Ожидаемая генерация данных в 2008 |
| CEBAF (экспериментв по исследованию структуры адронов) | <10 PB/год |
| RHIC (Эксперименты с кварк-глюонной плазмой) | 5 PB/ год |
| CERN LHC (поиск Хиггс-бозона) | 10 PB/ год |
| SLAC (BaBar эксперименты) | 1 PB/ год |
| Ядерная физика | 3 PB/ год |
| Ядерный синтез с магнитным удержанием плазмы | 1 PB/ год |
| Вычислительная гидродинамика | 2 PB/ год |
Таблица 2: Объем научных данных, полученных за 2008 год
| Отрасль | Ожидаемая генерация данных в 2008 |
| Изучение климата | >10 PB |
| Биоинформатика (Геномика, исследование протеинов, метаболизм) | >20 PB |
| Астрофизика | 8 PB |
| Цифровой обзор неба | 15 TB |
| Химия | 4 PB |
| Материаловедение (нейтроны и фотоны) | 0.35PB |
Рис. 7. Информационный лямбда-GRID, как часть киберинфраструктуры многослойной архитектуры (см. Lambda Data Grid: Communications Architecture in Support of Grid Computing)
Быстрое развитие оптической сетевой технологии значительно расширило количество пропускаемой информации. Теперь, всего одно оптическое волокно может обеспечить сотни 10 или 40 Гбит/с каналов данных (Лямбд), с емкостью более 6Tбит/c, что приблизительно соответствует трафику, циркулирующему в опорном канале Интернет.
Информационный трафик TCP по оптической сети через Атлантический океан составляет 20 Мбит/c. Новые транспортные протоколы были предложены, чтобы улучшить TCP. [51, 52, 66].
Обработка передачи 1 Мбит/c отличается от техники работы с одним из multi-10 Гбит/с. Это – на 4 порядка сложнее. Имея дело с маленькими трубами в диапазоне 1-100 МБ, мы можем сделать некоторую оптимизацию в стеке протоколов. Однако, имея дело с большими трубами в диапазоне multi-10 Гбит/с, стек протоколов и прикладная оптимизация могут препятствовать обработке данных. Радикальные изменения требований к полосе пропускания предполагают инновационные решения, которые будут различать маленькие потоки и большие.
Исторически, WAN-трафик был слабым местом сети и был относительно дорогим. Введение оптической передачи нейтрализует эти ограничения. Анализируя общую стоимость электрической маршрутизации, по сравнению с оптической, передача в рамках L3 в несколько раз дороже, чем в L0. Порты маршрутизатора являются более дорогостоящими, чем оптические порты и они же являются источником некоторых узких мест. Другими словами, передача фотонов по сравнению с передачей электронов относительно недорога.
Для быстрого доступа к большому набору данных была разработана передовая и эффективная архитектура памяти . Это система уникальна и очень дорога. В прошлом дисковая скорость передачи, предполагалась более высокой, чем WAN. В последнее время, оптическая передача стала намного быстрее, внутренней компьютерной шины или шины кластера. Копирование данных в локальное хранение может оказаться менее эффективным, чем запрос в отдаленную память через выделенный оптический канал с малой задержкой. Эти разработки проложили путь для удаленному прямому доступу к памяти (RDMA) вместо копирования на локальный диск. Это позволять получить удаленный доступ к данным.
Интернет-архитектура не может реалистично переместить десятки Терабайт или петабайт. Пакетная коммутация - эффективная технология для транспортировки коротких пакетов не была достаточно приспосаблена, чтобы стать адекватной для передачи больших объемов данных. Принятие решений о переадресации Ethernet-кадров каждые 1500 байтов достаточно для электронных писем или 10 КБ-100k веб-страниц.
Это не оптимальный механизм, если мы имеем дело с объемами информации в шесть или в девять раз больше. Например, при передаче 1.5TB файлов с помощью пакетнойю коммутации, те же самые решения переадресации должно быть принято миллиард раз, приводя к чрезвычайно неэффективному процессу.
Существующая архитектура L3 не предназначена для перемещения мульти терабайтов данных по Лямбдам multi-10Гбит/c по каналам с большими значениями RTT. Медленный старт, управление перегрузкой, и механизмы исключения перегрузки работают для большого числа небольших потоков, но неоптимальны для выделенных каналов точка-точка большой длины. Новые, улучшенные, механизмы L4 позволят получить более быструю передачу. Они функционируют лучше для выделенных оптических каналов.
С недавними достижениями в Wavelength Division Multiplexing (WDM),и Ultra Long Haul (ULH), передача данных более чем на тысячи километров через оптические каналы может быть реализована без регенерации сигнала. Сравнивая передачу L1 с маршрутизацией L3, следует констатировать, что число точек переадресации значительно сокращается.. При передаче на очень длинные расстояния, нет необходимости принимать решение о переадресации в каждом IP-маршрутизаторе. Вместо этого оптическая передача может быть реализована за один или несколько шагов. Для большого числа коротких передач маршрутизация работает хорошо. Однако, дальняя транспортировка больших объемов данных по оптике гораздо эффективнее.
В случае ограниченной полосы пропускания, задержка сети не является критической; тогда как, в случае широкополосных каналов сеть не может функционировать эффективно. TCP-отклики работают хорошо при малых значениях (RTT) и узкополосных каналах. Это было разработано и оптимизировано для ЛВС или узкополосных WAN. Ограничения TCP в широкополосных каналах и большом RTT хорошо-описаны в [47] [66].
Реактивность характеризуется временем, которое необходимо для восстановления системы после потери одного пакета. Она определяет, насколько быстро канал сможет работать с прежней пропускной способностью, после того как произошла потеря пакета. Отбрасывание пакетов является механизмом обеспечения балансировке обменов с точки зрения QoS в сетях с коммутацией пакетов. Такой механизм встроен в протокол TCP для управления перегрузкой. Например, 15 лет назад, в LAN с RTT = 2ms и 10Мбит/c, реактивность была около 1.7ms. В настоящее время для 1Гбит/c LAN с RTT порядка 2ms, реактивность составляет около 96ms. В среде WAN, RTT очень велико, напр., RTT для канала CERN-Чикаго равно 120ms, а до Токио - 300ms. В этих случаях реактивность может достигать часа [66].
В экспериментах OptIPuter, использовавших канал между Чикаго и Амстердамом получена полоса пропускания 4.36Mbs, при использовании немодифицированного протокола TCP. Новый протокол, базирующийся на UDP, показал полосу пропускания 700Mbs-920Mbs. Выделенные каналы для немодифицированного протокола TCP дает 1% использования полосы по сравнению с 92% для нового UDP. В выделенных оптических каналах не возможно совместное использование, и следовательно, проблема справедливого использования полосы не встает. Здесь нет конкуренции за использование ресурсов сети, а справедливое распределение ресурсов возможно за счет предварительного резервирования и диспетчеризации. По этой причине реактивность не представляет никакой проблемы.
Новые Транспортные Протоколы. - Много новых протоколов было разработано, чтобы устранить проблему сетевых ограничений, среди них - GRIDFTP [41], FAST [69], XCP , Parallel TCP, и Tsunami, SABUL/UDT [47]. Эти исследовательские проекты, на ряду с другими подобными проектами обеспечили улучшение основных транспортных механизмов, гарантируя эффективное использование широкополосных каналов пропускания. Улучшения в этих протоколах достигнуты за счет трех механизмов: 1) настройки TCP и UDP-узлов; 2) передачи нескольких потоков параллельно; 3) посылки данных с помощью UDP, используя ТСР для управления.
При использовании дальнего 1Гбит/с канала показало, что GridFTP дает 512Мбит/c [66], Tsunami позволяет достичь 700Мбит/c [66]. SABUL - 910Мбит/c [66], а FAST дал 930Мбит/c для канала между CERN и SLAC. Новые эксперименты по мультиплексированию 1Гбит/c в рамках FAST и SABUL [47] показали, что l-коммутация для 10Gbs обеспечивает лучшее использование сети.
Справедливое распределение ресурсов. - В пакетной коммутации контроль перегрузки и механизм предотвращения перегрузки обеспечивает некоторый уровень справедливого распределения ресурса канала. В случае выделенного канала проблема справедливости не актуальна.
Выделенные каналы и каналы коллективного пользования - многие из новых протоколов ресурсоемки и представляют проблему для справедливого использования кнала несколькими потоками. При разработке протоколов для выделенных каналах справедливость распределения ресурсов не актуальна, так как полоса оптического канала целеком выделяется для одного потока. В выделенных каналах (Lightpath, circuit) нет никакого разделения, и канал предоставляется на определенный период времени.
В настоящее время, коммерческая система DWDM может обеспечить полосу до 6.2Tбит/с, в то время как в лабораториях получена полоса пропускания 26 Tбит/с.
Рис. 8. История программирования и коммуникаций (см. A NETWORKING APPROACH TO GRID COMPUTING, DANIEL MINOLI)
Рис. 9. Временная эволюция GRID (см. A NETWORKING APPROACH TO GRID COMPUTING, DANIEL MINOLI)
Таблица 3. Список некоторых недостатков grid при вычислениях
| Не всегда ясна бизнес-задача | Постановщики задачи должны разработать и грамотно сформулировать бизнес-проблему |
| Процессы должны быть определены | Поставщики должны показывать, возможно ли эффективно управлять процессами GRID, включая модель на случай убытков |
| Должна поддерживаться безопасность | Безопасность важна, особенно в случае Intergrids |
| Сообщение/формулировки должна быть четче | В промышленности до сих пор существует неразбериха между кластерным программированием, виртуализацией, GRID’ом на предприятии и Р2Р. Требуются более четкие пояснения от поставщиков |
| Должны быть устранены собственнические подходы | Ведущие поставщики (Hewlett-Packard, IBM, Microsoft, Platform Computing, Sun Microsystems, Oracle, VMWare/EMC*) до сих пор подходят к теме по-разному и несовместно. Существующие решения программирования GRID ограничены индивидуальными продуктами поставщиков (Платформа GRID от IBM работала на большом количестве открытых стандартов, сравниваемых, в настоящее время, со стандартами других поставщиков) [165]. |
| Устранение узкого подхода разработчиков | К примеру, вычислительная платформа IBM ориентирована главным образом на виртуализации оборудования IBM и баз данных. Следовательно, если компания имеет однородный центр данных (IBM e-сервер, базы данных IBM DB2), то она может извлечь выгоду от использования решений GRID, в других случаях пользы не будет |
| Нормальное функционирование должно проверяться и мониторироваться | Вычислительные системы GRID требуют механизмов соответствующего разделения (зонирования) -, которые предотвращают подавление одних приложений другими при конкуренции за ресурсы (особенно в случае серверной виртуализации). |
Рис. 10. Основные элементы GRID Со стороны пользователя (см. A NETWORKING APPROACH TO GRID COMPUTING, DANIEL MINOLI)
Рис. 11. Дополнительные элементы GRID – Пользовательский взгляд (см. A NETWORKING APPROACH TO GRID COMPUTING, DANIEL MINOLI)
Таблица 4. Функциональные возможности, поддерживаемые GRID
| (Co-)резервирование, технология | Мониторинг |
| Процессы должны быть определены | Поставщики должны показывать, возможно ли эффективно управлять процессами GRID, включая модель на случай убытков |
| Учет и оплата | Гарантия функционирования |
| Адаптация | Удаленный доступ к данным |
| Авторизация и политика безопасности | Размещение ресурсов |
| Распределенные алгоритмы | Определение ресурсов |
| Управление ошибками | Обнаружение ресурсов |
| Высокоскоростная передача данных | Управление ресурсами |
| Идентификация и аутентификация | Развитие системы |
| Обнаружение несанкционированного вторжения |
Функциональный блок безопасности узлов всегда присутствует в среде GRID. Аутентификация и авторизация как «улица с двусторонним движением»; должен быть авторизован не только пользователь, но и вычислительный ресурс. Это является необходимым условием для безопасного (конфиденциального) взаимодействия между внутренними элементами вычислительного GRID’a, так как GRID состоит из устройств и программ, назначение которых не всегда понятно пользователю. Когда пользователь хочет запустить определенный процессор, ему необходимо убедиться, что процессор не взломан и его данные не подвергнутся опасности [72]. Если процессор используется динамически, то идентификация и аутентификация должна пройти до того, как процессор начнет работу в GRID, как это было описано ранее. Центр сертификации (CA) может быть использован для установления идентичности процессора «донора», так же как и пользователя или самого GRID. Некоторые системы GRID обеспечены своим логином (кодом доступа), тогда как другие системы зависят от аутентификации операционных систем пользователей.
Рис. 12. Пример стека протоколов и доступных сетевых сервисов (см. A NETWORKING APPROACH TO GRID COMPUTING, DANIEL MINOLI)
Некоторые понятия, которые необходимо знать:
Фундаментальной концепцией OGSA является то, что сервисная архитектура состоит из компонентов служб GRID, которые работают как специальные Web-сервисы, что предоставляет ряд интерфейсов, отвечающих специальным требованиям [119]. SOA определяет, как взаимодействуют два вычислительных объекта, для того, чтобы один объект дал возможность второму выполнить определенную работы в пользу первого. Эта работа соотносится с сервисом, а действия сервиса определяются языком описаний. Каждое взаимодействие самостоятельно и практически не зависит от другого. Бизнес приложения создаются для автоматизации различных бизнес-процессов, но зачастую без осуществления в них возможности адаптироваться к изменяющимся потребностям; доработка бизнес процессов в данной среде, достаточно трудоемкая задача. Все потому, что бизнес приложения традиционно создаются как единичные, монолитные, включающие в себя все, инструменты. Поэтому любые изменения в них достаточно дороги и времяемки. В среде SOA, приложения создаются в виде набора сервисов, каждый из которых имеет свои задачи и свойства. По мере изменения нужд, некоторые сервисы могут добавляться, некоторые удаляться или дорабатываться.
Web-сервисы обладают следующими характеристиками [85]:
Web-сервис представляет собой систему ПО, идентифицируемую URI, чьи интерфейсы и связи определены и описаны с помощью XML. Он может быть обнаружен другими системами ПО. Эти системы, в свою очередь, могут взаимодействовать с Web-сервисом, используя XML сообщения, передаваемые Интернет протоколами. Язык описаний Web-сервисов (WSDL) фактически является, основанным на XML, стандартом для описания Web-сервисов. Простой протокол доступа к объектам (SOAP) является, основанным на XML, стандартным сетевым протоколом для обмена сообщениями между Web-сервисами (описания W3C).
Выше, кроме того, упоминалась и технология .NET. NET - интернет и Веб стратегия компании Майкрософт, запущенная в 2000 году. Интернет инфраструктура для создания Web-сервисов и других универсальных систем. Она является костяком операционных систем Windows 2000 и Windows XP. В дальнейшем предполагается интеграция .NET во все операционные системы приложения и серверные продукты (в планах создать на основе .NET новую операционную систему Windows, новую версию Office и новое программное обеспечение для разработчиков Интернет приложений). .NET основан на веб-стандартах, таких как: HTTP, протоколах связи между интернет приложениями, XML, формате обмена данными между приложениями; SOAP, стандартном формате для обращения к Web-сервисам; и UDDI, описанном выше, стандарте поиска и исследования Web-сервисов. Web-сервисы предоставляют данные и службы другим приложениям. Среда .NET предназначена для построения и использования Web-сервисов и Web-приложений. Среда .NET содержит библиотеки общих классов (ADO.NET, ASP.NET) и формы Windows, поэтому, она может быть интегрирована в различные компьютерные системы.
Среда .NET нейтральна к различным языкам. Она может поддерживать работу с такими языками как: C++, C#, Visual Basic, JScript (версия Microsoft JavaScript), и COBOL. Web-сервисы являются основными строительными блоками модели программирования .NET Microsoft [16].
Рис. 13. Сетевые роли (см. A NETWORKING APPROACH TO GRID COMPUTING, DANIEL MINOLI)
Рис. 14. Базовая функциональная модель для среды GRID (см. A NETWORKING APPROACH TO GRID COMPUTING, DANIEL MINOLI)
WSDL (язык описаний Web-сервисов) документ определяет Web-сервис, используя, приведенные ниже, основные элементы:
| Элемент | Определяет |
| <portType> | Поставщики должны показывать, возможно ли эффективно управлять процессами GRID, включая модель на случай убытков |
| <Message> | Сообщения, используемые в Web-сервисе. Абстрактное определение передаваемых данных |
| <Types> | Типы данных, используемые в Web-сервисе. Предоставляет информацию о любых сложных типах данных, применяемых в документах WSDL. В случае использования простых типов данных этот элемент не нужен. |
| <Binding> | Протоколы соединения, используемые в Web-сервисе. Описывает, как вызывается операция, с помощью определения протокола и формата данных |
| <Port> | Определяет одиночную оконечную точку в виде адреса для соединения, т.е. оконечную точку соединения |
| <Service> | Определяет адреса портов соединения. Служба – совокупность сетевых оконечных точек или портов |
WSDL документ содержит описания элементов, состоящих из блоков types, message, portType, binding, и service elements, что описано в таблице выше. Основная структура документа WSDL выглядит следующим образом:
<definitions>
<types>
описание типов. . .
</types>
<message>
описание сообщений . . .
</message>
<portType>
описание порта . . .
</portType>
<binding>
описание соединения . . .
</binding>
</definitions>
Web Services Inspection Language (WSIL). WSIL – простой механизм обнаружения Web-сервисов. WSIL – формат XML документа, созданный для облегчения сбора и обнаружения Web-сервисов. Созданный IBM и Microsoft и изданный в конце 2001 года, WSIL является привлекательным за счет своей простоты, по сравнению с UDDI, он прост и лучше «поднимает» существующие Web-сервисы. Модель WSIL децентрализована и «поднимает» существующие Web-сервисы прямо на месте [153].
Universal Description, Discovery, and Integration (UDDI). (UDDI) – стандартный протокол описания Web-сервисов и протокол их поиска. Реестр (UDDI) может содержать метаданные для любых видов сервисов, вместе с вариантами «наилучшей практики», уже определенными для сервисов, описанных с помощью WSDL. За счет разбиения Web-сервисов на группы, взаимодействующие с категориями и бизнес процессами, UDDI способен более эффективно искать Web-сервисы. Спецификация UDDI определяет иерархическую схему XML, что обеспечивает модель для анонсирования, проверки и вызова информации о Web-сервисах [85]. Выбор пал на XML, так как его формат представления данных не зависит от платформы и отражает иерархические взаимосвязи. В UDDI используются технологии, основанные на общих интернет протоколах TCP/IP, HTTP, XML и SOAP. Существует 2 вида UDDI реестров: публичные UDDI реестры – служащие точками сбора различных бизнесов, для уведомления об их сервисах, частные UDDI реестры, которые делают то же самое но для организаций.
UDDI регистр содержит следующие структурные типы данных:
Протокол SOAP (Simple Object Access Protocol). SOAP – простой, основанный на XML, протокол, для обмена информацией в децентрализованной, распределенной среде. SOAP поддерживает различные стили обмена информацией, включая:
SOAP характеризуется:
Сообщение SOAP состоит из (1) SOAP конверта, который содержит две структуры данных, (2) SOAP-заголовка и тела SOAP и (3) информации об именах, служащих для их описания. Заголовок является необязательной частью, он передает информацию о запросе, определенном в теле SOAP. Например, он может содержать информацию по безопасности, деловую информацию или профиль пользователя. Тело содержит запрос Web-сервиса или ответ на него.
Спецификация описывает структуру и тип данных при обмене сообщениями, используя XML – схему. Способ, в котором SOAP используется для посылки запросов и получения ответов от Web-сервиса:
Теперь должно быть очевидно, что, OGSA направлен на стандартизацию адресации (для совместимости), при помощи определения основы структуры приложения GRID. Несколько механизмов, работающих в стандартных формулировках программирования GRID, было описано в предыдущем разделе. По существу стандарт OGSA определяет сервисы GRID, их возможности и то, на каких технологиях они основаны. Однако, OGSA не различает особенностей технической стороны спецификации; целью является определение – что является системой GRID [73]. OGSA называют архитектурой, так как она направлена на построение и установку интерфейсов, из которых могут быть построены, системы, основанные на открытых стандартах WSDL [143].
Таблица 5. Предлагаемый OGSA интерфейс служб GRID
| Тип порта | Операция | Описание |
| GridService | FindServiceData | Запрос различной информации о сервисах GRID, включая основную диагностическую информацию, информацию о интерфейсах и об особенностях сервисов. Поддержка различных языков запросов |
| SetTermination Time | Установка времени уничтожения сервиса GRID | |
| Destroy | Удаление службы | |
| Notification- Source | SubscribeTo-NotificationTopic | Подписка на уведомления о событиях, относящихся к сервисам, и основанная на типе сообщения |
| Notification- Sink | Deliver Notification | Выполнение и асинхронная воставка уведомления |
| Registry | RegisterService UnregisterService | Регистрация приложений GRID. Аннулирование регистрации приложений GRID |
| Factory | CreateService | Создание нового сервиса GRID |
| Handle Map | FindByHandle | Возврат ссылки о службе GRID, ассоциированные с их дескрипторами |
Для любых новых технологий, работники бизнеса ищут ответы на следующие вопросы: Есть ли жесткие стандарты поддержки технологий. Любой опытный планировщик осведомлен о финансовых последствиях использования технологии, которая не стандартизована. В предыдущее главе, в некоторых деталях, был освещен оригинальный стандарт OGSI, выпущенный Мировым Форумом GRID (OGSI определяет службы GRID и основные механизмы создания, управления и взаимодействия с ними). Второй стандарт появился год спустя (на данный момент остается в недоработанном состоянии) и носит название Открытой Архитектуры Служб GRID (OGSA). Как было отмечено ранее, стандарты играют важнейшую роль в коммерциализации Intergrid, так же как и интернет стандарты были решающими для коммерциализации интернета в 90х (см. [66-68]). Эти же самые стандарты могут в дальнейшем использоваться в «GRID предприятия», так же как браузеры, в данный момент использующиеся в интранет приложениях. Эти стандарты могут быть использованы для развития открытых сред аутсорсинга. OGSA определяет сферу важнейших служб, запрашиваемых для поддержки систем GRID в е-науке и е-бизнесе. OGSA определяет сервисы, которые являются составной частью большого количества систем и приложений и определяет функциональные требования и взаимодействие между их центральными службами. Эти же стандарты используются в производственных GRID. OGSA специальный Web-сервис, который предоставляет набор интерфейсов и следует специальным соглашениям. OGSA документ содержит технические стандарты и шаблоны стандартов GGF, OASIS, W3C, что говорит о высокой функциональности OGSA и определяет приоритеты для дальнейшей работы.
OGSI определяет необходимые блоки для построения распределенных систем, включая стандартные интерфейсы и связанные сценарии, для описания и поиска атрибутов сервисов, создания новых сервисов, управления их жизненным циклом и доставку уведомлений. Однако он не определяет все элементы, которые требуются для построения крупных и сложных систем. Но может пригодиться для решения других разнообразных проблем.
Управление ресурсами еще одно мультиуровневое требование, включающее SLA согласование, инициализацию, планирование для различных типов ресурсов и действий.
Одной из первых архитектур была GARA (Globus Architecture for Reservation and Allocation), которая была создана в соответствие с принципами архитектуры Globus [15, 16]. Эта архитектура обеспечивает простой механизм обнаружения и сохранения разнородных ресурсов с допущением, что эти ресурсы могут независимо управляться. GARA была разработана таким образом, что может широко применяться с любыми ресурсами, включая сети, и была предназначена для одновременного использования разнородных ресурсов. GARA определяет механизмы прохождения требований, выдвигаемых приложениями к менеджерам ресурсов, чтобы те, могли обработать запросы, даже если ресурс недоступен или является частью уже запущенного приложения. GARA распространяется и на другие сети и не ориентирована под какой-то конкретный программный слой.
На ранних стадиях GARA использовалась в качестве интерфейса для управляемых сетевых сервисов GRID 3 слоя, основанных на RSVP и интегрированных сервисах QoS (IntServ). Дальнейшие эксперименты основывались на DiffServ. В этом исполнении, сообщения переходят от приложений к ресурс-менеджерам, где присоединя.тся к процессам, которые опрашивают маршрутизаторы DiffServ, выясняя уровень доступности сетевых ресурсов, проверяя соответствующий диапазон полосы пропускания и обеспечения QoS.
В лямбда сетях в основном используются два переключающих элемента: (OADM optical adddrop multiplexer) и (OXC - optical cross-connect). Эти функции сходны с операциями, выполняемыми переключателями SDH-сетей, но в рамках одного оптического волокна. (OADM) используется для подключения терминального оборудования к лямбда сети, путем переключение одной длины волны (или нескольких соседних l) к выходному узлу (drop). Он также может ввести одновременно одну или несколько входных l одинаковой длины волны из узла, для поддержания количества l в главном волокне. Рис. 22 (a) показывает добавление и сброс лямбды 2 из волокна A
Рис. 15. (a) OADM, (b) OXC, (c) OXC с преобразованием длины волны (см. http://www.ringrid.eu/public/deliverables/RINGRID-WP3-D3_1-JKU-State_of_the_Art_in_Networks_final.pdf>RinGrid
)Разновидностью OADM является OADM с переменной конфигурацией или ROADM, в которой выбор какуюдобавляемой лямбды добавлять, осуществляется динамически. Это делает процесс построения лямбда сетей более гибким.
OXC это круговой переключатель каналов, имеющий два входных и два выходных волоконаных входа и выхода, лямбды с волокон на входе могут быть переключены на волокна любого из двух выходов, как показано на рисунке 1122 (b). Здесь нужно соблюдать осторожность, так как мы не можем направить две входных лямбды одного цвета на волокно одного и того же выхода. Одним из решений этой проблемы является использование преобразователя длин волн, который меняет длину волны лямбды, полученной на входе (см. рРисунок 1122 (с)).
Существуют различные альтернативы производству OADM и OXC. Они включают в себя мультиплексорные и демультиплексорные компоненты, сделанные из тонких пленочных светофильтров, волоконной сетки с оптическими циркуляторами, устройств со свободной пространственной решеткой и интегрированных плоских матричных волноводов. Известны различные технологии переключения, от ручной волоконной панели до разнообразных переключающих технологиий, таких как MEMS (Micro Electro-Mechanical Systems), жидкокристаллических и термооптических переключателей на плоских волноводныхнаправляющих схемах. Принцип использования устройств на основе MEMS (Микро электро-механических систем) показан на рис. 16, где тонкие зеркала подняты и опущены (а), или расположены под углом (b) [DOB02].
Рис. 16. Использование устройств MEMS для OADM (a), OXC (b) (см. http://www.ringrid.eu/public/deliverables/RINGRID-WP3-D3_1-JKU-State_of_the_Art_in_Networks_final.pdf>RinGrid)
Рис. 17. Система передачи WDM (см. http://www.ringrid.eu/public/deliverables/RINGRID-WP3-D3_1-JKU-State_of_the_Art_in_Networks_final.pdf>RinGrid)
Величина трафика данных относительно голосового трафика в оптических сетях и общего объема трафика, продолжает увеличиваться. Эти факторы стимулируют создание легкой в управлении, инфраструктуры передачи данных SONET/SDH, с возможностью передавать голос. На границе сети, где голос и другие данные объединяются в общую инфраструктуру, появились новые приложения для объединения данных. Характерным примером является комбинация виртуального соединения (VCAT), которая предоставляет гибкий механизм группирования для SONET/SDH, системы регулирования возможностей соединения (LCAS - Link Capacity Adjustment Scheme), предоставляющей динамическую настройку полосы пропускания, и общих фреймовых процедур (Generic Framing Procedures - GFP), предоставляющих протокольный кадровый «контейнер». В транспортном ядре, требования к полосе пропускания привели к созданию Оптической Транспортной Сети (Optical Transport Network (- OTN)), описанной в общем виде в ITU-T G.872. ITU-T G.709.
G.709 улучшает характеристики транспортных сетей и упрощает переход к более высоким скоростям передачи в опорных сетях. Фрэйм G.709 OTN включает в себя дополнительные транспортные функции, с возможностью использования, администрирования и поддержки, а так же функцию предотвращения и коррекции ошибок (Forward Error Correction (FEC)). FEC позволяет сократить число ошибок при передаче по каналам с шумами, что, в свою очередь, помогает создавать более длинные оптические диапазоны.
В сущности, OTN состоит из следующих частей, которые часто рассматриваются отдельно.
Каждый из этих элементов и их функции распределены по сети и активируются, когда при достижении места назначения.
Созданы различные интегрированные пакеты программ обслуживания GRID, часто называемые toolkit. Одной из них, является программа Globus, которая составляет часть инфраструктуры GRID, она предоставляет платформу для поддержки виртуальной организации и выполнения GRID приложений. В этом разделе рассказывается об этой программе и ее компонентах. Хотя каждый пакет программ инфраструктуры GRID - Globus [4], Condor [5], Legion [6], Unicore [7] или другие частные решения – имеют свои особенности и специализацию, компоненты программы Globus полностью соответствуют данной идеологии и ее основным тезисам.
Набор программ Globus Toolkit (GT) [4] – программный продукт с открытым исходным кодом и набором библиотек, разработанный в национальной лаборатории. Он содержит набор стандартных блоков и инструментов, которые могут быть использованы разработчиками и системными интеграторами. За несколько лет вышло четыре версии программы Globus: оригинальная – в конце девяностых, GT2 – в 2000, GT3 – в 2003, и GT4 – в 2005. Версия GT2 послужила базисом для множества GRID разработчиков по всему миру. GT3 – стала первой полноценной реализацией инфраструктуры GRID, построенной на технологии Web-сервисов, с использованием промежуточного звена GGF’s OGSI. GT4 – первая версия, полностью совместимая с основными Web-сервисами так же, как GRID- сервисы основанные на WSDL [9] и WSRF [10]. Большинство систем GRID используют ОС UNIX.
В последующих версиях программы Globus, ожидается дальнейшее совмещение с пакетом спецификаций OGSA, которые были определены в GGF. На протяжении всех этапов развития GT, разработчики Globus концентрировали свое внимание на создании инструментов, имеющих общий интерфейс для взаимодействия разнородными компонентами системы. В частности, в GT определены и реализованы протоколы, API, и другие средства, предоставляющие общие решение проблем использования и совместимости, таких как, идентификация, исследование ресурсов и доступ к ним. Решение этих проблем, достигается с помощью механизмов, которые обеспечивают безопасность, исследование информации, управление ресурсами и данными, связь, диагностику ошибок и портативность.
Ресурсные протоколы GT, используются для инициирования процесса расчета, выявления и мониторинга ресурсов, а также передачи данных. Пакет программ размещения и управления ресурсами GRID (GRAM - GRID Resource Allocation and Management), предназначен для безопасного управления процессами на удаленных ресурсах. Служба мониторинга и выявления свободных ресурсов предоставляет единый механизм обнаружения и доступа к информации по статусу и конфигурации GRID ресурсов, в частности, к конфигурации вычислительного сервера, сетевому статусу и возможностям различных сервисов. GridFTP - это расширенная версия FTP приложения и протокола [14]. Расширения включают в себя протоколы безопасного соединения, частичного доступа к файлам и управления распараллеливанием для более высокой скорости передачи данных. Безопасность в GT обеспечивается протоколами инфраструктуры безопасности Grid (GSI - GRID Security Infrastructure), которая используется для однопарольной аутентификации, защиты связи и для поддержки ограниченного делегирования.
Компоненты четвертой версии GT подразделяются на пять категорий: управление реализацией, служба безопасности, управление данными, информационная служба, работа в реальном масштабе времени. Категории показаны на рисунке 25.
GT4 содержит набор стандартных служб. На данный момент они представляют собой девять Web-сервисных интерфейсов, но их число растет.
Gridge - программный прдукт PSNC с открытым исходным кодом, призванный помочь пользователям в использовании промежуточного ПО GRID и в создании эффективных GRID инфраструктур. Все программные компоненты системы Gridge были соединены в единую распределенную систему, работающую по единым интерфейс-спецификациям, лицензиям и гарантиям качества.
Компоненты программы Gridge, так же как и другие представители промежуточного ПО GRID, прошли успешное тестирование различными версиями системы Globus. Компоненты программы Gridge распространяются бесплатно с полной коммерческой поддержкой. В добавок к уже описанным услугам, в следующем разделе PSNC предлагает:
Программный продукт Gridge содержит следующие инструменты и службы:
Служба авторизации GRID (GAS) – система авторизации, которая может служить единой точкой принятия решений для всех компонентов систем. Политика безопасности для всех компонентов системы заключена в GAS. Используя условия данной политики GAS способна аннулировать решение об авторизации по просьбе пользователя. Служба GAS разработана таким образом, что легко может интегрироваться с внешними компонентами и способна поддерживать безопасность комплексных систем. Способность взаимодействовать с различными компонентами Globus и операционных систем, делают GAS привлекательным решением для GRID приложений.
Система управления данными GRID - один из основных компонентов пакета управления данными Gridge (GDMSuite) – платформа промежуточного ПО, предоставляющая унифицированный интерфейс для соединения с разнородными хранилищами данных по всей сети. GDMSuite является основой всей среды Gridge, в рамках которой все вычислительные службы выполняют все свои операции. Пакет управления данными Gridge содержит набор блоков, разработанных для создания полной и добротной среды управления данными. Он разработан так, чтобы отвечать всем глобальным требованиям среды GRID, таким как, безопасность, совместимость и эффективность.
Мобильные службы GRID. Разработка программного обеспечения для мобильных устройств, по нашему мнению, должна фокусироваться на приложениях, которые способны установить взаимодействие между мобильными устройствами (мобильными телефонами, КПК, лэптопами) и службами GRID.
Журнальная система Toth. Этот компонент был разработан для решения проблемы сбора данных о событиях, генерируемых распределенными службами среды Gridge. Некоторые сервисы при решении общих задачах отдают предпочтение системе на основе библиотеки LOG4J, поэтому Toth полностью с ней совместим.
Система мониторинга GRID. Система мониторинга Mercury разработана в рамках проекта GridLab и предоставляет собой главную инфраструктуру мониторинга GRID. Она была специально разработана для того, чтобы отвечать специфическим требованиям мониторинга GRID: проведение мониторинга данных, представленных в виде метрик через модели pull/push семантики доступа к данным, а также предоставлять возможность мониторинга управления.
Порталы GRID разработаны специально для различных сценариев использования среды сообществами конечных пользователей. Порталы Gridge разработаны с помощью следующих инструментов и приложений: GridSphere, совместимой оболочки Java и провайдера GRID, которые позволяют быстро развертывать и использовать приложения, основанные на GRID, а также легко регулировать доступ к среде нескольких независимых порталов.
Система управления ресурсами GRID. Этот компонент является системой мета-планирования с открытым исходным кодом, он позволяет разработчикам создавать и использовать системы управления ресурсами для больших, трудно управляемых вычислительных инфраструктур.
В 2008 году сформировалась схема взаимодействия между GRID и базами данных Oracle (второе поколение технологии GRID-вычислений). Смотри конецформыначалоформыOracle Grid Computing Resources или Oracle Grid Computing Achieved.
Программное обеспечение для оконечных систем GridFTP – мощнейший инструмент для пользователей GRID и его приложений. В известном смысле, GridFTP устанавливает некую точку отсчета для сетевых решений GRID, для которых сеть это немодифицируемый, неизвестный ресурс, а стандартным протоколом является протокол TCP. GridFTP – основан на наборе команд и протоколов, стандартизованных IETF [14,28,29]. Аспекты программы GridFTP, реализующие независимую установку клиентского и серверного программного обеспечения GridFTP в сеть, стандартизованы совместно с GGF [30]. Globus GridFTP является решением, соответствующим [30]. Отличительными качествами программы GridFTP являются.
Из специфических особенностей, связанных с сетью, можно выделить полосовой сервер и параллельный канал данных, которые призваны увеличить пропускную способность. С выше перечисленными возможностями, многочисленные серверные реализации, при логических или физических трудностях, способны возобновить работу с одним и тем же файлом и функционировать как единичный FTP сервер. Использованиеуя параллельных каналов, позволяет распределить данные, которые должны быть переданы, по этим каналам, а также по независимым TCP потокам. Совместное использование полосовых и параллельных каналов данных GridFTP позволяет достичь примерно 90% использования полосы в 30 Гб/с, при передачи от память-память (27 Гб/с [31]). Когда происходит передача с диска на диск, пропускная способность достигает 17.5 Гб/с при тех же возможностях канала в 30 Гб/с.
Использование параллельных каналов данных, применительно к независимым TCP сессиям, отражается в более высокой средней величине пропускания за одну TCP сессию, чем в сетях со стандартным уровнем потерь (BER). Была сделана попытка количественно оценить разницу в полосе пропускания при трех простых предположениях: отправитель всегда имеет данные для отправки, издержки расщепления и объединения потоков для множественных сессий пренебрежимо малы, и оконечные системы имеют неограниченную полосу входа/выход.
GridFTP способен работать на большом количестве временных TCP портов. Однако, будет непрактично (и не безопасно) держать все эти порты открытыми для доступа при firewall’e априори. Решить все вопросы, связанные с функциями firewall призвана исследовательская группа проблем firewall [33] при GGF.
GRID предъявляет ряд требований по безопасности, некоторые из них приведены ниже.
Множественные инфраструктуры безопасности Для распределенных операций просто необходимо управление и взаимодействие с множественными инфраструктурами безопасности. Например, для коммерческого банка данных, изоляция клиентов внутри этого банка данных – основное требование; GRID должен осуществлять не только контроль доступа, но и предоставлять изоляцию. В качестве другого примера, можно привести системы онлайновых развлечений, где для предлагаемого контента должна быть гарантирована соответствующая изоляция, такой уровень изоляции должен осуществляться системой безопасности инфраструктуры.
Системы безопасности периметра. Многие задачи требуют, чтобы приложения могли использоваться и во вне собственного firewall’а. Коллпборпция Intergrid часто требует пересечения зон действия firewall’ов разных организаций. OGSA требуется стандартизировать безопасные механизмы взаимодействия firewall’ов.
Идентификация, авторизация и аккоунтинг. При создании и внедрении приложений в систему GRID требуется аутентификация/авторизация. В случае с коммерческим банком данных, банк данных опознает клиента и авторизует его запрос, когда клиент выставил запрос на загрузку задания. Банк данных так же определяет персональные настройки пользователей (безопасность, планирование и др.).
Шифрование. ИТ инфраструктура и ее управление требует шифрования коммуникаций, по крайней мере самых основных.
Firewall’ы сетевого уровня и приложения. Это давняя проблема. Особенно сложной ее делает огромное количество правил и условий, а также различные ограничения на международных сайтах.
Сертификация. Авторитетные организации сертифицируют работу отдельных сервисов. Например, компания может придерживаться правил, которые требуют, чтобы использовались сервисы электронной коммерции, сертифицированные Yahoo.
Возможности идентификации и авторизации в GT4 основаны на стандарте для сертифицирования X.509 [24]. Сертификаты используются для идентификации постоянных объектов, таких как пользователь или сервер. Proxy-сертификаты используются для поддержки временной передачи привилегий другим объектам. InGT4, WS-Security [25] включает в себя среду авторизации, набор механизмов безопасности передачи данных, а также ряд механизмов безопасности, касающихся сообщений. В частности:
Обсуждение общих проблем сетевой безопасности смотри по адресу book.itep.ru/6/secur_6.htm и ~/6/intrusion.htm/.
| 1 | Foster, C. Kesselman, and S. Tuecke, “The Anatomy of the GRID: Enabling Scalable Virtual Organizations,” International Journal of High Performance Computing Applications, 15 (3), 200–222, 2001 |
| 2 | D. Awduche, J. Malcolm, J. Agogbua, M. O’Dell, and J. McManus, “RFC 2702, MPLS Traffic Engineering,” IETF, September 1999 |
| 3 | Hudson, “Multilink Frame Relay: Expanding the Limits of T1,” Tiara Networks, FRF News, 4th Quarter 1999 |
| 4 | D. Minoli, A Collection of Potential Network-Based Data Services, Bellcore/Telcordia Special Report, SR-NPL-000790, 1987, Piscataway, NJ |
| 5 | G. Buda, D. Choi, R. F. Graveman, and C. Kubic, “Security Standards for the Global Information GRID,” in Military Communications Conference, 2001. MILCOM 2001 |
| 6 | R. Buyya, Economic-Based Distributed Resource Management and Scheduling for GRID Computing, Ph.D Thesis, Monash University, Melbourne, Australia, April 12, 2002 |
| 7 | C. Semeria, “RSVP Signaling Extensions for MPLS Traffic Engineering,” White Paper, Juniper Networks, Inc., 2000 |
| 8 | http://searchwebservices.techtarget.com |
| 9 | S. Hege, and J. E. Refsnes, “Glossary and Tutorials,” W3Schools, Web Developers Site On The Net, http://www.w3schools.com |
| 10 | ANSI INCITS, “Fibre Channel Arbitrated Loop (FC-AL-2),” revision 7.0, INCITS Project 1133D, April 1999 |
| 11 | ANSI INCITS, “Fibre Channel Framing and Signaling (FC-FS),” Rev 1.70, INCITS Project 1331D, Draft Standard, Rev. 1.9, April, 2003 |
| 12 | ANSI INCITS, “Fibre Channel Switch Fabric -2 (FC-SW2),” revision 5.2, INCITS Project 1305-D, May 2001 |
| 13 | Frank Gens, “IDC Predictions 2004: Top 10 Trends for the IT Industry,” IDC Executive Telebriefing, IDC, Boston, Mass. December 4, 2003 |
| 14 | OGSI Technology Preview Overview, The Globus Project™, Argonne National Laboratory, USC Information Sciences Institute, 2002; http://www.globus.org/toolkit/download/license.html |
| 15 | The Global GRID Forum, 9700 South Cass Avenue, Bldg. 221/A142, Lemont, IL, 60439, USA, http://www.ggf.org |
| 16 | The Globus Alliance, “The Globus Alliance is a research and development project focused on enabling the application of GRID concepts to scientific and engineering computing,” Press Releases, c/o Carl Kesselman, USC/Information Sciences Institute, 4676 Admiralty Way, Suite 1001, Marina del Rey, CA 90292-6695, Tel: 310 822-1511 x338, Fax: 310 823-6714, carl@isi.edu, http://www.globus.org, info@globus.org |
| 17 | P. Gralla, “What Is Service-Oriented Architecture?” The Web Services Advisor, 06 May 2003, http://searchwebservices.techtarget.com |
| 18 | The Global Alliance, “The Globus Toolkit,” The Globus Alliance Press Release, c/o Carl Kesselman, USC/Information Sciences Institute, 4676 Admiralty Way, Suite 1001, Marina del Rey, CA 90292-6695, Tel: 310 822-1511 x338, Fax: 310 823-6714, carl@isi.edu, http://www.globus.org, info@globus.org |
| 19 | IBM Press Releases. IBM Corporation, 1133 Westchester Avenue, White Plains, New York 10604, www.ibm.com |
| 20 | J. Shurtleff, “IP storage: A review of iSCSI, FCIP, and iFCP,” iSCSI Storage/IP network Storage Trend and News, iSCSI Storage Publications, P.O. Box 7317, Golden, CO, 80304-0100, info@iscsistorage.com, http://www.iscsistorage.com |
| 21 | J. Joseph, “A Developer’s Overview of OGSI and OGSI-Based GRID Computing Get an In-Depth Look at the Open GRID Service Infrastructure,” IBM Archives, April 7, 2003 |
| 22 | J. Unger, and Matt Haynos, “A Visual Tour Of Open GRID Services Architecture: Examine The Component Structure of OGSA,” IBM Achives, August 2003, Updated October 2003 |
| 23 | I. Foster, C. Kesselman, and S. Tuecke, “The Anatomy of the GRID: Enabling Scalable Virtual Organizations,” International Journal of Supercomputer Applications, 15 (3), 200–222. 2001 |
| 24 | “Kansai EPC Chooses IBM for GRID Computing Development, RBC Insurance, Royal Dutch Shell and Kansai Electric Power Newest IBM GRID Customers,” IBM Press Release, 28 Apr 2003. IBM Corporation, 1133 Westchester Avenue, White Plains, New York 10604, www.ibm.com |
| 25 | L. J. Zhang, Q. Zhoum, and J.-Y. Chung, “Developing GRID Computing Applications, Part 2, Introduction to a GRID Architecture and Toolkit for Building GRID Solutions,” December 3, 2002, http://www-106.ibm.com/developerworks/views/GRID/articles.jsp |
| 26 | M. C. Brown, “GRID Computing—Moving to a Standardized Platform,” August 2003, IBM archives, IBM Corporation, 1133 Westchester Avenue, White Plains, New York 10604, www.ibm.com |
| 27 | A. Miller, M. Jefferson, and J. Rogers, “Global Information GRID Architecture,” Mitre White Papers, MITRE Corporation, 202 Burlington Road, Bedford, MA 01730-1420, (781) 271-2000, http://www.mitre.org |
| 28 | R. Pulley and P. Christensen, “A Comparison Of MPLS Traffic Engineering Initiatives,” A White Paper by NetPlane Systems, Inc., Southboro Office Park,120 Turnpike Road, Southborough, MA 01772 |
| 29 | developerWorks staff, “Start Here to learn about GRID Computing,” IBM Corporation, 1133 Westchester Avenue, White Plains, New York 10604, August 2003 |
| 30 | T. Myer, “GRID Computing: Conceptual Flyover for Developers,” IBM Corporation, 1133 Westchester Avenue, White Plains, New York 10604, May 2003 |
| 31 | L.-J. Zhang, J.-Y. Chung, and Q. Zhou, “Developing GRID Computing Applications, Part 1: Introduction of a GRID Architecture and Toolkit for Building GRID Solutions,” Updated November 20, 2002, IBM Corporation, 1133 Westchester Avenue, White Plains, New York 10604, October 1, 2002 |
| 32 | F. Berman, G. Fox, and A. J. Hey (Eds.), GRID Computing: Making the Global Infrastructure a Reality, Wiley, 2003 |
| 33 | M. Chetty and R. Buyya, “Weaving Computational GRID: How Analogous Are They With Electrical GRID?” IEEE Computing in Science and Engineering, July/August 2002 |
| 34 | I. Foster and C. Kesselman (Eds.), The GRID: Blueprint for a Future Computing Infrastructure, Morgan Kaufmann Publishers, 1999 |
| 35 | GRID Computing Info Centre (GRID Infoware), “GRID Computing, Answers to the Enterprise Architect Magazine Query,” Enterprise Architect Magazine, http://www.cs. mu.oz.au/~raj/GRIDInfoware/GRIDfaq.html |
| 36 | I. Foster, “What Is the GRID? A Three Point Checklist,” Argonne National Laboratory and University of Chicago, July 20, 2002, Argonne National Laboratory, 9700 Cass Ave, Argonne, IL, 60439, Tel: 630 252-4619, Fax: 630 252-5986, foster@mcs.anl.gov |
| 37 | I. Foster, C. Kesselman, and S. Tuecke, “The Anatomy of the GRID: Enabling Scalable Virtual Organizations,” International Journal of High Performance Computer Applications, 15(3), 200 (2001). |
| 38 | http://www.GRIDcomputing.com/. |
| 39 | R. B. Cohen and E. Feser, GRID Computing, Projected Impact in North Carolina’s Economy and Broadband Use Through 2010, Rural Internet Access Authority, September 2003 |
| 40 | I. Foster, “The GRID: A New Infrastructure for 21st Century Science,” Physics Today, 55 (2), 42–47, 2002 |
| 41 | IDC, GRID Computing with Oracle Database 11g, March 2008 |
| 42 | Cloud Computing and Grid Computing 360-Degree Compared (Всестороннее сравнение GRID и Cloud Computing) |
UP:
4.7 Прикладные сети Интернет |
