IOPS is commonly recognized as a standard measurement of performance whether to measure the Storage Array’s backend drives or the performance of the SAN. In its most basic terms IOPS are the number of operations issued per second, whether, read, writes or other and admins will typically use their Storage Array tools or applications such as Iometer to monitor IOPS.
IOPS will vary on a number of factors that include a system’s balance of read and write operations, whether the traffic is sequential, random or mixed, the storage drivers the OS background operations or even the I/O Block size.
Block size is usually determined by the application with different applications using different block sizes for various circumstances. So for example Oracle will typically use block sizes of 2 KB or 4 KB for online transaction processing and larger block sizes of 8 KB, 16 KB, or 32 KB for decision support system workload environments. Exchange 2007 may use an 8KB Block size, SQL a minimum of 8KB and SAP 64KB or even more.
|IOPS and MB/s both need to be considered|
Additionally it is standard practice that when IOPS is considered as a measurement of performance, the throughput that is to say MB/sec is also looked at. This is due to the different impact they have with regards to performance. For example an application with only a 100MB/sec of throughput but 20,000 IOPs, may not cause bandwidth issues but with so many small commands, the storage array is put under significant exertion as its front end processors have an immense workload to deal with. Alternatively if an application has a low number of IOPS but significant throughput such as long sustained reads then the exertion will occur upon the SAN’s links.
Despite this MB/s and IOPS are still not a good enough measure of performance when you don’t take into consideration the Frames per second. To elaborate, referring back to the FC Frame, a Standard FC Frame has a Data Payload of 2112 bytes i.e. a 2K payload. So in the example below where an application has an 8K I/O block size, this will require 4 FC Frames to carry that data portion. In this instance this would equate to 1 IOP being 4 Frames. Subsequently 100 IOPS in this example would equate to 400 Frames. Hence to get a true picture of utilization looking at IOPS alone is not sufficient because there exists a magnitude of difference between particular applications and their I/O size with some ranging from 2K to even 256K, with some applications such as backups having even larger I/O sizes and hence more Frames.
|Frames per second give you a better insight of demand and throughput|
Looking at a metric such as the ratio of frames/sec to Mb/sec as is displayed below, we will actually get a better picture and understanding of the environment and it’s performance.To elaborate, the MB/sec to Frames/Sec ratio is different to the IOPS metric. So with reference to this graph of MB/sec to Frame/sec ratio, the line graph should never be below the 0.2 of the y-axis i.e. the 2K data payload.
If the ratio falls below this, say at the 0.1 level, we can identify that data is not being passed efficiently despite the throughput being maintained (MB/sec).
Given a situation where you have the common problem of slow draining devices, the case that MB/s and IOPS alone are not sufficient is even more compelling as you can actually be misled in terms of performance monitoring.
To explain, Slow draining devices are devices that are requesting more information than they can consume and hence cannot cope with the incoming traffic in a timely manner. This is usually because the devices such as the HBA have slower link rates then the rest of the environment, or the server or device are being overloaded in terms of CPU or memory and thus having difficulty in dealing with the data requested. To avoid performance problems it is imperative to proactively identify them before they impact the application layer and consequently emanate to the business’ operations.
|Slow Draining devices - requesting more information than they can consume|
In such a situation, looking again at the MB/S Frames per Sec ratio graph below we can now see that the ratio is at the 0.1 level, in other words we are seeing a high throughput but minimum payload. This enables you to proactively identify if there are a number of management frames being passed instead of data as they are busily reporting on the physical device errors that are occurring.
|Management Frames being passed can mislead|
So to conclude without taking Frames per second into consideration and having an insight into this ratio it is an easy trap to falsely believe that everything is ok and data is being passed as you see lots of traffic as represented by MB/S, when in actuality all you are seeing are management frames reporting a problem.
Here's an animated video to further explain the concept: