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.