Proliant ML350 Won’t Load Windows

The HP Smart Array P410 is a fine controller, but you will get poor performance out of it if you don't have the battery-backed or flash-backed cache units installed. The cache makes a tremendous difference in that writes are buffered by the cache memory before being committed to disk. You get the write confirmation to the application without having to incur the latency of the physical disk drives.

Here's a 4GB dd on a similarly-spec'd system (DL380 G7 with 24GB RAM and a p410 with 2 x SAS disks and 1GB Flash-Backed Write Cache). The RAM helps a lot in a test like this, but you get the idea...

[root@xxxx /]# dd if=/dev/zero of=somefile bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 3.70558 seconds, 1.2 GB/s

But realistically, your write performance with two SAS drives in a RAID 1 on that controller with the appropriate cache should be between a sustained 130-170 megabytes/second. A quick iozone test on the above server configuration shows:

[root@xxxx /]# iozone -t1 -i0 -i1 -r1m -s16g
Write
Avg throughput per process                      =  166499.47 KB/sec
Rewrite:
Avg throughput per process                      =  177147.75 KB/sec

Since you're using ESXi, you can't run online firmware updates. You should download the Current Smart Update Firmware DVD, burn it to disk and make sure your system is patched to a relatively recent level.

Here are the controller's quickspecs: http://h18004.www1.hp.com/products/quickspecs/13201_na/13201_na.html

You will want to purchase one of the following, ranging from $350-$600 US:
512MB BBWC
512MB Flash Backed Write Cache
1G Flash Backed Write Cache

To answer your question, the cache solution will help the most. Additional disks won't make much of a difference until you handle the caching situation.

*Note for other users. If you have cache memory on recent HP controllers with up-to-date firmware, there is a write cache override available if you have RAM on the controller but no battery unit. It's slightly risky, but can be an intermediate step in testing what performance would be like on the way to buying a battery or flash unit.

So, after bringing a third system into the mix, and experiencing the same issue, we began to question the environment. I dug up a copy of the HP ProLiant Servers Troubleshooting Guide and found the POST problems flowchart shown below.

Carefully running through the steps in the chart, we realized that the one constant across all of the servers was a KVM switch attached to the data center crash cart. This was a consumer-class USB-enabled KVM. As per the highlighted node in the flowchart, Do you have known good KVM?, I could not answer conclusively.

So, we unplugged the servers from the KVM switch and ran an automated boot, sleep 300; reboot sequence in rc.local. The servers had no issues with this, regardless of the normal DIMM, low-voltage DIMMs, PSU wattage, etc.

This was all the result of a poor interaction with a USB KVM switch. By virtue that this was the console, it ensured we'd see the failure if we were looking for it. Self-fulfilling...