UCloud物理云网关百G级集群设计实践

物理云主机是UCloud提供的专用物理服务器，具有出色的计算性能，知足核心应用场景对高性能及稳定性的需求，也能和其它产品灵活搭配。物理云网关用于承载物理云和公有云各产品间的内网通讯，因为用户有多地部署的必要，网关集群面临跨地域跨集群的流量压力。

咱们用多隧道流量打散等手段解决了Hash极化形成的流量过载问题，并经过容量管理和隔离区无损迁移限制大象流。新方案上线后，集群从承载几十G升级为可承载上百G流量，帮助达达等用户平稳度过双十一的流量高峰。如下是实践经验分享。一

1、流量过载的物理云

为了保证云上业务的高可用性，用户一般会将业务部署在不一样地域。此时用户的物理云便须要经过物理云网关相互访问，不可避免地，物理云网关会承载大量物理云主机的跨集群访问流量。

与此同时，为了保证不一样用户之间网络流量的隔离和机房内部的任意互访，物理云网关会对用户报文封装隧道，而后发送至接收方。

一、问题出现：Hash极化与过载的物理云

以下图，咱们发现物理云集群2中网关设备e的带宽过载，影响了访问集群2的全部业务。经过监控进一步查看到，集群2的流量分布很不均匀，集群中部分设备带宽被打爆，可是剩余的设备流量却很小。经过抓包分析，网关设备e的流量几乎所有来自于物理云集群1。

图：跨集群访问时封装隧道示意

结合业务分析，肯定物理云过载的缘由在于：物理云集群1和集群2之间的互访流量出现了Hash极化，致使流量分布不均。

那什么是Hash极化呢？

因为集群之间使用单条隧道传输，隧道封装隐藏了用户的原始信息，例如IP、MAC等，对外只呈现隧道信息，同时隧道采用了惟一的SIP和DIP。那么Hash算法相同，算出的结果一致，致使流量没法作到很好的负载分担，便会使集群的单台设备负载突增，极端状况下就会出现被打爆的现象，进而影响该集群下的全部用户，这就是Hash极化，常出现于跨设备的屡次Hash场景。

根据现状，咱们分别尝试从如下两个角度解决该问题：

① 若是用户流量能够打散，如何避免封装隧道后的Hash极化？

② 若是用户流量没法打散，又该如何防止“大象流”打爆物理云网络？

下面，咱们分别从这两点出发研究对应的解决方案。

二、如何避免封装隧道后的Hash极化？

针对这个问题，起初咱们提出了多个解决方案：

① 方案1：用户流量由交换机轮询发送到集群每台设备。这种方法的优势在于流量能够充分打散，不会出现Hash极化现象。但同时缺点在于网络报文的时序被打乱，可能影响用户业务。

② 方案2：交换机基于隧道内层报文Hash。该方法基于用户的报文打散，优势在于能够较为均衡地打散在集群不一样设备上。但问题在于用户报文封装隧道后会再次分片，将致使内层报文信息缺失和分片报文Hash到不一样设备上。

③ 方案3：为集群每台设备分配单独的隧道源IP。该方法能够实现有效的流量打散，但因为隧道数量有限，Hash不均的问题在现网实际表现依旧明显。

以上三个方法均不一样程度地存在缺点，不能彻底解决Hash极化问题。经过一系列的研究，最终咱们找到了一种多隧道解决方案。即打破网关的单隧道模式，全部的网关绑定一个网段的隧道IP，基于用户的内层报文信息Hash，并在预先分配的网段中选择隧道的SIP和DIP，保证不一样流量尽量分布在不一样的隧道，从而将用户流量打散。

图：多隧道解决方案示意

三、如何防止“大象流”打爆物理云网络？

多隧道方案的前提在于用户流量能够被打散，可是若是遇到“大象流”呢？即使是多个隧道也没法将避免被打爆的状况。面对用户的“大象流”，单靠技术手段还不够，咱们同时也须要从硬件配置方面作好事前预防和规避。

■ 单机容量管理

首先须要对物理云网关进行合理的容量管理，保证网关可承载带宽高于用户物理云主机的带宽，同时保证整集群的承载能力知足用户需求。

图：示例-将单机容量从10G调整为25G

