All issues

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

One of the important direction of cloud technologies development nowadays is a creation of methods for integration of various cloud infrastructures. An actuality of such direction in academic field is caused by a frequent lack of own computing resources and a necessity to attract additional ones. This article is dedicated to existing approaches to cloud infrastructures integration with each other: federations and so called ‘cloud bursting’. A ‘federation’ in terms of OpenNebula cloud platform is built on a ‘one master zone and several slave ones’ schema. A term ‘zone’ means a separate cloud infrastructure in the federation. All zones in such kind of integration have a common database of users and the whole federation is managed via master zone only. Such approach is most suitable for a case when cloud infrastructures of geographically distributed branches of a single organization need to be integrated. But due to its high centralization it's not appropriate when one needs to join cloud infrastructures of different organizations. Moreover it's not acceptable at all in case of clouds based on different software platforms. A model of federative integration implemented in EGI Federated Cloud allows to connect clouds based on different software platforms but it requires a deployment of sufficient amount of additional services which are specific for EGI Federated Cloud only. It makes such approach is one-purpose and uncommon one. A ‘cloud bursting’ model has no limitations listed above but in case of OpenNebula platform what the Laboratory of Information Technologies of Joint Institute for Nuclear Research (LIT JINR) cloud infrastructure is based on such model was implemented for an integration with a certain set of commercial cloud resources providers. Taking into account an article authors’ experience in joining clouds of organizations they represent as well as with EGI Federation Cloud a ‘cloud bursting’ driver was developed by LIT JINR cloud team for OpenNebula-based clouds integration with each other as well as with OpenStack-based ones. The driver's architecture, technologies and protocols it relies on and an experience of its usage are described in the article.

Одним из наиболее широко используемых решений для хранения данных в 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.

One of the most widely used storage solutions in WLCG is a Disk Pool Manager (DPM) developed and supported by SDC/ID group at CERN. Recently DPM went through a massive overhaul to address scalability and extensibility issues of the old code.

New system was called DMLite. Unlike the old DPM that was based on daemons, DMLite is arranged as a library that can be loaded directly by an application. This approach greatly improves performance and transaction rate by avoiding unnecessary inter-process communication via network as well as threading bottlenecks.

DMLite has a modular architecture with its core library providing only the very basic functionality. Backends (storage engines) and frontends (data access protocols) are implemented as plug-in modules. Doubtlessly DMLite wouldn't be able to completely replace DPM without GridFTP as it is used for most of the data transfers in WLCG.

In DPM GridFTP support was implemented in a Data Storage Interface (DSI) module for Globus’ GridFTP server. In DMLite an effort was made to rewrite a GridFTP module from scratch in order to take advantage of new DMLite features and also implement new functionality. The most important improvement over the old version is a redirection capability.

With old GridFTP frontend a client needed to contact SRM on the head node in order to obtain a transfer URL (TURL) before reading or writing a file. With new GridFTP frontend this is no longer necessary: a client may connect directly to the GridFTP server on the head node and perform file I/O using only logical file names (LFNs). Data channel is then automatically redirected to a proper disk node.

This renders the most often used part of SRM unnecessary, simplifies file access and improves performance. It also makes DMLite a more appealing choice for non-LHC VOs that were never much interested in SRM.

With new GridFTP frontend it's also possible to access data on various DMLite-supported backends like HDFS, S3 and legacy DPM.

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

The approach to build territorial distributed storage system for high performance computing environment of UB RAS is presented. The storage system is based on the dCache middleware from the European Middleware Initiative project. The first milestone of distributed storage system implementation includes the data centers at the two UB RAS Regions: Yekaterinburg and Perm.

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

Volunteer computing resembles private desktop grids whereas desktop grids are not fully equivalent to volunteer computing. There are several attempts to distinguish and categorize them using informal and formal methods. However, most formal approaches model a particular middleware and do not focus on the general notion of volunteer or desktop grid computing. This work makes an attempt to formalize their characteristics and relationship. To this end formal modeling is applied that tries to grasp the semantic of their functionalities — as opposed to comparisons based on properties, features, etc. We apply this modeling method to formalize the Berkeley Open Infrastructure for Network Computing (BOINC) [Anderson D. P., 2004] volunteer computing system.

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

The review of the distributed computing infrastructure of the Tier-1 sites for the Alice, ATLAS, LHCb experiments at the LHC is given. The special emphasis is placed on the main tasks and services of the Tier-1 site, which operates in the Kurchatov Institute in Moscow.

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

Grid is a new type of computing infrastructure, is intensively developed in today world of information technologies. Grid provides global integration of information and computing resources. The essence Conception of GRID in Azerbaijan is to create a set of standardized services to provide a reliable, compatible, inexpensive and secure access to geographically distributed high-tech information and computing resources a separate computer, cluster and supercomputing centers, information storage, networks, scientific tools etc.

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

The technique of ensuring of interoperability for Grid-systems and systems of cloud computing is provided. The technique is constructed on a basis of the uniform approach of ensuring interoperability for systems of the wide class offered by authors and recorded in the national Russian Federation standard.

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

The paper presents a new grid and cloud services simulation system. This system is developed in LIT JINR, Dubna, and it is aimed at improving the efficiency of the grid-cloud systems development by using work quality indicators of some real system to design and predict its evolution. For these purpose, simulation program is combined with real monitoring system of the grid-cloud service through a special database. The paper provides an example of the program usage to simulate a sufficiently general cloud structure, which can be used for more common purposes.

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

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

This article is about the organization of the cluster management using puppet. It tells about: safety of usage, from the point of view of mass apply at a computing cluster wrong configuration (by reason of human factor); collaboration work and the creation of opportunities for each cluster administrator, regardless of others, writing and debugging your own scripts, before include them in the overall system of cluster managment; writing scripts, which allow to get as fully configured nodes, and updates the configuration of any system parts, without affecting the rest of the nodes components, regardless of the current state of the node of computing cluster.

The article compares different methods of the creation of the hierarchy of puppet scenarios, describes problems associated with the use of “include” for the organization hierarchy, and tells about the transition to a system of sequential call classes through shell-script.