VersaStack for Data Center with Cisco UCS Director

 

NOTE: Works with document’s Advanced Properties “First Published” property. Click File | Properties | Advanced Properties | Custom.

Last Updated: June 25, 2015

NOTE: Works with document’s Advanced Properties “Last Updated” property. Click File | Properties | Advanced Properties | Custom.

                                                                                                                                                   

 

 

About Cisco Validated Designs

 

The CVD program consists of systems and solutions designed, tested, and documented to facilitate faster, more reliable, and more predictable customer deployments. For more information visit

http://www.cisco.com/go/designzone.

ALL DESIGNS, SPECIFICATIONS, STATEMENTS, INFORMATION, AND RECOMMENDATIONS (COLLECTIVELY, "DESIGNS") IN THIS MANUAL ARE PRESENTED "AS IS," WITH ALL FAULTS.  CISCO AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.  IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THE DESIGNS, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

THE DESIGNS ARE SUBJECT TO CHANGE WITHOUT NOTICE.  USERS ARE SOLELY RESPONSIBLE FOR THEIR APPLICATION OF THE DESIGNS.  THE DESIGNS DO NOT CONSTITUTE THE TECHNICAL OR OTHER PROFESSIONAL ADVICE OF CISCO, ITS SUPPLIERS OR PARTNERS.  USERS SHOULD CONSULT THEIR OWN TECHNICAL ADVISORS BEFORE IMPLEMENTING THE DESIGNS.  RESULTS MAY VARY DEPENDING ON FACTORS NOT TESTED BY CISCO.

CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.

All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0809R)

© 2015 Cisco Systems, Inc. All rights reserved.

 

Table of Contents

Executive Summary. 6

Background. 6

Objective and Benefits. 7

Audience. 7

VersaStack Components. 7

Data Center Virtualization and Cloud Management 9

VMware vSphere ESXi and VMware vCenter Server 9

IBM Storwize V7000 Unified Storage. 10

Cloud Overview and Considerations. 11

Overview.. 11

Cloud Model (IaaS Features) 11

Essential Characteristics. 12

Elasticity. 12

Broad Network Access. 12

Measured Services. 13

On-Demand Self-Service Provisioning and Automation. 15

Platform Modularity. 18

Integration Points. 18

Solution Architecture and Design. 20

Architecture. 20

Tenant Design. 21

Cloud Management Environment Sizing. 23

Minimum System Requirements for a Single-Node Setup. 23

Up to 2,000 Virtual Machines. 23

Up to 5,000 Virtual Machines. 23

Deployment of Cloud Services. 26

Base Platform.. 26

High-Level Architecture. 26

Cisco UCS Director Installation and Configuration. 28

Initial Cisco UCS Director Setup. 29

Create a Converged Pod. 33

Create Local Users and Groups. 39

LDAP Integration. 42

Virtual Data Center (vDC) 44

IBM Storwize V7000 Storage Tiering. 45

IBM Storwize V7000 Storage Pool Setup. 47

Case Study - Infrastructure Management for In-House Software Development 58

Create System Policy. 65

Create Compute Policy. 67

Create Network Policy. 69

Create Storage Policy. 73

Create Cost Model Policy. 75

Create End User Self -Service Policy. 76

Clone Cisco UCS Director Policies. 78

Clone vDC. 80

Catalog Publishing. 82

Publishing Advanced Catalog. 86

Self-Service Portal 90

Design. 90

Implementation. 90

Workflow Triggers and Schedules. 93

Scheduled Workflow.. 97

Scenarios for triggers and Schedulers. 101

Setting Quotas. 102

Configure Budget Policy. 103

Dashboard. 104

Resource Monitoring. 105

UCS Director Bare-Metal Provisioning. 110

Cisco UCS Director-BMA Configuration. 110

Bare-Metal Image Upload. 112

Bare Metal Workflow Orchestration. 116

Summary. 128

Cloud Use Cases. 130

Account Services. 131

Open an account 131

Close an account 134

Terminate an account 136

Data Services. 136

Copy data into the cloud. 136

Erase data in the cloud. 137

Identity Management 138

User account provisioning. 138

User authentication. 138

Virtual machine lifecycle services. 139

Provision virtual machine. 139

Manage/Reconfigure an existing virtual machine. 140

Decommission a Virtual Machine. 140

Bill of Material 141

Software Revisions. 144

Conclusion. 145

References. 146

Appendix –A. 147

Orchestration - Task Library. 147

Appendix – B. 164

Bare-metal workflow for Linux: 164

Summary. 173

About the Author 176

Acknowledgements. 176

 

 

IT departments have embraced efficiencies such as hardware consolidation and agility brought about by virtualization and have looked to extend such efficiencies, in an agnostic manner, to platforms that are application ready.  A platform with efficient characteristics mentioned above, sets the foundation for the delivery of IT resources as a service – Cloud. Since all workloads cannot or will not be virtualized on a hypervisor, it is also desirable to extend essential Infrastructure-as-a-Service (IaaS) features of agility and measured self-services to non-virtual environments.  Capabilities that will allow for the easy introduction of such an application ready and platform independent approach will lead to a more cost-effective  and inclusive IT-as-a-Service (ITaaS) Cloud. Cloud computing requires automation and self-service mechanisms that allow users to consume infrastructure without manual intervention for provisioning or configuration of pooled resources.  Customized workflows for orchestration of catalog items offered through a self-service portal in a secure manner, gives businesses the opportunity to offer IT-as-a-service.

This Cisco Validated Design (CVD) leverages the capabilities of Cisco UCS Director (UCSD) to deploy a multi-tenant IaaS cloud environment on the VersaStack integrated platform. The deployment model described in this document is an enterprise private-cloud.

Background

IaaS is a cloud service model where Information Technology (IT) resources are delivered as a service rather than a product. Due to the nature of delivery and capabilities expected and provided, cloud computing offers a value proposition that is different from traditional enterprise IT environments.  Instances can be provisioned and terminated more quickly while sharing resources. The consumer can therefore expect to be billed only for resources used without incurring steep initial capital costs or hiring a dedicated IT department. For the provider, since the Cloud can reside in a remote location with a lower cost structure, a centralized model that can provide greater economies of scale is feasible.  However, a standard implementation of an IaaS platform requires certain key features to be available. These features include self-service provisioning, a means of measuring and billing for services used and security to ensure appropriate access to data.

Any shared platform, including cloud, opens up access to key resources such as infrastructure, users and applications. Ensuring the consistent and correct delivery of data on a shared platform comes with increased risk and complexity. System consolidation efforts have also accelerated the movement toward co-hosting on integrated platforms and the likelihood of compromise is increased in a highly shared environment. This situation presents a need for enhanced security and an opportunity to create a framework and platform that instills trust. Many enterprises and IT service providers are developing cloud service offerings for public and private consumption. Regardless of whether the focus is on public or private cloud services, these efforts share several common objectives:

·         Cost-effective use of  IT resources through co-hosting

·         Better service quality through resiliency and QoS features

·         Increased operational efficiency and agility through automation

Enabling enterprises to migrate environments to a cloud architecture requires the capability to provide customer confidentiality while delivering the management and flexibility benefits of shared resources. Both private and public cloud providers must secure all customer data, communication and application environments from unauthorized access.

Objective and Benefits

This document illustrates the design and deployment steps required for implementing an IaaS solution using Cisco UCS Director (UCSD) 5.3.1 on VersaStack platform consisting of Cisco UCS compute, Cisco Nexus Ethernet switches, MDS fiber-channel switches and IBM Storwize V7000 Unified storage array.  The hypervisor used for virtual machines is VMWare 5.5 U2.  The solution implemented as proposed provides for an enterprise Private Cloud (ePC) which can be hypervisor/OS agnostic and application ready. Standardized integration points between Cisco UCS Director and other third-party tools for trouble-ticketing, notification and event monitoring functions provide for a cohesive and complete IaaS solution.

Most Cisco UCS Director Features covered in this Cisco Validated Document are available in a platform-agnostic manner. Features such as self-service portal, monitoring, chargeback for billing, orchestration/automation and Role-Based Access Control (RBAC) lead to benefits such as agility, efficiency and cost savings while providing necessary levels of security. RBAC also can be leveraged to conform to organizational roles and responsibilities where different groups may manage compute, network and storage resources. In this scenario, groups of users are assigned privileges (read/write for tasks) and mapped to resources (compute, network or storage) with provisions to set resource limits and approvals, as necessary. This framework provides for a consistent method through a single tool as the management point for the entire infrastructure while maintaining established organizational boundaries.

Configuration details unique to this deployment are mentioned, while VersaStack platform deployment procedure is referenced to an earlier CVD consisting of similar components. This end-to-end enterprise Private Cloud (ePC) solution takes full advantage of unified infrastructure components and Cisco UCS Director Device support to provide provisioning, monitoring and management of the infrastructure by consumers.

It is beyond the scope of this document to consider performance related details pertaining to the platform. Also excluded are details about integrating Cisco UCS Director with third-party enterprise tools, such as those for trouble-ticketing and monitoring.

Audience

The reader of this document is expected to have the necessary training and background on Cisco UCS Director, along with knowledge about installing and configuring the VersaStack platform. References to previous works of relevance, both internal and external, are provided where applicable and it is recommended that the reader be familiar with these documents. Readers are also expected to be familiar with the infrastructure and database security policies of the customer installation. This document is intended for executives, partners, system architects and cloud administrators of IT environments who want to implement or use an IaaS platform with Cisco UCS Director.

VersaStack Components

This solution consists of a foundational platform of VersaStack and a management suite as shown in Figure 1.

Figure 1       VersaStack Components

This Cisco Cloud solution integrates the best of Cisco’s hardware and management suite with IBM Storwize V7000 unified storage and VMware products to accelerate implementation and adoption of cloud infrastructure. The architecture provides sufficient flexibility to allow for customer choice while ensuring compatibility and support for the entire stack. The solution is applicable to customers who wish to preserve their investment and to those who want to build out new infrastructures dedicated to a cloud. This solution takes advantage of the strong integration between Cisco and IBM products/technologies with Cisco UCS Director. The Cisco Nexus 9396 switch used in this configuration operates in standalone mode, with capabilities similar to other Cisco Nexus 9000 series switches. Also included is a pair of Cisco MDS fiber-channel switches. The MDS switches support storage cluster traffic and provide for scaling the architecture past the Point-of-Delivery (PoD) to eliminate stranded capacity. At the storage layer, the configuration has been tested with IBM Storwize V7000 unified storage system. Validated architecture used for this CVD is shown in Figure 2.

 

Figure 2       Validated Architecture

Data Center Virtualization and Cloud Management

Cisco UCS Director enables customized, self-service provisioning and lifecycle management of cloud services that comply with established business policies. Cisco UCS Director provides a secure portal where authorized administrators, developers, and business users can request new IT services and manage existing computer resources from predefined user-specific menus. It also enables administrators and architects to develop complex automation tasks within the workflow designer using pre-defined tasks from a library.

VMware vSphere ESXi and VMware vCenter Server

VMware vSphere ESXi is a virtualization platform for building cloud infrastructures. vSphere enables users to confidently run their business-critical applications to meet demanding service level agreements (SLAs). This solution gives the consumer operational insight into the virtual environment for improved availability, performance and capacity utilization.

IBM Storwize V7000 Unified Storage

IBM Storwize V7000 Unified is a virtualized, flash-optimized, enterprise-class storage system that provides the foundation for implementing an effective storage infrastructure with simplicity, and transforming the economics of data storage. Designed to complement virtual server environments, these modular storage systems deliver the flexibility and responsiveness required for changing business needs. It has support for Fiber-Channel (FC), iSCSI and NFS/CIFS protocols. IBM Storwize V7000 Unified can deploy the full range of Storwize software features, including:

·         IBM Real-time compression

·         IBM Easy Tier for automated storage tiering

·         External storage virtualization and data migration

·         IBM Active Cloud Engine for policy-based file tiering

·         Synchronous data replication with Metro Mirror

·         Asynchronous data replication with Global Mirror

·         FlashCopy for near-instant data backups

Cloud computing is a model for enabling convenient and on-demand access to a shared pool of configurable computing resources. The expectation is to be able to rapidly provision and release with minimal effort or interaction. The cloud model promotes availability and consists of characteristics deemed essential and categorized along service and deployment models.

Overview

In keeping with the National Institute of Standards and Technology (NIST) model (Figure 3), this solution with Cisco UCS Director will be shown to provide the capability to provision processing, storage, network and other fundamental computing resources where the consumer can deploy and run arbitrary software including operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications within allocated resources.  

Figure 3       National Institute of Standards and Technology (NIST) Model 

Cloud Model (IaaS Features)

