Как настроить multipath в linux
Обновлено: 02.07.2024
Эта секция предоставляет пример пошаговых процедур для настройки DM-Multipath. Она включает следующие процедуры:
Общая настройка DM-Multipath
Игнорирование локальных дисков
Добавление дополнительных устройств в конфигурационный файл
Настройка DM-Multipath
До проведения настройки DM-Multipath на вашей системе убедитесь что система обновлена и содержит пакет multipath-tools. Если предусматривается загрузка с внешнего хранилища (SAN), также потребуется пакет multipath-tools-boot.
Базовый /etc/multipath.conf может быть даже не создан, когда multpath запускается без /etc/multipath.conf, он ищет в своей внутренней базе подходящую конфигурацию, а также копирует данные из внутреннего «черного списка». Если затем запустить multipath -ll без конфигурационного файла, не будет обнаружено ни одного множественного устройства. Кто-то может потребовать разъяснений почему не созданы множественные устройства. Принимая во внимание ссылки на документацию производителей внешних хранилищ, примеры конфигурационных файлов для multipath находятся в /usr/share/doc/multipath-tools/examples, а используемая база multipathd:
В случае причудливой работы multipathd, без создания /etc/multipath.conf, предыдущая команда ничего не вернет, поскольку это будет результатом объединения /etc/multipath.conf с базой в памяти. Для исправления этого либо создайте пустой /etc/multipath.conf, используя touch, либо создайте его, переопределив значения по умолчанию:и перезапустив multipathd:
Теперь «show config» будет возвращать актуальную базу.
Установка с поддержкой множественных устройств
по запросу установщика. Если множественные устройства найдутся, они будут показаны как /dev/mapper/mpath<X> в процессе установки.
Игнорирование локальных дисков при создании множественных устройств
Определите какие диски являются внутренними отметьте их в «черном списке». В этом примере /dev/sda является внутренним диском. Обратите внимание, что в соответствии с изначальной настройкой в конфигурационном файле multipath, выполнение multipath -v2 покажет локальный диск /dev/sda в списке множественных устройств. Для дополнительной информации по выводу команды multipath смотрите раздел Администрирование DM-Multipath и устранение проблем.
Для исключения из списка устройства /dev/sda при использовании multipath, отредактируйте секцию blacklist файла /etc/multipath.conf для включения в нее этого устройства. Вы можете заблокировать устройство sda используя тип devnode, что не является безопасной процедурой, поскольку с этого момента не гарантируется, что /dev/sda будет тем же после перезагрузки. Для блокирования индивидуальных устройств, лучше использовать их WWID. Обратите внимание, что в выводе команды multipath -v2 WWID устройства /dev/sda указан как SIBM-ESXSST336732LC F3ET0EP0Q000072428BX1. Для блокирования этого устройства, включите следующее в файл /etc/multipath.conf:
После изменений файла /etc/multipath.conf, вы должны вручную указать сервису multipathd перегрузить файл. Следующая команда перезагрузит измененный /etc/multipath.conf:
Запустите следующую команду для удаления множественного устройства:
Чтобы проверить, что удаление устройства сработало, вы можете запустить команду multipath -ll для просмотра текущей конфигурации multipath. Для информации по команде multipath -ll смотрите раздел Администрирование DM-Multipath и устранение проблем. Чтобы проверить, что устройства из «черного списка», не добавлены снова, вы можете выполнить команду multipath, как в приведенном примере. Команда multipath по умолчанию использует уровень пояснений v2, если не используется опция -v.
Настройка устройств массивов хранения
По умолчанию DM-Multipath включает поддержку большинства массивов хранения, которые поддерживают работу с DM-Multipath. Значения конфигурационных параметров по умолчанию, включая поддерживаемые устройства, могут быть найдены в файле multipath.conf.defaults.
Если вам нужно добавить устройство, не поддерживаемое по умолчанию, редактируйте файл /etc/multipath.conf для добавления информации о требуемом устройстве.
Например, при добавлении информации о HP Open-V series запись будет выглядеть так, где %n - имя устройства:
Для дополнительной информации смотрите раздел Конфигурационный файл DM-Multipath.
В этой заметке будет рассмотрен пример того, как настроить многоканальное ( 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
Процитирую документацию для того, чтобы отразить основные компоненты 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 подразумевает следующие шаги:
- Установка пакета device-mapper-multipath.
- Создание конфигурационного файла multipath.conf с помощью утилиты mpathconf и его редактирование (при необходимости).
- Запуск службы multipathd.
- Тюнинг драйверов FC HBA
- Зонирование фабрик SAN и СХД
- Установка и настройка DM Multipath (3 шага базового сценария)
- Разметка диска (опционально)
Тюнинг драйверов 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/<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 .
Эта глава содержит пошаговые инструкции по настройке DM-Multipath. В том числе рассматривается следующее:
активация многоканальных функций в файловой системе initramfs .
3.1. Настройка DM-Multipath
Прежде чем приступить к настройке DM-Multipath, убедитесь, что система обновлена и включает пакет device-mapper-multipath .
mpathconf создает и модифицирует файл /etc/multipath.conf .
Если /etc/multipath.conf существует, mpathconf будет его редактировать.
Если /etc/multipath.conf не существует, mpathconf создаст его, взяв за основу файл /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf .
Если файл /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf не существует, mpathconf создаст /etc/multipath.conf с нуля.
Если нет необходимости в модификации файла /etc/multipath.conf , с помощью приведенной ниже команды можно подключить файл конфигурации и запустить multipathd .
Если же необходимо внести изменения в /etc/multipath.conf , это надо сделать до запуска multipathd . Далее описывается процесс простой настройки DM-Multipath.
Описание параметров mpathconf можно найти на справочной странице mpathconf или выполнив:
Если необходимо, отредактируйте /etc/multipath.conf . Стандартные настройки DM-Multipath используются по умолчанию, поэтому не требуется их повторно определять в /etc/multipath.conf .
Изначально path_grouping_policy имеет значение failover , поэтому в нашем примере не придется его изменять. Глава 4, Файл конфигурации DM-Multipath содержит подробную информацию об изменении параметров.
В секции defaults имена устройств определены в виде mpath n. Если имена не заданы, по умолчанию используются идентификаторы WWID.
Так как параметр user_friendly_name установлен в yes , создаваемым устройствам будут присвоены имена /dev/mapper/mpath n (см. Глава 4, Файл конфигурации DM-Multipath).
Чтобы отключить присвоение понятных имен, выполните
Примечание
Если требуется изменить файл конфигурации после запуска multipathd, после завершения редактирования выполните service multipathd reload .
Использование DM Multipath позволяет достичь следующего:
Рис №1. Типовая схема применения DM Multipath
Основные компоненты DM Multipath
Как работает DM Multipath
После выполнения этих команд и перезагрузки сервиса iscsi, мы обнаружим в выводе fdisk -l два новых блочных устройства. Убедиться в том, что оба диска являются одним и тем же массивом СХД, можно сравнив идентификаторы iSCSI ID.
Такая ситуация происходит из-за того, что программный 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, одинаково доступен по двум маршрутам.
В CentOS для их установки вводим команду:
В рамках данного теста, оба маршрута проходят через единственный коммутатор. В реальной ситуации, для обеспечения более высокой отказоустойчивости необходимо развести маршруты по разным коммутаторам, так как показано на рисунке №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 с настройками по умолчанию и поместим его в нужный каталог.
Предназначение секций конфигурационного файла, а так же исчерпывающие описание параметров можно найти по ссылке [1] в конце статьи. По умолчанию, все разделы файла закомментированы. Для нормальной работы DM Multipath необходимо раскомментировать секцию defaults и для пункта path_grouping_policy указать предпочитаемую политику. Наиболее часто используемыми значениями являются:
Так же, можно смело включить секцию blacklist с перечислением тех устройств для которых DM Multipath выключен. В этот список попадают локальные флопи и ide диски и другие не используемые в нашем случае устройства.
В результате, multipathd.conf должен принять примерно следующий вид. Остальные настройки сейчас не важны.
После внесения изменений в конфигурационный файл, запускаем сервис multipathd
И добавляем службу multipathd в автозагрузку
Вместе с запуском службы, происходит автоматическая загрузка модулей ядра.
Проверяем их наличие.
dm_round_robin 2717 2
dm_multipath 17649 2 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
….
В моем случае был создан единственный раздел занявший все доступное пространство.
Остается только разместить файловую систему на новом разделе, смонтировать и использовать.
Тестирование
Тестирование работы DM Multipath проводилось в двух наиболее часто используемых режимах, применение которых мне кажется достаточным для решения большинства задач.
Режим failover
Утилита multipath с ключами -ll, отображает текущее состояние путей. Из данного листинга видно, что один из маршрутов находится в состоянии (status) active, а второй доступен, но не используется (status=enable).
В данном режиме, один из путей, автоматически выбирается активным. Оставшиеся маршруты, могут свободно использоваться при любом сетевом взаимодействии, но для multipathd они являются резервными и при доступе к блочному устройству не используются до выхода из строя основного маршрута.
Если настройка выполнена верно, то доступ к устройству /dev/mapper/mpathbp1 не должен быть потерян в случае проблем с одним из путей. Такую ситуацию легко симулировать путем физического отключения сетевого кабеля или выключения сетевого контроллера средствами ОС. В случае, отказа одного из резервных маршрутов, то нечего подозрительного в работе приложений использующих блочное устройство, замечено не будет. Все будет работать как и работало.
Если же произойдет отключение активного маршрута, то доступ к блочному устройству будет прерван на несколько секунд, после чего будет восстановлен через резервный. При этом приложение интенсивно работающее с блочным устройством, в момент отказа может зависнуть.
Режим multibus
Из данного листинга видно, что оба маршрута объединены в единый пул который находится в активном состоянии.
В данном режиме, операции чтения и записи будут максимально равномерно распределены по доступным маршрутам. При этом, выход из стоя одного из маршрутов, так же как и в режиме 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.
Читайте также: