关于云计算:分布式存储之-etcd-的集群管理

57次阅读

共计 3040 个字符,预计需要花费 8 分钟才能阅读完成。

在分布式文件存储中,咱们通常会面临集群选主,配置共享和节点状态监控的问题。通过 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 将一致性问题合成为三个子问题:

  1. Leader 选举:当已有的 leader 故障时必须选出一个新的 leader。
  2. 日志复制:leader 承受来自客户端的命令,记录为日志,并复制给集群中的其余服务器,并强制其余节点的日志与 leader 保持一致。
  3. 平安 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 单节点集群):

该实例的 IPv6 地址为 2022::24,应用时,用 [] 将 IPv6 地址括起来即可。须要留神的是该 IPv6 地址只能应用 Scope global 类型,不能应用 Scope link 类型,否则,在启动 etcd 服务时,会报 bind 地址有效谬误。

据统计,目前至多有 CoreOS、Kubernetes、Cloud Foundry,以及在 Github 上超过 500 个我的项目在应用 etcd。

正文完
 0