Partage Windows: le nom de réseau spécifié n'est plus disponible

8

Nous avons un boîtier SAN EMC NX4 servant un partage CIFS à un certain nombre de serveurs d'applications Windows Server 2008 R2. Les serveurs d'applications utilisent le partage CIFS pour servir de nombreux fichiers d'images (~ 2500 opérations / s sur le partage), mais ni le SAN ni les serveurs d'applications ne montrent de signes évidents de stress.

De temps en temps, un serveur d'applications interrompra, apparemment tout d'un coup, la connexion au SAN. Tout code .NET essayant de servir un fichier à partir du SAN échoue avec:

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

Si je RDP vers le serveur d'applications et que j'essaie d'accéder à "\ san-name" via l'explorateur, j'obtiens la même erreur. Tous les autres serveurs d'applications peuvent y accéder très bien. Je peux également accéder à "\ ip-of-san" parfaitement, le ping fonctionne également.

Un redémarrage du serveur d'application résout le problème, mais c'est une mesure quelque peu radicale du problème, étant donné qu'il semble que le SAN fonctionne correctement et que l'ordinateur peut y accéder - il semble que l'accès "\ san-name" ait grondé.

Cela est arrivé à deux serveurs d'applications différents au cours de la semaine dernière, donc je ne soupçonne pas qu'un seul serveur d'applications en soit la cause. Ignorer la cause pour l'instant - comment restaurer la connexion "\ san-name" sans redémarrer la machine? Et puis-je en quelque sorte demander ce qui ne va pas?

Les journaux d'événements ne montrent rien (à part les erreurs ASP.NET associées causées par le problème), ni sur les serveurs d'applications ni sur le SAN.

Mise à jour:
Sur la base des suggestions, je vais essayer de redémarrer le service Workstation la prochaine fois et voir si cela résout le problème. Certainement pas un correctif, mais beaucoup plus rapide à faire que de redémarrer la machine entière comme je le fais actuellement. Est-il possible d'interroger l'état des connexions gérées par le service Station de travail?

Mise à jour 2: a
confirmé que le redémarrage du service Workstation "résout" le problème. L'étape suivante consiste à essayer le changement de reg pour augmenter la valeur MaxCmds. Ne sera pas en mesure de confirmer si c'est le problème, ne peut supposer que s'il fonctionne pendant une longue période sans problèmes.

— Mark S. Rasmussen
source

Y a-t-il des indications dans les journaux d'événements sur les serveurs d'applications, en particulier dans le journal système, qui indiquent soit une défaillance transitoire, soit un autre mécanisme déclenché (par exemple, une protection DOS dans LanManagerService comme décrit ici blog.mreza.info/archive/ 2007/09/26 /… ). Aussi quelle configuration AV est en place et comment le Celerra est-il intégré à cela.

— Helvick

@Helvick Aucune entrée pertinente dans les journaux d'événements, ni application ni système. Nous n'exécutons pas AV ni sur les serveurs ni sur la Celerra. J'ai également cherché dans le journal des événements l'événement de protection DOS LanManagerService, mais il est revenu vide.

— Mark S. Rasmussen

7

Cela ressemble à ce que les MaxCmds sont épuisés. Voici deux bons articles à ce sujet: ici et ici .

Voici maintenant pour le changer. Créez un fichier appelé update.reg et placez-y les éléments suivants:

Windows Registry Editor Version 5.00 

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

Enregistrez, puis double-cliquez et acceptez l'invite. Un redémarrage est nécessaire.

— Scott Forsyth - MVP
source

Étant donné que la prime est sur le point de s'épuiser, je vais l'attribuer à votre réponse dans la mesure où c'est le meilleur pari à mon humble avis, bien que je devrai le tester avant d'accepter. J'ai précédemment modifié le FCNMode pour enregistrer uniquement le répertoire bin car j'avais des erreurs "limite de commande bios atteinte" sur certaines des applications hébergées sur un autre partage UNC. Mais je suppose que le paramètre FCNMode n'affecte pas les répertoires en dehors du répertoire d'application.

— Mark S. Rasmussen

Le FCNMode peut également aider, mais une grande structure de disque sur UNC, ils peuvent faire jouer les deux. Je «crois» que FCN est contre toute l'arborescence de répertoires pour .NET 2.0 et supérieur.

— Scott Forsyth - MVP

De plus: j'ai vu les MaxCmds s'épuiser avec plusieurs nœuds frontaux et plusieurs utilisateurs utilisés pour différents dossiers. Le MaxCmds est un paramètre que j'applique à toutes mes fermes Web UNC. Je n'ai jamais vu d'inconvénient à ce changement. Il existe également un paramètre de serveur si la cible de partage CIFS est un serveur Windows, mais cela ne s'applique pas à vous.

— Scott Forsyth - MVP

Juste pour clarifier mon commentaire, les applications .NET réelles sont stockées sur le disque local. Le but principal des applications est de servir des données d'image, qui sont stockées sur des partages UNC. Si je comprends bien, le paramètre FCNMode s'applique uniquement au répertoire d'application, n'ayant donc aucun impact dans mon cas. MaxCmds est toujours un coupable possible. Toutes les applications s'exécutent sous le même compte, mais avec plus de 500 applications Web sur chaque serveur, il est probable que j'en manque.

— Mark S. Rasmussen

