etcd工作原理和部署指南

etcd工作原理和部署指南_第1张图片
etcd-logo.png

​ 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.增加节点,读性能会提升,写性能会下降,减少节点,写性能会提升。

部署

单机节点(CentOS 7)

$ yum install etcd -y 
修改配置文件,通过yum 安装的etcd,以下是etcd的配置文件:

$ vim /etc/etcd/etcd.conf 
#[Member]
#ETC D_CORS=""
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
#ETCD_WAL_DIR=""
#ETCD_LISTEN_PEER_URLS="http://localhost:2380"
ETCD_LISTEN_CLIENT_URLS="http://192.168.1.109:2379"
#ETCD_MAX_SNAPSHOTS="5"
#ETCD_MAX_WALS="5"
ETCD_NAME="default"
#ETCD_SNAPSHOT_COUNT="100000"
#ETCD_HEARTBEAT_INTERVAL="100"
#ETCD_ELECTION_TIMEOUT="1000"
#ETCD_QUOTA_BACKEND_BYTES="0"
#ETCD_MAX_REQUEST_BYTES="1572864"
#ETCD_GRPC_KEEPALIVE_MIN_TIME="5s"
#ETCD_GRPC_KEEPALIVE_INTERVAL="2h0m0s"
#ETCD_GRPC_KEEPALIVE_TIMEOUT="20s"
#
#[Clustering]
#ETCD_INITIAL_ADVERTISE_PEER_URLS="http://localhost:2380"
ETCD_ADVERTISE_CLIENT_URLS="http://192.168.1.109:2379"
#ETCD_DISCOVERY=""
#ETCD_DISCOVERY_FALLBACK="proxy"
#ETCD_DISCOVERY_PROXY=""
#ETCD_DISCOVERY_SRV=""
#ETCD_INITIAL_CLUSTER="default=http://localhost:2380"
#ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
#ETCD_INITIAL_CLUSTER_STATE="new"
#ETCD_STRICT_RECONFIG_CHECK="true"
#ETCD_ENABLE_V2="true"
#
#[Proxy]
#ETCD_PROXY="off"
#ETCD_PROXY_FAILURE_WAIT="5000"
#ETCD_PROXY_REFRESH_INTERVAL="30000"
#ETCD_PROXY_DIAL_TIMEOUT="1000"
#ETCD_PROXY_WRITE_TIMEOUT="5000"
#ETCD_PROXY_READ_TIMEOUT="0"
#
#[Security]
#ETCD_CERT_FILE=""
#ETCD_KEY_FILE=""
#ETCD_CLIENT_CERT_AUTH="false"
#ETCD_TRUSTED_CA_FILE=""
#ETCD_AUTO_TLS="false"
#ETCD_PEER_CERT_FILE=""
#ETCD_PEER_KEY_FILE=""
#ETCD_PEER_CLIENT_CERT_AUTH="false"
#ETCD_PEER_TRUSTED_CA_FILE=""
#ETCD_PEER_AUTO_TLS="false"
#
#[Logging]
#ETCD_DEBUG="false"
#ETCD_LOG_PACKAGE_LEVELS=""
#ETCD_LOG_OUTPUT="default"
#
#[Unsafe]
#ETCD_FORCE_NEW_CLUSTER="false"
#
#[Version]
#ETCD_VERSION="false"
#ETCD_AUTO_COMPACTION_RETENTION="0"
#
#[Profiling]
#ETCD_ENABLE_PPROF="false"
#ETCD_METRICS="basic"
#
#[Auth]
#ETCD_AUTH_TOKEN="simple"

参数说明:

  • –data-dir:指定节点的数据存储目录,若不指定,则默认是当前目录。这些数据包括节点ID,集群ID,集群初始化配置,Snapshot文件,若未指 定–wal-dir,还会存储WAL文件
  • –wal-dir:指定节点的was文件存储目录,若指定了该参数,wal文件会和其他数据文件分开存储
  • –name:节点名称
  • –initial-advertise-peer-urls:告知集群其他节点的URL,tcp2380端口用于集群通信
  • –listen-peer-urls:监听URL,用于与其他节点通讯
  • –advertise-client-urls:告知客户端的URL, 也就是服务的URL,tcp2379端口用于监听客户端请求
  • –initial-cluster-token:集群的ID
  • –initial-cluster:集群中所有节点
  • –initial-cluster-state:集群状态,new为新创建集群,existing为已存在的集群
  • etcd 默认存储大小限制是 2GB, 可以通过 --quota-backend-bytes 标记配置,最大支持 8GB.

启动etcd服务

$ systemctl start etcd.service
$ systemctl status etcd.service
● etcd.service - Etcd Server
   Loaded: loaded (/usr/lib/systemd/system/etcd.service; disabled; vendor preset: disabled)
   Active: active (running) since 六 2018-06-02 22:17:34 CST; 9s ago
 Main PID: 2876 (etcd)
   CGroup: /system.slice/etcd.service
           └─2876 /usr/bin/etcd --name=default --data-dir=/var/lib/etcd/default.etcd --listen-client-urls=http://192.168.1.109:2379

多节点部署

自定义的 etcd discovery 服务

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

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

$ curl -X PUT https://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83/_config/size -d value=3

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

接下来你在 3 个节点上分别启动 etcd 程序,并加上刚刚的 token。
加 token 的方式同样也有 命令行参数环境变量 两种。

命令行参数:

-discovery https://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83

环境变量

ETCD_DISCOVERY=https://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83

命令行参数启动方式为例:

$ etcd -name etcd0 -initial-advertise-peer-urls http://10.0.1.10:2380 \
  -listen-peer-urls http://10.0.1.10:2380 \
  -listen-client-urls http://10.0.1.10:2379,http://127.0.0.1:2379 \
  -advertise-client-urls http://10.0.1.10:2379 \
  -discovery https://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83
$ etcd -name etcd1 -initial-advertise-peer-urls http://10.0.1.11:2380 \
  -listen-peer-urls http://10.0.1.11:2380 \
  -listen-client-urls http://10.0.1.11:2379,http://127.0.0.1:2379 \
  -advertise-client-urls http://10.0.1.11:2379 \
  -discovery https://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83
$ etcd -name etcd2 -initial-advertise-peer-urls http://10.0.1.12:2380 \
  -listen-peer-urls http://10.0.1.12:2380 \
  -listen-client-urls http://10.0.1.12:2379,http://127.0.0.1:2379 \
  -advertise-client-urls http://10.0.1.12:2379 \
  -discovery https://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83

测试

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

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

  • Google云计算引擎
  • 3台8个vCPU + 16GB内存+ 50GB固态硬盘
  • 1台机器(客户端),16个vCPU + 30GB内存+ 50GB SSD
  • Ubuntu 17.04
  • etcd 3.2.0,去1.8.3

有了这个配置,etcd可以大致写出:

密钥数量 密钥大小(字节) 值大小以字节为单位 连接数 客户数量 目标ETCD服务器 平均写入QPS 每个请求的平均延迟 平均服务器RSS
8 256 1 1 只有领导者 583 1.6毫秒 48 MB
100000 8 256 100 1000 只有领导者 44341 22毫秒 124MB
100000 8 256 100 1000 所有成员 50104 20ms的 126MB

示例命令是:

# write to leader
benchmark --endpoints=${HOST_1} --target-leader --conns=1 --clients=1 \
    put --key-size=8 --sequential-keys --total=10000 --val-size=256
benchmark --endpoints=${HOST_1} --target-leader  --conns=100 --clients=1000 \
    put --key-size=8 --sequential-keys --total=100000 --val-size=256

# write to all members
benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=100 --clients=1000 \
    put --key-size=8 --sequential-keys --total=100000 --val-size=256

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

请求数 密钥大小(字节) 值大小以字节为单位 连接数 客户数量 一致性 平均读取QPS 每个请求的平均延迟
8 256 1 1 线性化 1,353 为0.7ms
8 256 1 1 序列化 2909 0.3ms的
100000 8 256 100 1000 线性化 141578 5.5ms
100000 8 256 100 1000 序列化 185758 时间为2.2ms

示例命令是:

# Single connection read requests
benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=1 --clients=1 \
    range YOUR_KEY --consistency=l --total=10000
benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=1 --clients=1 \
    range YOUR_KEY --consistency=s --total=10000

# Many concurrent read requests
benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=100 --clients=1000 \
    range YOUR_KEY --consistency=l --total=100000
benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=100 --clients=1000 \
    range YOUR_KEY --consistency=s --total=100000

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

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

  • 关于对Raft算法原理参考链接:

    • InfoQ:Raft 一致性算法论文译文

      http://www.infoq.com/cn/articles/raft-paper

      知乎:raft算法与paxos算法相比有什么优势,使用场景有什么差异?

      https://www.zhihu.com/question/36648084

      Raft算法动画:经典的Raft算法动画演示链接

      http://thesecretlivesofdata.com/raft/

你可能感兴趣的:(etcd工作原理和部署指南)