摘要：?使用 Azure，你可以為內部部署 SharePoint 服務器場創建災難恢復環境。本文介紹如何設計和實施此解決方案。

觀看 SharePoint Server 2013 災難恢復概述視頻

?

當災難襲擊你的 SharePoint 內部部署環境時，頭等大事是迅速使系統恢復運行。如果你已有備份環境在 Microsoft Azure 中運行，SharePoint 災難恢復將更加快速、輕松。本視頻介紹 SharePoint 溫故障轉移環境的主要概念，并補充了本文中提供的完整詳細信息。

將本文與以下解決方案模型結合使用：?Microsoft Azure 中的 SharePoint 災難恢復?。

PDF?|?Visio

使用 Azure 基礎結構服務進行災難恢復

很多組織沒有 SharePoint 的災難恢復環境，因為在內部構建和維護此環境非常昂貴。Azure 基礎結構服務提供了災難恢復環境極具吸引力的選項，這些選項更加靈活且成本比內部部署方案要低。

使用 Azure 基礎結構服務的優點如下：

• 資源成本更低?維護和支付比內部部署災難恢復環境更少的資源。資源數量取決于你選擇的災難恢復環境：冷備用、溫備用或熱備用。

• 資源靈活性更高?如果發生災難，輕松擴展恢復 SharePoint 服務器場以滿足負載要求。當你不再需要這些資源時，進行縮放。

• 數據中心承諾更低?使用 Azure 基礎結構服務，而不是在其他地區投資建設輔助數據中心。

對于剛剛開始接觸災難恢復的組織，提供不太復雜的選項；對于具有高彈性要求的組織，則提供一些高級選項。當環境承載在云平臺上時，冷備用、溫備用和熱備用環境的定義略有不同。下表介紹了在 Azure 中構建 SharePoint 恢復場的環境。

表：恢復環境

恢復環境的類型說明

熱備用?	設置并更新一個完全大小的服務器場，且以備用狀態運行。?
溫備用?	已構建服務器場，虛擬機正在運行并且已更新。? 恢復包括附加內容數據庫、設置服務應用程序和爬網內容。? 服務器場可以是生產服務器場的較小版本，它可以向外擴展以便為整個用戶群提供服務。?
冷備用?	服務器場已完全構建，但虛擬機已停止。? 維護環境包括偶爾啟動虛擬機，以及修補、更新和驗證環境。? 啟動完整環境發生災難時。?

請務必評估你的組織的恢復時間目標 (RTO) 和恢復點目標 (RPO)。這些要求確定了哪個環境是最適合貴組織的投資。

本文中的指南介紹如何實現溫備用環境。你也可以對其進行調整使其適合冷備用環境，盡管你需要執行一些其他步驟才能支持此類環境。本文不會介紹如何實現熱備用環境。

有關災難恢復解決方案的詳細信息，請參閱?High availability and disaster recovery concepts in SharePoint 2013和Choose a disaster recovery strategy for SharePoint 2013。

解決方案描述

溫備用災難恢復解決方案需要以下環境：

• 內部部署 SharePoint 生產服務器場

• Azure 中的恢復 SharePoint 服務器場

• 兩個環境之間的站點到站點 VPN 連接

下圖說明了這三個元素。

圖：Azure 中溫備用解決方案的元素

SQL Server 日志傳送與分布式文件系統復制 (DFSR) 用于將數據庫備份和事務日志復制到 Azure 中的恢復場：

• DFSR 將日志從生產環境傳輸到恢復環境。在 WAN 方案中，DFSR 比將日志直接傳輸到 Azure 中的輔助服務器更有效。

• 日志將重播到 Azure 恢復環境中的 SQL Server。

• 你不會在恢復環境中附加日志傳送的 SharePoint 內容數據庫，除非執行恢復操作。

執行下列步驟，恢復服務器場：

停止日志傳送。

停止接受到主服務器場通信。

重播最后的事務日志。

將內容數據庫附加到服務器場。

從復制的服務數據庫中還原服務應用程序。

將域名系統 (DNS) 記錄更新為指向恢復場。

啟動完全爬網。

我們建議你定期演練這些步驟并進行記錄，以確保在線恢復順利運行。附加內容數據庫和恢復服務應用程序可能需要一些時間，并且通常涉及一些手動配置。

執行恢復后，此解決方案將提供下表中列出的項目。

表：解決方案恢復目標

項說明

網站和內容?	網站和內容在恢復環境中可用。?
新的搜索實例?	在此溫備用解決方案中，不會從搜索數據庫還原搜索。恢復場中的搜索組件盡可能配置得與生產服務器場類似。網站和內容還原后，會啟動完全爬網以重建搜索索引。你不需要等待爬網完成，即可使網站和內容可用。?
服務?	將數據存儲在數據庫中的服務從日志傳送的數據庫還原。不在數據庫中存儲數據的服務則直接啟動。? 并非數據庫的所有服務都需要還原。下列服務不需要從數據庫還原，在故障轉移后可以直接啟動：? Usage and Health Data Collection? State service? Word Automation? 任何其他不使用數據庫的服務?

