Openstack云操作系统产品概述.docx
《Openstack云操作系统产品概述.docx》由会员分享,可在线阅读,更多相关《Openstack云操作系统产品概述.docx(21页珍藏版)》请在冰豆网上搜索。
Openstack云操作系统产品概述
Openstack云操作系统
产品概述
目录
1产品简介2
2产品特点3
2.1企业云操作系统业务架构3
2.2CloudOS的优化之路6
2.2.1基于Docker的一键自动化部署7
2.2.2兼容多种虚拟化软件8
2.2.3CloudOS纳管VMware8
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服务的统一管理与运维,提高企业运营效率。
企业云操作系统(后面简称CloudOS)应运而生。
深厚的IT基础架构和运维管理支撑经验,专业的IToIP解决方案,融合的从终端到网络到云计算的服务模式,全面的SaaS、PaaS、IaaS层对接能力,使得华三“新IT易之道”的理念一出现就受到了客户的追捧,成就了客户的梦想。
让企业用户更专注于自身的职能和专长,从复杂的传统机房管理中解脱出来,改为享受专业的云服务商提供的服务。
2产品特点
2.1企业云操作系统业务架构
CloudOS云操作系统融入业界先进的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.2CloudOS的优化之路
CloudOS是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兼容多种虚拟化软件
CloudOS支持H3CCAS、VMWare、KVM、PowerVM、Xenserver等多种虚拟化软件,并支持不同种类的虚拟化软件的统一管理。
2.2.3CloudOS纳管VMware
Nova是OpenStack最核心的模块之一,负责计算资源的调度,即VM的生命周期管理,其核心代码已经非常成熟,各厂商对其的优化主要集中在NovaPlugin的优化上,以便更好地适配各种异构虚拟化软件,提供更丰富的功能。
在国内,虚拟化已经广泛部署,云计算才刚刚兴起,保护用户投资,帮助用户从虚拟化平滑过度到云计算,是引导用户接受云计算的关键因素之一,而国内已部署的虚拟化,VMWare占着绝对优势的份额。
因此,如何将OpenStack与VMWare完美结合,在保护用户投资的同时,让用户能够从OpenStack带来的云计算领域的各种新技术中受益,是我们研究和努力的重要方向。
VMWare是OpenStack的黄金会员,OpenStack社区版本中VMWare的Plugin也自然由其贡献和把持。
经过代码分析和实际测试,我们发现原生的VMWarePlugin存在着很多的约束和不足,例如必须绑定NSX、性能较低、支持的版本有限等等,这些严重制约了OpenStack+VMWare方案的实际落地。
CloudOS针对这些问题进行了深入的分析和针对性的攻关,取得了一些成果,分享给大家。
1.必须NSX?
在我们测试OpenStackNova与VMWare对接时,发现能适配的NeutronPlugin只能是NSX。
而我们了解到的现状是,国内部署了VMWare的用户中,很少有用户购买昂贵的NSX,那OpenStack在这些用户怎么落地呢?
为了能适应国内用户普遍没有采购NSX的现状,我们对VMWarePlugin代码做了修改,去掉了对NSX的硬性绑定,改为可以兼容OpenvSwitch。
我们把分布式vSwitch的PortGroup和OpenStack中的Network概念进行映射,用户创建VM的时候,自动把VM连接到对应的PortGroup上,如果需要的PortGroup不存在则创建带有VLANTag的PortGroup。
2.支持OVF格式镜像
原生的VMWarePlugin仅支持原始的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.镜像传输加速
ESXi
ESXi
Nova
ESXi
OpenStack创建虚拟机的时候,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的属性信息后,创新了一种能平滑的将VMWareVM纳管到OpenStack的方案。
vCenter
Openstack
1.根据VMWare中的VM所在的网络信息,在Openstack中创建对应的网络,VLANID保持一致
2.在OpenStack中创建port对象,MAC地址保持与VMWare中VM的MAC地址一致
3.在OpenStack中创建VM对象,UUID保持与VMWare中VM的UUID一致
4.将新创建的VM对象连接到分布式vSwitch
5.将新创建的VM的VNC端口打开,以支持远程访问
方案的核心思想是在OpenStack里增加一个与创建VM过程类似的纳管过程,输入被纳管VM的IP、MAC、CPU和内存规格、操作系