Авторизация



Теги сайта



0х0000007b 1c access control list acl activation active directory ad roles add route adexplorer apache authentication to zabbix bare metal recovery bg zsh bicycle books bruteforce c admin ccna centos centos packet change net adapter name chap chkrootkit chmod cisco clipboard cmd configuring cpu cores cron crontab csc cut cvsup cvsup-without-gui db dev null 2 1 dhcp dhcp reservation disable ipv6 diskpart dism dns domain naming master domain roles download download powershell enable routing on windows enabled end-system doc english english language esx eventlog exe file associations fail2ban fastest_cvsup fedora fg zsh formatdatabase freebsd fsmo get-aduser group policy management hardware https hyper-v idioms iis iperf iptables iscsi jobs kernel panic ldap ldap аутентификация zabbix limit lingualeo linux malware posix mcitp mcsa mcse memory check microsoft mod_ssl mount mssql mysql mysql user password netcache network network config network diagram network document network load balance cluster network scripts nginx nlb num lock numlock openssl pap partition pdc permissions php pipeline pkg_version ports upgrade portupgrade posix powershell ppp pwdlastset rdp reg add regedit registry remote enable restrictions reverse proxy rhel rid rope jumping bridge мост прыжок высота route add route freebsd router switch doc routing protocol rpm sc sc sdset sc sdshow schema scope script output secure web security seize role service permissions services set dns servers set ip address sftp shell script show variables snmp sound scheme sounds speed ssh standard-supfile subinacl supfile switch switchport sync syncronization task sсheduler tempdb topology map transfer role tripplite monitoring tweaks unix user must change password at next logon utf8 vim vlan vmware w32tm web windows windows 2003 r2 windows 2008 r2 windows administrative share windows firewall windows server windows server 2012 windows server backup windows service permissions windows пингалка winre wsus xargs yum zabbix zabbix external check zabbix ldap authentication zsh автоматическое обновление портов freebsd автономные файлы активация английский язык ассоциации файлов windows база данных безопасность active directory буфер вело велосипед видео включение роутинга в windows внешняя проверка zabbix вредоносное программное обеспечение posix документация сети задание двумерного массива захват ролей dc звуки звуковая схема идиомы иероглифы киев кодировка командная строка конфигурация сети маршрутизация маршруты в freebsd маршруты в redhat linux область ограничения windows основные команды отключение административных ресурсов пакеты centos перевод передача ролей dc перенос планировщик задач покатушки полет над днепром проблемы кодировки протокол путь развития в it разрешения служб windows регистрируем cmd скриптом недоступность хоста реестр резервирование ip скриптом роли домена русские символы синхронизация скачать скачать powershell скачать книгу скорость сети списки контроля доступа тарзанка твики фоновые процессы цикл mssql

Главная страница MICROSOFT NLB кластер в среде VMWare ESX
NLB кластер в среде VMWare ESX Печать

Поднятие Network Load Balancing кластера на базе Microsoft Windows Server 2012 внутри гипервизора VMWare ESX 5.0.

Кто хоть раз пытался поднять NLB внутри ESX наверняка сталкивался с рядом проблем и в итоге либо долго и мучительно копался решая их, либо вовсе отказывался от такой затеи. В этой статье я покажу что необходимо для работы представленной технологии внутри VMWare.

 

Подготовка среды VMWare ESX для работы технологии MS NLB

В этом пункте описаны действия, которые нужно выполнить с помощью VMWare VSphere. Без них кластер NLB работать не будет, в частности, после поднятия сервиса виртуальная машина просто перестанет быть доступной по сети. Связано это с тем, что NLB генерирует хитрый трафик, который блокирует среда ESX.

1. Переходим в VSphere в панель управления виртуальными свитчами: View -> Inventory -> Networking

2. Выбираем Port-group в которой будут находиться наши виртуалки и клацаем Edit Settings.

3. Изменяем три параметра: MAC Address Changes = Accept; Forged Transmits = Accept; Notify Switches = No.

nlb-security

 

nlb_teaming-and-failover

Поднимаем кластер NLB внутри виртуальных машин VMWare ESX

Для этого нам понадобятся две виртуалки с развернутыми в них Windows Server 2012. Каждая виртуальная машина должна иметь по два сетевых адаптера в одном или разных VLAN-ах. Второй NIC нужен для того, чтобы была возможность подконнектиться к конкретной ноде, после того как кластер будет собран (нужен отличный от кластерного MAC адрес).

 

