Davidnotes

本文关于云计算方面资料主要源于维基百科，OpenStack部分源于对OpenStack Grizzly Architecture的翻译修改。

简介

OpenStack是当下最为活跃的为公共及私有云的建设与管理提供软件的开源项目（由NASA和RackSpance合作开发，以Apache许可证授权），提供了完整的IaaS解决方案。任何企业和个人都可以使用OpenStack搭建私有云平台向企业内部提供服务，也可以搭建公共云平台向外部提供云服务。目前OpenStack已经有160多的成员，包括诸多行业翘楚。

云计算

云计算是一种基于互联网的计算方式，通过这种方式，共享的软硬件资源和信息可以按需求提供给计算机和其他设备。
根据美国国家标准和技术研究院（NIST）云计算有如下特征：

随需自助服务。
随时随地用任何网络设备访问。
多人共享资源池。
快速重新部署灵活度。
可被监控与量测的服务。

一般认为还有如下特征:

基于虚拟化技术快速部署资源或获得服务。
减少用户终端的处理负担。
降低了用户对于IT专业知识的依赖。

云计算服务模式

云计算通过以下三种模式提供服务:

基础设施即服务(IaaS)
平台即服务(PaaS)
软件即服务 (SaaS)

这里有张参考图：

在大多数云服务模型中，IaaS供应商提供了物理机或者虚拟机以及其他资源。云中可操作的hypervisor池提供大量计算资源，并且可以根据用户需求进行弹性调用资源。IaaS通常还提供虚拟机磁盘镜像库，块存储或者文件存储，防火墙，负载均衡，ip池，vlan以及软件包等等。
IaaS云用户通过镜像部署操作系统，通过软件包来安装维护服务应用。云服务供应商往往都按消费收取费用。
业界比较出名的IaaS供应商有：AMAZON EC2, Rackspace, Linode, Windows Azure Cloud Services等。
在PaaS模式中，云服务供应商提供一个计算平台，平台包括操作系统，开发语言运行环境，数据库，以及服务器。在PaaS云环境中，开发者不需购买和维护物理服务器就可以开发和部署他们的应用。计算和存储资源都是按需弹性分配的，用户不需要手动申请资源。
PaaS供应商主要有：GAE，AWS Elastic Beanstalk等。
在SaaS模式中，云服务供应商提供了应用和数据库的接入，用户既不用管硬件环境，也不用管运行平台。也就无需在自己设备上安装软件就可以使用服务。这大大简化了应用维护和支持的成本。
SaaS供应商主要有：Google Apps，Microsoft Office 365等。

除开上述三种云服务外还有诸如NaaS（Network as a service）, Desktop as a service, Business process as a service, commuication as a service等等云概念，但很多都是上述三种的延伸，也是很多三方公司自己定义的。此处不多赘述

云计算部署模型

先上图：

目前云计算部署模型主要有四种：

公有云 (Public Cloud)
私有云 (Private Cloud)
社区云 (Community Cloud)
混合云 (Hybrid Cloud)

简而言之，公用云服务可通过网络及第三方服务供应者，开放给客户使用，“公用”一词并不一定代表“免费”，但也可能代表免费或相当廉价，公用云并不表示用户数据可供任何人查看，公用云供应者通常会对用户实施使用访问控制机制，公用云作为解决方案，既有弹性，又具备成本效益。
私有云具备许多公用云环境的优点，例如弹性、适合提供服务，两者差别在于私有云服务中，数据与程序皆在组织内管理，且与公用云服务不同，不会受到网络带宽、安全疑虑、法规限制影响；此外，私有云服务让供应者及用户更能掌控云基础架构、改善安全与弹性，因为用户与网络都受到特殊限制。
社区云由众多利益相仿的组织掌控及使用，例如特定安全要求、共同宗旨等。社区成员共同使用云数据及应用程序。
混合云结合公用云及私有云，这个模式中，用户通常将非企业关键信息外包，并在公用云上处理，但同时掌控企业关键服务及数据。

OpenStack

OpenStack是IaaS软件，任何人都可以通过OpenStack建立和提供云端服务。OpenStack同时也可以建立防火墙内的“私有云”，提供机构或企业内部各部门共享资源。

技术框架

