受管理的可用性

適用于：Exchange Server 2013 SP1

確保使用者具有良好的電子郵件經驗一直是郵件系統管理員的主要目標。 為了協助確保 Microsoft Exchange Server 2013 組織的可用性和可靠性，您必須主動監控系統的各個層面，並快速解決任何偵測到的問題。 在舊版 Exchange 中，監控重要系統元件通常包括使用外部應用程式 (例如 Microsoft System Center 2012 Operations Manager) 來收集資料，以及針對因分析所收集資料而偵測到的問題提供復原動作。 Exchange 2010 及舊版已在管理組件中包含了健康情況資訊清單及關聯性引擎。 這些元件讓 Operations Manager 能做出有關特定元件健康情況是否良好的判斷。 此外，Operations Manager 也使用內建於 Exchange 2010 的診斷 Cmdlet 基礎結構，對系統的各個層面執行綜合交易。

Exchange 2013 會使用稱為「受控 可用性 」的功能，以原生方式監視和保留使用者體驗的新方法，該功能提供內建的監視和復原動作。

受控可用性也稱為 主動監視 或 本機主動監視，是內建監視和復原動作與 Exchange 高可用性平臺的整合。 其設計目的是在問題發生時立即偵測並從中復原，並由系統探索到。 不同于 Exchange 先前的外部監視解決方案和技術，受控可用性不會嘗試識別或傳達問題的根本原因。 而是著重于解決使用者體驗三個主要區域的復原層面：

• 可用性：使用者可以存取服務嗎？
• 延遲：使用者的體驗如何？
• 錯誤：使用者是否能夠完成他們想要的作業？

要在 Exchange 2013 中進行伺服器角色合併及其他架構變更，需要有新的方法來處理舊版 Exchange 中使用的監控方法和健康情況模型。 受管理的可用性就是設計來因應這些改變，其方式是提供原生的健康情況監控及復原解決方案。 它不再只是監控個別系統切片，而是監控端對端使用者經驗，並透過復原導向的動作來保護使用者經驗。

受控可用性是在每個 Exchange 2013 伺服器上執行的內部程式。 它會每秒輪詢並分析數百個健康情況計量。 如果發現錯誤，大部分時候都會自動修正。 但一律會有 Managed 可用性無法自行修正的問題。 在這些情況下，受控可用性會透過事件記錄向系統管理員呈報問題。

受管理的可用性以下列兩種服務形式實作：

• Exchange Health Manager 服務 (MSExchangeHMHost.exe) ：此服務是用來管理背景工作進程的控制器進程。 It's used to build, execute, and start and stop the worker process, as needed. It's also used to recover the worker process in case that process fails, to prevent the worker process from being a single point of failure.

• Exchange Health Manager 背景工作進程 (MSExchangeHMWorker.exe) ：此服務是負責在受控可用性架構內執行執行時間工作的背景工作進程。

受管理的可用性使用持續性儲存空間以執行其功能：

• \bin\Monitoring\config 資料夾中的 XML 檔案可用來儲存某些探查和監視器工作項目的組態設定。
• Active Directory 可用來儲存全域覆寫。
• Windows 登錄可用來儲存執行階段資料 (例如書籤) 以及本機 (伺服器特定) 覆寫。
• Windows Crimson Channel 事件記錄檔基礎結構用於儲存工作項目結果。
• 健康情況信箱可用於探查活動。 位於伺服器上的每個信箱資料庫上，將會建立多個健康情況信箱。

如下圖所示，受管理的可用性包括三個主要的非同步元件，這些元件會持續不斷地運作。

第一個元件稱為 探查。 探查負責在伺服器上進行測量並收集資料。 這些度量的結果會流入第二個元件 ：監視器。 監視器會根據所收集的資料，依據健全狀況列出系統使用的所有商務邏輯。 與模式識別引擎類似，監視器會尋找所有收集到的測量資料上的各種不同模式，接著判斷某個項目是否應視為健全。 最後，有回應 者負責復原和呈報動作。 若某個元件狀況不良，第一個動作就是嘗試復原該元件。 此復原工作可能包含多階段復原動作;例如，第一次嘗試是重新開機應用程式集區，第二次嘗試是重新開機服務，第三次嘗試是重新開機伺服器，而後續的嘗試可能是讓伺服器離線，使其不再接受流量。 若復原動作不成功，系統將透過事件記錄檔通知將問題呈報給使用者。

探查有三個主要類別：週期性探查、通知和檢查。 週期性探查是由系統執行的綜合交易，用來測試端對端使用者體驗。 檢查是執行效能資料收集的基礎結構，包括使用者流量，並根據設定來判斷使用者失敗尖峰的閾值來測量收集的資料。 此度量功能可讓檢查基礎結構在使用者遇到問題時變得察覺。 最後是通知邏輯，可讓系統依據關鍵事件立即採取行動，而不用等候透過探查所收集資料的結果。 您可以偵測和辨識這些例外狀況或條件，而不需要大型範例集。

週期性探查會每隔幾分鐘執行一次，並檢查服務健康情況的某些層面。 這些探查可能會透過Exchange ActiveSync傳送電子郵件至監視信箱、可能連線到 RPC 端點，或是確認用戶端存取至信箱連線能力。

所有探查都是在 Microsoft.Exchange.ActiveMonitoring\ProbeDefinition crimson 通道的 Health Manager 服務啟動時定義。 每個探查定義都有許多屬性，但最相關的屬性如下：

• 名稱：探查的名稱，以探查監視器的 SampleMask 開頭。
• TypeName：探查的程式碼物件類型，其中包含探查的邏輯。
• ServiceName：包含此探查的健康情況集名稱。
• TargetResource：探查正在驗證的物件。 當探查執行為成為探查結果ResultName時，此屬性名稱會附加至探查的名稱
• RecurrenceIntervalSeconds：探查執行的頻率。
• TimeoutSeconds：探查會在失敗前等待多久時間。

有數百個週期性探查。 這些探查中有許多是每個資料庫，因此隨著資料庫數目的增加，探查數目也會增加。 大部分探查都是在程式碼中定義，因此無法直接探索。

週期性探查的基本概念如下：啟動每個 RecurrenceIntervalSeconds ，並檢查 (或探查) 健康情況的某些層面。 如果元件狀況良好，探查會傳遞資訊事件，並將其寫入至 ResultType 為 3 的 Microsoft.Exchange.ActiveMonitoring\ProbeResult 通道。 如果檢查失敗或逾時，探查會失敗，並將錯誤事件寫入相同的通道。 ResultType為 4 表示檢查失敗，而 ResultType為 1 表示其逾時。許多探查會在逾時時時重新執行，最多可達MaxRetryAttempts屬性的值。

通知是不是由健全狀況管理員架構所執行，而是由伺服器上的一些其他服務所執行的探查。 這些服務會執行自己的監視，然後直接寫入探查結果，將其資料摘要至受控可用性架構。 您不會在 ProbeDefinition 通道中看到這些探查，因為此通道只會描述受控可用性架構將執行的探查。 例如，ServerOneCopyMonitor 監視器是由 MSExchangeDAGMgmt 服務所撰寫的探查結果所觸發。 此服務會執行自己的監視、判斷是否有問題，並記錄探查結果。 大部分的通知探查都能夠記錄會使監視器狀況不良的紅色事件，以及讓監視器再次狀況良好的綠色事件。

檢查是僅在效能計數器超過或低於定義閾值時記錄事件的探查。 它們實際上是通知探查的特殊案例，因為有服務會監視伺服器上的效能計數器，並在符合設定的閾值時將事件記錄到 ProbeResult 通道。

若要尋找視為狀況不良的計數器和閾值，您可以查看監視器以進行這項檢查。 Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueAboveThresholdMonitor或Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueBelowThresholdMonitor類型的監視器表示他們所監看的探查是檢查探查

監視器會查詢透過探查所收集的資料，根據預先定義的規則集，判斷是否需採取動作。 依規則或問題本質而定，監視器可以啟動回應程式，或透過事件記錄檔項目將問題呈報給人員。 此外，監視器會定義在失敗後執行回應程式的時間，以及復原動作的工作流程。 監視器具有多種狀態。 從系統狀態的角度來看，監視器有兩種狀態：

• 狀況良好：監視器正常運作，且所有收集到的計量都在一般作業參數內
• 狀況不良：監視器狀況不良，且已透過回應者起始復原，或透過呈報通知系統管理員。

從系統管理的觀點來看，監視器具有更多出現在殼層中的狀態：

• 已降級：當監視器處於 0 到 60 秒的狀況不良狀態時，會被視為已降級。 If a monitor is unhealthy for more than 60 seconds, it is considered Unhealthy.
• 已停用：系統管理員已明確停用監視器。
• 無法使用：Microsoft Exchange Health 服務會定期查詢每個監視器的狀態。 如果查詢無法取得回應，監視器狀態就會成為「無法使用」。
• 修復：系統管理員會設定修復狀態，向系統指出修正動作正由人類處理中，這可讓系統和人類區分在採取更正動作的同時可能發生的其他失敗， (例如資料庫複製重新儲存作業) 。

每個監視器在其定義中都有 SampleMask 屬性。 當監視器執行時，它會在 ProbeResult 通道中尋找結果 名稱 符合監視器 SampleMask的事件。 這些事件可能來自週期性探查、通知或檢查。 如果達到監視器的臨界值，它就會變成狀況不良。 從監視器的觀點來看，這三種探查類型都與每個登入 ProbeResult 通道的類型相同。

值得注意的是，單一探查失敗不一定表示伺服器發生問題。 這是監視的設計，可正確識別何時有需要修正的實際問題。 因此，許多監視器在變成狀況不良之前，都有多個探查失敗的臨界值。 即便如此，回應者還是可以自動修正上述許多問題，因此尋找需要手動介入問題的最佳位置是在 Microsoft.Exchange.ManagedAvailability\Monitoring crimson 通道中。 此通道包含最新的探查錯誤。

顧名思義，回應程式會對監視器產生的警示執行某種回應。 回應者會採取各種復原動作，例如將應用程式背景工作角色集區重設為重新啟動伺服器。 回應程式有多種類型：

• 重新開機回應程式：終止並重新啟動服務
• 重設 AppPool 回應程式：停止並重新啟動 Internet Information Services 中的應用程式集區 (IIS)
• 容錯移轉回應者：起始資料庫或伺服器容錯移轉
• 錯誤檢查回應程式：起始伺服器的錯誤檢查，因而導致伺服器重新開機
• 離線回應者：將伺服器上的通訊協定移出服務 (拒絕用戶端要求)
• 線上回應者：將伺服器上的通訊協定放回生產環境 (接受用戶端要求)
• 呈報回應者：透過事件記錄向系統管理員呈報問題

除了上述所列的回應程式，某些元件也有獨有的專用回應程式。

所有回應者都包含節流行為，其提供內建的排序機制來控制回應者動作。 節流行為的設計目的是要確保系統不會因為回應程式的復原動作而洩漏資料或惡化。 所有回應程式都以某種方式節流。 節流發生時，可能會略過或延遲回應程式的復原動作 (視回應程式的動作而定)。 例如，對檢查錯誤回應程式執行節流時，會略過其動作，但不會延遲。

健全狀況集合

從報告的觀點來看，受管理的可用性有兩個健康情況檢視，一個內部，一個外部。 內部檢視會使用 健全狀況集合。 Exchange 2013 中的每個元件 (例如 Outlook Web App、Exchange ActiveSync、Information Store 服務、內容索引、傳輸服務等等) 是由受管理的可用性使用探查、監視器及回應程式來監控。 指定元件的探查、監視和回應程式群組稱為 健康情況集。 健全設定是探查、監視器及回應程式的群組，可判斷該元件健康情況是否良好。 例如，健康情況集的目前狀態 (，其狀況良好或狀況不良) 是使用健全狀況集監視器的狀態來決定。 如果健全設定的監視器健康情況全都良好，則健全設定便是處於良好狀態。 如果有任何監視器不在良好狀態，則健全設定的狀態會以健康情況最差的監視器來決定。

如需檢視伺服器健康情況或健康情況集狀態的詳細步驟，請 參閱管理健全狀況集和伺服器健康情況。

健康情況群組

受控可用性的外部檢視是由 健康情況群組所組成。 健康情況群組會公開給 System Center Operations Manager 2007 R2 和 System Center Operations Manager 2012。

有四個主要的健康情況群組：

• 客戶觸控點：影響即時使用者互動的元件，例如通訊協定或資訊存放區
• 服務元件：沒有直接、即時使用者互動的元件，例如 Microsoft Exchange 信箱複寫服務，或 OABGen (離線通訊錄產生程式)
• 伺服器元件：伺服器的實體資源，例如磁碟空間、記憶體和網路
• 相依性可用性：伺服器能夠存取必要的相依性，例如 Active Directory、DNS 等。

安裝 Exchange 管理元件時，System Center Operations Manager (SCOM) 作為健康情況入口網站，以檢視與 Exchange 環境相關的資訊。 SCOM 儀表板包含三個 Exchange 伺服器健康情況檢視：

• 作用中警示：呈報回應者會將事件寫入 SCOM 內監視器所取用的 Windows 事件記錄檔。 這些事件會在 [作用中警示] 檢視中顯示為警示。
• 組織健康情況：此檢視會顯示 Exchange 組織健康情況整體健康情況的匯總摘要。 這些彙總內容包括顯示個別資料庫可用性群組的健康情況，以及特定 Active Directory 網站內的健康情況。
• 伺服器健康情況：相關的健全狀況集合會合並成健康情況群組，並在此檢視中摘要說明。

覆寫

覆寫讓系統管理員能夠設定受管理可用性的探查、監視器及回應程式的某些方面。 覆寫可用來微調某些受管理可用性所使用的臨界值。 覆寫也可用來為可能需要與現成可用預設值不同之組態設定的未預期事件啟用緊急動作。

您可以建立覆寫並套用至單一伺服器 (此程式稱為 伺服器覆 寫) ，或者可以套用至伺服器群組 (此程式稱為 全域覆 寫) 。 伺服器覆寫組態資料會儲存在套用覆寫的伺服器 Windows 登錄中。 全域覆寫組態資料則儲存在 Active Directory 中。

覆寫可以設定為無限期地執行下去，或是設定為在特定持續時間內執行。 此外，全域覆寫可以設定為套用到所有伺服器，或是只套用到執行特定 Exchange 版本的伺服器。

當您設定覆寫時，它不會立即生效。 Microsoft Exchange 健全狀況管理員服務每 10 分鐘會檢查一次是否有更新的組態資料。 此外，全域覆寫會依存於 Active Directory 複寫延遲。

如需檢視或設定伺服器或全域覆寫的詳細步驟，請參閱 設定受控可用性覆寫。

管理工作和 Cmdlet

關於受管理的可用性，系統管理員通常會執行三個主要的操作工作：

• 擷取或檢視系統健康情況
• 檢視健全設定以及關於探查、監視器及回應程式的詳細資料
• 管理覆寫

受管理可用性的兩個主要管理工具分別是 Windows 事件記錄檔和命令介面。 受管理可用性會在 Exchange ActiveMonitoring 和 ManagedAvailability Crimson 通道事件記錄檔中記錄大量資訊，例如：

• 探查、監視和回應器定義，這些定義會記錄在個別的 *Definition 事件記錄檔中。
• 探查、監視和回應器結果，這些結果會記錄在個別的 *Results 事件記錄檔中。
• 關於回應程式復原動作的詳細資料，包括復原動作的啟動時間，以及視為完成 (不論成功與否)，這些資訊記錄在 RecoveryActionResults 事件記錄檔中。

有 12 個 Cmdlet 用於受管理的可用性，如下表所述。