CloudStack中关于Agent和AgentAttach梳理的一些思路

说明：本文主要罗列一些关于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通讯的

转载于:https://my.oschina.net/abelgroup/blog/849680