现有需求
现有一台机器172.50.3.241,由于本地项目过多,导致硬件相关资源缺乏,需要在现有机器的基础上增加一台物理机172.50.3.242,172.50.3.241已安装mesos,只需在172.50.3.242中安装mesos,来缓和172.50.3.241对项目资源的管理。
引发问题
当在172.50.3.241/242中分别启动mesos对应的主节点和从节点一段时间后,172.50.3.241从节点自动挂掉,且在marathon中不能正常部署项目,mesos的agents中也不能正常显示mesos的节点部署情况(不能正常显示172.50.3.241和172.50.3.242节点信息),在172.50.3.241从节点的打印日志(部分)如下:
EXIT with status 1: Re-registered but got wrong id
E0507 11:56:19.636994 634949 slave.cpp:1273] EXIT with status 1: Re-registered but got wrong id: 10566f8d-583c-41ac-9f5c-202a3bcc16cb-S0
(expected: d82fe21a-3c67-45dc-9e34-75bc95a42c88-S2). Committing suicide
当发现此问题后,首先通过“d82fe21a-3c67-45dc-9e34-75bc95a42c88-S2”在mesos中找到了相关部署的项目,然后在marathon中依次destroy下述对应的项目(这里个人理解的是磁盘中的垃圾文件并没有真正删除),最终重启两台机器的mesos,但是还是复现上述问题。
物理机硬件资源配置
172.50.3.241
[root@172 ~]# cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
[root@172 ~]# uname -r
3.10.0-693.el7.x86_64
[root@172 ~]# cat /proc/meminfo
MemTotal: 16149900 kB
[root@172 ~]# df -hl
350GB
172.50.3.242
[root@localhost ~]# cat /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)
[root@localhost ~]# uname -r
3.10.0-862.el7.x86_64
[root@localhost ~]# cat /proc/meminfo
MemTotal: 7960072 kB
[root@localhost ~]# df -hl
870GB
相关软件版本
mesos1.4.1
marathon1.6.322
openjdk version "1.8.0_161"(通过mesos安装mesos步骤一起安装)
zookeeper3.4.11
集群设计
为模拟生产环境mesos配置,现在本地测试机中简要配置如下:
在172.50.3.241中,mesos依然为主从配置,marathon依然为单节点配置,zookeeper为单节点配置。
在172.50.3.242中,mesos同样为主从配置。
启动相关命令
172.50.3.241启动mesos的主节点:
/usr/local/sbin/mesos-master --zk=zk://172.50.3.241:9181/mesos --port=5050 --log_dir=/var/log/mesos --hostname=172.50.3.241 --hostname_lookup=false --ip=172.50.3.241 --quorum=1 --registry=replicated_log --work_dir=/var/lib/mesos/master --cluster=mesos &
172.50.3.241启动mesos的从节点:
/usr/local/sbin/mesos-slave --master=zk://172.50.3.241:9181/mesos --work_dir=/var/lib/mesos/agent --hostname=172.50.3.241 --log_dir=/var/log/agent --ip=172.50.3.241 &
172.50.3.241启动marathon(必须在此机器中先启动mesos的主从)
MESOS_NATIVE_JAVA_LIBRARY=/usr/local/lib/libmesos.so nohup /opt/marathon/marathon-1.6.322-2bf46b341/bin/marathon --master zk://172.50.3.241:9181/mesos --zk zk://172.50.3.241:9181/marathon >/opt/marathon/marathon-1.6.322-2bf46b341/marathonlog &
172.50.3.242启动mesos的主节点:
/usr/local/sbin/mesos-master --zk=zk://172.50.3.241:9181/mesos --port=5050 --log_dir=/home/application/data/mesos/log/mesos --hostname=172.50.3.242 --hostname_lookup=false --ip=172.50.3.242 --quorum=1 --registry=replicated_log --work_dir=/home/application/data/mesos/lib/mesos/master --cluster=mesos &
172.50.3.242启动mesos的从节点:
/usr/local/sbin/mesos-slave --master=zk://172.50.3.241:9181/mesos --work_dir=/home/application/data/mesos/lib/mesos/agent --hostname=172.50.3.242 --hostname_lookup=false --log_dir=/home/application/data/mesos/log/agent --ip=172.50.3.242 &
解决方案
在172.50.3.241和172.50.3.242中启动各自mesos对应主从的命令中,都有各自的工作目录属性work_dir,在停止上述物理机的所有mesos和marathon服务后,删除work_dir中的所有内容,比如删除172.50.3.241的mesos中”/var/lib/mesos/master”和”/var/lib/mesos/agent”的内容以及删除172.50.3.242的mesos中”/home/application/data/mesos/lib/mesos/master”和”/home/application/data/mesos/lib/mesos/agent”的内容。之后重启对应的mesos和marathon即可(这里最好找到问题中ID对应的项目,只删除问题ID对应的项目即可。由于这里是测试机,在生产中绝对不能这么干,一定要合理规划硬件资源和业务系统,如果这么干了,那么肯定是治标不治本,不仅浪费公司人力物力资源,也耽误了线上业务的发展)。
后续
针对此问题,个人推测如下几点引发的问题和以后的处理方式:
第一,在现有问题发生之前,172.50.3.241和172.50.3.242已经部署了跟现有解决方案相同的mesos等配置,由于172.50.3.242测试机硬件资源不足,并没有人为合理规划和使用字段,导致172.50.3.242的mesos不能正常部署等功能,于是人为的重装操作系统,导致现在重复的劳动和本地应用的重新部署,浪费时间很严重,以后需要合理规划硬件资源,避免过多的浪费。
第二,在引发的此问题中,不仅仅是由于硬件资源分配不合理导致的,在业务的规划中,并没有合理制定哪些业务及模块应部署到相应的节点,并没有充分的预估业务和硬件资源的关联和使用情况,比如在此问题日志中mesos的管理的应用程序的ID分配并不清晰,最主要的还是业务理解不透彻导致的,这个因素的引发原因很多,以后需要逐步改善。
标题:mesos增加节点扩展集群引发的问题(本地测试环境)
作者:yazong
地址:https://blog.llyweb.com/articles/2019/05/07/1578151187951.html