Вычислительной мощности распределенных сис тем




Дата11.02.2017
Размер0.66 Mb.
Просмотров119
Скачиваний0

Увеличение вычислительной мощности распределенных сис-
тем с помощью грид-систем из персональных компьютеров
*
R. Lovas
1
, А.П. Афанасьев
2
, В.В. Волошинов
2
,
М.А. Посыпкин
2
, О.В. Сухорослов
2
, Н.П. Храпов
2 1
MTA SZTAKI,
2
ИСА РАН
Рассматриваются технологии грид-систем из персональных компьютеров, получив- шие широкое распространение в последнее время. Эти технологии позволяют задей- ствовать свободные от полезной работы ресурсы рабочих станций, настольных ПК, ноутбуков для проведения ресурсоемких расчетов. Приводится обзор программного обеспечения, используемого для создания гридов из персональных компьютеров.
Рассматриваются средства разработки приложений для таких систем. Также в статье уделяется внимание вопросам интеграции различных типов грид-систем.
1. Введение
Современная наука и производство немыслимы без масштабных расчетов, требующих ко- лоссальной вычислительной мощности, которую можно обеспечить только в рамках распреде- ленных и параллельных систем. В настоящее время существует несколько подходов к органи- зации распределенных вычислений. Наибольшую производительность обеспечивают специали- зированные суперкомпьютеры большой мощности, которых насчитывается несколько сотен по всему миру[1]. Они могут решать широкий спектр вычислительных задач, но требуют больших расходов на создание и эксплуатацию.
Несколько меньшей производительностью обладают так называемые сервисные гриды, ко- торые соединяют кластеры, установленные в различных организациях. Это решение дешевле по отношению к суперкомпьютерам, но также требует выделенных ресурсов и значительных усилий, связанных с эксплуатацией. Инфраструктура сервисных гридов состоит из набора сер- висов, обеспечивающих доступ к брокерам ресурсов, информационным службам, хранилищам данных, вычислительным ресурсам. Пользователи сервисных гридов имеют соответствующие права доступа к предоставляемым сервисам. Контроль доступа к ресурсам осуществляется по- средством сертификатов безопасности. Хорошо известны следующие технологии создания сер- висных гридов, как Globus [2], LCG-2/gLite (EGEE) [3], ARC [4] и Unicore [5].
На нижнем уровне рассматриваемой иерархии находятся грид-системы персональных ком- пьютеров (ГПК). ГПК основаны на наблюдении, что большую часть времени персональные компьютеры либо простаивают, либо загружены лишь на некоторую небольшую долю своей мощности. ГПК обеспечивают возможность объединения свободных вычислительных мощно- стей домашних компьютеров и персональных компьютеров учреждений в единую распреде- ленную систему для решения сложных вычислительных задач. В отличие от сервисных гридов, грид-системы из персональных компьютеров легко установить и поддерживать. Как правило, требуется одна рабочая станция, на которой запускается серверная часть инфраструктуры.
Пользователи со всего мира имеют возможность подключать свои персональные компьютеры к этому ресурсу, предоставляя тем самым свободные ресурсы своих компьютеров для работы приложений, размещенных на центральном сервере. Грид-системы из персональных компьюте- ров являются наиболее дешевым решением, обеспечивающим большую вычислительную мощ- ность. ГПК обладают огромным потенциалом роста – в настоящее время в мире насчитывается более одного миллиарда персональных компьютеров и их число стремительно увеличивается.
К сожалению, далеко не все распределенные приложения могут эффективно выполняться на подобных системах из-за серьезных ограничений, накладываемых возможностями по передаче
*
Работа выполнена при поддержке Седьмой Рамочной программы Европейского Союза (FP7/2007-
2013), грант № 261561 (DEGISCO).
6
данных и высокой вероятностью отказа узлов, участвующих в вычислениях. Вместе с тем, дос- таточно широкий класс практических задач укладывается в модель управляющий-рабочие, ко- торая является основной моделью приложения в ГПК. К этому классу относятся многие пере- борные и комбинаторные задачи, моделирование методом Монте-Карло, задачи идентифика- ции и многие другие. Для таких задач использование ГПК оправдано и позволяет разгрузить суперкомпьютеры и сервисные гриды. Резюмируя можно сказать, что грид-системы персональ- ных компьютеров являются дешевой альтернативой суперкомпьютерам и сервисным гридам и для ряда задач могут их успешно заменять.
В настоящее время широко известны следующие системы ГПК: Condor[6], BOINC [7],
XtremWeb [8], OurGrid[9]. Эти системы могут быть использованы для создания распределен- ных систем масштаба лаборатории, предприятия, города или всего мира. Несмотря на различия между сервисными гридами и грид-системами персональных компьютеров между ними много общего. В частности, модель управляющий-рабочие используется при разработке приложений для систем обоих типов. Поэтому, важнейшей задачей является обеспечение интероперабель- ности между сервисными гридами и ГПК. Различают два вида интероперабельности: на про- граммном и на системном уровне. Интероперабельность на программном уровне означает на- личие универсального интерфейса для подключения вычислительного ресурса, позволяющего объединять разнородные ресурсы в единую распределенную систему. На этом принципе осно- ваны системы SAGA[10], P-GRADE[11], MathCloud[12], BNB-Grid[13]. Интероперабельность на системном уровне предполагает наличие прозрачных для приложения механизмов, обеспе- чивающих «бесшовную» интеграцию вычислительных ресурсов. Примером такого подхода яв- ляется механизм мостов[14], применяемый для интеграции сервисных гридов и ГПК.
В данной работе рассматриваются основные технологии, применяемые для организации грид-систем персональных компьютеров (раздел 2), методы и технологии разработки приложе- ний для таких систем (раздел 3), средства обеспечения интероперабельности с сервисными гридами (раздел 4). В заключении (раздел 5) приводятся примеры использования данной техно- логии для решения научных задач и рассматриваются организационные аспекты создания и развития ГПК.
2. Технологии гридов из персональных компьютеров
2.1 Condor
Система Condor [6] разрабатывается с 1988 года в рамках одноименного исследовательско- го проекта в University of Wisconsin-Madison (США). По предоставляемой пользователю функ- циональности Condor близок к традиционным системам управления пакетной обработкой, ис- пользуемых на вычислительных кластерах. В то же время, оригинальная архитектура Condor поддерживает режимы вычислений, недоступные в традиционных системах. Режим вычисле- ний высокой пропускной способности (High-Throughput Computing) позволяет надежно под- держивать высокие объемы вычислительных ресурсов в течение длительных периодов времени путем эффективного использования всех доступных в сети вычислительных ресурсов. Режим оппортунистических вычислений (opportunistic computing) позволяет использовать ресурсы в любой момент времени, когда они доступны, не требуя постоянного монопольного доступа.
Помимо управления кластерами из выделенных узлов Condor может эффективно использо- вать ресурсы простаивающих персональных компьютеров, объединяя все доступные ресурсы организации в единый «виртуальный» кластер или пул. Например, машина может быть автома- тически добавлена в пул в те моменты, когда отсутствует активность клавиатуры или мыши. В случае, если машина вновь задействована ее владельцем, Condor выводит машину из пула, осуществляя миграцию выполнявшихся на ней заданий на другие доступные узлы. В отличие от традиционных систем управления кластером, Condor не требует наличия разделяемой между узлами файловой системы. Система поддерживает передачу файлов задания между узлами и прозрачное перенаправление потоков ввода/вывода задания на машину, запустившую данное задание.
Пул под управлением Condor состоит из выделенного узла, играющего роль центрального менеджера, и произвольного количества других машин. Любая машина в пуле может играть как
7
роль узла, запускающего задания, так и роль узла, выполняющего задания. На концептуальном уровне пул представляет собой совокупность ресурсов (машин) и запросов (заданий). Цен- тральный менеджер пула играет роль посредника, сопоставляя поступившие запросы с доступ- ными ресурсами. Каждая машина в пуле периодически отправляет свое состояние центрально- му менеджеру, который использует данную информацию при выборе узлов для выполнения заданий.
Для описания заданий и ресурсов в Condor используется единый механизм ClassAd, обла- дающий высокой гибкостью и выразительностью. В описании задания могут быть указаны как обязательные требования, так и дополнительные предпочтения по выбору машин для выполне- ния задания. Аналогично, в описании ресурса (машины) могу быть указаны требования и пред- почтения относительно заданий, которые могут быть запущены на данной машине. Важно от- метить, что данные условия могут определяться индивидуально владельцем каждой машины.
Гибкость и выразительность языка ClassAd позволяет описать практически любые политики использования ресурсов. Использование единого механизма описания для заданий и ресурсов обеспечивает эффективный выбор ресурсов для выполнения заданий с учетом взаимных требо- ваний.
Несмотря на то, что основной областью применения Condor является интеграция ресурсов внутри организации, благодаря реализованному механизму «flocking» система также поддер- живает объединение ресурсов нескольких независимых пулов, принадлежащих различным ор- ганизациям.
2.2 BOINC
BOINC (Berkeley Open Infrastructure for Network Computing) [7] представляет собой плат- форму с открытым кодом для организации проектов добровольных вычислений. Разработка системы ведется в U.C. Berkeley Spaces Sciences Laboratory (США) исследовательской группой, которая также разрабатывала проект SETI@home. Работа над BOINC была начата в 2002 году с целью создания универсальной программной платформы для проектов подобного рода, которая бы упростила процесс развертывания необходимой инфраструктуры и разработки приложений.
Первый проект добровольных вычислений на основе BOINC был запущен в 2004 году. В на- стоящее насчитывается около 60 публичных проектов на основе BOINC, делая платформу стандартом де-факто в данной области. Система также часто используется для организации внутренних гридов из персональных компьютеров.
Программное обеспечение BOINC состоит из двух основных частей: серверной, которая обеспечивает функционирование проекта, и клиентской, размещаемой на машинах доброволь- цев. Каждый проект на основе BOINC создается и функционирует независимо от других проек- тов, поддерживая собственный центральный сервер и веб-сайт. Для участия в проекте добро- вольцы устанавливают на своих компьютерах универсальный клиент BOINC, распространяе- мый с сайта платформы и доступный для всех основных операционных систем.
Проект на основе BOINC идентифицируется с помощью уникального адреса (URL), яв- ляющегося одновременно главной страницей веб-сайта проекта и точкой входа для клиентов. В рамках проекта могут выполняться несколько приложений, состав которых может со временем изменяться. В рамках BOINC предусмотрена поддержка широкого класса вычислительных приложений, которые могут быть сформулированы в виде совокупности из большого количе- ства независимых заданий. Платформа обеспечивает надежное и эффективное выполнение приложений в динамичной распределенной среде, реализуя механизмы планирования заданий, передачи данных и обработки отказов. Существующие приложения на таких языках, как C, C++ и FORTRAN, могут быть использованы в рамках BOINC без или с минимальной модификацией их кода.
После установки клиента BOINC, добровольцы могут подключить клиент к одному или не- скольким проектам. При этом пользователь может указать то, каким образом в процентном от- ношении ресурсы его компьютера будут распределены между данными проектами. При под- ключении к проекту пользователь фактически дает разрешение на выполнение на своей маши- не любых исполняемых файлов, загруженных с сервера проекта. Несмотря на то, что BOINC обеспечивает определенную изоляцию выполняемого на клиентской стороне кода (sandboxing),
8
в общем случае пользователь самостоятельно должен убедиться в подлинности, защищенности и научной значимости проекта.
Для учета индивидуального вклада каждого из добровольцев в проект в BOINC реализован механизм учета кредитов, которые вычисляются пропорционально процессорному времени, использованному для выполнения заданий проекта. В BOINC также предусмотрена возмож- ность экспорта информации о кредитах пользователя на уровне отдельного проекта. Это, а так- же поддержка глобальной идентификации пользователя по его адресу электронной почты, по- зволяет агрегировать и делать доступной сводную статистику кредитов пользователя по всем проектам.
Механизм менеджеров учетных записей (account manager) позволяет централизованно управлять подключением клиентов к тем или иным проектам. В данном случае, вместо прямого подключения к проекту, клиент подключается к веб-сервису менеджера учетных записей. Во время работы клиент периодически связывается с менеджерам, получая от него список проек- тов, к которым необходимо подключиться. Данный механизм может быть использован для де- легации пользователем решений по выбору поддерживаемых проектов некоторому доверенно- му комитету.
2.3 XtremWeb и XWHEP
XtremWeb [8] представляет собой ПО с открытым кодом для создания грид-систем из пер- сональных компьютеров, разработанное в рамках исследовательского проекта по глобальным вычислениям в INRIA/IN2P3 (Франция). В настоящее время дальнейшее развитие системы под именем XWHEP (XtremWeb-HEP) ведется в LAL (Laboratoire de l’Accélérateur Linéaire), IN2P3-
CNRS (Франция). Система реализована на языке Java и доступа на условиях лицензии GPLv2.
Архитектура XWHEP состоит из трех основных типов компонентов: серверы, рабочие и клиенты. Серверы обеспечивают функционирование центральных сервисов системы, таких как планировщицах и агрегатор результатов заданий. Рабочие (workers) устанавливаются владель- цами ресурсов на своих компьютерах для предоставления данных ресурсов в рамках системы.
Клиенты устанавливаются пользователями ресурсов на своих компьютерах для взаимодействия с системой и использования агрегированных ею ресурсов. Клиент позволяет пользователям управлять системой, размещать приложения, запускать их в виде заданий и загружать получен- ные результаты. Запущенные клиентом задания регистрируются на сервере и назначаются ра- бочим. Аналогично системе Condor, в рамках XWHEP любой рабочий может одновременно играть роль клиента и наоборот.
XWHEP значительно расширяет изначальные возможности XtremWeb в плане обеспечения безопасности. Так, в системе реализованы механизмы прав доступа как на уровне пользовате- лей, так и групп пользователей. Данные механизмы однородным образом могут быть примене- ны для ограничения доступа пользователей к ресурсам, приложениям и данным.
2.4 OurGrid
Система OurGird [9], разрабатываемая в Federal University of Campina Grande (Бразилия), реализует оригинальную концепцию кооперативных грид-систем на основе модели peer-to-peer.
В рамках данной концепции простаивающие вычислительные ресурсы участников системы объединяются и разделяются между ними таким образом, что размер доступных участнику ре- сурсов пропорционален количеству ресурсов, предоставленных им сообществу. Система реали- зована на языке Java и доступна в исходных кодах на условиях лицензии GPL.
OurGird реализует масштабируемую и защищенную распределенную платформу для вы- полнения приложений класса Bag-of-Tasks (BoT), к которому относится широкий спектр при- кладных задач. Данные параллельные приложения, состоящие из множества независимых зада- ний, идеально подходят для запуска в грид-системах из персональных компьютеров.
Архитектура OurGrid основана на симметричной peer-to-peer модели, где каждый грид-сайт представлен в системе равноправным узлом (peer). Ключевой проблемой, связанной с примене- нием подобной модели, является возможность появления в системе узлов-паразитов (freeriders),
9
которые потребляют ресурсы других узлов, никогда не давая взамен своих ресурсов сообщест- ву. Для решения данной проблемы в OurGrid используется оригинальный подход «Сеть услуг»
(Network-of-Favors), мотивирующий кооперацию между узлами. Под услугой подразумевается выделение ресурса узлу, который запросил данный ресурс. Ценность (количественная мера) услуги определяется ценностью вычислений, выполненных по запросу узла. Каждый узел ло- кально хранит суммарное количество предоставленных и полученных им услуг. При выделении своих ресурсов узлы предпочитают те узлы, которым они «должны» больше всего услуг.
С 2004 года разработчики OurGrid поддерживают одноименную открытую кооперативную грид-систему, участники которой обмениваются свободными вычислительными ресурсами. К данной системе может присоединиться любой желающий, загрузив и установив на своих ре- сурсах ПО OurGrid. При этом, в отличие от традиционных грид-систем, не требуется никаких контактов и согласований.
3. Разработка приложений
Несмотря на широту класса приложений, пригодных для запуска в гридах из персональных компьютеров, данный класс предъявляет определенные требования к приложениям. Перечис- лим основные из них:
• Наличие большого количества подзадач (заданий), укладывающихся в модель «управ- ляющий-рабочие»;
• Типичный размер заданий соответствует нескольким часам вычислений на типичном персональном компьютере и не более десятков мегабайт входных и выходных данных;
• Отсутствие необходимости в общем доступе к данным и взаимодействии между рабо- чими узлами, выполняющими задания. Синхронизация между рабочими узлами возможна только через центральный сервер.
Приложения, запускаемые в гридах из персональных компьютеров, как привило, состоят из двух распределенных частей: серверной (управляющий) и клиентской (рабочий). Серверная часть приложения отвечает за формирование заданий, проверку результатов заданий и после- дующую их обработку. Клиентская часть приложения выполняется на рабочих узлах и отвечает за выполнение заданий. Данная часть приложения должна поддерживать работу в фоновом ре- жиме, без интерактивного ввода или графического интерфейса. Гетерогенность рабочих узлов обуславливает необходимость компиляции клиентской части приложения для всех используе- мых вычислительных платформ.
Технологии гридов из персональных компьютеров предоставляют функционирующее меж- ду двумя указанными частями приложения промежуточное ПО, которое прозрачным образом осуществляет распределение клиентского кода и заданий между доступными машинами, мони- торинг выполнения заданий, обработку отказов, сбор результатов заданий и передачу их сер- верной части приложения. Для разработки, развертывания и управления приложениям в каж- дой из технологий, как правило, предусмотрены универсальные интерфейсы командной строки и/или прикладного программирования.
Например, BOINC предоставляет подобного рода интерфейсы как для серверной (генера- ция заданий, валидация результатов и их обработка), так и для клиентской части (управление выполнением приложения, сохранение промежуточного состояние и учет используемых ресур- сов) приложения. Данные интерфейсы подразумевают модификацию исходного кода приложе- ния. Поскольку существует много «унаследованных» приложений, код которых недоступен или требует значительных усилий по модификации, в BOINC предусмотрен готовый конфигури- руемый адаптер (wrapper), позволяющий запускать на клиентской стороне любое приложение без модификации его исходного кода.
Технологии XtremWeb/XWHEP и OurGrid поддерживают запуск произвольных исполняе- мых файлов, что упрощает перенос приложений.
В случае с XtremWeb/XWHEP разработчик приложения в первую очередь должен зареги- стрировать приложение, загрузив исполняемый файл на центральный сервер с помощью клиен- та. Поддерживается регистрация сразу нескольких версий исполняемого файла для разных платформ. Любой пользователь может зарегистрировать приложение, при этом права доступа
10
приложения будут определятся правами доступа пользователя. Для регистрации публично дос- тупного приложения требуются права администратора. После того, как приложение зарегист- рировано, пользователь может запускать задания, указывая идентификатор приложения, аргу- менты командной строки и ссылки на входные данные. Задания могут быть объединены в группы, что упрощает реализацию приложений с большим количеством заданий.
В случае с OurGrid приложение описывается с помощью дескриптора задачи (job description file). Задача (job) состоит из нескольких заданий (tasks). Каждое задание формирует- ся из трех подзаданий: начального (init), удаленного (remote) и финального (final), которые вы- полняются последовательно. В качестве подзаданий указываются внешние команды, вызывае- мые OurGrid. Таким образом, допускается использование произвольных исполняемых файлов и скриптов. Начальное и финальное подзадания выполняются локально, на машине с которой производится запуск задачи. Начальное подзадание предназначено для подготовки окружения для выполнения задания, например — передачи входных данных задания на машину, которая выбрана для его выполнения. Финальное подзадание обычно используется для загрузки резуль- татов задания на машину пользователя. Удаленное подзадание запускается на машине в гриде и выполняет основные вычисления, связанные с заданием. Помимо описания подзаданий, в опи- сание задания также входят требования к ресурсам. OurGrid позволяет описывать подзадания, абстрагируясь от специфики конкретных машин, на которых будут запущены данные подзада- ния, например - организации файловой системы. Для этого применяются абстракции, представ- ляющие хранилище данных на удаленной машине в гриде, и набор команд для отправки и по- лучения файлов из хранилища.
Система Condor поддерживает запуск как немодифицированных исполняемых файлов, так и приложений, собранных с использованием библиотеки Condor. Во втором случае система бе- рет на себя обязанности по автоматическому сохранению контрольных точек приложения
(checkpointing) и перенаправлению системных вызовов с исполняемой на запускаемую машину.
Задание описывается с помощью текстового дескриптора (submit description file), содержащего информацию об исполняемом файле, аргументах запуска, входных и выходных файлах, требо- ваниях к ресурсам и т. п. Дескриптор заданий поддерживает возможность описания задания- кластера, состоящего из набора параметризованных подзаданий.
4. Технологии интеграции сервисных гридов и гридов из персональ-
ных компьютеров
Механизм мостов, предоженный в работе [14], позволяет осуществлять интеграцию сер- висных гридов и ГПК на системном уровне, т.е. прозрачным для пользователя образом. На данный момент этот подход реализован для связи грид-инфраструктуры EGEE/EGI с несколь- кими ГПК (Рис. 1). Суть подхода состоит в специальном программном компоненте 3G-Bridge (a
Generic Grid to Grid bridge) который, опираясь на абстрактное понятие задания, может быть ис- пользован для интеграции двух грид-систем. По выполняемым функциям интегрирующее про- граммное обеспечение можно подразделить на два типа:
• Мост EGEE
⇒ DG, обеспечивающий запуск заданий сервисного грида в инфраструкту- ре ГПК.
• Мост DG
⇒ EGEE, позволящий, наоборот, запускать задания ГПК в инфраструктуре
EGEE.
11

Рис. 1
. Основные элементы инфраструктуры, обеспечивающие взаимодействие разнород- ных грид-систем.
5.1 Мост EGEE



DG
Данное соединение функционирует как Computing Element (CE) сервисного грида, где за- дания вместо вычислительных узлов направляются в инфраструктуру грида из персональных компьютеров (BOINC, XWHEP, OurGrid). Взаимодействие различных типов грид-систем обес- печивается тремя основными программными компонентами:
1.
Функционирующий на стороне gLite модифицированный Computing Element, который отправляет принятые из инфраструктуры сервисного грида задания на удалённый мост.
Данный CE поставляется в качестве модуля YAIM, и может быть установлен и настроен вместе с другими компонентами gLite.
2.
На стороне сервера ГПК функционирует специальный адаптер, отвечающий за получение заданий, их преобразование для новой инфраструктуры, и выполнение.
3.
Репозиторий приложений (Application Repository — AP), содержащий информацию о всех приложениях, проходящих через данный мост.
5.2 Мост DG



EGEE
Поскольку принцип работы и основное программное обеспечение зависит от типа подклю- чаемой инфраструктуры ГПК, для каждой из них создана отдельная реализация моста:
1.
Мост BOINC



EGEE, который функционирует как клиент BOINC, отправляя скачанные задания в виртуальную организацию EGEE. В инфраструктуре сервисного грида задание запускается специальной программой (jobwrapper), которая которая запускает приложение BOINC, и эмулирует для него окружение клиента BOINC.
2.
Мост XWHEP



EGEE, подключающий рабочие узлы EGEE к гриду XWHEP путём запуска рабочих компонентов инфраструктуры в виде заданий EGEE.
3.
Мост OurGrid



EGEE, который непосредственно запускает задания на вычислительных узлах виртуальной организации EGEE.
12

Для организации взаимодействия с инфраструктурой EGEE в двух последних реализациях используется библиотека jLite[15].
В рамках EGEE создана виртуальная организация desktopgrid.vo.edges-grid.eu, предназна- ченная для выполнения заданий ГПК. Гриды из персональных компьютеров(включая три ос- новных варианта: BOINC, XWHEP, OurGrid), подключённые к EDGeS, и поддерживающие за- пуск EGEE приложений, позволяют добровольцам внести свой собственный вклад в проект
EGEE и инфраструктуру сервисного грида EGEE. Инфраструктура EDGeS, содержащая более
100 тыс. процессорных ядер создавалась на основе нескольких типов ГПК и европейского гри- да EGEE/EGI. Использование гибридной вычислительной инфраструктуры в научных целях даёт следующие преимущества:
1.
Операторы гридов из персональных компьютеров и сервисных гридов могут объединить свои системы посредством инфраструктуры EDGeS. Таким образом можно увеличить вычислительный ресурс, доступный для пользователей.
2.
Менеджеры виртуальных организаций (ВО) EGEE или другого сервисного грида могут подключиться к виртуальной организации EDGeS, и таким образом добавить вычислительный ресурс в инфраструктуру, и запускать в ней свои приложения.
3.
Потребители ресурсов, подключённые к EDGeS имеют в распоряжении больший вычислительный ресурс, чем на локальных гридах. Если используется приложение, портированное на несколько типов грид-систем, то соответствующие задания будут автоматически запускаться в нужных частях инфраструктуры.
4.
Любому желающему предоставить свой вычислительный ресурс для нужд науки достаточно подключиться к одной из поддерживаемых EDGeS грид-систем, и таким образом стать участником этой вычислительной инфраструктуры.
5. Заключение
В настоящее время грид-системы персональных компьютеров стали серьезной альтернати- вой традиционным высокопроизводительным вычислительным системам и получили призна- ние международного научного сообщества. Созданы инфраструктуры ГПК, в рамках которых ведутся расчеты различных научных приложений. Примерами таких инфраструктур являются локальная инфраструктура университета
Вестминстера[16], открытый проект
EDGeS@home[17], российский проект центра Грид-технологий и распределенных вычисле- ний[18].
Грид-системам персональных компьютеров посвящено несколько проектов европейской рамочной программы (FP7). Проект DEGISCO[19], направлен на поддержку и развитие между- народной кооперации в области создания и расширения ГПК, всемерную популяризацию этой технологии, поддержку разработчиков распределенных приложений. Участниками проекта
DEGISCO и родственного проекта EDGI [20] основана Международная федерация грид-систем из персональных компьютеров (IDGF)[21]. Международная федерация грид-систем из персо- нальных компьютеров является организацией, объединяющей людей из различных компаний, университетов и исследовательских институтов, заинтересованных в использовании вычисли- тельной мощности такого типа и желающих обменяться опытом друг с другом. Своим участни- кам федерация предоставляет несколько услуг: личные встречи на семинарах, доступ к доку- ментации, форум, веб-портал и консультации экспертов.
Учитывая темпы роста числа персональных компьютеров в мире и развития Интернет можно с уверенностью сказать, что грид-системы персональных компьютеров будут активно развиваться и в ближайшем будущем интерес к этой технологии будет возрастать. Технологии интеграции различных типов грид-систем будут способствовать популяризации ГПК в научной среде.
Литература
1.
Top 500 Supercomputers. URL: http://www.top500.org (дата обращения: 13.02.2011).
13

