Exportar (0) Imprimir
Expandir Tudo

Alta disponibilidade e resiliência do site

 

Aplicável a: Exchange Server 2013

Tópico modificado em: 2014-06-19

Bancos de dados de caixa de correio e os dados que eles contêm são um dos componentes mais críticos (talvez o mais crítico) de qualquer organização do Exchange. No Microsoft Exchange Server 2013, você pode proteger bancos de dados de caixa de correio e seus dados configurando os bancos de dados de caixa de correio para alta disponibilidade e resiliência de site. O Exchange 2013 reduz o custo e a complexidade de implantar uma solução de mensagens resiliente e altamente disponível, enquanto fornece níveis mais altos de disponibilidade de ponta a ponta e oferece suporte a grandes caixas de correio. Aprimorar os recursos de replicação nativos e a arquitetura de alta disponibilidade no Exchange 2010, Exchange 2013 permite que clientes de todos os tamanhos e em todos os segmentos implantem um serviço de continuidade do sistema de mensagens na organização de maneira econômica.

Procurando tarefas de gerenciamento relacionadas à alta disponibilidade e à resiliência de site? Consulte Gerenciando a alta disponibilidade e resiliência do site.

Sumário

Terminologia principal

Grupos de disponibilidade do banco de dados

Cópias de banco de dados de caixa de correio

Active Manager

Alterações na alta disponibilidade do Exchange 2010

Resiliência do site

API de replicação de terceiros

Documentação de resiliência de site e disponibilidade elevada

Os seguintes termos principais são importantes para entender a alta disponibilidade ou a resiliência de site:

Active Manager

Um componente interno do Exchange executado dentro do serviço de Replicação do Microsoft Exchange responsável pelo monitoramento de falhas e pela ação corretiva por meio de failover em um grupo de disponibilidade de banco de dados (DAG).

AutoDatabaseMountDial

Uma configuração de propriedade de um servidor de Caixa de Correio que determina se uma cópia de banco de dados passiva será montada como a nova cópia ativa, com base no número de arquivos de log ausentes na cópia sendo montada.

Replicação contínua - modo de bloqueio

No modo de bloqueio, cada atualização, ao ser gravada na buffer de log ativo da cópia ativa do banco de dados, também é enviada para um buffer de log em cada uma das cópias passivas da caixa de correio no modo de bloqueio. Quando o buffer de log estiver cheio, cada cópia do banco de dados desenvolve, inspeciona e cria o próximo arquivo de log na sequência de geração.

Replicação contínua - modo de arquivo

No modo de arquivo, os arquivos de log de transações fechadas são enviados da cópia ativa do banco de dados para uma ou mais cópias passivas do bancos de dados.

Grupo de disponibilidade de banco de dados

Um grupo de até 16 servidores de Caixa de Correio do Exchange 2013 que hospedam um conjunto de bancos de dados replicados.

Mobilidade de banco de dados

A capacidade de um banco de dados de caixa de correio do Exchange 2013 ser replicado e montado e outros servidores de Caixa de Correio do Exchange 2013.

Data center

Normalmente, isso se refere a um site do Active Directory; no entanto, pode também se referir a um local físico. No contexto desta documentação, datacenter é igual a site do Active Directory.

modo Coordenação de Ativação do Banco de Dados

A propriedade da configuração do DAG que, quando habilitada, força o serviço de Replicação do Microsoft Exchange a adquirir permissão para montar bancos de dados na inicialização.

Recuperação de desastres

Qualquer processo usado para se recuperar manualmente de uma falha. Pode ser uma falha que afeta um único item, ou uma falha que afeta toda uma localização física.

API de replicação de terceiros do Exchange

Uma API fornecida pelo Exchange que permite o uso de replicação síncrona de terceiros para um DAG, ao invés de replicação contínua.

Alta disponibilidade

Uma solução que fornece disponibilidade de serviço, de dados, e recuperação automática de falhas que afetam o serviço ou dados (como uma falha de rede, armazenamento ou servidor).

Implantação incremental

A capacidade de implantar alta disponibilidade e resiliência de site depois da instalação do Exchange 2013.

Cópia de banco de dados de caixa de correio defasada

