抽絲剝繭揭開Hyper-V虛機網絡阻塞真相

中國移動通信集團沈陽分公司│張永濤

抽絲剝繭揭開Hyper-V虛機網絡阻塞真相

中國移動通信集團沈陽分公司│張永濤

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

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

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

物理宿主機配置

在提供解決方案之前，首先介紹一下沈陽移動的IT系統運行環境。

服務器型號HP DL585、4塊CPU、32GB內存，配置4個千兆以太網端口；網卡型號NC375i，網卡芯片型號Broadcom NetXtreme Gigabit Ethernet；驅動程序版本號15.6.1.3，驅動文件名b57nd60a.sys；操作系統為Windows Server 2012標準版，安裝文件名SW_DVD9_Windows_ Svr_Std_and_DataCtr_2012_R2_64Bit_ChnSimp_-3_ MLF_X19-53577.ISO；安裝Hyper-V角色，建立一個外部交換機EVS；防火墻全部關閉，網絡環境為千兆以太網（物理服務器網絡拓撲見圖1）。

虛擬機配置

3臺虛擬機硬件配置：二代Hyper-V、8核CPU、10GB內存、127GB硬盤。操作系統安裝的是Windows Server 2012標準版，安裝SQL Server 2014企業版數據庫。安裝文件名是SW_DVD9_SQL_Svr_Ent_Core_2014_64Bit_ ChnSimp_MLF_X19-34249.ISO。網卡是Microsoft Hyper-V 網適配器。防火墻全部關閉。

組網方式是建立外部虛擬交換機。虛擬機通過外部虛擬交換機EVS、虛擬網絡適配器VEA、物理網絡適配器EA連接服務器OM（虛擬機網絡拓撲見圖2）。

網絡阻塞問題癥結

在搭建完數據庫群集后，我們發現數據在遷移過程中出現了問題。在服務器VM1數據庫上操作，從舊服務器OM導入數據時，發現數據傳輸很慢。從PC機Ping服務器VM1，延時非常嚴重，達到time=200ms左右，并出現丟包現象。在千兆以太網環境下，這個速度幾乎不可想象。但此時Ping物理服務器PM1，time＜1ms，網絡卻沒有延時。

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

場景一在數據庫上操作，從服務器OM向服務器VM1導入數據時，從PC機ping服務器VM1，此時平均延時達到200ms左右，延時在30ms ＜ time ＜ 250ms之間。數據丟包率達20%。

ping 10.65.28.73 -t發現：延時、丟包都非常嚴重，無法正常傳輸數據。

場景二為了排除數據庫和數據庫群集因素。此場景沒有采用兩數據庫之間導入數據的方式進行測試，而是在服務器OM配置共享文件夾，通過共享文件夾，從服務器OM向服務器VM1拷貝文件。結果同樣出現網絡延遲、延時和丟包情況和“場景一”相同。通過這一測試，排除了數據庫和群集因素，確認阻塞的原因在“網絡”方面。

場景三仍然是數據庫操作。從服務器OM向服務器PM導入數據。此時從PC機Ping服務器V1時，time＜1ms，沒有延時。從PC機Ping物理服務器PM1時，time＜1ms，沒有延時。此項測試排除了服務器OM到服務器PM1之間的網絡問題。

場景四測試服務器VM1和服務器VM2之間傳輸數據情況。從服務器VM1向服務器VM2導入數據。此時從PC機Ping服務器VM1時，time＜1ms，沒有延時。從PC機Ping物理服務器VM2時，time＜1ms，沒有延時。此項測試排除了服務器VM1到服務器VM2之間的網絡問題。

場景五測試服務器PM1和服務器VM1之間傳輸數據情況。從服務器PM1向服務器VM1導入數據。此時從PC機Ping服務器PM1時，time＜1ms，沒有延時。從PC機Ping物理服務器VM1時，time＜1ms，沒有延時。此項測試排除了服務器PM1到服務器VM1之間的網絡問題。

從表1中可以看出。在場景三、四、五的測試中似乎可以得出一個結論：OM、EA、VEA、EVS、VM1、VM2所有參與傳輸的節點都沒有問題。惟獨在場景一中，OM→EA→VEA→EVS→VM1這個路由發生網絡阻塞情況。用分段落查找故障點的方法沒有解決問題。

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

在以上5個測試場景中，之所以沒有直接確認問題出在物理網卡EA上，是因為在場景三的測試中，數據傳輸路由（OM→EA→VEA→PM1）中有節點EA參與，卻沒有發生網絡阻塞情況。沒有發生的原因是OM與物理機PM1之間傳輸數據時，“虛擬機隊列”功能不參與物理機傳輸控制，它只參與虛擬機傳輸控制?！疤摂M機隊列”功能開啟與否不對PM1傳輸數據產生影響。這也是場景三測試中，雖有EA節點參與，卻沒有發生網絡阻塞的原因所在。

“虛擬機隊列”真相浮出水面

Hyper-v外部虛擬網絡的通信，是通過在物理網卡上運行“Microsoft Virtual Network Switch Protocol（微軟虛擬交換機協議）”，模擬出一個標準的（ISO/OSI二層）交換機進行的。虛擬機隊列（VMQ）是Intel提供的網絡硬件技術，旨在允許物理網絡接口卡使用直接內存訪問功能，將內部幀直接傳送到網卡的接收緩沖區。提升了常見網絡流量類型（包括TCP/IP、iSCSI、FCoE）傳送到虛擬主機的效率。如果網卡支持虛擬機隊列技術，在網卡配置中會有虛擬機隊列選項。虛擬機隊列功能默認為啟用狀態。

如何對癥下藥？

虛擬機隊列旨在加速數據從物理適配器傳輸至虛擬機來提高網絡性能，但在此環境下開啟虛擬機隊列功能卻產生了相反效果。經過多方檢索資料和調測，確認Broadcom 網絡適配器的驅動程序同“虛擬機隊列”功能存在不兼容問題。而解決問題的辦法有兩種。

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

其二，更換網卡。安裝非Broadcom生產的網卡，或嘗試安裝Broadcom其它型號的網卡。

針對此次“網絡異常丟包”的測試結果，可以總結為：在啟用“虛擬機隊列”功能時，從服務器OM到虛擬機VM1的拷貝文件速率是2MB/秒，網絡延時達到200ms；禁用“虛擬機隊列”功能后，拷貝文件速率達到110MB/秒，網絡延時小于1ms。

最終我們在8臺Hyper-v虛擬機上搭建故障轉移群集，安裝SQL Server 2014并啟用Always On高可用性組功能。目前該群集已經運行3個月，網絡傳輸沒有發生阻塞狀況，整個群集運行穩定。

表1 測試情況匯總表

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