Openstack云操作系统产品概述.docx

1、Openstack云操作系统产品概述Openstack云操作系统产品概述目录1 产品简介 22 产品特点 32.1 企业云操作系统业务架构 32.2 Cloud OS的优化之路 62.2.1 基于Docker的一键自动化部署 72.2.2 兼容多种虚拟化软件 82.2.3 CloudOS纳管VMware 82.2.4 丰富的云业务服务 172.2.5 灵活的分权分域管理 252.2.6 可自定义的业务审批流程 282.2.7 计费管理 292.2.8 开放的API接口 301 产品简介信息化技术的飞速发展，使得传统机房管理模式带来的资源瓶颈、信息孤岛、标准不一、系统复杂、灾备昂贵、服务水平低下

2、等诸多矛盾愈发激化，IT的价值已经开始向云模式迁移。越来越多的企业由传统IT服务向云服务转变，并通过云平台实现IT服务的统一管理与运维，提高企业运营效率。企业云操作系统（后面简称Cloud OS）应运而生。深厚的IT基础架构和运维管理支撑经验，专业的IToIP解决方案，融合的从终端到网络到云计算的服务模式，全面的SaaS、PaaS、IaaS层对接能力，使得华三“新IT易之道”的理念一出现就受到了客户的追捧，成就了客户的梦想。让企业用户更专注于自身的职能和专长，从复杂的传统机房管理中解脱出来，改为享受专业的云服务商提供的服务。2 产品特点2.1 企业云操作系统业务架构Cloud OS云操作系统融

3、入业界先进的OpenStack协议框架，基于H3C融合管理架构，提供业界领先的云操作系统， 通过面向客户灵活可扩展的运维架构和运维流程，提供功能完备的云业务服务台，并通过统一门户便于用户通过各种方式接入访问；H3Cloud 云操作系统实现全面的IaaS服务并提供对PaaS、SaaS、DBaaS等业务支撑，通过完备的资源管理和面向应用的自动化编排和服务管理能力，全面支撑云业务运维。OpenStack是一个开源的云计算平台，经过6年的飞速发展，OpenStack已经从一众竞争对手之中脱颖而出，成为云计算平台的事实标准。随着2015年4月Kilo版本的发布，OpenStack社区宣布OpenStac

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

5、存储方案、网络设备、业务需求、管理规模的差异，会形成一个个完全不同的OpenStack部署方案。然后我们再来看一下OpenStack社区权力核心的组成： 董事会：共24席，其中白金董事8席，白金会员每家一席；黄金董事8席，从黄金会员中选举；独立董事8席，在个人会员中选举 技术委员会：一共13人，由活跃的技术贡献者选举 用户委员会：代表大众用户看起来是比较中立和公平，但实际的控制权还是把持在董事会手中，还是会体现某些厂商的意志。比如VMWare的OpenStack插件是由VMWare贡献的，VMWare就可以控制不提供某些功能，也能把持他人提交的改进意见是否被社区采纳。接着我们再看一下OpenS

6、tack核心玩家：包括HP、Redhat、IBM、SUSE、Mirantis等都提供了各自的OpenStack发行版，这些发行版与社区版有什么差异呢，意义何在呢？显然大家都意识到了原生OpenStack在易用性、性能、稳定性、功能等方面的不足，无法直接拿来用于生产环境。因此结合自己的技术优势以及对市场需求的把握，从不同角度对原生OpenStack进行了各种优化，来满足各自领域用户的需求。总结：OpenStack是一个由开源社区众多开发者维护的开源产品，在易用性、性能、稳定性等方面与生产环境的要求还有或多或少的差距，一些特定的用户需求还无法满足。因此，OpenStack在用于生产环境之前，还需要

7、在以下方面进行不断的优化和改进： 部署复杂 Horizon界面过于简单，易用性差 对不同虚拟化平台的支持参差不齐 L3、FW、LB等网络服务性能和稳定性较差 缺少必要的运营、运维特性（组织结构、计费、审批、审计）2.2 Cloud OS的优化之路Cloud OS是H3C基于OpenStack，并结合自己在网络、虚拟化、存储、运维等方面的深入理解和深厚技术积累，对OpenStack进行了大量优化改进后打造的云计算平台。2.2.1 基于Docker的一键自动化部署原生Openstack的安装部署非常复杂，需要手工通过命令行一步一步进行操作，安装过程中需要能连接Internet来不断下载各种组件包，

8、期间还要手工修改很多配置文件。一个对Linux较为熟悉的技术人员，第一次安装Openstack，也经常需要花费23天时间。企业云操作系统对Openstack进行了重新打包，将其纳入到企业云操作系统的统一安装框架中，实现基于Docker容器的自动化的安装部署，对用户屏蔽了Openstack安装的复杂性，整个企业云操作系统，包括Openstack在内，整体可以在1小时内部署完成。同时，CloudOS在业界首推基于Docker微服务的方式部署企业云操作系统。一个模块即一个微服务，运行在一个Docker中，模块间不互相印象。如果某一个微服务发生问题，只需要重启运行于这个服务的Docker即可。同时，在

9、版本升级时，也可以对模块进行单独升级。微服务的引入，大幅提高了云平台的稳定性和可维护性。2.2.2 兼容多种虚拟化软件Cloud OS支持H3C CAS、VMWare、KVM、Power VM、Xenserver等多种虚拟化软件，并支持不同种类的虚拟化软件的统一管理。2.2.3 CloudOS纳管VMwareNova是OpenStack最核心的模块之一，负责计算资源的调度，即VM的生命周期管理，其核心代码已经非常成熟，各厂商对其的优化主要集中在Nova Plugin的优化上，以便更好地适配各种异构虚拟化软件，提供更丰富的功能。在国内，虚拟化已经广泛部署，云计算才刚刚兴起，保护用户投资，帮助用户

10、从虚拟化平滑过度到云计算，是引导用户接受云计算的关键因素之一，而国内已部署的虚拟化，VMWare占着绝对优势的份额。因此，如何将OpenStack与VMWare完美结合，在保护用户投资的同时，让用户能够从OpenStack带来的云计算领域的各种新技术中受益，是我们研究和努力的重要方向。VMWare是OpenStack的黄金会员，OpenStack社区版本中VMWare的Plugin也自然由其贡献和把持。经过代码分析和实际测试，我们发现原生的VMWare Plugin存在着很多的约束和不足，例如必须绑定NSX、性能较低、支持的版本有限等等，这些严重制约了OpenStack+VMWare方案的实际

11、落地。Cloud OS针对这些问题进行了深入的分析和针对性的攻关，取得了一些成果，分享给大家。1. 必须NSX？在我们测试OpenStack Nova与VMWare对接时，发现能适配的Neutron Plugin只能是NSX。而我们了解到的现状是，国内部署了VMWare的用户中，很少有用户购买昂贵的NSX，那OpenStack在这些用户怎么落地呢？为了能适应国内用户普遍没有采购NSX的现状，我们对VMWare Plugin代码做了修改，去掉了对NSX的硬性绑定，改为可以兼容Open vSwitch。我们把分布式vSwitch的Port Group和OpenStack中的Network概念进行映

12、射，用户创建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存储镜像是由glanc

13、e模块服务负责，它的文件系统不会是VMware公司特有的vmdk文件系统。云管理员需要把vmdk文件拷贝到非vmdk文件系统，然后上传到glance镜像服务，这样传送到glance上必然是一个50G的大文件，这对空间和时间，都是巨大的浪费。而ovf格式是一种压缩优化格式，压缩后的大小比5G还要小。但Openstack不支持OVF格式。因此我们修改openstack的代码，加入了对OVF格式镜像的支持。改造后镜像在glance中占用的空间缩小为原来的120，Nova下载镜像到ESXi上花费的时间也缩小为原来的120，在空间和时间效率上都得到了极大的提升。3. 镜像传输加速ESXiESXiNova

14、ESXiOpenStack创建虚拟机的时候，nova-compute会从glance获取镜像，并且把镜像传送到vCenter，再由vCenter下发到ESXi。使用这种方式创建VM涉及到镜像文件的多次传输，速度会很慢，5G左右的镜像需要1个多小时才能完成VM创建。我们对这种机制进行了优化，让nova-compute直接去操作vCenter管理的ESXi，跳过了Nova和vCenter之前的传输过程，第一次下发镜像的时间减少至20分钟左右，然后ESXi会缓存该镜像，后续基于此镜像创建VM将非常快捷。这其中涉及到与vCenter的复杂交互，例如需要从vCenter获取ESXi主机的认证信息，然后利

15、用认证信息直接连接ESXi。4. VMWare纳管如何帮助用户从虚拟化平滑过度到云计算？用户原有的VMWare环境中已部署的、正在运行业务的VM如何纳入到Openstack中统一进行管理？能不中断业务吗？业界的普遍方案是进行v2v迁移操作：这种方式有几个弊端：1、 操作复杂2、 镜像文件需要进行多次传输，非常耗时3、 会产生大量镜像4、 业务会中断我们在仔细分析了OpenStack的VM创建流程，并对比了OpenStack的VM属性信息和vCenter中VM的属性信息后，创新了一种能平滑的将VMWare VM纳管到OpenStack的方案。vCenterOpenstack1.根据VMWare中的VM所在的网络信息，在Openstack中创建对应的网络，VLAN ID保持一致2.在OpenStack中创建port对象，MAC地址保持与VMWare中VM的MAC地址一致3.在OpenStack中创建VM对象，UUID保持与VMWare中VM的UUID一致4.将新创建的VM对象连接到分布式vSwitch5.将新创建的VM的VNC端口打开，以支持远程访问方案的核心思想是在OpenStack里增加一个与创建VM过程类似的纳管过程，输入被纳管VM的IP、MAC、CPU和内存规格、操作系