1794-Drive Array - Array Accelerator Battery Charge Low...

[Jake Douglas]

I have received the above error message on and off since install of server back to 2006. In the event I need to replace the array accelerator will I lose Array configuration or will the "drives" write their configuration to the new array accelerator?

The array accelerator is in a DL380 G4
Smart array 6i version 2.58

One logical drive -mirrored (2 physical drives)

thanx

[KarloChacon]

hi Jake that's in fact a known issue

you must update your 6i Controller up to 2.58 version

https://community.hpe.com/t5/disk-enclosures/1794-drive-array-array-accelerator-battery-charge-low/m-p/4240123#M27914

regards

[gregersenj]

" In the event I need to replace the array accelerator will I lose Array configuration or will the "drives" write their configuration to the new array accelerator? "

Replacing the accelerator, doesn't influence the configuration.
The accelerator, is only cache.
And in your case it's only the battery.

If you had to replace the Smart Array controller, then the new controller simply
read the configuration from the disks.
Configuration is stored on all drives, as meta data.

First follow Karlo's advice.

[Jake Douglas]

Guys,

Thanx for the great information and quick response.

-jake

[J. K. Anderson]

Given the advice, to update the 6i Controller up to 2.58 version, does anyone know if the response (posted write delay) to the condition (battery charge below 75%) exists prior to certain versions, but is just unreported? In other words, are there levels of firmware at which the issue occurs, but for which there is no system reporting of the error ... hence you are experiencing a "silent problem?"

[gregersenj]

hmmmm. Havn't been able to find anything on that. But tha smart array controllers always disable write cache when the batteries is insufficiently charged.
And it will tell you that the write cache is disabled.

But why didn't you upgrade to the latest FW?
2.58 is minimum vertion.

[James D. Young]

I have the same problem, but I have the firware at 2.84. Support just sent me new batteries today and I have installed it. It does not appear to charge it or change the status, I am not sure which is happening.

Is there something I am missing here. The batteries are not hard to change.

[lwright]

I have been fighting this same issue on at least 5 DL360 G4 and 1 DL360 G4p servers since December 2007. I have updated the firmware to v2.84 and replaced the batteries and battery housings. The battery will recharge and last at most, one month, but as little as 3 days. I have contacted HP numerous times, but they continue to state that there is no known issue. I'm tired of chasing these 'battery' issues. Has anyone had any success in getting the batteries to recharge and STAY recharged?

[Lamer_1]

I've the same message on the new (just bought) server. The battery simply can't be discharged.

Please help me with this issue.

Server ProLiant ML350 G5.

[JBonde]

Our data center (2200 HP ProLiant servers) is currently dealing with around 100 of these battery issues that all started around early 2008. During this year we have probably had several hundred of these battery failure alerts. Unfortunately we haven't found any guidance from HP on this either. It is not just our data center experiencing this either, most of the other 6 data centers in my company have very similar issues.

In the past we always used to update the firmware to the latest available (I agree that 2.58 is the absolute minimum to address this issue, but there is no reason not to update to the latest available) and then monitor it. 7 times out of 10 just updating the firmware fixed the issue. When updating firmware was not enough, we would replace the battery and that fixed the issue 9 times out of 10. However, just this year we have had to start replacing the battery, the actual cache accelerator card (part number 413486-001 - SPS-BD,DDR,40Bit,128MB) and update the firmware or 7 times out of 10 the issue would come back.

We have done some extensive research on this issue. We understand that the battery only has a life of 3 years, so it is understandable that we may need to change the battery as our data center is now 5 years old. What is confounding us is that we can not just update firmware and replace the battery. 70% return failure rate if we don't also replace the cache accelerator card itself is not acceptable. But, that is what we have to do now to resolve these issues. That isn't as big a deal with the server in warranty, but with out of warranty servers the cost is something we have to take into account.

What that has done is made us look at cache acceleration itself, is it actually required on most of these servers. The conclusion to that is often times no. And I am more than willing to listen to advice or counter arguments on this. My feeling is that unless the server has sustained level of disk I/O (measured through perfmon Physical Disk %Disk_Time over several days) of 10% or more, we do not feel cache acceleration is of any benefit, and we recommend disabling the CIM trap alerts on the monitoring console for those servers and then either 1) disabling Logical Drive Array Acceleration through ACU or 2) Just remove the card and battery from the server. Not an ideal solution, but it does prevent a flood of trouble tickets.

So right now we do several days of analysis of each server reporting this problem, and make a determination based on disk utilization of whether we were going to replace the battery, card and update firmware or simply suppress the alert. Typically we feel SQL servers, MQ, Citrix and Terminal servers, some file servers are candidates for parts replacements. Web servers and other low disk I/O servers we just suppress the alerts and/or remove the card and battery.

I would like to see some response from HP on this, but every time I've brought it up previsouly we've just been given the standard pat answers about firmware, battery life etc. It seems to me something else is going on, these cards shouldn't go bad just because the battery dips below 75% charge.