Chapter 9. Automating Cloud Infrastructure with UCS Director

There are many reasons to decide to implement a private cloud for your enterprise. The main reason should be to better enable your users to consume and manage infrastructure resources (compute, storage, network, etc.) by providing them the capability to discover services, order services, and manage their own consumption with little to no manual interaction with the IT team. Before you can provide users with this capability, you need to develop the services that will be made available. To do this, you need a comprehensive understanding of how to deliver the infrastructure that will back these services. Policies describing the consumption of compute, network, and storage resources need to be developed. And, automation workflows to deploy the standard configurations need to be built and tested.

Cisco UCS Director provides a platform for infrastructure management and automation designed for IT infrastructure teams to work together to easily build policies for standard infrastructure offerings. The virtual data centers and workflows you will build in UCS Director provide the foundation for users to begin ordering and managing their own resources within the cloud.

1. How many groups will be assigned ownership of a virtual data center?

a. One group

b. One or more groups

c. No groups, because virtual data centers are assigned to users

d. All groups share the same virtual data center assignments

2. Within what construct within UCS Director will you configure the policies that determine how a new virtual machine will be deployed into a cloud?

a. Virtual private cloud (vPC)

b. Virtual pod (vPod)

c. Virtual data center (vDC)

d. Virtual tenant (vTenant)

3. Which policy determines how elements such as hostname, domain membership, DNS settings, and time zone are configured?

a. Service Delivery Policy

b. Computing Policy

c. Guest Customization Policy

d. System Policy

4. Which of the following can be configured within UCS Director as part of the integrated IP address management capabilities?

a. Static IP pools

b. VLAN pools

c. IP subnet pools

d. All of the above

e. None of the above

5. When creating a new service profile through UCS Director, which physical infrastructure policies and templates must be configured within UCS Director itself? (Choose three.)

a. vNIC template

b. UCS Network Policy

c. UCS Storage Policy

d. UCS Bios Policy

e. UCS Boot Policy

6. What does the Workflow Property “Mark as Compound Task” indicate?

a. That this workflow is made up of child workflows

b. That this workflow will be leveraged in other workflows

c. That this workflow leverages external libraries and features

d. That this workflow will target a specific virtual machine

7. How do you add a new task to a workflow?

a. Right-click in the Workflow Designer design area and choose New

b. Drag from the Available Tasks list

c. Double-click a task in the Available Tasks list

d. Any of the above

8. With what type of task can you ask an external user to provide an input value during workflow execution?

a. User Approval Task

b. Get Input Task

c. Custom Approval Task

d. Query User Task

9. Which tab(s) of a service request can an end user view? (Choose all that apply.)

a. Status

b. Log

c. Objects Created/Modified

d. Inputs/Outputs

10. True or False. In order to use the Rollback capability of UCS Director, you must first build a workflow that acts as an Undo for the action you wish to roll back.

a. True

b. False

What hypervisor host and data store to instantiate new VMs on

If and how to provide network access for new VMs

How many virtual network adapters a new bare-metal server should have

What VLAN and subnet to use when creating a new network segment

You will create policies, pools, and virtual data centers to provide UCS Director with the information needed to answer these and other questions during provisioning processes.

You will need to determine the right number and purpose for building vDCs for your enterprise, as there are many possible strategies for using the vDC construct in a cloud. For example, an enterprise may choose to implement a very small number of vDCs based on a very coarse segmentation, such as a Production vDC, Development vDC, and Test vDC. In this case all virtual machines, no matter the application, would be deployed together and subject to the same set of policies. This model has the advantage of being simpler to initially set up, but you may find that it makes reporting on application usage and implementing flexible deployment polices more challenging. At the other end of the spectrum, you would deploy a vDC per application and environment. In this case you may have three or more vDCs per application (e.g., Production, Development, and Test). This method has the benefit of providing very granular controls and visibility over the deployed resources, but will result in a much larger number of vDCs within the environment. Whichever method you initially deploy your cloud with, you can always adjust the model as your needs evolve.

