OpenStack簡介：OpenStack是旨在為公有及私有云的建設與管理提供軟件的一個開源項目，采用Apache授權協議，它的核心任務是簡化云系統的部署過程，并且賦予其良好的可擴展性和可管理性。它已經在當前的基礎設施即服務(IaaS)資源管理領域占據領導地位，成為公有云、私有云及混合云管理的“云操作系統”事實上的標準，在政府、電信、金融、制造、能源、零售、醫療、交通等行業成為企業創新的利器。OpenStack基于開放的架構，支持多種主流的虛擬化技術，許多重量級的科技公司如RedHat，AT&T，IBM，HP，SUSE，Intel，AMD，Cisco，Microsoft，Citrix，Dell等參與貢獻設計和實現，更加推動了OpenStack的高速成長，打破了Amazon等少數公司在市場上壟斷的局面，解決云服務被單一廠商綁定的問題并降低了云平臺部署成本。
OpenStack資源調度和優化現狀
OpenStack的虛擬機調度策略主要是由FilterScheduler和ChanceScheduler實現的，其中FilterScheduler作為默認的調度引擎實現了基于主機過濾(filtering)和權值計算(weighing)的調度算法，而ChanceScheduler則是基于隨機算法來選擇可用主機的簡單調度引擎。如圖1是FilterScheduler的虛擬機調度過程，它支持多種built-in的filter和weigher來滿足一些常見的業務場景。在設計上，OpenStack基于filter和weigher支持第三方擴展，因此用戶可以通過自定義filter和weigher，或者使用json資源選擇表達式來影響虛擬機的調度策略從而滿足不同的業務需求。
圖1 OpenStack調度workflow
Built-in的filter(部分)：
1 ComputeFilter過濾計算節點down機的主機
2 CoreFilter過濾vcpu不滿足虛擬機請求的主機
3 DiskFilter過濾disk不滿足虛擬機請求的主機
4 RamFilter過濾ram不滿足虛擬機請求的主機
5 ImagePropertiesFilter過濾architecture，hypervisortype不滿足虛擬機請求的主機
6 SameHostFilter過濾和指定虛擬機不在同一個主機上的主機
7 DifferentHostFilter過濾和指定虛擬機在同一個主機上的主機
JsonFilter過濾不滿足OpenStack自定義的json資源選擇表達式的主機：json資源選擇表達式形如query=’[“>”，“$cpus”，4]’表示過濾掉cpus小于等于4的主機
Built-in的weigher(部分)：
1 RAMWeigher根據主機的可用ram排序
2 IoOpsWeigher根據主機的io負載排序
在一個復雜的云系統中，對云計算資源的監控和優化對于保證云系統的健康運行，提高IT管理的效率有重要的作用。最新版本的OpenStack也沒有提供類似的功能，這可能是由于云系統的監控的對象和優化目標對于不同的用戶有不同的要求，難于形成統一實現和架構，但是OpenStack已經意識到這部分的重要性并且啟動了2個項目來彌補這個短板，當前它們都處于孵化階段：
Watcher(https：//github.com/openstack/watcher)：一個靈活的、可伸縮的多租戶OpenStack-based云資源優化服務，通過智能的虛擬機遷移策略來減少數據中心的運營成本和增加能源的利用率。
Congress(https：//github.com/openstack/congress)：一個基于異構云環境的策略聲明、監控，實施，審計的框架。
PRS簡介
由于OpenStack開源的特性，直接投入商業使用可能面臨后期升級，維護，定制化需求無法推進的問題，因此一些有技術實力的公司都基于OpenStack開發了自己商業化的版本，這些商業化版本的OpenStack都包含了一些獨有的特性并和社區開源的OpenStack形成了差異化，比如完善了OpenStack虛擬機的調度和編排功能，加強了云系統的運行時監控和優化，彌補了云系統自動化災難恢復的空缺，簡化了云系統的安裝和部署，引入了基于資源使用時長的帳務費用系統等等。PRS(PlatformResourceScheduler)是IBMPlatformComputing公司的基于OpenStack的商業化資源調度，編排和優化的引擎，它基于對云計算資源的抽象和預先定義的調度和優化策略，為虛擬機的放置動態地分配和平衡計算容量，并且不間斷地監控主機的健康狀況，提高了主機的利用率并保持用戶業務的持續性和穩定性，降低IT管理成本。PRS采用可插拔式的無侵入設計，100%兼容OpenStackAPI，并且對外提供標準的接口，方便用戶進行二次開發，以滿足不同用戶的業務需求。本文將會從虛擬機初始調度策略，實時監控和優化策略，用戶自定義OpenStackFilter，虛擬機調度失敗的TroubleShootingReport和基于拓撲結構調度等方面概括介紹PRS的主要功能和使用場景，之后將有一系列文章對每個主題展開深入介紹。
虛擬機初始調度策略
虛擬機的初始放置策略指的是用戶根據虛擬機對資源的要求決定虛擬機究竟應該創建在哪種類型的主機上，這種資源要求就是一些約束條件或者策略。例如，用戶的虛擬機需要選擇CPU或者內存大小滿足一定要求的主機去放置，虛擬機是需要放置在北京的數據中心還是西安的數據中心，幾個虛擬機是放在相同的主機上還是放置在不同的主機上等等。原生OpenStack調度框架在靈活的支持第三方的filter和weigher的同時也喪失了對調度策略的統一配置和管理，當前PRS支持如圖2的初始放置策略，并且可以在運行時動態的修改放置策略。
圖2 虛似機初始放置策略
- Packing：虛擬機盡量放置在含有虛擬機數量最多的主機上
- Stripping：虛擬機盡量放置在含有虛擬機數量最少的主機上
- CPUlOAdbalance：虛擬機盡量放在可用core最多的主機上
- Memoryloadbalance：虛擬機盡量放在可用memory最多的主機上
- Affinity：多個虛擬機需要放置在相同的主機上
- AntiAffinity：多個虛擬機需要放在在不同的主機上
- CPUUtilizationloadbalance：虛擬機盡量放在CPU利用率最低的主機上
實時監控和優化策略
隨著OpenStack云系統的持續運行，云系統中的計算資源由于虛擬機的放置會產生碎片或分配不均，虛擬機的運行效率由于主機load過載而降低，主機的down機會造成用戶應用程序無法使用等一系列問題。用戶可以通過人工干預的方式來排除這些問題.例如用戶可以將load比較高的主機上的虛擬機migrate到其他主機上來降低該主機的load，通過rebuild虛擬機從down掉的主機上到其它可用主機上解決用戶應用程序高可用性的問題，但這需要消耗大量的IT維護成本，并且引入更多的人為的風險。PRS針對這些問題提供了如圖3的兩種類型的運行時策略來持續的監控和優化云系統。
圖3 監控和優化策略
基于虛擬機的HA策略：當主機down機后，主機上運行的虛擬機會自動rebuild到新的可用主機上
基于主機的LoadBalance策略：支持Packing/Stripping/CPUloadbalance/Memoryloadbalance/CPUUtilizationloadbalance策略，根據用戶設置的閾值持續不斷的平衡系統中主機上的計算資源
用戶可以根據業務需要定義相應的優化策略監控主機的健康狀況并進行持續不斷的優化。例如，用戶定義的集群中主機運行時監控LoadBalance策略是CPUUtilizationLoadBalance，并且閾值是70%，這就意味著當主機的CPU利用率超過70%的時候，這個主機上的虛擬機會被PRS在線遷移到別的CPU利用率小于70%的主機上，從而保證該主機始終處于健康的狀態，并且平衡了集群中主機的計算資源。這兩種運行時監控策略可以同時運行并且可以指定監控的范圍：
整個集群：監控的策略作用于整個集群中所有的主機
Hostaggregation：hostaggregation是OpenStack對一群具有相同主機屬性的一個邏輯劃分，這樣用戶可以根據業務需求對不同的hostaggregation定義不同LoadBalance策略，例如對aggregation1應用Packing策略，對aggregation2應用Stripping策略。
用戶自定義OpenStackFilter
OpenStack對虛擬機的調度是基于對主機的過濾和權值計算，PRS也實現了相同的功能，并且為提供了更加優雅的接口方便用戶定義出復雜的filter鏈，并且配合使用虛擬機初始調度策略從而動態的將用戶自定義的虛擬機放置策略插入到虛擬機的調度過程中去滿足業務需求：
PRSfilter支持定義workingscope：OpenStack原生的filter會默認作用于虛擬機調度的整個生命周期，比如create，livemigrate，coldmigrate，resize等。而PRS為filter定義了workingscope，這樣可以實現讓某些filter在create虛擬機的時候生效，某些filter在虛擬機migrate的時候生效，并且還支持讓一個filter工作在多個workingscope
PRSfilter支持定義includehosts和excludehosts：用戶可以直接在filter中為虛擬機指定需要排除的主機列表或者需要放置的主機列表
PRSfilter支持定義PRS資源查詢條件：用戶也可以在filter中定義PRS資源查詢條件，直接選擇條件具備住主機列表，例如select(vcpu>2&&memSize>1024)
圖4 PRS filter workflow
虛擬機調度失敗TroubleShootingReport
當虛擬機創建失敗處于Error的時候，云系統應該提供足夠的能力方便管理員troubleshooting，從而盡快排除錯誤并保證云系統正常運行。造成虛擬機部署失敗的原因主要有2種：第一種是調度失敗，沒有足夠的計算資源或者合適的主機滿足虛擬機虛擬機的請求。第二種是調度成功，但是在計算節點上部署虛擬機的時候失敗，原因是多種多樣的，比如Libvirt錯誤，image類型錯誤，創建虛擬機網絡失敗等。當前的OpenStack虛擬機的TroubleShooting機制不能清晰反映問題的原因，需要管理員大量的分析工作，這無疑增加了排除問題的難度和時間：
對于虛擬機調度失敗，OpenStack只提供NoValidHost的錯誤異常來表明沒有可用的資源，用戶無法通過CLI(novashow$vm_uuid)得到是哪個filter的約束條件造成調度失敗。
對于部署失敗，管理員需要SSH到失敗的計算節點去檢查日志文件分析失敗原因
PRS提供了troubleshootingreport統一的視圖顯示虛擬機整個生命周期(create/migrate/resize/等)操作失敗的原因如圖5，虛擬機test_vm在第一次創建的時候由于沒有足夠的計算資源或者合適的主機而失敗(“ErrorMessage”選項有失敗原因，”DeployedHost”為空的列表)。由troubleshootingreport的“AvailableHosts”選項可以知道系統中有4臺主機，綠色的方框表示系統中每一個fillter的資源要求和滿足資源要求的主機列表。最終選擇的主機應該被包含在所有filter主機列表中。由ComputeFilter選擇的主機列表不包含主機“my-comp3”，可以得此主機的nov-computeservice可能被關閉，由DiskFilter的主機列表不包含“my-comp1”和主機“my-comp2”可以得知這些主機的可用disk資源不足(<1024MB)，并且這兩個filter選擇的主機沒有交集，因此調度失敗，管理員可以根據這些信息能明確的知道調度失敗的原因從而輕易的排除錯誤。
圖5 Trouble Shooting Report
基于拓撲結構的調度
OpenStackHeat是虛擬機組的編排組件，它本身沒有調度模塊，它基于Nova的FilterScheduler作為調度的引擎對一組或多組虛擬機進行主機級別的扁平化調度和編排，但這種調度模型每次只能處理一個虛擬機請求，當部署多個虛擬機的時候，它不能根據資源請求進行統一的調度和回溯，將會造成調度結果不準確。PRS不但支持主機級別的扁平化調度，還支持對一組同構虛擬機內部或者一組虛擬機和另一組虛擬機在一個樹形拓撲結構上(Region，Zone，Rack，Host)上進行整體調度�；谕負浣Y構的多個虛擬整體調度可以得到一些顯而易見的好處，比如在部署的時候為了拓撲結構上層級之間或虛擬機之間獲得更好的通信性能可以選擇Affinity的策略，為了獲得拓撲結構上層級之間或虛擬機之間的高可用性，可以選擇Anti-Affinity策略。PRS通過和Heat的深度集成實現了基于拓撲結構的整體調度。新的Heat資源類型IBM：：Policy：：Group用來描述這種一組或多組虛擬機在一個樹形的拓撲結構上的部署需求。
Affinity：用來描述一組虛擬機內部的在指定的拓撲結構層級上是Affinity的或者一組虛擬機和另一組虛擬機在指定的拓撲結構層級上是Affinity的。
Anti-Affinity：用來描述一組虛擬機內部的在指定的拓撲結構層級上是Anti-Affinity的或者一組虛擬機和另一組虛擬機在指定的拓撲結構層級上是Anti-Affinity的。
MaxResourceLostPerNodeFailure：用來描述當拓撲結構指定層級發生單點故障時，用戶的一組虛擬機在這個層級上的損失率不能高于一個閾值。
案例1：如圖6，用戶定義了2個autoscalinggrouptier1和tier2，每個tier都需要2個虛擬機，其中tier1需要虛擬機在rack節點上Anti-Affinity，tier2需要虛擬機在rack節點上Affinity，并且tier1和tier2上的虛擬機之間需要滿足Affinity.這個場景類似于在生產環境上部署2組webapplication，要求運行database的虛擬機(tier1)和運行web的虛擬機(tier2)在相同的主機上(方便web服務器和database服務器通信)，并且2個運行database的虛擬機(tier1)和2運行web的虛擬機(tier2)不能同時運行在一臺主機上(rack級別上Anti-Affinity，擔心單rack單點故障造成所有的database服務器或者web服務器都不可用)。
圖的左邊是一個部署的結果，紅色的虛擬機的是web服務器tier1，黃色的虛擬機是database服務器(tier2)，這樣host1上的database服務器直接為host1上的web服務器提供服務，host6上的database服務器直接為host6上的web服務器提供，并且rack1或者rack3的單點故障，不會造成用戶web服務的中斷。
圖6 Affintylanti-Affinity策略
案例2：如圖7，用戶定義了1個autoscalinggrouptier1，這個tier1需要4個虛擬機，要求當zone發生單點故障的時候，用戶的4個虛擬機的損失率不能大于50%。這個場景類似于在生產環境上部署一個Nginx服務器集群，當發生故障時，總有一半的Nginx服務器能夠正常工作。圖的左邊是一個部署的結果，當zon1或者zone2中人任何一個發生故障，用戶的應用程序最多損失2個Nginx服務器，滿足用戶的業務要求，這樣用戶在部署的時候就通過整體優化的虛擬機放置策略實現應用程序的高可用性而不必等節點失敗的時候通過PRSHA策略的監控策略亡羊補牢。
圖7 MaxResourceLostPerNodeFailure策略
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://m.guhuozai8.cn/
本文網址：http://m.guhuozai8.cn/html/consultation/10839719604.html
相關文章
