虚拟化对网络提出挑战
如果一项新技术被“发酵”为一种趋势，那它将变得不可被阻挡。虚拟化技术虽然已经不再让人感到那么的新鲜，但对它我们是否依然感觉陌生?操作系统在应用虚拟化技术以后物理硬件不见了，服务器硬件变成了“篮子”，而篮子里放着的一个个鸡蛋就是以前运行在服务器硬件上的操作系统。
这种变化可以说是革命性的，它的好处显而易见，例如可以大幅提升服务器硬件的利用率，甚至可以成倍的缩减以往购买服务器硬件的成本;同时服务器管理也变得更加高效且可控，像管理员可以随时对虚拟机(VM)进行快照，迁移等操作。
应用虚拟化技术前后对比
虚拟化技术带来的变化不仅在操作系统层面，其实从上图中我们还可以看出另一种明显的变化——网络层面的变化。在非虚拟化环境中，一台物理服务器中运行着一个OS，经由一条链路或多条链路连接到交换机，这种环境下网络链路中的流量几乎全部为业务数据流量，流量的大小当然要看具体的应用是什么，但一般来讲，这个流量是不高的。
但在虚拟化环境下，这一切发生了很大的变化，简单的讲，此时交换机与物理服务器之间的链路中传输的数据流量变得远比以前复杂得多。首选，这一物理链路中将同时传输来自多个虚拟机(VM)中的数据，另外，除了业务数据流量，链路中还增加了虚机机运行时所需要的系统流量，而这部分流量是以往非虚拟化环境中所不存在的。
让我们简单总结一下这一变化，在非虚拟化环境中，物理服务器与交换机之间的关系是一对一的关系，而在虚拟化环境中，由于一台物理服务器中运行着多个虚拟机(VM)，从逻辑结构角度讲，这时服务器与交换机之间其实是“多”对一的关系;随着服务器(操作系统)与交换机之间逻辑结构的变化，物理链路中的流量也由一对一变为了“多”对一的关系，此外，还包括了以往非虚拟化环境中所不存在的虚拟机系统流量。
虚拟化后物理网络产生瓶颈
在虚拟化环境中，上面所提到的流量变化其实是可以在交换机端口上监控得到的，但还有一部分流量在交换机上我们是监控不到的，请看下图，我们来简单说一下。
#p#
虚拟交换机
虚拟服务器(这里指的是ESX)会在OS与网卡物理硬件之间创建一个中间层——虚拟交换机(Virtual Switch)，就是说，一台物理服务器上的各个虚机(OS)通过虚拟交换机可直接进行通信，这部分流量并不会出现在物理交换机上，而是在物理服务器内部被消化掉了。
这就给故障排查带来了一些新的挑战，在物理交换机端口上看似正常的流量，而问题可能是被虚拟交换机给掩盖掉了。VMware VirtualCenter是一个很有效的管理工具，管理员可以通过它对ESX SERVER进行各种管理工作，查看运行状况等，关于VC我们将在随后的文章中对其进行更为详细的介绍，而本文侧重于虚拟化对物理网络链路带来的影响。
服务器进行虚拟化之后，物理网络产生的瓶颈问题变得更为突出，这个以往可能并不存在的问题一下子成了必须要考虑并需要解决的问题。到底虚拟化会对物理网络产生怎样的影响?影响有多大?我们可以通过几个并不复杂的实验来说明它。
我们搭建了一个虚拟化的实验场景，逻辑拓扑图如下图所示。交换机的19#端口与存储相连，我们将17#端口认置为镜像端口，镜像19#端口上的所有流量并与监控电脑相连接。我们在虚似机(VM)上运行不同的应用，在监控电脑上使用流量监控软件跟踪其数据流量变化。
逻辑拓扑图
在这一测试环境中，各虚拟机(VM)的实体文件是存放在存储设备上的，就是说，无论物理交换机左侧的逻辑结构如何，在其右侧与存储设备相连的那根网线中，基本上只存在两种数据流量，一是业务应用流量，二是虚拟机本身的系统流量。这种环境下在交换机与存储之间的链路上就不可避免的会产生传输瓶颈。以上都是我们进行的逻辑推论，但问题到底有多严重?我们将用测试截图来一步步说明。
#p#
ERP测试流量
场景一：ERP流量
我们在一个VM上发起ERP查询请求，ERP服务器为另一个同在当前物理服务器上的VM，虽然在这种情况下有一部分网络流量被“消化”在了当前物理服务器内部，不过没关系，我们要关心的并不是这部分内容，我们关心的是在物理链路上产生的流量变化。
ERP基础流量
此处的ERP基础流量其实是大量的数据库查询操作，X轴为时间轴(180秒)，Y轴为数据流量(单位是Byte)。由于ERP查询脚本比较“单纯”，可以看到，流量曲线也比较有规则，其非峰值流量并不大，基本在1MBps以下。
随着ERP并发数的增加网络流量产生的变化
上图是我们测试的第二个ERP脚本，可看到，随着并发数的增加，峰值流量曲线基本上是一路走高，瞬间最高达到了50MBps。但非峰值曲线并没有大的变化，总体来说，网络流量依然不高。
持续ERP压力下的流量
ERP测试退出中(不断关闭会话)
ERP测试正式退出，退出时出现了一个流量峰值达到了120MBps
ERP测试退出后的基础流量(系统流量)，基本在200KBps左右
虚拟机(VM)重起
测试完ERP的两个脚本后，我们重起了两次虚拟机(VM)，VM的重起速度是非常快的，从截图中也可以看到，两次峰值流量的持续时间都只有不到10秒。由于VM的实体文件其实是存放在存储设备中的，VM在重起时必定会从存储中读取大量数据，不过从测试截图来看，重起VM所产生的流量对网络造成的冲击并不高。
#p#
叠加流量、总结
场景二：各种流量叠加
在本场景中，我们将ERP流量作为基础流量(必要流量)，一、对当前VM进行快照，二、在另一个VM中(不同物理服务器上)对存储设备使用IOMETER进行吞吐测试。
ERP(基础)流量峰值平均在5MBps左右
VM快照所谓快照就是将VM当前的状态进行“拍照”，主要包括当前VM的内存数据、CPU状态等信息。上图中55MBps处的峰值是快照启动时的流量，在快照进行中，流量基本维持在10MBps左右，虽然10MBps的流量并不高，但要知道，这一流量在非虚拟化环境中是不存在的。并且这仅是对一个VM进行快照，如果多台VM同时进行快照，这一流量将不容小视，因为这一流量是叠加在业务应用流量之上的。
VM快照进行中，流量稳定在10MBps左右。
VM快照结束，此时的流量仅为ERP流量。
IOMETER吞吐测试起动
IOMETER吞吐测试起动后网络流量达到了45MBps左右，此时的ERP流量被彻底淹没了，最左端的VM快照流量也显得有些微不足道。
IOMETER测试持续中
IOMETER测试结束后
从上面这些截图中我们可以看到，服务器虚拟化以后，流量叠加所产生的问题不容小视，我们所搭建的测试环境其实很简单，所产生的网络流量也相对“单纯”，但这已经可以说明问题。
我们要做的当然是要避免这些问题的发生，首先，也是最重要的，在您设计全局虚拟化拓扑结构时，要比以往发费更多精力关注由于网络结构变化带来的新性能瓶颈点，如何能让整个网络运行得高效且稳定，初期设计变得尤为重要，一个大的方向就是将应用网络与系统网络相分离。另外，对于一些大流量的应用，例如对VM进行快照，虽然技术上支持任何时间进行，但为了避免对业务应用造成冲击，这类操作应当尽量选择在网络空闲时进行。