With respect to the above NIST definition, this solution leverages the functionality of Cisco UCS Director for implementing an Infrastructure-as-a-service (IaaS) for a Private Cloud to be deployed with all essential characteristics detailed.

Essential Characteristics

Elasticity

This feature focuses on the ability of the platform to be able to support dynamic provisioning and decommissioning based on needs of the consumers (capacity-on-demand), in an efficient manner (faster time-to-market) and without any service interruption. Consumers can take advantage of the Cloud when they have a large fluctuation in their IT resource usage. For example, an organization may be required to double the number of web and application servers for the entire duration of a specific task. You would not want to pay the capital expense of having dormant (idle) servers on the floor most of the time and would want to release these server resources after the task is completed. The Cloud model enables you to grow and shrink these resources dynamically and allows the organization to pay on a usage basis. Elasticity requires seamless integration between the orchestration piece (UCSD) and the underlying integrated VersaStack to take full advantage of compute, network and storage resource scalability options.

Broad Network Access

Given the borderless nature of our networks and the number of devices used for access, this broad network access requirement translates to support for non-traditional end-points such as tablets and cell phones in a secure manner. Cisco UCS Director supports secure technologies such as TrustSec and security related devices, such as the ASA and VSG firewalls. Mobile and tablet access is provided by Android based Cloud Genie application, which interfaces with Cisco UCS Director.  Cloud Genie access is not within the purview of this CVD at this time.

In Cisco UCS Director, users get access privileges based on their roles (RBAC). The cloud administrator sets privileges based on available role templates and has the flexibility to create new roles or modify existing ones to suit the need. There is a separation between users within the group and across groups as well. Preservation of user-space confidentiality through encryption and other means at multiple levels through use of access controls, virtual storage controllers, VLAN segmentation, firewall rules, and intrusion protection should be employed where possible. Data protection through continuous encryption of data in flight and at rest is essential for integrity. Cisco TrustSec SGT and NetFlow support by Cisco UCS Director on most Cisco devices makes it easy to enable proper access control and visibility in a distributed manner for a scalable and secure platform.

In this deployment, the requirement is for flexibility in resourcing the tenant at the virtual level while preventing un-authorized data access. To this end, individual FC boot LUNs are created for each ESX host in the PoD. Data  on the SAN through Network File System (NFS) can be mapped either from a common share or individually. To make sure there is secure separation, user access controls at the hypervisor level (VMware) ensures users will not have unauthorized access to NFS space. Further access controls may be exercised through Trust Sec (SGT) and VMware vShield if desired. System access controls at the time of creating NFS exports on IBM Storwize allows for mapping to a host.

Measured Services

An IaaS platform consists of pooled resources serving multiple workloads and tenants. Given the services model followed, end-users are expected to pay only for resources used. End-users can belong to different departments within an enterprise or come from entirely different business entities. Whether internal to a company or across multiple companies, the platform, due to the shared nature, needs to incorporate a means to measure resource utilization for the purpose of billing. Cisco UCS Director has chargeback/show back capabilities based on cost models that can be set by the cloud administrator/provider. Data generated from chargeback can then be integrated with a payment gateway (First Data). Internal to Cisco UCS Director, there are also budget mechanisms tied to individual groups for resource management.

The Chargeback module in Cisco UCS Director gathers metering information at frequent intervals. This data can then be matched with cost-models to arrive at tenant costs and for reporting as well. Dashboard reports are also an offshoot of this module. The first step is to configure a budget policy to individual organizations.

Within Cisco UCS Director, cost models can be created for each tenant.  Costs for resources used in a vDC may be computed by the hour, month or year.  Each tenant is typically created in a separate vDC to facilitate easy separation for billing purposes.

The Standard  cost  model  is  a  basic and  linear  cost  model  based  on  resource consumption over the allotted  period.  CPU, Memory and Disk Resources used and idle over the period and their respective cost structure are used to estimate cost. The advanced cost model is more customized and allows for greater granularity in choices and billing using scripts. The scripts that are tailored to customer needs have to be generated, as they are not packaged with the system.

The setup below considers a straight-line Standard cost model to illustrate functionality and setup.

1.       Select Policies > Virtual/Hypervisor Policies > Service Delivery. Edit the default cost model.

Select a Standard Cost model type to illustrate a chargeback with an initial setup cost of $50.00 (say). The initial setup cost is assumed to include only costs pertaining to setting up the account. The VM cost needs to contain amortized fixed (CapEx) and variable costs (OpEx) for all under-lying system components that constitute a virtual instance – compute, network and storage. The capital expense component will be due to infrastructure – facilities and host platform. The variable operational expense portion could include such components as power and cooling, management and support costs. The approximate baseline used here to estimate chargeback is a unit active VM cost of $1.0 per hour and inactive VM cost of $0.10 per hour. The figures chosen are approximate and only used to illustrate method used and functionality on Cisco UCS Director. The reader is referred to external whitepapers if there is a need for more detailed chargeback figures. The assumption is that the VM contains compute, network and storage. It is also possible to define units and costs for individual components for greater accuracy.

2.       Integration with a payment gateway such as First Data is available for third-party billing.

An end-user/customer must setup a merchant account with First Data, which will then provide the necessary secure certificate and password for authorizing payments through their gateway. The provided First Data certificate and password needs to be input in above form to setup payments to the provider for IaaS resources used.

On-Demand Self-Service Provisioning and Automation

The customer needs to be able to provision and manage their environment on a shared platform with the least amount of intervention and delay from the provider. Providing this functionality requires the establishment of a self-service portal with necessary privileges. The portal should provide a catalog of items available for consumption to which the customer has access.  It should also include automated means of deploying instances to contribute to overall agility. Cisco UCS Director provides out-of-the-box self-service portal capability after setting up a set of policies and mapping entities (groups and users) to resources (on VersaStack).  Orchestration of workflows consisting of available and customizable tasks is enabled through a graphical workflow designer. Standard items are mapped to available workflows while advanced catalog items are mapped to newly created workflows for deployment.

Policies and cost model presented above, along with quota’s set for tenants, come together while designing a self-service portal defined below.

1.       Select Physical > Compute and then highlighting the VersaCloud and the Summary tab presents the following. A list of available metrics is shown above the graphs when the arrow next to the wheel to the right of the screen (below CloudSense tab) is selected. Below is a summary of compute related metrics.

2.       A snapshot of VM related metrics by selecting Virtual > Compute and then the PoD provides the following metrics. If any of these metrics/graphs need to be on the main dashboard, click the down arrow to the right of each graph or summary and select Add to Dashboard.

3.       Private Cloud Storage Metrics. Select Virtual > Storage and then select the VMware-Cloud and the summary tab.

 

4.       Virtual Network Metric snapshot. Select Virtual > Network and then select VMware-Cloud and click the summary tab.

Platform Modularity

The features mentioned in the previous section must be supported throughout the integrated stack for correct and consistent execution.  The VersaStack platform, with Cisco UCS compute, Nexus and MDS switches and IBM Storwize V7000 unified storage system, has the necessary flexibility at every layer to allow for elasticity within and external to the PoD. Compute can scale to 160 hosts/blades within a single Cisco UCS domain with storage on the Storwize system scaling to a maximum of 1056 disks of varying capacity and performance  distributed across four redundant block storage control enclosures.  The architecture includes common infrastructure components and services such as Active Directory, DNS, DHCP, vCenter, Nexus 1000v VSM (optional) and Cisco UCS Director to be hosted external to the IaaS PoD to provide a centralized and uniform management structure. This model also allows for the addition of more integrated PoD’s for growth, while preserving the cloud capabilities of Cisco UCS Director.

Integration Points

The current setup consists of several components and their respective native tools leading to a myriad of integration points as depicted in Figure 4. Cisco UCS Director has tight integration at the infrastructure layer with all underlying components within the VersaStack – UCS Manager, Nexus and IBM Storwize V7000 unified storage system.  The Cisco Nexus 1000v VSM communicates with both vCenter and Cisco UCS Director for distributed virtual switch functionality. Cisco UCS Director also has integration into vCenter and with its  bare-metal agent (BMA)  to extend functionality to non-virtual instances within the integrated stack.. External to this setup, Cisco UCS Director provides standard north-bound API’s for integration with third-party ITSM tools for event monitoring, trouble-ticketing and billing.

 

Figure 4       Integration Points

 

Architecture

The architecture for this solution uses two sets of hardware resources:

·         Common Infrastructure services on redundant and self-contained hardware

·         VersaStack for IaaS workloads under Cisco UCS Director Management

The common infrastructure services include Active Directory (A/D), Domain Name Services (DNS), Dynamic Host Configuration Protocol (DHCP), VMware vCenter, Cisco UCS Director and Cisco Nexus 1000v virtual supervisor module (VSM). These components are considered core infrastructure as they provide necessary data-center wide services where the IaaS Point-of-Delivery (PoD) resides. Since these services are integral to the deployment of IaaS, it is required to adhere to best practices in their design and implementation. This includes such features as high-availability, appropriate RAID setup and performance and scalability considerations given they may have to extend their services to multiple PoD’s.  Another consideration is to not introduce dependencies between management tools and the hosts/platforms they manage. For example, installing vCenter on ESX. At a customers’ site, depending on whether this is a new data center, there may not be a need to build this infrastructure piece. In our setup, given the limited scope of one VersaStack, this environment consists of a pair of Cisco UCS C-220 servers with internal disks. VMware has been used to clone the VM’s to serve as backups.

The IaaS VersaStack consists of Cisco UCS blade and rack servers. FC LUN’s from the IBM Storwize V7000 unified storage system were provisioned for booting these servers. The FC connections can go either directly to the fabric-interconnects (6248) from the servers or through redundant MDS FC switches, as in this case. The NFS space and the corresponding mount-point are visible to all hosts with hypervisor based user access control.  At the network layer, there are five VLAN’s – OOB-Mgmt (3171), NFS (3172), vMotion (3173), VM Traffic (3174) and IB-MGMT (3175). Cisco UCS Director appliance was setup as a single node with bare metal agent connected over a VLAN (3175). A highly-available and scalable multi-node Cisco UCS Director setup is available if there is a need to scale across multiple data centers.

 

 

                       

           

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

           

 

Tenant Design

User groups and accounts for the IaaS platform are created and managed from Cisco UCS Director.  For this exercise, three groups with two users in each group were created. The user groups were mapped to resources through the virtual data centers (vDC) construct to constitute a multi-tenant setup. Each tenant has an administrator user and another end-user role. Catalog items were created and shared by the cloud administrator (admin) through appropriate access to the self-service portal after setting up required policies. Each tenant group was assigned a budget and resources within the PoD and approximate cost for active and in-active instances was assigned. The understanding is that instances use compute, network and storage resources and as such, capture the overall requirements of the customer while also simplifying cost estimation from the providers’ perspective. In the event there is a need for more granular/accurate cost estimation, Cisco UCS Director has provisions for specifying cost at the compute, network and storage levels as well.

Cisco UCS Director uses Role-Based-Access-Control (RBAC) in assigning resource privileges to users. Many standard roles are pre-defined and there is the flexibility to add users with customized access levels. The group admin role has the privilege to create end-users within the group. Thus, the cloud admin needs to only create a group admin for each tenant.  This framework speaks to the delegation features available within Cisco UCS Director to facilitate assignment of roles and responsibilities by a local administrator. It also points to support of the existing organizational boundaries, for example, between compute, network and storage maintained through the same tool. This will make sure there is a single-pane-of-glass with consistent management practices that can add to efficiencies.

Cloud Management Environment Sizing

Minimum System Requirements for a Single-Node Setup

Reference

http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ucs-director/vsphere-install-guide/5-3/b_Installing_UCSDirector_on_vSphere_5_3.pdf

The minimum system requirements depend on how many VMs you plan to manage.

For information about minimum system requirements for a multi-node setup, see Minimum System Requirements for a Multi-Node Setup.

Up to 2,000 Virtual Machines

If you plan to manage up to 2,000 VMs, the Cisco UCS Director environment must meet at least the minimum system requirements in the following table.

Table 1           Minimum System Requirements for up to 2,000 VMs

Up to 5,000 Virtual Machines

If you plan to manage no more than 5,000 VMs, the Cisco UCS Director environment must meet at least the minimum system requirements and recommended configurations in the following tables.

Table 2           Minimum System Requirements for up to 5,000 VMs and Recommended Memory Configuration for Cisco UCS Director Services

Table 3           Minimum Database Configuration

