极端场景下的网关可用性挑战
黎斌腾讯–公网网关运维负责人 个人介绍 黎斌腾讯公网网关运维负责人 2015年毕业，先后从事过CDN、应用商店等运维工作，2019年开始负责腾讯弹性IP和负载均衡的运营和运维工作。 腾 讯 公 网 网 关 介 绍 1 目录 现网极端场景案例 2 CONTENTS 如 何 系 统 化 应 对 极 端 场 景 3 Part01腾讯公网网关介绍 腾讯公网网关—TGW EIP TGW是Tencent Gateway的简称，是承担公司自研以及腾讯云IDC机房外网出口、负载均衡等功能的IaaS平台。腾讯云上基于TGW的产品包括EIP和CLB。 CLB TGW整体架构 TGW整体架构——转发平面 核心功能 EIP和CLB场景 •转发：接受到数据包之后，需要解包或者封包，将请求再转发给客户端或者RS 仅CLB场景 •调度：根据不同的调度算法，将请求动态分配给RS•健康探测：当某台或某几台云服务器不可用时，负载均衡可自动屏蔽故障的RS，将请求分发给正常运行的RS，保障应用系统正常工作•会话保持：将同一客户端的请求转发到同一RS LD：LoadbalanceDispatcherRS：Real Server TGW整体架构——管控平面 核心功能 •控制台：申请VIP、绑定和解绑RS、调整权重等•监控平台：带宽/QPS/连接数等指标的上报，用于计费以及监控•限速中心：带宽包以及性能保证型实例的实时限速•调度系统：容量管理，自动均衡容量，提升集群利用率•集群管理：集群的上下线、LD管理 接口层（HTTP） OSS（管理系统） Part02 现网极端场景案例 转发平面的容灾架构 容灾情况 Ø单机容灾：不同设备通过ECMP实现容灾切换，另外还有连接同步功能确保设备切换后长连接不断Ø交换机容灾Ø机架容灾ØAZ容灾：通过大小路由实现，zoneA发/25位的路由，zoneB发24位的路由，平时走zoneA。ZoneA故障自动切换到zoneB生效时间：10s内 看起来这个架构还是挺健壮的，是不是已经足够了？ 案例一：网卡批次BUG 现网案例一 2019年某集群遭遇畸形包攻击，服务器直接失联，整SET故障，攻击停止后，通过扩容恢复，整个故障持续46分钟。 和厂商配合复现了很久，才定位到特定批次的网卡bug，在特定的畸形包攻击场景下，网卡直接hang住，需要机房驻场重启才能恢复。 在这种攻击场景下，单机/机架/交换机/机房容灾措施都没有用，流量自动切换后，最后还是整集群故障。 带外通过NC-SI（NetworkControllerSidebandInterface）和数据通道共用一张网卡，网卡故障导致带外也不可用 案例一：网卡批次BUG—解决方案 硬件异构 带外独立管理网 Ø带外独立管理网，确保带外不受数据链路影响 Ø同集群两种机型做硬件异构，确保批次BUG不会导致整集群故障 Ø硬件批次的BUG，最多只影响集群中50%的设备，集群依然可以正常提供服务 硬件异构方案 案例二：特定包引发程序core 现网案例二 特性分析 22年9月，带扩展头的IPv6报文触发程序处理缺陷，引发core，故障持续50分钟 有特殊处理逻辑的报文仅占总量的5%，但是core极大概率是这部分产生的 所有扩容上去的设备都core了，最后找到发出异常报文的规则，把规则下线后才恢复。 扩容和迁移等恢复手段在这种场景都失效了。 案例二：特定包引发程序core——解决方案 定位异常 封禁能力建设 降级 关闭分片等复杂处理逻辑，提供有限的服务能力，5分钟内恢复95%的服务 vip粒度的封禁能力，也可以通过下线规则等实现 制定core文件生成规范，core文件中一定要带上vip、vpcid等关键信息，程序core后能快速分析出异常的规则 Part03如何系统化应对极端场景 未雨绸缪 故障的代价太过沉重 未来无法预测 世界上总在发生过去从来没有发生过的事，比如911、新冠、俄乌大战，对于我们的系统，同样如此。 极端场景一旦发生，因为缺少应对预案，故障影响大，恢复时间不可控 以转发平面为例——功能和架构 核心功能 最核心的功能是转发，对于转发平面来说，最极端的场景就是转发异常。 关联组件 Ø交换机Ø管控OSSØ限速中心 除了服务器异常，关联组件也可能会影响转发，比如限速中心下发了一个错误的限速配置 极端场景假设 未知故障场景——故障感知 黑盒监控 监控的监控 Ø除单机、进程、业务指标等白盒监控之外，补充最重要的黑盒监控Ø模拟真实的业务场景，进行探测，有未知的异常，都能第一时间发现 Ø各种原因可能导致监控失效，比如部分集群没有添加拨测规则，告警被屏蔽Ø建议针对监控本身，再而外增加监控，通过巡检、演练等方式来确保监控切实有效 TCP/UDP/overlay/underlay/大包/小包等各种特性 未知故障场景——预案 在未知故障场景下，通过将规则拷贝到预留的buffer集群，达到快速恢复的目的。 演习验证 •机型、地域、集群类型•模拟真实环境 场景 挑战：不常用的预案，如何保证可靠性？1.人员对预案不熟 2.软件架构迭代快，很有可能之前有效的预案需要的时候失效了 解决方案：演练 Ø演习需要投入大量的人力，而TGW的做法是自动化演练 总结 开放运维联盟高效运维社区DevOps时代 荣誉出品
