eBay里Elasticsearch集群的生命周期

定義一個Elasticsearch集群的生命周期

eBay的“Elasticsearch即服務”（Elasticsearch as service，ES-AAS）平臺名叫Pronto，它可以為各種不同的搜索用例提供全面管理下的Elasticsearch集群。我們的ES-AAS平臺部署在基于 OpenStack 的一個私有內部云環境里。平臺現在管理著至少35個集群，支持跨多個數據中心的部署。為了實現對Elasticsearch集群的最優化管理，這篇文章針對定義一個集群生命周期的方方面面都提供了指導。在eBay系統里部署的所有Elasticsearch集群都符合我們在下圖中描繪的自己定義的Elasticsearch生命周期。

集群準備

當一個新的客戶用例被提交到我們的ES-AAS平臺上的時候，這個生命周期就開始了。

上線信息

客戶的全部需求都會用一個上線模板記錄下來，包括文檔大小、保留策略、讀寫請求吞吐量等信息。根據客戶提供的信息就可以估計集群的規模了，我們估計集群規模的方法是通過大量基準測試得出來的。上線信息在做集群規劃、為客戶定義服務等級協議等方面都非常有用。

在任何客戶用例上線之前，我們都會從客戶那里收集下列信息：

• 用例細節 ：包括對用例描述、重要性等相關的問題的詢問結果；
• 規模信息 ：文檔數量、平均的文檔大小、每年的增長比例估計等；
• 數據讀寫信息 ：包括預期的索引和檢索率、寫入模式（批量模式或是單條）、數據新鮮度、平均用戶數量，以及包含任何聚合、分頁或排序操作的特殊檢索請求等；
• 數據源與保留 ：數據源信息（比如Oracle、MySQL等）都記錄在上線模板上。如果分片是基于時間的，那索引刪除策略也要記錄下來。一般來說，我們不把Elasticsearch用于保存關鍵應用的數據。

基準測試策略

在做基準測試之前，必須先了解一下你的虛擬機所處的底層基礎設施的情況，這非常重要。如果你的測試環境是在云上，那就更要注意這個問題，因為這些信息都是針對終端用戶抽象過的了。要小心各種可能的“吵鬧的鄰居”問題，特別是在多租戶的環境里。

和許多人一樣，我們也會先在現有的硬件設施和鏡像上做一些額外的基準測試。存儲在Elasticsearch集群里的數據都專屬于客戶自己的業務。想在屬于不同用戶的所有數據庫里運行基準測試是幾乎不可能的。因此，在做任何的基準測試之前我們都會先做一些前提假設，下面的這些假設條件是非常重要的。

• 客戶端在對存儲在我們部署的Elasticsearch集群里的數據進行任何訪問時，都會使用REST路徑。（沒有傳輸客戶端）
• 最早的時候我們保持1GB的內存對應32GB的磁盤空間這樣的比例。（在我們從基準測試中得到經驗之后，我們對此做了改進）
• 針對不同的副本數量（1、2和3份副本），都有對應的仔細測試過的索引數量。
• 查詢基準測試的語句都是GetById類的（查詢語句都是定制的，對所有不同的查詢語句都進行分析是不可行的）。
• 我們使用了固定大小的1KB、2KB、5KB和10KB的文檔。

基于上述假設，我們還會進一步得出從性能角度考慮的最大分片大小（大概22GB）、對于大批量的請求（約5MB）的合適載荷大小，等等。我們使用了自己定制的 JMeter 腳本來做基準測試。最近Elasticsearch開發并開源了 基準測試工具Rally ，這個也很有用。另外，根據我們的基準測試經驗，我們還實現了一個容量估計計算器工具，可以向它輸入客戶需求，再根據客戶用例來計算對基礎設施的需求。我們也把這個工具直接分享給了終端用戶，用它幫助我們避免了與客戶之間的許多溝通。

虛擬機緩沖池

我們的Elasticsearch集群是通過一個智能熱緩沖層來部署的。熱緩沖層由許多隨時可用的虛擬機節點組成，這些節點都是根據某些預定義的規則提前構建好的。這樣就能保證虛擬機可以以統一的方式分布在不同的底層硬件之上。有了這個緩沖層，我們就可以在幾秒內快速擴張集群。另外，我們的修復引擎也可以利用這一層來成功的在現有的集群上拉起節點，不需要任何手工介入。我們發表過另一篇博客“ 借助于熱緩沖實現的隨時可用的虛擬機池 ”，里面描述了關于這個緩沖池的更多細節。

集群部署

集群的部署通過底層的 Puppet / Foreman 實現了完全自動化。我們不會詳細討論我們是如何利用Elasticsearch Puppet模塊來部署Elasticsearch集群的。這些都在 Elasticsearch Puppet模塊 的文檔中描寫得很充分了。Elasticsearch的每個版本發布之后，都會有一個相應版本的Puppet模塊發布。我們對這些Puppet腳本做了一些小改動來適應eBay的特別需求。Elasticsearch的不同配置參數都根據我們的基準測試結果作了定制。一般來說，我們不會讓JVM的堆內存大小超過28GB（因為這樣做會導致很長的垃圾回收周期），而且還會禁止Elasticsearch JVM進程的內存切換。不同的數據中心部署不同的集群，并使用負載均衡的VIP（Virtual IP addresses，虛擬IP地址）來訪問數據。

通常，每一套部署好的集群我們都會配置兩個VIP，一個用于讀操作，另一個用于寫操作。讀VIP通常配置在客戶端節點（或者協調節點）上，而寫VIP則配置在數據節點上。我們的集群在這樣配置之后，吞吐量明顯上升。

部署圖：

我們的平臺上使用了許多開源軟件，比如OpenStack、MongoDB、Airflow、Grafana、InfluxDB（公開版）、openTSDB等。我們的內部服務，像集群部署、集群管理和客戶管理服務等，都使用了基于API的REST管理方式做部署和配置。在跟蹤不同的客戶對集群資源的使用情況上，這些軟件也很好用。我們的集群部署服務主要用的是OpenStack。另外，我們還用 NOVA 來管理計算資源（節點），用 Neutron API來做負載均衡部署，以及用 Keystone 來做我們API的內部身份驗證和授權。

我們的Elasticsearch集群不會使用跨區域的部署方式。因為存在網絡延遲，我們不能采用這樣的部署方式。但是對于跨區域的用例，我們使用了專門的集群。當集群跨區域部署時，客戶端會做兩次寫入。我們也沒有使用 Tribe 節點模式。

集群上線

我們在客戶業務上線的過程中構建集群拓撲，這樣可以跟蹤與集群基礎設施有關的資源的使用情況。作為集群拓撲的一部分，元數據管理著區域部署信息、服務等級協議、集群管理信息等。我們用了eBay的內部配置管理系統（CMS）來以有向圖的形式跟蹤集群信息。還有一些外部工具與這個拓撲結合起來。這樣的外部集成方式讓我們可以從集中化的eBay專用系統的角度監控我們的集群。

集群拓撲示例：

集群管理

集群安全

我們集群上的安全功能是通過定制的安全插件提供的，它可以對Elasticsearch集群的使用情況進行審計和鑒權。我們的安全插件可以攔截消息，并使用內部的認證框架做基于上下文的審計和鑒權。我們也支持對客戶端IP做顯式的白名單配置，這對配置 Kibana 或其它的外部UI儀表盤非常有用。配置的管理員用戶對Elasticsearch集群擁有完全的訪問權限。我們建議大家使用基于TLS 1.2的HTTPS來實現客戶端與Elasticsearch集群之間的安全通信。

下面這段代碼是一段簡單的安全規則例子，可以配置在我們部署的集群上。

在上面的示例代碼中，“enabled”字段控制著是否啟用安全功能。“whitelisted_ip_list”是一個數組，記錄所有在白名單里的客戶端IP地址。所有對索引的開、關或刪除操作都只能由管理員用戶執行。

集群監控

集群監控是通過定制的監控插件實現的，它可以從各個Elasticsearch節點中把70多個指標推送到后端的基于TSDB的數據庫中。插件基于推的模式工作。外部的儀表盤使用Grafana來處理TSDB數據庫中的數據。我們還在Grafana儀表盤上創建了定制的模板，這樣就可以很方便地實現對我們集群的集中式監控了。

我們用了一套內部的告警系統來基于存儲在OpenTSDB中的數據配置基于閾值的告警。根據不同的輕重級別，現在我們已經為集群配置了500多種活躍的告警。告警主要分為“錯誤”和“警告”兩大類。如果發生了“錯誤”類的告警，告警事件馬上會被DevOps團隊或者我們的內部自動修復引擎處理，具體取決于我們對告警規則的配置。

在部署集群的過程中，可以根據不同的閾值來產生告警。比如，如果一個集群的狀態變成紅色了，那就會拋出一個錯誤。而如果節點的CPU使用率超過了80%，那就會拋出一個警告。

集群修復

收到任何集群內的異常事件時，我們的ES-AAS平臺都可以自動采取修復動作，具體是由我們定制的“熄燈管理”（Lights-Out-Management，LOM）模塊來定義的。這些自動修復模塊可以極大地減輕我們DevOps團隊的手工勞動量。熄燈模塊使用基于規則的引擎來監控集群上拋出的所有告警。反應器實例維護著所有已發生的告警事件的上下文，可以根據集群拓撲狀態（“自動”模式開或關）來采取修復動作。比如，如果某個集群有個節點宕機了，而且在接下來的15分鐘內還沒能恢復正常狀態返回集群，那修復引擎就會通過我們的內部集群管理服務來替換掉這個節點。另一種可選的模式是將告警事件發送給DevOps團隊，而不是自動采取修復動作。熄燈模塊采取的所有行動都會被記錄，作為有狀態的任務持久化地記錄在后端的MongoDB數據庫中。由于這些任務本身的有狀態特性，在需要時就可以重試或者回滾。在同時我們還保留了審計日志，來記錄由我們的熄燈模塊采取的所有修復行動的歷史。

集群日志

在部署標準的Elasticsearch系統的同時，我們也會部署我們定制的日志庫。這個庫會通過一個名為Sherlock的內部系統來把所有Elasticsearch應用程序的日志推送到后端的Hadoop數據庫里。這些集中收集起來的日志可以以集群或節點的不同級別查看。一旦Elasticsearch日志數據被傳上了Hadoop，我們就可以在日志庫上運行每日定時的 PIG 任務，來生成對錯誤日志或慢日志的計數報告。一般情況下我們會把日志級別設成INFO，在需要調查問題的時候，我們也會在很短的時間段內把日志級別設成DEBUG，這樣就可以把更細致的日志收集到后端的Hadoop數據庫中了。

集群下線

我們根據一個集群的下線流程來做Elasticsearch的主要版本升級。對于Elasticsearch集群的重大升級，我們會用我們可用的最新版的Elasticsearch生成一個新的集群，把舊的或現有版本的Elasticsearch集群中的所有文檔都復制到新的集群中。客戶端（用戶程序）會把新的寫入同時寫入新舊兩個集群，直到新集群中的數據全補齊了。在完成數據的奇偶校驗之后，就可以下線舊集群了。除了釋放系統資源之外，我們還會清理所有相關的集群拓撲。Elasticsearch也提供了遷移插件，用于檢查是否可以就地直接對Elasticsearch進行大版本升級。小版本的Elasticsearch更新是按需進行的，通常是就地升級。

感謝杜小芳對本文的審校。

給InfoQ中文站投稿或者參與內容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博（@InfoQ，@丁曉昀），微信（微信號： InfoQChina ）關注我們。

 

來自：http://www.infoq.com/cn/articles/elasticsearch-cluster-life-cycle-in-ebay