We added a Pure Storage flash array over a year ago to house our VMware VDI infrastructure and it worked well but it was never really tested. The number of desktops didn’t reach the number I had hoped by a long shot. The lack of VDI usage numbed the excitement of the dedupe and compression numbers that the Pure Array exhibited with 200 Windows 7 machines on it. Sure, getting 20-1 data reduction is awesome, but what would happen if we didn’t have 200 instances of the same data sets on there?
After some initial testing, we moved our production databases from a Dell Compellent to our Pure Storage array. We chose to have SQL and VDI workloads on the same array. How about that? Such a design used to be blasphemy or just dumb. Not anymore.
The SQL servers themselves are pretty old HP servers running Windows 2008 with 8 Gbps Fiber Channel NICs on the SAN configured in a standard Failover Cluster. Pure doesn’t have any documentation on supporting that OS version specifically, but they do have MPIO guidelines for Windows 2008 R2 and newer. There are several Microsoft hotfixes that help with Pure connectivity available for every OS beyond Server 2008, but we didn’t see any major issues with the testing. Plus, we’re moving off of that older hardware very soon in favor of new Cisco B200 M4 blades and a newer Windows Server OS.
I zoned the FC switches so Pure and the HPs could hook up then configured MPIO on the servers. Pure uses server groups to map the same volumes to multiple machines so that was no problem. A rescan on the servers showed the volumes created prior and I initialized and formatted them on the active SQL cluster node.
The DBA then copied the files from the Compellent to the Pure and fired up the database.
Now, some pictures: Data Reduction
The amount of storage space used on the Dell Compellent array: 868GB
Pure’s deduplication and compression reports a data reduction of 3 to 1..or is it 29 to 1! Disk Usage: 68GB
These numbers look ridiculous when comparing 868GB to 68GB. Pure’s overhead is calculated in a different way that won’t show on the volume stats like Dell does. There is a certain amount of space Pure uses for its magic that’s calculated in when you size an array reducing the amount of usable space. Minus the RAID overhead on the Compellent, we’re still looking at a round number of 500GB of data that was copied. That’s a 7.5 to 1 data reduction ratio using 500GB as the original data size and the resulting 68GB on the volume, which is double than what Pure is admitting to. The point here is, just using raw numbers, what did take 868GB on the Dell is using just 68GB on the Pure. The amount of storage saved here is definite ROI point.
If you noticed the “Total Reduction” number of 28.7 to 1 then the graph makes more sense. 68 x 29 (rounding up the reduction ratio) gets you close to the provisioned 2000GB volume. Total Reduction takes into account the space saved with thin provisioning.
This brings up another interesting element from Pure which is how they explain their data reduction rates. For the customer, it isn’t an exact science. It may be for them, but Pure doesn’t give us a calculation tool to get numbers beyond the vicinity.
I’m not saying that’s a bad thing unless you have someone in your department who really, really needs the details then you’ve got a blind faith thing going on because they aren’t going to get them. When we’ve presented Pure with questions concerning the reported used space and reduction rates not fitting together they’ve responded that the reduction rates are approximate. Not only that, but the approximations lean toward the low side. So, if they really are getting 7.5 to 1 they may report 3 just to make sure they don’t over-approximate.
Are you getting that “don’t worry about what’s behind the curtain” vibe yet? Pure has very intelligent and responsive customer facing engineers that will explain to you what is going on to get these extraordinary results. That’s not to imply that you should feel inadequate if the explanations cause your mind to splinter. I’ll put it this way, I’ve stopped asking certain questions.
From a Windows perspective, nothing looks any different. The database reported sizes are the same whether the reside on the Dell array or the Pure. This holds true for VMware as well. Reported datastore size in VMware’s management tools don’t take into account the Pure algorithms for actual array space used. So, that brings in another management situation where Windows and/or VMware will run out of space and disk/datastore expansion will be necessary to appease the software.
Get comfortable with over-provisioning is what I’m saying here. Again, not a bad thing since you know approximately how much space is actually being used on the Pure array.
More pictures: Latency
Dell Latency stats on the SQL database. Ignore the midnight backups at 00:00
Latency and other on the Pure during a typical SQL workload
The big stat here is latency. There is approximately (see, now Pure has me doing that too) 5 times less latency on the Pure array than Dell. The latency “spike” on the Pure is a measly 3ms which is 3x better than the average on the Dell.
Perception and numbers slow dance together in these situations. The numbers look better but does it “feel” faster? According to our Oracle application developers the answer is a resounding “yes!”. They had immediate numbers to back that up with query times taking half the time or less than usual. That will transfer to the users as well, especially the ones using VDI machines. This also helps in troubleshooting as we know the database can’t get much more responsive than it already is.
Slowness, in all it’s forms, can be attributed to something other than storage at this time. It could be bad code, a remote network or a choking VDI machine or maybe application error. I can tell what it won’t be: Pure Storage.
Moving SQL to Pure looks like a great move for us and I’m approximately 99% sure we’re never going back.
Categories: IT Pros
wfcastle33.wordpress.com 
Leave a Reply