標籤：

OpenStack高級特性簡介

05-22
OpenStack高級特性簡介

來自專欄 OpenStack

在OpenStack中那些很少見但很有用的操作中介紹了一些很少提及但很有用的功能，本文在此基礎上介紹幾個OpenStack的幾個高級特性。這裡所謂的高級特性，是指那些非人人都需要的OpenStack通用默認配置，而是專門針對一些特定場景需求設定的。

1 虛擬機軟刪除

通常情況下，當用戶刪除虛擬機時，虛擬機會立即從hypervisor底層刪除，不可撤回。為了防止人為誤操作，Nova支持開啟軟刪除(soft delete)功能，或者稱為延遲刪除，延遲刪除時間通過Nova配置項/etc/nova/nova.conf的reclaim_instance_interval項指定，如下:

[DEFAULT]...reclaim_instance_interval = 120

此時虛擬機執行普通刪除操作時，nova不會立即刪除虛擬機，而是會等待兩分鐘的時間，在此時間間隔內，管理員可以隨時恢復虛擬機，只有在超過120秒後虛擬機才會真正執行刪除操作，不可恢復。

為了演示該功能，我們刪除一台虛擬機int32bit-test-2:

# nova list+--------------------------------------+-----------------+--------+------------+-------------+-------------------+| ID | Name | Status | Task State | Power State | Networks |+--------------------------------------+-----------------+--------+------------+-------------+-------------------+| 8f082394-ffd2-47db-9837-a8cbd1e011a1 | int32bit-test-1 | ACTIVE | - | Running | private=10.0.0.6 || 9ef2eea4-77dc-4994-a2d3-a7bc59400d22 | int32bit-test-2 | ACTIVE | - | Running | private=10.0.0.13 |+--------------------------------------+-----------------+--------+------------+-------------+-------------------+# nova delete 9ef2eea4-77dc-4994-a2d3-a7bc59400d22Request to delete server 9ef2eea4-77dc-4994-a2d3-a7bc59400d22 has been accepted.

通過nova list命令並指定--deleted選項可以列出已刪除的所有虛擬機實例:

# nova list --deleted | grep -i soft_delete| 9ef2eea4-77dc-4994-a2d3-a7bc59400d22 | int32bit-test-2 | SOFT_DELETED | - | Shutdown | private=10.0.0.13 |

通過nova restore命令可以恢復虛擬機：

# nova restore 9ef2eea4-77dc-4994-a2d3-a7bc59400d22# nova list+--------------------------------------+-----------------+--------+------------+-------------+-------------------+| ID | Name | Status | Task State | Power State | Networks |+--------------------------------------+-----------------+--------+------------+-------------+-------------------+| 8f082394-ffd2-47db-9837-a8cbd1e011a1 | int32bit-test-1 | ACTIVE | - | Running | private=10.0.0.6 || 9ef2eea4-77dc-4994-a2d3-a7bc59400d22 | int32bit-test-2 | ACTIVE | - | Running | private=10.0.0.13 |+--------------------------------------+-----------------+--------+------------+-------------+-------------------+

可見，剛剛刪除的虛擬機已經恢復了。

注意如果管理員通過nova force-delete命令強制刪除虛擬機，虛擬機會立即從底層刪除而無視延遲時間。

需要注意的是，由於這個功能早期設計的缺陷，開啟虛擬機軟刪除功能必須保證所有計算節點和API節點配置一樣並且時間同步，並且所有節點的延遲時間不可動態修改，這非常不靈活。我在我們內部私有雲二次開發中改善了該功能，延時時間不再通過配置文件指定，而是通過虛擬機的admin metadata指定，這樣就不再依賴於各個節點的配置項的同步與更新，並且可隨時調整延時時間。

2 CPU拓撲以及核綁定

2.1 概述

OpenStack K版本引入了許多CPU高級特性功能，不僅支持自定義CPU拓撲功能，支持設置虛擬機CPU的socket、core、threads等，還支持CPU pinning功能，即CPU核綁定，甚至能夠配置虛擬機獨佔物理CPU，虛擬機的vCPU能夠固定綁定到宿主機的指定pCPU上，在整個運行期間，不會發生CPU浮動，減少CPU切換開銷，提高虛擬機的計算性能。除此之外，OpenStack還支持設置threads policy，能夠利用宿主機的SMT特性進一步優化虛擬機的性能。

接下來簡單介紹下如何配置OpenStack的CPU高級特性。

2.2 規劃CPU和內存

在配置之前，首先需要規劃計算節點的CPU和內存，哪些CPU分配給虛擬機，哪些CPU給宿主機本身的進程預留，預留多少內存等。為了性能的最優化，還需要考慮宿主機CPU的NUMA架構。

在Linux環境下可以通過以下命令查看CPU信息:

$ lscpuArchitecture: x86_64CPU op-mode(s): 32-bit, 64-bitByte Order: Little EndianCPU(s): 40On-line CPU(s) list: 0-39Thread(s) per core: 2Core(s) per socket: 10Socket(s): 2NUMA node(s): 2Vendor ID: GenuineIntelCPU family: 6Model: 63Model name: Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHzStepping: 2CPU MHz: 1201.480BogoMIPS: 4603.87Virtualization: VT-xL1d cache: 32KL1i cache: 32KL2 cache: 256KL3 cache: 25600KNUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39

由以上信息可知，該宿主機一共兩個CPU（socket)，每個CPU 10核(core)，每個核可以開啟兩個超線程(thread)，即一共有40個邏輯CPU，包含兩個NUMA node，其中node0包括0，2，4，...,38，node1包括1,3,5,...,39。

預留CPU個數和內存需要根據實際情況調整，比如若計算節點和存儲節點融合，則需要預留更多的CPU來保證存儲服務的性能。

本例子僅作為測試使用，測試環境預留了4個邏輯CPU(1-3)和4GB物理內存給宿主機，剩下的資源全部分配給虛擬機使用。

配置虛擬機使用的CPU集合(cpuset)是通過計算節點的vcpu_pin_set配置項指定，目前支持以下三種語法格式:

  • 1,2,3 # 指定CPU號，逗號隔開。
  • 2-15, 18-31 # 使用-表示連續CPU序列，使用逗號分隔。
  • ^0,^1,^2,^3 # 使用^表示排除的CPU號，剩下的全部作為虛擬機使用。

以上三種語法格式可以組合使用。

compute節點Nova參考配置如下:

# /etc/nova/nova.conf[DEFAULT]...vcpu_pin_set = ^0,^1,^2,^3reserved_host_memory_mb = 4096...

如果需要配置虛擬機CPU獨佔，則還需要配置內核參數isolcpu來限制其他進程使用指定的CPU。比如我們需要把CPU 2,3,6,7作為CPU pinning給虛擬機獨佔，設置如下:

grubby --update-kernel=ALL --args="isolcpus=2,3,6,7"

重新安裝grub:

grub2-install /dev/sda

重啟宿主機:

reboot

下次系統啟動時會默認添加如下內核參數：

linux /vmlinuz-xxx root=xxx ... isolcpus=2,3,6,7

在nova-scheduler節點上，需要配置默認filter，filters中必須包含AggregateInstanceExtraSpecFilter和NUMATopologyFilter這兩個filter：

# /etc/nova/nova.conf[DEFAULT]scheduler_default_filters=NUMATopologyFilter,AggregateInstanceExtraSpecsFilter,...

配置完重啟所有的nova-scheduler服務:

systemctl restart openstack-nova-scheduler

2.3 創建主機集合

在實際環境中肯定不是所有的計算節點都開啟這些高級功能，並且CPU特性也有差別，我們可以通過主機集合（host aggregate)把所有相同的CPU配置放到一個集合中，通過主機集合(host aggregate)區分哪些計算節點開啟CPU核綁定功能，哪些不開啟。

首先創建pinned-cpu主機集合:

nova aggregate-create pinned-cpu

增加metadata區分pinned:

nova aggregate-set-metadata pinned-cpu pinned=true

把配置開啟了CPU核綁定功能的兩個host加到該主機集合中:

nova aggregate-add-host pinned-cpu server-1nova aggregate-add-host pinned-cpu server-2

此時nova scheduler只要接收到包含pinned=true元數據的請求就會自動從包含pinned=true元數據的主機中調度。

2.4 創建flavor

目前Nova並不支持啟動時直接指定主機集合的metadata（hint只支持指定server group），需要通過flavor的extra specs配置，並與主機集合的metadata匹配，不匹配的主機將被過濾掉，不會被選擇作為候選主機。

flavor支持很多內置的extra specs，通過內置extra specs，可以配置虛擬機的CPU拓撲、QoS、CPU pinning策略、NUMA拓撲以及PCI passthrough等，更詳細的介紹可參考官方文檔。這裡我們只關心CPU拓撲和核綁定功能。

如下是設置CPU topology的語法，自定義CPU的socket數量、core數量以及超線程數量：

$ nova flavor-key FLAVOR-NAME set hw:cpu_sockets=FLAVOR-SOCKETS hw:cpu_cores=FLAVOR-CORES hw:cpu_threads=FLAVOR-THREADS hw:cpu_max_sockets=FLAVOR-SOCKETS hw:cpu_max_cores=FLAVOR-CORES hw:cpu_max_threads=FLAVOR-THREADS

注意以上配置項不需要全部設置，只需要設置其中一個或者幾個，剩餘的值會自動計算。

CPU核綁定配置語法如下:

$ nova flavor-key set FLAVOR-NAME hw:cpu_policy=CPU-POLICY hw:cpu_thread_policy=CPU-THREAD-POLICY

其中CPU-POLICY合法值為shared、dedicated，默認為shared，即不進行CPU核綁定，我們需要把這個值設置為dedicated。

CPU-THREAD-POLICY和SMT有關，合法值為:

  • prefer: 宿主機不一定需要符合SMT架構，如果宿主機具備SMT架構，將優先分配thread siblings。
  • isolate: 宿主機SMT架構不是必須的，如果宿主機不具備SMT架構，每個vCPU將綁定不同的pCPU，如果宿主機是SMT架構的，每個vCPU綁定不同的物理核。
  • require: 宿主機必須滿足SMT架構，每個vCPU在不同的thread siblins上分配，如果宿主機不具備SMT架構或者core的空閑thread siblings不滿足請求的vCPU數量，將導致調度失敗。

通常設置成默認值prefer或者isolate即可。

接下來開始創建flavor，設置為8個CPU、2GB內存以及20GB磁碟空間：

nova flavor-create m1.xlarge.pinned 100 2048 20 8

設置CPU Policy：

nova flavor-key m1.xlarge.pinned set hw:cpu_policy=dedicated

添加pinned相關的extra specs用於匹配主機集合metadata，保證調度時只選擇開啟了核綁定的宿主機:

nova flavor-key m1.xlarge.pinned set aggregate_instance_extra_specs:pinned=true

配置CPU拓撲為2 sockets * 2 cores * 2 threads:

nova flavor-key m1.xlarge.pinned set hw:cpu_sockets=2 hw:cpu_cores=2 hw:cpu_threads=2

查看flavor的extra specs信息:

# nova flavor-show m1.xlarge.pinned | awk -F | /extra_specs/{print $3} | python -m json.tool{ "aggregate_instance_extra_specs:pinned": "true", "hw:cpu_cores": "2", "hw:cpu_policy": "dedicated", "hw:cpu_sockets": "2", "hw:cpu_threads": "2"}

2.5 功能驗證

使用新創建的Flavor創建虛擬機:

nova boot int32bit-test-pinning --flavor m1.xlarge.pinned --image 16b79884-77f2-44f5-a6d7-6fcc30651283 --nic net-id=ed88dc5a-61d8-4f99-9532-8c68e5ec5b9e

使用nova-show命令查看虛擬機所在的宿主機，在該宿主機上查看虛擬機的xml文件:

virsh dumpxml 306abd22-28c5-4f91-a5ce-0dad03a35f49

其中306abd22-28c5-4f91-a5ce-0dad03a35f4為虛擬機的uuid。

在xml文件中可以看到如下內容:

<vcpu placement=static>8</vcpu><cputune><vcpupin vcpu=0 cpuset=25/><vcpupin vcpu=1 cpuset=5/><vcpupin vcpu=2 cpuset=8/><vcpupin vcpu=3 cpuset=28/><vcpupin vcpu=4 cpuset=9/><vcpupin vcpu=5 cpuset=29/><vcpupin vcpu=6 cpuset=24/><vcpupin vcpu=7 cpuset=4/><emulatorpin cpuset=4-5,8-9,24-25,28-29/></cputune>

即vCPU與pCPU的綁定關係。

進入虛擬機中查看CPU信息結果如下:

# lscpuArchitecture: x86_64CPU op-mode(s): 32-bit, 64-bitByte Order: Little EndianCPU(s): 2On-line CPU(s) list: 0,1Thread(s) per core: 2Core(s) per socket: 2Socket(s): 2NUMA node(s): 1Vendor ID: GenuineIntel...

和我們配置的結果一樣(2 sockets * 2 cores * 2 threads)。

在虛擬機上執行高密度計算，測試的Python腳本如下:

# test_compute.pyk = 0for i in xrange(1, 100000): for j in xrange(1, 100000): k = k + i * j

使用shell腳本同時跑50個進程，保證CPU滿載運行:

for i in `seq 1 50`; do python test_compute.py &done

使用sar命令查看宿主機CPU使用情況:

sar -P ALL 1 100

結果如下:

Linux 3.10.0-229.20.1.el7.x86_64 (8409a4dcbe1d11af) 05/10/2018 _x86_64_ (40 CPU)10:20:14 PM CPU %user %nice %system %iowait %steal %idle10:20:15 PM all 20.48 0.00 0.15 0.03 0.00 79.3410:20:15 PM 0 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 1 0.99 0.00 0.00 0.00 0.00 99.0110:20:15 PM 2 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 3 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 4 100.00 0.00 0.00 0.00 0.00 0.0010:20:15 PM 5 100.00 0.00 0.00 0.00 0.00 0.0010:20:15 PM 6 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 7 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 8 100.00 0.00 0.00 0.00 0.00 0.0010:20:15 PM 9 100.00 0.00 0.00 0.00 0.00 0.0010:20:15 PM 10 1.01 0.00 0.00 0.00 0.00 98.9910:20:15 PM 11 1.00 0.00 0.00 0.00 0.00 99.0010:20:15 PM 12 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 13 0.00 0.00 0.99 0.00 0.00 99.0110:20:15 PM 14 0.99 0.00 0.99 0.00 0.00 98.0210:20:15 PM 15 1.00 0.00 0.00 0.00 0.00 99.0010:20:15 PM 16 0.99 0.00 0.99 0.00 0.00 98.0210:20:15 PM 17 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 18 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 19 3.96 0.00 0.99 0.00 0.00 95.0510:20:15 PM 20 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 21 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 22 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 23 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 24 100.00 0.00 0.00 0.00 0.00 0.0010:20:15 PM 25 100.00 0.00 0.00 0.00 0.00 0.0010:20:15 PM 26 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 27 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 28 100.00 0.00 0.00 0.00 0.00 0.0010:20:15 PM 29 100.00 0.00 0.00 0.00 0.00 0.0010:20:15 PM 30 2.00 0.00 0.00 0.00 0.00 98.0010:20:15 PM 31 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 32 2.97 0.00 0.99 0.00 0.00 96.0410:20:15 PM 33 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 34 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 35 1.00 0.00 0.00 0.00 0.00 99.0010:20:15 PM 36 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 37 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 38 0.00 0.00 0.00 0.00 0.00 100.0010:20:15 PM 39 0.00 0.00 0.00 0.00 0.00 100.00

從CPU使用情況看宿主機的pCPU 4-5，8-9，24-25，28-29使用率100%，並且整個過程中沒有浮動，符合我們的預期結果，說明CPU核綁定成功。

3 虛擬化嵌套

3.1 開啟虛擬化嵌套

默認情況下我們創建的KVM虛擬機的CPU特性中沒有包含vmx，這意味著不能在虛擬機中再創建開啟KVM硬體加速的虛擬機，即不支持虛擬化嵌套。值得慶幸的是，目前除了VirtualBox(題外話：VirtualBox在9年前就有人提出要支持嵌套，只是一直沒有實現，參考ticket #4032)，主流的hypervisor比如VMware、KVM、Xen都支持已經虛擬化嵌套。也就是說，我們可以實現在支持KVM的宿主機創建同樣支持KVM的虛擬機。

這裡以KVM為例，首先查看系統是否開啟了KVM嵌套功能:

cat /sys/module/kvm_intel/parameters/nested

如果輸出為N則表明沒有開啟KVM嵌套功能，可以通過修改/etc/modprobe.d/kvm-intel.conf配置文件開啟該功能：

options kvm-intel nested=1

重新載入kvm-intel內核模塊:

rmmod kvm_intelmodprobe kvm_intel

3.2 配置計算節點

OpenStack支持虛擬化嵌套，修改計算節點的nova配置文件/etc/nova/nova.conf，設置cpu_mode = host-passthrough，然後重啟nova-compute服務即可。

需要注意的是，使用host-passthrough的虛擬機遷移功能受限，只能遷移到相同配置的宿主機。

4 使用virtio-scsi驅動

4.1 virtio-blk VS virtio-scsi

虛擬機的虛擬硬碟默認使用半虛擬化驅動virt-blk，此時硬碟在虛擬機的設備名稱形如/dev/vda、/dev/vdb等。

事實上，virt-blk有點老了，其本身也存在許多問題，比如:

  • virt-blk的存儲設備和PCI設備一一對應，而我們知道系統中至多可以有32個PCI匯流排，這說明虛擬機最多可以掛32個虛擬硬碟。
  • virt-blk的設備名稱為vd[a-z]，而現代的物理機通常都會使用SCSI控制器，設備名稱為sd[a-z]，這意味著物理機遷移到虛擬機中可能存在問題，比如fstab中使用的設備名掛載而不是uuid，系統就會起不來。
  • 如WIKI所言，virt-blk實現的指令不是標準的，並且可擴展差，實現一個新的指令，必須更新所有的guest。
  • 雲計算架構模式下，為了節省存儲空間，用戶更傾向於使用精簡置備(thin provision)，virtio-blk不支持discard特性，關於discard特性後面講。

因此，建議使用virtio-scsi半虛擬化驅動代替virtio-blk，這是因為:

  • 實現的是標準的SCSI指令介面，不需要額外實現指令，在虛擬機里看到的設備名稱和物理機一樣(sd[a-z])，解決了前面提到的物理機和虛擬機設備名不一樣的問題。
  • 一個SCSI控制器可以接256個targets，而一個target可以接16384個LUNs，也就是說一個controller理論上可以掛載256 * 16384 == 4194304個虛擬機硬碟，這100%足夠了。
  • virtio-scsi支持直通模式(passthrough)，也就是說可以把物理機的硬碟直接映射給虛擬機。
  • virtio-scsi支持前面提到的discard特性。

4.2 塊設備的discard功能

前面提到塊設備的discard特性，這個主要和精簡置備有關，就拿Ceph RBD說，我們知道當我們分配一個20GB的image時，Ceph並不會真正分配20GB的存儲空間，而是根據需要逐塊分配，這和Linux的sparse稀疏文件的原理是一樣的，這個特性節省了物理存儲空間，實現了硬碟的超售。然而，Ceph只知道上層文件系統需要空間時就分配，而並不知道上層文件系統如何使用存儲資源的（實際上也不關心）。而實際上，我們的文件系統肯定是頻繁創建文件、刪除文件的，刪除文件後按理說是可以釋放物理存儲資源的，然而Ceph並不知道，所以不會回收，佔據的存儲空間會越來越多，直到空間達到真實的分配空間大小(20GB)，而文件系統層可能並沒有真正使用那麼多空間，這就造成了存儲空間利用率下降的問題。比如，我們創建了一個5GB的文件，Ceph底層會分配5GB的空間，此時我們把這個5GB的文件刪除，分配的這5GB空間並不會釋放。好在Linux支持fstrim，如果塊設備支持discard特性，文件系統會發送flush通知給底層塊設備(RBD)，塊設備會回收空閑資源。Sébastien Han寫了一篇博客關於ceph discard的，參考ceph and krbd discard。

正如前面所言，virt-blk是不支持discard的，而virt-scsi支持，所以如果關心底層存儲的空間利用率，建議使用virt-scsi，並在掛載設備中指定discard參數(或者寫到fstab中):

mount -o discard /dev/rbd0 /mnt/

但是需要注意的是，任何事物都具有兩面性，既有優點，也存在缺點:

  • virio-scsi相對virtio-blk IO路徑會更複雜，性能可能會有所下降，參考virtio-blk vs virtio-scsi。
  • 通過mount命令掛載虛擬硬碟時開啟discard特性會降低文件系統的讀寫性能。

4.3 OpenStack使用virtio-scsi驅動

前面講了那麼多關於virio-blk以及virtio-scsi，那怎麼在OpenStack中使用virtio-scsi呢？很簡單，只需要設置Glance鏡像的property就可以了:

glance image-update --property hw_scsi_model=virtio-scsi --property hw_disk_bus=scsi ${IMAGE_UUID}

通過這個配置不僅使根磁碟會使用virtio-scsi驅動，掛載新的Cinder volume也會默認使用virtio-scsi驅動。

需要注意的是，製作OpenStack鏡像時一定要保證initrd中包含virtio-scsi驅動，否則操作系統會由於在初始化時不識別SCSI塊設備導致啟動失敗:

zcat /boot/initrd-3.0.101-63-default | cpio -it | grep virtio-scsi

如果鏡像的initrd沒有virtio驅動，可以編輯/etc/sysconfig/kernel文件，配置INITRD_MODULES參數：

INITRD_MODULES = ... virtio,virtio_net,virtio_blk,virtio_pci,virtio_scsi ...

然後重新生成initrd文件:

mkinitrd

啟動虛擬機後，如果根硬碟的設備名稱為/dev/sda，則說明使用的是virtio-scsi驅動。

5 使用qemu-guest-agent

5.1 qemu-guest-agent簡介

我們都知道OpenStack虛擬機啟動時是通過cloud-init完成初始化配置的，比如網卡配置、主機名配置、注入用戶密碼等。而虛擬機啟動之後處於運行狀態時，外部如何與虛擬機通信呢，這就是qemu-guest-agent要完成的事，這其實在如何構建OpenStack鏡像一文中已經介紹過，這裡直接搬過來。

qemu-guest-agent是運行在虛擬機的一個daemon服務，libvirt會在宿主機本地創建一個unix socket，並模擬為虛擬機內部的一個串口設備，從而實現了宿主機與虛擬機通信，這種方式不依賴於TCP/IP網路。

如下是開啟qemu-guest-agent的虛擬機xml配置信息：

<channel type=unix> <source mode=bind path=/var/lib/libvirt/qemu/org.qemu.guest_agent.0.instance-00003c2c.sock/> <target type=virtio name=org.qemu.guest_agent.0/> <address type=virtio-serial controller=0 bus=0 port=1/></channel>

以上宿主機的socket文件為org.qemu.guest_agent.0.instance-00003c2c.sock，在虛擬機內部映射為/dev/virtio-ports/org.qemu.guest_agent.0。

通過這種方式，宿主機只要發送指令到該socket文件中就會在虛擬機對應的串口設備中收到，虛擬機內部的qemu-guest-agent會輪詢查看這個串列設備是否有指令，一旦接收到指令就可以執行對應的腳本，從而實現了宿主機控制虛擬機執行命令的功能，其中最常用的指令就是通過libvirt修改虛擬機密碼。更多關於qemu-guest-agent請參考官方文檔。

5.2 在OpenStack中應用

首先在製作鏡像時需要安裝qemu-guest-agent服務:

yum install -y qemu-guest-agentsystemctl enable qemu-guest-agent

在glance鏡像中添加hw_qemu_guest_agent property:

glance image-update --property hw_qemu_guest_agent=yes ${IMAGE_ID}

可以通過Nova的nova set-password <server>子命令驗證修改虛擬機的密碼功能。

需要注意的是，Nova默認修改的是管理員用戶的密碼，Linux系統為root，Windows系統為Administrator，因此上傳鏡像時需要指明鏡像是什麼操作系統類型:

glance image-update --property os_type=linux/windows ${IMAGE_ID}

當然你也可以通過os_admin_user屬性配置修改其他用戶的密碼，比如配置修改密碼時指定用戶不是root，而是ubuntu用戶：

glance image-update --property os_admin_user=ubuntu ${IMAGE_ID}

6 網卡多隊列

默認情況下網卡中斷由單個CPU處理，當有大量網路包時單個CPU處理網路中斷就可能會出現瓶頸。通過網卡多隊列技術可以把網卡的中斷分攤到多個CPU中。阿里雲官方文檔測試表明在網路PPS和網路帶寬的測試中，與1個隊列相比，2個隊列最多可提升50%到1倍，4個隊列的性能提升更大。

OpenStack支持配置網卡多隊列(要求內核版本大於3.0)，配置方法如下：

glance image-update --property hw_vif_multiqueue_enabled=true ${IMAGE_ID}

隊列長度固定為虛擬機的核數。

創建虛擬機查看網卡信息:

# ethtool -l eth0Channel parameters for eth0:Pre-set maximums:RX: 0TX: 0Other: 0Combined: 2Current hardware settings:RX: 0TX: 0Other: 0Combined: 1

網卡信息表明支持的最大隊列(Combined)為2，目前設置為1，可以通過ethtool工具修改配置：

ethtool -L eth0 combined 2

為了保證中斷自動均衡到所有的CPU，建議開啟irqbalance服務：

systemctl enable irqbalancesystemctl start irqbalance

7 watchdog

在一些分散式集群中，我們可能期望虛擬機crash時自動關機，防止出現集群腦裂。或者當負載過高時自動執行重啟，使服務恢復正常。

OpenStack支持配置虛擬watchdog，首先製作鏡像時需要安裝並開啟watchdog服務:

yum install watchdogsystemctl enable watchdog

配置如下glance image屬性：

glance image-update --property hw_watchdog_action=${ACTION} ${IMAGE_ID}

其中支持的action列表如下:

  • reset: 強制重啟。
  • shutdown: 安全關機。
  • poweroff: 強制關機。
  • pause: 停止虛擬機。
  • none: 不執行任何操作。
  • dump: 導出dump core。

參考官方文檔可以查看更詳細的配置。

8 GPU虛擬化

OpenStack從Q版本開始支持GPU虛擬化，由於測試環境中沒有GPU，因此本文僅參考官方文檔描述配置過程。

首先在安裝有GPU（假設為nvidia-35）的計算節點中修改nova配置文件:

[devices]enabled_vgpu_types = nvidia-35

重啟nova-compute服務:

systemctl restart openstack-nova-compute

創建一個flavor，通過resources:VGPU=1extra specs指定虛擬GPU個數:

nova flavor-key gpu_test set resources:VGPU=1

使用該flavor創建的虛擬機就會分配一個虛擬GPU。

需要注意的是，如果使用libvirt driver，對於分配了vGPU的虛擬機：

  • 不能執行掛起(suspend)操作，這是因為libvirt不支持vGPU的熱插拔功能。
  • 冷遷移（migrate）、拯救（rescue）或者通過resize指定另一個設置了GPU的flavor，虛擬機都將不會再分配GPU，可以通過再執行一次rebuild操作恢復。

9. 參考文獻

  1. 維基百科NUMA.
  2. NUMA架構的CPU -- 你真的用好了么？.
  3. OpenStack官方文檔--Flavor.
  4. CPU pinning and numa topology awareness in OpenStack compute.
  5. Simultaneous multithreading - Wikipedia.
  6. isolcpus、numactl and taskset.
  7. Virtio-scsi.
  8. ceph and krbd discard.
  9. virio-blk vs virio-scsi.
  10. virtual gpu.
  11. libvirt watchdog.
  12. enable netsted virtualization kv centos 7.
  13. inception how usable are nested kvm guests.
  14. more recommandations ceph openstack.
  15. 阿里雲網卡多隊列文檔.

推薦閱讀：

※雲計算是個什麼玩意（上）
※kubernetes的kube-scheduler性能將提升40%
※純手工搭建k8s集群-序
※360°透視：雲原生架構及設計原則
※阿里雲升級人工智慧戰略，用大數據AI備戰新七年大考

TAG:雲計算 | OpenStack |