Настройка Hetzner Cloud Volumes и Object Storage под ключ

Почему диски в Hetzner Cloud Volumes упираются в предел

Том заполнен — и первым это замечает не мониторинг, а приложение. У блочного тома есть лимит: когда свободного места остаётся единицы процентов, файловая система начинает дробить записи, растёт очередь операций ввода-вывода, время ответа на запись увеличивается в разы — это деградация записи, которую по графику нагрузки видно раньше, чем по алертам. Сервис ещё работает, но логи, сессии, временные файлы и журналы базы пишутся с задержкой, а при полном исчерпании места ядро переводит раздел в режим только для чтения — и база отдаёт ошибки на каждой транзакции.

Отдельная ловушка в том, что том и файловая система масштабируются раздельно. Увеличение блочного тома само по себе места не добавляет: раздел остаётся прежнего размера, и свободное пространство не появится, пока не расширены раздел и файловая система. Диагностика этой связки обычно занимает больше времени, чем само исправление.

Ручное расширение — это почти всегда простой сервиса. Нужно остановить приложение, отмонтировать том, изменить раздел, выполнить проверку файловой системы, примонтировать обратно и убедиться, что данные целы. На нагруженной базе это окно в несколько десятков минут ночью, плюс риск ошибки в разметке и гарантированный откат по доступности.

Разбираем, как это закрывается: расширение без простоя, когда том наращивается на лету, а файловая система подхватывает новый размер без остановки приложения. И разделение данных по слоям — горячие наборы остаются на блочном томе, холодные и статические уезжают в объектное хранилище, так что том перестаёт быть единственным местом, где заканчивается место.

Расширение Volumes и снимки без остановки сервиса

Пока данные лежат на локальном диске сервера, любое изменение — размера, точки восстановления, переноса — требует остановки сервиса. Перевод на управляемые тома и объектное хранилище Hetzner развязывает вычислительный узел и данные: инстанс можно пересоздать или заменить, а тома и содержимое хранилища остаются на месте. Ниже — четыре эффекта, которые видно в эксплуатации.

Рост тома на ходу

Размер тома меняется отдельной операцией, без перезапуска инстанса: узел продолжает обслуживать запросы, а файловая система расширяется на работающей машине. Это снимает сценарий «место кончилось вечером, а окно на остановку — только в выходные».

Восстановление из снимков

Снимок фиксирует состояние блока целиком, поэтому возврат к предыдущей точке — это создание нового тома из снимка и его подключение. Вместо холодной выкладки архива с распаковкой получается подключение готового блока: восстановление сокращается с часов до минут, а исходный том остаётся нетронутым для разбора причины сбоя.

Оставшиеся два эффекта — резервное копирование и автоматизация операций. Выгрузки в объектное хранилище идут по расписанию и дописывают только изменения, а правила хранения сами снимают устаревшие поколения, поэтому архив не растёт бесконечно. Расписания снимков, ротация и регулярная проверка восстановлением описываются конфигурацией: отказ узла превращается в пересоздание инстанса с подключением тома, без ручного восстановления данных.

Режимы хранилища: блочные тома, объектное и локальное

Разница между режимами хранения проявляется на этапе отказов и роста нагрузки, а не в штатной работе. Блочный том в Hetzner Cloud монтируется к серверу и переживает его пересоздание, объектное хранилище отдаёт файлы по сети, а локальный диск живёт столько же, сколько сам сервер. Дальше — критерии, по которым мы разводим данные.

Критерии выбора

Первый вопрос — нужна ли файловая семантика: частичная запись, переименование, блокировки. Если приложение работает с каталогами и правами доступа, берём блочный том. Для архивов и редкого обмена достаточно объектного хранилища.

Типовые узкие места

Чаще всего ошибаются на двух вещах: монтируют один том к нескольким серверам и повреждают файловую систему, либо складывают базу данных в объектное хранилище, где задержка на каждой мелкой операции складывается в заметные секунды. Мы разводим данные по режимам заранее, чтобы это не всплыло в момент роста нагрузки.

