Advanced Policy Resolution
Note |
Watch a video that demonstrates Advanced Policy Resolution.This video is in English. |
You can make a global service profile template reference any policy. Policies with the same name can exist in different levels of the organization structure. However, two policies with the same name cannot exist in the same level of the organization structure.
Service profiles always follow policies in their specific organization level first. Then, if that policy name is not contained at that level, the resolution looks upward, all the way to /root.
To demonstrate the advanced policy resolution, in the video that accompanies this topic we discuss replicating a SAN-BOOT policy in different organizations, with different policy settings. Then we use a single global service profile template to instantiate resulting global service profiles into those different suborganizations. This allows for the suborganization to acquire the desired boot policy at that level of the suborganization.
Assume that the SAN-BOOT policy resides in /root with generic target initiators. No blade server boots to SAN with this boot policy. Itβs acting as a placeholder. The global service profile template consumes it.
When you edit the service profile template, click Policies and choose the Boot policy, you can see the details of the newly created SAN-BOOT policy.
In the SAN-BOOT policy, create generic initiators for the possible boot paths of a UCS or Cisco UCS Central SAN-BOOT policy. It consists of two possible VHBAs, one primary and one secondary. Each VHBA also has its own primary and secondary target initiators.
Create an organizational structure that reflects how the blade servers boot to the SAN. For example, you could have half of the global service profiles booting from one storage array controller, and the other half booting from another. This divides the boot load on the storage array.
In the suborganization created for production, we have SA-controller-A and SA-controller-B. We created boot controller SAN-BOOT policies within each of the SA-controller suborganizations. The SAN-BOOT policies contain the valid, true target initiators for booting the storage array, except that they contain different initiators to separate the boot load when all of the global service profiles boot to the storage array.
The SAN-BOOT policy that lives in the SA-controller-A suborganization, contains the following boot target initiator values. The WWPNs end in 11, 22, 33, 44 for the 4 target initiators. The SAN-BOOT policy that lives in the SA-Controller-B suborganization contains the boot target initiator values. The WWPNs end in 55, 66, 77, 88 for the 4 target initiators.
From the single global service profile template (G-SP-SAN-BOOT), consuming the SAN-BOOT policy, use the feature Create Service Profile from Template and instantiate those global service profiles to their respective SA-controller suborganizations.
Once the policy is created and associated to a blade in a UCS domain, you can see the global service profile deployment, SAN-BOOT policy, and the initiators that are copied to the domain. The target initiators precisely match those configured in the SAN-BOOT policy in the SA-controller-A and B suborganizations.
When Cisco UCS Central deploys the policies correctly, there is no object name conflict. The two policies with identical names are contained in different suborganization structures.