Domanda: esiste un modo per completare più rapidamente questo backlog di 350.000 file? Per quasi tutti i file l'unica modifica è stata una modifica all'ACL per ciascun file interessato. Alcuni file hanno modificato il contenuto, ma non è questo il caso comune in questa situazione.
Questo potrebbe essere risolto. Modificherò questo testo per confermare l'esito positivo / negativo dopo un periodo di tempo e la verifica. Verso la fine di questo testo della domanda ho dettagliato le modifiche apportate di recente che potrebbero averlo corretto.
Abbiamo un gruppo di replica DFSR con circa 450.000 file e occupa 1,5 TB di spazio. In questa situazione, esistono due server Windows Server 2008 R2 distanti circa 500 miglia. Esistono altri server, ma non sono coinvolti in questo gruppo di replica. Il server ALPHA è il server principale ed è quello utilizzato dalla maggior parte dello staff. Server BETA è il server nell'ufficio remoto ed è meno occupato.
Ecco un grafico di backlog per questo gruppo di replica (PNG ospitato su Google Drive) che mostra l'avanzamento della sincronizzazione lenta.
Avevo bisogno di rimuovere una voce di autorizzazione che si trovava nella directory principale di quel gruppo di replica, che ovviamente era ereditata dalla maggior parte delle sottocartelle. Ho apportato questa modifica sul server ALPHA. Subito dopo, DFSR aveva un backlog di 350.000 file. È passata più di una settimana e ora è a 267.000. L'unica cosa che è cambiata (inizialmente) è stata la modifica dell'autorizzazione singola.
Questo è quello che è successo (questa non è la soluzione, solo un'altra spiegazione di cosa è successo a causare questo problema): http://blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack -Perché-da-giri-out-venerdì-notte-era-bene-per-fighting.aspx # DFSR
Tutte le modifiche che si verificano sul server BETA vengono replicate sul server ALPHA molto rapidamente poiché non esiste alcun backlog in quella direzione. Tutti i file modificati su BETA arrivano a ALPHA senza problemi.
Si replica 24 ore su 24, 7 giorni su 7, a tutta velocità attraverso una connessione da 50 Mbps da un lato a una fibra da 100 Mbps dall'altro. L'area di gestione temporanea è di 100 GB su ciascun server. Non c'è nulla di interessante nei registri degli eventi. Esiste un evento di filigrana alta non correlato che viene visualizzato per un gruppo di replica non correlato che non è né per questa particolare replica né per questa coppia di server ALPHA / BETA. In particolare non ci sono voci nel registro eventi per la filigrana alta né per errori di connessione.
Il punto di vista di ALPHA sul gruppo di replica:
Risparmio di larghezza di banda : riduzione del 99,83% (30,85 MB replicati anziché 18,1 GB)
Credo che i 30,85 MB / 18,1 GB siano avvenuti dall'ultima volta che ho riavviato il servizio DFSR su ALPHA e BETA. In tal caso, ciò dimostra che, anche se sta impiegando molto tempo (più a lungo di quanto ritenga necessario), in realtà non trasferisce il contenuto del file attraverso il cavo.
Cartella replicata : 1,46 TB (dimensione effettiva), 439,387 (file), 52,886 (cartelle)
Cartella di conflitto ed eliminata : 100,00 GB (dimensione configurata), 34,01 GB (dimensione effettiva), 19.620 (file), 2.393 (cartelle)
Cartella di gestione temporanea : 200,00 GB (dimensione configurata), 92,54 GB (dimensione effettiva)
Ho riscontrato un errore di filigrana elevato nei registri (14 maggio, 19:00) e quindi ho aumentato la quota di gestione temporanea a 200 GB da 100 GB. So che il percorso approvato da Microsoft è destinato ad aumentare del 20%, ma non ci sto giocando. Abbiamo un sacco di spazio su disco da risparmiare sugli array di dischi di gestione temporanea.
La disabilitazione dell'antivirus su tutti i server non ha aiutato, anche se ho pensato che avrebbe aiutato un po '. Per ora ho riattivato l'antivirus, ma ho impostato il percorso del gruppo di replica da escludere dalla scansione per rimuovere quella variabile dall'equazione.
C'è un modo per farlo andare più veloce? Vorrei solo apportare questa modifica anche sul server BETA, ma ci sono file che sono cambiati su ALPHA ma non si sono replicati su BETA e apportando la modifica delle autorizzazioni ereditate su BETA spingerebbe i file VECCHI da BETA ad ALPHA (perché DFSR sembra ignora i timestamp dei file quando si confronta quale file è il vincitore in una collisione). E che ciò accada sarebbe piuttosto male.
Il portafoglio ordini si sta riducendo lentamente. Molto, molto lentamente. Andrà avanti, però. Ma a questo ritmo, passeranno settimane prima che finisca. Sto pensando di trasferire una copia del set di dati su un'unità da 3 TB e di spedirla all'ufficio remoto. Esiste un modo migliore?
16 maggio 4:00 US PT: cosa potrebbe aver risolto il problema (supponendo che sia stato risolto in modo onesto, comunque):
Ho apportato più modifiche ai controller di dominio che avrebbero dovuto essere apportate molto tempo fa. Il problema è che questa rete è stata ereditata da qualcun altro che probabilmente l'ha ereditata da qualcun altro, ecc. Non posso promettere quale modifica abbia risolto il problema. Eccoli senza alcun ordine particolare:
- Tutti i controller di dominio non erano nell'unità organizzativa "Controller di dominio". Non ho mai visto un dominio Windows che avesse i controller di dominio altrove. Li ho spostati di nuovo a dove appartenevano. In precedenza erano in unità organizzative separate dal nome della città in cui si trova ogni ufficio. (Ho la sensazione di avere dei lavori idraulici da affrontare ora che li ho spostati, ma al momento sembra tutto a posto ...)
- AVG Anti-Virus è in esecuzione su tutti i server DC e DFSR partecipanti. Ho escluso le cartelle replicate e le cartelle di gestione temporanea dalla scansione attiva / in accesso. Non credo che ciò abbia risolto il problema e probabilmente lo proverò più tardi per vedere se annullare questa modifica interferirà con la velocità di replica di DFSR. Questa è una sfida per un altro giorno.
- dcdiag.exe si è lamentato di un problema DNS relativo ai controller di dominio di sola lettura . Ho risolto il problema anche se non abbiamo alcun controller di dominio di sola lettura sul dominio. Dubito che ciò abbia risolto qualsiasi cosa.
- Uno dei record SRV _ldap._tcp.domain.GUID._msdcs.DOMAIN.NET mancava per uno dei controller di dominio (non uno dei server DFSR) e l'ho risolto. Non penso che questo abbia aiutato neanche.
- Una delle volte in cui ho riavviato il server BETA, si è lamentato di un cattivo arresto del database DFSR (evento 2212) e ha continuato a richiedere ore per ricostruire il database. Al termine, è stato segnalato l'evento 2214 per farmi sapere che è finito. Successivamente, la replica continuava a essere eseguita molto lentamente, ma avrebbe potuto aiutare a rimuovere tutto ciò che era bloccato.
- Uno dei controller di dominio non aveva 127.0.0.1 come server DNS secondario nella sua configurazione dell'interfaccia. L'ho aggiunto. Questo non era uno dei server DFSR, quindi probabilmente non aveva nulla a che fare con esso.
- Ho seguito il Blog TechNet: Ottimizzare le prestazioni di replica in DFSR ha raccomandato le impostazioni del Registro di sistema per i server DFSR. Ho usato tutti i valori di "valore ad alte prestazioni testato" ad eccezione di AsyncIoMaxBufferSizeBytes impostato su 4194304, che è di un livello inferiore rispetto al valore elevato. Questo avrebbe potuto aiutare con il problema ... o forse no. È difficile dire quando si cambiano troppe variabili.
- dcdiag.exe si è lamentato di un problema con la comunicazione con il servizio RPC su BETA, ma solo dopo aver già apportato le modifiche di cui sopra. Sembra che questo sia il problema più probabile, ma non ho fatto nulla per correggerlo. La VPN funzionava correttamente e il firewall non la bloccava. È possibile che uno degli elementi di cui sopra sia ciò che ha causato e risolto il problema RPC o potrebbe essere stata una semplice coincidenza. Ora non ricevo questo errore e al momento la replica funziona senza problemi.
La morale della storia è: cambiare una cosa alla volta o non saprai mai cosa l'ha risolta. Ma ero disperato e stavo esaurendo il tempo per risolverlo, quindi ho appena sparato un sacco di proiettili al problema. Se mai individuassi la correzione, la riferirò qui. Non contare su di me restringendolo, però.
EDIT 21/05/2012: ho risolto questo problema guidando ieri per circa sette ore con un server di riserva (GAMMA) nell'ufficio remoto. GAMMA ora agisce come il loro server locale primario mentre il loro solito server (BETA) raggiunge la replica. Da quando l'ho installato, i server hanno raddoppiato la velocità di replica. Sebbene ciò mi dica che potrebbe trattarsi di un problema relativo alla VPN, sono meno propenso a crederlo poiché tutti i nuovi aggiornamenti sembrano replicarsi su GAMMA da ALPHA sono stati molto rapidi e stanno andando bene.
MODIFICA 22/05/2012: al momento è alle 12000 e dovrebbe concludersi tra poche ore. Pubblicherò un bel grafico dei progressi dall'inizio alla fine. Il problema è che l'unica cosa che in realtà "risolve" è la connessione al server locale. Attualmente sto pensando che forse la VPN è parte del problema. E in tal caso, ritengo che questa domanda non abbia ancora ricevuto una risposta. Dopo aver avuto un po 'più di tempo per verificare come le cose si replicano tramite la VPN e vedere eventuali errori, eseguirò il debug e riferirò i progressi.
Se qualcosa cambia, aggiornerò qui.
dfsrdiag replicationstate /amostra che sta inviando solo due file, ma entrambi hanno lo stesso nome file. Dice che ha comunque due connessioni in uscita verso BETA da ALPHA. Il file che sta inviando è di 850 MB. Come descritto in precedenza, non sono convinto che stia effettivamente inviando l'intero contenuto del file, anche se non sono sicuro di cosa farebbe se non perché ci vuole molto tempo solo per gestire un singolo file. Il file è stato aggiornato l'ultima volta nel 2008 (su entrambi i server), quindi non c'è motivo per cui debba fare altro se non aggiornare le informazioni ACL sul file su BETA.