DockOne技术分享(三十一):细节 |谈谈CoreOS的etcd


【编者的话】本次分享主要介绍目前etcd的状况和其今后的发展。

@Container大会,专为一线开发者和运维工程师设计的顶级容器技术会议。

etcd是CoreOS开发的一个分布式一致性键值存储系统。etcd主要被用于存储集群的关键数据和对集群内部组建进行协调。etcd采用了raft分布式一致性协议来保证自身的数据一致性和可用性。一个etcd集群一般由3到5台节点组成。只要有多余半数的节点可用,整个etcd系统对外看来也是可用状态的。

etcd的API相对简单。首先etcd支持基本的键值操作,例如GET、PUT、DELETE。除此之外,etcd还支持CompareAndSwap这个原子性操作。CompareAndSwap首先对一个key进行值比较,如果比较结果一致才会进行下一步的赋值操作。像利用x86的CAS实现锁一样,利用CompareAndSwap可以实现分布式的锁系统。

另外etcd还支持watch操作。用户可以watch在一个key或者一个directory上。如果key的值发生了改变,etcd会通知watch的client。不同于ZooKeeper的ont time trigger watch,etcd的watch在一般情况下可以保证不漏掉任何变更。etcd不仅仅存储了全部的键值,它还存储了最近的键值变更纪录。所以一个比较落后的watch还是可以通过遍历最近的变更纪录来获取到最近的所有更新。

最后etcd支持TTL key。每个key可以有一个TTL属性来表示它的存活时间。如果存活时间是5秒,那么etcd会在5秒之后自动删除这个key并且通知watch在这个key上的用户。另外一个带有TTL的key也可以不断的被刷新来延长存活时间。用户可以利用这个功能来时间leader election。

etcd 2是目前最新的etcd版本。它支持稳定的v2 API以及非常稳固的raft分布式一致性。我们内部运行了一些etcd测试集群。这些测试集群不断的被注入错误。比如强制关闭一台机器、暂停一台机器、让一台机器运行缓慢或者阻断网络通讯等等。我们在前期发现了一些bug,在修复了bug之后etcd的测试集群已经稳定的工作了几个月。我们对etcd的稳定性非常有信心。

目前etcd项目的主要开发精力集中在推出全新一代的etcd 3。etcd 3主要解决如下几个问题:多版本键值(MVCC)、迷你事务(mini transcation)、更稳定的watch、大数据规模、大用户watch、性能优化。

多版本键值可以减轻用户设计分布式系统的难度。通过对多版本控制,用户可以获得一个一致的键值空间的snapshot。用户可以在无锁的状态下来查询snapshot上的键值来做出下一步决定。

mini transaction支持原子性比较多个键值并且操作多个键值。之前的CompareAndSwap实际上一个针对单个key的mini transaction。一个简单的例子是 Tx(compare: A=1 && B=2, success: C = 3, D = 3, fail: C = 0, D = 0)。当etcd收到这条transcation请求,etcd会原子性的判断A和B当前的值和期待的值。如果判断成功,C和D的值会被设置为3。

etcd 2保存了一个仅保存了1000个历史更改,如果watch过慢就无法得到之前的变更。etcd 3为了支持多纪录,采用了历史记录为主索引的存储结构。etcd3可以存储上十万个纪录,进行快速查询并且支持根据用户的要求进行compaction。

etcd 2和其它类似开源一致性系统一样最多只能数十万级别的key。主要原因是一致性系统都采用了基于log的复制。log不能无限增长,所以在某一时刻系统需要做一个完整的snapshot并且将snapshot存储到磁盘。在存储snapshot之后才能将之前的log丢弃。每次存储完整的snapshot是非常没有效率的,但是对于一致性系统来说设计增量snapshot以及传输同步大量数据都是非常繁琐的。etcd 3通过对raft和存储系统的重构,能够很好的支持增量snapshot和传输相对较大的snapshot。目前etcd 3可以存储百万到千万级别的key。

另外一个问题是支持大规模watch。我们主要工作是减小每个watch带来的资源消耗。首先我们利用了HTTP/2的multiple stream per tcp connection,这样同一个client的不同watch可以share同一个tcp connection。另一方面我们对于同一个用户的不同watch只使用一个go routine来serve,这样再一次减轻了server的资源消耗。

