近es集羣磁盤空間告警,日誌又沒地方能夠遷移,而後申請了新的服務器,一次性加入8臺新的服務器java
新增了32個新的數據節點,至此,咱們的主集羣已經到達85個數據節點的規模,整個集羣數據已達到PB級別,終於能夠跟別人炫耀我是作大數據的了。O(∩_∩)O哈哈~api
可是隨着集羣節點的不斷壯大,問題也隨之而來,剛開始加入新節點後,發現全部數據分片都會在新節點上,可是過幾天后,發現只有少部分在新節點上。服務器
而後,發現新的數據節點磁盤才使用40%,就再也不往這些新節點分配分片了。當時以爲很納悶。大數據
後來翻翻es文檔才發現,es自動均衡是按照分片數來分配的,並非按照磁盤空間使用率來分配的。頓時恍然大悟。日誌
由於個人集羣index是按期關閉的,並且es自動均衡是按照打開的index的分片來自動分配的。因此會致使這種狀況blog
我後來的解決辦法就是打開因此index,讓集羣自動均衡一下,而後磁盤空間就慢慢均衡了。文檔
有時候會出現以下圖磁盤水平線報警問題會致使副本unassigned io
能夠在kibana調整es磁盤水平線class
put _cluster/settings { "transient":{ "cluster":{ "routing":{ "allocation.disk.watermark.high":"95%", "allocation.disk.watermark.low":"90%", } } } }
es能夠根據磁盤使用狀況來決定是否繼續分配shard。默認設置是開啓的,也能夠經過api關閉:cluster.routing.allocation.disk.threshold_enabled: false集羣
在開啓的狀況下,有兩個重要的設置:
cluster.routing.allocation.disk.watermark.low:控制磁盤最小使用率。默認85%.說明es在磁盤使用率達到85%的時候將會中止分配新的shard。也能夠設置爲一個絕對數值,好比500M.
cluster.routing.allocation.disk.watermark.high:控制磁盤的最大使用率。默認90%.說明在磁盤使用率達到90%的時候es將會relocate shard去其餘的節點。一樣也能夠設置爲一個絕對值。
watermark setting能夠經過update-api動態修改,默認es每隔30s會收集各個節點磁盤的使用狀況,能夠cluster.info.update.interval來設置時間間隔。