纯Python开发；
终端用户可以Web(Horizon)或者三方开发的Client进行交互；
所有的服务通过单独模块(Keystone)认证授权；
各服务通过开放API（HTTP 1.1）通讯
服务内部通信基于AMQP，官方推荐的是Rabbit MQ;
大部分进程都实现了WSGI中间件。

产品线路图

OpenStack 组件(Grizzly)

在grizzly版本中，主要构成有7个模块：

计算(compute);
对象存储(object storage);
认证(identify);
导航(dashboard);
块存储(block storage);
网络(network);
镜像(image)服务

模块具体功能，下文将会有详细叙述。

概念架构

这是一个简化的样式架构图，基本展示了各个部分的功能和相互的接口调用。但是Openstack并不是一个极端的架构，各个部分的功能都可以独立工作。当然，就实践来看，没个模块似乎都离不开keystone。除此以外，每个模块的API大都兼容AWS的，这就给简化系统迁移带来了可能。

逻辑架构

一图胜千言，这张图可以看出我们要说点干货(虽然我有点讨厌这个词)了。同时可能有点看不清，没事，待会儿就能看拿到局部放大图。

Dashboard

Horizon 是官方提供的OpenStack图形界面。基于Django实现，界面提供了以下信息：

配额用度信息；
云计算实例；
对块存储的创建删除链接管理操作；
用于备份启动实例的镜像、快照上传和控制；
密匙对和安全组策略的管理
Cpu，内存，启动盘的实时监测
提供逻辑用户组的项目
用户账户管理员
系统信息
网络
Glance 镜像上传
实例支持细分
跨节点实例迁移

（加粗部分是G版新增部分）
Horizon 的架构非常简单，官方就是通过mod_wsgi进行部署在Apache上，代码独立可复用。

Compute

刚刚说完最简单的，现在可以说一下最复杂的。Nova, 这个模块几乎是OpenStack原型的存在，也是计算虚拟化的核心。由上图也可以看出来，Nova的进程非常之多。Nova中最突出的功能如下：

启动，分配，停止以及查询虚拟机（实例）
分配回收公共IP
链接分开块存储
配置安全组
提供实例命令行
对运行实例进行快照

在Grizzly版本中有了多处修改。其中包括了，nova-network和nova-volume的弃用（取而代之的是quntumn和cinder,quntumn在H版中更名Neutron），同时nova-compute针对数据库的去耦（通过no-compute-db实现）。所有这一系列的变化都是可选的，因为之前的代码都可以获取到。毫无疑问的是，随着项目的迭代，上述组件不久就会消失。

下面聊一下Nova各个模块进程的功能特性：
nova-api: nova-api是Nova进程家族的对外通信接口。支持OpenStack Compute API, 兼容 Amazon EC2 的 API 以及一个管理员的特殊接口。同时它初始化大多数协调进程以及强制一些策略检查。Nova针对不同的进程实现不同的API或者API组。
nova-compute: nova-compute是通过虚拟技术API创建和中介虚拟机实例的基础进程。(eg. XenAPI for XenServer/XCP, libvirt for KVM or QEMU, VMwareAPI for VMware, etc. G版开始支持Hyper-V)。nova-compute进程内部实现比较复杂，但是基础原理还是很好理解的：从消息队列(MQ)中获取request命令，然后执行并通过nova-conductor在数据库中更新状态。nova-conductor组件使用是可选的，使用的话对安全性提升会有帮助。
nova-schedule: nova-schedule进程是nova组件中逻辑最简单的：从消息队列中取出一条命令，然后决定在哪个实例上云运行。而事实上，目前这个模块实现是最复杂的之一。
nova-conductor: nova-conductor是G版新增的服务。它负责其他进程对数据库的访问（目前只有nova-compute），由它过滤后的访问的安全性非常之高。

其余模块，建议参考官方文档。

Object store

OpenStack 的对象存储（“Swift”）设计用于可伸缩扩展的大容量数据存储。不同于文件服务器的是，它是完全分布式的，多份冗余存储。Swift提供了以下功能:

存储和恢复对象（文件）；
配置对象（tags）的元数据；
对象版本管理；
通过HTTP提供静态web page和对象。

Swift 架构是完全分布式的，以此来防止单个节点报废对整个系统带来的影响。它包含了下列组件：