这一点其实与云厂商自身的能力密切相关，目前UCloud网关集群单机的承受能力远远大于单个用户的流量，在承载多用户汇聚流量的状况下，仍能保证个别用户的突发“大象流”不会打爆网关。

■ 隔离区无损迁移

提高单机容量还远远不够，以防万一，UCloud还配备了隔离区，隔离区一般是无流量经过的。

图：隔离区无损迁移

如上图，一旦监测到流量过大，存在集群被打爆的风险时，集群配套的自动迁移系统便会修改须要迁移的物理机数据库信息，并自动更新对应转发规则，部分业务流量即可经过隔离区分担出去。同时咱们还会基于强校验技术对迁移结果进行自动验证，保证迁移业务的无损可靠。

四、实例：新旧方案下的用户应用对比

在新方案上线前，因为Hash极化现象，集群一般只能承载几十G的流量，而且不时出现过载的状态。

新方案上线后，以下监控图，能够看到流量基本在集群上打散，集群的优点获得了充分发挥，目前集群能够承载上百G的流量，充分抵御用户业务量突增时的风险。例如达达在双十一时60G的流量压力是广泛现象，突发时还会出现流量达到100G的状况，此时集群流量依旧转发正常，对业务毫无影响。

图：流量监控图示意

除了提高性能，此次集群升级中对高可用设计也作了优化。

2、集群升级后的高可用性优化

针对集群升级，通常状况下会先部署新灰度集群，而后将用户业务逐步进行迁移。这样的好处在于能够在新集群版本存在缺陷的状况下，最大限度的控制影响范围，当出现故障时，能够及时回迁受影响的用户业务到老集群，避免用户业务受到影响。

图：预期结果-新Manager接管灰度集群

在灰度过程当中，曾发现一个问题。

在新集群Manager部署完毕后，因为配置错误致使灰度集群接管了旧集群，Manager基于配置文件的集群信息自动接管集群的控制，并直接下发配置信息，旧集群接受错误配置。因为旧集群和新集群配置差别较大，致使旧集群在解释新配置时有误，出现高可用异常。

图：灰度Manager错误接管旧集群示意

一、风险分析

为了系统性避免这类问题，咱们对配置过程进行了回溯分析，总结了存在的风险：

① 部署人为干预多，会加大故障几率；

② 程序的异常保护不够；

③ 集群之间的有效隔离不足，若故障影响范围大。

二、优化：自动化运维&程序优化&隔离影响

■ 自动化运维

自动运维化经过自动化代替人工操做，能够有效避免人为错误的发生。咱们对集群部署流程进行了优化，将其分为配置入库和部署两个流程，运维人员只需录入必要的配置信息，其他均经过自动化生成部署。

■ 完善校验和告警

此外，咱们还对部分程序做了优化，加大对异常配置的校验。例如，配置加载前，首先需进行白名单过滤，若是发现配置异常则终止配置加载，并进行告警通知后续人工介入。

图：白名单限制程序，只容许正确的控制面同步配置

■ 隔离影响

最后，无论自动化运维机制和程序自身多精密，总要假设异常的可能。在此前提下，还须要考虑在故障发生时如何最大程度地减小影响范围和影响时间。咱们的解决思路以下：

► 去除公共依赖

前次问题主要缘于集群全部设备同时依赖了异常的Manager，致使一损俱损。所以须要去除集群设备中的公共依赖，缩减影响范围。例如不一样的集群绑定不一样Manager，这样能够有效控制影响范围。固然集群的公共依赖不只仅可能出如今Manager，也多是一个IP、一个机架等，这就须要咱们在实际项目中仔细甄别。

► 设置隔离区在影响范围可控的状况下，一个Manager异常只会影响集群中的部分设备，在该状况下还应该迅速剔除异常设备或者直接迁移该集群下的全部用户到隔离区，争取最快时间排除故障。

总结

随着技术的发展和业务的扩张，系统架构愈加复杂、关联度愈加紧密，对技术人员的要求也愈来愈高。在物理云网关集群的开发过程当中，不可避免会遇到不少“坑”，可是不管什么时候都需秉承一点：一切技术都是为了业务服务。为此，咱们把方案设计的经验分享出来，但愿可以给予你们更多思考与收获。