автореферат диссертации по информатике, вычислительной технике и управлению, 05.13.11, диссертация на тему:Модели, методы и программное обеспечение обработки интенсивного потока экспериментальных данных на суперкомпьютере

Федеральное государственное бюджетное учреждение науки Институт проблем управления им. В. А. Трапезникова Российской академии наук

На правах рукописи

Щапов Владислав Алексеевич

Модели, методы и программное обеспечение обработки интенсивного потока экспериментальных данных на суперкомпьютере

05.13.11 - Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей

АВТОРЕФЕРАТ диссертации на соискание ученой степени кандидата технических наук

Москва - 2015

005558442

005558442

Работа выполнена в Федеральном государственном бюджетном учреждении науки Институт механики сплошных сред Уральского отделения Российской академии наук и в Федеральном государственном бюджетном образовательном учреждении высшего профессионального образования «Пермский национальный исследовательский политехнический университет».

Научный руководитель:

Официальные оппоненты:

кандидат технических наук, старший научный сотрудник, Масич Григорий Федорович доктор физико-математических наук, начальник отделения информационных технологий и математического моделирования Курчатовского центра НБИКС технологий НИЦ «Курчатовский институт», Ильин Вячеслав Анатольевич

доктор технических наук, профессор, заместитель директора по научной работе ФГУП «НИИ «Квант», Корнеев Виктор Владимирович

Ведущая организация:

ФГАОУ ВПО «УрФУ имени первого Президента России Б.Н.Ельцина»

Защита состоится 12 марта 2015 в 11 часов 00 мин. в МКЗ ИПУ РАН на заседании диссертационного совета Д002.226.03 при Федеральном государственном бюджетном учреждении науки Институт проблем управления им. В. А. Трапезникова Российской академии наук, расположенном по адресу: Россия, 117997, Москва ул. Профсоюзная, д. 65.

С диссертацией можно ознакомиться в библиотеке ИПУ РАН и на сайте http://www.ipu.ru/. |

Автореферат разослан « ^ » _2015 г.

Ученый секретарь диссертационного совета,

кандидат технических наук, ц

старший научный сотрудник / А. А. Кулинич

Общая характеристика работы

Актуальность работы. В последнее время известные проекты в области e-Science затрагивают обработку все больших наборов данных, получаемых от удаленных экспериментальных установок (например, CERN LHC в физике высоких энергий и голландский проект LOFAR в астрономии). Изначально в грид-вычислениях использовались разделяемые между всеми пользователями Интернет TCP/IP сети (public Internet). Текущий этап развития технологий распределенных вычислений ориентирован на использование национальных и региональных научно-образовательных оптических сетей (например, Geant2 в Европе, Internet2 в США, Initiative GIGA UrB RAS в России). Предмет исследований и разработок текущего времени сфокусирован на решении двух связанных задач: (1) эффективном использовании скоростных (10-100 Гбит/с) протяженных (сотни километров) линий связи и (2) способах организации скоростного ввода/вывода в суперкомпьютер. Так, например, известные проекты Суперкомпьютерного центра в Питтсбурге (Advanced Networking, Three Rivers Optical Exchange, WeblOG) направлены на повышение скорости доступа к хранилищам данных и тюнинг TCP протокола (Advanced Networking // URL: http: //ww.psc.edu/index.php/research-programs/advanced-networking).

В диссертационной работе развита принципиально новая идея ввода измеряемых величин в вычислительные узлы удаленного суперкомпьютера по скоростной оптической сети (P.A. Степанов и др. Инициативный проект «Распределенный PIV» // Научный сервис в сети Интернет: масштабируемость, параллельность, эффективность: Труды Всероссийской суперкомпьютерной конференции. - М.: Изд-во МГУ, 2009). Эта идея основана на возможности независимой обработки измерений, генерируемых в установках, использующих бесконтактные оптические методы измерений (PIV, PTV, PLIF). В настоящей работе исследования выполнялись с использованием научно-образовательной DWDM магистрали (3x10 Гбит/с), которая соединяет установки ИМСС УрО РАН (Пермь) с суперкомпьютерным центром ИММ УрО РАН (Екатеринбург). Таким образом, перенос вычислений на многопроцессорные системы позволит использовать ресурсоемкие, но высокоточные алгоритмы, избежать хранения гигантских объемов избыточной информации, обрабатывать измерения в темпе их генерации и проводить эксперименты с обратной связью.

Поэтому актуальной и практически значимой становится задача надежной доставки больших объемов измеряемых данных по протяженной скоростной сети в удаленный супервычислитель для их обработки приложениями в реальном времени.

Диссертационное исследование проведено при поддержке грантов:

• РФФИ У-11 - 0 7- 9 G001 - р _ у ра л _ а «Исследование и разработка процесса формирования региональной киберинфраструктуры на основе LambdaGrid технологии» (2011-2013 гг).

• Программа Президиума РАН .Vo 14 «Проблемы создания информационно-вычислительной среды на основе GRID технологий, облачных вычислений и современных телекоммуникационных сетей» проект РЦП-12-П-1-2012 «Создание архитектуры распределенной среды высокопроизводительных

вычислений УрО РАН на основе GRID технологий» (2012-2014 гг).

• Региональная целевая программа «Развитие ИВТР УрО РАН» проект РЦП-11-П10 «Кросскорреляционный параллельный алгоритм обработки на супервычислителе потока экспериментальных данных, поступающего от удаленной экспериментальной установки (Проект «Распределенный PIV», этап 2)» (2011 г).

Цель диссертационной работы состоит в разработке модели, методов и программного обеспечения для передачи интенсивного потока экспериментальных данных в удаленный суперкомпьютер для их обработки в реальном времени прикладными программами путем внедрения параллелизма на уровень передачи данных между компонентами территориально-распределенной системы.

Для достижения поставленных целей были исследованы и решены следующие задачи:

1. Анализ существующих подходов распределенной обработки интенсивных и продолжительных по времени потоков данных.

2. Определение путей и способов достижения ресурсной сбалансированности в тракте «Источник данных - Скоростная сеть - Суперкомпьютер».

3. Исследование и разработка модели параллельной передачи данных.

4. Исследование и разработка алгоритма диспетчеризации параллельных потоков данных.

5. Создание программной инфраструктуры для взаимодействия пользовательских приложений в Источнике и Суперкомпьютере.

6. Создание инструментальных средств тестирования и поиска параметров тракта, обеспечивающих допустимую физическими средствами пропускную способность.

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

Объект исследования: географически распределенные системы обработки потоков данных.

Предмет исследования: способы (процесс) ввода интенсивного потока экспериментальных данных в удаленный суперкомпьютер.

Научная новизна. В диссертационной работе получены следующие новые результаты:

• Предложена новая асинхронная модель передачи потока данных от источника в удаленный суперкомпьютер, основанная на идее параллельного прямого ввода структурированного потока данных в вычислительные узлы суперкомпьютера.

• Предложен новый способ автоматической балансировки (распределения измерений) потока данных по вычислительным узлам суперкомпьютера, путем представления элементов потока в виде очереди и передачи элементов очереди по запросам вычислительных узлов.

• На основе предложенных подходов разработаны алгоритмы и связующее программное обеспечение (middleware) для передачи данных между приложениями, обеспечивающее достижимую физическими средствами пропускную способность системы.

• Предложена методика оценки требуемых ресурсов тракта «Источник данных (скорость генерации) - Скоростная сеть (полоса пропускания) - Суперкомпьютер (число вычислительных узлов)» для обработки потока данных в реальном времени.

Практическая значимость. Результаты работы апробированы при проведении ресурсоемких физических экспериментов в фундаментальных и прикладных исследованиях и могут быть использованы для диагностических PIV измерений в промышленном секторе.

Результаты работы внедрены в Институте механики сплошных сред УрО РАН, Институте математики и механики УрО РАН и в рамках учебного процесса кафедры «Информационные технологии и автоматизированные системы» Пермского национального исследовательского политехнического университета.

На защиту выносятся следующие основные результаты и положения:

• Асинхронная модель передачи потока данных от источника в вычислительные узлы суперкомпьютера.

• Алгоритм диспетчеризации элементов потока данных.

• Программная инфраструктура (форматы данных, протокол, алгоритмы) для взаимодействия пользовательских приложений.

• Инструментальные средства тестирования и поиска параметров тракта «Источник данных - Скоростная сеть - Суперкомпьютер», обеспечивающих допустимую техническими средствами скорость передачи данных.

Апробация работы. Основные результаты диссертации докладывались на следующих конференциях:

• Конференция представителей региональных научно-образовательных сетей «RELARN-2010» [4].

• X международная конференция «Высокопроизводительные параллельные вычисления на кластерных системах «НРС-2010»» [5].

• Международная конференция «Математические и информационные технологии, М1Т-2011» [6]; «М1Т-2013» [7].

• Международная суперкомпьютерная конференция «Научный сервис в сети Интернет: экзафлопсное будущее» 2011 г. [8]; «Научный сервис в сети Интернет: поиск новых решений» 2012 г. [9].

• Международная конференция «Интеллектуализация обработки информации «ИОИ-9»» 2012 г. [10].

• Международная конференция «Параллельные вычислительные технологии (ПаВТ'2013)» [11].

Публикации. Материалы диссертации опубликованы в 12 печатных работах, из них 3 статьи в рецензируемых журналах [1-3], 6 статей в сборниках трудов конференций, 2 тезиса докладов и 1 свидетельство о государственной регистрации программы для ЭВМ [12].

Личный вклад автора заключается в анализе существующих подходов распределенной обработки потоков данных, определении способов достижения сбалансированности тракта передачи данных, разработке модели параллельной передачи данных, создании алгоритмов и связующего программного обеспечения (middleware), обеспечивающего взимодействие приложений эксперименталь-

ной установки с суперкомпьютером, формулировке результатов и выводов диссертации. Автор также разработал программное обеспечение для автоматизации тестирования тракта передачи данных, провел представленные в работе экспериментальные исследования и обрабатывал полученные результаты экспериментов.

Структура и объем диссертации. Диссертация состоит из введения, 4 глав, заключения, библиографии и 4 приложений. Общий объем диссертации 128 страниц, из них 108 страниц текста, включая 80 рисунков. Библиография включает 71 наименование на 9 страницах.

Содержание работы

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

В первой главе проведен обзор технологий распределенной обработки больших объемов данных.

Обработка потока данных - это подход, при котором обработка и генерация результата происходит по мере поступления данных. В этот класс задач попадают задачи обработки экспериментальных данных, кодирование видео- и аудиопотоков и т.д. Рост объемов обрабатываемых данных и требований к точности вычислений приводит к необходимости использования все больших вычислительных мощностей (суперкомпьютеров) для сохранения приемлемого времени расчета. Например, в экспериментальных PIV исследованиях, проводящихся в ИМСС УрО РАН интенсивность потоков данных может достигать 960 Мбит/с, при обработке изображений с разрешением 4 Мп (8 бит/пиксел), и 7200 Мбит/с, при обработке изображений с разрешением 10 Мп (24 бит/пиксел), при частоте кадров 30 кадров/с, а продолжительность экспериментов измеряться сутками. Возможность скоростного соединения источника интенсивного потока данных с удаленным суперкомпьютером обусловлено тем, что пропускная способность национальных сетей со спектральным уплотнением каналов в настоящее время не является дефицитным ресурсом. Примерами таких сетей с 10-100 Гбит/с в каждой лямбде являются Internet2 в США (http://www.internet2.edu); GEANT объединяет национальные сети в Европе (http://www.geant.net); «Инициатива GIGA UrB RAS» в России (http://giga-ural.ru), реализованный фрагмент научно-образовательной DWDM магистрали (3x10 Гбит/с), которая объединяет ресурсы ИМСС УрО РАН (Пермь) с суперкомпьютерным центром ИММ УрО РАН (Екатеринбург). Общепризнанной проблемой текущего времени является эффективное использование скоростных протяженных (10-40 Гбит/с, сотни километров) линий связи и каналов ввода/вывода суперкомпьютеров (Natarajan R., Kochte, М. System and method for executing compute-intensive database user-defined programs on an attached high-performance parallel computer // US Patent 7,885,969, 2007 r.)

Решению проблемы ввода/вывода данных в суперкомпьютер и обеспечению эффективной передачи данных по протяженным скоростным линиям связи

посвящена диссертационная работа.

Почти во всех работах упоминаются прикладные протоколы CIFS и NFS для доступа к хранилищам и FTP, SCP или GridFTP для передачи файлов. Отмечается плохая производительность транспортных протоколов, используемых на нижележащих уровнях модели OSI. Общепризнано, что одним из основных источников ухудшения совокупной производительности территориально распределенных высокоскоростных приложений является плохая end-to-end производительность протокола TCP, который по умолчанию присутствует во всех системах.

В задачах обработки больших данных на суперкомпьютерах источником данных обычно является система хранения данных суперкомпьютера. В этом случае обработка происходит в три этапа (рисунок 1):

1. Загрузка данных в хранилище суперкомпьютера.

2. Обработка данных на суперкомпьютере.

3. Выгрузка результатов обработки с хранилища суперкомпьютера.

Данный метод обработки ориентирован на пакетный режим работы суперкомпьютера.

✓ "ч

Г Суперкомпьютер

Рисунок 1. Существующее (классический режим) и разрабатываемое (память-память) архитектурное решение обработки данных на суперкомпьютере

Загрузка/выгрузка данных в/из хранилища (этапы 1 и 3) и последую-

щая обработка (этап 2) будут связаны с промежуточными операциями записи/чтения данных в хранилище суперкомпьютера.

Наиболее частым способом обмена данными с хранилищами является использование протоколов передачи файлов, таких как FTP/GridFTP и SCP. Другим направлением данного подхода является прямой доступ к хранилищу данных при помощи протоколов работы с файловой системой, таких как CIFS и NFS/pNFS. Этот способ позволяет подключить хранилище суперкомпьютера к источнику данных как удаленную файловую систему и производить запись данных без использования специализированного программного обеспечения. Однако, на протяженных высокоскоростных линиях связи эти решения работают недостаточно хорошо (D. Hildebrand, М. Eshel, R. Haskin, P. Kovatch, P. Andrews, J. «White Deploying pNFS Across the WAN: First Steps in HPC Grid Computing» //in Proceedings of the 9th LCI International Conference on High-Performance Clustered Computing, 2008; Weikuan Yu; Rao, N.S.V.; Wyckoff, P.; Vetter, J.S., «Performance of RDMA-capable storage protocols on wide-area network», Petascale Data Storage Workshop, 2008. PDSW '08. 3rd , vol., no., pp.1,5, 17-17 Nov. 2008 DOI: 10.1109/PDSW.2008.4811885).

В настоящей работе рассматривается подход, при котором элементы структурированного потока данных вводятся в вычислительные узлы и обрабатываются параллельно (модель «память-память» на рисунке 1).

В этом случае на первый план выходит необходимость обеспечения эффективной передачи данных на вычислительные узлы суперкомпьютера и решение задачи распределения элементов потока по вычислительным узлам.

Прототипом предлагаемой модели обработки данных является концепция очередей данных. Она позволяет реализовать параллельность на уровне обработки и передачи данных и перенести процесс диспетчеризации данных с множества вычислительных узлов на отдельный компонент системы - менеджер очередей.

Отличительные особенности предлагаемого решения:

• отказ от промежуточного хранения данных в хранилищах;

• прямой ввод данных в вычислительные узлы;

• параллелизм Ь2-соединений (каналы связи) на уровне передачи данных;

• параллелизм Ь4-соединений между оконечными системами.

Параллелизм Ь4-соединений позволяет получить необходимую скорость передачи данных при использовании протоколов, работающих с обратной связью для гарантированной доставки данных. Это позволило использовать в качестве транспортных протоколов (L4 OSI RM) такие протоколы, как TCP и UDT.

Во второй главе рассматривается предложенная модель обработки потока данных в распределенных системах.

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

лителям, базирующийся на следующих идеях:

• прямой ввод сообщений в вычислительные узлы удаленного суперкомпьютера;

• представление потока данных от Источника в виде единой очереди сообщений, которые распределяются по вычислительным узлам по запросам от вычислительных узлов в порядке FIFO (First In, First Out).

Уровень генерации Уровст. Уровень обработки

данных распределения данных данных

Менеджер очередей

*) Одно устройство может находиться и на уровне генерации данных, и на уровне обработки данных

Рисунок 2. Модель обработки потока данных

Процесс обработки потока данных можно представить в виде трех стадий: генерация исходных данных; распределение данных по обработчикам; обработка данных прикладными алгоритмами. Каждой стадии процесса обработки потока данных соответствует одноименный уровень модели (рисунок 2): уровень генерации данных; уровень распределения данных; уровень обработки данных.

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

На уровне генерации данных происходит появление новых данных, требующих передачи на обработку. Это может быть экспериментальная установка,

которая генерирует экспериментальные данные или алгоритм расчета, результаты которого должны быть сохранены.

Уровень обработки данных занимается решением задач расчета исходных данных с применением каких-либо алгоритмов, сохранения данных в высокопроизводительных хранилищах или на большом количестве локальных дисков, передачи данных из очередей в сторонние системы и т.д.

Уровень распределения данных занимается размещением сообщений, полученных от приложений уровня генерации данных в одной или нескольких очередях менеджера очередей, и передачей данных из очередей приложениям уровня обработки в ответ на их запросы.

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

Применение описанной модели дает принципиально новые возможности проведения экспериментальных исследований и организации распределенной обработки потоков данных:

• Обрабатывать данные от источника и управлять источником данных в реальном времени (рисунок 2, б).

• Сохранять (при необходимости) данные от источника и/или результаты счета в системах хранения для последующей обработки или интерпретации результатов.

• Избежать необходимости синхронизации между вычислителями на стороне суперкомпьютера.

• Автоматически балансировать нагрузку по вычислительным узлам.

• Изменять число используемых вычислительных узлов во время обработки данных прикладными программами.

• Использовать вычислительную мощность нескольких суперкомпьютеров.

• Избежать потери данных в случае выхода из строя одного или нескольких вычислительных узлов путем сохранения сообщения в буфере менеджера очередей до подтверждения его успешной обработки.

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

1. Параллелизм передачи данных (рисунок 3) для устранения проблем транспортных протоколов с обратной связью.

2. Собственные прикладные протоколы взаимодействия оконечных систем и стратегии управления потоком в них.

3. Алгоритм диспетчеризации параллельных потоков, обеспечивающий автоматическое распределение нагрузки по вычислительным узлам.

4. Настройки параметров сетевого стека операционных систем.

Суперкомпьютер

Диспетчер

Канал связи небольшой протяженности

Рисунок 3. Параллелизм

Параллелизм передачи данных в протяженных каналах связи

передачи данных по протяженными каналам связи

С точки зрения теории массового обслуживания, когда поток заявок и поток обслуживания - простейшие, система с общей очередью будет описываться моделью вида М/М/п, где п - число обработчиков (каналов обслуживания). Система с предварительным циклическим распределением данных по обработчикам будет описываться моделью Еп/М/1, где Еп - поток Эрланга порядка п. Расчеты показывают, что система с общей очередью дает меньшее среднее время ожидания в очереди и меньшую среднюю длину очереди.

Для оценки необходимых коммуникационных и вычислительных ресурсов предложена следующая методика.

Необходимая скорость передачи данных v в полнодуплексном канале связи равна:

^ ^ Vmax ' (1 + *), (1)

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

Например, при отсутствии потерь и повторных передач данных для транспортного протокола TCP, коэффициент к будет иметь приведенные ниже значения (при суммарной длине заголовков Ethernet, IPv4 и TCP - 70 байт).

При передаче исходных данных и результатов обработки в одном ТСР-соединении с использованием Ethernet кадров обычной длины (1518 байт): к = 0,04834, а при использовании технологии Jumbo-frame (длина кадра 9000 байт): к = 0,00872.

При передаче исходных данных и результатов обработки в независимых TCP-соединениях с использованием Ethernet кадров обычной длины (1518 байт): к = 0,09668, а при использовании технологии Jumbo-frame (длина кадра 9000 байт): А: = 0,01744.

Необходимое число обработчиков для онлайн-обработки потока данных

можно оценить по следующей формуле:

п = Г(т + 2 • ВТТ) ■ Л] + пр, (2)

где т ~ среднее время обработки сообщения, ЯТТ - время ретрансмиссии в канале связи, Л - интенсивность потока исходных данных, пр - параметр компенсации неидеальности реальных транспортных протоколов. Слагаемое 2 • ВТТ в формуле (2) необходимо для учета времени передачи подтверждения обработки сообщения менеджеру очередей (рисунок 4). Если результаты расчета передаются обратно менеджеру очередей, то время этой передачи также необходимо прибавлять к т, так как разработанное решение предполагает интерактивный протокол взаимодействия.

Источник данных

Менеджер очередей

Вычислитель 1

PC

Сообщение исходных данных

ST

Отправка f результатов обработки

i i GET

GET : 1 RESP т POST L_

POST RESP

Передача данных на обработку

Запрос данных для обработки (требует 1 ЯТТ)

V

Подтверждение получения 1 результатов обработки (требует 1 RTT)

Полный цикл обработки сообщения Рисунок 4. Временная диаграмма процесса обработки сообщения

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

В третьей главе описывается созданная программная инфраструктура для распределенной обработки данных.

Реализация предложенной модели обработки потока данных в распределенных системах требует создания протокола передачи данных, который формализует метод обмена сообщениями между компонентами системы и промежуточного программного обеспечения для всех уровней системы. Анализ существующих технологий работы с очередями в распределенных системах (ZeroMQ, протокол AMQP и реализация RabbitMQ) показал, что ни одна из них не удовлетворяет предъявляемым требованиям полностью (скорость работы, простота использования, возможности использовать сторонние транспортные протоколы). В связи

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

Разработанный протокол SciMP является интерактивным протоколом прикладного уровня (рисунок 5), работающим по схеме запрос-ответ. Протокол SciMP может использовать в качестве протокола транспортного уровня любой надежный потоковый протокол передачи данных. Текущая реализация поддерживает транспортные протоколы TCP и UDT. Протокол SciMP рассчитан на передачу именованных блоков бинарных данных. В одном пакете может быть передано от 0 до 65535 блоков размером не более 4 Гбайт каждый, при этом сохранение порядка следования блоков не гарантируется. Длина имени блока ограничена 255 байтами. Формат пакета протокола SciMP приведен на рисунке 6.

User Space

Socket API UDT Socket

§ciklQ library API (С++)

Kernel Sp

version 1 cmd status I

options block count I

Key 1 lenlKey 2 len Key 3 len|Key 4 len I

V

|Key N len

Block 1 length I

I

Block N length

Key 1 | Data 1 |

Max block_count*2A32 bytes

►-Заголовок

Список

блоков

Список длин блоков

Данные

Рисунок 5. Положение протокола БаМР в Рисунок 6. Формат пакета протокола стеке сетевых протоколов 8с1МР

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

На рисунке 7 приведена временная диаграмма работы протокола ЭоМР в трехуровневой программной архитектуре. Левая часть диаграммы показывает взаимодействие уровня генерации данных, а правая часть - уровня обработки данных с менеджером очередей.

Предложенная модель обработки потока данных в распределенных системах реализована в виде комплекса программного обеспечения БйМС^. Логическая схема взаимодействия компонент комплекса программного обеспечения показана на рисунке 8.

Источник данных

Mi li i 1жер

ОЧСрСЛСЙ

Данных больше нет

"MODIFY QUEUE-

Извлечение измерения из г

очереди и отправка -

Добавление >измерения в очередь

Добавление 3 измерения в очередь

Установка флата Данных больше - очереди «данных пет больше нет»

Менеджер Вычислительны

очередей ti узел

-C.F.T—-

RESPONSO Передача измерения*

Добавление результата в очередь

-POST--

-RESPONSE— -GET--

I Обработка [ измерения

^ Обработка подтверждения

Завершение работы клиента

Рисунок 7. Временная диаграмма работы системы с использованием протокола выМР

Уровень генерации данных __Л_

Уровень распределения данных

Г

Уровень обработки

данных _Л_

Рисунок 8. Логическая схема взаимодействия компонент комплекса программного обеспечения

Основу системы составляет программное обеспечение уровня распределения данных - сервер очередей, в паре с которым работают приложения уровней генерации и обработки данных (оконечных систем). Управление сервером очередей осуществляется при помощи web-интерфейса и интерфейса командной строки.

Приложения оконечных систем взаимодействуют с сервером очередей по сети с использованием протокола SciMP. Для программистов оконечных систем есть два варианта реализации взаимодействия. Первый вариант заключается в самостоятельной реализации протокола SciMP. Этот вариант позволяет добиться максимальной гибкости, в том числе, использовать неподдерживаемые языки программирования.

Второй вариант заключается в использовании С++ API, который предоставляется клиентской библиотекой. Библиотека скрывает от программиста реализацию протокола SciMP и работы с сетью, тем самым позволяя ему сосре-

доточиться на разработке прикладной задачи, а не реализации протокола взаимодействия. Типовой пример работы с сервером очередей с использованием клиентской библиотеки показан на рисунке 9.

Начало

т

SciMQ::Client::Connection client(...)

Нет

client.gel_message(...)

"I

Есть данные для обработки?

Обработка данных

т

client. post_message(...)

Создание соединения с сервером

Запрос данных для обработки

Отправка результатов обработки на сервер

Конец

Рисунок 9. Типовой пример работы с сервером очередей с использованием клиентской библиотеки

Все компоненты комплекса программного обеспечения разработаны на языке программирования С++. Выбор языка С++ обусловлен как техническими, так и прикладными требованиями. Прикладным требованием является необходимость предоставить конечным пользователям системы API, реализованный на языке С++. С технической точки зрения язык С++ позволяет разрабатывать приложения с использованием высокоуровневого объектно-ориентированного подхода и одновременно обеспечивать низкоуровневый контроль за используемыми ресурсами, в первую очередь ресурсами оперативной памяти, благодаря поддержке ручного управления памятью. Контроль за потреблением и освобождением ресурсов особенно важен в случае, когда объемы передаваемых данных существенно больше, чем доступная оперативная память и скорости передачи данных приближаются к пределу возможностей сетевых подсистем, так как позволяют исключить ненужные копирования данных или обнуление блоков памяти перед использованием.

Для уменьшения сложности разработки программного обеспечения требовалось выбрать библиотеки, предоставляющее кроссплатформенный API для работы с сетевыми сокетами и вводом/выводом. Были рассмотрены реализации Boost.Asio (Boost С++ Libraries. URL: http://www.boost.org/), POCO С++ Libraries (URL: http://pocoproject.org/) и libevent (URL: http://libevent. org/).

В результате анализа были выбраны библиотеки Boost, как обладающие наиболее широкими возможностями, в частности библиотека Boost.Asió, которая предоставляет кроссплатформенные интерфейсы для работы с сетевыми сокетами и вводом/выводом с использованием низкоуровневых возможностей, оптимальных для данной платформы. Например, в операционной системе Windows используются механизмы overlapped I/O и I/O completion ports для выполнения асинхронных операций с сокетами, а на платформе Linux механизм epoll (Platform-Specific Implementation Notes. URL: http://www.boost.org/doc/ libs/l_57_0/doc/html/boost_asio/overview/implementation.html).

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

Сервер очередей является ядром всего комплекса программного обеспечения и реализует основные функциональные возможности системы. Его задачей является управление сообщениями в очередях, включая их промежуточное хранение, распределение по запросам и прием/передачу от внешних систем. Сервер очередей состоит из четырех модулей: управляющего модуля, модуля очередей, фоновых процессов и сетевого взаимодействия. Все модули, за исключением модуля очередей, работают по событийно-ориентированному принципу с использованием технологий Boost.Asió.

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

Модуль очередей управляет хранением очередей в памяти сервера. Каждая очередь имеет свое уникальное имя и может быть с гарантией обработки или без гарантии обработки. Если очередь без гарантии обработки, то элемент удаляется из очереди сразу же после отправки клиенту. Если очередь с гаран-

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

Модуль фоновых процессов предназначен для выполнения низкоприоритетных отложенных задач, таких, как отслеживание таймаутов в очередях с гарантией обработки данных и отслеживание необходимости выгрузки данных из оперативной памяти на диски при достижении лимитов потребления памяти.

Модуль сетевого взаимодействия отвечает за реализацию взаимодействия с клиентами по сети, то есть непосредственно реализует функциональность протокола SciMP. Он представляет собой пул потоков, в каждом из которых работает локальный для потока объект-диспетчер событий boost:: asió:: i о _ ser v i ее. Для возможности обработки нескольких клиентских соединений одним потоком операционной системы применяются неблокирующие сокеты, асинхронные операции и зависимые от операционной системы технологии мультиплексирования, которые реализуются внутри библиотеки Boost.Asió. Каждому соединению с клиентом в момент его создания назначается один из диспетчеров событий io service, который будет обслуживать все асинхронные операции в этом соединении. Выбор такой архитектуры вызван тем, что операционная система Linux не поддерживает параллельное ожидание событий на одном наборе сокетов из нескольких потоков операционной системы, поэтому для распараллеливания ожидания событий на несколько ядер процессора клиентские сокеты принудительно распределяются по разным потокам, что позволяет снизить накладные расходы на синхронизации.

Клиентская библиотека предназначена для упрощения написания прикладных приложений, так как снимает с программиста необходимость написания собственной реализации протокола SciMP. Она предоставляет прикладному программисту синхронный API для взаимодействия с сервером очередей и скрывает все нюансы реализации протокола SciMP и работы с сетью.

Управляющее программное обеспечение предназначено для выполнения задач администрирования и тестирования комплекса программного обеспечения.

В четвертой главе приводятся результаты исследования производительности распределенной системы обработки данных и экспериментальной проверки методики оценки требуемых вычислительных ресурсов.

Экспериментальные исследования производились с использованием инфраструктуры проектов GIGA UrB RAS и «Распределенный PIV». На рисунке 10 показан фрагмент инфраструктуры, задействованный в исследовании.

Экспериментальная установка (Пермь, ИМСС УрО РАН) соединяется с суперкомпьютерами «Уран», «UM64» и системой хранения данных (СХД) ЕМС Celerra NS-480 (Екатеринбург, ИММ УрО РАН) по Ethernet технологии на скорости 1 Гбит/с. В оконечных системах используется стек протоколов TCP/IP.

Менеджер очередей установлен на сервере SunFire Х2100М2 (AMD Opteron 1214, 2,2 ГГц, 2 потока; RAM 2 Гб; 4 Ethernet интерфейса 1 Гбит/с; операционная система CentOS G.4). Сервер подключен к пограничному коммутатору сети в

установка

VLAN 10 Гбит/с

Рисунок 10. Схема компонент и коммуникаций системы

Хранилище

«EMC Celerra NS-480»

Пермь (НМСС УрО РАН)

/ Екатеринбург ШММ УрО РАН) \

ИМСС УрО РАН при помощи двух каналов пропускной способностью 1 Гбит/с каждый, агрегированных в один виртуальный канал при помощи технологии Link Aggregation Control Protocol (LACP).

Исследование эффективности алгоритмов управления перегрузкой TCP было проведено при помощи специально разработанного программного обеспечения, написанного на языке Bash, и приложения Iperf. Тестирование проводилось с использованием двух магистральных каналов связи - выделенного 1 Гбит/с и разделяемого 1 Гбит/с, в котором помимо исследуемого трафика передавалось до 100 Мбит/с интернет трафика. Результаты тестирования с использованием разделяемого канала связи показаны на рисунке 11.

cubic reno vegas yeah bic highspeed htcp hybla ]p scalable veno westwood iilinois Алгоритм управления перегрузкой TCP

Рисунок 11. Сравнение эффективности алгоритмов управления перегрузкой TCP по каналу 1 Гбит/с Пермь-Екатеринбург при наличии фонового интернет трафика (0,1 Гбит/с) и числе параллельных потоков (1, 4, 16, 64)

Из графиков следует, что наличие даже небольшого количества (менее 10%) стороннего трафика существенно снижает эффективность многих алгоритмов, но большинство алгоритмов достигают скорости передачи данных, близкой к максимальной пропускной способности канала при числе параллельных потоков в диапазоне от 4 до 16. Поэтому при наличии возможности настройки задействованных систем (в особенности тех компонент, на которых преобладает

исходящий трафик) эффективность передачи данных можно повысить путем выбора лучшего в данных условиях алгоритма управления перегрузкой из доступных в операционной системе, а также путем настройки размеров буферов в зависимости от пропускной способности канала связи и его RTF. В используемой инфраструктуре проекта «Распределенный PIV» для сервера очередей был выбран алгоритм управления перегрузкой bic, как обеспечивающий приемлемую эффективность, как в случае выделенного, так и в случае разделяемого канала передачи данных.

Исследование эффективной пропускной способности системы проводилось для двух транспортных протоколов: TCP и UDT. Исходные данные поступали в систему с заданной периодичностью и забирались на обработку вычислительными узлами. Это позволило проверить методику оценки требуемых вычислительных ресурсов для транспортного протокола TCP и экспериментально определить значение параметра пр для протокола UDT. В обоих случаях использовался выделенный канал связи 1 Гбит/с.

Измерения проводились для сообщений размером 2-22 Мб, временем между событиями появления новых данных (t\) 50 мс - 1 с и временем обработки одного блока данных (£м) 50 мс - 50 с. Выбранные диапазоны значений соответствуют некоторым режимам работы экспериментальной установки PIV, установленной в ИМСС УрО РАН и расширены в сторону увеличения необходимой скорости передачи данных до возможностей существующей инфраструктуры.

Измерения и последующий анализ, проведенные для протокола TCP, показали, что наличие во внутренней сети суперкомпьютера дополнительного трафика достаточно для того, чтобы в случае большой интенсивности потока данных общее поведение алгоритмов TCP было похоже на их поведение в протяженном разделяемом канале связи, несмотря на то, что доступная пропускная способность внутренней сети была больше, чем требовалось для экспериментов. Кроме того, при высокой интенсивности генерации данных, рассинхронизация интервалов обработки и генерации будет приводить к локальным перегрузкам системы. Также в этой области динамика разгона TCP-сессии оказывалась недостаточной, в результате чего, при передаче некоторого начального количества сообщений, реальная скорость передачи оказывалась существенно ниже достижимой. Анализ результатов измерений показал, что в области высокой интенсивности генерируемого потока данных реальное значение параметра пр для протокола TCP с алгоритмом управления перегрузкой bic равнялся 11, т.е. требовалось 11 дополнительных соединений для достижения требуемой скорости передачи данных.

Для протокола UDT экспериментально полученное значение параметра пр было равно 4. Однако, несмотря на то, что данный параметр оказался ниже, чем в случае с TCP, при использовании UDT наблюдалась существенная нагрузка процессора сервера, тем самым скорость передачи данных ограничивалась не только каналом связи и потоком исходных данных, но и вычислительной производительностью сервера очередей. Из-за этого в области высокой интенсивности потока данных реальная скорость генерации была примерно в 2 раза ниже, чем требуемая, и, как следствие, значение параметра пр = 4 отражает не всю динамику поведения UDT-протокола. Можно сделать вывод, что при использовании

протокола UDT требуется минимум в 2 раза более производительное оборудование на уровне генерации и распределения данных, чем для протокола TCP, а также вывод, что реальное значение параметра пр может быть больше, чем измеренный в рамках этих исследований.

Тестирование масштабируемости программного обеспечения проводилось с использованием двух серверов IIP ProLiant DL360p Gen8 (2x Intel Xeon CPU E5-2660, 2.20 ГГц, 16потоков; RAM 128 Гб; операционная система CentOS 6.5), объединенных сетью передачи данных пропускной способностью 10 Гбит/с.

'SciMQ: 1 поток FUS Г Mblt/s 'SciMQ: 1 поток ОПТ Mbit.'s 'SciMQ: 4 потока POST Mbn/s 'SciMQ: 4 потока GET Mbil/s SciMO: S nna POST Mbil/s SciMQ; 8 потоков GET Mbil/s 1 поток POST Mbit's 1 поток GET Mbit's 4 потока POST Mbit's

4 потока GET Mbit's

5 мотков POST Mbil/s S потоков GET Mbit's

SdMQ: 1 iioioK POST Msg's

SciMQ: 1 поток GET Msg's

SciMQ: 4 потока POST Msg-'s

SciMQ: 4 потока GET Msg's

SciMQ: 8 потоков POST Msg's

■^"SciMQ: Я потоков GET Msg's

— RMQ: 1 ittmiK POST Vlsg.'s

RMQ: ] поток GET Msg's

--RMQ: 4 потока POST Msg's

—RMQ: 4 потока GET Msg's

RMQ: X потоков POS I Msg's Размер сообщении (Mil)

RMQ: 8 потоков GET Msg's

Рисунок 12. Графики производительности сервера очередей SciMQ и RabbitMQ

На рисунке 12 показаны зависимости пропускной способности разработанного сервера очередей SciMQ и существующего сервера очередей RabbitMQ от размера сообщения и количества параллельных запросов к серверу. Из графиков следует, что при использовании программного обеспечения SciMQ на требуемых на практике размерах сообщений (2-22 Мб), пропускная способность ограничивается в основном доступной скоростью канала связи. Сравнение полученных результатов с результатами тестирования производительности возможных готовых решений на примере RabbitMQ показывает, что разработанное программное обеспечение SciMQ позволяет диспетчеризировать сообщения требуемых объемов (более 1 Мб) при интенсивности потока данных в 2-4 раза больше, чем RabbitMQ.

Для изучения стабильности работы системы во времени было проведено тестирование, эмулирующее 12-ти часовой эксперимент со скоростью потока исходных данных 8 Гбит/с. Для этого сервер очередей был подключен на скорости 10 Гбит/с к внутреннему коммутатору интерконнекта суперкомпьютера ИМСС УрО РАН. Поток исходных данных состоял из сообщений размером 16 Мбайт,

которые передавались каждые 16 мс. В эксперименте было передано 2700000 сообщений общим объемом 41 Тбайт. За получение данных отвечали 376 процессов, запущенных на суперкомпьютере ИМСС УрО РАН.

На рисунке 13 показано изменение длины очереди исходных данных (включая число сообщений, находящихся в обработке) и средние интервалы между поступлением исходных сообщений и отправкой сообщений клиентам.

(I 1 2 3 4 5 6 7 8 9 10 И 12

Время 1ч)

Рисунок 13. Графики изменения длины очереди исходных данных (включая число сообщений, находящихся в обработке) и средних интервалов между поступлением исходных сообщений и отправкой сообщений клиентам

Из приведенных графиков следует:

• пиковое потребление оперативной памяти сервером очередей было равно 2,03 Гбайт (130 сообщений по 16 Мб в памяти), а среднее - 1,58 Гбайт (101 сообщение по 16 Мб в памяти), что совпадает со статистикой потребления ресурсов, которую ведет программное обеспечение;

• система работает без перегрузок и обеспечивает обработку потока данных без дополнительных задержек и потерь сообщений;

• средние параметры работы системы не меняются во времени;

• программное обеспечение способно передавать продолжительные по времени потоки данных.

В заключении приведены основные результаты диссертационной работы.

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

2. Предложена модель обработки потоков экспериментальных данных в рас-

пределенных системах в реальном времени, основанная на идее параллельного прямого ввода в вычислительные узлы удаленного суперкомпьютера структурированного потока данных.

3. Разработан алгоритм диспетчеризации параллельных потоков данных, обеспечивающий допустимые техническими средствами скорость передачи и вычислительной обработки следующими способами:

• автоматическая балансировка нагрузки по вычислительным узлам;

• параллелизм передачи данных;

• учет специфики работы транспортных протоколов по скоростным протяженным линиям связи.

4. Предложена методика оценки требуемых вычислительных ресурсов суперкомпьютера и скорости в линии связи для обработки потока данных.

5. Разработан прикладной протокол (формат передачи и правила взаимодействия) для передачи элементов структурированного потока данных между компонентами распределенной системы.

6. Создана программная инфраструктура для организации распределенной обработки структурированного потока данных на основе разработанных технологий.

7. Созданы инструментальные средства тестирования для поиска параметров настроек узлов распределенной системы, обеспечивающих достижимую техническими средствами пропускную способность.

Основные публикации по теме диссертационной работы в рецензируемых журналах и изданиях, рекомендуемых ВАК

1. Степанов Р., Масич А., Щапов В. и др. Обработка на супервычислителе потока экспериментальных данных // Вестник УГАТУ. 2012. Т. 16, № 3(48). С. 126-133. URL: http://journal.ugatu.ac.ru/index.php/vestnik/ article/view/82.

2. Shchapov V., Masich A. Protocol of high speed data transfer from Particle Image Velocimetry system to supercomputer // Strategic Technology (IFOST), 2012 7th International Forum on. 2012.— sept. P. 1 -5.

3. Щапов В. А., Масич А. Г., Масич Г. Ф. Модель потоковой обработки экспериментальных данных в распределенных системах // Вычислительные методы и программирование. 2012. Т. 13, № 2. С. 139-145. URL: http: //num-meth.srcc.msu.su/zhurnal/tom_2012/vl3r218.html.

Другие публикации

4. Масич А. Г., Щапов В. А., Масич Г. Ф., Степанов Р. А. Протокол обмена интенсивным потоком данных между экспериментальной установкой и супервычислителем // Сб. тез. докл. XVII конференции представителей региональных научно-образовательных сетей "RELARN-2010". 2010. С. 26-33.

5. Масич А. Г., Масич Г. Ф., Степанов Р. А., Щапов В. А. Скоростной 1/О-канал супервычислителя и протокол обмена интенсивным потоком экспериментальных данных // Материалы X международной конференции «Высокопроизводительные параллельные вычисления на кластерных системах «НРС-2010»». Т. 2. Пермь: 2010. С. 119-128.

6. Масич А. Г., Масич Г. Ф., Щапов 1 Степанов Р. А. Потоковая обработка больших массивов экспериментальных данных на удаленном суперкомпьютере // ZBORNIK RADOVA KONFERENCIJE MIT 2011. Beograd: 2012.-mart. С. 266-270.

7. Щапов В. А., Масич А. Г., Масич Г. Ф. Экспериментальная оценка эффективности модели очередей и алгоритмов параллельной передачи в задачах обработки интенсивных потоков данных в распределенных системах // Тезисы Международной конференции «Математические и информационные технологии MIT-2013», (5.09.2013-8.09.2013, Вр-нячка Баня, Сербия, 9.09.2013 - 14.09.2013, Будва, Черногория). Белград: 2013. С. 105. URL: http://conf.nsc.ru/files/conferences/ MIT-2013/abstracts/146517/146518/Shchapov(MIT-2013).doc (дата обращения: 16.09.2013).

8. Степанов Р. А., Масич А. Г., Щапов В. А. и др. Обработка на супервычислителе потока экспериментальных данных // Научный сервис в сети Интернет: экзафлопсное будущее: Труды Международной суперкомпьютерной конференции (19-24 сентября 2011 г., г. Новороссийск). М.: Изд-во МГУ, 2011. С. 168-174.

9. Щапов В. А., Масич А. Г., Масич Г. Ф. Модель потоковой обработки экспериментальных данных в распределенных системах // Научный сервис в сети Интернет: поиск новых решений: Труды Международной суперкомпьютерной конференции (17-22 сентября 2012 г., г. Новороссийск). М.: Изд-во МГУ, 2012. С. 227-232.

10. Щапов В. А., Масич А. Г., Масич Г. Ф. Алгоритм распределения потока экспериментальных данных по вычислительным узлам суперкомпьютера // Доклады Международной конференция «Интеллектуализация обработки информации» (16-22 сентября 2012 г., Черногория, г. Будва). 2012. С. 699-702.

11. Щапов В. А. Программная архитектура системы передачи интенсивного потока данных в распределенных системах // Параллельные вычислительные технологии (ПаВТ'2013): труды международной научной конференции (г. Челябинск, 1-5 апреля 2013 г.). Челябинск: Издательский центр ЮУрГУ, 2013. С. 566-576.

12. Щапов В. А., Масич А. Г. Свидетельство о государственной регистрации программы для ЭВМ №2011614084 «Программный комплекс для передачи данных в распределенном эксперименте PIV». РОСПАТЕНТ. 25.05.2011.

Подписано в печать 16.01.2015. Тираж 100 экз. Усл. печ. л. 1,0 Формат 60x84/16. Набор компьютерный. Заказ № 893/2014.

Отпечатано с готового оригинал-макета в типографии издательства Пермского национального исследовательского политехнического университета 614990, г. Пермь, Комсомольский пр., 29, к. 113. Тел.: (342) 219-80-33