代理服务器（swift-proxy-server)通过Openstack Object API或者直接HTTP来获取进入的request。它接受需要上传的文件，元数据的修改或者是容器的创建。另外，它浏览器提供文件服务。代理服务器会使用一个可选的cache来提升表现。
Account server 管理有对象存储服务生成的账户。
Container server管理对象存储服务的容器映射表。
Object server管理在存储节点上的对象。

Image Store

OpenStack Image 存储集中了用户和云服务的镜像：

存储用户可以启动实例的公共或者私有镜像;
用户可以索引可用的镜像;
向Nova传输镜像来启动实例;
存储运行实例的快照来备份实例

Glance 的架构从Cactus版本已经开始相对稳定了。

Glance-api 接受Image API 调用来实现镜像检索，恢复和存储;
Galnce-registry 存储，运行以及恢复镜像的元数据（大小类型等等）;
数据库用来存储镜像的元数据，和Nova一样，支持sql数据库，一般用mysql;
一个镜像文件的存储仓储，在上图中，Swift用作镜像仓储，但这是可配置的。

除了 Swift，Glance 支持常见的文件系统RADOS的块存储，Amazon S3 以及HTTP。但部分是只读的。

Identity

Keystone 为 Openstack 的策略，认证，catalog，token 提供了一个单点集成。

对接入服务进行的事件和用户进行认证;
存储用户和租户的 RBAC;
在云端提供服务的 catalog;
创建服务或者用户的使用策略;

架构上来说，keystone非常简单：

Keystone 处理API请求同时提供可配置的catalog，策略，token以及认证服务;
每个keystone功能都有一个允许不同方式使用特别服务的插件。大多数支持标准接口诸如LDAP或者SQL以及kv存储。

Network

Quantum 向由其他OpenStack服务（主要是Nova）管理的接口设备提供“Network connectivity as a service”。它提供以下服务：

用户可以创建自己的网络以及链接服务器接口;
插件架构使用户利用了零碎使用的优势;
类似于负载均衡的扩展网络服务.

像 Openstack 的大多数服务一样，Quantum也是可以高度定制的。它是一个插件型的架构。这些插件容纳了不同的设备和软件。如此，架构和部署可以很大的变化。

Quantum-server 接受API的请求然后路由到合适的quantum活动插件;
Quantum扩展以及分支进行实际工作，开关端口，创建网络或超网以及IP地址。这些插件的区别取决于其特有云的技术实现。Quantum配备的插件和扩展：Cisco 虚拟和物理交换机，Nicira NVP产品，NEC OpenFlow产品，Open vSwitch, Linux 桥和Ryu 网络操作系统;
大多数Quantum安装也会使用消息队列来进行quantum-server和大量扩展以及数据库之间的数据交互。

Block Storage

Cinder 将存储功能从OpenStack Compute中分离了出来。OpenStack 块存储API允许卷和卷类别一句卷快照的操作：

创建、配置以及删除卷;
快照以及备份卷;
查询卷状态和元数据

它的架构和Quantum类似，提供了northbound API以及租赁商插件:

Cinder-api 接受API的请求以及将请求分发到cinder-volumn的处理模块
Cinder-volume 通过读写Cinder 数据库更新状态，与其他进程进行交互以处理请求。Cinder进程间通信是通过消息队列，会作用于块存储。它可以跟多种块存储供应商进行交互。
Cinder-scheduler进程和nova-schedule类似都是选择合适的对象进行操作，cinder-schedule是选择合适块存储物理设备来创建卷。
Cinder-backup是一个新的服务，顾名思义，备份用的。主要将卷数据备份到swift。
Cinder 部署同时会给予消息队列传输数据，同时也是用数据库存储volumn状态，一般也是mysql。你有空的话，sqlite和postgresql也不是不行。

后记

本文关于云计算方面资料主要源于维基百科，OpenStack部分源于对OpenStack Grizzly Architecture的翻译修改。
第二次修改做了一些人性化修改，修改了一些读起来反人类的语言，使之稍微容易理解一点。
本文只做概念性引入，细节请参考官方文档和代码。另外，由于H版已经发布，本文部分知识会稍微陈旧，一切以新版为准。在精力允许的情况下，会做H版的适配整理。
以上。

Cinder 简介

Cinder 架构

Cinder 工作原理

总结

参考文档

OpenStack 简介

简介

云计算