抽丝剥茧揭开Hyper

micromax

　　2016.2.17来源：通信世界网
通信世界网消息(CWW)近两年，云计算与虚拟化技术日臻成熟，在电信运营商的很多应用场景中都引用了虚拟机（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）。

图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）。

图2 虚拟机网络拓扑图
网络阻塞问题症结
在搭建完数据库群集后，我们发现数据在迁移过程中出现了问题。在服务器VM1数据库上操作，从旧服务器OM导入数据时，发现数据传输很慢。从PC机Ping服务器VM1，延时非常严重，达到time=200ms左右，并出现丢包现象。在千兆以太网环境下，这个速度几乎不可想象。但此时Ping物理服务器PM1，time<1ms，网络却没有延时。
为了找到问题所在，沈阳移动IT部门尝试了多种方式，并采用了两种数据传输方式，模拟出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 测试情况汇总表
从表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之间传输数据时，“虚拟机队列”功能不参与物理机传输控制，它只参与虚拟机传输控制。“虚拟机队列”功能开启与否不对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个月，网络传输没有发生阻塞状况，整个群集运行稳定。