Просмотров: 2937

Standard vSwitch - часть 4

Как vSwitch определяет неисправности путей, использование Cisco Discovery Protocol.

Итак, мы перенесли ответственность за отказоустойчивость из гостевой ОС в виртуальной машине и поставил ее ребром на vSwitch. Напрашивается вопрос – как vSwitch узнает, что произошел сбой, и что он сделает при этом?

ESX поддерживает два типа механизмов обнаружения сетевого сбоя, beaconing and link state detection. Давайте исследуем beaconing в первую очередь.

Beacon Probing

Beacon Probing, часто называют просто “beaconing”, что переводится "маяк". Маяк предназначен для использования в ситуациях, когда существует несколько pSwitches между различными pNICs в vSwitch. Маяк - это метод, который отправляет широковещательный (broadcast) Ethernet пакет 2-ого уровня из каждой pNIC в группе портов (Port Group) для каждой VLAN, присутствующей в vSwitch (это означает, что если ваш vSwitch участвует в 10 VLAN, Маяк будет передавать 10 широковещательных пакетов в pNIC), хотя у вас есть возможность переопределить настройки vSwitch по умолчанию на уровне групп портов (Port Group).

На рис.1 изображен один pNIC передающий beacon пакеты на широковещательный адрес (в нормальном режиме работы, каждый pNIC будет передавать beacon пакеты на каждую подключенную VLAN).

Этого пакета будут получать все другие pNICs в широковещательном домене. Интересно отметить, что это единственная ситуация, когда во время нормальной работы, вы увидите MAC-адрес pNIC в сети.

MAC-адрес beacon инициатора pNIC используется в качестве источника MAC-адрес.

vSwitch будет поглощать beacon кадры, полученные beacon приемниками – виртуальные машины никогда не увидят сигнальный (beacon) кадр.

рис.1. Beacon Probing

Если Маяк приемник пропускает три подряд Маяк пакетов, он будет помечен как “плохой” и поставьте в неактивное состояние.

Исходящий трафик vSwitch коммутатора будет автоматически маршрутизироваться через уцелевшие интерфейсы.

Существует два основных поведения, что vSwitch коммутатор будет делать при сбое beacon (from http://blogs.vmware.com/networking/2008/12/using-beaconing-to-detect-link-failures-or-beaconing-demystified.html):

Поведение esx в случае обнаружения отказа маяка выглядит следующим образом:

  1. Если два или более аплинков получите маяки друг от друга, эти аплинки считается хорошим. Аплинки, которые не получают Маяк пакеты будут остановлены в использовании.

  2. Если нет исходящей связи получает Маяк пакеты, трафик передается всем аплинкам  (shotgun mode). Если команда имеет двух аплинков, любой сбой ссылке в результате все пакеты, отправляемые с обоих аплинков.

Как вы видите, вы можете оказаться в ситуации, когда вы передаете все пакеты по каждому восходящему каналу. Это может вызвать крайнюю путаницу для вашего pSwitches, особенно если у вас несколько аплинки подключены к одному физическому коммутатору (pSwitch) (не рекомендуется при использовании маяка)!

There are other issues with Beacon Probing, too. For example http://kb.vmware.com/kb/1004373 reads as follows:

“When configuring networking for an ESX Server host using at least two vmnic as network adapters and VLAN Type 4095, duplicated packets can occur when Beacon Probing is selected in the Network Failover Detection dropdown menu.”

With the following recommended solution:

“Select the Link Status Only option in the Network Failover Detection dropdown menu instead of Beacon Probing.”

В принципе, Beacon Probing не должен использоваться в качестве альтернативы в надежной сети второго уровня. Вместо этого, используйте Link Status Only как механизм обнаружения сбоев в сети.

Link Status Only

Link Status Only обнаруживает ошибки  в зависимости  от pNIC по ссылке государственной функции по выявлению, когда возникла проблема с сетевой путь. На первый взгляд, можно подумать, что это не очень надежная схема обнаружения ошибок – он видит только состояние соединения между pNIC и подключенным pSwitch! Он также ничего не делает, чтобы убедиться, что порт pSwitch правильно настроен, и он не может видеть глубже в сеть. Пока все это правда, есть некоторые вещи, которые можно сделать, чтобы помочь облегчить эти проблемы.

First, use a pSwitch that has the “Link State Tracking” feature. This feature will mirror the link status of the upstream link (pSwitch to pSwitch) down to the downstream link (pSwitch to ESX pNIC). What this means is that if the first upstream pSwitch becomes isolated, the link status indicator for the pNIC will be set to “Down”, indicating to the vSwitch that the associated path is no longer viable.

рис.2. Link State Tracking

Figure 2 shows an example of how Link State Tracking works. When looking at the Downstream Link (from the first pSwitch’s perspective), everything looks good; however, the Upstream Link between the two pSwitches has failed. With Link State Tracking enabled on the pSwitch, will reflect the state of the Upstream link on the Downstream link, letting ESX know that the path is dead and that the alternate path should be used.

Which to Use?

So, you’ve got two options for managing network failure conditions, which should you use? I recommend the following:

  • When you initially configure your vSwitch, use Beacon Probing. This will allow you to test not only the link state, but also ensure that you can talk across all of your configured port groups. Once you’ve validated proper configuration, switch to Link Status Only

  • When you add a new port group to an existing vSwitch, set the error detection method for the port group to Beacon Probing to verify correct pSwitch configuration. Once you’ve validated proper configuration, switch to Link Status Only

  • Don’t use Beacon Probing if more than one pNIC in the vSwitch is connected to the same pSwitch. This could result in the same MAC address being presented on two or more ports on the pSwitch which is “a very bad thing”.

  • Use Link Status Only for network failure detection. If at all possible, use pSwitches that support Link State Tracking to reflect upstream network status back to the vSwitch.

  • Implement a robust Layer Two network. If possible, have your first level pSwitch multi-homed to eliminate single points of failure.

Cisco Discovery Protocol (CDP)

The Cisco Discovery Protocol (CDP) is used to obtain pSwitch port configuration from an ESX host. The information returned by CDP can be invaluable when you’re trying to verify or modify your network configuration. Examples of some of the information returned by CDP include:

  • Identification of the pSwitch to which a pNIC is connected

  • Identification of the pSwitch port to which the pNIC is connected

  • Speed & Duplex settings for the pSwitch port

  • VLAN number(s) associated with the pSwitch port

The CDP information is available either via the command line (use vmware-vim-cmd) or via vCenter Server (on the Configuration / Networking tab). For more detailed information on the use of CDP, check out the following VMware knowledgebase articles:

http://kb.vmware.com/kb/1007069

http://kb.vmware.com/kb/1003885

OK, this wraps it up for Part 4 of my series on vSwitches. In the next section (Part 5), I’ll start getting into some of my recommended configurations. That’s where the real fun begins – and hopefully we’ll get the “Debate” part of this thing spun up 

Ссылки:

Beaconing Demystified: Using Beaconing to Detect Link Failures

VMware Virtual Networking Concepts

Duplicated Packets Occur when Beacon Probing Is Selected Using vmnic and VLAN Type 4095

Cisco Discovery Protocol (CDP) network information via command line and VirtualCenter on an ESX host

Configuring the Cisco Discovery Protocol (CDP) with ESX Server

СОЦИАЛЬНЫЕ ГРУППЫ САЙТА

Яндекс.Метрика
Рейтинг@Mail.ru