【OpenStack】G版中关于Nova的Cell

OpenStack Cell 架构详解
本文详细介绍了OpenStack中的Cell架构,旨在解决大规模部署下的横向扩展问题,同时保持数据库和消息中间件的简单性。文章阐述了Cell架构的设计目标、概念及组件,并提供了具体的配置示例。

本博客欢迎转发,但请保留原作者信息!内容系本人学习、研究和总结,如有雷同,实属荣幸!

1 目标

1. 为了增加横向扩展以及分布式,大规模(地理位置级别)部署能力,但又不增加数据库和消息中间件的复杂度
2. 将cell调度和主机调度隔离

2 简介

我们都熟悉Amazon EC2,他有一些基本概念:
》一个地理区域(Region)包含多个可用区域(Availability Zone)
》Availability Zone相互之间物理隔离,一个Availability Zone的故障不会影响其他的使用
》客户端连接Region
》创建VM时,如果没有指定Availability Zone,调度算法会从Region中选择一个
》相反,如果指定了Availability Zone,则在其上创建VM

OpenStack从B版就基于Amazon的这种概念实现了Availability Zone。然后,又出现了Zone的概念:
》一个Zone就是一套独立的Nova部署环境
》Zone之间无共享,相互隔离
在D版,当出现Keystone之后,Zone的概念就被废弃掉了

而在G版,重新提出了”Cell”的概念,Cell之间的通信的可信的,基于AMQP协议。概括如下:
》每一个Cell中拥有独立的DB和AMQP broker
》引入新的nova-cell服务
-消息路由
-调度(与主机调度不同,子Cell通过定时刷新将自己能力和资源上报给父Cell)
》cell之间通信通过RPC
》cells之间是树状结构
-顶层是API cell,不感知底层物理主机以及虚拟化
-子cell无nova-api服务
-子cell无quota概念(NoopQuota)

3 服务部署



在API cell节点要部署nova-api对外提供统一服务,nova-cell负责与子cell之间通信;子cell节点统一要部署nova-cell,如果子cell直接接入虚拟化层,则还要部署nova-scheduler,nova-compute。消息通信如下:

上图是三个cell级联的情况,其中API Cell收到请求后,通过nova-cell提供的调度算法,通过消息队列将消息转发到Child Cell节点,在Child Cell节点做与API Cell同样的工作,选择一个Grandchild Cell并继续转发,在Grandchild节点上做真正的主机调度工作,选择主机创建虚拟机。

上面的情况下,Grandchild Cell需要将自己连接的资源信息定时上报给Child Cell以提供调度功能使用,同样Child Cell也要自己知道的资源信息上报给API Cell使用,这样,每层调度时只需拿自己掌握的资源信息即可,实现每层解耦。

4 配置

从目前的实现来看,在nova.conf中要提供几个配置项:
enable:是否启用cell功能
name:当前节点的cell名称
capabilities:自定义的键值对信息(目前尚未使用)
此外,要配置每个cell节点的compute_api_class和quota_driver,例如在API Cell节点需要配置:
compute_api_class=nova.compute.cells_api.ComputeCellsAPI
[cells]
name=api
enable=true
而在child cell节点,需要配置(compute_api_class默认配置为nova.compute.api.API):
quota_driver=nova.quota.NoopQuotaDriver
[cells]
enable=true
name=cell1

在使用前,还需要配置一些信息以便让cell之间相互识别并规定各自的角色,谁是谁的parent,谁是谁的child。因为cell之间通过AMQP协议通信,因此只需配置相互的AMQP信息即可。假如我们有三个cell,其中一个为parent cell(名称为api),其他两个为child cell(名称分别为cell1和cell2)。则在parent cell节点上执行:
> nova-manage cell create --name=cell1 --cell_type=child --username=cell1_user --password=cell1_passwd --hostname=10.0.1.10 --port=5673 --virtual_host=cell1_vhost --woffset=1.0 --wscale=1.0
> nova-manage cell create --name=cell2 --cell_type=child --username=cell2_user --password=cell2_passwd --hostname=10.0.2.10 --port=5673 --virtual_host=cell2_vhost --woffset=1.0 --wscale=1.0
而在两个child cell节点上,分别执行:
> nova-manage cell create --name=api --cell_type=parent --username=api1_user --password=api1_passwd --hostname=10.0.0.10 --port=5672 --virtual_host=api_vhost --woffset=1.0 --wscale=1.0

<think>好的,我现在需要回答用户关于OpenStack NovaCell的概念和作用的问题。首先,我应该回顾一下用户提供的引用内容,看看有哪些相关信息可以利用。 根据引用[1],Nova Cell模块是在G本中引入的,主要用于横向扩展和大规模部署。它通过将云环境划分为多个子Cell来减少对原环境的影响。每个Cell都有nova-cells服务,负责与其他Cell通信,目前只支持RPC。调度方面,Cell的调度和计算节点的调度是分离的,nova-cells服务会选择合适的Cell处理请求,然后再由目标Cell的计算主机调度处理。 引用[4]提到Cell V2架构涉及nova_api数据库中的三个表:cell_mappings、host_mappings和instance_mappings,这些表管理Cell、主机和实例的映射关系,这有助于理解Cell数据库层面的实现。 引用[5]提到了nova组件的入口点和RPC通信机制,这可能与Cell之间的通信有关,因为引用[1]指出Cell间通信使用RPC。 接下来需要将Cell的概念和作用整理清楚。概念部分应该包括Cell的定义、架构分层(如API Cell和子Cell)、数据库结构。作用部分需要强调横向扩展、资源隔离、调度分层、部署灵活性和高可用性。 需要注意用户要求使用中文回答,行内公式用$...$,独立公式用$$...$$,但这里可能不太涉及数学公式,所以可能不需要。但如果有涉及性能模型的地方,可能需要公式,比如横向扩展带来的性能提升模型,不过根据引用内容,可能不需要。 然后生成相关问题,应该基于用户的问题扩展,比如如何配置、与资源调度的区别、数据库表作用、通信机制、V1和V2的区别等。 检查引用标记是否正确添加,比如在提到横向扩展时引用[1],数据库结构引用[4],通信机制引用[1]和[5]。 需要确保回答结构清晰,分点说明概念和作用,使用用户提供的引用内容作为支持,并自然地添加引用标识。</think>### OpenStack NovaCell的概念及作用 #### 一、Cell的基本概念 1. **Cell定义** Nova CellOpenStack用于实现**横向扩展**和**分层管理**的架构模块,通过将云环境划分为多个逻辑单元(子Cell),解决单一Nova服务在大规模部署时的性能瓶颈[^1]。 2. **分层架构** - **API Cell**:负责接收用户请求,并协调子Cell间的任务分配。 - **子Cell**:包含独立的计算节点和资源池,每个子Cell运行完整的Nova服务(如nova-cells、nova-scheduler等)[^1][^4]。 3. **数据库结构** 多Cell的实现依赖以下关键数据库表(位于`nova_api`库): - `cell_mappings`:记录Cell的UUID和通信地址。 - `host_mappings`:关联主机与所属Cell。 - `instance_mappings`:管理实例与Cell的映射关系[^4]。 $$ \text{Cell划分逻辑} \rightarrow \text{cell\_mappings} \leftrightarrow \text{host\_mappings} \leftrightarrow \text{instance\_mappings} $$ #### 二、Cell的核心作用 1. **横向扩展能力** 通过添加子Cell扩展资源池,避免单点资源上限问题。例如,当计算节点超过1000台时,可通过分Cell降低调度压力[^1]。 2. **资源隔离与故障隔离** - 不同Cell的计算资源相互独立,避免资源竞争。 - 单个Cell故障不会影响其他Cell的运行[^1]。 3. **分层调度机制** - **Cell层调度**:由`nova-cells`服务选择目标子Cell(基于权重或随机策略)。 - **计算层调度**:子Cell内部的`nova-scheduler`选择具体主机[^1][^5]。 4. **部署灵活性** 支持动态添加或移除Cell,无需重启原有服务。例如,通过以下命令注册新Cell: ```bash nova-manage cell_v2 create_cell --name=cell2 --transport-url=rabbit://cell2:5672/ ``` 5. **高可用性增强** API Cell可部署为多节点集群,子Cell可独立配置冗余服务(如多个nova-conductor)[^2][^3]。 #### 三、通信机制 Cell间通过**RPC(远程过程调用)**通信,依赖消息队列(如RabbitMQ)传递请求。例如,API Cell将虚拟机创建请求转发至目标子Cell的`nova-cells`服务,再由子Cell内部处理[^1]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值