Elasticsearch+LogStash+Kibana+RedisLog Service的高可用方案

http://nkcoder.github.io/blog/20141106/elkr-log-platform-deploy-ha/

1. 高可用方案的架構

在上一篇文章使用Elasticsearch+LogStash+Kibana+Redis搭建日誌管理服務中介紹了Log Service的整體架構以及各組件的搭建部署，本篇文章主要討論一下Log Service架構的高可用方案，主要從以下三個方面考慮： 作為broker的Redis，可以使用redis cluster或者主備結構代替單一實例，提高broker組件的可用性； 作為indexer的LogStash，可以部署多個LogStash執行個體，協作處理日誌資訊，提高indexer組件的可用性； 作為search&storage的Elasticsearch，採用Elasticsearch Cluster，提高search&storage組件的效能和可用性；

Log Service的高可用方案的示意圖為：

下面分別予以介紹。 2. Redis Cluster和主備結構 2.1 Redis Cluster

首先需要部署一個redis cluster，為了方便，我在本機上部署了一個三主三從的cluster，連接埠分別為：7000, 7001, 7002, 7003, 7004, 7005，以連接埠7000為例，設定檔為：

include ../redis.confdaemonize yes pidfile /var/run/redis_7000.pidport 7000logfile /opt/logs/redis/7000.logappendonly yes cluster-enabled yes cluster-config-file node-7000.conf

對於redis來說，遠程Logstash和中心LogStash都是redis cluster的client，因此只需要與cluster中的任何一個節點串連即可；遠程LogStash和中心LogStash的redis配置部分為：

shipper.conf:

output {redis {host => "20.8.40.49:7000"data_type => "list"key => "key_count"}   }

central.conf:

input {redis {host => "20.8.40.49"port => 7000type => "redis-cluster-input"data_type => "list"key => "key_count"}}

使用redis cluster的優劣分析： 可以提高broker組件的可用性：當每一個master節點都有slave節點的時候，任何一個節點掛掉，都不影響叢集的正常工作；如果啟用cluster-require-full-coverage no，則有效節點構成的子叢集仍然可用。 當作為broker組件的redis成為瓶頸的時候，redis cluster提供良好的擴充性。但是redis cluster有一個比較頭疼的問題，就是在伸縮(增刪節點)時，需要手動做sharding，官方提供了redis-trib.rb工具，我自己實現了一個java版本，可以作為參考redis-toolkit。 當前的redis cluster還是RC1版，穩定版還需要等待一段時間。 2.2 redis主備結構

注意，主備不是主從，備用的redis執行個體只是作為冗餘節點，當主節點掛掉時，備用的節點會頂上，任何時刻僅有一個節點在提供服務。無論是遠程LogStash還是中心LogStash，都需要明確配置所有主備redis節點的資訊，LogStash會輪詢節點列表，選擇一個可用的節點。比如，配置兩個redis執行個體，6379作為主，6380作為從，則遠程LogStash和中心LogStash的配置分別為：

shipper.conf:

output {redis {host => ["20.8.40.49:6379", "20.8.40.49:6380"]data_type => "list"key => "key_count"}   }

central.conf:

input {redis {host => "20.8.40.49"port => 6379type => "redis-cluster-input"data_type => "list"key => "key_count"} redis {host => "20.8.40.49"port => 6380type => "redis-cluster-input"data_type => "list"key => "key_count"} }

redis主備結構的優劣分析： 可以提高broker組件的可用性：只要主備節點中有一個節點可用，broker元件服務就是可用的； 主備結構無法解決redis成為瓶頸的情況； 3. 部署多個中心LogStash

當日誌資訊的量很大時，作為indexer的LogStash很可能成為瓶頸，此時，可以部署多個中心LogStash，它們之間的關係是對等的，共同從broker處提取訊息，中心LogStash節點之間是相互獨立的。每一個中心LogStash節點的配置是完全一樣的，比如當broker是redis cluster時，中心LogStash的配置為：

central.conf:

input {redis {host => "20.8.40.49"port => 7000type => "redis-cluster-input"data_type => "list"key => "key_count"}}

部署多個中心LogStash的優劣分析： 可以提高indexer組件的可用性：多個中心LogStash節點之間是相互獨立的，任何一個節點的失效不會影響其它節點，更不會影響整個indexer組件；當broker是redis時，各個中心LogStash都是redis的client，它們都是執行BLPOP命令從redis中提取訊息，而redis的任何單個命令都是原子的，因此多中心LogStash不僅可以提高indexer組件的可用性，也可以提高indexer組件的處理能力和效率； 多中心LogStash節點的部署和維護成本，可以藉助組態管理工具如Puppet、SaltStack等 4. Elasticsearch Cluster

Elasticsearch原生支援Cluster模式，節點之間通過單播或多播進行通訊；Elasticsearch Cluster能自動檢測節點的增加、失效和恢複，並重新組織索引。

比如，我們啟動兩個Elasticsearch執行個體構成叢集，使用預設配置即可，如：

$ bin/elasticsearch -d$ bin/elasticsearch -d

使用預設配置，兩個執行個體的HTTP監聽連接埠分別為9200和9201，它們的節點間通訊連接埠分別為9300和9301，預設使用多播構成叢集，叢集的名稱為elasticsearch；

中心LogStash只需要配置Elasticsearch的cluster name即可(如果不能發現ES叢集，可以指定host: host => "20.8.40.49")，如：

output {elasticsearch {cluster => "elasticsearch"codec => "json"protocol => "http"}   }

使用Elasticsearch Cluster的優劣分析： 提高組件的可用性：cluster中任何一個節點掛掉，索引及副本都會自動重新分配； 極佳的水平擴充性：向cluster中增加新的節點即可，索引會自動重新組織； 5. 後續工作

關於ELKRLog Service，下一步的工作方向有： 學習grokRegex，匹配自訂的日誌輸出格式； 研究Elasticsearch的查詢功能及原理； 熟悉Kibana豐富的表徵圖展示功能；

Ok，高可用方案的介紹告一段落，如果用到實際的生產環境中，應該會遇到很多意想不到的問題，後續會繼續總結和分享。