本节书摘来自华章计算机《Storm分布式实时计算模式》一书中的第2章，第2.1节,作者：（美）P. Taylor Goetz Brian O’Neill 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
第2章 配置Storm集群
在本章中你将深入理解Storm的技术栈，它的软件依赖，以及搭建和部署Storm集群的过程。我们首先会在伪分布式模式下安装Storm，所有的组件都安装在同一台机器上，而不是在多台机器上。一旦你了解了安装和配置Storm的基本步骤，我们就可以通过Puppet这个工具进行自动化的安装，这样的话部署多节点的集群可以节省大量的时间和精力。
本章包括以下内容：
- 组成Storm集群的不同组件和服务
- Storm的技术栈
- 在Linux上安装和配置Storm
- Storm的配置参数
- Storm的命令行接口
- 使用服务提供工具Puppet进行自动安装
2.1 Storm集群的框架
Storm集群遵循主/从（master/slave）结构，和Hadoop等分布式计算技术类似，语义上稍有不同。主/从结构中，通常有一个配置中静态指定或运行时动态选举出的主节点。Storm使用前一种实现方式。主/从结构中因为引入了单点故障的风险而被诟病，我们会解释Storm的主节点是半容错的。
Storm集群由一个主节点（称为nimbus）和一个或者多个工作节点（称为supervisor）组成。在nimbus和supervisor节点之外，Storm还需要一个Apache ZooKeeper的实例，ZooKeeper实例本身可以由一个或者多个节点组成。如图2-1所示。
nimbus和supervisor都是Storm提供的后台守护进程，可以共存在同一台机器上。实际上，可以建立一个单节点伪集群，把nimbus、supervisor和ZooKeeper进程都运行在同一台机器上。
2.1.1 理解nimbus守护进程
nimbus守护进程的主要职责是管理，协调和监控在集群上运行的topology。包括topology的发布，任务指派，事件处理失败时重新指派任务。
将topology发布到Strom集群，将预先打包成jar文件的topology和配置信息提交（submitting）到nimbus服务器上。一旦nimbus接收到了topology的压缩包，会将jar包分发到足够数量的supervisor节点上。当supervisor节点接收到了topology压缩文件，nimbus就会指派task（bolt和spout实例）到每个supervisor并且发送信号指示supervisoer生成足够的worker来执行指派的task。
nimbus记录所有supervisor节点的状态和分配给它们的task。如果nimbus发现某个supervisor没有上报心跳或者已经不可达了，它会将故障supervisor分配的task重新分配到集群中的其他supervisor节点。
前面提到过，严格意义上讲nimbus不会引起单点故障。这个特性是因为nimubs并不参与topology的数据处理过程，它仅仅是管理topology的初始化，任务分发和进行监控。实际上，如果nimbus守护进程在topology运行时停止了，只要分配的supervisor和worker健康运行，topology一直继续数据处理。要注意的是，在nimbus已经停止的情况下supervisor异常终止，因为没有nimbus守护进程来重新指派失败这个终止的supervisor的任务，数据处理就会失败。
2.1.2 supervisor守护进程的工作方式
supervisor守护进程等待nimbus分配任务后生成并监控workers（JVM进程）执行任务。supervisor和worker都是运行在不同的JVM进程上，如果由supervisor拉起的一个woker进程因为错误（或者因为Unix终端的kill-9命令，Window的tskkill命令强制结束）异常退出，supervisor守护进程会尝试重新生成新的worker进程。
看到这里你可能想知道Storm的有保障传输机制如何适应其容错模型。如果一个worker甚至整个supervisor节点都故障了，Storm怎么保障出错时正在处理的tuples的传输？
答案就在Storm的tuple锚定和应答确认机制中。当打开了可靠传输的选项，传输到故障节点上的tuples将不会收到应答确认，spout会因为超时而重新发射原始tuple。这样的过程会一直重复直到topology从故障中恢复开始正常处理数据。
2.1.3 Apache ZooKeeper简介
ZooKeeper使用一个简单的操作原语集合和分组服务，在分布式环境下提供了集中式的信息维护管理服务。它是一种简单但功能强大的分布式同步机制，允许客户端的应用程序监控或者订阅数据集中的部分数据，当数据产生，更新或者修改时，客户端都会收到通知。使用常见的ZooKeeper模式或方法，开发者可以实现分布式计算所需要的很多种机制，比如Leader选举，分布式锁和队列。
Storm主要使用ZooKeeper来协调一个集群中的状态信息，比如任务的分配情况，worker的状态，supervisor之间的nimbus的拓扑度量。nimbus和supervisor节点之间的通信主要是结合ZooKeeper的状态变更通知和监控通知来处理的。
Storm对ZooKeeper的使用相对比较轻量化，不会造成很重的资源负担。对于重量级的数据传输操作，比如发布topology时传输jar包，Storm依赖Thirft进行通信。我们将会看到，topology组件之间的数据传输（最影响效率的地方）是在底层进行的，并且经过了性能优化。
2.1.4 Storm的DRPC服务工作机制
Storm应用中的一个常见模式期望将Storm的并发性和分布式计算能力应用到“请求-响应”范式中。一个客户端进程或者应用提交了一个请求并同步地等待响应。这样的范式可能看起来和典型topology的高异步性、长时间运行的特点恰恰相反，Storm具有事务处理的特性来实现这种应用场景，如图2-2所示。
为了实现这个功能，Storm将额外的服务（Storm DRPC）以及spout和bolt整合在一起工作，提供了可扩展的分布式RPC能力。
DRPC功能是完全是可选的，当Storm集群中的应用有使用这个功能时，DRPC服务节点才是必须的。
2.1.5 Storm UI
Storm UI也是可选功能，非常有用，会提供一个基于Web的GUI来监控Storm集群，对正在运行的topology有一定的管理功能。Storm UI提供了已经发布的topology的统计信息，对监控Storm集群的运转和topology的功能有很大帮助，如图2-3所示。
Storm UI只能报告由nimubs的trhift API获取的信息，不会影响到topology上其他功能。Storm UI可以随时开关而不影响任何topology的运行，在那里它完全是无状态的。它还可以用配置来进行一些简单的管理功能，如开启、停止、暂停和重新均衡负载topology。