У MS Windows NLB есть несколько режимов работы – это Unicast и Multicast (KB — Microsoft Network Load Balancing Multicast and Unicast operation modes).

Multicast mode

При работе NLB в Multicast не нужно делать каких либо специфических настройках на хостах, но зато придётся конфигурировать гостевые ВМ и физические свитчи. Подробнее в этих KB — Sample Configuration — Network Load Balancing (NLB) Multicast Mode Configuration и Sample Configuration — Network Load Balancing (NLB) Multicast mode over routed subnet — Cisco Switch Static ARP Configuration.

Скажу что этот режим работы, не считая настроек менее капризен и не имеет недостатков Unicast режима.

Unicast Mode

При работе NLB  в Unicast наоборот не нужно делать какие либо специфичные настройки на физических свитчах. Но зато нужно сделать кое, какие настройки на хосте. Этот режим легче всего сконфигурировать, поэтому чаще его и применяют многие на практике.

Чтобы NLB в Unicast режиме функционировала, на vSwitch в котором есть ВМ входящие в кластер NLB необходимо сделать следующее – зайти в свойства vSwitch и на вкладке Security необходимо параметр Forged Transmits установить в Accept на вкладке NIC Teaming параметр Notify Switches установить в NO.

Подробнее в этих KB — Sample Configuration — Network Load Balancing (NLB) UNICAST Mode Configuration.

Из за специфики работы Unicast режима, он зафлуживает свитчи. Что не всегда есть хорошо. И накладывает свои ограничения.

При функционирование кластера Windows NLB в Unicast режиме есть условия:

• Все ВМ входящие в кластер NLB должны быть на одном хосте.
• На каждом сервере входящем в кластер NLB должен быть дополнительный виртуальный сетевой интерфейс для коммуникаций, так как все сервера кластера имеют одинаковые IP и MAC адрес и соответственно коммуникация между ними не возможна.
• Не мигрировать ВМ, для таких ВМ отлючить DRS. VMotion обычно проблематичен и/или не возможен.

Я например в своей практике встречался с несколькими ситуациями когда при Unicast режиме ВМ входящие в кластер разносились по разным хостам и в результате флудинга на физическом свитчахсрабатывал Spanning Tree и просто отключались порты.

И еще на последок скажу что сама Microsoft не рекомендует использовать Windows NLB в средних и крупных инфраструктурах и в место этой службы использовать железные NLB решения и тут я с MS согласен, так как Windows NLB подходит для тестов и мелких инфраструктур.

Jumbo Frames – это сетевые кадры размером 9000+ байтов. Обычные кадры, использующиеся в сети имеют размером 1500 байт.  Jumbo Frames работает в сетях 1Гбит и выше. Для чего же нужны большие кадры? Собственно для того чтобы увеличить быстродействие сети при передачи большого числа данных и снизить накладные расходы. Рекомендуется включать Jumbo Frames в сетях, где наблюдается интенсивная пересылка больших объемов данных, например трафик iSCSI. Подробнее тут.

ESX/ESXi 4 имеет поддержку Jumbo Frames и ниже я расскажу как ее включить на примере хоста с ESX 4.

По умолчанию у нас есть коммутатор, который поддерживает Jumbo Frames и на нем уже включена поддержка больших кадров для нужных портов. Также есть хост, на котором уже есть отдельный vSwitch и два порта VMkernel использующийся для трафика iSCSI. Вот как раз на нем я включу поддержку Jumbo Frames.

Все операции по включению Jumbo Frames производятся из консоли. Включать поддержку Jumbo Frames я буду на vSwitch2.

Первым делом идем в консоль и смотрим командой esxcfg-vswitch –l какие у нас есть виртуальные свитчи и какой MTU выставлен. По умолчанию MTU = 1500.

Далее выполняю команду esxcfg-vswitch -m 9000 vSwitch2, тем самым включая поддержку больших кадров на виртуальном свитче vSwitch2.

Теперь остается включить Jumbo Frames для портов VMkernel, которым это необходимо. В моем примере они созданы, так что их придется пересоздавать.

В начале выполняем команду esxcfg-vmknic –d <port_group_name>, этой командой мы удалим VMkernel NIC в порт группе, в моем примере esxcfg-vmknic –d iSCSI1.

Затем выполняем команду esxcfg-vmknic -a -i <IP> -n <network_mask> -m 9000 <port_group_name>, этим действием мы заново создадим порт VMkernel с нужным IP, маской и размером кадра в 9000 байт, в моем примере esxcfg-vmknic –a –i 192.168.10.5 255.255.255.0 –m 9000 iSCSI1.

Тоже самое я проделаю и со вторым портом VMkernel.

esxcfg-vmknic –d iSCSI2

esxcfg-vmknic –a –i 192.168.10.6 255.255.255.0 –m 9000 iSCSI2

Теперь можно посмотреть, что получилось командой esxcfg-vmknic –l.

Все с конфигурацией.

Касетельно ESXi.

Тут есть несколько способов. Через unsupported mode или vSphere CLI или vMA.

Как сконфигурировать хост и сетевую инфраструктуру расскажу на примере одной реальной задачи. И так нужно сделать для ВМ и VMotion быструю сеть, а также обеспечить отказоустойчивость на случай выхода из строя одного канала, причем в наличие есть только две выделенные физические сетевые и один физический коммутатор с поддержкой IEEE 802.3ad.  Плюс ко всему разделить порт группы ВМ по своим VLAN. Особо тут не разгуляешься, и отказоустойчивость можно получить на случай выхода из строя одной из  сетевых плат или патча. В данной конфигурации существует единая точка отказа, это физический свитч. Деваться некуда, так как задача стоит и ее нужно решить. Собственно решение созрело сразу это LA.

Что для этого нужно, это собственно любой физический свитч, поддерживающий LA (IEEE 802.3ad) и VLAN. В ESX/ESXi уже включена поддержка LA, НО с некоторыми оговорками, работает только в режиме 802.3ad static. Почитать подробнее можно в этом KB.

Конфигурация вообще не сложная и поэтому ее подробно описывать не буду, только коснусь важных моментов.

И так у нас есть хост, 2 физические сетевые, свитч HP 2824 и 2 свободных порта на нем и несколько VLAN.

Конфигурация состоит из 2-х этапов.

1)      Конфигурация самого хоста.

2)      Конфигурация физического свитча.

Схема физического подключения.

1. Конфигурация Networking

Первое это нужно создать отдельный vSwitch, на котором будет использоваться LA или использовать существующий и привязать к нему наши две физические сетевые для аплинка. Далее идем в свойства vSwitch вкладка Ports -> vSwitch и на вкладке NIC Teaming необходимо убедиться, что обе сетевые активные.  В поле Load Balancing указываем Route based on ip hash.

Еще одно важное замечание. В поле Network Failover Detection должен быть выбран Link Status only, с beaconing probe работать не будет.

2. Конфигурация физ. свитча.

И так сама конфигурация на примере HP ProCurve 2824. Тут все просто. Заходим в консоль, далее в config и выполняем следующие trunk <port_list> < trk1 … trk60 > trunk

В моем примере патчи от физ. сетевых хоста висят на портах 11 и 12, и я ввожу trunk 11-12 trk1 trunk. После можете посмотреть, что получилось командой show trunk.

Ну осталось еще одно. Нашу группу trk1 пометить как tagged и прокинуть во все vlan. Это легко делается из веб интерфейса управления свитча или же из той же консоли.

Вот и все с конфигурацией.

А да кстати если кто незнает как настроить на работу с VLAN ESX/ESXi, то вот эта статья Вам в помощь.

Немного об iSCSI.
Про iSCSI можно почитать, например, тут или тут.
А теперь главное. Что меня самого поначалу путало, так это терминология. Особено понятия клиетской и серверной части.  Иногда  и сейчас путаю их в состояние своей большой загрузки 
iSCSI target (цель) — это контролер или приложение предоставляющее доступ к общему хранилищу данных. Попросту это может быть физическая железка или же ее программный вариант. Это и есть серверная часть.
iSCSI initiator (инициатор) — клиентская часть, осуществляющая клиентский доступ к хранилищу данных по iSCSI. Так же может быть реализовано и аппаратно и программно.

В VMware ESX/ESXi 4 Server уже есть программный инициатор iSCSI и основная его настройка не очень сложна. Далее опишу процесс активации и конфигурации инициатора iSCSI и добавления LUN в datastore в VMware ESX/ESXi 4 Server.

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

И еще небольшое отступление. Для активации инициатора iSCSI у вас должен быть сконфигурирован VMKernel, т.е  порт группа должна быть добавлена к vSwitch. Если не сконфигурирован VMKernel, то придется его конфигить. Как добавить порт группу для VMkernel можно прочитать тут.

Поехали.

Активация  iSCSI инициатора в VMware ESX/ESXi 4 и добавление цели.

Открываем VMware vSphere клиент и конектимся к нужному хосту. Идем в  Configuration — > Storage Adapters. Далее в Storage Adapters находим iSCSI Software Adapter.

Лезем  в Properties. И видим следующее. Пока инициатор iSCSI не задействован. Жмем Configure.

И просто ставим галку Enabled.

После получится примерно следующее

Теперь инициатор iSCSI в ESX активирован. Далее надо настроить таргет. Поэтому идем на вкладку Dynamic Discovery.

Нажимаем Add и забиваем IP и порт iSCSI цели. После получается примерно следующее.

Далее просто закрываем все и нас попросят сделать рескан адаптеров, с чем и соглашаемся.

Вуаля, все.  После появится описание добавленого iSCSI таргета.

Вот и все с активацией инициатора iSCSI и добавлением тагрета.

Теперь осталось добавить iSCSI LUN в datastores.

Добавление iSCSI LUN в в datastores.

Идем Configuration -> Storage и жмем Add Storage.

Выбираем Disk/LUN.

Выбираем из списка нужный сторадж.

Тут отображается инфа о подключаемом сторадже.

Забиваем имя нового datastore.

Выбираем размер блока, от него зависит какой максимальный размер файла будет на сторадже. Также тут можно выбрать и размер раздела.

В конце мастер выдаст суммарную информацию о создаваемом datastore. Все жмем Finish и ждем когда создастся новый datastore.

Теперь в списке datastores появился новый datastore.

Вот и все по инициатору iSCSI и добавление iSCSI LUN в  datastores.

Немного о VMkernel.
VMkernel – это ядро VMware ESX/ESXi Server. Оно занимает слой виртуализации и управляет большинством физических ресурсов: процессорами, памятью, системами хранения данных, сетевыми контролерами и п.р. Кто то может заметить, что в VMware ESX Server есть Red Hat Enterprise Linux, так и есть, но роль линукса сводится только к тому, чтобы загружить машину и само ядро VMkernel, вот оно то и управляет всем. Сам линукс в ESX Server служит только для предоставления командной консоли, а также для установки агентов мониторинга железа и бекапа. Кстати в VMware ESXi Server тоже есть линукс, но он просто очень и очень сильно обрезан.

Сетевые сервисы использующие стек TCP/IP такие как VMotion, iSCSI, NFS также работают через VMkernel, поэтому для включения их необходимо правильно сконфигурировать VMkernel. Стек TCP/IP в VMkernel полностью отделен от стека TCP/IP используемого в Service Console . Стек TCP\IP VMkernel создается как порт группа VMkernel и подключается к одному или нескольких vSwitch, которые в свою очередь подключены к различным сетям.

Конфигурирование сетевых сервисов VMkernel.
Как я уже выше писал, для работы VMotion, инициатора iSCSI и NFS необходимо сконфигурировать стек TCP\IP VMkernel. Конфигурация довольна, проста и заключается в добавление порт группы VMkernel к vSwitch на через который должен течь трафик сетевых сервисов iSCSI, NFS, VMotion. Все хватит теории, я больше люблю практику.

Go — go — go!

Открываем клиент vSphere и идем в раздел Configuration->Networking. В данном примере у меня на хосте 2-ве физические сетевые карты. Первая карта подключена vSwitch0, к которому подключены ВМ. Вторая карта подключена на vSwitch1, вот как раз на нем я и собираюсь создать порт VMkernel и гонять трафик.

Жмем Properties на нужном нам vSwitch и в  появившемся окне жмем Add.

Потом выбираем VMkernel.

И просто забиваем нужные параметры.  Думаю тут все понятно, имя порта и vlan id если необходим.

Далее сконфигурируем IP адрес, маску, и шлюз для VMkernel порта.

Жмем Next. Смотрим суммарную инфу и жмем Finish. После завершения мастера создастся порт VMkernel со своим сетевым интерфейсом.

Остается только проверить доступен ли только что созданный сетевой интерфейс VMkernel. Просто пингуем с машины которая находится в одной сети с портом VMkernel его интерфейс или же можно с консоли ESX пингануть какую либо машину в сети. Для пинга через интерфейс VMkernel используется команда vmkping.

Вот и вся конфигурация. Далее теперь можно сконфигурировать VMotion, iSCSI и NFS. Но это уже выходит за рамки этой публикации.