我们在性能方面也做了很多相关的优化。etcd 3目前的性能远强于etcd 2,我们相信etcd 3的性能在不进行特殊优化的情况下就可以足够应付绝大部分的使用。在一个由3台8核节点组成的的云服务器上,etcd 3可以做到每秒数万次的写操作和十万次读操作。

最后我们争取在明年年初发布etcd 3。

Q&A

Q:请问下etcd目前的并发连接是多少,支持多少目录?

A:这个要看你自身的服务器情况。目前每个watch都会占用一个tcp资源和一个go routine资源,大概要消耗30-40kb。etcd 3做了很多优化。
支持目录和key是类似的,目前可以做到100k左右的小key。
Q:etcd未来的版本会像ZooKeeper一样支持临时节点吗?

A:目前etcd支持ttl key,etcd 3会支持lease,lease可以lease到多key,lease到期会把所有key自动删除。相当于group一些ttl keys。ZooKeeper的临时节点从我看来是一个broken的功能。
Q:etcd在其他OS像CentOS上性能会有折扣吗?

A:etcd对CoreOS本身没有任何依赖,所以不会。
Q:etcd 2和ZooKeeper相比优势在哪些方面?

A:和ZooKeeper的设计理念和方向不太一样。目前etcd着重于go stack和cloud infra领域。很多上层系统例如Kubernetes、CloudFoundry、Mesos等都对稳定性、扩展性有更高的要求。由于理念的不同,导致了很多设计的不同。比如etcd会支持稳定的watch而不是简单的one time trigger watch,因为很多调度系统是需要得到完整历史记录的。etcd支持mvcc,因为可能有协同系统需要无锁操作等等。在性能上今后etcd可能也要做更多工作,因为container infra有更多的大规模场景。
Q:etcd能放到Docker里么,有没有这方面案例?

A:https://github.com/coreos/etcd ... de.md
Q:etcd与Consul比,有什么特色和差异?

A:Consul是个full stack的工具。etcd只是一个简单的一致性kv。我们认为能把一致性kv这件事情完整的做好已经不容易了。
我们希望上层的系统可以在etcd上搭建,而不是让etcd本身服务最终用户。另外在某些程度上而言,Consul并不着重保证自身的稳定性和可靠性。HashiCorp自己的调度系统nomad也并没有采用Consul。这些差别导致了很多设计、实现上的不同。
Q:请问Kubernetes中使用etcd主要用来做什么?

A:存储重要的集群信息和做相关组建之间的协调。
Q:etcd在n台(n大于等于3)机器组成的集群下,性能如何,性能会随机器数下降么?

A:写性能会的。etcd 3做了相关优化,分配了一些写load,etcd 2下降一些。
Q:外Masters实效后,要多久才能选出新的Masters恢复写?

A:可以根据服务环境自行设置。默认的timeout是1秒,2秒内可以选出。如果网络经常不稳定,或者服务器忙,可以提高到5秒,10秒内选出。
===========================
以上内容根据2015年11月6日晚微信群分享内容整理。分享李响,就职于CoreOS,专注于分布式系统和容器集群管理研究开发。目前是etcd的maintainer,rkt和Kubernetes的主要贡献者。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesx,进群参与,您有想听的话题可以给我们留言。

2 个评论

etcd 2和其它类似开源一致性系统一样最多只能数十万级别的key。主要原因是一致性系统都采用了基于log的复制。log不能无限增长,所以在某一时刻系统需要做一个完整的snapshot并且将snapshot存储到磁盘。在存储snapshot之后才能将之前的log丢弃。每次存储完整的snasphot是非常没有效率的,但是对于一致性系统来说设计增量snapshot以及传输同步大量数据都是非常繁琐的。etcd 3通过对raft和存储系统的重构,能够很好的支持增量snapshot和传输相对较大的snapshot。目前etcd 3可以存储百万到千万级别的key。

每次存储完整的snasphot是非常没有效率的。这句的snasphot,应该是snapshot吧。
是的,谢谢提醒。

要回复文章请先登录注册