雲計算與openstack學習(七)

創建 Image 

p_w_picpath106.5.png

本節演示如何通過 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

upload-ueditor-p_w_picpath-20160414-1460643895


2.點擊右上角upload-ueditor-p_w_picpath-20160414-1460643895按鈕,爲新 p_w_picpath 命名。
upload-ueditor-p_w_picpath-20160414-1460643896
這裏我們上傳一個 p_w_picpath。 點擊upload-ueditor-p_w_picpath-20160414-1460643896,選擇鏡像文件 cirros-0.3.4-x86_64-disk.img。 cirros 是一個很小的 linux 鏡像,非常適合測試用。 大家可以到 http://download.cirros-cloud.net/ 下載。

3.格式選擇 QCOW2。
upload-ueditor-p_w_picpath-20160414-1460643896
如果勾選upload-ueditor-p_w_picpath-20160414-1460643896,該 p_w_picpath 可以被其他 Project 使用 如果勾選upload-ueditor-p_w_picpath-20160414-1460643896,該 p_w_picpath 不允許被刪除。 

4. 點擊upload-ueditor-p_w_picpath-20160414-1460643897,文件上傳到 OpenStack 並創建新的 p_w_picpath

upload-ueditor-p_w_picpath-20160414-1460643897

5. 點擊 p_w_picpath 鏈接upload-ueditor-p_w_picpath-20160414-1460643897,顯示詳細信息

upload-ueditor-p_w_picpath-20160414-1460643897

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. 設置環境變量

upload-ueditor-p_w_picpath-20160414-1460643897
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 

upload-ueditor-p_w_picpath-20160414-1460643897

在創建 p_w_picpath 的 CLI 參數中我們用 --progress 讓其顯示文件上傳的百分比 %,是不是比 Web UI更直觀呢? 

在 /opt/stack/data/glance/p_w_picpaths/ 下查看新的 Image
upload-ueditor-p_w_picpath-20160414-1460643898

 

使用 OpenStack CLI 

p_w_picpath120.5.pngupload-ueditor-p_w_picpath-20160417-1460901196

 

本節首先討論 p_w_picpath 刪除操作,然後介紹 OpenStack CLI 的使用方法,最後討如何 Troubleshoot。

Web UI 刪除 p_w_picpath

1. admin 登錄後,Project -> Compute -> Images

upload-ueditor-p_w_picpath-20160417-1460901196
在列表中選擇格式爲 ARI 和 AKI 的 p_w_picpath,點擊upload-ueditor-p_w_picpath-20160417-1460901196
upload-ueditor-p_w_picpath-20160417-1460901196

2. 點擊upload-ueditor-p_w_picpath-20160417-1460901196確認刪除 

3. 操作成功

upload-ueditor-p_w_picpath-20160417-1460901197

CLI 刪除 p_w_picpath

1. 設置環境變量

p_w_picpath118.png

2. 查詢現有p_w_picpath

upload-ueditor-p_w_picpath-20160417-1460901197
3. 刪除p_w_picpath

upload-ueditor-p_w_picpath-20160417-1460901197

如何使用 OpenStack CLI

OpenStack 服務都有自己的 CLI。 命令很好記,就是服務的名字,比如 Glance 就是 glance,Nova 就是 nova。 

但 Keystone 比較特殊,現在是用 openstack 來代替老版的 keystone 命令。 比如查詢用戶列表,如果用 keystone user-list 

upload-ueditor-p_w_picpath-20160417-1460901197

會提示 keystone 已經 deprecated 了。 用 openstack 命令代替 

upload-ueditor-p_w_picpath-20160417-1460901198

不同服務用的命令雖然不同,但這些命令使用方式卻非常類似,可以舉一反三。 

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 爲參數,例如 

upload-ueditor-p_w_picpath-20160417-1460901198

4. 可用 help 查看命令的用法 

除了 delete,show 等操作只需要 ID 一個參數,其他操作可能需要更多的參數,用 help 查看所需的參數,格式是 

CMD help [SUB-CMD] 

例如查看 glance 都有哪些 SUB-CMD 

upload-ueditor-p_w_picpath-20160417-1460901198

查看 glance p_w_picpath-update 的用法 

upload-ueditor-p_w_picpath-20160417-1460901198

如何 Troubleshooting

OpenStack 排查問題的方法主要是通過日誌,Service 都有自己單獨的日誌。 Glance 主要有兩個日誌,glance_api.log 和 glance_registry.log,保存在 /var/log/apache2/ 目錄裏。 

devstack 的 screen 窗口已經幫我們打開了這兩個日誌,可以直接查看 

upload-ueditor-p_w_picpath-20160417-1460901198

g-api 窗口顯示 glance-api 日誌,記錄 REST API 調用情況 g-reg 窗口顯示 glance-registry 日誌,記錄 Glance 服務處理請求的過程以及數據庫操作 

如果需要得到最詳細的日誌信息,可以在 /etc/glance/*.conf 中打開 debug 選項。 devstack 默認已經打開了 debug。 

upload-ueditor-p_w_picpath-20160417-1460901198

在非 devstack 安裝中,日誌在 /var/log/glance/ 目錄裏。

 理解 Nova 架構 

p_w_picpath135.5.png

Compute Service Nova 是 OpenStack 最核心的服務,負責維護和管理雲環境的計算資源。 
OpenStack 作爲 IaaS 的雲操作系統,虛擬機生命週期管理也就是通過 Nova 來實現的。

p_w_picpath47.png

在上圖中可以看到,Nova 處於 Openstak 架構的中心,其他組件都爲 Nova 提供支持:
Glance 爲 VM 提供 p_w_picpath 
Cinder 和 Swift 分別爲 VM 提供塊存儲和對象存儲 
Neutron 爲 VM 提供網絡連接

Nova 架構如下

p_w_picpath136.png

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” 的數據庫。 

p_w_picpath137.png

Message Queue

在前面我們瞭解到 Nova 包含衆多的子服務,這些子服務之間需要相互協調和通信。 爲解耦各個子服務,Nova 通過 Message Queue 作爲子服務的信息中轉站。 所以在架構圖上我們看到了子服務之間沒有直接的連線,它們都通過 Message Queue 聯繫。 

p_w_picpath138.png

OpenStack 默認是用 RabbitMQ 作爲 Message Queue。 MQ 是 OpenStack 的核心基礎組件,我們後面也會詳細介紹。




發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章