怎么在生產(chǎn)環(huán)境運(yùn)行Elasticsearch

這篇文章主要講解了“怎么在生產(chǎn)環(huán)境運(yùn)行Elasticsearch”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“怎么在生產(chǎn)環(huán)境運(yùn)行Elasticsearch”吧！

基礎(chǔ)知識：集群，節(jié)點(diǎn)，索引和分片

如果你是 Elasticsearch(ES)新手，我想先解釋一些基本概念。本節(jié)完全不涉及最佳實(shí)踐，主要側(cè)重于解釋術(shù)語。大多數(shù)人可以直接跳過本節(jié)。

Elasticsearch 是用于運(yùn)行 Apache Lucene(基于 Java 的搜索引擎)分布式管理框架。Lucene  是實(shí)際保存數(shù)據(jù)并進(jìn)行索引和搜索的地方。ES 位于它之上，讓你可以并行運(yùn)行數(shù)千個(gè) Lucene 實(shí)例。

ES 的最高級別單元是集群(cluster)。集群是 ES 節(jié)點(diǎn) 和索引的集合。

節(jié)點(diǎn) (Node) 是 ES 的實(shí)例。它可以是單個(gè)服務(wù)器，也可以是服務(wù)器上運(yùn)行的 一個(gè) ES 進(jìn)程。服務(wù)器和節(jié)點(diǎn)不同，一個(gè) VM 或物理服務(wù)器可以包含許多  ES 進(jìn)程，每個(gè) ES 進(jìn)程是一個(gè)節(jié)點(diǎn)。節(jié)點(diǎn)只可以加入一個(gè)集群。節(jié)點(diǎn)有不同類型(type)，其中最值得關(guān)注的兩個(gè)類型是數(shù)據(jù)節(jié)點(diǎn)(data  node)和主候選節(jié)點(diǎn)( Master-Eligible  node)。一個(gè)節(jié)點(diǎn)可以同時(shí)具有多種類型。數(shù)據(jù)節(jié)點(diǎn)運(yùn)行所有數(shù)據(jù)操作，即存儲、索引和檢索數(shù)據(jù)。主候選節(jié)點(diǎn)具有投票 master  的權(quán)限，用于管理集群和索引。

索引(Index)是對數(shù)據(jù)的高級抽象，索引本身不保存數(shù)據(jù)，它們只是實(shí)際存儲數(shù)據(jù)的另一種抽象。對數(shù)據(jù)執(zhí)行的任何操作(例如插入，刪除，建立索引和搜索)都會對索引產(chǎn)生影響。索引可以完全屬于一個(gè)集群，并且由分片(  shard) 組成。

分片(Shard)是 Apache Lucene  的實(shí)例。一個(gè)分片可以容納許多文檔。分片是數(shù)據(jù)存儲，索引和搜索的實(shí)際對象。分片只屬于一個(gè)節(jié)點(diǎn)和索引。分片有兩種類型：primary 和  replica，它們基本上是完全相同的，擁有相同的數(shù)據(jù)，并且搜索并行運(yùn)行在所有分片。在擁有相同數(shù)據(jù)的所有分片中，其中一個(gè)屬于  primary。這是唯一可以接受索引請求的分片。如果節(jié)點(diǎn)中的主分片掛了，副本將接管并成為主分片。然后，ES 將創(chuàng)建一個(gè)新的副本并復(fù)制數(shù)據(jù)。

總結(jié)一下，我們整理得到下圖：

更深入了解 Elasticsearch

如果你想運(yùn)行一個(gè)系統(tǒng)，相信你需要了解該系統(tǒng)。在本節(jié)中，我將解釋 Elasticsearch  的各個(gè)部分，如果想在生產(chǎn)中進(jìn)行管理，我相信你需要理解它。本節(jié)也不牽涉到具體建議，后文會介紹。本節(jié)目的只是為了介紹必要的背景。

Quorum

理解 Elasticsearch  是一個(gè)(有缺陷的)選舉體系非常重要。節(jié)點(diǎn)投票決定誰應(yīng)該管理它們，即主節(jié)點(diǎn)。主節(jié)點(diǎn)運(yùn)行大量集群管理進(jìn)程，并且在許多事務(wù)方面擁有最終決策權(quán)。ES  選舉是有缺陷的，是因?yàn)橹挥幸恍〔糠止?jié)點(diǎn)，即主候選(master-eligible)節(jié)點(diǎn)才具有投票權(quán)。主候選節(jié)點(diǎn)是通過以下配置啟用：

node.master: true

在集群啟動或主節(jié)點(diǎn)離開群集時(shí)，所有符合主選舉條件的節(jié)點(diǎn)都會開始選舉新的主節(jié)點(diǎn)。為此，你需要具有 2n + 1  個(gè)主候選節(jié)點(diǎn)。否則，可能會出現(xiàn)腦裂情況，比如同時(shí)兩個(gè)節(jié)點(diǎn)獲得 50% 的選票，將會導(dǎo)致兩個(gè)分區(qū)之一中的所有數(shù)據(jù)丟失。為了不發(fā)生這種情況。你需要 2n + 1  個(gè)符合主候選的節(jié)點(diǎn)。

節(jié)點(diǎn)如何加入集群

當(dāng) ES 節(jié)點(diǎn)啟動時(shí)，它在廣闊世界中獨(dú)自存在。它怎么知道它屬于哪個(gè)集群?有不同的方法可以完成此操作，如今大多使用種子主機(jī)(Seed  Host)的方法來實(shí)現(xiàn)。

基本上，Elasticsearch  節(jié)點(diǎn)會不斷地就他們所見過的所有其他節(jié)點(diǎn)進(jìn)行通訊。因此一個(gè)節(jié)點(diǎn)最初只需要了解幾個(gè)其他節(jié)點(diǎn)即可了解整個(gè)集群。讓我們來看一個(gè)三節(jié)點(diǎn)集群的示例：

初始狀態(tài)

最初，節(jié)點(diǎn) A 和 C 只知道 B。B 是種子主機(jī)。種子主機(jī)要么以配置文件的形式提供給 ES，要么直接放入 elasticsearch.yml  中。

節(jié)點(diǎn) A 與 B 連接并交換信息

一旦節(jié)點(diǎn) A 連接到 B，B 就知道 A 的存在。對于 A 而言，沒有任何變化。

節(jié)點(diǎn) C 連接并與 B 共享信息

現(xiàn)在，C 連上來。一旦發(fā)生這種情況，B 就會告訴 C 有 A 的存在。C 和 B 現(xiàn)在知道群集中的所有節(jié)點(diǎn)。一旦 A 重新連接到 B，它也將了解 C  的存在。

段和段合并

上面我說過數(shù)據(jù)存儲分片中，這只是部分正確。最終數(shù)據(jù)是以文件的形式存儲在文件系統(tǒng)中。在 Lucene 和 Elasticsearch  中，這些文件稱為段(Segment)。一個(gè)分片將具有一到數(shù)千個(gè)段。

同樣，段是實(shí)際的真實(shí)文件，你可以在 Elasticsearch 安裝的 data  目錄中查看它。這意味著使用段存在開銷。如果要查看段，則必須找到文件并打開它。這意味著需要打開許多文件，并且將會有很多開銷。Lucene  中的段是不可變的，這是個(gè)問題。它們只能寫一次，然后就不能改了。反過來，這意味著你放入 ES  中的每個(gè)文檔都將創(chuàng)建一個(gè)僅包含這個(gè)文檔的段。顯然，一個(gè)擁有十億個(gè)文檔的集群具有十億個(gè)段，這意味著文件系統(tǒng)上確實(shí)有十億個(gè)文件，這樣理解對嗎?非也。

在后臺，Lucene 進(jìn)行持續(xù)的段合并，它不能更改段，但是可以使用兩個(gè)較小段的數(shù)據(jù)合并創(chuàng)建新的段。

這樣，lucene 會不斷嘗試使段數(shù)(文件數(shù)，即開銷)保持較小。你也可以使用強(qiáng)制合并。

消息路由

在 Elasticsearch 中，你可以對集群中的任何節(jié)點(diǎn)運(yùn)行任何命令，返回結(jié)果是相同的。有趣的是，文檔最終將只存在于一個(gè)主分片及其副本中，而 ES  不知道它在哪里。沒有一個(gè)映射來記錄某個(gè)文檔位于哪個(gè)分片中。

當(dāng)執(zhí)行搜索時(shí)，獲取請求的 ES 節(jié)點(diǎn)會將其廣播到索引中的所有分片。即主分片及所有副本。這些分片然后會在包含該文檔的所有段中進(jìn)行查找。

當(dāng)執(zhí)行插入時(shí)，ES 節(jié)點(diǎn)將隨機(jī)選擇一個(gè)主分片并將文檔放在其中。然后將其寫入該主分片及其所有副本。

如何在生產(chǎn)環(huán)境運(yùn)行 Elasticsearch?

本節(jié)是實(shí)踐部分。我前面提到，我管理 ES 的主要目的是為了記錄日志，本文將盡力避免這種傾向的影響，但有可能會失敗。

大小

需要提出并隨后回答自己的第一個(gè)問題是關(guān)于大小調(diào)整。你需要多少規(guī)模的 ES 集群?

內(nèi)存

我首先說的是 RAM，因?yàn)?RAM 將限制所有其他資源。

堆

ES 用 Java 編寫，Java 使用堆，你可以將其視為 Java  保留的內(nèi)存。如果將所有堆的重要因素都列出，會使這個(gè)文檔的大小增加三倍，所以我將介紹最重要的部分，即堆大小。

盡量使用更多內(nèi)存，但堆大小不得超過 30G。

有一個(gè)很多人都不知道的關(guān)于堆的秘密：堆中的每個(gè)對象都需要一個(gè)唯一的地址，即一個(gè)對象指針。該地址的長度是固定的，這意味著可以尋址的對象數(shù)量是有限的。簡單一點(diǎn)來描述就是，超出某個(gè)范圍時(shí)，Java  將開始使用壓縮的對象指針而不是未壓縮的對象指針。這意味著每個(gè)內(nèi)存訪問都將涉及其他步驟，這會嚴(yán)重拖慢速度。因此你 100% 不需要設(shè)置超過此閾值(大約  32G)。

我曾經(jīng)整整一個(gè)星期都呆在一個(gè)黑暗的房間里，沒做別的，只是使用 esrally 基準(zhǔn)化測試 Elasticsearch 在不同文件系統(tǒng)、堆大小、文件和  BIOS 設(shè)置組合。長話短說，下面就是關(guān)于堆大小如何設(shè)置的內(nèi)容：

添加索引延遲，越低越好

命名約定為 fs_heapsize_biosflags。如你所見，從 32G 的堆大小開始，性能突然開始變差。吞吐量也同樣情況：

索引附加中值吞吐量。越高越好。

長話短說：如果想幸運(yùn)一點(diǎn)，請使用 29G 或 30G 的 RAM，并使用 XFS，并盡可能啟用 hardwareprefetch 和  llc-prefetch。

文件緩存

大多數(shù)人在 Linux 上運(yùn)行 Elasticsearch，Linux 使用內(nèi)存作為文件系統(tǒng)緩存。常見的建議是 ES 服務(wù)器使用 64G  內(nèi)存，這樣的想法是一半用于緩存，一半用于堆。我尚未測試過文件緩存。但是不難看出，大型 ES  集群(如用于日志記錄)可以從配置大文件緩存中受益匪淺。如果你所有的索引都適合放入內(nèi)存堆，則不會那么多好處。

CPU

這取決于對集群執(zhí)行的操作。如果進(jìn)行大量索引，與僅執(zhí)行日志記錄相比，你需要更多更快的 CPU。對于日志記錄，我發(fā)現(xiàn) 8 個(gè) CPU  核綽綽有余，但是發(fā)現(xiàn)很多人使用更大的配置，但是對他的使用場景并沒有什么好處。

磁盤

這塊也沒有想像那么直接。首先，如果索引能放入 RAM，則磁盤僅在節(jié)點(diǎn)冷啟動時(shí)才重要。其次，實(shí)際可以存儲的數(shù)據(jù)量取決于索引布局。每個(gè)分片都是一個(gè)  Lucene 實(shí)例，它們都有內(nèi)存需求。這意味著你可以在堆中容納最大數(shù)量分片是有限的。我將在索引布局部分中詳細(xì)討論這一點(diǎn)。

通常，你可以將所有數(shù)據(jù)磁盤放入 RAID0。你需要在 Elasticsearch 級別進(jìn)行復(fù)制，因此丟失一個(gè)節(jié)點(diǎn)無關(guān)緊要。請勿將 LVM  與多個(gè)磁盤一起使用，因?yàn)?LVM 一次只能寫入一個(gè)磁盤，根本就不會帶來多個(gè)磁盤的好處。

關(guān)于文件系統(tǒng)和 RAID 設(shè)置，我整理了以下幾點(diǎn)：

• Scheduler：cfq 和 deadline 優(yōu)于 noop。如果你有 nvme，Kyber 可能會很好，但我還沒有測試過

• QueueDepth：盡可能高

• 預(yù)讀：請打開

• Raid chunk size：無影響

• FS 塊大?。簾o影響

• FS 類型：XFS > ext4

索引布局

這在很大程度上取決于你的用例。我只能從日志場景(尤其是使用 Graylog)討論一下。

分片

精簡版：

• 對于寫入繁重的工作負(fù)載，主分片 = 節(jié)點(diǎn)數(shù)

• 對于讀取繁重的工作負(fù)載，主分片 * 副本數(shù) = 節(jié)點(diǎn)數(shù)

• 更多副本 = 更高的搜索性能

可以通過以下公式給出最大寫入性能：

node_throughput * number_of_primary_shards  節(jié)點(diǎn)吞吐量 * 主分片數(shù)量

節(jié)點(diǎn)吞吐量 * 主分片數(shù)量

原因很簡單：如果只有一個(gè)主分片，那么寫入速度只類似于單節(jié)點(diǎn)，因?yàn)橐粋€(gè)分片只能位于一個(gè)節(jié)點(diǎn)上。如果確實(shí)想優(yōu)化寫入性能，則應(yīng)確保每個(gè)節(jié)點(diǎn)上只有一個(gè)分片(主節(jié)點(diǎn)或副本)，因?yàn)樵诖饲闆r下副本可以獲得與主節(jié)點(diǎn)相同的寫入速度，并且寫入很大程度上取決于磁盤  IO。注意：如果有很多索引，那么上述的策略可能有問題，性能瓶頸可能是其他原因。

如果要優(yōu)化搜索性能，可以通過以下公式給出：

node_throughput * (number_of_primary_shards + number_of_replicas)  節(jié)點(diǎn)吞吐量 *（主分片數(shù)量 + 副本數(shù)）

節(jié)點(diǎn)吞吐量 *(主分片數(shù)量 + 副本數(shù))

對于搜索，主分片和副本基本相同。因此，如果想提高搜索性能，只需增加副本的數(shù)量。

大小

關(guān)于索引大小，我已經(jīng)多次討論過。以下是我的經(jīng)驗(yàn)：

30G of heap = 140 shards maximum per node 30G 堆內(nèi)存 = 可以在一個(gè)節(jié)點(diǎn)最多啟動 140 個(gè)分片

使用 140 個(gè)以上的分片，Elasticsearch 就會進(jìn)程崩潰并出現(xiàn)內(nèi)存不足錯(cuò)誤。這是因?yàn)槊總€(gè)分片都是 Lucene  實(shí)例，并且每個(gè)實(shí)例都需要一定數(shù)量的內(nèi)存。這意味著每個(gè)節(jié)點(diǎn)可以擁有的分片數(shù)量是有限制的。

