Назад | Перейти на главную страницу

Хосты vSphere ESX 5.5 не могут подключиться к серверу NFS

Резюме: Моя проблема в том, что я не могу использовать сервер QNAP NFS в качестве хранилища данных NFS с моих хостов ESX, несмотря на то, что хосты могут пинговать его. Я использую vDS с восходящими каналами LACP для всего моего сетевого трафика (включая NFS) и подсеть для каждого адаптера vmkernel.

Настроить: Я оцениваю vSphere, и у меня есть два хоста vSphere ESX 5.5 (node1 и node2), и у каждого из них есть 4x NIC. Я объединил их всех, используя LACP / 802.3ad со своим коммутатором, а затем создал распределенный коммутатор между двумя хостами с LAG каждого хоста в качестве восходящего канала. Вся моя сеть проходит через распределенный коммутатор, в идеале я хочу воспользоваться DRS и резервированием. У меня есть виртуальная машина контроллера домена («Центральная») и виртуальная машина vCenter («vCenter»), работающие на узле 1 (с использованием локального хранилища данных узла 1), причем оба узла подключены к экземпляру vCenter. Оба хоста находятся в центре обработки данных vCenter и в кластере с отключенными HA и DRS. у меня есть

QNAP TS-669 Pro (версия 4.0.3) (серия TS-x69 находится на VMware Storage HCL), который я хочу использовать в качестве сервера NFS для моего хранилища данных NFS, у него есть 2x NIC, объединенных вместе с помощью 802.3ad с моим коммутатором.

vmkernel.log: Ошибка хоста vmkernel.log не очень полезна:

NFS: 157: Command: (mount) Server: (10.1.2.100) IP: (10.1.2.100) Path: (/VM) Label (datastoreNAS) Options: (None) cpu9:67402)StorageApdHandler: 698: APD Handle 509bc29f-13556457 Created with lock[StorageApd0x411121]
cpu10:67402)StorageApdHandler: 745: Freeing APD Handle [509bc29f-13556457]
cpu10:67402)StorageApdHandler: 808: APD Handle freed!
cpu10:67402)NFS: 168: NFS mount 10.1.2.100:/VM failed: Unable to connect to NFS server.

Настройка сети: Вот мой распределенная настройка коммутатора (JPG). Вот мои сети.

адреса vSphere

Другие адреса

Я использую коммутатор Cisco SRW2024P Layer-2 (включен Jumboframes) со следующей настройкой:

Каждая подсеть имеет маршрутизацию для другой, хотя соединения с сервером NFS от vmk1 не должны нуждаться в этом. Весь остальной трафик (веб-клиент vSphere, RDP и т. Д.) Проходит эту настройку нормально. Я заранее протестировал NFS-сервер QNAP с использованием виртуальных машин хоста ESX поверх рабочей станции VMware с выделенным физическим сетевым адаптером, и у меня не было проблем.

Список контроля доступа к общему ресурсу сервера NFS разрешающий и разрешает всем диапазонам подсетей полный доступ к общему ресурсу.

Я могу пинговать QNAP от node1 vmk1, адаптера, который следует использовать для NFS:

~ # vmkping -I vmk1 10.1.2.100
PING 10.1.2.100 (10.1.2.100): 56 data bytes
64 bytes from 10.1.2.100: icmp_seq=0 ttl=64 time=0.371 ms
64 bytes from 10.1.2.100: icmp_seq=1 ttl=64 time=0.161 ms
64 bytes from 10.1.2.100: icmp_seq=2 ttl=64 time=0.241 ms

Netcat не выдает ошибку:

~ # nc -z 10.1.2.100 2049
Connection to 10.1.2.100 2049 port [tcp/nfs] succeeded!

В таблица маршрутизации узла 1:

~ # esxcfg-route -l
VMkernel Routes:
Network          Netmask          Gateway          Interface
10.1.1.0         255.255.255.0    Local Subnet     vmk0
10.1.2.0         255.255.255.0    Local Subnet     vmk1
10.1.3.0         255.255.255.0    Local Subnet     vmk2
10.1.4.0         255.255.255.0    Local Subnet     vmk3
default          0.0.0.0          10.1.1.254       vmk0

Информация о сетевом адаптере ядра виртуальной машины

~ # esxcfg-vmknic -l
Interface  Port Group/DVPort   IP Family IP Address                              Netmask         Broadcast       MAC Address       MTU     TSO MSS   Enabled Type       
vmk0       133                 IPv4      10.1.1.1                                255.255.255.0   10.1.1.255      00:50:56:66:8e:5f 1500    65535     true    STATIC     
vmk0       133                 IPv6      fe80::250:56ff:fe66:8e5f                64                              00:50:56:66:8e:5f 1500    65535     true    STATIC, PREFERRED
vmk1       164                 IPv4      10.1.2.1                                255.255.255.0   10.1.2.255      00:50:56:68:f5:1f 1500    65535     true    STATIC     
vmk1       164                 IPv6      fe80::250:56ff:fe68:f51f                64                              00:50:56:68:f5:1f 1500    65535     true    STATIC, PREFERRED
vmk2       196                 IPv4      10.1.3.1                                255.255.255.0   10.1.3.255      00:50:56:66:18:95 1500    65535     true    STATIC     
vmk2       196                 IPv6      fe80::250:56ff:fe66:1895                64                              00:50:56:66:18:95 1500    65535     true    STATIC, PREFERRED
vmk3       228                 IPv4      10.1.4.1                                255.255.255.0   10.1.4.255      00:50:56:72:e6:ca 1500    65535     true    STATIC     
vmk3       228                 IPv6      fe80::250:56ff:fe72:e6ca                64                              00:50:56:72:e6:ca 1500    65535     true    STATIC, PREFERRED

Вещи, которые я пробовал / проверял:

У меня нет идей, что попробовать дальше. То, что я делаю иначе, чем моя установка VMware Workstation, - это использование LACP с физическим коммутатором и виртуальным распределенным коммутатором между двумя хостами. Я предполагаю, что vDS, вероятно, является источником моих проблем, но я не знаю, как исправить эту проблему, не устраняя ее.

Хм ... vDS, NFS и LACP у меня отлично работают. Однако похоже, что вы довольно глубоко погрузились в высококлассный набор функций vSphere. Для большинства установок LACP на самом деле не требуется, но я могу понять привлекательность попытки его использовать ...

Ни одна из vDS и других функций не имеет значения, если QNAP не позволяет монтировать ...

  • Вы подтвердили соединение с vmkping, но, вероятно, стоит попробовать это с большим MTU: vmkping -s 9000 10.1.2.100 (интерфейс указывать не нужно). Убедитесь, что это работает.
  • На данный момент я бы полностью отключил ACL QNAP.
  • Имя вашего пути монтирования, вероятно, должно быть ip.address:/share/VM/
  • Попробуйте смонтировать снова, но обратите внимание на сообщения в /var/log/vobd.log на хосте ESXi. Если там написано что-то вроде "Запрос на монтирование был отклонен сервером NFS.", проблема в QNAP.
  • Извините, но нам не хватает вашего физического типа коммутатора / модели и конфигурации ... Вы можете это описать? У вас должны быть транкинг-конфигурации VLAN + LACP на соответствующих портах.

Ваш снимок экрана с конфигурацией vDS выглядит так, как будто это информация для одного хоста. Убедитесь, что в вашей конфигурации LACP и установлены правильные режимы балансировки нагрузки. Должно получиться так:

вчера была такая же проблема с TS-420U и ESXi 5.5 U1. Моя настройка: - Два ESXi 5.5 с сервером vCenter - Хранилище с прямым подключением - NAS QNAP TS-420U в одной подсети с хостами ESXi (поэтому проблем с маршрутизацией нет) - Все находятся в подсети 10.207.253.128/26

После настройки NAS я установил ACL на соответствующую подсеть (10.207.253. *) И подключился без проблем. Но после перезагрузки хостов ESXi больше нет соединения, такие же ошибки, как у вас. Перезагрузка NAS и выключение / включение службы NFS не помогли. Последнее, что я пробовал, - это установить ACL на сервере NAS на * -> бум, снова заработало. Оба хоста ESXi могут без проблем подключаться к общему ресурсу NFS.

Теперь мне просто нужно выяснить, почему хосты ESXi не могут подключиться с ACL, установленным для подсети ...

Я сдался.

Я удалил LACP из восходящих каналов и переключился на iSCSI с несколькими путями (группа портов и связанный vmk для каждого восходящего канала, только для SAN).

К сожалению, ESXi не включает диагностические команды rpcinfo и showmount. NFS по умолчанию использует UDP. Чтобы выполнить монтирование, система должна иметь возможность взаимодействовать с rpc portmapper на сервере NFS (порт 111 tcp / udp), который предоставляет порты для mountd и nfs Сервисы. В любой другой системе я бы использовал rpcinfo -p <ip> чтобы убедиться, что portmap работает, и showmount -e <ip> чтобы увидеть, что экспортируется.

Кроме того, в отличие от vMotion, FT logging и iSCSI, NFS не привязан к конкретному vmk. Он будет использовать любой доступный интерфейс. Поскольку у вас есть интерфейс в той же подсети, что и сервер NFS, он должен используйте это.

Если на NAS есть журналы, поищите там подсказки. В противном случае возвращение к одной ссылке и отслеживание трафика может быть вашим единственным выходом. (этот коммутатор выполняет зеркалирование портов?)

Я думаю, это связано с NFS4. ESX поддерживает только NSF3, иначе это не сработает.

У меня была аналогичная проблема с моей конфигурацией, вы можете быть удивлены, но добавление записи для каждого хоста esx в файле / etc / hosts (IP hostname hostname) QNAP решило мою проблему.

Надеюсь это поможет.