前文（探讨 | 企业级IaaS私有云平台异构资源纳管）提到的物理机异构之外，私有云架构设计中更常见的是虚拟化异构。大型企业内部通常用商业级虚拟化软件承载主要业务系统，非核心业务或者开发测试环境往往部署在开源虚拟化软件之上。此时，讨论虚拟化异构解决方案就显得尤为必要。
虚拟化异构
目前主流的虚拟化软件有几种： VMWare
属于商业虚拟化软件，虚拟化的老大，以功能丰富、性能好、可靠性高著称。 Hyper-v
微软出品的虚拟化软件，自成体系，在公有云和混合云有较大市场，私有云市场影响力较小。 Xen
有开源和商业化两个版本，早期的公有云都是以Xen为虚拟化软件，如Amazon AWS等。 KVM
KVM是一种内核级虚拟化技术，自Linux2.6.20后集成在Linux的各个主要发行版本中。由于Openstack的影响力，KVM的应用越来越广泛。
在KVM和Xen上衍生的各种版本
各主流云计算厂商基于开源的KVM和Xen优化，推出的自己的版本。国内较知名的有华为的fusion系列（基于Xen版，现在还在开发KVM版本）、华3的虚拟化CAS系列等（基于KVM）。此外还有一些中小厂商也在此之列。在此不考虑LXC、virtualbox等。
能否支持X86虚拟化异构、异构的支持深度和广度是衡量一个云资源管理平台（区别与云服务管理平台）的一个重要标准。
与物理机的异构类似，虚拟化软件异构主要的实现思路也是在资源层做统一纳管，用一套接口整合，也即适配器模式，每种虚拟化软件使用一个适配器。在实际开发中，一般接口做二次抽象。
目前在企业级IaaS中最常见的异构是VMWare和KVM（只讨论Openstack纳管，不讨论RHEV等，下同）。以我遇到的客户建设要求和方案竞标计算，几乎所有IaaS平台客户都涉及VMWare虚拟化，40%-50%客户会考虑Openstack，10%-20%会同时要考虑hyper-v的纳管需求。
异构的VMWare和KVM虚拟化实现业界主要有几种途径，归纳如下：
企业级云管理软件
此一大类涵盖范围较广，通常不是纯粹意义上的云资源管理，而会一并包含云管理平台的功能。典型的如VMWare vRealize Suite等，因不是讨论的重点，从略。 Openstack社区版
Openstack社区本身支持KVM较好，而对于VMWare虚拟化的支持并不完善，开源版本中有两种方式：VMWare提供的VCDriver和Citrix提供的ESXDriver。后者已经基本上被废弃了，前者有很多bug、不完善。如果有能力、有合适的团队支撑，可以考虑在VCDriver基础上自行完善。
各企业商业发行版
各大IaaS厂商和VMWare合作，基于社区版Openstack做扩展或复写的版本。如Mirantis、HP HOS商业版等，不尽成熟。处于基本功能可用、但高级功能没有或者有缺陷的状态，同时要付出license费用。在特定情况下可以考虑此种方案。
VIO（VMWare Intergrated Openstack）
VIO是VMWare自己推出的集成Openstack的解决方案，收到业界的广泛期待。很多技术人员向我推荐VIO，我个人对VIO持保留意见，理由有几点：
i. 遗产系统接管
如果对于已有的VMWare虚拟化环境，后部署VIO，其无法接管旧有环境。不知道未来版本是否会改善。
ii. 性能
VIO部署在虚拟机上，作为VCenter插件，性能无法保障。
iii. 高级功能缺失。
VIO本质上还是Openstack标准接口的一种实现，没有HA、DRS等高级功能。同样拭目以待未来版本的改善。
iv. 标准版没有SDN。
如果需要SDN，要集成NSX，成本非常昂贵，集成方式等各方面都需要考虑。
因此，如果不需要高级功能（如SDN，HA、DRS等），可以考虑以VIO方案集成VMWare和KVM。
定制实现方案：
用适配器模式分别实现和调用VCenter（或VSphere）、Openstack的接口。
综合考虑成本、实现难度、功能丰富程度，我推荐使用这种方式。如上述几种方案的优缺点分析，此种方案要考虑高级功能的集成、遗产系统的接管等因素。
和物理机异构的实现架构类似，同样采用两层抽象的方式实现对于虚拟化资源的纳管、分配、调度、监控等管理功能。在第一层接口统一调用对象，第二层接口统一调用参数，具体实践中以Openstack的API参数为主做参数扩充。
实际开发过程中，通过对VCenter（和VSphere）API的调用，可以实现对VMWare虚拟化的资源纳管、分配、调度、监控等主要功能。相应的，通过调用Openstack API集（分别有各个组件提供的API构成），也可以实现Openstack对KVM的管理功能。
对于KVM不具备的VMWare高级功能和遗产接管，则采用同步信息的方式处理。也即通过API调用完成相关的高级功能的设置，在实际的HA或DRS触发时，用扫描或者同步的方式感知到资源变化，并更新资源状态。
采用此种实现需要考虑各种数据及其状态的来源，比如相对固定的配置管理、逻辑关联属性维护在CMDB中，而变化较大的相应数据（如虚机监控数据）直接用API或者独立的监控数据库获取。各数据源之间要划分清楚界限、减少冗余、重复数据。
我在以往的私有云建设实践中，针对异构虚拟化的实现，基本上均采用此种方案。
以上是本人对IaaS平台建设过程中架构设计的一些看法、异构资源统一纳管的解决办法，供大家参考，各位可以结合自身的实际情况加以考虑。
【科技云报道独家首发】
