不止是上云,更是上岸

常耀国,腾讯SRE专家,现就职于PCG-大数据平台部,负责千万级QPS业务的上云、监控和自动化工作。

背景

BeaconLogServer 是灯塔 SDK 上报数据的入口,接收众多业务的数据上报,包括微视、 QQ 、腾讯视频、 QQ 浏览器、应用宝等多个业务,呈现并发大、请求大、流量突增等问题,目前 BeaconLogServer 的 QPS 达到千万级别以上,为了应对这些问题,平时需要耗费大量的人力去维护服务的容量水位,如何利用上云实现 0 人力运维是本文着重分析的

混合云弹性伸缩

弹性伸缩整体效果

首先谈一下自动扩缩容,下图是 BeaconLogServer 混合云弹性伸缩设计的方案图

弹性伸缩方案

资源管理

先从资源管理讲起,目前 BeaconLogServer 节点个数是8000多个,需要的资源很大,单独依靠平台的公共资源,在一些节假日流量突增的时候,可能无法实现快速的扩容,因此,经过调研123平台(PAAS 平台)和算力平台(资源平台),我们采用了混合云的方式,来解决这个问题。分析 BLS 业务场景,流量突增存在下面两种情况

  • 日常业务负载小幅度升高,时间持续较短
  • 春节业务负载大幅度升高,并持续一段时间 针对上述的业务场景,我们采用三种资源类型来应对不同场景,具体如下表所述:

类型

场景

set

公共资源池

日常业务

bls.sh.1

算力平台

小高峰

bls.sh.2

专用资源池

春节

bls.sh.3

日常业务我们使用公共资源池+算力资源,当业务的负载小幅度上升的话,使用算力资源快速扩容,保障服务的容量水位不超过安全阈值。面对春节负载大幅度升高,这时需要构建专有资源池来应对春节的流量升高。

弹性扩缩容

上文阐述了资源的管理,那么针对不同的资源,何时开始扩容,何时开始缩容?

BeaconLogServer 日常的流量分布是 123 平台公共资源:算力平台=7:3。目前设置的自动扩容的阈值是60%,当 CPU 使用率大于60%,平台自动扩容。弹性扩缩容依赖的是 123 平台的调度功能,具体的指标设置如下:

类型

CPU自动缩容阈值

CPU自动扩容阈值

最小副本数

最大副本数

123平台公共资源池

20

60

300

1000

算力平台

40

50

300

1000

123平台专有资源池

20

60

300

1000

可以看到算力平台自动缩容阈值较大,自动扩容阈值较小,主要考虑算力平台是应对流量突增的情况,而且算力平台资源经常替换,因此优先考虑先扩容或缩容算力平台的资源。最小副本数是保障业务所需的最低资源需求,如果少于这个值,平台会自动补充。最大副本数设置1000,是因为 IAS 平台(网关平台)一个城市支持的最大 RS 节点数是1000。

问题及解决

方案推进的过程中,我们也遇到了很多问题,挑选几个问题和大家分享一下。

1)首先从接入层来讲,之前接入层业务使用的是 TGW , TGW 有一个限制,就是RS的节点不能超过200个,目前 BeaconLogServer 的节点是8000多个,继续使用 TGW 需要申请很多个域名,迁移耗时多且不便于维护。我们调研接入层 IAS , IAS 四层每个城市支持的节点个数是1000个,基本可以满足我们的需求,基于此,我们设计如下的解决方案如下:

总体上采用“业务+地域”模式分离流量。当集群中一个城市的 RS 节点超过500个就需要考虑拆分业务,例如公共集群的节点超出阈值,可以把当前业务量大的视频业务拆分出来,作为一个单独的集群;如果是一个独立集群的业务节点超出阈值,先考虑增加城市,把流量拆分到新的城市。如果无法新增城市,此时考虑新增一个 IAS 集群,然后在 GLSB 上按照区域把流量分配到不同的集群。

2)同一个城市不同的资源池设置不同的 set,那么IAS如何接入同一个城市不同 set 呢?北极星本来有[通配组功能],但是 IAS 不支持 set 通配符功能实际上,我们推动 IAS 实现了通配组匹配,例如使用 bls.sh.% 可以匹配 bls.sh.1 , bls.sh.2 , bls.sh.3 。注意, IAS 通配符和北极星的不一样,北极星使用的是***, IAS 在上线的时候发现有用户使用*做单独匹配,所以使用%来表示通配符。

3)资源管理这块遇到的难点是 IAS 四层无法使用算力资源的节点,后面在经过沟通,打通了 IAS 到算力资源的。这里的解决方案是使用 SNAT 能力

此方案的注意事项

  • 只能绑定 IP 地址,无法拉取实例,实例销毁也不会自动解绑,需要通过控制台或 API 主动解绑(已跨账号,拉取不到实例)
  • 如果是大规模上量:过哪些网关、哪些容量需要评估、风险控制,需要评估

单机故障自动化处理

单机故障处理效果

单机故障自动化处理,目标是实现0人力维护,如下图是我们自动化处理的截图

单机故障处理方案

单机故障主要从系统层面和业务层面两个维度考虑,详情如下:

维度

告警项

系统层面

CPU

系统层面

内存

系统层面

网络

系统层面

磁盘

业务层面

ATTA Agent不可用

业务层面

队列过长

业务层面

发送atta数据成功率

针对单机故障,我们采用的是开源的 Prometheus +公司的 Polaris(注册中心) 的方式解决。Prometheus 主要是用来采集数据和发送告警,然后通过代码把节点从 Polaris 摘除。

至于告警发生和告警恢复的处理,当告警发生的时候,首先会判断告警的节点个数,如果低于三个以下,我们直接在 Polaris 摘除节点,如果大于3个,可能是普遍的问题,这时候我们会发送告警,需要人工的介入。当告警恢复的时候,我们直接在平台重启节点,节点会重新注册 Polaris 。

ATTA Agent 异常处理

如图所示,处理流程是两条线,告警触发和告警恢复,当业务异常的时候,首先判断当前异常节点的数量,保证不会大范围的摘掉节点。然后在北极星摘除节点。当业务恢复的时候,直接重启节点。

问题及解决

主要的难点是 Prometheus Agent 的健康检查和 BeaconLogServer 节点的动态变化,对于第一个问题,目前主要是由平台方负责维护。对于第二个问题,我们利用了定时脚本从 Polaris 拉取节点和 Prometheus 热加载的能力实现的。

总结

此次上云有效的解决了自动扩缩容和单机故障这两块的问题,减少了手动操作,降低了人为操作错误风险,提升系统的稳定性。通过此次上云,也总结了几点:

  • 迁移方案:上云之前做好迁移方案的调研,特别是依赖系统的支持的功能,降低迁移过程因系统不支持的系统性风险 。
  • 迁移过程:做好指标监控,迁移流量之后,及时观测指标,出现问题及时回滚。

互动赢好礼

精读文章,回答问题赢好礼

Q1:0人力运维是否是伪命题?

Q2:目前大环境都在上云,那么在上云的过程中,各位遇到的问题和解决的方式可以分享一下。

12月1日上午11点由作者选出回答最佳的5位读者,送腾讯定制“猿”T恤一件。

  往期精选推荐  

  • GPU 分布式 AI 训练加速引擎 TACO-Training 容器方案首发!
  • 智能 Request 推荐,K8s 资源利用率提升 252%
  • 揭秘!containerd 镜像文件丢失问题,竟是镜像生成惹得祸
  • 容器服务 TKE 存储插件与云硬盘 CBS 最佳实践应用
  • 深入了解服务网格数据平面性能和调优

点个“在看”每天学习最新技术