Block storage для VM: де вузьке місце і що ламається
Block storage для VM рідко ламається сам по собі: просадка дискових операцій приходить з рівня зберігання.
Коли кілька машин ділять один том або спільний пул, їхні запити стають у спільну чергу, і будь-яке пікове навантаження — копіювання, важкий звіт, синхронізація — гальмує всіх сусідів. Застосунок бачить це як зростання часу відгуку, хоча процесор і пам'ять вільні.
Друге джерело — режим кешування. Якщо гіпервізор кешує запис, а всередині гостьової системи працює власний журнал, підтвердження повертаються швидше, ніж дані реально лягли на носій. До першого збою це виглядає як прискорення, після — як втрата останніх транзакцій.
Зворотна помилка теж дорога: надмірне наскрізне кешування з'їдає ресурс тома і додає затримку на кожну операцію.
Третя причина — відсутність рознесення за чергами. Дані, журнал транзакцій, знімки та копії на одному томі конкурують за одну смугу і один ліміт операцій.
Розвести їх по різних томах або групах — означає прибрати вузьке місце сховища з рівняння, і деградація віртуальної машини перестає залежати від чужої активності.
Діагностика починається з вимірювань: затримка читання і запису, довжина черги введення-виведення, частка часу зайнятості тома, розмір блока, співвідношення операцій читання і запису.
Далі — підбір типу тома, режиму кешу та політик моніторингу під профіль навантаження; розбираємо, як це закривається.
Що дає винесення дисків VM на окреме сховище
Коли диски віртуальних машин лежать на локальних масивах гіпервізора, час відгуку залежить від сусідів: одна машина у фоновому копіюванні з'їдає чергу, і в усіх інших зростає затримка читання і запису. Знайти винуватця складно, а пояснити бізнесу плаваючі гальмування сервісу — ще складніше.
Винесення дисків в окреме сховище розриває цю зв'язність. Кожен том отримує власні ліміти за кількістю операцій і пропускною здатністю, планувальник розкладає їх по вузлах, і час відгуку залишається передбачуваним у всьому діапазоні навантаження, включно з піковими вікнами.
Головний ефект — зникає цілий клас відмов. Дані лежать не на диску конкретного сервера, а на розподіленому сховищі рівня Ceph: вихід вузла з ладу не означає втрату тома, машина перезапускається на іншому сервері.
Час відновлення вимірюється хвилинами замість годин розбору і підйому з копії — вартість простою падає відповідно.
Витрати на зберігання при цьому перестають зростати разом із парком машин. Тонке виділення віддає тому лише реально записані блоки, клон під тестовий контур піднімається без повного копіювання, а застарілі знімки чистяться політикою зберігання.
Далі все тримається на моніторингу: затримка операцій, глибина черг, частка таймаутів і стан реплік. За цими метриками деградація помітна до того, як вона перетвориться на відмову.
Режими підключення дисків: порівняння варіантів
Режим підключення диска визначає, що станеться з віртуальною машиною при відмові вузла або мережі, і наскільки вільно її можна переносити між серверами. Нижче — реальні альтернативи, між якими вибирають на старті проєкту, разом з обмеженнями кожної схеми.
| Варіант | Коли підходить | Обмеження схеми |
|---|---|---|
| Локальні диски сервера | Один вузол, потрібен мінімальний відгук на запис, перенесення машин не планується | Немає реплікації: відмова заліза — втрата стану; машина жорстко прив'язана до вузла |
| Мережеві томи | Машини переносять між вузлами, потрібні знімки і швидке розширення | Затримка мережі на кожен запис, залежність від каналу, окрема межа на кількість операцій |
| Розподілене сховище | Багато вузлів, потрібно пережити відмову одного-двох без зупинки сервісу | Потрібно щонайменше три вузли і рівна внутрішня мережа; діагностика складніша, ніж в одиночного тома |
| Реплікація поверх мережевих томів | Критичні сервіси, де важливий швидкий перехід на копію | Подвійна витрата місця; при синхронному режимі зростає час відгуку на запис |
На практиці частіше беруть гібрид: систему і кеші — на локальні диски, дані — на мережеві томи. Тоді швидкість не заважає перенесенню машин, а резервне копіювання і відновлення залишаються передбачуваними.
Вибір фіксуємо у схемі розміщення і перевіряємо навантаженням до виведення в роботу, щоб обмеження проявилися на стенді, а не в проді.
Як ми підбираємо і налаштовуємо block storage під навантаження
Підбір сховища починається не з вибору моделі заліза, а з профілю навантаження: ми знімаємо метрики з працюючих віртуальних машин і дивимося, що саме впирається в диск.
Співвідношення читання і запису, характер піків, вимоги до затримки і глибина черги на томі визначають тип носія, рівень надмірності та топологію — помилка на цьому кроці проявляється не відразу, а на першому ж зростанні навантаження. Далі йде інженерний порядок, який ми тримаємо однаковим на всіх проєктах.
- Знімаємо профіль навантаження — збираємо статистику з гіпервізорів і гостьових систем за робочий цикл, а не за один день: де рівний потік, де короткі сплески, який том деградує першим.
- Підбираємо сховище — зіставляємо профіль з типом тома і рівнем надмірності, відсікаємо варіанти, які формально підходять за обсягом, але не витримають піків.
- Проєктуємо схему томів — розбиття за призначенням, файлова система, параметри монтування, резервні копії та порядок їх зняття, щоб том не доводилося зупиняти.
- Налаштовуємо і підключаємо — вмикаємо багатошляховий доступ, виставляємо кешування і чергу під характер навантаження, перевіряємо, що після перезавантаження вузла томи збираються автоматично.
- Перевіряємо на відмову — по черзі відключаємо шлях до сховища, вузол, половину каналів і фіксуємо, скільки триває перемикання і чи втрачається запис.
- Ставимо моніторинг — оповіщення за затримкою, заповненням, зносом і помилками введення-виведення, щоб деградація була помітна до того, як її помітить користувач.
- Передаємо регламенти — схему розміщення, процедури розширення тома, відкату і заміни диска, порядок дій при збої — у вигляді документа, за яким працює чергова зміна.
Що замовник отримує на руки: схеми, політики, регламенти
Проєкт закривається не презентацією, а робочою документацією: чергова зміна і ваш інженер мають уміти розширити том або відкотити зміну без нашої підказки. Тому комплект артефактів фіксується за фактичним станом сховища, а не за чернетками в листуванні.
- Карта томів — який том якому вузлу віддано, обсяг, клас носія, точка монтування, призначення і власник з боку замовника.
- Схема розміщення — пули, рівні відмовостійкості, межі доменів відмов: видно, чий збій зачепить конкретне навантаження.
- Політики доступу — ролі, зони, правила маскування, хто має право змінювати конфігурацію, а хто лише читає метрики.
- Налаштування реплікації — цільова точка відновлення, глибина зберігання копій, розклад, порядок відкату тома.
- Моніторинг — метрики (вільне місце, затримки відгуку, глибина черги, помилки введення-виведення), пороги попереджень і адресати сигналів.
- Документація сховища — конфігурація томів і мережевих шляхів, схема підключення вузлів, інструкції за типовими операціями.
- Регламент обслуговування — планові вікна, заміна носія, оновлення прошивок, перевірка відновлення з копій, відповідальні.
Кожен документ перевіряється на приймальному прогоні: імітуємо відмову і просимо вашого інженера виконати операцію строго за регламентом. Якщо крок не відтворюється — правимо документ, а не пояснюємо словами.
Кейс: як прибрали просадки введення-виведення на кластері віртуалізації
Де втрачали введення-виведення
Кластер віртуалізації на кілька десятків вузлів, диски машин лежали в блоковому сховищі на Ceph, томи зростали в тонкому режимі, а снапшоти резервного копіювання писалися в той самий пул, де йшов робочий трафік.
Спочатку все було рівно, але зі зростанням кількості машин з'явилися короткі просадки: затримка введення-виведення підскакувала в десятки разів під час нічного копіювання, міграцій вузлів і перебудови масивів.
Частка операцій довше цільового порога зросла з 1–2% до 15%, а окремі машини йшли в очікування диска на хвилини.
Причина — конкуруючі черги: довге відновлення ділило смугу з продуктивним трафіком, тонкі томи фрагментувалися, а файл підкачки і тимчасові каталоги жили на найнавантаженішому пулі.
Що змінили і як вимірювали
Рознесли зберігання по пулах під різні класи навантаження і залишили спільний пул лише під block storage для віртуальних машин.
Обмежили глибину черги і швидкість службового ребалансу, щоб фонові задачі не витісняли робочий трафік, винесли файл підкачки і тимчасові файли на окремі томи, увімкнули кеш запису і вирівняли розділи гостьових систем.
Телеметрію знімали однаковим профілем навантаження до і після: дивилися не середні, а перцентилі та частку операцій вище порога — саме середні просадки й приховують.
Результат: частка повільних операцій повернулася до 1%, затримка під резервним копіюванням перестала зростати, відновлення вузла прискорилося втричі, оновлення і міграції проходять без пауз для сервісів.
На моніторингу залишилося три метрики — затримка, глибина черги і запас місця в пулі, за ними налаштовані алерти зі зрозумілим порядком реакції чергового інженера.
Чим відрізняється блочне сховище від файлового та об'єктного?
Різниця не в залізі, а в моделі доступу до даних. Блочне сховище віддає віртуальній машині сирий том: усередині немає файлової системи, її створює й обслуговує гостьова ОС.
Файлове сховище, навпаки, публікує готову файлову систему з шляхами і правами — один каталог монтують одразу кілька машин. Об'єктне сховище влаштоване інакше: дані лежать як об'єкти з ключами в плоскому адресному просторі, доступ іде через API, а не через монтування.
Звідси різні задачі. Блочний том — це кореневий диск ВМ, розділ під базу даних, усе, де потрібен передбачуваний відгук на випадкові операції і власна файлова система.
Ціна — прив'язка до зони доступності й акуратність з одночасним записом: підключити один том до двох машин на запис не можна.
Файлове зберігання доречне там, де кілька віртуальних машин мають бачити одні й ті самі дані: спільні каталоги, профілі, обмінні папки. Обмеження — метадані і блокування: при навантаженні на дрібні файли вони стають вузьким місцем.
Об'єктне зберігання не підходить під диск ВМ: об'єкт перезаписується повністю, затримка доступу вища. Зате це правильне місце для образів, резервних копій та архівів — версіонування і термін зберігання задаються політикою.
Вибір типу зберігання йде від профілю навантаження: частка випадкових операцій, одночасний доступ з кількох вузлів, розмір об'єктів. На практиці моделі комбінують — блочне під диски машин, об'єктне під копії та образи, файлове під спільні каталоги.
Технічні сумніви: відмовостійкість, шифрування, міграція
Заперечення щодо block storage для VM рідко стосуються швидкості — частіше це експлуатаційні ризики: поведінка тома при втраті вузла, перенесення без зупинки сервісу, шифрування і сумісність з уже розгорнутим масивом. Розбираємо кожен.
Що буде з томом при втраті вузла?
Репліки тома розносимо по різних доменах відмов, тому відмова вузла не зупиняє гостьову систему: введення-виведення перемикається на живу копію.
Відмовостійкість тома перевіряємо окремим сценарієм — при синхронному записі підтверджені дані не втрачаються, при асинхронному заздалегідь відома точка відновлення.
Як проходить міграція без простою?
Усередині кластера том переносять разом із працюючою машиною: вміст копіюється заздалегідь, залишається коротке перемикання. Між сховищами вмикаємо поетапну реплікацію на рівні тома, звіряємо контрольні суми і лише потім переводимо навантаження. Вікно недоступності — секунди.
Чи можна підключити наявне сховище?
Так, уже розгорнутий масив підключається як окремий пул — перебудовувати його повністю не потрібно. Переносимо томи групами, на кожній звіряємо цілісність і поведінку під навантаженням, і лише потім переводимо решту. Вихідні копії живуть до кінця приймання, тому відкат на попередню схему залишається можливим.
Шифрування томів сповільнить роботу?
Шифрування робимо на рівні тома, ключі зберігаємо окремо від даних і налаштовуємо планову ротацію. Прискорення бере на себе процесор, тому накладні витрати вкладаються в однозначні відсотки і на типовому навантаженні не помітні. Зате винесення або утилізація носія більше не розкривають вміст диска.
Обговоримо задачу: підберемо режим зберігання під ваше навантаження
Щоб первинний розбір був предметним, а не вгадуванням, нам потрібні вхідні дані про навантаження і поточне сховище.
Обговоримо задачу у форматі: ви надсилаєте профіль навантаження й обмеження, ми повертаємо оцінку і план — з конкретним типом тома, налаштуваннями і схемою моніторингу.
- Профіль введення-виведення: частка читання і запису, розмір блока, потрібна затримка, добові та тижневі піки, сезонні сплески.
- Кількість віртуальних машин, їхні ролі та те, у яких із них зберігання критичне для відгуку застосунку, а в яких — лише для збереженості даних.
- Обсяги і швидкість зростання: поточний розмір томів, вільне місце, очікуваний приріст за квартал.
- Платформа і гіпервізор, тип томів, режим підключення (спільний або з локальною прив'язкою), вимоги до знімків і реплікації між зонами доступності.
- Що вже болить: просадки на піках, зростання черг, таймаути застосунків, несподівані витрати на зберігання, ручні операції при розширенні тома.
- Обмеження середовища: вікно обслуговування, політика резервного копіювання, вимоги до шифрування і до розділення доступів.
У відповідь ви отримаєте оцінку і план: рекомендований режим зберігання під ваш профіль, параметри томів і черг, налаштування знімків і життєвого циклу, набір метрик і порогів для оповіщень, а також порядок міграції з планом відкату.
Наступний крок — короткий дзвінок за надісланими даними: уточнюємо спірні місця і фіксуємо обсяг робіт.
