Partajare Windows: Numele de rețea specificat nu mai este disponibil (Administrarea sistemului, Windows Server 2008, Rețea De Stocare, Partajare Rețea, Unc)

Mark S. Rasmussen a intrebat.
a intrebat.

Avem o cutie SAN EMC NX4 care deservește un share CIFS pentru un număr de servere de aplicații Windows Server 2008 R2. Serverele de aplicații folosesc partajul CIFS pentru a servi o mulțime de fișiere imagine (~2500 de operații/secundă pe partaj), însă nici SAN, nici serverele de aplicații nu prezintă semne evidente de stres.

Din când în când, un server de aplicații va întrerupe, aparent dintr-o dată, conexiunea cu SAN. Orice cod .NET care încearcă să servească un fișier din SAN eșuează cu:

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

Dacă mă conectez prin RDP la serverul de aplicații și încerc să accesez „san-name” prin intermediul exploratorului, primesc aceeași eroare. Toate celelalte servere de aplicații îl pot accesa fără probleme. De asemenea, pot accesa „ip-de-san” perfect, ping-ul funcționează și el.

O repornire a serverului de aplicații rezolvă problema, dar aceasta este o măsură oarecum drastică pentru a rezolva problema, având în vedere că se pare că SAN-ul funcționează bine, iar computerul îl poate accesa – se pare doar că accesul la „san-name” a dat-o în bară.

Acest lucru s-a întâmplat la două servere de aplicații diferite în cursul săptămânii trecute, așa că nu bănuiesc că un singur server de aplicații ar fi cauza. Ignorând cauza pentru moment – cum aș putea restabili conexiunea „san-name” fără a reporni mașina? Și pot să interoghez cumva ce a mers prost?

Jurnalele de evenimente nu arată nimic (în afară de erorile ASP.NET aferente cauzate de problemă), nici pe serverele de aplicații, nici pe SAN.

Actualizare:
Pe baza sugestiilor, voi încerca data viitoare o repornire a serviciului Workstation și voi vedea dacă acest lucru rezolvă problema. Cu siguranță nu este o soluție, dar este mult mai rapid de făcut decât să repornesc întreaga mașină, așa cum am făcut în prezent. Există vreo modalitate de a întreba starea conexiunilor pe care le menține serviciul Workstation?

Actualizare 2:
Am confirmat că repornirea serviciului Workstation „rezolvă” problema. Următorul pas este să încerc modificarea reg pentru a mări valoarea MaxCmds. Nu voi putea confirma dacă aceasta este problema, pot doar să presupun dacă funcționează pentru o perioadă îndelungată fără probleme.

Comentarii

  • Există indicii în jurnalele de evenimente de pe serverele de aplicații, în special în jurnalul de sistem, care să indice fie o defecțiune tranzitorie, fie declanșarea unui alt mecanism (de exemplu, protecția DOS în LanManagerService, așa cum este descris aici)? blog.mreza.info/archive/2007/09/26/… ). De asemenea, ce configurație AV este în vigoare și cum este integrat Celerra în aceasta. –  > Por Helvick.
  • @Helvick Nu există intrări relevante în jurnalele de evenimente, nici în aplicație, nici în sistem. Nu rulăm AV nici pe servere și nici pe Celerra. Am căutat în jurnalul de evenimente și evenimentul de protecție DOS LanManagerService, dar nu am găsit nimic. –  > Por Mark S. Rasmussen.
6 răspunsuri
Scott Forsyth – MVP

Se pare că este vorba de MaxCmds s-au epuizat. Aici sunt două articole bune despre asta: aici și aici.

Iată cum să o schimbăm acum. Creați un fișier numit update.reg și plasați următoarele în el:

Windows Registry Editor Version 5.00 

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceslanmanworkstationparameters] 
"MaxCmds"=dword:00000800 

Salvați și apoi faceți dublu clic și acceptați solicitarea. Este necesară o repornire.

Comentarii

  • Din moment ce recompensa este pe cale să se termine, o voi acorda răspunsului tău de până acum, deoarece este cel mai bun pariu imho, deși va trebui să o testez înainte de a accepta. Am modificat anterior FCNMode pentru a înregistra doar directorul bin, deoarece am avut erori de tip „bios command limit reached” pe unele dintre aplicațiile găzduite pe o altă partajare UNC. Dar presupun că setarea FCNMode nu afectează directoare în afara directorului de aplicații. –  > Por Mark S. Rasmussen.
  • FCNMode poate ajuta, de asemenea, dar o structură de discuri mari peste UNC le poate face pe amândouă să intre în joc. Eu „cred” că FCN este împotriva întregului arbore de directoare pentru .NET 2.0 și versiunile ulterioare. –  > Por Scott Forsyth – MVP.
  • Mai mult decât atât: Am văzut cum MaxCmds se epuizează cu mai multe noduri front-end și mai mulți utilizatori utilizați pentru diferite dosare. MaxCmds este o setare pe care o aplic la toate webfarmele mele UNC. Nu am văzut niciodată un dezavantaj la această schimbare. Există și o setare pentru server dacă ținta partajului CIFS este un server Windows, dar aceasta nu se aplică în cazul dumneavoastră. –  > Por Scott Forsyth – MVP.
  • Doar pentru a-mi clarifica comentariul, aplicațiile .NET reale sunt stocate pe discul local. Scopul principal al aplicațiilor este de a servi date de imagine, care sunt stocate pe partaje UNC. Setarea FCNMode, din câte am înțeles, se aplică doar directorului de aplicații, neavând astfel niciun impact în cazul meu. Totuși, MaxCmds este încă un posibil vinovat. Toate aplicațiile rulează sub același cont, dar cu peste 500 de aplicații web pe fiecare server, este posibil să rămân fără. –  > Por Mark S. Rasmussen.
  • Comportamentul implicit în ASP.NET pentru FCN este de a traversa întreaga structură de directoare. Cheia de registru HKLMSoftwareMicrosoftASP.NETFCNMode poate fi 0, 1 sau 2. 0 este valoarea implicită, care are un obiect FCN pentru fiecare dosar. Dacă o modificați la 2, atunci se va folosi un singur obiect pentru rădăcină și pentru toate subdirectoarele. Setarea la 1 îl dezactivează complet. support.microsoft.com/kb/911272. S-ar putea să vă fie de ajutor și această postare pe blog și discuția: weblogs.asp.net/owscott/archive/2006/02/21/ASP.NET-v2.0-2D00-AppDomain-recycles_2C00_-more-common-than-before.aspx. –  > Por Scott Forsyth – MVP.
tony roth

poate reporniți serviciul stației de lucru pe serverul de aplicații!

Comentarii

  • dacă într-adevăr pierde rezoluția numelui, puteți încerca, ca experiment, să folosiți un fișier hosts pentru a scurtcircuita procesul de rezoluție a numelui. –  > Por tony roth.
  • Am încercat să repornesc serviciul, nu a funcționat, dar apoi am repornit serverul și pare să funcționeze după aceea. –  > Por Circle Hsiao.
sysadmin1138

Am mai avut cazuri de acest gen, deși nu cu un back-end EMC. Pentru aplicațiile userland, închiderea forțată a conexiunii la serverul de la distanță și redeschiderea acesteia îl va readuce la normal, deși este posibil să trebuiască să încercați de câteva ori până când își va reveni. Pentru aplicațiile serverland, reciclarea Pool-ului de aplicații pentru serviciul respectiv funcționează. Dacă acest lucru nu reușește, reciclarea serviciului Workstation Service poate evita repornirea, dar este aproape la fel de drastică.

Renik

Pe sursa :

Ați putea da mai multe detalii despre software-ul instalat pe serverul de aplicații ? Pe net veți găsi că de obicei este o problemă cu un AV, dar din moment ce nu rulați niciunul… poate o altă aplicație în modul kernel, cum ar fi un software de backup ?

Este activ firewall-ul? Ați verificat jurnalele de evenimente de pe DC pentru serverul de aplicații defect?

Ar trebui, de asemenea, să adulmecați traficul de rețea CIFS atunci când apare problema pentru a vedea ce se întâmplă.

Singurele dăți în care am întâlnit această eroare au fost atunci când serverul/stația de lucru și-a „pierdut” cumva legătura cu domeniul. Reforțarea apartenenței la domeniu a rezolvat problema (netdom /resetpwd). Puteți accesa alte partaje de rețea (din sesiunea RDP către serverul de aplicații) atunci când apare problema?

Comentarii

  • Singurul software care rulează pe server este IIS, care rulează o aplicație web .NET. Firewall-ul nu este activ, deoarece acesta se află în spatele DMZ-ului nostru. Voi încerca să verific jurnalele AD data viitoare când se va întâmpla acest lucru. Un sfat bun în ceea ce privește CIFS – voi încerca să adaug și eu un LUN ISCSI data viitoare pentru a vedea dacă este legat doar de CIFS sau dacă este o problemă generală de conectivitate folosind numele de gazdă. Pot să accesez toate celelalte mașini & partaje folosind CIFS în timp ce apare această eroare. –  > Por Mark S. Rasmussen.
maniargaurav

Poate fi aceasta o problemă cu rezoluția numelui. Puteți verifica cu serverul DNS? Dacă acesta nu permite rezolvarea numelui și după repornirea serverului de aplicații, acesta va permite accesul.

Am avut aceeași problemă atunci când un utilizator al unei stații de lucru s-a plâns că nu poate accesa aplicația stocată pe un alt server, am făcut același lucru încercând să accesăm cu server-ip, care a funcționat, dar nu și cu numele, așa că am verificat DNS. Am modificat aplicația pentru a accesa un alt server folosind adresa IP, deoarece avem o rețea IP statică.

Anunțați-mă dacă sugestia mea funcționează pentru dumneavoastră.

Comentarii

  • Deși primesc mesajul de eroare, pot efectua un nslookup foarte bine, returnând IP-ul corect de la DNS-ul nostru AD local. De asemenea, pot face ping folosind atât numele de gazdă, cât și adresa IP. –  > Por Mark S. Rasmussen.
info_tech

M-am confruntat cu o problemă similară. Nu am reușit să mapez un share pe Windows Server 2012 de pe un server Windows 2003.

Grupul de rețea a implementat o politică AD care a izolat versiunile mai mici de Windows într-un container AD care nu permitea ca versiunea mai mică de TLS să se conecteze la serverele care rulează versiuni mai mari de TLS. Mutarea serverului înapoi sau dezactivarea politicii de conectare cu o versiune inferioară de TLS a corectat această problemă.

Iată câteva erori pe care le-am întâlnit în jurnalul sistemului:

Certificatul primit de la serverul la distanță a fost emis de o autoritate de certificare care nu este de încredere. Din acest motiv, niciuna dintre datele conținute în certificat nu poate fi validată. Solicitarea de conectare SSL a eșuat. Datele atașate conțin certificatul serverului.

A fost generată și trimisă o alertă fatală către punctul final la distanță. Acest lucru poate duce la întreruperea conexiunii. Codul de eroare fatală definit de protocolul TLS este 48. Starea de eroare Windows SChannel este 552.

Sper că vă ajută să vă rezolvați problema.