Partilhar via

Planejando a replicação contínua local

  • Artigo

 

Aplica-se a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Tópico modificado em: 2008-01-04

O planejamento de LCR (replicação contínua local) envolve a criação de um grupo de armazenamento e uma topologia de banco de dados, bem como a garantia de um suporte adequado para soluções de armazenamento e monitoramento apropriado de LCR.

Recomendações e requisitos de armazenamento para LCR

A LCR inclui alguns requisitos e recomendações de armazenamento. Ao projetar sua solução LCR de armazenamento, inclua uso adicional de E/S (entrada/saída) para LCR, porque o ambiente LCR envolve as atualizações de log pela cópia ativa e leituras similares de log na cópia passiva. Recomendamos que o armazenamento seja projetado de modo que a cópia passiva tenha capacidade e possibilidade de desempenho similares às da cópia ativa. Ao usar a LCR, recomendamos que você siga estas práticas recomendadas:

  • Use um único banco de dados por grupo de armazenamento   Quando um grupo de armazenamento tiver sido habilitado para LCR, ele só poderá conter um único banco de dados. Além disso, se um grupo de armazenamento existente contiver vários bancos de dados, você só poderá habilitar a LCR desse grupo de armazenamento quando tiver removido todos os bancos de dados, exceto um. Esse método cria uma topologia de armazenamento do Microsoft Exchange mais fácil de gerenciar e isso aumenta a possibilidade de recuperação.

  • Usar pontos de montagem de volume   Você pode usar letras de unidade ou pontos de montagem de volume para seus LUNs (números de unidade lógica) de dados ou discos do Exchange para designar onde os arquivos de banco de dados e de log de transações serão armazenados. Recomendamos que você use o recurso de pontos de montagem de volume de sistema de arquivos NTFS para ultrapassar a limitação de 26 letras de unidade, existente no Exchange Server. Ao usar os pontos de montagem de volume, você pode transplantar ou montar uma partição de destino em uma pasta ou em outro disco físico. Os pontos de montagem de volume são transparentes para os programas, incluindo o Exchange Server. O uso de um ponto de montagem de volume simplifica o processo de recuperação quando danos são detectados nos logs de transação de produção ou nos arquivos de banco de dados, permitindo que você altere rapidamente caminhos e atribuições de letra de unidade. Para obter mais informações sobre como recuperar um log de transação de produção ou arquivos de banco de dados corrompidos, consulte Gerenciando a replicação contínua local.

  • Dados de partição para desempenho e recuperação   Geralmente, a partição de dados em vários discos rígidos pode aumentar o desempenho e reduzir a quantidade de dados que precisam ser recuperados. Dependendo do tipo de falha, colocar bancos de dados e arquivos de log de transação em discos separados pode minimizar bastante a perda de dados. Por exemplo, se você mantiver os bancos de dados e os arquivos de log de transação do Exchange no mesmo disco rígido físico e esse disco falhar, você só poderá recuperar os dados existentes desde o último backup. Por outro lado, considere que você tenha colocado os arquivos de log e de bancos de dados em discos separados. Se o disco que contém os arquivos de bancos de dados falhar, você pode recuperar seus dados a partir dos arquivos de log existentes no disco separado. Para otimizar o desempenho, aumentar a tolerância a falhas e facilitar a solução de problemas, particione os dados de modo que os seguintes arquivos fiquem em discos separados:

    • Arquivos do sistema operacional Microsoft Windows

    • Arquivos de aplicativo do Exchange Server

    • Arquivos de bancos de dados do Exchange na cópia ativa

    • Arquivos de log de transação do Exchange na cópia ativa

    • Arquivos de bancos de dados do Exchange na cópia passiva

    • Arquivos de log de transação do Exchange na cópia passiva

    Além disso, coloque as cópias passivas dos grupos de armazenamento habilitados para LCR em discos isolados das cópias ativas dos grupos de armazenamento habilitados para LCR. Verifique também se os discos que contêm os arquivos de LCR têm os mesmos recursos de desempenho dos discos que contêm o grupo de armazenamento de produção. Essa equivalência permite que a cópia LCR suporte a carga, em caso de failover.

  • Garanta espaço em disco suficiente   Os discos que contêm os arquivos LCR devem ser dimensionados em comparação com os volumes de produção. O armazenamento usado pelas cópias passivas deve ser equivalente ao usado nas cópias ativas. Além disso, as soluções de armazenamento precisam incluir espaço suficiente para acomodar o tamanho do banco de dados existente, além do crescimento previsto do banco de dados.

  • Verifique se há largura de banda suficiente e baixa latência ao usar o armazenamento iSCSI com SCR   Embora não seja recomendado, há suporte para configuração de LCR com armazenamento iSCSI (Internet SCSI) conectado ao servidor de Caixa de Correio por um link de LAN (rede local) ou WAN (rede de longa distância). Nessa configuração as atividades de envio de logs e repetição de logs aconteceriam na mesma rede de armazenamento. O principal motivo para desencorajarmos essa configuração é o tráfego de rede gerado pelo envio de logs. Para que a LCR ofereça no nível esperado de proteção, é fundamental que o envio de logs permaneça atualizado, e que o tráfego de rede associado ao envio de logs não consuma tanta largura de banda que chegue a interferir com o tráfego de rede associado à atividade de repetição de logs. Não há um método de classificação do tráfego de replicação. Além disso, há alguns requisitos de armazenamento que devem ser considerados:

    • Na versão RTM (Versão para Produção) do Microsoft Exchange Server 2007, o armazenamento para cópias passivas dos bancos de dados deve oferecer uma taxa de E/S por segundo (IOPS) de duas a três vezes maior do que o armazenamento usado para as cópias ativas dos bancos de dados.

    • No Microsoft Exchange Server 2007 Service Pack 1 (SP1), o armazenamento das cópias passivas pode ser equivalente ao das cópias ativas.

