Openstack (1) : 簡介

5月 01, 2019

關於Openstack

什麼是Openstack?

雲端運算類型

Openstack是一款雲端運算軟體，提供了雲端運算中的基礎設施即服務（IaaS）。

Openstack的起源：Openstack計劃是由美國航太總署(NASA)和Rackspace(世界第三大雲端服務供應商)於2010年共同發起，程式碼源自於NASA的Nebula platform以及Racksapce的Rackspace‘s Cloud Files platform，而後於2012年交由非營利組織Openstack Foundation繼續維護，為Apache license的open source cloud platform，有超過500家以上的公司參與這個計劃。

Openstack的宗旨："to produce a ubiquitous Open Source Cloud Computing platform that is easy to use, simple to implement, interoperable between deployments, works well at all scales, and meets the needs of users and operators of both public and private clouds"。(來源：Openstack官網)

Why Openstack?

成本節降：Openstack為開源軟體，可以大幅降低雲端服務業者部屬的成本
相容性及擴展性(Scalability)佳: Openstack相容於許多現有的技術，如存儲系統back-end、Hypervisor等
擺脫vendor的lock-in：理由同上，擺脫以往硬體設備綁定特定vendor軟體的問題
易於管理和維護: 維運人員可以透過Dashboard輕鬆的管理和維護，降低了人員訓練的複雜度和時間。

Openstack的版本(Release)

Openstack的命名方式是依照英文字母的順序，從第一版的Austin (A，2010年)到接下來的Train (T，2019年)，大約每半年發佈一版，如下圖所示：

Openstack版本分為5個status，每個版本都會依序進入這5個status：

Development：開發階段，此為Unstable branch，在這個階段之後都為Stable branch
Maintained：每個版本大約會持續維護18個月左右
Extended Maintenance：如果超過18個月還有需要繼續維護，就會展延，時間長短不一定
Unmaintained：在一個版本持續6個月沒有被維護之後就會進入EOL
End of Life (EOL)：進入這個status後，就會終止維護了

State	Time frame	Summary
Maintained	Approximately 18 months	All bugfixes (that meet the criteria described below) are appropriate. Releases produced.
Extended Maintenance	While there are community members maintaining it.	All bugfixes (that meet the criteria described below) are appropriate. No Releases produced, reduced CI commitment.
Unmaintained	6 months	The branch is under Extended Maintenance rules, but there are no maintainers
End of Life (EOL)	N/A	Branch no longer accepting changes

Openstack Distributions

詳細列表可參考：Commercial Distributions and Hardware Appliances of OpenStack

Openstack的架構

Overview

Openstack的projects有以下幾個：

Dashboard service：Horizon
Identity service：Keystone
Compute service：Nova
Image service：Glance
Network service：Neutron (以前叫做Quantum，更早以前是Nova-network)
Storage service：Cinder (Block storage)、Swift (Object storage)
Orchestration service：Heat
Telemetry service：Ceilometer

Openstack與AWS (Amazon Web Service)中Components的對應

Horizon → AWS Management Console
Keystone → AWS Identity and Access Management (IAM)
Nova → EC2
Glance → Amazon Machine Image (AMI)
Neutron → VPC、Amazon Route 53、Elastic Load Balancing (ELB)
Cinder → EBS
Swift → S3
更多Openstack和AWS的比較 → Public vs Private, Amazon compared to OpenStack

更細節的元件關係可以參考下面這張圖(來源)：

參考資料：

What Is OpenStack | OpenStack Tutorial For Beginners | OpenStack Training | Edureka

Horizon: Dashboard Service

Horizon是使用者操作介面，可以用瀏覽器開啟(如下圖所示)，可以對整個Openstack網絡進行控制和監控，只有Admin user可以看到左邊的Admin項目，這個項目有點像windows的Administrator使用者的管理項目，可以新增、刪除使用者，配置每個專案的資源、權限等等，關於Horizon的詳細說明，可以參考Openstack官網的說明。

Keystone: Authentication Service

Keystone的功能：

用戶(User)管理: 用戶的驗證
服務(Service)管理: 於某用戶/service欲使用某一服務時，會先向keystone進行認證，認證通過才可以使用某一服務

