Anyone using one of these Enterprise SSDs for SQL?

[Lordz]

Looking at using one in a SQL box that constantly has 100-150 clients workstations talking to it so disk speed is importaint to us.
http://www.oczenterprise.com/ssd-pro...-c-series.html
Anyone tried one yet?
Cheers

[Bad Sektor]

Fusion IO user here.

Have you gathered any statistics over the existing environment to discover where the shortfalls currently lie?

Would suggest whatever you do - have some form of redundancy available to you - I guess what I'm saying, is that if some way it fails, and your IO eventually exceeds what a regular RAID of disks and large RAM (for SQL cache) can cope with even in a degraded state.

Whether it be a second SSD enough RAM to hold the SQL databases in memory with a RAID controller serving them, just consider the consequences of having all your eggs in one basket if there is no failover avialable.

I'm personally a little cautious of these new SSD technologies, they have a short history in the data center, although all experiences of mine have been positive, just apply your same levels of caution with any technology and consideration for a failover scenario.

Either way, your question is about those units in particular, I'm sorry I have no experience with these, but if your SQL stores are experiencing a great deal of random reads/writes and warrants the reduced latency, then it's a great step forward. I've found having extravagant amounts of RAM avialable to the host to be equaly as beneficial (enough RAM to hold all MDF in memory).

I'd hope OCZ enterprise SSD's are cheaper than Fusion IO, might consider having a look into these next time around.

Dave

[Mr Bit]

We're currently running 3 SSD's in RAID 5 on our Clariion for a poorly coded SQL 2000 finance application VMDK. This financial system is a piece of cr*p..............in our particular scenario our only option was to throw as many IOPS as possible to the VM. Results have been very good. ie: reports that were taking 10-15 mins to generate in some instances are now taking 1-3.

[elvis]

Originally Posted by Mr Bit

We're currently running 3 SSD's in RAID 5

What prompted you to do that, instead of 4 drives in RAID10?

[Soarer GT]

Originally Posted by Mr Bit

We're currently running 3 SSD's in RAID 5 on our Clariion for a poorly coded SQL 2000 finance application VMDK. This financial system is a piece of cr*p..............in our particular scenario our only option was to throw as many IOPS as possible to the VM. Results have been very good. ie: reports that were taking 10-15 mins to generate in some instances are now taking 1-3.

SQL in a VMDK? There's your issue.

[elvis]

Originally Posted by Soarer GT

SQL in a VMDK? There's your issue.

Yeah well, some people just can't be convinced that it's a bad idea.

File inside a container inside a file inside a container inside a poorly written clustered file system that relies on SCSI locking? What could possibly go wrong?

[Skitza]

Originally Posted by Soarer GT

SQL in a VMDK? There's your issue.

Never had an issue, can't tell the difference. Maybe your'e doing it wrong

[bsbozzy]

Originally Posted by Soarer GT

SQL in a VMDK? There's your issue.

Originally Posted by elvis

Yeah well, some people just can't be convinced that it's a bad idea.

File inside a container inside a file inside a container inside a poorly written clustered file system that relies on SCSI locking? What could possibly go wrong?

Out of curiosity, do you connect to the LUN from the VM?

[Mr Bit]

Originally Posted by elvis

What prompted you to do that, instead of 4 drives in RAID10?

They were 3 drives that were originally going to be used for fast cache. We came to the conclusion that in our particular situation the best way to utilise them was for raw IOPS.

As for the guys questioning the use of a virtual disk........what have your experiences been using vmdk's along with demanding database servers?

[Bad Sektor]

Originally Posted by elvis

Yeah well, some people just can't be convinced that it's a bad idea.

File inside a container inside a file inside a container inside a poorly written clustered file system that relies on SCSI locking? What could possibly go wrong?

Seperating yourself from your position on VMWare for a moment, if the SSD's are connected via a hardware RAID controller to the host, what would be wrong with mounting the storage as an RDM to address the layering of storage ?

[elvis]

Originally Posted by Skitza

Never had an issue, can't tell the difference. Maybe your'e doing it wrong

Then you're not pushing SQL Server very hard.

Having worked in some large SQL Server shops in the past (my last two places of employment, in particular), VMWare was fine for test/dev stuff, but there's no way in hell it could keep up with their production databases and workloads.

Originally Posted by Bad Sektor

Seperating yourself from your position on VMWare for a moment, if the SSD's are connected via a hardware RAID controller to the host, what would be wrong with mounting the storage as an RDM to address the layering of storage ?

Nothing, as long as you're not topping out the IOPS (there is a hit, even with RDM - do the benchmarks on your own hardware and see it for yourself). But the OP stated clearly that they were doing it in a VMDK, which prompted my comments above.

And my position is the same for any virtualisation technology that wraps file systems inside of files. They *all* take a bad IOPS performance hit, regardless of how fantastic the software or file systems in question are. It doesn't take a lot of effort to understand why this is the case, and why it will never come close to raw storage. It's no secret I'm a huge fan of KVM and Xen, but both products also see an IOPS performance hit when doing the same "file system in a file" setup.

Again, it's fine if you're running light loads. IOPS are one of those things where, if your app is performing as needed, then it's fine. But once you hit that wall, it's a very black and white thing. And you'll know when you hit that wall.

RDM and the equivalent methods in other virtualisation systems are substantially better if IOPS matter, but it's pretty obvious that bare metal will win for true IOPS performance. That can be mitigated somewhat with better hardware if you absolutely must utilise the benefits that virtualisation gives you. Of course, people like Microsoft are notorious for telling you to run your database on bare metal when strange performance issues crop up at the high end of utilisation, which is something else to consider (I've been there and done that).

With that said, I've started a new job now, and there's not a single SQL Server install in site. So I'm pretty happy to see the tail end of that product for a while.