在生产集群上运行topology跟本地模式差不多。下面是步骤：
1）定义topology（如果是java的话， 用TopologyBuilder)
2) 使用StormSubmitter来把topology提交到集群。StormSubmitter的参数有：topology的名字，topology的配置对象，以及topology本身。
比如:
1 2 3 4 5
Config conf = new Config(); conf.setNumWorkers(20); conf.setMaxSpoutPending(5000); StormSubmitter.submitTopology("name", conf, topology);
3) 创建一个包含你的程序代码以及你代码所依赖的依赖包的jar包（有关storm的jar包不用包括， 这些jar包会在工作节点上自动被添加到classpath里面去)。如果你使用maven, 那么插件:Maven Assembly Plugin可以帮你打包，只要把下面的配置加入你的pom.xml。
01 02 03 04 05 06 07 08 09 10 11 12 13
<plugin> <artifactId>maven-assembly-plugin</artifactId> <configuration> <descriptorRefs> <descriptorRef>jar-with-dependencies</descriptorRef> </descriptorRefs> <archive> <manifest> <mainClass>com.path.to.main.Class</mainClass> </manifest> </archive> </configuration> </plugin>
然后运行mvn assembly:assembly就可以打包了. 再说一下，不用包括storm相关的jar包，它们会自动加到classpath里面。
4）用storm客户端去提交jar包:
1
storm jar allmycode.jar org.me.MyTopology arg1 arg2 arg3
storm jar 会把代码提交到集群并且配置StormSubmitter类以让它和正确的集群进行通信。在这个例子里面，上传jar包之后storm jar命令会调用org.me.MyTopology的main函数，参数是 arg1, arg2, arg3。关于如何配置你的storm客户端去和storm集群进行通信可以看下配置storm开发环境。
常见配置
有很多topology级的配置可以设。这里有关于所有配置的清单， 以”TOPOLOGY”打头的配置是topology级别的配置，可以覆盖全局级别的配置。下面是一些比较常见的：
1）Config.TOPOLOGY_WORKERS: 这个设置用多少个工作进程来执行这个topology。比如，如果你把它设置成25， 那么集群里面一共会有25个java进程来执行这个topology的所有task。如果你的这个topology里面所有组件加起来一共有150的并行度，那么每个进程里面会有6个线程(150 / 25 = 6)。
2）Config.TOPOLOGY_ACKERS: 这个配置设置acker线程的数目。Ackers是Storm的可靠性API的一部分，关于storm的可靠性API可以看下：Twitter Storm如何保证消息不丢失。
3）Config.TOPOLOGY_MAX_SPOUT_PENDING: 这个设置一个spout task上面最多有多少个没有处理的tuple（没有ack/failed）回复， 我们推荐你设置这个配置，以防止tuple队列爆掉。
4）Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS: 这个配置storm的tuple的超时时间 – 超过这个时间的tuple被认为处理失败了。这个设置的默认设置是30秒，对于大多数的topology都已经足够了。关于storm的可靠性API可以看看Twitter Storm如何保证消息不丢失。
5）Config.TOPOLOGY_SERIALIZATIONS: 为了在你的tuple里面使用自定义类型，你可以用这个配置注册自定义serializer。
终止一个topology
要终止一个topology, 执行:
1
storm kill {stormname}
其中{stormname}是提交topology给storm集群的时候指定的名字。
storm不会马上终止topology。相反，它会先终止所有的spout，让它们不再发射任何新的tuple， storm会等Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS秒之后才杀掉所有的工作进程。这会给topology足够的时间来完成所有我们执行storm kill命令的时候还没完成的tuple。
更新一个运行中的topology
为了更新一个正在运行的topology, 唯一的选择是杀掉正在运行的topology然后重新提交一个新的。一个计划中的命令是实现一个storm swap命令来运行时更新topology， 并且保证前后两个topology不会同时在运行，同时保证替换所造成的“停机”时间最少。
监控topology