Настройка mpio в windows server 2019 - Доктор Windows

На чтение 3 мин Просмотров 254 Опубликовано 01.07.2022

В этой статье мы разберем как настроить инициатор iSCSI и использовать его для подключения к виртуальному диску iSCSI на target сервере.

В моей предыдущей статье «Настройка и установка iSCSI target Server в Windows Server 2016/2019 объяснил следующее:

как установить роль iSCSI на Windows Server 2016.
как создать новый виртуальный диск iSCSI и настроить доступ к серверу.

iSCSI initiator — используется для подключения к внешнему хранилищу на основе iSCSI. Рабочие станции и серверы используют его для монтирования целевого тома в качестве локального тома. Он использует сеть Ethernet на основе IP для связи с target server iSCSI.

Содержание

Устанавливаем MPIO (multipath i/o)
Включаем iSCSI initiator
Настройка iSCSI initiator
Настройка MPIO
Включение виртуальных дисков

Устанавливаем MPIO (multipath i/o)

MPIO нужно настраивать на сервере к которому мы будет подключать диски. К серверу на котором будет стоять Роль iSCSI initiator

После добавления поддержки iSCSI устройств , сервер потребует перезагрузку!

Включаем iSCSI initiator

По умолчанию служба iSCSI остановлена. Чтобы использовать его, мы должны запустить службу. Чтобы запустить службу, откройте « Диспетчер серверов » -> Нажмите « Инструменты » и выберите « Инициатор iSCSI ». См. следующее изображение:

start-service MSiSCSI

Настройка iSCSI initiator

Перед настройкой , на всех интерфейсах которые будут взимодействовать с iscsi target сервером отключите IPV6

Чтобы настроить инициатор, откройте Диспетчер серверов -> Нажмите Инструменты и нажмите « Инициатор iSCSI ». Откроется диалоговое окно для его настройки. Здесь вы можете указать IP-адрес или DNS-имя целевого сервера iSCSI ИЛИ целевого портала iSCSI. См. следующее изображение:

Если на данном скриншоте у вас много дисков, перезагрузите ваш сервер. В совокупности при 2 подлеченных дисках , список должен состоять из 4 устройств.

Настройка MPIO

Здесь нам надо настроить политику использования путей. Выбирать можно из следующих вариантов:

• Fail Over Only — используется только один путь, указанный в качестве основного (active), остальные пути находятся в режиме ожидания (standby). При недоступности основного пути все подключения переводятся на резервный путь. Как только основной путь становится доступен, все подключения возвращаются обратно на основной путь;
• Round Robin — все возможные пути используются по очереди, для балансировки нагрузки;
• Round Robin with Subset — можно указать несколько основных путей, используемых как в предыдущем режиме Round Robin, а также один или несколько дополнительных путей. Пока доступен хотя бы один из основных путей, система использует их в режиме Round Robin. Если же ни один из основных путей недоступен, то используются дополнительные пути в порядке уменьшения приоритета. Когда восстанавливается работоспособность хотя бы одного из основных путей, система возвращается в режим балансировки.
• Least Queue Depth — запросы направляются на тот путь, который в данный момент имеет наименьшее число запросов в очереди;
• Weighted Paths — для каждого пути назначается некий вес (или стоимость), которая обозначает приоритет использования данного пути. Чем больше вес, тем ниже приоритет, соответственно для операций выбирается доступный путь с наименьшим приоритетом;
• Least Blocks — все запросы направляются на тот путь, в очереди которого на передачу стоит наименьшее число блоков данных.

Для обеспечения отказоустойчивости выберем самый простой вариант — политику Fail Over Only.

Включение виртуальных дисков

Источник

Windows Server 2019 – MPIO and iSCSI conectivity with Dell EMC SC Storage Series

This article is focused how to set up iSCSI connectivity with Windows Server 2019 (Hyper-V node) and DELL EMC SC 3020 (Compellent) Storage Series.

Infrastructure:

1x HPE DL360 g10 with 4×10 GbE SFP+ cards
- Windows Server 2019 (updated)
- 2x 10 GbE SFP+ adapters are in LACP 20 GbE – for VM and Production
- 2x 10 GbE SFP+ adapters are dedicated only for iSCSI traffic (never team iSCSI adapters !!!)
2x DELL EMC S4112 switches ( VLT configured)
1x DELL EMC SC3020 with 4×10 GbE SFP+ connectivity.( fault domain 1 and fault domain 2 configured)

IP configuration

HYPER1

iSCSI – PCIe Slot 1 Port 1 – 10.13.200.1
iSCSI – PCIe Slot 1 Port 2 – 10.13.201.1

SC3020

iSCSI-FD1-VIP – 10.13.200.200
iSCSI-FD1-TOP – 10.13.200.201
iSCSI-FD1-BOT – 10.13.200.202
iSCSI-FD2-VIP – 10.13.201.200
iSCSI-FD2-TOP – 10.13.201.201
iSCSI-FD2-BOT – 10.13.201.202

Download and install Dell Storage Manager Client

download and install latest DellEMCStorageClientWindows-19.1.20.30.zip (06. 10. 2020) from Dell EMC page

install it on your Windows Server 2019

Run DMS client as Administrator

run DSM Client and choose third option „Configure this host to access a Storage Center“

and log in to your Storage Center.

click > Next

please verify the connection for both FD, in my case:

iSCSI FD1- 10.13.200.200 is connected to Adapter 1 – 10.13.200.1
iSCSI FD2- 10.13.201.200 is connected to Adapter 1 – 10.13.201.1

and click to next.

Server is fully connected to both FD on SC3020 click to next

The host setup was Sucessful now we need reboot the Hyper-V host. „The preferred method to create a new server object on SC Series storage is to use the host configuration wizard on the launch screen of the Dell Storage Manager client. One of the main benefits of this method of server creation is the wizard will automatically adjust the host server MPIO time-out settings in the Windows registry to match the current best practices “

After reboot add the server in DSM console to your cluster and finish the host mapping.

Now open the MPIO and check, that COMPELNTCompellentVol is in MPIO Devices, if not go to the Discover Multi-Paths click on COMPELNTCompellentVol and click to „Add support to iSCCSI“ > reboot server.

go to the Disk Management click on Volume from Storage system and go to MPIO tab,

The MPIO policy is by default Round Robin and both paths are active ! 🙂

Once SC Series volumes are associated with the Microsoft DSM on a Windows server, no further steps are necessary unless changing the Windows default MPIO load balance policy is necessary. The default load balance policy on a Windows server can be changed system-wide or on a per-volume basis

Dell EMC SC Series Storage and Microsoft Multipath I/O

(Visited 3 106 times, 1 visits today)

Источник

В этой статье мы рассмотрим особенности реализации, установки и настройки MPIO в Windows Server 2016/2012 R2. MPIO (Multi—Path Input Output) или многопутевой ввод-вывод, это технология для построения отказоустойчивого транспорта к системе хранения данных (СХД) или выполняющему эти функции серверу за счет использования избыточных путей. Дополнительные пути между сервером и хранилищем создаются с использованием избыточных физических компонентов (коммутаторы, кабели, адаптеры или сетевые карты). Обратная сторона такой избыточности – операционная система может видеть один и тот же LUN по разным путям и считать их разными устройствами.

Если сервер может получить доступ к логическому диску (LUN) через несколько адаптеров инициатора iSCSI или несколько портов Fibre Channel, то в диспетчере устройств/дисков на системе без установленного MPIO модуля будет присутствовать большее количество LUN, чем презентовано на самом деле ( = количество путей к LUN * количество презентованных LUN).

На следующем скриншоте видно (список подключенных дисков можно вывести с помощью get-disk), что Windows видит без MPIO видит 2 диска по разным путям, которые по факту являются одним LUN:

Если ОС поддерживает MPIO, она будет видеть каждый из презентованных ей дисков в одном экземпляре. При включенном MPIO сервер может обращаться к данным на СХД по нескольким путям, что увеличивает скорость доступа к подключенному LUN и позволяет задействовать для доступа несколько сетевых или HBA-адаптеров.
MPIO может задействовать альтернативный логический путь при выходе из строя одного/нескольких компонентов, заставив операционную систему использовать для доступа к логическому диску (LUN) резервный маршрут, сохраняя непрерывность доступа к данным. Таким образом MPIO является важным компонентом при реализации отказоустойчивой системы доступа к данным, кроме того входящие в состав MPIO модули позволяют распределять нагрузку между различными путями к одному и тому же LUN-у.

Совет. Если ОС не поддерживает MPIO, то для предотвращения потери данных нужно уменьшить количество путей к LUN до 1. На сервере нужно оставить включенным только один порт Fiber Channel или адаптер iSCSI инициатора. Также нужно отключить дополнительные пути для данного LUN на уровне СХД и коммутаторов.

Содержание:

Установка MPIO в Windows Server 2016/2012R2
Настройка MPIO в Windows Server 2016
SAN Policy

Установка MPIO в Windows Server 2016/2012R2

Windows Server поддерживает многопутевой ввод-вывода MPIO начиная с версии Windows Server 2008 R2. Технология Microsoft MPIO позволяет обеспечить высокую доступность и балансировку нагрузки посредством возможности организации нескольких подключений к СХД, не зависит от протоколов и поддерживает подключение дисковых массивов и хранилищ по iSCSI, Fiber Channel и хранилищ SAS.

MPIO-модуль в Windows Server по умолчанию не включен. Установить его в Windows Server 2016 можно двумя способами:

Из графического интерфейса с использованием консоли Server Manager
Из командной строки Powershell

Установка MPIO с помощью консоли Server Manager

Откройте консоль Server Manager;
В списке компонентов (Features) найдите и активируйте опцию Multipath I/O;
Завершите установку компонента MPIO и перезагрузите сервер.

Установка MPIO с помощью Powershell

Запустите консоль PowerShell с правами администратора и для установки компонента выполните команду:

Add-WindowsFeature -Name 'Multipath-IO'

Чтобы убедиться, что модуль MPIO установлен в вашем Windows Server, выполните:

Get-WindowsFeature -Name 'Multipath-IO'

Примечание. Для отключения MPIO выполните команду:

Remove-WindowsFeature -Name 'Multipath-IO'

Настройка MPIO в Windows Server 2016

После установки MPIO модуля, необходимо активировать его для LUN, которые доступны по нескольким путям. По умолчанию ОС видит каждое подключение к диску как разные логические диски (LUN).

Совет. Одним из компонентов MPIO является специальный модуль MSDSM (Microsoft Device Service Module), позволяющий управлять политиками балансировки нагрузки. По умолчанию MPIO устанавливается со стандартным Microsoft DSM, однако в большинстве случаев стоит установить DSM модуль, предоставляемый производителем СХД (IBM DSM, HP DSM MPIO и т.д.). Обычно скорость работы и функционал нативного DSM модуля выше, чем у стандартного DSM-модуля Microsoft (производитель пишет свои DSM модули с учетом специфики работы и особенностей своего железа)/

Разрешите модулю DSM от Microsoft (MSDSM) автоматически объединять SAN диски в зависимости от типа подключений. MSDSM автоматически определяет наличие LUN, имеющих несколько путей к СХД и поддерживает большинство популярных систем хранения.

Сделать это можно из командной строки:

