自从VPLEX 2010年上市以来,EMC就将其定位于一款能够提供双活冗余,数据异地迁移的虚拟化平台。对于其强大功能的宣传似乎也伴随着一些质疑的声音,对于现有性能的影响,与其他厂商产品的比较等等。宏观地去考虑,任何存储虚拟化的平台似乎都是在主机和存储之间插入了一层,平台对存储进行封装,再呈现给主机,主机只会对封装过的存储进行操作。这样所有的I/O都会通过这个虚拟化的平台,那么存储虚拟化平台在接受、处理、转发这些I/O的过程中必然会引入一些延迟,从而对性能造成一定的影响。但是如果我们花点时间微观去考量,也许故事并没有那么简单。

首先我们要回答的问题应该是如何定义性能问题。关于这个问题已经有了很多的讨论,最后的答案似乎是性能问题是根据实际的应用情况会有不同的性能指标。也许是高的IOPS,抑或是IO throughput吞吐量,还是优秀的相应时间。但是这些也许是不能兼得的,下面的一张图可以说明一些问题:

1.jpg

高的IOPS往往意味着低的吞吐量,例如8KI/O大小的数据库操作1000IOPS的吞吐量才是8M/S。而高的吞吐量有时IOPS是很小的,例如流媒体的读数据IO大小为16M5IOPS就有80M/S的吞吐量。所以如果上层的主机应用不同,那么关注的性能指标不同,面临的性能问题也不一样。对于银行的交易系统,也许IOPS以及相应时间有严格要求,对于流媒体应用的系统,也许吞吐量带宽容易成为瓶颈;而对于每天需要备份的数据库,也许备份速度是关注的重点,而医院的HIS系统,终端用户对响应时间有明确的要求。所以首先要确定了系统的I/O类型之后,我们才可以开始考虑引入VPLEX可能对I/O造成的影响。

EMC VPLEX产品主要有三种类型:localmetro以及Geo,主要区别在于支持本地,同步距离以及异步距离。

2.jpg

目前VPLEX支持FC协议的硬件系统,其硬件配置可以见下表。目前其硬件及软件也在不断更新中,并且升级过程是非中断的:

3.jpg

可以看到VPLEX使用的是8Gb/sFC端口,在VS2的硬件中单引擎前端后端各有8个这样的FC口,所以总的带宽可以达到64Gb/s,如果配上4引擎,可以达到256Gb/s,这样的配置对于大部分系统想必是足够了。

然后I/O的总体走向可以见下图,在通过FC口进入VPLEX后,主要是经过缓存cache,然后可能经过com口,再通过FC口到达存储。

4.jpg

VPLEX VS2单引擎使用了72G的内存,其中小部分用于系统开销,大部分内存都是作为读缓存使用,由于其机制与存储的读缓存是一致的,所以相当于大大增加了存储读缓存的数量,在存储读缓存紧张时,或者在大量连续读操作时,VPLEX内存能够明显提高读操作的性能。对于读操作我们分两种情况,一种是读操作命中缓存,即read hit,另一种是未命中,即read miss。在read hit的情况下,读操作使用的时间一般是在200微秒以内。即使在read miss的情况下,读操作在抵达VPLEX后,经过VPLEX的处理(和IOSIZE有关),将从后端存储读取数据,而由VPLEX造成的延迟大概也在200-400微秒,而后端存储的响应时间往往会达到毫秒级别,所以VPLEX造成的延迟相对并不很大。

而对于写操作的情况,由于VPLEX localmetro使用的是write through的模型,而不是write back。也就是只有在写操作在后端存储完成后,VPLEX才会向主机返回确认完成的信息,所以写操作的花费时间必然会比直接写存储来的长。对于VPLEX local的模型,写操作不需要穿过跨地域的WAN连接到达远端存储,所以写操作的时间就是前端SAN的时间、VPLEX上的时间、后端SAN的时间、存储写操作时间(可能是多个存储)的总和。对于VPLEX metro的模型,写操作需要穿过跨地域的WAN链接到达远端存储,所以写操作的时间往往主要由WANRTTround trip time)决定,VPLEX metroRTT有小于5ms的严格要求,也是为了保证写操作的同步模式。综上,读写操作经过VPLEX的大致过程如下:

 

 