This deployment will consider a single VersaStack and its management with Cisco UCS Director in a non-redundant fashion. This is because Cisco UCS Director is not in the data path and one instance can support multiple integrated stacks. To ensure best practices, the Cisco UCS Director instance is installed external to the managed PoD (VersaStack) on common infrastructure components consisting of a pair of Cisco UCS C-220 rack servers with local storage. For deployments that require greater scale and/or connectivity across Data Centers, a highly redundant setup of Cisco UCS Director is available (multi-node setup). The user is referred to the following Cisco UCS Director guide if there is a need for such a redundant and scalable setup:

http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ucs-director/vsphere-install-guide/5-3/b_Installing_UCSDirector_on_vSphere_5_3.pdf

The private cloud platform can reside in premises or in provider space (hosted). As such, this deployment will be an enterprise Private Cloud (ePC) with characteristics deemed essential in the model defined by the National Institute of Standards and Technology (NIST). Common areas of monitoring, management and on-boarding pertaining to the ePC will also be shown through Cisco UCS Director.

Cisco UCS Director uses a policy-based model for managing assigned resources. Policies are sets of rules that set forth the framework for how resources will be provisioned and accounted. Fox example, setting up a self-service portal requires establishing compute, network, storage and system policies and the application of a cost model to leverage chargeback for billing purposes. Setting up the required policies to provide necessary functionality for an IaaS platform is covered in the following sections.

Base Platform

This Document assumes that you have followed the procedure detailed in the CVD link below to build the base VersaStack platform:

http://www.cisco.com/c/dam/en/us/td/docs/unified_computing/ucs/UCS_CVDs/Versastack_n9k_vmw55.pdf

High-Level Architecture

Figure 5       Cisco UCS Director Infrastructure Abstraction- Single Pane Management

The above referenced CVD presents fiber-channel (FC) LUN’s and NFS mount-points  from the IBM Storwize V7000 unified storage system as datastores to the Cisco UCS compute within VersaStack. The connectivity is through a set of redundant MDS (FC) and Cisco Nexus 9396 (Ethernet) switches. One FC LUN is used to boot each ESXi host with an NFS share providing storage for workloads across the host. There are five VLAN’s, – OOB-Mgmt (3171), NFS (3172), vMotion (3173), VM Traffic (3174) and IB-MGMT (3175). Changes to the VersaStack infrastructure detailed above include use of VMware 5.5U2 in place of VMware 5.5U1 and UCS Director 5.3.1 for providing IaaS Cloud functionality.

Figure 6illustrates the high-level architecture for all devices in this solution. The focus is on using a validated converged infrastructure (VersaStack) to provide resources for the cloud with IaaS features provided by Cisco UCS Director.

Figure 6       High-Level Architecture

The following section outlines prerequisites to install and setup a working instance of Cisco UCS Director. The intent is to leverage the automation features of Cisco UCS Director for correct and consistent cloud deployment.

Cisco UCS Director Installation and Configuration

Download VMware virtual appliance (ovf) for Cisco UCS Director 5.3.1 and Cisco UCS Director Bare metal Agent 5.2 from the following link:

http://software.cisco.com/download/release.html?mdfid=286282000&flowid=&softwareid=285018084&os=null&release=5&relind=null&rellifecycle=null&reltype=null

You will need the bare metal agent software for building bare metal instances such as installing Linux or ESX on blade and rack servers. This step is a prerequisite to installing applications or databases on operating systems and hypervisor supported virtual-instances:

1.       Through the vSphere web client, connect to vCenter 5.5U2 installed external to the VersaStack on common infrastructure.

2.       Select File, and then Deploy OVF Template. Browse to the directory where the CUCSD_5_3_0_0_VMWARE_GA  ovf file is located and click    Next twice then Accept the terms and click Next.  Provide a name and click Next three times without changing default selections. Provide new root and shelladmin user passwords, IP subnet mask and default router for the appliance. Click Next.  You will see a confirmation screen with your selections next. After making sure your selections are correct, select the check box before Power on after deployment and click Finish.  The installation will take about 2 minutes. Proceed to install the bare-metal agent (CUCSD_BMA_5_2_0_0.ovf) in a similar manner.

Initial Cisco UCS Director Setup

To configure the Cisco UCS Director Virtual Machine on VMware, complete the following steps:

1.       Right-click the UCSD VM and click Edit Settings.     

2.       Select the Resources  tab.

3.       Select CPU, and change the Reservation to about 4000 MHz, then select Memory, and change Reservation to over 4000 MB and click OK

4.       Select the UCSD VM and right-click, Guest and click   Install/Upgrade VMware Tools.      

5.       When the Cisco UCS Director VM comes up, it will have the necessary interface plumbed up and available for connectivity.  Logging-in as user shelladmin takes one to the Cisco UCS Director shell Menu:

You may also access through the console or a browser (shown below):

6.       Connect to the URL for your UCSD system through the IP address you assigned.

7.       Login as default user admin with the password of admin and click  Login.

8.       Click OK to temporarily ignore the popup information message for login profile.

9.       Deploying the Initial System Configuration wizard takes the user through a series of steps. The first step is to upload a UCSD license file. Under License tab Browse to the license file and click   Upload.

10.   Click Next and under Locale, select Language and click Next. Selecting Next after each step in the Initial System Configuration wizard allows for a mapping to the DNS, Mail (SMTP) and NTP servers, in that order.

Create a Converged Pod

1.       The Device Discovery wizard is deployed next. It takes inputs such as an address range and account type for each device to be discovered.

 

2.       Each Account type has a credential policy associated with it. Clicking the “+” sign under Credential Policy results in a pop-up where the Account Type is selected by checking a box.

3.       When an Account Type is selected, another pop-up with policy name, user name and password is presented. The policy name is any unique name for the device type of interest. User name and password should be for an account that is setup on the device in question for logging-in to allow adding into the PoD.

4.       After above inputs are provided, the process discovers required devices and allows for grouping into a PoD. In this case, it is called the VersaCloud.

5.       Select Next and then click the “+” sign after Select Pod to bring-up the following screen. Enter VersaCloud as the Name and pick a Type of Generic from the drop-down.

6.       Click the Add button at bottom left (above screen) and Close the wizard.

7.       At the end of this stage, the converged infrastructure PoD – VersaCloud is built in Cisco UCS Director.

8.       After initial polling, data from all devices is gathered and displayed in a tabular manner.

 

Create Local Users and Groups

In Cisco UCS Director, you can use local accounts and/or LDAP accounts. Here we will go through necessary steps to create local groups and users within each group.

1.       From the Main Menu click Administration and select User and Groups.

2.       Under the User Groups tab, click     to add Group.

3.       In Name field name of the group  like (DevGroup), email address, First and  Last Name.

4.       Repeat Step (2 and3) to Create Two more group (Test and Prod).

5.       Select Login Users tab and click   to Create Group Admin logins for the three groups.

6.       Select User Role of Group Admin for a user group that was recently created. Provide login name and password for the account and click the Add button.

7.       Repeat Steps 4 and 5 to create Test and Prod Group Admin accounts.

8.       Click   to Create a Service-End User login for each of DevGroup, TestGroup and ProdGroup.

9.       Click Add.

LDAP Integration

LDAP can be integrated to synchronize the LDAP server groups and users with Cisco UCS Director. LDAP authentication enables synchronized users to authenticate with the LDAP server. LDAP synchronization for users and groups can be done either automatically or manually. In addition, LDAP synchronization is also available as a system task. When new organizational units (OU) are added in the LDAP directory, and a synchronization process is run, either manually or automatically, the recently added LDAP users and groups are displayed in Cisco UCS Director.

1.       From Main menu, click Administration Tab > Select User and Group

2.       Click Authentication Preferences Tab and Select Authentication Preferences LDAP First, fallback to local.

3.       Click Save.                         

4.       Click the LDAP Integration tab, and then click  

5.       Add LDAP Configuration detail, Account Name, Server Type, Server Name/IP, Domain Name and LDAP user name and password.

6.       Click Next.

7.       In LDAP Search Base click Search Base DN and make selections on the popup to get a list to use for the correct Base DN.

8.        Click Select, Submit, and then click OK

9.       To update records again, click  Request LDAP Sync, click Submit,

10.   Click OK

11.   Click Login Users tab and click Refresh you will see your LDAP users, if present.

Virtual Data Center (vDC)

A Virtual Data Center (vDC) is an environment that combines virtual resources, operational details and policies to manage specific group requirements. It is a construct that allows for the mapping of resources and policies to groups of users on shared infrastructure. Tenant requirements (SLA’s) are captured as policies, which are then mapped to allocated resources to deliver the desired QoS. An organization/department can manage multiple vDC’s and each vDC allows for a set of approvers (if necessary) and quotas to control and limit resource usage for the assigned user. Operational details such as budgeting of resources with or without limits can be included with chargeback to help with billing. A VM that is provisioned using a service request can be associated with a vDC. When you are creating a service request, you can choose the vDC on which this VM is provisioned. You can view a list of vDC that are available for a particular group and choose the required vDC when provisioning VMs. Following is a mapping between the constructs of Policies, vDCs, Users and Groups.

IBM Storwize V7000 Storage Tiering

In VersaStack, tiering can be controlled at multiple levels – at the storage pool, the mdisk or the vdisk level. This allows for complete flexibility when choosing the data to be managed by tiering. When tiering is turned on, the system will automatically allocate the most active data to the best performing set of disks in the pool. For a Storwize V7000 storage system, it is recommended to use disks of the same type/performance characteristic within each mdisk. The system will automatically determine the tier of the mdisk from its member drives. Each pool has an extent size, the default being 1GiB.  This is the unit of allocation from the pool to volumes. A volume is typically striped over all the MDisks in the pool with the extent size being the unit of striping. Given the mix of disks available, the tiers are set as follows with Gold focused on performance, Silver showing a mix of capacity and performance and Bronze geared only for capacity.

Just as storage pools containing multiple tiers of disks can benefit from EasyTier, storage pools with a single tier can also benefit from the system automatically balancing data across disks in that tier. A set of storage pools with the following characteristics is created to provide three levels of service to cater to SLA’s.

IBM Storwize V7000 Storage Pool Setup

1.       On the Storwize V7000 management GUI, navigate to the Internal Storage page (under Pools > Internal Storage).

2.       Click the Configure Storage button to bring up the Configure Internal Storage wizard.

3.       Select Use a different configuration, choose Flash drive class, and select the desired RAID type and number of drives to provision. Click Next.

4.       Select Create one or more new pools and enter the pool name of Gold. Click Finish, and wait for the task to complete, and then click Close.

5.       Click Configure Storage and select Select a different configuration. This time select Enterprise drive class, the desired RAID type and number of drives to provision, then click Next.

6.       Select Expand an existing pool then select the Gold pool and click Finish.

7.       Click Configure Storage and select a different configuration. Select Enterprise drive class, the desired RAID type and number of drives to provision, and then click Next.

8.       Select Create one or more new pools, enter Silver for the name and click Finish. Wait for the task to complete, and then click Close.

9.       Click Configure Storage and select Select a Different Configuration. Select Nearline drive class, the desired RAID type and number of drives to provision, and then click Next.

10.   Select Expand an existing pool then select the Silver pool and click Finish. Wait for the task to complete, and then click Close.

11.   Click Configure Storage and click Select a Different Configuration. Select Nearline drive class, the desired RAID type and number of drives to provision, and then click Next.

12.   Select Create one or more new pools enter a name of Bronze, and then click Finish. Wait for the task to complete, and click Close.

13.   In the MDisks by Pools view, you can see the three storage pools. These pools can now be used to allocate volumes.

14.   Clicking the (+) sign before each pool provides for an expanded view with details on mdisks in each pool.

The following section details a method of deploying a multi-tenant platform using Cisco UCS Director based on above storage QoS levels and the vDC construct. At the vDC level, relevant compute, network and storage constructs are assigned based on desired customer Service Level Agreements (SLA).

In this hypothetical structure, there are three vDC’s – Dev_vDC, Test_vDC and Prod_vDC. They represent the three functions required for developing software in-house - Development, Testing and Production.

Case Study - Infrastructure Management for In-House Software Development

The following case is presented to underscore the relevance of features in Cisco UCS Director to a real-world scenario. As with any hypothetical case, certain assumptions are made as detailed below.

The department in question builds a three-tiered proprietary Geospatial Information System (GIS) software in-house and provides this as a service for consumption by customers of the parent service provider. Thus, there is a need for a production environment as well. The software architecture allows for horizontal scaling where capacity at each of the web, application and database layers can be scaled by adding more number of instances from templates of corresponding catalog items. 

