Discovery模塊的配置 · Mastering Elasticsearch 中文版

## 節點發現模塊的配置 <div style="text-indent:2em;"> <p>我們已經多次提到，ElasticSearch創建的目的就是對應集群工作環境。這是跟與ElasticSearch功能類似的其它開源解決方案(比如solr)主要的不同點。其它解決方案也許同樣能或難或易地應用于多節點的分布式環境，但是對對于ElasticSearch來說，工作在分布式環境就是它每天的生活。由于節點發現機制，它最大程度簡化了集群的安裝和配置。</p> <p>該發現機制主要基于以下假設：集群由cluster.name設置項相同的節點自動連接而成。這就允許了同一個網段中存在多個獨立的集群。自動發現機制的缺點在于：如果有人忘記改變cluster.name的設置項，無意中連接到其它的某個集群。在這種情況下，ElasticSearch可能出于重新平衡集群狀態的考慮，將一些數據移動到了新加入的節點。當該節點被關閉，節點所在的集群中會有部分數據像出現魔法一樣憑空消失。 </p> <h4>Zen 發現機制</h4> <p>Zen 發現機制是ElasticSearch中默認的用來發現新節點的功能模塊，而且集群啟動后默認生效。Zen發現機制默認配置是用多播來尋找其它的節點。對于用戶而言，這是一極其省事的解決方案：只需啟動新的ElasticSearch節點即可，如果各個模塊工作正常，該節點就會自動添加到與節點中集群名字(cluster.name)一樣的集群，同時其它的節點都能感知到新節點的加入。如果節點添加不進去，你就應該檢查節點的publish_host屬性或者host屬性的設置，來確保ElasticSearch在監聽合適的網絡端口。 </p> <p> 有時由于某些原因，多播無法使用或者由于前面提到的一些原因，你不想使用它。在比較大的集群中，多播發現機制可能會產生太多不必要的流量開銷，這是不使用多播的一個充分理由。在這種情況下，Zen發現機制引入了第二種發現節點的方法：單播模式。讓我們在這個知識點上停留一段時間，了解這些模式的配置相關知識。 </p>  <div style="height:50px;width:650px;text-indent:0em;"> <div style="float:left;width:13px;height:100%; background:black;"> <img src="../lm.png" height="40px" width="13px" style="margin-top:5px;"/> </div> <div style="float:left;width:50px;height:100%;position:relative;"> <img src="../note.png" style="position:absolute; top:30%; "/> </div> <div style="float:left; width:550px;height:100%;"> <p style="font-size:13px;margin-top:5px;">如果想知道關于單播和多播ping方法更多的不同點，請參考:http://en.wikipedia.org/wiki/Multicastand http://en.wikipedia.org/wiki/Unicast. </p> </div> <div style="float:left;width:13px;height:100%;background:black;"> <img src="../rm.png" height="40px" width="13px" style="margin-top:5px;"/> </div> </div>  <h4>多播</h4> <p>前面已經提到，這是默認的網絡傳輸模式。當節點并非集群的一部分時(比如節點只是剛剛啟動或者重啟 )，它會發送一個多播的ping請求到網段中，該請求只是用來通知所有能連接到節點和集群它已經準備好加入到集群中。關于多播發送，Zen發現模塊暴露出如下的設置項： <ul> <li>discovery.zen.ping.multicast.address(默認是所有的網絡接口):屬性值是接口的地址或者名稱。</li> <li>discovery.zen.ping.multicast.port(默認是54328):端口用于網絡通信。</li> <li>discovery.zen.ping.multicast.group(默認是:224.2.2.4):代表多播通信的消息接收地。</li> <li>discovery.zen.ping.multicast.buffer\_size(默認是:2048byte):</li> <li>discovery.zen.ping.multicast.ttl(默認是3):它代表多播信息的生存時間。只要數據包通過的路由，TTL值就廢棄了。通過該參數可以限制信息接收的區域。注意路由器可以指定一個類似于TTL值的閾值來確保TTL值并非唯一可以限制數據包可以跳過路由器的因素。</li> <li>discovery.zen.ping.multicast.enabled(默認值為true):設置該屬性值的值為false就關閉了多播傳輸。如果計劃使用單播傳輸，就應該關閉多播傳輸。 </li> </ul> </p> <h4>單播</h4> <p>當像前面描述的那樣關閉多播，就可以安全地使用單播。當節點不是集群的一部分時(比如節點重啟，啟動或者由于某些錯誤從集群中斷開)，節點會發送一個ping請求到事先設置好的地址中，來通知集群它已經準備好加入到集群中了。相關的配置項很簡單，如下： <ul> <li>discovery.zen.ping.unicats.hosts:該配置項代表集群中初始結點的主機列表。每個主機由名字(或者IP地址)加端口或者端口范圍組成。比如，該屬性值可以是如下的寫法：["master1","master2:8181", "master3[80000-81000]"] ，因此用于單播節點發現的主機列表基本上不必是集群中的所有節點，因為一個節點一旦連接到集群中的一個節點，這個連接信息就會發送集群中其它所有的節點。 </li> <li> discovery.zen.ping.unicats.concurrent\_connects(默認值: 10):該屬性指定節點發現模塊能夠開啟的單播最大并發連接數。</li> </ul> </p> <h4>主節點候選節點個數的最小化</h4> <p>對于節點發現模塊來說，discovery.zen.minimum\_master\_nodes無疑是最重要的一個屬性。該屬性允許用戶設置集群選舉時主節點的候選節點數，該數值是組建集群所必須的。該屬性存在的意義就是解決集群的裂腦現象。由于某些故障(比如網絡故障)，網絡中原來的集群分成了多個部分，每個部分的集群名字都相同，這種現象就是集群的裂腦現象。你可以想象兩個同名的集群(本應該是一個)索引著不同的數據，很容易就會出現問題。因此，專家建議使用discovery.zen.minimum\_master\_nodes屬性，并且該屬性值的下限是集群節點總數的50%+1。比如，如果你們集群有9個節點，所有的節點都可以作為主結點，我們就需要設置discovery.zen.minimum\_master\_nodes屬性值為5。即集群中至少要有5個符合選舉條件的節點，才能夠選擇出一個主節點。 </p> <h4>Zen發現機制的故障檢測</h4> <p>ElasticSearch運行時會啟動兩個探測進程。一個進程用于從主節點向集群中其它節點發送ping請求來檢測節點是否正常可用。另一個進程的工作反過來了，其它的節點向主節點發送ping請求來驗證主節點是否正常且忠于職守。但是，如果我們的網絡很慢或者節點分布在不同的主機，默認的配置可能顯得力不從心。因此，ElasticSearch的節點發現模塊開放出了如下的屬性： <ul> <li>discovery.zen.fd.ping_interval:該屬性的默認值是1s,指定了本節點隔多久向目標結點發送一次ping請求。</li> <li>discovery.zen.fd.ping_timeout:該屬性的默認值是30s,指定了節點等待ping請求的回復時間。如果節點百分百可用或者網絡比較慢，可能就需要增加該屬性值。</li> <li>discovery.zen.fd.ping_retries:該屬性值默認為3，指定了在目標節點被認定不可用之前ping請求重試的次數。用戶可以在網絡丟包比較嚴重的網絡狀況下增加該屬性值(或者修復網絡狀況)。</li> </ul> </p> <h4>Amazon EC2 discovery</h4> <blockquote> 關于Amazon EC2 discovery相關內容暫時不翻譯 </blockquote> <h4>本地Gateway</h4> <p>隨著ElasticSearch 0.20版本發布(有些在0.19版本中)，除默認的local類型外，其它所有的gateway類型，都將廢棄并且不建議用戶使用，因為在未來的ElasticSearch版本中，這些類型將被移除。如果想避免出現整個數據集重新索引的情況，用戶應該只使用local類型的gateway，這也是我們為什么不探討所有其它類型gateway的原因。 local類型的gateway使用本機硬盤存儲節點上的元數據、mappings數據、索引數據。為了能夠使用這種gateway類型，需要服務器的硬盤有足夠的空間在不使用內存緩存的情況下存儲所有數據。local類型的gateway持久化數據的方式與其它gateway有所不同，為了確保在寫數據的過程中，數據不丟失，它采用同步的方式來完成寫數據的功能。 </p>  <div style="height:50px;width:650px;text-indent:0em;"> <div style="float:left;width:13px;height:100%; background:black;"> <img src="../lm.png" height="40px" width="13px" style="margin-top:5px;"/> </div> <div style="float:left;width:50px;height:100%;position:relative;"> <img src="../note.png" style="position:absolute; top:30%; "/> </div> <div style="float:left; width:550px;height:100%;"> <p style="font-size:13px;margin-top:5px;">如果想設置集群使用的gateway類型，用戶需要使用gateway.type屬性，默認情況下該屬性值為local </p> </div> <div style="float:left;width:13px;height:100%;background:black;"> <img src="../rm.png" height="40px" width="13px" style="margin-top:5px;"/> </div> </div>  <h4>local類型gateway的備份</h4> <p>ElasticSearch直到0.90.5版本(包括該版本)都不支持存儲在local類型gateway中數據的自動備份。然而，做數據備份是至關重要的，比如，如果想把集群升級到一個比較新的版本，如果升級出現了一些問題，就需要回滾操作了。為了完成上述的操作，需要執行如下的步驟： <ul> <li>停止發生在ElasticSearch集群中的數據索引操作(這可能意味著停止rivers或者任何向ElasticSearch集群發送數據的應用)</li> <li>用Flush API刷新所有還沒有提交的數據。</li> <li>為集群中的每一個分片至少創建一個拷貝，萬一出現問題，也能找回數據。當然，如果希望盡可能簡單地解決問題，也可以復制整個集群中每個節點的所有數據作為備用集群。</li> </ul> </p> <h4>恢復機制的配置</h4> <p>我們已經提到可以使用gateway來配置ElasticSearch恢復過程的行為,但是除外之外，ElasticSearch還允許用戶自己配置恢復過程。在第4章分布式索引構架的改變分片的默認分配方式一節中，我們已經提到一些恢復功能的配置，但是，我們認為在gateway和recovery相關的章節中討論這些用到的屬性是最合適的。 </p> <h4>cluster-level 恢復機制的配置</h4> <p>絕大多數恢復機制都是定義在集群層面的，用戶通過為恢復模塊設置通用的規則來控制恢復模塊的工作。這些設置項如下： <ul> <li>indices.recovery.concurrent\_streams:該屬性的默認值為3，表明從數據源恢復分片數據時，允許同時打開的數據流通道。該值越大，網絡層的壓力也就越大，同時恢復的速度也就越快，當然恢復速度與網絡使用量和總的吞吐量也有關系。 <li> <li>indices.recovery.max\_bytes\_per\_sec:該屬性默認設置為20MB，表示分片在恢復過程中每秒傳輸的最大數據量。要想關閉傳輸量的限制，用戶需要設置該屬性值為0。與并發流的功能相似，該屬性允許用戶在恢復過程中控制網絡的流量。設置該屬性一個比較大的值會導致網絡變得繁忙，當然恢復過程也會加快。<li> <li>indices.recovery.compress:該屬性值默認為true，允許用戶自行決定在恢復過程是否對數據進行壓縮。設置該屬性值為false可以降低CPU的壓力，與此同時，會導致網絡需要傳輸更多的數據。 <li> <li>indices.recovery.file\_chunk\_size:該屬性值指定了用于從源數據復制到分片時，每次復制的數據塊的大小。默認值是512KB,同時如果indices.recovery.compress屬性設置為true，數據會被壓縮。 <li> <li>indices.recovery.translog\_ops:該屬性值默認為1000，指定了在恢復過程中，單個請求中分片間傳輸的事務日志的行數。<li> <li>indices.recovery.translog\_size: 該屬性指定了從源數據分片復制事務日志數據時每次處理的數據塊的大小。默認值為512KB，同時如果如果indices.recovery.compress屬性設置為true，數據會被壓縮。 <li> </ul> </p>  <div style="height:50px;width:650px;text-indent:0em;"> <div style="float:left;width:13px;height:100%; background:black;"> <img src="../lm.png" height="40px" width="13px" style="margin-top:5px;"/> </div> <div style="float:left;width:50px;height:100%;position:relative;"> <img src="../note.png" style="position:absolute; top:30%; "/> </div> <div style="float:left; width:550px;height:100%;"> <p style="font-size:13px;margin-top:5px;">在ElasticSearch 0.90.0版本前，曾用到indices.recovery.max\_size\_per\_sec屬性，但是在隨后的版本中，該屬性值被廢棄了，由indices.recovery.max\_bytes\_per\_sec屬性替代。然而，如果使用0.90.0版本前的ElasticSearch，還是有必要記住這個屬性。 </p> </div> <div style="float:left;width:13px;height:100%;background:black;"> <img src="../rm.png" height="40px" width="13px" style="margin-top:5px;"/> </div> </div>  <p>上述的所有屬性都可以通過集群的update API或者elasticsearch.yml來設置生效。</p> <h4>index-level 恢復機制的配置</h4> <p>除了前面提到的屬性，還有一個可以作用于單個索引的屬性。該屬性可以在elasticsearch.yml文件中設置，也可以用索引更新的API來設置，它是index.recovery.initial\_shards。通常情況下，當集群中還存在著不低于quorum數量的分片，并且這些分片都可進行分配時，ElasticSearch只會恢復一個特殊的分片。quorum數量是指總的分片數量加一。通過使用index.recovery.initial\_shards屬性時，用戶可以改變ElasticSearch中quorum的實際分片數量。該屬性可設置如下值： <ul> <li>quorum: 該值意味著集群中至少有(分片總數的50%+1)個分片存在并且可分配。</li> <li>quorum-1:該值意味著集群中至少有(分片總數的50%-1)個分片存在并且可分配。</li> <li>full:該值意味著集群中所有的分片都必須存在并且可分配。</li> <li>full-1:該值意味著集群中至少有(分片總數-1)個分片必須存在并且可分配。</li> <li>整數值:表示可設置為任意的整數值，比如1,2或者5，表示至少需要存在且可分配的分片數。比如，屬性值為2，表示最少需要2個分片存在，同時ElasticSearch中至少需要2個分片可分配。</li> </ul> 了解該屬性值的作用總會有用上的一天，盡管在絕大多數場景中使用默認值就足夠了。 </p> </div>