The Cisco UCS Remote Access Laboratory

by NetApp Staff on ‎2010-08-23 03:11 PM

Have you ever wished that it was easy to try out a new computing platform with your workloads and data before you buy it? Cisco set out to help eliminate the need for time- consuming and disruptive on-site testing to make the evaluation process dramatically simpler for its Unified Computing System® (UCS).

The Cisco® UCS Remote Access Laboratory was created to give users a hands-on understanding of the new management model created by UCS. The UCS lab is intended to allow you to see firsthand the powerful management capabilities of UCS and to bridge any gaps in understanding. The lab combines elements of Cisco, VMware®, and NetApp® technology to make it easy to do testing and proofs of concept using your workloads and configurations.

Since the lab was built, we've remained extremely busy with proofs of concept, demonstrations, and partner integration work. This article explains a little bit about UCS, and then describes the lab architecture and the advantages we get from NetApp storage.

Understanding UCS

Cisco announced the Unified Computing System in 2009. The architecture integrates compute, networking, storage access, and virtualization in a single platform. Cisco UCS is a model-driven server management system designed to reduce hardware and connectivity constraints, simplify server lifecycle management, and provide an agile infrastructure to support cloud computing. Based on a 10-Gigabit Ethernet-FCoE unified fabric, UCS greatly reduces the number of server connections and access-layer switches by consolidating compute resources around a unified I/O fabric that supports network, storage, and management traffic simultaneously.

The Cisco Unified Fabric is well aligned with the NetApp Unified Storage Architecture. UCS addresses the limitations of fixed/static server I/O connectivity by abstracting the hardware and I/O interfaces, thereby removing the hardware and connectivity constraints from a logical server ("service-profile" in UCS) and providing greater agility. Getting a deep understanding of UCS is difficult without seeing it firsthand, which is exactly why the Remote Access Laboratory is so important.

Figure 1) Cisco UCS management domain.

Cisco provides a single point of management for all elements in a UCS domain, as shown in Figure 1. Extending the size of a domain by adding blades or chassis is a simple task, since there are no points of management within a UCS chassis. UCS Manager lets you manage all physical elements as a pool of stateless resources that can be configured on demand, with whatever connectivity and server "personality" is required. The UCS Manager itself is embedded in the fabric-interconnect devices and automatically discovers and inventories new physical resources dynamically. A primary goal is to shorten the server deployment time to minutes rather than hours or days.

UCS Lab Architecture and Key Features

The high-level architecture of the UCS Remote Access Laboratory is shown in Figure 2.

Figure 2) Cisco UCS Remote Access Laboratory architecture.

Multi-Tenant Environment

The lab was designed with the idea that multiple tenants would need to be able to share it. It currently consists of three separate pods. Each pod is isolated on its own VLAN and is under the control of a separate instance of UCS Manager. We like to say that we could host Coke and Pepsi in the lab simultaneously and they'd be none the wiser (assuming that at least one of them was accessing the lab remotely, of course).

Consoles Hosted in Virtual Desktops

A separate VMware ESX server has been configured to host the console sessions for each instance of UCS Manager. Each instance is in its own VM, and each VM is on a separate volume on our back-end NetApp FAS3170 storage system. This approach provides isolation for separate clients, and it makes it possible to access a UCS console from a virtual desktop session either locally or at a remote location. VMs connect to storage via NFS over bonded 10-Gigabit Ethernet connections, which provide great performance for these virtual desktops when they are performing OS provisioning tasks.

SAN Boot

SAN boot is an essential element of UCS-and of the UCS lab. SAN boot allows UCS to support stateless servers for greater hardware abstraction. Any UCS blade can boot and run any boot image. This makes it easy to have hot spare blades within your UCS environment and immediately restart a server should the blade it's running on fail. In many ways this is the bare-metal equivalent of VMware VMotion™ (although there is a reboot when you move a server to a new blade).

In the lab, we need to support both physical as well as virtualized servers for our users. Doing SAN boot from NetApp storage makes it easy to configure any of our UCS pods with any combination of virtual or physical servers. I've configured SAN boot on other storage systems in the past, and it's much simpler with NetApp storage. In our environment, we have up to eight paths between storage and each host. With some storage systems you have to register each individual path on the storage array, which can be extremely cumbersome. With Data ONTAP®, paths from the host to the storage system are detected and registered automatically, saving a lot of time and pain.

CIFS Shares

The stateless nature of UCS makes it convenient for a lab environment like ours-or any dynamic environment. We have a CIFS share on the same NetApp storage system that mounts to each terminal console. The great thing about NetApp for our environment is that it supports all the storage protocols we need-or might need for testing-from a single storage system. We get both CIFS and NFS NAS protocols, plus we can use iSCSI, Fibre Channel, and FCoE SAN protocols.

The CIFS share contains all the applications and boot images-for both physical and virtual servers-that lab users might want to test with. The UCS Manager can direct any blade that it controls to boot from any of the available ISO images in the share using a "virtual media" capability.

We have the ability to prestage a UCS pod for you if desired, but we often like to let users do this themselves so they can see how simple the provisioning process is with UCS for both physical and virtual servers.

CIFS shares are also used as scratch/landing areas for lab user data, images, results, etc.

SnapRestore

A great capability that we get from NetApp storage is the ability to do a "clean reset" whenever a proof of concept completes. With NetApp SnapRestore® software we can roll everything-terminal console desktops, VMs, SAN boot LUNs, anything that was used during the test-back to a pristine state so that we can immediately restart, and the whole process takes just a few seconds to complete.

Who Uses the UCS Lab?

The Cisco UCS Remote Laboratory is designed to support both customers and partners. This is where the "remote" aspect of the lab comes into play. You can come to the facility if you wish, but you also have the ability to access the lab remotely, either from a Cisco field location or through one of our strategic partners.

A typical engagement usually starts with a one-hour live demonstration via WebEx; then you can use one of our UCS pods for from one to five days to focus on various aspects of running, operating, and maintaining the system. Most lab users bring their own workloads to qualify and benchmark so they can learn exactly how those workloads perform on UCS.

Our UCS environment is preconfigured with a variety of operating environments and applications to meet your needs, and the hardware is installed according to Cisco best practices. The lab contains nothing that isn't standard in a UCS environment-no special software, hardware, etc. When you use the lab you can be sure that what you see and the results you get are the same as what you would get in your own data center.

Another important focus for the lab is testing with Cisco partners. UCS offers an open XML-based API that allows management software to integrate with and manage the UCS environment. Ecosystem partners like CA, Platform, BMC, and others use the lab environment to do integration testing with UCS. At the management/orchestration layer, tools such as CA Spectrum can also take advantage of the Data ONTAP storage management APIs for end-to-end provisioning.

Fueling Success

One particular example illustrates how the UCS lab can help you succeed. Recently a large retailer used the lab in collaboration with several partners to demonstrate greatly reduced server provisioning time.

This particular company had outsourced all its IT operations, and provisioning time for a new service was in excess of a month. Now the IT team is in the process of developing a private cloud and bringing its IT infrastructure back in-house.

The UCS lab was used to support an integration demonstration that layered a NewScale solution on top of CA Spectrum Automation Manager, which in turn integrated directly with the UCS Manager via Cisco's XML-based API.

The end result of this extended lab session was a provisioning sequence demonstration-using the company's actual service catalog-that brought an entire approved technology stack (operating system, database, and applications) into service within eight minutes. The design also demonstrated automated provisioning plus the scalability of servers, networks, and storage in both physical and virtual contexts. Physical servers and vSphere™ VMs can be provisioned with equal ease and speed. In one use case when the system load exceeded a prescribed threshold, it automatically triggered the deployment of additional servers until load returned to an acceptable range. The CIO was thrilled to see this level of responsiveness, and was quoted as saying "This is amazing!"

Conclusion

I launched the UCS Remote Access Laboratory just prior to the general Cisco UCS announcement, and it's very gratifying to see users of the lab succeed beyond their expectations with UCS. The lab continues to be very busy-so busy, in fact, that we're currently planning the deployment of three additional UCS pods so that we can handle more activities in parallel. We'll also be able to take advantage of new capabilities like direct FCoE connectivity to NetApp storage.

NetApp is an integral component of the UCS Remote Access Laboratory. NetApp unified storage lets us support any storage requirement from a single storage system, simplifying the lab architecture and making the lab very easy to manage. Capabilities like NetApp SnapRestore make it fast and easy for us to start new testing sessions. The alignment I've seen between NetApp and Cisco is particularly strong; not only is NetApp a fundamental component of the UCS lab, UCS is a major component of NetApp Engineering's internal Kilo-Client test lab.

The Cisco UCS Remote Access Laboratory is available to help anyone who wants to test in a UCS environment. Just let us know if you are   interested, and we can help connect you with the right contact.

Ask questions, exchange ideas, and share your thoughts online in NetApp Communities.

Jeff Silberman
Technical Marketing Engineer

Cisco


Jeff is responsible for managing customer/partner proof of concepts, product demos, and customer "first encounters" with UCS. Jeff came to Cisco through its acquisition of Topspin. At Topspin he was responsible for the largest HPC deployments, including the Sandia Thunderbird 4,400-node cluster, which made its debut at #4 on the Top 500 deployments in November 2005. Prior to working at Topspin, Jeff spent four years at NetApp in the Advanced Product Development Group, bringing some of the first unified fabric solutions to market for Oracle®/NetApp environments.

Explore

Warning!

This NetApp Community is public and open website that is indexed by search engines such as Google. Participation in the NetApp Community is voluntary. All content posted on the NetApp Community is publicly viewable and available. This includes the rich text editor which is not encrypted for https.

In accordance to our Code of Conduct and Community Terms of Use DO NOT post or attach the following:

  • Software files (compressed or uncompressed)
  • Files that require an End User License Agreement (EULA)
  • Confidential information
  • Personal data you do not want publicly available
  • Another’s personally identifiable information
  • Copyrighted materials without the permission of the copyright owner

Files and content that do not abide by the Community Terms of Use or Code of Conduct will be removed. Continued non-compliance may result in NetApp Community account restrictions or termination.