ETCD系列之二：部署集群
1. 概述
想必很多人都知道ZooKeeper，通常用作配置共享和服务发现。和它类似，ETCD算是一个非常优秀的后起之秀了。本文重点不在描述他们之间的不同点。首先，看看其官网关于ETCD的描述[1]:
A distributed, reliable key-value store for the most critical data of a distributed system.
在云计算大行其道的今天，ETCD有很多典型的使用场景。常言道，熟悉一个系统先从部署开始。本文接下来将描述，如何部署ETCD集群。
安装官网说明文档，提供了3种集群启动方式，实际上按照其实现原理分为2类：
- 通过静态配置方式启动
- 通过服务发现方式启动
在部署集群之前，我们需要考虑集群需要配置多少个节点。这是一个重要的考量，不得忽略。
2. 集群节点数量与网络分割
ETCD使用RAFT协议保证各个节点之间的状态一致。根据RAFT算法原理，节点数目越多，会降低集群的写性能。这是因为每一次写操作，需要集群中大多数节点将日志落盘成功后，Leader节点才能将修改内部状态机，并返回将结果返回给客户端。
也就是说在等同配置下，节点数越少，集群性能越好。显然，只部署1个节点是没什么意义的。通常，按照需求将集群节点部署为3，5，7，9个节点。
这里能选择偶数个节点吗？ 最好不要这样。原因有二：
- 偶数个节点集群不可用风险更高，表现在选主过程中，有较大概率或等额选票，从而触发下一轮选举。
- 偶数个节点集群在某些网络分割的场景下无法正常工作。试想，当网络分割发生后，将集群节点对半分割开。此时集群将无法工作。按照RAFT协议，此时集群写操作无法使得大多数节点同意，从而导致写失败，集群无法正常工作。
当网络分割后，ETCD集群如何处理的呢?
- 当集群的Leader在多数节点这一侧时，集群仍可以正常工作。少数节点那一侧无法收到Leader心跳，也无法完成选举。
- 当集群的Leader在少数节点这一侧时，集群仍可以正常工作，多数派的节点能够选出新的Leader, 集群服务正常进行。
当网络分割恢复后，少数派的节点会接受集群Leader的日志，直到和其他节点状态一致。
3. ETCD参数说明
这里只列举一些重要的参数，以及其用途。
- —data-dir 指定节点的数据存储目录，这些数据包括节点ID，集群ID，集群初始化配置，Snapshot文件，若未指定—wal-dir，还会存储WAL文件；
- —wal-dir 指定节点的was文件的存储目录，若指定了该参数，wal文件会和其他数据文件分开存储。
- —name 节点名称
- —initial-advertise-peer-urls 告知集群其他节点url.
- — listen-peer-urls 监听URL，用于与其他节点通讯
- — advertise-client-urls 告知客户端url, 也就是服务的url
- — initial-cluster-token 集群的ID
- — initial-cluster 集群中所有节点
4. 通过静态配置方式启动ETCD集群
按照官网中的文档，即可完成集群启动。这里略。
5. 通过服务发现方式启动ETCD集群
ETCD还提供了另外一种启动方式，即通过服务发现的方式启动。这种启动方式，依赖另外一个ETCD集群，在该集群中创建一个目录，并在该目录中创建一个_config的子目录，并且在该子目录中增加一个size节点，指定集群的节点数目。
在这种情况下，将该目录在ETCD中的URL作为节点的启动参数，即可完成集群启动。使用--discovery https://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83 配置项取代静态配置方式中的--initial-cluster 和inital-cluster-state参数。其中https://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83是在依赖etcd中创建好的目录url。
6. 节点迁移
在生产环境中，不可避免遇到机器硬件故障。当遇到硬件故障发生的时候，我们需要快速恢复节点。ETCD集群可以做到在不丢失数据的，并且不改变节点ID的情况下，迁移节点。
具体办法是：
- 1）停止待迁移节点上的etc进程；
- 2）将数据目录打包复制到新的节点；
- 3）更新该节点对应集群中peer url，让其指向新的节点；
- 4）使用相同的配置，在新的节点上启动etcd进程；
5. 结束
本文记录了ETCD集群启动的一些注意事项，希望对你有帮助。
