The integrated hardware would be elegant but incomplete without the Cisco UCS Manager software application. The UCS Manager lives in the UCS 6120XP Fabric Interconnect. As was mentioned previously, the UCS Manager is a device manager that provides discovery and monitoring features, as well as low-level configuration support for the hardware and logical components that make up the Cisco UCS.
During my tests, this meant that I was able to use the UCS Manager to provide low-level identifiers that are normally burned into hardware devices, such as a MAC on a network interface card, to mask physical changes in the network from operating systems and hypervisors running on that hardware.
For example, I was able to use VMotion to move a virtual machine from a VMware ESX Server running on one physical blade server to another, change out the physical blade for one with more RAM and a faster processor, and then migrate the blade back without the VMware ESX Server knowing that it was moving onto a physically different server. In other words, when physical actions are required-either to recover from hardware failure or to facilitate an upgrade-they can be performed in a nondisruptive manner to the operating system or hypervisor.
The UCS Manager interface is divided into five areas: administration, equipment, servers, LAN and SAN. Administration covers the operation of UCS Manager; equipment generally refers to the actual, physical UCS equipment; servers generally covers the logical entities that are created and used in UCS Manager; LAN refers to networking; and SAN refers to storage resources.
Administration of UCS Manager
The UCS Manager is built around a DME (Data Management Engine). Secure access to the UCS Manager is configured from the DME, and all changes to the UCS configuration are conducted as transactions to the DME.
I was able to set up roles that limited UCS Manager users to specific areas of the product interface-for example, access only to LAN functions and/or by organizational area-in my test case, eWEEK West. This compartmentalization based on function or organization makes the Cisco UCS suitable for use by organizations that provide multitenant services where operational separation is necessary.
While it was easy enough to back up the UCS Manager configuration, one of the Version 1.0 weaknesses I found is that the process must be kicked off manually. I would like to see an internal mechanism for scheduling configuration backups, and for these backups to be handled more gracefully. Currently, the backup overwrites the previous configuration.
Fortunately, everything that can be done in the UCS Manager GUI can also be done at the command line. I anticipate that most data center managers will use the CLI to automate tasks such as configuration backup and other routine maintenance tasks.
Resource Pools-the Building Blocks
Cisco uses resource pools to great advantage in UCS Manager.
The basic idea is to pre-position network and storage resources that hamper speedy hardware changes in the data center. In practice, this meant that I created pools of MAC addresses and WWPN (World Wide Port Names) from which policy-driven tools called Service Profiles automated the creation of logical server entities in the UCS management domain.
In an actual organization, these resource pools would be created in cooperation with network and storage engineers, so that when a Service Profile created a system that used one of these unique identifiers, it would be correctly configured to join the network or SAN resource.
During my tests, machines that I created using this method worked correctly. While it was just a matter of walking through a wizard to configure these tools, the underlying knowledge to correctly configure the pools means that only the most experienced IT staff should be involved in this part of UCS Manager setup.