Table Of Contents
Cisco Virtualization Experience Infrastructure 2.5 Implementing VMware View 5
Virtualization: Safeguarding the Desktop
Cisco VXI: New User Deployment Possibilities
Centralized, Virtual User Computing
Optimizing the Compute Subsystem in Cisco VXI
Fabric Interconnect and Switching Subsystem
Optimizing the Fabric Interconnect and Switching Sub-system in Cisco VXI
Advanced Configuration Options for the vSphere Hypervisor
Best Practices for vSphere Hypervisor Deployment
Virtual Switching: The Cisco Nexus 1000v
VM-based Security Zones: The Cisco Virtual Security Gateway
VM-based Network Optimization: Cisco vWAAS
Cisco VXI General Guidance for Shared Storage
Implementing EMC Unified Storage
Implementing NetApp FAS3170 Storage
Storage IO Traffic Reduction with Software Processing
Inline Deduplication of VDI Workloads
Optimizing IO Traffic - From Random to Sequential
Integrating Servers, Switches, Storage, and Hypervisor
WAN Optimization for VXI Traffic
WAN Fluctuations and Path Optimization
VXI Endpoint Access Services in the Branch
Load Balancing, SSL Offloading and VXI Health Monitoring
Deployment and Configuration Best Practices for VXI Network
Cisco Virtual Experience Client DV Endpoints
VXC 4000 UC Software Appliance for Thick Clients
VXC Media Termination Capability
DV Endpoint Printing (Network Printer)
DV Endpoint Access to USB-attached Peripherals (Storage or Printing)
Cisco Unified Communications Applications
VXC and UC Endpoint Single Sign-on:
Cisco Unified Personal Communicator, HVD and SRST
Cisco VXI System Applications Enabling UC Collaboration
Cisco VXI Management and Operations Architecture
Cisco VXI Management Tool Summary
Desktop Virtualization Endpoints
Cisco VXI Management Tasks and Work Flows
VMware View Manager Administrator Console
EMC Unisphere Management Suite
NetApp Virtual Storage Console
AppSense User Virtualization Platform
Unidesk Desktop Management for VDI
Anti-Virus for Desktop Virtualization
Deployment and Configuration Best Practices of Cisco VXI Security Components.
AnyConnect 3.0, 802.1X, and MAB along with ISE
Antivirus Solutions in Cisco VXI
Queuing for Optimum Cisco Unified Computing System Performance
Computing and Storage Capacity Planning
Resource Utilization in Current Environment
Estimating Resource Requirements in a Virtualized Environment
Hypervisor Considerations - VMware ESXi
Single Server Scale and Performance Testing
Network Characterization Results
Post Deployment Performance Monitoring
Cisco Virtualization Experience Infrastructure 2.5 Implementing VMware View
5
April 13, 2012
Contents
Preface
This Cisco Validated Design Guide provides design considerations and guidelines for deploying an end-to-end Cisco® Virtualization Experience Infrastructure (Cisco VXI) based on VMware® View™. The guide is intended for use by network engineers and architects considering the implementation of the Cisco Virtual Experience Infrastructure system.
The Cisco VXI system places a user's computing environment in the data center, allows it to be accessed through a variety of endpoints, integrates it with collaboration tools, and helps to ensure a high-quality user experience.
This guide discusses the system as a whole and groups subsystem descriptions as separate chapters. The chapters describe major functional groups—such as data center, network, and endpoints—as well as pervasive system functions, such as management, security, and quality of service.
The chapters have been organized to offer a modular discussion of the Cisco VXI system.
Document Objectives
This document provides design considerations and guidelines for deploying an end-to-end Cisco Virtualization Experience Infrastructure (Cisco VXI). The Cisco VXI system places a user's computing environment in the data center and allows it to be accessed via a variety of endpoints, integrates it with collaboration tools, and ensures a quality user experience.
The system as a whole is discussed, and subsystem descriptions have been grouped under separate chapters. The grouping is done along the lines of major functional groups: Data Center, Network, and Endpoints, as well as pervasive system functions: Management, Security, and Quality Of Service.
The chapters have been organized to offer a modular discussion of the Cisco VXI system. Table 1 describes each chapter/module.
Table 1
Chapter/Module Descriptions
The Cisco VXI system described here in reference form represents the totality of components supported by the design. However, the components described here are not intended as a recommendation of specific design substitutions. For instance, a finite set of access switching products were used during the testing of the reference architecture, but this does not mean that other access switching products are incompatible with the Cisco VXI system. Where required, specific component requirements are highlighted.
A Cisco VXI system is based on many subsystems like the virtualized data center, the virtualization aware network, and the virtualized workspace; for many customers, many of these subsystems are already deployed. For instance, most customers will already have a routing and switching infrastructure in place. This document is focused on the VXI-specific design guidance needed to augment a preexisting infrastructure within which VXI functionality will be deployed.
This document does not cover all of the foundational technologies and reference designs for routing, switching, security, storage, and virtualization. It refers to detailed documents covering those technologies and reference designs.
The Cisco VXI system is based on the integration of subsystems from different vendors. References to other vendors' product and system documentation are offered, and while every effort has been made to ensure that at time of publication, these references are accurate, there may be instances where changes to a vendor product or design guidance make specific references in this guide out of date. Please contact Cisco if you find such disparities.
The reader is referred to the VXI Configuration Guide that documents the detailed validated configuration for the VXI architecture. It includes specific software and hardware versions, complete device configurations and topology diagrams used in the validation. It also includes guidance on completing VXI specific use cases.
What's New in Cisco VXI 2.5
•
New UCS hardware including the UCS B200 M2, B250 M2, B230 M2, the UCS 2208 XP Fabric Extender, the UCS 6248 Fabric Interconnect, and the Cisco Nexus 5548UP that provide added network features for virtualized environment and increase the performance and scalability of the system.
•
•
•
•
•
•
•
•
•
•
•
Note
Acknowledgements
We would like to acknowledge our ecosystem partners for reviewing and providing feedback on the VXI CVD content.
These partners include VMware, Citrix, Microsoft, EMC, NetApp, Atlantis, Wyse, McAfee, TrendMicro, LiquidWare Labs, AppSense and Unidesk.
Revision History
This document was originally published on April 29, 2011. See Table 2 for the revision history.
Table 2
Revision History
Introduction
The main goal of desktop virtualization is to reduce total cost of ownership associated with a user's desktop environment while enhancing security and increasing business agility without compromising the quality of the user experience.
Virtualization: Safeguarding the Desktop
Centralized desktop virtualization (DV) takes the user's desktop environment and hosts it in a data center-based virtual infrastructure.
Since most of the desktop-related IT investment is now centralized, the management and operation of the enterprise's computing resources is simplified. Endpoints are easier to maintain and less expensive. The reduction of endpoint cost applies to both the capital expenditure (where the purchase cost of a DV endpoint is lower than that of a regular laptop/desktop) and the operational expenditure surrounding the operation of complex, "thick" endpoints. For instance, activities such as software asset tracking, licensing, patching, backup (both in time and bandwidth costs), and failure recovery are easier. In a virtualized desktop environment, an endpoint experiencing a failure is mainly a hardware appliance replacement issue with the user's files and desktop environment left intact within the data center's virtualized environment.
Data security is improved. A user has access to data as if they were connecting through a regular desktop computing environment, but the actual data is not delivered to or stored in the user's computing endpoint; rather, the data is merely viewed remotely. This presents two main advantages from a security standpoint:
•
•
Platform Independence
The endpoint can be chosen from an ever-expanding list of devices, including smartphones, tablet computing platforms, laptop and desktop computers. These include a multitude of operating systems. Thanks to virtualization, the enterprise can offer a consistent user experience across multiple devices. An employee can now access their desktop environment from various endpoints during the day: a desktop computer while working from headquarters, a thin endpoint when visiting a remote branch office, a mobile smartphone while traveling, and a tablet when moving around the enterprise. Even when working from home, an employee is provided with the means to "attach" to the enterprise through the use of a personal computer and a VPN client. In an enterprise where users are allowed to bring their own device (BYOD), virtual desktops provide a secure and alternative way of providing access to corporate applications with the HVD acting as a 'proxy' transmitting only display traffic to the users device.
Challenges
A user's IT environment is not entirely contained within the desktop. Collaboration tools such as audio and video telephony and printing services may not be served by DV technologies to the user's satisfaction.
For instance, remotely accessing audio, video, and interactive multimedia resources from within a virtual desktop may offer a degraded level of performance, while increasing the demands placed on the IT infrastructure such as WAN bandwidth. A telephone call, if placed from within the remote desktop and carried within the remote desktop's display protocol, may be connected to the user's computing endpoint without any network-based traffic prioritization. This effectively prevents the network's QoS functionality from affording the audio media the special handling it requires to prevent loss of quality due to delay, jitter, and packet drops. Likewise, the streaming of interactive multimedia content may inflate the bandwidth consumption of the DV endpoint, thus reducing the quality of the experience of not only the viewer of the media, but also that of other colocated users relying on the same WAN connection.
What Is Cisco VXI?
Cisco Virtualization Experience Infrastructure (VXI) is a service-optimized desktop virtualization system that spans Cisco's Data Center, Borderless Networks and Collaboration architectures to deliver a superior collaboration and rich media user experience in a fully integrated, open and validated desktop virtualization solution.
With Cisco VXI, you can take advantage of an architectural approach and services that deliver the best virtual desktop experience, while lowering operational costs.
VXI end-to-end services optimized for desktop virtualization include:
•
•
•
•
•
Cisco Virtualization Experience Infrastructure enhances desktop virtualization in the following ways:
•
•
Virtualized Workspace
Cisco VXI supports a rich ecosystem of Desktop Virtualization endpoints that include UC and rich media capabilities. The Endpoints and Applications chapter offers details on Cisco's DV endpoint offerings, including the Cisco VXC2200 series Zero client stand-alone tower, the Cisco VXC2100 series Zero client integrated with Cisco IP phone, the Cisco Cius mobile tablet, the Cisco VXC4000 UC software appliance, and the VXC6215 Thin client. The VXC endpoints include industry leading capabilities like PoE, integrated hardware and software form factors, mobility, and native UC media engine that significantly enhance TCO and the user experience for VXI users.
Integration into Cisco Unified Communications
A user can now connect to the hosted virtual desktop (HVD) to make and receive voice or video calls from Cisco Unified Personal Communicator. Cisco Unified Personal Communicator acts as a controller to the user's desk phone. The control plane of the phone is integrated into the user's desktop. However, the media plane is the same as that of any desk phone: the media traffic is connected outside of the remote desktop display protocol. This allows the network to perform quality-of-service (QoS) functions such as Real-Time Transport Protocol (RTP) packet prioritization, Call Admission Control, and path optimization. For example, two Cisco VXI users in the same branch can call each other, and while the control (signaling) plane resides in the data center, the audio connection between the users never leaves the branch. The branch network applies packet prioritization to the RTP flow, and the two phones connect directly to each other, without the need for the voice to traverse the WAN twice and hairpin through the data center. This same approach applies whether the endpoints are audio-capable only or video-capable.
Simplified Configuration Through the Cisco Unified Computing System Virtualized Computing Platform
The Cisco Unified Computing System™ integrates the compute, virtualization hypervisor, fabric interconnect, and storage functions usually found in separate platforms. This degree of integration is enhanced by the UCS Manager (UCS-M) and benefits both the performance and manageability of the data center. For instance, the Cisco Nexus®
1000V Virtual Ethernet Module places switching, traffic isolation, and policy-insertion capabilities within the virtualized environment. This means two virtual computers, which must be connected per a Layer 2 policy, can communicate directly within the virtualized environment, without the frames being switched through the physical switching infrastructure. Likewise, if a user should be prevented from connecting to a specific file system, the policy can be applied directly within the virtualized environment by using Cisco's virtualized switching platform.
Network Optimization
Many of the applications we use today are based on network protocols not optimized to be economical of network bandwidth, and may not perform well in the presence of bandwidth limits and/or network latencies. Cisco Wide Area Application Services (WAAS) technology can improve application response time by reducing bandwidth consumption, thereby increasing application performance. For instance, remote print operations can be launched from a user's virtual desktop within the data center, toward a network printer at a remote branch. WAAS can automatically recognize the printing protocol, compress it to reduce WAN bandwidth consumption, and spool the resulting print file at the remote branch, even if the remote printer is busy. This translates into a faster application response time for the user while consuming less bandwidth on the WAN. This has the dual benefit of improving the user experience while allowing a higher quantity of users to be served by a given WAN link. The core of Cisco WAAS Cisco Virtualization Experience Infrastructure Using VMware View functionality relies on Transport Flow Optimization (TFO), Data Redundancy Elimination (DRE) and Lempel-Ziv (LZ) compression technologies, which combine to minimize bandwidth consumption.
Security
Connectivity into the network can be controlled starting at the access layer, where a device first attaches to the virtual infrastructure. Industry-standard 802.1X can be deployed to control network access at the port level. Cisco's access switches can thus enforce a security policy at the physical device level and user level by interacting with the credentials-based access control integrated with directory services such as Microsoft Active Directory.
Teleworker users, such as mobile users using laptop computers, as well as fixed users, such as home-based teleworkers, can use Cisco's award-wining VPN technology to connect them into the enterprise network across the Internet. The user's virtual desktop data is fully protected as it traverses the Internet in a VPN tunnel, encrypted. This technology can also be deployed for traffic traversing a managed WAN.
End-to-End Testing
Cisco VXI is an end-to-end system, integrating network and collaboration functions into the virtual desktop experience. It has been designed and tested as an integrated whole, and mitigates the system integration investment required if one were to deploy DV, compute, networking, storage, security, optimization, and load balancing technologies in isolation. The design guidelines and best practices provided in the document will reduce the risk associated with a VXI deployment.
Deployment Models
The Cisco borderless network's promise of bringing the networked user experience to any device, in any place, at any time, can be fulfilled in various ways, depending on the particular demands of the enterprise. Virtualization brings another set of possibilities to the system designer, allowing different deployment models based on a shift in where the computing and networking investments are made.
The Cisco Virtualization Experience Infrastructure (Cisco VXI) system is fundamentally based on the centralization of the user's computing infrastructure in the data center. The computing infrastructure is virtualized and hosts the desktop virtualization (DV) and collaboration subsystems. Together, these subsystems provide the user community with desktop and telephony services delivered through the network to the various DV and collaboration endpoints. These endpoints can be located anywhere within the enterprise's network. The term "enterprise network" is used to signify both the enterprise's own networking infrastructure, as well as it's virtual private network (VPN)-based extensions into the Internet, and other various forms of externally-managed commercial networks.
A user can access the computing resources from a variety of locations. In the context of this chapter, location refers to the conditions of the network connectivity that the user's endpoint will be using to connect to the centralized computing services. As illustrated in Figure 1, endpoints are further defined based on their location in the network.
Figure 1 Cisco VXI Top-Down View
Campus Endpoint
A campus endpoint is deployed in a campus, where a colocated data center provides the computing resources, and a LAN provides the network connectivity, typically at speeds of 100 Mbps or more, and latency of 15 ms or less.
Branch Endpoint
A branch endpoint is deployed in an enterprise's remote branch, connected to the data center through a managed WAN. The WAN typically provides bandwidth, latency, and jitter guarantees, as per a negotiated service-level agreement (SLA), on-net addressing (addressing is private, as per RFC 1918), and offers some inherent degree of security (by comparison to the Internet). The remote branch where the endpoint is located is an enterprise-controlled environment and will typically feature a Cisco branch router (such as Cisco Integrated Services Routers), thus offering the ability to deploy network-based services, such as Cisco WAAS, telephony gateways, and Survivable Remote Site Telephony (SRST) to aid in accelerating some aspects of the DV service (such as printing).
Teleworker Endpoint
A teleworker endpoint is deployed over the Internet—for instance, when a remote worker is accessing the corporate network services over a VPN. The connectivity is provided by a VPN connection established over the public Internet. The characteristics of bandwidth, latency, and jitter are typically not known, and can vary from connection to connection, or over time within the span of the same VPN connection's duration. There are typically one (or more) Network Address Translation (NAT) traversals to connect through, and the underlying transport mechanism (the Internet) is untrusted. The remote environment can vary greatly, and the type of endpoint can be further classified as a mobile teleworker endpoint or a fixed teleworker endpoint.
Mobile Teleworker Endpoint
When the user is in a location where the connection to the Internet is made from a public Wi-Fi hotspot, hotel room, airport or other public space, it is considered a mobile teleworker endpoint. Typically, no equipment other than a laptop or mobile Internet device is available; the user is essentially relying on the device's own network and VPN capabilities. If more than one device is used (for instance, a mobile phone, a tablet computing device, and a laptop computer), they are each connected to the enterprise network services over their own, separated VPN connections.
Fixed Teleworker Endpoint
The endpoint is considered a fixed teleworker endpoint when the user is connected to the Internet through a dedicated broadband connection, such as a user in a home office environment. This situation can be very similar to the mobile teleworker endpoint, except for the relative bandwidth, which is typically greater in quantity and availability than provided by a public Internet connection. Another possibility in this case is to provide the user with a Small Office Home Office (SOHO) router, through which hardware-based VPN connectivity can be established. This affords the user more endpoint and connectivity choices, such as:
•
•
•
•
The various endpoint location possibilities just highlighted, share many attributes with Cisco VXI. The common functionality attributes are presented next through a discussion anchored on a branch endpoint. This is done to simplify the narrative. The various chapters covering the constituent technologies will highlight the differences stemming from the endpoint's location.
Cisco VXI: New User Deployment Possibilities
To illustrate some of the fundamental shifts in the deployment of user computing resources caused by centralized virtualization, the following sections contrast the computing and networking environment of the traditional, distributed user computing with the centralized, Cisco VXI environment.
Traditional Desktop Computing
Consider a typical desktop user's computing environment shown here located in the branch illustrated in Figure 2.
Figure 2 Traditional Desktop Computing Environment
User Computing Resources
The desktop user's computing environment (shown here located in the branch) is centered on the desktop personal computer. The user's desktop relies on its own hardware resources of compute (CPU), memory (RAM) and storage (hard drive). Of particular interest, the locally configured storage contains the user's operating system (OS) and personal files. This storage resource is an IT asset that must often be managed (backed up, patched, configured) remotely, across the enterprise's IP network. Centralized virtualization will bring the compute and storage resources under a shared, centrally managed and deployed storage system.
User Network Connectivity
User actions trigger various connections from the desktop, which support the user's typical applications.
•
•
•
•
•
•
Centralized, Virtual User Computing
Virtualization brings about a fundamental shift in the deployment of a user's computing and networking environments. Figure 3 illustrates the shift in the user's compute, connectivity, and storage environments when using desktop virtualization (DV).
Figure 3 DV-Based Computing Environment
User Computing Resources: Central, Virtual
In this deployment, the user's desktop has been deployed in a virtualized infrastructure. The user desktop's OS is now running centrally, over a shared compute, storage and connectivity infrastructure. This means that:
•
•
Note
User Network Connectivity
Connectivity between the user's desktop environment and the various IT services is now achieved within the data center. In some instances, when both the user's desktop and the target service are virtualized within the same compute infrastructure, the connections never leave the virtualized environment.
A New Type of Endpoint
The user's desktop has been replaced by a DV endpoint. In contrast to a traditional desktop environment where a "thick" client is required to support the user's applications executing locally, a virtualized environment requires a comparatively "thin" user device, supporting display and user input devices. User actions are relayed from the keyboard and mouse to the user's hosted virtual desktop (HVD) across a display protocol, and the resulting action is executed over the shared, virtualized resources of compute, storage, and connectivity. The visual result of the user's actions is propagated back to the user's DV endpoint across the display protocol.
Note
Cisco VXI supports a rich ecosystem of Desktop Virtualization endpoints that include UC and rich media capabilities. The Endpoints and Applications chapter offers details on Cisco's DV endpoint offerings, including the Cisco VXC2200 series Zero client stand-alone tower, the Cisco VXC2100 series Zero client "backpack."", the Cisco Cius mobile tablet, the Cisco VXC4000 UC software appliance, and the VXC6215 Thin client.
In the context of Figure 3, the Cisco VXC2200 is a standalone DV endpoint which can be powered by the access switch if Power over Ethernet (PoE) is available, or by a standalone power supply module if required.
The Cisco VXC2100 features similar functionality, but in the form of an add-on hardware module to the Cisco IP telephone; the phone's connection to the access switch can thus be leveraged to power and provide network connectivity to the Cisco VXC2200. This approach yields a workspace where the physical desktop is free from extra clutter and devices.
The Cisco Cius is a touch-screen mobile tablet that supports UC applications including voice and video conferencing as well as DV applications that allow it to act as a Virtual Desktop Thin-Client.
The Cisco VXC 4000 is a UC enabled software appliance that delivers UC capabilities to a thick client running a DV client. The VXC 4000 delivers UC voice collaboration to the DV user by terminating voice media streams on the local thick client when controlled by CUPC running in the HVD. This solution intelligently separates the desktop protocol and media (voice and video) traffic so that the each individual media type can be handled separately and prioritized by the network.
The Cisco VXC-6215 is a thin DV client that provides the necessary functionality to connect to an HVD. It will also include (in future release) a built-in Cisco Unified Communications media engine that delivers optimized UC voice and video capabilities to the HVD. The VXC-6215 will intelligently separate the UC media traffic from the DV display protocol traffic so that each media type can be handled and prioritized by the network.
A Shift in Connectivity
In a non-virtualized environment, a user's actions often result in network traffic between the user's desktop and the data center. The habitual connectivity consideration of system designers is to make sure an enterprise branch is deployed with an amount of bandwidth commensurate with the connectivity needs of desktop applications contained within the branch. These needs vary per application: some will consume as much bandwidth as possible during execution (true, for example, of a data backup application), while others will sporadically require bandwidth (for example, web browsing). In all but campus deployments, the connectivity traverses the limited bandwidth of WAN or Internet clouds.
Let's explore some examples of how the connectivity needs of a DV user shift when compared to those of a desktop user.
File Backup
As illustrated in Figure 4, when a backup application copies files from the user's desktop toward a central file storage system, the data flow traverses the enterprise IP network. When the user is located in a branch office, the backup action traverses the WAN, where latency and bandwidth impact the duration and cost of the transaction.
Figure 4 Traditional Desktop File Backup
In a centralized desktop virtualization environment, the user's desktop and the central storage system are co-located and served by the same high-speed LAN. The backup action is thus comparatively faster and more economical. Figure 5 illustrates the shift in connectivity for backup operations:
Figure 5 DV-Based File Backup
Whether the file backup system is itself virtualized or not, it is co-located with the user's HVD, and thus the backup traffic does not traverse the WAN. This example illustrates the shift in connectivity brought about by virtualization of the user's desktop in the data center.
Internet Browsing
A traditional desktop Internet browsing example is illustrated in Figure 6. Consider a desktop user located in a branch accessing the Internet. There are two popular connectivity topologies for enterprises to choose from: either a centralized Internet access point located within the data center, or access to the Internet through a localized branch connection. When considering equivalent bandwidth connections, the user's experience is the same in both cases, although Internet access through the data center places bandwidth demands over the enterprise IP WAN.
In the specific case of desktop based interactive multimedia content browsing, such as the viewing of Flash-based video files, bandwidth demands precede the playing of the file. The content is downloaded first and then played. Even in the case of some streaming content, the content viewing lags behind the bandwidth demand, due to the buffering of the media file.
Once the interactive multimedia file is playing in the user's desktop (or, in the case of streaming media, once the buffer has reached the end of the file), it places no bandwidth demands on the WAN or the Internet connection.
Figure 6 Traditional Desktop Internet Access
When Internet access is achieved through a HVD, the shift in connectivity depends on the DV endpoint's capabilities. In Figure 7, consider a DV endpoint whose Internet browsing abilities are essentially carried out by the HVD's browser. This results in bandwidth consumption between the user's HVD and the Internet through the central Internet connection during the multimedia content download, followed by bandwidth consumption over the enterprise IP WAN while the file is playing. The latter is an important consequence of the displacement of content execution from the remote branch toward the central data center: display updates from the HVD to the DV endpoint require WAN bandwidth, even after the Internet content being viewed has been delivered to the HVD. In the case of looped interactive multimedia animations, the Internet download of the content may represent a punctual, finite amount of bandwidth over the central site's Internet connection (for example, 1 Mbps for a few seconds), while the display protocol's demands on WAN bandwidth will last as long as the user's desktop is rendering the file.
Figure 7 DV-Based Internet Access
In another deployment model, shown in Figure 8, the DV endpoint, while still relying on the centralization of much of the user's computer resources in the data center, retains some local execution capabilities for multimedia files.
Figure 8 Local Internet Access to Rich Media Content
Figure 8 illustrates a DV endpoint supporting local execution of media-rich content. In this deployment model, the DV endpoint interacts with the display protocol and the HVD's management system to retain control over certain media types. Upon accessing interactive multimedia content over the Internet, the DV subsystem instructs the DV endpoint to locally connect to the Internet to fetch the media file to be viewed. Once received at the DV endpoint, the file's content is locally executed on the endpoint, with no dependency on the WAN connectivity to the user's HVD. This approach can yield better performance for the user, while reducing the bandwidth demands placed on the enterprise's WAN. The DV endpoint's content viewing and rendering capabilities vary according to the DV subsystem's functionality and the type of endpoint. The "Data Center" chapter offers more insight into various vendor options and level of support provided for this functionality
Printing
In the non-virtualized environment shown in Figure 9, the printing actions of a desktop user typically do not generate network traffic outside the local branch. A user printing to a directly attached USB printer or even to a network-attached IP printer will trigger a data connection flow from the desktop to the printer directly. The bandwidth consumption is essentially contained within the branch location.
Figure 9 Traditional Desktop Printing
In a centrally virtualized environment, the user's print actions rely on a connection from the user's HVD to the branch-located printer. This connection is either from the HVD to the DV endpoint's USB port, as illustrated in Figure 10, or to a branch's IP networked printer as shown in Figure 11. In either case, the print action is dependent on the connectivity from the user's HVD to the branch location. Cisco's WAN optimization solution (WAAS) can provide significant bandwidth optimization of the print traffic travelling across the WAN from the Data Center towards the branch. Please refer to the Network Chapter for more details on the print optimization that can be achieved with WAAS.
Figure 10 DV-based USB Printing
Figure 11 DV-based Network Printing
The functionality considerations of compute and network resources outlined in these figures apply to DV deployments in general. The Cisco VXI system facilitates the deployment of centralized virtual environments by targeting various subsystems to the DV challenges:
•
The Cisco Unified Computing System™ (UCS) family of servers and fabric interconnect products bring integrated management, performance, and scalability to the compute and storage needs of centralized virtualization.
•
Cisco Wide Area Application Services (WAAS), Adaptive Security Appliance, and Application Control Engine offer bandwidth efficiency, security and high availability to network connections.
•
Cisco Unified IP Phones offer a guaranteed-quality video and audio experience to the user. Cisco Unified Personal Communicator integrates telephony functionality into the desktop virtualization user experience. Cisco VXC endpoints integrate the Desktop Virtualization and the Unified Communications and Collaboration user experience.
As part of Cisco's Borderless Networks Architecture, the Cisco VXI system allows desktop virtualization deployments to deliver a high-quality experience to the user while enabling the many cost and operational advantages of centralized virtualization.
Data Center
In virtualized environments, desktops are generally hosted on data center servers. Changes in the user population translate directly into changes in the data center, which means that scalability and flexibility become critical. Data center servers must be capable of (1) delivering high performance, (2) providing sufficient memory for high virtual machine (VM) densities, and (3) offering improved energy efficiency. The data center also needs to be capable of integrating hypervisors with appropriate policy and security processes for virtual resources. Finally, with storage now centralized as well, the data center needs to easily accommodate a wide range of storage options, including Network-Attached Storage (NAS), Storage Area Networks (SAN), and Local Storage.
The Cisco VXI Virtualized Data Center is based on Cisco's Data Center Business Advantage architecture, which is designed to create data centers that are efficient, agile, and transformative. The Virtualized Data Center (Figure 12) enables enterprises to consolidate data center infrastructure, reduce energy costs, improve workforce productivity, and ensure business continuity. It also can be adopted in an incremental, granular fashion to assure a graceful evolution in response to organizational needs. The Virtualized Data Center provides the compute, switching, storage, and virtualization capabilities needed to support a hosted desktop solution.
The Virtualized Data Center comprises four essential subsystems: (1) Compute, (2) Fabric Interconnect and Switching, (3) Virtualization, and (4) Storage. In addition, the Virtualized Data Center includes the tools necessary to manage each of these subsystems.
•
•
•
•
–
–
–
–
–
•
Figure 12 Data Center Building Blocks
Note
Compute Subsystem
The Cisco VXI system's compute building block uses Cisco Unified Computing System (UCS) B-Series blade servers or C-Series rack-mount servers to host the virtual desktops. Both B- and C-Series servers support the Cisco Unified Fabric system, which provides 10 GB connectivity between compute, LAN, and storage networks via a single media. Both types of server also support Cisco Extended Memory Technology, which increases performance, capacity, and VM density compared to traditional servers. UCS servers are designed to reduce energy consumption, with highly efficient power supplies and Intel Xeon processors that match power consumption with workloads. Each server contains the processor, RAM, and I/O resources needed to support a virtualized desktop environment. Cisco UCS servers are managed by Cisco UCS manager, which implements role-based and policy-based management using service profiles and templates.
B-Series Servers
The Cisco UCS B-Series Blade Servers are housed in the Cisco UCS 5108 Blade Server Chassis, which can contain up to eight half-slot or four full-slot B-Series blade servers. Cisco VXI has validated three models of the Cisco UCS B-Series:
•
•
•
•
The B-Series blade servers connect to the chassis mid-plane by means of Virtual Interface Cards, installed as mezzanine cards on each server. These cards provide virtual Ethernet NICs or HBAs to the server operating system, and 10 GB FCoE ports for connecting to Cisco UCS 2x00 Series Fabric Extenders located on the back of each chassis. The fabric extenders aggregate traffic from the Virtual Interface Cards and pass it along (using 10 Gigabit FCoE uplinks) to a pair of Cisco UCS Series 6x00 Fabric Interconnects (see Figure 13). The Cisco UCS 6x00 hosts the Cisco UCS Manager, which is used to manage both compute and switching fabric resources.
C-Series Servers
Cisco UCS C-Series Rack-Mount Servers extend Cisco Unified Computing System™ innovations, such as Cisco Extended Memory Technology and unified network fabric, to an industry standard rack-mount form factor. The C-Series servers can operate both in standalone environments and as part of the Cisco Unified Computing System. The C-Series servers can be deployed incrementally according to an organizations timing and budget. These servers support Converged Network Adapters, and integrate easily with existing networks and storage solutions. This Cisco Validated Design was verified with two models of the Cisco UCS C-Series:
•
•
Figure 13 Cisco UCS B-Series
Optimizing the Compute Subsystem in Cisco VXI
•
•
•
•
Note
Fabric Interconnect and Switching Subsystem
The Cisco UCS 6x00 Fabric Interconnects provide both network connectivity and management capabilities for the Cisco Unified Computing System. The Cisco Fabric Interconnects offer line-rate, low-latency, lossless 10 GE, Fibre Channel and Fibre Channel over Ethernet capabilities. The fabric interconnects are formatting typically deployed in redundant pairs to provide uniform access to both networks and storage. The Cisco UCS 6x00 delivers a high performance unified fabric, centralized unified management with Cisco UCS Manager, and virtual machine-optimized services with support for VN-Link technologies.
The Cisco UCS 6x00 Series terminates the FCoE traffic flows coming from the blade enclosures. The Ethernet traffic is separated and forwarded to the data center switch fabric (composed of Cisco Nexus® 5000 and 7000 Series Switches). Fibre Channel traffic is forwarded via Fibre Channel uplinks to the Fibre Channel storage area network (SAN). The Fabric Interconnect and Switching building block supports both the networking and storage data flows from the Compute building block.
The fabric interconnect embeds Cisco UCS Manager to facilitate management of the UCS system. By using Cisco UCS Manager in combination with DV management software, administrators can deploy virtual machines, perform software upgrades, migrate virtual machines between physical servers, and extend compute resource control over thousands of virtualized desktops. In addition, the Cisco UCS Manager and the DV management software provide tools for monitoring and managing the entire desktop virtualization environment.
The Cisco Nexus 5000 Series and 7000 Series switches provide high-speed Ethernet switching. They are generally installed as redundant pairs, with the 5000 Series switches in the access layer and the 7000 Series switches in the core. In conjunction with the Cisco UCS fabric interconnects and the Cisco Nexus 1000V Series Switch, the Nexus 5000 and 7000 Series switches provide a high performance, low latency infrastructure for supporting desktop virtualization.
Optimizing the Fabric Interconnect and Switching Sub-system in Cisco VXI
As the number of virtual desktops grows, so does the complexity of management, security, and availability. The effective use of VLANs will improve the efficiency of the switching sub-system. For example, Figure 14 shows the use of multiple VLANs to segment the DV server pool. These VLANs may terminate on the data center router or a firewall based on the company's network policies.
In Figure 14 the VLANs assigned to three separate pools of machines are implemented in the Cisco Nexus 5000 Series Switches and the Cisco UCS 6x00 Fabric Interconnect at the physical level, while the hypervisor provides the VLAN implementation at the virtual level. The VLAN numbers shown for the separate pools of virtual machines are arbitrary. These VLAN designators should be assigned according to the network policies set by the data center administrators.
The pool labeled VLAN 21 represents applications that need access to the public Internet. Those virtual machines are typically firewalled from the internal applications hosted on the servers in the pool marked with VLAN 22. The pool of servers hosting the virtual desktops is represented by VLAN 23. This pool also would be firewalled from the servers shown in VLAN 22.
Successful implementation of a Cisco VXI system will necessitate extensive use of VLANs to separate DV, storage, management, VM migration, and other forms of traffic. Refer to the "Connecting the Server to the Network" section later in this chapter for a recommended list of VLANs.
Figure 14 Physical Resource Allocation for Network Connectivity
Hypervisor
VMware vSphere is a suite of products that provides virtualization, management, resource optimization, availability, and optimization capabilities. The VMware vSphere hypervisor (which has also been known as ESX/ESXi) is the primary virtualization component of vSphere. vSphere is a Type 1 hypervisor, meaning it runs directly on physical server hardware. vSphere abstracts the processor, memory, storage, and networking resources of its physical server into multiple virtual machines, and ensures that each VM receives its appropriate share of these resources (see Figure 15). The VMware vCenter Server is a set of advanced tools front ended by a Graphical User Interface (GUI) by which vSphere servers and its associated virtual machines are managed. It also provides advanced capabilities that are particularly useful in high density production environments. These tools enable IT administrators to identify over-committed host machines, move VMs among pooled hosts, manage power up sequences, consolidate active VMs on the fewest possible hosts, and more.
The hypervisor is installed on each Cisco UCS server to allow virtualized desktops and servers to run as independent virtual machines (VMs). Physical and virtual resources can be grouped according to several criteria. Pools of virtual machines can be defined along the lines of worker profile boundaries such as "task worker" "knowledge worker," or "power user." Resources also can be grouped according to organizational boundaries such as sales, marketing, and engineering. Each pool contains a set of like VMs with the same security and QoS policies. Pools of virtual machines are associated with common resources by the hypervisor. These common resources are kept available to the virtual machines wherever the hypervisor chooses to run the virtual machines.
Figure 15 VMware vSphere Hypervisor
The hypervisor also provides virtual desktops with storage resources. Each virtual desktop is associated with a storage pool. Connectivity to the storage is provided in the virtual realm by the hypervisor and can be physically located on the UCS blade server (a local drive) or remotely attached. In order to support virtual machine migration, clustering, distributed resource scheduling and other advanced virtualization features, the data storage for a particular set of users must be common to the entire set of physical servers hosting those virtual desktops. For this reason, shared storage is often preferred for DV. The shared storage may be located on a Fibre Channel SAN or on the IP network in the form of network file server (NFS) or iSCSI-based storage.
For access to Ethernet data and network-based storage resources, the hypervisor bridges the virtual and physical realms by interfacing the virtual desktops with Virtual Interface Cards on the physical blade servers. The Virtual Interface Cards provide the physical server (and thus the hypervisor) access to Ethernet NICs and Fibre Channel host bus adapters (HBAs). Each card combines the Ethernet and Fibre Channel traffic onto a unified fabric in the form of Fibre Channel over Ethernet (FCoE) traffic. The hypervisor maps the physical network interface cards (NICs) to virtual NICs as part of the virtual switch. Physical Host Bus Adapters (HBAs) for Fibre Channel traffic are bridged directly to virtual HBAs.
Advanced Configuration Options for the vSphere Hypervisor
VMware vSphere provides the ability to fine-tune CPU and memory resources in virtual machines, which can increase VM density per server. For example, vSphere can ensure that each VM is granted fair access to CPU resources. In some cases, such as with hyper-threaded processors, the fairness algorithm can idle logical processors and actually reduce overall performance. To address this situation, VMware vSphere includes the HaltingIdleMsecPenalty (HIMP) parameter, which controls when the fairness algorithm takes effect, and enables administrators to strike the appropriate balance between aggregate throughput and CPU resource sharing.
Vmware vSphere also includes memory reclamation capabilities that enable administrators to over-commit host physical memory. These capabilities include transparent page sharing, memory ballooning, memory compression, and hypervisor swapping. A fully detailed description of these features and their use is beyond the scope of this document. Please refer to Understanding Memory Resource Management in VMware vSphere 5 for complete information.
For vSphere 5, VMware has adjusted the default settings for these parameters so that the hypervisor is optimized for larger scale deployments. Cisco VXI has validated vSphere 5 to measure the increase in VM density associated with these optimized settings. Refer to the Capacity and Performance document for specific test results.
Note
Best Practices for vSphere Hypervisor Deployment
The vSphere hypervisor should be set to boot from shared storage where possible. This allows for off-the-shelf server replacements as well as centralized configuration management of the ESX/VMware ESXi™ software.
Set the vSphere management Ethernet address on a different subnet from the Cisco UCS Manager network. This allows the user to have access to the virtual KVM console (part of the UCS Manager software) even if the hypervisor is not functional.
Synchronize the hypervisor clock to an external NTP server. Then synchronize the virtual desktop OS clocks to the hypervisor clock. This will help ensure that logging information will maintain time consistency. This task can be accomplished with the VMware tools installed on the virtual desktop.
Refer to the VMware vSphere documentation page for more details: http://www.vmware.com/support/pubs/vsphere-esxi-vcenter-server-pubs.html
Virtual Switching: The Cisco Nexus 1000v
The Cisco Nexus 1000v is a virtual machine access switch for VMware vSphere environments. The Cisco Nexus 1000v runs inside the VMware ESX or ESXi hypervisor, and leverages Cisco VN-Link server virtualization technology to deliver policy-based VM connectivity, mobile VM security and network policy, and a non-disruptive operational model. The Cisco Nexus 1000v provides administrators with a consistent networking feature set and provisioning process all the way from the VM access layer to the core of the data center network infrastructure. Virtual servers can leverage the same network configuration, security policy, diagnostic tools, and operational models as their physical server counterparts.
With the Cisco Nexus 1000v virtual switch, a virtual realm is not bound to one physical server. A single distributed virtual switch can cross several physical servers. Port profiles can be created once and associated with each virtual desktop. Targeted port profiles can be created for the specific requirements associated with each type of user and virtual desktop. If the virtual desktop migrates, the port profile will migrate with it. This profile is created within the Cisco Nexus 1000V Series Switch and contains information such as VLAN assignment, QoS policies, and security access control lists (ACLs). The port profile is linked to the VMware vCenter virtual machine profile, such that if vCenter migrates a particular virtual desktop via vMotion, the associated port profile will also migrate.
Troubleshooting of virtual desktop connectivity issues is enhanced through the built-in switched port analyzer (SPAN) protocol. Lastly, increased security is implemented by the use of several additional features such as VLANs, private VLANs, port security, security ACLs. The Cisco Nexus 1000V also provides a foundation for other virtual networking solutions such as the Cisco Virtual Security Gateway (VSG) and Cisco vWAAS.
The Cisco Nexus 1000V is currently supported on VMware vSphere hypervisors with Enterprise licensing.
Figure 16 VMware ESX/ESXi and Cisco Nexus 1000V Series Integration
VM-based Security Zones: The Cisco Virtual Security Gateway
Cisco Virtual Security Gateway for Cisco Nexus 1000v Series switches is a virtual appliance that controls and monitors access to trust zones in enterprise and cloud provider environments. Cisco VSG provides secure segmentation of virtualized data center VMs using granular, zone-based control and monitoring with context-aware security policies. Controls can be applied across organizational zones, lines of business, or multitenant environments. Context-based access logs are generated with network and VM activity levels. Trust zones and security templates can be provisioned on-demand as VMs are created.
Cisco VSG employs the virtual network service data path (vPath) technology that is embedded in the Cisco Nexus 1000v Series Virtual Ethernet Module. Cisco vPath steers traffic to designated Cisco VSG for initial policy evaluation and enforcements. Subsequent policy enforcement is offloaded directly to vPath. Cisco VSG can provide protection across multiple physical servers. It can be transparently inserted in one-arm mode, and offers an active-standby mode for high availability.
Cisco VSG can be deployed across multiple virtual machine zones, virtualized data centers, and/or virtualized applications. It requires a virtual 1.5 Ghz CPU, 2 GB RAM, 3 GB hard drive, and three network interfaces (data, management, and high availability). It also requires VMware vSphere and vCenter, Cisco Nexus 1000v VEMs and VSMs, and Cisco Virtual Network Management Center.
For more information on the Cisco VSG, refer to the "Cisco VXI Security" chapter, in this guide.
Figure 17 Cisco Virtual Security Gateway
VM-based Network Optimization: Cisco vWAAS
Cisco Virtual WAAS (vWAAS) is a virtual appliance that accelerates business applications delivered from private and virtual private clouds. Cisco vWAAS runs on Cisco UCS servers and the VMware vSphere hypervisor, using policy-based configuration in the Cisco Nexus 1000v switch. Cisco vWAAS can be associated with application server VMs as these are instantiated or moved. With Cisco vWAAS, cloud providers can rapidly provision WAN optimization services with little to no configuration or disruption.
Figure 18 Cisco vWAAS
Cisco vWAAS requires storage access to store the data redundancy elimination byte cache and the Common Internet File System (CIFS) cache. In the data center, it supports either local storage or remote shared storage in a SAN (SCSi or iSCSi). Cisco recommends the use of the SAN option to enable advanced VMware features such as vMotion, VMware Storage vMotion ®, and VMware High Availability.
In the deep data center deployment model, Cisco vWAAS VMs are placed next to server VMs in the same VMware vSphere host. Using the policy-based virtual services of the Cisco Nexus 1000v switch, Cisco vWAAS can be deployed on a per-application or per-server-group basis. vPath interception in the Cisco Nexus 1000v intercepts all traffic to and from these servers and forwards it to the Cisco vWAAS VM for optimization.
Cisco vWAAS requires storage access to store the data redundancy elimination byte cache and the Common Internet File System (CIFS) cache. In the data center, it supports either direct-attached storage or remote shared storage in a SAN (SCSi or iSCSi). Cisco recommends the use of the SAN option to enable advanced VMware features such as vMotion, VMware Storage vMotion ®, and VMware High Availability.
For more information on Cisco vWAAS, see the "VXI Network" and "Performance and Capacity "chapters, in this guide.
Desktop Virtualization
This Cisco Validated Design guide describes the implementation of Cisco VXI with VMware's View solution for desktop virtualization. With View, organizations can create and run virtual desktops in the data center, and deliver these desktops to employees using a wide range of endpoints. Users access their virtual desktops from zero, thin, or thick clients by means of a remote display protocol (PCoIP or RDP). Figure 19 shows a typical desktop virtualization implementation based on VMware View. Key components of the View solution include:
•
•
•
•
•
View Agent
VMware View Agent on each HVD in the pool is required to create the connection between the client and HVD. The features and policies on View Agent can be controlled via Active Directory and/or View Connection Server settings. The agent also provides features such as connection monitoring, virtual printing, and access to locally connected USB devices. To install the agent automatically on all HVDs in a pool, install the View Agent service on a virtual machine and then use the virtual machine as a template or as a parent of linked clones. The capability set of the agent is tied to the operating system. Please consult the appropriate VMware documentation for compatibility information.
View Client
VMware View Client is installed on each endpoint that needs to access its HVD. View Client supports PC over IP® and Microsoft Remote Desktop Protocol (RDP). View Client also supports a local mode option that enables the user to work in offline mode; however, this needs View Transfer Server in the data center and is not covered here. Zero client devices have a View Client integrated in the embedded operating system.
VMware View Client supports Local Mode operations, in which users can download a View desktop to a local system and operate with or without a network connection. View desktops in local mode function the same way as equivalent remote desktops, but are also able to take advantage of local system resources such as memory and CPU. This capability may reduce latency and enhance performance for desktop users. If a network connection is available, the local mode desktop continues to communicate with the View Connection Server for updates. Users can access their checked-out desktop directly, and can log off and on without going through the Connection Server. The local desktop can be checked back in at the user's convenience.
View Connection Server
This software service acts as a broker for client connections. VMware View Connection Server authenticates users via Active Directory and post-authentication directs the user to an appropriate HVD. Some other important functions performed by View Connection Server are desktop entitlement for users, desktop session management, establishing secure connections between users and desktops, policy application, and single sign-on. View Administrator is a user interface that comes prepackaged with the View Connection Server and provides an administrative interface for management. The sizing guidelines for View Connection Server can vary based on display protocol type, VM resources, use of encryption, and choice of tunneled or non tunneled mode. It is highly recommended to implement a load balancing solution such a Cisco ACE Application Control Engine Module in a large deployment. Please see Chapter 4, "Network," for more details on this topic. VMware View enables desktops to be configured to run in kiosk mode. This mode might be used at airline check-in stations, libraries, or customer self-service locations. In kiosk mode, accounts can be associated with client devices, so that users do not have to log-in to the client device or the View desktop (however, the hosted application can still require user authentication). View desktops running in kiosk mode use stateless desktop images, and do not preserve user data in the operating system. VMware recommends that administrators use dedicated View Connection Servers to handle clients in kiosk mode, and use dedicated groups in Active Directory for their accounts. To configure kiosk mode, refer to the VMware View Administrator's Guide.
View Composer
View Composer is an important VMware View component that allows for storage optimization. In DV environments, data redundancy per HVD is very high since typically the same OS and application sets are replicated across the virtual desktop pool. To deal with this, View Composer creates a pool of linked clones from a specified parent virtual machine. Each linked clone acts like an independent desktop, with a unique host name and IP address, yet the linked clone requires significantly less storage because it shares a base image with the parent.
View Composer can create images that share the base OS image while still keeping the user profile data separate. It is highly recommended to separate the OS files from user profiles in the storage array. Disk space requirements when using View Composer can be reduced by more than 50 percent.
View Composer is set up on the same virtual machine as vCenter to allow control of the VMware ESX® hosts. Each View Composer server in a cluster can handle up to 512 HVDs in a pool; in a large deployment, clustering multiple View Composer instances may be required.
Please note that if the company policy allows users to install custom applications, the full benefits of View Composer can't be realized. It is highly recommended to separate such user profiles and place these HVDs on a backed up data storage system.
View Transfer Server
This server manages transfers between the data center and View desktops that have been checked out for use on local systems. It is required for desktops that run View Client with Local Mode. The View Transfer Server also ensures that changes generated on the local desktop are propagated to the appropriate desktop in the data center. It keeps local desktops current by distributing common system data from the data center to the local clients. If a local computer is corrupted or lost, View Transfer Server can provision the local desktop and recover user data by downloading the data and system image.
Deployment
In a typical VMware View deployment the data center houses, at a minimum, an HVD pool (Host Machine 2 in Figure 19), the View Connection Server, Active Directory, and vCenter Server. Each HVD in the pool is a VM and the pool itself is on a physically separate host machine. Another host houses the VMs on which the connection broker, Active Directory, and the vCenter Server are installed (Host Machine 1 in Figure 19). It is highly recommended that HVD pools and enterprise services be housed on different host machines.
The hypervisors in each host connect to separate storage and management networks marked black and blue, respectively. Note here that the endpoints in the campus or the branch connect to the already existing access network infrastructure, and the HVDs in the pool attach to the virtual switch installed inside the hypervisor. All the endpoints, HVDs, and DV server components are on the "green" network. Devices in the green network can reach each other using Layer 2 or Layer 3 connectivity. All the display protocol traffic originates and terminates between the endpoints and HVDs.
Figure 19 DV Connection Paths
User Virtualization
User virtualization solutions link a user's unique desktop configuration (or persona) with a generic, pooled desktop (persistent or non-persistent). Cisco VXI has validated three solutions for user virtualization:
•
•
•
Refer to the respective documentation links for information on installing and configuring these solutions. See the "Management and Operations" chapter of this guide for more information on creating and managing user personas.
Application Virtualization
Application virtualization "containerizes" and insulates applications from the guest operating system. This permits a single instance of a virtualized application to run across different Windows OS versions, and helps reduce the risk that any malware infecting a virtualized application will not escape the container to infect the OS or other applications. Virtualized applications are delivered to these "sand-boxed" containers from a central repository. VMware ThinApp can be used for application virtualization in View environments. ThinApp packages applications into single executable files, which can be run in isolation from the OS and other applications. This functionality enables applications to be run on different Windows platforms and/or user profiles. Refer to the vendor documentation link for information on installing and configuring this solution.
Desktop Layering
Desktop layering assembles user data, applications, and operating system at runtime to create a personalized desktop. Cisco VXI has validated the Unidesk desktop management for VDI solution for desktop layering. The Unidesk packages and delivers the OS and all application types as independent layers, and shares a single instance of each layer across multiple desktops for storage efficiency. Layering is useful for minimizing the number of gold OS images and for delivering applications that are difficult to virtualize. It is also ideal for departmental applications needed by small numbers of users that are too resource-intensive to virtualize. Refer to the vendor documentation for information on installing and configuring this solution. See the "Management and Operations" chapter of the guide for more information on using Unidesk in a Cisco VXI environment.
Storage
The Cisco VXI system supports both shared storage (NAS, SAN) and local storage). VMware highly recommends the use of shared storage resources for View deployments. Shared storage offers centralized security, high performance, resource sharing, and vMotion support. Shared storage systems are also used to host user data, personas, and profiles on CIFS.
Shared storage solutions are provided by ecosystem partners EMC and NetApp. Both solutions provide NAS-based and SAN-based storage connectivity options. Shared storage is often preferred for virtual desktop environments, as it facilitates use of advanced hypervisor features, and aids in desktop migration.
SAN storage arrays are broken down into several logical unit numbers (LUNs), also called partitions. Each LUN can be shared among several servers (and virtual desktops). However, isolation of the virtual desktops from other virtual servers into separate storage pools is highly recommended for security reasons and to help balance the storage traffic load. For NFS access, the array is broken down into separate file systems. Each is mapped by the hypervisor into local storage pools.
Cisco VXI General Guidance for Shared Storage
Storage traffic consumes network bandwidth. QoS policies and queue mapping should be employed for the remote storage traffic. See the "Quality of Service" chapter in this guide for more information. A storage VLAN should be created to isolate this traffic.
Since many different VMs share the same storage, aggregated traffic could exceed the available resources. If one virtual desktop runs an application consuming a lot of storage device I/Os, it could starve others relying on the same shared pool of storage resources. Segregating the shared resources according to virtual machine type, servers (for example, a web services machine), and virtual desktops can help eliminate this issue. See the "Performance and Capacity" chapter of this guide for details.
Configuring resource pools separately for each of the DV pools can avoid depletion of storage resources. The isolation of HVDs from general-purpose servers is best achieved by configuring segregated service profiles, each assigned to separate storage volumes.
The number of VMs assigned to a volume should not exceed the aggregate I/O bandwidth available to the specific volume. The configuration steps for this are part of the server template configured in DV management software. See the "Performance and Capacity" chapter of this guide for more information.
A wide range of storage optimization technologies are available from NAS/SAN storage providers, hypervisor vendors, and software appliance companies which may improve system performance, reduce overall storage requirements, and improve manageability. While a complete analysis of these solutions is beyond the scope of this document, Cisco VXI deployments may benefit from the use of non-persistent desktops, thin provisioning, hypervisor caching technologies, tiered storage, data deduplication, layering, and dedicated storage optimization appliances. Cisco VXI has validated the use of many of these solutions, as indicated throughout this chapter. System test results are reported in the Capacity and Performance chapter of this document.
Implementing EMC Unified Storage
The EMC Unified Storage solution provides advanced failover and fully automated storage tiering to virtual desktop environments. EMC Unified Storage solution can connect to multiple storage networks via network-attached storage (NAS), iSCSI and Fibre Channel storage area network (SAN). Cisco VXI system testing validated the EMC Unified Storage solutions for SAN deployments. Test results are shown in the Capacity and Performance chapter of this guide.
Design Solution to Performance Requirements
Planning and designing the storage infrastructure is a critical step in architecting a VDI solution. The shared storage must be able to absorb the bursts of input/output (I/O) that occur across the hundreds or thousands of users in your enterprise. A flaw in the design will lead to periods of erratic and unpredictable virtual desktop performance.
Many customers tend to ignore I/O requirements and design their storage solutions based strictly on capacity. In a virtual desktop environment, a small change in the I/O load can have a big impact on the storage. For example, a single desktop might execute 15-20 I/O operations per second (IOPS). In a traditional desktop environment an individual laptop or desktop hard drive can easily support a 15-20 IOPS workload. However when you deploy a virtual desktop solution across an organization, that same 15-20 IOPS workload multiplies very quickly to 15,000 - 20,000 IOPS. The storage solution that you deploy must be able to meet these demanding workloads. In a traditional storage environment customers would need to buy and provision hundreds of high-performance FC or SAS drives to meet these workload demands. To improve storage efficiency, EMC has developed the FAST Suite for VNX. The FAST Suite leverages flash drive technology to deliver the necessary IOPS required for thousands of desktops while simultaneously saving the space, power and cost of purchasing hundreds of FC or SAS drives.
FAST Cache, a part of the VNX FAST suite, is an extended read/write cache that can absorb read-heavy activities such as boot storms and antivirus scans as well as write-heavy workloads such as operating system patches and application updates. FAST Cache has array-wide features available for both file and block storage. FAST Cache works by examining 64 KB chunks of data objects on the array. Frequently accessed data is copied to the FAST Cache and subsequent accesses to that data chunk are serviced by FAST Cache. This allows immediate promotion of very active data to the flash drives. This dramatically improves the response time for very active data and reduces the data hot spots that can occur within the LUN. For additional information on FAST Cache please refer to the following white paper. http://www.emc.com/collateral/software/white-papers/h8046-clariion-celerra-unified-fast-cache-wp.pdf
To improve storage utilization and to simplify the management of virtual desktops, EMC supports VMware View Composer-based linked cloning. This technology allows IT administrators to quickly create thin copies of virtual machines (VMs) that share virtual disks with their master image. the operating system reads from the common read-only replica image and writes to the linked clone. Any unique data created by the virtual desktop is also stored in the linked clone.
The support of linked-clone technology enables rapid deployment of large numbers of desktops because administrators can provision a golden image and then easily clone and deploy it as needed. Because the clones are thin images, deployment time and storage needs are drastically reduced. For example, if a corporate OS image is 10 GB in size, to deploy 1,000 desktops will require 10 TB of disk space in a traditional thick provisioning deployment. EMC support of VMware View Composer provides a combination of thin provisioned storage and near zero capacity linked clone-based deployment mechanisms to rapidly deploy desktops at scale and drastically reduce storage needs by up to 90%.
While linked-clone technology reduces the storage requirement for desktop images, they have the opposite effect on I/O requirements. Each desktop must read its data off of a common base image. In cases such as boot storms, where all the desktops are reading data at once, the I/O that must be serviced by the common base image rapidly escalates to several thousand IOPS.
When using linked-clones and EMC FAST Cache, the combination of two Flash Drives and about 15 Fiber Channel drives delivers sufficient capacity to support over 1000 virtual desktops. During a desktop boot storm test, the system cache and the VNX FAST Cache (based on Flash Drives) absorbed over 40,000 IOPS and the desktops fully booted in less than 7 minutes. EMC has demonstrated similar performance benefits for virus scanning, patch updates and recompose operations. For additional information reference the following white paper: http://www.emc.com/solutions/application-environment/vmware/vmware-view-virtual-desktops.htm
Leverage Storage Efficiency
In addition to the IOP performance benefits of FAST Cache, EMC VNX has additional features that improve storage efficiency in a Virtual Desktop deployment. EMC FAST VP (Fully Automated Storage Tiering for Virtual Pools) works at the storage pool level, below the LUN abstraction and at a far more granular level than previous versions of FAST. FAST VP now identifies and monitors the entire storage pool in 1 GB chunks. When data becomes active, then FAST VP automatically moves only these "hot" chunks to a higher storage tier like Flash.
As data cools, FAST VP also correctly identifies which chunks to migrate to lower tiers and proactively moves them. With such granular tiering, it is now possible to reduce storage acquisition while at the same time improve performance and response time. For additional information on FAST VP please reference the following white paper http://www.emc.com/collateral/software/white-papers/h8058-fast-vp-unified-storage-wp.pdf.
EMC VNX storage also supports Block Data Compression, File Level Deduplication and File Level Compression, allowing customers to save space anywhere in their production environment. This capability makes storage even more efficient by eliminating duplicate data and compressing what is left. EMC recommends that these features be fully utilized when using the VNX for unstructured (file) data.
Ensure Scalability and Quality of Experience
Scalability presents a significant challenge to companies that are considering deploying a virtual desktop environment. Businesses that hope to achieve a flexible desktop infrastructure—one that can easily accommodate additional users and data—sometimes make the mistake of using a storage infrastructure that cannot scale to their growth needs. Without scalability, the user experience will degrade as new users are migrated to the environment.
When deploying Virtual Desktops across your enterprise it is important to leverage storage solutions that can scale without compromising performance. Technologies such as EMC FAST Cache ensure the quality of experience for your virtual desktop users under I/O intensive activities such as Boot or Login-in storms, Anti-Virus Scanning and OS patch updates. At the same time, the flash capabilities allow the array to easily scale without the expense of adding hundreds of new disk drives.
Implementing NetApp FAS3170 Storage
The NetApp FAS3100 Series is a unified storage solution that supports both SAN and NAS deployments. NetApp storage arrays are highly optimized for the heavy read and write workload typical of virtual desktop environments (see your product documentation for more information). Cisco VXI system testing validated the NetApp FAS3170 solution for file-based, network-attached storage. Test results are described in the Performance and Capacity chapter of this guide. The FAS3170 runs NetApp's Data ONTAP operating system, which provides SAN (FCoE, Fibre Channel, and iSCSI), NAS (CIFS, NFS), primary storage, and secondary storage on a single platform so that all virtual desktop components (e.g., VM OS, user persona, user data, applications, and data) can be hosted on the same unified storage array.
Storage Efficiencies
NetApp storage efficiency technologies, such as data deduplication, compression, and thin provisioning are designed to reduce storage requirements. These technologies deliver significant value in a dense solution architecture such as desktop virtualization, where they can be applied to reduce storage requirements of master desktop images, user data, and streaming applications. Collectively, features such as deduplication, thin provisioning, and FlexClone can reduce storage overhead by up to 90%.
Hardware Accelerated VM Cloning
NetApp provides array based, zero cost cloning available with FlexClone, which can be used for the immediate and space efficient deployment of virtual servers and desktops. For an overview of NetApp best practices for VMware View deployment, please see http://media.netapp.com/documents/tr-3915.pdf
Flash Cache
Flash Cache is a PCI Express card that can be installed many of the current NetApp storage controller systems. Each module contains either 256GB, 512GB, or 1TB of SLC NAND Flash. In the VMware View solution on NetApp, NetApp recommends having at least one Flash Cache device per FAS or V-Series storage cluster. Details on the number of modules per platform and the supported Data ONTAP versions can be found at Flash Cache Technical Specifications.
NetApp Write Optimization
Virtual desktop I/O patterns are often very random in nature. Random writes are the most expensive operation for almost all RAID types because each write operation requires more than one disk operation. The ratio of VDI client operation to disk operation also depends on the RAID type for the back-end storage array. In a RAID 5 configuration on a traditional storage array, each client write operation requires up to four disk operations. Large write cache might help, but traditional storage arrays still require at least two disk operations. (Some coalescing of requests happens if you have a big enough write cache. Also, there is a chance that one of the reads might come from read cache.) In a RAID 10 configuration, each client write operation requires two disk operations. The cost of RAID 10 is very high compared to RAID 5. However, RAID 5 offers lower resiliency (protection against single disk failure). Imagine dual disk failure in the middle of the day, making hundreds to thousands of users unproductive.
With NetApp, write operations have been optimized for RAID-DP by the core operating system Data ONTAP and WAFL® since their invention. NetApp arrays coalesce multiple client write operations and send them to disk as a single IOP. Therefore, the ratio of client operations to disk operations is always less than 1, as compared to traditional storage arrays with RAID 5 or RAID 10, which require at least 2x disk operations per client operation. Also, RAID-DP provides the desired resiliency (protection against dual disk failure) and performance, comparable to RAID 10 but at the cost of RAID 5.
Virtual Storage Tiering
NetApp dynamically responds to increases in I/O demands via the Virtual Storage Tiering capability. This function enables organizations to deploy virtual desktop infrastructures with inexpensive commodity hard drives and receive the performance levels traditionally found with expensive solid state drives. VST is deduplication-aware, and will increase the performance of solutions incorporating deduplication and hardware-accelerated cloning. VST is modularly expandable and provides configuration flexibility.
Data Protection
NetApp offers RAID-DP, specifically designed for shared virtual infrastructures. RAID-DP provides data protection and performance greater than that of RAID 10 and is less expensive, in terms of RAID overhead, than that of the RAID 5. RAID-DP simplifies desktop architectural designs as it eliminates the possibility on one implementing the wrong type of RAID.
Virtual Storage Controllers
NetApp provide virtual storage arrays in the form of vFilers. With vFilers administrators can non-disruptively migrate a production desktop or user environment between storage controllers for purposes such as performance leveling, data center maintenance, and hardware life cycle management. Once a virtual environment is configured it is no longer tied to a physical controller. vFilers also simplify disaster recovery designs, as the array identity remains persistent even when running on different hardware.
Multiprotocol and Unified Fabric Adapter
These adapters simplify connectivity to various data sets. Every NetApp array is capable of providing the storage protocols required for a robust virtual desktop deployment ranging from FCoE to NFS, to SMB2.
Integrated Data Protection
NetApp arrays support both immediate hardware accelerated snapshot backups and deduplication-aware replication. These capabilities are available and integrated with the NetApp backup plug-in for the Virtual Storage Console.
Local Storage
Cisco UCS B-Series and C-Series servers offer a range of local storage options, such as SAS, SATA, and SSD, for organizations that do not need or want a central shared storage solution. Cisco VXI has validated the Cisco UCS C250 M2 (which supports up to 384G total) in two local storage configurations - (1) 5 x 100 GB SSD and 3 x 300 GB SAS drives, and (2) 8 x 300 GB SAS drives. Cisco VXI also has validated the Cisco UCS B230 with local storage. Both Cisco UCS models were tested with the Atlantis ILIO appliance (see below). Refer to "Performance and Capacity" document for details.
Atlantis ILIO
Atlantis ILIO is a storage and performance optimization software solution that integrates with Desktop Virtualization offerings to cut storage costs, provide IT teams with lower cost storage options, and boost desktop performance. Atlantis ILIO is a unique and innovative storage optimization technology that fundamentally changes the scalability, performance characteristics and economics of desktop virtualization by intelligently optimizing how the Microsoft Windows operating system interacts with VDI storage. Atlantis ILIO increases the number of virtual desktops that can be run on a storage system by 4 to 7 times, while at the same time boosting desktop performance, reducing the amount of storage capacity required for virtual desktop images and enabling customers to use lower cost storage options. During system testing, Atlantis ILIO was deployed on each server with direct attached storage. Test results are discussed in the Cisco VXI Performance and Capacity Validation Results Guide for VMware document. Cisco tested the Atlantis ILIO with the following key features/capabilities enabled: Inline Deduplication and IO Offload.
Storage IO Traffic Reduction with Software Processing
The Windows operating system was designed to operate with a dedicated local drive that frequently accesses storage for tasks that have nothing to do with storing unique data. With shared storage, each virtual desktop must traverse multiple switches each time it reads and writes data to disk. This process can increase latency and decrease desktop performance. Atlantis ILIO presents the hypervisor with a virtual hard drive (.VMDK or .VHD file) that processes Windows NTFS IO traffic locally in memory on the same rack (in a Top-Of-Rack deployment) or the same hypervisor (on an Each-Server Deployment), making the virtual desktop's hard drive much faster and offloading up to 90% of IOPS from the storage system.
Inline Deduplication of VDI Workloads
Atlantis ILIO performs deduplication in real-time on-the-wire, before any IO transactions reach the storage fabric. By eliminating up to 90% of IO traffic, the IOPS requirement for the storage infrastructure decreases by a similar percentage. At the same time, because no duplicate data is written to disk, post-process deduplication is not required, and the associated IOPS and storage capacity cost is never incurred.
Increase Storage Choices
In additional to reducing storage capacity and increasing the number of virtual desktops per disk, Atlantis ILIO makes it possible to choose from a broad range of storage options for HVDs including Cisco UCS local disks (SATA, SAS, SSD), and NAS or SAN from Cisco validated storage partners NetApp and EMC. Atlantis ILIO makes it possible for customers to use very small amounts of local disk storage available on the Cisco UCS platform (SATA, SAS, SSD) for the operating system and application base image, while maintaining user data on shared SAN/NAS (EMC Celera NS480, NetApp FAS3170). When using Atlantis ILIO in this hybrid Cisco UCS DAS and SAN/NAS storage environment, the base virtual desktop images are stored using local SATA, SAS or SSD drives, while the unique user data is stored on traditional SAN/NAS storage.
Optimizing IO Traffic - From Random to Sequential
When the Windows operating system generates disk IO, it optimizes that IO on its local hard drive so that blocks are stored sequentially for optimal performance. With virtual desktops, the hypervisor converts sequential IO into small blocks of random IO (the IO Blender effect), which decreases storage and desktop performance. Atlantis ILIO converts the small block random IO generated by the hypervisor into larger blocks of sequential IO to send to storage, improve storage (EMC and NetApp) performance, and maximizing the opportunity to deliver all requested data locally from memory.
Storage Area Networks
Fibre Channel storage arrays are attached to members of the Cisco MDS family of switches. The Cisco MDS switches allow multiple arrays to talk to multiple hosts (servers) in much the same manner as an Ethernet switch. The Cisco MDS switch connects to Fibre Channel uplinks on the Cisco UCS Fabric Interconnects. Traffic is encapsulated by the Cisco UCS Fabric Interconnect into FCoE frames and passed to the server's Virtual Interface Cards, where it is converted back into Fibre Channel packets and presented on the vHBA.
Fibre Channel connections typically operate in an active or standby mode. If SAN A is the primary array, SAN B is a mirror copy. In some cases, depending on the storage array vendor, the uplinks from Cisco MDS switch A and Cisco MDS switch B may point to the same array. However, a particular logical unit number (LUN) will show up on only one of the interfaces at a time. For traffic load balancing, the user should mix the LUN assignments across the two SANs.
Figure 20 Storage Area Networking
Network-Attached Storage
With network-attached storage, traffic originating from the NFS server is switched as Ethernet traffic to the storage array via the Cisco Nexus 5000 or 7000 Series Switches. The Nexus switches provide a universal platform for diverse data center needs, facilitate network consolidation, and enable a seamless transition from traditional to advanced technologies. Like Fibre Channel attached storage, the remote array is mapped to a local hypervisor storage pool, and the hypervisor provides virtual desktops with simulated local storage. Since this is Ethernet-based, storage is assigned to a separate storage VLAN. In most cases, the storage array is placed in the same VLAN. This alleviates the need for the hypervisor or DV virtual machines to have multiple default routes, which can cause network issues.
Figure 21 Network Attached Storage
Integrating Servers, Switches, Storage, and Hypervisor
Figure 22 shows a server with a pair of interface cards installed and the logical connections made within the server. Each interface card presents to the server Fibre Channel Host Buffer Adapters and Ethernet NICs. When the vSphere hypervisor is installed, the Fibre Channel HBAs are mapped to virtual HBAs, which can be used for attaching remote storage. The Cisco Nexus 1000V Series is not aware of the HBAs since they are not mapped into the internal virtual Ethernet framework. The Ethernet interfaces are mapped to the Cisco Nexus 1000V virtual switch. The Cisco Nexus 1000V Series treats these as uplink ports. They are usually configured as trunk ports and connected through EtherChannel for redundancy and load balancing.
Internal to the Cisco Nexus 1000V Series, several virtual interfaces (vETHs) are created. One is reserved for the kernel traffic (connection to vCenter) and is put into a separate VLAN and assigned a unique IP address. A second one is reserved for vMotion, and again placed in a separate VLAN and assigned a second unique IP address. Neither of these interfaces is seen by the virtual desktops. For security reasons, the virtual desktops do not have access to these VLANs. One final reserved vETH may be created if the vSphere hypervisor datastore is connected via Ethernet-based storage (NFS). The Ethernet-based storage traffic should also be isolated into its own VLAN.
Additional VLANs will be created for the virtual desktops. The IP addresses may be statically defined or acquired via Dynamic Host Configuration Protocol (DHCP). The addresses assigned and subnet mask needs to be created according to the size of the virtual desktop pool. Virtual desktops can migrate only within the same pool (subnet, VLAN, and so on). For each virtual desktop, only a single vNIC needs to be created. It is possible to have virtual desktops from different pools running on the same physical server. The configuration for the trunk ports needs to include all possible VLANs, including the ones for the allowed virtual desktops. The Cisco Nexus 1000V Series will create an EtherChannel across the two CNA (NIC) interfaces, so loads on each interface should be monitored to ensure the appropriate load balancing algorithm was selected.
The Cisco Integrated Management Controller is forwarded internally to the UCS Fabric Interconnects. The Cisco UCS Manager assigns and manages that interface. The IP address assigned to the Cisco Integrated Management Controller must be on the same subnet as the UCS Manager. This is the address that will be used for remote KVM and server maintenance.
The VMware vKernel interface will be used to communicate with vCenter. The IP address should be assigned to a separate VLAN from the Cisco Integrated Management Controller interface. This VLAN should be routable to the vCenter server's VLAN.
The vMotion interface is used for virtual desktop mobility. It also should be assigned to a separate VLAN that is common to all the servers within the same virtual desktop pool. This network does not need to be extended beyond the access layer, since vMotion is a not routable protocol. vCenter will use the vMotion interfaces on the servers (and the associated VLAN) for the traffic flow needed to migrate the virtual desktop. Because the virtual desktop's storage is maintained remotely, only the contents of RAM (the CPU state) of the desktop are transmitted.
Figure 22 Cisco VXI Data Center Connectivity
Table 3 List of Required VLANs for Cisco VXI Deployment
For the virtual desktops, as shown in Figure 23, the traffic flows include:
1.
2.
3.
4.
a.
b.
c.
Figure 23 Virtual and Physical Traffic Flows
For More Information
See the links below for more detailed information regarding specific vendor information including hardware and software discussed in this chapter.
Cisco Data Center Design Zone
http://www.cisco.com/en/US/netsol/ns743/networking_solutions_program_home.html
Best Practices in Deploying Cisco Nexus 1000V Series Switches on Cisco UCS B Series Blade Servers
http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/white_paper_c11-558242.html
EMC Solutions for VMware View
http://www.emc.com/solutions/application-environment/vmware/vmware-view-virtual-desktops.htm
EMC Infrastructure for VMware View
http://www.emc.com/collateral/hardware/technical-documentation/h8283-view-vnx-vsphere-psg.pdf
Top 5 Reasons Why Customers Deploy VMware View on EMC VNX Storage
http://www.emc.com/collateral/software/15-min-guide/h8532-top5-deploy-vmware-view-uni-stor.pdf
Deploying Microsoft Windows 7 Virtual Desktops with VMware View - Applied Best Practices
http://www.emc.com/collateral/software/white-papers/h8043-windows-virtual-desktop-view-wp.pdf
Deploying Microsoft Windows XP Virtual Desktops with VMware View - Applied Best Practices
http://www.emc.com/collateral/software/white-papers/h7168-performance-optimization-windows-xp-vdi-wp.pdf
Atlantis ILIO for VDI
http://www.atlantiscomputing.com/atlantisiliovd
NetApp TR-3298: RAID-DP: NetApp Implementation of RAID Double Parity for Data Protection
http://media.netapp.com/documents/tr-3298.pdf
NetApp TR-3347: FlexClone Volumes: A Thorough Introduction
http://media.netapp.com/documents/tr-3347.pdf
NetApp TR-3437: Storage Best Practices and Resiliency Guide
http://media.netapp.com/documents/tr-3437.pdf
NetApp TR-3505: NetApp Deduplication for FAS, Deployment and Implementation Guide
http://media.netapp.com/documents/tr-3505.pdf
NetApp TR-3563: NetApp Thin Provisioning
http://media.netapp.com/documents/tr-3563.pdf
VMware VSphere Documentation Page
http://www.vmware.com/support/pubs/vs_pages/vsp_pubs_esxi40_i_vc40.html
Atlantis ILIO for VDI
http://www.atlantiscomputing.com/downloads/VDIStorage_SolBrief_020411.pdf
VXI Network
VXI Network Introduction
The network design for Cisco VXI system is based on Cisco's best practices for deploying campus, WAN, and data center network infrastructures. VXI network design, however, needs special considerations around the virtual desktop display protocol, UC and peripheral traffic to create a better user experience, no matter where the user is located in the network. This chapter discuses these network considerations. As depicted in the figure below, the display protocol traffic delivered over the network needs to be optimized and secured. Further, the need for the network to provide high availability of the virtual desktop and other applications in the data center is even higher; especially since all enterprise productivity now depends on it. The VXI system optimizes the network by providing QoS guidelines and capabilities for virtual desktop traffic and also optimizes traffic over the WAN for Branch or Mobile access scenarios. The definition of availability can be based on an IT organization's business objectives and measurements. The different types of availability include availability of devices, media interfaces, and paths, and availability of the network to users and applications. Availability in VXI system is achieved by relying on Cisco's network best practices that make network path available through downtimes or upgrades and by ensuring that virtual desktop services in the data center are healthy and available. Network security is covered in detail in the "Cisco VXI Security" chapter.
Figure 24 Functional Flow for a DV Network
VXI Network Components
The diagram below shows the three VXI deployment use cases. Virtual desktop users can be in the Campus headquarters, a small/medium/large Branch or be Fixed or Mobile teleworkers. No matter the location of the users the expectations from the Network remain the same. The diagram also walks through all the components and network areas a VXI administrator should focus on to deliver good user experience. The rest of the chapter discusses the VXI design requirements for the above scenarios and the components that are required in the network at various locations.
Figure 25 Key Components for Enabling VXI Networks
The campus network connects end users and devices in the corporate network with the data center, WAN, and Internet. The campus network also provides access to end hosts over trusted enterprise network. In this release of Cisco VXI we discuss the design best practices for connecting the endpoint to the first hop switch, since this is where all the endpoint services are delivered. The rest of the Campus network, starting from the first hop switch all the way to the Data Center edge, is recommended to be deployed using Cisco Enterprise Campus 3.0 Architecture and is assumed to provide high-throughput, low latency and always available connectivity needed for good VXI user experience. In addition to the high-speed connectivity, the VXI campus network, with its direct interaction with end users and devices, must provide a rich set of services, such as Power over Ethernet (PoE), secure access control using IEEE 802.1x, intelligent and dynamic provisioning of VXI endpoints into the correct VLANs with appropriate QoS/Security policies, assist in location tracking of the VXI endpoints, traffic monitoring and management. To enable above services VXI endpoints inside the campus should be connected to a wiring closet switch such as Catalyst 4K, 3K or 2K.
Powering the Endpoints
Today, Power over Ethernet technology is mostly associated with IP Telephony because of its ability to provide high availability, high efficiency and easy manageability for power. High availability for power is critical for E911 type of applications and so it is mandatory in many enterprises to power IP telephones over PoE. With the introduction of PoE+ and Universal Power Over Ethernet (UPoE) capable VXI clients, enterprises now have the opportunity to transition the entire employee work environment to single power source, adding significant savings on wiring and energy costs. With transition to VXI PoE today, enterprises will be enabled to use advanced workplace power policy applications in the future such as Cisco Prime LMS 4.x. Further details on these applications can be found in the Management and Operations chapter of this Guide. With PoE+ (IEEE 802.3at, 30W) scalability and a rich road map extending PoE+ technology beyond 30W, Cisco Catalyst 4500E, Catalyst 2000S and Catalyst 3000-X are the recommended campus access platforms for VXI. For VXI deployments looking to serve data and power on all devices through a single cable, UPoE is highly recommended since this technology has the potential to deliver up to 60W per device. Cisco UPOE leapfrogs the industry to provide 60W PoE per switch port to enable new deployment options in next-generation workspace environments and is available today on Catalyst 4500E switches (WS-X4748-UPOE+E line card). Catalyst 4500E is well suited for large enterprise with its support for 240 simultaneous PoE+ port. Catalyst 3000-X with stack support and Catalyst 2000-S series are perfectly suited for medium and small enterprises.
Cisco VXI validated the use of a Catalyst 4500E switch with the UPOE line card (WS-X4748-UPOE+E) module for desktop virtualization environments. The system used the UPOE-capable switch along with a splitter to deliver power to both a Cisco VXC zero client (with keyboard and mouse), and a 12V DC video monitor. This configuration, shown in Figure 26, offers several advantages. The splitter enables the client and monitor to share a single UPOE port, which reduces the number of ports necessary to power the endpoints. This setup also simplifies wiring, eliminates the need for multiple power outlets, improves availability, and consolidates backup power. Overall savings can be significant when deployed on a system-wide basis, and is easier to manage with tools such as an EnergyWise compatible management application
One important design point to note is that the splitter does not support the negotiation protocols that native PoE/UPOE devices use to set power levels. The switch port that connects to the splitter needs to be configured in "Forced Mode" to ensure that 60 watt UPOE is delivered to the splitter. The splitter provides two connections for end points - a standard Ethernet connection that supports both data and power, and a DC connection that delivers power only. The splitter can be used in either of two modes. In passthrough mode, power (up to 51 watts) is divided between the connectors. The Ethernet cable transports both power and data. In non-passthrough mode, the Ethernet connection is data-only, and the DC connection delivers all available power. The mode is determined by the power requirements of the endpoints to which the splitter is connected.
Figure 26 Cisco VXI System with UPOE
Automatic Port Provisioning
The Auto Smartports enable the switch to dynamically provision VXI clients by automatically configuring a port based on device identification obtained through CDP or MAC addresses. Smartport macros are pre-created customizable configuration scripts based on Cisco best practices that allow administrators to easily configure common switch port configurations. Auto Smartports feature helps to attain consistency in the network in terms of policies used for Security, QoS and High Availability.
With Auto Smartports, the macros are applied automatically by the switch based on end point credentials. The configuration is removed when the link to the end point is dropped or when the user session is terminated. For example, when a Cisco IP phone is detected by the switch on a port, an IP phone macro is applied which configures the voice VLAN, Port Security and setups QoS policy. This same level automation can be achieved for VXI endpoints. In the current release the process is manual only (called Static macro) and the support for automatic VXI endpoint detection is being added to future releases. The automatic macro deployment is dependent on the VXI endpoint identifying itself to the switch, unlike, Cisco IP phone that uses CDP to accomplish this VXI endpoints today don't have any such self identification support. For a VXI system it is recommended to turn on AutoSmartPorts feature to detect Cisco IP phones and create a Static MAC based macro for VXI endpoints. Deployment guidance for Auto/Static macros in VXI system is discussed in the next section. Cisco Catalyst 4000E and Catalyst 3000-X switch platforms support both types of macros.
QoS
The display traffic is encapsulated in vendor proprietary protocols. These protocols are non-standard protocols that can't be deciphered by network elements on their path, making them Opaque to the network, limiting the critical value added services networks can provide to VXI. Although the display protocol is Opaque to the network, some level of QoS services at Layer 3 level can still be applied to this traffic collectively. Further, since Voice traffic is brought out of the display protocol by Cisco VXI, QoS on voice traffic is a requirement to achieve good user experience in VXI system. For details on end-to-end VXI QoS guidelines please refer to the Quality of Service chapter of this guide.
Securing Endpoint Access
Although the display protocol may be opaque to the Campus, the Cisco Catalyst® family of switches can still provide security and availability functions in a Cisco VXI system-enabled network. This functionality enables some DV traffic types to be characterized and secured based upon log-in characteristics. For example, contractors may use their own laptops, with the contractor's virtual desktop accessed using a thin client. When the contractor connects to the network, he/she will login using the laptops username/password and be authenticated using 802.1X. The Catalyst switches can map that user into a discrete contractor VPN with ACLs that enable access to the Internet for VPN traffic and connectivity to only the contractor desktops. The Cisco Catalyst 4500 E and Catalyst 3000-X switches provide 802.1X and port security features to provide endpoint level security. The deployment and design details for these security centric features are covered in the Cisco VXI Security chapter of this guide.
Location - Endpoint Tracking
Network Mobility Services Protocol (NMSP) provides the capability to determine the physical location of a host in the network. This provides the ability to track assets for inventory as well as compliance. Access switches, such as the Catalyst 4500E and Catalyst 3000-X, provide the wired location service feature and transmit location information of connected endpoints to the Cisco Mobility Services Engine (MSE). Cisco MSE is an appliance-based platform for delivering mobility services in a centralized and scalable fashion across wired and wireless networks. In the case of a wireless connection, the access point (AP) tracks and transmits location information of its connected VXI endpoints to the MSE via the Wireless Control System (WCS). The WCS is the management platform for location services and tracks devices, allows setting up of event notifications, and alarms based on the location triggers. The actual location information of the Switch/AP and the ports on the Switch are configured in the Switch/AP itself.
Figure 27 Location Tracking Topology in VXI
Device information such as MAC address, IP address, Serial number, Unique Device Identifier (UDI) and model number can be obtained by the Switch or the AP. The Switch learns the information of the connected VXI endpoint using CDP/LLDP-Med or ARP snooping. The AP learns the information above using standard wifi WiFi registration exchange. Current VXI endpoints don't support CDP/LLDP-Med so only ARP snooping is used to learn the IP address and MAC address of the endpoint on wired switches and wifi endpoint registration sequence on wireless APs. Switches and APs also transmit state information such as Device Category (Wired/Wireless), Time of attachment, Operational state (Connected/Disconnected). MSE holds the location database and in this release of VXI, a manually maintained list of MAC addresses tied to each enterprise client. If the device location needs to be mapped to the User, another manually maintained database of user to MAC ID mapping needs to be maintained. All models of Cisco switches and Cisco Access Points support location services natively and can be used in VXI. However, as part of Cisco VXI only Catalyst 4500E and Catalyst 3000-X were validated. For details on how the switches, APs and WCS is configured with functionality please refer to Deployment Models section.
Campus Access Availability
All productivity applications in a VXI system are centralized inside the data center, the end user is completely dependent on the network to perform even the basic daily tasks. The VXI system requires the underlying network to be always available starting at the point of attachment, i.e. the access switch. Even very small down times can result in significant loss of productivity. As one of the key design requirements, all network components that carry VXI traffic must be highly redundant and available in an event of equipment failure or upgrade/downgrade process.
Cisco Catalyst 4500E in redundant configuration with dual supervisors allows Cisco IOS software to be upgraded or modified while packet forwarding continues using the In-Service Software Upgrade (ISSU) feature. This increases network availability and reduces downtime caused by planned software upgrades. The ISSU feature allows for a non-disruptive user experience during a planned upgrade or modification. The ISSU process with Supervisor 7E is reduced to a single line command and the traffic hit is less than 10 milliseconds. The VXI session in terms of Power over Ethernet (PoE) and data plane stays up during the ISSU process.
Cisco VXI in the Branch
This release of Cisco VXI focuses heavily on making the Branch network functions for VXI traffic. WAN presents a number of challenges and the branches are where enterprises can benefit from VXI.
Dynamic VPNs in Cisco VXI
Branch to Campus WAN connectivity can, in many cases, be over untrusted WAN links. Further, some traffic originating in a multi-branch environment can be destined for another Branch in the enterprise network. An example is Cisco IP phone traffic when a user in one branch calls a user in another branch. Normally, the voice traffic in the above example will be forwarded to the Campus and then routed to the second branch. From an Enterprise perspective, this can possibly add to bandwidth costs and even more importantly cause extra WAN delays resulting in bad user experience. Based on the above, a solution that can dynamically create and tear down encrypted tunnels based on traffic destination is a requirement. DMVPN fills this need by providing best combination of performance, scale, application support, and ease of deployment. In Cisco VXI system, the virtual desktop display traffic will almost always be from Branch to Data Center and Collaboration traffic can be peer to peer between the branches. DMVPN serves both security and optimized route selection requirements and is recommended.
The DMVPN routers use GRE based tunnel interfaces that support IP unicast as well as IP multicast and broadcast traffic, including the use of dynamic routing protocols such as EIGRP. After the initial
spoke-to-hub or Branch to Campus tunnel is active, dynamic spoke-to-spoke or Branch to Branch tunnels are created depending traffic flow requirements. DMVPN uses Next Hop Resolution Protocol (NHRP) to find other spokes based on IP destination prefix in the flow. The spoke-spoke or Branch-Branch tunnels are encrypted using IPSec. If there are any idle connections between the branches, created due to historical traffic flows, they are timed-out. Internet Security Association and Key Management Protocol (ISAKMP) is a requirement for DMVPN to allow fast re-convergence. Without active Dead Peer Detection (DPD) using ISAKMP, unused tunnels or orphan tunnels (in an even of Peer reload) can take up to 60 minutes before time-out. IPSec tunneling is also required when DMVPN hubs are behind firewall implementing Network Address Translation (NAT). Since the tunnels are created behind the physical interface, branch routers configured for DMVPN can use the DHCP address provided by the service provider. The DMVPN hub, however, must have a static IP address so all Branch routers can be created in the initial spoke-hub tunnel.
As it is explained later in the chapter, WAN optimization is a highly recommended component for good Cisco VXI user experience. WAN optimization along with DMVPN can be deployed successfully but some configuration best practices need to be followed. These are also discussed later in the chapter. An excellent resource for DMVPN and Cisco WAN deployments in general is located at the link below. It is recommended to understand this document completely before starting any VXI over WAN implementations:
http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns742/ns982/c07-610746-02_wanDeploy.pdf
All other key resources specific to Cisco DMVPN are located at http://www.cisco.com/en/US/products/ps6658/index.html
WAN Optimization for VXI Traffic
Delivery of interactive multimedia, such as voice and video, is one of the biggest challenges in desktop virtualization deployment. Display protocols are not optimized for interactive multimedia delivery, especially in a WAN environment. This causes challenges in extending desktop and application virtualization to the branch office or even teleworkers. The primary challenge with the delivery of hosted virtual desktops to branch offices is the ability to ensure adequate levels of performance over the WAN that meets the end-users experience expectations. When delivering hosted virtual desktops over the WAN the end-user traffic has to cope with the following characteristics:
•
•
•
Further, even the smallest branch offices have printers. Most branch offices do have print servers, as they use embedded printer servers from vendors. For the branch office that does not have any print server or embedded printer server when a document has to be printed at the remote office, the rendered document print job is spooled over the WAN from the data center to the user's local printer. Print traffic is very chatty and consumes a large amount of bandwidth if not natively compressed. Such traffic types compete with real time high priority traffic for already limited bandwidth resources. A WAN optimization solution that can handle DV traffic, Real time traffic and other such non-priority peripheral traffic is a requirement for VXI Branch/Teleworker deployments.
The branch-office Cisco WAAS deployment, together with the data center Cisco WAAS deployment offers a WAN optimization service through the use of intelligent caching, compression, and protocol optimization. When end users access the virtual desktops through the connection broker, Cisco WAAS compresses the response and then efficiently passes it across the WAN with minimal bandwidth use and high speed. Commonly used information is cached at both the Cisco WAAS solution in the branch office and the data center, which significantly reduces the burden on the servers and the WAN.
Cisco WAAS provides a holistic approach to supporting a variety of print strategies, including Centralized network printing through a print server that can dramatically improve printing performance and reduce WAN data by using print-specific optimizations. Cisco WAAS provides print servers locally to branch-office users by running Microsoft Windows print services. Combined with USB redirection, Cisco WAAS offers optimization of the printing traffic redirected to locally attached peripherals (such as USB-connected printers) at the branch client device by reducing the bandwidth utilization and mitigating the WAN latency. Deploying WAAS on existing Branch WAN connection also helps salvage bandwidth. WAN optimization should not be thought of as just a requirement for VXI. Most practical VXI deployments will be done on existing branch network infrastructures. Deploying WAAS there will allows the salvaging of bandwidth on the WAN by optimizing both VXI and non VXI traffic. This may result in cost savings on new bandwidth purchases.
Protocol optimization is possible because network appliances have the ability to understand the protocol and terminate the user's requests. Protocol optimizers open a separate connection to the server. Some network protocols used in a Cisco VXI system apply methods of encryption and compression. For a protocol optimizer to be able to terminate and optimize a user's request, the network appliance will need to understand the methods of encryption or compression.
Cisco WAAS accomplishes all the WAN optimization functions using a suite of technologies listed below.
•
•
•
Optimization of desktop virtualization protocols, including Remote Desktop Protocol (RDP) is achieved by applying DRE, LZ and TFO techniques. It is important to note that WAAS works only with TCP transport as of now with possible future support for UDP transport. This means that protocols that use UDP transport cannot benefit from using WAAS. However, combined with reduction in bandwidth consumed by chatty protocols even UDP traffic can see noticeable benefits.
A list of WAAS technologies applicable to various types of applications and traffic types seen in a VXI system is presented in the Table 4 below.
Table 4
Traffic Types
Delivery of interactive multimedia, such as voice and video, is one of the biggest challenges in desktop virtualization deployment. DV vendors today struggle to provide a good user experience for voice and video applications within the display protocol. The Teradici PC over IP (PCoIP) protocol used by VMware View provides network and performance optimizations to deliver the best user experience over any network for interactive multimedia. The PCoIP protocol uses TCP and User Datagram Protocol (UDP) over port 4172. The TCP port is used for session establishment and control, while the UDP port is used for the display protocol. The display protocol is encrypted with 128-bit Advanced Encryption Standard (AES) or 256-bit Salsa20 encryption. The software implementation of PC over IP (PCoIP), one of the display protocols used by VMware View uses TCP and User Datagram Protocol (UDP) over port 4172. The TCP port is used for session establishment and control, while the UDP port is used for the display protocol. The display protocol is encrypted with 128-bit Advanced Encryption Standard (AES); when used in its hardware implementation, it can use AES or Salsa20. Cisco's WAAS cannot optimize UDP packets and therefore just passes the packet through. Therefore WAAS can apply network optimization only for PCoIP session establishment and control session.
VXI deployment almost always causes the need for a WAN upgrade for supporting users across the enterprise WAN. WAN upgrade costs can be reduced by 75% or sometimes more with the deployment of Cisco WAAS.
Context Aware WAAS 4.5
Cisco WAAS 4.5 provides significant performance improvements for VMware View users using MMR, USB and RDP desktop session protocols. The unidirectional caching improvements reduces disk usage, reduce CPU load and increases the scalability of the WAAS. WAAS is a comprehensive WAN optimization approach as it optimizes all types of WAN traffic voice, video, print, file system including desktop session traffic. The combined benefits of these two features include improved bandwidth utilization and improvement in user experience for VXI users.
Application Aware DRE
Advanced compression efficiency using context aware DRE reduces disk space and memory usage resulting in greater scalability and performance of the WAAS appliance. This feature is available in WAAS 4.4 and 4.5 release. Context aware DRE supports two features: unidirectional DRE and single instance of data. These two features can greatly benefit the optimization of desktop session traffic which can be optimized by WAAS and is unidirectional in nature.
The unidirectional DRE feature improves efficiency of caching by eliminating caching of unneeded data on the sending side WAAS. For specific traffic, cache data is only maintained on the receiving side WAAS where it is needed for de-compression. The sending side WAAS appliance will not maintain a copy of this data as it is not likely that the same data will flow in the reverse direction. This feature can provide benefits to traffic that is asymmetrical in nature like desktop session traffic. In the event that the same data flows in the reverse direction, this data will not be optimized on the first transmission but will be optimized on subsequent transmissions. For asymmetrical traffic, this event is unlikely and should not incur a significant impact on performance. Note that traffic classification is necessary to indicate to WAAS which traffic requires unidirectional cache versus which traffic requires bidirectional cache. See the deployment guidelines section for more information on deploying this feature.
Single instance of data further improves the caching efficiency by eliminating multiple copies of same data for multiple connections across multiple branches. This feature reduces memory and disk space usage resulting in greater scalability performance of the WAAS appliance. It allows WAAS to optimize data across user sessions, and will benefit scenarios where the same desktop session data is being transmitted to multiple users. (like an audio or video stream for example) This feature demonstrates the distinct advantage VXI has of performing the optimization in the network (by offloading the task from the endpoints and servers). This feature is enabled with both unidirectional and bidirectional DRE.
Note
WAAS 4.5 is compatible with VMware View versions 4.x and 5.x and the all the VXC clients (VXC 2x00, VXC 4000 and VXC 6215).
Deploying WAAS
Since WAAS is transparent in the network, some form of network interception is required to redirect relevant traffic types to the Cisco Wide Area Application Engine (WAE). Cisco WAAS supports many methods of network interception. The following two methods are recommended with the Cisco VXI system.
•
•
In the example branch office setup depicted below, the Cisco WAE appliance is connected to a local router, typically a Cisco Integrated Services Router (ISR) and in the Data Center Cisco WAAS is connected to a Data Center WAN edge router, typically an Aggregation Services Router (ASR). The branch router intercepts the traffic from VXI endpoints and sends it to the attached WAE, which after optimizing sends it out the Data Center WAN edge router. The DC WAN edge router intercepts the traffic and sends to Cisco WAAS Core for optimization, from where the traffic reaches the data center.
Figure 28 WAAS Deployment in The Branch Network
The WAAS deployment can be managed using WAAS Central Manager or Cisco Prime LMS. VXI system recommendation is to use WAAS Central Manager for its ease of use.
Multiple form factors for Cisco WAAS are available for deployment and are listed below. Network designers can pick and choose any form factor independently from a interoperability perspective, unless noted otherwise. All the WAAS models will work with the DC/Campus WAAS WAE headend appliance and the choice of branch or DC equipment is based on scale needed and the version of software chosen. Detailed WAAS sizing guidelines can be found at: http://tools.cisco.com/WAAS/sizing
Table 5 WAAS Form Factor
WAN Fluctuations and Path Optimization
Fluctuating WAN services provided by the Service Providers can have detrimental impacts the user VXI experience. Branches usually deployed with multiple load balanced WAN links with some links offering different SLAs and cost basis along with different delay, jitter and loss characteristics. Some of the links may randomly offer the performance required by VXI while others may not. Customers are interested in insulating their applications from such network fluctuations but at the same time do not prefer to deploy an active and standby WAN links in their branches due to the cost implications of unused bandwidth. Cisco offers Performance Routing (PfR) features on the routers to ensure that VXI users are not impacted by the issues of the network, especially when other paths are available that can provide the WAN performance required for VXI.
Performance Routing (PfR) improves application performance by selecting the best path across the WAN. PfR takes into account network metrics such as application reachability, delay, loss and jitter to help select the best path based on the application needs. It measures the network performance and dynamically re-routes the traffic when the metrics do not meet the application needs. PfR thus provides path optimization and advanced load balancing for VXI traffic over the WAN.
PfR and WAAS both provide different forms of WAN Optimization and working together can complement each other to provide even better VXI experience over WAN than alone. Cisco WAAS improves performance with data-reduction, compression and TFO techniques and works by reducing the bandwidth needs on the WAN. However, WAAS, unlike PfR, does not help with fluctuating network performance and so VXI performance can still be impacted. Further, if cost-based link policies are used with PfR, it can help enterprises reduce operational costs.
PfR has two logical components, a Master Controller (MC) and a Border Router (BR). The MC acts as a central processor and data collection point for PfR and can be running on the router or in standalone mode. MC gathers network metrics from all the BRs and determines adherence of traffic classes to the configured policy. Based on the determination it can instruct the BR to stay on the current WAN link or change the traffic path (if available). The execution is done on the BR by using route injection or dynamic policy based routing injection. In a small deployments the MC can be deployed on the BR itself.
PfR operates in three logical steps:
Step 1
This is done by using a combination of traffic class, port, protocol, src/dst prefix information. For VXI traffic TCP/UDP ports can be used to identify the display protocol traffic.
Step 2
This is done either passively by using Netflow based monitoring on the BR or actively by sending network probes to measure health of the WAN link. Both methods can be used together for better accuracy.
Step 3
This is done either using traffic class optimization or link optimization. For VXI traffic, traffic class optimization is recommended since the aim is to improve the performance of a specific traffic type. Link based optimization optimizes based on link cost and will result in optimum load balancing of multiple traffic flows. Link cost optimization is the primary focus for this approach.
Please see the "Deployment and Configuration Best Practices for VXI Network" section later in this chapter for VXI specific PfR best practices and deploying PfR.
VXI Endpoint Access Services in the Branch
All the Campus Access features such as PoE+, Location tracking, Auto port provision etc. discussed earlier in the Campus subsection are supported in the Branch environment and should be enabled for VXI system.
Teleworker
In a Cisco VXI enabled network teleworkers fall into two categories fixed and mobile teleworkers. Both teleworkers could possibly access similar virtual desktops in the same data center, the only difference is there location from where the remote-user is connecting from
A fixed teleworker is a user taking advantage of a solution such as Cisco Virtual Office (CVO). The Cisco Virtual Office solution provides secure, rich network services to workers at locations outside of the traditional corporate office, including full- and part-time home-office workers, mobile contractors, and executives. By providing extensible network services that include data, voice, video, and applications, the Cisco Virtual Office effectively creates a comprehensive office environment for employees. The Cisco Virtual Office solution consists of the following components:
•
•
•
•
A Cisco VXI enabled network provides additional benefits to the fixed teleworker using the CVO solution. These enhancements include a VXI endpoint behind the Cisco 800 ISR. The end-user can now access their virtual desktop secured through a VPN tunnel established between the Cisco 800 ISR and corporate edge router. Further, by using WAN optimization technologies offered by WAAS Mobile the VXI traffic is optimized to provide better user experience. The VXI virtual desktop will have Cisco Unified Personal Communicator installed. From the Cisco Unified Personal Communicator application the user can control an IP Phone on their desk. More information on Cisco CVO solution can be found at http://www.cisco.com/en/US/netsol/ns855/index.html
VXI mobile teleworkers connect to their virtual desktop securely from any endpoint capable of running Cisco AnyConnect Secure Mobility client and WAAS mobile. There is no requirement for a Cisco IP phone in the mobile teleworker use case. Mobile teleworkers are typically in unsecure network locations. One of the advantages of Cisco VXI is the fact that the data is still secure, even if the endpoint is stolen, damaged or lost. Further, by using WAN optimization technologies offered by WAAS Mobile the VXI traffic is optimized to provide better user experience.
WAAS mobile client is installed on the endpoint device connecting via a VPN or in a home office (CVO router) into the VXI data center. WAAS mobile has a small footprint and is supported on a majority of the thin and thick endpoints. The WAAS mobile client pairs with a WAAS mobile server positioned behind the VPN. Please note that the WAAS mobile server is not the same as a WAAS head-end appliance and so can't pair with WAVE, WAAS express or WAAS on the SRE products. WAAS mobile functionality is turned off when a teleworker endpoint is in Campus or Branch environments. This allows the more feature rich WAN optimization. WAAS mobile deployments are managed by WAAS mobile manager which provides the ability to monitor performance and measure ROI.
More information on WAAS mobile is available at: http://www.cisco.com/en/US/prod/collateral/contnetw/ps5680/ps6870/data_sheet_cisco_wide_area_application_services_mobile.html
Figure 29 shows the mobile teleworker connecting to a hosted virtual desktop from an unsecure location using a secure connection.
•
•
•
•
Figure 29 Teleworker With Thick Client
VXI Data Center Edge
Load Balancing, SSL Offloading and VXI Health Monitoring
Maintaining application uptime and availability is a major concern of IT system administrators. Many mission-critical applications in the Cisco VXI system require transparent failover if parts of the system become unresponsive. Server uptime is important in helping prevent lost productivity and ensuring that users can access their virtual desktops without any interruptions. Cisco VXI systems must be able to detect failures of a connection broker or virtual desktop and use a dynamic approach to mitigate these failures. In virtual desktop environment(s), verification of several layers of infrastructure (such as a connection broker, Active Directory, servers and storage) may be desirable before a virtual desktop request is sent to a server. To determine that all pieces are active and available, load balancers are needed to verify the connection broker. The connection broker will verify the virtual machines and servers hosting them. Active health checking is required to test the application server and not just the protocol layer. The Cisco ACE Application Control Engine part of the Cisco VXI solution provides these capabilities.
Desktop virtualization relies on an always-on network connectivity to the data center. Over the last decade, availability has become a critical part for every network design. Cisco provides high-availability network design guidance focused on specific areas of the enterprise network, such as data center, campus, branch/WAN, and Internet edge. Hierarchical network design is a common theme for designing the network for high availability. Refer to the link below for high availability network design guidance when building out a Cisco VXI system-enabled network: http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA1_7_/configuration/device_manager/guide/UG_ha.html
To further enhance the availability and scalability requirements of your DV environment, it is recommended that you deploy a load balancing solution.
For load balancing and SSL offloading, the Cisco ACE is deployed at the aggregation layer in the data center using one-armed mode. In one-arm mode, the Cisco ACE is configured with a single VLAN that handles both client requests and server responses. Routed and bridged ACE deployments also work in this design. For one-arm mode, client-source NAT or policy-based routing (PBR) needs to be configured. The Cisco ACE then uses NAT to send the requests to the real servers. Server responses return through the Cisco ACE rather than directly to the original clients. This topology is convenient, since the Cisco ACE can be almost anywhere on the network, but its reliance on NAT makes it impractical in some situations. However if you are routed or bridging mode, confirm there is sufficient bandwidth for all of the users display connections. In a one-armed topology, the Cisco ACE is connected to the real servers "connection broker" via an independent router, and acts as neither a switch nor a router for the real servers. Clients send requests to the virtual IP (VIP) on the Cisco ACE.
A minimum of two Cisco ACE appliances are required. Either the Cisco ACE Application Control Engine Module or Cisco ACE 4170 Application Control Engine Appliance can be used. When deploying the Cisco ACE Module, we recommend that you use technologies such as the Cisco Catalyst® 6500 Virtual Switching System (VSS) 1440 with its multi-chassis EtherChannel. This can help improve the resiliency of the network design by delivering a sub-second network convergence in a failure recovery. Cisco ACE 4710 appliances are connected to the aggregation layer using a port channel and are enabled for high availability. The Cisco ACE Module or 4710 Appliance load-balances virtual desktop requests to the connection broker while providing session persistence. The main features implemented on the Cisco ACE for the Cisco VXI system are:
•
•
•
For best practice guidelines for deploying Cisco ACE in VXI environment please refer to the next section in this document.
VPN Termination
To deliver desktop services, many IT organizations have turned to VPN solutions to provide secure connections to end users accessing virtual desktops from branch-offices or fixed and mobile teleworker locations. With solutions such as the Cisco ASA appliances and the Cisco AnyConnect Secure Mobility Client, an end user is able to use an encrypted connection to the data center where their virtual desktop resides.
The Cisco ASA 5500 Series Adaptive Security Appliance is a purpose-built platform that combines best-in-class security and VPN services. The Cisco ASA 5500 Series enables customization for specific deployment environments and options, with special product editions for secure remote access (SSL/IPsec VPN), firewall, content security, and intrusion prevention. The ASA can act as a VPN concentrator and/or a firewall and is the first point at the Data Center or Campus edge where all traffic is received. All VPN tunnels from VPN clients such as AnyConnect or IPSec enabled ISR 800 routers terminates here. Additional network security concerns and detailed information regarding the Cisco ASA appliances with the Cisco AnyConnect Secure Mobility Client will be covered in the "Security" chapter.
Deployment and Configuration Best Practices for VXI Network
WAAS
WAAS requires a central manager to manage the Cisco WAAS solution from a central point. The central manager for the Cisco WAAS runs on a Cisco WAE appliance. When the administrator applies configuration or policy changes to a Cisco WAE device or a group of Cisco WAE devices, the Cisco WAAS manager automatically propagates the changes to each of the managed Cisco WAE devices. Each Cisco WAE device can be configured either as an application accelerator or a central manager. Best practice is to deploy a primary and a standby central manager.
Configuring WAAS in a Cisco VXI Environment
Table 6 provides the relative configuration information needed to configure WAAS on a Cisco VXI network.
Table 6 Cisco WAAS Configuration Information
Setting Up Traffic Interception for WAAS Using WCCP
WCCP, as discussed earlier in the chapter is used to configure the router to intercept all "interesting" traffic and forward it to WAAS. WCCP service 61 and 62 direct the router to reroute traffic from the interface to the WCCP group. Service 61 redirects ingress traffic, and service 62 redirects egress traffic. Services 61 and 62 are both needed to redirect bidirectional traffic flow.
Exclude the WAE subnet from interception since this configuration uses a single interface to intercept incoming and outgoing packets. The interception exclusion is required because the router does not differentiate between traffic from the Cisco WAE for the client or server. Traffic from the Cisco WAE should not be redirected again by the router as this will create a loop.
Configure WCCP interception services 61 ingress interface and 62 on the egress interface. All ingress and egress packets from the interface are forwarded to the Cisco WAE for optimization.
For further details please refer to the excellent WAN deployment guide at the link below and read the WAAS section.
http://www.cisco.com/en/US/docs/solutions/Enterprise/Borderless_Networks/Smart_Business_Architecture/February2012/SBA_Mid_DC_DataCenterDeploymentGuide-February2012.pdf
WAAS appliances and vWAAS are expected by design to use all the available RAM on the device/VM. This is a normal condition and its recommended to configure the low memory threshold alert to a higher level in order to avoid unnecessary messages.
Cisco VSG and Cisco vWAAS are both virtual appliances that require Nexus 1000v dVS to function. Both these virtual appliances need to intercept traffic on Nexus 1000v and are not simultaneously supported as of this writing but will be supported in the future. As a workaround, if VSG is installed in the data center then WAAS appliance form factor can be used. WAAS appliances in the Data Center will typically intercept traffic at Data Center edge and don't require Nexus 1000v for operation. If vWAAS is installed in the data center, it is highly recommended to use Cisco ASA, instead of VSG, to segment and firewall the HVD traffic.
When using vWAAS in the data center the traffic would need to pass through the ASA at the data center edge. To allow Cisco ASA/PIX Firewall to recognize, permit and secure Cisco WAAS optimized traffic, a new command-line interface CLI) is provided. The new CLI should be enabled as part of the class Modular Policy Framework (MPF) to facilitate Cisco ASA/PIX Firewall interoperability with Cisco WAAS.
PoE+
Cisco VXC endpoints require 30W power and no special configuration is required as long as the line cards on Cat4K or the Cat3K switch supports PoE+. Please refer to product documentation below to get complete list of commands and supported line cards/switches.
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sg/configuration/guide/PoE.html
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.1_19_ea1/configuration/guide/swint.html#wp1289756
HA - ISSU
Access switch high availability is provided by Cat4K series modular chassis switches in the form of In-Service Software upgrade. Detailed deployment guide can be found at http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps4324/prod_white_paper0900aecd805e6a95.html
AutoSmart Port
Static Smartports macros provide port configurations that one can manually apply based on the device connected to the port. When a static macro is applied, the CLI commands attached to the macro is added to the existing port configuration. These configs are not removed during a link-down event on the port.
For current release of Cisco VXI system, configure a MAC address group with a MAC operationally unique identifier (OUI)-based trigger. Map the MAC address to a built-in or user defined macro. This macro is applied when the VXI endpoint connecting to the switch satisfies the trigger condition defined above. If the connecting endpoint does not trigger the Macro, the port is considered untrusted and can be placed in a guest VLAN by default. The user defined macro file can be maintained in a remote server location and all access switches in the network can consistently apply the same macro; this is the recommended deployment model for Cisco VXI.
The procedure for manual requires these steps:
•
•
•
The above procedure logically applies to both Catalyst 4500E and Catalyst 3000-X series switches. For specific configuration details and commands please refer to http://www.cisco.com/en/US/docs/switches/lan/auto_smartports/12.2_55_se/configuration/guide/iosaspcg.pdf
Location Tracking
Location tracking for Cisco VXI requires the following minimums
Catalyst 4K Switch IOS version 12.2(52)SG or later.
Catalyst 3K Switch IOS version 12.2(50)SE or later.
MSE 3355 - Recommended for large scale deployments to track up to 18,000 endpoints
MSE 3310 - Recommended for smaller VXI deployments of up to 2000 devices.
Currently VXI environment can only leverage the admin tag and civic information stored on the switches. Admin tag is an administrative tag or a site location associated with a logical grouping of devices or users.
The civic location is a string which usually denotes the various elements of a civic location as described in RFC 4776.
Configuration sequence - Wired Switch
The switch have to be configured for the location service. This includes configuration of location data as well as enabling NMSP. These are the configuration steps on the switch side:
•
•
•
•
•
•
•
CLI commands for the above sequence and other useful debug information can be found at: http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_50_se/configuration/guide/swlldp.html
Configuration sequence - for WCS. Required for wired switches to relay location information to the WCS.
On the WCS:
•
•
•
•
•
•
•
•
•
•
•
Once both configuration sequences above are complete wired elements can be viewed on the WCS:
•
•
•
Detailed configuration steps and screen shots for Location based services, also called context-aware-services can be found at.
http://www.cisco.com/en/US/partner/products/ps9742/products_installation_and_configuration_guides_list.html
http://www.cisco.com/en/US/partner/docs/wireless/mse/3350/7.0/CAS/configuration/guide/CAS_70.html
Tracking
Wired and wireless VXI endpoints can be looked up by IP address, partial IP address, MAC Address, partial MAC Address or VLAN ID. WCS can be setup to serve notifications when certain conditions about endpoint location or status is met. Configuration links above cover these aspects of tracking. For a quick video of the same please go to: http://www.cisco.com/web/techdoc/wcs/location/client-tracking/tracking_wi-fi_clients.html?referring_site=bodynav
PFR
VXI Design recommendations for PfR:
•
•
PfR functionality is available in Cisco ISR and Cisco ASR platforms. In the VXI branch environments, the BR functionality should be deployed using the ISR at the branch and on ASR in the data center. The MC should be enabled on the Data Center ASR.
Note
PfR deployment with WAAS and PfR deployment with DMVPN are both possible. Please refer to the links below to understand the requirements for interoperability.
Enhancing the WAN Experience with PfR and WAAS
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/ps8787/prod_white_paper0900aecd806c5077.html
Using PfR in Redundant VPN networks
http://www.cisco.com/en/US/products/ps8787/products_ios_protocol_option_home.html
PfR deployment involves multiple logical steps. Each of the phase along with the relevant documentation is tabulated below.
Table 7
PfR Deployment Steps
DMVPN
Cisco WAN Deployment guide is the best resource for DMVPN deployment in VXI system. Please refer to the link below:
http://www.cisco.com/en/US/docs/solutions/Enterprise/Borderless_Networks/Smart_Business_Architecture/February2012/SBA_Mid_DC_DataCenterDeploymentGuide-February2012.pdf
DMVPN and WAAS both use WCCP for traffic interception and redirection. Please follow the guidelines
below for deployment
•
•
•
It is recommended to use ISR G2 routers for the spoke (branch) and ASR/7200 series routers for the Hub (Head-End). All the routers must have Security plus licensing for IOS to get DMVPN functionality.
ACE
The Cisco ACE Application Control Engine periodically checks the health of the connection broker. Using the probe information, Cisco ACE determines if the connection broker can service the user's request with the best performance and availability.
When a user needs to access a virtual desktop in the data center, the user connects to a virtual IP address configured on the Cisco ACE. Then the Cisco ACE forwards the request from the user to the connection broker. Cisco ACE supports several session persistence mechanisms between the client and the connection broker so that a particular client session is always directed to the same server. The Cisco ACE is configured to perform session persistence based on the client IP address. If endpoints are coming via proxy servers, this can cause some inconsistencies with session persistence. It is then recommended to use JSESSIONID cookie persistence. The Cisco ACE will need to terminate the SSL session the view the cookie.
When deploying a Cisco ACE with connection brokers, it is best practice to use either tunneled or direct mode or a combination of the two methods.
•
•
Figure 30 shows the deployment of the Cisco ACE 4710 appliances using direct mode. The Cisco ACE 4170 Application Control Engine Appliance provides load balancing only for the connection broker. Once the connection broker has assigned the user a virtual desktop, the display protocol bypasses the Cisco ACE 4710 appliance. The Cisco ACE is configured in one-armed mode. One-armed mode is preferred in a Cisco VXI system-enabled network. Since the display protocol is between the end user and virtual desktop, the Cisco ACE does not need to be in the middle of the transaction. This will save resources on the Cisco ACE for load balancing incoming end-user requests for an available desktop from the connection broker. Since ACE is deployed in one-armed mode you need to configure source network address translation (SNAT).
Figure 30 ACE Deployment in the Network
ACE Configuration Tasks
Table 8 provides the detailed configurations for enhancing the availability for DV servers. You will notice that the table refers to contexts. The virtualized device environment provided by the Cisco ACE is divided into objects called contexts. Each context behaves like an independent Cisco ACE load balancer with its own policies, interfaces, domains, server farms, real servers, and administrators. Each context also has its own management. When Cisco ACE is deployed, the Admin context is used for managing and provisioning other virtual contexts. It is best practice to create a virtual context named VMware DV load balancing.
Table 8
DV Server Configurations
For More Information
The following list of web links offer detailed information regarding specific vendor information including hardware and software discussed in this chapter.
Introduction to the WAAS Central Manager GUI
http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v421/configuration/guide/intro.html#wp1122501
First link Vmware View 4.x
Second Vmware View 4.x
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012382#View4x
Configuring Traffic Interception
http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v4013/configuration/guide/traffic.html
Configuring Application Acceleration
http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v4013/configuration/guide/policy.html
Configuring Network Settings
http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v4013/configuration/guide/network.html
Configuring and Managing WAAS Print Services
http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v4013/configuration/guide/printsvr.html
Data Center
http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DC_3_0/DC-3_0_IPInfra.html
Campus
http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/HA_campus_DG/hacampusdg.html
Branch/WAN
http://www.ciscosystems.com/en/US/docs/solutions/Enterprise/Branch/srlgbrnt.pdf
Physical interfaces
Management access
Resource Management - http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA1_7_/configuration/device_manager/guide/UG_confg.html#wp2700097
High availability - http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA1_7_/configuration/device_manager/guide/UG_ha.html
Configuring Virtual Contexts - http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA1_7_/configuration/device_manager/guide/UG_confg.html
One-armed mode configuration - http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/vA2_3_0/configuration/getting/started/guide/one_arm.pdf
Configuring Session Persistence -
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA1_7_/configuration/device_manager/guide/UG_lb.html#wp1062118
Configuring Health Monitoring -
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA1_7_/configuration/device_manager/guide/UG_lb.html#wp1045366
Balancing Algorithm -
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA1_7_/configuration/device_manager/guide/UG_lb.html#wp1045366
Configuration of Source NAT -
Endpoints and Applications
The Cisco VXI system includes a variety of endpoints and applications offering Desktop Virtualization (DV) and collaboration services. The DV endpoints for desktop virtualization support user desktop interaction through keyboard, mouse and touch screen input devices. They also offer some USB-based print and storage capabilities. The Unified Communication (UC) endpoints deliver voice and video communications. Cisco Unified Personal Communicator, Cisco Unified Communication Integration for Microsoft Lync (CUCILync) and Cisco Unified Communication Integration for Cisco Webex Connect (CUCIConnect) provide the functional integration between the virtual desktop and the UC endpoint, by allowing user control of a deskphone, a UC enabled thin client or a UC software appliance on a thick client through a software application deployed on the user's Hosted Virtual Desktop (HVD).
Figure 31 provides a general endpoint data flow diagram for virtual desktop environment.
Figure 31 General Endpoint Data Flow Diagram
Note
Cisco Virtual Experience Client DV Endpoints
The VXC endpoint family includes zero clients (VXC 2x11 and VXC 2x12), UC enabled thin client (VXC-6215), a UC enabled software appliance (VXC 4000) for thick clients and the VXI (UC/DV) capable tablet Cisco Cius.
VXC 2x11 Zero Clients
Cisco offers four VXC zero-client models that can connect to a VMware View hosted virtual desktop environment. The Cisco VXC 2111 and the VXC 2211 are hardware-based (Teradici chip based) zero-clients. These devices provide the necessary functionality to connect to a VMware View environment using the PCoIP display protocol. The VXC 2112 and VXC 2212 are also zero-clients running a thin embedded OS that provides the necessary functionality to connect to a VMware view environment using RDP as a display protocol.
The Cisco VXC 2111 and VXC 2112 endpoint attaches seamlessly to any Cisco 9971, 9951* or 8961 IP phone. This configuration delivers a single integrated device offering UC and DV functionality. For example, the user can access Instant Messaging, Directory Lookup/Contact list, Presence, and Cisco IP telephony control, including conferencing, through Cisco Unified Personal Communicator or UC Integration for WebEx Connect on the HVD, while using the audio and video capabilities on the local IP phone. The IP phone intelligently separates the UC media traffic from the DV display protocol traffic so that each media type can be handled and prioritized by the network separately.
Figure 32 Cisco VXC 2!11
The VXC 2111 or VXC 2112 has an Ethernet port connecting to the PC port of the IP phone for network access, and a power cable connecting to the side of the Cisco IP phone. This approach allows a single Ethernet-based network connection to provide both network connectivity and power supply to both the UC and the DV endpoint. It is recommended to place the VXC network traffic on the data VLAN. The zero client does not perform QOS marking of DV traffic. Please refer to QoS chapter for guidance on applying QoS markings to the DV traffic for the VXC endpoint.
The VXC 2111 or VXC 2112 requires 802.3AT-based inline power (PoE, 25.5W) when in a basic configuration (i.e. keyboard, mouse and a single monitor connection) but will require an external power supply (CP-PWR-CUBE-4) for other configurations where USB ports, a Cisco Key Expansion Module (KEM) and/or multiple monitor are required.
Another way to supply enough power in expanded configurations is by leveraging Universal Power over Ethernet (UPoE) capabilities available on latest Catalyst 4500E switches. This option is recommended for deployments where external power supply adds to energy cost and cabling management and complexity. Cisco Catalyst 4500E's UPoE technology provides up to 60 watt power to enable very broad endpoint support, with additional benefits of higher availability, lower OpEx, and faster deployment. More information on UPoE can be found at www.cisco.com/go/upoe. Catalyst 4500E switches have full support of Cisco EnergyWise and this support is extended via UPoE giving single point of power control across the enterprise. Also refer to the UPoE section of the VXI Network chapter for design considerations.
When used in the branch or home office, the VXC 2111 or VXC 2112 can connect to the campus via SSLVPN, using the VXC VPN feature of the IP phone on both lines. Note that the phone load running on the 9971 should support the VXC VPN feature (no specific VXC firmware is required). Please refer to the Security chapter for more details guidance on the SSLVPN feature available on the IP phones.
Refer to Cisco VXI Configuration Guide for the correct phone loads that support UPoE and SSLVPN.
For configuration details of the VXC clients see: http://www.cisco.com/go/vxc.
Note
For information on VXC 2111/VXC 2112 and VXC 2211/VXC 2212, visit: http://www.cisco.com/go/vxc.
Figure 33 Cisco VXC 2211
The VXC 2211 or the VXC 2212 zero-client endpoint is a standalone DV appliance; it delivers DV functionality and, when associated with a Cisco Unified Communication endpoint (e.g. Cisco 79XX IP phone), can deliver an integrated user experience through the use of Cisco Unified Personal Communicator on the Hosted Virtual Desktop, while relying on the audio and video capabilities of the associated IP phone.
The VXC 2211 or VXC 2212 requires 802.3AF-based inline power (PoE, 15W) when in a basic configuration (i.e. keyboard, mouse and a single monitor connection) but will require 802.3AT-based inline power (PoE, 25.5W) or an external power supply (CP-PWR-CUBE-4) for other configurations.
The VXC 2211 or VXC 2212 typically connects directly to the access switch; placing the VXC 221x's port in the data vlan is recommended.
For configuration details of the VXC clients see: http://www.cisco.com/go/vxc.
VXC 6215 UC enabled Thin Clients
The VXC-6215 is Cisco's next generation VXC client with the necessary functionality to connect to a VMware view environment using PCoIP as the display protocol. It can also include an add-on Cisco Unified Communications software appliance that delivers optimized UC voice and video capabilities to the HVD
Note
This enables DV users to collaborate via instant messaging, e-mail, presence and voice/video conferencing using a single device on their desk. The VXC-6215 intelligently separates the UC media traffic from the DV display protocol traffic so that each media type can be handled and prioritized by the network separately. The combination of a UC enabling application (e.g. CUPC) running in the users HVD in deskphone control mode and a local UC software appliance running in the thin client is designed to replace the users deskphone and PC while maintaining good user experience for both the desktop and the audio and video conferencing applications. This solution is well suited for campus workers and for remote workers, where UC survivability is not required.
Note
Figure 34 Cisco VXC-6215
The VXC-6215 operates in two modes, basic VDI mode or VDI with Cisco Unified Communication integration mode. For basic VDI mode (no UC capability) VXC-6215 supports VMware view 4.x or 5.0 using RDP 7 or PCoIP. The VDI with Cisco Unified Communication integration mode will not be supported in the first firmware release of VXC-6215 for VMware view HVD environments, for target availability see www.cisco.com/go/vxc. The VXC-6215 requires an external power supply. The VXC-6215 connects directly to the access switch and placing the VXC-6215's Ethernet port in the data VLAN is recommended.
For configuration details of the VXC clients see: http://www.cisco.com/go/vxc.
VXC 4000 UC Software Appliance for Thick Clients
The Cisco VXC 4000 is a UC enabled software appliance that delivers UC voice capabilities to a thick client (Windows OS) running VMware View client for DV functionality. The VXC 4000 delivers UC voice collaboration to the DV user by terminating voice media streams on the local thick client when controlled by an application like Cisco Unified Personal Communicator or Cisco Unified Communications Integration for Microsoft Lync running in the HVD. Cisco Unified Communications Manager (7.1.x or later), and Cisco Unified Presence Server (8.0 or later) are required (If it is a Cisco Unified Integration to Microsoft Lync environment the Cisco Unified Presence Server is not required). This solution intelligently separates the desktop protocol and UC media (voice) traffic so that each individual media type can be handled and prioritized by the network. The combination of CUPC running in the users HVD in deskphone control mode and local media engine running in the thick client is designed to replace the users desktop phone while still maintaining high voice quality that users expect from their desktop phone. The VXC 4000 enhances the user-experience by providing the ability to work and collaborate seamlessly using a single DV appliance. The VXC 4000 can be installed on a users existing Windows based computing device including repurposed PC's. This is especially useful for leveraging existing PC investment and for contractors, work at home and BYOD scenarios.
Figure 35 Cisco VXC 4000
The Cisco VXC 4000 hosted UC software appliance delivers a single integrated device offering UC and DV functionality. For example, the user can access Instant Messaging, Directory Lookup/Contact list, Presence, and Cisco IP telephony control, including audio conferencing, through Cisco Unified Personal Communicator or UC Integration for Lync on the HVD, while using the audio capabilities on the local UC software appliance. The thick client (windows XP and Windows 7) will also allow the user to run other applications in addition to the DV and UC clients.
Cisco's VPN client AnyConnect an EnergyWise compatible client can also be installed on the thick client and is compatible with VXC 4000. The VXC 4000 UC software appliance does not provide the capability to connect to your HVD, that capability is accomplished by VMware View client application. The user is required to install the VMware View client on the thick client in order to connect to the VMware View environment. Any peripherals used to access the audio capabilities of the UC software appliance should not be redirected to the HVD; instead the device must remain locally connected. For example, a USB headset should be installed and be locally available to the thick client OS.
The VXC 4000 currently only supports audio streams but will support video in future release. When launched, the VXC 4000 runs in the background in minimized appearance. As a user interface it is designed to operate only while being controlled by CUPC, it is not recommended or supported to run the UC appliance in standalone mode. The end user will need to select the VXC 4000 device as the CTI controlled endpoint in the CUPC or CUCI-Lync instance running in the HVD.
Note
For configuration details of the VXC clients see: http://www.cisco.com/go/vxc.
VXC Media Termination Capability
The VXC 4000 includes a media engine that allows voice and video to terminate directly on thick client PC. This allows the media stream to take an optimum path between endpoints and allows for native network based QOS to be applied to the media stream. Having a local UC media engine handling UC media locally at the client also avoids the user-experience degradation when running UC applications in softphone mode inside the HVD. The user-experience degradation stems from the UC media stream traveling through the display protocol all the way back to the HVD in the data center and then back to the remote endpoint, this results in excessive bandwidth and server resource usage as well as increased latency. This is known as the hairpin effect.
For the HVD clients the network providing connectivity back to the data center becomes the most important part of a virtual desktop solution in order to provide users a rich user-experience. The VXC 4000 is designed to leverage the network by intelligently separating UC media traffic an placing it outside the display protocol traffic (PCoIP/RDP) allowing for network-awareness of each traffic type. Although the UC enabled VXC client does not do native VLAN or QoS tagging, it allows for proper QoS treatment of both the UC media traffic and the HVD media traffic within the network when QoS markings are set accordingly at the access switch, refer to the QoS chapter for details. The UC enabled VXC client optimizes the media traffic flows further by allowing UC media traffic to travel directly between the UC enabled end-points, while the DV traffic flows between the VXC device and the DC hosting the HVD. The UC enabled VXC client's ability to allow for different media flows to be separated along with network awareness of each media flow delivers a best in class user experience.
The deskphone control signaling for VXC 4000 occurs outside of the display protocol as with hardphone control. The VXC 4000 register to CUCM enabling location awareness. This results in better CAC, E911 and codec selection for media traversing different types of links. This is in contrast to softphone based solution where softphone runs in HVD and CUCM has no awareness of the location of the endpoint.
Figure 36 Separation of Media Using Cisco VXC 4000
VXC 4000 QOS Considerations
Cisco VXC 4000 currently handles all data traffic, including DV traffic, on a Best-Effort basis in terms of QoS. To ensure that DV traffic is prioritized over other data traffic on the wired or wireless link, administrators should configure the access switch or wireless access point to do QoS marking (see the QoS chapter for specific DV traffic marking recommendations). QoS marking should also be consistently applied between the access point and the HVD to provide a high quality user experience
All traffic (DV and voice) is sent through the same interface. The relative size of the various traffic flows can potentially create situations where the network interface bandwidth is over-subscribed. Again, QoS marking should be done at the access point to ensure that DV and voice traffic is suitably prioritized.
Telephony calls will generate a constant RTP media flow commensurate with the codec being used; for example, a G.722 audio call would consume approximately 80kbps for the duration of the call, in each direction (as this is a duplex call). The following table indicates the nominal bandwidth consumption of the audio and video codecs supported by the VXC 4000.
Table 9 Codec / Bandwidth Consumption
g.729
24kbps, symmetrical
g.711, g.722
80kbps, symmetrical
iLBC
16 kbps, symmetrical
The desktop virtualization bandwidth will be more asymmetrical. The bandwidth consumption is also related to the amount of activity on the user's hosted virtual desktop. For example, an idle desktop will only generate a small, quiescent amount of traffic, while a desktop running visually rich applications (e.g.: a flash video) will consume more bandwidth.
The thick client allows other applications to run which also consume network bandwidth. For example, running a local browser will result in traffic flows in addition to those of DV and UC applications on a thick client.
The aggregate bandwidth consumption of a VXC endpoint needs to be considered when estimating the impact it may have on the network. A proper network design must be implemented in order to ensure the proper quality of service is delivered to the end-user.
The Cisco VXC 4000 does not provide QoS markings for DV traffic. It does provide markings for UC traffic, but typically these markings will not be honored by the access switch. It is recommended the UC and DV traffic QoS markings be configured at the access switch or wifi access point. It is possible to limit the UDP port range for voice traffic by configuring Audio properties on the VXC 4000 or on the CUCM device profile with default port range being 24576 up to 32768) (please refer to the QoS chapter of this guide for implementation details and special considerations when deployed in an environment with a separate secured voice network).
Cisco Cius as a DV Endpoint
Cius Overview
The Cisco Cius is a 7" diagonal, high-resolution color touch-screen tablet. Cius runs on the Android operating system and supports WiFi (802.11a/b/g/n), Bluetooth 2.1, HD video (720p) with Cisco Telepresence interoperability, and Collaboration applications including voice/video conferencing, Presence, Instant Messaging and one-click access to WebEx Meeting Center. Cisco Cius also acts as a Virtual Desktop Thin-Client. The central management and application control policies make Cius the first enterprise ready tablet for knowledge workers and executives, and provides the most comprehensive, reliable, and secure collaboration experience in the industry. Cius can be a stand-alone device or can be paired with a companion docking station (Cisco Media Station)
The Cius device is powered by a detachable and serviceable 8-hour battery and comes with a 5Vdc power adapter, capable of recharging the Cius battery. The available docking station comes equipped with a -48Vdc power adapter. When the Cius is docked, the battery is charged using the -48Vdc power adapter and the 5Vdc power adapter is not needed. For energy savings and single wire convenience, the Cisco Media Station supports Power-over-Ethernet (802.3AT 30W required). The Cius tablet can be fully powered and recharged through a PoE+ connection, which can eliminate the need for an external power adapter.
Figure 37 Cisco Cius Endpoint
Cius Management
The Cisco Cius tablet is centrally managed through Cisco Unified Communications Manager (7.1.5, 8.5 or later), which makes it ideal for enterprise environments. Through Cisco Unified Communications Manager the administrator can set policies, enable features, and even lock or wipe the device in case it has been lost or stolen. Administrators also can control the USB port (enabled or disabled), video calling capability, access to Android application markets, and remote VPN access.
Figure 38 Cius Management
Cius Applications
Cius applications can be accessed and installed in four different ways. Access is defined by means of Cisco UCM policy settings. Administrators can enable all options, or specifically disable certain options according to organization policy. Available app store options include:
•
•
•
•
•
Applications that can be managed via any of the four methods described above are the DV capable applications WYSE PocketCloud and VMware view client, which enable the Cius user to access a Hosted Virtual Desktop from a VMware view connection server. The WYSE Pocket Cloud Pro application supports the RDP display protocol and the VMware View client supports both RDP and PCoIP display protocols. Both vendors have optimized their respective DV application to run and perform better on Cisco Cius.
Figure 39 Cius Applications
Having these application management capabilities allows an IT department to restrict users, or group of users, to applications the department deems compliant. Administrators can disable the ability to install applications from unknown sources and prevent applications from the public Android Market.
Cius Operating Modes
Cisco Cius can be used in standalone mode, where all connectivity is carried out over its WiFi connection and the user interface is based on its touch-screen display. It can also be used with its companion docking station, and connected to an external monitor, mouse, and keyboard. The docking station provides a second wired Ethernet connection. The docking station transforms the Cius from a tablet content-consumption device to a fully capable desktop device able to connect to a hosted virtual desktop. This functionality enables Cius to be used as a full-featured content creation device (creating a power-point or word document) and provides a similar experience to using a dedicated PC.
Unlike other Desktop Virtualization (DV) endpoints, Cisco Cius features a local voice and video media plane; this means that calls from a Cisco Cius are supported by a voice/video media channel which is anchored on the Cius device itself. The flow of the media channel does not go through the user's Hosted Virtual Desktop, but rather is established as per the best available network path directly to the destination device. When docked, the UC application client [Cius Phone] maintains its UC signaling connection over the WiFi network while routing UC media traffic through the wired interface. This approach maintains the signaling connection through dock and un-dock actions, which allows the system to coordinate the media connection's switch between wired and wireless access networks.
Figure 40 VMware Flow
Cisco QoS
Cisco Cius currently handles all data traffic, including DV traffic, on a Best-Effort basis in terms of QoS. Only voice and video traffic are marked and queued per QoS markings. To ensure that DV traffic is prioritized over other data traffic on the wireless link, administrators should configure the wireless access point to do QoS marking (see the QoS chapter for specific DV traffic marking recommendations). QoS marking should also be consistently applied between the access point and the HVD to provide a high quality user experience (please refer to the QoS chapter of this guide for details). When Cius is docked, DV traffic and UC media traffic maintain separate network paths. Because the video and voice traffic no longer contend for wireless access, the QoS-marked DV traffic will have priority over other data traffic from the access point across the network and to data center.
When used in standalone mode (un-docked), all traffic is sent through the WiFi interface. The relative size of the various traffic flows can potentially create situations where the WiFi network's bandwidth is over-subscribed. Again, QoS marking should be done at the access point to ensure that DV traffic is suitably prioritized.
Telephony calls will generate a constant RTP media flow commensurate with the codec being used; for example, a G.722 audio call would consume approximately 80kbps for the duration of the call, in each direction (as this is a duplex call). The following table indicates the nominal bandwidth consumption of the audio and video codecs supported by the Cisco Cius.
Table 10 Codec / Bandwidth Consumption
The desktop virtualization bandwidth will be more asymmetrical. The bandwidth consumption is also related to the amount of activity on the user's hosted virtual desktop. For example, an idle desktop will only generate a small, quiescent amount of traffic, while a desktop running visually rich applications (e.g.: a flash video) will consume more bandwidth.
The Cisco Cius tablet supports applications which, when installed, also consume network bandwidth. For example, running a local browser will result in traffic flows in addition to those of DV and UC applications.
The aggregate bandwidth consumption of a Cisco Cius tablet needs to be considered when measuring the impact it may have on the network. A proper network design must be implemented in order to ensure the proper quality of service is delivered to the end-user. http://sjc-fs1-web/users-m/migilles/published/Docs/Cius/Cius_dply_eft.pdf
Cius provides two separate Ethernet connections (when docked) for signaling and media separation and supports the following QoS markings during undocked or docked configuration:
Table 11 Cius QoS Support
Note
The Cius WiFi supports IEEE 802.1a/b/g/n with 20MHz and 40MHz channel width support. For more information on Wifi channel details and WiFi network design considerations see http://sjc-fs1-web/users-m/migilles/published/Docs/Cius/Cius_dply_eft.pdf
Cius Security
Cisco Cius supports SIP over TLS and secure real-time-protocol to securely send and receive UC signaling and media traffic. To secure all types of traffic Cius supports Cisco's AnyConnect VPN and is natively installed and managed via Cisco UCM. With AnyConnect VPN capability the DV and UC media traffic as well as other data, including DV traffic, is securely encrypted between the Cius device and the corporate head-end security gateway (Cisco ASA 5500 adaptive security appliance is required, running IOS version 8.0 or later).
Figure 41
Apple iPad as a DV End-Point
The Apple iPad has the capability to run "VMware View Client for iPad" application which is available, from the Apple app store. Using "VMware view client for iPad" a user can configure the VMware view "Server" (which in this case is the VMware view desktop connection broker) residing in the data center. Once the user installs and configures the VMware view client app a connection to the user's HVD can be made. A limitation of the iPad as a desktop virtualization device is that it does not support an external mouse, only keyboard, making it difficult to create documents using content creation apps running on the HVD. The VMware view client software addresses the limitation by providing a touch screen based track-pad that can be enabled via the VMware view client menu. The Apple iPad can also be installed with Cisco AnyConnect SSL VPN application enabling the device to access the users HVD securely from anywhere and any place. Cisco AnyConnect on iPad, allows for the HVD traffic to be secured, as well as, any corporate application can be securely accessed by iPad from a remote location via wifi or 3G. By installing Cisco Jabber for iPad a Cisco Unified Communication collaborative suite of apps can be leveraged. This combination of applications makes it possible for the user to take important information or documents, residing on his/her HVD, on the road without security compromise and remain connected and ready to collaborate. For Cisco AnyConnect and VMware view client support the Apple iPad must be running iOS 4.2 or later, Cisco AnyConnect for iPad is supported on ASA security gateways running 8.0(3).1 or later. The Cisco ASA must also be licensed for AnyConnect mobile license feature. For specific questions on AnyConnect licensing send an e-mail to: ac-mobile-license-request@cisco.com.
Configuring ASA:
http://www.cisco.com/en/US/partner/docs/security/asa/asa82/configuration/guide/svc.html#wp1094561
AnyConnect on iPad user guide:
http://www.cisco.com/en/US/docs/security/vpn_client/anyconnect/anyconnect24/ios4.2-user/guide/ipad-ugac-ios4.2.html
VMware view client:
http://blogs.vmware.com/view/2011/03/view-client-for-ipad.html
DV Endpoint Management
Management software for the DV endpoints is typically provided by either the endpoint manufacturer or the HVD software vendor, or both. For the Cisco VXC 211x and VXC 221x using the Virtual Experience Client Manager allows administrators to manage large deployments of zero-clients. Cisco Virtual Experience Client Manager (VXC-M) supports:
•
•
•
•
•
•
•
See the "Management and Operations" chapter for more information covering DV Endpoint Management.
DV Endpoint Printing (Network Printer)
When a user sends a document to a network printer co-located with the user's endpoint, the print flow actually originates from within the data center. The print flow to the network printer actually travels outside the desktop display protocol, and can be optimized with WAAS. Cisco WAAS can recognize the printing protocol, compress it to reduce WAN bandwidth consumption, and send the resulting print file to the remote branch (see Figure 42). WAAS offers queuing functionality if the remote printer is busy. Details of this print optimization and queuing can be found in configuration guide for Cisco Wide-Area Application Services:
http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v421/configuration/guide/cnfgbook.pdf
Figure 42 Network Printing Data Flow
1.
2.
Note
DV Endpoint Access to USB-attached Peripherals (Storage or Printing)
DV endpoints often feature USB ports allowing connections to storage devices (such as, hard disks, "thumb" drives) and printers. Although physical access to the USB port may allow a user to connect such peripherals, it is the connection broker that controls the logical enabling of the port.
USB port access is a policy that follows the user, not the device. For example, one user may be allowed to use storage peripherals on a DV endpoint, log out, and then when another user logs into the same DV endpoint, storage access is disabled. When USB peripheral access is enabled for a given user, the flow of data to the USB peripheral originates in the user's Hosted Virtual Desktop, in the Data Center; all file storage or print operations to a USB-attached peripheral thus result in a data flow across the network to the DV endpoint, encapsulated within the display protocol.
Details on enabling/disabling the USB access can be found in the "Cisco VXI Security" chapter of this document.
Figure 43 USB Printing Data Flow
1.
2.
DV Tested Endpoints
Table 12 is a list of endpoints used during the testing to verify the Cisco VXI design. It is not intended to be an exhaustive list of supported vendors or devices.
Table 12 Endpoints
Cisco VXI System
A typical HVD connection relies on an IP-based display protocol connection to carry the Graphical, user input (e.g.: mouse/keyboard), and multimedia information (such as voice and video telephony) between the endpoint and the HVD. This approach places all information types (e.g.: voice, video, display updates, USB-based information) in the same IP connection between the endpoint and the HVD. Since the Display Protocol is opaque to network services, QOS, CAC and codec negotiation cannot be applied to the individual media streams within the Display Protocol possibly resulting in a sub optimal user experience. Figure 44 describes a typical DV deployment.
Figure 44 DV Appliance
With Cisco's VXI system, optimum user experience can be realized using coupled UC endpoint and DV endpoint appliances to achieve media separation. In this case, the voice and video media streams are separated from the Display Protocol and are terminated point to point between the UC endpoints, bypassing the data center. Network Services can now be applied:
•
•
•
Figure 45 demonstrates the flow of the separated traffic.
Figure 45
Flow of Separated Traffic
Cisco Unified Communications Applications
In a Cisco VXI system, support for Cisco Unified Communications is through the deployment of desktop applications that utilize Cisco's Client Services Framework and are thereby capable of controlling a Cisco Unified IP Phone. Cisco Unified Personal Communicator, Cisco Unified Communications Integration for WebEx Connect and Cisco Unified Communications Integration™ for Microsoft Lync are examples of such applications. These applications can run within the HVD, and can be used to control the user's desktop hard phone or UC enabled VXC client. With Cisco Unified Personal Communicator, the Cisco VXI end-user has the ability to manage contact information (directory lookup), obtain real-time availability status of colleagues and co-workers (Presence), online chat (Instant Messaging) and voice+video IP telephony and conferencing.
Cisco's Unified Personal Communicator, UC Integration™ for Microsoft Lync and UC Integration for WebEx Connect applications can be configured in one of two modes: Soft phone mode and desk phone control mode. Soft phone mode is not supported in a Cisco VXI solution, as it places UC media within the display protocol. Deskphone control mode utilizes a physical Cisco Unified IP phone or UC enabled VXC client and allows the control of that phone via the application on the desktop while the audio/video of the call is terminated directly on the IP phone or UC enabled VXC client rather than the HVD. The real issue in how this application should be deployed comes down to the audio/video stream of the call. Since the audio/video stream in soft phone mode would attempt to go through the display protocol, as discussed in the previous section, and could not be differentiated from other applications being transported within that desktop display protocol, it is advised to run the UC application of choice in deskphone control mode where the audio/video stream remains separate, and can be handled within the network as it normally would.
http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cucm/admin/8_5_1/ccmsys/a08video.html
http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cucm/docguide/8_5_1/dg851.html
Software version of the UC applications supported can be found in the Cisco Virtualization Experience Infrastructure Configuration Guide: http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/VXI/configuration/VXI_Config_Guide.pdf
A typical Cisco Unified Personal Communicator call flow is shown in Figure 46.
Figure 46 Data Flow for Placing a Cisco Unified Personal Communicator Call from HVD
In Figure 46, the Data flow for placing Cisco Unified Personal Communicator call from the HVD diagram, the DV endpoint provides the user with a visual representation of their individual virtual desktop environment, and supports user input via keyboard, mouse and/or touch screen input device. The user's desktop is configured with an instance of Cisco Unified Personal Communicator, offering instant messaging, presence, directory lookup and telephony control over the desk phone. The desk phone or UC enabled VXC client offers the voice/video media handling.
Note that all the user's actions are relayed within the display protocol to the virtual desktop in the data center. Likewise, all visual updates to the Cisco Unified Personal Communicator screen, like any other screen update, are delivered to the user within the display protocol from the virtual desktop to the HVD endpoint's screen.
As user input is processed by Cisco Unified Personal Communicator, which is on the HVD desktop in the data center, it communicates to the appropriate collaboration servers that are also located within the data center, and possibly within the same UCS cluster. Note that since the desktop is now running on a platform within the data center, this means that all communication controlling the call can remain within the data center. The complete data flow for this call process is listed below:
1.
2.
3.
4.
5.
6.
7.
8.
Note
Note
VXC and UC Endpoint Single Sign-on:
When a user logs into their HVD a single sign-on process can be supported where the user only needs to enter his/her credentials one time. The user will enter the required credentials in the VXC GUI sign-on screen; this would log the user to the appropriate HVD connection broker and automatically log and launch the connection to the HVD. Once the user is connected to the HVD Cisco Unified Personal Communicator, UC Integration™ for Microsoft Lync or UC Integration for WebEx Connect have the capability to launch automatically. The UC user credentials are saved, once the initial sign-on is done manually, enabling automatic sign-in to the UC deskphone control application. Single sign-on to the HVD is supported in two ways, it can be configured manually on each Virtualization Experience Client or using Virtualization Experience Client Manager. When using Virtual Experience Client Manager (VXC-M) and supporting services .ini files are downloaded by VXC devices during the boot up and login process containing global, device-specific, and user-specific configuration settings including sign-in credentials and the HVD connection information. When using Virtual Experience Client Manager (VXC-M) and supporting services .ini files are downloaded by VXC devices during the boot up and login process containing global, device-specific, and user-specific configuration settings including sign-in credentials and the HVD connection information. For more information on VXC-M see the "Management and Operations" chapter.
Note
Cisco Unified Personal Communicator, HVD and SRST
SRST is supported in Cisco VXI. Figure 47 describes the call flow during a failover situation where the WAN link between the DV and UC endpoints and the data center is lost. The HVD with Cisco Unified Personal Communicator running will continue to have contact with the Cisco Unified Communications Manager co-located in the data center. However, the Cisco Unified Communications Manager connectivity to the hard phone will be lost. If the end-user location is equipped with a voice gateway capable of supplying SRST services, the phones can re-register with the gateway. In this way, the phones will still be capable of placing and receiving calls.
Note
Figure 47 SRST Signaling And Media Flow
It is difficult to predict how the hard phone control configuration described above will respond when network service to the data center is restored. The Cisco Unified Personal Communicator application has never lost contact with Cisco Unified Communications Manager. With connectivity restored, the phone can now resume its connection to Cisco Unified Communications Manager. The unpredictable behavior arises from the timing of the end-user re-establishing connectivity with their desktop. If this is before the phone re-connects with Cisco Unified Communications Manager, it is possible for the end-user to attempt to control their hard desk phone before Cisco Unified Communications Manager is aware the phone is present. The best way to avoid such issues is to verify that Cisco Unified Personal Communicator can correctly reflect the status of the phone by going off-hook and confirming a status change in Cisco Unified Personal Communicator. In some rare cases, this status may not re-sync, and Cisco Unified Personal Communicator may need to be restarted within the HVD in order to re-establish proper status of the phone.
For more detailed information on Cisco Unified SRST please see the Cisco Unified SRST Configuration Guide:
http://www.cisco.com/en/US/docs/voice_ip_comm/cusrst/admin/srst/configuration/guide/SRST_SysAdmin.pdf
For basic configuration on how to deliver a UC video and voice call solution using deskphone control in a hosted virtual environment see the Cisco Virtualization Experience Infrastructure Configuration Guide.
Cisco VXI System Applications Enabling UC Collaboration
The installation, configuration, and security associated with any applications installed on the HVD user's desktop should be subject to all the same corporate policies and procedures as if they were installed on a traditional desktop. This includes the ability to load applications onto the desktop outside of the corporate IT infrastructure. If corporate policy dictates that users cannot install applications on a traditional desktop or laptop device, the local OS should be locked down on a Thin-Client as well. Provided there are no issues with an individual product's ability to run in a HVD environment, virus protection policies, backup procedures for data, and personal security permissions within the enterprise should all remain the same even though the location of the data has moved to the data center.
The following UC applications have been validated for delivering Cisco rich-media collaboration experience in a Cisco VXI solution. These are Cisco Unified Personal communicator, Cisco Unified Communications Integration™ for Microsoft Lync, Cisco Unified Communications Integration™ for WebEx Connect and Cisco QUAD.
Note
For More Information
Table 13 provides more detailed information regarding specific vendor information including hardware and software discussed in this chapter.
Table 13 Endpoints and Applications Links
Management and Operations
An end-to-end Cisco® Virtual Experience Infrastructure (Cisco VXI) deployment requires a comprehensive management architecture that provides the capability to provision, monitor, and troubleshoot the service for a large number of users on a continuous basis. This chapter provides best practices and guidelines for managing a Cisco VXI system. It also describes the key tasks and tools associated with Cisco VXI services delivery that pertain to daily operations (postdeployment). An understanding of the demands of managing the system can serve as a basis for validating off-the-shelf management tools and developing such tools in house.
Managing a Cisco VXI system is challenging given the number of hardware and software components in the end-to-end system (campus, branch office, and Internet; see). These components provide services (such as desktop virtualization, network, storage, compute, security, load-balancing, WAN acceleration, and unified communications services) to local and remote end users and administrators. Administrators are expected to manage different technologies and services, such as network, storage, database, and desktop administration.
Figure 48 Tools Used to Manage the Cisco VXI System
Cisco VXI Management and Operations Architecture
This section describes the main aspects of a management architecture for a Cisco VXI system. Operations management, service management, service statistics management, and provisioning management are the main management elements for Cisco VXI (Table 14). Other important areas to consider include scalability, high availability, management traffic, desktop management, and endpoint management.
Table 14 Cisco VXI Management Architecture
Scalability
As an alternative to provisioning and managing every device with a command-line interface (CLI), you can use a management tool to scale management for a large number of endpoints though a centralized control point. The use of polling, SNMP traps, and syslog messages are crucial for monitoring a large-scale deployment. In addition, GUI-based tools are helpful for navigating complex deployments and viewing detailed reports. Many device management tools also provide an API or CLI that can be used to automate workflows. This feature is particularly useful when you are adding a large number of users, desktops, or endpoints.
High Availability
For high availability, you should deploy management applications in redundant configurations (primary and secondary servers) and back up configurations and databases periodically. You should also deploy management application servers on virtual machines, to use resources efficiently and capitalize on high-availability features provided by the hypervisor infrastructure, such as virtual machine migration (VMware vMotion), VMware Distributed Resource Scheduling (DRS), and VMware Fault Tolerance (FT). Although many applications will need to reside on a dedicated server, consider consolidating applications and servers on the same virtual machine to conserve resources where possible. In general, the ideal place to locate management servers is in the data center with other critical resources.
Management Traffic
As a general guideline, a separate IP network for management traffic is recommended. For example, a dedicated IP subnet and VLAN for remote-access, SNMP, syslog, and FTP traffic could be managed out of band, where practical. This approach helps ensure that end-user and administrative traffic flows do not compete for, or interfere with, available bandwidth, and that remote access to a device is not compromised when the device needs to be reset or provisioned. This approach also mitigates threats to network security and availability that could be introduced when end-user and administrative traffic share the same interface.
The isolation of management and user traffic is especially important in the data center, where virtualization of the desktops concentrates user traffic in an infrastructure traditionally used for server and management traffic loads.
The isolation of management traffic may not be practical in some parts of the system. For example, an endpoint usually has a single Ethernet port, so it must use this port for both end-user and administrative traffic. Also, it may not be practical to set up a separate out-of-band network dedicated to management traffic across a WAN due to cost and network address conservation concerns. In these cases, keep in mind that certain types of management traffic (SNMP polling) can consume substantial bandwidth and should be scheduled appropriately, monitored, and possibly rate limited using standard quality-of-service (QoS) techniques.
Each management tool uses a specific set of protocols to communicate with devices. Refer to the vendor documentation for a complete list of protocols and ports used by each tool. Make sure that these ports are open on all intermediary routers, switches, and firewalls.
Endpoint Management
The OS, applications, and settings on the endpoint also need to be managed. When these endpoints run an embedded version of Microsoft Windows, they can be managed in much the same way as a physical desktop. Endpoint management tools can be used to automate and simplify the task of provisioning and monitoring the desktop virtualization endpoints. Network-based services such as Dynamic Host Configuration Protocol (DHCP) and file servers can also be used to provision and update endpoints. Also, local software repositories or caching services (Cisco Wide Area Application Services) can be used to distribute patches and updates to desktop virtualization endpoints. Refer to the section describing desktop virtualization endpoint management for more information.
Cisco VXI Management Tool Summary
This section summarizes the Cisco VXI system components and the management tools that can be used to provision and monitor each element. It also provides a brief description of each associated capability and a link to additional documentation.
Data Center and Applications
The main data center components that need to be managed are the compute servers, hypervisor, virtual machines, storage, switching fabric, connection managers, and servers that provide network services. The management tasks include the provisioning of end users, virtual desktops, desktop pools, hypervisor, and storage, as well as the monitoring of sessions and use of resources (compute, memory, storage, and network). Table 15 summarizes the components and management tools.
Table 15 Data Center and Applications - Management Tools
Network Infrastructure
The main elements in the network infrastructure (LAN, WAN, and SAN) that need to be managed are the switches, routers, WAN acceleration devices, load balancers, security gateways, and network analyzers. These components span the data center, enterprise core, WAN, and branch offices and provide both data and storage connectivity. The management tasks include provisioning and monitoring these elements and monitoring a desktop virtualization session and reporting on network use (Table 16).
Table 16 Network Infrastructure - Management Tools
Desktop Virtualization Endpoints
The desktop virtualization endpoints that need to be managed are zero clients, thin clients, virtual clients, and web-based clients. The management of endpoints includes tasks to provision and monitor endpoints, update images, perform asset management, measure the quality of the user experience, and remotely access the endpoints. Use of enterprise desktop management tools such as Altiris, Cisco VXC Manager, Wyse Device Manager, and Unified CM is recommended to manage the desktop virtualization endpoint OS. See Table 17 for DV Endpoints - Management Tools.
Table 17 DV Endpoints - Management Tools
Unified Communications
The main unified communications elements that need to be managed are Cisco Unified IP Phones, Cisco Unified Personal Communicator clients, Cisco Cius Tablet, and Cisco Unified Communications servers (Cisco Unified Communications Manager, Cisco Unified Presence, and Cisco Unity® devices). The management of UC elements include tasks to provision and monitor the IP phones, Cisco Unified Personal Communicator clients, Cisco Unity accounts, and servers. The Cisco Unified Communication servers include an embedded web-based GUI management interface that can be used to complete the basic provisioning and monitoring tasks. The Cisco Unified Communications Management suite of tools is recommended for advanced management features, scalability, and performance (Table 18.)
Table 18 Unified Communications - Management Tools
Cisco VXI Management Tasks and Work Flows
This section presents use cases for an IT administrator and includes workflows for the most common operations that a Cisco VXI administrator performs in day-to-day operations. For example, adding a user might involve creation of a new desktop user in VMware vCenter, View Manager, and Microsoft Active Directory; configuration of a new phone and Cisco Unified Personal Communicator account in Cisco Unified Communications Manager, Cisco Unified Presence Server, and Cisco Unity; provisioning of a new desktop virtualization endpoint in VXC Manager and a DHCP server; and addition of storage, memory, compute, and network resources in the data center.
A unified management console for service management is an important management tool for a Cisco VXI system. This customized management application manages the main Cisco VXI components using interfaces provided by each vendor. Consider using off-the-shelf enterprise network managers that integrate with component-specific management tools through an API, protocol, or plug-in that exposes some aspects and features of the tool in the central management utility and allows the administrator to invoke the tool to access its full capabilities.
An orchestration tool is also an important management tool for large-scale deployments. It automates the tasks associated with a particular workflow (such as the addition of users, endpoints, and virtual desktops). The automation interface can also allow an end user to self-provision a virtual desktop without the assistance of an administrator by automating the interaction with each vendor-specific management tool. The topology diagrams in Figure 49 show actions in relation to components in the solution related to a particular workflow.
Consider using off-the-shelf enterprise network managers that support SNMP and syslog—for example, IBM Network Manager—which can also be used to manage elements in the system that support these protocols. The collection and correlation of logs from different devices in the system can be very useful for an administrator troubleshooting or monitoring a user session. Consider using Splunk, which is a tool that can perform this function. Consider using tools from the VizionCore tool suite (which includes applications such as vFoglight for virtual machine performance management and reporting and vControl for automation and workflow management) that provide advanced features to manage the virtual data center and storage infrastructure. The Cisco Intelligent Automation for Cloud software has a suite of automation tools that can be used to orchestrate the components of the Cisco VXI system. Please refer to the white paper "VXI Automation and the Cisco Intelligent Automation for Cloud Framework" for more details.
Figure 49 Cisco VXI Workflow- Add User
Add User
Table 19 Cisco VXI Workflow - Add User
Figure 50 Cisco VXI Workflow: Add User
Delete User
Table 20 Cisco VXI Workflow - Delete User
Figure 51 Cisco VXI Workflow - Delete User
Change User
Table 21 Cisco VXI Workflow - Update Desktop
Figure 52 Cisco VXI Workflow - Update Desktop
Table 22 Cisco VXI Workflow - Change Desktop
Figure 53 Cisco VXI Workflow - Monitor or Troubleshoot User Session
Monitor/Troubleshoot User Session
Table 23
Cisco VXI Workflow - Monitor or Troubleshoot User Session
Cisco VXI Management Tools
This section includes a summary and brief description of each management tool that can be used to provision and monitor the components of the system. It includes guidelines and best practices associated with the tools used and tasks being performed and reference links to additional documentation.
VMware vCenter and vSphere
The VMware vCenter and vSphere management suite is used to manage the hypervisor (VMware ESX and ESXi) running on hosts (physical compute servers). It enables administrators to manage multiple hypervisor hosts and to deploy and manage virtual machines and virtual appliances. It is also used to monitor compute, memory, storage, and network resource utilization on hosts and virtual machines; monitor system events; and generate reports. The VMware vCenter server is accessed and administered with the VMware vSphere client (Figure 54).
Figure 54 vSphere Client Interface
Guidelines for Using VMware vCenter and vSphere in the Cisco VXI System
Virtual Desktops
•
•
•
Provisioning
•
•
•
Note
•
•
•
•
VMware View Manager Administrator Console
VMware View Manager 5.0 is used for managing remote desktop sessions between desktop virtualization endpoints and virtual desktops. It authenticates users initiating a session and then redirects them to a virtual desktop. The VMware View Administrator Console (VMware View Administrator Console) is a web-based application used to deploy and manage desktop pools, control user authentication, monitor desktop use, examine system events, and perform analysis. VMware View 5.0 also includes the VMware View Agent running on the virtual desktop and the VMware View Client running on the desktop virtualization endpoint. Note that these are software components that also need to be managed as described here.
Figure 55 VMware View Administrator Console
Features and Guidelines for Using VMware View Manager Administrator Console in the Cisco VXI System
Provisioning
•
•
•
Cisco VXC Manager
Cisco's VXC Manager (VXC-M) is used to centrally manage an enterprise-scale deployment of Cisco VXC endpoints in the Cisco VXI system. It is used to efficiently provision, monitor, troubleshoot the VXC endpoints; perform asset management and inventory; remotely control and access the devices; update firmware and configuration using an enterprise policy based approach; generate reports. The VXC-M can also be used to manage Wyse endpoints with appropriate license installed. The VXC-M supports advanced device control, scripting and imaging capabilities. It supports secure (HTTPS based) imaging, compression, and bandwidth throttling for efficiency; device health status reporting, shadowing, remote control and scripting of the device, and default device configuration; device discovery and provides detailed device hardware and software asset information; client cloning feature that allows the administrator to capture the image and configuration on a reference client and deploy it across the enterprise. It also supports a distributed scalable architecture including the use of master and remote software repositories for deploying images.
Figure 56 VXC Manager Architecture
The Cisco VXC Manager includes the following components: management console GUI (MMC based snap-in) for administration, device management services for communicating with endpoints (includes HTTP, DHCP proxy and FTP support), a database for storing configuration and device information, and a master software repository for storing images, configuration files, and packages. The VXC clients run a web agent that enables communication with the VXC-M server.
The VXC-M management console includes a device, package, update, report, and configuration manager. The device manager displays the health status of all devices that check-in with the VXC-M server. The device status indicates green, yellow, or red depending on the check-in status of the device. The device checks-in to the server periodically to indicate device status and check for updates including configuration or firmware. The default device check-in interval is 5 minutes for PCoIP VXC clients. Other devices check-in every 60 minutes. The checkin interval can be configured in VXC-M. A device that is powered off will appear red in the device listing. Note that the device status does not include information about whether the device is idle or is actively being used in a remote desktop session. The Device manager also includes detailed information on the device hardware and software profile (including OS version), software installed, network settings, and packages installed. Devices can be logically grouped according to OS type, geographical location, building, floor, department or subnet. This makes it easier to view the status, apply policies, and deploy packages to a particular group of devices.
The device discovery feature allows desktop virtualization endpoints to be manually added to the device manager or discovered dynamically by the device manager by providing an IP address range or subnet within which to perform the discovery. The VXC Manager can remotely control a desktop virtualization endpoint, including reboot, shutdown, and wakeup (using Wake on LAN) operations. Shadowing allows the administrator to remotely access the DV endpoint console to verify settings and set up a remote desktop session. Shadowing can be useful for troubleshooting endpoint issues in real time. Management features available for endpoints depend on the endpoint OS or device type.
Figure 57 VXC-M Device Manager Console
The Package manager is used to deploy packages to VXC endpoints. A package is a collection of files (scripts, configuration files, or firmware images) that instruct the device to perform a set of actions (modify device settings, upload a configuration, download a firmware image, shutdown, reset,). The VXC-M script builder utility can be used for creating scripts to be included in packages.
Note
It is recommended to validate packages on a test device before deploying it across the enterprise. Note that the web agent update in package manager does not apply to VXC clients. The web agent running on a VXC client can be updated by changing the firmware of the device.
The update manager is used to schedule the deployment of packages to devices at a prescribed time (for instance during off-peak hours). The scheduled time is automatically adjusted to the time zone of the client device. For example, a package can be deployed to a group of devices to update the firmware at a scheduled time or to reboot a group devices in order to clear user sessions at 6pm everyday. The report manager can be used to generate a log report to troubleshoot administrative changes to the VXC-M; a device listing report which include a complete list of devices being managed; a package distribution report which includes package deployment logs and status (this report indicates successful package download to devices).
The configuration manager can be used customize settings on the VXC-M server, create device groups, setup subnets and IP ranges, and provision remote software repositories. The VXC-M settings include device check-in interval, enabling device security, changing logging levels, timeout preferences, and enabling default device configuration (DDC). Timeout preferences can be set globally for all endpoints or a subset of endpoints based on subnet. For example, the timeout can be adjusted for endpoints located across high latency WAN links. It is recommended to limit the number of simultaneous image updates across low bandwidth links (so that they are not slowed down to the point of failure due to timeout). This setting can be provisioned in configuration manager. In addition, the VXC-M supports role based access and provisioning of administrators with associated permissions. For example, read-only permissions can be assigned for a specific group of administrators. Integration with Active Directory (AD) allows addition of multiple administrative users who can be delegated to manage separate pools of endpoints organized by logical views, endpoint properties, OS and device type and subnet.
The repository creation and administration feature allows the administrator to easily build and administer a repository of software, images, and configuration updates for distribution. The VXC Manager server includes a master software repository, which acts as the image and package server. The master repository can be synchronized with a remote software repository that is located in a branch office. For remote locations such as a branch office, it is recommended to use remote file repositories that are local to the endpoints to conserve WAN bandwidth. Since the file transfers are completed using TCP based protocols (FTP and HTTP), any file transferred across the WAN would benefit from the acceleration, caching, and compression features of Cisco WAAS.
The VXC Manager Default Device Configuration (DDC) is a policy management tool that allows administrators to create rules for automatic deployment of OS images, scripts, packages, and other settings to thin-client end-points. DDC allows an administrator to configure default software and device settings for a group of devices to simplify and fully automate the management of their endpoints. For example, an administrator for a global organization can use DDC to map a subnet to a specific country. When an endpoint is connected to the network for the first time, DDC uses the subnet information to provision the DV endpoint with the correct language settings and configuration. The DDC feature ensures device configuration and image version conformance for all devices in a particular group (like building or subnet) running a particular OS. It is useful for automatically implementing the device configuration change based on a change in the subnet, physical location or device group of a device. For example, a VXC client can be easily migrated from one View environment to another and be re-configured automatically simply be changing the VLAN assignment of the device or physical port on a switch. Note that a DDC is applied to a device during the device bootup phase when it checks-in to the VXC-M server.
A package for PCoIP VXC client includes a script to change configuration settings and firmware and is applied to the device during the device check-in to VXC-M or by an administrator using the package manager.
Figure 58 VMware View Package Script
Typical use cases of VXC Manager
•
•
•
•
•
•
•
Use the VXC-M device manager dashboard to modify the following configuration on a PCoIP VXC client: VMware view client, label, video, and time zone settings.
Figure 59 ThreadX Device Information Window
Guidelines for using VXC manager:
When deploying a large number of desktop virtualization endpoints, a centralized configuration approach is recommended. This approach allows an endpoint to automatically detect the VXC manager and desktop controller locations and update itself with the correct image and settings. Endpoints should be provisioned with network settings, locations of VXC-M server, and the location of a desktop controller during bootup using DHCP, DNS, and FTP services. Refer to the VXC client and VXC Manager documentation for more information about the specific DHCP options to use here.
In addition, file server locations can provide configuration files instructing the endpoint to download updated images and configurations. The DV endpoints can be reset or reboot by end users. Alternatively, the administrator can centrally manage the power on VXC clients (using PoE switches with an EnergyWise compatible management application) or the administrator can use VXC Manager to centrally initiate this task and push configurations and image updates to endpoints. Remember that these settings (filer server, VXC Manager server, and desktop controller locations) can also be provisioned manually by accessing the endpoint through the console or web interface. Consult the Cisco VXC documentation for specific instructions for setting up a master file server repository, including the directory structure for storing configurations and images and the format of the configuration files for each desktop virtualization endpoint type being deployed.
Figure 60 VXC client boot process
The PCoIP VXC endpoint can be managed using a web interface to remotely access configuration settings, using on screen display available on the device console, using the device manager dashboard, or by using package manager feature on the VXC-M. The VXC endpoints can learn the VXC-M server location using DHCP options or using standard service (SRV) and DNS records that identify the location of the server. Use DHCP options (12 and 15) to specify the VXC-M server location (IP address, port, and secure port). Alternatively, VXC endpoints will query the DNS server for VXC-M server location (The hostname '_pcoip-tool' is used by PCoIP VXC clients). Note that the PCoIP VXC client will also query the DNS server for the View Manager location (The hostname is `_pcoip-broker'). The use of DNS can be useful in a deployment scenario where the DHCP service cannot be modified (for example, on a branch router located at a customer site). Finally, the use of manual or auto discovery of the endpoint in the VXC-M device manager is another method of informing the device of the VXC-M location. Use the subnet manager to define subnets and IP ranges on which to auto discover devices. This can be useful when the devices cannot be remotely rebooted in order to discover the VXC-M server.
FTP should be enabled on the master software repository during the VXC-M installation to support image deployment to PCoIP VXC endpoints.
The recommended method for creating and modifying package configuration files for PCoIP VXC devices is to use a text editor.
Ensure that all communication ports used by VXC Manager are open on the network used by VXC-M to communicate with endpoints and management console: 80,280, and 443 (HTTP); 21 (FTP); 1433 (database), and 5900 (VNC) Please consult Cisco VXC-M documentation for complete list of ports used by the server.
The VXC Manager can be installed on a single server or multiple servers for large deployments (by distributed services across multiple servers using the customized installation procedure). Note that multiple management consoles can be installed to facilitate remote access from multiple administrators.
Use the power management features to power on and power off endpoints at scheduled times to conserve energy. Note that only devices that support WoL can be powered on by the VXC-M.
Ensure that remote software repositories are synchronized with the master software repository. Use Microsoft synchronization services to synchronize the software repositories. When using remote software repositories across a WAN, it is recommended to deploy one remote repository per subnet located in a branch.
The recommended troubleshooting tools include Wireshark to monitor device and server communications, Microsoft debugviewer to log events and errors on the server including database communications, and the use of VXC-M server log reports.
Custom reports can be generated using any tools that are ODBC compliant (including Crystal reports, MS-ACCESS, MS-SQL client tool) and that can access the VXC-M database.
Wyse Device Manager
Wyse Device Manager (Figure 61) allows the administrator to perform image (OS), configuration, and asset management; remote control; monitoring; and shadowing of Wyse desktop virtualization endpoints. It can be used to plan and implement enterprise-scale endpoint device discovery, upload and download endpoint parameters, and distribute software packages to endpoints. It also supports a thin-client cloning feature that allows the administrator to capture the image and configuration on a reference thin client and deploy it across the enterprise. It allows the creation of customized scripts that are distributed to endpoints to automate endpoint device setup and configuration. You should validate scripts on a test device before deploying it across the enterprise. It supports thousands of Microsoft Windows Embedded Standard (WES) or Compact Edition (CE), Linux, Wyse ThinOS, or Wyse XP Embedded (XPe) thin-client devices deployed across a LAN, WAN, or wireless network. Wyse Device Manager Enterprise Edition is recommended for large-scale deployments for added security, scalability, and performance features (note that the Workgroup Edition supports up to 750 endpoints). Refer to the Wyse documentation for a complete list of features. You should use Wyse Device Manager to manage Wyse desktop virtualization endpoints to enable a more centralized and hands-on approach.
Figure 61 Wyse Device Manager Console
The asset information collection feature allows Wyse Device Manager to track hardware revision of endpoint and software OS, application, and add-on versions that have been applied. Wyse Device Manager monitors and stores all asset information about each device (including hardware asset information and information about the software that is installed on each device). Software information includes the operating system, as well as all applications and add-ons that have been applied to the endpoint device. Note that Wyse Device Manager can monitor the status of the write filter on thin clients running the XPe client OS. Reports can be generated to provide a list endpoints being managed, endpoints scheduled for updates, current endpoint software revision levels, server logs, and endpoint availability based on the endpoint uptime.
The device management feature allows the administrator to view and monitor the status of the desktop virtualization endpoints in real time. Wyse Device Manager can be configured to automatically provide up-to-date status information for all endpoints. To remotely manage an endpoint, a Wyse Device Manager agent should be installed on the endpoint. The agent needs to be provisioned with the address of the Wyse Device Manager server. This provisioning can be performed automatically during the device discovery process, or can it be performed manually on the endpoint. It can also be performed using DHCP options during endpoint bootup or using standard service (SRV) and DNS records that identify the location of the server. The agent running on the endpoint periodically checks in with the device manager using the heartbeat mechanism and looks for any updates. The agent also reports any status changes to the server. The device discovery feature allows desktop virtualization endpoints to be manually added to the device manager or discovered dynamically by the device manager by providing an IP address range within which to perform the discovery.
Wyse Device Manager can remotely control a desktop virtualization endpoint, including reboot, shutdown, and wakeup (using Wake on LAN) operations. Shadowing (using VNC) allows the administrator to remotely access the endpoint console to verify settings and set up a remote desktop session. Shadowing can be useful for troubleshooting endpoint issues in real time. Note that in addition to allowing configuration access directly from the endpoint console, some zero and thin clients (Viance and P20) allow the administrator to remotely access configuration information through a web-based GUI.
The desktop virtualization endpoint updates include updates to the image (OS), applications (agent), and settings (network and connection), and these can be initiated by the device manager server according to a schedule (to reduce downtime and move it to off-peak hours) or when the device checks in to the server. The repository creation and administration feature allows the administrator to easily build and administer a repository of software, images, and configuration updates for distribution. The Wyse Device Manager server includes a master software repository, which acts as the image and package server. The master repository can be synchronized with a remote software repository that is located in a branch office. For remote locations such as a branch office, you should use remote file repositories that are local to the endpoints to conserve WAN bandwidth. Since the file transfers are completed using TCP based protocols (FTP and HTTP), any file transferred across the WAN would benefit from the acceleration, caching, and compression features of Cisco WAAS.
When deploying a large number of desktop virtualization endpoints, a centralized configuration approach is recommended. This approach allows an endpoint to automatically detect the desktop controller location and update itself with the correct image and settings. Endpoints should be provisioned with network settings and the location of a desktop controller during bootup, through DHCP. Refer to the Wyse thin-client and Wyse Device Manager documentation for more information about the specific DHCP options to use here.
In addition, file server locations can provide initialization files instructing the endpoint to download updated images and configurations. Users can be instructed to reset or reboot their endpoints through e-mail notification with instructions, or the administrator can use Wyse Device Manager to centrally initiate this task and push configurations and image updates to endpoints. Remember that these settings (filer server, Wyse Device Manager server, and desktop controller locations) can also be provisioned manually by accessing the endpoint through the console or web interface. Consult the Wyse documentation for specific instructions for setting up a master file server repository, including the directory structure for storing configurations and images and the format of the configuration files for each desktop virtualization endpoint type being deployed.
Wyse Device Manager Default Device Configuration (DDC) is a policy management tool that allows administrators to create rules for automatic deployment of OS images, scripts, packages, and other settings to thin-client endpoints. DDC allows an administrator to configure default software and device settings for a group of devices to simplify and fully automate the management of their endpoints. For example, an administrator for a global organization can use DDC to map a subnet to a specific country. When an endpoint is connected to the network for the first time, Wyse Device Manager DDC uses the subnet information to provision the thin-client endpoint with the correct language settings and configuration.
EMC Unisphere Management Suite
The EMC Unisphere (Figure 59) management suite is used to provision and monitor the EMC Unified Storage device. It provides a web-based interface that allows administrators to discover, monitor, and configure storage systems. It can also be used to collect storage latency measurements and to perform trend analysis, reporting, and system capacity management. It supports automatic notification of events, allowing the administrator to proactively manage critical status changes.
The EMC Unisphere is virtualization-aware. It provides visibility into how the hypervisor server is configured and identifies which virtual machines are consuming specific storage resources. It provides virtual-to-physical mapping of physical storage and servers as well as VMware ESX hosts and the virtual machines that reside on them. It allows administrators to ensure that the appropriate amount of storage is allocated to virtual machines.
VMware administrators can use the EMC Virtual Storage Integrator (VSI) to manage commonly used storage features from vSphere client without the need to access a separate storage management interface. The VSI is a VMware vCenter plug-in that provides visibility into the EMC Unified storage. The VSI simplifies the job of mapping vSphere datastores to LUNs and NFS shares on the EMC storage, and helps pinpoint the location of virtual machines and raw device mapping files on the array.
Since the storage device (NAS or SAN) maintains the virtual machine configuration and files for many end user desktops, it represents a critical resource in the Cisco VXI system. In addition to using the redundancy and fault tolerance built in to the storage device itself, you should back up storage to another physical location, to enable restoration of service in the event of a failure.
NetApp Virtual Storage Console
The NetApp Virtual Storage Console (VSC) is recommended for provisioning and monitoring the NetApp FAS 3170. NetApp VSC is a plug-in that can be installed in VMware vCenter. The NetApp VSC provisioning and cloning capability can be used to deploy NetApp space-efficient clones. Administrators can provision or reprovision thousands of new virtual machines without logging into the NetApp storage console.The VSC allows administrators to leverage NetApp FlexClone technology and redeploy virtual machines after patching or software updates, thin provisioning, and deduplication management capabilities.
Cisco NAM
The Cisco NAM Traffic Analyzer software (Figure 61) allows administrators to monitor, manage, and improve the way that applications and services are delivered to end users. Cisco NAM offers flow-based traffic analysis of applications, hosts, conversations, and streams that use differentiated services code points (DSCPs); performance-based measurements of application, server, and network latency; QoE metrics for network-based services such as voice over IP (VoIP) and video; and problem analysis using deep, insightful packet captures. Cisco NAM can monitor traffic, collect packet traces, and generate historical reports. It can provide comprehensive traffic analysis and insightful troubleshooting information in real time, which can be used to increase the efficiency of the network and applications. Cisco NAM can also be used to validate QoS planning assumptions to help ensure that service levels are met and to assess the user experience with transaction-based statistics. Consider the guidelines and recommendations presented here when using Cisco NAM to monitor and troubleshoot a Cisco VXI system.
Note that Cisco NAM includes an embedded, web-based traffic analyzer GUI that provides access to the configuration menus and presents easy-to-read performance reports about web, voice, and video traffic utilization through the browser. You should dedicate a separate management interface on the Cisco NAM appliance for accessing the GUI.
Cisco NAM comes in several form factors and can be deployed in different locations of the network. The Cisco NAM probe should be placed in a location suitable to the specific task being performed. Any location that is the ingress or egress point of a logical network boundary (aggregation layer, core, or campus edge) can offer valuable insights into the network activity within that partition and is usually a good choice for Cisco NAM deployment. For example, you should place Cisco NAM in the data center core to monitor sessions connecting to critical server farms, such as the connection manager. This location would allow you to monitor sessions initiated by end users located in all parts of the enterprise network. Cisco NAM can also be placed in a branch office to troubleshoot a particular set of users connecting across a WAN. The WAN edge is the optimal location for monitoring sessions originating from multiple branch offices. In the branch office, Cisco NAM can be deployed as a network module on a Cisco ISR branch-office router, or in the core network as a blade on a Cisco Catalyst 6000 Series core
switch or a separate appliance (Cisco NAM 2204 or 2220 Appliance.) Cisco NAM can also be deployed as a software module on the Cisco Nexus 1000V or the Cisco WAAS device. In the data center core, you should deploy a separate Cisco NAM appliance, which uses dedicated hardware to provide the required level of performance. Refer to the Cisco NAM deployment guide for a comprehensive discussion of considerations for Cisco NAM deployment.
Use NetFlow Data Export (NDE) from a remote router to Cisco NAM for network traffic utilization reports. The NetFlow data can be exported from a Cisco WAAS appliance (to monitor the traffic across the WAN), router, switch, or Cisco ASA appliance. For example, NetQoS flow data from Cisco WAAS can provide information about application latency. The traffic utilization reports will help identify traffic types that will benefit from QoS policies and Cisco WAAS optimization. These measurements can also be used for growth forecasting and planning (Figure 62).
Figure 62 Cisco Network Analyzer Module Traffic Utilization Report
Switched Port Analyzer (SPAN) sessions on a core switch capable of monitoring multiple source ports, such as the Cisco Catalyst 6000 Series or Cisco Nexus 7000 Series Switches, should be used for packet captures. Use a SPAN port (preferably 10 Gigabit Ethernet) on the data center core switch (Cisco Nexus 7000 Series) to monitor all traffic to and from the data center servers. Note that there is a limit of 2 SPAN sessions on the switch.
The main use of Cisco NAM is to troubleshoot and analyze a user session that fails to set up correctly or a user session with poor quality. To display a specific conversation, a packet capture can be filtered based on the endpoint, desktop controller, or virtual desktop network address. It can also be filtered based on VLAN, protocol (port), or DSCP marking in the stream.
Note that Cisco NAM is not currently capable of decoding the contents of a desktop virtualization protocol packet, since the protocol format is proprietary and may be encrypted. Cisco NAM can identify and label the stream based on the port numbers used (Figure 63).
Figure 63 NAM Packet Decoder
Table 24 lists the protocol and port used by desktop virtualization sessions. This information can be utilized to identify the user streams in a packet capture:
Table 24
Protocol/Port Information
Note that a typical VMware View session setup (desktop virtualization endpoint to VMware View Manager stream) uses TCP (port 80) and Transport Layer Security Version 1 (TLSv1; port 443). The communication between VMware View Manager and View Agent uses TCP (port 4001). The VMware vCenter server's VMware vSphere client and software development kit (SDK) interface uses HTTP (80) and HTTPS (443). VMware vCenter communication to the VMware ESXi host uses a TCP (port 902) stream. The VXC Manager defaults to HTTP (80) and HTTPS (443) for communication with desktop virtualization endpoint agents. The administrator should make sure that these ports are open on all firewall devices.
Packet capture of the traffic from a virtual desktop running Cisco Unified Personal Communicator with an active voice call does not include any Real-Time Transfer Protocol (RTP) traffic, since the Cisco Unified Personal Communicator client is running in desk phone control mode. The UC signaling traffic uses the following ports: SCCP TCP 2000 and SIP TCP/UDP 5060.
The desktop packet capture does include Cisco Unified Personal Communicator client communications with Cisco Unified Presence and Cisco Unified Communications Manager through the Computer Telephony Integration (CTI) protocol. The packet capture of a Cisco IP Phone that is co-located with the desktop virtualization endpoint does include the RTP traffic. Cisco NAM can also collect RTP metrics used for audio-quality measurements from the Cisco Unified Management Suite.
Cisco Netflow
Cisco NetFlow provides statistics on packets flowing through network elements (routers and switches) and can be used to monitor traffic utilization in a Cisco VXI system. Netflow data can be used for application and user monitoring, network bandwidth analysis and capacity planning, security analysis, accounting and billing, traffic engineering, and NetFlow data warehousing and data mining. Netflow is supported on the following routing and switching platforms: Cisco ISR and 7200, 10000, 12000, CRS-1 Series Routers; Catalyst4k, Cat6500, and Nexus switches.
NetFlow captures data from ingress and egress packets on a network element that includes a rich set of packet characteristics like IP address, protocol, application port, and DSCP or type of service (ToS) information, packet size, and count. The main components of NetFlow are the NetFlow cache that stores IP flow information, and the NetFlow export that sends NetFlow data to a network management collector, such as the Cisco NetFlow Collector. NetFlow collectors aggregate exported NetFlow records to provide monitoring and reporting information regarding the IP traffic flows within the network. NetFlow accounts for every packet (non-sampled mode) and is transparent to the end user. The key to NetFlow-enabled switching scalability and performance is the efficient flow cache management which is capable of dynamically updating per-flow accounting measurements residing in the NetFlow cache, and cache aging/flow expiration determination. Expired flows are grouped together into datagrams for export to the Netflow collector.
It is recommended to use the latest NetFlow export format Version 9 which represents a flexible and extensible means for carrying NetFlow records from a network node to a collector. NetFlow Version 9 has definable record types and is self-describing which allows for easier NetFlow Collection Engine configuration.
Guidelines for using Cisco Netflow:
•
•
•
•
Typical Use Cases of Netflow:
•
•
•
•
•
Steps to enable Netflow in a Cisco VXI network workflow:
1.
a.
b.
2.
a.
3.
4.
Figure 64 Netflow Analyzer report on Orion Network Performance Monitor
Cisco NetFlow Collector (NFC) is a scalable data collection and aggregation product that provides a centralized view of data, analysis and reporting. NFC enables enterprises to optimize network infrastructure for application delivery and network capacity planning. The Cisco NAM can also be used as a netflow collector and analyzer and supports basic functionality. Alternatively, Netflow analyzers from ManageEngines, Solar Winds, or NetQOS will support advanced reporting and analysis capabilities as well as a larger database.
Note
Note
Cisco EnergyWise Orchestrator
Cisco's EnergyWise Orchestrator provides a centralized interface for measuring, reporting and regulating energy consumption in the Cisco VXI system. It integrates with Cisco's EnergyWise technology to manage power consumption on a wide array of IT devices including DV endpoints, desktop PC's, laptops, IP phones, routers, switches, access points and any device that supports EnergyWise technology. It supports sophisticated energy management policies that enhance energy savings. It can generate compelling reports for policy optimization, troubleshooting, and demonstration of energy savings. As a key component in an Energy management architecture, the EnergyWise Orchestrator derives its importance from its ability to reduce energy consumption and costs, provide measurable return on investment (ROI), allow compliance with government regulations, reduce greenhouse gas emissions and increase overall sustainability.
For example, in a building with a core router, 10 access switches, and 400 end points, such as phones, access points, and PCs running the EnergyWise SDK, an EnergyWise domain called MyBuilding can be created with the router and switches as domain members. The domain members form neighbor relationships using CDP or EnergyWise UDP messages and forward EnergyWise messages (queries) to other members and to end points. Note that the EnergyWise protocol uses port 43440 for communications between members and management stations. EnergyWise queries support set, collect, save, summarize operations on the power state of domain members and endpoints. Once the domain is setup, SNMP or EnergyWise API on the domain member can be used to monitor and control power usage from a centralized management station like EnergyWise Orchestrator. Policies can also be manually configured on domain members using the router CLI, referred to as recurring events or recurrences, to use time-of-day settings to automatically manage power usage. The power on an EnergyWise endpoint can be controlled manually (via the switch CLI or an EnergyWise query) or automatically via recurring event provisioned on the switch or policy created on the Orchestrator.
Figure 65 Cisco EnergyWise Orchestrator Architecture
The EnergyWise orchestrator communicates with all EnergyWise network elements using the EnergyWise protocol and provides comprehensive power management for PCs via the EnergyWise API. The EnergyWise proxy acts as a bridge between the Orchestrator Server and the Cisco EnergyWise protocol compliant devices. The EnergyWise PC agent enables EnergyWise on desktop PC's and laptops. It operates transparently to the end user and enforces power policies received from the Orchestrator server. It stores utilization information locally on the PC and relays this to the server periodically.
The Orchestrator provides multiple management interfaces: the Orchestrator Administration Console (that can be used by IT administrators), the Sustainability Dashboard (that can be used by executives, employees, customers, etc.), and Wake for remote access (that can be used by IT staff and employees that needs to wake PCs remotely). The Administration Console provides an easy to use web-based GUI for centralized administration of device power states, real-time monitoring, policy-based management, monitoring of actual PC usage for intelligent policy authoring. It supports group-oriented administration with role-based security privileges and event reporting for analysis and troubleshooting. It can be used to alter or view power state of device in real-time, manually change device policy or group membership, or edit EnergyWise attributes for a device or PC.
An enterprise power policy dictates when devices turn on or go into low power mode. For PCs, policy also defines: IDLE timeouts when not used and exception handling for end-users and business applications. Orchestrator offers a graphical, time based view of policy schedule. When PCs transition to low power mode, administrators can optionally, allow users to skip the power state change, or allow users to delay the state change by fixed amount of time, and specify a message seen by the PC user prior to state change. Policies can also disable sleep and shutdown if remote users are logged into the PC. Policies also govern how applications behave when PC sleeps or shuts down. In this case, applications can be gracefully ended or instead the state change can be aborted.
Cisco EnergyWise is an energy management architecture based on an intelligent network-based approach to manage the power consumption of powered devices which include Cisco devices and all the connected end points. An EnergyWise domain is treated as one logical unit of power management and consists of management stations, domain members, and endpoints. An end point is a device connected to the network, such as an IP phone, access point, DV endpoint or PC. Endpoints receive power from domain members like PoE switches. EnergyWise is supported in Catalyst 2960, 3560, 3750, 4500, 6500 Series switches, and the Cisco ISR G2 routers and Enhanced EtherSwitch Service modules.
For example, in a building with a core router, 10 access switches, and 400 end points, such as phones, access points, and PCs running the EnergyWise SDK, an EnergyWise domain called MyBuilding can be created with the router and switches as domain members. The domain members form neighbor relationships using CDP or EnergyWise UDP messages and forward EnergyWise messages (queries) to other members and to end points. Note that the EnergyWise protocol uses port 43440 for communications between members and management stations. EnergyWise queries support set, collect, save, summarize operations on the power state of domain members and endpoints. Once the domain is setup, SNMP or EnergyWise API on the domain member can be used to monitor and control power usage from a centralized management station like EnergyWise Orchestrator. Policies can also be manually configured on domain members using the router CLI, referred to as recurring events or recurrences, to use time-of-day settings to automatically manage power usage. The power on an EnergyWise endpoint can be controlled manually (via the switch CLI or an EnergyWise query) or automatically via recurring event provisioned on the switch or policy created on the Orchestrator.
Figure 66 Cisco EnergyWise Orchestator Sustainability Dashboard
Cisco EnergyWise is an energy management architecture based on an intelligent network-based approach to manage the power consumption of powered devices which include Cisco devices and all the connected end points. An EnergyWise domain is treated as one logical unit of power management and consists of management stations, domain members, and endpoints. An end point is a device connected to the network, such as an IP phone, access point, DV endpoint or PC. Endpoints receive power from domain members like PoE switches. EnergyWise is supported in Catalyst 2960, 3560, 3750, 4500, 6500 Series switches, and the Cisco ISR G2 routers and Enhanced EtherSwitch Service modules.
For example, in a building with a core router, 10 access switches, and 400 end points, such as phones, access points, and PCs running the EnergyWise SDK, an EnergyWise domain called MyBuilding can be created with the router and switches as domain members. The domain members form neighbor relationships using CDP or EnergyWise UDP messages and forward EnergyWise messages (queries) to other members and to end points. Note that the EnergyWise protocol uses port 43440 for communications between members and management stations. EnergyWise queries support set, collect, save, summarize operations on the power state of domain members and endpoints. Once the domain is setup, SNMP or EnergyWise API on the domain member can be used to monitor and control power usage from a centralized management station like EnergyWise Orchestrator. Policies can also be manually configured on domain members using the router CLI, referred to as recurring events or recurrences, to use time-of-day settings to automatically manage power usage. The power on an EnergyWise endpoint can be controlled manually (via the switch CLI or an EnergyWise query) or automatically via recurring event provisioned on the switch or policy created on the Orchestrator.
Figure 67 Cisco EnergyWise Monitoring
EnergyWise attributes are user-specified values assigned to domain members and end points that provide context about how the device is used in the organization. Devices can be assigned keywords and rated based on the importance in the organization. The attributes can be used to search for and control devices devices satisfying a particular criteria when generating a report or applying a policy for example, all PC's on the second floor used by the finance department. The importance attribute (range from 1 to 100) is used to rate the devices based on the business priority. A public desk phone would have a lower importance (10) than a business-critical emergency phone (100). For example, a PoE switch that provides power to an end-point IP phone and to other connected devices would have a great importance than the connected devices. Use keyword attributes to tag devices or interfaces with location and user information. Examples include: IT, lobby, HumanResources, Accounting, router, phone, floor2. The role attribute groups devices based on a specific use or device function. For example interface, switch model number, Lobby, Teller, HelpDesk, or GuardDesk. Once the attributes are assigned, a policy can be used to turn off all devices with importance less than 70 after 6pm. Refer to EnergyWise documentation for more guidelines on setting the specific device attributes.
EnergyWise uses a standard set of power levels (0 to 10, where 0 is off and 1 - 10 is on) to manage power usage on devices from different manufacturers consistently. This allows the end point to determine the appropriate action when EnergyWise sets the power level to each of these standard levels. The following diagram summarizes the modes of operation associated with different power levels.
Cisco's EnergyWise Orchestrator can be used to monitor, control, and conserve power consumption on EnergyWise enabled network elements and endpoints in a Cisco VXI deployment. Cisco VXI desktop virtualization endpoints like thick PC's and thin clients running the Orchestrator Client can be managed directly by the EnergyWise Orchestrator. The power consumption on DV endpoints like VXC clients (zero clients) that use PoE can also be monitored and controlled by managing the attached port on an EnergyWise enabled switch.
A Cisco VXI user power policy could include managing power for all Cisco VXI components unique to that user like the associated IP phone, VXC endpoints and virtual desktops. An energy policy can be used to shut down and power on IP phones, VXC endpoints, and virtual desktops at a specific time of day. For example, The PCs and zero clients on the first floor automatically power on at 6am and power off at 8pm. A Cisco VXI user power consumption report would report and chart energy usage by IP phones, VXC endpoints and thick clients over the last month, and year. It would report on power usage patterns (peak, average, lows) and summarize the cost savings using the specified energy policy. The power levels on Cisco VXI endpoints can be managed dynamically in real-time by managing selecting devices, viewing current power levels and setting power levels in the EnergyWise Orchestrator Administration console.
Steps for adding endpoints to an EnergyWise Orchestrator workflow:
1.
a.
b.
2.
3.
a.
4.
Guidelines for using EnergyWise Orchestrator:
Note
Note
Tip
Currently, the EnergyWise compatible client is supported on the following desktop operating systems: Windows 7, Windows Vista, and Windows XP (SP3). The client may install successfully on a thin client running Windows embedded OS but this application is not currently supported.
In larger Cisco VXI deployments, the Orchestrator server can be scaled by distributing services (including server, provisioning, database, and proxy) across multiple physical servers for example by installing the proxy on a separate physical server and using multiple proxy servers. For smaller deployments (POC), the orchestrator server, database, provisioning server, and proxy server can be installed on a single windows server.
Use the EnergyWise management station and endpoint toolkit SDK's available from Cisco to enable EnergyWise support on management stations and endpoints. Note that successful implementation of the EnergyWise SDK's requires that the domain members run EnergyWise Phase 2 or later. To display the EnergyWise version running on the switch, use the "show energywise version" command. An upgrade of switch software may be required to support the correct EnergyWise version.
Cisco Prime LAN Management Solution (LMS) 4.0 can be used to manage an EnergyWise enabled network. It supports the following features and capabilities: discover EnergyWise-capable devices, automatically upgrade devices to the proper Cisco IOS software release, set the EnergyWise domain and attributes, monitor and report power usage, troubleshoot EnergyWise. Note that Cisco Prime LMS EnergyWise feature support is focused on provisioning and monitoring of the domain members (including network elements like routers and switches) while the EnergyWise Orchestrator is designed to control and apply sophisticated power management policies on endpoints like thick clients and desktop PC's.
Desktop Management Tools
Desktop provisioning and monitoring is critical to successful management of a Cisco VXI system. The challenge of VXI is to deliver a customized Microsoft Windows desktop to every user without bringing all the PC management issues from the desktop to the data center. The complexity associated with meeting end user expectations for a VDI desktop experience that matches their desktop PC experience can lead to delays or failures with the implementation desktop virtualization initiatives and projects such as, Windows 7 migration, application, and desktop migration. It is critical to eliminate these impediments to broad-based Cisco VXI deployment in order to help IT organizations meet their intended strategic objectives and goals.
Virtual desktops and desktop virtualization endpoints can be managed using standard Microsoft Windows software management tools such as Altiris. These tools can be used to push out agent updates, OS fixes, security updates, and applications. The Microsoft Windows desktop user profiles can be managed and applied to desktops using tools such as AppSense, Liquidware Labs ProfileUnity, and VMware View Persona. These desktop personalization tools improve login times and prevent the corruption of user profiles. The complete desktop image including applications and persona can be managed with Unidesk.
Desktop Provisioning
Taking the approach of managing virtual desktops as though they were individual physical desktops can substantially increase CapEx as a result of unnecessary consumption of SAN or NAS storage and can increase OpEx by statically assigning users to specific HVD's in the data center. When users are assigned to a specific HVD, then if that HVD hangs or its performance starts to degrade, then the end user must contact Desktop Support to troubleshoot their desktop. The goal of VXI desktop management is to deliver a dynamic desktop the end user (with their favorite applications) at runtime from a single golden image with virtualized user persona while maintaining a small subset of desktop images. The administrator can efficiently maintain and troubleshoot issues with the user's desktop and applications. The end users can install applications and personalize their settings.
By using a combination (one or more) of three key virtualization technologies in a best-practices framework, VXI deployment TCO (OpEx, CapEx) may be substantially reduced and productivity gains can be realized. These three technologies are User Virtualization, Application Virtualization and Desktop Layering. These three key virtualization technologies permit IT organizations to deliver desktops replicating the traditional end user PC experience whilst managing their data center desktop infrastructure using pooled, non-persistent HVD images.
•
•
•
When these technologies are combined, all of those characteristics that make a particular end user's desktop unique to that end user have been abstracted away from the Windows OS and may be managed as independent entities. The decoupling of the user persona from a specific Windows OS instance permits that persona to be applied to any Windows OS instance at any time. Decoupling applications through either virtualization or layering allows patches or upgrades to be applied to only a single virtualized or layered app instance, which will then benefit all users of the application the next time they launch it. Finally, the decoupling of user personas and applications from the Windows OS permits a very stripped-down, `vanilla' base golden image to be used in a pooled, non-persistent VXI model for a large variety of end users. This reduces the storage footprint and facilitates centralized patching and updates to the golden OS image. There will always be a design trade off between using persistent and non-persistent desktops in terms of the amount of customization a user is allowed to perform.
AppSense User Virtualization Platform
The AppSense User Virtualization Platform (AppSense UVP) is a User Virtualization solution that:
•
•
•
Business drivers that lead to the adoption of the AppSense UVP include:
•
•
•
The integration of Cisco VXI and AppSense UVP improves the end user acceptance of their virtual desktop by providing the flexibility end users expect while improving their deployment's ROI through reduced management and migration expenses. It permits IT staff to deploy desktops using a pooled, non-persistent model. This model is one of the easiest, and least expensive VDI models to deploy and maintain, while providing the end user the customized desktop experience they have come to depend upon from the traditional use of a single-pc-per-user model.
In addition, the inclusion of the AppSense UVP facilitates faster response to and resolution of desktop configuration issues experienced by Cisco VXI desktop users. Since only a single, well tested, approved OS `golden image' is used for all desktop instances, desktop support tickets arising from end-user inflicted damage to the OS image itself are eliminated as a source of VDI desktop issues. Further, since all VDI user's desktop profiles are stored in a single, centralized configuration repository, desktop support staff no longer need remote access to an end-user's physical PC to examine registry settings and application configurations. Instead, they can use the management tools provided by the AppSense UVP to see the exact desktop configuration of any user in the Cisco VXI community and roll back a user's configuration to a prior known-working checkpoint as appropriate.
Design Considerations
The AppSense UVP permits the use of Pooled, Non-Persistent Desktops as the primary VDI deployment model, while binding each VDI user's desktop customizations to the non-persistent desktop at runtime. AppSense decouples the VDI user's desktop configuration from the OS itself, permitting each setting to be manipulated independently. In this fashion, a single OS `golden image' may be used to launch a desktop session for a VDI user and then the AppSense UVP may be used to add each user's desktop `personality' to the running desktop session dynamically and on-demand as a user utilizes different aspects of his/her desktop environment.
The AppSense Environment Manager abstracts all user desktop and application settings from the Windows OS and stores those settings in a MSFT SQL Server RDBMS. The user settings are persisted in a structured OS independent format, enabling the solution to work across all versions of Microsoft Windows from Windows XP to Windows 7. The Environment Manager may be deployed with multiple redundant servers for high scalability and availability. It is recommended to apply the appropriate backup strategies to the MSFT SQL Server database in order to meet business continuity requirements. Microsoft SQL mirroring, Microsoft IIS load balancing and failover architectures are all supported.
One of the key strengths of the Cisco VXI System is the UCS blade computing platform which hosts the virtual machines within which the various enterprise applications needed to run an enterprise and VDI desktops may be hosted. UCS was designed to provide stateless computing resources for hosting virtual machines. UCS blades are configurable at blade boot time; effectively the `blade personality' is bound dynamically to the blade on demand at boot. The AppSense UVP permits the extension of this `stateless computing infrastructure model' all the way up the VDI software stack through the Windows OS itself, and into individual desktop instances.
This `stateless' approach to physical server, VM and desktop deployment can be used to improve Business Continuity scenarios in which desktops may have to be migrated not only between servers in a data center but also between data centers on an emergent basis. With AppSense UVP the number of HVD `golden images' can be greatly reduced and the need to manage images on a per-user basis is eliminated. This results in less administrative and patching overhead for IT, and reduces the amount of information that must be replicated across server farms to support robust Business Continuity scenarios. Similarly, the AppSense architecture lends itself to straightforward replication and redundancy to provide High Availability for the service itself.
Figure 68 Logical integration of AppSense User Virtualization Platform with the Cisco VXI System
In conjunction with user personalization management, the AppSense UVP also has a fully featured enterprise policy management framework that is used to implement a desktop environment that is compliant with corporate requirements. The policy feature set delivers the required corporate compliance and governance for the desktop by ensuring the correct network drive mappings, printers, and other, are correctly provisioned. These depend on factors such as the location of the user or the application in use. The AppSense UVP's policy engine can also be used to address a number of advanced desktop configuration, customization and security use cases as well. The policy engine is able to control access to application and network resources based on a number of session parameters such as current time, user AD group membership, client IP or MAC address.
At a high level, the AppSense UVP adheres to a scalable 3 tier model consisting of a client agent, a middle tier web application (IIS) with a Microsoft SQL Server as the third tier storage mechanism:
The AppSense UVP management infrastructure consists of two components:
•
•
Both of these components have HVD based agents that deliver the users profile with highly scalable second tiers that are delivered as Microsoft IIS applications that leverage the UCS infrastructure for scalability, disaster recovery and business continuity. Cisco's ACE can be deployed as a load balancing and server failover solution in front of the AppSense application server tier. The third tier consists of two Microsoft SQL Server instances as repositories for the Management Center and Personalization Server applications, respectively. These database instances may be hosted by the same SQL Server instance although best practice for an enterprise deployment would be to physically separate the instances onto separate servers.
The Management Center is responsible for tracking all of the AppSense managed desktops and for managing the client configuration of agents and agent configuration on those desktops. A Client Communications Agent (CCA) resides on each managed HVD with the purpose of interacting with the Management Server to ensure that the appropriate set of agents (both management and environment) are present and current on the HVD.
The Personalization Server acts as the intermediary between the environment management agent installed on a managed desktop and the Microsoft SQL database that stores the user profiles for user personalization. All communications between the client agents and their respective management frameworks are either HTTP or HTTPS.
The AppSense Environment Manager is compatible with all leading VDI solutions including VMware View and Microsoft RDS in addition to working in a physical desktop environment. Additionally, it provides seamless application of user configuration settings to applications installed directly into the HVD or delivered as virtualized or remote applications by Altiris SVS. The Cisco Virtualization Experience Clients (VXC) and all standard thick, thin and zero client endpoints are compatible with an AppSense instrumented virtual desktop.
Note that user installed applications and user data is not captured by the AppSense UVP. It is recommend to re-direct the user data to a network file share to allow access from any desktop. User installed applications will be removed when the non-persistent desktop is refreshed. If user installed applications need to be retained, it is recommended to use persistent desktops.
Deployment, Configuration, and Best Practices
The AppSense Environment Manager can be integrated into a VXI system in order to virtualize the user profiles and customize pooled, non-persistent desktops facilitating dynamic desktop and image delivery in a VMware View environment.
The View environment should be configured to use pooled, non-persistent desktops using linked clones. User personas can be virtualized with AppSense and ThinApp can be used to deliver the virtualized productivity applications. Note that currently AppSense is not compatible with all ThinApp features. Please consult AppSense documentation for specific implementation limitations.
The AppSense personalization server and management center runs on the Windows 2008. The CCA agent should be installed in virtual desktops running Windows XP and Windows 7.
The `Golden Image' for these desktops should include the AppSense CCA and the AppSense EM agents pre-installed. Where reasonable, such as designation of network storage for each user, GPO settings currently enforced by the Active Directory (AD) server can be moved into the AppSense UVP policy management framework.
The VMware vSphere hypervisor can be used for both hosting HVDs and for hosting the AppSense UVP server virtual machines. The applications can be delivered to the desktops using ThinApp with applications streaming delivery. The virtualized applications should be stored on network file share and made available on the desktop using a shortcut. SQL Express can be used as the database service for the AppSense UVP. For enterprise production environments, it is recommended to use Microsoft SQL Server 2008.
Cross-platform and policy enforcement capabilities of the AppSense UVP were also evaluated. In one use case, the AppSense UVP was installed on a virtualized Windows XP desktop and was used to collect desktop configuration changes on that desktop. The settings included wallpaper, IE home page, bookmarks, Word settings, folder re-direction, and Cisco Unified Personal Communicator settings. Note that with AppSense, the user does not have to log off the desktop for the profile settings to be saved in the central repository as is the case with roaming profiles and other user personalization tools.
This approach to capturing user personal settings is considered the passive approach after the agent is installed and the migration settings feature of AppSense UVP is enabled. The user is expected to run through their regular workflows over a period of time to ensure all apps/features have been accessed and the appropriate configuration settings recorded. Once the user persona had been captured by AppSense on the XP desktop, the same user logged into a Win 7 HVD with the AppSense agent installed and it was confirmed that the desktop configuration created in the Windows XP instance was applied to the Windows 7 instance. It is important to disable the migration settings feature after profile capture is complete to ensure profiles are delivered to desktops. Also, it is recommended to use the AppSense Configuration Assistant tool to identify application dependencies in order to successfully capture user settings for complex windows based applications with multiple executables.
An alternate approach to virtualizing a user profile with AppSense UVP would involve the creation of scripts targeting specific desktop and application settings to be captured from an existing desktop instance in a single step. This approach could be used to migrate the majority of desktop and application settings for a large collection of users in a batch operation. Regardless of the passive or active approach used to capture the user desktop and application settings, once captured those settings can be applied to any Windows desktop instance from Windows XP through to Windows 7 (32 and/or 64bit). This could provide an effective technique to ease migration from legacy Windows OS instances to Windows 7 instances in a virtualized environment. This active approach can be scripted using 3rd party tools such as vbs or can be configured via GUI in the AppSense UVP solution. Both migration processes are fully supported by AppSense and the choice normally depends on the type of existing infrastructure and profile being used prior to migration.
Unidesk Desktop Management for VDI
Unidesk uses dynamic desktop layering technology to offer an alternative approach to the non-persistent desktop model of cloning, application virtualization, and profile management tools. Unidesk creates persistent or non-persistent desktops out of the same reusable OS and application "layers." A single clean golden OS layer can be used for all desktops. Enterprise and departmental applications can be layered and added on top of the OS layer in different combinations to meet different user requirements. Each desktop also has a personalization layer that captures all user customizations, including those not contained in profiles, such as OS and application security identifiers and settings, user-installed applications, and ad hoc applications that IT installs on behalf of an end user. Unidesk dynamically merges these layers together into a unified C: drive at runtime to create desktops that appear as if everything is installed locally, even though the OS and application layers are created and updated once centrally by IT. By sharing a single instance of the OS and application layers across all desktops hosted on a single UCS blade, Unidesk offers the same storage capacity reduction as Linked Clones, even for persistent desktops.
The business drivers that lead to the adoption of Unidesk are:
•
•
•
•
•
•
•
Design Considerations
Unidesk Composite Virtualization® is the technology that dynamically assembles desktop layers into a single complete HVD image on demand. Unidesk CacheCloud is the cluster of storage caching servers, implemented as virtual appliances called CachePoints, that replicates the layers as needed, and provides caching, version control, backup, and rollback capabilities. Unidesk includes the following virtual appliances:
•
•
•
Figure 69 Application Layering technology with Unidesk
Unidesk uses local caching of desktop images and maintains high availability by supporting block-level data replication between local and master caches using reliable TCP transport. Unidesk creates a natural I/O pattern that optimizes hybrid SSD/SAS load balancing on the CachePoints - the shared OS and application layers quickly become hot and stored on SSD, whereas infrequently accessed personalization layer content goes cold, and gets moved to SAS. The sharing of single OS and application layers across all desktops on a single host also provides storage capacity reduction. Note that the CachePoint appliance does present a single point of failure in the Unidesk architecture, so it is recommended to run this appliance on a dedicated host (the next major release of Unidesk fixes this).
Unidesk enables administrators to create or patch underlying layers once and then push the changes out to all or some subset of desktops, simplifying OS and application upgrades and patches. Unidesk supports layer versioning for instant repair or rollback without a loss of data in case a user's desktop is compromised or corrupted. Note that the administrator will need to reboot the desktops to instantiate any changes to application layers. Unidesk integration with VMware View enables Unidesk to create View pools, add desktops to View pools, and put the desktops into maintenance mode so they can be patched and updated.
The user's persona (desktop and application settings) is retained in each desktop's personalization layer. The Personalization layer retains all user customizations including profile settings, user data, app and OS security settings, and user installed applications. Unidesk can be used in combination with other user virtualization tools, but given Unidesk captures everything those tools do and more, it is not widely deployed in this way. The exception is when customers want users to have profile settings "roam" across physical and virtual desktops. Please refer to Unidesk documentation to confirm compatibility and support for persona management tools.
Unidesk is storage agnostic and is compatible with all types of storage: NAS (NFS, iSCSI and SAN) and even DAS. Unidesk has deep integration with VMware View and VMware vSphere, and works with any connection broker. Currently, VMware vSphere is the only hypervisor supported by Unidesk.
Note that the Unidesk solution is not compatible with Linked Clone or image management technologies such as VMware View Composer that only work for non-persistent desktops. As the Unidesk solution builds the HVD disk image dynamically from common OS, application, and unique user personalization `layers', it should be considered as an alternative image management technology, achieving the same benefits, but expanding VXI use cases to include non-persistent and persistent desktops.
Note Unidesk also makes it possible to deploy virtual desktops at remote and branch offices in low bandwidth scenarios by putting local Desktop CachePoint appliances in the branches, but still managing all layers once centrally in the data center.
Deployment, Configuration, and Best Practices
In the Cisco VXI validation, Unidesk was used to provision and update desktops, deliver applications, preserve the full user persona, and provide storage efficiency in a VMware View 5 environment. The View desktops were configured to "Assign on First Use," with Unidesk dynamic image composition handling the single image management and storage reduction. Unidesk was also used to deliver the productivity applications from the KW+ workload using a packaged set of application layers. VMware vSphere was used as the hypervisor to host all desktop and servers. Standard KW+ test workloads were used for testing this profile. Please refer to Performance and Capacity chapter for detailed scalability test results obtained with these profiles.
The Unidesk Management Appliance and Master CachePoint were deployed on the server VLAN and the Desktop CachePoint was placed in the desktop VLAN. In the validation, 8GB of storage was allocated for the personalization layer.
It is recommended to setup one Desktop CachePoint per host for best performance. Unidesk can scale up to approximately 100 desktops per CachePoint, but this varies based on desktop configurations (CPUs, memory) and host specifications. The amount of storage allocated for a Desktop CachePoint should be based on the amount of storage required to host all attached desktops (formula is size of each desktop's personalization layer plus the size of 1 OS layer plus the size of all the app layers shared by the desktops, with some additional headroom for expansion). Shared storage (NAS) is recommended for the Master CachePoint, which stores the single copy of each OS and application layer. Hybrid SSD/SAS storage arrays are ideal for Desktop CachePoints, since they can take advantage of Unidesk's shared layer data pattern and capacity reduction to optimize IOPS and host 4X as many Unidesk desktops as they could full-sized persistent clones. High-speed DAS is also an option for Desktop CachePoints, since Unidesk automatically backs up all personalization layers, and can recover all desktops to another CachePoint in the event of a local disk failure using the backed up personalization layers and the Master CachePoint's OS and application layers.
It is recommended to use a single clean OS layer for all desktops to simplify OS patching, leveraging Unidesk's ability to layer all apps separately. A desktop administrator can create an application layer by choosing Create Layer. Unidesk will spin up a clean virtual desktop "installation machine" with the OS layer that was specified, and any prerequisite application layers. The administrator runs Setup and does whatever else would normally be done to install the app. The administrator then chooses Finalize, and the app can be immediately assigned to one or more desktops. For the purposes of improved logging and monitoring, it is recommended to set up a separate Unidesk Administrator account in vSphere.
The Unidesk Integration Agent for VMware View installed on the View Manager server communicates with Unidesk on port 390 using the PowerShell interface. Unidesk will synchronize desktop pool configuration with View Manager, create View pools, and add created desktops into View pools. It was discovered that deleting a desktop in the version of Unidesk that we tested deletes the desktop in vCenter, but not in View Manager. Unidesk claims this has been fixed in the latest release, but a simple workaround is to manually delete the desktop in View Manager. Unidesk supports other desktop brokers, but without the deeper integration it has with View.
Note that ThinApp can be used to deliver virtualized applications in this environment, but this was not included in the validation. Unidesk can distribute ThinApp virtualized applications to one or more desktops just by putting the ThinApp packaged executable file into a layer. Doing this adds Unidesk's ad hoc assignment, version control, rollback, and detailed reporting capabilities to ThinApp. ThinApp virtualized applications can also be run on a variety of Windows versions on physical desktops. The ThinApp executable can be placed on a conventional network file server and accessed by a link embedded on the end user's desktop or as part of a user's profile settings. Unidesk cannot be a delivery vehicle for ThinApp in this case because it does not support physical desktops.
It is important to evaluate the performance (i.e. application launch and response times) of applications packaged as application layers in Unidesk before deploying them to desktops. In certain instances, the application may not achieve optimal performance.
Unidesk does not support deployment on physical desktops or overlaying a `user personalization' layer created on one OS version (Windows XP) onto a different OS (Windows 7). These use cases would typically be exercised in a migration or upgrade scenario.
If full persistence is required to sustain user-installed applications and other deep user customizations, desktop layering can be used. Layering enables a single golden OS image to be used for all desktops, and different combinations of app layers to be added to different desktops as needed, while preserving all user customizations in separate personalization layers. This offers the same centralized patching and storage savings as in a pooled, non-persistent VXI model, but with full persona persistence. The complete desktop - OS image, applications, and persona (including profile settings, application and OS security/settings, and user-installed applications) - can be managed with Unidesk.
Desktop Monitoring and Assessment
A key monitoring and reporting requirement in VXI deployments is a `single-pane-of-glass' high-level, view of the end-to-end VXI deployment. The individual IT departments which participate in a VXI deployment (Desktop Services, DC Storage, DC Compute, Network) have tools appropriate to their specific domain but in the event of an when there is an outage, there is a need for a tool that can be used by an IT help desk worker to quickly diagnose an end-user's desktop issue, identify the root cause, and route a trouble ticket to the right IT department, and to rapidly resolve the issue. Many end users will simply report degraded performance in their HVD making this support task further challenging. The system performance monitoring and reporting tool will monitor and report key metrics like active desktop sessions and session traffic performance issues.
Benefits include reducing the mean time to repair for support team that has to troubleshoot an issue reported by a end user. A monitoring dashboard for the operations support team allows an administrator to proactively detect issues with desktops before an issue is reported by an end user. Another benefit is being able to monitor and report on HVD usage over an extended period of time in a large enterprise to facilitate capacity and life cycle management.
There are tools available within the hypervisor management infrastructure that can be used for desktop monitoring. Resource (CPU, memory, storage, and network) use on individual desktops can be measured and monitored in real time by using the VMware statistics logging application. Consider using the Intel IOMeter tool and the built-in Microsoft Windows Task Manager, which displays resource utilization and performance measurements (Figure 70). These tools are also useful for troubleshooting purposes. VMware vCenter can be used to capture these measurements on a per-virtual machine basis.
Figure 70 Windows Task manager Performance Monitor
Measuring resource utilization of physical desktops enables administrators to assess the physical desktop infrastructure prior to migration to a virtualized environment. It also enables capacity planning for future resource buildout (compute, memory, storage, and network resources) and post deployment QoS monitoring on virtual desktops. An audit log of the files being accessed and the applications being invoked on the desktop may also be useful for monitoring desktop use and troubleshooting performance problems. Consider using Microsoft Windows Performance Manager in addition to any other software or application probes that can be installed on the desktop.
Stratusphere UX
The Cisco VXI validation includes Liquidware Lab's Stratusphere UX product as a tool for use as a user experience monitoring and virtual desktop diagnostic aid and is a key component in building an end-to-end VXI system view. This tool enriches the diagnostic and monitoring information available to IT administrators by correlating all performance metrics into a single pane of glass. It complements existing management solutions, particularly those associated with specific VXI subsystems like storage, hypervisor, and network management. It allows administrators to perform HVD monitoring and troubleshooting of user experience issues. It also provides insight into all levels of application and user interactions - from the desktop, through the network, to the data center in terms of resource usage.
The tool can be used to:
•
•
•
•
•
•
Design Guidelines
Use cases for virtual desktop monitoring tools include:
•
•
•
The monitoring tools provide real-time monitoring of virtual desktops via interactive displays, reports, and alerts. The monitoring tool validates service levels and the security of the VDI environment, and can also be used to assign service charges for use of the virtual desktop environment. Virtualized applications can also be monitored.
The Stratusphere UX architecture includes a client agent that runs on the HVD that periodically collects and communicates desktop performance information to the Stratusphere hub. The agent installation enables three services to run in desktop. The hub is a virtual appliance that resides in the DC and provides a web interface for remote access and management. The Stratusphere Network Station is required to perform network traffic monitoring and gain insight into desktop session activity.
The hub uses an internal database to store performance data and an external database can also be used to further improve the scalabilty with respect to number of managed desktops. Performance data can be exported to other management tools using the ODBC interface, SNMP or RSS feed. Note that the agent incurs minimal impact on the HVD performance as a result of only periodic performance data collection and transmission to the hub.
Using a default configuration settings, the current version of Stratusphere hub can manage and scale up to approximately 1000 desktops (recommended upper limit for standalone hub). Beyond a 1000 desktops, the scalability of the hub is increased significantly by adding an external database appliance used to store the collected statistics. In this scenario, a single hub can scale up to 10,000 desktops. Refer to Stratusphere documentation for best practices on scaling in a large deployment. Scalability of the Stratusphere hub depends on a number of factors including the polling interval for statistics collection and whether the network station is being used to report network statistics.
Stratusphere UX is compatible with VMware View environments. The network station when deployed is capable of collecting desktop session statistics (ICA/PCoIP/RDP). Use the Stratusphere Network Station to monitor desktop session state, and perform packet capture of session traffic.
Stratusphere UX virtual appliances are compatible with vSphere. Stratusphere UX can collect host usage statistics from the vCenter.
Figure 71 Stratusphere UX Management Console
Deployment, Configuration, and Best Practices
It is recommended to use Stratusphere UX to:
•
•
•
•
During the data collection, be aware that the Statusphere agent may invoke child processes periodically and frequently (particularly for GDI/GPU metric data collection). Ensure compatibility with other software installed on the HVD that may be monitoring process and application activity. Please refer to Stratusphere documentation for latest information on compatibility.
The reporting interval for performance monitoring was set to a default setting of 15 minutes. It should be noted that a shorter time period will incur more CPU and network utilization on the desktop and impact the scalability of the hub and associated database.
Metrics that would indicate poor performance and user experience include the desktop CPU queue, IOPS, IO latency, long application launch times and login times. It is recommended to tune desktop assessment thresholds (that classify a users desktop performance as good, fair, poor) appropriate to the users workload profile (for example, task worker, knowledge worker, power users with graphics intensive applications and may use high GDI or memory intensive user profiles).
When interpreting the login delay measurement, it is important to understand that if a user simply disconnects from their HVD, they may remain logged in depending on the desktop environment configuration, so the desktop is still considered being used in this case. If specific HVD usage measurement is required this can be extracted from the desktop session usage metrics available for ICA/PCoIP/RDP. These measurements can be obtained from the network station that monitors all HVD network traffic.
When running reports on application usage, it is recommended to filter out the system applications (Altiris) and report only the ones uses invoked by end users (Microsoft Office and Cisco Unified Personal Communicator).
There are several methods to deploy the Stratusphere agent to the HVD's:
1.
2.
3.
4.
5.
After the desktop registers to the management station, the administrator will need to enable inspection for the desktop in order to collect relevant statistics.
Shadowing into the desktop is not always permitted and may require the user to log out of their desktop first. It is possible to shadow into a client device that is running VNC server.
Virtual Desktop Assessment
Design Guidelines
A comprehensive pre-deployment assessment of the exiting desktop computing infrastructure; virtual desktop implementation design and capacity planning; and post-deployment optimization and monitoring of virtual desktops are important aspects of a successful implementation of a Cisco VXI system. The best way to assess an organization's readiness for desktop virtualization, and its potential benefits, is to develop a set of realistic and well-defined business drivers and a clear snapshot of the current infrastructure. The tools that perform virtual desktop pre-assessment, design, implementation, monitoring, optimization and capacity planning are key to performing this evaluation. These tools provide the following capabilities: ability to understand existing desktop computing resource usage and user experience, ability to do capacity planning for desktop virtualization deployment, ability to monitor virtual desktop resource usage and user experience, and ability to demonstrate and report on benefits of desktop virtualization. The goal of the assessment is to determine readiness and requirements for desktop virtualization. Determining suitability of a desktop or user for desktop virtualization is part of the design and planning stage of a deployment.
These tools provide visibility into desktop computing resource usage, application workload, user behavior and user experience for large desktop deployments. Typical measurements provided by these tools include usage metrics in terms of compute, memory, storage, and network resources as well as desktop user experience metrics in terms of application response times, login times and latency measurements. A detailed hardware and software profile of the desktops is also compiled that includes operating system, hardware profile, applications, user settings, peripherals (printers), and monitor usage. Performing a baseline user experience assessment prior to virtualization is important in assessing the user experience in a virtual desktop deployment.
After data gathering is complete, the assessment tools generate reports that are used to identify the optimal and sub-optimal desktop candidates for desktop virtualization. The goal of the assessment is not a final design, but rather an analysis of the feasibility of a desktop virtualization project given the combination of network infrastructure, user applications, and desktop environment. The relative suitability or fit for virtualization is determined using an objective fitness rating based on a composite metric using pre-established thresholds. Assessment tools can also provide estimate of productivity improvement based on reduction in login times, or due to benefits of desktop high availability and replacement time reduction, as well as reduction of application load times.
The assessment tool typically requires the installation of agent software on the desktop for data collection and communication of the data to a central repository for aggregation and analysis. The operation of the agent software is transparent to the end user and should not impact the performance of the desktop. It is important that the ports used for this communication are open on all intermediary network elements. As thousands of desktops can be monitored, it is important to allocate enough storage for the database on the central repository. The agent software can be installed manually on a desktop or be distributed automatically using an LDAP/GPO or other standard tool used for updating desktops (SMS). Once data is collection begins, it is collected continuously for the duration of the evaluation (for instance, 30 days). The collected data will allow the creation of a detailed picture of the machines, application, and user inventory of the desktops being monitored.
Some indications of poor desktop performance include:
•
•
•
•
•
•
The assessment and monitoring tool provides real-time display of inspection data, diagnostic reports, and assessment reports. The tool provides summary views of inspection data using graphs and charts to help analyze trends and identify potential problems. These views are useful when examining the health of the Cisco VXI deployment. When specific measurement thresholds are passed, alerts can be sent via e-mail or RSS feed. Automated programs can be used to poll the RSS feeds and to pass on the data to other systems. It is recommended to schedule a report to be sent via e-mail on daily basis to indicate how many machines are reporting data to ensure that data collection is progressing without any issues.
Deployment, configuration, and Best Practices
It is recommended to use a dedicated network monitor attached to the virtual switch to monitor virtual desktop network traffic and report on application usage. Proper network planning and provisioning is important in order to allocate the correct bandwidth and to ensure low latency for users accessing their virtual desktops across WAN.
It is recommended to establish a baseline for user experience prior to migration. A post-deployment user experience measurement quantifies the impact to the end user during a deployment or pilot. The assessment will assist in determining how to provision the virtual desktops (resources, images, and applications) and which desktop protocol to use, and which desktop protocol features to enable (peripherals).
Identifying applications that are poor fit for virtualization is key to a successful Cisco VXI deployment. Ensure that applications currently used operate correctly and without performance impact in a virtualized environment especially when scaled to tens of virtual desktops on a single host machine.
Cisco Advance Services provides a Cisco VXI planning, design and monitoring service that will conduct the evaluation and generate an assessment report and virtualization design plan. The outputs of the services include Cisco VXI design documents, operation readiness and implementation plans, self-service guides, PoC report, test plan, and a readiness report. Please consult Cisco AS for further information at http://www.cisco.com/en/US/products/ps10374/services_segment_service_home.html
Cius Management Tools
The Cisco Unified Call Manager (CUCM) can be used to manage the Cius tablet device which is both a UC and DV endpoint in the VXI system. The CUCM is used to perform firmware updates and apply device configuration (including security policy like file encryption and VPN settings), manage applications and perform bulk updates. The Cisco Anyconnect client is integrated with Cius and provides VPN capability. Note that CUCM 8.5 is required to support advanced management features for the Cius. Applications can be downloaded and installed on the Cius by the end user or can be pushed down to all devices by the administrator using CUCM. Applications are deployed on the Cius from the CUCM application repository, the device SD card, the Android Market, Cisco Marketplace application repository, or an enterprise specific repository. DV client applications (Wyse PocketCloud, and VMware View client) that run on Android OS should be downloaded and installed on the Cius. An administrator can specify enterprise applications to be pushed to the Cius when it registers to CUCM. End users can also select applications from an administrator approved list. In this case, an end user would request an application list from CUCM, from which the user can subscribe or unsubscribe to a particular application. Note that some application settings are preconfigured by the administrator while others are customized by the end user. More advanced mobile device management features like remote wipe, backup and restore, device tracking, policy enforcement, and virus protection are available in enterprise mobile device management tools from 3rd party vendors.
For More Information
The following list of web links offer detailed information regarding specific vendor information including hardware and software discussed in this chapter.
Cisco Deployment Guide for VMware View 4.0
http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/vmware/cisco_VMwareView.html
Cisco UCS GUI Configuration Guide
Cisco Unified Communications Manager Systems Guide
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_0_2/ccmsys/accm.pdf
VMware vSphere 4.2 documentation
http://www.vmware.com/support/pubs/vs_pages/vsp_pubs_esxi41_i_vc41.html
VMware vSphere Command-Line Interface Documentation
http://www.vmware.com/support/developer/vcli/
VMware APIs and SDKs Documentation
http://www.vmware.com/support/pubs/sdk_pubs.html
VMware View 4.6 Documentation
http://www.vmware.com/support/pubs/view_pubs.html
VMware View Installation Guide (release 4.5)
http://www.vmware.com/support/pubs/view_pubs.html
VMware View Administrators Guide (release 4.5)
http://www.vmware.com/support/pubs/view_pubs.html
VMware View Integration Guide (release 4.5)
http://www.vmware.com/support/pubs/view_pubs.html
VMware View Architecture Planning Guide (release 4.5)
http://www.vmware.com/support/pubs/view_pubs.html
VMware Configuration Maximums
http://www.vmware.com/pdf/vsphere4/r40/vsp_40_config_max.pdf
EMC Unisphere management suite
http://www.emc.com/products/detail/software/unisphere.htm?context=storage
NetApp Virtual Storage Console
http://www.netapp.com/us/products/management-software/vsc/virtual-storage-console.html
Altiris reference documentation
http://www.symantec.com/business/theme.jsp?themeid=altiris
Microsoft Active Directory and Network services
Cisco Network Analysis Module Deployment Guide
http://www.cisco.com/en/US/prod/collateral/modules/ps2706/white_paper_c07-505273.html#wp9000247
Cisco NAM Appliance Documentation (command reference and user guide)
http://www.cisco.com/en/US/partner/products/ps10113/tsd_products_support_series_home.html
Cisco Wide Area Application Services Configuration Guide (Software Version 4.1.1)
http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v411/configuration/guide/cnfg.html
Cisco Adaptive Security Device Manager Configuration Guide
http://www.cisco.com/en/US/products/ps6121/tsd_products_support_configure.html
Cisco ACE 4700 Series Application Control Engine Appliances Documentation
http://www.cisco.com/en/US/products/ps7027/tsd_products_support_series_home.html
Cisco UCS Manager Configuration Guide
http://www.cisco.com/en/US/products/ps10281/products_installation_and_configuration_guides_list.html
http://www.cisco.com/en/US/products/ps9369/tsd_products_support_configure.html
Cisco Fabric manager documentation
http://www.cisco.com/en/US/partner/products/ps10495/tsd_products_support_configure.html
Cisco Nexus 1000v documentation
Devon IT Echo™ Thin Client Management Software Version 3 Overview
http://www.devonit.com/software/echo/overview
Devon ThinManage 3.1 Admin Guide
http://downloads.devonit.com/Website/public/Documentation/thinmanage-3-1-adminguide-rev12.pdf
Devon IT TC5 Terminal Quick Start Guide
http://www.devonit.com/_wp/wp-content/uploads/2009/04/tc5-quickstartguide-devonit-english.pdf
IGEL Universal Management Suite 3 Overview
http://www.igel.com/igel/live.php,navigation_id,3294,_psmand,9.html
IGEL Universal Management Suite 3 Install Guide
IGEL Universal Management Suite 3 User Guide
http://www.download-igel.com/ftp/manuals/english/universalmanagement/IGEL%20UMS%20User%20Guide.pdf
IGEL Universal Desktops User Guide
http://www.download-igel.com/ftp/manuals/english/universalmanagement/IGEL%20UMS%20User%20Guide.pdf
Cisco VXI Security
Introduction
Desktop Virtualization is inherently more secure than a traditional desktop environment, as there is no local data present at the user endpoint and no data leaves the data center. However, desktop virtualization allows for anytime, anywhere access to the data center, opening new areas of security challenges. IT data centers were traditionally built with the mind set that an end user, in most scenarios, does not need to access data center components directly, and only user applications over controlled access mechanisms interact with servers in the data center. This is no longer true and the separation between the user desktops (which are untrusted compute environments) and data center components need to be ensured. Further, since all user desktops are now clustered together, the impact footprint in case of a security breach is much higher than in traditional desktop environments. The Cisco VXI system tackles the security challenges in the dynamic and virtual environment by introducing a robust set of security features and guidelines. This chapter details these features and discusses the best practices of securing a Cisco VXI system. It should be noted that these security mechanisms introduced in Cisco VXI are consistent with traditional/existing enterprises security technologies.
Figure 72 End to End Cisco VXI Security
Figure 72 above depicts three logical sections of the Cisco VXI system that need to be secured. These logical divisions are separated based on where the data originates and what needs to be secured. The focus of all three divisions together is control access into the VXI system, secure display protocol traffic, UC traffic, peripheral traffic, data residing in the virtual desktops and isolation of compromised machines.
The first division is at the Access. Access security is aimed at securing everything originating from the Endpoint to first hop network element, and spans Fixed/Mobile Teleworker, Branch and Campus user environments. The second division is the Network. Network security covers the Cisco VXI security aspects of data travelling over the untrusted (such as Internet) or trusted (such as Campus) networks. Once the user data is delivered into the data center, at the data center or campus edge, the security aspects within the Data center need to be looked at. These aspects are covered under Data Center security, which covers securing VM access, Segmentation/zoning and Virtual desktop OS protection. The rest of the chapter discusses the Cisco VXI specific technologies and design strategies based on the above.
Design Considerations
Access Security
The implementation of a Cisco VXI-enabled network moves the location of application data from user-controlled desktops to a centralized data center. Access security in Cisco VXI focuses on protecting data and identity while it travels between the endpoint and the data center. Since the enterprise supported applications and OS are present in the data center and not locally, the impact of a breach of endpoint security depends how end-to-end security is implemented all the way into the data center.
Cisco VXI users in a Campus environment are inside a trusted network, and the traffic from access switch to the data center is assumed to travel over a managed and secure network. The access switch however, considers the host ports untrusted unless a specific trusted device such as Cisco IP phone is connected. Cisco VXI endpoints connected to the Campus access switch are considered untrusted. The endpoint in the Cisco VXI system is no longer attached to a specific user and any user can potentially access their virtual desktop from anywhere. Enterprises may choose to either tie each endpoint to a user or authenticate an endpoint and user independently in the Cisco VXI environment. In either case, implementing endpoint authentication mechanisms is highly recommended. The Cisco VXI system utilizes IEEE 802.1x for client authentication. Cisco AnyConnect 3.0 with Network Access Manager (NAM) can be used if a native IEEE 802.1x supplicant is not available on the endpoint. Testing done on the Cisco VXI system used AnyConnect 3.0 on Windows XP endpoints, and employed Microsoft's native supplicant under Windows 7. Some thin clients support IEEE 802.1x but don't support installation of AnyConnect 3.0; in this scenario the native 802.1x feature should be used. If the endpoints deployed don't support any form of IEEE 802.1x supplicant, then 802.1x based MAC authentication By-pass (MAB) feature on the access switches should be employed. In MAB, a database of trusted endpoint MAC addresses maintained in the RADIUS server running on ACS 5.2 is used to authenticate the MAC address of the endpoint. More information about configuring and using 802.1x with MAB can be found at http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/31sg/configuration/guide/dot1x.html
Beyond the authentication of the device as a network entity, devices should also be monitored for continued authenticity as close to their access point as possible. This is accomplished through the configuration of port security measures such as DHCP snooping, dynamic ARP inspection, and IP source guard discussed later in the chapter.
Branch access is part of the corporate security enclave, but is separated from it by a WAN link. Branches are typically deployed with Cisco Integrated Services Routers Generation 2 (ISR G2) Routers with encrypted tunnels to the Campus/data center. As with the campus located access switches, since the branch will typically service its own local DHCP requests, the following inspection configurations should be deployed at the access layer switches: DHCP Snooping, dynamic ARP inspection and IP source guard. MAB and IEEE 802.1x for device authentication should also be deployed locally, via branch switches or switch modules within the Cisco ISR.
Policy Based Network Access Control Using Identity Services Engine (ISE)
Policy based network access control in VXI allows endpoints accessing virtual desktops to be controlled granularly based on device type, location of the network attachment point etc. This allows secure desktop virtualization access to specific devices. For example, a contractor connecting their own laptop into the network will not be given access to VXI resources, whereas an employee connecting a VXC endpoint to the same network port will get automatic access to their virtual desktops. VXI also enables the enterprise to deploy Bring Your Own Device (BYOD) models where the end users are responsible for the physical endpoint and the local data while the enterprise ensures that the user's work environment is securely delivered to the endpoint on a need only basis. BYOD with VXI allows the enterprise to reduce endpoint hardware/software management costs and provide very robust data security options. It also gives end users the choice of using the device of personal liking and potentially converge their personal and work endpoints into one device.
Cisco VXI policy based network access solution when applied on top of desktop virtualization enables tighter control on who gets access to what part of the network. For example, an employee can now bring their personal endpoint to work, connect to the enterprise network and based on policy get access only to their virtual desktop and/or the internet. At the same time, an employee using an IT managed endpoint might be allowed access to other parts of the network along with their virtual desktop. A much more granular level of control can also be applied based on user's network attachment point. Policy based Network Access Control in Cisco VXI is applicable for both Campus and Branch environments.
The key components involved in creating a Policy based network access solution are Cisco Identity Services Engine (ISE) 1.0, Cisco access devices compatible with ISE (most Cisco Catalyst access switches and wireless access points are capable) and a network designed to isolate traffic. The figure below depicts a personal device and an Enterprise asset getting access to different parts of the network based on policy decisions made by ISE. The first step is to perform device profiling to identify the network attached device as corporate or personal device. This is done using ISE device profiling feature that allows the network administrator to match the device against single or multiple pre-defined attributes in ISE. The access switch is configured with 802.1x or MAC Address Bypass (MAB) to authenticate the endpoints trying to access the network. When the device tries to access for the first time, the switch sends the Mac address and optionally other attributes such as DHCP requests to the ISE. ISE then profiles and identifies the device by looking up the device data base and sends the preconfigured Access Control List (ACL) to the switch based on the configured policy. The ACL is defined to place the device on a specific VLAN. In the figure, Personal Devices are placed in VLAN 30, and VLAN 30 is pre-configured as a VXI VLAN that transports all endpoint traffic to the VXI network in the data center. To further enhance the data security, the connection broker serving the VLAN 30 based subnet can be pre-configured to disallow any USB attached devices to get transfer data from the HVD. Apart from device profiling, ISE can also perform posturing, AAA, TrustSec and other services. It is also very easily extensible to many third party policy information points and keeps a correlated log of all events to help track users and aid audits. For more information on ISE please refer to http://www.cisco.com/en/US/products/ps11640/index.html
Figure 73
When using 802.1x for device authentication multiple authentication techniques such as EAP/PEAP/WPA etc. are supported. VXC 2211 supports certificate based 802.1x supplicants and the VXC 2111 attached to a Cisco IP Phone also support certificate based 802.1x. Any non-VXC endpoint that has a 802.1x supplicant or can run Anyconnect 3.0 is also supported. For devices that don't support 802.1x a MAB can be used for authentication, keeping in mind that administrative overhead of mapping device to Mac address is required. Pre-configured device profiles for VXC endpoints are available for use within ISE or can be easily created by using the information in the VXI configuration guide. Further deployment guidance and best practices are discussed in later in the section for each of the components involved.
Secure Access for Fixed Teleworkers and Home User Environments
Cisco VXI offers two solutions for Fixed Teleworker environments that enterprises deploy. The first solution is the Cisco Virtual Office (CVO) solution which allows multiple endpoints and IP phones to be connected in the home or small branch environment. These endpoints can connect to CVO routers using wired or WiFi and also leverage Power over Ethernet. The second solution leverages VXC VPN capabilities on Cisco 9971, 9951 and 8961 phones to allow collaboration and desktop virtualization in a simple form factor without the need of routers or separate devices. The Cisco 9971/9951/8961 VXC VPN solution is specific to VXC 2111 endpoints and does not extend connectivity to any other endpoint. For all other endpoints deployed in a fixed teleworker or home user environments it is recommended to use the CVO solution.
The CVO solution leverages pre-existing Cisco Virtual Office Deployment Guide that allows VPN access from a home office by means of an access router. The deployment guide is available at the CVO solution page listed below. This deployment creates an encrypted VPN tunnel over which the endpoint can access the virtual desktops in the data center as shown in the figure below. The local network behind the access router can be considered trusted since deployment of a home-based router is an extension of the secure corporate network into the employee's home. It should be noted that some configurations of CVO allow untrusted endpoints to directly access the public internet outside the VPN tunnel. For all devices attempting access to corporate network device authentication using 802.1X or MAB is required. For Cisco zero clients that don't support local browser and hence are unable to authenticate using web based proxy, the CVO router can be configured with specific ports opened along with MAB. VXI specific deployment considerations are covered later in this chapter. Many routing platforms are supported for CVO in teleworker and branch environments including C880, 890, 1900, 2900, 3900 and the appropriate platform is selected based on throughput required. For a typical Teleworker environment the C881 platform is recommended. For general details on CVO solution please visit: http://www.cisco.com/go/cvo
Figure 74
VXC VPN
For scenarios where a teleworker or home user only needs a phone for voice/video telephony and their virtual desktop the VXC VPN solution is recommended. The solution allows the Cisco IP phones 8961, 9951 or 9971 to encrypt VXC 2111 (attached to the phones) traffic going into the phone's computer port along with voice/video traffic in a separate encrypted tunnel. This allows for the phone and VXC traffic to be securely transmitted over the internet or any untrusted network. As depicted in the figure above, two separate SSL VPN tunnels are created. The first one is a DTLS based tunnel to encrypt the UDP Voice, Video and Call signaling traffic originating from the phone and the second one is a TCP based TLS tunnel for all the VXI traffic. Once the SSL VPN tunnels terminate on the ASA all traffic is routed in the corporate and data center networks as configured.
This solution mitigates many of other security concerns such as a rogue device connecting to the phone's computer port by removing the VXC 2111 after authentication, attaching a non-corporate (unrecognized) VXC 2111 or sending non-VXI traffic in the tunnel. The traffic on the computer ports is limited to display protocol traffic and some required management traffic (DNS, NetBios, http and https) using Access lists configured on the computer port of the phones. The access lists used are similar to the ones used in CVO solutions. This helps prevent the user from connecting a non VXC Ethernet device to the phone computer port. To further improve security, MAC address based authentication is supported on the computer port and is highly recommended to deny access to un-trusted devices. Since this solution extends the corporate network behind the IP phone in an untrusted location (home) over untrusted network, there could be a potential security concerns and it is recommended to closely evaluate the risks and conformance policies before deployment.
After the UCM and ASA are configured with the recommended VPN configurations, the user can connect the IP Phone with the attached VXC endpoint attached to their home network. The Phone will automatically initiate a VPN connection to the ASA headend after detecting that its not on the corporate network. The ASA will challenge the user for username/password or do certificate based authentication. Username/Password method requires the end user to enter the credential twice at first login (if persistent username/password settings are configured) and username/password method is recommended for deployments where the endpoints are used in a shared environments. Certificate based authentication fits well in scenarios where endpoints are specifically assigned to a user; it is recommended to setup operation procedures to revoke certificates if the end user looses the endpoint. Post authentication, IP phone will use the same credentials to establish the VXC VPN tunnel and the user can then login to their virtual desktops as they would in the campus. Note that all traffic on the phone's computer port will go through the VXC VPN tunnel. The Phone is capable of prioritizing voice and video traffic over the VXI traffic to ensure quality. The recommended total internet bandwidth for good user experience should account for Voice/Video bandwidth along with the VXI traffic requirement.
Please refer to the deployment and best practices section of this chapter for more details on configuration options and caveats.
Secure Remote Access for Mobile Environments
In the mobile teleworker environment, virtual desktops will be typically accessed over untrusted public network. A mobile worker is expected to use a thick endpoint such as VXC 4000, laptop, or a Cisco VXI thin client such as CIUS or even a third party tablet, to access the virtual desktop. The Cisco Unified Personal Communicator for hard-phone control is not part of mobile teleworker profile. Display traffic in this scenario needs to be protected starting at the endpoint; Cisco VXI recommends creating a VPN tunnel into the corporate network via AnyConnect 3.0 and authenticating against a directory or network access control database. Further, to increase cost effectiveness, all internet traffic not required to go through the corporate network should be routed directly to the internet outside the VPN session and protected using Cisco ScanSafe. The Cisco AnyConnect client should be configured to automatically launch the desktop client once the tunnel is established. The following link provides an example configuration: http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00808efbd2.sht ml
The Cisco AnyConnect connection typically terminates at a Cisco ASA Adaptive Security Appliance at the Internet access edge of the data center. A user challenge (passcode request) is presented, authentication takes place, and an encrypted tunnel is built to allow the employee access. Since Display traffic is latency-sensitive, it is recommended to use Datagram Transport Layer Security (DTLS). Cisco AnyConnect client and ASA can be configured to setup DTLS as primary connection options. Using secure split tunneling and Anyconnect 3.0 web security module for ScanSafe all the non-enterprise bound internet traffic (ports 80/443/8080) is routed outside the VPN tunnel through a ScanSafe cloud. This is depicted in the figure below. ScanSafe allows the enterprise to extend their internet bound traffic policies in the cloud without handling the traffic directly. This has direct impact on the cost of the bandwidth of the enterprise and provides better control. Secure split tunneling installs routes on the local VPN adapter to allow only "interesting" traffic to the ASA and rest remains local.
Figure 75
Network Security
Data security in a VXI Branch
Site-to-Site VPNs between the Branches and the Corporate head offices are secured IP security (IPsec) encrypted tunnels. These tunnels can be deployed by means of certificates or preshared passwords for authentication of the tunnel endpoints. This deployment model encrypts the Cisco VXI data between the two locations in order to minimize data being casually captured along the route. Cisco VXI supports Easy VPN and Dynamic Multipoint VPN (DMVPN). With desktop virtualization, anytime anywhere access to the corporate data center is a highly critical. One of the ways to achieve this is to provide an ability to securely connect large number of fixed teleworkers and branches to the corporate data center over the WAN. Further, to save on network bandwidth and administrative overhead and increase productivity, these connections should preferably be created on-demand when data needs to be transported, and, torn down when not in use. In a typical enterprise Cisco VXI system, all display traffic from all users needs to reach the nearest data center. Phone traffic needs to route locally between the users and not necessarily via the data center, in most cases. In a branch and teleworker environment, it is highly desirable to have the capability to create secure VPN tunnels to the nearest data center for display traffic and if needed, for the phone traffic, and the capability for on-demand tunneling between two branches temporarily. On top of these requirements, QoS marking and WAN optimization should be integrated within the solution to preserve user experience. To cater to all these needs, a Cisco VXI system uses DMVPN technology that uses Next Hop Resolution Protocol and Multipoint GRE Tunnels to establish IPSec connections on demand based on routing requirements, while still allowing WAAS to optimize these connections. A DMVPN solution supports a variety of WAN links such as T1/T3, WWAN, xDSL etc. In a Cisco VXI system it can be implement by configuring the ISR G2 router at each branch or fixed teleworker location to connect to an ASR 1000 VPN head-end at the Data Center edge. Cisco Security Manager (CSM) is used to configure DMVPN. The details on the working of DMVPN can be found at http://www.cisco.com/en/US/products/ps6658/index.html.
Cisco VXI network security requirement for the Campus are exactly the same as in any existing Campus environment. The details of this deployment can be found in Chapter 8 of the Cisco SAFE Reference Guide: http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/Safe-RG/SAFE_rg.pdf.
Data Center Security
Cisco VXI network and access security ensures that users "access" their virtual desktops in the data center securely. Securing the Cisco VXI data center however, requires further design considerations. Some of the important things to consider for data center security are as follows:
•
•
•
•
•
Typically, compute device (such as a desktop PC) authentication is thought of as occurring at the access level within the network. In the Cisco VXI system there is also an access level within the data center. The deployment of virtual machines on large server farms means that it's essential to monitor not only the physical connections, but also the virtual connections. This means monitoring should start within the virtual switch located within the DV environment, just as if it were a physical switch in any other network. The virtual desktop addresses can be dynamic and require the same level of surveillance as a desktop device outside the data center's "glass-house" infrastructure. With this vulnerability to spoofing in mind, it is recommended that you implement an intelligent Layer 2 virtual switch within the enclave of virtual machines. The Cisco Nexus® 1000V Series virtual switches can be deployed with its ability to employ the safeguards of Port Security, DHCP snooping, dynamic ARP inspection, and IP source guard. As noted earlier, this can be an effective first line of verification that the machine originally associated with a port is not replaced by a rogue machine. Details on deploying these features in a Cisco VXI system are covered later in this chapter. For general configuration and deployment guidelines please refer to http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0_4_s_v_1_3/security/configuration/guide/n1000v_security.html
In the Cisco VXI environment a large number of virtual desktops are present in the same data center and very likely connect to the same vlan spanning multiple servers using a distributed virtual switch. In this environment, traffic to and from the virtual desktops needs to be isolated and controlled from each other and from existing critical data center resources. Further, all the isolation and access control must be done close to the source of traffic, preferably at the vnic level; this is to allow for maximum control of the traffic and also to avoid sending the traffic out to a physical firewall for inspection that resulting in in-efficient use of network bandwidth. VMs containing the virtual desktops can move within a data center for various reasons, such movements need to be seamless from a user experience perspective but also equally importantly from a network security perspective. Atomic transition of security policies applied at the vnic level, such that policies move with the VMs, is required in this environment. To satisfy all these critical security requirements, a virtual zone based firewall that can handle movements of VMs atomically is required. A Cisco VXI system is best firewalled by deploying the Cisco Virtual Security Gateway. This virtual firewall is tightly integrated with the Nexus 1000v distributed virtual switch and provides all the critical security features. Further, in such a multi-tiered virtual environment the administrative boundaries of server administrators, network administrators and Security administrators blur and a combination of VSG and Nexus 1000V restores these boundaries. VSG is used to define the security policies to create desktop zones and access rules based on Network attributes, VM attributes or Custom attributes. These security policies are then applied to specific Nexus 1000v port profiles. The Nexus 1000v Port profiles are exposed in the hypervisor and the VMs containing the virtual desktops are attached. This tiering enables the atomicity across VM movement and also helps to keep administration boundaries distinct.
Figure 76 Virtual Security Gateway (VSG)
Figure 76 above depicts VSG zoning in an example health care setting. Virtual desktops in the hospital data center are placed into various zones by VSG leveraging common attributes (VMware or Network). These logical zones are Doctor, Assistant/Nurse, Guest/Patient and hospital IT admin. Application servers are similarly zoned using VSG based on functionality and data sensitivity as shown in the figure. Once the zones are defined, the security policy can be defined leveraging these pre-defined zones. The policy is enforced by binding the security profile to the port profile of Nexus 1000V. All the traffic leaving or terminating at HVD are subjected to policy evaluation.
The zoning policies in this example block all Inter-zone and Intra-zone traffic such that a HVD in the Guest zone has no access to any HVD in the Doctor zone, shown by the red arrow in Figure 64. Furthermore, two HVDs within the Doctor Zone can't communicate with each other by default, unless explicitly allowed. Some virtual desktops in Doctor zone need access to Patient Records and this access is allowed only from Doctor zone to the Records zone as shown by the green arrows in Figure 64. Attempts to access patient records by an IT admin or a Guest HVD are blocked. VSG implements the policies using vPath in Nexus 1000v allowing policy enforcement to happen on the virtual switch, instead of requiring all traffic to be sent to VSG thus allowing for higher performance. It is a recommended security best practice to enforce access policies closest to the source and preferably inline with traffic flow, and VSG does just that. The network admin managing Nexus 1000v in the above example only needs to ensure that correct connectivity exists and the server admin ensures that VMs are assigned to the right virtual networks. The two administrators need not be aware of the zoning and policy which is independently managed by the Security administrator using VSG.
Cisco VXI specific zoning recommendations and best practices are covered later in this chapter. For detailed understanding of VSG architecture and deployment models please refer to: https://www.myciscocommunity.com/servlet/JiveServlet/previewBody/20605-102-2-35558/Virtual_Security_Gateway_Deployment_Guide_-_v_2.9.pdf;jsessionid=05FA56FD50FAA7DB50BC995B1B397D87.node0
Anti-Virus for Desktop Virtualization
Anti-virus protection is still required as users use their virtual desktops and access insecure areas in the network or the internet. Using a traditional anti-virus/anti-malware software in a dense virtual desktop environment does not scale well. Any virus definition updates, on access scans, scheduled disk scans, boot up scans, and so forth, consume significant amount of memory, compute and I/O resources and can severely impact the VM density that can be supported. This is a very critical problem to address since the viability of the entire virtual desktop environment hinges on achieving high densities while keeping a secure virtual desktop environment. Since most virtual desktops in a typical environment run the same operating system and similar set of applications, the underlying file systems that need to be protected can be remarkably similar. This characteristic is leveraged by centralized anti-virus solutions such as McAfee's Management Optimized for Virtualized Environments or Trend Micro's Deep Security Appliance to provide a scalable virus protection product. A highly optimized and dedicated virus scan server cluster does the resource intensive work of scanning the virtual desktop files, thereby significantly increasing the VM density achievable. The basic concept is that any new file that needs to be scanned is sent to a central virus scan server, which scans the file only if the file has not been scanned previously, due to a request by another virtual desktop. If a previous scan of the file has already occurred, the client makes use of a cached scan result rather than triggering a new full scan of the file.
McAfee MOVE Antivirus
McAfee MOVE Antivirus provides Virtual Desktop Infrastructure (VDI) security without compromising on performance. By leveraging McAfee Virus Scan and McAfee's Global Threat Intelligence (now optimized with McAfee MOVE-AV), McAfee reduces the overall overhead of antivirus while managing all endpoint security, regardless of how they are delivered (virtual or physical), through a single console. McAfee MOVE Antivirus requires the following components be installed to provide and manage operations:
•
•
•
•
The MOVE Antivirus product guide found at the link below, discusses further details of each component. https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/23000/ PD23332/en_US/MOVE_AV_20_Product_Guide.pdf
Some key deployment best practices are covered later in this chapter. When designing an anti-virus scanning system for Cisco VXI, it is recommended to dedicate server resources to the Offload servers and preferably place these servers within the same cluster as the virtual desktops. Note that this model is not a requirement for a McAfee MOVE Antivirus deployment. McAfee MOVE Antivirus also supports off-hypervisor Offload Servers.
Trend Micro Deep Security Agentless Anti-Virus
Trend Micro has expertise in the area of virtualization security via products such as Deep Security, OfficeScan, Core Protection for Virtual Machines, and Secure Cloud. Cisco VXI integrates Trend Micro Deep Security as one of the Anti-virus solutions in the eco-system that is optimized for Desktop virtualization.
Through its integration with the vShield hypervisor-level APIs in VMware vSphere 4.1 or above, the individual file-IO and network-IO of every VM is intercepted and analyzed by a dedicated security Virtual Appliance setup on each ESX host. Trend Micro Deep Security provides the security virtual appliance that hosts the antivirus engine and performs familiar actions such as scheduled (and on-access) file scans, pattern file updates, checks for file disposition (known malware or not), and instructions on enforcement action (e.g. quarantine, deletion). When remediation is required, administrators can specify the actions to take using the existing anti-virus manager, while vShield Endpoint enforces remediation action automatically within the respective virtual machines.
Trend Micro Deep Security also integrates with the VMware vCenter and enables rapid deployment on ESX servers as a virtual appliance to immediately and transparently protect vSphere virtual machines. This drastically reduces the management effort and also fully integrate status and security information with VMware vCenter making security an integrated part of your desktop virtualization deployment.
Deep Security Product Page is available at the url below http://us.trendmicro.com/us/products/enterprise/datacenter-security/deep-security/index.html
The Deep Security product guide that discusses each component in detail can be found at the following link: http://us.trendmicro.com/us/products/enterprise/datacenter-security/deep-security/architecture/index.html
Please refer to Deployment and best practices section for key pointers when deploying Trend Micro in VXI environment.
Deployment and Configuration Best Practices of Cisco VXI Security Components.
AnyConnect 3.0, 802.1X, and MAB along with ISE
AnyConnect 3.0 support for SSL VPN Tunnel mode is leveraged to place the Cisco VXI endpoint in a VPN. Further, AnyConnect 3.0 allows the installation of Web Security module for Scan Safe and Network Access Manager (NAM) module used to provide wired and wireless device and user authentication via 802.1X. The Websecurity module is only available with an installed AC 3.0 client as an option, and allows the endpoint to intercept all internet bound traffic not destined to go over the VPN tunnel, to go via the ScanSafe servers in the public cloud. ScanSafe provides capabilities to block malicious sites, apply company internet access policies and do a search ahead on popular search engines such as Google. AC 3.0 deployments can be done over the web interface allowing easy management of policies and software distribution. A basic AnyConnect deployment requires the following components: ASA infrastructure, and Access and routing policy configuring on ASA for AnyConnect using profile manager. For Cisco VXI, ISE 1.0 or ACS 5.2 must be used as the AAA server to authenticate the endpoint using 802.1X, and 3K or 4K access switches should be used with their 802.1X support turned on. The detailed steps and screenshots to create the above infrastructure is present at the links below. http://www.cisco.com/en/US/docs/security/vpn_client/anyconnect/anyconnect30/administration/guide/ anyconnectadmin30.html
http://www.cisco.com/en/US/docs/security/vpn_client/anyconnect/anyconnect30/feature/guide/anycon nect30features.html
http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htwebvpn.html#wp1053858
The AnyConnect Client SSLVPN configuration should be for DTLS which is the optimum transport for latency sensitive traffic (voice/video). The AnyConnect Client should be configured to automatically launch the virtual desktop client, where applicable, once the tunnel is established.
802.1X authentication support requires a 802.1X supplicant installed on the endpoint, an access switch capable of incepting and processing EAPOL messages and relaying the authentication requests to an ISE or ACS server. For clients that don't support 802.1X supplicants, MAB should be enabled within the context of 802.1X configuration on the access switch. During Cisco VXI validation, it was found that MAB response time for acquiring DHCP information can be improved on several thin clients by tuning the device's port's 802.1X timeout tx-period.
Apart from the guidelines listed below, more information can be found at:
http://www.cisco.com/en/US/docs/switches/lan/trustsec/configuration/guide/trustsec.html http://www.cisco.com/en/US/docs/switches/lan/catalyst3750x_3560x/software/release/12.2_53_se/configuration/guide/sw8021x.html
A step by step guide to deploy the following procedure should be used to setup AnyConnect, 802.1X, ACS5.2 in the Cisco Virtualization Experience Infrastructure Configuration Guide at the url below. Note that ACS 5.2 is replaced by ISE in Cisco VXI but most ACS 5.2 configurations in concept apply to ISE too.
http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/VXI/configuration/VXI_Config_ Guide.pdf
Endpoint Support
The table below lists a variety of endpoints supported in the Cisco VXI system and corresponding VPN and Device authentication methods.
Table 25 Cisco VXI System Supported Endpoints
Note
Device Profiling Using ISE
ISE is the central policy engine recommended for Identity based network access, device profiling, AAA and posturing. Detailed guidance on deployment and configuration of ISE 1.0 is available at the links below.
http://www.cisco.com/en/US/docs/security/ise/1.0/user_guide/ise10_dis_deploy.html#wpxref26216
http://www.cisco.com/en/US/docs/security/ise/1.0.4/user_guide/ise104_user_guide.html
For VXI device profiling involves authenticating the VXI endpoints using 802.1x or MAC address bypass at the first hop switch followed by policy application and enforcement at the switch interfaces. Catalyst switches such as Cat 3500 series, 4500 series, or 6500 series can be integrated with ISE 1.0 and above. For a complete list of compatible switches and wireless access points refer to the url below. http://www.cisco.com/en/US/docs/security/ise/1.0.4/compatibility/ise104_sdt.pdf
Once the profiling probes have been setup in ISE using the reference link above and information on suggested VXI endpoint attributes for probing below, the next step is to configure the actual policies themselves. The policies can be defined at a very granular level by pulling together profiling results, network attachment points (wireless/wifi/subnets etc), user names, user authorization etc. The action of from these policies can be as simple as denying access to the network all together using 802.1x messages or granular to allow specific traffic types on specific VLANs using ACLs. The complexity of the policies and the enforcement actions depends on the network setup and security policy requirements.
During VXI validation devices listed below were profiled successfully. Other devices that support 8021x can also be integrated, for example when deploying BYOD, but it's recommended to validate such devices for the environment. A combination of four attributes is used to narrowly identify the endpoint origin and authencity. These attributes are used for device authentication and not for user authentication. The attributes used were MAC Address OUI, MAC Address, DHCP user Class-ID and DHCP class identifier. All the attribute information is sent to ISE device profiling service. If more attributes are used the access switches need to be configured appropriately as listed in the ISE admin guides listed above. Device profiles for VXI endpoints using the four attributes above can be created in the ISE profile store.
Note
Note
DMVPN
Cisco VXI supports multiple Branch to Campus VPN options. DMVPN is the only IPSec site to site solution that officially supports integration with QoS. WAAS and QoS need to be configured for each branch to optimize the voice and video traffic for all the branch users.
A DMVPN setup in the Cisco VXI system requires an ASR router at the headend and supported versions of ISR G2 routers in the branches.
Refer to network section for details on the deployment of DMVPN. Cisco Security Manager (CSM) must be used to configure DMVPN. Also refer to documentation at: http://www.cisco.com/en/US/products/ps6658/index.html
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a008075ea98.pdf
CVO
To deploy VXC endpoints behind in CVO, the administrator has one of three options listed below to ensure secure deployment:
•
–
–
–
•
•
The table below lists the ports that need to be opened for Auth proxy or dedicated switchports.
Table 26 Auth Proxy
VMware View web
80
VMware View https
443
PCoIP USB traffic
32111
PCoIP old port, being phased out
50002
PCoIP TCP traffic
4172
PCoIP UDP traffic
4172
VXC VPN
Cisco Unified Communications Manager 8.6 or above, Cisco ASA 8.0.4 (or above) with "AnyConnect Cisco VPN Phone" license, Multi-session support on the ASA and the round table phones (8961, 9951 or 9971) upgraded to 9.2.3 phone release (SIP protocol firmware load only). Note that only a phone upgrade is required for this solution and no change to the VXC endpoints is required.
With the introduction of VXC VPN, all the traffic is switched in software. The software is tuned to provide priority to voice/video traffic on the phone VPN to ensure quality. Further, once VXC VPN is enabled the layer 2 traffic from the computer port can't be switched and only IP traffic is sent in the VPN tunnels.
Deploying VXC VPN is multi-step process and all of them are detailed at link below http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/security/8_0_2/secugd/secuvpn.html. VXC VPN deployments differs from existing IP Phone VPN deployment in two crucial ways; a firmware upgrade is required on the IP Phones and the number of ASA AnyConnect Cisco Phone VPN licenses consumed. In general all the best practices listed in the document referenced above should be followed, however the key steps involved along with some VXI specific changes, best practices and recommendations are listed below.
•
•
•
•
Note
Table 27 lists the traffic types and ports are allowed on the Phone's computer port using fixed ACLs, all other traffic is dropped.
Table 27 Traffic Types and Ports
Please refer to VXC VPN release notes for more details at: http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/9971_9951_8961/firmware/9_2_3/release_notes/9900_8900_923.html#wp74488
Nexus 1000v
Nexus 1000v is central in providing advanced security features and is a required component for deploying the Cisco Virtual Security Gateway. Guidelines for designing and configuring Nexus 1000v in the Cisco VXI environment are covered in the Data Center chapter of this design guide. Once the traffic from the VMs is switching in the virtual environment as expected, Nexus 1000v security features should be turned on. Port Security, DHCP snooping, Dynamic ARP inspection and IP source guard are the features that should be enabled to secure the Cisco VXI environment. Details on configuring each one of these features is covered in the Nexus 1000v Security configuration guide at http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0_4_s_v_1_3/security/configuration/guide/n1000v_security.html. General Nexus 1000v deployment guide is present at http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/guide_c07-556626.html.
Best Practices
•
•
•
•
VSG
The components needed to successfully setup VSG in the Cisco VXI system are: Dual redundant VSG VM, VNMC for management and Nexus 1000v. A detailed document of the configuration and deployment caveats including an up to date version compatibility can be found at: http://savbu.cisco.com/index.php/nexus-1000v-homepage/n1kv-sales/n1kv-sales-files/1001-nexus-1000v-virtual-security-gateway
The latest release of VSG requires version 1.4 of Nexus 1000V distributed virtual switch. Nexus 1000V and VSG are not supported in XenServer or Hyper-V environments. VSG is managed by Virtual Network Management Center (VNMC) only and not via Nexus OS CLI.
Nexus 1000V Virtual Supervisor Module (VSM) is deployed in two forms: VSM on a VM or VSM on a Nexus 1010. Currently, the Cisco VXI system supports VSG with the VSM on a VM only. The VSG VM cannot be vMotioned in this release of Cisco VXI, and is not supported. VSG is designed for large scale cloud deployments and supports Multi-tenancy. Although supported in the product, multi-tenancy features were not tested for this release of Cisco VXI. Further, in this release only, active-standby mode of VSG HA is supported in Cisco VXI. All access external to/from the zone and within the zone is blocked by default.
Best Practices
Zones are created by using network/VM attributes. The vm.portprofile-name is recommended since it provides the maximum lockdown in sync with Nexus 1000v port profiles. Other attributes can also be used for creating trusted zones and have been validated in Cisco VXI however, care must be taken with naming schemes of the VMs so that unintended VMs are not allowed access due to naming scheme inconsistencies. Further, VM naming schemes are normally outside the administrative jurisdiction of the security administrator and hence VM name based attributes provide less control in the Cisco VXI environment.
Cisco VXI specific policy recommendations: When creating policies for the virtual desktop zones following minimum communication needs to be allowed through the VSG firewall.
•
•
•
•
•
•
All attempts by any HVD to directly communicate with any other HVD within the zone or in a different zone are blocked by default, but should also be logged. This can be done by creating an explicit any-any deny policy that is logged. The implicit deny policy in VSG does not allow logging. It is recommended to place the vCenter and virtual desktop brokers in a separate zone to allow better control, and also to simplify changes.
Below is the list of ports that need to be opened in the VSG firewall to allow basic communication from
Cisco VXI HVD and Cisco VXI specific applications, such as Cisco Unified Personal Communicator.
Table 28
List of Ports
Note
Antivirus Solutions in Cisco VXI
McAfee Optimized Virtual Environments - Anti-Virus (MOVE-AV)
When designing an anti-virus scanning system for Cisco VXI, it is recommended to dedicate server resources to the MOVE Antivirus Offload servers and preferably place these servers within the same cluster as the virtual desktops. One MOVE Antivirus Offload server per hypervisor is recommended for maximum performance by McAfee.
In a large deployment where hundreds of servers host the virtual desktops, it might be desirable not to install the MOVE Antivirus offload server on each host hypervisor, especially since each MOVE Antivirus Offload server instance can consume up to 10% of the server compute resource. In such scenarios, it is possible to set up the Offload Server on dedicated hosts. If deployed on dedicated hosts it should be ensured that enough network bandwidth is available between MOVE Antivirus Offload server and the HVDs, and network latency is very small. In situations where there is a physical firewall such as Cisco ASA or virtual firewall such as Cisco VSG between the HVDs and the MOVE Antivirus Offload server, appropriate ports need to be opened on the firewall. The MOVE Antivirus Offload server's default TCP port is 9053, and is customizable during installation.
Depending on the enterprise virtual desktop deployment strategy, two separate deployment scenarios are suggested. These scenarios are differentiated primarily based on how HVD golden images with MOVE Antivirus are shared across clusters of virtual desktops. The shared underlying goal for the two deployment scenarios is to:
Ensure that IP address of the correct MOVE Antivirus Offload server is reachable by all the HVDs in the cluster, no matter which Master Image was used to create the individual HVD and, ensure the ePO has correct policies configured even where golden images are shared across the clusters. The two scenarios are further detailed in the reference link below and the reader can choose the scenario that best suits their virtual desktop deployment strategy.
https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/23000/ PD23333/en_US/MOVE_Antivirus_2_0_Deployment_Guide.pdf
Beyond the deployment guidelines above, the installation of MOVE Antivirus components is independent of the underlying virtual infrastructure. Detailed installation instructions can be found at the reference links below. https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/23000/PD23332/en_US/MOVE_AV_20_Product_Guide.pdf VXI specific scaling guidelines with MOVE-AV are discussed in the "Performance and Capacity" chapter.
Trend Micro Deep Security Agentless Anti-Virus
Trend Micro Deep Security appliance is an agent less system that requires VMware vSphere 4.1 or higher to leverage the VMware vShield Endpoint APIs. Deep Security works with VMware View running on VMware vSphere infrastructure. In Cisco VXI the following versions of the key software components were validated. Any versions higher than the ones listed below should also be compatible, but haven't been validated.
•
•
•
Cisco VXI can scale to more than 100 virtual desktops per UCS blade and this level of density requires and appropriate sizing guidelines should be followed to ensure that adequate memory is allocated to the Deep Security Virtual Appliance. Please refer to the section "Appendix C: Deep Security Virtual Appliance Memory Usage" within the install guide for sizing guidelines. The install guide can be accessed via the following link: http://www.trendmicro.com/ftp/documentation/guides/Deep%20Security%207.5%20SP3%20Installation%20Guide.pdf
Within Cisco VXI it is highly recommended to tie each Deep Security Virtual Appliance to physical host or compute blade that the appliance protects within the VMware vSphere cluster. In case of host failure in the cluster, VMware vSphere will vMotion all the virtual machines on failed host to a healthy host along with the appliance automatically. But, if a host ends up with two active Deep Security virtual machines it will lead to issues with antivirus operations leading to un-intentional security holes.
Note
For deployment and configuration details of Trend Micro agent less Deep Security Appliance please refer to the following links:
Deep Security Installation Guide - http://www.trendmicro.com/ftp/documentation/guides/Deep%20Security%207.5%20SP3%20Installation%20Guide.pdf
Deep Security User Guide -
http://www.trendmicro.com/ftp/documentation/guides/Deep%20Security%207.5%20SP3%20Users%20Guide.pdf
For More Information
Table 29 provides more detailed information regarding specific vendor information, including hardware and software, discussed in this chapter.
Table 29 Security Links
Cisco SAFE Architecture Guide
http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/SAFE_RG/SAFE_rg.pdf
Cisco Data Center 3.0 Security Guide
http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DC_3_0/dc_sec_design.pdf
Cisco Identity-Based Network Security Guide
http://www.cisco.com/en/US/solutions/collateral/ns340/ns394/ns171/CiscoIBNS-Technical-Review.pdf
Cisco 3650 Command Reference Guide
http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_35_se/command/reference/cli1.html#wp2757193
Cisco Business Ready Teleworker Design Guide
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a008074f24a.pdf
Cisco ASA 8.x : VPN Access with the AnyConnect VPN Client Configuration Example
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00808efbd2.shtml
Microsoft - Disabling Remote Desktop Services Features
http://msdn.microsoft.com/en-us/library/aa380804%28VS.85%29.aspx
Quality of Service
Quality of service (QoS) in a Cisco® Virtual Experience Infrastructure (Cisco VXI) system is required not only within the delivery network, but within the data center as well. In the campus and WAN networks, QoS is used to help ensure the same speed of access to data and desktop applications that people have come to expect with their laptop and desktop systems. A Cisco VXI data center requires QoS. Moving the desktop applications into the data center puts these applications on the same LAN as many of the application servers they are accessing. The desktop to application server traffic no longer traverses the WAN, but requires the same kind of service policies and prioritization it received while traversing the larger network.
QoS in a Cisco VXI system has unique challenges. In particular, the protocols involved are proprietary and in some cases encrypted. Often the applications being displayed on the desktop cannot be differentiated because they are all encapsulated in the desktop virtualization display protocol. Traffic (for example video) may be put into a separate channel, but this implementation still may be proprietary and cannot be handled by normal QoS. Therefore, network devices, which formerly could optimize data based on specific markings per application, types of traffic, or the protocol itself, no longer can use that level of granularity. You can use the information presented here to improve the traffic for which you have visibility.
Table of QoS Markings
The following sections discuss the various protocols, including how to recognize them, set their Differentiated Services Code Point (DSCP) values, and optimize the settings to handle data throughout the network. Table 30 lists the protocols in a generic Cisco VXI system.
Table 30 QoS Markings of Cisco VXI-related
Protocol
Figure 77 Overview of Protocols within Cisco VXI Network
Data Center
Classification and marking should be performed in the data center as close to the application servers and virtual desktops as possible. Then, provided that proper QoS policies and queuing priorities are put in place, these markings should be maintained and their traffic handled appropriately throughout the network.
Markings
Many applications do not mark traffic with DSCP values. For even those that do, the marking may not be appropriate for every enterprise's priority scheme. Therefore, you should perform hardware-based classification (using a Cisco Catalyst® or Cisco Nexus® Family switch) instead of software-based classification. In testing, the markings were implemented on a Cisco Nexus 1000V Switch whenever possible. The DSCP values given and the ports matched are based on Table 30. For more information and examples, see the Cisco Virtualization Experience Infrastructure Configuration Guide at:
http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/VXI/configuration/VXI_Config_Guide.pdf.
Queuing for Optimum Cisco Unified Computing System Performance
In addition to marking traffic to traverse the network outside the data center, you may need to mark different traffic to traverse devices within the data center. For example, desktop virtualization traffic servicing desktops should not starve the Cisco Unified Computing System™ for storage resources. The Cisco Unified Computing System is uniquely equipped with the capability to mark and queue outbound packets to improve its performance with other data center entities (such as storage). Details and recommendations about queuing strategies for activities specific to the Cisco Unified Computing System can be found in the Cisco Unified Computing System GUI Configuration Guide, at
http://www.cisco.com/en/US/docs/unified_computing/ucs/sw/gui/config/guide/1.3.1/UCSM_GUI_Configuration_Guide_1_3_1.pdf
Network
The primary responsibility of the network devices relative to QoS is to route the traffic to the correct queue, assuming that the local switch (in the branch office or data center) has marked the data appropriately based on its type of traffic. Proper priority is given to forward the traffic based on the DSCP markings. Although remarking could take place within the network, if the endpoint locations and data center deploy the suggested remarking configurations, there should be no need for further remarking within the network.
In a campus network, the bandwidth is high enough so that contention for the resources should be minimal. However, slower connections in a branch WAN router network need to be examined. Here at the egress point from the high-speed connections of the branch-office LAN to the slower-speed links of the WAN is where bandwidth contention is likely to occur. Service policies that constrain the amount of bandwidth that is dedicated to a given protocol are defined and applied at this point. These same queuing and bandwidth configurations can be placed anywhere there is a concentration of Cisco VXI endpoints, to enforce the appropriate response in case of traffic congestion (Figure 78).
Figure 78 Location of Service Policies for QoS
To view an example of the Bandwidth Service Policies, see the in the Cisco Virtualization Experience Infrastructure Configuration Guide at:
http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/VXI/configuration/VXI_Config_Guide.pdf.
Endpoint
Cisco VXI thin-client endpoints do not typically provide the capability to mark the desktop session traffic. Therefore, the same marking that was performed on the Cisco Nexus1000V in the data center for outbound desktop virtualization traffic must be performed at the branch office on behalf of the endpoints for the traffic returning to the data center virtual machine. The configuration on the branch switch will look similar to configuration presented in the Cisco Virtualization Experience Infrastructure Configuration Guide at:
http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/VXI/configuration/VXI_Config_ Guide.pdf.
Admission control is another means of contention reduction that is required by some applications to enforce QoS. Using Cisco Unified Personal Communicator for hard phone control of an IP phone, voice-over-IP (VoIP) traffic is supported outside the display protocols. This traffic is admitted into the priority queue. Admission control is required to prevent this priority queue from flooding. Cisco Unified Communications Manager supports two kinds of admission control: location based and Resource-Reservation Protocol (RSVP) based.
Although location-based communications admission control is extensively deployed in many Cisco Unified Communications Manager installations, it cannot use redundant links or a mesh topology. RSVP-based admission control is a network-aware admission control system. With the help of proxies, called RSVP agents, that run in Cisco 2800, 2900, 3800, and 3900 Series Integrated Services Routers, RSVP is a much more robust solution for controlling hard phones in Cisco VXI. For information about implementing RSVP-based admission control in Cisco Unified Communications Manager, please see Part 2, Chapter 8, in the 8.0 Cisco Unified Communications Manager System Guide.
VXC client QOS Considerations
The Cisco VXI validation includes the VXC4000, a UC software appliance that transmits both UC (voice and video media streams) and DV traffic using single IP address and VLAN. Since the endpoint separates these traffic types into separate streams, it is recommended to perform QOS marking on the access switch. For specific QOS guidance on integrating these endpoints into a Cisco VXI deployment, please refer to the endpoints chapter.
Note that when deploying the VXC 4000 in a network that includes separate VLAN's or VRF's for voice and data traffic that are secured (ie. there exists a firewall limiting traffic flow between the two networks), you will need to employ a network based mechanism to allow inter-VLAN/VRF connectivity. In the case that the IP phones are placed in the voice VLAN and the VXC clients connected to the data VLAN, you will need to use a network based mechanism to allow media traffic to pass between IP phones and the VXC clients. In the case that both IP phones and VXC clients are placed in the voice VLAN, you will need to use a network based mechanism to allow the VXC clients to access the data VLAN.
Some of these network based approaches include using static ACL's to open up the firewall based on endpoint IP address and application port numbers in use. For example, this could mean identifying UDP port ranges used by the endpoints to transmit voice and video streams. It is recommended to limit the UDP port ranges utilized by the VXC endpoints in this case. Another approach is to dynamically open the firewall for media streams by monitoring the signaling traffic passing between the endpoint and the CUCM using a application layer gateway. Note that this assumes that the signaling and media follow the same route through the network. Another approach is to assign the endpoint to a TRP (Trusted Relay Point) so that all media traffic originated by the TRP is allowed through the firewall. Please refer to the UC SRND " Network security and virtualization" for more detailed guidance on the implementation of these solutions.
For More Information
The following links offer more detailed information regarding specific vendor information, including hardware and software discussed in this chapter.
Cisco UCS GUI Configuration Guide
Cisco Unified Communications Manager Systems Guide
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_0_2/ccmsys/accm.pdf
Cisco Virtualization Experience Infrastructure Configuration Guide
http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/VXI/configuration/VXI_Config_Guide.pdf
Performance and Capacity
This chapter describes the tools and methods to use for capacity planning an end-to-end Cisco® Virtual Experience Infrastructure (Cisco VXI) deployment.
In an enterprise network, performance and capacity planning for desktop virtualization services has three fundamental dimensions:
•
•
•
It is important to note that recommendations and guidance provided in this chapter are based on testing done across an end-to-end Cisco VXI system with a Cisco VXI workload that includes rich media and anti-virus. Detailed test results are available in the Performance Guide published along with this CVD. Readers can use the information in this chapter to guide them in their capacity planning but should carefully consider their own workloads and environments to make adjustments as needed for their own deployments. This chapter is also not a comprehensive guide for scaling every Cisco and third-party component used in the Cisco VXI system - for these, the reader is best served by reading the product documentation directly.
Computing and Storage Capacity Planning
When migrating users from physical desktops to virtual desktops, it is important to have a good understanding of the user base and their resource requirements in terms of CPU, memory and disk space. Many enterprises transitioning to desktop virtualization also see it as an opportunity to do Windows 7 migration so understanding the implications of such a transition is also important.
A key step in the process is to group the users being migrated based on common application, workload and desktop (dedicated, personalized) needs so that capacity planning for their compute and storage needs can be done at the group level. Grouping enables the administrator to develop a base profile for each user group based on common factors such as same operating system, applications and usage patterns. The base profile should also include resource metrics such as CPU, memory, network bandwidth and disk I/O utilization that is representative of the group by collecting data over a period of time from a statistically significant number of users from within that group. The base profile can then be used to estimate the compute and storage needs of the user group in a virtualized environment. If disparate user groups are not estimated separately, it could result in wasted capacity or if capacity is underestimated, resource constraints could result in poor user experience. Therefore, from an overall resource estimation and capacity planning perspective, administrators should group users with similar workloads and environment rather than across the entire user base being migrated - particularly in large desktop virtualization deployments.
In the next few sections, we will take a closer look at the steps involved in planning for the compute and storage needs of an end-to-end Cisco VXI deployment. The approach taken can be summarized as follows:
•
•
•
•
•
•
•
User Workload Profile
A base profile used in capacity planning should include the workload profile in terms of the applications, the activities within those applications and a pattern of usage that is representative of the user group. The group's workload profile can then be used to classify the user group into one of the generic workload profiles commonly used by vendors to characterize users with similar compute, storage and networking needs. The generic profiles form the basis for performance and scalability results used in capacity planning as benchmarking tools used in server and storage performance testing use these profiles to generate a corresponding workload. The intensity of the workload can significantly vary the scale and capacity results and as such it is critical to any data used for estimating compute and storage resources needed. Workload profile is also critical if any testing is done in the customer environment to validate the resource estimations as the workload profiles used by load generation tools should closely match the user group's workload profile in order to accurately size the environment. In short, workload profiles play a critical role in any data used for capacity planning and therefore accuracy of sizing estimation used to determine the server and storage needs of the desktop virtualization system being deployed. Since it is difficult to accurately reflect the workload generated by users in different Enterprise environments using a generic workload profile, any capacity estimations based on data using a generic workload profile should be adjusted to accommodate any differences - a more conservative estimation should be implemented and resource utilization should be monitored closely over a period of time to make any adjustments as needed to the estimated server and storage needs.
It is also important to note the workload used in Cisco's VXI system for scale and performance benchmarking includes the following applications that are typically not seen in similar benchmarking tests from other vendors:
•
•
For more details on the workload used in the VXI system for scale and performance capacity testing, see the "Workload Considerations" section of this chapter.
Resource Utilization in Current Environment
An important factor for estimating resource requirements in a virtualized environment is the resource utilization in the current physical desktop environment. Therefore, for a given target user group being migrated to virtual desktops, it is important to have a full understanding of the current environment and to characterize the resource utilization in terms of the following metrics:
•
•
•
–
–
–
•
Administrators should monitor the use pattern of the target user group and determine the average and peak utilization for each of these in the environment. Monitoring should factor in potential variations in use pattern based on geographical location, when users log on for the day including shift transitions for environments that work in shifts, timing of backups, virus scans, and similar activities.
The resource utilization of the average physical desktop user can be determined as follows:
•
•
•
Once the administrator has characterized the average and peak resource utilization for the group using a physical desktop, the process of estimating the compute, storage, and networking needs for migrating to a Cisco VXI system can begin.
Estimating Resource Requirements in a Virtualized Environment
To accurately estimate the resource requirements in a virtualized environment, several factors must be considered. In this section, we will take a closer look at three of these factors, namely CPU, memory, and storage. The data gathered in the previous section in terms of CPU, memory and storage can be used to estimate the number of virtual desktops a given server in the data center can support. Virtualization does introduce additional factors so the above resource requirements may need to be adjusted before estimating server capacity. Capacity of a single Server capacity can now be used to estimate hardware resources or servers necessary for a large-scale deployment.
Estimating CPU
To estimate the CPU resources needed in a virtualized environment, you can use the data from the physical desktops as illustrated in the example below. Consider the following scenario:
•
•
•
–
–
–
–
Based on the above, the average CPU requirement of each desktop is 8% of 2x2GHz = 320GHz. With a conservative guard band of 25 percent, the average CPU requirement for each desktop = 400MHz.
You can now start sizing your server requirements using the average CPU per desktop and the compute capabilities of the server chosen for your deployment. Processor info for different Cisco UCS servers that can be used for hosting virtual desktops are shown in the tables below.
Note
Table 31 UCS B-Series Blade Servers - Models and Processor Info
Table 32 UCS C-series Rack Mount Servers - Models and Processor Info
For additional information about the Cisco UCS server chassis and blade servers, please refer to the "Data Center" chapter.
Using computing power as the only criterion, you can calculate the number of desktop virtual machines on a given blade server as shown here. For example, the number of virtual desktops that a Cisco UCS B250 M2 server can support would be:
Total compute power = 2 socket x 6 core a 3.33GHz = 39.96 GHzAverage CPU utilization of desktop = ~400MHzNumber of virtual desktops per server = 39.96GHz/400MHz = ~100 desktops
Note
The single server sizing estimation above could be lower or higher in your deployment depending on the average utilization of the physical desktops used. Similarly, the Cisco UCS server model chosen for a given desktop virtualization deployment can also affect the number due to differences in the computing capabilities of the different servers available on the Cisco Unified Computing System™. As new processors are released for each server model, improvements in processor designs can further increase the number of desktops supported in which case an estimation based on compute power is only a starting point as higher densities could be supported.
If computing power is the only criterion used, the above estimation for a single UCS blade server can be extrapolated to determine the overall UCS server needs of a Cisco VXI deployment. However, a similar exercise using memory and storage is necessary to determine the limiting factor for your environment before this estimation can be used deployment wide. A number of other factors also have to be considered before an estimation can be considered final for a given server blade.
Estimating Memory
To estimate the overall memory requirements in a virtualized environment, use the same methodology used for estimating CPU. The memory estimate for a single virtual desktop can be calculated from the statistical average determined from the physical desktops, as shown in the following example.
•
•
•
•
Table 33 Cisco UCS Memory Capacity
For additional information about the Cisco UCS server chassis and blade servers, please refer to the Data Center chapter in this design guide.
Using memory as the single criteria for sizing the hardware needs in a Cisco VXI deployment, you can calculate the number of desktop virtual machines that a blade server can support as shown here. For example, the number of virtual desktops that a Cisco UCS B250 M2 server can support would be:
Memory Capacity = 192GBAverage memory requirement for a virtualized desktop = ~1.3GBNumber of virtual desktops per server= 192G/1.3G = 147 desktopsAs with CPU estimation, the estimated number of virtual desktops on a single server may be lower or higher, depending on the data gathered from the physical desktops and the model of Cisco UCS server selected for the deployment. Also, this data can be used to extrapolate the total number of servers needed for a given Cisco VXI deployment if memory is determined to be the limiting factor.
Note that the memory utilization from a physical desktop used in the preceding calculation can vary depending on the guest OS and applications deployed in a given environment. An alternative but also a less accurate method of estimating the number of virtual desktops is to use the minimum recommendation from Microsoft for per-virtual machine memory utilization, as shown in Table 34. However, for Microsoft Windows XP, the minimum recommendation shown here should be increased to 512 MB to accommodate Microsoft Office applications and other applications that may be running on the desktop. The memory configuration used for virtual desktops in an end-to-end Cisco VXI system is also provided as an example. The memory configuration was sufficient to provide a good user experience for the workload profile validated in the end-to-end system.
Table 34 Memory Configuration
Estimating Storage
For storage, the average IOPS and throughput data collected from monitoring the physical desktops can be used as the storage requirements for the virtualized desktops. For example, if the average IOPS is 5 and the average throughput is 115 kbps, then the same IOPS and throughput values should be expected when the desktop is virtualized. For a desktop virtualization deployment, the factors summarized here can also have a significant effect and should be considered when sizing storage needs. For example, IOPS can peak when:
•
•
•
Some applications specific to a customer environment can cause similar spikes in storage I/O. All these factors must be taken into account when designing the storage environment for Cisco VXI deployments.
Another aspect that needs to be considered when sizing storage needs is the disk space allocated to a virtual desktop. You can calculate this space by adding the storage requirements required for each of the following items:
•
•
•
•
•
For an example of the storage allocation to use for virtual desktop machines, see Table 35. Note that deploying desktop virtualization using View linked cloned desktops with a provisioning server will minimize the per-desktop disk space necessary for windows and applications as large groups of desktop pools can share the same master virtual machine image. As a result, only the delta between that and the available disk space on the master VM may need to be allocated on a per-desktop basis by using deployment models mentioned above. However this delta disk size can also be minimized by refreshing the OS disk periodically or by using non-persistent desktops - so a number of options exist in this regard as well.
Table 35 Storage Allocation for Desktop VM
Estimating Server Capacity
As stated before, several factors can influence the performance and scalability of a server. The estimation for the number of virtual desktops on a given server can yield a different number if each factor is considered independently. For this reason, the estimations performed in the Estimating CPU and Estimating Memory sections earlier in this chapter for a Cisco UCS B250 M2 server are theoretical exercises. However, the data (summarized in Table 36) can aid in finding the limiting factor for a given server, as well as provide the initial virtual machine density to target if testing is performed to validate the estimation using the specific workload for that environment.
Table 36 Estimated Capacity
(Theoretical for Cisco UCS B250 M2)CPU
400 MHz
100
Memory
1.3 GB
147
Note
The theoretical estimation shows that the limiting factor for this deployment is the compute capacity However, actual scale and performance results on a B250 M2 in the VXI system using the VXI workload shows the results to be different from the ones in the table above. For actual data from the testing, see the Results Summary section later in the chapter.
The reason for the difference between the theoretical and estimated data can be attributed to workload used in the theoretical estimation vs. the one used in testing. For any desktop virtualization deployment, workload is one of the most critical factors for accurately estimating the virtual desktop capacity of a given server. Therefore, it is critical that you use a workload that closely matches the user group's workload when validating the theoretical server sizing estimation.
In addition to the scalability study testing done across the end-to-end Cisco VXI system discussed in this design guide, Cisco has published a number of other design guides in partnership with VMware, EMC and NetApp which are listed below as reference:
•
http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns743/ns993/landing_dcVirt-vdi.html
•
http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns743/ns993/landing_dcVirt-VM_EMC.html
•
http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns743/ns993/landing_dcVirt-VM_netapp.html
In the Cisco VXI system discussed in this design guide, single server scalability testing was done for a number of deployment profiles across the end-to-end Cisco VXI system similar to how customers would deploy and use the system. The testing was done using test tools located in the campus network that initiate VDI sessions to the virtual desktops hosted in the data center where the session would span the following:
•
•
•
•
•
•
For details on the results and data from the single server testing done in the Cisco VXI system using a Cisco VXI workload - please see the "Single Server Scale and Performance Testing" section of this chapter.
In addition to the workload, there are a number of other factors apart from CPU, memory, and storage utilization can influence a server's scale and capacity numbers in a Cisco VXI deployment, as discussed in the next few sections.
Hypervisor Considerations - VMware ESXi
Hypervisor resource consumption should be closely monitored for CPU, memory and storage performance. Memory consumption on a hypervisor should be monitored to see if any memory ballooning could be an indication that the host is in need of additional memory. Resources should also be monitored at the cluster level so that additional resources can be added if needed.
Transparent Page Sharing
The transparent page sharing (TPS) feature available on ESXi hypervisor can significantly reduce the memory footprint, particularly in desktop virtualization deployments where the OS and applications data may have a lot in common across different desktop virtual machines. TPS uses a background process to monitor the contents of memory and evaluates the data being loaded to determine if it is the same as what is already in memory. If it is the same, the virtual machine attempting to load the duplicate data will be redirected to existing content in memory, thereby enabling memory sharing. TPS can be thought of as memory de-duplication feature and is enabled by default. For more information about this feature, see Memory Resource Management in VMware ESX Server document.
In a Cisco VXI environment, transparent memory sharing enables a server to accommodate a larger number of virtual desktops on a single blade, at least from a memory perspective though this may not be a limiting factor.
Since TPS uses redundancy to share and overcommit memory between virtual machines running on a host, the workloads on these virtual machines should be as similar as possible. To optimize the effect of TPS in a Cisco VXI environment, you should group virtualized desktops of users with similar workloads, such as the same guest OS (Microsoft Windows 7 and Windows XP) and applications (Microsoft Office and antivirus applications), on the same host to optimize the effect of TPS.
TPS behaves differently on the newer hardware-assisted virtualization processors, such as the Intel Nehalem and Westmere processors that are used on Cisco UCS servers. The newer processors use memory pages that are 9KB in size and improve performance by 10 to 20 percent. TPS operates on 4-KB pages to eliminate duplicate data. With these newer processors, TPS is not in effect until the available memory reaches a minimum and there is a need to overcommit memory. A background process is still monitoring and scanning the memory pages to determine when TPS takes effect. See the following VMware Knowledge Base articles for more information about TPS with the newer hardware assisted virtualization processors:
•
•
Also note that VMware studies have shown that TPS does not have any effect on the performance of the host and therefore recommends the use of this feature. Please contact VMware for additional information about TPS.
High-Availability (HA) Considerations
For a desktop virtualization deployment of significant scale, high availability of the virtual desktop is a concern for most administrators. Virtual desktop machines, as a best practice, are typically deployed in clusters so that a pool of hosts are available to the cluster. With clustering, VMware can distribute the virtual desktops across the pool of resources using VMware DRS to increase the resources available to the virtual machine. The clusters are also used to implement specific high-availability features such as VMware High Availability (HA), DRS, Fault Tolerance, and vMotion. However, deploying servers in a cluster can change and potentially limit the maximums that VMware supports. The supported limits are available through VMware configuration maximums and are available when new releases change the supported limits. Table 37 lists some of the data relevant to sizing a desktop virtualization deployment. This table should be reviewed for planning any large-scale deployment of Cisco VXI. For a complete set of configuration maximums, refer to VMware documentation.
Table 37 Configurations Maximums
Power Management Policy
The power management policy for the virtual desktops in a desktop virtualization environment can have affect the host resources. VMware View recommends that the virtual desktop be put in a suspended state if it is not in use. The suspended state is an optimal configuration that enhances the user experience while reducing resource (CPU and memory) use. If all virtual machines are left powered on, the host resources cannot be used by other virtual machines on the same server. With persistent desktops, the virtual machine can be immediately suspended when the user logs off.
Storage Considerations
Desktop virtualization architectures solution from VMware used in the Cisco VXI system reduce the overall storage needs as follows:
VMware View uses Linked Clone technology through which a parent virtual machine's virtual disk is used as the main OS disk for all clones created through the linked clone process. This feature prevents each cloned desktop from needing its own OS disk, thereby reducing the overall storage capacity needed for a Cisco VXI deployment. See Data center chapter for more information about deploying virtual desktops using VMware View.
Using pooled desktopslinked clones with VMware View greatly reduces the aggregate storage capacity necessary for migrating to a virtualized environment. Although the cost of the shared storage is significantly higher than that for using separate disks on laptops and desktops, VMware View can reduce overall storage costs due to the ability to share the same OS disks among many desktop virtual machines.
Operating System Disk
In View deployments, the OS disk refers to the parent virtual machine's virtual disk on which the guest OS (Microsoft Windows XP or Windows 7) and applications (Microsoft Office) are installed. This OS disk is read by all desktops in the pool with VMware View deployments, resulting in significant storage savings, since a single OS disk can be used by a large number of desktops without each having to maintain its own OS disk. Ideally, this disk should be read-only for both storage and operation efficiency, but it can be used as a read-write disk to store the following types of typical Microsoft Windows desktop data:
•
•
•
For better storage and operation efficiency, the OS disk should be kept as a read-only disk, and the data listed here should be redirected to another location as follows.
•
•
•
Thin Compared to Thick Provisioning
Thin provisioning is a way to conserve storage resources and increase storage utilization in a virtualized environment. With thick provisioning, when a virtual machine is deployed, the virtual disk associated with the virtual machine is given its full allocation of storage regardless of whether it uses it, resulting in wasted space. With thin provisioning, this inefficiency is reduced by allocating storage resources only when the virtual machine needs them. Therefore, a virtual desktop running Microsoft Windows 7 with a 20-GB disk will not have 20 GB of disk space reserved on the storage system (SAN or NAS), though Microsoft Windows and applications running on the desktop will operate as if it has the full 20 GB of space allocated to it. On the back end, VMware ESX and ESXi hide the actual state of the storage allocation and allocate the space to the desktop only as and when it needs it. The dynamic allocation of storage is performed in chunks, with the unit size of a chunk defined when the data store is created. This specific type of thin provisioning is referred to as a VMware virtual disk and is supported with both file-based (NFS) and block-based (SAN) data stores. For more information about VMware thin provisioning, please refer to the following VMware Knowledge Base article:
•
Therefore, thin provisioning enables the efficient use of the underlying storage resources and improves the scalability of the aggregate storage capacity by overcommitting the storage. In a Cisco VXI environment, this approach results in a higher number of virtual desktops that can be supported with the given storage capacity. For this reason, thin provisioning of VMware's virtual disk is recommended in an end-to-end Cisco VXI system, though you should note that thin provisioning does have some effect on the CPU performance of the host.
In the Cisco VXI system, all VMware View pools were validated with thin provisioning enabled on the parent virtual machine used to create the VMware View desktop pools. In each case, the parent virtual machine's virtual disk was residing on either EMC's Fibre Channel attached SAN storage or NetApp's NAS (Network File System [NFS]) storage.
In addition to VMware's virtual disk thin provisioning, storage vendors such as NetApp and EMC offer thin provisioning at the storage level that further improves the storage efficiency gained by VMware thin provisioning. With storage thin provisioning, the actual state of the storage allocation is hidden from VMware ESX and ESXi by the storage system.
For Cisco VXI deployments, both virtual disk and storage thin provisioning can be deployed in a complementary fashion to optimize storage utilization. All validation with NetApp in the Cisco VXI system was performed with both virtual disk and storage thin provisioning in place.
Note
Please refer to the For More Information section of this chapter.
Storage Optimization Technologies
Storage costs are typically the highest CAPEX costs associated with a VDI deployment and reducing these costs are critical to VDI adoption. Storage Optimization or caching technologies from vendors such as Atlantis Computing can significantly reduce the IOPS the back end storage array needs to support by offloading these IOPS using a caching technology deployed closer to the desktops. Large SAN or NAS based storage arrays provide the IOPS necessary for a VDI deployment by increasing the number of storage drives and the number of storage drives required are often beyond that of the capacity needed to support the user base of VDI users. As such, we are adding drives to the storage array to meet the IOPS performance necessary for a good VDI user experience. Storage Optimization technologies strive to reduce the IOPS performance that the storage array needs to deliver by offloading it to local DRAM or SSD cache residing on the same server or centrally deployed between the servers and the back-end storage system. In the case of Atlantis, storage optimization is for both read and write caching. Atlantis for instance employs de-duplication technology to reduce the physical storage capacity needed to store the information from the virtual desktops. Through the read caching capabilities, it can significantly increase the number of virtual desktops supported for a given number of physical drives as the number of drives would have to be otherwise increased to meet the IOPS load. In environments were IOPS load is significant, the server density can be limited by IOPS and in these cases, these technologies can also remove this bottleneck and improve the VM density on the server.
Storage Footprint Reduction
Storage vendors support technologies that offer economies of scale for sizing the storage needs of a desktop virtualization deployment. Technologies include data de-duplication to increase storage efficiency by eliminating redundant information in the data being stored. This feature can be used for primary file systems and end-user file data in VMware and other virtualized environments. If the duplicate data is from different virtualized desktop virtual machines, the data is stored only once and the metadata associated with it is changed so that both virtual machines have access to the data. As with thin provisioning, de-duplication can provide significant storage efficiencies, improving desktop virtualization scalability since the existing storage can now support a larger number of desktop virtualization desktops. Therefore, enabling de-duplication, particularly in large desktop virtualization deployments, is highly recommended.
Please refer to EMC and NetApp documentation for more information about using de-duplication in a desktop virtualization environment.
Partition Alignment
Microsoft Windows file system partitions running on virtualized desktops should be aligned with the underlying storage partitions. This alignment can improve storage performance by reducing overall I/O latency while increasing storage throughput. This alignment is currently needed only with Microsoft Windows XP because Microsoft Windows 7 (32-bit and 64-bit) automatically provides this alignment. The problem occurs because Microsoft Windows writes 63 blocks of metadata directly at the beginning of the drive, resulting in misalignment of the first partition created on the disk. As a result, the drives may need to read an extra block of data unnecessarily, causing additional IOPS on the drive. To address the misalignment problem, an aligned partition is created on the drive that aligns with the storage system used. Both block-based and file-based storage systems can benefit from this alignment. In the Cisco VXI system, a 64-KB aligned partition was created on the parent virtual machine of the desktop pools to align with EMC's SAN and NetApp's NAS storage. Please refer to Microsoft and VMware's documentation for information about implementation.
Storage Network Considerations
•
•
Similar physical separation is recommended for IP-based storage, such as storage of NFS and Small Computer System over IP (iSCSI) traffic. A separate VMkernel port and VLAN should be used for IP storage traffic using a dedicated uplink port on the host. This type of physical separation of the IP storage traffic from other IP traffic is possible using the latest converged network adapters (CNAs) on the Cisco Unified Computing System, which support 128 virtual uplink ports. If an uplink cannot be dedicated, the separate VLAN used for storage will provide the logical isolation. The physical isolation should be extended into the data center network by using dedicated ports or switches at the access layer where Cisco Nexus 5000 Series Switches are typically deployed. If the storage traffic extends into the aggregation layer of the data center network, Cisco Nexus 7000 Series Switches that are typically deployed at this layer support physical separation through the virtual data center (VDC).
•
•
Guest OS Optimizations
Microsoft Windows can be optimized to improve the performance and scalability of virtualized desktops as outlined below.
•
•
•
•
A number of windows optimizations can be enabled on virtualized desktops to improve performance. Table 38 shows some of the main optimizations implemented on the Cisco VXI system for Microsoft Windows XP and Windows 7.
Table 38
Microsoft Windows Guests OS Optimizations
Validating Capacity Estimates
The next step in the overall resource planning process is to validate the capacity estimations based on factors such as CPU, memory, and storage as well as factors outlined in the previous section. On the basis of the baseline performance data from the physical desktop and the theoretical estimation for the number of virtual desktops that can be rolled out on the Cisco UCS blade server chosen for the deployment, perform performance characterization and validation in a virtualized environment to determine the following:
•
•
•
•
•
Workload Considerations
To validate capacity estimates for a Cisco VXI deployment, one option is to roll out the service to a pilot group and validate the resource estimation with actual users. Alternatively, the data regarding user activities, applications used, and use patterns collected from the physical desktops can be used to define a workload specific to that environment. For testing, the custom workload can then be automated to simulate the user workload, or it can be mapped to one of the generic profiles commonly used by workload generation tools used in scale and performance testing.
The workload defines the applications that a person actively uses, such as word processing, presentation, and other office applications, but it can also include background activities such as backups and antivirus scans. Workloads for users within a company will vary depending on a person's job or functional role and may differ according to the organization structure (sales, marketing, manufacturing, etc.). Workloads can also vary based on the time of day, particularly if the desktop virtualization users are geographically dispersed. Background activities that begin at specific times, such as backups and antivirus scans, can also increase workloads.
Table 39 shows a very high level categorization of a user's profile based on their desktop usage patterns. Most workload generation tools will have workloads to reflect these profiles - however, other than the profile names and possibly the applications being used, the actual load they generate for a given profile will still be significantly different from one tool to another in that they may not yield the same performance results. From a capacity planning perspective, it is important to understand the details of the workload to assess how closely it matches your environment. It is probably best to assume a difference and tack on an X% performance hit when using that data for your environment - choice of X depends on how closely a given tool's workload and desktop environment used for testing matches that of yours. The preferable option still is to use feedback from your own production environment to validate the compute and storage estimations made when using performance data resulting from the use of a workload generation tool.
Table 39 User Workload Profiles
Cisco VXI Knowledge Worker+ Profile
For the end-to-end Cisco VXI system outlined in this document, a variation of the first two user profiles was used for testing and will be referred to as the Cisco VXI Knowledge Worker+ (KW+) profile. The details of this profile are outlined in the table below.
Table 40 Cisco VXI Knowledge Worker + Profile
Anti-Virus Considerations
Anti-Virus Scan Policy
The tables following that include the scan policies used for the Anti-virus solution deployed for the testing - see Cisco VXI Performance and Capacity Validation Results Guide for VMware for specifics on the AV solution used for a given test. Note that the AV agent is installed in the golden and as the workload is executed by the simulation tool, this will trigger AV to scan on the reads and writes associated with a given activity, resulting in additional load on the compute and storage resources. For this reason, the scan policy used could change the load on the server and storage resources and impact the performance results used for capacity planning.
Figure 79 Scan Policy for McAfee's MoveAV Solution
Table 41 Scan Policy for Trend Micro's Deep Security Solution
Single Server Scale and Performance Testing
This section covers the validation methodology and a summary of the various scale and performance testing done in Cisco VXI systems. The actual results from the testing will be part of the Cisco VXI Performance and Capacity Validation Results Guide for VMware that will serve as an addendum to this document.
In the following sections we look at the results of the single server characterization done for various deployment profiles, followed by application characterization done for Cisco collaboration applications in a Cisco VXI environment.
Validation Methodology
In this section we take a look at the validation methodology used for the scale and performance testing results documented in the Cisco VXI Performance and Capacity Validation Results Guide. All testing is done across the end-to-end VXI system. For performance testing, workload generation tool from Scapa Test Technologies is used to initiate a large number of user sessions. This tool is used for all scale, performance and other characterization type testing.
Workload Profile: Cisco VXI Knowledge Worker+
As stated earlier, the workload used is a critical factor for any performance related characterization done in a desktop virtualization environment. All the test results presented here used the Cisco VXI Knowledge Worker (KW)+ workload unless it is stated otherwise. An overview of this profile is provided in the Workload considerations section of this chapter.
Success Criteria
For all single server testing, the objective is to determine the virtual desktop density that can be supported on a given model of the server for the specified deployment profile based on a Cisco VXI KW+ profile as defined above. The success criteria used in each case is as follows:
•
•
•
Application Response Times
Table 42 summarizes the average application response times used as the success criteria in the Cisco VXI system. All testing was done using Test and Performance Platform (TPP) from Scapa Technologies. On each virtual desktop hosted on the UCS server, Scapa load generation tool will initiate a VDI session and then initiate activities defined in the workload profile to generate a workload on each desktop. Applications in the workload (except for Cisco Unified Personal Communicator in deskphone mode) are launched and closed in each iteration of the workload loop. Therefore the average response times measured (shown below) for a given application is a combination of the response times measured for that application across all HVDs running on a server as well as the response times across multiple iterations of the workload running on each HVD. The success criteria was derived from a combination of testing done on physical desktops and HVD with these applications and measuring the response times. For each test, the response times measured are compared against the success criteria defined below in order for the test to pass. It is also important to note that Scapa measures the response times from an user/endpoint perspective and not from the hosted virtual desktop in the data center.
Table 42 Success Criteria
Performance Metrics
The following aspects of the server performance are measured for each deployment profile tested. For ESXi, esxtop is used to measure these metrics using a 5s polling interval. Storage statistics from NetApp and EMC are included where possible.
•
•
•
–
–
–
•
Summary of Results
Scale and Performance data for capacity planning based on testing done in the VXI system can be found in the VXI Performance and Capacity Validation Results Guide. A high level summary of the deployment profiles characterized from a single server perspective is provided in Table 43.
Table 43
WAN Capacity Planning
This section looks at the enterprise WAN and the factors that need to be considered to determine the number of desktop virtualization users that can be deployed at a branch site with a finite amount of bandwidth. In simple terms, the number of desktop virtualization users that a WAN link of a given bandwidth can support is:
Bandwidth of WAN link /Bandwidth of single desktop virtualization session
However, in desktop virtualization environments, this type of sizing is a challenge due to a number of variables that can affect the amount of bandwidth in a single desktop virtualization session. In voice over IP (VoIP) environment, in which a voice call is a voice call—that is, there is a predictable, smooth, and a constant 80 kbps per call for a given codec—desktop virtualization session traffic is a complete variable, as a user's network traffic is today. In a voice environment, if a branch location needs to support
10 simultaneous calls, 10 x 80 kbps = 800 kbps of traffic is needed. For desktop virtualization, the session traffic flow can vary widely between two different users, based on what they are doing on their desktops—this is just one of several variables that can vary the bandwidth requirements for a session.
With desktop virtualization, every action that a user initiates (mouse clicks, keyboard actions) and the response to that action is transported across the network and is part of the session traffic between the virtual desktop hosted in the data center and the client that the end user is using. Unlike physical desktops where many applications can be launched and used without network access (e.g. editing a local copy of a Microsoft Word document), using a virtual desktop implies that all activities on that desktop require network access and therefore network bandwidth. For a given virtual desktop session, there is a main display session that is either TCP (RDP) or UDP (PCoIP) based for transporting the desktop display to the end user. There could also be additional TCP sessions associated with the main display session to provide features and experience equivalent to that of a physical desktop such as multimedia redirection [MMR] and USB redirection traffic
•
•
•
•
•
These aspects of the protocol behavior can have a direct bearing on your WAN capacity planning in a number of ways.
In addition to the display protocol itself, there are a number of other factors that can impact network bandwidth and therefore WAN sizing as outlined below
•
•
•
Figure 80 Windows Appearance and Performance Setting
Video
Another important consideration is whether streaming video needs to be supported in virtual desktop. If so there are a number of considerations that impact capacity planning as well the overall user experience. Video in general is very bandwidth intensive with stringent loss, jitter and latency requirements and so video deployment in branch environments require very careful consideration and this challenge exists regardless of desktop virtualization. In VMware View deployments, the video can be transported using Multimedia Redirection (MMR) which is a separate TCP session from that of the main display session which could be UDP based (PCoIP) or TCP based (RDP). This provides the administrator with the ability to provide not only provide QoS that has a direct impact on the overall user experience at the branch but also allows WAN optimization to be used to reduce the bandwidth requirements across the WAN. However there are some caveats that are worth mentioning. First, MMR cannot be used to transport flash video. Second Cisco WAAS does not optimize flash video as of now and lastly, VMware View does not have support for MMR when the guest OS running on the HVD is Microsoft Windows 7.
Printing
Printing in a desktop virtualization environment can also affect the per-session traffic and therefore WAN capacity needed to support it depending on the type of printing solution deployed. Enterprises can deploy the print server in their data center and have the print traffic traverse the WAN network to a local printer at the branch site -either USB attached or otherwise. The USB print traffic is transported on a separate channel from that of the main display session in VMware environments which helps in providing network level QoS that can be important for overall user experience. From a WAN capacity planning perspective, WAN optimization can provide significant to reduce the bandwidth needs associated with printing. There are two deployment options that can be used with WAAS in a desktop virtualization environment - one is to use the Cisco WAAS Print Application Optimizer (PAO) feature (available as of WAAS 4.1) to accelerate Microsoft Windows printing and the second is to deploy a print server on the branch router on the WAAS appliance itself. In the first case, PAO optimizes the Windows printing protocol CIFS/MSRPC by removing the chattiness of the protocol across the WAN through metadata caching, delayed closing of printer handles, asynchronous handling of print data, and so on- in addition to the transport level optimization that is fundamentally provides for TCP based protocols. In the second case, by deploying the WAAS as a print server, the spooled print traffic does not have to traverse the WAN network. See VXI Network chapter for more details on the deployment options for printing in a desktop virtualization environment, including the benefits that WAAS can bring to your deployment.
WAN Optimization
Another important consideration when sizing WAN links is whether to use WAN optimization. Cisco's WAAS is an application performance optimization solution designed to reduce bandwidth requirements, thereby enabling a larger number of users to be deployed across a given WAN link. It also reduces latency by locally caching the application traffic which serves to improve user experience. In VXI deployments, there are two key benefits in deploying WAAS as outlined below:
•
•
It is important to note the following caveats when using WAAS:
•
•
Estimating Network Bandwidth
Based on the discussion so far, it should be clear that there are number of variables at play with desktop virtualization that can impact the per-session bandwidth utilization and therefore network capacity planning for the overall branch deployment. Since the applications, workloads and use patterns can all vary the bandwidth requirements, the sizing of the WAN link is not a trivial effort, and any sizing estimations must be validated in the customer environment.
Due to the highly variable nature of desktop virtualization traffic, there are many factors that can impact the per-session bandwidth utilization and therefore network capacity for the overall branch deployment in an Enterprise. One approach to determining the bandwidth requirements for a WAN link is to characterize the bandwidth needs using a load generation tool and a generic workload profile (Task Worker, Knowledge Worker) that best matches your environment. See "Workload Considerations" section earlier in this chapter for more info on the generic profiles and the workload used for network characterization in the VXI system. However, any estimation based on generic workloads should be adjusted to account for any variability in your environment or one should calibrate the workload used for estimation using a workload that is more representative of your environment. If Cisco WAAS is used for WAN optimization, some testing in a pilot environment should be considered due to the variability of the traffic usage pattern in your environment that would be difficult to simulate using test tools.
To aid in the sizing process, validation was done in the VXI system to determine bandwidth sizing data with a detailed per-application analysis of the peak and average utilization used by the more common applications in a Knowledge Worker workload. These and other network characterization testing done in the VXI system are summarized in the table below and can be starting point for guiding the sizing of your WAN network for VXI deployment.
Network Characterization Results
Data to guide your WAN capacity planning based on testing done in the VXI system can be found in the Cisco VXI Performance and Capacity Validation Results Guide for VMware. A high level summary of the areas covered in the Cisco VXI Performance and Capacity Validation Results Guide for VMware are provided in the table below.
All of the testing was done from branch sites across an end-to-end Cisco VXI network built using the Cisco VXI system architecture outlined in earlier chapters of this document. As stated earlier, the data presented here is based on a Cisco VXI Knowledge Worker+ workload - however it provides valuable insight into the factors that an Enterprise will need to consider for WAN deployments with limited bandwidth. For a complete description of the Cisco VXI KW+ workload, please refer to the "Workload Considerations" section earlier in this chapter.
Table 44
Key Takeaways
In summary, some key takeaways based on the network characterization testing done in the VXI system are as follows:
•
•
•
•
Post Deployment Performance Monitoring
Capacity and performance analysis tools to monitor capacity on all components in the data center as well as application performance in desktop virtualization sessions are needed so that the administrator can increase capacity or make changes as needed based on use and activity patterns. Some tools that can be used specifically for capacity and performance monitoring are as follows:
•
–
–
–
–
–
•
•
Please refer to the "Management and Operations" chapter for a comprehensive look at the network management tools available for monitoring an end-to-end Cisco VXI system.
VXI Bill of Materials (BOM)
There are pre-configured VXI BOM packages available to assist in assembling an end-to-end VXI solution for 1000, 2000, 5000 and 10,000 user deployments. Please contact your sales representative for more information on these comprehensive BOM packages.
For More Information
The following links provide more detailed information regarding specific vendor information including hardware and software discussed in this chapter:
VMware View 5.0 Documentation
http://www.vmware.com/support/pubs/view_pubs.htmlPerformance Best Practices for VMware vSphere 5.0
http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.0.pdfVMware View 5 Performance and Best Practices - Technical White Paper
http://www.vmware.com/files/pdf/view/VMware-View-Performance-Study-Best-Practices-Technical-White-Paper.pdfConfiguration Maximums for vSphere 5.0
http://www.vmware.com/pdf/vsphere5/r50/vsphere-50-configuration-maximums.pdfwkvQTra_K-HeiAKb8siKDA&usg=AFQjCNEB6XvonDGGm4HQVMware KB article on HIMP(HaltingIdleMsecPenalty) Parameter
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1020233VMware KB Article on Transparent Page Sharing Memory vSphere 5.0 Resource Management
http://kb.vmware.com/kb/1021095Performance Study of VMware vStorage Thin Provisioning VMware KB: Using thin provisioned disks with virtual machines
http://www.vmware.com/pdf/vsp_4_thinprov_perf.pdfWorkload Considerations for Virtual Desktop Reference Architectures
http://www.vmware.com/go/view4rawc&ei=hFXQTr6QDKbjiAKk84ngCw&usg=AFQjCNEIFLVirtual Reality Check - Phase III and Phase IV
http://www.projectvrc.com/white-papers.htmlDesktop Virtualization with View 4.5 and EMC Storage
http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns743/ns993/landing_dcVirt-VM_EMC.htmlDesktop Virtualization with View 4.5 and NetApp Storage
http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns743/ns993/landing_dcVirt-VM_netapp.htmlVMware View on NetApp Deployment Guide
http://media.netapp.com/documents/tr-3770.pdfScalability Study for Deploying VMware View on Cisco UCS and EMC Symmetrix V-Max Systems
http://www.google.com/url?sa=t&rct=j&q=scalability%20study%20for%20deploying%20vmware%20view%20on%20cisco%20ucs%20and%20emc%20symmetrix%20v-max%20systems&source=web&cd=1&ved=0CCsQFjAA&url=http%3A%2F%2Fwww.cisco.com%2Fen%2FUS%2Fdocs%2Fsolutions%2FEnterpriseVMware View 5 Network Optimization with PCoIP
http://www.vmware.com/files/pdf/view/VMware-View-5-PCoIP-Network-Optimization-Guide.pdfNetwork Design for View
http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns743/ns993/landing_dcVirt-vm_view4.htmlResource Management
http://pubs.vmware.com/vsphere-50/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-50-resource-management-guide.pdfVMware KB: Using thin provisioned disks with virtual machines
http://kb.vmware.com/kb/1005418Acronyms
Table 45 defines the acronyms and abbreviations used in this publication.
Table 45 List of Acronyms
Additional References
The following links provide more detailed information regarding specific vendor information including hardware and software discussed in this document.
Desktop Virtualization Links:
VMware
VMware view 4.0 architecture planning guide
http://www.vmware.com/pdf/view401_architecture_planning.pdf
Introduction to VMware vSphere (ESX 4.1, ESXi 4.1)
http://www.vmware.com/support/pubs/vs_pages/vsp_pubs_esx41_vc41.html
VMware VDI implementation best practices
http://www.vmware.com/files/pdf/vdi_implementation_best_practices.pdf
Performance Best Practices for VMware vSphere® 4.0 (ESX 4.0 and ESXi 4.0)
http://www.vmware.com/pdf/Perf_Best_Practices_vSphere4.0.pdfData Center links:
Cisco Data Center Design Zone
http://www.cisco.com/en/US/netsol/ns743/networking_solutions_program_home.html
Best Practices in Deploying Cisco Nexus 1000V Series Switches on Cisco UCS B Series Blade Servers
http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/white_paper_c11-558242.html
EMC Solutions for VMware View
http://www.emc.com/solutions/application-environment/vmware/vmware-view-virtual-desktops.htm
Top 5 Reasons Why Customers Deploy VMware View on EMC Unified Storage
http://www.emc.com/collateral/software/15-min-guide/h8532-top5-deploy-vmware-view-uni-stor.pdf
Deploying Microsoft Windows 7 Virtual Desktops with VMware View - Applied Best Practices
http://www.emc.com/collateral/software/white-papers/h8043-windows-virtual-desktop-view-wp.pdf
Deploying Microsoft Windows XP Virtual Desktops with VMware View - Applied Best Practices
http://www.emc.com/collateral/software/white-papers/h7168-performance-optimization-windows-xp-vdi-wp.pdf
NetApp TR-3298: RAID-DP: NetApp Implementation of RAID Double Parity for Data Protection
http://media.netapp.com/documents/tr-3298.pdf
NetApp TR-3347: FlexClone Volumes: A Thorough Introduction
http://media.netapp.com/documents/tr-3347.pdf
NetApp TR-3437: Storage Best Practices and Resiliency Guide
http://media.netapp.com/documents/tr-3437.pdf
NetApp TR-3505: NetApp Deduplication for FAS, Deployment and Implementation Guide
http://media.netapp.com/documents/tr-3505.pdf
NetApp TR-3563: NetApp Thin Provisioning
http://media.netapp.com/documents/tr-3563.pdf
VMware VSphere Documentation Page
http://www.vmware.com/support/pubs/vs_pages/vsp_pubs_esxi40_i_vc40.htmlNetwork Links:
First link Vmware View 4.x
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012382#View4.x
Second Vmware View 4.x
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012382#View4x
Introduction to the Cisco WAAS Central Manager GUI
http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v421/configuration/guide/intro.html#wp1122501
Configuring Traffic Interception
http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v4013/configuration/guide/traffic.html
Configuring Application Acceleration
http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v4013/configuration/guide/policy.html
Configuring Application Acceleration
http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v4013/configuration/guide/policy.html
Configuring Network Settings
http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v4013/configuration/guide/network.html
Configuring and Managing WAAS Print Services
http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v4013/configuration/guide/printsvr.html
Data Center
http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DC_3_0/DC-3_0_IPInfra.html
Campus
http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/HA_campus_DG/hacampusdg.html
Branch/WAN -
http://www.ciscosystems.com/en/US/docs/solutions/Enterprise/Branch/srlgbrnt.pdf
Physical interfaces
Management access
Resource Management
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA1_7_/configuration/device_manager/guide/UG_confg.html#wp2700097
High availability
Configuring Virtual Contexts
One-armed mode configuration
Configuring Session Persistence
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA1_7_/configuration/device_manager/guide/UG_lb.html#wp1062118
Configuring Health Monitoring
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA1_7_/configuration/device_manager/guide/UG_lb.html#wp1045366
Balancing Algorithm
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA1_7_/configuration/device_manager/guide/UG_lb.html#wp1045366
Configuration of Source NAT
Cisco Enterprise Campus 3.0 Architecture
http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/campover.html
Endpoints and Applications Links:
Cisco Wide Area Application Services (WAAS) Configuration Guide
http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v421/configuration/guide/cnfgbook.pdf
Cisco Unified SRST Configuration Guide
Cisco Unified Communications 8.X SRND
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/uc8xsrnd.pdf
Cisco Unified Personal Communicator User's Guide
Management and Operations Links:
Cisco Deployment Guide for VMware View 4.0
http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/vmware/cisco_VMwareView.html
Cisco UCS GUI Configuration Guide
Cisco Unified Communications Manager Systems Guide
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_0_2/ccmsys/accm.pdf
VMware vSphere 4.2 documentation
http://www.vmware.com/support/pubs/vs_pages/vsp_pubs_esxi41_i_vc41.html
VMware vSphere Command-Line Interface Documentation
http://www.vmware.com/support/developer/vcli/
VMware APIs and SDKs Documentation
http://www.vmware.com/support/pubs/sdk_pubs.html
http://www.vmware.com/support/pubs/view_pubs.html
VMware View Installation Guide (release 4.5)
http://www.vmware.com/support/pubs/view_pubs.html
VMware View Administrators Guide (release 4.5)
http://www.vmware.com/support/pubs/view_pubs.html
VMware View Integration Guide (release 4.5)
http://www.vmware.com/support/pubs/view_pubs.html
VMware View Architecture Planning Guide (release 4.5)
http://www.vmware.com/support/pubs/view_pubs.html
http://www.vmware.com/pdf/vsphere4/r40/vsp_40_config_max.pdf
EMC Navisphere/Unisphere Management Suite
http://www.emc.com/products/detail/software/navisphere-management-suite.htm
http://www.netapp.com/us/products/management-software/provisioning.html
Altiris reference documentation
http://www.symantec.com/business/theme.jsp?themeid=altiris
Microsoft Active Directory and Network services
Cisco Network Analysis Module Deployment Guide
http://www.cisco.com/en/US/prod/collateral/modules/ps2706/white_paper_c07-505273.html#wp9000247
Cisco NAM Appliance Documentation (command reference and user guide )
http://www.cisco.com/en/US/partner/products/ps10113/tsd_products_support_series_home.html
Cisco Wide Area Application Services Configuration Guide (Software Version 4.1.1)
http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/v411/configuration/guide/cnfg.html
Cisco Adaptive Security Device Manager Configuration Guide
http://www.cisco.com/en/US/products/ps6121/tsd_products_support_configure.html
Cisco ACE 4700 Series Application Control Engine Appliances Documentation
http://www.cisco.com/en/US/products/ps7027/tsd_products_support_series_home.html
Cisco UCS Manager Configuration Guide
http://www.cisco.com/en/US/products/ps10281/products_installation_and_configuration_guides_list.html
http://www.cisco.com/en/US/products/ps9369/tsd_products_support_configure.html
Cisco Fabric manager documentation
http://www.cisco.com/en/US/partner/products/ps10495/tsd_products_support_configure.html
Cisco Nexus 1000v documentation
http://www.wyse.com/products/software/devicemanager/index.asp
WDM Admin Guide (release 4.7.2)
WDM Install Guide (release 4.7.2)
Wyse Device Manager Integration Add-ons Admin Guide
Wyse® Thin Clients, Based on Microsoft® Windows® XP Embedded, Admin Guide
Devon IT Echo™ Thin Client Management Software Version 3 Overview
http://www.devonit.com/software/echo/overview
Devon ThinManage 3.1 Admin Guide
http://downloads.devonit.com/Website/public/Documentation/thinmanage-3-1-adminguide-rev12.pdf
Devon IT TC5 Terminal Quick Start Guide
http://www.devonit.com/_wp/wp-content/uploads/2009/04/tc5-quickstartguide-devonit-english.pdf
IGEL Universal Management Suite 3 Overview
http://www.igel.com/igel/live.php,navigation_id,3294,_psmand,9.html
IGEL Universal Management Suite 3 Install Guide
IGEL Universal Management Suite 3 User Guide
http://www.download-igel.com/ftp/manuals/english/universalmanagement/IGEL%20UMS%20User%20Guide.pdf
IGEL Universal Desktops User Guide
http://www.download-igel.com/ftp/manuals/english/universalmanagement/IGEL%20UMS%20User%20Guide.pdf
Cisco VXI Security Links:
Cisco SAFE Architecture Guide
http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/SAFE_RG/SAFE_rg.pdf
Cisco Data Center 3.0 Security Guide
http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DC_3_0/dc_sec_design.pdf
Cisco Identity-Based Network Security Guide
http://www.cisco.com/en/US/solutions/collateral/ns340/ns394/ns171/CiscoIBNS-Technical-Review.pdf
Cisco 3650 Command Reference Guide
http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_35_se/command/reference/cli1.html#wp2757193
Cisco Business Ready Teleworker Design Guide
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a008074f24a.pdf
Cisco ASA 8.x : VPN Access with the AnyConnect VPN Client Configuration Example
http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00808efbd2.shtml
Microsoft - Disabling Remote Desktop Services Features
http://msdn.microsoft.com/en-us/library/aa380804%28VS.85%29.aspx
Quality of Service (QoS) Links:
Cisco Deployment Guide for VMware View 4.0
http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/vmware/cisco_VMwareView.html
Cisco UCS GUI Configuration Guide
Cisco Unified Communications Manager Systems Guide
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_0_2/ccmsys/accm.pdf
Performance and Capacity Links:
Reference Architecture-Based Design for Implementation of VMware vSphere, and NetApp Storage
VMware Reference Architecture for Cisco UCS and EMC CLARiiON with VMware View 4
http://www.vmware.com/go/vce-ra-brief
Workload Considerations for Virtual Desktop Reference Architectures Info Guide
http://www.vmware.com/files/pdf/VMware-WP-WorkloadConsiderations-WP-EN.pdf
VMware View on NetApp Deployment Guide
http://www.vmware.com/files/pdf/resources/VMware_View_on_NetApp_Unified_Storage.pdf
Performance Best Practices for VMware vSphere 4.0
http://www.vmware.com/pdf/Perf_Best_Practices_vSphere4.0.pdf
Virtual Reality Check - Phase II version 2.0
http://www.vmware.com/pdf/Perf_Best_Practices_vSphere4.0.pdf
Scalability Study for Deploying VMware View on Cisco UCS and EMC Symmetrix V-Max Systems
http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/App_Networking/vdiucswp.html
Configuration Maximums for vSphere 4.0
http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/App_Networking/vdiucswp.html
Configuration Maximums for vSphere 4.1
http://www.vmware.com/pdf/vsphere4/r41/vsp_41_config_max.pdfnfiguration Maximums for vSphere 4.1
VMware KB Article on Transparent Page Sharing
Performance Best Practices for VMware vSphere 4.0
http://www.vmware.com/pdf/Perf_Best_Practices_vSphere4.0.pdf
Performance Study of VMware vStorage Thin Provisioning
http://www.vmware.com/pdf/vsp_4_thinprov_perf.pdf
VMware KB: Using thin provisioned disks with virtual machines
http://kb.vmware.com/kb/1005418
Cisco Validated Design
About Cisco Validated Design (CVD) Program
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 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.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned 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. (1110R)
© 2012 Cisco Systems, Inc. All rights reserved
