Planejar a recuperação de desastre (SharePoint Server 2010)

Artigo
03/07/2017

Aplica-se a: SharePoint Foundation 2010, SharePoint Server 2010

Tópico modificado em: 2016-11-30

Este artigo descreve decisões importantes para a escolha de estratégias de recuperação de desastre para um ambiente do Microsoft SharePoint Server 2010.

Neste artigo:

Visão geral da recuperação de desastre
Escolher uma estratégia de recuperação de desastre
Planejamento de data centers em espera a frio
Planejamento de data centers em espera passiva
Planejamento de data centers em espera ativa
Requisitos do sistema para recuperação de desastre

Visão geral da recuperação de desastre

Para os fins deste artigo, definimos a recuperação de desastre como a capacidade de se recuperar de uma situação em que um data center que hospeda o SharePoint Server se torna indisponível.

A estratégia de recuperação de desastre que você usa para o SharePoint Server deve ser coordenada com a estratégia de recuperação de desastre para a infraestrutura relacionada, incluindo domínios do Active Directory, Exchange Server e Microsoft SQL Server. Trabalhe com os administradores da infraestrutura de que você necessita a fim de projetar um plano e uma estratégia de recuperação de desastre coordenados.

O tempo e o esforço imediato para colocar outro farm em funcionamento em um local diferente muitas vezes são chamados de espera ativa, passiva ou a frio. Nossas definições para esses termos são:

Espera ativa Um segundo data center que pode fornecer disponibilidade em segundos ou minutos.

Espera passiva Um segundo data center que pode fornecer disponibilidade em minutos ou horas.

Espera a frio Um segundo data center que pode fornecer disponibilidade em horas ou dias.

A recuperação de desastre pode ser um dos requisitos mais caros de um sistema. Quanto menor for o intervalo entre a falha e a disponibilidade e quanto mais sistemas você proteger, mais complexa e dispendiosa provavelmente será a solução de recuperação de desastre. Quando você investe em data centers em espera ativa ou passiva, os custos incluem:

Hardware e software adicionais, que frequentemente aumentam a complexidade das operações entre aplicativos de software, como scripts personalizados para failover e recuperação.
Complexidade operacional adicional.

Os custos de manutenção de data centers em espera ativa ou passiva devem ser avaliados com base nas necessidades comerciais. Nem todas as soluções em uma organização exigem o mesmo nível de disponibilidade após um desastre. Você pode oferecer níveis diferentes de recuperação de desastre para diferentes tipos de conteúdo, serviços ou farms — por exemplo, conteúdo com alto impacto em relação aos negócios, serviços de pesquisa ou um farm de publicação na Interne

A recuperação de desastre é uma área crucial em que grupos de tecnologia da informação (TI) oferecem contratos de nível de serviço para definir as expectativas com grupos de clientes. Muitas organizações de TI oferecem vários contratos de nível de serviço associados a níveis de cobrança diferentes.

Ao implementar o failover entre farms de servidores, é recomendável que primeiro você implante e ajuste a solução principal em um farm e, em seguida, implemente e teste a recuperação de desastre.

Escolha uma estratégia de recuperação de desastre

Você pode escolher entre diversas abordagens para fornecer recuperação de desastre para um ambiente do SharePoint Server, dependendo de suas necessidades comerciais. Os exemplos a seguir mostram os motivos pelos quais as empresas podem escolher estratégias de recuperação de desastre em espera a frio, passiva ou ativa.

Estratégia de recuperação de desastre em espera a frio: uma empresa envia backups para dar suporte à recuperação bare-metal de armazenamento externo local e regional regularmente e tem contratos em vigor para aluguel de servidores de emergência em outra região.

Prós:
- Frequentemente, essa é a opção com manutenção mais barata em termos operacionais.
- Muitas vezes, é uma opção cara em termos de recuperação, pois exige que servidores físicos sejam configurados corretamente após um desastre.
Contras: essa é a opção com recuperação mais lenta.
Estratégia de recuperação de desastre em espera passiva: uma empresa envia imagens de servidores virtuais a farms de recuperação de desastre locais e regionais.

Prós: frequentemente, essa opção tem custo relativamente baixo em termos de recuperação, pois um farm de servidores virtual pode exigir pouca configuração após a recuperação.

Contras: pode ser muito dispendioso e demorado manter essa opção.
Estratégia de recuperação de desastre em espera ativa: uma empresa executa vários data centers, mas fornece conteúdo e serviços por meio de apenas um deles.

Prós: essa opção costuma ter recuperação relativamente rápida.

Contras: a configuração e a manutenção podem ser bastante dispendiosas.

Importante

Seja qual for a solução de recuperação de desastre que você decidir implementar para seu ambiente, provavelmente ocorrerá alguma perda de dados.

Planejamento de data centers em espera a frio

Em um cenário de recuperação de desastre em espera a frio, você pode executar a recuperação configurando um novo farm em um novo local (de preferência, usando uma implantação controlada por script) e restaurando backups. Ou então, é possível executar a recuperação restaurando um farm por meio de uma solução de backup, como o Microsoft System Center Data Protection Manager 2007, que protege seus dados no nível do computador e permite restaurar cada servidor individualmente. Este artigo não contém instruções detalhadas sobre criação e recuperação em cenários em espera a frio. Para obter mais informações, consulte:

Planejamento de data centers em espera passiva

Em um cenário de recuperação de desastre em espera passiva, para criar uma solução em espera passiva, crie de maneira consistente e frequente imagens virtuais dos servidores no farm, as quais você enviará a um local secundário. Nesse local, deve haver um ambiente disponível em que você possa facilmente configurar e conectar as imagens para recriar o ambiente de farm.

Este artigo não contém instruções detalhadas sobre criação de soluções em espera passiva. Para obter mais informações sobre como planejar a implantação de farms usando soluções virtuais, consulte Planejar a virtualização (SharePoint Server 2010).

Planejamento de data centers em espera ativa

Em um cenário de recuperação de desastre em espera ativa, você pode configurar um farm de failover para fornecer recuperação de desastre em um data center separado do farm principal. Um ambiente com um farm de failover separado tem as seguintes características:

Um banco de dados de configuração separado e um banco de dados de conteúdo da Administração Central devem ser mantidos no farm de failover.
Todas as personalizações devem ser implantadas nos dois farms.

Observação

É aconselhável usar a implantação com script para criar o farm principal e de failover usando as mesmas configurações e personalizações. Para obter mais informações, consulte Instalar o SharePoint Server 2010 usando o Windows PowerShell.
As atualizações devem ser aplicadas aos dois farms, separadamente.
Os bancos de dados de conteúdo do SharePoint Server podem ser espelhados de forma assíncrona ou enviados com logs para o farm de failover.

Observação

O espelhamento do SQL Server só pode ser usado para copiar bancos de dados para um único servidor espelho, mas você pode enviar logs para vários servidores secundários.
Os aplicativos de serviço podem ou não ser enviados com logs a um farm. Para obter mais informações, consulte Redundância de aplicativos de serviço em data centers mais adiante neste artigo.

Esta topologia poderá ser repetida em vários data centers se você configurar o envio de logs do SQL Server para um ou mais data centers adicionais.

Consulte o fornecedor da SAN para determinar se você pode usar a replicação de SAN em outro mecanismo para o qual haja suporte, para fornecer disponibilidade entre data centers.

A ilustração a seguir mostra farms principais e de failover antes do failover.

Fams principal e de failover antes do failover

Farms primário e de failover antes do failover

Redundância de aplicativos de serviço entre data centers

Para oferecer disponibilidade a aplicativos de serviço entre data centers, é recomendável que, para os serviços que podem ser executados entre farms, você execute um farm de serviços separado, que possa ser acessado por meio dos data centers principal e secundário.

Para serviços que não podem ser executados entre farms, e para oferecer disponibilidade ao próprio farm de serviços, a estratégia de fornecimento de redundância entre data centers a um aplicativo de serviço pode variar. A estratégia a ser adotada depende dos seguintes fatores:

Há valor comercial na execução do aplicativo de serviço no farm de recuperação de desastre quando ele não está em uso.
Os bancos de dados associados ao aplicativo de serviço podem ser enviados com logs ou espelhados de forma assíncrona.
O aplicativo de serviço pode ser executado com bancos de dados somente leitura.

As seções a seguir descrevem as estratégias de recuperação de desastre recomendadas para cada aplicativo de serviço. Os aplicativos de serviço são agrupados por estratégia.

Bancos de dados que podem ser enviados com logs ou espelhados de forma assíncrona

Depois que um aplicativo de serviço é inicialmente implantado em um farm secundário, os bancos de dados que dão suporte aos aplicativos de serviço a seguir podem ser espelhados de forma assíncrona ou enviados com logs entre farms:

Aplicativo de serviço de Metadados Gerenciados

Bancos de dados: serviços de Metadados Gerenciados

Observação

Se a marcação estiver em uso, para utilizar com êxito o aplicativo de serviço de Metadados Gerenciados no farm de recuperação de desastre, você deverá executar o Mecanismo de Replicação de Perfil de Usuário incluído no SharePoint Administration Toolkit. Para obter mais informações, consulte User Profile Replication Engine overview (SharePoint Server 2010).
Serviços do PerformancePoint

Bancos de dados: aplicativo de Serviço do PerformancePoint
Aplicativo de serviço do Project Server

Bancos de dados: Rascunho, Publicado, Arquivo Morto, Relatório

O Project Server 2010 exige sincronização entre seus bancos de dados. É possível replicar o Project Server entre farms usando um mecanismo de replicação assíncrona (espelhamento de banco de dados assíncrono, envio de logs ou replicação de SAN assíncrona). Porém, para recuperação, verifique se os logs do banco de dados do Project são sincronizados à medida que você restaura.

Observação

Apesar da recomendação de enviar com logs ou espelhar os bancos de dados do Project Server para o farm de recuperação de desastre, não é possível executar o aplicativo de serviço do Project Server em bancos de dados somente leitura. Portanto, não é aconselhável executar o aplicativo de serviço do Project Server no farm de recuperação de desastre antes do failover. Para sincronizar com êxito os bancos de dados do Project Server no farm de recuperação de desastre, configure carimbos de data/hora ou marcação de log nos bancos de dados.
Aplicativo de serviço de Repositório Seguro

Bancos de dados: Repositório Seguro
Aplicativo de serviço de Coleta de Dados de Uso e Integridade

Bancos de dados: registro em log

Observação

É possível enviar com logs ou espelhar o banco de dados de registro em log. No entanto, é recomendável não executar o serviço Coleta de Dados de Uso e Integridade no farm de recuperação de desastre e não espelhar nem enviar com logs o banco de dados de registro em log.
Aplicativo de serviço do Web Analytics

Bancos de dados: Preparo, Relatório

Observação

É aconselhável enviar com logs ou espelhar os bancos de dados de Preparo e Relatório do Web Analytics. No entanto, não é aconselhável executar o aplicativo de serviço do Web Analytics no farm de recuperação de desastre antes do failover.

Aplicativos de serviço e bancos de dados que não podem ser enviados com logs nem espelhados de forma assíncrona

Os aplicativos de serviço a seguir devem ser implantados nos farms principal e de failover e não podem ser enviados com logs nem espelhados de forma assíncrona. Para a maioria desses aplicativos de serviço, é recomendável implantá-los e verificar se o farm de failover tem as mesmas definições de configuração que o farm principal. Se alterações de configuração que afetam o serviço forem feitas no farm principal, você deverá atualizar o farm de failover.

Aplicativo de serviço de Registro de Aplicativo

Bancos de dados: serviço de Registro de Aplicativo

Não há suporte para o envio do banco de dados do serviço de Registro de Aplicativo com logs.
Aplicativo de serviço Conectividade de Dados Corporativos

Bancos de dados: Conectividade de Dados Corporativos
Aplicativo de serviço de Perfil de Usuário

Bancos de dados: Perfil, Sincronização, Marcação Social

Não é possível enviar com logs os bancos de dados de Perfil, Sincronização e Marcação Social.

Para fornecer redundância ao aplicativo de serviço de Perfil de Usuário, primeiro implante o aplicativo de serviço nos data centers principal e secundário.

Para configurar os bancos de dados de Perfil e Sincronização, é aconselhável recuperar um backup dos bancos de dados no data center secundário e anexá-lo ao aplicativo de serviço de Perfil de Usuário nesse data center.

Para manter os perfis sincronizados, execute o Mecanismo de Replicação de Perfil de Usuário incluído no SharePoint Administration Toolkit após a atualização dos dados do perfil no farm principal. Para obter mais informações, consulte User Profile Replication Engine overview (SharePoint Server 2010).
Aplicativo de serviço de Configurações de Inscrição do Microsoft SharePoint Foundation

Banco de dados: Inscrição

Observação

Não há suporte para o envio de logs do banco de dados de Configurações de Inscrição.
Serviços do Access

Bancos de Dados: nenhum
Serviços do Excel

Bancos de Dados: nenhum
Pesquisa

Bancos de dados: Rastreamento, Propriedade, Administração da Pesquisa

A pesquisa requer total sincronização entre seus bancos de dados e o índice. Por causa desse requisito, não é possível replicar a pesquisa entre farms usando um mecanismo de replicação assíncrona (espelhamento de banco de dados assíncrono, envio de logs ou replicação de SAN assíncrona).

Para realizar uma pesquisa atualizada em um farm de failover, execute a pesquisa no farm secundário.

Importante

O aplicativo de serviço de Pesquisa no farm de failover deve ser definido para rastrear ativamente o farm secundário. No failover, configure a associação a aplicativos Web para usar o aplicativo de serviço de Pesquisa de failover.
Serviço de Controle de Sessão

Bancos de dados: Controle de Sessão

Observação

Não há suporte para o envio do banco de dados de Controle de Sessão com logs.
Serviços do Visio

Bancos de Dados: nenhum
Word Automation Services

Bancos de dados: Word Automation Services

Não há suporte para o envio do banco de dados do Word Automation Services com logs.

Requisitos do sistema para recuperação de desastre

Em um cenário ideal, os sistemas e componentes de failover correspondem aos sistemas e componentes principais de todas as maneiras: plataforma, hardware e número de servidores. No mínimo, o ambiente de failover deve ser capaz de lidar com o tráfego esperado durante um failover. Tenha em mente que somente um subconjunto de usuários pode ser atendido pelo site de failover. Os sistemas devem ser correspondentes pelo menos nos seguintes itens:

Versão e todas as atualizações do sistema operacional
Versões e todas as atualizações do SQL Server
Versões e todas as atualizações dos Produtos do SharePoint 2010

Embora este artigo aborde principalmente a disponibilidade de Produtos do SharePoint 2010, a duração da operação do sistema também será afetada pelos outros componentes no sistema. Particularmente, faça o seguinte:

Garanta que as dependências de infraestrutura, como energia, resfriamento, rede, diretório e SMTP, sejam totalmente redundantes.
Escolha um mecanismo de comutação (DNS ou balanceamento de carga de hardware) que atenda às suas necessidades.

Partilhar via