Microsoft Azure 中的 SharePoint Server 2013 災害復原

使用 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) 。 這些需求會決定哪一個環境最適合您的組織投資。

本文中的指引說明如何實作暖待命環境。 您也可以將其調整為冷待命環境，不過您需要遵循其他程式來支援這種環境。 本文不會說明如何實作熱待命環境。

如需災害復原解決方案的詳細資訊，請 參閱 SharePoint 2013 的高可用性和災害復原概念 和 選擇 SharePoint 2013 的災害復原策略。

解決方案描述

暖待命災害復原解決方案需要下列環境：

• 內部部署 SharePoint 生產伺服器陣列

• Azure 中的復原 SharePoint 伺服器陣列

• 兩個環境之間的站對站 VPN 連線

下圖說明這三個元素。

圖：Azure 中暖待命解決方案的元素

SQL Server使用分散式檔案系統複寫 (DFSR) 來將資料庫備份和交易記錄複製到 Azure 中的復原伺服器陣列：

• DFSR 會將記錄從生產環境傳輸到復原環境。 在 WAN 案例中，DFSR 比直接將記錄傳送至 Azure 中的次要伺服器更為有效率。

• 記錄會重新執行至 Azure 復原環境中的SQL Server。

• 在執行復原練習之前，您不會在復原環境中附加記錄傳送的 SharePoint 內容資料庫。

執行下列步驟來復原伺服器陣列：

1. 停止記錄傳送。

2. 停止接受傳送至主要伺服器陣列的流量。

3. 重新執行最終交易記錄。

4. 將內容資料庫附加至伺服器陣列。

5. 從複寫的服務資料庫還原服務應用程式。

6. 更新網域名稱系統 (DNS) 記錄以指向復原伺服器陣列。

7. 開始完整編目。

建議您定期重聽這些步驟，並記錄這些步驟，以協助確保即時復原順暢地執行。 附加內容資料庫和還原服務應用程式可能需要一些時間，而且通常牽涉到一些手動設定。

執行復原之後，此解決方案會提供下表所列的專案。

資料表：解決方案復原目標

項目	描述
網站和內容	網站和內容可在復原環境中使用。
新的搜尋實例	在此暖待命解決方案中，搜尋不會從搜尋資料庫還原。 復原伺服陣列中的搜尋元件會盡可能設定為與生產伺服器陣列類似的設定。 還原網站和內容之後，就會開始進行完整搜耙以重建搜尋索引。 您不需要等待編目完成，即可讓網站和內容可供使用。
服務	將資料儲存在資料庫中的服務會從記錄出貨的資料庫還原。 系統只會啟動未將資料儲存在資料庫中的服務。 並非所有具有資料庫的服務都需要還原。 下列服務不需要從資料庫還原，而且只能在容錯移轉之後啟動： Usage and Health Data Collection 狀態服務 Word 自動化 任何其他不使用資料庫的服務

您可以與 Microsoft 諮詢服務 (MCS) 或合作夥伴合作，以解決更複雜的復原目標。 下表摘要說明這些專案。

表格：MCS 或合作夥伴可以定址的其他專案

項目	描述
同步處理自訂伺服器陣列解決方案	在理想情況下，復原伺服器陣列組態與生產伺服器陣列相同。 您可以與顧問或合作夥伴合作，評估是否複寫自訂伺服器陣列解決方案，以及程式是否已就緒，以便讓兩個環境保持同步。
內部部署資料來源的連線	將連線複寫到後端資料系統可能不實用，例如備份網域控制站 (BDC) 連線和搜尋內容來源。
搜尋還原案例	由於企業搜尋部署通常相當獨特且複雜，因此從資料庫還原搜尋需要更大的投資。 您可以與顧問或合作夥伴合作，以識別並實作組織可能需要的搜尋還原案例。

本文提供的指引假設內部部署伺服器陣列已設計和部署。

詳細架構

在理想情況下，Azure 中的復原伺服器陣列設定與內部部署的生產伺服器陣列完全相同，包括下列各項：

• 伺服器角色的相同標記法

• 相同的自訂群組態

• 搜尋元件的相同組態

Azure 中的環境可以是較小版本的生產伺服器陣列。 如果您打算在容錯移轉之後相應放大復原伺服陣列，請務必一開始表示每種類型的伺服器角色。

某些設定可能不適用於在容錯移轉環境中複寫。 請務必測試容錯移轉程式和環境，以協助確保容錯移轉伺服器陣列提供預期的服務等級。

此解決方案不會規定 SharePoint 伺服器陣列的特定拓撲。 此解決方案的重點是針對容錯移轉伺服器陣列使用 Azure，並在兩個環境之間實作記錄傳送和 DFSR。

暖待命環境

在暖待命環境中，Azure 環境中的所有虛擬機器都在執行中。 環境已準備好進行容錯移轉練習或事件。

下圖說明從內部部署 SharePoint 伺服器陣列到設定為暖待命環境之 Azure 架構 SharePoint 伺服器陣列的災害復原解決方案。

圖：生產伺服器陣列和暖待命復原伺服器陣列的拓撲和主要元素

在此圖表中：

• 並排說明兩個環境：內部部署 SharePoint 伺服器陣列和 Azure 中的暖待命伺服器陣列。

• 每個環境都包括檔案共用。

• 每個伺服器陣列都包含四層。 為了達到高可用性，每一層都包含兩部伺服器或虛擬機器，這些伺服器或虛擬機器針對特定角色的設定相同，例如前端服務、分散式快取、後端服務和資料庫。 在此圖中，呼叫特定元件並不重要。 這兩個伺服器陣列的設定方式相同。

• 第四層是資料庫層。 記錄傳送可用來將記錄從內部部署環境中的輔助資料庫伺服器複製到相同環境中的檔案共用。

• DFSR 會將檔案從內部部署環境中的檔案共用複製至 Azure 環境中的檔案共用。

• 記錄傳送會將記錄從 Azure 環境中的檔案共用重新執行至復原環境的 SQL Server AlwaysOn 可用性群組中的主要複本。

冷待命環境

在冷待命環境中，大部分的 SharePoint 伺服器陣列虛擬機器都可以關閉。 (我們建議偶爾啟動虛擬機器，例如每兩周或一個月一次，讓每部虛擬機器可以與網域同步。) Azure 復原環境中的下列虛擬機器必須繼續執行，以協助確保記錄傳送和 DFSR 的持續作業：

• 檔案共用

• 主資料庫伺服器

• 至少一部執行網域服務和 DNS Windows Server Active Directory虛擬機器

下圖顯示檔案共用虛擬機器和主要 SharePoint 資料庫虛擬機器正在執行的 Azure 容錯移轉環境。 所有其他 SharePoint 虛擬機器都會停止。 未顯示執行 Windows Server Active Directory 和 DNS 的虛擬機器。

圖：具有執行中虛擬機器的冷待命復原伺服器陣列

容錯移轉至冷待命環境之後，所有虛擬機器都會啟動，而且必須設定達到資料庫伺服器高可用性的方法，例如SQL Server AlwaysOn 可用性群組。

如果實作多個儲存體群組 (資料庫會分散到多個SQL Server高可用性設定組) ，則每個儲存體群組的主資料庫都必須執行以接受與其儲存體群組相關聯的記錄。

技能和體驗

此災害復原解決方案中會使用多項技術。 為了協助確保這些技術如預期般互動，必須正確安裝和設定內部部署和 Azure 環境中的每個元件。 我們建議設定此解決方案的人員或小組，具備具備下列文章所述技術的強大工作知識和實際操作技能：

• 分散式檔案系統 (DFS) 複寫服務

• 具有 SQL Server 的 Windows Server 容錯移轉叢集 (WSFC)

• 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	在 Azure 中部署 SharePoint 復原伺服器陣列。
階段 5	在伺服器陣列之間設定 DFSR。
階段 6	設定記錄傳送至復原伺服器陣列。
階段 7	驗證容錯移轉和復原解決方案。 這包括下列程式和技術： 停止記錄傳送。 還原備份。 編目內容。 復原服務。 管理 DNS 記錄。

階段 1：設計災害復原環境

使用 Microsoft Azure Architectures for SharePoint 2013 中的指引來設計災害復原環境，包括 SharePoint 復原伺服器陣列。 您可以使用 Azure Visio 檔案 中 SharePoint 災害復原解決方案中的 圖形來開始設計程式。 建議您在開始 Azure 環境中的任何工作之前，先設計整個環境。

除了 Microsoft Azure Architectures for SharePoint 2013 中針對設計虛擬網路、VPN 連線、Active Directory 和 SharePoint 伺服器陣列所提供的指引，請務必將檔案共用角色新增至 Azure 環境。

為了支援災害復原解決方案中的記錄傳送，檔案共用虛擬機器會新增至資料庫角色所在的子網。 檔案共用也可作為SQL Server AlwaysOn 可用性群組之節點多數的第三個節點。 這是使用 SQL Server AlwaysOn 可用性群組的標準 SharePoint 伺服器陣列的建議組態。

注意事項

請務必檢閱資料庫參與SQL Server AlwaysOn 可用性群組的必要條件。 如需詳細資訊，請參閱 AlwaysOn 可用性群組的必要條件、限制和建議。

圖：用於災害復原解決方案的檔案伺服器位置

在此圖中，檔案共用虛擬機器會新增至 Azure 中包含資料庫伺服器角色的相同子網。 請勿將檔案共用虛擬機器新增至具有其他伺服器角色的可用性設定組，例如SQL Server角色。

如果您擔心記錄的高可用性，請考慮使用SQL Server備份和還原Azure Blob 儲存體服務來採取不同的方法。 這是 Azure 中將記錄直接儲存至 Blob 儲存體 URL 的新功能。 此解決方案不包含使用此功能的指引。

當您設計復原伺服器陣列時，請記住，成功的災害復原環境會正確反映您想要復原的生產伺服器陣列。 復原伺服陣列的大小不是復原伺服器陣列設計、部署和測試中最重要的專案。 伺服器陣列規模會根據商務需求，從組織到組織而有所不同。 在短暫中斷或效能和容量需求要求您調整伺服器陣列之前，可能會使用相應減少的伺服器陣列。

盡可能以與生產伺服器陣列相同的方式設定復原伺服陣列，使其符合您的服務等級協定 (SLA) 需求，並提供支援企業所需的功能。 當您設計災害復原環境時，也請查看生產環境的變更管理程式。 建議您以與生產環境相同的間隔更新復原環境，以將變更管理程式延伸至復原環境。 在變更管理程式中，建議您維護伺服器陣列組態、應用程式和使用者的詳細清查。

階段 2：建立 Azure 虛擬網路和 VPN 連線

將內部部署網路連線到 Microsoft Azure 虛擬網路 會示範如何在 Azure 中規劃和部署虛擬網路，以及如何建立 VPN 連線。 請遵循主題中的指引來完成下列程式：

• 規劃虛擬網路的私人 IP 位址空間。

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

• 針對往返內部部署 VPN 裝置的流量規劃防火牆規則。

• 在 Azure 中建立跨單位虛擬網路。

• 設定內部部署網路與虛擬網路之間的路由。

階段 3：將 Active Directory 和功能變數名稱服務部署至 Azure 虛擬網路

此階段包括將Windows Server Active Directory和 DNS 部署到混合式案例中的虛擬網路，如Microsoft Azure Architectures for SharePoint 2013所述，如下圖所示。

圖：混合式 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 管理嵌入式管理單元。 不過，在設定 DFSR 之前，登入您的內部部署檔案伺服器和 Azure 檔案伺服器，並在 Windows 中啟用服務。

從 [伺服器管理員儀表板]，完成下列步驟：

• 設定本機伺服器。

• 啟動 [新增角色及功能精靈]。

• 開啟 [檔案和儲存體服務] 節點。

• 選取 [DFS 命名空間 ] 和 [DFS 複寫]。

• 按 [下一步 ] 以完成精靈步驟。

下表提供 DFSR 參考文章和部落格文章的連結。

資料表：DFSR 的參考文章

標題	描述
複製	包含複寫連結的 DFS 管理 TechNet 主題
DFS 複寫：存活指南	具有 DFS 資訊連結的 Wiki
DFS 複寫：常見問題	DFS 複寫 TechNet 主題
Matt Barreto 的部落格	由 Microsoft 檔案伺服器小組的首席計畫經理所撰寫的部落格
Microsoft 儲存體小組 - 檔案封包部落格	關於 Windows Server 中檔案服務和儲存體功能的部落格

階段 6：設定記錄傳送至復原伺服器陣列

記錄傳送是在此環境中設定災害復原的重要元件。 您可以使用記錄傳送，將資料庫的交易記錄檔從主資料庫伺服器實例自動傳送至輔助資料庫伺服器實例。 若要設定記錄傳送， 請參閱在 SharePoint 2013 中設定記錄傳送。

重要事項

SharePoint Server 中的記錄傳送支援僅限於特定資料庫。 如需詳細資訊，請參閱 SharePoint 2013 (支援的 SharePoint 資料庫高可用性和災害復原選項) 。

階段 7：驗證容錯移轉和復原

此最終階段的目標是要確認災害復原解決方案如規劃般運作。 若要這樣做，請建立容錯移轉事件，以關閉生產伺服器陣列並啟動復原伺服器陣列作為取代。 您可以手動或使用腳本來啟動容錯移轉案例。

第一個步驟是停止伺服陣列服務或內容的傳入使用者要求。 您可以藉由停用 DNS 專案或關閉前端網頁伺服器來執行此動作。 伺服器陣列「關閉」之後，您可以容錯移轉至復原伺服器陣列。

停止記錄傳送

您必須在伺服器陣列復原之前停止記錄傳送。 請先在 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 = @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 + ' )')

還原備份

備份必須以備份的建立順序進行還原。 在還原特定交易記錄備份之前，您必須先還原下列先前的備份，而不復原未認可的交易 (也就是使用 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) 。

編目內容來源

您必須針對每個內容來源啟動完整搜耙，才能還原搜尋服務。 請注意，您會遺失一些來自內部部署伺服器陣列的分析資訊，例如搜尋建議。 開始完整編目之前，請使用 Windows PowerShell Cmdlet Restore-SPEnterpriseSearchServiceApplication，並指定記錄出貨和複寫的搜尋管理資料庫，Search_Service__DB_ < GUID >。 此 Cmdlet 會提供搜尋組態、架構、Managed 屬性、規則和來源，並建立一組預設的其他元件。

若要開始完整編目，請完成下列步驟：

1. 在 SharePoint 2013 管理中心中，移至 [應用程式管理>服務應用程式>] [管理服務應用程式]，然後按一下您要編目的 Search Service 應用程式。

2. 在 [ 搜尋管理] 頁面上，按一下 [ 內容來源]，指向您要的內容來源，按一下箭號，然後按一下 [ 開始完整編目]。

復原伺服器陣列服務

下表顯示如何復原具有記錄出貨資料庫的服務、具有資料庫但不建議使用記錄傳送進行還原的服務，以及沒有資料庫的服務。

重要事項

將內部部署 SharePoint 資料庫還原至 Azure 環境並不會復原您尚未在 Azure 中手動安裝的任何 SharePoint 服務。

資料表：服務應用程式資料庫參考

從記錄出貨的資料庫還原這些服務	這些服務具有資料庫，但建議您啟動這些服務，而不需還原其資料庫	這些服務不會將資料儲存在資料庫中;在容錯移轉之後啟動這些服務
機器翻譯服務 Managed Metadata Service Secure Store Service 使用者設定檔。 (僅支援設定檔和社交標記資料庫。不支援同步處理資料庫。) Microsoft SharePoint Foundation 訂閱設定服務	Usage and Health Data Collection 狀態服務 Word 自動化	Excel Services PerformancePoint Services PowerPoint 轉換 Visio Graphics Service Work Management

下列範例示範如何從資料庫還原 Managed Metadata 服務。

這會使用現有的Managed_Metadata_DB資料庫。 此資料庫是記錄出貨，但次要伺服器陣列上沒有作用中的服務應用程式，因此必須在服務應用程式就緒後連線。

首先，使用 New-SPMetadataServiceApplication ，並以還原的資料庫名稱指定 DatabaseName 參數。

接下來，在次要伺服器上設定新的受控中繼資料服務應用程式，如下所示：

• 名稱：受控中繼資料服務

• 資料庫伺服器：出貨交易記錄檔中的資料庫名稱

• 資料庫名稱：Managed_Metadata_DB

• 應用程式集區：SharePoint 服務應用程式

管理 DNS 記錄

您必須手動建立 DNS 記錄，才能指向 SharePoint 伺服器陣列。

在您有多個前端網頁伺服器的大多數情況下，利用 Windows Server 2012 中的網路負載平衡功能或硬體負載平衡器，將要求分散到伺服器陣列中的 Web 前端伺服器之間是合理的。 如果其中一部 Web 前端伺服器失敗，網路負載平衡也可以將要求散發到其他伺服器，以協助降低風險。

一般而言，當您設定網路負載平衡時，會為您的叢集指派單一 IP 位址。 然後，您會在指向叢集的網路 DNS 提供者中建立 DNS 主機記錄。 (針對此專案，我們會在內部部署資料中心失敗時，將 DNS 伺服器放在 Azure 中以進行復原。) 例如，您可以在 Active Directory 的 DNS 管理員中建立 DNS 記錄，例如，稱為 https://sharepoint.contoso.com ，指向負載平衡叢集的 IP 位址。

針對 SharePoint 伺服器陣列的外部存取，您可以在外部 DNS 伺服器上建立主機記錄，其 URL 與用戶端在內部網路上使用的 URL 相同 (例如， https://sharepoint.contoso.com) 指向防火牆中的外部 IP 位址。 (使用此範例的最佳做法是設定分割 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 應用程式裝載的數個網站集合，例如， (唯一的 DNS 名稱， https://sales.contoso.com 以及 https://marketing.contoso.com) 。 在此情況下，您可以為指向叢集 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	前端網頁伺服器。	四個處理器 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 和應用程式伺服器的虛擬機器磁片磁碟機需求

磁碟機代號	Size	目錄名稱	路徑
C	80	系統磁片磁碟機	<DriveLetter > ：\Program Files\Microsoft SQL Server\
E	80	記錄磁片磁碟機 (40 GB)	<DriveLetter > ：\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
F	80	頁面 (36 GB)	<DriveLetter > ：\Program Files\Microsoft SQL Server\MSSQL\DATA

下表描述建立並設定為作為內部部署資料庫伺服器之 Hyper-V 虛擬機器的磁片磁碟機組態。 在 [ 資料庫引擎組態] 頁面上，存取 [資料目錄] 索引 標籤以設定並確認下表所示的設定。

資料表：內部部署測試之資料庫伺服器的虛擬機器磁片磁碟機需求

磁碟機代號	Size	目錄名稱	路徑
C	80	資料根目錄	<DriveLetter > ：\Program Files\Microsoft SQL Server\
E	500	使用者資料庫目錄	<DriveLetter > ：\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
F	500	使用者資料庫記錄目錄	<DriveLetter > ：\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
G	500	暫存 DB 目錄	<DriveLetter > ：\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
H	500	暫存資料庫記錄目錄	<DriveLetter > ：\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 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	前端網頁伺服器	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

作業

在測試小組穩定伺服器陣列環境並完成功能測試之後，他們已啟動設定內部部署復原環境所需的下列作業工作：

• 設定完整和差異備份。

• 在檔案伺服器上設定 DFSR，以在內部部署環境與 Azure 環境之間傳輸交易記錄。

• 在主資料庫伺服器上設定記錄傳送。

• 視需要穩定、驗證和疑難排解記錄傳送。 這包括識別和記錄任何可能會造成問題的行為，例如網路延遲，這會導致記錄傳送或 DFSR 檔案同步處理失敗。

資料庫

我們的容錯移轉測試涉及下列資料庫：

• WSS_Content

• ManagedMetadata

• 設定檔資料庫

• 同步資料庫

• 社交資料庫

• 內容類型中樞 (專用內容類型新聞訂閱中樞的資料庫)

疑難排解提示

本節說明我們在測試期間遇到的問題及其解決方案。

使用字詞庫管理工具造成「受控中繼資料存放區或連線目前無法使用」錯誤。

請確定 Web 應用程式所使用的應用程式集區帳戶具有字詞庫的讀取權限。

網站集合中無法使用自訂字片語

檢查內容網站集合與內容類型中樞之間的服務應用程式關聯是否遺失。 此外，在 [受 控中繼資料 - < 網站集合名稱 > 聯 機屬性] 畫面下，確定已啟用此選項： 此服務應用程式是資料行特定字片語的預設儲存位置。

Get-ADForest Windows PowerShell命令會產生錯誤：「無法將 'Get-ADForest' 一詞辨識為 Cmdlet、函式、腳本檔案或可操作程式的名稱。」

設定使用者設定檔時，您需要 Active Directory 樹系名稱。 在 [新增角色和功能精靈] 中，確定您已在 [遠端伺服器管理工具] [角色管理 > 工具 > ] [AD DS 和 AD LDS 工具] 區段下啟用 [Active Directory 模組] Windows PowerShell () 。 此外，請先執行下列命令，再使用 Get-ADForest 來協助確保已載入您的軟體相依性。

Import-Module ServerManager
Import-Module ActiveDirectory

在 'server name > ' 上啟動 'AlwaysOn_health' XEvent 會話時 < ，可用性群組建立失敗

請確定容錯移轉叢集的兩個節點都處於「上」狀態，而不是「已暫停」或「已停止」。

SQL Server記錄傳送作業失敗，嘗試連線至檔案共用時發生拒絕存取錯誤

請確定您的SQL Server Agent是在網路認證下執行，而不是預設認證。

SQL Server記錄傳送作業表示成功，但不會複製任何檔案

這是因為可用性群組的預設備份喜好設定為 「偏好次要」。 請確定您從可用性群組的次要伺服器執行記錄傳送作業，而不是從主要伺服器執行;否則，作業將會以無訊息方式失敗。

受管理的中繼資料服務 (或其他 SharePoint 服務) 無法在安裝後自動啟動

服務可能需要幾分鐘的時間才能啟動，視 SharePoint Server 的效能和目前負載而定。 手動按一下服務的 [開始 ]，並提供足夠的啟動時間，同時偶爾重新整理伺服器畫面上的 [服務] 以監視其狀態。 如果服務仍停止，請啟用 SharePoint 診斷記錄、再次嘗試啟動服務，然後檢查記錄檔中是否有錯誤。 如需詳細資訊， 請參閱在 SharePoint 2013 中設定診斷記錄

將 DNS 變更為 Azure 容錯移轉環境之後，用戶端瀏覽器會繼續使用 SharePoint 網站的舊 IP 位址

您的 DNS 變更可能不會立即顯示給所有用戶端。 在測試用戶端上，從提升許可權的命令提示字元執行下列命令，然後再次嘗試存取網站。

Ipconfig /flushdns

其他資源

SharePoint 資料庫支援的高可用性和災害復原選項

設定 sharePoint 2013 SQL Server 2012 AlwaysOn 可用性群組

另請參閱

Microsoft 365 解決方案與架構中心