2.
I. Foster, C. Kesselman: The Globus Project: A Status Report, Proc. IPPS/SPDP ’98
Heterogeneous Computing Workshop, pp. 4-18, 1998.
3.
The gLite webpage, http://glite.web.cern.ch/glite.
4.
M.Ellert et al.: Advanced Resource Connector middleware for lightweight computational Grids,
Future Generation Computer Systems 23 219-240, 2007.
5.
A. Streit, D. Erwin, Th. Lippert, D. Mallmann, R. Menday, M. Rambadt, M. Riedel, M. Romberg,
B. Schuller, and Ph. Wieder L. Grandinetti (Edt.): UNICORE - From Project Results to Production
Grids, Grid Computing: The New Frontiers of High Performance Processing, Advances in Parallel
Computing 14, Elsevier, 2005, pages 357-376 6.
Michael Litzkow, Miron Livny, and Matt Mutka, Condor-A Hunter of Idle Workstations. In Proc.
The 8th International Conference of Distributed Computing Systems, San Jose, California, June,
1988, pp.204-111.
7.
D. P. Anderson. Boinc: A system for public-resource computing and storage. In R. Buyya, editor,
Fifth IEEE/ACM International Workshop on Grid Computing, pages 4-10, 2004.
8.
F. Cappello, S. Djilali, G. Fedak, T. Herault, F. Magniette, V. Neri and O. Lodygensky: Compu- ting on Large Scale Distributed Systems: XtremWeb Architecture, Programming Models,Security,
Tests and Convergence with Grid FGCS Future Generation Computer Science, 2004.
9.
Walfredo Cirne, Francisco Brasileiro, Nazareno Andrade, Lauro B. Costa, Alisson Andrade, Rey- naldo Novaes and Miranda Mowbray. Labs of the World, Unite!!! J. Grid Computing 4(3), 2006, pp. 225-246.
10.
Shantenu Jha, Hartmut Kaiser, André Merzky, Ole Weidner: Grid Interoperability at the Applica- tion Level Using SAGA. eScience 2007: 584-591 11.
P. Kacsuk and G. Sipos: Multi-Grid, Multi-User Workflows in the P-GRADE Portal. Journal of
Grid Computing, Vol. 3, No. 3-4, Springer Publishers, pp. 221-238, 2005 12.
Астафьев А.С., Афанасьев А.П., Лазарев И.В., Сухорослов О.В., Тарасов А.С. Научная сер- вис-ориентированная среда на основе технологий Web и распределенных вычислений. //
Научный сервис в сети Интернет: масштабируемость, параллельность, эффективность: Тру- ды Всероссийской суперкомпьютерной конференции (21-26 сентября 2009 г., г. Новорос- сийск). – М.: Изд-во МГУ, 2009. – 524 с. (с. 463-467)
13.
Посыпкин М.А. Решение задач глобальной оптимизации в среде распределенных вычисле- ний // Программные продукты и системы. № 1. 2010. С. 23-29.
14.
E. Urbach, P. Kacsuk, Z. Farkas, G. Fedak, G. Kecskeméti, O.Lodygensky, A. Cs. Marosi, Z. Ba- laton, Zoltán; G. Caillat, G. Gombás, A.Kornafeld, J. Kovács, H. He, R. Lovas: EDGeS: Bridging
EGEE to BOINC and Xtrem Web, Journal of Grid Computing, 2009, Vol 7, No. 3, pages 335 -354 15.
O.V. Sukhoroslov. jLite: A Lightweight Java API for gLite. // Distributed Computing and Grid-
Technologies in Science and Education: Proceedings of the 3rd Intern. Conf. (Dubna, June 30 -
July 4, 2008). - Dubna: JINR, 2008. - 401 p. , pp. 201-204 16.
The University of Westminster Local DesktopGrid. URL: http://wgrass.wmin.ac.uk/index.php/Desktop_Grid:Westminster_Local_DG (дата обращения:
13.02.2011).
17.
EDGeS@Home Desktop Grid. URL: http://home.edges-grid.eu/home/ (дата обращения:
13.02.2011)
18.
Проекты Центра грид-технологий и распределенных вычислений. URL: http://boinc.isa.ru/dcsdg/ (дата обращения: 13.02.2011)
19.
The DEGISCO project. URL: http://degisco.eu (дата обращения: 13.02.2011)
20.
The EDGI project. URL: http://edgi-project.eu (дата обращения: 13.02.2011)
21.
Международная федерация грид-систем персональных компьютеров. URL: http://desktopgridfederation.org (дата обращения: 13.02.2011)
14


Поделитесь с Вашими друзьями:


База данных защищена авторским правом ©nethash.ru 2017
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал