反思一次Exchange服务器运维故障

    本文是对2018年8月9日公司Exchange邮件系统邮件流故障的故障发现、故障处理和故障修复的过程记录和总结反思。帮助本身总结经验和吸收教训，同时也做为一次反面教材让其余运维或管理员吸收教训。

故障发现

    昨天下午18点50左右结束团队内培训分享会后，收到同事的反馈，说他们几我的都没法收到外部邮件（Internet上的邮件），故障现象为：Exchange服务器内网收发邮件正常，外网发送正常，但没法收到外部邮件。

由于公司的邮件系统是公司自建的Exchange Server 2010，所以须要运维本身去管理。通过多个外部邮箱的测试发现，的确没法收到外部邮件，这些外部邮箱包括网易、阿里企业邮箱和微软Outlook邮箱。

由于邮件服务是企业核心服务之一，加之已经有同事反馈遇到问题，所以此故障应该是重要紧急故障，必须尽快排除以恢复服务。

注1：若是问题比较严重或者有紧急事件处理流程规定，应该按照流程汇报上级领导和发出通告。

注2：如下是我的见解和经验总结，若有错误敬请指出。

故障处理

面临故障最重要的就是尽快经过排除法进行故障排除以实现服务的最快恢复。所以首先要作的故障排除。因为已是下班时间，事故虽然重大，但还还没有形成重大影响。

由于在Windows特别是Exchange的运维上我的经验比较欠缺，不能凭经验一会儿发现问题，所以只能先根据以往经验，结合Google等逐个排查。

通过初步测试，内部邮件收发正常，内部向外部发送邮件正常，但接收异常。因而开始如下排查。

在排查以前应该先须要搞清楚最近发生的变动，如软件配置，致使变动的操做，特别是两个及以上的管理员共同管理时。所以服务器由一人管理，且最近没有进行过任何更改，是忽然出现的问题，所以直接开始排查：

1. 检查域名解析，排查mx记录等是否存在问题。使用nslookup命令在多个外网服务器上测试MX记录、以及相关的A记录和CNAME记录。

   注1：Windows服务器可使用nslookup -q=mx xxx.com直接查询，Linux命令须要交互式查询，即先执行nslookup再set q=mx或set type=mx，再查询

   注2：在查询mx记录时，只须要查询邮件服务器fqdn域名的上级域名便可。如mail.qq.com，则只须要查询qq.com的mx记录便可。

   通过排查，排除域名解析问题。

2. 检查外部与内部的通讯问题，检查防火墙拦截状况和防火墙到服务器中间的网络链路问题。使用telnet mail.xxx.com 25命令检查25端口的打开状况，通过测试排除防火墙问题。

   注1：25端口是接收外部邮件的约定端口

   注2：若是25端口正常且目标为Exchange邮件服务器，应该提示相似“220 mail.xxx.com Microsoft ESMTP MAIL Service ready at Fri, 10 Aug 2018 10:43:58 +0800”字样。

3. 为了确认不是防火墙或网络设备bug问题，重启防火墙或网络设备。一般无软关闭和重启功能的防火墙须要断电或切换电源状态10s以上。通过检查不是网络设备问题。

以上3个步骤排除后，应该肯定问题是出在邮件服务器身上。开始邮件服务器自身的排查：

1. 由于是邮件服务器内部收发正常，所以直接登陆邮件服务器，检查邮件服务器的其余可能影响因素

2. 首先检查服务器负载，包括CPU、内存、磁盘空间、IO和网络等负载状况。一般影响Exchange的主要是CPU和内存，其次磁盘空间和IO。通过检查磁盘空间不足（已经低于5%，但尚有3GB可用空间，因为经验不足，没有判断出此问题可能形成的影响，加以内网邮件正常，所以没有优先处理，最后发现是此缘由形成）。

3. 其次应该检查服务器系统日志。关于先检查日志仍是先检查负载状况，只是习惯问题。系统日志通常会给与管理员足够的信息。虽然Windows的事件管理器并非特别好用，可是Exchange在日志方面仍是比较良心，通常大小事件均记录在内。

4. 除了检查系统日志以外，Exchange通常提供了其余诊断工具。好比“队列查看器”，由于队列查看器可用于解决邮件流问题，所以队列查看器里面也会有一些关于邮件没法传输的问题的提示。

5. 通过查看系统日志和队列查看器后，发现问题是因为资源不足引发。系统有两处明显的提示：

   1.队列查看器提示上一个错误为“452 4.3.1 Insufficient system resources”。通过Google查询，这一般意味着要么磁盘空间不足要么内存空间不足。

   2.事件查看器中来源自“MSExchangeTransport”报告称：

   （1）警告：资源压力已从 普通 增至 中。

   （2）错误：Microsoft Exchange 传输服务拒绝邮件提交，由于可用磁盘空间已降至配置的阈值之下。

故障确认和修复

    已经确认为磁盘空间问题致使的触发Exchange的“反压”保护策略。经过释放磁盘空间解决。解决后通告给上级领导和相关人员。

---

    知识点

    关于“反压”。如下摘录Microsoft文档库--了解反压。

    反压是存在于 Microsoft Exchange Server 2010 集线器传输服务器和边缘传输服务器上的 Microsoft Exchange 传输服务的一种系统资源监视功能。Exchange 传输能够检测重要资源（例如可用硬盘空间和内存）什么时候具备压力，并采起操做以尝试阻止服务不可用性。

    反压能够防止过多地使用系统资源，而且 Exchange 会尝试传递现有邮件。当系统资源使用率恢复到正常级别后，Exchange 服务器就能够逐渐恢复正常运行。

    在 Exchange Server 2007 中，当集线器传输服务器或边缘传输服务器具备资源压力时，它会拒绝传入链接。在 Exchange 2010 中，会接受传入链接，可是会以更慢的速度接受或拒绝经过这些链接传入的邮件。SMTP 主机尝试链接处处于反压下的集线器传输服务器或边缘传输服务器时，链接会成功，可是该主机什么时候发出 MAIL FROM 命令来提交邮件，则取决于具备压力的资源，Exchange 可能会延迟确认 MAIL FROM 命令或拒绝该命令。

    如下摘录自事件查看器：

    Microsoft Exchange 传输服务拒绝邮件提交，由于可用磁盘空间已降至配置的阈值之下。

    如下资源处于压力之下: 队列数据库日志记录路径(“C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue\”) = 95% [中] [正常=93% 中=95% 高=97%]

    反压力致使禁用了如下组件: 从集线器传输服务器提交入站邮件

    从 Internet 提交入站邮件

    从分拣目录提交邮件

    从重播目录提交邮件

    从邮箱服务器提交邮件

    向远程域传递邮件

    正在从队列数据库加载电子邮件(若是可用)

    如下资源处于正常状态: 队列数据库路径(“C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue\mail.que”) = 95% [普通] [正常=95% 中=97% 高=99%]

    版本存储桶 = 0 [普通] [正常=80 中=120 高=200]

    专用字节 = 0% [普通] [正常=71% 中=73% 高=75%]

    物理内存负载 = 11% [开始邮件冻结的限制为 94%。]

    批处理点 = 0 [普通] [正常=1000 中级=2000 高级=4000]

    提交队列 = 0 [普通] [通常=1000 中=2000 高=4000]

    注：其实Linux中也有相似的保护机制，如oom，磁盘保留5%，遇到此类知识应该触类旁通，举一反三。

---

故障反思和总结

1. 遇到故障或问题应该保持头脑冷静，切莫慌乱，不能自身乱了阵脚。不少运维或者管理员在遇到问题时首先想到是如何解决，而尝试各类办法解决无果后为了节约时间就想到回滚，这是不正确的。做为一个合格的运维应该弄清事情的前因后果和问题的根本缘由。在排查问题时首先想到经过日志去排查问题。在排查时应当尽量全面的排查，不要漏掉任何一个可能致使问题的细节。

2. 部署必须听从标准，必须规范。从此次事故来看，此Exchange服务器中含有三个数据库，其中一个数据库存放在C盘没有在其余盘。随着时间的增加，这个数据库占用了大量的磁盘空间，致使磁盘空间不足，从而触发了“反压”机制。从标准和规范的作法来看，应该将此数据库从C盘移动到其余容量大的磁盘。而且在部署最开始时计算好容量。

3. 重视报警。此服务器是配置了Zabbix监控报警的，并且Zabbix已经监测到故障并发送报警，因为没有及时的处理才致使本次故障的发生。
   

4. 就算是接盘也要痛改前非。由于此邮件服务器是以前运维同事部署的，所以里面有些问题一直搁置而迟迟没有解决（也有技术上的缘由），从长远角度上看，即便须要付出必定的代价也需亡羊补牢。

5. 保持学习。虽然有些时候，某些东西偏离了本身的发展方向，但像邮件服务器这样的公司的核心IT系统应该去深刻的学习。只有了解和懂得才能遇到问题时更快的解决问题。

6. 每次故障后总结经验和吸收教训。将知识和经验记录下来，沉淀下来。好比这次总结后，在遇到此故障可能一会儿就想到了磁盘空间不足会致使Exchange触发反压，从而致使没法收到外部邮件。

--end--