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

На картинке представлена логическая схема. Отметьте, что 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 в разных подсетях.

Оставить комментарий

20/0.135

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.