Archive for the ‘howto’ Category.

Замена “головы” в сторадже: LUN serial

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

Если у вас на сторадже используются SAN LUN-ы, то при замене “головы”, а если более точно, то при замене NVRAM (при замене контроллера обычно с ним также меняется и NVRAM (NVMEM), установленная внутри) у этих LUN изменится их SerialID. В ряде случаев это может озадачить использующие их хосты (например Windows Cluster изменяет при этом их signatures, и не может после поднять в онлайн). Поэтому было бы правильно, после замены контроллера, и до возвращения LUN-ов использующим их системам, вернуть им старые SerialID.

Если у вас LUN-ов всего несколько, то это можно сделать и вручную (главное не забыть). Но если их много, то встает вопрос автоматизации.

На сайте communities.netapp.com было найдено несколько вариантов такого скрипта. На Perl, на VBS, и в виде скрипта PowerShell.

Замена “головы” в сторадже: disk ownership change

Вы уже наверняка знаете, что, в принципе, замена контроллера на установленной системе хранения NetApp процедура довольно несложная. Так как все контроллеры, всех семейств, используют одну и ту же OS Data ONTAP, отличаясь только  внутренним аппаратным устройством, а индивидуальные настройки контроллера системы (файловая система /etc, если кто понимает UNIX-style) находится отдельно от контроллера, на дисках дисковых полок, то вообще говоря замена контроллера на новый, даже другой системы, сводится к простому перетыканию кабелей, после чего новый контроллер с OS внутри подмонтирует свои индивидуальные настройки и поднимется с сохранением настроек и данных на дисках. Но следует не забыть про software ownership. Дело в том, что в этой схеме, ныне общепринятой, диски “приписаны” к определенному контроллеру по его SystemID (а не по подключенным портам, как было когда-то, во времена FAS3020 и старше). Соответственно, чтобы старые диски увиделись новым контроллером нужно на них записи их владельца поменять на нового. делается это из Maintenance mode:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2012.10.08 09:26:06 =~=~=~=~=~=~=~=~=~=~=~=
login as: root
root@192.168.99.161’s password:
=== OEMCLP v1.0.0 BMC v1.3 ===
bmc shell -> system power cycle
This will cause a dirty shutdown of your appliance. Continue? [y/N] y
bmc shell ->
bmc shell -> system console
Press ^G to enter BMC command shell

AMI BIOS8 Modular BIOS
Copyright (C) 1985-2009,  American Megatrends, Inc. All Rights Reserved
Portions Copyright (C) 2009 NetApp, Inc. All Rights Reserved
BIOS Version 6.1
+++++++++++++++++++++++++++++++++++

Boot Loader version 2.1
Copyright (C) 2000-2003 Broadcom Corporation.
Portions Copyright (C) 2002-2008 NetApp

4096MB RAM installed
CPU Type: Intel(R) Xeon(R) CPU                  @ 1.66GHz

Starting AUTOBOOT press Ctrl-C to abort…
Loading X86/freebsd/image2/kernel:..0×200000/7916668 0×98cc7c/708860 0xa3a000/573440 Entry at 0×00248390
Loading X86/freebsd/image2/platform.ko:0xac6000/380544 0xb23000/28000 0xb29d60/109976
Starting program at 0×00248390
NetApp Data ONTAP 8.1.1 7-ModeCopyright (C) 1992-2012 NetApp.
All rights reserved.
md1.uzip: 26368 x 16384 blocksmd2.uzip: 3584 x 16384 blocks

*******************************
*                             *
* Press Ctrl-C for Boot Menu. *
*                             *
*******************************
^C

Boot Menu will be available.

Please choose one of the following:

(1) Normal Boot.
(2) Boot without /etc/rc.
(3) Change password.
(4) Clean configuration and initialize all disks.
(5) Maintenance mode boot.
(6) Update flash from backup config.
(7) Install new software first.
(8) Reboot node.
Selection (1-8)? 5

