Exchange传输组件大揭秘(下)

Exchange传输组件大揭秘(下)

作者/喻勇

 

导读：

本文根据笔者在微软Technet Webcast上的讲稿整理而成。文章介绍了微软Exchange Server中的核心传输组件以及它们的工作原理，阐述了SMTP协议的内容和使用SMTP发送邮件时的详细过程；深入地讨论了邮件传输和路由的工作机制，分析了SMTP报文的组成和Exchange在传输邮件时的路由过程（包括AQ, Routing Engine等组件）。本文可以供Exchange管理员深入的了解邮件传输组件的内部工作方式。

 

上期回顾

在上一期文章中，我们深入地探讨和分析了邮件在执行分类器操作时所经历的步骤。包括了收件人解析、邮件拆分、地址标识等等细节。当邮件完成分类器的步骤后，系统就已经明确了邮件最终投递位置的地址。怎样从当前的服务器选择一条到达目的地的最优化路径进行邮件投递，就是路由模块所需要考虑的问题。

 

邮件路由

 

在完成邮件的分类操作之后，Exchange Server的路由模块会进行邮件的投递选路。路由模块的任务主要有两个，一个任务是通过读取活动目录和路由更新信息，来掌握整个Exchange组织内部的路由拓扑结构(由Exchange Routing Engine Service来完成)，另一个任务，就是针对在拓扑结构中给定的两个主机，选择一条最为快捷(low cost)的邮件传送线路(由Routing Engine来完成)。为了理解这两个主要的功能，我们需要先了解一下Exchange中关于邮件路由的一些重要概念。图一中显示了一个比较典型的Exchange邮件系统的拓扑结构，这个结构由路由组，桥头堡服务器和连接器所组成。下面，我们逐一解释一下这些概念。

 

路由组通常由一些具有高速连接或者地理位置分布上靠近的服务器所组成。在路由组内部，服务器之间的邮件传递是通过直接连接进行的。例如，当图一C路由组中C-EX02服务器上的邮箱用户发信给C-EX01服务器上的邮箱时，C-EX02的SMTP引擎和C-EX01建立直接的连接并进行邮件投递。

 

桥头堡服务器负责其所在的路由组与外界进行沟通的任务。所有发送到路由组以外的邮件，都需要通过桥头堡服务器进行转发；同样，所有来自外界的邮件，也需要先由桥头堡服务器进行接收，然后再转发到路由组内部的服务器上。例如，当图一中C-EX01服务器需要向A-EX02服务器发送邮件时，邮件的投递路径为：C-EX01-->C-MX01-->A-MX01-->A-EX02。在这个路径中，本地桥头堡(C-MX01)和远程桥头堡(A-MX01)承担了邮件的转发任务。

 

连接器是一系列连接路由组的逻辑规则。图一中的1、2、3都表示连接路由组和外界的连接器。在Exchange系统中，主要采用的连接器类型有路由组连接器和SMTP连接器。其中前者主要负责Exchange系统内部各个路由组之间的连接，如图中的1和2，而后者主要负责Exchange系统和外部的连接，图中的3号连接器为SMTP连接器，负责为整个系统向Internet发送邮件。

图一：典型Exchange路由拓扑结构

 

路由组、桥头堡和连接器这些构成Exchange拓扑结构的要素，其配置信息都保存在活动目录中，并通过活动目录的复制，在所有的域控制器上保持同步。当任何一台Exchange Server启动时，它需要做的一项重要操作就是构建其所在的这个Exchange组织的路由表。Exchange Routing Engine Service(resvc.dll)会在服务器启动时，从活动目录中获取所需要的拓扑结构信息，并通过这些信息来构建Exchange的初始路由表(称之为Link State Table)。当服务器运行过程中有任何路由更新发生时(如某一个桥头堡服务器down机，或者某一个连接器的配置发生变化)，Exchange Routing Engine Service会侦测到这一个路由拓扑变化，并向各个服务器发送路由更新通知，以确保所有的服务器都及时地更新其路由表。

 

系统管理员可以使用Winroute这个工具察看Exchange的路由表信息，该工具的具体操作步骤，可以参考下面的微软知识库文档：How to use the WinRoute tool，。

 

对于每一个路由组之间的连接器，都有至少一个地址空间(Address Space)与其关联。地址空间表示通过该连接器可以到达的目的地范围。路由引擎在进行邮件选路时，根据邮件的目的地，通过这些连接器上地址空间信息来判断和选择相应的连接器进行邮件传送。

 

连接器上的每一条地址空间记录由三部分字段组成，分别是地址空间类型、权重(Cost)和地址空间实际数据。

 

地址空间类型用来指明连接器所连接的目标服务器的类型，可以是内部的Exchange路由组，也可能是X.400的系统或者外部的SMTP服务器。根据连接目标类型的不同，地址空间数据的格式也不同。

 

权重是地址空间的属性之一，用来决定哪一个连接器对特定的目的地有优先级。例如，当通过多个连接器都能到达一个目标时，权重(Cost)最低的那个连接器将被选中。如果有多个连接器都有同样的权重，则路由引擎将在这些连接器上平均分配负载。

 

在图二中，我们在原来的路由拓扑基础之上，标注了地址空间的信息。连接器1，2是路由组连接器，每个连接器上都有双向的地址空间，表示这个连接器两端的路由组。连接器3是SMTP连接器，这个是单向的，地址空间为所有外部的域名。

图二：连接器上的地址空间

 

我们通过举例子来了解Exchange的邮件路由过程。

 

从B-EX01服务器发信到B-EX02服务器。邮件在B-EX01服务器上完成分类器操作，通过查询活动目录，得知邮件最终目的地为B-EX02服务器。根据B-EX01服务器所掌握的邮件系统拓扑结构，它知道B-EX02服务器跟它是在同一个路由组中，因此使用直接连接进行发信。

 

当B-EX01服务器发信给C-EX02服务器。邮件在B-EX01服务器上完成分类器操作，通过查询活动目录，得知邮件最终目的地为C-EX02服务器。根据B-EX01服务器所掌握的邮件系统拓扑结构，它知道C-EX02服务器位与路由组C，此时，需要进行选路操作。由于路由组B和C之间没有直接的连接器，路由引擎在经过判断后，会选择通过连接器1、2进行邮件投递。

 

从B-EX01服务器发信给Internet上的地址，此时目的地的地址类型和SMTP连接器上所标注的地址空间匹配，系统知道，邮件必须首先抵达SMTP连接器的桥头堡(即A-MX02服务器)才能向外发送，因此路由引擎会把邮件通过1、3连接器进行外发投递。

 

上面我们讨论的只是最简单的路由结构，当有多个路由组、连接器和不同的权重混合共存时，选路的过程会变得复杂的多。Exchange Server路由引擎采用经典的Dijkstra最短路径算法进行路由计算，确保在任何情况下，总是获得最优的路由结果。

 

Exchange存储和传输模块之间的桥梁: Store Driver

 

我们回忆一下在前文中出现过的这个邮件投递过程图(图三)。需要进行投递的邮件来源包括SMTP引擎(Queue目录)和Exchange数据库，Exchange传输系统在工作时，会频繁的从硬盘的Queue目录和Exchange数据库中读取和写入邮件数据。我们知道，SMTP传输系统工作在IIS的进程中，Exchange邮件数据库引擎工作在Store.exe进程中，如何使这两个进程可以快速的交换数据，是Exchange开发者所必须解决的问题。

 

高级对列引擎(AQE)在处理邮件时，在每个Event Sink之间传递代表邮件的MailMsg对象(具体过程请参考上期文章)。MailMsg对象由待处理邮件的SMTP信封数据和一个指向实际邮件位置的指针(句柄)所组成。当传输引擎需要读取邮件的内容时，会通过这个指针访问磁盘上的Queue目录或者邮件数据库。微软采用NTFS Store Driver和Exchange Store Driver这两种技术，使这些访问能够以非常高效的方式进行。

图三：Exchange邮件传输流程

 

为了使传输组件方便的访问磁盘上Queue目录中的邮件，微软采用了名为NTFS Store Driver的底层组件，这个组件可以帮助传输引擎使用指针(句柄)的方式快速的访问NTFS文件系统上的文件，而不是采用相对比较慢的CreateFile的传统Win32 API方式进行访问。这个模块包含在Windows 2000 IIS 5.0中，在NTFSDrv.dll这个文件中被实现，Exchange只是“借用”了这个现成的组件。

 

为了解决传输组件访问Exchange数据库的性能问题，微软采用了Exchange Store Driver技术。Exchange Store Driver使传输引擎可以使用指针(句柄)的方式快速的访问Exchange的数据库中的内容，而不是采用非常低效率的MAPI接口，这样极大的提高了邮件传输的效率和性能。

 

相比前面提到的NTFS Store Driver，Exchange Store Driver在技术上更加复杂。我们知道，在Windows平台下，Exchange数据库引擎(Store.exe)和IIS服务进程(inetinfo.exe)是各自独立的进程(如图四)。Windows的每个进程都有独立的虚拟地址空间，因此，IIS是无法直接访问Store进程空间中的数据的。

图四：Store和IIS的进程

 

为了把数据库中的邮件信息放置到AQE的pre-submission队列中，Exchange store driver成为了两个进程间数据交换的桥梁。Exchange store driver由一组Event Sink组成，主要包括如下三个文件：

 

Drviis.dll，这个DLL运行在IIS的进程空间，负责和AQE引擎进行通信。

 

ExSMTP.dll，这个DLL运行在Exchange数据库引擎的进程空间，这个组件负责建立数据库和Epoxy.dll的通信接口。

 

我们可以认为Drviis.dll和ExSMTP.dll是坐落在两个不同进程上桥墩，而Epoxy.dll，就是实现数据共享的桥梁本身。在Epoxy.dll中，微软通过ExIPC连接Store和IIS，在这两个进程中，开启了一块可以共享的虚拟内存空间(基于Shared Memory Circular Queue技术)。在这块共享内存的帮助下，Exchange得以在存储和传输引擎之间快速的进行数据交换。

 

如图五，Epoxy.dll不仅为SMTP服务和Store建立了快速通道，实际上，通过Epoxy，IIS中的多个服务都可以与Store里面对应的模块进行快速通信。举例来说，当用户通过OWA访问邮件时，IIS就是通过IFS和Epoxy到数据库中去获取邮件的；POP3服务也是同样，当用户使用POP3客户端收信时，邮件通过Expop3-->Epoxy-->IFS-->POP3这样的路径传递到IIS，最终通过网络到达客户端。

图五：Epoxy

 

常用的传输排错工具

 

为了有效的诊断和解决Exchange传输和路由系统中的问题，系统管理员必须对这些组件有深入的理解，包括组件之间的交互方式、邮件传输的路径、路由判断的依据等等。同时，管理员也应该对一些常用的工具做到了如指掌，在出现问题的时候，可以对症下药。下面我们介绍一些用来诊断邮件传输问题工具。我们把常用的工具分为四个类别：Exchange管理器中集成的工具、日志记录工具、报表统计工具和跟踪工具。

 

在Exchange管理器中，常用的工具包括队列查看器和Message Tracking Center。通过队列查看器，可以观察到SMTP AQE各个队列中正在被处理的邮件数量，明确当前邮件传输的瓶颈位置；使用Message Tracking Center工具，可以获得一封邮件在Exchange系统中投递的详细过程，包括经过每一台服务器的时间和投递动作。

 

日志记录工具包括Exchange诊断日志和SMTP协议日志。管理员可以开启Exchange诊断日志来获得邮件服务器内部更加详细的信息，SMTP协议日志则将记录SMTP交互过程中的每一个细节。这两种日志默认情况下是关闭的，启用这些日志将影响系统的性能。

 

报表统计工具包括LDP、ADSIEdit、NetDiag、Winroute、目录复制工具、DsaDiag。使用LDP和ADSIEdit可以获得活动目录内部的细节数据；NetDiag可以诊断服务器网络设置是否有问题；Winroute可以查看Exchange的路由表；目录复制检测工具可以判断域控制器之间的复制是否完成；DsaDiag可以诊断Exchange和活动目录之间的连接是否存在问题。

 

跟踪工具包括Regtrace和Netmon。Regtrace是一个源代码级别的排错工具，它会记录传输组件内部每一个函数调用和参数，输出的文件需要由微软公司专门的技术人员进行分析，可以发现和定位非常隐蔽的问题。Netmon可以获取网络数据包并进行分析。

 

除了以上四个类别以外，还有一些常用的工具，包括：Telnet、Nslookup、Filever等。

 

在下表中，笔者列出了这些工具的名称和如何使用的文档，这些代号是微软知识库文档的标号，在 输入文档号，即可查到文档内容。

 

工具名称	文档代号
队列查看器	823489
Message Tracking Center	246983
Exchange诊断日志	181451
SMTP协议日志	265139
LDP	255602
ADSIEdit	312299
NetDiag	321708
Winroute	281382
Replmon	318340
RepAdmin	229896
NLTest	158148
DsaDiag	283099
Regtrace	238614
Netmon	812953
Telnet	153119
Nslookup	203204
Filever	183713

 

表一：常用Exchange排错工具

 

在此我们并不会花太多的篇幅介绍每个工具的详细用法，我们将讨论一些诊断邮件传输问题的流程和思路。

 

邮件传输问题大致可以分为两类：连通性问题，即无法正确的发送和接收邮件；性能问题，即邮件传输速度明显的下降。在诊断问题时，首先要精确的定义问题，包括：问题的具体表现形式，重现问题的步骤，问题影响的范围。问题发生的时间等。笔者见过很多管理员在系统发生问题时进行盲目的诊断操作，在没有搞清楚问题的实质时就匆忙操作，这无异于南辕北辙、事倍功半。

 

对于邮件连通性问题，一般有以下的一些原因：

 

1.       外网DNS设置不当，包括没有正确的配置MX记录和反向解析记录。

2.       邮件传输受到反垃圾邮件系统和黑名单的屏蔽。

3.       Exchange SMTP虚拟服务器的设置不正确。

4.       Exchange系统内部的连通行问题比较少见，一般跟路由组连接器设置有关。活动目录信息的不同步，也会造成这样的问题。

 

对于邮件传输性能问题，一般有以下的一些原因：

 

1.       邮件系统的SMTP网关受到垃圾邮件攻击，包括被Relay、NDR和DDOS攻击等,导致系统过载，邮件处理速度缓慢。

2.       邮件服务器和活动目录的连接出现问题，导致系统在执行邮件分类操作时动作缓慢，这会严重的影响系统性能。一般网络连接问题、域控制器繁忙都会引起此类问题。可以通过查看Exchange Server上LDAP请求的性能计数器来判断是否属于域控制器的问题。

3.       邮件服务器的Queue目录所在的磁盘过于繁忙，也会导致传输速度缓慢。如果服务器有大量的邮件进出流量，一般建议把Queue目录放到一个专用的磁盘阵列上，以提高I/O响应速度。

 

下面是一些常规的传输问题排错思路

 

General troubleshooting for transport issues in Exchange Server

How to troubleshoot for Exchange Server 2003 transport issues