Device mapper tools linux

Use the Device Mapper storage driver

Estimated reading time: 28 minutes

Device Mapper is a kernel-based framework that underpins many advanced volume management technologies on Linux. Docker’s devicemapper storage driver leverages the thin provisioning and snapshotting capabilities of this framework for image and container management. This article refers to the Device Mapper storage driver as devicemapper , and the kernel framework as Device Mapper.

For the systems where it is supported, devicemapper support is included in the Linux kernel. However, specific configuration is required to use it with Docker.

The devicemapper driver uses block devices dedicated to Docker and operates at the block level, rather than the file level. These devices can be extended by adding physical storage to your Docker host, and they perform better than using a filesystem at the operating system (OS) level.

Prerequisites

• devicemapper is supported on Docker Engine — Community running on CentOS, Fedora, SLES 15, Ubuntu, Debian, or RHEL.
• devicemapper requires the lvm2 and device-mapper-persistent-data packages to be installed.
• Changing the storage driver makes any containers you have already created inaccessible on the local system. Use docker save to save containers, and push existing images to Docker Hub or a private repository, so you do not need to recreate them later.

Configure Docker with the devicemapper storage driver

Before following these procedures, you must first meet all the prerequisites.

Configure loop-lvm mode for testing

This configuration is only appropriate for testing. The loop-lvm mode makes use of a ‘loopback’ mechanism that allows files on the local disk to be read from and written to as if they were an actual physical disk or block device. However, the addition of the loopback mechanism, and interaction with the OS filesystem layer, means that IO operations can be slow and resource-intensive. Use of loopback devices can also introduce race conditions. However, setting up loop-lvm mode can help identify basic issues (such as missing user space packages, kernel drivers, etc.) ahead of attempting the more complex set up required to enable direct-lvm mode. loop-lvm mode should therefore only be used to perform rudimentary testing prior to configuring direct-lvm .

Edit /etc/docker/daemon.json . If it does not yet exist, create it. Assuming that the file was empty, add the following contents.

See all storage options for each storage driver in the daemon reference documentation

Docker does not start if the daemon.json file contains badly-formed JSON.

Verify that the daemon is using the devicemapper storage driver. Use the docker info command and look for Storage Driver .

This host is running in loop-lvm mode, which is not supported on production systems. This is indicated by the fact that the Data loop file and a Metadata loop file are on files under /var/lib/docker/devicemapper . These are loopback-mounted sparse files. For production systems, see Configure direct-lvm mode for production.

Configure direct-lvm mode for production

Production hosts using the devicemapper storage driver must use direct-lvm mode. This mode uses block devices to create the thin pool. This is faster than using loopback devices, uses system resources more efficiently, and block devices can grow as needed. However, more setup is required than in loop-lvm mode.

After you have satisfied the prerequisites, follow the steps below to configure Docker to use the devicemapper storage driver in direct-lvm mode.

Warning: Changing the storage driver makes any containers you have already created inaccessible on the local system. Use docker save to save containers, and push existing images to Docker Hub or a private repository, so you do not need to recreate them later.

Allow Docker to configure direct-lvm mode

Docker can manage the block device for you, simplifying configuration of direct-lvm mode. This is appropriate for fresh Docker setups only. You can only use a single block device. If you need to use multiple block devices, configure direct-lvm mode manually instead. The following new configuration options are available:

Option	Description	Required?	Default	Example
dm.directlvm_device	The path to the block device to configure for direct-lvm .	Yes	В	dm.directlvm_device=»/dev/xvdf»
dm.thinp_percent	The percentage of space to use for storage from the passed in block device.	No	95	dm.thinp_percent=95
dm.thinp_metapercent	The percentage of space to use for metadata storage from the passed-in block device.	No	1	dm.thinp_metapercent=1
dm.thinp_autoextend_threshold	The threshold for when lvm should automatically extend the thin pool as a percentage of the total storage space.	No	80	dm.thinp_autoextend_threshold=80
dm.thinp_autoextend_percent	The percentage to increase the thin pool by when an autoextend is triggered.	No	20	dm.thinp_autoextend_percent=20
dm.directlvm_device_force	Whether to format the block device even if a filesystem already exists on it. If set to false and a filesystem is present, an error is logged and the filesystem is left intact.	No	false	dm.directlvm_device_force=true

