一点调研资料,比较浅,只是觉得部分内容比较有用,记在这里;
首先,关于云计算,要理解什么是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的发展,看能否得到新的感悟。