關於 Elasticsearch 集群核心配置,騰訊大佬的靈魂9問,你能接住幾個?(轉)


2021年9月28日07:36:04

原文: https://mp.weixin.qq.com/s/ChPs80_1HeuUtUHpthqEBA

 

題記

這是一位騰訊大佬 2020年4月份在死磕 Elasticsearch技術交流微信群里發起討論的問題,之前初步討論了答案,但是不夠細或者說講解不透,所以一直沒有成文。

這一次,加上了實踐驗證,說透。

1、上問題

還是沒太搞懂 seed_hosts 和 cluster.initial_master_nodes 的區別。

  • 1、 seed_hosts里面一定是配置 master eligible節點嗎?
  • 2、還是說data節點也可以配置到 master eligible
  • 3、是如何發現潛在機器的呢?
  • 4、initial_master一定是master eligible節點吧?
  • 5、集群初始啟動時, 這幾個節點一定都要在是嗎?
  • 6 、初始的時候是不是可以配置一個, 然后集群初始化后, 再加master eligible節點也可以的是嗎?
  • 7 、多加幾個以后, 把initial_master里的幾個去掉是不是也可以了?
  • 8、如果一個集群當前master為7,那他的quorum是4。es 是支持慢慢去掉節點,quorum慢慢降低的嗎?
  • 9、 那假如慢慢去掉了3個節點,原集群正常工作,那這三個節點重啟后網絡分區在一起了,那會不會自己形成集群啊?

希望大佬們點撥一下... ...

2、拆解一把

問題的核心是:seed_host 和 cluster.initial_master_nodes 的區別?

2.0 認知前提

為避免認知偏差,將常用英文詞匯做基礎釋義:

  • Discovery :發現是節點間在形成集群之前發現其他節點的過程。當你啟動Elasticsearch節點時,或者當節點認為主節點發生故障時,此過程將運行,並持續到找到主節點或選擇新的主節點為止。
  • master-eligible nodes:候選主節點
  • master-ineligible nodes:非候選主節點
  • coordinating-only nodes:僅協調節點
  • data-only nodes:僅數據節點
  • seed hosts providers:種子主機列表
  • voting configuration:投票配置
  • split brain:腦裂
  • initial quorum:初始仲裁——僅在整個集群首次啟動時才需要初始仲裁

2.1 主節點職責

主節點負責集群范圍內的輕量級操作,例如:

  • 創建或刪除索引

  • 跟蹤哪些節點是集群的一部分

  • 確定將哪些分片分配給哪些節點。

擁有穩定的主節點對於集群健康非常重要。

候選主節點通過主選舉過程成為主節點。

一個集群中:選舉后只有一個主節點。

2.2 腦裂

以下腦裂是我的通俗解釋:

假設在 2.1 選舉主節點過程中,一個集群中出現了 2個或者2個以上的主節點,也就是說一個集群形式上划分為兩個或兩個以上的孤立集群,這就被稱為腦裂。

2.3 候選主節點兩大基本任務

候選主節點必須合力完成的兩個基本任務:

  • 選舉主節點

  • 更改集群狀態

即時某些節點故障,也要保住以上兩活動正常運行。

2.4 投票配置

每個 Elasticsearch 集群都有一組投票配置,這是一組候選主節點的集合。

什么時候使用呢?

  • 第一:選舉主節點;

  • 第二:提交新的集群狀態。

什么時候做決策?——僅在投票配置中超過一半節點做出響應后才做決策。

通常:投票配置和集群中所有候選主節點集合相同。但,某些情況下可以不同。

以下是要強調的也是被問最多的問題之一:

  • 為確保集群仍然可用,請勿同時停止投票配置中的一半或更多節點。

  • 只要有一半以上的投票節點可用,集群就可以正常工作。

例如:

  • 如果有三個或四個候選主機節點,則集群可以容忍一個候選主節點不可用。

  • 如果有兩個或更少的候選主節點,則它們必須全部保持可用。

后面的實戰驗證舉例,你會進一步看到結論。

2.5 集群規划時設置奇數個候選主節點

集群中通常應有奇數個候選主節點。

如果有偶數個,Elasticsearch將其中一個排除在投票配置之外,以確保其大小為奇數。

換種通俗說法:

4個候選主節點和3個候選主節點本質一樣,只容許一個候選主節點失效。

2.6 discovery.seed_hosts  和 initial_master_nodes 作用

