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?
-
Translator
