It should work, however there are several critical factors to consider in the design. First, is disk layout.
The 9960, as well as it's competetors, has a virtualization layer. You put X number of spindles into a disk group, then you care virtual drives out of the disk group and presnt them to the OS. The OS sees these virtual LUNs as physical drives. The problem is that when you carve multiple LUNs out of a disk group, there is no way to guarantee that IO against on LUN will not affect IO against another LUN in the same disk group.
This is the biggest mistake I have seen in SAN deployments regardless of the vendor. Even if you follow the Exchange deployment guide and split out you IO onto different drives, vendors commonly put all the drives in one disk group and carve up LUNs. This has the same effect as putting everything on one drive; all that tuning will have no effect. Worse yest, LUNS are careved out of the disk group and presented to different servers running different apps. You end up in situations where running payroll on the mainframe impacts SQL or exchange performance the 1st and 15th of every month. This is especially prevelant in situations where an existing SAN is "leveraged".
When you combine the first mistake with the second, it spells disaster. The second most common mistake is to confuse space with performance. The perfornce of a disk array is a function of the RAID type and the number of spindles. Commonly, storage architects are only concerned with how much space they need and neglect to incorporate and adequate number of spindles in the design. Increases in spindle capacity tend to drive this trend as design tend to contain fewer, larger, drives. You end up with inadequate IO out of the gate, and a spike in read activity on say the database detrimentally impacts write performance on the log drive. It's a recipie for disaster.
To do it right, you want to get a copy of the Exchange 2000 load calculator, that is a free download from MS. After filling in your projected users and usage patterns, check the IO numbers required for the logs, database, and smtp virtual directories. Use the peak numbers plus factor in growth over the next 3 years. Next, choose and appropriate number of spindles and RAID type to meet your needs for each LUN. Assuming 10K drives which get about 100 I/O per second on a single spindle:
P = performance of a single spindle
n = number of spindles
RAID 5 Read
P * (N-1)
RAID 5 Write
P * N/4
RAID 1 or 10 or 0+1 Read
P * N
RAID 1 or 10 or 0+1 Write
P * N/2
It's clear that to reach a given number of IOs, RAID 1/10/0+1 requires fewer spindles. For performance, this is the clear choice. RAID 5 gives you the most space with the fewest spindles, at the cost of performance; especially write performance. With applications like Exchange or SQL, yes you do need to meet a minimum amount of space however, performance is the critical factor. Performance requirements determine the number of spindles required, not space requirements.
Next, put all of the drives for your log LUN in one disk group. Only carve out the one LUN. Do the same for the database LUN and the SMTP virtual directory LUN. The disk group is the only barrier that will prevent IO on one LUN from impacting another. This way, you can be assured that you LUN will perform to the IO level it was designed for.
There's quite a bit more, it would probably fill a book. This, however, should get you started in the right direction.
BTW: We want to se writes to the logs <10ms and reads/writes to the database <40ms on average in Exchange.
