CoreOS 实战：剖析 etcd

CoreOS 实战：剖析 etcd

1. 概述

etcd 是一个应用在分布式环境下的 key/value 存储服务。利用 etcd 的特性，应用程序可以在集群中共享信息、配置或作服务发现，etcd 会在集群的各个节点中复制这些数据并保证这些数据始终正确。etcd 无论是在 CoreOS 还是 Kubernetes 体系中都是不可或缺的一环。笔者由于项目的原因对 etcd 进行了一些了解，也已经使用了一段时间。同时在与同行的交流中常被问到 etcd 是什么、与 ZooKeeper 有什么不同。那么借着 etcd 0.5.0 即将发布的机会，向感兴趣的读者介绍一下 etcd，希望可以帮助读者了解 etcd 的工作原理以及具体实现，同时也作为 CoreOS 实战的第二部分内容为后面相关的部分进行铺垫。

随着 etcd 0.5.0 alpha （本文完稿时为 etcd 0.5.0 alpha.3）版发布，etcd 将在未来几周内迎来一次重要的更新。在 0.5.0 版里除了修复现有稳定版中的一系列 Bug 之外，一些新的特性和变更也将随之发布。这些变化将提升 etcd 服务安全性、可靠性和可维护性。

新的特性包括

  • 规范词汇表；
  • 新的 raft 算法实现；
  • 新增 etcd node 身份标记；
  • WAL (Write-ahead logging) 增加 CRC 校验；
  • API 中新增 member {list, add, remove} 接口，原来的 list machines 接口将被移除，未来 etcd 集群中将不存在 machine 的称呼；
  • 两个主要端口变更为 2379 (for client) 与 2380 (for peer/raft) 并成为 IANA 的注册端口。

重要的变更包括

  • 运行时重构 (runtime reconfiguration)。用户不需要重启 etcd 服务即可实现对 etcd 集群结构进行变更。
  • 摒弃通过配置文件配置 etcd 属性的方式，转而以 CLI (command-line interface) flags 或环境变量的方式实现 etcd 节点的配置。
  • 每个节点可监听多个广播地址。监听的地址由原来的一个扩展到多个，用户可以根据需求实现更加复杂的集群环境，如搭建一个混合了私有云与公有云服务的 etcd 集群。
  • 新增 proxy mode。

2. 规范词汇表

etcd 0.5.0 版首次对 etcd 代码、文档及 CLI 中使用的术语进行了定义。

2.1. node

node 指一个 raft 状态机实例。每个 node 都具有唯一的标识，并在处于 leader 状态时记录其它节点的步进数。

2.2. member

member 指一个 etcd 实例。member 运行在每个 node 上，并向这一 node 上的其它应用程序提供服务。

2.3. Cluster

Cluster 由多个 member 组成。每个 member 中的 node 遵循 raft 共识协议来复制日志。Cluster 接收来自 member 的提案消息，将其提交并存储于本地磁盘。

2.4. Peer

同一 Cluster 中的其它 member。

2.5. Client

Client 指调用 Cluster API 的对象。

3. Raft 共识算法

etcd 集群的工作原理基于 raft 共识算法 (The Raft Consensus Algorithm)。etcd 在 0.5.0 版本中重新实现了 raft 算法，而非像之前那样依赖于第三方库 go-raft 。raft 共识算法的优点在于可以在高效的解决分布式系统中各个节点日志内容一致性问题的同时，也使得集群具备一定的容错能力。即使集群中出现部分节点故障、网络故障等问题，仍可保证其余大多数节点正确的步进。甚至当更多的节点（一般来说超过集群节点总数的一半）出现故障而导致集群不可用时，依然可以保证节点中的数据不会出现错误的结果。

3.1. 集群建立与状态机

raft 集群中的每个节点都可以根据集群运行的情况在三种状态间切换：follower, candidate 与 leader。leader 向 follower 同步日志，follower 只从 leader 处获取日志。在节点初始启动时，节点的 raft 状态机将处于 follower 状态并被设定一个 election timeout，如果在这一时间周期内没有收到来自 leader 的 heartbeat，节点将发起选举：节点在将自己的状态切换为 candidate 之后，向集群中其它 follower 节点发送请求，询问其是否选举自己成为 leader。当收到来自集群中过半数节点的接受投票后，节点即成为 leader，开始接收保存 client 的数据并向其它的 follower 节点同步日志。leader 节点依靠定时向 follower 发送 heartbeat 来保持其地位。任何时候如果其它 follower 在 election timeout 期间都没有收到来自 leader 的 heartbeat，同样会将自己的状态切换为 candidate 并发起选举。每成功选举一次，新 leader 的步进数都会比之前 leader 的步进数大1。

