運維經驗（轉）

1）安裝、部署過程要儘量自動化。

將集羣搭建的步驟腳本化，能夠作到批量部署多個節點、快速上線/下線一個節點。集羣的節點多，或者不斷有節點上下線的話，都能省出很多的時間。

2）搭建並充分利用好集羣的監控系統。

首先，最重要的是集羣自帶的監控系統。例如，HBase的Master、Region Server監控頁面；Hadoop的JobTracker/TaskTracker、NameNode/DataNode監控頁面；Storm的Storm UI監控頁面，等等。這類監控側重集羣上的做業、資源等，並且包含的信息很全，包括做業運行的異常日誌等，這對於排查、定位問題是很是及時有效的。

其次，既然是集羣，就須要有一個統一的監控地址負責收集、展現各個節點的工做狀態，集羣既不能太閒，也不能負載太高。所以，咱們須要對集羣內各節點的CPU、內存、磁盤、網絡等進行監控。Ganglia是個很不錯的工具，它的安裝配置過程簡單，採集的指標豐富，並且支持自定義，像Hadoop、HBase都對Ganglia進行了擴展。

3）爲集羣內節點添加必要的運維腳本。

刪除過時的、無用的日誌文件，不然磁盤佔滿會致使節點不工做甚至發生故障，如Storm集羣的Supervisor進程日誌、Nimbus進程日誌，Hadoop集羣的各個進程日誌。

爲集羣上的守護進程添加開機自啓動腳本，儘量避免宕機重啓後的人工干預。例如，CDH已經爲Hadoop、Hive、HBase等添加了啓動腳本，rpm安裝後進程可在機器重啓後自啓動。

同時監控集羣上的守護進程是否存在，不存在則直接重啓。這種方式只適用於無狀態的進程，像Storm的Nimbus、Supervisor進程，Zookeeper進程等，都應該加上這樣的監控腳本，確保服務進程終止後能夠儘快被重啓恢復。例如，經過設置crontab每分鐘檢查一次。

4）根據業務特色添加應用層的監控和告警。

對於業務層的計算任務，能夠監控天天產出數據的大小和時間，若是出現異常狀況（如數據文件的大小驟變，計算結果產出延遲等）則進行報警。

對於實時計算的應用，最重要的是數據處理是否出現明顯延遲（分鐘延遲、秒級延遲等），基於此，能夠定義一系列的規則，觸發不一樣級別的報警，以便第一時間發現並解決問題。

5）使多個用戶可以共享集羣的計算和存儲資源。

使用集羣的Quota限制不一樣用戶的資源配額，例如Hadoop就提供了這一機制；可是，Storm和HBase目前並無發現有什麼方式能夠限制。

經過多用戶隊列的方式對集羣的資源進行限制與隔離。例如Hadoop爲了解決多用戶爭用計算資源的狀況，使用Capacity Scheduler或Fair Scheduler的方式，對不一樣用戶提交的做業進行排隊，能夠直接部署應用，也能夠根據業務需求對其進行定製後使用，很方便。

對於Storm集羣，其計算資源也是按照Slots劃分的，所以能夠考慮在Storm之上加上一層資源控制模塊，記錄每一個用戶最大可佔用的Slots數、當前已佔有的Slots數等，從而實現用戶的資源配額（不過目前Storm不管從集羣規模仍是內部使用用戶來看，都還不算多，這一需求並非特別迫切）。

另外，不一樣用戶對集羣的訪問控制權限十分必要。好比，是否能夠提交做業、刪除做業，查看集羣各種資源等，這是保證集羣安全運行的一道基本保障。

6）實時計算應用要想辦法應對流量峯值壓力。

真實壓測：例如爲了應對雙11當天流量壓力，模擬平時3~5倍流量進行壓測，提早發現解決問題，保證系統穩定性。

運維開關：經過加上運維開關，避免流量峯值時刻對系統帶來的衝擊，例如，經過ZooKeeper對實時計算應用加上開關，在線調整處理速度，容許必定時間的延遲，將流量平滑處理掉。

容錯機制：實時計算的場景隨流量的變化而變化，可能遇到各類突發狀況，爲此在作系統設計和實現時必須充分考慮各類可能出錯的狀況（如數據延遲、丟數據、髒數據、網絡斷開等等）。

穩定性與準確性折中：建議不要在實時計算中過於追求計算結果的準確性，爲了保證系統的穩定運行，能夠犧牲必定的準確性，保證應用可以「活下去」更重要。

7）多種方式追蹤、定位、解決集羣中的問題。

藉助於集羣的監控系統，定位問題所在的具體機器。登陸到問題機器上，也可以使用top、free、sar、iostat、nmon等經常使用命令進一步查看、確認系統資源使用狀況、問題之處。

同時，經過查看集羣上的日誌（包括集羣級別、業務級別），確認是否有異常日誌及對應的緣由。

另外，也可經過strace、jvm工具等方式追蹤工做進程，從問題現場尋找緣由。

8）集羣運行任務的一些調優思路。

綜合考慮系統資源負載：結合集羣監控，從各個節點上任務實例的運行狀況（CPU、內存、磁盤、網絡），定位系統瓶頸後再作優化，儘量使得每一個節點的系統資源獲得最大利用，尤爲是CPU和內存。

任務實例並行化：能夠並行化的直接採用多shard，多進程/多線程的方式；複雜的任務則能夠考慮先進行拆解，而後進行並行化。

不一樣類型的任務：CPU密集型考慮利用多核，將CPU儘量跑滿；內存密集型則考慮選擇合適的數據結構、數據在內存中壓縮（壓縮算法的選擇）、數據持久化等。

緩存Cache：選擇將頻繁使用、訪問時間開銷大的環節作成Cache；經過Cache減小網絡/磁盤的訪問開銷；合理控制Cache的大小；避免Cache帶來的性能顛簸，等等。

 

 

出自 http://www.cnblogs.com/panfeng412/archive/2013/06/27/cluster-use-and-maintain-experience-summary.html