SAN boot configuration - Targets

[TWILSON_DPS]

      I have configured the Boot Order to point to a specific target for vHBA0 (Primary) and vHBA1 (primary), assigned it to an "Updating" Service Profile template, then create the service profiles from the template. Works like a champ.

Now for the wrinkle, on the VNX this works as I have one set of targets for the boots, however now add a VPLEX where you distribute the targets to prevent a boot storm and now I need to make some changes.

I now create an  "initial" Service Profile Template, create 4 different Boot Policies, create service profiles from the template, then modify the service profile to add the Boot policy that matches the target of the storage.

The question:

Since I can define a target and a boot LUN on the wwpn. Can I define a boot policy that only has vHBAO and vBHA1 without targets (to enable them for boot) and will the server boot from the target defined on the wwpn's? This way I can just create one Boot Policy and add it to an updating service profile template for those servers on the VPLEX.      

   

[Walter Dey]

Boot policy: vhba without a target pwwn will result in a failure during association.

[TWILSON_DPS]

So do I use a dummy target and will the entry on the wwpn override the target on the boot policy?

If not, then what do we use the fields for on the wwpn? How do I exploit the Boot Target and LUN information on the wwpn?

[Walter Dey]

Just a clarification:

You have initators eg. vhba0 and vhba1 with pwwn which are used for    

     1) zoning

     2) lun masking / mapping, eg. initiator with pwwn a -> lun 0

Bootpolicy

     1) specifies the outgoing adaptor, e.g. vhab0

     2) specifies the pwwn of the storage subsystem controller

Typically, a storage subsystem has 2 controllers 1 and 2; and each has at least one (or more) interfaces in fabric A resp. B.

This applies to VNX, and if you use VPLEX, you just introduce an intermediate virtualization layer to hide the VNX; the concept is the same.

To avoid that in a boot storm, all the traffic would flow over the same hba and storage system port, you have to define multiple bootpolicies. I don't know if any other solution.

e.g. Boot policy nr. 1

hba0     -> primary controller 1 port 1 Fabric a

              -> secondary controller 2 port 1 Fabric a

hba1     -> primary controller 1 port 2 Fabric b

               -> secondary controller 2 port 2 Fabric b

e.g. Boot policy nr. 2

hba1     -> primary controller 1 port 2 Fabric b

               -> secondary controller 2 port 2 Fabric b

hba0     -> primary controller 1 port 1 Fabric a

              -> secondary controller 2 port 1 Fabric a

[TWILSON_DPS]

We are currently using multiple Boot Policies.

The question is what are the BOOT TARGET and BOOT LUN on the wwpn used for and how do we exploit them?

see image above. When you bring up the wwpn pool and look at the assigments, you can enter a BOOT Target and Boot Lun, but then what?

[Walter Dey]

You can just take a vhba (which took a pwwn out of the pool, figure above) and add to it boot target pwwn and lun. this would be just another procedure, not using a boot policy.

It is however not recommended; the advantage of a boot policy: it can be used for many initiator pwwn;