Compartilhamento do Windows: o nome da rede especificado não está mais disponível

8

Temos uma caixa EMC NX4 SAN que serve 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 veicular muitos arquivos de imagem (~ 2500 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, aparentemente, de repente, um servidor de aplicativos interrompe a conexão com a SAN. Qualquer código .NET que tenta servir um arquivo da SAN falha com:

System.IO.IOException: The specified network name is no longer available

Se eu fizer o RDP no servidor de aplicativos e tentar acessar "\ san-name" através do explorer, recebo o mesmo erro. Todos os outros servidores de aplicativos podem acessá-lo perfeitamente. Também posso acessar "\ ip-of-san" perfeitamente, o ping também funciona.

Uma reinicialização do servidor de aplicativos corrige o problema, mas é uma medida um tanto drástica para o problema, pois parece que a SAN está funcionando bem e o computador pode acessá-lo - apenas parece que o acesso "\ san-name" vomitou.

Isso aconteceu com dois servidores de aplicativos diferentes durante a última semana, então não suspeito que um único servidor de aplicativos seja a causa. Ignorando a causa por enquanto - como eu restauraria a conexão "\ san-name" sem reiniciar a máquina? E posso, de alguma forma, consultar o que deu errado?

Os logs 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 na próxima vez e ver se isso ajuda no problema. Definitivamente, não é uma correção, mas é muito mais rápido do que reiniciar toda a máquina, como eu venho fazendo atualmente. Alguma 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 Estação de Trabalho "corrige" o problema. O próximo passo é tentar a alteração reg para aumentar o valor MaxCmds. Não será possível confirmar se esse é o problema; só podemos assumir se ele for executado por um longo período sem problemas.

— Mark S. Rasmussen
fonte

Existem indicações nos logs de eventos nos servidores de aplicativos, especificamente no log do sistema, que apontam para uma falha transitória ou algum outro mecanismo sendo acionado (por exemplo, proteção do DOS no LanManagerService, conforme descrito aqui blog.mreza.info/archive/ 2007/09/26 /… ). Além disso, qual configuração de AV está em vigor e como o Celerra está integrado a isso.

— Helvick

@ Helvick Não há entradas relevantes nos logs de eventos, nem aplicativo nem sistema. Nós não executamos o AV nem nos servidores nem no Celerra. Também procurei no log de eventos o evento de proteção LanManagerService DOS, mas ele voltou vazio.

— Mark S. Rasmussen

7

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 prompt. É necessária uma reinicialização.

— Scott Forsyth - MVP
fonte

Como a recompensa está prestes a acabar, atribuirei a sua resposta na medida em que for a melhor aposta, embora tenha que testá-la antes de aceitar. Eu alterei anteriormente o FCNMode para registrar apenas o diretório bin, pois havia erros de "limite de comando da bios atingido" em alguns aplicativos hospedados em outro compartilhamento UNC. Mas acho que a configuração FCNMode não afeta dirs fora do diretório do aplicativo.

— Mark S. Rasmussen

O FCNMode também pode ajudar, mas uma estrutura de disco grande sobre UNC pode causar a entrada de ambos. Acredito que o FCN é contra toda a árvore de diretórios do .NET 2.0 e superior.

— Scott Forsyth - MVP

Além disso: vi o MaxCmds esgotar-se com vários nós de front-end e vários usuários usados para pastas diferentes. O MaxCmds é uma configuração que aplico a todos os meus webfarms UNC. Eu nunca vi uma desvantagem nessa mudança. Também existe uma configuração de servidor se o destino de compartilhamento CIFS for um servidor Windows, mas isso não se aplica a você.

— Scott Forsyth - MVP

Apenas para esclarecer meu comentário, os aplicativos .NET reais são armazenados no disco local. O principal objetivo dos aplicativos é veicular dados de imagens armazenados em compartilhamentos UNC. A configuração FCNMode, como eu a entendo, se aplica apenas ao diretório do aplicativo, não tendo impacto no meu caso. MaxCmds ainda é um possível culpado. Todos os aplicativos estão em execução na mesma conta, mas com mais de 500 aplicativos da web em cada servidor, é provável que eu esteja acabando.

— Mark S. Rasmussen

O comportamento padrão no ASP.NET para FCN é percorrer toda a estrutura de diretórios. A chave de registro do HKLM \ Software \ Microsoft \ ASP.NET \ FCNMode pode ser 0, 1 ou 2. 0 é o padrão que possui um objeto FCN para cada pasta. Se você mudar para 2, ele usará um objeto para a raiz e todos os subdiretórios. Definir como 1 o desliga completamente. support.microsoft.com/kb/911272 . Você também pode achar útil esta postagem e discussão no blog: weblogs.asp.net/owscott/archive/2006/02/21/ASP.NET-v2.0- 2D00 -AppDomain-recycles_2C00_-mais-comum-que-antes.aspx .

— Scott Forsyth - MVP

1

talvez reinicie o serviço da estação de trabalho no servidor de aplicativos!

— Tony Roth
fonte

se estiver realmente perdendo a resolução de nomes, você pode tentar como um experimento usar um arquivo de hosts para causar um curto-circuito no processo de resolução de nomes.

— tony roth

Tentei reiniciar o serviço, não funcionou, mas reiniciei o servidor e ele parece funcionar depois disso.

— Circle Hsiao

0

Já tive casos como este antes, embora não com um back-end da EMC. Para aplicativos da área de usuário, o fechamento forçado da conexão com o servidor remoto e a reabertura o trará de volta, embora você precise 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 da Estação de Trabalho pode evitar uma reinicialização, mas é quase tão drástica.

— sysadmin1138
fonte

0

Na fonte:

Você poderia fornecer mais detalhes sobre o software instalado no servidor de aplicativos? Na rede, você encontrará que geralmente é um problema com um AV, mas como você não executa nenhum ... talvez outro aplicativo no modo kernel como um software de backup?

O firewall está ativo? Você verificou os logs de eventos no controlador de domínio com falha no servidor de aplicativos?

Você também deve detectar o tráfego da rede CIFS quando surgir o problema para ver o que acontece.

As únicas vezes que deparei com esse erro foram quando o servidor / estação de trabalho "perdeu" o vínculo com o domínio. Reforçar a associação ao 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 surgir?

— Renik
fonte

O único software em execução no servidor é o IIS executando um aplicativo da Web .NET. O firewall não está ativo, pois está por trás da nossa DMZ. Vou tentar verificar os logs do AD na próxima vez que isso acontecer. Boa dica sobre o CIFS - Vou tentar adicionar um ISCSI LUN na próxima vez também para ver se ele está relacionado apenas ao CIFS ou se é um problema geral de conectividade usando o nome do host. Posso acessar todas as outras máquinas e compartilhamentos usando CIFS enquanto este erro está ocorrendo.

— Mark S. Rasmussen

0

Isso pode ser um 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, o acesso será permitido.

Eu tive o mesmo problema quando algum usuário da estação de trabalho reclama que não conseguiu acessar o aplicativo armazenado em outro servidor, fizemos o mesmo tentando acessar com o servidor-ip que funcionaria, mas não com o nome, para verificar 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ê.

— maniargaurav
fonte

Enquanto recebo a mensagem de erro, posso executar uma pesquisa ns corretamente, retornando o IP correto do nosso DNS local do AD. Também posso executar ping usando o nome do host e o endereço IP.

— Mark S. Rasmussen

0

Encontrei um problema semelhante. Não foi possível mapear um compartilhamento no Windows Server 2012 a partir de um servidor Windows 2003.

O grupo de rede havia implementado uma política do AD que isolava as versões inferiores do Windows em um contêiner do AD que não permitia que a versão inferior do TLS se conectasse a servidores executando versões superiores do TLS. Mover o servidor de volta ou desativar a política para conectar-se à versão inferior do TLS corrigiu esse problema.

Aqui estão alguns erros que encontrei no log do sistema:

O certificado recebido do servidor remoto foi emitido por uma autoridade de certificação não confiável. Por esse motivo, nenhum dos dados contidos no certificado pode ser validado. A solicitação de conexão SSL falhou. Os dados anexados contêm o certificado do servidor.

Um alerta fatal foi gerado e enviado ao terminal remoto. Isso pode resultar no encerramento da conexão. O código de erro fatal definido pelo protocolo TLS é 48. O estado de erro do Windows SChannel é 552.

Espero que ajude a resolver seu problema.

— info_tech
fonte