微軟公司針對Exchange Server 2010在一些底層數據結構上作了一些主要的變更，而這些顯著的變更會對后續的針對Exchange Server 2010的存儲需求和部署帶來較大的影響。
微軟所作的最大的變更則是去掉了單一實例存儲(single-instance storage，SIS)。在之前的版本中，如果一條消息被轉發給多個收件人，那么只有這條消息的一份副本會被存儲到mailbox數據庫中。用戶將會收到針對這份單一副本的一個指針而不是這個副本的完全拷貝。
那么，既然微軟取消了對單一實例存儲的支持，也就意味著同樣的消息會被發送給多個收件人，每個收件人都會受到一份實體消息副本。從存儲空間規劃角度來看，這個巨大變更對規劃的影響，主要取決于帶有附件的郵件的數量了。
文本或者HTML格式的消息一般都是非常小的，所以它們對存儲空間規劃的影響不會很大，而且微軟針對這些消息都會有自動壓縮機制以進一步降低影響。然而，如果你的環境中總是有用戶不斷的發送帶有大附件的郵件給多個收件人的話，那么這些郵件就會對數據庫的增量產生較大影響。微軟這次重新設計數據庫底層架構的目標就是為了降低數據庫的I/O負載續期。所以，微軟這次選擇了不對郵件附件進行壓縮，以便節省壓縮/解壓縮過程中對存儲I/O的額外耗費。
看起來可能有些奇怪，曾幾何時，存儲管理領域在大肆搞數據縮減，比如重復數據刪除等，但是為何微軟這次卻在Exchange Server 2010中去掉了數據縮減功能。因為微軟如果針對Exchange郵箱數據庫放棄使用單一實例存儲的話，那么數據庫會運作的更加高效，微軟宣稱，Exchange Server 2010的數據庫I/O負載需求已經有了大概70%的降低。
另外一種經常使用的能夠保持 Exchange Server 2010郵箱數據庫不至于變得太大的辦法就是使用郵箱限額。郵箱限額功能可以防止某郵箱的尺寸超過預設的大小。在Exchange Server 2010中，郵箱限額的功能與之前的版本幾乎都一致，除了一點之外。Exchange Server 2010引入了一個叫做歸檔郵箱的概念(我們稍后討論)。如果某個用戶擁有一個歸檔郵箱，那么郵箱限額在計算這個用戶到底使用了多少底層空間的時候，并不將歸檔郵箱的內容尺寸算在里面。Exchange同時也允許你通過額外的限額配置來專門針對歸檔郵箱做限額。
郵箱限額這個功能是一個被充分證明很有效的用于限制數據存儲過快被占用的方法。但是微軟一直在鼓勵企業使用低成本的存儲系統而不是用郵箱限額來節省成本。其出發點是企業可以在保證郵箱數據不斷增長的前提下，避免花費太多成本在昂貴的存儲系統和解決方案上。
之所以推薦使用低成本的存儲系統，并不只是基于單純存儲的成本考慮的。很多企業被迫對郵箱設置非常嚴格限額策略，以至于對應的郵箱用戶不得不將一些重要的郵件也刪除掉。顯然，如果使用廉價的存儲系統，那么企業就可以放開設置郵箱限額，甚至根本不適用限額了。
之前，在Exchange Server環境中使用最低端的廉價存儲系統好像是一件前所未聞的事情，但是本次Exchange Server 2010中對I/O負載需求的降低使得諸如SATA硬盤這種存儲選項變得可以接受了。而且Exchange Server 2010對底層可使用存儲的要求已經非常靈活了，它可以使用直連存儲(direct-attached storage，DAS)或者存儲區域網絡SAN設備，甚至也可以使用經由iSCSI協議連接的存儲。然而，微軟在Exchange Server方面卻并不支持那種必須映射成一個網絡盤符才可以存取數據的存儲，比如NAS。所以，Exchange Server并不支持在NAS中存儲郵箱數據庫，除非這臺NAS支持使用iSCSI協議訪問。
額外的考慮
雖然地段存儲系統也可以提供足夠的性能，但是依然有必要選擇一臺能夠同時滿足企業可靠性需求的存儲系統。比如，如果你選用了基于SATA硬盤的存儲系統，那么你最好創建一個具有較高容錯性的SATA Raid組。微軟推薦使用基于RAID10模式的Raid。某些企業也選擇使用Raid5，因為Raid5相比Raid10來講更加廉價經濟，而且仍然能夠提供容錯性，但是通常認為Raid10能夠提供更好的性能。
數據庫的大小對性能沒有直接的影響。通常來講，一臺單獨的郵箱服務器上的郵箱數據庫的大小應該被限制在200GB或者更少。如果某個郵箱數據庫增長到大于200GB了，此時你可以將數據庫分割為多個更小的數據庫。對于Database Availability Group中的郵箱數據庫，推薦的最大數據庫尺寸為2TB。
判斷存儲需求
在一個Exchange Server 2010的部署環境中，判斷出準確的存儲需求是個不小的工作，但是微軟提供了一個免費的工具可以用來協助你完成這項任務。Exchange 2010 Mailbox Server Role Requirements Calculator (http://msexchangeteam.com/files/12/attachments/entry453145.aspx)是一個 Excel擴展表，它可以根據你的企業對Exchange的使用情況來判斷Exchange Server對存儲的需求。
使用 Exchange 2010 Mailbox Server Role Requirements Calculator 時，你只需回答一系列如Exchange Server的配置和使用情況相關的問題，要填入一系列的表格單元值即可完成。例如，表格中會問你平均每份郵件的大小以及每天用戶可能發送的郵件數量等問題。表格中內置的腳本會根據你所回答問題的答案來自動計算出存儲的各方面需求。
但是要注意一點，雖然Exchange 2010 Mailbox Server Role Requirements Calculator可能是用來預估Exchange郵箱服務器對存儲需求的最好的工具，但是它的一些推薦頁僅僅是根據你所提供的數據所計算出的，所以它 的準確性完全依賴于你所提供的數據的準確性。為了保險起見，微軟推薦提供足夠的磁盤空間，至少是所計算出的所需空間的120%。
Exchange歸檔郵箱
在影響Exchange Server存儲規劃的因素中，還有一些其他需要考慮的，比如你是否需要實施用戶歸檔郵箱，這是Exchange Server提供的一個新的，而且是可選的功能。用戶歸檔郵箱相對于主郵箱來講屬于一種二級郵箱，它專門用于存放一些長期不了瀏覽的郵件。歸檔郵箱與 Exchange歸檔模式之間的區別是，前者不是一種傳統的歸檔，比如日志郵箱，而是用戶依然擁有歸檔郵箱中的郵件。所以，用戶的歸檔郵箱也是隨時可以被訪問的。
歸檔郵箱是被設計用來替換PST文件的。但是并不像PST文件，歸檔郵箱會被存儲在可被管理員管理的郵箱數據庫中。
在一開始的Exchange 2010 RTM版本中，用戶歸檔郵箱與用戶的主郵箱是一同被存儲在相同的郵箱數據庫中的。在SP1版本中，微軟提供了選項，可以將用戶歸檔郵箱重定向存儲到一個單獨的郵箱數據庫中，從而可以讓針對歸檔郵箱的訪問I/O卸載到其他存儲空間，從而防止對主郵箱訪問的影響。
微軟通常會推薦將用戶歸檔郵箱存儲在低端的服務器上以及低端的直連模式的存儲中，比如SATA硬盤陣列。要記住的是，一個只存儲歸檔郵箱的郵箱數據 庫對I/O負載的需求根本不像存儲有用戶主郵箱的郵箱數據庫要求的那樣高。針對歸檔郵箱數據庫使用低端存儲的另一個好處就是這樣做可以針對歸檔郵箱設置比 較寬松的限額。
對日志郵箱的誤解
需要考慮的另外一個問題就是日志郵箱。如果你在Exchange的hub transport情況下使用日志方式來歸檔郵件的話，那么所有的歸檔郵件都會被放入日志郵箱了。
我個人從沒看到過任何微軟發布的如何放置日志郵箱的最佳實踐，但是我傾向于將日志郵箱就放到它自己的郵箱數據庫中。這是因為日志過程是一個對I/O 要求比較高的處理過程，將日志郵箱放到它自身的郵箱數據庫中可以確保能夠獲得足夠的I/O性能，并且不會影響其他的郵箱數據庫。如果所有郵件都被推入了日 志，那么在訪問日志郵箱的時候，由于日志郵箱與用戶主郵箱都處于同一個郵箱數據庫中，所以這時的I/O負載需求就會加倍，因為Exchange 2010已經不支持單一實例存儲了。也就是說，使用了日志郵箱之后，所有的郵件都會在同一個郵箱數據庫中被復制一份存放。
如果你真的在與用戶主郵箱相同的郵箱數據庫中創建了日志郵箱，那么可能會對數據的復制過程產生一定的影響。
如果將日志郵箱存儲在與用戶主郵箱不同的單獨的郵箱數據庫中，這樣做的一個優勢就是可以讓管理存儲限額和保留周期變得更容易。你可以針對用戶主郵箱創建一套策略，而針對日志郵箱則可以根據需求再創建另一套策略。
Discovery郵箱
在規劃Exchange Server 2010存儲時，最后一種需要考慮的郵箱類型就是discovery郵箱了。Discovery郵箱的唯一用途是用于做多郵箱聯動搜索(比如電子發現過程)。搜索的結果就會被存儲到discovery郵箱中。
默認情況下，discovery郵箱會被分配給50GB的限額。這看起來是挺大，但是在一個較大的企業中，如果真的做起電子發現過程，那么這個數值就顯得非常小了。
當要考慮將discovery郵箱的存儲規劃時，一般情況下容量比性能更加重要。雖然電子發現過程對I/O負載要求是很高的，但是這些I/O會被分攤在存儲用戶郵箱的郵箱數據庫以及存儲discovery郵箱的的數據庫上。
如果你將來不需要實施電子發現，那么你根本就可以不創建discovery郵箱，直到你什么時候需要時，現用現創建即可。如果你必須前期創建discovery郵箱，那么你最好將它放到一個底層使用大容量低端存儲系統的郵箱數據庫中。
結論
顯然，在規劃Exchange Server存儲架構時，有非常多的東西需要考慮，雖然Exchange 2010并不像之前版本那樣對I/O性能有較高要求，但是I/O性能依然是設計過程中所要首先考慮的。還有一些其他要考慮的，比如容量以及容錯等，這里就不展開講了。
相關鏈接1：Exchange Server的歸檔和電子發現功能會取代第三方產品么?
在Exchange Server 2010版本發布之前，第三方針對Exchange Server有一個完整的歸檔和電子發現產業鏈。而如今Exchange Server 2010自身就提供了原生的用戶歸檔以及內建的電子發現支持。那就非常自然的讓人有所聯想，Exchange Server 2010內建的電子發現功能是否會取代原來的第三方產品呢?
Exchange 2010內置的電子發現和歸檔功能或許對一些小企業來講已經足夠了，但是對于大企業來講卻顯得并不是非常專業，因為Exchange 2010內置的歸檔和電子發現在功能等方面確實相比第三方專業產品來講還是有一些限制和不足的。
例如，Exchange 2010的歸檔郵箱并不是一種純歸檔解決方案。歸檔郵箱允許用戶將重要的郵件轉到二級郵箱，二級郵箱并不受嚴格的保留期限約束以及存儲空間限額。但是如果 你依然想做純歸檔方案的話，你就必須使用Exchange的日志特性了。日志方式是可以工作，但是第三方的歸檔產品可以提供對郵件歸檔的更好的控制能力、 保留期限以及其他處理過程。
對于Exchange2010的多郵箱聯動電子發現搜索特性來講，情況也是一樣的。多郵箱聯動搜索有很多限制，比如，僅支持Exchange 2010的郵箱，一旦遇到之前版本的Exchange或者PST文件，那么你就必須要使用第三方產品了。
Exchange 2010內置的多郵箱歸檔功能也缺乏一些多樣的報表選項，以及缺乏導出功能等，而這些功能一般在第三方專業產品中都是標配。
相關鏈接2：保護Exchange的數據
Exchange Server的數據通常比較難于對其實施保護。如果你打算做一個每晚的數據備份，那么一個很小的錯誤就可能導致一整天的郵件丟失。對于大多數公司來講，這種損失是不可接受的。
Exchange的管理員會有多種不同的方法和步驟來防止潛在的數據丟失。在Exchange 2007中，例如，采用連續的數據復制從而將郵箱數據復制到另一臺郵箱服務器就被認為是一種很好的而且經常使用的方式。連續的數據復制解決方案可以提供數據的容錯性同時也可以作為一種除了備份之外的數據保護方式。當然，使用諸如System Center Data Protection Manager這種數據連續復制保護方案也是一種很好的選擇。
一些分析者認為微軟正在致力于徹底讓Exchange Server的數據不再需要備份，比如使用Database Availability Groups特性，從而讓Exchange足夠強大而根本不用備份。
Database Availability Groups是Exchange Server 2010中的一個特性，它可以讓你創建最高16份針對郵箱數據庫的備份副本。這些副本被存放在其他的郵箱服務器上，不僅如此，甚至還可以將數據副本創建在其他數據中心里。雖然現在針對Database Availability Groups是否真的可以保護郵箱數據方面有很大的爭論，不管怎么樣，你還是不要放棄傳統的備份。
針對每個數據庫都有多份備份副本會對于保護Exchange Server的數據變得更加容易，但是如果一旦一個郵箱數據庫損壞或者中了病毒等，也就是發生邏輯錯誤，那么同樣的邏輯損毀或者病毒均被被體現在其他副本中，因為他們之間是完全同步的。
但是微軟也確實提供了一種延后的數據回放特性，其中，一些數據尚未完全同步的服務器被用來放置這些有害的數據操作被同步的提交到副本數據中。如果一 旦發現數據除了問題，那么由于數據的復制是延后的，所以此時你就有足夠時間來阻止這些有害數據被同步到副本數據中。經過這種處理方式，在發生問題之后你就 可以使用未經損毀的數據來回到之前完好的狀態了。
雖然這個方法在理論上看起來很牛，但是如果真想將其做成產品，還需要很多工作要做。當前，這個方法所涉及的一些步驟，都需要接受特殊的培訓課程，其 中會告訴你哪筆交易日志含有受損的第一個數據位，然后你需要人工操作一些很復雜的步驟來裁剪日志文件。所以，雖然Exchange 2010的存儲架構可以通過使用Database Availability Groups來讓數據保護變得更容易，但是并不要將其視作保護Exchange Server數據的唯一辦法。
原文地址：http://www.searchstorage.com.cn/showcontent_53841.htm