Сетевая конфигурация узлов до настройки (два адаптера в одной подсети)

nlb-ip-1

 

nlb-ip-2

 

1. Инсталлируем фичу NLB с помощью PowerShell

PS C:\> Import-Module ServerManager
PS C:\> 
PS C:\> Install-WindowsFeature NLB, RSAT-NLB # Инсталлируем сервис балансера и средства графического управления им

Success		Restart Needed	Eхit Code	Feature Result
-------		--------------	---------	--------------
True		No				Success		{Network Load Balancing, Remote Server Adm...

 

2. На узле 1 приступаем к конфигурированию кластера NLB

В главном меню оснастки Network Load Balancing Manager выбираем Cluster -> New

 

В поле Host вводим IP текущей ноды и нажимаем Connect

Далее в отобразившемся списке доступных интерфейсов выбираем тот, через который будет работать NLB

nlb-conf-01

 

Если Вы заранее назначили интерфейсу NLB IP-адрес и остальные параметры, то на этом этапе просто жмем Next

nlb-conf-02

 

Задаем виртуальный IP-адрес нашего кластера (ну или несколько IP-адресов)

nlb-conf-03

 

Указываем параметры кластера. FQDN кластера также нужно прописать в DNS. Multicast прячет два MAC-адреса в одном, однако не все сетевое оборудование сможет работать в такой конфигурации (в частности известны проблемы с Cisco и у меня как раз такая ситуация, так что настраиваем Unicast)

nlb-conf-04

 

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

nlb-conf-05

 

После нажатия на Finish нужно какое-то время подождать. В итоге должен подняться и быть доступным по сети одноузловой кластер NLB. Выделенный (Dedicated) и виртуальный (Cluster) IP-адреса будут иметь единый виртуальный MAC.

nlb-cluster-ip

3. Приступаем к добавлению второго узла в кластер

Предварительно на втором узле нужно установить фичу NLB точно также, как это делалось для первой ноды (см. пункт 1). Дополнительно настраивать на втором узле NLB не нужно

nlb-conf-06

 

Указываем IP второй ноды и затем выбираем интерфейс для NLB

nlb-conf-07

 

Если интерфейс для NLB на второй ноде был предварительно настроен то можно смело жать Next

nlb-conf-08

 

Можно определить какие протоколы и порты будут затронуты кластеризацией на узле 2

nlb-conf-09

 

После завершения получаем такую картину

nlb-conf-10

 

Смотрим IP конфигурацию второй ноды после добавление в кластер

nlb-cluster-ip-node2

Как видим, виртуальный MAC-адрес NLB-интерфейса второй ноды идентичен с виртуальным MAC-адресом NLB-интерфейса первой ноды (это значит что все сетевые пакеты, адресованные NLB-кластеру, примут абсолютно все узлы. А уж потом между собой разберутся какой конкретно узел обработает клиентский запрос).

 

4. Добавляем записи в DNS

Я добавил имена каждой из нод в DNS, связав их с соответствующим IP-адресом второго (не NLB интерфейса)


Комментарии:

 

КОММЕНТАРИИ 

 
#9 Dev_LC 23.09.2013 09:07
Цитирую Victor:
Мигрировал нод2 на хост к ноду1. Все заработало. Но, если вдруг погаснет хост1, и машины переедут на два разных? У меня их три (хоста)?


Этими действиями вы выяснили, что проблема у вас не в настройке NLB, а в сетевом оборудовании, которое связывает ноды VMWare. Разбирайтесь.
Почитайте мой комментарий ниже (#4 Dev_LC 02.07.2013 10:49). Там я подробно описал как NLB успешно работает на практике.

Цитирую Victor:
И ещё вопрос, можно создать кластер NLB на третьей машине, а два которые должны разбирать на себя нагрузку подключить подключить на неё? Или это противоречит принципу NLB кластера?


Не понял задачу.
Цитировать
 
 
#8 Victor 23.09.2013 09:00
Цитирую Dev_LC:
Цитирую Victor:
Сделал все по инструкции, но НОДы друг друга не пингуют ((( Подскажите пожалуйста,где собака порылась?


Проверьте, NLB ноды должны быть в одной подсети. Посмотрите, после добавления NLB фичи, обе ноды должны иметь один и тот же MAC адрес на сетевухе, которую вы указывали. Перенесите обе NLB ноды на одну ноду VMWare; выключите NLB ноды, включите их снова и после этого попробуйте коннект. Физическое соединение должно быть простое (без Team). Виртуальный свитч для нод NLB лучше иметь отдельный.


Мигрировал нод2 на хост к ноду1. Все заработало. Но, если вдруг погаснет хост1, и машины переедут на два разных? У меня их три (хоста)?
И ещё вопрос, можно создать кластер NLB на третьей машине, а два которые должны разбирать на себя нагрузку подключить подключить на неё? Или это противоречит принципу NLB кластера?
Цитировать
 
 
#7 Dev_LC 23.09.2013 08:40
Цитирую Victor:
Сделал все по инструкции, но НОДы друг друга не пингуют ((( Подскажите пожалуйста,где собака порылась?


Проверьте, NLB ноды должны быть в одной подсети. Посмотрите, после добавления NLB фичи, обе ноды должны иметь один и тот же MAC адрес на сетевухе, которую вы указывали. Перенесите обе NLB ноды на одну ноду VMWare; выключите NLB ноды, включите их снова и после этого попробуйте коннект. Физическое соединение должно быть простое (без Team). Виртуальный свитч для нод NLB лучше иметь отдельный.
Цитировать
 
 
#6 Victor 23.09.2013 07:38
Сделал все по инструкции, но НОДы друг друга не пингуют ((( Подскажите пожалуйста,где собака порылась?
Цитировать
 
 
+1 #5 Владислав 02.07.2013 12:54
Спасибо большое, будем пробовать=)

Вот Вам мои лайки)
Цитировать
 
 
#4 Dev_LC 02.07.2013 10:49
Теория теорией, но я решил также закрепить её практикой.
Вот что из этого вышло:

1) Есть две Unicast ноды NLB на Server 2008 R2, внутри двух разных хостов кластера Hyper-V. Каждая нода HV подключена к соседним портам одного access свитча, который в свою очередь скоммутирован в core L3 свитч.
Результат: все работает нормально, при LiveMigration одной из нод NLB на тот же хост HV, на котором крутится вторая нода NLB, проблем не возникает.

2) Есть кластер ESX со множеством хостов, подключенным к совершенно другим access свитчам. Поднял внутри одного из них третью ноду NLB на Server 2012, подключенную к соответствующем у VLAN'у.
Результат: Все завелось с пол пинка. Миграция третьей ноды NLB между хостами кластера ESX проходит без потери пинга на третью ноду NLB.
Цитировать
 
 
#3 Dev_LC 02.07.2013 08:08
Цитирую Владислав:
Т.е. юникаст все-таки можно поднять на виртуалках, расположенных на разных хостах (с единственным условием - vlan должен присутствовать на коммутаторах (у нас как раз так и есть))?

Прошу прощения, что переспрашиваю - просто везде пишут, что нельзя юникаст на разных хостах, но не пишут почему=).


На заборах много чего бывает :lol:
  • Можно
  • Работать будет
  • Проверено
Цитировать
 
 
#2 Владислав 02.07.2013 07:30
Т.е. юникаст все-таки можно поднять на виртуалках, расположенных на разных хостах (с единственным условием - vlan должен присутствовать на коммутаторах (у нас как раз так и есть))?

Прошу прощения, что переспрашиваю - просто везде пишут, что нельзя юникаст на разных хостах, но не пишут почему=).
Цитировать
 
 
#1 Dev_LC 02.07.2013 07:10
Цитирую Владислав Дадимов:
Добрый день,

В описанной схема узлы находятся на одном хосте или это не важно?


Добрый!

Узлы могут находиться как на одном хосте, так и на разных. Главное чтобы vLAN был размазанан по свитчам, к которым подключены хосты VMWare, ну и настроен в самой среде.

Точно также будет работать NLB и внутри Microsoft Hyper-V (из особенностей: в свойствах виртуалки нужно поставить галочку "Enable MAC address spoofing").
Цитировать
 

Добавить комментарий

Чтобы иметь дополнительные опции редактирования, возможность оценивать чужие комментарии и не вводить код Captcha с картинки перед отправкой сообщения, войдите под своим аккаунтом или зарегистрируйтесь.

Защитный код
Обновить

Главная страница MICROSOFT NLB кластер в среде VMWare ESX