Alterações na alta disponibilidade e resiliência de site em relação às versões anteriores

Aplica-se a: Exchange Server 2013 SP1

O Exchange 2013 usa DAGs e cópias de banco de dados de caixa de correio, além de outros recursos, como recuperação de itens únicos, políticas de retenção e cópias de banco de dados com atraso, para fornecer alta disponibilidade, resiliência de site e proteção de dados nativos do Exchange. A plataforma de alta disponibilidade, o Exchange Information Store e o Extensible Storage Engine (ESE) são aprimorados para fornecer maior disponibilidade e gerenciamento mais fácil e reduzir custos. Esses aprimoramentos incluem:

• Redução do IOPS no Exchange 2010: isso permite aproveitar discos maiores em termos de capacidade e IOPS da maneira mais eficiente possível.

• Disponibilidade gerenciada: com a disponibilidade gerenciada, o monitoramento interno e os recursos orientados à recuperação estão totalmente integrados para ajudar a impedir falhas, restaurar serviços proativamente e iniciar failovers de servidor automaticamente ou alertar administradores para tomarem uma providência. 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 recém-reescritos do Repositório de Informações no Exchange 2013. O novo Repositório Gerenciado é escrito em C# e possui alta integração com o serviço de Replicação do Microsoft Exchange (MSExchangeRepl.exe) para oferecer disponibilidade maior por meio de resiliência aprimorada.

• Suporte para vários bancos de dados por disco: o Exchange 2013 inclui aprimoramentos que permitem dar suporte a vários bancos de dados (misturas de cópias ativas e passivas) no mesmo disco, aproveitando assim 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: esse recurso continua a inovação introduzida no Exchange 2010 para permitir que o sistema se recupere de falhas que afetam a resiliência ou redundância. Além dos comportamentos de marcar de bugs do Exchange 2010, o Exchange 2013 inclui comportamentos adicionais 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 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. Cópias defasadas também invocarão esse recurso de reprodução automática quando um limite de espaço em disco baixo for atingido e quando a cópia defasada for detectada como a única cópia disponível por um período específico de tempo. Além disso, cópias defasadas podem usar o Safety Net, facilitando 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 de IOPS em relação ao Exchange 2010

No Exchange 2010, as cópias passivas de banco de dados têm uma profundidade de ponto de verificação baixa, o que é necessário para failover rápido. Além disso, a cópia passiva realiza uma pré-leitura agressiva de dados para acompanhar a profundidade de ponto de verificação de 5 MB. Como resultado do uso de uma baixa profundidade de ponto de verificação e da execução dessas operações agressivas de pré-leitura, o IOPS para uma cópia de banco de dados passivo foi igual ao IOPS para uma cópia ativa no Exchange 2010.

No Exchange 2013, o sistema consegue fornecer failover rápido ao usar uma profundidade de ponto de verificação alta na cópia passiva (100 MB). Como as cópias passivas têm profundidade de ponto de verificação de 100 MB, elas são desajustadas para não serem mais tão agressivas. Como resultado do aumento da profundidade de ponto de verificação e do desajuste das pré-leituras agressivas, o IOPS de uma cópia passiva é de aproximadamente 50% do IOPS da cópia ativa no Exchange 2013.

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. No Exchange 2013, o registro em log de ESE foi reescrito para que o cache seja persistido através da 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.

Devido a essas alterações, o Exchange 2013 fornece uma redução significante no IOPS em relação ao Exchange 2010.

Disponibilidade gerenciada

A disponibilidade gerenciada é a integração de monitoramento ativo incorporado e da plataforma de alta disponibilidade do Exchange 2013. 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 nas funções de servidor de Acesso para Cliente e de Caixa de Correio no Exchange 2013. A disponibilidade gerenciada inclui três componentes assíncronos principais que estão constantemente fazendo o trabalho. O primeiro componente é o mecanismo de sondagem, responsável por realizar medições no servidor e coletar os 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, que é 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 de vários estágios; por exemplo, a primeira tentativa pode ser reiniciar o pool de aplicativos; a segunda pode ser reiniciar o serviço; a terceira tentativa pode ser reiniciar o servidor e a tentativa subsequente pode ser colocar o servidor em modo offline, para que ele não aceite mais 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): esse é 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 pela execução das tarefas de runtime.

A disponibilidade gerenciada usa armazenamento persistente para desempenhar 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 disponibilidade gerenciada, consulte Disponibilidade Gerenciada.

Repositório Gerenciado

Todas as versões anteriores do Exchange Server, de Exchange Server 4.0 a Exchange Server 2010, deram 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. Nas arquiteturas anteriores 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 da Store em versões anteriores do Exchange é que o ESE (Mecanismo de Armazenamento Extensível) 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 uma escala negativa. Dado os servidores maiores 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 etc.). 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 se foi 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 os aprimoramentos de armazenamento no Exchange 2013 sejam projetados principalmente para configurações de apenas um grupo de discos (JBOD), eles estão disponíveis para uso por todas as configurações de armazenamento suportadas. 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, com unidades de 8 TB que devem estar disponíveis em breve. Usando unidades de 8 TB em conjunto com as diretrizes de práticas recomendadas de tamanho máximo de banco de dados do Exchange (2 TB), você gastaria mais de 5 TB de espaço em disco. Uma solução seria aumentar os bancos de dados, mas isso inibe a capacidade de gerenciamento porque introduz tempos de ressecamento longos, incluindo, em alguns casos, tempos de ressecabilidade operacionalmente incontroláveis e a confiabilidade de copiar essa quantidade de dados pela rede está comprometida.

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.

Dando continuidade a uma prática de longa data, o Exchange 2013 foi otimizado para que ele possa usar discos grandes (8 TB) em uma configuração JBOD de modo mais eficiente. No Exchange 2013, com vários bancos de dados por disco, você pode ter discos com o mesmo tamanho armazenando várias cópias de banco de dados incluindo cópias com retardamento. 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.

A configuração acima 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. No exemplo acima, existem quatro cópias de cada banco de dados: uma cópia ativa, duas cópias passivas e uma cópia com retardamento. 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 tem um valor de preferência de ativação de 1, a primeira cópia passiva tem um valor de preferência de ativação de 2, a segunda cópia passiva tem um valor de preferência de ativação de 3 e a cópia defasada terá um valor de preferência de ativação de 4.

