В Linux, Диспетчер логических томов (LVM ) - это каркас устройства, который обеспечивает управление логическими томами для Linux. ядро. Большинство современных дистрибутивов Linux поддерживают LVM до такой степени, что могут иметь свои корневые файловые системы на логическом томе.
Хайнц Мауэльсхаген написал исходный код LVM на 1998 г., когда он работал в Sistina Software, принимая его основные рекомендации по дизайну от менеджера томов HP-UX.
Содержание
- 1 Использует
- 2 Характеристики
- 2.1 Базовая функциональность
- 2.2 Расширенная функциональность
- 2.3 RAID
- 2.4 Высокая доступность
- 2.5 Политика распределения групп томов
- 3 Реализация
- 4 См. Также
- 5 Ссылки
- 6 Дополнительная литература
Использование
LVM используется для следующих целей:
- Создание отдельных логических томов из нескольких физических томов или целых жестких дисков (несколько аналогичен RAID 0, но больше похож на JBOD ), позволяющий динамически изменять размер тома.
- Управление большими фермами жестких дисков, позволяя добавлять и заменять диски без простои или перебои в обслуживании в сочетании с горячая замена.
- В небольших системах (например, настольных компьютерах), вместо того, чтобы во время установки оценивать размер раздела, LVM позволяет легко изменять размер файловых систем по мере необходимости.
- Выполнение согласованного резервного копирования путем создания моментальных снимков логических томов.
- Шифрование нескольких физических разделов с помощью одного пароля.
LVM можно рассматривать как тонкий программный слой поверх жестких дисков и разделов, который создает абстракцию непрерывности и простоты использования для управления заменой, перераспределением жестких дисков и резервным копированием.
Характеристики
Различные элементы LVM
Базовая функциональность
- Размер групп томов (VG) можно изменять в режиме онлайн, поглощая новые физические тома (PV) или удаляя существующие.
- Размер логических томов (LV) можно изменить в оперативном режиме путем объединения экстентов на них или усечения их экстентов.
- LV можно перемещать между PV.
- Создание доступных только для чтения моментальных снимков логических томов (LVM1) с использованием функции копирования при записи (CoW) или моментальных снимков чтения / записи (LVM2)
- Группы групп могут быть разделены или объединяются на месте, пока ни один LV не перекрывает разделение. Это может быть полезно при переносе целых LV в автономное хранилище или из него.
- LVM-объекты могут быть помечены для удобства администрирования.
- VG и LV можно сделать активными по мере того, как базовые устройства становятся доступными через использование демона
lvmetad.
Расширенная функциональность
- Гибридные тома могут быть созданы с использованием цели dm-cache, что позволяет использовать одно или несколько устройств быстрого хранения, например как флэш-накопители SSD, чтобы действовать как кеш для одного или нескольких более медленных жестких дисков.
- Тонко выделенные LV могут быть выделены из пула.
- В более новых версиях устройства сопоставления LVM интегрирован с остальным устройством сопоставления устройств в достаточной степени, чтобы игнорировать отдельные пути, которые поддерживают устройство dm-multipath, если
devices / multipath_component_detection = 1устанавливается в lvm.conf. Это предотвращает активацию томов LVM по отдельному пути вместо устройства с несколькими путями.
RAID
- LV могут быть созданы для включения функций RAID, включая RAID 1, 5 и 6.
- Целые LV или их части могут быть распределены по нескольким PV, аналогично RAID 0.
- Внутреннее устройство RAID 1 (PV) может быть настроено как «преимущественно для записи», что позволяет избежать чтения с таких устройств без необходимости.
- Скорость восстановления можно ограничить с помощью
lvchange --raidmaxrecoveryrateи lvchange --raidminrecoveryrateдля поддержания приемлемой производительности ввода-вывода при восстановлении LV, который включает RAID.
Высокая доступность
LVM также работает в общем хранилище кластере, в котором диски, содержащие PV, используются совместно несколькими хост-компьютерами, но может потребоваться дополнительный демон для посредничества доступ к метаданным посредством блокировки.
- CLVM
- A распределенный диспетчер блокировок используется для управления одновременным доступом к метаданным LVM. Когда узлу кластера необходимо изменить метаданные LVM, он должен получить разрешение от своего локального
clvmd, который находится в постоянном контакте с другими демонами clvmdв кластере и может сообщить о своем желании получить блокировку для определенного набора объектов. - HA-LVM
- Поддержка кластера остается за приложением, обеспечивающим функцию высокой доступности. Что касается LVM, HA-LVM может использовать CLVM в качестве механизма блокировки или может продолжать использовать блокировку файлов по умолчанию и уменьшать «коллизии», ограничивая доступ только к тем объектам LVM, которые имеют соответствующие теги. Поскольку это более простое решение позволяет избежать конфликта, а не смягчить его, одновременный доступ запрещен, поэтому HA-LVM считается полезным только в активно-пассивных конфигурациях.
- lvmlockd
- По состоянию на 2017 год стабильный Компонент LVM, предназначенный для замены
clvmd, делая блокировку объектов LVM прозрачной для остальной части LVM, не полагаясь на распределенный менеджер блокировок. В 2016 году он получил массовое развитие.
Описанные выше механизмы решают только проблемы с доступом LVM к хранилищу. Файловая система, выбранная для размещения поверх таких LV, должна либо поддерживать кластеризацию сама по себе (например, GFS2 или VxFS ), либо она должна монтироваться только одним узлом кластера в любое время. (например, в активно-пассивной конфигурации).
Политика распределения групп томов
Группы LVM должны содержать политику распределения по умолчанию для новых томов, созданных из нее. Позже это можно изменить для каждого LV с помощью команды lvconvert -Aили на самом VG с помощью vgchange --alloc. Чтобы свести к минимуму фрагментацию, LVM сначала попытается применить самую строгую политику (непрерывную), а затем перейдет к наиболее либеральной политике, определенной для объекта LVM, до тех пор, пока распределение не будет окончательно успешным.
В конфигурациях RAID почти все политики применяются к каждой ветви изолированно. Например, даже если LV имеет политику привязки, расширение файловой системы не приведет к тому, что LVM будет использовать PV, если он уже используется одной из других ветвей в настройке RAID. LV с функцией RAID будут помещать каждую ветвь в разные PV, делая другие PV недоступными для любой другой ветви. Если бы это был единственный доступный вариант, расширение LV не удалось бы. В этом смысле логика привязки будет применяться только к расширению каждой из отдельных ветвей массива.
Доступны следующие политики распределения:
- Смежный - принудительно устанавливает все LE в данном LV как смежные и упорядоченные. Это устраняет фрагментацию, но значительно снижает возможность расширения LV.
- Cling - принудительное выделение новых LE только на PV, которые уже используются LV. Это может помочь смягчить фрагментацию, а также снизить уязвимость определенных LV в случае выхода устройства из строя, за счет снижения вероятности того, что другие LV также имеют экстенты на этом PV.
- Нормальный - подразумевает почти неизбирательный выбор PE, но он будет пытаться удерживать параллельные ветви (например, в конфигурации RAID) от совместного использования физического устройства.
- Anywhere - не накладывает никаких ограничений. Очень рискованно при настройке RAID, поскольку игнорируются требования изоляции, что ограничивает большинство преимуществ RAID. Для линейных томов это может привести к повышенной фрагментации.
Реализация
Базовый пример головки LVM
Внутренняя работа LVM версии 1. На этой схеме PE обозначает физический экстент.
Как правило, первый мегабайт каждого физического тома содержит в основном структуру с кодировкой ASCII, называемую «заголовком LVM» или «заголовком LVM». Первоначально голова LVM записывалась в первый и последний мегабайт каждого PV для резервирования (в случае частичного сбоя оборудования); однако позже он был изменен только на первый мегабайт. Заголовок каждого PV - это полная копия структуры всей группы томов, включая UUID всех других PV и LV, а также карту распределения от PE до LE. Это упрощает восстановление данных в случае потери PV.
В ядре Linux серии 2.6 LVM реализован в виде устройства отображения, простой блочной схемы для создания виртуальных блочных устройств и отображения их содержимого на другие блочные устройства. Это сводит к минимуму объем относительно трудно поддающегося отладке кода ядра, необходимого для реализации LVM. Он также позволяет совместно использовать свои службы перенаправления ввода-вывода с другими менеджерами томов (такими как EVMS ). Любой специфичный для LVM код помещается в его инструменты пользовательского пространства, которые просто манипулируют этими сопоставлениями и реконструируют свое состояние из метаданных на диске при каждом вызове.
Чтобы перевести группу томов в оперативный режим, инструмент «vgchange»:
- выполняет поиск PV во всех доступных блочных устройствах.
- Анализирует заголовок метаданных в каждом найденном PV.
- Вычисляет макеты всех видимых групп томов.
- Зацикливается на каждом логическом томе в группе томов, которая должна быть переведена в оперативный режим, и:
- Проверяет, есть ли у логического тома, который будет переведен в оперативный режим, все Отображаются PV.
- Создает новое пустое сопоставление устройства.
- Отображает его (с «линейной» целью) в области данных PV, к которым принадлежит логический том.
Кому переместить онлайн-логический том между PV в одной и той же группе томов, используйте инструмент «pvmove»:
- Создает новое пустое сопоставление устройства для места назначения.
- Применяет «зеркальное» целевое устройство к исходному и карты назначения. Ядро запустит зеркало в "деградированном" режиме и начнет копировать данные из оригинала в место назначения, чтобы синхронизировать их.
- Заменяет исходное отображение на место назначения, когда зеркало входит в синхронизацию, затем уничтожает оригинал.
Эти операции сопоставления устройств выполняются прозрачно, приложения или файловые системы не знают, что их базовое хранилище перемещается.
Предостережения
- До ядра Linux 2.6.31 барьеры записи не поддерживались (полностью поддерживаются в 2.6.33). Это означает, что гарантия от повреждения файловой системы, предлагаемая журналируемыми файловыми системами, такими как ext3 и XFS, была аннулирована при некоторых обстоятельствах.
- По состоянию на 2015 год., для LVM не существует интерактивной или автономной программы дефрагментации. Это несколько смягчается тем, что фрагментация происходит только при расширении тома и путем применения вышеупомянутых политик распределения. Однако фрагментация все еще происходит, и для ее уменьшения необходимо идентифицировать несмежные экстенты и вручную переставлять их с помощью команды
pvmove. - В большинстве конфигураций LVM только одна копия голова LVM сохраняется для каждого PV, что может сделать тома более уязвимыми для отказавших секторов диска. Это поведение можно изменить с помощью
vgconvert --pvmetadatacopies. Если LVM не может прочитать правильный заголовок, используя первую копию, он проверит конец тома на предмет резервного заголовка. Большинство дистрибутивов Linux хранят текущую резервную копию в / etc / lvm / backup, что позволяет вручную перезаписывать поврежденную головку LVM с помощью команды vgcfgrestore.
См. Также
Linux портал
Ссылки
Дополнительная литература
Различные элементы LVM 
Базовый пример головки LVM 
Внутренняя работа LVM версии 1. На этой схеме PE обозначает физический экстент. 
Linux портал 