本系列會介紹OpenStack 企業私有雲的幾個需求：
- 自動擴展（Auto-scaling）支持
- 多租戶和租戶隔離 （multi-tenancy and tenancy isolation）
- 混合雲（Hybrid cloud）支持
- 主流硬件支持、雲快速交付 和 SLA 保證
- 大規模擴展性支持
- 私有雲外圍環境支持（包括支持CDN 、商業SDN控制器、防火牆和VPN/專線等）
- 良好的可使用性（用戶和運維 Dashboard 等）
- 向上擴展性（PaaS 和 SaaS 等支撐）
- 企業數據中心IT環境支持（包括裸金屬/Bare metal、F5 、GPU、跨雲網絡連通、租戶計費、備份等支持）
- 行業解決方案
- 獨立的服務，包括培訓、運維等
彈性是一個真正的雲平台必須具備的五大特征（自助使用、網絡、獨立資源池、快速彈性、服務可計量）之一，它是指一種對資源快速和彈性地提供（擴展），以及同樣對資源快速和彈性地釋放（收縮）的能力。因此，可以認為，彈性是雲平台的一種屬性和能力，而自動擴展（Auto-Scaling）資源即是實現該能力的方法。借助 Auto-Scaling，客戶可以在峰值期間無縫地擴展資源來處理增加的工作負載，並在峰值過后自動減少資源來保持合理的容量和最大程度地降低成本。
1. 擴展（Scale）的概念
1.1 垂直擴展和水平擴展
當一個應用所收到的負載超出了它當前的處理能力時，支撐它的資源必須得到增加。從方向上將，有兩種增加的方式：
- Scale up / Vertically Scale ：垂直擴展。它也有兩種可能：
- 當物理機/虛機目前還有富裕的資源時，向應用分配更多的資源，比如 CPU、內存、網絡帶寬、磁盤等等。這種分配可以是手工或者自動的。
- 當物理機/虛機已經沒有空余的資源時，先向物理機/虛機增加更多的資源，再分配給應用。
- Scale Out /Horizonally Scale：水平擴展。這種擴展方式不是向應用的物理機/虛機增加資源，而是增加其數目，從而增加其服務能力。
下面左圖的垂直擴展實例中，應用所在的虛機的 CPU 從 2 個增加到了 4 個；下面右圖的水平擴展實例中，通過兩次按需水平擴展，虛擬服務器（虛機）數目從1個增加到了3個。
（垂直擴展） （水平擴展）
兩者之間的簡單對比：
| 對比項 | 水平擴展 | 垂直擴展 |
| 成本 | 較低，因為往往可以增加普通商用服務器即可 | 較高，因為單個普通服務器性能總是有限的，因此往往需要專用的服務器 |
| 實時性 | 往往能達到實時性要求 | 部分情況下可以實時，部分情況下需要一些停機時間 |
| 自動化能力 | 往往能較容易地自動擴展 | 往往需要額外的步驟，不太容易實現自動擴展。 |
| 硬件服務器限制 | 不受單個服務器最高容量的限制 | 往往受到單個服務器最高容量的限制 |
| 應用限制 | 對應用有要求，往往要求應用是無狀態的、可橫向擴展的 | 對應用沒有要求，傳統應用和雲原生應用都可以 |
簡單地，可以認為傳統應用往往需要垂直擴展，而新型的雲應用往往需要水平擴展。
1.3 自動擴展
根據上文中的對比，水平擴展比較容易實現自動化，因此，在現在的雲提供商所提供的雲中，往往都是提供很豐富的自動擴展能力，以及小部分垂直擴展能力，比如增加虛機的內存等。下文的介紹都只涉及到水平擴展。
在垂直擴展方面，國內刻通雲有支持實時增加虛機的 CPU 和 內存：“縱向熱擴展：對於支持的操作系統，雲主機可以在不關機和重啟的情況下增加CPU和內存容量。”（來源）
1.3.1 常見實現方式
自動擴展在理論上有多種實現方式，比如 基於閾值的規則（threshold-based rules）、 增強型學習（reinforcement learning or Q-learning (RL)）、 隊列理論（queuing theory）、控制理論和時間序列分析（control theory and time series analysis）等等。
其中，基於閾值的規則 在目前的雲中實現得較為普遍，比如亞馬遜的Cloud Watch。在這種實現方式中，要將水平擴展自動化，往往需要一個管理軟件，它包括以下幾個基本模塊：
- 擴展觸發模塊：往往包括定時觸發模塊，以及根據系統狀態觸發，比如通過對 CPU、內存、網絡帶寬等做持續監測然后根據定義的不同策略來觸發擴展。
- IT資源編排模塊：在被調用的時候，可以增加或者減少服務器
- 負載均衡模塊：將運行在多個服務器中的服務虛擬化為一個虛擬服務
不同的雲服務供應商都有自己實現這種管理軟件的方式，下文將會仔細分析當前比較流行的實現，比如阿里雲、亞馬遜和OpenStack 中的實現方式。
1.3.2 自動擴展的目標
理論上，自動擴展的目標包括所有類型的資源，包括計算、存儲、網絡資源等。目前，應用較多的、實現得較為完善的為計算資源即虛機的自動擴展。
1.3.3 自動擴展的模式
彈性伸縮模式主要分為以下幾類：
- 定時模式：配置周期性任務（如每天 13：00），定時地增加或減少實例。
- 動態模式：基於雲監控性能指標（如 CPU 利用率），自動增加或減少實例。
- 固定數量模式：通過“最小實例數”屬性，可以讓用戶始終保持健康運行的實例數量，以保證日常場景實時可用。
- 自定義模式：根據用戶自有的監控系統，通過 API 手工伸縮實例。
- 健康模式：如實例為非運行狀態，將自動移出或釋放該不健康的實例。
2. 公有雲上的自動擴展功能
2.1 亞馬遜（AWS）彈性伸縮服務
亞馬遜彈性計算雲（EC2，Elastic Compute Cloud）在 2009 年就發布了實現彈性的特性，包括：
- 用於監測的 CloudWatch：一項針對 AWS 雲資源和在 AWS 上運行的應用程序進行監控的服務，使用戶可以了解到資源使用、操作性能和總體需求狀況，包括CPU使用、磁盤讀寫和網絡流量等指標。
- 自動伸縮的 Auto Scaling：允許EC2的容量根據需求增大或減小，保證EC2在流量高峰時增容以維持其性能，在流量較低時減容以節省成本，此特性對於使用率波動頻繁的程序來說尤其適用。它由 Amazon CloudWatch 啟用，無需額外費用。
- 彈性負荷調節 Elastic Load Balancing（ELB）：在各EC2計算實例之間分配流量，允許程序出錯，它還能夠在資源池中探測出運行不正常的實例，並引導信息流通過正常實例前進，直到不正常實例被修復。
2.1.1 基本概念和流程
AWS 的 Auto Scaling 的基本概念和流程如下圖所示：
其中，Auto Scaling groups，即伸縮組，包含若干虛機，可以跨可用域。用於可以設置其（1）最小虛機數目（2）最大虛機數目（3）期望虛機數目（4）
2.1.2 Scaling Policy （擴展策略）
（1）簡單擴展策略（Simple Scaling Policy）及問題：評估（evaluation period）- 告警發出 （alarm）- 擴展（scale out/down）- 冷卻（cool down）
這種策略的問題是，一個完整的周期內，系統是不會發出新的告警的，直到當前周期處理結束。那么，可能的問題是，當前處理周期還沒結束，系統就因為扛不住超大的負載而宕機了：
（2）亞馬遜的分步擴展策略（Step Scaling Policy）
2015 年，亞馬遜為了解決上述問題，上線了分步擴展策略（Auto Scaling Update – New Scaling Policies for More Responsive Scaling）。其特征如下：
- 一個策略中定義多個步驟
- 沒有鎖定，而是持續評估和告警
- 根據告警，從多個步驟中選擇最合適的步驟來執行
- 不支持 cooldown
結果和比較：
AWS 的推薦策略：When in doubt, prefer step scaling policies （當你有疑惑時，請使用 step scaling policy）。
2.1.3 Netfix 使用 AWS Auto-scaling 服務的經驗教訓（lesson learnt）
- Scale up early：早 Scale up，建議將 CloudWatch 告警的閾值設置為 75%，並且需要考慮虛機創建所需要的時間和應用啟動所需要的時間。
- Scaling down slowly：晚 Scale down，這樣可以減少虛機數量減少帶來的風險。比如， 在虛機 CPU 使用率高於60% 持續五分鍾后，scale up 10%；在 CPU 使用率低於 30% 並持續 20分鍾后，scale down 10%。
- When NOT to use Percent Based Auto scaling：對於小規模的自動伸縮組，不要使用基於百分比的自動伸縮策略。
- 伸和縮策略使用相同的調整量：比如伸縮比例都設置為 10%，這么做可以避免”容量顛簸 capacity thrashing“。
2.2 阿里雲彈性伸縮服務（Elastic Scaling Service - ESS）
（阿里雲官網鏈接）
阿里雲的彈性伸縮服務（Elastic Scaling Service）是根據用戶的業務需求和策略，自動調整其彈性計算資源的管理服務。用戶根據自己的業務需求自動調整其彈性計算資源，在滿足業務需求高峰增長時無縫地增加 ECS 實例，並在業務需求下降時自動減少 ECS 實例以節約成本。目前，阿里雲的該產品是免費提供給客戶使用的，但是目前一個用戶最多只能創建20個伸縮組。
2.2.1 基本功能
基本功能除了動態增加或者減少ECS實例外，還包括其它附加功能，比如在增加或減少 ECS 實例時，自動向 SLB（彈性負載均衡器） 實例中添加或移除相應的 ECS 實例；以及 自動向 RDS（關系數據庫） 訪問白名單中添加或移出該 ECS 實例的 IP。可見，阿里雲所實現的方式正是亞馬遜在2015年之前實現的方式。
2.2.2 基本概念和流程
2.2.3 應用示例
ESS 作為雲平台基礎服務之一，幾乎在阿里雲的各種解決方案中都能看到它的身影。比如多媒體解決方案中，流媒體轉碼集群和服務集群都是具有自動伸縮能力的集群。
（資源來源）
目前本人還沒有機會試用阿里雲的ESS服務。從官網的介紹來看，該服務是2015年8月27日正式開放上線，因此其功能還比較簡單，只是提供了最基本的能力，比如從可以查找到的渠道來看，其監控指標只是包括傳統的如CPU、內存利用率等指標；而且一個用戶只能使用有限的ESS組。
3. OpenStack 中的 Auto-scaling
3.1 當前版本中的實現：Heat + Ceilometer + Neutron LBaaS V1
3.1.1 原理
目前 OpenStack 實現的是類似 AWS 的自動擴展架構：
- Ceilometer：類似於 AWS CloudWatch，監控指定的虛機的各種指標，並根據告警策略發出告警。
- Neutron LBaaS：類似於 AWS ELB，提供虛擬的負載均衡器
- Heat：類似於 AWS Auto Scaling，提供自動擴展功能，以及承擔編排器角色。它通過 HOT 創建所有需要的對象，包括 Ceilometer alarm。
3.1.2 簡單例子：僅使用 Heat + Ceilometer
（1）定義 heat HOT 文件 simple-no-lb.yaml，內容如下
heat_template_version: 2016-02-16
description: A simple auto scaling group by Sammy Liu resources: group: type: OS::Heat::AutoScalingGroup #定義自動擴展組 properties: cooldown: 60 #冷卻時間，單位秒 desired_capacity: 2 #起始組內虛機數目 max_size: 5 #組內最大虛機數目 min_size: 1 #組內最小虛機數目 resource: type: OS::Nova::Server #組內資源即虛機的類型 properties: image: 'cirros' #虛機所使用的Glance 鏡像的名稱 metadata: {"metering.stack": {get_param: "OS::stack_id"}} #設置虛機的元數據 'metering.stack' 為 heat stack ID flavor: m1.tiny networks: - network: sammynet1
scaleup_policy: #向上擴展策略 type: OS::Heat::ScalingPolicy properties: adjustment_type: change_in_capacity #heat 支持三種調整方式：change_in_capacity (new = current + adjustment), exact_capacity (new = adjustment), percent_change_in_capacity (在current 的基礎上上按照 adjustment 的 百分比調整) auto_scaling_group_id: {get_resource: group} #該 policy 的 group 就是上面定義的 'group ' cooldown: 60 #冷卻時間 scaling_adjustment: 1 #每次的調整量 cpu_alarm_high: #定義一個 ceilometer alarm type: OS::Ceilometer::Alarm properties: meter_name: cpu_util #監控虛機的 cpu_util statistic: avg #statistic 的計算方法為 avg 即平均值法 period: 60 #統計周期 evaluation_periods: 1 #連續幾個周期才算有效 threshold: 50 #cpu_util 的閾值 alarm_actions: #該告警在alarm 狀態時的 action。還可以定義象 ok_actions, insufficient_data_actions 等等 - {get_attr: [scaleup_policy, alarm_url]} matching_metadata: {'metadata.user_metadata.stack': {get_param: "OS::stack_id"}} #設置 ceilometer statistic 的計算方位為元數據 ‘metering.stack' 為 stack id 的虛機 comparison_operator: gt #檢測值和閾值的比較方式為 gt 即大於
（2）創建 heat stack
heat stack-create -f simple-no-lb.yaml simple-no-lb
（3）創建成功后生成的 heat resource 和兩個虛機
root@hkg02kvm004ccz023:/home/sammy# heat stack-list +--------------------------------------+----------------------+-----------------+----------------------+--------------+ | id | stack_name | stack_status | creation_time | updated_time | +--------------------------------------+----------------------+-----------------+----------------------+--------------+ | 51f3ec34-8914-475d-b9df-c50be7893041 | simple-no-lb | CREATE_COMPLETE | 2016-02-21T14:17:13Z | None | +--------------------------------------+----------------------+-----------------+----------------------+--------------+
root@hkg02kvm004ccz023:/home/sammy# heat resource-list 51f3ec34-8914-475d-b9df-c50be7893041 +----------------+--------------------------------------+----------------------------+-----------------+----------------------+ | resource_name | physical_resource_id | resource_type | resource_status | updated_time | +----------------+--------------------------------------+----------------------------+-----------------+----------------------+ | cpu_alarm_high | 76a82c7a-89e0-4888-bd0a-0c7e2c70df29 | OS::Ceilometer::Alarm | CREATE_COMPLETE | 2016-02-21T14:17:13Z | | group | f7d2c038-a955-4930-b757-3a12a22640c4 | OS::Heat::AutoScalingGroup | CREATE_COMPLETE | 2016-02-21T14:17:13Z | | scaleup_policy | 5a5fdfc1b396403aa5d010e3a79d2eb3 | OS::Heat::ScalingPolicy | CREATE_COMPLETE | 2016-02-21T14:17:13Z | +----------------+--------------------------------------+----------------------------+-----------------+----------------------+
三個資源中：group （AutoScalingGroup）被 scaleup_policy （ScalingPolicy） 所使用，scaleup_policy 被 cpu_alarm_high （Ceilometer::Alarm） 使用。
（4）alarm的細節
root@hkg02kvm004ccz023:/home/sammy# ceilometer alarm-show 76a82c7a-89e0-4888-bd0a-0c7e2c70df29 +---------------------------+--------------------------------------------------------------------------+ | Property | Value | +---------------------------+--------------------------------------------------------------------------+ | alarm_actions | [u'https://devci23.open-test.ibmcloud.com:8000/v1/signal/arn%3Aopenstack | | | %3Aheat%3A%3Abd6b9346393d469eb52734bc3ed42b3c%3Astacks%2Fsimple-no- | | | lb%2F51f3ec34-8914-475d-b9df-c50be7893041%2Fresources%2Fscaleup_policy?T | | | imestamp=2016-02-21T14%3A17%3A12Z&SignatureMethod=HmacSHA256&AWSAccessKe | | | yId=0211a96fd1114eca9d4da8167fbdae5a&SignatureVersion=2&Signature=ji0r5c | | | vQGAIEGkmkCiehxHTCBsDr4jfecv%2BHia6aSbg%3D'] | | alarm_id | 76a82c7a-89e0-4888-bd0a-0c7e2c70df29 | | comparison_operator | gt | | description | Alarm when cpu_util is gt a avg of 50.0 over 60 seconds | | enabled | True | | evaluation_periods | 1 | | meter_name | cpu_util | | name | simple-no-lb-cpu_alarm_high-leb4nvtkincw | | period | 60 | | project_id | bd6b9346393d469eb52734bc3ed42b3c | | query | metadata.user_metadata.stack == 51f3ec34-8914-475d-b9df-c50be7893041 | | statistic | avg | | threshold | 50.0 | | type | threshold | +---------------------------+--------------------------------------------------------------------------+
Ceilometer 的 statistics 方法：
root@hkg02kvm004ccz023:/home/sammy# heat output-show 51f3ec34-8914-475d-b9df-c50be7893041 ceilometer_statistics_query "ceilometer statistics -m cpu_util -q metadata.user_metadata.stack=51f3ec34-8914-475d-b9df-c50be7893041 -p 60 -a avg\n"
root@hkg02kvm004ccz023:/home/sammy# ceilometer statistics -m cpu_util -q metadata.user_metadata.stack=51f3ec34-8914-475d-b9df-c50be7893041 -p 60 -a avg +--------+---------------------+---------------------+---------------+----------+---------------------+---------------------+ | Period | Period Start | Period End | Avg | Duration | Duration Start | Duration End | +--------+---------------------+---------------------+---------------+----------+---------------------+---------------------+ | 60 | 2016-02-21T14:29:31 | 2016-02-21T14:30:31 | 4.8197740113 | 10.0 | 2016-02-21T14:30:01 | 2016-02-21T14:30:11 | | 60 | 2016-02-21T14:30:31 | 2016-02-21T14:31:31 | 4.73989071038 | 11.0 | 2016-02-21T14:31:01 | 2016-02-21T14:31:12 | | 60 | 2016-02-21T14:31:31 | 2016-02-21T14:32:31 | 4.81666666667 | 11.0 | 2016-02-21T14:32:01 | 2016-02-21T14:32:12 | +--------+---------------------+---------------------+---------------+----------+---------------------+---------------------+
（4）簡要過程
（a）Ceilometer 每個 60s 運行 "ceilometer statistics -m cpu_util -q metadata.user_metadata.stack=51f3ec34-8914-475d-b9df-c50be7893041 -p 60 -a avg\n"，求得其 avg 值，和閾值 50.0 比較。如果大於 50.0，則發出 alarm。注意這里只統計虛機的元數據 ‘metering.stack’ 的值為 stack id 即 "51f3ec34-8914-475d-b9df-c50be7893041" 的所有虛機。
（b）該 alarm 的 action 是 ‘https://devci23.open-test.ibmcloud.com:8000/v1/signal/arn%3Aopenstack%3Aheat%3A%3Abd6b9346393d469eb52734bc3ed42b3c%3Astacks%2Fsimple-no-lb%2F51f3ec34-8914-475d-b9df-c50be7893041%2Fresources%2Fscaleup_policy?Timestamp=2016-02-21T14%3A17%3A12Z&SignatureMethod=HmacSHA256&AWSAccessKeyId=0211a96fd1114eca9d4da8167fbdae5a&SignatureVersion=2&Signature=ji0r5cvQGAIEGkmkCiehxHTCBsDr4jfecv%2BHia6aSbg%3D’，其實是調用 heat 的 scaleup_policy，並傳入了幾個包括 Timestamp的參數。
（c）heat 的 scaleup_policy 被觸發，計算新的虛機數目 new_capacity，然后調用 resize（new_capacity）來將 instance group 的 capacity 調整為 new_capacity。
3.1.3 OpenStack Kilo 版本中的 Neutron LBaaS V1 和 V2
目前（Kilo 和 Liberty 版本）Heat 只支持 Neutron LBaaS V1， V2 的支持將會在 M 版本中添加。在我的環境中，之前已經通過從 github neutron_lbaas xiangm 上拉取 Neutron LBaaS Kilo stable 代碼的方法並且在使用 V2 版本。為了能夠支持 Auto-scaling，需要將其降低到 V1 版本。下面簡要描述其過程。 （關於直接安裝 V1 版本，可以參考我的另一篇文章 Neutron 理解 (7): Neutron 是如何實現負載均衡器虛擬化的 [LBaaS V1 in Juno]）.
（0）代碼的根目錄的路徑：
- neutron_lbaas 代碼：/opt/bbc/openstack-11.0-bbc148/neutron/lib/python2.7/site-packages/neutron_lbaas
- neutron 代碼：/opt/bbc/openstack-11.0-bbc148/neutron/lib/python2.7/site-packages/neutron
（1）修改配置文件
/etc/neutron/neutron.conf：
service_plugins = neutron.services.l3_router.l3_router_plugin.L3RouterPlugin,neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPlugin
/etc/neutron/neutron_lbaas.conf：
service_provider = LOADBALANCER:Haproxy:neutron_lbaas.services.loadbalancer.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default
/etc/neutron/services/loadbalancer/haproxy/lbaas_agent.ini
interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver
（2）創建 /usr/local/bin/neutron-lbaas-agent 可執行文件
import sys from neutron_lbaas.services.loadbalancer.agent.agent import main if __name__ == "__main__": sys.exit(main())
（3）創建 neutron-lbaas-agent 服務
創建 /etc/init.d/neutron-lbaas-agent 文件
ln -s /lib/init/upstart-job /etc/init.d/neutron-lbaas-agent
創建 /etc/init/neutron-lbaas-agent.conf 文件：
start on starting neutron-linuxbridge-agent stop on stopping neutron-linuxbridge-agent env REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt respawn exec start-stop-daemon --start --chuid neutron --exec /usr/local/bin/neutron-lbaas-agent -- --config-dir /etc/neutron --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/services/loadbalancer/haproxy/lbaas_agent.ini --config-file /etc/neutron/neutron_lbaas.conf
（4）在控制節點重啟 neutron-server 服務，在網絡節點啟動 neutron-lbaas-agent 服務
neutron 2257 1 0 08:36 ? 00:01:04 /opt/bbc/openstack-11.0-bbc148/neutron/bin/python /usr/local/bin/neutron-lbaas-agent --config-dir /etc/neutron --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/services/loadbalancer/haproxy/lbaas_agent.ini --config-file /etc/neutron/neutron_lbaas.conf
需要注意的是：
（1）設置 service_plugins 和 service_provider 需要注意 V1 所使用的類的路徑。neutron-lbaas 項目中，V1 和 V2 代碼混雜在一起，所有到處都是同樣名稱的文件和類，在不同的目錄下，分別被V1 和 V2 使用。
（2）Neutron 的 V1 和 V2 lbaas agent 不可以同時運行。
（3）neutron-lbaas-agent 服務文件的創建，可以參考 neutron-lbaasv2-agent 的各文件
（4）neutron-server 和 neutron-lbaas（v2）-agent 的修改必須同步，否則會出現 agent 和 server 無法通信的情況
3.1.4 綜合例子：使用 Heat + Ceilometer + Neutron LBaaS V1
（1）幾個 Heat HOT 文件
simple. yaml：
heat_template_version: 2014-10-16 description: A simple auto scaling group. resources: group: type: OS::Heat::AutoScalingGroup properties: cooldown: 60 desired_capacity: 2 max_size: 5 min_size: 1 resource: type: OS::Nova::Server::Cirros #在 lb_server.yaml 中定義的一個新類型 properties: image: 'cirros' metadata: {"metering.stack": {get_param: "OS::stack_id"}} flavor: m1.tiny pool_id: {get_resource: pool} network_id: sammynet1 scaleup_policy: type: OS::Heat::ScalingPolicy properties: adjustment_type: change_in_capacity auto_scaling_group_id: {get_resource: group} cooldown: 60 scaling_adjustment: 1 scaledown_policy: #新增資源收縮策略 type: OS::Heat::ScalingPolicy properties: adjustment_type: change_in_capacity auto_scaling_group_id: {get_resource: group} cooldown: 60 scaling_adjustment: -1 #虛機數據減一
cpu_alarm_high: type: OS::Ceilometer::Alarm properties: meter_name: cpu_util statistic: avg period: 60 evaluation_periods: 1 threshold: 50 alarm_actions: - {get_attr: [scaleup_policy, alarm_url]} matching_metadata: {'metadata.user_metadata.stack': {get_param: "OS::stack_id"}} comparison_operator: gt cpu_alarm_low: #新增檢測值低於閾值告警 type: OS::Ceilometer::Alarm properties: description: Scale-down if the max CPU < 30% for 60 secs meter_name: cpu_util statistic: avg period: 60 evaluation_periods: 1 threshold: 30 #閾值為 30 alarm_actions: - {get_attr: [scaledown_policy, alarm_url]} matching_metadata: {'metadata.user_metadata.stack': {get_param: "OS::stack_id"}} comparison_operator: lt #比較方法為”小於“ monitor: # 定義 Neutron LbaaS 的 health monitor type: OS::Neutron::HealthMonitor properties: type: TCP #注意 HAProxy 其實是不支持 PING 的 delay: 10 max_retries: 5 timeout: 10
pool: #定義 Neutron LbaaS Pool type: OS::Neutron::Pool properties: protocol: HTTP monitors: [{get_resource: monitor}] #關聯 monitor 和 pool subnet_id: 66a47602-f419-4e40-bec8-929ee0c99302 lb_method: ROUND_ROBIN vip: protocol_port: 80 subnet: sammysubnet1 lb: type: OS::Neutron::LoadBalancer properties: protocol_port: 80 pool_id: {get_resource: pool} #關聯 lb（vip）和 pool # assign a floating ip address to the load balancer pool. #給 vip（lb）分配一個浮動IP lb_floating: type: OS::Neutron::FloatingIP properties: floating_network_id: 8f361a34-52bf-4504-a11b-30c53c0a7bb8 port_id: {get_attr: [pool, vip, port_id]}
lb-server.yaml：
description: A load-balancer server parameters:
#定義 image、flavor、pool_id、network_id、user_data 和 metadata 等幾個參數
... resources: server: type: OS::Nova::Server properties: flavor: {get_param: flavor} image: {get_param: image} metadata: {get_param: metadata} networks: - network: {get_param: network_id} user_data: {get_param: user_data} user_data_format: {get_param: user_data_format} member: type: OS::Neutron::PoolMember properties: pool_id: {get_param: pool_id} #將 member 加入 pool 中 address: {get_attr: [server, first_address]} protocol_port: 80
env.yaml：
resource_registry: "OS::Nova::Server::Cirros": "lb-server.yaml"
（2）創建 heat stack
結果除了兩個虛機外，還有如下的 heat resource：
root@hkg02kvm004ccz023:~# heat resource-list f27cde5a-efa3-4d40-a76f-e0f69331e75b +------------------+--------------------------------------+----------------------------+-----------------+----------------------+ | resource_name | physical_resource_id | resource_type | resource_status | updated_time | +------------------+--------------------------------------+----------------------------+-----------------+----------------------+ | cpu_alarm_high | 6297a648-978f-4781-89fa-65d6492f862b | OS::Ceilometer::Alarm | CREATE_COMPLETE | 2016-02-19T13:57:46Z | | cpu_alarm_low | 50d4c4ad-7c1a-4d23-a308-0091002532f9 | OS::Ceilometer::Alarm | CREATE_COMPLETE | 2016-02-19T13:57:46Z | | group | b6a2862d-7723-40d8-b1c1-2a15f0814f58 | OS::Heat::AutoScalingGroup | CREATE_COMPLETE | 2016-02-19T13:57:46Z | | lb | | OS::Neutron::LoadBalancer | CREATE_COMPLETE | 2016-02-19T13:57:46Z | | lb_floating | 3a6e3d4e-aace-4930-b98c-7b2ac81b54ac | OS::Neutron::FloatingIP | CREATE_COMPLETE | 2016-02-19T13:57:46Z | | monitor | 939aaafd-4efc-4130-b71e-fe6caab2025a | OS::Neutron::HealthMonitor | CREATE_COMPLETE | 2016-02-19T13:57:46Z | | pool | dd41f00a-8928-4c05-bfc3-b3824d9ef7e0 | OS::Neutron::Pool | CREATE_COMPLETE | 2016-02-19T13:57:46Z | | scaledown_policy | 640e97fa3aff445aa0df086737587a12 | OS::Heat::ScalingPolicy | CREATE_COMPLETE | 2016-02-19T13:57:46Z | | scaleup_policy | 21d42d330144473dbe691d366b1fff21 | OS::Heat::ScalingPolicy | CREATE_COMPLETE | 2016-02-19T13:57:46Z | +------------------+--------------------------------------+----------------------------+-----------------+----------------------+
（3）簡要自動伸縮過程
- 在2個虛機內都啟動 HTTP 服務
- pool 內的2個虛機的平均 cpu_util 超過 50%，增加一個虛機，總虛機數目達到3，並加入到 Neutron LB pool 中成為一個新的 member
- 繼續檢測，發現3個虛機的平均 cpu_util 仍然超過 50%，增加一個虛機，總虛機數目達到4，並加入到 Neutron LB pool 中成為一個新的 member
- 繼續檢測，經過一段時間后，發現4個虛機的平均 cpu_util 低於 30%，減少一個虛機，總虛機數目下降為 3，並將其從 Neutron LB pool 中刪除
- 繼續檢測，3 個虛機的瓶頸 cpu_util 穩定在 40 左右，不再執行自動伸縮
注：以上兩個例子，只是測試和驗證用例，真正在生產環境使用中，還有更多的事情要做。
3.2 Auto-scaling 在將來的實現
曾經和社區 Heat 人士（IBM 北京研究院 Tent Qi Ming 博士，Heat Core member，Senlin 發起人之一）進行過交流，大概意思如下：
- 目前 Heat 中的 Auto-scaling 是依照 AWS 的 Auto-scaling 實現的，在實際應用中存在不足
- Heat 認為 Auto-scaling 不是它的 mission 范圍內，它的主要和唯一的任務是提供 OpenStack 資源編排接口
- Heat 在將來不會繼續增加 Auto-scaling 功能，除了在 M 版本支持 Neutron LBaaS V2 外
- 將來 Auto-scaling 功能將會在新的項目 Senlin 中實現。在項目在 2015年5月發布，它提供 OpenStack Clustering（集群）功能，可以實現包括 Auto-scaling、HA、負載均衡（load-balancing） 等功能
和正在實現 Heat 支持 LBaaS V2 的團隊交流的結果：
- M 版本中 LBaaS V1 將繼續保留，N 版本是否刪除待定
- LBaaS V1 的主要問題是擴展性
- M 版本之前基於 LBaaS V1 創建的 Heat stack 和虛機，無法在 M 版本中向新的 Heat 和 LBaaS V2 平滑遷移
參考鏈接
- 阿里雲彈性伸縮服務入門指南
- AWS Auto Scaling
- 探索 OpenStack 之（16）：計量模塊 Ceilometer 介紹及優化
- 探索 OpenStack 之（17）：計量模塊 Ceilometer 中的數據收集機制
- Neutron 理解 (7): Neutron 是如何實現負載均衡器虛擬化的 [LBaaS V1 in Juno]