常见问题解答(FAQ)
etcd,一般客户是否必须向etcd负责人发送请求?
raft是基于领导者的;领导者处理所有需要集群共识的客户请求。但是,客户端不需要知道哪个节点是领导者。发送给关注者的任何需要共识的请求都将自动转发给领导者。不需要共识(例如,序列化读取)的请求可以由任何集群成员处理。(简单的说就是写给Leader读给追随者)
配置
advertise-urls和listen-urls有什么区别?
listen-urls
指定etcd服务器绑定到的本地地址,以接受传入的连接。要在端口上侦听所有接口,请指定0.0.0.0
为侦听IP地址。
advertise-urls
指定etcd客户端或其他etcd成员用于联系etcd服务器的地址。通告地址必须可以从远程计算机访问。请勿将地址localhost
或0.0.0.0
用于生产设置,因为从远程计算机无法访问这些地址。
部署方式
系统要求
由于etcd将数据写入磁盘,因此强烈建议使用SSD(复制日志(mysql binlog))。为了防止性能下降或意外导致键值存储超载,etcd强制使用2GB的默认存储大小配额,该配额最多可配置为8GB。为避免交换或内存不足,计算机应至少具有尽可能多的RAM来覆盖配额。在CoreOS上,通常在具有双核处理器,至少2GB RAM(内存)和80GB SSD(硬盘)的专用CoreOS Container Linux机器上部署etcd集群。请注意,性能本质上取决于工作负载;请在生产部署前进行测试。
最稳定的生产环境是具有amd64架构的Linux操作系统。
为什么集群成员的数量为奇数?
一个etcd集群需要大多数节点(仲裁)来同意对集群状态的更新(去中心化需要协商产生一致性基础就是大多数成员同意提交的数据,Leader选举同样需要)。对于具有n个成员的群集,仲裁数为(n / 2)+1。对于任何奇数大小的群集,添加一个节点将始终增加仲裁所需的节点数。尽管由于有更多的计算机而将节点添加到奇数大小的群集中看起来更好(就是3+1变成了4),但是容错能力更差,性能也会变低(日志复制多了一个节点),因为完全相同数量的节点可能会失败而不会丢失仲裁(网络分区),当有更多的节点失败。如果群集处于无法容忍更多故障的状态,则在删除节点之前添加节点是危险的,因为如果新节点无法在群集中注册(例如,地址配置错误),仲裁将永久丢失。
最大群集大小是多少?
从理论上讲,没有硬性限制。但是,一个etcd集群可能最多只能有七个节点。类似于etcd的Google Chubby Lock服务已经在Google中广泛部署了很多年,建议运行五个节点。一个5成员的etcd集群可以容忍两个成员的故障,这在大多数情况下就足够了。尽管较大的群集可提供更好的容错能力,但由于必须在更多计算机上复制数据,因此写入性能会受到影响。(集群在大也要考虑日志复制的效率,稳定只是其中之一)
什么是容错能力?
只要可以建立成员仲裁,etcd群集就会运行。如果由于暂时性的网络故障(例如分区)而丢失了仲裁,那么一旦网络恢复并恢复了仲裁,etcd就会自动安全地恢复。raft强制执行群集一致性。对于断电,etcd会将Raft日志持久保存到磁盘;etcd将日志重播到故障点并恢复集群。对于永久性硬件故障,可以通过运行时重新配置将节点从群集中删除。
建议集群中的成员数为奇数。奇数大小的群集可以容忍的故障数量与偶数大小的群集相同(推荐奇数主要怕Leader选举时增加均票重选几率导致可用性降低),但节点数较少。通过比较偶数和奇数大小的群集可以看出差异:
簇的大小 | 多数 | 容错能力 |
---|---|---|
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配置可能会导致频繁的选举或心跳超时。((配置)中的—heartbeat-interval与—election-timeout)
如何备份etcd集群?
etcdctl提供了snapshot
创建备份的命令。(维护)
在删除不健康的成员之前,我应该添加成员吗?
替换etcd节点时,重要的是先删除该成员,然后添加其替换。
etcd使用基于仲裁模型的分布式共识;(n + 1)/ 2个成员(多数)必须先同意一项提案,然后才能将该提案提交到集群。这些建议包括键值更新和成员资格更改。该模型完全避免了脑裂的任何可能性。不利的一面是永久的仲裁丢失是灾难性的。
这对成员资格的适用方式:如果3成员群集中有1个关闭的成员,则由于仲裁人数为2,并且2个成员仍处于活动状态,因此它仍可以向前发展。但是,将新成员添加到3个成员的群集将使法定人数增加到3,因为4个成员中的大多数需要3票。由于法定人数增加,因此这个额外的成员在容错方面一无所获;群集仍然是一个不可恢复的节点故障。
此外,该新成员存在风险,因为它可能配置错误或无法加入集群。在这种情况下,无法恢复仲裁,因为群集的成员减少了两个,成员增加了两个,但是需要三票才能更改成员身份才能撤消增加的成员资格。默认情况下,etcd将拒绝成员添加尝试,这种尝试可能会以这种方式关闭集群。
另一方面,如果首先从集群成员资格中删除被降级的成员,则成员数变为2,并且法定人数保持为2。在此之后,通过添加新成员进行删除也将使法定人数稳定在2。因此,即使无法启动新节点,仍然可以通过仲裁删除其余活动成员上的新成员。
为什么etcd不接受我的会员更改?
strict-reconfig-check
为了拒绝可能导致仲裁丢失的重新配置请求,etcd进行了设置。放弃仲裁确实有风险(尤其是当群集已经不健康时)。尽管如果增加新成员的导致仲裁丢失,而很想禁用仲裁检查,但这可能会导致完全成熟的群集不一致。对于许多应用程序,这将使问题更加严重(“磁盘损坏”是最令人恐惧的选择)。
表现
我应该如何对etcd进行基准测试?
尝试使用基准测试工具。当前的基准测试结果可用于比较。
etcd警告“应用条目时间过长”是什么意思?
在大多数etcd成员同意提交请求之后,每个etcd服务器将请求应用于其数据存储,并将结果保存到磁盘。即使使用慢速机械磁盘或虚拟化网络磁盘(例如Amazon的EBS或Google的PD),应用请求通常也应少于50毫秒。如果平均申请时间超过100毫秒,etcd将警告条目申请时间太长。
通常,此问题是由磁盘速度慢引起的。磁盘可能正在etcd和其他应用程序之间争用,或者磁盘太慢(例如,共享的虚拟磁盘)。要排除慢速磁盘引起此警告的危险,请监视 backend_commit_duration_seconds(p99持续时间应小于25ms),以确认磁盘速度相当快。如果磁盘速度太慢,则将专用磁盘分配给etcd或使用速度更快的磁盘通常可以解决该问题。
第二个最常见的原因是CPU资源紧张。如果监视计算机的CPU使用率显示利用率很高,则可能没有足够的计算能力来存储etcd。将etcd移至专用计算机(外部单独集群),增加进程资源隔离cgroup或将etcd服务器进程重新设置为更高的优先级通常可以解决该问题。
访问过多密钥(例如,获取整个密钥空间)的大开销用户请求也可能导致较长的应用等待时间。但是,每个请求访问少于几百个密钥应该总是有效的。
如果以上建议均不能清除警告,请打开debug,其中包含详细的日志记录,监视,指标和可选的工作负载信息。
etcd警告“未能及时发送心跳”是什么意思?
etcd使用基于领导者的共识协议来实现一致的数据复制和日志执行(去中心)。集群成员选出一个领导者,其他所有成员都成为跟随者。周期性发送心跳信息. 如果在选举时间间隔内未收到任何心跳,则跟随者会推断领导者失败并触发选举。如果领导者没有及时发送心跳信号但仍在运行,则选举是虚假的,很可能是由于资源不足造成的。为了捕获这些软故障,如果领导者跳过两个心跳间隔,则etcd将警告它无法按时发送心跳。
通常,此问题是由磁盘速度慢引起的。领导者发送附有元数据的心跳之前,可能需要将元数据持久保存到磁盘。磁盘可能正在etcd和其他应用程序之间争用,或者磁盘太慢(例如,共享的虚拟磁盘)。要排除慢速磁盘引起此警告的危险,请监控 wal_fsync_duration_seconds(p99持续时间应小于10ms)以确认该磁盘是否足够快。如果磁盘速度太慢,则将专用磁盘分配给etcd或使用速度更快的磁盘通常可以解决该问题。
第二个最常见的原因是CPU资源紧张。如果监视计算机的CPU使用率显示利用率很高,则可能没有足够的计算能力来存储etcd。将etcd移至专用计算机,使用cgroup增强进程资源隔离或将etcd服务器进程重新设置为更高的优先级通常可以解决该问题。
网络速度慢也会导致此问题。如果etcd机器之间的网络指标显示出较长的延迟或高丢弃率,则可能没有足够的网络容量用于etcd。将etcd成员移动到不太拥挤的网络通常可以解决该问题。但是,如果etcd集群跨数据中心部署,则成员之间的等待时间会很长。对于此类部署,请调整heartbeat-interval
配置以使其与计算机之间的往返时间大致匹配,并且election-timeout
配置至少应为5 * heartbeat-interval
。有关详细信息,请参见调整文档。
如果以上建议均不能清除警告,请打开debug,其中包含详细的日志记录,监视,指标和可选的工作负载信息。
etcd警告“请求被忽略(集群ID不匹配)”是什么意思?
每个新的etcd群集都会根据初始群集配置和用户提供的唯一initial-cluster-token
值生成一个新的群集ID(集群代号类似于vrrp的vrid) 。通过具有唯一的集群ID,可以保护etcd免受可能破坏集群的跨集群交互的影响。
通常,此警告是在拆除旧群集,然后为新群集重新使用某些对等地址之后发生的。如果旧集群中的任何etcd进程仍在运行,它将尝试与新集群联系。新集群将识别出集群ID不匹配,然后忽略该请求并发出此警告。通常通过确保不同群集之间的对等地址不相交来清除此警告。(就是集群之间要唯一)