Temos uma caixa EMC NX4 SAN que oferece um compartilhamento CIFS para vários servidores de aplicativos do Windows Server 2008 R2. Os servidores de aplicativos estão usando o compartilhamento CIFS para fornecer muitos arquivos de imagem (~ 2.500 ops / s no compartilhamento), no entanto, nem a SAN nem os servidores de aplicativos estão mostrando sinais óbvios de estresse.
De vez em quando, um servidor de aplicativos, aparentemente, de repente, desconecta a conexão com a SAN. Qualquer código .NET que tente servir um arquivo da SAN falha com:
System.IO.IOException: The specified network name is no longer available
Se eu executar o RDP no servidor de aplicativos e tentar acessar "\ san-name" por meio do explorer, recebo o mesmo erro. Todos os outros servidores de aplicativos podem acessá-lo bem. Eu também posso acessar "\ ip-of-san" apenas perfeitamente, ping também funciona.
Uma reinicialização do servidor de aplicativos corrige o problema, mas isso é uma medida um tanto drástica para o problema, já que parece que o SAN está funcionando bem e o computador pode acessá-lo - ele simplesmente parece o "\ san-name" "o acesso aumentou.
Isso aconteceu com dois servidores de aplicativos diferentes durante a última semana, por isso não suspeito que um único servidor de aplicativos seja a causa. Ignorando a causa por enquanto - como restauraria a conexão "\ san-name" sem reiniciar a máquina? E posso de alguma forma consultar o que deu errado?
Os registros de eventos não mostram nada (além dos erros relacionados ao ASP.NET causados pelo problema), nem nos servidores de aplicativos nem na SAN.
Atualização:
Com base nas sugestões, tentarei reiniciar o serviço Estação de Trabalho da próxima vez e ver se isso ajuda no problema. Definitivamente não é uma correção, mas muito mais rápido de fazer do que reiniciar a máquina inteira como eu tenho feito atualmente. Qualquer maneira de consultar o status das conexões que o serviço Estação de Trabalho mantém?
Atualização 2:
Confirmado que reiniciar o serviço de estação de trabalho "corrige" o problema. O próximo passo é tentar a mudança de registro para aumentar o valor de MaxCmds. Não será possível confirmar se esse é o problema, só pode ser assumido se for executado por um longo período sem problemas.
Parece que os MaxCmds acabaram. Aqui estão dois bons artigos sobre isso: aqui e aqui .
Aqui está agora para mudar isso. Crie um arquivo chamado update.reg e coloque o seguinte:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters]
"MaxCmds"=dword:00000800
Salve e clique duas vezes e aceite o aviso. Uma reinicialização é necessária.
talvez reinicie o serviço da estação de trabalho no servidor de aplicativos!
Já tive casos assim antes, mas não com um back end da EMC. Para aplicações de usuário, forçar o fechamento da conexão com o servidor remoto e reabri-lo irá trazê-lo de volta, embora você possa ter que tentar algumas vezes antes que ele atue em conjunto. Para aplicativos de servidor, a reciclagem do Pool de Aplicativos para esse serviço funciona. Se isso falhar, a reciclagem do Serviço de Estações de Trabalho pode evitar uma reinicialização, mas é quase tão drástica.
Na fonte:
Você poderia fornecer mais detalhes sobre o software instalado no servidor de aplicativos? Na net, você descobrirá que normalmente é um problema com um antivírus, mas como você não executa nenhum ... talvez outro aplicativo do modo kernel como um software de backup?
O firewall está ativo? Você verificou os logs de eventos no controlador de domínio do servidor de aplicativos defeituoso?
Você também deve farejar o tráfego de rede CIFS quando o problema surgir para ver o que acontece.
As únicas vezes em que encontrei esse erro foram quando o servidor / estação de trabalho de alguma forma "perdeu" seu link com o domínio. Reforçar a participação no domínio fez o truque (netdom / resetpwd). Você pode acessar outros compartilhamentos de rede (da sessão RDP para o servidor de aplicativos) quando o problema surge?
Isso pode ser problema com a resolução de nomes. Você pode verificar com o seu servidor DNS? Se isso não permitir resolver o nome e depois de reiniciar o servidor de aplicativos, ele permitirá o acesso.
Eu tive o mesmo problema quando algum usuário da estação de trabalho reclama que eles não conseguiam acessar o aplicativo armazenado em outro servidor, nós tínhamos feito o mesmo tentando acessar com o servidor-ip que funcionaria mas não com nome então checamos o DNS . Fizemos alterações no aplicativo para acessar outro servidor usando o endereço IP, pois temos uma rede IP estática.
Deixe-me saber se minha sugestão funciona para você.
Eu me deparei com um problema semelhante. Eu não era capaz de mapear um compartilhamento para o Windows Server 2012 a partir de um servidor Windows 2003.
O grupo de rede tinha implementado uma política do AD que havia isolado as versões inferiores do Windows para um contêiner do AD que não permitia a versão inferior do TLS para se conectar a servidores que executavam versões superiores do TLS. Mover o servidor de volta ou desativar a política para se conectar com uma versão inferior do TLS corrigiu esse problema.
Aqui estão alguns erros que encontrei no log do sistema:
The certificate received from the remote server was issued by an untrusted certificate authority. Because of this, none of the data contained in the certificate can be validated. The SSL connection request has failed. The attached data contains the server certificate.
A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 48. The Windows SChannel error state is 552.
Espero que ajude a resolver seu problema.