about NetApp

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

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

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

Однако существует еще одна опция, доступная для имеющих лицензию Enterprise Plus: она называется политика балансировки (load balancing policy) "Route by physical NIC load", иначе называемая load based teaming (LBT). Эта политика доступна только на distributed switches (vDS),которые не могут быть созданы, если у вас нет лицензии Enterprise Plus.

Load based teaming это очень мощная технология, которая мониторит состояние и загрузку vmnic (аплинка, физического порта хоста). Когда vmnic достигает 75% загрузки на протяжении 30 секунд, LBT пытается перенести нагрузку на другой, незагруженный vmnic. Это было сделано, как мне кажется, в первую очередь для балансировки трафикаVM, то также хорошо работает и для vmknic, несущих трафик NFS. В этом посте я покажу, как этот процесс работает, и как его правильно сконфигурировать.

Load Based Teaming

Концепция мониторинга загрузки и связанной с ним миграции трафика не является новинкой в мире vSphere. Администраторы систем VMwareпостоянно занимаются этим с использованием vMotion, перемещая загруженные виртуальные машины с одного хоста на другие, имеющие свободные ресурсы, например с помощью средств Distributed Resource Scheduler (DRS), помогающего сделать это автоматически.

Некоторые интересные сведения о работе load based teaming:

• Механизм load based teaming работает уровнем над portgroup. Это значит, вам не требуется иметь все ваши VM или vmkernel в одной портгруппе, чтобы использовать load based teaming.
• Когда выбрана опция "Route based on physical NIC load", любая портгруппа будет наблюдаться в отношении загрузки vmnic в ее team и перемещения нагрузки, даже если за генерацию нагрузки ответственна другая портгруппа.
• Однозначно можно сказать, что уровень использования vmnic является триггером для перемещения нагрузки.
• Включение LBT не влияет на активную в момент включения рабочую нагрузку.
  Только активные vmnic используются для перемещения нагрузки. ??нтерфейсы в standby или unused не участвуют в этом процессе.
• Насыщение линка Fast Ethernet (100 Mb/s) не запускает LBT, я протестировал это на стенде, это так, но кто сегодня использует стомегабитные интерфейсы для хоста vSphere?

??так, давайте посмотрим на конфигурацию стенда, который позволит нам увидеть возможности LBT.

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

Ниже на рисунке вы видите логическую схему стенда. Я собрал стенд с использованием одного сервера NAS (Nexenta CE), отдающего 4 экспорта. Весь трафик идет в VLAN 1, 2, 3, и 4 (это подсети 10.0.X.0/24 стенда, где номер VLAN соответствует третьему октету адреса) на хост ESXi 5.0 update 1 (build 623860). Хост имеет два аплинка-физических порта, и 4 порта vmkernel. Для создания стабильного трафика ввода-вывода я установил 4 VM с VMware IO analyzer appliances – по одному на каждый экспорт. Это позволит мне создавать стабильный трафик ввода-вывода на все экспорты одновременно.

Скриншоты

Вместо использования виртуальных хостов я переделал стенд на использование физических хостов и коммутаторов. Это позволили мне проще генерировать достаточно объемный трафик для того, чтобы запустить работу LBT и устранить огромное количество дублирующихся фреймов, принимаемых сетевыми портами, на этот эффект вы, возможно, обратили внимание в предыдущих демонстрациях. Этот эффект был вызван тем, что мои "хосты" стенда были на самом деле виртуальными машинами, с портгруппами в promiscuous mode).

Кроме этого я использовал в качестве сервера NFS физический сервер с Nexenta с парой SSD в нем, что дало мне возможность увеличить предельное количество операций ввода-вывода, необходимых в этом тесте, а также возможность просто смонтировать один датастор в разные VLAN.

Тестирование – Как включается Load Based Teaming

Давайте взглянем на получившуюся систему и рассмотрит то, как порты vmkernel связаны с портами vmnics (аплинками). vmk1 и vmk4 подключены на vmnic3, а vmk2 и vmk3 используют vmnic0. Так решил гипервизор, не будем в это вмешиваться.

Также обратите внимание, что vmk0 (это мой management vmkernel) использует vmnic3 и при этом находится в отдельной портгруппе. Я разрешил использование LBT для этой портгруппы, чтобы убедиться, что LBT в работе не ограничивается пределами одной портгруппы.

Давайте создадим большую нагрузку по трафику на vmnic3 и позволим остальным использовать vmnic0. Я запускаю IO Analyzer, который сидит на VLAN1 (vmk1) и посмотрим, как справится LBT. Ниже вы видите скриншот результата, вместе с данными вывода ESXTOP.

Задача IO Analyzer заполняет трафиком интерфейс vmnic3, поэтому LBT перемешает все другие vmkernels в vmnic0, даже порт управления (management) vmk0, который находится в совсем другой портгруппе. Как вы можете себе представить, это очень мощный метод балансировки нагрузки.

Далее, я генерирую большую загрузку на 3 портах vmkernel, которые сидят на vmnic0, за которым также следит LBT. Ниже вы видите как мы нагрузили трафиком vmk2, vmk3, и vmk4, заполнившим vmnic0.

После оценки трафика в течение 30 секунд LBT включается и переносит vmk2 и vmk3 на vmnic3. Довольно сложно добиться балансировки при использовании 3 потоков трафика, используя 2 физических канала, но LBT довольно неплохо пытается этого добиться.

??того

Как видитеload based teaming прекрасный способ динамически перераспределять нагрузку, к тому же он относительно просто настраивается. Если вы используете лицензию Enterprise Plus и distributed switches (vDS), то, возможно, это будет наилучшим из всех перечисленных способов. Помните, однако, что вам нужно нагрузить ваши vmnic (аплинки, физические порты хоста) достаточным количеством портов vmkernel. В противном случае LBT будет нечего балансировать. Например, если у вас всего 2 vmkernel на 2 vmnic, каждый vmkernel будет закреплен за своим отдельным vmnic – LBT не будет их перемещать и балансировки нагрузк не произойдет. Также не произойдет балансировки нагрузки на незагруженном (менее 75% его физической полосы пропускания) порту vmnic, или если время загрузки выше 75% не превышает 30 секунд.

Надеюсь что серия этих постов развеяла ряд заблуждений и затруднений в понимании работы NFS в VMware vSphere, и вы уже не считаете, что NAS пригоден только для хранения ISO-образов.

??сточник <http://wahlnetwork.com/2012/04/30/nfs-on-vsphere-technical-deep-dive-on-load-based-teaming/>