云管平台中的统一资源层如何设计，如何将资源层设计为资源的统一管理平台？

云管平台的统一资源层并非是资源的直接提供者，而是资源的管控者或者调度者，对上提供API，供服务抽象层调用，对下集成资源的Driver，承上启下，作为云计算技术的具体实现层。统一资源层的设计需要有“平台”的设计理念，资源层能够提供一个资源适配平台，能够适配各类计算资源（异构X86和Power虚拟化、物理机、公有云和容器云），各类网络资源（网络类型：local、Flat、VLAN、VXLAN、GRE；网络机制：LinuxBridge、Openvswitch；网络服务：Router、LoadBalance、Firewall、DHCP等），各类存储资源（LVM，NFS，Ceph，GlusterFS，以及EMC和IBM等商业存储系统），各类软件资源（中间件、工具、数据库和应用等）

“平台”理念：
（1）计算资源
OpenStack作为开放的Infrastracture as a Service云操作系统，支持业界各种优秀的技术，这些技术可能是开源免费的，也可能是商业收费的。 这种开放的架构使得OpenStack 保持技术上的先进性，具有很强的竞争力，同时又不会造成厂商锁定（Lock-in）。那OpenStack 的这种开放性体现在哪里呢？一个重要的方面就是采用基于Driver的平台框架。先来看Nova组件：
计算资源分两块，一块是虚拟化资源，一块是物理资源，虚拟化资源又分直接虚拟化资源和间接虚拟化资源，先说直接虚拟化资源，也就是云管平台资源层直接对接虚拟化资源，但是现在市面上有这么多Hypervisor，资源层的Nova又是如何与他们配合的呢？答案是通过Nova-API调用Nova-compute子组件，Nova-compute子组件为Driver 架构，nova-compute 为这些 Hypervisor 定义了统一的接口，Hypervisor只需要实现这些接口，就可以Driver 的形式即插即用到OpenStack Nova系统中。下面是Nova Driver的架构示意图，这时的Nova-compute存在于物理计算节点中：

再说间接虚拟化资源，云管平台资源层的Nova-compute集成了虚拟化管理平台的Driver，间接通过虚拟化管理平台管理和调度计算资源，如PowerVC、Vcenter和Z/VM就是这样纳入云管平台的。但是这种方式也有一个弊端，虽然通过Driver可以调用虚拟化管理平台的API获得资源信息和进行操作，但是由于不直接跟Hypervisor通信，一些底层的虚拟化操作是无法被云管接管的，特别是一些特性化的功能，另外API也无法提供所有的操作，依旧需要去虚拟化管理平台进行操作，此外，虚拟化管理平台本身也具备一些编排策略和动态优化规则，而云管平台资源层也设计了相应的策略和规则，间接的接管方式需要考虑这些功能是否可以通过API往统一资源层上集成，再往服务抽象层上集成。
最后是物理资源，Nova-API调用资源层的Nova-compute，Nova-compute再调用Ironic的API来实现对物理资源的管理和控制，可以理解为Nova-compute集成了Ironic的Driver，Ironic可以看成一个Hypervisor Driver来给Nova来用。再者Ironic中也集成了许多Baremetal Server的Driver，并提供了插件的机制让二次开发的厂商可以开发一些其他Baremetal Server的Driver嵌入其中。
（2）存储资源
OpenStack的存储组件为Cinder，存储节点支持多种Volume Provider，包括LVM, NFS, Ceph, GlusterFS，以及EMC, IBM等商业存储系统。Cinder-volume为这些Volume Provider定义了统一的 Driver 接口，Volume Provider只需要实现这些接口，就可以Driver的形式即插即用到OpenStack中。下面是Cinder Driver的架构示意图：

（3）网络资源
Neutron的核心组件包括Core Plugin和Service Plugin，Core Plugin负责管理和维护 Neutron的Network, Subnet和Port的状态信息，这些信息是全局的，只需要也只能由一个Core Plugin管理。只使用一个Core Plugin本身没有问题。但问题在于传统的Core Plugin 与Core Plugin Agent是一一对应的。也就是说，如果选择了Linux Bridge Plugin，那么 Linux Bridge Agent将是唯一选择，就必须在OpenStack的所有节点上使用Linux Bridge作为虚拟交换机（即Network Provider）。同样的，如果选择Open Vswitch Plugin，所有节点上只能使用Open Vswitch，而不能使用其他的Network Provider。此外，所有传统的 Core Plugin都需要编写大量重复和类似的数据库访问的代码，大大增加了Plugin开发和维护的工作量。到了OpenStack Havana版本时，实现了一个新的Core Plugin，即ML2，ML2作为新一代的Core Plugin，提供了一个框架，允许在OpenStack网络中同时使用多种Layer 2网络技术，不同的计算节点可以使用不同的网络实现机制。如下图所示，采用ML2 Plugin 后，可以在不同节点上分别部署Linux Bridge Agent, Open Vswitch Agent, Hyper-v Agent 以及其他第三方Agent。 ML2不但支持异构部署方案，同时能够与现有的Agent无缝集成：以前用的Agent不需要变，只需要将Neutron server上的传统Core plugin替换为ML2。 有了ML2，要支持新的Network Provider就变得简单多了：无需从头开发Core Plugin，只需要开发相应的Mechanism Driver，大大减少了要编写和维护的代码。

（4）软件资源
软件也作为一种资源存在于云管的资源层，软件资源的实现有多种方式，一是最简单的镜像模板实现，通过制作安装了特定软件资源的虚拟机，再捕获为镜像模板，存在镜像仓库，部署时克隆一份；二是通过OpenStack HEAT组件实现，OpenStack Heat是一个基于模板来编排复合云应用的服务模板，它的使用简化了复杂基础设施，服务和应用的定义和部署。Heat模板支持丰富的资源类型，实现了对操作系统、应用、中间件、框架和工具等的自动化安装和配置，规范了软件资源的部署。OpenStack Heat提供四种软件资源编排方式：Heat对软件配置和部署的编排；Heat对负载均衡的编排；Heat对资源自动伸缩的编排；Heat和配置管理工具集成。云管平台在设计时，在服务抽象层存放编排的脚本，服务层在进行翻译时，会将编排的脚本加载至资源层的OpenStack Heat组件中，在其他组件完成硬件资源的部署后，OpenStack Heat运行编排脚本，实现软件资源的部署；三是通过容器编排实现，服务层将需求翻译成资源层的API，再通过云管平台的资源层API调度容器云的编排引擎（Docker Swarm、Kubernetes和Mesos），间接实现容器软件资源部署；四是通过OpenStack的特殊组件实现特殊软件服务，如OpenStack的Trove组件可以实现DBaaS，OpenStack的Sahara组件可以实现HadoopaaS等。
综上，在设计云管平台资源层时，要以“平台”的理念去长远规划，保证云管平台资源管理的统一性和可扩展性。