Architecture Planning
Table Of Contents
- View Architecture Planning
- Contents
- View Architecture Planning
- Introduction to View
- Planning a Rich User Experience
- Feature Support Matrix for View Agent
- Choosing a Display Protocol
- Using Hosted Applications
- Using View Persona Management to Retain User Data and Settings
- Using USB Devices with Remote Desktops and Applications
- Using the Real-Time Audio-Video Feature for Webcams and Microphones
- Using 3D Graphics Applications
- Streaming Multimedia to a Remote Desktop
- Printing from a Remote Desktop
- Using Single Sign-On for Logging In to a Remote Desktop
- Using Multiple Monitors
- Managing Desktop and Application Pools from a Central Location
- Architecture Design Elements and Planning Guidelines for Remote Desktop Deployments
- Virtual Machine Requirements for Remote Desktops
- View ESXi Node
- Desktop Pools for Specific Types of Workers
- Desktop Virtual Machine Configuration
- RDS Host Virtual Machine Configuration
- vCenter Server and View Composer Virtual Machine Configuration
- View Connection Server Maximums and Virtual Machine Configuration
- vSphere Clusters
- Storage and Bandwidth Requirements
- View Building Blocks
- View Pods
- Advantages of Using Multiple vCenter Servers in a Pod
- Planning for Security Features
- Understanding Client Connections
- Choosing a User Authentication Method
- Restricting Remote Desktop Access
- Using Group Policy Settings to Secure Remote Desktops and Applications
- Implementing Best Practices to Secure Client Systems
- Assigning Administrator Roles
- Preparing to Use a Security Server
- Understanding View Communications Protocols
- Overview of Steps to Setting Up a View Environment
- Index
The Cloud Pod Architecture feature is not supported in an IPv6 environment.
For more information, see Administering View Cloud Pod Architecture.
Advantages of Using Multiple vCenter Servers in a Pod
When you create a design for a View production environment that accommodates more than 500 desktops,
several considerations affect whether to use one vCenter Server instance rather than multiple instances.
Starting with View 5.2, VMware supports managing up to 10,000 desktop virtual machines within a single
View pod with a single vCenter 5.1 or later server. Before you attempt to manage 10,000 virtual machines
with a single vCenter Server instance, take the following considerations into account:
n
Duration of your company's maintenance windows
n
Capacity for tolerating View component failures
n
Frequency of power, provisioning, and refit operations
n
Simplicity of infrastructure
Duration of Maintenance Windows
Concurrency settings for virtual machine power, provisioning, and maintenance operations are determined
per vCenter Server instance.
Pod designs with one
vCenter Server
instance
Concurrency settings determine how many operations can be queued up for an entire View pod
at one time.
For example, if you set concurrent provisioning operations to 20 and you have only one
vCenter Server instance in a pod, a desktop pool larger than 20 will cause provisioning
operations to be serialized. After queuing 20 concurrent operations simultaneously, one
operation must complete before the next begins. In large-scale View deployments, this
provisioning operation can take a long time.
Pod designs with
multiple
vCenter Server
instances
Each instance can provision 20 virtual machines concurrently.
To ensure more operations are completed simultaneously within one maintenance window, you can add
multiple vCenter Server instances (up to five) to your pod, and deploy multiple desktop pools in vSphere
clusters managed by separate vCenter Server instances. A vSphere cluster can be managed by only one
vCenter Server instance at one time. To achieve concurrency across vCenter Server instances, you must
deploy your desktop pools accordingly.
Capacity for Tolerating Component Failures
The role of vCenter Server in View pods is to provide power, provisioning, and refit (refresh, recompose,
and rebalance) operations. After a virtual machine desktop is deployed and powered on, View does not rely
on vCenter Server for the normal course of operations.
Because each vSphere cluster must be managed by a single vCenter Server instance, this server represents a
single point of failure in every View design. This risk is also true for each View Composer instance. (There is
a one-to-one mapping between each View Composer instance and vCenter Server instance.) Using one of
the following products can mitigate the impact of a vCenter Server or View Composer outage:
n
VMware vSphere High Availability (HA)
n
VMware vCenter Server Heartbeat™
View Architecture Planning
70 VMware, Inc.