CLI 創建 image
1、將 image 上傳到控制節點的文件系統中，例如 /tmp/cirros-0.3.4-x86_64-disk.img
2、設置環境變量
source devstack/openrc admin admin
Devstack 的安裝目錄下有個 openrc 文件。source 該文件就可以配置 CLI 的環境變量。這里我們傳入了兩個參數，第一個參數是 OpenStack 用戶名 admin；第二個參數是 Project 名 admin
3、執行 image 創建命令
glance image-create --name cirros --file /tmp/cirros-0.3.4-x86_64-disk.img --disk-format qcow2 --container-format bare --progress
在 /opt/stack/data/glance/images/ 下查看新的 Image
CLI 刪除 image
1、查詢現有image
glance image-list
2、刪除image
glance image-delete 1651654s-d15dsf-adsf1-354-adf5-3a1465
如何使用 OpenStack CLI
OpenStack 服務都有自己的 CLI。
命令很好記，就是服務的名字，比如 Glance 就是 glance，Nova 就是 nova。
但 Keystone 比較特殊，現在是用 openstack 來代替老版的 keystone 命令。
不同服務用的命令雖然不同，但這些命令使用方式卻非常類似，可以舉一反三。
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 管理的是 image，那么:
CMD 就是 glance；obj 就是 image
對應的命令就有
glance image-create
glance image-delete
glance image-update
glance image-list
glance image-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 為參數，例如
如何 Troubleshooting
OpenStack 排查問題的方法主要是通過日志，Service 都有自己單獨的日志。
Glance 主要有兩個日志，glance_api.log 和 glance_registry.log，保存在 /var/log/glance/ 目錄里。
devstack 的 screen 窗口已經幫我們打開了這兩個日志，可以直接查看
g-api 窗口顯示 glance-api 日志，記錄 REST API 調用情況
g-reg 窗口顯示 glance-registry 日志，記錄 Glance 服務處理請求的過程以及數據庫操作
如果需要得到最詳細的日志信息，可以在 /etc/glance/*.conf 中打開 debug 選項。
devstack 默認已經打開了 debug。
Nova
Nova 處於 Openstak 架構的中心，其他組件都為 Nova 提供支持：
Glance 為 VM 提供 image
Cinder 和 Swift 分別為 VM 提供塊存儲和對象存儲
Neutron 為 VM 提供網絡連接
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-xvpnvncproxy，基於 Java 客戶端的 VNC 訪問
nova-consoleauth
負責對訪問虛機控制台請親提供 Token 認證
nova-cert
提供 x509 證書支持
從虛機創建流程看 nova-* 子服務如何協同工作
1、客戶（可以是 OpenStack 最終用戶，也可以是其他程序）向 API（nova-api）發送請求：“幫我創建一個虛機”
2、API 對請求做一些必要處理后，向 Messaging（RabbitMQ）發送了一條消息：“讓 Scheduler 創建一個虛機”
3、Scheduler（nova-scheduler）從 Messaging 獲取到 API 發給它的消息，然后執行調度算法，從若干計算節點中選出節點 A
4、Scheduler 向 Messaging 發送了一條消息：“在計算節點 A 上創建這個虛機”
5、計算節點 A 的 Compute（nova-compute）從 Messaging 中獲取到 Scheduler 發給它的消息，然后在本節點的 Hypervisor 上啟動虛機。
6、在虛機創建的過程中，Compute 如果需要查詢或更新數據庫信息，會通過 Messaging 向 Conductor（nova-conductor）發送消息，Conductor 負責數據庫訪問。
上面是創建虛機最核心的幾個步驟，當然也省略了很多細節，我們會在后面的章節詳細討論。 這幾個步驟向我們展示了 nova-* 子服務之間的協作的方式，也體現了 OpenStack 整個系統的分布式設計思想，
nova-scheduler 的調度機制和實現方法
創建 Instance 時，用戶會提出資源需求，例如 CPU、內存、磁盤各需要多少。
OpenStack 將這些需求定義在 flavor 中，用戶只需要指定用哪個 flavor 就可以了。
lavor 主要定義了 VCPU，RAM，DISK 和 Metadata 這四類。 nova-scheduler 會按照 flavor 去選擇合適的計算節點。 VCPU，RAM，DISK 比較好理解，而 Metatdata 比較有意思，我們后面會具體討論。
下面介紹 nova-scheduler 是如何實現調度的。
在 /etc/nova/nova.conf 中，nova 通過 scheduler_driver，scheduler_available_filters 和 scheduler_default_filters 這三個參數來配置 nova-scheduler。
Filter scheduler
Filter scheduler 是 nova-scheduler 默認的調度器，調度過程分為兩步：
通過過濾器（filter）選擇滿足條件的計算節點（運行 nova-compute）
通過權重計算（weighting）選擇在最優（權重值最大）的計算節點上創建 Instance。
scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler
Nova 允許使用第三方 scheduler，配置 scheduler_driver 即可。 這又一次體現了OpenStack的開放性。
Scheduler 可以使用多個 filter 依次進行過濾，過濾之后的節點再通過計算權重選出最適合的節點。
Filter
當 Filter scheduler 需要執行調度操作時，會讓 filter 對計算節點進行判斷，filter 返回 True 或 False。
Nova.conf 中的 scheduler_available_filters 選項用於配置 scheduler 可用的 filter，默認是所有 nova 自帶的 filter 都可以用於濾操作。
scheduler_available_filters = nova.scheduler.filters.all_filters
另外還有一個選項 scheduler_default_filters，用於指定 scheduler 真正使用的 filter，默認值如下
scheduler_default_filters = RetryFilter, AvailabilityZoneFilter, RamFilter, DiskFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter
Filter scheduler 將按照列表中的順序依次過濾。 下面依次介紹每個 filter。
RetryFilter
RetryFilter 的作用是刷掉之前已經調度過的節點。
舉個例子方便大家理解： 假設 A,B,C 三個節點都通過了過濾，最終 A 因為權重值最大被選中執行操作。 但由於某個原因，操作在 A 上失敗了。 默認情況下，nova-scheduler 會重新執行過濾操作（重復次數由 scheduler_max_attempts 選項指定，默認是 3）。 那么這時候 RetryFilter 就會將 A 直接刷掉，避免操作再次失敗。 RetryFilter 通常作為第一個 filter。
AvailabilityZoneFilter
為提高容災性和提供隔離服務，可以將計算節點划分到不同的Availability Zone中。
例如把一個機架上的機器划分在一個 Availability Zone 中。 OpenStack 默認有一個命名為 “Nova” 的 Availability Zone，所有的計算節點初始都是放在 “Nova” 中。 用戶可以根據需要創建自己的 Availability Zone。
創建 Instance 時，需要指定將 Instance 部署到在哪個 Availability Zone中。
nova-scheduler 在做 filtering 時，會使用 AvailabilityZoneFilter 將不屬於指定 Availability Zone 的計算節點過濾掉。
RamFilter
RamFilter 將不能滿足 flavor 內存需求的計算節點過濾掉。
對於內存有一點需要注意： 為了提高系統的資源使用率，OpenStack 在計算節點可用內存時允許 overcommit，也就是可以超過實際內存大小。 超過的程度是通過 nova.conf 中 ram_allocation_ratio 這個參數來控制的，默認值為 1.5
ram_allocation_ratio = 1.5
其含義是：如果計算節點的內存有 10GB，OpenStack 則會認為它有 15GB（10*1.5）的內存。
DiskFilter
DiskFilter 將不能滿足 flavor 磁盤需求的計算節點過濾掉。
Disk 同樣允許 overcommit，通過 nova.conf 中 disk_allocation_ratio 控制，默認值為 1
disk_allocation_ratio = 1.0
CoreFilter
CoreFilter 將不能滿足 flavor vCPU 需求的計算節點過濾掉。
vCPU 同樣允許 overcommit，通過 nova.conf 中 cpu_allocation_ratio 控制，默認值為 16
cpu_allocation_ratio = 16.0
這意味着一個 8 vCPU 的計算節點，nova-scheduler 在調度時認為它有 128 個 vCPU。 需要提醒的是： nova-scheduler 默認使用的 filter 並沒有包含 CoreFilter。 如果要用，可以將 CoreFilter 添加到 nova.conf 的 scheduler_default_filters 配置選項中。
ComputeFilter
ComputeFilter 保證只有 nova-compute 服務正常工作的計算節點才能夠被 nova-scheduler調度。
ComputeFilter 顯然是必選的 filter。
ComputeCapabilitiesFilter
ComputeCapabilitiesFilter 根據計算節點的特性來篩選。
這個比較高級，我們舉例說明。
例如我們的節點有 x86_64 和 ARM 架構的，如果想將 Instance 指定部署到 x86_64 架構的節點上，就可以利用到 ComputeCapabilitiesFilter。
還記得 flavor 中有個 Metadata 嗎，Compute 的 Capabilitie s就在 Metadata中 指定。
ImagePropertiesFilter
ImagePropertiesFilter 根據所選 image 的屬性來篩選匹配的計算節點。
跟 flavor 類似，image 也有 metadata，用於指定其屬性。
配置好后，ImagePropertiesFilter 在調度時只會篩選出 kvm 的節點。
如果沒有設置 Image 的Metadata，ImagePropertiesFilter 不會起作用，所有節點都會通過篩選。
ServerGroupAntiAffinityFilter
ServerGroupAntiAffinityFilter 可以盡量將 Instance 分散部署到不同的節點上。
例如有 inst1，inst2 和 inst3 三個 instance，計算節點有 A,B 和 C。
為保證分散部署，進行如下操作：
創建一個 anti-affinity 策略的 server group “group-1”
nova server-group-create --policy anti-affinity group-1
請注意，這里的 server group 其實是 instance group，並不是計算節點的 group。
依次創建 Instance，將inst1, inst2和inst3放到group-1中
nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst1
nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst2
nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst3
因為 group-1 的策略是 AntiAffinity，調度時 ServerGroupAntiAffinityFilter 會將 inst1, inst2 和 inst3 部署到不同計算節點 A, B 和 C。
目前只能在 CLI 中指定 server group 來創建 instance。
創建 instance 時如果沒有指定 server group，ServerGroupAntiAffinityFilter 會直接通過，不做任何過濾。
ServerGroupAffinityFilter
與 ServerGroupAntiAffinityFilter 的作用相反，ServerGroupAffinityFilter 會盡量將 instance 部署到同一個計算節點上。
方法類似
創建一個 affinity 策略的 server group “group-2”
nova server-group-create --policy affinity group-2
依次創建 instance，將 inst1, inst2 和 inst3 放到 group-2 中
nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst1
nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst2
nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst3
因為 group-2 的策略是 Affinity，調度時 ServerGroupAffinityFilter 會將 inst1, inst2 和 inst3 部署到同一個計算節點。
創建 instance 時如果沒有指定 server group，ServerGroupAffinityFilter 會直接通過，不做任何過濾。
Weight
經過前面一堆 filter 的過濾，nova-scheduler 選出了能夠部署 instance 的計算節點。
如果有多個計算節點通過了過濾，那么最終選擇哪個節點呢？
Scheduler 會對每個計算節點打分，得分最高的獲勝。
打分的過程就是 weight，翻譯過來就是計算權重值，那么 scheduler 是根據什么來計算權重值呢？
目前 nova-scheduler 的默認實現是根據計算節點空閑的內存量計算權重值：
空閑內存越多，權重越大，instance 將被部署到當前空閑內存最多的計算節點上
日志
是時候完整的回顧一下 nova-scheduler 的工作過程了。
整個過程都被記錄到 nova-scheduler 的日志中。
比如當我們部署一個 instance 時
打開 nova-scheduler 的日志 /opt/stack/logs/n-sch.log（非 devstack 安裝其日志在 /var/log/nova/scheduler.log）
nova-compute
nova-compute 在計算節點上運行，負責管理節點上的 instance。
OpenStack 對 instance 的操作，最后都是交給 nova-compute 來完成的。
nova-compute 與 Hypervisor 一起實現 OpenStack 對 instance 生命周期的管理。
通過 Driver 架構支持多種 Hypervisor
接着的問題是：現在市面上有這么多 Hypervisor，nova-compute 如何與它們配合呢？
這就是我們之前討論過的 Driver 架構。
nova-compute 為這些 Hypervisor 定義了統一的接口，Hypervisor 只需要實現這些接口，就可以 Driver 的形式即插即用到 OpenStack 系統中。
下面是Nova Driver的架構示意圖
我們可以在 /opt/stack/nova/nova/virt/ 目錄下查看到 OpenStack 源代碼中已經自帶了上面這幾個 Hypervisor 的 Driver
某個特定的計算節點上只會運行一種 Hypervisor，只需在該節點 nova-compute 的配置文件 /etc/nova/nova.conf 中配置所對應的 compute_driver 就可以了。
compute_driver=libvirt.LibvirtDriver
nova-compute 的功能可以分為兩類：
1、定時向 OpenStack 報告計算節點的狀態
2、實現 instance 生命周期的管理