sviluppo-web-qa.it

Lunga pausa durante l'accesso allo spazio dei nomi DFS

Di recente abbiamo migrato la nostra rete Windows per utilizzare DFS per i file condivisi. DFS funziona bene, tranne per un fastidioso problema: gli utenti riscontrano un ritardo significativo quando provano ad accedere a uno spazio dei nomi DFS a cui non hanno avuto accesso per un po 'di tempo. Ho provato a risolvere il problema, ma finora non ho avuto successo, e speravo che qualcuno qui potesse avere alcuni suggerimenti per aiutare a risolvere il problema.

Innanzitutto, alcuni retroscena sulla nostra rete:

La rete utilizza un dominio Active Directory a livello funzionale Windows 2008 con due controller di dominio Windows 2008 e due server DNS (uno su ciascuno dei controller di dominio). La rete è solo DNS - nessun WINS. Tutti i computer si trovano nello stesso sito e collegati tramite Gigabit Ethernet. Abbiamo circa 20 spazi dei nomi DFS basati su dominio in modalità Windows 2008 e ogni spazio dei nomi DFS ha due server dello spazio dei nomi DFS di Windows 2008 (gli stessi due server per tutti gli spazi dei nomi). Tutti i server dello spazio dei nomi sono in modalità FQDN e tutte le destinazioni delle cartelle sono specificate usando il loro FQDN. Tutti i computer sono aggiornati con Service Pack e patch.

Le destinazioni delle cartelle effettive (ovvero le condivisioni SMB condivise dalle nostre cartelle DFS) sono distribuite su più file e server applicazioni, tutti con Windows 2008 che barra due server applicazioni che eseguono Windows 2003 R2, senza alcuna configurazione di replica (ad es. tutte le cartelle DFS hanno attualmente solo una destinazione cartella).

Qualche dettaglio in più sul problema:

Il ritardo di accesso allo spazio dei nomi è generalmente compreso tra 1 e 10 secondi e sembra verificarsi quando un determinato computer non ha avuto accesso allo spazio dei nomi richiesto per circa cinque minuti o più.

Ad esempio, se l'utente non ha avuto accesso a \\ domain.name\namespace1\per più di cinque minuti e ha tentato di accedere a \\ domain.name\namespace1\tramite Esplora risorse, la finestra di Explorer si bloccherà per 1 - 10 secondi prima che finalmente riprendere e visualizzare le cartelle esistenti in \\ domain.name\namespace1. Se poi chiudono la finestra di Explorer e tentano di accedere nuovamente a \\ domain.name\namespace1\entro cinque minuti, i contenuti verranno visualizzati quasi istantaneamente - se aspettano più di cinque minuti, passeranno di nuovo la pausa di 1 - 10 secondi.

Una volta "dentro" lo spazio dei nomi tutto è bello e scattante, è solo la connessione iniziale allo spazio dei nomi che è lenta.

I ritardi nella navigazione sembrano influenzare tutte le varianti di Windows che utilizziamo (Windows 2008 x64 SP2, Windows 2003 R2 x86 SP2, Windows XP Pro x86 SP3) - è probabilmente un po 'peggio in Windows XP/2003 rispetto a Windows 2008, ma non sono sicuro che la differenza non sia solo psicologica.

L'accesso ai target delle cartelle sottostanti non mostra direttamente alcun ritardo, ovvero se si accede direttamente alle condivisioni SMB indicate da DFS (ignorando DFS), non vi è alcuna pausa.

Durante la risoluzione dei problemi ho notato che la "Durata della cache" per tutte le nostre radici DFS è impostata su 300 secondi - 5 minuti. Dato che questo è lo stesso tempo necessario per innescare la pausa, presumo che questa memorizzazione nella cache sia in qualche modo correlata, anche se non sono sicuro di cosa sia memorizzato nella cache sul client e quindi di cosa debba essere cercato nuovamente dopo che sono trascorsi 5 minuti.