You have selected the maintenance boot option:
the system has booted in maintenance mode allowing the
following operations to be performed:

?                 disk             
key_manager       fcadmin          
fcstat            sasadmin         
sasstat           acpadmin         
halt              help             
ifconfig          raid_config      
storage           sesdiag          
sysconfig         vmservices       
version           vol              
aggr              sldiag           
dumpblock         environment      
systemshell       vol_db           
led_on            led_off          
sata              acorn            
stsb              scsi             
nv8               disk_list        
fctest            disktest         
diskcopy          vsa              
xortest           disk_mung        

Type "help <command>" for more details.

In a High Availablity configuration, you MUST ensure that the
partner node is (and remains) down, or that takeover is manually
disabled on the partner node, because High Availability
software is not started or fully enabled in Maintenance mode.

FAILURE TO DO SO CAN RESULT IN YOUR FILESYSTEMS BEING DESTROYED

NOTE: It is okay to use ’show/status’ sub-commands such as
‘disk show or aggr status’ in Maintenance mode while the partner is up
Continue with boot?Please answer yes or no.
Continue with boot? yes

*> disk ?
usage: disk <options>

Options are: 
        assign {<disk_name> | all | [-T <storage type> | -shelf <shelf name>] [-n <count>] | auto} [-p <pool>] [-o <ownername>] [-s <sysid>] [-c block|zoned] [-f] - assign a disk to a filer or all unowned disks by specifying "all"  or <count> number of unowned disks
        ddr_label {repair | print | delete | dumpraw | modify [-c] -o <offset> -v <value> | start_scan | pause_scan | resume_scan | error_scan} [-d all | <disk_list>]
        encrypt { lock | rekey | destroy | sanitize | show } - perform tasks specific to self-encrypting disks
        power_cycle [ -f ] { [-d <disk_list>] | [ -c <channel_name> [ -s <shelf_number> ] ] } - power-cycle one or more disks
        reassign {-o <old_name> | -s <old_sysid>} [-n <new_name>] [-d <new_sysid>] - reassign disks from old filer
        remove_ownership [<disk_name> | all | -s <sysid>] [-f] - revert/remove disk ownership
        sanown_stats {start| stop| show }- collect sanown event stats
        show [-o <ownername> | -s <sysid> | -n | -v | -a]  - lists disks and owners
        unfail [-s] <disk_name>     - unfail a disk  (-s  not valid in maintenance mode)
        upgrade_ownership           - upgrade disks to new ownership scheme

*>

*> disk reassign -s xxxxxxxxxxx -d yyyyyyyyyyy

Partner node must not be in Takeover mode during disk reassignment
from maintenance mode.
Serious problems could result!!
Are you sure partner is NOT in takeover mode (y/n)? n

*> halt

Oct 08 01:34:22 [localhost:kern.cli.cmd:debug]: Command line input: the command is ‘halt’. The full command line is ‘halt’.

Uptime: 6m54sSystem halting…

Выше я прервал переназначение disk ownership, сама же эта процедура делается довольно быстро, и если нигде не ошибиться, и все иметь подготовленным и смонтированным, то можно уложить процедуру замены контроллера системы хранения в 15-20 минут.

Впрочем, если вы используете NetApp как SAN-устройство, и храните на нем LUN-ы, есть еще одна тонкость, связанная со сменой serial id этих LUN при замене NVRAM (отдельно, или в составе контроллера целиком), о которой поговорим в четверг.

Радикальное ускорение работы NetApp System Manager 2.x

Если вы, как и я ранее, мучаетесь от совершенно запредельно ннизкой скорости работы NetApp System Manager 2.x, основного ныне инструмента администрирования NetApp, то радикально ускорить его поможет вам способ, порекомендованный в нашем форуме (если вы еще не там – настоятельно приглашаю, ссылка в шапке блога):

По видимому причина тормозов – в крайне кривом разрешении хостнейма в IP в Java при работе через DNS, поэтому добавьте соответствие имен контроллеров и их IP в локальный файл hosts. Таким доисторическим приемом вы, на глаз, в десятки раз увеличите скорость работы, открытия панелей и их обновления.

Data ONTAP 8.1.x 7-mode Cookbook

В этом блоге я уже как-то рассказывал про прекрасный документ, под названием Data ONTAP Cookbook. Словом “Cookbook”, или, по русски, “поваренной книгой” обычно в IT называют сборники “рецептов”, как сделать то-то и то-то. Крайне полезные документы с пошаговыми инструкциями “как”: настроить экспорты NFS и поддержку для NFSv4, изменить размеры тома, провести траблшутинг проблем подключения клиента по CIFS, настроить репликацию между системами, включить и настроить компрессию, настроить BMC или RLM, подключить LUN по iSCSI, и так далее.
Раньше подобный Cookbook был выпущен для Data ONTAP 7.x, и многие им пользовались, как “настольной книгой админа”, а вот теперь у нас есть и версия для Data ONTAP 8.x 7-mode.

Если вы по каким-то этическим причинам не имеете логина на communities.netapp.com, необходимого для скачивания оттуда кукбуков по приведенным выше ссылкам, то можете взять версию на момент публикации отсюда:
https://www.box.com/s/jdvkjmtqns1i5xuhnaxc
https://www.box.com/s/qzxdsyc0g3fi4znlrf8a

Ну и, пользуясь случаем, напоминаю, что NetApp Innovation 2012 в Москве - послезавтра!

Загрузка серверов на Linux с NFS

Некоторое время назад попал на глаза любопытный текст, рассказывающий как можно организовать загрузку серверов с RedHat Server (в общем случае – любого Linux) с сервера NFS (в нашем случае, понятно, с NetApp FAS). В практике описавшего человека речь шла о загрузке большой кластерной вычислительной фермы, но, вероятно, такая возможность подойдет и во множестве других случаев.

По поводу бездисковой загрузки, как я заметил, существует также довольно много странных предубеждений и заблуждений. Например, считается, что только по FC, и только с помощью поддерживающих это HBA можно осуществить бездисковую загрузку сервера. Однако это не совсем так. Конечно, с помощью FC это сделать достаточно просто, и я даже писал на эту тему статью в блоге, с рядом типсов и триксов. Однако кроме загрузки по FC есть и другие варианты. Можно загрузиться по iSCSI, если у вас есть iSCSI HBA с BIOS и режимом загрузки в нем. Но даже и без HBA с BIOS это сделать можно, что и показывает рассматриваемый пример.

Сегодня практически любой современный сервер умеет делать загрузку netboot с помощью PXE – Pre-boot eXecution Environment. С его помощью мы сможем, в том числе, осуществить полноценную загрузку бездисковых серверов с NFS-сервера, без какого-либо FC, а дальше уже вольны использовать все возможности сервера Linux и системы хранения NetApp.

Преимущества такой загрузки, кроме очевидной экономии на локальных дисках:

  • Развертывание новых серверов, особенно когда их счет идет на десятки или даже сотни, становится тривиальным.
  • Отсутствие внутреннего жесткого диска делает проблему замены сервера, например в случае выхода из строя, предельно простой. Сервер с унифицированным “железом” грузится из загрузочного образа, в котором находятся все identities.
  • Очень простой становится и процедура Disaster Recovery. Устанавливаем репликацию SnapMirror между двумя сайтами, в случае проблем на основном сайте переносите или устанавливаете новые сервера (или VM) на резервном сайте, правите MAC на TFTP boot server, чтобы не исправлять этот параметр в бут-образах, и сервера грузятся также, и с тем же содержимым, что и на старом сайте.
  • Нет проблем с повреждениями локальной файловой системы. Никакх fsck. Для сервера его “файловая система” – WAFL на сторадже, отдаваемая по NFS, а WAFL крайне устойчива к повреждениям, так как это транзакционная файловая система.
  • Можно использовать FlexClone. Тома ваших OS и загрузочные образы это идеально подходящий случай для использования FlexClone, экономия пространства будет великолепная, а эффективность работы, в том числе за счет повышения эффективности кэширования – очень высокая.
  • Работа с централизованным, легко расширяемым  стораджем решает проблему исчерпания локального места на дисках серверов.

Конечно есть и ряд недостатков (решаемых):

  • TFTP-сервер и DHCP становятся критичными ресурсами, и могут даже стать “точкой отказа”, если вы не позаботитесь о их резервировании. Например можно поднять tftp-server непосредственно на NetApp FAS (options tftp.enable on и установить том для .rootdir), а для возможности работать с несколькими dhcpd, на разных машинах, можно использовать опцию next-server в файле конфигурации dhcpd.conf на загружающемся сервере.
  • Сетевые интерфейсы иногда могут иметь разные имена. ??з этой ситуации можно выйти, предусмотрев возможность переименовывать в скрипте имена udev, приводя их к единообразному виду. В приведенном документе показан способ этого решения.

Подробный документ how-to по загрузке сервера Linux с NFS-шары по TFTP, со всеми полезными настройками и скриптами можно взять здесь:

RHEL 6.2 NFS Boot installation.docx (63.4 K)

Настройка SNMP v3 для DFM/OnCommand Core

Как вы знаете, в состав ПО для стораджа, которое доступно вам для новых систем NetApp, входит полезный инструмент наблюдения, управления, диагностики и рисования красивых графиков –  OnCommand Core 5 (ранее – DFM, Data Fabric Manager). Для его работы необходимо использовать протокол SNMP. NetApp Data ONTAP поддерживает SNMP вплоть до версии 3. Вот как включить и настроить использование аутентифицируемого SNMPv3 для работы с DFM/OnCommand Core.

Начнем с того, что в админской консоли NetApp включим отключенный по умолчанию в сторадже протокол SNMP.

> options snmp.enable on

Хотя с NetApp и можно работать под root-ом, но тут это такая же “плохая практика” как и в обычном UNIX-like. Поэтому сразу начнем учиться жить “по-правильному”. Воспользуемся имеющимися средсвам RBAC – Role-based Access Control (кстати про использовани RBAC вы можете почитать перевод руководства на сайте Netwell в переводах Best Practices).

Создадим роль (snmpv3role), которой назначим определенную доступную ей функцию (login-snmp). Затем создадим группу, которой присвоим созданную роль с функцией, а затем добавим в эту группу созданного пользователя, которому назначена роль, с присвоенной роли функцией (“…в доме, который построил Джек”). Вот в таком порядке это создается:

> useradmin role add snmpv3role -a login-snmp

> useradmin group add snmpv3group -r snmpv3role

> useradmin user add snmpv3user -g snmpv3group

> Enter password:

Введем, в заключение процесса, пароль на пользователя snmpv3user. Это будет наш пользователь для операций SNMPv3. Протокол v3 отличается от традиционного и привычного v1 как раз наличием средств аутентификации.

Включим трапы SNMP.

> snmp traps enable

> snmp init 1

?? разрешим аутентификацию.

> snmp authtrap 1

А затем добавим хост, с которого будут происходить обращения к SNMP. В нашем случае это хост с установленным DFM или OnCommand Core 5.0, или же любым другим средством, работающим по SNMP, например собирающем со стораджа статистику. Можно добавить и несколько хостов.

> snmp traphost add <DFM server hostname>

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

> snmp location <filer location> (если в строке есть пробелы – окружите строку кавычками; snmp location “ДЦ2, комн.5, стойка 8”)

Все готово на стороне стораджа. Переходим на сторону хоста DFM/OnCommand 5.0

  • Если вы настраиваете из GUI, то проследуйте сюда:

Control Center tab | Setup | Options | SNMP Trap Listener. Щелкните Yes для включения листенера и щелкнитеk Update.

Control Center tab | Setup | Network Credentials.

Если вы использовали SNMPv1, найдите сеть вашего стораджа, которую вы хотите изменить на использование SNMPv3 в списке внизу страницы, и щелкните Edit справа.

В Edit Network Credentials, выберем SNMPv3.

В SNMPv1 Settings, убираем все, что указано в этом поле.

В SNMPv3 Settings, введем имя пользователя и пароль, созданные выше (snmpv3user) и щелкнем Update. НЕ ВВОД??ТЕ ничего в поле Privacy password. Это пока не используется, если вы туда что-то напишете, то получите сообщение об ошибке “snmpd:error Encryption not enabled” на стороне стораджа.

  • Если вы настраиваете из командной строки:

C:\> cd c:\Program Files\Network Appliance\DataFabric\DFM\bin

> dfm host list (чтобы посмотреть ID стораджа и его IP)

> dfm host set <storage ip> prefsnmpVersion=3

> dfm host get -q <ID стораджа, который вы подключаете по v3> (для проверки версии snmp)

> dfm host diag <имя хоста стораджа>

Вы получите следующий диагностический вывод:

SNMP Version in use SNMPv3

SNMPv1 Failed (это правильно)

SNMP Community <пусто> (так и должен быть пустой, см. ниже)

SNMPv3 Passed (297ms)

SNMPv3 Auth Protocol MD5

SNMPv3 Privacy Enabled No (Так и должно быть, это зарезервировано для будущего использования Privacy password, и сейчас не работает)

SNMPv3 Username root (OK, диагностика использует root, а не нашего созданного snmpv3user)

SNMP sysName <…> (какие-то значения, указанные в настройках)

SNMP sysObjectID <…>

SNMP productID <…>

 

Диагностика использует выполнение от пользователя root, поэтому мы видим выше упоминание root.

Если вы не очистите строку read only community в DFM GUI, то DFM будет использовать SNMPv1 в том случае, если строка  ro community определена на сторадже. Для ее удаления выполните команду в консоли стораджа:

> snmp community delete ro <community ro string>

??мейте ввиду, что System Manager v1.x и 2.x пока не поддерживают SNMPv3. Это означает, что если вы отключите использование SNMPv1, у вас перестанет работать функция обнаружения стораджей в сети, однако вы сможете добавить их вручную по IP-адресу (не Discover, а Add, затем введите IP-адрес стораджа, затем щелкните на иконку стрелки вниз, следующей за More, и введите логин и пароль административного аккаунта). Ели вам нужно продолжать использовать System Manager вместе с DFM, то оставьте  строку ro community на сторадже, удалив ее в DFM. DFM будет работать по v3, а System Manager по v1, без аутентификации.

Про настройку NetApp – новый блог

К пользующимся у меня тут, судя по вебсатистике, бешеным спросом статьям о начальном запуске и настройке новых систем NetApp (часть 1 и часть 2), в закладки админу добавились в интернете новые тексты:

Настройка NetApp FAS – Часть 1 

(Описание контроллера FAS2040, возврат к заводским настройкам, базовая настройка файлера, настройка BMC, обновление Data ONTAP, NTP сервера).

Настройка NetApp FAS – Часть 2

  

(Multimode VIF и его виды, балансировка нагрузки, интерфейсы-партнер в кластере, псевдонимы aka IP Aliasing, flowcontrol и MTU, настройка Static и Dynamic VIF с  коммутатором Cisco Catalyst).

Настройка NetApp FAS – Часть 3

  

(disk ownership, raid group, aggregate, volume, qtree, lun).

Настройка NetApp FAS – Часть 4

  

(iSCSI, настройка iSCSI, безопасность iSCSI, iSNS)

Все это – в блоге http://twistedminds.ru.

Если вы интересуетесь темой, то сходите, посмотрите, может быть полезно. Автор раскрывает тему в несколько ином ключе, и пишет, например, гораздо больше о сетевых настройках и VIF, о которых я в своих постах “самого начала” не говорил (отчасти намеренно).

Ожидается продолжение. да и вообще заглядывайте туда, интересный ресурс.

UPD: Пока пост отстаивался в “отстойнике”, как это обчно и бывает с написанными мной текстами, автор удвоил количество своих постов на данную тему. Шоназывается “респект”.

VMware и использование NFS: часть 3d – Трафик NFS и балансировка Load Based Teaming

Третья часть серии постов в блоге Wahl Network, посвященных вариантам использования NFS в Vmware и организаци балансировки трафика по нескольким физическим путям.

NFS в vSphere – погружение в детали: часть 3, VMware Load Balancing Teaming

 

В предшествующих трех постах этой серии мы рассмотрели основные ошибки и заблуждения, связанные с использованием NFS в VMware, а также рассмотрели два варианта построения сети хранерия с использованием NFS - с единой подсетью, и с множественными подсетями. Если вы не слишком хорошо знакомы с тем, как NFS работает в vSphere, рекомендую вам начать с чтения этих статей. Выводы, к которым мы пришли, состоят в том, что NFS в vSphere требует использовать множественные подсети, чтобы использовать множественные физические линки к системе хранения, за исключением, когда EtherChannel правильно настроен правильно используется на одной подсети. Однако, даже при использовании static EtherChannel, множественные таргеты на стороне стораджа, и правильно спланированные least significant bits в адресе необходимы для использования более одного физического пути к системе хранения.

Continue reading ‘VMware и использование NFS: часть 3d – Трафик NFS и балансировка Load Based Teaming’ »

VMware и использование NFS: часть 3b – Трафик NFS в одной подсети

Для рассмотрения вопроса, как работает доступ к стораджу по NFS с хоста ESXi, я снова воспользуюсь серией постов блога Wahl Network, переводы которых я публикую сегодня и в ближайшие несколько дней. Его автор провел экспериментальную работу, показав то, как работает NFS в сети хранения, когда датасторы и vmkernel расположены в одной общей подсети, в разных подсетях, и рассмотрел вариант использования Load-based teaming, доступный для пользователей версии vSphere уровня Enterprise Plus.

Я надеюсь, что эти статьи ответят на вопрос, как же все же работает NFS в сети хранения vSphere, и как стораджи с использованием этого протокола правильно использовать для VMware vSphere 5.0.

NFS в vSphere – погружение в детали: часть 1, порты vmkernel и экспорты NFS в единой общей подсети

Apr 23, 2012

Конфигурация

Для эксперимента, показывающего, как vSphere направляет трафик NFS в одной подсети, я создал тестовый стенд, с использованием 2 серверов NFS (я использовал для этого NetApp Simulator) с каждого их которых выведено по 2 экспорта, суммарно 4 экспорта NFS. Весь трафик направлен в VLAN 5 (это подсеть 10.0.5.0/24 моего стенда) и идет на хост ESXi 5.0 update 1 (build 623860). Хост имеет 2 физических порта-аплинка и 4 порта vmkernel, дающих трафику NFS множество возможны путей. Для того, чтобы создать существенный трафик в сети хранения, я развернул 4 VM с VMware IO analyzer appliance – по одному на каждый экспорт. Это позволит мне быстро создать трафик с виртуальных машин на все экспорты разом.

Continue reading ‘VMware и использование NFS: часть 3b – Трафик NFS в одной подсети’ »

VMware и использование NFS: часть 3а –Балансировка нагрузки по NFS

Как вы помните, я обещал остановиться на вопросе как именно правильно настраивать работу NFS по нескольким физическим интерфейсам Ethernet. ??так, отдельный разоблачения заблуждений в отношении multipathing для NFS псто!

Как я уже вкратце показал, широкораспространенное заблуждение, что, использовав NFS, вы будете вынужденно ограничены ровно одним интерфейсом ethernet, так как “NFS не поддерживает multipathing” – не верно. К моему глубокому сожалению, это заблуждение местами поддерживает даже сама VMware, несмотря на то, что метод балансировки с помощью нескольких портов VMkernel и нескольких IP-алиасов описан и рекомендуется в их же Best Practices.