Edit the daemon.json file and set the appropriate options, then restart Docker for the changes to take effect. The following daemon.json configuration sets all of the options in the table above.

See all storage options for each storage driver in the daemon reference documentation

Restart Docker for the changes to take effect. Docker invokes the commands to configure the block device for you.

Warning: Changing these values after Docker has prepared the block device for you is not supported and causes an error.

Configure direct-lvm mode manually

The procedure below creates a logical volume configured as a thin pool to use as backing for the storage pool. It assumes that you have a spare block device at /dev/xvdf with enough free space to complete the task. The device identifier and volume sizes may be different in your environment and you should substitute your own values throughout the procedure. The procedure also assumes that the Docker daemon is in the stopped state.

Identify the block device you want to use. The device is located under /dev/ (such as /dev/xvdf ) and needs enough free space to store the images and container layers for the workloads that host runs. A solid state drive is ideal.

Install the following packages:

RHEL / CentOS: device-mapper-persistent-data , lvm2 , and all dependencies

Ubuntu / Debian / SLES 15: thin-provisioning-tools , lvm2 , and all dependencies

Create a physical volume on your block device from step 1, using the pvcreate command. Substitute your device name for /dev/xvdf .

Warning: The next few steps are destructive, so be sure that you have specified the correct device!

Create a docker volume group on the same device, using the vgcreate command.

Create two logical volumes named thinpool and thinpoolmeta using the lvcreate command. The last parameter specifies the amount of free space to allow for automatic expanding of the data or metadata if space runs low, as a temporary stop-gap. These are the recommended values.

Convert the volumes to a thin pool and a storage location for metadata for the thin pool, using the lvconvert command.

Configure autoextension of thin pools via an lvm profile.

Specify thin_pool_autoextend_threshold and thin_pool_autoextend_percent values.

thin_pool_autoextend_threshold is the percentage of space used before lvm attempts to autoextend the available space (100 = disabled, not recommended).

thin_pool_autoextend_percent is the amount of space to add to the device when automatically extending (0 = disabled).

The example below adds 20% more capacity when the disk usage reaches 80%.

Apply the LVM profile, using the lvchange command.

Ensure monitoring of the logical volume is enabled.

If the output in the Monitor column reports, as above, that the volume is not monitored , then monitoring needs to be explicitly enabled. Without this step, automatic extension of the logical volume will not occur, regardless of any settings in the applied profile.

Double check that monitoring is now enabled by running the sudo lvs -o+seg_monitor command a second time. The Monitor column should now report the logical volume is being monitored .

If you have ever run Docker on this host before, or if /var/lib/docker/ exists, move it out of the way so that Docker can use the new LVM pool to store the contents of image and containers.

Источник

Настраиваем Device Mapper Multipathing в CentOS Linux 7.2 для FC HBA при подключении к СХД HP 3PAR 7200 (3PAR OS v. 3.2.2)

В этой заметке будет рассмотрен пример того, как настроить многоканальное ( Multipath ) подключение оптических хост-контроллеров (FC HBA) Emulex/QLogic, установленных в сервере на базе ОС CentOS Linux 7.2, к системе хранения данных (СХД) HP 3PAR 7200 (версия firmware 3PAR OS — 3.2.2). Для настройки multipath в CentOS мы будем использовать возможности модуля ядра Linux — dm-multipath (Device Mapper Multipath, DM Multipath).

Онлайн документация по DM Multipath, доступная на сайте CentOS.org по сути дублирует документацию с сайта RedHat и является уже устаревшей. Более актуальную версию (для 7 ветки RHEL) можно найти на сайте RedHat . Если с английским языком есть сложности, то для общего понимания первично можно заглянуть в переведённое на русский язык руководство для RHEL 6 .

