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

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


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

IBM SmartCloud Desktop Infrastr#cture

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.

VMware View 5

XenDesktop and
VDI in a Box

Windows
Server 2012

Multi-Vendor VDI Support
Large Scale Virtual
Desktops
Multi-Hypervisor Support

ESXi, Hyper-V, XenServer

IBM Rack and
Flex System Building
Blocks
Local SSDs

IBM Shared Storage

IBM Storwize V7000 and
Flex System V7000 Storage Node

IBM Storwize
V3700

IBM N Series

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

Administrator
GUIs for
Support
Services

Client Devices
Client
Agent

Client
Agent

Client
Agent

Web Protocols

Client
Agent

Display Protocols
Dedicated
Virtual
Desktops

Web Server

Management Protocols

Connection Broker
Provisioning Services
VM Manager
VM Manager DB Server

License Server

Stateless
Virtual
Desktops

VM
Agent

VM
Agent

Published
Desktop

VM
Agent

VM
Agent

Published
Desktop

Local SSD
Storage

Published
Application

Hypervisor

Hypervisor

Other Services

Management Services

Hypervisor

Published
Desktops
and Apps

Support Service Protocols

VDI
Administrator
GUIs

Directory
DNS
DHCP
OS Licensing

Storage Protocols
Management
Databases

VM
Repository

VM
Deltas

User
Profiles

User
Data Files

Shared Storage
SmartCloud Desktop Infrastructure

Support
Services

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 standalone 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 storagehungry 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
Stateless
Stateless with motion
Dedicated

Local storage
High IOPS (using SSD)
Not Used
Not Used

Live migration
Not supported
Supported
Supported

Shared storage
Low IOPS
High IOPS
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.

Administrator
GUIs for
Support
Services

Client Devices

VDI
Administrator
GUIs

Client
Agent

Client
Agent

Client
Agent

Client
Agent

User VLAN

VM Manager
VM Manager DB Server

License Server

Management VLAN

Provisioning Services

VM
Agent

VM
Agent

Published
Desktop

VM
Agent

VM
Agent

Published
Desktop

Local SSD
Storage

Connection Broker

Stateless
Virtual
Desktops

Published
Application

Hypervisor

Hypervisor

Other Services

Management Services

Hypervisor

VM
Repository

Directory
DNS
DHCP
OS Licensing

SAN

Storage VLAN
Management
Databases

Published
Desktops
and Apps

USer VLAN

Dedicated
Virtual
Desktops

Web Server

VM
Deltas

User
Profiles

User
Data Files

Shared Storage
SmartCloud Desktop Infrastructure – Networking
Figure 4: Network model for SDI

12

Support
Services

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, unpersonalized 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 computeintensive, 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

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

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

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



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

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

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 datacenter 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 highavailability 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

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

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 deduplication 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.
G8124
Switch

SAN24B-5
Switch

User Network
Management Network
Storage Network
SAN Network

Shared Storage

Active Directory,
DHCP, and
DNS Server
Load Generation
Servers (Users)

VM Servers (for
users and
management)

System Under Test

Test Infrastructure

Figure 26: Example test environment


33

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

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

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

Figure 29: Example Microsoft Performance Monitor output from esxtop


36

Phase 2 –
Steady
Steady
State
State
20 mins

Phase 3Log Off
Log Off

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

IBM SmartCloud Desktop Infrastructure

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (18)

Similaire à IBM SmartCloud Desktop Infrastructure

Similaire à IBM SmartCloud Desktop Infrastructure (20)

Plus de IBM India Smarter Computing

Plus de IBM India Smarter Computing (20)

Dernier

Dernier (20)

IBM SmartCloud Desktop Infrastructure