Etcd 写请求过程

etcdserver:mvcc:database space exceeded错误:

etcd server收到put/txn等写请求的时候,会首先检查当前etcd db大小加上请求的key-value大小只是否超过了配额。

如果超过配额,会产生一个告警请求,告警类型为NO SPACE,并通过Raft日志同步给其他节点,告知db无空间,并将告警持久化

到db中。

etcd设置建议配额不超过8G。APPLY模块在执行每个命令的时候,都会去检查当前是否存在NO SPACE告警,如果有则拒绝写入。

在调大配额之后,需要发送一个取消告警的命令,以消除所有告警。

检查etcd的压缩是否开启、配置是否合理。在配置etcd db配额,就不要设置小于0的,这样是禁用配额功能。

为了保证集群稳定性,避免雪崩,任何提交到raft模块的请求,都会做一些简单的限速判断。

在经过检查之后,会生成一个唯一的ID,将此请求关联到一个对应的消息通知channel,然后raft模块发起Propose一个提案,向raft模块发起的提案后,

KVServer模块会等待此put请求,等待写入结果通过消息通知channel返回或者超时。etcd默认超时时间是7秒,如果一个请求超时未返回结果,则可能会出现你熟悉的

Raft模块收到提案后,如果当前节点是Follower,它会转发给Leader,只有Leader才能处理写请求,Leader收到提案后,通过Raft模块输出待转发给Follower

节点的消息和待持久化的日志条目。

etcdserver 从Raft模块获取到以上消息和日志条目后,作为Leader,它会将put提案消息广播给集群各个节点,同时需要把集群Leader任期号、投票信息、

以提交索引、提案内容持久化到一个WAL日志文件中,用于保证集群的一致性，可恢复性。

WAL记录是按照顺序追加写入组成,每个记录由类型(Type)、数据(Data)、循环冗余校验码(CRC)组成。

WAL记录类型目前支持5种,分别是文件元数据记录、日志条目记录、状态信息记录、CRC记录、快照记录:

WAL模块是如何持久化一个put提案的日志条目记录:

每个提案被提交前都会被持久化到WAL文件中,以保证集群的一致性和可恢复性。

etcd的幂等性是根据Raft日志条目中的索引字段。etcd通过引入consistent index字段,来存储系统当前已经执行过的日志条目索引,实现幂等性。

Apply模块基于consistent index和事务实现了幂等性。

MVCC主要是由两部分组成,一个是内存索引模块treeIndex,保存key的历史版本信息,另一个是boltdb模块,用来持久化存储key-value数据。

版本号在etcd里面发挥着重大作用,它是etcd的逻辑时钟。etcd启动的时候默认版本号是1,从最小值1开始枚举到最大值,未读到数据的数据则结束,最后读出来的

版本号即时当前etcd的最大版本号currentRevision。

boltdb是一个基于B+tree实现的key-value嵌入式db,通过提供桶机制实现类似于MySQL表的逻辑隔离。

将修改的数据放入到一个名为key的桶里,在启动etcd时自动创建。

boltdb value的值是将包含key名称、key创建是时版本号、最后一次修改的版本号、修改菜蔬、value值、租赁信息序列化为二进制数据。

etcd使用合并再合并解决写性能差的问题:

etcd在启动时候通过mmap机制将etcd db文件映射到etcd进程地址空间,并设置mmap的MAP_POPULATE flag,它会告诉Linux内核预读文件,Linux就会将文件内容

拷贝到物理内存中,此时会产生磁盘I/O。节点在内存足够的请求下,后续处理读请求过程中就不会产生磁盘I/O了。

如果etcd节点内存不足时,可能会导致db文件对应的内存页被换出,当读请求命中的文件未在内存中时,就会产生缺页异常,导致读过程中产生磁盘IO,

可以通过观察etcd进程

可以通过观察etcd进程的majflt字段来判断etcd是否产生了主缺页中断。

一、生成带认证的etcd签名

核心： http://www.simlinux.com/2017/09/07/k8s-cfssl-install-cert.html

主要： https://www.jianshu.com/p/1043903bc359

次要： https://www.jianshu.com/p/807c9a0c5185

