Pre-staging la replica servizio Replica file in SYSVOL e distribuito condivisioni di sistema del file per la sincronizzazione ottimale

Sul volume di sistema (SYSVOL) e condivisioni di Distributed file system (DFS) per la sincronizzazione ottimale, in questo articolo viene descritto il processo di pre-staging per i file (FRS) replicati di replica.

In Windows Server 2003, dell'installazione di Active Directory (Dcpromo.exe) di procedura guidata contiene un'origine dalla funzionalità di Media che consente di Active Directory per essere originati da una copia recente del database su un CD a differenza di esecuzione di una sincronizzazione completa di Active Directory su rete.

In Windows 2000 build 2195 e Windows XP, la versione di FRS supporta una funzionalità simile quando le cartelle di destinazione su nuovi membri di replica vengono ripristinate dal programma NTBackup per i membri esistenti prima di unirsi a set di repliche. Questa operazione può essere utilizzata sul nuovo o reinizializzata i membri di replica SYSVOL e DFS:

1. Impostare almeno due alternative DFS, ad esempio \\Server1\Apps, \\Server2\Apps e \\ServerX...\Apps.
2. Abilitare la replica solo tra due membri di replica, ad esempio \\SERVER1 e \\Server2. È possibile designare qualsiasi server come principale, ma le cartelle replicate devono essere vuote quando i computer vengono aggiunti il DFS/FRS set di repliche.
3. Copiare i file destinati a set nella cartella replicata \\Server1\Apps di repliche.
   
   Poiché \\SERVER1 dispone di almeno un partner in uscita (\\Server2), quando si copia un file in \\SERVER1, induce FRS generare un file dell'area di gestione temporanea e un ordine di modifica viene inviato a \\Server2. Un MD5 (un algoritmo di hash) viene calcolato il checksum durante la generazione dell'area di gestione temporanea del file e il risultato viene salvato nel IDTable su \\SERVER1 e nell'ordine modifica inviato al \\Server2. Quando \\Server2 elabora questo ordine di modifica viene salvato il checksum MD5 nell'on\\Server2 IDTable. Questo processo è l'unico modo che un checksum MD5 viene salvato nella finestra di IDTable e l'utilizzo del MD5 è necessaria per evitare un sovraccarico quando nuovi membri vengono aggiunti in un secondo momento.
   
   Al termine del passaggio 3, file replicati devono esistere sul \\SERVER1 e \\Server2 ed entrambi IDTables deve avere un checksum MD5 per ogni file e cartelle.
4. Consente di eseguire il backup il contenuto della struttura della replica da \\SERVER1 o \\Server2 NTBackup o un equivalente di terze parti. NTBackup Salva e ripristina l'attributo di Identificazione dell'oggetto (ID) associato a ogni file e cartelle. Né i comandi di copia di MS-DOS che Windows NT è necessario conservare queste informazioni quando i file vengono copiati da \\SERVER1 \\Server2. Questo ID di oggetto deve essere ripristinato con i file quando nuovi membri vengono aggiunti in un secondo momento.
5. Se meno di sette giorni sono trascorsi poiché il set di repliche contenente Server1 e Server2 è stato creato, è necessario cancellare il registro in uscita in modo che un completo vvjoin viene attivato quando viene aggiunto il membro successivo.
   
   Nota Impostare il seguente valore del Registro di sistema su 0 Cancella il registro in uscita:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters

   
   Nome chiave:

   Outlog Change History In Minutes

   (REG_DWORD)
   Valore:

   0
