etcd 集群备份/恢复/性能测试

• 备份/恢复数据

  • 备份数据

etcdctl snapshot save snapshot.db --cacert="/etc/ssl/etcd/ssl/ca.pem" --cert="/etc/ssl/etcd/ssl/admin-kube-master-172-16-100-226.pem" --key="/etc/ssl/etcd/ssl/admin-kube-master-172-16-100-226-key.pem"

• 恢复数据(新建集群)

etcdctl snapshot restore /root/snapshot.db --name etcd1 --initial-cluster \

etcd1=https://172.16.100.248:2380,etcd2=https://172.16.100.249:2380,etcd3=https://172.16.100.250:2380 \

--initial-cluster-token k8s_etcd --initial-advertise-peer-urls https://172.16.100.248:2380 \

--cert="/etc/ssl/etcd/etcd.pem" --key="/etc/ssl/etcd/etcd-key.pem" --cacert="/etc/ssl/etcd/ca.pem" \

--data-dir=/root/etcd/data --wal-dir=/root/etcd/wal

1. 新建一个etcd集群，将data目录设置成数据保存目录(建议多个节点修改完成之后同时启动)
   1. 修改ETCD_INITIAL_CLUSTER_TOKEN
   2. 修改ETCD_DATA_DIR

• 恢复数据(在老集群)

1. 停止数据写入(比如在k8s里需要停止apiserver)

etcdctl snapshot restore /root/snapshot.db --name kube-master-1 \

--initial-cluster kube-master-1=https://172.20.0.11:2380,kube-master-2=https://172.20.0.12:2380,kube-master-3=https://172.20.0.13:2380 \

--initial-cluster-token etcd-server-cluster --initial-advertise-peer-urls https://172.20.0.11:2380 \

--cert /var/lib/etcd/ssl/etcd.crt --key /var/lib/etcd/ssl/etcd.key --cacert /var/lib/etcd/ssl/ca.crt \

--data-dir=/root/etcd/data --wal-dir=/root/etcd/wal

1. 将data和wal目录覆盖旧目录(每个节点都需要复制)，还原数据目录注意修改name
2. 重启服务

---

• ETCD集群性能测试

etcd 提供稳定的，持续的高性能。两个定义性能的因素：延迟(latency)和吞吐量(throughput)。延迟是完成操作的时间。吞吐量是在某个时间期间之内完成操作的总数量.

当 etcd 接收并发客户端请求时，通常平均延迟随着总体吞吐量增加而增加。在通常的云环境，比如 Google Compute Engine (GCE) 标准的 n-4 或者 AWS 上相当的机器类型，一个三成员 etcd 集群在轻负载下可以在低于1毫秒内完成一个请求，并在重负载下可以每秒完成超过 30000 个请求。

etcd 使用 Raft 一致性算法来在成员之间复制请求并达成一致。一致性性能，特别是提交延迟，受限于两个物理约束：网络IO延迟和磁盘IO延迟。

完成一个etcd请求的最小时间是成员之间的网络往返时延(Round Trip Time / RTT)，加需要提交数据到持久化存储的 fdatasync 时间。

在一个数据中心内的 RTT 可能有数百毫秒。在美国典型的 RTT 是大概 50ms, 而在大陆之间可以慢到400ms. 旋转硬盘(注：指传统机械硬盘)的典型 fdatasync 延迟是大概 10ms .

对于 SSD 硬盘, 延迟通常低于 1ms, 为了提高吞吐量, etcd 将多个请求打包在一起并提交给 Raft。这个批量策略让 etcd 在重负载试获得高吞吐量.

有其他子系统影响到 etcd 的整体性能。每个序列化的 etcd 请求必须通过 etcd 的 boltdb支持的(boltdb-backed) MVCC 存储引擎,它通常需要10微秒来完成。etcd 定期递增快照它最近实施的请求，将他们和之前在磁盘上的快照合并。这个过程可能导致延迟尖峰(latency spike)。虽然在SSD上这通常不是问题，在HDD上它可能加倍可观察到的延迟。而且，进行中的压缩可以影响 etcd 的性能。幸运的是，压缩通常无足轻重，因为压缩是错开的，因此它不和常规请求竞争资源。RPC 系统，gRPC，为 etcd 提供定义良好，可扩展的 API，但是它也引入了额外的延迟，尤其是本地读取。

 

工具 benchmark (etcd/tools/benchmark)

https://github.com/etcd-io/etcd/tree/master/tools/benchmark

对于某些基线性能数字，我们考虑的是3成员 etcd 集群，带有下列硬件配置：

• 线性读测试

 

benchmark --endpoints=https://172.20.0.11:2381 --conns=100 --clients=1000 \

range key --total=100000 --consistency=l --cert /var/lib/etcd/ssl/etcd.crt \

--key /var/lib/etcd/ssl/etcd.key --cacert /var/lib/etcd/ssl/ca.crt

• 串行读

benchmark --endpoints=https://172.20.0.11:2381 --conns=100 --clients=1000 \

range key --total=100000 --consistency=s --cert /var/lib/etcd/ssl/etcd.crt \

--key /var/lib/etcd/ssl/etcd.key --cacert /var/lib/etcd/ssl/ca.crt

• 写

benchmark --endpoints=https://172.20.0.11:2379,https://172.20.0.12:2379,https://172.20.0.13:2379 \

--conns=100 --clients=1000 put --key-size=8 --sequential-keys --total=100000 --val-size=256 --cert \

/var/lib/etcd/ssl/etcd.crt --key /var/lib/etcd/ssl/etcd.key --cacert /var/lib/etcd/ssl/ca.crt