你可以與 Microsoft 咨詢服務 (MCS) 或合作伙伴合作以實現更復雜的恢復目標。下表中匯總了詳細信息。

表：可以由 MCS 或合作伙伴解決的其他項目

項說明

正在同步的自定義場解決方案?	理想情況下，恢復場的配置與生產服務器場相同。你可以與顧問或合作伙伴合作，評估是否復制了自定義服務器場解決方案，以及是否制定了將兩個環境保持同步的流程。?
到內部部署數據源的連接?	將連接復制到后端數據系統可能并不實用，例如備份域控制器 (BDC) 連接和搜索內容源。?
搜索還原方案?	由于企業搜索部署通常非常獨特且復雜，從數據庫還原搜索需要更大的投資。你可以與顧問或合作伙伴合作，以確定并實施貴組織可能需要的搜索還原方案。?

本文中提供的指南假定已設計和部署內部部署服務器場。

詳細體系結構

理想情況下，Azure 中的恢復服務器場配置與內部部署服務器場相同，其中包括以下內容：

• 服務器角色的表示形式相同

• 自定義配置相同

• 搜索組件的配置相同

Azure 中的環境可以是生產服務器場的較小版本。如果你計劃在故障轉移后向外擴展恢復場，必須對每種類型的服務器進行初始表示。

某些配置可能無法在故障轉移環境中復制。請務必測試故障轉移過程和環境，確保故障轉移服務器場提供預期的服務級別。

此解決方案不會規定 SharePoint 服務器場的特定拓撲。此解決方案的焦點是將 Azure 用于故障轉移服務器場，并在兩個環境之間實施日志傳送和 DFSR。

溫備用環境

在溫備用環境中，Azure 環境中的所有虛擬機均正常運行。環境已準備就緒，可用于故障轉移練習或事件。

下圖說明了從內部部署 SharePoint 服務器場到基于 Azure 的 SharePoint 服務器場（配置為溫備用環境）的災難恢復解決方案。

圖：生產場和溫備用狀態恢復場的拓撲和主要元素

在此圖中：

• 兩個環境并排顯示：內部部署 SharePoint 服務器場和 Azure 中的溫備用服務器場。

• 每個環境包含一個文件共享。

• 每個服務器場包含四層。為實現高可用性，每一層包含兩臺服務器或為特定角色配置得相同的虛擬機，如前端服務、分布式緩存、后端服務和數據庫。在此圖中，調用特定的組件并不重要。兩個服務器場的配置相同。

• 第四層是數據庫層。日志傳送用于將日志從本地環境中的輔助數據庫服務器復制到同一環境中的文件共享。

• DFSR 將本地環境中的文件共享復制到 Azure 環境中的文件共享

• 日志傳送將日志從 Azure 環境中的文件共享中繼到恢復環境中 SQL Server AlwaysOn 可用性組的主副本。

冷備用環境

在冷備用環境中，大部分 SharePoint 服務器場虛擬機都可以關閉。（建議有時啟動虛擬機，例如每兩周或一次或一個月一次，以便每個虛擬機可與域同步。）Azure 恢復環境中的下列虛擬機必須保持運行狀態，以確保日志傳送和 DFSR 持續運行：

• 文件共享

• 主數據庫服務器

• 至少一個運行 Windows Server Active Directory 域服務和 DNS 的虛擬機

下圖顯示了文件共享虛擬機和主 SharePoint 數據庫虛擬機正在運行的 Azure 故障轉移環境。所有其他 SharePoint 虛擬機都已停止。運行 Windows Server Active Directory 和 DNS 的虛擬機不會顯示。

圖：包含運行的虛擬機的冷備用恢復場

故障轉移到冷備用環境之后，所有虛擬機都將啟動，必須配置實現數據庫服務器高可用性的方法，例如 SQL Server AlwaysOn 可用性組。

如果實施了多個存儲組（數據庫分布在多個 SQL Server 高可用性集之間），則每個存儲組的主數據庫都必須處于運行狀態以接受與其存儲組關聯的日志。

技能和經驗

此災難恢復解決方案中使用了多種技術。要確保這些技術按預期交互，內部部署和 Azure 環境中的每個組件都必須正確安裝和配置。我們建議設置此解決方案的用戶或團隊具有下列文章中所述技術的豐富工作知識和動手技能：

• 分布式文件系統 (DFS) 復制服務

