Альтернативные подходы к системам хранения данных: миграция после ухода западных вендоров
Предпосылки трансформации
До 2022 года российские ЦОДы в основном полагались на традиционные системы хранения данных западных производителей, интегрированные с популярными платформами виртуализации. VMFS (VMware), NTFS+ CSV (Microsoft), GPFS (IBM) и аналогичные кластерные файловые системы обеспечивали надежное управление общим доступом к дисковому пространству. После ухода западных производителей с рынка российские компании столкнулись с необходимостью переосмыслить архитектуры своих инфраструктур.
Отечественные разработчики оперативно предложили несколько типов решений. Во-первых, традиционные системы хранения данных (СХД) собственной разработки, которые обеспечивали относительную простоту внедрения: достаточно было закупить специализированное оборудование и оно было готово к использованию с предустановленным программным обеспечением. Во-вторых, начали развиваться гиперконвергентные архитектуры, которые интегрируют хранилище, вычисления и сетевые функции на одних и тех же серверах. Однако при попытке интеграции этих решений с растущей вычислительной инфраструктурой и стремлении к масштабированию появлялись различные сложности.
Проблемы интеграции и миграции
Традиционная СХД, отличаясь своей простотой первого развертывания, менее гибка при необходимости масштабирования в крупных ЦОДах с распределенной архитектурой. Проблема усугубляется отсутствием подходящих кластерных файловых систем корпоративного уровня, которые бы обеспечивали надежное управление общим доступом к блочному хранилищу в масштабе предприятия, особенно после ухода западных вендоров.
На этом фоне российские компании начали экспериментировать с различными подходами. Некоторые стали использовать открытые решения — GFS2, OCFS2, Ceph и GlusterFS. Однако на практике каждое из этих решений имеет существенные ограничения.
GFS2 требует развертывания distributed lock manager (DLM) через corosync и специальных сервисов управления кластером. Эта система поддерживает кластеры до 32 узлов, но производительность и надежность могут деградировать при расширении. OCFS2, разработанная Oracle, проще в эксплуатации, но также имеет ограничения по масштабируемости при добавлении новых узлов.
LVM без кластеризации вообще не подходит для shared storage-сценариев — использование LVM без cluster-aware-функций создает риск data corruption при одновременном доступе с нескольких хостов. Даже CLVM требует single-writer approach и не поддерживает thin provisioning для shared storage. Несмотря на риск, LVM продолжают широко использовать, где в некоторых случаях применяют настройки блокировщика sanlock.
Компании, которые попытались внедрить распределенные системы хранения вроде Ceph, столкнулись с серьезными вызовами. Ceph требует минимум 10 Gbps сетевой пропускной способности в базовом конфигурировании и 40 Gbps для production environment. Требуются квалифицированные специалисты для первоначальной настройки и постоянного мониторинга. Кроме того, Ceph требует значительных ресурсов CPU и памяти. GlusterFS страдает от плохой производительности метаданных и не масштабируется эффективно при значительном увеличении количества узлов, особенно из-за использования FUSE на клиентской стороне. Оба решения имеют ограничения при использовании в критических рабочих нагрузках.
Гиперконвергентные или дезагрегированные архитектуры как альтернатива
Параллельно с развитием традиционных СХД и экспериментами с открытыми системами на рынке стали развиваться гиперконвергентные и дизагрегированные архитектуры. Такой подход объединяет вычисления, хранение и сетевые функции на одних и тех же серверах, потенциально решая проблемы, возникающие при использовании отдельных СХД или сложных открытых распределенных систем, а дизагрегированный подход позволяет в большом количестве серверов определять роли, какие-то сервера с SDS, а какие-то как клиенты только с вычислениями.
Гиперконвергентный сценарий на примере продуктов Росплатформы
Конфигурация состоит из минимального набора трех серверов, где на каждом одинаковое количество дисков (SSD или HDD), сетевых адаптеров и процессоров, поверх которых установлен дистрибутив Росплатформы, включающий в себя Р-виртуализацию (гипервизор) и Р-Хранилище(SDS). В виртуальных средах (виртуальные машины или контейнеры) работают различные гостевые отечественные операционные системы, а также системы управления антивирусами такие как «Касперский», системы резервного копирования такие как Rubackup, системы балансировки нагрузки такие как Octopus и т.д.
Основная идея гиперконвергенции состоит в том, что хранилище данных работает на тех же серверах, на которых выполняются виртуальные машины и другие рабочие нагрузки. Это исключает необходимость в отдельных системах хранения и сложных кластерных файловых системах. Вместо этого используется сетевая синхронизация блоков данных и их копий, что обеспечивает надежность без требования к отдельной инфраструктуре. Совместную работу гипервизора и сервисов хранения обеспечивает отдельный компонент, который разделяет и изолирует ресурсы, а сервисы хранения запускаются как независимые (атомарные) экземпляры с заданными лимитами CPU и памяти и могут масштабироваться при увеличении доступных ресурсов или расширении кластера.
Масштабирование происходит горизонтально — путем добавления новых серверов с дисками, которые интегрируются в распределенное хранилище. Для начального развертывания требуется минимальный набор: стоечные серверы с встроенными дисками в режиме JBOD или passthrough, два Ethernet-коммутатора для резервирования сетевых путей и соответствующее программное обеспечение для управления.
Такая архитектура хорошо комбинируется с сервисами объектного хранения на базе протокола S3, который является де-факто стандартом для облачных хранилищ и больших данных. Минимальный кластер из трех серверов может расширяться по мере необходимости, с поддержкой хранения объемов данных вплоть до нескольких десятков петабайт в сыром объеме (raw capacity).
Сценарий объектного хранения по протоколу s3 на примере продукта Р-Хранилище (SDS)
Кроме трех серверов добавляются внешние балансировщики распределения нагрузки по серверам от клиентов объектного хранения, таких как: «1C» или PostgreSQLPro для хранения вложенных документов на s3, для хранения бэкпов от системы резервного копирования RuBackup, для хранения видео-файлов от камер, для хранения снимков или медицинских томографических снимков или видео, для хранения файлов для искусственного интеллекта под RAG(Retrieval-Augmented Generation), для хранения объектов под контейнеры на основе Kubernetes и т.д.
Сценарий экспорта iSCSI на примере Р-Хранилища
Так же как и в традиционной архитектуре СХД, можно экспортировать от SDS хранилище по протоколу iSCSI для внешних систем, как для единичных систем (standalone), так и для множества серверов.
Практические примеры внедрения
Примеры использования гиперконвергентных подходов в России указывают на их жизнеспособность в производственных сценариях.
Один из опытов Россельхозбанка демонстрирует долгосрочную стабильность такой архитектуры. Компания развернула гиперконвергентное решение, построенное на платформе Р-виртуализации от Росплатформы с интегрированным хранилищем Р-Хранилище, на трех серверах с относительно скромными характеристиками (по одному 12-ядерному процессору, HDD и SSD для кэша). Система обслуживает производственную нагрузку из 8 виртуальных серверов и тестовый сегмент с 5-8 серверами уже более трех лет непрерывно. Процесс миграции виртуальных машин между хостами для балансировки нагрузки происходит без перерыва в обслуживании, что критически важно для банковских операций. Этот пример показывает, что проприетарная гиперконвергентная архитектура с поддержкой вендора может обеспечить требуемую надежность для критических систем. Еще один пример - Trinity провела техническое тестирование гиперконвергентного решения на своих серверах.
По результатам выявились вопросы, связанные с требованиями к сетевой инфраструктуре, — необходимостью выделенных каналов с высокой пропускной способностью для синхронной репликации блоков данных. Обмен опытом между интегратором и производителем позволил уточнить конфигурацию и выявить особенности развертывания, которые были документированы для будущих внедрений. Этот пример демонстрирует как преимущества поддержки вендора, так и важность надлежащей подготовки сетевой инфраструктуры.
Публично доступные примеры внедрения показывают, что гиперконвергентные решения способны работать в производственной среде, однако требуют правильной сетевой инфраструктуры и понимания специфики развертывания.
Сравнение подходов и их особенности
При выборе архитектуры следует взвесить несколько ключевых факторов.
Традиционная СХД остается практичным выбором для организаций, где приоритет отдается простоте первого развертывания и не требуется значительного расширения инфраструктуры. Предустановленное программное обеспечение и готовый к использованию контроллер минимизируют время внедрения. Однако при необходимости интеграции с растущей вычислительной инфраструктурой в крупных ЦОДах этот подход может потребовать использования LVM с блокировкой или других подручных решений, которые не обеспечивают требуемую надежность или производительность.
Открытые распределенные системы (Ceph, GlusterFS) привлекательны с точки зрения независимости от вендора и отсутствия лицензионных затрат. Однако они требуют значительных специализированных знаний для развертывания и управления, имеют повышенные требования к аппаратным ресурсам и сетевой инфраструктуре, а их надежность и производительность в критических приложениях ниже, чем у проприетарных решений. Кроме того, при возникновении проблем может быть затруднена техническая поддержка.
Проприетарные гиперконвергентные системы требуют более тщательного планирования сетевой инфраструктуры (выделенные каналы для репликации, высокая пропускная способность, правильная конфигурация MTU и агрегирование) и более глубокого понимания операционной модели. Вместе с тем они обеспечивают большую гибкость при масштабировании и позволяют эффективнее эксплуатировать аппаратные ресурсы, так как вычисления и хранение распределены на одних и тех же серверах. Такие решения (например, «Р-Хранилище» от Росплатформы) обладают сертификацией ФСТЭК, что актуально для критичных систем в России, и предусматривают оперативную техническую поддержку от вендора.
Текущее состояние рынка
Рынок отечественных решений для хранения данных включает несколько типов игроков. Традиционные СХД предлагают компании YADRO, «Аэродиск», «Гравитон» и другие. В области гиперконвергентных решений с интегрированным хранилищем активна Росплатформа с продуктом Р-Хранилище, которое может работать совместно с гипервизором Р-виртуализации и позволяет создавать растянутые кластеры между ЦОДами и настраивать гео-репликацию для S3.
Недостаток квалифицированных специалистов для развертывания и обслуживания сложных систем хранения остается вызовом независимо от выбранного подхода. Миграция с западных решений происходит медленнее, чем в первые годы после ухода производителей, так как многие организации все еще используют старые системы и только постепенно переходят на отечественные платформы.
В этих условиях компании ищут решения, которые обеспечивают баланс между надежностью, гибкостью и управляемостью. Для задач, требующих высокой доступности и критичности, гиперконвергентные архитектуры с проприетарным управлением (такие как решение Росплатформы) предлагают один из перспективных вариантов с гарантией поддержки и документированным опытом внедрения. Для организаций, стремящихся к независимости от вендора, открытые решения остаются вариантом, требующим, однако, значительных инвестиций в квалификацию персонала и инфраструктуру.
Гибридные подходы и переходные стратегии
На практике многие организации не отказываются полностью от традиционных СХД, а используют гибридный подход. Традиционные СХД могут оставаться для хранения резервных копий или для работы с определенными рабочими нагрузками, в то время как основная инфраструктура постепенно переводится на более современные архитектуры. Кроме того, гиперконвергентное решение может быть интегрировано с существующими СХД для использования в специфических сценариях, где каждый компонент выполняет свою роль.
Подобная гибридность позволяет организациям снизить риск при переходе, проверить новое решение в определенном сегменте перед полным развертыванием и постепенно наращивать компетенции. Компании получают время для обучения персонала, поэтапной миграции приложений и постепенного увеличения доли новой архитектуры в общей инфраструктуре.
Заключение
Рынок отечественных решений для хранения данных находится в процессе становления, предлагая несколько основных подходов, каждый со своими преимуществами и требованиями. Традиционные СХД остаются простым и надежным выбором для базовых сценариев. Открытые решения (Ceph, GlusterFS) обеспечивают независимость от вендора, но требуют значительных инвестиций в подготовку специалистов и инфраструктуру. Гиперконвергентные архитектуры, разработанные отечественными компаниями, предлагают баланс между управляемостью и гибкостью для критичных систем, предусматривая профессиональную поддержку и сертификацию.
Выбор оптимального решения зависит от конкретных требований организации, размера инфраструктуры, требуемых показателей надежности, доступного опыта персонала и приоритизации между независимостью от вендора и наличием профессиональной поддержки.
Постепенная диверсификация предложений на рынке и рост количества примеров успешного внедрения различных подходов указывают на то, что российский сектор информационных технологий адаптируется к новым условиям и развивает собственные компетенции в области инфраструктурного ПО.