其他分享
首页 > 其他分享> > 阿里巴巴云原生 etcd 服务集群管控优化实践

阿里巴巴云原生 etcd 服务集群管控优化实践

作者:互联网

简介: 这些年,阿里云原生 etcd 服务发生了翻天覆地的变化,这篇文章主要分享一下 etcd 服务在面对业务量大规模增长下遇到的问题以及我们是如何解决的,希望对读者了解 etcd 的使用和管控运维提供经验分享。

头图.png

作者 | 陈星宇(宇慕)
来源 | 阿里巴巴云原生公众号

背景

Kubernetes 采用 etcd 存储其内部核心元数据信息。经过这些年的发展,尤其是伴随着这两年云原生的快速发展,Kubernetes被人们广泛认同并大规模被使用。伴随阿里内部容器平台 ASI 及公有云 ACK 集群数飞速增长,底层存储 etcd 集群获得井喷式地增长,etcd 集群数从原来的十几个发展到了目前达到几千个,它们分布在世界各地,为上层 Kubernetes 集群以及其他产品服务,服务用户超万个。

这些年,阿里云原生 etcd 服务发生了翻天覆地的变化,这篇文章主要分享一下 etcd 服务在面对业务量大规模增长下遇到的问题以及我们是如何解决的,希望对读者了解 etcd 的使用和管控运维提供经验分享。

具体将分三个部分进行介绍:

etcd 集群运行成本优化、利用率提升

近些年,etcd 集群数井喷式增长。它的运行形态经历了从 1.0 到 2.0 到 3.0 的变化,具体如下图:

1.jpg

1.0 物理机时代

在一开始,我们管控的 etcd 集群数比较少,我们在宿主机上使用 docker 直接运行 etcd 容器。即图中的 1.0 模式。

2.0 云上时代

1.0 模式运行 etcd 非常简单,但也存在使用物理机运行软件低效等常见问题,随着阿里巴巴全面上云的步伐,etcd 也全面将运行环境切到了云上 ecs,存储也换成了云盘 ssd 或 essd。

全面上云优势明显,利用阿里云底层 Iaas 的 ecs 弹性和存储云盘,etcd 集群可快速完成垂直水平伸缩,故障迁移也比 1.0 时容易的多。以集群升配操作为例,整个升级时间从最初的半小时降低到现在的 10 分钟,可以兼顾业务使用峰值和日常普通压力,稳定承载阿里内部双十一业务高峰以及外部多个公有云客户春节大促活动。

2.jpg

3.0 大规模云上时代

随着 etcd 集群数大量增长,运行这些集群需要的 ecs 与云盘成本越来越高,etcd 已成为容器服务花费资金最多的部分之一,etcd 运行的成本成为我们必须面对并解决优化的问题。

2.0 模式下使用独占 ecs 和云盘我们发现 etcd 资源利用率比较低,存在较多的资源浪费,我们将 2.0 模式进行了进一步升级:将集群进行混部,降级运行成本。但混部之后我们遇到计算资源争抢和集群稳定性等风险,时常发生 etcd 集群切主,导致上层依赖 etcd 软件功能异常,例如 Kubernetes controller 切主影响用户服务。

针对这些问题,我们首先将不同的 etcd 集群根据不同的服务质量和 SLO 拆分成多种类型,类似 Kubernetes 中 Best effort、Burstable 和 Guaranteed 3 种类型,把不同类型的集群放在不同的资源池中运行管理。混合部署由于采用了高度打散, 随机的模式, 再加上我们的集群用户很多,对 etcd 的热点请求被分割的很散,没有聚集,稳定性问题例如集群切主次数大量降低。在保证稳定性的前提下提升了资源利用率的目的,成本下降明显。

管控运维效率提升

早期我们运维管理 etcd 集群的方式比较简单,采用 shell 脚本基本可以涵盖 etcd 集群生命周期全过程,例如集群创建、删除,迁移都利用脚本完成。以前的这种小作坊模式随着集群数的井喷式增长越来越不适用,我们遇到 etcd 集群生产速度慢,适配底层 IaaS 变化难度大等问题,运行时集群管理效率也很低。

针对这些运维管控效率低的问题,我们拥抱云原生生态,用 Kubernetes 作为运行 etcd 的底座,并基于开源的 etcd-operator,经过几年的研发,适配阿里云底层 IaaS,修改了很多开源的 bug, 将 etcd 管控运维动作标准化,功能覆盖 etcd 管控全生命周期,推出了新的 etcd 运维管控后台 alpha, 我们利用 alpha 统一了阿里巴巴内部的 etcd 集群及公有云 ACK 上的 etcd 集群管控,极大地提高了我们管控运维 etcd 集群的效率。目前我们投入 0.5 人力就可以管理近万集群,人效比显著。下图展示了他的控制界面。

3.jpg