Компоненты DM Multipath

Процитирую документацию для того, чтобы отразить основные компоненты DM Multipath:

• dm-multipath (модуль ядра) — Перенаправляет ввод-вывод и обеспечивает
  отказоустойчивость маршрутов и их групп.
• multipathd (служба) — Следит за маршрутами, инициализирует переключение групп маршрутов и позволяет изменять устройства интерактивно. Чтобы изменения в /etc/multipath.conf вступили в силу, необходим перезапуск этой службы.
• mpathconf (утилита) — Используется для настройки и активации многоканальных
  возможностей.
• multipath (утилита) — Возвращает список многоканальных устройств и позволяет их
  настроить. Запускается с помощью /etc/rc.sysinit или во время добавления блочного устройства при помощи udev.
• kpartx (утилита) — Создает многоканальные устройства для разделов DOS с DM Multipath. kpartx предоставляется в виде отдельного пакета и требуется для установки device-mapper-multipath.

Модуль ядра dm-multipath поставляется вместе с системой CentOS

Утилита multipath и служба multipathd входят в состав пакета device-mapper-multipath, который мы установим позже.

Порядок настройки

Базовый сценарий настройки DM Multipath подразумевает следующие шаги:

1. Установка пакета device-mapper-multipath.
2. Создание конфигурационного файла multipath.conf с помощью утилиты mpathconf и его редактирование (при необходимости).
3. Запуск службы multipathd.

Помимо этих действий мы выполним рекомендации данные производителем СХД. В нашем случае придётся взять на вооружение документ HPE 3PAR Red Hat Enterprise Linux and Oracle Linux Implementation Guide (emr_na-c04448818-9.pdf) , с учётом которого последовательность наших действий будет выглядеть следующим образом:

1. Тюнинг драйверов FC HBA
2. Зонирование фабрик SAN и СХД
3. Установка и настройка DM Multipath (3 шага базового сценария)
4. Разметка диска (опционально)

Тюнинг драйверов FC HBA

Документация рекомендует нам выполнить тюнинг драйверов хост-контроллеров с указанием конкретных предложенных параметров в файле /etc/modprobe.d/modprobe.conf с последующей пересборкой образа initramfs

Для контроллеров QLogic строка параметров тюнинга выглядит так:

Для контроллеров Emulex строка параметров тюнинга выглядит так:

Для контроллеров Brocade тюнинг выполняется отдельной командой:

Обратите внимание на то, что указанные опции драйвера справедливы только для прошивки 3PAR OS версии 3.1.1 и новее. Для старых версий 3PAR OS параметры будут несколько иные и их можно найти в ранее упомянутом документе.

В нашем случае используются только контроллеры QLogic и Emulex, поэтому сразу добавим параметры для обоих этих драйверов в файл /etc/modprobe.d/modprobe.conf (если файл в системе отсутствует, то его нужно создать):

Кстати, с помощью утилиты modinfo мы можем посмотреть краткое описание изменяемых параметров:

Теперь нужно пересобрать образ initramfs. Для этого сначала сделаем резервную копию текущего используемого образа для текущей версии ядра, затем вызовем команду пересборки нового образа, в процессе чего будет учтён добавленный нами файл modprobe.conf:

После того, как последняя команда отработает, перезагружаем сервер и убеждаемся в том, что система успешно загружается с новыми тюнингованными параметрами драйверов HBA. Для того, чтобы проверить то, что модуль с драйвером загружен именно с заданными нами параметрами можно использовать проверку файлов /sys/module/ /parameters/*

или же можно воспользоваться утилитой systool из пакета sysfsutils:

Зонирование фабрик SAN и СХД

В данный момент наш сервер ничего не видит через свой контроллер FC HBA, так как нам ещё нужно настроить зонирование на оптических коммутаторах (фабриках) SAN и СХД:

Для настройки зонирования нам потребуется информация о идентификаторах WWN. Идентифицировать контроллеры HBA в Linux можно разными способами. В частности, чтобы быстро узнать Node WWN, выполним:

Чтобы узнать Port WWN, выполним:

Дополнительные примеры идентификации FC HBA можно посмотреть в Вики-статье Как идентифицировать контроллеры FC HBA в CentOS Linux .

Настройку зонирования на оптических коммутаторах и СХД в данной заметке мы рассматривать не будем. Сделаю только одно важное замечание по настройке зонирования в СХД HP 3PAR 7200. При создании записи о хосте на СХД в поле Host OS выбираем наиболее близкую к нам ОС, таким образом, чтобы атрибут Persona был определён как 2-Generic-ALUA (согласно стр.12 используемого нами руководства это рекомендуемый вид для RHEL7).

Итак, предполагается, что зонирование сделано, и теперь наш сервере с CentOS 7.2 уже имеет доступ к дискам через HBA. Заставим систему обновить информацию о подключенных дисках методом описанным здесь :

После этого посмотрим, какие устройства видит наш сервер:

В нашем случае после зонирования SAN сервер увидел презентованный с 3PAR дисковый том (3PARdata Model: VV) доступный по 4 путям.

Установка и настройка DM Multipath

Устанавливаем пакет device-mapper-multipath

После установки нужно настроить основной конфигурационный файл /etc/multipath.conf , которого по умолчанию не существует. Чтобы создать этот файл в конфигурации «по умолчанию» можно воспользоваться утилитой mpathconf:

Без учёта комментариев, создаваемый файл multipath.conf по умолчанию будет иметь следующее содержимое:

Как я понял, до версии RHEL/CentOS 6 не существовало параметра автоматической настройки find_multipaths и поэтому устройства, подлежащие включению/исключению из механизма multipath, приходилось всегда прописывать в файле multipath.conf в ручную. В современной версии RHEL/CentOS всё несколько упрощено. Цитата по этому поводу из документации:

В Red Hat Enterprise Linux 6 появился новый способ настройки многоканальных устройств с
помощью параметра find_multipaths. Раньше устройства создавались для всех путей, не
внесенных в черный список. Теперь, если параметр find_multipaths имеет значение yes,
метаустройство будет создано только в одном из следующих случаев:
* Существует по крайней мере два пути с одним и тем же WWID, не указанных в списке
исключений.
* Пользователь создает устройство вручную с помощью multipath.
* Путь имеет тот же WWID что и созданное ранее метаустройство (даже если это
устройство в настоящий момент уже не существует). Раздел 4.2, «Секция blacklist»
объясняет, что делать, если многоканальные устройства были созданы, в то время как
параметр find_multipaths не был определен.

Поэтому, наверняка, в большинстве случаев можно оставить предложенный по умолчанию файл multipath.conf . Что ж, попробуем…

Выполняем запуск службы multipathd и после этого выполняем команду вывода информации о топологи multipath:

В нашем случае из вывода последней команды стало понятно, что, во-первых, не смотря на параметр find_multipaths yes, DM Multipath пытается обработать multipath для локального логического диска cciss/c0d0 с контроллера HP Smart Array P400i, на котором установлена сама CentOS 7.2 (это также хорошо видно в выводе команды multipath -v3), а во-вторых multipath с настройками по умолчанию таки смог собрать мультиканальное устройство используя все 4 пути до СХД:

Добавим регулярное выражение определяющее любые диски с контроллера Smart Array в секцию blacklist в конфигурационном файле multipath.conf .

Кстати довольно странно, что в уважаемых источниках, например здесь или здесь можно встретить пример неработающего регулярного выражения для определения дисков с контроллера Smart Array. Но наш вариант рабочий:

А чтобы более правильно настроить DM Multipath на работу СХД 3PAR, всё таки нам придётся воспользоваться точной настройкой файла multipath.conf в соответствии с рекомендацией из руководства HP, согласно которой, настройки конфигурации под хост ALUA Persona 2 (а мы помним, что именно этот тип выбран при создании записи о нашем сервере на СХД 3PAR) имеют свои особенности. В итоге результирующий файл в нашем случае примет следующий вид:

Для вступления в силу изменений конфигурационного файла выполним перезапуск службы multipathd:

Теперь снова проверим состояние multipath:

Теперь видно, что наше multipath-устройство работает с другими настройками, а предупреждений по поводу локального контроллера Smart Array нет.

Разметка диска (опционально)

Описанные в данном разделе действия по разметке multipath-диска являются опциональными, и приведены исключительно для примера. Предположим, что нам нужно создать раздел диска с файловой системой ext4 размером всего multipath-диска.

Как видно на предыдущем скриншоте, наш multipath-диск в системе доступен по 4 путям в виде равнозначных устройств /dev/sda , /dev/sdb , /dev/sdc , /dev/sdd . Выполнить разметку можно на любом из этих устройств, но нельзя выполнять эту операцию обращаясь к устройству как к multipath-диску через /dev/mapper/* (об этом в руководстве сделано отдельное замечание). Для разметки воспользуемся утилитой parted, все действия будем выполнять на любом из дисков, например /dev/sdd . Пошагово процедуру разметки диска с помощью parted я рассматривал в статье Вики , поэтом здесь приведу лишь последовательный набор команд:

В документации отдельное внимание обращается на то, что при создании раздела диска нужно выбрать оптимальную конфигурацию для 3PAR, а именно учесть то, что раздел должен начинаться с сектора 32768. Это нужно учесть, если для разметки диска вы используете утилиту fdisk, которая по умолчанию начальным сектором устанавливает 30876, что в последствии, как я понял, может отрицательно сказаться на производительности будущего дискового раздела в Linux. Поэтому я и использую утилиту parted, которая по умолчанию при создании раздела использует правильный, с точки зрения 3PAR, начальный сектор.

В случае, если вы всё же для создания раздела будете использовать утилиту fdisk, то вызывать её нужно с соответствующими ключами (пример взят из документации и мной не проверялся):

Далее созданный раздел диска нам нужно добавить к мультиканальным устройствам в /dev/mapper/ . Для этого используем утилиту kpartx и ID корневого multipath-диска. ID видно как в выводе утилиты multipath, так и собственно в каталоге /dev/mapper/

Выполним команду добавления раздела в /dev/mapper/ :

После этого появится новое multipath-устройство ( 360002ac000000000000000160000cec9p1 ), олицетворяющее собой ранее созданный нами раздел на корневом multipath-диске ( 360002ac000000000000000160000cec9 ).

Форматируем multipath-раздел в нужную нам файловую систему, например ext4:

Теперь пропишем в файл /etc/fstab информацию для автоматического монтирования multipath-раздела в точку монтирования /mnt/3par-vv1 . Для этого сначала узнаем UUID раздела:

Потом добавим информацию о монтировании в конец файла /etc/fstab

После этого перезагружаем сервер и убеждаемся в том, что конечный результата достигнут и multipath-раздел автоматически монтируется в точку монтирования /mnt/3par-vv1

Пробуем создать новый пустой файл в смонтированном в каталог разделе, проверяя тем самым возможность записи в этот каталог. Затем пробуем удалить созданный файл:

Замечание. Multipath в кластерных конфигурациях

Если сервер, на котором мы настраиваем multipath, в дальнейшем будет использоваться в качестве узла кластера с общим дисковым хранилищем, то для возможно потребуется обеспечить то, чтобы все узлы кластера имели одинаковые настройки multipath. Для этого можно использовать механизм алиасов. В таком случае для каждого multipath-устройства можно задать опцию alias в секции multipaths конфигурационного файла multipath.conf , например:

Настройку алиасов имеет смысл делать лишь в том случае, если в секции defaults значение параметра user_friendly_names равно yes. Дополнительную информацию об этом можно найти здесь: Consistent Multipath Device Names in a Cluster .

Дополнительные источники информации:

Источник