Migration of Existing Deployments
When migrating existing local deployments to global deployments, best practices involve using global operational and service profile policies.
Policies in Cisco UCS Central
Cisco UCS Central provides global policies, which automatically enforce consistent global behavior across multiple domains.
-
Operational Policies
-
Workload Policies (or service profile consumed policies)
Operational Policies
Examples include features in the User Authentication settings, such as call home, user management, time zone, and DNS, NTP, backups, . In Cisco UCS Central, operational policies are applied in the context of a domain group (or subdomain group) and all of its associated domains.
Domain groups and operational policies typically govern site-specific aspects, such as those that would be affected by to physical location, geography, or other factors.
Take advantage of the domain group hierarchy to minimize the number of operational policies that you define. You can segment operational policies into those that are nondisruptive and those that are potentially disruptive.
Best practices dictate that administrators place as many nondisruptive policies as high up in the domain group hierarchy as possible. Similarly, place any potentially disruptive operational policies as low in the domain group hierarchy as possible.
When adopting service profile policies and global service profiles, qualify them based on requirements and constraints. For example, migrating local service profiles to global service profiles is straightforward if there is no need to maintain the same IDs. It is complicated if IDs must remain the same. Remember that you can view local service profiles from Cisco UCS Central, even if you cannot configure them.
Workload Policies
Workload policies are typically associated with service profile, such as boot policy, VNIC/VHBA templates, network QoS, and BIOS policy. In Cisco UCS Central, apply workload policies in an organization and all of its associated child organizations.
Organizations and workload policies typically govern service profiles and their associated templates, pools, and policies.
When adopting Cisco UCS Central for Cisco UCS domains, take note of current caveats and limitations. The most notable limitation: While local service profiles can refer to global pools and policies, you cannot convert local service profiles to global service profiles. Therefore, leave the existing service profile in a locally managed mode. The only way to re-create the settings is to reconstruct them in a global service profile.
Only adopt service profile policies and global service profiles if they contribute to management simplicity. If their adoption complicates management, avoid adopting them.
There is no dependency between operational policies and service profile policies. There is no requirement in Cisco UCS Central that forces you to adopt global service profile policies as well as global service profiles.
Cisco UCS Manager domains are not aware that they are contained in a domain group. Therefore, they do not share operational structure created within Cisco UCS Central. However, the organizational structure remains consistent and mutually shared between Cisco UCS Manager and Cisco UCS Central with a global scope.
Global Operational Policies
Cisco UCS Central provides global operational policies for one or more Cisco UCS domains. All participation in global policies is on an opt-in basis for Cisco UCS Manager domains. Cisco UCS Central does not take control of global policies unless such control is first delegated from the local Cisco UCS Manager domain administrator. A local Cisco UCS Manager domain administrator can revoke control by opting out of global management for any policy.
All administrative policies are under local domain control, by default, until the following occurs:
-
The local domain is registered to Cisco UCS Central.
-
The local domain is moved from ungrouped domains to a domain group in Cisco UCS Central.
-
The local domain administrator explicitly promotes a given policy from local to global resolution.
There is no dependency between the various policy promotion decisions. For example, you can globalize fault policies while still managing infrastructure and catalog firmware locally. In Cisco UCS Manager , all of the policies listed within the policy resolution control are independent.
Once a policy is promoted from local to global, you can only change the effective policy definition at the Cisco UCS Central level. This is by design, to enforce the desired consistency across domains. However, administrators can return to locally resolved policies at any time. If an administrator reverts to local management for a policy, that policy setting remains until the local administrator changes it. Then Cisco UCS Central no longer controls that policy.
Best Practices for Global Operational Policies
When contemplating a transition from local operational policy control to global control, maintain local policy resolution prior to a broader adoption of global policies. Adopt global policies on an individual policy basis, phased over time, as you gain familiarity. This is also true for firmware management.
Generally, system health and monitoring are all low-risk candidates for using in global policies. Defining SNMP, syslog, and call home policies as operational policies, as high up in the domain group hierarchy as possible, provides the simplest approach. All domains in the subordinate domain groups inherit these global policy definitions.
Cisco recommends taking advantage of policy consistency and centralized policy enforcement, whenever possible. Global consistency and policy enforcement are among the key architectural goals for Cisco UCS Central. By consolidating policy definition and configuration within Cisco UCS Central, you reduce administrative burdens for local Cisco UCS administrators. Keep in mind that any opportunity to define and manage policy at a higher and more central level promotes greater administrative scalability. Design your policies with an emphasis on simplicity, and centralize policy definitions whenever possible.
Available Global Operational Policies
The following table shows the correspondences between Cisco UCS Central and Cisco UCS Manager. The UCSM Navigation column shows where the references are inactive in the GUI once you configure the policies to resolve globally at Cisco UCS Central. It also shows where the references are inactive once the domain becomes part of a domain group.
Policy Type |
Cisco UCS Central Reference |
Cisco UCS Manager Navigation |
---|---|---|
Infrastructure & Catalog Firmware |
|
|
Time Zone Management |
|
|
Communication Services |
|
|
Global Fault Policy |
|
|
User Management |
|
|
DNS Management |
|
|
Backup and Export Policies |
|
|
Monitoring |
|
|
SEL Policy |
|
|
Power Allocation |
|
|
Power Policy |
|
|
Migrating
Note |
IDs must remain the same during migration. |
When migrating, you must:
-
Register existing UCS domains with Cisco UCS Central.
-
Create global pools, policies, VLANS, VSANS, vNIC templates, vHBA templates, LAN connectivity policies, SAN connectivity policies, global service profile templates, and global service profiles.
Make sure these global ID pools and policies match the exact format, settings and scheme, that are currently built locally in the UCS domains.
Make sure that all names are unique when creating global counterparts.
-
Use the same IDs as those of locally defined VSANs in Cisco UCS Manager, when creating global VSANs.
-
Use a “G-“ in front of the VSAN name.
- Make sure that the FCoE VLAN
ID, on the newly created global VSAN, exactly matches the FCoE VLAN ID
configured on the corresponding local VSAN.
Note
If you are creating a global VSAN with the same ID as a global VSAN already defined in a UCS domain, the FCoE ID must match exactly between the local VSAN and global VSAN. If not, the mismatch triggers a fault upon association of a global service profile.
-
Create global service profiles that allocate new UUID, MACs, WWNN, and WWPNs from their respective global ID pools.
-
Leverage simple Cisco UCS Central Powertools scripts to assign the original (correctly zoned) WWPNs and other IDs.
Migrating Brownfield Local Service Profiles to Global Service Profiles in Cisco UCS Central
Procedure
Step 1 |
Document pool IDs, policies, VLANs, VSANs, and templates of the local service profiles. |
Step 2 |
Re-create all IDs, policies, VLANs, VSANs, templates, and global service profiles in Cisco UCS Central. |
Step 3 |
Gracefully shut down the server with the local service profiles. |
Step 4 |
Disassociate the local service profile from the domain. |
Step 5 |
Delete the local service profiles. |
Step 6 |
Execute a Cisco UCS Central Powertools script to swap IDs for the specific global service profiles. |
Step 7 |
Verify that the IDs are correct for the specific server in the new global service profile. |
Step 8 |
Associate the global service profiles with the proper server. |
Step 9 |
Boot the server from the SAN LUN. |
Example of a Cisco UCS Central Powertools Script
Global service profile Name: G-Sp-TEST-2 (with global pool derived IDs)
Org: root
Global WWNN pool: G-USA-WWNN
Global UUID pool: G-USA-UUID
Global MAC pool: G-USA-MAC
New (from local service profile) UUID: dc81c8de-3b00-11e5-0000-000000000025
New (from local service profile) MAC for vnic0: 00:25:B5:00:00:25
New (from local service profile) MAC for vnic1: 00:25:B5:00:00:26
New (from local service profile) WWNN ID: 20:00:00:25:B5:00:00:25
New (from local service profile) WWpN for A Fabric: 20:00:00:25:B5:AA:00:25
New (from local service profile) WWPN for B Fabric: 20:00:00:25:B5:BB:00:25
Warning |
The script is not an officially supported product of Cisco. Use at your own risk. |
# Start-UcsCentralTransaction
Get-UcsCentralOrg -Name root | Add-UcsCentralserviceprofile -Name "G-Sp-TEST-2" -Modifypresent -IdentpoolName "G-USA-UUID" -Uuid "dc81c8de-3b00-11e5-0000-000000000025"
$mo = Get-UcsCentralserviceprofile -Name "G-Sp-TEST-2"
$mo_1 = $mo | Add-UcsCentralVnic -Modifypresent -Name "vnic0" -IdentpoolName "G-USA-MAC" -Addr "00:25:B5:00:00:25" -Order "1" -SwitchId "A"
$mo_2 = $mo | Add-UcsCentralVnic -Modifypresent -Name "vnic1" -IdentpoolName "G-USA-MAC" -Addr "00:25:B5:00:00:26" -Order "2" -SwitchId "B"
$mo_3 = $mo | Add-UcsCentralvhba -Modifypresent -AdaptorprofileName "global-default"-Addr "20:00:00:25:B5:AA:00:25" -AdminVcon "any" -MaxDataFieldSize "2048" -NwTemplName "" -Order "3" -pinToGroupName ""-QospolicyName "" -StatspolicyName "global-default" -SwitchId "A" -Name "vhba0"
$mo_4= $mo | Add-UcsCentralvhba -Modifypresent -AdaptorprofileName "global-default"-Addr "20:00:00:25:B5:BB:00:25" -AdminVcon "any" -MaxDataFieldSize "2048" -NwTemplName "" -Order "4" -pinToGroupName ""-QospolicyName "" -StatspolicyName "global-default" -SwitchId "B" -Name "vhba1"
$mo_5 = $mo | Add-UcsCentralVnicFcNode -Modifypresent -IdentpoolName "G-USA-WWNN" -Addr "20:00:00:25:B5:00:00:25"
Complete-UcsCentralTransaction