【ArchSummit】如何通过AIOps推动可量化的业务价值增长和效率提升?>>> 了解详情
写点什么

使用 Amazon Route 53 和 AWS Transit Gateway 对混合云进行集中式 DNS 管理

  • 2019-09-25
  • 本文字数:4583 字

    阅读完需:约 15 分钟

使用 Amazon Route 53 和 AWS Transit Gateway 对混合云进行集中式 DNS 管理

成功的混合联网策略不仅仅局限于私有网络连接。它通常需要在 Amazon Virtual Private Cloud (Amazon VPC) 和本地环境中处理独立的内部区域。这种策略需要跨越整个网络的域名系统 (DNS) 命名。通常,这是通过在资源和工作负载所在的相同位置提供名称解析服务来管理的。例如,在本地数据中心 DNS 基础设施(用于响应本地资源的查询)和 Amazon Route 53 私有 DNS 解析器(用于响应 AWS 云中资源的查询)等位置会出现这种情况。要在应用程序所需的这种混合网络上获得 DNS 的统一视图,您可能需要双向查询转发。这使您能够从 Amazon VPC 中查询本地内部区域,并从本地数据中心查询 Route 53 解析器专用 DNS。


AWS 于 2018 年 11 月发布了针对混合云的 Amazon Route 53 Resolver。通过解决诸多 DNS 挑战,这使得迁移到云或使用混合架构更加简单易行。在您第一次规划云迁移之旅时,这些挑战可能并不明显,但它们经常出现在迁移过程当中,因为可能会降低开发人员的开发速度。


许多用户都将基础设施分布在多个账户和多个 Amazon VPC 上,其中每个账户的 VPC 都有多个域(Domain)和私有托管区域 (hosted zones) 。跨账户集成 DNS 或与本地 DNS 服务器,过程会变得很复杂。您需要通过一组统一的规则和单个 Route 53 Resolver,轻松管理多个 VPC 账户中的递归 DNS 行为。现在,您可以通过对所有 VPC 和本地域的 DNS 进行集中管理来实现这一目标。


本博文将介绍在设计集中管理的 DNS 时需要考虑的最佳实践和折衷方案。我们将概括介绍跨多个互连 Amazon VPC 管理 DNS 的建议方法。


适用于本地网络和 Amazon VPC 的 DNS 单一视图


在这种情况下,您拥有本地 DNS 解析器的现有基础设施,这些解析器对于解析本地域名具有权威性。此外,在 AWS 的多个账户中,您还拥有多个 VPC,其中有多个域和专用托管区域与这些 VPC 关联。这些 Amazon VPC 通过 Transit Gateway 使用中心辐射型拓扑进行互连。要在此混合环境中简化 DNS,您可以采用集中管理的 DNS,该 DNS 可以解析本地数据中心与 VPC 之间的 DNS 名称。


Route 53 Resolver 终端节点和转发规则主要用于为混合网络提供集成 DNS,在混合网络中,往往难免要实时转发 DNS 查询。这些新功能允许 Route 53 Resolver 和您的本地 DNS 解析器通过实时向对端转发查询,来解析由对端托管的域。

在 Amazon VPC 之间共享 PrivateLink 终端节点

在此设置中,您要使用 AWS PrivateLink 通过 VPC 和本地服务器的专用连接安全地访问 AWS 服务。您需要接口终端节点,该终端节点可用作流向 AWS PrivateLink 支持的 AWS 服务流量的入口点。您可以在每个 VPC 中配置接口终端节点以访问 AWS 服务,但是,对于在每个可用区中所创建的终端节点,将需按小时付费。为了降低成本并简化管理每个 VPC 中接口终端节点的管理开销,您可以在共享服务 VPC 中启动 PrivateLink 终端节点并与其他 VPC 共享。我们将详细介绍如何跨 VPC 为集中式 PrivateLink 设计最佳 DNS 解析。


