共用方式為

Exchange Server中的陰影備援

  • 發行項

陰影備援是在 Exchange 2010 中引進，可在訊息傳遞至信箱之前提供備援的郵件複本。 在 Exchange 2010 中，陰影備援延遲從中樞傳輸伺服器上的佇列資料庫刪除訊息，直到伺服器確認訊息傳遞路徑中的下一個躍點已完成傳遞為止。 如果下一個躍點在回報成功傳遞回中樞傳輸伺服器之前失敗，伺服器會將訊息重新提交至下一個躍點。 Exchange 2010 Hub Transport Server 使用 XSHADOW 動詞來公告其陰影備援支援。 如果來源傳訊伺服器不支援陰影備援，Exchange 2010 會根據接收連接器上設定的時間間隔，使用延遲通知來建立訊息的備援複本。

Exchange 2016 和 Exchange 2019 具有對 Exchange 2013 中陰影備援所做的相同改善：信箱伺服器上的傳輸服務現在會先備援所收到的任何訊息複本，再確認將訊息接收到傳送伺服器。 維護傳輸中訊息的備援複本不只是可能無法運作的最佳工作，因為現在陰影備援不會相依于傳送伺服器的支援功能 (支援或缺少陰影備援的支援，) 無關緊要。 這有助於確保傳輸管線中的所有訊息在傳輸時都會變成備援。 如果 Exchange 判斷原始訊息在傳輸過程中遺失，則會重新傳遞訊息的備援複本。

如需在 Exchange Server 中傳輸高可用性功能的詳細資訊，請參閱在Exchange Server 中傳輸高可用性。 如需成功傳遞訊息後訊息備援的詳細資訊，請參閱Exchange Server 中的安全網。

陰影備援元件

下表描述信箱伺服器上傳輸服務中陰影備援的元件。 這些詞彙會在整個主題中使用。

術語 描述
傳輸高可用性界限 資料庫可用性群組 (DAG 環境中的 DAG) ，或非 DAG 環境中的 Active Directory 月臺。 對於跨越多個 Active Directory 月臺的 DAG，DAG 本身仍然是界限 (不是月臺) 。

當郵件抵達傳輸高可用性界限的信箱伺服器時，Exchange 會嘗試在界限內的信箱伺服器上維護郵件的兩個備援複本。 當訊息離開傳輸高可用性界限時，Exchange 會停止維護訊息的備援複本。
主要訊息 送出至傳輸管線以進行傳遞的訊息。
陰影訊息 陰影伺服器保留之訊息的備援複本，直到確認主伺服器已成功處理主要訊息為止。
主伺服器 目前正在處理主要訊息的信箱伺服器。
陰影伺服器 保存主伺服器陰影訊息的信箱伺服器。 信箱伺服器可能是某些訊息的主伺服器，而其他訊息則是陰影伺服器。
陰影佇列 陰影伺服器儲存陰影訊息的傳遞佇列。 對於具有多個收件者的郵件，主要訊息的每個下一個躍點都需要個別的陰影佇列。
捨棄狀態 信箱伺服器針對陰影訊息所維護的資訊，表示已成功處理主要訊息。
捨棄通知 陰影伺服器從主伺服器接收的回應，指出陰影訊息已準備好要捨棄。
安全網 Exchange 2013 或更新版本中已改善的傳輸傾印機版本。 信箱伺服器上的傳輸服務成功處理或傳遞至信箱收件者的郵件會移至安全網。 如需詳細資訊，請參閱Exchange Server 中的安全網。
陰影備援管理員 管理陰影備援的傳輸元件。
活動訊號 允許主伺服器和陰影伺服器驗證彼此可用性的程式。

陰影備援的需求

雖然看起來很明顯，但陰影備援需要多部信箱伺服器：

  • 如果信箱伺服器不是 DAG 的成員，則其他信箱伺服器必須位於本機 Active Directory 網站。

  • 如果信箱伺服器是 DAG 的成員，則其他信箱伺服器必須屬於相同的 DAG。 其他 DAG 成員可以位於本機 Active Directory 網站或遠端月臺中。 根據預設，如果 DAG 跨越多個 Active Directory 月臺，陰影備援會偏好在遠端月臺中建立訊息的備援複本，以進行月臺復原。

以下是陰影備援無法保護傳輸中訊息的情況：

  • 在單一 Exchange 伺服器環境中。

  • 在布建不足的 DAG 中。

  • 在涉及訊息陰影備援的兩部或多部信箱伺服器同時失敗期間。

預設會啟用陰影備援

根據預設，所有信箱伺服器上的傳輸服務會全域啟用陰影備援。 下表描述啟用陰影備援的參數。

參數 預設值 描述
Set-TransportConfig上的ShadowRedundancyEnabled $true $true：組織中的所有信箱伺服器上都會啟用陰影備援。

$false：組織中的所有信箱伺服器上都會停用陰影備援。
Set-TransportConfig上的RejectMessageOnShadowFailure $false $false：無法建立郵件的陰影複本時，組織中的信箱伺服器還是會接受主要訊息。 這些訊息在傳輸中時不會重複保存。

$true：在成功建立郵件的陰影複製之前，組織中的任何信箱伺服器不會接受或認可任何訊息。 如果無法建立訊息的陰影複製，則會拒絕主要訊息並出現暫時性錯誤，但傳送伺服器可以再次傳輸訊息。 SMTP 回應碼為 451 4.4.0 Message failed to be made redundant 。 組織中的所有訊息都會在傳輸中時重複保存。

注意： $true 只有當您在同一個 DAG 或 Active Directory 網站中有多個信箱伺服器，才能建立訊息的陰影複本時，才使用 。

只有當 ShadowRedundancyEnabled 為 時，這個參數才有 $true 意義。

如何建立陰影訊息

陰影備援的主要目標是在訊息傳輸時，一律在傳輸高可用性界限內擁有兩份訊息複本。 訊息備援複本的建立位置和時間取決於訊息的來源，以及訊息的來源。 建立陰影訊息有三個決定因素：

  • 從傳輸高可用性界限外部接收的訊息 (DAG，或非 DAG 環境中的 Active Directory 月臺) 。

  • 在傳輸高可用性界限外傳送的訊息。

  • 從信箱傳輸提交服務從傳輸高可用性界限內的信箱伺服器接收到的訊息。

陰影備援永遠不會跨傳輸高可用性界限追蹤陰影訊息。 當訊息跨越傳輸高可用性界限時，陰影備援會開始或重新開機。 這可減少陰影訊息維護流量，並防止跨傳輸高可用性界限重新提交陰影訊息。 Exchange 2010 Hub Transport Server 是特殊案例，稍後會在本主題中討論。

從傳輸高可用性界限外部接收的訊息

當信箱伺服器上的傳輸服務收到來自傳輸高可用性界限外部的訊息時，信箱伺服器不會擔心傳送伺服器支援或缺乏陰影備援的支援。 只要啟用陰影備援，接收訊息的信箱伺服器就會在傳輸高可用性界限內的另一部信箱伺服器上建立訊息的備援複本，然後才確認接收回傳送伺服器的郵件。 以下是程式運作方式的範例：

陰影訊息建立。

  1. 訊息伺服器會將訊息傳輸至信箱伺服器上的傳輸服務。 信箱伺服器是主伺服器，而訊息是主要訊息。

  2. 雖然傳訊伺服器的原始 SMTP 會話仍在作用中，但是主伺服器上的傳輸服務會開啟新的同時 SMTP 會話，並在組織中不同的信箱伺服器上與 Transport 服務一起開啟，以建立訊息的備援複本。

    • 如果主伺服器是 DAG 的成員，主伺服器會連線到相同 DAG 中不同的信箱伺服器。 如果 DAG 跨越多個 Active Directory 網站，則預設會偏好使用不同 Active Directory 網站中的信箱伺服器， (Set-TransportConfig Cmdlet 上ShadowMessagePreferenceSetting參數的預設值為 PreferRemote ，但您可以將它變更為 RemoteOnly 或 LocalOnly) 。

    • 如果主伺服器不是 DAG 的成員，則無論 ShadowMessagePreferenceSetting 參數的值為何，主伺服器都會連線到相同 Active Directory 月臺 (中不同的信箱伺服器) 。

  3. 主伺服器會將訊息複本傳輸到另一部信箱伺服器上的傳輸服務，而另一部信箱伺服器上的傳輸服務則確認已成功建立郵件複本。 訊息的複本是陰影訊息，而保存它的信箱伺服器則是主伺服器的陰影伺服器。 訊息存在於陰影伺服器的陰影佇列中。

  4. 主伺服器收到來自陰影伺服器的認可之後，主伺服器會在原始 SMTP 會話中認可接收到原始訊息伺服器的主要訊息，且 SMTP 會話已關閉。

在傳輸高可用性界限外傳送的訊息

當信箱伺服器在傳輸高可用性界限外傳輸訊息，而另一端的訊息伺服器認可成功接收訊息，而信箱伺服器將訊息移至安全網時。 成功跨傳輸高可用性界限傳輸主要訊息之後，就無法從安全網重新提交訊息。 如需 Safety Net 的詳細資訊，請參閱Exchange Server 中的安全網。

傳輸高可用性界限內傳輸的訊息

訊息路由已優化，因此當最終目的地位於 DAG 或 Active Directory 月臺時，通常不需要目的地 DAG 或月臺內伺服器之間的多個躍點。 在目的地 DAG 或 Active Directory 中信箱伺服器上的傳輸服務接受郵件之後，訊息的下一個躍點通常是最終目的地本身 (例如，保存目的地信箱作用中複本的信箱伺服器) 。 當 DAG 或 Active Directory 網站內 的任何 位置都存在訊息的一個陰影複製時，陰影備援的目標就是在傳輸中保留兩份訊息複本。 一般而言，只有 DAG 中需要 Redirect-Message Cmdlet 以清空信箱伺服器上作用中訊息佇列的容錯移轉案例，才需要相同傳輸高可用性界限內的多個躍點。

在 Exchange 2016 組織的相同 Active Directory 網站中使用 Exchange 2010 中樞傳輸伺服器的陰影備援

當 Exchange 2010 中樞傳輸伺服器將訊息傳輸至相同 Active Directory 網站中的 Exchange 2016 信箱伺服器時，Exchange 2010 中樞傳輸伺服器會使用 XSHADOW 命令公告陰影備援的支援，但信箱伺服器不會公告陰影備援的支援。 這可防止 Exchange 2010 Hub Transport Server 在 Exchange 2016 信箱伺服器上建立郵件的陰影複本。

當 Exchange 2016 信箱伺服器上的傳輸服務將訊息傳輸至相同 Active Directory 月臺中的 Exchange 2010 中樞傳輸時，Exchange 2016 信箱伺服器會遮蔽 Exchange 2010 Hub Transport Server 的訊息。 在 Exchange 2016 信箱伺服器收到 Exchange 2010 中樞傳輸伺服器的確認訊息已成功接收之後，Exchange 2016 信箱伺服器會將已成功處理的郵件移至安全網。 不過，Exchange 2016 信箱儲存在 Safety Net 中成功處理的郵件永遠不會重新提交至 Exchange 2010 中樞傳輸伺服器。

SMTP 逾時

嘗試建立訊息的備援複本期間，傳送伺服器與主伺服器 (伺服器之間的 SMTP 連線，或主伺服器與陰影伺服器) 之間的 SMTP 連線可能會逾時。 當資料實際在連接器上傳輸時，接收連接器和傳送連接器都有 ConnectionInactivityTimeOut 參數。 接收連接器也有絕對 ConnectionTimeOut 參數。

如果在成功建立並認可訊息陰影複製之前，任何 SMTP 會話逾時，結果會由Set-TransportConfig Cmdlet 上的RejectMessageOnShadowFailure參數控制。 根據預設，此參數的值為 $false ，這表示不需建立陰影複製，就會接受主要訊息。 如果此參數的值為 $true ，則會拒絕主要訊息，並出現暫時性錯誤 451 4.4.0 。

如果成功建立訊息的陰影複製，但傳送伺服器與主伺服器之間的 SMTP 會話逾時，主伺服器會接受並處理主要訊息。 傳送伺服器會重新傳遞未確認的郵件，但重複的訊息偵測會防止 Exchange 信箱使用者看到重複的郵件。 當傳送伺服器重新提交訊息時，主伺服器會建立另一個訊息陰影複本。 傳送伺服器在訊息重新提交期間建立的陰影訊息之間沒有任何關聯性。

下表描述控制陰影訊息建立的參數

來源 預設值 描述
Set-TransportConfig上的ShadowMessagePreferenceSetting PreferRemote 只有當嘗試製作訊息陰影複製的主伺服器是跨越多個 Active Directory 月臺的 DAG 成員時，才會使用此參數。
  • PreferRemote：根據 MaxRetriesForRemoteSiteShadow 參數所指定的嘗試次數，嘗試在不同 Active Directory 網站的 DAG 成員上製作訊息的陰影複製。 如果作業失敗，請嘗試根據 MaxRetriesForLocalSiteShadow 參數所指定的嘗試次數，在本機 Active Directory 網站的 DAG 成員上製作訊息的陰影複製。
  • LocalOnly：請嘗試根據 MaxRetriesForLocalSiteShadow 參數所指定的嘗試次數，只在本機 Active Directory 網站的 DAG 成員上製作訊息的陰影複製。
  • RemoteOnly：嘗試只根據 MaxRetriesForRemoteSiteShadow 參數所指定的嘗試次數，在不同 Active Directory 網站的 DAG 成員上複製訊息。
Set-TransportConfig上的MaxRetriesForRemoteSiteShadow 4 當 ShadowMessagePreferenceSetting 參數的值 (預設值時，這個參數 PreferRemote 會指定在 DAG 中的另一部伺服器上建立訊息陰影複製的嘗試次數上限，) 或 RemoteOnly 。

只有當信箱伺服器是跨多個 Active Directory 網站的 DAG 成員時，才會使用此參數。

如果在指定的嘗試次數之後未成功建立訊息的陰影複製，則結果取決於 RejectMessageOnShadowFailure 參數的值：

  • $true：主要訊息遭到拒絕，並出現暫時性錯誤。
  • $false：主要訊息還是會被接受，但不會重複保存。
Set-TransportConfig上的MaxRetriesForLocalSiteShadow 2 當下列情況下，此參數會指定嘗試在本機 Active Directory 網站的另一部信箱伺服器上建立郵件陰影複製的次數上限：
  • 信箱伺服器是跨越多個 Active Directory 網站的 DAG 成員， 而 ShadowMessagePreferenceSetting 參數 PreferRemote 的值會 (預設值) 或 LocalOnly 。
  • 信箱伺服器是位於一個 Active Directory 網站的 DAG 成員。
  • 信箱伺服器不是 DAG 的成員。

如果在指定的嘗試次數之後未成功建立訊息的陰影複製，則結果取決於 RejectMessageOnShadowFailure 參數的值：

  • $true：主要訊息遭到拒絕，並出現暫時性錯誤。
  • $false：主要訊息還是會被接受，但不會重複保存。
Set-ReceiveConnector上的ConnectionInactivityTimeout 信箱伺服器上傳輸服務中的接收連接器 5 分鐘 此參數會指定在關閉連線之前，來源傳訊伺服器開啟的 SMTP 連線可以保持閒置的時間上限。 此參數的值必須大於 ConnectionTimeout 參數的值。
Set-ReceiveConnector上的ConnectionTimeout 信箱伺服器上傳輸服務中的接收連接器 10 分鐘 此參數會指定即使伺服器正在傳輸資料，與來源傳訊伺服器的 SMTP 連線仍可保持開啟的最長時間。 此參數的值必須大於 ConnectionInactivityTimeout 參數的值。
Set-SendConnector上的ConnectionInactivityTimeOut 10 分鐘 此參數指定在關閉連線之前，與目的郵件伺服器的開啟 SMTP 連線可以持續閒置的時間上限。

如何維護陰影訊息

成功建立陰影訊息之後，陰影備援的工作才剛開始。 主伺服器和陰影伺服器必須彼此保持聯繫，才能追蹤訊息的進度。

當主伺服器成功將訊息傳輸到下一個躍點，而下一個躍點認可收到訊息時，主伺服器會在傳遞完成時更新訊息的 捨棄狀態 。 捨棄狀態基本上是包含受監視訊息清單的訊息。 成功傳遞的訊息不需要保留在陰影佇列中，因此，一旦陰影伺服器知道主伺服器已成功將訊息傳輸到下一個躍點，陰影伺服器就會將陰影訊息從陰影佇列移至 Safety Net。

陰影伺服器會藉由查詢主伺服器來判斷陰影佇列中陰影訊息的捨棄狀態。 如果陰影伺服器因為任何原因而開啟與主伺服器的 SMTP 會話 (包括其他不相關訊息的傳輸) ，陰影伺服器會發出 XQDISCARD 命令來判斷主要訊息的捨棄狀態。 否則，在Set-TransportConfig Cmdlet 上的ShadowHeartbeatFrequency參數 (預先設定的時間間隔之後，陰影伺服器會自動開啟與主伺服器的 SMTP 會話;預設值為 2 分鐘) 。

在陰影伺服器開啟與主伺服器的 SMTP 會話之後，主伺服器會回應套用至查詢陰影伺服器之訊息 的捨棄通知 。 捨棄通知會儲存在磁片上 (不在記憶體) 因此，如果 Microsoft Exchange Transport 服務重新開機，捨棄通知會持續存在。 服務啟動之後，主伺服器仍然知道它已成功處理的訊息，而且該資訊可供陰影伺服器使用。

陰影伺服器與主伺服器之間的 SMTP 通訊會作為決定伺服器可用性 的活動訊號 。 如果在預先設定的時間間隔之後，陰影伺服器無法開啟與主伺服器的 SMTP 會話， (Set-TransportConfig Cmdlet 上的ShadowResubmitTimeSpan參數;) 陰影伺服器將本身升級為主伺服器、將陰影訊息升階為主要訊息，並將訊息傳輸至下一個躍點時，預設值為 3 小時。 但是，每當陰影伺服器偵測到主伺服器的佇列資料庫識別碼已變更時，陰影伺服器也會將自己升級為主伺服器、將陰影訊息升階為主要訊息，並將訊息傳輸到下一個躍點。 這可能會在 ShadowResubmitTimeSpan 參數值通過之前發生。

陰影備援管理員 是信箱伺服器上負責管理陰影備援的核心元件。 陰影備援管理員負責維護伺服器目前正在處理之所有主要訊息的下列資訊：

  • 正在處理之每個主要訊息的陰影伺服器。

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

陰影備援管理員會針對陰影伺服器在其陰影佇列中擁有的所有陰影訊息負責下列動作：

  • 維護每個陰影訊息的主伺服器清單。

  • 比較儲存訊息主要複本之佇列資料庫的原始資料庫識別碼和目前資料庫識別碼。

  • 檢查陰影訊息排入佇列的每部主伺服器的可用性。

  • 處理從主伺服器捨棄通知。

  • 在收到所有預期的捨棄通知之後，從陰影佇列中移除陰影訊息。

  • 決定陰影伺服器何時應取得陰影訊息的擁有權，成為主伺服器。

  • 追蹤訊息交換和其他副作用訊息，例如傳遞狀態通知 (也稱為 DSN、非傳遞報告、DDR 或退回的訊息) 和日誌報告，以確認在完整處理訊息的所有分支之前，不會釋放訊息的備援複本。

下表描述控制陰影訊息維護方式的參數。

參數 預設值 描述
Set-TransportConfig上的ShadowHeartbeatFrequency 2 分鐘 陰影伺服器在開啟與主伺服器的 SMTP 連線之前等待的時間上限，以檢查訊息的捨棄狀態。
Set-TransportConfig上的ShadowResubmitTimeSpan 3 小時 伺服器在決定主伺服器失敗之前等待多久，並假設無法連線主伺服器的陰影佇列中有陰影訊息的擁有權。

請注意，當主伺服器的佇列資料庫找到不同的資料庫識別碼時，陰影伺服器也可以將自己升級為主伺服器，再將此參數的值升級為主伺服器。
Set-TransportConfig上的ShadowMessageAutoDiscardInterval 2 天 伺服器保留捨棄事件的時間長度，以便成功傳遞訊息。 主伺服器佇列會捨棄事件，直到陰影伺服器查詢為止。 不過，如果陰影伺服器未在此參數中指定的持續時間內查詢主伺服器，主伺服器就會刪除佇列捨棄事件。
Set-TransportConfig上的SafetyNetHoldTime 2 天 成功處理的訊息會保留在 Safety Net 中多久。 在Set-TransportService Cmdlet 上SafetyNetHoldTime和MessageExpirationTimeout參數值的總和之後，未認可的陰影訊息最終會從 Safety Net 過期。
Set-TransportService上的MessageExpirationTimeout 2 天 訊息在到期之前，可以在佇列中保留多久的時間。

中斷後的訊息處理

下表摘要說明陰影備援如何將伺服器中斷所造成的訊息遺失降至最低。 為了清楚起見，發生中斷的伺服器名為 Mailbox01。

復原案例 採取的動作
Mailbox01 會在 ShadowResubmitTimeSpan 參數的值預設傳遞 (之前，使用新的佇列資料庫重新上線，) 3 小時。

當佇列資料庫因為資料損毀或硬體故障而無法復原時，就會發生此案例。

 在 Mailbox01 上偵測到新的佇列資料庫識別碼時，針對 Mailbox01 排入佇列之陰影訊息的每部伺服器都會採用這些訊息的擁有權，並重新提交這些訊息。 訊息接著會傳遞至其目的地。

偵測到新佇列資料庫之後，訊息提交的最大延遲是 ShadowHeartbeatFrequency 參數的值預設 (，) 2 分鐘。
在 ShadowResubmitTimeSpan 參數的值預設傳遞 (3 小時之後，Mailbox01 會以相同的資料庫重新上線，) 3 小時。

此案例可能會在網路卡故障或伺服器上耗時的維護之後發生。

 在 Mailbox01 重新上線之後，它會在其佇列中傳遞郵件，這些訊息已由保存 Mailbox01 訊息陰影複本的伺服器所傳遞。 這會導致這些訊息的傳遞重複。 Exchange 信箱使用者不會因為重複的郵件偵測而看到重複的郵件。 不過，其他訊息系統上的收件者可能會看到重複的訊息複本。

訊息提交的最大延遲是 ShadowResubmitTimeSpan 參數的值。