OpenStack 架构

zxmin4236 贡献于2012-12-04

作者 HENRY  创建于2012-11-28 14:04:00   修改者HENRY  修改于2012-11-28 14:57:00字数6572

文档摘要:OpenStack既是一个社区,也是一个项目和一个开源软件,它提供了一个部署云的操作平台或工具集。其宗旨在于,帮助组织运行为虚拟计算或存储服务的云,为公有云、私有云,也为大云、小云提供可扩展的、灵活的云计算。OpenStackCompute,为云组织的控制器,它提供一个工具来部署云,包括运行实例、管理网络以及控制用户和其他项目对云的访问。它底层的开源项目名称是Nova,其提供的软件能控制IaaS云计算平台。
关键词:

OpenStack架构 OpenStack既是一个社区,也是一个项目和一个开源软件,它提供了一个部署云的操作平台或工具集。其宗旨在于,帮助组织运行为虚拟计算或存储服务的云,为公有云、私有云,也为大云、小云提供可扩展的、灵活的云计算。 OpenStack旗下包含了一组由社区维护的开源项目,他们分别是: ①OpenStackCompute(Nova), ②OpenStackObjectStorage(Swift), ③OpenStackImageService(Glance)。 三个项目的基本关系如下图所示: 1.OpenStack Computer(Nova) OpenStackCompute,为云组织的控制器,它提供一个工具来部署云,包括运行实例、管理网络以及控制用户和其他项目对云的访问。它底层的开源项目名称是Nova,其提供的软件能控制IaaS云计算平台。 1.1逻辑架构 OpenStack Compute逻辑架构中,组件中的绝大多数可分为两种自定义编写的Python守护进程(custom written python daemons)。 a) 接收和协调API调用的WSGI应用(nova-api, glance-api, etc) b) 执行部署任务的Worker守护进程(nova-compute, nova-network, nova-schedule, etc.) 然而,逻辑架构中有两个重要的部分,既不是自定义编写,也不是基于Python,它们是 ①消息队列和②数据库。二者简化了复杂任务(通过消息传递和信息共享的任务)的异步部署。 逻辑架构如下图所示: 从OpenStack Compute的逻辑架构图中可总结出一下三点: a) 终端用户(DevOps, Developers 和其他的 OpenStack 组件)通过和nova-api对话来与OpenStack Compute交互。 b) OpenStack Compute守护进程之间通过队列(行为)和数据库(信息)来交换信息,以执行API请求。 c) OpenStack Glance基本上是独立的基础架构,OpenStack Compute通过Glance API来和它交互。 其各个组件的情况如下: a) nova-api守护进程是OpenStack Compute的中心。它为所有API查询(OpenStack API 或 EC2 API)提供端点,初始化绝大多数部署活动(比如运行实例),以及实施一些策略(绝大多数的配额检查)。 b) nova-compute进程主要是一个创建和终止虚拟机实例的Worker守护进程。其过程相当复杂,但是基本原理很简单:从队列中接收行为,然后在更新数据库的状态时,执行一系列的系统命令执行他们。 c) nova-volume管理映射到计算机实例的卷的创建、附加和取消。这些卷可以来自很多提供商,比如,ISCSI和AoE。 d) nova-network worker守护进程类似于nova-compute和nova-volume。它从队列中接收网络任务,然后执行任务以操控网络,比如创建bridging interfaces或改变iptables rules。 e) Queue提供中心hub,为守护进程传递消息。当前用RabbitMQ实现。但是理论上能是python ampqlib支持的任何AMPQ消息队列。 f) SQL database存储云基础架构中的绝大多数编译时和运行时状态。这包括了可用的实例类型,在用的实例,可用的网络和项目。理论上,OpenStack Compute能支持SQL-Alchemy支持的任何数据库,但是当前广泛使用的数据库是sqlite3(仅适合测试和开发工作),MySQL和PostgreSQL。 g) OpenStack Glance,是一个单独的项目,它是一个compute架构中可选的部分,分为三个部分:glance-api, glance-registry and the image store. 其中,glance-api接受API调用,glance-registry负责存储和检索镜像的元数据,实际的Image Blob存储在Image Store中。Image Store可以是多种不同的Object Store,包括OpenStack Object Storage (Swift) h) 最后,user dashboard是另一个可选的项目。OpenStack Dashboard提供了一个OpenStack Compute界面来给应用开发者和devops staff类似API的功能。当前它是作为Django web Application来实现的。当然,也有其他可用的Web前端。 1.2 OpenStack Computer系统架构 OpenStack Compute由一些主要组件组成。“Cloud controller”包含很多组件,它表示全局状态,以及与其他组件交互。实际上,它提供的是Nova-api服务。它的功能是:为所有API查询提供一个端点,初始化绝大多数的部署活动,以及实施一些策略。API 服务器起cloud controller web Service前端的作用。Compute controller 提供compute服务资源,典型包含compute service,Object Store component可选地提供存储服务。Auth manager提供认证和授权服务,Volume controller为compute servers提供快速和持久的块级别存储。Network controller提供虚拟网络使compute servers彼此交互以及与公网进行交互。Scheduler选择最合适的compute controller来管理(host)一个实例。 OpenStack Compute建立在无共享、基于消息的架构上。Cloud controller通过HTTP与internal object store交互,通过AMQP和scheduler、network controller、 和volume controller 来进行通信。为了避免在等待接收时阻塞每个组件,OpenStack Compute用异步调用的方式。 为了获得带有一个组件多个备份的无共享属性,OpenStack Compute将所有的云系统状态保持在分布式的数据存储中。对系统状态的更新会写到这个存储中,必要时用质子事务。 对系统状态的请求会从store中读出。在少数情况下,控制器也会短时间缓存读取结果。 1.3 OpenStack Computer物理结构 OpenStack Compute采用无共享、基于消息的架构,非常灵活,我们能安装每个nova- service在单独的服务器上,这意味着安装OpenStack Compute有多种可能的方法。可能多结点部署唯一的联合依赖性,是Dashboard必须被安装在nova-api服务器。 几种部署架构如下: a) 单结点:一台服务器运行所有的nova- services,同时也驱动虚拟实例。这种配置只为尝试OpenStack Compute,或者为了开发目的; b) 双结点:一个cloud controller 结点运行除nova-compute外的所有nova-services,compute结点运行nova-compute。一台客户计算机很可能需要打包镜像,以及和服务器进行交互,但是并不是必要的。这种配置主要用于概念和开发环境的证明。 c) 多结点:通过简单部署nova-compute在一台额外的服务器以及拷贝nova.conf文件到这个新增的结点,你能在两结点的基础上,添加更多的compute结点,形成多结点部署。在较为复杂的多结点部署中,还能增加一个volume controller 和一个network controller作为额外的结点。对于运行多个需要大量处理能力的虚拟机实例,至少是4个结点是最好的。 1.4OpenStack Computer服务架构 因为Compute有多个服务,也可能有多种配置,下图显示了总体的服务架构,以及服务之间的通信系统。 2.OpenStack Object Storage OpenStackObjectStorage,是一个可扩展的对象存储系统。对象存储支持多种应用,比如复制和存档数据,图像或视频服务,存储次级静态数据,开发数据存储整合的新应用,存储容量难以估计的数据,为Web应用创建基于云的弹性存储。 2.1 OpenStack Object Storage的各组件 a) Ring Ring 代表磁盘上存储的实体的名称和它们的物理位置的映射。accounts, containers, and objects都有单独的Ring。其他组件要在这三者之一进行任何操作,他们都需要合相应的Ring进行交互以确定它在集群中的位置。 Ring用zones,devices,partitions,和replicas来维护映射,在Ring中的每个分区都会在集群中默认有三个副本。分区的位置存储在Ring维护的映射中。Ring也负责确定失败场景中接替的设备。 (这点类似HDFS副本的复制)。分区的副本要保证存储在不同的zone。Ring的分区分布在OpenStack Object Storage installation所有设备中。分区需要移动的时候,Ring确保一次移动最少的分区,一次仅有一个分区的副本被移动。 权重能用来平衡分区在磁盘驱动上的分布。Ring在代理服务器和一些背景进程中使用。 b) Proxy Server 代理服务器负责将OpenStack Object Storage架构中其他部分结合在一起。对于每次请求,它都查询在Ring中查询account, container, or object的位置,并以此转发请求。公有APIs也是通过代理服务器来暴露的。 大量的失败也是由代理服务器来进行处理。比如一个服务器不可用,它就会要求Ring来为它找下一个接替的服务器,并把请求转发到那里。 当对象流进或流出object server时,它们都通过代理服务器来流给用户,或者通过它从用户获取。代理服务器不会缓冲它们。 Proxy服务器的功能可以总结为:查询位置,处理失败,中转对象。 c) Object Server Object Server,是非常简单的blob存储服务器,能存储、检索和删除本地磁盘上的对象,它以二进制文件形式存放在文件系统中,元数据以文件的扩展属性存放。 对象以源于对象名的hash和操作的时间戳的路径来存放。上一次写总会成功,确保最新的版本将被使用。删除也视作文件的一个版本:这确保删除的文件也被正确复制,更旧的把本不会因为失败情形离奇消失。 d) Container Server 其主要工作是处理对象列表,它不知道对象在哪里,只是知道哪些对象在一个特定的container。列表被存储为sqlite 数据库文件,类似对象的方式在集群中复制。也进行了跟踪统计,包括对象的总数,以及container中使用的总存储量。 e) Account Server 它是类似于Container Server,除了它是负责containers的列表而非对象。 f) Replication 设计副本的目的是,在面临网络中断或驱动失败等临时错误条件时,保持系统在一致的状态。 副本进程会比较本地的数据和每个远处的副本,以确保他们所有都包含最新的版本。对象副本用一个Hash列表来快速比较每个分区的片段,而container和 account replication 用的是Hash和共享的高水印结合的方法。 副本的更新,是基于推送的。对于对象副本,更新是远程同步文件到Peer。Account和container replication通过HTTP or rsync把整个数据库文件推送遗失的记录。 副本也通过tombstone设置最新版本的方式,确保数据从系统中清除。 g) 更新器(Updaters) 有时,container 或 account数据不能被立即更新,这通常是发生在失败的情形或高负载时期。如果一个更新失败,该更新会在文件系统上本地排队,更新器将处理这些失败的更新。事件一致性窗口(eventual consistency window)最可能来起作用。比如,假设一个container 服务器正处于载入之中,一个新对象正被放进系统,代理服务器一响应客户端成功,该对象就立即可读了。然而,container服务器没有更新Object列表,所以更新就进入队列,以等待稍后的更新。Container列表,因此可能还不会立即包含这个对象。 实际上,一致性窗口只是与updater运行的频率一样大,当代理服务器将转发清单请求到响应的第一个container服务器中,也许甚至还不会被注意。在载入之下的服务器可能还不是服务后续清单请求的那个。另外两个副本中的一个可能处理这个清单。 h) Auditors Auditors会检查objects, containers, 和 accounts的完整性。如果发先损坏的文件,它将被隔离,好的副本将会取代这个坏的文件。如果发现其他的错误,它们会记入到日志中。 2.2 OpenStack Object Storage物理架构 Proxy Services 偏向于CPU和network I/O 密集型,而 Object Services, Container Services, Account Services 偏向于disk and network I/O 密集型。 可以在每一服务器上安装所有的服务,在Rackspace内部, 他们将Proxy Services放在他们自己的服务器上,而所有存储服务则放在同一服务器上。这允许我们发送10G的网络给代理,1G给存储服务器,从而保持对代理服务器的负载平衡更好管理。我们能通过增加更多代理来扩展整个API吞吐量。如果需要获得Account或 Container Services更大的吞吐量,它们也可以部署到自己的服务器上。 在部署OpenStack Object Storage时,可以单结点安装,但是它只适用于开发和测试目的。也可以多服务器的安装,它能获得分布式对象存储系统需要的高可用性和冗余。 3.OpenStack Image Service OpenStackImageService,是一个虚拟机镜像的存储、查询和检索系统,服务包括的RESTfulAPI允许用户通过HTTP请求查询VM镜像元数据,以及检索实际的镜像。VM镜像有四种配置方式:简单的文件系统,类似OpenStackObjectStorage的对象存储系统,直接用Amazon'sSimpleStorageSolution(S3)存储,用带有ObjectStore的S3间接访问S3。 OpenStack Image Service包括两个主要的部分,分别是API server和Registry server(s)。 OpenStack Image Service的设计,尽可能适合各种后端仓储和注册数据库方案。API Server(运行“glance api”程序)起通信hub的作用。比如各种各样的客户程序,镜像元数据的注册,实际包含虚拟机镜像数据的存储系统,都是通过它来进行通信的。API server转发客户端的请求到镜像元数据注册处和它的后端仓储。OpenStack Image Service就是通过这些机制来实际保存进来的虚拟机镜像的。 OpenStack Image Service支持的后端仓储有: a) OpenStack Object Storage。它是OpenStack中高可用的对象存储项目。 b) FileSystem。OpenStack Image Service存储虚拟机镜像的默认后端是后端文件系统。这个简单的后端会把镜像文件写到本地文件系统。 c) S3。该后端允许OpenStack Image Service存储虚拟机镜像在Amazon S3服务中。 d) HTTP。OpenStack Image Service能通过HTTP在Internet上读取可用的虚拟机镜像。这种存储方式是只读的。 OpenStack Image Service registry servers是遵守OpenStack Image Service Registry API的服务器。

下载文档到电脑,查找使用更方便

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享文档获得金币 ] 0 人已下载

下载文档