瞭解 Active Manager

 

適用版本： Exchange Server 2010 SP2, Exchange Server 2010 SP3

上次修改主題的時間： 2015-03-09

Microsoft Exchange Server 2010 內含名為 Active Manager 的新元件，可取代舊版 Exchange 與叢集服務整合後所提供的資源模型與容錯移轉管理功能。Exchange 不再使用叢集資源模型來提供高可用性。所有由 exres.dll 提供的 Exchange 叢集資源已不存在，包含名為叢集信箱伺服器的建構。Exchange 會使用 Windows 容錯移轉叢集，但是 Exchange 已不含任何叢集群組，且叢集裡也沒有任何儲存資源。因此，假如您使用叢集管理工具來檢查叢集，只會看到核心叢集資源 (IP 位址與網路名稱，必要時還包括仲裁資源)。叢集節點與網路將同時存在，但是由 Exchange 而非叢集或叢集工具所管理。

Active Manager 會在所有信箱伺服器上以角色的形式來執行。在沒有設定高可用性的信箱伺服器上，只有單一的 Active Manager角色：「獨立 Active Manager」。在隸屬於資料庫可用性群組 (DAG) 成員的伺服器上，有兩個 Active Manager 角色：主要 Active Manager (PAM) 與待機 Active Manager (SAM)。PAM 是 DAG 中決定哪些副本為主動/被動的 Active Manager。PAM 負責取得拓撲變更通知，並回應伺服器失敗。取得 PAM 角色的 DAG 成員，一律為目前擁有叢集仲裁資源的成員 (預設叢集群組)。如果擁有叢集仲裁資源的伺服器失敗，則 PAM 角色會自動移至取得叢集仲裁資源擁有權的剩餘伺服器。此外，如果您需要中斷主控叢集仲裁資源的伺服器連線，以便進行維護或升級，首先必須將 PAM 移至 DAG 中的另一台伺服器上。PAM 控制資料庫副本之間所有的主動指定動作 (在任何指定時間內只有一份副本可以成為主動，且該副本可以是已裝載或卸載)。PAM 同時會在本機系統上執行 SAM 角色功能，偵測本機資料庫與本機資訊儲存庫的失敗。

SAM 所提供的資訊，是關於哪一台伺服器，會將信箱資料庫的主動副本裝載至執行 Active Manager 用戶端元件的其他 Exchange 元件 (例如，RPC 用戶端存取服務或集線傳輸伺服器)。SAM 會偵測到本機資料庫與本機資訊儲存庫的失敗。它會要求 PAM 初始化容錯移轉 (如果資料庫已複寫的話) 來回應失敗。SAM 無法決定容錯移轉目標，也無法更新 PAM 中資料庫的位置狀態。它會存取主動資料庫副本位置狀態，以回答所收到的主動資料庫副本查詢。

附註：
Exchange 2010 不是叢集應用程式。它會使用 clusapi.dll 中實作的叢集程式庫功能，來執行叢集、群組、叢集網路 (活動訊號)、節點管理、叢集登錄與一些控制碼功能。此外，Active Manager 會將目前的信箱資料庫資訊 (例如，主動與被動資料以及裝載的資料)，儲存在叢集資料庫中。雖然這項資訊是直接儲存在叢集資料庫中，但卻無法由其他任何元件直接存取。

在 Exchange 2010 中，Microsoft Exchange 複寫服務會定期監視所有已裝載資料庫的健康狀態。此外，它還會監視可延伸儲存引擎 (ESE)，查看是否有任何 I/O 錯誤或失敗。當服務偵測到失敗時，會通知 Active Manager。這時 Active Manager 會判斷應該裝載那一個資料庫副本，以及裝載該資料庫需要哪些條件。此外，它會追蹤信箱資料庫的主動副本 (依據上次裝載的資料庫副本)，並將追蹤結果資訊提供給與該用戶端連線之用戶端存取伺服器上的 RPC 用戶端存取元件。

Active Manager 最佳副本選擇

當發生失敗而影響到已複寫的信箱資料庫時，Active Manager 會採取幾個步驟，透過選取要啟動的已失敗資料庫最佳可行副本，以便從失敗中復原。一般程序進行的順序如下：

1. Active Manager 偵測到失敗。

2. PAM 執行名為最佳副本選擇 (BCS) 的內部演算法。

3. 發生名為*「嘗試複製最後的記錄檔」*(ACLL) 的處理程序，它會嘗試從在容錯移轉之前主控主動資料庫副本的伺服器複製所有遺失的記錄檔。

4. 一旦 ACLL 處理程序完成之後，PAM 便會透過遠端程序呼叫 (RPC)，向 Microsoft Exchange Information Store 發出裝載要求。此時：

   1. 資料庫會裝載並供用戶端使用；或者

   2. 資料庫不會裝載，而由 PAM 對下一個最佳副本 (如果有的話) 執行步驟 3 和步驟 4。

在搜尋最佳可行副本時，PAM 最多會根據十組不同的準則，來判斷所要啟動的最佳副本。找到最佳的可行副本之後，ACLL 便會開始執行。ACLL 處理程序完成之後，假如所有遺漏的記錄檔都順利從先前主動副本複製，資料庫便可以順利裝載，而無任何資料遺失。這就是所謂的無遺失容錯移轉。如果 ACLL 處理程序失敗，便會參考已設定的 AutoDatabaseMountDial 值。如需 AutoDatabaseMountDial 的相關資訊，請參閱 Set-MailboxServer。如果遺失的記錄檔數量介於已設定的 AutoDatabaseMountDial 值之間，便會裝載該資料庫。如果遺失的記錄檔數量超出已設定的 AutoDatabaseMountDial 值，則必須等到遺失的記錄檔全都復原，或是系統管理員明確地裝載資料庫，並接受範圍較大的資料遺失情況時，才會裝載該資料庫。如果資料庫無法自動裝載，PAM 將會選取下一個最佳副本 (如果有的話)。造成最初選取的資料庫副本無法自動裝載的原因至少有三個：

1. 遺失的記錄檔數目大於 AutoDatabaseMountDial 設定的值。

2. 嘗試進行裝載作業的伺服器設定的是資料庫作用中數目的非強制上限，而伺服器已達到主動資料庫副本的數目上限。

3. 資料庫副本的啟動作業遭到擱置。

最佳副本選擇程序

開始進行最佳副本選擇的程序時，Active Manager 會先建立一份可能啟動的資料庫副本清單。選擇程序中將會忽略也不會使用任何無法存取的資料庫副本，或是任何以系統管理方式封鎖啟動 (利用 Set-MailboxServer 指令程式的 DatabaseCopyAutoActivationPolicy 內容) 的資料庫副本。這份清單的順序依據 Exchange 2010 的版本而定：

• 在 Exchange 2010 量產發行 (RTM) 版本中，Active Manager 會使用複製佇列長度作為主要索引鍵來排序產生的清單。這項計算是以 LastLogInspected (從副本的觀點) 作為根據，因此可能的副本清單會依據 LastLogInspected 的最高值 (具有最小複製佇列長度的副本) 進行排序。接著，Active Manager 會使用 ActivationPreference 的值作為次要索引鍵，再一次排序此清單。ActivationPreference 值最低的副本在清單中將具有較高的優先順序。

• 在 Exchange 2010 Service Pack 1 (SP1) 中，此行為與 RTM 版本相同，但自動資料庫裝載撥號值設為 Lossless 的伺服器除外。使用 Lossless 的設定時，Active Manager 會使用 ActivationPreference 的值作為主要索引鍵，按照遞增順序來排序產生的清單。這是刻意設計的行為，目的是為了盡量減少因為移動作業 (例如轉換或執行 StartDagServerMaintenance.ps1 時) 所造成的資料庫不平衡。

接下來，Active Manager 會嘗試在清單中尋找具有 Healthy、DisconnectedAndHealthy、DisconnectedAndResynchronizing 或 SeedingSource 狀態的信箱資料庫副本，然後再使用依序排列的十組準則來評估清單中每個副本啟動的可能性。Active Manager 會判斷是有任何可能啟動的副本符合第一組準則：

• 它具有 Healthy 狀態的內容索引。

• 它的副本佇列長度少於 10 個記錄檔。

• 它的重新顯示佇列長度少於 50 個記錄檔。

如果沒有任何一個資料庫副本符合第一組準則，Active Manager 會嘗試尋找符合第二組準則的資料庫副本：

• 它具有 Crawling 狀態的內容索引。

• 它的副本佇列長度少於 10 個記錄檔。

• 它的重新顯示佇列長度少於 50 個記錄檔。

如果沒有任何一個資料庫副本符合第二組準則，Active Manager 會嘗試尋找符合第三組準則的資料庫副本：

• 它具有 Healthy 狀態的內容索引。

• 它的重新顯示佇列長度少於 50 個記錄檔。

如果沒有任何一個資料庫副本符合第三組準則，Active Manager 會嘗試尋找符合第四組準則的資料庫副本：

• 它具有 Crawling 狀態的內容索引。

• 它的重新顯示佇列長度少於 50 個記錄檔。

如果沒有任何一個資料庫副本符合第四組準則，Active Manager 會嘗試尋找符合第五組準則的資料庫副本：

• 它的重新顯示佇列長度少於 50 個記錄檔。

如果沒有任何一個資料庫副本符合第五組準則，Active Manager 會嘗試尋找符合第六組準則的資料庫副本：

• 它具有 Healthy 狀態的內容索引。

• 它的副本佇列長度少於 10 個記錄檔。

如果沒有任何一個資料庫副本符合第六組準則，Active Manager 會嘗試尋找符合第七組準則的資料庫副本：

• 它具有 Crawling 狀態的內容索引。

• 它的副本佇列長度少於 10 個記錄檔。

如果沒有任何一個資料庫副本符合第七組準則，Active Manager 會嘗試尋找符合第八組準則的資料庫副本：

• 它具有 Healthy 狀態的內容索引。

如果沒有任何一個資料庫副本符合所有第八組準則，Active Manager 會嘗試尋找符合第九組準則的資料庫副本：

• 它具有 Crawling 狀態的內容索引。

如果沒有任何一個資料庫副本符合第九組準則，Active Manager 會嘗試使用 Healthy、DisconnectedAndHealthy、DisconnectedAndResynchronizing 或是 SeedingSource (第十組準則) 來啟動任何一個資料庫副本。如果找不到任何符合第十組準則的資料庫副本，它就無法自動啟動資料庫副本。

一旦找到符合一或多組準則的一或多個副本之後，ACLL 處理程序便會執行，以便將任何記錄檔從原始來源複製到可能的新主動副本。在 ACLL 處理程序完成之後，PAM 會發出裝載要求，且資料庫會裝載並供用戶端使用，或者資料庫並不會裝載，而由 PAM 搜尋下一個最佳副本 (如果有的話)。

最佳副本選擇範例

下節說明 Active Manager 的幾個最佳副本選擇與啟動程序範例。

範例 1：基本案例

在這個範例中，信箱資料庫 DB1 有四個副本。DB1 目前在 Server1 上作用，而 Server1 遇到硬體故障。下表顯示 DB1 的資料庫副本目前在 Server2、Server3 和 Server4 上的狀態。

資料庫副本	啟動喜好設定	複製佇列長度	重新顯示佇列長度	內容索引狀態	資料庫狀態	封鎖啟動
Server2\DB1	2	4	0	正常	正常	否
Server3\DB1	3	2	2	正常	DisconnectedAndHealthy	否
Server4\DB1	4	10	0	Crawling	正常	否

根據可用副本的複製佇列長度 (視需要使用 [啟動喜好設定]) 對其進行排序時，將會產生下列排序清單：

• Server3\DB1

• Server2\DB1

• Server4\DB1

在這份清單中，只有兩個資料庫副本符合第一組啟動準則：

• Server3 上的副本，此副本的資料庫狀態為 Disconnectedandhealthy、複製佇列長度小於 10、重新顯示佇列長度小於 50，且具有健全的內容索引。

• Server2 上的副本，此副本的資料庫狀態為 Healthy、複製佇列長度小於 10、重新顯示佇列小於 50，而且具有正常的內容索引。

在這兩個副本中，Server3 上的副本具有最小的複製佇列長度，因此選取 Server3 作為嘗試啟動的副本，因為它遺失的資料量最少。

啟動 Server3 上的副本之後，Server3 上的 Microsoft Exchange 複寫服務會執行 ACLL 處理程序，並嘗試從先前的主動伺服器 (在此範例中為 Server1) 複製任何遺失的記錄檔。當 ACLL 處理程序完成時，PAM 會接到 ACLL 處理程序結果的通知。如果所有記錄檔都已順利複製，則會將資料庫標示成主動副本，而且將進行裝載，而不會遺失任何資料。如果有一或多個記錄檔遺失，則會參考 AutoDatabaseMountDial 參數的值。若資料遺失仍在設定的值範圍內，則資料庫會標示成主動副本，並在有資料遺失的狀況下進行裝載。接著便會從傳輸暫放復原大部分的遺失資料。

如果 Active Manager 確實傳送了裝載要求到資訊儲存庫，而且裝載作業也順利完成，Active Manager 將會返回上列排序清單，並嘗試啟動下一個最佳副本 (在此範例中為 Server2)。

範例 2：複製佇列長度相同的兩個副本

在這個範例中，信箱資料庫 DB2 有四個副本。DB2 目前在 Server1 上作用，而 Server1 遇到硬體故障。下表顯示 DB2 的資料庫副本目前在 Server2、Server3 和 Server4 上的狀態。

資料庫副本	啟動喜好設定	複製佇列長度	重新顯示佇列長度	內容索引狀態	資料庫狀態	封鎖啟動
Server2\DB2	2	2	0	正常	正常	否
Server3\DB2	3	2	2	正常	DisconnectedAndHealthy	否
Server4\DB2	4	10	0	Crawling	正常	否

根據可用副本的複製佇列長度 (視需要使用 [啟動喜好設定]) 對其進行排序時，將會產生下列排序清單：

• Server2\DB2

• Server3\DB2

• Server4\DB2

在這份清單中，只有兩個資料庫副本符合第一組啟動準則：

• Server2 上的副本，此副本的資料庫狀態為 Healthy、複製佇列長度小於 10、重新顯示佇列小於 50，而且具有正常的內容索引。

• Server3 上的副本，此副本的資料庫狀態為 DisconnectedandHealthy、複製佇列長度小於 10、重新顯示佇列長度小於 50，且具有健全的內容索引。

在這兩個副本中，Server2 上副本的複製佇列長度與 Server3 上的副本相等，但是前者的 [啟動喜好設定] 值也比較低，因此 Server2 上的副本位於清單的頂端，而且會被選為嘗試啟動的副本，因為它遺失的資料量最少，[啟動喜好設定] 的值也最低。

範例 3：具有相同資料庫狀態和不同內容索引狀態的副本

在這個範例中，信箱資料庫 DB3 有四個副本。DB3 目前在 Server1 上作用，而 Server1 遇到硬體故障。下表顯示 DB3 的資料庫副本目前在 Server2、Server3 和 Server4 上的狀態。

資料庫副本	啟動喜好設定	複製佇列長度	重新顯示佇列長度	內容索引狀態	資料庫狀態	封鎖啟動
Server2\DB3	2	0	3	Crawling	正常	否
Server3\DB3	3	0	3	正常	DisconnectedAndHealthy	否
Server4\DB3	4	0	0	正常	正常	否

根據可用副本的複製佇列長度 (視需要使用 [啟動喜好設定]) 對其進行排序時，將會產生下列排序清單：

• Server2\DB3

• Server3\DB3

• Server4\DB3

上列伺服器所主控的三個資料庫副本全都符合啟動的準則。雖然 Server2 的 [啟動喜好設定] 值比較低，但是它的內容索引狀態是 Crawling，因此當 Active Manager 根據第一組準則 (其中包括 Healthy 的內容索引狀態) 檢查清單時，將優先啟動 Server3 上的資料庫副本，因為它的內容索引狀態是 Healthy。

範例 4：AutoDatabaseMountDial 對最佳副本選擇的影響

在這個範例中，信箱資料庫 DB4 有四個副本。DB4 目前在 Server1 上作用，而 Server1 發生造成它重新開機的失敗狀況。下表顯示 DB4 的資料庫副本目前在 Server2、Server3 和 Server4 上的狀態。DAG 中所有信箱伺服器的 AutoDatabaseMountDial 全都設定為 Lossless (複製佇列長度為 0)。

資料庫副本	啟動喜好設定	複製佇列長度	重新顯示佇列長度	內容索引狀態	資料庫狀態	封鎖啟動
Server2\DB4	2	0	4523	正常	正常	否
Server3\DB4	3	100	25	Crawling	正常	否
Server4\DB4	4	6	62	正常	正常	否

由於自動資料庫裝載撥號設定是設成 Lossless，因此 Active Manager 會使用 [啟動喜好設定] 取代複製佇列長度作為主要排序索引鍵。根據可用副本的 [啟動喜好設定] 對其進行排序時，將會產生下列排序清單：

• Server2\DB4

• Server3\DB4

• Server4\DB4

沒有任何資料庫符合第一、第二或第三組準則，但是 Server3 上的資料庫副本確實符合第四組準則 (它具有 Crawling 的內容索引狀態且重新顯示佇列長度小於 50)。Server3 上的資料庫副本的複製佇列長度為 100，不過因為 Server1 尚未完成重新開機，所以 ACLL 處理程序無法將這些遺失的記錄檔複製到 Server3。ACLL 處理程序會通知 PAM 遺失的資料量不在 AutoDatabaseMountDial 參數設定的值範圍內，而這會讓 PAM 選取下一個最佳的可用副本。

在上面的案例中，Server2 和 Server4 上的資料庫副本符合第六組準則 (它們具有正常的資料庫和內容索引，而且複製佇列長度小於 10)。由於 Server2 上的資料庫副本在可用副本的排序清單中的位置較高，所以接下來會嘗試啟動該副本。ACLL 處理程序會在 Server2 上執行，但是 Server1 仍然無法在網路上通訊，而且 ACLL 無法複製任何記錄檔。不過因為複製佇列長度在 AutoDatabaseMountDial 參數設定的值範圍內，所以 ACLL 會傳送成功訊息到 PAM，而且 PAM 會透過 RPC 發出資料庫裝載要求。

 © 2010 Microsoft Corporation. 著作權所有，並保留一切權利。