二、cd /root/kubernetes/cluster/centos/master/scripts/ 找到 etcd.sh，并执行

1）发现需要第一个参数是etcd名称，第二个参数是监听的端口；该两个参数在生成签名的时候要注意

以下为签名过程

以上的192.168.235.70，127.0.0.1即为 etcd.sh 脚本启动时的ip，我们发现了 etcd.sh 脚本中（ETCD_LISTEN_CLIENT_URLS="https:// {ETCD_LISTEN_IP}:2379；即0.0.0.0，那么systemctl restart etcd启动时，会报错误（listen tcp 127.0.0.1:2379: bind: address already in use）；因为0.0.0.0生成签名的时候并没有指定；

2、测试是否通过

返回

​ etcd是由CoreOS团队发的一个分布式一致性的KV存储系统，可用于服务注册发现和共享配置，随着CoreOS和Kubernetes等项目在开源社区日益火热，它们项目中都用到的etcd组件作为一个高可用强一致性的服务发现存储仓库，渐渐为开发人员所关注。在云计算时代，如何让服务快速透明地接入到计算集群中，如何让共享配置信息快速被集群中的所有机器发现，更为重要的是，如何构建这样一套高可用、安全、易于部署以及响应快速的服务集群，已经成为了迫切需要解决的问题。etcd为解决这类问题带来了福音，本文将从etcd的应用场景开始，深入解读etcd的实现方式，以供开发者们更为充分地享用etcd所带来的便利。

​ etcd推荐使用奇数作为集群节点个数。因为奇数个节点和其配对的偶数个节点相比，容错能力相同，却可以少一个节点。综合考虑性能和容错能力，etcd官方文档推荐的etcd集群大小是3,5,7。由于etcd使用是Raft算法，每次写入数据需要有2N+1个节点同意可以写入数据，所以部分节点由于网络或者其他不可靠因素延迟收到数据更新，但是最终数据会保持一致，高度可靠。随着节点数目的增加，每次的写入延迟会相应的线性递增，除了节点数量会影响写入数据的延迟，如果节点跟接节点之间的网络延迟，也会导致数据的延迟写入。

结论：

​ 1.节点数并非越多越好，过多的节点将会导致数据延迟写入。

​ 2.节点跟节点之间的跨机房，专线之间网络延迟，也将会导致数据延迟写入。

​ 3.受网络IO和磁盘IO的延迟

​ 4.为了提高吞吐量，etcd通常将多个请求一次批量处理并提交Raft，

​ 5.增加节点，读性能会提升，写性能会下降，减少节点，写性能会提升。

参数说明：

这种方式就是 利用一个已有的 etcd 集群来提供 discovery 服务，从而搭建一个新的 etcd 集群。

假设已有的 etcd 集群的一个访问地址是： myetcd.local ，那么我们首先需要在已有 etcd 中创建一个特殊的 key，方法如下：

其中 value=3 表示本集群的大小，即: 有多少集群节点。而 6c007a14875d53d9bf0ef5a6fc0257c817f0fb83 就是用来做 discovery 的 token。

接下来你在 3 个节点上分别启动 etcd 程序，并加上刚刚的 token。

加 token 的方式同样也有 命令行参数 和 环境变量 两种。

命令行参数:

环境变量

以 命令行参数 启动方式为例：

可以使用etcd附带的 基准 CLI工具完成基准测试etcd性能。

对于一些基准性能数字，我们考虑具有以下硬件配置的三个成员的etcd集群：

有了这个配置，etcd可以大致写出：

示例命令是：

可线性读取请求通过集群成员的法定人数达成一致以获取最新数据。可序列化的读取请求比线性读取要便宜，因为它们由任何单个etcd成员提供，而不是成员法定人数，以换取可能的陈旧数据。etcd可以阅读：

示例命令是：

我们鼓励在新环境中首次安装etcd集群时运行基准测试，以确保集群达到足够的性能群集延迟和吞吐量可能会对较小的环境差异敏感。

以上测试部分翻译自官方文档（ https://coreos.com/etcd/docs/latest/op-guide/performance.html ）

---