图 3-1 raft 状态切换示意图

3.2. 选举

3.2.1. 一个 candidate 成为 leader 需要具备三个要素：

  • 获得集群多数节点的同意；
  • 集群中不存在比自己步进数更高的 candidate；
  • 集群中不存在其他 leader。

3.2.2. 下面为一个 etcd 集群选举过程的简单描述：

初始状态下集群中的所有节点都处于 follower 状态。

某一时刻，其中的一个 follower 由于没有收到 leader 的 heartbeat 率先发生 election timeout 进而发起选举。

只要集群中超过半数的节点接受投票，candidate 节点将成为即切换 leader 状态。

成为 leader 节点之后，leader 将定时向 follower 节点同步日志并发送 heartbeat。

3.3. 节点异常

集群中各个节点的状态随时都有可能发生变化。从实际的变化上来分类的话，节点的异常大致可以分为四种类型：

  • leader 不可用；
  • follower 不可用；
  • 多个 candidate 或多个 leader；
  • 新节点加入集群。

3.3.1. leader 不可用

下面将说明当集群中的 leader 节点不可用时，raft 集群是如何应对的。

一般情况下，leader 节点定时发送 heartbeat 到 follower 节点。

由于某些异常导致 leader 不再发送 heartbeat ，或 follower 无法收到 heartbeat 。

当某一 follower 发生 election timeout 时，其状态变更为 candidate，并向其他 follower 发起投票。

当超过半数的 follower 接受投票后，这一节点将成为新的 leader，leader 的步进数加1并开始向 follower 同步日志。

当一段时间之后，如果之前的 leader 再次加入集群，则两个 leader 比较彼此的步进数，步进数低的 leader 将切换自己的状态为 follower。

较早前 leader 中不一致的日志将被清除，并与现有 leader 中的日志保持一致。

3.3.2. follower 节点不可用

follower 节点不可用的情况相对容易解决。因为集群中的日志内容始终是从 leader 节点同步的，只要这一节点再次加入集群时重新从 leader 节点处复制日志即可。

集群中的某个 follower 节点发生异常，不再同步日志以及接收 heartbeat。

经过一段时间之后，原来的 follower 节点重新加入集群。

这一节点的日志将从当时的 leader 处同步。

3.3.3. 多个 candidate 或多个 leader

在集群中出现多个 candidate 或多个 leader 通常是由于数据传输不畅造成的。出现多个 leader 的情况相对少见，但多个 candidate 比较容易出现在集群节点启动初期尚未选出 leader 的“混沌”时期。

初始状态下集群中的所有节点都处于 follower 状态。

两个节点同时成为 candidate 发起选举。

两个 candidate 都只得到了少部分 follower 的接受投票。

candidate 继续向其他的 follower 询问。

由于一些 follower 已经投过票了，所以均返回拒绝接受。

candidate 也可能向一个 candidate 询问投票。

在步进数相同的情况下，candidate 将拒绝接受另一个 candidate 的请求。

由于第一次未选出 leader，candidate 将随机选择一个等待间隔（150ms ~ 300ms）再次发起投票。

如果得到集群中半数以上的 follower 的接受，这一 candidate 将成为 leader。

稍后另一个 candidate 也将再次发起投票。

由于集群中已经选出 leader，candidate 将收到拒绝接受的投票。

在被多数节点拒绝之后，并已知集群中已存在 leader 后，这一 candidate 节点将终止投票请求、切换为 follower，从 leader 节点同步日志。

3.4. 日志

3.4.1. 复制

在 raft 集群中，所有日志都必须首先提交至 leader 节点。leader 在每个 heartbeat 向 follower 同步日志，follower 在收到日志之后向 leader 反馈结果，leader 在确认日志内容正确之后将此条目提交并存储于本地磁盘。

首先有一条 uncommitted 的日志条目提交至 leader 节点。

在下一个 heartbeat，leader 将此条目复制给所有的 follower。

当大多数节点记录此条目之后，leader 节点认定此条目有效，将此条目设定为已提交并存储于本地磁盘。

在下一个 heartbeat，leader 通知所有 follower 提交这一日志条目并存储于各自的磁盘内。

3.4.2. 容错

如果由于网络的隔断，造成集群中多数的节点在一段时间内无法访问到 leader 节点。按照 raft 共识算法，没有 leader 的那一组集群将会通过选举投票出新的 leader，甚至会在两个集群内产生不一致的日志条目。在集群重新完整连通之后，原来的 leader 仍会按照 raft 共识算法从步进数更高的 leader 同步日志并将自己切换为 follower。

集群的理想状态。

网络间隔造成大多数的节点无法访问 leader 节点。

新的日志条目添加到 leader 中。

leader 节点将此条日志同步至能够访问到 leader 的节点。

follower 确认日志被记录，但是确认记录日志的 follower 数量没有超过集群节点的半数，leader 节点并不将此条日志存档。

在被隔断的这部分节点，在 election timeout 之后，followers 中产生 candidate 并发起选举。

多数节点接受投票之后，candidate 成为 leader。

一个日志条目被添加到新的 leader。

日志被复制给新 leader 的 follower。

多数节点确认之后，leader 将日志条目提交并存储。

在下一个 heartbeat，leader 通知 follower 各自提交并保存在本地磁盘。

经过一段时间之后，集群重新连通到一起，集群中出现两个 leader 并且存在不一致的日志条目。

新的 leader 在下一次 heartbeat timeout 时向所有的节点发送一次 heartbeat。

#1 leader 在收到步进数更高的 #2 leader heartbeat 时放弃 leader 地位并切换到 follower 状态。

节点中所有未存档的日志条目都将被丢弃。

未被复制的日志条目将会被同步给所有的 follower。

通过这种方式，只要集群中有效连接的节点超过总数的一半，集群将一直以这种规则运行下去并始终确保各个节点中的数据始终一致。

4. 实现

4.1. etcd 结构

一个 etcd 节点的核心由三部分组成：

  • Raft：raft 状态机是对 raft 共识算法的实现
  • WAL：raft 日志存储
  • Storage：数据的存储与索引

WAL (Write-ahead logging)，是用于向系统提供原子性和持久性的一系列技术。在使用 WAL 的系提供中，所有的修改在提交之前都要先写入 log 文件中。etcd 的 WAL 由日志存储与快照存储两部分组成，其中 Entry 负责存储具体日志的内容，而 Snapshot 负责在日志内容发生变化的时候保存 raft 的状态。WAL 会在本地磁盘的一个指定目录下分别日志条目与快照内容。

4.2. 服务

4.2.1. Clients

在默认设定下，etcd 通过主机的 2379 端口向 Client 提供服务。如下图：

每个主机上的应用程序都可以通过主机的 2379 以 HTTP + JSON 的方式向 etcd 读写数据。写入的数据会由 etcd 同步到集群的其它节点中。

4.2.2. Peers

在默认设定下，etcd 通过主机的 2380 端口在各个节点中同步 raft 状态及数据。

5. 创建

从方法上来划分，创建 etcd 集群的方式分为两种：Static （通过制定 peers 的 IP 和端口创建）与 Discovery （通过一个发现服务创建）。

Static 方式需要预先知道集群所有节点的 IP，所以适合小规模的集群或者搭建一个临时的开发与测试环境。

Discovery 方式不需要预先了解其他节点的 IP。启动时 etcd 通过访问一个 Discovery URL 来注册自己并获取其他节点的信息。这种方式通常适合将 etcd 部署在某个云服务平台或是一个 DHCP 环境中。其中 Discovery 服务可以使用 CoreOS 提供的一个公共地址 https://discovery.etcd.io/new 来申请一个 token，或者自己搭建一个这样的服务并设定一个 token。出于安全的考虑，这个 token 应该只在集群初始引导时短暂存在，因为集群建立之后将不再需要这一地址，而集群中节点的变更可以通过 etcd 运行时重构的能力来进行配置。

6. 运行

