Estamos movendo vários terabytes de caixas de correio de um Ex2010 DAG para outro - mesma sub-rede para as caixas de correio ativas, o destino tem membros em um link de WAN, mas atualmente são cópias passivas. Este processo parece ter sido mais rápido quando começamos e está rodando bem devagar agora. Não tenho métricas sólidas sobre isso do passado, mas o BytesTransferredPerMinute geralmente está abaixo de dois dígitos agora, onde estava em várias centenas anteriormente.
Todos os nossos bancos de dados de destino (no novo DAG) foram definidos como "secondcopy" para DataMoveReplicationConstraint - temos dois membros aqui no HQ, na mesma sub-rede dos servidores de origem, e as filas de replicação para esses dois membros são de um dígito, principalmente zeros. Temos números mais altos para os membros no link WAN, que é o comportamento que vimos quando as coisas estavam funcionando bem - a mudança para o novo DAG é rápida nos servidores HQ e fica atrasada nos servidores DR porque tem para atravessar um link WAN de 50 Mb. Portanto, esse não deve ser o problema, aberto para investigar mais se houver um bug ou comportamento inesperado da API de garantia de dados do MRS.
Reduzi o serviço MRS para executar apenas 2 de cada vez e não melhorou muito. Agora, executando o PerfMon, estou vendo o que eu acho que são valores altos em "movimentos paralisados (replicação de banco de dados)", "falhas transitórias (rede)", "solicitações de movimento: paradas". Ativei o log de diagnóstico para ambos os itens em MRS para "Expert" e não está realmente me mostrando muita coisa, exceto "semeadura inicial", etc. Os status da cópia do banco de dados são bons.
Existe algum outro lugar para procurar para ter uma ideia do que o Exchange está vendo como o motivo do problema? Prefiro não ter que começar pela infraestrutura e verificar se está tudo ótimo; Eu gostaria de saber especificamente com o que o Exchange está insatisfeito e partir daí.
Eu sou um marrom. Há um registro muito bom na
"get-moverequeststatistics -includereport"bandeira.