火山引擎云调度 GTM“同城容灾”与“异地多活”实践

随着企业不断推进数字化进程，高并发业务和海量数据的挑战也随之而来。在现实生活中，除了地震、台风、挖光纤这种小概率事件，还有很多人为造成的高概率数据丢失事件，比如人为操作失误、硬件故障、网络攻击等等，故障容灾能力的重要性也因此逐渐凸显出来。根据地理位置的不同，灾备方案往往分为同城和异地，今天重点介绍的就是 GTM 在互联网服务“同城容灾”和“异地多活”场景下的实践应用。

本文带你了解火山引擎边缘云 TrafficRoute DNS 套件——云调度 GTM，它是火山引擎 TrafficRoute 解析调度套件中的全局流量管理服务，基于 DNS 进行流量管理。如果你的业务需要就近接入、负载均衡、流量调度和故障容灾能力，那么火山引擎云调度 GTM 可以帮助到你。

云调度 GTM

对照以下表格，我们先来理解 GTM 的基本能力，再看这些能力在实现过程中如何应对不同的调度和故障场景。

互联网服务的“同城容灾”

当用户服务部署在同一个区域的多个机房时，如公有云的 XX 云在华东某个城市包含两个可用区机房 1/机房 2，一旦其中某个机房发生故障，将基于预案进行自动或手动故障转移，确保服务不中断或快速恢复。

同城容灾有以下 3 种参考模式：

• 冷备：同区域的 2 个机房采用“主-备”模式，即主机房平时承载流量，备机房不承载流量，当主机房故障时，流量迁移到备机房。该模式部署简单，但有两个缺点：第一是平常状态下的资源浪费；第二是主机房故障时，由于平时没有流量，备机房的后端配置、容量、各系统状态等是否“Ready”是不可知的。

• 热备：同区域的两个机房采用“主-备”模式，主机房平时承载主要流量，备机房承载少量流量，这部分流量用来验证备机房的功能是否可用。这个模式解决了故障发生时备机房没有准备好的问题，但还是无法解决常态下一半资源的浪费和备用机房有可能出现容量不足的问题。

• 双活：同区域的两个机房在常态下同时进行工作，当一个机房故障时，流量切换到另一个机房。由于常态下的同时工作，所以不存在是否“Ready”的问题，只需要关注故障时另一个机房能否承载流量即可。这个模式下，同一个区域多个机房也是可行的，冗余会更高，对非故障机房承载故障机房流量时，要保留“剩余容量”的要求就更低了，当然多个机房也可能带来数据/配置一致性等问题。

适用场景

同城容灾适用于距离较近的场景，包括同城多个机房、几个相邻的自建机房通过流量转发组成“同城/区域”等情况，支持通过主备（冷、热备）、双活（多活）等模式实现同城情况下的容灾，典型例子就是公有云同城内部的若干机房之间的容灾。

注：上述“冷备”，“热备”等名词定义并不严谨，文内只为解释不同模式之间的区别。

参考架构

架构图中，将公有云的 Region 替换成“同城”，AZ 换成普通机房也同样适用。这种情况下，机房入口（例如一个 Region）使用一个负载均衡的 CNAME 标记集群是可以的，同时集群内部，如多个 AZ 之间也支持流量相互转发，负载均衡层面对用户会屏蔽 AZ 的细节。

优势介绍

• 低成本：建设成本低、架构入侵小、适配性强；配置和管理简单；确保多 IDC 环境下服务不中断或者快速恢复；

• 按需选择：可根据需要实现“冷备”、“热备” 和 “双活（多活）”；

• 灵活配置：支持健康检查和自动容灾，也支持手动模式和多个预案的配置（结合在多个 PoolSet 间切换）；

• 方便管理：便于进行流量灰度和 AB 测试、流量机房间迁移等。

方案实践

互联网服务的“异地多活”

在同城容灾的基础上，流量的调度容灾可以扩展到更大的范围。为了在性能、冗余（数据备份）和容灾上有更多的余地，全国/全球性的互联网服务通常采用多中心场景，包含多云、混合云，这要求我们不仅要做到同城一个机房/单个 AZ 故障时的容灾，也要做到多个地域部署服务时，地域级别故障下的异地灾备，确保服务的连续工作。当然，这需要解决多个地区、机房之间的流量均衡问题，确保每个机房的水位安全。

这就涉及到了异地灾备方案，由于异地的 IDC 转发延时较同城大，Region 间的流量转发通常存在性能、成本等问题，可以通过做异地多活架构来替代流量转发，多个公有云的 Region 大体属于此类情况。

由于异地多活是一个相对复杂的话题，例如如何保持数据的一致性等，所以我们更关注从公网流量角度出发，进行容灾“多活”的举措。

适用场景

机房位于全国/全球多个位置，需要实现按地区的流量调度/均衡、跨地区的备份和流量灾备。例如，公有云多个区域之间的“多活”，或者距离较远的几个自建核心机房之间的灾备和服务多活。

参考架构

上图是参考架构示意图，更关注外部流量的容灾方案。机房内部服务有多种选择，VM、容器、微服务等，而 DB、MQ、缓存等的异地容灾也应该单独考虑。

优势介绍

• 部署简单：建设成本低、架构入侵小、适配性强；配置和管理简单；同时具备区域内多个机房（AZ）和跨区域的容灾能力；AZ 故障时由 LB 进行同 Region 其他 AZ 转发，可以实现大家常说的“两地三中心”+“同城容灾/异地多活”；

• 多种模式：支持健康检查、自动容灾和手动模式，手动模式便于配置多个供选择的容灾预案；

• 多区可用：适用于多机房、多 Region 流量均衡、灰度和 AB 测试；

• 统一管理：可实现多地区、多机房、运营商、IP 流量的统一管理和调度。

方案实践

写在最后

完善的灾备方案在保证业务的持续性上不可或缺，火山引擎云调度 GTM 基于解析进行流量调度，可以实现流量的就近接入（地理位置/性能）、负载均衡 。GTM 借助分布式、多协议健康检查能力来实现故障容灾（Failover），诸如上文说到的“同城容灾”、“异地多活”等场景。此外 GTM 还提供了多云环境下的流量编排、资源粘合能力，可视化的健康检查数据分析、操作日志等功能帮助排查定位问题，便于日常运维。

当前，TrafficRoute DNS 套件下的各个产品，包括云调度 GTM、私网解析 PrivateZone、移动解析 HTTPDNS 和公共解析 PublicDNS，服务了抖音，头条，飞书和火山引擎 ALB、CDN、动态加速、存储等各类 APP 和云产品，具备重要产品稳定服务的能力，在技术、成本、性能和产品成熟度方面拥有深厚积累。

TrafficRoute DNS 套件已正式上线火山引擎官网，欢迎点击【阅读原文】，了解更多 TrafficRoute DNS 套件相关信息。

关于火山引擎边缘云：

火山引擎边缘云，以云原生技术为基础底座，融合异构算力和边缘网络，构建在大规模边缘基础设施之上的云计算服务，形成以边缘位置的计算、网络、存储、安全、智能为核心能力的新一代分布式云计算解决方案。