Хайнц Мауэльсхаген написал оригинальный код LVM в 1998 году, когда он работал в Sistina Software , взяв за основу основные принципы проектирования менеджера томов HP-UX . [1]
Использует
LVM используется в следующих целях:
Создание отдельных логических томов из нескольких физических томов или целых жестких дисков (нечто похожее на RAID 0 , но больше похожее на JBOD ), позволяющее динамически изменять размер тома.
Управление большими массивами жестких дисков путем добавления и замены дисков без простоев или прерывания обслуживания в сочетании с возможностью горячей замены .
На небольших системах (например, на настольных компьютерах) вместо того, чтобы оценивать во время установки, насколько большим может быть раздел, LVM позволяет легко изменять размер файловых систем по мере необходимости.
Выполнение последовательного резервного копирования путем создания снимков логических томов.
Шифрование нескольких физических разделов одним паролем.
LVM можно рассматривать как тонкий программный слой поверх жестких дисков и разделов, который создает абстракцию непрерывности и простоты использования для управления заменой жестких дисков, переразбиением и резервным копированием.
Функции
Базовая функциональность
Размеры групп томов (VG) можно изменять в режиме онлайн, поглощая новые физические тома (PV) или удаляя существующие.
Размеры логических томов (LV) можно изменять в режиме онлайн, объединяя с ними экстенты или усекая их экстенты.
LV можно перемещать между PV.
Создание моментальных снимков логических томов, доступных только для чтения (LVM1), с использованием функции копирования при записи (CoW) [6] или моментальных снимков, доступных для чтения/записи (LVM2)
VGs можно разделять или объединять на месте, пока ни один LV не охватывает разделение. Это может быть полезно при миграции целых LV в или из автономного хранилища.
Объекты LVM могут быть помечены тегами для удобства администрирования. [7]
VG и LV могут быть активированы, когда базовые устройства станут доступны с помощью демона lvmetad. [8]
Расширенная функциональность
Гибридные тома могут быть созданы с использованием цели dm-cache , которая позволяет одному или нескольким быстрым устройствам хранения данных, таким как твердотельные накопители на основе флэш-памяти , выступать в качестве кэша для одного или нескольких более медленных жестких дисков . [9]
Тонко распределенные логические тома могут быть выделены из пула. [10]
В более новых версиях device mapper LVM достаточно интегрирован с остальной частью device mapper, чтобы игнорировать отдельные пути, которые поддерживают устройство dm-multipath, если devices/multipath_component_detection=1установлено в lvm.conf. Это не позволяет LVM активировать тома на отдельном пути вместо устройства multipath. [11]
РЕЙД
LV могут быть созданы с включением функциональности RAID , включая RAID 1 , 5 и 6. [12 ]
Целые логические тома или их части могут быть распределены по нескольким физическим томам, аналогично RAID 0 .
Внутреннее устройство RAID 1 (PV) можно настроить как «в основном для записи», в результате чего чтение с таких устройств будет производиться только в случае необходимости. [13]
Скорость восстановления можно ограничить с помощью lvchange --raidmaxrecoveryrateи lvchange --raidminrecoveryrateдля поддержания приемлемой производительности ввода-вывода при восстановлении логического тома, включающего функциональность RAID.
Высокая доступность
LVM также работает в кластере с общим хранилищем , в котором диски, содержащие физические тома, совместно используются несколькими хост-компьютерами, но может потребоваться дополнительный демон для посредничества в доступе к метаданным с помощью определенной формы блокировки.
КЛВМ
Распределенный менеджер блокировок используется для посредничества в одновременных доступах к метаданным LVM. Всякий раз, когда узлу кластера необходимо изменить метаданные LVM, он должен получить разрешение от своего локального clvmd, который находится в постоянном контакте с другими clvmdдемонами в кластере и может сообщать о желании получить блокировку на определенный набор объектов.
HA-LVM
Осведомленность о кластере остается за приложением, обеспечивающим функцию высокой доступности. Что касается LVM, HA-LVM может использовать CLVM в качестве механизма блокировки или продолжать использовать блокировку файлов по умолчанию и уменьшать «коллизии», ограничивая доступ только теми объектами LVM, которые имеют соответствующие теги. Поскольку это более простое решение позволяет избежать конкуренции, а не смягчить ее, одновременный доступ не допускается, поэтому HA-LVM считается полезным только в активно-пассивных конфигурациях.
lvmlockd
По состоянию на 2017 год [update]— стабильный компонент LVM, который предназначен для замены, clvmdделая блокировку объектов LVM прозрачной для остальной части LVM, не полагаясь на распределенный менеджер блокировок. [14] Он получил широкое развитие в 2016 году. [15]
Описанные выше механизмы решают только проблемы с доступом LVM к хранилищу. Файловая система, выбранная для размещения поверх таких LV, должна либо сама поддерживать кластеризацию (например, GFS2 или VxFS ), либо она должна монтироваться только одним узлом кластера в любой момент времени (например, в конфигурации «активный-пассивный»).
Политика распределения групп томов
Группы LVM VG должны содержать политику распределения по умолчанию для новых томов, созданных из них. Позже ее можно изменить для каждого LV с помощью lvconvert -Aкоманды или на самой группе VG с помощью vgchange --alloc. Чтобы минимизировать фрагментацию, LVM сначала попытается применить самую строгую политику (непрерывную), а затем перейдет к наиболее либеральной политике, определенной для объекта LVM, пока распределение не будет успешно выполнено.
В конфигурациях RAID почти все политики применяются к каждой ноге изолированно. Например, даже если LV имеет политику cling , расширение файловой системы не приведет к использованию LVM PV, если он уже используется одной из других ног в настройке RAID. LV с функциональностью RAID поместят каждую ногу на разные PV, сделав другие PV недоступными для любой другой данной ноги. Если бы это был единственный доступный вариант, расширение LV не удалось бы. В этом смысле логика, лежащая в основе cling , будет применяться только к расширению каждой из отдельных ног массива.
Доступные политики распределения:
Contiguous – заставляет все LE в данном LV быть смежными и упорядоченными. Это устраняет фрагментацию, но значительно снижает расширяемость LV.
Cling – заставляет новые LE выделяться только на PV, которые уже используются LV. Это может помочь смягчить фрагментацию, а также снизить уязвимость конкретных LV в случае выхода устройства из строя, уменьшая вероятность того, что другие LV также имеют экстенты на этом PV.
Нормальный — подразумевает практически беспорядочный выбор PE, но при этом будет предпринята попытка не допустить совместного использования физического устройства параллельными ветвями (например, ветвями RAID-массива).
Anywhere – не накладывает никаких ограничений. Очень рискованно в конфигурации RAID, так как игнорирует требования изоляции, подрывая большинство преимуществ RAID. Для линейных томов это может привести к увеличению фрагментации.
Выполнение
Обычно первый мегабайт каждого физического тома содержит в основном закодированную в ASCII структуру, называемую «заголовком LVM» или «головой LVM». Первоначально голова LVM записывалась в первый и последний мегабайт каждого PV для избыточности (в случае частичного отказа оборудования); однако позже это было изменено на только первый мегабайт. Заголовок каждого PV представляет собой полную копию макета всей группы томов, включая UUID всех других PV и LV, а также карту распределения PE в LE . Это упрощает восстановление данных в случае потери PV.
В серии 2.6 ядра Linux LVM реализован в терминах device mapper , простой схемы на уровне блоков для создания виртуальных блочных устройств и отображения их содержимого на другие блочные устройства. Это минимизирует объем относительно сложного для отладки кода ядра, необходимого для реализации LVM. Это также позволяет использовать его службы перенаправления ввода-вывода совместно с другими менеджерами томов (такими как EVMS ). Любой код, специфичный для LVM, выводится в его инструменты пользовательского пространства, которые просто манипулируют этими отображениями и восстанавливают их состояние из метаданных на диске при каждом вызове.
Чтобы перевести группу томов в режим онлайн, используйте инструмент «vgchange»:
Поиск фотоэлектрических модулей во всех доступных блочных устройствах.
Анализирует заголовок метаданных в каждом найденном PV.
Вычисляет макеты всех видимых групп томов.
Выполняет цикл по каждому логическому тому в группе томов, который необходимо перевести в режим онлайн, и:
Проверяет, видны ли все физические тома логического тома, который необходимо подключить.
Создает новое пустое сопоставление устройств.
Отображает его (с «линейной» целью) на области данных физических томов, к которым принадлежит логический том.
Чтобы переместить подключенный логический том между физическими томами в одной группе томов, используйте инструмент «pvmove»:
Создает новое пустое сопоставление устройств для места назначения.
Применяет цель "зеркала" к исходной и целевой картам. Ядро запустит зеркало в "деградированном" режиме и начнет копировать данные из оригинала в цель, чтобы синхронизировать их.
Заменяет исходное сопоставление на место назначения, когда зеркало синхронизируется, а затем уничтожает оригинал.
Эти операции по отображению устройств выполняются прозрачно, без того, чтобы приложения или файловые системы знали о перемещении их базового хранилища.
Предостережения
До ядра Linux 2.6.31 [16] барьеры записи не поддерживались (полностью поддерживаются в 2.6.33). Это означает, что гарантия от повреждения файловой системы, предлагаемая журналируемыми файловыми системами , такими как ext3 и XFS, при некоторых обстоятельствах отменялась. [17]
По состоянию на 2015 год [update]для LVM не существует онлайн- или офлайн-программы дефрагментации. Это несколько смягчается тем, что фрагментация происходит только при расширении тома и применении вышеупомянутых политик распределения. Однако фрагментация все еще происходит, и если ее нужно уменьшить, необходимо определить несмежную область и вручную переупорядочить ее с помощью команды pvmove. [18]
В большинстве установок LVM только одна копия заголовка LVM сохраняется на каждом PV, что может сделать тома более восприимчивыми к сбою секторов диска. Это поведение можно переопределить с помощью vgconvert --pvmetadatacopies. Если LVM не может прочитать правильный заголовок с помощью первой копии, он проверит конец тома на наличие резервного заголовка. Большинство дистрибутивов Linux сохраняют работающую резервную копию в /etc/lvm/backup, что позволяет вручную перезаписывать поврежденный заголовок LVM с помощью vgcfgrestoreкоманды.
Патент США 5129088, Аусландер и др., «Метод обработки данных для создания виртуальных дисков из несмежных групп логически смежных адресуемых блоков запоминающего устройства с прямым доступом», выдан 7 июля 1992 г. (фундаментальный патент).
"RedHat Linux: Что такое Logical Volume Manager или LVM?". techmagazinez.com . 6 августа 2013 г. Архивировано из оригинала 10 августа 2013 г. Получено 4 сентября 2013 г.
"Страница ресурсов LVM2". sourceware.org . 8 июня 2012 г. . Получено 4 сентября 2013 г. .
"Как: установить Ubuntu на разделы LVM". Debuntu.org . 28 июля 2007 г. . Получено 4 сентября 2013 г. .
«Диспетчер логических томов». markus-gattol.name . 13 июля 2013 г.