物理云主机是UCloud提供的专用物理服务器，具备出色的计算性能，满足核心应用场景对高性能及稳定性的需求，也能和其它产品灵活搭配。物理云网关用于承载物理云和公有云各产品间的内网通信，由于用户有多地部署的必要，网关集群面临跨地域跨集群的流量压力。
我们用多隧道流量打散等手段解决了Hash极化造成的流量过载问题，并通过容量管理和隔离区无损迁移限制大象流。新方案上线后，集群从承载几十G升级为可承载上百G流量，帮助达达等用户平稳度过双十一的流量高峰。以下是实践经验分享。一
一、流量过载的物理云
为了保证云上业务的高可用性，用户通常会将业务部署在不同地域。此时用户的物理云便需要通过物理云网关相互访问，不可避免地，物理云网关会承载大量物理云主机的跨集群访问流量。
与此同时，为了保证不同用户之间网络流量的隔离和机房内部的任意互访，物理云网关会对用户报文封装隧道，然后发送至接收方。
1、问题出现：Hash极化与过载的物理云
如下图，我们发现物理云集群2中网关设备e的带宽过载，影响了访问集群2的所有业务。通过监控进一步查看到，集群2的流量分布很不均匀，集群中部分设备带宽被打爆，但是剩余的设备流量却很小。通过抓包分析，网关设备e的流量几乎全部来自于物理云集群1。
图：跨集群访问时封装隧道示意
结合业务分析，确定物理云过载的原因在于：物理云集群1和集群2之间的互访流量出现了Hash极化，导致流量分布不均。
那什么是Hash极化呢？
由于集群之间使用单条隧道传输，隧道封装隐藏了用户的原始信息，例如IP、MAC等，对外只呈现隧道信息，同时隧道采用了唯一的SIP和DIP。那么Hash算法相同，算出的结果一致，导致流量无法做到很好的负载分担，便会使集群的单台设备负载突增，极端情况下就会出现被打爆的现象，进而影响该集群下的所有用户，这就是Hash极化，常出现于跨设备的多次Hash场景。
根据现状，我们分别尝试从以下两个角度解决该问题：
①?如果用户流量可以打散，如何避免封装隧道后的Hash极化？
②?如果用户流量无法打散，又该如何防止“大象流”打爆物理云网络？
下面，我们分别从这两点出发研究对应的解决方案。
2、如何避免封装隧道后的Hash极化？
针对这个问题，起初我们提出了多个解决方案：
①?方案1：用户流量由交换机轮询发送到集群每台设备。这种方法的优点在于流量可以充分打散，不会出现Hash极化现象。但同时缺点在于网络报文的时序被打乱，可能影响用户业务。
②?方案2：交换机基于隧道内层报文Hash。该方法基于用户的报文打散，优点在于可以较为均衡地打散在集群不同设备上。但问题在于用户报文封装隧道后会再次分片，将导致内层报文信息缺失和分片报文Hash到不同设备上。
③?方案3：为集群每台设备分配单独的隧道源IP。该方法可以实现有效的流量打散，但由于隧道数量有限，Hash不均的问题在现网实际表现依旧明显。
以上三个方法均不同程度地存在缺点，不能完全解决Hash极化问题。通过一系列的研究，最终我们找到了一种多隧道解决方案。即打破网关的单隧道模式，所有的网关绑定一个网段的隧道IP，基于用户的内层报文信息Hash，并在预先分配的网段中选择隧道的SIP和DIP，保证不同流量尽可能分布在不同的隧道，从而将用户流量打散。
图：多隧道解决方案示意
3、如何防止“大象流”打爆物理云网络？
多隧道方案的前提在于用户流量可以被打散，但是如果遇到“大象流”呢？即便是多个隧道也无法将避免被打爆的情况。面对用户的“大象流”，单靠技术手段还不够，我们同时也需要从硬件配置方面做好事前预防和规避。
■ 单机容量管理
首先需要对物理云网关进行合理的容量管理，保证网关可承载带宽高于用户物理云主机的带宽，同时保证整集群的承载能力满足用户需求。
图：示例-将单机容量从10G调整为25G
这一点其实与云厂商自身的能力密切相关，目前UCloud网关集群单机的承受能力远远大于单个用户的流量，在承载多用户汇聚流量的情况下，仍能保证个别用户的突发“大象流”不会打爆网关。
■?隔离区无损迁移
提升单机容量还远远不够，以防万一，UCloud还配备了隔离区，隔离区通常是无流量通过的。
图：隔离区无损迁移
如上图，一旦监测到流量过大，存在集群被打爆的风险时，集群配套的自动迁移系统便会修改需要迁移的物理机数据库信息，并自动更新对应转发规则，部分业务流量便可通过隔离区分担出去。同时我们还会基于强校验技术对迁移结果进行自动验证，保证迁移业务的无损可靠。
4、实例：新旧方案下的用户应用对比
在新方案上线前，由于Hash极化现象，集群通常只能承载几十G的流量，并且不时出现过载的状态。
新方案上线后，如下监控图，可以看到流量基本在集群上打散，集群的优势得到了充分发挥，目前集群可以承载上百G的流量，充分抵御用户业务量突增时的风险。例如达达在双十一时60G的流量压力是普遍现象，突发时还会出现流量达到100G的情况，此时集群流量依旧转发正常，对业务毫无影响。
图：流量监控图示意
除了提升性能，这次集群升级中对高可用设计也做了优化。
二、集群升级后的高可用性优化
针对集群升级，一般情况下会先部署新灰度集群，然后将用户业务逐步进行迁移。这样的好处在于可以在新集群版本存在缺陷的情况下，最大限度的控制影响范围，当出现故障时，可以及时回迁受影响的用户业务到老集群，避免用户业务受到影响。
图：预期结果-新Manager接管灰度集群
在灰度过程中，曾发现一个问题。
在新集群Manager部署完毕后，由于配置错误导致灰度集群接管了旧集群，Manager基于配置文件的集群信息自动接管集群的控制，并直接下发配置信息，旧集群接受错误配置。由于旧集群和新集群配置差异较大，导致旧集群在解释新配置时有误，出现高可用异常。
图：灰度Manager错误接管旧集群示意
1、风险分析
为了系统性避免这类问题，我们对配置过程进行了回溯分析，总结了存在的风险：
①?部署人为干预多，会加大故障概率；
②?程序的异常保护不够；
③?集群之间的有效隔离不足，若故障影响范围大。
2、优化：自动化运维&程序优化&隔离影响
■ 自动化运维
自动运维化通过自动化代替人工操作，可以有效避免人为错误的发生。我们对集群部署流程进行了优化，将其分为配置入库和部署两个流程，运维人员只需录入必要的配置信息，其余均通过自动化生成部署。
■?完善校验和告警
此外，我们还对部分程序作了优化，加大对异常配置的校验。例如，配置加载前，首先需进行白名单过滤，如果发现配置异常则终止配置加载，并进行告警通知后续人工介入。
图：白名单限制程序，只允许正确的控制面同步配置
■?隔离影响
最后，不管自动化运维机制和程序自身多精密，总要假设异常的可能。在此前提下，还需要考虑在故障发生时如何最大程度地减少影响范围和影响时间。我们的解决思路如下：
??去除公共依赖
前次问题主要缘于集群所有设备同时依赖了异常的Manager，导致一损俱损。因此需要去除集群设备中的公共依赖，缩减影响范围。例如不同的集群绑定不同Manager，这样可以有效控制影响范围。当然集群的公共依赖不仅仅可能出现在Manager，也可能是一个IP、一个机架等，这就需要我们在实际项目中仔细甄别。
??设置隔离区在影响范围可控的情况下，一个Manager异常只会影响集群中的部分设备，在该情况下还应该迅速剔除异常设备或者直接迁移该集群下的所有用户到隔离区，争取最快时间排除故障。
总结
随着技术的发展和业务的扩张，系统架构越发复杂、关联度越发紧密，对技术人员的要求也越来越高。在物理云网关集群的开发过程中，不可避免会遇到很多“坑”，但是无论何时都需秉承一点：一切技术都是为了业务服务。为此，我们把方案设计的经验分享出来，希望能够给予大家更多思考与收获。
原文地址：https://blog.51cto.com/13832960/2465210