Informazioni sulla replica delle cartelle pubbliche

Si applica a: Exchange Server 2010

Ultima modifica dell'argomento: 2009-12-07

La replica delle cartelle pubbliche indica il processo mediante il quale il contenuto e la gerarchia delle cartelle pubbliche vengono replicati su più server per una maggiore efficienza e tolleranza di errore. Se più database delle cartelle pubbliche ubicati su server separati supportano un unico albero delle cartelle pubbliche, Microsoft Exchange utilizza la replica delle cartelle pubbliche per mantenere sincronizzati i database. Il contenuto delle cartelle pubbliche è presenti solo negli archivi di Exchange configurati per la replica di una cartella specifica. Le informazioni sul contenuto e la gerarchia vengono replicate separatamente. Ogni database delle cartelle pubbliche mantiene una copia della gerarchia, che comprende gli elenchi degli altri database delle cartelle pubbliche che mantengono le repliche del contenuto di ogni cartella. Le repliche del contenuto sono presenti solo nei database delle cartelle pubbliche specificati. Per ulteriori informazioni su come configurare la replica delle cartelle pubbliche, vedere Configurazione della replica delle cartelle pubbliche.

I database delle cartelle pubbliche replicano due tipi di informazioni sulle cartelle pubbliche:

• Gerarchia   La replica della gerarchia avviene quando le proprietà delle cartelle e le informazioni dell'organizzazione sulle cartelle vengono modificate. Tutti i database delle cartelle pubbliche dispongono di una copia delle informazioni sulla gerarchia. La replica della gerarchia avviene quando si modificano le seguenti informazioni relative alle cartelle pubbliche:

  • Nome della cartella

  • Elenco delle repliche

  • Posizione della cartella nell'albero delle cartelle pubbliche (incluse cartelle principali e secondarie)

  • Autorizzazioni

    Nota

    La replica della gerarchia non si verifica quando si modificano gli indirizzi di posta elettronica per una cartella pubblica abilitata alla posta. Gli indirizzi di posta elettronica vengono archiviati nell'oggetto directory di Active Directory. La replica della gerarchia avviene solo quando si modificano le proprietà nel database dell'archivio delle cartelle pubbliche.

• Contenuto   La replica del contenuto avviene quando vengono inviati messaggi alle cartelle pubbliche o quando vi vengono aggiunti dati. Ad esempio, l'invio di messaggi di posta elettronica a una cartella pubblica abilitata all'utilizzo della posta o l'aggiunta di un modulo dell'organizzazione a una cartella pubblica comportano la replica del contenuto. Per replicare il contenuto, è necessario configurare una cartella in modo che replichi il proprio contenuto in un database o in un elenco di database delle cartelle pubbliche specifici. Solo i database specificati disporranno di copie del contenuto. La copia di una cartella che include contenuto viene detta replica del contenuto.

Sommario

Funzionamento della replica delle cartelle pubbliche

Messaggi di replica

Richieste e messaggi di recupero

Esempi di cicli di repliche

Procedure consigliate per l'implementazione della replica

Per informazioni sulle attività di gestione relative alle cartelle pubbliche, vedere Gestione delle cartelle pubbliche.

Funzionamento della replica delle cartelle pubbliche

Quando si modifica una cartella pubblica o il suo contenuto, il database delle cartelle pubbliche contenente la replica della cartella modificata invia un messaggio di posta elettronica descrittivo agli altri database delle cartelle pubbliche che ospitano una replica della cartella pubblica. Per ridurre il traffico sulla rete, Exchange include informazioni su più modifiche in un unico messaggio di posta elettronica. La quantità di informazioni comprese in questi messaggi dipende dai limiti di dimensione impostati per i messaggi di replica. Se un messaggio supera il limite specificato per le dimensioni, viene inviato come messaggio di replica separato. Exchange esegue il routing di questi messaggi allo stesso modo in cui esegue quello di altri messaggi di posta elettronica.

