Windows-Freigabe: Der angegebene Netzwerkname ist nicht mehr verfügbar

8

Wir haben eine EMC NX4 SAN-Box, die eine CIFS-Freigabe für eine Reihe von Windows Server 2008 R2-App-Servern bereitstellt. Die App-Server verwenden die CIFS-Freigabe, um viele Bilddateien bereitzustellen (~ 2500 Ops / Sek. Auf der Freigabe). Weder das SAN noch die App-Server weisen jedoch offensichtliche Anzeichen von Stress auf.

Hin und wieder wird ein App-Server anscheinend plötzlich die Verbindung zum SAN trennen. Jeder .NET-Code, der versucht, eine Datei aus dem SAN bereitzustellen, schlägt fehl mit:

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

Wenn ich RDP zum App-Server verwende und versuche, über den Explorer auf "\ san-name" zuzugreifen, wird der gleiche Fehler angezeigt. Alle anderen App-Server können problemlos darauf zugreifen. Ich kann auch perfekt auf "\ ip-of-san" zugreifen, Ping funktioniert auch.

Ein Neustart des App-Servers behebt das Problem, aber das ist eine etwas drastische Maßnahme für das Problem, da das SAN anscheinend einwandfrei funktioniert und der Computer darauf zugreifen kann - es sieht nur so aus, als hätte der Zugriff "\ san-name" barfed up.

Dies ist in der letzten Woche zwei verschiedenen App-Servern passiert, daher vermute ich nicht, dass ein einzelner App-Server die Ursache ist. Die Ursache vorerst ignorieren - wie würde ich die Verbindung "\ san-name" wiederherstellen, ohne den Computer neu zu starten? Und kann ich irgendwie abfragen, was schief gelaufen ist?

Ereignisprotokolle zeigen nichts (außer verwandten ASP.NET-Fehlern, die durch das Problem verursacht wurden), weder auf App-Servern noch im SAN.

Update:
Basierend auf den Vorschlägen werde ich beim nächsten Mal einen Neustart des Workstation-Dienstes versuchen und prüfen, ob dies das Problem behebt. Auf jeden Fall kein Fix, aber viel schneller als den gesamten Computer neu zu starten, wie ich es derzeit getan habe. Gibt es eine Möglichkeit, den Status der Verbindungen abzufragen, die der Workstation-Dienst verwaltet?

Update 2: Es wurde
bestätigt, dass durch einen Neustart des Workstation-Dienstes das Problem "behoben" wird. Der nächste Schritt besteht darin, die Reg-Änderung zu versuchen, um den MaxCmds-Wert zu erhöhen. Kann nicht bestätigen, ob es sich um das Problem handelt, kann nur annehmen, wenn es über einen längeren Zeitraum ohne Probleme ausgeführt wird.

— Mark S. Rasmussen
quelle

Gibt es in den Ereignisprotokollen auf den App-Servern Hinweise, insbesondere im Systemprotokoll, die darauf hinweisen, dass entweder ein vorübergehender Fehler oder ein anderer Mechanismus ausgelöst wird (z. B. DOS-Schutz im LanManagerService, wie hier beschrieben blog.mreza.info/archive/). 2007/09/26 /… ). Außerdem, welches AV-Setup vorhanden ist und wie das Celerra darin integriert ist.

— Helvick

@Helvick Keine relevanten Einträge in Ereignisprotokollen, weder App noch System. Wir führen AV weder auf den Servern noch auf dem Celerra aus. Ich habe das Ereignisprotokoll auch nach dem LanManagerService DOS-Schutzereignis durchsucht, aber es war wieder leer.

— Mark S. Rasmussen

7

Das hört sich so an, als wären die MaxCmds ausgegangen. Hier sind zwei gute Artikel dazu: hier und hier .

Hier ist jetzt, um es zu ändern. Erstellen Sie eine Datei mit dem Namen update.reg und platzieren Sie Folgendes darin:

Windows Registry Editor Version 5.00 

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

Speichern und dann doppelklicken und die Eingabeaufforderung akzeptieren. Ein Neustart ist erforderlich.

— Scott Forsyth - MVP
quelle

Da das Kopfgeld bald aufgebraucht ist, werde ich es Ihrer Antwort zuweisen, sofern es die beste Wette imho ist, obwohl ich es testen muss, bevor ich es akzeptiere. Ich habe zuvor den FCNMode so geändert, dass nur das bin-Verzeichnis registriert wird, da bei einigen Apps, die auf einer anderen UNC-Freigabe gehostet werden, Fehler "BIOS-Befehlslimit erreicht" aufgetreten sind. Aber ich denke, die FCNMode-Einstellung wirkt sich nicht auf Verzeichnisse außerhalb des Anwendungsverzeichnisses aus.

— Mark S. Rasmussen

Der FCNMode kann ebenfalls helfen, aber bei einer großen Festplattenstruktur über UNC können beide ins Spiel kommen. Ich 'glaube', dass FCN gegen den gesamten Verzeichnisbaum für .NET 2.0 und höher ist.

— Scott Forsyth - MVP

Darüber hinaus: Ich habe gesehen, dass die MaxCmds mit mehreren Front-End-Knoten und mehreren Benutzern, die für verschiedene Ordner verwendet werden, erschöpft sind. Die MaxCmds ist eine Einstellung, die ich auf alle meine UNC-Webfarms anwende. Ich habe noch nie einen Nachteil dieser Änderung gesehen. Es gibt auch eine Servereinstellung, wenn das CIFS-Freigabeziel ein Windows-Server ist, dies gilt jedoch nicht für Sie.

— Scott Forsyth - MVP

Um meinen Kommentar zu verdeutlichen, werden die tatsächlichen .NET-Anwendungen auf der lokalen Festplatte gespeichert. Der Hauptzweck der Apps besteht darin, Bilddaten bereitzustellen, die auf UNC-Freigaben gespeichert sind. Die FCNMode-Einstellung gilt meines Wissens nur für das Anwendungsverzeichnis und hat daher in meinem Fall keine Auswirkungen. MaxCmds ist jedoch immer noch ein möglicher Schuldiger. Alle Apps werden unter demselben Konto ausgeführt, aber mit mehr als 500 Web-Apps auf jedem Server ist es wahrscheinlich, dass mir die Apps ausgehen.

— Mark S. Rasmussen

Das Standardverhalten in ASP.NET für FCN besteht darin, die gesamte Verzeichnisstruktur zu durchlaufen. Der Registrierungsschlüssel von HKLM \ Software \ Microsoft \ ASP.NET \ FCNMode kann 0, 1 oder 2 sein. 0 ist die Standardeinstellung, die für jeden Ordner ein FCN-Objekt enthält. Wenn Sie es in 2 ändern, wird ein Objekt für das Stammverzeichnis und alle Unterverzeichnisse verwendet. Bei Einstellung auf 1 wird es vollständig ausgeschaltet. support.microsoft.com/kb/911272 . Möglicherweise finden Sie diesen Blog-Beitrag und die Diskussion auch hilfreich: 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

Starten Sie möglicherweise den Workstation-Dienst auf dem App-Server neu!

— Tony Roth
quelle

Wenn die Namensauflösung wirklich verloren geht, können Sie als Experiment versuchen, mithilfe einer Hosts-Datei den Namensauflösungsprozess kurzzuschließen.

— Tony Roth

Ich habe versucht, den Dienst neu zu starten, habe nicht funktioniert, aber dann habe ich den Server neu gestartet und es scheint danach zu funktionieren.

— 為元

0

Ich hatte schon einmal solche Fälle, allerdings nicht mit einem EMC-Backend. Wenn Sie für Userland-Anwendungen die Verbindung zum Remote-Server erzwingen und erneut öffnen, wird sie wiederhergestellt. Möglicherweise müssen Sie dies jedoch einige Male versuchen, bevor die Verbindung hergestellt werden kann. Bei Serverland-Anwendungen funktioniert das Recycling des Anwendungspools für diesen Dienst. Wenn dies fehlschlägt, kann durch das Recycling des Workstation-Dienstes ein Neustart vermieden werden, der jedoch fast genauso drastisch ist.

— sysadmin1138
quelle

0

Auf der Quelle:

Können Sie weitere Details zu der auf dem Apps-Server installierten Software angeben? Im Internet werden Sie feststellen, dass es normalerweise ein Problem mit einem AV ist, aber da Sie keine ausführen ... vielleicht eine andere Kernel-Modus-App wie eine Backup-Software?

