高可用性策略

適用版本： Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

上次修改主題的時間： 2007-08-31

本主題廣泛概述 Microsoft Exchange Server 2007 的高可用性。本主題也介紹為組織選擇最適合的可用性解決方案時建議的決策過程。

根據使用的環境與對象，「可用性」及「高可用性」這兩個術語的意義可能有很大的差別。這兩個術語可用來表達各種商業目標及技術需求，從僅限硬體的可用性目標到整個郵件服務的關鍵目標，全部涵括在內。

一般而言，組織很容易會對可用性目標有不適當的預期。而組織在了解成本意涵之前，也很容易要求高於實際願意付費之層級的可用性。

大多數可用性解決方案的成本意涵包括 (但不限於)：

• 硬體

• 軟體

• 網路基礎結構

• 訓練

• 服務性

• 作業成本

服務性是指與協力廠商服務提供者所訂定的契約協議，或與組織內的資訊技術部門所訂定的作業層級合約，用以提供或維護資訊技術服務或元件。

可用性

可用性指的是應用程式、服務或系統所提供的服務層級。高可用系統比較不會發生計畫性或未計畫性停機的情況。可用性通常是以服務或系統可用的時間百分比表示，例如，99.9% 代表每年會有 8.75 小時無法使用服務。

為了改善可用性，您必須執行容錯機制，以避免或降低服務的元件和相依關係失敗所造成的影響。容錯是透過執行單一失敗點元件的備援來達成。

規劃 Microsoft Exchange 可用性時，請考慮所有屬於郵件基礎結構的元件。部分元件也可以是其他具有子元件的服務。郵件服務可用性是取決於基礎結構所屬之每個元件的可用性。

定義可用性需求

服務的可用性是跨越許多準則的複雜問題。您可以採用許多不同的方式來達到必要的可用性層級，而每個都有它們自己的成本意涵。

然而，客戶通常會以相當簡單的術語來表示可用性需求，而未完整了解其意涵。此狀況會導致客戶與資訊技術組織之間的誤解以及投資層級失當，最終造成客戶不滿意當初所設定的預期。

兩個都表示 99.5% 的可用性需求可能會有不同的意義。其中一個需求所討論的，可能只是硬體平台的可用性，而另一個需求可能討論的，則是完整端對端服務的可用性。甚至，完整端對端服務可用性的定義也會有明顯地不同。重要的是確實了解如何測量所有可用性需求。例如：

• 如果主要伺服器上的所有軟硬體都正確運作，而應用程式也準備好接受使用者連線，則解決方案視為 100% 可用嗎？

• 如果有 100 位使用者，但是其中的 25% 因區域網路失敗而無法連線，則解決方案仍然視為 100% 可用嗎？

• 如果 100 位使用者中只有一位使用者可以連線並處理工作，則解決方案的可用性就是只有 1% 嗎？

• 如果所有 100 位使用者都可以連線，但是服務因為三個客戶交易中只有兩個交易可用而降低，或效能不佳，則這對可用性測量的影響程度為何？

測量可用性的期間也會對可用性定義有明顯的影響。歷時一年的 99.9% 可用性需求允許有 8.75 小時的停機時間。而每四週一期的 99.9% 可用性需求只允許每期有 40 分鐘的停機時間。

另外，也需要識別及交涉計劃性維護活動、Service Pack 更新及軟體更新的停機期間。可以容忍的計劃性停機數量會對可用性需求定義有明顯的影響。

Exchange Server 2007 的量產發行 (RTM) 版本包含可降低成本和加長運作時間的新功能：

• 本機連續複寫 本機連續複寫是單一伺服器解決方案，它使用內建的技術，在第二組磁碟 (與生產儲存群組連接至相同伺服器) 上建立並維護儲存群組的副本。LCR 提供非同步記錄傳送、記錄重新顯示，以及快速地手動切換至資料副本。如需 LCR 的相關資訊，請參閱本機連續複寫。

