回望二十一世紀已過去的十六個年頭，云計算可謂賺足了風頭，而作為云計算IaaS（基礎設施即服務）模式的新貴，OpenStack打出生起（2010年7月份NASA和Rackspace公司將其開源）便立馬集眾方IT大佬如IBM、Red Hat、HP、Inter等寵愛于一身，一時間IT界眾多門派、各路草莽紛紛出錢出力以促進OpenStack的茁壯成長，而OpenStack不負眾望，以其開源免費、可擴展、高兼容等優良品德立名IT界，迅速坐穩開源云市場占用率頭把交椅。
　　本文將基于OpenStack最新release的liberty版本，分析OpenStack的虛擬機資源調度服務nova-scheduler的調度流程，并逐步說明OpenStack管理員在進行資源調度的錯誤排查過程中的尷尬境遇，然后提出一個OpenStack資源調度錯誤排查的改進方案，最后，本文會為大家展示IBM PRS（Platform Resource Scheduler）基于此方案的實現版本。
　　OpenStack虛擬機的資源調度
　　OpenStack對虛擬機的資源調度由nova模塊的nova-scheduler服務實現，根據調度策略的不同，有兩個插件：基于filter的調度和基于隨機策略的調度，其中基于隨機策略的調度僅對正在服務的host隨機選擇，不進行任何資源審查，在實際生產環境中基本上不會用到，所以本文僅就OpenStack的默認的調度策略：基于filter的調度進行分析。如圖1所示，該策略主要通過三步完成虛擬機的資源調度返回候選host：
　　
　　圖1.基于filter的調度workflow
　　Step 1： 獲取所有host的信息，如果調度請求中要求忽略一些host（ignore hosts），就將這些host從本次的候選host中刪除掉（一種特殊的情況是如果調度請求中要求虛擬機只能調度到一些host或者節點上，則只保留這些host作為候選host，不會對這些host做進一步額外的資源審查即step 2便直接返回）。
　　Step 2： 將第一步中返回的host列表依次迭代地通過scheduler_default_filters配置的所有filter的host_passes處理函數，該函數會過濾掉不滿足相應filter條件的host。
　　Step 3：對第二步返回的host列表根據scheduler_weight_classes配置的weigher對候選host進行排序。
　　至此調度服務完成對虛擬機的資源調度，nova-conductor服務將會向調度服務選出的host所對應的nova-compute服務發出虛擬機部署請求。由于OpenStack調度服務固有的race condition，當虛擬機在compute節點部署失敗時，相應nova-compute服務將會向nova-conductor服務發送重新部署對應虛擬機的請求，用戶可以通過scheduler_max_attempts配置最多可以容忍compute部署失敗的次數，該reschedule機制如圖2所示：
　　
　　圖2.OpenStack資源調度的reschedule機制
　　由上可知，當我們在部署一個虛擬機的時候，本質上有兩類型的錯誤可能導致部署失敗：第一是調度服務發現沒有host可以滿足虛擬機的資源需求，第二是虛擬機在調度服務選出的目標host上部署時因為某種原因部署失敗（如卷請求超時或者網卡創建失敗等等）。我們在虛擬機部署失敗的錯誤排查時，需要從這兩類錯誤類型逐一排查。怎么查呢？當然是看日志（其實也可以首先通過nova show命令查看fault項，但基本上通過這個信息是看不出錯誤所在的），從圖2可以看出，我們應該從nova-conductor的日志開始，然后根據對應錯誤信息決定下一步該看nova-scheduler的日志還是對應nova-compute的日志。下面舉一個最簡單的由第一種錯誤導致虛擬機部署失敗的錯誤排查的例子來說明一下OpenStack原生資源調度的錯誤排查是如何讓管理員望而生畏的。

普通下載普通下載

相關電子資料下載

• Openstack網絡模型場景及代碼解析 161
• 2023年了，OpenStack仍是第三大開源項目 849
• 圖數據庫驅動的基礎設施運維代碼編程案例 83
• openEuler資源利用率提升之道：虛擬機混部OpenStack調度 398
• 使用Ansible的OpenStack自動化 501
• 中國OpenStack往事回望 449
• openEuler社區鄧一諾：實踐是探索和提升的最佳捷徑 663
• 后OpenStack時代的Kubernetes 398
• NestOS實例創建與配置 517
• 開源云基礎設施軟件OpenStack最新版本Yoga發布 1644