Uma cópia de banco de dados passiva que tem um intervalo de repetição de log superior a zero.

Cópia de banco de dados de caixa de correio

Um banco de dados de caixa de correio (arquivo .edb e logs), que é ativo ou passivo.

Resiliência de caixa de correio

O nome de uma solução unificada de alta disponibilidade e resiliência de site no Exchange 2013.

Disponibilidade gerenciada

Um conjunto de processos internos compostos por investigações, monitoramentos e respondentes que incorporam o monitoramento e a alta disponibilidade em todas as funções de servidor e em todos os protocolos.

*over(pronuncia-se "star over")

Abreviação para switchovers (alternâncias) e failovers. Uma alternância é uma ativação manual de uma ou mais cópias de bancos de dados. Um failover é uma ativação automática de uma ou mais cópias de bancos de dados após uma falha.

Rede de Segurança

Anteriormente conhecido como o dumpster de transporte, este é um recurso do serviço de transporte que armazena uma cópia de todas as mensagens por X dias. A configuração padrão é de 2 dias.

Redundância de sombra

Um recurso de servidor de transporte que fornece redundância para mensagens durante todo o tempo em que estão em trânsito.

Resiliência do site

Uma configuração que estende a infraestrutura de mensagens para multiplicar os sites de Active Directory e fornecer continuidade operacional para o sistema de mensagens no caso de uma falha afetar um dos sites.

Terminologia principal

Um DAG é o componente base da estrutura de alta disponibilidade e resiliência de site interna do Exchange 2013. Um DAG é um grupo de até 16 servidores de Caixa de Correio que hospeda um conjunto de bancos de dados e oferece recuperação automática no nível de banco de dados diante de falhas que afetem bancos de dados, redes ou servidores individuais. Qualquer servidor em um DAG pode hospedar uma cópia de um banco de dados de caixa de correio de qualquer outro servidor no DAG. Quando um servidor é adicionado a um DAG, funciona com outros servidores no DAG para oferecer recuperação automática de falhas que afetem bancos de dados de caixa de correio, como uma falha de disco ou uma falha do servidor. Para obter mais informações sobre DAGs, consulte Grupos de Disponibilidade de Banco de Dados.

Terminologia principal

Os recursos de alta disponibilidade e resiliência de site, introduzidos pela primeira vez no Exchange 2010, são usados no Exchange 2013 para criar e manter cópias de bancos de dados. O Exchange 2013 também aproveita o conceito de mobilidade de banco de dados, composto por failovers em nível de banco de dados gerenciados por Exchange.

A mobilidade de banco de dados desconecta bancos de dados dos servidores, adiciona suporte para até 16 cópias de um único banco de dados. Ele também oferece uma experiência nativa para a criação de cópias de um banco de dados.

Definir uma cópia de banco de dados como o banco de dados de caixa de correio ativo é conhecido como alternância. Quando uma falha que afeta um banco de dados ou o acesso a um banco de dados ocorre e um novo banco de dados torna-se a cópia ativa, esse processo é conhecido como failover. Este processo também refere-se a uma falha de servidor na qual um ou mais servidores colocam online o banco de dados que anteriormente estava online no servidor onde a falha aconteceu. Quando uma alternância ou failover ocorre, outros servidores Exchange 2013 tomam conhecimento da alternância quase imediatamente e redirecionam o tráfego de mensagens e os clientes para o novo banco de dados ativo.

Por exemplo, se um banco de dados ativo em um DAG falhar devido a uma falha do armazenamento subjacente, o Active Manager automaticamente se recupera, executando failover para uma cópia do banco de dados em outro servidor de Caixa de Correio no DAG. No Exchange 2013, a disponibilidade gerenciada adiciona novos comportamentos para recuperação a partir de perda de acesso de protocolo a um banco de dados, incluindo a reciclagem de pools de trabalhos de aplicativos, a reinicialização de serviços e servidores e a inicialização de failovers de banco de dados.

Para obter mais informações sobre cópias de banco de dados de caixa de correio, consulte Cópias do Banco de Dados de Caixa de Correio.

Terminologia principal

O Exchange 2013 utiliza o componente do Active Manager apresentado no Exchange 2010 para gerenciar o banco de dados e a integridade de cópia do banco de dados, o status, a replicação contínua e outros aspectos de alta disponibilidade do servidor de Caixa de Correio. Para obter mais informações sobre o Active Manager, consulte Active Manager.

Terminologia principal

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 item único, políticas de retenção e cópias de banco de dados com retardamento, para fornecer alta disponibilidade, resiliência de site e proteção de dados nativos do Exchange. A plataforma de alta disponibilidade, o Repositório de Informações do Exchange e o Mecanismo de Armazenamento Extensível (ESE) foram aprimorados para oferecer maior disponibilidade, gerenciamento mais fácil e reduzir custos. Esses aprimoramentos incluem:

  • Redução de IOPS em relação ao Exchange 2010   Permite utilizar discos maiores em termos de capacidade e IOPS da forma mais eficiente possível.

  • Disponibilidade gerenciada   Com a disponibilidade gerenciada, o monitoramento interno e os recursos orientados a recuperação possuem alta integração para ajudar a impedir falhas, restaurar serviços proativamente e iniciar failovers de servidor automaticamente ou alertar administradores para agir. 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.

  • Repositório Gerenciado   Repositório Gerenciado é o nome dos processos de Repositório de Informações reescritos recentemente 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 de vários bancos de dados por disco   O Exchange 2013 inclui aprimoramentos que lhe permitem dar suporte a vários bancos de dados (misturas de cópias ativas e passivas) no mesmo disco, utilizando dessa forma discos maiores em termos de capacidade e IOPS da forma mais eficiente possível.

  • Nova propagação automática   Permite que você rapidamente restaurar a redundância de banco de dados após uma falha de 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 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. Além dos comportamentos de verificação de bugs do Exchange 2010, o Exchange 2013 inclui comportamentos de recuperação adicionais para tempos de E/S longos e consumo de memória excessivo pelo MSExchangeRepl.exe. Nos casos severos em que o sistema está em um estado inválido, threads não podem ser agendados.

  • Aprimoramentos de cópias com retardamento   As cópias com retardamento podem agora administrar a si próprias até um determinado limite, desprezando o log automático. As cópias com retardamento desprezarão automaticamente os arquivos de log em uma variedade de situações, como cenários de correção de páginas e pouco 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. 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, as cópias com retardamento podem utilizar a Rede de Segurança, tornando a recuperação ou a ativação mais fácil.

  • Aprimoramentos de alerta de cópia única   O alerta de cópia única apresentado 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 do DAG   As redes do DAG podem ser automaticamente configuradas pelo sistema com base nas definições de configuração. 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.

No Exchange 2010, as cópias de banco de dados passivas têm uma profundidade de ponto de verificação muito baixa, o que é necessário para failover mais 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 profundidade de ponto de verificação baixa e realizando essas operações de pré-leitura agressivas, o IOPS de uma cópia de banco de dados passiva foi igual ao IOPS de 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 uma profundidade de ponto de verificação de 100 MB, elas foram desajustadas para não serem mais 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 de 50% no IOPS em relação ao Exchange 2010.

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 vão para o segundo componente, chamado de monitoramento. O monitoramento contém toda a lógica de negócios usada pelo sistema com base no que é considerado íntegro nos dados coletados. Similar ao mecanismo de reconhecimento de padrão, o monitoramento procura os vários padrões diferentes em todas as medições coletadas e pode decidir se algo é considerado íntegro ou não. Finalmente, há o mecanismo de respondente, que é responsável pelas ações de recuperação. Quando algo não é íntegro, a primeira ação é tentar recuperar esse componente. Essas ações podem ser de recuperação em vários estágios; por exemplo, a primeira tentativa pode ser reiniciar o pool de aplicativos, a segunda pode ser reiniciar o serviço, e a terceira, reiniciar o servidor, e a tentativa seguinte, colocar o servidor offline para que 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 de Gerenciador de Integridade do Exchange (MSExchangeHMHost.exe)   Este é um processo de controlador usado para gerenciar processos de trabalho. É usado para criar, executar e 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 Trabalho do Gerenciador de Integridade do Exchange (MSExchangeHMHost.exe)   Este é um processo de trabalho responsável por executar as tarefas de tempo de execução.

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 Monitoramento de Grupos de Disponibilidade de Banco de Dados.

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 simplesmente aumentar os bancos de dados, mas isso inibe a capacidade de gerenciamento porque apresenta tempos de nova propagação muito grandes, incluindo, em alguns casos, tempos de nova propagação operacionalmente não gerenciáveis, e a capacidade de cópia dessa quantidade de dados pela rede fica 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.

