Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
VMware и использование NFS: часть 3а –Балансировка нагрузки по NFS | about NetApp

VMware и использование NFS: часть 3а –Балансировка нагрузки по NFS

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

4 комментария

  1. Александр:

    А как насчет pNFS?

  2. Александр:

    Роман, пока скорее нет, но я хочу знать о технологии до того как задача появится :)
    в частности мне всегда доставляло некий дискомфорт, что имея HA пару их пространство нельзя было объединить в одно “логическое целое”. Надеюсь корректно выразился и ни в чем не заблуждаюсь. ? как мне кажется pNFS может помочь в этом частном случае.

    Документы зачетные и свежие, буду читать. Спасибо!

  3. Александр:

    Нет, тут вы ошибаетесь. pNFS не дает такой возможности. Строго говоря, это вообще для другого, в первую очередь для задач High-Performance Computing (HPC), когда производительности одного стораджа уже не хватает для обеспечения потоком чтения-записи потребителя. То есть это “конкурент” для Lustre, GPFS, и прочих штук.

    > в частности мне всегда доставляло некий дискомфорт

    Главное чтобы это не доставляло дискомфорт решаемой задаче ;) А уж душевным дискомфортом сисамина часто можно пожертвовать, я считаю :)

    Я упоминал уже в статье про Cluster-mode, разницу между Single Namespace и Single Filesystem. К сожалению организация Single Filesystem на множественных процессорных узлах влечет за собой значительный оверхед на general purpose задачах, как это демонстрирует, например, EMC Isilon (там же).

    Cluster-mode в Data ONTAP, как и pNFS, как средство доступа к нему, это все Single Namespace, но НЕ Single Filesystem.

    Опять же, уже в завершение, вопрос: а у вас есть задача, которая нереализуема иначе, чем через Single Filesystem? А если нет, то не запрягаете ли вы телегу впереди лошади? Решение должно решать какую-то задачу, а не существовать само по себе, для удовлетворения эстетического чувства админа. ;)

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

20/0.082

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией 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.