О конфигурации VMotion можно прочесть тут.

О конфигурации iSCSI тут.

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

Первоначально вроде бы все было хорошо, а ну потом меня задача немного загнала в ступор. Пришлось вспоминать, как работаю сети и vlan. Как раз получилась, так что мне была разминка, чтобы не забывать старое.

Решил написать свое решение, для меня всегда было удобно читать теорию и сразу видеть практическое применение или решение задачи. Думаю, поможет многим кто столкнется с подобным вопросом.

И от себя немного теории, и конечно потом само тех.задание и решение вопроса.

VMware ESX Server 3.5 входящий в Virtual Infrastructure 3 и конечно VMware ESX Server 4 входящий в VMware vSphere 4 (тут еще больше возможностей по виртуальным сетям) позволяют быстро и удобно создавать виртуальные сети различной сложности.

Виртуальная сетевая инфраструктура состоит из виртуальных свитчей (vSwitch), самих виртуальных сетей vlan, виртуальных сетевых картах на виртуальных машинах и физических сетевых картах vmnic на хостах.

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

Vlan он и в Африке vlan. По данному вопросу можно почитать тут или просто погуглить, по данной теме информации много.

Vlan в виртуальной инфраструктуре VMware по основным принципам работы практически ничем не отличается от классического vlan в обычной физической сетевой инфраструктуре.

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

Все хватит теории. Я люблю практику и конкретные задачи и их решение.

И так само тех. задание. Есть хост на ESX 3.5 U4 с 8-ю виртуальными серверами(скажем Server1-Server8). На сервере два физических сетевых адаптера. Оба подсоединены к свитчу HP ProCurve J4903A Switch 2824. На нем 3 vlan’а.

1. Локальная сеть 1 (vlan ID 1).
2. Локальная сеть 2 (vlan ID 2).
3. Интернет (vlan ID 3).

Необходимо через один физический сетевой адаптер связать и разнести виртуальные сервера по своим vlan’нам. Server 1 – Server4 привязать к первому vlan. Server5, Server6 ко второму vlan и Server7-Server8 к третьему vlan.

Вот тут я и застопорился минут на 30. Самое первое и простое решение, которое мне пришло в голову это конечно сделать 3 виртуальных свитча и каждый привязать к физической сетевой карте (их еще надо было купить и подключить к хосту ну и конечно чтобы их опознал ESX) и ее в свою очередь подключить к нужным портам физического свитча, к которые привязаны к своим vlan’ам. Слишком просто с одной стороны, но немножко не то (не хотелось возиться с сетевыми картами, проводами, драйверами и т.п. ), да и задача была все связать через одну физическую сетевую карту.

Все делается проще. За что я и люблю продукты VMware. Ни каких лишних сетевых карт, проводов и т.п.

Первое что нужно сделать, это залезть в физический коммутатор и настроить порт, который будет подключен к физической карте ESX сервера(vmnic0). В моем примере коммутатор HP ProCurve J4903A Switch 2824. На нем включаем для нужного нам порта режим tagged (в других устройствах может быть по другому, например в Cisco если мне не изменяет память это trunk) и добавляем этот порт ко всем 3-м vlan’ам на свитче. В данном режиме этот порт будет помечать пакеты (тегировать) идущие из vlan’ов с обычных портов для последующей передачи на наш виртуальный свитч.

Затем в ESX на виртуальном свитче (vSwitch0) создаем три группы портов VMNetwork1, VMNetwork2, VMNetwork3. Каждая группа портов привязана к своим vlan: vlan id 1, vlan id 2, vlan id 3 соответствующих нашим vlan на физическом коммутаторе. Дальше виртуальный свитч vSwitch0 подключаем к физической карте vmnic0, которая подключена к физическому порту коммутатора работающему в режиме tagged.

Все настройка закончена. Теперь наши виртуальные сети разделены и связаны только с нужными сетями. Т.е VMNetwork1 с Локальная сеть 1 (vlan ID 1), VMNetwork2 с Локальная сеть 2 (vlan ID) и VMNetwork3 с Интернет (vlan ID 3).

Вот так просто и легко, и самое главное ничего лишнего, ни проводов лишних, ни сетевых карт дополнительных, ни возни с установкой и дровами от сетевых карт. А самое главное время, затраченное на конфигурацию, не считая моего 30 минутного ступора и обдумывание проблемы, на конфигурирование я затратил добрых 15 минут. Вот Вам и выгода от виртуализации.