• E-mail this page
• |  Print this page
• | 
• | 
• | 

Understanding Storage Controller Performance

Storage controllers are the engine that drives the storage system you own. They are essentially a compute engine for storage arrays. Understanding storage controller performance and what can impact storage controllers is an important step in the optimization of your storage environment. It is also something that many storage managers assume is good enough.

Storage controller’s performance can be impacted by a host of circumstances. Today's storage systems are asked to do so much more than the first external SCSI arrays. First, they manage significantly more capacity and drive quantity. Capabilities like snapshots, replication and the RAID calculation all impact the storage controller. Further new features like thin provisioning are just adding to the problem. This is why so many storage systems hit maximum performance at about 1/2 the drive population than the brochure states.

Second, storage systems are no longer responsible for servicing the requests of a single server. In shared environments the storage controllers can be responding to dozens if not hundreds of attached servers and workstations. To compound the issue, many environments, thanks to server virtualization, will have multiple server instances making multiple storage I/O requests from a single host. This leads to extremely random and unpredictable workloads in the environment which can saturate controllers.

Today's storage controllers are responding to requests from more performance hungry servers that are attached to them. In web applications for example the storage may be responding to thousands of simultaneous users all accessing the same database or randomly each accessing different photos. Again, in virtualized server environments, these demands can come from 1,000 VMs spread out across a few hundred physical systems.

The classic dual controller architecture itself is misleading. In many cases both controllers are not equally handling the storage I/O for a given RAID volume. Usually one is assigned as the primary and the other as the secondary. The secondary is only used if the primary fails. The result is a single controller, handling all the above highly random conditions, can more realistically get saturated.

The classic response has been to overbuy storage compute muscle. The problem with this is that we all know that today's processors will be replaced by tomorrow's for less money. When you overbuy processing you are paying extra for compute muscle that you may not need until next year or later.

This has lead to some of the major manufacturers following the lead of a few storage innovators to start delivering clustered storage systems. Although how these clusters are assembled and the services they offer vary, they address the storage controller performance bottleneck that we detail in our article "What's Causing the Storage I/O Bottleneck?".

These systems allow continuous scale of capacity, I/O bandwidth as well as storage compute performance. Not every data center is going to encounter storage controller performance issues, and for those data centers standard systems are more than acceptable, but if your data center can cause any of the above conditions then storage controllers are something you need to pay attention to.

Track us on Twitter: http://twitter.com/storageswiss

Subscribe to our RSS feed.

George Crump is lead analyst of Storage Switzerland, an IT analyst firm focused on the storage and virtualization segments. Find Storage Switzerland's disclosure statement here.

« Microsoft Seeks SAP Synergy In Alliance With Capgemini | Main | New Wi-Fi Tech Will Let Devices Connect Without Hotspots »