當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

白话Elasticsearch70-ES生产集群部署之production mode下启动时的bootstrap check

發布時間：2025/3/21 编程问答 69 豆豆

生活随笔收集整理的這篇文章主要介紹了白话Elasticsearch70-ES生产集群部署之production mode下启动时的bootstrap check 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

文章目錄

概述
官方文檔
什么是bootstrap check(啟動時檢查）?
development mode vs. production mode
heap size check
file descriptor check
maximum number of thread check
Max file size check
maximum size virtual memory check
maximum map count check
client jvm check
use serial collector check
system call filter check
OnError and OnOutOfMemoryError check
early-access check
G1 GC check
All permission check
Discovery configuration check

概述

繼續跟中華石杉老師學習ES，第69篇

課程地址： https://www.roncoo.com/view/55

官方文檔

https://www.elastic.co/guide/en/elasticsearch/reference/current/bootstrap-checks.html

什么是bootstrap check(啟動時檢查）?

經常會碰到一些es的用戶，遇到一些奇怪的問題，主要是因為他們沒有配置一些重要的設置。在es以前的老版本中，對這些設置錯誤的配置，會在日志里記錄一些warning告警。但是有時候用戶會忽略這些日志中的告警信息。為了確保說這些設置的錯誤配置告警信息可以引起用戶的注意，es的新版本中引入了bootstrap check，也就是啟動時檢查。

這些啟動時檢查操作，會檢查許多es和系統的設置，將這些配置的值跟es期望的安全值去進行比較。如果es在development mode下，那么失敗的檢查僅僅在日志中打印warning。如果es運行在生產模式下，任何啟動時檢查的失敗都會導致es拒絕啟動。

development mode vs. production mode

默認情況下，es綁定到localhost hostname，來進行http和內部通信。這對于下載es并簡單試用一下，包括日常的開發，都是非常方便的，但是對于生產環境是不行的。

如果要搭建一個es集群，es實例必須能夠通過內部通信協議互相連通，所必須綁定通信到一個外部的接口上。因此如果一個es實例沒有綁定通信到外部接口（默認情況下），那么就認為es是處于開發模式下。反之，如果綁定通信到外部接口，那么就是處于生產模式下。

下面的 single-node 了解就行，生產環境是不會用的。

可以通過http.host和transport.host，單獨配置http的傳輸。這就可以配置一個es實例通過http可達，但是卻不觸發生產模式。

因為有時用戶需要將通信綁定到外部解耦來測試client的調用。對于這種場景，es提供了single-node恢復模式（將discovery.type設置為single-node），配置過后，一個節點會選舉自己作為master，而且不會跟其他任何節點組成集群。

如果在生產模式下運行一個single node實例，就可以規避掉啟動時檢查（不要將通信綁定到外部接口，或者將通信綁定到外部接口，但是設置discovery type為single-node）。

在這種場景下，可以設置es.enforce.bootstrap.checks為true（通過jvm參數來設置），來強制bootstrap
check的執行。

https://www.elastic.co/guide/en/elasticsearch/reference/current/bootstrap-checks.html#bootstrap-checks

heap size check

https://www.elastic.co/guide/en/elasticsearch/reference/current/_heap_size_check.html

如果jvm啟動的時候設置的初始隊大小和最大堆大小不同，可能會導致es運行期間的暫停，因為jvm堆在系統運行期間可能會改變大小。為了避免這種jvm resize導致的es進程暫停，建議啟動jvm時，將初始堆大小和最大堆大小設置的相等。除此之外，如果bootstrap.memory_lock被啟用了，jvm會在啟動期間鎖定jvm的初始大小。

如果要通過heap size check，就必須合理設置heap size。 https://www.elastic.co/guide/en/elasticsearch/reference/current/heap-size.html

默認情況下，es的jvm堆的最小和最大大小都是1g。如果在生產環境中使用，應該配置合理的heap size確保es有足夠的堆內存可以使用。

在jvm.options中設置的Xms和Xmx會用來分配jvm堆內存帶澳。

這些設置的值依賴于服務器上可用的總內存大小。下面是一些最佳實踐的建議：

（1）將heap的最小和最大大小設置為一樣大
（2）es有更多的heap大小，就有更多的內存用來進行緩存，但是過大的jvm heap可能會導致長時間的gc停頓
（3）不要設置最大heap size超過物理內存的50%，很專業昂才能給核心的file system cache留下足夠的內存
（4）不要將Xmx設置超過32GB，否則jvm無法啟用compressed oops，將對象指針進行壓縮，確認日志里有heap size [1.9gb], compressed ordinary object pointers [true]
（5）更好的選擇是，heap size設置的小于zero-based compressed ooops，也就是26GB，但是有時也可以是30GB。通過-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode開啟對應，確認有heap address: 0x000000011be00000, size: 27648 MB, zero based Compressed Oops，而不是heap address: 0x0000000118400000, size: 28672 MB, Compressed Oops with base: 0x00000001183ff000
（6）在jvm.options文件中，可以通過如下方式來配置heap size

-Xms2g -Xmx2g

（（7）也可以通過ES_JAVA_OPTS環境變量來設置heap size

ES_JAVA_OPTS="-Xms2g -Xmx2g"

file descriptor check

https://www.elastic.co/guide/en/elasticsearch/reference/current/_file_descriptor_check.html

file descriptor是unix操作系統的一種數據結構，用來track打開的文件。在unix操作系統中，所有東西都是file。比如，file可以是物理文件，虛擬文件，或者網絡socket。

es需要大量的file descriptor，比如說每個shard都由多個segment和其他文件組成，還有跟其他節點之間的網絡通信連接。

file descriptor: https://www.elastic.co/guide/en/elasticsearch/reference/current/file-descriptors.html

因為es要使用大量的file descriptor，所以如果file descriptor耗盡的話，會是一場災難，甚至可能會導致數據丟失。盡量給es的file descriptor提升到65536，甚至更高。

可以在/etc/security/limits.conf中，設置nofile為65536

GET _nodes/stats/process?filter_path=**.max_file_descriptors

可以用上面這行代碼檢查每個node上的file descriptor數量

lucene會使用大量的文件，同時es也會使用大量的socket在節點間和client間進行通信，這些都是需要大量的file descriptor的。

但是通常來說，現在的linux操作系統，都是給每個進程默認的1024個file descriptor的，這對于一個es進程來說是遠遠不夠的。

我們需要將es進程的file descriptor增加到非常非常大，比如說65535個。一般需要根據我們的操作系統的文檔來查看如何設置file descriptor。

然后可以直接對es集群查看GET，來確認file descriptor的數量：

{"cluster_name": "elasticsearch","nodes": {"nLd81iLsRcqmah-cuHAbaQ": {"timestamp": 1471516160318,"name": "Marsha Rosenberg","transport_address": "127.0.0.1:9300","host": "127.0.0.1","ip": ["127.0.0.1:9300","NONE"],"process": {"timestamp": 1471516160318,"open_file_descriptors": 155,"max_file_descriptors": 10240, "cpu": {"percent": 0,"total_in_millis": 25084},"mem": {"total_virtual_in_bytes": 5221900288}}}} }

5、memory lock check

https://www.elastic.co/guide/en/elasticsearch/reference/current/_memory_lock_check.html

如果jvm進行一個major gc的話，那么就會涉及到heap中的每一個內存頁，此時如果任何一個內存頁被swap到了磁盤上，那么此時就會被swap回內存中。這就會導致很多的磁盤讀寫開銷，而這些磁盤讀寫開銷如果節省下來，可以讓es服務更多的請求。

有很多方法可以配置系統禁止swap。其中一種方法就是讓jvm去lock heap內存在物理內存中，設置bootstrap.memory_lock即可。

GET _nodes?filter_path=**.mlockall

檢查一下，mlockall是否開啟，如果是false，那么說明lock memory失敗了，而且日志里可能會有unable to lock jvm memory的字樣

可能就是因為運行es的用戶沒有lock memory的權限，此時就需要進行授權

/etc/security/limits.conf

設置memlock為unlimited即可完成授權

另外一個原因導致lock memory失敗，可能是因為臨時目錄，/tmp用noexec option來mount了

那么就需要設置ES_JAVA_OPTS，export ES_JAVA_OPTS="$ES_JAVA_OPTS -Djava.io.tmpdir=/path/to/temp/dir" 或者在jvm.options中設置這個參數

maximum number of thread check

https://www.elastic.co/guide/en/elasticsearch/reference/current/max-number-threads-check.html

es會將每個請求拆分成多個stage，然后將stage分配到不同的線程池中去執行。在es中有多個線程池來執行不同的任務。所以es會創建許多的線程。最大線程數量的檢查會確保說，es實例有權限去創建足夠的線程。如果要通過這個檢查，必須允許es進程能夠創建超過4096個線程。

/etc/security/limits.conf，在這個文件中，用nproc來設置

Max file size check

在Elasticsearch流程可以創建的文件的最大大小受到限制的系統上，這可能導致寫入失敗。

因此，這里最安全的選擇是最大文件大小不受限制，這就是最大文件大小引導檢查強制執行的內容。要通過最大文件檢查，必須配置系統以使Elasticsearch進程能夠寫入無限大小的文件。

這可以通過 /etc/security/limits.conf使用fsize設置來完成unlimited（請注意root用戶也要修改）。

maximum size virtual memory check

es使用mmap來將索引映射到es的address space中，這可以讓jvm heap外但是內存中的索引數據，可以有非常告訴的讀寫速度。因此es需要擁有unlimited address space。最大虛擬內存大小的檢查，會要求es進程有unlimited address space。

/etc/security/limits.conf，設置as為unlimited

maximum map count check

https://www.elastic.co/guide/en/elasticsearch/reference/current/_maximum_map_count_check.html

要高效使用mmap的話，es同樣要求創建許多memory-mapped area。因此要求linux內核允許進程擁有至少262144個memory-mapped area，需要通過sysctl設置vm.max_map_count至少超過262144。

client jvm check

https://www.elastic.co/guide/en/elasticsearch/reference/current/_client_jvm_check.html

jvm有兩種模式，client jvm和server jvm。

不同的jvm會用不同的編譯器來從java源碼生成可執行機器代碼。

client jvm被優化了來減少startup time和內存占用，

server jvm被優化了來最大化性能。

兩種jvm之間的性能區別是很明顯的。client jvm check會確保es沒有運行在client jvm下。必須使用server jvm模式來啟動es，而server jvm是默認的。

use serial collector check

https://www.elastic.co/guide/en/elasticsearch/reference/current/_use_serial_collector_check.html

針對不同的工作負載，jvm提供了不同的垃圾回收器。串行化垃圾回收期對于單cpu機器或者小內存，是很有效的。但是對于es來說，用串行化垃圾回收器，會成為一場性能上的災難。因此這個check會確保es沒有被配置使用串行化垃圾回收器。

es默認的就是cms垃圾回收器。

system call filter check

https://www.elastic.co/guide/en/elasticsearch/reference/current/_system_call_filter_check.html

es會根據不同的操作系統來安裝system call filter，用來阻止執行作為defense機制的fork相關system call，進而避免任意代碼執行的攻擊。

這個check會檢查是否允許system call filter，然后安裝這些system call filter。

避免bootstrap.system_call_filter設置為false。

OnError and OnOutOfMemoryError check

https://www.elastic.co/guide/en/elasticsearch/reference/current/_onerror_and_onoutofmemoryerror_checks.html

jvm參數，OnError和OnOutOfMemoryError允許在jvm遇到了fatal error或者是OutOfMemoryErro的時候，執行我們預定義的命令。

然而，默認情況下，es system call filter是啟用的，這些filter是阻止forking操作的。

因此，用OnError和OnOutOfMemroyError和system call filter是不兼容的。這個check會檢查，如果啟用了system call filter，還設置了這兩個jvm option，那么就不能啟動。所以不要在jvm option中設置這兩個參數。

early-access check

https://www.elastic.co/guide/en/elasticsearch/reference/current/_early_access_check.html

jdk提供了early-access快照，為即將到來的版本。這些版本不適合用作生產環境。這個check會檢查有沒有使用jdk的early-access快照版本。我們應該用jdk穩定版本，而不是試用版本。

G1 GC check

https://www.elastic.co/guide/en/elasticsearch/reference/current/_g1gc_check.html

jdk 8的jvm早期版本中的g1 gc，有已知的問題可能導致索引破損。在JDK 8u40之前的版本都有這個問題。這個check會檢查是否使用了那種早期的JDk版本。

All permission check

https://www.elastic.co/guide/en/elasticsearch/reference/current/_all_permission_check.html

所有權限檢查可確保引導過程中使用的安全策略不會將權限授予java.security.AllPermissionElasticsearch。以授予的所有權限運行等同于禁用安全管理器

Discovery configuration check

https://www.elastic.co/guide/en/elasticsearch/reference/current/_discovery_configuration_check.html

默認情況下，當Elasticsearch首次啟動時，它將嘗試發現在同一主機上運行的其他節點。如果在幾秒鐘內找不到任何選舉出的主節點，則Elasticsearch將形成一個包含所有其他已發現節點的集群。

無需在開發模式下進行任何額外配置就可以形成此群集很有用，但這不適用于生產，因為有可能形成多個群集并因此丟失數據。

此引導檢查可確保發現未使用默認配置運行。可以通過設置以下至少一個屬性來滿足：

discovery.seed_hosts discovery.seed_providers cluster.initial_master_nodes

總結

以上是生活随笔為你收集整理的白话Elasticsearch70-ES生产集群部署之production mode下启动时的bootstrap check的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：白话Elasticsearch69-ES
下一篇：白话Elasticsearch71-ES