創建 Image
本節演示如何通過 Web GUI 和 CLI 兩種方法創建 Image。
OpenStack 爲終端用戶提供了 Web UI(Horizon)和命令行 CLI 兩種交換界面。
兩種方式我們都要會用。
可能有些同學覺得既然有更友好的 Web UI 了,幹嘛還要用 CLI? 這裏 CloudMan 給出下面的理由:
1. Web UI 的功能沒有 CLI 全,有些操作只提供了 CLI。 即便是都有的功能,CLI 可以使用的參數更多
2. 一般來說,CLI 返回結果更快,操作起來更高效
3. CLI 可放在腳本中進行批處理
4. 有些耗時的操作 CLI 更合適,比如創建鏡像(後面將涉及)
Web UI 創建 p_w_picpath
1. admin 登錄後,Project -> Compute -> Images
2.點擊右上角按鈕,爲新 p_w_picpath 命名。
這裏我們上傳一個 p_w_picpath。 點擊,選擇鏡像文件 cirros-0.3.4-x86_64-disk.img。 cirros 是一個很小的 linux 鏡像,非常適合測試用。 大家可以到 http://download.cirros-cloud.net/ 下載。
3.格式選擇 QCOW2。
如果勾選,該 p_w_picpath 可以被其他 Project 使用 如果勾選,該 p_w_picpath 不允許被刪除。
4. 點擊,文件上傳到 OpenStack 並創建新的 p_w_picpath
5. 點擊 p_w_picpath 鏈接,顯示詳細信息
10.
CLI 創建 p_w_picpath
cirros 這個 linux 鏡像很小,通過 Web UI 上傳很快,操作會很順暢。 但如果我們要上傳的鏡像比較大(比如好幾個 G ),那麼操作會長時間停留在上傳的 Web 界面,我們也不知道目前到底處於什麼狀態。 對於這樣的操作,CLI 是更好的選擇。
1. 將 p_w_picpath 上傳到控制節點的文件系統中,例如 /tmp/cirros-0.3.4-x86_64-disk.img
2. 設置環境變量
Devstack 的安裝目錄下有個 openrc 文件。source 該文件就可以配置 CLI 的環境變量。這裏我們傳入了兩個參數,第一個參數是 OpenStack 用戶名 admin;第二個參數是 Project 名 admin
3. 執行 p_w_picpath 創建命令
glance p_w_picpath-create --name cirros --file /tmp/cirros-0.3.4-x86_64-disk.img --disk-format qcow2 --container-format bare --progress
在創建 p_w_picpath 的 CLI 參數中我們用 --progress 讓其顯示文件上傳的百分比 %,是不是比 Web UI更直觀呢?
在 /opt/stack/data/glance/p_w_picpaths/ 下查看新的 Image
使用 OpenStack CLI
本節首先討論 p_w_picpath 刪除操作,然後介紹 OpenStack CLI 的使用方法,最後討如何 Troubleshoot。
Web UI 刪除 p_w_picpath
1. admin 登錄後,Project -> Compute -> Images
在列表中選擇格式爲 ARI 和 AKI 的 p_w_picpath,點擊
2. 點擊確認刪除
3. 操作成功
CLI 刪除 p_w_picpath
1. 設置環境變量
2. 查詢現有p_w_picpath
3. 刪除p_w_picpath
如何使用 OpenStack CLI
OpenStack 服務都有自己的 CLI。 命令很好記,就是服務的名字,比如 Glance 就是 glance,Nova 就是 nova。
但 Keystone 比較特殊,現在是用 openstack 來代替老版的 keystone 命令。 比如查詢用戶列表,如果用 keystone user-list
會提示 keystone 已經 deprecated 了。 用 openstack 命令代替
不同服務用的命令雖然不同,但這些命令使用方式卻非常類似,可以舉一反三。
1. 執行命令之前,需要設置環境變量。
這些變量包含用戶名、Project、密碼等; 如果不設置,每次執行命令都必須設置相關的命令行參數
2. 各個服務的命令都有增、刪、改、查的操作
其格式是
CMD <obj>-create [parm1] [parm2]… CMD <obj>-delete [parm] CMD <obj>-update [parm1] [parm2]… CMD <obj>-list CMD <obj>-show [parm]
例如 glance 管理的是 p_w_picpath,那麼: CMD 就是 glance;obj 就是 p_w_picpath 對應的命令就有
glance p_w_picpath-create glance p_w_picpath-delete glance p_w_picpath-update glance p_w_picpath-list glance p_w_picpath-show
再比如 neutron 管理的是網絡和子網等,那麼: CMD 就是 neutron;obj 就是 net 和 subnet 對應的命令就有
網絡相關操作
neutron net-create neutron net -delete neutron net -update neutron net -list neutron net –show
子網相關操作
neutron subnet-create neutron subnet -delete neutron subnet -update neutron subnet -list neutron subnet–show
有的命令 <obj> 可以省略,比如 nova 下面的操作都是針對 instance
nova boot nova delete nova list nova show
3. 每個對象都有 ID
delete,show 等操作都以 ID 爲參數,例如
4. 可用 help 查看命令的用法
除了 delete,show 等操作只需要 ID 一個參數,其他操作可能需要更多的參數,用 help 查看所需的參數,格式是
CMD help [SUB-CMD]
例如查看 glance 都有哪些 SUB-CMD
查看 glance p_w_picpath-update 的用法
如何 Troubleshooting
OpenStack 排查問題的方法主要是通過日誌,Service 都有自己單獨的日誌。 Glance 主要有兩個日誌,glance_api.log 和 glance_registry.log,保存在 /var/log/apache2/ 目錄裏。
devstack 的 screen 窗口已經幫我們打開了這兩個日誌,可以直接查看
g-api 窗口顯示 glance-api 日誌,記錄 REST API 調用情況 g-reg 窗口顯示 glance-registry 日誌,記錄 Glance 服務處理請求的過程以及數據庫操作
如果需要得到最詳細的日誌信息,可以在 /etc/glance/*.conf 中打開 debug 選項。 devstack 默認已經打開了 debug。
在非 devstack 安裝中,日誌在 /var/log/glance/ 目錄裏。
理解 Nova 架構
Compute Service Nova 是 OpenStack 最核心的服務,負責維護和管理雲環境的計算資源。
OpenStack 作爲 IaaS 的雲操作系統,虛擬機生命週期管理也就是通過 Nova 來實現的。
在上圖中可以看到,Nova 處於 Openstak 架構的中心,其他組件都爲 Nova 提供支持:
Glance 爲 VM 提供 p_w_picpath
Cinder 和 Swift 分別爲 VM 提供塊存儲和對象存儲
Neutron 爲 VM 提供網絡連接
Nova 架構如下
Nova 的架構比較複雜,包含很多組件。
這些組件以子服務(後臺 deamon 進程)的形式運行,可以分爲以下幾類:
API
nova-api
接收和響應客戶的 API 調用。 除了提供 OpenStack 自己的API,nova-api 還支持 Amazon EC2 API。 也就是說,如果客戶以前使用 Amazon EC2,並且用 EC2 的 API 開發了些工具來管理虛機,那麼如果現在要換成 OpenStack,這些工具可以無縫遷移到 OpenStack,因爲 nova-api 兼容 EC2 API,無需做任何修改。
Compute Core
nova-scheduler
虛機調度服務,負責決定在哪個計算節點上運行虛機
nova-compute
管理虛機的核心服務,通過調用 Hypervisor API 實現虛機生命週期管理
Hypervisor
計算節點上跑的虛擬化管理程序,虛機管理最底層的程序。 不同虛擬化技術提供自己的 Hypervisor。 常用的 Hypervisor 有 KVM,Xen, VMWare 等
nova-conductor
nova-compute 經常需要更新數據庫,比如更新虛機的狀態。 出於安全性和伸縮性的考慮,nova-compute 並不會直接訪問數據庫,而是將這個任務委託給 nova-conductor,這個我們在後面會詳細討論。
Console Interface
nova-console
用戶可以通過多種方式訪問虛機的控制檯: nova-novncproxy,基於 Web 瀏覽器的 VNC 訪問 nova-spicehtml5proxy,基於 HTML5 瀏覽器的 SPICE 訪問 nova-x***vncproxy,基於 Java 客戶端的 VNC 訪問
nova-consoleauth
負責對訪問虛機控制檯請親提供 Token 認證
nova-cert
提供 x509 證書支持
Database
Nova 會有一些數據需要存放到數據庫中,一般使用 MySQL。 數據庫安裝在控制節點上。 Nova 使用命名爲 “nova” 的數據庫。
Message Queue
在前面我們瞭解到 Nova 包含衆多的子服務,這些子服務之間需要相互協調和通信。 爲解耦各個子服務,Nova 通過 Message Queue 作爲子服務的信息中轉站。 所以在架構圖上我們看到了子服務之間沒有直接的連線,它們都通過 Message Queue 聯繫。
OpenStack 默認是用 RabbitMQ 作爲 Message Queue。 MQ 是 OpenStack 的核心基礎組件,我們後面也會詳細介紹。