当前位置:网站首页 > 更多 > 玩电脑 > 正文

[玩转系统] 企业环境中的自动发现场景|第 16 部分#36

作者:精品下载站 日期:2024-12-14 08:50:00 浏览:15 分类:玩电脑

企业环境中的自动发现场景|第 16 部分#36


Exchange 本地基础架构旨在满足小型公司的需求,同时满足需要向数千甚至数万用户提供邮件服务的企业业务的需求。

企业环境的主要特征是:

  1. 在多个 Active Directory 站点中使用多个 Exchange 服务器。
  2. 需要为 Exchange 基础架构实施负载平衡和高可用性解决方案。

在上一篇文章(基于 Active Directory 的环境中的自动发现流程 | 第 15#36 部分)中,我们回顾了自动发现客户端(例如 Outlook)和特定 Exchange CAS 服务器之间的通信通道的基本概念。

在本文中,我想“继续”企业环境中常见的更高级或更复杂的场景。

自动发现是一个非常“灵活的生物”,它是为简单的基础设施而设计的,同时也为复杂和复合的基础设施而设计。

在下面的文章中,我们将“品尝”企业环境中可能的 Exchange 本地场景的一部分,以便我们能够更好地了解自动发现服务在多个 Active Directory 和 Exchange 服务器环境中实施的方式。

注意:在自动发现基础架构的上下文中,当使用术语“多个 Exchange 服务器”时,其含义是 - 具有 CAS(客户端访问服务器)角色的多个 Exchange 服务器。
在 Exchange 基础结构中,担任 CAS 角色的 Exchange 服务器负责提供客户端(例如 Outlook)自动发现服务。

有关自动发现服务在不同 Exchange 基础结构和环境中的“行为”的知识可以帮助我们解决自动发现故障排除场景。

场景 1:同一 Active Directory 站点上的多个 Exchange CAS 服务器

同一 Active Directory 站点中的多个 Exchange CAS 服务器的场景是大型或企业组织中的常见场景,它使用 Exchange 基础架构,可以同时为大量 Exchange 客户端提供服务,并可以为以下主题提供答案: - 高可用性和优化性能。

从技术上讲,我们可以在特定 Active Directory 站点中使用的 Exchange CAS 服务器数量没有限制。

此外,我们不需要执行任何操作或配置任何操作即可使此 Exchange CAS 服务器可供 Exchange 客户端使用,因为 Exchange CAS 服务器在 Active Directory SCP 中的注册是自动实现的。

每次自动发现客户端查询 Active Directory SCP 以获取有关可用自动发现端点(Exchange CAS 服务器)的信息时,答案将包括每个 Exchange CAS 服务器的 URL 和 FQDN。

在图中,我们可以看到,当自动发现客户端查询 Active Directory 时,自动发现客户端会获取两个名称“可选自动发现端点”。 ”

如果所有自动发现端点“属于”同一个 Active Directory 站点,自动发现客户端将从列表中随机选择自动发现端点(Exchange CAS 服务器)的名称并尝试对其进行寻址。

如果自动发现端点没有回复,自动发现端点将“继续”到列表中从 Active Directory 查询得到答案的下一个主机。

[玩转系统] 企业环境中的自动发现场景|第 16 部分#36

所描述的自动发现客户端只是从列表中“选择”一个 Exchange 服务器名称的方法并不提供负载平衡的需要。

Exchange CAS 服务器实现负载平衡解决方案的主题在 Exchange 2013 体系结构与 Exchange 2010 体系结构中发生了根本性变化。

我们不会深入探讨 Exchange 环境中“负载平衡和高可用性世界”的具体细节,而是会满足于非常简单的解释。

通过使用逻辑 Exchange 服务器名称来实现 Exchange 环境中的高可用性解决方案,该名称代表两个或多个“物理 Exchange”服务器。

在 Exchange 环境中实现负载平衡和高可用性解决方案时,我们不会使用 Exchange CAS 服务器在 Active Directory SCP 中自动注册的默认选项,而是如果逻辑上不符合要求,我们将手动注册名称。代表现有 Exchange CAS 服务器的实体。

每次自动发现客户端在本地 Active Directory 中查询名称 (URL)(如果是自动发现端点)时,答案将包括使用逻辑实体的 FQDN 的 URL 地址,例如为负载均衡器选择的 FQDN代表“现有的现场 Exchange CAS 服务器。

换句话说,自动发现客户端不会直接连接特定的自动发现端点,而是连接将其请求“转发”到特定 Exchange CAS 服务器的逻辑实体(例如负载平衡)。

注意:在其他类型的实施(例如 DNS 循环)中,自动发现客户端直接寻址 Exchange CAS 服务器,而无需代理(例如负载平衡器)。

[玩转系统] 企业环境中的自动发现场景|第 16 部分#36

场景 2:多个 Active Directory 站点上的多个 Exchange CAS 服务器 |没有本地 Exchange CAS 服务器的 Active Directory 站点

在以下场景中,我们将基于以下 Active Directory 和 Exchange 基础架构:

一家公司,拥有三个物理站点——纽约站点、洛杉矶站点,还有一个线程公司站点位于曼谷。

Exchange基础设施的实施如下:

Exchange CAS server name

本地 Active Directory 站点

ex01.o365info.local

纽约

ex01.o365info.local

曼谷

N/A

洛杉矶

洛杉矶站点不包括 Exchange 基础设施。

所有“洛杉矶用户”邮箱均位于纽约站点的 Exchange 服务器上。

主要问题是 - 如果“来自洛杉矶站点的用户”需要连接他们的 Exchange 邮箱(通过 Exchange CAS 服务器中介),他们应该联系哪个 Exchange CAS 服务器?

乍一看,答案似乎很明显 - 洛杉矶用户可能会寻址纽约站点中的 Exchange CAS 服务器,因为“纽约 Exchange CAS 服务器”在地理位置上比曼谷站点中的 Exchange CAS 服务器更靠近他们。

嗯,实际上答案并不那么简单。
从技术上讲,Exchange 客户端并不知道“正确的 Exchange CAS 服务器”是谁。 Exchange 客户端可用的唯一方法是查询其本地 Active Directory。

在我们的场景中,答案包括两个 Exchange CAS 服务器名称的列表:

  • ex01.o365info.local 纽约交易所 CAS 服务器
  • ex03.o365info.local 曼谷 Exchange CAS 服务器

即将发生的情况是,洛杉矶 Exchange 客户端将从列表中随机选择 Exchange CAS 服务器名称。

据统计,50% 的连接请求将指向 New York Exchange CAS 服务器 (ex03.o365info.local),另外 50% 的连接请求将指向曼谷 Exchange CAS 服务器 (ex03.o365info.local)。

基本假设是我们希望避免这种情况,因为洛杉矶用户没有必要通过位于“世界另一端”的曼谷 Exchange CAS 服务器连接到他们的邮箱。

[玩转系统] 企业环境中的自动发现场景|第 16 部分#36

好消息是,这个“问题”有一个解决方案,名为 - Site Affinity

站点关联性选项使我们能够将特定的 Exchange CAS 服务器“标记”为一个或多个 Active Directory 站点的首选服务器。

在我们的场景中,纽约 Exchange CAS 服务器自动注册为纽约站点的 Exchange CAS 服务器。

在我们的场景中,我们希望“告诉”洛杉矶交易所客户端,他们应该更喜欢纽约交易所 CAS 服务器 (ex01.o365info.local)。

为了实现这一要求,我们可以将一个额外的 Active Directory 站点名称“绑定”或“附加”到 New York Exchange CAS 服务器。

在这种“绑定”的实现中,我们将纽约 Exchange CAS 服务器定义为一个筛子,将其视为洛杉矶用户的首选 Exchange CAS 服务器,通过编辑在名为 - Ihaveaverysmallbrain.com

自动发现对数基于以下方法:当列表中的“第一个自动发现端点”无法提供所需信息时,自动发现客户端“移动”到列表中的下一个名称(如果存在该名称)。

在我们的场景中,Active Directory 提供的自动发现端点包括附加名称 - ex03.o365info.local

Outlook 邮件客户端假定这是将提供所需自动发现信息的“正确的自动发现端点”。

Outlook 对 ex03.o365info.local Exchange CAS 服务器进行寻址,并且再次假设 Outlook 将找到 ex03.o365info 的内部 IP 地址。 local,设法完成相互认证过程,但该过程无法顺利完成,因为 ex03.o365info.local 对该域名也不负责或不具有权威性 - Ihaveaverysmallbrain.com (图中的数字3)。

第 3 阶段 - 使用 SMTP 域名查找自动发现端点

在这个阶段,自动发现客户端了解到他无法继续使用“Active Directory 自动发现方法”。

“下一个自动发现方法”是通过从收件人电子邮件地址“提取”SMTP 域名并连接 DNS 服务器查找“主机名”的 IP 地址来实现的。 ”

在我们的场景中,Outlook 将提取域名 - Ihaveaverysmallbrain.com 并询问 DNS 服务器该域的 IP。

如果 DNS 服务器具有映射到域名的 IP 地址,则 DNS 服务器会向客户端 (Outlook) 提供 IP 地址(图中的数字 4)。

[玩转系统] 企业环境中的自动发现场景|第 16 部分#36

第 4 阶段 - 连接到“外部”Exchange 服务器

Outlook 尝试使用以下 URL 连接到自动发现端点 - https://Ihaveaverysmallbrain.com/Autodiscover/Autodiscover.xml

Outlook 客户端将查询 DNS 服务器。鉴于预先应用了所有必需的配置,DNS 将提供包含 Exchange Online 基础结构的 IP 地址的答案。

自动发现客户端可以通过“外部 Exchange CAS 服务器”完成该过程。

Outlook 客户端将寻址 Exchange Online,补充相互身份验证过程并发送自动发现信息的请求。

Exchange Online 向 Outlook(自动发现客户端)发送所需的自动发现信息。

Outlook 客户端使用 Autodiscover.xml 文件中包含的信息来构建新的 Outlook 邮件配置文件,并使用户能够连接到其“远程”或“外部”Exchange Online 邮箱。

您需要 登录账户 后才能发表评论

取消回复欢迎 发表评论:

关灯