下面我们详细介绍一下 alpha 的具体功能,首先我们看一下下面这幅图,它描绘了一个 etcd 集群从创建-》运行-》故障-》再运行-》停止-》销毁的典型生命周期大图。

4.jpg

alpha 做的事情就是覆盖图上的方方面面,具体分为以下两部分:

1. etcd 集群生命周期管理

2. etcd 数据管理

etcd 数据管理包括数据迁移、备份管理以及恢复,脏数据清理,热点数据识别等。这块是 alpha 的特色,我们发现开源或其他产品这方面做得工作很少。我们做的功能具体如下。

1)etcd 数据备份及恢复

两种方式如下:

2)脏数据清理

我们可以根据指定 etcd key 前缀删除垃圾 kv 的能力,降低 etcd server 存储压力。

3)热点数据识别

我们开发了按照 etcd key 前缀进行聚合分析热点 key 的能力,另外还可以分析不同 key 前缀的 db 存储使用量。利用这个能力,我们多次帮助客户排查分析 etcd 热点 key,解决 etcd 滥用问题,这个在大规模 etcd 集群上是一个必备的能力。

4)数据迁移能力,两种方式

5)数据水平拆分

当集群数据存储数据量超大时,我们支持使用水平拆分将不同客户数据拆分存储到不同的 etcd 集群中。我们在阿里内部 ASI 集群就用了这个功能,使其支持超万规模节点。

总结一下,我们采用 Kubernetes 作为 etcd 集群的运行底座,基于开源 operator 改良适配研发了新的 etcd 管控软件 alpha,覆盖 etcd 全生命周期管控工作,一套软件管理所有 etcd 集群,显著提升了 etcd 管控效率。

etcd 内核架构升级更新

etcd 是云原生社区中非常重要的一款软件,几年的演进发展,解决了很多 bug, 提升了内核的性能和存储容量。但开源软件就像是一个毛坯房,真正在生产环境使用问题还是有的,阿里内部有更大数据存储规模和性能方面的要求,另外 etcd 自身多租户共享使用 QoS 控制能力很弱,不适用于我们的使用场景。

我们早期使用开源的 etcd 3.2/3.3 版本, 针对一些我们的使用场景需求,后续我们加入了一些稳定性和安全增强,形成了现在我们使用阿里内部版本,如下展示了重要的几个不同:

1. 自适应历史数据清理 compact 技术

etcd 会存储用户数据的历史值,但是它不能长久的存储所有历史值,否则存储空间会不足。因此 etcd 内部会利用 Compact 机制周期性地清理历史值数据。当我们的集群超大,数据量超大时,每次清理对运行时性能影响很大,可以类比一次 full gc。本技术可以根据业务请求量调整 Compact 时机,避开业务使用高峰期, 减少干扰。

2. 基于 raft learner 的只读节点水平扩展能力

raft learner 是 raft 协议中的一种特殊的角色,他不参与 leader 选举, 但是可以从 leader 处获得集群中最新的数据,因此他可以作为集群的只读节点进行水平扩展,提升集群处理读请求的能力。

3. 基于 raft learner 的热备节点

除了上面说的 raft learner 可以作为只读节点,我们也可以将其使能用于作为集群的热备节点,目前我们广泛使用热备节点做异地双活,保证集群高可用。

4. etcd 集群 QoS 能力

公有云上,我们有大量的用户采用共享 etcd 集群的方式使用 etcd, 在这种多租户使用场景下我们即需要保证租户公平使用 etcd 存储资源,也要保证稳定性即不会因为某一租户的滥用将集群整体搞挂,影响其他租户使用。为此我们自研了相应的QoS限流功能,可以实现不同租户运行时读写数据流量限制以及静态存储数据空间限制。

总结

阿里云采用 etcd 服务化做容器服务的核心数据存储系统已经有了将近 4 年的历史,我们积累了大量的运维管控 etcd 的经验和使用 etcd 的最佳实践,这篇文章分享了我们在降本提效,内核优化方面的一些实践。

近年来随着云原生的浪潮,etcd 也获得前所未有地急速发展,etcd 去年已从 cncf 正式毕业。阿里云为 etcd 社区贡献了重要的 feature 和 bug fix,积极参与社区,汲取社区营养,反哺贡献社区,可以预见未来 etcd 集群还会继续保持高速的增长,我们将继续在降本增效,保证稳定性和可靠性上持续投入努力。我们非常欢迎有兴趣的同学加入我们,联系 xingyu.chenxingyu@alibaba-inc.com。

KubeMeet 杭州站开放报名!

5.png

4 月 17 日,云原生基金会 CNCF 和阿里巴巴联合主办的「KubeMeet 开发者沙龙·云原生应用管理专场」来到杭州啦!这里有 Kubernetes 生态开发者都在关注的开源项目,以及阿里巴巴、携程、第四范式的一线云原生落地实践。点击此处赶紧报名吧

标签:原生,运维,管控,learner,集群,etcd,我们
来源: https://blog.csdn.net/xxscj/article/details/115718450