Этапы внедрения: от аудита нагрузки до передачи регламентов

Работу ведём итерациями: каждый этап заканчивается артефактом, который можно проверить. Порядок не декоративный — если схема размещения данных не опирается на замеры, проверка отказами вскроет это уже в эксплуатации.

Аудит и проектирование

1. Аудит нагрузки — снимаем профиль за длительный период: объём и характер записи, доля чтения, пики, скорость роста. На выходе — расчёт, что держим на томах, а что уводим в объектное хранилище.
2. Схема размещения данных — раскладываем базы, файлы и резервные копии по томам и бакетам, задаём размер с запасом на рост и точки снапшотов. Отдельно фиксируем, что живёт вместе с сервером, а что независимо от него.
3. Разграничение доступов — ключи и роли отдельно для приложений, сервисов и людей; права только на нужные операции с конкретными бакетами, секреты не лежат рядом с кодом.

Внедрение и приёмка

• Настройка — создаём тома Hetzner Cloud Volumes и объектное хранилище, прописываем монтирование, шифрование, расписание копий и политики жизненного цикла: сколько версий хранить и когда освобождать место.
• Проверка отказами — перезапускаем узел, переполняем том, роняем копию: смотрим, поднимается ли сервис сам и сколько занимает восстановление из снапшота.
• Передача регламентов — схема хранения, правила ротации, порядок действий дежурного при переполнении и инструкция по откату на предыдущий снапшот.

Конфигурации, схемы и политики доступа после внедрения

После внедрения у команды заказчика остаётся не «работающая инфраструктура» как чёрный ящик, а комплект, по которому её можно сопровождать, расширять и восстанавливать без нас. Ниже — что именно передаётся и в каком виде.

Что входит в комплект передачи

• Конфигурация хранилища — описания томов Hetzner Cloud Volumes и бакетов Object Storage: размер, точка монтирования, файловая система, параметры подключения к серверам. Всё файлами, а не настройками, выставленными руками в панели.
• Схема размещения — карта: какой том и бакет обслуживает какой сервис, где лежат данные состояния, где резервные копии и как между ними идёт трафик.
• Политики доступа — роли и ключи: кто и из какой сети читает и пишет, какие ключи только на чтение, где ограничение по префиксу, как проходит ротация.
• Расписание снимков — интервалы, глубина хранения, что покрывают автоматические снимки, а что копирование между локациями.
• Инструкция по восстановлению — порядок: из какого снимка, в какой последовательности, как проверить целостность и вернуть сервис в работу.
• Регламент проверок — как часто разворачиваем снимок на тестовом контуре и что делаем при расхождении.
• Схема наблюдаемости — метрики заполнения томов, оповещения об отказах копирования и ошибках доступа.

Комплект живёт в репозитории рядом с конфигурацией инфраструктуры: правки проходят проверку, история сохраняется, а новый инженер входит в контур по документации, а не по рассказам.

Кейс: реестр изображений переехал без остановки сервиса

Реестр образов продуктовой команды упирался в размер тома. Новые сборки добавляли слои, старые манифесты и теги никто не удалял, и заполнение росло быстрее, чем том успевали расширять. Заканчивалось предсказуемо: запись падала, дежурный останавливал реестр, вручную переносил данные и подменял точку монтирования — простой на часы, а восстановление вслепую, без проверенного порядка.

Хранение разделили по назначению: метаданные и рабочие каталоги оставили на блочном томе, который расширяется на ходу, слои образов перевели в объектное хранилище Hetzner. Правило хранения держит фиксированное число последних сборок на тег и убирает остальное — объём перестал расти сам по себе.

Переезд без остановки сервиса

Переключение шло через один адрес реестра с коротким TTL: пока сборочные контуры выгружали образы со старого хранилища, данные уже синхронизировались в новое. Старый контур перевели в режим только чтения, сверили расхождения и сняли его последним — ни один контур не получил ошибку при выгрузке.