下面我们尝试使用 etcd 0.5.0 以 discovery 方式创建一个 CoreOS 集群。当然由于 etcd 0.5.0 尚未正式发布，所以我们目前还无法从官方渠道获得打包 etcd 0.5.0 的 CoreOS 镜像，但是我们可以修改引导文件，在 CoreOS 启动时将 etcd 0.5.0 下载至系统里进行配置并启动。

CoreOS 官方提供了一个使用 vagrant + virtualbox 项目，供用户在本地电脑中创建一个微型 CoreOS 集群。我们可以在这个项目的基础上进行修改来实现我们的需求。

6.1. Clone 项目到本地



    

  1. git clone
    2. 

  2. https://github.com/coreos/coreos-vagrant.git
    3. 

  3. cd coreos-vagrant
    4. 

  4. cp config.rb.sample config.rb
    5. 

  5. cp user-data.sample user-data.sample
    6. 



6.2. 通过 CoreOS 提供的公共 discovery 服务申请 token


curl https://discovery.etcd.io/new?size=3


https://discovery.etcd.io/780456e1317eb2db312b62ba1cb9a4f7


size = 3 表示这个集群节点总数为 3 个。


6.3. 修改 config.rb 文件




    

  1. # Size of the CoreOS cluster created by Vagrant
    2. 

  2. $num_instances=3
    3. 



将启动的 CoreOS 实例数量定为 3 个


6.4. 修改 user-data 文件


6.4.1. 修改 etcd 参数：




    

  1. etcd:
    2. 

  2. discovery: https://discovery.etcd.io/780456e1317eb2db312b62ba1cb9a4f7
    3. 

  3. advertise-client-urls: http://$public_ipv4:2379
    4. 

  4. initial-advertise-peer-urls: http://$public_ipv4:2380
    5. 

  5. listen-client-urls: http://$public_ipv4:2379
    6. 

  6. listen-peer-urls: http://$public_ipv4:2380
    7. 



6.4.2. 修改 etcd 服务内容




    

  1. - name: etcd.service
    2. 

  2. command: start
    3. 

  3. content: |
    4. 

  4. [Unit]
    5. 

  5. After=network-online.target
    6. 

  6. Requires=network-online.target
    7. 

  7. [Service]
    8. 

  8. ExecStartPre=/usr/bin/wget -N -P /opt/bin https://github.com/coreos/etcd/releases/
    9. 

  9. download/v0.5.0-alpha.3/etcd-v0.5.0-alpha.3-linux-amd64.tar.gz
    10. 

  10. ExecStartPre=/usr/bin/tar -C /opt/bin -xvf /opt/bin/etcd-v0.5.0-alpha.3-linux-amd64.tar.gz
    11. 

  11. ExecStartPre=/usr/bin/chmod +x /opt/bin/etcd-v0.5.0-alpha.3-linux-amd64/etcd
    12. 

  12. ExecStart=/opt/bin/etcd-v0.5.0-alpha.3-linux-amd64/etcd
    13. 

  13.  
    14. 

  14. [Install]
    15. 

  15. WantedBy=multi-user.target
    16. 



修改的部分让我们重新定制了 etcd 服务的内容。在系统启动时，先将 etcd 0.5.0 的打包文件下载至指定目录并在稍后将其启动。


6.4.3. 使用 vagrant 启动集群




    

  1. vagrant up
    2. 



稍后 vagrant 将帮助我们在 VirtualBox 中创建三个 CoreOS 实例。


6.4.4. 登录到 CoreOS


登录到其中的一个节点




    

  1. vagrant ssh core-01
    2. 



查看一下 etcd.service 的状态，输入：




    

  1. systemctl status etcd.service
    2. 



不出意外的话，可以看到其状态为 active (running)




    

  1. etcd.service
    2. 

  2. Loaded: loaded (/etc/systemd/system/etcd.service; disabled)
    3. 

  3. Drop-In: /run/systemd/system/etcd.service.d
    4. 

  4. └─20-cloudinit.conf
    5. 

  5. Active: active (running) since Sun 2014-11-16 13:10:59 UTC; 12min ago
    6. 

  6. Process: 894 ExecStartPre=/usr/bin/chmod +x /opt/bin/etcd-v0.5.0-alpha.3-
    7. 

  7. linux-amd64/etcd (code=exited, status=0/SUCCESS)
    8. 

  8. Process: 890 ExecStartPre=/usr/bin/tar -C /opt/bin -xvf /opt/bin/etcd-
    9. 

  9. v0.5.0-alpha.3-linux-amd64.tar.gz (code=exited, status=0/SUCCESS)
    10. 

  10. Process: 857 ExecStartPre=/usr/bin/wget -N -P /opt/bin
    11. 

  11. https://github.com/coreos/etcd/releases/download/v0.5.0-alpha.3/etcd-v0.5.0
    12. 

  12. -alpha.3-linux-amd64.tar.gz (code=exited, status=0/SUCCESS)
    13. 

  13. Main PID: 896 (etcd)
    14. 

  14. CGroup: /system.slice/etcd.service
    15. 

  15. └─896 /opt/bin/etcd-v0.5.0-alpha.3-linux-amd64/etcd
    16. 



6.4.5. 通过 etcdctl 查询集群状态


etcdctl 可以帮助我们查询一下集群中节点信息，输入：




    

  1. /opt/bin/etcd-v0.5.0-alpha.3-linux-amd64/etcdctl --peers 172.17.8.101:2379 member list
    2. 



启动参数 --peers 172.17.8.101:2379 表示通过本节点的 2379 端口访问 etcd 接口，用户可以根据自己的实际情况对 IP 地址进行修正。


正常情况下可看到如下输出：




    

  1. b4f4d25ed56d7a44: name=b74c24773df147e1be8e1e35defaad38 peerURLs=
    2. 

  2. http://172.17.8.101:2380 clientURLs=http://172.17.8.101:2379
    3. 

  3. b7404cc414e7affa: name=001db0fc02184af5b293e2cb21c86a11 peerURLs=
    4. 

  4. http://172.17.8.102:2380 clientURLs=http://172.17.8.102:2379
    5. 

  5. f609956c55a6809e: name=2840dc331d224360a097b781c876c9e5 peerURLs=
    6. 

  6. http://172.17.8.103:2380 clientURLs=http://172.17.8.103:2379
    7. 



这样，我们就在本地创建了一个基于 etcd 0.5.0 的 CoreOS 集群。


7. 预告


作为 CoreOS 及管理工具介绍的第三部分，笔者将向大家介绍 CoreOS 集群的重要管理工具 fleet ，通过 fleet 用户可以在 CoreOS 实现简单的 Orchestration 功能，敬请期待。


原文发布时间：2014-11-21


本文来自云栖合作伙伴“linux中国”
				


				
时间： 2024-04-25 22:52:53

		
		


		


	

	
	

		


		
CoreOS 实战：剖析 etcd的相关文章


								

		

			

                CoreOS 实战：CoreOS 及管理工具介绍
			

		

		

									

				CoreOS 实战:CoreOS 及管理工具介绍 [编者按]CoreOS是一个基于Docker的轻量级容器化Linux发行版,专为大型数据中心而设计,旨在通过轻量的系统架构和灵活的应用程序部署能力简化数据中心的维护成本和复杂度.CoreOS作为Docker生态圈中的重要一员,日益得到各大云服务商的重视,目前已经完成了A轮融资,发展风头正劲.InfoQ希望<CoreOS实战>系列文章能够帮助读者了解CoreOS以及相关的使用方法.如果说Docker是下一代的虚拟机,那CoreOS就应该是下一代的			

		

	

				

		

			

                CIO实战剖析：13步设计出一个ITSM系统
			

		

		

									

				这是我一直想写的内容,本来是希望把这个项目从立项到规划,到设计开发,到最后的实施应用的全部过程写成一个笔记,但工程浩大,就先把我们规划这款http://www.aliyun.com/zixun/aggregation/13823.html">ITSM系统的想法写出来,里面会夹杂着我对这类系统的深入思考. 这种考虑一是基于对ITIL的理解,二是对软件实现的理解,三是运维管理的考量.内容不会十分具体,因为每一个部份基本都是一个模块,如果写得深入,就是一个详细的设计说明书了.下面逐步展开说明.			

		

	

				

		

			

                CoreOS实践指南（六）：分布式数据存储Etcd（下）
			

		

		

									

				注:本文首发于CSDN,转载请标明出处. [编者按]在"漫步云端:CoreOS实践指南"系列第五篇: 分布式数据存储Etcd(上)中,ThoughtWorks的软件工程师林帆从系统运维工作者的角度介绍了Etcd的操作和API的使用.本文为分布式数据存储Etcd的下篇.Etcd是CoreOS生态系统中处于连接各个节点通信和支撑集群服务协同运作的核心地位的模块,这篇文章将主要介绍Etcd的RESTful API.如果说Etcd数据存储服务是CoreOS分布式架构的基石,那么Etcd的RES			

		

	

				

		

			

                漫步云端：CoreOS实践指南（一）
			

		

		

									

				[编者按]Docker和CoreOS都是硅谷创业孵化器的优秀"毕业生",据说两家老板的私交很好,Docker做容器引擎,CoreOS做容器管理,合作得非常愉快,只是随着Rocket的发布逐步"分道扬镳".虽然Docker和CoreOS都在求"简",但是Docker的"简"是力求用户能达到最简便地使用,CoreOS的"简"是追求极致的轻量化,究竟哪个将是Container技术的未来,其实也很难说.今天开始,来			

		

	

				

		

			

                CoreOS Fest 系列之第一篇：容器江湖
			

		

		

									

				本文讲的是CoreOS Fest 系列之第一篇:容器江湖,[编者的话] 这是总结 CoreOS Fest 大会的三篇文章之一,主要介绍了 CoreOS 公司与 Docker 公司之争,新成立的 appc 规范委员会, Tectonic 平台, Kubernetes 项目. 最近在旧金山, Linux 容器已经显得非常有「钱」景,看起来每个人都想从这个有几十亿美金规模的新市场中分得一杯羹.多家创业公司和云主机公司已经或者即将召开有关容器的大会,包括 4 月 17 日召开的 Container Ca			

		

	

				

		

			

                新一代etcd：etcd3
			

		

		

									

				本文讲的是新一代etcd:etcd3[编者的话]李响,CoreOS工程师,负责CoreOS分布式系统相关项目开发,对分布式一致协议.存储.调度等有很多研究.他是分布式一致性存储系统etcd的作者和开发者.他对容器生态系统也有较多的贡献,目前主要关注提升Kubeternetes的集群规模和调度系统.另外,他也是开源倡导者和go语言的推广者. 在过去的几个月中,CoreOS致力于完善etcd3 API的beta版,经过对系统的严格测试并且在一些用户的共同协作下,etcd得到了长足的进步.今天etcd			

		

	

				

		

			

                CoreOS Linux，为中国用户提供创新型容器技术
			

		

		

									

				诞生于2013年7月1日的CoreOS Linux马上即将度过"三岁生日".该项目最初以"为驱动互联网所需的基础结构提供保护"为使命,通过为服务器和集群提供自动化的软件更新,让互联网的"大后方"更安全.考虑到很多管理员在配置好服务器之后就永远不再改动,CoreOS认为只有通过为服务器提供自动化的软件更新,才能让让整个互联网更安全. 近日,CoreOS Linux已面向中国发布.通过与世纪互联运营的Microsoft Azure合作,CoreOS为			

		

	

				

		

			

                CoreOS，一款Linux容器发行版
			

		

		

									

				CoreOS,一款最新的 Linux 发行版本,支持自动升级内核软件,提供各集群间配置的完全控制. 关于使用哪个版本的 Linux 服务器系统的争论,常常是以这样的话题开始的: 你是喜欢基于 Red Hat Enterprise Linux (RHEL) 的 CentOS 或者 Fedora,还是基于 Debian 的 Ubuntu,抑或 SUSE 呢? 但是现在,一款名叫 CoreOS 容器 Linux 的 Linux 发行版加入了这场"圣战".这个最近在 Linode 服务器上提供			

		

	

				

		

			

                CoreOS 继续推进 Docker 容器替代 Rockets
			

		

		

									

				企业Linux发行版项目CoreOS因为不满Docker的现状而在去年底宣布开发替代容器Rocket.CoreOS发行版的特别之处是它试图解决服务器维护的一大难题--更新,它利用了双缓存回滚更新的方法解决更新中遇到的问题.eWeek报道了CoreOS项目的近况: CoreOS 平台的核心部分是etcd系统,它提供了共享配置和调度器协调功能,由一个分布式.一致性key-value存储启用.1月28日,CoreOS宣布了 etcd 2.0版本,而上一个版本是 0.4.6.版本号大跃进的原因是Core