Ist die Firewall aktiv? Haben Sie die Ereignisprotokolle auf dem DC auf den fehlerhaften App-Server überprüft?

Sie sollten auch den CIFS-Netzwerkverkehr abhören, wenn das Problem auftritt, um zu sehen, was passiert.

Ich bin nur dann auf diesen Fehler gestoßen, wenn der Server / die Workstation irgendwie die Verbindung zur Domäne "verloren" hat. Das Erzwingen der Domain-Mitgliedschaft hat den Trick gemacht (netdom / resetpwd). Können Sie auf andere Netzwerkfreigaben zugreifen (von der RDP-Sitzung zum App-Server), wenn das Problem auftritt?

— Renik
quelle

Die einzige Software, die auf dem Server ausgeführt wird, ist IIS, auf dem eine .NET-Webanwendung ausgeführt wird. Die Firewall ist nicht aktiv, da sich diese hinter unserer DMZ befindet. Ich werde versuchen, die AD-Protokolle beim nächsten Mal zu überprüfen. Guter Tipp zu CIFS - Ich werde auch beim nächsten Mal versuchen, eine ISCSI-LUN hinzuzufügen, um festzustellen, ob es sich nur um CIFS handelt oder ob es sich um ein allgemeines Konnektivitätsproblem bei Verwendung des Hostnamens handelt. Ich kann mit CIFS auf alle anderen Computer und Freigaben zugreifen, während dieser Fehler auftritt.

— Mark S. Rasmussen

0

Kann dies ein Problem mit der Namensauflösung sein? Können Sie sich bei Ihrem DNS-Server erkundigen? Wenn dies nicht zulässt, dass der Name aufgelöst wird, und nach dem Neustart Ihres App-Servers der Zugriff möglich ist.

Ich hatte das gleiche Problem, als sich einige Workstation-Benutzer beschwerten, dass sie nicht auf Anwendungen zugreifen konnten, die auf einem anderen Server gespeichert waren. Wir hatten das gleiche getan, indem wir versucht hatten, mit einer Server-IP zuzugreifen, die funktionieren würde, aber nicht mit Namen, also haben wir DNS überprüft. Wir haben in der Anwendung Änderungen vorgenommen, um auf einen anderen Server zuzugreifen und die IP-Adresse zu verwenden, da wir über ein statisches IP-Netzwerk verfügen.

Lassen Sie mich wissen, ob mein Vorschlag für Sie funktioniert.

— maniargaurav
quelle

Während ich die Fehlermeldung erhalte, kann ich ein nslookup problemlos durchführen und die richtige IP von unserem lokalen AD-DNS zurückgeben. Ich kann auch sowohl mit dem Hostnamen als auch mit der IP-Adresse pingen.

— Mark S. Rasmussen

0

Ich bin auf ein ähnliches Problem gestoßen. Ich konnte Windows Server 2012 keine Freigabe von einem Windows 2003-Server zuordnen.

Die Netzwerkgruppe hatte eine AD-Richtlinie implementiert, die die unteren Windows-Versionen in einen AD-Container isoliert hatte, der es der niedrigeren TLS-Version nicht ermöglichte, eine Verbindung zu Servern herzustellen, auf denen höhere TLS-Versionen ausgeführt wurden. Durch Zurücksetzen des Servers oder Deaktivieren der Richtlinie für die Verbindung mit einer niedrigeren TLS-Version wurde dieses Problem behoben.

Hier sind einige Fehler, auf die ich im Systemprotokoll gestoßen bin:

Das vom Remoteserver empfangene Zertifikat wurde von einer nicht vertrauenswürdigen Zertifizierungsstelle ausgestellt. Aus diesem Grund kann keine der im Zertifikat enthaltenen Daten validiert werden. Die SSL-Verbindungsanforderung ist fehlgeschlagen. Die angehängten Daten enthalten das Serverzertifikat.

Eine schwerwiegende Warnung wurde generiert und an den Remote-Endpunkt gesendet. Dies kann zur Beendigung der Verbindung führen. Der vom TLS-Protokoll definierte schwerwiegende Fehlercode ist 48. Der Windows SChannel-Fehlerstatus lautet 552.

Hoffe, es hilft, Ihr Problem zu lösen.

— info_tech
quelle