為 SharePoint Server 打造高可用性架構和策略
適用於：
2013 Subscription Edition 
SharePoint in Microsoft 365
高可用性策略對 SharePoint Server 實際執行環境而言是一項重要需求。 端對端策略包括作業程序、平台管理、架構及技術解決方案。 本文著重在高可用性的架構和技術層面。 本指引將說明決定高可用性策略的特定 SharePoint 設計元素和技術選項。
注意事項
[!附註] 高可用性和災害復原是不一樣的。 雖然在規劃與解決方案上會互相重疊，但都是營運持續力的一部分。 高可用性旨在為主要資料中心和預定的停機時間之間提供彈性。 而災害復原的宗旨，則是當主要資料中心的災害導致基礎結構無法運用時，能夠協助組織恢復次要資料中心的電腦運作。 如需 SharePoint Server 災害復原的相關資訊，請參閱＜選擇 SharePoint Server 的災害復原策略＞。
高可用性通常是描述系統能夠持續運作的能力，而且在容錯網域的硬體、軟體或應用程式等一或多個類別中發生故障時，可提供資源給使用者。 可用性層級會以時間百分比的方式表示，測量系統持續運作支援商務功能的時間。 可用性的必要層級會依組織而異。 雖然此需求也會因業務單位而異，但服務層級協議則是適用組織整體。 從用戶的觀點來看，當使用者可以存取伺服器陣列，並使用必須執行其工作的功能和服務時，即可使用SharePoint伺服器數位。
高可用性 SharePoint 伺服器陣列具備下列目標與特性：
伺服器陣列設計可降低潛在的故障點。 這是因為不太可能消除所有故障點，因此整體策略必須能夠針對如何回應故障事件加以解決。
容錯移轉事件會順暢進行，幾乎不會影響到使用者活動。
伺服器陣列會減少容量來持續運作，而不會完全失效。
伺服器陣列相當有彈性。 不會經常發生影響服務的事件，萬一發生也會即時採取有效行動。
簡介
在針對 SharePoint 環境建立實際和經濟的高可用性架構和策略之前，必須先定義及量化可用性目標。 這些目標反映出貴組織依據 SharePoint Server 所能達到的程度，以及服務遺失會如何影響組織運作。 服務遺失造成的影響取決於遺失性質 (全面或部分) 和持續遺失的時間。
一項成功的高可用性策略必須能夠反映出組織的特定需求。 此外，該策略必須在各項業務需求、IT 服務等級協定 (SLA)、以及技術解決方案、IT 支援能力及基礎結構成本的可用性之間取得最佳平衡。
識別出組織的可用性需求後，即可開始打造高可用性的設計和策略，降低停機時間風險和作業效率低落問題。 設計和部署高可用系統的 IT 專家會利用下列指引方針來滿足目標：
消除各個容錯網域和各個可能層級 (作業系統、軟體及 SharePoint 應用程式) 整體系統的單一失敗點。
執行超快速錯誤偵測、隔離及解決方案。
高可用性解決方案的範圍很廣，可提供一套全系統的共用資源，經過整合後能提供預先定義的必要服務。 此解決方案採取不同軟硬體組合，可在系統或部分系統故障時將停機時間降到最低，並還原服務。
容錯解決方案以硬體為主，採用特定硬體偵測錯誤並即時切換到備援硬體元件。 此元件可以是處理器、記憶板、電源供應器、I/O 子系統或儲存子系統。 切換到備援元件的方式有助於提高服務等級。
組織可參照容錯解決方案和高可用性解決方案的成本效益分析來擬定有效策略，以期符合 SharePoint 伺服器陣列的可用性目標。 通常這兩項解決方案之間會有成本上的權衡。
對於 SharePoint 伺服器陣列而言，執行高可用性成本的程序是較為昂貴的一項投資。 當可用性等級和想提高可用性的系統數目增加時，可用性解決方案的複雜度和成本也會隨之增加。
而精進虛擬化技術則可讓組織使用虛擬電腦作為熱備用、暖備用及冷備用。 虛擬電腦可能更適合提供同樣的功能。 虛擬化具備彈性和成本效益。 不過您必須確認虛擬機器有足夠容量處理即將更換的實體電腦負載。
建立支援高可用性的伺服器陣列架構
下列圖例說明如何散佈及設定不同部分的 SharePoint 環境來提升伺服器陣列的可用性。 此範例亦說明備援如何解決容錯網域。
注意事項
[!附註] 我們提供的範例並不完整。 舉例來說，此範例並未顯示所有容錯網域和容錯硬體。
伺服器拓撲備援解決失敗點的範例
請參閱前述圖例的拓撲，並注意下列事項：
本範例中的陣列伺服器可以是部署在 Hyper-V 主機伺服器的實體電腦或虛擬機器。 識別與回應失敗點的原則均適用於這兩種環境。
由四部伺服器 (W1-W4) 專門提供內容，而且如果有一或多部伺服器發生失敗，此備援即可提高可用性。 套用軟體更新時，此備援等級也可協助讓伺服器陣列持續運作。
由四部應用程式伺服器 (A1-A4) 提升伺服器陣列服務的可用性和搜尋等特定應用程式元件。 以搜尋角色和元件為備援。
以伺服器陣列資料庫伺服器為備援，而且使用資料庫鏡像或叢集，可達到資料庫高可用性。
在虛擬環境中，會將虛擬機器設置在獨立的 Hyper-V 主機伺服器中，藉此消除單一失敗點。 這項設置虛擬機器的方式係遵照可用性與效能的最佳作法指引。
將涵蓋兩部虛擬化主機電腦的主要資料庫伺服器 (標示為 1) 和機架 2 (標示為 2) 識別為容錯網域，以顯示如何將伺服器陣列和基礎結構視為一個容錯網域集合。 此方式顯示您可以如何深入分析環境，以便研擬完整策略和成本效益分析。
其他伺服器陣列角色和服務
我們的範例不包含可能在特定 SharePoint 伺服器陣列中執行的所有角色、服務以及服務應用程式。 您無法針對 SharePoint 伺服器陣列的一切使用一般方式達到高可用性。 部分可使用標準方式達到高可用性的重要排除如下：
在容錯期間，分散式快取有特殊的考量事項。 如需詳細資訊，請參閱＜規劃分散式快取服務＞和＜在 SharePoint Server 中管理分散式快取服務＞。
SharePoint 工作流程需要工作流程管理員 1.0 累積更新 3。 設定 SharePoint Server 2016 的工作流程，做法如同 SharePoint Server 2013。 如需詳細資訊，請參閱＜工作流程管理員 1.0 累積更新 3 的描述＞和＜在工作流程管理員 1.0 中設定高可用性工作流程＞。
注意事項
[!附註] SharePoint Server 2016 的工作流程設定沒有改變，和 SharePoint Server 2013 相同。 您必須安裝工作流程管理員 1.0 累積更新 3。
雖然我們建議服務應用程式可在多部電腦上執行，但有些應用程式對於高可用性有獨特的安裝與設定需求。 「使用者設定檔」應用程式就是一個已知範例。
在高可用性解決方案中使用容錯
在設計出支援高可用性角色和工作量的架構後，您可以使用容錯元件提升可用性。 容錯解決方案適用於整個基礎結構，其中包括資料庫。
容錯基礎結構
容錯功能幾乎隨時適用於 SharePoint 伺服器陣列基礎結構中的每個硬體元件。 請在您的高可用性設計中，從運作和成本觀點決定應具備容錯功能的基礎結構部分。 由於您可以讓基礎結構各個部分都具備容錯功能，但不表示一定需要如此。
容錯資料庫伺服器和資料庫
由於 SharePoint 平台及其應用程式工作量仰賴所有 SharePoint 資料庫的可用性和可靠性，因此高可用性資料庫對於高可用性策略而言是一個極度重要的環節。 您可以利用下列功能作為 SharePoint 資料庫伺服器和資料庫的容錯解決方案：
SQL Server 故障轉移叢集 (SQL Server 2014 中 Service Pack 1 (SP1) ) 和 SQL Server 2012 中的 AlwaysOn 故障轉移叢集實例 (FCI)
AlwaysOn 可用性群組
SQL Server 高可用性資料庫鏡像
關於AlwaysOn故障轉移叢集實例和AlwaysOn可用性群組
容錯移轉叢集在兩部電腦之間需要有共用的磁碟儲存體。 在兩個設定節點中，會將這兩部電腦設定為主動/被動，以便提供主要節點的完整備援執行個體。 只有在主要節點失敗時，被動節點才會上線運作。 共用磁碟一次只會顯示給一部電腦。 此設定通常需要大部分的其他硬體。 在 SQL Server 2014 (SP1) 和 SQL Server 2012 中，這種類型的叢集組態是 AlwaysOn 故障轉移叢集實例，它是安裝 SQL Server 的特定方式。 由於設定需求關係，您無法採用標準的 SQL Server 安裝並輕鬆地將其變更成容錯移轉叢集執行個體。
AlwaysOn 可用性群組是 SQL Server 2014 (SP1) 和 SQL Server 2012 中的不同技術， (將其視為使用 Windows 叢集所公開之某些功能的資料庫鏡像) 子系。 不過此技術並不需要共用磁碟儲存體，而且可用性群組中的電腦不必安裝 SQL Server 的特定設定。 將資料庫伺服器新增至 Windows 叢集之後，就可以輕鬆地啟用 AlwaysOn 可用性群組，然後設定您想要的可用性群組。
總而言之，任何執行 SQL Server 2014 (SP1) 和 SQL Server 2012 Enterprise Edition 的伺服器，都可以藉由加入叢集並設定可用性群組來使用 AlwaysOn 可用性群組。 AlwaysOn 故障轉移叢集需要特殊的硬體和設定步驟，才能設定故障轉移叢集實例。 這些技術都可用於特定環境，而且兩者都是互補的競爭對手。 如需這些功能的相關詳細資訊，請參閱＜高可用性解決方案 (SQL Server)＞。 如需決定要使用哪一種 SQL Server 可用性技術的協助，請參閱 商務持續性和資料庫復原 - SQL Server。
重要事項
[!重要事項] 由於每個 SQL Server 高可用性選項有其專屬功能、優勢及缺點，因此單一選項不見得會比其他選項卓越。 例如，在使用AlwaysOn可用性群組的指定案例中，將數據遺失降至最低可能會優於AlwaysOn故障轉移叢集實例所達到的任何效能提升。 您必須依據業務需求和 IT 基礎結構需求選擇高可用性解決方案。
選擇要使用的 SQL Server 選項之決定性要素便是 SharePoint 資料庫。 您必須了解 SharePoint Server 資料庫的特性。 每個資料庫的特定需求或限制將決定 SQL Server 容錯解決方案是否適合或完全支援您的實際執行環境。 建議您閱讀下列文章：
SQL Server 容錯移轉叢集
容錯移轉叢集為 SQL Server 2014 (SP1) 上的 SQL Server 或 SQL Server 2012 執行個體提供可用性支援。
容錯移轉叢集結合了一或多項節點或伺服器，以及二或多個共用磁碟。 雖然容錯移轉叢集的執行個體會顯示為單一電腦，但如果目前節點無法使用，該執行個體也可在各節點之間提供容錯移轉。 SharePoint Server 可在執行於 SQL Server 支援叢集中的各種主動和被動節點組合。
SharePoint Server 將此叢集視為單一個體。 因此從 SharePoint Server 的觀點來看，容錯移轉為自動而且一致。
注意事項
從一個叢集節點轉換到另一個時，若發生計劃或非計劃的容錯移轉，會造成連線中斷且必須重新建立連線。
如需 SQL Server 故障轉移叢集的詳細資訊，請參閱 (SQL Server) 的 AlwaysOn 故障轉移叢集實例 。
SQL Server AlwaysOn 可用性群組和 SQL Server 資料庫鏡像
SQL Server Always On 可用性群組和 SQL Server 資料庫鏡像的主要優點是，這兩者都會提供完整或幾乎完整的數據備援，這取決於您設定它們以進行交易處理的方式。 除了將資料遺失情形降到最低之外，自動容錯移轉也可降低實際執行資料庫的停機時間。
重要事項
雖然 SQL Server 2016、SQL Server 2014 (SP1) ，以及 SQL Server 2012 支援資料庫鏡像，但此功能已規劃淘汰。 建議您避免在新的開發工作中使用此功能。 規劃變更目前使用此功能的應用程式。 請改用 AlwaysOn 可用性群組。
AlwaysOn 可用性群組
SQL Server AlwaysOn 可用性群組功能是高可用性和災害復原解決方案，可提供資料庫鏡像的企業層級替代方案。 AlwaysOn 可用性群組支援使用者定義集合中包含之一或多個使用者資料庫的故障轉移環境。 此集合 (即可用性群組) 包含下列要素：
複本，此為一組名稱為可用性資料庫的離散使用者資料庫，可當成單一單位處理。 每個可用性群組都支援一個主要複本且最多可支援四個次要複本。
SQL Server 的特定執行個體，可主控每個複本以及維護每個隸屬於可用性群組之資料庫的本機複本。
當可用性群組容錯移轉至目標執行個體或目標伺服器時，群組中的所有資料庫也會進行容錯移轉。 由於 SQL Server 2014 (SP1) 和 SQL Server 2012 可以在單一伺服器上裝載多個可用性群組，因此您可以設定 Always On 故障轉移至不同伺服器上的 SQL Server 實例。 這樣能夠減少閒置高效能待命伺服器來處理完全載入主要伺服器的需求，此為可用性群組的許多優點之一。
注意事項
資料庫問題 (例如，因為資料檔遺失、資料庫刪除或交易記錄毀損而變成有疑問的資料庫 ) 不會導致容錯移轉。
如需AlwaysOn可用性群組優點和AlwaysOn可用性群組術語概觀的詳細資訊，請參閱 SQL Server (AlwaysOn 可用性群組) 。
資料庫鏡像
注意事項
雖然 SQL Server 2016、SQL Server 2014 (SP1) ，以及 SQL Server 2012 支援資料庫鏡像，但此功能已規劃淘汰。 建議您避免在新的開發工作中使用此功能。 規劃變更目前使用此功能的應用程式。 請改用 AlwaysOn 可用性群組。
資料庫鏡像以保有主要資料庫伺服器中資料庫鏡像複本的方式，提供資料庫備援。 鏡像會在每個資料庫上執行，而且只會搭配採用完整復原模式的資料庫使用。
注意事項
鏡像作業模式共有兩種。 其中一個是支援同步作業的高安全性模式。 在高安全性模式下，當工作階段開始時，鏡像伺服器會儘快同步處理鏡像資料庫和主體資料庫。 一旦資料庫同步處理完畢後，交易就會寫入次要伺服器的記錄中並重新執行。 (控件會在交易強化后立即返回主體伺服器。) 另一個鏡像模式是高效能，它會使用異步操作來減少交易延遲，但代價是數據遺失增加。
若是 SharePoint 伺服器陣列中的高可用性鏡像，您必須使用具備自動容錯移轉功能的高安全性模式。 高安全性資料庫鏡像需要三種伺服器執行個體：主體、鏡像及見證。 見證伺服器可讓 SQL Server 從主體伺服器自動容錯移轉至鏡像伺服器。 從主體資料庫容錯移轉至鏡像資料庫通常需要幾秒的時間。
如需資料庫鏡像的一般資訊，請參閱＜資料庫鏡像＞。
重要事項
設定使用 SQL Server FILESTREAM 遠端 BLOB (二進位大型物件) 存放區提供者的資料庫無法使用鏡像。
比較單一伺服器陣列的資料庫可用性和復原策略
會針對高可用性和資料復原選用 SQL Server 技術，應該是依據組織對於目標復原時點 (RPO) 和目標復原時間 (RTO) 的業務目標而選。 雖然 RPO 和 RTO 通常與災害復原有關，但部分失敗事件則不屬於災害範圍，而是需要從主體資料中心的本機備份媒體中復原。
重要事項
[!重要事項] 根據特定資料庫，各種 SharePoint Server 資料庫僅支援特定的 SQL Server 高可用性選項。 如需詳細資訊，請參閱＜SharePoint 資料庫支援的高可用性和災害復原選項＞。
下表依據 SQL Server 可用解決方案能達到的 RPO 和 RTO 結果提供一般比較。
注意事項
[!附註] 下表中的時間是為了比較資料庫選項。 在實際情況中，所有時間會依據工作量、資料磁碟區及容錯移轉程序而定。
依據資料庫技術比較 RPO 和 RTO
| SQL Server 解決方案 | 可能遺失資料 (RPO) | 可能復原時間 (RTO) | 自動容錯移轉 |
可讀取次要 注意： SharePoint Server 支援可讀取的次要複本，以供運行時間使用。 如需詳細資訊，請參閱 2014 年 4 月的 Office 2013 累積更新 和 在 SharePoint Server 中執行使用只讀資料庫的伺服器數位。 |
|---|---|---|---|---|
| AlwaysOn 可用性群組 (同步認可) |
零 |
秒 |
是 |
0 - 2 |
| AlwaysOn 可用性群組 (異步認可) |
秒 |
分鐘 |
否 |
0 - 4 |
| AlwaysOn 故障轉移叢集實例 |
不適用 FCI 本身不具備資料保護功能。 資料遺失量需視儲存系統實作而定。 |
秒至分鐘 |
是 |
不適用 |
| 資料庫鏡像 - 高安全性 (同步模式 + 見證伺服器) |
零 |
秒 |
是 |
不適用 |
| 資料庫鏡像 - 高效能 (非同步模式) |
秒 |
分鐘 |
否 |
不適用 |
| 備份、複製、還原 |
若失敗後可存取記錄結尾，則為數小時或零。 |
數小時至數天 |
否 |
還原時沒有 |
SQL Server 叢集、AlwaysOn 可用性群組和資料庫鏡像的比較
| 程序 | SQL Server 容錯移轉叢集 | SQL Server 2014 (SP1) 和 SQL Server 2012 AlwaysOn 可用性群組 | SQL Server 高可用性鏡像 |
|---|---|---|---|
| 容錯移轉時機 |
失敗後叢集成員幾乎會立即接管。 當叢集節點加速時，會發生延遲。 |
失敗後複本幾乎會立即接管。 當次要複本加速時，會發生延遲。 |
一旦處理重做佇列，鏡像就會接管。 |
| 交易一致性 |
是 |
是 |
是 |
| 交易並行 |
是 |
是 |
是 |
| 復原時機 |
比起可用性群組，復原時間更短。 |
比起容錯移轉叢集，復原時間更長，但比起鏡像解決方案，復原時間更快。 |
比起叢集或可用性群組，復原時間稍長。 |
| 容錯移轉所需採取的步驟 |
資料庫節點自動偵測失敗。 SharePoint Server 參考叢集，因此容錯移轉一致且自動。 |
可用性群組接聽程式會自動偵測失敗，且容錯移轉一致且自動。 |
資料庫會自動偵測失敗。 SharePoint Server 設定正確時會知曉鏡像位置，則容錯移轉屬於自動。 |
| 提供保護，避免失敗儲存 |
容錯移轉叢集本身不具備資料保護功能。 資料遺失量需視儲存系統實作而定。 例如 SAN 環境有多個檔案路徑、RAID 及熱備用等備援要素。 |
提供保護，避免失敗儲存，原因是主要複本會寫入次要複本中的本機磁碟。 |
提供保護，避免失敗儲存，原因是主體和鏡像資料庫伺服器會寫入本機磁碟。 |
| 支援的儲存類型 |
需要比專屬儲存更為昂貴的共用儲存。 |
可使用較不昂貴的直接附加儲存解決方案。 |
可使用較不昂貴的直接附加儲存。 |
| 位置需求 |
叢集的成員必須在相同的子網路上。 Note: 這不適用於 SQL Server 2014 (SP1) 和 SQL Server 2012。 |
只要延遲不會造成效能問題，複本便可位於不同子集。 |
主體、鏡像及見證伺服器必須位於同一個 LAN (來回最高達 1 毫秒延遲)。 |
| 復原模式 |
建議使用 SQL Server 完整復原模式。 您可以使用 SQL Server 簡易復原模式。 不過如果叢集遺失，唯一可用的復原點將是上次的完整備份。 |
需要 SQL Server 2014 (SP1) 和 SQL Server 2012 完整復原模式。 |
需要使用 SQL Server 完整復原模式。 |
| 效能負荷 |
進行容錯移轉時，可能會發生效能降低情形。 容錯移轉時伺服器將會無法使用，而連線也會中斷，因此請於新主動節點中重新建立。 |
AlwaysOn 可用性群組因為次要複本上的同步認可而導致交易延遲。 延遲量會依據必須進行同步處理的次要複本量而定。 記憶體和處理器負荷大於叢集，但小於鏡像， |
高可用性鏡像會造成交易延遲，因為它是同步的。 它也需要額外的記憶體和處理器額外負荷。 |
| 作業負荷 |
設定並維持在伺服器等級。 |
作業負荷大於叢集和鏡像。 除了 Windows Server 層級之外，Always On 還需要 SQL Server 資料庫伺服器層級的額外負荷。 附註：登入和代理程式作業等伺服器等級物件必須手動維護。 如果新增內容資料庫，必須將其新增至可用性群組，並將主要複本同步處理至次要複本。 SharePoint 伺服器陣列環境需要多個設定步驟，才能確保 SharePoint Server 連線字串與可用性群組接聽程式名稱建立正確關聯。 |
作業負荷大於叢集。 必須設定及維護所有資料庫。 容錯移轉後手動重新設定。 附註：登入和代理程式作業等伺服器等級物件必須手動維護。 如果新增內容資料庫，必須將其新增至主體，並將主體同步處理至鏡像。 |
將兩個資料中心設定為單一伺服器陣列 (「延伸的」伺服器陣列)，以提供高可用性
有些企業的各資料中心位置非常接近，並透過高頻寬光纖連結加以連接。 當這類環境可供使用時，就可能將兩個資料中心設為單一伺服器陣列。 這樣的分散式伺服器陣列拓撲稱為「延伸的」伺服器陣列。
若要將延伸的伺服器陣列架構當作支援的高可用性解決方案使用，必須符合下列前提：
伺服器數位內部延遲 <高度一致， (單向) ,99.9% 的時間在10分鐘內。 (伺服器數位內部延遲通常定義為前端網頁伺服器與資料庫伺服器之間的延遲。)
頻寬速度必須至少每秒 1 Gigabit。
如要提供延伸伺服器陣列的容錯能力，請使用標準最佳作法指導設定備援服務應用程式和資料庫。
下列圖例顯示延伸的伺服器陣列。
延伸的伺服器陣列
將備份與還原作業納入高可用性策略
您的高可用性策略必須包含適當的備份和還原作業，方可確保 SharePoint 伺服器陣列的靈活度。 發生媒體失敗或使用者錯誤等事件時，必須能夠即時還原伺服器陣列環境或伺服器陣列資料中受影響的部分。 有效的備份和還原解決方案應該能夠讓您達到定義的目標復原時間 (RTO) 和目標復原時點 (RPO)。