当前位置：首页 > news >正文

分布式存储之 etcd 的集群管理

news 来源：原创 2024/4/27 6:20:43

在分布式文件存储中，我们通常会面临集群选主，配置共享和节点状态监控的问题。通过 etcd（基于 Raft 协议)）可以实现超大规模集群的管理，以及多节点的服务可靠性。今天，我们就聊聊 etcd 在分布式存储中的具体应用。

什么是 etcd ?

etcd 是由 CoreOS 公司开发的一个开源的分布式 KV 存储，主要用于服务发现、共享配置以及一致性保障。etcd 的灵感来自于 ZooKeeper 和 Doozer，但它更侧重以下几点：

简单：安装配置简单，支持 curl 方式的用户 API (HTTP+JSON)。
安全：可选支持 SSL 客户端证书验证。
快速：根据官方提供的 benchmark 数据，单实例支持每秒 1w+ 写操作。
可靠：采用 Raft 算法，实现分布式系统数据的可用性和一致性。

为什么采用 etcd ?

谈到 etcd，我们不免会与 Zookeeper（以下简称 ZK）或 Consul 进行比较，Consul 的可靠性和稳定性还需要时间来验证（项目发起方自己也并未使用）；ZK 和 etcd 都是顺序一致性的（满足 CAP 的 CP），这就意味着无论我们访问任意节点，都将获得最终一致的数据视图。对比 ZK， etcd 具有以下优势：

一致性：etcd 使用 Raft 协议，简单易懂，而 ZK 使用 ZAB（类 paxos 协议)，该协议以复杂著称，尤其对初学者来说。
运维方面：etcd 比 ZK 更容易运维。
项目活跃度：etcd 社区比较活跃，代码贡献者超 700 人，目前一直在更新。而 ZK 社区相比活跃度不是那么高，代码贡献者 170 多人，版本很久没有更新。
接口方面：etcd 提供了 http + json，grpc 接口，支持跨平台。而 ZK 需要使用其专属客户端。
安全性：etcd 支持 https 访问，ZK 在这方面缺失。

etcd 架构及工作原理

etcd 架构图

网络层 HTTP Server：用于处理用户发送的 API 请求以及其它 etcd 节点的同步与心跳信息请求。
Raft 模块：Raft 强一致性算法的具体实现，是 etcd 的核心。
Store 模块：涉及 KV 存储、WAL 文件、Snapshot 管理等，用户处理 etcd 支持的各类功能的事务，包括数据索引节点状态变更、监控与反馈、事件处理与执行，是 etcd 对用户提供的大多数 API 功能的具体实现。
副本状态机：这是一个抽象的模块，状态机的数据维护在内存中，定期持久化到磁盘，每次写请求都会持久化到 WAL 文件，并根据写请求的内容修改状态机数据。

etcd 工作原理

etcd 集群是一个分布式系统，由多个节点相互通信构成整体对外服务。每个节点都存储了完整的数据，并且通过 Raft 协议保证每个节点维护数据的一致性。在 Raft 协议中，有一个强 leader，由它全权负责接收客户端的请求命令，并将命令作为日志条目复制给其他服务器，在确认安全后，将日志命令提交执行。当 leader 故障时，会选举产生一个新的 leader。在强 leader 的帮助下，Raft 将一致性问题分解为三个子问题：

Leader 选举：当已有的 leader 故障时必须选出一个新的 leader。
日志复制：leader 接受来自客户端的命令，记录为日志，并复制给集群中的其他服务器，并强制其他节点的日志与 leader 保持一致。
安全 safety 措施：通过一些措施确保系统的安全性，如确保所有状态机按照相同顺序执行相同命令的措施。

etcd 在分布式存储中的应用

对于分布式存储来说，需要存储提供一些公用的配置信息，提供统一的集群视图。存储具备读写速度快，支持高可用且部署简单。此时，就需要使用到 etcd 了。

分布式存储节点角色一般有：mgr，mds 和 oss。其中 mgr 是集群的管理节点，提供共享配置和维护集群主从视图，mds 存储集群的元数据，oss 则用来存储用户数据。

将 etcd 纳入分布式存储内部的架构图如下所示：

利用 etcd lease 机制为分布式存储选主

etcd lease 机制能够确保一个 etcd 集群中的 key 拥有一种临时性的特征，被指定某个 lease 的 key 只能在集群中存活某一段时间，时间到了就会被集群自动删除。这段存活时间叫做 TTL (Time To Live)。

mgr 节点之间可以竞争 etcd 中同一个拥有 lease 属性的 key，比如: “/dfs/mgr/master”。当一个 mgr 节点竞争到这个 key，他就成为了mgr 主，同时其他节点就成为了 mgr 从。mgr 节点存活期间，定期给自己的 lease 续租，就可以一直保持自己的 mgr 主身份。一旦 mgr 主发生异常（比如宕机），过了 TTL 时间后，其持有的 key 就会被自动删除。此时，mgr 从节点发现 “/dfs/mgr/master” key 不存在后，就会重新竞争 mgr 主，重新获得此 key 的 mgr 升级为新的 mgr 主。

利用 etcd watch 机制为组件探活

etcd 提供了watch 机制，客户端 watch 了一系列 key，当这些被 watch 的 key 数据发生变化时，就会产生相应的事件通知客户端，相关的事件类型有：set, delete, update, create, compareAndSwap, compareAndDelete。

在 mds 服务启动时，向 etcd 注册自己的 ip（例如 /dfs/mds_nodes/, /dfs/mds_nodes/...），该 key 拥有 lease 属性。一旦 mds 服务异常，该 mds 的 ip 就会从 etcd 中 /dfs/mds_nodes 自动删除。这样，我们在 mgr 主节点启动监听 /dfs/mds_nodes 目录，就会得到某个 mds 上线和下线的事件通知，并且可以对 mds 相应的状态做标记，如果是 mds 主下线，则立即执行 mds 主从切换。

oss 同 mds 一样，监听的的目录变为 /dfs/oss_nodes。

通过 etcd 的 watch 机制，我们能快速地感知到 mds 或 oss 故障，进行 mds 或 oss 的主从切换（时间控制在 10 秒以内），从而保证客户端业务不受影响。

利用 etcd 做配置共享

etcd 高可用特性和快速读写，为我们使用配置共享提供了基础。我们把 mgr，mds，oss 的配置信息写入 etcd 集群中，各个组件从 etcd 集群中读取相应配置即可。

etcd 集群节点个数和性能

据 etcd 官网介绍，etcd V3 版本最高可以提供每秒 1 万次写入操作。但是随着 etcd 节点个数的增加，其写入性能会逐渐降低，所以我们一般采用 3 节点，5 节点或 7 节点部署 etcd 集群。大家可能会问：为什么不采用偶数节点，比如 4 节点，6 节点呢？因为 etcd 采用 Raft 协议，是 quorum 机制，要求半数以上节点在线。所以 4 节点的容错性和 3 节点是等价的，都是只能允许一个节点故障。但是多一个节点，一方面写入性能不如 3 节点，另一方面偶数节点在 etcd 内部选主时，有可能造成某一轮两个 candidate 节点获取的选票一致，从而延长选主时间。

etcd 支持 IPv6 协议

对于某些用户，为了安全，不提供 IPv4 地址，主机只有 IPv6 地址。这时候，etcd 的 IPv6 就发挥作用了。我们用实例展示，etcd 如何配置 IPv6 进行节点间通信，如下图所示（etcd 单节点集群）: