在 Workflow Manager 1.0 中进行灾难恢复和范围还原

 

本主题概述了用于 Workflow Manager 1.0 的灾难恢复选项和过程。 它介绍了处理数据库服务器故障、应用程序服务器故障的过程，并提供了还原已损坏或已删除范围的过程。

• 灾难恢复

• 范围还原

灾难恢复

使用 Workflow Manager 1.0 可以为处理灾难方案做准备。 在本主题的范围内，灾难是指导致严重损失、破坏、困难等的事件。 对于服务器产品来说，灾难是指导致服务器可用性中断延长的任何事件，并可能伴随为服务器设置的初始群集（或群集部件）的不同程度的损失。

灾难恢复与高可用性

通常，灾难恢复与高可用性交织在一起。 高可用性是确保在正常情况下服务高度可用（包括在系统中构建足够的冗余以及消除单点故障）的问题， 而灾难恢复则是在主要服务因外在因素（如自然灾害）影响出现故障的情况下，必须继续提供相同级别服务的问题。

高级别灾难恢复模式

为灾难做准备和应对灾难的过程可分为多个阶段，如以下部分所示。 此图说明了其中每一个阶段，并标出了用户使用 Workflow Manager 提供的相应功能时所需履行的职责。

针对 Workflow Manager 的不同类型的灾难方案

对于 Workflow Manager，应准备不同的灾难方案。

1. 导致 Workflow Manager 所使用的一个或多个数据库丢失的灾难。

   1. 这可能是由硬件故障或日期中心范围的灾难事件导致的。

2. 导致已部署 Workflow Manager 二进制文件的应用程序服务器丢失的灾难。

3. 导致整个群集丢失（其中的应用程序服务器和数据库均丢失）的灾难。

由于 Workflow Manager 包含与用户的工作流、活动和实例相关的信息，因此在进行 Workflow Manager 灾难恢复时，关键是能够使用备份副本还原 Workflow Manager 安装的数据。 因此，在这些方案的大多数中，灾难恢复主要是从备份中还原数据，并确保数据在 Workflow Manager 的各个子系统之间保持一致性。

为灾难恢复做准备

简而言之，灾难恢复是指为可能出现的紧急情况做准备。 你可能希望使用 Workflow Manager 保留与所有活动、工作流和实例相关的数据（即使在发生灾难的情况下）。

Workflow Manager 将其所有数据存储在 SQL Server 数据库中。 因此，灾难恢复的重要前提条件是设置定期备份和/或数据冗余解决方案，以便在袭击数据中心的灾难实际发生时，能够使用最新的数据库副本来还原你的 Workflow Manager 安装。

Workflow Manager 安装使用以下数据库。

数据库名称	说明
WFManagementDB	Workflow Manager 场管理数据库
SbManagementDB	Service Bus 场管理数据库
WFResourceManagementDB	Workflow Manager 资源管理存储
WFInstanceManagementDB	Workflow Manager 实例管理存储
SbGatewayDatabase	Service Bus 网关数据库
SBMessageContainer01 - n	Service Bus 消息容器数据库

你可以根据 Workflow Manager 安装中工作流数据的重要程度，从各种灾难恢复准备选项中进行选择。 由于 Workflow Manager 的所有数据存储在上述 SQL Server 数据库中，因此任何基于 SQL Server 的高可用性和备份策略也应适用于 Workflow Manager。

有关 有关 对 SQL Server 实施高可用性和灾难恢复的详细信息，请参阅 Selecting a High Availability Solution（选择高可用性解决方案）和 Description of disaster recovery options for Microsoft SQL Server（Microsoft SQL Server 的灾难恢复选项的说明）。

注意
无论你选择哪个选项来备份这些数据库，请确保这些备份在时间上不要相差太远。 例如，如果这些单个数据库的备份彼此相差几个小时或几天，则 Workflow Manager 将难以正确还原。

下图列出了 Workflow Manager 安装的不同组件。

从服务器场管理员的角度来看，Workflow Manager 有两个潜在部分在发生灾难时可能中断：所涉及的一个或多个数据库，或者一个或多个应用程序服务器节点。 应用程序和数据库服务器故障可能存在不同的组合，但从高级别来看，故障点是在数据层和应用层。

• 数据层

• 计算层（工作流/消息层）

数据层

Workflow Manager 1.0 在以下 SQL Server 数据库中存储其数据。

数据库名称	说明
WFManagementDB	Workflow Manager 场管理数据库
SbManagementDB	Service Bus 场管理数据库
WFResourceManagementDB	Workflow Manager 资源管理存储
WFInstanceManagementDB	Workflow Manager 实例管理存储
SbGatewayDatabase	Service Bus 网关数据库
SBMessageContainer01 - n	Service Bus 消息容器数据库

关于数据层，有三个重要任务与灾难恢复相关联：

1. 准备 - 确保为数据库制定正确的备份/复制策略，以免在发生与数据库相关的灾难时丢失数据。

   你必须为灾难做好准备，这样才能从灾难状况中恢复。 具体而言，为了从涉及数据库丢失的灾难中恢复，你必须设法将数据的副本存储在其他位置。 由于这些数据库是标准 SQL 数据库，因此建议使用确定的 SQL 技术，如：

   1. SQL 镜像

   2. SQL 复制

   3. 简单备份以及备份和日志传送相结合

   你可以根据业务性质以及备份与主数据库之间所需的数据保真度，选择这些技术中的任一种。

   事实上，作为 Workflow Manager 场的管理员，你应该根据需要使用相应的备份策略创建这些数据库的备份。Workflow Manager 不提供任何帮助创建这些备份数据库的功能。

2. 还原备份数据库

   根据你的数据复制策略，你必须使用相应的还原工具/机制来还原备份数据库。 你可以使用行业标准 SQL 工具和技术来还原你的 SQL 数据库。

3. 还原 Workflow Manager 场

   此步骤是指确保将 Workflow Manager 场还原到一致状态并使其可以正常工作这样一个过程。Workflow Manager 为执行此步骤提供了必要的 PowerShell 脚本和指南。

计算层（工作流/消息层）

你可以在备用位置创建一个可在灾难恢复方案中提供帮助的辅助场。 你可以在灾难发生之前或之后创建辅助场。 有三种模式可以考虑。

1. 冷备份

   在此模式中，可以在灾难发生后重新创建场。 这会影响恢复场所需的时间，因为你需要设置新的计算节点并在这些节点上重新安装 Workflow Manager。

2. 热备份

   若要确保在灾难发生之前创建并测试辅助场，通常可选择此模式。 在此模式中，在灾难发生之前就在新场中设置计算节点。 在建立数据库配对关系后，将此新场指向辅助数据库。

   设置此新场之后，即可关闭计算节点，避免其空运转。 在灾难恢复过程中，你必须运行 Workflow Manager 提供的数据库一致性脚本。

   注意
   此模式假定在进行初始安装后未在主架构中创建新的 Service Bus 容器数据库。 如果在主架构中创建了新的 Service Bus 容器数据库，则在恢复期间必须执行附加的步骤。

3. 过热备份

   这是对热备份的改进，其中计算节点可以处于打开状态。 这将减少从灾难中恢复所需的时间。

   警告
   Workflow Manager 不支持过热备份。

灾难恢复过程

本部分介绍用于上述各种灾难方案的实际灾难恢复过程。 在高级别上，建议的过程是从备份（使用任何标准的 SQL Server 技术创建的备份）还原所需的数据库，并使用由 Workflow Manager 提供的还原 cmdlet 来还原场。

注意
以下步骤介绍了丢弃以前的场管理数据库并重新创建它们的过程。

运行还原命令的过程

1. 同时导出带私钥的 ServiceBus 场证书和带私钥的 Service Bus 加密证书。 将这两个证书导入到新服务器的“本地计算机\个人”文件夹中。 此外将根证书导入到新服务器的“本地计算机\受信任根证书颁发机构”文件夹中。 你可以根据 Get-SBFarm 输出标识场证书和加密证书。

   注意

   仅当旧 WFM/SB 服务器中的旧 ServiceBus 加密证书满足以下条件，导入才适用： 是在旧场配置期间由配置工具自动生成的。 或者，在你已对旧环境中的 ServiceBus 使用自定义证书的情况下，该证书需要成为你所在域的通配符证书，即证书中的“使用者可选名称”字段是使用类似“*.mydomainname.com”的值创建的。 如果未执行旧 ServiceBus 证书导入，则在以下步骤中 Restore-WFFarm cmdlet 将失败并显示如下错误。 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. 在新的计算机上打开提升的 PowerShell（RunAs 管理员）窗口。

3. 调用 Restore-SBFarm cmdlet 并传递以下参数。 此 cmdlet 将创建新的 Service Bus 场管理数据库。 然后，你可以删除旧的 Service Bus 场管理数据库。

   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>]
   

   注意
   如果你已在旧 ServiceBus 配置中使用自定义通配符证书并且已将两个不同的证书用作 FarmCertificate 和 EncryptionCertificate，则必须在每个新节点上导入这两个证书，并在上面的 cmdlet 中相应地提供 FarmCertificateThumbprint 和 EncryptionCertificateThumbprint 参数。

   以下代码片断显示调用 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. 使用以下参数对其中一个场节点调用 Restore-SBGateway cmdlet。

   Parameter	说明
   SBFarmDBConnectionString	在上一步中创建的 Service Bus 场数据库的连接字符串。
   GatewayDBConnectionString	已还原网关数据库的连接字符串。

   以下代码片断显示调用 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. 对于每个容器数据库，使用以下参数调用 Restore-SBMessageContainer cmdlet。 在其中一个场计算机上运行此 cmdlet。

   Parameter	说明
   SBFarmDBConnectionString	在上一步中创建的 Service Bus 场数据库的连接字符串。
   ContainerDBConnectionString	容器数据库的连接字符串。
   Id	还原的消息容器的 ID。 可从网关数据库的 [dbo].[ContainersTable] 表获得还原的消息容器的 ID，该表包含所有消息容器的 ID、连接字符串、数据库服务器名称和数据库名称。 选择其数据库名称与原始容器数据库名称匹配的容器的 ID。

   以下代码片断是调用 Restore-SBMessageContainer cmdlet 的示例。

   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. 调用 Add-SBHost cmdlet 并传递以下参数。

   Parameter	说明
   SBFarmDBConnectionString	在上一步中创建的 Service Bus 场数据库的连接字符串。
   CertificateAutoGenerationKey	这是用于自动生成 SB 证书的密钥
   RunAsPassword	SecureString，包含在其下运行 Service Bus 进程的帐户的密码。
   EnableFirewallRules	如果主机的防火墙规则应更新为允许 Service Bus 数据通过防火墙，则为 true； 否则为 False。

   以下示例演示如何调用该 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. 使用 ResourceManagement 和 Instance Database 连接字符串调用 Restore-WFFarm cmdlet。

   以下示例演示如何调用该 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
   

   注意
   InstanceStateSyncTime 必须遵循前面示例中指定的确切格式。 ConsistencyVerifierLogPath 应为允许 cmdlet 在其中写入还原过程相关日志的文件夹的路径。

8. 调用 Add-wfhost cmdlet。

   以下示例演示如何调用该 cmdlet。

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

方案 1 - 灾难影响整个群集

在此方案中，整个群集因灾难而受到影响。 若要从此灾难方案中恢复，整个群集必须使用最新的数据库备份进行重建。

1. 在新计算机上安装 Workflow Manager 1.0。

   注意
   使用安装程序安装 Workflow Manager 1.0，但不开始配置场

2. 使用 SQL Server 还原功能还原已备份的主数据库。 此步骤因所选的备份解决方案而异。

   应只还原以下数据库：

   • WFResourceManagementDB

   • WFInstanceManagementDB

   • SbGatewayDatabase

   • SBMessageContainer*

   重要事项
   不要还原 WFManagementDB 和 SbManagementDb 数据库，因为它们将在执行还原操作的过程中被重新创建。

3. 请按照 运行还原命令的过程 中所述步骤操作。

方案 2 - 灾难仅影响 SQL Server 数据库

在这种情况下，由 Workflow Manager 使用的一个或多个数据库将丢失或无法访问。 这可能是由硬件故障或任何局限于 SQL Server 的其他灾难导致的。

注意
若要从一个数据中心迁移到另一个数据中心，也可以遵循此方案中的步骤，方法是：将数据库的最新备份传输到新的数据中心，然后使用本部分所述过程。

1. 从现有应用程序服务器节点之一卸载 Workflow Manager 1.0。

2. 在上一步提到的服务器上重新安装 Workflow Manager 1.0。

   注意
   使用安装程序安装 Workflow Manager，但不开始配置场

3. 使用 SQL Server 还原功能还原已备份的主数据库。 此步骤因所选的备份解决方案而异。 你可以根据灾难的性质，还原到现有 SQL Server 或其他 SQL Server。

4. 请按照 运行还原命令的过程 中所述步骤操作。

完成这些步骤后，你将有一个场带有一个使用现有数据库的节点。 该场已使用原始数据库的备份副本进行还原，并且已进入能够完全正常工作的稳定状态。

对于属于主场的每个节点，请执行以下步骤。

1. 卸载 Workflow Manager 1.0。

2. 重新安装 Workflow Manager 1.0。

3. 如 运行还原命令的过程 中所述，运行 Add-sbhost 和 Add-wfhost cmdlet。

方案 3 - 灾难仅影响应用程序服务器

有时候，可能会出现应用程序服务器因局部灾难而崩溃或丢失，而数据库服务器却完好的情况。 发生这种灾难时很容易恢复，虽然数据中心很少发生这种情况。 由于没有丢失数据库，因此你想要在主位置继续，同时将新节点添加到这个现有的场。 如果你愿意移动到备用位置，不管出于何种原因，你都可以在执行恢复步骤时将数据库复制到备用位置并引用新数据库。

若要从应用程序服务器灾难情况中恢复，请执行以下步骤。

1. 在新计算机上安装 Workflow Manager 1.0。

2. 删除以下数据库：

   • WFManagementDB

   • SbManagementDB

3. 按照运行还原命令的过程中所述过程操作。

   注意
   如果你移动了数据库，请在执行这些步骤时引用新数据库，否则请引用原始数据库。

完成这些步骤后，你将有一个场带有一个使用现有（或已移动）数据库的节点。 你可以根据需要将其他节点添加到该场，其方式与将更多节点添加到 Workflow Manager 场的方式相同。

范围还原

可能会有这样的情况：你意外地删除了某个特定范围或者特定范围的内容已损坏。 不过，你还有在该范围的内容处于良好状态时 Workflow Manager 数据库的备份。 你可能想要从现有备份副本中只还原该范围的内容。

还原范围时，将还原以下内容。

• 范围和子范围以及它们的配置

• 所还原的范围层次结构内的活动

• 该范围层次结构内的工作流及其配置

• 该范围层次结构内的工作流实例

  • 实例将从其最后一个暂留点继续执行。

• 与这些实例对应的跟踪记录。

• 该范围层次结构内工作流的任何未传递消息

注意
删除某个范围时，该范围的所有内容（包括实例和跟踪记录）将在几分钟内清理完毕（该处理是异步的）。

下表介绍了范围还原操作中使用的主要术语。

项	说明
备份数据库	假定你已经创建由 Workflow Manager 使用的所有数据库的备份，并且你计划还原的范围也在此备份副本中提供。 换句话说，此数据库将充当用于复制该范围内容的源数据库。
实时数据库	此术语是指 Workflow Manager 场中当前处于活动状态的数据库。 换句话说，这是范围还原过程的目标数据库。
要还原的范围。	你可以在范围层次结构内指定要从备份数据库还原的任何范围。

Workflow Manager 为你提供了启用此方案的功能。 以下是完成范围还原时必须执行的步骤。

• 范围还原过程

• 范围还原注意事项

范围还原过程

你想要还原的范围不应存在于实时数据库中。 因此，如果因实时数据库包含某个范围的受损副本，你要从备份还原该范围，则必须从实时数据库中删除该受损范围。

1. 还原 SQL 数据库：第一步是使用 Restore a Database Backup (SQL Server Management Studio)（存储数据库备份 (SQL Server Management Studio)）中描述的备份还原 SQL 数据库。

   重要事项
   必须将备份数据库还原到其他服务器。 不要覆盖实时数据库。

2. 通过传递以下参数来运行 Restore-WFScope PowerShell 命令，

   • 要还原的范围的路径

   • 备份资源数据库的连接字符串

   • 备份实例数据库的连接字符串

   • 提供创建备份的时间 – 这可以是一个粗略的近似值。 如果在不同的时间点对数据库进行了备份，则请确保从这些时间戳中选择最早的作为此步骤的输入。

   • 网关数据库的连接字符串

   • 一个或多个容器数据库的连接字符串。 通常情况下，你只有一个容器数据库。 如果你的服务器有多个容器数据库，请确保将所有这些连接字符串都提供给此 cmdlet。

   此时，范围和内容会在实时数据库中还原，新还原的备份数据库则可删除。

范围还原注意事项

当“范围还原”从备份和还原的数据库还原范围时，你应注意整体还原过程的以下几点。

• 只能从当前的实时数据库的以前备份副本还原范围。 换句话说，你不能尝试将某个特定范围从一个 Workflow Manager 场移到另一个场。

• “范围还原”只还原属于某个范围及其所有子级的内容。 它不还原该范围的子层次结构之外的任何内容。

• 如果某项活动或某个工作流引用的是此范围层次结构之外的其他活动（假设被引用的活动处于要还原的范围上面的父范围中），则不会在执行此操作过程中还原被引用的活动。 这意味着此类工作流将无效，任何创建此类工作流实例的尝试都将导致错误。