IBM SmartCloud Desktop Infrastructure

IBM SmartCloud Desktop Infrastructure Reference architecture

21 October 2013

IBM Systems and Technology Group ISV Enablement Team

© Copyright IBM Corporation, 2013

https://twitter.com/IBMSystemsISVs�

IBM SmartCloud Desktop Infrastructure

Reference architecture

Table of contents

Introduction .................................................................................................................................1 Business problem and business value.....................................................................................1 Requirements ..............................................................................................................................2 Architectural overview................................................................................................................5 Component model.......................................................................................................................6

Management services.............................................................................................................................. 8 Support services ...................................................................................................................................... 9 Storage .................................................................................................................................................. 10 Image assignment models..................................................................................................................... 10 Networking model .................................................................................................................................. 12 User virtualization .................................................................................................................................. 13

Operational model.....................................................................................................................14 Servers................................................................................................................................................... 15 Local storage ......................................................................................................................................... 18 Shared storage ...................................................................................................................................... 19 10 GbE networking ................................................................................................................................ 22 1 GbE networking .................................................................................................................................. 25 Storage area network............................................................................................................................. 26

System performance considerations ......................................................................................27 Processor and memory for user desktops............................................................................................. 28 High availability for management VMs .................................................................................................. 29 Storage .................................................................................................................................................. 29 Networking ............................................................................................................................................. 30

Appendix A: Performance testing ...........................................................................................32 Performance testing methodology ......................................................................................................... 32 Performance test environment............................................................................................................... 33 Performance test tools ........................................................................................................................... 34

Resources..................................................................................................................................38 Trademarks and special notices..............................................................................................39

IBM SmartCloud Desktop Infrastr#cture


Introduction IBM® SmartCloud® Desktop Infrastructure (SDI) is IBM’s answer to end-user virtualization and integration needs. It offers robust virtual desktop solutions, infrastructure, and services designed to make the deployment of virtual desktops easier as is based on a reference architecture approach. As such, IBM SDI supports a wide range of hardware, hypervisors and software platforms from multiple vendors, providing a high degree of flexibility and customization choices. IBM SDI helps offer a more cost-effective, manageable, virtual desktop environment for a wide range of customer sizes, user types and industry segments.

The intended audience for this document is technical IT architects, system administrators, and managers interested in deploying a virtual desktop infrastructure (VDI) solution.

This document describes the business problem solved by SDI, elaborates on the business benefits of using a VDI solution based on SDI, and discusses the details of the logical architecture of SDI .The actual mapping of the SDI logical architecture to the VDI-specific solution implementations is described in the corresponding reference architecture documents for those solutions.

Concerns about endpoint management, desktop backup, multisite deployments, and data replication are outside the scope of this document.

Business problem and business value Today’s IT staff are faced with ever-rising costs, increased complexity of maintaining remote end-user workstations, growing needs to avoid security exposures such as virus attacks, the lack of centralized management, and the need for flexibility and global availability of compute resources.

The IBM SDI uses a VDI approach to solve these business problems. VDI is an enterprise architecture that stores user data, user profiles, and application data files on centralized servers. These servers are located in data centers, and therefore, this approach extends the data center security and manageability down to the end-user resources. Additionally, VDI provides users with anywhere, anytime, secure access to data and applications from any device. This includes popular mobile devices such as tablets and cell phones.

In essence, VDI consists of server hosted virtual machines (VMs) running desktop operating systems in the central data center location, delivering a graphical representation (screen updates) to remotely connected users, and allowing local user input (keyboard/mouse/touch) to their virtual desktops. Whereas, in a traditional desktop model, a user has the entire compute environment (OS, processing power, memory, hard disk) placed in front of the user. In case of VDI, the user uses a lightweight endpoint device with minimal need for processing power and little or no storage to access the user’s desktop that is processed on remote hardware.

The advantages of a VDI approach to enterprise desktop management compared to traditional desktop environments can include:

Rapid desktop deployment, including updates, patches, security enhancements

Overall cost savings in desktop support, a centralized approach to client OS management, and reduced client machine energy consumption

Unified management and reporting through a single administrator console

Easy accessibility through a variety of endpoint devices (notebooks, tablets, thin clients), both locally and remotely

1



User and application virtualization that disaggregates resources for balanced network workloads while maintaining a consistent look and feel for the user

Ability to leverage centralized data center resources and processes for backup and recovery

Horizontal scalability — up to tens of thousands of endpoint devices can be handled through a central point

Improved data security through centralization of sensitive data behind data center firewalls and security protection

Compliance with regulatory norms for information protection [such as HIPAA and Sarbanes-Oxley (SOX) security standards]

Requirements Figure 1 is a simplified use case model that shows the major actors and operations in the SDI solution.

Figure 1: Use case model for SDI

The following list provides the functional and nonfunctional requirements needed for typical VDI deployments.

User experience

Connects from any mainstream client OS, such as Microsoft® Windows®, Linux® and Mac OS

Connects from any mainstream thin or zero clients, such as mobile devices and VDI zero clients

Allows customer applications to run properly on the virtual system

2



Includes a universal printer driver

Dynamically adjusts for changes in endpoint printer/scanner configuration

Dynamically adjusts for changes in endpoint monitor configuration including multiple monitors

Masks the impact of network latency on user-initiated actions

Supports common Universal Serial Bus (USB) devices

Supports playback of multimedia content

Provides audio and video resource utilization tuning and control

Supports boot and reboot storms

Includes on-demand Windows endpoint client software, (that is, clicking a link starts an application)

Provides self-service virtual workplace and application provisioning

Provides self-service user image and file recovery / rollback

Service advertising and connection brokerage

Broker cluster scales to 10,000 virtual desktops and allows for multiples thereof

Provides a web-based connection interface

Supports industry standard remote display protocols

Enables session reconnection from both current or new endpoints

Maintains user experience across multiple delivery models

Integrates with application and profile virtualization

Networking and connectivity

Integrates with enterprise application delivery controllers that provide high-speed load balancing and content switching for VDI sessions

Integrates with virtual private network (VPN) appliances or access gateway, or both

Provides network separation using mechanisms such as virtual LANs (VLANs)

Provides centralized management of networking parameters for thin clients

Offers traceability mapping between virtual workplace/user and external IP

Supports low-bandwidth / high-latency wide area network (WAN) connections

Supports WAN acceleration devices, which reduce WAN bandwidth and latency requirements

Storage and provisioning

Integrates with storage provisioning features for the server virtualization platform

Supports thin provisioning

Manages disconnected virtual desktop synchronization

3



Management and performance tooling

Requires that customer applications deployment or publishing must be done accordingly with user groups

Must have built-in fully automated customization for applications or offer tools to achieve this customization

Supports multiple concurrent administrators or connections

Offers policy-based management

Includes user, virtual desktop, and client endpoint search capabilities

Provides flexible management of virtual desktop OS and application updates

Includes command-line interface (CLI) and scripting support

Comes with real-time and historical data management

Monitors application for traffic analysis

Offers planning and migration tools

Allows for virtual desktop provisioning

Provides a management console

Enables virtual desktop pooling and resource prioritization

Suspends or shuts down idle virtual desktops instances or sessions

Security

Offers directory service integration

Provides role-based access controls

Ensures that client and management traffic is secured

Allows for security logging and auditing of administrative actions

Supports standard remote-access authentication protocols

Takes vendor-provided hardening guidelines into account

Offers configuration file and virtual desktop image integrity checking

Comes with multi-factor authentication for users, client endpoints, and management server

Provides antivirus and antispyware software integration

Allows for USB device access restrictions

Offers granular desktop access control

Patches deployment

Business continuity

Provides no single points of failure

Provides failure detection, isolation, and recovery

4



Allows for live migration of virtual workplace instance/sessions

Offers client connection failure notification and automatic reconnection

Provides session failure notification and automatic restart

Allows for resource prioritization

The following sections of the document describe the reference architecture that meets all these business needs, and their functional and nonfunctional requirements.

Architectural overview Figure 2 provides an architectural overview of the SDI solution, which consists of:

Choice of VDI middleware: Representing the main four software VDI solutions, that is, VMware View, Citrix XenDesktop and VDI in a box, and Microsoft® Windows® Server 2012

Server building blocks: Includes IBM Flex System™ and IBM System x® servers

Storage: Includes IBM Storwize® V7000, IBM Flex System V7000 Storage Node, IBM Storwize V3700, and IBM System Storage® N series storage.

ESXi, Hyper-V, XenServer

Multi-Vendor VDI Support

Large Scale Virtual Desktops

Multi-Hypervisor Support

IBM Rack and Flex System Building

BlocksLocal SSDs

IBM Shared Storage

XenDesktop and VDI in a Box

VMware View 5 Windows Server 2012

IBM N SeriesIBM Storwize V7000 and Flex System V7000 Storage Node

IBM StorwizeV3700

Figure 2: Architectural overview of SDI

5



Component model IBM SDI offers flexibility through choice of solution elements. There are however standard components, such as connection brokers, provisioning servers, and administrator consoles that make up and define the IBM SDI architecture. This section describes all these required components.

Different organizations have different guidelines on the amount of personalization permitted on end-user desktops. Some allow end users to customize to the extent that users are permitted to install applications, others allow minor changes such as screensavers, desktop wall papers, and many do not allow any changes to the standard image at all.

This set of policies can be applied to a VDI environment in a similar manner. Users can be allowed to have their own dedicated virtual desktops or be required to use a standard desktop image, only being able to make minor modifications or even no modifications at all. Eliminating modifications to a virtual desktop environment allows images to be shareable across multiple users, thus allowing a virtual desktop image to be stateless.

