Налаштування 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 і бакети об’єктного сховища з правами та іменами;
• правило зберігання версій: скільки останніх копій тримаємо, що переходить у холодний клас, що видаляється;
• послідовність робіт за кроками — від тестового контуру до перемикання продуктивного навантаження;
• точки перевірки після кожного кроку: як переконуємося, що дані зійшлися і сервіс відповідає;
• план відкату: у який момент і якими діями повертаємося до попередньої схеми;
• набір метрик і оповіщень: заповнення томів, частка помилок запису, затримка відгуку;
• підсумкова документація — схема, політики, інструкції для чергової зміни.

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