Uso compartido de Windows: el nombre de red especificado ya no está disponible

8

Tenemos una caja SAN EMC NX4 que sirve un recurso compartido CIFS a varios servidores de aplicaciones de Windows Server 2008 R2. Los servidores de aplicaciones están utilizando el recurso compartido CIFS para servir muchos archivos de imagen (~ 2500 operaciones / segundo en el recurso compartido), sin embargo, ni la SAN ni los servidores de aplicaciones muestran signos evidentes de estrés.

De vez en cuando, un servidor de aplicaciones, aparentemente de repente, desconecta la conexión a la SAN. Cualquier código .NET que intente servir un archivo desde la SAN falla con:

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

Si RDP al servidor de aplicaciones e intento acceder a "\ san-name" a través del explorador, obtengo el mismo error. Todos los demás servidores de aplicaciones pueden acceder a él perfectamente. También puedo acceder a "\ ip-of-san" perfectamente, el ping funciona también.

Un reinicio del servidor de aplicaciones soluciona el problema, pero esa es una medida un tanto drástica del problema, dado que parece que la SAN está funcionando bien y la computadora puede acceder a ella, solo parece que el acceso "\ san-name" tiene vomitado.

Esto ha sucedido con dos servidores de aplicaciones diferentes durante la última semana, por lo que no sospecho que un solo servidor de aplicaciones sea la causa. Ignorando la causa por ahora, ¿cómo restablecería la conexión "\ san-name" sin reiniciar la máquina? ¿Y de alguna manera puedo preguntar qué salió mal?

Los registros de eventos no muestran nada (además de los errores relacionados con ASP.NET causados por el problema), ni en los servidores de aplicaciones ni en la SAN.

Actualización:
según las sugerencias, intentaré reiniciar el servicio de estación de trabajo la próxima vez y veré si eso ayuda al problema. Definitivamente no es una solución, pero es mucho más rápido que reiniciar toda la máquina como lo he estado haciendo actualmente. ¿Alguna forma de consultar el estado de las conexiones que mantiene el servicio de estación de trabajo?

Actualización 2: se
confirmó que reiniciar el servicio de estación de trabajo "soluciona" el problema. El siguiente paso es probar el cambio de registro para aumentar el valor de MaxCmds. No podrá confirmar si se trata del problema, solo puede suponer si se ejecuta durante un período prolongado sin problemas.

— Mark S. Rasmussen
fuente

¿Hay alguna indicación en los registros de eventos en los servidores de aplicaciones, específicamente en el registro del sistema, que apuntan a una falla transitoria o algún otro mecanismo que se activa (por ejemplo, la protección de DOS en LanManagerService como se describe aquí blog.mreza.info/archive/ 2007/09/26 / ... ). También qué configuración AV está en su lugar y cómo se integra Celerra con eso.

— Helvick

@Helvick No hay entradas relevantes en los registros de eventos, ni la aplicación ni el sistema. No ejecutamos AV ni en los servidores ni en Celerra. También busqué en el registro de eventos el evento de protección de LanManagerService DOS, pero volvió vacío.

— Mark S. Rasmussen

7

Esto suena como si los MaxCmds se hubieran agotado. Aquí hay dos buenos artículos sobre eso: aquí y aquí .

Aquí está ahora para cambiarlo. Cree un archivo llamado update.reg y coloque lo siguiente en él:

Windows Registry Editor Version 5.00 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters] 
"MaxCmds"=dword:00000800

Guarde y luego haga doble clic y acepte la solicitud. Se requiere un reinicio.

— Scott Forsyth - MVP
fuente

Dado que la recompensa está a punto de agotarse, la otorgaré a su respuesta en la medida en que sea la mejor apuesta, aunque tendré que probarla antes de aceptar. Previamente modifiqué el FCNMode para registrar solo el directorio bin ya que tuve errores de "límite de comando bios alcanzado" en algunas de las aplicaciones alojadas en otro recurso compartido UNC. Pero supongo que la configuración de FCNMode no afecta a los directorios fuera del directorio de la aplicación.

— Mark S. Rasmussen

El FCNMode también puede ayudar, pero una gran estructura de disco sobre UNC puede hacer que ambos entren en juego. 'Creo' que FCN está en contra de todo el árbol de directorios para .NET 2.0 y superior.

— Scott Forsyth - MVP

Además de eso: he visto que los MaxCmds se agotan con múltiples nodos front-end y múltiples usuarios utilizados para diferentes carpetas. MaxCmds es una configuración que aplico a todos mis webfarms de UNC. Nunca he visto un inconveniente en ese cambio. También hay una configuración de servidor si el objetivo compartido de CIFS es un servidor de Windows, pero eso no se aplica a usted.

— Scott Forsyth - MVP

Solo para aclarar mi comentario, las aplicaciones .NET reales se almacenan en el disco local. El objetivo principal de las aplicaciones es servir datos de imágenes, que se almacenan en recursos compartidos UNC. La configuración de FCNMode, según tengo entendido, solo se aplica al directorio de la aplicación, por lo que no tiene ningún impacto en mi caso. Sin embargo, MaxCmds sigue siendo un posible culpable. Todas las aplicaciones se ejecutan con la misma cuenta, pero con más de 500 aplicaciones web en cada servidor, es probable que se esté agotando.

— Mark S. Rasmussen

El comportamiento predeterminado en ASP.NET para FCN es atravesar toda la estructura de directorios. La clave de registro de HKLM \ Software \ Microsoft \ ASP.NET \ FCNMode puede ser 0, 1 o 2. 0 es el valor predeterminado que tiene un objeto FCN para cada carpeta. Si lo cambia a 2, usará un objeto para la raíz y todos los subdirectorios. El ajuste a 1 lo apaga por completo. support.microsoft.com/kb/911272 . También puede encontrar útil esta publicación de blog y discusión: weblogs.asp.net/owscott/archive/2006/02/21/ASP.NET-v2.0- 2D00 -AppDomain-recycles_2C00_-more-common-than-before.aspx .

— Scott Forsyth - MVP

1

¡quizás reinicie el servicio de estación de trabajo en el servidor de aplicaciones!

— Tony Roth
fuente

si realmente está perdiendo resolución de nombre, puede intentarlo como un experimento utilizando un archivo de hosts para cortocircuitar el proceso de resolución de nombre.

— tony Roth

Traté de reiniciar el servicio, no funcionó, pero luego reinicio el servidor y parece que funciona después de eso.

— Círculo Hsiao

0

He tenido casos como este antes, aunque no con un backend EMC. Para las aplicaciones de usuario, forzar el cierre de la conexión al servidor remoto y volver a abrirlo lo traerá de vuelta, aunque es posible que tenga que intentarlo un par de veces antes de que funcione. Para aplicaciones de servidor, el reciclaje del grupo de aplicaciones para ese servicio funciona. Si eso falla, reciclar el Servicio de estación de trabajo puede evitar un reinicio, pero es casi tan drástico.

— sysadmin1138
fuente

0

En la fuente:

¿Podría dar más detalles sobre el software instalado en el servidor de aplicaciones? En la red encontrará que generalmente es un problema con un AV, pero dado que no ejecuta ninguno ... ¿tal vez otra aplicación en modo kernel como un software de respaldo?

¿Está activo el firewall? ¿Ha verificado los registros de eventos en DC para el servidor de aplicaciones defectuoso?

También debe detectar el tráfico de red CIFS cuando surja el problema para ver qué sucede.

Las únicas veces que me encontré con este error fueron cuando el servidor / estación de trabajo de alguna manera "perdió" su enlace con el dominio. Reforzar la membresía de dominio hizo el truco (netdom / resetpwd). ¿Puede acceder a otros recursos compartidos de red (desde la sesión RDP al servidor de aplicaciones) cuando surge el problema?

— Renik
fuente

El único software que se ejecuta en el servidor es IIS que ejecuta una aplicación web .NET. El cortafuegos no está activo ya que está detrás de nuestra DMZ. Intentaré comprobar los registros de AD la próxima vez que ocurra. Un buen consejo con respecto a CIFS: intentaré agregar un LUN ISCSI la próxima vez también para ver si está relacionado solo con CIFS o si es un problema de conectividad general usando el nombre de host. Puedo acceder a todas las otras máquinas y recursos compartidos utilizando CIFS mientras se produce este error.

— Mark S. Rasmussen

0

¿Puede ser un problema con la resolución de nombres? ¿Puedes consultar con tu servidor DNS? Si eso no permite resolver el nombre y después de reiniciar su servidor de aplicaciones, le permitirá acceder.

Tuve el mismo problema cuando algunos usuarios de la estación de trabajo se quejan de que no pudieron acceder a la aplicación almacenada en otro servidor, hicimos lo mismo al tratar de acceder con server-ip que funcionaría pero no con el nombre, por lo que hemos verificado el DNS. Hemos realizado cambios en la Aplicación para acceder a otro servidor para usar la dirección IP ya que tenemos una red IP estática.

Avísame si mi sugerencia funciona para ti.

— maniargaurav
fuente

Mientras recibo el mensaje de error, puedo realizar un nslookup bien, devolviendo la IP correcta de nuestro AD DNS local. También puedo hacer ping usando el nombre de host y la dirección IP.

— Mark S. Rasmussen

0

Me encontré con un problema similar. No pude asignar un recurso compartido a Windows Server 2012 desde un servidor Windows 2003.

El grupo de red había implementado una política AD que había aislado las versiones inferiores de Windows a un contenedor AD que no permitía que una versión inferior de TLS se conectara a servidores que ejecutaban versiones superiores de TLS. Mover el servidor hacia atrás o deshabilitar la política para conectarse con una versión inferior de TLS corrigió este problema.

Aquí hay algunos errores que encontré en el registro del sistema:

El certificado recibido del servidor remoto fue emitido por una autoridad de certificación no confiable. Debido a esto, ninguno de los datos contenidos en el certificado puede ser validado. La solicitud de conexión SSL ha fallado. Los datos adjuntos contienen el certificado del servidor.

Se generó una alerta fatal y se envió al punto final remoto. Esto puede provocar la finalización de la conexión. El código de error fatal definido por el protocolo TLS es 48. El estado de error de SChannel de Windows es 552.

Espero que ayude a resolver su problema.

— info_tech
fuente