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
Etherchannel | about NetApp

Posts tagged ‘etherchannel’

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

Continue reading ‘VMware и использование NFS: часть 3b – Трафик NFS в одной подсети’ »

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

О использовании EtherСhannel в vSphere

Несмотря на то, что основная тема блога – системы хранения, прежде всего системы хранения NetApp, поневоле приходится затрагивать интересные смежные темы. Раз уж мы заговорили тут про NFS, стоит затронуть тему использования LACP при организации EtherChannel, так как, как я заметил, понимание этой темы у многих все еще довольно зыбкое.

Поэтому, в очередных переводах в этом блоге – перевод поста в интересном блоге Wahl Network

Демистификация LACP и Static EtherChannel в vSphere

May 9, 2012

Удивительно часто я слышу о людях, которые воспринимают LACP как некую волшебную палочку, которой достаточно махнуть, и все чудесным образом становится лучше, а трафик волшебным образом распределяется по множеству линков. Я думаю, что это происходит от непонимания базового устройства того, как работает EtherChannel, так как я слышал множество ошибочных утверждений и FUD вокруг этого. Этот пост является попыткой описать то, что же за штука, этот LACP, почему он не работает на обычных, native vSphere switches, и почему он, на деле, имеет совсем небольшое количество преимуществ, в сравнении со static EtherChannel.

?так, что такое LACP?

LACP, иначе известный как IEEE 802.1ax Link Aggregation Control Protocol, это простой способ динамически строить EtherChannel. Для этого "активная" сторона группы LACP посылает специальный фрейм, оповещающий о возможностях и желаемых формах EtherChannel. Возможно существование, и чаще всего так и бывает, когда обе стороны являются "активными" (может быть и пассивная сторона). Также следует отметить, что LACP поддерживает только full duplex линки (в настоящий момент, в мире гигабитных, и более, линков, которые всегда full duplex, это уже не является значимым ограничением). Как только обмен фреймам произведен, и порты на обоих сторонах согласовали поддержку требований, LACP создает EtherChannel.

Внимание: LACP также имеет ряд дополнительных возможностей при установке EtherChannel, например вычисление приоритета системы или порта, конфигурацию административного ключа, и так далее. Для нас сейчас это все не важно, поэтому эти детали мы опускаем, если хотите разобраться в подробностях, вам придется изучить эти опущенные подробности самостоятельно.

LACP отсутствует в Native vSphere Switches

Ситуация проста, нативные коммутаторы vSphere не отвечают на фреймы LACP. Они не слушают и не передают соответствующие кадры. Если вы настроили LACP на внешнем коммутаторе, он не получит отклика на запросы LACP от хоста vSphere, и, следовательно, EtherChannel не будет создан.

Если вы хотите создать EtherChannel с участием хоста vSphere, вы должны создать Static EtherChannel. Когда порт установлен в Static, он не участвует в процессах объявления или распознавания LACP – канал EtherChannel немедленно создается физическим коммутатором.

Как работает распределение нагрузки (Load Distribution)?

Главная мысль:
Как Static так и Dynamic (LACP) EtherChannel используют одни и те же методы распределения нагрузки (load distribution).

Я специально выделил это курсивом и жирным шрифтом. Да, это правда. ? Static, и LACP используют одни и те же техники балансировки нагрузки для распределения трафика по линкам. Если кто-то утверждает иное, то можете поспорить с ним на деньги, можете хорошо выиграть.

Но Static EtherChannel требует IP Hash, а LACP - нет, не так ли?

А сейчас переходим в темную часть. Ответ на заданный в заголовке вопрос: "Это не так", но вот почему это не так?

IP Hash это требование native vSphere switch. Он не поддерживает никакие другие методы load distribution.

clip_image001

Скриншот выше взять из vSphere Networking guide

А это уведомление из vSphere:

clip_image002

Отметьте, что если я хочу использовать EtherChannel, я выбираю IP Hash в качестве метода балансировки, и появляется данный бокс с сообщением.

Внимание: Термин IP Hash эквивалентен политике load distribution policy вида src-dst-ip на коммутаторе Cisco.

Static EtherChannel в других случаях может использовать любые из доступных политик распределения нагрузки. Но когда порты работают с хостом vSphere, мы вынуждены использовать только IP Hash, так как vSphere ничего другого не умеет.

