The Horizon View components fit together within a physical architecture, based on the concept of building blocks and pods. This scalable approach allows IT professionals to build out a solution as users migrate to virtual desktops.
A Horizon View pod integrates five 2,000-user building blocks into a View Manager installation that you can manage as one entity.
By taking this approach, you can be fairly user-agnostic and deploy additional blocks or pods with varying performance characteristics, geographical locations, or access mechanisms as required.
A typical Horizon View deployment can consist of 500 to 10,000 virtual desktops hosted across a single or multiple ESXi clusters managed by a management building block. In the following example, each ESXi host has two CPUs with eight cores, providing 16 cores in total and 128 desktop virtual machines per host. The building block has two clusters with 1024 desktop virtual machines in each cluster.
The components of this design are described below.
View Pod
The View pod (item 1), is an abstract component of View architecture. The View pod is the core of the logical View Manager Architecture Design. The View pod contains the following components:
- Connection Servers – There are 7 Horizon View Connection Servers in one replicated cluster. These operate in a 5+2 configuration, with 5 View Connection Servers actively brokering and possibly tunneling connections, and 2 in failover mode.
- Security Servers – There are 10 Security Servers in this design. Security servers are paired directly with a single View Connection Server.
- View blocks – There are 5 View blocks in this architecture design.
The View Management Block is a key component of the overall infrastructure supporting this View Architecture design. The View Management Block is where the virtual machines that support View pod and block infrastructure reside.
The View Management Block (item 3) is an abstract component of the View Architecture. These are:
- View Connection Servers.
- View Security Servers. Each security server is associated with one Connection Server, and a View Connection Server can have more than one paired View Security Server.
- View block vCenter servers, one per View block.
- Supporting vSphere infrastructure.
- Supporting server storage infrastructure.
- Supporting network infrastructure.
View Desktop Block
A View block (item 2), also known as a View building block, is also an abstract component in View architecture. View blocks are delineated by a vCenter instance and include the resources managed by a vCenter instance (ESXi hosts and vSphere clusters) and the View desktops and desktop pools that run on those hosts.
A View block consists of the following mandatory and optional components:
- vCenter servers – A View block is delineated by the resources managed by a vCenter server. There is always one vCenter Server per View block.
- ESXi hosts – A View block always has at least one ESXi host upon which to run the View desktops.
- Sphere clusters – vSphere clusters that contain the ESXi hosts. A desktop pool must not extend beyond the boundary of a vSphere cluster.
- View desktop pool – Every View block has at least one View desktop pool.
- Local mode pool – An optional type of View desktop pool that contains View local mode desktops. Local mode desktops can be checked out to run locally on a supported user access device, such as a laptop.
- View transfer server – At least one transfer server is required in a View block that contains a local mode pool. The View transfer server handles all communication with a checked out local mode desktop.
- Shared storage – A VMFS or NFS datastore that is accessible to all ESXi hosts in a View block. Datastores can be shared across View blocks.
- Local storage – Local datastores (HDD, SSDs or PCI storage physically installed in the ESXi server) are valid datastores for View desktop pools.
Additionally, load-balancing technologies can maximize the
scalability of a solution by automatically rebalancing connections when
additional resources are added to the View environment.
Support for a redundancy and failover mechanism at the
network level prevents the load balancer from becoming a single point of
failure. To prevent a single point of failure, the load balancers must cater to
redundancy and failover requirements so that if the main load balancer fails,
another load balancer in the group automatically starts handling connections.
To provide a degree of fault tolerance, a load balancing
solution must be able to remove failed View server nodes from the load-balanced
group.
The Horizon View solution does not include load balancing—it requires third party solution, typically Microsoft NLB or a hardware-based load balancer such as the F5 or Cisco load balancing products.
These are the basic design components of a Horizon View 5.2 pod which changed significantly in scale compared to the prior Vmware View 5.0 pod design. With VMware View 5.0, you had an 8 ESXi host cluster limit with 512 desktops per pool; but now, with Horizon View 5.2, that has increased to 32 ESXi host per cluster and 2000 desktops per pool.