Each vDC will be made up of several policies that determine how new virtual machines will be deployed, managed, and billed back to the users and groups. Figure 9-1 provides a graphical representation of a vDC and the most important policies you will need to create.

Configuration of the vDC and policies is done in the Edit vDC window, accessed via the administrator portal by choosing Policies > Virtual/Hypervisor Policies > Virtual Data Centers, as shown in Figure 9-2. Each of the policies is leveraged by UCS Director when provisioning new virtual machines to the underlying hypervisor platform being leveraged. Therefore, you’ll find that there are tabs for each of the supported cloud types. The differences between the VMware System Policy and the HyperV System Policy, as an example, are minor, and once you understand the overall usage of each policy type, it is fairly easy to leverage a different cloud type. In our discussions of the policies, we will be assuming VMware vCenter as the cloud type.

Figure 9-3 shows vDC properties where the different policies are applied. As indicated by the red asterisk, the System, Computing, Network, and Storage Policies are mandatory for vDC creation. Policies for Cost Model and User Action are optional. Table 9-2 provides a simple breakdown of each virtual data center policy and its purpose.

As you can see in Figure 9-4, UCS Director supports using variables within policies. Within UCS Director, variables are indicated and accessed through a ${Variable Name} syntax. For example, ${GROUP_NAME} would be replaced with the name of the group for which a resource is being provisioned, and ${USER_NAME} would represent the requesting user’s username. These variable references are often used when creating VM name and hostname templates as part of the System Policy. Table 9-3 lists and describes the available variables for use in creating hostnames and VM names.

Administrators can mix static characters with variables to create a template for name creation. For example, the VM Name Template setting shown in Figure 9-4 is u${SR_ID}. This will create a name in which the service request number will be preceded by a single lowercase “u” character. This type of name will ensure uniqueness for new virtual machines. Administrators can choose to allow end users to provide a prefix that would be inserted before the template configured in the policy.

The default behavior for UCS Director when deploying a new VM is to maintain the underlying image/template settings for CPU and RAM. You can opt to give your users the ability to resize a VM at provision time by clicking the Resizing Options button near the bottom and providing a comma-separated list of options. The Override Template configuration in the policy would be a universal administrative override for all new VMs being deployed with this policy.

Figure 9-6 shows the main page of the VMware Network Policy. This page lists the number of VM networks (or virtual network adapters) this policy will configure. Clicking the Add button or Edit button above the table opens the dialog box shown in Figure 9-7 where you configure the settings for an individual network adapter. Each network entry has one or more port groups listed. Any single vNIC can be assigned only a single port group at a point in time. When multiple options exist, you can allow end users to choose their desired port group if you wish; otherwise, UCS Director will select the first one available (typically due to available IP addresses). Click the Add or Edit button in the Port Groups table to open the Edit Entry dialog box, shown in Figure 9-8, where the port-group and IP assignment configuration is completed. Configuring IPv6 connectivity is an optional setting in the policy.

Be aware that when creating a new Storage Policy, all storage options (Local, NFS, and SAN) are selected by default. Be sure to specify which are appropriate for your cloud. A common mistake made by administrators is to leave Use Local Storage selected, in which case UCS Director will attempt to provision new VMs to local data stores.

If your environment has different tiers of data stores for uses like databases, swap, or general data, you can indicate this type of configuration need in the Additional Disk Policies configuration of the Storage Policy, as shown in Figure 9-10.

The End User Self-Service Policy is located at Policies > Virtual/Hypervisor Policies > Service Delivery > End User Self-Service Policy, and is the policy you will start with to offer end-user control of VMs. Shown in Figure 9-12, this policy provides you the options to enable which of the out-of-the-box actions supported by UCS Director the end user will have access to. There are greater than 30 possible actions you can enable covering basic power management, snapshot management, and VM resizing.

You will likely eventually find a need to enable end users to take some action on a VM that is not an out-of-the-box capability for UCS Director, or perhaps you may simply want to change or extend the behavior of an out-of-the-box task. In this case, you can build a workflow with a VM context for the new action and leverage the User Action Policy to give users access to the new capability. One common example is extending the Add VM Disk action to include mounting and formatting the disk in the guest operating system.

The User Action Policy is configured via the Policies > Orchestration menu four tabs down from Workflows. Figure 9-13 shows a sample policy with some example Actions that could be built.

Virtual data center categories can help solve the problem of differentiating policies within a vDC. In the “Standard Catalog” section in Chapter 10, “Building a Service Catalog and User Portal with UCS Director and Prime Service Catalog,” you learn that when creating a Standard Catalog, one parameter you configure is the category of the catalog. The category selected corresponds to one of the available categories of a vDC.

After creating a new vDC, you can select it in the Policies > Virtual/Hypervisor Policies > Virtual Data Centers menu and click Manage Categories from the action menu. Figure 9-14 shows a sample view of this interface, where you can see each of the categories listed with columns for each of the configured policies. Any policy setting configured here will override the default policy as configured on the vDC itself. In the figure you can see that the Network Policy has been adjusted to reflect web, app, and data port groups for the related categories.

Whatever method your organization is using, UCS Director supports a lite-IPAM capability that will enable it to automatically allocate and record the consumption of resources as they are provisioned to new virtual machines or during a workflow execution. You configure these pools and policies from Policies > Virtual/Hypervisor Policies > Network. Figure 9-15 shows the Static IP Pool Policy as well as the tabs for IP Subnet Pool Policy, VLAN Pool Policy, and VXLAN Pool Policy.

You add or edit a policy with an interface similar to Figure 9-16. A policy requires a name and optional description and one or more pools or ranges of IP addresses. If you configure more than one pool in a single policy, UCS Director will exhaust the first pool and then move to subsequent pools. Though a pool entry can include a VLAN ID, it is more for notation than an actionable piece of data. When an IP address is requested from a pool, a VLAN ID is not a consideration for determining an appropriate IP address.

Once a policy is created, you can double-click its name to bring up a table similar to the one shown in Figure 9-17, where each of the used IP addresses is noted along with details regarding which VM or service request has it reserved. The reservation can be cleared by rolling back the service request, or manually by the administrator.

You will only need a few pieces of information to create a new IP Subnet Pool Policy. In addition to the policy name and description, you’ll need to provide a network supernet address and mask, and indicate the number of subnets required. Finally, you indicate whether the gateway address should be the first or last available address in the subnet. This is helpful because the workflow task to generate a new subnet from a pool will provide several outputs to make using the new subnet easier, one of which is the gateway IP address. You can see an example of the interface in Figure 9-18.

You will find that UCS Director offers many methods of configuring infrastructure as you become more familiar, but for this book we will be discussing what is available for assisting with provisioning new UCS service profiles. Figure 9-20 shows the location of both UCS Manager and UCS Central Policies, along with Rack Server (standalone Cisco C-Series) and NetApp Policies.

The UCS Manager (or UCS Central) Network Policy simply indicates the number and type of virtual NICs (vNIC) to configure in a new template. Figure 9-21 shows a sample UCS Manager Network Policy. In the UCS Network Policy, you specify UCS Director vNIC templates for the vNIC1 and vNIC2 templates displayed in the figure. It is typical to link the UCS Director vNIC template to an underlying UCS Manager or Central template.

The UCS Manager Storage Policy does the same thing for virtual host bus adapters (vHBA) as the UCS Manager Network Policy does for vNICs. Figure 9-22 provides a sample.

Regarding UCS Manager and UCS Central policies, templates and profiles, UCS Director will allow the creation of policies using local (from UCS Manager) or global (from UCS Central) templates; however, you should avoid mixing them when you create a service profile or template in UCS Director. Either use only local or use only global objects underlying your policies.

Once you have created the necessary policies, you can create a new service profile or template within UCS Director that leverages them. Most often you will create a service profile or template as part of a workflow, but you can also create one on demand by navigating to Physical > Compute and locating your UCS Account in the tree menu on the left. On the Organizations tab, double-click the UCS Organization that your new service profile or template will be created within, and then switch to the Profile or Templates tab. Figure 9-23 shows UCS Director navigated to the Service Profile Templates page.

Click the Add button to open the Create Service Profile Template dialog box, shown in Figure 9-24, where you can create a new service profile template within your UCS environment. The Storage and Network Policies are used within this dialog box to create the desired connectivity options.

Within the dialog box to create the new service profile template is a Template Type field with options for Updating Template or Initial Template. This is an important characteristic of the service profile template to understand. New service profiles created from an Initial Template will match the template’s settings at the time of creation, but if the template were to be updated in the future, any service profiles already created would not be affected. With an Updating Template, changes to the template will also change all service profiles created and bound to the service profile template. There are circumstances where you may want to leverage both of these template types within your organization. For example, your critical production database servers may be created based on Initial Templates because any updates or changes to that server must be well planned and explicitly addressed per server. However, your virtualization host servers would be created based on Updating Templates to make sure that each host in your cluster has consistent settings when changes happen, such as new VLANs being added to vNICs.

Deploy one or more virtual machines

Deploy new bare-metal servers for running applications on a Windows or Linux OS (including full configuration of physical compute, storage, and network requirements)

Expand the cloud capacity of an existing virtualization solution, by adding either new compute hosts or shared storage

Add a new network segment to the data center across physical, virtual, and compute networking domains

Add new data drives to a virtual machine, including mounting and formatting

Perform snapshot maintenance and purging across all VMs in the cloud

Create or update a help desk ticket in an external ticketing system

Construct a standard three-tier application environment including network segmentation, security policy, and load-balancing rules

Locate the Orchestration capabilities of UCS Director under Policies > Orchestration. Figure 9-25 shows the menu location and the initial view of the Orchestration module. You will find there are several tabs and sections of the Orchestration engine. As you become more advanced, you will learn to leverage many of the capabilities available within this interface; however, for now we will focus on the first tab, Workflows, where you build and edit workflows.

The Workflow Context field has two possible options, Any or Selected VM. Most general-purpose workflows will have a context of Any, but if you are building a workflow that is specifically intended to operate on a single VM, you can use Selected VM as the context. One advantage of setting up your workflow this way is that you will immediately have access to several inputs for tasks for details about the VM, such as its name and IP address. Table 9-4 provides a list of the additional variables available when working in a VM context. Second, this is the type of workflow you will want to use if you are building something intended to become part of a User Action Policy, as discussed earlier in this chapter.

Another important property to be familiar with is the ability to save the workflow as a compound task. This means that once the new workflow is created, it will show up in the Task Library (discussed in the next section, “Workflow Designer”) as a reusable task. This allows for you to build reusable automation structures and use them within other workflows, providing for modular development. Then when you update the underlying compound workflow, all other workflows leveraging it will immediately benefit from the changes.

On the second page of the Edit Workflow window, Edit User Inputs, you indicate the number and types of user inputs that will be gathered, as shown in Figure 9-27. These user inputs are a collection of variables that can be leveraged during workflow execution. Some of these variables will come from the end users when they either directly execute a workflow or order an Advanced Catalog backed by your workflow. Others can be administratively defined by the user building the workflow. Common user inputs include names or descriptions for servers or networks, IP address details, username and passwords for systems, detail selections such as the operating system or application tier needed for a new server, and so on. The workflow shown in Figure 9-27 will add a new network segment to the data center. The end user provides the VLAN name to use for the new network, but other inputs you might expect, such as VLAN ID or IP subnet, will be dynamically determined from configured pools as described earlier in the chapter.

