Route based on ip hash vmware настройка

Обновлено: 07.07.2024

On VMware ESXi, port bonding configuration operations for servers managed by a cluster and servers not managed by a cluster are different. For servers not managed by a cluster, the operations vary according to different OSs. The following describes operations for VMware ESXi 6.0.3 and VMware ESXi 6.5 servers not managed by a cluster, and operations for vSphere Client servers managed by a cluster.

VMware ESXi 6.0.3

Install VMware ESXi 6.0.3 on a compute node and install vSphere Client on a PC as the management terminal.
On the System Customization screen, select Configure Management Network > Network Adapter.

Figure 4-33 Specifying the physical port of the management network

The management network refers to the PC where vSphere Client is installed. The vmnic is also used to connect to the service network.
If multiple vmnics are select, the hypervisor (VMware ESXi) chooses a vmnic as the default management network port for connecting to the management network. The management network port can be changed.

Figure 4-34 Specifying the physical port of the management network
Figure 4-35 Setting an IP address for a vmnic for connecting to the management network

VLAN (Optional) on the Configure Management Network screen is an optional parameter. You do not need to configure a VLAN for connecting to the management network.

Figure 4-37 Setting Connection Types to Virtual Machine
Figure 4-38 Selecting two physical network ports of the SM330

After the vSwitch is added, click Finish.

Figure 4-43 Setting NIC teaming to the active/standby mode
Figure 4-44 Finishing the NIC teaming configuration for vSwitch1

VMware ESXi 6.5

Use a browser to log in to the management network IP address, enter the username and password to access the management page.

Click the NIC Teaming tab and configure Load Balancing, Network Failover Detection, Notify Switches, Failback, and Failover Order. By default, both vmnic0 and vmnic1 are active adapters. Select vmnic1 and click Mark standby to set vmnic1 as a standby adapter. After the active/standby bonding configuration is complete, click Save.

Options of Load Balancing are as follows: Route based on originating virtual port ID, Route based on source MAC hash, Route based on IP hash, and Use explicit failover order.

Распределение нагрузки трафика между физическими и виртуальными сетями.

Также обеспечивает пассивную отказоустойчивость, в случае сбоя оборудования или сбоя в работе сети.

Для того, чтобы использовать NIC Teaming нам потребуется минимум два активных сетевых адаптера.

Настройка NIC Teaming

Для настройки будем использовать vSphere клиент.

Шаг 1. Подключаемся к хосту и переходим на вкладку Конфигурация, Сеть (Configuration - Networking )

Шаг 2. Переходим в свойства - сетевые адаптеры (network adapters) - Добавить (Add).

Шаг 3. Выбираем неназначенный интерфейс и нажимаем Далее.

Шаг 4. Проверяем что выбранные адаптеры находятся под вкладкой Активные адапторы

Шаг 5. Нажимаем Далее и Финиш

Шаг 6. На вкладке портов выбираем необходимую группу портов и переходим в свойства

Шаг 7. Переходим на вкладку NIC Teaming и выбираем нужную политику балансировки нагрузки

Режимы работы

Route based on the originating virtual switch port ID – распределение на основе идентификатора порта виртуального коммутатора. Этот механизм используется по умолчанию. Он выбирает для uplink-порт, на основании номера виртуального порта на виртуальном коммутаторе. Один виртуальный адаптер может одновременно использовать только один физический адаптер.

Данный механизм может обеспечивать равномерное распределение, если количество виртуальных сетевых адаптеров превышает количество физических адаптеров. Он не подходит для виртуальных серверов, обрабатывающих большое количество запросов от разных клиентов, когда необходимо разделять трафик одной виртуальной машины (с одним виртуальным сетевым адаптером) по нескольким NIC’ам. Этот механизм не позволяет использовать технологию агрегирования каналов 802.3ad. Кроме всего прочего проблемы могут возникнуть с доступом к IP-хранилищам (iSCSI, NFS), так как VMkernel аналогично сможет использовать только один физический NIC для работы с разными iSCSI-таргетами.

