У нас есть блок EMC NX4 SAN, обслуживающий общий ресурс CIFS для ряда серверов приложений Windows Server 2008 R2. Серверы приложений используют общий ресурс CIFS для обслуживания большого количества файлов изображений (~ 2500 операций в секунду для общего ресурса), однако ни SAN, ни серверы приложений не демонстрируют явных признаков нагрузки.
Время от времени сервер приложений, очевидно, внезапно разрывает соединение с SAN. Любой код .NET, пытающийся обслужить файл из SAN, завершается ошибкой:
System.IO.IOException: The specified network name is no longer available
Если я подключу RDP к серверу приложений и попытаюсь получить доступ к "\ san-name" через проводник, я получу ту же ошибку. Все остальные серверы приложений могут получить к нему доступ. Я также могу без проблем получить доступ к "\ ip-of-san", пинг тоже работает.
Перезагрузка сервера приложений решает проблему, но это несколько радикальная мера решения проблемы, учитывая, что кажется, что SAN работает нормально и компьютер может получить к нему доступ - просто похоже, что доступ "\ san-name" имеет заколотили.
Это произошло с двумя разными серверами приложений за последнюю неделю, поэтому я не подозреваю, что причиной является один сервер приложений. Пока не обращаем внимания на причину - как мне восстановить соединение "\ san-name" без перезагрузки машины? И можно как-то спросить, что пошло не так?
Журналы событий не показывают ничего (кроме связанных ошибок ASP.NET, вызванных проблемой) ни на серверах приложений, ни в SAN.
Обновить:
Основываясь на предложениях, я попробую перезапустить службу Workstation в следующий раз и посмотрю, поможет ли это решить проблему. Определенно не исправление, но сделать это намного быстрее, чем перезагружать всю машину, как я сейчас делал. Есть ли способ запросить статус подключений, поддерживаемых службой рабочей станции?
Обновление 2:
Подтверждено, что перезапуск службы рабочей станции «решает» проблему. Следующий шаг - попытаться изменить регистр для увеличения значения MaxCmds. Не смогу подтвердить, проблема ли в этом, могу только предположить, если он работает в течение длительного периода без проблем.
Похоже, что MaxCmds закончились. Вот две хорошие статьи об этом: Вот и Вот.
Вот теперь это изменить. Создайте файл с именем update.reg и поместите в него следующее:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters]
"MaxCmds"=dword:00000800
Сохраните, а затем дважды щелкните и подтвердите запрос. Требуется перезагрузка.
возможно, перезапустите службу рабочей станции на сервере приложений!
Об источнике:
Не могли бы вы подробнее рассказать о программном обеспечении, установленном на сервере приложений? В сети вы обнаружите, что это обычно проблема с AV, но поскольку вы не запускаете его ... может быть, другое приложение режима ядра, такое как программное обеспечение для резервного копирования?
Брандмауэр активен? Проверяли ли вы журналы событий на контроллере домена на предмет неисправного сервера приложений?
При возникновении проблемы следует также проанализировать сетевой трафик CIFS, чтобы посмотреть, что происходит.
Единственный раз, когда я сталкивался с этой ошибкой, были когда сервер / рабочая станция каким-то образом «теряли» связь с доменом. Повторное принудительное членство в домене помогло (netdom / resetpwd). Вы можете получить доступ Другой сетевые ресурсы (от сеанса RDP до сервера приложений), когда возникает проблема?
У меня были такие случаи раньше, но не с серверной частью EMC. Для приложений пользовательского уровня принудительное закрытие соединения с удаленным сервером и его повторное открытие вернет его обратно, хотя вам, возможно, придется попробовать пару раз, прежде чем оно начнет действовать. Для серверных приложений перезапуск пула приложений для этой службы работает. Если это не удается, перезапуск службы рабочей станции может избежать перезагрузки, но это почти столь же радикально.
Это может быть проблема с разрешением имен. Можете ли вы проверить свой DNS-сервер? Если это не позволяет разрешить имя, и после перезагрузки сервера приложений он разрешит доступ.
У меня была такая же проблема, когда некоторые пользователи рабочей станции жалуются, что они не могут получить доступ к приложению, хранящемуся на другом сервере, мы сделали то же самое, пытаясь получить доступ с помощью server-ip, который работал бы, но не с именем, поэтому мы проверили DNS. Мы внесли изменения в приложение для доступа к другому серверу с использованием IP-адреса, поскольку у нас есть статическая IP-сеть.
Сообщите мне, работает ли мое предложение для вас.
Я столкнулся с подобной проблемой. Мне не удалось сопоставить общий ресурс с сервером Windows 2012 с сервера Windows 2003.
Сетевая группа внедрила политику AD, которая изолировала более низкие версии Windows от контейнера AD, что не позволяло более низкой версии TLS подключаться к серверам с более высокими версиями TLS. Перемещение сервера назад или отключение политики для подключения к более ранней версии TLS решило эту проблему.
Вот несколько ошибок, с которыми я столкнулся в системном журнале:
Сертификат, полученный с удаленного сервера, был выдан ненадежным центром сертификации. Из-за этого никакие данные, содержащиеся в сертификате, не могут быть проверены. Запрос на соединение SSL не удался. Прилагаемые данные содержат сертификат сервера.
Сгенерировано фатальное предупреждение и отправлено на удаленную конечную точку. Это может привести к разрыву соединения. Код фатальной ошибки, определенный протоколом TLS, - 48. Состояние ошибки Windows SChannel - 552.
Надеюсь, это поможет решить вашу проблему.