openstack云計算cinder架構及各組件功能是什么

這篇文章主要介紹“openstack云計算cinder架構及各組件功能是什么”的相關知識，小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“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架構及各組件功能是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識，可以關注億速云行業資訊頻道，小編每天都會為大家更新不同的知識點。