Storm介紹(二) Storm介紹(二)

Storm介紹(二)

轉載：https://www.cnblogs.com/Jack47/p/storm_intro-2.html

 

本文是Storm系列之一，主要介紹Storm的架構設計，推薦讀者在閱讀Storm介紹(一）的基礎之上，閱讀這一篇。本文只是做者的讀書筆記，偏重於淺層次的架構介紹，若是想真正理解內部設計時候的權衡，還須要更多的去閱讀Storm源碼。

理解Storm的架構，有助於幫助咱們理解大型分佈式系統設計中須要解決的問題，以及解決問題的思路，幫助咱們更好的進行Storm性能調優化。

架構

先上一張Storm的架構圖，若是熟悉 GFS和Hadoop的架構，會發現這些系統的架構圖都很相似。

Storm架構圖

 

各節點的做用

若是你熟悉Hadoop的話，能夠這樣作一下類比：

Hadoop	Storm
JobTracker	Nimbus(只有一個)
TaskTracker	Supervisor（有不少個)
MapReduce任務	Topology

能夠看到Nimbus是調度器，Worker是Task的容器，Task是任務的真正執行者。

啓動拓撲

爲了在集羣上啓動一個拓撲，須要首先把代碼打包成一個「胖jar包」--必須包含全部的依賴代碼，除了Storm它自身，由於Storm集羣會提供。而後在一臺安裝了storm命令行的機器上經過storm jar命令來提交拓撲:

storm jar my-topology-version-with-dependency.jar com.corp.MyTopology arg1 arg2

這個命令會連到Nimbus，上傳jar包。接下來Nimbus會把拓撲的代碼運送到多臺不一樣的機器或者JVM上。只有當拓撲在機器上部署成功了而且在JVM中初始化了以後，才能真正開始處理消息。

Master結點(Master node)

在分佈式系統中，調度服務很是重要，它的設計，會直接關係到系統的運行效率，錯誤恢復(fail over),故障檢測(error detection)和水平擴展(scale)的能力。

集羣上任務(task)的調度由一個Master節點來負責。這臺機器上運行的Nimbus進程負責任務的調度。另一個進程是Storm UI，能夠界面上查看集羣和全部的拓撲的運行狀態。

從節點(Slave node)

Storm集羣上有多個從節點，他們從Nimbus上下載拓撲的代碼，而後去真正執行。Slave上的Supervisor進程是用來監督和管理實際運行業務代碼的進程。在Storm 0.9以後，又多了一個進程Logviewer,能夠用Storm UI來查看Slave節點上的log文件。
在配置文件storm.yaml中,決定了一臺機器上運行幾個worker:

supervisor.slots.ports:
- 6700 - 6701 - 6702

ZooKeeper的做用

ZooKeeper在Storm上不是用來作消息傳輸用的，而是用來提供協調服務(coordination service)，同時存儲拓撲的狀態和統計數據。

• ZooKeeper至關於一塊黑板，Supervisor，Nimbus和worker都在上面留下約定好的信息。例如Supervisor啓動時，會在ZooKeeper上註冊，Nimbus就能夠發現Supervisor；Supervisor在ZooKeeper上留下心跳信息，Nimbus經過這些心跳信息來對Supervisor進行健康檢測，檢測出壞節點
• 因爲Storm組件(component)的狀態信息存儲在ZooKeeper上，因此Storm組件就能夠無狀態，能夠 kill -9來殺死
  • 例如：Supervisors/Nimbus的重啓不影響正在運行中的拓撲，由於狀態都在ZooKeeper上，從ZooKeeper上從新加載一下就行了
• 用來作心跳
  • Worker經過ZooKeeper把孩子executor的狀況以心跳的形式彙報給Nimbus
  • Supervisor進程經過ZK把本身的狀態也以心跳的形式彙報給Nimbua
• 存儲最近任務的錯誤狀況(拓撲中止時會刪除)

Storm的容錯(Fault Tolerance)機制

正如「搭建一個Storm集羣」一文介紹的同樣，必須用工具如daemontools或者monit來監控Nimbus和Supervisor的後臺進程。這樣若是Nimbus或者Supervisor進程掛掉，會被daemontools檢測到，並進行重啓。

Nimbus和Supervisor進程被設計成快速失敗(fail fast)的(當遇到異常的狀況，進程就會掛掉)而且是無狀態的(狀態都保存在Zookeeper或者在磁盤上)。

最重要的是，worker進程不會由於Nimbus或者Supervisor掛掉而受影響。這跟Hadoop是不同的，當JobTracker掛掉，全部的任務都會沒了。

1. 當Nimbus掛掉會怎樣？

   若是Nimbus是以推薦的方式處於進程監管(例如經過supervisord)之下，那它會被重啓，不會有任何影響

   不然當Nimbus掛掉後：
   • 已經存在的拓撲能夠繼續正常運行，可是不能提交新拓撲
   • 正在運行的worker進程仍然能夠繼續工做。並且當worker掛掉，supervisor會一直重啓worker。
   • 失敗的任務不會被分配到其餘機器(是Nimbus的職責)上了

2. 當一個Supervisor(slave節點)掛掉會怎樣？

   若是Supervisor是以推薦的方式處於進程監管(例如經過(supervisord)[supervisord.org/])之下，那它會被重啓，不會有任何影響

   不然當Supervisor掛掉: 分配到這臺機器的全部任務(task)會超時，Nimbus會把這些任務(task)從新分配給其餘機器。

3. 當一個worker掛掉會怎麼樣？

   當一個worker掛掉，supervisor會重啓它。若是啓動一直失敗那麼此時worker也就不能和Nimbus保持心跳了，Nimbus會從新分配worker到其餘機器

4. Nimbus算是一個單點故障嗎？
   若是Nimbus節點掛掉，worker進程仍然能夠繼續工做。並且當worker掛掉，supervisor會一直重啓worker。可是，沒有了Nimbus，當須要的時候(若是worker機器掛掉了)worker就不能被從新分配到其餘機器了。
   因此答案是，Nimbus在「某種程度」上屬於單點故障的。在實際中，這種狀況沒什麼大不了的，由於當Nimbus進程掛掉，不會有災難性的事情發生

硬件要求

ZooKeeper

1. 推薦精心設計過的機器，由於ZooKeeper是Storm的瓶頸
   • 每一個機器使用一個ZK的實例
   • 注意由於同一臺機器上的其餘進程或者虛擬機他們是共享這臺機器的，因此可能會影響ZK的性能(來源)
2. I/O是ZooKeeper的瓶頸

• 把ZooKeeper的存儲放到本身的磁盤上
• 使用SSD會顯著提高性能
• 正常狀況下，Zookeeper的每次寫操做都會同步到磁盤，這就致使了兩次磁盤尋址操做(一次是數據，一次是數據的日誌)。當全部的worker都發心跳給ZooKeeper時，可能會顯著影響性能(來源)。
  • 須要監控ZooKeeper節點的I/O負載

1. 推薦在生產環境上運行的ZooKooper集羣有至少3個節點，這樣即便有一個ZooKeeper服務器掛掉了(例如進行維護)，也是能夠的。

Storm安全性

原始設計Storm時，徹底沒有把安全性考慮在內
如今安全性能相關的功能在一步步加進來
Storm 0.9.x版本上的安全問題：

1. 沒有驗證機制(authentication)，沒有受權機制(authorization)
2. 傳輸的數據(例如worker之間)沒有加密
3. ZooKeeper上存儲的數據沒有訪問限制
4. 若是Nimbus的Thrift端口沒有鎖住，任意的用戶代碼均可以在節點上執行

更多Storm安全性方面的建議見這裏

題外話：
在接觸Storm以後，有個問題在個人腦海裏升起，國內的大公司，好比Baidu，Ali，騰訊，都是有誕生Storm這類實時計算框架的土壤的，但是爲何沒有作出來呢？

Apache Storm Basic Training
Fault tolerance

Storm in pictures

Storm 0.9 Basic Training