柔中带刚，刚中带柔，淫荡中富含柔和，刚猛中荡漾风骚，无坚不摧，无孔不入！
全部博文（1669）
分类： 云计算
2014-05-28 00:59:46
一点调研资料，比较浅，只是觉得部分内容比较有用，记在这里；
首先，关于云计算，要理解什么是SAAS、PAAS、IAAS，这里不述；关于虚拟化，需要知道什么是Hypervisor，这里也不述；
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的每个主版本系列以字母表顺序（A~Z）命名，以年份及当年内的排序做版本号，从第一版的Austin（2010.1）到目前最新的稳定版Havana（2013.2），共经历了8个主版本，第9版的Icehouse仍在开发中。以下是各个版本的简单描述（注：描述摘取自官方文档 ，当版本描述较多时，仅选取个人认为比较重要（且能看懂）的部分）：
| Series | Status | Releases | Date |
| Icehouse | Under development | Due | tbd |
| Havana | Current stable release, security-supported | Oct 17, 2013 | |
| Grizzly | Security-supported | Apr 4, 2013 | |
| May 9, 2013 | |||
| Jun 6, 2013 | |||
| Aug 8, 2013 | |||
| Oct 17, 2013 | |||
| Folsom | EOL | Sep 27, 2012 | |
| Nov 29, 2012 | |||
| Dec 13, 2012 | |||
| Jan 31, 2013 | |||
| Apr 11, 2013 | |||
| Essex | EOL | Apr 5, 2012 | |
| Jun 22, 2012 | |||
| Aug 10, 2012 | |||
| Oct 12, 2012 | |||
| Diablo | EOL | Sep 22, 2011 | |
| Jan 19, 2012 | |||
| Cactus | Deprecated | Apr 15, 2011 | |
| Bexar | Deprecated | Feb 3, 2011 | |
| Austin | Deprecated | Oct 21, 2010 |
? 作为第一正式版本的OpenStack，主要包含两子项目，Swift是对象存储模块，Nova是计算模块；
? 带有一个简单的控制台，允许用户通过web管理计算和存储；
? 带有一个部分实现的Image文件管理模块，未正式发布；
? 正式发布Glance项目，负责Image的注册和分发；
? Swift增加了对大文件（大于5G）的支持；增加了支持S3接口的中间件； 增加了一个认证服务中间件Swauth； 等；
? Nova增加对raw磁盘镜像的支持，增加对微软Hyper-V的支持；等；
? 开始了Dashboard控制台的开发；
? Nova增加新的虚拟化技术支持，如LXC容器、VMWare/vSphere、ESX/ESXi 4.1；支持动态迁移运行中的虚机；增加支持Lefthand/HP SAN做为卷存储的后端；
? Glance提供新的CLI工具以支持直接访问；支持多种不同的Image格式；
? Nova 整合Keystone认证 ；支持KVN的暂停恢复；KVM的块迁移；全局防火墙规则；
? Glance 整合Keystone认证 ；增加事件通知机制；
? 正式发布Horizon项目，支持开发第三方插件扩展web控制台；正式发布Keystone项目，提供认证服务；
? Swift支持对象过期；在swift CLI接口上支持Auth 2.0 API；支持URL以允许通过控制台向要求认证的swift集群上传对象；
? Nova 完全依赖Keystone 管理用户、项目、角色等；支持根据角色设定访问控制； 计算与网络解耦，使得网络可以通过独立的服务进行管理；卷管理使用了独立api； 为消息队列增加额外的后端模块；元数据分离；支持浮动ip池；
? 正式发布Quantum项目，提供网络管理服务；正式发布Cinder项目，提供块存储服务；
? Nova中libvirt驱动增加支持以LVM为后端的虚机实例；Xen API增加支持动态迁移、块迁移等功能；增加可信计算池功能； 卷管理服务抽离成Cinder；
? Nova支持将分布于不同地理位置的机器组织成的集群划分为一个cell；支持通过libguestfs直接向guest文件系统中添加文件；通过Glance提供的Image位置URL直接获取Image内容以加速启动；支持无image条件下启动带块设备的实例；支持为虚机实例设置（CPU、磁盘IO、网络带宽）配额；
? Keystone中使用PKI签名令牌代替传统的UUID令牌；
? Quantum中可以根据安全策略对3层和4层的包进行过滤；引入仍在开发中的load balancer服务；
? Cinder中支持光纤通道连接设备；支持LIO做ISCSI的后端；
? 正式发布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；
注：红字部分指出系统添加了新的服务组件，或是新组件出现前的铺垫工作；
| 服务 | 项目名 | 描述 |
| 控制台 | Horizon | 用户通过该服务与OpenStack的各服务进行交互，如启动虚机实例、分配IP地址、设置访问控制等； |
| 计算 | Nova | 按需分派并管理虚机； |
| 网络 | Neutron | 通常是计算服务通过该服务管理网络设置之间的连接，也可以允许终端用户创建并添加网络接口；通过一个插件式架构支持大量网络广商设备及网络技术； |
| 存储类 | ||
| 对象存储 | Swift | 存取文件，但并不提供传统挂载式的文件服务； |
| 块存储 | Cinder | 向虚机提供可用于持久存储的块存储服务； |
| 共用服务 | ||
| 身份服务 | Keystone | 为OpenStack提供认证及授权服务。 |
| 镜像服务 | Glance | 提供虚机镜像的注册服务；同时计算服务也使用该服务分派实例； |
| 计量/监控服务 | Ceilometer | 用于计费、基准测试及数据统计等功能 |
| 更高层服务 | ||
| 编排组织服务 | Heat | 使用自带的HOT模板或AWS的CloudFormation模板，通过OpenStack中各服务的REST API，将各组件的资源组织形成云应用； |
逻辑架构图如下（注：原图在 ，Ceilometer与Heat与服务逻辑无关，因而不在这张图中体现）
计算服务是OpenStack的核心服务，它由nova-compute模块通过libvirt、XenAPI等管理hypervisor，从而管理虚机，此外它还通过nova-api服务向外提供如EC2兼容、管控功能等的接口，通过nova-scheduler模块提供虚机调研逻辑等；这些模块间的通信全部通过消息队列完成；
对象存储服务是OpenStack最早期的两个服务之一（另一个是计算服务），在OpenStack平台中，任何的数据都是一个对象；swift-proxy模块对外提供如HTTP(S)、OpenStack Object API及与S3兼容的存取接口。对象的存取经swift-proxy接入后，还需要经三个模块进行定位，即account、container、object；这是因为在OpenStack中一个对象被描述为：某个帐户下某个容器中的某个对象；
Glance的出现是解决虚机镜像的管理问题；在生成一个镜像后，需要将镜像注册到系统的数据库中；当要实例化一个虚机时，需要将镜像分派到一台具体的实机上用来以启动虚机；因而Glance最重要的接口是镜像的注册和分派；
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的挂载动作封装在驱动中。
经过一定时间的演变，网络管理也抽离成一个独立的服务；在OpenStack的网络管理流程中，通常需要经过以下几个步骤：
1. 创建一个网络；
2. 创建一个子网；
3. 启动一个虚机，将一块网卡对接到指定的网络上；
4. 删除虚机；
5. 删除网络端口；
6. 删除网络；
身份服务需要进行认证凭证的验证及关于用户、角色等的信息，及所有相关的元数据；这些数据全都由Keystone服务管理，并提供CRUD的操作方法；另外这些信息可以从另一个认证服务中获取，例如使用LDAP做Keystone的后端。
以上这些服务与服务、服务与虚机的关系如下图所示：
? 来自加拿大 CANARIE机构的 DAIR：
? 微软的Azure：
? 亚马逊AWS（EC2及配套的S3等）：
? 来自UCSB的Eucalyptus： ，中文入门资料：
? Google GCE：
至于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的发展，看能否得到新的感悟。