Nel tentativo di risolvere il problema ho già provato/verificato quanto segue (senza successo):

  • Esegui dcdiag su entrambi i controller di dominio - non sono stati rilevati problemi
  • Eseguito alcuni controlli di base del server DNS senza trovare alcun problema: non so come controllare in dettaglio i server DNS, ma aggiungerei che la rete non presenta altri comportamenti strani che potrebbero indicare un problema DNS
  • Anti-virus disabilitato su client e server
  • Rimozione di uno dei server dello spazio dei nomi da un paio di spazi dei nomi - nessuna differenza

Quindi è lì che sto facendo - e sono senza idee. Qualcuno può suggerire cosa potrebbe causare i ritardi e/o cosa dovrei provare dopo?

22
Matt

Bene, noi finalmente sembra aver risolto questo problema nel nostro ambiente. Per i vantaggi degli altri, ecco cosa abbiamo scoperto e come abbiamo risolto il problema:

Per cercare di ottenere ulteriori informazioni su ciò che stava accadendo prima/durante/dopo i ritardi, abbiamo utilizzato Wireshark su un computer client per acquisire/analizzare il traffico di rete mentre quel client ha tentato di accedere a una condivisione DFS.

Queste acquisizioni hanno mostrato qualcosa di strano: ogni volta che si è verificato il ritardo, tra la richiesta DFS inviata dal client a un controller di dominio e il riferimento a un server root DFS che ritorna da DC al client , il DC stava inviando diverse ricerche di nomi di broadcast alla rete.

Innanzitutto, il DC trasmetterà una ricerca NetBIOS per DOMAIN (dove DOMAIN è il nostro nome di dominio Active Directory pre-Windows 2000). Pochi secondi dopo, trasmetterà un LLMNR ricerca per DOMAIN. A questo seguirà un'altra trasmissione NetBios per DOMAIN. Dopo che queste tre ricerche sono state trasmesse (e presumo scaduto) il DC avrebbe infine risposto al client con un riferimento (corretto) a un server root DFS.

Queste ricerche di nomi di trasmissione per DOMAIN venivano inviate solo quando si verificava il lungo ritardo nell'apertura di una condivisione DFS e dalla cattura di Wireshark si vedeva chiaramente che DC non restituiva un riferimento a un DFS server root fino a quando non sono state inviate tutte e tre le ricerche (e sono trascorsi ~ 7 secondi). Quindi, queste ricerche dei nomi delle trasmissioni sono state ovviamente la causa dei nostri ritardi.

Ora che sapevamo quale fosse il problema, abbiamo iniziato a cercare di capire perché si stavano verificando queste ricerche dei nomi delle trasmissioni. Dopo un po 'più di Google e alcuni tentativi, abbiamo trovato la nostra risposta: non avevamo impostato la chiave di registro DfsDnsConfig sui nostri controller di dominio su 1, come è necessario quando si utilizza DFS in un ambiente solo DNS.

Quando inizialmente abbiamo installato DFS nel nostro ambiente, abbiamo letto i vari articoli su come configurare DFS per un ambiente solo DNS (ad es. Microsoft KB24438 e altri) ed erano a conoscenza di questa chiave di registro, ma avevano frainteso le istruzioni su quando/come usarlo.

KB244380 dice:

La chiave del Registro di sistema DFSDnsConfig deve essere aggiunta a ciascun server che parteciperà allo spazio dei nomi DFS affinché tutti i computer possano comprendere nomi completi.

Pensavamo che ciò significasse che la chiave del Registro di sistema doveva essere impostata solo sui server DFS dei namespace , non rendendoci conto che era richiesta anche sui controller di dominio. Dopo aver impostato DfsDnsConfig su 1 sui nostri controller di dominio (e riavviato il servizio "Spazio dei nomi DFS"), il problema è svanito.

