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

1. 高可用方案的架構

• 作為broker的Redis，可以使用redis cluster或者主備結構代替單例項，提高broker元件的可用性；
• 作為indexer的LogStash，可以部署多個LogStash例項，協作處理日誌資訊，提高indexer元件的可用性；
• 作為search&storage的ElasticSearch，採用ElasticSearch Cluster，提高search&storage元件的效能和可用性；

日誌服務的高可用方案的示意圖為：

下面分別予以介紹。

2. Redis Cluster和主備結構

2.1 Redis Cluster

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

include ../redis.conf
daemonize yes 
pidfile /var/run/redis_7000.pid
port 7000
logfile /opt/logs/redis/7000.log
appendonly 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 => 7000
		type => "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 => 6379
		type => "redis-cluster-input"
		data_type => "list"
		key => "key_count"
	} 
	
	redis {
		host => "20.8.40.49"
		port => 6380
		type => "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 => 7000
		type => "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. 後續工作

關於ELKR日誌服務，下一步的工作方向有：

• 學習grok正則表示式，匹配自定義的日誌輸出格式；
• 研究ElasticSearch的查詢功能及原理；
• 熟悉Kibana豐富的圖示展示功能；

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