Blog: HP

You know the situation… you’re keeping lots of plates spinning, multi-tasking, generally having a productive day when you look down and realize that you have 87 windows open on your task bar…the Windows Weeds. In my particular situation I was about to install a Proliant Support Pack (a conglomeration of driver updates approved by HP for a particular server model). The order of events was as follows: [more]

  • Downloaded compressed PSP from HP website to a network location
  • Extracted PSP to a child folder on the network
  • Was planning to copy the extracted files from the network to a Temp directory on the terminal server I was working on to perform a local installation of the PSP
  • Received a support call for a different problem and turned my attention to that task for a while
  • Came back to the PSP task. On the terminal server to be updated, I saw that there was already a d:\cnx\temp folder that had what appeared to be my extracted PSP files in it. With so many windows and directories opened I thought I had already copied the extracted files over to the local directory before I got called away to the other task.
  • Upon installing the extracted PSP files from the local directory, several core networking components crashed rendering the teamed NICs on this server useless. Re-running the PSP as a whole as well as just installing the updated networking driver portion of the PSP did not help at all.

As it turns out, the directory and PSP files that were in d:\cnx\temp were created by another engineer during maintenance procedures several months ago. It was just coincidence that the same type of installation files (just an earlier version) were in the exact network location I was going to create…what are the odds?!? When extracted, PSP files from different versions look the same, so there was nothing to tip me off that I was actually installing an old (and also corrupted) PSP.

Lessons learned:

  1. Keep a tidy task bar
  2. Clean up old temp files when finished with them
  3. Question your presuppositions if things aren’t adding up (i.e. “I KNOW these are my PSP files”)
  4. The unlikely is still a possibility (ie. same files –just diff versions- in the same directory). 

 

I visited with a HP storage engineer at a conference and he told me that the I/O module on a 1510i does NOT have the disk configuration information in it’s memory, but that the disk configuration is written on each disk drive. Therefore, if the I/O module fails, you can replace it with another module and the drive configuration (RAID, LUN’s, etc) will not be effected. He also suggested that if the I/O module fails, then you should move the cache memory from the old to the new I/O controller prior to bringing up the system so that the cache will be flushed to the disks.  I definitely recommend contacting HP support if your I/O controller goes out to verify this, but it made me feel better about the recoverability of our SAN.  If you have a spare I/O module on hand, recovering from an I/O module failure should be easy (in theory).


 

When working with HP Ultrium tape drives, it is sometimes a challenge to get them to run at speeds even close to the advertised maximum. Sometimes there are questions as to how to troubleshoot and how know you are getting the most out of the drive. Here are some tips: [more]

  • Most HP modern Ultrium drives have a hardware compression feature. In order to get even close to the advertised speed of the drive, you must ensure that the hardware compression is enabled on the drive. You can do this with the HP Library and Tape Tools utility. Without it, you will get approximately half of the advertised speed.
  • If you are using Backup Exec with an Ultrium drive, use the Symantec drivers that are provided on their website and make sure the drive you are using is on the HCL for the version of BE you are using. Only switch to the HP/OEM driver if you experience issues with media robotics when moving/inventorying media.
  • If you are using a tape library or autoloader, use the HP/OEM driver for the media changer/robotics and the Symantec driver for the drive. Symantec does not make drivers for the robotics.
  • Make sure that you are not using a SCSI channel that is connected to a RAID card. This can seriously impact performance of the drive. Best possible scenario is an Ultra320 SCSI card on a dedicated 64-bit PCI bus. Make sure the SCSI card drivers are up to date.
  • There are two types of autoloaders/libraries: LUN based and SCSI ID based. The difference is the way the device presents itself to the OS. LUN based devices share a SCSI ID and present different LUNs to the OS for the media changer and the drive. SCSI ID devices present two different SCSI IDs . Backup Exec works best on SCSI ID devices, but either will work. If the device you are working on allows you to choose LUN based or SCSI based, choose SCSI based.
  • Make sure the SCSI bus of your device chain is properly terminated. If using LVD SCSI, make sure you are using an LVD/SE terminator. Do not put more than two SCSI devices on the same SCSI chain as the tape device.
  • When testing performance, do a backup to local disk to test performance. If speeds are significantly faster, you should further troubleshoot the tape device because data CAN be backed up faster; the bottleneck is the tape device. If speeds are about the same, the bottleneck is the BE remote agent. Data cannot be presented to the device fast enough to keep it busy. In this scenario, troubleshoot the hosts for performance increases.
  • On the Backup Exec media server, disable the "Removable Storage" service. It has been known to cause issues with Backup Exec since version 8 and up.