Кейс: собственное S3-хранилище на Debian и плате Supermicro
Папка по сети удобна людям, а приложению часто нужен другой способ работы: загрузить объект по API, получить его по ключу, выдать ограниченный доступ и сохранить версию. В этом кейсе разбираем собственное S3-хранилище на Debian и платформе Supermicro X10SDV. Цель — понять, как небольшой команде совместить файловые ресурсы и объектный сервис, не спутать RAID с резервной копией и не превратить локальный сервер в неподдерживаемый набор случайных программ.
Практическая отправная точка — проект ServerFlow 2025 года: семейство X10SDV с двумя 10GbE, 64 ГБ ECC, четыре диска, mdadm RAID5, ext4, Samba и MinIO. Дальнейшие расчёты и правила приёмки — наш инженерный разбор, а не дополнительные результаты испытаний исходного сервера.
Что важно сегодня: архитектура Debian + файловая система + S3-сервис остаётся понятной, но прежняя MinIO Community к октябрю 2026 года уже не является сопровождаемым продуктом. Повторять старую установку без выбора поддерживаемой реализации, версии и лицензии не следует.
Когда общей папки SMB недостаточно
У разработчика возникает обычная задача: приложение принимает вложения, складывает изображения, выдаёт ссылки и удаляет временные результаты по сроку хранения. Привязывать всё это к сетевому диску рабочего компьютера неудобно. Меняются учётные записи, имена папок, права и пути монтирования. S3 API предоставляет другую модель: bucket, ключ объекта, метаданные, запросы чтения и записи.
При этом S3 — интерфейс, а не обещание облачной отказоустойчивости. Один локальный сервер с S3 API остаётся одним локальным сервером. Отказ его платы, системы питания или файловой системы может остановить и SMB, и объектный доступ одновременно. Для лаборатории это приемлемо, если простой учтён. Для сервиса с обязательствами перед клиентами может понадобиться иная архитектура.
Другая распространённая причина собственного сервиса — тестирование приложений перед облачным развёртыванием. Локальный endpoint позволяет проверять загрузку, multipart, права и жизненный цикл объектов. Но совместимость проверяют по используемым операциям: надпись S3-compatible сама по себе не доказывает полную идентичность всех функций конкретному облаку.
Как устроена исходная конфигурация
| Слой | В кейсе | Ответственность |
|---|---|---|
| Аппаратная платформа | Supermicro X10SDV, 64 ГБ ECC, два 10GbE | CPU, память, сеть и подключение дисков |
| Операционная система | Debian | Драйверы, службы, обновления, пользователи |
| Дисковая избыточность | mdadm RAID5 на четырёх дисках | Продолжение работы при допустимом отказе диска |
| Файловая система | ext4 | Размещение файлов и каталогов |
| Файловый доступ | Samba | Сетевые папки SMB |
| Объектный доступ | MinIO в исторической сборке | Обслуживание S3-запросов |
| Контроль состояния | SMART и уведомления | Раннее обнаружение проблем, а не автоматическая гарантия сохранности |
Сильная сторона подхода — видимые границы ответственности. Проблему сети не лечат заменой файловой системы, а ошибку ключей приложения — перестройкой массива. Обратная сторона: администратор отвечает за согласованность всех слоёв, порядок запуска, обновления и восстановление.
Для аппаратного подбора полезно начать с материнских плат Supermicro. Например, X10SDV-4C-TLN2F — конкретная компактная модель серии с ECC и двумя 10GbE, но её выбор для нового проекта нужно оформить отдельным составом оборудования. Совпадение семейства не делает её автоматически платой из исходного S3-кейса.
Можно ли обращаться к одним данным через SMB и S3
Нужно различать общую дисковую систему и общее внутреннее содержимое сервиса. SMB-каталог с обычными документами можно разместить на том же массиве, что и данные объектного хранилища. Но нельзя давать пользователям прямую файловую запись во внутренний каталог S3-реализации: там могут находиться служебные метаданные, версии и фрагменты объектов.
Практическая схема — отдельные каталоги данных и отдельные владельцы служб. Обмен происходит через API, экспорт или приложение, которое понимает обе стороны. Например, сотрудник кладёт исходники в SMB, сервис обработки читает их и загружает готовые превью в S3. Пользователь не редактирует скрытую структуру объектного движка через Проводник.
У файлового доступа и объектного API различается семантика. Переименование файла в привычной папке и перенос объекта между ключами могут иметь разную стоимость и поведение. Приложение следует тестировать на оборванной загрузке, повторном запросе и одновременном изменении одного ключа, а не только на успешной передаче маленького файла.
Что изменилось у MinIO и как выбирать реализацию S3
В исходном проекте MinIO решала задачу локального S3 API. После прекращения сопровождения прежней открытой Community Edition этот выбор нельзя механически переносить в новую производственную систему. Старый работающий бинарный файл не получает поддержку только потому, что служба запускается после перезагрузки.
У MinIO есть развиваемая линейка AIStor, включая вариант для одного узла с отдельными условиями лицензирования. Выбор редакции, получение обновлений и допустимое использование нужно подтвердить до развёртывания. Различия касаются не названия исполняемого файла, а жизненного цикла, функций и ответственности за устранение уязвимостей.
При сравнении с другими S3-реализациями составляют короткую матрицу обязательных операций: multipart upload, Range GET, версии объектов, политики жизненного цикла, presigned URL, Object Lock при необходимости, аудит и интеграция с резервным копированием. Если нужна только тестовая среда на 100 ГБ, требования будут одними; для юридически значимого архива на десятки терабайт — другими.
Практический результат выбора — зафиксированные версия, способ обновления, лицензия, источник пакета и процедура отката. Команда установки «скачать последний файл и запустить от root» не заменяет эту работу. В статье намеренно нет команды создания массива на буквенных именах дисков: одна ошибка в таком примере может уничтожить данные на другом накопителе.
Как рассчитать ёмкость с версиями и резервом
В исходной сборке четыре диска, но их единый подтверждённый номинал для расчёта здесь не используется. Возьмём отдельный проектный пример: четыре одинаковых HDD по 8 ТБ. RAID5 даст около 24 ТБ номинально до файловой системы и служебных затрат. Это не характеристика первоначального стенда, а арифметическая модель для планирования.
| Статья бюджета | Расчётный объём | Почему он нужен |
|---|---|---|
| Сырая сумма 4 × 8 ТБ | 32 ТБ | Не равна доступному объёму |
| После одной дисковой избыточности | Около 24 ТБ | До ext4 и данных объектного движка |
| Политика свободного резерва 20% | 4,8 ТБ | Запас для роста и служебных операций |
| Плановая занятость | Не более 19,2 ТБ в этой модели | Включает текущие объекты и сохранённые версии |
| Текущий полезный набор | 12 ТБ | Результаты работы приложений |
| Версии и временные данные | Проектный лимит 4 ТБ | Ограничивается политиками и контролем |
| Остаток до планового лимита | 3,2 ТБ | Не заменяет отдельную резервную копию |
Версионирование меняет характер роста. Если приложение ежедневно заменяет 200 ГБ объектов и старые версии сохраняются месяц, грубая верхняя оценка дополнительного объёма — 6 ТБ. Реальный расход зависит от реализации и паттерна изменений, но считать только размер актуальных ключей явно недостаточно. Незавершённые multipart-загрузки тоже должны иметь контролируемый срок хранения.
Для большого числа мелких объектов важна не только сумма байтов. Миллионы ключей создают нагрузку на метаданные и листинг. Отдельно испытывают запросы LIST, небольшие GET/PUT и параллельность. Красивый результат записи одного файла на 20 ГБ не отвечает на вопрос, как сервис работает с десятью миллионами объектов по 64 КБ.
Достаточно ли RAID5 для такого сервера
RAID5 в исходном кейсе — факт выбранной конфигурации, а не универсальная рекомендация. При отказе одного диска система лишается единственного уровня дисковой избыточности до завершения восстановления. На больших HDD это длительный период повышенной уязвимости. Решение зависит от стоимости простоя, размера массива, доступности резервного носителя и срока восстановления.
Для нового проекта можно сравнить зеркала, двойной паритет или другую топологию. Смысл сравнения — не выиграть спор о названиях RAID, а получить требуемую доступность и понятный регламент. Подробная настройка контроллеров и уровней защиты вынесена в руководство по RAID Supermicro; этот кейс сосредоточен на приложениях поверх хранения.
Задание RPO и RTO важнее самого факта наличия массива. Если проект допускает восстановление тестовых вложений за сутки, один узел с проверенной копией может подходить. Если клиентский портал должен оставаться доступным при выходе сервера из строя, нужно оценивать несколько независимых узлов и поддерживаемую распределённую архитектуру.
Где окажется узкое место: CPU, HDD или сеть
Путь запроса проходит через TLS, сервис S3, файловую систему, RAID и диски. Для крупных последовательных объектов может ограничивать пропускная способность. Для мелких — задержка и число операций. Для множества HTTPS-соединений — CPU, управление соединениями и обработка метаданных. Два порта 10GbE не доказывают, что весь тракт выдержит 20 Гбит/с полезных данных.
Удобно оценить порядок величин. 100 запросов в секунду по 1 МБ означают примерно 100 МБ/с полезного потока; 1000 запросов по 64 КБ — около 64 МБ/с, но в десять раз больше отдельных операций. Один и тот же показатель мегабайт в секунду скрывает совершенно разную работу CPU и дисков.
При проверке записывают p50, p95 и p99 задержки, частоту ошибок, число одновременных клиентов, размер объектов и долю чтения/записи. Среднее время ответа не показывает редкие многосекундные остановки. Тест длится достаточно долго, чтобы закончился эффект RAM-кэша и проявилась реальная скорость носителей.
Как разделить доступ приложения, людей и администратора
Одна пара ключей администратора для всех приложений создаёт общий риск. Каждому сервису выделяют минимально необходимый доступ: конкретный bucket или префикс, нужные операции и срок действия там, где он поддерживается. Чтение публичного каталога изображений и право удаления резервных копий не должны принадлежать одной технической учётной записи.
Секреты хранят в предусмотренном для приложения механизме, не в репозитории и не в открытом журнале диагностики. Presigned URL — временная возможность выполнить конкретный запрос, поэтому его тоже нельзя считать безусловно безопасным для бессрочного распространения. Проверяются срок, операция, подпись и доступ из внешней сети.
Административная консоль, SSH и IPMI не нужны обычным пользователям S3. Их размещают в сети управления с ограниченным доступом. TLS нужен и внутри локальной сети, если по ней передаются ключи и чувствительные данные; доверие к сертификату настраивают на клиентах, а не выключают проверку ради успешного теста.
Почему порядок запуска служб влияет на сохранность
Опасная ситуация: RAID или файловая система не смонтировались, а S3-служба запустилась и создала новый каталог данных на системном SSD. Сервис отвечает, часть объектов записывается в другое место, затем диск ОС заполняется. Простая проверка «порт открыт» такую ошибку не обнаруживает.
Зависимости запуска должны требовать наличия нужного mount point и корректного владельца каталога. До старта проверяют доступность массива, UUID и ожидаемый путь. После аварийной перезагрузки контролируют, что сервис видит именно прежние данные, а не пустую новую директорию с тем же именем.
Отдельно полезно ограничить объём журналов и временных файлов. Диск ОС, заполненный логами неудачных запросов, способен остановить и вполне исправный массив. Мониторинг должен охватывать свободное место во всех участвующих файловых системах, а не только график занятости bucket.
Как связать отказ диска с конкретным объектом приложения
Для Debian-сборки полезно провести один сквозной опыт на тестовых данных. Приложение загружает небольшой объект и объект в несколько гигабайт; инженер сохраняет их ключи, размер и контрольную сумму. Затем выполняется штатная перезагрузка сервера. После неё проверяются сборка mdadm, монтирование файловой системы и чтение обоих объектов через тот же S3-клиент. Проверка по SMB этот результат не заменяет: у приложения другой протокол и своя авторизация.
Имена вида /dev/sdb не годятся как единственная карта дисков: порядок обнаружения устройств может измениться. В эксплуатационной записи нужны серийный номер накопителя, отсек, идентификатор массива и UUID файловой системы. При замене диска сверяют все эти признаки, а также ёмкость в секторах: одинаковая маркетинговая ёмкость не гарантирует идентичный размер двух накопителей.
Отдельно проверяют восстановление самого S3-сервиса. Нужны не только файлы объектов, но и предусмотренные выбранной реализацией метаданные, настройки доступа и секреты приложения, сохранённые надлежащим способом. Копирование внутреннего каталога работающего сервиса без согласованной процедуры не следует считать проверенной резервной копией. Результат испытания должен звучать предметно: приложение получило прежний объект по прежнему ключу, его содержимое совпало, а права постороннего пользователя остались ограниченными.
Как резервировать S3-хранилище
Копируются не только актуальные объекты. Для восстановления могут понадобиться конфигурация сервиса, политики, учётные записи, сертификаты и сведения о шифровании. При серверном шифровании потеря ключей может сделать исправную дисковую копию бесполезной. Секреты резервируют отдельно и с соответствующей защитой.
Репликация и версия объекта не равны независимому бэкапу. Ошибка администратора или вредоносное удаление способны распространиться на связанный узел. Политика сохранения должна учитывать такой сценарий и предусматривать изолированную копию либо поддерживаемую неизменяемость с проверенными правами управления.
Пример оценки: 6 ТБ данных при устойчивых 200 МБ/с потребуют не менее 8,3 часа только на передачу. Для RTO четыре часа этого уже недостаточно. Тогда меняют объём первой очереди восстановления, инфраструктуру копирования или саму цель RTO. Значения здесь расчётные; подтверждение даёт только пробное восстановление.
Какие проверки обязательны перед запуском приложения
| Сценарий | Проверка | Что считать результатом |
|---|---|---|
| Большой объект | Multipart-загрузка с прерыванием соединения | Повтор и очистка незавершённых частей работают предсказуемо |
| Мелкие объекты | Параллельные PUT/GET и LIST | Известны задержки и предел запросов при заданном профиле |
| Права | Чужой bucket, удаление, просроченная ссылка | Запрещённые операции действительно отклоняются |
| Перезапуск | Возврат ОС и служб после выключения | Используется правильный каталог, прежние объекты читаются |
| Бэкап | Восстановление в чистом окружении | Хэши совпадают, приложение открывает данные |
| Наблюдаемость | Заполнение диска, ошибка службы, недоступность endpoint | Администратор получает понятное уведомление |
Как согласовать контракт S3 между сервером и приложением
До развёртывания полезно описать один полный пользовательский путь. Например: приложение получает файл, выдаёт уникальный ключ, загружает объект, проверяет размер и содержимое, записывает ссылку в свою базу и только затем сообщает пользователю об успехе. Если объект загружен, а запись базы не сохранилась, появляется бесхозный объект; если база обновилась раньше загрузки, ссылка может вести к отсутствующим данным.
Это задача согласованности приложения, а не только RAID. Для неё нужны повторяемые операции, обработка ошибок и уборка незавершённых действий. Нельзя исправить неправильный порядок транзакций увеличением памяти сервера. В тестовом контуре специально разрывают соединение между стадиями и проверяют, может ли система безопасно повторить запрос.
Ключи объектов лучше проектировать независимо от пользовательского имени файла. Два сотрудника могут одновременно загрузить report.pdf, и это не должно случайно перезаписать чужой документ. Идентификатор, исходное имя, тип содержимого и принадлежность пользователю — отдельные данные приложения. Такой подход упрощает перенос между хранилищами и восстановление связей.
Не следует использовать ETag как универсальную контрольную сумму всего файла: его смысл зависит от способа загрузки и реализации, в том числе multipart и шифрования. Для проверки целостности выбирают поддерживаемую явную checksum-функцию либо собственный сохранённый хэш. Алгоритм должен быть известен обеим сторонам и проверяться при восстановлении.
Как составить полезный профиль нагрузки
Одной фразы «нужно быстрое S3» недостаточно. Пусть расчётная команда создаёт 20 тысяч объектов в сутки со средним размером 2 МБ. Это около 40 ГБ новых данных в день, примерно 1,2 ТБ за 30 дней до версий и служебных расходов. При пике в 50 одновременных загрузок нагрузка будет совсем иной, чем при равномерном распределении в течение суток.
Если те же 40 ГБ состоят из 20 миллионов объектов по 2 КБ, меняется число операций и объём метаданных. Поэтому тестовые данные должны сохранять распределение размеров, а не только общую ёмкость. Важно включить и самые большие объекты, и многочисленные небольшие, и запросы перечисления, если приложение их действительно делает.
Параллельность увеличивают ступенями: один клиент, несколько, затем ожидаемый пик с запасом. На каждой ступени смотрят p95/p99, долю ошибок и занятость CPU/дисков. Рабочий предел — точка, после которой задержка или ошибки перестают соответствовать требованиям. Это не обязательно максимальное значение, при котором сервер ещё не упал.
Для фоновой загрузки пакета могут быть допустимы секунды ответа, для пользовательского превью — нет. Разделение классов запросов помогает избежать ложного компромисса, когда тяжёлый экспорт ухудшает интерактивную работу. Иногда отдельная очередь и ограничение фоновой параллельности дают больше, чем замена CPU.
Версии, удаление и сроки хранения: где возникает скрытый рост
Если приложение удаляет объект, нужно понимать, что именно происходит с прежними версиями и занимаемым местом. Отметка удаления и физическое освобождение данных могут быть разными действиями. Политика «хранить всё навсегда» удобна в первые недели и становится дорогой через год.
Для каждого типа данных задают срок: временные загрузки, результаты обработки, активные документы, архив и незавершённые multipart-части. Политики проверяют на отдельном bucket с тестовыми объектами. Ошибка в условии жизненного цикла может удалить нужные данные намного быстрее, чем администратор заметит график свободного места.
Неизменяемость тоже требует проверки конкретной реализации и режима. Нельзя обещать WORM только по наличию пункта Object Lock в интерфейсе. Нужно проверить создание объектов с нужным retention, права изменения, поведение привилегированного пользователя и восстановление. Для обычной лаборатории такие функции могут быть избыточными, для архива с обязательными сроками — определяющими.
Как обновлять сервер без неожиданной потери доступа
Пакеты Debian, ядро, S3-сервис, reverse proxy и сертификаты имеют разные циклы обновления. Обновлять их одновременно на единственном узле без проверенного возврата рискованно для доступности. Практический порядок начинается с резервирования конфигурации, проверки совместимости приложения и запуска тестового экземпляра на копии данных.
Для самого объектного движка заранее выясняют, изменяет ли новая версия формат данных и возможен ли обратный запуск старой. Копия бинарного файла ещё не является откатом, если метаданные уже преобразованы. В регламенте фиксируют конкретную точку возврата и длительность окна обслуживания.
Проверка после обновления включает не только ответ health endpoint. Приложение должно загрузить объект, прочитать прежний, получить корректную временную ссылку и выполнить разрешённое удаление. Затем проверяются заведомо запрещённые операции. Это обнаруживает ошибки политик и маршрутизации, которые обычный мониторинг порта не видит.
Как оформить восстановление, которое сможет выполнить другой инженер
Памятка начинается с зависимостей: где резерв конфигурации, где данные, как получить ключи, какое имя endpoint ожидает приложение и какие версии нужны. Затем описывается создание чистой среды, возвращение данных и проверка. Секреты не публикуются вместе с обычной документацией.
Полезно отдельно измерять время до первого доступного критичного bucket и время полного восстановления. Эти показатели могут отличаться в несколько раз. Если приложению для старта достаточно последних 500 ГБ, такой приоритет можно заранее заложить в процедуру, не дожидаясь возврата всего многотерабайтного архива.
Завершение восстановления подтверждается приложением и контрольными данными: права, версии, содержимое и записи базы должны согласоваться. Полученный HTTP200 от пустого нового сервиса не означает возврата рабочей системы. Именно эта проверка превращает собственное S3 из эксперимента в поддерживаемый внутренний инструмент.
Частые вопросы по собственному S3 на Debian
Обязательно ли давать серверу доступ из интернета?
Нет. S3 API может обслуживать только внутренние приложения. Публичный endpoint нужен лишь при соответствующей задаче и отдельной настройке доступа, сертификатов, ограничений и наблюдения. Сам протокол не требует публичного размещения.
Нужны ли 64 ГБ RAM для любого объекта?
Нет универсального требования именно такого объёма. В исходном кейсе установлено 64 ГБ; для нового проекта память рассчитывают по реализации сервиса, метаданным, кэшу и параллельности. Маленький лабораторный endpoint и производственный архив требуют разного бюджета.
Когда стоит отказаться от одного сервера?
Когда допустимое время простоя меньше времени замены и восстановления узла, когда нет окна обслуживания или когда необходима отказоустойчивость на уровне площадки. В таком случае следует выбирать архитектуру из независимых серверов, а не добавлять ещё один сетевой порт к прежнему.
Какие данные нужны для подбора оборудования?
Количество объектов, их размеры, пиковые запросы в секунду, годовой рост, обязательные S3-функции, RPO/RTO и схема резервирования. С этими вводными можно сравнить компактную плату и полноценный сервер хранения Supermicro и заранее определить, кто будет сопровождать программную часть.