Recuperação de Desastre do SharePoint Server 2013 no Microsoft Azure
Usando o Azure, você pode criar um ambiente de recuperação de desastre para seu farm de SharePoint local. Este artigo descreve como criar e implementar esta solução.
Assista ao vídeo SharePoint visão geral da recuperação de desastre do SharePoint Server 2013
Quando o desastre atinge SharePoint ambiente local, sua prioridade principal é fazer com que o sistema seja executado novamente rapidamente. A recuperação de SharePoint é mais rápida e fácil quando você tem um ambiente de backup já em execução Microsoft Azure. Este vídeo explica os principais conceitos de um ambiente de failover SharePoint warm e complementa os detalhes completos disponíveis neste artigo.
Use este artigo com o seguinte modelo de solução: SharePoint recuperação de desastre no Microsoft Azure.
Usar os Serviços de Infraestrutura do Azure para recuperação de desastre
Muitas organizações não têm um ambiente de recuperação de desastre para SharePoint, o que pode ser caro para criar e manter localmente. Os Serviços de Infraestrutura do Azure fornecem opções atraentes para ambientes de recuperação de desastre que são mais flexíveis e menos caros do que as alternativas locais.
As vantagens de usar os Serviços de Infraestrutura do Azure incluem:
Recursos menos dispendiados Mantenha e pague por menos recursos do que os ambientes de recuperação de desastre locais. O número de recursos depende de qual ambiente de recuperação de desastre você escolher: espera a frio, espera passiva ou espera ativa.
Melhor flexibilidade de recursos Em caso de desastre, expanda facilmente seu farm de SharePoint de recuperação para atender aos requisitos de carga. Reduzir horizontalmente quando você não precisar mais dos recursos.
Compromisso de datacenter inferior Use os Serviços de Infraestrutura do Azure em vez de investir em um datacenter secundário em uma região diferente.
Há opções menos complexas para organizações que estão começando a usar a recuperação de desastre e opções avançadas para organizações com requisitos de alta resiliência. As definições para ambientes de espera frios, quentes e quentes são um pouco diferentes quando o ambiente é hospedado em uma plataforma de nuvem. A tabela a seguir descreve esses ambientes para criar um farm SharePoint recuperação no Azure.
Tabela: ambientes de recuperação
| Tipo de ambiente de recuperação | Descrição |
|---|---|
| Quente | Um farm totalmente dimensionado é provisionado, atualizado e em execução em espera. |
| Quente | O farm é criado e as máquinas virtuais estão em execução e atualizadas. A recuperação inclui anexar bancos de dados de conteúdo, provisionar aplicativos de serviço e rastrear conteúdo. O farm pode ser uma versão menor do farm de produção e, em seguida, escalado horizontalmente para atender à base de usuários completa. |
| Frio | O farm é totalmente criado, mas as máquinas virtuais são interrompidas. Manter o ambiente inclui iniciar as máquinas virtuais de tempos em tempos, aplicar patches, atualizar e verificar o ambiente. Inicie o ambiente completo em caso de desastre. |
É importante avaliar os RTOs (Objetivos de Tempo de Recuperação) e os RPOs (Objetivos de Ponto de Recuperação) da sua organização. Esses requisitos determinam qual ambiente é o investimento mais apropriado para sua organização.
As diretrizes neste artigo descrevem como implementar um ambiente de espera passiva. Você também pode adaptá-lo a um ambiente de espera frio, embora precise seguir procedimentos adicionais para dar suporte a esse tipo de ambiente. Este artigo não descreve como implementar um ambiente de espera ativa.
Para obter mais informações sobre soluções de recuperação de desastre, consulte conceitos de alta disponibilidade e recuperação de desastre no SharePoint 2013 e Escolha uma estratégia de recuperação de desastre para SharePoint 2013.
Descrição da solução
A solução de recuperação de desastre em espera passiva requer o seguinte ambiente:
Um farm de SharePoint local
Um farm SharePoint recuperação no Azure
Uma conexão VPN site a site entre os dois ambientes
A figura a seguir ilustra esses três elementos.
Figura: Elementos de uma solução de espera passiva no Azure
SQL Server envio de logs com DFSR (Replicação do Sistema de Arquivos Distribuído) é usado para copiar backups de banco de dados e logs de transações para o farm de recuperação no Azure:
O DFSR transfere logs do ambiente de produção para o ambiente de recuperação. Em um cenário WAN, a DFSR é mais eficiente do que enviar os logs diretamente para o servidor secundário no Azure.
Os logs são reproduzidos no SQL Server no ambiente de recuperação no Azure.
Você não anexa bancos de dados de conteúdo enviados por log SharePoint no ambiente de recuperação até que um exercício de recuperação seja executado.
Execute as seguintes etapas para recuperar o farm:
Pare o envio de logs.
Pare de aceitar o tráfego para o farm primário.
Reproduza os logs de transação finais.
Anexe os bancos de dados de conteúdo ao farm.
Restaure aplicativos de serviço dos bancos de dados de serviços replicados.
Atualize os registros DNS (Sistema de Nomes de Domínio) para apontar para o farm de recuperação.
Inicie um rastreamento completo.
Recomendamos que você ensaiar essas etapas regularmente e documentá-las para ajudar a garantir que sua recuperação ao vivo seja executada sem problemas. Anexar bancos de dados de conteúdo e restaurar aplicativos de serviço pode levar algum tempo e normalmente envolve alguma configuração manual.
Depois que uma recuperação é executada, essa solução fornece os itens listados na tabela a seguir.
Tabela: Objetivos de recuperação da solução
| Item | Descrição |
|---|---|
| Sites e conteúdo | Sites e conteúdo estão disponíveis no ambiente de recuperação. |
| Uma nova instância de pesquisa | Nessa solução de espera passiva, a pesquisa não é restaurada dos bancos de dados de pesquisa. Os componentes de pesquisa no farm de recuperação são configurados da mesma forma possível para o farm de produção. Depois que os sites e o conteúdo são restaurados, um rastreamento completo é iniciado para recompilar o índice de pesquisa. Você não precisa aguardar a conclusão do rastreamento para disponibilizar os sites e o conteúdo. |
| Serviços | Os serviços que armazenam dados em bancos de dados são restaurados dos bancos de dados enviados por log. Os serviços que não armazenam dados em bancos de dados são simplesmente iniciados. Nem todos os serviços com bancos de dados precisam ser restaurados. Os seguintes serviços não precisam ser restaurados de bancos de dados e podem simplesmente ser iniciados após o failover: Coleta de Dados de Uso e Integridade Serviço de Controle de Sessão Automação do Word Qualquer outro serviço que não use um banco de dados |
Você pode trabalhar com o MCS (Serviços de Consultoria da Microsoft) ou um parceiro para abordar objetivos de recuperação mais complexos. Eles são resumidos na tabela a seguir.
Tabela: outros itens que podem ser abordados pelo MCS ou por um parceiro
| Item | Descrição |
|---|---|
| Sincronizando soluções de farm personalizadas | O ideal é que a configuração do farm de recuperação seja idêntica ao farm de produção. Você pode trabalhar com um consultor ou parceiro para avaliar se as soluções de farm personalizadas são replicadas e se o processo está em vigor para manter os dois ambientes sincronizados. |
| Conexões com fontes de dados locais | Pode não ser prático replicar conexões para sistemas de dados de back-end, como conexões BDC (controlador de domínio de backup) e fontes de conteúdo de pesquisa. |
| Cenários de restauração de pesquisa | Como as implantações de pesquisa corporativa tendem a ser bastante exclusivas e complexas, restaurar a pesquisa de bancos de dados requer um maior investimento. Você pode trabalhar com um consultor ou parceiro para identificar e implementar cenários de restauração de pesquisa que sua organização pode exigir. |
As diretrizes fornecidas neste artigo pressupõem que o farm local já foi projetado e implantado.
Arquitetura detalhada
O ideal é que a configuração do farm de recuperação no Azure seja idêntica ao farm de produção local, incluindo o seguinte:
A mesma representação de funções de servidor
A mesma configuração de personalizações
A mesma configuração de componentes de pesquisa
O ambiente no Azure pode ser uma versão menor do farm de produção. Se você planeja escalar horizontalmente o farm de recuperação após o failover, é importante que cada tipo de função de servidor seja inicialmente representado.
Algumas configurações podem não ser práticas para serem replicadas no ambiente de failover. Certifique-se de testar os procedimentos de failover e o ambiente para ajudar a garantir que o farm de failover forneça o nível de serviço esperado.
Essa solução não prescrii uma topologia específica para uma SharePoint farm. O foco dessa solução é usar o Azure para o farm de failover e implementar o envio de logs e DFSR entre os dois ambientes.
Ambientes de espera passiva
Em um ambiente de espera passiva, todas as máquinas virtuais no ambiente do Azure estão em execução. O ambiente está pronto para um exercício ou evento de failover.
A figura a seguir ilustra uma solução de recuperação de desastre de um farm de SharePoint local para um farm de SharePoint baseado no Azure configurado como um ambiente de espera passiva.
Figura: Topologia e principais elementos de um farm de produção e um farm de recuperação em espera passiva
Neste diagrama:
Dois ambientes são ilustrados lado a lado: o farm de SharePoint local e o farm de espera passiva no Azure.
Cada ambiente inclui um compartilhamento de arquivos.
Cada farm inclui quatro camadas. Para obter alta disponibilidade, cada camada inclui dois servidores ou máquinas virtuais configurados de forma idêntica para uma função específica, como serviços front-end, cache distribuído, serviços de back-end e bancos de dados. Não é importante nesta ilustração chamar componentes específicos. Os dois farms são configurados de forma idêntica.
A quarta camada é a camada de banco de dados. O envio de logs é usado para copiar logs do servidor de banco de dados secundário no ambiente local para o compartilhamento de arquivos no mesmo ambiente.
A DFSR copia os arquivos do compartilhamento de arquivos no ambiente local para o compartilhamento de arquivos no ambiente Azure.
O envio de logs reproduz os logs do compartilhamento de arquivos no ambiente Azure para a réplica primária no grupo de disponibilidade AlwaysOn do SQL Server no ambiente secundário.
Ambientes em espera a frio
Em um ambiente de espera frio, a maioria das máquinas virtuais SharePoint farm pode ser desligada. (Recomendamos ocasionalmente iniciar as máquinas virtuais, como a cada duas semanas ou uma vez por mês, para que cada máquina virtual possa sincronizar com o domínio.) As seguintes máquinas virtuais no ambiente de recuperação do Azure devem permanecer em execução para ajudar a garantir operações contínuas de envio de logs e DFSR:
O compartilhamento de arquivos
Servidor de banco de dados principal
Pelo menos uma máquina virtual executando Windows Server Active Directory Domain Services e DNS
A figura a seguir mostra um ambiente de failover do Azure no qual a máquina virtual de compartilhamento de arquivos e a máquina virtual SharePoint banco de dados primário estão em execução. Todas as outras SharePoint virtuais são interrompidas. A máquina virtual que está executando Windows Server Active Directory e DNS não é mostrada.
Figura: Farm de recuperação em espera a frio com máquinas virtuais em execução
Após o failover para um ambiente de espera a frio, todas as máquinas virtuais são iniciadas e o método para obter a alta disponibilidade dos servidores de banco de dados deve ser configurado, como SQL Server grupos de disponibilidade AlwaysOn.
Se vários grupos de armazenamento forem implementados SQL Server (os bancos de dados são distribuídos em mais de um conjunto de alta disponibilidade), o banco de dados primário de cada grupo de armazenamento deverá estar em execução para aceitar os logs associados ao seu grupo de armazenamento.
Habilidades e experiência
Várias tecnologias são usadas nesta solução de recuperação de desastre. Para ajudar a garantir que essas tecnologias interajam conforme o esperado, cada componente no ambiente local e no Azure deve ser instalado e configurado corretamente. Recomendamos que a pessoa ou a equipe que configura essa solução tenha um forte conhecimento prático e habilidades práticos com as tecnologias descritas nos seguintes artigos:
Por fim, recomendamos habilidades de script que você pode usar para automatizar tarefas associadas a essas tecnologias. É possível usar as interfaces do usuário disponíveis para concluir todas as tarefas descritas nesta solução. No entanto, uma abordagem manual pode ser demorada e propensa a erros e fornece resultados inconsistentes.
Além do Windows PowerShell, também há Windows PowerShell bibliotecas para SQL Server, SharePoint Server e Azure. Não se esqueça do T-SQL, que também pode ajudar a reduzir o tempo para configurar e manter seu ambiente de recuperação de desastre.
Roteiro de recuperação de desastre
Este roteiro pressupõe que você já tenha um farm SharePoint Server 2013 implantado em produção.
Tabela: Roteiro para recuperação de desastre
| Fase | Descrição |
|---|---|
| Fase 1 | Projete o ambiente de recuperação de desastre. |
| Fase 2 | Crie a rede virtual do Azure e a conexão VPN. |
| Fase 3 | Implante Windows Active Directory e Serviços de Nome de Domínio na rede virtual do Azure. |
| Fase 4 | Implante o SharePoint de recuperação no Azure. |
| Fase 5 | Configure a DFSR entre os farms. |
| Fase 6 | Configure o envio de logs para o farm de recuperação. |
| Fase 7 | Validar soluções de failover e recuperação. Isso inclui os seguintes procedimentos e tecnologias: Pare o envio de logs. Restaure os backups. Conteúdo de rastreamento. Recuperar serviços. Gerenciar registros DNS. |
Fase 1: Projetar o ambiente de recuperação de desastre
Use as diretrizes do Microsoft Azure Architectures for SharePoint 2013 para projetar o ambiente de recuperação de desastre, incluindo o farm de SharePoint recuperação. Você pode usar os elementos gráficos na solução SharePoint recuperação de desastre no arquivo Visio Azure para iniciar o processo de design. Recomendamos que você projete todo o ambiente antes de iniciar qualquer trabalho no ambiente do Azure.
Além das diretrizes fornecidas nas Arquiteturas do Microsoft Azure para o SharePoint 2013 para projetar a rede virtual, a conexão VPN, o Active Directory e o farm do SharePoint, certifique-se de adicionar uma função de compartilhamento de arquivos ao ambiente do Azure.
Para dar suporte ao envio de logs em uma solução de recuperação de desastre, uma máquina virtual de compartilhamento de arquivos é adicionada à sub-rede em que residem as funções de banco de dados. O compartilhamento de arquivos também serve como o terceiro nó de uma maioria de nós para o grupo SQL Server de disponibilidade AlwaysOn. Essa é a configuração recomendada para um farm SharePoint padrão que usa SQL Server de disponibilidade AlwaysOn.
Observação
É importante examinar os pré-requisitos para que um banco de dados participe de um SQL Server de disponibilidade AlwaysOn. Para obter mais informações, consulte Pré-requisitos, restrições e Recomendações grupos de disponibilidade AlwaysOn.
Figura: Posicionamento de um servidor de arquivos usado para uma solução de recuperação de desastre
Neste diagrama, uma máquina virtual de compartilhamento de arquivos é adicionada à mesma sub-rede no Azure que contém as funções de servidor de banco de dados. Não adicione a máquina virtual de compartilhamento de arquivos a um conjunto de disponibilidade com outras funções de servidor, como as SQL Server funções.
Se você estiver preocupado com a alta disponibilidade dos logs, considere usar uma abordagem diferente usando SQL Server backup e restauração com o Armazenamento de Blobs do Azure Service. Esse é um novo recurso no Azure que salva logs diretamente em uma URL de armazenamento de blobs. Essa solução não inclui diretrizes sobre como usar esse recurso.
Ao projetar o farm de recuperação, tenha em mente que um ambiente de recuperação de desastre bem-sucedido reflete com precisão o farm de produção que você deseja recuperar. O tamanho do farm de recuperação não é o mais importante no design, implantação e teste do farm de recuperação. A escala do farm varia de organização para organização com base nos requisitos de negócios. Pode ser possível usar um farm escalonado para uma pequena interrupção ou até que as demandas de desempenho e capacidade exijam que você dimensione o farm.
Configure o farm de recuperação da maneira mais idêntica possível para o farm de produção para que ele atenda aos requisitos de SLA (contrato de nível de serviço) e forneça a funcionalidade de que você precisa para dar suporte à sua empresa. Ao projetar o ambiente de recuperação de desastre, examine também seu processo de gerenciamento de alterações para seu ambiente de produção. Recomendamos que você estenda o processo de gerenciamento de alterações para o ambiente de recuperação atualizando o ambiente de recuperação no mesmo intervalo que o ambiente de produção. Como parte do processo de gerenciamento de alterações, recomendamos manter um inventário detalhado da configuração, dos aplicativos e dos usuários do farm.
Fase 2: Criar a rede virtual do Azure e a conexão VPN
Conexão uma rede local para uma rede virtual Microsoft Azure mostra como planejar e implantar a rede virtual no Azure e como criar a conexão VPN. Siga as diretrizes no tópico para concluir os seguintes procedimentos:
Planeje o espaço de endereço IP privado do Rede Virtual.
Planeje as alterações de infraestrutura de roteamento para o Rede Virtual.
Planeje regras de firewall para o tráfego de e para o dispositivo VPN local.
Crie a rede virtual entre locais no Azure.
Configure o roteamento entre sua rede local e o Rede Virtual.
Fase 3: Implantar o Active Directory e o Domain Name Services na rede virtual do Azure
Essa fase inclui a implantação de Windows Server Active Directory e DNS no Rede Virtual em um cenário híbrido, conforme descrito em arquiteturas do Microsoft Azure para o SharePoint 2013 e conforme ilustrado na figura a seguir.
Figura: Configuração de domínio do Active Directory Híbrido
Na ilustração, duas máquinas virtuais são implantadas na mesma sub-rede. Cada uma dessas máquinas virtuais hospeda duas funções: Active Directory e DNS.
Antes de implantar o Active Directory no Azure, leia As diretrizes para implantar Windows Server Active Directory no Azure Máquinas Virtuais. Essas diretrizes ajudam você a determinar se você precisa de uma arquitetura diferente ou definições de configuração diferentes para sua solução.
Para obter diretrizes detalhadas sobre como configurar um controlador de domínio no Azure, consulte Instalar um controlador de Domínio do Active Directory réplica em redes virtuais do Azure.
Antes dessa fase, você não implanta máquinas virtuais no Rede Virtual. As máquinas virtuais para hospedar o Active Directory e o DNS provavelmente não são as maiores máquinas virtuais necessárias para a solução. Antes de implantar essas máquinas virtuais, primeiro crie a maior máquina virtual que você planeja usar em seu Rede Virtual. Isso ajuda a garantir que sua solução seja implantada em uma marca no Azure que permita o maior tamanho de que você precisa. Você não precisa configurar essa máquina virtual no momento. Simplesmente crie-o e reserve-o. Se você não fizer isso, poderá encontrar uma limitação ao tentar criar máquinas virtuais maiores posteriormente, o que era um problema no momento em que este artigo foi escrito.
Fase 4: Implantar o farm SharePoint recuperação no Azure
Implante o SharePoint farm em seu Rede Virtual de acordo com seus planos de design. Pode ser útil examinar o Planejamento do SharePoint 2013 nos Serviços de Infraestrutura do Azure antes de implantar SharePoint funções no Azure.
Considere as seguintes práticas que aprendemos criando nosso ambiente de prova de conceito:
Crie máquinas virtuais usando o portal do Azure ou o PowerShell.
O Azure e o Hyper-V não dão suporte à memória dinâmica. Verifique se isso é fatorado em seus planos de desempenho e capacidade.
Reinicie as máquinas virtuais por meio da interface do Azure, não do logon da máquina virtual em si. Usar a interface do Azure funciona melhor e é mais previsível.
Se você quiser desligar uma máquina virtual para economizar custos, use a interface do Azure. Se você desligar o logon da máquina virtual, os encargos continuarão acumulando.
Use uma convenção de nomenclatura para as máquinas virtuais.
Preste atenção em qual local do datacenter as máquinas virtuais estão sendo implantadas.
Não há suporte para o recurso de dimensionamento automático no Azure para SharePoint funções.
Não configure itens no farm que serão restaurados, como conjuntos de sites.
Fase 5: Configurar DFSR entre os farms
Para configurar a replicação de arquivos usando DFSR, use o snap-in Gerenciamento de DNS. No entanto, antes da instalação do DFSR, faça logon no servidor de arquivos local e no servidor de arquivos do Azure e habilite o serviço no Windows.
No painel Gerenciador do Servidor, conclua as seguintes etapas:
Configure o servidor local.
Inicie o Assistente de Adição de Funções e Recursos.
Abra o nó Arquivo e Armazenamento Services.
Selecione Namespaces do DFS e replicação do DFS.
Clique em Avançar para concluir as etapas do assistente.
A tabela a seguir fornece links para artigos de referência DFSR e postagens no blog.
Tabela: artigos de referência para DFSR
| Cargo | Descrição |
|---|---|
| Replicação | Tópico do TechNet de Gerenciamento do DFS com links para replicação |
| Replicação do DFS: Guia de sobrevivência | Wiki com links para informações do DFS |
| Replicação do DFS: Perguntas frequentes | Tópico do TechNet de Replicação do DFS |
| Blog de Jose Barreto | Blog escrito por um Gerente de Programa Principal na equipe do Servidor de Arquivos da Microsoft |
| The Armazenamento Team at Microsoft - File Cabinet Blog | Blog sobre serviços de arquivo e recursos de armazenamento no Windows Server |
Fase 6: Configurar o envio de logs para o farm de recuperação
O envio de logs é o componente crítico para configurar a recuperação de desastre nesse ambiente. Você pode usar o envio de logs para enviar automaticamente arquivos de log de transações para bancos de dados de uma instância do servidor de banco de dados primário para uma instância secundária do servidor de banco de dados. Para configurar o envio de logs, consulte Configurar o envio de logs no SharePoint 2013.
Importante
O suporte ao envio de logs no SharePoint Server é limitado a determinados bancos de dados. Para obter mais informações, consulte As opções de alta disponibilidade e recuperação de desastre com suporte SharePoint bancos de dados (SharePoint 2013).
Fase 7: Validar o failover e a recuperação
O objetivo dessa fase final é verificar se a solução de recuperação de desastre funciona conforme planejado. Para fazer isso, crie um evento de failover que desligue o farm de produção e inicia o farm de recuperação como uma substituição. Você pode iniciar um cenário de failover manualmente ou usando scripts.
A primeira etapa é interromper as solicitações de usuário de entrada para conteúdo ou serviços de farm. Você pode fazer isso desabilitando entradas DNS ou desligando os servidores Web front-end. Depois que o farm estiver "inoperante", você poderá fazer failover para o farm de recuperação.
Parar envio de logs
Você deve parar o envio de logs antes da recuperação do farm. Pare o envio de logs no servidor secundário no Azure primeiro e, em seguida, interrompa-o no servidor primário local. Use o script a seguir para interromper o envio de logs no servidor secundário primeiro e, em seguida, no servidor primário. Os nomes de banco de dados no script podem ser diferentes, dependendo do seu ambiente.
-- This script removes log shipping from the server.
-- Commands must be executed on the secondary server first and then on the primary server.
SET NOCOUNT ON
DECLARE @PriDB nvarchar(max)
,@SecDB nvarchar(250)
,@PriSrv nvarchar(250)
,@SecSrv nvarchar(250)
Set @PriDB= ''
SET @PriDB = UPPER(@PriDB)
SET @PriDB = REPLACE(@PriDB, ' ', '')
SET @PriDB = '''' + REPLACE(@PriDB, ',', ''', ''') + ''''
Set @SecDB = @PriDB
Exec ( 'Select ''exec master..sp_delete_log_shipping_secondary_database '' + '''''''' + prm.primary_database + ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec ON prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')
Exec ( 'Select ''exec master..sp_delete_log_shipping_primary_secondary '' + '''''''' + prm.Primary_Database + '''''', '''''' + sec.Secondary_Server + '''''', '''''' + sec.Secondary_database + ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec ON prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')
Exec ( 'Select ''exec master..sp_delete_log_shipping_primary_database '' + '''''''' + prm.primary_database + ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec ON prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')
Exec ( 'Select ''exec master..sp_delete_log_shipping_secondary_primary '' + '''''''' + prm.primary_server + '''''', '''''' + prm.primary_database + ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec ON prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')
Restaurar os backups
Os backups devem ser restaurados na ordem em que foram criados. Antes de restaurar um backup de log de transações específico, você deve primeiro restaurar os seguintes backups anteriores sem reverter transações não confirmadas (ou seja, usando WITH NORECOVERY):
O backup completo do banco de dados e o último backup diferencial – restaure esses backups, se houver, feitos antes do backup de log de transações específico. Antes da criação do backup de banco de dados completo ou diferencial mais recente, o banco de dados estava usando o modelo de recuperação completa ou o modelo de recuperação bulk-logged.
Todos os backups de log de transações – restaure quaisquer backups de log de transações feitos após o backup completo do banco de dados ou o backup diferencial (se você restaurar um) e antes do backup de log de transações específico. Os backups de log devem ser aplicados na sequência em que foram criados, sem lacunas na cadeia de log.
Para recuperar o banco de dados de conteúdo no servidor secundário para que os sites renderizem, remova todas as conexões de banco de dados antes da recuperação. Para restaurar o banco de dados, execute a instrução SQL seguir.
restore database WSS_Content with recovery
Importante
Ao usar o T-SQL explicitamente, especifique WITH NORECOVERY ou WITH RECOVERY em cada instrução RESTORE para eliminar a ambiguidade— isso é muito importante ao escrever scripts. Depois que os backups completos e diferenciais forem restaurados, os logs de transação poderão ser restaurados SQL Server Management Studio. Além disso, como o envio de logs já foi interrompido, o banco de dados de conteúdo está em estado de espera, portanto, você deve alterar o estado para acesso completo.
No SQL Server Management Studio, clique com o botão direito do mouse no banco de dados WSS_Content, aponte para TasksRestore > e clique em Log de Transações (se você não tiver restaurado o backup completo, isso não estará disponível). Para obter mais informações, consulteRestore um backup de log de transações (SQL Server).
Rastrear a fonte de conteúdo
Você deve iniciar um rastreamento completo para cada fonte de conteúdo para restaurar o Serviço de Pesquisa. Observe que você perde algumas informações de análise do farm local, como recomendações de pesquisa. Antes de iniciar os rastreamentos completos, use o cmdlet Windows PowerShell Restore-SPEnterpriseSearchServiceApplication e especifique o banco de dados de Administração de Pesquisa de log enviado e replicado,<GUID> Search_Service__DB_. Esse cmdlet fornece a configuração de pesquisa, o esquema, as propriedades gerenciadas, as regras e as fontes e cria um conjunto padrão dos outros componentes.
Para iniciar um rastreamento completo, conclua as seguintes etapas:
Na Administração Central SharePoint 2013, vá para aplicativos de serviço Application ManagementService > ApplicationsManage > e clique no aplicativo de Serviço de Pesquisa que você deseja rastrear.
Na página Administração de Pesquisa , clique em Fontes de Conteúdo, aponte para a fonte de conteúdo desejada, clique na seta e clique em Iniciar Rastreamento Completo.
Recuperar serviços de farm
A tabela a seguir mostra como recuperar serviços que têm bancos de dados enviados por log, os serviços que têm bancos de dados, mas não são recomendados para restauração com envio de logs e os serviços que não têm bancos de dados.
Importante
Restaurar um banco de dados SharePoint local no ambiente do Azure não recuperará nenhum serviço SharePoint que você ainda não instalou no Azure manualmente.
Tabela: Referência de banco de dados do aplicativo de serviço
| Restaurar esses serviços de bancos de dados enviados por log | Esses serviços têm bancos de dados, mas recomendamos que você inicie esses serviços sem restaurar seus bancos de dados | Esses serviços não armazenam dados em bancos de dados; iniciar esses serviços após o failover |
|---|---|---|
| Serviço de Tradução Automática Serviço de Metadados Gerenciados Serviço de Repositório Seguro Perfil do Usuário. (Há suporte apenas para os bancos de dados de Marcação De Perfil e Social. Não há suporte para o banco de dados de sincronização.) Serviço de Configurações de Assinatura do Microsoft SharePoint Foundation |
Coleta de Dados de Uso e Integridade Serviço de Controle de Sessão Automação do Word |
Serviços do Excel Serviços do PerformancePoint Conversão do PowerPoint Serviço de Gráfico do Visio Gerenciamento de Trabalho |
O exemplo a seguir mostra como restaurar o serviço de Metadados Gerenciados de um banco de dados.
Isso usa o banco de dados Managed_Metadata_DB existente. Esse banco de dados é enviado por log, mas não há nenhum aplicativo de serviço ativo no farm secundário, portanto, ele precisa ser conectado depois que o aplicativo de serviço estiver em vigor.
Primeiro, use New-SPMetadataServiceApplicatione especifique a opção DatabaseName com o nome do banco de dados restaurado.
Em seguida, configure o novo Aplicativo de Serviço de Metadados Gerenciados no servidor secundário, da seguinte maneira:
Nome: Serviço de Metadados Gerenciados
Servidor de banco de dados: o nome do banco de dados do log de transações enviado
Nome do banco de dados: Managed_Metadata_DB
Pool de aplicativos: SharePoint aplicativos de serviço
Gerenciar registros DNS
Você deve criar manualmente registros DNS para apontar para o SharePoint farm.
Na maioria dos casos em que você tem vários servidores Web front-end, faz sentido aproveitar o recurso de Balanceamento de Carga de Rede no Windows Server 2012 ou um balanceador de carga de hardware para distribuir solicitações entre os servidores front-end da Web em seu farm. O balanceamento de carga de rede também pode ajudar a reduzir o risco distribuindo solicitações para os outros servidores se um dos servidores front-end da Web falhar.
Normalmente, quando você configura o balanceamento de carga de rede, o cluster recebe um único endereço IP. Em seguida, você cria um registro de host DNS no provedor DNS para sua rede que aponta para o cluster. (Para este projeto, colocamos um servidor DNS no Azure para resiliência em caso de falha do datacenter local.) Por exemplo, você pode criar um registro DNS, no Gerenciador dns no Active Directory, por exemplo, chamado , https://sharepoint.contoso.comque aponta para o endereço IP do cluster com balanceamento de carga.
Para acesso externo ao farm do SharePoint, você pode criar um registro de host em um servidor DNS externo com a mesma URL que os clientes usam na intranet (por exemplo) https://sharepoint.contoso.comque aponta para um endereço IP externo no firewall. (Uma prática recomendada, usando este exemplo, é configurar o DNS dividido para que o servidor DNS interno seja autoritativo contoso.com e encaminhe solicitações diretamente para o cluster de farm do SharePoint, em vez de rotear solicitações DNS para o servidor DNS externo.) Em seguida, você pode mapear o endereço IP externo para o endereço IP interno do cluster local para que os clientes localizem os recursos que estão procurando.
A partir daqui, você pode ter alguns cenários diferentes de recuperação de desastre:
Cenário de exemplo: o farm de SharePoint local não está disponível devido a uma falha de hardware no farm de SharePoint local. Nesse caso, depois de concluir as etapas de failover para o farm do Azure SharePoint SharePoint, você poderá configurar o balanceamento de carga de rede nos servidores web-front-end do farm de recuperação, da mesma maneira que fez com o farm local. Em seguida, você pode redirecionar o registro de host em seu provedor DNS interno para apontar para o endereço IP do cluster do farm de recuperação. Observe que pode levar algum tempo até que os registros DNS armazenados em cache nos clientes sejam atualizados e apontem para o farm de recuperação.
Cenário de exemplo: o datacenter local é completamente perdido. Esse cenário pode ocorrer devido a um desastre natural, como um incêndio ou inundação. Nesse caso, para uma empresa, você provavelmente teria um datacenter secundário hospedado em outra região, bem como sua sub-rede do Azure que tem seus próprios serviços de diretório e DNS. Como no cenário de desastre anterior, você pode redirecionar seus registros DNS internos e externos para apontar para o farm de SharePoint do Azure. Novamente, observe que a propagação de registro DNS pode levar algum tempo.
Se você estiver usando conjuntos de sites nomeados pelo host, conforme recomendado na arquitetura e implantação do conjunto de sites nomeado pelo host (SharePoint 2013),poderá ter vários conjuntos de sites hospedados pelo mesmo aplicativo Web em seu farm do SharePoint, com nomes DNS exclusivos (por exemplo, https://sales.contoso.com e https://marketing.contoso.com). Nesse caso, você pode criar registros DNS para cada conjunto de sites que apontam para o endereço IP do cluster. Depois que uma solicitação atinge SharePoint servidores web front-end, eles lidam com o roteamento de cada solicitação para o conjunto de sites apropriado.
Ambiente de prova de conceito da Microsoft
Criamos e testamos um ambiente de prova de conceito para essa solução. A meta de design para nosso ambiente de teste era implantar e recuperar um farm SharePoint que poderíamos encontrar em um ambiente de cliente. Fizemos várias suposições, mas sabíamos que o farm precisava fornecer toda a funcionalidade inicial sem nenhuma personalização. A topologia foi projetada para alta disponibilidade usando diretrizes de práticas recomendadas do campo e do grupo de produtos.
A tabela a seguir descreve as máquinas virtuais hyper-V que criamos e configuramos para o ambiente de teste local.
Tabela: Máquinas virtuais para teste local
| Nome do servidor | Função | Configuração |
|---|---|---|
| DC1 | Controlador de domínio com o Active Directory. | Dois processadores De 512 MB a 4 GB de RAM Disco rígido de 1 x 127 GB |
| RRAS | Servidor configurado com a função RRAS (Serviço de Roteamento e Acesso Remoto). | Dois processadores 2 a 8 GB de RAM Disco rígido de 1 x 127 GB |
| FS1 | Servidor de arquivos com compartilhamentos para backups e um ponto de extremidade para DFSR. | Quatro processadores 2 a 12 GB de RAM Disco rígido de 1 x 127 GB SAN (disco rígido de 1 x 1 TB) Disco rígido de 1 x 750 GB |
| SP-WFE1, SP-WFE2 | Servidores Web front-end. | Quatro processadores 16 GB de RAM |
| SP-APP1, SP-APP2, SP-APP3 | Servidores de aplicativos. | Quatro processadores 2 a 16 GB de RAM |
| SP-SQL-HA1, SP-SQL-HA2 | Servidores de banco de dados, configurados SQL Server grupos de disponibilidade AlwaysOn 2012 para fornecer alta disponibilidade. Essa configuração usa SP-SQL-HA1 e SP-SQL-HA2 como réplicas primárias e secundárias. | Quatro processadores 2 a 16 GB de RAM |
A tabela a seguir descreve as configurações de unidade para as máquinas virtuais hyper-V que criamos e configuramos para os servidores web e de aplicativos front-end para o ambiente de teste local.
Tabela: Requisitos de unidade de máquina virtual para os servidores web front-end e de aplicativos para o teste local
| Letra da unidade | Size | Nome do diretório | Caminho |
|---|---|---|---|
| C | 80 | Unidade do sistema | <DriveLetter>:\Arquivos de Programas\ Microsoft SQL Server\ |
| E | 80 | Unidade de log (40 GB) | <DriveLetter>:\Arquivos de\ Microsoft SQL Server\ MSSQL10_50.MSSQLSERVERMSSQLDATA\\ |
| S | 80 | Página (36 GB) | <DriveLetter>:\Arquivos de\ Programas Microsoft SQL Server\ MSSQLDATA\ |
A tabela a seguir descreve as configurações de unidade para as máquinas virtuais do Hyper-V criadas e configuradas para servir como servidores de banco de dados locais. Na página Mecanismo de Banco de Dados Configuração, acesse a guia Diretórios de Dados para definir e confirmar as configurações mostradas na tabela a seguir.
Tabela: Requisitos de unidade de máquina virtual para o servidor de banco de dados para o teste local
| Letra da unidade | Size | Nome do diretório | Caminho |
|---|---|---|---|
| C | 80 | Diretório raiz de dados | <DriveLetter>:\Arquivos de Programas\ Microsoft SQL Server\ |
| E | 500 | Diretório de banco de dados do usuário | <DriveLetter>:\Arquivos de\ Microsoft SQL Server\ MSSQL10_50.MSSQLSERVERMSSQLDATA\\ |
| S | 500 | Diretório de log do banco de dados do usuário | <DriveLetter>:\Arquivos de\ Microsoft SQL Server\ MSSQL10_50.MSSQLSERVERMSSQLDATA\\ |
| G | 500 | Diretório de BD Temporário | <DriveLetter>:\Arquivos de\ Microsoft SQL Server\ MSSQL10_50.MSSQLSERVERMSSQLDATA\\ |
| H | 500 | Diretório de log do BD Temporário | <DriveLetter>:\Arquivos de\ Microsoft SQL Server\ MSSQL10_50.MSSQLSERVERMSSQLDATA\\ |
Configurando o ambiente de teste
Durante as diferentes fases de implantação, a equipe de teste normalmente trabalhou na arquitetura local primeiro e, em seguida, no ambiente do Azure correspondente. Isso reflete os casos gerais do mundo real em que as fazendas de produção internas já estão em execução. O que é ainda mais importante é que você deve saber a carga de trabalho de produção atual, a capacidade e o desempenho típico. Além de criar um modelo de recuperação de desastre que possa atender aos requisitos de negócios, você deve dimensionar os servidores do farm de recuperação para fornecer um nível mínimo de serviço. Em um ambiente de espera frio ou quente, um farm de recuperação normalmente é menor do que um farm de produção. Depois que o farm de recuperação estiver estável e em produção, o farm poderá ser escalado verticalmente e horizontalmente para atender aos requisitos de carga de trabalho.
Implantamos nosso ambiente de teste nas três fases a seguir:
Configurar a infraestrutura híbrida
Provisionar os servidores
Implantar os farms SharePoint dados
Configurar a infraestrutura híbrida
Essa fase envolveu a configuração de um ambiente de domínio para o farm local e para o farm de recuperação no Azure. Além das tarefas normais associadas à configuração do Active Directory, a equipe de teste implementou uma solução de roteamento e uma conexão VPN entre os dois ambientes.
Provisionar os servidores
Além dos servidores de farm, era necessário provisionar servidores para os controladores de domínio e configurar um servidor para lidar com o RRAS, bem como a VPN site a site. Dois servidores de arquivos foram provisionados para o serviço DFSR e vários computadores cliente foram provisionados para testadores.
Implantar os farms SharePoint dados
Os SharePoint farms foram implantados em dois estágios para simplificar a estabilização e a solução de problemas do ambiente, se necessário. Durante o primeiro estágio, cada farm foi implantado no número mínimo de servidores para cada camada da topologia para dar suporte à funcionalidade necessária.
Criamos os servidores de banco de SQL Server instalados antes de criar os servidores SharePoint 2013. Como essa era uma nova implantação, criamos os grupos de disponibilidade antes de implantar SharePoint. Criamos três grupos com base nas diretrizes de práticas recomendadas do MCS.
Observação
Crie bancos de dados de espaço reservado para que você possa criar grupos de disponibilidade antes da SharePoint instalação. Para obter mais informações, consulte Configure SQL Server 2012 AlwaysOn Availability Groups for SharePoint 2013
Criamos o farm e ingressados em servidores adicionais na seguinte ordem:
Provisione SP-SQL-HA1 e SP-SQL-HA2.
Configure o AlwaysOn e crie os três grupos de disponibilidade para o farm.
Provisione SP-APP1 para hospedar a Administração Central.
Provisione SP-WFE1 e SP-WFE2 para hospedar o cache distribuído.
Usamos o parâmetro skipRegisterAsDistributedCachehost quando executamos psconfig.exena linha de comando. Para obter mais informações, consulte Plan for feeds and the Distributed Cache service in SharePoint Server 2013.
Repetimos as seguintes etapas no ambiente de recuperação:
Provisione AZ-SQL-HA1 e AZ-SQL-HA2.
Configure o AlwaysOn e crie os três grupos de disponibilidade para o farm.
Provisione o AZ-APP1 para hospedar a Administração Central.
Provisione o AZ-WFE1 e o AZ-WFE2 para hospedar o cache distribuído.
Depois de configurarmos o cache distribuído e adicionamos usuários de teste e conteúdo de teste, começamos a fase dois da implantação. Isso exigia escalar horizontalmente as camadas e configurar os servidores de farm para dar suporte à topologia de alta disponibilidade descrita na arquitetura do farm.
A tabela a seguir descreve as máquinas virtuais, sub-redes e conjuntos de disponibilidade que configuramos para nosso farm de recuperação.
Tabela: infraestrutura do farm de recuperação
| Nome do servidor | Função | Configuração | Sub-rede | Conjunto de disponibilidade |
|---|---|---|---|---|
| spDRAD | Controlador de domínio com o Active Directory | Dois processadores De 512 MB a 4 GB de RAM Disco rígido de 1 x 127 GB |
sp-ADservers | |
| AZ-SP-FS | Servidor de arquivos com compartilhamentos para backups e um ponto de extremidade para DFSR | Configuração do A5: Dois processadores 14 GB de RAM Disco rígido de 1 x 127 GB Disco rígido de 1 x 135 GB Disco rígido de 1 x 127 GB Disco rígido de 1 x 150 GB |
sp-databaseservers | DATA_SET |
| AZ-WFE1, AZ -WFE2 | Servidores Web front-end | Configuração do A5: Dois processadores 14 GB de RAM Disco rígido de 1 x 127 GB |
sp-webservers | WFE_SET |
| AZ -APP1, AZ -APP2, AZ -APP3 | Servidores de aplicativos | Configuração do A5: Dois processadores 14 GB de RAM Disco rígido de 1 x 127 GB |
sp-applicationservers | APP_SET |
| AZ -SQL-HA1, AZ -SQL-HA2 | Servidores de banco de dados e réplicas primárias e secundárias para grupos de disponibilidade AlwaysOn | Configuração do A5: Dois processadores 14 GB de RAM |
sp-databaseservers | DATA_SET |
Operações
Depois que a equipe de teste estabiliza os ambientes de farm e concluiu o teste funcional, ela iniciou as seguintes tarefas de operações necessárias para configurar o ambiente de recuperação local:
Configure backups completos e diferenciais.
Configure o DFSR nos servidores de arquivos que transferem logs de transação entre o ambiente local e o ambiente do Azure.
Configure o envio de logs no servidor de banco de dados primário.
Estabilizar, validar e solucionar problemas de envio de logs, conforme necessário. Isso inclui identificar e documentar qualquer comportamento que possa causar problemas, como latência de rede, o que causaria falhas de sincronização de arquivo DFSR ou envio de logs.
Bancos de dados
Nossos testes de failover envolveram os seguintes bancos de dados:
WSS_Content
ManagedMetadata
Banco de Dados de Perfil
Sincronizar banco de dados
Banco de Dados Social
Hub de Tipo de Conteúdo (um banco de dados para um Hub de Sindicalização de Tipo de Conteúdo dedicado)
Dicas de solução de problemas
A seção explica os problemas que encontramos durante nossos testes e suas soluções.
O uso da Ferramenta de Gerenciamento do Repositório de Termos causou o erro "O Repositório de Metadados Gerenciados ou a Conexão não está disponível no momento".
Verifique se a conta do pool de aplicativos usada pelo aplicativo Web tem a permissão Acesso de Leitura ao Repositório de Termos.
Conjuntos de termos personalizados não estão disponíveis no conjunto de sites
Verifique se há uma associação de aplicativo de serviço ausente entre o conjunto de sites de conteúdo e o hub de tipo de conteúdo. Além disso, na <site collection name> tela Propriedades de Metadados Gerenciados – Conexão, verifique se essa opção está habilitada: esse aplicativo de serviço é o local de armazenamento padrão para conjuntos de termos específicos de coluna.
O Get-ADForest Windows PowerShell comando gera o erro "O termo 'Get-ADForest' não é reconhecido como o nome de um cmdlet, função, arquivo de script ou programa operável".
Ao configurar perfis de usuário, você precisa do nome da floresta do Active Directory. No Assistente para Adicionar Funções e Recursos, verifique se você habilitou o Módulo do Active Directory para Windows PowerShell (na seção Ferramentas de Administração de Servidor Remoto>Ferramentas de Administração de Função >AD DS e AD LDS Tools). Além disso, execute os comandos a seguir antes de usar Get-ADForest para ajudar a garantir que suas dependências de software sejam carregadas.
Import-Module ServerManager
Import-Module ActiveDirectory
Falha na criação do grupo de disponibilidade ao iniciar a sessão XEvent 'AlwaysOn_health' em '<server name>'
Verifique se os dois nós do cluster de failover estão no status "Para cima" e não "Pausado" ou "Parado".
SQL Server trabalho de envio de logs falha com o erro de acesso negado ao tentar se conectar ao compartilhamento de arquivos
Verifique se o SQL Server Agent está em execução em credenciais de rede, em vez das credenciais padrão.
SQL Server de envio de logs indica êxito, mas nenhum arquivo é copiado
Isso acontece porque a preferência de backup padrão para um grupo de disponibilidade é Preferir Secundário. Verifique se você executa o trabalho de envio de logs do servidor secundário para o grupo de disponibilidade em vez do primário; caso contrário, o trabalho falhará silenciosamente.
O serviço de Metadados Gerenciados (ou outro serviço SharePoint) falha ao iniciar automaticamente após a instalação
Os serviços podem levar vários minutos para serem iniciados, dependendo do desempenho e da carga atual do SharePoint Server. Clique manualmente em Iniciar para o serviço e forneça o tempo adequado para inicialização enquanto atualiza ocasionalmente a tela Serviços no Servidor para monitorar seu status. Caso o serviço permaneça parado, habilite SharePoint log de diagnóstico, tente iniciar o serviço novamente e verifique se há erros no log. Para obter mais informações, consulte Configurar o log de diagnóstico no SharePoint 2013
Depois de alterar o DNS para o ambiente de failover do Azure, os navegadores do cliente continuam a usar o endereço IP antigo para o SharePoint site
A alteração de DNS pode não estar visível para todos os clientes imediatamente. Em um cliente de teste, execute o comando a seguir em um prompt de comando com privilégios elevados e tente acessar o site novamente.
Ipconfig /flushdns
Recursos adicionais
Configurar SQL Server grupos de disponibilidade AlwaysOn 2012 para SharePoint 2013