about NetApp

Для рассмотрения вопроса, как работает доступ к стораджу по 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 – по одному на каждый экспорт. Это позволит мне быстро создать трафик с виртуальных машин на все экспорты разом.

На картинке представлена логическая схема. Отметьте, что vmk10 мы сделали с самый меньшим IP (10.0.5.3) но с самым большим номером vmkernel, далее мы проверим один из интересных моментов с этим связанных:

Скриншоты

Посмотрите на vDS, показывающего 4 порта vmkernel, смаппированных на 2 порта физических карт-аплинков. Все vmkernel находятся в подсети VLAN 5. Больше никаких других vmkernel в VLAN 5 нет; это полностью изолированная подсеть.

Теперь посмотрим на датасторы NFS. Отметьте, что каждый датастор смаппирован в VLAN 5 на пару NetApp Simulators. Маппинг сделан с помощью простого скрипта PowerShell.

Эксперимент #1 – Создание трафика NFS

Для первого эксперимента я установлю виртуалки с IO Analyzer и запущу ESXTOP. Все VM с IO analyzer включены одновременно, и сторадж подключен непосредственно перед загрузкой IO Analyzers, давая возможность датасторам выбрать любой из 4 vmkernels в VLAN 5.

На скриншоте показана конфгурация IO Analyzer для моих 4 VM. Адреса IP, указанные для каждой VM, отражают адреса их management network и не имеют отношения к подсетям для NFS-хранилища.

Весь трафик NFS выбрал vmk7, который использует физический порт карты vmnic6. Видимый на картинке факт того, что vmnic7 также принимает пакеты, является следствием работы ESXTOP в используемом нами "виртуальном ESXi", который требует для работы promiscuous port, поэтому многие received-пакеты дублируются на втором аплинке. Несмотря на этот побочный эффект мы видим, что vmk7 передает все запросы на чтение (12 711,04 PKTTX/s на данном скриншоте).

Эксперимент #1 – Выводы

В этом эксперименте мы проверили несколько вещей.

• vmk7 является наименьшим номером vmkernel, и первым доступным vmkernel в группе (в группе также присутствуют vmk8, vmk9, и vmk10).
• vmk10 имеет наименьший номер IP (10.0.5.3), что опровергает любые предположения, что IP-адрес порта vmkernel влияет на выбор аплинка. Хост не обращает внимания на IP-адрес при выборе порта vmkernel.
• Датастор NFS выбирает для работы не произвольный vmkernel, он выбрает первый vmkernel из списка. Это не обязательно означает vmkernel с наименьшим номером, но обычно порты vmkernel создаются подряд, и нумеруются при этом инкрементально (7, затем 8, затем 9, и так далее).

Эксперимент #2 – Добавление и удаление аплинков

Для этого эксперимента я запустил тот же IO Analyzer, и затем удалил работающий порт vmkernel (vmk7), позволив трафику мигрировать на другой порт vmkernel, а затем добавил vmk7 назад в группу. Этот эксперимент проверяет, ищется ли vmk7 для возвращения на него трафика, или миграция датастора на другой vmkernel постоянна до следующего отказа порта.

Мы видим, что трафик шел через vmkernel 7 (vmk7), который мы удаляем.

Трафик хоста переместился на vmk8. Отметьте, что на картинке уже нет vmk7.

Теперь я добавляю vmk7 обратно в группу.

Трафик остался на vmk8. Ниже на картинке я выделил vmk7 и vmk8.

Я не стану заполнять этот пост картинками, поэтому просто опишу, что когда я удалил vmk8, то увидел, что трафик переместился на vmk9. Удаление vmk9 переместило трафик на vmk10, и, наконец, после удаления vmk10 трафик вернулся на исходный vmk7.

Эксперимент #2 – Выводы

Этот эксперимент дает нам еще несколько выводов:

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

При отключении аплинка мы видим, что vmkernel просто перемещается на другой доступный аплинк.

??того

Я надеюсь, что приведенные эксперименты проясняют некоторую неясность с тем, как работают порты vmkernel в одной подсети с системой хранения NFS. Главный вывод тут: при использовании одной подсети вы не можете организовать балансировку нагрузки трафика NFS в конфигурации по умолчанию.

Если вы используете EtherChannel в единственной подсети, лучшее, на что вы можете рассчитывать, с точки зрения распределения нагрузки, это один vmkernel на хосте и несколько IP на таргете (системе хранения), из которых Load Distribution policy коммутатора сделает IP hash. Но вам необходимы отдельные таргеты для каждого аплинка (vmnic, физического порта хоста), с уникальными least significant bits. Это означает, что если у вас есть два канала-аплинка, вам нужно два IP-таргета на стороне стораджа. Соответственно для 4 аплинков необходимо 4 таргета. ??спользование нескольких портов vmkernel в одной подсети не влияет на EtherChannel Load Distribution так как хост использует только один vmkernel для передачи трафика!

??сточник:
http://wahlnetwork.com/2012/04/23/nfs-on-vsphere-technical-deep-dive-on-same-subnet-storage-traffic/

В следующем посте мы посмотрим на практике как ведет себя другая конфигурация - с несколькими портами vmkernel в разных подсетях.