about NetApp

Как вы помните, я обещал остановиться на вопросе как именно правильно настраивать работу 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 стораджа. Подробнее о таком варианте – в одном из следующих постов.