運維管理

Ganglia是個很不錯的工具，它的安裝配置過程簡單，採集的指標豐富，而且支援自定義，像Hadoop、HBase都對Ganglia進行了擴充套件。

在做系統設計和實現時必須充分考慮各種可能出錯的情況（如資料延遲、丟資料、髒資料、網路斷開等等）。

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

登入到問題機器上，也可使用top、free、sar、iostat、nmon等常用命令進一步檢視、確認系統資源使用情況、問題之處。

同時，通過檢視叢集上的日誌（包括叢集級別、業務級別），確認是否有異常日誌及對應的原因。

strace、jvm工具等方式追蹤工作程式，從問題現場尋找原因。

系統的自動安裝 kickstart cobbler

1.      伺服器型號的區分，為以後的統一化和標準化作硬體上的準備，很多人忽視這一點，其實如果這一點做得好會使後面的運維工作輕鬆很多，根據應用我們主要把伺服器分為3中，cpu密集型，主要用於大量計算應用，比如p2p;記憶體密集型，用於cache類應用，比如squid,varnish快取伺服器；磁碟密集型，用於大儲存類應用，比如視訊儲存伺服器，Hadoop日誌儲存叢集。

2.      系統的的自動安裝，主要有kickstart和cobbler

3.      統一的yum源和定製化的rpm包， 並整合至yum源站，為後續的環境初始化做軟體上的準備

4.      構建專屬於自己的內網DNS

5.      標準化的統一的命名方式（標準化基礎），便於使用puppet管理，並且減少操作的錯誤，如果每個機器的hostname都為localhost，那將是一個多麼可怕的事。。。在我們的生產環境中主要使用下面這種命名方式

機房-主業務-應用程式-IP後兩位-公司域名，這樣一眼就可以看出是哪臺伺服器，應用於什麼業務，報警也可以直接定位。

6.自動化的配置管理和環境部署工具：puppet,puppet的模組編寫要儘量減少模組直接的耦合度，並使用class繼承的方式來減少運維的工作量，定製化的facter變數會使軟體的配置環境更加靈活，由於puppet暫時不支援群集，所以在實際應用中需要部署多套，根據經驗，1500臺左右的server時puppet會出現效能問題。

7.      強大有效的監控系統，在生產環境中我們使用了zabbix proxy+zabbix master的群集結構，zabbix可以實現有效的系統和應用級別的監控，應用監控同時也使用了ppmon來實現多點監控。

選擇zabbix有一個最大的好處，就是監控資料是存放在資料庫中的，這樣就可以利用資料庫中的資料做很多操作，比如可以分析一段時間內伺服器的各個效能指標，檢視伺服器的資源利用率，可以對資料進行聚合操作，從而分析全網的指標，比如總的流量，總的http code分佈情況。

8.      日誌收集伺服器群集 和qos分析系統，構建 有效的日誌收集系統可以有效地對使用者的訪問資料進行整合和分析，可以快速的分析qos，對應重要的節點我們採用本地分析並匯入mongodb,最後匯入zabbix的方式，非重要節點則直接將日誌打包壓縮，通過ftp上傳至hadoop資料倉儲叢集中。

9.      構建冗餘的結構，消除單點，在生成環境中對於一些重要節點都採用keepalived-ha的方案來提高冗餘度。對於resin,php等應用伺服器則在前端使用nginx做反向代理，同時nginx使用keepalived-ha

10.  自動化的程式碼分發系統，主要是controltier + svn的使用，可以方便快速地部署程式碼。

任務例項並行化：可以並行化的直接採用多shard，多程式/多執行緒的方式；複雜的任務則可以考慮先進行拆解，然後進行並行化。

不同型別的任務：CPU密集型考慮利用多核，將CPU儘可能跑滿；記憶體密集型則考慮選擇合適的資料結構、資料在記憶體中壓縮（壓縮演算法的選擇）、資料持久化等。

快取Cache：選擇將頻繁使用、訪問時間開銷大的環節做成Cache；通過Cache減少網路/磁碟的訪問開銷；合理控制Cache的大小；避免Cache帶來的效能顛簸，等等。

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帶來的效能顛簸，等等。