如果你有大量節(jié)點(diǎn)，分片和索引大小，則可以容納多少個(gè)索引可以由以下公式計(jì)算：

number_of_indices = (140 * number_of_nodes) / (number_of_primary_shards * replication_factor)  索引數(shù) = (140*節(jié)點(diǎn)數(shù))/（主分片數(shù) * 復(fù)制因子）

根據(jù)磁盤大小，可以很容易地計(jì)算出索引的大?。?/p>

index_size = (number_of_nodes * disk_size) / number_of_indices 索引大小 = （節(jié)點(diǎn)數(shù)量 * 磁盤大小）/ 索引數(shù)量

然而索引越大搜索越慢。對于日志記錄來說，慢一點(diǎn)問題不大，但是對于真正的搜索量大的應(yīng)用程序，應(yīng)該根據(jù) RAM 大小來調(diào)整索引大小。

段合并

每個(gè)段都是文件系統(tǒng)中的一個(gè)實(shí)際文件，更多的段意味著更大的讀取開銷?；旧?，對于每個(gè)搜索查詢，它都會轉(zhuǎn)到索引中的所有分片，再轉(zhuǎn)到分片中的所有段。多個(gè)段極大地增加集群讀取  IOPS，直到它變得不可用。因此，需要盡可能減少段的數(shù)量。

force_merge API 允許你將段合并到某個(gè)數(shù)量，比如 1。如果你執(zhí)行索引滾動(例如使用 Elasticsearch  做日志記錄)，那么在集群未使用時(shí)執(zhí)行常規(guī)強(qiáng)制合并是一個(gè)好建議。強(qiáng)制合并會占用大量資源，并且會顯著降低集群的運(yùn)行速度。因此，最好不要讓 Graylog  幫你來做，而是選擇在較少使用集群時(shí)間自己完成。如果你有很多索引的話，你必須定期執(zhí)行段合并。否則，集群運(yùn)行速度將會非常慢并最終掛掉。

集群布局

對于除最小設(shè)置外的所有設(shè)置，最好使用專用的候選主節(jié)點(diǎn)。主要原因是確保始終有 2n + 1  個(gè)候選主節(jié)點(diǎn)來確保仲裁。但是對于數(shù)據(jù)節(jié)點(diǎn)，可以在任何時(shí)候添加新節(jié)點(diǎn)，而不必?fù)?dān)心這個(gè)需求。另外，我們不希望數(shù)據(jù)節(jié)點(diǎn)上的高負(fù)載影響主節(jié)點(diǎn)。

最后，主節(jié)點(diǎn)是種子節(jié)點(diǎn)的理想候選節(jié)點(diǎn)。請記住，種子節(jié)點(diǎn)是在 Elasticsearch  中進(jìn)行節(jié)點(diǎn)發(fā)現(xiàn)的最簡單方法。由于主節(jié)點(diǎn)很少更改，因此它是最佳選擇，因?yàn)樗芸赡芤呀?jīng)知道集群中的所有其他節(jié)點(diǎn)。

主節(jié)點(diǎn)可以非常小，一個(gè) CPU 核，4G 的 RAM 已經(jīng)足夠大多數(shù)集群使用。當(dāng)然也需要關(guān)注實(shí)際使用情況，并進(jìn)行相應(yīng)調(diào)整。

監(jiān)控

ES 為你提供了大量的指標(biāo)，并且以 JSON 的形式提供所有指標(biāo)，這使得傳遞給監(jiān)控工具非常容易。以下是一些有用的監(jiān)控指標(biāo)：

• 段數(shù)

• 堆使用

• 堆 GC 時(shí)間

• 平均 搜索，索引，合并時(shí)間

• IOPS

• 磁盤利用率

感謝各位的閱讀，以上就是“怎么在生產(chǎn)環(huán)境運(yùn)行Elasticsearch”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對怎么在生產(chǎn)環(huán)境運(yùn)行Elasticsearch這一問題有了更深刻的體會，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！