Automating UCS Manager Configuration with Ansible

Cisco UCS Manager is the management plane service for Cisco UCS solutions. Using a policy-based management approach, server configurations are decoupled from the physical hardware.

Brett Johnson

October 19, 2018

4 Min Read
NetworkComputing logo in a gray background | NetworkComputing

Policy-based management improves the ability to manage infrastructure at scale, where making hardware more ethereal provides flexibility and improves handling of hardware faults.

Operating a UCS environment is not without challenges, there are a lot of settings to configure which increases the chance of misconfiguration and configuration bloat due to unused settings not being removed.

Cisco’s approach to policy-based management uses multiple layers of settings. To demonstrate the layers and inheritance of a setting, let’s look at assigning a vNIC to a server using a service profile.

  • VLAN created on the fabric

  • VLAN added to vNIC Template

  • vNIC Template added to Lan Connection Policy

  • LAN connection policy added to Service Template

  • Service Profile created from Service Template

  • Service Profile is assigned to a Server which can now use the vNIC

The steps above show the number of inheritance levels for adding a VLAN to a vNIC. With updating templates at the vNIC and Service Template levels, a change within the chain affects all the following policies.

(Image: Gorodenkoff/Shutterstock)

Management complexity continues to grow as more policies and servers are added. This growth usually triggers an increase in the environments dynamics and frequency of changes, which can make accurate change tracking a challenge.

The highlighted management challenges are some of the key value propositions for Automation, or specifically in this case, Infrastructure as Code. Which is why Cisco has been developing Ansible modules for managing UCS.

Before getting started with writing a playbook take a step back and make sure that you have validated design and As-Built documentation. Reviewing and understand these documents will help you understand the current state and design logic, which further improves the logic within the playbook and reduces repeated settings.

From this point, there is an assumed level of knowledge with Python, Git, and Ansible terminology.

Ansible modules for UCS are included with the default install of UCS, but additional modules are available from GitHub at https://github.com/ciscoUCS/ucsm-ansible. Modules within the repository are in a preview state and will eventually make their way to the main Ansible project.

Ansible modules provide a framework, the logic and consumption of the modules is dependent on your environment. As a rule of thumb, the structure of the playbook should be reflective of the environment, simplifying segregation of settings and clean up at EOL.

The UCS modules are dependent on two external Python libraries; UCSMSDK and ucsm_apis. These need to be installed on the host running the Ansible tasks. As an alternative you can use the Docker image sdbrett/ucsm-ansible. The ucsm-ansible git repository contains detailed steps for getting up and running.

The module behavior design has a compromise between true idempotence and safe guards. Specifically, if a managed object has child objects and those child objects are not set within the playbook, they will not be changed.

An example of this behavior is vNIC templates and VLANs. If I specify a vNIC template in the playbook which already exists within UCS Manager and do not specify a configuration for VLANS already on the template, the unspecified VLANs will not be touched or removed from the template.

The UCS Platform Emulator is the best place to get started as it provides the required functionality without risk to systems which others are using. To add another safe guard, you may wish editing ‘ansible.cfg’ within the project root to specify a default inventory file which points on the UCSPE.

UCSPE does have some limitations and may not provide full validation of how settings might behave on the physical UCS Managers. It is important to keep this in mind when testing.

To summarize I want to describe how I have used this module within a production environment.

The playbook has three environments: Local (UCSPE), test, and production. These are represented by folders with an inventory file in the root of each environment. Environments have their own host and group variables. They include:

  • Host variables are variables specific to each UCS manager such as IP Pools, MAC Pools, Server Profiles, and Server Pool membership.

  • Group variables are those which apply across all UCS Manager within the environment such as DNS, NTP, VLANs, and vNICS.

  • Tasks and roles are the same for all environments, this validates the same logic across environments.

Configuration settings are distinguished between two scopes: Global and application. This approach aims to improve the association between setting and purpose. Additionally, when an application is removed all relevant settings are as well, reducing clutter and orphaned settings.

The introduction of Ansible to manage UCS with the above method as simplified management tasks and increased consistency.

 

 

About the Author

Brett Johnson

Senior Consultant, VMwareBrett works as a consultant focusing on helping clients adopt automating platforms and practices. A core component of these engagements is to help clients integrate new processes within their existing policies.

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like


More Insights