关于cloudstack 个人使用的一些经验记录

        今天主要分享一下基于cloudstack开发的技术以及相关的问题。主要包括以下几个内容：基于CS二次开发的主要形式，如何利用CS的API进行开放，Cloudstack 在虚拟机中部署时常见的一些问题。

        Cloudstack 作为开源平台，我们可以直接基于CS的源码进行二次开发。还有一种是基于CS开放出来的API进行二次开发。我们主要采用API的方式。

Cloudstack API 主要有两个特征，第一是 API 分用户权限，不同的用户使用API的权限不同。对用户主要有 根管理员、域管理员和普通用户级的API，其中根管理员的权限最大，基本所有的API都有使用的权限，域管理员其次，普通用户的最小。第二个特征是 API 分同步 和异步，同步是指对某个API进行调用可以直接返回结果，异步是指调用之后不立刻返回结果，而是返回一个异步任务ID，需要通过这个异步任务ID去查询执行结果，如果异步任务完毕，返回执行结果或者错误信息。

        CSAPI 是基于WEB Service ,可以使用任何一种支持HTTP调用的语言 ，使用Cloudstack API 需要通过CS 管理服务器的认证。CS管理服务器有两种认证方式：一种是 Session 认证。Session 认证是通过登录接口 登录到CS服务器，登录成功后服务器会返回session ID，使用其他API的时候 就带上这个session 去执行。登录接口是不需要sessionkey的。

另一种方式是采用APIKey, 在使用API时带上用户的密钥和API 密钥进行认证。API密钥可以通过CS生成。

基于API的这些特征我们采用API的思路是，采用根管理员的权限及session认证的方式进行使用。我们把所有的API封装成类，所有的参数通过set方法进行或者API执行方法的参数形式进行设置。所有的返回响应都封装成类的对象进行接收。

          基于CS API 具有同步和异步的这些特征，在封装API的时候 我们对同步和异步的执行调用进行区分。BaseCmd 是同步命令调用入口，包含有命令执行方法。AsynCmd 是异步命令调用入口，继承于BaseCmd，包含有异步任务查询方法。对于API的同步的命令都继承于BaseCmd类，异步命令都继承于AsyncCmd。执行的流程是：当需要执行某个同步方法时，调用BaseCmd中的方法，将请求发送到CS服务器，CS服务器按照请求参数中的返回格式返回响应内容。如果是json,在命令中将json串 转成类对象。

对于异步的通过调用AsyncCmd中方法，实际上还是通过BaseCmd中的命令调用将请求发送到CS管理服务器，服务器返回jobid,命令类通过返回的jobid 实施查询任务执行状态。最后将执行结果转成类对象。

       CS提供工程的管理的方式，可以将虚拟机和网络创建在工程下。工程模式可以带来资源管理上的方便，一个工程可以创建一个或多个网络，网络间是隔离的。在工程中，我们可以定义网络的IP段、网关以及网络服务等，然后部署该网络下的实例。例如图中，部署了两个不同10.1.1.0 和10.1.2.0 两个网络，两个网络相互隔离，每个网络都有一个VR提供网络服务。如果需要网络1中需要访问网络2 中虚拟机，需要通过端口转发的形式，走互联网到另外网络。还有就是可以将实例部署到两个或者两个以上的网络中 ，这样这台虚拟机就可以和所在网络中的机器互通。

另外一种比较复杂一点的网络是VPC的网络，它支持多个网络，只需要配置VPC的CIDR，就可以创建VPC网络下的多个网络。VPC的网络个数受全局配置 vpc.max.network 的限制，默认为3个。VPC网络多个网络只有一个VPC的虚拟路由器。与上面不同的是，多个网络内的机器可以设置它的网络访问规则互通。如果外网需要访问该网络下实例的话，也需要通过创建端口转发规则。有一点不一样的是，如果需要给网络分配一个公共IP，然后建立该IP的端口转发规则才能访问。如对需要访问2号段的网络，需要给2号段分配一个IP，然后建立该IP 端口的规则到对应的机器上才能访问。相对比较复杂一点的VPC网络，一个工程下多个VPC网络。两个VPC网络具有不同的CIDR，vpc层间通过建立acl访问规则保持连通。

       CS经常出现的一些虚拟机创建错误。像这种undeplpoy某某主机，一般是部署的资源的问题。要么是计算资源不足，要么是资源不可达。资源不足是指有时在CS的资源使用率超过了设定的阀值时还去部署就会出现这个错误。还有一种情况是计算出的资源充足，还是部署失败。这种情况是部署资源不可达。还有网络资源，像主机所有网络服务都需要由VR提供 ，像这个例子就是网络资源不可用。这里是不能将应用VR DHCP服务。这里的原因可能有两种情况:VR 状态不对，没有运行。还有就是Host不能SSH 连上VR。

还有一种比较常见的错误是由于不能获取网络配置信息。在部署时报虚拟机启动失败，直接原因是VR不能提供网络服务。这种错误在最开始的创建模式并发较多时比较常见，创建模式并发较多出现这种情况实例创建好先于VR，在启动时VR还未启动完毕，导致不能获取网络服务。后来采取创建模式下并发部署数来控制和分配模式来避免这个问题。

这种错误的直接原因与VR有关，但最终原因可能形态各异。在以往实施过程中，有些工程的VR根本就起不来。报的错误如图。定位到CS的一个主存访问不了，XEN的SR出现了问题，导致一系列的工程不可用。

       另外虚拟机的不能执行当前的操作，有可能是上一个操作还未完成就执行另外一个操作命令时就会出现。比如停止一个VR，在停止该VR的过程中，又部署虚拟机到该VR对应到的网络下就会出现这种情况，这也是CS的bug，在4.2版本中仍然有提出这个问题的bug。这种情景我们会有。另外一个是采用未下载完的模板部署实例。部署中比较常出现的问题，有些可以通过采取某种方式避免。但还有些问题还没找到有效地解决方案或者还需要我们进一步对CS或者更一层的XEN进行了解才能去避免或者减少错误的发生。我这里只简单的罗列了一些现象或者问题。比如我们的环境在用了一段时间后就容易出现各种问题，比如上面提到的XEN SR 存储出现问题的原因，如何修复，以及有时CS一个任务在中等待处理的时间比较长。

   格式比较乱