Объём реестра сократился примерно вдвое за счёт чистки старых сборок, ручные переносы ушли из регулярных работ, а расширение тома идёт под нагрузку. Плановое восстановление репетировали на копии: разворот из снимка занял около двадцати минут вместо прежних четырёх-шести часов ручных операций. Алерты следят за скоростью роста и прогнозом заполнения — о риске узнаём заранее, а не в момент отказа.

Что делать, если хранилище уже развёрнуто и занято данными?

Миграция хранилища на живом сервисе не делается «в лоб»: пока идёт трафик, блочные тома Hetzner Cloud Volumes и объектное хранилище продолжают меняться, и любая копия устаревает в момент создания. Поэтому переезд без простоя строим как параллельную схему, а не как остановку и перенос: новая конфигурация поднимается рядом со старой, приложение пишет в оба места, а чтение переключается только после сверки.

Целостность проверяем сходимостью, а не «на глаз»: контрольные суммы блоков, количество и размер объектов, время последней записи в каждой ветке. Расхождение разбирается до переключения — дельта дописывается из журнала изменений, а не переносится вслепую. Пока сверка не сошлась, трафик читает старая схема.

Обратная совместимость держится на том, что старые пути и точки монтирования остаются рабочими: приложение получает новые адреса через переменные окружения, а не через правку кода. Тогда откат — это возврат одной переменной и перезапуск, а не второй переезд.

План отката фиксируем до старта: старая схема не демонтируется, пока новая не отработает полный цикл «запись — чтение — резервная копия — восстановление». Простой при таком переходе измеряется секундами на переключение чтения, а не часами копирования; основная работа идёт фоном, на живом сервисе.

Технические сомнения: целостность, доступы и отказоустойчивость

Возражения по надёжности у инженеров почти всегда про проверяемость, а не про недоверие к платформе. Ниже — те, что чаще всего всплывают при переносе данных на Hetzner и разделении доступов между сервисами.

Как разграничить права доступа сервисов?

На каждый сервис — отдельный ключ, ограниченный своим контейнером объектного хранилища и набором операций: приложению, читающему статику, не нужны права на запись и удаление. Тома подключаем с нужными флагами монтирования, для критичных данных — только чтение.

Что будет при отказе узла?

Снимки томов и версионирование объектов держат точку восстановления независимо от состояния сервера. Подъём из снимка отрабатываем на стенде заранее — фактическое время восстановления известно, а не предполагается.

Как устроены шифрование и аудит обращений?

Данные шифруются при хранении и при передаче, ключи лежат вне конфигурации приложения. Обращения к объектному хранилищу пишутся в журнал доступа — по нему видно, кто и когда читал контейнер, и настраиваются оповещения об аномалиях.

Обсудим задачу: соберём схему хранения и план переезда

План переезда собирается из вводных данных, а не из общих соображений. Опишите постановку задачи: какие сервисы пишут и читают данные, суточный и пиковый объём, доля мелких объектов, требования к сохранности и географии. По этим цифрам мы прикидываем оценку объёма работ и понимаем, где нужен промежуточный контур, а где достаточно переключения на лету.

Отдельно уточняем то, что чаще всего тормозит переезд: окна на обслуживание, доступы к панели управления и программному интерфейсу, кто владеет DNS и сертификатами, есть ли жёсткое требование совместимости с привычным интерфейсом объектного хранилища. Если часть вводных неизвестна — не страшно, разберём на первом разговоре.

В план работ войдёт:

• схема разбиения на тома Hetzner Cloud Volumes и бакеты объектного хранилища с правами и именами;
• правило хранения версий: сколько последних копий держим, что уходит в холодный класс, что удаляется;
• последовательность работ по шагам — от тестового контура до переключения продуктивной нагрузки;
• точки проверки после каждого шага: как убеждаемся, что данные сошлись и сервис отвечает;
• план отката: в какой момент и какими действиями возвращаемся к прежней схеме;
• набор метрик и оповещений: заполнение томов, доля ошибок записи, задержка отклика;
• итоговая документация — схема, политики, инструкции для дежурной смены.

Опишите задачу в свободной форме: вернёмся с оценкой объёма, планом переезда и согласованной последовательностью работ.