Ovviamente siamo contenti di questo risultato, ma aggiungerei che non sono ancora convinto al 100% che questo è il nostro unico problema - mi chiedo se l'aggiunta di DfsDnsConfig = 1 ai nostri controller di dominio abbia solo aggirato il problema, piuttosto che risolverlo . Non riesco a capire perché i controller di dominio tenterebbero di cercare DOMAIN (il nome di dominio stesso, anziché un server nel dominio) durante il processo di riferimento DFS, anche in un ambiente non solo DNS, e so anche che non ha impostato DfsDnsConfig = 1 su controller di dominio in altri ambienti (solo molto più piccoli/semplici) DNS e non ha avuto lo stesso problema. Tuttavia, abbiamo risolto il nostro problema, quindi siamo felici.

Spero che ciò sia utile per gli altri che stanno riscontrando un problema simile - e grazie ancora a quelli che hanno offerto suggerimenti lungo la strada.

28
Matt

Ciò potrebbe essere causato dall'ordinamento della maschera di rete del server DNS. Ci siamo imbattuti di recente in Server 2003. Questo dipende dalla sottorete corrente.

Esempio.

Sito 1: sottorete IP 10.0.0.0/24 Sito 2: sottorete IP 10.0.1.0/24

Il client nel sito 2 esegue una query DNS per lo spazio dei nomi basato sul dominio e verrà assegnato il server DFS nel sito 1 per impostazione predefinita poiché il server DNS non è a conoscenza dei confini IP del sito. È necessario indicare ai server DNS quale subnet mask utilizzare per identificare gli indirizzi IP con cui rispondere.

Vedi http://support.Microsoft.com/kb/842197

3
Chris

Il blog del team di Active Directory contiene un articolo in tre parti TUTTO sui ritardi DFS.

http://blogs.technet.com/b/askds/archive/2009/09/29/o-dfs-shares-where-art-thou-part-1-3.aspx

Descrive le basi del processo di riferimento e quindi mostra come utilizzare vari strumenti tra cui dfsUtil e dfsDiag per scoprire la causa effettiva dei ritardi.

Mi ha aiutato a trovare il mio problema. Che si è rivelato essere senza autorizzazioni di lettura sulla directory di condivisione per gli utenti del dominio.

HTH, Daniel

3
Daniel B

Odora di un problema DNS ma va bene qualsiasi cosa. Preferivo di gran lunga il vecchio FRS perché gli strumenti diagnostici come Ultrasound erano così utili: 7

Ricevi qualcosa nel registro eventi replica DFS sulle destinazioni? (il rapporto DFS Health trarrà i suoi avvisi dal registro eventi)

Correre senza WINS è un obiettivo piacevole e ammirevole, anche se sono praticamente contrario a questo se ci sono sistemi Windows pre-Vista/2008 in giro perché le cose non funzionano sempre come previsto o così velocemente senza WINS nella mia esperienza, anche se in realtà non dovrebbe importare.

2
Oskar Duveborn

Quindi ho usato questo articolo nella mia ricerca. Ho impostato tutto e ho ancora problemi. Dopo aver trascorso diversi giorni a esaminare il problema ed escludere tutto ciò che "Microsoft", immaginavo fosse legato alla rete. Risulta che il nostro WAN Accelerator era il problema. Ho chiesto ai nostri ragazzi di Networking di disattivare l'accelerazione per i nostri controller di dominio e tutto è migliorato.

1
David Jenkins

dfsutil/spcflush e dfsutil/pktflush possono essere una soluzione anche in una rete multi-sito, assicurarsi che il collegamento DFS del sito principale provenga dal server locale e non dalla cache.

1
Parag DJ

Si è verificato un problema con un suono simile, in cui gli utenti potrebbero riscontrare ritardi (fino a un minuto) tra il clic su un'unità mappata su una condivisione DFS e la possibilità di visualizzare e sfogliare le cartelle all'interno della condivisione.

Gli utenti avevano anche le unità home mappate su una diversa condivisione DFS sullo stesso volume e non avevano alcun ritardo nell'accedere alle cartelle lì.

La differenza tra i due è Enumerazione basata sull'accesso (ABE) - la condivisione del problema ha abilitato questa opzione (è un'unità comune per gli utenti, con migliaia di cartelle - ABE significa che gli utenti vedono solo quelle cartelle per le quali dispongono delle autorizzazioni).

La disabilitazione di ABE ha rimosso completamente il problema. Ovviamente questa non è una soluzione poiché gli utenti vedono tutte le cartelle, confondendole. Ho replicato la condivisione DFS su un server con alcuni dischi di riserva come misura temporanea e anche con ABE abilitato su questo nuovo target, il ritardo è andato.

Il server problematico è 2k3R2 e ha un tempo di attività di oltre 150 giorni (!), Quindi verrà riavviato e far funzionare CHKDSK sul volume offensivo. Riporterò qui se questo fa la differenza per il problema. Il nuovo target si trova su un server 2k8.

1
slag

Aveva molti controller, così come uno script (dnsdfs.cmd servername):

dfsutil server registry dfsdnsconfig set %1
sc \\%1 stop dfs
sc \\%1 start dfs
1
i3laze

Il client memorizza nella cache un riferimento DFS, vale a dire quando si inserisce\domain.name\namespace, memorizzerà nella cache il nome dominio.name del server effettivo. Una volta scaduto il riferimento dalla cache, il client deve sostanzialmente "scoprire" di nuovo la topologia DFS, quindi il ritardo.

Dai un'occhiata qui: http://technet.Microsoft.com/en-us/library/cc758234 (WS.10) .aspx e qui http: //blogs.technet. com/filecab/archive/2006/01/20/417832.aspx per ulteriori informazioni su come funziona.

Possibili soluzioni? Un modo bizzarro di fare ciò potrebbe essere quello di scrivere un piccolo programma che fa "rimanere in vita" ogni pochi minuti; per esempio. un programma C che apre il primo file che trova e lo chiude immediatamente. Non ho provato o testato questo, e avresti sicuramente bisogno di prendere attentamente in considerazione se lo avessi fatto.

1
Maximus Minimus

So che il poster originale non utilizzava WINS, ma sto postando a beneficio di altri, poiché abbiamo usato questo post di più per aiutare a risolvere un problema molto simile. Per noi è finito per essere qualcuno che ha deciso di nominare la propria workstation con lo stesso nome del dominio. Quindi, ogni volta che DC ha fatto una ricerca sul nome di dominio per il riferimento DFS, voleva risolversi su quella workstation e causava un considerevole ritardo di più di 10 secondi. Un dato statico 20 la voce è stata inserita in WINS che punta a DC e questo ha risolto il problema. Se non avessi WINS, potresti provare a posizionare il nome di dominio come un nome di macchina nel file LMHOSTS puntava a DC per ottenere la ricerca 20, e imposta la priorità affinché LMHOSTS sia il primo posto in cui cercare la risoluzione dei nomi netbios.

1
newguy

http://technet.Microsoft.com/en-us/library/cc780950 (v = ws.10) .aspx Questa pagina menziona effettivamente sia i controller di dominio che DFSN, se ciò aiuta.

Voci di registro DFS Domain Controller e Root Server

Le seguenti voci di registro si trovano in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

su server root e controller di dominio. Tutte le voci sono REG_DWORD.

1
Amy

Dici che hai 20 server DFS ma non riesci a menzionare se tutti i server si trovano nella stessa struttura.

Se questi server non si trovano nella stessa struttura e ogni altro sito ha il proprio dominio, è possibile assicurarsi che il failback del client sia abilitato.

0
Ishmael

Per quelli che finiscono qui attraverso una ricerca su Google e che hanno lo stesso problema ...

Per prima cosa controlla che tutti i collegamenti nel tuo spazio dei nomi siano disponibili e validi. Questo è quello che è successo nel mio caso, c'era ancora un collegamento nello spazio dei nomi a un server che era inattivo, quindi la lunga pausa all'apertura di DNS è stata perché stava cercando quel server e falliva. Una volta disabilitato quel collegamento in DFS, la lunga pausa è andata via.

0
Bryan