Openstack云操作系统产品概述目录1产品简介 (2)2产品特点 (3)2.1企业云操作系统业务架构 (3)2.2 Cloud OS的优化之路 (6)2.2.1基于Docker的一键自动化部署 (7)2.2.2兼容多种虚拟化软件 (8)2.2.3 CloudOS纳管VMware (8)2.2.4丰富的云业务服务 (17)2.2.5灵活的分权分域管理 (25)2.2.6可自定义的业务审批流程 (28)2.2.7计费管理 (29)2.2.8开放的API接口 (30)1 产品简介信息化技术的飞速发展，使得传统机房管理模式带来的资源瓶颈、信息孤岛、标准不一、系统复杂、灾备昂贵、服务水平低下等诸多矛盾愈发激化，IT的价值已经开始向云模式迁移。

越来越多的企业由传统IT服务向云服务转变，并通过云平台实现IT服务的统一管理与运维，提高企业运营效率。

企业云操作系统（后面简称Cloud OS）应运而生。

深厚的IT基础架构和运维管理支撑经验，专业的IToIP解决方案，融合的从终端到网络到云计算的服务模式，全面的SaaS、PaaS、IaaS层对接能力，使得华三“新IT易之道”的理念一出现就受到了客户的追捧，成就了客户的梦想。

让企业用户更专注于自身的职能和专长，从复杂的传统机房管理中解脱出来，改为享受专业的云服务商提供的服务。

2 产品特点2.1 企业云操作系统业务架构Cloud OS云操作系统融入业界先进的OpenStack协议框架，基于H3C融合管理架构，提供业界领先的云操作系统，通过面向客户灵活可扩展的运维架构和运维流程，提供功能完备的云业务服务台，并通过统一门户便于用户通过各种方式接入访问；H3Cloud 云操作系统实现全面的IaaS服务并提供对PaaS、SaaS、DBaaS等业务支撑，通过完备的资源管理和面向应用的自动化编排和服务管理能力，全面支撑云业务运维。

OpenStack是一个开源的云计算平台，经过6年的飞速发展，OpenStack已经从一众竞争对手之中脱颖而出，成为云计算平台的事实标准。

随着2015年4月Kilo版本的发布，OpenStack社区宣布OpenStack已经达到了满足生产环境使用的质量标准。

但事实是否真的如此呢？我们首先来看一下OpenStack的架构：⏹OpenStack是一种模块化的架构，各模块提供不同的服务，分工明确，界限清晰，可根据用户的需求不同而进行灵活组合；⏹OpenStack各模块之间通过统一的REST风格的API调用以及AMQP消息队列，实现模块间的松耦合；⏹OpenStack定义的是框架、接口以及业务抽象，并不实现具体的计算、存储、网络功能，这些功能由第三方实现，并通过Plugin方式集成到系统中；OpenStack这种架构是一柄双刃剑，在带来灵活性、扩展性、兼容性的同时，也必然带来不确定性和复杂性。

用户使用的虚拟化系统、存储方案、网络设备、业务需求、管理规模的差异，会形成一个个完全不同的OpenStack部署方案。

然后我们再来看一下OpenStack社区权力核心的组成：⏹董事会：共24席，其中白金董事8席，白金会员每家一席；黄金董事8席，从黄金会员中选举；独立董事8席，在个人会员中选举⏹技术委员会：一共13人，由活跃的技术贡献者选举⏹用户委员会：代表大众用户看起来是比较中立和公平，但实际的控制权还是把持在董事会手中，还是会体现某些厂商的意志。

比如VMWare的OpenStack插件是由VMWare贡献的，VMWare就可以控制不提供某些功能，也能把持他人提交的改进意见是否被社区采纳。

接着我们再看一下OpenStack核心玩家：包括HP、Redhat、IBM、SUSE、Mirantis等都提供了各自的OpenStack发行版，这些发行版与社区版有什么差异呢，意义何在呢？显然大家都意识到了原生OpenStack在易用性、性能、稳定性、功能等方面的不足，无法直接拿来用于生产环境。

因此结合自己的技术优势以及对市场需求的把握，从不同角度对原生OpenStack进行了各种优化，来满足各自领域用户的需求。

总结：OpenStack是一个由开源社区众多开发者维护的开源产品，在易用性、性能、稳定性等方面与生产环境的要求还有或多或少的差距，一些特定的用户需求还无法满足。

因此，OpenStack在用于生产环境之前，还需要在以下方面进行不断的优化和改进：⏹部署复杂⏹Horizon界面过于简单，易用性差⏹对不同虚拟化平台的支持参差不齐⏹L3、FW、LB等网络服务性能和稳定性较差⏹缺少必要的运营、运维特性（组织结构、计费、审批、审计…）2.2 Cloud OS的优化之路Cloud OS是H3C基于OpenStack，并结合自己在网络、虚拟化、存储、运维等方面的深入理解和深厚技术积累，对OpenStack进行了大量优化改进后打造的云计算平台。

2.2.1 基于Docker的一键自动化部署原生Openstack的安装部署非常复杂，需要手工通过命令行一步一步进行操作，安装过程中需要能连接Internet来不断下载各种组件包，期间还要手工修改很多配置文件。

一个对Linux较为熟悉的技术人员，第一次安装Openstack，也经常需要花费2~3天时间。

企业云操作系统对Openstack进行了重新打包，将其纳入到企业云操作系统的统一安装框架中，实现基于Docker容器的自动化的安装部署，对用户屏蔽了Openstack安装的复杂性，整个企业云操作系统，包括Openstack在内，整体可以在1小时内部署完成。

同时，CloudOS在业界首推基于Docker微服务的方式部署企业云操作系统。

一个模块即一个微服务，运行在一个Docker中，模块间不互相印象。

如果某一个微服务发生问题，只需要重启运行于这个服务的Docker即可。

同时，在版本升级时，也可以对模块进行单独升级。

微服务的引入，大幅提高了云平台的稳定性和可维护性。

2.2.2 兼容多种虚拟化软件Cloud OS支持H3C CAS、VMWare、KVM、Power VM、Xenserver等多种虚拟化软件，并支持不同种类的虚拟化软件的统一管理。

2.2.3 CloudOS纳管VMwareNova是OpenStack最核心的模块之一，负责计算资源的调度，即VM的生命周期管理，其核心代码已经非常成熟，各厂商对其的优化主要集中在Nova Plugin的优化上，以便更好地适配各种异构虚拟化软件，提供更丰富的功能。

在国内，虚拟化已经广泛部署，云计算才刚刚兴起，保护用户投资，帮助用户从虚拟化平滑过度到云计算，是引导用户接受云计算的关键因素之一，而国内已部署的虚拟化，VMWare占着绝对优势的份额。

因此，如何将OpenStack与VMWare完美结合，在保护用户投资的同时，让用户能够从OpenStack带来的云计算领域的各种新技术中受益，是我们研究和努力的重要方向。

VMWare是OpenStack的黄金会员，OpenStack社区版本中VMWare的Plugin也自然由其贡献和把持。

经过代码分析和实际测试，我们发现原生的VMWare Plugin存在着很多的约束和不足，例如必须绑定NSX、性能较低、支持的版本有限等等，这些严重制约了OpenStack+VMWare方案的实际落地。

Cloud OS针对这些问题进行了深入的分析和针对性的攻关，取得了一些成果，分享给大家。

1. 必须NSX？在我们测试OpenStack Nova与VMWare对接时，发现能适配的Neutron Plugin 只能是NSX。

而我们了解到的现状是，国内部署了VMWare的用户中，很少有用户购买昂贵的NSX，那OpenStack在这些用户怎么落地呢？为了能适应国内用户普遍没有采购NSX的现状，我们对VMWare Plugin代码做了修改，去掉了对NSX的硬性绑定，改为可以兼容Open vSwitch。

我们把分布式vSwitch的Port Group和OpenStack中的Network概念进行映射，用户创建VM的时候，自动把VM连接到对应的Port Group上，如果需要的Port Group不存在则创建带有VLAN Tag的Port Group。

2. 支持OVF格式镜像原生的VMWare Plugin仅支持原始的vmdk文件做为镜像。

这种原始的vmdk文件，一旦脱离ESXi的vmdk文件系统，就会丧失压缩的特性，例如一个虚拟机硬盘50G，实际使用了5G，如果使用的是瘦模式，那么硬盘文件在ESXi中它占用的空间是5G。

这种硬盘文件一旦拷贝到Linux的EXT3文件系统或者Window的FAT32等格式文件系统上就变成真的占用50G磁盘空间了。

而openstack存储镜像是由glance模块服务负责，它的文件系统不会是VMware公司特有的vmdk文件系统。

云管理员需要把vmdk文件拷贝到非vmdk文件系统，然后上传到glance镜像服务，这样传送到glance上必然是一个50G的大文件，这对空间和时间，都是巨大的浪费。

而ovf格式是一种压缩优化格式，压缩后的大小比5G还要小。

但Openstack不支持OVF格式。

因此我们修改openstack的代码，加入了对OVF格式镜像的支持。

改造后镜像在glance中占用的空间缩小为原来的1／20，Nova下载镜像到ESXi上花费的时间也缩小为原来的1／20，在空间和时间效率上都得到了极大的提升。

3. 镜像传输加速EEEOpenStack创建虚拟机的时候，nova-compute会从glance获取镜像，并且把镜像传送到vCenter，再由vCenter下发到ESXi。

使用这种方式创建VM涉及到镜像文件的多次传输，速度会很慢，5G左右的镜像需要1个多小时才能完成VM创建。

我们对这种机制进行了优化，让nova-compute直接去操作vCenter管理的ESXi，跳过了Nova和vCenter之前的传输过程，第一次下发镜像的时间减少至20分钟左右，然后ESXi会缓存该镜像，后续基于此镜像创建VM将非常快捷。

这其中涉及到与vCenter的复杂交互，例如需要从vCenter获取ESXi主机的认证信息，然后利用认证信息直接连接ESXi。

4. VMWare纳管如何帮助用户从虚拟化平滑过度到云计算？用户原有的VMWare环境中已部署的、正在运行业务的VM如何纳入到Openstack中统一进行管理？能不中断业务吗？业界的普遍方案是进行v2v迁移操作：这种方式有几个弊端：1、操作复杂2、镜像文件需要进行多次传输，非常耗时3、会产生大量镜像4、业务会中断我们在仔细分析了OpenStack的VM创建流程，并对比了OpenStack的VM属性信息和vCenter中VM的属性信息后，创新了一种能平滑的将VMWare VM纳管到OpenStack的方案。