vEra of the Virtual Revolution

В этой статье я постараюсь объяснить, режим связи MS NLB Cluster, как работает MS NLB Cluster, какие режимы связи рекомендовано выбирать в среде VMware ESX, и почему.

Для начала, введение:

MS NLB Cluster ( Network Load Balancing) имеет два типа связи, это Unicast и Multicast, рассмотрим их по отдельности, чтобы понят разницу.

Unicast:

В режиме Unicast, NLB переназначает MAC адрес сетевого адаптера, для которого он включен, на виртуальный MAC адрес. Тем самым Unicast приводит к “Switch Flooding”-у, когда все порты коммутатора получает трафик NLB, и даже те порты, в которые подсоединены не NLB сервера. Поскольку все сервера, которые являются членами NLB кластера, имеют, одинаковы IP и MAC адрес, коммуникация между серверами невозможна, чтобы избежать этой проблемы необходимо добавить добавочный сетевой интерфейс в виртуальную машину (это относится и к физическому миру)

Multicast:

В режиме multicast, NLB присваивает Layer-2 multicast адрес, (вместо переназначения) для сетевого адаптера на котором включен NLB. Тем самым коммуникация между серверами, которые являются членами NLB multicast возможна, так как здесь не меняется MAC адрес и IP адрес, а добавляется, и каждый сервер имеет, уникальны MAC и IP адрес, также MAC и IP адрес NLB кластера.Однако, в multicast режиме, сервера посылают ARP запросы к маршутизатору , которые содержат IP адрес Unicast-а ( то ест “родной” IP адрес сервера, а ни NLB IP) и MAC Multicast ( MAC добавлены NLB), за частую некоторые маршритизароты отвергают такие запросы и не обновляют ARP таблицы . В током случае надо прописать статическую ARP запись на маршутизаторе.

Из ходя из этих отличии, стоит заметит что Multicast менее проблематичен !, и является рекомендованным методом построения NLB кластеров, в среде VMware ESX. За исключением когда коммутатор не поддерживает multicast ( некоторые коммутаторы HP ), и в током случае конечно же можно использовать Unicast.

Теперь рассмотрим один из самых распространенных вариантов развертывания NLB.

Давайте разберемся в этой “картинке”.

Каждый сервер в NLB кластере, имеет одинаковый, виртуальны IP адрес, когда делается запрос на виртуальны IP адрес, драйвер сетевого интерфейса на каждом сервере, прерывает запрос и перенапровляет его на один из серверов в НЛБ кластере.

Теперь постараюсь описать в “картинках” , как конфигурируется каждый из методов (Multicast и Unicast)

Multicast (Recommended Method)

Как видно из картинки здесь все также как и в “физическом мире”, и никаких “телодвижении” не требуется со стороны VMware ESX

Unicast:

С Unicast, чуть-чуть по сложнее, придется кое-что сделать:

Добавить каждому серверу добавочную сетевую карту и присвоить фиксированный ИП адрес,

В итоге мы получим сервер с двумя сетевыми картами, на одном сетевом адаптере будет “жить” реальны IP адрес сервера (Microsoft называет Dedicate IP адрес) а на втором сетевом адаптере, будет “жить” виртуальны IP адрес (Microsoft называет Cluster IP адрес).

Теперь почему именно так, рекомендуется делать:

В такой конфигурации получается, что на каждом из сетевых адаптеров только будет “жить” один MAC адрес и один ИП адрес, и второй сетевой адаптер будет, служит для “меж-сервернои” коммуникации для членов кластера. Исходя из этого, можно выделит один + Unicast-а. Используя Unicast, ни надо беспокоится по поводу ARP записей и соответственно, нет необходимости делать статические ARP записи на маршрутизаторе

Теперь надо сделать некоторые изменения и на стороне ЕSХ-а :

В свойствах “Port Group” виртуального коммутатора где “живет” сетевой адаптер виртуальной машины, который служит для NLB кластера, установлены следующие параметры

Forged Transmits = Accept

Notify Switches = NO

И несмотря на это, есть нарекания на то что VMotion, для таких машин работает проблематично, по этому рекомендовано такие машина держать на одном сервере и выключит их из под контроля VMware DRS чтобы они никуда не переехали