Для SAS дисков:
Enable-MSDSMAutomaticClaim -BusType SAS

Для iSCSI дисков:
Enable-MSDSMAutomaticClaim -BusType iSCSI

Примечание. Эту же операцию можно выполнить с помощью утилиты mpclaim (появившуюся в Windows 2008 R2). Следующая команда проанализирует все устройства, обнаруженные системой, определит какие из них имеют несколько путей и включит поддержку MPIO для них. Опция
-r
[automatically reboot (if needed) without prompting] разрешает автоматическую перезагрузку сервера:

mpclaim.exe -r -i -a ""

Также вы можете включить DSM через графический интерфейс. Откройте консоль управления Server Manager и в меню Tools выберите пункт MPIO (или выполните команду mpiocpl).

Перейдите на вкладку Discover Multi—Paths, включите опцию Add support for SAS devices (или Add support for iSCSI devices, если вы используете iSCSI хранилище) и нажмите Add. После этого перезагрузите сервер.

После перезагрузки откройте диспетчер устройств или диспетчер дисков и убедитесь, что количество подключенных дисков (LUN), доступных серверу уменьшилось в 2 раза (при наличии подключений к СХД по двум путям).

Вы можете управлять списком устройств, для которых включена поддержка MPIO на вкладке MPIO Devices (или командой
Get-MSDSMSupportedHw
).

Вы можете добавить новые MPIO устройства, нажав кнопку Add или из PowerShell:

New-MSDSMSupportedHw -VendorId <vend> -ProductId <product>

При настройке кластера конфигурацию MPIO необходимо выполнить на всех узлах.

Если вы подключаете iSCSI таргет по 2 путям и хотите использовать MPIO для этого подключения, нужно при подключении Target выбрать iSCSI LUN, нажать кнопку Connect и включить опцию Enable multi—path.

Затем нажмите на кнопку Advanced и привяжите разные IP адреса инициатора к разным IP адресами target.

С помощью PowerShell можно получить текущие настройки MPIO:

Get-MPIOSetting

PathVerificationState     : Disabled
PathVerificationPeriod    : 30
PDORemovePeriod           : 20
RetryCount                : 3
RetryInterval             : 1
UseCustomPathRecoveryTime : Disabled
CustomPathRecoveryTime    : 40
DiskTimeoutValue          : 60

Можно изменить настройки MPIO таймеров так (например, установим рекомендованные настройки для flash массива):

Set-MPIOSetting -NewPathRecoveryInterval 20 -CustomPathRecovery Enabled -NewPDORemovePeriod 30 -NewDiskTimeout 60 -NewPathVerificationState Enabled

Доступны следующие политики балансировки MPIO:

FOO — Fail Over Only
RR — Round Robin
LQD — Least Queue Depth
LB — Least Blocks

Чтобы задать политику балансировки (например, Round Robin):

Set-MSDSMGlobalLoadBalancePolicy -Policy RR

Также политику балансировки можно изменить в свойствах подключенного LUN на вкладке MPIO. В этом примере для массива выбрана политика Round Robin.

Чтобы увидеть полный список PowerShell команд, доступных в модуле MPIO, выполните команду:

Get-Command –Module Mpio

SAN Policy

В Windows имеется специальная политика дисков (SAN Policy), которая определяет, нужно ли автоматически монтировать диски при их подключении к хосту.

Текущую настройку SAN Policy можно получить с помощью diskpart. По умолчанию используется SAN политика Offline Shared.

Чтобы автоматически монтировать диски, нужно изменить значение SAN Policy на OnlineAll.

DISKPART> san policy=OnlineAll

Возможные значение SAN policy:

OfflineAll	Все диски по умолчанию в offline режиме
OfflineInternal	Все диски на внутренних шинах в offline
OfflineShared	Все диски, подключенные через iSCSI, FC или SAS в offline
OnlineAll	Все диски автоматически переводятся в онлайн режим (рекомендуется)

Источник

При хранении критически важных данных обеспечение высокой доступности является одной из основных задач. Для высокодоступных решений необходимо обеспечить избыточность на разных уровнях: на уровне дисковой подсистемы, на уровне транспорта, на уровне сервера или системы хранения. Одним из механизмов, предназначенных для обеспечения высокой доступности на транспортном уровне, является технология многопутевого ввода-вывода (Multi-Path Input-Output, MPIO).

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

Однако недостаточно просто подключить к серверу один LUN по нескольким путям. Операционная система не сможет понять, что она видит одно и то же устройство и подключит его дважды. Это чревато тем, что данные на диске будут перезаписаны или повреждены.

Технология MPIO как раз и предназначена для того, чтобы система видела каждый из презентованных ей дисков в единственном экземпляре. При наличии нескольких путей между сервером и устройством хранения MPIO обеспечивает маршрутизацию операций вводавывода по этим путям и перенаправление запросов в случае сбоя одного из путей. MPIO в Windows Server 2012 позволяет операционной системе определять и использовать до 32 путей между сервером и устройством хранения.

MPIO не зависит от протокола и может использоваться с интерфейсами Fibre Channel, Internet SCSI (iSCSI) и Serial Attached SCSI (SAS). В Windows Server MPIO состоит из двух элементов: компонента операционной системы под названием Multipath I/O и специального программного модуля Device-Specific Module (DSM). Модуль DSM поставляется производителем СХД и обеспечивает работу Microsoft MPIO с данной конкретной моделью оборудования. Кроме того, в Windows Server 2012 есть встроенный DSM, который также можно использовать с различными СХД.

Примечание. Для работы с Microsoft DSM система хранения должна поддерживать SCSI Primary Commands-3 (SPC-3).

В предыдущей статье была описана настройка хранилища iSCSI на базе Windows Server 2012. Продолжая эту тему, я опишу настройку MPIO для обеспечения отказоустойчивости при подключении по iSCSI. В качестве хранилища выступает сервер SRV2 c установленной ролью iSCSI Target, в качестве клиента сервер SRV3. На каждом сервере несколько сетевых интерфейсов, подключенных к разным свичам для обеспечения большей надежности.

Все настройки будут производиться на клиенте, поэтому подключаемся к SRV3 и приступаем.

Установка компонента Multipath I/O

MPIO в Windows Server 2012 является дополнительным компонентом (Feature) и по умолчанию неактивен. Установить его можно из оснастки Server Manager, запустив мастер добавления ролей и компонентов и выбрав компонент Multipath I/O.

Также для включения MPIO мы можем воспользоваться PowerShell. Сначала проверяем состояние компонента:

Get-WindowsOptionalFeature -Online -FeatureName MultiPathIO

И если он неактивен (disabled), устанавливаем его:

Enable-WindowsOptionalFeature -Online -FeatureName MultiPathIO

Включение MPIO для iSCSI

Сама по себе установка компонента еще не означает, что система определит диски правильно. Поэтому следующим шагом является включение MPIO для iSCSI, для чего нам понадобится оснастка MPIO. Для ее запуска в Server Manager открываем меню Tools и выбираем пункт MPIO, либо нажимаем Win+R и вводим команду mpiocpl.exe.

Для включения поддержки MPIO для устройств iSCSI переходим на вкладку «Discover Multi-Paths», отмечаем чекбокс «Add support for iSCSI devices» и жмем кнопку Add.

После чего перезагружаем сервер.

Настройка MPIO для iSCSI

Теперь, когда MPIO включен и доступен для использования, приступим к подключению iSCSI устройств. Открываем оснастку iSCSI Initiator, переходим на вкладку «Discovery», жмем кнопку «Discover Portal» и вводим один из IP-адресов (любой) сервера SRV2, на котором запущен iSCSI Target.

Переходим на вкладку Targets, выбираем наш таргет и жмем «Properties» для перехода к его свойствам.

В свойствах откроем вкладку «Portal Groups», на которой отображены все доступные пути до выбраного таргета. Выберем два из них.

Теперь переходим на вкладку «Sessions» и жмем на кнопку «Add session».

Отмечаем чекбокс «Enable multi-path» и жмем «Advanced» для перехода к дополнительным настройкам.

В дополнительных настройках в поле «Initiator IP» выбираем адрес локального интерфейса, а в поле «Target portal IP» — соответствующий адрес iSCSI-сервера. Как видите, оба IP находятся в одной подсети. Таким образом мы определяем путь, по которому будет производиться подключение к iSCSI Target на SRV2. Жмем OK, затем таким же способом добавляем второй путь.

Теперь надо сконфигурировать диск iSCSI для использования MPIO. Возвращаемся на вкладку «Sessions», выбираем обе сессии и жмем кнопку «Devices».

В списке у нас одно устройство — Disk 1. Выбираем его и жмем кнопку MPIO.

Здесь нам надо настроить политику использования путей. Выбирать можно из следующих вариантов:

Для обеспечения отказоустойчивости выберем самый простой вариант — политику Fail Over Only.

Кроме того, выбрав путь и кликнув на «Details» можно посмотреть подробности этого подключения.

А по кнопке «Edit» — выбрать активный путь (для Fail Over Only) или указать вес пути (для Weighted Paths).

Настройка MPIO с помощью PowerShell

Управлять MPIO можно и с помощью PowerShell, где для этого есть специальный модуль. Выведем все командлеты этого модуля командой:

Get-Command -Module MPIO

Так например можно включить MPIO для iSCSI:

Enable-MSDSMAutomaticClaim -BusType iSCSI

Так настроить политику Fail Over Only :

Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy FOO

А вот так посмотреть все доступные для MPIO устройства iSCSI:

Get-MPIOAvailableHW -BusType iSCSI

Также стоит упомянуть о дополнительных параметрах MPIO, доступных из консоли PowerShell. Вывести их можно командой Get-MPIOSetting. Это настройки таймера, которые отвечают за таймауты при переключении:

• PathVerificationState — определяет, нужна ли проверка доступности пути;
• PathVerificationPeriod — указывает время в секундах, в течение которого сервер будет проверять каждый путь. Этот параметр действует только при включенном параметре PathVerificationState;
• PDORemovePeriod — задает время в секундах, по истечении которого физическое устройство будет полностью удалено, если все пути к устройству недоступны;
• RetryCount — задает количество повторов запроса вводавывода;
• RetryInterval — задает период времени, по истечении которого сервер повторяет попытку запроса вводавывода;
• UseCustomPathRecoveryTime — указывает, задавать ли вручную период восстановления. Если этот параметр отключен, то используется удвоенное значение PDORemovePeriod;
• CustomPathRecoveryTime — задает период времени в секундах, по истечении которого выполняется попытка восстановления подключения. Этот параметр действует только при включенном UseCustomPathRecoveryTime;
• DiskTimeoutValue — указывает, сколько времени должен ожидать сервер перед тем, как считать запрос вводавывода к диску истекшим.

В большинстве случаев эти параметры можно оставить без изменения, однако в некоторых ситуациях для получения оптимальной производительности может потребоваться их изменить. К примеру, если используется отказоустойчивый кластер и балансировка нагрузки по нескольким путям, то уменьшение таймаута может ускорить переключение между узлами. И наоборот, для одиночного сервера некоторые из значений можно увеличить, для обеспечения большей надежности.

Для изменения этих параметров воспользуемся командой Set-MPIOSetting. Для примера изменим таймаут переключения диска:

Set-MPIOSetting -NewDiskTimeout 30

