炼数成金 门户 大数据 分布式系统 查看内容

手把手教你学习 etcd

2018-7-23 15:19| 发布者: 炼数成金_小数| 查看: 17412| 评论: 0|原作者: SRE|来自: 小米运维

摘要: etcd 是一个分布式的、一致性的键值存储系统,主要用于配置共享和服务发现,etcd 基于 Go 语言实现;Google 的容器集群管理系统 Kubernetes、开源 PaaS 平台 Cloud Foundry 和 CoreOS 的 Fleet 都广泛使用了 etcd。 ...

算法 存储 安全 服务器 分布式

基本概念及特点
etcd 是一个分布式的、一致性的键值存储系统,主要用于配置共享和服务发现,etcd 基于 Go 语言实现;Google 的容器集群管理系统 Kubernetes、开源 PaaS 平台 Cloud Foundry 和 CoreOS 的 Fleet 都广泛使用了 etcd。有以下特性:

简单:安装配置简单,而且提供了 HTTP API 进行交互,使用简单;
安全:可选的 SSL 客户端证书认证;
快速:根据官方提供的 benchmark 数据,单实例支持每秒 2k+ 读操作;
可靠:采用 Raft 算法,实现分布式系统数据的可用性和一致性。

etcd 主要组成部分


图1

HTTP Server:用于处理用户发送的 API 请求以及其它 etcd 节点的同步与心跳信息请求。

Store:用于处理 etcd 支持的各类功能的事务,包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等,是 etcd 对用户提供的大多数 API 功能的具体实现。

Raft:Raft 强一致性算法的具体实现,是 etcd 的核心。

WAL:Write Ahead Log(预写式日志),是 etcd 的数据存储方式。除了在内存中存有所有数据的状态以及节点的索引以外,etcd 就通过 WAL 进行持久化存储。WAL 中, 所有的数据提交前都会事先记录日志。Snapshot 是为了防止数据过多而进行的状态快照;Entry 表示存储的具体日志内容。

etcd 工作原理


图2

STATUS
在任何时刻,每一个服务器节点都处于这三个状态之一:领导人、跟随者或者候选人。

在通常情况下,系统中只有一个领导人并且其他的节点全部都是跟随者。

跟随者都是被动的:他们不会发送任何请求,只是简单的响应来自领导者或者候选人的请求。

领导人处理所有的客户端请求(如果一个客户端和跟随者联系,那么跟随者会把请求重定向给领导人)。

第三种状态,候选人,是用来在选举新领导人时使用。图二展示了这些状态和他们之前转换关系。

图3

TERM
Raft 把时间分割成任意长度的任期,如图三。任期用连续的整数标记。每一段任期从一次选举开始,一个或者多个候选人尝试成为领导者。如果一个候选人赢得选举,然后他就在接下来的任期内充当领导人的职责。

在某些情况下,一次选举过程会造成选票的瓜分。在这种情况下,这一任期会以没有领导人结束;一个新的任期(和一次新的选举)会很快重新开始。

Raft 保证了在一个给定的任期内,最多只有一个领导者。任期在 Raft 算法中充当逻辑时钟的作用,这会允许服务器节点查明一些过期的信息比如陈旧的领导者。

每一个节点存储一个当前任期号,这一编号在整个时期内单调的增长。当服务器之间通信的时候会交换当前任期号。

如果一个服务器的当前任期号比其他人小,那么他会更新自己的编号到较大的编号值。

如果一个候选人或者领导者发现自己的任期号过期了,那么他会立即恢复成跟随者状态。

如果一个节点接收到一个包含过期的任期号的请求,那么他会直接拒绝这个请求。

RPCS
Raft 算法中服务器节点之间通信使用远程过程调用(RPCs):

请求投票(RequestVote) RPCs 由候选人在选举期间发起;
附加条目(AppendEntries)RPCs 由领导人发起,用来复制日志和提供一种心跳机制;
传输快照 RPCs,服务器没有及时的收到 RPC 的响应时,会进行重试, 并且他们能够并行的发起 RPCs 来获得较佳的性能;

时间要求
广播时间(broadcastTime) << 选举超时时间(electionTimeout) << 平均故障间隔时间(MTBF)

广播时间指的是从一个服务器并行的发送 RPCs 给集群中的其他服务器并接收响应的平均时间;

选举超时时间就是选举的超时时间限制;

平均故障间隔时间就是对于一台服务器而言,两次故障之间的平均时间。广播时间必须比选举超时时间小一个量级,这样领导人才能够发送稳定的心跳消息来阻止跟随者开始进入选举状态;通过随机化选举超时时间的方法,这个不等式也使得选票瓜分的情况变得不可能。选举超时时间应该要比平均故障间隔时间小上几个数量级,这样整个系统才能稳定的运行。

领导人选举
Raft 使用心跳机制来进行领导人选举。当集群初始化时候,每个 node 都是跟随者身份。node 节点继续保持着跟随者状态直到他从领导人或者候选者处接收到有效的 RPCs。

领导者周期性的向所有跟随者发送心跳包(即不包含日志项内容的附加日志项 RPCs)来维持自己的权威。如果一个跟随者在一段时间里没有接收到任何消息,也就是选举超时,那么他就会认为系统中没有可用的领导者, 并且发起选举以选出新的领导者。

要开始一次选举过程,跟随者先要增加自己的当前任期号并且转换到候选人状态。然后他会并行的向集群中的其他服务器节点发送请求投票的 RPCs 来给自己投票。

候选人会继续保持着当前状态直到以下三件事情之一发生:
自己赢得了这次的选举;
其他的 node 成为领导者;
一段时间之后没有任何一个 node 获胜;

如上结果会分别的在下面进行讨论:
当一个候选人从整个集群的大多数服务器节点获得了针对同一个任期号的选票,那么他就赢得了这次选举并成为领导人。每一个 node 最多会对一个任期号投出一张选票,按照先来先服务的原则。要求大多数选票的规则确保了最多只会有一个候选人赢得此次选举。一旦候选人赢得选举,他就立即成为领导人。然后他会向其他的服务器发送心跳消息来建立自己的权威并且阻止新的领导人的产生。

在等待投票的时候,候选人可能会从其他的服务器接收到声明它是领导人的附加日志项 RPC。如果这个领导人的任期号(包含在此次的 RPC 中)不小于候选人当前的任期号,那么候选人会承认领导人合法并回到跟随者状态。 如果此次 RPC 中的任期号比自己小,那么候选人就会拒绝这次的 RPC 并且继续保持候选人状态。

第三种可能的结果是候选人既没有赢得选举也没有输:如果有多个跟随者同时成为候选人,那么选票可能会被瓜分以至于没有候选人可以赢得大多数人的支持。当这种情况发生的时候,Raft 算法使用随机选举超时时间的方法来确保很少会发生选票瓜分的情况,就算发生也能很快的解决。为了阻止选票起初就被瓜分,选举超时时间是从一个固定的区间(例如 150-300 毫秒)随机选择。这样可以把服务器都分散开以至于在大多数情况下只有一个服务器会选举超时;然后他赢得选举并在其他服务器超时之前发送心跳包。

在选票瓜分的情况下,每一个候选人在开始一次选举的时候会重置一个随机的选举超时时间,然后在超时时间内等待投票的结果;这样减少了在新的选举中另外的选票瓜分的可能性。

etcd 数据存储
etcd 的存储分为 内存存储 和 持久化(硬盘)存储 两部分。

在 WAL 的体系中,所有的数据在提交之前都会进行日志记录。在 etcd 的持久化存储目录中,有两个子目录。

一个是 WAL,存储着所有事务的变化记 录;另一个则是 snapshot,用于存储某一个时刻 etcd 所有目录的数据。

通过 WAL 和 snapshot 相结合的方式,etcd 可以有效的进行数据存储和节点故障恢复等操作。既然有了 WAL 实时存储了所有的变更,为什么还需要 snapshot 呢?随着使用量的增加,WAL 存储的数据会暴增,为了防止磁盘很快就爆满,etcd 默认每 10000 条记录做一次 snapshot,经过 snapshot 以后的 WAL 文件就可以删除。而通过 API 可以查询的历史 etcd 操作默认为 1000 条。首次启动时,etcd 会把启动的配置信息存储到 data-dir 参数指定的数据目录中,如下图:


部署 etcd
etcd 一般部署集群推荐奇数个节点,推荐的数量为 3、5 或者 7 个节点构成一个集群。如下使用三个节点为例:


1、安装 etcd 服务
yum install etcd

2、修改配置,如下配置文件根据实际应用场景做相应的修改。


3、启动服务
systemctl start etcd.service

注意:如果修改了 etcd.service 文件,需要先 load 配置,再启动服务。

systemctl daemon-reload
systemctl start etcd.service

4、检查所有集群节点信息
V2:  etcdctl member list
V3:  ETCDCTL_API=3 etcdctl member list


5、检查集群健康状态
V2: etcdctl cluster-health
V3: ETCDCTL_API=3 etcdctl --endpoints=[10.108.187.32:2379,10.108.187.12:2379,10.108.28.30:2379,10.108.16.30:2379] endpoint status
V3: ETCDCTL_API=3 etcdctl --endpoints=[10.108.187.32:2379,10.108.187.12:2379,10.108.28.30:2379,10.108.16.30:2379] endpoint health


总结
Raft 强一致性算法的具体实现是 etcd 的核心;理解 raft 一致性算法,是理解 Etcd 集群工作原理的基础,本文拿出大量篇幅来描述 raft 协议中领导人选举,使大家清晰的明白选举过程;raft 协议除了领导人选举,还包含日志复制和安全等两个重要模块。日志复制模块是 etcd 集群数据一致性的基础,安全模块是 etcd 集群稳定和可靠的基础,都比较重要。

本文是 etcd 服务简介、架构、工作原理和服务部署解析入门,etcd 服务集群还包括集群使用、集群管理、集群升级、集群数据备份和集群监控等内容,大家可以进行更深一步的学习。

声明:文章收集于网络,如有侵权,请联系小编及时处理,谢谢!

欢迎加入本站公开兴趣群
软件开发技术群
兴趣范围包括:Java,C/C++,Python,PHP,Ruby,shell等各种语言开发经验交流,各种框架使用,外包项目机会,学习、培训、跳槽等交流
QQ群:26931708

Hadoop源代码研究群
兴趣范围包括:Hadoop源代码解读,改进,优化,分布式系统场景定制,与Hadoop有关的各种开源项目,总之就是玩转Hadoop
QQ群:288410967 

鲜花
1

握手

雷人

路过

鸡蛋

刚表态过的朋友 (1 人)

相关阅读

最新评论

热门频道

  • 大数据
  • 商业智能
  • 量化投资
  • 科学探索
  • 创业

即将开课

 

GMT+8, 2018-11-16 19:23 , Processed in 0.286365 second(s), 24 queries .