openstack云計(jì)算cinder架構(gòu)及各組件功能是什么

這篇文章主要介紹“openstack云計(jì)算cinder架構(gòu)及各組件功能是什么”的相關(guān)知識(shí)，小編通過(guò)實(shí)際案例向大家展示操作過(guò)程，操作方法簡(jiǎn)單快捷，實(shí)用性強(qiáng)，希望這篇“openstack云計(jì)算cinder架構(gòu)及各組件功能是什么”文章能幫助大家解決問(wèn)題。

一 cinder各組件

1、cinder主要組成:

#cinder-api
#cinder-scheduler
#cinder-volume

2、cinder各組件功能：

Cinder-api 是 cinder 服務(wù)的 endpoint，提供 rest 接口，負(fù)責(zé)處理 client 請(qǐng)求，并將 RPC 請(qǐng)求發(fā)送至 cinder-scheduler 組件。

Cinder-scheduler 負(fù)責(zé) cinder 請(qǐng)求調(diào)度，其核心部分就是 scheduler_driver, 作為 scheduler manager 的 driver，負(fù)責(zé) cinder-volume 具體的調(diào)度處理，發(fā)送 cinder RPC 請(qǐng)求到選擇的 cinder-volume。

Cinder-volume 負(fù)責(zé)具體的 volume 請(qǐng)求處理，由不同后端存儲(chǔ)提供 volume 存儲(chǔ)空間。目前各大存儲(chǔ)廠商已經(jīng)積極地將存儲(chǔ)產(chǎn)品的 driver 貢獻(xiàn)到 cinder 社區(qū)

3、nova與cinder的工作原理類似

nova主要組成:

#nova-api
#nova-scheduler
#nova-compute
#nova-conductor

二 cinder架構(gòu)圖

openstack組件間通信:調(diào)用各組件api提供的rest接口，組件內(nèi)通信:基于rpc(遠(yuǎn)程過(guò)程調(diào)用)機(jī)制，而rpc機(jī)制是基于AMQP模型實(shí)現(xiàn)的

從rpc使用的角度出發(fā)，nova，neutron，和cinder的流程是相似的，我們以cinder為例闡述rpc機(jī)制

參考鏈接：https://developer.ibm.com/

三 RPC機(jī)制

Openstack 組件內(nèi)部的 RPC（Remote Producer Call）機(jī)制的實(shí)現(xiàn)是基于 AMQP(Advanced Message Queuing Protocol)作為通訊模型，從而滿足組件內(nèi)部的松耦合性。AMQP 是用于異步消息通訊的消息中間件協(xié)議

AMQP 模型有四個(gè)重要的角色:

Exchange：根據(jù) Routing key 轉(zhuǎn)發(fā)消息到對(duì)應(yīng)的 Message Queue 中

Routing key：用于 Exchange 判斷哪些消息需要發(fā)送對(duì)應(yīng)的 Message Queue

Publisher：消息發(fā)送者，將消息發(fā)送的 Exchange 并指明 Routing Key，以便 Message Queue 可以正確的收到消息

Consumer：消息接受者，從 Message Queue 獲取消息

消息發(fā)布者 Publisher 將 Message 發(fā)送給 Exchange 并且說(shuō)明 Routing Key。Exchange 負(fù)責(zé)根據(jù) Message 的 Routing Key 進(jìn)行路由，將 Message 正確地轉(zhuǎn)發(fā)給相應(yīng)的 Message Queue。監(jiān)聽(tīng)在 Message Queue 上的 Consumer 將會(huì)從 Queue 中讀取消息。

Routing Key 是 Exchange 轉(zhuǎn)發(fā)信息的依據(jù)，因此每個(gè)消息都有一個(gè) Routing Key 表明可以接受消息的目的地址，而每個(gè) Message Queue 都可以通過(guò)將自己想要接收的 Routing Key 告訴 Exchange 進(jìn)行 binding，這樣 Exchange 就可以將消息正確地轉(zhuǎn)發(fā)給相應(yīng)的 Message Queue。

Publisher可以分為4類：

• Direct Publisher發(fā)送點(diǎn)對(duì)點(diǎn)的消息；

• Topic Publisher采用“發(fā)布——訂閱”模式發(fā)送消息；

• Fanout Publisher發(fā)送廣播消息的發(fā)送；

• Notify Publisher同Topic Publisher，發(fā)送 Notification 相關(guān)的消息。

Exchange可以分為3類：

• 1.Direct Exchange根據(jù)Routing Key進(jìn)行精確匹配，只有對(duì)應(yīng)的 Message Queue 會(huì)接受到消息；

• 2.Topic Exchange根據(jù)Routing Key進(jìn)行模式匹配，只要符合模式匹配的Message Queue都會(huì)收到消息；

• 3.Fanout Exchange將消息轉(zhuǎn)發(fā)給所有綁定的Message Queue。

AMQP消息模型

RPC 發(fā)送請(qǐng)求

Client 端發(fā)送 RPC 請(qǐng)求由 publisher 發(fā)送消息并聲明消息地址，consumer 接收消息并進(jìn)行消息處理，如果需要消息應(yīng)答則返回處理請(qǐng)求的結(jié)果消息。

OpenStack RPC 模塊提供了 rpc.call，rpc.cast, rpc.fanout_cast 三種 RPC 調(diào)用方法，發(fā)送和接收 RPC 請(qǐng)求。

1.rpc.call 發(fā)送 RPC 請(qǐng)求并返回請(qǐng)求處理結(jié)果，請(qǐng)求處理流程如圖 5 所示，由 Topic Publisher 發(fā)送消息，Topic Exchange 根據(jù)消息地址進(jìn)行消息轉(zhuǎn)發(fā)至對(duì)應(yīng)的 Message Queue 中，Topic Consumer 監(jiān)聽(tīng) Message Queue，發(fā)現(xiàn)需要處理的消息則進(jìn)行消息處理，并由 Direct Publisher 將請(qǐng)求處理結(jié)果消息，請(qǐng)求發(fā)送方創(chuàng)建 Direct Consumer 監(jiān)聽(tīng)消息的返回結(jié)果

圖5.RPC.call消息流程

2.rpc.cast 發(fā)送 RPC 請(qǐng)求無(wú)返回，請(qǐng)求處理流程如圖 6 所示，與 rpc.call 不同之處在于，不需要請(qǐng)求處理結(jié)果的返回，因此沒(méi)有 Direct Publisher 和 Direct Consumer 處理。

圖 6. RPC.cast 消息流程

3.rpc.fanout_cast 用于發(fā)送 RPC 廣播信息無(wú)返回結(jié)果

圖 7. RPC.fanout 消息處理

關(guān)于“openstack云計(jì)算cinder架構(gòu)及各組件功能是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)，可以關(guān)注億速云行業(yè)資訊頻道，小編每天都會(huì)為大家更新不同的知識(shí)點(diǎn)。