CC BY
57
ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ
УДК 004.75
ЭВОЛЮЦИЯ СИСТЕМЫ МЕТАКОМПЬЮТИНГА X-Com*
© 2009 г. Вл.В. Воеводин, Ю.А. Жолудев, С.И. Соболев, К.С. Стефанов
Научно-исследовательский вычислительный центр МГУ им. М.В. Ломоносова
Поступила в редакцию 11.03.2009
Рассмотрено текущее состояние системы метакомпьютинга Х-Сот, разработанной в НИВЦ МГУ. С учетом опыта практического использования системы была существенно переработана ее архитектура и изменена технологическая основа. В новой версии сделан особый акцент на масштабируемости, поддержке распределенных сред с суперкомпьютерным уровнем производительности. Реализованы механизмы буферизующих серверов, средства синхронизации файлов и сетевой безопасности.
Ключевые слова: распределенные вычисления, метакомпьютинг, Х-Сот.
Введение
Система метакомпьютинга X-Com [1], разработанная в НИВЦ МГУ, представляет собой инструментарий низкого уровня, предназначенный для организации распределенных вычислительных сред, а также для адаптации и поддержки выполнения прикладных задач в таких средах. Основными требованиями к системе, исходя из которых велась ее разработка, были легкость установки и развертывания программного обеспечения, поддержка различных программно-аппаратных платформ, простота адаптации прикладных программ для работы в распределенных средах, отсутствие необходимости административного доступа к подключаемым вычислительным ресурсам. Полнофункциональная версия системы X-Com первого поколения появилась в 2002 г. С учетом приведенных требований, аналогичных по функциональности программных продуктов на тот момент фактически не было. Так, инструментарий Globus Toolkit [2] уже в те времена отличался сложностью в настройке, установке и использовании. Система Condor [3] исходила из иных принципов, обеспечивая распределение потоков
* Статья рекомендована к печати программным комитетом Международной научной конференции «Параллельные вычислительные технологии 2009» (http:// agora.guru.ru/pavt).
относительно небольших задач на доступные ресурсы. Система ВОШС [4], лежащая в основе многих известных Интернет-проектов по распределенным вычислениям, еще находилась в стадии разработки.
Развитие и использование системы Х-Сот насчитывает уже более 7 лет. За это время система многократно использовалась для решения вычислительно сложных и практически важных задач молекулярного моделирования [5], электромагнитной динамики [6], биоинженерии и других областей. В составе системы Х-Сот появились модули генерации статистики по проведенным экспериментам и визуализации хода расчетов, подсистема управления заданиями, наборы сценариев для установки и запуска клиентской части Х-Сот в различных режимах (стоит отметить, что при этом ядро системы практически не менялось). В ходе практической работы с системой, а также в результате общения с другими пользователями Х-Сот был получен огромный опыт, который позволил тщательно проанализировать систему в целом - ее программную архитектуру, используемые алгоритмы, методы взаимодействия между компонентами и т.д. Анализ выявленных слабых мест позволил сформулировать ряд требований к дальнейшему развитию системы Х-Сот, которые легли в основу архитектуры системы нового поколения.
1. Архитектура системы Х-Сош нового поколения
Безусловно, в новой архитектуре системы требовалось сохранить все ее сильные стороны, а именно оперативность развертывания распределенных вычислительных сред, поддержку различных программно-аппаратных платформ, различные режимы подключения вычислительных узлов, простоту адаптации прикладных задач. Для облегчения перехода пользователей со старой версии системы Х-Сот хотелось в целом сохранить логику работы и интерфейсы взаимодействия системы и прикладной задачи.
В новой архитектуре системы Х-Сот был сделан особый акцент на возможностях масштабируемости и поддержки распределенных сред с суперкомпьютерным уровнем производительности. Такой акцент не случаен - за последние несколько лет в России значительно выросло число суперкомпьютеров. Инфраструктура суперкомпьютеров, и в особенности кластерных вычислительных систем, представляет собой практически идеальный вариант для развертывания распределенных сред. Однородная структура узлов суперкомпьютера и возможность управления ими с выделенной (головной) машины позволяют оперативно подключать к распределенным расчетам сегменты терафлопного уровня производительности.
Для повышения уровня масштабируемости Х-Сот архитектура серверной части системы является распределенной, с возможностью разнесения процессов на физически отдельные машины. Кроме того, был реализован полнофункциональный механизм буферизующих серверов, позволяющих как снизить нагрузку на центральный сервер системы, так и оптимизировать сетевые обмены.
В архитектуру заложены возможности по управлению узлами со стороны серверной части. Каждый узел периодически может отсылать информацию о своем состоянии, получая в ответ команду на продолжение текущего расчета либо на совершение какого-либо действия, например на смену задачи. Благодаря такой возможности динамического перераспределения узлов становится возможным реализовать один из вариантов многозадачности в распределенной среде. При появлении очередной задачи среда выделяет часть узлов для ее решения, обеспечивая таким образом одновременное выполнение нескольких задач. Другой режим многозадачности заключается в учете требований прикладной задачи, накладываемых на вычислительные узлы, на которых она может выполняться.
Новая архитектура X-Com предусматривает уровень безопасности с опциональным шифрованием данных, передающихся по открытым сетям, а также сертификацию доверенных клиентов и серверов. Дополнительные возможности включают в себя механизмы передачи файлов между серверной частью X-Com и вычислительными узлами, расширение функциональности клиентской части и другие.
На рис. 1 приведена архитектура системы X-Com нового поколения. Прямоугольники на рисунке соответствуют процессам системы. Общение между процессами осуществляется по сетям TCP/IP. В архитектуре выделяются три уровня - пользовательский уровень, серверный уровень и уровень вычислительных узлов.
На пользовательском уровне находятся процессы пользовательских клиентов и веб-браузеров. Пользовательский клиент - компонент системы, обеспечивающий интерфейс между пользователями и системой метакомпьютинга. С его помощью пользователь может поставить задачу в очередь на выполнение и отслеживать ее состояние. При постановке задания в очередь пользователь формирует файл описания задания, в котором указываются входные данные прикладной задачи и требования к ее запуску, в том числе требования к ресурсам, на которых задача будет выполняться.
Веб-браузер - обычный Интернет-браузер, с помощью которого пользователь может следить за ходом расчетов и состоянием распределенной среды в наглядной форме. При наличии веб-интерфейса к прикладной задаче с помощью браузера также может осуществляться постановка задачи в очередь.
На серверном уровне находятся процессы сервера задачи, управляющего сервера и менеджера клиентов. Сервер задачи - компонент, обеспечивающий выполнение одной конкретной прикладной задачи. Он взаимодействует с серверной частью прикладной задачи, которая генерирует порции данных и осуществляет финальную обработку результатов, приходящих от клиентов с вычислительных узлов. Сервер задачи реализует логику выдачи порций клиентам. С клиентами на вычислительных узлах сервер задачи взаимодействует не напрямую, а через процессы-сервисы, обозначенные на рисунке как File service, REQ, ASW и STAT. Файловый сервис - это фактически файловый сервер, у которого клиент запрашивает файлы прикладной задачи и вспомогательные файлы, если они необходимы. Через сервис REQ (request) клиент запрашивает очередную порцию данных у сервера задачи. Результаты выполнения приклад-
ной задачи над данными очередной порции клиент пересылает сервису ASW (answer). Сервис STAT (statistics) обеспечивает обмен контрольной информацией между клиентами и серверной частью. Выделение сервисов REQ, ASW и других отдельными процессами обусловлено требованием распределения нагрузки между компонентами системы. Это будет особенно важно при интенсивных обменах данными между клиентами и серверной частью при включенном шифровании (см. далее). В этом случае сервисы берут на себя всю предварительную обработку входящих и исходящих порций. В качестве файлового сервера может применяться любой http-сервер.
Управляющий сервер - компонент, обеспечивающий управление прохождением заданий в распределенной среде, в частности реализующий логику очередей заданий или же логику одновременного выполнения задач. На каждое запускаемое задание управляющий сервер порождает свой сервер задачи. Управляющий сервер транслирует команды - например, на срочное прекращение расчета - серверу задачи, которые затем передаются клиентам, работающим с данным сервером.
Менеджер клиентов - компонент, к которому все клиенты обращаются при первом запус-
ке. Менеджер клиентов перенаправляет вычислительные узлы к тем серверам задач, требованиям которых они соответствуют. По завершении работы с заданием клиенты вновь обращаются к менеджеру.
На уровне вычислительных узлов функционирует клиент Х-Сот, который получает от сервера задач очередную порцию данных, запускает клиентскую (вычислительную) часть прикладной задачи и передает результаты вычислений обратно на сервер. Очередную задачу клиент получает через менеджер. В ответах на запросы клиентов, формируемые сервером, может быть предусмотрена смена адресов сервисов, с которыми клиент работал прежде. Таким образом, можно, например, динамически перенаправить клиента для работы с другой задачей.
В качестве единой технологической основы для реализации всех компонентов системы была выбрана технология программирования Рег1. Рег1 доступен практически для всех программно-аппаратных платформ, он пригоден для написания переносимого кода. Рег1 фактически по умолчанию входит в дистрибутивы Linux, имеются хорошие реализации для платформы MS Windows. Рег1 также добавляет удобный интерфейс для программирования серверной части прикладных задач.
Рис. 1. Архитектура системы X-Com нового поколения
2. Особенности реализации и функционирования модулей системы X-Com
2.1. Промежуточные серверы. В базовом варианте организации распределенной среды на основе технологии Х-Сот в ней выделяется единственный сервер Х-Сот, с которым общаются все подключенные клиенты. Основное достоинство данного способа - единообразие настройки всех клиентов. Он может применяться в достаточно однородной среде с относительно небольшим числом входящих в нее узлов, каждый из которых имеет непосредственный доступ к серверу. Однако зачастую возникает ситуация, при которой часть узлов находится внутри закрытой локальной сети и не имеет прямого доступа к центральному серверу. Такая ситуация типична для кластерных вычислительных комплексов, узлы которых имеют «приватные» 1Р-адреса, и работа с ними может осуществляться только через головную машину кластера. С другой стороны, большое количество подключенных к центральному серверу узлов может создать значительную нагрузку на сервер, что может привести к снижению эффективности использования вычислительной среды.
Для решения этих проблем в иерархическую структуру сервер - клиенты вводится еще один класс компонентов - промежуточных серверов, располагающихся между основным сервером и вычислительными узлами. Использование их
позволяет организовать топологию распределенной среды в виде произвольного иерархического дерева. Листьями такого дерева всегда будут вычислительные узлы, в корне дерева остается центральный сервер Х-Сот, а во внутренних узлах дерева будут располагаться промежуточные серверы Х-Сот (рис. 2).
Промежуточные серверы с точки зрения центрального сервера выглядят как обычные вычислительные узлы, а с точки зрения нижележащих вычислительных узлов - как центральный сервер Х-Сот. Полная архитектура системы недоступна ни одному из компонентов системы. Для центрального сервера любой нижележащий промежуточный сервер Х-Сот представляется узлом, мощность которого в несколько раз превосходит мощность обычных узлов. Такой подход позволяет в любой момент времени подключать и отключать как обычные вычислительные узлы, так и целые кластеры узлов через промежуточный сервер. На результатах вычислений подключение и отключение узлов и промежуточных серверов не отразится, это повлияет только на производительность системы в целом. Одновременно это же свойство помогает обеспечить необходимую степень масштабируемости - поскольку часть клиентов находится за промежуточными серверами, центральному серверу Х-Сот не требуется поддерживать большое количество сетевых соединений, и таким образом нагрузка на него выравнивается.
Алгоритм работы промежуточного сервера X-Com следующий. Соединившись с центральным сервером, он получает от него P вычислительных порций для нижележащих узлов. Далее, в зависимости от настроек промежуточный сервер либо постоянно поддерживает окно в P порций, делая запрос к центральному серверу сразу же после получения порций конечным узлом, либо всякий раз запрашивает по P порций и дожидается их исчерпания. Результаты, приходящие от нижележащих узлов, могут отправляться центральному серверу сразу же, а могут группироваться по Q порций. При выставлении настроек P = Q = 1 промежуточный сервер не применяет буферизацию, фактически транслируя запросы между центральным сервером и узлами. Такой вариант имеет смысл использовать, например, в случае если узлы находятся во внутренней закрытой сети, каналы связи стабильны, а условия решения прикладной задачи требуют минимизации задержки между отправкой входных порций данных и получением результатов их обработки.
2.2. Методы работы клиентской части X-Com. Клиент X-Com отвечает за загрузку клиентской части прикладной задачи и необходимых для работы файлов на узлы, производящие вычисления, формирование рабочего окружения, получение порций данных, запуск задачи и передачу полученных результатов серверу X-Com.
После запуска клиент находится в начальном состоянии, он создает рабочий каталог, производит определение характеристик платформы, на которой он запущен, и посылает серверу запрос на описание задачи (GetTask). В ответ сервер выдает описание задачи (команда Proc-essTask). В описании находится информация об URL файлов задачи (исполняемых файлов и файлов данных).
После получения описания задачи клиент приступает к загрузке файлов. Все файлы, указанные в описании задачи, загружаются при помощи метода GET протокола HTTP. Имеется возможность передавать файлы в виде архива tar, упакованного gzip. После получения всех необходимых файлов клиент производит инициализацию клиентской части прикладной задачи и посылает запрос порции данных для счета (GetPortion). После получения порции данных клиент запускает обработку порции. После обработки порции данных клиент отсылает результат на сервер (запрос PostResult), после чего получает новую порцию данных и так далее.
Если в результате какого-либо запроса получена не та команда сервера, которую ожидал кли-
ент, либо получена специальная команда Initialize, клиент переходит в начальное состояние.
Протокол общения между клиентом и сервером X-Com реализован поверх протокола HTTP с использованием библиотеки libwww-perl (LWP). Использование HTTP позволяет организовать соединение через HTTP-прокси в том случае, когда сервер напрямую недоступен с клиента, а промежуточные серверы по каким-то причинам не применяются.
Файлы, указанные в описании задачи, загружаются при помощи метода GET протокола HTTP. Все остальные запросы клиента серверу реализованы при помощи метода POST. Первая часть запроса и ответа представляет собой описание на языке XML. Если в запросе клиента или в ответе сервера нужно передать дополнительную информацию (порцию данных или результат расчета), то передается MIME-сообщение из нескольких частей, первая из которых -это описание на XML, а остальные - необходимые данные.
Для разбора XML используется модуль XML::Parser, который является надстройкой над библиотекой Expat. Для создания XML используется модуль XML::Writer. Для изоляции кода клиента X-Com от кода клиентской части прикладной задачи, который также пишется на Perl, используется модуль Safe из комплекта поставки Perl. Этот модуль позволяет запускать код в изолированном окружении без получения доступа к пространству имен вызывающих модулей.
2.3. Определение характеристик вычислительных узлов. Корректное определение характеристик узлов позволяет учесть специфику аппаратного и программного обеспечения для того, чтобы, во-первых, повысить эффективность работы клиентской части, во-вторых, избежать связанных с несовместимостью проблем, в-третьих, позволить более точно оценить эффективность работы задач на X-Com в целом. Зная архитектуру узла, можно оптимизировать клиентскую часть задачи с учетом этой архитектуры. С точки зрения совместимости интерес представляют характеристики, которые были распознаны и могут использоваться работающей на узле операционной системой и приложениями, в ней выполняющимися.
Клиент X-Com собирает и предоставляет серверной части X-Com следующие данные:
• тип операционной системы (Linux/Windows);
• аппаратную архитектуру процессора (x86/x86_64/IA64/MIP S/Alpha/PowerPC);
• производительность процессора (flops);
• объем оперативной памяти (bytes).
Информация об аппаратной архитектуре -это, по сути, часть информации о самой операционной системе, точнее, о том, на каких архитектурах ей предназначено работать и какие приложения могут на ней выполняться. Поэтому было решено брать архитектуру прямо из версии операционной системы, работающей на узле. В Linux архитектуру можно узнать с помощью системного вызова uname, в Windows архитектуру можно получить с помощью интерфейсов WMI (Windows Management Instrumentation).
Объем оперативной памяти, контролируемой ОС, также весьма важен для решения задач с помощью X-Com. Так, если объем памяти узла относительно невелик, то этот факт необходимо учитывать, передавая узлу на обработку порцию данных или исполняемую часть задания.
Современные процессоры предоставляют доступ к технической информации о себе через ассемблерную инструкцию CPUID, которая поддерживается практически всеми моделями различных производителей, начиная с Intel 486DX/SX/DX2 SL, AMD 486DX4, Cyrix 6x86 (M1) и UMC U5S. В зависимости от параметра (содержания регистра EAX) можно получить информацию о производителе, об архитектуре, о номере модели, номере семейства, тактовой частоте, а также о поддерживаемых расширениях инструкций, дающих доступ к определенным архитектурным дополнениям процессора (например, Streaming SIMD Extensions - SSE, позволяющим за один такт производить сразу несколько операций).
ОС Windows и Linux самостоятельно с помощью CPUID определяют характеристики процессоров. Данные, полученные Windows, сохраняются в реестре, а Linux информацию обо всех процессорах отображает в файле /proc/cpuinfo. Следует отметить, что определенные версии ОС Linux могут и «не заметить» некоторых особенностей процессора. Дело в том, что CPUID возвращает информацию о поддерживаемых инструкциях и связанных с ними архитектурных решениях в виде набора битовых флагов, каждый из которых отвечает за поддержку определенных инструкций или является зарезервированным на будущее. Разбор операционной системой массива флагов может быть неверным просто потому, что ОС является устаревшей и по-прежнему считает определенный бит зарезервированным и игнорирует представленное в нем значение. Например, ОС Linux с ядром версии 2.6.17-13mdv (Mandriva 2007), вызывая CPUID с параметром в EAX=0x1 на процессоре AMD Phenom, может проигнориро-
вать значение 6-го бита в ЕСХ, который отвечает за поддержку 8БЕ4а, и этот факт не найдет отражения в /ргос/сршп^э. Таким образом, с точки зрения ОС, инструкции 8БЕ4а (да и все другие расширения, появившиеся позднее) не существуют, а следовательно, процессор «не умеет» выполнять за такт 4 операции над вещественными числами с их помощью.
Но это всего лишь означает, что сама ОС не сможет воспользоваться расширениями инструкций процессора, когда как приложениям использовать эти расширения можно, и за счет их использования можно достигнуть ускорения, на которое и рассчитаны дополнительные инструкции процессора. В этой связи было рассмотрено несколько вариантов определения производительности процессора на основе присутствующих в нем расширений.
Первый вариант - самостоятельно обращаться к СРиГО и разбирать массив флагов. Это неудобно тем, что в реализации невозможно обойтись только сценариями Рег1; при использовании исполняемой бинарной компоненты будет нанесен ущерб кросс-платформенности клиентской части Х-Сот.
Второй вариант заключается в определении производительности только по трем значениям: производитель, идентификатор модели и тактовая частота. Эти значения корректно определяются практически всеми современными версиями Ьтих и Windows. Такой подход более гибок и потому является предпочтительным (несмотря на то, что модельный ряд процессоров постоянно пополняется и в этой связи процедуру определения производительности следует регулярно пересматривать и обновлять).
2.4. Механизмы сетевой безопасности в системе Х-Сот. При общении в Intemet между клиентской частью Х-Сот и серверной частью возможны различного рода удаленные атаки. Выделяются следующие типы зловредных действий.
Анализ и/или модификация трафика. Если злоумышленник имеет доступ к узлу, через который проходит трафик, то он имеет возможность снимать с него передаваемые данные и/или модифицировать их. При анализе трафика конфиденциальность нарушается, а модификация (модификация порций данных, клиентской части задания, описания узлов, результатов вычислений, управляющих сообщений) в результате может привести к срыву вычислительного процесса.
Подмена одной из сторон передачи данных. При подмене серверной части злоумышленник
получает контроль над клиентами X-Com, что может привести не только к срыву вычислительного процесса, но и к использованию клиентов в зловредных целях (например, для распределенных удаленных атак или для нанесения ущерба узлам, на которых работают клиенты). При подмене клиентской части злоумышленник может передавать неверные результаты вычислений или не передавать их вовсе. Особенно ощутимым такое вмешательство может оказаться, если подменяемый объект - промежуточный сервер; в таком случае все клиенты, находящиеся под ведением истинного промежуточного сервера, выбывают из вычислительного процесса. Также при такой подмене нарушается конфиденциальность: злоумышленник получает
часть порций данных, предназначенных для обработки.
Внедрение ложного клиента. Злоумышленник может принять участие в вычислениях, используя модифицированный клиент X-Com. При этом он получает доступ к порциям данных, предназначенных для обработки, и имеет возможность отсылать неверные результаты вычислений.
В целях защиты от описанных действий были реализованы механизмы идентификации клиентов и серверов, шифрования трафика и верификации результатов вычислений.
Шифрование трафика серьезно затрудняет его анализ и модификацию. Идентификация при каком-либо общении клиента с сервером позволяет установить, являются ли обе стороны доверенными. Это не дает злоумышленнику их подменить или внедрить своего клиента. Верификация результатов вычислений помогает установить подлинность полученных результатов.
В X-Com механизмы идентификации и шифрования реализованы с помощью OpenSSL -открытой реализации протоколов TLS/SSL [7], а также утилит для шифрования, создания центров сертификации (ЦС), проверки сертификатов и др.
В клиентской части X-Com используется модуль Crypt::SSLeay, обеспечивающий поддержку протокола HTTPS для LWP::UserAgent (libwww-perl). Для того чтобы начать безопасную передачу данных по http, вместо префикса http в URL указывается префикс https. Дополнительно в переменных окружения HTTPS_KEY_FILE, HTTPS_CERT_FILE, HTTPS_CA_PATH (либо в соответствующих параметрах файла настройки) указывается путь к закрытому ключу клиента, сертификату и директории с сертификатами доверенных центров сертификации соответственно.
В серверной части X-Com для поддержки TLS/SSL необходимы модули Net::SSLeay, IO::Socket::SSL и HTTPS::Daemon::SSL. При подключении клиента к серверу производится SSL handshake, который параметризуется указанием сертификата и ключа сервера, а также директории с сертификатами доверенных ЦС. Обе стороны полностью проверяют сертификаты друг друга (прозрачная реализация такой проверки полностью включена в модули Crypt::SSLeay и Net::SSLeay), и если она прошла успешно, происходит передача данных по шифрованному каналу.
Каждый работающий клиент или сервер должен использовать собственные ключи шифрования и собственный сертификат. Поскольку одно лицо может отвечать за работу сразу множества клиентов X-Com, было предложено применять сертификаты, условно называемые сертификаты администратора клиентов, которые могут быть использованы в качестве сертификата локального ЦС, предназначенного для подписи сертификатов клиентов, находящихся в ведении администратора. В таком случае, для того чтобы сервер мог аутентифицировать клиента с сертификатом, подписанным администратором клиента, в директории TRUSTED на сервере должны лежать сертификаты администратора, сертификат доверенного ЦС, подписавшего сертификат администратора, и так далее до сертификата корневого ЦС.
Для того чтобы клиент мог аутентифицировать сервер, в директории TRUSTED должны быть сертификаты, составляющие цепочку от ЦС, подписавшего сертификат сервера, до корневого ЦС. Файлы CRL, изданные каждым ЦС из упомянутых цепочек, также должны присутствовать в TRUSTED, что пресечет успешную аутентификацию стороны, пользующейся недействительным сертификатом.
Заключение
Новая версия системы X-Com была апробирована в ходе серии масштабных вычислительных экспериментов, проведенных в ноябре 2008 г. Построенная распределенная среда для экспериментов объединила ресурсы крупнейших суперкомпьютерных центров МГУ (г. Москва), ЮУрГУ (г. Челябинск), УГАТУ (г. Уфа), СПбГТУ (г. Санкт-Петербург), ИВМиМГ СО РАН (г. Новосибирск) и ТГУ (г. Томск). В ходе экспериментов помимо решения реальных прикладных задач были отработаны и новые архитектурные решения, примененные в системе. Был выявлен и устранен ряд узких мест системы,
при этом эффективность работы системы и среды в целом была крайне высокой. Мы искренне благодарны коллегам из упомянутых университетов за помощь и исключительно доброжелательное отношение к нашим исследованиям.
Система Х-Сот распространяется свободно, дистрибутив и документация к системе доступны на официальном сайте проекта [1].
Работа выполнена при поддержке ФЦП «Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 20072012 годы», научно-технической программы Союзного государства СКИФ-ГРИД.
Список литературы
1. Система метакомпьютинга Х-Сот [Электронный ресурс]. - Режим доступа: http://x-com.parallel.ru/ (дата обращения: 12.02.2009).
2. The Globus Alliance: [Электронный ресурс]. -Режим доступа: http://www.globus.org/toolkit/ (дата обращения: 12.02.2009).
3. Condor Project Homepage [Электронный ресурс]. - Режим доступа: http://www.cs.wisc.edu/con-dor/ (дата обращения: 12.02.2009).
4. Berkeley Open Infrastructure for Network Com-
puting [Электронный ресурс]. - Режим доступа: http://boinc.berkeley.edu/ (дата обращения: 12.02.
2009).
5. Соболев С.И. Использование распределенных компьютерных ресурсов для решения вычислительно сложных задач // Системы управления и информационные технологии. 2007. № 1.3 (27). С. 391-395.
6. Медведик М.Ю., Смирнов Ю.Г., Соболев С.И. Параллельный алгоритм расчета поверхностных токов в электромагнитной задаче дифракции на экране // Вычислительные методы и программирование. 2005. Т. 6. № 1. С. 86-95.
7. OpenSSL: The OpenSource toolkit for TLS/SSL
EVOLUTION OF THE X-Com METACOMPUTING SYSTEM
VL V. Voevodin, Yu. A. Zholudev, S. I. Sobolev, K.S. Stefanov
The current state of the X-Com metacomputing system developed in RCC MSU is described. The system architecture and technological base has totally been redesigned with regard for the experience of its practical use. A new version of the X-Com system highlights such features as scalability and support of distributed environments with a supercomputer performance level. Buffering server mechanisms, means of file synchronization and network security have also been realized in the system.
Keywords: distributed computing, metacomputing, X-Com.
[Электронный ресурс]. - Режим доступа: http:// openssl.org/ (дата обращения: 12.02.2009).
