VNX. Хранилище данных NFS периодически переходит в автономный режим для одного хоста

Одно или несколько хранилищ данных NFS на одном хосте одновременно переходят в состояние APD (все пути не работают). Это может произойти с разными хранилищами данных на разных хостах или с одним и тем же хранилищем данных на нескольких хостах. Как правило, это случайная и непостоянная проблема, которую можно устранить путем отключения и включения портов Ethernet на хосте ESXi или его перезагрузки. Это не обязательно всегда происходит с одним и тем же хранилищем данных или одним и тем же хостом.

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

Это относится как к продуктам VNX1, VNX2, так и к продуктам eNAS.

Служба поддержки VMware может порекомендовать настройку NFS. MaxQueueDepth в 64, но в настоящее время у Dell нет рекомендаций по этому значению. Однако это вряд ли решит эту проблему.

Инженерный отдел обнаружил проблему в том, как мы обрабатываем расчет окна отправки TCP в некоторых ситуациях. По сути, происходит следующее: в определенный момент VNX неправильно устанавливает значение 0 для окна отправки TCP. Это запрещает системе VNX отправлять новые данные на хост, с которым она взаимодействует через это подключение. Система VNX по-прежнему может принимать входящие данные на уровне TCP, но не может отправлять ответы NFS.

Насколько нам известно, мы наблюдали такое поведение, влияющее на хранилища данных ESXi NFS только из-за особого способа, которым ESXi время от времени выполняет подтверждения TCP. В определенные моменты вместо отправки подтверждения со следующим пакетом данных ESXi использует дополнительное отдельное подтверждение сразу после получения новых данных от VNX, даже если в очереди передачи имеются данные. Такое поведение заставляет DM думать, что передача является однонаправленной, и переводит ее в режим прогнозирования заголовка. Если при передаче более 2 Гбайт данных из DM поведение подтверждения TCP ESXi остается согласованным, DM будет медленно сокращать окно отправки TCP до 0, в результате чего данное конкретное TCP-соединение сможет отправлять данные только в одном направлении (от хоста к массиву). Если модуль переноса данных получает пакет данных с новым номером ACK в течение передачи объемом 2 Гбит/с или происходит потеря пакета, которая приводит к повторной передаче, проблема не возникает.

ESXi отправляет тактовый импульс в хранилище данных, чтобы определить, доступно ли оно. Этот тактовый импульс представляет собой запрос GetAttr к определенному файлу в хранилище данных. Если несколько раз происходит сбой, хост ESXi помечает хранилище данных как APD. Поскольку система VNX не может отвечать на запросы GetAttr от хоста ESXi, пока для ее TCP-запроса задано значение 0, она помечает хранилище данных как недоступное. По какой-либо причине ESXi не пытается сбросить соединение, что также устранило бы эту проблему. Поэтому перезагрузка или отключение и активация сетевых портов на хосте работает для восстановления доступа.

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

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

Поведение вычисления окна отправки TCP будет исправлено в будущих выпусках кода для версий кода 7.1 и 8.1 (VNX1, VNX2 и eNAS). В настоящее время доступно оперативное исправление. Если требуется немедленное исправление, обратитесь в службу поддержки и запросите его, а также запланирован перезапуск или переключение при отказе.