OpenStack调研:OpenStack是什么、版本演变、组件关系(Havana)、同类产品及个人感想 – ZisZ – 推酷

一点调研资料,比较浅,只是觉得部分内容比较有用,记在这里;

首先,关于云计算,要理解什么是SAAS、PAAS、IAAS,这里不述;关于虚拟化,需要知道什么是Hypervisor,这里也不述;

OpenStack是什么

OpenStack是一个由美国宇航局NASA与Rackspace公司共同开发的云计算平台项目,且通过Apache许可证授权开放源码。它可以帮助服务商和企业实现类似于Amazon EC2和S3的云基础架构服务。下面是OpenStack官方给出的定义:

OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources throughout a datacenter, all managed through a dashboard that gives administrators control while empowering their users to provision resources through a web interface.

OpenStack是一个可以管理整个数据中心里大量资源池的云操作系统,包括计算、存储及网络资源。管理员可以通过管理台管理整个系统,并可以通过web接口为用户划定资源。

由以上可以知道OpenStack的主要目标是管理数据中心的资源,简化资源分派。它管理三部分资源,分别是:

    计算资源:OpenStack可以规划并管理大量虚机,从而允许企业或服务提供商按需提供计算资源;开发者可以通过API访问计算资源从而创建云应用,管理员与用户则可以通过web访问这些资源;

    存储资源:OpenStack可以为云服务或云应用提供所需的对象及块存储资源;因对性能及价格有需求,很多组织已经不能满足于传统的企业级存储技术,因此OpenStack可以根据用户需要提供可配置的对象存储或块存储功能;

    网络资源:如今的数据中心存在大量的设置,如服务器、网络设备、存储设备、安全设备,而它们还将被划分成更多的虚拟设备或虚拟网络;这会导致IP地址的数量、路由配置、安全规则将爆炸式增长;传统的网络管理技术无法真正的可高扩展、高自动化地管理下一代网络;因而OpenStack提供了插件式、可扩展、API驱动型的网络及IP管理;

OpenStack的版本演变

OpenStack的每个主版本系列以字母表顺序(A~Z)命名,以年份及当年内的排序做版本号,从第一版的Austin(2010.1)到目前最新的稳定版Havana(2013.2),共经历了8个主版本,第9版的Icehouse仍在开发中。以下是各个版本的简单描述(注:描述摘取自官方文档 https://wiki.openstack.org/wiki/Releases

,当版本描述较多时,仅选取个人认为比较重要(且能看懂)的部分):

Series Status Releases Date
Icehouse Under development Due tbd
Havana Current stable release, security-supported

2013.2

Oct 17, 2013
Grizzly Security-supported

2013.1

Apr 4, 2013

2013.1.1

May 9, 2013

2013.1.2

Jun 6, 2013

2013.1.3

Aug 8, 2013

2013.1.4

Oct 17, 2013
Folsom EOL

2012.2

Sep 27, 2012

2012.2.1

Nov 29, 2012

2012.2.2

Dec 13, 2012

2012.2.3

Jan 31, 2013

2012.2.4

Apr 11, 2013
Essex EOL

2012.1

Apr 5, 2012

2012.1.1

Jun 22, 2012

2012.1.2

Aug 10, 2012

2012.1.3

Oct 12, 2012
Diablo EOL

2011.3

Sep 22, 2011

2011.3.1

Jan 19, 2012
Cactus Deprecated

2011.2

Apr 15, 2011
Bexar Deprecated

2011.1

Feb 3, 2011
Austin Deprecated

2010.1

Oct 21, 2010
  • Austin

    作为第一正式版本的OpenStack,主要包含两子项目,Swift是对象存储模块,Nova是计算模块;

     带有一个简单的控制台,允许用户通过web管理计算和存储;

     带有一个部分实现的Image文件管理模块,未正式发布;

  • Bexar

     正式发布Glance项目,负责Image的注册和分发;

    Swift增加了对大文件(大于5G)的支持;增加了支持S3接口的中间件; 增加了一个认证服务中间件Swauth;

等;

    Nova增加对raw磁盘镜像的支持,增加对微软Hyper-V的支持;等;

     开始了Dashboard控制台的开发;

  • Cactus

    Nova增加新的虚拟化技术支持,如LXC容器、VMWare/vSphere、ESX/ESXi 4.1;支持动态迁移运行中的虚机;增加支持Lefthand/HP SAN做为卷存储的后端;

    Glance提供新的CLI工具以支持直接访问;支持多种不同的Image格式;

  • Diablo

    Nova 整合Keystone认证

;支持KVN的暂停恢复;KVM的块迁移;全局防火墙规则;

    Glance 整合Keystone认证

;增加事件通知机制;

  • Essex

     正式发布Horizon项目,支持开发第三方插件扩展web控制台;正式发布Keystone项目,提供认证服务;

    Swift支持对象过期;在swift CLI接口上支持Auth 2.0 API;支持URL以允许通过控制台向要求认证的swift集群上传对象;

    Nova 完全依赖Keystone

