Все выпуски

Одним из важных направлений развития облачных технологий на данный момент является разработка методов интеграции различных облачных инфраструктур. В научной сфере актуальность данного направления обусловлена в первую очередь часто возникающей проблемой нехватки собственных вычислительных ресурсов и необходимостью привлечения дополнительных мощностей. В данной статье рассматриваются существующие подходы к интеграции облачных инфраструктур между собой: федеративные объединения и так называемая модель cloud bursting. Федеративное объединение на базе облачной платформы OpenNebula строится по схеме «одна главная зона и несколько управляемых зон», где под «зоной» понимается каждая из инфраструктур федерации. В подобной интеграции все облачные инфраструктуры имеют единую базу пользователей, а управление всей федерацией осуществляется централизованно с главной зоны. Данная схема наиболее подходит для объединения территориально разнесенных облачных инфраструктур, например подразделений одной организации, но не подходит для объединения инфраструктур разных организаций ввиду присущего данному подходу централизованного управления, а в случае использования организациями разных облачных платформ — невозможна. Модель федеративного объединения, реализованная в европейской грид-инфраструктуре «EGI Federated Cloud», хотя и позволяет интегрировать между собой облачные инфраструктуры на базе разных платформ, однако для интеграции подобным способом требуются установка и настройка существенного дополнительного набора специфических для данной конкретной европейской грид-инфраструктуры сервисов, что лишает данный подход универсальности. Модель cloud bursting лишена ограничений перечисленных федеративных подходов, однако в случае OpenNebula, на базе которой построена облачная инфраструктура Лаборатории информационных технологий Объединенного института ядерных исследований (ЛИТ ОИЯИ), такая модель была реализована только для интеграции с фиксированным набором коммерческих поставщиков облачных ресурсов. С учетом этого, а также на основании полученного авторами статьи опыта как по объединению облачных инфраструктур представляемых ими организаций, так и интеграции с европейским облаком EGI Federated Cloud командой ЛИТ ОИЯИ был разработан драйвер для объединения облаков партнерских организаций по модели cloud bursting на базе платформы OpenNebula как с аналогичным, так и с облаками на базе OpenStack. В статье описывается архитектура этого драйвера, используемые в нем технологии и протоколы, а также опыт его применения для объединения облачных инфраструктур организаций из стран-участниц ОИЯИ.

Одним из наиболее широко используемых решений для хранения данных в WLCG является Disk Pool Manager (DPM), разрабатываемый и поддерживаемый группой SDC/ID в ЦЕРНе. Недавно старый код DPM был практически переписан с нуля для решения накопившихся проблем с масштабируемостью и расширением функциональности.

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

DMLite имеет модульную архитектуру, при которой основная библиотека обеспечивает только несколько базовых функций. Системы хранения данных, а также протоколы доступа к ним реализованы в виде подключаемых модулей (plug-ins). Конечно, DMLite не смогла бы полностью заменить DPM без поддержки протокола GridFTP, наиболее широко используемого для передачи данных в WLCG.

В DPM поддержка протокола GridFTP была реализована в виде модуля Data Storage Interface (DSI) для GridFTP сервера Globus. В DMLite было решено переписать модуль GridFTP с нуля, чтобы, во-первых, воспользоваться новыми возможностями DMLite, а во-вторых, добавить недостающую функциональность. Наиболее важным отличием по сравнению со старой версией является возможность перенаправления соединений.

При использовании старого интерфейса GridFTP клиенту было необходимо предварительно связаться со службой SRM на головном узле хранилища, чтобы получить Transfer URL (TURL), необходимый для обращения к файлу. С новым интерфейсом GridFTP делать этот промежуточный шаг не требуется: клиент может сразу подключиться к службе GridFTP на головном узле хранилища и выполнять чтение-запись используя логические имена файлов (LFNs). Канал передачи данных при этом будет автоматически перенаправлен на соответствующий дисковый узел.

Такая схема работы делает одну из наиболее часто используемых функций SRM ненужной, упрощает доступ к файлам и повышает производительность. Это также делает DMLite более привлекательным выбором для виртуальных организаций, не относящихся к БАК, поскольку они никогда не были особо заинтересованы в SRM.

Новый интерфейс GridFTP также открывает возможности для хранения данных на множестве альтернативных систем, поддерживаемых DMLite, таких как HDFS, S3 и существующие пулы DPM.

Представлен подход к созданию территориально-распределенной системы хранения данных для нужд среды высокопроизводительных вычислений УрО РАН. Система основывается на промежуточном программном обеспечении dCache из проекта European Middleware Initiative. Первая очередь реализации системы охватывает вычислительные центры в двух регионах присутствия УрО РАН: г. Екатеринбург и г. Пермь.

Добровольные вычисления напоминают частные desktop гриды, тогда как desktop гриды не полностью эквивалентны добровольным вычислениям. Известны несколько попыток отличить и категоризировать их, используя как неофициальные, так и формальные методы. Однако, наиболее формальные подходы моделируют специфическое промежуточное ПО (middleware) и не сосредотачиваются на общем понятии добровольного или desktop грид. Эта работа и есть попытка формализовать их характеристики и отношения. Для этой цели применяется формальное моделирование, которое пытается охватить семантику их функциональных возможностей — в противоположность сравнениям, основанным на свойствах, особенностях, и т. п. Мы применяем этот метод моделирования с целью формализовать добровольную вычислительную систему Открытой Инфраструктуры Беркли для сетевых вычислений (BOINC) [Anderson D. P., 2004].

Представлен обзор распределенной вычислительной инфраструктуры ресурсных центров коллаборации WLCG для экспериментов БАК. Особое внимание уделено описанию решаемых задач и основным сервисам нового ресурсного центра уровня Tier-1, созданного в Национальном исследовательском центре «Курчатовский институт» для обслуживания ALICE, ATLAS и LHCb экспериментов (г. Москва).

Грид-инфраструктура — компьютерная инфраструктура нового типа, обеспечивающая глобальную интеграцию информационных и вычислительных ресурсов. Грид-сегмент в Азербайджане был создан в 2008 году в Институте физики НАН при активной поддержке международных организаций ОИЯИ и CERN. Грид приобретает все большую популярность в научно-исследовательских и образовательных центрах Азербайджана. Среди основных направлений использования грид на данный момент можно выделить научные исследования в физике высоких энергий, физике твердого тела, энергетике, астрофизике, биологии, науках о Земле, а также в медицине.

Представлена методика обеспечения интероперабельности для Грид-систем и систем облачных вычислений. Методика построена она основе единого подхода к обеспечению интероперабельности для систем широкого класса, предложенного авторами и зафиксированного в национальном стандарте РФ.

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

Статья посвящена организации системы управления кластером при помощи puppet. Рассматриваются вопросы: безопасности использования, с точки зрения массового применения к вычислительному кластеру неверной конфигурации (в виду человеческого фактора); организации совместной работы и создания для каждого администратора возможности, независимо от других, написания и отладки собственных сценариев, до включения их в общую систему управления; написания сценариев, которые позволят получить как целиком настроенный узел, так и обновлять конфигурацию по частям, не затрагивая остальные компоненты, независимо от текущего состояния узла вычислительного кластера.

Сравниваются различные подходы к созданию иерархии puppet сценариев: описываются проблемы, связанные с использованием «include» для организации иерархии и переход к системе последова- тельного вызова классов через shell-скрипт.