Сравнительный анализ объектных систем хранения данных с открытым исходным кодом

Полный текст

Введение В рамках предоставления услуг корпоративного мессенджера неизбежно возникает потребность хранения больших объемов пользовательских файлов. В настоящее время в рассматриваемом авторами мессенджере объем потребности насчитывает в среднем 24 терабайта хранимых файлов в год, однако этот показатель имеет тенденцию к увеличению. Период хранения составляет минимум 1 год (с возможностью продления срока). При удалении учетной записи пользователя файлы, владельцем которых являлся этот пользователь, необходимо сохранять в течение 1 календарного месяца. Цель исследования - выбор оптимального решения для предоставления пользователям возможности удаленного хранения не ограниченных по размеру данных произвольного формата. Наибольший интерес для реализации запроса представляют открытые решения. Согласно Национальному стандарту Российской Федерации ГОСТ Р 7.0.95-2015[7], электронный объект - это файл (или совокупность файлов), формируемый в компьютерной программе пользователя или в автоматизированной системе и содержащий в зафиксированном виде данные, предназначенные для восприятия с помощью средств вычислительной техники [1]. Файл - это именованная часть диска [2]. Ниже перечислим основные существующие типы систем хранения данных [3]. 1. Файловое хранилище - традиционная модель хранения данных, где информация организована в иерархическую структуру [4]. Это наиболее распространенный и простой тип структурированного хранения данных, который чаще всего можно найти на персональных компьютерах, серверах и мобильных устройствах. В данной модели каждый файл имеет уникальное имя, сопровождается метаданными (информацией о файле) и занимает строго определенное место в иерархии [5]. Преимущества файловой системы в иерархическом формате заключаются в ее простоте и интуитивной понятности для большинства конечных пользователей, что не требует от них особых навыков для работы и настройки, а также возможность кроссплатформенной совместимости по причине высокой популярности. Кроме того, такой тип хранения данных является относительно экономически эффективным и безопасным [6]. К недостаткам файлового хранилища можно отнести: - ограничения на размеры файлов в хранилище, - ограничения на количество файлов, - сложности с масштабированием системы. Данная форма хранения предпочтительна для относительно небольших объемов данных и локального использования обычными пользователями. Организация общего доступа к содержимому файлового хранилища может быть реализована с использованием специализированных расширений, таких как Network File System (NFS) [7]. 2. Блочное хранилище - система хранения информации, которая напоминает иерархическую модель, но при этом файлы разбиваются на одинаковые по объему, непересекающиеся фрагменты или блоки [8].В этой системе блоками являются отдельные кластеры, способные вмещать большие объемы данных. Преимущества блочной системы заключаются в возможности разделения большого объема информации на блоки и обеспечении отдельного доступа к каждому из них [9]. Кроме того, блочные хранилища используют набор инструментов, которые обеспечивают высокую производительность системы: хост-адаптер шины разгружает процессор, осво-бождая его ресурсы для выполнения других задач [10]. Отсутствие сложных абстракций также способствует увеличению производительности и упрощает процесс масштабирования. Поэтому блочные системы хранения часто применяются в контексте гипервизоров и виртуализации, а также удобны для работы с реляционными базами данных [11]. К недостаткам блочной системы относятся сложность управления и необходимость узкой специализации для настройки, а также ограниченность объема хранения. Эти факторы также влияют на стоимость такой структуры, делая ее использование достаточно дорогим. Ограниченность метаданных[8] приводит к необходимости обработки вспомогательной информации на уровне приложений и баз данных. 3. Объектная система хранения данных - это тип хранилища, в котором данные различного формата и объема хранятся в виде объектов с метаданными, как правило, на облачном сервисе [12]. Оптимизация хранения метаданных достигается за счет соответствующей настройки. К основным преимуществам объектного хранилища относятся [13]: - легкая масштабируемость и практически неограниченный объем; - отсутствие громоздкой структуры; - высокая скорость поиска объектов; - отсутствие строгих ограничений по формату и предобработке файлов; - внутренние механизмы проверки целостности данных и другие функциональные возможности. Недостатками объектного хранилища являются сложности при работе из-за частого отсутствия интерфейса или необходимости установки дополнительного программного обеспечения в правильной конфигурации, а также более высокая задержка доступа к данным из-за значительного объема метаданных по сравнению с блочной структурой [14]. Таким образом, объектная структура хранения лучше всего подходит для больших объемов неструктурированных данных, в то время как хранение реляционных баз данных в таком формате представляется крайне сложным и нецелесообразным. 1. Методы Для реализации объектного доступа было разработано множество протоколов, среди которых наиболее популярными являются SOAP, S3 и OpenStack Swift [15]. Рассмотрим их особенности. SOAP (Simple Object Access Protocol) - это протокол обмена сообщениями, используемый для передачи структурированной информации между веб-службами. Данный протокол предоставляет стандартизированный формат для коммуникации, включая использование XML для инкапсуляции сообщений. Он разработан с целью обеспечения взаимодействия между приложениями различных платформ и языков программирования через интернет. Для передачи документов SOAP может использовать различные протоколы, такие как FTP, HTTP, SMTP и POP3[9]. S3 (Simple Storage Service) - протокол, предоставляющий механизмы управления доступом к данным, позволяя назначить различные разрешения для отдельных объектов. Кроме того, S3 поддерживает управление жизненным циклом данных [16]. Этот протокол был представлен компанией Amazon в 2006 г. API (интерфейс прикладного программирования) доступен для всех сторонних разработчиков [17]. Некоторые уникальные особенности протокола S3[10]: - элементы управления на уровне контейнера для управления версиями и истечения срока действия, которые применяются ко всем объектам в контейнере; - копирование объектов - позволяет делать копии объектов на стороне сервера. - анонимный доступ - возможность установить публичный доступ к объекту и обслуживать его по HTTP/HTTPS без аутентификации. OpenStack Swift. OpenStack - это бесплатная платформа облачных вычислений с открытым исходным кодом, совместная разработка NASA и облачного провайдера Rackspace [18]. Swift - компонент объектного хранилища в OpenStack, действующий по одноименному протоколу[11]. Протокол Swift управляется OpenStack Foundation, некоммерческой корпоративной организацией, созданной в сентябре 2012 г. для продвижения программного обеспечения OpenStack и его сообщества. К проекту присоединились более 500 компаний. Уникальная особенность Swift API: создание неразмерного объекта. Swift - единственный протокол, в котором можно использовать кодирование «Chunked» (фрагментация) для загрузки объекта, размер которого заранее неизвестен. S3 требует для этого несколько запросов [19]. Аутентификация в Swift осуществляется через отдельный механизм, создающий «токен», который может передаваться для аутентификации запросов. OpenStack Swift в ECS поддерживает две версии аутентификации. На сегодняшний день протоколы S3 от Amazon и Swift от OpenStack - две наиболее популярные версии протоколов для облачных объектных хранилищ [20]. Они представлены в различных продуктах, предоставляющих интерфейсы взаимодействия с облачными сервисами[12]. Для реализации сравнительной характеристики взаимодействия существующих хранилищ с имеющимися данными мы будем изучать протоколы S3 от Amazon и Swift от OpenStack для объектного типа хранения данных и предлагаемые в рамках этих протоколов продукты для облачного хранения данных. В качестве продуктов для сравнения выберем три предложения с открытым исходным кодом: Ceph [21], MinIO [22], Openstack Swift[13]. Ceph - комплексная система, поддерживает блочные, объектные и файловые данные. Основной отличительной чертой является высокая отказоустойчивость, которая хорошо зарекомендовала себя в применении для крупных инфраструктур [23]. MinIO - легкое, высокопроизводительное решение, оптимизировано под работу с данными через S3 API. Отлично подходит для контейнерных сред [24]. В отличие от других open-source решений MinIO изначально разработан как высокоскоростная, легковесная и масштабируемая система, оптимизированная именно для работы с большими объемами неструктурированных данных, что идеально соответствует природе медиаконтента, передаваемого в мессенджерах: изображений, видео-, аудиофайлов и документов [25]. OpenStack Swift - часть экосистемы OpenStack. Простая в развертывании, но менее производительна на мелких файлах. Лучше подходит для холодного хранения данных, то есть при редком использовании хранящихся файлов [26]. 2. Результаты и обсуждение 2.1. Результаты анализа Результаты сравнения после реализации представлены в таблице. Опираясь на результаты представленной таблицы сравнения, можно сделать некоторые ключевые выводы о описанных продуктах хранения данных. Для заявленной цели, поставленной в данной работе, наиболее приемлемым вариантом будет являться решение MinIO. Одним из главных преимуществ MinIO является его полная совместимость с API Amazon S3, который стал де-факто стандартом для объектного хранения. Это означает, что любое приложение, рассчитанное на работу с AWS S3, включая большинство современных платформ корпоративных коммуникаций, шлюзов безопасности и систем анализа данных, может быть интегрировано с MinIO без необходимости изменения кода. Такая совместимость значительно упрощает миграцию с облачных решений на локальную или гибридную инфраструктуру и позволяет организациям сохранять контроль над своими данными, соблюдая требования к их локализации и защите. Архитектура MinIO построена на принципах горизонтального масштабирования и отказоустойчивости. Система легко формирует кластеры из множества узлов, автоматически распределяя данные с использованием технологии erasure coding, которая обеспечивает защиту от потери информации даже при выходе из строя нескольких дисков или серверов одновременно. При этом MinIO демонстрирует одну из самых высоких скоростей чтения и записи среди open-source решений, что критично для мессенджеров, где пользователи ожидают мгновенной загрузки медиафайлов. По сравнению с такими альтернативами, как OpenStack Swift или Ceph, MinIO требует меньше ресурсов для запуска, проще в настройке и не нуждается в сложной инфраструктуре управления, такой как мониторинговые узлы или специальные базы метаданных. Его можно быстро развернуть в виде кон-тейнеров в Kubernetes, что делает его естественным выбором для организаций, использующих микросервисную архитектуру. Сравнительный анализ предложений хранилищ объектного типа Параметр Ceph MinIO OpenStack Swift 1 2 3 4 Протокол S3, Swift, RESTful S3 API (полная cовместимость) OpenStack Swift API, S3-совместимый доступ Производительность: · Скорость загрузки (большие файлы) · Скорость загрузки (мелкие объекты) · Скорость скачивания (большие файлы) · Скорость скачивания (мелкие объекты) · 250-300 МБ/с (без аппаратного ускорения) · 100-120 МБ/сек (ограничено оверхедом CRUSH и репликацией) · 280-320 МБ/с (с кэшированием) · 120-140 МБ/с · 300-400+ МБ/с (в распред. режиме) · 120-150 МБ/с · 350-450+ МБ/с · 160-200 МБ/с · 180-220 МБ/с · 70-100 МБ/с · 200-250 МБ/с · 80-110 МБ/с Максимальный объем хранимых данных Не ограничен (масштабируется го-ризонтально) Не ограничен (распределенное хранение) Не ограничен (масштабируется горизонтально) Возможность работы кластера с опциями отказоустойчивости Высокая отказоустойчивость: механизм репликации и авт. восстановление данных. Различные уровни отказоустойчивости Поддержка отказоустойчивости через репликацию данных и механизм распределенного хранения Обеспечивает отказоустойчивость через репликацию и возможные настройки различных уровней защиты данных Репликация Разные стратегии репликации (в т.ч. 3-way replication) и erasure coding для защиты данных Стандартная репликация, erasure coding для защиты данных Реализует репликацию объектов и поддерживает erasure coding для оптимизации хранения Работа в контейнере Поддерживает работу в контейнеризованных средах (в том числе Kubernetes) с помощью Rook и других интеграций Оптимизирован для работы в контейнерах, легко разворачивается в Kubernetes и Docker Может работать в контейнерах, требует больше усилий для интеграции по сравнению с MinIO Клиентские приложения и монтирование в популярные ОС CLI (radosgw), S3cmd, Rclone, FUSE-монтирование в Linux S3cmd, MinIO Client (mc), Rclone, FUSE, Web UI, поддержка S3 SDK для всех языков CLI, Swift CLI, Rclone, поддержка FUSE (через проекты сообщества) Трудозатраты разработчика при подготовке проекта (в раб. ч.) 20 2,5 12 И с т о ч н и к: выполнено С.А. Тастом. Comparative Analysis of Object Storage Solutions Parameter Ceph MinIO Open Stack Swift 1 2 3 4 Protocol S3, Swift, RESTful S3-compatible API OpenStack Swift API, S3-com-patible access Performance: · Upload speed (large files) · Upload speed (small objects) · Download speed (large files) · Download speed (small objects) · 250-300 MB/s (without hardware acceleration) · 100-120 MB/s (limited by CRUSH and replication overhead) · 280-320 MB/s (with caching) · 120-140 MB/s · 300-400+ MB/s (in distributed mode) · 120-150 MB/s · 350-450+ MB/s · 160-200 MB/s · 180-220 MB/s · 70-100 MB/s · 200-250 MB/s · 80-110 MB/s Maximum storage capacity Not limited (horizontally scalable) Not limited (distributed storage) Not limited (horizontally scalable) Cluster fault-tolerance capabilities High fault tolerance: replication mechanism and automatic data recovery; various levels of fault tolerance Fault-tolerance support through data replication and distributed storage mechanisms Provides fault tolerance through replication and the ability to configure different levels of data pro-tection Replication Various replication strategies, including 3-way replication, and erasure coding for data protection Standard replication and erasure coding for data protection Implements object replication and supports erasure coding for storage optimization Containerized deployment Supports operation in containerized environments, including Kubernetes, using Rook and other integrations Optimized for containerized dep-loyment; easily deployed in Kuber-netes and Docker Can run in containers, but re-quires more integration effort compared with MinIO Client applications and mounting in popular OS CLI (radosgw), s3cmd, Rclone, FUSE mounting in Linux S3cmd, MinIO Client (mc), Rclone, FUSE, Web UI, S3 SDK support for major programming languages CLI, Swift CLI, Rclone, FUSE sup-port through community projects Developer effort for project preparation, person-hours 20 2.5 12 S o u r c e: by S.A. Tast. Кроме того, MinIO активно развивается сообществом и компанией-разработчиком, регулярно получает обновления и поддерживает современные функции, такие как уведомления о контейнерах, управление жизненным циклом, встроенная антивирусная проверка через интеграцию с ClamAV и поддержка машинного обучения через MinIO ML Gateway. Это позволяет не только хранить медиаданные, но и организовать их автоматическую обработку - например, анализ содержимого, тегирование на основе метаданных или удаление устаревших файлов согласно политикам хранения. 2.2. Обсуждение результатов Проведенное исследование направлено на сравнительный анализ современных систем хранения данных с точки зрения их применимости в качестве хранилища медиафайлов для систем обмена сообщениями, с акцентом на требования к производительности, масштабируемости, отказоустойчивости и простоте эксплуатации. На основе анализа функциональных характеристик и архитектурных особенностей различных решений авторами было определено, что объектно-ориентированное хранилище, в частности MinIO, в наибольшей степени удовлетворяет совокупности предъявляемых требований и может рассматриваться как приоритетный вариант для внедрения в инфраструктуру корпоративных и отраслевых мессенджеров. Ключевой результат работы заключается в обосновании выбора MinIO как оптимального решения, которое обеспечивает необходимую производительность, а также бесшовную интеграцию с широким спектром существующих приложений и сервисов без модификации их кода. Такая совместимость снижает порог внедрения для организаций, уже использующих облачные платформы, и открывает возможности для построения гибридных архитектур, в которых локальное объектное хранилище интегрируется с публичными облаками. В отличие от более тяжелых по инфраструктурным требованиям решений, таких как OpenStack Swift или Ceph, MinIO демонстрирует относительно низкую ресурсозатратность и упрощенную конфигурацию, что делает его особенно привлекательным для микросервисных систем. Научная новизна работы для отечественной и зарубежной науки проявляется, прежде всего, в комплексной оценке MinIO как элемента инфраструктуры систем обмена сообщениями с учетом специфики их нагрузочного профиля. Если в существующих исследованиях объектные хранилища преимущественно рассматриваются в контексте высокопроизводительных вычислений, аналитики больших данных или классических облачных платформ, то в данной работе акцент сделан на сценариях, где критичны одновременно высокая скорость работы с медиафайлами, простота масштабирования и соответствие требованиям по локализации и защите данных. Представляется целесообразным проведение экспериментальных нагрузочных испытаний MinIO в реальных (или близких к реальным) условиях эксплуатации мессенджеров с различными профилями трафика (корпоративный, образовательный, массовый публичный сервис) для количественной оценки показателей задержек, пропускной способности и устойчивости к отказам. Отдельным перспективным направлением может стать разработка методик и рекомендаций по миграции существующих систем хранения, основанных на файловой или блочной модели к объектной архитектуре с учетом организационных, правовых и эксплуатационных ограничений конкретных отраслей. Авторы видят также возможности для даль-нейших исследований в области совмещения функций хранения и интеллектуальной обработки данных на уровне инфраструктуры. Также для изучения интересной представляется сфера различных возможностей, которые не включены в текущую конфигурацию хранилища: логирование операций с данными, ограниченные возможности условий фильтрации, отсутствие автоматического отслеживания доступа и прочее. Эти особенности могут быть необходимы для отдельных областей применения хранилища, поэтому необходим их тщательный анализ. Заключение Используя представленные результаты, можно сделать вывод о несомненных преимуществах объектного типа хранилища для решения поставленной задачи - безопасного и эффективного хранения мультимедийных данных в системах корпоративных коммуникаций. При анализе конкретных протоколов и решений с открытым исходным кодом были определены ключевые характеристики, влияющие на выбор заказчика. Среди хранилищ Ceph, MinIO и OpenStack Swift имеются различия, которые могут быть преимуществами и недостатками, в зависимости от особенностей файлов, инфраструктуры и прочих параметров. Выбранное нами решение - MinIO - сочетает в себе производительность, безопасность, масштабируемость и простоту внедрения, что делает его наиболее подходящим для хранения мультимедийных данных в системах корпоративных коммуникаций.

Об авторах

Сергей Артурович Таст

Московский технический университет связи и информатики

Автор, ответственный за переписку.
Email: s.a.tast@edu.mtuci.ru
ORCID iD: 0009-0004-6244-654X

магистрант Центра заочного обучения по программам магистратуры

Российская Федерация, г. Москва, ул. Авиамоторная, д. 8А

Марина Сергеевна Мосева

Московский технический университет связи и информатики

Email: m.s.moseva@mtuci.ru
ORCID iD: 0000-0002-9778-124X
SPIN-код: 1313-0436

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

Российская Федерация, г. Москва, ул. Авиамоторная, д. 8А

Список литературы

Дополнительные файлы