Если вы хотите использовать LACP с vSphere, вам потребуется установить виртуальный коммутатор Cisco Nexus 1000V (или IBM 5000v). Нет других способов задействовать LACP с vSphere на момент написания этого поста. ?, так как 1000V это (почти) полнофункциональный коммутатор Cisco, в отличие от native vSphere switch, вы можете использовать любые политики load distribution – вы не ограничены только IP Hash (src-dst-ip)

Преимущества LACP перед Static

LACP имеет несколько "карт в рукаве", но это не относится к методам распределения трафика по каналам EtherСhannel.

Hot-Standby Ports

Если вы добавите больше поддерживаемого числа портов в LACP port channel, есть возможность использовать лишние порты в качестве портов hot-standby mode. Если произойдет отказ активного порта, порт hot-standby автоматически заменит его.

Однако, типичное число поддержваемых портов в LACP равно 8, так что для системы vSphere это не та возможность, о коорой стоит беспокоиться. Сомнительно, что у вас сделан 8-канальный EtherChannels к одному хосту vSphere.

Failover

Если у вас имеется dumb-устройство между двумя концами EtherChannel, например media converter, и один из линков, идущих через него отказывает, LACP это понимает и перестает слать трафик в отказавший линк. Static EtherChannel не мониторит состояние линков. Это не типичная ситуация для большинства систем vSphere, которые мне встречались, но в ряде случаев это может оказаться полезным.

Проверка конфигурации

EtherChannel с использованием LACP не активируется, если есть какие-то проблемы с конфигурацией. Это помогает убедиться, что все настроено нормально. Static EtherСhannel не делает каких-либо проверок перед своим задействованием, то есть вам нужно заранее быть уверенными, что все сделано правильно.

Выводы

Я не хочу сказать, что LACP (или Nexus 1000V) это плохо. LACP - это очень полезный и популярный протокол, активно используемый. Проблема, побудившая меня написать этот пост в том, что я вижу людей, которые считают что с использованием LACP они получат лучшую балансировку трафика, или же что-то еще, что он совершенно точно не делает. Так что не спешите закупать Cisco 1000V для вашей системы vSphere только оттого, что вы хотите использовать LACP, пока вы не будете иметь ясного плана того, что, на самом деле, вы хотите получить в результате.

?сточник:
http://wahlnetwork.com/2012/05/09/demystifying-lacp-vs-static-etherchannel-for-vsphere/

Multimode VIF в NetApp (часть 2)

MAC Load-Balancing
Этот алгоритм используется не так часто, так как ему присущ ряд недостатков. Основанный на использовании MAC алгоритм балансировки вычисляет XOR между MAC-адресами пар источника и получателя. ?сточником будет MAC-адрес сетевой карты хосте, подключенного к контроллеру  NetApp. Получателем будет MAC-адрес VIF-интерфейса контроллера NetApp. Алгоритм работает хорошо, когда хосты и контроллер NetApp размещаются в одной подсети или VLAN. Когда хост расположен в другой подсети относительно контроллера NetApp, мы сталкиваемся с недостатками алгоритма. Для понимания того, что происходит, нам надо разобраться с тем, что происходит с фреймом Ethernet, когда он маршрутизируется по сети.

Допустим, мы хотим соединить Host1 с Controller1.

Host1 IP address - 10.10.1.10/24 (default gateway для Host1 - 10.10.1.1)
Controller1 IP address - 10.10.3.100/24 (default gateway для Controller1 - 10.10.3.1)

Выше мы задали для Host1 и Controller1 две отдельные подсети. Единственный путь передачи данных в том случае - через роутер. В рассматриваемом случае, роутер для подсетей 10.10.1.1 и 10.10.3.1 это один и тот же физический роутер, эти адреса просто два физических его интерфейса. Задача роутера - связать две подсети, и обеспечить передачу данных между ними.

Когда Host1 передает frame предназначенный для Controller1, он отправляет его на роутер по адресу default gateway, так как видит, что адрес 10.10.3.100 это IP-адрес не его локальной подсети, потому он отправляет его в адрес default gateway, по которому расположен роутер, в надежде, что роутер знает что с ним делать дальше, и найдет путь к получателю.

с Host1 на Host1Router

-IP Source: Host1 (10.10.1.10)
-MAC Source: Host1
-IP Destination: VIFController1 (10.10.3.100)
-MAC Destination: Host1DefaultRouter

с Host1Router на Controller1

-IP Source: Host1 (10.10.1.10)
-MAC Source: Controller1DefaultRouter
-IP Destination: VIFController1 (10.10.3.100)
-MAC Destination: VIFController1

Обратите внимание: MAC-адреса источника и получателя меняются, когда фрейм передается по сети. Так работает маршрутизация, и когда маршрутизаторы встречаются на пути несколько раз, то и MAC будет изменен несколько раз по пути от источника к получателю. Не важно сколько раз конкретно, главное что он меняется когда фрейм попадает в локальный сегмент контроллера. MAC источника будет являться MAC-ом роутера, а получателем – MAC-адрес VIF контроллера. Для полного понимания проблемы, допустим у нас есть четыре 1Gbps канала, объединенных в Etherchannel на Controller1. Допустим у нас есть 50 хостов в той же подсети, что и  Host1. Пары source и destination для соединения Host1 к Controller1 будут ровно теми же, что и любых других хостов в подсети host1, так как  MAC-адреса source и destination всегда будут равны Controller1DefaultRouter и VIFController1.

IP Load-Balancing
IP Load-Balancing это параметр по умолчанию для всех NetApp MultiMode VIF и наиболее часто используемый на практике метод построения MultiMode VIF на сегодня. Алгоритм не отличается от уже рассмотренного алгоритма с использованием MAC, который мы расмотрели выше. Разница только в том, что мы используем IP-адреса ?сточника (Source) и Получателя (Destination), которые, если вы посмотрите рассмотренный ранее вариант, никогда не менятся, в отличие от  адресов MAC. Факт того, что IP-адреса не меняются, создает сценарий, в котором у вас больше шансов получить уникальные пары, что, в результате, приводит к более равномерному распределению трафика по физическим линкам.

Для правильного понимания механизма работы следует учесть один важный момент, касающийся пар IP-адресов source и destination: при вычислении пар source-destination принимаются во внимание только последние октеты адресов. Это означает, что в адресе 10.10.1.10 будет использован для идентификации только 10 – последний октет адреса, в адресе 10.10.3.100 - только 100. Принимать во внимание этот момент следует в случае развертывания системы в сети, состоящей из нескольких подсетей, в этом случае может получиться так, что адреса из разных подсетей (но с одинаковым последним октетом) будут передаваться по одному физическому линку.

IP Aliasing
Понимание принципов алгоритмов Load-Balancing позволяет вам, как администратору, использовать их к собственной выгоде. Все NetApp VIF и физичские интерфейсы имеют возможность назначить им так называемые “алиасы”. Это просто дополнительный адрес для самого VIF. Рекомендуется назначит адреса(для VIF + определенное количество алиасов) равное числу физических линков в EtherChannel между контроллером и коммутатором, к которому подключен контроллер. Таким образом если вы используете VIF, состоящий из  4 штук 1Gbps линков в виде MultiMode VIF между контроллером и коммутатором, то назначьте один адрес для VIF и добавьте к нему три алиаса для того же VIF.

Простое назначение дополнительных адресов не поможет использовать преимущества дополнительных адресов. Вы должны убедиться, что хосты, которые смонтировали данные с контроллеров NetApp используют все эти адреса. Этого можно достичь несколькими разными путями, в зависимости от того, какие протоколы используются для доступа к данным, ниже приведены некоторые примеры для NFS.

Oracle NFS -  хосты с Oracle должны монтировать тома NFS равномерно распределяя их по доступным  IP-адресам контроллера. Если у вас есть 4 различных NFS ресурса, то смонтируйте их используя для доступа четыре различных IP-адреса контроллера. Каждый ресурс будет иметь различную пару из источника и получателя (source and destination pair) и полоса передачи между хостом и контроллером будет использована более эффективно.

VMware NFS – хосты ESX должны монтировать каждый NFS Datastore через различные IP-адреса контроллера NetApp. Такой вариант наилучшим способом использует один интерфейс VMkernel (адрес источника (source)). Если у вас больше датасторов, чем  IP-адресов, то просто распределите датасторы по доступным IP-адресам контроллера NetApp поравномернее.

Обратите внимание: Когда вы назначаете алиас интерфейсу, и у вас установлены и включены партнерские отношения между двумя контроллерами (и, естественно, их физическими интерфейсами) кластера NetApp, то в случае кластерного файловера алиасы также перенесутся на партнерский интерфейс

Ну и, наконец, обещанные шаблоны:

Continue reading ‘Multimode VIF в NetApp (часть 2)’ »

20/0.102

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