Configuração que usa vários bancos de dados por volume

Vários bancos de dados por volume

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 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 e a cópia com retardamento 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 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 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.

A nova propagação automática, ou simplesmente AutoReseed, é um recurso que funciona como substituição do que é normalmente uma ação voltada para 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. O AutoReseed foi projetado para automaticamente restaurar a redundância de banco de dados após uma falha de disco usando discos sobressalentes provisionados no sistema.

Em uma configuração do AutoReseed, uma estrutura de apresentação de armazenamento padronizada é usada, e o administrador escolhe o ponto de partida. O AutoReseed deve restaurar a redundância assim que possível após a falha de uma unidade. Isso envolve o pré-mapeamento de um conjunto de volumes (incluindo volumes de reserva) e bancos de dados que usam pontos de montagem. No caso de uma falha de disco em que o disco não está mais disponível para o sistema operacional ou para gravação, um volume de reserva é alocado pelo sistema, e as cópias de banco de dados afetadas são propagadas novamente de forma automática. O AutoReseed usa o seguinte processo:

  1. O serviço de Replicação do Microsoft Exchange periodicamente verifica e informa que tem um status de FailedAndSuspended.

  2. Quando ele encontra uma cópia com esse status, ele realiza algumas verificações de pré-requisito, como verificar se esta é uma situação de cópia única, se reservas estão disponíveis e se não há nada que possa impedir que o sistema execute uma nova propagação automática.

  3. Se as verificações de pré-requisito forem aprovadas com êxito, o serviço de Replicação do Microsoft Exchange alocará e mapeará uma reserva.

  4. Em seguida, é realizada a operação de propagação.

  5. Após o término da propagação, o serviço de Replicação do Microsoft Exchange verifica se a cópia recém-propagada está íntegra.

Neste ponto, se a falha tiver uma falha de disco, ela precisará de intervenção manual de um operador ou administrador para remover e substituir o disco com falha, formatá-lo, inicializá-lo e reconfigurá-lo como reserva.

O AutoReseed é configurado com o uso de três propriedades do DAG. Duas das propriedades referem-se pontos de montagem em uso. aproveita o fato de que o Windows Server permite vários pontos de montagem por volume. A propriedade AutoDagVolumesRootFolderPath se refere ao ponto de montagem que contém todos os volumes disponíveis. Isso inclui os volumes que hospedam bancos de dados e volumes de reserva. A propriedade AutoDagDatabasesRootFolderPath se refere ao ponto de montagem que contém os bancos de dados. Uma terceira propriedade do DAG, AutoDagDatabaseCopiesPerVolume, é usada para configurar o número de cópias de banco de dados por volume.

Um exemplo de configuração do AutoReseed é ilustrado abaixo.

Exemplo de configuração de AutoReseed

Exemplo de Configuração de Nova Propagação Automática

Nesse exemplo, há três volumes, dois dos quais terão bancos de dados (VOL1 e VOL2) e um deles será um volume de reserva formatado em branco (VOL3).

Para configurar o AutoReseed:

  1. Os três volumes são montados sob um ponto de montagem único. Neste exemplo, um ponto de montagem de C:\ExchVols é usado. Isso representa o diretório usado para obter o armazenamento de bancos de dados do Exchange.

  2. Em seguida, o diretório raiz dos bancos de dados de caixa de correio é montado como outro ponto de montagem. Neste exemplo, um ponto de montagem de C:\ExchDBs é usado. Em seguida, uma estrutura de diretório é criada para que um diretório pai seja criado para o banco de dados. E, no diretório pai, dois subdiretórios são criados: um para arquivo de banco de dados e um para os arquivos de log.

  3. Bancos de dados são criados. O exemplo acima mostra um design simples que usa um banco de dados único por volume. Assim, em VOL1, existem três diretórios: o diretório pai e dois subdiretórios (um para o arquivo de banco de dados de MDB1 e um para seus logs). Embora não detalhado na imagem de exemplo, em VOL2, haveria também três diretórios: o diretório pai e, abaixo dele, um diretório para o arquivo de banco de dados de MDB2 e um para seus arquivos de log.

Nessa configuração, se MDB1 ou MDB2 tiver uma falha, uma cópia do banco de dados com falha será propagada novamente para VOL3 de forma automática.

Para obter mais informações sobre a configuração do AutoReseed, consulte Configurar o AutoReseed para um grupo de disponibilidade do banco de dados.

A recuperação automática de falhas de armazenamento 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. Além dos comportamentos de verificação de bugs do Exchange 2010, o Exchange 2013 inclui comportamentos de recuperação adicionais para tempos de E/S longos e consumo de memória excessivo pelo serviço de Replicação do Microsoft Exchange (MSExchangeRepl.exe). Nos casos severos, threads não podem ser agendados.

Mesmo em ambientes JBOD, os controladores de matriz de armazenamento podem ter problemas, como travar ou parar. incluindo a detecção de E/S paradas e recursos de recuperação que ofereceram uma maior resiliência. Esses recursos estão relacionadas na tabela a seguir.

 

Nome Verificar Action 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 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.

 

Nome Verificar Action 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. Gerar log de evento 4395 no canal crimson com uma solicitação de cancelamento do serviço

  2. Iniciar encerramento de MSExchangeRepl.exe

  3. Se o encerramento 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

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 da Rede Segura , a ativação de uma cópia de banco de dados com retardamento se torna bem 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 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 (ativas ou passivas) há 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. 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.

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\ReplayLagPlayDownPercentDiskFreeSpace

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 é particularmente crucial em ambientes que não usam RAID e, em vez disso, implantam configurações de 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.

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.

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.

No Exchange 2013, o recolhimento de redes do DAG não é mais necessário. O Exchange 2013 ainda usa os mesmos mecanismos de detecção para distinguir entre as redes MAPI e de replicação, mas agora automaticamente recolhe as redes do DAG conforme apropriado para você.

Além disso, por padrão, as redes do DAG são agora automaticamente gerenciadas pelo sistema. Para exibir as propriedades da rede do DAG usando o Centro de Administração do Exchange (EAC), você deverá configurar o DAG para controle de rede manual modificando as propriedades do DAG usando o EAC, ou utilizando o cmdlet Set-DatabaseAvailabilityGroup para definir o parâmetro ManualDagNetworkConfiguration como True.

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

A BCSS inclui diversas verificações de integridade novas que fazem parte dos componentes integrados 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. Tudo Íntegro   Verifica um servidor que hospeda uma cópia do banco de dados afetado que tem todos os componentes de monitoramento em um estado íntegro.

  2. Até Integridade Normal   Verifica um servidor que hospeda uma cópia do banco de dados afetado que tem todos os componentes de monitoramento com prioridade Normal em um estado íntegro.

  3. Tudo Melhor que Fonte   Verifica um servidor que hospeda uma cópia do banco de dados afetado que tem componentes de monitoramento em um estado melhor que o servidor atual que hospeda a cópia afetada.

  4. Mesmo que Fonte   Verifica um servidor que hospeda uma cópia do banco de dados afetado que tem componentes de monitoramento em um estado igual ao do 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 do Microsoft Office Outlook Web App disparar um failover de disponibilidade gerenciada por meio de um respondente de Failover, a BCSS deverá selecionar um servidor que hospeda uma cópia do banco de dados afetado em que o Outlook Web App é integro.

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

Todos os DAGs em execução no Windows Server 2008 R2 ou no Windows Server 2012 exigem pelo menos um endereço IP em todas as sub-redes incluídas 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á endereço IP atribuído ao cluster e, portanto, nenhum Recurso de Endereço IP no grupo de recursos principais do cluster.

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

  • O nome do cluster não é registrado no DNS e não pode ser resolvido na rede.

  • Um objeto de nome do cluster (CNO) é criado no Active Directory.

  • O cluster de failover do Windows não pode ser gerenciado usando a ferramenta Gerenciamento de Cluster de Failover. Ele deve ser gerenciado usando 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, veja Criando DAGs e Criar um Grupo de Disponibilidade de Banco de Dados.

