У 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 подходит для тестов и мелких инфраструктур.

1. Виртуальное железо должно быть не ниже версии 7.
2. USB Arbitrator
3. USB controller
4. USB устройство или хаб

Все основные моменты по поддержки USB можно прочитать в этом KB или в доке Virtual Machine Administration Guide.

Поддерживаются устройства как USB 2.0 так и USB 1.1. Список  официально поддерживаемых устройств.

Я для тестов брал несколько флешек разных производителей и все они поддерживались и прекрасно работали. К сожалению, под рукой не было алладиновского ключа чтобы и этот вариант опробовать, но думаю работать будет без проблем, если заявлено официально. А вот USB DVD-RW от ASUS так и не заработал, его хосты видеть отказались.

Какие существуют ограничения для проброса USB

Контроллер USB

• 1 ВМ может иметь 1 виртуальный контроллер USB
• USB Arbitrator может работать только с 15 физическими контроллерами USB
• Перед тем как добавить в ВМ USB устройство, нужно в эту же ВМ добавить виртуальный USB контроллер
• Перед тем как удалить виртуальный USB контроллер из ВМ, необходимо удалить все USB устройства

USB устройства

• 1-ой ВМ можно давать несколько устройств USB, максимум 20
• Устройство USB  доступно только 1-ой ВМ к которой оно подключено
• Официально не поддерживаемые устройства (линк на список поддерживаемых девайсов), могут некорректно работать с каким либо функционалом (к примеру с VMotion)
• Перед тем как сделать HotAdd  виртуального железа на ВМ, необходимо отключить все USB устройства, так как при горячем добавление автоматически отключаются от ВМ все USB устройства.
• Если ВМ была suspend, а затем снова продолжала работу, то USB устройства ведут себя, так как будто их отключили и снова включили.

Для устройств USB поддерживается VMotion и DRS. Это наверное самое вкусное. Так как можно спокойно мигрировать машины с хоста на хост и иметь подключенный USB девайс. Кстати DPM не поддерживается, так что на хостах где есть USB девайсы нужно отключить DPM.

Подключение

Тут все просто. Cкажем, берем флешку, вставляем в USB порт хоста, далее идем в консоль vSphere.

Идем в свойства ВМ которой нужно добавить USB устройство.

Так как виртуального USB контроллера нет на ВМ, с начала добавлем его.

Затем уже добавляем USB устройство.

Выбираем из списка нужное устройство. Если необходимо чтобы устройство поддерживало VMotion, ставим галку Support vMotion while device is connected.

Жмем ОК и идем в ВМ смотреть что получилось.

Опа, вот и она, моя флешка уже в ВМ.

Далее я пробовал мигрировать (VMotion) данную ВМ с прокинутой флешкой на разные хосты. Флешка была доступна!

Кстати если открыть свойства ВМ, а затем посмотреть свойства USB устройства то в поле USB Unique ID как раз будет указан хост и путь где подключен девайс.

Итог таков что в версии vSphere 4.1 прокидывание USB есть и оно работает замечательно как с VMotion так и без него. Огорчает правдо не такой внушительный список поддержки USB устройств, но я думаю, в будущем он расширится.

Решил начать с iSCSI Hardware Offloads.

Из релиза известно что

vSphere 4.1 enables 10Gb iSCSI hardware offloads (Broadcom 57711) and 1Gb iSCSI hardware offloads (Broadcom 5709).

Что это и с чем его едят? Собственно теперь сетевые карточки с функцией iSCSI Offload  или Accelerated iSCSI в терминологии HP и некоторых других производителей будут в ESX/ESXi работать как iSCSI HBA и в документации VMware дается обозначение таким адаптерам как Dependent Hardware iSCSI Adapters.

Более точное определение из доков VMware что такое Dependent Hardware iSCSI Adapters (зависимый железный iSCSI адаптер)

A dependent hardware iSCSI adapter is a third-party adapter that depends on VMware networking, and iSCSI configuration and management interfaces provided by VMware.

This type of adapter can be a card, such as a Broadcom 5709 NIC, that presents a standard network adapter and iSCSI offload functionality for the same port. The iSCSI offload functionality appears on the list of storage adapters as an iSCSI adapter. Although the iSCSI adapter is enabled by default, to make it functional, you must set up networking for the iSCSI traffic and bind the adapter and an appropriate VMkernel iSCSI port.

Ура, возрадуйтесь коллеги у кого есть сетевухи построенные на выше перечисленных чипах, раньше данный функционал был доступен только в ОС семейства Windows, RHEL и еще некоторых *nix систем для которых нужно было инсталлировать  драйвер, в ESX/ESXi данной поддержки не было.

Пока официально поддерживаются только два чипа это Broadcom 57711 и Broadcom 5709, не очень много, но все же, хотя думаю, в будущем список расширится.

Супер, пробежала мысль в голове, но мне пока не судьба сейчас попробовать заявленный  iSCSI Hardware Offloads, так как у меня нет хостов с данными чипами, но есть хост с парой сетевых карточек HP NC373T построенных на Broadcom 5708. Чипы 5708 и 5709 почти что похожи, но с некоторыми функциональными отличиями, хотя драйвер используют один и тот же и оба поддерживают iSCSI Offload. Каково мое было удивление, когда после обновления до ESXi 4.1 в разделе Storage adapter я увидел два iSCSI HBA которые как раз и были моими картами на 5708 чипе.

Так как Dependent Hardware iSCSI Adapters не чисто отдельная железная HBA, а сетевуха с функцией iSCSI Offload  то ее необходимо правильно настроить. ESX/ESXi 4.1 видят такую сетевую как два устройства: физ. сетевую карту и физическую iSCSI HBA. В моем примере vmnic2 она же vmhba32 и vmnic3 она же vmhba33.

Для полноты картины приведу рисунок общей конфигурации из доков VMware.

На рисунке в левой части показано подключение через софтверный iSCSI инициатор через две сетевые карты с 2-мя портами VMkernel, а справа через две сетевые карты которые поддерживают iSCSI Offload.

Конфигурация очень похожа чем то на конфигурацию софтверного iSCSI инициатора в ESX/ESXi с небольшими нюансами.  Для информации моя статья о конфигурации  софтверного iSCSI инициатора, а также статья о настройки multipathing и RR для софтверного iSCSI инициатора.

Едем дальше.

Первым делом что нужно сделать это создать порты VMKernel для трафика iSCSI и сделать активными только те сетевые карты, которые соответствуют своим HBA. В моем примере iSCSI1 будет работать через vmnic2, а iSCSI2 будет работать через vmnic3. Для этого я сделаю отдельный vSwitch и делаю все необходимые настройки.

Далее необходимо порты VMkernel  привязать к существующим зависимым адаптерам iSCSI.

Это уже делается из консоли либо локальной (благо теперь уже и у ESXi она тоже официально поддерживается), либо удаленной или через vSphere CLI.

Я удаленно через SSH все сделаю.

esxcli swiscsi nic add -n vmk1 -d vmhba32

esxcli swiscsi nic add -n vmk2 -d vmhba33

Осталось настроить таргеты в свойствах iSCSI HBA (также как и в софтверном инициаторе) и сделать рескан адаптеров.

Добавил 2 LUN. Вот что у меня получилось.

А вот и multipathing до LUN.

На этом все.

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, то вот эта статья Вам в помощь.

Цитирую что ответили.

- As you must be aware, thin provisioning is only available for in ESX 4.0. The behavior that you have mentioned in the case description is by design. Whenever a think provisioned disk is moved or copied to a different data store it will be converted to a thick disk. When you are copying it to a workstation and if we assume that it is running Windows (NTFS file system) it is automatically converted to a thick disk.

- However we can clone a thin provisioned vmdk to anther data store keeping it in the thin format.

Как я и думал. Прямого копирование между датасторами или же на другую файловую систему тонких дисков нет. Т.е оно есть, но при копирование он автоматом превращается в толстый. Хотите перенести ВМ с тонким диском на другую датасторе – мигрируйте (Migrate) или клонируйте (Clone) ее.

Существует несколько способов, с помощью которых можно обновить хосты:

1. vSphere Host Update Utility;
2. Утилита esxupdate;
3. vSphere CLI vihostupdate;
4. VMware Update Manager;

1. vSphere Host Update Utility

С помощью данной утилиты можно обновлять(патчить) только хосты с ESXi 4.

Тут все очень просто и легко. Данная утилита устанавливается при установке VMware vSphere  Client (во время установки клиента нужно выбрать соответствующую опцию). Запускаем утилиту, она предложит подключится к репозиторию патчев, соглашаемся.

Далее необходимо добавить хосты. Нажимаем Add Host и забиваем туда имя или IP хоста. При добавление утилита попросит ввести логин и пароль администратора.

Если хостов несколько проделываем туже процедуру для нового хоста.

Затем выбираем нужный хост и жмем Scan for Patches. После утилита просканирует хост на наличие тех или иных обновлений и выдаст результат.

Далее жмем Patch Host и идем наливать себе кофе/чай и ждать успешного завершения. В начале утилита автоматом закачает патчи из интернета, а потом начнет только устанавливать их. Так что в начальном этапе установки может показаться что процесс подвис. Тем кто сидит за проксей и нет NAT’а — решение траблы.

2. Утилита esxupdate

С помощью данной утилиты можно обновлять хосты только на ESX. Данная утилита входит в состав сервисной консоли. Перед тем как начать обновление, необходимо перевести хост в режим Maintenance Mode.

В начале необходимо скачать zip архив с обновлением с сайта VMware. Затем скопировать обновления на доступную для хоста Datastore.

Далее перейти в каталог куда было скопировано обновление и выполнить команду esxupdate —bundle=<имя_файла> update

Полный синтаксис утилиты esxupdate можно посмотреть в доке ESX 4 Patch Management Guide.

3. vSphere CLI — vihostupdate

Еще один способ обновления хостов на ESX 4 и ESXi4. На этот раз через скрипт vihostupdate.pl входящий в состав  vSphere CLI.

Чтобы обновить хост конкретным обновлением необходимо в начале скачать обновление из интернета, затем перевести хост в Maintenance Mode и выполнить команду vihostupdate.pl —server Имя_сервера_или_IP —username имя_пользователя —password Ваш_пароль —bundle путь_имя_файла_обновления –install

Более подробно о синтаксисе и опциях можно узнать в доке vSphere Command-Line Interface manual.

4. VMware Update Manager

Один из самых удобных и моих любимых способов обновления хостов с ESX и ESXi.

Описывать подробно не буду что да как, так как у VMware есть видео по работе с VUM.

В данном примере я буду использовать хост на ESX 4, два физических сетевых адаптера выделенных для работы под трафик iSCSI и СХД HP MSA 2324i с двумя контролерами (что то по серьезней пока нет под рукой для свободного разделывания), работающими в режиме Active-Active ULP.  Конфигурация из этого примера подойдет для настройки ESX/ESXi c другими типами СХД. Тут я затрону только настройку самого ESX, по умолчанию мы уже имеем несколько LUN на СХД(в моем примере 2 LUN).

Описывать настройку портов VMkernel, как и iSCSI инициатора в ESX/ESXi подробно не буду, а сразу перейду к настройки мультипатчинга и Round Robin.

Сама суть конфигурации для обеспечения multipathing в следующем. Каждый физический интерфейс отдаем только под использование 1-го порта VMkernel, в идеале вообще под монопольное использование. Т.е этот же интерфейс не должен быть задействован на другом порте VMkernel, который также будет использоваться для трафика iSCSI.

Есть два варианта конфигурации.

1. С одним vSwitch и несколькими портами VMkernel, а также несколькими привязанными физ. сетевыми к нему.

2. С несколькими vSwitch, в каждом из которых по 1-му порту VMkernel и к каждому привязана 1 физ. сетевая.

Оба варианта дают один и тот же результат. Я предпочитаю первый вариант, сделать отдельный vSwitch под нужды iSCSI трафика, он мне удобнее. Его я и опишу ниже.

Сама железная конфигурация выглядит так.

Далее конфигурируем хост для работы по iSCSI с мультипатчингом.

Создаем vSwitch с двумя портами VMkernel и привязываем к этому vSwitch 2-е физические сетевые карты.

Проделываем следующие: заходим в свойства порта VMkernel в моем примере iSCSI1 (Идем у нужного нам vSwitch в Properties -> выбираем нужный порт -> Edit) и переходим на вкладку NIC Teaming.

Включаем Failover Order, затем выбираем одну из сетевых карт которая будет не использована в данном подключение и перетаскиваем ее с помощью кнопки Move Down в секцию Unused Adapters. Этим действием мы оставили в использование под VMkernel порт только одну сетевую карту.

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

Теперь из консоли нужно выполнить следующую команду esxcli swiscsi nic add -n <port_name> -d <vmhba>, где port_name имя порта VMkernel, а vmhba имя iSCSI адаптера. Этим действием мы привязываем порты VMkernel к iSCSI инициатору хоста.

В моем примере я последовательно добавляю каждый порт

esxcli swiscsi nic add -n vmk1 -d vmhba34

esxcli swiscsi nic add -n vmk2 -d vmhba34

Далее командой esxcli swiscsi nic list -d <vmhba> можно просмотреть привязанные порты VMkernel к iSCSI адаптеру.

Теперь осталось сделать Rescan. Идем Configuration — > Storage Adapters. В правом верхнем углу жмем Rescan. По завершению процедуры у нас появятся 4 пути, по 2 на каждый LUN.

На вкладке Paths это хорошо видно.

По умолчанию для данного типа хранилищ работающих в режиме Active/Active политика multipathing является Fixed.  О политиках multipathing можно прочесть в другой моей заметки.

Возвращаемся на вкладку Devices и щелкаем правой кнопкой мыши по первому LUN и выбираем Manage Paths.

Вот тут как раз и меняем политику multipathing с Fixed на Round Robin.

Затем тоже самое проделываем со следующим LUN.

В итоге у меня получилась вот такая картина.

Вот и все с настройкой.

Из скринов видно что с Round Robin одновременно активны сразу два контролера и оба контролера участвуют во операциях I/O, в отличие от политики Fixed где одновременно активны оба контролера, но в операциях I/O участвует только один контролер.

Для чего нужен multipathing? Основное назначение это поддержка связи между хостом и хранилищем данных по нескольким физическим путям для обеспечения отказоустойчивости, а также для распределения нагрузки. Пример есть внешнее хранилище iSCSI и к нему подключен хост. Если использовать одно физ. подключение (1 порт), то при падение свитча/порта и т.п. мы потеряем связь с хранилищем. Рассказывать не буду чем это может обернуться для среды и для админа. Если же используется для подключения несколько портов, то в случае падения одного из портов технология мультипатчинга найдет другой доступный путь к хранилищу.

В ESX/ESXi 4 существует 3 политики мультипатчинга

• Fixed
• Most Recently Used
• Round Robin

Fixed — это политику рекомендуется использовать для тех хранилищ которые работают в режиме Active/Active. Суть ее в том, что доступ осуществляется по одному фиксированному пути (заранее определенному или выборному автоматически), если он становиться не доступным, то ищется альтернативный маршрут, как только становиться доступным первоначальный путь, хост переходит обратно на работу с ним.

Most Recently Used — данная политика используется с хранилищами, которые работают в режиме Active/Passive. Принцип работы данной политики: при работе с хранилищами используется последний работающий путь, если теряется связь по этому пути, то хост ищет альтернативный путь до хранилища и продолжает работать уже на новом. Если же восстанавливается работа предыдущего пути, хост не переходит на старый, а продолжает работать на том же.

Round Robin – данная политика работает по принципу автоматического выбора из имеющихся уже путей и распределению нагрузки между ними т.е она служит как и для отказоустойчивой работы хоста с LUN’ми, так и для распределения нагузки.

Более подробнее в этом KB о Multipathing policies in ESX 4

Статья о том как настроить multipathing и Round Robin для iSCSI LUN в ESX/ESXi 4.

Предыстория.

За последние пару дней на ВМ тестировался софт и различная конфигурация, поэтому было сделано несколько снапшотов, и несколько бекапов. В общей сложности 10 снапшотов размером в 60-65Гб.

После последнего бекапа, была попытка удалить несколько снапшотов, а затем и все снапшоты и остаться на последней точки, через GUI vSphere  клиента, которая закончилась неудачей.

Видимо файлы остались заблокированными после последнего сеанса бекапа. Почему так произошло я понял чуть позже. Оказывается, запустился еще один бекап джоб ВМ в Veeam Backup, про который я и совсем забыл. Этот джоб пришлось остановить, где то в середине процесса. Я торопился, и не хотелась ждать очередного завершения.

Минут через 10 блокировка исчезла. Я решил удалять снапшоты через snapshot manager. Зайдя туда я не обнаружил не одной точки отката.

Минут 5 сидел, думал что делать. Варианты решения пришли очень быстро.

1)      Есть бекап, можно откатиться, но вот беда после бекапа делались кое, какие настройки и реконфигурация ВМ, которая успешна работала. Делать второй раз туже процедуру мне не хотелось. Вариант отпал сразу.

2)      Сделать клон ВМ, затем его запустить и убить старую ВМ. Как известно при клонирование ВМ создается один ее диск, без дельт, к той точке, на которой сейчас работает ВМ.   Вариант отпал, так как тратить время на клонирование не хотелось.

3)      Просто  сделать новый снапшот ВМ, а затем попробовать из snapshot manager сделать Delete All. Этим вариантом я воспользовался и он мне помог.

4)      Был еще вариант удаления снапшотов из консоли ESX, но до него дело не дошло.

Снова хепи энд без лишних усилий.