這兩天我們會介紹有關cluster建立起來的一個過程
包含node之間是怎麼找到彼此
以及後續叢集的健康狀態等等

一共分成5個部分來說明：

1. Discovery：當master node還未建立時，或是原本的master node掛掉時，node互相找尋彼此的過程
2. Quorum-based decision making：在原本的master node掛掉，或是在初始狀態下，透過投票機制選出master node
3. Voting configurations：在cluster中有node的進出時，能自動的維護master-eligible nodes的機制
4. Bootstrapping a cluster：在cluster初始化階段處理相關機制
5. cluster state：主節點會更新叢集中其他node的資訊，以及檢查cluster與nodes的健康狀態

今天會先對discovery與Quorum-based decision making進行介紹

Discovery：
就是node在互相找到彼此然後形成一個cluster的過程

• 發生在cluster剛建立或是master node掛掉時，開始運行
• 如果master node選出來，就會停止

Discovery主要流程

1. 首先節點們會根據自己的seed address來尋找其他節點
   • 從seed hosts provider拿到節點的ip位置
   • 如果是上一個master node掛掉，導致重新一輪discovery，則是拿master-eligible nodes
2. 如果有成功連到(代表還活著)，確認遠端節點是否master-eligible
   • 如果對方沒有主節點候選資格，會繼續這個discovery的流程
     • 如果都沒有發現主節點資格node，經過discovery.find_peers_interval設定的時間後(默認為1秒)，會再重新嘗試
   • 如果對方有主節點候選資格，一樣會繼續這個discovery的流程
     • 直到他找到已經成為master node，或是找到的master-eligible nodes足夠數量能進行選舉
     • 如果都沒有達到上述條件，經過discovery.find_peers_interval設定的時間後(默認為1秒)，會再重新嘗試
   • 如果對方已經是master node
     • 加入cluster
     • 從master node獲取整個cluster資訊
3. 一旦master node成功選舉出來，就會保持為master node的身份
   • 不論任何因素所導致master node消失，就會再次discovery

Seed hosts provider：

• 可以分為settings-based跟file-base的provider
• 每個seed hosts provider提供ip位置或是host name：
  • 如果使用host name，使用DNS解析出ip位置
    • 如果解析出多ip，則會嘗試所有可能
  • 如果沒有給TCP端口，會使用Transport.profiles.default.port範圍內的資料
• 設置settings-based的幾種範例

discovery.seed_hosts:
   - 192.168.1.10:9300
   - 192.168.1.11 
   - seeds.mydomain.com

• file-base的provider則是檔案提供
  • 如果檔案更新時，ES會自動更新。這在使用docker時非常的方便
  • yml檔案中添加如下，並並會存在$ES_PATH_CONF/unicast_hosts.txt

discovery.seed_providers: file

• 檔案格式如下：

10.10.10.5
10.10.10.6:9305
10.10.10.5:10005
# an IPv6 address
[2001:0db8:85a3:0000:0000:8a2e:0370:7334]:9301

• 如果有設置檔案跟setting，ES都會使用這些seeds

Quorum-based decision making：
選出master node：

• 當選舉失敗時或是在初始化階段時執行
• 選舉機制以Raft演算法為基礎，但是有些微修改，讓成功選出master node的機率更高
  • 候選node分成三種狀態
    • leader：正常來說一個cluster只會有一個leader
    • follower：被動接收請求，不發送主動請求
    • candidate：從follower到leader的一個中間狀態
  • 有term(任期)的概念，節點通信時會帶著term
    • 如果對方較小會拒絕請求
    • 如果對方較大會更新自己的term
• 三個身份轉換的過程如下：
  • 初始為candidate，如果在discovery階段發現有leader，就加入cluster並轉成follower
  • 如果candidate收到足夠多的投票，會轉變成leader，
  • 如果leader發現有人的term比他高，他會轉成candidate
• 投票流程：
  • 初始為candidate狀態，準備發起選舉
  • 先執行preVote，送給其他node(包含自己)，請求中包含自己的term
    • 目的：讓其他node要同意自己這個node能夠發起選舉
      • 發起人的term要夠大
      • 發起人term相同，但是cluster state version更新
      • 得到大家同意就能發起選舉
    • 其他node接收後執行相關動作：

1.更新自己看到的maxTermSeen
2.如果自己是leader，而maxTermSeen大於自己的currentTrem，就轉成candidate，開始下一輪選舉

• 發起人等待preVote的回傳，如果自己的cluster version與term為最新，則發出投票request
  • 請求為Math.max(getCurrentTerm(), maxTermSeen) + 1
  • 雖然有加1，但是發起人自己在node裡面的term沒有+1
• 其他接收node接到request時
  • 看term有沒有大於當前cluster的term，如果沒有就拒絕
  • 如果是leader身份接到，會轉成candidate
  • 確認term沒問題，會發起投票，並不限制只能投1票
• 發起者如果得票數過半就當選，並且發布叢集狀態 elected-as-master（宣布凍蒜XDD）
  • 如果宣布失敗，就切換回candidate

上述的選舉過程，可能看似複雜，並且給人的感覺好像很難成功
但是ES的官方文檔提到有配置好的話，通常第一次就會選舉成功
並且避免出現兩個node同時發出投票的狀態
會根據master election settings，來讓投票的時間是隨機不固定的

上面這樣說可能還是很模糊
我這邊用docker建立了一個三節點的cluster(後面提到xpacks時會一併說明)
並且去觀察cluster建立時的相關log
以下均擷取部分節點1之log

 
"message":"using discovery type [multi-node] and seed hosts providers [settings]"
"log.logger":"org.elasticsearch.discovery.DiscoveryModule"
...
"message":"master node changed {
previous [], 
current [{es02}{7dZyqMdtQNe_Z4WVrG8vug}{Njn4ojV1TU-hB6UhITReTg}..."

• 我們可以看到根據seed hosts providers中settungs的配置開始進行discovery階段
• 而es02選上了master node，並且從previous為[]得知，之前該cluster沒有過master node

雖然我在log檔中沒有看到選舉過程，但是沒關係
我把現在是master node的docker容器停下來

"message":"master node changed {
previous [{es02}{7dZyqMdtQNe_Z4WVrG8vug}{Njn4ojV1TU-hB6UhITReTg}...], 
current []}

• 可以看到因為es02掛掉了，所以master node由es02轉成[]
• 接著es03選上master node

那此時我把es02重新開啟後，會發生什麼事情呢？
因為在es02有設置

discovery.seed_hosts=es01,es03

所以我們看log

"message":"added {{es02}{7dZyqMdtQNe_Z4WVrG8vug}...., 
term: 4, 
version: 260, 
reason: ApplyCommitRequest{term=4, version=260, 
sourceNode={es03}{-Er7BdJnS5q0HKRhCSwBpw}...

• es02成功被加進cluster中，並且sourceNode也是es03也就是master node，負責更新cluster與node的狀態

希望這樣的實際log檔能讓大家更了解這些過程
以上就是今天的內容～
明天會繼續把剩下的內容補完

參考資料
discovery and cluster formation：
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery.html
discovery：
https://www.elastic.co/guide/en/elasticsearch/reference/current/discovery-hosts-providers.html
quorum-based decision making：
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-quorums.html
選舉過程：
https://blog.csdn.net/qq_21383435/article/details/109953947