02/10/2011
Notes on HP raid controllers
Lately I had to deal with some HP raid controllers and I’ve gathered some notes on them. I’ll post them here so I won’t forget about them.
First of all, don’t even think on using them without a battery pack. Seriously DON’T. The performance degradation is humongous. Without a battery pack the controllers were giving me 1/20th of the results with a battery pack. If you want to quickly test them, try iozone using the following options: iozone -t4 -I
Installing hpacucli is a also a must if you want to monitor or configure the controllers from within your OS. Be sure to add the repositories from HWraid to your system and then issue: aptitude install hpacucli
(you are using Debian, arent’ you?). That reminds me that I am using those repositories on so many systems I manage that I must send a donation to the people at hwraid to thank them.
Below are some commands using hpacucli that I used.
# Show everything about your raid controllers
# hpacucli controller all show config detail
Cache Board Present: True
Cache Status: OK
Accelerator Ratio: 25% Read / 75% Write
Drive Write Cache: Enabled
Total Cache Size: 512 MB
Battery Pack Count: 1
Battery Status: OK
SATA NCQ Supported: True
What you must take notice here is the Accelerator Ratio, Drive Write Cache and Battery Pack Count.
if you have a battery pack installed but your Drive Write Cache is still shown as “Disabled”, you can enable it using the command:
# hpacucli controller slot=X modify dwc=enable
You’ll know what to put instead of “slot=X” from the output of the previous command (show config detail).
To modify Accelerator Ratio (read/write):
# hpacucli controller slot=X modify cacheratio=25/75
To enable Array Acceleration for one of your logical drives use:
# hpacucli controller slot=X logicaldrive Y modify aa=enable
If you happen to face the following error while opening hpacucli, don’t worry. You don’t need to reboot your machine as I’ve seen in various blogs.
Error: Another instance of ACU is already running (possibly a service). Please
terminate the ACU application before running the ACU CLI. Press ENTER to
exit.
What you need to do is delete the shared IPC that hpacucli left when it got killed for some reason.
To see all your ipcs:
# ipcs ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status ------ Semaphore Arrays -------- key semid owner perms nsems 0xffffffff 32768 root 0 1 ------ Message Queues -------- key msqid owner perms used-bytes messages
Then use ipcrm to remove the array with the semid you want:
# ipcrm -s 32768
and try to start hpacucli again.
References:
1. http://www.datadisk.co.uk/html_docs/redhat/hpacucli.htm
2. http://people.freebsd.org/~jcagle/hpacucli-readme
Filed by kargig at 12:15 under Linux
Tags: Accelerator ratio, cache ratio, debian, HP, hpacucli, Linux, P410, raid, raid controller, storage, sysadmin, Write Cache
6 Comments | 11,307 views
The reason that all raid controllers suck without the battery pack, is that they have to write all the data to disk before they ack the write. RAID5 is not the best solution for having to write to disks (without the cache). This is not bad, since you want to be sure that your data exist at a consistent state. But perhaps other raid controllers do something smarter so they have better performance (haven’t really benchmark different RAID controllers).
A colleagues of mine has fixed the performance problem by enabling the local disk cache: be aware that this expose you to the risk of data loss in case of power or other kind of hw failure…
Just a simple question, is there any way to configure HP Smart Array, so when it detects that an specific drives is failed send a message to OS (some Linux) so my monitoring tool can know about the faulty drive?
Thank you very much.
I’m using nagios checks to do this. Take a look at dsa-check-hpacucli.
I’m sure you will find more online.
Thanks Kargig for your reply. I’ll analyze the code, thanks again.
Just wondering if HP Smart Array does not have an automatic way to do this? I guess it does, or at least, it should does. When it detects that a drive is failling pass this messages to the OS logs.
Maybe somewhere on the configuration files? I made a lot of research but I couln’t find any way to do it.
“Drive Write Cache” refers to the cache *on the drives*, which are not protected by the controller battery back-up. It’s unlikely to be safe to enable it unless you also have a separate battery back-up for the drives.
The “No-Battery Write Cache” *does* refer to the controller cache; it should normally be disabled, to prevent the same issue.