Ошибка клиента SMB

При использовании HyperV Server 2016 с масштабируемым файловым сервером (хранение файлов VHDX на файловом сервере) в журнале событий гипервизора (клиент SMB - подключение) появляется следующая ошибка:

Failed to establish a network connection.

Error: {Device Timeout}
The specified I/O operation on %hs was not completed before the time-out period expired.

Server name: storage.DOMAIN
Server address: IP_OF_STORAGE2:445
Connection type: Wsk

Guidance:
This indicates a problem with the underlying network or transport, such as with TCP/IP, and not with SMB. A firewall that blocks TCP port 445, or TCP port 5445 when using an iWARP RDMA adapter, can also cause this issue.

Среда кажется нестабильной, виртуальные машины продолжаются ошибки ввода-вывода, поэтому хранилище действительно выходит из строя.

Среда выглядит следующим образом:

  • Сервер HyperV 2016 с объединением сетевых карт (два интерфейса Ethernet 10G) с тегами VLAN
  • Двойные головные серверы хранилища с HyperV 2016 Включены сервер и файловые службы, объединенные в отказоустойчивый кластер с ролью масштабируемого файлового сервера (Storage1 и Storage 2).В качестве бэкэнда хранения у нас есть блок хранения EMC, подключенный через iSCSI к головным узлам.

Между узлами у нас есть сеть Cisco Nexus, работающая с активным etherchannel / LACP на объединенных интерфейсах.

Я бы больше, чем с радостью предоставлю любую информацию, если потребуется.

Единственным подходящим хитом, который я обнаружил во время поиска в Google, был этот поток технет без каких-либо решений https://social.technet.microsoft.com/Forums/en-US/ef3e9243-5a22-4020-97a0-219595666cd7/smbclient-errors?forum=winserver8gen

7
задан 12 May 2017 в 18:01
3 ответа

Мы решили воспользоваться полученными предложениями и модифицировать нашу сеть на их основе:

  • Мы добавили второй интерфейс с тегами VLAN в команду LBFO, которую мы использовали для включения SMB MultiChannel
  • Изменен алгоритм балансировки нагрузки команды на Address hash вместо значения по умолчанию Dynamic

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

Спасибо!

1
ответ дан 2 December 2019 в 23:32

Лоша идея е да смесвате iSCSI и LACP. Опитайте се да обедините връзките си и да използвате MPIO там, където правите транкинг досега.

4
ответ дан 2 December 2019 в 23:32

Я согласен с предыдущим оратором, MPIO - ваш лучший выбор, если вы в первую очередь рассматриваете производительность. Что касается конфигурации в целом, я думаю, вы можете сделать ее менее сложной, более надежной и, что самое главное, более производительной, используя локальное хранилище ваших узлов вместо физического блока SAN. Возьмите starwind free и позвольте ему синхронизировать данные между узлами, что должно дать вам приличный прирост производительности, поскольку у ваших клиентов будет кратчайший путь к хранилищу (локальность данных - низкая задержка).

4
ответ дан 2 December 2019 в 23:32

Теги

Похожие вопросы