One important aspect of user inputs, and of all inputs and outputs in workflows, is that UCS Director has a strongly typed model for variables. Each input will be assigned one of many types, and when you later go to use that input within a workflow task, the type of the user input must match the type that the task is expecting. The one exception to this rule is the Generic Text Input (gen_text_input) option. In most cases, any workflow task input will accept a Generic Text Input; however, it is recommended to use this sparingly. Leveraging a type of IP address or VLAN ID for an input has the added benefit that UCS Director will make sure the value provided by the user fits the type of input expected. This means that a user would not be able to enter a value of 555.555.555.555 for an IP address. Figure 9-28 shows a sample of some of the input types available within UCS Director.

The final page of the Edit Workflow window is Edit User Outputs. Workflow outputs are used in compound tasks to pass information up to the parent workflow. Though all task outputs from the child task can be made available, often it is a subset of these outputs that will be of interest in the parent workflow. By mapping the relevant values to workflow outputs, it is much simpler to build complex workflows.

To begin, we need to create a new workflow using the procedure discussed in the previous “Workflow Properties” section. Figure 9-30 shows the Add Workflow Details page filled in for our new workflow, and Figure 9-31 shows the Add User Inputs page configured to prompt the user for a VLAN name.

Next, open the Workflow Designer to begin creating our new workflow. Two pieces of information are required to add a VLAN to a switch: the name and ID. The user will provide the name, but we need to generate the ID within the workflow. UCS Director provides tasks to generate available resources from pools and policies, and as shown in Figure 9-32, we leverage a task called Generate VLAN from pool. After dragging this task into the Workflow Designer pallet, we provide a descriptive name and comment for our task and click Next to continue.

For this task we are not mapping any user inputs into the task, so skip the User Input Mapping page by clicking Next and move to the Task Inputs page. Here, as shown in Figure 9-33, we define the VLAN Pool Policy from which a new VLAN ID will be generated. Click Next and Submit on the Use Output Mapping page to save the task.

Figure 9-34 shows this first task complete and added to the design, automatically connected to Start and Completed blocks. Also shown on the left in the figure are the many possible tasks to create a new VLAN. Drag the Create VLAN task from the Cisco Network Tasks group onto the Workflow Designer for our next step.

The first step after dragging any new task into the Designer is to provide it a name and comment. For this task, we use “Create VLAN on Switch 1” for both the name and comment. After you click Next, Figure 9-35 shows the User Input Mapping page of the task, where we checked the Map to User Input check boxes for VLAN ID and VLAN Name. This allows us to select either a workflow input, such as VLAN Name, or a previous task output, such as Generate VLAN ID.OUTPUT_VLAN_ID, to use as the task inputs. The latter example shows the notation used to reference task outputs within UCS Director with a TASK_NAME.OUTPUT_NAME structure.

Not all of the task inputs are mapped to user inputs. After clicking Next, in Figure 9-36 we are identifying which switch we will be adding this VLAN to. Click Next and Submit on the Use Output Mapping page to save the task.

After finishing the configuration of the task inputs, we still need to place the new task into the workflow processing structure. Only the first task added to a workflow is automatically added, and in Figure 9-37 we are indicating that a successful completion of the first task will lead to our new task. Figure 9-38 shows the Workflow Designer with both tasks completely configured.

The final step in our walkthrough is shown in Figure 9-39, where we have validated our new workflow and executed it. As expected, we are prompted to provide a new VLAN name to continue.

Following are descriptions of the most common methods for extending Orchestration within UCS Director. Advanced discussion of these methods is beyond the scope of this book, and leveraging them is not part of the exam topics. Review the Cisco UCS Director Orchestration Guide and Programming Cookbooks available in the Programming Guides on Cisco.com for UCS Director.

Most Cloupia Scripts that you will write will be very simple functions. A common example would be manipulating a user input to meet some organizational standard. Figure 9-40 shows one such example where a user-provided name is appended with the service request number to ensure uniqueness and document the source of the new service profile.

You can create Custom Approval Tasks in the Orchestration interface several tabs to the right of the Workflow list. Each Custom Approval Task can be used in multiple workflows. Once created, the new task will show up in the Task Library along with all the others in a folder called Custom Approvals. Figure 9-41 shows an example Custom Approval Task where the approver will be asked to provide the vCPU and vRAM size information for a new VM.

