关于Exchange邮箱服务器角色故障排查及解决思路分享

wfds

  在最近一次关于Exchange服务器故障中，出现了员工无法进入邮箱的问题，最直接方法来登录OWA页面，看看正常不正常，反映出来的报错信息如下：
     当接到这个报障后，第一时间，当时有人问到是不是公司的CAS服务器挂了？当然还是如果对邮件服务器足够了解的话， 这个报错一定不是邮箱服务器CAS出现故障，因为如果CAS出现问题，您也到不了这个页面的，所以根据产品提供服务来判断，能打开OWA页面，说明CAS服务器是正常的，出现这个报错是在用户输入帐号和密码后出现的，那么其实不用去思考，故障点一定出现在邮箱服务器角色上，好带着这个排错思路我们来看看邮箱服务器角色吧。
     当打开EMC控制台时，所以数据库全为宕的状态，所以这也就是为什么用户在网页方式输入邮箱帐号及密码后，提示邮箱不可用的原因了，但是数据库全为宕状态的根本原因又是什么呢？根据经验有极大的可能是邮箱数据库所在的存储盘满了，OK，那么来看看，发现数据库所在磁盘可用空间为几百KB。
     现在要做的事情，就是尽快清理出空间来先恢复主体业务，可用方法有如下：
1.数据库采用了DAG，那么可以先把副本库删除，保证每个主数据库所在的磁盘有足够的空间，但是隐性的风险在于如果主数据库宕掉，又恢复不起来，那故障影响范围就更大了。
2.通过清除Log的方法释放空间，此方法还是比较稳妥的，至少能先把主、副数据库挂起来，而且不会影响业务使用。
3.开启日志循环功能，但需要卸载故障数据库，且需要时间等待。
     所以最后选择了第二种方法，清除Log，那么OK，这里我采用如下命令清理数据库log文件，GUI下也可以，但是数据量过大，很有可能会导致系统假死，而且清理起来要比较费事。
forfiles /s /m *.log /d -4 /c "cmd /c del @file /f"
上边这条命令的意思是删除4天前的日志，清理后发现空间释放出来几十个G，再来看数据库状态，已经正常挂载和同步，那么OK,此时至少在邮件量不大的情况下能恢复业务。
   好，接下来就要考虑的是如何增加存储的问题了，由于环境中是在esxi中搭建的虚拟化，方法有如下几种：   
1.直接对邮箱服务器角色存储盘扩容，但由于是生产，所以还是有一定风险，如果扩盘失败，那么会带来邮箱服务器整体真正宕机。
2.新增单独的存储盘，并且由于之前是日志与edb数据库文件位于同一个盘下，所以我们在增加新的存储盘时，要增加2块，一块用于存放edb文件，另一块用于存放log文件，也在数据库的恢复性上做了优化这样，增加新存储盘后，再新建新的数据库，将原存储盘中较大的数据库邮箱进行迁移，此项操作虽比较耗时，但是还是相对来说比较稳妥的方法。
3.增加新的邮箱服务器角色，将出问题的原存储盘中的邮箱数据库分别增加副本至新的邮箱服务器中，但是此方法虽也是比较稳妥的方法，但是从服务器增加搭建再到同步副本，仍是很慢的方法。
     所以最终在解决根本性问题时，选择了方法二，这样既能调优Exchange数据库存放结构，又保证不会出现更大的问题，唯一可能要注意的就是要时时观察原数据库存储盘，如是空间接近不足时，要用上述命令删除日志，来保证迁移的顺利，当然也通过这种方法起到了释放空白空间的作用，迁移结束后，先将原数据库卸载，观察如果邮箱无问题，就可以直接删除旧的数据库了。
    当然，存储盘是有限的，而日志文件的增长又是比较迅速的，所以尽可能在企业环境中增加备份软件对日志进行备份来减少日志增加量及完整性，如果实在没有条件搭建备份平台，那么也可以数据库新建后，开启日志循环功能，来控制日志容量的增长。
    当然，最后还想说的是运维工作本身是一件非常谨慎的事情，所以遇到事情还是应该冷静下来，先确认问题点，快速恢复业务，同时找到最稳妥的解决办法来保证从根本防止此类故障问题，这次故障其实还有一个原因就是上一代管理员在对邮件平台规划中并没有考虑到更长远的问题，数据库存储空间不做规划，导致数据库日志在增长后，无法及时清理，所以做任何平台，都应该本着规划为先，测试及评估为中，实施为后的思想，多想想当前规划是否会成为自己运维的增加了更大的风险。
    这篇文章只起到一个排错思路的分享，更多的还是然望能通过这个案例，来说明存储空间及备份在企业中的根本作用和必要性。