昨天我們介紹了cluster初始化時
選出master node並穩定整個cluster的過程

今天則是針對昨天的內容繼續延伸

1. 首先會先介紹voting configuration對於叢集穩定的重要性與功能
2. 再來會介紹在初始化cluster時，還沒有voting configuration時Bootstrapping a cluster所扮演的角色
3. 選舉結束後，整個cluster應該要怎麼維持穩定的相關機制

Voting configuration：

• voting configuration就是每一個ES叢集中都會存著的一份master-eligible nodes的名單
  • 讓master node掛掉時，其他node能依照這份清單重新discovery
• 在node進出cluster時，ES會對voting configuration進行調整
  • 如果有設定cluster.auto_shrink_voting_configuration為False，則需要自己手動使用voting configuration exclusion API來調整
    • 設定true時，只要維持3個nodes以上就能維持自動操作
  • 為了維持叢集的穩定與彈性
    • 會讓node數量維持奇數，如果是偶數可能會導致投票沒有共識
  • 此時不要再刪除更多node，如果一次移除超過一半的node會導致cluster崩潰
• 較大的voting configuration會讓整個cluster更有彈性
  • 如果有新的master-eligible node進入cluster，ES會更願意將其加入voting configuration
  • 如果voting configuration中的節點掛掉，會將其他在非voting configuration中但是master-eligible node納入
• 什麼時候voting configuration跟master-eligible node會不相符？
  • node進出後，ES調整voting configurationd可能造成名單不同

可以透過以下API來獲取當前在cluster中的voting configuration

GET _cluster/state?filter_path=metadata.cluster_coordination

{
  "metadata": {
    "cluster_coordination": {
      "term": 4,
      "last_committed_config": [
        "7dZyqMdtQNe_Z4WVrG8vug",
        "iVc4ApIeQzqGm34WPx_ZTQ",
        "-Er7BdJnS5q0HKRhCSwBpw"
      ],
      "last_accepted_config": [
        "7dZyqMdtQNe_Z4WVrG8vug",
        "iVc4ApIeQzqGm34WPx_ZTQ",
        "-Er7BdJnS5q0HKRhCSwBpw"
      ],
      "voting_config_exclusions": []
    }
  }
}

• last_committed_config代表上次提交的節點配置id，反應當前cluster狀態
• last_accepted_config代表上次接受但是還沒提交的節點id
  • 可以會因為網路問題或是其他因素導致配置一直改變，比對兩組資料才能確保系統穩定
• voting_config_exclusions表示沒有投票權的node

Bootstrapping a cluster：

• 第一次啟動cluster時，需要進行cluster bootstrapping
  • 也就是初始化這個cluster的master-eligible nodes
  • 由yml中的cluster.initial_master_nodes定義master-eligible nodes，並且需要提供額外的必要資訊
    • node name of the node
    • node’s hostname
    • node’s transport publish address
    • 以上資訊擇一即可
• 在cluster形成後，應該將cluster.initial_master_nodes設定從個節點中去除掉，以下幾種node不應該有這樣的設定
  • 不是master-eligible nodes
  • 剛加入現有cluster且具有master-eligible 的nodes
  • 正在重新啟動的node
• 如果不刪除，有可能會導致在現有cluster旁邊引導出新cluster的風險

"message": "this node is locked into cluster UUID [3arfDVeHS8ejCQH00117qA] but [cluster.initial_master_nodes] is set to [es01, es02, es03]; remove this setting to avoid possible data loss caused by subsequent cluster bootstrap attempts; for further information see ..."

• 在初始化cluster時，可以將每台機器設置相同的cluster.initial_master_nodes
  • 避免有可能發生所有node還沒找完，但是就能符合建立cluster條件的狀況

Cluster state：

可以分成兩部分來說：

1. publish cluster state
2. cluster detection

publish cluster state：

• 只有master node能更新cluster state
• master node 一次處理一批叢集狀態更新，計算所需的變更並將更新的叢集狀態發佈到叢集中的所有其他node
• 過程如下：
  1. 每個節點如果收到更新資訊，會返回響應，但還沒直接套用新接收到的狀態
  2. master node從足夠多的master-eligible nodes的響應，新的cluster state就稱為已提交
     • 如果超過cluster.publish.timeout的時間(預設30s)沒有獲得超過半數node的響應
     • 放棄這次cluster state更新，並讓出master node位置，並且重新開始discovery跟選舉階段
  3. master node再次通知其他所有node，說明已提交cluster state
  4. nodes接收消息後，套用更新後的狀態，然後再響應給master node
     • 如果超過cluster.follower_lag.timeout(預設90s)，該node沒有回傳響應，master node會將該節點踢出cluster

cluster detection：

• node彼此之間會檢查健康狀態，依照身份分為
  • follower checks
  • leader checks
• 除非檢查一直連續失敗，不然偶爾失敗ES不會有反應
  • 可以設置cluster.fault_detection相關的配置
• 但如果是發現失去連結的狀態
  • master node發現node失聯，會將其直接踢除
  • 反之，則馬上進到discovery階段
• 節點會傳輸小檔案到磁碟中，並且刪除它。用以驗證自己的儲存檔案路徑沒有問題

我們這兩天稍微介紹了有關叢集建立與初始化的過程
並且透過觀察log的方式更加了解整個流程的運作
也探討相關的yml配置，以及後續叢集運作的相關機制

明天我們會延伸之前所說單節點的叢集建立
用docker建立一個三節點的cluster
說明基本配置以及xpack的相關機制
最後會再簡單介紹有關node要加入或是移除現有cluster的步驟

參考資料
voting configuration：
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-voting.html
bootstrapping a cluster：
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-bootstrap-cluster.html
publish cluster state：
https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-state-publishing.html