Ограничение пропускной способности (Traffic Shaping)

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

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

Зайдя  в окно настроек Traffic shaping (Configuration ? Network ? Properties

для нужного вКоммутатора ? Edit для самого вКоммутатора или одной группы

портов), мы увидим три настройки:

Q  Average Bandwidth – столько  килобит  в секунду в среднем может проходить через каждый порт этого коммутатора/группы портов. Фактически – средняя, обычная скорость сети;

Q  Peak Bandwidth – столько килобит в секунду может проходить через порт, если полоса пропускания занята не полностью. Фактически – максималь ная  скорость  сети. Это значение  всегда  должно  быть не меньше  Average Bandwidth;

Q  Burst Size – если ВМ пытается  передавать  данные со скоростью большей, чем average bandwidth, то превышающие это ограничение пакеты помещаются в специальный буфер, размер его как раз и задается этой настройкой. Когда буфер заполнится, то данные из него будут переданы  со скоростью Peak Bandwidth (если у коммутатора  есть свободная полоса пропускания).

Обратите  внимание:  эти  настройки применяются к каждому  виртуальному сетевому контроллеру (на самом деле – к порту вКоммутатора, куда те подключены). Таким образом, если ВМ имеет 2 виртуальных сетевых контроллера в одной группе портов, то для каждого из них эти настройки применяются независимо.

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

2.4.3. NIC Teaming. Группировка сетевых контроллеров

Если зайти  в настройки вКоммутатора или группы портов, то последней  закладкой  мы увидим  «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) будет определять, что физический  сетевой контроллер неработоспособен? Вариантов  два:

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

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

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

Q  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. В этом выпадающем меню вы можете выбрать, по какому алгоритму будет балансироваться трафик  виртуальных машин между каналами  во внешнюю сеть виртуального коммутатора,  к которому они подключены.

Вариант  настройки Use explicit failover order указывает  не использовать балансировку нагрузки.  Используется первый  vmnic  из  списка  Active – см. чуть выше описание  Failover Order. А прочие  три варианта  настройки – это как раз выбор того, по какому  принципу  будет балансироваться нагрузка.  Суть в чем – есть трафик,  и есть несколько каналов  наружу  (vmnic#). Надо трафик  поделить между каналами.  Три варианта  настройки отличаются  тем, каким образом будет делиться трафик:

Q  Route based on the originating port ID – балансировка по номеру порта.

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

Q  Route based on source MAC hash – балансировка по MAC-адресу источни-

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

Q  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;

Q  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  сервера.

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

2.4.4. Cisco Discovery Protocol, CDP

CDP  – протокол  от Cisco, позволяющий обнаруживать и получать информа цию о сетевых устройствах.  ESX(i) 4 поддерживает этот протокол.

Чтобы изменить  настройки CDP  для стандартных  вКоммутаторов,  вам понадобится командная  строка. Команда

esxcfg-vswitch -b  <vSwitch>

покажет текущую настройку CDP  для вКоммутатора <vSwitch>.

Команда

esxcfg-vswitch -B <mode>  <vSwitch>

поможет  изменить  значение  настройки CDP  для вКоммутатора <vSwitch>. Доступные значения  параметра <mode>:

Q  Down – CDP  не используется;

Q  Listen – ESX получает  и отображает  информацию о коммутаторах Cisco, к которым подключен. На коммутаторы  информация о вКоммутаторах не отправляется;

Q  Advertise – ESX отправляет информацию о вКоммутаторах наружу, но не принимает  и не отображает информацию о физических коммутаторах;

Q  Both – ESX и обнаруживает подключенные физические коммутаторы,  и отправляет на них информацию о коммутаторах виртуальных.

Когда CDP настроен в listen или both, нам доступна информация о коммутато рах Cisco. Для просмотра пройдите Configuration ? Networking ? иконка справа

от vSwitch (рис. 2.34).

Рис. 2.34. Просмотр информации от CDP

Разное

Для  распределенных коммутаторов эта настройка  выполняется из графического интерфейса.

Источник: Михеев М. О.  Администрирование VMware vSphere 4.1. – М.: ДМК Пресс, 2011. – 448 с.: ил.

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

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