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,来提高存储的使用率。。

    如何取舍?相信每个老百姓心里都有自己的一杆称。。。
 

    最后贴个示意图,相信大家都能看明白。。