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

Проблема с VMWare vSphere и NFS: повторное возникновение состояния apd

У меня возникли проблемы с VMWare vSphere 5.1 и хранилищем NFS в двух разных настройках, что приводит к состоянию «All Path Down» для общих ресурсов NFS. Сначала это происходило один или два раза в день, но в последнее время это происходит гораздо чаще, особенно когда выполняются задания Acronis Backup.

Настройка 1 (производство): 2 хоста ESXi 5.1 (Essentials Plus) + OpenFiler с NFS в качестве хранилища

Установка 2 (лабораторная работа): 1 хост ESXi 5.1 + Ubuntu 12.04 LTS с NFS в качестве хранилища

Вот пример из vmkernel.log:

2013-05-28T08:07:33.479Z cpu0:2054)StorageApdHandler: 248: APD Timer started for ident [987c2dd0-02658e1e]
2013-05-28T08:07:33.479Z cpu0:2054)StorageApdHandler: 395: Device or filesystem with identifier [987c2dd0-02658e1e] has entered the All Paths Down state.
2013-05-28T08:07:33.479Z cpu0:2054)StorageApdHandler: 846: APD Start for ident [987c2dd0-02658e1e]!
2013-05-28T08:07:37.485Z cpu0:2052)NFSLock: 610: Stop accessing fd 0x410007e4cf28  3
2013-05-28T08:07:37.485Z cpu0:2052)NFSLock: 610: Stop accessing fd 0x410007e4d0e8  3
2013-05-28T08:07:41.280Z cpu1:2049)StorageApdHandler: 277: APD Timer killed for ident [987c2dd0-02658e1e]
2013-05-28T08:07:41.280Z cpu1:2049)StorageApdHandler: 402: Device or filesystem with identifier [987c2dd0-02658e1e] has exited the All Paths Down state.
2013-05-28T08:07:41.281Z cpu1:2049)StorageApdHandler: 902: APD Exit for ident [987c2dd0-02658e1e]!
2013-05-28T08:07:52.300Z cpu1:3679)NFSLock: 570: Start accessing fd 0x410007e4d0e8 again
2013-05-28T08:07:52.300Z cpu1:3679)NFSLock: 570: Start accessing fd 0x410007e4cf28 again

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

Я много искал в Интернете и спрашивал на форумах, но до сих пор никто не мог мне помочь. Основываясь на сообщениях в блогах и статьях базы знаний VMWare, я попробовал следующие настройки NFS:

Net.TcpipHeapSize = 32
Net.TcpipHeapMax = 128
NFS.HartbeatFrequency = 12
NFS.HartbeatMaxFailures = 10
NFS.HartbeatTimeout = 5
NFS.MaxQueueDepth = 64

Вместо NFS.MaxQueueDepth = 64 я уже пробовал другие настройки, такие как NFS.MaxQueueDepth = 32 или даже NFS.MaxQueueDepth = 1. К сожалению, безуспешно.

Было бы здорово, если бы мне кто-нибудь помог в этом вопросе. Это действительно раздражает.

Заранее спасибо за помощь.

[ОБНОВЛЕНИЕ] Как я объяснил в комментарии ниже, вот настройка сети:

В производственной установке трафик NFS привязан к отдельной VLAN с идентификатором 20. Я использую 24-портовый коммутатор HP 1810. Система OpenFiler подключена к VLAN с помощью 4 сетевых адаптеров Intel GbE с динамическим LACP. Оба ESX имеют 4 сетевые карты Intel GbE, использующие 2 статических транка LACP, каждая из которых содержит 2 сетевые карты. Одна пара подключена к обычной локальной сети, а другая - к VLAN 20.

А вот скриншот vSwitch:

Конфигурация переключателя:

Конфигурация порта:

В лабораторной работе установите по одной сетевой карте Intel на каждой стороне без VLAN, но с другой IP-подсетью.

Я рекомендую попробовать это без статических магистралей на стороне хоста ESXi. Вероятно, они не делают того, что вы ожидаете (скорость передачи> 1 Гбит / с). Попробуйте обойтись без этого и посмотрите, каковы будут последствия ... Я настраиваю свое хранилище NFS с несколькими сетевыми адаптерами на стороне хоста ESXi, но выполняю LACP от устройства хранения к коммутатору.

У меня была такая же проблема. Оказалось, что это были мои физические коммутаторы, MTU которых я установил на 9000, и мои порты vmk также были установлены на 9000. Похоже на брак, заключенный на небесах. Мой коммутатор хотел, чтобы он был установлен на 9000+. Не уверен, что это за плюс, так как я в отчаянии установил его на 9216 (максимум переключателя), и он сработал.