• Windows Server 故障轉移群集 (WSFC) 與 SQL Server

• AlwaysOn 可用性組 (SQL Server)

• SQL Server 數據庫的備份和還原

• SharePoint Server 2013 安裝和服務器場部署

• Microsoft Azure

最后，我們建議使用腳本編程技能，你可以用于將與這些技術相關的任務自動化。可以使用可用的用戶界面完成此解決方案中所述的所有任務。但是，手動方法可能非常耗時且容易出現錯誤，并會交付不一致的結果。

除了 Windows PowerShell 之外，還有用于 SQL Server、SharePoint Server 和 Azure 的 Windows PowerShell 庫。不要忘記 T-SQL，它還可以幫助減少配置和維護災難恢復環境所需的時間。

災難恢復路線圖

此路線圖假定你已經在生產中部署了 SharePoint Server 2013 服務器場。

表：災難恢復路線圖

階段說明

階段 1?	設計災難恢復環境。?
階段 2?	創建 Azure 虛擬網絡和 VPN 連接。?
階段 3?	將 Windows Active Directory 和域名服務部署到 Azure 虛擬網絡。?
階段 4?	將 SharePoint 恢復場部署到 Azure 中。?
階段 5?	設置場之間的 DFSR。?
階段 6?	設置到恢復場的日志傳送。?
階段 7?	驗證故障轉移和恢復解決方案，其中包括以下過程和技術：? 停止日志傳送。? 將備份還原。? 對內容爬網。? 恢復服務。? 管理 DNS 記錄。?

階段 1：設計災難恢復環境

使用?SharePoint 2013 的 Microsoft Azure 體系結構中的指導設計災難恢復環境，包括 SharePoint 恢復場。?您可以使用 Azure Visio 文件中的 SharePoint 災難恢復解決方案中的圖形來啟動設計過程。?我們建議你先設計整個環境，然后開始在 Azure 環境中執行任何工作。

除了?SharePoint 2013 的 Microsoft Azure 體系結構中提供的虛擬網絡、VPN 連接、Active Directory 和 SharePoint 服務器場設計指導外，請務必將文件共享角色添加到 Azure 環境。

要在災難恢復解決方案中支持日志傳送，應將文件共享虛擬機添加到數據庫角色駐留的子網。文件共享還充當 SQL Server AlwaysOn 可用性組多數節點的第三個節點。對于使用 SQL Server AlwaysOn 可用性組的標準 SharePoint 服務器場，這是建議配置。

?備注

必須查看使數據庫參與 SQL Server AlwaysOn 可用性組的先決條件。有關詳細信息，請參閱針對 AlwaysOn 可用性組的先決條件、限制和建議。

圖：用于災難恢復解決方案的文件服務器的放置

在此圖中，文件共享虛擬機將添加到 Azure 中包含數據庫服務器角色的相同子網中。請勿將文件共享虛擬機添加到具有其他服務器角色的可用性集，例如 SQL Server 角色。

如果你關注日志的高可用性，請考慮采取其他方法，即使用 Azure Blob 存儲服務進行 SQL Server 備份和還原。這是 Azure 中的新增功能，可將日志直接保存到 Blob 存儲 URL。此解決方案不包括有關使用此功能的指導。

在設計恢復場時，請牢記，成功的災難恢復環境能夠準確反映你想要恢復的生產服務器場。恢復場的大小不是恢復場設計、部署和測試中最重要的因素。恢復場規模因組織而異，具體取決于組織的需求。在出現短暫中斷時，它可能會使用向下伸縮的服務器場，或者直到性能和容量需求要求你擴展服務器場。

將恢復場盡量配置得與生產服務器場相同，以便其滿足服務級別協議 (SLA) 要求并提供支持業務所需的功能。當你設計災難恢復環境時，還需審核生產環境的變更管理過程。我們建議你按與生產環境相同的間隔更新恢復環境，以將變更管理過程擴展到恢復環境。作為變更管理過程的一部分，我們建議你維護一張詳細的服務器場配置、應用程序和用戶清單。

階段 2：創建 Azure 虛擬網絡和 VPN 連接

將本地網絡連接到 Microsoft Azure 虛擬網絡?介紹如何在 Azure 中規劃和部署虛擬網絡以及如何創建 VPN 連接。請按照相應主題中的指導完成下列過程：

• 規劃虛擬網絡的專用 IP 地址空間。

• 規劃虛擬網絡的路由基礎結構更改。

• 規劃發送到本地 VPN 設備以及從本地 VPN 設備發出的流量的防火墻規則。

• 在 Azure 中創建跨部署虛擬網絡。

• 配置本地網絡和虛擬網絡之間的路由。

階段 3：將 Active Directory 和域名服務部署到 Azure 虛擬網絡

