ETCD系列之二：部署叢集ETCD系列之二：部署叢集

想必很多人都知道zookeeper，通常用作配置共享和服務發現。和它類似，etcd算是一個非常優秀的後起之秀了。本文重點不在描述他們之間的不同點。首先，看看其官網關于etcd的描述[1]:

a distributed, reliable key-value store for the most critical data of a distributed system.

在雲計算大行其道的今天，etcd有很多典型的使用場景。常言道，熟悉一個系統先從部署開始。本文接下來将描述，如何部署etcd叢集。

安裝官網說明文檔，提供了3種叢集啟動方式，實際上按照其實作原理分為2類：

通過靜态配置方式啟動

通過服務發現方式啟動

在部署叢集之前，我們需要考慮叢集需要配置多少個節點。這是一個重要的考量，不得忽略。

etcd使用raft協定保證各個節點之間的狀态一緻。根據raft算法原理，節點數目越多，會降低叢集的寫性能。這是因為每一次寫操作，需要叢集中大多數節點将日志落盤成功後，leader節點才能将修改内部狀态機，并傳回将結果傳回給用戶端。

也就是說在等同配置下，節點數越少，叢集性能越好。顯然，隻部署1個節點是沒什麼意義的。通常，按照需求将叢集節點部署為3，5，7，9個節點。

這裡能選擇偶數個節點嗎？ 最好不要這樣。原因有二：

偶數個節點叢集不可用風險更高，表現在選主過程中，有較大機率或等額選票，進而觸發下一輪選舉。

偶數個節點叢集在某些網絡分割的場景下無法正常工作。試想，當網絡分割發生後，将叢集節點對半分割開。此時叢集将無法工作。按照raft協定，此時叢集寫操作無法使得大多數節點同意，進而導緻寫失敗，叢集無法正常工作。

當網絡分割後，etcd叢集如何處理的呢?

當叢集的leader在多數節點這一側時，叢集仍可以正常工作。少數節點那一側無法收到leader心跳，也無法完成選舉。

當叢集的leader在少數節點這一側時，叢集仍可以正常工作，多數派的節點能夠選出新的leader, 叢集服務正常進行。

當網絡分割恢複後，少數派的節點會接受叢集leader的日志，直到和其他節點狀态一緻。

這裡隻列舉一些重要的參數，以及其用途。

—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 叢集中所有節點

按照官網中的文檔，即可完成叢集啟動。這裡略。

etcd還提供了另外一種啟動方式，即通過服務發現的方式啟動。這種啟動方式，依賴另外一個etcd叢集，在該叢集中建立一個目錄，并在該目錄中建立一個<code>_config</code>的子目錄，并且在該子目錄中增加一個<code>size</code>節點，指定叢集的節點數目。

在這種情況下，将該目錄在etcd中的url作為節點的啟動參數，即可完成叢集啟動。使用

<code>--discovery https://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83</code> 配置項取代靜态配置方式中的<code>--initial-cluster</code> 和<code>inital-cluster-state</code>參數。其中<code>https://myetcd.local/v2/keys/discovery/6c007a14875d53d9bf0ef5a6fc0257c817f0fb83</code>是在依賴etcd中建立好的目錄url。

在生産環境中，不可避免遇到機器硬體故障。當遇到硬體故障發生的時候，我們需要快速恢複節點。etcd叢集可以做到在不丢失資料的，并且不改變節點id的情況下，遷移節點。

具體辦法是：

1）停止待遷移節點上的etc程序；

2）将資料目錄打包複制到新的節點；

3）更新該節點對應叢集中peer url，讓其指向新的節點；

4）使用相同的配置，在新的節點上啟動etcd程序；

本文記錄了etcd叢集啟動的一些注意事項，希望對你有幫助。