Recuperação de Desastres e Restauração de Escopo no Workflow Manager 1.0

Este tópico fornece uma visão geral das opções e procedimentos de recuperação de desastres para o Workflow Manager 1.0. Ele cobre procedimentos para lidar com falhas de servidor de bancos de dados, falhas de servidor de aplicativos e fornece procedimentos para restaurar um escopo corrompido ou excluído.

• Recuperação de desastres

• Restauração de Escopo

Recuperação de desastres

O Workflow Manager 1.0 permite que você se prepare para lidar com cenários de desastre. No escopo deste tópico, um desastre é um evento que causa perda grave, destruição, dificuldade e assim por diante. No caso de um produto de servidor, isso representa qualquer evento que resulta em perturbações prolongadas a disponibilidade do servidor e pode ser acompanhado por vários graus de perda do cluster original (ou partes dele) que foi configurado para o servidor.

Recuperação de Desastres vs. Alta Disponibilidade

Normalmente, a Recuperação de Desastres é confundida com a Alta Disponibilidade. A Alta Disponibilidade consiste na disponibilização de alta disponibilidade do serviço em circunstâncias normais – incluindo a criação de redundâncias suficientes no sistema e eliminação de pontos únicos de falha. Porém, a Recuperação de Desastres consiste na indisponibilidade do serviço principal devido a circunstâncias alheias (como um desastre natural) e o mesmo nível de serviço tem que continuar sendo disponibilizado.

Modelo de recuperação de desastre de alto nível

O processo de preparação e resposta a um desastre pode ser divido em várias etapas como mostrado nas seguintes seções. Esse diagrama ilustra cada uma dessas etapas e expõe as responsabilidades que o usuário tem versus as funcionalidades fornecidas pelo Workflow Manager.

Diferentes tipos de cenários de desastre do Workflow Manager

No caso do Workflow Manager, podem ocorrer diferentes cenários de desastre para os quais deve estar preparado.

1. Um desastre que resulte na perda de um ou mais bancos de dados usados pelo Workflow Manager.

   1. Isso pode ter sido causado por uma falha de hardware ou um desastre no data center.

2. Um desastre que resulte na perda dos servidores de aplicativo onde os binários do Workflow Manager foram implantados.

3. Um desastre que resulte na perda de todo o cluster, onde os servidores e os bancos de dados do aplicativo se perderam.

Como o Workflow Manager contém informações relacionadas aos fluxos de trabalho, atividades e instâncias do usuário, uma das partes principais da Recuperação de Desastres do Workflow Manager é a capacidade de restaurar os dados de instalação do Workflow Manager usando cópias de backup. Assim, na maioria desses cenários, a recuperação de desastres tem a ver principalmente com a restauração de dados de backups e a verificação da consistência dos dados nos vários subsistemas do Workflow Manager.

Preparação para uma recuperação de desastre

A Recuperação de Desastres tem a ver com estar preparado para uma emergência, caso ocorra. Com o Workflow Manager, você pode desejar preservar os dados relacionados a todas as atividades, fluxos de trabalho e instâncias mesmo em caso de desastre.

O Workflow Manager armazena todos os seus dados em bancos de dados do SQL Server. Assim, um pré-requisito importante para a recuperação de desastres é configurar backups periódicos e/ou soluções de redundância de dados de modo que, caso um desastre real atinja o seu data center, exista uma cópia recente do seu banco de dados para que você possa restaurar a instalação do Workflow Manager.

A instalação do Workflow Manager usa os seguintes bancos de dados.

Dependendo no nível de criticidade dos dados do fluxo de trabalho que você tem na sua instalação do Workflow Manager, é possível escolher entre várias opções de preparação de recuperação de desastres. Já que todos os dados do Workflow Manager são armazenados nos banco de dados do SQL Server mencionados acima, qualquer estratégia do SQL Server baseada em alta disponibilidade e backup deve ser aplicada também no Workflow Manager.

Sobre implementação de Para obter mais informações sobre de alta disponibilidade e recuperação de desastres para o SQL Server, consulte Selecionar uma solução de alta disponibilidade e Descrição de opções de recuperação de desastres do Microsoft SQL Server.

O seguinte diagrama lista os diferentes componentes de uma instalação do Workflow Manager.

Do ponto de vista do administrador do farm de servidor, existem duas partes potenciais do Workflow Manager que podem deixar de funcionar em caso de desastre: Um ou mais dos bancos de dados envolvidos ou um ou mais dos nós de servidor de aplicativo. Podem haver diferentes combinações de servidores de aplicativo e banco de dados indisponíveis, mas em um alto nível, a camada de dados e a camada de aplicativo são os pontos de falha.

• Camada de Dados

• Camada de Computação (Camada do Workflow/Sistema de Mensagens)

Camada de Dados

O Workflow Manager 1.0 armazena os seus dados nos seguintes bancos de dados do SQL Server.

Com relação à camada de dados, existem três tarefas importantes associadas à recuperação de desastres:

1. Preparação - verificar que você tem a estratégia de backup/replicação correta para os seus bancos de dados, de modo que não perca dados em caso de um desastre envolvendo os bancos de dados.

   Para recuperar de uma situação de desastre, você deve estar preparado para o desastre. Especificamente, com relação a desastres que envolvem a perda dos bancos de dados, você deve ter uma maneira de armazenar uma cópia dos dados em um local diferente. Uma vez que esses bancos de dados são bancos de dados SQL padrão, é recomendado que use as técnicas SQL estabelecidas, como:

   1. Espelhamento SQL

   2. Replicação SQL

   3. Backups simples assim como a combinação de backups e envio de logs

   Você pode escolher entre qualquer uma dessas técnicas dependendo da natureza do seu negócio e o nível de fidelidade de dados que deseja entre os seus bancos de dados primários e de backup.

   Essencialmente, é esperado que você, como administrador do seu farm do Workflow Manager, crie backups desses bancos de dados usando uma estratégia de backup apropriada que se adeque a suas necessidades. O Workflow Manager não fornece funcionalidades para ajudar na criação desses bancos de dados de backup.

2. Restaurar os bancos de dados de backup

   Dependendo da sua estratégia de replicação de dados, você teria que usar uma ferramenta/mecanismo de restauração adequada para restaurar os bancos de dados de backup. Existem ferramentas e técnicas SQL padrões do setor que você pode usar para restaurar os bancos de dados SQL.

3. Restaurar o farm do Workflow Manager.

   Esta etapa refere-se ao processo de verificação da consistência e funcionamento adequado do farm do Workflow Manager restaurado. O Workflow Manager fornece os scripts de PowerShell e a ajuda necessários para realizar a etapa.

Camada de Computação (Camada do Workflow/Sistema de Mensagens)

Você pode criar um farm secundário em um local secundário para ajudar em caso de cenários de recuperação de desastres. Você pode criar o farm secundário antes ou depois do desastre. Existem três modelos a considerar.

1. Espera a frio

   Neste modelo, você pode recriar o farm após o desastre ter ocorrido. Isto tem impacto sobre o tempo necessário para recuperar o farm, uma vez que você teria que provisionar novos nós de computação e instalar o Workflow Manager nesses nós de novo.

2. Espera passiva

   Você pode optar por este modelo se desejar certificar-se que tem um farm secundário criado e testado antes mesmo de um desastre ocorrer. Nesse modelo, você provisiona nós de computação no novo farm antes do desastre. Após estabelecer o relacionamento de paridade do banco de dados, você aponta esse novo farm para bancos de dados secundários.

   Após configurar esse novo farm, essencialmente, você desliga os nós de computação para que eles não fiquem em um estado ocioso. Como parte de uma recuperação de desastre, você tem que executar os scripts de consistência do banco de dados fornecidos pelo Workflow Manager.

   Observação

   Este modelo assume que os novos bancos de dados de contêiner do Barramento do Serviço não estão sendo criados no primário após a configuração inicial ter sido realizada. Se um novo banco de dados de Contêiner do Barramento do Serviço é criado no primário, são necessárias etapas adicionais durante a recuperação.

3. Espera ativa

   Trata-se de uma melhoria em relação à Espera passiva onde os nós de computação podem estar ligados. Isto iria diminuir o tempo necessário para recuperar de um desastre.

   Aviso

   A Espera ativa não é suportada pelo Workflow Manager.

Processo de recuperação de desastres

Esta seção descreve o processo de recuperação de desastres reais usado para os vários cenários de desastre explicados anteriormente. Em um nível mais alto, o processo recomendado é restaurar os bancos de dados necessários de um backup (que você criou usando uma das técnicas SQL Server padrão) e usar os cmdlets de restauração fornecidos pelo Workflow Manager para restaurar o farm.

Processo para executar os comandos de restauração

1. Exporte o certificado do farm e o certificado de criptografia do Barramento de Serviço, ambos com a chave privada. Importe ambos na pasta Computador Local/Pessoal do novo servidor. Importe também os certificados raiz para a pasta Computador Local\Autoridade Raiz Confiável do novo servidor. Você pode identificar o certificado do farm e o certificado de criptografia na saída Get-SBFarm.

   Observação

   A importação só funciona quando os certificados de criptografia antigos do Barramento de Serviço originários de servidores WFM/SB antigos foram: Gerados automaticamente durante a configuração do farm antigo pela ferramenta de configuração. Ou, caso você tenha usado certificados personalizados para o Barramento de Serviço no ambiente antigo, eles devem ser certificados curinga do domínio, ou seja, o campo "Nome Alternativo da Entidade" nos certificados foi criado com um valor como - *.mydomainname.com. Se a importação do certificado antigo do Barramento de Serviço não for executada, o cmdlet Restore-WFFarm nas próximas etapas falhará com um erro semelhante ao exibido a seguir. Token provider returned message: '<Error><Code>400</Code><Detail>The namespace 'WorkflowDefaultNamespace' does not have a valid issuer that can be used to issue tokens. Add a valid issuer with a valid signature to the namespace.

2. Abra uma janela PowerShell (Administrador RunAs) elevada em um novo computador.

3. Chame o cmdlet Restore-SBFarm passando os seguintes parâmetros. Este cmdlet cria um novo banco de dados de Gerenciamento de Farm do Barramento do Serviço. O antigo banco de dados de Gerenciamento de Farm do Barramento do Serviço pode ser excluído.

   Restore-SBFarm -FarmCertificateThumbprint <String> -GatewayDBConnectionString <String> -SBFarmDBConnectionString <String> [-AdminApiCredentials <PSCredential> ] [-AdminGroup <String> ] [-AmqpPort <Int32> ] [-AmqpsPort <Int32> ] [-EncryptionCertificateThumbprint <String> ] [-FarmDns <String> ] [-Force] [-HttpsPort <Int32> ] [-InternalPortRangeStart <Int32> ] [-MessageBrokerPort <Int32> ] [-RPHttpsPort <Int32> ] [-RunAsAccount <String> ] [-TcpPort <Int32> ] [-TenantApiCredentials <PSCredential> ] [-Confirm] [-WhatIf] [ <CommonParameters>]
   

   Observação

   Se você tiver usado certificados curinga personalizados na configuração antiga do Barramento de Serviço e usado dois certificados diferentes para FarmCertificate e EncryptionCertificate, será necessário importar ambos em cada novo nó e fornecer os parâmetros FarmCertificateThumbprint e EncryptionCertificateThumbprint no cmdlet acima adequadamente.

   O trecho de código a seguir é um exemplo de chamada a Restore-SBFarm.

   Restore-SBFarm -RunAsAccount 'farm\test' -FarmCertificateThumbprint 41FED42EC87EA556FB64A41572111B96D13FBFC2 -GatewayDBConnectionString 'Data Source=DBServer;Initial Catalog=SbGatewayDatabase;Integrated Security=True;Encrypt=False' -SBFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False' -AdminGroup 'BUILTIN\Administrators' -EncryptionCertificateThumbprint 41FED42EC87EA556FB64A41572111B96D13FBFC2
   

4. Chame o cmdlet Restore-SBGateway em um dos nós do farm com os seguintes parâmetros.

   Parâmetro	Descrição
   SBFarmDBConnectionString	Cadeia de conexão do banco de dados do farm do Service Bus que é criado na etapa anterior.
   GatewayDBConnectionString	Cadeia de conexão do banco de dados de gateway restaurado.

   O trecho de código a seguir é um exemplo de chamada a Restore-SBGateway.

   Restore-SBGateway -GatewayDBConnectionString 'Data Source= DBServer;Initial Catalog=SbGatewayDatabase;Integrated Security=True;Encrypt=False' -SBFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False'
   

5. Para cada banco de dados do contêiner, chame o cmdlet Restore-SBMessageContainer com os seguintes parâmetros. Execute este cmdlet em um dos computadores do farm.

   Parâmetro	Descrição
   SBFarmDBConnectionString	Cadeia de conexão do banco de dados do farm do Service Bus que é criado na etapa anterior.
   ContainerDBConnectionString	Cadeia de conexão do banco de dados de contêiner.
   Id	ID do contêiner de mensagens restaurado. Obtém o ID do contêiner de mensagens restaurado da tabela [dbo].[ContainersTable] do banco de dados de gateway, que contém os IDs, cadeias de conexão, nomes dos servidores de banco de dados e nomes dos bancos de dados de todos os contêineres de mensagens. Selecione o ID do contêiner cujos nomes do banco de dados correspondam ao nome do banco de dados de contêiner original.

   O trecho a seguir é um exemplo de chamada do cmdlet Restore-SBMessageContainer.

   Restore-SBMessageContainer -ContainerDBConnectionString "Data Source=localhost;Initial Catalog=SBMessageContainer01;Integrated Security=SSPI;Asynchronous Processing=True" -SBFarmDBConnectionString "Data Source=localhost;Initial Catalog= SBManagementDB;Integrated Security=SSPI;Asynchronous Processing=True" –id 1
   

6. Chame o cmdlet Add-SBHost e passe os seguintes parâmetros.

   Parâmetro	Descrição
   SBFarmDBConnectionString	Cadeia de conexão do banco de dados do farm do Service Bus que foi criado na etapa anterior.
   CertificateAutoGenerationKey	Esta é a chave usada para a geração automática de certificados de SB
   RunAsPassword	SecureString que contém a senha da conta sob a qual os processos de Service Bus são executados.
   EnableFirewallRules	Verdadeiro se as regras de firewall do host devem ser atualizadas para permitir que os dados do Service Bus passem pelo firewall. Caso contrário, falso.

   O exemplo a seguir demonstra como invocar o cmdlet.

   $myPassword=convertto-securestring 'ereee' -asplaintext -force Add-SBHost -EnableFirewallRules $TRUE -RunAsPassword $myPassword -SBFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=SbManagementDB;Integrated Security=True;Encrypt=False'
   

7. Chame o cmdlet Restore-WFFarm, usando as cadeias de conexão de Banco de Dados de Instância e ResourceManagement.

   O exemplo a seguir demonstra como invocar o cmdlet.

   $mykey=convertto-securestring 'etwegff' -asplaintext -force Restore-WFFarm  -RunAsAccount 'farm\test' -InstanceDBConnectionString 'Data Source= DBServer;Initial Catalog=WFInstanceManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False' -ResourceDBConnectionString 'Data Source= DBServer;Initial Catalog=WFResourceManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False' -WFFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=WFManagementDB;Integrated Security=True;Encrypt=False' -InstanceStateSyncTime 'Sunday, May 11, 2014 12:30:00 PM' -ConsistencyVerifierLogPath 'c:\log.txt' -CertificateAutoGenerationKey $myKey
   

   Observação

   O InstanceStateSyncTime deve seguir o exatamente o formato especificado no exemplo anterior. ConsistencyVerifierLogPath deve ser o caminho para a pasta onde esse cmdlet deve gravar os logs relacionados com o processo de restauração.

8. Chame o cmdlet Add-WFHost.

   O exemplo a seguir demonstra como invocar o cmdlet.

   Add-WFHost -WFFarmDBConnectionString 'Data Source= DBServer;Initial Catalog=WFManagementDB;Integrated Security=True;Asynchronous Processing=True;Encrypt=False' -RunAsPassword $myPassword -EnableFirewallRules $TRUE -CertificateAutoGenerationKey $myKey
   

Cenário 1 - O desastre afeta todo o cluster

Neste cenário, todo o cluster é afetado por causa de um desastre. Para recuperar deste cenário de desastre, todo o cluster deve ser reconstruído, usando os backups de banco de dados mais recentes.

1. Instale o Workflow Manager 1.0 em um novo computador.

   Observação

   Instale o Workflow Manager 1.0 usando o instalador, mas não inicie a configuração do farm

2. Restaure os bancos de dados primários de backup usando as recursos de Restauração do SQL Server. Esta etapa varia consoante a escolha da solução de backup.

   Apenas o seguinte banco de dados deve ser restaurado.

   • WFResourceManagementDB

   • WFInstanceManagementDB

   • SbGatewayDatabase

   • SBMessageContainer*

   Importante
   Não restaure os bancos de dados WFManagementDB e SbManagementDb, uma vez que eles serão recriados como parte da operação de restauração.

3. Siga as etapas descritas em Processo para executar os comandos de restauração.

Cenário 2 - O desastre afeta apenas os bancos de dados do SQL Server

Neste caso, um ou mais bancos de dados usados pelo Workflow Manager foram perdidos ou estão inacessíveis. Isso pode ter sido causado por uma falha de hardware ou qualquer outro desastre local apenas nos SQL Servers.

1. Desinstale o Workflow Manager 1.0 de um dos nós do servidor de aplicativo existentes.

2. Reinstale o Workflow Manager 1.0 no servidor da etapa anterior.

   Observação

   Instale o Workflow Manager usando o instalador, mas não inicie a configuração do farm

3. Restaure os bancos de dados primários de backup usando as recursos de Restauração do SQL Server. Esta etapa varia consoante a escolha da solução de backup. Você pode restaurar para um SQL Server existente ou para um SQL Server diferente dependendo da natureza do desastre.

4. Siga as etapas descritas em Processo para executar os comandos de restauração.

Quando essas etapas estiverem concluídas, você terá um farm com um nó que usa os bancos de dados existentes. Este farm foi restaurado com as suas cópias de backup dos bancos de dados originais e esse farm foi levado a um estado consistente para que ele seja totalmente funcional.

Para cada nó que foi parte do farm primário, siga as seguintes etapas.

1. Desinstale o Workflow Manager 1.0

2. Reinstale o Workflow Manager 1.0.

3. Execute os cmdlets Add-SBHost e Add-WFHost, conforme descrito em Processo para executar os comandos de restauração.

Cenário 3 - O desastre afeta apenas os servidores de aplicativos

Às vezes, é possível que apenas os servidores de aplicativos falhem ou se percam devido a um desastre local e os servidores de banco da dados fiquem intactos. Embora este seja um cenário raro em um data center, é muito fácil recuperar, caso um desastre desse tipo ocorra. Uma vez que você não perdeu os seus bancos de dados, você desejaria continuar com a localização primária e adicionar novos nós a este farm existente. Caso deseje mover para uma localização secundária por qualquer motivo, você poderia copiar os bancos de dados para a segunda localização e fazer referência aos novos bancos de dados quando realizar as etapas de recuperação.

Para recuperar de cenários de desastre de servidor de aplicativos, siga as seguintes etapas.

1. Instale o Workflow Manager 1.0 em um novo computador.

2. Remova os seguintes bancos de dados.

   • WFManagementDB

   • SbManagementDB

3. Siga o procedimento descrito em Processo para executar os comandos de restauração.

   Observação

   Se você moveu os bancos de dados, faça referência aos novos bancos de dados quando seguir estes passos; caso contrário faça referência aos bancos de dados originais.

Quando essas etapas estiverem concluídas, você terá um farm com um nó que usa os bancos de dados existentes (ou movidos). Se desejar, você pode adicionar nós adicionais ao farm do mesmo modo que você adicionaria mais nós em um farm do Workflow Manager.

Restauração de Escopo

Podem haver situações, nas quais você excluiu acidentalmente um determinado escopo ou os conteúdos de um determinado escopo estão corrompidos. Você também tem um backup dos seus bancos de dados do Workflow Manager de quando os conteúdos do escopo estavam em ordem. Você pode desejar restaurar os conteúdos apenas desse escopo da cópia de backup.

Quando você restaura um escopo, os seguintes conteúdos são restaurados.

• Escopos e escopos filho junto com as suas configurações

• Atividades dentro da hierarquia do escopo sendo restaurado

• Fluxos de trabalho dentro da hierarquia de escopo junto com as suas configurações

• Instâncias para os fluxos de trabalho dentro da hierarquia de escopo

  • As instâncias continuariam a sua execução a partir do seu último ponto de persistência.

• Registros de rastreamento correspondentes a essas instâncias.

• Quaisquer mensagens não entregues aos fluxos de trabalho dentro dessa hierarquia de escopo

A seguinte tabela descreve as principais terminologias usadas em uma operação de restauração de escopo.

O Workflow Manager fornece as funcionalidades para permitir este cenário. Aqui estão as etapas que você tem de seguir para realizar uma restauração de escopo.

• Processo de restauração de escopo

• Considerações de restauração de escopo

Processo de restauração de escopo

O escopo que você deseja restaurar não deve existir no(s) banco(s) de dados em execução. Logo, se está restaurando um escopo de um backup porque o banco de dados em execução contém uma cópia corrompida desse escopo, você deve excluir esse escopo corrompido do banco de dados em execução.

1. Restaurar os Bancos de Dados SQL: A primeira etapa é restaurar os bancos de dados SQL usando os backups como destacado em Restaurar um backup de banco de dados (SQL Server Management Studio).

   Importante
   Você deve restaurar os bancos de dados de backup para um servidor diferente. Não substitua os bancos de dados em execução.

2. Execute o comando PowerShell Restore-WFScope passando os seguintes parâmetros,

   • Caminho do escopo a restaurar

   • Cadeia de conexão do backup do BD de Recurso

   • Cadeia de conexão do backup do BD de Instância

   • Forneça a hora em que os backups foram criados – essa pode ser uma estimativa aproximada. Se os backups dos bancos de dados foram feitos em diferentes momentos, verifique se o mais antigo desses carimbos de data/hora é fornecido como entrada nesta etapa.

   • Cadeia de conexão do BD de Gateway

   • Cadeias de conexão de um ou mais bancos de dados de contêiner. Geralmente, você teria apenas um banco de dados de contêiner. Caso o seu servidor tenha vários bancos de dados de contêiner, verifique se você fornece todas essas cadeias de conexão para este cmdlet.

   Nesse ponto, o escopo e o conteúdo devem estar restaurados no banco de dados em execução e os recém restaurados bancos de dados de backup podem ser removidos.

Considerações de restauração de escopo

Embora a Restauração de Escopo restaure o escopo a partir de bancos de dados de backup restaurados, você deve observar os seguintes pontos sobre o processo de restauração de um modo geral.

• Você só pode restaurar um escopo a partir de uma cópia de backup anterior do banco de dados atualmente em execução. Em outras palavras, você não pode tentar mover um determinado escopo de um farm do Workflow Manager para outro.

• A Restauração de Escopo apenas restaura os conteúdos pertencentes ao escopo e todos os seus filhos. Ela não restaura nenhum conteúdo fora dessa hierarquia de filhos do escopo.

• Se uma atividade ou um fluxo de trabalho estiver referenciando outra atividade fora dessa hierarquia de escopo (digamos que, a atividade referenciada está em um escopo pai acima do escopo sendo restaurado), a atividade referenciada não será restaurada como parte dessa operação. Isso significa que tais fluxos de trabalho seriam inválidos e qualquer tentativa de criar uma instância desses fluxos de trabalho resultaria em erros.