Se si apportano alla gerarchia di cartelle pubbliche modifiche che riguardano diverse cartelle, il processo di replica può richiedere una larghezza di banda di rete considerevole. Ad esempio, per spostare le cartelle pubbliche da un server all'altro, è necessario creare le repliche sul server su cui si desidera spostare le cartelle pubbliche, attendere che le modifiche alla gerarchia vengono replicate sul server originale, quindi attendere che il contenuto venga replicato nelle nuove repliche. Una volta sincronizzate le repliche, è necessario rimuoverle dal vecchio server. Anche la rimozione delle repliche dal vecchio server genera traffico di rete in quanto la rimozione di repliche deve replicarsi come modifica della gerarchia. Per ulteriori informazioni su come le modifiche apportate alle gerarchi di cartelle pubbliche possa influire sul sistema, vedere "Richieste di stato e messaggi di stato" più avanti in questo argomento.

Processo di replica della gerarchie e del contenuto di base

Nelle figure e nel testo esplicativo riportati di seguito viene descritto il processo di base attraverso il quale la gerarchia e il contenuto di cartelle pubbliche vengono replicati.

Processo di base per la replica

I dettagli relativi al processo sono riportati di seguito:

1. Un utente modifica la cartella pubblica.
2. La modifica viene registrata nel database delle cartelle pubbliche locali.
3. In occasione del ciclo di replica programmato successivo (determinato dall'intervallo di replica impostato per il database delle cartelle pubbliche), nel database delle cartelle pubbliche vengono verificate le proprietà della cartella per stabilire se altri server contengono una replica di tale cartella. Se esistono altre repliche, il database stabilisce quali sono le informazioni da replicare. Queste informazioni diventano l'aggiornamento delle repliche.
   La replica delle cartelle pubbliche si basa su oggetti. Se viene modificata la proprietà di un oggetto, l'intero oggetto deve essere replicato. Poiché il database che replica la modifica non può presumere che tutte le repliche che riceve siano aggiornate, deve replicare l'intero oggetto. Di seguito sono riportate le implicazioni per i diversi tipi di replica:
   • Replica della gerarchia   La replica delle nuove modifiche apportate alla gerarchia avviene quando viene creata o eliminata una cartella pubblica oppure quando viene apportata una modifica alle proprietà di una cartella pubblica (ad esempio una modifica all'elenco delle repliche, alle autorizzazioni client, alla descrizione, a una nota amministrativa o ai limiti di archiviazione).
   • Replica del contenuto   Se viene inserito un nuovo messaggio o viene modificato un messaggio esistente, l'aggiornamento include l'intero messaggio e le sue proprietà.
4. Il database delle cartelle pubbliche assegna un numero di modifica all'aggiornamento.
   Quando una cartella replica un aggiornamento a un altro server, il numero di modifica viene incluso insieme all'aggiornamento. Il server che riceve utilizza quindi il numero di modifica per stabilire se l'aggiornamento costituisce una nuova modifica e se al server mancano dati.
5. Il database delle cartelle pubbliche riunisce gli aggiornamenti in un messaggio di replica. I numeri delle modifiche di tutti gli aggiornamenti nel messaggio vengono chiamati insiemi di numeri di modifica (CNSet*)*.
   Insieme agli aggiornamenti, il database delle cartelle pubbliche riunisce le informazioni provenienti dagli elementi della cartella che si trovano nella tabella di stato della replica, compresi i CNSet precedentemente applicati alla replica. Per ulteriori informazioni sulla tabella di stato della replica, vedere "Tabella di stato della replica" più avanti in questo argomento.
6. Per ridurre il traffico di posta elettronica, il database delle cartelle pubbliche riunisce più aggiornamenti della gerarchia in un unico messaggio di replica. Similmente, il database riunisce più aggiornamenti del contenuto per la stessa cartella in un unico messaggio di replica. Il database non può tuttavia riunire gli aggiornamenti della gerarchia nello stesso messaggio di replica degli aggiornamenti del contenuto e ogni messaggio di replica del contenuto contiene gli aggiornamenti per un'unica cartella.
7. Il database delle cartelle pubbliche invia il messaggio di replica agli altri database delle cartelle pubbliche che ospitano repliche della cartella aggiornata. Il database invia il messaggio insieme ad altri messaggi riuniti a partire dal ciclo di replica precedente.
   Per il recapito dei messaggi di replica, il database delle cartelle pubbliche fa affidamento sui componenti di routing interno di Exchange. Il database non tenta di suddividere i messaggi di replica in base ai dettagli della topologia. Se il contenuto di una cartella viene modificato e la cartella dispone di altre cinque repliche, il database genera un unico messaggio di replica e lo invia a tutti e cinque i database che ospitano le repliche. I componenti di routing determinano come effettuare il routing del messaggio e come recapitarlo.
8. Il database delle cartelle pubbliche riceve il messaggio di replica.
9. Il database delle cartelle pubbliche che riceve separa l'aggiornamento e le informazioni sullo stato contenute nel messaggio di replica.
10. Il database confronta i numeri delle modifiche dei nuovi aggiornamenti con l'elenco dei numeri delle modifiche che già contiene, quindi identifica gli aggiornamenti non ricevuti in precedenza.
11. Il database applica i nuovi aggiornamenti alle repliche delle cartelle appropriate.
12. Per ogni replica aggiornata, il database aggiorna la tabella di stato della replica con i numeri di modifica dell'aggiornamento corrente e le informazioni sullo stato della cartella contenute nel messaggio di replica.
    Se le informazioni nella tabella di stato della replica indicano che sono stati applicati altri CNSet ad altre repliche della cartella e non alle repliche di questo database, il database registra i CNSet mancanti in una posizione denominata matrice di recupero informazioni e si prepara a inviare una richiesta di recupero informazioni. Per ulteriori informazioni sulle richieste di recupero, vedere "Richieste e messaggi di recupero" più avanti in questo argomento.

Inizio pagina

Messaggi di replica

Il processo di replica utilizza gli attributi di Active Directory dei database delle cartelle pubbliche e non gli attributi di Active Directory delle singole cartelle pubbliche. Gli attributi di Active Directory per le singole cartelle pubbliche vengono utilizzati solo per inviare messaggi di posta elettronica normali a o dalle cartelle. Un oggetto database delle cartelle pubbliche viene configurato e mantenuto automaticamente e si trova nel contenitore della configurazione di Active Directory.

I messaggi di replica differiscono dagli altri messaggi di posta elettronica per il fatto che Exchange li considera messaggi di sistema. Ciò significa che i messaggi di replica non sono vincolati alle restrizioni applicate ai messaggi di posta elettronica degli utenti (ad esempio, le restrizioni relative alle dimensioni e al recapito).

Nella tabella riportata di seguito sono elencati i diversi tipi di messaggi di replica utilizzati da Exchange.

Tipi di messaggi di replica delle cartelle pubbliche e motivo del loro utilizzo

Tabella di stato delle repliche

Ogni database delle cartelle pubbliche mantiene una tabella di stato della replica per tenere traccia dello stato di ogni replica nel database. Nella tabella di stato della replica vengono archiviate le seguenti informazioni:

• Informazioni di base necessarie per la costruzione degli aggiornamenti a ogni replica.
• Informazioni sull'ultimo aggiornamento a ciascuna replica che ha avuto origine nel database locale, compreso il numero di modifica dell'aggiornamento.
• Gruppi di aggiornamenti applicati a tutte le altre repliche note della cartella. I numeri di modifica identificano gli aggiornamenti in ciascun gruppo. L'insieme dei numeri di modifica per tutti gli aggiornamenti in un gruppo è detto CNSet. Le informazioni sugli aggiornamenti vengono passate da un database all'altro come parte del processo di replica.

Nella tabella seguente viene fornito un esempio del funzionamento delle tabelle di stato della replica. In questo esempio i database delle cartelle pubbliche sul server A e sul server B dispongono entrambi di repliche di una cartella denominata Projects. Su ogni server, la tabella di stato della replica tiene traccia non solo dello stato della replica su quel server, ma anche dello stato della replica sull'altro server. Utilizzando queste informazioni, il server A stabilisce se la sua replica della cartella Projects è sincronizzata con la replica della cartella Projects sul server B. Il server B può parimenti tenere traccia del suo stato relativo al server A.

Dati di esempio dalla tabella di stato della replica per Server A

Dati di esempio dalla tabella di stato della replica per Server B

Combinando gli elenchi dei database delle cartelle pubbliche contenenti le repliche del contenuto con le informazioni nella tabella di stato della replica, ogni database delle cartelle pubbliche può stabilire quanto è aggiornato rispetto agli altri database delle cartelle pubbliche che supportano l'albero delle cartelle pubbliche.

Inizio pagina

Richieste e messaggi di recupero

Il recupero informazioni avviene quando un database delle cartelle pubbliche si accorge di non avere ricevuto tutti gli aggiornamenti per una cartella replicata (o per la gerarchia) e deve pertanto recuperare gli aggiornamenti mancanti da un altro database delle cartelle pubbliche.

Per semplificare il processo di recupero informazioni, in Exchange vengono archiviate le informazioni sugli aggiornamenti mancanti nella matrice di recupero informazioni.

Gli eventi riportati di seguito possono segnalare a un database delle cartelle pubbliche aggiornamenti mancanti che devono essere recuperati:

• Le informazioni sullo stato in un messaggio di replica in arrivo indicano che la replica sul database delle cartelle pubbliche che ha inviato il messaggio presenta aggiornamenti nel database ricevente. Il database ricevente identifica i numeri di modifica mancanti e li archivia nella sua matrice di recupero.
• Un database delle cartelle pubbliche viene avviato per la prima volta. Il nuovo database invia richieste di stato per ottenere informazioni sugli altri database nella gerarchia. Una volta arrivato il messaggio di stato corrispondente, il database completa la tabella di stato della replica e, se necessario, la matrice di recupero informazioni. La matrice di recupero può contenere elementi sia per la gerarchia che per eventuali repliche di contenuto che il database deve ospitare.
• Un messaggio di gerarchia in arrivo indica che una nuova replica di contenuto deve essere posizionata nel database delle cartelle pubbliche. Il nuovo database invia richieste di stato per ottenere informazioni sul contenuto che potrebbe essere disponibile per questa replica negli altri database nella gerarchia. Una volta arrivato il messaggio di stato corrispondente, il database completa la tabella di stato della replica e, se necessario, la matrice di recupero informazioni.

Queste informazioni restano archiviate nella matrice di recupero per un periodo di tempo specificato (detto timeout di recupero). Se gli aggiornamenti mancanti arrivano in messaggi di replica successivi durante questo intervallo, vengono rimossi dalla matrice di recupero. Nella tabella riportata di seguito vengono elencati i valori di timeout di recupero predefiniti, che dipendono dal fatto che esistano aggiornamenti mancanti e dal fatto che siano stati precedentemente richiesti.

Valori di timeout predefiniti utilizzati per le richieste di recupero

Se il timeout di recupero scade e gli aggiornamenti sono sempre mancanti, Exchange crea una o più ulteriori richieste di recupero e stabilisce i server da utilizzare come origini del recupero.

Per selezionare i server da utilizzare come origine per il recupero informazioni, Exchange crea innanzitutto un elenco di tutti i server che dispongono di repliche della cartella, quindi ordina l'elenco in base alla sequenza di criteri riportata di seguito:

1. Ordinamento in base allo stato del server. I server inattivi o non disponibili vengono posizionati in fondo all'elenco.
2. Ordinamento in base al server di recupero informazioni preferito (se presente). Exchange controlla l'oggetto database delle cartelle pubbliche in Active Directory per un server di recupero informazioni preferito. Questa impostazione viene utilizzata raramente. Nella maggior parte delle circostanze, il processo di recupero funziona in maniera più efficiente se Exchange seleziona automaticamente un server di recupero. La maggior parte delle distribuzioni di Exchange non necessita di un server di recupero informazioni preferito. Il servizio supporto tecnico clienti Microsoft può fornire uno script per l'impostazione di un server di recupero informazioni preferito, se richiesto dalla distribuzione.
3. Ordinamento in base al costo di trasporto (dal più basso al più alto). I server appartenenti allo stesso gruppo di routing hanno priorità sui server nei siti remoti di Active Directory.
4. Ordinamento in base alla versione di Exchange (dalla più recente alla più vecchia).
5. Ordinamento in base al numero delle modifiche necessarie disponibili sul server (dalla più grande alla più piccola). I server che non dispongono di modifiche mancanti vengono eliminati dall'elenco.

Se un server non dispone di tutte le modifiche necessarie, Exchange seleziona il server successivo nell'elenco ordinato e invia una richiesta di recupero informazioni anche a quel server. Il processo viene ripetuto fino a che non vengono richieste tutte le modifiche.

Se il server selezionato non risponde alla richiesta di recupero informazioni, il database lo contrassegna come non disponibile e ripete il processo di selezione. I server contrassegnati come non disponibili vengono spostati alla fine dell'elenco.

Richieste e messaggi di stato

Oltre alle informazioni sullo stato contenute in ciascun messaggio di replica, Exchange utilizza richieste e messaggi di stato per stabilire se le cartelle pubbliche devono inviare richieste di recupero.

Un database delle cartelle pubbliche invia una richiesta di stato nelle circostanze riportate di seguito:

• Al database viene inviata notifica di una modifica all'elenco dei database contenenti repliche di una cartella. Ad esempio, se si aggiunge/rimuove un database a/dall'elenco, Exchange replica la modifica utilizzando messaggi di aggiornamento della gerarchia. In questo caso il database invia una richiesta di stato che esige una risposta da ogni database contenente una replica della cartella.
• Un nuovo database viene avviato per la prima volta. In questo caso il database richiede lo stato della gerarchia delle cartelle pubbliche. Il database invia una richiesta di stato che esige una risponda da ogni database che supporta l'albero delle cartelle pubbliche.
• Un database ripristinato utilizzando Windows Server Backup viene avviato per la prima volta al termine della fase di ripristino. In questo caso il database richiede lo stato della gerarchia delle cartelle pubbliche e di tutte le cartelle per cui il database contiene repliche di contenuto. La richiesta di stato include due o tre database come risponditori necessari. I risponditori necessari sono database che supportano questa gerarchia e, in base a un processo di selezione interno, sono origini affidabili del contenuto della cartella.

Per indicare lo stato corrente di una particolare cartelle sul database mittente, il database delle cartelle pubbliche invia un messaggio di stato a un altro database nelle seguenti circostanze:

• In risposta a una richiesta di stato inviata da un altro database. Il messaggio di stato viene inviato solo al database richiedente e solo se si verificano le condizioni riportate di seguito:
  • Il database che ha ricevuto la richiesta di stato è incluso nell'elenco delle richieste dei risponditori necessari.
  • La tabella di stato della replica indica che il database che ha ricevuto la richiesta di stato dispone degli aggiornamenti mancanti dal database che ha inviato la richiesta.
• 24 ore dopo avere ricevuto l'aggiornamento più recente su una cartella, se non ci sono stati aggiornamenti successivi. Ogni volta che il database riceve un aggiornamento per una cartella specifica, il timer viene resettato su 24 ore. Questo messaggio di stato viene inviato a tutti gli altri database delle cartelle pubbliche contenenti repliche della cartella aggiornata.

Se un database delle cartelle pubbliche riceve un messaggio di stato indicante che il database mittente dispone di informazioni più recenti sulla cartella, il database ricevente crea una richiesta di recupero. Se i numeri di modifica risultano uguali (o i numeri di modifica sul server ricevente sono più recenti), non viene intrapresa alcuna azione. Ad esempio, quando un nuovo database delle cartelle pubbliche viene avviato per la prima volta, invia messaggi di richieste di stato a ciascun database che supporta la gerarchia delle cartelle pubbliche. Ciascun database risponde con informazioni sullo stato della gerarchia (come registrata da quel database). Il nuovo database utilizza queste informazioni per identificare le eventuali repliche che dovrebbe possedere; può quindi inviare richieste di recupero secondo necessità per compilare il contenuto della replica.

Inizio pagina

Esempi di cicli di repliche

Nella figura seguente viene mostrato uno scenario semplificato a due server che illustra la sequenza degli eventi che si verificano quando si aggiunge una replica di contenuto a un database delle cartelle pubbliche. Questa azione aggiunge il database delle cartelle pubbliche all'elenco di repliche della cartella. Si noti che la sequenza dei passaggi dipende da fattori quali i tempi degli intervalli di replica e la topologia del routing.

Sequenza di eventi quando si aggiunge una replica a un database delle cartelle pubbliche

I dettagli relativi al processo sono riportati di seguito:

1. Lavorando su ExServ01, un amministratore lo aggiunge a un elenco delle repliche di una cartella.
2. ExServ01 invia un messaggio di gerarchia.
3. ExServ02 aggiunge ExServ01 alla copia locale dell'elenco delle repliche della cartella.
4. ExServ01 invia una richiesta di stato a ExServ02.
5. ExServ02 invia un messaggio di stato a ExServ01 che include il CNSet completo della cartella.
6. ExServ01 stabilisce che il contenuto di tutte le cartelle è mancante e registra gli elementi appropriati nella matrice di recupero.
7. Se il contenuto è ancora mancante una volta trascorso il timeout di recupero, ExServ01 crea una richiesta di recupero e la invia a ExServ02.
8. ExServ02 compila i messaggi di contenuto e li invia a ExServ01.
9. ExServ01 utilizza i messaggi di contenuto in arrivo per aggiornare il contenuto della cartella e le relative informazioni di verifica.
10. Se i numeri di modifica continuano ad essere mancanti, ExServ01 attende 24 ore, quindi invia una richiesta di recupero aggiornata. Se è disponibile un server diverso da ExServ02, ExServ01 può inviare la richiesta a quel server.

Nella figura seguente viene mostrato uno scenario semplificato a due server che illustra la sequenza di eventi che si verificano quando si rimuove una replica da un database delle cartelle pubbliche (questa azione rimuove il database delle cartelle pubbliche dall'elenco di repliche della cartella). Si noti che la sequenza dei passaggi dipende da fattori quali il numero di server nella topologia.

Sequenza di eventi quando si rimuove una replica da un database delle cartelle pubbliche

I dettagli relativi al processo sono riportati di seguito:

1. Lavorando su ExServ01, un amministratore lo rimuove da un elenco delle repliche di una cartella.
2. ExServ01 contrassegna la replica (la copia della cartella su ExServ01) come in attesa di eliminazione.
   I client non possono più accedere alla cartella utilizzando questo database.
3. ExServ01 invia un messaggio di gerarchia.
4. ExServ02 aggiorna la sua copia dell'elenco delle repliche delle cartelle in modo da mostrare che la cartella è in attesa di eliminazione su ExServ01.
   ExServ02 non rimanda più i client che cercano questa cartella a ExServ01.
5. ExServ01 invia una richiesta di stato a ExServ02.
6. ExServ02 invia un messaggio di stato a ExServ01. Se la replica su ExServ02 non è aggiornata, ExServ02 colloca gli elementi adeguati nella matrice di recupero informazioni. Entro cinque minuti, ExServ02 invia la richiesta di recupero corrispondente a ExServ01.
7. ExServ01 verifica che la replica della cartella su ExServ02 contenga tutte le informazioni presenti nella replica in attesa di eliminazione. In caso contrario, ExServ01 invia gli aggiornamenti del contenuto adeguati e torna al passo 5. Altrimenti, ExServ01 passa al punto 8.
   Questo processo garantisce che, fintanto che esistono altre repliche, l'eliminazione di una singola replica non si traduca in una perdita di contenuto.
8. ExServ01 contrassegna la replica come elimina ora. In occasione del ciclo di manutenzione successivo la replica verrà rimossa da ExServ01.
9. ExServ01 invia un messaggio di gerarchia.
10. ExServ02 rimuove ExServ01 dalla sua copia dell'elenco delle repliche della cartella.

Inizio pagina

Procedure consigliate per l'implementazione della replica

La replica delle cartelle pubbliche in Exchange può essere un'operazione che richiede l'utilizzo di numerose risorse. Per il suo funzionamento la replica richiede risorse di rete CPU e di disco. Implementando una soluzione che consente una replica efficace delle cartelle pubbliche, soprattutto nel caso di organizzazioni con un utilizzo elevato delle cartelle pubbliche, è possibile migliorare notevolmente il carico della rete, della CPU e del disco in un'organizzazione Exchange.

In genere, si consiglia di ridurre al minimo la replica nell'intera organizzazione. In tal modo, viene minimizzata la quantità di dati che viaggiano in rete. Riducendo al minimo la replica, inoltre, diminuisce la probabilità che più utenti accedano a diverse versioni di dati su più repliche. Si noti tuttavia che minimizzando la replica, diminuisce la disponibilità del dati contenuti nelle cartelle pubbliche in quanto meno repliche della cartella sono disponibili ai client in caso di errore di un database delle cartelle pubbliche. Se è richiesta una disponibilità su larga scala per i dati contenuti in una cartella pubblica specifica, è possibile richiedere un'ulteriore replica.

Inizio pagina