Route based on source MAC hash - распределение на основе хеширования MAC-адреса источника. Этот механизм аналогичен предыдущему и использовался по умолчанию в более ранних версиях ESX Server.

Route based on IP hash - распределение на основе хеширования IP-адреса источника и получателя. Трафик с одной виртуальной машины, направленный на разные IP-адреса, распределяется по разным физическим сетевым адаптерам. Для использования этого механизма необходимо включить поддержку 802.3ad на физическом коммутаторе, к которому подключен ESX Server.

Равномерность распределения трафика зависит от числа TCP/IP-сессий между хостом и различными клиентами. При большом количестве соединений Route based on IP hash позволяет распределять нагрузку наиболее равномерно и не имеет недостатков присущих механизму Route based on the originating virtual switch port ID.

Use explicit failover order - для передачи трафика используется первый по списку активный физический сетевой адаптер виртуального коммутатора, определенный параметром failover order, который определяет Active/Standby режим NIC’ов по отношению к виртуальному коммутатору.

Этот механизм удобно использовать на уровне портов виртуальных машин, сервисной консоли и VMkernel. Например, установив для сервисной консоли активный режим первого NIC’а и пассивный для второго, а для порта VMkernel соответственно наоборот, можно таким образом сконфигурировать failover для сетей управления.

В данной статье рассматриваются назначения NIC Teaming в сетевой конфигурации VmWare ESXi и приводится пример настройки на основе Route based on IP hash.

NIC Teaming это агрегирование каналов, то есть объединение физических каналов в логические.

Load Balancing

Первым пунктом в настройке является load-balancing policy. Говоря по простому мы выбираем как vSwitch будет обрабатывать исходящий трафик.

Имеется 4 варианта обработки трафика:

Route based on the originating virtual port
Route based on IP hash
Route based on source MAC hash
Use explicit failover order

Route based on the originating virtual port

Данная опция является стандартным для любого только что созданного vSwitch и каждая виртуальная машина и VMkernel порт на vSwitch подключён к виртуальному порту. Когда vSwitch получает трафик от подключённых к нему объектов он назначает виртуальный порт и физический порт и использует его для передачи данных. Выбранный физический порт не меняется до тех пор пока не произойдёт какая либо ошибка или виртуальная машина не выключится или не мигрирует на другой сервер.

Route based on IP hash

Данная опция используется совместно с группой агрегации каналов LAG, так же называется EtherChannel или Port Channel. Когда трафик попадает на vSwitch, политика балансировки каналов создаёт в пакете хеш IP-адреса источника и назначения. Результирующий хеш указывает какой физический порт будет использоваться.

Route based on source MAC hash

Данная опция схожа по принципу работы с Route based on IP hash, за исключением того, что политика рассматривает только MAC-адрес источника в кадре Ethernet.

Use explicit failover order

Данная опция в действительности не выполняет никакой балансировки нагрузки и если у вас используется для подключения несколько физических портов то в любой момент времени использоваться будет только один. Сначала система пытается использовать первый активный физический сетевой порт. Если использовать первый физический порт не удаётся, то используется следующий активный физический порт и так далее.

Network Failure Detection

Данный пункт отвечает за определение ошибок в подключении физических портов и имеет две опции.

link status only

Данная опция позволяет определить ошибки, вызванные отключением кабеля или проблемой физического интерфейса и не способна определять конфигурационный ошибки, такие как если физический коммутатор заблокировал порт из-за ошибок конфигурации VLAN,spanning tree или отключения кабеля на другой стороне физического коммутатора.

Beacon probing

Данная опция отправляет и слушает специальные пакеты-маяки на все физические интерфейсы в группе и использует полученную информацию. В дополнение так же использует статус физического порта для определения проблемы подключения. Данная опция способна более точно определить проблему в отличие от link status only.

Не используйте Beacon probing вместе с Route based on IP hash чтобы избежать ложных срабатываний.

Notify Switches

По умолчанию данный пункт установлен как "YES" и он позволяет уведомить коммутатор о том, что виртуальная машина использует другой физический порт, посылая специальный Reverse Address Resolution Protocol фрейм принимающим физическому коммутаторы для обновления таблицы MAC-адресов коммутатора.

