Alterações na alta disponibilidade e resiliência do site em relação às versões anteriores do Exchange Server
Exchange Server 2013 e posterior usa cópias de banco de dados DAGs e caixas de correio (juntamente com outros recursos, como recuperação de item único, políticas de retenção e cópias de banco de dados defasadas) para fornecer alta disponibilidade, resiliência do site e proteção de dados nativos do Exchange. A plataforma de alta disponibilidade, o Exchange Information Store e o ESE (Mecanismo de Armazenamento Extensível) foram aprimorados desde o Exchange 2010 para fornecer disponibilidade e gerenciamento menos complexo e reduzir custos. Esses aprimoramentos incluem:
Redução do IOPS: isso permite que você use discos maiores em termos de capacidade e IOPS da maneira mais eficiente possível.
Disponibilidade gerenciada: com a disponibilidade gerenciada, os recursos de monitoramento interno e orientados à recuperação são fortemente integrados para ajudar a evitar falhas, restaurar serviços proativamente e iniciar failovers de servidor automaticamente ou alertar os administradores a tomar medidas. O foco está no monitoramento e no gerenciamento da experiência do usuário final em vez de apenas no servidor e no tempo de operação de componentes, para ajudar a manter o serviço continuamente disponível.
Loja Gerenciada: a Loja Gerenciada é o nome dos processos reescritos do Repositório de Informações no Exchange 2013 ou posterior. A Loja Gerenciada é escrita em C# e fortemente integrada ao serviço de Replicação do Microsoft Exchange (MSExchangeRepl.exe) para fornecer maior disponibilidade por meio de resiliência aprimorada.
Suporte para vários bancos de dados por disco: aprimoramentos permitem dar suporte a vários bancos de dados (misturas de cópias ativas e passivas) no mesmo disco, usando discos maiores em termos de capacidade e IOPS da maneira mais eficiente possível.
AutoReseed: o recurso de resseque automático permite que você restaure rapidamente a redundância do banco de dados após falha no disco. Se um disco falhar, a cópia de banco de dados armazenada nesse disco será copiada da cópia de banco de dados ativa para um disco reserva no mesmo servidor. Se várias cópias de banco de dados forem armazenadas no disco com falha, todas elas poderão ser automaticamente repropagadas em um disco reserva. Isso permite propagações mais rápidas, visto que os bancos de dados ativos provavelmente estão em vários servidores, e os dados são copiados em paralelo.
Recuperação automática de falhas de armazenamento; este recurso dá continuidade à inovação introduzida no Exchange 2010 para permitir que o sistema se recupere de falhas que afetam a resiliência ou a redundância. O Exchange agora inclui mais comportamentos de recuperação por tempos longos de E/S, consumo excessivo de memória por MSExchangeRepl.exe e casos graves em que o sistema está em um estado tão ruim que os threads não podem ser agendados.
Aprimoramentos de cópia defasados: as cópias defasadas agora podem cuidar de si mesmas até certo ponto usando a reprodução automática de log. As cópias defasadas reproduzirão automaticamente arquivos de log em várias situações, como patching de página e cenários de baixo espaço em disco. Se o sistema detectar que o patch de página é necessário para uma cópia defasada, os logs serão reproduzidos automaticamente na cópia defasada para fazer patch de página. As cópias com retardamento chamarão esse recurso de reprodução automática quando um limite de pouco espaço em disco for atingido e quando a cópia com retardamento tiver sido detectada como a única disponível para um período específico. Além disso, cópias defasadas podem usar o Safety Net, facilitando muito a recuperação ou a ativação.
Aprimoramentos de alerta de cópia única: o alerta de cópia única introduzido no Exchange 2010 não é mais um script agendado separado. Ele está agora integrado aos componentes de disponibilidade gerenciados no sistema e é uma função nativa no Exchange.
Configuração automática da rede DAG: as redes DAG podem ser configuradas automaticamente pelo sistema com base nas configurações. Além das opções de configuração manual, os DAGs podem também fazer a distinção entre as redes MAPI e de replicação e configurar as redes do DAG automaticamente.
Redução do IOPS
No Exchange 2010, as cópias passivas de banco de dados têm uma profundidade de ponto de verificação baixa, que é necessária para failover rápido. Além disso, a cópia passiva faz uma pré-leitura agressiva de dados para acompanhar uma profundidade de ponto de verificação de 5 megabytes (MB). Como resultado do uso de uma baixa profundidade de ponto de verificação e de fazer essas operações agressivas de pré-leitura, o IOPS para uma cópia de banco de dados passivo é igual ao IOPS para uma cópia ativa no Exchange 2010.
No Exchange 2013 ou posterior, o sistema pode fornecer failover rápido usando uma profundidade de ponto de verificação alta na cópia passiva (100 MB). Como as cópias passivas têm uma profundidade de ponto de verificação de 100 MB, elas foram desajustadas para não serem mais agressivas. Como resultado de aumentar a profundidade do ponto de verificação e desafinar as pré-leituras agressivas, o IOPS para uma cópia passiva é cerca de 50% do IOPS de cópia ativo.
Ter uma profundidade de ponto de verificação mais alta na cópia passiva também resulta em outras alterações. No failover no Exchange 2010, o cache de banco de dados é liberado conforme o banco de dados é convertido de uma cópia passiva para uma ativa. A partir do Exchange 2013, o registro em log do ESE foi reescrito para que o cache seja persistente durante a transição de passivo para ativo. Como ESE não precisa liberar o cache, você obtém failover rápido.
Uma outra alteração foi feita para o processo de manutenção de banco de dados em segundo plano (BDM). A BDM agora processa cerca de 1 a 2 MB por segundo por cópia.
Como resultado dessas alterações, o Exchange agora fornece uma redução significativa no IOPS em relação ao Exchange 2010.
Disponibilidade gerenciada
A Disponibilidade Gerenciada é a integração de monitoramento interno e ativo e a plataforma de alta disponibilidade do Exchange. Com disponibilidade gerenciada, o sistema pode determinar quando fazer o failover de um banco de dados com base na integridade do serviço. A Disponibilidade Gerenciada é uma infraestrutura interna implantada nos serviços de acesso ao cliente (front-end) e serviços de back-end em servidores de caixa de correio. A Disponibilidade Gerenciada inclui três componentes assíncronos principais que estão constantemente funcionando:
O primeiro componente é o mecanismo de investigação, responsável por fazer medidas no servidor e coletar dados. Os resultados dessas medições fluem para o segundo componente, o monitor.
O monitor contém toda a lógica de negócios usada pelo sistema com base no que é considerado íntegro nos dados coletados. De modo similar a um mecanismo de reconhecimento de padrão, o monitor analisa os vários e diferentes padrões em todas as medições coletadas e, então, decide se algo pode ser considerado íntegro.
Por fim, há o mecanismo de resposta, responsável pelas ações de recuperação.
Quando algo perde integridade, a primeira ação é tentar recuperar esse componente. Isso pode incluir ações de recuperação em vários estágios; por exemplo:
Reiniciar o pool de aplicativos.
Reinicie o serviço.
Reiniciar o servidor.
Deixe o servidor offline para que ele não aceite mais o tráfego.
Se as ações de recuperação não tiverem êxito, o sistema escalará o problema a uma pessoa por meio de notificações de log de eventos.
A disponibilidade gerenciada é implementada na forma de dois serviços:
Serviço do Exchange Health Manager (MSExchangeHMHost.exe): este é um processo de controlador usado para gerenciar processos de trabalho. É usado para criar, executar, iniciar e interromper o processo de trabalho, conforme necessário. É também usado para recuperar o processo de trabalho caso o processo falhe, para impedir que o processo de trabalho seja um ponto de falha único
Processo do Exchange Health Manager Worker (MSExchangeHMWorker.exe): esse é o processo de trabalho responsável por executar as tarefas de runtime.
A disponibilidade gerenciada usa o armazenamento persistente para executar suas funções:
Os arquivos de configuração XML são usados para inicializar as definições de item de trabalho durante a inicialização do processo de trabalho.
O Registro é usado para armazenar dados de tempo de execução, como indicadores.
A infraestrutura do log de eventos do canal crimson é usada para armazenar os resultados de item de trabalho.
Para obter mais informações sobre a disponibilidade gerenciada, consulte Disponibilidade gerenciada.
Repositório Gerenciado
As versões anteriores e do Exchange 2010 dão suporte à execução de uma única instância do processo do Repositório de Informações (Store.exe) na função de servidor caixa de correio. Essa única instância da Loja hospeda todos os bancos de dados no servidor: ativo, passivo, defasado e recuperação. Nessas arquiteturas do Exchange, há pouco, se houver, isolamento entre os diferentes bancos de dados hospedados em um servidor de caixa de correio. Um problema com um único banco de dados de caixa de correio tem o potencial de afetar negativamente todos os outros bancos de dados e falhas resultantes de uma corrupção na caixa de correio podem afetar o serviço para todos os usuários cujos bancos de dados estão hospedados nesse servidor.
Outro desafio com uma única instância do Store é a falta de escalabilidade do processador com o ESE (Mecanismo de Armazenamento Extensível). O ESE escala bem para núcleos de processador de 8 a 12, mas além disso, problemas de comunicação entre processadores e sincronização de cache levam a um desempenho negativo. Dado os servidores de hoje com mais de 16 sistemas principais disponíveis, isso imporia o desafio administrativo de gerenciar a afinidade de 8 a 12 núcleos para ESE e usar os outros núcleos para processos não armazenados (por exemplo, Assistentes, Search Foundation, Disponibilidade Gerenciada e assim por diante). Além disso, a arquitetura anterior restringiu a expansão para o processo store.
O processo Store.exe evoluiu consideravelmente ao longo dos anos à medida que Exchange Server evoluiu, mas como um único processo, em última análise, sua escalabilidade é limitada e representa um único ponto de falha. Devido a esses limites, Store.exe foi removido no Exchange 2013 e substituído pela Loja Gerenciada.
Para obter mais informações, consulte Loja Gerenciada.
Vários bancos de dados por volume
Embora as melhorias de armazenamento no Exchange sejam projetadas principalmente para apenas um monte de configurações JBOD (discos), elas estão disponíveis para uso por todas as configurações de armazenamento com suporte. Um recurso é a disponibilidade de hospedar vários bancos de dados no mesmo volume. Esse recurso é sobre a otimização do Exchange para discos grandes. Essas otimizações resultam em um uso muito mais eficiente de discos grandes em termos de capacidade, IOPS e tempos de nova propagação e devem resolver os desafios associados à execução em uma configuração de armazenamento JBOD:
Os tamanhos de banco de dados devem ser gerenciáveis.
As operações de nova propagação devem ser rápidas e confiáveis.
Embora a capacidade de armazenamento esteja aumentando, o IOPS não aumenta.
As cópias de banco de dados passivas de hospedagem de discos estão subutilizadas em termos de IOPS.
Cópias com retardamento têm requisitos de armazenamento assimétrico.
Existe agilidade limitada para se recuperar de condições de pouco espaço em disco.
A tendência de aumento da capacidade de armazenamento continua. Por exemplo, a diretriz de prática recomendada do Exchange para o tamanho máximo do banco de dados (2 terabytes) em uma unidade de 8 terabytes significa que você desperdiçaria mais de 5 terabytes de espaço em disco.
Uma solução seria aumentar os bancos de dados, mas isso inibe a capacidade de gerenciamento porque pode introduzir tempos de ressecamento longos (incluindo tempos de reseados operacionalmente incontroláveis) e comprometer a confiabilidade de copiar essa quantidade de dados pela rede.
Além disso, no modelo Exchange 2010, o disco que armazena uma cópia passiva fica subutilizado em termos de IOPS. No caso de cópia passiva com retardamento, o disco fica não só subutilizado em termos de IOPS, mas também assimétrico em termos de seu tamanho, em relação aos discos usados para armazenar as cópias ativas e passivas sem retardamento.
O Exchange 2013 e posterior foi otimizado para usar discos grandes (8 terabytes) em uma configuração JBOD de forma mais eficiente. Com vários bancos de dados por disco, agora você pode ter discos do mesmo tamanho armazenando várias cópias de banco de dados, incluindo cópias defasadas. A meta é realizar a distribuição de usuários em um número de volumes existentes, oferecendo um design simétrico em que, durante as operações normais, cada membro do DAG hospeda uma combinação de cópias com retardamento ativas, passivas e opcionais nos mesmos volumes.
Um exemplo de uma configuração que utiliza vários bancos de dados por volume está ilustrada abaixo.
Configuração que usa vários bancos de dados por volume
A configuração no diagrama fornece um design simétrico. Os quatro servidores têm os mesmos quatro bancos de dados hospedados em um único disco por servidor. A questão aqui é que o número de cópias de cada banco de dados que você tem deve ser igual ao número de cópias de banco de dados por disco.
Na configuração no diagrama, há quatro cópias de cada banco de dados: uma cópia ativa, duas cópias passivas e uma cópia defasada. Como há quatro cópias de cada banco de dados, a configuração correta é a que tem quatro cópias por volume.
Além disso, a preferência de ativação é configurada para que seja balanceada no DAG e em cada servidor. Por exemplo:
A cópia ativa terá um valor de preferência de ativação de 1.
A primeira cópia passiva terá um valor de preferência de ativação de 2.
A segunda cópia passiva terá um valor de preferência de ativação de 3.
A cópia defasada terá um valor de preferência de ativação de 4.
Além de ter uma melhor distribuição de usuários entre os volumes existentes, outro benefício de usar vários bancos de dados por disco é uma redução no tempo para restaurar a proteção de dados para falhas que exigem uma resseada (por exemplo, falha no disco).
À medida que um banco de dados cresce, a nova propagação do banco de dados leva cada vez mais tempo. Por exemplo, um banco de dados de 2 TB poderá levar 23 horas para uma nova propagação, ao passo que um banco de dados de 8 TB, até 93 horas (quase 4 dias). Ambas as propagações ocorreriam em cerca de 20 MB por segundo. Isso geralmente significa que um banco de dados muito grande não pode ser propagado dentro de um prazo operacionalmente razoável.
No caso de um cenário de cópia por disco de banco de dados único, a operação de propagação é efetivamente vinculada à fonte, porque ela está sempre propagando o disco a partir de uma única fonte.
Dividindo o volume em várias cópias de banco de dados e armazenando a cópia ativa dos bancos de dados passivos de um determinado volume em membros separados do DAG, o sistema não será mais vinculado à fonte no contexto de nova propagação do disco. Quando um disco com falha é substituído, ele pode ser propagado novamente a partir de várias fontes. Isso permite que o sistema propague novamente e restaure a proteção de dados para esses bancos de dados em um tempo muito menor.
Ao usar vários bancos de dados por volume, recomendamos que você siga estas melhores práticas e requisitos:
Uma única partição de disco lógico por disco físico deve ser usada. Não crie várias partições no disco. Cada cópia de banco de dados e seus arquivos complementares (como logs de transação e índice de conteúdo) devem ser hospedados em um único diretório na partição única.
O número de cópias de banco de dados configuradas por volume deverá ser igual ao número de cópias de cada banco de dados. Por exemplo, se você tiver quatro cópias de seus bancos de dados, você deverá usar quatro cópias por volume.
Cópias de banco de dados devem ter os mesmos vizinhos. (Por exemplo, todas elas devem compartilhar o mesmo disco em cada servidor.)
Equilibre a preferência de ativação no DAG, de forma que cada cópia de banco de dados em um determinado disco tenha um valor de preferência de ativação exclusivo.
Propagação automática
O resseed automático (também conhecido como AutoReseed) é a substituição para o que normalmente é uma ação orientada pelo administrador em resposta a uma falha de disco, evento de corrupção de banco de dados ou outro problema que requer uma reseed de uma cópia de banco de dados. A AutoReseed foi projetada para restaurar automaticamente a redundância de banco de dados após uma falha de disco usando discos sobressalentes provisionados no sistema.
Para obter mais informações, consulte Propagação automática. Para obter etapas detalhadas sobre como configurar o AutoReseed, consulte Configurar o AutoReseed para um grupo de disponibilidade do banco de dados.
Recuperação automática de falhas de armazenamento
A recuperação automática de falhas de armazenamento permite que o sistema se recupere de falhas que afetam resiliência ou redundância. Além dos comportamentos de verificação de bugs introduzidos no Exchange 2010, o Exchange agora inclui comportamentos adicionais de recuperação por tempos longos de E/S, consumo excessivo de memória pelo serviço de Replicação do Microsoft Exchange (MSExchangeRepl.exe) e casos graves em que os threads não podem ser agendados.
Mesmo em ambientes JBOD, os controladores de matriz de armazenamento podem ter problemas, como falhas ou travamentos. A tabela a seguir lista recursos que fornecem recursos de detecção e recuperação de E/S suspensos que fornecem resiliência aprimorada.
| Nome | Cheque | Ação | Limite |
|---|---|---|---|
| Detecção de ES de travamento de banco de dados de ESE | ESE verifica se há E/Ss pendentes | Gera um item de falha no canal crimson para reiniciar o servidor | 240 segundos |
| Pulsação de canal de item de falha | Verifica se os itens de falha podem ser gravados no canal crimson e lidos dele | Canal crimson de pulsações do serviço de replicação e servidor de reinicialização em falhas | 30 segundos |
| Pulsação de disco do sistema | Verifica o estado de disco do sistema do servidor | Envia periodicamente E/S sem buffer ao disco do sistema; reinicia o servidor no limite de pulsações | 120 segundos |
O Exchange 2013 e posterior aprimora a resiliência do servidor e do armazenamento, incluindo comportamentos para outras condições graves. Essas condições e esses comportamentos são descritos na tabela a seguir.
| Nome | Cheque | Ação | Limite |
|---|---|---|---|
| Estado inválido do sistema | Nenhum thread, incluindo threads não gerenciados, pode ser agendado | Reiniciar o servidor | 302 segundos |
| Tempos de I/O longos | Medições de latência de operação de E/S | Reiniciar o servidor | 41 segundos |
| Uso de memória do serviço de replicação | Medir o conjunto de trabalho de MSExchangeRepl.exe | 1: Evento de log 4395 no canal vermelho com uma solicitação de rescisão de serviço 2: Iniciar o término do MSExchangeRepl.exe 3: Se o término do serviço falhar, reinicie o servidor |
4 gigabytes (GB) |
| System Event 129 (Reiniciar barramento) | Verifique o Event 129 no log de eventos do Sistema. | Reiniciar o servidor | Quando ocorrer o evento |
| O banco de dados do cluster trava | As atualizações do Gerenciador de Atualização Globais estão bloqueadas | Reiniciar o servidor | Quando ocorrer o evento |
Aprimoramentos de cópias com retardamento
Os aprimoramentos de cópias com retardamento incluem integração com Rede Segura e desprezo automático de arquivos de log em determinados cenários. O Safety Net foi introduzido no Exchange 2013 para substituir o recurso exchange 2010 conhecido como lixeira de transporte. A Rede de Segurança é semelhante à lixeira de transporte, pois é uma fila de entrega associada ao serviço de transporte em um servidor de caixa de correio. Essa fila armazena cópias de mensagens entregues com êxito ao banco de dados de caixa de correio ativo no servidor de Caixa de Correio. Cada banco de dados de caixa de correio ativo no servidor de Caixa de Correio tem sua própria fila que armazena cópias das mensagens entregues. Você pode especificar por quanto tempo a Rede Segura deve armazenar cópias das mensagens entregues com êxito antes que elas expirem e sejam excluídas automaticamente.
A Rede Segura assume alguma responsabilidade pela redundância de sombra em ambientes do DAG. Nos ambientes do DAG, a redundância de sombra não precisa manter outra cópia da mensagem entregue em uma fila de sombra enquanto aguarda a mensagem entregue ser replicada nas cópias passivas dos bancos de dados de caixa de correio nos outros servidores de Caixa de Correio no DAG. A cópia da mensagem entregue já está armazenada na Rede Segura, portanto, a redundância de sombra pode entregar novamente a mensagem a partir da Rede Segura se necessário.
Com o Safety Net, a ativação de uma cópia de banco de dados defasada fica mais fácil. Por exemplo, considere que você tenha uma cópia com retardamento que tem um retardo de repetição de dois dias. Nesse caso, você configuraria a Rede Segura para um período de dois dias. Se você encontrar uma situação em que precisa usar sua cópia defasada, poderá:
Suspenda a replicação para ele.
Copie-o duas vezes (para preservar a natureza defasada do banco de dados e para criar uma cópia extra caso precise).
Pegue uma cópia e descarte todos os arquivos de log, exceto aqueles no intervalo necessário.
Monte a cópia, que dispara uma solicitação automática para a Rede Segura entregar novamente os últimos dois dias de email.
Com a Rede Segura, não é preciso mais realizar nenhuma busca a partir de onde o ponto de corrupção foi introduzido. Você receberá os últimos dois dias de email, exceto os dados normalmente perdidos em um failover com perdas.
As cópias com retardamento podem agora administrar a si próprias chamando a reprodução de log automática para descartar os arquivos de log em certos cenários:
Quando um limite de pouco espaço em disco é atingido
Quando a cópia com retardamento tem corrupção física e precisa passar por correção de página
Quando há menos de três cópias íntegras disponíveis (apenas ativa ou passiva; cópias de banco de dados com retardamento não são contadas) por mais de 24 horas
No Exchange 2010, a correção de página não estava disponível para cópias com retardamento. No Exchange 2013 ou posterior, o patch de página está disponível para cópias defasadas por meio desse recurso de reprodução automática. Se o sistema detectar que a correção de páginas é necessária para uma cópia com retardamento, os logs serão automaticamente reproduzidos na cópia com retardamento para a correção das páginas. As cópias com retardamento também chamarão esse recurso de reprodução automática quando um limite de pouco espaço em disco for atingido e quando a cópia com retardamento tiver sido detectada como a única disponível para um período específico.
O comportamento de descarte da cópia com retardamento está desabilitado por padrão e pode ser habilitado pela execução do seguinte comando.
Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true
Uma vez habilitado, o descarte ocorrerá quando houver menos de três cópias. Você pode alterar o valor padrão de 3 modificando o seguinte valor do registro DWORD.
HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies
Para habilitar o descarte de limites de pouco espaço em disco, será preciso configurar a seguinte entrada do Registro.
HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagLowSpacePlaydownThresholdInMB
Após configurar essas configurações de Registro, reinicie o serviço de Gerenciamento do Microsoft Exchange DAG para fazer com que as alterações entrem em vigor.
Como exemplo, considere um ambiente em que um determinado banco de dados tem quatro cópias (três cópias altamente disponíveis e uma cópia defasada) e a configuração padrão é usada para ReplayLagManagerNumAvailableCopies. Se uma cópia sem atraso estiver fora de serviço por qualquer motivo (por exemplo, se estiver suspensa, etc) então uma cópia com atraso vai desprezar automaticamente os arquivos de log em 24 horas.
Aprimoramentos de alerta de cópia único
Garantir que seus servidores estejam operando de forma confiável e que suas cópias de banco de dados de caixa de correio sejam saudáveis são os principais objetivos das operações diárias de mensagens do Exchange. É necessário monitorar ativamente o hardware, o sistema operacional Windows e os serviços do Exchange.
Mas em um ambiente de resiliência da caixa de correio do Exchange, é importante que você monitore a integridade e o status do DAG e suas cópias de banco de dados de caixa de correio. É especialmente vital executar o gerenciamento de riscos de redundância de dados e monitorar os períodos em que um banco de dados replicado fica reduzido a apenas uma única cópia. Isso é fundamental em ambientes que não usam a Matriz Redundante de Discos Independentes (RAID) e, em vez disso, implantam configurações JBOD. Em um ambiente RAID, uma única falha de disco não afeta uma cópia de banco de dados de caixa de correio ativa. Entretanto, em um ambiente JBOD, uma única falha de disco disparará um failover de banco de dados.
O script CheckDatabaseRedundancy.ps1 foi introduzido no Exchange 2010. Como seu nome sugere, a finalidade do script é monitorar a redundância de bancos de dados de caixa de correio replicados, confirmando que há pelo menos duas cópias configuradas, íntegras e atualizadas, e alertar um administrador por meio de geração de log de eventos quando houver somente uma cópia íntegra de um banco de dados replicado. Nesse caso, tanto cópias ativas como passivas são contadas ao determinar a redundância.
As condições de cópia única incluem, sem limitações:
Falha de uma cópia ativa para replicar para qualquer cópia passiva.
Falha de todas as cópias passivas, que inclui os estados FailedAndSuspended e Falha, além de estados íntegros em que a cópia está atrás na reprodução ou na cópia de log. As cópias defasadas não serão consideradas para trás se estiverem dentro de 10 minutos na reprodução de seus logs no período de atraso.
Falha do sistema em precisamente conhecer a geração de log atual da cópia ativa.
Como é importante para os administradores saberem quando estão com apenas uma cópia íntegra de um banco de dados, o script CheckDatabaseRedundancy.ps1 foi substituído por uma funcionalidade integrada e nativa que faz parte do Conjunto de Integridade DataProtection da disponibilidade gerenciada.
A funcionalidade nativa ainda alerta os administradores por meio de notificações de log de eventos e para distinguir alertas do Exchange 2013 ou posteriores do Exchange 2010, o Exchange agora usa as seguintes IDs de Evento:
Evento 4138 (alerta vermelho)
Evento 4139 (alerta verde)
A funcionalidade nativa foi aprimorada para reduzir o ruído de alerta que ocorre quando vários bancos de dados no mesmo servidor entram em uma única condição de cópia. No Exchange 2010, foram gerados alertas de cópia única, por banco de dados. Como resultado, um problema em todo o servidor que afetou vários bancos de dados e várias cópias de banco de dados pode causar tempestades de alerta. Como várias falhas são em todo o servidor (por exemplo, problemas de controlador ou memória), havia uma boa chance de que uma tempestade de alerta ocorresse para cada incidente de servidor.
Os alertas agora são gerados por servidor. Quando uma interrupção afeta um servidor inteiro e a redundância de dados se torna em risco para várias cópias de banco de dados, um único alerta por servidor é gerado.
Autoconfiguração de rede do DAG
Uma rede do DAG é uma coleção de uma ou mais sub-redes usadas para tráfego de replicação ou tráfego MAPI. Cada DAG contém um máximo de uma rede MAPI e zero ou mais redes de replicação.
No Exchange 2010, as redes DAG iniciais (por exemplo, DAGNetwork01 e DAGNetwork02) foram criadas pelo sistema com base nas sub-redes que foram enumeradas pelo serviço cluster. Se você tivesse várias redes e as interfaces de uma rede especificada (por exemplo, a rede MAPI) estavam na mesma sub-rede, havia pouca configuração adicional necessária. No entanto, se as interfaces de uma rede especificada estiverem em várias sub-redes, você precisará executar uma tarefa conhecida como redes DAG em colapso.
No Exchange 2013 ou posterior, o colapso de redes DAG não é mais necessário. O Exchange ainda usa os mesmos mecanismos de detecção para distinguir entre o MAPI e as redes de replicação, mas agora ele colapsa automaticamente as redes DAG conforme apropriado.
Além disso, por padrão, as redes do DAG são agora automaticamente gerenciadas pelo sistema. Para exibir propriedades de rede DAG usando o Centro de Administração do Exchange (EAC), você deve configurar o DAG para controle manual de rede modificando as propriedades do DAG usando o EAC ou usando o cmdlet Set-DatabaseAvailabilityGroup para definir o parâmetro ManualDagNetworkConfiguration como $true.
Mudanças para seleção de melhor cópia
A seleção de melhor cópia (BCS) é um processo de algoritmo interno para localizar a melhor cópia de um banco de dados individual a ser ativado, dada uma lista de cópias potenciais para ativação e sua integridade e seu status. O Active Manager seleciona a melhor cópia disponível (e desbloqueada) para se tornar a nova cópia de banco de dados ativa quando a cópia de banco de dados ativa existente falhar ou um administrador executar uma alternância sem destino. No Exchange 2010, o processo de BCS avaliava vários aspectos de cada cópia de banco de dados para determinar a melhor cópia a ser ativada. Isso incluía:
Comprimento da fila de cópia
Comprimento da fila de repetição
Status do banco de dados
Status do índice de conteúdo
No Exchange 2013 ou posterior, o Active Manager executa as mesmas verificações e fases do BCS para determinar a integridade da replicação, mas agora também inclui o uso de uma restrição da ordem decrescente dos estados de saúde. Devido a essas mudanças, a BCS é agora chamada de seleção de melhor cópia e servidor (BCSS).
O BCSS inclui várias novas verificações de integridade que agora fazem parte dos componentes internos de monitoramento de disponibilidade gerenciada no Exchange. Há quatro verificações adicionais executadas pelo Active Manager (listadas na ordem em que são executadas):
All Healthy: verifica se um servidor hospeda uma cópia do banco de dados afetado que tem todos os componentes de monitoramento em um estado íntegro.
Até Normal Healthy: verifica se um servidor hospeda uma cópia do banco de dados afetado que tem todos os componentes de monitoramento com prioridade normal em um estado saudável.
Tudo melhor que a origem: verifica se um servidor hospeda uma cópia do banco de dados afetado que tem componentes de monitoramento em um estado melhor do que o servidor atual que hospeda a cópia afetada.
O mesmo que o Source: verifica se um servidor hospeda uma cópia do banco de dados afetado que tem componentes de monitoramento em um estado que é o mesmo que o servidor atual que hospeda a cópia afetada.
Se a BCSS for chamada como um resultado de um failover disparado por um componente de monitoramento de disponibilidade gerenciada (por exemplo, por meio de um respondente de Failover), uma restrição obrigatória adicional será aplicada onde a integridade de componentes do servidor de destino deve ser melhor que o servidor em que o failover ocorreu. Por exemplo, se uma falha de Outlook na Web (anteriormente conhecida como Outlook Web App) disparar um failover de disponibilidade gerenciada por meio de um respondente de Failover, o BCSS deverá selecionar um servidor que hospeda uma cópia do banco de dados afetado no qual Outlook na Web está saudável.
Serviço de gerenciamento de DAG
O Exchange 2013 CU2 ou posterior inclui o MSExchangeDAGMgmt (Serviço de Gerenciamento de DAG do Microsoft Exchange). Esse serviço contém a funcionalidade interna de monitoramento DAG que estava anteriormente dentro do SERVIÇO de Replicação do Microsoft Exchange (MSExchangeRepl).
DAGs sem um ponto de acesso administrativo de cluster
Todos os DAGs em servidores do Exchange que executam o Windows Server 2008 R2 ou Windows Server 2012 exigem pelo menos um endereço IP em cada sub-rede incluída na rede MAPI. Os endereços IP atribuídos ao DAG são usados pelo cluster do DAG com o ponto de acesso administrativo do cluster (também conhecido como o nome de rede do cluster) para habilitar a resolução de nomes e a conectividade para o cluster (ou, mais precisamente, a conectividade com o membro do cluster que atualmente é proprietário do grupo de recursos principal do cluster) usando o nome do cluster.
Windows Server 2012 R2 ou posterior permite que você crie um cluster de failover sem um ponto de acesso administrativo. Os clusters de failover do Windows sem pontos de acesso administrativos têm as seguintes características:
Nenhum endereço IP é atribuído ao cluster, portanto, não há nenhum recurso de endereço IP no grupo de recursos do núcleo de cluster.
Nenhum nome de rede é atribuído ao cluster, portanto, não há nenhum Recurso de Nome de Rede no grupo de recursos do cluster core.
O nome do cluster não está registrado no DNS e o nome do cluster não é resolvível na rede.
Um objeto de nome de cluster (CNO) não é criado no Active Directory.
Você não pode gerenciar o cluster de failover do Windows usando a ferramenta Gerenciamento de Cluster de Failover. Em vez disso, você precisa usar Windows PowerShell e precisa executar os cmdlets do PowerShell em relação aos membros individuais do cluster.
O Exchange 2013 SP1 ou posterior em execução no Exchange no Windows Server 2012 R2 ou posterior permite criar um DAG sem um ponto de acesso administrativo de cluster. Para obter mais informações, consulte Criando DAGs e Criar um grupo de disponibilidade de banco de dados.