微軟公司針對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://storage.chinabyte.com/144/12178144.shtml