SAN Disk Allocation

I'm looking at getting an MD3620i SAN with 24 drives for virtualizing our envoroment and was wondering the best way to carve up the disk.

For starters I will be running DC, SQL database, SQL repoting, Exchange and a web server eventually looking to move the remainder of our environment to this setup. I am stretched for budget or would look at getting an additional MD1220. Do I have enough disk here? Any suggestions on how I should set this up?

I'd drop all 24 disks into the same disk group to give you the maximum I/O overhead possible. You'll be hosting some very highly I/O intensive applications on that array (SQL DB, SQL Reporting, and Exchange), so you'll need everything you can get. And please don't use 7.2K RPM drives; they may be cheap and big, but you'll pay for it in performance scaling.

In my opinion, optimizations like putting DB and Log traffic on different spindles is likely to be drowned out in the overall virtualization I/O traffic. You're going to have two big database I/O applications on this storage (SQL and Exchange) and (again, my opinion) you'll need as much I/O overhead as you can get, so pool it all into one big pool; rigidly separating DB and Log I/O will cause you to run into bottlenecks sooner.

Also consider making sure your Exchange server(s) Online Defrag & Backups don't coincide with your SQL backups. Those three operations are very heavy I/O, and you don't want them overlapping if at all possible. As for Reporting Services, if you have any really big queries/reports/jobs running, try to avoid those backup periods.

The DC and web-servers are very minor players here, so should be just fine.

WHY should you bundle them all into a single group and not split them out?

With 12x 15K drives and 12x 10K drives, you'll probably end up having to have two disk-groups, one for each speed. I wouldn't recommend splitting further.

12x 15K drives should provide you with around 2270 I/O Ops/s for fully random I/O in R0, 1135-2270 for R10, and 2080 for R5. The 12x 10K drives should give you 1700 I/O Ops/s (850-1700 in R10, 1560 in R5). The R10 speeds are variable because it depends on your read/write percentages, and whether or not the controller will supply reads from multiple stripes (I don't know if the Dell does that or not). Significantly sequential operations will be faster, but you can't count on that with a shared storage system.

Those are some respectable speeds, but they also represent the maximum performance for each disk-type. Going with the full separation model for each of your five identified services:

• SQL
• SQL Reporting
• Exchange
• AD DC
• Web-serving

I'd lump the last two on a pair of 300GB 10K drives in a R1 config, leaving the other 22 disks for the rest. As for the rest...

• SQL
  • 1x R5 set of 6 15K drives for logs
  • 1x R5 set of 4 10K drives for databases
• SQL Reporting
  • 1x R5 set of 3 10K drives for databases and such
• Exchange
  • 1x R5 set of 6 15K drives for mailstores
  • 1x R5 set of 4 10K drives for logs

Depending on your capacity requirements, you may need to swap the DB/Log volumes. A configuration like this gives both SQL and Exchange a total of 945 I/O Ops/s for Logs and Mailstores respectively, and 420 I/O Ops/s for Databases and Logs respectively. Reporting gets 280 I/O ops/s. This gives an overall disk subsystem performance of 3230 I/O Ops/s.

Compare that with 3640 for overall system performance with just two disk groups. That's 12% of performance you're sacrificing in order to isolate your production systems. One of the chief benefits of shared storage systems like this is that you can make more efficient use of the storage. Separating things like the above means your prime benefit is the cost savings for having all the storage in one device on one set of RAID controllers instead of having multiple RAID controllers.

By going with the siloed config above, you hit I/O bottlenecks faster:

• Your DB backups can fully saturate the 945 I/O Ops/s they've been assigned and will take a lot longer than if they had double that space available to them. During this time DB queries will be markedly slower. This is an I/O bottleneck.
• When dealing with occasional complex queries your DB volumes can't use unused capacity in other silos to return results faster. They will be constrained by the disks explicitly assigned to them. This is an I/O bottleneck.
• When backing up Exchange (which can go very fast, it's nice that way) your backups will take longer, causing visible performance problems for users interacting with the system during the backups. This is an I/O bottleneck.

When others say that 'one big disk group means you hit I/O bottlenecks faster', what they usually mean is that one badly behaved app can affect the performance of the whole and it's best to silo everything to protect everything from everything else. They're treating storage like old operating-systems used to treat memory: everybody gets a discrete memory allocation at startup and no-one can go outside of it. Unlike memory, there is no such thing as virtual memory in this model, so it's physical memory that's being assigned to processes at startup time.

Better to treat it like modern OSs treat memory: virtually. The system has 3640 I/O ops available to it, why not let everything think it has that much to play with. Everything won't use that all the time, and the storage subsystem will be able to serve most requests just fine. If demand does get to that level, then things start bogging down (IOWAIT increases), and it's time to analyze the system to figure out what's causing the slow-downs.

Well I am no expert, but for my ESXi environment which runs a small DC, a small SQL DB and an Exchange server. We just lumped all of the storage into one pool.

Based on what I am reading I think more of how you want allocate the space will be left up this individual VMs rather than the storage backend.

If you are using VMware I would defiantly use thin provisioning on the VM disks so they don't take up all of the space until they need it. That has saved us a lot of space compared to thick provisioning everything.