此階段包括將 Windows Server Active Directory 和 DNS 部署到混合方案中的 虛擬網絡，如?SharePoint 2013 的 Microsoft Azure 體系結構中所述以及下圖中所示。

圖：混合 Active Directory 域配置

在此圖中，將兩個虛擬機部署到相同的子網中。這兩個虛擬機分別托管兩個角色：Active Directory 和 DNS。

在 Azure 中部署 Active Directory 之前，閱讀在 Azure 虛擬機上部署 Windows Server Active Directory 的指南。這些指南將幫助你確定你的解決方案是否需要不同的體系結構或不同的配置設置。

有關在 Azure 中設置域控制器的詳細指導，請參閱在 Azure 虛擬網絡中安裝副本 Active Directory 域控制器。

在此階段之前，你沒有向虛擬網絡部署虛擬機。用于承載 Active Directory 和 DNS 的虛擬機可能不是你的解決方案需要的最大虛擬機。在部署這些虛擬機之前，首先創建你計劃在虛擬網絡中使用的最大虛擬機。這有助于確保你的解決方案在 Azure 中被標記為允許你需要的最大大小。目前不需要配置此虛擬機。只需進行創建，然后放到一旁。如果不這樣做，你稍后在嘗試創建更大的虛擬機時可能會受到限制，編寫本文時此問題尚未解決。

階段 4：在 Azure 中部署 SharePoint 恢復場

根據你的設計規劃，在 虛擬網絡 中部署 SharePoint 服務器場。在 Azure 中部署 SharePoint 角色之前，查看在 Azure 基礎結構服務上規劃 SharePoint 2013?對你有一定的幫助。

考慮在構建概念證明環境時了解到的以下做法：

• 通過使用 Azure 門戶或 PowerShell 創建虛擬機。

• Azure 和 Hyper-V 不支持動態內存。請確保在你的性能和容量規劃中考慮到了這一點。

• 通過 Azure 界面重新啟動虛擬機，而不是在虛擬機登錄時。使用 Azure 界面會更順利，并且更易于預測。

• 如果你想關閉某個虛擬機以節約成本，請使用 Azure 界面。如果你在虛擬機登錄時關閉，費用仍會累計。

• 使用虛擬機的命名約定。

• 注意虛擬機部署在哪個數據中心位置。

• SharePoint 角色不支持 Azure 中的自動縮放功能。

• 請勿在將要還原的服務器場中配置項目，例如網站集。

階段 5：設置場之間的 DFSR

要使用 DFSR 設置文件復制，請使用 DNS Management 管理單元。但是在 DFSR 設置之前，請登錄到你的內部部署文件服務器和 Azure 文件服務器，并在 Windows 中啟用服務。

從服務器管理器儀表板中，完成以下步驟：

• 配置本地服務器。

• 啟動"添加角色和功能向導"。

• 打開"文件和存儲服務"節點。

• 選擇"DFS 命名空間"和"DFS 復制"。

• 單擊"下一步"完成向導步驟。

下表提供了指向 DFSR 參考文章和博客文章的鏈接。

表：DFSR 的參考文章

標題說明

復制?	DFS 管理 TechNet 主題，包含復制鏈接?
DFS 復制：生存指南?	Wiki，包含 DFS 信息的鏈接?
DFS 復制：常見問題?	DFS 復制 TechNet 主題?
Jose Barreto 的博客?	由 Microsoft 文件服務器團隊首席項目經理撰寫的博客?
Microsoft 存儲團隊 - 文件柜博客?	關于 Windows Server 中的文件服務和存儲功能的博客?

階段 6：設置到恢復場的日志傳送

日志傳送是在此環境中設置災難恢復的關鍵組件。你可以使用日志傳送，將數據庫的事務日志文件從主數據庫服務器實例自動傳送到輔助數據庫服務器實例。要設置日志傳送，請參閱Configure log shipping in SharePoint 2013。

?重要

SharePoint Server 中的日志傳送支持僅限于特定數據庫。有關詳細信息，請參閱?SharePoint 數據庫的受支持的高可用性和災難恢復選項 (SharePoint 2013)。

階段 7：驗證故障轉移和恢復

最后這一階段的目的是驗證災難恢復解決方案按計劃運行。為此，請創建一個故障轉移事件，關閉生產服務器場并啟動恢復場以進行替換。您可以手動或使用腳本啟動故障轉移方案。

第一步是停止對服務器場服務或內容的傳入用戶請求。你可以通過禁用 DNS 條目或關閉前端 Web 服務器來執行此操作。服務器場關閉后，你可以故障轉移到恢復場。

停止日志傳送

你必須在服務器場恢復之前停止日志傳送。首先在 Azure 中的輔助服務器上停止日志傳送，然后在內部部署主服務器上停止日志傳送。使用以下腳本，首先在輔助服務器上，然后在主服務器上停止日志傳送。腳本中的數據庫名稱可能不同，具體取決于你的環境。

復制

-- 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 = @PriDBExec ( '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 + ' )')

將備份還原

備份必須按其創建的順序還原。在還原特定事務日志備份之前，你必須首先在不回滾未提交的事務的情況下，還原下列之前的備份（即，使用?WITH NORECOVERY）：

• 完整的數據庫備份和最新的差異備份 - 還原在執行特定事務日志備份之前創建的備份（如果存在）。在最新的完整或差異數據庫備份創建之前，數據庫使用完整恢復模型或大容量日志恢復模型。

• 所有事務日志備份 - 還原在執行完整數據庫備份或差異備份（如果還原其中一個）之后，執行特定事務日志備份之前創建的備份。日志備份必須按其創建順序應用，日志鏈中沒有任何間隔。

要恢復輔助服務器上的內容數據庫以便由網站呈現，請在恢復之前移除所有數據庫連接。要還原數據庫，請運行以下 SQL 語句。

復制

restore database WSS_Content with recovery

?重要

明確使用 T-SQL 時，在每個 RESTORE 語句中指定?WITH NORECOVERY?或?WITH RECOVERY?以消除歧義這在編寫腳本時非常重要。還原完整和差異備份后，可以在 SQL Server Management Studio 中還原事務日志。此外，由于日志傳送已停止，內容數據庫處于備用狀態，因為你必須將狀態更改為完全訪問。

在 SQL Server Management Studio 中，右鍵單擊“WSS_Content”**** 數據庫，依次指向“任務”**** > “還原”****，再單擊“事務日志”****（如果還沒有還原完整備份，則不可用）。有關詳細信息，請參閱還原事務日志備份 (SQL Server)。

對內容源進行爬網

你必須為每個內容源啟動完整爬網以還原 Search Service。請注意，你會丟失內部部署服務器場的部分分析信息，例如搜索建議。在啟動完整爬網之前，請使用 Windows PowerShell cmdlet?Restore-SPEnterpriseSearchServiceApplication?并指定日志傳送和復制的搜索管理數據庫?Search_Service__DB_。此 cmdlet 將提供搜索配置、架構、托管屬性、規則和源，并創建一組默認的其他組件。

要啟動完全爬網，請完成以下步驟：

在 SharePoint 2013 管理中心中，轉到"應用程序管理">"服務應用程序">"管理服務應用程序"，然后單擊你要爬網的 Search Service 應用程序。

在"搜索管理"頁上，單擊"內容源"，指向你需要的內容源，單擊箭頭，然后單擊"啟動完整爬網"。

恢復服務器場服務

下表顯示如何恢復已對數據庫進行日志傳送的服務、具有數據庫但不建議使用日志傳送進行還原的服務，以及沒有數據庫的服務。

?重要

將內部部署 SharePoint 數據庫還原到 Azure 環境中將不會恢復任何尚未手動安裝在 Azure 中的 SharePoint 服務。

表：服務應用程序數據庫引用

從已進行日志傳送的數據庫還原這些服務這些服務具有數據庫，但我們建議你直接啟動這些服務，無需還原其數據庫這些服務不在數據庫中存儲任何數據；請在故障轉移后啟動這些服務

機器翻譯服務? Managed Metadata Service? Secure Store Service? User Profile。（僅支持配置文件和社交標簽數據庫。不支持同步數據庫。）? Microsoft SharePoint Foundation Subscription Settings Service?	Usage and Health Data Collection? State service? Word Automation?	Excel Services? PerformancePoint Services? PowerPoint 轉換? Visio Graphics Service? 工作管理?

以下示例演示如何從數據庫中還原 Managed Metadata Service。

需使用現有的Managed_Metadata_DB數據庫。此數據庫已進行日志傳送，但輔助服務器場上沒有活動的服務應用程序，因此需要在服務應用程序就位后進行連接。

首先，使用?New-SPMetadataServiceApplication，并使用已還原數據庫的名稱指定?DatabaseName?開關。

接下來，在輔助服務器上配置新的 Managed Metadata Service 應用程序，如下所示：

• 名稱：Managed Metadata Service

• 數據庫服務器：傳送的事務日志中的數據庫名稱

• 數據庫名稱：Managed_Metadata_DB

• 應用程序池：SharePoint 服務應用程序

管理 DNS 記錄

您必須手動創建 DNS 記錄以指向您的 SharePoint 服務器場。

在你具有多個前端 Web 服務器的大多數情況下，利用 Windows Server 2012 中的網絡負載平衡功能或硬件負載平衡器在服務器場中的 Web 前端服務器之間分發請求是明智的。網絡負載平衡還可以在一個 Web 前端服務器出現故障時將請求分發到其他服務器，從而減少風險。

通常情況下，當你設置網絡負載平衡時，將向群集分配單個 IP 地址。然后你在 DNS 提供程序中為指向群集的網絡創建 DNS 主機。（在此項目中，我們將 DNS 服務器放置在 Azure 中，確保在出現內部部署數據中心故障時能夠恢復。）例如，你可以在 DNS 管理器的 Active Directory 中創建指向負載平衡群集的 IP 地址的 DNS 記錄（例如，稱為?https://sharepoint.contoso.com）。

對于 SharePoint 服務器場的外部訪問，可以在外部 DNS 服務器上創建一個主機記錄，該服務器具有客戶端在您的內部網（例如，?https://sharepoint.contoso.com）上使用的、指向防火墻中的外部 IP 地址的相同 URL。?（使用此示例的最佳做法是設置拆分 DNS，以使內部 DNS 服務器對contoso.com?SharePoint 場群集的授權和路由請求，而不是將 DNS 請求路由到外部 DNS 服務器。）然后，可以將外部 IP 地址映射到本地群集的內部 IP 地址，以便客戶端找到他們要查找的資源。

接下來，將介紹幾種不同的災難恢復應用場景：

示例場景：由于內部部署 SharePoint 服務器場中的硬件故障，內部部署 SharePoint 服務器場不可用。?這種情況下，在你完成故障轉移到 Azure SharePoint 服務器場的步驟后，你可以在恢復 SharePoint 服務器場的 Web 前端服務器上配置網絡負載平衡，就像在內部部署服務器場中一樣。然后你可以將內部 DNS 提供程序中的主機記錄重定向為指向恢復場的群集 IP 地址。請注意，可能需要一些時間才會刷新客戶端上的緩存 DNS 記錄并使其指向恢復場。

示例場景：內部部署數據中心會完全中斷。?此場景可能是由于自然災害所致，例如火災或水災。這種情況下，對于企業來說，可能希望有一個輔助數據中心承載在另一個區域，還有具有自己的目錄服務和 DNS 的 Azure 子網。與前一個災難場景中一樣，你可以將內部和外部 DNS 記錄重定向為指向 Azure SharePoint 服務器場。同樣，記下該 DNS 記錄傳播可能需要一些時間。

如果您使用以主機命名的網站集（如在以主機命名的網站集體系結構和部署（SharePoint 2013）中的建議），則您的 SharePoint 服務器場中的同一個 web 應用程序可能會有多個網站集https://sales.contoso.com?，?https://marketing.contoso.com其中包含唯一 DNS 名稱（例如，和）。?在這種情況下，你可以為每個網站集創建指向群集 IP 地址的 DNS 記錄。?請求到達 SharePoint Web 前端服務器之后，它們會將每個請求路由到相應的網站集。

Microsoft 概念證明環境

我們為此解決方案設計了概念證明環境并進行了測試。我們的測試環境的設計目標是部署和恢復已在客戶環境中找到的 SharePoint 服務器場。我們進行了幾種假設，但我們始終牢記，服務器場需提供所有現成功能，而無需進行任何自定義。我們使用現場和產品團隊的最佳實踐指南設計拓撲，確保其高可用性。

下表列出了我們為內部部署測試環境創建和配置的 Hyper-V 虛擬機。

表：用于內部部署測試的虛擬機

服務器名稱。角色配置

DC1?	具有 Active Directory 的域控制器。?	兩個處理器? 從 512 MB 到 4 GB RAM? 1 x 127-GB 硬盤?
RRAS?	配置為路由和遠程訪問服務 (RRAS) 角色的服務器。?	兩個處理器? 2-8 GB 的 RAM? 1 x 127-GB 硬盤?
FS1?	具有備份共享和 DFSR 終結點的文件服務器。?	四個處理器? 2-12 GB 的 RAM? 1 x 127-GB 硬盤? 1 x 1-TB 硬盤 (SAN)? 1 x 750-GB 硬盤?
SP-WFE1、SP-WFE2?	前端 Web 服務器。?	四個處理器? 16 GB RAM?
SP-APP1、SP-APP2、SP-APP3?	應用程序服務器。?	四個處理器? 2-16 GB 的 RAM?
SP-SQL-HA1、SP-SQL-HA2?	數據庫服務器，配置了 SQL Server 2012 AlwaysOn 可用性組以提供高可用性。此配置使用 SP-SQL-HA1 和 SP-SQL-HA2 作為主副本和輔助副本。?	四個處理器? 2-16 GB 的 RAM?

下表介紹了我們為內部部署測試環境的前端 Web 服務器和應用程序服務器而創建和配置的 Hyper-V 虛擬機的驅動器配置。

