Planejar a recuperação de desastre (SharePoint Foundation 2010)
Aplica-se a: SharePoint Foundation 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 Foundation 2010.
Neste artigo:
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 Foundation se torna indisponível.
A estratégia de recuperação de desastre que você usa para o SharePoint Foundation 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 Foundation, 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 Foundation 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
Recomendamos que você use a implantação com script para criar o farm principal e o farm de failover usando as mesmas configurações e personalizações.
As atualizações devem ser aplicadas aos dois farms, separadamente.
Os bancos de dados de conteúdo do SharePoint Foundation 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 de 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
.gif "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 em relação a 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 Registro de Aplicativo
Bancos de dados: serviço de Registro de Aplicativo
Aplicativo de serviço Conectividade de Dados Corporativos
Bancos de dados: Conectividade de Dados Corporativos
Aplicativo de serviço 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.
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 Configurações de Inscrição do Microsoft SharePoint Foundation
Banco de dados: Configurações de Inscrição
Observação
Não há suporte para o envio de logs do banco de dados de Configurações de Inscrição.
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 atualizações do SQL Server
Versões e todas as atualizações do 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.