Напомню, что при изменении параметров MPIO может потребоваться перезагрузка сервера.

Примечание. Также сконфигурировать MPIO можно c помощью утилиты командной строки mpclaim.exe. Для просмотра ее возможностей наберите в командной строке mpclaim /?.

Отработка отказа

После завершения настройки необходимо протестировать получившуюся конфигурацию. Для этого запускаем копирование на общий диск, а затем отключаем один сетевой интерфейс, обеспечивавший активный путь. Копирование приостанавливается, скорость падает до нуля

Но по истечении таймаута процесс возобновляется и успешно завершается.

А если теперь посмотреть в настройки устройства, то мы увидим, что переключение произошло и запасной путь стал активным.

Таким образом с помощью MPIO мы настроили отказоустойчивое подключение к хранилищу iSCSI.

В завершение напомню, что в данной статье приведен вариант настройки MPIO с использованием встроенного модуля Microsoft DSM. При использовании системы хранения других производителей рекомендуется использовать DSM, поставляемое с этим оборудованием, соответственно процедура настройки будет отличаться.

Источник

Содержание

Настройка функции Multipath I/O для устройства StorSimple
Общие сведения о конфигурации MPIO
Шаг 1. Установка MPIO на узле Windows Server
Установка MPIO на узле
Шаг 2. Настройка MPIO для томов StorSimple
Настройка MPIO для томов StorSimple
Шаг 3. Подключение томов StorSimple на узле
Подключение томов на узле
Шаг 4. Настройка MPIO для обеспечения высокого уровня доступности и балансировки нагрузки
Настройка MPIO для обеспечения высокого уровня доступности и балансировки нагрузки
How to Enable and Configure MPIO on Windows Server 2016/2012R2?
Installing MPIO Installation on Windows Server 2016/2012R2
Enable MPIO Using Server Manager
Installing Multipath-IO Using PowerShell
Configuring MPIO on Windows Server 2016
SAN (Disk) Policy on Windows Server
Объединение сетевых карт
Доступность
Поддерживаемые и неподдерживаемые сетевые карты
Совместимость
Очереди виртуальных машин (ВМКС)
Виртуализация сети Hyper-V (HNV)
Динамическая миграция
Виртуальные локальные сети (VLAN)
Использование виртуальных ЛС с объединением сетевых карт в виртуальной машине
Управление сетевыми интерфейсами и виртуальными ЛС
виртуальные машины;
Сетевые адаптеры с поддержкой SR-IOV
Связанные темы

Настройка функции Multipath I/O для устройства StorSimple

В этом руководстве рассматриваются действия, которые необходимо выполнить для установки и использования функции MPIO (Multipath I/O) на узле под управлением Windows Server 2012 R2, который подключен к физическому устройству StorSimple. Рекомендации в этой статье относятся только к физическим устройствам StorSimple серии 8000. Сейчас функция MPIO не поддерживается для облачных устройств StorSimple.

Корпорация Майкрософт обеспечила встроенную поддержку функции Multipath I/O (MPIO) в Windows Server для создания высокодоступных и отказоустойчивых конфигураций сети iSCSI. С помощью избыточных компонентов физических путей — адаптеров, кабелей и коммутаторов — функция MPIO создает логические пути между сервером и устройством хранения. Если возникает сбой компонента, который вызывает отказ логического пути, многопутевая логика использует альтернативный путь для ввода-вывода, а приложения при этом сохранят доступ к данным. Кроме того, в некоторых конфигурациях MPIO может повысить производительность благодаря балансировке нагрузки между этими путями. Дополнительные сведения см. в обзоре MPIO.

Для высокого уровня доступности решения StorSimple следует настроить MPIO для устройства StorSimple. Если MPIO устанавливается на базовых серверах, работающих под управлением Windows Server 2012 R2, серверы смогут выдержать сбой канала, сети или интерфейса.

Общие сведения о конфигурации MPIO

MPIO представляет собой дополнительный компонент, который по умолчанию не устанавливается в Windows Server. Его необходимо устанавливать в качестве отдельного компонента через диспетчер сервера.

Чтобы настроить MPIO на устройстве StorSimple, выполните следующие действия:

В следующих разделах рассматриваются все перечисленные выше действия.

Шаг 1. Установка MPIO на узле Windows Server

Чтобы установить этот компонент на узле Windows Server, выполните следующую процедуру.

Установка MPIO на узле

Откройте диспетчер сервера на узле Windows Server. По умолчанию диспетчер сервера запускается, когда член группы администраторов выполняет вход на компьютер под управлением Windows Server 2012 R2 или Windows Server 2012. Если диспетчер сервера не открыт, щелкните Пуск > Диспетчер сервера.

Выберите Диспетчер сервера > Панель мониторинга > Добавить роли и компоненты. Это запускает мастер Добавление ролей и компонентов wizard.

В мастере Добавление ролей и компонентов выполните следующие шаги.

На странице Перед работой нажмите кнопку Далее.

На странице Выбор типа установки выберите вариант по умолчанию Установка ролей или компонентов. Щелкните Далее.

На странице Select destination server (Выбор целевого сервера) выберите Select a server from the server pool (Выбрать сервер из пула серверов). Сервер должен быть найден автоматически. Щелкните Далее.

На странице Выбор ролей сервера нажмите кнопку Далее.

На странице Выбор компонентов выберите Multipath I/O и нажмите кнопку Далее.

На странице Подтверждение установки компонентов проверьте выбранные компоненты и установите флажок Автоматический перезапуск конечного сервера, если требуется, как показано ниже. Нажмите кнопку Установить.

Вы получите уведомление, когда установка закончится. Нажмите кнопку Закрыть, чтобы завершить работу мастера.

Шаг 2. Настройка MPIO для томов StorSimple

Настройка MPIO требуется для идентификации томов StorSimple. Чтобы настроить MPIO для распознавания томов StorSimple, выполните следующие действия.

Настройка MPIO для томов StorSimple

Шаг 3. Подключение томов StorSimple на узле

После настройки MPIO на сервере Windows тома, созданные на устройстве StorSimple, можно будет подключить и они смогут воспользоваться преимуществами MPIO для обеспечения избыточности. Чтобы подключить том, выполните следующие действия.

Подключение томов на узле

Откройте окно Свойства инициатора iSCSI на узле Windows Server. Выберите Диспетчер серверов > Панель мониторинга > Сервис > Инициатор iSCSI.

В диалоговом окне iSCSI Initiator Properties (Свойства инициатора iSCSI) перейдите на вкладку «Обнаружение» и нажмите кнопку Обнаружение целевого портала.

В диалоговом окне Обнаружение целевого портала выполните следующие шаги.

Введите IP-адрес порта DATA для устройства StorSimple (например, введите «DATA 0»).

Нажмите кнопку OK, чтобы вернуться к диалоговому окну Свойства инициатора iSCSI.

При использовании частной сети для подключения iSCSI введите IP-адрес порта данных, подключенного к частной сети.

Повторите шаги 2–3 для установки второго сетевого интерфейса (например, DATA 1) на устройстве. Помните, что эти интерфейсы должны поддерживать iSCSI. Дополнительные сведения см. в разделе Изменение сетевых интерфейсов.

Перейдите на вкладку Целевые объекты в диалоговом окне Свойства инициатора iSCSI. На вкладке Обнаруженные целевые объекты должен быть целевой IQN устройства StorSimple.

Щелкните Подключение для установления сеанса iSCSI с устройством StorSimple. Появится диалоговое окно Подключение к конечному объекту.

В диалоговом окне Подключение к целевому объекту установите флажок Включить поддержку многопутевых накопителей. Щелкните Дополнительно.

В диалоговом окне Дополнительные параметры выполните следующие шаги.

Нажмите кнопку Свойства. В диалоговом окне Свойства нажмите кнопку Добавить сеанс.

В диалоговом окне Дополнительные параметры:

Откройте Управление компьютером, для чего выберите Диспетчер серверов > Панель мониторинга > Управление компьютером. В левой области щелкните Хранилище > Управление дисками. Видимые для текущего узла тома, созданные на устройстве StorSimple, отображаются на вкладке Управление дисками в качестве новых дисков.

Инициализируйте диск и создайте новый том. При форматировании выберите размер блока 64 КБ.

В разделе Управление дисками щелкните правой кнопкой мыши Диск и выберите Свойства.

В диалоговом окне Свойства многопутевого диска StorSimple модели #### щелкните вкладку MPIO.

В разделе Имя DSM выберите сведения и убедитесь, что параметры имеют значения по умолчанию. Используются следующие параметры по умолчанию.

Не изменяйте параметры по умолчанию.

Шаг 4. Настройка MPIO для обеспечения высокого уровня доступности и балансировки нагрузки

Чтобы реализовать высокий уровень доступности и балансировку нагрузки на основе нескольких путей ввода-вывода, необходимо вручную добавить несколько сеансов, чтобы объявить о наличии разных путей. Например, если узел имеет два интерфейса, подключенные к сети iSCSI, и устройство имеет два интерфейса, подключенные к сети iSCSI, потребуется четыре сеанса с настроенными путями (потребуется только два сеанса, если каждый интерфейс DATA и интерфейс узла находятся в разных подсетях IP и не поддерживают маршрутизацию).

Мы рекомендуем использовать по крайней мере 8 активных параллельных сеансов между устройством и узлом приложения. Это можно сделать, включив 4 сетевых интерфейса в системе Windows Server. Используйте физические сетевые интерфейсы или виртуальные интерфейсы (с помощью технологий виртуализации сети) на уровне оборудования или операционной системы на узле Windows Server. При наличии двух сетевых интерфейсов на устройстве эта конфигурация образует 8 активных сеансов. Такая конфигурация позволяет оптимизировать пропускную способность устройства и облака.

Мы рекомендуем не смешивать сетевые интерфейсы 1 и 10 GbE. При использовании двух сетевых интерфейсов оба интерфейса должны иметь одинаковый тип.

Далее рассматривается добавление сеансов для случая, когда устройство StorSimple с двумя сетевыми интерфейсами подключено к узлу с двумя сетевыми интерфейсами. Это дает только 4 сеанса. Используйте эту процедуру для устройства StorSimple с двумя сетевыми интерфейсами, подключенного к узлу с четырьмя сетевыми интерфейсами. Понадобится настроить 8 сеансов вместо 4, описанных здесь.

Настройка MPIO для обеспечения высокого уровня доступности и балансировки нагрузки

Выполните обнаружение целевого объекта. Для этого в диалоговом окне iSCSI Initiator Properties (Свойства инициатора iSCSI) на вкладке Обнаружение щелкните Обнаружить портал.

В диалоговом окне Подключение к целевому объекту укажите IP-адрес одного из сетевых интерфейсов устройства.

Нажмите кнопку OK, чтобы вернуться к диалоговому окну Свойства инициатора iSCSI.

В диалоговом окне Свойства инициатора iSCSI перейдите на вкладку Целевые объекты, выделите обнаруженный целевой объект и щелкните Подключить. Откроется диалоговое окно Подключение к целевому объекту.

В диалоговом окне Подключение к целевому объекту:

В диалоговом окне Дополнительные параметры:

Щелкните Свойства и в диалоговом окне Свойства щелкните Добавить сеанс.

