Exchange Server 2003 邮件路由
上一次修改主题: 2007-03-06
上一主题已讨论,对于要发送给非本地收件人的邮件,路由引擎必须提供高级排队引擎,并提供目标传输路径中的下一跃点主机的有关信息以及下一跃点类型。下一跃点主机是实际的路由地址,下一跃点类型决定了高级排队引擎如何处理邮件。要提供这一重要信息,路由引擎必须全面了解整个路由拓扑。其中包括所有路由组及其服务器、路由组连接器,以及连接到外部邮件系统的连接器。可在 Exchange Server 2003 的 Active Directory 目录服务中获取此信息。
邮件路由和链路状态表
每一台 Exchange 2003 服务器都基于 Active Directory 和链路状态信息在内存中动态维护其自身的路由表,也称为链路状态表,具体如下所述:
与路由有关的 Active Directory 信息 此信息存储在组织对象、路由组对象、连接器对象和服务器对象的属性中。这些对象驻留在配置目录分区中,并定义整个 Exchange 组织的路由拓扑。
注意: 管理组不是 Exchange 组织中的路由拓扑的一部分。 链路状态信息 该信息指定路由拓扑中的每个连接器可用 (up) 还是不可用 (down)。链路状态信息是动态的,当连接器遇到传输问题或者传输问题解决时,此信息可能会发生变化。有关链路状态更改和跨 Exchange 组织传播链路状态信息的详细信息,请参阅链路状态传播。
初始化链路状态表
启动时,每一台 Exchange 服务器都用 Active Directory 中的下列信息初始化它的链路状态表:
- 组织对象 路由拓扑边界是 Exchange 组织。也就是说,链路状态表不包含有关外部桥头服务器或外部邮件系统中的邮件连接器的任何信息。考虑到路由引擎,路由拓扑将终止在外部邮件系统连接器。因此,路由引擎读取在 Active Directory 中的 Exchange 组织对象的 objectGUID 属性中注册的 GUID,并用此 GUID 标记此链路状态表,以确定该路由信息所属的组织。
- 路由组对象 路由引擎枚举任何管理组中存在的所有路由组,并在每个路由组中查询所有对象属性,其中包括列出所有路由组成员服务器的 msExchRoutingGroupMembersBL 属性。路由引擎将此信息放在链路状态表中。路由引擎还将服务器及服务器所属路由组的 GUID 放入内存中的服务器缓存中。服务器缓存中的每个条目都依次由服务器的 FQDN 及服务器所属路由组的 GUID 组成。
另一个重要的路由组属性是 msExchRoutingMasterDN 属性,该属性指向所选路由组中的路由组主服务器的可分辨名称。有关路由组主服务器的任务和职责的详细信息,请参阅此部分后面的讨论。 - 邮件连接器对象 路由引擎枚举每个路由组的“连接”容器中存在的所有对象类型为 msExchconnector 的子对象。“连接”容器中的 msExchconnector 对象是路由组中配置的路由组连接器和外部邮件系统连接器。路由引擎从这些连接器对象中读取所有属性,以确定地址空间、开销值、限制等等。路由引擎将每个连接器的信息放入链路状态表中。这使得邮件可以被路由到本地路由组外部的目标。
此过程将一直持续到路由引擎找到了所有直接和非直接连接的路由组,并查询到了其邮件连接器的详细配置信息。在此过程结束时,路由引擎便全面了解了整个 Exchange 组织中的所有可用传输路径。一个假定前提是所有链路都处于 up 状态,并且可用于邮件传输。链路状态表初始化完成后,路由引擎与本地服务器上的 Microsoft Exchange Routing Engine 服务通信,以获取反映每个连接器当前状态的动态链路状态信息。Exchange Routing Engine 服务通过 TCP 端口 691 连接到本地路由组中的路由组主服务器,以检索此信息。有关链路状态信息的详细信息,请参阅本主题后面的“分析链路状态表”部分。
路由引擎和 Exchange Routing Engine 服务
传输子系统中的路由引擎与 Exchange Routing Engine 服务具有不同的角色。Exchange Routing Engine 服务不执行任何邮件路由。Exchange Routing Engine 服务在本地路由组中的 Exchange 2000 Server 及 Exchange Server 2003 服务器之间传递链路状态信息。Exchange Routing Engine 服务是在 resvc.dll 中实现的,后者位于 \Program Files\Exchsrvr\bin\ 目录中。服务名为 RESvc。有关 Exchange Server 2003 的 Microsoft Windows 服务的详细信息,请参阅 Exchange Server 2003 服务依存关系。
Exchange Routing Engine 服务是路由组内部的链路状态通信服务,而不是路由引擎。SMTP 高级排队引擎和 Exchange MTA 用来路由邮件的实际路由引擎是在名为 reapi.dll 的文件中实现的。对于 Exchange MTA,另外还在 mtaroute.dll 中提供了一些代码。因此,当 Exchange Routing Engine 服务停止时,高级排队引擎和 Exchange MTA 仍然使用 reapi.dll 中的代码来路由邮件。只是,此时不会再收到链路状态表的动态更新。
注意: |
---|
尽管通常不推荐这样做,但是可以禁用组织中运行 Exchange Server 2003 的所有服务器的 Exchange Routing Engine 服务。此时,reapi.dll 中的代码仍然能够使用 Active Directory 中的信息来初始化每一台服务器上的链路状态表,但不会动态更新链路状态表。在这种情况下,Exchange Server 2003 执行静态邮件路由。 |
分析链路状态表
链路状态表是未存储在磁盘中的小型内存数据库。若要检查路由引擎用来制定路由决策的条目,可以使用 Exchange Server 2003 WinRoute 工具 (Winroute.exe),可以从 Downloads for Exchange Server 2003 网站下载该工具。
注意: |
---|
还随 Exchange 2000 Server 一起提供 WinRoute 工具,但是最好下载 Exchange Server 2003 版的 WinRoute 工具,并在组织中的所有 Exchange 2000 及 Exchange Server 2003 服务器上使用此版本的工具。 |
WinRoute 工具连接到选定的 Exchange 服务器上的链路状态端口(TCP 端口 691),并提取链路状态表。该表中的信息是一系列 GUID 和 ASCII 文本,这些 GUID 和 ASCII 文本表示路由组、路由组成员以及路由组中的连接器。链路状态表还包含每个连接器的配置的有关信息。链路状态表中的信息字段以括号进行分隔,如下所示:
'General Info' ('Routing Group' 'Routing Group Master' 'Version Info' 'Routing Group Addresses' (Routing Group Members) (Connectors in Routing Group (Connector configuration))).
下面是链路状态表的一个简化示例(保留了一个路由组,其他所有路由组均被删除):
d38082e7c9ecd74dbff32bada8932642 d037d6eaf2fa7cd10934aca433390623 (489416bfa3a4ff459b8f4403f20cad0d 1650c1fe32aef740be236e1089e0da6a 8 0 2 c2da71f9b39ec748aaf44119a2bdcb36 {26}*.489416BF-A3A4-FF45-9B8F-4403F20CAD0D {4c}c=DE;a= ;p=TailspinToys;o=Exchange;cn=489416BF-A3A4-FF45-9B8F-4403F20CAD0D;* {55}/o=TailspinToys/ou=First administrative Group/*/489416BF-A3A4-FF45-9B8F-4403F20CAD0D ( 1650c1fe32aef740be236e1089e0da6a YES 1 1b20 {10}0701000000000101 ) ( aa582d35e9621c4ca8ae57aa33d953a1 ( CONFIG {4}SMTP {} {23}_aa582d35e9621c4ca8ae57aa33d953a1_D {63}/o=TailspinToys/ou=First administrative Group/cn=Configuration/cn=Connections/cn=RGC RG A <-> RG B 0 0 0 0 ffffffff ffffffff 0 1 0 () 0 () 0 () 0 () ARROWS ( {2}RG {20}83bd0e29fad06d4eb8b00faab3265cd5 1 {4}X400 {23}c=DE;a= ;p=TailspinToys;o=Exchange; 1 ) BH () TARGBH ( 766a192b43bfc3459ee85608d65a98a9 CONN_AVAIL {19}server01.TailspinToys.com ) STATE UP)))
(... next routing group... (... next routing members...) (... connectors in routing group (... connector configuration..)))
下表将此信息与链路状态表中的各个信息字段对照起来进行分析。
链路状态表中的信息
字段 | 值 | 注释 | ||||
---|---|---|---|---|---|---|
组织 objectGUID |
|
在 Active Directory 中的 Exchange 组织对象的 objectGUID 属性中注册的 GUID。 |
||||
MD5 摘要 |
|
MD5 摘要或哈希值。这是表示链路状态表版本号的加密签名。路由引擎可以根据此信息来确定它们是否具有相同的链路状态信息。如果信息不同,路由引擎将交换 OrgInfo 数据包,以确定哪一台服务器拥有最新的信息。OrgInfo 数据包中包含链路状态表,其中有路由拓扑的所有详细信息和状态。链路状态信息的传播在此部分的后面讨论。 |
||||
路由组 objectGUID |
|
在路由信息所属的路由组对象的 objectGUID 属性中注册的 GUID。此 GUID 在链路状态表中位于 MD5 摘要的后面。 |
||||
路由组主服务器 objectGUID |
|
在该路由组中的路由组主服务器的 objectGUID 属性中注册的 GUID。 每个路由组内部的路由组主服务器都负责维护链路状态信息,并将该信息传递给所有路由组成员。每个路由组中都只能有一个路由组主服务器存在。有关路由组主服务器的角色的详细信息,请参阅此部分后面的讨论。 |
||||
版本信息 |
|
版本 8 0 2 分别是链路状态信息的主版本、次版本和用户版本。路由引擎使用此版本信息对链路状态信息的更新进行分类,如下所述:
余下的数据是该版本信息的 GUID。 |
||||
路由组地址 |
|
将 SMTP、X.400、X.500 和地址信息与各个路由组 GUID 对应。路由引擎使用此信息来生成内部服务器缓存,后者用于确定路由拓扑中每台服务器所属的路由组。服务器缓存是路由引擎的内部表。 例如,假定 SERVER01 位于名为“第一个路由组”的路由组中,并且 FQDN 为 SERVER01.TailspinToys.com。按照路由组地址的定义,路由引擎在服务器缓存中为 SERVER01 创建一个条目,如下所示:
在路由事件过程中,如果高级排队引擎将该 FQDN 传递给路由引擎,路由引擎便会在服务器缓存中进行查找,以找到与 SERVER01.TailspinToys.com 对应的条目,并快速确定目标路由组。X.400 和 X.500 地址同理;只有地址信息复杂一些。 |
||||
路由组成员 |
|
列出属于该路由组的所有服务器,并标识其状态。但是,请注意,路由引擎在路由邮件的过程中不使用此信息。关于路由引擎使用服务器缓存这一点,在此部分前面已讨论。 为便于系统监视,路由组成员在 Routing Group Members () 列表中列出。在 Exchange 系统管理器中依次打开“工具”节点、“监视和状态”和“状态”后,可以查看此信息。 Routing Group Members () 列表中的服务器状态条目包含下列信息:
用户数据表示服务器的状态。如果该值以 0701 开头,说明服务器可用,并且正在工作。如果该值以 0702 开头,说明服务器处于警告状态。如果该值以 0703 开头,说明服务器处于紧急状态。 要临时取消对服务器的监视,可以将服务器切换到维护模式。这时该值以 0781 开头。 |
||||
路由组中的连接器 |
|
从下一个左括号开始,属于该路由组的每个连接器都在单独的条目中列出。该条目包含连接器的 objectGUID 以及路由引擎用来制定邮件路由决策的配置信息。
|
||||
连接器 objectGUID |
|
在 Exchange 组织中唯一标识连接器的 GUID。 |
||||
连接器类型 |
|
该字段出现在 CONFIG 关键字后,用于标识连接器类型。类型可以是 SMTP、X.400、Notes 或 Exchange Development Kit (EDK)。Notes 和 EDK 类型指的是连接到非 Exchange 邮件系统且基于 MAPI 的邮件连接器的实例。有关基于 MAPI 的连接器的详细信息,请参阅网关邮件连接器体系结构。
|
||||
源桥头地址 |
|
该字段可以有如下三种值之一:
|
||||
目标桥头地址 |
|
与“源桥头地址”字段一样,该字段可以有如下三种值之一:
|
||||
旧的可分辨名称 |
|
这是采用旧的 Exchange 5.5 目录格式的连接器可分辨名称。该值对应 Active Directory 中的连接器对象的 legacyExchangeDN 属性。 |
||||
日程安排 ID |
|
“日程安排 ID”字段未使用,并始终设置为 0。高级排队引擎和 Exchange MTA 查询 Active Directory,以确定连接器的激活日程安排。 |
||||
限制 |
|
“限制”字段标识连接器的作用域、邮件大小限制以及其他约束条件,如下所述:
|
||||
地址空间 |
|
每个连接器至少有一个关联的地址空间。通过将收件人地址与可用的地址空间信息进行比较,路由引擎使用该信息来确定特定邮件的可能连接器。 在链路状态表中,ARROWS () 列表包含属于该连接器的各个地址空间。每个地址空间条目都包含如下三条信息:
|
||||
源桥头 |
|
BH 字段列出连接器的本地桥头服务器及其状态信息。桥头服务器是使用如下三条信息来标识的:
|
||||
目标桥头 |
|
与 BH () 列表类似,TARGBH () 列表包含连接器的目标桥头服务器。此列表对于路由组连接器尤为重要。路由组连接器可以有多个远程桥头服务器。 在本例中,下列信息标识远程桥头服务器:
|
||||
状态 |
|
连接器的状态。该字段有两个可能的值:
连接器状态是从连接器源桥头服务器的状态中得出的。只有在至少有一个源桥头服务器可用 (CONN_AVAIL) 时,连接器才处于 STATE UP 状态。如果连接器的所有源桥头虚拟服务器都未启动 (VS_NOT_STARTED),或者源桥头无法建立连接 (CONN_NOT_AVAIL),那么连接器状态将为 STATE DOWN。
|
注意: |
---|
如果 WinRoute 工具能够访问 Active Directory,便会将链路状态表中的 GUID 解析为采用可读格式的名称,从而提供了路由拓扑和链路状态表的直观视图。WinRoute 程序窗口的上窗格显示解析后的数据,中间窗格列出现有的所有地址空间,下窗格显示链路状态表中的原始信息。有关 WinRoute 工具的详细信息,请参阅 Tools for Exchange Server 2003中的工具下载信息。 |
Exchange 路由路径选择
在具有多个路由组的组织中,可能有多个路由路径的目标相同。通常,采用最高效(即最短或开销最低)的路由路径来传输邮件,而其他路由路径处于等待状态,以备在最佳路由路径暂时不可用时启用。例如,在如下图所示的拓扑中,所有路由组之间都存在多个传输路由路径。
注意: |
---|
邮件路由应遵循物理网络拓扑。如果在真正的中心辐射型结构中设计了基础网络拓扑(其中路由组 A 为中心组),那么定义如上图所示的路由组连接器没有意义。因而,由组 B、C、D 和 E 应当直接连接到路由组 A,并且所有路由组间的邮件传输都应当通过路由组 A 进行路由。在实际的中心辐射型布置中,没有备用的邮件路径,并且路由路径选择是很简单的。但是,为方便此部分进行说明,假定物理网络拓扑是网状结构,它采用如图所示的路由组连接器布置。 |
路由引擎使用下列信息来确定最佳路由:
地址空间 配置路由组连接器时,可以使用连接器属性中的“连接的路由组”选项卡将可能的目标与邮件连接器关联。但是,路由组连接器不提供该选项卡。由于此连接器仅用于连接到路由组,因此路由引擎可以通过连接器配置来确定路由组地址空间。
可以通过“地址空间”选项卡将地址空间添加到连接器中。“链路状态表中的信息”中已提到,地址空间由地址类型(如 RG、SMTP、X400、MSMAIL 或 CCMAIL)、地址和开销值组成。分配给地址空间的开销值是一个重要的路由标准。路由引擎使用 Dijkstra 最短路径算法来制定路由决策。此算法就是基于开销值。连接器作用域 外部邮件系统连接器的作用域可能仅限于连接器的路由组,在这种情况下,只允许连接器本地路由组中的用户使用该连接器。默认情况下,所有连接器的作用域都是“整个组织”。
注意: 路由组连接器始终可以用在整个组织中。 限制 路由引擎确定邮件大小、优先级以及邮件类型(也就是系统邮件还是非系统邮件)。路由引擎将这些属性与可用的连接器限制信息进行比较。然后,它将由于违反连接器限制而无法传输邮件的那些连接器从可能的连接器列表中删除。
状态 在选择路由的过程中只能选择可用的连接器。每个连接器的状态字段都指示该连接器可用 (STATE UP) 还是不可用 (STATE DOWN)。
路由路径选择过程
为了选择到达目标的最佳路径,路由引擎使用 Dijkstra 最短路径算法,计算在 Exchange 组织中从源路由组到目标路由组的最短传输路径。然后,路由引擎确定高级排队引擎应当用来传输邮件的最短路径中的下一跃点。
选择路由路径的过程由两步组成:
- 高级排队引擎调用路由引擎的 IMessageRouter 接口上的 GetMessageType 方法。在 GetMessageType 方法中,高级排队引擎将邮件以 MailMsg 对象的形式传递给路由引擎。
在这一步中,路由引擎执行下列过程:检查邮件跟踪信息以检测是否存在循环。如果检测到邮件循环,便会将邮件随同 NDR 一起返还给发件人。
读取或重新计算(如有必要)当前组织拓扑,也就是说,确定到达路由拓扑中的所有目标的最短路径列表(从本地路由组开始)。
在链路状态表中检查关于连接器的限制信息,并在必要时刷新此限制信息。
确定组织拓扑中可用来将邮件传输到目标的所有连接器,然后分析邮件特征和连接器限制,以排除不得用来传输邮件的所有连接器。
计算邮件的筛选值,该值唯一地定义邮件类型。邮件类型标识具有类似特征的邮件可以使用的实际路径。邮件类型会缓存起来。这样,路由引擎便不必为具有类似特征的后续邮件重新计算筛选值。
注意: 高级排队引擎为每一种邮件类型都维护一个单独的邮件队列。 创建关联的邮件类型。关联的邮件类型与实际邮件类型类似,但却是使用较宽松的限制标准来计算的。如果由于连接器限制而使传输路径对于实际的邮件类型不可用,关联的邮件类型使 SMTP 传输子系统可以返回更多的错误代码。
将缓存的邮件类型的索引返回给高级排队引擎。
- 路由引擎确定最短路径中的下一跃点。为完成此步骤,高级排队引擎调用 IMessageRouter 接口上的 GetMessageType 方法。高级排队引擎此时传递给路由引擎的最重要信息是目标地址和邮件类型 ID。对于 Exchange 组织中的收件人,目标地址是收件人主服务器的 FQDN。路由引擎根据服务器缓存确定目标路由组、检查可用于该邮件类型的传输路径,并将到达目标路由组的传输路径中的下一跃点返回给高级排队引擎。然后,高级排队引擎可以将邮件传输到目标路径中的下一跃点。
Dijkstra 最短路径算法
要制定正确的路由决策,路由引擎必须了解到达路由拓扑中所有可能目标的最短路径。在复杂的路由拓扑中,路由引擎必须从到达所有目标的所有可用传输路径中选择最短的传输路径。此问题称为单源最短路径问题。
下图显示:即使在相对简单的路由拓扑中,从一个路由组到其他任何路由组之间也可能存在许多路由路径。该图以简化的形式显示图 5.4 中的路由组连接器,并假定其默认开销值为 1。
1959 年,Edsger Dijkstra 教授提出了一种算法,通过一次计算找到从指定源到拓扑中所有点的最短路径,从而解决了单源最短路径问题。
路由引擎采用 Dijkstra 算法,具体如下所述:
- 用路由拓扑来表示从一个路由组到其他所有路由组的所有路径,并假定路由拓扑是一棵生成树。这决定了拓扑必须包含所有路由组和路由组连接器,并且路由组之间不存在循环。因此,路由拓扑中允许邮件返回源路由组的路径是非法传输路径,在计算时不包括这些路径。
- 根据 Dijkstra 的算法,路由引擎维护两个路由组集合。第一个集合包含到源路由组的最短路径已被确定的所有组。第二个集合包含余下的所有路由组。起初,到源路由组的最短路径已被确定的路由组集合是空的。只要还有剩余的路由组未处理,路由引擎便会执行步骤 3 到步骤 6,如下所述:
- 路由引擎依据与源路由组的距离的当前最佳估计值(即开销值之和)对余下的路由组进行排序。
- 然后,将距离最近的路由组添加到被确定为具有最短路径的路由组集合中。
- 然后,路由引擎更新连接到该路由组的所有路由组的开销(如果这能够改善余下的每个路由组的最短路径最佳估计值),方法是将这些路由组之间的连接器的开销值加到距离值中。
- 更新所有已更新的路由组的前置路由组。前置路由组列表最终定义了从每个路由组到目标路由组的最短路径。
下列步骤说明了路由引擎如何找到从路由组 A 到路由拓扑中的其他所有路由组的最短路径。
- 计算开始于路由组 A,因为在此示例中源为路由组 A。路由组 A 到它本身的距离值是零。其他所有路由组的距离值尚未确定。
- 路由组 A 被添加到已确定到源路由组的最短路径的路由组集合中。然后,用与路由组 A 相邻的所有路由组的连接器开销值更新其距离值。然后所有这些路由组的原有值(用黑色箭头的源指示)都更新。前置路由组是路由组 A。
- 路由引擎依据与源路由组的距离的当前最佳估计值对余下的路由组进行排序。将距离最近的路由组添加到其最短路径已被确定的路由组集合中。由于路由组 B 和 C 具有相同的距离值,因此路由引擎随机选择一个路由组。本示例假定路由引擎选择路由组 B。
- 路由引擎计算与路由组 B 相邻的余下所有路由组的距离值,方法是:将路由组 B 与相邻路由组之间的连接器开销值与路由组 B 的距离值相加。只有在计算出的距离值小于已分配给该路由组的值时,才更新相邻路由组的距离值,并在之后更新前置路由组(用黑色箭头指示)。
与路由组 B 相邻的路由组是路由组 C、D 和 E。路由组 C 和 D 的当前距离值未指定。因此,通过将其连接器的开销值与路由组 B 的距离值相加 (1+1) 来确定其距离值。然后所有这些路由组的前置路由组(用黑色箭头的源指示)都更新。前置路由组是路由组 B。
路由组 C 未更新,因为路由组 C 的距离值与连接器开销之和 (1+1) 大于路由组 C 当前的距离值。 - 路由引擎依据与源路由组的距离的当前最佳估计值对余下的路由组进行排序,并将最近的路由组添加其最短路径已被确定的路由组集合中。该算法现在采用路由组 C,因为该路由组具有最小的距离值。
- 路由引擎计算与路由组 C 相邻的余下所有路由组的距离值,方法是:将路由组 C 与相邻路由组之间的连接器开销值与路由组 C 的距离值相加。只有在计算出的距离值小于已分配给该路由组的值时,才更新相邻路由组的距离值,并在之后更新前置路由组(用黑色箭头指示)。
与路由组 C 相邻的余下路由组是路由组 D 和 E(路由组 A 和 B 已处理)。
路由组 D 和 E 的当前距离值是 2。该值小于连接器开销与路由组 C 的距离值之和 (1+2)。因此,路由组 D 和 E 的距离值和前置路由组列表不更新。 - 路由引擎依据与源路由组的距离的当前最佳估计值对余下的路由组(路由组 D 和 E)进行排序,并将最近的路由组添加到其最短路径已被确定的路由组集合中。
由于路由组 D 和 E 具有相同的距离值,因此路由引擎随机选择一个路由组。本示例假定路由引擎选择路由组 D。
余下的唯一一个相邻路由组是路由组 E,该路由组的当前距离值为 2。该值小于连接器开销与路由组 D 的距离值之和 (1+2)。因此,路由组 E 的距离值和前置路由组列表不更新。
尚未添加到其最短路径已被确定的路由组列表中的最后一个路由组是路由组 E。余下没有相邻的路由组。因此,最短路径的计算完成。从路由组 A 到拓扑中的其他所有路由组的最短路径都已确定。
邮件传输负载平衡
如前面步骤所述,如果存在多个开销值相同的路径,路由引擎将随机选择一条传输路径。但是,路由引擎不执行负载平衡。前面已指出,路由引擎缓存邮件类型信息,该信息指示邮件可用来到达目标的最短路径。因此,同一类型的所有邮件采用相同的路径,即便存在开销值相同的其他路径也是如此(例如,“路由组 A > 路由组 B > 路由组 E”和“路由组 A > 路由组 C > 路由组 E”)。
路由组之间的负载平衡
路由组之间真正的负载平衡只能通过使用一个具有多个桥头服务器的路由组连接器来实现。
下表列出了可以用在路由组之间的负载平衡配置。
路由组之间可能的配置
可能的配置 | 注释 | ||
---|---|---|---|
具有多个源桥头服务器和/或多个目标桥头服务器的单路由组连接器。 |
使用这些类型的连接器,路由引擎可以将下一跃点信息中的连接器 GUID 返回给高级排队引擎。然后,高级排队引擎随机选择必须使用的桥头服务器,从而在所有桥头服务器之间平衡邮件传输负载。 如果邮件到达具有多个源桥头服务器的路由组连接器的某个源桥头服务器,邮件将不会被重新路由到其他任何源桥头服务器。在邮件到达路由组连接器后,便可直接传输到目标路由组。因此,其邮箱驻留在桥头服务器上的用户始终使用本地服务器将邮件传输到目标路由组。
|
||
具有相同的地址空间(或连接的路由组)、相同权重(开销)并且每个都有一个源桥头服务器和一个目标桥头服务器的多个连接器 |
在此类型的配置中,未实现真正的负载平衡。只有在一开始为给定邮件类型选择连接器时才会执行负载平衡。路由引擎仅确定邮件类型一次,并缓存此信息,之后将通过同一连接器路由该类型的所有邮件。第二个连接器只有在第一个连接器失败时才使用。但是,第二个服务器可能会选择第二个连接器,并以此方式使负载达到某种程度的平衡。
|
||
具有相同的地址空间(或连接的路由组)、不同权重(开销)并且每个都有一个源桥头服务器和一个目标桥头服务器的多个连接器 |
如果希望配置连接器使其自动进行故障转移,可以在不同的桥头服务器上创建两个单独的连接器,并使每个连接器的开销不同。连接器的链接状态是由其本地桥头服务器来确定的。如果开销最低的首选连接器上的桥头服务器不可用,将认为该连接器不可用,并且路由将自动选择第二个连接器。当开销最低的连接器所在的桥头服务器可用时,Exchange 服务器将再次开始使用它。 |
连接器与外部系统之间的负载平衡
取决于具体方案,可以有几种方式实现跨 SMTP 连接器的负载平衡。
- 如果要在发送方组织中让跨越多个服务器的出站请求实现负载平衡,请配置多个源桥头。
- 如果要让跨越多个目标服务器的通信实现负载平衡,则可以让目标管理员正确配置 DNS(使用合适的 MX 和 A 记录配置),也可以在连接器上指定多个智能主机地址。
或者,如果要确保故障转移弹性,请创建多个 SMTP 连接器,并将相同的地址空间、不同的开销和不同的源桥头作为作用域。如果开销最低的首选连接器上的桥头服务器不可用,将认为该连接器不可用,路由将自动选择第二个连接器。如果使用两个具有相同开销的连接器,则 Exchange 服务器随机选择要使用的桥头服务器和连接器。然后,如果此桥头服务器变得不可用,它们会将故障转移到第二个连接器。但是,在第一台桥头服务器变为可用时,服务器不会将故障回复到这台服务器上,因为其路由开销与它们正在使用的服务器的开销相同。
例如,由于地址空间不匹配,下图中的连接器配置不是针对故障转移的负载平衡配置。发送到 .Net 域中的外部用户的邮件始终通过地址空间为 .Net 的 SMTP 连接器传输。这是因为路由引擎在评估开销之前,先选择最具体的地址。
注意: |
---|
如果地址空间为 *.Net 的连接器上存在限制,并且这些限制使得某些邮件无法通过该连接器(例如,由于拒绝发件人通过该连接器传输邮件),那么路由引擎会将邮件随同 NDR 一起返还给发件人。路由引擎不会重新尝试通过第二个连接器来传输这些邮件。将使用地址空间最具体的连接器来传输邮件。计算传输路径的过程中,不会考虑地址空间具体程度较低的连接器。 |
基于链路状态信息的邮件重新路由
如果连接器无法传输邮件,高级排队引擎将通知路由引擎链路出现故障。这可能导致路由引擎将连接器标记为 down。在这种情况下,将重新路由所有排队的邮件。
如果满足下列条件之一,路由引擎便会认为连接器的状态为 down:
- 路由引擎无法与连接器的任何源桥头服务器建立连接,并且在路由组主服务器与源桥头服务器之间没有与端口 691 的 TCP/IP 连接。在链路状态表中,不可用的源桥头服务器标记为 VS_NOT_STARTED。
- 任何源桥头服务器都无法成功地将邮件传输到目标桥头服务器。无法将邮件传输到目标的源桥头服务器标记为 CONN_NOT_AVAIL。
注意: |
---|
如果使用 X.400 连接器,但是该连接器无法传输邮件,则 xchange MTA 会通知路由引擎发生了链路故障。这时源桥头服务器的状态为 CONN_NOT_AVAIL。X.400 连接器只能有一个源桥头服务器。 |
邮件重新路由
为确保有效的邮件传输,路由引擎会在链路状态发生任何变化时立即通知高级排队引擎和 Exchange MTA。为避免通过已断开的路径发送邮件,必须再次路由所有排队的邮件。此过程称为重新路由。在重新路由过程中,高级排队引擎丢弃缓存的所有下一跃点信息,因为这些信息不再有效。当前等待传输的每一封邮件都再次被传递到路由引擎,由路由引擎重新计算下一跃点。这可能是一项非常耗费资源的任务。
下图显示了一个重新路由示例,在该示例中,路由组 E 中的桥头服务器的状态为 down。当前没有任何邮件能够到达该路由组。当路由引擎重新计算将邮件传输到路由组 E 中的收件人的最短路径时,发现没有可用的路径。路由过程中,不考虑标记为 down 的连接器。因此,路由组 E 当前处于孤立状态。
由于不存在有效路径,因此路由引擎无法为等待传输到路由组 E 的邮件确定有效的下一跃点。路由引擎通过下一跃点类型信息通知高级排队引擎下一跃点当前不可达。高级排队引擎必须保留邮件,直到至少有一个传输路径可用,或者直到邮件过期,而必须随同 NDR 一起返还给发件人。
注意: |
---|
如果只有一个路由组连接器存在,而没有备用路径,那么链路状态将始终标记为可用,以减少路由拓扑中的链路状态变化次数。Exchange Server 2003 将邮件排队,并在传输路径再次可用时将其发送出去。 |
重新路由和地址空间
与负载平衡一样,Exchange Server 2003 只通过地址空间相同的连接器来重新路由邮件。例如,您可能在不同的桥头服务器上创建了两个独立的连接器,两个连接器地址空间相同但开销不同。如果首选连接器不可用,路由引擎将自动选择第二个连接器,直到主连接器再次可用。
注意: |
---|
路由引擎不会将邮件从地址空间具体的连接器重新路由到地址空间不具体的连接器,因为路由引擎认为这是另一个目标。邮件将保留在源桥头服务器上,直到地址空间具体的连接器可用。 |
如果地址空间为 *.Net 的连接器上存在限制,并且这些限制使得某些邮件无法通过该连接器(例如,由于拒绝发件人通过该连接器传输邮件),那么路由引擎会将邮件随同 NDR 一起返还给发件人。路由引擎不会重新尝试通过第二个连接器来传输这些邮件。将使用地址空间最具体的连接器来传输邮件。计算传输路径的过程中,不会考虑地址空间具体程度较低的连接器。
连接器恢复
如果出现下列任一种情况,路由引擎可确定连接器再次可用:
- VS_NOT_STARTED 路由组主服务器建立了与源桥头服务器上的 TCP 端口 691 的连接。源桥头服务器标记为 CONN_AVAIL,并且由于至少有一个源桥头服务器可用于该连接器而使连接器的状态切换为 STATE UP。
- CONN_NOT_AVAIL 对于不可用的连接器,即使没有等待传输的邮件,桥头服务器也继续每隔 60 秒重试连接。连接建立后,高级排队引擎或 Exchange MTA 报告路由引擎从源桥头服务器建立出站连接成功。之后,路由引擎将源桥头服务器的状态切换为 CONN_AVAIL,而将连接器的状态切换为 STATE UP。
重新路由和激活日程安排
所有类型的连接器都允许您配置连接器日程安排,这样您可以在特定的时间传输电子邮件。可以将连接器配置为始终处于活动状态、在指定的时间处于活动状态,或者从不处于活动状态。在最后一种情况下,除非再次更改连接器日程安排,否则连接器将不会传输邮件。还可以将连接器配置为远程启动。这意味着连接器自己不启动连接,而是等待远程服务器连接到它并触发邮件传输。
连接器日程安排仅影响邮件传输,而不影响邮件路由。对于具有任何日程安排类型的连接器而言,只要其状态为 STATE UP,路由引擎就认为它可用。因此,邮件甚至可能路由到激活日程安排设置为“从不”的连接器。这些连接器的链路状态不会发生变化,并且不会重新路由邮件。邮件将在连接器队列中等待,直到激活日程安排被更改。远程启动的连接器也是如此。邮件在等待检索的过程中,不会被重新路由。
提示: |
---|
如果要避免邮件路由到连接器,应将其最大邮件大小设置为 1 KB。 |