Condividi tramite


Concetti relativi alla replica delle cartelle pubbliche

 

Si applica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Ultima modifica dell'argomento: 2008-07-14

La replica delle cartelle pubbliche è il processo attraverso il quale i contenuti e la gerarchia delle cartelle pubbliche vengono replicati in più server per una maggiore efficienza e tolleranza di errore. Se più database delle cartelle pubbliche ubicati in server separati supportano un unico albero delle cartelle pubbliche, Microsoft Exchange utilizza la replica delle cartelle pubbliche per mantenere sincronizzati i database. I contenuti delle cartelle pubbliche sono presenti solo in archivi di Exchange configurati per la replica di una cartella specifica. Le informazioni sul contenuto e la gerarchia vengono replicate separatamente. Ciascun database delle cartelle pubbliche mantiene una copia della gerarchia, che include elenchi di altri database delle cartelle pubbliche che mantengono 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 Come configurare la 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 di una cartella pubblica abilitata all'utilizzo della posta elettronica. Gli indirizzi di posta elettronica vengono archiviati nell'oggetto directory nel servizio 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.

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 incluse nei 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. Per ulteriori informazioni sul routing delle cartelle pubbliche, vedere Routing di messaggi verso cartelle pubbliche.

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 cartelle pubbliche da un server all'altro, è necessario creare nuove repliche sul server su cui si desidera spostare le cartelle pubbliche, attendere che le modifiche alla gerarchia vengono replicate sul server originale e 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.

Il processo di base di replica delle cartelle pubbliche

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 delle cartelle che si trovano nella tabella di stato delle repliche, compresi i CNSet precedentemente applicati alla replica. Per ulteriori informazioni sulla tabella di stato delle repliche, vedere "Tabella di stato delle repliche" 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 aggiornamenti per una singola 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 alle informazioni sulla 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 in precedenza non ricevuti.

  11. Il database applica i nuovi aggiornamenti alle repliche delle cartelle appropriate.

  12. Per ogni replica aggiornata, il database aggiorna la tabella di stato delle repliche 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 delle repliche indicano che sono stati applicati altri CNSet ad altre repliche della cartella ma non a repliche su questo database, il database registra i CNSet mancanti in una posizione denominata matrice di recupero e si prepara quindi a inviare una richiesta di recupero. Per ulteriori informazioni sulle richieste di recupero, vedere "Richieste e messaggi di recupero" più avanti in questo argomento.

Messaggi di replica

Il processo di replica utilizza gli attributi di Active Directory del database delle cartelle pubbliche, 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 è configurato e mantenuto automaticamente e risiede nel contenitoreConfigurazione in 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.

Nota

I valori indicati tra parentesi nella tabella indicano la notazione esadecimale dei tipi di messaggio. Queste notazioni vengono utilizzate negli eventi e nei registri. È possibile utilizzare il valore esadecimale per la risoluzione di problemi legati alla replica.

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

Tipo di messaggio* Motivo di utilizzo

Gerarchia (0x2)

Consente di replicare le modifiche alla gerarchia dal database delle cartelle pubbliche locali a tutti gli altri database delle cartelle pubbliche che supportano la stessa gerarchia. Sebbene Exchange gestisca le modifiche alla gerarchia separatamente rispetto alle modifiche alle repliche del contenuto, considera la gerarchia come se fosse un'altra cartella. In alcuni messaggi di evento e in altre operazioni, Exchange fa riferimento alla gerarchia come alla cartella 1-1.

Contenuto (0x4)

Consente di replicare le modifiche al contenuto da una replica a tutte le altre repliche di contenuto di quella cartella. Un messaggio di contenuto contiene solo informazioni applicabili a una singola cartella.

Richiesta di recupero (0x8)

Consente di richiedere dati mancanti nei CNSet da un altro database. Ciò include i numeri di modifica alle gerarchia e al contenuto.

Risposta di recupero (0x80000002 o 0x80000004)

Consente di inviare i dati mancanti nei CNSet a un database che ha richiesto gli aggiornamenti mancanti.

Stato (0x10)

Consente di inviare il CNSet corrente di una cartella a una o più repliche di quella cartella. Ciò include i numeri di modifica alle gerarchia e al contenuto.

Richiesta di stato (0x20)

Consente di richiedere CNSet da replicare o messaggi di stato da rinviare. Ciò include i numeri di modifica alle gerarchia e al contenuto.

Tabella di stato delle repliche

Ciascun database delle cartelle pubbliche mantiene una tabella di stato delle repliche per tenere traccia dello stato di ciascuna replica nel database. Nella tabella di stato delle repliche sono archiviate le informazioni riportate di seguito:

  • Informazioni di base necessarie per la costruzione di aggiornamenti a ciascuna 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 riportata di seguito viene fornito un esempio del funzionamento delle tabelle di stato delle repliche. 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 ciascun server, la tabella di stato delle repliche 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.

Esempi di dati della tabella di stato delle repliche per il server A

Replica Dati

Cartella Projects sul server A

(replica locale)

Ultimo aggiornamento inviato: A-100

Cartella Projects sul server B

A-100 ricevuto

B-50 ricevuto

Esempi di dati della tabella di stato delle repliche per il server B

Replica Dati

Cartella Projects sul server A

A-100 ricevuto

B-50 ricevuto

Cartella Projects sul server B

(replica locale)

Ultimo aggiornamento inviato: B-50

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

Richieste e messaggi di recupero

Il recupero 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, in Exchange 2007 vengono archiviate informazioni sugli aggiornamenti mancanti nella matrice di recupero.

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 compila la sua tabella di stato delle repliche e, se necessario, la matrice di recupero. 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 compila la tabella di stato delle repliche e, se necessario, la matrice di recupero.

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

Tipo di richiesta Contenuto esistente su un database nel sito di Active Directory locale Contenuto esistente su un database in un sito di Active Directory remoto

Recupero iniziale

6 ore

12 ore

Primo tentativo di recupero

12 ore

24 ore

Tentativi di recupero successivi

24 ore

48 ore

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, Exchange crea innanzitutto un elenco di tutti i server che possiedono repliche della cartella, quindi ordina l'elenco in base alla sequenza di parametri 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 preferito (se presente). Exchange controlla l'oggetto database delle cartelle pubbliche in Active Directory per un server di recupero 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 preferito. Il servizio supporto tecnico Microsoft può fornire uno script per l'impostazione di un server di recupero preferito se la distribuzione utilizzata lo richiede.

  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 di modifiche necessarie disponibili sul server (dalla più grande alla più piccola). I server che non possiedono modifiche mancanti vengono eliminati dall'elenco.

Se un server non possiede tutte le modifiche necessarie, Exchange seleziona il server successivo nell'elenco ordinato e invia una richiesta di recupero 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, il database lo contrassegna come non disponibile e ripete il processo di selezione. I server contrassegnati come non disponibili vengono spostati in fondo all'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 che è stato ripristinato utilizzando lo strumento di backup di Microsoft Windows viene avviato per la prima volta dal completamento del 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 delle repliche indica che il database che ha ricevuto la richiesta di stato dispone di 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.

Esempi di cicli di repliche

Nella figura in basso viene mostrato uno scenario semplificato basato su due server che illustra la sequenza di eventi che vengono attivati 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

aggiungere alla gerarchia la replica 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 in basso viene mostrato uno scenario semplificato basato su due server che illustra la sequenza di eventi che vengono attivati 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

Eliminazione delle repliche dal 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 sua replica (la copia della cartella su ExServ01) come in corso 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. 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 adeguati aggiornamenti del contenuto e torna al passaggio 5. Altrimenti ExServ01 passa al punto 8.

    Il processo garantisce che fintanto che esistono altre repliche, l'eliminazione di una singola replica non provoca una perdita di contenuto.

  8. ExServ01 contrassegna la sua replica come "elimina adesso". 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.

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 efficiente delle cartelle, 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.

Generalmente è consigliabile ridurre al minimo la replica nell'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.

Replica delle cartelle pubbliche e replica continua

La replica continua e la replica delle cartelle pubbliche sono due forme di replica ben distinte incorporate in Exchange. Poiché esistono alcune limitazioni relative all'interoperabilità tra la replica continua e la replica delle cartelle pubbliche, sono disponibili istruzioni specifiche per la combinazione della replica delle cartelle pubbliche con la replica continua. Per esaminare queste istruzioni, vedere Pianificazione di una replica continua cluster, Pianificazione della replica continua locale e Replica continua di standby.

Ulteriori informazioni

Per ulteriori informazioni sulle cartelle pubbliche, vedere Concetti relative alle cartelle pubbliche.

Per ulteriori informazioni su come gestire le cartelle pubbliche, vedere Gestione delle cartelle pubbliche.

Per ulteriori informazioni su come gestire i database delle cartelle pubbliche, vedere Gestione dei database delle cartelle pubbliche.