從 Datacenter 學習：Managed Availability

英文原文已於 2012 年 9 月 22 日星期六發佈

監控是成功 Exchange 部署重要的一環。先前發行的版本，我們投入了大量資金發展相互關聯引擎，並與 System Center Operations Manager (SCOM) 產品群組緊密合作，為 Exchange 環境提供全方位警報解決方案。

一般來說，監控牽涉到收集資料，必要時，還要根據收集的資料執行動作。例如，在 SCOM 環境中，您可透過 Exchange Management Pack 使用不同機制收集資料：

Exchange Server 2013 監控目標

我們開始發展 Exchange 2013 時，著重的領域在於改善所有 Exchange 部署的端對端監控，從最小的內部部署到全球最大的部署 Office 365。我們有三個主要目標：

1. 將我們的 Office 365 服務知識和經驗，傳遞給內部部署客戶  近 6 年來，Exchange 產品小組已在經營 Exchange Online。我們使用的操作模型稱為開發人員操作模型 (DevOps)。在這個模型中，若服務的功能不佳，或客戶回報一個已向上呈報的未知問題，問題會直接向功能開發人員呈報。不論問題源頭為何，只要向上呈報，指出軟體的缺陷，就會直接施予開發者改良軟體的責任義務。

   使用這種模型，讓我們學到很多。例如 Exchange 2010 Management Pack 幾乎有 1100 種警報。但這些年來，我們發現，只在 Office 365 使用了約 150 個 (其他都停用了)。此外，我們發現，開發人員收到向上呈報的問題時，他們更可能負起責任並努力解決問題 (無論是透過修復代碼、新復原工作流程，或是微調警報等方式)，因為開發人員不希望一直被中斷或叫醒，就為了一再解決同樣的問題。在 DevOps 模型內，我們的流程是，每週備勤工作人員都要參與交接會議，檢視上週的事件；會議結果是開發內部復原工作流程，例如重設 IIS 應用程式集區等等。在 Exchange 2013 之前，我們有專屬的內部引擎，專門處理這些復原工作流程。這方面的知識從未應用在內部部署產品。有了 Exchange 2013，我們元件化了復原工作流程引擎，這樣我們才能將所學與內部部署客戶分享。

2. 根據使用者的體驗監控  我們也了解到，有很多用於監控的方法，並無法確實幫助我們經營環境。因此，我們正在調整監控方法，往後一切將以客戶為中心。

   在過去的版本中，每個元件團隊都會明確列出系統內的所有元件，以開發一個健康的模型。例如傳輸包含 SMTP-IN、SMTP-OUT、傳輸代理程式、分類程式、路由引擎，儲存區驅動程式等等。然後元件團隊會針對每一個元件建立警報。接著管理組件內會有一些警報讓您知道儲存區驅動程式已故障。但還是有其缺憾，警報不會告訴我們端對端使用者的體驗，或在該體驗過程中，哪個元件故障了。因此，在 Exchange 2013 中，我們試圖顛覆模型。我們沒有要淘汰系統層級監控，因為這個部分至關重要。但是，若想做好服務管理，真正重要的是使用者看到了什麼，因此，我們顛覆模型，致力於監控使用者體驗。

3. 透過復原導向運算，保護使用者體驗  舊版 Exchange 監控的重點是系統和元件，而不是如何自動復原和恢復使用者體驗。

監控 Exchange Server 2013：Managed Availability

Managed Availability 是監控和復原基礎結構，整合了 Exchange 的高可用性解決方案。Managed Availability 會在問題一發生時便偵測出來，並在發現問題後復原。

Managed Availability 以使用者為中心。我們要測量三個主要層面：可用性、經驗 (多數用戶端的測量結果為延遲)，以及是否發生錯誤。要了解這三個層面，先看看以下範例，使用 Outlook Web App (OWA) 的使用者。

可用性的概念很簡單，就是使用者是否能存取 OWA 表單型驗證網頁。如果不能，就是體驗失敗，問題會向上呈報到支援人員。說到經驗，若使用者可登入 OWA，對該體驗有何感想：有載入介面嗎？使用者可以存取郵件嗎？最後一個層面為延遲：使用者能夠登入並存取介面，但郵件轉譯在瀏覽器的速度有多快？這些就是構成使用者體驗的要素。

舊版和 Exchange 2013 最大的差異，在於 Exchange 2013 的監控解決方案並不試圖提供根本原因 (這並不代表系統不會在日誌中記錄資料，或是不會產生傾印，又或者是不會發現根本原因)。有一點您一定要了解，我們在舊版的時候，從未盡力溝通根本原因，有時我們是對的，但通常我們是錯的。

Managed Availability 的元件

Managed Availability 內建於 Exchange 2013 的兩個伺服器角色中，包含三個主要非同步元件。第一個元件是探查引擎。探查引擎負責在伺服器上測量。接著就說到第二元件：監控。監控包含商務邏輯，負責編碼我們認為健康的元件。您可將之視為模式識別引擎；在測量結果中尋找不同的模式，然後決定某元件是否健康。最後一個元件是回應程式引擎，也就是下方圖表中標示為復原的部分。若有某元件不健康，回應程式引擎首先會做的就是嘗試復原該元件。Managed Availability 提供多重階段復原動作：第一次嘗試可能是重新啟動應用程式集區，第二次嘗試可能是重新啟動服務，第三次嘗試可能是重新啟動伺服器，最後一次嘗試可能是讓伺服器離線，不再接受流量。若這些嘗試都失敗，Managed Availability 會透過事件日誌通知向上呈報給相關人員。

您可能也注意到我們分散了一些東西。過去我們在各個伺服器上安裝 SCOM 代理程式，然後將所有測量結果傳至中央 SCOM 伺服器。SCOM 伺服器必須評估所有測量結果，判斷某元件是否健康。在高階環境中，關聯交錯複雜，倏來忽往。我們注意到的是，警報需要較長時間才會觸發等問題。將所有東西往一個地方集中，並不會進步。所以，我們讓每個伺服器獨立運作：每個伺服器執行自己的探查工作、自我監控，並採取行動，自我復原，當然，必要時向上呈報問題。

圖 1：Managed Availability 的元件

探查

探查基礎結構包含三個相異的架構：

1. 探查是各個元件團隊建立的「綜合交易」，類似舊版的測試 Cmdlet。探查是透過執行綜合端對端使用者交易來測量服務認知。
2. 檢查是被動的監控機制，會測量實際客戶流量。
3. 通知架構讓我們能夠立即採取行動，不必等待探查的執行。這樣如果我們偵測到故障，可以立即採取行動。通知架構的基礎是通知。例如憑證過期時，即會觸發通知事件，提醒營運部門需要更新該憑證。

監控

從探查收集來的資料會送到監控。探查和監控的相互關係不一定是一對一；多個探查可將資料送入單一監控。監控會研究探查結果並得出結論。結論為二進制：監控不是健康，就是不健康。

如上所述，Exchange 2013 監控重點在於使用者體驗。要達到此目標，我們必須監控環境各層：

圖 2：監控各層，查看使用者體驗

正如您從上圖所見，我們有四種不同的檢查。第一個檢查是郵箱自我測試；此探查會驗證本機通訊協定或介面是否可以存取資料庫。第二個檢查稱為通訊協定自我測試，驗證郵箱伺服器的本機通訊協定是否正常運作。第三次檢查是 Proxy 自我測試，在用戶端存取伺服器上執行，驗證通訊協定的 Proxy 是否正常運作。第四個檢查，也就是最後一個檢查是全套檢查，驗證端對端體驗 (通訊協定 Proxy 到存放區函式)。每次檢查都會依不同間隔執行偵測。

我們會監控各層，處理依存關係。因為 Exchange 2013 沒有相互關聯引擎，所以我們要區分與各個項目之間的依存關係，包括對應到不同探查的唯一錯誤碼，以及不包含相連依存關係的探查。例如，若您看到郵箱自我測試和通訊協定自我測試探查同時故障，這傳達什麼訊息？是否告訴您存放區已離線？不一定；要傳達的真正訊息是，郵箱伺服器的本機通訊協定沒在運作。若您看到通訊協定自我測試正常運作，但郵箱自我測試卻故障，這傳達什麼訊息？這種情況是要告訴您，「儲存區」層有問題，實際原因可能是存放區或資料庫離線。

從監控的角度來看，這意味著，我們現在更能有效控制要發出哪些警報。例如若我們在評估 OWA 的健康狀況，我們很可能在郵箱自我測試故障但通訊協定自我測試正常運作的情況下，延遲觸發警報；但是若郵箱自我測試與通訊協定自我測試監控皆不健康，就會觸發警報。

回應程式

回應程式會根據監視器產生警報執行回應。應答永遠不會執行，除非監視器不健全，否則回應程式永遠不會執行。

回應程式有許多類型：

• 重新啟動回應程式  終止並重新啟動服務
• 重設 AppPool 回應程式  循環 IIS 應用程式集區
• 容錯移轉回應程式  將 Exchange 2013 信箱伺服器從服務剔除
• 檢查錯誤回應程式  檢查伺服器的錯誤
• 離線回應程式  將機器的通訊協定從服務剔除
• 向上呈報回應程式  向上呈報問題
• 特定的元件回應程式 

離線的回應程式是用來刪除不讓用戶端存取伺服器使用的通訊協定。此回應程式專為無從驗證的負載平衡器特別設計。叫用此回應程式時，通訊協定不會認可負載平衡器的狀況檢查，從而啟用負載平衡器的以移除負載平衡器集區的伺服器或通訊協定。同樣地，一旦對應的監控器恢復健康狀況 (假設沒有其他相關監控器處於不健康狀態)，對應的線上回應程式就會自動啟動：線上回應程式只允許通訊協定回應負載平衡器的狀況檢查，讓負載平衡器將伺服器或通訊協定加回負載平衡器集區。您也可以透過 ServerComponentState Cmdlet 手動叫用離線回應程式。這樣可讓系統管理員手動將用戶端存取伺服器置於維修模式。

叫用向上呈報回應程式時，會產生一個 Exchange 2013 Management Pack 可識別的 Windows 事件，這不是正常的 Exchange 事件，不是通知我們 OWA 故障或發生 Hard IO 錯誤的事件，而是告訴我們健康情況如何的 Exchange 事件。我們使用類似的單一執行個體事件來操作 SCOM 內的監控器。我們是根據向上呈報回應程式中產生的事件來執行，與傳遍了整個產品的事件截然不同。另一個思考的角度是間接性。Managed Availability 決定何時該打開 SCOM 內的監控器，Managed Availability 負責決定何時該向上呈報，或者換句話說，何時該讓相關人員參與此事。

您也可為回應程式節流，確保不會拖累整個服務。節流方法視回應程式而有所不同：

• 某些回應程式會考量 DAG 或負載平衡的 CAS 集區內的服務數量下限
• 某些回應程式會考量每次執行之間的時間長度。
• 某些回應程式會考量該回應程式所啟動的發生次數。
• 某些回應程式則會考量以上各點。

節流發生時，回應程式的動作可能會視回應程式的不同而延遲或略過。

復原順序

您必須明白一點，監控器是依執行的回應程式以及執行的時間表來定義回應程式的類型；這就是我們所說的監控器的復原順序。例如 OWA 通訊協定 (通訊協定自我測試) 的探查資料觸發了即將呈現不健康狀況的監控器。此時目前時間就省下來了 (我們稱為 T)。監控器啟動以目前時間為基礎的復原管線，並在復原管線內依指定的時間間隔定義復原動作。以郵箱伺服器的 OWA 通訊協定監控器為例，復原順序為：

1. T=0 時，執行重設 IIS 應用程式集區回應程式。
2. 若在 T=5 分鐘時，監控器尚未還原到健康狀態，即啟動容錯移轉回應程式，從伺服器移出資料庫。
3. 若在 T=8 分鐘時，監控器尚未還原到健康狀態，即啟動檢查錯誤回應程式，並強制重新啟動伺服器。
4. 若在 T=15 分鐘時，監控器尚未還原到健康狀態，即觸發向上呈報回應程式。

監控器還原到健康狀態時，復原順序管道將停止。請注意，下一個指定的時間動作開始前，上一個指定時間動作不一定要完成。  此外，監控器的指定時間間隔次數不受限制。

Systems Center Operations Manager (SCOM)

Systems Center Operations Manager (可能為英文網頁) (SCOM) 可做為入口網站，查看 Exchange 環境相關的健康資訊。SCOM 入口網站內的不健康狀態是由寫到應用程式記錄檔的事件透過向上呈報回應程式觸發。SCOM 儀表板經過精簡，現在有三個主要區域：

• 作用中警示
• 組織健康狀況
• 伺服器健康狀況

Exchange Server 2013 SCOM Management Pack 將受 SCOM 2007 R2 與 SCOM 2012 支援。

覆寫

任何環境下，預設值可能並不總是最佳條件，或需要緊急動作時可能存在的條件。Managed Availability 包含可在整個環境或各個伺服器啟用覆寫的功能。您可在指定的期間設定各個覆寫，或套用至指定的伺服器版本。*-ServerMonitoringOverride 和 *-GlobalMonitoringOverride Cmdlet 可讓系統管理員設定、刪除或檢視覆寫。

健康的評斷標準

類似的監控器，或是依賴特定元件結構的監控器，都會分在同一組，形成健康集。健康集的健康狀況一直是以健康集內監控器的「最差」評價為評斷標準。也就是說，若您在健康集有 9 個監控器，其中有 1 個監控器不健康，則該健康集就視為不健康。您可以使用 Get-MonitoringItemIdentity Cmdlet，評斷指定健康集內的監控器 (以及相關探查和回應程式) 集合。

要檢視健康狀況，您可使用 Get-ServerHealth 和 Get-HealthReport Cmdlet。Get-ServerHealth 用於讀取原始健康狀況資料，Get-HealthReport 則在原始健康狀況資料運作，提供目前健康狀況的快照集。這些 Cmdlet 可在許多層中運作：

• 這些 Cmdlet 可顯示指定伺服器的健康狀況，並依健康集分析。
• 這些 Cmdlet 可用於研究特定健康集，並查看各監控器的狀態。
• 這些 Cmdlet 可用於總結指定伺服器集 (DAG 成員或 CAS 的負載平衡陣列) 的健康狀況。

健康集進一步分成稱為「健康群組」的功能單元。健康群組共有 4 個，您可在 SCOM 管理入口網站報告利用這些健康群組回報：

1. 客戶觸控點：可直接、即時與客戶互動的元件 (例如 OWA)。
2. 服務元件：不能直接、即時與客戶互動的元件 (例如 OAB 產生)。
3. 伺服器元件：伺服器的實體資源 (例如磁碟、記憶體)。
4. 依存性可用性：伺服器呼叫依存性的能力 (例如 Active Directory)。

結論

Managed Availability 在各個伺服器內執行各種健康評估。這些定期的測試可評斷伺服器各個元件的可行性，保證使用者載入前與載入期間的伺服器 (或伺服器集) 健康狀況。偵測到問題時，將採取包含多重步驟的更正措施，讓伺服器回到正常運作的狀態；若伺服器不能回到健康狀態，Managed Availability 可以提醒操作人員多加注意。

如此一來，Managed Availability 就能著重在使用者體驗，並保證出現問題時，若會影響使用體驗，會將影響降到最低。

這是翻譯後的部落格文章。英文原文請參閱 Lessons from the Datacenter: Managed Availability