HP BL460c Boot from EVA 5000 Notes
Booting from SAN isn’t really anything special these days, but it’s still not the easiest thing in the world to do. Of course, having older storage hardware as your boot source can complicate things. So, here’s some notes and guidance developed in my environment to successfully get HP BL460c blades booting from a Generation 1 EVA 5000.
Disclaimer: Not every, exact, specific step you have to perform is listed here. It’s assumed that you’ve fully read the HP Booting from SAN document listed below. Furthermore, it’s assumed that you’re familiar with installing all of the HBA firmware, drivers and other software listed here. If you have existing knowledge of working with BL460c blades, Emulex LPe1105-HP HBAs and EVA 5000 storage systems, then you should be OK. Your mileage may very. Always keep your local HP support team engaged in changes in your environment.
Applicable documents:
- HP StorageWorks Booting Windows Server 2003 and Windows Serverx64 Edition systems from a storage area network application notes
- Rapid Deployment Pack: How To Perform a Boot From SAN Installation (not used in this procedure though, discussed below)
Equipment list:
- HP c7000 blade system chassis
- Brocade 4/24 4GB FC switches for c-Class blade system
- HP BL460c servers
- Emulex LPe1105-HP 4GB dual-port HBAs
- EVA 5000 with HSV110 controllers (Generation one)
- (Optional) Other FC switches upstream of c-Class chassis, commonly the case when you add the c-Class chassis into an existing EVA environment
- Fabric environment that includes two independent zones, A and B or 1 and 2, or something such similar
Software list:
- Windows Server 2003 R2 SP2 64-bit (could use 32-bit as well, but not Windows Server 2008 as it is not supported in Active/Passive controller mode with VCS 3.x code on the EVA 5000)
- Most current versions of firmware, drivers and management software for the LPe1105-HP HBA.
- Start here to obtain these software items
- Emulex HBAnyware management software (v 3.3a14 as of this post)
- HP branded firmware for the LPe1105-HP (v 2.72a2 as of this post)
- HP branded multi-boot firmware for the LPe1105-HP (v 6.00a5 as of this post)
- HP StorPort driver for LPe1105-HP (v 7-2.00a12 as of this post)
- MPIO Basic package from HP (v 1.2 as of this post)
- LP6DUTIL command line HBA maintenance utility (found in v 2.70a5 of firmware)
- Microsoft StorPort hotfix for HP systems (currently MS KB 946448 as far as I know)
So, the basic process goes like this:
- Create and enable a single zone that includes HBA port #1 and a single EVA controller port on Fabric A.
- Boot to a DOS prompt and use the the LP6DUTIL to update the multi-boot code on the LPe1105-HP HBAs. See below for more information on creating a bootable USB key.
- On the BL460c, enter the RBSU (ROM Based Setup Utility) and move HBAs up to #1 and #2 in boot order list. Disable the on board E200i adapter from PC device list.
- Reboot the BL460c and enter Emulex BIOS.
- Enable the BIOS on HBA port #1.
- Set HBA port #1 fabric topology to “Fabric Point to Point” by choosing option 4 from the menu and then selection option 4 again (see Image 1 and 2 below).
- Set HBA port #1 “Start Unit Command” to enabled, which is only needed on Generation 1 EVAs, by choosing Option 8 from the menu.
- Create the server object in Command View.
- Create a boot from SAN LUN in Command View.
- Assign the new LUN to the server in Command View.
- Configure boot options on HBA (1 port with 1 path), follow the directions in the HP document.
- Send the Boot from SAN specific RDP job to server (this is a modified standard job with one change to “Distribute Disk Image” part (see Image 3 below).
- Complete Windows configuration using standard guidelines.
- Install all HBA items in this order:
- HBAnyware
- HBA firmware via HBAnyware
- HP StorPort driver
- Reboot
- Microsoft StorPort hotfix
- Reboot
- MPIO Basic
- Reboot
- HBAnyware (yes, again, it gets uninstalled when you install the HP StorPort driver for whatever reason)
- Change first zone to include both EVA controller ports on Fabric A.
- Add the second HBA port to Boot from SAN LUN in EVA Command View.
- Add the second zone with both EVA controller ports and HBA port #2 in Fabric B.
- Reboot, enter Emulex BIOS again.
- Add second boot path to HBA port #1 (this would be other EVA controller in Fabric A).
- Enable the BIOS on HBA port #2 and add both boot paths to it.
- Make sure that both HBAs are setup in the same order (i.e. Primary to Controller B, Secondary to controller A…see what controller “owns” the BoS volume in Command View).
- Set HBA port #2 fabric topology to “Fabric Point to Point”.
- Set HBA port #2 “Start Unit Command” to enabled (only needed on Gen 1 EVA).
- Reboot the server.
- Complete monitoring application configuration.
- Complete application software installation and configuration.
Image 1: The Configure This Adapter’s Parameters menu
Image 2: Configuring the fabric topology type
Image 3: Changes made to Distribute Disk Image step in RDP installation job
Making this change to the RDP job was a suggestion of an HP support engineer who’s done quite a few Boot from SAN installations using RDP. Furthermore, he also stated there was no reason to perform the actions outlined in RDP KB article 127 if you’re following along step for step with the Boot from SAN document listed above.
You can create a bootable USB key by downloading and using the HP USB Disk Storage Format Tool (v2.1.8), which is pretty hard to find. Download it from a Chinese language HP page here. Just click the button to the right of the file name. You’ll also need the Windows 98 or Me media to make your boot disk.
Image 4: The HP USB Disk Storage Format Tool
Run the utility and be sure to select Create a DOS startup disk and you’ll have a formatted, bootable, USB key in no time. Place your LP6DUTIL file and your multi-boot code file (.PRG) on the USB key and you’re good to go on that.
Booting BL460c blades from an EVA 5000…did this help?
My “unofficial” Exchange Server 2007 CCR recommendations
Having had Cluster Continuous Replication in place now for about a year, I’ve derived some of my own best practice recommendations that might not be found within the official Microsoft documentation. Of course, it’s been a little while since I last checked that documentation, so this could be duplication of recommendations.
Although these recommendations are based on a very solid and stable production environment…anything bad or job search inducing that happens as a result of implementing them in your environment is not my responsibility.
So, here is the list in order of importance:
- Hub Transport servers should NOT be the location for your File Share Witness. I have found the BEST location in my opinion is in fact Domain Controllers in the same domain as the Exchange servers. This is obviously to be extended to cover other sites and domains as your organization may have them. Of course, you need to set up two FSW locations…one primary and one staged with folders and permissions in place in the event your primary FSW server dies.
- I do know for a fact that the original guidance Microsoft gave was to have the FSW on the Hub Transport servers. The logic was that a Hub Transport is a required role and the FSW needs to be on a server the Exchange administrator controls…a natural fit.
- The servers hosting the File Share Witness (or at least the one server that is the primary FSW host) should NOT be in the same data center as either of the two Mailbox server nodes in the CCR cluster. By using a three data center model (all local and in the same AD site) you provide complete and automatic fail over protection in the event of a data center failure.
- Hub Transport servers should NOT use SAN attached storage for their queue databases. Internal storage, in the Hub Transport server, is preferred. In the event that a CCR lossy failure occurs and Transport Dumpster redelivery is required, it would be best to not have that Transport Dumpster data on the SAN that is possibly out of action now due to a data center failure or SAN failure. If the queue database is located on internal storage in the Hub Transport server, you can simply move that Hub Transport server physically to an operating location (doesn’t even have to be in a data center), put it back on the network and now it can participate in Transport Dumpster redelivery. Cool.
- If possible, Hub Transport servers should NOT be placed on blade server hardware UNLESS you have the capability to place a blade server chassis in another location during a data center failure. This goes along with the previous recommendation about being able to bring that Hub Transport back online in an alternate location.
- At least one Domain Controller SHOULD be placed in each local data center you’ve got Exchange servers placed in. Of course, you should really have a minimum of two data centers to take advantage of CCR and you should always have at least two Domain Controllers per AD site…so one Domain Controller per data center makes perfect sense. If you’re going to use a Domain Controller (as noted previously) for your File Share Witness, this then offers you both AD and Exchange protection in one move.
Do you have anything to add?
Scheduled task for EVAPerf
Note: This information is based on a Gen 1 EVA…things are not necessarily the same with newer generations. Your mileage may vary.
If you’ve got HP EVAs as your storage platform, you’ve probably heard of EVAPerf at some time or another…
Sure, you can run EVAPerf interactively now and then to gather data on your EVAs, but what about running it as a scheduled task and keeping a month or three or more of daily output files? You can easily do that using a scheduled task on the server running Command View and the two scripts attached here. That way you actually have the data when you need it, usually when something goes wrong in your EVA environment.
The first script is a simple VBScript that deletes files older than XX days from directory YY. You specify both items and it just works. In fact, both items you need to put are in a single line in the script! The line below assumes that you’ve created a “Data” folder inside of your “EVA Performance Monitor” folder…why not. 30 days of data will be retained with this entry.
Call CleanDirectory(”C:\Program Files\Hewlett-Packard\EVA Performance Monitor\Data”, 30)
The second script is a batch file that calls the VBScript cleanup script and then actually runs the EVAPerf command. You’ll need to have done your homework first on setting friendly names and so forth on your EVAs, but your local HP storage support team should be able to assist with that if you don’t already have that done.
The second script does a few nice things for you. First of all, it automatically generates a new file name daily with date/time in the file name. Not as easy from the command line as in VBScript or Powershell, but it can be done. The script also clears the counters on the EVA and then runs the EVAPerf command. You’ll want to pay attention to make sure you edit the EVA WWN correctly, and you might even want to not clear counters. Again, up to you and local support.
Put both scripts, once you’ve edited them, in a folder named “Scripts” inside your “EVA Performance Monitor” folder and then create a scheduled task to run the batch file. The account you use to run the batch file needs to be a local admin on the server where the scripts (and Command View) are running as well as a storage administer. How you go about setting that up depends on whether or not you have your Command View server in your Active Directory domain (all new installations) or if its in a work group (older SA based installations).
Configure the scheduled task to run once daily, I’d suggest midnight local time. Then configure it to only run for 23 hours and 58 minutes. That makes sure you get a new run daily, with a new file.
Pay attention to the following lines which require editing in the batch file:
- set filename (put your EVA name in here)
- The line where counters are cleared (put your EVA name here)
- The line where the actual EVAPerf command is issued (put your EVA WWN here). Note that you may want to change what EVAPerf data you are collecting here.
Here’s a whitepaper on EVAPerf (happy reading): whitepaper
Get the scripts here…
EVAPerf.zip (1.5 KiB, 1,297 hits)
The perils of manually setting Fibre Channel port speeds
We’ve had a lingering issue for some months with one of our HP EVA SANs that we’ve traced to a pair of bad GBIC modules on an unused ISL between a blade chassis switch and the core switches. As part of the cleanup, we’ve been doing some other administrative “best practice” tasks in the fabric like getting all the switch firmware versions up to date from one version behind and manually setting all of the FC switch port speeds.
Although several senior engineers at HP, as well as ourselves, reviewed the plans for setting the port speeds all to 2 GB, something was missed…a pair of older HBAs that only supported 1 GB link speeds. The net result of setting the associated FC switch ports to 2 GB for these old Emulex LP950 HBAs was that the HBAs links to the switches became unavailable, which caused us some time spent trying to track down why these hosts were not seeing the fabric. This in itself wouldn’t normally be catastrophic except for the fact that those HBAs happened to be in the Storage Appliances running Command View, thus making the entire EVA infrastructure unmanageable. At 3 AM, that’s a bad thing.
Lesson learned: Always (triple) verify every host’s and switch’s capabilities before making any change to the overall FC fabric.
-
Translator
