Exchange/SQL design question

[dapdx1999]

I'm evaluating the purchase of a 2020 with 15k SAS disks and a second tray with SATA disks. The second tray would be used for backup, maybe email archiving and hopefully file shares, maybe storing VMWare vm files as well.

The SAS disks would be used for Exchange (2003 now will be 2007/2010 when on the SAN) and SQL 2005 (maybe upgraded to 2008). We are a small 100 user environment with a total of about 1500 - 2000 IOPS (mostly reads) needed from the SAN. The plan is to virtualize the Exchange and SQL running on clustered ESXi servers. I am having trouble understanding how I can get the Exchange dbs and logs and the SQL dbs and logs on such a limited number of spindles.

I have met with some NetApp resellers and they told me no problem that you cut the aggregate up into FlexVols, put the dbs and logs on different FlexVols and the FlexVols get the benefit of all the spindles in the aggregate. However, my understanding of Exchange and SQL best practices still makes me think this is a bad design and I'm mixing logs and dbs and random and sequential all up on shared spindles and my performance is going to be terrible.

All the Exchange on SAN design documents I have read from NetApp and other SAN vendors use dedicated SANs for Exchange and dedicated disks for dbs and logs. None of the design documents I have located address Exchange and SQL on the same SAN.

Is it doable to have SQL and Exchange sharing the same 2020?

If so, is carving out FlexVols from the aggregate a legitimate way to mix SQL and Exchange dbs and logs on the same SAN?Anybody mixing SQL and Exchange on the same 2020, or know of any documentation about the same?

Any design suggestions are welcome.

Thanks

[gridley · Accepted solution]

NetApp storage stripes the workload across an entire aggregate - and an aggregate can be formed by several RAID groups. Generally the best performance is gained from the largest aggregate, rather than by splitting aggregates up to separate workloads. They also aren't conventional SANs so sometimes traditional storage concepts don't apply; for example, random writes will end up as sequential when they hit the discs on a NetApp array.

You can use FlexShare to prioritise FlexVols if need be.

In your case you'd only have 10 data spindles at best in one 12-drive SAS RAID group - it would still be best to keep them together.

Have you had a reseller or NetApp SE run through a sizing exercise with you to make sure you have enough spindles?

I would say most customers run NetApp SANs supporting multiple applications and uses, especially in the smaller installations. It's very common to have a FAS array supporting MS Exchange, SQL, VMWare and CIFS filesharing at the same time, for example.

[dapdx1999]

Thanks for the info.

The NetApp rep suggested a 2050 but - since I'm lucky if my company springs for a 2020 - that might be out of budget range. I'm starting to conclude that its not going to be possible to squeeze the SQL and Exchange together on the 2020. Guesstimating a SAS 15K drive to provide about 100 IOPS after RAID-DP overhead, etc, 10 drives would provide a max of 1000 IOPS which is below the minimum 1500 IOPS I need. Exchange 2007 would bring down the Exchange IOPS but its still too tight.

Related to those small companies that run SQL, Exchange and the other stuff on a FAS array, are they using one big RAID-DP group broken up into multi-FlexVols or are they cutting up the ten disks (2020) into multiple RAID-DP groups which doesn't seem doable since I'm assuming each RAID-DP group needs two parity disks?

[gridley]

They'll have one RAID group. The default size is 16 drives and it will try to stick to this as it offers the best performance / protection. If you were to go for more RAID groups you would be reducing the amount of data spindles you have available for performance because of extra parity drives as you mention. They will have multiple FlexVols.

A 15k rpm spindle will give about 180 random read IOPS before latency starts getting too high so you might have enough spindles, but I'd still be looking to your account team to let you know the spindle count you'd need (there are particular sizing exercises we use for SQL and Exchange.)