7.x 7.X 之前
discovery.seed_hosts discovery.zen.ping.unicast.hosts
cluster.initial_master_nodes minimum_master_nodes  min_master_count
  • discovery.seed_hosts 的來龍去脈

6.X 5.X對應名字:discovery.zen.ping.unicast.hosts。

看如下截圖,對比:除了名稱不同,釋義部分一模一樣。

圖片

如果多節點集群,discovery.seed_hosts 應該配置為候選主節點。

  • cluster.initial_master_nodes

這也是7.X的特性,區別於之前設置min_master_count候選主節點的個數。

白話文:設置候選主機節點的主機名稱列表。

在7.x節點上,discovery.zen.minimum_master_nodes設置是允許的,但被忽略。

集群首次啟動的時候,cluster.initial_master_nodes 必須設置為執行集群引導。

在集群初始化階段,cluster.initial_master_nodes 應該包含候選主節點的名稱,並在集群中每個候選主節點上進行定義。

本質區別:

  • cluster.initial_master_nodes:僅在集群首次啟動會使用。
  • discovery.seed_hosts:每次啟動都需要。

2.7 Discovery 過程解讀

Discovery 過程從一個或多個種子主機列表以及集群中已知的任何一個候選主節點地址開始。

該過程分兩個階段進行:

  • 首先,探測種子地址。

每個節點通過連接到每個地址並嘗試識別其連接的節點是否是候選主節點來探測種子地址。

  • 其次,如果成功,它將與遠程節點共享其所有已知的候選主機節點列表,並且遠程節點將依次與其做對等回應。

然后,該節點將探測剛剛發現的所有新節點,請求其對等節點,依此類推。

如果該節點不是候選主節點,則它將繼續此 Discovery 過程,直到發現了選舉的主節點為止。如果未發現選擇的主節點,則該節點將在默認值為 1s 之后重試。

如果該節點是候選主節點,則它將繼續此 Discovery 過程,直到它找到了選舉的主節點,或者它找到了足夠的候選主節點來完成選舉。同樣的,如果這兩種方法都沒有很快的進行,則該節點將在 1s 后重試。

這里有點繞,需要結合英文文檔多讀幾遍,加深 Discovery 理解。

2.8 elasticsearch.yml 配置注意

現在,7.X Elasticsearch 的生產部署需要至少在 elasticsearch.yml 配置文件中指定以下設置之一:

  • discovery.seed_hosts
  • discovery.seed_providers
  • cluster.initial_master_nodes
  • discovery.zen.ping.unicast.hosts
  • discovery.zen.hosts_provider

2.9  非候選主節點在 discovery  階段被忽略

在 7.X 之前早期版本中,有可能在 discovery 過程中使用非候選主節點作為種子節點或在符合條件的主機之間間接傳輸信息。

像這樣的依賴非候選主節點的集群非常脆弱,無法自動從某些故障中恢復。

7.X 版本之后,discovery 僅涉及集群中候選主節點,不會像早期版本一樣依賴於非候選主節點。

如何在7.X 中配置呢?應該在配置中將  discovery.seed_hosts 或者  discovery.seed_providers 設置為所有候選主節點的地址。

2.10 關於故障檢測超時時間

7.X 默認情況下,如果集群節點未能響應 3 個連續的 ping(每個 ping 在 10 秒后超時),則集群故障檢測子系統現在將其視為故障節點。

因此,響應時間超過 30 秒 的節點可能會從集群中刪除。

7.X 以前,每個ping的默認超時為 30 秒,因此,無響應的節點可能會在集群中保留 90 秒以上。

2.11  刪除候選主節點有時需要做排除投票

如果你希望從集群中刪除一半或更多的候選主節點,則必須首先使用投票配置排除API從投票配置中排除受影響的節點。

排除 API 如下:

POST _cluster/voting_config_exclusions?node_names=<node_names>
POST _cluster/voting_config_exclusions?node_ids=<node_ids>
DELETE _cluster/voting_config_exclusions

如果你同時刪除少於一半的候選主節點,則不需要做投票排除。

如果僅刪除非候選主節點(例如僅數據節點或僅協調節點),則不需要做投票排除。

同樣,如果將節點添加到集群,也不需要投票排除。

3、實踐一把

3.1 場景1:一主節點、一僅數據節點

數據節點配置:

圖片

  • seed host 和  initial_master_nodes 只設置主節點配置。

結果如下:

圖片

3.2 場景二:一主節點、二僅數據節點

兩個數據節點配置:

圖片

  • seed host 和  initial_master_nodes 只設置主節點配置。

    圖片

3.3 場景三:三個節點都是主節點同時也是數據節點

三節點相同配置如下:

圖片

圖片

注意,這時候,我把node-1 強制殺掉?大家猜會發生什么?

如果說宕機,你錯了!集群進行了重新選主:

圖片

結果如下:節點2 成為主節點。

圖片

實際業務場景不建議這么做,數據節點在沒有設置主節點角色:node.master: true 的前提下,成為了主節點。

3.4 場景四:三個節點都是主節點同時也是數據節點

三節點相同配置如下:

圖片

圖片

逐個kill 掉 節點2、節點 1 看看結果?

先干掉節點2:節點1成為了主節點。

圖片

再干掉節點1:集群已無法訪問和使用。

圖片

這個時候,錯誤日志如下:

核心錯誤說明:候選主節點要求至少 2個節點。

an election requires at least 2 nodes  .....  which is not a quorum.

詳細報錯如下:

 [node-3] master not discovered or elected yet, an election requires at least 2 nodes with ids from [0bozQB4VRZWB4TuzjRahAw, Z7PxWN_bQEeeI6KOlQT8pw, AWDZHrxaTd2qmOB1e8kadQ], have discovered [] which is not a quorum; discovery will continue using [172.21.0.14:9300, 172.21.0.14:9302] from hosts providers and [{node-3}{Z7PxWN_bQEeeI6KOlQT8pw}{ejRvW9egTrum3G5DrwmrIA}{172.21.0.14}{172.21.0.14:9303}{ml.machine_memory=8200851456, xpack.installed=true, ml.max_open_jobs=20}, {node-1}{AWDZHrxaTd2qmOB1e8kadQ}{FFIDQcynQMGHqPwCW9lFfw}{172.21.0.14}{172.21.0.14:9300}{ml.machine_memory=8200851456, ml.max_open_jobs=20, xpack.installed=true}] from last-known cluster state; node term 8, last-accepted version 92 in term 8

正如官方文檔所示:

為確保集群仍然可用,你不得同時停止投票配置中的一半或更多節點。只要有一半以上的投票節點可用,集群可以正常工作。

如前所述:投票配置中配置的就是候選主節點!

3.5 場景五:三個節點都是主節點同時也是數據節點

在老配置基礎上修改,注釋掉:initial_master_nodes 的配置。配置如下:

圖片

集群結果如下:

圖片

集群也能正常啟動。結合 2.6 小節看能更好理解一些。

4、再回答騰訊大佬的問題

  • 1、 seed_hosts里面一定是配置 master eligible節點嗎?

是的,必須候選主節點。

  • 2、還是說data節點也可以配置到 master eligible

理論可以,實際不推薦。

  • 3、是如何發現潛在機器的呢?

Discovery 過程就是發現過程。

  • 4、initial_master一定是master eligible節點吧?

是的。

  • 5、集群初始啟動時, 這幾個節點一定都要在是嗎?

大規模集群要注意:集群規划階段要考慮設置:奇數個候選主節點。

集群初始啟動階段之前候選主節點配置要設置合理。

  • 6 、初始的時候是不是可以配置一個, 然后集群初始化后, 再加master eligible節點也可以的是嗎?

可以,但不推薦。

如果多節點集群,建議一步到位。

  • 7 、多加幾個以后, 把initial_master里的幾個去掉是不是也可以了?

僅在集群首次啟動會使用,其他階段可以去掉。詳見案例五。

不過,規范管理起見,配置上不用動就可以了。

  • 8、如果一個集群當前master為7,那他的quorum是4。es 是支持慢慢去掉節點,quorum慢慢降低的嗎?

換個思維理解,這里如果有 7 個候選主節點,意味着至少要一半以上有效集群才能存活。

也就是干掉3個候選主節點,集群依然是存活狀態的。

  • 9、 那假如慢慢去掉了3個節點,原集群正常工作,那這三個節點重啟后網絡分區在一起了,那會不會自己形成集群啊?

不會,去掉的3個節點,還會繼續加入原來的集群啊!

5、小結

類似概念的確單純看文檔不好理解,甚至你看完本文還是有點糊塗。

不要為了區分概念而區分概念,實踐一把,把理論概念轉成實踐、再結合理論,就好理解了。

歡迎留言寫下你的思考!

參考:

https://www.elastic.co/guide/en/elasticsearch/reference/7.0/breaking-changes-7.0.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-voting.html8


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM