about NetApp

Продолжаем публикацию переводов серии постов в блоге Wahl Network, посвященных вариантам использования NFS в VMware.

NFS в vSphere – погружение в детали: часть 2, порты vmkernel и экспорты NFS в разных подсетях

Apr 27, 2012

Ранее мы уже рассмотрели некоторые ошибочные концепции относительно NFS в vSphere, а также убедились в том, как трафик NFS идет при использовании одной подсети. Сейчас давайте посмотрим, как трафик NFS в vSphere пойдет в случае использования множественных подсетей. Хотя мы говорим тут прежде всего о NFS, это все также применимо и в случае iSCSI, если для него не используется binding.

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

Стенд выглядит похожим на уже рассмотренный в преыдущем посте этой серии, но мы настроили в нем отдельные VLAN для каждого vmkernel и таргета на стороне системы хранения.

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

Скриншоты

Сперва давайте посмотрим на vDS, с новыми vmkernels в подсетях. Для простоты запоминания я использовал одинаковый четвертый октет (53) для IP портов vmkernel. Каждый vmkernel находится в выделенной VLAN (подсети) в транкированных портах аплинка.

??спользованные датасторы также различны, и каждый замаплен на свой VLAN.

Тестирование – Создание трафика NFS

На самом деле есть только одна причина, почему я делаю несколько vmkernels в нескольких подсетях: монтирование каждого экспорта в отдельной подсети (VLAN) заставляет трафик идти из этого vmkernel в конкретную подсеть (VLAN). Для проверки, я эмулирую нагрузку, загрузив все четыре VMware IO Analyzers, чтобы увидеть, как пойдет трафик и удовтовериться в правильности моей гипотезы. Как вы помните из описания выше, каждая VM смаплена на отдельную подсеть (VLAN).

Ниже приведен скриншот генерации нагрузки в IO Analyzer. Снова хочу отметить, что приведенные на скриншоте VM IP это порты сети management, они не относятся к трафику NFS, о котором мы говорим здесь.

Когда VM начали генерировать трафик, мы видим, что он пошел через все 4 vmkernel, и оба vmnics (физических порта, аплинка) одновременно.

Но постойте!

Если все четыре VM посылают трафик, как мы можем быть уверены, что трафик определенной подсети остается только в ней, и в vmkernel этой подсети?

??нтересный вопрос. Я запущу трафик только в VLAN 4 (vmkernel 6) и посмотрим что произойдет. Ниже скриншот ESXTOP, показывающий, что весь трафик посылается только через vmkernel 6 в VLAN 4 (10.0.4.0/24).

Тестирование – Выводы

Проведенное тестирование, и его результаты, позволяют сделать следующие выводы:

• Гипервизор следует стандартным правилам маршрутизации. Если у вас есть IP-источник (vmkernel) в подсети, и вы подключаетесь к IP-адреса получателя в той же подсети, то гипервизор пошлет трафик напрямую. Он не будет использовать default gateway (management vmkernel).
• ??спользование отдельных подсетей для разделения трафика позволяет задейстовать множественные vmkernel (один для каждой подсети).
• Пока vmkernel присутствует в подсети, гипервизор будет использовать его для всего трафика, предназначенного на таргет в той же подсети. Трафик не выходит за пределы своей подсети, если это не требуется для передачи данных.
• Если вы создали несколько подсетей и поместили порты vmkernel в каждую подсеть, которая также имеет там и порт интерфейса системы хранения, вы можете монтировать экспорты NFS в разные подсети, добиваясь организации статической балансировки нагрузки.

Закрепление трафика за портом

Дополнительно вы можете воспользоваться возможностью закрепить (pinning) трафик за определенным портом аплинка. Если у вас есть 2 физических порта хоста (аплинка), как в случае моего стенда, например, вы можете сделать следующее:

• Создайте две подсети для NFS
• Создайте две portgroup, по одной для каждой подсети, и поместите vmkernel в каждой portgroup для этой подсети.
• Установите первую portgroup uplink team как active / standby, заставляя трафик идти через первый аплинк.
• Установите вторую portgroup uplink team как standby / active, заставляя трафик идти через второй аплинк.
• Подключите экспорты (датасторы) через выделенные подсети, как вам необходимо.

При такой схеме вы можете подключать экспорты в каждой подсети, основываясь на известных показателях их загрузки. Если подсеть 1 заполнена трафиком NFS, можно перенести VM и ее трафик на датастор в подсети 2, с помощью Storage vMotion.

??того

??спользование метода множественных подсетей должно быть методом де-факто для балансировки трафика, когда использование EtherChannel невозможно (или нежелательно). Нет способа направить трафик через несколько аплинков и vmkernels без использования множественных подсетей, так как, в противном случае, трафик пойдет через один единственный путь.

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