如何并發(fā)創(chuàng)建2000虛擬機(jī)？浪潮ICOS分布式鎖方案了解一下

浪潮云海InCloud OpenStack 5.6（ICOS 5.6）于2019年完成單一集群規(guī)模達(dá)500節(jié)點(diǎn)的測(cè)試，驗(yàn)證了商業(yè)發(fā)行版的優(yōu)越性和穩(wěn)定性，為生產(chǎn)環(huán)境部署提供了參考。浪潮陸續(xù)推出了ICOS 5.6對(duì)社區(qū)版的深度優(yōu)化介紹，本篇將分享解決并發(fā)創(chuàng)建2000虛擬機(jī)的秘密。

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

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

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

本次大規(guī)模測(cè)試過(guò)程中，進(jìn)行并發(fā)創(chuàng)建800虛擬機(jī)時(shí)發(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)錯(cuò)，如圖2所示。

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

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

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

針對(duì)這一問(wèn)題，社區(qū)提供的解決方案是為create_port增加retry裝飾器，一旦監(jiān)測(cè)到提交數(shù)據(jù)庫(kù)失敗后重新執(zhí)行create_port來(lái)解決沖突，其默認(rèn)休息0.1秒，最大重試10次。不過(guò)，在并發(fā)規(guī)模過(guò)大時(shí)，由于間隔較短且重試次數(shù)偏少，很容易出現(xiàn)retry次數(shù)耗盡也無(wú)法成功創(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ù)并加長(zhǎng)重試間隔，將設(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ù)增加與間隔延長(zhǎng)帶來(lái)的通信開(kāi)銷(xiāo)與CPU資源占用嚴(yán)重：大批量創(chuàng)建虛擬機(jī)，創(chuàng)建端口時(shí)間有概率增長(zhǎng)，理論最壞情況為[0.5, 1, 2, 4, 8, 10, 10, ... 10] 共165.5秒，需要延長(zhǎng)Nova等待vf_plugged時(shí)間，與此同時(shí)由于最大重試20次，期間Neutron server異常繁忙，占用大量CPU資源。

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

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

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

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

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

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

圖6 ICOS分布式鎖方案效果

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

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書(shū)面權(quán)利通知或不實(shí)情況說(shuō)明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開(kāi)相關(guān)鏈接。