Since 2010, VPLEX has been regarded as an active-active virtualized platform. Let’s begin our discussion of VPLEX performance by considering what good performance is.

First, we have to answer the question about how to define performance. On this issue there has been a lot of discussions, the final answer seems to be performance is based on the actual application. Perhaps it is high IOPS, IO throughput, or response time. This produces a relationship between IOPS and throughput as shown in Figure 1 below:

High IOPS often means low throughput, for example in 8K I/O database operations the throughput of 1000IOPS is 8M/S. High throughput may be very small IOPS, e.g., stream media read IO size is 16M, 5IOPS means 80M/S throughput. So if the host has different applications, different performance indicator is concerned. For the bank's trading system, perhaps IOPS and response time have strict requirements, for the system of stream media applications, the bandwidth throughput may easily become a bottleneck; while for the database to be backed up every day, maybe backup speed is the focus of attention, and for the hospital's HIS system, there is a clear response time requirements from end-users. So we must first determine the I/O type before we can begin to consider the influence of VPLEX on I/O.

EMC VPLEX products are mainly three types: local, metro and Geo, the main difference is to support local, synchronous and asynchronous distance away.Below is the hardware configuration table:

VPLEX uses 8Gb/s FC ports, the VS2 hardware have eight FC ports respectively at front end and back end in a single-engine, so the total bandwidth is up to 64Gb/s. With 4 engines, it can reach 256Gb/s, and this configuration for most systems must be sufficient.

Then the overall trend of I/O can be seen below, after entering VPLEX by FC ports, data mainly goes through cache, and then may go through com port, and then reach the storage by FC ports.

VPLEX VS2 has 72G memory which is mostly used as a read cache memory. Due to VPLEX and storage array have the same read cache mechanism, so VPLEX has greatly increased the read buffer of storage array. VPLEX memory can significantly improve the performance of read operations. For read operations there are two cases, one is the read cache hit, the other is the read miss. In the case of read hit, the time of a read operation is generally less than 200 microseconds. Even in the case of read miss, after read operation reaches VPLEX and VPLEX handles it (depends on IOSIZE), data is read from the back-end, and the delay caused by VPLEX is about 200-400 microseconds while the response time of the back-end storage often at millisecond level, so the delay caused by the VPLEX is not so great relatively.

In the case of a write operation, VPLEX local and metro use “write through”model, rather than “write back”. That is only after the write operation is completed at the back-end storage, VPLEX will return to confirm the completion to the host, so the write operation takes more time than direct write. For VPLEX local model, write operations do not need to reach remote storage across the WAN connection, so the write operation time is the summary of front-end SAN time, VPLEX time, backend SAN time, storing the write operation time (probably a plurality of storage). For VPLEX metro model, writes need to pass through WAN links to reach the remote storage, so the write operation time is often determined mainly by the WAN RTT (round trip time), VPLEX metro has strict requirements that the RTT must be less than 5ms, in order to assure the write operation in synchronous mode. 

In addition to the change of I/O process, we also need to consider I/O size. VPLEX accepts I/O from the host, and then forwards it to the back-end storage, VPLEX has 4K cache page size, so the performance of the I/O size which is an integer multiple of 4K is relatively good. For more than 1M I/O size, VPLEX may be split it into smaller I/O, and then sent them to the back-end storage. Once the split occurs, it could have an impact on response time. Starting from VPLEX version 5.2, write I/O which is bigger than 128K has been optimized, to avoid I/O splitting.

Certainly VPLEX also has a performance monitoring system, and VPLEX will take samples and records on up to 100 system-defined performance metrics, which will be in the form of logs stored on the VPLEX management console.

These performance indicators include VPLEX CPU, memory utilization, front-end host IOPS, back-end storage IOPS, throughput, response time, as well as latency and package loss in the WAN environment, etc. VPLEX can act as performance monitor, providing a lot of data to evaluate system performance.

In addition to these performance log data, we are also able to observe the performance of real-time data recorded on VPLEX through VPLEX Unisphere interface, as shown:

If you find the system at a certain time has performance issue, you can log on to review these indicators.

After reading the above data, I just have a simple conclusion. VPLEX may not cause performance problems. The real problem is to find the system I/O types, performance indicators, as well as evaluation, testing and monitoring methodological tools.