GitHub此前的搜索使用Solr實現，新上線的搜索基于elasticsearch，運行在多個集群上。由于代碼搜索索引很大，GitHub專門為其指定了一個集群。目前該集群包括26個存儲節(jié)點和8個客戶端節(jié)點。存儲節(jié)點負責保存構成搜索索引的數據，而客戶端節(jié)點負責協調查詢活動。每個搜索節(jié)點中有2TB的SSD存儲。
發(fā)生故障時，整個集群保存了大概17TB的代碼。數據以分片方式跨越整個集群存儲，每個分片（shard）在另一個節(jié)點上有一份復制作為冗余，整個索引用去大約34TB存儲空間。整個存儲容量占用了集群總存儲空間的67%左右。代碼搜索集群運行在Java 6和elasticsearch 0.19.9上。當時這個集群已經正常運行了好幾個月。
在1月17日、星期四，準備上線這個代碼搜索功能，以完成整個統一搜索的實現。后來發(fā)現elasticsearch已經發(fā)布了0.20.2版本，其中包括多個功能修復和性能改進。
他們決定推遲代碼搜索上線，先升級elasticsearch，希望這可以讓新功能的上線更加順暢。
在1月17日完成了升級，集群中所有節(jié)點都成功上線，而且恢復到正常的集群狀態(tài)。
問題就此開始出現。
從這次升級開始，集群中出現兩次故障。
elasticsearch與其他使用大量單一索引存儲數據的索引服務不同，它使用分片模式切分數據，這樣可以很容易地將數據分布在整個集群中，而且易于管理。每個分片自己是一個Lucene索引，elasticsearch使用Lucene合并索引來聚合所有的分片搜索查詢。
在升級后兩個小時，第一次故障出現了，恢復的過程中要重啟整個集群。我們在索引日志中發(fā)現的錯誤信息指出：有些分片無法分配到特定節(jié)點上。進一步檢查后，我們發(fā)現：這些數據分片有些區(qū)段的緩存文件已經損壞，其他在磁盤上已經丟失，但elasticsearch仍然可以恢復有損壞區(qū)段緩存的分片，它也可以恢復丟失了一份復制的分片，但是總計510個分片中有7個分片，主分片和副本都已經丟失了。
我們復核了發(fā)生故障的環(huán)境，當時的結論是：我們發(fā)現的問題，來源于集群恢復帶來的高負載。對問題的進一步研究后，沒有發(fā)現其他elasticsearch用戶遇到過類似問題。在那個周末，集群沒有問題，因此我們決定發(fā)布新功能。
下一次故障出現在1月24日、星期四。引起團隊注意的，是他們的異常跟蹤和監(jiān)控系統，其中檢測到大量的異常爆發(fā)。進一步調查指出：大部分異常來自代碼查詢的超時，以及加入新數據時更新代碼搜索索引的后臺作業(yè)。
這一次，我們開始同時檢查集群中全部節(jié)點的整體狀態(tài)和elasticsearch的日志。我們發(fā)現：看似隨機性的多個存儲節(jié)點出現高負載。大多數節(jié)點的CPU使用率都是個位數，有幾個消耗量幾乎100%可用的CPU核。我們可以消除系統和IO引起的負載，在這些服務器上唯一導致高負載的是運行elasticsearch的Java進程?，F在搜索和索引還是會超時，我們也在日志中注意到：一些節(jié)點被很快選為master，此后又很快被移除。為了消除這種快速切換master角色帶來的潛在問題，我們決定：最好的方法，是讓集群完全停機，然后將其啟動，禁止數據分片的分配和重新平衡。
這種方式讓集群恢復上線，但是他們發(fā)現elasticsearch日志中有一些問題。集群重啟后，他們發(fā)現有些節(jié)點無法重新加入到集群中，有些數據分片試圖二次分配到同一個節(jié)點上。這次，他們求助于elasticsearch公司的技術人員，并確認：
這些無法分配的分片（主分片與復制合計23個）都有數據丟失。除數據丟失外，集群花費很多時間試圖恢復剩余的分片。在這次恢復過程中，我們必須多次重啟整個集群，因為我們加入了多次升級和配置變更，必須要驗證和再次恢復分片。這是這次故障中最耗時的部分，因為多次從磁盤中加載17TB索引數據十分緩慢。
和elasticsearch的技術人員一起，他們發(fā)現集群中有些地方配置錯誤，或是需要調優(yōu)配置，才能得到最佳性能。這次問題也讓elasticsearch的技術人員也發(fā)現了elasticsearch的兩個bug。還有一個很重要的原因：
我們當時運行的Java 6是2009年早期的版本，其中包含多個嚴重bug，影響elasticsearch和Lucene，同時造成大量內存分配，導致高負載。
根據他們的建議，我們馬上升級了Java和elasticsearch，并按他們的推薦調整了配置。具體做法是：在我們的Puppetmaster上，針對這些特定變更，創(chuàng)建了一個新的話題分支，并在環(huán)境中的這些節(jié)點上運行了Puppet。使用了新的配置、新版本elasticsearch和Java7之后，此前兩次故障中遇到的負載不穩(wěn)定和快速master選舉問題再也沒有出現了。
但是，1月28日，又出現一次故障。不過這次與之前沒有關系，完全是人為錯誤。
一名工程師要把包含有Java和elasticsearch更新的特性分支合并到我們的生產環(huán)境中。過程中，工程師將代碼搜索節(jié)點上的Puppet環(huán)境回滾到了生產環(huán)境中，這是在部署合并代碼之前。這導致elasticsearch在節(jié)點上重啟，因為Puppet運行在上面。
我們馬上就發(fā)現了問題根源，并停下集群，防止在一個集群中運行多個版本Java和elasticsearch導致任何問題。當合并代碼部署后，我們在所有代碼搜索節(jié)點上再次運行Puppet，啟動集群。我們沒有選擇在集群處于降級狀態(tài)時建立索引和查詢，而是等它完全恢復。當集群完成恢復后，我們將代碼搜索功能打開。
總結這幾次故障，Will指出：
在將代碼搜索集群中的elasticsearch升級到0.20.2版本之前，我們沒有在我們的基礎設施中對其進行足夠測試，也沒在其他集群中測試。還有一個原因是：對于代碼搜索集群，我們沒有足夠的上線前（staging）環(huán)境。
現在運行的Java版本已經經過elasticsearch團隊測試，而且代碼集群配置也經過他們審核，未來的審核過程也已經安排確定。
對于周一的故障，我們正在開發(fā)自動化過程，保證這樣的效果：如果GitHub上的分支比Puppetmaster上分支更超前，確保這個環(huán)境中的Puppet不會運行。
最后，elasticsearch團隊提供了對運行大集群的幾點優(yōu)化建議：
1.設置ES_HEAP_SIZE環(huán)境變量，保證JVM使用的最大和最小內存用量相同。如果設置的最小和最大內存不一樣，這意味著當jvm需要額外的內存時（最多達到最大內存的大?。?，它會阻塞java進程來分配內存給它。結合使用舊版本的java情況就可以解釋為什么集群中的節(jié)點會停頓、出現高負載和不斷的進行內存分配的情況。elasticsearch團隊建議給es設置50%的系統內存
2.縮短recover_after_time超時配置，這樣恢復可以馬上進行，而不是還要再等一段時間。
3.配置minimum_master_nodes，避免多個節(jié)點長期暫停時，有些節(jié)點的子集合試圖自行組織集群，從而導致整個集群不穩(wěn)定。
4.在es初始恢復的時候，一些節(jié)點用完了磁盤空間。這個不知道是怎樣發(fā)生的，因為整個集群只使用了總空間的67%，不過相信這是由于之前的高負載和舊java版本引起的。elasticsearch的團隊也在跟進這個問題。
原文地址
