Ⅰ 《跟老男孩學Linux運維：Web集群實戰》epub下載在線閱讀全文，求百度網盤雲資源
《跟老男孩學Linux運維：Web集群實戰》（老男孩）電子書網盤下載免費在線閱讀
鏈接：https://pan..com/s/1tYblRy6YN3HTEFB-rqKXHg
書名:跟老男孩學Linux運維：Web集群實戰
豆瓣評分:7.9
作者:老男孩
出版社:機械工業出版社
出版年:2016-3
頁數:99
內容簡介
資深運維架構實戰專家及教育培訓界頂尖專家十多年的運維實戰經驗總結，系統講解網站集群架構的框架模型以及各個節點的企業級搭建和優化。
實戰性強，不僅講解了web集群所涉及的各種技術，還針對整個集群中的每個網路服務節點給出解決方案，並指導你細致掌握web集群的運維規范和方法。
作者簡介
老男孩，北京老男孩IT教育創始人，擁有十多年一線大規模網站集群運維架構實戰經驗及教學培訓經驗，曾主導了從幾台到上千台規模集群運維架構的擴展，運維架構實戰知識體系全面，擅長大規模集群架構部署調優、虛擬化、雲計算、大數據、MySQL資料庫等技術，是IT界資深的Linux集群架構實戰專家。
老男孩也是國內NLP心理學運維思想體系創始人，將心理學運維思想大量應用於教學培訓實踐，取得了顯著效果，所教學生平均就業工資及後期發展速度連續多年在國內Linux同行業中處於領先地位。
授課注重理論結合企業真實場景，認真負責，思維嚴謹，重視對學生的運維思想、規范、習慣、總結、表達溝通等能力的培養，累計受益人員數萬！
Ⅱ PB級大規模Elasticsearch集群運維與調優實踐
某中型互聯網公司的游戲業務，使用了騰訊雲的Elasticsearch產品，採用ELK架構存儲業務日誌。因為游戲業務本身的日誌數據量非常大(寫入峰值在100w qps)，在服務客戶的幾個月中，踩了不少坑，經過數次優化與調整，把客戶的ES集群調整的比較穩定，避免了在業務高峰時客戶集群的讀寫異常，並且降低了客戶的資金成本和使用成本。下面把服務客戶過程中遇到的典型問題進行梳理，總結經驗，避免再次踩坑。
解決方案架構師A: bellen, XX要上線一款新游戲，日誌存儲決定用ELK架構，他們決定在XX雲和我們之間二選一，我們首先去他們公司和他們交流一下，爭取拿下！
bellen: 好，隨時有空！
。。。
和架構師一起前往該公司，跟負責底層組件的運維部門的負責人進行溝通。
XX公司運維老大：不要講你們的PPT了，先告訴我你們能給我們帶來什麼！
bellen: 。。。呃，我們有很多優勢。。。比如靈活地擴容縮容集群，還可以一鍵平滑升級集群版本，並且提供有跨機房容災的集群從而實現高可用。。
XX公司運維老大：你說的這些別的廠商也有，我就問一個問題，我們現在要存儲一年的游戲日誌，不能刪除數據，每天就按10TB的數據量算，一年也得有個3PB多的數據，這么大的數量，都放在SSD雲盤上，我們的成本太高了，你們有什麼方案既能夠滿足我們存儲這么大數據量的需求，同時能夠降低我們的成本嗎？
bellen: 我們本身提供的有冷熱模式的集群，熱節點採用SSD雲硬碟，冷節點採用SATA盤，採用ES自帶的ILM索引生命周期管理功能定期把較老的索引從熱節點遷移到冷節點上，這樣從整體上可以降低成本。另外一方面，也可以定期把更老的索引通過snapshot快照備份到COS對象存儲中，然後刪除索引，這樣成本就更低了。
XX公司運維老大：存儲到COS就是冷存儲唄，我們需要查詢COS里的數據時，還得再把數據恢復到ES里？這樣不行，速度太慢了，業務等不了那麼長時間，我們的數據不能刪除，只能放在ES里！你們能不能給我們提供一個API, 讓老的索引數據雖然存儲在COS里，但是通過這個API依然可以查詢到數據，而不是先恢復到ES， 再進行查詢？
bellen: 。。。呃，這個可以做，但是需要時間。是否可以採用hadoop on COS的架構，把存量的老的索引數據通過工具導入到COS，通過hive去查詢，這樣成本會非常低，數據依然是隨時可查的。
XX公司運維老大：那不行，我們只想用成熟的ELK架構來做，再增加hadoop那一套東西，我們沒那麼多人力搞這個事!
bellen: 好吧，那可以先搞一個集群測試起來，看看性能怎麼樣。關於存量數據放在COS里但是也需要查詢的問題，我們可以先制定方案，盡快實施起來。
XX公司運維老大：行吧，我們現在按每天10TB數據量預估，先購買一個集群，能撐3個月的數據量就行，能給一個集群配置的建議嗎？
bellen: 目前支持單節點磁碟最大6TB, cpu和內存的話可以放到8核32G單節點，單節點跑2w qps寫入沒有問題，後面也可以進行縱向擴容和橫向擴容。
XX公司運維老大：好，我們先測試一下。
N 天後，架構師A直接在微信群里反饋："bellen, 客戶反饋這邊的ES集群性能不行啊，使用logstash消費kafka中的日誌數據，跑了快一天了數據還沒追平，這是線上的集群，麻煩緊急看一下吧。。"
我一看，一臉懵, 什麼時候已經上線了啊，不是還在測試中嗎？
XX公司運維小B: 我們購買了8核32G*10節點的集群，單節點磁碟6TB, 索引設置的10分片1副本，現在使用logstash消費kafka中的數據，一直沒有追平，kafka中還有很多數據積壓，感覺是ES的寫入性能有問題。
隨後我立即查看了集群的監控數據，發現cpu和load都很高，jvm堆內存使用率平均都到了90%，節點jvm gc非常頻繁了，部分節點因為響應緩慢，不停的離線又上線。。
經過溝通，發現用戶的使用姿勢是filebeat+kafka+logstash+elasticsearch, 當前已經在kafka中存儲了有10天的日誌數據，啟動了20台logstash進行消費，logstash的batch size也調到了5000，性能瓶頸是在ES這一側。客戶8核32G*10節點的集群，理論上跑10w qps沒有問題，但是logstash消費積壓的數據往ES寫入的qps遠不止10w，所以是ES扛不住寫入壓力了，所以只能對ES集群進行擴容，為了加快存量數據的消費速度，先縱向擴容單節點的配置到32核64GB，之後再橫向增加節點，以保證ES集群能夠最大支持100w qps的寫入(這里需要注意的是，增加節點後索引的分片數量也需要調整)。
所以一般新客戶接入使用ES時，必須要事先評估好節點配置和集群規模，可以從以下幾個方面進行評估：
上述場景2遇到的問題是業務上線前沒有對集群配置和規模進行合理的評估，導致上線後ES集群負載就很高，通過合理的擴容處理，集群最終抗住了寫入壓力。但是又有新的問題出現了。
因為kafka積壓的數據比較多，客戶使用logstash消費kafka數據時，反饋有兩個問題：
經過分析客戶logstash的配置文件，發現問題出現的原因主要是：
分析後，對kafka和logstash進行了如下優化：
通過上述優化，最終使得logstash機器資源都被充分利用上，很快消費完堆積的kafka數據，待消費速度追平生成速度後，logstash消費kafka一直穩定運行，沒有出現積壓。
另外，客戶一開始使用的是5.6.4版本的logstash，版本較老，使用過程中出現因為單個消息體過長導致logstash拋異常後直接退出的問題:
通過把logstash升級至高版本6.8避免了這個問題(6.x版本的logstash修復了這個問題，避免了crash)。
客戶的游戲上線有一個月了，原先預估每天最多有10TB的數據量，實際則是在運營活動期間每天產生20TB的數據，原先6TB*60=360TB總量的數據盤使用率也達到了80%。針對這種情況，我們建議客戶使用冷熱分離的集群架構，在原先60個熱節點的基礎上，增加一批warm節點存儲冷數據，利用ILM(索引生命周期管理)功能定期遷移熱節點上的索引到warm節點上。
通過增加warm節點的方式，客戶的集群磁碟總量達到了780TB， 可以滿足最多三個月的存儲需求。但是客戶的需求還沒有滿足：
XX公司運維老大：給我們一個能存放一年數據的方案吧，總是通過加節點擴容磁碟的方式不是長久之計，我們得天天盯著這個集群，運維成本很高！並且一直加節點，ES會扛不住吧？
bellen: 可以嘗試使用我們新上線的支持本地盤的機型，熱節點最大支持7.2TB的本地SSD盤，warm節點最大支持48TB的本地SATA盤。一方面熱節點的性能相比雲盤提高了，另外warm節點可以支持更大的磁碟容量。單節點可以支持的磁碟容量增大了，節點數量就不用太多了，可以避免踩到因為節點數量太多而觸發的坑。
XX公司運維老大：現在用的是雲盤，能替換成本地盤嗎，怎麼替換？
bellen: 不能直接替換，需要在集群中新加入帶本地盤的節點，把數據從老的雲盤節點遷移到新的節點上，遷移完成後再剔除掉舊的節點，這樣可以保證服務不會中斷，讀寫都可以正常進行。
XX公司運維老大：好，可以實施，盡快搞起來！
雲盤切換為本地盤，是通過調用雲服務後台的API自動實施的。在實施之後，觸發了數據從舊節點遷移到新節點的流程，但是大約半個小時候，問題又出現了：
XX公司運維小B: bellen, 快看一下，ES的寫入快掉0了。
bellen: 。。。
通過查看集群監控，發現寫入qps直接由50w降到1w，寫入拒絕率猛增，通過查看集群日誌，發現是因為當前小時的索引沒有創建成功導致寫入失敗。
緊急情況下，執行了以下操作定位到了原因：
經過了這次擴容操作，總結了如下經驗：
在穩定運行了一陣後，集群又出問題了。。
XX公司運維小B: bellen, 昨晚凌晨1點鍾之後，集群就沒有寫入了，現在kafka里有大量的數據堆積，麻煩盡快看一下？
bellen: 。。。
通過cerebro查看集群，發現集群處於yellow狀態，然後發現集群有大量的錯誤日誌：
然後再進一步查看集群日誌，發現有"master not discovered yet..."之類的錯誤日誌，檢查三個master節點，發現有兩個master掛掉，只剩一個了，集群無法選主。
登陸到掛了了master節點機器上，發現保活程序無法啟動es進程，第一直覺是es進程oom了；此時也發現master節點磁碟使用率100%， 檢查了JVM堆內存快照文件目錄，發現有大量的快照文件，於是刪除了一部分文件，重啟es進程，進程正常啟動了；但是問題是堆內存使用率太高，gc非常頻繁，master節點響應非常慢，大量的創建索引的任務都超時，阻塞在任務隊列中，集群還是無法恢復正常。
看到集群master節點的配置是16核32GB內存，JVM實際只分配了16GB內存，此時只好通過對master節點原地增加內存到64GB(虛擬機，使用的騰訊雲CVM， 可以調整機器規格，需要重啟)，master節點機器重啟之後，修改了es目錄jvm.options文件，調整了堆內存大小，重新啟動了es進程。
3個master節點都恢復正常了，但是分片還需要進行恢復，通過GET _cluster/health看到集群當前有超過10w個分片，而這些分片恢復還需要一段時間，通過調大"cluster.routing.allocation.node_concurrent_recoveries"， 增大分片恢復的並發數量。實際上5w個主分片恢復的是比較快的了，但是副本分片的恢復就相對慢很多，因為部分副本分片需要從主分片上同步數據才能恢復。此時可以採取的方式是把部分舊的索引副本數量調為0， 讓大量副本分片恢復的任務盡快結束，保證新索引能夠正常創建，從而使得集群能夠正常寫入。
總結這次故障的根本原因是集群的索引和分片數量太多，集群元數據佔用了大量的堆內存，而master節點本身的JVM內存只有16GB(數據節點有32GB)， master節點頻繁full gc導致master節點異常，從而最終導致整個集群異常。所以要解決這個問題，還是得從根本上解決集群的分片數量過多的問題。
目前日誌索引是按照小時創建，60分片1副本，每天有24*60*2=2880個分片，每個月就產生86400個分片，這么多的分片可能會帶來嚴重的問題。有以下幾種方式解決分片數量過多的問題：
和客戶溝通過後，客戶表示可以接受方式1和方式2，但是方式3和4不能接受，因為考慮到存在磁碟故障的可能性，必須保留一個副本來保證數據的可靠性；另外還必須保證所有數據都是隨時可查詢的，不能關閉。
在場景5中，雖然通過臨時給master節點增加內存，抗住了10w分片，但是不能從根本上解決問題。客戶的數據是計劃保留一年的，如果不進行優化，集群必然扛不住數十萬個分片。所以接下來需要著重解決集群整體分片數量過多的問題，在場景5的最後提到了，用戶可以接受開啟shrink以及降低索引創建粒度(經過調整後，每兩個小時創建一個索引)，這在一定程度上減少了分片的數量，能夠使集群暫時穩定一陣。
輔助客戶在kibana上配置了如下的ILM策略：
在warm phase, 把創建時間超過360小時的索引從hot節點遷移到warm節點上，保持索引的副本數量為1，之所以使用360小時作為條件，而不是15天作為條件，是因為客戶的索引是按小時創建的，如果以15天作為遷移條件，則在每天凌晨都會同時觸發15天前的24個索引一共24*120=2880個分片同時開始遷移索引，容易引發場景4中介紹的由於遷移分片數量過多導致創建索引被阻塞的問題，所以以360小時作為條件，則在每個小時只會執行一個索引的遷移，這樣把24個索引的遷移任務打平，避免其它任務被阻塞的情況發生。
同時，也在warm phase階段，設置索引shrink，把索引的分片數縮成5個，因為老的索引已經不執行寫入了，所以也可以執行force merge, 強制把segment文件合並為1個，可以獲得更好的查詢性能。
另外，設置了ILM策略後，可以在索引模板里增加index.lifecycle.name配置，使得所有新創建的索引都可以和新添加的ILM策略關聯，從而使得ILM能夠正常運行。
客戶使用的ES版本是6.8.2， 在運行ILM的過程中， 也發現一些問題：
這是因為shrink操作需要新把索引完整的一份數據都遷移到一個節點上，然後在內存中構建新的分片元數據，把新的分片通過軟鏈接指向到幾個老的分片的數據，在ILM中執行shrink時，ILM會對索引進行如下配置：
問題是索引包含副本，而主分片和副本分片又不能在同一個節點上，所以會出現部分分片無法分配的情況(不是全部，只有一部分)，這里應該是觸發了6.8版本的ILM的bug，需要查看源碼才能定位解決這個bug，目前還在研究中。當前的workaround是通過腳本定期掃描出現unassigned shards的索引，修改其settings:
優先保證分片先從hot節點遷移到warm節點，這樣後續的shrink才能順利執行(也可能執行失敗，因為60個分片都在一個節點上，可能會觸發rebalance, 導致分片遷移走，shrink的前置條件又不滿足，導致執行失敗)。要完全規避這個問題，還得在ILM策略中設置，滿足創建時間超過360個小時的索引，副本直接調整為0，但是客戶又不接受，沒辦法。
在場景5和6中，介紹了10w個分片會給集群帶來的影響和通過開啟shrink來降低分片數量，但是仍然有兩個需要重點解決的問題：
可以估算一下，按小時建索引，60分片1副本，一年的分片數為24*120*365=1051200個分片，執行shrink後分片數量24*10*350 + 24*120*15 = 127200(15天內的新索引為了保障寫入性能和數據可靠性，仍然保持60分片1副本，舊的索引shrink為5分片1副本), 仍然有超過10w個分片。結合集群一年總的存儲量和單個分片可以支持的數據量大小進行評估，我們期望集群總體的分片數量可以穩定為6w~8w，怎麼優化？
可以想到的方案是執行數據冷備份，把比較老的索引都冷備到其它的存儲介質上比如HDFS，S3，騰訊雲的COS對象存儲等，但是問題是這些冷備的數據如果也要查詢，需要先恢復到ES中才可查，恢復速度比較慢，客戶無法接受。由此也產生了新的想法，目前老的索引仍然是1副本，可以把老索引先進行冷備份，再把副本調為0，這樣做有以下幾點好處：
經過和客戶溝通，客戶接受了上述方案，計劃把老索引冷備到騰訊雲的對象存儲COS中，實施步驟為：
其中步驟1的實施可以通過腳本實現，本案例中採用騰訊雲SCF雲函數進行實施，方便快捷可監控。實施要點有：
在實施完步驟1之後，就可以批量把對索引進行過備份的索引副本數都調為0， 這樣一次性釋放了很多磁碟空間，並且顯著降低了集群整體的分片數量。
接下來實施步驟2，需要每天執行一次快照，多創建時間較久的索引進行備份，實施比較簡單，可以通過crontab定時執行腳本或者使用騰訊雲SCF執行。
步驟2實施之後，就可以修改ILM策略，開啟cold phase, 修改索引副本數量為0:
此處的timing是創建時間20天後，需要保證步驟2中對過去老索引數據備份先執行完成才可以進入到cold phase.
通過老索引數據冷備並且降低索引副本，我們可以把集群整體的分片數量維持在一個較低的水位，但是還有另外一個問題待解決，也即shrink失敗的問題。剛好，我們可以利用對老索引數據冷備並且降低索引副本的方案，來徹底解決shrink失敗的問題。
在場景5中有提到，shrink失敗歸根接地是因為索引的副本數量為1， 現在我們可以吧數據備份和降低副本提前，讓老索引進入到ILM的warm phase中時已經是0副本，之後再執行shrink操作就不會有問題了；同時，因為副本降低了，索引從hot節點遷移到warm節點遷移的數據量也減少了一半，從而降低了集群負載，一舉兩得。
因此，我們需要修改ILM策略，在warm phase就把索引的副本數量調整為0， 然後去除cold phase。
另外一個可選的優化項是，對老的索引進行凍結，凍結索引是指把索引常駐內存的一些數據從內存中清理掉(比如FST, 元數據等)， 從而降低內存使用量，而在查詢已經凍結的索引時，會重新構建出臨時的索引數據結構存放在內存中，查詢完畢再清理掉；需要注意的是，默認情況下是無法查詢已經凍結的索引的，需要在查詢時顯式的增加"ignore_throttled=false"參數。
經過上述優化，我們最終解決了集群整體分片數量過多和shrink失敗的問題。在實施過程中引入了額外的定時任務腳本實施自動化快照，實際上在7.4版本的ES中，已經有這個功能了，特性名稱為 SLM (快照生命周期管理)，並且可以結合ILM使用，在ILM中增加了"wait_for_snapshot"的ACTION, 但是卻只能在delete phase中使用，不滿足我們的場景。
在上述的場景4-7中，我們花費大量的精力去解決問題和優化使用方式，保證ES集群能夠穩定運行，支持PB級別的存儲。溯本回原，如果我們能有一個方案使得客戶只需要把熱數據放在SSD盤上，然後冷數據存儲到COS/S3上，但同時又使冷數據能夠支持按需隨時可查，那我們前面碰到的所有問題都迎刃而解了。可以想像得到的好處有：
而這正是目前es開源社區正在開發中的Searchable Snapshots功能，從 Searchable Snapshots API 的官方文檔上可以看到，我們可以創建一個索引，將其掛載到一個指定的快照中，這個新的索引是可查詢的，雖然查詢時間可能會慢點，但是在日誌場景中，對一些較老的索引進行查詢時，延遲大點一般都是可以接受的。
所以我認為，Searchable Snapshots解決了很多痛點，將會給ES帶了新的繁榮！
經歷過上述運維和優化ES集群的實踐，我們總結到的經驗有：
從一開始和客戶進行接觸，了解客戶訴求，逐步解決ES集群的問題，最終使得ES集群能夠保持穩定，這中間的經歷讓我真真正正的領悟到"實踐出真知"，只有不斷實踐，才能對異常情況迅速做出反應，以及對客戶提的優化需求迅速反饋。