Developers of GIS software are expected to make frequent changes to their environment, including build and teardown of instances. They are also expected to focus on functional and interop features more so than performance. This criterion translates to the development group requiring loose infrastructure change-control procedures, dedicated platforms to prevent collateral damage and possibly Bronze tier for storage. Further, if developers are performing different functions, interop and resiliency components could be allocated more resources as there may be a need for it. In Cisco UCS Director, this translates to having no approvers to facilitate quick deployments with a group budget to prevent excessive cost due to high infrastructure use. Allowing for exceeding the budget to accommodate for interop and resiliency pieces while also limiting resource usage for the functional portion of development through resource limits can provide a necessary layer of control that leads to flexibility and greater alignment with business goals.

The Test group may require tighter change-control mechanisms to ensure a group of testers can work in lock step to perform end-to-end testing. This will prevent un-foreseen consequences due to missteps such as deletion of instances or results. Apart from testing functional and interop pieces, performance and resiliency will play a major part as well. This points to a need for faster and redundant infrastructure resources. Therefore, the Test group may require Silver tier storage with an approver within the group (say testadm) for workflows that delete or alter running instances. Group budgeting could still be instituted to prevent excessive infrastructure cost along with deletion of inactive instances, upon approval, to reclaim un-used resources after 90 days (for example).

The resource requirements for the production group is expected to be higher due to a greater focus on performance, high-availability and geographical redundancy for higher uptime (99.999%). Change control mechanism needs to be the strongest for this group to prevent changes from affecting critical services. From a Cisco UCS Director perspective, there needs to be multiple approvers for all catalog items, both within and external to the vDC. Group budgeting needs to be turned off to allow for agile/elastic scaling to meet demand upon approval of changes.

Within Cisco UCS Director, there are two methods of providing Catalog items – the ISO method and the template method. The ISO method allows for certain flexibilities, which can also lead to more mistakes.

The Cisco UCS Director template method leverages options presented by vCenter – Clone to template or Convert to template.  Corresponding vCenter template needs to be created and made available through Cisco UCS Director discovery and mapped to the catalog item. Converting to a template is available when the virtual instance is down while clone to a template is available when it is up. With the virtual instance up, select the “clone to template” under Template after right-clicking the VM. After the vCenter template is created, back in Cisco UCS Director, complete the following steps:

1.       Force iso gathering by going to Administration > System > System Tasks. Then, select VMware inventory collector and select Run Now.

2.       Policies > Virtual/Hypervisor Policies > Service Delivery.

3.       Select the Mark Datastores for ISO Inventory Collection tab and click   the datastore where the template was saved in vCenter. Select Edit and then pick the datastore for Select Data Stores option and Submit.

4.       In Guest OS ISO Image Mapping Policy, select the policy to Edit and click the (+) next to ISO. Provide a name and select the ISO Image to map. Click Submit twice.

Cloning an existing virtual instance to a template and using the template from Cisco UCS Director is the most restrictive method where settings and data are captured without a way to reverse engineer the VM. Converting to a template in vCenter provides a way to convert back the template to a VM if required such as in the event of applying patches. Deploying new instances based on templates of catalog items allows for consistent and standards based rollout with determinable outcome. Depending on the level of control needed in an environment, a combination of templates and clones through vCenter and Cisco UCS Director can be used.

The vDC’s (and groups) differ with respect to resource limits and approvers with potentially the same consistent set of templates available to deploy a three-tiered application on which development, test and production can take place.

5.       Click Administration Tab, from drop down Menu select Guided Setup.

6.       Select vDC Creation.

  

 

 

7.       View the Prerequisites and click Next.

8.       In the vDC General Information tab, Write vDC Name Dev_vDC.

9.       Provide access to resources in this vDC to previously created group. Select Group Name DevGroup.

10.   Select Cloud Name VMware.

11.   Enter required approvers and other details as below. 

12.   Click Next.

Create System Policy

1.       In Policies Tab, policies for System, Compute, Network and Storage are to be entered.  Click  next to each of these policies to add required policies. When next to System Policy is selected, a screen requiring following inputs is presented.

 

2.       Click Submit. Click Next to add the Compute Policy.

Create Compute Policy

1.       Back in the Policies tab,  click  next to create Compute Policy. Enter the details as follows.

2.       Click Submit and then OK.

3.       Optional. Uncheck Allow Resizing of VM and Check Override Template and enter required values for vCPU (2) and memory (4096) with CPU and memory shares as normal. This will allow for a mapping of the previously cloned template (through vCenter) to the service request to prevent the operator/self-service user from altering resources used by the instance.

Create Network Policy

1.       Back in the Policies tab,  click   next to create Network Policy.

2.       Click     to Add VM Networks, provide a NIC Alias and click    to select Port Groups.

3.       Click Select to Select Port Group.

4.       Click Port Group to Check it and click Select.

5.       Pick adapter type of E1000 and select the port group, and then click the pen-like icon to edit.

6.       Select IP Address Type DHCP and click Submit and then click OK.

7.       Click Submit and OK twice.

 

Create Storage Policy

1.       Back in Policies Tab, click   to create a Storage Policy. Policy Name Versa_Dev_Web_Pol.

2.       Selected Data Stores, click Select and make the selection as below.

3.       Click Select.

4.       Click Next.

5.       In Additional Disk Policies, click Submit.

6.       Click OK.

7.       Optional: Check Override Template and Manual Disk Size boxes and enter required values for disk space (40G).

Create Cost Model Policy

1.       In Policies Tab click  to create Cost Model Policy.

There is the provision to assign cost to both virtual and bare-metal instances. For virtual instances, cost may be assigned in a more granular manner by providing cost for compute, memory, network and storage components or by setting cost at the VM level. Bare-metal cost is calculated by considering individual component cost with a provision to also include fixed costs that may have been incurred due to other incidentals. In our case, we will provide cost estimates at the VM level as one time cost, active vm cost and vm cost for inactive instances.

2.       Click Add and then OK.

Create End User Self -Service Policy

The End User Self-Service Policy allows for setting of access to particular user operations within the vDC. There is the flexibility to set user access to be as restrictive or open as needed. User management and access includes such areas as VM Power Management, Resizing, Snapshots, VM deletes, Disk management, Network and Console Management. This policy controls actions and tasks that a user can perform on a vDC.

1.       Back in Policies Tab; click   to create End User Self-Service Policy. Policy Name versa_Dev_SelfServ.

2.       In the End User Policy dialog box, provide the Policy Name versa_Dev_SelfServ (say), Description (optional) and select required options as below.

3.       Click Submit and then click OK to get back to the vDC creation screen.

4.       Click Next and in the Summary tab, view all the steps and status and click OK.

5.       Click Next and then Close.

At this point, we have created a vDC (Dev_vDC) and all associated policies pertaining to the DevGroup. Next, we will clone policies with a view to use these policies in cloned virtual data-centers (vDC) for test and production groups. This will provide a framework for a multi-tenant platform with room to customize policies as required.

Clone Cisco UCS Director Policies

Cloning is a quick and easy method to replicate policies and /or vDC’s. Further, it ensures consistency and contributes to a reduction of human errors during setup.

1.       From main menu bar, click Policies > Virtual/Hypervisor Policies > Computing.

2.       Select Versa_Dev_Web_Pol, click Clone.

3.       Change Policy Name  as Versa_Test_Web_Pol.

4.       Description as required.

5.       Select Cloud Name as VMWare.

6.       Host Node/Cluster Scope Al.l

7.       Click  Resource Pool and  Check Resource Pool.

8.       Click  Select.

9.       Under Resizing Options, leave default values for Permitted Values for vCPUs and Memory.

10.   Deploy to Folder as Test.

11.   Click  Submit and click OK.

12.   From main menu bar,  click   Policies > Virtual/Hypervisor Policies > Storage.

13.   Click  VMware Storage Policy tab.

14.   Select Versa_Dev_Web_Pol, click Clone.

15.   Change Policy Name  as Versa_Test_Web_Pol.

16.   Description as required.

17.   Data Store/Datastore Clusters Scope as Include Selected Datastore.

18.   Selected Data Stores, click Select.

19.   Check versa_common_nfs as this is a datastore, which will be available through the SAN.

20.   Click Select and then Next.

21.   In Additional Disk Policies, click Submit.

22.   Click OK.

23.   From main menu bar,  click   Policies > Virtual/Hypervisor Policies > Network

24.   Click  VMware Network Policy tab.

25.   Select Versa_Dev_Web_Pol  and click Clone.

26.   Change Policy Name  as Versa_Test_Web_Pol. 

27.   Description as required.

28.   Click Submit.

29.   Click OK.

30.   From main menu bar,  click Policies > Virtual/Hypervisor Policies > Service Delivery.

31.   Click the VMware System Policy tab.

32.   Select VersaAdm, click Clone.

33.   Change Policy Name to Versa_User.

34.   Click Submit.

35.   Click OK.

Clone vDC

1.       Click  Policies > Virtual/Hypervisor Policies > Virtual Data Centers.

2.       Pick the recently created vDC (Dev_vDC) and click Clone button.

3.       Change the names as required and map to cloned policies tied to the vDC in question.

4.       Click Add and then click OK to add the new vDC.

5.       Perform the same set of vDC cloning steps to create another vDC called Prod_vDC.

Catalog Publishing

A Catalog includes the definition of service items and how they are delivered or provisioned. The self-service portal user interface (UI) in  Cisco UCS Director provides a non-administrative interface to the Cisco UCS Director Catalog service items. The end user will see a catalog for self-provisioning. A catalog item is created by the system administrator/Cloud admin, and defines parameters such as cloud name, and group name to which it is bound. To aid in managing catalogs, Cisco UCS Director allows you to group similar catalog items within a folder. While creating a catalog, you can either select a specific folder, which has been created earlier or create a new folder, if one does not exist. A folder is visible only when it contains a catalog item. Following is a depiction of how different functions within a software development company may be setup.

1.       Click Policies > Catalog and then click (+) Add.

2.       Select catalog type Standard and Submit. Provide a catalog name and other details as shown.

3.       Click Next and then Submit.

4.       Perform the same set of steps for other two catalog items of application and database instances for the Dev group.

The steps above create a catalog with three items listed below for the Dev user.

5.       Optional. Uncheck Provision New VM Using ISO Image checkbox as in step 4 above and select the image to map the catalog item to the corresponding vCenter template. This mapping will prevent the operator/self-service user from altering resources used by the instance.

Publishing Advanced Catalog

Advanced catalog type allows for mapping custom workflows to catalog items for end user deployment. Therefore, End users can use these catalog items during a service request to execute workflows. Following is the procedure to create an advanced catalog item.

1.       Click Policies > Catalogs and then Add. Pick Catalog Type of Advanced and click Submit.

2.       Enter the details as shown and click Next.

3.       Click Select and select the workflow of interest. In this case, select a shell workflow (Create VM from ISO) which creates a basic VM with option to mount an iso for install.

4.       Click Next, Submit and then OK.

5.       When above sequence of steps are completed, the devgroup (say devuser1) will have access to an advanced catalog item mapped to the workflow “Create VM from ISO”.

Self-Service Portal

Design

The Cloud Administrator creates tenant groups and users within the group as a prerequisite step. Following this step, the tenant group is associated with cloud resources and privileges assigned to users. Catalog items for self-service portal are then created and associated with tenant users. These steps are required prior to tenant user provisioning activities on the VersaStack Cloud platform with Cisco UCS Director.  Tenant users generate a service request when one of the catalog items is selected for deployment with optional approvals prior to execution. Tenant Administrators and Operations personnel will then consume/release cloud resources as needed with chargeback tied to resource utilization.

Figure 7       Tenant Catalog for Self-Service Portal

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Implementation

The self-service portal in Cisco UCS Director is available out of the box with catalog items created by the administrator as described in previous sections. When a catalog is created and made available to a group of users, the user has the capability to deploy tasks and workflows associated with the catalog item. This is done through service requests with provisions for approvals, if necessary and budget/resource constraints applied as set by the cloud administrator.

Create Service Request

1.       Go to the folder (Advanced) with the catalog item to be deployed and select the icon associated with the item.

2.       Click Next and then provide details as below.

3.       Click Next and Submit to generate a service request. Go to the services tab and select the recently deployed SR for details on progress and outcome.

4.       The instance corresponding to above workflow is created and available under the Virtual Resources area. Click the VMs tab to see a list of VM’s available with status.

5.       VM actions permitted for the VM for the user can be viewed by selecting any VM and right-clicking as follows.

Workflow Triggers and Schedules

Workflows can be deployed manually through service requests, through triggers or in a scheduled fashion. Triggers are used to execute workflows when specified conditions are met. As an example, a trigger is used below to create a new VM for added capacity (say) when application is approaching system limits.

1.       From main menu, click Policies > Orchestration. Click Trigger tab and then select  to Add Triggers.

2.       Click Next. Then, In Specify Conditions page, click    to add condition and click Submit.

3.       Back in the Specify Conditions screen, click Next

4.       In Specify Workflow page, Select Maximum Invocations as 1 (for now or as many as required)

5.       Select Workflow as Create VM from ISO (or something of relevance to the condition) for “when trigger State becomes Active”. Optionally, another workflow which will do the reverse (if available) for “When trigger State Becomes Clear” may be used to reclaim resources as when system demand goes down.

6.       Click Next and provide details.

7.       Click Submit and OK

The trigger will create a service request once the hosts reach the threshold limit. The same approach may be applied for scheduling a workflow.

Scheduled Workflow

1.       From main menu, click Policies > Orchestration. In Orchestration page, click   IBM Storwize folder and select workflow Create VM from ISO. Right click   the workflow and select schedule.

2.       In Schedule Workflow select Recurrence Type as Only Once, Start Time & User ID

3.       Click Submit and OK. Select Workflow Schedules tab and  verify the  workflow schedule

4.       Workflow will execute at given time as shown below.

Scenarios for triggers and Schedulers

Here are some suggestions on when triggers and schedulers may be used in conjunction with workflows to further automate infrastructure management.

1.       Trigger a notification (say an email) if available (un-associated) compute/storage capacity is less than or equal to 15% of total capacity (in PoD).

2.       Execute ESX bare-metal workflow as a pre-requisite step to adding capacity (Elasticity) based on (triggers -> available vCPU’s is less than or equal to 90% of capacity (say) [or] available memory is less than or equal to 90% of capacity of the PoD).

Assumption: there is un-associated capacity available in the PoD.

3.       Trigger a notification (say a text message) if available (un-associated) compute/storage capacity is less than or equal to 5% of total capacity (in PoD)

4.       Schedule snapshot/clone for production VM’s to ensure delivery of SLA. Trigger initial/full snapshot/clone at time of creation and schedule incremental once every week.

5.       Trigger an end-of-life notification to testadm after 60 days (say) of creating a test VM saying “VM at EOL. Will be deleted in 2 weeks. Please re-create/delete”. Delete a test VM after 90 days to reclaim resources.

 

Setting Quotas

Resource limits at the group level and in units pertaining to either physical or virtual instances can be set as shown below.

1.       Select Administration > Users and Groups > User Groups tab, then select the group of interest and click   the Edit Resource Limits button.

2.       Write the limit parameter

3.       Click Save

4.       Click OK

Configure Budget Policy

The Chargeback feature allows for accounting of resources. Thus,

 

 

Total cost incurred by a group is the sum of all resource costs within the group. Total cost for the group    may be             capped through a budget policy with provision to exceed (allow over budget), if necessary. Resource limits, for a non-service provider setup can be set at the parent organization level or below (group).            Irrespective of the level at which limits are set, sum of all resources used cannot exceed set limit at the next higher level.

1.       Select Administration > Users and Groups and then the group created (DevGroup) and click   Budget Policy. Enabling Budget Watch is required for monitoring resource usage for this group.  The other option allows for exceeding allocated budget, if necessary.

2.       Click Save

3.       Click OK

Dashboard         

The Dashboard provides a snapshot and trend of selected data in easy to read graphs. It forms the basis of monitoring and provides a summary of the state of the enterprise on a single-pane. This functionality can be enabled as follows:

1.       Select admin account on top right corner of the login screen and click   the Dashboard tab. Then, select Enable Dashboard option and Apply.

 

2.       Click  Dashboard Tab and turn on automatic refresh

3.       From main menu click  Virtual > Cloud VMWare

4.       Click  summary tab, Select VMs Active vs Inactive, click top right corner and select Add to Dashboard

5.       Select one by one All tabs you want to add in Dashboard

Following is an example screenshot of the metrics and reports selected.

Resource Monitoring

The admin user has necessary privileges to monitor the entire Cloud or converged stack for a global view. Selecting each of the components (VMWare, Compute, Network or Storage) below brings up comprehensive sets of metrics in tabbed displays for the component. Following is a sampling of metrics and views offered.

1.       From main menu select Converged and then click   VersaCloud for individual components and their status

2.       Select VMWare then click   Summary tab to get familiar with the tool.

3.       The Topology tab to the right presents various options to visualize physical and virtual instance mappings.

4.       Selecting the Compute category brings up the following set of tabs with polled information for each compute component and other relevant data.

5.       Similar operation (selecting IBM V7000 from Storage section) results in the following screen with tabs that present comprehensive data on the storage array.

Cisco UCS Director uses a Bare-Metal Agent (BMA) to automate the process of a Preboot Execution Environment (PXE) to install operating systems on bare metal servers and on hypervisor virtual machines. Bare metal Agent provides the following services that are required for a functional PXE install environment:

·         Dynamic Host Control Protocol (DHCP)

·         Hypertext Transfer Protocol (HTTP)

·         Trivial File Transfer Protocol (TFTP)

When this environment is operational and Bare metal Agent and Cisco UCS Director are correctly configured, It is possible to build PXE installation tasks into any Cisco UCS Director Infrastructure workflow. Following is the architecture used in this VersaStack setup where the PXE and MGMT traffic flows over VLAN 3175.

Cisco UCS Director-BMA Configuration

1.       Right click   the deployed BMA  and select Open Console

 

2.       Wait for the initial boot of the UCSD-BMA until a blue screen appears on the console.

3.       Back in UCSD, click   Administration > Guided Setup and select the Bare Metal Agent Setup wizard.

4.       Provide required inputs and click   Next.

5.       Click Next and then provide details on the DHCP network. Then, click Next and Close.

6.       At this point, go to Administration > Physical Accounts and select the Bare Metal Agents tab. Select the agent and check its status and interfaces using the buttons on top. Then, click   Set default BMA button to pick it as the default BMA.

7.       Select the BMA and click   Start Services

8.       The BMA should show all services enabled (DHCP, TFTP and HTTP) and be reachable with a status of Active.

Bare-Metal Image Upload

Cisco UCS Director has the capability to install operating systems and hypervisors on servers through customized workflows that automate the entire process. The preference on Cisco UCS is to provision servers to boot from the SAN, as this would allow for easy migration of workloads from one physical server to another, much like on virtual platforms. This functionality allows for two use-cases:

1.       Maintain resiliency and capacity of the integrated platform by pre-provisioning resources with OS/hypervisors to readily accept workloads in the event of hardware failures.

2.       Provide much needed elasticity for a cloud platform through quick and consistent provisioning of hardware resources based on demand.

Bare-metal provisioning is required to meet one of the four essential characteristics (Elasticity) of a shared platform (IaaS) as stipulated by the NIST.

Prior to using an image (say ESXi 5.5u2), it needs to be uploaded and made available for PXE boot. This is done as follows:

1.       Upload the binary to /opt/image directory on the BMA (say through sftp/pscp)

2.       Through a terminal session (such as Putty), login to the BMA server as root.

3.       Change directory:  cd  /opt/infra

4.       Setup your environment:  ./infraenv.sh

5.       Run the ISO extractor script:  ./isoExtractor.sh

 

Following is a screenshot of the proceedings:

At this stage, a RHEL71 directory will be created under /opt/cnsaroot/images.

6.       Make the iso available to the BMA through a common datastore. 

7.       Force inventory collection.                                                                                     

8.       Administration > System > System Tasks tab.

a.     Expand VMware VM Tasks, select VMware Inventory Collector and click Run Now at the top of the screen

b.    Expand Cisco UCS Tasks, select UCS Inventory Collector and click Run Now at the top of the screen.

9.       In UCSD, select Policies > Virtual/Hypervisor Policy > Service Delivery.  Tab to Mark Datastores for ISO Inv. Collection. Pick the common share and click Mark Datastores for ISO.

10.   Next, go to Guest OS ISO Image Mapping Policy tab, select the policy and add new iso.

 

Bare Metal Workflow Orchestration

Cisco UCS Director Orchestrator allows for automation of out-of-the-box tasks arranged as workflows using an intuitive graphical interface called the workflow designer. Please see Appendix-A for a list of relevant tasks supported in version 5.3.1.  Both virtual and physical tasks can be included to design custom workflows. Triggers can be setup to help initiate workflows based on specified conditions or workflows may be executed by hand. A typical workflow consists of the following elements:

·         Workflow Designer (GUI interface)

·         Predefined Tasks for the supported component

The simplest workflow consists of two connected tasks. A task represents a particular action or operation. The workflow determines the order in which your tasks are executed by Orchestrator. When constructing workflows, by dragging-and-dropping tasks, it is necessary to route the output of one task into the input of the next task. This connecting of multiple tasks is how a workflow is created.

1.       Click Policies > Orchestration and select the Workflows tab.

2.       Click (+) Add Workflow and provide a Workflow Name and folder to place the workflow.

3.       Click Next twice and then Submit to create a shell workflow.

4.       Expand the folder (IBM Storwize) where the workflow was created and select it to bring up the workflow designer.

5.       The design pane, to the right with Start and Completed conditions is where tasks from the library (Available Tasks) are dragged and dropped to create the workflow. The search pane under “Available Tasks” allows keywords to identify and locate required tasks as shown below.

6.       Dropping the task in the design pane opens the task for inputs..

7.       Once required inputs are provided, the task is ready to be linked.

8.       Drag and drop other required tasks as before and provide necessary inputs for each to create a complete workflow. Below, we have a newly created ESX bare-metal workflow (Deploy ESXi FC host on IBM Storwize V7000). The workflow uses LUN on fiber-channel (FC) residing on IBM Storwize V7000 system for booting a new server. Initial image is picked up from the BMA through PXE. List of tasks that constitute the workflow are:

a.     Create UCS Service Profile from Template

b.    Setup PXE Boot

c.     Create IBM Storwize Volume

d.    Create IBM Storwize Host

e.    Map IBM Storwize Volume to Host

f.      Configure SAN Zoning

g.    Power ON UCS Server

h.     Monitor PXE Boot

i.      Reset UCS Server and

j.      Register Host with vCenter

Following presents input around tasks constituting the bare-metal workflow built for VersaStack with the boot LUN on fiber-channel (FC) residing on IBM Storwize V7000.

 

9.       Create UCS Service Profile from Template.

10.   Where the service profile template in UCS Manager, Versa-VM-Host-Fabric-A is as shown below.

11.   Setup PXE Boot.

 

Variable                                          Input/Selection

_______________________________________________________________

Server MAC Address                      1303.OUTPUT_UCS_BLADE_MAC_ADDRESS

Server Hostname                            Host Name

_______________________________________________________________

12.   Create IBM Storwize Volume.

13.   Create IBM Storwize Host.

Variable                                          Input/Selection

__________________________________________________________________

Host Name                                     Host Name [or] IBM_STORWIZE_VOLUME_NAME

Fibre Channel Port Definitions         1303.SP_VHBA1_WWPN

__________________________________________________________________

14.   Map IBM Storwize volume to Host.

Variable                              Input/Selection

______________________________________________________________

Volume                               1329.IBM_STORWIZE_OUTPUT_VOLUME_IDENTITY

Host                                   840.IBM_STORWIZE_OUTPUT_HOST_IDENTITY

______________________________________________________________

15.   Generic Configure SAN Zoning.                                                                              

Variable                              Input/Selection

______________________________________________________________

Service Profile                    1303.SERVICE_PROFILE_IDENTITY

Select vHBA                       1303.SP_VHBA1

VLAN  ID                             VLAN  ID

VSAN  ID                             1303.SP_VSAN1

Select vHBA                       1303.SP_VHBA2

VSAN  ID                             1303.SP_VSAN2

_____________________________________________________________

16.   Power ON UCS Server.

Variable                              Input/Selection

________________________________________________________

Server                                1303.SERVER_IDENTITY

________________________________________________________

17.   Monitor PXE Boot.

Variable                              Input/Selection

________________________________________________________

PXE Request ID                   PXEBoot_134.OUTPUT_PXE_BOOT_ID

________________________________________________________

With a maximum wait time (hours) of 1 hr.

18.   Wait for Specified Duration. Set the value to 30 seconds.

19.   Reset UCS Server.

Variable                              Input/Selection

________________________________________________________

Server                                1303.SERVER_IDENTITY

________________________________________________________

20.   Register Host with vCenter.

Variable                              Input/Selection

________________________________________________________

PXEBoot Request ID            PXEBoot_134.OUTPUT_PXE_BOOT_ID

________________________________________________________

Summary

The entire workflow, consists of creating a service profile from template, associating the UCS service profile with an available blade, creating required FC LUN on IBM Storwize V7000 storage array, mapping it to a host and SAN zoning on Cisco MDS switches. The ESX5.5u2 PXE image from the Bare-Metal Agent (BMA) is also installed and the server rebooted twice. This entire process, with waits, took approximately 22 minutes from start to finish as shown in the following service request report.

Use cases are a well-known tool for expressing requirements at a high level. It provides a description of how groups of users and their resources may interact with one or more cloud computing systems to achieve specific goals.

The following section presents descriptions of some actors, their goals and an idea of success and failure conditions with a view to clarify the interaction while meeting a set of IaaS tasks defined in the NIST model.

Table 4           Actors

Account Services

Cisco UCS Director supports user roles. These user roles are system-defined and available by default.

Open an account

Actors:  unidentified-user (devuser1), cloud-subscriber (devadm), payment-broker, cloud-v Provider (admin).

Goals:  Cloud-provider opens a new account for an unidentified-user who then becomes cloud Subscriber.

Assumptions:  Service offered, cost and the payment mechanism is known and agreed upon and the user Request is valid.

Success Scenario:  The unidentified-user gets:

·         A unique name for the new account (devuser2)

·         Optional: information about the unidentified-user's financials and

·         When the unidentified-user wants the account opened.  (Now)

The cloud-provider verifies the unidentified-user's information. If the information is deemed valid and approved by cloud-provider, the unidentified-user becomes a cloud-subscriber and the cloud-provider returns authentication information that the cloud-subscriber can subsequently use to access the service.

Observation:  As admin, with system admin privileges, created a new user – devadm, with Group Admin privileges for DevGroup.  Logged back in as devadm and ascertained access as provisioned.  Devadm could see and do only what was allowed by the admin user. Devadm.

As Devadm, create a user with end-user privileges.

1.       Administration > Organization  and select the Users tab and click   (+) Add

2.       Select Add after entering above details to add new user devuser2.

3.       Login as devuser2 to confirm.

Close an account

 

Actors:  unidentified-user, cloud-subscriber, cloud-provider, payment-broker.

Goals:  Close an existing account belonging to a group for a cloud-subscriber.

Success Scenario: The cloud-subscriber requests closing an account. The cloud-provider:

·         performs the requested actions on the timetable requested;

·         Deletes the cloud-subscriber's payment-broker information from the cloud-provider's  Systems; and

·         Revokes the cloud-subscriber's authentication information.  Now the cloud-subscriber is Classified as an unidentified-user.

Observation:  proceeded to close (delete) devuser2 by devadmin. Tried logging in as devuser2 after deletion and was unsuccessful. Data categorized as ‘public’ was still available to the group Admin account (devadm) and hence recoverable if necessary.

Terminate an account

Actors:  unidentified-user, cloud-subscriber, cloud-provider.

Goals:  Cloud-provider terminates a cloud-subscriber's account.

Assumptions:  A cloud-provider determines that a cloud-subscriber's account should be terminated per the terms of the SLA.  The issue of multiple accounts for a cloud-subscriber is not considered part of the scope of this use      case, nor is the issue of retaining sufficient information to recognize an abusive cloud-subscriber trying to create a new account to continue the abuse.

Success Scenarios: (terminate, IaaS)  Possible reasons for termination may be that the cloud-subscriber has violated acceptable usage      guidelines (e.g., by storing illegal content, conducting cyber-attacks, or misusing software licenses), or that the cloud-subscriber is no longer paying for service.  The cloud-provider sends a notice to the cloud-subscriber explaining the termination event and any actions the cloud-subscriber may take to avoid it (e.g., paying overdue bills, deleting offending content) or to gracefully recover data.  Optionally, the cloud-provider may freeze the cloud-subscriber's account pending resolution of the issues prompting the termination. The requested actions, charges the cloud-subscriber according to the terms of the service, notifies the cloud-subscriber that the account has been terminated, deletes the cloud-subscriber's payment information from the cloud-provider's system, and revokes the cloud-subscriber's identity credentials.  At this point, the cloud-subscriber becomes an unidentified-user.

Test/Observation:   As ‘admin’, a password reset and not revealing the new password will lock the user out while retaining data and provide an opportunity for remediation. A permanent account delete has the effect of removing the user, associated data from the system, and convert the user into an unidentified user.

Data Services

Copy data into the cloud

Actors:  cloud-subscriber, cloud-provider, transport-agent.

Goals:  Cloud-subscriber initiates a copy of data objects from the cloud-subscriber's system to a cloud-     provider's system. Optionally, protect transferred objects from disclosure.

Assumptions: Assumes the Use Case "Open an Account" for cloud-subscriber on cloud-provider's system.  The cloud-subscriber has modified access to a named data object container on the cloud-provider's system.

Success Scenario: (cloud-subscriber-to-network copy, IaaS) The cloud-subscriber determines a local file for Copying to the cloud-provider's system.  The cloud-subscriber issues a command to the cloud-provider's system to copy the object to a container on the cloud-provider's system.  The command may perform both the object creation and the data transfer, or the data transfer may be performed with subsequent commands.  The command specifies the location of the local file, the data encoding of the local file, and the name of the new object within the container. 

Observation: There are two scenarios for this case. An ‘upload’ option for placing ova/zip/jar files for build purposes. A second method pertains to file/data transfer from a virtual instance. The upload option is strict with only certain types of files allowed for upload to ‘public’, ‘user’ or ‘group’ space’. Files uploaded to public space are available to all users in the group.

Erase data in the cloud

Actors:  unidentified-user, cloud-subscriber, cloud-provider.

Goals:  Erase a data object on behalf of a cloud-subscriber or unidentified-user.

Assumptions:  One or more data objects already exist in a cloud-provider's system.  A request to erase a data object includes the unique identifiers of the objects to delete. There is no redundant data storage by cloud-provider or redundant copies are deleted together.

Success: A cloud-subscriber sends a delete-objects request to the cloud-provider's system.  At the requested deletion time, the system disables all new attempts to access the object. 

Observation:  A user with the privilege to delete can remove images and data from VM’s created. The deleted Image becomes un-available for others in the group as well.

Identity Management

User account provisioning

Actors: cloud-subscriber, cloud-subscriber-administrator, cloud-provider

Goals: The cloud-subscriber requires to provision (create) user accounts for cloud-subscriber-users to access the cloud. Optimally, the cloud-subscriber requires the synchronization of enterprise system-wide user accounts from enterprise data center-based infrastructure to the cloud, as part of the necessary process to streamline and enforce identical enterprise security (i.e., authentication and access control policies) on cloud-subscriber-users accessing the cloud.

Assumption: The cloud-subscriber has well defined policies and capabilities for identity and access management for its enterprise IT applications and data objects. The cloud-subscriber has         enterprise infrastructure to support the export of cloud-subscriber-user account identity and credential data. The cloud-subscriber can establish trusted connections to these cloud services.

Success: This scenario illustrates how a cloud-subscriber can provision accounts on the Versacloud (IaaS).

Observation:  User account provisioning allows for local and domain user creation (User Group -> Domain Users).

User authentication

Actors: cloud-subscriber, cloud-subscriber-user, cloud-provider, identity-provider (optional)

Goals:  The cloud-subscriber-user should be able to authenticate through a central LDAP/Active Directory system.

 

Assumption: The cloud-subscriber-user's account has been already provisioned in the cloud, see use case Identity Management – User Account Provisioning.

Success:  This scenario illustrates how a cloud-subscriber-user can authenticate against a cloud-based Authentication service using the appropriate credentials to gain access to the cloud-based Applications/services.

Observation:  A combination of steps such as setting Authentication Preferences, LDAP Integration and a Domain group account provides necessary mechanism.

Virtual machine lifecycle services

Provision virtual machine

Actors: cloud-subscriber, cloud-provider

Goals: The cloud-subscriber should have the capability to create VM images that meet functions, performance and security requirements and launch them as VM instances to meet IT support needs.

Assumption: The cloud-subscriber has an account with an IaaS cloud service that enables creation of Virtual Machine (VM) images and launching of new VM instances. The cloud-provider shall offer the following capabilities for VM Image creation to the cloud-subscriber:

·         A set of pre-defined VM images that meets a range of requirements (O/S version,CPU Cores, memory, and security)

·         Tools to create a new VM image from scratch

 

 The cloud-provider shall support the following capabilities with respect to launching of a VM instance:

Secure administration of the cloud-subscriber's VM instance through the ability to configure certain ports (e.g., opening of port 3389 for window to enable remote desktop and 22 for Linux to enabling a SSH session.

Observation:  A generic instance was created from the self-service catalog. Provisioning Succeeded after sufficient funds were made available for the group and a budget ceiling was removed.

Manage/Reconfigure an existing virtual machine

Actors: cloud-subscriber, cloud-provider

Goals:  A cloud-subscriber stops, terminates, reboots, starts or otherwise manages the state of a virtual Instance

Assumptions:  A suitable VM image (operating system executables and configuration data) exists.  Possible Formats include OVF.

Success:    A cloud-subscriber identifies a VM image to run.  The cloud-provider provisions VM and Performs the loading and boot-up cycle for the selected image for the requesting cloud-Subscriber. Power-on, power-off and resizing of the VM.

Observation: The selected VM was powered-off from UCSD, memory, and CPU resized prior to power on. vCenter status was monitored and noted to reflect correct operation.

Decommission a Virtual Machine

Actors:  cloud-subscriber, cloud-provider

Goals: The cloud-subscriber should have the capability to decommission VM resources that are no Longer needed or do not meet functional, performance and security requirements and either reclaim such resources or relinquish to the provider.

Assumption: The cloud-subscriber has an account with an IaaS cloud service that enables Decommissioning/removal of Virtual Machine (VM) images.

Success:  The cloud-subscriber selects a specific Virtual Machine image supplied by the cloud-Provider (O/S, CPU cores, memory, and security) is decommissioned to reclaim/relinquish associated resources.

Observation:  A shutdown of the VM in question, while reducing active resource usage from a customer perspective does not revert back resources for reuse by the provider. A VM delete option is preferred and sought.

Below is a summary of main components used in building the VersaStack.

Please refer to the “Bill of Material” in the following link for a complete list:

http://www.cisco.com/c/dam/en/us/td/docs/unified_computing/ucs/UCS_CVDs/Versastack_n9k_vmw55.pdf

 

 

 

 

 

 

 

Following table details the software revisions for various components of the VersaStack architecture:

The IaaS platform discussed and deployed using UCS Director uses the common components of Cisco UCS compute and Nexus switching with IBM Storwize V7000 Unified storage system. It addresses business requirements such as agility and cost with security. These functional requirements promote uniqueness and innovation in the integrated computing stack, augmenting the original VersaStack architecture with support for essential IaaS services as stipulated by the NIST model. The result is a framework for the easy and efficient consumption of resources, both within and external to the integrated platform in the form of an application ready IaaS.  This setup is designed and built to appropriately address the diverse workloads, activities and business goals of any organization. This design and the validation discussed here describe the benefits of UCS Director on VersaStack integrated stack.

VersaStack for Data Center – Deployment of VMware 5.5 on Cisco UCS and IBM Storwize V7000 Unified storage:

http://www.cisco.com/c/dam/en/us/td/docs/unified_computing/ucs/UCS_CVDs/Versastack_n9k_vmw55.pdf

The NIST Definition of Cloud Computing, Peter Mell and Timothy Grance.

http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

 

Cloud Computing Use Cases, National Institute of Standards and Technology (NIST).

http://www.nist.gov/itl/cloud/use-cases.cfm

 

Cloud Computing Use Cases ver. 1.0, Cloud Standards Customer Council, 10/2011.

http://www.cloudstandardscustomercouncil.org/use-cases/CloudComputingUseCases.pdf

 

Cisco UCS Security:  Target of Evaluation (ToE), 11/2012.

https://www.commoncriteriaportal.org/files/epfiles/st_vid10403-st.pdf

 

 

Cisco UCS Director Literature:  http://www.cisco.com/en/US/products/ps13050

Cisco Validated Designs: http://www.cisco.com/go/designzone

 

Cisco UCS Director Installation and Upgrade Guide on VMware vSphere, release 5.3:

http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ucs-director/vsphere-install-guide/5-3/b_Installing_UCSDirector_on_vSphere_5_3.pdf

 

Cisco UCS Director Administration Guide, Release 5.3

http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ucs-director/administration-guide/5-3/b_Cisco_UCSD_Admin_Guide_53.pdf

 

 

Cisco Systems Inc., Whitepaper -

“Managing Real Cost of On-Demand Enterprise Cloud Services with Chargeback Models”

http://www.techdata.com/content/tdcloud/files/cisco/Cloud_Services_Chargeback_Models_White_Paper.pdf

 

Cisco UCS Director Bare Metal Agent Installation and Configuration Guide:

http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ucs-director/bma-install-config/5-3/b_ucsd_bma_install_config_guide_5_3.pdf

Orchestration - Task Library

Following is a list of tasks grouped by category for components in this CVD. It is not comprehensive and only provided to inform on out-of-box task support for relevant components. These tasks may be used to create workflows through the designer tool in Cisco UCS Director as shown before. For detailed information, go to Cisco UCS Director –Online Help.

Login to UCSD and select Administration > Orchestration and then, Task Library button on top to generate the document for the first time. This brings up the hyperlinked list of tasks supported by the version of UCSD. Selecting the individual task presents detailed input and output information on the task as follows:

List of Tasks pertaining to components covered in this CVD.

Custom - VMware Host Tasks

1. Create Datastore Cluster - 2015-02-04

Custom Tasks

1. Iterator Task
2. Add VMkernel Interfaces (custom)
3. Get_Interface_Index_For_Tier
4. Get Interface Info For Tier
5. NTP Server
6. DNS Server
7. Mail Setup
8. Configured Email
9. Select Locale

Containers

1. APIC_L4L7_ASAv_Network_VLAN_Info
2. Get_APICContainerL4L7Definition
3. Get APIC Container Tier Type
4. Get APIC Container LB VIP
5. Get APIC Container LB External IP

VDCProvisioning

1. Approvers and Contacts

User and Group Tasks

1. Add Group
2. Modify Group
3. Add User
4. Modify User
5. Modify User Password
6. Delete User
7. Delete Group
8. Add User Access Profile
9. Modify User Access Profile
10. Delete User Access Profile
11. Add Group Share Policy
12. Modify Group Share Policy
13. Delete Group Share Policy
14. Add Group To Group Share Policy
15. Delete Group From Group Share Policy
16. Assign Volume Group to Group
17. Remove Volume Group from User Group
18. Unassign Raid Group from Group
19. Assign Cluster Aggregate to User Group
20. Assign Cluster Volume to User Group
21. UnAssign Cluster Aggregate from User Group
22. UnAssign Cluster Volume from User Group
23. Assign Service Profile to Group
24. Unassign Service Profile from Group
25. Assign CUIC VLAN to Group
26. Unassign CUIC VLAN from Group
27. Resource Limits to Group
28. Add Resource Limits to Group

vDC Tasks

1. Create vDC
2. Update Storage Policy
3. Update Hyper V Network Policy
4. Undo Update Storage Policy
5. Delete vDC Policy
6. Delete vDC
7. Modify Computing Policy
8. Modify Network Policy
9. Add Network To Network Policy
10. Remove Network From Network Policy

Context Mapper Tasks

1. Context Mapper: Cloud
2. Context Mapper: LUN
3. Context Mapper: Initiator Group
4. Context Mapper: UCS Server
5. Context Mapper: UCS Service Profile

IBM Storwize Volume Tasks

1. Create IBM Storwize Volume
2. Delete IBM Storwize Volume
3. Rename IBM Storwize Volume
4. Shrink IBM Storwize Volume
5. Expand IBM Storwize Volume
6. Migrate IBM Storwize Volume
7. Map IBM Storwize Volume To Host
8. UnMap IBM Storwize Volume From All Hosts
9. UnMap IBM Storwize Volume From Single Host
10. Duplicate IBM Storwize Volume
11. Split IBM Storwize Volume
12. Delete IBM Storwize Mirrored Copy
13. Add IBM Storwize Mirrored Copy
14. Make IBM Storwize Primary Volume
15. Edit IBM Storwize Volume

IBM Storwize Pool Tasks

1. Create IBM Storwize Pool
2. Delete IBM Storwize Pool
3. Rename IBM Storwize Pool
4. Expand IBM Storwize Pool

 

IBM Storwize Host Tasks

1. Create IBM Storwize Host
2. Delete IBM Storwize Host
3. Rename IBM Storwize Host
4. Unmap All IBM Storwize Volumes
5. Import IBM Storwize Mappings
6. IBM Storwize Duplicate Mappings

IBM Storwize Mdisk Tasks

1. Create IBM Storwize Array MDisk
2. Rename IBM Storwize MDisk
3. Delete IBM Storwize Array MDisk
4. Set IBM Storwize Spare Goal
5. Unassign IBM Storwize MDisks from Pool
6. Select IBM Storwize MDisk Tier
7. Assign IBM Storwize MDisk to Pool
8. Swap IBM Storwize MDisk Drive

IBM Storwize FileSet Tasks

1. New IBM Storwize File Set
2. Delete IBM Storwize File Set

IBM Storwize Snapshot Tasks

1. Create IBM Storwize Snapshot
2. Delete IBM Storwize Snapshot

IBM Storwize Snapshot Rule Tasks

1. Create IBM Storwize Snapshot Rule
2. Delete IBM Storwize Snapshot Rule

IBM Storwize DataStore Tasks

1. IBM Storwize Block Volume Datastore
2. IBM Storwize Compressed Block Volume Datastore
3. IBM Storwize Thin Provision Volume Datastore
4. IBM Storwize iSCSI Boot Target
5. IBM Storwize Add NFS Datastore

IBM Storwize FileShare Tasks

1. Delete IBM Storwize File Share
2. Create IBM Storwize File Share
3. Active OR Deactive IBM Storage File Share

IBM Storwize FileSystems Tasks

1. Create IBM Storwize File System
2. Delete IBM Storwize File System
3. Mount IBM Storwize File System
4. Unmount IBM Storwize File System
5. Replicate IBM Storwize File System

IBM Storwize FC Consistency Group Tasks

1. Create IBM Storwize Consistency Group
2. Rename IBM Storwize Consistency Group
3. Delete IBM Storwize Consistency Group
4. Start IBM Storwize Consistency Group
5. Stop IBM Storwize Consistency Group

IBM Storwize RemoteCopy Tasks

1. Create IBM Storwize Remote Copy Relationship
2. Delete IBM Storwize Remote Copy
3. Start IBM Storwize Remote Copy Relationship
4. Stop IBM Storwize Remote Copy Relationship

IBM Storwize Tasks

1. IBM Storwize Custom SSH Command

IPMI Tasks

1. Verify IPMI Connectivity
2. Power On/Off IPMI Server
3. Select Boot Device

General Tasks

1. Apply License
2. Execute PowerShell Command
3. Set the starting time for the next task
4. Get IP Address From Pool
5. Get IP Subnet From IP Subnet Pool Policy
6. Get IP Address From IP Subnet
7. Remove IPAddress Reservation
8. Send Email
9. Send Email Through Template
10. User Approval
11. SSH Command
12. Notify URL
13. Wait for Specified Duration
14. Modify Workflow Priority
15. Execute Cloupia Script
16. Wait For Service Requests
17. Generate VLAN from pool
18. Generate VXLAN from pool
19. Collect Inventory
20. Rollback Child Service Request
21. Budget Allocation
22. Guest Setup
23. Notification
24. Resource Limit
25. VMware Provision Inputs
26. Multi User Approval
27. Reserve Capacity
28. Remove Capacity Reservation

VMware Host Tasks

1. Register iSCSI Storage with Hostnode
2. Get Service Profile vNICs associated to VMware Hosts
3. Register Host with vCenter
4. Register Hosts with Cluster
5. VSAN Enable Cluster
6. VMware Host Power Action
7. Mount NFS Datastore
8. Add Hosts to DVSwitch
9. Associate Hosts to DVSwitch
10. Remove Hosts from DVSwitch
11. Create Host Profile
12. Apply Host Profile
13. Attach Host to Host Profile
14. Detach Host from Host Profile
15. Delete Host Profile
16. Collect Host Profile Inventory
17. Assign VMs from Resource Pool to VDC
18. Unregister Host from vCenter
19. Create Resource Pool
20. Modify Resource Pool
21. Delete Resource Pool
22. VMware Remove Datastore from Host
23. Assign Resource Pool to Group
24. Assign Datastore to Group
25. Assign Datastore Cluster to Group
26. Unassign Resource Pool from Group
27. Unassign Datastore from Group
28. Unassign Datastore Cluster from Group
29. Create Cluster
30. Remove VMware Cluster
31. Cluster Resource Selector
32. Create DRS Rule
33. Modify DRS Rule
34. Delete DRS Rule
35. Create DRS Group
36. Modify DRS Group
37. Delete DRS Group
38. Enable/Disable DRS
39. Modify DRS Automation Level
40. Create Datastore Cluster
41. Modify Datastore Cluster
42. Delete Datastore Cluster
43. Add Datastore to Datastore Cluster
44. Remove Datastore from Datastore Cluster
45. Create Datastore Cluster DRS Rule
46. Modify Datastore Cluster DRS Rule
47. Delete Datastore Cluster DRS Rule
48. Enable or Disable VMDK Affinity Rule on VM

Cisco Network Tasks

1. Provision Network
2. Switch Port Action
3. Configure SAN Zoning
4. Copy Running To Startup Configuration
5. Delete SAN Zone
6. Create VLAN
7. Delete VLAN
8. Create VSAN
9. Delete Network Element
10. Delete VSAN
11. Create Port Profile
12. Delete Port Profile
13. Update Port Profile
14. Create Port Channel
15. Delete Port Channel
16. Configure Trunk
17. Configure Access
18. Modify Service Policy
19. Update Trunk
20. Configure VPC Domain
21. Assign Port to Port Channel
22. Assign FC Port to VSAN
23. Delete Device Alias
24. Create Device FCAlias
25. Update Device FCAlias
26. Delete Device FCAlias
27. Create Device Alias
28. Create ACL Entry
29. Delete ACL Entry
30. Add IP ACL Rule
31. Delete IP ACL Rule
32. Delete MAC ACL Rule
33. Add MAC ACL Rule
34. Assign VLAN to Group
35. Unassign VLAN from Group
36. Configure QOS on Nexus 5K
37. Configure QOS on Nexus 9K
38. Delete N9K QOS Profile
39. Configure QOS on Nexus 1K
40. Create Static MACAddress
41. Remove Static MACAddress
42. Assign Static MACAddress
43. UnAssign MACAddress Port
44. Configure MACAddress Table
45. Configure VTP
46. Create VXLAN
47. Update VXLAN
48. Remove VXLAN
49. Configure PVST
50. Configure Port License
51. Configure Port
52. Configure STP PORT
53. Configure MST INSTANCE
54. Configure MST
55. Assign VXLAN to PortProfile
56. Configure Feature
57. UnAssign VXLAN PortProfile
58. Encapsulate VXLAN PortProfile
59. Create N7K VDC
60. Remove N7K VDC
61. Update N7K VDC
62. Configure VPC PortChannel
63. Remove VPC PortChannel
64. Create VFC Interface
65. Associate VFC Interface
66. Allocate Port To VDC
67. Remove Port From VDC
68. Associate VSAN to VLAN
69. UnAssociate VSAN from VLAN
70. Create SAN Zone
71. Create SAN Zone Set
72. Delete SAN Zone Set
73. Add SAN Zone to Zone Set
74. Add Member To SAN Zone
75. Remove Member From SAN Zone
76. Activate SAN Zone Set
77. Remove San Zone From Zone Set
78. Create SXP Connection Peer
79. Update SXP Connection Peer
80. Remove SXP Connection Peer
81. Create HSRP
82. Update HSRP
83. Remove HSRP
84. Create SVI
85. Remove SVI
86. Delete VFC Interface
87. Remove System VLAN from Port Profile
88. Remove System VLAN Undo Configuration
89. Generic Configure SAN Zoning
90. Create Private VLAN
91. Delete Private VLAN
92. Associate Private VLAN
93. Delete Associate Private VLAN
94. Configure Private VLAN Port
95. Remove Private VLAN Ports
96. Configure Private VLAN Port Profile
97. Create N1K HyperV Port Profile
98. Update N1K HyperV Port Profile
99. Execute Network Device CLI
100. Configure System Level HA
101. Create Logical Network
102. Delete Logical Network
103. Create Network Segment Pool
104. Create Tenant VRF
105. Configure VXLAN Range
106. Delete Tenant VRF
107. Update Network Segment Pool
108. Delete Network Segment Pool
109. Create Network Segment
110. Update Network Segment
111. Delete Network Segment
112. Create Uplink Network
113. Update Uplink Network
114. Delete Uplink Network
115. Create IP Pool Template
116. Delete IP Pool Template
117. Update Ip Pool Template
118. Inherit Port Profile
119. Delete Inherit Port Profile
120. Publish to SCVMM

Cisco Security Tasks

1. Create Security Context
2. Remove Security Context
3. Configure Sub Interface
4. Configure Context Interface
5. Configure Context ACL
6. Configure Context NAT
7. Deploy ASAv OVF
8. TrustSec Refresh
9. Configure NAT
10. Configure License
11. Configure Cisco ASA Firewall Mode

Network Services Tasks

1. Setup PXE Boot
2. Setup PXE Boot With BMA Selection
3. Setup PXE Boot for Virtual SAN
4. Setup Windows PXE Boot
5. Remove PXE Boot Setup
6. Monitor PXE Boot
7. DNS name to IP Resolver
8. IP Address to DNS name Resolver
9. Add Account
10. Configure DHCP
11. Configure Interface
12. Service Status

1. Tenant Resource Cleanup
2. Tenant Onboarding Cleanup
3. Update Tenant Wrapper Cleanup

System Activity Tasks

1. Firewall Rule Actions Activity
2. APIC Container BM - iSCSI
3. APIC Container Setup Activity
4. APIC L4L7 Config Activity
5. LB Server Farm Actions Activity

RHEV KVM VM Tasks

1. RHEV KVM Resource Allocation
2. RHEV KVM Provision
3. RHEV KVM Power Action

Service Container Tasks

1. Provision Container - Network
2. Provision Container - VM
3. Allocate Container VM Resources
4. Verify Container Resource Limits
5. Setup Container Gateway
6. Setup Container F5 Load Balancer
7. Setup Container ASA Gateway
8. Send Container Email
9. De Provision Container - VM
10. De Provision Container - Network
11. Container VM Action
12. Update Servers To LB Farm Wrapper
13. Service Container Firewall Actions Wrapper
14. Container VMs Action
15. Re-Sync Container VMs
16. Allocate Additional Container VM Resources
17. Delete Container
18. Allocate APIC Container Resources
19. De Allocate APIC Container Resources
20. Provision APIC Container VMs
21. De Provision APIC Container - VM
22. Provision APIC Container Network
23. De Provision APIC Container - Network
24. Setup APIC Container Network Connection
25. Release APIC Container Network Connection
26. Create APIC Container Contracts
27. Delete APIC Container Contracts
28. Deploy ASAv VM from OVF
29. Allocate Additional APIC Container VM Resources
30. Deallocate Additional APIC Container VM Resources
31. Configure APIC Container L4-L7 Services
32. Initiate APIC Container BM Provisioning
33. Rollback APIC Container BMs
34. Persist APIC Container L4-L7 Service Info
35. Delete APIC Container L4-L7 Service Setup Info
36. Attach LB To APIC Container
37. Detach LB from APIC Container
38. Get APIC Container Tier Data
39. APIC Container L4-L7 Service Info Wrapper
40. Resource Limits to Container
41. Modify Cost Model of Container

Tier3 VM Tasks

1. Tier3 VM Power Action
2. Tier3 VM Provision

Cisco UCS Tasks

1. Select UCS Server
2. Create UCS Server Pool
3. Delete UCS Server Pool
4. Add Servers to UCS Server Pool
5. Delete Servers from UCS Server Pool
6. Associate UCS Service Profile Template
7. Reset UCS Server
8. Power On UCS Server
9. Power Off UCS Server
10. Create UCS Service Profile from Template
11. Create UCS Service Profile
12. Select UCS Service Profile
13. Modify UCS Service Profile Boot Policy
14. Delete UCS Service Profile
15. Associate UCS Service Profile
16. Check UCS Service Profile Association Status
17. Disassociate UCS Server
18. Disassociate UCS Service Profile
19. Create UCS Boot Policy
20. Modify UCS Boot Policy LUN ID
21. Clone UCS Boot Policy
22. Modify UCS Boot Policy WWPN
23. Create VLAN Group
24. Delete UCS VLAN Group
25. Modify UCS VLAN/VLAN Group Org Permissions
26. Server Maintenance
27. Reacknowledge Server Slot
28. Add VLANS to VLAN Group
29. Delete VLANS from VLAN Group
30. Add VLAN
31. Delete UCS Boot Policy
32. Delete UCS VLAN
33. Add VLAN to Service Profile
34. Delete VLAN from Service Profile
35. Add iSCSI vNIC to Service Profile
36. Delete iSCSI vNIC from Service Profile
37. Add vNIC to UCS Service Profile
38. Delete vNIC from Service Profile
39. Create Service Profile iSCSI Boot Policy
40. Modify Service Profile Boot Policy to Boot From iSCSI
41. Delete VLAN from Service Profile vNIC
42. Add VLAN to vNIC Template
43. Delete VLAN from vNIC Template
44. Create UCS Organization
45. Delete UCS Organization
46. Rename UCS Service Profile
47. Manage UCS Servers
48. Unmanage UCS Servers
49. Verify UCS Server Management State
50. Disassociate UCS Service Profile Template
51. Clone UCS Service Profile Template
52. Delete UCS Service Profile Template
53. Clone UCS Service Profile
54. Add NTP Server to UCSM
55. Set Time Zone to UCSM
56. Delete NTP Server from UCSM
57. Bind UCS Service Profile to Template
58. Unbind UCS Service Profile from Template
59. Add VLAN to Multiple UCS Managers
60. Virtual SAN PXE Boot on SD
61. Create Virtual Drives On C240M3
62. Mark SSD On C240M3

CIMC Tasks

1. Power On/Off CIMC Server
2. Select CIMC Boot Device
3. Configure Rack Server
4. Unconfigure Rack Server

VMware VM Tasks

1. Convert Image As VM
2. Create VM Snapshot
3. Save VM as Template
4. Clone VM as Image
5. Convert VM as Image
6. New VM Provision
7. VM Mount ISO As CD ROM
8. VM UnMount ISO From CD ROM
9. VM Remove CD/DVD Drive
10. OVF Import to VMware Cloud
11. Revert VM Snapshot
12. Mark/Unmark As Golden Snapshot
13. Delete VM Snapshot
14. Delete all VM Snapshots
15. Execute VIX Script
16. Resize VM Memory and CPU
17. Guest Setup
18. Resize VM Disk
19. VMware VM Resync
20. Create VM Disk
21. Delete VM Disk
22. Execute VM Command
23. File Explorer
24. Migrate VM
25. Resize VMWare Generic Datastore
26. VM Configure VNC
27. VM Disable VNC
28. Assign VMware Image to Group
29. Unassign VMware Image from Group
30. Delete VMware VM
31. Delete VMware Image
32. Assign VMs to VDC
33. VMware Resource Allocation
34. VMware VM Provision

VMware Network Tasks

1. Add Network to VM
2. Create vSwitch
3. Delete vSwitch
4. Create Virtual Nic
5. Delete Virtual Nic
6. Create DVSwitch
7. Modify DVSwitch For Teaming and Failover Settings
8. Delete DVSwitch
9. Modify DVSwitch For NIOC
10. Modify DVSwitch For System Network Resource Pools Traffic Setting
11. Enable Discovery Protocol on DVSwitch
12. Enable/Disable vMotion on VMkernel Port
13. Create DVPortGroup
14. Delete DVPortGroup
15. Add Virtual Adapter
16. Generate VMWare Generic PortGroup Identity
17. Add VMKernel Port On DVSwitch
18. Add Host VMKernel Port On DVSwitch
19. Remove Virtual Adapters
20. Add Service Console PortGroup
21. Add PNIC to DVSwitch
22. Migrate vSwitch PNIC to DVSwitch
23. Migrate vSwitch VMkernal Port to DVSwitch
24. Migrate Default vSwitch to DVSwitch
25. Migrate Default vSwitch to DVSwitch By Mapping Policy
26. Create VMware Port Group
27. Create VMKernel Port Group
28. Remove VMware Networking
29. Modify VM Network
30. Add VM vNICs
31. Delete VM vNICs
32. Add PNIC to VSwitch
33. Assign Port Group to Group
34. UnAssign Port Group from Group
35. Assign DV Port Group to Group
36. UnAssign DV Port Group from Group
37. Modify PortGroup
38. Update Network Policy

VMware Storage Tasks

1. Create Storage Profile
2. Edit Storage Profile
3. Delete Storage Profile
4. Expand Virtual SAN Cluster Wrapper
5. Create Virtual SAN Cluster Wrapper
6. Cleanup Virtual SAN Cluster Info
7. Rescan Storage Adapter

PNSC Tasks

1. Deploy VSG
2. Undeploy Container VSG
3. Provision Container VSG Network
4. Deprovision Container VSG Network
5. Provision PNSC Policies
6. DeProvision PNSC Policies
7. Add Tenant
8. Delete Tenant
9. Add vDC
10. Delete vDC
11. Add App
12. Delete App
13. Add Tier
14. Delete Tier
15. Add Zone
16. Delete Zone
17. Add Zone Conditions
18. Delete Zone Conditions
19. Add ACL Policy
20. Delete ACL Policy
21. Add ACL Policy Rules
22. Delete ACL Policy Rules
23. Add ACL Policy Set
24. Delete ACL Policy Set
25. Add Compute Security Profile
26. Delete Compute Security Profile
27. Add Compute Firewall
28. Delete Compute Firewall
29. Assign VSG To Compute Firewall
30. Unassign VSG From Compute Firewall
31. Bind Compute Security Profile To Port Profile
32. Unbind Compute Security Profile From Port Profile
33. Bind Compute Firewall To Nexus 1K
34. Unbind Compute Firewall From Nexus 1K

Amazon VM Tasks

1. Amazon VM Power Action
2. Create Amazon EC2 Volume
3. Create Amazon EC2 Volume from Snapshot
4. Attach Volume to EC2 Instance
5. Detach Volume
6. Delete Volume

F5 Big IP Tasks

1. Create F5 Load Balancer Virtual Server
2. Delete F5 Load Balancer Virtual Server
3. Modify F5 Load Balancer Virtual Server
4. Delete F5 Load Balancer Pool
5. Create F5 Load Balancer Application Service
6. Modify F5 Load Balancer Application Service
7. Delete F5 Load Balancer Application Service
8. Add Member to F5 Pool
9. Remove Member from F5 Pool
10. Create F5 Load Balancer Pool

Cisco Fabric Tasks

1. Create Fabric Organization
2. Modify Fabric Organization
3. Delete Fabric Organization
4. Create Fabric Network
5. Modify Fabric Network
6. Delete Fabric Network
7. Create Fabric Partition
8. Modify Fabric Partition
9. Delete Fabric Partition
10. Create VDC Fabric Switch Association
11. Delete VDC Fabric Switch Association
12. Extend Fabric Network Switch Association
13. Remove Extended Network Switch Association
14. Create end-user Fabric Network
15. Add Fabric Network To Network Policy
16. Add Fabric Network To Network Policy Allowed PortGroup
17. Fabric VDC Selector
18. Fabric Port Group Selector
19. Fabric Network Selector
20. Create Fabric Network for VDC Enabled Switches
21. Create Fabric MobilityDomain
22. Modify Fabric MobilityDomain
23. Delete Fabric MobilityDomain

Procedural Tasks

1. Start Loop
2. End Loop
3. If Else
4. Conditional Task
5. Resume Task

 

Generic VM Tasks

1. VM Power Action
2. Select VM Task
3. Modify VM Life Cycle
4. VM SSH Command

Business Process Tasks

1. Budget Watch
2. Resource Limit

Total number of tasks: 1508

Bare-metal workflow for Linux:

The workflow below is a variant of the previous ESX bare-metal workflow  in that it uses an almost similar set of tasks with minor variations to install a CentOS linux distribution on a Cisco UCS blade. The operating system is installed on FC LUN’s from the IBM Storwize V7000 Unified storage system. This workflow is shown to illustrate the flexibility and common methodology used for building infrastructure with UCS Director:

Overall workflow with list of  tasks:

Here is a screenshot to give an idea of workflow progress with time spent at each stage:

Task Details/Inputs:

Summary

It takes approximately 10 minutes for this workflow to  execute and another 5 minutes for the install to complete and the system to get rebooted. This platform can be the foundation for either a bare-metal workload or provide the basis for a docker container which requires Linux as the operating system. This           step could be followed by execution of  custom scripts to dockerize the linux platform. One option is to create a set of  custom tasks and integrate with above workflow after the OS is installed.  A basic task running a shell command (uname –a) and its output is shown below for reference:

 

 

 

 

 

 

 

 

 

 

K. Shivakumar Shastri, Technical Marketing Engineer(TME),  DC Solutions Engineering, Cisco Systems, Inc.

Shiva has about  20 years of experience in various aspects of Systems Engineering. Currently, his focus is on Cloud and hyper-convergence on integrated platforms.

Acknowledgements

Jeffrey Fultz , Cisco Systems, Inc.

Chris O’Brien, Cisco Systems, Inc.

Phani Penmethsa, Cisco Systems, Inc.

Muhammad Ashfaq, Cisco Systems, Inc.

Sally Neate, IBM

 

NOTE: Available paragraph styles are listed in the Quick Styles Gallery in the Styles group on the Home tab. Alternatively, they can be accessed via the Styles window (press Alt + Ctrl + Shift + S).