Налаштування LVM: де ламається статична розмітка дисків
Класична ситуація: сервер нарізали один раз — під систему, логи та бази, з розрахунку на стартове навантаження. Через кілька місяців розділ упирається в стелю, хоча поруч залишається нерозмічений хвіст носія, а в сусідньому розділі простоює вільне місце.
Статична розмітка дисків віддати його не дає: межі зафіксовані, і переповнення розділу стає питанням часу.
Далі знайомий сценарій. Місце шукають на іншому носії, додають другий диск і переносять дані вручну — із зупинкою сервісу, перевіркою цілісності та зворотною синхронізацією.
Простій під час перенесення даних вимірюється годинами, а запас за місцем на сервері щоразу купується ціною недоступності.
Налаштування LVM прибирає саму причину: фізичні томи (PV) збираються в групу (VG), а логічні томи (LV) нарізаються під задачі, а не під геометрію конкретного диска. Розширення тому та файлової системи відбувається на працюючій системі, без розмонтування та перезавантаження. Додали носій — він увійшов у групу, і місце стало доступним усім томам одразу.
Снапшоти закривають другу половину задачі: копія тому знімається за секунди й слугує опорною точкою для резервного копіювання або відкату перед оновленням. Дані переносяться між томами та носіями без вікна обслуговування. Розбираємо, як це закривається на практиці — від схеми томів до політики розширення.
Що дає гнучке керування дисками та томами
Гнучке керування дисками починається з абстракції: фізичні томи об'єднуються в групу, з якої нарізаються логічні томи. Диск перестає бути одиницею адміністрування — замість питання «на якому носії лежить база» з'являється «скільки місця потрібно розділу». Перевірний список ефектів, які видно в експлуатації після переходу на LVM.
- Розширення на ходу. Вільне місце з групи додається до розділу на працюючій системі, без зупинки сервісу та розмонтування файлової системи — оновлення перестає чекати на нічне вікно обслуговування.
- Точка повернення снапшотом. Копія стану тому знімається швидко, і якщо міграція схеми даних пішла не туди, повернення займає хвилини замість тривалого відновлення з повної резервної копії.
- Зниження ризику простою. Дані переносяться з носія на носій на живій системі: заміна деградованого диска та переїзд на інший масив не потребують зупинки застосунків.
- Єдина схема зберігання. Дані, логи та копії живуть в одній групі за спільними правилами — місце перерозподіляється між розділами без перерозмітки та перевстановлення серверів.
- Тонке виділення. Томи отримують ємність із запасом, а фізично займають стільки, скільки реально записано, — нові стенди піднімаються без очікування на нові носії.
- Керування дисковим простором. Вільне місце рахується за групою, а не за кожним диском: одна метрика в моніторингу замість десятка, і заздалегідь видно, куди додавати ємність.
Налаштування LVM: порівняння підходів і режимів
LVM не замінює розмітку диска, а надбудовується над нею: фізичні томи (PV) лягають поверх розділів або цілих носіїв, з них збираються групи томів (VG), а всередині групи нарізаються логічні томи.
Практичний вибір зводиться до чотирьох схем, і різниця між ними проявляється на операціях, які болять найчастіше: розширення, перенесення даних і зняття копії на гарячу.
Схеми та їхні межі
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Звичайні розділи | Простий сервер, статичні дані, мінімум змін | Місце не можна перекинути між розділами; зростання потребує перерозмітки та розмонтування |
| Томи поверх одного носія | Один диск під дані, потрібне зростання без зупинки сервісу й адресний снапшот | Відмова носія забирає всю групу — рятують лише копія або дзеркало |
| Об'єднання кількох носіїв у групу | Великий пул із різних дисків, гнучка нарізка під сервіси | Втрата одного PV рве том; без дзеркала LVM відмовостійкості не дає |
| Тонкі томи зі снапшотами | Віртуалізація, контейнери, багато точок відновлення | Потрібен контроль заповнення пулу та підтримка discard; переповнення пулу валить томи |
Снапшот тому — точка відкату на хвилини, а не заміна резервному копіюванню: він живе в тому самому пулі й помирає разом із ним. Під бази даних ми зазвичай збираємо кілька PV в одну групу з дзеркалом, а тонкі томи віддаємо під віртуалізацію, де важлива щільність снапшотів.
Порядок впровадження: від аудиту дисків до передачі
Роботи йдуть етапами, і кожен закривається перевірюваним результатом: до наступного кроку переходимо лише після підтвердження попереднього. Так розмітку не змінюють на живому сервері навпомацки — спочатку стенд, потім бойовий контур.
- Аудит дискової підсистеми. Знімаємо фактичну картину: які фізичні томи та групи томів є, як розподілені логічні томи, де залишилися нерозмічені ділянки. На виході — карта розміщення з вузькими місцями.
- Схема розміщення даних. Проєктуємо цільове розкладання: що об'єднуємо в групу томів, де розміщуємо корінь, журнали та дані застосунків, який запас залишаємо під снапшоти. Узгоджуємо до змін на бойових дисках.
- Складання на стенді. Відтворюємо розкладання на тестовому контурі та проганяємо повний цикл: створення томів, розширення, зняття й відкат снапшота. Тут же перевіряємо, як група поводиться під час додавання нового диска.
- Переведення без втрати даних. Ідемо в узгоджене вікно: зупиняємо запис, синхронізуємо дані, перемикаємо сервіс на нове розкладання, перевіряємо цілісність. Точка повернення залишається, поки все не підніметься штатно.
- Перевірка поведінки під навантаженням. Дивимося, як живуть снапшоти за активної роботи, скільки займає відкат, що відбувається при заповненні групи томів. Виміри стають орієнтирами для моніторингу.
- Передача регламенту обслуговування томів. Віддаємо документ: як додати диск, розширити том, почистити застарілі снапшоти, що перевіряти черговому.
Підсумок — передбачуване розкладання та відтворювані операції замість разових правок за фактом збою.
Що передаємо команді після налаштування томів
Налаштування томів закінчується не успішним монтуванням, а передачею пакета, за яким далі працюють чергова зміна та інженери без автора змін. Фіксуємо фактичний стан сховища, а не початковий задум: як розкладені фізичні томи, які групи зібрані, де залишився вільний обсяг. Усе, що не описано, за пів року перетворюється на розбір аварії наосліп.
- Схема томів і груп розміщення — які фізичні томи входять до кожної групи, які логічні томи створені, їхні розміри, точки монтування та файлові системи.
- Політики доступу до сховища — які сервіси та облікові записи бачать конкретні томи, хто має право розширювати й монтувати, що заборонено змінювати вручну на бойових групах.
- Порядок зняття снапшотів — коли знімається, який резерв під зміни виділяється, скільки снапшот живе, як видаляється і що робити при заповненні його тому.
- Інструкція для чергової зміни — розширення тому разом із файловою системою, додавання диска в групу, перевірка заповнення, дії при помилках введення-виведення.
- Документація щодо зберігання — карта розміщення, домовленості про найменування, квоти та пороги попереджень, журнал змін із причиною кожного розширення.
- Процедура повернення — який снапшот якому стану відповідає, як повернути том і як перевірити цілісність даних після відкату.
- Спостереження — які метрики знімаються, при якому заповненні надходить попередження і хто його отримує.
Кейс: розширення розділу на бойовому сервері без простою
Що було
На бойовому сервері розділ під дані підійшов до 95% — оновлення сервісу відкладали, бо попередній сценарій вимагав зупинки, копіювання та перерозмітки.
У такому вікні будь-яка помилка оберталася відкатом із резервної копії та годинами недоступності, а перенесення даних без зупинки здавалося нездійсненним.
Що змінили і що отримали на виході
Перевели сховище на LVM: додали диски в групу томів, перенесли дані між фізичними томами на працюючій системі та розтягнули логічний том разом із файловою системою без розмонтування. Перед змінами зняли снапшот — точку відкату, яка живе хвилини й не потребує повного дампа.
Заповненість розділу знизилася з 95% до 40%, а вікно робіт — із чотирьох годин планової зупинки до п'яти хвилин без переривання сервісу. Повернення до попереднього стану зі снапшота займає одиниці хвилин замість відновлення всієї копії.
Тепер розширення стало штатною операцією: додаємо том у групу, розтягуємо розділ, застосунок цього не помічає.
Результат впровадження томів — запас за обсягом, за якого наступне переповнення видно за графіком зростання заздалегідь, і стійкість до переповнення перестала бути аварійною задачею.
Чим тонкі томи відрізняються від звичайних і коли потрібні снапшоти
LVM дає дві моделі розміщення. Звичайний том отримує фізичні екстенти в момент створення — місце в групі томів зайняте, навіть якщо файлова система всередині порожня.
Тонкий том бере блоки із спільного пулу в міру запису: десятки томів уживаються на тому самому масиві, а витрата збігається з реальним обсягом даних. Виграш помітний на безлічі невеликих томів, а не на одному великому.
Снапшот працює за принципом копіювання при записі: у момент створення дані не копіюються, фіксується стан, а подальші зміни вихідного тому йдуть в окрему ділянку.
Чим довше він живе і чим інтенсивніший запис, тим більше займає — аж до вичерпання метаданих, після чого стає недійсним. Для тонкого тому снапшот дешевший, ніж для звичайного, але природа та сама.
Снапшот і резервна копія вирішують різні задачі. Снапшот лежить у тій самій групі томів і на тому самому носії — відмова диска або руйнування метаданих забирає і вихідний том, і снапшот.
Логічне псування (помилковий запит застосунку, зміна схеми) потрапляє в снапшот одразу після його створення. Його призначення — короткий відкат на хвилини: оновлення схеми, міграція, ризикована операція. Повноцінну копію виносять за межі вузла й зберігають окремо.
При виборі режиму тонкі томи виграють там, де томів багато і місце потрібно віддавати гнучко; звичайні — де важливіша передбачуваність і простота.
Тонкий пул потребує контролю перевантаження сховища: зайнятість даних і метаданих, пороги автоматичного розширення, повернення звільнених блоків. Без цього дозволене перепідписування перетворюється на відкладений збій.
Технічні сумніви, які варто зняти до старту
Інженерна команда замовника перед стартом ставить той самий набір питань: чи не зламаємо працюючий сервер, що буде при відмові носія, як це уживеться з віртуальними машинами.
Нижче — відповіді в тому вигляді, як ми даємо їх на етапі проєктування, до будь-яких змін на бойовому контурі.
Чи доведеться зупиняти працюючий сервер?
Ні. Новий диск підключається як фізичний том, дані переносяться на нього в працюючій системі — томи залишаються доступними. Зупинка потрібна лише на правку таблиці монтування та завантажувача; до неї знімаємо снапшот кореневого тому, відкат займає хвилини.
Що станеться при відмові фізичного диска?
Відмова одного носія не валить томи, розміщені на решті. Для критичних томів вмикаємо дзеркалювання, носій, що відмовив, виключаємо з групи, не розбираючи інші, — сервіс живе до планової заміни.
Як це уживається з віртуальними машинами та хмарними дисками?
Шар томів знаходиться вище за гіпервізор: гостьові системи бачать звичайні блочні пристрої та не потребують переналаштування. Хмарні диски підключаються як фізичні томи, а снапшот тому дає консистентну точку для резервної копії.
Як перевіряємо перед бойовим запуском?
На стенді з тією самою топологією проганяємо зростання тому, відкат зі снапшота та сценарій витягування диска. Звіряємо стан груп і томів до та після, окремо перевіряємо, що завантаження проходить без ручного втручання.
Чи сумісно це з поточною схемою?
Розмітка, масиви та шифрування залишаються як є — LVM встає поверх або під них, перезбирати схему не потрібно. План розміщення фіксуємо до робіт і проходимо по ньому разом із вашою командою.
Обговоримо задачу: повернемося з планом та оцінкою
Щоб повернутися з планом робіт зі зберігання, а не із загальними словами, нам потрібні вхідні дані щодо серверів. Достатньо того, що у вас уже є під рукою: вивід lsblk, pvs, vgs і lvs, схема розміщення та короткий опис, що саме перестало влаштовувати.
- Перелік серверів і віртуальних машин із роллю кожної — база, застосунок, файлове сховище, резервні копії.
- Поточна розмітка: які томи зібрані, де залишилися нерозмічені ділянки, скільки місця вільно на кожному фізичному носії.
- Типи носіїв та їхнє призначення — що віддаємо під гарячі дані, що під архів, де допустиме змішування.
- Вимоги до снапшотів: як часто знімаємо, скільки зберігаємо, у яке вікно допустиме короткочасне уповільнення запису.
- Чинний регламент резервного копіювання та вікна обслуговування, в які можна змінювати схему томів.
- Обмеження щодо доступів: хто дає SSH і права на керування томами, чи є погодження змін.
- Що болить зараз — розділ упирався в розмір, розширення потребує простою, снапшоти не вміщаються.
Далі ми уточнимо межі груп томів, схему зростання й відкату, точки, де снапшот безпечний для застосунку. У відповідь повернемося з планом робіт зі зберігання: етапи, оцінка термінів кожного, порядок перемикання без тривалого простою та схема підсумкового розкладання.
Якщо якихось даних немає — не страшно, частину знімемо самі на дзвінку. Опишіть задачу, і ми почнемо зі старту: узгодимо вхідні дані та запустимо роботи.
