**:
本人目前很重要的一部分工作是參與或負責部門內一些集群的維護、應用開發以及優化，其中包括：hbase集群、storm集群、hadoop集群、super mario集群（部門內部開發的實時流處理系統）等，隨著業務的拓展，集群機器數已經小有規模。
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倍流量進行壓測，提前發現解決問題，保證系統穩定性。
容錯機制：實時計算的場景隨流量的變化而變化，可能遇到各種突發情況，為此在做系統設計和實現時必須充分考慮各種可能出錯的情況（如資料延遲、丟資料、髒資料、網路斷開等等）。
穩定性與準確性折中：建議不要在實時計算中過於追求計算結果的準確性，為了保證系統的穩定執行，可以犧牲一定的準確性，保證應用能夠「活下去」更重要。
7）多種方式追蹤、定位、解決集群中的問題。
借助於集群的監控系統，定位問題所在的具體機器。登入到問題機器上，也可使用top、free、sar、iostat、nmon等常用命令進一步檢視、確認系統資源使用情況、問題之處。
同時，通過檢視集群上的日誌（包括集群級別、業務級別），確認是否有異常日誌及對應的原因。
另外，也可通過strace、jvm工具等方式追蹤工作程序，從問題現場尋找原因。
8）集群執行任務的一些調優思路。
綜合考慮系統資源負載：結合集群監控，從各個節點上任務例項的運**況（cpu、記憶體、磁碟、網路），定位系統瓶頸後再做優化，盡可能使得每個節點的系統資源得到最大利用，尤其是cpu和記憶體。
任務例項並行化：可以並行化的直接採用多shard，多程序/多執行緒的方式；複雜的任務則可以考慮先進行拆解，然後進行並行化。
不同型別的任務：cpu密集型考慮利用多核，將cpu盡可能跑滿；記憶體密集型則考慮選擇合適的資料結構、資料在記憶體中壓縮（壓縮演算法的選擇）、資料持久化等。
快取cache：選擇將頻繁使用、訪問時間開銷大的環節做成cache；通過cache減少網路/磁碟的訪問開銷；合理控制cache的大小；避免cache帶來的效能顛簸，等等。
linux伺服器集群運維經驗
以下是自己在運維工作中的一點經驗和看法，希望對大家有所幫助 2.系統的的自動安裝，主要有kickstart和cobbler 3.統一的yum源和定製化的rpm包，並整合至yum源站，為後續的環境初始化做軟體上的準備 4.構建專屬於自己的內網dns 5.標準化的統一的命名方式 標準化基礎 便於使用pu...
Elasticsearch集群運維
1 es滾動重啟 準備工作 提前開啟如下資訊，有些api是需要觀察的各項指標 出現問題則停止重啟 其餘是配合檢查的api 檢視集群unassigen shards 原因 curl 集群配置 curl pending tasks curl 集群健康 curl 重啟client node組節點 star...
Linux 運維經驗
以下是自己在運維工作中的一點經驗和看法，希望對大家有所幫助 2.系統的的自動安裝，主要有kickstart和cobbler 3.統一的yum源和定製化的rpm包，並整合至yum源站，為後續的環境初始化做軟體上的準備 4.構建專屬於自己的內網dns 5.標準化的統一的命名方式 標準化基礎 便於使用pu...