The IBM SDI architecture allows for both dedicated and stateless desktop images. A key design decision however is to favor stateless desktop images whenever possible, as this reduces the shared storage requirements by utilizing local solid-state drive (SSD) storage instead of large-scale shared storage arrays for the performance-intense I/O operations that occur in most VDI environments, and can thus greatly improve on performance as well.

Figure 3 on page 7 shows a layered component model for the IBM SDI solution. Conceptually, there are four logical layers; end-user clients, VDI middleware including management services, hypervisors running VMs containing desktops, and shared storage.

The main components depicted in Figure 3 are explained in the following table.

VDI administrator GUIs The VDI middleware infrastructure is configured, managed, and monitored using administrator graphical user interfaces (GUIs), which can be browser’s interfaces or thick-client applications. The administrator GUIs usually interact with one or more of the management services.

Management services The VDI middleware consists of several different management services for provisioning of desktops, connection to desktops, management of desktops, and licensing. Data about the VDI infrastructure is usually held in one or more management databases in shared storage. Refer to page 8 for more details on “Management services”.

Client devices Users can access their virtual desktop, published desktop, or published application from any device supported by the respective desktop virtualization solution; this includes company notebooks, home PC, thin-client devices, or tablets. IBM does not prescribe any particular approach for clients. Customers can repurpose existing desktops (which is typical for many deployments) or green-field with thin- or zero-client devices.

Hypervisor The hypervisor for each server is responsible for running multiple VMs and sharing the resources of that server (processor, memory, and local storage) between the VMs.

6



Support ServicesSmartCloud Desktop Infrastructure

Management Services

Web Server

VM Manager

Provisioning Services

Connection Broker

VM Manager DB Server

Directory

OS Licensing

DHCP

DNS

Client Devices

ClientAgent

ClientAgent

ClientAgent

ClientAgent

Shared Storage

VMRepository

VMDeltas

UserData Files

UserProfiles

Storage Protocols

Ma

na

ge

me

nt P

roto

cols

Other Services

VDIAdministrator

GUIs

Web Protocols Display Protocols

ManagementDatabases

AdministratorGUIs for Support Services

License Server

Su

pp

ort

Se

rvic

e P

roto

cols

Hypervisor

VMAgent

Hypervisor

Dedicated Virtual

Desktops

Stateless Virtual

Desktops

Local SSDStorage

VMAgent

VMAgent

VMAgent

Hypervisor

Published Desktops and Apps

PublishedDesktop

PublishedDesktop

PublishedApplication

Figure 3: Component model for SDI

Dedicated virtual desktops

These desktops hold user configuration information that is dedicated to each individual user. Refer to the “Management services” section on page 8.

Stateless virtual desktops

These desktops share a standard image across multiple users. Refer to the “Management services” section on page 8. Stateless desktops require local storage to keep any modified state that is discarded when the desktop is ended for the current user.

Published desktops and applications

Published desktops are shared desktops where each user is sharing a VM. A published application provides access to a single application without first needing to go to a desktop.

Shared storage Shared storage is used to hold all of the data that can be shared across servers including the VM images themselves, deltas (changes) to dedicated VM images, user profile information, user data files, and VDI management databases. Refer to page 10 for more details on the types of data in shared storage.

7



Support Services Support services are outside the definition of SDI. Generally, these are services that already exist in the organization and are reused for VDI. See page 10 for more details on support services.

Administrator GUIs for support services

The support services usually have administrator GUIs to configure, manage, and monitor these services. Further discussion of these GUIs is outside the scope of the SDI.

Web protocols Web protocols such as Hypertext Transfer Protocol (HTTP) and Hypertext Transfer Protocol Secure (HTTPS) are used between the VDI administrator GUIs or client devices and the management services.

Display protocols The virtual desktop image is streamed to the client device using a display protocol. Depending on the solution the choice of protocols available are Remote Desktop Protocol (RDP), PC-over-IP (PCoIP), Independent Computing Architecture (ICA) and Simple Protocol for Independent Computing Environments (SPICE). The agent in the desktop takes display information and sends it to the agent in the client device. The agent in the client device displays the information appropriately and also captures keyboard and gesture input, which is then transmitted back to the agent in the desktop.

Management protocols The protocols used between the management services, and hypervisor or desktop agents are usually vendor specific and might not have a public specification.

Storage protocols Data can be read or written to shared storage using many different protocols. File I/O is typically done with Common Internet File System (CIFS) or Network File System (NFS) into a network-attached storage (NAS). Other types of data such as databases and VM images are accessed using block I/O using Fibre Channel into a storage area network (SAN).

Support service protocols

The protocols for desktops to access support services are different and might not have a public specification.

Management services Management services are provided by the VDI vendor solution for creating desktops, provisioning of desktops, connection to desktops, maintenance and management of desktops, and licensing. In many cases, these management services can be installed as desktops themselves and thus do not need separate stand-alone servers. In some cases, such as large-scale deployments, the use of bare-metal management servers is required. Other scenarios include situations where a management service needs to manipulate specifics on the underlying server.

The management services that can be provided by a VDI vendor are explained in the following table.

Web server The web server is often the first point of contact for a client that wants to access a desktop or virtual application. The user provides the credentials, which are verified in the directory, and then the user might be presented with one or more types of virtual desktops that the user can connect to. The web server needs to be highly available.

8



Connection broker User requests for virtual desktops are sent from the web server to the connection broker. After a user is authenticated, it directs the client to its assigned virtual desktop running in a VM. If a desktop is not available, the connection broker works with the provisioning services to have the desktop ready and available. The connection broker plays no further role after the agent in the desktop and the agent in the client are communicating with each other. The connection broker needs to be highly available.

Provisioning services Provisioning services is responsible for creating VM for virtual desktops or virtualized applications. This can be done on demand from the connection broker or ahead of time so that a pool is ready and waiting for users to connect to. Provisioning services uses VM repository and VM deltas in shared storage to create the appropriate VM. Provisioning services need to be highly available and might require many instances as this service type has the heaviest workload especially at the start of a day when every user wants to get started with a virtual desktop.

VM manager The VM manager is responsible for managing the state of a VM after it is created by provisioning services. Desktops can be returned to an idle state or deleted after a user disconnects from the desktop. The VM manager needs to be highly available.

VM Manager DB server

The VM manager database server is responsible for storing and retrieving the metadata about desktops and their state. The VM manager database server needs to be highly available.

License server The License server is used to verify licensing of the VDI infrastructure including management services. Often, a grace period is allowed so that this service does not need to be highly available.

Other services The VDI infrastructure from vendors might include other services that often provide a differentiated function such as event or performance monitoring.

For manageability, virtual desktops are usually divided into pools. There are several reasons for desktop pools including:

Each unique desktop image has to have its own pool.

Desktops can be used with different sets of applications for different user groups. For example, accounting, engineering, and sales, can be divided into separate pools.

Stateless and dedicated desktops need to be in separate pools.

Management services limit the number of desktops they control within one instance. Therefore, multiple pools with the same VM image might be needed.

Support services Generally, support services already exist in the organization and are reused for VDI. In some cases, these support services are VMs themselves that can be run under a hypervisor and do not need separate stand-alone servers. For large-scale deployments, IBM recommends that these services are run bare-metal on multiple physical servers that are redundant using the high-availability functionality built into the services.

9



Directory The most-often used directory service is Microsoft Active Directory Server which provides authentication for both virtual desktop machine accounts and user access to the virtual desktops. Microsoft Active Directory has built in high availability features such as multi-master replication. Other directory servers and protocols can be leveraged as well, such as Samba or standards-compliant Lightweight Directory Access Protocol (LDAP) clients for higher integration into UNIX®-like server environments.

DNS Domain name server (DNS) services are required to resolve fully qualified domain names (FQDNs). DNS servers need to have high availability.

DHCP When a new virtual desktop is started, it requests an address from Dynamic Host Configuration Protocol (DHCP). The DHCP system used within the organization must be designed for high availability. The most common methods for redundant DHCP are to use split scopes or to cluster DHCP servers.

OS licensing The Windows operating system in the virtual desktop or management services needs to be licensed using Microsoft Volume Licensing.

Storage Storage is required for persistent or nonpersistent access of all the databases, VM images, user files, and other data needed for a VDI deployment. This storage can be either shared and accessed using Ethernet or fiber networking or can be cached in some way in locally attached storage. The types of data and methods used to store it vary by VDI vendor solution and can include:

Management databases

Management databases hold information related to either the configuration of the VDI infrastructure or some kind of logging of activities in the VDI infrastructure.

VM repository The VM repository contains master virtual desktop images. A history to changes to the images can also be kept. Backups of these images should also be stored separately.

VM deltas Changes to virtual desktop images made by users need to be kept. Because keeping a separate copy of every user’s image is wasteful, most VDI infrastructures have a way to only store the changes (or deltas).

User profiles Using Microsoft Roaming Profile (MSRP) allows users anywhere on the network to access their profile information. However MSRP has several functional and performance disadvantages. Some VDI implementations attempt to eliminate these problems with their own custom profile solution. Refer to the “User virtualization” section on page 13 for more details.

User data files User data files are usually made available using a shared drive letter. Note that the hidden AppData folder, which contains files and settings for individual applications, is sometimes stored separately with the VM image.

Image assignment models When designing virtual desktop solutions, it is important to understand the relationship between the user and the virtual desktop image, the image assignment model. When using a physical desktop computer (desktop PC or a notebook), there is a one-to-one relationship between a user and the physical computer. As a natural evolution, most VDI deployments initially used the same approach for the VDI device

10



management. With this design, users have a dedicated (persistent) virtual desktop instance and logs into the same virtual desktop image every time they connect. The dedicated desktop model is best for users who need the ability to install additional applications, store data locally, and retain the ability to work offline.

