KVM agent的Ansible的配置文件如图所示：
配置文件和KVM agent的Python包都包含在Java WAR文件中，在用户调用API添加一个计算节点时，ZStack会自动找到对应的配置文件并调用Ansible去部署agent，用户甚至都不知道这个过程的存在。此外，对于高级用户，可以通过扩展Ansible配置文件来实现运维过程中的系统维护和升级。例如为了升级KVM机器的某个安装包修复一个安全漏洞，用户只需要在KVM的配置文件中加上相关内容，再调用ZStack的ReconnectHost API，就可以自动实现升级功能。 在监控方面，ZStack目前提供对关键的系统资源比如物理机，虚拟机的状态进行监控，任何在ZStack控制外的状态变化，例如虚拟机的意外宕机，都会在一定的时间内被检测到并同步到数据库。此外ZStack还通过Java的JMX协议对外暴露监控自身的接口，例如监控当前系统运行的任务，系统正在处理的消息，消息的平均处理时间和最大处理时间等。让用户可以实时了解系统动态。 丰富的查询API是ZStack为用户运维提供的一个重要功能。ZStack的查询API提供超过400万单项查询条件，400万阶乘的组合查询条件。用户在API层面就可以完成数据库级别的资源查询。查询API带来的意义是可以打造真正企业级的UI。在优秀的企业软件中，例如微软outlook，JIRA中，用户都可以根据自己的需求创建不同的视图。在IaaS中也有同样的需求。用户可能需要视图显示所有在同一三级网络中的虚拟机，显示所有内存容量低于2G的物理服务器等。在没有完善的查询API支持下，UI就只能提供几个默认视图，而无法允许用户自定义视图。
ZStack的查询API的一个独特之处在于，查询框架在接收到API后可以自动生成SQL语句，无需编写代码。开发人员只要在数据库中定义了表，然后在Java程序中用annotation描述新表与其它表之间的foreign key，再为新表继承一个查询API的基础类，所有工作就完成了。用户使用新API时，查询框架可以自动感知，根据用户的查询条件生成单表SQL以及多表Join的SQL语句。 稳定性IaaS软件本身是个集成项目，管理了数据中心中大量的子系统，它实际上管理着所有子系统和所有设备的状态。加之IaaS中每一个任务的执行路径非常长，例如创建一个虚拟机就涉及到计算节点，网络节点，存储节点状态的变化，其中任何一个步骤都可能出错。一旦错误发生，由于当前IaaS缺乏回退机制，某些子系统会遗留在中间状态。比如一个虚拟机最后创建失败了，但它的DHCP信息却可能遗留在网络节点，导致将来可能的DHCP冲突。为此，ZStack设计了一个workflow引擎，将任务的每个操作都封装到flow中，一旦某个操作出错，workflow引擎会回退(rollback)所以已经执行的flow，保证不会系统遗留在中间状态。
例如在上图的创建虚拟机workflow中，假设任务在VmCreateOnHypervisorFlow这一步失败了，workflow引擎会回退前面已执行的6个flow，包括子workflow（图中计算节点分配workflow，创建网络节点虚拟机的workflow）。例如删除已创建的网络节点虚拟机，删除已创建的虚拟磁盘，归还已分配的计算资源到计算节点等。最大程度保证系统状态的完整性。 除了可以回退外，workflow引擎还可以允许开发人员通过XML文件来配置关键任务。例如在上图中，创建虚拟机的workflow包含一个创建网络节点虚拟机的子workflow（Creating Appliance VM sub-workflow）。这个子workflow跟创建用户虚拟机的workflow类似，只有分配网卡这个flow不同。ZStack通过配置XML文件替换掉该条flow（图中绿色部分），就实现了创建网络节点虚拟机的逻辑。这种通过XML文件配置workflow的方式被大量运用，例如计算节点分配器(host allocator)，存储分配器(storage allocator)，IP地址分配器(IP allocator)都是通过这种方式实现的。开发人员甚至不用写新代码，只需重新组合一些flow的顺序就可以实现新的业务逻辑。例如计算节点分配器里的一些实现，就是通过组合已有的flow实现的。这种方式使ZStack的组件复用度非常高，帮助整个架构实现了松耦合。 |