Embora o Exchange 2013 continue a usar os DAGs e o Cluster de Failover do Windows para alta disponibilidade da função de servidor de Caixa de Correio e resiliência de site, a resiliência de site não é a mesma no Exchange 2013. A resiliência de site é muito melhor no Exchange 2013 porque ela foi simplificada. As alterações de arquitetura subjacentes que foram feitas no Exchange 2013 têm impacto significativo nos aspectos de recuperação de uma configuração de resiliência de site.

No Exchange 2010, a recuperação de caixa de correio (DAG) e de acesso para cliente (matriz de servidor de Acesso para Cliente) era feita em conjunto. Se perdesse todos os seus servidores de Acesso para Cliente ou o VIP para a matriz ou perdesse uma parte significativa do seu DAG, você ficaria em uma situação em que precisava fazer uma alternância de data center. Esse é um processo bem-documentado e geralmente bem-compreendido, embora leve tempo para ser executado e exija intervenção humana para iniciar o processo.

No Exchange 2013, se perder sua matriz de servidor de Acesso para Cliente (por exemplo, o balanceador de carga falhar), você não precisará realizar uma alternância de data center. Com a configuração correta, o failover ocorre no nível de cliente, e os clientes são automaticamente redirecionados para um segundo data center que tem servidores de Acesso para Cliente operacionais, e esses servidores usam um proxy na comunicação de volta para o servidor de Caixa de Correio, que permanece não afetado pela interrupção (porque você não faz uma alternância). Em vez de trabalhar para recuperar o serviço, o serviço se autorrecupera e você pode se concentrar na correção do problema principal (por exemplo, substituir o balanceador de carga com falha).

Além do mais, com a simplificação de namespace, a consolidação de funções de servidor, a remoção dos requisitos de função de servidor do site do Active Directory, a separação da matriz do servidor de Acesso para Cliente e a recuperação do DAG, além das alterações de balanceamento de carga, há mudanças no Exchange 2013 que agora permitem que a recuperação do servidor de Acesso para Cliente e do DAG seja separada e automática nos sites, fornecendo dessa forma cenários de failover de datacenter, se você tiver três locais.

No Exchange 2010, era possível implantar um DAG entre dois data centers e hospedar o testemunha em um terceiro data center e habilitar o failover para a função de servidor de Caixa de Correio para um dos data centers. Mas, você não obtinha failover para a própria solução porque o namespace ainda precisava ser manualmente alterado para as funções de servidor que não são de Caixa de Correio.

No Exchange 2013, o namespace não precisa acompanhar o DAG. O Exchange utiliza a tolerância a falhas integrada ao namespace por meio de vários endereços IP, balanceamento de carga (e se necessário, a capacidade de colocar os servidores em operação e tirá-los de operação). Os clientes HTTP modernos funcionam com esta redundância automaticamente. A pilha HTTP pode aceitar vários endereços IP para um nome de domínio totalmente qualificado (FQDN), e se o primeiro endereço IP que ela tentar tiver falha grave (ou seja, não conseguir se conectar), ela tentará o próximo endereço IP na lista. Em uma falha de software (conexão perdida após estabelecimento da sessão, talvez devido a uma falha intermitente no serviço em que, por exemplo, um dispositivo está ignorando pacotes e precisa ser retirado de operação), pode ser que o usuário precise atualizar seu navegador.

Isso significa que o namespace não é mais um ponto único de falha, como era no Exchange 2010. No Exchange 2010, talvez o maior ponto único de falha no sistema de mensagens seja o FQDN que você fornece aos usuários porque ele informa o usuário aonde ir. No paradigma do Exchange 2010, mudar onde esse FQDN vai não é tão fácil porque você precisa alterar o DNS e lidar com a latência de DNS, o que em algumas partes do mundo é muito ruim. E você tem caches de nome nos navegadores que geralmente levam cerca de 30 minutos ou mais e com os quais é preciso lidar também.

