作者: 大圓那些事 | 文章可以轉載，請以超鏈接形式標明文章原始出處和作者信息
本人目前很重要的一部分工作是參與或負責部門內一些集群的維護、應用開發以及優化，其中包括：HBase集群、Storm集群、Hadoop集群、Super Mario集群（部門內部開發的實時流處理系統）等，隨着業務的拓展，集群機器數已經小有規模。
接下來是我對自己這1年多以來，在集群應用與運維方面所做事情的梳理與總結。以下內容有些零散，大家姑且當做一篇非嚴格意義上的技術文章來閱讀。
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帶來的性能顛簸，等等。