LVM. Управление Логическими Томами

Введение

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

1. Размер создаваемой единицы хранения данных ограничен размером физического диска. (или RAID-массива, что немногим лучше)


2. Ограничены возможности управления хранилищем.
   


3. Отсутствует возможность он-лайн увеличения хранилища.
   


4. Отсутствуют встроенные возможности обеспечения избыточности (здесь мы имеем ввиду средства разбиения, а не Linux software RAID).
   


5. Отсутствует гибкость проведения он-лайн архивирования системы с динамично меняющимися данными.
   


6. Сложности с динамическим именованием устройств, хотя они и несколько обходятся с помощью UDEV и монтирования по меткам.
   

Все эти (а на самом деле не только эти) проблемы решены в системе, получившей название LVM (Logical Volume Management), которая уже давно является частью "Ванильного" ядра Linux. Эта система делает управление данными под Linux "просто сказкой". Если вы еще не знакомы с ней - самое время. Как обычно, все примеры приведены для системы RHEL5, но, скорее всего, с минимальными изменениями будут работать в других дистрибутивах.

Условные обозначения

1. Физический том (Physical Volume, или PV) - специальным образом отформатированное блочное устройство. Может быть как диском целиком, так и партицией, MD-устройством и т.д.
   


2. Логическая группа (Volume Group, или VG) - по сути "пул ресурсов". Имеет логическое и физическое представление. С физической точки зрения является объединением физических томов, с логической точки зрения является "емкостью", из которой "разливаются" логические тома.
   


3. Логический том (Logical Volume, или LV) - собственно логическая "партиция", расположенная на логической группе.
   

Основы практической работы

Работает все это следующим образом. Физические партиции форматируются в физические тома, например вот так:

 # pvcreate /dev/sda

После команды pvcreate могут вообще говоря следовать несколько блочных устройств. В этом случае все они будут отформатированы как PV. Затем следует объединить физические тома в логические группы. Для начала мы сделаем группу, состоящую только из одного PV:

 # vgcreate -s 32M vg0 /dev/sda

По сути, единственный актуальный параметр - это так называемый Physical Extent Size. Он определяет "квант" места, то есть единицу, до которой округляются все размеры логических томов. По сути Extent - это "клеточка", в которую "разлинована" ваша логическая группа.
После того, как мы сделали логическую группу, время создать логические тома:

 # lvcreate -L10G -n lvol vg

Последняя команда создает логический том в группе vg0. Она имеет множество опций, самые важные, впрочем, это -L РАЗМЕР -n ИМЯ. Возможно также задать политику расположения (аллокации) логических экстентов на физических, сделать LV "зеркалируемым" или "черезполосным" (Stripped - аналог RAID0).
Теперь самое время отформатировать логический том нашей любимой файловой системой EXT3:

 # mkfs.ext3 /dev/vg0/lvol

Обычно в Red Hat Enterprise Linux симлинки на логические тома доступны по пути /dev/[лог. группа]/[лог. том].
Допустим, что позднее мы добавляем в систему еще одно блочное устройство /dev/sdb. Причем хотим не просто добавить, а использовать его как "расширение" уже имеющегося хранилища, желательно в рамках той же файловой системы и без остановки приложений. Делается это следующим образом: форматируем новое устройство как физизческий том:

 # pvcreate /dev/sdb

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

 # vgextend vg0 /dev/sdb

Расширяем логический том, добавляя, например, еще 10Gb места:

 # lvextend -L +10G /dev/vg0/lvol

После чего осталось лишь расширить файловую систему на устройстве. К счастью для нас файловая система Ext3 (как впрочем и GFS) поддерживает online resize в большую сторону.

 # resize2fs /dev/vg0/lvol.

вполне могут располагаться на разных физических дисках. В итоге размер физического устройства не является причиной не иметь разделы большего размера. =) И при этом оставаться чрезвычайно гибким в управлении хранением данных.

Принципы устройства и прочие возможности

Теперь вернемся к теории и рассмотрим, как же это работает, и какие выгоды теоретически достижимы. Принцип устройства логических томов очень похож на принципы устройства виртуальной памяти в современных ОС. Дисковое пространство "нарезается" на экстенты. Далее логическим экстентам ставятся в соответствие физические, в соответствие с политикой аллокации. То есть весь концепт логического управления томами идейно - не более чем игра с соответствиями логических и физических единиц.

Допустим, каждому выделяемому логическому экстенту ставятся в соответствие 2 физических, убеждаясь при этом, что они расположены на разных физических томах. Получается естественный метод "зеркалирования", то есть функциональность RAID1. Это все просто и интересно, но не самое оригинальное и не это самое прекрасное в LVM.

Прекрасно то, что можно, не прерывая доступа к данным, "передвинуть" занятые физические экстенты на другие физические тома, тем самым освободив физический драйв от данных. Как вам перспектива замены жестких дисков под системным разделом в процессе работы системы (убедитесь, что ваши HDD поддерживают HotPlug =))) )?

Прекрасно то, что LVM "собирается" каждый раз по UUID-идентификаторам, которые расположены на самих разделах. LVM не зависит от порядка обнаружения SCSI-устройств, моделей именования устройств и прочих мелочей.

Наконец, LVM поддерживает технологию Snapshots. Эта технология крайне напоминает технологию COW (Copy-on-Write, копирования при записи), используемую в linux при создании новых процессов. При создании Snapshot'а логического тома все логические "клеточки" созданного тома-снапшота ссылаются на те же самые физические "клеточки" блочных устройств, что и «клеточки» исходного тома. Это означает, что одни и те же данные доступны по двум логическим именам. Это же, кстати, делает процесс создания снапшота любого размера практически мгновенным. При изменении одной из "копий" данных логические ячейки разносятся. Это позволяет двум логическим томам использовать совместно неизменяемую часть данных, поддерживая независимо только различающуюся часть.

Такой подход значительно экономит ресурсы диска, но это не главное. Главное – что со снапшота очень удобно производить резервное копирование файловых систем, содержащих динамично изменяющиеся данные (например, данные СУБД). Алгоритм прост:

1. Создаем снапшот, "замораживая" состояние логического тома для резервного копирования. При этом мы не блокируем исходный LV, приложения могут продолжать работать и изменять данные на нем.
   
2. Спокойно делаем резервную копию со снапшота.
   
3. Уничтожаем снапшот и продолжаем работу как ни в чем ни бывало.
   

Заключение

Тут и сказочке конец. Можно еще добавить, что Red Hat предоставляет довольно удобный графический инструмент для управления LVM (system-config-lvm), который позволяет делать все описанное несколько быстрее. А самое интересное - большинство возможностей LVM уже давно доступно и в кластерном варианте (CLVM - Cluster Logical Voume Management). Но об этом в другой раз.