磨刀不誤砍柴工,OpenStack核心服務詳解(上)

前言

本文主要介紹了OpenStack的界面管理、認證管理和鏡像管理。

OpenStack操作界面管理

OpenStack操作界面服務Horizon提供基於Web的控制界面,是雲管理員和用戶能夠管理各種OpenStack資源和服務。
從Horizon着手學習OpenStack,快速瞭解OpenStack全貌,爲學習OpenStack技術細節打下紮實基礎。

OpenStack操作界面服務Horizon簡介

OpenStack操作界面Horizon

  • Horizon
    操作界面
    首次出現在OpenStack的"Essex"版本中
  • 簡介
    Horizon提供基於Web的控制界面,使雲管理員和用戶能夠管理各種OpenStack資源和服務。
  • 依賴的OpenStack服務
    Horizon唯一依賴的服務是Keystone認證服務。
    Horizon可以與其他服務結合使用,例如鏡像服務,計算服務和網絡服務。
    Horizon還可以在有獨立服務(如對象存儲)的環境中使用。

Horizon在OpenStack中的位置和作用
Horizon主要提供基於Web的OpenStack控制界面,使雲管理員和用戶能夠管理各種OpenStack資源和服務。
Horizon在OpenStack中的位置和作用
Horizon項目開發思想
Horizon項目開發思想

OpenStack操作界面服務Horizon功能

OpenStack Horizon界面

Project

Project界面提供租戶可以管理的資源,例如計算、存儲、網絡等。
Project

Admin

Admin界面提供管理員可以管理的資源,例如計算、存儲、網絡和系統設置等。
Admin

Identity

Identity界面提供認證管理功能。
Identity

Settings

Settings界面提供操作界面配置功能
Settings

OpenStack認證管理

Keystone爲OpenStack提供共用的認證與鑑權機制,在整個OpenStack中佔有舉足輕重的地位。

OpenStack認證服務Keystone簡介

OpenStack認證服務Keystone

  • Keystone
    認證服務
    首次出現在OpenStack的“Essex”版本中。
  • 簡介
    Keystone提供身份驗證,任務發現和分佈式多租戶授權。
    Keystone支持LDAP,OAuth,OpenID Connect,SAML和SQL。
  • 依賴的OpenStack服務
    Keystone爲其他項目提供認證。
    外部請求調用OpenStack內部的服務時,需要先從Keystone獲取到相應的Token。
    類似的,OpenStack內部不用項目間的調用也需要先從Keystone獲取到認證後才能進行。
    Keystone在OpenStack中的位置
    Keystone提供身份驗證,任務發現和分佈式多租戶授權,屬於共用服務。
    Keystone在OpenStack中的位置
    Keystone在OpenStack中的作用
    Keystone在OpenStack中的作用

Keystone架構

Keystone架構圖
Keystone架構圖
Keystone服務包括如下組件:

  • Keystone API
    接收外部請求
  • Keystone Middleware
    緩存Token等,減輕Keystone Services壓力
  • Keystone Services
    不同的Services提供不同的認證或鑑權服務
  • Keystone Backends
    實現Keystone服務,不同的Services由不同的Backends提供
  • Keystone Plugins
    提供密碼、Token等認證方式

Keystone對象模型

Keystone的管理主要是針對Identity,Resource,Assignment,Token,Catalog,Service,這些對象具體由其他更小的對象實現。
同時OpenStack各種資源和服務的訪問策略由Policy定義。
Keystone對象模型

Service

  • Keystone是在一個或多個端點(Endpoint)上公開的一組內部服務(Service)
  • Keystone內部服務包括Identity、Resource、Assignment、Token、Catalog等。
  • Keystone許多內部服務以組合方式使用。
    例如,身份驗證時將使用認證服務(Identity)驗證用戶或項目證據,並在成功時創建並返回帶有令牌服務(Token)的令牌。
    身份驗證
  • 除內部服務外,Keystone還負責與OpenStack其他服務(Service)進行交互,例如計算、存儲或鏡像,提供一個或多個端點,用戶可以通過這些端點訪問資源並執行操作。

Identity

  • Identity服務提供身份憑據驗證以及用戶(User)和用戶組(Group)的數據。
    Identity
  • User是單個OpenStack服務使用者,用戶本身必須屬於某個特定域。所有用戶名不是OpenStack全局唯一的,僅在其所屬域唯一。
  • Groups把多個用戶作爲一個整體進行管理。組本身必須屬於某個特定域。所有組名不是OpenStack全局唯一的,僅在其所屬域唯一。
  • 通常情況下,用戶和用戶組數據由Identity服務管理,允許它處理與這些數據關聯的所有CRUD操作。
  • 複雜情況下,用戶和用戶組數據由權威後端服務管理。
    • 例如,Identity充當LDAP的前端,LDAP服務器是權威的信息來源,Identity準確地中繼LDAP信息。

Resource

  • Resource服務提供有關項目(Project)和域(Domain)的數據。
    Resource
  • Project是OpenStack資源擁有者的基本單元,OpenStack中所有資源都屬於特定項目。
  • Domain把項目、用戶和組作爲一個整體管理,每種資源都屬於某個特定域。Keystone默認域名爲“Default”。
  • 項目本身必須屬於某個特定域。所有項目名不是OpenStack全局位移的,僅在其所屬域唯一。
  • 創建項目時如果未指定域,則將其添加到默認域。

Assignment

  • Assignment服務提供有關角色(Role)和角色分配(Role Assignment)的數據
    Assignment
  • Role規定最終用戶可以獲得的授權級別。角色可以在域或項目級別授予。可以在單個用戶或組級別分配角色。角色名稱在擁有該角色的域中是唯一的。
  • Role Assignment是一個3元組,有一個Role,一個Resource和一個Identity。

Token

  • Token服務提供用戶訪問服務的憑證,代表着用戶的賬戶信息。
  • Token一般包含User信息、Scope信息(Project、Domain或者Trust)、Role信息。
  • Token如果未包括Scope,即Unscoped Token,這種Token中既不包含服務目錄,也不包含任何角色,項目範圍和域範圍。它的主要作用是稍後向Keystone證明身份(通常是生成範圍標記),而不用重複提交原始憑據。
  • 必須滿足以下條件才能接收Unscoped Token:
    • 身份驗證請求中未指定授權範圍(例如,在命令中使用–os-project-name或等參數–os-domain-id)。
    • 身份沒有與之關聯的“默認項目”,還未分配角色,因此也需要授權。
      Token

Catalog

  • Catalog服務提供用於查詢端點(Endpoint)的端點註冊表,以便外部訪問OpenStack服務。
  • Endpoint本質上是一個URL提供服務的入口,有如下幾種:
    • Public:最終用戶或其他服務用戶使用,通常在公共網絡接口上使用。
    • Internal:供最終用戶使用,通常在未計量的內部網絡接口上。
    • Admin:供管理服務的用戶使用,通常是在安全的網絡接口上。
      Catalog

Policy

  • 每個OpenStack服務都在相關的策略文件中定義其資源的訪問策略(Policy)。
  • 訪問策略類似於Linux中的權限管理,不同角色的用戶或用戶組將會擁有不同的操作權限。
    Policy
  • 訪問策略規則以JSON格式制定,文件名爲policy.json
    策略文件的路徑是/etc/SERVICE_NAME/policy.json,例如/etc/keystone/policy.json。

Keystone對象模型示例

Region>Domain>Project>Group>User
用戶提交用戶名、密碼後,Keystone驗證後生成Token,操作OpenStack服務的請求必須攜帶Token,通過端點URL訪問服務。
Keystone對象模型示例
Region,Service,Endpoint:
Catalog中包含不同Region中的不同Service,每個Service一般有不同類型的Endpoint。
Keystone對象模型示例

  • User:
    • 獲取Token
    • 獲取Service Catalog
  • Admin User:
    • 管理Users,Projects,Roles
    • 管理特定Project中Users的Roles
    • 管理Services,Services的Endpoint
  • Service:
    • 驗證Token
    • 定位其他Service的位置
    • 調用其他Service

Keystone認證工作原理和流程

Keystone認證方式概覽

Keystone最重要的工作是認證,Keystone支持多種認證方式。
Keystone的認證方式概覽

  • UUID:Universal Unique Indentifier
  • PKI:Public Key Infrastructure

Keystone三種認證方式對比

  • 基於令牌的認證方式(生產環境環境中常用,需要重點學習)
    • 最常用的Keystone認證方式,使用方式簡單。
    • 認證請求發送時添加一個“X-Auth-Token”的HTTP頭,Keystone檢查該HTTP頭中的Token值,並與數據庫中的令牌值進行對比驗證。
  • 基於外部的認證方式
    • 集成使用第三方驗證系統,在認證請求中添加“REMOTE_USER”信息。
  • 基於本地的認證方式
    • 默認認證方式,即用戶名和密碼認證。

基於令牌的認證

UUID

  • UUID令牌是長度固定爲32Byte的隨機字符串,但是UUID令牌不攜帶其他信息,OpenStack API收到該令牌後,需要找Keystone校驗令牌,並獲取用戶相關信息。
  • UUID不攜帶其他信息,因此Keystone必須實現令牌的存儲和認證,集羣規模擴大時,Keystone將成爲性能瓶頸。
    UUID

PKI

  • PKI的本質就是基於數字簽名,Keystone私鑰對令牌進行數字簽名,各個OpenStack服務的API server用公鑰在本地驗證該令牌。
  • 和UUID相比,PKI令牌攜帶更多用戶信息的同時還附上了數字簽名,以支持本地認證,從而避免多次找Keystone認證。但因爲攜帶更多信息,當OpenStack規模較大時,PKI令牌大小容易超出HTTP Header大小,導致請求失敗。
    PKI

PKIZ

  • PKIZ在PKI的基礎上做了壓縮處理但是壓縮的效果極其有限。
  • 一般情況下,壓縮後的大小爲PKI Token的90%左右,所以PKIZ不能友好的解決token size太大的問題。
    PKIZ

Fernet

  • UUID,PKI,PKIZ令牌都會持久存放在數據庫中,積累的令牌容易導致數據庫性能下降,用戶需定期清理數據庫中的令牌。
  • 爲避免該問題,OpenStack目前版本都默認使用Fernet令牌,攜帶少量的用戶信息,採用對稱加密,無需存於數據庫中,但需定期更換祕鑰。
    Fernet

如何選擇Keystone基於令牌的認證方式?

目前OpenStack新發布版本默認採用Fernet令牌。

令牌類型的選擇涉及多個因素,包括Keystone server的負載、region數量、安全因素、維護成本以及令牌本身的成熟度。

  • Region的數量影響PKI/PKIZ令牌的大小。
  • 從安全的角度上看,UUID無需維護祕鑰,PKI需要妥善保管Keystone Server上的私鑰,Fernet需要週期性的更換祕鑰。
  • 因此從安全、維護成本和成熟度上看,UUID>PKI/PKIZ>Fernet。

如果,

  • Keystone server負載低,region少於3個,採用UUID令牌。
  • Keystone server負載高,region少於3個,採用PKI/PKIZ令牌。
  • Keystone server負載低,region大於或等於3個,採用UUID令牌。
  • Keystone server負載高,region大於或等於3個,目前OpenStack新版本默認採用Fernet令牌。
    如何選擇Keystone基於令牌的認證方式

OpenStack認證流程-以創建VM爲例

不同服務間的調用需要攜帶Token,Keystone負責驗證Token有效性。
創建VM

RBAC:基於角色的訪問控制

流程

Policy.json文件是實現RBAC(基於角色的訪問控制)的關鍵機制。
RBAC流程

原理

Policy模塊在檢測時需要三方面的數據:

  1. policy.json策略配置文件
  2. auth_token添加到http頭部的token數據
  3. 用戶的請求數據

RBAC原理
示例的policy.json說明:

  • 定義了all_admins包含哪些角色
  • 定義了list project針對all_admins的具體規則,create project時需要admin角色。

Keystone如何實現認證和權限控制

流程圖簡單演示用戶創建虛擬機的過程中,Keystone是如何發放Token,驗證Token及權限控制的過程。
Keystone如何實現認證和權限控制

OpenStack動手實驗:Keystone操作

  • 命令help
  • 角色管理
  • 用戶與用戶組管理
  • 域如何與項目、角色、用戶和用戶組一起使用
  • 項目管理
  • 配額管理
  • 服務管理

OpenStack鏡像管理

Glance提供鏡像服務,是OpenStack的基礎服務,創建虛擬機實例時離不開鏡像服務。

OpenStack鏡像服務Glance簡介

鏡像服務Glance

  • Glance
    鏡像服務
    首次出現在OpenStack的“Bexar”版本中。
  • 簡介
    Glance提供發現、註冊和檢索虛擬機鏡像功能。
    Glance提供的虛擬機實例鏡像可以存放在不同地方,例如本地文件系統、Swift對象存儲、Cinder塊存儲等。
  • 依賴的OpenStack服務
    Keystone

鏡像服務在OpenStack中的位置和作用
Glance提供發現、註冊和檢索虛擬機鏡像功能,編寫時遵循高可用、可恢復和高容錯的原則。
鏡像服務在OpenStack中的位置和作用

Glance架構

Glance使用C/S架構,提供REST API,用戶可以通過API執行對服務器的請求。
Glance架構

Glance組件詳解

  • Client
    glance-agent,使用glance服務器的任何應用程序,接收請求並調用glance-api。
  • REST API
    glance-api,通過REST接口對外開放Glance功能,接收請求。
  • Glance Domain Controller
    管理Glance內部服務器,Glance Domain Controller分層實現特定任務,如認證、事件通知、策略控制和數據庫連接等。
  • Registry Layer
    實現Glance Domain Controller與DAL之間的安全訪問。
  • Database Abstraction Layer(DAL)-數據庫抽象層
    提供Glance與數據庫之間的統一API接口。
  • Glance DB
    Glance DB在所有組件之間共享,存放管理、配置信息等數據。
  • Glance Store
    負責與外部存儲後端或本地文件系統的交互,持久化存儲鏡像文件。
    Glance Store提供一個統一的接口來訪問後端存儲,屏蔽不同後端存儲的差異。

Glance工作原理和流程

OpenStack中的鏡像、實例和規格

  • 鏡像Image
    虛擬機鏡像包含一個虛擬磁盤,其上包含可引導的操作系統,爲虛擬機提供模版。
  • 實例Instance
    實例是在OpenStack上運行的虛擬機。
  • 規格Flavor
    規格定義了實例可以有多少個虛擬CPU,多大的RAM以及多大的臨時磁盤。
  • 鏡像、實例和規格的關係
    • 用戶可以從同一個鏡像啓動任意數量的實例。
    • 每個啓動的實例都是基於鏡像的一個副本,實例上的任何修改都不會影響到鏡像。
    • 啓動實例時,必須指定一個規格,實例按照規格使用資源。
    • 創建實例時,必須指定鏡像和規格。

Glance鏡像磁盤格式

將鏡像添加到Glance時,必須指定虛擬機鏡像的磁盤格式。
Glance鏡像磁盤格式

Glance狀態機

Glance中有兩種狀態機:鏡像狀態和任務狀態。
Glance狀態機

Glance狀態機的轉化

轉化圖

Glance鏡像緩存

  • 鏡像緩存:在API節點本地存放原始鏡像的一個副本,實質上使多個API服務器能夠提供相同的鏡像。由於提供鏡像的服務器數量增加,提升了鏡像服務的可伸縮性。
  • 控制cache總量的大小
    • 週期性清理
      週期運行glance-cache-pruner
    • 清理image cache
      通過glance-cache-cleaner清理狀態異常的cache文件
    • 預取某些熱門鏡像到新增的api節點中
      glance-cache-manage – host=<HOST> queue-image <IMAGE_ID>
    • 手動刪除image cache來釋放空間
      glance-cache-manage – host=<HOST> delete-cached-image <IMAGE_ID>
  • 鏡像緩存機制對終端用戶來說是透明的,也就是說終端用戶不會清楚從Glance服務獲取的鏡像文件的真實來源。

鏡像與實例交互流程

實例啓動前

Glance store包含一定數量的鏡像,計算節點包含可用的vCPU,內存和本地磁盤資源,Cinder-volume包含一定數量的卷。
實例啓動前

實例從鏡像啓動

  • 啓動實例時,需要選擇一個鏡像,規格和任何可選屬性。選定的規格提供一個系統盤,標記爲vda,另外一個臨時盤被標記爲vdb,cinder-volume提供的卷被映射到第三個虛擬磁盤並將其稱爲vdc。
  • 鏡像服務將基本鏡像從鏡像存儲複製到本地磁盤。vda是實例訪問的第一個磁盤。如果鏡像文件越小,則通過網絡複製的數據越少,實例啓動就會越快。
  • 實例啓動時還會創建一塊空的臨時磁盤vdb,刪除實例時將刪除此磁盤。
  • 計算節點使用iSCSI連接到cinder-volume提供的某個卷。該卷被映射到第三個磁盤vdc。計算節點爲實例提供vCPU和內存資源後,實例將從根卷vda啓動。該實例運行並更改磁盤上的數據(圖中紅色標識磁盤)。
  • 如果cinder-volume位於單獨的網絡上,則存儲節點配置文件中my_block_storage_ip選項會將鏡像流量定向到計算節點。
  • 注意:
    此示例場景中的某些詳細信息可能與實際環境不同。例如,可以使用不同類型的後端存儲或不同的網絡協議。常見的一種場景是vda,vdb存放在SAN存儲,而不是本地磁盤上。
    實例從鏡像啓動

實例刪除後

實例被刪除後,除cinder-volume卷之外的其他資源都會被回收。臨時磁盤無論是否加密過,都將會被清空,內存和vCPU資源將會被釋放。在這個過程中鏡像不會發生任何改變。
注意:如果創建實例時選擇了“刪除實例時刪除卷”,則實例刪除時,cinder-volume卷也會被刪除。
實例刪除後

鏡像製作

直接下載鏡像文件

最簡單的Glance鏡像製作方法是下載系統供應商官方發佈的OpenStack鏡像文件。大多數鏡像預安裝了Cloud-init包,支持SSH祕鑰對登錄和用戶數據注入功能。
直接下載鏡像文件

手動製作鏡像

  • 如果直接下載的鏡像不符合要求,可以手動製作Glance鏡像文件。
  • 以製作Ubuntu 18.04爲例:
    • 使用virt-manager創建一個Ubuntu 18.04虛擬機並安裝系統
    • 登陸虛擬機並安裝cloud-init $ sudo apt install cloud-init
    • 虛擬機內部,停止虛擬機 $ sudo shutdown -h now
    • 預清理虛擬機 $ sudo virt-sysprep -d VM_ID
    • 釋放虛擬機定義 $ virsh undefine VM_ID
    • 製作鏡像 $ qemu-img create
    • 上傳鏡像 $ openstack image create

virt-manager是一套圖形化的虛擬機管理工具,提供虛擬機管理的基本功能,如開機,掛起,關機,強制關機/重啓,遷移等。

常用工具

鏡像製作工具

  • Diskimage-builder
    • 自動化磁盤映像創建工具,可以製作Fedora,Red Hat Enterprise Linux,Ubuntu,Debian,CentOS和openSUSE鏡像。
    • 示例:$ disk-image-create ubuntu vm
  • Packer
    使用Packer製作的鏡像,可以適配到不同的雲平臺,適合使用多個雲平臺的用戶。
  • virt-builder
    快速創建新虛擬機的工具,可以在幾分鐘或者更短的時間內創建各種用於本地或雲用途的虛擬機鏡像。

鏡像轉換

  • 命令行qemu-img convert
$ qemu-img convert -f raw -O qcow2 image.img image.qcow2
  • VBoxManage: VDI(VirtualBox)轉換爲RAW
$ VBoxManage clonehd image.vdi image.img --format raw

OpenStack動手實驗:Glance操作

  • 命令help
  • 下載Cirros鏡像
  • 鏡像創建
  • 鏡像修改
  • 鏡像註冊
  • 鏡像共享
  • 鏡像轉換
  • 導出鏡像
  • 鏡像刪除
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章