这篇文章主要为大家介绍了openstack云计算之cinder架构及各组件功能介绍,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
一 cinder各组件
1、cinder主要组成:
#cinder-api
#cinder-scheduler
#cinder-volume
2、cinder各组件功能:
Cinder-api
是 cinder 服务的 endpoint,提供 rest 接口,负责处理 client 请求,并将 RPC 请求发送至 cinder-scheduler 组件。
Cinder-scheduler
负责 cinder 请求调度,其核心部分就是 scheduler_driver, 作为 scheduler manager 的 driver,负责 cinder-volume 具体的调度处理,发送 cinder RPC 请求到选择的 cinder-volume。
Cinder-volume
负责具体的 volume 请求处理,由不同后端存储提供 volume 存储空间。目前各大存储厂商已经积极地将存储产品的 driver 贡献到 cinder 社区
3、nova与cinder的工作原理类似
nova主要组成:
#nova-api
#nova-scheduler
#nova-compute
#nova-conductor
二 cinder架构图
openstack组件间通信:调用各组件api提供的rest接口,组件内通信:基于rpc(远程过程调用)机制,而rpc机制是基于AMQP模型实现的
从rpc使用的角度出发,nova,neutron,和cinder的流程是相似的,我们以cinder为例阐述rpc机制
参考链接:https://developer.ibm.com/
三 RPC机制
Openstack 组件内部的 RPC(Remote Producer Call)机制的实现是基于 AMQP(Advanced Message Queuing Protocol)作为通讯模型,从而满足组件内部的松耦合性。AMQP 是用于异步消息通讯的消息中间件协议
AMQP 模型有四个重要的角色:
Exchange
:根据 Routing key 转发消息到对应的 Message Queue 中
Routing key
:用于 Exchange 判断哪些消息需要发送对应的 Message Queue
Publisher
:消息发送者,将消息发送的 Exchange 并指明 Routing Key,以便 Message Queue 可以正确的收到消息
Consumer
:消息接受者,从 Message Queue 获取消息
消息发布者 Publisher 将 Message 发送给 Exchange 并且说明 Routing Key。Exchange 负责根据 Message 的 Routing Key 进行路由,将 Message 正确地转发给相应的 Message Queue。监听在 Message Queue 上的 Consumer 将会从 Queue 中读取消息。
Routing Key 是 Exchange 转发信息的依据,因此每个消息都有一个 Routing Key 表明可以接受消息的目的地址,而每个 Message Queue 都可以通过将自己想要接收的 Routing Key 告诉 Exchange 进行 binding,这样 Exchange 就可以将消息正确地转发给相应的 Message Queue。
Publisher可以分为4类:
- Direct Publisher发送点对点的消息;
- Topic Publisher采用“发布——订阅”模式发送消息;
- Fanout Publisher发送广播消息的发送;
- Notify Publisher同Topic Publisher,发送 Notification 相关的消息。
Exchange可以分为3类:
- 1.Direct Exchange根据Routing Key进行精确匹配,只有对应的 Message Queue 会接受到消息;
- 2.Topic Exchange根据Routing Key进行模式匹配,只要符合模式匹配的Message Queue都会收到消息;
- 3.Fanout Exchange将消息转发给所有绑定的Message Queue。
AMQP消息模型
RPC 发送请求
Client 端发送 RPC 请求由 publisher 发送消息并声明消息地址,consumer 接收消息并进行消息处理,如果需要消息应答则返回处理请求的结果消息。
OpenStack RPC 模块提供了 rpc.call,rpc.cast, rpc.fanout_cast 三种 RPC 调用方法,发送和接收 RPC 请求。
1.rpc.call 发送 RPC 请求并返回请求处理结果,请求处理流程如图 5 所示,由 Topic Publisher 发送消息,Topic Exchange 根据消息地址进行消息转发至对应的 Message Queue 中,Topic Consumer 监听 Message Queue,发现需要处理的消息则进行消息处理,并由 Direct Publisher 将请求处理结果消息,请求发送方创建 Direct Consumer 监听消息的返回结果
图5.RPC.call消息流程
2.rpc.cast 发送 RPC 请求无返回,请求处理流程如图 6 所示,与 rpc.call 不同之处在于,不需要请求处理结果的返回,因此没有 Direct Publisher 和 Direct Consumer 处理。
图 6. RPC.cast 消息流程
3.rpc.fanout_cast 用于发送 RPC 广播信息无返回结果
图 7. RPC.fanout 消息处理
以上就是openstack云计算cinder架构及各组件功能介绍的详细内容,更多关于openstack云计算cinder架构组件的资料请关注编程学习网其它相关文章!
本文标题为:openstack云计算cinder架构及各组件功能介绍
基础教程推荐
- IIS 6 的 PHP 最佳配置方法 2022-09-01
- 实战Nginx_取代Apache的高性能Web服务器 2023-09-29
- Apache Hudi数据布局黑科技降低一半查询时间 2022-10-06
- centos 7 安装及配置zabbix agent 2023-09-24
- nginx.conf(centos7 1.14)主配置文件修改 2023-09-23
- Apache服务器配置攻略3 2022-09-01
- apache和nginx结合使用 2023-09-10
- 服务器添加git钩子的步骤 2022-12-12
- linux下安装apache与php;Apache+PHP+MySQL配置攻略 2023-08-07
- linux之conda环境安装全过程 2023-07-11