Le comportement par défaut dans ASP.NET pour FCN consiste à parcourir l'intégralité de la structure de répertoires. La clé de Registre HKLM \ Software \ Microsoft \ ASP.NET \ FCNMode peut être 0, 1 ou 2. 0 est la valeur par défaut qui a un objet FCN pour chaque dossier. Si vous le changez en 2, il utilisera un objet pour la racine et tous les sous-répertoires. Le réglage sur 1 le désactive complètement. support.microsoft.com/kb/911272 . Vous pouvez également trouver cet article de blog et cette discussion utiles: 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

peut-être redémarrer le service de poste de travail sur le serveur d'applications!

— Tony Roth
source

si sa résolution de nom est vraiment perdante, vous pouvez essayer comme expérience en utilisant un fichier d'hôtes pour court-circuiter le processus de résolution de nom.

— tony roth

J'ai essayé de redémarrer le service, cela n'a pas fonctionné, mais j'ai redémarré le serveur et cela semble fonctionner après cela.

— Circle Hsiao

0

J'ai eu des cas comme celui-ci auparavant, mais pas avec un back-end EMC. Pour les applications utilisateur, la fermeture forcée de la connexion au serveur distant et sa réouverture le ramèneront, bien que vous deviez peut-être essayer plusieurs fois avant qu'il ne fonctionne. Pour les applications Serverland, le recyclage du pool d'applications pour ce service fonctionne. Si cela échoue, le recyclage du service Workstation peut éviter un redémarrage, mais c'est presque aussi radical.

— sysadmin1138
source

0

Sur la source:

Pourriez-vous donner plus de détails sur le logiciel installé sur le serveur d'applications? Sur le net, vous constaterez que c'est généralement un problème avec un AV, mais puisque vous n'en exécutez pas ... peut-être une autre application en mode noyau comme un logiciel de sauvegarde?

Le pare-feu est-il actif? Avez-vous vérifié les journaux d'événements sur le contrôleur de domaine pour le serveur d'applications défectueux?

Vous devez également renifler le trafic réseau CIFS lorsque le problème survient pour voir ce qui se passe.

Les seules fois où j'ai rencontré cette erreur ont été lorsque le serveur / poste de travail "perdait" en quelque sorte son lien avec le domaine. Le re-forçage de l'appartenance au domaine a fait l'affaire (netdom / resetpwd). Pouvez-vous accéder à d' autres partages réseau (de la session RDP au serveur d'applications) lorsque le problème survient?

— Renik
source

Le seul logiciel exécuté sur le serveur est IIS exécutant une application Web .NET. Le pare-feu n'est pas actif car il se trouve derrière notre DMZ. Je vais essayer de vérifier les journaux AD la prochaine fois que cela se produit. Bon conseil concernant CIFS - J'essaierai également d'ajouter un LUN ISCSI la prochaine fois pour voir s'il est lié uniquement à CIFS ou s'il s'agit d'un problème de connectivité général en utilisant le nom d'hôte. Je peux accéder à toutes les autres machines et partages à l'aide de CIFS pendant que cette erreur se produit.

— Mark S. Rasmussen

0

Cela peut-il être un problème de résolution de nom. Pouvez-vous vérifier avec votre serveur DNS? Si cela ne permet pas de résoudre le nom et après le redémarrage de votre serveur d'applications, cela permettrait d'accéder.

J'ai eu le même problème lorsque certains utilisateurs de postes de travail se plaignent de ne pas pouvoir accéder à l'application stockée sur un autre serveur, nous avons fait la même chose en essayant d'accéder avec server-ip qui fonctionnerait mais pas avec le nom, nous avons donc vérifié DNS. Nous avons modifié l'application pour accéder à un autre serveur en utilisant l'adresse IP car nous avons un réseau IP statique.

Faites-moi savoir si ma suggestion vous convient.

— maniargaurav
source

Pendant que je reçois le message d'erreur, je peux effectuer une nslookup très bien, en renvoyant l'IP correcte à partir de notre DNS AD local. Je peux également envoyer une requête ping en utilisant à la fois le nom d'hôte et l'adresse IP.

— Mark S. Rasmussen

0

J'ai rencontré un problème similaire. Je n'ai pas pu mapper un partage sur Windows Server 2012 à partir d'un serveur Windows 2003.

Le groupe réseau avait mis en œuvre une stratégie AD qui avait isolé les versions de fenêtres inférieures dans un conteneur AD qui ne permettait pas à la version inférieure de TLS de se connecter aux serveurs exécutant des versions supérieures de TLS. Le déplacement du serveur en arrière ou la désactivation de la stratégie pour se connecter avec une version inférieure de TLS a corrigé ce problème.

Voici quelques erreurs que j'ai rencontrées dans le journal système:

Le certificat reçu du serveur distant a été émis par une autorité de certification non approuvée. Pour cette raison, aucune des données contenues dans le certificat ne peut être validée. La demande de connexion SSL a échoué. Les données jointes contiennent le certificat du serveur.

Une alerte fatale a été générée et envoyée au point de terminaison distant. Cela peut entraîner la fin de la connexion. Le code d'erreur fatale défini par le protocole TLS est 48. L'état d'erreur Windows SChannel est 552.

J'espère que cela vous aidera à résoudre votre problème.

— info_tech
source