102_es生產(chǎn)集群部署之production mode下啟動時的bootstrap check

1卑惜、bootstrap check

經(jīng)常會碰到一些es的用戶边坤，遇到一些奇怪的問題晦墙，主要是因為他們沒有配置一些重要的設(shè)置。在es以前的老版本中叽掘，對這些設(shè)置錯誤的配置勉躺，會在日志里記錄一些warning告警。但是有時候用戶會忽略這些日志中的告警信息瓮下。為了確保說這些設(shè)置的錯誤配置告警信息可以引起用戶的注意翰铡，es的新版本中引入了bootstrap check，也就是啟動時檢查讽坏。

這些啟動時檢查操作锭魔，會檢查許多es和系統(tǒng)的設(shè)置，將這些配置的值跟es期望的安全值去進行比較路呜。如果es在development mode下迷捧，那么失敗的檢查僅僅在日志中打印warning。如果es運行在生產(chǎn)模式下拣宰，任何啟動時檢查的失敗都會導(dǎo)致es拒絕啟動党涕。

2、development mode vs. production mode

默認情況下巡社，es綁定到localhost hostname膛堤，來進行http和內(nèi)部通信。這對于下載es并簡單試用一下晌该，包括日常的開發(fā)肥荔，都是非常方便的，但是對于生產(chǎn)環(huán)境是不行的朝群。如果要組件一個es集群燕耿，es實例必須能夠通過內(nèi)部通信協(xié)議互相連通，所必須綁定通信到一個外部的接口上姜胖。因此如果一個es實例沒有綁定通信到外部接口（默認情況下）誉帅，那么就認為es是處于開發(fā)模式下。反之右莱，如果綁定通信到外部接口蚜锨，那么就是處于生產(chǎn)模式下。

可以通過http.host和transport.host慢蜓，單獨配置http的傳輸亚再。這就可以配置一個es實例通過http可達，但是卻不觸發(fā)生產(chǎn)模式晨抡。

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

如果在生產(chǎn)模式下運行一個single node實例伪朽，就可以規(guī)避掉啟動時檢查（不要將通信綁定到外部接口轴咱，或者將通信綁定到外部接口，但是設(shè)置discovery type為single-node）烈涮。在這種場景下朴肺，可以設(shè)置es.enforce.bootstrap.checks為true（通過jvm參數(shù)來設(shè)置），來強制bootstrap check的執(zhí)行坚洽。

3戈稿、heap size check

如果jvm啟動的時候設(shè)置的初始隊大小和最大堆大小不同，可能會導(dǎo)致es運行期間的暫停讶舰，因為jvm堆在系統(tǒng)運行期間可能會改變大小鞍盗。為了避免這種jvm resize導(dǎo)致的es進程暫停，建議啟動jvm時跳昼，將初始堆大小和最大堆大小設(shè)置的相等般甲。除此之外，如果bootstrap.memory_lock被啟用了鹅颊，jvm會在啟動期間鎖定jvm的初始大小敷存。

如果要通過heap size check，就必須合理設(shè)置heap size堪伍。

默認情況下比肄，es的jvm堆的最小和最大大小都是2g肩榕。如果在生產(chǎn)環(huán)境中使用，應(yīng)該配置合理的heap size確保es有足夠的堆內(nèi)存可以使用呢灶。

在jvm.options中設(shè)置的Xms和Xmx會用來分配jvm堆內(nèi)存帶澳撮竿。

這些設(shè)置的值依賴于服務(wù)器上可用的總內(nèi)存大小玛臂。下面是一些最佳實踐的建議：

（1）將heap的最小和最大大小設(shè)置為一樣大
（2）es有更多的heap大小画舌，就有更多的內(nèi)存用來進行緩存兵拢，但是過大的jvm heap可能會導(dǎo)致長時間的gc停頓
（3）不要設(shè)置最大heap size超過物理內(nèi)存的50%，很專業(yè)昂才能給核心的file system cache留下足夠的內(nèi)存
（4）不要將Xmx設(shè)置超過32GB吮廉，否則jvm無法啟用compressed oops睹栖，將對象指針進行壓縮，確認日志里有heap size [1.9gb], compressed ordinary object pointers [true]
（5）更好的選擇是茧痕，heap size設(shè)置的小于zero-based compressed ooops，也就是26GB恼除，但是有時也可以是30GB踪旷。通過-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode開啟對應(yīng)曼氛，確認有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環(huán)境變量來設(shè)置heap size

ES_JAVA_OPTS="-Xms2g -Xmx2g"

4舀患、file descriptor check

file descriptor是unix操作系統(tǒng)的一種數(shù)據(jù)結(jié)構(gòu)，用來track打開的文件气破。在unix操作系統(tǒng)中聊浅，所有東西都是file。比如现使，file可以是物理文件低匙，虛擬文件，或者網(wǎng)絡(luò)socket碳锈。es需要大量的file descriptor顽冶，比如說每個shard都由多個segment和其他文件組成，還有跟其他節(jié)點之間的網(wǎng)絡(luò)通信連接售碳。

因為es要使用大量的file descriptor强重，所以如果file descriptor耗盡的話，會是一場災(zāi)難贸人，甚至可能會導(dǎo)致數(shù)據(jù)丟失间景。盡量給es的file descriptor提升到65536，甚至更高艺智。

可以在/etc/security/limits.conf中倘要，設(shè)置nofile為65536

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

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

lucene會使用大量的文件，同時es也會使用大量的socket在節(jié)點間和client間進行通信力惯，這些都是需要大量的file descriptor的碗誉。但是通常來說，現(xiàn)在的linux操作系統(tǒng)父晶，都是給每個進程默認的1024個file descriptor的哮缺，這對于一個es進程來說是遠遠不夠的。

我們需要將es進程的file descriptor增加到非常非常大甲喝，比如說65535個尝苇。一般需要根據(jù)我們的操作系統(tǒng)的文檔來查看如何設(shè)置file descriptor。然后可以直接對es集群查看GET埠胖，來確認file descriptor的數(shù)量：

{
"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

如果jvm進行一個major gc的話，那么就會涉及到heap中的每一個內(nèi)存頁直撤，此時如果任何一個內(nèi)存頁被swap到了磁盤上非竿，那么此時就會被swap回內(nèi)存中。這就會導(dǎo)致很多的磁盤讀寫開銷谋竖，而這些磁盤讀寫開銷如果節(jié)省下來红柱，可以讓es服務(wù)更多的請求承匣。有很多方法可以配置系統(tǒng)禁止swap。其中一種方法就是讓jvm去lock heap內(nèi)存在物理內(nèi)存中锤悄，設(shè)置bootstrap.memory_lock即可韧骗。

GET _nodes?filter_path=**.mlockall

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

可能就是因為運行es的用戶沒有l(wèi)ock memory的權(quán)限隶症，此時就需要進行授權(quán)

/etc/security/limits.conf

設(shè)置memlock為unlimited即可完成授權(quán)

另外一個原因?qū)е耹ock memory失敗政模，可能是因為臨時目錄，/tmp用noexec option來mount了

那么就需要設(shè)置ES_JAVA_OPTS沿腰，export ES_JAVA_OPTS="$ES_JAVA_OPTS -Djava.io.tmpdir=/path/to/temp/dir"

或者在jvm.options中設(shè)置這個參數(shù)

6览徒、maximum number of thread check

es會將每個請求拆分成多個stage，然后將stage分配到不同的線程池中去執(zhí)行颂龙。在es中有多個線程池來執(zhí)行不同的任務(wù)习蓬。所以es會創(chuàng)建許多的線程。最大線程數(shù)量的檢查會確保說措嵌，es實例有權(quán)限去創(chuàng)建足夠的線程躲叼。如果要通過這個檢查，必須允許es進程能夠創(chuàng)建超過2048個線程企巢。

/etc/security/limits.conf枫慷，在這個文件中，用nproc來設(shè)置

7浪规、maximum size virtual memory check

es使用mmap來將索引映射到es的address space中或听，這可以讓jvm heap外但是內(nèi)存中的索引數(shù)據(jù)，可以有非常告訴的讀寫速度笋婿。因此es需要擁有unlimited address space誉裆。最大虛擬內(nèi)存大小的檢查，會要求es進程有unlimited address space缸濒。

/etc/security/limits.conf足丢，設(shè)置as為unlimited

8、maximum map count check

要高效使用mmap的話庇配，es同樣要求創(chuàng)建許多memory-mapped area斩跌。因此要求linux內(nèi)核允許進程擁有至少262144個memory-mapped area，需要通過sysctl設(shè)置vm.max_map_count至少超過262144捞慌。

9耀鸦、client jvm check

jvm有兩種模式，client jvm和server jvm啸澡。不同的jvm會用不同的編譯器來從java源碼生成可執(zhí)行機器代碼揭糕。client jvm被優(yōu)化了來減少startup time和內(nèi)存占用萝快，server jvm被優(yōu)化了來最大化性能。兩種jvm之間的性能區(qū)別是很明顯的著角。client jvm check會確保es沒有運行在client jvm下。必須使用server jvm模式來啟動es旋恼，而server jvm是默認的吏口。

10、use serial collector check

針對不同的工作負載冰更，jvm提供了不同的垃圾回收器产徊。串行化垃圾回收期對于單cpu機器或者小內(nèi)存，是很有效的蜀细。但是對于es來說舟铜，用串行化垃圾回收器，會成為一場性能上的災(zāi)難奠衔。因此這個check會確保es沒有被配置使用串行化垃圾回收器谆刨。es默認的就是cms垃圾回收器。

11归斤、system call filter check

es會根據(jù)不同的操作系統(tǒng)來安裝system call filter痊夭，用來阻止執(zhí)行作為defense機制的fork相關(guān)system call，進而避免任意代碼執(zhí)行的攻擊脏里。這個check會檢查是否允許system call filter她我，然后安裝這些system call filter。避免bootstrap.system_call_filter設(shè)置為false迫横。

12番舆、OnError and OnOutOfMemoryError check

jvm參數(shù)，OnError和OnOutOfMemoryError允許在jvm遇到了fatal error或者是OutOfMemoryErro的時候矾踱，執(zhí)行我們預(yù)定義的命令恨狈。然而，默認情況下介返，es system call filter是啟用的拴事，這些filter是阻止forking操作的。因此圣蝎，用OnError和OnOutOfMemroyError和system call filter是不兼容的刃宵。這個check會檢查，如果啟用了system call filter徘公，還設(shè)置了這兩個jvm option牲证，那么就不能啟動。所以不要在jvm option中設(shè)置這兩個參數(shù)关面。

13坦袍、early-access check

jdk提供了early-access快照十厢，為即將到來的版本。這些版本不適合用作生產(chǎn)環(huán)境捂齐。這個check會檢查有沒有使用jdk的early-access快照版本蛮放。我們應(yīng)該用jdk穩(wěn)定版本，而不是試用版本奠宜。

14包颁、G1 GC check

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