In this post, I’ll be discussing how to plan storage performance capacity via IOPS.
Let say as an IT Admin, you’re presented with a storage migration task, or a deployment of additional iSCSI Storage for growing application servers, such as Microsoft Exchange Server or VMware ESX Hypervisor. The question is – how does an IT admin determine the performance needed to handle the newly requested duties? I was recently presented with this task, as a growing divisional office was growing beyond the capabilities of their five-year-old storage system – and they were torn between the RS2211RP+ and the RS3411RPxs. Both offer more than enough capacity for their needs – the question was the performance. Well, after further analysis of their storage needs and usage behavior of everyone in the office – it was determined that all that is required is a RS2211RP+ to meet their needs. In this post – I’ll be covering a discussion about the IOP – which is one of two performance benchmarks in the storage industry.
What are IOPS?
Previously – to measure a storage system performance capability was to measure its throughput, typically by a single computer. Throughput measures the average number of megabytes transferred within a given period of a specific file size. However, using throughput at the scale of larger storage system isn’t accurate enough – as most of the time, when requesting data from a storage server – it’s typically a lot of small read/writes of packets of data and not a single computer conducting a single large file request. Measuring the storage system’s ability of handling numerous small packets of data requests requires a more advanced benchmark, which is the IOPS.
IOPS (Input/Output Operations per Second) measure the number of operations per second that a storage system can perform. IOPS offers a different way of measuring activity, as it can be used to simulate multi-user behavior – as the cumulative total of user access is essentially the number of IOPS being requested to the storage array at a given time.
How to determine how many IOPS you need
Here is how IT Admins can determine the IOPS currently used by their current applications, which is the best recommend practice by most solution providers. First, evaluate the current performance usage of what the server is performing over a period of thirty days, such as during the beginning of the business day, mid-day, closing hours, and when backups are occurring. From here, a sampling of data can be generated and help determine how many IOPS an application server is using. Here are a couple of examples below.
View of my Windows workstation, an average of 18 IOPS @ 64K, running multiple office applications, multiple multi-tab browsers, and multiple multimedia applications concurrently.Ref: 1, 2, 3
View of a production use VMware Server – note that in the image that the performance of the machine does not show high amount of single throughput (about 11.3MB/Sec Read, 1.6MB/Sec Write) – but high amounts of IOPS being requested.Ref: 4
Estimating IOPS performance needed
Here, is information gathered from various websites, which can help estimate the number of IOPS needed. While this information is useful for providing an estimation, it doesn’t replace conducting an evaluation of the current performance utilization of an application server.
- Microsoft Exchange 2010 ServerRef: 5
- Assuming 5000 users that send/receive 500 emails a day, an estimated total of 3000 IOPS is needed
- Microsoft Exchange 2003 ServerRef: 6
- Assuming 5000 users are sending 60, receiving 150 emails a day, an estimated total of 7500 IOPS is needed
- Microsoft SQL 2008 Server, cited by VMwareRef: 7
- 3557 SQL TPS generates 29,000 IOPS
- Various Windows ServersRef: 8
- Community Discussion: between 10-40 IOPS per Server
- Oracle Database Server, cited by VMwareRef: 9
- 100 Oracle TPS generates 1,200 IOPS
How to measure IOPS
Typically speaking – IOPS can be measured as 100% Read Event, or 100% Write Event; although this is seldom the case in the real world. Mixed performance can also be measuredRef: 6, along with using typical IOP size (or block size) of 4KB, upwards to 32KB. The number of IOPS will vary depending on the IOP size, where typically, a smaller IOP size will result in a greater number of IOPS. In contrast, a larger IOP size results in higher throughput – but lower IOPS.
Storage array overhead
Even if the desired number of IOPS is known – the storage array itself will incur a penalty as it is calculating RAID parity as its writing data to the disks. The formula for calculating storage array over head is as follows,Ref: 10
Array IOPS = (I * r) + (I * w * f) r=read percentage (as a decimal point, ie 0.75) w=write percentage (as a decimal point, ie 0.25) I= Desired IOPS f=raid penalty RAID-0 = 1 RAID-1/10 = 2 RAID-5/50 = 4 RAID-6/60 = 6 With this formula, if 3000 IOPS is required for the application server, the array using RAID-6 will need to be capable of 6750 IOPS. Personally speaking, as I tend to be conservative with capacity planning – I would add 20% as a buffer, so 8100 IOPS is what a storage array would need to be capable of conducting for this hypothetical scenario.
Editors note: after further research, it’s found that the above information doesn’t apply to today’s environment as when conducting performance benching of storage system, the performance result already has the penalty inherit of the result. Therefore, this formula isn’t needed. However, the practice of using a 20% overhead as a buffer is still recommended.
Performance capacity planning can be an arduous task, however, given that there are tools available to conduct IOPS benching of existing servers – this process is a little bit easier for IT Admins for SMBs. As a quick summary – the best way to determine how many IOPS is required is to log the existing storage server’s performance for thirty days. After the amount of IOPS required is identified, determining which Synology DiskStation or RackStation to use will become a bit easier.
Stay tuned! My next blog post will be covering the IOPS performance of selected Synology DiskStations, and RackStations to help make your purchase decision easier.
1. Understanding Perfmon Counters while troubleshooting SQL Server Performance Issues
2. Appendix D: Server Performance Analyzing and Scaling
3. Analyzing Storage Performance
4. Using esxtop to identify storage performance issues
5. Understanding Database and Log Performance Factors
6. How to Calculate Your Disk I/O Requirements
7. Performance and Scalability of Microsoft SQL Server on VMware vSphere 4
8. Recommended IOPS per VM?
9. VMware Sets Virtualization Performance Records for Database and Web Workloads