转：我眼里的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，来提升存储的使用率。。

    如何取舍？相信每一个老百姓内心都有本身的一杆称。。。

 

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