1. 程式人生 > >OpenStack基礎原理詳解

OpenStack基礎原理詳解

  OpenStack主要分為Nova.Glance.Swift,Cinder等,實際上是由一組離散服務組成的.儘管新元件更多的是面向業務的,但是OpenStack還是可以提供構建網路的基礎設施和執行通用虛擬機器的.OpenStack支援包括公有云,私有云,混合雲的部署方式,但OpenStack不是虛擬化,也不是雲,構建雲,我們還需要很多東西.那麼OpenStack是什麼呢?
  OpenStack是目前最主流的開源雲系統作業系統核心.

OpenStack三大元件

計算,網路,儲存

Nova

主要功能:

實現例項的生命週期的管理
調動管理平臺的網路、儲存等資源
提供了統一風格的 RestAPI介面
支援KVM、VMware等透明的hypervisor
各個模組之間通過訊息佇列來進行訊息傳遞

常用術語:

KVM:核心虛擬化,OpenStack預設的是Hypersvisor
Qemu:KVM的替補角色,沒有KVM效率高,不支援全虛擬化
Flavor:新建虛擬機器的配置列表,虛擬機器模板
Keypair:ssh連線訪問例項的金鑰對
安全組:用來控制例項訪問策略的容器
安全組規則:用來控制訪問的具體例項

Nova框架:

這裡寫圖片描述
Nova Api:提供統一rest-Api風格Api介面,作為Nova元件的入口,接受使用者的請求
Nova scheduler :負責排程,將例項分配到具體計算節點
Nova conductor:負責Nova與資料庫進行互動
Nova compute:用於虛擬機器例項的建立和管理
Message Queue:Nova各個元件之間的資訊傳遞

Nova工作原理:

這裡寫圖片描述
Nova api接受使用者的Cli命令或horizon建立例項請求,以訊息佇列的形式將請求傳送給Nova scheduler,Nova scheduler通過Nova conductor與資料庫進行互動,計算當前節點的負載及使用情況,將虛擬機器例項分配到當前節點負載最小且滿足啟動虛擬機器例項的節點上,而最終的例項還是要通過Nova compute來建立,而Nova compute將會與Nova volume、Nova network等等一些元件通過訊息佇列的方式實現相互的協作,最終完成虛擬機器例項的建立.

Swift

主要功能:

實現高可用分散式物件儲存
為Nova元件提供虛擬機器映象儲存
適用於網際網路應用場景下非結構化資料儲存

常用術語:

Account:使用者的管理儲存區域
Cnotainer:儲存隔間,類似於資料夾或目錄
Object:包含了基本的儲存實體和它本身的元資料
Ring:記錄了磁碟上儲存的實體名稱和物理位置對映關係
使用者可以建立多個Account,每個account裡可以建立多個容器container,每個container下可以建立多個object.【container 之間不能相互巢狀】
Region:地域,從地理位置上劃分的一個概念
Zone:可用區,按照獨立的供網,供電基礎設施劃分
Node:節點,儲存伺服器
Disk:磁碟,物理伺服器上的儲存裝置
Cluster:為冗餘考慮的部署架構
不同的region代表不同的城市,然後在同一個region下,為冗餘的考慮,設定了多個可用區,zone。每一個可用去可以有不同的儲存節點,node;在更大的架構上,兩個region可以構成一個cluster。

儲存特性

Swift在物理結構上往往會儲存物件的多個副本,通常按照物理位置的特點,將物件拷貝到不同哦奶粉的物理位置上,來保證資料的可靠性

Swift架構

這裡寫圖片描述
使用者提出一個物件儲存服務的申請,由Swift的API接受和處理,收到之後,先去找keyStore認證節點,對使用者的身份進行認證。認證通過後,將請求提交給名稱為Swift Proxy的元件,Swift Proxy是Swift 的代理,由Swift Proxy來確定究竟應該將儲存物件放在哪一個滿足儲存要求的儲存節點上。最終將返回結果返回給使用者。

KeyStone

主要功能:

提供身份驗證、服務規則和服務令牌功能
任何服務之間相互呼叫,都需要經過keystone的身份驗證

常用術語:

User:Openstack最基本的使用者
Project:指分配給使用者的資源的集合
Role:代表一組使用者可以訪問組員的許可權
Domain:定義管理邊界,可以包含多個project/tenant、user、role等
Endpoint:服務的URL路徑,暴露出來的訪問點
每個Domain對應多個Project,Project對應多個使用者,使用者可以跨Project存在

認證原理

這裡寫圖片描述
當用戶再建立時,將通過Keystone將會建立一個訪問令牌accesstoken,假設當用戶提出建立虛擬機器例項的請求時,首先將自己的訪問令牌和訪問請求提交給NOVE服務,NOVE服務為確保使用者的訪問令牌並沒有篡改過,因此首先會將訪問令牌交給keystone進行驗證,驗證通過後nova為了啟動虛擬機器的例項,還需要向Glance元件申請相關的映象資源,Glance為保證訪問令牌在傳遞的過程中沒有被篡改過,也需要將訪問令牌傳送給keystone做確認,驗證通過後將會發放映象資源給nova元件,虛擬機器例項的建立還需要儲存、網路等資源,因此nova元件還需要給負責各種資源的模組傳遞申請資源的請求,資源申請的過程中都會伴隨這訪問令牌的驗證,nova拿到啟動虛擬機器例項的所有資源後進行例項的啟動,然後分配給相關的使用者。整個過程來看元件之間資源的呼叫都離不開keystone的驗證….

Neutron

主要功能:

提供網路服務的核心元件
基於軟體定義網路的思想
實現軟體化的網路資源管理,在實現上,充分利用了linux系統中各種與網路相關的技術,支援第三方外掛

Neutron中常用的術語

Bridge-int:綜合網橋,常用於實現內部網路通訊功能的網橋
Br-ex:外部網橋,通常用於跟外部網路通訊的網橋。
Neutron-server:提供了API介面,將配置好的API介面,提供給相關的外掛,進行後續處理
Neutron-L2-agent:二層代理,用於實現二層網路通訊的代理,用於管理VLAN的外掛,接受Neutron-server的指令來建立VLAN。
Neutron-DHCP-agent:為子網自動分發IP地址
Neutron-L3-agent:負責租戶網路和floating IP之間的地址轉換,通過linux iptables 中的NAT功能來實現IP轉換
Neutron-metadata-agent:執行在網路節點上,用來響應nova中的metadata請求
LBaaS agent:為墮胎例項和open vswitch agent提供負載均衡服務

Neutron架構

這裡寫圖片描述
當Neutron通過API介面,接受來自使用者或者其他元件的網路請求時,以訊息佇列的方式提交給2、3層代理,其中Neutron-DHCP-agent實現子網的建立和IP地址的自動分發。而Neutron-L2-agent實現相同VLAN下,網路的通訊,Neutron-L3-agent實現同一個租戶網路下不同子網間的通訊

Glance

主要功能:

為Nova提供映象服務
通常不包括映象的本地儲存
實現對映象的管理

支援格式

Raw、vhd、vdi、iso、qcow2、aki ami

元件

Glance-api :負責提供映象服務的rest api服務
Glance-registry: 負責與glance使用的資料庫互動

Glance架構

這裡寫圖片描述
當有來自Cli命令或horizon傳送過來的映象請求,由Glance-api進行處理,傳遞給元件Glance-registry,然後到資料庫中查詢映象資訊,將查詢到的結果返回給使用者。接下來將會呼叫元件Glance-registry進行查詢,用來查詢後端的儲存,最終獲取映象返回給使用者。

Cinder

主要功能:

為虛擬機器例項提供volume卷的塊儲存服務
一個volume可以同時掛載到多個例項上
共享的卷同時只能被一個例項進行寫操作

支援檔案系統型別

LVM/ISCSI,NFS,NETAPP NFS,Gluster,DELL Equall Logic

常用術語

Volume備份:volume卷的備份
volume快照:某個時間點的狀態
Cinder Api :為Cinder請求提供統一風格的Rest Api服務
Cinder Scheduler:負責為新建卷指定塊儲存裝置
Cinder Volume:負責與儲存的塊裝置互動,實現卷操作
Cinder Backup:備份服務,負責通過後端和驅動的備份裝置打交道

Cinder架構

這裡寫圖片描述
使用者或者Nova提出請求,Cinder Api接收請求並通過訊息佇列的方式將請求提交給Cinder Scheduler來呼叫,Cinder Scheduler到資料庫中查詢,並通過相應策略選擇最佳Volume節點,將結果反饋給Scheduler Service呼叫,Service 通過Volume Providers建立相關的卷,並把結果反饋給使用者,同時,也會更新資料庫.

Ceilometer

主要功能:

為計費、監控等其他的服務提供資料支撐。

Ceilometer的核心概念

Ceilometer-agent-compute:執行在計算節點上,是收集計算節點上資訊的代理
Ceilometer-agent-central:執行在控制節點上,輪詢服務的非持續化資料
Ceilometer-collector:執行在一個或者多個控制節點上,監聽Message Bus【訊息匯流排】,將收到的資訊寫入到資料庫中
Storage:資料儲存,支援mongo DB,mysql等等。用於儲存收集到的樣本資料
API server:執行在控制節點上,提供對資料庫的資料的訪問
Message Bus:計量資料的訊息匯流排,收集資料給Ceilometer-collector

Ceilometer架構

這裡寫圖片描述
Ceilometer採用了兩種資料採集的方式,其中一種是消費了open stack內各個服務自動發出的notification訊息,【圖中的藍色箭頭】,另外一種是呼叫各個服務的API,去主動輪詢獲取資料。【圖中的黑色箭頭】

為什麼採用兩種資料採集的方式?

因為在open stack 中,大部分事件都會發出notification訊息,比如建立刪除instance例項的時候,這些計量計費的資訊時,都會發出notification訊息。而作為Ceilometer元件,就是notification訊息的最大的消費者。因此,第一種方式,是Ceilometer的首要的資料來源。
但是,也有一些計量的訊息,是notification獲取不到的,比如一些instance的CPU的執行時間,或者是CPU的使用率等等。因此,Ceilometer增加了第二種方式,即為週期性的呼叫相關的API,去輪詢這些訊息。

Heat

主要功能

OpenStack核心專案之一
提供基於模板的編排任務

常用術語:

這裡寫圖片描述

Heat元件

這裡寫圖片描述

Heat架構

這裡寫圖片描述
這裡寫圖片描述