前面的內容裏面,已經爲你們比較深刻的介紹了Exchange2013的客戶端訪問角色涉及到的諸多細節。在接下來的章節裏就跟你們聊一聊Exchange 2013裏的傳輸服務,這一節總共的內容都比較多,並且更偏向理論,因此咱先來一篇簡述,而後再分拆開一個一個講。前端
在以前的版本中,由Exchange2007引入了Hub Transport(集線器傳輸)角色做爲全部郵件信息的傳遞中樞,任何發送或者接收到的郵件都必然會通過至少一個Ex2010與Ex2007的集線器傳輸角色;那麼在Exchange2013當中,任何發送或接收的郵件都必然會通過MBX上的傳輸組件。這種必然性就表明Exchange能夠實現如下這些功能:數據庫
一、 全部的郵件都會傳輸規則過濾並處理,傳輸規則能夠同時對入站和出站兩個方向的郵件設置過濾規則。緩存
二、 全部郵件傳輸路徑上通過的MBX服務器都會存有日誌,也就是tracking logs,這個功能在排查郵件流問題的時候每每會首先被考慮到。服務器
三、 MBX會保存一份當前正在傳輸的郵件的臨時性副本,直到下游服務器返回了郵件送達的確認消息。若是在正常郵件傳輸路徑當中出現問題致使這份郵件不能立刻被送達,那麼MBX會嘗試用不一樣的郵件路由來發送臨時副本。架構
四、 郵件只會到達擁有該郵箱活動數據庫副本的MBX服務器ide
五、 組織內部,組織之間,組織外部的郵件流均可以被監控和管理。spa
做爲一個郵件管理員,對於Exchange傳輸系統所要重點注意:翻譯
一、 配置默認的鏈接器來符合組織內的需求。代理
二、 郵件傳輸路徑的高可用日誌
三、 知足合規性的必要措施
四、 爲環境內部其餘的SMTP客戶端配置自定義的接收鏈接器,好比郵件應用,掃描儀複印機,或者是其餘的郵件系統
五、 突發的異常狀況須要快速定位而且效率處理
六、 收集監控和報告的數據,以隨時可以提供報表。
簡述傳輸管道
微軟在不少文檔中,不管是針對Exchange開發者,或是管理員,都常常用到一個詞,叫Transport Pipeline。這個概念在Exchange實際架構當中被分割成了兩個部分,看起來就像下圖所歸納的樣子。圖中標示出CAS和MBX在邏輯上分別負責不一樣的傳輸模塊。
從這個抽象的圖裏描述一下入站的郵件流:
一、 入站郵件流到達接收鏈接器,
二、 FET(MSExchangeFrontEndTransport.exe 前端傳輸)服務將郵件代理給MBX上的Transport服務
三、 Transport(MSExchangeTransport.exe)服務接收代理鏈接。微軟說Ex2013裏的Transport服務幾乎等同於早期Exchange版本里的Hub Transport服務,意味着該服務會負責進行郵件分揀,郵件路由,應用傳輸規則,以及檢查和修改郵件頭與內容(渲染郵件)。
四、 Transport服務向MBX上的郵箱傳輸傳遞服務(MSExchangeDelivery.exe)發起SMTP鏈接(注意這裏不是HTTP也不是RPC而是HTTP鏈接),該服務接收Transport的鏈接,接受入站郵件而後使用RPC鏈接將郵件放到Information Store裏。因此整個過程中郵箱傳輸傳遞服務充當了RPC存儲服務和SMTP流量之間的一塊適配器;Transport和FET服務沒法直接對store進行鏈接,郵箱傳輸傳遞和郵箱傳輸提交服務利用RPC與store進行通訊是Exchange2013裏惟一用到RPC服務的地方。其餘的內部服務器之間的Transport通訊都是使用SMTP。
出站郵件流量的走向基本與入站流量走向相反,當用戶發送一封新郵件的時候,客戶端首先將郵件存儲在特定的文件夾當中:Microsoft Outlook 緩存模式客戶端會存在已發送郵件裏,Outlook在線模式(或者Outlook 2011 for MAC OS X)的發件箱裏,或者是Outlook Web App的草稿裏。而後MBX上的郵件傳輸提交服務(MSExchangeSubmission.exe)會從這些文件夾裏經過RPC拿走這些郵件,而後發送給傳輸服務,再丟給發送鏈接器。
這個過程中也有例外,比方是某種郵件應用或者是郵件管理員本身把郵件直接放到MBX裏的分揀或重播目錄裏頭,這種狀況我們在後面的文章裏會詳細說明。
關於郵件流我之前也翻譯過technet blog上的一篇文章:
http://sodaxu.blog.51cto.com/8850288/1651613
簡述郵件路由
郵件路由在Ex2013的實現與之前的版本有諸多不一樣。在Exchange2010當中,AD站點是郵件路由的主要邊界,和Exchange5.5的郵件路由工做方式相似。而在Exchange2000和Exchange2003當中,郵件路由則是依靠路由組和路由組鏈接器的概念來工做。Exchange 2013繼續使用AD站點做爲郵件路由範圍的一部分,另外一部分範圍是DAG組。獨立的MBX服務器(即沒有加入到DAG組裏的MBX)以AD站點做爲路由邊界,而加入到了DAG組的MBX服務器以DAG關係做爲路由邊界。這個改動也在必定意義上直接影響了Exchange2013其餘組件的變更。固然DAG成員之間依然要求有健壯的鏈接來支撐,特別是跨站點的DAG。
在獨立的MBX上,入站的郵件固然直接被丟到擁有該郵箱的數據庫裏;而在DAG裏,入站郵件是被丟到擁有該郵箱的數據庫的活動副本里(叫激活副本更爲合適)。因此路由組件必須提供一個方法使得發送服務器能夠辨識出哪臺MBX得郵箱傳輸傳遞服務可以接受該郵件。這個需求被一個叫Active Manager的組件所知足,它會提供一張表,表裏列出了哪些數據庫的活動副本對應的MBX服務器。
另一點,DAG自己就能夠提供傳輸服務的彈性擴展,比方你部署了一個跨站點的DAG,那麼其中任何的DAG成員均可以handle郵件的傳輸,而不須要額外的配置。
郵件的路由主要由Trransport服務裏的分揀器組件負責,由它來決定郵件的下一跳地址(下一個目的地)而後將這個郵件投遞到對應目的地的隊列裏。隊列既包括本地的郵件流即SMTP發送給MBX郵箱傳遞傳輸服務,也有多是外部的郵件流,發送給其餘的郵件服務器。
實際上Exchannge2013包含三種目的地類型:郵箱數據庫,郵件鏈接器,通信組擴展服務器(distribution group expansion)。每封郵件的投遞都會被指向這三種目的地其中一種。
這三種目的地在Exchange中被細化爲投遞組(delivery group)。關於投遞組的更詳細的其餘說明,我會在後續的文章中再來跟你們聊聊。
那麼到目前爲止,對Exchange 2013上的傳輸服務組件,我們應該有一個大體的瞭解,後續的文章當中再來具體針對組件進行詳細描述;你們敬請期待。