CC BY
15
Бурлаков Андрей Анатольевич, канд. воен. наук, доцент, burlakov [email protected], Россия, Санкт-Петербург, Военная академия связи
A MODEL FOR DETERMINING ADDITIONAL COSTS DEPENDING ON THE RELIABILITY OF THE SAMPLE TECHNICAL MEANS OF SPECIAL PURPOSE
A.V. Myakotin, E.V. Komarov, A.I. Muravyev, V.A. Pitenko, A.A. Burlakov
The article substantiates the need to improve the reliability of special-purpose technical means. The problem of allocating additional costs to ensure the reliability of the product at the stages of development, production and operation is considered and a variant of its solution is proposed.
Key words: technical means of special purpose, life cycle, reliability, costs.
Myakotin Alexander Viktorovich, doctor of technical sciences, professor, [email protected], Russia, St. Petersburg, Military Academy of Communications,
Komarov Evgeny Vladimirovich, candidate of military sciences, docent, SCS, komarovv53@,mail.ru, Russia, St. Petersburg, Military Academy of Communications,
Muravyev Alexander Ivanovich, lecturer of the department, muravjev. a1 @yandex. ru, Russia, St. Petersburg, Military Academy of Communications,
Pitenko Valery Aleksandrovich, senior lecturer of the department, [email protected], Russia, St. Petersburg, Military Academy of Communications, Russia, St. Petersburg, Military Academy of Communications,
Burlakov Andrey Anatolyevich, candidate of military sciences, docent, [email protected], Russia, St. Petersburg, Military Academy of Communications
УДК 004
DOI: 10.24412/2071-6168-2022-7-25-33
ОПТИМИЗАЦИЯ МЕТОДИКИ ПРОЦЕССА РЕЗЕРВНОГО КОПИРОВАНИЯ
ДЛЯ ПРОЕКТОВ UNREAL ENGINE В УСЛОВИЯХ ОГРАНИЧЕННОГО СВОБОДНОГО ОБЪЕМА ДИСКОВОГО ПРОСТРАНСТВА
Б.С. Яковлев, М.Ю. Шамрин
Рассмотрены вопросы, связанные с реализацией резервного копирования для игровых и мультимедийных проектов, выполненных на основе Unreal Engine. Показаны влияние способа копирования данных, связь структуры и типов файлов на скорость процесса резервного копирования.
Ключевые слова: резервное копирование, игровой движок, Unreal Engine, структура данных, централизованное хранение данных, контроль версий.
За последние 10 лет бурно развивается медиа индустрия, растут требования к качеству, реалистичности графической составляющей, звуку. Всегда считалось, что качество спецэффектов в кино, графики в играх и других продуктах сдерживается временем подготовки итогового контента. Сделать сложную сцену, подсветку, анимацию персонажа, сделать крайне детализированную 3D-модель не являлось ранее и тем более сейчас невыполнимой задачей. Киностудии и игровые гиганты не могут ждать окончания подготовки видео или отдельных кадров месяцами, а иногда и годами, если в проект заложить максимальное качество итогового рендеринга. На это влияет прежде всего производительность аппаратной части ЭВМ, отвечающее за процесс.
Однако, в данный момент времени развитие технологий, увеличение объемов памяти, скорости передачи, обработки данных привело, что мы все ближе к эффекту «зловещей долины». Нам тяжело отличить огонь, дым, воду, закаты и пейзажи, персонажей, людей, технику, снятых на кинопленку от, созданных при помощи популярных SD-программных решений.
Сами программы тоже не остаются в стороне, появляются новые технологии расчета освещения, управления частицами, упрощается захват движений, создание реалистичного персонажа, также можно отметить развитие генерации пространств и объектов, что упрощает и главное ускоряет процесс создания контента почти любой сложности.
Появление ассетов, особенно бесплатных наборов от крупных фирм, затрагивающие почти все сферы деятельности человека, природы, техники, животных, также очень позитивно сказалось на качестве и объемах мультимедийной продукции. Разработчики перестали тратить много усилий на создание своих собственных моделей, скорее они переквалифицировались в полноценных дизайнеров, расставляющих предметы на общей сцене, добиваясь задуманного эффекта.
Не стоит сбрасывать со счетов и тенденции на изменение стандарта разрешения. За последние 10 лет они изменились с типичного разрешения 800 х 600 до 1920 х 1080 (Full HD) и 3840 х 2160 пикселей (4k). При этом от Full HD до 4k данный процесс прошел быстрее обычного и занял 3 - 4 года.
Подход крупнейших студий к своим разработкам тоже сказывается на индустрии. Так Epic Game сделало достаточно давно свой основной игровой движок бесплатным, для некоммерческих проектов, она же активно сотрудничает с другими производителями программного обеспечения, например, с бесплатным редактором трехмерной графики Blender, внедряет удобные инструменты по симбиозу своих возможностей с элементами Houdini, который ранее всегда рассматривался как отдельный продукт, ориентированный на имитацию поведения частиц. Это позволило компании стать очень полезной и практически безальтернативной разработкой, дающей непревзойденный результат.
Надо сказать, что результат действительно впечатляющий, компаниям удалось объединить сообщество и привести к единому мышлению, и стремлениям, заложить новый стандарт качества.
Однако, для производителей встал другой вопрос, так как проекты стали более сложными и затратными, любая потеря данных приводит к остановке и достаточно долгой. Этот вопрос стал еще более важным после появления вирусов шифровальщиков, которые фактически уничтожали проект. Даже его создатели вряд ли могут расшифровать файлы, после действий вирусов.
Существующие технологии нередко не подходят для мультимедийных проектов. Так контроль версий, который считался в ряде профессий незаменимым инструментом не работает для больших медийных проектов, так как слишком большие изменения вносятся программами в содержание и структуру файлов. Поэтому любые бинарные данные, особенно большие по объему, просто будут усложнять базу контроля версий и нередко копии подобных проектов занимают больший объем, чем он же в актуальном состоянии.
Поэтому данные компании в тесном сотрудничестве с крупнейшими дата-центрами решают эту проблему переносом копий на сетевые хранилища или внутренние сервера компаний. Чаще всего они организованы на технологиях RAID, в зависимости от задач [1, 2].
Однако небольшие, инди студии в своих проектах тоже используют мощности игровых движков, и им сложнее решить задачу с резервными копиями проектов. К сожалению, это важно, так как любое не поправимое действие может уничтожить или откатить весь прогресс. Зависания, закрытия с ошибками программного обеспечения нередки, они могут повредить файловую структуру проекта, не сохранить наработки, загруженные материалы, текстуры. В этом случае может помочь только полное восстановление проекта из копий.
Сам процесс резервного копирования был неоднократно описан в различной литературе и статьях [3, 4, 5]. Также процесс контроля целостности данных и его сохранение относится к одному из направлений «Комплексной системы безопасности» (КСЗИ). В первую очередь - это защита информации и определение ответственности за несанкционированный доступ к ней, а именно - нормативно-правовые меры, необходимые для решения следующих вопросов [6, 7]:
- разделение на категории доступа - открытый или ограниченный доступ;
- распределение ролей и доступа к информации в различных учреждениях и на производственных объектах;
- права и обязанности должностных лиц;
- юридические и технические возможности организации, необходимые для осуществления доступа к базам данных и иным типам данных, документам;
- лицензирование деятельности организаций, занимающихся вопросами защиты данных.
Технические аспекты, влияющие на устойчивость и скорость процесса резервного копирования в целом ясны. В основном - это количество и размер файлов в проекте, каталоге. В работе [3] показано, что при условии одинаковых объемов данных, но различиях в количестве файлов, меньшее время будет у каталога с меньшим количеством файлов.
Также известно, что технологии децентрализованного хранения данных в целом быстрее, чем централизованные. Но многие забывают, что относящиеся к ним RAID массивы и реализованное решение для PS5, ускоряют процесс не сами по себе, из-за алгоритма, а из-за того, что в итоге файл читается с больше чем одного физического диска. Это сильно ускоряет процесс, так как в этом случае данные поступают параллельно с разных источников.
Поэтому процесс резервного копирования можно ускорить при помощи просто изменения методики резервного копирования, например, смены направления копирования, места назначения хранения и т.д.
Проведем ряд экспериментов, необходимых для установления значимых параметров на процесс резервного копирования. В частности, необходимо установить влияние на процесс направления копирования, возможности сжатия файлов проекта.
В качестве тестовых проектов были выбраны 4 проекта, разного объема:
1. 393 файла, 30 каталогов - 583 Мб;
2. 856 файлов, 129 каталогов - 1 Гб 166 Мб (1166 Мб);
3. 524 файла, 190 каталогов - 5 Гб 26 Мб (5026 Мб);
4. 9355 файлов, 498 каталогов - 30 Гб 417 Мб (30417 Мб).
Эксперимент был проведен на ЭВМ со следующими техническими параметрами:
1. Операционная система Windows 11 Pro, версия 21H2, сборка 22000.856. Взаимодействие Windows Feature Experience Pack 1000.22000.856.0;
2. Тип системы: 64-разрядная операционная система, процессор x64;
3. Процессор: Intel(R) Core(TM) Í9-10900F CPU @ 2.80GHz 2.81 GHz;
4. Оперативная память: 64,0 ГБ (доступно: 63,9 ГБ);
5. Жесткие диски: 2 диска 3 Тб Western Digital - WD Red NAS Hard Drive. Технические характеристики:
Емкость: 3 ТБ;
Интерфейс: SATA;
Transfer Rate: up to 180MB/s;
Form Factor: 3.5 дюйма;
Объем кэш-памяти: 256 МБ;
Disk Speed (RPM): 5400rpm;
Совместимость: использует технологию SMR в системах NAS с 1-8 отсеками, оптимизированных для массивов RAID, для выполнения таких задач, как хранение, архивирование и предоставление доступа в персональных системах и в условиях домашнего офиса;
Recording Technology: SMR;
Габариты (Д х Ш х В): 147мм x 101.6мм x 26.1мм.
Наиболее важным параметром здесь является скорость вращения шпинделя, он занижен во всех сериях RED данной компании до 5400 оборотов в минуту.
Эксперимент были выполнены следующим образом.
1. Для установления влияния структуры каталогов на скорость процесса:
а - отобранные проекты были скопированы в формате «как есть», с полным сохранением структуры и данных;
б - отобранные проекты были скопированы с применением предварительного архивирования.
Архивирование производилось двумя способами - один файл, и многотомный архив, разделенный на части объемом 300 Мб. Считается, что данный размер идеален для копирования в условиях облачных хранилищ.
2. Для установления влияния направления копирования, описанные выше действия, производились для трех случаев:
а - на разные жесткие диски в пределах одного ЭВМ;
б - в пределах одного жесткого диска (первая запись данных); в - в пределах одного жесткого диска (повторная запись данных).
В ходе проведения эксперимента были получены результаты, представленные в табл.
1 - 3.
Таблица 1
Время и средняя скорость процесса резервного копирование проекта,
представленном в изначальном виде
№ п/п Количество файлов и каталогов Объем Время копирования Рассчитанная средняя скорость
В пределах одного жесткого диска (первая запись данных)
1 393 файла, 30 каталогов 583 Мб 11,31 51,5 Мб/с
2 856 файлов, 129 каталогов 1 Гб 166 Мб (1166 Мб) 30,19 с 38,6 Мб/с
3 524 файла, 190 каталогов 5 Гб 26 Мб (5026 Мб) 113 с (1 мин. 53 с) 44,5 Мб/с
4 9355 файлов, 498 каталогов 30 Гб 417 Мб (30417 Мб) 767 с (12 мин. 47 с) 39,6 Мб/с
В пределах одного жесткого диска (повторная запись данных)
1 393 файла, 30 каталогов 583 Мб 1,3 с 448,5 Мб/с
2 856 файлов, 129 каталогов 1 Гб 166 Мб (1166 Мб) 1,6 с 728,7 Мб/с
3 524 файла, 190 каталогов 5 Гб 26 Мб (5026 Мб) 3,7 с 1358 Мб/с
4 9355 файлов, 498 каталогов 30 Гб 417 Мб (30417 Мб) 645 с (10 мин. 45 с) 47,1 Мб/с
На разные жесткие диски в пределах одного ЭВМ
1 393 файла, 30 каталогов 583 Мб 5,05 с 115,4 Мб/с
2 856 файлов, 129 каталогов 1 Гб 166 Мб (1166 Мб) 6,15 с 189,6 Мб/с
3 524 файла, 190 каталогов 5 Гб 26 Мб (5026 Мб) 34,62 с 146,7 Мб/с
4 9355 файлов, 498 каталогов 30 Гб 417 Мб (30417 Мб) 284 с (4 мин. 44 с) 107,1 Мб/с
Таблица 2
Время процесса архивирования в формате __
№ п/п Итоговый Время создания архива Среднее зна-
Степень сжатия объем ар- без разделения с разделением чение време-
хива на тома на тома ни
Без сжатия 656 Мб 463 Кб 2 с 3 с
Скоростной 591 Мб 757 Кб 7 с 7 с
1 Быстрый 589 Мб 645 Кб 14 с 13 с без томов: 19,5 с
Нормальный 583 Мб 836 Кб 19 с 19 с с томами: 19,3 с
Максимальный 583 Мб 695 Кб 23 с 22 с
Ультра 583 Мб 263 Кб 52 с 52 с
Окончание таблицы 2
№ п/п Степень сжатия Итоговый объем Время создания архива Среднее значение
архива времени
Без сжатия 1 Гб 305 Мб 339 Кб 3 с 3
Скоростной 1 Гб 183 Мб 892 Кб 14 с 14 с
2 Быстрый 1 Гб 178 Мб 35 Кб 27 с 27 с без томов: 29 с
Нормальный 1 Гб 167 Мб 426 Кб 32 с 31 с с томами: 28,5 с
Максимальный 1 Гб 166 Мб 669 Кб 33 с 33 с
Ультра 1 Гб 166 Мб 593 Кб 65 с (1 мин. 5 с) 65 с (1 мин. 5 с)
Без сжатия 5 Гб 310 Мб 205 Кб 8 с 7 с
Скоростной 5 Гб 68 Мб 194 Кб 60 с 61 с
Быстрый 5 Гб 49 115 с 114 с без томов:
3 Мб 234 Кб (1 мин. 55 с) (1 мин. 54 с) 112,5 с
Нормальный 5 Гб 34 Мб 649 Кб 134 с (2 мин. 14 с) 134 с (2 мин. 14 с) с томами: 112,3 с
Максимальный 5 Гб 31 Мб 211 Кб 141 с (2 мин. 21с) 141 с (2 мин. 21 с)
Ультра 5 Гб 26 Мб 793 Кб 217с (3 мин. 37 с) 217с (3 мин. 37 с)
Без сжатия 30 Гб 417 Мб 690 Кб 857 с (14 мин. 17 с) 822 с 13 мин. 42 с
Скоростной 28 Гб 841 Мб 294 Кб 838 с (13 мин. 58 с) 806 с 13 мин. 26 с
Быстрый 28 Гб 586 Мб 257 Кб 802 с (13 мин. 22 с) 840 с (14 мин.) без томов:
4 Нормальный 27 Гб 905 Мб 337 Кб 822 с 13 мин. 42 с 854 с 14 мин. 14 с 893,5 с с томами:
Максимальный 26 Гб 487Мб 998 Кб 843 с (14 мин. 3 с) 897 с 14 мин. 57 с 911,3 с
Ультра 26 Гб 307Мб 615 Кб 1199 (19 мин. 59 с) 1249 с (20 мин. 49 с)
Таблица 3
Время копирования данных, полученных после предварительного архивирования_
№ п/п Время копирования архива (единый) Время копирования архива (многотомный) Итоговое время операции резервного копирования с учетом времени архивирования
В пределах одного жесткого диска (первая запись данных)
1 0,75 с 0,74 с 1,49 с
2 1,18 с 1,9 с 3,08 с
3 80,43 с 122,6 с 122,03 с
4 606,1 с 776,1 с 1382,2 с
Окончание таблицы 3
№ п/п Время копирования архива (единый) Время копирования архива (многотомный) Итоговое время операции резервного копирования с учетом времени архивирования
В пределах одного жесткого диска (повторная запись данных)
1 0,8 с 0,8 с 1,6 с
2 1 с 1,1 с 2,1 с
3 81,58 с 122,1 с 203,68 с
4 614,1 с (10 мин. 14 с) 767,1 с (12 мин. 47 с) 1381,2 с
На разные жесткие диски в пределах одного ЭВМ
1 0,82 с 0,81 с 1,63 с
2 1,16 с 1,1 с 2,26 с
3 4,34 с 27,85 32,19 с
4 227,1 с 277,1 с 504,2 с
По табл. 1, 3 можно выявить самый простой и очевидный фактор - это сам объем данных, чем выше, тем дольше идет резервное копирование независимо от методики.
На основе экспериментальных данных были получены графические зависимости, представленные на рис. 1 - 5.
1 1
□ 2 Ж 3 В пределах одного жесткого диска (первая запись данных) В пределах одного жесткого диска (повторная запись данных) На разные жесткие диски в пределах одного ЭВМ / / / и
700 --- /
/ / / / / / /
400 300 200 / / / / / / / /
_ ** ** *> у / ' у у у / /. 4---- , - / у у у у у у у у у - X
- * ~ -- у у у
100 0 _ ** * а — □ - " _ х-" _ ----- „ , - Г* у 1 -
О 5 10 15 20 25 30 35
Объем данных, Гб
Рис. 1. Процесс копирования (как есть)
Анализируя рис. 1 - 5 можно увидеть, что наименьшее время копирования наблюдается в случае операции на разных жестких дисках. Также процесс копирования один раз и повторно внутри одного жесткого диска ведут себя неодинаково. Если копирование проходит второй раз, то оно идет всегда быстрее. Однако, добиться такого практически невозможно, так как любое копирование файлов из иного источника данных нивелирует эффект.
Нам не совсем понятно с чем связан данный эффект, это требует дополнительного исследования. Мы полагаем что это могло быть из-за антивирусного программного обеспечения, не проверяющего файлы второй раз, либо возможности и особенности файловый системы NTFS и операционной системы.
Анализируя табл. 2 и рис. 4 - 5 (сравнивая с рис. 2 - 3) можно выявить, что процесс архивирования в целом вредит скорости процесса резервного копирования. Однако, без него нельзя создать однообразных по размеру файлов, поэтому для больших проектов это вынужденная мера.
1 Л-1-■-
V 1 -В пределах одного жесткого диска (первая запись данных)
□ 2 -В пределах одного жесткого диска (повторная запись данных)
И 3 ■ На разные жесткие диски в пределах одного ЭВМ_
Объем данных, Гб
Рис. 2. Процесс копирования (однотомного архива)
^ 1 - В пределах одного жесткого диска (первая запись данных) I □ 2 - В пределах одного жесткого диска (повторная запись данных) * 3 - На разные жесткие диски в пределах одного ЭВМ |
Объем данных, Гб
Рис. 3. Процесс копирования (многотомного архива)
ф 1 - В пределах одного жесткого диска (первая запись данных) □ 2 - В пределах одного жесткого диска (повторная запись данных) ж 3 ■ На разные жесткие диски в пределак одного ЭВМ
, **
Объем данных, Гб
Рис. 4. Процесс копирования (однотомного архива с учетом времени архивирования)
31
S.1000
ф 1 ■ В пределах одного жесткого диска (первая запись данных) 5 2 - В пределах одного жесткого диска (повторная запись данных) Я 3 - На разные жесткие диски в пределах одного ЭВМ
ч
ч
*
*
*
*
у
у
у* „
Объем данных, Гб
Рис. 5. Процесс копирования (многотомного архива с учетом времени архивирования)
При малых объемах проекта среднее время подготовки архива из табл. 2 соответствует нормальной степени сжатия, но начиная с 5 Гб это свойство не прослеживается.
На основе проведенных исследований можно сделать следующие основные выводы и рекомендации:
1. На основе имеющихся теоретических сведений децентрализованный способ хранения данных не лучшее решение, так как несмотря на скорость копирования данных, виртуальная структура в случае повреждения не даст восстановить все что на нем находилось. Централизованное хранение, хоть и является затратным по объемам, но оно более надежно.
2. Копию проектов имеет смысл размещать на разных жестких дисках. Время копирования в этом случае многократно меньше, чем в случае копий на одном диски.
3. Не имеет смысла иметь копии на одном и том же диски, так как в случае его выхода из строя будут потеряны и копии, и сам проект.
4. Наилучшим способом копирования данных является «как есть». Это даст наилучшее ускорение времени копирования.
5. При вводе предварительного архивирования целесообразно производить копирование одним файлом, без деления на тома. Об этом говорит рис. 4 и 5. Рис. 4 показывает, что процесс становится практически линейным на протяжении всего этапа, что дает максимально хорошие условия для предсказания времени длительности операции.
6. Стоит обратить внимание на то, что архив разбитый на тома будет удобнее при передачи данных по сети с ограниченной и малой скоростью. Это показывают ряд работ, выполненных до этого [3]. Также этот метод дает возможность станадартизировать эту процедуру, например, указать 300 Мб как стандарт размера тома, тогда предугадать время окончания станет легче во всей организации.
Список литературы
1. Rahman P.A. and G D'K Novikova F.S. Reliability model of disk arrays RAID-5 with data striping // IOP Conference Series: Materials Science and Engineering, 2018. Vol.: 327. DOI: 10.1088/1757-899X/327/2/022087.
2. Rahman P.A. Using a specialized Markov chain in the reliability model of disk arrays RAID-10 with data mirroring and striping // IOP Conference Series: Materials Science and Engineering, 2017. Vol.: 177. DOI: 10.1088/1757-899X/177/1/012087.
3. Proskuriakov N.E., Yakovlev B.S. Determination of parameters of the Automated backup process of digital data for printing houses and publishing houses without use of external network technologies transformations // Journal of Physics: Conference Series, Volume 1210, conference 1 (2019); DOI: 10.1088/1742-6596/1210/1/012116.
4. Ruben G.A. How to automatically test and validate your database backup and recovery strategy // Journal of Physics: Conference Series, 2011. Vol.: 331. DOI: 10.1088/17426596/331/4/042031.
5. Kalita A., Ozhiganova M., Tishchenko E. Basics of Adaptive Information Security Systems // NBI technologies. 2019. Vol. 13. No. 1. P. 11 - 15. DOI: 10.15688/NBIT.jvolsu.2019.1.2.
6. ГОСТ Р 50739-95 «Средства вычислительной техники. Защита от НСД к информации. Общие технические требования». М.: Госстандарт России, 2021. 8 с.
7. ГОСТ Р 50922-2006. Защита информации. Основные термины и определения. М.: Стардартинформ, 2006. 8 с.
Яковлев Борис Сергеевич, канд. техн. наук, доцент, [email protected], Россия, Тула, Тульский государственный университет,
Шамрин Максим Юрьевич, канд. юрид. наук, доцент, [email protected], Россия, Москва, Московский государственный юридический университет им. О.Е. Кутафина
OPTIMIZING THE BACKUP PROCESS TECHNIQUE FOR UNREAL ENGINE PROJECTS WITH LIMITED FREE DISK SPACE
B.S. Yakovlev, M.Yu. Shamrin
Issues related to the implementation of backup for game and multimedia projects based on the Unreal Engine are considered. The influence of the data copying method, the relationship between the structure and types offiles on the speed of the backup process is shown.
Key words: backup, game engine, Unreal Engine, data structure, centralized data storage, version control.
Yakovlev Boris Sergeevich, candidate of technical sciences, docent, [email protected], Russia, Tula, Tula State University,
Shamrin Maxim Yurievich, candidate of law sciences, docent, [email protected], Russia, Moscow, Kutafin Moscow State Law University
УДК 521.3
DOI: 10.24412/2071-6168-2022-7-33-38
МАТЕМАТИЧЕСКАЯ МОДЕЛЬ УГЛОВОГО ДВИЖЕНИЯ ЛИНИИ ВИЗИРОВАНИЯ ОБСЛУЖИВАЕМОГО КОСМИЧЕСКОГО АППАРАТА
Л.П. Зозуля, М.Ю. Булекбаева, П.С. Гончаров
Разработана математическая модель углового движения линии визирования обслуживаемого космического аппарата (ОКА) с применением аппарата кватернионов. Получены аналитические зависимости, позволяющие осуществлять прогнозирование появления ОКА в заданной точке пространства и выполнять моделирование углового движения линии визирования ОКА для решения задачи дистанционного осмотра. При моделировании может быть выполнен расчет дальности до ОКА.
Ключевые слова: линия визирования, обслуживаемый космический аппарат, космический аппарат орбитального обслуживания, математическая модель, угловое движение
Процесс выведения космического аппарата (КА) на околоземную орбиту является трудоемким и материально затратным. Поэтому обеспечение проектного срока активного существования (САС) КА является актуальной научно-технической задачей. Одной из причин прекращения активного существования КА является окончание запаса рабочего тела
33
