Диспетчер логических томов (Linux) - Logical Volume Manager (Linux)

Диспетчер логических томов

Оригинальный автор (ы)	Хайнц Мауэльсхаген
Стабильный выпуск	2.03.12  / 7 мая 2021 г . ; 2 месяца назад ( 7 мая 2021 г. )
Репозиторий	исходное ПО .org / git /? p = lvm2 .git
Написано в	C
Операционная система	Linux , Netbsd
Лицензия	GPLv2
Веб-сайт	исходное ПО .org / lvm2 /

В Linux , Logical Volume Manager ( LVM ) является картограф устройства структуры , которая обеспечивает логическое управление томами для ядра Linux . Большинство современных дистрибутивов Linux поддерживают LVM до такой степени, что могут иметь свои корневые файловые системы на логическом томе .

Хайнц Мауэльсхаген написал исходный код LVM в 1998 году, когда он работал в Sistina Software , взяв его основные принципы проектирования от менеджера томов HP-UX .

Использует

LVM используется для следующих целей:

• Создание отдельных логических томов из нескольких физических томов или целых жестких дисков (несколько похоже на RAID 0 , но больше похоже на JBOD ), позволяющее динамически изменять размер тома.
• Управление большими фермами жестких дисков, позволяя добавлять и заменять диски без простоев или прерывания обслуживания в сочетании с горячей заменой .
• В небольших системах (например, настольных компьютерах) вместо того, чтобы во время установки оценивать размер раздела, LVM позволяет легко изменять размер файловых систем по мере необходимости.
• Выполнение согласованного резервного копирования путем создания моментальных снимков логических томов.
• Шифрование нескольких физических разделов одним паролем.

LVM можно рассматривать как тонкий программный слой поверх жестких дисков и разделов, который создает абстракцию непрерывности и простоту использования для управления заменой, перераспределением жестких дисков и резервным копированием.

Функции

Различные элементы LVM

Базовая функциональность

• Размер групп томов (VG) можно изменять онлайн, поглощая новые физические тома (PV) или удаляя существующие.
• Размер логических томов (LV) можно изменять в режиме онлайн, объединяя экстенты на них или обрезая их.
• LV можно перемещать между PV.
• Создание моментальных снимков логических томов (LVM1) только для чтения, использование функции копирования при записи (CoW) или моментальных снимков чтения / записи (LVM2)
• Группы VG могут быть разделены или объединены на месте при условии, что LV не охватывает разделение. Это может быть полезно при переносе целых LV в автономное хранилище или из него.
• Объекты LVM могут быть помечены тегами для удобства администрирования.
• Группы VG и LV могут быть активированы по мере того, как базовые устройства становятся доступными с помощью lvmetadдемона.

Расширенный функционал

• Гибридные тома могут быть созданы с использованием цели dm-cache , которая позволяет одному или нескольким быстрым устройствам хранения, например твердотельным накопителям на основе флэш- памяти , выступать в качестве кеша для одного или нескольких более медленных жестких дисков .
• Логические тома с тонкой подготовкой можно выделить из пула.
• В более новых версиях устройства сопоставления устройств 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

Распределенные менеджер блокировки используются для брокера одновременного доступа 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:

1. Ищет PV во всех доступных блочных устройствах.
2. Анализирует заголовок метаданных в каждом найденном PV.
3. Вычисляет макеты всех видимых групп томов.
4. Зацикливается на каждом логическом томе в группе томов, который нужно перевести в оперативный режим, и:
   1. Проверяет, отображаются ли все PV логического тома, который нужно перевести в оперативный режим.
   2. Создает новое пустое сопоставление устройств.
   3. Отображает его (с «линейной» целью) на области данных PV, к которым принадлежит логический том.

Чтобы переместить онлайн-логический том между PV в одной группе томов, используйте инструмент «pvmove»:

1. Создает новое пустое сопоставление устройств для места назначения.
2. Применяет "зеркальную" цель к исходной и целевой картам. Ядро запустит зеркало в «деградированном» режиме и начнет копировать данные из оригинала в место назначения, чтобы синхронизировать их.
3. Заменяет исходное сопоставление на место назначения, когда зеркало синхронизируется, а затем уничтожает оригинал.

Эти операции сопоставления устройств выполняются прозрачно, приложения или файловые системы не знают, что их базовое хранилище перемещается.

Предостережения

• До ядра Linux 2.6.31 барьеры записи не поддерживались (полностью поддерживается в 2.6.33). Это означает, что гарантия от повреждения файловой системы, предлагаемая журналируемыми файловыми системами, такими как ext3 и XFS, при некоторых обстоятельствах была аннулирована.
• По состоянию на 2015 год для LVM не существует интерактивной или автономной программы дефрагментации. Это в некоторой степени смягчается тем, что фрагментация происходит только при расширении тома и путем применения вышеупомянутых политик распределения. Однако фрагментация все еще происходит, и для ее уменьшения необходимо идентифицировать несмежные экстенты и вручную переставлять с помощью pvmoveкоманды.
• В большинстве конфигураций LVM для каждого PV сохраняется только одна копия головки LVM, что может сделать тома более уязвимыми для отказавших секторов диска. Это поведение можно изменить с помощью vgconvert --pvmetadatacopies. Если LVM не может прочитать правильный заголовок, используя первую копию, он проверит конец тома на предмет резервного заголовка. Большинство дистрибутивов Linux хранят работающую резервную копию /etc/lvm/backup, которая позволяет вручную перезаписывать поврежденную головку LVM с помощью vgcfgrestoreкоманды.

Смотрите также

Рекомендации

дальнейшее чтение