故障发现 某天下午18点50左右结束团队内培训分享会后,收到同事的反馈,说他们几个人都无法收到外部邮件(Internet上的邮件),故障现象为:Exchange服务器内网收发邮件正常,外网发送正常,但无法收到外部邮件。 因为公司的邮件系统是公司自建的Exchange Server 2010,因此需要运维自己去管理。经过多个外部邮箱的测试发现,的确无法收到外部邮件,这些外部邮箱包括网易、阿里企业邮箱和微软Outlook邮箱。
因为邮件服务是企业核心服务之一,加之已经有同事反馈遇到问题,因此此故障应该是重要紧急故障,必须尽快排除以恢复服务。
故障处理
面临故障最重要的就是尽快通过排除法进行故障排除以实现服务的最快恢复。因此首先要做的故障排除。由于已经是下班时间,事故虽然重大,但还尚未造成重大影响。
因为在Windows特别是Exchange的运维上个人经验比较欠缺,不能凭经验一下子发现问题,因此只能先根据以往经验,结合Google等逐个排查。
经过初步测试,内部邮件收发正常,内部向外部发送邮件正常,但接收异常。于是开始以下排查。
在排查之前应该先需要搞清楚最近发生的变更,如软件配置,导致变更的操作,特别是两个及以上的管理员共同管理时。
因此服务器由一人管理,且最近没有进行过任何更改,是突然出现的问题,因此直接开始排查:
一、网络问题排查 检查域名解析,排查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记录即可。 经过排查,排除域名解析问题。
检查外部与内部的通信问题,检查防火墙拦截情况和防火墙到服务器中间的网络链路问题。使用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”字样。
为了确认不是防火墙或网络设备bug问题,重启防火墙或网络设备。 通常无软关闭和重启功能的防火墙需要断电或切换电源状态10s以上。经过检查不是网络设备问题。
以上3个步骤排除后,应该确定问题是出在邮件服务器身上。开始邮件服务器自身的排查!
二、服务器自身排查
因为是邮件服务器内部收发正常,因此直接登录邮件服务器,检查邮件服务器的其他可能影响因素 首先检查服务器负载,包括CPU、内存、磁盘空间、IO和网络等负载情况。通常影响Exchange的主要是CPU和内存,其次磁盘空间和IO。经过检查磁盘空间不足(已经低于5%,但尚有3GB可用空间,由于经验不足,没有判断出此问题可能造成的影响,加之内网邮件正常,因此没有优先处理,最后发现是此原因造成)。
其次应该检查服务器系统日志。关于先检查日志还是先检查负载情况,只是习惯问题。系统日志一般会给与管理员足够的信息。虽然Windows的事件管理器并不是特别好用,但是Exchange在日志方面还是比较良心,一般大小事件均记录在内。
除了检查系统日志之外,Exchange一般提供了其他诊断工具。比如“队列查看器”,因为队列查看器可用于解决邮件流问题,因此队列查看器里面也会有一些关于邮件无法传输的问题的提示。
经过查看系统日志和队列查看器后,发现问题是由于资源不足引起。
系统有两处明显的提示:
1.队列查看器提示上一个错误为“452 4.3.1 Insufficient system resources”。 经过Google查询,这通常意味着要么磁盘空间不足要么内存空间不足。
2.事件查看器中来源自“MSExchangeTransport”报告称: (1)警告:资源压力已从 普通 增至 中。 (2)错误:Microsoft Exchange 传输服务拒绝邮件提交,因为可用磁盘空间已降至配置的阈值之下。
故障确认和修复 已经确认为磁盘空间问题导致的触发Exchange的“反压”保护策略。通过释放磁盘空间解决。解决后通告给上级领导和相关人员。
|