现有需求

现有一台机器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分配并不清晰，最主要的还是业务理解不透彻导致的，这个因素的引发原因很多，以后需要逐步改善。