Хабр, привет! На связи Антон Ботвинников, директор по продукту SDS TROK.
S3 — модное слово. Его вставляют в питчи, роадмапы и презентации так часто, что даже человек, который не до конца понимает технологию, умудряется звучать убедительно, называя это вслух. Мы тоже решили быть в теме и в новом релизе SDS TROK добавили поддержку S3. Очень просили заказчики. Хочу рассказать, что получилось.
Короткое ревью для тех, у кого нет времени на всю статью: в SDS TROK появилось объектное хранилище с S3-протоколом. Под капотом — надежный S3-шлюз поверх реплицированного блочного устройства. Три реплики, автоматическое переключение при отказе узла, без ручного вмешательства. Мы движемся плавно и мелодично по roadmap.
Что такое S3, если по-честному
Кто в теме S3, можете этот блок пропустить) Он для выравнивания контекста.
Если объяснять на пальцах, у хранилища есть три способа доступа: блочный, файловый и объектный.
При блочном доступе тебе выделяют, условно, пустой лист, как бы подключенный не проводами, а по сети. Файловую систему на нем создаешь сам, точно так же, как на жестком диске у компуктера :) Доступ к файлам через NFS или SMB работает похоже. Это тот же, грубо говоря, диск, но поверх него уже есть созданная файловая система, доступная по сети. Заходишь как пользователь, и у тебя есть классические POSIX-права: читать, писать, исполнять.
И блочный, и файловый доступ почти всегда живут в изолированной сети. Подключился к блочному устройству, получил доступ ко всем данным без разбора + защиту приходится строить поверх самому. Поэтому внутреннее файловое хранилище никто не публикует в интернете напрямую (никто в здравом уме).
S3 устроен иначе. Подключаешься по обычному HTTPS, как к сайту: один порт, TLS, сертификаты. Вместо логина и пароля здесь ключи доступа, каждый запрос подписывается по спецификации. Внутри бакетов лежат объекты. Они очень похожи на файлы, но по протоколу это разные сущности. У бакета, если не наложены квоты, вообще нет ограничения объема.
Пользоваться этим можно через веб-интерфейс: кинул файл мышкой и увидел его в бакете. А можно из кода, вызовом API с командой вроде PutObject, куда передаешь имя бакета, ключ доступа и путь к файлу. Чтобы не реализовывать вручную подпись каждого запроса, берешь готовый SDK под свой язык, например Java или Go, и работаешь с S3 как с обычной библиотекой.
За счет этого S3 стал стандартом не только для веб-приложений, но и для софта в целом. AI-пайплайн тянет через него исходные данные и вес модели. Система видеонаблюдения режет поток с камеры на файлы по 3–5 минут и складывает их в бакет по имени: сразу понятно, с какой камеры и когда снято. Бэкапы баз данных, статические файлы сайта — тот же протокол. Под каждый сценарий не нужно «городить» отдельный прямой доступ к внутренней сети, достаточно HTTPS и ключей.
Например, как может использовать S3 медтех-платформа с сетью партнерских лабораторий. Пациент сдает анализы, результат приходит в приложение в виде PDF, дальше с ним уже работает ИИ, от расшифровки до подсказок по телемедицине. Нагрузка на такую систему неровная. Перед 1 сентября, когда все ведут детей на медосмотры, трафик и объем данных резко подскакивают, поэтому приложение не может себе позволить упасть именно в этот момент. PDF с анализами прекрасно ложатся в бакеты, а ИИ, который их разбирает, почти всегда написан на Python и одинаково легко работает что с локальным диском, что с S3. Красата)
Почему для SDS TROK это было архитектурно нетривиально
Amazon придумал S3 и с тех пор остается эталоном. Полная спецификация, бесконечная география хранения, любой уровень скорости и надежности за N-бюджеты. Сама спецификация S3 API от AWS, кстати, тянет примерно на две тысячи страниц, это чтение на пару отпусков вперед, не меньше. Все остальные, кто делает S3-совместимые хранилища, по сути пытаются повторить идею Amazon поверх собственного слоя хранения данных. Ceph и MinIO, два самых известных open source аналога, устроены похоже друг на друга.
Основные минусы, с которым все сталкиваются
Ceph — штука мощная, но администрировать ее тяжело. Под капотом лежит массивный слой метаданных, без отдельной квалифицированной команды не обойтись, иначе на ребалансировке производительность просядет.
Адекватная лицензия на MinIO стоит денег, и немалых — от $96 000 в год за 1 ТБ. От бесплатной с 2024 года толку не очень много, а «корячиться» с покупкой платного западного функционала в России… ну вы поняли.
Основной минус, который мы видим дополнительно
Данные режутся на блоки и «размазываются» по всем нодам хранения — слой метаданных сам решает, что где лежит. Фактически ты не знаешь и не контролируешь, на каком физическом узле оказался конкретный кусок твоих данных. А значит, не можешь предсказать ни производительность, ни поведение хранилища при сбое конкретного диска.
Поэтому SDS TROK устроен иначе
Принципиально. В основе у нас data locality. Мы решили строить от своей сильной стороны, от блочной зеркальной репликации. Взяли блочный уровень SDS TROK на технологии DRBD с локальной файловой системой. У него три реплики на разных хостах, одна из них Primary. Туда же, где в конкретный момент находится Primary-реплика, поднимается S3 API Gateway. Другими словами, мы не «размазываем» данные через дополнительный слой метаданных. Так надежнее.
Без нюансов не обошлось, конечно же. У S3-интерфейса, каким его все привыкли видеть, нет ограничения по размеру. Бакет без квот бесконечен, но чтобы дать эту бесконечность, нужен нижележащий слой хранения, который тоже способен растягиваться без границ, как у Ceph или у самого Amazon. У архитектуры data locality такого слоя нет: блочное устройство конечно. Поэтому просто поднять S3 gateway поверх файловой системы и получить неограниченный объем не получится.
Но мы нашли выход:
Сохраняя подход data locality, мы решили, что каждый S3 gateway будет хранить часть объектов S3 хранилища.
Количество S3 gateway и «приколоченных» к ним блочных хранилищ не ограничено.
Поскольку запрос клиента может прийти на любой из S3 gateway, то надо сделать так, чтобы любой S3 gateway мог отдать объект, даже если он лежит на соседнем шлюзе. Мы реализовали эту логику, и у нас получилось сделать «резиновое» объектное хранилище поверх ограниченных по объему реплицированных блочных хранилищ.
Кому уже подходит SDS TROK с S3
Самый частый сценарий на практике простой. У заказчика уже стоит MinIO, open source, которое он сам разворачивает и сам чинит, когда что-то ломается. В какой-то момент появляется задача заменить его на продукт из реестра отечественного ПО, с поддержкой от вендора, а не только от собственного дежурного администратора. Здесь SDS TROK и выходит на сцену.
Просто песня, а не роадмап
У нас есть план, и мы его придерживаемся. На S3 не останавливаемся. До конца 2026 года планируем реализовать поддержку геораспределенного кластера, а также синхронную и асинхронную репликацию данных между кластерами — это позволит заказчикам строить катастрофоустойчивые конфигурации на нескольких площадках. Параллельно продукт проходит сертификацию по требованиям ФСТЭК России. Ну сами понимаете, без этого никуда.
А что про облака? Вопрос логичный.
На самом деле, в релизе платформы Astra Cloud 2.1 уже доступны блочный и файловый уровни хранения данных внутри единого облачного контура для виртуальных машин, баз данных, почтовых сервисов и резервных копий.
А вот S3-часть туда пока не дошла, и мы не хотим спешить с этим шагом, чтобы не наделать ошибок. Двигаемся постепенно.
По факту имеем
S3 в SDS TROK — не попытка повторить Amazon или Ceph в миниатюре и не гонка за модным словом из заголовка. Могу с уверенностью сказать, что наша система хранения данных уже сейчас является рабочим инструментом для решения конкретных задач. Но главное, что это надежно. Мое любимое слово в этой жизни, потому что так надежнее :)
Если у вас есть вопросы, пишите в комментариях. Готовы к приему заявок)
