Chassis/FEX Discovery Policy:
“Link Grouping Preference” is where you choose the number of links.
The best practice is to set Link Grouping Preference to “Port Channel”, to which provides greater availability in the event of link failure
Create Host Firmware Package:
In the initial configuration and setup (or for any UCSM firmware upgrade), a best practice is to create a corresponding Host Firmware Package with the corresponding UCSM version.
Pools:
There are three sets of pools used part of best practices:
- WWNN and WWPN pools: Provide unique IDs for Fibre Channel resources on a server (Fibre Channel nodes and ports)
- MAC address pools: Provide unique IDs for network interface ports
- UUID pools: Provide IDs similar to a serial number or service tag
Define and use Pools as a standard practice. Make sure that:
- UUID pools are referenced when you create Service Profiles
- MAC address pools are referenced when you create vNICs
- WWNN pools are referenced when you create Service Profiles
- WWPN pools are referenced when you create vHBAs
UUID – Server Tab
WWNN & WWPN – SAN Tab
MAC Address Pools – LAN Tab
ID Conventions:
To avoid duplicate WWN’s and MAC Addresses to the LAN or SAN, adopt an enumeration scheme for domains, such that domain ID’s are embedded in the high-order byte range of all pools, including MAC, WWNN, WWPN and UUID. Best practices are to embed either a simple domain ID, or a site/domain pair, along with a fabric side indicator to guarantee uniqueness and identify fabric source. For example, a MAC pool block would take the form 00:25:B5:23:BX:YY, where 00:25:B5 designates Cisco UCS, 23 indicates site 2, domain 3, and B indicates the B-side fabric.
Smaller environments could shorten the encoding to just domain and fabric side, as in 00:25:B5:1A:XX:YY. As organizations grow their UCS infrastructure, the use of UCS Central6 is strongly recommended for managing global ID pools.
=====POLICIES:
Boot Policy:
Much of the Cisco UCS core value around availability is predicated on SAN boot. Therefore, the use of SAN boot within a Boot policy is a most highly recommended best practice to improve service availability.
Suggested Practices: Boot Policy
- Have a CD-ROM as the first in the boot order, for emergencies and for booting in recovery mode.
- For SAN boot, define separate boot policies for each storage array that would be serving boot LUNs.
- For network boot, define the vNIC device as last in the boot order, following either SAN or local boot. This allows for a network boot and installation, only if the OS had not previously been installed.
Host Firmware Policy:
A best practice is to create one policy, based on the latest packages that correspond with the Cisco UCS Manager Infrastructure and server software release, and to reference that Host Firmware Package for all Service Profiles and templates created. This best practice will help ensure version consistency of a server’s lowest-level firmware, regardless of physical server failures that may cause re-association of Service Profiles on other blades.
Maintenance Policy:
The best practice is to not use the “default” policy, and instead to create and use Maintenance Policies for either “user-ack” or “timer automatic”, and to always have these as elements of the Service Profile or Service Profile Template definition.
Local Disk Policy:
A best practice is to specify no local storage for SAN boot environments, thereby precluding any problems at Service Profile association time, when local disks may present themselves the host OS during installation. For additional assurance, you can remove or unseat local disks from blades completely, especially blades used for OS installation.
Scrub Policy:
A best practice is to set the policy to scrub the local disk, especially for service providers, multi-tenant customers, and environments in which network installation to a local disk is used.
=====ISOLATION:
Cisco UCS addresses isolation requirements with the following objects:
- VLANs: These provide the foundation for network-based isolation. VLANs are created on the northbound LAN switch and then declared as available, since UCS does not create VLANs. Any declared VLANs can then be referenced when vNICs or vNIC templates are created.
- VSANs: These provide corresponding storage-based isolation capabilities. VSANs are created on the northbound SAN switch and then declared as available, since UCS does not create VSANs. Any declared VSAN can then be referenced when you create vHBAs or vHBA templates. Unlike with VLANs, vHBAs can associate with only a single VSAN.
- Pin groups: These provide isolation to specific northbound interfaces for both network and storage traffic. After pin groups are defined, they can be referenced as the target data path for any given vNIC or vHBA (or template) to help ensure that all traffic associated with a given vNIC or vHBA is isolated to the prescribed physical uplink ports.
=====TEMPLATES
Best Practices: Templates
In the GUI, use expert mode when creating Service Profile templates to achieve the optimal level of control and definition.
When creating templates, reference the subordinate Pools and Policies that have been previously defined.
Best Practice: vNIC and vHBA Templates
Create reusable vNIC and vHBA templates in which termination is either reflected in the name (e.g., “fc0-A”) or through well-accepted conventions (e.g., even interface to A side, and odd interface to B side). vNIC templates should be thought of as application-specific network profiles that include important security definitions, such as VLAN mappings
Best Practice: Network Availability
For network availability, either use hardware failover or use NIC teaming (or bonding), but do not use both concurrently.
Best Practice: Service-Profile Templates
Use a Service Profile template as a definition for a class or type or version of an application, service, or operating system.
SAN-Boot Troubleshooting
Resolving SAN-boot problems typically require diagnostic examination from all 3 participating elements: the SAN switch, the storage array, and the server. Following are some common helpful techniques:
- Disable Quiet Boot in the BIOS policy to view boot-time diagnostics.
- Verify that the upstream SAN switch is enabled and configured for NPIV.
- Remove or unseat any local disks from blades during the OS installation phase.
Best Practices: Preserve Identities
- Use the Preserve Identities feature when backing up individual domains for prescribed restoration (same site or domain or exact recovery site or domain).
- Do not use Preserve Identities when creating “gold UCSM domain configuration” templates.
Although identify pools can be maintained at local organizational levels, a best practice is be to have a single set of UUID, MAC address, WWNN and WWPN pools maintained exclusively at the root level and created in close coordination with the data center’s site-wide catalog.
The best practice for UCS monitoring is to use existing methods and frameworks that are already familiar and well understood, such as SCOM,9 OpenView, or BPPM.10
Lightweight Directory Access Protocol (LDAP)
Cisco UCS was designed to integrate seamlessly with existing authentication frameworks, such as LDAP and Active Directory. While the basic configuration has already been well documented, 11 here are some of best practices to keep in mind:
- Maintain matching role names between Active Directory and Cisco UCS.
- Use non-expiring passwords for the non-administrative bind user account (which periodically verifies group membership).
- Test or verify all LDAP providers as they are added.
Best Practice: Configuring Network Policy
Configure network policy based on isolation and security requirements and SLAs, not based on virtual or physical boundaries, and not based on physical connectivity constraints.
Policy-based automation is the ultimate best practice, where use of the UCSM GUI diminishes over time. Data center designers, operators, and administrators are encouraged to explore all paths that lead to greater automation. Here are some general guidelines:
- Leverage the integration work already done by Cisco and its Partner Ecosystem27 in the area of data center automation.
- Use “ConvertTo-UcsCmdlet” within the Cisco UCS PowerTool to capture configuration changes made through the UCSM GUI. Captured configuration changes are then displayed as corresponding PowerTool cmdlets.
- Focus on repetitive operational tasks. Use the XML API and SDKs to create parameterized scripts that can address and automate these common tasks.