В диалоговом окне Подключение к целевому объекту установите флажок Включить поддержку многопутевых накопителей и затем щелкните Дополнительно.

В диалоговом окне Дополнительные параметры:

Повторите шаги 8–10, чтобы добавить дополнительные сеансы (пути) в целевой объект. С двумя интерфейсами на узле и двумя на устройстве можно добавить не более четырех сеансов.

После добавления необходимых сеансов (путей) в диалоговом окне Свойства инициатора iSCSI выберите целевой объект и щелкните Свойства. На вкладке «Сеансы» диалогового окна Свойства обратите внимание на четыре идентификатора сеансов, которые соответствуют возможным перестановкам путей. Чтобы отменить сеанс, установите флажок рядом с идентификатором сеанса и затем нажмите Отключить.

Чтобы просмотреть устройства, представленные в сеансах, перейдите на вкладку Устройства. Чтобы настроить политику MPIO для выбранного устройства, щелкните MPIO. Откроется диалоговое окно Сведения об устройстве. На вкладке MPIO можно выбрать соответствующие параметры Политики балансировки нагрузки. Можно также просмотреть активный или ждущий тип пути.

Источник

How to Enable and Configure MPIO on Windows Server 2016/2012R2?

In this article we will consider how to install and configure MPIO on Windows Server 2016/2012 R2. MPIO (Multi—Path Input Output) is a technology that allows to build fault-tolerant transport to a data storage system (or a storage server) by using redundant paths. Additional paths between a server and a storage are created using redundant physical components (switches, cables, adapters or NICs). This redundancy type has a drawback: an operating system may see the same LUN at different paths and treat it as different drives.

The following screenshot shows that Windows without MPIO sees 2 drives with different paths, which are in fact the same LUN (the list of presented disks may be displayed using the Get-Disk PowerShell cmdlet).

If the OS supports MPIO, it will see each of the disks presented to it in one copy. If MPIO is enabled, a server may access data on a storage using multiple paths that makes access to a connected LUN faster and allows using multiple network or HBA adapters.
MPIO may use an alternative logical path if one or more components fail, thus making an operating system use another route to access a logical disk (LUN) maintaining data access consistency. So, MPIO is an important component of a fail-tolerant storage and data access system, and MPIO modules can distribute the load on the same LUN across different paths.

Installing MPIO Installation on Windows Server 2016/2012R2

Windows Server supports multi-path input output (MPIO) starting from Windows Server 2008 R2. Microsoft MPIO provides high availability and load balancing using multiple connections to a storage, doesn’t depend on any protocols and supports disk array and storage connection using iSCSI, Fiber Channel and SAS.

By default, MPIO module is disabled on Windows Server. There are two ways to install it in Windows Server 2016:

Enable MPIO Using Server Manager

Installing Multipath-IO Using PowerShell

Run the PowerShell console as an administrator and use the following command to install the Windows Server feature:

To make sure that MPIO has been installed on your Windows Server, run this command:

Configuring MPIO on Windows Server 2016

After installing the MPIO module, you need to activate it for the LUNs that are available by multiple paths. By default, Windows sees each connection to a disk as different logical disks (LUNs).

Allow the DSM module by Microsoft (MSDSM) to automatically merge SAN disks based on the connection type. MSDSM automatically detects LUNs that have multiple paths to a storage and supports most popular storage devices.

You can do it from the command prompt:

You can also enable DSM in the GUI. Open the Server Manager and select MPIO in the Tools menu (or run the command: mpiocpl ).

Go to the Discover Multi—Paths tab, check Add support for SASdevices (or Add supportfor iSCSI devices if you are using iSCSI storage) and click Add. Then restart your server.

After the restart, open the Device Manager (or the Disk Manager) and make sure that the number of connected disks (LUNs) available to your server has reduced twice (if there are two paths to your storage device).

You can manage the list of devices with MPIO support enabled in the MPIO Devices tab (or using the Get-MSDSMSupportedHw command).

You can add new MPIO devices by clicking Add or from PowerShell:

If you connect an iSCSI target via 2 paths and want to use MPIO for it, select iSCSI LUN when you connect a Target, click Connect and check the Enable multi—path option.

Then click Advanced and bind different initiator IP addresses to different target IP addresses.

You can get current MPIO settings using PowerShell:

You can change MPIO timer settings as follows (for example, let’s enable recommended settings for the all-flash array):

The following MPIO balancing policies are available:

To change a balancing policy:

You can also select the balancing policy in the MPIO tab of the connected LUN properties. In this example, the Round Robin policy is selected for the array.

To view the full list of PowerShell commands available in the MPIO module, run this command:

Get-Command –Module Mpio

SAN (Disk) Policy on Windows Server

Windows has a special disk policy (SAN Policy) that determines whether disks must be mounted automatically when they are connected to a host.

To mount the drives automatically, change the SAN Policy value to OnlineAll.

Источник

Объединение сетевых карт

Область применения: Windows Server 2022, Azure Stack HCI, версия 20H2; Windows Server 2019; Windows Server 2016

в этом разделе представлен обзор объединения сетевых карт (NIC) в Windows Server. Объединение сетевых карт позволяет объединять один и 32 физических сетевых адаптеров Ethernet в один или несколько программных виртуальных сетевых адаптеров. Эти виртуальные сетевые адаптеры обеспечивают высокую производительность и отказоустойчивость в случае сбоя сетевого адаптера.

Сетевые адаптеры члена группы сетевой карты необходимо установить на одном физическом компьютере узла.

Группа сетевых адаптеров, которая содержит только один сетевой адаптер, не может обеспечить балансировку нагрузки и отработку отказа. Однако с помощью одного сетевого адаптера можно использовать объединение сетевых карт для разделения сетевого трафика при использовании виртуальных локальных сетей (VLAN).

При настройке сетевых адаптеров в команде сетевой карты они подключаются к общему ядру решения для объединения сетевых карт, который затем представляет собой один или несколько виртуальных адаптеров (также называемых сетевыми интерфейсами группы [Тникс] или командные интерфейсы) в операционной системе.

поскольку Windows Server 2016 поддерживает до 32 командных интерфейсов на одну группу, существует множество алгоритмов, которые распределяют исходящий трафик между сетевыми картами. На следующем рисунке показана группа сетевых адаптеров с несколькими Тникс.

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

Доступность

Объединение сетевых карт доступно во всех версиях Windows Server 2016. Для управления объединением сетевых карт с компьютеров, работающих под управлением клиентской операционной системы, можно использовать разнообразные средства, например:

Поддерживаемые и неподдерживаемые сетевые карты

вы можете использовать любой сетевой адаптер Ethernet, прошедший проверку Windows оборудования и проверки логотипов (WHQL tests) в группе сетевых адаптеров в Windows Server 2016.

Вы не можете разместить следующие сетевые карты в группе сетевых адаптеров:

Виртуальные сетевые адаптеры Hyper-V, которые являются портами виртуального коммутатора Hyper-V, предоставленными в виде сетевых карт в разделе узла.

Не размещайте виртуальные сетевые карты Hyper-V, представленные в разделе узла (vNIC), в группе. Объединение vNIC внутри раздела узла не поддерживается ни в какой конфигурации. Попытки команды vNIC могут привести к потере связи, если произошел сбой сети.

Сетевой адаптер отладки ядра (КДНИК).

Сетевые карты, используемые для сетевой загрузки.

сетевые карты, использующие технологии, отличные от Ethernet, такие как WWAN, WLAN/Wi-Fi, Bluetooth и Infiniband, включая сетевые адаптеры по протоколу infiniband (IPoIB).

Совместимость

объединение сетевых карт совместимо со всеми сетевыми технологиями в Windows Server 2016 со следующими исключениями.

Виртуализация ввода-вывода с одним корнем (SR-IOV). Для SR-IOV данные доставляются непосредственно в сетевую карту, не передавая их через сетевой стек (в операционной системе узла, в случае виртуализации). Поэтому Группа сетевых адаптеров не может проверить или перенаправить данные в другой путь в группе.

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

TCP Chimney. TCP Chimney не поддерживается при объединении сетевых карт, так как TCP Chimney разгружает весь сетевой стек непосредственно на сетевой адаптер.

Проверка подлинности 802.1 x. Не следует использовать проверку подлинности 802.1 X с объединением сетевых карт, так как некоторые коммутаторы не допускают настройку проверки подлинности 802.1 X и объединения сетевых карт на одном и том же порте.

Дополнительные сведения об использовании объединения сетевых карт в виртуальных машинах, работающих на узле Hyper-V, см. в статье Создание группы сетевых адаптеров на главном компьютере или виртуальной машине.

Очереди виртуальных машин (ВМКС)

ВМКС — это функция сетевого интерфейса, которая выделяет очередь для каждой виртуальной машины. Когда Hyper-V включен; также необходимо включить VMQ. в Windows Server 2016 вмкс использовать NIC Switch впортс с одной очередью, назначенной впорт, для предоставления тех же функций.

В зависимости от режима конфигурации коммутатора и алгоритма распределения нагрузки объединение сетевых карт представляет собой минимальное количество доступных и поддерживаемых очередей любым адаптером в группе (режим min-Queues) или общее число очередей, доступных для всех участников группы (режим SUM-of-Queues).

Если команда находится в режиме объединения Switch-Independent и вы устанавливаете распределение нагрузки в режим порта Hyper-V или динамический режим, число сообщаемых очередей — это сумма всех очередей, доступных для членов группы (режим SUM-of-Queues). В противном случае количество очередей в отчете является наименьшим числом очередей, поддерживаемых любым участником команды (режим min-Queues).

Для этого есть следующие причины.

Если независимая команда находится в режиме порта Hyper-V или в динамическом режиме, входящий трафик для порта коммутатора Hyper-V (ВМ) всегда поступает на один и тот же участник команды. Узел может предсказать или контролировать, какой член получает трафик для конкретной виртуальной машины, чтобы объединение сетевых карт было более продуманным, чем очереди VMQ, выделяемые для конкретного участника команды. Объединение сетевых карт, работа с коммутатором Hyper-V, устанавливает VMQ для виртуальной машины на точно одном члене команды и определяет, что входящий трафик поступает в эту очередь.

Если команда находится в любом режиме, зависимом от переключения (статическое объединение или объединение LACP), коммутатор, к которому подключена команда, управляет распределением входящего трафика. Программному обеспечению для объединения сетевых карт не удается предсказать, какой член команды получает входящий трафик для виртуальной машины. возможно, коммутатор распределяет трафик для виртуальной машины по всем членам группы. В результате работы программы объединения сетевых карт, работающей с коммутатором Hyper-V, программа программирует очередь для виртуальной машины на всех участниках группы, а не только на одном члене команды.

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

Большинство сетевых адаптеров используют очереди для масштабирования на стороне приема (RSS) или VMQ, но не в одно и то же время. Некоторые параметры VMQ выглядят как параметры для очередей RSS, но являются параметрами универсальных очередей, которые используются как для RSS, так и для VMQ в зависимости от того, какая функция используется в настоящее время. Каждая сетевая карта имеет в своих дополнительных свойствах значения для * Рссбасепрокнумбер и * максрсспроцессорс. Ниже приведены несколько параметров VMQ, обеспечивающих лучшую производительность системы.

В идеале для каждой сетевой карты необходимо, чтобы для параметра * Рссбасепрокнумбер было установлено четное число, большее или равное двум (2). Первый физический процессор, ядро 0 (логические процессоры 0 и 1) обычно выполняет большую часть системной обработки, поэтому сетевая обработка должна отойти от этого физического процессора. Некоторые архитектуры компьютеров не имеют двух логических процессоров на один физический процессор, поэтому для таких компьютеров базовый процессор должен быть больше или равен 1. Если вы сомневаетесь в том, что ваш узел использует 2 логических процессора на архитектуру физического процессора.

Если команда находится в режиме суммирования очередей, процессоры членов группы должны быть не перекрывающиеся. Например, в 4-ядерном хосте (8 логических процессорах) с группой из 2 10 Гбит/сетевых интерфейсов можно установить первый из них, чтобы использовать базовый процессор 2 и использовать 4 ядра; второй будет установлен для использования базового процессора 6 и 2 ядер.

Если команда работает в Min-Queues режиме, наборы процессоров, используемые членами команды, должны быть идентичны.

Виртуализация сети Hyper-V (HNV)

Объединение сетевых карт полностью совместимо с виртуализацией сети Hyper-V (HNV). Система управления HNV предоставляет сведения о драйвере объединения сетевых карт, который позволяет объединением сетевых карт распределить нагрузку таким образом, чтобы оптимизировать трафик HNV.

Динамическая миграция

Объединение сетевых карт в виртуальных машинах не влияет на динамическая миграция. Существуют те же правила, что и для динамическая миграция настройки объединения сетевых карт в виртуальной машине.

Виртуальные локальные сети (VLAN)

При использовании объединения сетевых карт создание нескольких интерфейсов команды позволяет узлу подключаться к разным виртуальным ЛС одновременно. Настройте среду, следуя приведенным ниже рекомендациям.

Перед включением объединения сетевых карт настройте порты физического коммутатора, подключенные к узлу Teaming, для использования режима магистрали (неизбирательного). Физический коммутатор должен передавать весь трафик на узел для фильтрации без изменения трафика.

Не настраивайте фильтры VLAN на сетевых адаптерах с помощью параметров дополнительных свойств сетевого адаптера. Разрешите программе объединения сетевых карт или виртуальному коммутатору Hyper-V (при наличии) выполнить фильтрацию виртуальных ЛС.

Использование виртуальных ЛС с объединением сетевых карт в виртуальной машине

Когда команда подключается к виртуальному коммутатору Hyper-V, все разделение виртуальных ЛС должно выполняться в виртуальном коммутаторе Hyper-V, а не в группе объединения сетевых карт.

Запланируйте использование виртуальных ЛС на виртуальной машине, настроенной с помощью группы сетевых адаптеров, по следующим рекомендациям.

Предпочтительным способом поддержки нескольких виртуальных ЛС в виртуальной машине является настройка виртуальной машины с несколькими портами на виртуальном коммутаторе Hyper-V и связывание каждого порта с виртуальной ЛС. Никогда не указывайте эти порты на виртуальной машине, так как это вызывает проблемы с сетевым подключением.

Если виртуальная машина имеет несколько виртуальных функций SR-IOV (VFs), убедитесь, что они находятся в одной виртуальной ЛС, прежде чем они будут объединены в виртуальную машину. Вы можете легко настроить различные VFs в различных виртуальных ЛС, и это приведет к проблемам с сетевыми подключениями.

Управление сетевыми интерфейсами и виртуальными ЛС

переименуйте интерфейсы с помощью команды Windows PowerShell rename-NetAdapter или путем выполнения следующей процедуры:

В диспетчер сервера в свойствах сетевого адаптера, который требуется переименовать, щелкните ссылку справа от имени сетевого адаптера.

Щелкните правой кнопкой мыши сетевой адаптер, который необходимо переименовать, и выберите команду Переименовать.

Введите новое имя для сетевого адаптера и нажмите клавишу ВВОД.

виртуальные машины;

Если вы хотите использовать объединение сетевых карт на виртуальной машине, необходимо подключить виртуальные сетевые адаптеры виртуальной машины только к внешним коммутаторам Hyper-V. Это позволяет виртуальной машине поддерживать сетевое подключение даже в случае сбоя одного из физических сетевых адаптеров, подключенных к одному виртуальному коммутатору, или отключения. Виртуальные сетевые адаптеры, подключенные к внутренним или частным виртуальным коммутаторам Hyper-V, не могут подключиться к коммутатору, если они находятся в группе, и для виртуальной машины не удалось выполнить сетевые подключения.

объединение сетевых карт в Windows Server 2016 поддерживает команды с двумя членами виртуальных машин. Вы можете создавать крупные команды, но больше не поддерживаются крупные команды. Каждый член команды должен подключаться к другому внешнему коммутатору Hyper-V, а сетевые интерфейсы виртуальной машины должны быть настроены для поддержки объединения.

Если вы настраиваете группу сетевых адаптеров на виртуальной машине, необходимо выбрать режим объединения коммутаторов в независимом режиме и режим балансировки нагрузки для хэша адреса.

Сетевые адаптеры с поддержкой SR-IOV

Группа сетевых адаптеров в или на узле Hyper-V не может защищать трафик SR-IOV, так как он не проходит через коммутатор Hyper-V. С помощью параметра объединения ВИРТУАЛЬНЫХ сетевых карт можно настроить два внешних коммутатора Hyper-V, каждый из которых подключен к своей собственной сетевой карте с поддержкой SR-IOV.

Каждая виртуальная машина может иметь виртуальную функцию (VF) из одной или обеих сетевых адаптеров SR-IOV и, в случае отключения сетевого адаптера, отработки отказа из основного VF в адаптер резервного копирования (VF). Кроме того, виртуальная машина может иметь VF из одной сетевой карты и Вмник, отличной от VF, подключенной к другому виртуальному коммутатору. Если сетевая карта, связанная с VF, отключена, трафик может выполнить отработку отказа на другой коммутатор без потери подключения.

Поскольку отработка отказа между сетевыми картами в виртуальной машине может привести к передаче трафика с MAC-адресом другого Вмник, каждый порт виртуального коммутатора Hyper-V, связанный с виртуальной машиной с помощью объединения сетевых карт, должен быть настроен для разрешения объединения.

Связанные темы

Объединение сетевых карт. использование и управление MAC-адресами. при настройке группы сетевых карт с независимым режимом и при использовании хэша или динамического распределения нагрузки группа использует Mac-адрес основного члена группы сетевых адаптеров для исходящего трафика. Член группы основного сетевого адаптера — это сетевой адаптер, выбранный операционной системой из начального набора членов группы.

Параметры объединения сетевых карт. в этом разделе мы преддадим Обзор свойств группы сетевых адаптеров, таких как объединение и режим балансировки нагрузки. Кроме того, мы предоставляем подробные сведения о параметре адаптера ожидания и свойстве основного интерфейса группы. Если у вас есть по крайней мере два сетевых адаптера в группе сетевых адаптеров, не нужно назначать резервный адаптер для отказоустойчивости.

Создание группы сетевых адаптеров на главном компьютере или в виртуальной машине. в этом разделе вы создадите новую группу сетевых адаптеров на главном компьютере или на виртуальной машине Hyper-V, работающей Windows Server 2016.

Устранение неполадок объединения сетевых адаптеров. в этом разделе обсуждаются способы устранения неполадок объединения сетевых карт, таких как оборудование, безопасность физического коммутатора и отключение или включение сетевых адаптеров с помощью Windows PowerShell.

Источник

Remove From My Forums

Question
I’ve been looking online on best practice. I have brand new Windows Server 2019 Datacenter installed on my host machine. I am trying to setup something
new (in our environment) which is not new to the world I would like to provide high availability for our storage, to store VMs on a CSV. I have two separate 10 Gbps cards. My
question is when I set this up and when setting up iSCSI, should I setup NIC Team in server manager for my storage network or should I have two separate cards with separate IPs and turn on MPIO? I
am seeing articles about this but most articles are outdated and talk about Windows Server 2012 R2 when technology was not as mature as it is today.

Answers

NIC teaming does not always provide for simultaneous use of all NICs in the team. MPIO allows for use of all NICs/HBAs. NIC teaming is handled outside the storage stack, so issues in the NIC teaming stack may not be visible to the storage stack,
causing disconnects. Are there any documents to support this? It seems like that is what you found in your search. You did not find any documents to support NIC teaming, though I bet you found lots and lots to support MPIO.

tim
- Marked as answer by
  
  Friday, December 6, 2019 2:23 PM

Источник

When configuring storage for Windows Server Hyper-V clusters with SAN storage, you always want to make sure you have multiple paths to your storage for redundancy and performance. With SAN storage and iSCSI you won’t want to utilize link aggregation technologies such as LACP switch LAGs or Switch Embedded Teaming. Instead you want to use something called Multipath I/O or MPIO in Microsoft terms for connecting your Hyper-V hosts using multiple paths to your storage. First, let’s see why you want to use MPIO instead of LACP or other link aggregation technologies and the Windows components that need to be installed in Windows Server to allow utilizing MPIO connections. This will allow Hyper-V hosts to make use of multiple paths connected to iSCSI storage. Let’s look at Hyper-V Cluster MPIO iSCSI installation and configuration and why this is important.

Why Use MPIO instead of Link Aggregation?

Why do you use MPIO instead of link aggregation technolgies like NIC teaming or LACP? The link aggregation technologies certainly have their place and would serve to solve the redundancy problem but would not improve performance. This is due to the fact that Link Aggregation technologies improve throughput when there are unique I/O flows that originate with different sources. The iSCSI flows do not appear to be unique to the aggregation technologies and so do not benefit from any performance boost with link aggregation. MPIO on the other hand deals with multi-pathing by looking at the initiator and the target, or client and server level. So multiple initiators can connect to the same or different targets and benefit from the multipathing capabilities that MPIO brings to the mix.

With the above state reason, Hyper-V benefits from the use of MPIO and is the way you want to configure your iSCSI connections when connecting the individual Hyper-V hosts to the iSCSI SAN shared storage. What is involved with configuring MPIO in Hyper-V? Let’s look at what is required from the Windows Server side of things.

Configuring MPIO in Windows Server requires just a few steps. They include:

Adding the MPIO Windows Feature
Reboot
Configuring the Add support for iSCSI devices for your particular SAN device
Reboot
Configure iSCSI connections with Enable multi-path
Add all the connections for each target, enabling multi-path
Check multi-path MPIO connections

Configuring MPIO Windows Feature

The first thing you need to do in a Windows Server installation is add the Multipath I/O Windows Feature. To do that, simply add the Feature in Server Manager or PowerShell with the Add-WindowsFeature cmdlet.

Enable Multi-path IO Windows Feature for MPIO

After the installation of Multipath I/O, you will be prompted to restart Windows to finalize the installation. After restarting Windows, you are ready to enable the add support for iSCSI devices feature for your selected SAN device. To do this, after the server reboot, launch the MPIO configuration utility by typing mpiocpl at a run menu or cmd line.

After launching the utility, navigate to the Discover Multi-Paths tab, select your SPC-3 compliant device, and check the box Add support for iSCSI devices. Afterwards, click the Add button. You will be prompted for a reboot.

Add support for iSCSI devices to configure MPIO in Hyper-V

After this reboot, you are ready to start adding your iSCSI connections with multi-path enabled.

Adding Hyper-V iSCSI Connections with MPIO Multi-path

To begin adding target portals and then the targets themselves, launch the iSCSI Initiator Properties configuration utility. This can be done by typing iscsicpl at a run or cmd prompt. Navigate to the Discovery tab and then click the Discover Portal button.

Discover ports in the iSCSI initiator properties

Enter your first iSCSI portal address, then click the Advanced button.

Discover Target Portal in configuring MPIO in Hyper-V for iSCSI

Under the Advanced Settings, you can set a specific Local adapter and Initiator IP.

Discover target portal advanced settings MPIO configuration

Do this for your multiple target portals. As you can see below, I have different target portal IPs that have been added using the specific network adapter that aligns with the target portal network address/subnet.

After adding both target ports for MPIO configuration in Hyper-V

After adding the portals, click on the Targets tab. You will see the Discovered targets and they will most likely be in the Inactive status. Click the Connect button.

Connecting the iSCSI discovered targets

On the Connect to Target dialog box, click the Enable multi-path checkbox and then click the Advanced button.

Connecting the first target with multi-path and advanced settings for MPIO in Hyper-V

Here is where the actual magic of the MPIO connections comes into play. Below, I am setting the Local adapter, then the Initiator IP and Target portal IP. So our end goal here is to setup the connections using each portal adapter IP.

Setting the Initiator Initiator IP and Target Portal IP for first MPIO connection in Hyper-V iSCSI

Click the Connect button again on the same discovered target. Now, I use the second Initiator IP and Target portal IP for the second connection to the same target.

Setting the Initiator Initiator IP and Target Portal IP for first MPIO connection in Hyper-V iSCSI for second connection

Now we see the Connected status. Click the Properties button so you can verify the MPIO status.

First Hyper-V MPIO iSCSI connection

Notice you have two identifiers. Click each one and you will see the respective Target portal group tag.

Verifying the first portal group ID for MPIO in Hyper-V iSCSI

Clicking on the second Identifier and notice the Target portal group tag is the second group tag.

Verifying the second portal group ID for MPIO in Hyper-V iSCSI

Click the Portal Groups tab and you should see both Associated network portals.

Verifying portal group connections

For each Identifier, you can Configurer Multiple Connected Session settings by clicking the MCS button.

Configuring Multiple Connected Session

Note the MCS policy options that control the multi-pathing behavior. Options are:

Fail Over Only
Round Robin
Round Robin With Subset
Least Queue Depth
Weighted Paths

Configuring the MCS policy for Hyper-V MPIO connections

You will want to complete the above configuration for every Hyper-V host that you have in the Windows Server Hyper-V Failover Cluster to ensure you have multi-path connections to shared storage.

Verifying Hyper-V iSCSI MPIO Multi-path Connections

There is a powerful little built-in cmd line utility that allows easily seeing the state of your MPIO connections in Hyper-V. The utility is mpclaim. Below, you can see your MPIO enabled devices with the command:

mpclaim -s -d

Using mpclaim to check MPIO devices

To look at the multipath information for a specific device use:

mpclaim -s -d <device ID>

You can see below, I have two active paths to the specific device ID queried. State is Active/Optimized.

Using mpclaim to verify path ID state SCSI Address and Weight for specific MPIO device in Hyper-V

Takeaways

Hyper-V Cluster MPIO iSCSI Installation and Configuration involves a few steps as shown above but is relatively easy to configure. After adding the Multipath I/O Windows Feature and enabling the iSCSI multi-path plugin for your specific storage array, you can then add your iSCSI targets and connect to them using the multiple portal IP addresses, thus enabling multi-path connectivity to your storage. This allows for not only having a redundant connection to your storage devices but also allows for optimum performance for iSCSI traffic to the SAN storage.

Источник

System Requirements:

Windows Server 2008 Storage Server
Windows Server 2008 R2 Storage Server
Windows Server 2012, 2012 R2, 2016

The Problem:

I needed to outline some of the general thinking relating to exactly how a practitioner should logically and physically understand MPIO, however most of the discourse on the subject skips a fair amount of the obvious questions that people starting out with the technology may be asking (or trying to answer). I therefore present some thinking on the subject of understanding MPIO optimisation and best practice for iSCSI.

The information presented in this document is intended for those who are new to the concept of iSCSI and MPIO and is not intended to be product specific.

More Info

Multi-Path Input/Output or MPIO is a server technology that usually sits on the storage side of load balancing, failover and aggregation technologies. If you are getting into SAS, iSCSI or Enterprise RAID solutions where it is most commonly used (encountered), then you this may (or may not) help you with understanding what MPIO is any why it (possibly) isn’t what you think it is!

The document is written from the perspective of an iSCSI user where it can be conceptually a little harder for new users to understand the best way to approach MPIO.

Logically understanding what MPIO is all about

So you have 2x1Gbps ports in a MPIO team, that means you’ve got a 2Gbps link right? Wrong. That isn’t what is going on with MPIO.

MPIO (and in fact pretty much the majority of balancing and aggregation technologies) doesn’t double the speed, but it does roughly double the bandwidth available to the system. Confused? Think of it like this:

You own a car. The car has a top speed of 70mph and not one mph more. You get on a one way, single track road in a country where there are no speed limits. You are now happily driving along at 70mph. Some bright spark at your local council decides that you should be able to drive at 140mph, so they cut down the trees on one side of the road and add a second one-way carriage way, going in the same direction as the first.

Can your car now drive at 140mph because of the new lane? No. The public official is wrong. Your engine can only offer you 70mph. The extra lane doesn’t help you, but it does help the guy in the car next to you also driving at 70mph arrive at the other end of the road at the same time. It also means that when you encounter a tractor ambling along in your lane, you have somewhere else to go without slowing down.

This is fundamentally what MPIO is doing. So why isn’t it a 2Gbps link? Basically, because networking technology is a serial communications medium and by adding a second lane and calling it a faster way to get data to the end of it, you get into the different world of parallel communications. Under parallel communications you have to split (fragment) information into smaller pieces and push it down each one of the wires to the destination. This in turn infers the need to have more complicated buffer/caching designs to store information as part of a strategy that is designed to be able to cope with each section of the data arriving at a different time, it arriving all at the same time, in a different order than intended or of course, it not arriving at all. Something known as clock skew.

To fix this, you need to introduce overhead either to synchronise delivery to be reliable (thus slowing it down and reducing error tolerance) or adding overheard mechanisms designed to deconstruct, sequence, wait for or re-request missing or corrupt data sections and track timing – alls something that you really don’t want in an iSCSI or SAS environment where response time (latency) is king. Consequently, there is a diminishing return on how much of this parallel working you can derive a benefit from in any system, including an MPIO system. iSCSI MPIO, if correctly configured, will offer something at around about the boundary between worth-while and not bothering in the first place. Yet it is important to understand that it will not be a 100% increase in performance, neither will likely be a 50% increase, but more realistically something around the 30-40% mark.

Performance is only one of the intended design considerations for MPIO, and in that it is not the primary consideration. The primary consideration is for fault tolerance and reliability.

In a correctly designed iSCSI system, independent NICs connected to more than one switch and usually to more than one controller on the storage side and more than one server on the host side. If one of these fails, in a correctly implemented system, your production service probably won’t even notice. You can even be as bold to perform live switch re-wiring on iSCSI systems without impacting the client services involved – although it should be stressed that this is for bragging rights and in practice should not be attempted.

To summarise, MPIO allows you to get twice (+) as much data down to the end of the link, but you cannot get it there any faster. In general, if you can avoid using fragmented streams, you will reap the maximum benefit. The obvious approach here is that each “lane” should be using unrelated data: instead of carving up a single video file and pushing little bits of it down each lane one bit at a time (MPIO can do this), one lane is used for the video and the second lane is used for literally anything and everything else. This is a simplification of what MPIO generally does, however in practice is offers a good way to get your head around it.

Techniques

So how does MPIO carve up the traffic?

There are broadly speaking 4 different paradigms for carving up MPIO traffic

Failover/Redundant	In this mode, one link is active, while the other is passive i.e. up, but not doing anything. If the first link fails, the second path takes over and all existing traffic streams continue to receive the same bandwidth (% of the total available pie) on the same terms as before. This would give us a completely separate road that can only be used in emergencies. It may not be as fast or robust, or it may be identically spec’d and just as capable. A failover design may or may not return traffic to the first channel once it becomes available once again.
Round Robin	This mode alternates traffic between channel 1 and channel 2, then goes back to channel 1, channel 2 and so on. Both links are active, both receive traffic in a slight skew as the data is de-queued at the sender. This offers the 2 lane analogy used above with each 70mph car getting to the end at roughly the same time.
Least Queue Depth	This puts the traffic into the channel that has the least amount on it (or to be more accurately about to go onto it). If one channel is busier than the other (e.g. the large video file) then it will put other traffic down the second channel, allowing the video to transfer without needing to slow down to allow new traffic to join, delaying its delivery. There are many different algorithms that exist on how this is achieved, including varieties that use hashing to offer clients consistent paths based upon Layer 2 or Layer 3 addresses.
Path Weighting	Weighted paths and least blocking methods assess the state/capabilities of the channels. This is more useful if there are lots of hops between source and destination, multiple routes between a destination or different channels have different capabilities. For example, if you have iSCSI running through a routed network, then there could be multiple ways for it to get there. One route may go through 5 routers and another 18 routers. Generally, the 5 router path might be preferable, provided the lower hop route genuinely gets the data there faster. Equally the weighting could be based upon the speed of the path through to the recipient or finally, if channel 1 is 10Gbps and channel 2 is only 1Gbps, then you might prefer the 10Gbps path to be used with a higher preference. Usually, a lower weighting number means a higher preference. This would be the equivalent of a 70mph road with a backup road with a max speed of 50mph. You know that it will get you to the destination, but you can guarantee that if you have to use it, it will take longer.

So, more lanes equal more stuff then?

Sounds simple doesn’t it? Just keep throwing lanes into the road and then everyone gets to travel smoothly at 70mph.

In principle, it is a nice idea, but in practice it doesn’t actually work in most iSCSI implementations.

For starters, server grade network card (which you should be using for MPIO, and not client adapters) are expensive and server backplanes can only accept a finite amount of them. Server NIC’s also consume power and power consumes money! Keep that in mind if you do decide to throw extra ports at an iSCSI solution.

The reality is that if you have an MPIO solution that will allow you to experiment with more than 2 NIC adapters in a MPIO group, you will likely see the performance gain rapidly tail off. In turn it will actually wind up presenting you with steadily worsening performance, not the increase that you are expecting.

Attempting to MPIO iSCSI traffic across 4x 1Gbps NIC’s actually offers worse read and write speeds for a virtual machine than 2x 1Gbps under a Hyper-V environment (see tests E and F below). The system starts to waste so much time trying to break apart and put back together each lane’s worth of traffic that it just doesn’t help the hypervisor.

Where a 4 NIC configuration is beneficial is actually in providing you with a “RAID 6” MPIO solution. Here you can have 2 active and 2 passive adapters – remember in an idealised scenario they could be 2x10Gbe and 2x1Gbe with a hard-coded preference for the 10Gbe and a method of failing traffic back to the 10Gbe. Just be aware that you can only use the 10Gbe set OR the 1Gbe set at the same time, not one port from each. The exception to this rule is for hashing based channel assignment as these offer more paths to “permanently” assign data into, without the overhead of path swapping or de-fragmentation of traffic.

Some DSM’s (effectively a OEM specific MPIO driver under Windows, such as Dell Host Integration Tools [HIT] or NetApp Host Utilities) logically limit a MPIO to two active NIC’s if the storage controller is only exposing 2 usable NICs back to the HIT instance. Dell EqualLogic Host Integration Tools (the EqualLogic DSM) will grab the first two paths it finds and shutdown any others into a passive state, no matter how hard you try to start them up.

What should a MPIO network “look” like?

Ultimately this is down to what you want to get out of the MPIO solution and within the bounds of what your hardware vendor will support.

There are effectively three schools of thought here (I won’t comment on which is right because as you’ll see, it isn’t that simple)

MPIO is about Meshing

If you see MPIO is a mesh then 2 NIC’s in a server connecting to 2 NIC’s in a storage appliance equals a mesh where each NIC has a path to the other. This is more aligned with how you probably already think about Ethernet networks.

MPIO is about Pathing

If you see MPIO in this model it is simple about more than one line being drawn between two different end points, with no line crossing or adding any complexity, complication and confusion. This is more aligned with how you likely currently think about SAS, Fibre Channel and hard drive wiring.

MPIO is about Redundancy

This is the purest of the three views. It sees the complexity and overheads associated with MPIO as being a problem – there will always be some sort of increase in latency, a drop in some aspect performance by trying to squeeze more bandwidth out of MPIO. This view attempts to keep the design simple, run everything at an unimpeded wire speed but maintain the failover functionality afforded by MPIO.

The three schools of thought are outlined in the diagram below.

Why not Meshing?

When you start out with MPIO, you may be tempted towards implementing option 1. After all, your Server NICs (circles) are likely connected to a switch, as is your storage array (squares). The switch allows you to design to this topology and if you allow the MPIO system to have knowledge over all possible permeations of connectivity, the system will highly redundant, making it very robust.

Yes and no! Yes, it is very robust, but at this point in your implementation, how do you know which path traffic is taking? How do you know that it is optimised? What is stopping Server NIC1 and Server NIC2 from both talking to storage NIC1 at the same time? If they do that, then they have to share 1Gbps of bandwidth between them while Storage NIC2 is left idle. Suddenly all of your services will have intermediate bursts of speed and infuriating drops in performance. The more server NICs that you add, the faster the decrease in performance will be. With 4 Server NICs, there is nothing to stop the MPIO load balancer from intermittently pushing the data from all 4 Server NICs towards a single Storage NIC.

