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

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

什么是 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 架构图

分布式存储之 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 将一致性问题分解为三个子问题:

1、Leader 选举:当已有的 leader 故障时必须选出一个新的 leader。

2、日志复制:leader 接受来自客户端的命令,记录为日志,并复制给集群中的其他服务器,并强制其他节点的日志与 leader 保持一致。

3、安全 safety 措施:通过一些措施确保系统的安全性,如确保所有状态机按照相同顺序执行相同命令的措施。

etcd 在分布式存储中的应用

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

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

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

分布式存储之 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 单节点集群):

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

该实例的 IPv6 地址为 2022::24, 使用时,用 [] 将 IPv6 地址括起来即可。需要注意的是该 IPv6 地址只能使用 Scope global 类型,不能使用 Scope link 类型,否则,在启动 etcd 服务时,会报 bind 地址无效错误。

发表评论

相关文章