Настройка LVM: гибкое управление дисками, PV, VG, снапшоты

Настройка LVM: где ломается статичная разметка дисков

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

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

Настройка LVM убирает саму причину: физические тома (PV) собираются в группу (VG), а логические тома (LV) нарезаются под задачи, а не под геометрию конкретного диска. Расширение тома и файловой системы идёт на работающей системе, без размонтирования и перезагрузки. Добавили носитель — он вошёл в группу, и место стало доступно всем томам сразу.

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

Что даёт гибкое управление дисками и томами

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

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

Настройка LVM: сравнение подходов и режимов

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

Схемы и их пределы

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

Порядок внедрения: от аудита дисков до передачи

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

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

Итог — предсказуемая раскладка и воспроизводимые операции вместо разовых правок по факту сбоя.

Что передаём команде после настройки томов

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

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

Кейс: расширение раздела на боевом сервере без простоя

Что было

На боевом сервере раздел под данные подошёл к 95% — обновление сервиса откладывали, потому что прежний сценарий требовал остановки, копирования и переразметки. В таком окне любая ошибка оборачивалась откатом из резервной копии и часами недоступности, а перенос данных без остановки казался невыполнимым.

Что изменили и что получили на выходе

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

Заполненность раздела снизилась с 95% до 40%, а окно работ — с четырёх часов плановой остановки до пяти минут без прерывания сервиса. Возврат к прежнему состоянию из снапшота занимает единицы минут вместо восстановления всей копии.

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

Чем тонкие тома отличаются от обычных и когда нужны снапшоты

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

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

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

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

Технические сомнения, которые стоит снять до старта

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

Что произойдёт при отказе физического диска?

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

Как это уживается с виртуальными машинами и облачными дисками?

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

Как проверяем перед боевым запуском?

На стенде с той же топологией прогоняем рост тома, откат со снапшота и сценарий выдёргивания диска. Сверяем состояние групп и томов до и после, отдельно проверяем, что загрузка проходит без ручного вмешательства.