# 設置Storm集群
本頁概述了啟動和運行Storm集群的步驟,如果您使用AWS,您應該查看[storm-部署](https://github.com/nathanmarz/storm-deploy/wiki)項目.[storm-部署](https://github.com/nathanmarz/storm-deploy/wiki) 在EC2上完全自動化配置和安裝Storm集群. 它還為您設置Ganglia,以便您可以監視CPU,磁盤和網絡使用情況.
如果您在運行Strom集群時遇到困難,請首先在 [Troubleshooting](Troubleshooting.html) 頁尋求解決. 再者, 查看或者發送郵件列表.
下面是部署Storm集群的步驟總結:
1. 設置 Zookeeper 集群.
2. 設置Nimbus和worker 節點的安裝環境
3. 在集群節點下載解壓 Storm
4. 在storm.yaml中設置必要的配置
5. 在指導下使用 storm 腳本來啟動相應的守護進程.(備注:master包括nimbus和UI進程,slave包括supervisor和logviewer)
### 設置Zookeeper集群
Storm 使用 Zookeeper 協調管理集群. Zookeeper **并不是** 用于消息傳遞, 所以 Storm 對Zookeeper造成的負載壓力非常低. 單節點Zookeeper集群在大多數情況下應該是足夠的,但是如果您想要故障轉移或部署大型Storm集群,則可能需要較大的Zookeeper集群. 部署Zookeeper的說明是[這里](http://zookeeper.apache.org/doc/r3.3.3/zookeeperAdmin.html).
關于Zookeeper部署的幾點注意事項:
1.在監督下運行Zookeeper至關重要,因為Zookeeper是故障快速的,如果遇到任何錯誤的情況都將退出進程. 有關詳細信息,請參閱[這里](http://zookeeper.apache.org/doc/r3.3.3/zookeeperAdmin.html#sc_supervision) .
2.建立一個cron定時任務來壓縮Zookeeper的數據和事務日志至關重要. Zookeeper守護進程本身不會這樣做,如果沒有設置cron,Zookeeper將很快耗盡磁盤空間. 有關詳細信息,請參閱[這里](http://zookeeper.apache.org/doc/r3.3.3/zookeeperAdmin.html#sc_maintenance).
### Nimbus 和 worker 節點的安裝環境
接下來你需要準備Nimbus 和 worker 節點的安裝環境:
1. Java 7 (備注:建議使用Java 8,畢竟很多的項目開發環境已經遷移到8以上)
2. Python 2.6.6
這些依賴版本是Storm已經測試過的. Storm 在不同的Java 或Python版本上也許會存在問題.
### 下載解壓 Storm
接下來,下載一個Storm版本,并解壓zip文件到Nimbus和每個worker機器上的某個目錄下. Storm版本可以從這里[下載](http://github.com/apache/storm/releases).
### 在storm.yaml中設置必要的配置
Storm 發布包中在目錄`conf/storm.yaml` 下包含一個默認的配置文件. 你可以在[這里](http://github.com/apache/storm/blob/master%0A/conf/defaults.yaml)查看默認值. storm.yaml 中的存在的配置項會覆蓋掉 defaults.yaml中相應的配置項. 下面一些配置是集群運行時所必要的:
1) **storm.zookeeper.servers**: 這是一個Storm集群所依賴 Zookeeper 集群的hosts列表. 類似于:
```
storm.zookeeper.servers:
- "111.222.333.444"
- "555.666.777.888"
```
如果配置的Zookeeper集群不是默認的端口, 你應該設置 **storm.zookeeper.port** 選項.
2) **storm.local.dir**: Nimbus 和 Supervisor 守護進程需要配置一個本地目錄來存儲少量狀態信息(例如jars包,配置文件等等). 您應該在每個機器上創建該目錄,給予適當的權限,然后使用此配置填寫目錄位置. 例如:
```
storm.local.dir: "/mnt/storm"
```
如果您在windows下運行Strom,應該如下: `yaml storm.local.dir: "C:\\storm-local"` 如果您使用相對路徑,那么路徑是相對于(STORM_HOME). 您也可以使用默認值 `$STORM_HOME/storm-local`
3) **nimbus.seeds**: worker節點需要知道哪些機器是主機的候選者,以便下載 topology jar和confs(nimbus.host 在1.0之后已經廢棄,這里實現了HA). 例如:
```
nimbus.seeds: ["111.222.333.44"]
```
鼓勵您填寫*_機器的FQDN *_(Fully Qualified Domain Name,全域名)列表. 如果要設置Nimbus HA,則必須解決運行nimbus的所有機器的FQDN.當您只想設置“偽分布式”集群時您可能希望將其保留為默認值,仍然鼓勵您填寫FQDN.
4) **supervisor.slots.ports**: 對于每個worker節點,您可以使用此配置設置在該計算機上運行的worker數量. 每個worker使用單個端口接收消息,并且此設置定義哪些端口打開以供使用. 如果您在此定義五個端口,那么Storm將分配最多五個worker在本機上運行. 如果您定義了三個端口,Storm將只能運行三個worker. 默認情況下,此設置被配置為在端口6700,6701,6702和6703上運行4個worker:
```
supervisor.slots.ports:
- 6700
- 6701
- 6702
- 6703
```
### 監控 Supervisors 健康狀態
Storm提供了一種機制,管理員可以通過該機制配置supervisor進程定期運行管理員提供的腳本,以確定節點是否健康. 管理員可以通過執行位于storm.health.check.dir中的腳本來確定supervisor節點是否處于健康狀態. 如果腳本檢測到節點處于不正常狀態,則必須標準流輸出ERROR開頭的信息. supervisor將定期運行健康檢查目錄中的腳本并檢查輸出. 如果腳本的輸出包含字符串ERROR,如上所述,superviosr進程將關閉所有worker并退出.
如果supervisor 已經有監控腳本,通過執行 "/bin/storm node-health-check"可以確定 supervisor 是否可以啟動 或 supervisor 節點是否健康
健康檢查目錄的地址通過以下配置項設置:
```
storm.health.check.dir: "healthchecks"
```
腳本必須有執行權限. 健康檢查腳本可以設置超時失敗,在時間段內腳本未執行完畢則被標記為失敗,腳本運行超時時間設置:
```
storm.health.check.timeout.ms: 5000
```
### 配置外部libs和環境變量 (可選)
490/5000 如果需要外部庫或自定義插件的支持,可以將這些jar放在extlib/ 和 extlib-daemon/ 目錄中. 請注意,extlib-daemon/ 目錄存儲僅由守護進程(Nimbus,Supervisor,DRPC,UI,Logviewer)所調用加載的jar,例如HDFS和自定義調度庫. 因此,用戶可以配置兩個環境變量STORM_EXT_CLASSPATH和STORM_EXT_CLASSPATH_DAEMON,以便包含外部classpath和僅限守護進程調用的外部classpath.
### 在指導下使用 "storm" 腳本啟動相應的守護進程
最后一步是啟動所有的Storm守護進程. 在指導下運行這些守護進程是至關重要的. Storm是一個**fail-fast**系統,這意味著每當遇到意外錯誤時,進程將停止. Storm的設計使得它可以在任何時候安全地停止,并在進程重新啟動時正確恢復. 這就是為什么Storm不會在進程中保持狀態 - 如果Nimbus或者Supervisors重新啟動,運行的topologies不會受到影響. 以下是運行Storm守護進程的方法:
1. **Nimbus**: 在主節點(Nimbus)運行命令行 "bin/storm nimbus".
2. **Supervisor**: 在每個supervisor節點運行命令行 "bin/storm supervisor". supervisor守護程序負責啟動和停止該機器上的worker進程.
3. **UI**:通運行命令“bin/storm ui”,運行Storm UI(一般選擇在Nimbus節點啟動一個,可以從瀏覽器訪問群集和topologies的診斷信息).可以通過瀏覽網頁瀏覽器訪問http://{ui host}:8080.
正如你所看到的,運行守護進程非常簡單.守護進程將日志輸出到您解壓縮Storm時的 logs/ 目錄.
- Storm 基礎
- 概念
- Scheduler(調度器)
- Configuration
- Guaranteeing Message Processing
- 守護進程容錯
- 命令行客戶端
- Storm UI REST API
- 理解 Storm Topology 的 Parallelism(并行度)
- FAQ
- Layers on Top of Storm
- Storm Trident
- Trident 教程
- Trident API 綜述
- Trident State
- Trident Spouts
- Trident RAS API
- Storm SQL
- Storm SQL 集成
- Storm SQL 示例
- Storm SQL 語言參考
- Storm SQL 內部實現
- Flux
- Storm 安裝和部署
- 設置Storm集群
- 本地模式
- 疑難解答
- 在生產集群上運行 Topology
- Maven
- 安全地運行 Apache Storm
- CGroup Enforcement
- Pacemaker
- 資源感知調度器 (Resource Aware Scheduler)
- 用于分析 Storm 的各種內部行為的 Metrics
- Windows 用戶指南
- Storm 中級
- 序列化
- 常見 Topology 模式
- Clojure DSL
- 使用沒有jvm的語言編輯storm
- Distributed RPC
- Transactional Topologies
- Hooks
- Storm Metrics
- Storm 狀態管理
- Windowing Support in Core Storm
- Joining Streams in Storm Core
- Storm Distributed Cache API
- Storm 調試
- 動態日志級別設置
- Storm Logs
- 動態員工分析
- 拓撲事件檢查器
- Storm 與外部系統, 以及其它庫的集成
- Storm Kafka Integration
- Storm Kafka 集成(0.10.x+)
- Storm HBase Integration
- Storm HDFS Integration
- Storm Hive 集成
- Storm Solr 集成
- Storm Cassandra 集成
- Storm JDBC 集成
- Storm JMS 集成
- Storm Redis 集成
- Azue Event Hubs 集成
- Storm Elasticsearch 集成
- Storm MQTT(Message Queuing Telemetry Transport, 消息隊列遙測傳輸) 集成
- Storm MongoDB 集成
- Storm OpenTSDB 集成
- Storm Kinesis 集成
- Storm Druid 集成
- Storm and Kestrel
- Container, Resource Management System Integration
- Storm 高級
- 針對 Storm 定義一個不是 JVM 的 DSL
- 多語言協議
- Storm 內部實現
- 翻譯進度