表：用于內部部署測試的前端 Web 服務器和應用程序服務器的虛擬機驅動器要求

驅動器號尺寸目錄名稱路徑

C?	80?	系統驅動器?	:\Program Files\Microsoft SQL Server\?
E?	80?	日志驅動器 (40 GB)?	:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA?
F?	80?	頁面 (36 GB)?	:\Program Files\Microsoft SQL Server\MSSQL\DATA?

下表介紹了創建和配置作為內部部署數據庫服務器的 Hyper-V 虛擬機的驅動器配置。在"數據庫引擎配置"頁上，訪問"數據目錄"選項卡以設置并確認下表中所示的設置。

表：用于內部部署測試的數據庫服務器的虛擬機驅動器要求

驅動器號尺寸目錄名稱路徑

C?	80?	數據根目錄?	:\Program Files\Microsoft SQL Server\?
E?	500?	用戶數據庫目錄?	:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA?
F?	500?	用戶數據庫日志目錄?	:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA?
G?	500?	臨時數據庫目錄?	:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA?
H?	500?	臨時數據庫日志目錄?	:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA?

設置測試環境

在不同的部署階段，測試團隊通常首先構建內部部署基礎結構，然后構建相應的 Azure 環境。這反映了內部生產服務器場已在運行的常規真實案例。更為重要的是，你應該了解當前生產工作負載、容量和典型性能。除了構建可以滿足業務需求的災難恢復模型外，你還應該調整恢復場服務器的大小以交付最低級別的服務。在冷備用或溫備用環境中，恢復場通常小于生產服務器場。恢復場穩定并且投入生產之后，服務器場可以向上和向外擴展以滿足工作負載要求。

我們分三個階段來部署測試環境：

• 設置混合基礎結構

• 設置服務器

• 部署 SharePoint 服務器場

設置混合基礎結構

此階段涉及設置內部部署服務器場的域環境以及 Azure 中的恢復場。除了與配置 Active Directory 相關的普通任務之外，測試團隊還在兩個環境之間實施了一個路由解決方案和 VPN 連接。

設置服務器

除了場服務器之外，還必須為域控制器設置服務器，并配置處理 RRAS 以及站點間 VPN 的服務器。為 DFSR 服務設置兩個文件服務器，為測試人員設置多個客戶端計算機。

部署 SharePoint 服務器場

SharePoint 服務器場分兩個階段部署，以便在必要時簡化環境穩定化和故障排除。在第一個階段中，每個服務器場部署在拓撲每一層最低數量的服務器上，以支持所需功能。

我們在創建 SharePoint 2013 服務器之前創建安裝了 SQL Server 的數據庫服務器。因為這是一個新部署，我們在部署 SharePoint 之前創建了可用性組。我們根據 MCS 最佳實踐指南創建了三個組。

?備注

創建占位符數據庫，以便你可以在執行 SharePoint 安裝之前創建可用性組。有關詳細信息，請參閱為 SharePoint 2013 配置 SQL Server 2012 AlwaysOn 可用性組

我們創建了服務器場并按以下順序加入其他服務器：

• 設置 SP-SQL-HA1 和 SP-SQL-HA2。

• 為服務器場配置 AlwaysOn 并創建三個可用性組。

• 將 SP-APP1 設置為承載管理中心。

• 將 SP-WFE1 和 SP-WFE2 設置為承載分布式緩存。

在命令行運行?psconfig.exe?時，我們使用了?skipRegisterAsDistributedCachehost?參數。?有關詳細信息，請參閱在 SharePoint 中規劃源和分布式緩存服務 (SharePoint Server 2013)。

在恢復環境中重復以下步驟：

• 設置 AZ-SQL-HA1 和 AZ-SQL-HA2。

• 為服務器場配置 AlwaysOn 并創建三個可用性組。

• 將 AZ-APP1 設置為承載管理中心。

• 將 AZ-WFE1 和 AZ-WFE2 設置為承載分布式緩存。

配置分布式緩存并添加測試用戶和測試內容后，我們開始部署的第二個階段。此階段需要向外擴展各層并將場服務器配置為支持服務器場體系結構中所述的高可用性拓撲。

下表介紹了我們為恢復場設置的虛擬機、子網和可用性集。

表：恢復場基礎結構

服務器名稱。角色配置子網可用性集

spDRAD?	具有 Active Directory 的域控制器?	兩個處理器? 從 512 MB 到 4 GB RAM? 1 x 127-GB 硬盤?	sp-ADservers?	?
AZ-SP-FS?	具有備份共享和 DFSR 終結點的文件服務器?	A5 配置：? 兩個處理器? 14 GB RAM? 1 x 127-GB 硬盤? 1 x 135-GB 硬盤? 1 x 127-GB 硬盤? 1 x 150-GB 硬盤?	sp-databaseservers?	DATA_SET?
AZ-WFE1、AZ -WFE2?	前端 Web 服務器?	A5 配置：? 兩個處理器? 14 GB RAM? 1 x 127-GB 硬盤?	sp-webservers?	WFE_SET?
AZ -APP1、AZ -APP2、AZ -APP3?	應用程序服務器?	A5 配置：? 兩個處理器? 14 GB RAM? 1 x 127-GB 硬盤?	sp-applicationservers?	APP_SET?
AZ -SQL-HA1、AZ -SQL-HA2?	數據庫服務器以及 AlwaysOn 可用性組的主副本和輔助副本?	A5 配置：? 兩個處理器? 14 GB RAM?	sp-databaseservers?	DATA_SET?

操作

測試團隊將服務器場環境穩定下來并完成功能測試之后，即開始配置內部部署恢復環境所需的下列操作任務：

• 配置完整備份和差異備份。

• 在負責在內部部署環境和 Azure 環境之間傳輸事務日志的文件服務器上配置 DFSR。

• 在主數據庫服務器上配置日志傳送。

• 根據需要穩定和驗證日志傳送并進行故障排除。這包括標識和記錄可能導致網絡延遲等問題的任何行為，這些行為可能導致日志傳送或 DFSR 文件同步失敗。

數據庫

我們的故障轉移測試涉及以下數據庫：

• WSS_Content

• ManagedMetadata

• 配置文件數據庫

• 同步數據庫

• 社交數據庫

• 內容類型集線器（用于專用內容類型聯合集線器的數據庫）

疑難解答提示

本節介紹在測試過程中遇到的問題及其解決方案。

使用術語庫管理工具導致了錯誤："托管元數據存儲或連接當前不可用。"

確保 Web 應用程序使用的應用程序池帳戶具有讀取術語庫的權限。

自定義術語集在網站集中不可用

檢查內容網站集和內容類型集線器之間是否缺少服務應用程序關聯。此外，在"Managed Metadata - <網站集名稱> 連接"屬性屏幕中，確保此選項已啟用："此服務應用程序是欄特定的術語集的默認存儲位置。"

Get-ADForest Windows PowerShell 命令會生成錯誤："術語'Get-ADForest'未識別為 cmdlet、函數、腳本文件或可運行程序的名稱。"

設置用戶配置文件時，需要 Active Directory 林名稱。在“添加角色和功能”向導中，確保已啟用用于 Windows PowerShell 的 Active Directory 模塊（依次轉到“遠程服務器管理工具”>“角色管理工具”>“AD DS 和 AD LDS 工具”**** 部分下）。此外，先運行以下命令，再使用?Get-ADForest，以確保已加載軟件依賴項。

復制

Import-module servermanager Import-module activedirectory

在"<服務器名稱>"上啟動"AlwaysOn_health"XEvent 會話時可用性組創建失敗

確保故障轉移群集中的兩個節點已啟動，沒有暫停或停止。

SQL Server 日志傳送作業失敗，并顯示嘗試連接到文件共享時出現訪問拒絕錯誤

確保你的 SQL Server Agent 在網絡憑據而不是默認憑據下運行。

SQL Server 日志傳送作業指示成功，但未復制任何文件

發生這種情況是因為可用性組的默認備份首選項是"首選輔助"。確保你是從可用性組的輔助服務器而不是主服務器運行日志傳送作業，否則，作業將失敗且無提示。

Managed Metadata Service（或其他 SharePoint 服務）在安裝后無法自動啟動

服務可能需要幾分鐘才能啟動，具體取決于你的 SharePoint Server 的性能和當前負載。?手動單擊服務的"?啟動"按鈕，留出足夠的時間讓服務器啟動，并時常刷新一下服務器上的服務屏幕以監視其狀態。?如果服務仍處于停止狀態，啟用 SharePoint 診斷日志記錄，再次嘗試啟動服務，然后檢查日志中是否包含錯誤。?有關詳細信息，請參閱在 SharePoint 2013 中配置診斷日志記錄

將 DNS 更改為 Azure 故障轉移環境之后，客戶端瀏覽器繼續使用 SharePoint 網站的舊 IP 地址

你的 DNS 更改可能不會立即對所有客戶端可見。在測試客戶端上，從提升的命令提示符處執行以下命令，并再次嘗試訪問該網站。

復制

Ipconfig /flushdns

其他資源

SharePoint 數據庫受支持的高可用性和災難恢復選項

為 SharePoint 2013 配置 SQL Server 2012 AlwaysOn 可用性組

另請參閱

云應用和混合解決方案

總結

以上是生活随笔為你收集整理的Microsoft Azure 中的 SharePoint Server 2013 灾难恢复的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。