storm中supervisor的启动exit问题


在使用storm流数据处理框架的过程中,经常会碰到由于服务器出现问题,或者断电等的问题致使storm系统需要重启。有的时候,比如只有nimbus挂掉,但是其他的还是正常运行。则当再次重新启动nimbus时,会看到前面运行的Topology仍然在运行,只是有可能资源(supervisor)分配不均。这个时候,需要将许多的supervisor启动。但是启动的时候经常碰到这样的问题:当执行"storm supervisor"命令时,经常会过一会就会出现“Exit 20              storm supervisor”等诸如此类的问题。本文就来进行一定的解析。


遇到这个问题时,我最初的解决方法是比较土的,也是没有深究的去处理:就是将storm系统重新解压装一遍,然后重新配置一下storm.yaml。

后来考虑到需要去了解下具体的原因。现在比较有效的做法是:将storm.yaml中配置的storm.local.dir目录中的supervisor和workers两个目录删除掉。然后就可以再启动了。


具体的原因还需再考虑。

我现在的想法是:在上次系统非正常退出时,topology仍然还在运行(此时虽然无资源,但仍有这个topology在虚拟的运行)。因此,系统停止后,仍有一部分的配置文件驻留在storm.local.dir中。这部分文件是在storm系统启动时生成的。当再重新启动storm时,这部分旧配置文件的存在会阻止新的配置文件的生成。有可能在配置文件中会有很多的命名机制在启动而导致本supervisor启动不成功。比如:上次非正常退出时,遗留了一个“111111111”的配置文件。这次启动时,要生成一个“2222222222”的配置文件(有可能是按照时间序列来命名的)。这样,因为检测到系统缺少一个“111111111”对应的supervisor实体(只有配置文件的存在,但是supervisor不存在),使得现在的supervisor无法启动(有可能是nimbus想当然的认为还存在一个“11111111111”的supervisor,占用着这台机器上的资源,使得“22222222222”无法开启。)


如果有这种场景:当nimbus因为出问题而关闭后。这个时候topology其实还是在运行的,不过有没有在处理数据我现在还不能确定。这个时候,如果直接启动nimbus上的supervisor的话(当前前提是首先将nimbus和ui启动),这时应该supervisor是不会退出的(我自己的推断,后面我会进行进一步的测试)。原因是:当意外退出nimbus和supervisor时,如果topology还在继续运行的话,则会在本地仍然保留当前的那些supervisor和worker的相关信息。如果这个时候不关闭topology的话,应该还是可以直接启动supervisor的;如果这个时候关闭了topology的话,这个时候本地还保存有掐面的数据,但是topology已经结束,则无法生成这个新启动的supervisor。


刚才搭建的服务器出现了一个问题,nimbus的主机的nimbus进程停掉了。这就刚好应上了前面的那个场景。当我重新打开nimbus和ui时,发现另外的几台服务器上的supervisor还是正常在跑的,同时topology也在继续运行。因此,我就先不关闭topology,而是直接开启nimbus那台服务器上的supervisor。第一次开启式未成功,第二次成功了。这应该从一定程度上证明我的想法是正确的。如果这个时候要是将topology停掉了,也就没法再启动nimbus机器上的supervisor,只能先将supervisor和workers两个目录删除掉,才能重新启动。


以上是我自己的想法,后面还会再经过实践去进行测试,或者去寻找其他的类似的原因。

展开阅读全文

没有更多推荐了,返回首页