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

电信下载联通下载

相關(guān)電子資料下載

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