Exchange 2010 之：1—DAG

精选转载

Forestgao 2010-07-09 12:01:34 博主文章分类：Exchange

文章标签 职场 exchange 休闲 Exchange 2010 文章分类 服务器

那么第一个，就来谈谈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，来提高存储的使用率。。

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

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