Although this aligns most closely to the way people have approached desktops for a long time, it also prevents them from fully taking advantage of some of the most important aspects and opportunities of desktop virtualization, such as:

Administration aspects

Data management aspects

Cost aspects (predominantly requirement of external storage)

From an administrator’s point of view, dedicated desktops have many drawbacks. The desktop images are all unique, and are typically large in size, grow quickly in size, and need to be updated and patched individually as they have no common base image. There is often no separation between the operating system and user data. Additionally, data backup is critical (as the image is unique to each user) and typically entails the backup of large data sets. More importantly, high availability needs to be considered as the user needs to be able to connect to the exact same image even if a VDI host fails, which is impossible if hosted locally. Therefore, dedicated desktops require access to expensive shared storage.

Stateless (also referred to as pooled, floating, or nonpersistent) desktops are allocated to users temporarily. After the user has logged off, changes to the image are usually discarded (reset) and the desktop becomes available for the next user or a new desktop is created for the next user session. A persistent user experience (that is, the ability to personalize the desktop and save data) is achieved through user profile management, folder redirection, difference data collection, and similar approaches. Additionally, specific individual applications can be provided to stateless desktops using application virtualization technologies.

A stateless approach is based on a logical separation of operating system, application, and user layers that unlock the full benefits of desktop virtualization, if architected properly. It means that a common base image can be used for all users in the same pool. This image can also be updated centrally. If the image is corrupt or becomes unavailable, the user simply connects to another image in the pool, thus using the high-availability features of connection brokers, rather than providing high availability through a storage-hungry VM failover approach. Backup is simplified as only a small subset of the overall data (profile information and saved data) needs to be archived.

As a result of these attributes, the stateless approach inherently enables the use of local storage instead of shared storage (with only a fraction of the data residing on distributed storage, for example, profile and user data), which helps to directly reduce the cost per desktop. The only potential restriction to storing this state locally is that a desktop cannot be moved from one server to another (motion) without restarting the VM – live migration. Motion is often used to maintain a live server by moving all of the desktops to another server. If the maintenance is not needed immediately, the server can be put into maintenance mode so that no new desktops are placed on the server. When the last desktop is closed, then the server can be taken offline and have maintenance applied. If this live migration of servers is absolutely required, then a stateless desktop can be still used but all of data is on shared storage with a corresponding increase in the performance requirements of shared storage.

For dedicated virtual desktops, it is also a good practice to separate out user profile and user data files from the VM images and VM deltas/differences. This separation makes it easier to refresh the VM images and reset the VM deltas when they get too large. Also, because both dedicated and stateless virtual

11



desktops access user profiles and user data files in the same way, it is easier to migrate from dedicated to stateless desktops.

This distinction between dedicated and stateless desktops and the use of local storage instead of shared storage is one of the key differentiators for the IBM SDI. The stateless approach addresses a common practical inhibitor to VDI, which is shared storage cost, and reduces networking requirements, and also improves overall end-user performance and manageability. Table 1 gives a comparison of the approaches:

Approach Local storage Live migration Shared storage Stateless High IOPS (using SSD) Not supported Low IOPS Stateless with motion Not Used Supported High IOPS Dedicated Not Used Supported High IOPS

Table 1: Comparison of stateless and dedicated desktops

Both the dedicated and stateless approaches are supported by the IBM SDI and both can be used in the same environment. The exact mix of dedicated to stateless desktops depends on end-user requirements and customer policies.

Networking model

The SDI networking model is shown in Figure 4.

Support ServicesSmartCloud Desktop Infrastructure – Networking

Management Services

Web Server

VM Manager

Provisioning Services

Connection Broker

VM Manager DB Server

Directory

OS Licensing

DHCP

DNS

Client Devices

ClientAgent

ClientAgent

ClientAgent

ClientAgent

Shared Storage

VMRepository

VMDeltas

UserData Files

UserProfiles

Storage VLAN

Ma

na

ge

me

nt V

LA

N

Other Services

VDIAdministrator

GUIs

ManagementDatabases

AdministratorGUIs for Support Services

License Server

US

er

VL

AN

User VLAN

SAN

Hypervisor

VMAgent

Hypervisor

Dedicated Virtual

Desktops

Stateless Virtual

Desktops

Local SSDStorage

VMAgent

VMAgent

VMAgent

Hypervisor

Published Desktops and Apps

PublishedDesktop

PublishedDesktop

PublishedApplication

Figure 4: Network model for SDI

12



The IBM SDI includes many different kinds of networking protocols. For simplification, the SDI network is divided into three VLANs:

User VLAN (for web protocols, display protocols, and support service protocols)

Management VLAN (for management protocols)

Storage VLAN (for storage protocols)

A 10-Gbit network infrastructure is used to provide the required bandwidth and performance for these three VLANs. The storage VLAN requires the maximum bandwidth. As an alternative, shared storage can be attached using 8 Gbps or 16 Gbps Fibre Channel SAN or using Fibre Channel over Ethernet (FCoE). A 1 Gigabit Ethernet (GbE) network can also be used for certain VDI solutions aimed at a small number of users (fewer than 600).

Not shown in Figure 4 is a separate IT administration network that is used for systems management of nodes (power-up, reboot), optional Preboot Execution Environment (PXE) boot of hypervisors, and shared storage management. A separate 1 GbE network is used for the IT administration network.

User virtualization User virtualization means independent management of all aspects of the user’s desktop environment by decoupling a user’s profile, settings, and data from the operating system and storing that data centrally. In fact, user virtualization can be performed with standard physical desktops as a first step towards VDI.

Within a VDI environment, IBM recommends to always perform user virtualization even if users have dedicated desktops. This separation of user-specific data makes it much easier to manage and perform upgrades to the VDI environment.

User folders

User folder redirection to a shared directory is very easy to perform using Microsoft Active Directory services and is well documented. The most common folder that is redirected is the user’s home directory.

User profiles

User profile data for the purposes of this discussion is everything user specific not including the user’s home directory. There are different kinds of user profiles as explained in the following table:

None Each user’s desktop contains the profile, which makes things hard to manage and hard to recover from if an error occurs. This is not recommended.

Mandatory Mandatory profiles are used in locked-down environments where users are not allowed to perform tasks, such as changing the font, setting a personalized background, and so on. Everyone gets the same, un-personalized desktop. This is a not a common scenario as most users demand some level of customization to their desktops.

Roaming Roaming profiles allow users to personalize the desktop experience. When a user moves from one desktop to another, the profile moves with that user.

Terminal services Terminal services profiles are used in conjunction with application virtualization. It allows users to save their application specific customization between logins so it does not need to be redone every time they log in to a virtualization application.

13



Hybrid Combines the Mandatory and Roaming profiles, which can speed up the user login process.

There are several potential problems with profiles that need careful planning and a software solution that eliminates or reduces the impact of these problems. The three main problems are profile corruption, last write wins, and slow logins.

1. Corruption Over a period of time, profiles can get corrupt. It might have been a result of the last write wins scenario, a driver installation that malfunctioned, or possibly a bad sector on the disk. If the profile cannot be repaired, then perhaps it can be restored from a backup. If this does not resolve the problem, then the profile has to be deleted and the user has to start over, which usually results in an unhappy user.

2. Last write wins In many environments, a user might have a roaming profile and multiple terminal service profiles for each virtualized application that they use. If the user logs in to several applications and virtual desktops at the same time, then it is possible that the profile changes saved with a virtual desktop will overwrite the profile changes for a virtualized application. To a user, it looks like the virtual application changes were not saved.

3. Slow logins There are several factors that can affect the login time including: the size of the profile itself, the network latency of accessing the profile from a different location, not using folder redirection, and possibly disk fragmentation. Slow logins can also result from the number and type of Active Directory policies each of which is applied in a serial fashion. By implementing a VDI-specific resource domain, only those Active Directory policies required for VDI are moved to the resource domain and applied at login time.

The standard solution for profiles is to use MSRP. However, MSRP does not scale very well. In small environments with less than 600 users, MSRP can be just fine. MSRP should be used with folder redirection to reduce what is stored in the profile itself — the smaller the profile the better the performance. Left unchecked, profiles can grow very large and substantially increase user login type. MSRP can also have problems with data corruption and errors from last-write-wins scenarios.

Because of the problems with MSRP, a number of third-party user environment management (UEM) products have been created including some from VDI vendors. Ruben Spruijt has produced a well-written comparison of different UEM products called “UEM Smackdown”. Refer to goo.gl/uYZRr for more information and instructions on how to download the full white paper. IBM recommends evaluating an UEM solution for larger deployments.

Operational model The operational model for SDI depends upon the VDI middleware that is used. Because there are multiple options and each is fairly complex in nature, there are separate reference architecture documents for each major VDI middleware implementation. Refer to the “Resources” section on page 38 for vendor-specific reference architecture documents.

Instead of describing a particular operational model, this section is used to describe the IBM hardware you can use for implementing SDI.

14



Servers You can use various IBM server platforms to implement SDI including a modular blade-based system or traditional rack-based servers.

IBM PureFlex System and IBM Flex System elements

IBM PureFlex™ System is an IBM enterprise-class platform specifically created to meet the demands of a virtualized data center, and help clients establish a highly secure private cloud environment. For clients who want to custom-tune their systems, IBM Flex System provides the elements of a PureFlex System, which can be configured and tuned similar to blade products. The features of PureFlex System and Flex System are:

Greatest choice for clients in processor type (x86 and IBM POWER® processors), and OS platform, all in the same chassis, managed from a single point of control.

The IBM Flex System Manager™ (FSM) is the management console for systems that works with the management tools from companies like IBM Tivoli®, CA Technologies, or BMC to deliver new management functionality across all resources.