Uma das mudanças no Exchange 2013 é permitir que os clientes tenham mais de um lugar para ir. Considerando que o cliente tem a capacidade de usar mais de um lugar para ir (quase todos os protocolos de acesso para cliente no Exchange 2013 são baseados em HTTP - exemplos incluem Outlook, Outlook em Qualquer Lugar, EAS, EWS, OWA e EAC - e todos os clientes HTTP com suporte têm a capacidade de usar vários endereços IP), proporcionando dessa forma failover no lado do cliente. Você pode configurar o DNS para lidar com vários endereços IP para um cliente durante uma resolução de nome. O cliente solicita mail.contoso.com e recebe de volta dois endereços IP ou quatro endereços IP, por exemplo. Contudo, vários endereços IP que o cliente recebe de volta serão usados de maneira confiável pelo cliente. Isso torna o cliente bem melhor porque se um dos endereços IP falhar, o cliente tem outros endereços IP para tentar se conectar. Se um cliente tentar um e ele falhar, ele aguardará cerca de 20 segundos e tentará o próximo na lista. Dessa forma, se você perder o VIP para a matriz de servidor de Acesso para Cliente, a recuperação dos clientes acontecerá automaticamente e em aproximadamente 21 segundos.

Os benefícios são os seguintes:

  • No Exchange 2010, se você perdesse o balanceador de carga no seu data center principal e não tivesse outro nesse site, era necessário fazer uma alternância de data center. No Exchange 2013, se perdesse o balanceador de carga no seu site principal, você simplesmente o desativava (ou talvez desativava o VIP) e o reparava ou substituía. Os clientes que ainda não estão usando o VIP no data center secundário farão automaticamente failover para o VIP secundário sem nenhuma alteração de namespace e sem nenhuma alteração no DNS. Isso não só significa que você não precisará mais realizar a alternância, mas também que todo o tempo normalmente associado a uma recuperação de alternância de data center não será gasto. No Exchange 2010, você precisava lidar com a latência de DNS (daí, a recomendação para definir a vida útil (TTL) como 5 minutos, e a introdução da URL de failback). No Exchange 2013, não é preciso fazer isso porque você obtém failover rápido (20 segundos) do namespace entre VIPs (data centers).

  • Como você pode fazer o failover do namespace entre os data centers, tudo o que você precisa para realizar um failover de data center é um mecanismo de failover da função de servidor de Caixa de Correio entre data centers. Para obter um failover automático para o DAG, você simplesmente arquiteta uma solução em que o DAG é dividido igualmente entre dois data centers e coloca o servidor testemunha em um terceiro local, de forma que possa ser arbitrado pelo membros do DAG em qualquer um dos data centers, independentemente do estado da rede entre os data centers que contêm os membros do DAG.

  • Nesse cenário, os esforços do administrador são para simplesmente corrigir o problema e não para restaurar o serviço. Você simplesmente corrige a coisa que falhou; enquanto isso, o serviço está em operação, e a integridade dos dados foi mantida. O nível de urgência e estresse que você sente ao reparar um dispositivo quebrado não é nada como a urgência e o estresse que sente quando está trabalhando para restaurar o serviço. É melhor para o usuário e menos estressante para o administrador.

Você pode permitir que o failover ocorra sem precisar realizar switchbacks (às vezes mencionadas incorretamente como failbacks). Se perder os servidores de Acesso para Cliente no datacenter principal e isso resultar em uma interrupção de 20 segundos para os clientes, você não precisará se preocupar com o failback. Nesse ponto, sua preocupação principal seria corrigir o problema principal (por exemplo, substituir o balanceador de carga com falha). Quando isso estiver online novamente e funcionando, alguns clientes começarão a usá-lo, e outros poderão continuar operacional por meio do segundo data center.

