并發(fā)創(chuàng)建虛擬機(jī)是云計(jì)算最常見的應(yīng)用場景之一，幾乎所有的云計(jì)算廠商都有相對成熟的解決方案，可以支持?jǐn)?shù)百規(guī)模的虛擬機(jī)并發(fā)創(chuàng)建。然而當(dāng)并發(fā)規(guī)模突破1000量級后，確保虛擬機(jī)100%成功創(chuàng)建的難度急劇增加，僅有少數(shù)廠商的產(chǎn)品能夠達(dá)到這一水平。

在浪潮基于OpenStack Rocky版本進(jìn)行的全球最大規(guī)模單一集群測試中，浪潮云海InCloud OpenStack 5.6（ICOS5.6）成功完成了100%并發(fā)創(chuàng)建2000虛擬機(jī)的極限挑戰(zhàn)，其首創(chuàng)的分布式鎖方案很好地解決了由于Neutron（OpenStack網(wǎng)絡(luò)組件）瓶頸導(dǎo)致的IP地址沖突問題。

IP地址沖突導(dǎo)致并發(fā)創(chuàng)建800虛擬機(jī)失敗

本次大規(guī)模測試過程中，進(jìn)行并發(fā)創(chuàng)建800虛擬機(jī)時發(fā)現(xiàn)總有失敗出現(xiàn)，不能達(dá)到100%的成功率，查看Nova（OpenStack核心組件，負(fù)責(zé)管理和維護(hù)計(jì)算資源）日志發(fā)現(xiàn)如圖1所示。

圖1 并發(fā)創(chuàng)建800虛擬機(jī)失敗提示

Neutron日志也報(bào)錯，如圖2所示。

圖2 Neutron日志報(bào)錯提示

在對Neutron分配IP機(jī)制進(jìn)行深入研究后，ICOS網(wǎng)絡(luò)團(tuán)隊(duì)發(fā)現(xiàn)原生社區(qū)分配IP設(shè)計(jì)存在缺陷，無鎖設(shè)計(jì)必然導(dǎo)致IP分配產(chǎn)生沖突。沖突產(chǎn)生的根源在于并發(fā)情況下同時讀取ipam_allocate表并分配可用IP（分配完成后并不立即commit到數(shù)據(jù)庫），會大概率導(dǎo)致IP沖突，同時由于create_port_db封裝方式，會將創(chuàng)建port、創(chuàng)建可用IP、可用IP保存到IPS表，這三個事務(wù)共同commit，進(jìn)一步加劇了沖突概率。分析如圖3所示。

圖3 無鎖設(shè)計(jì)導(dǎo)致IP分配產(chǎn)生沖突

針對這一問題，社區(qū)提供的解決方案是為create_port增加retry裝飾器，一旦監(jiān)測到提交數(shù)據(jù)庫失敗后重新執(zhí)行create_port來解決沖突，其默認(rèn)休息0.1秒，最大重試10次。不過，在并發(fā)規(guī)模過大時，由于間隔較短且重試次數(shù)偏少，很容易出現(xiàn)retry次數(shù)耗盡也無法成功創(chuàng)建虛擬機(jī)的情況，浪潮在并發(fā)創(chuàng)建800虛擬機(jī)出現(xiàn)失敗的原因即在于此。

尋找最優(yōu)解 獨(dú)創(chuàng)分布式鎖方案

經(jīng)歷并發(fā)創(chuàng)建800虛擬機(jī)失敗后，ICOS網(wǎng)絡(luò)團(tuán)隊(duì)嘗試增加retry重試次數(shù)并加長重試間隔，將設(shè)置調(diào)整為重試次數(shù)20，間隔0.5秒，實(shí)現(xiàn)了并發(fā)創(chuàng)建800 虛擬機(jī)成功，如圖4所示。

圖4 成功并發(fā)創(chuàng)建800 虛擬機(jī)

但這一優(yōu)化方案并非最優(yōu)解，次數(shù)增加與間隔延長帶來的通信開銷與CPU資源占用嚴(yán)重：大批量創(chuàng)建虛擬機(jī)，創(chuàng)建端口時間有概率增長，理論最壞情況為[0.5, 1, 2, 4, 8, 10, 10, ... 10] 共165.5秒，需要延長Nova等待vf_plugged時間，與此同時由于最大重試20次，期間Neutron server異常繁忙，占用大量CPU資源。

擺在ICOS網(wǎng)絡(luò)團(tuán)隊(duì)面前的問題是，如果800并發(fā)就產(chǎn)生如此高的資源占用，那么在2000并發(fā)的情況下，平臺性能是否足以支撐100%的成功率？有沒有更好的優(yōu)化方案？最終，ICOS網(wǎng)絡(luò)團(tuán)隊(duì)開發(fā)了分布式鎖方案，成功完成了并發(fā)創(chuàng)建2000虛擬機(jī)。

浪潮獨(dú)創(chuàng)的分布式鎖方案采用了新的IPAM_DLM驅(qū)動，引入OpenStack Tooz項(xiàng)目，基于原有的IP分配算法對分配IP過程增加分布式鎖，解決IP分配沖突。

解決IP地址分配沖突問題與酒店辦理入住的場景非常相似，假設(shè)有10名前臺負(fù)責(zé)同時到店的800位客人入住，retry的機(jī)制是前臺僅負(fù)責(zé)隨機(jī)分配房卡，由客人自行前往確認(rèn)該房間是否可以入住，若已有人入住則返回前臺重新分配新房間；而分布式鎖方案的機(jī)制則是所有前臺臨時共享一個獨(dú)立數(shù)據(jù)庫，基于“先到先得”原則，任一房間一旦在數(shù)據(jù)庫中已經(jīng)登記則自動鎖定，確保了每位領(lǐng)到房卡的客人一定可以入住該房間。

IPAM_DLM設(shè)計(jì)序列圖如圖5所示。

圖5 IPAM_DLM設(shè)計(jì)序列圖

在更新Neutron代碼后，采用etcd作為分布式鎖后端，重新測試并發(fā)創(chuàng)建800虛擬機(jī)的平均時長相比優(yōu)化后的retry方案減少了18秒，load duration時間大幅縮短。如圖6所示。

圖6 ICOS分布式鎖方案效果

目前，浪潮已經(jīng)將分布式鎖解決方案作為BP提交社區(qū)，并且得到社區(qū)的認(rèn)可（BP已合入）。隨后，浪潮將正式向社區(qū)提交代碼。