In a Round Robin setup, in a full Mesh design (as shown in #1) it will likely order the RR protocol in the order that you gave the system access to the paths. Given the following IP Addresses

Server: 192.168.0.1, 192.168.0.2
Storage: 192.168.0.11, 192.168.0.12

The RR table could like this

192.168.0.1 -> 192.168.0.11
192.168.0.2 -> 192.168.0.11
192.168.0.1 -> 192.168.0.12
192.168.0.2 -> 192.168.0.12

Or it could like like this

192.168.0.1 -> 192.168.0.11
192.168.0.1 -> 192.168.0.12
192.168.0.2 -> 192.168.0.11
192.168.0.2 -> 192.168.0.12

In both examples you either have two different sets of traffic being sent from the same Server NIC concurrently or received by the same Storage NIC concurrently. This is going to undermine performance, not improve it (this is outlined in Mbps terms in the tests shown later in this document).

In a failure situation, the performance issue is exacerbated

If #3 fails, then nothing changes in performance or bandwidth.
If #2 fails then the total bandwidth available to the system halves and all services contend using the first link.
If #1 fails then as with #2, all services suffer with contended bandwidth, however the system also has the overhead of MPIO to further reduce performance.

What benefit is there to MPIO operating in scenario #1? In this failed state, should one of the Storage NICs also fail, the system will continue to operate. In #2 if the working Storage NIC fails, the entire system will fail despite the fact that the Storage NIC on the second path is actually working. It is up to you and your design as to whether you think that the performance hit that you will experience is worth this extra safeguard? In a highly secure system, mission critical or safety system it may be worth the extra overhead.

There are however some middleware layers that can manage this for you. Dell Host Integration Tools (HIT), does, for example, attempt to undertake some management of these types of situations, optimising the mesh by putting the links that will cause overhead into a failover only state, while maintaining the optimal number of active mesh links. In my experience though, the HIT solution is not able to perfectly manage the optimal risk. It does not provide any consideration over redundant NIC controllers. For example, if you have 2 physical Dual Port NICs in your Server with the intention of one port from each NIC making up the active “pair”, Dell HIT is not able to detect or be programmed to ensure that the active paths are prioritised around ensuring that the correct controller is being used. In my experience, it will tend to bunch them together onto the same physical NIC controller, leaving the second controller idle.

Fixing this problem requires an additional layer of complex, expensive and usually proprietary middleware logic, further impacting performance and increasing cost. Therefore, industry best practice is to avoid thinking of iSCSI MPIO as being a Full or even a Partial Mesh, but instead think of it as offering independent channels akin to those shown in #2. It is for this reason that virtually all iSCSI MPIO vendors insist that each Server -> Storage NIC pair exist on its own logical IP subnet as this completely negates the possibility of interweaving the MPIO paths while also ensuring that any subnet-local issue (such as a broadcast or unicast storm) is only likely to take down one of the subnets, not both.

iSCSI as part of a Virtual Network Adapter, Converged Fabric LBFO Team

Since the release of Windows Server 2012, Microsoft have allowed to be hinted at the idea of using iSCSI through Converged Fabric* Load balancing Failover (LBFO) teams — as long as the iSCSI NICs are Virtual and they connect through a Hyper-V VM Switch which itself backs onto a Windows Server LBFO team. Even the venerable Aidan Finn has hinted at it. I have, however, never seen a discussion of it being attempted online, neither have I ever seen it benchmarked.

To be clear over what we are talking about when I say a Virtualised, Converged Fabric, LBFO Team:

4x 1Gbps Ethernet physical adapters
Grouped into a Windows Server 2016 LBFO Team, appearing to Windows as a single logical network adapter called “ConvergedNIC”
“ConvergedNIC” is connected to an External Virtual Switch called “ConvergedSwitch”
A Virtual Machine Network Adapter is created on the Hypervisor’s Parent Partition (ManagementOS) and this is assigned to the correct VLAN, given an IP address and hooked up to the iSCSI Target
4 physical NICs, no MPIO, 1 logical NIC

So, does it work?

Yes! It does work and it appears to be stable and even usable; but with some sacrifice in performance (keep reading for some benchmark numbers as “test A” below). I have however had test VMs running under this design for nearly a year without any perceivable issues in either VM or hypervisor stability.

* If you are not familiar with the Concept of a Converged Fabric: A Converged Fabric is a data centre architecture model in which the concept of 1 NIC = 1 Network/Subnet/VLAN/Traffic Type is abandoned. Instead, NICs are usually pooled together into Teams with multiple traffic types, Networks, Subnets and VLANs being allowed to use any of the available bandwidth within the team. Quality of Service (QoS) algorithms are used to ensure that priority traffic types are defined (such as iSCSI in this example), ensuring that the iSCSI system is never starved for bandwidth by someone performing a large file transfer across the team. A Converged Fabric architecture is considered to be more efficient, lower cost and offer better failover reliability than traditional methods in which entire 1GbE or 10GbE NICs could be left idle, waiting for traffic that while high bandwidth, may be infrequent. A Converged Fabric architecture allows other users/systems to benefit from the available bandwidth when not needed by its primary application. It can also offer the primary application additional bandwidth in some situations.

If you have an 8 NIC Hypervisor setup with 2 physical iSCSI NICs, 2 physical production network NICs, 1 physical heartbeat NIC, 1 physical live migration NIC, 1 management network NIC and 1 out of bounds management NIC, then you are paying to power but to not derive much of any benefit from NICs 4-8 due to how infrequently they are used. If this sounds familiar to you, then you should consider migrating to a Converged Fabric design.

Quantifying Best Practice

So far, this article has discussed MPIO, meshing, pathing and redundancy as well as a quick detour into using converged fabric LBFO for iSCSI connections. So let’s look at some numbers that underpin these approaches.

Tests were undertaken using the following hardware configuration:

Dell EqualLogic PS4110x running firmware 9.1.1 R436216, with 2 active 1GbE NIC’s on a single controller
Dell PowerEdge P630 with 8x1GbE adapters (4x Broadcom NetXtreme and 4x Intel I350 adapters) with 9K Jumbo Frames correctly enabled
Windows Server 2016
Switching on Cat6a cabling via 2x Cisco Catalyst 2960-48’s
The 64K block, GPT formatted, 3TB target LUN was setup as a CSV and the nodes were in a Cluster with a second identical node idling as a second cluster member (CSV-FS has a natural performance hit compared to NTFS)

7 tests were performed as outlined in the following table

		Physical Paths	Active NICs
Test	Description	Active	Passive	Intel	Broadcom	LBFO Team	Dell HIT	MPIO Mode
A	4 NIC in LBFO Team, No MPIO	4	0	0	4	Y	N	n/a
B	4 NICs, fully meshed, RR	8	0	2	2	N	N	Round Robin
C	2 NICs, no mesh (point to point)	2	2	2	0	N	N	Round Robin
D	1 NIC only (control test)	1	1	1	0	N	N	n/a
E	4 NICs, fully meshed, LQD	8	0	2	2	N	N	Least Queue Depth
F	4 NICs, partial mesh, RR	4	0	2	2	N	N	Round Robin
G	2 NICs, no mesh (point to point) with EqualLogic Host Integration Tools	1	1	2	0	N	Y	Least Queue Depth

If you are more visual, the following diagram summarises the above in a graphical format

The Results

The following table summarises the read/write performance of each test on Sequential 4MB reads as outlined through “Anvil’s Storage Utilities”, version 1.1.0, build 1st January 2014. all tests were performed on the same Windows 10 Enterprise VM without rebooting in between each test and without performing any other activities on the VM disk.

The results below are ordered by test, from the test offering the best performance to the test offering the worst performance, using the Read MB/s column as the sort index.

	Sequential 4MB (Read)	Sequential 4MB (Write)
Test	Response (ms)	MB read	IOPS	MB/s	Control Deviance (%)	Response (ms)	MB written	IOPS	MB/s	Control Deviance (%)
C	30.4791	1052	32.81	131.24	32.17	21.7266	1024	46.03	184.11	70.25
F	39.801	804	25.13	100.50	1.21	468.9896	772	2.13	8.53	-92.11
D	40.2814	796	24.83	99.30	0	36.9883	1024	27.04	108.14	0
A	51.3782	624	19.46	77.85	-21.60	89.5977	1024	11.16	44.64	-58.72
G	60.7197	528	16.47	65.88	-33.66	23.8047	1024	42.01	168.03	55.38
E	273.9667	120	3.65	14.60	-85.30	1010.7556	360	0.99	3.96	-96.34
B	404.65	80	2.47	9.89	-90.04	964.766	376	1.04	4.15	-96.16

Response (ms) = Lower is better
MB read/written = Higher is better
IOPS = Higher is better

Control Deviance (%) = the positive or negative impact in MB/s performance compared to the single NIC, no MPIO control test (test D).

Test A | Converged Fabric LBFO

The Microsoft dream of virtualising everything does hold up – at not being completely terrible. Sitting in the middle of the table, using a fully converged fabric, virtualised setup across 4 NICs resulted in a 22% reduction in read speed compared to a single NIC and a 59% reduction in write speed.

There may be some improvements to made by creating multiple Virtual iSCSI interfaces connected to the virtual switch, however these were not tried. Based upon the current view of the technology, while it works and offers a data centre design simplification, that simplification factor is not worth the performance sacrifice.

Test B | Round Robin, Full Mesh

This test proves that viewing an iSCSI setup as a full mesh and throwing NICs at the proverbial problem is going to do nothing to help you. Your iSCSI should be configured in a 1:1 “path” setup between initiator and target. Any additional NICs should be put into “Round Robin with subset” i.e. made to be passive fail-over adapters. That is a 90% and 96% reduction in respective read/write performance!

Test C | Round Robin, 1:1 Paths

This test proves how you are supposed to use iSCSI. Two, non-crossing paths allows for a full bandwidth connection down each path between the initiator and the target. This configuration provided an increase in performance over a single adapter and was the only test that provided improvements to both read and write metrics.

Test D | Control

This was the baseline control test for this experiment. 1 NIC talking to 1 controller port. Nothing complicated here.

Test E | Least Queue Depth, Full Mesh

This test repeated Test B, but changed the MPIO model from RR to LQD to see if it made any difference. Read performance was slightly better than under RR, but was still 85% worse than the control test.

Test F | Partial Active Mesh

This test looked to see whether having a partial active mesh made any difference. There was a very small 1% increase in read performance from this, but a significant write penalty. In practice, you cannot push/pull 2Gbps to/from a 1Gbps source, so the design is not conducive towards improved speed under a synthetic load.

Test G | Least Queue Depth, 1:1 Paths

Test G was a genuine surprise. I was expecting to see Dell EqualLogic Host Integration Tools (HIT) version 4.9 offer an increase in performance, not a decrease. However, repeating the test yielded the same results. In my experience, this has never usually been the case, with VM’s feeling more responsive with HIT installed compared to not. Experience suggests to me that something else was at play here, perhaps the HIT version being poorly optimised for Windows Server 2016, or the Dell stack getting grumbly about it using a retail Intel I350-T4 adapter instead of a Dell one. Dell HIT forces the use of pathing no matter what you try and set all other adapters into passive mode. It used LQD as the MPIO algorithm. Evidently this resulted in an increase in writes but a reduction in read performance, be it not as high as without HIT being installed.

Although not shown in the results above, HIT did help improve performance in some of the Anvil Tests. The long queue depth tests resulted in higher IOPS figures for both read and write values by a small margin. None of the other tests yielded such an improvement.

Conclusion

As you can see from these results. There is only one way that you should be conceptually thinking about your iSCSI environment – 1:1, point to point paths. Anything over and above this should be set to being passive/failover/offline in order not to impact performance.

General Subnet Recommendations

Subnet recommendations go hand in hand with this, but you should note are generally made by the storage vendor — and you should follow their advice. I have encapsulated the general recommendations/requirements of a number of providers in the table below. The subnet count column is in essence a statement that for each NIC on the storage device, there should be a dedicated subnet (and ideally broadcast domain/VLAN) back to the iSCSI server.

Vendor	Subnet Count	Source
Dell (Non-EqualLogic)	2	View
Dell EMC	2	View
Dell EqualLogic	1	View
Microsoft	2	View
NetApp	?	I couldn’t find any guidance from an official source. There is community evidence of both being used by end-users
NetGear	2	View
QNAP	2	View
Synology	2	View

As you can see, with the exception of Dell EqualLogic which provides a middleware solution known as the Host Integration Tools (HIT) to cope with this, most vendors are quite specific on the use of a “single path” logical topology for server/storage connectivity — aka one subnet per storage appliance NIC.

General Advice

I will end this piece with some general advice and tips for working with MPIO. It isn’t exhaustive, but they are some quick observations from experience of using the technology for many years. Some of them are obvious, some of them might help you avoid a head scratcher.

If you are using an enterprise iSCSI solution, follow the vendor’s advice, forget anything you read on the Internet. Everyone is a know-it-all on the internet and there are plenty of “I’m a Linux user so I know best” screaming matches about how EqualLogic are wrong about the recommendations for EqualLogic’s own hardware. I’m pretty sure that EqualLogic… uh, tested their stuff before writing their user manual.
If you are using an enterprise solution and the vendor offers a DSM (MPIO driver), use it. Dell HIT vs the generic Microsoft DSM for Windows Server is noticeably faster, but only works will Dell SAN hardware (naturally). Also ensure that you keep you DSMs up to date.
Follow you vendor’s guidelines with respect to subnets. If in doubt, drop them an email. You’ll usually find them quite accommodating.
Unless your vendor has expressly told you to, you do not MPIO back from the storage system – i.e. don’t team, MPIO, load balance etc on the storage side. Do it all on the server initiating the request.
Stick to two port/1:1 path MPIO designs. If you need more create multiple pairs and have each on different networks going to different storage systems so that the driver knows where to send traffic explicitly while maintaining isolation.
If you want to think about your MPIO as a meshing design, it has to be meshed for redundancy, not active links (unless your system needs to keep living, breathing human beings alive and do so at all costs).
With iSCSI and SAN MPIO, try and avoid network hops (routers).
All ports in a group must be the same type, speed and duplex.
Disable port negotiation and manually set the speed on the client and switch, this will make failover/failback processes faster for your redundant paths.
Use VLAN’s as much as possible (try and avoid overlaying broadcast domains across a shared Layer 2 topology).
Use Jumbo Frames as much as possible unless the iSCSI subnet involves client traffic.
Hint: Your iSCSI subnet should not involve client traffic!
Ensure that your NIC drivers and firmware are kept up-to-date
Disable all Windows NIC service bindings apart from vanilla IPv4 on your iSCSI networks. For example, Client for Microsoft Networks, QoS Packet Scheduler, File and Printer Sharing for Microsoft Networks etc. If you aren’t using it, disable IPv6 too on the iSCSI interfaces to prevent IPv6 node-chatter.
In the driver config for your server grade NIC (because you are using server grade NIC’s, right?) max out the send and receive buffer sizes on the iSCSI port. If the server NIC has iSCSI features that are relevant (such as iSCSI offloading), enable them.
When you are building a Windows Server, script the MPIO install, enable MPIO during the script and set the default policy as part of the build process —- then patch and REBOOT the system before you even start configuration. If I had a £1 for every time I’d had to rescue someone from not doing that and then not REBOOTING…
If you are using a SOHO/SME general purpose commodity NAS, if (and only if) you have a UPS, disable Journaling and/or Sync Writes on your iSCSI partitions/devices. There is a benefit, but remember if you are hosting SMB shares on a commodity appliance you actually do want Journaling running on those volumes.
Keep your NAS/SAN firmware up to date.
Keep your storage system and iSCSI block sizes, cluster and sector sizes optimised for the workload. Generally this means bigger is better for virtualisation storage and video. 256/64K, 128/64K or 64/64K depending on what your solution can offer.
Keep volumes under 80% of capacity as much as possible.
Use UPS’s: Remember, iSCSI and SAS are hard drive/storage protocols. They are designed to get data onto permanent storage medium just like RAID controllers. RAID controllers have backup batteries because you do not want to lose what is in process in the RAID controller cache when the power goes out. Similarly, you need to think of your iSCSI and External SAS sub-systems much the same as you would a RAID sub-system.
If you have a robust UPS solution, enable write caching and write behind/write back cache features on your storage systems and iSCSI mounted services to gain extra performance benefits. Be mindful that there is risk in this if your power and shutdown solution isn’t bullet proof.
Test it! Build a test VM and yank a cable out a few times. You’ll be glad you sacrificed a Windows install or two to ensure it is right when you actually pull an iSCSI cable out of a running server… Believe me I know what a relief that is.

Источник

Устанавливаем MPIO (multipath i/o)

Включаем iSCSI initiator

Настройка iSCSI initiator

Настройка MPIO

Включение виртуальных дисков

Windows Server 2019 – MPIO and iSCSI conectivity with Dell EMC SC Storage Series

Infrastructure:

IP configuration

Установка MPIO в Windows Server 2016/2012R2

Установка MPIO с помощью консоли Server Manager

Установка MPIO с помощью Powershell

Настройка MPIO в Windows Server 2016

SAN Policy

Установка компонента Multipath I/O

Включение MPIO для iSCSI

Настройка MPIO для iSCSI

Настройка MPIO с помощью PowerShell

Отработка отказа

Настройка функции Multipath I/O для устройства StorSimple

Общие сведения о конфигурации MPIO

Шаг 1. Установка MPIO на узле Windows Server

Установка MPIO на узле

Шаг 2. Настройка MPIO для томов StorSimple

Настройка MPIO для томов StorSimple

Шаг 3. Подключение томов StorSimple на узле

Подключение томов на узле

Шаг 4. Настройка MPIO для обеспечения высокого уровня доступности и балансировки нагрузки

Настройка MPIO для обеспечения высокого уровня доступности и балансировки нагрузки

How to Enable and Configure MPIO on Windows Server 2016/2012R2?

Installing MPIO Installation on Windows Server 2016/2012R2

Enable MPIO Using Server Manager

Installing Multipath-IO Using PowerShell

Configuring MPIO on Windows Server 2016

SAN (Disk) Policy on Windows Server

Объединение сетевых карт

Доступность

Поддерживаемые и неподдерживаемые сетевые карты

Совместимость

Очереди виртуальных машин (ВМКС)

Виртуализация сети Hyper-V (HNV)

Динамическая миграция

Виртуальные локальные сети (VLAN)

Использование виртуальных ЛС с объединением сетевых карт в виртуальной машине

Управление сетевыми интерфейсами и виртуальными ЛС

виртуальные машины;

Сетевые адаптеры с поддержкой SR-IOV

Связанные темы

Question

Answers

Why Use MPIO instead of Link Aggregation?

Configuring MPIO Windows Feature

Adding Hyper-V iSCSI Connections with MPIO Multi-path

Verifying Hyper-V iSCSI MPIO Multi-path Connections

Takeaways

System Requirements:

The Problem:

More Info

Logically understanding what MPIO is all about

Techniques

So, more lanes equal more stuff then?

What should a MPIO network “look” like?

MPIO is about Meshing

MPIO is about Pathing

MPIO is about Redundancy

Why not Meshing?

iSCSI as part of a Virtual Network Adapter, Converged Fabric LBFO Team

Quantifying Best Practice

The Results

Test A | Converged Fabric LBFO

Test B | Round Robin, Full Mesh

Test C | Round Robin, 1:1 Paths

Test D | Control

Test E | Least Queue Depth, Full Mesh

Test F | Partial Active Mesh

Test G | Least Queue Depth, 1:1 Paths

Conclusion

General Subnet Recommendations

General Advice