Cisco UCS Director: Key Concepts Illustrated In Big Pictures
During the last few months, I worked a lot with Cisco UCS Director on daily basis. As I wrote before, UCS Director is a powerful platform for you to manage and orchestrate infrastructures from VMware, Hyper-V, KVM, to the public clouds like Amazon, Azure.
Just like any other management platform, it abstracts the underlying infrastructure and operations using its own concepts and workflows. By exploring its Flex GUI, one can gradually get familiar with these concepts. It takes time to master a product, and no exception for UCS Director. Understanding key concepts and their relationships can help speed up the process significantly.
Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.
In the following two sections, I will try to explain these concepts with two UML class diagrams. Unlike other UML class diagrams, my focus is not to show what attributes and methods in each class, but rather what key concepts/components are there, and how they are related to each other. The second part is very important for understanding a key concept because the role of a component is mostly defined how it’s associated with others. Without big pictures, it’s sometimes not easy to fully understand a key concept or component in short time.
There are a variety of infrastructures in a physical data center. To abstract these, Cloud is used as common concept for vSphere, Hyper-V, and etc. On top of a cloud, multiple VDCs (virtual data center) can be created. Unlike data center in vSphere, the VDC does not represent resources. Instead, it aggregates different aspects of policies, like compute, storage, network, system, cost model, and options for lease, self service etc. To find out what exactly in each policy, you can take a look at the GUI form where you can find all the details.
Associated with cloud is Catalog, which is essentially another name for virtual machine template. Because different cloud has its own virtual machine template format, the Catalog is cloud dependent. There could be multiple catalogs for one cloud.
Now, let’s take a look at the ownership of infrastructure. For that, the Group is used for group users in same organization. One Group can have zero to many VDCs, but any VDC must be owned by a Group.
For the Catalog, it’s much more flexible with many to many relationship. In other words, one group can have many Catalogs, and one catalog can belong to multiple Groups. This design allows re-use of Catalogs across multiple Groups.
The infrastructure and policies are not the end. They are means for the end that serves users with various operations like deploying new virtual machines. This is accomplished by ServiceRequest.
To submit a service request, a user selects a catalog that is pre-defined in a Group it belongs to, and then picks a VDC to operate on.
I just illustrated some key concepts in UCS Director on infrastructure, ownership, and service request. Hopefully you will find it’s easier to learn and use UCS Director after reading this.
Should you need consulting on UCS Director, please feel free to reach out to me.