瞭解陰影備援

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

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

Exchange 的高可用性策略，會著重在信箱資料庫中所儲存的資料可用性與復原能力。當您為信箱伺服器實作高可用性的解決方案時，電子郵件並不會遺失，而且只要到達信箱，即使發生失敗情況也能輕鬆復原。

不過，這些策略並未涵蓋正在傳輸的郵件。如果 Hub Transport Server 在處理郵件時失敗且無法復原，則可能導致資料遺失。隨著集線傳輸伺服器所處理的郵件數量增加，系統管理員便需要開始注意資料遺失問題。

Microsoft Exchange Server 2007 推出了 Hub Transport Server 的傳輸暫放功能。Exchange 2007 Hub Transport Server 會針對信箱位於叢集信箱伺服器上的收件者，維護一份最近傳遞至收件者的郵件佇列。當容錯移轉發生時，叢集信箱伺服器會自動要求 Active Directory 站台中的每一個 Hub Transport Server 重新提交傳輸暫放佇列中的郵件。這樣可在叢集的容錯移轉期間預防郵件遺失。儘管這麼做可以提供基本的傳輸備援等級，不過僅限於在叢集連續複寫 (CCR) 環境中傳遞的郵件，並無法解決在 Hub Transport Server 與 Edge Transport Server 之間傳輸郵件可能發生遺失的問題。

Exchange Server 2010 採用 陰影備援功能，在郵件傳輸的整個過程中都能提供郵件備援。這項解決方案包含與傳輸暫放類似的技術。使用陰影備援時，從傳輸資料庫刪除郵件時會發生延遲，直到傳輸伺服器驗證該郵件的所有下一個躍點都已完成遞送為止。如果在回報成功傳遞之前，有任何下一個躍點失敗，會重新提交郵件以便傳遞至該下一個躍點。

陰影備援具有下列優點：

• 它會消除對任何特定集線傳輸或邊際傳輸伺服器之狀態的依賴。只要路由拓撲中一直存在備援郵件路徑，任何傳輸伺服器都可進行處置。

• 萬一有任何傳輸伺服器失敗，您可以將其從生產環境中移除，而不用清空佇列或擔心會遺失郵件。

• 如果您想要升級集線傳輸或邊際傳輸伺服器，隨時可以中斷該伺服器的連線，而不用擔心會遺失郵件。

• 如此一來，您就不需要針對傳輸伺服器準備儲存硬體備援機制。

• 它所使用的頻寬，小於在多台伺服器上建立重複郵件副本所需的頻寬。陰影備援所產生的唯一額外的網路流量，就是在傳輸伺服器之間交換捨棄狀態時所產生的流量。捨棄狀態為每台傳輸伺服器維護的資訊。此資訊會指出何時可以從傳輸資料庫捨棄郵件。

• 它提供可靠度並簡化在傳輸伺服器失敗時的復原作業。

您可以擴充 SMTP 服務，藉此實作陰影備援。此服務延伸模組可讓 SMTP 主機交涉陰影備援支援，並交換陰影郵件的捨棄狀態。

要尋找與管理傳輸伺服器相關的管理工作嗎？請參閱 管理傳輸伺服器。

陰影備援元件

下表提供陰影備援的所有元件說明。

陰影備援元件

回到頁首

陰影備援郵件流程

若要使用啟用的陰影備援機制來說明郵件流程，請考慮集線傳輸伺服器透過周邊網路中的邊際傳輸伺服器，將郵件傳送給協力廠商郵件伺服器的簡單案例。

使用陰影備援的郵件流程

在這種情況下，郵件流程會經歷下列階段：

1. Hub Transport server 將郵件傳送到 Edge Transport server。

   1. 集線傳輸伺服器會使用邊際傳輸伺服器，來開啟 SMTP 工作階段。

   2. 邊際傳輸伺服器會通告陰影備援支援。

   3. 集線傳輸伺服器會通知邊際傳輸伺服器追蹤捨棄狀態。

   4. Hub Transport server 將郵件提交到 Edge Transport server。

   5. Edge Transport Server 會確認收到郵件，並記錄 Hub Transport Server 身分識別以便傳送郵件的捨棄資訊。

   6. 集線傳輸伺服器會將郵件移至邊際傳輸伺服器的陰影佇列，並將邊際傳輸伺服器標示為主要伺服器。Hub Transport server 會成為陰影伺服器。

2. 邊際傳輸伺服器會將訊息傳送到下一個躍點。

   1. 邊際傳輸伺服器會將郵件提交給協力廠商郵件伺服器。

   2. 協力廠商郵件伺服器會確認收到郵件。

   3. 邊際傳輸伺服器會將郵件的捨棄狀態更新為傳遞完成。

3. 集線傳輸伺服器會查詢邊際傳輸伺服器的捨棄狀態 (成功案例)。

   1. 在每個邊際傳輸伺服器的 SMTP 工作階段結尾，集線傳輸伺服器會查詢邊際傳輸伺服器有關先前提交的郵件捨棄狀態。如果集線傳輸伺服器在初始郵件提交作業完畢後，尚未開啟任何邊際傳輸伺服器的 SMTP 工作階段，便會開啟邊際傳輸伺服器的 SMTP 工作階段，以便單獨查詢在經過指定的時間後的捨棄狀態。

   2. 邊際傳輸伺服器會檢查本機捨棄狀態，並傳回已經傳遞的郵件清單，接著移除捨棄資訊。

   3. 集線傳輸伺服器會從其陰影佇列中刪除郵件清單。

4. 集線傳輸伺服器會查詢邊際傳輸伺服器的捨棄狀態，然後重新提交郵件 (失敗案例)。

   1. 如果集線傳輸伺服器沒有連絡邊際傳輸伺服器，則集線傳輸伺服器會恢復主要伺服器角色，並重新提交陰影佇列中的郵件。

   2. 重新提交的郵件會傳遞至另一台邊際傳輸伺服器，此時工作流程將從第 1 階段重新來過。

      附註：
      如果陰影郵件沒有其他可用的路由 (例如，上一張圖表中所示的第二台邊際傳輸伺服器)，則郵件不會重新提交，而是留在陰影佇列中。

有關各種不同案例中訊息流程的相關資訊，請參閱陰影備援郵件流程案例。

多重躍點案例

如果郵件經過多部支援陰影備援的伺服器，則陰影郵件會保留在某一台伺服器中，直到郵件路徑中的下一台伺服器確認傳遞為止。為了詳細說明運作方式，假設組織中有五個安裝集線傳輸伺服器的 Active Directory 站台。這些站台彼此互相連線，如下圖所示。組織將位於紐約與倫敦的站台設為集線站台，因此來自芝加哥或亞特蘭大的郵件，必須經過紐約及倫敦站台中的 Hub Transport Server，才能傳遞至都柏林站台。

多個躍點案例的範例拓撲

假定位於芝加哥站台裡的某位使用者，傳送一封郵件給位於都柏林站台的使用者。這封郵件需要經過紐約與倫敦站台才能抵達都柏林。在本案例中，會發生下列情況：

1. 芝加哥的集線傳輸伺服器將把郵件傳送給紐約的集線傳輸伺服器，並將保留一份郵件陰影副本。

2. 紐約的集線傳輸伺服器會將郵件傳送給倫敦的集線傳輸伺服器，並為芝加哥集線區排入捨棄狀態佇列。

3. 芝加哥集線區會查詢紐約集線區的捨棄狀態，然後接收該郵件的捨棄通知。此時，它就可以從資料庫中移除陰影郵件。不管郵件是否已經由倫敦傳遞至都柏林，都不會影響芝加哥刪除陰影郵件的時間。

當 Hub Transport 和 Mailbox Server Role 與 DAG 共存時的陰影備援保護

使用資料可用性群組 (DAG) 時，已經認可至信箱資料庫的郵件會受到 DAG 架構保護。針對傳送到屬於 DAG 的信箱資料庫的任何郵件，該郵件的陰影副本會保留在傳輸暫放中，直到該郵件複寫至所有 DAG 成員。同樣地，從 DAG 成員傳送到 Hub Transport Server 的任何郵件也會有兩個副本，一個在 Hub Transport Server 佇列中等待傳送，另一個是寄件者的 [寄件備份] 資料夾中的陰影副本。此方法是陰影備援的關鍵元件。

不過，當 Hub Transport 和 Mailbox server role 共存在同一部伺服器上，而且信箱資料庫屬於 DAG 的一部分時，Hub Transport Server 可能必須透過額外的躍點路由郵件，以避免主要郵件和陰影郵件存放在同一個伺服器硬體上。明確地說，Hub Transport server role 會避免發生下列兩種情況，因為單一伺服器故障可能會導致主要和陰影郵件同時遺失：

• 在傳遞郵件的過程中，郵件收件者的主動信箱資料庫與包含郵件陰影副本的傳輸暫放位於相同的伺服器上   為避免發生此情況，Hub Transport Server 會透過站台內另一部 Hub Transport Server 路由郵件，以確保陰影郵件最後出現在不同的伺服器硬體上。不過，如果沒有其他的 Hub Transport Server 可用，就會直接傳遞郵件。

• 在傳送郵件的過程中，存放主要郵件的傳輸佇列與寄件者的 [寄件備份] 資料夾中的陰影郵件位於相同的伺服器上   為避免發生此情況，儲存區驅動程式會優先選擇站台中的其他 Hub Transport Server 來傳送郵件。不過，如果站台中沒有其他的 Hub Transport Server 可用，則會將郵件傳送到本機 Hub Transport Server。

如需使用 DAG 時 Hub Transport 和 Mailbox server role 共存的相關資訊，請參閱使用 DAG 時共存的 Hub Transport 和 Mailbox Server 角色。

交互操作性

建立新的 SMTP 連線時，會決定是否要使用陰影備援。如果 SMTP 連線中的兩台伺服器同時支援陰影備援，就會使用上述的工作流程。不過，還是可能出現 Exchange 2010 傳輸伺服器與不支援陰影備援的郵件伺服器交換郵件的情況。這種情況可能是因為協力廠商郵件伺服器、舊版的 Exchange 或是 Exchange 2010 組織沒有啟用陰影備援所導致。

當支援陰影備援的 Exchange 2010 傳輸伺服器，與不支援陰影備援的伺服器建立連線時，會發生下列事件：

1. Exchange 與目標伺服器建立 SMTP 連線。

2. 目標伺服器不會通告陰影備援支援。

3. 由於目標伺服器不支援備援，Exchange 會針對每一封郵件執行下列動作：

   1. 將郵件傳遞到目標伺服器。

   2. 陰影備援管理員會把該郵件標示為已經傳遞至下一個躍點。

   3. 當郵件已傳遞至所有的下一個躍點之後，則刪除該郵件。

當不支援陰影備援的伺服器與 Exchange 2010 伺服器建立連線時，會發生下列事件：

1. 傳送端伺服器會與 Exchange 建立 SMTP 連線。

2. Exchange 會通告陰影備援支援。

3. 傳送端伺服器不支援陰影備援，因此不會使用此功能。它會將郵件傳遞到 Exchange 伺服器。

4. 它會針對 Exchange 所收到的每封郵件執行下列動作：

   1. 將郵件傳遞至下一個躍點，或是製作一份陰影副本。

   2. 將確認傳送到傳送端伺服器。

延遲的確認

陰影備援的大原則就是維護上一個躍點的郵件副本，直到伺服器確認該郵件已經成功傳遞至所有的下一個躍點為止。當 Exchange 2010 傳輸伺服器收到來自不支援陰影備援的郵件伺服器之郵件時，不會出現這種情況。此郵件伺服器可以是執行舊版 Exchange 的 Exchange 伺服器、標準 SMTP 用戶端，或是網際網路上非 Exchange 郵件伺服器。在此情況下，Exchange 會嘗試延遲向郵件伺服器確認來達成陰影備援目的，直到它確認郵件已經成功傳遞給內部的所有下一個躍點為止。如此一來，假使 Exchange 2010 伺服器失敗，傳送端郵件伺服器會假定該郵件永遠無法傳遞至 Exchange，而會再次嘗試傳遞郵件。

不過，如果您的路由基礎結構非常複雜，或是下一個躍點當中有一個躍點發生失敗，便可能需要很長一段時間才能將郵件傳遞至下一個躍點。在此情況下，為了防止 SMTP 工作階段逾時，Exchange 2010 傳輸伺服器會將確認傳送至傳送端郵件伺服器。在此情況下，系統便無法保證郵件備援，而只能盡力而為。比方說，郵件可能會在下列案例中遺失：：網際網路郵件伺服器將郵件傳輸至邊際傳輸伺服器。邊際傳輸伺服器因為網路問題而無法與集線傳輸伺服器進行通訊，並向網際網路郵件伺服器確認收到該郵件。邊際傳輸伺服器會接著失敗，而且無法在網路問題獲得解決之前回復正常。這時訊息將會遺失。

延遲的確認逾時值事由每個接收連接器的 MaxAcknowledgementDelay 屬性所控制。預設值為 30 秒。若要深入瞭解設定此屬性的相關資訊，請參閱設定陰影備援。

略過延遲的確認

在某些情況下，必須先達到延遲的確認逾時，郵件才會傳遞。在這種情況下，傳輸伺服器會使用下列其中一種方法來處理郵件：

• 略過延遲的確認   根據預設，傳輸伺服器會略過延遲的確認，以維持 SMTP 接收輸送量。基本上，傳輸伺服器會在達到逾時前發出確認。

• 陰影備援升級    在 Microsoft Exchange Server 2010 Service Pack 1 (SP1) 中，傳輸伺服器不會略過延遲的確認，而是可以設定將郵件轉送到站台內的任何其他傳輸伺服器。這相當於將郵件插入陰影備援管線，因此可保護郵件。此程序稱為陰影備援升級。相較於略過延遲的確認方法，這種方法可將組織中未受保護的郵件數目減至最少。依預設會停用此功能。若要啟用陰影備援升級，系統管理員必須編輯 Edgetransport.exe.config 檔案，將 shadowredundancypromotionenabled 機碼變更為 true，並將變更儲存到檔案，然後重新啟動 Microsoft Exchange Transport 服務 (MSExchangeTransport.exe)。若需要如何進行此工作的相關資訊，請參閱 設定陰影備援 主題的＜啟用陰影備援升級＞一節。

下表列出傳輸伺服器略過延遲的確認的不同案例，並描述 Exchange 2010 伺服器處理該案例的方式。

回到頁首

陰影備援管理員

陰影備援管理員是負責管理陰影備援的 Exchange 2010 傳輸伺服器的核心元件。

陰影備援管理員負責針對伺服器目前處理的所有主要郵件維護下列資訊：

• 正在處理的每封主要郵件的陰影伺服器。

• 要傳送至陰影伺服器捨棄狀態。

陰影備援管理員會針對伺服器在其陰影佇列中所擁有的所有陰影郵件，負責處理下列事項：

• 維護每封陰影郵件之主要伺服器清單。

• 檢查已將陰影郵件排入佇列的每台主要伺服器的可用性。

• 處理來自主要伺服器的捨棄通知。

• 在收到所有預期的捨棄通知之後，從資料庫移除陰影郵件。

• 決定陰影伺服器何時該取得陰影郵件的擁有權，並成為主要伺服器。

此外，陰影備援管理員同時必須負責與陰影備援相關的效能計數。

活動訊號

陰影備援管理員使用活動訊號，來判斷將陰影郵件排入佇列的伺服器可用性。在兩台同時支援陰影備援的伺服器之間進行 SMTP 工作階段期間，初始化連線的伺服器會將先前提交給該伺服器的郵件捨棄狀態，排入目標伺服器佇列當中。起始伺服器會發出 XQUERYDISCARD 命令來完成此作業。而目標伺服器則是傳回捨棄通知做為回應。兩台伺服器之間會透過這項交換作業，做為陰影備援的活動訊號。

此活動訊號有逾時值。如果陰影備援管理員在這段期間維護了陰影佇列，但未與支援陰影備援的伺服器建立連線時，則該伺服器會特別嘗試與主要伺服器建立 SMTP 連線，以查詢捨棄狀態並重設計時器。逾時值是由 Set-TransportConfig 指令程式的 ShadowHeartbeatTimeoutInterval 參數所控制。在量產發行 (RTM) 版的 Exchange 2010 中，此參數的預設值為 300 秒，而在 Exchange 2010 SP1 中，此參數的預設值為 900 秒。

如果該伺服器未能在到達逾時值時與主要伺服器建立連線，會重設計時器並再試一次如果連續 12 次達到逾時值 (Exchange 2010 RTM 中為三次)，該伺服器會認定主要伺服器失敗，並取得陰影郵件的擁有權，然後開始產生這些郵件的捨棄通知，以便傳送至失敗的主要伺服器。判斷主要伺服器已經失敗之前必須等候的逾時次數，是由 Set-TransportConfig 指令程式的 ShadowHeartbeatRetryCount 參數所控制。

若要深入了解陰影備援活動訊號的詳細設定資訊，請參閱設定陰影備援。

回到頁首

運作中斷後的郵件處理

陰影備援可將伺服器運作中斷後，所遺失的郵件數量降到最低。一旦傳輸伺服器在運作中斷後重新上線，會出現以下兩種情況：

• 伺服器會透過新的傳輸伺服器重新上線   在此案例中，傳輸資料庫將無法在資料中斷或硬體失敗之後復原。在此情況下，由於傳輸伺服器將擁有全新的資料庫 ID，組織裡的其他傳輸伺服器會將其識別為新的路由。當某一台伺服器無法復原，而由另一台全新的伺服器加以取代時，也會發生這種情況。

• 伺服器透過相同的傳輸資料庫重新上線   在此案例中，特殊的傳輸伺服器沒有失敗，而是離線很長一段時間。例如，網路卡失敗，或是伺服器上冗長的維護作業都會導致這種情況。

下表摘要說明傳輸伺服器在啟用陰影備援時，對以上兩種情況的因應之道。為清楚說明，我們假定運作中斷的伺服器名為 Hub01。

在復原案例中處理郵件

回到頁首

陰影備援所需的延伸權限

Exchange 2010 介紹下列兩種陰影備援需要的延伸權限：

• ms-Exch-SMTP-Accept-XSHADOW

• ms-Exch-SMTP-Send-XSHADOW

一旦與 Exchange 2010 傳輸伺服器建立 SMTP 連線，當所使用的接收連接器上具有 ms-Exch-SMTP-Accept-XSHADOW 延伸權限時，該伺服器就會通告陰影備援支援。此外，接收連接器上的驗證機制，應該是 Exchange Server 驗證或是外部保護。

一旦 Exchange 2010 傳輸伺服器與另一台通告陰影備援支援的伺服器建立 SMTP 連線，只有當系統授與工作階段 ms-Exch-SMTP-Send-XSHADOW 延伸權限時，該伺服器才會發出 XSHADOW 命令。

根據預設，這些延伸權限會授與所有內部傳送連接器，與接收連接器上的 Exchange Servers 群組。

附註：
您可以透過 Set-TransportConfig 指令程式的 ShadowRedundancyEnabled 參數，來啟用或停用整個組織的陰影備援。此設定會覆寫這一節中所述的延伸權限。一旦組織停用陰影備援，Exchange 將永遠不會通告陰影備援支援或是發出 XSHADOW 命令，即使已經將必要的延伸權限授與 SMTP 工作階段亦然。

回到頁首

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