multipathd ubuntu что это
Обзор установки DM-Multipath
Содержание
Обзор установки DM-Multipath
Эта секция предоставляет пример пошаговых процедур для настройки DM-Multipath. Она включает следующие процедуры:
Общая настройка DM-Multipath
Игнорирование локальных дисков
Добавление дополнительных устройств в конфигурационный файл
Настройка DM-Multipath
До проведения настройки DM-Multipath на вашей системе убедитесь что система обновлена и содержит пакет multipath-tools. Если предусматривается загрузка с внешнего хранилища (SAN), также потребуется пакет multipath-tools-boot.
и перезапустив multipathd:
Теперь «show config» будет возвращать актуальную базу.
Установка с поддержкой множественных устройств
по запросу установщика. Если множественные устройства найдутся, они будут показаны как /dev/mapper/mpath в процессе установки.
Игнорирование локальных дисков при создании множественных устройств
После изменений файла /etc/multipath.conf, вы должны вручную указать сервису multipathd перегрузить файл. Следующая команда перезагрузит измененный /etc/multipath.conf:
Запустите следующую команду для удаления множественного устройства:
Настройка устройств массивов хранения
По умолчанию DM-Multipath включает поддержку большинства массивов хранения, которые поддерживают работу с DM-Multipath. Значения конфигурационных параметров по умолчанию, включая поддерживаемые устройства, могут быть найдены в файле multipath.conf.defaults.
Если вам нужно добавить устройство, не поддерживаемое по умолчанию, редактируйте файл /etc/multipath.conf для добавления информации о требуемом устройстве.
Для дополнительной информации смотрите раздел Конфигурационный файл DM-Multipath.
Device Mapper Multipath will be referred here as multipath only.
This section provides step-by-step example procedures for configuring multipath.
It includes the following procedures:
Basic setup
Main defaults & devices attributes.
Shows how to ignore disks with blacklists
Shows how to rename disks using WWIDs
Configuring active/active paths
Basic Setup
Before setting up multipath on your system, ensure that your system has been updated and includes the multipath-tools package. If boot from SAN is desired, then the multipath-tools-boot package is also required.
The internal attributes database can be acquired by doing:
Multipath is usually able to work out-of-the-box with most common storages. This does not mean the default configuration variables should be used in production: they don’t treat important parameters your storage might need.
With the internal attributes, described above, and the given example bellow, you will likely be able to create your /etc/multipath.conf file by squashing the code blocks bellow. Make sure to read every defaults section attribute comments and change it based on your environment needs.
Note: You can obtain the WWIDs for your LUNs executing:
Device Mapper Multipath will be referred here as multipath only.
Multipath allows you to configure multiple I/O paths between server nodes and storage arrays into a single device. These I/O paths are physical SAN connections that can include separate cables, switches, and controllers.
Multipathing aggregates the I/O paths, creating a new device that consists of the aggregated paths. This chapter provides an introduction and a high-level overview of multipath.
Overview
Multipath can be used to provide:
multipath can provide failover in an active/passive configuration. In an active/passive configuration, only half the paths are used at any time for I/O. If any element of an I/O path (the cable, switch, or controller) fails, multipath switches to an alternate path.
Multipath can be configured in active/active mode, where I/O is spread over the paths in a round-robin fashion. In some configurations, multipath can detect loading on the I/O paths and dynamically re-balance the load.
Storage Array Overview
It is a very good idea to consult your storage vendor installation guide for the recommended multipath configuration variables for your storage model. The default configuration will probably work but will likely need adjustments based on your storage setup.
Multipath Components
Multipath Setup Overview
multipath includes compiled-in default settings that are suitable for common multipath configurations. Setting up multipath is often a simple procedure. The basic procedure for configuring your system with multipath is as follows:
Install the multipath-tools and multipath-tools-boot packages
Create an empty config file called /etc/multipath.conf
Edit the multipath.conf file to modify default values and save the updated file.
Start the multipath daemon
Update initial ramdisk
For detailed setup instructions for multipath configuration see DM-Multipath Configuration and DM-Multipath Setup.
Multipath Devices
Without multipath, each path from a server node to a storage controller is treated by the system as a separate device, even when the I/O path connects the same server node to the same storage controller. Multipath provides a way of organizing the I/O paths logically, by creating a single device on top of the underlying paths.
Multipath Device Identifiers
For example, a node with two HBAs attached to a storage controller with two ports via a single unzoned FC switch sees four devices: /dev/sda, /dev/sdb, /dev/sdc, and /dev/sdd. Multipath creates a single device with a unique WWID that reroutes I/O to those four underlying devices according to the multipath configuration.
When the user_friendly_names configuration option is set to yes, the name of the multipath device is set to mpathn. When new devices are brought under the control of multipath, the new devices may be seen in two different places under the /dev directory: /dev/mapper/mpathn and /dev/dm-n.
The devices in /dev/mapper are created early in the boot process. Use these devices to access the multipathed devices.
Any devices of the form /dev/dm-n are for internal use only and should never be used directly.
You can also set the name of a multipath device to a name of your choosing by using the alias option in the multipaths section of the multipath configuration file.
For information on the multipath configuration defaults, including the user_friendly_names and alias configuration options, see DM-Multipath Configuration.
Consistent Multipath Device Names in a Cluster
This should not cause any difficulties if you use LVM to create logical devices from the multipath device, but if you require that your multipath device names be consistent in every node it is recommended that you leave the user_friendly_names option set to no and that you not configure aliases for the devices.
If you configure an alias for a device that you would like to be consistent across the nodes in the cluster, you should ensure that the /etc/multipath.conf file is the same for each node in the cluster by following the same procedure:
Configure the aliases for the multipath devices in the in the multipath.conf file on one machine.
Disable all of your multipath devices on your other machines by running the following commands:
Copy the /etc/multipath.conf file from the first machine to all the other machines in the cluster.
Re-enable the multipathd daemon on all the other machines in the cluster by running the following command:
When you add a new device you will need to repeat this process.
Multipath Device attributes
For information on the multipaths section of the multipath configuration file, see DM-Multipath Configuration.
Multipath Devices in Logical Volumes
After creating multipath devices, you can use the multipath device names just as you would use a physical device name when creating an LVM physical volume.
For example, if /dev/mapper/mpatha is the name of a multipath device, the following command will mark /dev/mapper/mpatha as a physical volume:
You can use the resulting LVM physical device when you create an LVM volume group just as you would use any other LVM physical device.
If you attempt to create an LVM physical volume on a whole device on which you have configured partitions, the pvcreate command will fail.
Multipath I/O для программного iSCSI
Статья опубликована в журнале «Системный Администратор»
Немного терминологии
Multipath I/O — технология, позволяющая задействовать нескольких контроллеров или шин для доступа к одному устройству хранения данных. Например, один SCSI диск может быть подсоединён к двум SCSI контроллерам. В случае отказа одного из них, операционная система будет продолжать работать по другому. Это дает возможность повысить производительность и отказоустойчивость среды передачи данных.
В случае с iSCSI, принципиальная схема не меняется т.к. подключенные по сети блочные устройства (iSCSI-Target) для операционной системы не чем не отличаются от локальных устройств хранения данных. Единственное, что вместо SCSI контроллеров и шлейфов, используются компоненты обычного Ethernet — сетевые карты, медные или оптические кабеля. В продуктах VMware и Citrix данную технологию можно встретить под именем Multipathing.
Device-Mapper Multipath (DM Multipath, множественное связывание устройств) — название реализации технологии Multipath I/O в Linux доступной во всех современных дистрибутивах. Реализован в виде модуля ядра. Прозрачно для приложений, представляет массив, доступный по нескольким путям, в виде одного мета-устройства.
Использование DM Multipath позволяет достичь следующего:
• Отказоустойчивость — в случае сбоя любого маршрута (кабеля, контроллера или коммутатора) DM-Multipath начнет использовать альтернативный путь из числа не активных.
• Балансировка нагрузки – запросы ввода и вывода распределяюся между путями по очереди, что равномерно загружает все доступные сетевые контроллеры и каналы.
Рис №1. Типовая схема применения DM Multipath
Основные компоненты DM Multipath
dm_multipath — перенаправляет ввод-вывод
dm_round_robin — обеспечивает отказоустойчивость маршрутов и их груп
mpathconf — Используется для настройки возможностей DM-Multipath.
multipath — Позволяет просмотреть топологию маршрутов, принудительно переключаться между режимами.
multipathd — Следит за маршрутами, инициализирует переключение групп маршрутов при их сбое и восстановлении и позволяет изменять устройства интерактивно.
Как работает DM Multipath
Работу Multipath I/O лучше всего проиллюстрировать на примере. Допустим есть сеть хранения данных (СХД) с двумя сетевыми контроллерами (хотя их может быть сколько угодно) eth0 — 192.168.0.10/24, eth1 — 192.168.1.10/24. Тип СХД не принципиален, возможно это Fibre Chanel (FC), Fibre Chanel over Ethernet (FCoE) или iSCSI — который мы и будем использовать в качестве примера. На СХД имеется дисковый массив доступный как iSCSI-Target на обоих сетевых интерфейсах. При подключении к нему на другом сервере, так же с двумя сетевыми интерфейсами eth0-192.168.0.130/24, eth1-192.168.1.130/24 получим два, как будто бы разных массива, но фактически, он один.
Такая ситуация происходит из-за того, что программный iSCSI-Initiator с помощью которого выполняется подключение устройств iSCSI, не умеет работать с одним блочным устройством используя несколько путей. Даже если это одно и тоже устройство. Другой канал, значит и устройство тоже другое.
Вот здесь на помощь и приходит DM Multipath, понимающий, что к разным маршрутам подключен один и тот же массив. При этом количество путей, может быть произвольным и даже не одинаковым на обеих сторонах. Например если у сервера на котором подключается iSCSI-Target больше сетевых контроллеров чем у самой СХД. Но они настроены на работу в одной подсети и через них так же доступен дисковый массив. Они будут сгруппированы DM Multipath и настроены в соответствии с выбранным режимом о которых пойдет речь ниже.
Исходные данные
В качестве СХД используется StarWind iSCSI SAN со свободной лицензией, установленный на Windows Server 2008 R2. В сервере имеются два контроллера Gigabit Ethernet (192.168.0.10/24, 192.168.1.10/24). Тестовый iSCSI-Traget, одинаково доступен по двум маршрутам.
В качестве сервера на котором будет задействован DM-Multipath при подключении iSCSI-Target’a используется CentOS 6.3 с двумя контроллерами Gigabit Ethernet (192.168.0.130/24, 192.168.1.130/24)
В ходе настройки понадобится ряд утилит установить которые не составит труда из стандартных репозиториев.
В CentOS для их установки вводим команду:
# yum –y install device-mapper-multipath iscsi-initiator-utils
# apt-get install open-iscsi open-iscsi-utils multipath-tools
В рамках данного теста, оба маршрута проходят через единственный коммутатор. В реальной ситуации, для обеспечения более высокой отказоустойчивости необходимо развести маршруты по разным коммутаторам, так как показано на рисунке №1.
От себя лично, рекомендую по возможности использовать одинаковые сетевые контроллеры и каналы с равной пропускной способностью. В противном случае, возможны проблемы с производительностью!
Настройка
Первым делом, необходимо подключить iSCSI-Target доступный по нескольким маршрутам используя iscsiadm с параметрами указанными в примере выше.
Перезапускаем службу iscsi для того что бы обнаруженные iSCSI-Targets были подключены как локальные диски.
Далее как и во вступительном примере, обнаруживаем два как будто бы разных диска (/dev/sdb, /dev/sdс).
Диск /dev/sda: 8589 МБ, 8589934592 байт
…
(листинг локальных дисков не приводится для сокращения объемов статьи)
…
Диск /dev/sdb: 536 МБ, 536870912 байт
17 heads, 61 sectors/track, 1011 cylinders
Units = цилиндры of 1037 * 512 = 530944 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Диск /dev/sdc: 536 МБ, 536870912 байт
17 heads, 61 sectors/track, 1011 cylinders
Units = цилиндры of 1037 * 512 = 530944 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Теперь, когда наш дисковый массив подключен, настроим для него Multipath I/O.
Все действия сводятся к правке конфигурационного файла multipathd.conf который после установки пакета device-mapper-multipath должен находиться в /etc, но в некоторых дистрибутивах может отсутствовать.
По этому, сами возьмем шаблон multipathd.conf с настройками по умолчанию и поместим его в нужный каталог.
# cp /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf /etc/multipath.conf
Предназначение секций конфигурационного файла, а так же исчерпывающие описание параметров можно найти по ссылке [1] в конце статьи. По умолчанию, все разделы файла закомментированы. Для нормальной работы DM Multipath необходимо раскомментировать секцию defaults и для пункта path_grouping_policy указать предпочитаемую политику. Наиболее часто используемыми значениями являются:
failover = Режим активный/пассивный. В таком случае будет использоваться один из доступных маршрутов, а второй — является резервом на случай отказа первого. Данный режим используется по умолчанию.
multibus = Активный/активный. Все маршруты будут использоваться одновременно.
Так же, можно смело включить секцию blacklist с перечислением тех устройств для которых DM Multipath выключен. В этот список попадают локальные флопи и ide диски и другие не используемые в нашем случае устройства.
В результате, multipathd.conf должен принять примерно следующий вид. Остальные настройки сейчас не важны.
defaults <
udev_dir /dev
polling_interval 10
path_selector «round-robin 0»
path_grouping_policy failover
getuid_callout «/lib/udev/scsi_id —whitelisted —device=/dev/%n»
prio alua
path_checker readsector0
rr_min_io 100
max_fds 8192
rr_weight priorities
failback immediate
no_path_retry fail
user_friendly_names yes
>
blacklist <
wwid 26353900f02796769
devnode «^(ram|raw|loop|fd|md|dm-|sr|scd|st)8*»
devnode «^hd[a-z]»
После внесения изменений в конфигурационный файл, запускаем сервис multipathd
И добавляем службу multipathd в автозагрузку
# chkconfig multipathd on
Вместе с запуском службы, происходит автоматическая загрузка модулей ядра.
Проверяем их наличие.
dm_round_robin 2717 2
dm_multipath 17649 2 dm_round_robin
Если по какой то причине модули на загружены, то можно выполнить это в ручную.
# modprobe dm_multipath
# modprobe dm_round_robin
Если все сделано правильно, то в списке дисков выводимых fdisk –l должно появиться новое устройство, с тем же идентификатором (Disk identifier: 0x00000000).
Диск /dev/mapper/mpathb: 536 МБ, 536870912 байт
255 heads, 63 sectors/track, 65 cylinders
Units = цилиндры of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Далее, как и на любом другом диске, на нем нужно создать разделы. Но делать это нужно на оригинальном устройстве /dev/sdb или /dev/sdc, а не на новом мета-устройстве /dev/mapper/mpathb появившемся после настройки DM Multipath!
Если реальный диск еще не размечен, это можно сделать любым удобным средством.
Разметки дисков в Linux, посвящено достаточно много статей. Как это сделать конкретно с помощью fdisk, можно посмотреть по ссылке [2]. В случае если на подключенном диске уже существуют разделы, их можно просто смонтировать с помощью утилиты mount как показано ниже и использовать по назначению.
После разметки можно выполнить команду partprobe, что бы таблица разделов была перечитана или перезагрузить сервер.
После синхронизации, разделы созданные на одном из реальных дисков, появятся и на новом мета-устройстве;
….
Устр-во Загр Начало Конец Блоки Id Система
/dev/mapper/mpathbp1 1 1011 524173 83 Linux
….
В моем случае был создан единственный раздел занявший все доступное пространство.
Остается только разместить файловую систему на новом разделе, смонтировать и использовать.
# mkfs.ext3 /dev/mapper/mpathbp1
# mount /dev/mapper/mpathbp1 /test-dm
Тестирование
Тестирование работы DM Multipath проводилось в двух наиболее часто используемых режимах, применение которых мне кажется достаточным для решения большинства задач.
Режим failover
May 04 04:50:24 | sdb: alua not supported
May 04 04:50:24 | sdc: alua not supported
mpathb (210f6e58300000000) dm-2 ROCKET,RAM DISK 512 MB
size=512M features=’0′ hwhandler=’0′ wp=rw
|-+- policy=’round-robin 0′ prio=-1 status=active
| `- 4:0:0:0 sdb 8:16 active ready running
`-+- policy=’round-robin 0′ prio=-1 status=enabled
`- 3:0:0:0 sdc 8:32 active ready running
Если настройка выполнена верно, то доступ к устройству /dev/mapper/mpathbp1 не должен быть потерян в случае проблем с одним из путей. Такую ситуацию легко симулировать путем физического отключения сетевого кабеля или выключения сетевого контроллера средствами ОС. В случае, отказа одного из резервных маршрутов, то нечего подозрительного в работе приложений использующих блочное устройство, замечено не будет. Все будет работать как и работало.
Если же произойдет отключение активного маршрута, то доступ к блочному устройству будет прерван на несколько секунд, после чего будет восстановлен через резервный. При этом приложение интенсивно работающее с блочным устройством, в момент отказа может зависнуть.
Режим multibus
May 04 04:10:16 | sdc: alua not supported
May 04 04:10:16 | sdb: alua not supported
mpathb (210f6e58300000000) dm-2 ROCKET,RAM DISK 512 MB
size=512M features=’0′ hwhandler=’0′ wp=rw
`-+- policy=’round-robin 0′ prio=-1 status=active
|- 3:0:0:0 sdc 8:32 active ready running
`- 4:0:0:0 sdb 8:16 active ready running
Из данного листинга видно, что оба маршрута объединены в единый пул который находится в активном состоянии.
В данном режиме, операции чтения и записи будут максимально равномерно распределены по доступным маршрутам. При этом, выход из стоя одного из маршрутов, так же как и в режиме failover не приводит к потере доступа к массиву. После нескольких попыток восстановить маршрут, работа с устройством продолжится по оставшимся, работающим маршрутам. При возвращении в строй отказавшего ранее пути, он будет автоматически задействован.
Производительность
ВАЖНО: Если основной решаемой задачей является не отказоустойчивость а повышение производительности операций вводавывода. То применять Multipath I/O стоит только в том случае, если в вашем хранилище, достаточно быстрый массив, полностью загружающий один канал. В случае, если единственный маршрут ведущий к массиву не загружается полностью хотя бы под пиковыми нагрузками, добавление еще одного маршрута лишь приведет к потере производительности и увеличению задержек(latency)!
В моем случае, при копировании больших файлов на разные массивы, с нескольких узлов, загрузка гигабитного интерфейса хранилища, большую часть времени составляет 100%, при том, что загрузка дисковой подсистемы не достигает максимума. В таком случае, самое время задействовать дополнительный канал.
Результаты работы утилиты dd;
При одном канале, по стандартной схеме без Multipath I/O;
1073741824 bytes (1.1 GB) copied,
29.0323 s 37 Mb/s
А это уже dd с Multipath I/O поверх двух гигабитных каналов
1073741824 bytes (1.1 GB) copied,
23.4791 s, 48.0 Mb/s
Кроме утилиты dd были выполнены тесты с помощью утилиты fio (flexible I/O tester), информацию о которой можно найти по ссылке[3] в конце статьи.
Вкратце отмечу, что по результатам тестирования было выявлено примерно одинаковое количество iops(число операция вводавывода в секунду) как в случае с одним каналом так и при Multipath I/O. Такая же ситуация и с latency(время ответа от массива). То есть количество маршрутов увеличивает суммарную пропускную способность но не как не улучшает остальные характеристики каналов.
Выводы
DM Multipath является низкоуровневым средством для оптимизации и повышения надежности сетевого ввода/вывода. Даже при использовании дешевого оборудования и стандартного Ethernet, можно построить достаточно производительную и надежную среду передачи данных. Особенно это эффективно в случае с iSCSI в контексте виртуализации.
В данной статье я использовал по два сетевых контроллера с каждой стороны, но их число может быть произвольным. Причем не обязательно одинаковым на обеих сторонах.
При более тонкой настройке, можно добиться любой желаемой производительности и обеспечить необходимый уровень резервирования. Особенно, удобно то, что настройки требует только та сторона на которой выполняется подключение блочного устройства.
При сравнении возможных режимов, наиболее оптимальным мне показался режим multibus т. к. он позволяет задействовать всю пропускную способность, при этом не уступая в надежности режиму failover.
Пошаговые руководства, шпаргалки, полезные ссылки.
Инструменты пользователя
Инструменты сайта
Боковая панель
Настройка DM-Multipath в Debian/GNU Linux 9 при подключении к СХД HP MSA 1500CS
В рассматриваемом примере к виртуальному серверу на базе ОС Debian GNU/Linux 9 из сети FC SAN подключен дисковый том (RAID-массив) с системы хранения данных HP StorageWorks Modular Smart Array 1500CS. Подключение тома выполнено по двум путям, то есть через две отдельные фабрики FC SAN. Для того, чтобы задействовать механизм multipath (Device Mapper Multipath/DM-multipath), который позволит обращаться к этим двум дисковым устройствам, доступным по разным путям, как к одному устройству в Debian Linux нам потребуется установить пакет multipath-tools.
После установки пакета, опорный конфигурационный файл /etc/multipath.conf не создаётся, а механизм multipath использует конфигурацию по умолчанию. Посмотреть то, какую базовую конфигурацию использует служба multipath-tools, можно командой:
Здесь мы увидим, что служба multipath-tools имеет множество параметров, в том числе и базовую конфигурацию с множеством правил обработки путей для разных типов СХД и базовый набор устройств, которые должны исключаться из механизмов работы по нескольким путям (blacklist).
Посмотрим, что нашла служба multipath-tools в нашей системе
Как видим, служба успешно распознала дисковый том с СХД HP MSA, доступный в системе по двум путям, и применила к нему некий предопределённый набор правил работы с этими путями.
Правила, описанные нами в данном случае в собственном конфигурационном файле multipath.conf будут суммироваться с правилами базовой конфигурации службы multipath-tools
После внесения изменений в конфигурацию multipath выполним перезапуск службы
После перезапуска снова проверим конфигурацию
В нашем примере из двух устройств (одно логического тома СХД, который доступен системе по двум путям) мы получили единое multipath-устройство. То есть, в нашем примере блочные устройства sdb и sdc это один и тот же диск, доступный серверу по двум путям. Список блочных устройств можно получить командой
Список multipath-устройств можно получить командами:
Монтирование multipath-диска
Создаём файловую систему на диске (в нашем случае это будет ext4), затем создаём каталог, в который будем монтировать созданный раздел и, наконец, монтируем этот раздел:
Теперь пропишем в файл /etc/fstab информацию для автоматического монтирования раздела, например, в точку монтирования /mnt/storage в процессе загрузки системы. Для этого сначала узнаем UUID раздела:
Затем добавим информацию о монтировании в конец файла /etc/fstab
В конечном итоге конфигурация fstab может принять следующий вид:
После этого перезагружаем сервер и убеждаемся в том, что конечный результат достигнут и раздел автоматически монтируется в нужную нам точку монтирования.
Теперь остаётся только попробовать создать новый пустой файл в смонтированном в каталог разделе, проверяя тем самым возможность записи в этот каталог:
Дополнительные источники информации:
Проверено на следующих конфигурациях:
Автор первичной редакции:
Алексей Максимов
Время публикации: 04.05.2019 11:37