随着 Route 53 Resolver 服务的引入,您可以实现以下设计目标:


  1. 您可以使用完全托管的服务,其中 AWS 负责处理为确保可用性和可靠性而需执行的无差别繁重工作。

  2. 该服务确保可用区隔离和可用区本地应答。

  3. 入站和出站终端节点支持在一个终端节点中每个 IP 地址每秒进行 10000 次查询。您只需为转发流量而查询终端节点。

  4. 该服务在 Amazon CloudWatch 中提供查询量指标,允许您设置告警。

  5. 现在,我们来看看 Route 53 Resolver 的一些最佳实践:

  6. 我们建议常规 Amazon EC2 实例应使用 .2 进行 DNS 解析,这样每个网络接口最多可为每个 EC2 实例提供 1024 个数据包/每秒 (pps),并确保可用区隔离。

  7. 您应确保 DHCP 选项设置中的域名服务器指向 AmazonProvidedDNS,而非解析器终端节点。使用转发规则确保 AmazonProvidedDNS 具有您需要的 DNS 视图。

  8. 解析器终端节点在设计上将 Route 53 解析器与本地 DNS 相集成。

  9. DNS 解析几乎对每个应用程序都非常重要,因此我们建议在设计中始终考虑可靠性。但查询转发为实时 DNS 解析增加了额外的复杂性,因此最佳实践是仅在必要时使用此功能。

  10. 虽然可以使用转发规则来解析其他 VPC 中的专用托管区域,但我们不建议这样做。最可靠、高性能且低成本的方法,是将专用托管区域直接共享和关联到需要它们的所有 VPC。


我们来深入探讨一些使用 Route 53 解析器集中管理 DNS 的设计设置和配置示例。

适用于本地网络和 Amazon VPC 的 DNS 单一视图

在此设置中,您希望在多个账户查询 Route 53 私用托管区域解析,并在本地环境中查询 VPC。在此设计设置中,您将使用共享服务 VPC 来做到这一点。同时,您还希望有条件地将本地域的查询从 VPC 转发到本地 DNS 解析器。这些 VPC 使用中心辐射型拓扑进行互连。每个辐射型 VPC 属于一个不同的账户,并且它们由其各自的账户管理。


如前所述,当需要在多个 VPC 和 AWS 账户中解析 Route 53 私用托管区域时,最可靠的模式是在账户之间共享专用托管区域并将其关联到需要它的每个 VPC。尽管可以使用 Route 53 Resolver 转发来解决此用例,但这会带来额外的成本以及可用区之间可能的依赖性和复杂性,而直接关联区域(Zones)可以避免这些问题。


下图显示了此设置的架构。



要创建此设置,请按照以下概括性步骤操作。


1.建立网络 IP 连接。


  • 使用 AWS Transit Gateway 建立从辐射型 VPC 到共享服务 VPC 的网络连接。

  • 使用 AWS Direct Connect 或 AWS Site-to-Site VPN 建立与本地服务器的连接。


2.配置 Route 53 Resolver 终端节点。


  • 创建入站终端节点。我们建议您在至少两个可用区中指定 IP 地址,以便在共享服务 VPC 中实现高可用性。

  • 创建出站终端节点。我们建议您在至少两个可用区中指定 IP 地址,以便在共享服务 VPC 中实现高可用性。


3.创建私用托管区域。


  • 在共享服务 VPC 中创建 Route 53 私用托管区域并关联它们。此外,由于辐射型 VPC 位于不同账户中,因此要完成辐射型 VPC 的跨账户专用托管区域-VPC 关联。如果需要,所有 VPC 都需要将其私用托管区域与所有其他 VPC 相关联。


4.创建转发规则。


  • 创建条件转发规则,指定要转发到本地 DNS 解析器的 DNS 查询的本地域名。

  • 示例:域名为“onprem.mydc.com”的规则将导致转发 onprem.mydc.com 和子域的所有查询。

  • 为出站流量配置规则时,请将使用此规则的 VPC 设置为共享服务。

  • 如果辐射型 VPC 与共享服务 VPC 位于同一账户中,可以在创建出站规则时选择多个 VPC 作为使用此规则的 VPC,也可以在创建后将 VPC 与规则关联。


5.与其他 AWS 账户共享转发规则并使用共享规则。


  • 在此设置中,辐射型 VPC 跨越不同的账户,您可以通过 AWS Resource Access Manager (AWS RAM) 在其他使用共享规则的 AWS 账户中与 VPC 共享转发规则。以下屏幕截图显示了如何使用 AWS RAM 为多个账户转发与 VPC 共享的解析器规则:


在 VPC 之间共享 PrivateLink 终端节点

以下设置通常是前面描述的 DNS 单一视图的补充。在此设置中,您希望集中 PrivateLink 以在共享服务 VPC 中安全地访问 AWS 服务。您希望从其他辐射型 VPC 和本地服务器连接到共享服务 VPC 中的 PrivateLink 终端节点,因此需要 DNS 解析才能实现。


所有辐射型 VPC 都属于不同的账户,并且它们由其各自的账户所有者管理。


接口终端节点私有 DNS


在创建接口终端节点时,您会收到特定于终端节点的区域 DNS 主机名,该主机名的名称中包含唯一的终端节点标识符、服务标识符、区域(Region)和 vpce.amazonaws.com。例如,vpce-12345678-abcdefg.sqs.us-east-1.vpce.amazonaws.com。此名称解析为共享服务 VPC 中终端节点的 IP 地址。此服务的默认 DNS 主机名是 sqs.us-east-1.amazonaws.com。解析此 DNS 主机名会产生公共 IP 地址。


为接口终端节点启用专用 DNS 会创建专用托管区域,以便将默认名称 (sqs.us-east-1.amazonaws.com) 解析为终端节点 IP 地址。但是,现在这只适用于终端节点所在的 VPC。其他 VPC 会继续解析公有 IP 地址。以下步骤描述了如何确保所有 VPC 和本地服务器解析专用终端节点 IP 地址。


下图显示了此设置的架构,说明了 PrivateLink 终端节点如何访问某些 AWS 服务,例如 Amazon ECS、Amazon SNS 和 Amazon SQS。这可以扩展到 PrivateLink 支持的其他 AWS 服务。


要创建此设置,请按照以下步骤操作。



1.建立网络 IP 连接。


  • 使用 AWS Transit Gateway 建立从辐射型 VPC 到共享服务 VPC 的网络连接。

  • 使用 AWS Direct Connect 或 AWS Site-to-Site VPN 建立与本地服务器的连接。


2.配置 Route 53 解析器终端节点。


  • 创建入站终端节点。我们建议您在至少两个可用区中指定 IP 地址,以便在共享服务 VPC 中实现高可用性。


3.创建 PrivateLink 终端节点。


  • 为 AWS 服务创建接口终端节点,不启用“ Enable Private DNS Name”选项。


4.创建私用托管区域。


如果要从辐射型 VPC 和本地服务器访问共享服务 VPC 中的接口终端节点 sqs.us-east-1.amazonaws.com,请执行以下操作:


a.创建与共享服务 VPC 关联的名为 sqs.us-east-1.amazonaws.com 的 Route 53 私用托管区域。


b.创建名为 sqs.us-east-1.amazonaws.com 的别名记录,该记录针对特定于终端节点的区域 DNS 主机名 (vpce-12345678-abcdefg.sqs.us-east-1.vpce.amazonaws.com)。



  • 完成与辐射型 VPC 的跨账户专用托管区域 VPC 关联。

重要注意因素

上面的设置为 PrivateLink 提供了集中 DNS 管理的解决方案,但不一定能解决 Amazon Elastic File System (Amazon EFS) 等 AWS 服务方面的问题,该服务依赖于特定于可用区的应答,目前无法创建别名记录。


虽然您可以通过出站终端节点为跨账户的 Amazon EFS 域名创建转发规则,但客户端将不会收到针对其可用区优化的应答。这可能会导致跨可用区的联网费用、更高的操作延迟和更低的耐用性。我们建议仅使用此技术转发可用区特定的 EFS 域名,要特别注意每个客户端使用特定于其可用区的 DNS 条目来挂载 EFS。


如果要跨账户挂载,请注意可用区名称(例如 us-east-1a)在各个账户之间可能各不相同。您可能需要将可用区名称映射到可用区 ID。这是可用区的唯一且一致的标识符,可确保建立正确的连接。例如,use1-az1 是 us-east-1 区域的可用区 ID,它在每个 AWS 账户中具有相同的位置。Route 53 解析器终端节点专为混合 DNS 设置而设计,它们不是针对 Amazon EFS 这样的用例构建的。

小结

在这篇博文中,我向您介绍了为混合云设计集中式管理的 DNS 时可以使用的一些设置。您可以使用 Amazon Route 53 和 AWS Transit Gateway 通过统一的规则集和 Route 53 解析器跨多个账户和本地域的 VPC 进行解析。如果您有任何问题或反馈,请给我们留言。


相关文章:


https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-dns-management-of-hybrid-cloud-with-amazon-route-53-and-aws-transit-gateway/


作者介绍:


Bhavin Desai


Bhavin Desai 是 AWS 的高级解决方案架构师。他乐于为客户提供技术指导,并帮助他们构建和生成解决方案,以利用 AWS 实现无限可能。


本篇译者


刘春华


AWS 解决方案架构师,AWS 的云计算方案架构的咨询和设计,同时致力于 AWS 云服务在国内和全球的应用和推广,在大规模并发应用架构、无服务器架构,人工智能与安全等方面有丰富的实践经验。 曾任 IBM 云架构师,对企业应用迁移到云及应用系统改造有深入的研究。


本文转载自 AWS 技术博客。


原文链接:


https://amazonaws-china.com/cn/blogs/china/use-amazon-route-53-and-aws-transit-gateway-dns-management/


2019-09-25 17:57819
用户头像

发布了 1832 篇内容, 共 91.2 次阅读, 收获喜欢 73 次。

关注

评论

发布
暂无评论
发现更多内容

阿里云中间件开源往事

阿里巴巴中间件

阿里云 开源 中间件

企业中台建设新路径——低代码平台

力软低代码开发平台

Web开发小妙招:巧用ThreadLocal规避层层传值

华为云开发者联盟

Java 前端 web开发

1500万员工轻松管理,云原生数据库GaussDB让HR办公更高效

华为云开发者联盟

数据库 后端

张平安:加快云上数字创新,共建产业智慧生态

华为云开发者联盟

云计算 后端 SaaS 华为云

SchedulX V1.4.0及SaaS版发布,免费体验降本增效高级功能!

星汉未来

DevOps 运维 k8s IT FinOps

阿里云易立:云原生如何破解企业降本提效难题?

阿里巴巴中间件

阿里云 架构 云原生

用头像模仿天狗食月

急需上岸的小谢

7月月更

云原生混部最后一道防线:节点水位线设计

阿里巴巴中间件

阿里云 云原生 中间件 混部

小程序能运行在自有App中,且实现直播和连麦?

Speedoooo

小程序 直播 移动开发 小程序容器 连麦

【刷题记录】2. 两数相加

WangNing

7月月更

【写给初发论文的人】撰写综述性科技论文常见问题

左手の明天

论文阅读 论文 论文写作 研究论文 论文撰写

Linux 下的传统 IPC 通信原理

北洋

Andriod 7月月更

leetcode 53. Maximum Subarray 最大子数组和(中等)

okokabcd

LeetCode 动态规划 数据结构与算法

架构实战营模块 6 作业

Roy

架构实战营

offer如何选择该考虑哪些因素

KEY.L

7月月更

企业数字化转型,低代码是“趋势”还是“陷阱”?

云智慧AIOps社区

大前端 低代码 云开发

枚举通用接口&枚举使用规范

靠谱的程序员

枚举 企业应用 企业级应用

抖音或将推出独立种草社区平台:会不会成为第二个小红书

石头IT视角

“去虚向实”大潮下,百度智能云向实而生

科技新知

从解析HTML开始,破解页面渲染时间长难题

华为云开发者联盟

html 前端 web开发 网页

牛客java选择题每日打卡Day8

京与旧铺

7月月更

解密函数计算异步任务能力之「任务的状态及生命周期管理」

阿里巴巴中间件

阿里云 中间件 异步 函数计算

HAVE FUN | “飞船计划”活动最新进展

SOFAStack

微服务架构 开源软件 新手引导

当 Knative 遇见 WebAssembly

阿里巴巴中间件

阿里云 容器 云原生 Knative WebAssenbly

java零基础入门-Scanner类

喵手

Java’ 7月月更

Flutter3.0了,小程序不止于移动应用跨端运行

Speedoooo

flutter 小程序 移动开发 小程序容器 跨端运行

华为小米互“抄作业”

科技新知

组织实战攻防演练的5个阶段

穿过生命散发芬芳

攻防演练 7月月更

ServiceMesh主要解决的三大痛点

阿泽🧸

Service Mesh 7月月更

从0开始创建小程序

小恺

7月月更

使用 Amazon Route 53 和 AWS Transit Gateway 对混合云进行集中式 DNS 管理_语言 & 开发_亚马逊云科技 (Amazon Web Services)_InfoQ精选文章