虚拟化技术向网络提出挑战(下)

日期: 2009-08-16 来源:TechTarget中国 英文

  在本文的上半部分中,我们介绍了虚拟化给网络带来了什么变化,本文将继续分析具体场景。

  场景一:ERP流量

  我们在一个VM上发起ERP查询请求,ERP服务器为另一个同在当前物理服务器上的VM,虽然在这种情况下有一部分网络流量被“消化”在了当前物理服务器内部,不过没关系,我们要关心的并不是这部分内容,我们关心的是在物理链路上产生的流量变化。

ERP

ERP基础流量

  此处的ERP基础流量其实是大量的数据库查询操作,X轴为时间轴(180秒),Y轴为数据流量(单位是Byte)。由于ERP查询脚本比较“单纯”,可以看到,流量曲线也比较有规则,其非峰值流量并不大,基本在1MBps以下。

网络流量

随着ERP并发数的增加网络流量产生的变化

  上图是我们测试的第二个ERP脚本,可看到,随着并发数的增加,峰值流量曲线基本上是一路走高,瞬间最高达到了50MBps。但非峰值曲线并没有大的变化,总体来说,网络流量依然不高。

ERP

持续ERP压力下的流量

ERP测试

ERP测试退出中(不断关闭会话)

ERP测试

ERP测试正式退出,退出时出现了一个流量峰值达到了120MBps

ERP测试

ERP测试退出后的基础流量(系统流量),基本在200KBps左右

虚拟机

虚拟机(VM)重起

  测试完ERP的两个脚本后,我们重起了两次虚拟机(VM),VM的重起速度是非常快的,从截图中也可以看到,两次峰值流量的持续时间都只有不到10秒。由于VM的实体文件其实是存放在存储设备中的,VM在重起时必定会从存储中读取大量数据,不过从测试截图来看,重起VM所产生的流量对网络造成的冲击并不高。

  场景二:各种流量叠加

  在本场景中,我们将ERP流量作为基础流量(必要流量),一、对当前VM进行快照,二、在另一个VM中(不同物理服务器上)对存储设备使用IOMETER进行吞吐测试。

ERP

ERP(基础)流量峰值平均在5MBps左右

快照

VM快照

  所谓快照就是将VM当前的状态进行“拍照”,主要包括当前VM的内存数据、CPU状态等信息。上图中55MBps处的峰值是快照启动时的流量,在快照进行中,流量基本维持在10MBps左右,虽然10MBps的流量并不高,但要知道,这一流量在非虚拟化环境中是不存在的。并且这仅是对一个VM进行快照,如果多台VM同时进行快照,这一流量将不容小视,因为这一流量是叠加在业务应用流量之上的。

虚拟机快照

VM快照进行中,流量稳定在10MBps左右。

ERP

VM快照结束,此时的流量仅为ERP流量。

IOMETER吞吐测试

IOMETER吞吐测试起动

  IOMETER吞吐测试起动后网络流量达到了45MBps左右,此时的ERP流量被彻底淹没了,最左端的VM快照流量也显得有些微不足道。

IOMETER测试

IOMETER测试持续中

IOMETER测试

IOMETER测试结束后

  从上面这些截图中我们可以看到,服务器虚拟化以后,流量叠加所产生的问题不容小视,我们所搭建的测试环境其实很简单,所产生的网络流量也相对“单纯”,但这已经可以说明问题。

  我们要做的当然是要避免这些问题的发生,首先,也是最重要的,在您设计全局虚拟化拓扑结构时,要比以往发费更多精力关注由于网络结构变化带来的新性能瓶颈点,如何能让整个网络运行得高效且稳定,初期设计变得尤为重要,一个大的方向就是将应用网络与系统网络相分离。另外,对于一些大流量的应用,例如对VM进行快照,虽然技术上支持任何时间进行,但为了避免对业务应用造成冲击,这类操作应当尽量选择在网络空闲时进行。

  本次的两个场景测试,我们对应用虚拟化技术之后会带给物理链路怎样的影响作了说明,在随后的测试中,我们将向大家介绍在虚拟机(VM)动态迁稳时物理链路将发生怎样的状况,VM迁移是根据策略自动进行的,链路流量起伏也将随之变得更加难以预知,敬请期待。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

相关推荐