Also, you can often find third-party integrations posted in the community. At the time of writing, integrations to the Infoblox IPAM solution and Nimble Storage Array are two examples shared on the community.

You can find the home page for Cisco Communities at http://communities.cisco.com. The sample UCS Director workflows are located by navigating to Data Center Community > Unified Computing System (UCS) > UCS Integrations > UCS Director Workflows. See Figure 9-43 for a glimpse into the community.

Service requests are available to be viewed and leveraged in both the administrator portal and the end-user portal, but the type of details available differ. An end user will only have visibility to the service requests initiated by themselves or other members of their group. Figure 9-44 shows the Services page of the end-user portal. The user sees only three requests that were initiated. Compare this to the page available in the administrator portal at Organizations > Service Requests shown in Figure 9-45. The administrator sees the three requests executed by clouduser as well as those executed by user cloudadmin. Also notice that administrators have access to the archived service requests. Though end users can archive one of their service requests, they can’t view or unarchive the archived requests.

When an end user opens a service request to see more information, he will see the service request Status information, as shown in Figure 9-46. The Status page provides details on the request such as its Request ID, current status, the group and user who own the request, as well as a listing of each step or task in the underlying workflow indicating which steps have completed successfully (displayed in green with a time stamp) and which are currently in progress (displayed in blue), and, if applicable, which steps may have had errors (displayed in red or orange). The Status page is very helpful for end users to understand their request, but lacks the details available to an administrator in other tabs.

When you open a request as an administrator, the most helpful details are available on the Log tab, shown in Figure 9-47. You will find a very detailed rundown of the entire workflow and each included task. All inputs and outputs for each task are listed within the log to make it very easy to follow the progress as values change and new objects are created. When you are building a new workflow and troubleshooting a behavior that isn’t working as you intended, your best tool for debugging and fixing the problem will be the Log view of your service requests. Within the Log view, different colors indicate different types of messages. Informational messages are shown in black, debug messages in gray, errors in red, and warnings in orange.

As an administrator, you will also have access to two other tabs providing details about the service request. First is the Objects Created and Modified tab, which shows some of the change-tracking capabilities of UCS Director. This view will list all VMs created, IP addresses reserved, VLANs created, LUNs created, and interfaces manipulated during the execution of the service request. An example of this view is shown in Figure 9-48. This information is useful as part of managing change, but even more important is how UCS Director can use this when rolling back or undoing a service request. The last tab is the Input/Output tab, where you will find a list of each task in the workflow and a breakdown of the different inputs and outputs involved. These details are also helpful during debugging workflows, or simply determining details such as what was the LUN ID of the new storage device that was created.

The most powerful of service request actions is the ability to roll back the request. A unique value provided with the automation engine of UCS Director is the integrated ability to roll back any automation workflow. UCS Director is model based, not script based. This means that a task from the library that takes an action, such as creating a new VLAN, can be undone without needing a separate task that would delete the VLAN. All tasks included in UCS Director include the capability to be rolled back, and it is best practice to consider rollback for any custom tasks or scripts you may create.

You won’t need to build separate workflows to reclaim or delete resources; that logic is included when you build the initial workflow. This capability combined with the details stored in Objects Created and Modified view (previously shown in Figure 9-48) enable UCS Director to immediately and consistently roll back service requests that are executed. When you choose to roll back a service request, a new Undo service request is created. If you were not the originator of the service request being rolled back, an approval request will be sent to the original requester. UCS Director administrators have the ability to bypass this approval step. A sample Undo service request is shown in Figure 9-50. Notice that the Undo Workflow is mostly a reverse mirror of the tasks taken in the initial workflow.

virtual data center (vDC)

System Policy

Computing Policy

Network Policy

Storage Policy

End User Self-Service Policy

User Action Policy

vDC categories

UCS Network Policy

UCS Storage Policy

workflow

compound workflow

Cloupia Script

service request

Rollback