轉：我眼裏的Exchange 2010 之：1—DAG

轉自：http://bisheng.blog.51cto.com/409831/270739

 

 

相比以前的Blog更新速度，最近應該算好久沒有寫新的東西了。一方面是工做的事情太多，另外一方面也主要是在學習和研究。如今工做上的事情，相對輕了一些，並且，也該總結一點東西了。
    因此如今，我儘量的將前一段時間的一點心得，總結於此。算是對本身的總結，也爲路過的朋友提供一點參考。

    那麼第一個，就來談談DAG這個東西。

    DAG(Database Availability Groups)：數據庫可用性組技術使Exchange Server 2010在高可用性方面獲得進一步簡化與完善，藉助於多臺服務器間的連續複製，可爲用戶提供高可用性的Exchange郵箱。這看似只是一項簡單的改進，但實際上，與前代版本相比，這是一個很是大的進步，它使用戶無需藉助複雜的技術與高昂的設備，就能夠得到高可用性。(此段摘自於exchangecn.com)
    相信對Exchange2010有所瞭解的人確定會知道這項重大的改變。相比一些其餘的所謂的新功能、新體驗來講，這項位於系統核心的數據結構和服務器結構上的變化，我我的以爲，可能意義更爲重大一些。到底有何意義，又爲什麼重大，咱們暫且不論。先來一些理性的分析看看。

 

    不管是中文名字「數據庫可用性組」仍是英文名字「Database Availability Groups」，咱們均可以看到，它們是由三個部分組成：D-數據庫、A-高可用、G-組。那麼咱們就從這三個方面來個全面的認識。

 

•     D-數據庫
      這個數據庫從本質上，它是一個位於硬盤上的文件，相信這點絕對沒有歧義。那麼這麼一個本質的東西能有什麼值得關注的呢？有，那就是容錯方式。
      相信你們都知道在Exchange2007的時候，有兩種用於高可用性的技術，LCR和CCR。LCR是經過在本地建立一個數據庫的副本，而CCR是在一個Failover Cluster的備份節點上建立一個數據庫副本。這兩種方式能夠任選一種，或者組合使用。
      好處沒必要多說，以前實際接觸過的朋友，天然清楚。不大瞭解的朋友，也能經過搜索來獲取到很是豐富的信息。這裏只談談不足之處，也就是促使微軟在Exchange2010裏作出改進的地方。
      下面列舉一二：
          LCR、CCR只能用於MB角色
          LCR沒法支持主機級容災，換句話說，若是是主機掉電或者物理網卡失敗，不管本地有多少個數據庫副本，均沒法實現高可用。
          CCR必須構建於Windows Failover Cluster之上，隨之帶來諸如沒法實現異地容災；或者某一節點上的某一DB失敗，致使全部DB所有發生切換操做；以及永遠都有至少一個未被實際利用的備份節點服務器資源；等等。
      爲了解決這些問題，在Exchange2010中，結合了之前的CCR和LCR想法。在DAG中，數據庫的容災，徹底基於DB級或者說是服務級，與windows是否實現cluster無關。換句話說，有點相似於SQL的數據庫鏡像。它是經過數據庫日誌的方式，同時在幾個數據庫鏡像上寫入相同的數據，且有一套機制來保證全部鏡像副本上的操做一致性。數據庫鏡像最多能夠建立16個，在這些鏡像中，有一個是出於活動的對外提供服務，其他的所有用來備用。而這每個鏡像副本，分別放置在可用性組中的不一樣服務器上。
      這樣作的一個最大的好處就是，最爲關鍵的郵箱數據庫服務，不會受到任何其餘層面的影響，而只會關注某一個數據庫的狀態是否可用。它不關心數據庫文件是放在哪裏，放在什麼樣的存儲設備上，也不關心Windows是否實現了高可用，更不關心網絡是否通暢。只要它發現某個應該提供服務的數據庫副本沒法提供服務了，就馬上會啓動另一個副本進行工做。而且只是針對這一個郵件數據庫而已，若是同一個服務器上的其餘副本的數據庫服務正常的話，它們將不會被切換走。
      另外，脫離Cluster，就更容易實現異地災備的解決方案了。理論上，DAG的數據庫鏡像，並不關心這些服務器是否在同一個地點，它們之間只要保證必要的鏈路帶寬，保證數據庫日誌的有效複製，就能夠實現高可用了。固然，具體的帶寬，目前我也沒有去測過。留個做業給你們把。
      數據庫的結構如此，其實只是一個基礎。至於怎麼被切換，纔是關鍵，下面就看看高可用性是如何實現的了。
•     A-高可用
      DAG中所實現的高可用，簡單來講，是兩個層面的工做。一個是數據庫服務的監控，第二個，其實仍是使用了Windows底層的MSCS（MS Cluster Service），只是能夠不須要將Windows搭建成Cluster環境而已。
      MSCS就不單說了，就是個底層的Windows服務，隨便一搜，就能搜到好多。這裏咱們主要談談服務的監控和切換的實現。
      在此以前，我以爲有必要提一下Exchange2010中服務器角色架構的改變。其中最大的改變就是CAS，由於之前MAPI方式的客戶端是直接鏈接到MB角色上的。而在Exchange2010中，CAS接管了全部方式的客戶端鏈接，包括MAPI方式的鏈接。
      在活動郵箱數據庫副本上會運行 Information Store, CI, Assistants等服務，而每一個DAG中的服務器上都會運行一個叫Active Manager的組件（貌似它就是基於MSCS之上的一個東西）。在CAS角色上，有一個叫RPC Client Access的東西。
      在它們之間又造成了一個C/S結構，CAS是C，MB是S。經過CAS上的RPC Client Access服務，若是它發現MB上的這個服務有任何的閃失，它將經過Active Manager的配合，找到另一個副本進行鏈接。而且Active Manager會將那個備份副本，啓用成活動副本。
      這樣，一個服務的快速切換，就完成了，不過其實大概須要30秒左右。若是湊巧此刻沒有用戶在收發郵件的話，可能就是一次神不知鬼不覺的切換了。若是碰上老大正在發郵件，被卡了的話，30秒好像也不是很嚴重，不過提早編好3套以上的解說詞比較靠得住。。嚯嚯。。
      固然，有人確定會問，若是CAS出現故障，不就歇菜啦？確實如此！！我很負責的告訴你們，若是CAS不可用了，就等着電話被打爆吧。。。呵呵。。不過還好的一點是，Exchange2010除MB之外的全部角色均支持NLB，因此在這個問題上，比Exchange2007要好解決多了。
•     G-組
      最後，咱們再來看看這個用來作數據庫載體的「組」，是個什麼東西。
      其實很簡單，它就是一堆服務器的集合。這個集合所起的做用是明確資源的邊界，明確管理的邊界，僅此而已。
      若是還不太明白，咱們就來一個著名的比喻吧。。組就是一張茶几，上面放滿了「杯具」。。杯具就比如咱們的服務器節點，數據庫副本就是水，你能夠把水倒入這張茶几上的任意一個或者多個杯具裏（提示：DAG中最多隻能倒16個），但你沒有辦法把水倒在這張茶几之外的杯具裏面。換句話說，若是你但願用另一個杯具來盛水，那你必須先把它放到這個茶几上來。
      大體能夠這麼認爲，但其實DAG中，服務器節點和組的狀況要比這個比喻複雜。準確來講，是一個茶几上放了好幾套杯具，注意是套，不是個，由於一套可能有好幾個杯具組成，而每一套裏的杯具能夠分別放入不一樣的飲料。因此一個服務器節點，其實至關於一套杯具。由於在一個服務器中，能夠放入多個不一樣的數據庫副本，而且容許它們有些是活動的，有些是其餘節點上的備份副本。

 

    談到這裏，算是把DAG大體瞭解了一下。歸納來講，它就是經過相似SQL的數據庫鏡像技術，實現了郵件數據庫的高可用性。從而避免了對Windows Cluster的依賴，也簡化了高可用的實現方式。這就是DAG的意義所在。

    至於意義是否重大，還要看不一樣的企業，不一樣的需求，不見得DAG就能適用於全部的場景。

 

 

    其實明眼人可能已經看出其中的貓膩了，對，就是存儲！！若是沒明白過來的人，能夠算筆賬。若是在Exchange2007下使用CCR的方式實現高可用性的話，咱們算一下若是數據庫是1個G的大小，最終咱們須要多少個G的存儲空間。其實很簡單，就是1個G。由於即便是多節點的Cluster，因爲咱們可使用共享存儲機制，因此，實際支出的存儲空間，只有共享存儲中的那1個G而已。。

    可是若是是DAG呢？乖乖隆嘀隆啊！！有幾個副本，所須要的空間就翻多少倍！由於DAG是不關心你底層數據存儲方式的，不論是本地硬盤、直連存儲、仍是網絡存儲，也無論你的存儲級別是否已經提供了冗餘機制。

    不過以微軟本身的說法，這種方式也有它的好處，由於DAG的機制，加上Exchange2010中郵件數據結構的變化，使得I/O大量減小，且提升了數據存儲的效率。因此使得用戶可使用更爲廉價的直連存儲，甚至是SATA的本地硬盤來做爲郵件系統的存儲解決方案。暫且不說是否壞了好多存儲硬件廠商的好事，對於中小型企業來說，這確實是一件很是好的事情。

    可是，對於一些大型或者超大型企業來講，他們可能已經在早期作出了規劃，並投入了SAN或者別的存儲解決方案。並且對於他們來講，垂直型的IT架構分解，對於管理來講是很是有必要的。那麼對於這些企業來講，DAG將絕對是個噩夢。。如今惟一能作的，就是經過配置不一樣的RAID，來提升存儲的使用率。。

    如何取捨？相信每一個老百姓內心都有本身的一杆稱。。。

 

    最後貼個示意圖，相信你們都能看明白。。