All issues

Гибридный кластер подразумевает использование вычислительных ресурсов с различными архитектурами. Как правило, в таких системах используется CPU распространенной архитектуры (например, x86_64) и GPU (например, NVIDIA CUDA). Создание и эксплуатация подобного кластера требует определенного опыта: для того чтобы задействовать все вычислительные мощности такой системы и получить существенное ускорение на задачах, требуется учесть множество факторов. К таким факторам относятся как характеристики оборудования (например, особенности сетевой инфраструктуры, хранилища, архитектуры GPU), так и характеристики программного обеспечения (например, реализация MPI, библиотеки для работы с GPU). Таким образом для эффективных научных расчетов на подобных системах требуется помнить о характеристиках ускорителя (GPU), особенностях программного обеспечения, характеристиках задачи и о многих других факторах.

В этой статье анализируются достоинства и недостатки гибридных вычислений. Будут приведены результаты запуска некоторых тестов и научных приложений, использующих GPGPU. Основное внимание уделено программных продуктах с открытым исходным кодом, которые поддерживают работу с GPGPU.

Существует несколько подходов для организации гетерогенных вычислений. В данной статье мы рассмотрим приложения, использующие CUDA и OpenCL. CUDA довольно часто используется в подобных гибридных системах, в то время как переносимость OpenCL-приложений может сыграть решающую роль при выборе средства для разработки. Мы также уделим внимание системам с несколькими GPU, которые все чаще используются в рамках подобных кластеров. Вычисления проводились на гибридном кластере ресурсного центра «Вычислительный центр СПбГУ».

A hybrid cluster implies the use of computational devices with radically different architectures. Usually, these are conventional CPU architecture (e.g. x86_64) and GPU architecture (e. g. NVIDIA CUDA). Creating and exploiting such a cluster requires some experience: in order to harness all computational power of the described system and get substantial speedup for computational tasks many factors should be taken into account. These factors consist of hardware characteristics (e.g. network infrastructure, a type of data storage, GPU architecture) as well as software stack (e.g. MPI implementation, GPGPU libraries). So, in order to run scientific applications GPU capabilities, software features, task size and other factors should be considered.

This report discusses opportunities and problems of hybrid computations. Some statistics from tests programs and applications runs will be demonstrated. The main focus of interest is open source applications (e. g. OpenFOAM) that support GPGPU (with some parts rewritten to use GPGPU directly or by replacing libraries).

There are several approaches to organize heterogeneous computations for different GPU architectures out of which CUDA library and OpenCL framework are compared. CUDA library is becoming quite typical for hybrid systems with NVIDIA cards, but OpenCL offers portability opportunities which can be a determinant factor when choosing framework for development. We also put emphasis on multi-GPU systems that are often used to build hybrid clusters. Calculations were performed on a hybrid cluster of SPbU computing center.

Хранение — это существенная и дорогая часть облачных вычислений как с точки зрения требований сети, так и организации доступа к данным, поэтому выбор архитектуры хранения может быть критическим для любого приложения. В этой работе мы сможем посмотреть на типы облачных архитектур для обработки и хранения данных, основанных на доказанной технологии хранения в сети масштаба пред- приятия. Преимущество облачных вычислений — это способность визуализировать и разделять ресурсы среди различных приложений для наилучшего использования сервера. Мы обсуждаем и оцениваем распределенную обработку данных, архитектуры баз данных для облачных вычислений и очередь баз данных в локальной сети и для условий реального времени.

Storage is the essential and expensive part of cloud computation both from the point of view of network requirements and data access organization. So the choice of storage architecture can be crucial for any application. In this article we can look at the types of cloud architectures for data processing and data storage based on the proven technology of enterprise storage. The advantage of cloud computing is the ability to virtualize and share resources among different applications for better server utilization. We are discussing and evaluating distributed data processing, database architectures for cloud computing and database query in the local network and for real time conditions.

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

Virtual machines are usually associated with an ability to create them on demand by calling web services, then these machines are used to deliver resident services to their clients; however, providing clients with an ability to run an arbitrary programme on the newly created machines is beyond their power. Such kind of usage is useful in a high performance computing environment where most of the resources are consumed by batch programmes and not by daemons or services. In this case a cluster of virtual machines is created on demand to run a distributed or parallel programme and to save its output to a network attached storage. Upon completion this cluster is destroyed and resources are released. With certain modifications this approach can be extended to interactively deliver computational resources to the user thus providing virtual desktop as a service. Experiments show that the process of creating virtual clusters on demand can be made efficient in both cases.

В данной статье рассматривается проблема централизованного планирования маршрутов передачи данных в сетях, устойчивых к задержкам и разрывам. Исходная проблема расширяется дополнительными требованиями к хранению узлов и процессу связи. Во-первых, предполагается, что связь между узлами графа устанавливается с помощью антенн. Во-вторых, предполагается, что каждый узел имеет хранилище конечной емкости. Существующие работы не рассматривают и не решают задачу с этими ограничениями. Предполагается, что заранее известны информация о сообщениях, подлежащих обработке, информация о конфигурации сети в указанные моменты времени, взятые с определенными периодами, информация о временных задержках для ориентации антенн для передачи данных и ограничения на объем хранения данных на каждом спутнике группировки. Два хорошо известных алгоритма — CGR и Earliest Delivery with All Queues — модифицированы для удовлетворения расширенных требований. Полученные алгоритмы решают задачу поиска оптимального маршрута в сети, устойчивой к разрывам, отдельно для каждого сообщения. Также рассматривается проблема валидации алгоритмов в условиях отсутствия тестовых данных. Предложены и апробированы возможные подходы к валидации, основанные на качественных предположениях, описаны результаты экспериментов. Проведен сравнительный анализ производительности двух алгоритмов решения задачи маршрутизации. Два алгоритма, названные RDTNAS-CG и RDTNAS-AQ, были разработаны на основе алгоритмов CGR и Earliest Delivery with All Queues соответственно. Оригинальные алгоритмы были значительно расширены и была разработана дополненная реализация. Валидационные эксперименты были проведены для проверки минимальных требований «качества» к правильности алгоритмов. Сравнительный анализ производительности двух алгоритмов показал, что алгоритм RDTNAS-AQ на несколько порядков быстрее, чем RDTNAS-CG.

The problem of centralized planning for data transmission routes in delay tolerant networks is considered. The original problem is extended with additional requirements to nodes storage and communication process. First, it is assumed that the connection between the nodes of the graph is established using antennas. Second, it is assumed that each node has a storage of finite capacity. The existing works do not consider these requirements. It is assumed that we have in advance information about messages to be processed, information about the network configuration at specified time points taken with a certain time periods, information on time delays for the orientation of the antennas for data transmission and restrictions on the amount of data storage on each satellite of the grouping. Two wellknown algorithms — CGR and Earliest Delivery with All Queues are improved to satisfy the extended requirements. The obtained algorithms solve the optimal message routing problem separately for each message. The problem of validation of the algorithms under conditions of lack of test data is considered as well. Possible approaches to the validation based on qualitative conjectures are proposed and tested, and experiment results are described. A performance comparison of the two implementations of the problem solving algorithms is made. Two algorithms named RDTNAS-CG and RDTNAS-AQ have been developed based on the CGR and Earliest Delivery with All Queues algorithms, respectively. The original algorithms have been significantly expanded and an augmented implementation has been developed. Validation experiments were carried to check the minimum «quality» requirements for the correctness of the algorithms. Comparative analysis of the performance of the two algorithms showed that the RDTNAS-AQ algorithm is several orders of magnitude faster than RDTNAS-CG.

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