6. In \\Server3 e tutti i membri futuro repliche, ripristinare il backup nella cartella \\Server3\Apps replicati (utilizzando il menu di ripristino di file ) in un percorso"alternativo" prima di aggiungere il computer al set di repliche.
7. Per abilitare la replica \\Server3\Apps, è che \\Server3 di FRS \\Server3 spostamento tutti i file dalla cartella di destinazione per la cartella preesistente e quindi avvia una sincronizzazione completa (nota anche come un'operazione di join del vettore di versione) da tutti i computer in servizi di directory di Windows NT (NTDS) gli oggetti di connessione in ingresso. In caso di DFS con un intero set di repliche mesh topologia preferita per lo snap-in DFS di Windows 2000, i set possono includere tutti i server che partecipano a set di repliche, ad esempio, \\SERVER1 e \\Server2. La versione di Windows XP dello snap-in DFS supporta più topologie ottimale, inclusa un'opzione personalizzata.
   
   Il requisito chiave in questa situazione è che \\Server3 dispone di connessioni in ingresso da un partner upstream, la \\SERVER1 e \\Server2 in questo caso, la cui IDTABLE contiene i checksum MD5 per i file contenuti nei set di repliche di interesse.
   
   FRS su \\SERVER1 enumera tutti i file e le cartelle in relativo IDTable e invia diretto (destinazione singolo) consente di modificare gli ordini in \\Server3. Poiché il IDTable ha un MD5 checksum, è incluso nell'ordine di modifica. Come \\Server3 elabora queste modifiche ordini, questo richiede l'ID di oggetto di server per il file o la cartella dall'ordine di modifica e tenta di individuare il file corrispondente nella cartella preesistente. Se il server individua il file, Ricalcola il checksum MD5 sul contenuto del file, confronta il risultato con il checksum MD5 è ricevuto l'ordine di modifica e, se corrispondono, utilizza il file preesistente anziché tenta per ottenere il file da \\SERVER1. Se il file non viene trovato \\Server3 o se il checksum MD5 non corrisponde, il server ottiene il file da \\SERVER1. Qualsiasi modifica ai file di contenuto, ad esempio, per il controllo di accesso gli elenchi di flussi di dati o gli attributi possono provocare una mancata corrispondenza MD5 e il file è ottenuto dal \\SERVER1 o altri partner upstream.
   
   Nel frattempo, FRS in \\Server2 (e tutti gli altri partner upstream del membro di replica nuova o reinizializzato) sta eseguendo lo stesso processo \\SERVER1. Processi \\Server3 una modifica ordine per un determinato file o una cartella da Server1 o Server2, a seconda di quale arriva prima. L'altra modifica viene ignorata.
   
   Quando tutte le attività di replica sono uscita, nella cartella replicata il IDTables su tutti i tre server sono un checksum MD5 identici e il contenuto del file identici. Ripetere i passaggi 5 e 6 per aggiungere server aggiuntivi al set di repliche.

Ottimizzazione i join VV processo iniziale

Il join VV corrente è intrinsecamente poco efficiente. Durante la normale replica, partner upstream per generare un singolo file dell'area di gestione temporanea, che è possibile origine tutti i partner downstream. In un join VV, tutti i computer dispongono di connessioni in uscita in un nuovo o reinizializzata partner downstream generazione file designati esclusivamente da partner di gestione temporanea. Se 10 computer esegue un join iniziale da \\SERVER1, il join genera 10 file in fase di ciascun file in corso la replica. Ottimizzazioni per limitare l'impatto del join VV includono:

• Predisporre il contenuto di nuovi membri tramite NTBackup (illustrata in precedenza).
• Ridurre il numero di server di gestione temporanea di creazione nuovo file o reinizializzata partner downstream.
• Rimuovere o ridurre il numero di file della cartella replicata fino al completamento della fase di join VV di tutti i computer.
• Attivare un solo join si verifichi in un determinato partner upstream.

Ridurre il numero di file di gestione temporanea di creazione di server per i partner downstream di nuovi o reinizializzati

Aggiunta a domini basati su Windows esistenti del controller di dominio replica (controller di dominio di backup) tenta di replicare la cartella SYSVOL dal controller di dominio stesso utilizzato per Active Directory. Il server di origine SYSVOL viene identificato nel valore del Registro di sistema Replica Set Parent . È necessario confermare che FRS sia in esecuzione e tempi di risposta sul server di origine designato.

Per SYSVOL set di repliche viene reinizializzata con un ripristino non autorevole (Burflags = D2), gli amministratori possono limitare la generazione di file da un server specifico impostando la chiave del Registro di sistema di Replica Set Parent per puntare a un sito stesso o di un server di gestione temporanea designato di gestione temporanea.

Per ulteriori informazioni sulla chiave del Registro di sistema di Replica Set Parent, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito riportato: L'ottimizzazione di chiave del Registro di sistema di Replica Set Parent non è possibile che i membri di repliche DFS. Soluzioni alternative possibili includono:

• Disattivare il servizio FRS in tutti i possibili partner upstream (connessioni da tali computer contenente il membro nuovo o reinizializzato in ingresso) in modo che origine generato dall'unico server rimanente.
  
  Questa soluzione non è la soluzione migliore, in quanto l'interruzione del servizio FRS non interrompe l'accumulo di record di modifica per il diario delle modifiche NTFS. Se il giornale di registrazione esegue il wrapping (overflow), un join VV è necessaria quando il servizio viene riavviato in un secondo momento. Se è noto che vi è trascurabile o nessuna attività di modifica file (ad esempio, crea, Elimina, Rinomina, gli aggiornamenti) su qualsiasi i volumi del disco che ospita un set di repliche, il rischio di giornale di registrazione include è probabilmente insufficiente.
• Rimuovere o ridurre il numero di file della cartella replicata fino al completamento della fase di join VV (descritto nella sezione seguente) di tutti i computer.
  
  Questa operazione potrebbe non essere una valida alternativa se i server centrali sono collegati ai nuovi server diramazione per mezzo di collegamenti di larghezza di banda ridotta e si dispone gigabyte di dati dei file per l'inizializzazione. Tuttavia, si consiglia l'opzione seguente.
• Controllare il numero di connessioni in ingresso da server di origine disponibili al membro nuovo o reinizializzato (vale a dire il join si verifica con una singola connessione in ingresso).
• Propagare i dati dal server hub in ore pomeridiane o fine settimana.
  
  Anche con un collegamento di 64 kilobit al 75 % larghezza di banda disponibile, è possibile spostare 21 MB di dati ogni ora o 506 MB ogni giorno. Con due computer hub e 200 filiali connessi tramite collegamenti di 64 kilobit, è possibile inizializzare tali con 1 GB di contenuto durante un fine settimana due giornate. Se si ottiene un rapporto di compressione media del 50 %, è possibile spostare 2 GB di dati durante un fine settimana. Questa operazione non richiede alcuna copia di backup o operazioni di ripristino, non phasing dell'avvio di diramazione per evitare di confondere i server di hub e tutti i monitoraggi lo stato di avanzamento possono utilizzare i server di hub utilizzando il comando Imposta ntfrs e lo strumento di report Connstat per verificare eventuali backlog per diramazioni specifiche. Lo spazio su dell'area di gestione temporanea e il parametro di limite dell'area di gestione temporanea nel server hub deve essere sufficiente per contenere tutti i dati in quanto la generazione di file dell'area di gestione temporanea può facilmente outpace il recapito di dati di diramazione over slow links.

Rimuovere o ridurre il numero di file nella cartella replicato fino a tutti i computer ha completato la fase di join VV

In genere, è necessario che tutti i membri set di repliche per partecipare a set di repliche con le cartelle vuote o quasi vuote per evitare la generazione inefficiente di file su più server di gestione temporanea. Questo processo è minore di un problema per SYSVOL, perché i server vengono generati in modo incrementale, il contenuto è in genere minore di condivisioni DFS e la chiave di registro Replica Set Parent significa che FRS tenta di origine da un singolo partner upstream.

Per set di repliche DFS grandi dimensioni, in cui è in genere abilitata la replica immediatamente su server 2 a 50 per decine di gigabyte di contenuto, l'impatto è maggiore. È possibile aggiungere la maggior parte dei computer alle condivisioni DFS replicati da FRS dopo aver distribuiti. Inoltre, si desidera la cartella replicata nel server primario sia vuota in modo che il join VV si verifica senza dover replicare i file. File è possibile aggiungere, ad esempio in modo incrementale, con efficienza normale.

È possibile utilizzare un join VV vuoto o minimo per ripristinare una distribuzione in cui Active Directory e/o FRS esperti "fusione verso il basso" e deve essere reinizializzata. Dopo avere verificato che Active Directory replica è funzionante, spostare il file fuori della cartella replicata nel server primario e quindi reinizializzare i membri di replica. In caso di SYSVOL, mantenere il dominio predefinito e criterio controller di dominio nelle cartelle \Policies intatta nel server primario (Burflags = "D4" o rimanente del server di origine) in modo che la reinizializzazione controller di dominio può replicare in e applicare il criterio (ad esempio, il criterio "Questo computer dalla rete e altri necessari diritti di accesso") per il corretto funzionamento dominio e client.

Attivare un solo join per cui si verificano in un determinato partner upstream

Per medie e grandi repliche DFS contenente decine di GB di file, è consigliabile aggiungono un solo membro contemporaneamente alle cartelle replicate di FRS. In particolare, consentire il nuovo membro completare la sincronizzazione completa e spostare modalità join VV. Il partner upstream deve ripulire i file dalla cartella dell'area di gestione temporanea prima di aggiungere membri aggiuntivi.

Inoltre, impostare il limite di spazio gestione temporanea (definito nel seguente articolo, Q221111, "Description of voci FRS nel Registro di sistema") su tutti i server di origine potenziali uguale o maggiore rispetto ai file più grandi 128 replicati dai partner upstream (il numero di join VV che si verificano in un determinato).

Per ulteriori informazioni, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito riportato: