W2K3 3

[picapiedra]

Hi everyone and thanks in advance.
Does anyone knows if there is any compatibility issue between HDS SAN 9960/9970 and Windows 2003?
This OS is not officially supported in the 9900Vseries specs.(

http://www.hds.com/products/systems/9900/specs/op_system_support.html)

Any information about that?
We are planning to connect some W2K3 server to SAN 9960 and 9970 (HBAs Emulex LP9002L-F2 LC connectors, switches Brocade Silkworm 3800,etc).

 

[petemullis]

Hi, this may be of some help:

We have recently implemented several Win 2003/Exchange 2003 servers on two HDS 9960 arrays and have had some performance problems.
Our problems surround the write performance to the SAN. Microsoft say for the counter "Avg. Disk sec/write", the value should not exceed:

avg: 20ms
spikes: 100ms,

we are getting:

avg: 150-200ms (offpeak-peak)
spikes: 200-350ms (in some extreme cases as much as 1.3 seconds)

We are using HP Proliant 580-G2 servers and dual Emulex LP9002L HBAs for loadbalancing. The switches in use are brocade silkworm 3900. We are also using HDLM (Hitachi Dynamic Link Manager) 5.2.

Our kernel memory paged-pool bytes is also running at dangerously high levels. In one case we had to reboot the server because it ran out of kernel user space.

Not managed to check out HDS Graph-Track etc. yet.

Did you observe anything similar?

 

[xmsre]

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.

 

[petemullis]

You really know your stuff.

You are exactly right about an existing SAN being "leveraged". This is what happened. The matter was out of my hands, and unfortunately the existing san was carved into RAID 5 chunks.
Not only that, the disk grouping was out of my hands also, so its no wonder the system was under strain.

Thanks again,

Pete