O Exchange 2013 também fornece funcionalidade que permite aos administradores lidar com falhas intermitentes. Uma falha intermitente é quando, por exemplo, a conexão TCP inicial pode ser feita, mas nada acontece em seguida. Uma falha intermitente requer que um tipo de ação administrativa extra seja executada porque ela pode ser resultado de um dispositivo de substituição sendo colocado em operação. Enquanto este processo de reparo estiver ocorrendo, o dispositivo poderá ser ligado e aceitar algumas solicitações, mas não estará realmente pronto para atender os clientes até a execução das etapas de configuração necessárias. Nesse cenário, o administrador pode executar uma alternância de namespace simplesmente removendo o VIP do dispositivo sendo substituído a partir do DNS. Em seguida, durante esse período de serviço, nenhum cliente tentará se conectar a ele. Quando o processo de substituição tiver terminado, o administrador poderá adicionar o VIP de volta ao DNS, e os clientes finalmente começarão a utilizá-lo.

Para detalhes sobre planejamento e implantação de resiliência do site, consulte Planejamento de alta disponibilidade e de resiliência do site e Implantando a alta disponibilidade e resiliência do site.

Terminologia principal

O Exchange 2013 também inclui uma API de replicação de terceiros que permite que as organizações usem soluções de replicação síncronas de terceiros, ao invés do recurso de replicação contínua interno. A Microsoft oferece suporte a soluções de terceiros que usam essa API, desde que a solução ofereça as funcionalidades necessárias para substituir todas as funcionalidades nativas de replicação contínua que são desabilitadas como resultado do uso da API. As soluções têm suporte apenas quando a API é usada dentro de um DAG para gerenciar e ativar cópias do banco de dados de caixa de correio. Não há suporte ao uso da API fora desses limites. Além disso, a solução deve atender às especificações aplicáveis de suporte a hardware do Windows. (O teste de validação não é necessário para suporte.)

Ao implantar uma solução que use a API de replicação interna de terceiros, lembre-se que o fornecedor da solução é responsável pelo suporte primário à solução. A Microsoft dá suporte aos dados do Exchange para soluções replicadas e não-replicadas. As soluções que usam a replicação de dados devem adotar a política de suporte da Microsoft para replicação de dados, conforme descrito no artigo 895847 da Base de Dados de Conhecimento da Microsoft, Suporte à replicação de dados em vários locais para Exchange Server. Além disso, as soluções que utilizam o modelo do recurso Windows Failover Cluster devem atender os requisitos de suporte a cluster do Windows conforme descrito na Base de Conhecimento da Microsoft artigo 943984, A Política de Suporte da Microsoft Clusters de Failover do Windows Server 2008 ou Windows Server 2008 R2 Failover Clusters ou A Política de Suporte da Microsoft Clusters de Failover do Windows Server 2012.

A política de suporte para restaruação e backup da Microsoft para implantações que usam soluções baseadas em API de replicação de terceiros é a mesma que aquela para implantações nativas de replicação contínua.

Se você for um parceiro procurando informações sobre a API de replicação de terceiros, entre em contato com seu representante Microsoft.

Terminologia principal

A tabela a seguir contém links para tópicos que irão ajudar você a aprender sobre e gerenciar DAGs, cópias de banco de dados de caixa de correio e backup e restauração para Exchange 2013.

 

Tópico Descrição

Grupos de Disponibilidade de Banco de Dados

Saiba mais sobre DAGs, Active Manager, o modo Coordenação de Ativação de Datacenter (DAC) e cópias de banco de dados de caixa de correio.

Planejamento de alta disponibilidade e de resiliência do site

Saiba mais sobre geral, hardware, rede, software, servidor testemunha e outros requisitos e práticas recomendadas para DAGs.

Implantando a alta disponibilidade e resiliência do site

Explore um cenário de exemplo de implantação para implantar e configurar DAGs.

Gerenciando a alta disponibilidade e resiliência do site

Saiba mais sobre as tarefas de gerenciamento de DAG, alternâncias e failovers e modo de manutenção.

Monitoramento de Grupos de Disponibilidade de Banco de Dados

Saiba mais sobre os cmdlets e scripts incorporados para monitorar DAGs cópias de banco de dados.

Recuperação de Backup, Armazenamento e Desastre

Leia sobre backup e restauração de bancos de dados do Exchange, bancos de dados de recuperação e recuperação de servidor.

Terminologia principal

 
Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
Mostrar:
© 2014 Microsoft