The Flex System networking delivers 50% latency improvement through node-to-node (east-west) traffic rather than routing everything through the top-of-rack (TOR) switch (north-south).

Figure 5: IBM Flex System Enterprise Chassis, and IBM Flex System compute nodes

For more information, visit the IBM PureFlex System and IBM Flex System website at: ibm.com/systems/pureflex/overview.html

IBM Flex System x240 Compute Node

The IBM Flex System x240 Compute Node (refer to Figure 6) is a high-performance Intel® Xeon® processor-based server that offers outstanding performance for virtualization with new levels of processor performance and memory capacity, and flexible configuration options for a broad range of workloads. The Flex System x240 Compute Node is ideal for virtualization, with maximum memory support (24 DIMMs and up to 768 GB of memory capacity) and 10 GbE Integrated Virtual Fabric for high networking bandwidth. The Flex System x240 Compute Node also supports Flex System Flash for up to eight 1.8-inch SSDs for maximum local storage.

15



Figure 6: IBM Flex System x240 Compute Node

IBM Flex System x222 Compute Node

The IBM Flex System x222 Compute Node (refer to Figure 7) is a high-density blade server designed for virtualization, dense cloud deployments, and hosted clients. The Flex System x222 Compute Node has two independent compute nodes in the one mechanical package, which means that Flex System x222 has a double-density design allowing up to 28 servers to be housed in a single 10U Flex System Enterprise Chassis. The Flex System x222 Compute Node supports up to 768 GB of memory capacity and 10 GbE Integrated Virtual Fabric for high networking bandwidth. The Flex System x222 Compute Node also supports Flex System Flash for up to four 1.8-inch SSDs for maximum local storage.

Figure 7: IBM Flex System x222 Compute Node

IBM Flex System Manager

The IBM Flex System Manager (refer to Figure 8) is a high-performance scalable systems management appliance with a preloaded software stack. As an appliance, the hardware is closed, on a dedicated compute node platform, and designed to configure, monitor, and manage IBM Flex System resources in multi-node IBM Flex System servers. An increased focus on optimizing time-to-value is evident in these features:

Setup wizards, including initial setup wizards, provide intuitive and quick setup of Flex System Manager.

The chassis map provides multiple view overlays to track health, firmware inventory, and environmental metrics.

Configuration management for repeatable setup of compute, network, and storage devices.

Remote presence application for remote access to compute nodes with single sign-on (SSO).

16



Quick search provides results as you type.

Beyond the physical world of inventory, configuration, and monitoring, IBM Flex System Manager enables virtualization and workload optimization for a new class of computing.

Resource utilization detects congestion, notification policies, and relocation of physical and virtual machines that include storage and network configurations within the network fabric.

Resource pooling allows for pooled network switching, with placement advisors that consider VM compatibility, processor, availability, and energy.

Intelligent automation offers automated and dynamic VM placement based on utilization, energy, hardware predictive failure alerts, and host failures.

Figure 8: IBM Flex System Manager

IBM System x3550 M4

The powerful IBM System x3550 M4 rack server (refer to Figure 9) blends outstanding uptime, performance and I/O flexibility, delivering cost efficiency and rock-solid reliability all in a 1U footprint.

Innovative design, optimized for cost and performance, supports business-critical applications and cloud deployments.

Excellent reliability, availability, and serviceability (RAS) and outstanding uptime for an improved business environment.

Easy to deploy, integrate, service, and manage.

With redundant hot-swap fans, disks, and power supplies, the System x3550 M4 server provides a resilient architecture ideal for business-critical applications. Predictive failure analysis and light path diagnostics provide advanced warning on power supplies, fans, voltage regulator modules (VRMs), disks, processors, and memory. Redundant hot-swap components make it easy to replace failures without taking your system down.

With more computing power per watt, support for the latest Intel Xeon processor E5-2600 series and advanced memory support, System x3550 M4 offers balanced performance and density ideal for compute-intensive, general-business applications and virtualized environments. The IBM System x3550 M4 server is scalable with a storage capacity of up to eight 2.5 in. hot-swappable serial-attached SCSI (SAS) / Serial Advanced Technology Attachment (SATA) hard disks or SSDs.

For more information, visit the IBM System x3550 M4 website at: ibm.com/systems/x/hardware/rack/x3550m4.

17

http://www-03.ibm.com/systems/x/hardware/rack/x3550m4



Figure 9: IBM System x3550 M4

IBM System x3650 M4

Similar to System x3550 M4, the System x3650 M4 rack server (refer to Figure 10) blends outstanding uptime, performance, and I/O flexibility delivering cost efficiency and rock-solid reliability but in a 2U footprint. The key differences are more expansion slots and additional eight 2.5 in. hot-swappable SAS/SATA hard disks or SSDs for a total of 16.

For more information, visit the IBM System x3650 M4 website at ibm.com/systems/x/hardware/rack/x3650m4.

Figure 10: IBM System x3650 M4

Local storage Local storage can be either solid state or spinning drives. The tradeoff is between speed and performance. Larger capacity SSDs are now available in sizes similar to spinning drives but with much better performance and also have similar 3- to 5-year lifetimes.

SATA 1.8 in. SSDs

These drives are limited to 200 GB. The drive endurance is up to 2,793 TB total bytes written (TBW), which is more than 2.5 TB TBW per day in a 3-year cycle and more than 1.5 TB TBW per day in a 5-year cycle. They require a Redundant Array of Independent Disks (RAID) controller for both System x servers and IBM Flex System compute nodes. Up to four of these drives can be used in an IBM Flex System x240 Compute Node for a maximum capacity of 800 GB at RAID 0.

Figure 11: IBM SATA 1.8 in. SSDs

For more information, refer to ibm.com/redbooks/abstracts/tips0792.html.

SAS 2.5 in. SSDs

These drives can be 200 GB, 400 GB or 800 GB in size. The drive endurance for a 5-year cycle is up to 3.65 TBW for the 200 GB drives, 7.3 PB for 400 GB drives, and 14.6 PB for 800 GB drives. They require a

18

http://www-03.ibm.com/systems/x/hardware/rack/x3650m4



RAID controller for System x servers and can use the built-in RAID controller in IBM Flex System nodes. Up to two of these drives can be used in an IBM Flex System x240 Compute Node for a maximum capacity of 1600 GB at RAID 0.


Spinning drives

If spinning drives are needed, then in general 2.5 in. SAS drives are preferred to 3.5 in. because they provide greater density and are the only ones that can be used in IBM Flex System nodes. The trade off is that currently the largest capacity for 15k rpm is 300 GB. Depending on the VDI solution, it might be possible to use 10k rpm drives that have a capacity up to 900 GB.

Shared storage IBM has a range of both NAS and SAN storage solutions that can be used as shared storage for VDI. NAS storage uses Network File System (NFS) or Common Internet File System (CIFS) file protocols over 1 or 10 GbE networks. Block-oriented storage uses an 8 or 16 Gbps Fibre Channel SAN or iSCSI / FCoE over a 10 GbE network.

IBM Storwize V7000

The IBM Storwize® V7000 virtualized storage system is designed to consolidate workloads into a single storage system for simplicity of management, reduced cost, highly scalable capacity, performance, and high availability. It offers improved efficiency and flexibility through built-in flash storage optimization, thin provisioning and non-disruptive migration from existing storage. The benefits of the IBM Storwize V7000 storage include:

Support for RAID 0, 1, 5, 6 and 10 disk arrays

Flash storage for applications that demand high speed and quick access to data

Scale up to 240 2.5-inch disk drives per Storwize V7000 system using nine expansion units (20U)

Clustering of up to four Storwize V7000 systems together for a total of up to 960 drives (80U)

A potential three times performance improvement by moving as little as five percent of data to flash storage using the IBM System Storage® Easy Tier® feature.

Storing up to five times more active primary data in the same physical disk space using IBM Real-time Compression™ technology

Near-continuous availability of applications through dynamic migration

Easy-to-use data management designed with a graphical user interface and point-and-click system management capabilities

Metro Mirror and Global Mirror for replicating data synchronously or asynchronously between systems for backup efficiency

Host attachment through SAN-attached 8 Gbps Fibre Channel, 1 Gbps iSCSI and optional 10 Gbps iSCSI / FCoE

19

http://www.redbooks.ibm.com/abstracts/tips0792.html



Figure 12: IBM Storwize V7000 (2.5 in. drive model with 24 drives)

For more information, refer to ibm.com/systems/storage/disk/storwize_v7000/overview.html. Note that the IBM Storwize V7000 Unified disk system is not recommended for VDI workloads.

IBM Flex System V7000 Storage Node

The IBM Flex System V7000 Storage Node is a Storwize V7000 storage system that can be inserted into an IBM Flex System Enterprise Chassis and has all of the same benefits. The IBM Flex System V7000 Storage Node uses four slots in the chassis. Up to nine external V7000 storage expansion units can be attached per storage node and up to four storage nodes can be clustered together.

Figure 13: IBM Flex System V7000 Storage Node (2.5 in. drive model with 24 drives)

For more information refer to ibm.com/systems/flex/storage/v7000.

IBM Storwize V3700

The IBM Storwize V3700 entry-level disk storage system is designed with sophisticated capabilities unusual for a system of this class. It offers efficiency and flexibility through built-in thin provisioning and nondisruptive migration of data from existing storage. Built upon the innovative technology in the Storwize family, Storwize V3700 addresses block storage requirements of small and midsize organizations at an affordable price.

The IBM Storwize V3700 storage system provides the following benefits.

Easily manage and deploy this system using the embedded graphical user interface based on the IBM Storwize interface design

Experience rapid, flexible provisioning and simple configuration changes with internal virtualization and thin provisioning

Have continuous access to data with integrated non-disruptive migration

20

http://www-03.ibm.com/systems/flex/storage/v7000/



Protect data with sophisticated remote mirroring and integrated IBM FlashCopy® functionality.

Optimize costs for mixed workloads, with up to three times performance improvement with only five percent flash storage capacity using the IBM System Storage Easy Tier feature

Benefit from advanced functionality and reliability usually only found in more expensive systems

Scale up to 120 2.5-in. disk drives or 60 3.5-in. disk drives with four expansion units

Provide host attachment through 6 Gb SAS and 1 Gb iSCSI ports (standard)

Figure 14: IBM Storwize V3700 (2.5 in. drive model with 24 drives)

For more information, refer to ibm.com/systems/storage/disk/storwize_v3700.

IBM System Storage N series

The IBM System Storage N series systems provide powerful virtualization and thin-provisioning capabilities to help you maximize storage utilization while minimizing the use of power, cooling, and floor space. At the same time, you can improve staff productivity with an integrated suite of application-aware manageability software offering policy-based automation to otherwise manual tasks, improving storage efficiency.

The N series systems can integrate Fibre Channel, SAN, iSCSI SAN, NAS, Fibre Channel over Ethernet (FCoE), primary, near-line and regulatory compliance data retention and archival storage in a single code architecture. It also offers massive expandability to support growth and consolidation. The combination of versatility and simplicity of N series systems is intended to help you respond quickly to changing business needs.

For more information, visit the IBM Network attached storage website at ibm.com/systems/storage/network/index.html.

N3220 controller

IBM System Storage N3220 is an entry-level system, using internal SATA disk and SAS technologies. It is a 2U, high-density system. Up to five expansion units (EXN3000) can also be attached for a total of 144 hard drive spindles.

The IBM System Storage N3220 system consists of single-node (Model A12) and a dual-node (Model A22) in a 2U rack-mountable enclosure. The N3220 Model A22 is designed to provide identical functions as the single-node Model A12, but with the addition of a second processor control module and the Clustered Failover (CFO) licensed function. These controllers support the addition of a mezzanine I/O card which could be 10GbE. The controllers do not support the FlashCache feature.

N6240 controller

IBM System Storage N6240 storage controllers include the Model C21, an active/active dual-node base unit, the Model E11, a 3U single-node base unit, and the Model E21 which is the coupling of two Model E11s for a total of 6U. Exx models contain an I/O expansion module that provides additional PCIe slots.

21

http://www-03.ibm.com/systems/storage/disk/storwize_v3700/

http://www-03.ibm.com/systems/storage/network/index.html



At least one storage expansion unit and a maximum of 25 must be attached to the N6240 storage controller giving a total maximum of 600 hard drive spindles. Each N6240 controller can support up to 512MB of FlashCache and numerous I/O features.

N7950T controller

The IBM System Storage N7950T (2867 Model E22) system is an active/active dual-node base unit consisting of two cable-coupled chassis with one controller and one I/O expansion module per node in a 12U rack-mountable enclosure. The N7950T supports up to PCIe adapters with a variety of Fiber and Ethernet options. At least one storage expansion unit and a maximum of 60 must be attached to the N7950T storage controller giving a total maximum of 1440 hard drive spindles. Each N67950T controller can support up to 3GB of FlashCache and numerous I/O features.

EXN3000 expansion unit

The EXN3000 storage expansion unit is a 4U rack-mountable disk enclosure containing five (and up to a maximum of 24) SAS or SATA disk drives. The supported disk drives are:

SAS 15k rpm: 300 GB, 450 GB, and 600 GB

SATA 7.2k rpm: 500 GB, 750 GB, 1 TB, and 2 TB

10 GbE networking As noted earlier, 10 GbE is used as the standard network for IBM SDI and it needs to transport several VLANs. IBM Virtual Fabric provides a fast, flexible, and reliable I/O solution. This new and innovative solution based on Emulex adapters and specific IBM switches is different than other virtual network interface card (NIC) solutions in that it establishes dedicated pipes between the adapter and the switch. This solution is built on industry standards and provides maximum performance in both directions. IBM Virtual Fabric also allows for advanced levels of security and higher levels of availability per virtual NIC by leveraging virtual pipes, which isolate vNICs from each other.

For more information, visit the IBM website for network switches ibm.com/systems/networking/switches/rack.html.

Emulex 10 GbE adapters

The Emulex10 Gb Virtual Fabric Adapters are available as slotless mezzanine cards for both Flex System x240 and the System x rack servers. An optional upgrade provides iSCSI and FCoE capability. The Emulex card takes a 10 Gb port and splits it into four vNICs. This configuration allows each vNIC or virtual channel to be between 100 Mb and 10 Gb in increments of 100 Mb. The total of all four vNICs cannot exceed 10 Gb.

IBM Flex System Fabric EN4091 Pass-thru Module

The IBM Flex System EN4091 10 GbE Pass-thru Module (as shown in Figure 15) offers easy connectivity of the IBM Flex System Enterprise Chassis to any external network infrastructure. This unmanaged device enables direct connectivity of the compute node in the chassis to an external top-of-rack data center switch. This module can function at both 1 GbE and 10 GbE speeds. It has 14 internal 10 Gb links, and 14 external 10 Gb SFP+ uplinks.

22

http://www-03.ibm.com/systems/networking/switches/rack.html



Figure 15: IBM Flex System Fabric EN4091 10 Gb Pass-thru Module

IBM Flex System Fabric EN4093R 10 Gb Scalable Switch

The IBM Flex System Fabric EN4093R 10 Gb Scalable Switch offers easy connectivity of the IBM Flex System Enterprise Chassis to any external network infrastructure. By default the CN4093 switch supports fourteen 10 GbE internal ports, two external 10 GbE SFP+ ports, and six external Omni Ports. Further ports can be enabled, including up to 28 additional internal ports, two external 40 GbE QSFP+ uplink ports, and six additional external Omni Ports. The switch offers full Layer 2/3 switching, FCoE Full Fabric, can help clients migrate to a 10 Gb or 40 Gb Ethernet infrastructure, and offers virtualization features such as Virtual Fabric and IBM VMready®, plus the ability to work with IBM Distributed Virtual Switch 5000V.

Figure 16: IBM Flex System Fabric EN4093R 10 Gb Scalable Switch

For more information, see ibm.com/redbooks/abstracts/tips0864.html.

IBM Flex System Fabric CN4093 10 Gb Converged Scalable Switch

The IBM Flex System Fabric CN4093 10Gb Converged Scalable Switch offers easy connectivity of the IBM Flex System Enterprise Chassis to any external network infrastructure. The switch offers full Layer 2/3 switching and FCoE Full Fabric and Fibre Channel NPV Gateway operations to deliver a truly converged integrated solution, and is designed to install within the I/O module bays of the IBM Flex System Enterprise Chassis. The switch can help clients migrate to a 10 Gb or 40 Gb converged Ethernet infrastructure and offers virtualization features such as Virtual Fabric and VMready, plus the ability to work with IBM Distributed Virtual Switch 5000V.

23




Figure 17: IBM Flex System Fabric CN4093 10 Gb Converged Scalable Switch


IBM RackSwitch G8124E

The IBM RackSwitch™ G8124E (as shown in Figure 18) is a 10 GbE switch specifically designed for the data center, providing a virtualized, cooler and easier network solution. The G8124E offers twenty-four 10 GbE ports in a high-density, 1U footprint. Designed with top performance in mind, the RackSwitch G8124E provides line-rate, high-bandwidth switching, filtering and traffic queuing without delaying data and large data-center grade buffers to keep traffic moving.

