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

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

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

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

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

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

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

Neutron日志也報錯，如圖2所示。

圖2 Neutron日志報錯提示

在對Neutron分配IP機制進行深入研究后，ICOS網(wǎng)絡(luò)團隊發(fā)現(xiàn)原生社區(qū)分配IP設(shè)計存在缺陷，無鎖設(shè)計必然導(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，進一步加劇了沖突概率。分析如圖3所示。

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

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

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

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

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

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

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

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

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

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

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

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

圖6 ICOS分布式鎖方案效果

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

生成海報

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