Terminology：

Domain: Domain可以當作是 project、user和group的namespace，為一個邏輯上的分割，同樣的user name、group name或project name可以出現在不同Domain中
Project:比較舊的版本稱作Tenant，為分配/切割資源的一個單位
User: 包含使用OpenStack雲端服務的人、系統、服務(如Nova)
Group: 包含了若干個Users的集合，方便Role的指派
Role: user或group的權限(類似於Linux中的普通user和sudoer)，用於將user或是group加入project，為globally的，在一個 keystone 管轄範圍內其名稱必須唯一
Authentication: User或service欲使用某一service時，會先向keystone發送Credentials進行認證，取得token後，再利用token繼續訪問openstack
Credentials(認證用): 如User name and password、API key、EC2 Credentials等
Token: 認證成功後會拿到，之後使用service時候都需出示的憑證，只有一段時間的效期，目的是為了增加安全性，如果User每次使用service時都出示user name和password會造成安全隱患。(Token有UUID tokens、PKI and PKIZ tokens、Fernet tokens等：Openstack Tokens)
Service: 如nova、cinder等
Region: 不同區域的openstack，但是他們可以共用一個Keystone和Horizon
Endpoints: service的子集(Regional)，為一個URL，user在認證成功後，除了會取得token以外，也會取得可以訪問(使用)的Endpoints位置，每個service都有三個類型的Endpoints

Admin (e.g. http://controller:35357/v3): Admin user才能訪問
Public (e.g. http://controller:5000/v3): 可以跨Region訪問
Internal (e.g. http://controller:5000/v3): 只有Region內的user可以訪問

範例: Launch一個Instance

Request Flow for Provisioning Instance in Openstack (來源)

The request flow for provisioning an Instance goes like this:

Dashboard or CLI gets the user credential and does the REST call to Keystone for authentication.
Keystone authenticate the credentials and generate & send back auth-token which will be used for sending request to other Components through REST-call.
Dashboard or CLI convert the new instance request specified in ‘launch instance’ or ‘nova-boot’ form to REST API request and send it to nova-api.
nova-api receive the request and sends the request for validation auth-token and access permission tokeystone.
Keystone validates the token and sends updated auth headers with roles and permissions.
nova-api interacts with nova-database.
Creates initial db entry for new instance.
nova-api sends the rpc.call request to nova-scheduler excepting to get updated instance entry with host ID specified.
nova-scheduler picks the request from the queue.
nova-scheduler interacts with nova-database to find an appropriate host via filtering and weighing.
Returns the updated instance entry with appropriate host ID after filtering and weighing.
nova-scheduler sends the rpc.cast request to nova-compute for ‘launching instance’ on appropriate host .
nova-compute picks the request from the queue.
nova-compute send the rpc.call request to nova-conductor to fetch the instance information such as host ID and flavor( Ram , CPU ,Disk).
nova-conductor picks the request from the queue.
nova-conductor interacts with nova-database.
Return the instance information.
nova-compute picks the instance information from the queue.
nova-compute does the REST call by passing auth-token to glance-api to get the Image URI by Image ID from glance and upload image from image storage.
glance-api validates the auth-token with keystone.
nova-compute get the image metadata.
nova-compute does the REST-call by passing auth-token to Network API to allocate and configure the network such that instance gets the IP address.
quantum-server validates the auth-token with keystone.
nova-compute get the network info.
nova-compute does the REST call by passing auth-token to Volume API to attach volumes to instance.
cinder-api validates the auth-token with keystone.
nova-compute gets the block storage info.
nova-compute generates data for hypervisor driver and executes request on Hypervisor( via libvirt or api).

The table represents the Instance state at various steps during the provisioning :

Status	Task	Power state	Steps
Build	scheduling	None	3-12
Build	networking	None	22-24
Build	block_device_mapping	None	25-27
Build	spawing	None	28
Active	none	Running

一些參考資料：

Nova

架構

上圖是Nova的架構圖，以下針對各個元件進行說明(其中的API和Message Queue也適用於Cinder、Heat等元件)：

nova-api

nova-api是nova對外唯一的接口，其他Openstack的元件僅能透過nova-api使用nova的服務(如透過Dashboard請求nova創建一個instance)，透過nova-api傳送進來的請求會進入Queue(AMQP)中，傳遞給nova中的其他服務(如nova-schedule、nova-compute等)。

nova-api可以支援Openstack API、Amazon EC2 API等，如下圖所示

Messages Queue (AMQP)

Openstack的RPC(Remote Producer Call)系統是基於AMQP(Advanced Message Queuing Protocol)協定，在Openstack中，基於AMQP的RPC backend有RabbitMQ、QPid、ZeroMQ等(預設是RabbitMQ)。然而，這些backend使用的參數和接口各異，不利於直接使用，於是Openstack發展出了oslo.messaging(由python函式庫kombu修改而成)這個函式庫，對這三種接口進行了包裝，形成統一的接口。

每一個Nova服務都會向AMQP註冊兩個項目：Node-Type跟Node-Type.Node Host，如compute向AMQP註冊compute以及compute.phantom，用rabbitmqctl list_queues name指令就可以查看AMQP上面的list，如下圖所示：

AMQP的運作模型可以分為兩種，分別是rpc.call(同部模式)和rpc.cast(非同部模式，廣播模式)，可以參考下面的兩張圖。Host分為兩種，Publisher和Consumer，分別是發送訊息和接收訊息的人。

rpc.call 運作流程

rpc.cast 運作流程

rpc.call和rpc.cast的差別在於，rpc.call的topic.host發出請求後，會產生一個Direct Consumer等待Woker那邊的Direct Publisher回應，而rpc.cast則是發出請求之後就繼續做其他事情，有點像TCP跟UDP的關係。

nova-schedule

用戶在創建instance時，會透過nova-api提出請求，請求中會包含了對資源需求，如CPU、Memory等，nova-schedule接收到請求後，會檢視所有運行nova-compute的host，並進行Filtering以及Weighting，挑選出合適的host創建instance：

Filtering：nova-schedule中有許多不同的filter，如CoreFilter、RamFilter等，nova-schedule透過這些filter替除掉不適合的host，接著進行在根據資源利用率進行Weighting

Weighting：上圖中的Weighting部分，依照目前資源的使用率(costs)，計算出各個host的weight，然後進行排序，決定出最適合部屬的host，並傳送請求給這個host的nova-compute，進行instance的佈署

nova-compute

nova-compute提供instance的佈署和運行，並透過libvirt支援QEMU、KVM、Xen等多種不同的Hypervisor(支援多種) 。

nova-conductor

一個介於service(nova-compute等)與database中間的間接程式，主要作用是避免nova-compute直接接觸database，增加系統的安全性

Placement API

Placement service是從14.0.0 Newton release後才加入的功能，將原本在nova-compute中記錄資源的功能(Nova Resource Tracker)抽離出來，成為一個獨立的API Endpoints，並擁有自己的database。

Placement 主要用於追蹤跟紀錄 Resource Provider 的 Inventory 和 Usage，並使用不同的 Resource Classes來標記資源類型，一個resource provider 可以是一個 compute node、一個 shared storage pool或者是一個 IP allocation pool。

nova vncproxy

nova-novncproxy：基於 Web 瀏覽器的 VNC 訪問 (如下圖所示)
nova-spicehtml5proxy：基於 HTML5 瀏覽器的 SPICE 訪問

nova-xvpnvncproxy：基於 Java 客戶端的 VNC 訪問

一些參考資料：

Compute

OpenStack Nova虚拟机创建流程解析

Message Queues

Placement API

Cinder: Block Storage

架構

Cinder架構圖

Cinder提供以下服務：

Volume的創建、刪除
Volume的snapshot以及lifecycle等管理
Volume的backup(透過Swift或是Ceph進行Object存儲)
支援多種back-end存儲，如LVM、NFS、Ceph等等(詳細列表) ，cinder-volume 為這些 volume provider 定義了統一的接口，volume provider 只需要實現這些接口，就可以 Driver 的形式即插即用到 OpenStack 系統中。

運作方式

Cinder運作方式

上圖是Cinder的運作方式，分為三個步驟：

cinder-volume service接收到由nova或是horizon傳來的請求，接著透過cinder-api對Storage device(實體儲存設備)發出建立volume的請求，並挑選適當的volume driver。
Volume建立完成後，nova-compute透過storage network運行storage protocol (如iSCSI、NFS、Ceph RBD、Fibre Channel等等)連結Compute host上的hypervisor和剛剛創立好的volume。
連結完後，hypervisor通知instance創建完成，接著這個instance就會認為他有一個實體的volume存在了，就像我們在電腦裡可以看到C槽或D槽。

Swift: Object Storage

Swift主要提供Volume等資料的object備份(更詳細的API請參考Openstack文件)

Swift除了提供volume的backup以外，也儲存其他如影片、email等資料，就像我們在google雲端硬碟上看到的檔案
Swift中所有Object都有至少三份的備份，用以提高可靠性

架構：

Proxy Server: 是Swift對外唯一的接口，負責和其他component(client)溝通，並將訊息轉送給Account、Object和Container server進行處理

Account Server: Swift中的Account並不是指帳戶，而是一堆container的集合
Container Server: Container可以想像成google drive裡面的資料夾，是使用者自行定義的儲存區域(Storage Area)
Object Server: 就是存放的資料(如volume)，包含了這個Object的metadata

Account、Container和Object的關係可以參考下面這張圖：

Glance

Glance架構圖

Glance提供以下幾個功能：

管理image，包含創建、刪除等
提供image的snapshot功能
支援Raw、VDI、QCOW2等image格式
和Cinder一樣支援Ceph等多種back-end

Neutron

架構

Neutron為Openstack提供了網路的服務，Neutron分為以下幾個部分：

neutron server (neutron-server and neutron-*-plugin)：neutron-server和各種neutron-*-plugin插件可以佈建於controller node或network node上，用於接受API傳送過來的命令(如新增/刪除一個Router)，接著透過RPC向Agent發出請求以完成命令，和其他Nova等元件一樣，這些命令會通過AMQP Queue分派傳送給各Agent。
Core plugin / Agent：包含了network、subnet、port等的管理

plugin agent (neutron-*-agent)：佈署在compute node或network node上，用來處理server發送過來的請求，管理net、subnet、port等配置。

Service plugin / Agent：管理更高級的網絡服務。

DHCP agent (neutron-dhcp-agent)：佈署在network node上，用來對Tenant以及其他plugin提供DHCP服務。
L3 agent (neutron-l3-agent)：佈署在network node上，為用戶提供外網L3/NAT轉發的服務。

network provider services (SDN server/services)：一些額外的網路服務，如SDN service利用Rest APIs和neutron-server、neutron-plugin以及plugin-agents溝通。

ML2 Plugin

以往的plugin和agent是一對一對應的，Core plugin負責管理和維護network,、subnet 和 port等的狀態，這些狀態只需要也只能由一個core plugin管理。也就是說，如果挑了一間廠商的agent，則其對應的plugin也就被綁定了，這樣就無法支援不同廠商的agent，為了解決這個問題，openstack開發了ML2 Plugin，提供統一的管理，並兼容所有現存的agent，以後只要一個ML2 Plugin就能支援各種不同廠商提供的agent了。

實機部屬範例

以下是一個標準(非絕對)的Openstack配置方式範例，一共使用了三台實體機器(或VM)。

Controller Node：部屬了neutron-server
Network Node：部屬了core plugin的agent (圖上的neutron-plugin-agent)和service plugin的agent (如neutron-DHCP-agent和neutron-L3-agent)
Compute Node：部屬了core plugin的agent (圖上的neutron-plugin-agent)

一些參考資料：

Neutron 架构 - 每天5分钟玩转 OpenStack（67）

Heat

Heat為Openstack提供了Orchestration的服務。

一些參考資料：

Ceilometer

Ceilometer提供以下功能：

Metering(計量): 蒐集資源使用的資訊，包含使用對象(what)、使用者(who)、使用時間(when)、用量(how much)
Rating(計費): 將Metring的資料用量透過營運商的收費金額(policy)做計算
Billing(開票): 產生帳單

Ceilometer運作方式(圖片來源)

搜尋此網誌

藍天的自由之路