Exchange Server 2016 架構前瞻

在Ignite 2015上，Exchange產品組介紹了Exchange2016的一些新功能，這裏主要總結一下架構更改方面的東西，並分享給你們，其中的一些內容可能在之後不久發生更改，一切以最終發行的正式版文檔爲準：

附上：Exchange@Ignite2015視頻集錦

在Exchange 2016當中，引入了「積木式架構」這樣一種概念，移除了CAS角色，在MBX角色上添加了客戶端訪問這樣一個服務（Client Access Service）。目的嘛，就是微軟常說的簡化代碼，加強性能之類的……

Ex2016當中的MailBox角色：

一、負責傳輸邏輯

二、負責全部的處理、渲染（對郵件進行處理）、存儲郵件的組件和協議

客戶端沒法直接鏈接到MBX的後端終結點；而是首先鏈接到客戶端訪問服務，而後經由客戶端訪問服務來進行路由（本地或遠程代理）到擁有該用戶郵箱數據庫的活動副本的MBX服務器

Ex2016中的DAG加強：

一、建立DAG的時候再也不須要DatabaseAvailabilityGroupIpAddresses ，故障轉移羣集在創建的時候，不會同時在AD裏面創建計算機帳戶，也就是管理訪問點。（Ex2013 SP1就支持這個功能：http://jaapwesselius.com/2014/11/09/cluster-administrative-access-point-and-database-availability-group/）

二、默認打開延遲滯後重播功能（-ReplayLagManageEnabled $True :https://technet.microsoft.com/zh-cn/library/dd979786(v=exchg.150).aspx）

三、基於磁盤的延遲，智能減小已經延遲滯後的數據庫的複製，以保證目前的活動用戶不受影響

四、數據庫故障轉移時間比Exchange 2013減小了33%

移除了全部的CAS組件並不會影響服務器間的通訊，服務器間通訊仍然保持在協議的層面。（跟2013的服務器間通訊其實差很少：http://blogs.technet.com/b/exchange/archive/2013/01/23/exchange-2013-server-role-architecture.aspx）

負載均衡配置不會被這種架構更改所影響。

例子：在協議的層面來看一次客戶端的郵箱鏈接請求：

一、客戶端解析了DNS命名空間到負載均衡的虛擬ip。

二、負載均衡將此鏈接會話分配給負載均衡池裏的MBX服務器

三、MBX服務器認證請求，爾後經由活動目錄進行服務發現，查詢該請求，收到如下信息：

    a、郵箱版本（假設爲一個Ex2016郵箱）

    b、郵箱位置信息（所屬的數據庫信息）

四、MBX服務器決定是代理該請求或是重定向該請求到同一個森林中的其餘郵箱服務器

五、MBX服務器查詢活動數據庫實例管理器，得知哪一個MBX服務器擁有該郵箱的活動數據庫副本

六、MBX代理該請求到擁有該郵箱活動數據庫副本的MBX服務器

第六步所用的協議取決於客戶端用那種協議去鏈接客戶端訪問服務（Client Access Serices）,若是客戶端使用HTTP請求，那麼服務器間也使用HTTP（使用自簽名證書的SSL加密）。若是客戶端使用IMAP或者POP，那麼在服務器間使用的也是IMAP或者POP。

第六步中，若是是一個電話請求，則不會被MBX服務器進行代理，而是直接重定向到活動數據庫副本所在MBX服務器。由於電話設備支持重定向，而且須要與MBX服務器上的UM服務創建直接的SIP和RTP鏈接。

至於爲何移除CAS角色，產品組的解釋是：

一、咱們但願你全部的Exchange服務器都是相同的配置，相同的硬件，以便於你採購、維護、管理

二、咱們原本就推薦角色協同並置，以充分利用Cpu和磁盤。試想你在Ex2010環境裏專門爲了Hub角色單獨放一臺物理服務器該多浪費啊

三、因此咱們的目的是爲了減小你的服務器數量……減小硬件開支……

其餘關鍵性的增強：

增強搜索：

在Ex2016當中，在活動副本和被動副本之間的複製帶寬下降了40%。這是因爲本地的搜索實例將只從本地的數據庫讀取數據進行索引，意味着若是被動副本要更新它的索引，只須要等待複製，而後從其自身的數據庫進行索引，而非每一次都去找活動副本。

另外一方面，則是改進在線模式的客戶端的搜索體驗（好比OWA客戶端），下降其得到搜索結果的時間。當用戶輸入完搜索關鍵詞以前，就開始執行多此異步磁盤讀取，以緩存與關鍵詞相關的信息；經過這樣來下降查詢延遲

文檔協同：

在以前的Ex2013版本中，OWA已經能夠在線預覽office和PDF文件。Sharepoint+Office Web Apps服務器也能夠實現這些功能。在office 365當中，已經徹底使用Office Web Apps來提供統一文檔預覽和協同編輯功能。

這個特性移植到了Ex2016上，集成office web apps服務器的Exchange2016在OWA裏會擁有富文本編輯以及預覽功能。

下一代Office Web App服務器將不能與Exchange服務器進行並置，因此得部署獨立的Office Web App服務器場來實現這功能，這個服務器場須要獨立的命名空間，以及可以保持會話關聯的負載均衡器。

Exchange支持非綁定的命名空間，而Office Web App須要綁定的命名空間，（可是不會因爲訪問位置發生改變而改變）。因此整個架構看起來就像下圖同樣

可擴展性：

Ex2016引入了O365使用的REST（Representational State Transfer） API，擁有更好的開放性與靈活性。這些api容許開發者從任何平臺鏈接，好比web、pc、移動SDK（Android、IOS、.NET）或者nodejs，ruby，python，Cordova、CORS……

被拋棄的EWS在哪哭泣……

Outlook鏈接：

在Exchange 2013 SP1當中，outlook鏈接已經默認使用MAPI over HTTP，在Ex2016當中，Mapi Over HTTP已是默認設置了；而且在此鏈接模型之上，加入了每用戶控制，以及控制某種協議是否對外部用戶可用。

注意：Ex2016再也不支持經過MAPI/CDO庫直接鏈接，第三方產品須要遷移到EWS或者是REST APIs來訪問Exchange數據。

與Exchange 2013共存：

在Ex2013當中，CAS角色只代理鏈接，不負責處理任何內容。因此當你在環境中引入了一臺Ex2016的時候，是不須要去更改命名空間的，由於Ex2013的CAS架構徹底可以將用戶請求代理給擁有該郵箱活動數據庫副本的Ex2016服務器。也就是說，你能夠在同一個負載均衡池裏同時存在Ex2013和Ex2016，而後能夠一臺一臺的升級13到16，加一臺16，減一臺13.

架構須要：

Exchange 2016只支持Windows server 2012 R2和 Windows Server 10操做系統

AD層面：     
    Windows 2008 R2 或者更新的AD服務器

Windows 2008 R2或者更新的林功能級別以及域功能級別

共存：

Exchange 2013 CU11

Exchange 2010 SP3 RU11

（這倆都沒出來呢……）

最佳實踐架構：

與Ex2013的PA差很少：數據中心配對之上創建DAG，DAG中的MBX服務器交錯分佈全部的活動數據庫副本，數據庫副本基於JBOD存儲，每塊盤4個副本，其中一個副本爲延遲滯後副本。客戶端經過統一的命名空間進行訪問，負載均衡到整個站點。

一、Ex2016 的非綁定命名空間模型使得跨越整個數據中心的7層負載均衡在配置上不須要保持會話關聯性

二、你須要在每一個數據中心中部署一個Office Web Apps場，每一個場有其獨立的命名空間，負載均衡器須要打開回話關聯性

三、DAG的部署再也不須要管理訪問點。

四、服務器：雙CPU插槽，有20-24個處理器和最高196G內存，以及帶電池的寫入緩存控制器

五、全部數據存儲卷都被格式化爲ReFS（https://technet.microsoft.com/zh-cn/library/hh831724.aspx）

總結：

Exchange 2016仍是在減小服務器角色架構複雜度和引入從O365移植的成熟的設計思想兩方面下功夫。若是看過視頻就知道。。幾乎每一項新功能前面都會加上，we learn from O365 blablabla的……