管理用户、项目、角色等;支持根据角色设定访问控制; 计算与网络解耦,使得网络可以通过独立的服务进行管理;卷管理使用了独立api;

为消息队列增加额外的后端模块;元数据分离;支持浮动ip池;

  • Folsom

     正式发布Quantum项目,提供网络管理服务;正式发布Cinder项目,提供块存储服务;

    Nova中libvirt驱动增加支持以LVM为后端的虚机实例;Xen API增加支持动态迁移、块迁移等功能;增加可信计算池功能; 卷管理服务抽离成Cinder;

   

  • Grizzly

    Nova支持将分布于不同地理位置的机器组织成的集群划分为一个cell;支持通过libguestfs直接向guest文件系统中添加文件;通过Glance提供的Image位置URL直接获取Image内容以加速启动;支持无image条件下启动带块设备的实例;支持为虚机实例设置(CPU、磁盘IO、网络带宽)配额;

    Keystone中使用PKI签名令牌代替传统的UUID令牌;

    Quantum中可以根据安全策略对3层和4层的包进行过滤;引入仍在开发中的load balancer服务;

    Cinder中支持光纤通道连接设备;支持LIO做ISCSI的后端;

  • Havana

     正式发布Ceilometer项目

,进行(内部)数据统计,可用于监控报警; 正式发布Heat项目

,让应用开发者通过模板定义基础架构并自动部署; 网络服务Quantum变更为Neutron;

    Nove中支持在使用cell时同一cell中虚机的动态迁移;支持Docker管理的容器;使用Cinder卷时支持加密;增加自然支持GlusterFS(If qemu_allowed_storage_drivers is set to gluster in nova.conf then QEMU is configured to access the volume directly using libgfapi instead of via fuse);

    Glance中按组限制对Image的元属性的访问修改;增加使用RPC-over-HTTP的注册 API;增加支持Sheepdog、Cinder、GridFS做后端存储;

    Neutron中引入一种新的边界网络防火墙服务;可通过VPN服务插件支持IPSec VPN;

    Cinder中支持直接使用裸盘做存储设备无需再创建LVM;新支持的厂商中包含IBM的GPFS;

注:红字部分指出系统添加了新的服务组件,或是新组件出现前的铺垫工作;

OpenStack的架构及组件(Havana)

服务

项目名

描述

控制台 Horizon 用户通过该服务与OpenStack的各服务进行交互,如启动虚机实例、分配IP地址、设置访问控制等;
计算 Nova 按需分派并管理虚机;
网络 Neutron 通常是计算服务通过该服务管理网络设置之间的连接,也可以允许终端用户创建并添加网络接口;通过一个插件式架构支持大量网络广商设备及网络技术;

存储类

对象存储 Swift 存取文件,但并不提供传统挂载式的文件服务;
块存储 Cinder 向虚机提供可用于持久存储的块存储服务;

共用服务

身份服务 Keystone 为OpenStack提供认证及授权服务。
镜像服务 Glance 提供虚机镜像的注册服务;同时计算服务也使用该服务分派实例;
计量/监控服务 Ceilometer 用于计费、基准测试及数据统计等功能

更高层服务

编排组织服务 Heat 使用自带的HOT模板或AWS的CloudFormation模板,通过OpenStack中各服务的REST API,将各组件的资源组织形成云应用;

逻辑架构图如下(注:原图在 这里

,Ceilometer与Heat与服务逻辑无关,因而不在这张图中体现)

Nova

计算服务是OpenStack的核心服务,它由nova-compute模块通过libvirt、XenAPI等管理hypervisor,从而管理虚机,此外它还通过nova-api服务向外提供如EC2兼容、管控功能等的接口,通过nova-scheduler模块提供虚机调研逻辑等;这些模块间的通信全部通过消息队列完成;

Swift

对象存储服务是OpenStack最早期的两个服务之一(另一个是计算服务),在OpenStack平台中,任何的数据都是一个对象;swift-proxy模块对外提供如HTTP(S)、OpenStack Object API及与S3兼容的存取接口。对象的存取经swift-proxy接入后,还需要经三个模块进行定位,即account、container、object;这是因为在OpenStack中一个对象被描述为:某个帐户下某个容器中的某个对象;

Glance

Glance的出现是解决虚机镜像的管理问题;在生成一个镜像后,需要将镜像注册到系统的数据库中;当要实例化一个虚机时,需要将镜像分派到一台具体的实机上用来以启动虚机;因而Glance最重要的接口是镜像的注册和分派;

Cinder

Essex将nove的卷管理api独立化后,Folsom终于将卷管理服务抽离成了Cinder;Cinder管理所有的块存储设备,块设备可以挂接在虚机的实例中,然后虚机里的guest系统可以像操作本地卷一样操作块存储设备;

Cinder需要处理的主要问题应该是接入各种块设备,如本地磁盘、LVM或各大广商提供的设备如EMC、NetApp、HP、HuaWei,还有如Vmware提供的虚拟块设备等。

值得一提的是发现在Cinder的驱动列表中出现了NFS,按理说NFS提供的不是块访问接口,而是文件访问接口,走到文档中看到说明为:NFS based cinder driver. Creates file on NFS share for using it as block device on hypervisor.竟然是用NFS上的文件模拟块设备。为什么不直接写一个将本地文件模拟为块设备的驱动呢?应该是写成NFS驱动,可以将NFS的挂载动作封装在驱动中。

Neutron

经过一定时间的演变,网络管理也抽离成一个独立的服务;在OpenStack的网络管理流程中,通常需要经过以下几个步骤:

1.    创建一个网络;

2.    创建一个子网;

3.    启动一个虚机,将一块网卡对接到指定的网络上;

4.    删除虚机;

5.    删除网络端口;

6.    删除网络;

Keystone

身份服务需要进行认证凭证的验证及关于用户、角色等的信息,及所有相关的元数据;这些数据全都由Keystone服务管理,并提供CRUD的操作方法;另外这些信息可以从另一个认证服务中获取,例如使用LDAP做Keystone的后端。

OpenStack与VM

以上这些服务与服务、服务与虚机的关系如下图所示:

  • 真正服务于VM的服务只有Nova、Glance、Neutron、Cinder:

    • Nova调派资源实例化虚机;
    • Glance提供虚机实例化时需要的镜像;
    • Neutron提供网络连接;
    • Cinder提供外接的块存储服务;
  • Ceilometer从上面与虚机相关的几个服务中收集数据,用于统计、监控、计费、报警等;
  • Swift可以为Glance提供镜像的存储服务,可以为Cinder提供卷的备份服务;
  • Keystone为所有服务提供认证、授权等服务;
  • Horizon为所有服务提供基于Web的操作接口;
  • 通过Heat可以方便地将各组件组织起来;

同类产品

    来自加拿大 CANARIE机构的

DAIR: http://www.canarie.ca/en/dair-program/about

    微软的Azure: http://www.windowsazure.com/zh-cn/

    亚马逊AWS(EC2及配套的S3等): http://aws.amazon.com/

    来自UCSB的Eucalyptus: http://www.eucalyptus.com/

,中文入门资料: http://www.oschina.net/p/eucalyptus

    Google GCE: https://cloud.google.com/products/compute-engine

至于Google的App Engine?应该是PAAS了,不算同类;

———以上是正文———

———以下是个人的一点看(fei)法(hua)———

OpenStack无疑是当前最火的开源IAAS方案,而且已经得到大量厂商的支持,如HP、IBM、Intel、EMC、Huawei,当然还不能忘记Ubuntu系统等,看一下Cinder的api中那一堆的驱动,再看一下Nova不断支持的各类虚拟化技术,不由会去想当年Linux是否也是这样蓬勃发展起来的。个人感觉,厂商积极参与的最终目标肯定还是想捞金,试想如果突然冒出大批公司做OpenStack平台,这必然有大量存储和计算设备可以卖啊$$

2011年我在Intel实习,有幸参与了OpenStack的开发工作,当初使用的D版只有三大模块,因为自己研究方向偏Storage,所以碰过Swift和Glance,又因为有Security背景,所以也在Nova中为Intel TXT打通了上下层接口。研究版本演变时,看到可信计算池功能被F版支持,感觉一点点小成就感,虽然我的代码可能早被refactor了。

两年后再来看H版的OpenStack,子项目已经暴增到9个,对一个新人而言也许难以下手,但如果可以从发展的角度看,会清楚很多,我是这样理解:最初的A版应该是学习AWS的EC2+S3,只抽象出计算与存储两个服务;存储一直是一个比较容易理解的层次,接口明晰,而计算/VM则变数很多,一开始也只能将Image的管理剥离出来,成为Glance;后来,为了产品化,出于安全性及简化使用的需求,洐生了Keystone和Horizon;再后来,E版对Nova进行了大的调整,尽量解耦,从而允许网络和卷管理独立,为后来Neutron和Cinder的出现做了铺垫;再后应该是出于监控和统计的需求,出现了Ceilometer;然后发现过度解耦,提供的选择太多,组织起来比较麻烦,所以做了Heat(我相信,如果OpenStack继续像Linux那样发展下去,将来Heat会变成今天Linux Kernel的menuconfig:)。从这个过程可以看出,大部分的功能,都是慢慢从最核心的计算需求中抽离出来的。

OpenStack的演变过程,也正是一家公司的基础平台发展过程的缩影。区别在于,在公司,基础平台的目标不是产品化,所以很难出现一个Horizon和Heat,而以SLA或PKI为目标时,Ceilometer会变得过分重要,会重要到影响其它组件的发展,比如Nova永远得不到调整,因为调整前,上头就可能要问你:为什么要这样做,能带来什么收益,拿出点数据看看;而这个后果就是,各组件越来越难用越来越难以维护,成为恶性循环。算了,吐槽有点过。废话到此吧,以后有时间我会继续关注OpenStack的发展,看能否得到新的感悟。

来源URL:http://www.tuicool.com/articles/7FZFRj