哇 COW!Exchange 2010 SP2 RU3 中 Recoverable Items 版本設定的變更
英文原文已於 2012 年 6 月 1 日星期五發佈
過去幾個月來,我們收到關於可復原的項目資料夾 (俗稱「垃圾桶」,雖然我們已正名了) 容量暴增的回報。造成檔案大小暴增的原因主要有兩個:
- 「單項復原」和訴訟暫止的版本設定
- 行事曆版本記錄
「單項復原」和「訴訟暫止」可讓資料保存在信箱內部。若您不熟悉這些功能,我之前有篇文章 Exchange 2010 中的單項復原 (可能為英文網頁) 內有詳細說明,歡迎參考。
除了將資料保存在信箱內部外,「單項復原」和「訴訟暫止」也啟用了版本設定。實質上就是說,當有項目變更時,系統就會執行一次「寫入時複製」(copy-on-write,簡稱 COW) 以保存該物件的原始版本。原始項目會置於 Recoverable Items\Versions 資料夾中。此資料夾使用者是看不到的。
由於 Exchange 2010 在用戶端連線與存取信箱相關資料的方式上有一點改變,此 COW 活動會出現在用戶端存取伺服器上的 Exchange 系統物件 (XSO) 層。
- 對於訊息與貼文 (IPM.Note* 和 IPM.Post*),COW 會捕捉主題、本文、附加檔案、寄件人/收件人以及寄送/收到日期的變更。
- 對於其他類型的項目,COW 會捕捉一切對該項目所做的變更,但資料夾之間的移動以及讀取/未讀取狀態的變更除外。
- 草稿自動儲存時會被 COW 排除在外,以避免產生過多的複本。
COW 的行為可能就是罪魁禍首。我們的調查結果發現,在下列使用 Microsoft Outlook 的案例中,會造成過度 COW 的主因:
- 您在行事曆中建立了一筆約會。
- 您附加了一份 Office 文件到該約會並加以儲存
- 稍後,您想要打開這筆約會,以對照那份 Office 文件內寫的某些內容。於是您開啟了文件。
- Outlook 會在幕後開始自動儲存這份開啟的約會,以及相對應的開啟文件 (Outlook 預設每隔 3 分鐘就會自動儲存一次)。
- 每筆自動儲存事件只會觸發一次 COW。但由於此自動儲存需同時儲存 Office 文件和約會兩者,因而就產生兩筆 COW 事件了。若還有更多的附加檔案,則每個後續的檔案都會再額外產生一個隨之而來的 COW 版本。
這下可好了。
既然附加檔案算是訊息的一部分,為每個項目的每個附加檔案分別建立複本實在沒什麼道理。當您儲存一封有附加檔案的項目時,Outlook 實際上是執行了下列動作:
- CreateAttachment
- SaveAttachment
- SaveMessage
COW 則是發生在 SaveAttachment 和 SaveMessage 的階段。深入研究程式碼後,我們發現呼叫 SaveAttachment 儲存附加檔案後,最終將會在與它相關的信件上呼叫 Flush 方法 (用戶端與伺服器狀態同步的一種方法)。而不斷通報 COW 程式碼發生作用的,就是這個 Flush 方法。
經過進一步的分析,我們發現只要有「任何」Flush 呼叫,都會觸發 COW 的運作邏輯。這真是個重大的發現,因為在許多種情況下,都可能會啟動到 Flush,進而導致出現上千筆 COW 活動,也就是過去幾位客戶在他們的環境下遭遇的情況。
隨著 Exchange 2010 SP2 RU3 和更新版本的推出,COW 現在已能分辨 Flush 和 Save 作業的差異,也只有在發生 Save 作業時才會觸發了。
「行事曆版本記錄」是當發生在信箱內部的行事曆變更要透過 COW 儲存時,所進行的程序。「行事曆版本記錄」是 Exchange 2010 推出的新功能,目的是為了協助診斷和修復行事曆的可靠性問題。
行事曆版本記錄的設計,會在每次有行事曆項目被更動時,自動建立一份記錄。這些記錄全部組合在一起,就構成了完整的會議歷史。您可以使用 Get-CalendarDiagnosticLog Cmdlet 查閱此歷史記錄,並依此判定哪些客戶曾採取了破壞性的舉動。「行事曆版本記錄」的第二項用途,是它可以讓行事曆修復小幫手在偵測某行事曆項目不一致的情形時,拿來當做判定的依據。
在 Exchange 2010 的信箱上預設啟用「行事曆版本記錄」。您也可以從 CalendarVersionStoreDisabled 屬性停用或加以啟用。請注意,它的屬性名稱是 CalendarVersionStoreDisabled,所以如果將預設值設成 $false 代表「行事曆版本記錄」預設為啟用。依信箱設定之不同,隨後儲存行事曆項目複本的程序可能會有所不同:
- 如果信箱未啟用「單項復原」或「訴訟暫止」,縮減版的行事曆項目會保存在 Recoverable Items 資料夾的根目錄下 120 天。此縮減版 (已移除本文和重要性非第一級或非內嵌訊息類型的附加檔案) 是由 COW 所建立。
- 如果信箱已啟用「單項復原」或「訴訟暫止」,Recoverable Items\Deletions 或 Recoverable Items\Versions 資料夾中則會保存完整版的行事曆項目。每當有 Recoverable Items\Deletions 或 Recoverable Items\Versions 資料夾中的行事曆項目受到實際刪除的動作時,就會經由 COW 的基礎架構建立一個縮減的版本。此縮減版會置於 Recoverable Items 資料夾的根目錄中 120 天。不會建立縮減版的唯一情況,是當 Recoverable Items\Deletions 或 Recoverable Items\Versions 資料夾中某項目的保存時間已超過 134 天 (120 + 14) 時。如果您變更了保留時限,如果很久未執行「信箱資料夾助理」,或如果「訴訟暫止」已停用等,就有可能會發生此情況。
由於上述有關 COW 運作邏輯未分辨 Flush 和 Save 作業的問題,「行事曆版本記錄」在某些情況下,有可能佔用掉 Recoverable Items 資料夾容量配額的一大塊空間 (如果您還記得的話,警告臨界值是 20GB,固定配額是 30GB)。
雖然 SP2 RU3 已解決 COW 的問題,但為了化解「行事曆版本記錄」可能佔用掉 Recoverable Items 資料夾全部配額的疑慮,在 SP2 RU2 中我們引進了一項架構上的變更,藉此「行事曆版本記錄」如今在啟動 COW 之前,會先將 Recoverable Items 資料夾的大小列入考量。
如果該資料夾大小超過 RecoverableItemsWarningQuota,信箱就會停用「行事曆版本記錄」。其所參考的 RecoverableItemsWarningQuota 值會依信箱設定而異:
- 如信箱的 UseDatabaseQuotaDefaults 設為 $true,就會參考該信箱資料庫的 RecoverableItemsWarningQuota。
- 若信箱的 UseDatabaseQuotaDefaults 設為 $false,則會參考該信箱的 RecoverableItemsWarningQuota。
當「行事曆版本記錄」停用時,用戶端存取伺服器上的應用程式事件記錄中就會產生下列事件:
Event ID: 5003
Source: MSExchange Mid-Tier Storage
Task Category: CopyOnWrite
Level: Information
Description: User mailbox <legacyExchangeDN> has exceeded the dumpster warning quota. Calendar logging has been disabled for the mailbox.
我們想做的事還不只如此。此開發目前尚屬早期階段,我不打算討論詳情,但我可以說我們正在努力進一步改善「行事曆版本記錄」,以使本功能對您部署的負面影響降到最低。待時機成熟,我便會透過本部落格向大家報告更多消息。
Ross Smith IV
首席專案經理
Exchange 客戶經驗部
這是翻譯後的部落格文章。英文原文請參閱 Holy COW! Changes to Recoverable Items versioning in Exchange 2010 SP2 RU3