Is your storage architecture stealing CPU cycles?
by David Merrill on Oct 28, 2009
Some of our work in storage economics tracks the cost and impact of storage architectures to CPU cycles (or MIPS, or IO) required of local or specialized servers.
We have documented this effect for years, and put together costs models on the added expense needed for dedicated servers or excess servers required for the storage environment. Lately I have seen dialog around a return to DAS, cloud architectures and some silo storage architectures that require unnecessary burdens on servers or CPU cycles. Here are some examples:
- Remote replication run and managed by the hosts
- Host based local replication
- Snap copies
- Backup tasks that burden the application server, and that require specialized backup servers (whatever happened to server free, LAN free backups?)
- CIFS and NFS are obvious
- Migration effort that taxes the application hosts
- Moving volumes
There are probably more CPU stealing examples from within various storage environments.
Now this topic becomes relevant now as new storage cloud architectures are emerging that return to a bundled CPU/Disk configuration, in that dedicated servers are needed for some pretty basic storage functions (copy, RAID, backup, etc.). As some storage arrays scale out, additional CPU nodes are added for capacity growth. Granted the CPU is imbedded in the storage control function, but there are new elements to power, cool, administer and purchase for a scale-out solution.
Architects need to be aware/sensitive to CPU cycles taken away from the hosts (virtual or not) that are required for the storage environment. There are storage solutions that are lighter-weight to the application host, and when you drill into the total cost of the solution, these costs can add up to a significant part of the storage infrastructure TCO.
[...] sure that you understand the cost of placing yet-another-host-agent on SAN attached hosts. David Merrill (HDS) goes into this a little more on his [...].