抽絲剝繭揭開Hyper-V虛機(jī)網(wǎng)絡(luò)阻塞真相

中國移動(dòng)通信集團(tuán)沈陽分公司│張永濤

抽絲剝繭揭開Hyper-V虛機(jī)網(wǎng)絡(luò)阻塞真相

中國移動(dòng)通信集團(tuán)沈陽分公司│張永濤

在Hyper-V虛擬機(jī)搭建故障轉(zhuǎn)移群集過程中，出現(xiàn)了網(wǎng)絡(luò)阻塞、數(shù)據(jù)丟包情況，為排除此故障，中國移動(dòng)沈陽分公司模擬了10種場景分別測試，最終找到了網(wǎng)絡(luò)適配器與“虛擬機(jī)隊(duì)列”功能不兼容的根源所在。

近兩年，云計(jì)算與虛擬化技術(shù)日臻成熟，在電信運(yùn)營商的很多應(yīng)用場景中都引用了虛擬機(jī)（Virtual Machine）技術(shù)。目前在虛擬技術(shù)領(lǐng)域，主要存在著兩大技術(shù)流派，它們分別是VMware的VMware ESX和微軟的Hyper-V。沈陽移動(dòng)公司采用的是Hyper-V技術(shù)路線。在2015年初，我公司購入了4臺HP DL585服務(wù)器和Windows Server 2012標(biāo)準(zhǔn)版，準(zhǔn)備搭建SQL Server 2014數(shù)據(jù)庫群集，為上層應(yīng)用系統(tǒng)提供更好服務(wù)。

在搭建數(shù)據(jù)庫群集的過程中，我們在4臺物理服務(wù)器上安裝了Windows Server 2012操作系統(tǒng)，然后分別安裝Hyper-V角色。在每臺服務(wù)器上分別創(chuàng)建了3臺Hyper-V虛擬機(jī)。但在搭建過程中，我們發(fā)現(xiàn)Hyper-V虛擬機(jī)對外部通信時(shí)經(jīng)常發(fā)生阻塞現(xiàn)象，尤其當(dāng)系統(tǒng)中有大數(shù)據(jù)涌入時(shí)，一定會發(fā)生大量丟包現(xiàn)象，并且造成嚴(yán)重的網(wǎng)絡(luò)阻塞。如何解決此類問題，沈陽移動(dòng)為此進(jìn)行了大量試驗(yàn)，反復(fù)論述其分析、測試的場景，并通過“虛擬機(jī)隊(duì)列”機(jī)制，提出了解決以上問題的兩種方法，供業(yè)界參考。

物理宿主機(jī)配置

在提供解決方案之前，首先介紹一下沈陽移動(dòng)的IT系統(tǒng)運(yùn)行環(huán)境。

服務(wù)器型號HP DL585、4塊CPU、32GB內(nèi)存，配置4個(gè)千兆以太網(wǎng)端口；網(wǎng)卡型號NC375i，網(wǎng)卡芯片型號Broadcom NetXtreme Gigabit Ethernet；驅(qū)動(dòng)程序版本號15.6.1.3，驅(qū)動(dòng)文件名b57nd60a.sys；操作系統(tǒng)為Windows Server 2012標(biāo)準(zhǔn)版，安裝文件名SW_DVD9_Windows_ Svr_Std_and_DataCtr_2012_R2_64Bit_ChnSimp_-3_ MLF_X19-53577.ISO；安裝Hyper-V角色，建立一個(gè)外部交換機(jī)EVS；防火墻全部關(guān)閉，網(wǎng)絡(luò)環(huán)境為千兆以太網(wǎng)（物理服務(wù)器網(wǎng)絡(luò)拓?fù)湟妶D1）。

虛擬機(jī)配置

3臺虛擬機(jī)硬件配置：二代Hyper-V、8核CPU、10GB內(nèi)存、127GB硬盤。操作系統(tǒng)安裝的是Windows Server 2012標(biāo)準(zhǔn)版，安裝SQL Server 2014企業(yè)版數(shù)據(jù)庫。安裝文件名是SW_DVD9_SQL_Svr_Ent_Core_2014_64Bit_ ChnSimp_MLF_X19-34249.ISO。網(wǎng)卡是Microsoft Hyper-V 網(wǎng)適配器。防火墻全部關(guān)閉。

組網(wǎng)方式是建立外部虛擬交換機(jī)。虛擬機(jī)通過外部虛擬交換機(jī)EVS、虛擬網(wǎng)絡(luò)適配器VEA、物理網(wǎng)絡(luò)適配器EA連接服務(wù)器OM（虛擬機(jī)網(wǎng)絡(luò)拓?fù)湟妶D2）。

網(wǎng)絡(luò)阻塞問題癥結(jié)

在搭建完數(shù)據(jù)庫群集后，我們發(fā)現(xiàn)數(shù)據(jù)在遷移過程中出現(xiàn)了問題。在服務(wù)器VM1數(shù)據(jù)庫上操作，從舊服務(wù)器OM導(dǎo)入數(shù)據(jù)時(shí)，發(fā)現(xiàn)數(shù)據(jù)傳輸很慢。從PC機(jī)Ping服務(wù)器VM1，延時(shí)非常嚴(yán)重，達(dá)到time=200ms左右，并出現(xiàn)丟包現(xiàn)象。在千兆以太網(wǎng)環(huán)境下，這個(gè)速度幾乎不可想象。但此時(shí)Ping物理服務(wù)器PM1，time＜1ms，網(wǎng)絡(luò)卻沒有延時(shí)。

為了找到問題所在，沈陽移動(dòng)IT部門嘗試了多種方式，并采用了2種數(shù)據(jù)傳輸方式，模擬出10種場景進(jìn)行測試。以下列舉5種場景數(shù)據(jù)進(jìn)行分析（五大場景測試結(jié)果見表1）。

場景一在數(shù)據(jù)庫上操作，從服務(wù)器OM向服務(wù)器VM1導(dǎo)入數(shù)據(jù)時(shí)，從PC機(jī)ping服務(wù)器VM1，此時(shí)平均延時(shí)達(dá)到200ms左右，延時(shí)在30ms ＜ time ＜ 250ms之間。數(shù)據(jù)丟包率達(dá)20%。

ping 10.65.28.73 -t發(fā)現(xiàn)：延時(shí)、丟包都非常嚴(yán)重，無法正常傳輸數(shù)據(jù)。

場景二為了排除數(shù)據(jù)庫和數(shù)據(jù)庫群集因素。此場景沒有采用兩數(shù)據(jù)庫之間導(dǎo)入數(shù)據(jù)的方式進(jìn)行測試，而是在服務(wù)器OM配置共享文件夾，通過共享文件夾，從服務(wù)器OM向服務(wù)器VM1拷貝文件。結(jié)果同樣出現(xiàn)網(wǎng)絡(luò)延遲、延時(shí)和丟包情況和“場景一”相同。通過這一測試，排除了數(shù)據(jù)庫和群集因素，確認(rèn)阻塞的原因在“網(wǎng)絡(luò)”方面。

場景三仍然是數(shù)據(jù)庫操作。從服務(wù)器OM向服務(wù)器PM導(dǎo)入數(shù)據(jù)。此時(shí)從PC機(jī)Ping服務(wù)器V1時(shí)，time＜1ms，沒有延時(shí)。從PC機(jī)Ping物理服務(wù)器PM1時(shí)，time＜1ms，沒有延時(shí)。此項(xiàng)測試排除了服務(wù)器OM到服務(wù)器PM1之間的網(wǎng)絡(luò)問題。

場景四測試服務(wù)器VM1和服務(wù)器VM2之間傳輸數(shù)據(jù)情況。從服務(wù)器VM1向服務(wù)器VM2導(dǎo)入數(shù)據(jù)。此時(shí)從PC機(jī)Ping服務(wù)器VM1時(shí)，time＜1ms，沒有延時(shí)。從PC機(jī)Ping物理服務(wù)器VM2時(shí)，time＜1ms，沒有延時(shí)。此項(xiàng)測試排除了服務(wù)器VM1到服務(wù)器VM2之間的網(wǎng)絡(luò)問題。

場景五測試服務(wù)器PM1和服務(wù)器VM1之間傳輸數(shù)據(jù)情況。從服務(wù)器PM1向服務(wù)器VM1導(dǎo)入數(shù)據(jù)。此時(shí)從PC機(jī)Ping服務(wù)器PM1時(shí)，time＜1ms，沒有延時(shí)。從PC機(jī)Ping物理服務(wù)器VM1時(shí)，time＜1ms，沒有延時(shí)。此項(xiàng)測試排除了服務(wù)器PM1到服務(wù)器VM1之間的網(wǎng)絡(luò)問題。

從表1中可以看出。在場景三、四、五的測試中似乎可以得出一個(gè)結(jié)論：OM、EA、VEA、EVS、VM1、VM2所有參與傳輸?shù)墓?jié)點(diǎn)都沒有問題。惟獨(dú)在場景一中，OM→EA→VEA→EVS→VM1這個(gè)路由發(fā)生網(wǎng)絡(luò)阻塞情況。用分段落查找故障點(diǎn)的方法沒有解決問題。

通過以上分析，阻塞問題的產(chǎn)生不是某一節(jié)點(diǎn)的孤立問題，可能是在某一特定路由上，上、下節(jié)點(diǎn)間相互影響產(chǎn)生的。在查找問題過程中，首先對外部虛擬交換機(jī)EVS和虛擬網(wǎng)絡(luò)適配器VEA進(jìn)行了檢查，重點(diǎn)查找同上、下各節(jié)點(diǎn)有關(guān)的參數(shù)配置。對一些參數(shù)進(jìn)行了調(diào)整，但問題沒有得到解決。在查找到物理網(wǎng)卡EA時(shí)，發(fā)現(xiàn)有個(gè)“虛擬機(jī)隊(duì)列”屬性項(xiàng)目，處于已啟用狀態(tài)。從名稱上看似乎同虛擬機(jī)的通信有關(guān)。我們嘗試將“虛擬機(jī)隊(duì)列”屬性設(shè)置為禁用，結(jié)果網(wǎng)絡(luò)阻塞狀態(tài)立即解除，網(wǎng)絡(luò)延時(shí)由原來的200ms立即下降到1ms以內(nèi)。

在以上5個(gè)測試場景中，之所以沒有直接確認(rèn)問題出在物理網(wǎng)卡EA上，是因?yàn)樵趫鼍叭臏y試中，數(shù)據(jù)傳輸路由（OM→EA→VEA→PM1）中有節(jié)點(diǎn)EA參與，卻沒有發(fā)生網(wǎng)絡(luò)阻塞情況。沒有發(fā)生的原因是OM與物理機(jī)PM1之間傳輸數(shù)據(jù)時(shí)，“虛擬機(jī)隊(duì)列”功能不參與物理機(jī)傳輸控制，它只參與虛擬機(jī)傳輸控制。“虛擬機(jī)隊(duì)列”功能開啟與否不對PM1傳輸數(shù)據(jù)產(chǎn)生影響。這也是場景三測試中，雖有EA節(jié)點(diǎn)參與，卻沒有發(fā)生網(wǎng)絡(luò)阻塞的原因所在。

“虛擬機(jī)隊(duì)列”真相浮出水面

Hyper-v外部虛擬網(wǎng)絡(luò)的通信，是通過在物理網(wǎng)卡上運(yùn)行“Microsoft Virtual Network Switch Protocol（微軟虛擬交換機(jī)協(xié)議）”，模擬出一個(gè)標(biāo)準(zhǔn)的（ISO/OSI二層）交換機(jī)進(jìn)行的。虛擬機(jī)隊(duì)列（VMQ）是Intel提供的網(wǎng)絡(luò)硬件技術(shù)，旨在允許物理網(wǎng)絡(luò)接口卡使用直接內(nèi)存訪問功能，將內(nèi)部幀直接傳送到網(wǎng)卡的接收緩沖區(qū)。提升了常見網(wǎng)絡(luò)流量類型（包括TCP/IP、iSCSI、FCoE）傳送到虛擬主機(jī)的效率。如果網(wǎng)卡支持虛擬機(jī)隊(duì)列技術(shù)，在網(wǎng)卡配置中會有虛擬機(jī)隊(duì)列選項(xiàng)。虛擬機(jī)隊(duì)列功能默認(rèn)為啟用狀態(tài)。

如何對癥下藥？

虛擬機(jī)隊(duì)列旨在加速數(shù)據(jù)從物理適配器傳輸至虛擬機(jī)來提高網(wǎng)絡(luò)性能，但在此環(huán)境下開啟虛擬機(jī)隊(duì)列功能卻產(chǎn)生了相反效果。經(jīng)過多方檢索資料和調(diào)測，確認(rèn)Broadcom 網(wǎng)絡(luò)適配器的驅(qū)動(dòng)程序同“虛擬機(jī)隊(duì)列”功能存在不兼容問題。而解決問題的辦法有兩種。

其一，最簡單和直接的辦法就是禁用此功能，但卻無法體驗(yàn)到“虛擬機(jī)隊(duì)列”所帶來的傳輸效率的提升。禁用“虛擬機(jī)隊(duì)列”功能的操作步驟是：物理網(wǎng)絡(luò)適配器→屬性→配置→高級→虛擬機(jī)隊(duì)列→選擇“已禁用”。

其二，更換網(wǎng)卡。安裝非Broadcom生產(chǎn)的網(wǎng)卡，或嘗試安裝Broadcom其它型號的網(wǎng)卡。

針對此次“網(wǎng)絡(luò)異常丟包”的測試結(jié)果，可以總結(jié)為：在啟用“虛擬機(jī)隊(duì)列”功能時(shí)，從服務(wù)器OM到虛擬機(jī)VM1的拷貝文件速率是2MB/秒，網(wǎng)絡(luò)延時(shí)達(dá)到200ms；禁用“虛擬機(jī)隊(duì)列”功能后，拷貝文件速率達(dá)到110MB/秒，網(wǎng)絡(luò)延時(shí)小于1ms。

最終我們在8臺Hyper-v虛擬機(jī)上搭建故障轉(zhuǎn)移群集，安裝SQL Server 2014并啟用Always On高可用性組功能。目前該群集已經(jīng)運(yùn)行3個(gè)月，網(wǎng)絡(luò)傳輸沒有發(fā)生阻塞狀況，整個(gè)群集運(yùn)行穩(wěn)定。

表1 測試情況匯總表

編輯｜張鵬 zhangpeng@bixintong.com.cn