Além de ter uma distribuição melhor de usuários nos volumes existentes, outro benefício de usar vários bancos de dados por disco é que isso reduz o tempo necessário para restaurar a proteção de dados no caso de uma falha que necessite de uma nova propagação (por exemplo, falha de 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 terabytes pode levar 23 horas para ser reutilizado, enquanto um banco de dados de 8 terabytes pode levar até 93 horas (quase quatro 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 tendo a cópia ativa dos bancos de dados passivos em um volume especificado armazenado em membros DAG separados. O sistema não está mais vinculado à origem no contexto de reseeding 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 resseque e restaure a proteção de dados desses bancos de dados em um período menor de tempo.

Ao usar vários bancos de dados por volume, recomendamos aderir às seguintes boas 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

A nova propagação automática, ou simplesmente AutoReseed, é um recurso que funciona como substituição do que é normalmente uma ação voltada para a administração em resposta a uma falha de disco, um evento de corrupção de banco de dados ou outro problema que necessite de uma nova propagação 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 continua a inovação introduzida no Exchange 2010 para permitir que o sistema se recupere de falhas que afetam resiliência ou redundância. Além dos comportamentos de marcar de bugs do Exchange 2010, o Exchange 2013 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. O Exchange 2010 incluiu os recursos de detecção e recuperação de E/S parada, os quais proporcionaram maior resiliência. Esses recursos estão relacionadas na tabela a seguir.

O Exchange 2013 aprimora a resiliência de servidor e armazenamento incluindo novos comportamentos para outras condições sérias. Essas condições e esses comportamentos são descritos na tabela a seguir.

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. Rede Segura é um recurso de transporte que substitui o recurso do Exchange 2010 conhecido como dumpster de transporte. Rede Segura é similar a dumpster de transporte, por ser 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 a introdução do Safety Net, a ativação de uma cópia de banco de dados defasada torna-se 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 encontrar uma situação em que precisa usar sua cópia com retardamento, você poderá suspender a replicação para ela e copiá-la duas vezes (para preservar a natureza de retardamento do banco de dados e criar uma cópia extra caso você precise dela). Em seguida, faça 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 saudáveis disponíveis (somente ativas ou passivas; cópias de banco de dados defasadas 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, a correção de página está disponível para cópias com retardamento por meio desse recurso de descarte automático. 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. Cópias defasadas também invocam esse recurso de reprodução automática quando um limite de espaço em disco baixo é atingido e quando a cópia defasada é detectada como a única cópia disponível por um período específico de tempo.

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 4 cópias (3 cópias altamente disponíveis e 1 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 confiavelmente e que suas cópias de bancos de dados de caixa de correio sejam íntegras são os principais objetivos das operações diárias de mensagens do Exchange 2013. É necessário monitorar ativamente o hardware, o sistema operacional Windows e os serviços do Exchange. Mas, ao executar em um ambiente de resiliência de caixa de correio do Exchange 2013, é importante monitorar 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. No entanto, em um ambiente JBOD, uma única falha de disco dispara um failover de banco de dados.

No Exchange 2010, o script chamado CheckDatabaseRedundancy.ps1 foi introduzido. 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. Observe que as cópias com retardamento não serão consideradas como estando atrás se elas estiverem dentro dos dez minutos na reprodução de seus logs para seu período de retardamento.

• 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 os alertas do Exchange 2013 do Exchange 2010, o Exchange 2013 usa as seguintes IDs de Evento:

• Evento 4138 (alerta vermelho)

• Evento 4139 (alerta verde)

No Exchange 2013, a funcionalidade nativa foi aprimorada para reduzir o nível de ruído de alerta que pode ocorrer quando vários bancos de dados no mesmo servidor entram em uma condição de cópia única. No Exchange 2010, foram gerados alertas de cópia única, por banco de dados. Como resultado, quando ocorrer um problema no lado do servidor que afete vários bancos de dados e várias cópias de banco de dados, poderão ocorrer tempestades de alertas. Como várias falhas, como problemas de controlador ou memória, ocorrem no lado do servidor, há uma probabilidade moderadamente maior de tal tempestade de alerta ocorrer para cada incidente de servidor. No Exchange 2013, os alertas são agora gerados por servidor. Quando uma interrupção afeta todo um servidor, e a redundância de dados se torna um risco para várias cópias de banco de dados, um alerta único por servidor é gerado agora.

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) criadas pelo sistema têm como base as sub-redes enumeradas pelo serviço de Cluster. Nos ambientes em que várias redes são usadas, e as interfaces de uma determinada rede (por exemplo, a rede MAPI) estavam na mesma sub-rede, havia pouca configuração adicional que um administrador precisava executar. Entretanto, nos ambientes em que as interfaces de uma determinada rede estavam em várias sub-redes, o administrador precisava executar uma tarefa conhecida como recolhimento de redes do DAG.

Em Exchange 2013, o recolhimento das redes DAG não é mais necessário. O Exchange 2013 ainda usa os mesmos mecanismos de detenção para distinguir entre as redes MAPI e de Replicação, mas agora as redes do DAG são recolhidas automaticamente, 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, o Active Manager executa as mesmas verificações e fases de BCS para determinar a integridade da replicação, mas agora inclui o uso de uma restrição em ordem decrescente de estados de integridade. 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 fazem parte dos componentes internos de monitoramento de disponibilidade gerenciada no Exchange 2013. Existem quatro novas verificações adicionais executadas pelo Active Manager (listadas na ordem em que são executadas):

1. 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.

2. 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.

3. 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.

4. 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 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 Web App está saudável.

Serviço de gerenciamento de DAG

Atualização cumulativa 2 (CU2) para a versão Release to Manufacturing (RTM) do Exchange 2013 contém um novo serviço em servidores de caixa de correio que são membros de um DAG. Este serviço é chamado de Microsoft Exchange DAG Management Service (MSExchangeDAGMgmt). Este novo serviço contém funcionalidade de monitoramento DAG interna que anteriormente era executada dentro do serviço de Replicação do Microsoft Exchange (MSExchangeRepl).

DAGs sem um ponto de acesso administrativo de cluster

Todos os DAGs 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. O Windows Server 2012 R2 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:

• Não há nenhum endereço IP atribuído ao cluster e, portanto, nenhum recurso de endereço IP no grupo de recursos do cluster core.

• Não há nenhum nome de rede atribuído ao cluster e, portanto, nenhum Recurso de Nome de Rede no grupo de recursos do cluster core

• O nome do cluster não está registrado no DNS e não é resolvível na rede.

• Um objeto de nome de cluster (CNO) não é criado no Active Directory.

• O cluster de failover do Windows não pode ser gerenciado usando a ferramenta Gerenciamento de Cluster de Failover. O gerenciamento deve ser feito com o Windows PowerShell e os cmdlets do PowerShell devem ser executados em membros individuais do cluster.

Ao executar no Windows Server 2012 R2 ou posterior, o Service Pack 1 (SP1) para Exchange 2013 e posterior permite que você crie um DAG sem um ponto de acesso administrativo de cluster. Você pode criar um DAG sem um ponto de acesso administrativo usando o centro de administração do Exchange ou usando o Shell. Para obter mais informações, consulte Criando DAGs e Criar um grupo de disponibilidade de banco de dados.