Failback

Данная опция отвечает за активацию физического порта, который находится в режиме ожидания если больше нет ни одно активного физического порта. Опция представляет своего рода активацию запасного порта на случай сбоя активного порта. Так же система переводит "запасной" порт в режим ожидания если соединение по "основному" порту восстановлено.

Failover Order

Данная опция отвечает за отказоустойчивость и имеет 3 разных статуса адаптера:

Active adapters

Адаптеры, используемые для передачи трафика.

Standby adapter

Адаптеры в режиме ожидания, используются если активные адаптеры дали сбой.

Unused adapters

Неиспользуемые для передачи трафика адаптеры.

Пример настройки

Пример показывает как с помощью vSphere Client можно настроить NIC Teaming на хосте с использованием Route based on IP hash.

В моем случае все физические порты ESXi хоста подключены к коммутатору Cisco, на котором уже собран EtherChannel

1. Выбираем необходимы хост и переходим во вкладку Configuration - Networking. По умолчанию в системе всегда уже имеется стандартный vSwitch - его свойства мы и откроем нажав на кнопку Properties.

2. В появившемся окне выбираем vSwitch и нажмем кнопку редактировать Edit

3. В появившемся окне откроем вкладку NIC Teaming и укажем следующие параметры:

Опцию Load Balancing установим в Route based on IP hash
Опцию Network Failure Detection установим в link status only
Опцию Notify Switches установим в Yes
Опцию Failback установим в Yes

Так же проследим, что все физические порты активированы и переведены в раздел Active Adapters

Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.

Если зайти в настройки вКоммутатора или группы портов, то последней закладкой мы увидим «NIC Teaming», группировка контроллеров. Она нам потребуется в том случае, если к вКоммутатору у нас подключен более чем один физический сетевой контроллер сервера (vmnic).

А зачем мы можем захотеть, чтобы к одному вКоммутатору были подключены несколько vmnic? Ответ прост: для отказоустойчивости в первую очередь и для повышения пропускной способности сети - во вторую.

Обратите внимание. Если мы подключаем к одному виртуальному коммутатору, стандартному или распределенному, несколько физических сетевых контроллеров, то они должны быть из одного домена широковещательной рассылки. VMware не рекомендует подключать к одному вКоммутатору сетевые карты, подключенные в разные физические сети или разные VLAN: коммутаторы виртуальные обрабатывают только кадры Ethernet (второй уровень модели OSI) и не могут осуществлять маршрутизацию.

Если у вКоммутатора только один физический сетевой контроллер, то сам этот контроллер, его порт в физическом коммутаторе и физический коммутатор целиком являются единой точкой отказа. Поэтому для доступа в сеть критичных ВМ более чем правильно использовать два или более vmnic, подключенных в разные физические коммутаторы.

Но здесь встает вопрос политики их использования. Мы можем использовать конфигурацию, дающую лишь отказоустойчивость - когда работает только один vmnic, а остальные ожидают его выхода из строя, чтобы подменить его. Или мы можем задействовать сразу несколько сетевых контроллеров сервера, тем или иным образом балансируя между ними нагрузку.

Взглянем на окно настроек - рис. 2.32.

Failover Order. Самое нижнее поле позволяет выбрать используемые (Active Adapters), запасные (Standby Adapters) и неиспользуемые (Unused Adapters) физические сетевые контроллеры из подключенных к этому вКоммутатору. Если вы хотите, чтобы какие-то vmnic стали резервными и не были задействованы в нормальном режиме работы, тогда перемещайте их в группу Standby. Все (или несколько) оставляйте в Active, если хотите балансировку нагрузки. Ну а Unused обычно нужна на уровне групп портов - когда у вКоммутатора много каналов во внешнюю сеть, но трафик именно конкретной группы портов вы через какие-то пускать не хотите ни при каких обстоятельствах.

Failback. Эта настройка напрямую относится к Failover Order. Если у вас vmnic3 Active, а vmnic2 Standby, то в случае выхода из строя vmnic3 его подменит vmnic2. А что делать, когда vmnic3 вернется в строй? Вот если Failback выставлен в Yes, то vmnic2 опять станет Standby, а vmnic3 - опять Active. Соответственно, если Failback = No, то даже когда vmnic3 опять станет работоспособным, он станет Standby. Каким образом ESX(i) понимает, что vmnic неработоспособен? См. пункт Network Failover Detection.

Notify Switches. Эта настройка включает (Yes) или выключает (No) оповещение физических коммутаторов об изменениях в MAC-адресах ВМ на ESX(i). Когда вы создаете новую ВМ и подключаете ее к группе портов (как вариант -добавляете в ВМ еще один виртуальный сетевой контроллер) или когда трафик ВМ начинает идти через другой vmnic из-за сбоя ранее задействованного - тогда ESX(i) отправит пакет rarp с оповещением вида «Такой-то MAC-адрес теперь доступен на этом порту».

Рис. 2.32. Окно настроек группировки контроллеров -NIC Teaming

Рекомендуется выставлять в Yes для того, чтобы физические коммутаторы максимально быстро узнавали о том, на каком их порту доступен MAC-адрес ВМ. Однако некоторые приложения потребуют выключения этой функции, например кластер Microsoft NLB.

Network Failover Detection. Каким образом ESX(i) будет определять, что физический сетевой контроллер неработоспособен? Вариантов два:

- Link Status Only - когда критерием служит лишь наличие линка, сигнала. Подобный режим позволит обнаружить такие проблемы, как выход из строя самого vmnic, отключенный сетевой кабель, обесточенный физический коммутатор.

Такой подход не поможет определить сбой сети в случае неправильной настройки порта, например внесение его в неправильный VLAN и т. п. Также он не поможет в случае, если обрыв сети произошел где-то за физическим коммутатором;

- Beacon Probing - эта функция нужна только тогда, когда у вКоммутатора несколько внешних подключений (рис. 2.33) к разным физическим коммутаторам. При этой настройке, кроме проверки статуса подключения, виртуальный коммутатор еще рассылает (с интервалом порядка 5-10 секунд) через каждый свой vmnic широковещательные пакеты, содержащие MAC-адрес того сетевого интерфейса, через который они ушли. И ожидается, что каждый такой пакет, посланный с одного vmnic, будет принят на других vmnic этого вКоммутатора. Если этого не происходит - значит где-то по каким-то причинам сеть не работает.

Рис. 2.33. Пример конфигурации сети, при которой имеет смысл использовать Beacon Probing

В этом примере пакеты, посланные через vmnic5, не дойдут до клиентов, подключенных к «дальним» физическим коммутаторам. Если для определения отказов сети используется «Link status only» - то ESX(i) не сможет определить такую неработоспособность сети. А beaconing сможет - потому что широковещательные пакеты от vmnic5 не будут приняты на vmnic3 и vmnic2.

Но обратите внимание: если beacon-пакеты отправляются и не принимаются в конфигурации с двумя vmnic на вКоммутаторе, то невозможно определить, какой из них не надо использовать - ведь с обоих beacon-пакеты уходят и на оба не приходят.

Тогда вКоммутатор начинает работать в режиме «Shotgun», что здесь можно перевести как «двустволка», - начинает отправлять весь трафик через оба подключения, мол, через какой-то да дойдет.

Конечно, такой ситуации лучше избегать. Сделать это можно правильной структурой физической сети, чтобы какие-то проблемы в ней решались за счет Spanning Tree. Вообще, механизм beaconing позиционируется как крайнее сред ство - если вы не можете повлиять на правильность конфигурации сети на физической стороне, то подстрахуйтесь от сбоев с помощью beaconing. Но эффективнее, когда подобные сбои в сети устраняются средствами этой сети и beaconing вам не нужен.

Наконец, самая интересная настройка.

Load Balancing. В этом выпадающем меню вы можете выбрать, по какому алгоритму будет балансироваться трафик виртуальных машин между каналами во внешнюю сеть виртуального коммутатора, к которому они подключены.

- Route based on the originating port ID - балансировка по номеру порта. У каждой ВМ (у каждого виртуального сетевого контроллера в ВМ) есть порт в вКоммутаторе, к которому она подключена. При данном варианте настройки балансировки нагрузки трафик будет делиться по этим портам - весь трафик от одного порта вКоммутатора будет идти в какой-то один vmnic; трафик из другого порта - через другой vmnic и т. д. Выбор очередного vmnic осуществляется случайным образом, не по его загрузке. Данный метод балансировки нагрузки используется по умолчанию и является рекомендуемым. Рекомендуемым он является потому, что дает какую-никакую балансировку нагрузки, а накладные расходы на анализ трафика минимальны. Однако трафик от одного виртуального контроллера не получит полосы пропускания больше, чем дает один физический интерфейс, выступающий каналом во внешнюю сеть. Косвенный вывод отсюда - виртуальная машина с несколькими виртуальными сетевыми контроллерами сможет задействовать несколько каналов во внешнюю сеть;

- Route based on source MAC hash - балансировка по MAC-адресу источника. В этом случае трафик делится на основе MAC-адреса источника пакета. Таким образом, исходящий трафик делится точно так же, как и в случае балансировки по портам. На практике метод практически не применяется;

- Route based on ip hash - балансировка по хэшу (контрольной сумме) IP. Здесь критерием разделения трафика считается пара IP-источника - IP-получателя. Таким образом, трафик между одной ВМ и разными клиентами, в том числе за маршрутизатором, может выходить по разным vmnic. Этот метод балансировки нагрузки является самым эффективным, однако он может вызвать большую нагрузку на процессоры сервера, так как именно на них будет вычисляться хэш IP-адресов для каждого пакета.

Также этот метод балансировки требует настроенной группировки портов (известной как link aggregation, Ether-Channel, Ethernet trunk, port channel, Multi-Link Trunking) на физическом коммутаторе, к которому подключен коммутатор виртуальный. Это вызвано тем, что при данном методе балансировки нагрузки MAC-адрес одной ВМ может одновременно числиться на нескольких vmnic, как следствие - на нескольких портах коммутатора физического. Что не является допустимым в штатном режиме работы, без группировки портов.

В обратную сторону - если вы хотите настроить группировку портов между физическим и виртуальным коммутаторами, то вы настраиваете ее на физическом; а на виртуальном ставите балансировку по хэшу IP для нужных групп портов - и все.

Последний нюанс: если у вас один коммутатор виртуальный подключен к нескольким физическим (из соображений отказоустойчивости), то далеко не с любыми физическими коммутаторами получится использовать этот тип балансировки нагрузки в такой конфигурации.

ESX(i) не поддерживает автоматической настройки группировки портов с помощью Link Aggregation Control Protocol (LACP).

Link Aggregation (Etherchannel) на физическом коммутаторе должен быть настроен, только если на виртуальном коммутаторе используется балансировка нагрузки по IP;

- Route based on physical NIC load - этот метод балансировки нагрузки доступен только для распределенных коммутаторов и только начиная с ESX(i) версии 4.1. Суть данного механизма напоминает работу первого варианта балансировки - по Port ID. Однако есть и значительные различия. Во-первых, при принятии решения, через какой pNIC выпускать очередную «сессию», выбор осуществляется в зависимости от нагрузки на этот pNIC, а не случайным образом. Во-вторых, выбор повторяется каждые 30 секунд (в то время как во всех прочих вариантах однажды осуществленный выбор не меняется до выключения ВМ).

Резюме: рекомендуемым в общем случае является Route based on the physical NIC load - по совокупности характеристик. Он дает балансировку нагрузки с минимальными накладными расходами (но использовать этот метод балансировки возможно только на распределенных коммутаторах, и только начиная с версии 4.1). В случае если вы твердо уверены, что вам необходима большая эффективность балансировки, используйте Route based on ip hash. Пример такой ситуации - одна ВМ, генерирующая большой объем трафика и работающая с большим количеством клиентов. Однако если нет возможности настроить etherchannel на физическом коммутаторе, то Route based on ip hash использовать невозможно.

Если не подходят и Route based on ip hash, и Route based on physical NIC load, используйте Route based on the originating port ID.

Более эффективную балансировку нагрузки рекомендуется ставить лишь для той группы портов, для которой она необходима, - с целью свести к минимуму накладные расходы в виде нагрузки на CPU сервера.

Для распределенных виртуальных коммутаторов все так же, с поправкой на абстрактность каналов во внешнюю сеть, для которых выполняется эта настройка.

четверг, 3 мая 2012 г.

Что лучше: Etherchannel и IP Hash или Load Based Teaming?

Споры что лучше - Etherchannel или LBT ведутся с тех пор, как последний механизм балансировки нагрузки появился в vSphere 4.1. Основная причина споров состоит в том, что администраторы или не знают о существовании LBT, или же думают, что сетевой стек у vSphere работает как и у физических серверов - один интерфейс активен, а все остальные простаивают до момент выхода активного из строя.

Варианты тиминга сетевых интерфейсов в vSphere

С самого начала хочу отметить, что vNetwork Distributed Switch (vDS) поддерживает пять разных режимов тиминга, но не поддерживает LACP (802.3ad) или же Dynamic Etherchannel, поддерживается только Static Etherchannel. Для использования LACP необходимо использовать Cisco Nexus 1000V или какой-либо другой сторонний vDS.

Route based on originating virtual port
Route based on IP Hash (единственный механизм, поддерживаемый с Static Etherchannel и Static 802.3ad)
Route based on Source MAC address
Route based on physical NIC load (Load Based Teaming или LBT)
Use explicit failover order (не является механизмом балансировки нагрузки. Обеспечивает только отказоустойчивость).

Etherchannel и IP Hash Load Balancing

IP Hash Load Balancing требует настроенного Static Etherchannel на свитчах, и использует хэш IP адрес источника и адресата для выбора интерфейса по которому будет отправлен трафик. В KB 1004048 описаны все поддерживаемые конфигурации и примеры настройки сетевого оборудования.

Конфигурации когда виртуальная машина сможет использовать все сетевые интерфейсы возможны, но довольно редки - ВМ должна отсылать большое количество трафика на разные адреса. Каждый поток будет привязан к одному интерфейсу, а выбор интерфейса не зависит от
его загруженности.

Все используемые свитчи должны поддерживать Static Etherchannel, и он должен быть настроен для всех используемых серверов.
Для обеспечения избыточности свитчей они должны поддерживать стэкирование или протокол аналогичный Virtual Port Channel.
Нельзя использовать beacon probing.
Нельзя настроить неиспользуемые или standby интерфейсы.
Поддерживается только один Etherchannel на vNetwork Distributed Switch (vDS).
Поддерживается от одного до восьми сетевых интерфейсов.
Для обеспечения максимальной эффективности необходимо использовать множество источников и получателей.

Если же необходимо использовать реальную балансировку нагрузки и отказоустойчивость то это не самый лучший метод.

Load Based Teaming

Load Based Teaming, или же Route based on Physical NIC Load, проверяет нагрузку сетевого интерфейса каждые 30 секунд, и если она превышает 75%, то порт виртуальной машины будет перемещён на другой интерфейс.

Данный механизм не требует какой-либо дополнительной настройки или поддержки сторонних протоколов. Пропускная способность ВМ будет ограничена скоростью физического интерфейса. Кроме того, LBT работает как для входящего, так и для исходящего трафика.

Данный механизм тиминга обладает следующими преимуществами:

Простота настройки и использования.
Лёгкость в локализации и решении проблем.
Динамическая утилизация ресурсов.
Поддержка исходящего и входящего трафика.
Небольшой overhead.
Уменьшает вероятность включения механизмов Network IO Control (NIOC).
Нету ограничений свойственных Etherchannel и IP Hash Load Balancing.

Так что же на счёт LACP?

Для использования LACP вам нужен развёрнутый Cisco Nexus 1000V, и физические свитчи поддерживающие Virtual Port Channels. Данный dVS поддерживает 19 алгоритмов хэширования.
Вместе с тем, LACP страдает от тех же недостатков что и EtherChannel, как-то необходимость дополнительной настройки оборудования.

Читайте также: