Как узнать, какой VTEP использует ВМ в VMware NSX?

Одной из возможностей VMware NSX является поддержка нескольких VTEP (VXLAN Tunnel Endpoint), через которые осуществляется взаимодействие виртуальных машин с внешним миром (ВМ на других хостах и физическими устройствами).

Каждый VTEP представляет собой отдельный VMKernel интерфейс на хосте ESXi, который использует физические интерфейсы (аплинков) для передачи трафика VXLAN.

При настройке кластера администратор может выбрать - использовать один VTEP на каждом хосте или несколько. При использовании одного VTEP на хост поддерживаются практически все режимы балансировки за исключением балансировки по загрузке физического адаптера (Physical NIC Load).

Создание нескольких VTEP на одном хосте может пригодиться в тех случаях, когда нет возможности объединить интерфейсы при помощи LACP или Etherchannel, но требуется каким-либо образом обеспечить их равномерную загрузку. При использовании нескольких VTEP поддерживаются два режима балансировки:

• Route based on Port ID
• Route based on Source MAC hash

Тип балансировки задается для всех хостов кластера.

При выборе режима балансировки по Port ID или MAC hash мастер настройки автоматически задает количество VTEP равное количеству аплинков на распределенном коммутаторе. На всех хостах в кластере создается по одному VMkernel интерфейсу для каждого VTEP (в данном случае vmk1 и vmk2).

Все ВМ, создаваемые на хосте с несколькими VTEP, и подключающиеся к логическим коммутаторам, будут распределены между VTEP.

В ряде случаев требуется узнать - какой VTEP и какой физический интерфейс используется для передачи трифика ВМ?

Сделать это можно двумя способами. Во-первых, подключившись к хосту по SSH или через сервисную консоль, и запустив утилиту esxtop. После запуска нужно нажать клавишу 'n', чтобы переключиться на отображение информации о сети.

Для VMkernel интерфейсов и для сетевых интерфейсов ВМ информация об используемом аплинке будет отображаться в колонке TEAM-PNIC. Определить - какой VTEP используется, можно, сопоставив имя аплинка для сетевого интерфейса ВМ с именем аплинка для VMKernel интерфейса (в данном случае, для nsxsrv04 используется vmk1, а для nsxsrv05 - vmk2). Однако, этот способ работает не всегда.

Выбор VTEP для передачи трафика осуществляется в момент когда сетевой интерфейс ВМ переходит в активное состояние. Соответственно, такие операции, как перезагрузка ВМ или отключение/подключение сетевого интерфейса ВМ могут привести к смене используемого VTEP.

Однако, смена VTEP не происходит, если отключается или выходит из строя один из аплинков на хосте. В этом случае VMKernel интерфейс переключается на один из оставшихся активных аплинков и ВМ продолжает свою работу в качестве VTEP. Возвращаясь к примеру с esxtop, в случае когда один из физических интерфейсов вышел из строя, и несколько VMKernel используют один и тот же аплинк, невозможно будет понять - для какого сетевого адаптера ВМ какой VTEP используется.

Второй способ определить VTEP - подключиться к NSX Manager'у и выполнить команду:
show logical-switch controller <controller_id> vni <vni_id> mac

NSX Manager отобразит информацию об известных MAC адресах ВМ и IP адресах VTEP, через которые осуществляется сетевое взаимодействие с данными ВМ. Зная MAC адрес сетевого адаптера ВМ можно легко определить VTEP, который он использует.

Публикация веб-браузеров Google Chrome и Mozilla Firefox на терминальном сервере Windows Server 2008

Не так давно я столкнулся с несколькими проблемами при публикации веб-браузеров на терминальном сервере под Windows Server 2008 (R2).

Google Chrome

При попытке запустить опубликованный Google Chrome в seamless mode (у разных вендоров этот режим называется по-разному - RemoteApp у Microsoft, Hosted Applications у VMware, Application Publishing у Citrix), в окне браузера не загружались страницы, и через некоторое время он завершал свою работу с ошибкой.

Для решения проблемы при публикации Chrome через Microsoft RDS или VMware View достаточно добавить параметр "--allow-no-sandbox-job".

Для Citrix XenApp 6.5 есть статья в базе знаний (http://support.citrix.com/article/CTX132057), в которой при публикации Chrome также рекомендуется добавить параметр "--disable-gpu". Для решения проблемы мне также пришлось заменить Chrome на 32-битную версию, т.к. 64-битная ни в какую не хотела работать.

Mozilla Firefox

При попытке запустить два экземпляра Firefox на одном терминальном сервере под одним пользователем возникает ошибка "Firefox is already running but is not responding".

Проблема возникает в том случае, если два экземпляра Firefox запускаются из-под одной учетной записи пользователя в разных сессиях. При запуске процесс Firefox блокирует на запись профиль настроек для других процессов, соответственно, второй процесс Firefox не может получить доступ к профилю и выдает ошибку. Проверить это можно, открыв на терминальном сервере в момент возникновении ошибки диспетчер задач и посмотрев на количество сессий у пользователя (у данного пользователя будет две или больше сесии ICA-TCP).

По умолчанию Citrix использует механизм Session Sharing, который запускает опубликованные приложения внутри одной сессии. Данная ошибка возникает, если отключить Session Sharing, добавив ключ в реестре:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\Wfshell\TWI\:

Type: REG_DWORD

Value: SeamlessFlags = 1

а также настроить разрешение на запуск пользователем нескольких сессий на одном терминальном сервере (Remote Desktop Session Host Configuration -> Restrict each user to a single session: no).

Соответственно, чтобы решить проблему, надо либо включить Session Sharing обратно, либо настроить публикацию Firefox с ключами "-P -no-remote", тогда при запуске пользователь сможет создавать и использовать отдельный профиль для каждого экземпляра браузера.

Механизм IP Discovery в VMware NSX

При настройке логических коммутаторов в VMware NSX по умолчанию включается опция Enable IP Discovery.

Enable IP Discovery включает режим ARP Suppression, который позволяет уменьшить количество широковещательных ARP запросов, генерируемых виртуальными машинами для разрешения IP адресов в MAC адреса.

Проиллюстировать работу ARP Suppression можно на следующем примере. VM1 требуется отправить пакет VM2, подключенной к тому же логическому коммутатору (VXLAN 5001).

1. VM1 генерирует широковещательный ARP запрос с целью узнать MAC адрес VM2 (MAC2).
2. ESXi-1 перехватывает широковещательный запрос и вместо этого отправляет unicast запрос к контроллеру NSX Controller.
3. Контроллер получает ARP запрос.
4. Контроллер проверяет свою ARP таблицу на соответствие IP/MAC из запроса.
5. При наличии совпадения контроллер отправляет эту информацию серверу ESXi-1.
6. ESXi-1 получает сообщение от контроллера и обновляет локальную ARP таблицу, так, что в дальнейшем он будет знать на каком VTEP находится MAC адрес VM2 (10.20.10.11).
7. ESXi-1 генерирует ARP ответ от имени VM2 и отправляет его VM1. 

Если на 4 шаге контроллер не обнаружил соответствующую запись в таблице, то он уведомляет сервер ESXi-1, который затем отправляет широковещательный запрос на все VTEP, подключенные к данному логическому коммутатору.

При выключенном ARP Suppression / Enable IP Discovery - контроллер не сохраняет ARP таблицу, и, соответственно, все ARP запросы разрешаются широковещательно.

Посмотреть содержимое ARP таблицы на контроллере можно из консоли NSX Manager с помощью команды:
show logical-switch controller <controller_id> vni <vni_id> arp

Либо из консоли NSX Controller:
show control-cluster logical-switches arp-table <vni_id>

Информацию для ARP таблицы контроллеру NSX предоставляют сами серверы ESXi. Серверы ESXi могут получить информацию об IP адресах ВМ одним из двух способов:

• Для ВМ со статическими адресами, ESXi серверы узнают об IP адресе ВМ из ARP запроса, который генерирует данная ВМ.
• Для ВМ с динамическими адресами ESXi также может узнать об IP адресе ВМ из DHCP ответа, отправляемого сервером DHCP данной ВМ.

Посмотреть содержимое локальной ARP таблицы на сервере ESXi можно с помощью команды:
esxcli network vswitch dvs vmware vxlan network arp list --vds-name=<dvs_name> --vxlan-id=<vni_id>

IP Discovery можно включить и для обычных групп портов распределенного коммутатора. Делается это на вкладке Manage | Settings | NSX Configuration.