• 叢集連續複寫 叢集連續複寫 (CCR) 結合了 Exchange 2007 中的複寫及重新顯示功能與 Microsoft 叢集服務中的容錯移轉功能。CCR 是一種可在單一資料中心或兩個資料中心之間部署的解決方案，不會發生單一失敗點。如需 CCR 的相關資訊，請參閱叢集連續複寫。相較於舊版 Exchange Server 中的叢集及 Exchange 2007 中的單一副本叢集，CCR 提供了更多的優點。如需這些優點的詳細資料，請參閱透過單一副本叢集之叢集連續複寫的優點。

• 單一副本叢集 單一副本叢集 (SCC，在舊版 Exchange Server 中稱為共用儲存叢集) 存在於 Exchange 2007，而且有一些重大的變更及改善。如需 SCC 的相關資訊，請參閱單一副本叢集。

Microsoft Exchange Server 2007 Service Pack 1 (SP1) 新增另一個功能來提供站台回復性：

• 待命連續複寫   待命連續複寫 (SCR) 是 Exchange 2007 SP1 中引進的一項新功能。顧名思義，SCR 是為使用或啟用待命修復伺服器的情況而設計的。SCR 延伸現有的連續複寫功能，並且為 Exchange 2007 Mailbox Server 提供新的資料可用性案例。SCR 也會利用 LCR 及 CCR 所使用的相同記錄傳送及重新顯示技術，提供新增的部署選項及組態。SCR 可以從獨立 Mailbox Server 和叢集信箱伺服器複寫資料。如需 SCR 的相關資訊，請參閱待命連續複寫。

這些功能提供加強的修復機會，以符合各種可用性需求。下表列出各種可用性需求，並且比較 Exchange 2007 解決方案與 Exchange Server 2003 中的嚴重損壞修復解決方案。如需 Exchange 2007 的高可用性組態的相關資訊，請參閱高可用性部署。

根據可用性需求的高可用性解決方案比較

選擇適當的可用性解決方案

有數個組態可以用來改善 Exchange 2007 部署的可用性。選擇正確的可用性解決方案時，分析選取之選項集合是一個重要的步驟，如此才能判斷哪一個解決方案最符合業務目標與可用性需求。一個作法是建立表格，每個失敗類型佔一個區段。在表格的每個區段中，使用列來識別提供復原策略的每個解決方案 (此策略與失敗的可用性需求一致)。在欄位中記錄解決方案的重要因素。一般的因素為：

• 復原時間

• 復原的資料影響

• 相關的軟硬體成本

• 相關的資源成本

• 事件的可能性

• 對業務的意涵

• 複雜性風險

• 協力廠商解決方案

• 優點

• 缺點

完成這些表格後，請選取幾個解決方案進行成本分析。對於每個選取的解決方案，應算出每個信箱的估計成本 (這也可用表格來呈現)。在成本表格中，請務必提供一列用來表示對照業務目標的解決方案品質特性。請記得要多方評估選擇。至少要選取一個符合需求的解決方案，但又要不同於組織通常會選擇的解決方案。

最後，請檢閱業務目標、可用性需求、可能的解決方案及成本分析，來選取您的解決方案。在這個過程中，請考慮下列重點來進行正確的決策：

• 明確設定一組優先的業務目標   因為不同的目標很可能發生衝突，因此必須設定優先順序。

• 挑戰可能不再適用的過去事實   在設計與評估階段中妥善運用 Exchange 2007。經驗顯示，最划算的解決方案可能需要採取新的備份、儲存及操作方法。

• 檢查郵件系統中的單一失敗點   在單一存放區域網路 (SAN) 上儲存的信箱資料的單一副本，表示無法完全避免資料損毀和失敗的情況。無論 SAN 提供多少備援能力，總是會有各種狀況造成該單一資料副本損毀或失敗。使用 SCC，SAN 失敗可能會使服務遭遇數小時的資料遺失與數日的中斷。CCR 是伺服器失敗發生時可能會遺失部分資料的可用性解決方案，但它也維護兩份資料。CCR 使用一項稱為「傳輸暫放」的 Hub Transport Server 功能，降低伺服器失敗時常見的資料遺失情形。因此，對於大部分的硬失敗情況，均可保留信箱資料。

• 探究每個解決方案可用的儲存選項範圍   CCR 可讓組織選擇使用更多種儲存解決方案，例如直接連接的儲存裝置。CCR 不需要會減少相關的複雜性與成本的 SAN 結構。不論 SAN 或低價儲存解決方案，直接附加儲存都是比較容易部署和操作的選項。

• 考量 CCR 和 LCR 可讓您將備份策略從一般的每日完整備份變更為較不頻繁的完整備份和每日增量策略   對於初次失敗的復原，CCR 和 LCR 也可支援較短的服務等級協定 (SLA)。從雙重失敗 (兩份資料均失敗或損毀) 復原的 SLA 可能需要延長至超過目前的還原 SLA。像這樣的變更可大幅降低擁有權總成本 (TCO)，因為備份成本通常是 TCO 的主要成分。此外，切換至磁碟式備份策略也可降低備份成本。

• 研究在 Exchange 2007 中使用連續複寫技術來建立解決方案   有了 CCR 就不需要協力廠商複寫技術。目前，CCR 支援雙節點叢集，每個節點維護一份資料。採用此技術的站台回復性解決方案有許多好處：

  • 它可確保備份資料中心的信箱資料可供用戶端使用。

  • 連續複寫移動的資料比大部分協力廠商解決方案更少。

  • 建立站台回復性解決方案不需要太多整合。

• 建立表格來了解各種選項的復原行為和相關成本   在成本表格中，請記得加入一些違反現有作法的選項。使用您建立的表格中的事實來設計符合下列條件的解決方案：

  • 提供針對業務需求的最佳解決方案。

  • 滿足成本需求。

  • 表現出組織能夠支援的部署及操作複雜程度。

基本的產品及元件

部署產品與元件，均應根據其功能來滿足迫切的可用性與可靠性需求。請將這些需求視為可用性設計的基石。如果這些基本的產品與元件並不可靠且容易故障，則為達到更高之可用性等級所需的額外投資就會變成浪費，且無法達到可用性等級。

服務管理程序

有效的服務管理程序有助於達成更高的可用性等級。可用性管理、事件管理、問題管理及變更管理之類的程序，在整個郵件服務管理中扮演著重要的角色。

系統管理

系統管理應提供監視、診斷及自動錯誤修復，以便迅速偵測並解決可能與實際的失敗。

具有完全備援的特定解決方案

若要達到 100% 的持續可用性，需要有包含完全備援的昂貴解決方案。備援是使用重複元件來改善可用性的技術。為了符合迫切的可用性需求，這些元件必須可以平行地自主運作。

建立可用性目標和 SLA 需求

達到高可用性等級的第一步是部署品質良好的產品與元件。不過，單靠這些產品與元件，不可能持續提供所需的可用性等級。您應盡可能地在開發階段早期，就將設計程序中的可用性目標納入考慮。此方法可避免可能會因重新作業而導致成本提高、為符合必要可用性所需的非計劃性升級、要用以監視基礎結構的非計劃性工具、為消除基礎結構、維護性及服務性中單點失敗的非計劃性支出。

達到高可用性的首要步驟之一，就是檢閱您為組織建立的 SLA。建立 SLA 之後，您可以決定最適合該協定的 Exchange 2007 部署及伺服器組態。

下列是高可用性的重要考量，因為它們與嚴重損壞修復相關：

• 允許的停機   根據組織的 Exchange 服務可用性定義，考慮組織可接受的允許停機上限。根據組織的停機定義，您也許能夠藉由使用郵件撥號音復原策略來符合組織的 SLA。郵件撥號音復原策略包括提供您的使用者暫時信箱，以便使用者可以在嚴重損壞之後立即傳送及接收電子郵件。此策略會在復原歷程信箱資料之前迅速還原電子郵件服務。通常，將藉由最終合併歷程及暫時信箱資料來完成復原。

• 允許的復原時間   考慮每一類型的嚴重損壞修復作業所允許的時間上限。例如，您應該指定復原信箱、單一資料庫或正在執行 Exchange 2007 的整個伺服器所需的大約期間。

• 資料遺失容忍度   考慮組織對於暫時或永久遺失 Exchange 資料的容忍度。例如，只要使用者可以在 4 小時的期間內傳送及接收郵件，則組織也許能夠在前次備份之後容忍暫時遺失信箱資料 24 小時。在其他情況下，您可能想要考慮更嚴格的需求，例如要求所有在失敗點之前的 Exchange 資料在 4 小時內還原。

在考慮停機對組織的影響，並決定想要在郵件環境中達成的開機層級之後，可以準備建立 SLA。SLA 需求會決定有多少因素納會入組織中，例如儲存、叢集及備份和復原。

存取 SLA 時，應該先識別一般作業時數及有關計劃衷停機的預期。然後，應該決定公司對於可用性、效能及復原性的預期，包括郵件傳遞時間、伺服器開機百分比、所需的儲存數量，以及復原 Exchange 資料庫的時間。

此外，也應該識別意外停機的預估成本，以便可以提供適當的容錯數量給郵件系統。

Exchange 2007 和 Windows Server 2003 中的功能可能會影響您如何設計組織來符合 SLA。例如，LCR、CCR、SCC、磁碟區陰影複製服務 (VSS)、復原儲存群組、資料庫可攜性及撥號音可攜性功能，都可以讓您挑戰 SLA 先前所設定的限制。

下表列出您可能想要併入 SLA 中的某些類別及特定元素。

典型企業層級 SLA 中的類別及元素

將各種效能測量併入 SLA，可幫助確定您符合使用者的特定效能需求。例如，如果用戶端與信箱伺服器之間有高延遲或低可用頻寬，使用者將檢視與系統管理員不同的效能層級。使用者將特別把效能層級視為不佳，但是系統管理員將把效能視為可接受。因此，請記得監視磁碟輸入/輸出 (I/O) 延遲層級。

附註：
對於每一個 SLA 元素，也須決定特定效能評定，它將用來測量效能以及可用性目標。此外，也須決定您將提供統計資料給資訊技術管理及其他管理的頻率。

與廠商建立服務等級協定

許多重視高可用性解決方案的企業都會使用協力廠商的服務來達成其高可用性目標。在這些情況下，若要達成高可用郵件系統，需要外部軟硬體廠商提供的服務。反應遲鈍的廠商及訓練不佳的廠商人員會降低郵件系統的可用性。

請確定與每一個主要廠商協議 SLA。與廠商建立 SLA 可協助保證郵件系統按規格執行、支援必要的成長，以及可供特定標準使用。若沒有 SLA，會大為增加無法使用郵件系統的時間長度。

重要事項：
請確定您的人員了解每個 SLA 的條款。例如，許多硬體廠商 SLA 都包含若干條款，只允許廠商的支援人員或您組織的認證人員才能開啟伺服器外殼。若未遵守，會導致違反 SLA，因而可能會使任何廠商保固或責任無效。

除了與主要廠商建立 SLA 之外，也應該進行支援要求訓練，定期測試提升程序。若要確認具有最新的連絡資訊，請確定也測試呼叫器及電話樹狀目錄。

可用性的考量

建議您考量下列問題，以判斷可用性需求：

• 了解提出之基礎結構設計發生失敗的弱點。您應確定沒有單點失敗。單點失敗是指郵件基礎結構內不具備援功能，因此在其失敗時可能會影響使用者的任何元件。提出的解決方案技術設計應涵蓋完整的端對端組態。

• 考量業務所需之郵件服務的可用性等級下限，以及郵件基礎架構中各元件之可靠性、維護性及服務性的等級下限。

• 考量測試或模擬新元件以確定其符合特定需求的能力。若要評估設計內的新元件是否符合特定需求，您主導的測試制度應確定可提供預期的可用性。提供元件的服務時也應執行測試。您應認真考量產生新資訊技術服務之預期使用者需求的模擬工具，以確定元件可在大量與壓力狀況下持續運作。

高可用性的考量

高可用性的郵件解決方案需要您投資及部署監視解決方案、服務管理程序、系統管理工具及備援。對於高可用性部署，在此端對端組態內不應存在任何的單點失敗。高可用性的設計必須考量消除單點失敗及提供替代元件，以便在發生元件失敗時，將營運中斷減至最小。設計也必須消除或減少一般在提供維護活動 (例如執行基礎結構變更) 所需之計劃中停機對營運的影響。復原準則應將快速復原與服務恢復定義為要在設計的復原階段進行設計的主要目標。

針對郵件解決方案開發部署計劃時，必須識別解決方案的目標。設計解決方案的可用性特徵時，這點尤其重要。業務目標常常會產生矛盾。例如，可用性目標可能包括 100% 可用性，同時也要求在最新的安全性升級推出一週內套用這些升級。成本通常是形成部署計劃挑戰的另一項因素。遵循識別所有業務需求並對照這些需求來評估可用選項的規劃方法，是識別企業之正確解決方案的最佳方法。

欲成功達成高可用性，需要持續不斷專注於組織的營運作法。您必須了解中斷的所有原因。對於程序變更可防止的中斷，必須開始進行適當的程序變更。

達到最高可用性的另一項關鍵要素，在於是否能主動地監視 Exchange 環境。藉由主動監視，可在系統中的問題區域造成失敗與中斷前予以識別。此外，監視可對操作人員警示系統無法自動復原的問題。在這類狀況中，及時的回應可縮短中斷的持續時間，因而提高可用性。

Exchange 2007 的依存項目在資料中心內的基礎結構上。因此，Exchange 的可用性受限於其依存項目所提供的可用性。建議組織針對每個依存項目建立 SLA。SLA 必須指定提供之服務的可用性及失敗發生時的復原時間。例如，Active Directory 目錄服務是 Exchange 的主要依存項目。若 Active Directory 的可用性低於 Exchange 可用性目標，則 Exchange 就可能無法達到其目標。

Exchange 2007 的可用性取決於資訊技術基礎結構內其他服務的可用性。Active Directory 及網路等服務必須正常運作，Exchange 才能運作。這些服務的可用性會直接影響 Exchange 可用性。因此，您應該確定 Exchange 可用性需求不能高於其依存項目的可用性需求。常見的依存項目清單如下：

• Active Directory

• 網域名稱系統

• TCP/IP 網路

• 儲存子系統

• 備份服務

• 監視服務

• 資料中心基礎結構 (電源與空調)

建立業務目標與 Exchange 依存項目的 SLA 之後，建議您開發郵件服務可用性需求的初始清單。此清單應包含失敗的每個一般類別與預期的復原時間目標 (RTO)。對於資料相關失敗，此清單應包含失敗對資料之影響的指示。這可經由指出復原點目標 (RPO) 來指定。RPO 可藉指定定義復原後可用資料層次的時間來識別資料影響。應考慮的失敗包括：

• 單一郵件項目遺失

• 單一信箱遺失

• 資料庫遺失或損毀

• 磁碟失敗

• 磁碟區失敗或損毀

• 儲存單位失敗

• 伺服器失敗

• 網路連線遺失

• 資料中心失敗

在許多組織中，建立的可用性需求依使用者的類型而有所不同。例如，一些使用者可能會使用郵件系統追蹤送貨或銷售狀況，而另一些則將郵件系統用於不重要的郵件。倚賴郵件系統進行重要程序之使用者的 RTO 和 RPO 必須盡可能短，而使用郵件系統進行不重要之程序的使用者則可容忍較長的 RTO 和 RPO。

相關資訊

如需 Exchange 2007 的站台回復性的相關資訊，請參閱Site Resilience Configurations。