Iscsi multipath настройка linux

Обновлено: 05.07.2024

Abstract: как работает open-iscsi (ISCSI initiator в linux), как его настраивать и чуть-чуть про сам протокол ISCSI.

Лирика: В интернете есть множество статей довольно хорошо объясняющих, как настроить ISCSI target, однако, почему-то, практически нет статей про работу с инициатором. Не смотря на то, что target технически сложнее, административной возни с initiator больше — тут больше запутанных концепций и не очень очевидные принципы работы.

Перед тем, как рассказать про ISCSI — несколько слов о разных типах удалённого доступа к информации в современных сетях.

NAS vs SAN

Существует два метода доступа к данным, находящимся на другом компьютере: файловый (когда у удалённого компьютера запрашивают файл, а какими файловыми системами это сделано — никого не волнует), характерные представители NFS, CIFS (SMB); и блочный — когда у удалённого компьютера запрашивают блоки с дискового носителя (аналогично тому, как их читают с жёсткого диска). В этом случае запрашивающая сторона сама себе делает на блочном устройстве файловую систему, а сервер, отдающий блочное устройство, знать не знает про файловые системы на нём. Первый метод называют NAS (network attached storage), а второй — SAN (storage area network). Названия вообще указывают на другие признаки (SAN подразумевает выделенную сеть до хранилищ), но так сложилось, что NAS — это файлы, а SAN — это блочные устройства по сети. И хотя все (?) понимают, что это неправильные названия, чем дальше, тем больше они закрепляются.

scsi over tcp

Одним из протоколов доступа к блочным устройствам является iscsi. Буква 'i' в названии относится не к продукции эппл, а к Internet ~~Explorer~~. По своей сути это 'scsi over tcp'. Сам протокол SCSI (без буквы 'i') — это весьма сложная конструкция, поскольку он может работать через разные физические среды (например, UWSCSI — параллельная шина, SAS — последовательная — но протокол у них один и тот же). Этот протокол позволяет делать куда больше, чем просто «подтыкать диски к компьютеру» (как это придумано в SATA), например, он поддерживает имена устройств, наличие нескольких линков между блочным устройством и потребителем, поддержку коммутации (ага, SAS-коммутатор, такие даже есть в природе), подключение нескольких потребителей к одному блочному устройству и т.д. Другими словами, этот протокол просто просился в качестве основы для сетевого блочного устройства.

Терминология

В мире SCSI приняты следующие термины:
target — тот, кто предоставляет блочное устройство. Ближайший аналог из обычного компьютерного мира — сервер.
initiator — клиент, тот, кто пользуется блочным устройством. Аналог клиента.
WWID — уникальный идентификатор устройства, его имя. Аналог DNS-имени.
LUN — номер «кусочка» диска, к которому идёт обращение. Ближайший аналог — раздел на жёстком диске.

ISCSI приносит следующие изменения: WWID исчезает, на его место приходит понятие IQN (iSCSI Qualified Name) — то есть чистой воды имя, сходное до степени смешения с DNS (с небольшими отличиями). Вот пример IQN: iqn.2011-09.test:name.

IETD и open-iscsi (сервер и клиент под линукс) приносят ещё одну очень важную концепцию, о которой чаще всего не пишут в руководствах по iscsi — portal. Portal — это, если грубо говорить, несколько target'ов, которые анонсируются одним сервером. Аналогии с www нет, но если бы веб-сервер можно было попросить перечислить все свои virtualhosts, то это было бы оно. portal указывает список target'ов и доступные IP, по которым можно обращаться (да-да, iscsi поддерживает несколько маршрутов от initiator к target).

Статья не про target, так что даю очень краткое описание того, что делает target. Он берёт блочное устройство, пришлёпывает к нему имя и LUN и публикет его у себя на портале, после чего позволяет всем желающим (авторизация по вкусу) обращаться к нему.

Вот пример простенького файла конфигурации, думаю, из него будет понятно что делает target (файл конфигурации на примере IET):

(сложный от простого отличается только опциями экспорта). Таким образом, если у нас есть target, то мы хотим его подключить. И тут начинается сложное, потому что у initiator'а своя логика, он совсем не похож на тривиальное mount для nfs.

В качестве инициатора используется open-iscsi. Итак, самое важное — у него есть режимы работы и состояние. Если мы дадим команду не в том режиме или не учтём состояние, результат будет крайне обескураживающий.

Поиск target'ов (discovery)
Подключение к target'у
Работа с подключенным target'ом

Немного о состоянии. После discovery open-iscsi запоминает все найденные target'ы (они хранятся в /etc/iscsi/), другими словами, discovery — операция постоянная, совсем НЕ соответствующая, например, dns resolving). Найденные target можно удалить руками (кстати, частая ошибка — когда у open-iscsi, в результате экспериментов и настройки, пачка найденных target'ов, при попытке логина в которые выползает множество ошибок из-за того, что половина target'ов — старые строчки конфига, которые уже давно не существуют на сервере, но помнятся open-iscsi). Более того, open-iscsi позволяет менять настройки запомненного target'а — и эта «память» влияет на дальнейшую работу с target'ами даже после перезагрузки/перезапуска демона.

Второй вопрос, который многих мучает по-началу — куда оно попадает после подключения? open-iscsi создаёт хоть и сетевое, но БЛОЧНОЕ устройство класса SCSI (не зря же оно «я сказя»), то есть получает букву в семействе /dev/sd, например, /dev/sdc. Используется первая свободная буква, т.к. для всей остальной системы это блочное устройство — типичный жёсткий диск, ничем не отличающийся от подключенного через usb-sata или просто напрямую к sata.

В отличие от SAS/UWSCSI, ISCSI доступно для подключения кому попало. Для защиты от таких, есть логин и пароль (chap), и их передача iscsiadm'у — ещё одна головная боль для начинающих пользователей. Она может осуществляться двумя путями — изменением свойств уже найденного ранее target'а и прописываем логина/пароля в файле конфигурации open-iscsi.
Причина подобных сложностей — в том, что пароль и процесс логина — это атрибуты не пользователя, а системы. ISCSI — это дешёвая версия FC-инфраструктуры, и понятие «пользователь» в контексте человека за клавиатурой тут неприменимо. Если у вас sql-база лежит на блочном устройстве iscsi, то разумеется, вам будет хотеться, чтобы sql-сервер запускался сам, а не после минутки персонального внимания оператора.

Это очень важный файл, потому что помимо логина/пароля он описывает ещё поведение open-iscsi при нахождении ошибок. Он может отдавать ошибку «назад» не сразу, а с некоторой паузой (например, минут в пять, чего достаточно для перезагрузки сервера с данными). Так же там контролируется процесс логина (сколько раз пробовать, сколько ждать между попытками) и всякий тонкий тюнинг самого процесса работы. Заметим, эти параметры довольно важны для работы и вам нужно обязательно понимать, как поведёт ваш iscsi если вынуть сетевой шнурок на 10-20с, например.

Я не очень люблю цитировать легконаходимые маны и строчки, так что приведу типовой сценарий употребения iscsi:

сначала мы находим нужные нам target, для этого мы должны знать IP/dns-имя инициатора: iscsiadm -m discovery -t st -p 192.168.0.1 -t st — это команда send targets.

iscsiadm -m node (список найденного для логина)
iscsiadm -m node -l -T iqn.2011-09.example:data (залогиниться, то есть подключиться и создать блочное устройство).
iscsiadm -m session (вывести список того, к чему подключились)
iscsiadm -m session -P3 (вывести его же, но подробнее — в самом конце вывода будет указание на то, какое блочное устройство какому target'у принадлежит).
iscsiadm - m session -u -T iqn.2011-09.example:data (вылогиниться из конкретной )
iscsiadm -m node -l (залогиниться во все обнаруженные target'ы)
iscsiadm -m node -u (вылогиниться из всех target'ов)
iscsiadm -m node --op delete -T iqn.2011-09.example:data (удалить target из обнаруженных).

Ещё один вопрос, важный в серьёзных решениях — поддержка нескольких маршрутов к источнику. Прелесть iscsi — в использовании обычного ip, который может быть обычным образом обработан, как и любой другой трафик (хотя на практике обычно его не маршрутизируют, а только коммутируют — слишком уж великая там нагрузка). Так вот, iscsi поддерживает multipath в режиме «не сопротивляться». Сам по себе open-iscsi не умеет подключаться к нескольким IP одного target'а. Если его подключить к нескольким IP одного target'а, то это приведёт к появлению нескольких блочных устройств.

Использование 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.

Основная часть материалов, посвященная виртуализации, ориентирована в основном на крупные и средние инфраструктуры. О внедрениях виртуализации в масштабах 10-20 ВМ на нескольких серверах сегодня почти никто не говорит. А на самом деле, сред, в которых работает не большее число ВМ, на проложенном в далеком прошлом Ethernet и самосборных сетевые хранилищах, достаточно. И ситуация эта особенно характерна для СНГ, где на развитие ИТ-отдела и на внедрение новых технологий порой выделяют столько средств, что трудно не заплакать.
В этой статье, хочется уделить внимание возможным путям оптимизации сетевой подсистемы, как на аппаратном уровне, так и на программном, для повышения производительности имеющегося оборудования и каналов связи.
В данной статье, под каналами связи везде, где не указанно обратное, подразумевается доступный даже в самых бюджетных организациях Gigabit Ethernet.

Аппаратная оптимизация

Аппаратная оптимизация подразумевает под собой приобретение дополнительного оборудования, в частности сетевого, что может показаться не вписывающимся в контекст данной статьи. Все же я решил об этом упомянуть, так как возможно, это будет следующим этапом развития вашей инфраструктуры.
Сетевые контроллеры с TCP Offload Engine (сокращенно TOE) — это технология, встраиваемая в сетевые адаптеры для разгрузки центрального процессора и возложения функций по обработке сетевых пакетов стека протоколов TCP/IP таких как формирование и подсчет контрольной суммы пакетов на контроллер сетевого адаптера. Как правило, применяется в высокоскоростных сетевых адаптерах: Gigabit Ethernet и 10 Gigabit Ethernet, когда накладные расходы на обработку сетевых пакетов становятся существенными[1].
Устройство TOE взаимодействует с хост-системой посредством интерфейса сеансового уровня. К примеру, при загрузке файла длиной 64 Кбайт обычная сетевая плата (без TOE) инициирует около 60-ти транзакций (прием около 40 пакетов данных и передача 20 подтверждений) для ЦП хост-системы. Если же на сетевом адаптере имеется устройство TOE, обработка пакетов и передача подтверждений осуществляются самим адаптером. В этом случае данные загружаются в буферы приложений и выгружаются из них с помощью аппаратно реализованного механизма прямого доступа к памяти (DMA), а сэкономленная вычислительная мощность ЦП используется для выполнения критически важных приложений.
Сетевые контроллеры с TOE в одинаковой степени повышают производительность сетевой подсистемы и снижают нагрузку на ЦПУ не зависимо от используемого протокола на более высоком уровне(NFS,iSCSI и так далее).
В случае с iSCSI требуется больше вычислительных ресурсов, чем для простого обмена TCP/IP-данными, поскольку в нем предусмотрены дополнительные операции по упаковыванию и распаковыванию SCSI-блоков. Поэтому рекомендуется использовать сетевые адаптеры (iSCSI Host Bus Adapter), в которых кроме TOE аппаратно реализован и уровень iSCSI. Эти адаптеры имеют специальные чипы iSCSI и TCP/IP, что позволяет достигать высоких скоростей обработки пакетов iSCSI и максимальной разгрузки процессора хоста.
В свою очередь, NFS является сетевой файловой системой, большая часть стека которой должна поддерживаться ОС, поэтому каких либо адаптеров, способных аппаратно выполнять уровни NFS, не существует. В этом плане у iSCSI есть преимущество.
Все вышесказанное, является теорией и в большинстве своем общеизвестно. От себя хочется добавить, что при сегодняшних реалиях с многоядерными серверами. Которые сейчас используются даже в организациях с небольшим ИТ-бюджетом. На практике, положительный эффект от контроллеров с TOE будет на уровне нескольких процентов. В случае же если сервера совсем старые, с высокой загрузкой процессора, использование контроллеров с аппаратной разгрузкой будет наиболее полезно.
Такая же ситуация и с iSCSI HBA. Если производительности процессоров с избытком, то эффект от таких контроллеров будет минимальный, почти не заметный.
Рис. №1. Уровни разгрузки сетевого стека различными контроллерами

Различные методики агрегации каналов

Одними из достоинств технологии Ethernet, являются ее гибкость и простота.
Если дорогостоящие контроллеры с аппаратными функциями не вписываются в ваш бюджет, можно воспользоваться другим подходом.
Например, обзавестись кучей дешевых контроллеров Gigabit Ethernet и воспользоваться одной из хорошо зарекомендовавших себя техник агрегации каналов.
Например, технология «Multipath IO» и ее реализация в linux (DM-Multipath) позволяет прозрачно для ОС и приложений агрегировать несколько каналов ведущих к одному дисковому массиву системы хранения в один логический. Тем самым пропорционально количеству каналов повышается производительность и отказоустойчивость в случае выхода одного из каналов.

Multipathing никак не отменяет все сказанное в этой статье, а является следующим шагом в оптимизации производительности сетевой подсистемы. На эту тему будет подготовлен отдельный материал.

Оптимизация сетевого стека

Современные операционные системы, в частности серверные версии Linux, которые чаще всего используются в качестве ОС для серверов хранения и виртуализации, по умолчанию не оптимизированы для конкретных ролей. Большинство компонентов и сервисов ОС настроены универсально для широкого круга задач и готовы к работе в любых условиях и на различном оборудовании. Например, сетевой стек, без каких либо настроек способен одновременно поддерживать сотни подключений к веб-серверу и при этом обслуживать тяжелые операции чтения/записи в роле программного iSCSI SAN. Такой подход, понятен и он удобен в большинстве задач. Но, в случае, когда требования к производительности высоки, для конкретных ролей, сервер и ОС должны быть дополнительно оптимизированы и настроены более тонко.
Используя 1G Ethernet мы, по большему счету (в сравнении с FC), не получаем широких каналов и уж тем более приемлемого, критичного для ВМ времени отклика. В таком случае, упираясь в производительность сетевого оборудования остается только попробовать оптимизировать работу сетевых протоколов, для получения максимального эффекта от того что имеем.
К программной оптимизации можно отнести всевозможные методы ускорения сетевого стека ядра за счет переключения различных режимов или возможных выделений дополнительных ресурсов.
В дальнейшем, по ходу статьи, полагается, что среда передачи стабильная. Обрывы и многочисленные потери пакетов исключаются.

Увеличение MTU

Изменение сетевых параметров ядра

Список наиболее важных параметров ядра, имеющих отношение к эффективности и производительности сети в контексте сетей хранения данных [3];
net.core.somaxconn = 256 (по умолчанию 128) — Максимальное число открытых сокетов, ждущих соединения. Имеет смысл увеличить значение при большем количестве соединений. Для высоко нагруженных серверов советуют значения в районе 15000-20000.
В нашем случае, количество соединений не большое (это не веб-сервер), поэтому можно и не увеличивать.
net.core.rmem_max = 1073741824 (по умолчанию 124928) — Устанавливает максимальный размер буфера на прием для всех протоколов.
net.core.wmem_max = 1073741824 (по умолчанию 124928) — Устанавливает максимальный размер буфера на передачу для всех протоколов.
net.ipv4.tcp_reordering = 20 (по умолчанию 3) Иногда увеличение времени прохождения пакета в локальной сети может считаться потерей пакета. Для таких случаев увеличение значения этого параметра повышает производительность.
net.ipv4.tcp_rmem = 1048576 16777216 1073741824 (по умолчанию 4096 87380 937024)
Соответственно минимум, по умолчанию и максимум. Переменная в файле tcp_rmem содержит 3 целых числа, определяющих размер приемного буфера сокетов TCP.
Каждый сокет TCP имеет право использовать эту память по факту своего создания. Размер минимального буфера по умолчанию составляет 4 Кбайт (4096)
net.ipv4.tcp_wmem = 1048576 16770216 1073741824 (по умолчанию 4096 16384 937024 )
Переменная в файле tcp_wmem содержит 3 целочисленных значения, определяющих минимальное, принятое по умолчанию, и максимальное количество памяти, резервируемой для буферов передачи сокета TCP.
Каждый сокет TCP имеет право использовать эту память по факту своего создания. Размер минимального буфера по умолчанию составляет 4 Кбайт (4096)
ВНИМАНИЕ: Максимальные значения параметров net.ipv4.tcp_rmem, net.ipv4.tcp_wmem не должны превышать значения параметров net.core.rmem_max и net.core.wmem_max!
net.ipv4.tcp_mem = 1048576 16770216 1073741824 (по умолчанию 21960 29282 43920)
Переменная в файле tcp_mem содержит 3 целых числа (порога), определяющих отношение протокола TCP к выделению памяти.
Нижний порог: при значениях ниже этого уровня TCP не заботится о расходе памяти.
Порог ограничения: при достижении этого порога TCP контролирует размер выделяемой памяти и переходит в режим memory pressure (нехватка памяти), из которого выходит при снижении расхода памяти до нижнего порога.
Верхний порог: число страниц памяти, доступных для создания очередей всеми сокетами TCP.
Значения всех порогов рассчитываются во время загрузки ОС с учетом доступной на компьютере памяти.
net.ipv4.tcp_window_scaling = 1 (по умолчанию обычно 1) — Активирует масштабирование окна, как определено в RFC 1323; должен быть включен(1) для поддержки окон размером больше, чем 64KB.

net.ipv4.tcp_sack = 1 (по умолчанию обычно 1) — Активирует выборочное подтверждение (selective acknowledgment), которое улучшает производительность, выборочно подтверждая пакеты, полученные вне очереди (в результате отправитель повторно передает только пропущенные сегменты); должен быть включен (для большой области сетевых коммуникаций), но может усилить использование CPU.

net.ipv4.tcp_timestamps = 1 (по умолчанию обычно 1) — Активирует вычисление RTT более достоверным способом (смотрите RFC 1323), чем интервал для повторной передачи; должен быть включен для быстродействия.

Установить значения приведенных выше параметров можно воспользовавшись командой:

Например устанавливаем новое значение параметра net.ipv4.tcp_low_latency:

Изменение значений параметров с помощью утилиты sysctl, действуют только до перезагрузки системы. Для установки постоянных значений необходимо прописать соответствующие параметры и их значения в файле /etc/sysctl.conf
Посмотреть текущие значения параметров можно в соответствующих файлах виртуальной файловой системы /proc:

Изменение значения перечисленных выше параметров в разной степени, но все же оказываю влияние на потребление памяти и ресурсов CPU.

Конкретно для NFS

Число потоков nfsd

В моем случае их было 8.

Задать собственное количество до перезагрузки:

Задать число потоков на постоянной основе можно в конфигурационном файле /etc/sysconfig/nfs. Параметр RPCNFSDCOUNT=8.
Как определить достаточно ли потоков?

Проверка утилизации потоков сервера

Утилита nfsstat выполненная на клиенте с ключами -rc выводит нам примерно следующую информацию:

Здесь видно, что значение retrans (повторная отправка RPC-запроса) достаточно высокое. Это явный признак того, что количества доступных потоков ядра NFS на сервере недостаточно, чтобы обрабатывать запросы от этого клиента.
С помощью утилиты nfsstat с ключами -s (на сервере) или -c (на клиенте) можно получить исчерпывающую информацию о работе обеих сторон. Например, получить процентное соотношение операций чтения и записи.
Напоследок, стоит отметить, что если процессор или дисковая подсистема компьютера уже перегружены, увеличение числа потоков не приведет к повышению производительности. Число потоков должно быть оптимально подобранно с учетом возможностей оборудования! Тестируйте.

Опции монтирования (относится к NFS-клиентам)

Размеры блоков чтения и записи (rsize и wsize)

Эти опции отвечают за то, какими порциями nfs-клиент будет отправлять и получать данные за раз, в одном RPC-запросе.
В идеале, значения этих опций не должны превышать размер MTU, так как в этом случае, возрастает фрагментация пакетов. Это приводит к дополнительным затратам на сборку пакетов как на сервере так и на клиенте и негативно сказывается на производительности.
Обычно, если опции rsize и wsize не заданы, то в зависимости от версии NFS или сборки будет читать и писать блоками по 4096 или 8192 байтов. Некоторые ядра Linux(в частности, сетевой стек) и сетевые кары не могут обрабатывать такие большие блоки, что приводит к деградации производительности.
Посмотреть установленные по умолчанию в вашей ОС rsize и wsize можно вот так cat /proc/mounts. При этом должен быть смонтирован хотя бы один NFS-каталог.

Выше приводится информация об одном из смонтированных каталогов. Здесь можно увидеть все опции монтирования, в том числе и желанные rsize и wsize.
Данный вывод получен на ОС Ubuntu 12.04 с настройками по умолчанию.
В дистрибутиве XenServer 6.0.2 по умолчанию, используются такие же значения.
Установить произвольные значения параметров rsize и wsize можно при монтировании NFS-каталога.

В данном примере, указанны значения в 8kb, что оптимально при включенных Jombo-кадрах(MTU=9000)

При подключении NFS-хранилища, например, в графической консоли Citrix XenCenter или VMware vSphere Client, опции монтирования так же указываются в соответствующих полях и разделах интерфейса.

Выводы

Сетевой стек так же, как и большинство серверных приложений и служб современных ОС, имеют достаточно универсальные настройки по умолчанию. Такие настройки позволяют одинаково не плохо (но и не очень хорошо) работать в различных условиях, не требуя вмешательства. Если ваше сетевое хранилище построено на базе одной из универсальных ОС, то придется засучить рукава и выполнить дополнительные настройки для получения максимальной производительности.

У одного из наших клиентов, который приобретал сервера и лезвия HP, а сейчас прикупил HP MSA 2040, недавно возник вопрос:

Почему сервер видит презентованный ему лун, как 4 отдельных диска одинакового объема (ОС Linux)?

Ответ прост:

Подключение к серверу в данном случае происходит по 4 независимым каналам и каждый из этих дисков представляет собой отдельный канал.

Чтобы в итоге получить один диск, для работы нужно использовать службу multipath IO.

Multipath LUN СХД к VMware ESXi

Multipath LUN СХД к Debian GNU/Linux

Немного сложнее:

На начальном этапе установки Debian GNU/Linux, мы можем столкнуться с проблемой невозможности обнаружить системой firmware ql2400_fw.bin. Решается это просто:
На рабочей Linux системе скачиваем пакет firmware-qlogic, распаковываем, записываем в образ и монтируем через ILO (действия производятся на сервере HP Proliant). Выглядит это примерно так:

Подключаем qlfw.raw через меню Virtual Device->Image File Removable Media. Если инсталятор по-прежнему не может найти firmware, это можно сделать вручную, смонтировав образ в каталог /lib/firmware и перезагрузив модуль qla2xxx. Переключаемся на текстовую консоль ( нижеследующие действия производятся в ILO. Меню Keyboard->CTRL-ALT-Fn->CTRL-ALT-F2):

После чего, возвращаемся к инсталятору (меню Keyboard->CTRL-ALT-Fn->CTRL-ALT-F5), и доустанавливаем систему в штатном режиме.

На рабочей системе, нам потребуется установить пакет multipath-tools со всеми зависимостями:

Определяем автозапуск сервиса:

Посмотрим, как сгруппировались устройства:

Создадим файловую систему на нужном нам LUN'e:

Смонтируем, и посмотрим, что получилось:

LUN смонтирован и готов к использованию. Осталось дописать строчку в fstab:

В данном случае мы рассмотрели пример подключения к VMware ESXi и Debian GNU/Linux.

Систему выделения LUNов к серверам мы также используем у себя на хостинге
В данном случае мы используем:

1. Блейд шасси HP C7000 в максимальной комплектации, с двумя административными модулями.

2. FC коммутаторы в шасси С7000 для подключения внешних СХД — HP Brocade 8Gb 8/24c SAN Switch. Внешние FC коммутаторы — HP StorageWorks 8/40 Base 24, (24) порта Full Fabric SAN Switch.

3. СХД HPE 3PAR StorServ 7400 (4-node), HPE 3PAR StorServ 7450c (4-node), HPE 3PAR StorServ 7400c (2-node) и СХД HPE EVA P6550.

Где мы выделяем луны:
ALLFlash — only SSD
AO — смешанный SSD+SAS
NL — only SAS

В следующей статье мы рассмотрим Подключение Multipath LUN СХД к Windows Server 2008 и Windows Server 2012.

Читайте также: