相比之前的Blog更新速度，最近應該算很久沒有寫新的東西了。一方面是工作的事情太多，另一方面也主要是在學習和研究。現在工作上的事情，相對輕了一些，而且，也該總結一點東西了。
所以現在，我儘可能的將前一段時間的一點心得，總結於此。算是對自己的總結，也爲路過的朋友提供一點參考。
所以現在，我儘可能的將前一段時間的一點心得，總結於此。算是對自己的總結，也爲路過的朋友提供一點參考。
那麼第一個，就來談談DAG這個東西。
DAG(Database Availability Groups)：數據庫可用性組技術使Exchange Server 2010在高可用性方面得到進一步簡化與完善，藉助於多臺服務器間的連續複製，可爲用戶提供高可用性的Exchange郵箱。這看似只是一項簡單的改進，但實際上，與前代版本相比，這是一個非常大的進步，它使用戶無需藉助複雜的技術與高昂的設備，就可以獲得高可用性。(此段摘自於exchangecn.com)
相信對Exchange2010有所瞭解的人肯定會知道這項重大的改變。相比一些其他的所謂的新功能、新體驗來說，這項位於系統核心的數據結構和服務器結構上的變化，我個人覺得，可能意義更爲重大一些。到底有何意義，又爲何重大，我們暫且不論。先來一些理性的分析看看。
相信對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，來提高存儲的使用率。。
如何取捨？相信每個老百姓心裏都有自己的一杆稱。。。
最後貼個示意圖，相信大家都能看明白。。
