You just went out and upgraded your storage to all-flash. Or, maybe you have moved your systems to the cloud where you can choose the SLA to get the performance you want. We can provide you with a secret weapon that will make you continue to look like a hero and get the real performance you made these choices for.
Let’s start with why you made those choices to start with. Why did you make the change? Why not just upgrade the aging storage to a new-gen HDD or hybrid storage subsystem? After all, if you’re like most of us, you’re still experiencing explosive growth in data and HDDs continue to be more cost-effective for whatever data requirements you’re going to need in the future.
If you went to all-flash, perhaps it was the decreasing cost that made it more approachable from a budgetary point of view and the obvious gain in speed made it easy to justify.
If it was a move to the cloud, there may have been many reasons including:
• Not having to maintain the infrastructure anymore
• More flexibility to quickly add additional resources as needed
• Ability to pay for the SLA you need to match application needs to end user performance
Good choices. So, what can Diskeeper® and V-locity® do to help make these even better choices to provide the expected performance results at peak times when needed most?
Let’s start with a brief conversation about I/O bottlenecks.
If you have an All-Flash Array, you still have a network connection between your system and your storage array. If you have local flash storage, system memory is still faster, but your data size requirements make it a limited resource.
If you’re on the cloud, you’re still competing for resources. And, at peak times, you’ll have slows due to resource contention. Plus, you will experience issues because of File System and Operating System overhead.
File fragmentation creates significant increases in the number of I/Os that have to be requested for your applications to process the data they need to. Free Space fragmentation adds overhead to allocating file space and makes file fragmentation far more likely.
Then there is all the I/Os that Windows creates that are not directly related to your application’s data access. And then you have utilities to deal with anti-malware, data recovery, etc…. And trust me, there are LOTs of those.
At Condusiv, we’ve watched the dramatic changes in storage and data for a long time. The one constant we have seen is that your needs will always accelerate past the current generation of technologies you use. We also handle the issues that aren’t handled by the next generation of hardware. Let’s take just a minute and talk about that.
What about all the I/O overhead created in the background by Windows or your anti-malware and other system utility software packages? What about the I/Os that your application doesn’t bother to optimize because it isn’t the primary data being accessed? Those I/Os account for a LOT of I/O bandwidth. We refer to those as “noisy” I/Os. They are necessary, but not the data your application is actually trying to process. And, what about all the I/Os to the storage subsystem from other compute nodes? We refer to that problem as the I/O Blender Effect.