本文為機器翻譯文章。如需檢視英文版,請選取 [原文] 核取方塊。您也可以將滑鼠指標移到文字上,即可在快顯視窗顯示英文原文。
譯文
原文

為 SharePoint 2013 打造高可用性架構和策略

 

適用版本:SharePoint Foundation 2013, SharePoint Server 2013

上次修改主題的時間:2016-12-16

摘要:了解如何在單一 SharePoint 2013 伺服器陣列中結合伺服器陣列架構和技術,並打造高度可用的環境。

高可用性策略對 SharePoint 2013 實際執行環境而言是一項重要需求。端對端策略包括作業程序、平台管理、架構及技術解決方案。本文著重在高可用性的架構和技術層面。本指引將說明決定高可用性策略的特定 SharePoint 設計元素和技術選項。

注意事項 附註:
高可用性和災害復原是不一樣的。雖然在規劃與解決方案上會互相重疊,但都是營運持續力的一部分。高可用性旨在為主要資料中心和預定的停機時間之間提供彈性。而災害復原的宗旨,則是當主要資料中心的災害導致基礎結構無法運用時,能夠協助組織恢復次要資料中心的電腦運作。如需 SharePoint 2013 災害復原的相關資訊,請參閱<選擇 SharePoint 2013 的災害復原策略>。

本文內容:

高可用性通常用來描述系統,以繼續作業系統與一個或多個容錯網域中的下列類別中發生失敗時提供給其使用者的資源的能力: 硬體、 軟體或應用程式。可用性層級被表示系統支援商務函數持續運作的時間百分比的量值。所需的層級的可用性會視組織而異。雖然這項需求也可能不同業務單位之間,服務等級協定為整個組織。從使用者的觀點來看,Sharepoint 伺服器陣列時可用的使用者可以存取伺服器陣列及使用的功能和服務,他們必須先執行其工作。

高可用性 SharePoint 伺服器陣列具備下列目標與特性:

  • 伺服器陣列設計可降低潛在的故障點。這是因為不太可能消除所有故障點,因此整體策略必須能夠針對如何回應故障事件加以解決。

  • 容錯移轉事件會順暢進行,幾乎不會影響到使用者活動。

  • 伺服器陣列會減少容量來持續運作,而不會完全失效。

  • 伺服器陣列相當有彈性。不會經常發生影響服務的事件,萬一發生也會即時採取有效行動。

在針對 SharePoint 環境建立實際和經濟的高可用性架構和策略之前,必須先定義及量化可用性目標。這些目標反映出貴組織依據 SharePoint 2013 所能達到的程度,以及服務遺失會如何影響組織運作。服務遺失造成的影響取決於遺失性質 (全面或部分) 和持續遺失的時間。

虧損通常是指服務減少或完全遺失所導致的結果,特別是針對執行線上業務的公司而言。然而其他潛在的後果一樣會傷害組織。例如合作夥伴、供應商或客戶可能不再信任組織、損害企業品牌形象及法律問題等。

一項成功的高可用性策略必須能夠反映出組織的特定需求。此外,該策略必須在各項業務需求、IT 服務等級協定 (SLA)、以及技術解決方案、IT 支援能力及基礎結構成本的可用性之間取得最佳平衡。

在您識別出組織的可用性需求後,即可開始打造高可用性設計和策略,降低停機時間風險和作業效率低落問題。設計和部署高可用系統的 IT 專家會利用下列指引方針來滿足目標:

  • 消除各個容錯網域和各個可能層級 (作業系統、軟體及 SharePoint 應用程式) 整體系統的單一失敗點。

    注意事項 附註:
    容錯網域可提供實體失敗點的範圍和限制。IEEE Computer Magazine 在 2011 年 3 月份的議題 (March 2011 Issue of IEEE Computer Magazine) 中做出以下定義:「容錯網域係指一套包含電腦、交換器等的硬體元件共用單一失敗點。」
    如需容錯網域和升級網域的詳細資訊,請參閱Window Azure 容錯網域和升級網域的 IT 專業人員
  • 執行超快速錯誤偵測、隔離及解決方式。

注意事項 附註:
SLA 屬於 IT 服務業者 (內部 IT 群組或外部廠商) 與使用者代表之間的交涉協定,是用以識別和量化服務業者即將提供的必要服務與支援。SLA 明確、具體而且精確,可避免誤解業者和使用者的期望。由於 SLA 通常會明訂第三方服務業者涉及的罰款,因此清晰和精確度相當重要。

高可用性和容錯是不一樣的。高可用性的定義很重要,這是因為通常會將容錯當成同義詞來形容高可用性的執行方式。

高可用性解決方案的範圍很廣,可提供一套全系統的共用資源,經過整合後能提供預先定義的必要服務。此解決方案採取符合業界標準的不同軟硬體組合,可在系統或部分系統故障時將停機時間降到最低,並還原服務。

容錯解決方案以硬體為主,採用特定硬體偵測錯誤並即時切換到備援硬體元件。此元件可以是處理器、記憶板、電源供應器、I/O 子系統或儲存子系統。切換到備援元件的方式有助於提高服務等級。

成本效益分析容錯解決方案和高可用性解決方案可讓組織建立有效的策略以符合其 SharePoint 伺服器陣列的可用性目標。通常是成本的兩個解決方案之間的優缺點。如需詳細資訊,請參閱 <評估高可用性 (HA) 相對於容錯容錯 (FT) 解決方案

可用性是以 100% 的運作時間或不停機進行評估。IT 領域常見的可用性評估方式是以 9 的數字多寡表示,從一個 9 (90%) 到最理想的五個 9 (99.999%)。「數字 9」的評估方式是依指定系統執行、運作以及供使用者使用的時間百分比。

注意事項 附註:
「運作時間」通常用來當作可用性的同義詞,但這會令人產生誤解,原因是電腦系統可以運作,但是無法提供使用者所需的服務和功能。

可用性百分比的計算方程式如下:x = (n - y) * 100/n

  • x 表示百分比

  • n 表示在指定行事曆月中的總分鐘數 (30 天)

  • y 表示系統或服務無法使用的總分鐘數

如您所見下表顯示可用性百分比與行事曆時間對應項的關聯,以五個 9s 的可用性會很難達成。此層級的可用性也是昂貴、 複雜,並在某些情況下涉及的風險。在五個 9s 的多個觀點來看,請閱讀 Vijay: Gill post多少 9?和 Sean 船殼張貼的五個 9-高可用性 overrated 的為何神獸

注意事項 附註:
可用性達三個 9 對於在資料中心執行 SharePoint 伺服器陣列的大多數企業而言均屬正常。而部署在代管環境或雲端的 SharePoint 伺服器陣列,其可用性等級也屬於正常。

建立 % 可用性與行事曆停機時間的關聯

可接受的可用性百分比 每日停機時間 每月停機時間 每年停機時間

90 (一個 9)

144.00 分鐘

72 小時

36.5 天

99 (兩個 9)

14.40 分鐘

7 小時

3.65 天

99.9 (三個 9)

86.40 秒

43 分鐘

8.77 小時

99.99 (四個 9)

8.64 秒

4 分鐘

52.60 分鐘

99.999 (五個 9)

0.86 秒

26 秒

5.26 分鐘

雖然超出本文章範圍,但下列幾個 SLA 層面仍應該反映在高可用性的設計上。

可用性定義和範圍

您無法建立可用性環境或交涉 SLA 直到您定義的可用性。其必須為量值的使用者完成其工作所需的一般工作並使用的功能和服務的 SharePoint 提供的功能。組織使用的 SharePoint 工作負載決定此定義與可用性的範圍。工作量需求客戶而異和每個組織、 伺服器陣列所提供的功能及需求的伺服器陣列的使用者設定檔為基礎。

可用性計算例外

可用性例外對於可用性設計之重要,不亞於對 SLA 的重要性。每個系統都需要執行日常維護,因此預訂的停機時間或等級較低的服務均不列入可用性計算當中。一般例外有排程維護時數和活動的預訂停機時間,例如隔離病毒或回應安全威脅。

停機時間指標

前述的「建立 % 可用性與行事曆停機時間的關聯 」一表中,已識別出可用性每個 9 的停機時間。下列方法可用來計算可用性:

  • 各項失敗之間的平均時間 (MTBF) - 可修復系統中兩個連續失敗之間的預計間隔時間。

  • 失敗的平均時間 (MTTF) - 系統無法修復時的預計失敗時間。

  • 維修或更換平均時間 (MTTR) - 修復或更換失敗元件的預計時間。

下列方程式可以計算可用性:可用性 = MTTF / (MTTF + MTTR)。您可以利用此方程式計算總可用性;若要改善可用性,可採用更可靠的軟硬體元件來增加 MTTF 和減少 MTTR。

效能與可用性的關係

效能不會將可用性隔離在外。當系統在正常狀況下執行時,服務業者和消費者會為服務等級定義可量化的效能基準。但是如果特殊事件嚴重影響效能,致使系統基本上無法使用 (定義:無法使用伺服器陣列),便會降低可用性。下列是常見的特殊事件範例:

  • 公開網頁伺服器上的拒絕服務攻擊

  • 使用資料庫伺服器資源或鎖定表格的資料庫交易之簡單格式查詢

  • 其他位置事件所造成的廣域網路 (WAN) 失敗或高網路延遲

當越來越多組織移轉到分散在不同地理區的 SharePoint 伺服器陣列或代管環境時,網路延遲對於可用性規劃就變得極為重要。

對於 SharePoint 伺服器陣列而言,執行高可用性成本的程序是較為昂貴的一項投資。當可用性等級和想提高可用性的編號系統增加時,可用性解決方案的複雜度和成本也會隨之增加。下列成本通常隸屬於高可用性投資項目:

  • 其他基礎結構元件,例如網路介面卡、交換器及備援電源。

  • 其他硬體、軟體或軟體授權,可支援為伺服器陣列架構提供工作量備援的各種伺服器陣列角色。

  • 備用硬體,可更換失敗的設備。

    雖然為了日常維護或更換失敗伺服器而準備不同讀取狀態的備用電腦十分常見,但卻是投資閒置的硬體。

    注意事項 附註:
    而精進虛擬化技術則可讓組織使用虛擬電腦作為熱備用、暖備用及冷備用。虛擬電腦可能更適合提供同樣的功能。虛擬化具備彈性和成本效益。不過您必須確認虛擬機器有足夠容量處理即將更換的實體電腦負載。
  • 維護和支援成本的增加與可用性等級成比例,且這些解決方案可符合可用性需求。

  • 伺服器陣列預期性的變更,例如擴充。擴充伺服器陣列時,可用性解決方案必須能夠反映所有對伺服器陣列拓撲的變更,而成本也可能會隨之增加。

  • 健全的偵測和警示系統可快速偵測錯誤。此系統可使用現有的錯誤偵測工具,而且可納入 System Center Operations Manager 等狀況監控和警示工具。

  • 實行伺服器陣列本身高可用性或符合大型資料中心需求所需的整合或自訂成本。

在核心業務需求環境中評估較佳可用性的成本。在許多情況下,每個組織單位並不需要等級相同的可用性。請考慮不同網站、不同服務或不同伺服器陣列適用的各種可用性等級。

根據前述的「建立 % 可用性與行事曆停機時間的關聯」表,可用性為五個 9 表示連續一整年中系統的停機時間僅 5.26 分鐘!雖然可以達到此等級的可用性,但對許多組織而言成本卻過於高昂。關鍵決策在於,比起失敗造成的影響,必須能夠找出在提升可用性 9 的數量之投資時不會產生成本效益的平衡點。

下列圖例說明如何散佈及設定不同部分的 SharePoint 環境來提升伺服器陣列的可用性。此範例亦說明備援如何解決容錯網域。

注意事項 附註:
我們提供的範例並不完整。舉例來說,此範例並未顯示所有容錯網域和容錯硬體。

備援的範例中的伺服器陣列拓撲位址點 offailure

這個伺服器陣列範例顯示如何使用重複的角色與服務來處理單一失敗點。

請參閱前述圖例的拓撲,並注意下列事項:

  • 本範例中的陣列伺服器可以是部署在 Hyper-V 主機伺服器的實體電腦或虛擬機器。識別與回應失敗點的原則均適用於這兩種環境。

  • 由四部伺服器 (W1-W4) 專門提供內容,而且如果有一或多部伺服器發生失敗,此備援即可提高可用性。套用軟體更新時,此備援等級也可協助讓伺服器陣列持續運作。

  • 由四部應用程式伺服器 (A1-A4) 提升伺服器陣列服務的可用性和搜尋等特定應用程式元件。以搜尋角色和元件為備援。如需搜尋可用性的相關詳細資訊,請參閱<在 SharePoint Server 2013 中擴充網際網路網站的搜尋

  • 以伺服器陣列資料庫伺服器為備援,而且使用資料庫鏡像或叢集,可達到資料庫高可用性。

  • 在虛擬環境中,會將虛擬機器設置在獨立的 Hyper-V 主機伺服器中,藉此消除單一失敗點。這項設置虛擬機器的方式係遵照可用性與效能的最佳作法指引。

  • 將涵蓋兩部虛擬化主機電腦的主要資料庫伺服器 (標示為 1) 和機架 2 (標示為 2) 識別為容錯網域,以顯示如何將伺服器陣列和基礎結構視為一個容錯網域集合。此方式顯示您可以如何深入分析環境,以便研擬完整策略和成本效益分析。

其他伺服器陣列角色和服務

我們的範例不包含可能在特定 SharePoint 伺服器陣列中執行的所有角色、服務以及服務應用程式。您無法針對 SharePoint 伺服器陣列的一切使用一般方式達到高可用性。部分可使用標準方式達到高可用性的重要排除如下:

在設計出支援高可用性角色和工作量的架構後,您可以使用容錯元件提升可用性。容錯解決方案適用於整個基礎結構,其中包括資料庫。

容錯功能幾乎隨時適用於 SharePoint 伺服器陣列基礎結構中的每個硬體元件。請在您的高可用性設計中,從運作和成本觀點決定應具備容錯功能的基礎結構部分。由於您可以讓基礎結構各個部分都具備容錯功能,但不表示一定需要如此。

因為 SharePoint 平台和其應用程式工作量取決於可用性及可靠性,所有 SharePoint 資料庫、 高可用性資料庫的高可用性策略的變得極為重要環節。您可以使用為容錯解決方案的下列功能的 SharePoint 資料庫伺服器和資料庫:

  • SQL Server 容錯移轉叢集 (SQL Server 2012 中的 AlwaysOn 容錯移轉叢集執行個體 (FCI))

  • SQL Server 高可用性資料庫鏡像

  • AlwaysOn 可用性群組

重要事項 重要事項:
SQL Server 2012 AlwaysOn 僅適用於 SQL Server 企業。

關於 AlwaysOn 容錯移轉叢集執行個體和 AlwaysOn 可用性群組

容錯移轉叢集在兩部電腦之間需要有共用的磁碟儲存體。在兩個設定節點中,會將這兩部電腦設定為主動/被動,以便提供主要節點的完整備援執行個體。只有在主要節點失敗時,被動節點才會上線運作。共用磁碟一次只會顯示給一部電腦。此設定通常需要大部分的其他硬體。在 SQL Server 2012 中,這類的叢集設定即是一個 AlwaysOn 容錯移轉叢集執行個體,而且是安裝 SQL Server 的一項特定方式。由於設定需求關係,您無法採用標準的 SQL Server 安裝並輕鬆地將其變更成容錯移轉叢集執行個體。

AlwaysOn 可用性群組是 SQL Server 2012 中的另一項技術 (將其視為資料庫鏡像的下階),並採用 Windows 叢集公開的部分功能。不過此技術並不需要共用磁碟儲存體,而且可用性群組中的電腦不必安裝 SQL Server 的特定設定。資料庫伺服器新增至 Windows 叢集後,便可相當輕鬆地啟用 AlwaysOn 可用性群組,接著再設定需要的可用性群組。

在 [摘要] 執行SQL Server 2012 Enterprise Edition 的任何伺服器然後可以使用 AlwaysOn 可用性群組加入叢集設定可用性群組。AlwaysOn 容錯移轉叢集需要特殊的硬體和設定容錯移轉叢集執行個體的設定步驟。每個這些技術及其使用特定的環境中,且兩者都是免費競爭者。如需這些功能的詳細資訊,請參閱Microsoft SQL Server AlwaysOn 解決方案指南的高可用性和嚴重損壞修復

重要事項 重要事項:
由於每個 SQL Server 高可用性選項有其專屬功能、優勢及缺點,因此單一選項不見得會比其他選項卓越。舉例來說,在使用 AlwaysOn 可用性群組的指定狀況中,比起 AlwaysOn 容錯移轉叢集執行個體所能獲得的效能,將資料遺失情形降到最低可能會更加妥當。您必須依據業務需求和 IT 基礎結構需求選擇高可用性解決方案。

選擇要使用的 SQL Server 選項之決定性要素便是 SharePoint 資料庫。您必須了解 SharePoint 2013 資料庫的特性。每個資料庫的特定需求或限制將決定 SQL Server 容錯解決方案是否適合或完全支援您的實際執行環境。建議您閱讀下列文章:

容錯移轉叢集可為 SQL Server 2008 R2 Service Pack 1 (SP1) 或 SQL Server 2012 的 SQL Server 執行個體提供可用性支援。

注意事項 附註:
SQL Server 容錯移轉叢集已重新命名為 SQL Server 2012 的 AlwaysOn 容錯移轉叢集執行個體 (FCI)。為了簡化,容錯移轉叢集一詞適用於 SQL Server 2008 R2 Service Pack 1 (SP1) 中的 SQL Server 容錯移轉叢集或 SQL Server 2012 中的 AlwaysOn FCI。

容錯移轉叢集結合了一或多項節點或伺服器,以及二或多個共用磁碟。雖然容錯移轉叢集的執行個體會顯示為單一電腦,但如果目前節點無法使用,該執行個體也可在各節點之間提供容錯移轉。SharePoint 2013 可在執行於 SQL Server 支援叢集中的各種主動和被動節點組合。

SharePoint 2013 將此叢集視為單一個體。因此從 SharePoint 2013 的觀點來看,容錯移轉為自動而且一致。

注意事項 附註:
從一個叢集節點轉換到另一個時,若發生計劃或非計劃的容錯移轉,會造成連線中斷且必須重新建立連線。

如需 SQL Server 容錯移轉叢集的相關詳細資訊,請參閱下列文章:

SQL Server AlwaysOn 可用性群組和 SQL Server 資料庫鏡像的關鍵優勢在於,這兩者都能夠依據處理交易時的設定方式,提供完整或幾乎完整的資料備援。除了將資料遺失情形降到最低之外,自動容錯移轉也可降低實際執行資料庫的停機時間。

重要事項 重要事項:
雖然 SQL Server 2012 支援資料庫鏡像,但此功能已遭取代。建議您在新的開發工作中避免使用此功能,並規劃變更目前使用此功能的應用程式。請使用 AlwaysOn 可用性群組。

AlwaysOn 可用性群組

SQL Server AlwaysOn 可用性群組的特色在於是一項能夠為資料庫鏡像提供企業級替代方案的高可用性和災害復原解決方案。AlwaysOn 可用性群組支援容錯移轉環境,適用於涵蓋在使用者定義集合中的一或多個使用者資料庫。此集合 (即可用性群組) 包含下列要素:

  • 複本,此為一組名稱為可用性資料庫的離散使用者資料庫,可當成單一單位處理。每個可用性群組都支援一個主要複本且最多可支援四個次要複本。

  • SQL Server 的特定執行個體,可主控每個複本以及維護每個隸屬於可用性群組之資料庫的本機複本。

當可用性群組容錯移轉至目標執行個體或目標伺服器時,群組中的所有資料庫也會進行容錯移轉。因為 SQL Server 2012 可以在單一伺服器上主控多個可用性群組,所以您可以將 AlwaysOn 設定為容錯移轉至不同伺服器上的 SQL Server 執行個體。 這樣能夠減少閒置高效能待命伺服器來處理完全載入主要伺服器的需求,此為可用性群組的許多優點之一。

注意事項 附註:
資料庫問題 (例如,因為資料檔遺失、資料庫刪除或交易記錄毀損而變成有疑問的資料庫 ) 不會導致容錯移轉。

如需有關優點 AlwaysOn 可用性群組和 AlwaysOn 可用性群組詞彙的概觀,請參閱AlwaysOn 可用性群組 (SQL Server)

資料庫鏡像

資料庫鏡像以保有主要資料庫伺服器中資料庫鏡像複本的方式,提供資料庫備援。鏡像會在每個資料庫上執行,而且只會搭配採用完整復原模式的資料庫使用。

注意事項 附註:
鏡像作業模式共有兩種。其中一個是支援同步作業的高安全性模式。在高安全性模式下,當工作階段開始時,鏡像伺服器會儘快同步處理鏡像資料庫和主體資料庫。一旦資料庫同步處理完畢後,交易就會寫入次要伺服器的記錄中並重新執行。(一旦強化交易後,控制項就會返回主體伺服器。) 另一個鏡像模式是高效能,採用非同步作業減少交易延遲,但可能增加資料遺失情形。

若是 SharePoint 伺服器陣列中的高可用性鏡像,您必須使用具備自動容錯移轉功能的高安全性模式。高安全性資料庫鏡像需要三種伺服器執行個體:主體、鏡像及見證。見證伺服器可讓 SQL Server 從主體伺服器自動容錯移轉至鏡像伺服器。從主體資料庫容錯移轉至鏡像資料庫通常需要幾秒的時間。

如需資料庫鏡像的一般資訊,請參閱資料庫鏡像

重要事項 重要事項:
設定使用 SQL Server FILESTREAM 遠端 BLOB (二進位大型物件) 儲存提供者的資料庫無法使用鏡像。

會針對高可用性和資料復原選用 SQL Server 技術,應該是依據組織對於目標復原時點 (RPO) 和目標復原時間 (RTO) 的業務目標而選。雖然 RPO 和 RTO 通常與災害復原有關,但部分失敗事件則不屬於災害範圍,而是需要從主體資料中心的本機備份媒體中復原。

重要事項 重要事項:
根據特定資料庫,各種 SharePoint 2013 資料庫僅支援特定的 SQL Server 高可用性選項。如需詳細資訊,請參閱<SharePoint 資料庫支援的高可用性和災害復原選項 (SharePoint 2013)>。

下表依據 SQL Server 可用解決方案能達到的 RPO 和 RTO 結果提供一般比較。

注意事項 附註:
下表中的時間是為了比較資料庫選項。在實際情況中,所有時間會依據工作量、資料磁碟區及容錯移轉程序而定。

依據資料庫技術比較 RPO 和 RTO

SQL Server 解決方案 可能遺失資料 (RPO) 可能復原時間 (RTO) 自動容錯移轉 可讀取次要
重要事項 重要事項:
SharePoint 2013支援可讀取次要複本執行階段使用狀況若安裝 SharePoint 2013 年 4 月累計更新 (CU) 套件或更好。如需詳細資訊,請參閱2014 年 4 月的 Office 2013 累計更新。請參閱在 SharePoint 2013 中執行使用唯讀資料庫的伺服器陣列

AlwaysOn 可用性群組 (同步認可)

0 - 2

AlwaysOn 可用性群組 (非同步認可)

分鐘

0 - 4

AlwaysOn 容錯移轉叢集執行個體

不適用

FCI 本身不具備資料保護功能。資料遺失量需視儲存系統實作而定。

秒至分鐘

不適用

資料庫鏡像 - 高安全性 (同步模式 + 見證伺服器)

不適用

資料庫鏡像 - 高效能 (非同步模式)

分鐘

不適用

備份、複製、還原

若失敗後可存取記錄結尾,則為數小時或零。

數小時至數天

還原時沒有

比較 SQL Server 叢集、AlwaysOn 可用性群組及資料庫鏡像

  SQL Server 容錯移轉叢集 SQL Server 2012 AlwaysOn 可用性群組 SQL Server 高可用性鏡像

容錯移轉時機

失敗後叢集成員幾乎會立即接管。當叢集節點加速時,會發生延遲。

失敗後複本幾乎會立即接管。當次要複本加速時,會發生延遲。

一旦處理重做佇列,鏡像就會接管。

交易一致性

交易並行

復原時機

比起可用性群組,復原時間更短。

比起容錯移轉叢集,復原時間更長,但比起鏡像解決方案,復原時間更快。

比起叢集或可用性群組,復原時間稍長。

容錯移轉所需採取的步驟

資料庫節點自動偵測失敗。

SharePoint 2013 參考叢集,因此容錯移轉一致且自動。

可用性群組接聽程式會自動偵測失敗,且容錯移轉一致且自動。

資料庫會自動偵測失敗。

SharePoint 2013 設定正確時會知曉鏡像位置,則容錯移轉屬於自動。

提供保護,避免失敗儲存

容錯移轉叢集本身不具備資料保護功能。資料遺失量需視儲存系統實作而定。例如 SAN 環境有多個檔案路徑、RAID 及熱備用等備援要素。

提供保護,避免失敗儲存,原因是主要複本會寫入次要複本中的本機磁碟。

提供保護,避免失敗儲存,原因是主體和鏡像資料庫伺服器會寫入本機磁碟。

支援的儲存類型

需要比專屬儲存更為昂貴的共用儲存。

可使用較不昂貴的直接附加儲存解決方案。

可使用較不昂貴的直接附加儲存。

位置需求

叢集成員必須位於相同子集。

注意事項 附註:
這不適用於 SQL Server 2012。

只要延遲不會造成效能問題,複本便可位於不同子集。

主體、鏡像及見證伺服器必須位於同一個 LAN (來回最高達 1 毫秒延遲)。

復原模式

建議使用 SQL Server 完整復原模式。您可以使用 SQL Server 簡易復原模式。不過如果叢集遺失,唯一可用的復原點將是上次的完整備份。

需要 SQL Server 2012 完整復原模式。

需要 SQL Server 完整復原模式。

效能負荷

進行容錯移轉時,可能會發生效能降低情形。容錯移轉時伺服器將會無法使用,而連線也會中斷,因此請於新主動節點中重新建立。

由於次要複本上有同步認可,因此 AlwaysOn 可用性群組會存有交易延遲。延遲量會依據必須進行同步處理的次要複本量而定。

記憶體和處理器負荷大於叢集,但小於鏡像,

高可用性鏡像因為同步,所以存有交易延遲,同時也需要額外記憶體和處理器負荷。

作業負荷

設定並維持在伺服器等級。

作業負荷大於叢集和鏡像。除了 Windows Server 等級,AlwaysOn 還需要 SQL Server 資料庫伺服器等級的負荷。

注意事項 附註:
登入和代理程式工作等伺服器等級物件必須手動維護。

如果新增內容資料庫,必須將其新增至可用性群組,並將主要複本同步處理至次要複本。

SharePoint 伺服器陣列環境需要多個設定步驟,才能確保 SharePoint 2013 連線字串與可用性群組接聽程式名稱建立正確關聯。

作業負荷大於叢集。必須設定及維護所有資料庫。容錯移轉後手動重新設定。

注意事項 附註:
登入和代理程式工作等伺服器等級物件必須手動維護。

如果新增內容資料庫,必須將其新增至主體,並將主體同步處理至鏡像。

有些企業的各資料中心位置非常接近,並透過高頻寬光纖連結加以連接。當這類環境可供使用時,就可能將兩個資料中心設為單一伺服器陣列。這樣的分散式伺服器陣列拓撲稱為「延伸的」伺服器陣列。

若要將延伸的伺服器陣列架構當作支援的高可用性解決方案使用,必須符合下列前提:

  • <1ms (單向) 擁有高度一致的內部伺服器陣列延遲,有 99.9% 的時間超過十分鐘。(內部伺服器陣列延遲通常定義為前端網頁伺服器和資料庫伺服器之間的延遲。)

  • 頻寬速度必須至少每秒 1 Gigabit。

如要提供延伸伺服器陣列的容錯能力,請使用標準最佳作法指導設定備援服務應用程式和資料庫。

下列圖例顯示延伸的伺服器陣列。

延伸的伺服器陣列

使用兩個資料中心來提供高可用性的延伸伺服器陣列拓撲。

您的高可用性策略必須包含適當的備份和還原作業,方可確保 SharePoint 伺服器陣列的靈活度。發生媒體失敗或使用者錯誤等事件時,必須能夠即時還原伺服器陣列環境或伺服器陣列資料中受影響的部分。有效的備份和還原解決方案應該能夠讓您達到定義的目標復原時間 (RTO) 和目標復原時點 (RPO)。

如需詳細資訊,請參閱<備份及還原 SharePoint 2013>。

https://technet.microsoft.com/zh-tw/library/ff628971.aspx
顯示: