CC BY
1210. Heinisuo M., Laasonen M. Product modeling, part of the fire safety concept in the future for metal structures //Advanced Research Workshop, Fire Computer Modeling, Santander. (2007). - pp. 18-20.
11. Поздеев С.В. Разработка уточненного расчетного метода для определения предела огнестойкости несущих железобетонных конструкций. / Поздеев С.В., Левченко А.Д. // Вестник национального технического университета «Львовская политехника». - Львов: НТУ «Львовская политехника». - 2011. - С. 264 - 269.
12. Improvement of the estimation method of the possibility of progressive destruction of buildings caused by fire // IOP Conference Series: Materials Science and Engineering, 2019, 708(1), 012067 / Pozdieiev S., Nekora O., Kryshtal T., Sidnei S., Shvydenko A.
13. Method of the calculated estimation of the possibility of progressive destruction of buildings in result of fire // MATEC Web of Conferences, 2018, 230, 02026 / Pozdieiev S., Nekora O., Kryshtal T., Zazhoma V., Sidnei S.
14. Research of the behavioral of the wooden beams with fire protection lining under fire loading // IOP Conference Series: Materials Science and Engineering, 2021, 1021(1), 012031 / Zmaha M.I., Pozdieiev S.V., Zmaha Y.V., Nekora O.V., Sidnei S.O.
15. Temperature effect on the thermal-physical properties of fire-protective mineral wool cladding of steel structures under the conditions of fire resistance tests // Eastern-European Journal of Enterprise Technologies, 2020, 4(12-106), p. 39-45 / Pozdieiev S., Nuianzin O., Binetska O., Shvydenko A., Alimov B.
РЕАЛИЗАЦИЯ СЕТЕВОЙ АРХИТЕКТУРЫ ДЛЯ РАСПРЕДЕЛЁННОЙ СИСТЕМЫ ПРОВЕДЕНИЯ АУКЦИОНОВ НА ВИРТУАЛЬНЫЕ РЕСУРСЫ
Чекан М.А.
магистрант гр. ЭВМм-19-1, Иркутский национальный исследовательский технический университет г. Иркутск Широков В.В. методист,
Лаборатория развития научно-инженерного творчества (ЛАРНИТ) МБОУ Лицей №2,
г. Иркутск
IMPLEMENTATION OF NETWORK ARCHITECTURE FOR DISTRIBUTED AUCTION SYSTEM
FOR VIRTUAL RESOURCES
Chekan M.
postgraduate student of group EVMm-19-1, Irkutsk National Research Technical University
Irkutsk Shirokov V. methodist,
Laboratory of development of scientific and technical creativity of the Lyceum no. 2,
Irkutsk
Аннотация
В данной статье рассмотрена реализация распределённой сетевой архитектуры для многомодульного программного комплекса, предназначенного для проведения виртуальных аукционов в составе стенда-лаборатории по интеллектуальной энергетике. Архитектура с использо-ванием SSH-туннелирования и параметризуемых системных модулей на базе NixOS позволяет до-статочно быстро перенастраивать конфигурацию, обеспечивает безопасность соединения и пере-дачи данных.
Abstract
This article discusses the implementation of the distributed network architecture for a multi-module software package, created for conducting virtual auctions as part of stand-laboratory for intellectual energy. using. The architecture using SSH tunneling and parameterizable system modules based on NixOS allows to quickly change the configuration, ensures the security of the connection and data transmission
Ключевые слова: сетевая архитектура, распределённые системы, SSH, NixOS.
Keywords: network architecture, distributed systems, SSH, NixOS.
Введение. В настоящее время большинство вычислительного устройства и тем или иным обра-программных решений вышло за пределы одного зом охватывает комплекс устройств, соединённый
в информационную сеть, будь то Интернет в случае с прикладными сервисами и мобильными приложениями, или локальная вычислительная сеть на уровне предприятия, если речь идёт о встраиваемых автоматизированных системах. Все эти программные системы объединяет наличие распределённой сетевой архитектуры, соединяющей между собой различные программные модули, размещённые на отдельных устройствах одной сети. Принципы разработки распределённых программных систем сформированы достаточно давно, но при этом не существует единого стандарта де-факто, равно как и не может быть универсального рецепта, применимого для всех практических сценариев. Тем не менее, существуют технологии, признанные «хорошими практиками», равно как и инструменты, внедряющие эти технологии в разрабатываемое приложение. Разное сочетание технологий в зависимости от сценария позволяет сформировать архитектуру, решающую поставленную задачу.
Стенд-лаборатория «Интеллектуальные энергетические системы» [12] (далее - СТ-ИЭС) представляет собой аппаратно-программный комплекс для изучения интеллектуальной энергетики в игровой форме. Одним из этапов игровой сессии на стенде является закрытый аукцион на объекты потребления и генерации.
В первых версиях стенда аукцион проводился вручную, в 2018 году разработан модуль для их виртуального проведения [14]. Функционально он работает как клиент-серверная сетевая игра, где во время игровой сессии участники (пользователи стенда) асинхронно делают ставки на поочерёдно выставляемые игровые объекты. Ставки собираются сервером (ядром), сравниваются, после чего объект приписывается участнику-победителю. В конце аукциона данные об объектах передаются в модуль, реализующий основную часть игровой сессии на стенде. В 2020 году возникла необходимость доработать стенд-лабораторию для проведения распределённых мероприятий, когда игровая сессия проводится одновременно на нескольких стендах, размещённых в разных локациях и подключенных через облачный сервер. Модуль проведения аукционов также потребовалось переработать под распределённый формат проведения.
Обновлённый стенд состоит из трёх архитектурных уровней, образующих дерево, в корне которого находится логическое ядро, отвечающее за управление игровой сессией. Так как модуль рассчитан на использование в территориально распределённой конфигурации, подразумевается размещение ядра на облачном сетевом ресурсе и подключение к нему нескольких стендов, каждый из которых представлен сервером стенда. К нему, в свою очередь, в локальной сети подключены пользовательские рабочие станции (терминалы).
К модулю аукционов, как и остальному ПО стенда, помимо функциональных требований предъявлены следующие:
• Минимизация рисков внешнего вмешательства при сохранении относительной простоты
подключения и авторизации подмодулей (с учётом заранее известной конфигурации их подключения).
• Нивелирование сетевых задержек с сохранением относительной синхронности игровой сессии и равенства длительности тактов.
• Сохранение устойчивости системы при отказе одного из подмодулей, а также быстрое восстановление подмодуля при отказе.
Таким образом, необходимо разработать технологию, позволяющую объединить подмодули в описанную архитектуру и удовлетворить поставленным требованиям. Иными словами, цель работы — реализация распределённой трёхуровневой сетевой архитектуры многомодульного программного комплекса на базе UNIX-подобной ОС, удовлетворяющей требованиям по безопасности, отказоустойчивости и гибкости.
Для достижения цели выполнены следующие задачи:
• анализ существующих инструментов,
• выбор инструментов для реализации архитектуры,
• реализация архитектуры по выбранной технологии;
• практическое испытание архитектуры и анализ его результатов.
Заметим, что подробности нивелирования сетевых задержек не входят в тему этой статьи, т.к. это касается непосредственной реализации модулей, но, тем не менее, инструменты реализации сетевой архитектуры должны оказывать минимальное влияние на этот фактор.
1. Обзор и выбор инструментов. Теоретическая база распределённых программных систем обладает значительной степенью проработки, существуют работы, подробно рассматривающие её аспекты [1]. В частности, достаточно хорошо изучены централизованные архитектуры и их вариации (клиент-сервер, трёхзвенная, n-звенная). Поэтому в архитектурном плане современные работы уделяют достаточно много внимания децентрализованным (peer-to-peer) архитектурам, в частности на основе блокчейна [9].
Программные решения для реализации распределённых архитектур чаще всего сводятся к встраиваемым библиотекам для сетевого взаимодействия и передачи сообщений. Отдельно стоит выделить библиотеки для реализации удалённого вызова процедур (RPC), в частности gRPC [2], полноценное кроссплатформенное решение для распределённых вычислений.
Но в данной статье внимание уделяется именно сетевой инфраструктуре, а именно подключению сервисов между собой. По этому вопросу нет единого мнения, и чаще всего сервисы взаимодействуют через открытые каналы по протоколам TCP и UDP. Этот вариант наиболее быстрый, а в случае с TCP обеспечивает целостную двустороннюю передачу данных, но при этом накладывает требования по безопасности и сетевой инфраструктуре. Проблемы касательно сетевой инфраструктуры чаще всего заключаются в настройке маршрутизации и портов доступа, а вопросы безопасности
удовлетворяются путём различных надстроек, связанных с шифрованием и механизмами авторизации. Наиболее популярным в текущее время протоколом контроля доступа является OAuth [5], существуют готовые решения [6], реализующие взаимодействие по данному протоколу. Также для защиты приложений от атак типа «отказ в обслуживании» применяют балансировщики, в частности, NGINX [3].
В то же время существуют сценарии, где необходимо закрыть доступ к приложению из внешней сети всем, кроме доверенных узлов, особенно это актуально для корпоративных систем. Чаще всего для реализации таких сценариев применяют VPN-туннелирование, доступ через терминальное соединение (например, VNC) и публикацию веб-интерфейса по протоколу HTTPS [13], причём последний способ является наиболее желательным по утверждению автора источника. При этом VPN-туннелирование считается наиболее популярным и распространённым методом создания закрытого канала между узлами. Тем не менее, его использование сопряжено с рядом рисков и требует правильной настройки. То же касается веб-приложения, для реализации которого потребуется дополнительные трудозатраты. Терминальное соединение же используется в основном для организации пользовательского взаимодействия с рабочим столом (для этого используют VNC). В то же время, протокол SSH помимо основной функциональности - удалённого взаимодействия с пользовательской средой - предоставляет туннелирование TCP-соединений по зашифрованному каналу [10]. Для организации простейшего SSH-тоннеля достаточно двух узлов, где на одном установлен SSH-сервер, а на втором - клиент SSH, запускаемый с определённым набором аргументов. Оба компонента входят в стандартную поставку многих Linux-дистрибути-вов. Дальнейшая конфигурация зависит от требований к безопасности и инфраструктуре.
Наличие OpenSSH-сервера и клиента в составе стандартного системного ПО, а также простота конфигурации делает данный инструмент подходящим решением для построения сетевых приложений с распределённой архитектурой.
Как было упомянуто выше, для правильного функционирования требуется конфигурация SSH-компонентов. Если для клиента достаточно использования аргументов командной строки, то сервер необходимо настраивать через конфигурационный файл. При этом конфигурация может различаться в зависимости от сценария использования комплекса (в том числе в пределах одного продукта). К этом добавляются проблемы с массовым развёртыванием и переконфигурацией узлов системы. Существуют инструментальные средства для автоматизации этих процессов (Ansible, Chef), но они удобны для развёртывания отдельных компонентов, когда как есть сценарии с конфигурацией узлов системы целиком, на уровне ОС. Поэтому решено выбрать дистрибутив NixOS [4] на базе ядра Linux, учитывая, что ЭВМ стенда уже работают на его основе.
Особенностью NixOS является то, что система настраивается с помощью конфигурационных файлов на языке Nix, который используется в одноимённом файловом менеджере для описания пакетов. И пакеты, и конфигурации вычисляются из Nix-описания, что позволяет добавить параметры, влияющие на процесс сборки. На вычислимости и основана конфигурационная составляющая NixOS: сборщик вычисляет конфигурацию, сравнивает её с текущей и производит необходимые изменения в системных настройках и файлах, создаёт символьные ссылки на необходимые пакеты. Тем самым формируется статическая системная среда, не подверженная так называемому «bit rot», когда в системе скапливается много побочных файлов, замедляющих систему и препятствующих её последующей настройке. Пакетный менеджер Nix позволяет устанавливать в систему одновременно разные версии библиотек и программ, а также создавать изолированные среды (shells) без формирования файловых образов, как это делается в Docker. Все пакеты содержатся в хранилище изолированно друг от друга и от основной системы, добавление или удаление пакета не меняет системные файлы, а лишь меняет символьные ссылки на необходимые компоненты [11].
Главное же достоинство пакетов на языке Nix и системы NixOS - воспроизводимость и переносимость. Если Nix-пакет формирует работоспособную программу, то её можно гарантированно развернуть на любом компьютере на базе той же платформы. Аналогично, если NixOS-описание может сформировать систему, её можно развернуть на любом компьютере, и все экземпляры системы будут функционально идентичными. Также экосистема Nix предоставляет инструмент для развёртывания систем из нескольких машин - NixOps.
Архитектура, описанная на языке Nix, легко параметризуется, обеспечивает гибкость и простоту развёртывания на многочисленных конфигурациях, а также позволяет объединить описание и настройку сетевой архитектуры с развёртыванием узлов этой архитектуры, образующих в совокупности полноценный распределённый программный комплекс. Это обуславливает выбор NixOS в качестве второго, связующего компонента рассматриваемой архитектуры.
2. Описание архитектуры. Модуль состоит из сервисов, образующих трёхуровневое дерево, в корне которого находится сервер, логическое ядро, управляющее игровой логикой на основе принятых сообщений от участников. В данном сценарии роль промежуточного звена выполняет реле, координирующее взаимодействие с отдельным стендом и нивелирующего сетевую задержку за счёт хранения локальной копии игрового состояния. К реле подключаются медиаторы, размещённые на рабочих станциях участников и выполняющие формирование данных для графического интерфейса (рисунок 1). Данные между сервисами в цепи передаются через тоннель по протоколу WebSocket небольшими сообщениями, содержащими лишь изменения игрового состояния. Это позволяет свести к минимуму
нагрузку на канал связи, и как следствие, снизить сетевые задержки при передаче.
Рис. 1. Типовая конфигурация модулей для трёх площадок
Так, архитектура состоит из двух уровней клиент-серверных подключений. Рассмотрим пример реализации такого подключения на основе OpenSSH и NixOS. Пусть сервер предоставляет доступ к приложению через произвольный порт 12345, закрытый сетевым экраном. Также на порту 24000 запущен SSH-сервер, доступный в сети Интернет по адресу example.com через пользователя tunneler. Необходимо предоставить доступ определённому кругу клиентов (т.е. по «белому списку») к этому приложению. Очевидно, что в этом сценарии достаточно выполнить проброс (forwarding) порта 12345 на локальную машину, т.е. запустить SSH-клиент со следующими аргументами: ssh -NL 12345:localhost:12345 -p24000 tunneler@exam-ple.com. Эта команда создаст откроет SSH-канал на порту 12345, прозрачно передающий трафик в приложение на сервере.
Очевидно, что доступ к пользователю tunneler должен быть ограничен из соображений безопасности. С учётом автоматизации развёртывания архитектуры будет нерациональным использовать авторизацию по паролю, поэтому необходимо использование уникальных пар ключей шифрования для каждого клиента. Это означает, что на сервере (как принимающей стороне) необходимо записать публичные ключи клиентов, образуя тем самым выше-
coreAddre33 = "exar.ple . сэги"; kevFatn = n/Jreys/clier.t-001. Jreyn
упомянутый «белый список». Приватный ключ хранится в клиенте и используется при создании тоннеля.
Далее логичным будет отметить тот факт, что тоннель создаётся путём запуска SSH-клиента, и для автоматического создания необходимо задействовать системные средства. Дистрибутив NixOS работает на менеджере служб Systemd, что позволяет создать сервис, выполняющий запуск туннели-рования при включении узла, а также обеспечить перезапуск клиента в случае временной потери соединения или проблем с конфигурацией на принимающей стороне. Благодаря этому при правильной настройке такая сеть будет настраиваться автоматически без участия администраторов и обеспечивать ровно ту топологию, которая от неё ожидается.
Пример описания сервиса для создания тоннеля на языке Nix приведён на рис. 1. Это минимальный пример, который при добавлении в системную конфигурацию реализует автоматическое туннелирование порта 12345 с указанного сервера и обеспечивает перезапуск тоннеля с задержкой в 3 секунды при неполадках. Заметим, что некоторые параметры подключения (адрес и путь к приватному ключу) вынесены в отдельные переменные, которые могут вычисляться, в том числе в зависимости от иных конфигурационных параметров, индивидуальных для каждого клиента.
systemd. services . service-tunnel = -[
description = 1Сoj'i'.oservice - -. ______ _ T;
wantedBv = [ nmulti-tser.target" ]; 3erviceConf ig = -[ Type = "simplerUser = "root"; H]>Lec5tart =
{plrcjs . oper.ssh.l- /bir./ssh. -o ServerAliveIr_terval=2 0 \ -о г:лг.г.e с tTirreott = 2и -о ServerAlive~our.tMax=2 \ -o StrictHostKey~hecJrir.5=r.o -o UserKr.owr.HostsFile=/dev/r.ull \ -o Ider.tityFile=$ {JreyPath.} -p2iQ00 \
tur.r.elerGi { ccireAddre33} -L 12Si5 : local"r.:=i3t: 12г-.Ъ -1Г; Re3tart5ec = j; Restart = nor.-failtren ;
:;
:;
Рис. 2. Nix-конфигурация сервиса для создания тоннеля
Пример фрагмента конфигурации принимаю- виде строки, либо как на рисунке, чтением содер-
щей части приведен на рис. 2. Здесь активируется жимого файла, что достаточно удобно при хране-
SSH-сервер, настраивается нестандартный порт нии ключей в общей директории, из которой осу-
(как дополнительная мера безопасности) и созда- ществляется развёртывание системы. Если это до-
ётся пользователь tunneler, в который добавляются пускает сценарий, Nix позволяет реализовать
ключи разрешённых узлов. Их можно передавать в чтение всех ключей из заданной директории. В реализации модуля это не потребовалось.
k3 = builtirL3 . resdFile ./key3/cl±erLt-Q03 . key .р'лЬ;
орепззп. £ut.hor±zedKeys . keys = fj^^elKeys;
Рис. 3. Nix-конфигурация принимающей части
3. Практическое применение. На основе описанной выше технологии реализованы три сервиса (для каждого уровня архитектуры), образующие вместе модуль проведения аукционов. Во время его апробации на испытательных запусках и во время Олимпиады КД НТИ 2020-2021 года модуль отработал успешно и без ошибок, в том числе по сетевой составляющей. При обрыве подключения тоннель автоматически перезапускается через Systemd, а за счёт программной реализации при восстановлении связи выполняется отправка пакета синхронизации с актуальным состоянием.
Главным положительным фактором построения топологии на SSH-тоннелях является упрощение реализации системных модулей. Тоннель соединяет локальное пространство сетевых портов, благодаря чему межмашинное взаимодействие двух сервисов сводится к подключению в пределах логического устройства. В клиентской части достаточно реализовать подключение к определённому сетевому порту на локальной машине (номер порта может быть задан константой или определяться иным удобным способом). Серверная часть принимает подключения на локальный адрес (1оса1Ио&1), и при отсутствии необходимости в идентификации достаточно реализовать бизнес-логику, т.к. авторизация и шифрование уже осуществляются на уровне протокола SSH.
В случае с модулем аукционов требовалась идентификация клиента, что стало одной из значимых проблем реализации архитектуры. Текущим решением стало использование идентификатора клиентской рабочей станции, который прописывается через конфигурацию NixOS в закрытую часть системы и не изменяется пользователем. Так как
конфигурации узлов меняются редко и при грамотно построенном инструментарии применяются единственной командой, это решение признано удовлетворяющим поставленным требованиям.
Издержки на передачу данных через SSH-тоннели оказались минимальны, даже при передаче полного состояния игровой сессии. Отчасти это достигается за счёт оптимальной реализации протокола (минимизации числа и размеров передаваемых сообщений). При необходимости передавать большие объёмы данных можно применить разработки, направленные на увеличение скорости и снижение задержек [7, 8], также одним из решений будет дополнительная конфигурация сервера и клиента (включение сжатия, переиспользование подключений и т.д.). В текущей реализации проблема пропускной способности признана незначительной и не вносящей большого влияния в процесс использования конечной системы.
Огромным преимуществом оказалась возможность поместить сервис на любой узел с сохранением необходимой связности. Это позволяет без дополнительных изменений в программной части реализовать конфигурацию для одной площадки, где ядро и реле размещаются на сервере стенда (рисунок 4), либо, при конфигурации с несколькими стендами, рассредоточить сервисы по нескольким серверам для распределения вычислительной нагрузки. Отдельно стоит отметить, что во время разработки и отладки приложения сервисы всех трёх уровней можно выполнять на одном компьютере (рисунок 5), что снижает аппаратные требования к процессу разработки и ускоряет его за счёт быстрого получения обратной связи, в том числе благодаря отсутствию влияния сетевых каналов.
Рис. 4. Конфигурация модулей для одной площадки
Рис. 5. Конфигурация модулей для отладки на одном компьютере
Заключение. Распределённая архитектура на основе SSH-тоннелей и NixOS-конфигураций позволяет создавать воспроизводимые и при должном подходе легко настраиваемые конфигурации программных модулей. При правильном подходе к разработке сетевой составляющей модуля архитектура конечного приложения соответствует поставленным требованиям отказоустойчивости и безопасности. Делегирование создания межмашинных каналов системе позволяет упростить архитектуру самого модуля и сосредоточить внимание на бизнес-логике. Дополнительными преимуществами можно обозначить возможность отладки всего комплекса на одной локальной машине, а также гибкую маршрутизацию каналов связи с возможностью провести тоннель через промежуточный (proxy) узел, что при правильной настройке увеличивает безопасность.
Описанная технология использована для реализации модуля проведения виртуальных аукционов, реализованного как приложение с трёхуровневой клиент-серверной архитектурой, используемое в составе программного комплекса СТ-ИЭС. Практические испытания продемонстрировали гибкость и простоту развёртывания приложения, и его достаточную отказоустойчивость в случае проблем с сетью.
Очевидно, что успешное применение технологии предусматривает требования к ПО, в том числе усложняет процесс определения источника сообщения. С другой стороны, факт установленного SSH-соединения в большинстве случаев подразумевает его доверенность, что может позволяет свести задачу аутентификации к идентификации клиента внутри установленного подключения.
Список литературы
1. Burns B. Designing Distributed Systems: Patterns and Paradigms for Scalable, Reliable Services. -
Япония: "O'Reilly Media, Inc.", 2018. 149 с. ISBN: 9781491983614
2. gRPC: [сайт]. URL: https://grpc.io (дата обращения: 21.03.2021)
3. NGINX.: [сайт]. URL: https ://nginx. org (дата обращения: 21.03.2021)
4. NixOS Linux.: [сайт]. URL: https://nixos.org/ (дата обращения: 21.03.2021)
5. OAuth Community Site.: [сайт]. URL: https://oauth.net (дата обращения: 21.03.2021)
6. ORY Oathkeeper [Электронный ресурс] // GitHub: страница репозитория. URL: https://github.com/ory/oathkeeper (дата обращения: 21.03.2021)
7. Rapier C. et al. High performance SSH. [Электронный ресурс] // SCP-HPN-SSH: сайт. 2007. URL: http ://www.psc.edu/networking/proj ects/hpn-ssh
8. Rapier C., Bennett B. High speed bulk data transfer using the SSH protocol // Proceedings of the 15th ACM Mardi Gras conference: From lightweight mash-ups to lambda grids: Understanding the spectrum of distributed computing requirements, applications, tools, infrastructures, interoperability, and the incremental adoption of key capabilities. - 2008. - С. 1-7. DOI: 10.1145/1341811.1341824
9. Raval S. Decentralized applications: harnessing Bitcoin's blockchain technology. - США. "O'Reilly Media, Inc.", 2016. 103 с. ISBN: 9781491924549
10. SSH Tunnel [Электронный ресурс] // SSH.COM: [сайт]. URL: https://www.ssh.com/ssh/ tunneling/ (дата обращения: 21.03.2021)
11. Галатенко В.А., Дзабраев М.Д., Костюхин К.А. Выбор пакетного менеджера для многоверси-онных приложений // Программные продукты и системы. 2018. Т. 31. № 3. С. 469-474. DOI: 10.15827/0236-235X. 123.469-474.45
12. ИЭС [Электронный ресурс] // Полюс-НТ: [сайт производителя]. 2021. URL: http://polyus-nt.ru/powerstand.html (дата обращения: 20.03.2021)
13. Скородумов А. Безопасный доступ к информационным ресурсам компании // «Information Security/ Информационная безопасность».: электрон. версия журн. 2016. № 2. URL: http://lib.itsec.ru/articles2/sys_ogr_dost/bezopasnyy-dostup-k-informatsionnym-resursam-kompanii (дата обращения: 21.03.2021)
14. Чекан М.А. Разработка модуля проведения виртуальных аукционов для тренировочного стенда СТ-ИЭС ООО «Полюс-НТ» // Винеровские чтения - 2019: мат-лы Всероссийской молодежной науч.-практ. конференции. - Иркутск: Изд-во ИРНИТУ, 2019. С. 100-105.
