etcd 介绍

什么是etcd?
etcd是一个一致的分布式键值存储。主要作为一个独立的协调服务,在分布式系统中使用。并被设计为容纳少量的数据,可以完全放在内存中。

etcd怎么发音?
etcd的发音是/ˈɛtsiːdiː/,意思是 "分布式etc目录"。

客户端必须向etcd领导者发送请求吗?
Raft是基于领导者的;领导者处理所有需要集群共识的客户端请求。然而,客户端不需要知道哪个节点是领导者。任何需要达成共识的请求都会自动转发到领导者那里。不需要共识的请求(例如,序列化读取)可以由任何集群成员处理。

配置
listen-<client,peer>-urls、advertise-client-urls或initial-advertise-peer-urls之间有什么区别?
listen-client-urls和listen-peer-urls指定了etcd服务器为接受传入连接而绑定的本地地址。要在一个端口上监听所有接口,请指定0.0.0.0作为监听IP地址。

advertise-client-urls和initial-advertise-peer-urls指定etcd客户端或其他etcd成员应使用的地址来联系etcd服务器。广告地址必须是可以从远程机器到达的。在生产设置中,不要公布像localhost或0.0.0.0这样的地址,因为这些地址从远程机器上是不可达的。

 

为什么改变--listen-peer-urls或--initial-advertise-peer-urls不能更新etcdctl成员列表中的广告对等体网址?
成员公布的对等体URL来自集群初始启动时的-initial-advertis-peer-urls。在启动成员后改变监听对等体URL或初始广告对等体不会影响导出的广告对等体URL,因为改变必须经过quorum以避免成员配置分裂的大脑。使用 etcdctl member update 来更新成员的对等体 URL。

 

 

 

部署

系统要求

由于etcd将数据写入磁盘,其性能强烈依赖于磁盘性能。出于这个原因,强烈建议使用SSD。要评估磁盘的速度是否足以满足etcd的需要,一种方法是使用磁盘基准测试工具,如fio。关于如何做到这一点的例子,请阅读这里。为了防止性能下降或无意中使键值存储超载,etcd执行了一个可配置的存储大小配额,默认设置为2GB。为了避免交换或内存耗尽,机器应该有至少同样多的内存来覆盖配额。8GB是正常环境下的建议最大容量,如果配置的值超过了,etcd会在启动时发出警告。在CoreOS,etcd集群通常被部署在专用的CoreOS Container Linux机器上,这些机器拥有双核处理器、2GB内存和至少80GB的SSD。请注意,性能在本质上取决于工作负载;请在生产部署前进行测试。更多建议见硬件。

最稳定的生产环境是amd64架构的Linux操作系统;更多信息见支持的平台。

为什么集群成员的数量是奇数?
一个etcd集群需要大多数节点,即法定人数,以同意对集群状态的更新。对于一个有n个成员的集群,法定人数是(n/2)+1。对于任何奇数大小的集群,添加一个节点总是会增加法定人数所需的节点数。虽然在奇数大小的集群中增加一个节点看起来更好,因为有更多的机器,但容错性更差,因为完全相同数量的节点可能失败而不失去法定人数,但有更多的节点可能失败。如果集群处于不能再容忍任何故障的状态,在删除节点之前添加一个节点是很危险的,因为如果新的节点不能在集群中注册(例如,地址配置错误),法定人数将永久丢失。

什么是最大的集群规模?
理论上,没有硬性限制。然而,一个etcd集群可能不应该有超过七个节点。谷歌Chubby锁服务,类似于etcd,在谷歌内部广泛部署多年,建议运行5个节点。一个由5个成员组成的etcd集群可以容忍两个成员的故障,这在大多数情况下是足够的。虽然更大的集群提供了更好的容错性,但由于数据必须在更多的机器上复制,所以写入性能受到影响。

什么是故障容错?
只要能建立一个成员的法定人数,etcd集群就能运行。如果由于瞬时网络故障(如分区)而失去了法定人数,一旦网络恢复并恢复了法定人数,etcd就会自动安全地恢复;Raft执行集群的一致性。对于电源损失,etcd将Raft日志持久化到磁盘;etcd将日志复制到故障点并恢复集群参与。对于永久性的硬件故障,节点可以通过运行时的重新配置从集群中移除。

建议在一个集群中拥有奇数的成员。一个奇数规模的集群可以容忍与偶数规模的集群相同数量的故障,但节点较少。通过比较偶数和奇数大小的集群,可以看出其中的差别。

集群大小 多数  故障容忍度
1 1 0
2 2 0
3 2 1
4 3 1
5 3 2
6 4 2
7 4 3
8 5 3
9 5 4
增加一个成员以使集群的规模达到偶数,并不能买到额外的容错。同样,在网络分区期间,奇数成员保证总有一个多数分区可以继续运行,并在分区结束时成为真相的来源。

etcd在跨区域或跨数据中心的部署中是否有效?
跨区域部署etcd可以提高etcd的容错性,因为成员处于不同的故障域中。其代价是跨越数据中心边界的共识请求延迟更高。由于etcd依靠成员的法定人数来达成共识,跨越数据中心的延迟会有些明显,因为至少有大多数集群成员必须响应共识请求。此外,集群数据必须在所有对等体之间进行复制,所以也会有带宽成本。

在较长的延迟下,默认的etcd配置可能导致频繁的选举或心跳超时。请参阅调整,以调整高延迟部署的超时。

 

操作

如何备份一个etcd集群?
etcdctl提供了一个快照命令来创建备份。更多细节请参见备份。

我应该在删除不健康的成员之前添加一个成员吗?
当替换一个etcd节点时,重要的是先移除成员,然后再添加其替代者。

etcd 采用了基于法定人数模型的分布式共识;(n/2)+1 个成员,即多数人,必须在提案上达成一致,才能提交给集群。这些提议包括键值更新和成员变更。这种模式完全避免了任何分裂大脑不一致的可能性。缺点是永久性的法定人数损失是灾难性的。

这如何适用于成员资格。如果一个由3个成员组成的集群有1个宕机的成员,它仍然可以向前推进,因为法定人数是2,2个成员仍然活着。然而,在一个由3个成员组成的集群中增加一个新成员,将使法定人数增加到3人,因为4个成员的多数需要3票。由于法定人数增加了,这个额外的成员在容错方面没有买到任何东西;该集群仍然是一个节点故障,无法恢复的。

此外,这个新成员是有风险的,因为它可能被错误地配置或无法加入集群。在这种情况下,没有办法恢复法定人数,因为集群有两个成员倒下,两个成员起来,但需要三票来改变成员资格,以撤销错误的成员添加。

另一方面,如果先将倒下的成员从集群成员中移除,那么成员的数量就会变成2,而且法定人数也会保持在2的水平。

为什么etcd不接受我的成员变更?
etcd设置了严格的reconfig-check,以便拒绝会导致法定人数损失的重新配置请求。放弃法定人数是非常危险的(尤其是当集群已经不健康的时候)。尽管在有法定人数损失的情况下禁用法定人数检查来添加新成员可能很诱人,但这可能会导致成熟的集群不一致的情况。对于许多应用程序来说,这将使问题变得更糟("磁盘几何损坏 "是最可怕的候选者)。

为什么etcd会因为磁盘延迟的峰值而失去其领导者?
这是故意的;磁盘延时是领导者有效性的一部分。假设集群领导者需要一分钟的时间将一个筏子日志更新到磁盘上,但etcd集群有一秒钟的选举超时。即使领导者可以在选举间隔内处理网络消息(例如,发送心跳),但它实际上是不可用的,因为它不能提交任何新的提议;它在缓慢的磁盘上等待。如果集群由于磁盘延迟而经常失去其领导者,请尝试调整磁盘设置或etcd时间参数。

etcd警告 "请求被忽略(集群ID不匹配)"是什么意思?
每个新的etcd集群都会根据初始集群配置和用户提供的唯一初始集群令牌值生成一个新的集群ID。通过拥有唯一的集群ID,etcd被保护起来,避免了跨集群的互动,这可能会破坏集群。

通常情况下,这种警告发生在拆毁一个旧集群,然后为新集群重新使用一些对等体地址之后。如果任何来自旧集群的etcd进程仍在运行,它将尝试联系新集群。新集群会识别出集群ID不匹配,然后忽略该请求并发出这个警告。这个警告通常是通过确保不同集群之间的对等地址不相交来清除的。

mvcc:数据库空间超标 "是什么意思,我如何解决?
etcd中的多版本并发控制数据模型保留了密钥空间的精确历史。如果不定期压缩这个历史(例如,通过设置 -- 自动压缩),etcd 最终会耗尽其存储空间。如果etcd的存储空间不足,它就会发出一个空间配额警报,以保护集群免受进一步的写入。只要警报被拉响,etcd就会以错误mvcc:数据库空间超标来响应写入请求。

要从低空间配额警报中恢复过来。

压缩etcd的历史记录。
对每个etcd端点进行碎片整理。
解除警报。
etcd警告 "etcdserver/api/v3rpc: transport: http2Server.HandleStreams failed to read frame: read tcp 127.0.0.1:2379->127.0.0.1:43020: read: connection reset by peer "是什么意思?
这是gRPC方面的警告,当服务器收到TCP RST标志时,客户端的流被过早关闭。例如,客户端关闭其连接,而gRPC服务器尚未处理TCP队列中的所有HTTP/2帧。一些数据可能会在服务器端丢失,但只要客户端连接已经关闭,就没有问题。

只有旧版本的gRPC才会记录这一点。etcd >=v3.2.13默认以DEBUG级别记录这一点,

 

posted @ 2022-09-29 21:31  风在何方  阅读(1115)  评论(0编辑  收藏  举报