深入理解Openstack QoS控制實現與實踐
0.什么是QoSFrom
Wikipedia:
Quality of service (QoS) is the overall performance of a telephony or computer network, particularly the performance seen by the users of the network. To quantitatively measure quality of service, several related aspects of the network service are often considered, such as error rates, bit rate, throughput, transmission delay, availability, jitter, etc.
簡單來說,QoS是一種控制機制,提供針對不同用戶或者不同數據流采用相應不同的優先級,或者根據應用程序的要求,保證數據流的性能達到一定的水準。QoS的保證對于容量有限的網絡來說是十分重要的,特別是對于流媒體應用,例如VoIP和IPTV等,因為這些應用常常需要固定的傳輸率,對延時也比較敏感。
QoS通常指網絡上的數據流控制,本文討論的QoS則更廣泛些,不僅包含了傳統的網絡數據流控制(即網絡IO控制),還包括了本地磁盤的讀寫控制,比如IOPS等。其中包括兩種類型:
- 質量控制:通過提供不同性能的硬件設備來滿足不同應用的性能需求,比如存儲設備有SATA、SSD、RAID等。
- 量化控制:針對應用,對其流量進行嚴格控制,比如IOPS、網絡帶寬等。
Openstack同時支持以上兩種QoS控制,這些組件包括但不限于計算服務Nova、網絡服務Neutron、塊存儲服務Cinder、對象存儲Swift等,Ceph雖然不是Openstack的組件之一,但通常作為Openstack的存儲后端,因此本文也會對其進行簡單的介紹。
本文旨在歸納總結Openstack如何在應用層實現QoS控制,讀者如果對底層實現原理感興趣,可以查閱相關資料。
1.Ceph
Ceph是近年來非常火熱的開源統一分布式存儲系統,最初是Sage Weil在University of California, Santa Cruz(UCSC)的PhD研究內容,目前由Inktank公司掌控Ceph的開發。Ceph同時支持塊存儲(LVM、裸硬盤)、對象存儲(S3、Swift)、文件系統存儲(HDFS、GFS),并且具有高擴展性、高可靠性、高性能的優點。
Ceph其中最廣泛的應用之一是作為Openstack的存儲后端,為Openstack提供統一分布式存儲服務。Openstack組件中Nova、Glance、Cinder都支持直接對接Ceph,云主機的在線遷移、故障轉移、鏡像存儲等功能都依賴于Ceph提供的統一分布式存儲服務。
實際在部署時不同的機房或者機架可能配置不同的存儲設備,比如SSD固態存儲設備、SATA普通硬盤等,rbd image實例使用不同的存儲后端,顯然能夠提供不同的性能。
我們知道ceph是通過crush算法和crush map決定對象如何分布存儲的,cursh map描述了存儲設備的層級拓撲(可以是物理拓撲,比如機架、機房、區域等,也可以是邏輯拓撲,比如故障域、性能等),整個map圖是一個樹狀結構,如圖:
- ssd
- / | \
- / | \
- rack1 rack2 rack3
- / \ ... / \
- host-1 host-2 host-m host-n
- / \ ... ... / \
- osd1 osd2 osd-m osd-n
其中中間節點由自定義的bucket type實例構成,通常和物理拓撲名稱一致,比如room、rack、host等,葉子節點是真正的存儲設備,對應一塊硬盤或者分區。根據樹的結構,每個存儲設備(葉子)有唯一一條路徑到root節點,該路徑定義為crush location,比如:
- root=ssd rack=rack1 host=host-1
crush map rule能夠制定某個pool的數據放置策略,rule的格式如下:
- rule <rulename> {
- ruleset <ruleset>
- type [ replicated | erasure ]
- min_size <min-size>
- max_size <max-size>
- step take <bucket-name>
- step [choose|chooseleaf] [firstn|indep] <N> <bucket-type>
- step emit
- }
其中ruleset為rule的id,type用于區分是存儲驅動設備(replicated)還是RAID。min_size為最小副本數,如果副本數小于這個數,crush將不會選這個rule,同理max_size為最大副本數。step take開始選擇root(注意圖上我們只畫了一棵樹,但crush map可以有多棵樹,因此存在多個root type),choose表示從子樹種選擇對應的bucket type,其中N表示選擇的數量:
- N == 0, 表示設置為pool副本數量;
- N > 0 && N < replicas,表示真實的數量;
- N < 0,表示副本數減去該數的絕對值。
比如:
- step choose firstn 1 type rack
表示從當前位置向下迭代遍歷隨機選擇一個rack類型。
該step必須位于take或者choose之下。
chooseleaf和choose類似,唯一不同的是在選擇的每個bucket中再從中選擇一個葉子節點。
以官方例子說明:
- rule ssd-primary {
- ruleset 5
- type replicated
- min_size 5
- max_size 10
- step take ssd
- step chooseleaf firstn 1 type host
- step emit
- step take sata
- step chooseleaf firstn -1 type host
- step emit
- }
假設冗余副本數為3,則以上規則會首先從ssd中選擇其中一個host,然后在host中選擇其中一個osd作為主節點,然后從sata中選擇3-1=2個host,分別從當中選擇一個osd節點,一共兩個osd節點作為副本節點。
注:
- 主節點負責實際和client通信的節點,而副本節點不會直接和client通信,但會和主節點保持數據同步,當主節點掛了,其中一個副本節點會接管主節點。
- 在寫入數據時,主節點會同步到副本節點,只有當所有的副本節點都寫完后,主節點才算寫成功,因此ceph采取的是強一致性模型(而Swift是最終一致性模型)
- 可以通過primary-affinity值設置選擇為主節點的概率,值為0表示不會被選擇為主節點,值為1表示表示選擇為主節點的概率極大(考慮到有多個節點都為1的情況)。
關于crush map 和rule參考官方文檔。
ceph中不同的pool可以定義不同的crush以及ruleset,從而可以實現不同的pool,選擇不同的osd,比如固定某個pool選擇ssd,另一個pool選擇sata,其中官方也有個例子:
- device 0 osd.0
- device 1 osd.1
- device 2 osd.2
- device 3 osd.3
- device 4 osd.4
- device 5 osd.5
- device 6 osd.6
- device 7 osd.7
- host ssd-server-1 {
- id -1
- alg straw
- hash 0
- item osd.0 weight 1.00
- item osd.1 weight 1.00
- }
- host ssd-server-2 {
- id -2
- alg straw
- hash 0
- item osd.2 weight 1.00
- item osd.3 weight 1.00
- }
- host sata-server-1 {
- id -3
- alg straw
- hash 0
- item osd.4 weight 1.00
- item osd.5 weight 1.00
- }
- host sata-server-2 {
- id -4
- alg straw
- hash 0
- item osd.6 weight 1.00
- item osd.7 weight 1.00
- }
- root sata {
- id -5
- alg straw
- hash 0
- item sata-server-1 weight 2.00
- item sata-server-2 weight 2.00
- }
- root ssd {
- id -6
- alg straw
- hash 0
- item ssd-server-1 weight 2.00
- item ssd-server-2 weight 2.00
- }
- rule sata {
- ruleset 1
- type replicated
- min_size 0
- max_size 10
- step take platter
- step chooseleaf firstn 0 type host
- step emit
- }
- rule ssd {
- ruleset 2
- type replicated
- min_size 0
- max_size 4
- step take ssd
- step chooseleaf firstn 0 type host
- step emit
- }
拓撲圖如下:
- ssd | sata
- / \ | / \
- / \ | / \
- / \ | / \
- ssd-server-1 ssd-server-2 | sata-server-1 sata-server-2
- / \ / \ | / \ / \
- / \ / \ | / \ / \
- osd0 osd1 osd2 osd3 | osd4 osd5 osd6 osd7
我們定義兩個rule,假設冗余副本數為3,一個是ssd,它會從ssd中(即左邊的樹中)中選擇osd,另一個是sata,從sata中(即右邊的樹種)選擇osd。
我們創建兩個pool,并關聯ruleset:
- ceph osd pool set sata crush_ruleset 1
- ceph osd pool set ssd crush_ruleset 2
通過以上方式我們實現了不同性能的ceph pool,實現QoS質量控制。
那ceph是否支持量化控制呢,rbd目前好像并不支持控制,但可以通過qemu、kvm等控制讀寫速率。
2.Cinder
介紹完Ceph,接下來終于進入Openstack正題,首先從Cinder談起。Cinder是Openstack的基礎組件之一,提供塊存儲服務,類似AWS的EBS服務。但是Cinder本身并不提供塊服務,而只是一個管理工具,由具體后端實現,后端包括比如LVM、Ceph RBD等,Cinder通過調用對應的驅動來完成volume的生命周期管理。
下面以Ceph RBD作為存儲后端為例,首先介紹如何實現volume的QoS質量控制。Cinder支持多后端存儲,不同的后端通過不同的配置組區別開,如:
- [sata-ceph]
- volume_backend_name=sata
- rbd_pool=sata
- volume_driver=cinder.volume.drivers.rbd.RBDDriver
- rbd_ceph_conf=/etc/ceph/ceph.conf
- ...
- [ssd-ceph]
- volume_backend_name=ssd
- rbd_pool=ssd
- volume_driver=cinder.volume.drivers.rbd.RBDDriver
- rbd_ceph_conf=/etc/ceph/ceph.conf
- ...
以上有兩個配置組,分別為sata-ceph和ssd-ceph,這里我們都使用了ceph rbd作為存儲后端,實際部署時可以是完全不同的存儲后端,比如混合rbd和LVM。以上我們指定了不同pool以及不同的后端名稱,后端名稱是為了方便后續創建volume type引用。我們由上面關于Ceph中介紹可知,不同的pool可以定義不同的rule從而選擇不同特性的硬件,如果能夠綁定Ceph pool和volume問題就解決了,值得慶幸的是,Cinder就是這么實現的。
Cinder自定義volume type,分別創建ssd和sata兩個volume type:
- cinder type-create ssd
- cinder type-create sata
創建完后type后綁定volume_backend_name從而實現與ceph pool關聯起來:
- cinder type-key sata set volume_backend_name=sata
- cinder type-key ssd set volume_backend_name=ssd
查看extra-specs:
- [root@server-39.0.lg.ustack.in ~ ]$ cinder extra-specs-list
- +--------------------------------------+------+-----------------------------------+
- | ID | Name | extra_specs |
- +--------------------------------------+------+-----------------------------------+
- | 1a0cb988-58a6-43bf-b4ea-199e0e02239b | sata | {u'volume_backend_name': u'sata'} |
- | 38344c5c-b61b-4677-9a48-e70d723b8620 | ssd | {u'volume_backend_name': u'ssd'} |
- +--------------------------------------+------+-----------------------------------+
此時只需要在創建時指定volume type就可以實現創建不同QoS性能的數據卷,比如:
- cinder create --volume-type ssd --display-name int32bit-test-ssd 1
以上我們通過自定義volume type并綁定不同的后端實現了對volume訪問的QoS質量控制,接下來我們介紹如何通過制定volume type實現不同的QoS量化控制。和前面的步驟類似,首先創建一個high-iops-type volume type:
- cinder type-create high-iops-type
cinder通過qos實例對volume進行量化控制,我們需要創建high-iops,設置讀最大iops為2000,寫最大iopos為1000:
cinder qos-create high-iops consumer="front-end" read_iops_sec=2000 write_iops_sec=1000
查看qos列表:
- $ cinder qos-list
- +--------------------------------------+-----------+-----------+---------------------------------------------------------+
- | ID | Name | Consumer | specs |
- +--------------------------------------+-----------+-----------+---------------------------------------------------------+
- | 4ba70d30-eb36-4267-8ee5-5c9cc2f8af32 | high-iops | front-end | {u'write_iops_sec': u'1000', u'read_iops_sec': u'2000'} |
- +--------------------------------------+-----------+-----------+---------------------------------------------------------+
其中consumer的合法值為front-end、back-end、both。front-end表示使用前端控制(hypervisor控制,會在libvirt xml文件中定義), 而back-end表示使用后端控制(cinder drivers,需要driver支持),both表示前后端同時進行QoS控制。
最后綁定qos實例和volume type實例:
- QOS_SPEC_ID=4ba70d30-eb36-4267-8ee5-5c9cc2f8af32
- VOLUME_TYPE_ID=26e33f06-e011-4cf7-a397-91a00ef0a233
- cinder qos-associate $QOS_SPEC_ID $VOLUME_TYPE_ID
查看綁定情況:
- $ cinder qos-get-association 4ba70d30-eb36-4267-8ee5-5c9cc2f8af32
- +------------------+----------------+--------------------------------------+
- | Association_Type | Name | ID |
- +------------------+----------------+--------------------------------------+
- | volume_type | high-iops-type | 26e33f06-e011-4cf7-a397-91a00ef0a233 |
- +------------------+----------------+--------------------------------------+
下面我們創建一個volume驗證其功能,我們創建時指定volume type為high-iops-type,并掛載到虛擬機中:
- cinder create --volume-type high-iops-type --display-name high-iops-test 1
- SERVER_ID=1ea33417-b577-45cb-83a0-fc412e421811
- VOLUME_ID=bb2ccbfb-654a-473e-9f35-ae548c8e59e1
- nova volume-attach $SERVER_ID $VOLUME_ID
查看libvirt xml文件,截取部分disk信息如下:
- <disk type='network' device='disk'>
- <driver name='qemu' type='raw' cache='writeback'/>
- <auth username='admin'>
- <secret type='ceph' uuid='bdf77f5d-bf0b-1053-5f56-cd76b32520dc'/>
- </auth>
- <source protocol='rbd' name='openstack-00/volume-bb2ccbfb-654a-473e-9f35-ae548c8e59e1'>
- <host name='10.0.103.61' port='6789'/>
- <host name='10.0.103.62' port='6789'/>
- <host name='10.0.103.63' port='6789'/>
- </source>
- <backingStore/>
- <target dev='vdc' bus='virtio'/>
- <iotune>
- <read_iops_sec>2000</read_iops_sec>
- <write_iops_sec>1000</write_iops_sec>
- </iotune>
- <serial>bb2ccbfb-654a-473e-9f35-ae548c8e59e1</serial>
- <alias name='virtio-disk2'/>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
- </disk>
由xml文件可見在iotune中對讀寫IOPS的控制。
以上總結了Openstack Cinder的QoS的控制,接下來將介紹Nova實現機制。
3.Nova
Nova是Openstack最核心的服務,提供計算服務,其功能類似AWS EC2。官方描述為:
Nova is an OpenStack project designed to provide power massively scalable, on demand, self service access to compute resources.
Nova雖然沒有直接方式對QoS質量進行控制,但我們可以通過主機集合(Host Aggregate)實現,比如我們有兩個計算節點node-1,node-2,配置SSD磁盤,我們創建對應的主機集合并把兩個節點加入到該主機集合中:
- nova aggregate-create ssd nova
- nova aggregate-set-metadata ssd ssd=true
- nova aggregate-add-host ssd node-1
- nova aggregate-add-host ssd node-2
創建一個新的flavor并設置key指定綁定的key-value:
- nova flavor-create ssd.large 6 8192 80 4
- nova flavor-key set_key --name=ssd.large --key=ssd --value=true
查看flavor:
- $ nova flavor-show ssd.large
- +----------------------------+-------------------+
- | Property | Value |
- +----------------------------+-------------------+
- | OS-FLV-DISABLED:disabled | False |
- | OS-FLV-EXT-DATA:ephemeral | 0 |
- | disk | 80 |
- | extra_specs | {u'ssd': u'true'} |
- | id | 6 |
- | name | ssd.large |
- | os-flavor-access:is_public | True |
- | ram | 8192 |
- | rxtx_factor | 1.0 |
- | swap | |
- | vcpus | 4 |
- +----------------------------+-------------------+
此時當用戶指定ssd.large flavor時,調度器將篩選具有ssd=true標簽的計算節點,其余不滿足條件的主機將被過濾掉, 最后在node-1和node-2中選取作為虛擬機的宿主機。
同樣地,Nova可通過flavor的Extra Specs實現QoS量化控制,以下內容直接參考官方文檔-compute flavors:
比如限制IO最大讀寫速率為10MB/s:
- openstack flavor set FLAVOR-NAME \
- --property quota:read_bytes_sec=10240000 \
- --property quota:write_bytes_sec=10240000
除了IO控制,還支持CPU以及內存限制:
CPU
- openstack flavor set FLAVOR-NAME \
- --property quota:cpu_quota=10000 \
- --property quota:cpu_period=20000
內存
- openstack flavor set FLAVOR-NAME \
- --property quota:memory_shares_level=custom \
- --property quota:memory_shares_share=15
設置虛擬機最大的disk寫入數據為10MB/s:
- openstack flavor set FLAVOR-NAME \
- --property quota:disk_write_bytes_sec=10485760
另外,除了QoS控制,Flavor的強大之處遠不止這些,還支持用戶自定義CPU拓撲:
- openstack flavor set FLAVOR-NAME \
- --property hw:cpu_sockets=FLAVOR-SOCKETS \
- --property hw:cpu_cores=FLAVOR-CORES \
- --property hw:cpu_threads=FLAVOR-THREADS \
- --property hw:cpu_max_sockets=FLAVOR-SOCKETS \
- --property hw:cpu_max_cores=FLAVOR-CORES \
- --property hw:cpu_max_threads=FLAVOR-THREADS
以及NUMA 拓撲:
- openstack flavor set FLAVOR-NAME \
- --property hw:numa_nodes=FLAVOR-NODES \
- --property hw:numa_cpus.N=FLAVOR-CORES \
- --property hw:numa_mem.N=FLAVOR-MEMORY
4.Swift
Openstack Swift提供對象存儲服務,功能類似AWS S3以及Ceph RGW,Swift可以通過配置不同的Storage Policies來實現不同性能的后端存儲。具體可參看官方文檔Stroage Policie.
5.Neutron
Neutron是OpenStack項目中負責提供網絡服務的組件,它基于軟件定義網絡(SDN)的思想,實現了網絡虛擬化的資源管理。Neutron支持對虛擬網卡進行帶寬流量限制,主要通過QoS Policy實現,需要在neutron server端配置項service_plugins中開啟qos插件,參考Neutron QoS。
以下內容主要參考官方文檔實例。首先創建一個Qos Policy:
- neutron qos-policy-create bw-limiter
設置帶寬:
- neutron qos-bandwidth-limit-rule-create bw-limiter --max-kbps 3000 \
- --max-burst-kbps 300
通過neutron port-list找到需要限制帶寬的端口(虛擬網卡):
- $ neutron port-list
- +--------------------------------------+----------------------------------+
- | id | fixed_ips |
- +--------------------------------------+----------------------------------+
- | 0271d1d9-1b16-4410-bd74-82cdf6dcb5b3 | { ... , "ip_address": "10.0.0.1"}|
- | 88101e57-76fa-4d12-b0e0-4fc7634b874a | { ... , "ip_address": "10.0.0.3"}|
- | e04aab6a-5c6c-4bd9-a600-33333551a668 | { ... , "ip_address": "10.0.0.2"}|
- +--------------------------------------+----------------------------------+
關聯port和QoS Policy:
- neutron port-update 88101e57-76fa-4d12-b0e0-4fc7634b874a --qos-policy bw-limiter
移除port和Qos Policy的關聯:
- neutron port-update 88101e57-76fa-4d12-b0e0-4fc7634b874a --no-qos-policy
創建port時可以指定QoS Policy:
- neutron port-create private --qos-policy-id bw-limiter
總結
本文詳細介紹了Openstack基礎服務的QoS控制,包括質量控制和量化控制,涉及的內容包括:
- Ceph通過crush map和ruleset選取不同性能的后端存儲設備
- Cinder支持多后端存儲,Volume type綁定具體的后端從而實現不同性能的后端選擇,并且可以自定義QoS實現數據卷的IO讀寫限制。
- Nova可以通過Host Aggregate的Metadata以及Flavor Extra Specs控制調度器選取符合某些特性的(比如SSD)計算節點,通過Flavor Extra Specs實現虛擬機的IO讀寫限制。
- Swift 支持多Policy,通過Storage Policies可以實現不同性能的后端存儲設備。
- Neutron通過Qos Policy完成對虛擬網卡的帶寬限制。
由此可見,Openstack同時支持計算、存儲和網絡的QoS控制,通過QoS控制可以滿足不同應用對不同資源的異構需求。
【本文是51CTO專欄作者“付廣平”的原創文章,如需轉載請通過51CTO獲得聯系】