Я уже написал ранее, что принципы работы NFS таковы, что даже пустив трафик Ethernet по нескольким объединенным в etherchannel портам, вы не добьетесь не только равномерной их загрузки, но даже не загрузите порты кроме первого. Это по видимому связано с тем, что NFS образует ровно одну TCP/IP сессию для данной пары IP-адресов “источник-приемник”, и именно ее и пускает по первому же подходящему для этого порту. А одну сессию разбить на несколько интерфейсов нельзя. Видимо именно это явилось источником странного заблуждения, что трафик NFS нельзя распределить по нескольким интерфейсам. Это не так, можно. Но нужна некоторая хитрость, в общем-то очевидная. Нужно создать несколько пар IP “источник-получатель”, в разных подсетях, и их уже распределить по интерфейсам.  Об этом подробнее далее в постах серии.

Впрочем, как вы уже видите, неверно и обратное убеждение. Совсем недостаточно объединить несколько портов в etherchannel (у NetApp он называется VIF или ifgrp), чтобы, автоматически, увеличить пропусную способность получившегося интерфейса в Х-раз.

Давайте разберем некоторые распространенные заблуждения на этот счет:

1. Трафик NFS можно назначить на порт VMkernel также, как мы назначаем его для iSCSI.

Это не так. К сожалению.

Как вы видите на рисунке, в обведенном оранжевой рамкой боксе, можно назначить данный порт для: iSCSI, FT, Management или vMotion. Но не для NFS. Трафик NFS пойдет по первому же порту, принадлежащему подсети IP-получателя. Если порта в подсети IP-получателя трафика нет, то трафик пойдет через порт Management, в направлении его default gateway (предсказуемо), и такого варианта следует всеми силами избегать.

2. Трафик NFS равномерно распределяется по всем аплинкам (физическим vmnic) хоста, используемым для связи с системой хранения.

Увы – нет. Когда ESXi нажодит и выбирает подходящий порт vmkernel (принцип выбора описан выше), следуюшим шагом он выбирает аплинк. Независимо от типа vSwitch, хост vSphere использует конфигурацию portgroup по умолчанию (только с использованием virtual port ID), и, при наличии нескольких активных аплинков в группе, будет выбран только один (первый подходящий) аплинк для трафика NFS к данному примонтированному экспорту. Порты в группе при этом работают на поддержку high availability, то есть при выходе из строя активного порта, трафик перейдет на ранее пассивный порт, но не для load balancing, то есть трафик NFS по портам vmnic в группе не распределяется.

3. Достаточно включить несколько физических портов на стороне стораджа в VIF (etherchannel), и трафик магическим образом распределится по всем им, расширяя полосу пропускания интерфейса в Х-раз.

Тоже, к сожалению, в общем случае, без дополнительных усилий, неверно. При наличии одной TCP/IP сессии NFS с одного IP-источника на один IP-получатель, нельзя “разложить” трафик на несколько портов. Но можно это сделать для нескольких портов, нескольких IP-алиасов для получателя и/или  нескольких портов VMkernel. Тогда, создав, например 4 пары IP в разных подсетях, для четырех eth, можно гораздо более равномено загрузить их работой. Это не столь “магически-автоматически”, но это работает. Без такого разбиения и распределения  etherchannel обеспечивает только отказостоустойчивость (при отказе активного порта, трафик перенаправится в другой, ранее неактивный, в той же группе), но не балансировку нагрузки и не расширение bandwidth.

На стороне хоста ESXi для использования балансировки вам необходимо создать static Etherchannel с IPhash-based teaming policy, и иметь у vmkernel IP уникальный, между другими vmk, так называемый least significant bit.

Если у вас на VMware лицензия Enterprise Plus, и вы используете vSphere Distributed Switch, вы также можете воспользоваться Load-based Teaming для распределения трафика по VLAN или подсетям. При этом вам также понадобятся несколько VLAN или подсетей на VIF стораджа. Подробнее о таком варианте – в одном из следующих постов.