etcd概述和相关命令

# 什么是etcd
> 官方原话：  
A highly-available key value store for shared configuration and service discovery.

# etcd的特点
- **简单**：基于HTTP+JSON的API让你用curl就可以轻松使用。  
- **安全**：可选SSL客户认证机制。  
- **快速**：每个实例每秒支持一千次写操作。  
- **可信**：使用Raft算法充分实现了分布式。

# etcd概念词汇表
- **Raft**：etcd所采用的保证分布式系统强一致性的算法。
- **Node**：一个Raft状态机实例。
- **Member**： 一个etcd实例。它管理着一个Node，并且可以为客户端请求提供服务。
- **Cluster**：由多个Member构成可以协同工作的etcd集群。
- **Peer**：对同一个etcd集群中另外一个Member的称呼。
- **Client**： 向etcd集群发送HTTP请求的客户端。
- **WAL**：预写式日志，etcd用于持久化存储的日志格式。
- **snapshot**：etcd防止WAL文件过多而设置的快照，存储etcd数据状态。
- **Proxy**：etcd的一种模式，为etcd集群提供反向代理服务。
- **Leader**：Raft算法中通过竞选而产生的处理所有数据提交的节点。
- **Follower**：竞选失败的节点作为Raft中的从属节点，为算法提供强一致性保证。
- **Candidate**：当Follower超过一定时间接收不到Leader的心跳时转变为Candidate开始竞选。
- **Term**：某个节点成为Leader到下一次竞选时间，称为一个Term。
- **Index**：数据项编号。Raft中通过Term和Index来定位数据。

# etcd部署要求
etcd作为一个高可用键值存储系统，天生就是为集群化而设计的。

由于Raft算法在做决策时需要多数节点的投票，所以etcd一般部署集群推荐奇数个节点，推荐的数量为3、5或者7个节点构成一个集群。

# etcd集群启动方式
etcd有三种集群化启动的配置方案，分别为：

- 静态配置启动  
- etcd自身服务发现  
- 通过DNS进行服务发现

# etcd相关命令
## 相看集群是否健康
```
#!/bin/bash

etcdctl --endpoint https://192.168.2.240:2379   \
--ca-file=/etc/kubernetes/pki/etcd-ca.pem        \
--cert-file=/etc/kubernetes/pki/etcd-server.pem    \
--key-file=/etc/kubernetes/pki/etcd-server-key.pem \
cluster-health
```
## 备份etcd数据
```
ETCDCTL_API=3 \
ETCDCTL_CERT="/etc/kubernetes/pki/etcd-server.pem" \
ETCDCTL_KEY="/etc/kubernetes/pki/etcd-server-key.pem" \
ETCDCTL_CACERT="/etc/kubernetes/pki/etcd-ca.pem" \
/opt/bin/etcdctl --endpoints=https://192.168.2.240:2379 snapshot save  my.db
```

## etcd访问脚本
```
cat etcdctl.sh
#!/bin/bash

ETCDCTL_API=3 etcdctl --endpoints "https://192.168.1.209:2379,https://192.168.1.210:2379,https://192.168.1.211:2379"  \
--cacert=/etc/kubernetes/pki/etcd-ca.pem \
--cert=/etc/kubernetes/pki/etcd-server.pem \
--key=/etc/kubernetes/pki/etcd-server-key.pem \
$*
```

```
sh etcdctl.sh member list

# 查看此节点是否是leader

curl --insecure https://192.168.1.209:2379/v2/stats/leader

# 查看etcd节点的 metrics

curl --insecure https://192.168.1.209:2379/metrics
```

# etcd调优

## 磁盘
etcd 的存储目录分为 snapshot 和 wal，他们写入的方式是不同的，snapshot 是内存直接 dump file。而 wal 是顺序追加写，对于这两种方式系统调优的方式是不同的，snapshot 可以通过增加 io 平滑写来提高磁盘 io 能力，而 wal 可以通过降低 pagecache 的方式提前写入时序。因此对于不同的场景，可以考虑将 snap 与 wal 进行分盘，放在两块 SSD 盘上，提高整体的 IO 效率，这种方式可以提升 etcd 20% 左右的性能。

etcd 集群对磁盘 I/O 的延时非常敏感，因为 Etcd 必须持久化它的日志，当其他 I/O 密集型的进程也在占用磁盘 I/O 的带宽时，就会导致 fsync 时延非常高。这将导致 Etcd 丢失心跳包、请求超时或暂时性的 Leader 丢失。这时可以适当为 Etcd 服务赋予更高的磁盘 I/O 权限，让 Etcd 更稳定的运行。在 Linux 系统中，磁盘 I/O 权限可以通过 ionice 命令进行调整。

nux 默认 IO 调度器使用 CFQ 调度算法，支持用 ionice 命令为程序指定 IO 调度策略和优先级，IO 调度策略分为三种：

- **Idle** ：其他进程没有磁盘 IO 时，才进行磁盘 IO
- **Best Effort**：缺省调度策略，可以设置 0-7 的优先级，数值越小优先级越高，同优先级的进程采用 round-robin 算法调度；
- **Real Time** ：立即访问磁盘，无视其它进程 IO
None 即 Best Effort，进程未指定策略和优先级时显示为 none，会使用依据 cpu nice 设置计算出优先级
Linux 中 etcd 的磁盘优先级可以使用 ionice 配置：
```
$ ionice -c2 -n0 -p `pgrep etcd`
```

参考：  
https://cloud.tencent.com/developer/article/1520057
https://bingohuang.com/etcd-benchmark/
https://www.cnblogs.com/bakari/p/10515977.html

# etcd 故障排查
etcd 故障排查之 `failed to send out heartbeat on time`

etcd使用了raft算法，leader会定时地给每个follower发送心跳，如果leader连续两个心跳时间没有给follower发送心跳，etcd会打印这个log以给出告警。
通常情况下这个issue是disk运行过慢导致的，leader一般会在心跳包里附带一些metadata，leader需要先把这些数据固化到磁盘上，然后才能发送。
写磁盘过程可能要与其他应用竞争，或者因为磁盘是一个虚拟的或者是SATA类型的导致运行过慢，此时只有更好更快磁盘硬件才能解决问题。
etcd暴露给Prometheus的metrics指标walfsyncduration_seconds就显示了wal日志的平均花费时间，通常这个指标应低于10ms。

第二种原因就是CPU计算能力不足。
如果是通过监控系统发现CPU利用率确实很高，就应该把etcd移到更好的机器上，然后通过cgroups保证etcd进程独享某些核的计算能力，或者提高etcd的priority。

第三种原因就可能是网速过慢。
如果Prometheus显示是网络服务质量不行，譬如延迟太高或者丢包率过高，那就把etcd移到网络不拥堵的情况下就能解决问题。但是如果etcd是跨机房部署的，长延迟就不可避免了，那就需要根据机房间的RTT调整heartbeat-interval，而参数election-timeout则至少是heartbeat-interval的5倍。

# 参考
https://www.jianshu.com/p/66e2a0cd93d5

导航

最近发表

友情链接