说明:本文主要罗列一些关于cloudstack中agent和agentAttach的运行逻辑,所写不一定正确且还有很多细节待完善,只是作为这几天梳理这一块的一个中间成果记录在案,后续会不断完善。
问题描述
前几天在197环境下测试的时候发现KVM的两台主机状态都变为Alert,并且使用强制重新连接功能直接报"Failed to reconnect host"错误
问题排查
关于强制重新连接报“Failed to reconnect host”是因为以下代码
AgentAttache attache = findAttache(hostId);
根据主机ID拿到的attache为Null。
那attache是个什么东西呢,这里就涉及到CS(CloudStack,下文如无特别说明都简写为CS)怎样跟主机来通讯
CS 跟每一个主机(包括系统虚拟机)通讯都要通过在对应的主机上安装运行相应的Agent(代理)来进行,而AgentAttach就是CS中与该主机Agent对应的
如果你登录到ssvm和cpvm上会发现有一个JAVA进程(登录ssvm的方式为先ssh到所在的主机,然后运行命令
ssh -i /root/.ssh/id_rsa.cloud -p 3922 root@xxxx xxxx为ssvm在CS中的本地链接IP 地址)
稍微分析一下这个JAVA进程我们发现它的main方法所在的类为com.cloud.agent.AgentShell
(对我来说这算是一个重大的发现,这样我们对ssvm的这个JAVA进程就非常清晰了)。
接着分析AgentShell的启动过程发现它主要是利用JAVA的NIO作为一个Client来跟CS的管理节点进行通讯,
连接的端口从上图也可以看出是8250正好是管理节点的CS监听的一个端口。
关于AgentShell的启动和运行逻辑以及NIO的原理可以用一整篇文章来讲解,这里就不详细展开(后续有时间会补上)。
接下来我们来看看KVM主机上的情况:通过ps aux|grep java命令同样会发现有JAVA进程在运行
(此时172.16.65.135上有两个启动命令一样的JAVA进程,这应该是属于异常情况)
关于这个进程的更进一步的理解还没有来得及梳理,不过在该主机上也发现了非常重要的信息,那就是主机的运行日志
日志目录位于/var/log/cloudstack/agent,主要的日志文件包括
特别是对agent.log和cloudstack-agent.err这两个文件的分析发现了很多重要的日志信息,进一步的分析后续展开。
以上主要Agent的部分
接下来我们梳理一下CS的管理节点关于AgentAttach的内容
我们知道在管理节点中有一个AgentManagerImpl对象(更准确的说是ClusteredAgentManagerImpl)
该对象持有一个ConcurrentHashMap<Long, AgentAttache> _agents,就是主机ID和对应的attach的Map
回忆一下文章开头findAttach(hostId)返回Null,其实就是去这个Map里面拿数据
其实AgentManagerImpl还持有一个protected NioServer _connection;
这个NioServer就是利用NIO作为服务端跟上面说的Client通讯的