通过

对 SharePoint Server 和 Access Services 执行灾难恢复的最佳做法

适用于：yes-img-132013 yes-img-162016 yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint in Microsoft 365

本文介绍如何为 SharePoint Server 的 Access Services 服务应用程序成功实现灾难恢复 (DR) 策略。

特别感谢 Microsoft 高级项目经理 Neil Hodgkinson，是他测试了此灾难恢复策略并为本文提供参考内容的。

Access Services 和灾难恢复概述

根据 Access Services 简介 的介绍，SharePoint 2010 引入了 Access Services 概念作为集成服务应用程序。 数据保留在 SharePoint 列表中，可以通过浏览器或 Microsoft Access 2010 客户端访问。 在 SharePoint 2013 中，Access Services 体系结构发生了变化，引入了包含的数据库这一概念，将数据从 SharePoint 列表移入 SQL Server 2012 应用数据库。 在 SharePoint Server 2016 版本中，此体系结构保持不变。

为 SharePoint Server 场配置灾难恢复的方法有多种。 具体选择哪一种方法则完全视组织对允许的数据丢失和最短故障时间的要求而定。 Microsoft 已在选择 SharePoint Server 的灾难恢复策略中记录了各种方法。

无论你选择哪种技术，都请遵循多项与配置灾难恢复场以支持 Access Services 相关的要求和最佳做法。 下文对此进行了详细介绍。

重要

请先确认自己是否符合权限中的所有要求，然后才能使用下面步骤中详述的任意 Microsoft PowerShell cmdlet。

第 1 步：为 SharePoint 服务器设置灾难恢复

这一步的目标是通过修复潜在故障点，提供更为顺畅的灾难恢复体验。 通过匹配身份验证领域和数据库服务器参考ID，使它们在灾难恢复场中与主场中相同，你将为恢复做好准备。 同样，必须知道必须管理哪些数据库才能成功恢复。

现在，我们来深入了解这几点。

a. 使用相同的身份验证领域

设置新的身份验证领域会阻止所有使用访问令牌的 SharePoint 应用进行访问。 Access Services 应用程序依赖于应用基础结构。 因此，灾难恢复场最好使用与主场相同的身份验证领域。 在部署灾难恢复场时，应将身份验证领域设置作为一项初始安装步骤执行。

若要获取主场的身份验证领域，请使用以下 PowerShell 命令：

 Get-SPAuthenticationRealm

示例： 示例身份验证领域为 GUID，因此返回的值可能如下所示：4a2cc8f8-51ab-4367-8a76-ab629c882a68。

以此 GUID 为例，使用下面这些 PowerShell 命令在辅助场上对它进行设置：

Set-SPAuthenticationRealm -Realm 4a2cc8f8-51ab-4367-8a76-ab629c882a68
Restart-Service sptimerv4
Restart-Service spadminv4

重要

[!重要说明] 建议在更改身份验证领域后重启 SharePoint 定时服务和 SharePoint 管理服务。 可能需要安排时间来执行 IISReset（在 IISReset 成功结束前，SharePoint 站点将无法使用）。

b. 使用相同的数据库服务器引用 ID

SharePoint Server 2013 中的 Access Services 和 SharePoint Server 2016 使用 SQL Server 来托管各个支持基于 Access 的应用的数据库。 在内部，这些数据库服务器不是按名称引用，而是按 ReferenceID 引用。

重要

[!重要说明] 使用与主服务器完全相同的 ReferenceID ，将辅助数据中心内的数据库服务器注册为应用程序服务器主机，对于成功应用灾难恢复策略来说至关重要。 > 这只能通过使用 PowerShell 注册数据库服务器来完成。

注册主场的 Access Services 数据库服务器

$serverGroupName = 'DEFAULT'
$ASapp = Get-SPAccessServicesApplication
$app = $Null
if ($ASapp.length -ne $Null) { $app = $ASapp[0] } else { $app = $ASapp }
$context = [Microsoft.SharePoint.SPServiceContext]::GetContext($app.ServiceApplicationProxyGroup, [Microsoft.SharePoint.SPSiteSubscriptionIdentifier]::Default)
$ServerRefID = [System.Guid]::NewGuid().toString()
$newdbserver = New-SPAccessServicesDatabaseServer -ServiceContext $context -DatabaseServerName "<PrimaryDatabaseServerName>" -DatabaseServerGroup $serverGroupName -ServerReferenceId $ServerRefID -AvailableForCreate $true

将 ServerRefID 写入屏幕，以便在注册辅助场 Access Services 数据库服务器时使用。

 $ServerRefID

注册辅助场的 Access Services 数据库服务器

$serverGroupName = 'DEFAULT'
$DatabaseServerName = "<Secondary Access Database Server>"
$PrimaryServerRefID = "<Primary Server Reference ID>"
$ASapp = Get-SPAccessServicesApplication
$app = $Null
if ($ASapp.length -ne $Null) { $app = $ASapp[0] } else { $app = $ASapp }
$context = [Microsoft.SharePoint.SPServiceContext]::GetContext($app.ServiceApplicationProxyGroup, [Microsoft.SharePoint.SPSiteSubscriptionIdentifier]::Default)
$newdbserver = New-SPAccessServicesDatabaseServer -ServiceContext $context -DatabaseServerName $DatabaseServerName  -DatabaseServerGroup $serverGroupName -ServerReferenceId $PrimaryServerRefID -AvailableForCreate $true

可以根据需要引用任意数量的 Access Services 应用数据库服务器。 在此简单示例中，我们只引用了一个。 如果你引用了多个服务器，请务必跟踪注册情况，并确保在恢复时数据库正常恢复为灾难恢复站点中的匹配服务器。

c. 了解支持 Access Services 服务应用程序的数据库

SharePoint Server 中的 Access Services 与自己的服务应用程序数据库相比，它与 SharePoint 场中的多个数据库有着紧密的依赖关系。

必须在灾难恢复策略中管理这些数据库。

数据库 说明
应用程序管理数据库
 包含 Access 应用注册情况和应用主体。
订阅设置数据库
 管理提供给 Access 应用的唯一标识，创建 Access 应用程序的 URL。
安全存储数据库
 安全存储服务可用于为 Access 应用提供备用身份验证方法。 前面提到的指南不介绍如何执行此操作，但我们会将安全存储数据库添加到我们的策略中，以确保完整性。
SharePoint 内容数据库
 这些数据库包含其中已部署 Access 应用的网站集。
Access Services 应用数据库
 此类数据库包含需要保留的实际数据，以确保 Access Services 应用程序正常运行。

具体选择哪一种灾难恢复方法视以下因素而定：恢复时间目标 (RTO) 和恢复点目标 (RPO)、可以处于脱机状态的时间，以及在灾难发生时你可以承受的数据丢失量。 无论你如何选择，Access Services 的恢复过程保持不变。

第 2 步：在执行故障转移后进行恢复

在将故障转移到辅助数据中心后，你需要使用第 1 步中列出的五个不同数据库，在灾难恢复场上重新生成 Access Services 应用基础结构。

注意

本文仅介绍上表中列出的五种数据库类型。 若要在数据中心故障转移后成功恢复完整的 SharePoint Server 场，需要执行其他步骤，并指示读者查看 规划 SharePoint Server 的高可用性和灾难恢复中的步骤。

对于本文中讨论的测试环境，以下数据库从主 SQL Server SQL01 恢复到 DR 站点中的辅助 SQL Server SQL02。

  • 应用程序管理数据库

  • 订阅设置数据库

  • 安全存储数据库

  • SharePoint 内容数据库

  • Access Services 应用数据库

我们可以利用本文介绍的技术，恢复这些服务应用程序并附加内容数据库。

a. 从还原/恢复的数据库重新创建服务应用程序

使用下列 PowerShell 命令：

  1. 应用程序管理数据库和代理：
$AppPool = Get-SPServiceApplicationPool -Identity "<Services Application Pool Name> "
$AppDatabasename = "<restored App Management database name>"
$appman = New-SPAppManagementServiceApplication -Name "App Management" -DatabaseServer "<SecondaryDatabaseServerName>" -DatabaseName $AppDatabaseName -ApplicationPool $AppPool 
$appmanproxy = New-SPAppManagementServiceApplicationProxy -Name "App Management Proxy" -ServiceApplication $appman
  1. 订阅设置数据库和代理：
 $SubDatabasename = "<restored Subscription Settings database name>"
$subset = New-SPSubscriptionSettingsServiceApplication -Name "Subscription Settings" -DatabaseServer "<SecondaryDatabaseServerName>" -DatabaseName $SubDatabaseName -ApplicationPool $AppPool
$subsetproxy = New-SPSubscriptionSettingsServiceApplicationProxy -Name "Sub Settings Proxy" -ServiceApplication $subset
  1. 安全存储数据库和代理：
$SecDatabasename = "<restored Secure Store database name>"
$secstore = New-SPSecureStoreServiceApplication -DatabaseServer "<SecondaryDatabaseServerName>" -DatabaseName $SecDatabaseName -ApplicationPool $AppPool
$secstoreproxy = New-SPSecureStoreServiceApplicationProxy -Name "Secure Store Proxy" -ServiceApplication $secstore