Dica

Você pode usar a ferramenta Jetstress do Microsoft Exchange Server para validar sua solução de armazenamento antes de colocá-la em produção. Recomendamos que você valide o armazenamento que está sendo usado para as cópias ativas dos bancos de dados primeiro, e depois valide o armazenamento usado para as cópias passivas do banco de dados. Para obter mais informações sobre o Jetstress, consulte "Ferramentas para Armazenamento" em Validação de armazenamento.

Recomendações de memória e processador para LCR

Em um servidor de Caixa de Correio habilitado para LCR e que tenha todos os serviços da função de servidor Caixa de Correio do Exchange Server 2007, bem como o Serviço de Replicação do Microsoft Exchange em execução no mesmo servidor, serão necessários recursos adicionais de hardware disponíveis para tratar essa carga adicional. A maior parte do consumo adicional de recursos é devida à verificação e repetição de arquivos de log no servidor de Caixa de Correio habilitado para LCR.. Esse custo adicional de processamento é de aproximadamente 20 por cento (além do guia de processador listado em Planejando Configurações do Processador) e deve ser considerado quando você estiver determinando o tamanho de servidores de Caixa de Correio com LCR. Além disso, o Serviço de Replicação do Microsoft Exchange funcionará bem em um servidor de LCR com base nos recursos de memória fornecidos. Contudo, para garantir que o cache do banco de dados ESE (Mecanismo de Memória Extensível) mantenha eficiência ideal com LCR, recomendamos que você providencie 1 GB (gigabyte) adicional de RAM física para os servidores de Caixa de Correio do Exchange e servidores com várias funções (além do guia de memória listado em Planejando Configurações de Memória.

Recomendações de tamanho de banco de dados para LCR

A LCR fornece muito mais flexibilidade para recuperação de perda de dados catastrófica. A primeira linha de defesa contra graves falhas de armazenamento ou danos físicos do banco de dados com LCR é ativar a cópia passiva dos dados e não restaurar algo do backup. Lembre-se de que LCR oferece recuperação rápida de dados, mas não é uma solução de backup. A LCR diminui muito a importância de ter RTOs (Objetivos de Tempo de Recuperação) curtos baseados na restauração a partir de arquivo ou fita. Em vez de restauração a partir da fita, você ativa a cópia passiva e os dados ficam disponíveis para clientes em minutos, em vez de horas. Nesse sentido, a LCR pode ser considerada um mecanismo de recuperação rápida, colocando-a na mesma categoria de clones com base em hardware criados com VSS (Serviço de Cópias de Sombra de Volume) no Exchange Server 2003.

Não é incomum que um administrador tenha que realizar operações de banco de dados offline, como reparações, devido a backups danificados. (Por exemplo, uma fita está danificada ou uma restauração falha.) Embora a porcentagem de situações nas quais o reparo é necessário deva diminuir dramaticamente, ainda haverá momentos em que ele será necessário. Verifique sua tolerância ao "pior caso" de inatividade ao decidir sobre o tamanho do banco de dados.

A LCR permite fazer um backup a partir da cópia passiva de um grupo de armazenamento, o que permite estender a janela de manutenção na cópia ativa. Em muitos casos, é possível duplicar a janela de manutenção online, permitindo que você tenha caixas de correio e/ou bancos de dados maiores.

Nesse ponto, pode parecer que a LCR permite aumentar os bancos de dados o quanto desejar sem risco algum, mas não é assim que acontece. A manutenção online concluída em um tempo razoável por banco de dados ainda é um fator limitante para o tamanho do banco de dados. Com a LCR, a possibilidade de precisar propagar novamente os bancos de dados também é um fator limitante. A LCR fornece redundância de banco de dados, de modo que, se a cópia ativa de um banco de dados desaparecer ou for danificada, a recuperação poderá ser executada rapidamente, ativando manualmente a cópia passiva do banco de dados.

Depois da ativação, apenas uma cópia do banco de dados permanecerá, ou seja, a nova cópia ativa. Como a cópia passiva não existirá mais, a resiliência do banco de dados poderá ficar comprometida. No entanto, você ainda terá seu backup. Para reabilitar a resiliência, o banco de dados perdido/danificado precisará ser removido e uma nova cópia passiva do banco de dados precisará ser criada e novamente propagada a partir da cópia ativa. Dependendo do tamanho do banco de dados, essas tarefas podem demorar muito tempo. A pior situação possível é a perda ou corrupção de todas as cópias ativas, em que todas as cópias passivas precisam ser novamente propagadas.

É possível um tamanho máximo de banco de dados maior quando a replicação contínua é usada. Recomendamos usar os seguintes tamanhos máximos de bancos de dados para o Exchange 2007:

  • Bancos de dados hospedados em um servidor de Caixa de Correio sem LCR: 100 GB

  • Bancos de dados hospedados em um servidor de Caixa de Correio com LCR: 200 GB

    Importante

    O tamanho máximo real para bancos de dados deve ser ditado pelo SLA (acordo de nível de serviço) vigente em sua organização. A determinação do banco de dados de maior tamanho cujo backup e restauração poderão ser feitos dentro do período especificado no SLA da organização é a forma de determinar o tamanho máximo de seus bancos de dados.

LCR e bancos de dados de pasta pública

A LCR e a replicação de pasta pública são duas formas diferentes de replicação incorporadas ao Exchange. Devido a limitações de interoperabilidade entre a replicação contínua e a replicação de pasta pública, se mais de um servidor de Caixas de Correio na organização do Exchange tiver um banco de dados de pasta pública, a replicação de pasta pública será habilitada e os bancos de dados de pasta pública não deverão ser hospedados em um grupo de armazenamento que está habilitado para LCR.

A seguir estão as configurações recomendadas para uso de bancos de dados de pasta pública e da LCR em sua organização do Exchange:

  • Se você tiver um único servidor de Caixas de Correio em sua organização do Exchange e ele for um servidor autônomo, o servidor de Caixa de Correio poderá hospedar um banco de dados de pasta pública em um grupo de armazenamento habilitado para LCR. Nessa configuração, existe somente um banco de dados de pasta pública na organização do Exchange. Portanto, a replicação de pasta pública está desabilitada.

  • Se você tiver vários servidores de Caixas de Correio e somente um dos servidores de Caixas de Correio contiver um banco de dados de pasta pública, o servidor de Caixas de Correio poderá hospedar um banco de dados de pasta pública em um grupo de armazenamento habilitado para LCR. Nessa configuração, existe somente um banco de dados de pasta pública na organização do Exchange. Portanto, a replicação de pasta pública está desabilitada.

  • Se você estiver migrando dados de pasta pública para um grupo de armazenamento habilitado para LCR, poderá usar a replicação de pasta pública para mover o conteúdo de um banco de dados de pasta pública em um grupo de armazenamento habilitado para LCR. Depois de criar o banco de dados de pasta pública em um grupo de armazenamento habilitado para LCR, os bancos de dados de pasta pública adicionais só devem estar presentes até que os dados de pasta pública tenham sido completamente replicados para o banco de dados de pasta pública no grupo de armazenamento habilitado para LCR. Quando a replicação tiver sido concluída com êxito, todos os bancos de dados de pasta pública fora do grupo de armazenamento habilitado para CCR devem ser removidos e você não deve hospedar nenhum outro banco de dados de pasta pública na organização do Exchange.

  • Se você estiver migrando dados de pasta pública de um grupo de armazenamento habilitado para LCR, poderá usar a replicação de pasta pública para mover o conteúdo de um banco de dados de pasta pública do banco de dados de pasta pública em um grupo de armazenamento habilitado para LCR. Depois de criar o banco de dados de pasta pública adicional fora do grupo de armazenamento habilitado para LCR, o banco de dados de pasta pública no grupo de armazenamento habilitado para LCR somente deve estar presente até que os dados de pasta pública tenham sido completamente replicados para os bancos de dados de pasta pública adicionais. Quando a replicação tiver sido concluída com êxito, todos os bancos de dados de pasta pública dentro de todos os grupos de armazenamento habilitados para LCR devem ser removidos e todos os bancos de dados de pasta pública subseqüentes não devem ser hospedados em grupos de armazenamento que estejam habilitados para replicação contínua.

Durante qualquer período em que mais de um banco de dados de pasta pública existir na organização do Exchange e um ou mais bancos de dados de pastas públicas estiverem hospedados em um grupo de armazenamento habilitado para LCR, se ocorrer uma falha do grupo de armazenamento ativo da LCR e a cópia passiva do grupo de armazenamento com um banco de dados de pasta pública precisar ser ativado, ele só poderá se tornar montável se todos os logs do grupo de armazenamento que hospeda o banco de dados de pasta pública estiverem disponíveis. Se qualquer log estiver ausente ou não disponível como resultado da falha da cópia ativa, você não poderá ativar a cópia passiva do banco de dados de pasta pública. Nesse caso, a cópia ativa deve ser colocada online para garantir que não haja perda de dados, ou o banco de dados de pasta pública deve ser recriado na cópia ativa do grupo de armazenamento e seu conteúdo deve ser recuperado usando a replicação de pasta pública de banco(s) de dados de pasta pública diferente da cópia passiva.

Recomendações de monitoração para LCR

A LCR é uma solução de disponibilidade de dados. Ela precisa ser monitorada de modo proativo. O Exchange 2007 publica várias informações de status para cópias LCR. Após habilitar a LCR para um grupo de armazenamento, você poderá usar o Console de Gerenciamento do Exchange ou o Shell de Gerenciamento do Exchange para exibir as definições de status e configuração de cópias de LCR. Para obter etapas detalhadas sobre como exibir informações de status e configuração, consulte Como exibir o status de uma cópia de replicação contínua local.

Para obter um monitoramento proativo e automatizado, recomendamos que você use o Microsoft Operations Manager (MOM) e o Pacote de Gerenciamento do Exchange 2007 para MOM. Para obter mais informações sobre monitoração de LCR, consulte Gerenciamento de monitoramento e de operações.

No Exchange 2007 SP1, você também pode usar um novo cmdlet chamado Test-ReplicationHealth para testar a integridade e status dos grupos de armazenamento habilitados para LCR. Para obter mais informações sobre o cmdlet Test-ReplicationHealth, consulte Test-ReplicationHealth.

Backup e restauração e LCR

A LCR fornece envio de logs, repetição de logs e uma troca manual rápida para uma cópia secundária dos dados. Esses recursos reduzem o tempo de recuperação necessário para desastres no nível de dados. A LCR reduz também o número de backups necessários para proteção suficiente de dados. Embora a LCR não evite a necessidade de fazer backups, ela reduz a necessidade de fazer backups diários e completos. A LCR permite também que você descarregue backups de VSS (Serviço de Cópias de Sombra de Volume) do grupo de armazenamento ativo para o grupo de armazenamento passivo. Os quatro tipos de backup (Completo, Cópia, Incremental e Diferencial) podem ser feitos a partir dos locais de cópia passiva, preservando a E/S importante do disco nos LUNs da cópia ativa para atender aos clientes.

Além de reduzir o TCO (custo total de propriedade) geral, a LCR oferece outras vantagem em relação às soluções de backup anteriores. A LCR permite ter cópias adicionais dos bancos de dados do Exchange, o qual oferece os seguintes benefícios:

  • Redução na freqüência de backup do banco de dados   A cópia de LCR é a primeira linha de defesa contra uma falha no banco de dados de produção. Tanto o grupo de armazenamento de produção quanto a cópia do grupo de armazenamento deveriam falhar para que as cópias de backups fossem necessárias. Como conseqüência, recomendamos um SLA (acordo de nível de serviço) mais longo para esse caso. Com um SLA mais longo, recomenda-se backups completos semanais e backups incrementais diários.

  • Recuperação rápida de desastres   Geralmente, a recuperação ocorre em menos de dez minutos com pouca ou nenhuma perda de dados.

  • Suporte para cotas maiores de caixa de correio   Esse suporte é obtido como resultado de uma recuperação rápida que é independente do tamanho do banco de dados.

Para obter mais detalhes e orientação específica para backup e restauração, consulte Recuperação de Desastres.

LCR e backups do Exchange

Os backups sensíveis ao Exchange são aceitos em grupos e bancos de dados de armazenamento ativos e a partir de cópias de bancos de dados passivas.

Dica

Uma tarefa comum durante a criação de backups sensíveis ao Exchange é o truncamento de arquivos de log de transação depois que a operação de backup for concluída com êxito. O recurso de replicação na LCR garante que os logs que não foram replicados sejam excluídos. Como resultado, a execução de backups em um modo que exclui logs pode não criar realmente espaço livre, caso a replicação esteja muito atrasada em sua operação de cópia de log.

Os backups sensíveis ao Exchange desta configuração também podem ser feitos por um streaming ou soluções de backup do VSS. Embora backups de streaming só possam ser executados com base na cópia ativa, backups de VSS podem ser feitos a partir da cópia ativa ou passiva.

LCR e restaurações do Exchange

As restaurações sensíveis ao Exchange também podem ser realizadas por um fluxo contínuo ou soluções de backup do VSS. As restaurações podem ser destinadas aos locais de arquivos de log e do banco de dados ativo. As restaurações sensíveis ao Exchange de backups do banco de dados diretamente no local da cópia passiva não são aceitos nativamente. As restaurações para locais de cópia passiva podem ser obtidas manualmente por uma restauração no nível do arquivo.

Antes de restaurar um banco de dados de um grupo de armazenamento, configurado para LCR, suspenda a LCR do grupo de armazenamento. Após a conclusão da restauração, você pode continuar a LCR. A LCR deve ser suspensa nos bancos de dados que estão sendo restaurados.

Depois de restaurar um banco de dados a partir do backup em um grupo de armazenamento habilitado para LCR, você deve suspender e, em seguida, continuar a replicação contínua do grupo de armazenamento usando Suspend-StorageGroupCopy e Resume-StorageGroupCopy, respectivamente. Esse processo é necessário para atualizar o Serviço de Replicação do Microsoft Exchange com as informações corretas de geração de log. Se a replicação contínua não for suspensa e continuada, o Serviço de Replicação do Microsoft Exchange terá informações desatualizadas da geração de log e parará de replicar os arquivos de log.