When people have issues with performance on a server, the first thing they think about is adding flash to that server for tiering or caching. It’s a logical first step. For most companies these servers are hosting their VMware environment, but is it really that easy? To talk about flash and improving it’s use on your servers I sat down with Rich Peterson from SanDisk and Eric Slack, Senior Analyst from Storage Switzerland.
Rich, if you don’t mind, I’d like to start with you. When talking about adding flash to the server for tiering and caching, aren’t their non virtualized servers good candidates for server side flash as well?
Rich: Yes, that’s actually the case. There are many, of course, in the VMware environment. It’s that latency between the I/O and storage that’s the primary constraint on application performance and VM density. But I/O latency can also be a constraint on certain applications running in bare metal environments. So, in order to get the most value out of the server CPU and memory and get the greatest performance to the application, that I/O latency should be addressed. One of the easiest ways to address it is with flash directly installed into the server itself.
Charlie: Eric, what kind of applications are there that you see running on bare metal servers and why?
Eric: These can typically be legacy applications that IT doesn’t want to particularly move because they’re running and they’re working. It’s sort of a “if it ain’t broke don’t fix it” paradigm. They can also be clustered servers. These can be pretty complicated. Even in clusters where they’re spending quite a bit of money on software to do that cluster, again it’s a production application. It’s working so they’d like to leave those alone. There’s also the idea, real or imagined, that virtualization will affect performance. It can in some scenarios but it’s not a given. These can be servers where performance is important, making people hesitant to move them over to virtualization. Rich, can you think of any examples of servers that people that are hesitant to virtualize?
Rich: Sure. A lot of transactional servers – servers that are doing real time transactions and where the response latency is the critical metric won’t be virtualized. In a lot of cases it’s what you said, it’s a legacy application – it’s an “if it isn’t broke don’t touch it” kind of scenario. Quite often with these legacy applications, you’ll see that the workload being placed on the application has been increasing over time.
You might look at a healthcare records application for example, where patient records used to be relatively small, but as the resolution of medical images gets larger and larger, those patient records can balloon in size.
Now the question with the IT administrator basically is, “How can I improve the performance of these legacy applications if I’m not allowed to touch the code itself? How do I fix that problem?” And running on a bare metal server, it may be the case that it’s really a storage I/O latency issue. And that’s one that you could resolve by adding a flash based cache into the server that’s running the application.
Charlie: Rich, are there any considerations to choosing a flash solution for these bare metal servers, anything that’s different from, say, a virtualized server?
Rich: There are some considerations. The first is to understand what is the metric of performance you want to improve. Is it the latency of the response time? Is it the number of concurrent processes that can be supported? Is it reducing the batched process time for an analytics application? Or improving the response time for real-time analytics applications?
Those considerations are going to lead you to ask the question as to whether you need to deploy a write-back cache, or a write-through cache. Which is to say, will you get the required performance improvement by accelerating read operations only, or do you need to address both read and write operations with the cache?
Charlie: Eric, you recently did a blog on how to address performance problems in virtual environments that talks about looking at other non virtualized servers, the bare metal servers. This does seem a little counter-intuitive. Can you explain how putting flash into one of these bare metal servers can help the performance on any other server, say a host server in a VMware environment?
Eric: Yeah, it does seem a little counter-intuitive, Charlie. What we’re really talking about here are stand-alone servers like you just mentioned. Maybe they’ve got large data sets and significant workloads. If they’re on a storage environment, they’re on a SAN, we can really be taking some of the available storage performance from the other systems that are on that SAN – like virtualized servers.
So the concept is that when running flash-based caching inside a bare metal server you take some of that workload off the shared storage system and essentially are reserving those resources (or returning those resources) to other servers, like the virtualization host.
Actually Rich, we just did a webinar with you and I heard you talk about a customer example that you had. One of your SanDisk customers had gotten some significant percentage of performance that was returned, a big number that came out of the traffic that was reduced off of this network in the storage array, can you talk about that?
Rich: Yeah, sure. It’s basically looking at a database application that is highly transactional in nature. By executing reads and write operations against the solid state storage in the server, about 90% of those I/Os came from the local cache, versus traversing the SAN and reaching down to the disk based storage. So, in that environment by using server-side caching, they were taking 90% of the I/O traffic from those applications off the SAN and freeing up bandwidth for other applications contesting for that bandwidth.
We’ve seen this in a number of different instances where some large organizations running legacy Unix servers were running on the same storage infrastructure as a bunch of bare-metal window servers. The window servers were taking up a lot of bandwidth that the Unix servers needed.
Now, we’re able to accelerate the performance of the applications on those Windows servers, but just as importantly we were able to reduce the overhead that those Windows servers were placing on the SAN, which freed up bandwidth and improved the performance of the applications running on the legacy Unix systems. So, it’s a very paradoxical kind of thing, but that’s what happens in a shared storage environment.
Eric: So just to be clear, when you’re talking about bandwidth, you’re talking about network bandwidth but also the amount of resources that the storage controller has to divvy up to the hosts that are using that shared storage, right?
Rich: That’s exactly right, yeah.
Eric: Wow! That’s pretty amazing.
Charlie: There is a webinar Rich did with Storage Switzerland Founder and Lead Analyst George Crump. It’s on-demand so you can go anytime to storageswiss.com and you’ll find it there, or you can do a search for SanDisk and you can find that webinar.
SanDisk is a client of Storage Switzerland
StorageSwiss.com - The Home of Storage Switzerland 