另请注意，如果在辅助场中使用安全存储，则需要先生成新的安全存储加密密钥，然后才能利用其中注册的任何应用程序。

b. 附加内容数据库 ()

使用 PowerShell 在灾难恢复场上将故障转移内容数据库装载到适当的 Web 应用程序中：

请先确认自己是否符合权限中的所有要求，然后才能使用任意 Microsoft PowerShell cmdlet。

 Mount-SPContentDatabase -WebApplication "<http://DRWebApp>"  -Name "<Database name>" -DatabaseServer "<SecondaryDatabaseServerName>"

c. 恢复 Access Services 应用数据库

同样，与其他数据库一样，具体选择哪一种技术视 RTO 和 RPO 而定。 不过，若要执行恢复，只需将数据库还原或恢复为已使用主数据库服务器的 ServerReferenceID 在 Access Services 中正确注册的辅助服务器。 配置混合 OneDrive 中对此进行了详细介绍。

第 3 步：执行故障转移后的配置操作

此时，我们已几乎满足所有的 Access Services 灾难恢复条件。 我们需要执行的最后两个任务是：

  • 设置应用域 URL

  • 请确保 Access Services 应用数据库登录已从主站点转移到辅助站点中。

a. 在辅助站点中设置应用域

此处要考虑的关键元素是在主站点中指定的域，以及打算在辅助 DR 站点中使用的域。 如果计划使用相同的域，请将 SP Apps 域的 CNAME 记录重新指向辅助 SharePoint 服务器，例如将 *.contosoapps.com 重新指向辅助 SharePoint Server。

请确保在 DR 站点的管理中心中设置应用 URL。

  1. 打开管理中心，选择" 应用"。

  2. 选择" 配置应用 URL"。

恢复应用管理数据库不会保留应用域，即使它确实保留了应用前缀。

重要

如果未设置应用域，则会导致 DNS 查找失败以及浏览器中出现与找不到站点相关的错误。

b. 为辅助站点设置 Access 数据库登录名

Access Services 需要 SQL Server 的包含数据库功能，该功能支持包含的数据库登录名。 但是，SharePoint 2013 和 2016 中的 Access Services 仅部分使用此功能，因此数据库登录名与任何其他登录名一样存储在 Master DB 中。 这样做的缺点是，在故障转移时，我们需要重新生成任何缺失的登录名，并确保为帐户设置相同的密码。

幸运的是，Microsoft 在如何在 SQL Server 实例之间传输登录和密码中介绍了一种简便方法（我们将在下面的第 1 步中参阅这篇文章）。

此流程包括三个关键步骤：

  1. 使用如何在 SQL Server 实例之间传输登录和密码中的脚本，在主 Access Services 数据库服务器 Master 数据库中生成两个新的存储过程。

  2. 执行存储过程，生成可以复制到目标辅助服务器的 TSQL 脚本，例如：

Login: db_ _dbo
CREATE LOGIN [db_63eb8501_29b0_401a_becd_9931ae72ea3d _dbo] WITH PASSWORD = *********** HASHED, SID = 0x0C3431F92F162D4EA913E07E1DAB3979 , DEFAULT_DATABASE = [master], CHECK_POLICY = OFF, CHECK_EXPIRATION = OFF — Login: db_63eb8501_29b0_401a_becd_9931ae72ea3d_custom
CREATE LOGIN [db_63eb8501_29b0_401a_becd_9931ae72ea3d_custom] WITH PASSWORD = ***********  HASHED, SID = 0x8B68A3A203D6D14E88F13B504420BD7E, DEFAULT_DATABASE = [master], CHECK_POLICY = OFF, CHECK_EXPIRATION = OFF
  1. 在目标辅助数据库服务器上执行 TSQL 以生成登录。

完成这些操作后，辅助灾难恢复场将能够在故障转移后从主服务器场呈现 Access Services 应用。

摘要

已在使用 SQL Server 2012 的灾难恢复案例中将 SharePoint Server 2013 作为 Access 应用数据库服务器平台进行了测试。

已在使用 SQL Server 2016 的灾难恢复案例中将 SharePoint Server 2016 作为 Access 应用数据库服务器平台进行了测试。

在遵循本文档中的指导执行操作后，我们始终能够在辅助 SharePoint 场上成功恢复 Access 应用程序，并能成功执行所有故障转移后 CRUD 操作。

关键元素是：确保两个服务器场都设置了匹配的身份验证领域。 务必使用相同的 ServerReferenceID 引用 Access Services 数据库服务器。 将 SQL 登录从生产转移到灾难恢复 SQL 服务器。

另请参阅