Exchange Server数据库可用性组怎么弄，管理起来那些事儿和注意点分享

Exchange Server数据库可用性组怎么弄，管理起来那些事儿和注意点分享

数据库可用性组，说白了就是Exchange高可用性里面最核心的一个技术，它的目标很简单，就是保证邮箱数据库不能单点故障，做法就是把几个邮箱服务器（至少两台）捆在一起，形成一个组，在这个组里，每个邮箱数据库都会在其他服务器上保留一份甚至多份实时更新的副本，这样，万一有一台服务器或者上面的数据库出问题了，Exchange可以自动快速地把用户切换到另一台服务器上那个健康的数据库副本上，用户可能就感觉不到中断,或者只会遇到非常短暂的卡顿。

搭建DAG的前期准备和关键步骤

搭建DAG不是点几下鼠标就完事的，需要事先做好功课，根据微软官方文档的指导,有几个硬性条件必须满足：

1. 服务器要一致：准备加入DAG的所有Exchange邮箱服务器，最好型号、配置、特别是磁盘性能都差不多，你不能把一台老掉牙的服务器和一台顶级新服务器放一个组里，那样弱的会成为瓶颈,操作系统版本和Exchange版本必须完全一致。
2. 网络要通畅：DAG内部的服务器之间需要心跳线来互相“打招呼”，确认对方还活着，除了生产网络之外，强烈建议专门划一个独立的网络用于DAG内部通信，这个网络要和其他网络隔离开，避免干扰,每台服务器至少需要两块网卡。
3. 见证服务器是关键：如果DAG里有偶数台服务器（比如2台），就需要一个“裁判”来打破平局，防止“脑裂”现象（就是两台服务器都以为对方死了，都想去接管服务，导致混乱），这个裁判就是见证服务器，它不能是DAG的成员，可以是一台低配的Exchange服务器（只装邮箱管理角色），也可以是一台普通的Windows服务器，关键是要能通过网络被所有DAG成员访问到,并且上面有一个共享文件夹的权限。
4. IP地址要规划好：DAG本身需要一个独立的、静态的IP地址，这个IP地址是用于管理DAG的,客户端不直接连接它。

具体搭建过程，参考微软Technet的步骤,大致是这样的：

• 先配网络：在每个DAG成员服务器上，把用于DAG内部通信的网卡设置好，确保它们在一个独立的子网里能互相ping通,禁用这个网卡上的NetBIOS之类的无关服务。
• 创建DAG：在Exchange管理中心（EAC）里，找到“服务器”下的“数据库可用性组”，点击新建，给DAG起个名字，填上规划好的那个静态IP地址，最重要的一步是指定见证服务器和见证目录,系统会自动在见证服务器上创建共享。
• 添加成员：创建好空的DAG后，就可以把准备好的邮箱服务器一台台加进去了,这个过程系统会自动配置。
• 添加数据库副本：DAG建好了，服务器也加进去了，但这时候数据库还没有副本，你需要为每个需要高可用的邮箱数据库，在其他服务器上添加副本，服务器A上有数据库DB1，你就在DAG管理界面里，对DB1操作，选择“添加数据库副本”，然后勾选服务器B和服务器C（如果你有的话），添加后，Exchange会开始将DB1的完整数据复制到B和C,这个初始同步可能会耗费一些时间和网络带宽。

日常管理中的那些事儿

DAG建好不等于一劳永逸,日常管理维护很重要。

• 监控健康状况：每天上班第一件事，可能就是打开EAC，看看所有数据库副本的“内容索引状态”和“复制状态”是不是“正常”，如果有显示“失败”或“已挂起”，那就得赶紧排查了，常见的比如网络闪断、磁盘空间不足都会导致复制失败。
• 执行服务器切换：有时候你需要对某台服务器进行维护，比如打Windows补丁或者更新Exchange补丁，这时候就需要执行计划内的切换，正确做法是使用EAC中的“切换服务器”功能，这个操作会安全地将这台服务器上所有活跃的数据库（称为“主动副本”）转移到组内其他健康的服务器上，转移完成后再对服务器进行维护，维护完成后，可以再切换回来。绝对不要直接关掉一台服务器，那样会触发非计划的中断，虽然DAG会自动接管,但体验不如计划内切换平滑。
• 处理副本失败：如果看到副本状态异常，先看日志找原因，常见处理方法是尝试“更新”副本，如果不行，可能需要“重新播种”，重新播种是个大动作，相当于把整个数据库重新复制一遍，对网络压力很大，所以要想办法避免，比如保证网络质量,监控磁盘空间。
• 备份策略变化：由于DAG有多份副本，你的备份策略可以调整，传统上直接备份活跃数据库当然可以，但更现代的做法是利用DAG的特性，比如可以从一个被动的、健康的副本上进行备份，这样不影响活跃数据库的性能,微软也推荐使用支持VSS的备份软件来操作。

必须牢记的注意点和坑

根据很多运维工程师的经验分享,以下几点特别容易出问题：

1. 时间同步是底线：DAG所有成员服务器之间的时间差绝对不能超过几分钟，否则复制和故障转移会出诡异问题,务必确保所有服务器都从一个可靠的时间源同步时间。
2. DNS解析要靠谱：DAG严重依赖DNS来解析成员服务器的主机名和DAG名称，如果DNS不稳定或解析慢，会导致心跳超时，误认为伙伴服务器宕机，从而触发不必要的故障转移，确保DNS服务器高可用,并定期检查解析是否正常。
3. 网络是生命线：专门用于DAG复制的网络一定要稳定、低延迟，如果这个网络质量差，复制日志积压会非常严重，最终导致副本失效,避免在这个网段跑任何其他流量。
4. 磁盘空间预警：不仅要监控数据库所在磁盘的空间，更要密切关注日志磁盘的空间！Exchange的复制是靠传输事务日志实现的，如果日志磁盘满了，数据库就会卸载，服务立刻中断,设置充足的磁盘空间预警阈值。
5. 补丁更新顺序：给DAG成员打补丁时，一定要一台一台来，先切换走要打补丁服务器上的数据库，确认转移成功后再打补丁，重启，确认服务正常后，再处理下一台,切忌同时操作多台。
6. 别忽略见证服务器：见证服务器虽然不承载用户数据，但它挂了的话，万一遇到偶数节点同时需要故障转移，整个DAG可能会僵住,要保证见证服务器的稳定性和可访问性。

DAG是个强大的功能，但它不是“魔法”，它的稳定运行建立在扎实的前期规划、可靠的底层设施（网络、存储）和细心持续的日常维护之上，多看看官方文档和社区里的故障排查案例,能帮你少走很多弯路。