Вопрос или проблема
Я знаю, что могу указать точки монтирования в fstab, используя путь (например, /dev/sda1 или /dev/mapper/myvg-logicalVolume1) или метку файловой системы (LABEL=root), или UUID (UUID=1234-5678-...).
Я вижу явное преимущество с точки зрения надежности в использовании UUID для “классических” разделов, таких как /dev/sda1, поскольку если вы перепартируете диск или добавите больше дисков, некоторые из ваших разделов могут быть распознаны под другим именем, хотя монтирование по UUID усложняет определение того, в каком разделе/ЛВ ваши данные хранятся.
Но при использовании LVM я думаю, что система LVM сама управляет обнаружением своих дисков/разделов, и не важно, если какой-то PV теперь называется по-другому после манипуляций с разделами/дисками. Таким образом, не будет никакой разницы (говоря о надежности) в монтировании по UUID или по пути, как /dev/mapper/vg-lv, и последний вариант более ясен.
Это верно?
Это верно.
Монтирование по UUID является одним из способов обойти старую проблему изменения имен разделов, таких как /dev/sda1, если вы добавите другой диск.
device-mapper будет постоянно именовать ваши LVM-тома в /dev/mapper/vg-lv, так что вы можете полагаться на это абстрагированное имя, которое останется неизменным, независимо от изменений в базовом хранилище.
То же самое касается устройств, управляемых device-mapper-multipath, как без использования удобочитаемых имен (/dev/mapper/WWID), так и с использованием удобочитаемых имен и файла привязок (/dev/mapper/mpath0).
Вы можете столкнуться с проблемами, если захотите переименовать группу томов или логический том позднее…. (lvrename или vgrename).
Независимо от причин, по которым вы переименовали vg или lv, это действие может повредить ваши монтирования и экспорты.
LVUUID остается постоянным при переименовании комманд vg и lv.
Может быть полезно использовать UUID только по этой причине, особенно если вы отвечаете за большое количество экспортов и монтирований.
В среде, где вы используете SAN-хранилище, этот подход является плохой идеей, так как UUID зависит от оборудования. Если вы выполняете полное резервное копирование на ленту и восстанавливаете на новом оборудовании, система не загрузится, поскольку все UUID теперь разные.
Ответ или решение
Когда речь заходит о монтировании логических томов (LV) в операционной системе Linux, пользователи часто сталкиваются с выбором между использованием UUID и путей, таких как /dev/mapper/vg-lv. Этот выбор может иметь значительное влияние на надежность системы, особенно в сложных инфраструктурах. Давайте более подробно рассмотрим преимущества и недостатки каждого из этих подходов с точки зрения теории, примеров и практической реализации.
Теория
UUID
UUID (Universally Unique Identifier) предоставляет уникальное идентифицирующее значение для каждого раздела или логического тома. Это уникальное значение присваивается во время создания файловой системы и остаётся неизменным, пока сама файловая система существует. Использование UUID в конфигурации файлов, таких как /etc/fstab, предоставляет следующие преимущества:
-
Независимость от переприсвоения имен устройств: Имя устройства, например /dev/sda1, может измениться в зависимости от порядка обнаружения устройств при загрузке системы. Однако UUID остаётся постоянным, что обеспечивает надежное монтирование.
-
Независимость от аппаратных изменений: Если вы добавите или удалите диски, UUID останется прежним, что минимизирует риск некорректного монтирования.
-
Совместимость: UUID работает с большинством современных систем управления томами, включая LVM и это позволяет легко интегрировать их в инфраструктуру системы.
Пути в /dev/mapper
В среде LVM (Logical Volume Manager), устройства представлены в виде /dev/mapper/vg-lv. Эти имена обеспечивают более дружественный интерфейс и стабильность, так как LVM управляет логическими томами на абстрагированном уровне:
-
Удобочитаемость: Путевое имя, содержащее названия группы томов и логического тома (например, /dev/mapper/myvg-mylv), является более читаемым по сравнению с UUID и легко указывает на расположение данных в управляемой среде.
-
Статичность в контексте LVM: Поскольку имена в /dev/mapper остаются неизменными при добавлении новых дисков или изменении партиций, они представляют собою надежный метод для монтирования в большинстве случаев использования LVM.
-
Simplicity in Administration: Управление томами становится более простым с точки зрения человеческого восприятия и администрирования благодаря их структурированным именам.
Примеры
Пример с использованием UUID:
UUID=123e4567-e89b-12d3-a456-426614174000 /mnt/ext4 ext4 defaults 0 2Этот способ обеспечивает стабильное монтирование независимо от изменений в конфигурации оборудования.
Пример с использованием путей в /dev/mapper:
/dev/mapper/myvg-mylv /mnt/lvm ext4 defaults 0 2Этот метод чтение-совместим и интуитивно понятен для системного администратора, работающего с LVM.
Практическая реализация
В реальных сценариях, где стабильно и надежно работают информационные системы, решение, какой метод монтирования выбрать, зависит от специфических требований и инфраструктуры:
-
Инфраструктура на базе ЛВС и SAN: В SAN-средах рекомендуется быть осторожным с использованием UUID, поскольку аппаратные аспекты могут повлиять на уникальность UUID при переносе на новое оборудование. Вместо этого использование /dev/mapper может стать более разумным выбором, так как он менее подвержен зависимостям от переприсвоения согласно конфигурациям SAN.
-
Частые изменения в конфигурации: В средах, где изменение конфигурации и структурирование хранения происходит часто, использование UUID может минимизировать риски связанных с этим проблем монтирования. Ваши UUID останутся неизменными, даже если вы переименовываете группы томов или логические тома.
-
Организации с высокой доступностью и большим количеством системных администраций: В таких сценариях использование UUID может быть предпочтительной практикой, чтобы избежать ошибок, связанных с человеческим фактором, так как изменения в именах /dev/mapper/vg-lv не будут влиять на монтирование.
В заключение, выбор между UUID и путями может зависеть от многих факторов, включая специфичности вашего рабочего окружения, требований к стабильности и читаемости, а также сложности вашей IT инфраструктуры. Принятие осознанного решения на основе понимания теоретических различий и потенциалов применения сделает вашу систему более устойчивой и управляемой.