Compreendendo a replicação de pasta pública
Aplica-se a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Tópico modificado em: 2008-07-14
A replicação de pasta pública é o processo pelo qual o conteúdo da pasta pública e a hierarquia são replicados por vários servidores, a fim de obter eficiência e tolerância a falhas. Quando vários bancos de dados de pasta pública que estão localizados em servidores separados oferecem suporte a uma única árvore de pasta pública, o Microsoft Exchange usa a replicação de pasta pública para manter os bancos de dados sincronizados. O conteúdo da pasta pública existe apenas em armazenamentos do Exchange que são configurados para ter uma réplica de uma pasta específica. Informações sobre conteúdo e hierarquia são replicadas separadamente. Cada banco de dados de pastas públicas retém uma cópia da hierarquia, que inclui listas dos outros bancos de dados de pastas públicas que retêm réplicas de conteúdo de cada pasta. As réplicas de conteúdo existem apenas nos bancos de dados de pasta pública que você especificar. Para obter mais informações sobre como configurar a replicação de pastas públicas, consulte Como configurar a replicação de pasta pública.
Os bancos de dados de pasta pública replicam dois tipos de informações de pasta pública:
Hierarquia A replicação da hierarquia ocorre quando as propriedades das pastas e as informações organizacionais sobre as pastas foram modificadas. Todos os bancos de dados de pasta pública têm uma cópia das informações de hierarquia. Modificar as informações da pasta pública a seguir resulta em replicação da hierarquia:
Nome da pasta
Lista de réplicas
A posição da pasta na árvore de pastas públicas (incluindo todas as pastas pai e filho)
Permissões
Dica
A replicação de hierarquia não ocorre quando você altera os endereços de email para pasta pública habilitada para email. Os endereços de email são armazenados no objeto do diretório no serviço de diretório do Active Directory. A replicação de hierarquias ocorre apenas mediante alteração das propriedades dentro do banco de dados de armazenamento público.
Conteúdo A replicação de conteúdo ocorre quando as mensagens são enviadas para pastas públicas ou quando dados são adicionados. Por exemplo, o envio de mensagens de email para uma pasta pública habilitada para email ou a adição de um formulário organizacional a uma pasta pública resulta em replicação de conteúdo. Para replicar o conteúdo, é necessário configurar uma pasta para replicar seu conteúdo em um banco de dados de pasta pública específico ou em uma lista de bancos de dados. Somente bancos de dados especificados terão cópias do conteúdo. Uma cópia da pasta que inclui o conteúdo é chamada réplica de conteúdo.
Como a replicação de pasta pública funciona
Quando você modifica uma pasta pública ou seu conteúdo, o banco de dados de pasta pública que contém a réplica da pasta pública alterada envia uma mensagem de email descritiva para os outros bancos de dados de pastas públicas que hospedam uma réplica da pasta pública. Para reduzir o tráfego da rede, o Exchange inclui informações sobre diversas alterações feitas, em apenas uma mensagem de email. A quantidade de informações incluídas nessas mensagens depende do limite de tamanho definido para mensagens de replicação. Se alguma mensagem exceder o limite de tamanho especificado, ela será enviada como uma mensagem de replicação separada. O Exchange roteia essas mensagens de replicação da mesma maneira que roteia outras mensagens de email. Para obter mais informações sobre roteamento de pastas públicas, consulte Roteamento de mensagens para pastas públicas.
Se você fizer alterações na hierarquia de pastas públicas que afetam várias pastas, o processo de replicação poderá precisar de largura considerável de banda de rede. Por exemplo, para mover as pastas públicas de um servidor para outro, é necessário criar novas réplicas no servidor para o qual deseja mover as pastas públicas, esperar as alterações de hierarquia serem replicadas para o servidor original e, em seguida, esperar o conteúdo ser replicado para as novas réplicas. Depois de as réplicas terem sido sincronizadas, é necessário removê-las do servidor antigo. Mesmo a remoção das réplicas do servidor antigo gera tráfego de rede, pois a remoção das réplicas deve ser replicada como uma alteração de hierarquia. Para saber mais sobre como essas alterações na hierarquia de pastas públicas podem afetar o sistema, consulte "Solicitações e mensagens de status" mais adiante neste tópico.
Processo básico de replicação de hierarquia e conteúdo
A figura a seguir e o texto explicativo que se segue descrevem o processo básico pelo qual hierarquia e conteúdo de pasta pública são replicados.
.gif "Replicação de pasta pública de processo básico")
Os detalhes do processo são os seguintes:
Um usuário modifica a pasta pública.
O banco de dados de pasta pública local registra a alteração.
No próximo ciclo de replicação programada (que é determinado pelo intervalo de replicação definido para o banco de dados de pastas públicas), o banco de dados de pastas públicas verifica as propriedades da pasta para determinar quais outros servidores contêm uma réplica. Se existirem outras réplicas, o banco de dados determinará quais informações devem ser replicadas. Essas informações se tornam a atualização das réplicas.
A replicação das pastas públicas é baseada em objeto. Se uma propriedade de um objeto for modificada, todo o objeto deverá ser replicado. Como o banco de dados que replica a alteração não pode assumir que todas as réplicas de recebimento são atualizadas, ele deverá replicar todo o objeto. As implicações para os diferentes tipos de replicação são:
Replicação de hierarquia A replicação de novas alterações de hierarquia ocorre quando uma pasta pública é criada ou excluída, ou quando uma alteração é feita nas propriedades de uma pasta pública (como uma alteração em lista de réplicas, permissões de cliente, descrição, nota administrativa ou limites de armazenamento).
Replicação de conteúdo Se uma nova mensagem for lançada ou uma existente for modificada, a atualização incluirá toda a mensagem e suas propriedades.
O banco de dados de pasta pública atribui um número de alteração à atualização.
Quando uma pasta replica uma atualização para outro servidor, o número da alteração é incluído com a atualização. O servidor de recebimento usa o número da alteração para determinar se a atualização representa uma nova alteração e se o servidor perdeu algum dado.
Os pacotes do banco de dados de pasta pública são atualizados em uma mensagem de replicação. Os números de alteração de todas as atualizações da mensagem são chamados de conjunto de números da alteração (CNSet*)*.
Juntamente com as atualizações, as informações dos pacotes de bancos de dados de pastas públicas das entradas das pastas que estão na Tabela de Estado de Replicação, incluindo os CNSets que foram anteriormente aplicados à réplica. Para obter mais informações sobre a Tabela de Estado de Replicação, consulte "Tabela de Estado de Replicação" mais adiante neste tópico.
Para reduzir o tráfego de mensagens, o banco de dados de pasta pública coloca várias atualizações de hierarquias em uma única mensagem de replicação. Da mesma maneira, o banco de dados coloca várias atualizações de conteúdo para a mesma pasta em uma única mensagem de replicação. No entanto, o banco de dados não pode colocar as atualizações de hierarquia na mesma mensagem de replicação que as atualizações de conteúdo, e cada mensagem de replicação de conteúdo contém atualizações para uma única pasta.
O banco de dados de pasta pública endereça a mensagem de replicação para os outros bancos de dados de pasta pública que hospedam réplicas da pasta atualizada. O banco de dados envia a mensagem, juntamente com quaisquer outras mensagens que foram colocadas desde o ciclo de replicação anterior.
Para enviar mensagens de replicação, o banco de dados de pasta pública conta com os componentes de roteamento interno do Exchange. O banco de dados não tenta dividir as mensagens de replicação com base nos detalhes da topologia. Se o conteúdo de uma pasta for modificado e a pasta tiver cinco outras réplicas, o banco de dados gerará uma única mensagem de replicação e a endereçará para todos os cinco bancos de dados que hospedam essas réplicas. Os componentes de roteamento determinam como rotear e enviar a mensagem.
O banco de dados de pasta pública recebe a mensagem de replicação.
O banco de dados de pasta pública de recebimento descompacta as informações de status e atualização da mensagem de replicação.
O banco de dados compara os números de alterações das novas atualizações com a lista de números que ele já contém e depois identifica quais atualizações ele não recebeu anteriormente.
O banco de dados aplica as novas atualizações às réplicas de pasta apropriadas.
Para cada réplica atualizada, o banco de dados atualiza a tabela de estados de replicação com os números de alteração da atualização atual e as informações de status de pasta da mensagem de replicação.
Se as informações na Tabela de Estado de Replicação indicarem que outros CNSets foram aplicados a outras réplicas da pasta, mas não às réplicas desse banco de dados, o banco de dados registrará os CNSets que estão faltando em um local chamado matriz de aterramento e preparará o envio de uma solicitação de aterramento. Para obter mais informações sobre solicitações de aterramento, consulte "Solicitações e mensagens de aterramento" mais adiante neste tópico.
Mensagens de replicação
O processo de replicação usa os atributos do Active Directory dos bancos de dados de pasta pública, não os atributos do Active Directory de pastas públicas individuais. Os atributos do Active Directory para pastas públicas individuais são usados apenas para enviar mensagens comuns de email para ou das pastas. Um objeto de banco de dados de pasta pública é configurado e mantido automaticamente e reside no contêiner Configuração do Active Directory.
As mensagens de replicação diferem de outras mensagens de email no sentido que o Exchange trata as mensagens de replicação como mensagens do sistema. Isso significa que as mensagens de replicação não estão vinculadas pelas restrições que são aplicadas às mensagens de email do usuário (como restrições de tamanho e de envio).
A tabela a seguir lista os diferentes tipos de mensagens de replicação usados pelo Exchange.
Dica
Os valores que estão listados entre parêntesis na tabela a seguir são a notação hexadecimal dos tipos de mensagem. Essas notações são usadas em eventos e logs. Você pode usar o valor hexadecimal para solucionar problemas de replicação.
Tipos de mensagens de replicação de pasta pública e quando são usadas
| Tipo de mensagem* | Quando usada |
|---|---|
Hierarquia (0x2) |
Replica as alterações de hierarquia do banco de dados de pasta pública local para todos os outros bancos de dados de pasta pública que oferecem suporte para a mesma hierarquia. Embora o Exchange trate as alterações de hierarquia separadamente das alterações em réplicas de conteúdo, ele trata a hierarquia como se fosse uma outra pasta. Em algumas mensagens de eventos e outras operações, o Exchange refere-se à hierarquia como Pasta 1-1. |
Conteúdo (0x4) |
Replica as alterações de conteúdo de uma réplica para todas as outras réplicas de conteúdo dessa pasta. Uma mensagem de conteúdo contém apenas informações que se aplicam a uma única pasta. |
Solicitação de aterramento (0x8) |
Solicita dados ausentes nos CNSets de outro banco de dados. Isso inclui números de alteração de conteúdo e hierarquia. |
Resposta de aterramento (0x80000002 ou 0x80000004) |
Envia dados ausentes nos CNSets para um banco de dados que solicitou atualizações ausentes. |
Status (0x10) |
Envia o CNSet atual de uma pasta para uma ou mais réplicas dessa pasta. Isso inclui números de alteração de conteúdo e hierarquia. |
Solicitação de status (0x20) |
Solicita os CNSets a serem replicados ou as mensagens de status a serem retornadas. Isso inclui números de alteração de conteúdo e hierarquia. |
Tabela de Estado de Replicação
Cada banco de dados de pasta pública mantém uma Tabela de Estado de Replicação para controlar o status de cada réplica no banco de dados. A Tabela de Estado de Replicação armazena as seguintes informações:
Informações básicas que são exigidas para criar atualizações em cada réplica.
Informações sobre a última atualização em cada réplica originada no banco de dados local, incluindo o número de alteração da atualização.
Grupos de atualizações que foram aplicados a todas as outras réplicas conhecidas da pasta. Os números das alterações identificam as atualizações em cada grupo. O conjunto de números das alterações para todas as atualizações de um grupo é chamado de CNSet. As informações das atualizações são transmitidas de um banco de dados para outro como parte do processo de replicação.
As tabelas a seguir fornecem um exemplo de como as Tabelas de Estado de Replicação funcionam. Nesse exemplo, os bancos de dados de pasta pública no Servidor A e no Servidor B têm réplicas de uma pasta denominada Projetos. Em cada servidor, a Tabela de Estado de Replicação controla não apenas o status da réplica nesse servidor, mas também o status da réplica no outro servidor. Usando essas informações, o Servidor A determina se sua réplica da pasta Projetos será sincronizada com a réplica da pasta Projetos no Servidor B. O Servidor B pode, de maneira semelhante, controlar seu status em relação ao Servidor A.
Dados de amostra da Tabela de Estado de Replicação para o Servidor A
| Réplica | Dados |
|---|---|
A pasta Projetos no Servidor A (réplica local) |
Última atualização enviada: A-100 |
A pasta Projetos no Servidor B |
A-100 recebida B-50 recebida |
Dados de amostra da Tabela de Estado de Replicação para o Servidor B
| Réplica | Dados |
|---|---|
A pasta Projetos no Servidor A |
A-100 recebida B-50 recebida |
A pasta Projetos no Servidor B (réplica local) |
Última atualização enviada: B-50 |
Comparando as listas de bancos de dados de pastas públicas que contêm réplicas de conteúdo com as informações na tabela de estado de replicação, cada banco de dados de pasta pública pode determinar o quão atualizado ele está em comparação com os demais bancos de dados de pastas públicas que aceitam a árvore de pastas públicas.
Solicitações de aterramento e mensagens de aterramento
Aterramento ocorre quando um banco de dados de pasta pública determina que ele não recebeu todas as atualizações para uma pasta replicada (ou para a hierarquia) e deve recuperar as atualizações ausentes de outro banco de dados de pasta pública.
Para simplificar o processo de aterramento, o Exchange 2007 armazena informações sobre atualizações ausentes na matriz de aterramento.
Os eventos a seguir podem alertar um banco de dados de pasta pública para atualizações ausentes que precisam ser aterradas:
As informações de status em uma mensagem de replicação de entrada indica que a réplica no banco de dados de pastas públicas que enviou a mensagem tem atualizações que estão ausentes no banco de dados de recebimento. O banco de dados de recebimento identifica os números das alterações ausentes e os armazena na matriz de aterramento.
Um banco de dados de pasta pública é iniciado pela primeira vez. O novo banco de dados envia solicitações de status para obter informações sobre os outros bancos de dados na hierarquia. Depois que as mensagens de status correspondentes chegam, o banco de dados preenche sua Tabela de Estado de Replicação e, se necessário, a matriz de aterramento. A matriz de aterramento pode conter entradas tanto para a hierarquia como para réplicas de conteúdo que o banco de dados deve hospedar.
Uma mensagem de hierarquia de entrada indica que uma nova réplica de conteúdo deve ser colocada no banco de dados de pasta pública. O novo banco de dados envia solicitações de status para obter informações sobre conteúdo que pode estar disponível para essa réplica nos outros bancos de dados da hierarquia. Depois que as mensagens de status correspondentes chegam, o banco de dados preenche a Tabela de Estado de Replicação e, se necessário, a matriz de aterramento.
A matriz de aterramento armazena essas informações por um período especificado (chamado tempo limite de aterramento). Se as atualizações ausentes chegarem em mensagens de replicação subseqüentes durante esse período, elas serão removidas da matriz de aterramento. A tabela a seguir lista os valores de tempo limite de aterramento padrão, que dependem de onde estão as atualizações ausentes e se elas já foram solicitadas antes.
Tempos limite padrão usados para solicitações de aterramento
| Tipo de solicitação | Existe conteúdo em um banco de dados no site do Active Directory local | Existe conteúdo em um banco de dados de um site do Active Directory remoto |
|---|---|---|
Aterramento inicial |
6 horas |
12 horas |
Primeira repetição de aterramento |
12 horas |
24 horas |
Repetições de aterramento subseqüentes |
24 horas |
48 horas |
Se o tempo limite de aterramento expirar, e as atualizações ainda estiverem ausentes, o Exchange criará uma ou mais solicitações de aterramento e determinará quais servidores usar como fontes de aterramento.
Para selecionar servidores para uso como fonte de aterramento, o Exchange primeiramente cria uma lista de todos os servidores que tenham réplicas da pasta e, em seguida, classifica a lista de acordo com a seguinte seqüência de critérios:
Classificar de acordo com o status do servidor. Os servidores desativados ou indisponíveis vão para o final da lista.
Classificar de acordo com o servidor de aterramento preferido (se houver). O Exchange verifica o objeto do banco de dados de pasta pública no Active Directory para um servidor de aterramento preferido. Essa configuração raramente é usada. Na maioria das circunstâncias, o processo de aterramento opera de maneira mais eficiente se o Exchange seleciona um servidor de aterramento automaticamente. A maioria das implantações do Exchange não precisa de um servidor de aterramento preferido. O Atendimento Microsoft pode fornecer um script que defina um servidor de aterramento preferido se isso for exigido por sua implantação.
Classificar de acordo com o custo do transporte (do mais baixo para o mais alto). Os servidores no mesmo grupo de roteamento têm prioridade perante os servidores em sites remotos do Active Directory.
Classificação de acordo com a versão do Exchange (da mais recente para a mais antiga).
Classificar de acordo com o número de alterações necessárias que estão disponíveis no servidor (do maior para o menor). Os servidores que não tiverem alterações ausentes serão eliminados da lista.
Se um servidor não tiver todas as alterações necessárias, o Exchange selecionará o próximo servidor na lista classificada e enviará uma solicitação de aterramento para esse servidor também. Esse processo é repetido até todas as alterações serem solicitadas.
Se o servidor selecionado não responder à solicitação de aterramento, o banco de dados marcará esse servidor como indisponível e repetirá o processo de seleção. Os servidores marcados como indisponíveis vão para o final da lista.
Solicitações de status e mensagens de status
Além das informações de status em cada mensagem de replicação, o Exchange usa solicitações e mensagens de status para determinar se pastas públicas devem emitir solicitações de aterramento.
Um banco de dados de pasta pública envia uma solicitação de status nos seguintes casos:
O banco de dados é notificado de uma alteração na lista de bancos de dados que contêm réplicas de uma pasta. Por exemplo, se você adicionar um banco de dados à lista ou remover um banco de dados da lista, o Exchange replicará essa alteração usando mensagens de atualização de hierarquia. Nesse caso, o banco de dados envia uma solicitação de status que exige que cada banco de dados que contém uma réplica da pasta responda.
Um novo banco de dados foi iniciado pela primeira vez. Nesse caso, o banco de dados solicita o status da hierarquia de pastas públicas. O banco de dados envia uma solicitação de status que exige que cada banco de dados que oferece suporte à árvore de pastas públicas responda.
Um banco de dados que foi restaurado usando a ferramenta de Backup do Microsoft Windows é iniciado pela primeira vez depois que a restauração é concluída. Nesse caso, o banco de dados solicita o status da hierarquia das pastas públicas e todas as pastas para as quais o banco de dados contém réplicas de conteúdo. Essa solicitação de status lista dois ou três bancos de dados como respondedores exigidos. Os respondedores exigidos são bancos de dados que oferecem suporte a essa hierarquia e, de acordo com um processo de seleção interno, são fontes dependentes de conteúdo da pasta.
Para indicar o estado atual de uma determinada pasta no banco de dados de envio, o banco de dados de pasta pública envia uma mensagem de status para outro banco de dados nos seguintes casos:
Em resposta a uma solicitação de status que é enviada por outro banco de dados. A mensagem de status é enviada apenas para o banco de dados solicitante e apenas se o seguinte for verdade:
O banco de dados que recebeu a solicitação de status está na lista de solicitações dos respondentes exigidos.
A tabela de estado de replicação indica que o banco de dados que recebeu a solicitação de status tem atualizações que estão faltando no banco de dados que enviou a solicitação.
24 horas depois da atualização mais recente de uma pasta ter sido recebida, se não tiver havido nenhuma atualização subseqüente. Cada vez que o banco de dados recebe uma atualização para uma pasta específica, o temporizador é redefinido para 24 horas. Essa mensagem de status é enviada para os outros bancos de dados de pasta pública que contêm réplicas da pasta atualizada.
Se um banco de dados de pasta pública receber uma mensagem de status indicando que o banco de dados de envio tem informações mais recentes sobre a pasta, o banco de dados de recebimento criará uma solicitação de aterramento. Se os números das alterações forem mostrados como sendo iguais (ou os números das alterações no servidor de recebimento forem mais recentes), nenhuma ação será tomada. Por exemplo, quando um banco de dados de pasta pública é iniciado pela primeira vez, ele envia mensagens de solicitação de status para cada banco de dados que oferece suporte à hierarquia de pastas públicas. Cada banco de dados responde com informações sobre o status da hierarquia (conforme controlado pelo banco de dados). O novo banco de dados usa essas informações para identificar quais réplicas (se houver), devem existir. Em seguida, o novo banco de dados pode enviar solicitações de aterramento, conforme necessário, para preencher o conteúdo da réplica.
Exemplos de ciclos de replicação
A figura a seguir ilustra um cenário simplificado de dois servidores que mostra a seqüência de eventos que você aciona ao adicionar uma réplica de conteúdo a um banco de dados de pasta pública. Essa ação adiciona o banco de dados de pasta pública à lista de réplicas da pasta. Observe que a seqüência de etapas depende de fatores, como o tempo dos intervalos de replicação e a topologia do roteamento.
Seqüência de eventos ao adicionar uma réplica a um banco de dados de pasta pública
.gif "adicionar réplica de pasta pública à hierarquia")
Os detalhes do processo são os seguintes:
Trabalhando no ExServ01, um administrador adiciona o ExServ01 a uma lista de réplicas de pasta.
ExServ01 envia uma mensagem de hierarquia.
ExServ02 adiciona ExServ01 à cópia local da lista de réplicas de pasta.
O ExServ01 envia uma solicitação de status para o ExServ02.
ExServ02 envia uma mensagem de status a ExServ01 que inclui o CNSet completo da pasta.
ExServ01 determina que está faltando todo o conteúdo da pasta e registra as entradas apropriadas na matriz de aterramento.
Se o conteúdo ainda estiver ausente decorrido o tempo limite de aterramento, ExServ01 criará uma solicitação de aterramento e a enviará a ExServ02.
ExServ02 compila as mensagens de conteúdo e as envia a ExServ01.
ExServ01 usa as mensagens de conteúdo de entrada para atualizar o conteúdo da pasta e as informações de controle relacionadas.
Se os números das alterações ainda parecerem estar ausentes, o ExServ01 esperará 24 horas e enviará uma solicitação de aterramento atualizada. Se um servidor que não seja o ExServ02 estiver disponível, o ExServ01 poderá enviar a solicitação para esse servidor.
A figura a seguir ilustra um cenário simplificado de dois servidores que mostra a seqüência de eventos que você aciona ao remover uma réplica de um banco de dados de pasta pública. (Essa ação remove o banco de dados de pasta pública da lista de réplicas da pasta.) Observe que a seqüência de etapas depende de fatores, como o número de servidores na topologia.
Seqüência de eventos ao remover uma réplica de um banco de dados de pasta pública
.gif "Excluindo réplica do banco de dados de pasta pública")
Os detalhes do processo são os seguintes:
Trabalhando no ExServ01, um administrador remove o ExServ01 de uma lista de réplicas de pasta.
ExServ01 marca sua réplica (a cópia da pasta em ExServ01) como exclusão pendente.
Os clientes não podem mais acessar a pasta usando esse banco de dados.
ExServ01 envia uma mensagem de hierarquia.
ExServ02 atualiza sua cópia da lista de réplicas de pasta para mostrar que a pasta está no estado de exclusão pendente em ExServ01.
ExServ02 não submete mais a ExServ01 os clientes que estão procurando essa pasta.
ExServ01 envia uma solicitação de status para o ExServ02.
O ExServ02 envia uma mensagem de status para o ExServ01. Se a réplica no ExServ02 não for atualizada, o ExServ02 coloca as entradas adequadas na matriz de aterramento. No prazo de cinco minutos, o ExServ02 envia a solicitação de aterramento correspondente para o ExServ01.
O ExServ01 verifica se a réplica da pasta no ExServ02 contém todas as mesmas informações que a réplica pendente de exclusão. Se não contiver, o ExServ01 enviará as atualizações de conteúdo adequadas e retornará para a Etapa 5. Caso contrário, o ExServ01 irá para a Etapa 8.
Esse processo garante que se houver outras réplicas, a exclusão de uma única réplica não resultará em perda de conteúdo.
O ExServ01 marca sua réplica como "excluir agora". O próximo ciclo de manutenção removerá a réplica do ExServ01.
ExServ01 envia uma mensagem de hierarquia.
ExServ02 remove ExServ01 de sua cópia da lista de réplicas de pasta.
Práticas recomendadas para implementar replicação
A replicação da pasta pública no Exchange pode ser uma operação intensiva de recursos. A replicação exige rede, CPU e recursos de disco para operar. Ao implementar uma solução que permite a replicação eficiente de pasta pública, especialmente em organizações com uso intenso de pastas públicas, você pode melhorar muito a carga da rede, da CPU e do disco na sua organização do Exchange.
Geralmente, é uma prática recomendada minimizar a replicação na organização. Ao minimizar a replicação, você minimiza a quantia de dados que passam pela rede. Além disso, minimizando a replicação, você pode ajudar a garantir a menor probabilidade de que vários usuários acessem diferentes versões de dados em várias réplicas. No entanto, é necessário observar que ao minimizar a replicação, você reduz a disponibilidade dos dados da pasta pública, pois menos réplicas da pasta estarão disponíveis para os clientes se um banco de dados de pasta pública falhar. Se a disponibilidade em larga escala for necessária para dados em uma pasta pública específica, poderá ser necessário mais replicação.
Replicação de pasta pública e replicação contínua
A replicação contínua e a replicação de pasta pública são duas formas muito diferentes de replicação que são incorporadas no Exchange. Devido às limitações de interoperabilidade entre a replicação contínua e a replicação de pasta pública, há uma orientação específica para combinação de replicação de pasta pública com a replicação contínua. Para revisar essa orientação, consulte Planejando a replicação contínua em cluster, Planejando a replicação contínua local e Replicação Contínua Em Espera.
Para obter mais informações
Para saber mais sobre pastas públicas, consulte Compreendendo Pastas Públicas.
Para obter mais informações sobre como gerenciar pastas públicas, consulte Gerenciando pastas públicas.
Para obter mais informações sobre como gerenciar bancos de dados de pastas públicas, consulte Gerenciando bancos de dados de pasta pública.