Local

Metro

Time

Read hit

本地VPLEX cache

通过global cache,保证本地VPLEX cache服务

~200微秒

Read miss

将由本地VPLEX从后端存储读取数据

将由本地或者远端VPLEX从后端存储读取数据

SAN延迟+VPLEX延迟+存储响应时间(+WAN 延迟,如果由远端VPLEX从后端存储读取)

Write

通过本地VPLEX写到后端存储(可能是多个存储)

通过本地及远端VPLEX写到两地的后端存储

SAN延迟+VPLEX延迟+存储响应时间(+WAN 延迟,metro环境)

总的来看,由VPLEX自身引入的I/O延迟并不大,我的理解只是相当于多通过了两个光纤交换机。而metro环境的WAN延迟也是出于保证数据在两个站点的一致性考虑。

除了I/O过程的变化,我们还需要考虑下I/O size。由于VPLEX从主机接受I/O,再将其转发给后端存储,VPLEX自身的cache page size4K,所以4K整数倍大小的I/O的性能是比较好的。对于大于1MI/O sizeVPLEX可能对其进行一个拆分,拆分为小的I/O,再发给后端存储,如果一旦发生这个拆分,就可能对响应时间造成影响。从VPLEX 5.2的版本开始,已经对大于128K的写I/O进行了优化,尽量避免发生I/O拆分的情况。

       在大致了解了VPLEX的引入对I/O的改变之后,我们可以开始对性能进行评估以及平衡了。确定我们最关心的数据,评估以及测试VPLEX引入对其造成的影响。亦或是在性能和VPLEX提供的高可用性之间做出一个平衡。毕竟VPLEX提供的高可用性,迁移性以及存储虚拟化可以为数据中心的提供更好的RTORPO及更方便的管理。

当然VPLEX自身也有一套不断完善的性能监控系统,VPLEX会对系统定义的接近100个性能指标进行采样和记录,这些记录会以日志的形式保存在VPLEX的管理机上,在每个director的日志写满100M后,会对日志记录进行滚动,最早的性能日志就会被新的覆盖掉。

5.jpg

这些性能指标及包括了VPLEX自身的CPU,内存使用率,也包括前端主机,后端存储的IOPSthroughput吞吐量,响应时间,还有对WAN环境的延迟,丢包等等,夸张一点说,VPLEX可以充当环境中的性能监控器,为系统性能评估提供大量的数据。

除了这些性能日志数据外,我们还能够通过VPLEX Unisphere的界面实时观察VPLEX上记录的性能数据,如图:

6.jpg

如果在某段时间发现系统进行备份或者其他操作的时候性能出现问题,我们可以登录到这里对各项指标进行一个查看,当然如果我们以前有在系统稳定的时候对这些指标进行记录作为比较基准的话,此时就可以做逐一比较来确定可能存在的问题。

需要指出的是,由于这些系统定义的性能指标都是针对系统层面的,如果需要得到对具体的某个主机,或者后端某个存储的性能数据,就需要对VPLEX进行一个自定义的性能指标监控,具体操作步骤可见VPLEX-Administration-Guide

VPLEX还提供对SNMP的支持,用户可以通过自己的SNMP监控工具对VPLEX的性能数据进行查询,从而可以从VPLEX上获得丰富的数据,并将其整合进SNMP监控工具。

看完以上的这些数据,我只是想得到一个简单的结论,VPLEX并不一定会造成性能问题。真正的问题是要找到系统的I/O类型,关心的性能指标,以及评估、测试和监控它的方法工具。正所谓每一个人都是独一无二的,每一个数据中心也是。

最后推荐一篇EMC的文档 EMC VPLEX: ELEMENTS OF PERFORMANCE AND TESTING BEST PRACTICES DEFINED,即使不会用到VPLEX,文章中的某些部分也会是有所裨益的。

http://www.emc.com/collateral/white-papers/h11299-emc-vplex-elements-performance-testing-best-practices-wp.pdf