The G8124E switch is virtualized by providing rack-level virtualization of networking interfaces. The VMready software enables movement of virtual machines providing matching movement of VLAN assignments, access control lists (ACLs) and other networking and security settings. VMready works with all leading VM providers including VMware, Citrix, and Microsoft Hyper-V. The G8124E switch also supports Virtual Fabric, which allows for the distribution of a physical NIC into two to eight vNICs and creates a virtual pipe between the adapter and the switch (for improved performance, availability and security, while reducing cost and complexity. The G8124E switch is easier to manage with server-oriented provisioning using point-and-click management interfaces.

Figure 18: IBM RackSwitch G8124E

For more information, see ibm.com/redbooks/abstracts/tips0787.html.

IBM RackSwitch G8264

Designed with top performance in mind, IBM RackSwitch G8264 (shown in Figure 19) is ideal for today’s big data, cloud and optimized workloads. The G8264 switch offers up to 64 10 Gb SFP+ ports in a 1U form factor and is future-proofed with four 40 Gb QSFP+ ports. It is an enterprise-class and full-featured data-center switch that deliver line-rate, high-bandwidth switching, filtering, and traffic queuing without delaying data. Large data-center grade buffers keep traffic moving. Redundant power and fans along with numerous high availability features equip the switches for business-sensitive traffic. The G8264 switch supports IBM VMready technology, an innovative, standards-based solution to manage desktops in small to large-scale data center and cloud environments.

The G8264 switch is ideal for latency-sensitive applications such as VDI. It supports IBM Virtual Fabric to help clients reduce the number of I/O adapters to a single dual-port 10 Gb adapter, helping reduce cost and complexity. The G8264 switch supports the newest protocols—including Data Center Bridging/Converged Enhanced Ethernet (DCB/CEE) for support of FCoE, in addition to iSCSI and NAS.

24





Figure 19: IBM RackSwitch G8264


IBM RackSwitch G8264CS

The G8264CS switch offers the benefits of a converged infrastructure today, while providing flexibility for future growth and expansion. The switch simplifies deployment with its innovative IBM Omni Port technology. Omni Ports give clients the flexibility to choose 10 Gb Ethernet, 4/8 Gb Fibre Channel or both for upstream connections and in FC mode, Omni Ports provide convenient access to FC storage.

The G8264CS switch offers up to 36 10 Gb SFP+ ports, and 12 Omni Ports in a 1U form factor and is future-proofed with four 40 Gb QSFP+ ports. It is an enterprise-class and full-featured data -center switch that deliver line-rate, high-bandwidth switching, filtering, and traffic queuing without delaying data. Large data-center grade buffers keep traffic moving. Redundant power and fans along with numerous high-availability features equip the switches for business-sensitive traffic. The G8264 switch supports IBM VMready technology, an innovative, standards-based solution to manage desktops in small to large-scale data center and cloud environments.

The G8264CS switch is ideal for latency-sensitive applications such as VDI. It supports IBM Virtual Fabric to help clients reduce the number of input/output (I/O) adapters to a single dual-port 10 Gb adapter, helping reduce the cost and complexity. The G8264CS switch supports the newest protocols—including Data Center Bridging/Converged Enhanced Ethernet (DCB/CEE) for support of FCoE, in addition to iSCSI, NAS, and Fibre Channel.

Figure 20: IBM RackSwitch G8264CS


1 GbE networking

IBM RackSwitch G8052

The IBM System Networking RackSwitch G8052 (as shown in Figure 21) is an Ethernet switch specifically designed for the data center, providing a virtualized, cooler and simpler network solution. The IBM RackSwitch G8052 offers up to forty-eight 1 GbE ports and up to four 10 GbE ports in a 1U footprint. Redundant power supplies and fans, along with numerous high-availability features, mean that the G8052 switch is always available for business-sensitive traffic.

Figure 21: IBM RackSwitch G8052


25



http://ibm.com/redbooks/abstracts/tips0813.html



Storage area network

8 Gb and 16 Gb Fibre Channel adapters

IBM offers a range of 8 Gb and 16 Gb Fibre Channel adapters either as slotless mezzanine cards for the Flex System x240 Compute Node or card adapters for System x rack servers.

IBM Flex System FC3171 8Gb SAN Switch

The IBM Flex System FC3171 8Gb SAN Switch is a full-fabric Fibre Channel component with expanded functionality that is used in the IBM Flex System Enterprise Chassis. The SAN switch supports high-speed traffic processing for IBM Flex System configurations, and offers scalability in external SAN size and complexity, and enhanced systems management capabilities. The FC3171 switch provides 14 internal 8 Gb Fibre Channel ports and 6 external ports and supports 2 Gb, 4 Gb, and 8 Gb port speeds.

Figure 22: IBM Flex System FC3171 8 Gb SAN Switch


IBM Flex System FC5022 16 Gb SAN Switch

The IBM Flex System FC5022 16 Gb SAN Scalable Switch is a high-density, 48-port, 16 Gbps Fibre Channel switch that is used in the IBM Flex System Enterprise Chassis. The switch provides 28 internal ports to compute nodes and 20 external SFP+ ports. The FC5022 offers end-to-end 16 Gb and 8 Gb Fibre Channel connectivity.

Figure 23: IBM Flex System FC5022 16 Gb SAN Switch


IBM System Storage SAN24B-4 Express

The IBM System Storage SAN24B-4 switch Express is a simple-to-use SAN switch with easy-to-install and easy-to-use features designed specifically for the needs of small to medium-size environments. It supports autosensing of 2, 4, or 8 port speeds. The SAN24B-4 supports up to 24 ports in a 1U package.

26





Figure 24: IBM System Storage SAN24B-4 Express

For more information, refer to ibm.com/systems/networking/switches/san/b-type/san24b-4/express

IBM System Storage SAN24B-5/SAN48B-5

The IBM System Storage SAN24B-5 and SAN48B-5 SAN switches are designed to meet the demands of hyper-scalable, private cloud storage environments by delivering 16 Gbps Fibre Channel technology and capabilities that support highly virtualized environments. These switches support autosensing of 2, 4, 8 or 16 Gb port speeds. The SAN24B-5 supports up to 24 ports and the SAN48B-5 supports up to 48 ports in a 1U package.

Figure 25: IBM System Storage SAN48B-5

For more information, refer to ibm.com/systems/networking/switches/san/b-type/san24b-5 and ibm.com/systems/networking/switches/san/b-type/san48b-5.

System performance considerations There are four main factors that affect the performance of a VDI solution:

Processor

Memory

Storage

Networking

A good VDI deployment is balanced with respect to these four factors and should not unduly stress one of these factors to the detriment of the overall solution.

Equally important is the elimination of single points of failure in the infrastructure architecture and the ability to failover if an individual piece of hardware or software is no longer functional. The cost of the infrastructure might increase if it needs to cope with multiple points of failure. The performance design of the system should be unaffected in the failover scenario, which means that extra performance capacity is built into the system for the normal case.

This section addresses considerations for these factors in a general way. Detailed performance results and recommendations are found in each of the vendor-specific reference architectures.

27

http://ibm.com/systems/networking/switches/san/b-type/san24b-4/express/

http://ibm.com/systems/networking/switches/san/b-type/san24b-5

http://ibm.com/systems/networking/switches/san/b-type/san24b-5



For all production deployments, IBM recommends an assessment and a proof of concept or pilot deployment to validate the actual performance against the expected performance. Actual user workload in production environments can vary greatly, might be due to lighter or heavier user tasks, impact of antivirus solutions, additional load generated by application virtualization, profile management solutions or operational tasks such as patching or indexing.

There are four well-known phases when considering the performance of a VDI implementation:

1. Boot

2. Login

3. Steady state

4. Logoff

The boot phase is when all of the desktops are booted and made ready for users. Desktops are booted when the system is first initialized and IBM recommends restarting the desktops once a week. Staggering of the reboots reduces the impact of this so-called “boot storm.” Any image-recompose or refresh operations or other maintenance requiring the restart of all virtual desktops must be performed during maintenance windows or off-peak hours to minimize the input/output operation (IOP) impact on the storage system.

The login phase occurs when users log in to the desktops. The so-called “login storm” occurs when all the employees come to work and first log in to their desktops at the beginning of the day. The measurements from the login storm are used in the vendor-specific reference architectures as the peak IOP rate. This peak assumes that a new user logs into a server every 30 seconds. The load on the storage system is the currently logged on users in a steady state plus all of the new users, one per server that are logging on.

The steady state phase occurs when after log in is complete and the users are performing the normal work. The steady state phase is typically the longest phase. The IOP measurements from this phase must not be used as a basis for a VDI deployment as they are usually too small and do not adequately represent the daily peak at login.

The logoff phase is when users log out from their desktop and a new desktop VM is restarted. If there are many simultaneous log out operations, then this phase is similar to the boot phase and can be very I/O intense. The logoff phase needs to be managed appropriately in order to avoid refresh operation impacting the system performance. You can for example set timeouts that delay the logout after the user disconnects and therefore delay the refresh operation or script the refresh (for example, at night time) instead of refreshing the image automatically on logoff.

The login and logoff pattern of a given environment can influence the system utilization if it significantly deviates from the baseline assumptions described here, such as users logging into their desktops in intervals shorter than 30 seconds.

Processor and memory for user desktops The number of desktops that can be run on a given server depends upon the available system memory and compute power of the processors. For a cost-effective solution, the maximum number of users should be put on each server without wasting processor resource or memory, notwithstanding the extra buffer needed for failover in case a server fails.

It is a best practice not to overcommit on memory as swapping to disk can have severe impact on performance — a better strategy is to give each desktop more memory. Alternatively, a monitoring tool can be run to gather information about existing desktops. The desktop memory size required does not necessarily have to match the memory supplied in a desktop machine – it can be larger or smaller.

28



Some hypervisors implement schemes to better manage the memory for each desktop with the ultimate aim of allowing more desktops to share a server. For example, memory blocks that are exactly the same are shared between desktops. This can reduce the total memory needed. However, no good calculators exist to understand the savings. Ultimately, it might require testing to determine the best VM size for a given workload.

To simplify matters, the easiest solution is still to divide the system memory by the average VM size after taking into account the average hypervisor memory of 4 GB. For example, a server with 256 GB of memory can host up to 125 desktops each with 2 GB of memory.

If one or more servers fail, then the users on that server need to be transferred over to the remaining servers, which increases the number of desktops per server. This means, for production purposes, the number of users on each server needs to be low enough to allow for headroom in both memory and processor to support these additional desktops and still keep processor utilization under 100%. This is a best practice to avoid overcommitting on the processors, which can be worse than overcommitting on memory. The redundancy required for failover is dependent on the system environment and a 5 to 1 ratio is recommended for most circumstances.

High availability for management VMs In addition to user desktops, there are a number of different VMs needed for management of the VDI environment. The size and type of management VMs required depends on the individual VDI vendor solution. In all cases, it is a best practice to use at least two separate servers for these VMs so that there is failover from one of these servers to the other. It also makes sense that these management VM servers are configured the same as the servers for user desktops so that they can be used interchangeably. For example, a server running user virtual desktops can be co-opted to run management VMs while a management server is down thus maintaining high availability for the management services.

Storage VDI can be a very intensive workload for storage both in terms of IOPS and amount of data to be stored, which translate to a high cost per user. Therefore there are a number of different solutions to reduce both the IOPS and the amount of data stored. The storage infrastructure for VDI is highly dependent on the individual situation and depends on both technical as well as unique organizational criteria.

The most significant performance optimization is to use stateless desktops and where possible to use local SSDs to cache data locally. This helps reduce cost as server SSDs are less expensive than storage SSDs and also reduces network traffic. Refer to the “Image assignment models” section on page 10 for more information.

Other optimizations that can be performed locally at each server are storage read/write caches and de-duplication that reduce data transfers to and from shared storage. These software-based caches can provide very significant advantages at the cost of extra RAM in each server.

For shared storage, the most important performance criterion is the ability to service I/O operations from all of the desktops. The performance required for a desktop logon is at least 50% more than that needed for a steady state condition. At logon, the I/O operations consist of mainly reads. At logout, profile changes are written back to disk using the chosen profiling tool (refer to the “User profiles” section on page 13). Third-party alternatives to MSRP tend to load profile information on demand and store changes in regular intervals, which flattens the input/output operations per second (IOPS) requirement at the cost of making the data a little larger.

An understanding of the read-write ratio is important as writes generally have a larger impact on the disk subsystem due to RAID penalties (writing the redundancy information) and the fact that caching algorithms

29



often only address reads. VDI is normally 75% or more writes, thus having an additional impact on the number of IOPS. For example, a single 15k rpm drive of 175 IOPS in a RAID 10 array with a two times write penalty is actually only worth 100 IOPS (25 read and 75 write).

The simplest and most transparent storage optimization is a RAM or flash memory-based read-only cache in the shared storage device. As indicated before, this has only limited usefulness at logon time when there are reads.

Tiering of shared storage so that different types of VDI I/O transactions go to different types of storage is helpful. Frequently read data, such as VM base images, can be explicitly placed into a separate RAID 1 or RAID 10 array of SSDs. SSDs can also be used as a general read/write cache so that the frequently used data is stored transparently on SSDs. Some amount of learning may be required to train this SSD cache in shared storage.

Data compression and data de-duplication are other possibilities for reducing the amount of data to be stored at the cost of processing power either at the VDI server or in the shared storage device. Both of these techniques might also destroy the original meaning of the data, which can make it harder to perform backups or data replication to other sites.

As an alternative to spinning disks and SSDs, all flash memory storage systems solve the VDI IOPS problem but are costly even for small storage sizes. These flash storage systems tend to be used in combination with other storage devices or optimizations such as compression to somewhat lessen the cost.

A discussion on storage is not complete without mentioning RAID. For temporary data stored on local SSDs as required by stateless desktops, RAID 0 provides the best performance and capacity. The decision is not so clear for other types of VDI data that need redundancy. It is often a trade-off between drive capacity and drive performance.

With stateless desktops and local SSDs, the remainder of the I/O for folders and profile data tends to be capacity-bound meaning that the limit on the disk capacity you need rather than the disk performance. This allows using a RAID 5 or RAID 50 array for the best compromise on disk storage and disk performance. However for dedicated desktops, the I/O tends to be performance bound and more drives are needed to give the required IOPS, often then providing more capacity than needed. In this case, RAID 10 is the best option. Some storage systems offer custom RAID levels, which might offer a better compromise than standard RAID levels.

Networking There are essentially three types of VDI networking transactions: user, management, and storage.

User and management networking

Regardless of the flavor of virtual desktop, published desktop, or published application being implemented, the network plays a critical role, especially for remote and branch office users. If the network bandwidth is not planned properly, users might most likely experience poor performance with their virtual desktop. As one might expect, the user experience can degrade as the latency increases and the bandwidth decreases.

Proper network planning must be based on the type of work users are performing and the overall network topology. The bandwidth requirements of delivering a full Windows desktop might likely be higher than the bandwidth required for delivering few applications because a full Windows desktop provides a richer experience along with more multimedia and graphical content and is idle less often than when a user is only accessing few applications.

30



To better determine user bandwidth requirements of the user VLAN, the user’s activity must be assessed. Estimating bandwidth for office-based applications might result in inadequate performance if users also print and access multimedia content. The percentage of time a user spends working with Microsoft Office based applications, browsing the Internet, accessing videos, and being idle can help in determining the overall bandwidth required. Table 2 gives the bandwidth estimates for different types of workload.

Activity Bandwidth per user

Office-based 50 kbps

Internet 80 kbps

Printing 600 kbps

Flash video 200 kbps

Standard WMV video 500 kbps

High-definition WMV Video 2000 kbps

Idle Based on active application

Table 2. Typical user workload bandwidth estimates

By estimating the percentage of time for each activity, an overall estimate of average required bandwidth per user can be obtained. Caution must be taken when using the average value. By averaging out the bandwidth requirements across an entire day and across many users, there might be a lack of bandwidth if a large percentage of users have a large burst in traffic at the same time. Based on the expected user habits, it is advisable to include bandwidth burst calculations for unexpected bursts of traffic.

Assuming an average bandwidth requirement of 100 to 200 kbps, then 10,000 users would need a bandwidth of 1 to 2 Gbps on the user VLAN. The management VLAN is used much less and a general guideline is 0.5 Gbps. Both the user VLAN and management VLAN can be provided by a single dual-port Emulex 10GbE Virtual Fabric Adapter.

In order to support networking failover, it is recommended that some kind of link aggregation is used, such as Link Aggregation Control Protocol (LACP). For smaller environments, this might be too complex and it can be sufficient to just keep a spare switch.

Storage networking

The shared storage for VDI can be connected to the server nodes in a variety of ways. The three most common are 10 GbE, 8/16 Gbps Fibre Channel SAN, or FCoE using 10 GbE.

The storage network requires the most bandwidth and lowest latency compared to the user and management networks. It is suggested that at least four and possibly eight network connections are used going into a shared storage device. Half of the connections go into each storage controller and each storage controller is connected to two different network switches to provide redundancy. This connection strategy provides the best performance if either a storage controller or a network fails. If both a storage controller and a network fail, then there is at least one network connection to handle the load. Redundancy is provided by LACP for 10 GbE networking and dual-zoning fabrics for Fibre Channel.

31



Appendix A: Performance testing This appendix describes IBM’s performance testing methodology, test environment, and tools that were used to verify VDI performance for different hardware and software infrastructures. The tests for each of the solutions were conducted in partnership with the product vendors at IBM lab facilities.

The lab setup consisted of various IBM PureFlex System and IBM System x servers, combined with an IBM 10 GbE SAN networking infrastructure and IBM storage systems. The individual virtual desktop solutions were installed on top of the described infrastructure and architecture validation testing was performed using the test methodology described in the following section.

Performance testing methodology The key to any successful performance test is to understand what is being measured and how to interpret the results. VDI is a performance-intensive workload that can stress all parts of the system including processors, memory, storage, networking, and the VDI software infrastructure. In order to successfully measure the performance, each of these attributes needs to be stressed in turn to find out its limits.

To understand processor performance and how many desktops can be serviced by processors, the VM server should have access to copious local memory (384 GB or more) and shared storage. The desktop memory size is kept small to fit as many desktops as possible into the local server (1 GB or 1.5 GB). Variables include using processors of different clock speeds, different number of cores, or a different number of processors. Only one server is needed per processor performance test as scaling for servers is usually linear.

To understand memory performance and how many desktops can be serviced, the VM server should have fast processors and access to sufficient shared storage. Variables include using different amounts of memory and desktops with different memory requirements. Only one server is needed per processor performance test as scaling for servers is usually linear.

To understand storage performance and the number of IOPS from a given storage configuration, the storage configuration is artificially constrained to a smaller array of drives. Variables include using different storage technologies both local and shared, different speeds of drives, and different RAID levels. Depending on the amount of storage allocated, one or more servers might be needed to drive the storage to capacity. It is also advisable to test different storage sizes to verify linear scalability.

To understand networking performance, the network is artificially constrained, where possible. Variables include using different networking technologies, different network speeds, and different display protocols such as RDP, PCoIP, and ICA. This performance test is the hardest to verify and usually many servers are needed to drive the network to capacity.

Performance testing of the VDI software infrastructure was not explicitly performed as this is the responsibility of the VDI vendor. Implicit testing was performed as part of other tests. This is also true for validation testing. Potential errors and problems were reported by the VDI vendor as they were found during testing but there is not an explicit plan to verify all of the VDI functionality.

The primary performance metrics captured by IBM’s testing included:

Processor Throughout the testing, the VSImax was typically triggered by processor constraints. Refer to the “Login VSI” section on page 34 for more information.

Memory Monitored aspects of memory related behavior, such as memory ballooning and swapping that can have a significant impact on the overall system performance.

32



IOPS Where appropriate, separate data stores were created for the different storage types, for example, replicas, linked clones, and so on in order to determine IOPS distribution.

Disk latency This is the latency seen at the device driver level and includes the roundtrip time between the host bus adapter (HBA) and the storage. The esxtop command returns the DAVG/cmd metric (average driver milliseconds/command), which provides a good indicator of performance of the backend storage. Refer to the “Esxtop” section on page 35 for more information.

Network traffic Estimate of network bandwidth requirements.

Performance test environment The performance test environment consists of two distinct parts:

The test framework that is used to generate test workload and capture the test results

The hardware and software configuration that is being tested

Each part is connected together by common networking and common services such as Active Directory, DHCP, DNS, and WINS. Figure 26 is an example test environment for an IBM Flex System Enterprise Chassis connected to shared storage either using 10 GbE or a SAN network switch.

Test InfrastructureSystem Under Test

Active Directory, DHCP, and DNS Server

Load Generation Servers (Users)

Storage for results, logs, management and load generation VM images

VM Servers (for users and management)

Shared Storage

Management Network

Storage Network

User Network

SAN Network

G8124Switch

SAN24B-5Switch

Figure 26: Example test environment

33



Performance test tools Performance test tools are needed to both generate user loads and to monitor and measure the system performance under a particular load. Several different tools were used including Login Virtual Session Indexer (VSI), esxtop, and IBM Tivoli® Storage Productivity Center. It is a good practice to perform multiple runs to verify the consistency of results.

Login VSI

Login VSI is a VDI vendor-independent benchmarking tool to objectively test and measure the performance and scalability of centralized Windows desktop environments such as Server Based Computing and VDI. Leading IT analysts recognize and recommend Login VSI as an industry-standard benchmarking tool for SBC and VDI and can be used by end-user organizations, system integrators, hosting providers and testing companies.

Login VSI can be used for different purposes:

Benchmarking: Make the right decisions about different infrastructure options based on tests.

Load-testing: Gain insight in the maximum capacity of your current (or future) hardware environment.

Capacity planning: Decide exactly what infrastructure is needed to offer users an optimal performing desktop.

Change Impact Analysis: To test and predict the performance effect of every intended modification before its implementation.

Login VSI measures the capacities of virtualized infrastructures by simulating typical (and atypical) user workloads and application usage. For example, the Login VSI medium workload simulates a medium-level knowledge worker using Microsoft Office, Internet Explorer, and PDFs. The medium workload is scripted in a 12- to 14-minute loop when a simulated Login VSI user is logged on and each test loop performs the following operations:

Microsoft Outlook 2007 and Outlook 2010, browse 10 messages.

Internet Explorer, one instance is left open (BBC.co.uk), one instance is browsed to Wired.com, Lonelyplanet.com

Flash application called gettheglass.com (not used with MediumNoFlash workload).

Word 2007 and Word 2010, one instance to measure response time, one instance to review and edit document.

Bullzip PDF Printer and Acrobat Reader, the Word document is printed and reviewed to PDF.

Microsoft Excel 2007 and Excel 2010, a very large randomized sheet is opened.

Microsoft PowerPoint 2007 and PowerPoint 2010, a presentation is reviewed and edited.

7-zip: Using the command line version, the output of the session is zipped.

After the loop finished, it restarted automatically. Each loop takes approximately 14 minutes to run. Within each loop, the response times of specific operations are measured at a regular interval: six times within each loop. The response times of these seven operations is used to establish the VSImax score. VSImax is the maximum capacity of the tested system expressed in the amount of Login VSI sessions.

34



The VSImax score parameter (the number to indicate user density) can then be used to determine the performance of a particular system configuration and determine the influence of changes when Login VSI test is rerun on a modified system. Figure 27 provides an example output of the LoginVSI Analyzer showing VSImax.

Figure 27: VSImax example

The following parameters and rules were used for Login VSI tests:

User login interval: 30 seconds (some tests were ran at 15 seconds intervals).

Workload: Medium for most tests but additional tests have been performed using the light, heavy, and multi-media workloads.

All virtual desktops were pre-booted before the tests.

The number of powered-on VMs was adjusted to stay within a 10% margin of VSImax in order to avoid unreasonable overhead by “idling” virtual machines.

Esxtop

IOPS distribution and latency are the two most important metrics to be considered in the analysis of storage system. The VMware tool esxtop was used to capture this information for those test scenarios that use the VMware ESXi hypervisor. Refer to http://communities.vmware.com/docs/DOC-9279 for more details on iInterpreting esxtop statistics.

35

http://communities.vmware.com/docs/DOC-9279



The esxtop tool was used to capture the results from a test run. Figure 28 shows the command used to pipe the esxtop data to a file.

Figure 28: esxtop command line and usage

The esxtop data file is then opened using Microsoft Performance Monitor, an example of which is shown in Figure 29.

Phase 1 – Log in 30 Sec Intervals

Phase 3-Log Off

Phase 2 – Steady State 20 mins

Phase 3-

Log Off Phase 2 –

Steady State Phase 1 – Log in 30 Sec Intervals

Figure 29: Example Microsoft Performance Monitor output from esxtop

36



The test results for booted desktops are usually split into three standard phases (login, steady state, logoff) in order to provide a more comprehensive insight into the IOPS patterns across an average user’s desktop session. The maximum and average data points for all relevant performance aspects are extracted and collated into tables for the vendor-specific reference architecture documents.

A value of 20 milliseconds is typically considered the threshold for acceptable disk latency. The I/O latency can be verified by comparing the DAVG/cmd metric with the corresponding data from the storage system. If the two measurements are close, then the storage array might be faulty or misconfigured. If not, then the DAVG/cmd metric should be compared with corresponding data from points in between the storage system and the ESXi Server such as the FC switches. If this intermediate data also matches DAVG/cmd values, then it is likely that the storage is under-configured for the application.

Tivoli Storage Productivity Center

IBM Tivoli Storage Productivity Center helps to manage performance, availability, and capacity utilization of multi-vendor storage environments. It performs device configuration and management of multiple devices from a single-user interface, and helps to tune and proactively manage the performance of storage devices on the SAN while managing, monitoring, and controlling your SAN fabric.

Tivoli Storage Productivity Center provides comprehensive device, capacity, availability, and performance management features for IBM platforms, and significant capabilities for managing multi-vendor storage systems. It has advanced, native integration for IBM System Storage DS8000®, IBM Storwize V7000, IBM System Storage SAN Volume Controller and IBM XIV® Storage System. Two key areas of focus are performance management of storage systems and storage networking platforms, and capacity and operational management of IBM and heterogeneous storage systems. Tivoli Storage Productivity Center can help storage administrators to more efficiently manage large and complex heterogeneous storage environments by simplifying day-to-day operations, reducing management complexities, and improving system availability.

Tivoli Storage Productivity Center was used during testing to obtain in-depth insight into the storage performance. Storage metrics such as cache hit ratio, cache destage to disk (backend), and managed disk (MDisk) IOPS, and latency are exposed with Tivoli Storage Productivity Center. When these metrics are combined with hypervisor and Login VSI metrics, a complete infrastructure performance picture of the VDI environment is available. Figure 30 has example output for login and steady state phases where red is write IOPS and blue is read IOPS. This example shows some write caching and significant read caching.

Figure 30: Example Tivoli Storage Productivity Center output – front-end and back-end IOPS

37



Resources Reference architecture for IBM SmartCloud Desktop Infrastructure with Citrix XenDesktop at

ibm.com/partnerworld/page/stg_ast_eis_sdi_citrix_xendesktop

Reference architecture for IBM SmartCloud Desktop Infrastructure with VMware View at ibm.com/partnerworld/page/stg_ast_eis_sdi_vmware_view

Reference architecture for IBM SmartCloud Desktop Infrastructure with Microsoft Windows Server 2012 at ibm.com/partnerworld/page/stg_ast_sys_wp_ibm-smartcloud-virtual-desktop-infrastructure

IBM network-attached storage website at ibm.com/systems/storage/network/index.html

IBM website for network switches ibm.com/systems/networking/switches/rack.html

IBM PureSystems™ website at ibm.com/puresystems

IBM solid-state storage website at ibm.com/systems/x/options/storage/solidstate/enterprise.html

IBM System x rack servers website at ibm.com/systems/x/hardware/rack

IBM Flex System interoperability guide at ibm.com/redbooks/redpapers/pdfs/redpfsig.pdf

Tivoli Storage Productivity Center V5.1 Technical Guide at

ibm.com/redbooks/redpieces/pdfs/sg248053.pdf

38

https://twitter.com/IBMSystemsISVs�

https://www.ibm.com/partnerworld/page/stg_ast_eis_sdi_citrix_xendesktop

https://www.ibm.com/partnerworld/page/stg_ast_eis_sdi_vmware_view

http://www.ibm.com/partnerworld/page/stg_ast_sys_wp_ibm-smartcloud-virtual-desktop-infrastructure

http://www-03.ibm.com/systems/storage/network/index.html

http://www-03.ibm.com/systems/networking/switches/rack.html

http://www.ibm.com/ibm/puresystems/us/en/index.html

http://www-03.ibm.com/systems/x/options/storage/solidstate/enterprise.html

http://www-03.ibm.com/systems/x/hardware/rack

http://ibm.com/redbooks/redpapers/pdfs/redpfsig.pdf

http://www.redbooks.ibm.com/redpieces/pdfs/sg248053.pdf



Trademarks and special notices © Copyright IBM Corporation 2013.

References in this document to IBM products or services do not imply that IBM intends to make them available in every country.

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at www.ibm.com/legal/copytrade.shtml.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Linux is a trademark of Linus Torvalds in the United States, other countries, or both.

Other company, product, or service names may be trademarks or service marks of others.

Information is provided "AS IS" without warranty of any kind.

All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer.

Information concerning non-IBM products was obtained from a supplier of these products, published announcement material, or other publicly available sources and does not constitute an endorsement of such products by IBM. Sources for non-IBM list prices and performance numbers are taken from publicly available information, including vendor announcements and vendor worldwide homepages. IBM has not tested these products and cannot confirm the accuracy of performance, capability, or any other claims related to non-IBM products. Questions on the capability of non-IBM products should be addressed to the supplier of those products.

All statements regarding IBM future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. Contact your local IBM office or IBM authorized reseller for the full text of the specific Statement of Direction.

Some information addresses anticipated future capabilities. Such information is not intended as a definitive statement of a commitment to specific levels of performance, function or delivery schedules with respect to any future products. Such commitments are only made in IBM product announcements. The information is presented here to communicate IBM's current investment and development activities as a good faith effort to help with our customers' future planning.

Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the

39

http://www.ibm.com/legal/copytrade.shtml



40

storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput or performance improvements equivalent to the ratios stated here.

Photographs shown are of engineering prototypes. Changes may be incorporated in production models.

Any references in this information to non-IBM websites are provided for convenience only and do not in any manner serve as an endorsement of those websites. The materials at those websites are not part of the materials for this IBM product and use of those websites is at your own risk.