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程序；