nimbus
守護進程的主要職責是管理，協調和監控在集羣上運行的topology. 包括topology的發佈，任務指派，事件處理失敗時重新指派任務。
將topology發佈到Storm集羣，將預先打包成jar文件的topology和配置信息提交到nimbus服務器上。一旦nimbus接收到topology的壓縮包，會將jar包分發到足夠數量的supervisor節點上。當supervisor節點接收到了topology的壓縮文件，nimbus就會指派task（bolt和spout實例）到每個supervisor並且發送信息指示supervisor生成足夠的worker來執行指派的task。
nimbus記錄所有supervisor節點的狀態和分配給它們的task。如果nimbus發現某個supervisor沒有上報心跳或者已經不可達了，它會將故障supervisor分配的task重新分配到集羣中的其他supervisor節點。
前面提到過，嚴格意義上講nimbus不會引起單點故障。這個特性是因爲nimbus並不參與topology的數據處理過程，它僅僅是管理topology的初始化，任務分發和進行監控。實際上，如果nimbus守護進程topology運行時停止了，只要分配的supervisor和worker健康運行，topology一直繼續數據處理。要注意的是，在nimbus已經停止的情況下supervisor異常終止，因爲沒有nimbus守護進程來重新指派失敗這個終止的supervisor的任務，數據處理就會失敗。
supervisor守護進程的工作方式
supervisor守護進程等待nimbus分配任務後生成並監控workers（JVM進程）執行任務。supervisor和worker都是運行在不同的JVM進程上，如果由supervisor拉起的一個worker進程因爲錯誤（或者因爲Unix終端的kill-9命令，Window的tskkill命令強制結束）異常退出，supervisor守護進程會嘗試重新生成新的worker進程。
如果一個worker甚至整個supervisor節點都故障了，Storm怎麼保障出錯時正在處理的tuples的傳輸？
答案就是Storm的tuple的應答確認機制中。當打開了可靠傳輸的選項，傳輸到故障節點上的tuples將不會收到應答確認，spout會因爲超時而重新發射原始tuple。這樣的過程會一直重複直到topology從故障中恢復開始正常處理數據。（數據會發送到worker的本地隊列中，一旦worker恢復，就會開始處理這些數據了）。