Openstack开源系统架构的分析.docx
《Openstack开源系统架构的分析.docx》由会员分享,可在线阅读,更多相关《Openstack开源系统架构的分析.docx(17页珍藏版)》请在三一办公上搜索。
1、OpenStack的架构1. OpenStack 是什么OpenStack既是一个社区,也是一个项目和一个开源软件,它提供了一个部署云的操作 平台或工具集。其宗旨在于,帮助组织运行为虚拟计算或存储服务的云,为公有云、私有云, 也为大云、小云提供可扩展的、灵活的云计算。OpenStack旗下包含了一组由社区维护的开源项目,他们分别是 OpenStack Compute (Nova),OpenStack Object Storage(Swift),以及 OpenStack Image Service(Glance)。OpenStack Compute,为云组织的控制器,它提供一个工具来部署云,包括
2、运行实例、 管理网络以及控制用户和其他项目对云的访问(the cloud through users and projects)0它底层 的开源项目名称是Nova,其提供的软件能控制IaaS云计算平台,类似于Amazon EC2和 Rackspace Cloud Servers0实际上它定义的是,与运行在主机操作系统上潜在的虚拟化机制 交互的驱动,暴露基于Web API的功能。OpenStack Object Storag e2,是一个可扩展的对象存储系统。对象存储支持多种应用, 比如复制和存档数据,图像或视频服务,存储次级静态数据,开发数据存储整合的新应用, 存储容量难以估计的数据,为Web
3、应用创建基于云的弹性存储。OpenStack Image Service】1】,是一个虚拟机镜像的存储、查询和检索系统,服务包括的 RESTful API允许用户通过HTTP请求查询VM镜像元数据,以及检索实际的镜像。VM镜 像有四种配置方式:简单的文件系统,类似OpenStack Object Storage的对象存储系统,直 接用 Amazons Simple Storage Solution (S3)存储,用带有 Object Store 的 S3 间接访问 S3。三个项目的基本关系如下图1-1所示:OpenStack能帮我们建立自己的IaaS,提供类似Amazon Web Servic
4、e的服务给客户。为 实现这一点,我们需要提供几个高级特性:a)允许应用拥有者注册云服务,查看运用和计费情况;b)允许Developers/DevOps folks创建和存储他们应用的自定义镜像;c)允许他们启动、监控和终止实例;d)允许Cloud Operator配置和操作基础架构这四点都直击提供IaaS的核心,现在假设你同意了这四个特性,现在就可以将它们放 进如下所示的概念架构2-1中。ResourcesManagementnttp:.,jiKen.peppic.injoCustonierPortalLogic (Control)2-1 OpenStack概念架构owners and在此模型
5、中,作者假设了需要与云交互的四个用户集:developers, devops, operators,并为每类用户划分了他们所需要的功能。该架构采用的是非常普通的分层方法(presentation, logic and resources), 它带有两个正交区域。展示层,组件与用户交互,接受和呈现信息。Web portals为非开发者提供图形界面,为开发者提供API端点。如果是更复杂的结构,负载均衡,控制代理,安全和名称服务也都 会在这层。逻辑层为云提供逻辑(intelligence)和控制功能。这层包括部署(复杂任务的工作流), 调度(作业到资源的映射),策略(配额等等),镜像注册image
6、registry (实例镜像的元数据),日志(事件和计量)。假设绝大多数服务提供者已经有客户身份和计费系统。任何云架构都需要整合这些系 统。在任何复杂的环境下,我们都将需要一个management层来操作这个环境。它应该包括一个API访问云管理特性以及一些监控形式(forms)0很可能,监控功能将以整合的形式加 入一个已存在的工具中。当前的架构中已经为我们虚拟的服务提供商加入了 monitoring和 admin API,在更完全的架构中,你将见到一系列的支持功能,比如provisioning和 configuration management。最后,资源层。既然这是一个compute云,我们
7、就需要实际的computenetwork和storage 资源,以供应给我们的客户。该层提供这些服务,无论他们是服务器,网络交换机,NAS (network attached storage)还是其他的一些资源。3. OpenStack Compute 架构3.1 OpenStack Compute 逻辑架构OpenStack Compute逻辑架构中,组件中的绝大多数可分为两种自定义编写的Python守 护进程(custom written python daemons)。a) 接收和协调 API 调用的 WSGI 应用(nova-api, glance-api, etc)b) 执行部署任务
8、的 Worker 守护进程(nova-compute, nova-network, nova-schedule, etc.)然而,逻辑架构中有两个重要的部分,既不是自定义编写,也不是基于Python,它们 是消息队列和数据库。二者简化了复杂任务(通过消息传递和信息共享的任务)的异步部署。逻辑架构图3-1如下所示:DashboardEC2/Admln9lance-apnova-apinova-networkglance-r9istrynova-schedulenova-volumeXmage Stor (swift, etc)ECZ/OpcnStack APIGlance APInova dat
9、abaseglanct databa$http Ken.peppie .irntav&lume storage (iSCSI,酎。)3-1 OpenStack Compute 逻辑架构从图中,我们可以总结出三点:a) 终端用户(DevOps, Developers和其他的OpenStack组件)通过和nova-api对话b) OpenStack Compute守护进程之间通过队列(行为)和数据库(信息)来交换信息, 以执行API请求。c) OpenStack Glance 基本上是独立的基础架构,OpenStack Compute 通过 Glance API 来和它交互。其各个组件的情况如下:
10、a) nova-api 守护进程是 OpenStack Comput e 的中心。它为所有 API 查询(OpenStack API 或EC2 API)提供端点,初始化绝大多数部署活动(比如运行实例),以及实施一 些策略(绝大多数的配额检查)。b) nova-compute进程主要是一个创建和终止虚拟机实例的Worker守护进程。其过程 相当复杂,但是基本原理很简单:从队列中接收行为,然后在更新数据库的状态时, 执行一系列的系统命令执行他们。c) nova-volume管理映射到计算机实例的卷的创建、附加和取消。这些卷可以来自很 多提供商,比如,ISCSI和AoE。d) Nova-networ
11、k worker 守护进程类似于 nova-compute 和 nova-volume。它从队列中接 收网络任务,然后执行任务以操控网络,比如创建bridging interfaces或改变iptables rules。e) Queue提供中心hub,为守护进程传递消息。当前用RabbitMQ实现。但是理论上 能是python ampqlib支持的任何AMPQ消息队列。f) SQL database存储云基础架构中的绝大多数编译时和运行时状态。这包括了可用的 实例类型,在用的实例,可用的网络和项目。理论上,OpenStack Compute能支持 SQL-Alchemy支持的任何数据库,但是当
12、前广泛使用的数据库是sqlite3 (仅适合 测试和开发工作),MySQL和PostgreSQLog) OpenStack Glance,是一个单独的项目,它是一个compute架构中可选的部分,分 为三个部分:glance-api, glance-registry and the image store. 其中,glance-api 接受 API调用,glance-registry负责存储和检索镜像的元数据,实际的Image Blob存储 在 Image Store 中。Image Store 可以是多种不同的 Object Stor。,包括 OpenStack Object Storage
13、 (Swift)h) 最后,user dashboard是另一个可选的项目。OpenStack Dashboard提供了一个 OpenStack Compute界面来给应用开发者和devops staff类似API的功能。当前它是作为Django web Application来实现的。当然,也有其他可用的Web前端。3.2概念映射将逻辑架构映射到概念架构中(如3-2所示),可以看见我们还缺少什么。ustomsrLogic (Control)Management3-2逻辑架构到概念架构的映射这种覆盖方式并不是唯一的,这里的只是作者的理解。通过覆盖OpenStack Compute 逻辑组件,G
14、lance和Dashboard,来表示功能范围。对于每一个覆盖,都有相应的提供 该功能的逻辑组件的名称。a) 在这种覆盖范围中,最大的差距是logging和billing。此刻,OpenStack Compute没 有能协调logging事件、记录日志以及创建/呈现bills的Billing组件。真正的焦点是 logging和Billing的整合。这能通过以下方式来补救。比如代码扩充,商业产品或者 服务或者自定义日志解析的整合。b) Identity也是未来可能要补充的一点。c) customer portal也是一个整合点。user dashboard(见运行的实例,启动新的实例)没 有提供
15、一个界面,来允许应用拥有者签署服务,跟踪它们的费用以及声明有问题的 票据(lodge trouble tickets)0而且,这很可能对我们设想的服务提供商来说是合适的。d) 理想的情况是,Admin API会复制我们能通过命令行接口做的所有功能。在带有 Admin API work的Diablo发布中会更好。e) 云监控和操作将是服务提供商关注的重点。好操作方法的关键是好的工具。当前, 们还需要三方工具来监控。f)Policy是极其重要的方面,但是会与供应商很相关。从quotas到QoS,到隐私控制 都在其管辖内。当前图上有部分覆盖,但是这取决于供应商的复杂需求。为准确起 见,OpenSta
16、ck Compute为实例,浮点IP地址以及元数据提供配额。g)当前,OpenStack Compute内的Scheduling对于大的安装来说是相当初步的。调度器 是以插件的方式设计的,目前支持chance(随机主机分配),simple(最少负载)和zone(在一个可用区域里的随机结点。)分布式的调度器和理解异构主机的调度器正在开 发之中。如你所见,OpenStack Compute为我们想象的服务提供商,提供了一个不错的基础,只 要服务提供商愿意做一些整合。3.3 OpenStack Compute 系统架构OpenStack Compute由一些主要组件组成。“Cloud control
17、ler”包含很多组件,它表示全 局状态,以及与其他组件交互。实际上,它提供的是Nova-api服务。它的功能是:为所有 API查询提供一个端点,初始化绝大多数的部署活动,以及实施一些策略。API服务器起cloud controller web Service 前端的作用。Compute controller 提供 compute 服务资源,典型包含 compute service, Object Store component 可选地提供存储服务。Auth manager 提供认证和授 权服务,Volume controller为compute servers提供快速和持久的块级别存储。Net
18、work controller提供虚拟网络使compute servers彼此交互以及与公网进行交互。Scheduler选择最 合适的compute controller来管理(host)一个实例。OpenStack Compute建立在无共享、基于消息的架构上。Cloud controller通过HTTP与 internal object store 交互,通过 AMQP 和 scheduler、network controller、 和 volume controller 来进行通信。为了避免在等待接收时阻塞每个组件,OpenStack Compute用异步调用的方式。为了获得带有一个组件
19、多个备份的无共享属性,OpenStack Compute将所有的云系统状 态保持在分布式的数据存储中。对系统状态的更新会写到这个存储中,必要时用质子事务。 对系统状态的请求会从store中读出。在少数情况下,控制器也会短时间缓存读取结果。3.4 OpenStack Compute 物理架构OpenStack Compute采用无共享、基于消息的架构,非常灵活,我们能安装每个novaservice 在单独的服务器上,这意味着安装OpenStack Compute有多种可能的方法。可能多结点部署唯一的联合依赖性,是Dashboard必须被安装在nova-api服务器。几种部署架构如下:a)单结点:
20、一台服务器运行所有的nova- services,同时也驱动虚拟实例。这种配置只为尝试OpenStack Compute,或者为了开发目的;b)双结点:一个 cloud controller 结点运行除 nova-compute 夕卜的所有 nova-services,compute 结点运行nova-computeo 一台客户计算机很可能需要打包镜像,以及和服务器进行交互, 但是并不是必要的。这种配置主要用于概念和开发环境的证明。c)多结点:通过简单部署nova-compute在一台额外的服务器以及拷贝nova.conf文件到这 个新增的结点,你能在两结点的基础上,添加更多的compute结
21、点,形成多结点部署。 在较为复杂的多结点部署中,还能增加一个volume controller和一个network controller 作为额外的结点。对于运行多个需要大量处理能力的虚拟机实例,至少是4个结点是最 好的。一个可能的Openstack Compute多服务器部署(集群中联网的虚拟服务器可能会改变) 如下3-3所示:Private SwitchGpenStack Compute services server on second nodeCloud of 2-4 irtijal servers i:n on e dustier S4fclfontained storage of
22、virtual imagesInternetRouter3-3 OpenStack Compute 物理架构一如果你注意到消息队列中大量的复制引发了性能问题,一种可选的架构是增加更多的 Messaging服务器。在这种情形下,除了可以扩展数据库服务器外,还可以增加一台额外的 RabbitMQ服务器。部署中可以在任意服务器上运行任意 nova-service, 只要 nova.conf 中配己 置为指向RabbitMQ服务器,并且这些服务器能发送消息到它。下图3-4是另外一种多结点的部署架构。Cloud controller spread across mulitple nodesDatabas
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Openstack 系统 架构 分析
链接地址:https://www.31ppt.com/p-4886991.html