3-4 多结点的部署架构二
3.5 OpenStack Compute服务架构
因为Compute有多个服务，也可能有多种配置，下图3-5显示了总体的服务架构，
以及服务之间的通信系统。
16
3-5 OpenStack Compute服务架构
1. OpenStack Image Service
OpenStack Image Service包括两个主要的部分，分别是API server和Registry server(s)。
OpenStack Image Service的设计，尽可能适合各种后端仓储和注册数据库方案。API Server（运行“glance api”程序）起通信hub的作用。比如各种各样的客户程序，镜像元数据的注册，实际包含虚拟机镜像数据的存储系统，都是通过它来进行通信的。API server转发客户端的请求到镜像元数据注册处和它的后端仓储。OpenStack Image Service就是通过这些机制来实际保存进来的虚拟机镜像的。
OpenStack Image Service支持的后端仓储有：
? OpenStack Object Storage。它是OpenStack中高可用的对象存储项目。
? FileSystem。OpenStack Image Service存储虚拟机镜像的默认后端是后端文件系统。
这个简单的后端会把镜像文件写到本地文件系统。
? S3。该后端允许OpenStack Image Service存储虚拟机镜像在Amazon S3服务中。 ? HTTP。OpenStack Image Service能通过HTTP在Internet上读取可用的虚拟机镜像。
这种存储方式是只读的。
17
OpenStack Image Service registry servers是遵守OpenStack ImageService Registry API的服务器。
根据安装手册，这两个服务安装在同一个服务器上。镜像本身则可存储在OpenStack Object Storage， Amazon's S3 infrastructure，fileSystem。如果你只需要只读访问，可以存储在一台Web服务器上。
2. OpenStack ObjectStorage
5.1 关键概念
? Accounts和 Account Servers
OpenStack Object Storage系统被设计来供许多不同的存储消费者或客户使用。每个用户必须通过认证系统来识别自己。为此，OpenStack Object Storage提供了一个授权系统（swauth）。
运行Account服务的结点与个体账户是不同的概念。Account服务器是存储系统的部分，必须和Container服务器和Object服务器配置在一起。 ? Authentication 和 Access Permissions
你必须通过认证服务来认证，以接收OpenStack ObjectStorage连接参数和认证令牌。令牌必须为所有后面的container/object操作而传递。典型的，特定语言的API处理认证，令牌传递和HTTPS request/response通信。
通
过
运
用
X-Container-Read:
accountname
和
X-Container-Write:
accountname:username，你能为用户或者账户对对象执行访问控制。比如，这个设置就允许来自accountname账户的的任意用户来读，但是只允许accountname账户里的用户username来写。你也能给OpenStack Object Storage中存储的对象授予公共访问的权限，而且可以通过Referer头部阻止像热链接这种基于站点的内容盗窃，来限制公共访问。公共的container设置被用作访问控制列表之上的默认授权。比如，X-Container-Read: referer: any这个设置，允许任何人能从container中读，而不管其他的授权设置。
一般来说，每个用户能完全访问自己的存储账户。用户必须用他们的证书来认证，一旦被认证，他们就能创建或删除container，以及账户之类的对象。一个用户能访问另一个账户的内容的唯一方式是，他们享有一个API访问key或你的认证系统提供的会话令牌。
? Containers and Objects
一个Container是一个存储隔间，为你提供一种组织属于属于你的数据的方式。它比较类似于文件夹或目录。Container和其他文件系统概念的主要差异是containers不能嵌套。然而，你可以在你的账户内创建无数的containers。但是你必须在你的账户上有一个container，因为数据必须存在Container中。
Container取名上的限制是，它们不能包含“/”，而且长度上少于256字节。长度的限制也适用于经过URL编码后的名字。比如，Course Docs的Container名经过URL编
18
码后是“Course Docs”，因此此时的长度是13字节而非11字节。
一个对象是基本的存储实体，和表示你存储在OpenStack Object Storage系统中文件的任何可选的元数据。当你上传数据到OpenStackObject Storage，它原样存储，由一个位置（container），对象名，以及key/value对组成的任何元数据。比如，你可选择存储你数字照片的副本，把它们组织为一个影集。在这种情况下，每个对象可以用元数据Album :
Caribbean Cruise 或Album : Aspen Ski Trip来标记。
对象名上唯一的限制是，在经过URL编码后，它们的长度要少于1024个字节。 上传的存储对象的允许的最大大小5GB，最小是0字节。你能用内嵌的大对象支持
和St工具来检索5GB以上的对象。对于元数据，每个对象不应该超过90个key/value对，所有key/value对的总字节长度不应该超过4KB。 ? Operations
Operations是你在OpenStack Object Storage系统上执行的行为，比如创建或删除containers，上传或下载objects等等。Operations的完全清单可以在开发文档上找到。Operations能通过ReST web service API或特定语言的API来执行。值得强调的是，所有操作必须包括一个来自你授权系统的有效的授权令牌。 ? 特定语言的API绑定
一些流行语言支持的API 绑定，在RackSpace云文件产品中是可用的。这些绑定在基础ReST API上提供了一层抽象，允许变成人员直接与container和object模型打交道，而不是HTTP请求和响应。这些绑定可免费下载，使用和修改。它们遵循MIT许可协议。对于OpenStack Object Storage，当前支持的API绑定是：PHP，Python，Java，C#/.NET 和Ruby。
5.2 Object Storage如何工作 ? Ring
Ring 代表磁盘上存储的实体的名称和它们的物理位置的映射。accounts, containers, and objects都有单独的Ring。其他组件要在这三者之一进行任何操作，他们都需要合相应的Ring进行交互以确定它在集群中的位置。
Ring用zones，devices，partitions，和replicas来维护映射，在Ring中的每个分区都会在集群中默认有三个副本。分区的位置存储在Ring维护的映射中。Ring也负责确定失败场景中接替的设备。（这点类似HDFS副本的复制）。分区的副本要保证存储在不同的zone。Ring的分区分布在OpenStack ObjectStorage installation所有设备中。分区需要移动的时候，Ring确保一次移动最少的分区，一次仅有一个分区的副本被移动。
权重能用来平衡分区在磁盘驱动上的分布。Ring在代理服务器和一些背景进程中使用。
? Proxy Server
代理服务器负责将OpenStack Object Storage架构中其他部分结合在一起。对于每次
19
请求，它都查询在Ring中查询account, container, orobject的位置，并以此转发请求。公有APIs也是通过代理服务器来暴露的。
大量的失败也是由代理服务器来进行处理。比如一个服务器不可用，它就会要求Ring来为它找下一个接替的服务器，并把请求转发到那里。
当对象流进或流出object server时，它们都通过代理服务器来流给用户，或者通过它从用户获取。代理服务器不会缓冲它们。
Proxy服务器的功能可以总结为：查询位置，处理失败，中转对象。 ? Object Server
Object Server，是非常简单的blob存储服务器，能存储、检索和删除本地磁盘上的对象，它以二进制文件形式存放在文件系统中，元数据以文件的扩展属性存放。 对象以源于对象名的hash和操作的时间戳的路径来存放。上一次写总会成功，确保最新的版本将被使用。删除也视作文件的一个版本：这确保删除的文件也被正确复制，更旧的把本不会因为失败情形离奇消失。 ? Container Server
其主要工作是处理对象列表，它不知道对象在哪里，只是知道哪些对象在一个特定的container。列表被存储为sqlite 数据库文件，类似对象的方式在集群中复制。也进行了跟踪统计，包括对象的总数，以及container中使用的总存储量。 ? Account Server
它是类似于Container Server，除了它是负责containers的列表而非对象。 ? Replication
设计副本的目的是，在面临网络中断或驱动失败等临时错误条件时，保持系统在一致的状态。
副本进程会比较本地的数据和每个远处的副本，以确保他们所有都包含最新的版本。对象副本用一个Hash列表来快速比较每个分区的片段，而containe和 account replication用的是Hash和共享的高水印结合的方法。
副本的更新，是基于推送的。对于对象副本，更新是远程同步文件到Peer。Account和container replication通过HTTPor rsync把整个数据库文件推送遗失的记录。
副本也通过tombstone设置最新版本的方式，确保数据从系统中清除。 ? 更新器（Updaters）
有时，container 或 account数据不能被立即更新，这通常是发生在失败的情形或高负载时期。如果一个更新失败，该更新会在文件系统上本地排队，更新器将处理这些失败的更新。事件一致性窗口（eventual consistency window）最可能来起作用。比如，假设一个container服务器正处于载入之中，一个新对象正被放进系统，代理服务器一响应客户端成功，该对象就立即可读了。然而，container服务器没有更新Object列表，所以更新就进入队列，以等待稍后的更新。Container列表，因此可能还不会立即包含这个对象。
20
基于云计算平台的openstack系统集成与实现毕业论文
