Scalability and High Availability

Connection Broker Architecture and Scalability:
Multiple Connection Brokers are permitted within a Provision infrastructure to ensure high levels of scalability and availability. Should one Connection Broker become unavailable, other Connection Brokers can automatically assume the added load. To optimize performance and increase scalability, the Connection Broker has been enhanced to service incoming authentication and connectivity requests from its local datastore cache, obviating the need to maintain and manage a pool of connections with the central datastore.

The connection broker is a transient subsystem of the overall VAS architecture; A connection (i.e., Remote Desktop Protocol) between an end-user device (i.e., PC, thin client) and a hosted desktop (i.e., Windows XP, Vista) does NOT pass through the Connection Broker. In the event of a Connection Broker malfunction, active clients do NOT suffer any disruptions, and new client connection requests are automatically redirected to other Connection Brokers within the Provision-enabled infrastructure.

The client-facing side of the Connection Broker is tasked with authenticating users and retrieving their authorized lists of published apps and desktops based on account name, group and OU memberships, and client device properties (i.e., thin PC or client device name and IP address). The Connection Broker is also tasked with redirecting clients to their appropriate VMs. For example, if a user requests to be connected to a published resource named 'Virtual Desktop', the Connection Broker responds with the address of the target VM and "drops out of the picture. The client then establishes an RDP connection directly with the target VM. If so desired, the RDP connection can be established indirectly with the target VM through the Provision SSL Gateway (RDP-over-SSL).

It is also important to note that the connection broker is a multi-threaded service capable of servicing thousands of requests per minute. To optimize its performance and efficiency, the Connection Broker was designed to maintain a pool of up to 100 active database connections, allowing it to service as many as 100 simultaneous connection requests. In the event it receives more than 100 simultaneous requests, the 'excess' requests are queued up and promptly serviced as pooled database connections become available. Typically, each connection request consumes a database connection for 1 or 2 seconds.

On the back-end, the Connection Broker communicates with VMware VI3 through the VirtualCenter SDK in order to perform power management tasks on an as need basis. For example, if, upon receiving a client connection request, the user's virtual machine is found to be powered off or suspended, the Connection Broker instructs VirtualCenter to power on (or resume) the virtual machine. Likewise, if a Provision VAS policy is in place to suspend an idle virtual machine, the Connection Broker sends a 'suspend' command to VirtualCenter. Additional VMware-integrated features include the ability to mass-produce virtual machines using VMware templates and customization objects, as well as enumerate existing data centers, resource pools, templates, and virtual machines.

In summary, the Provision Virtual Access Suite is designed to manage tens of thousands of hosted desktops, provided other infrastructure dependencies such as Windows Active Directory and VMware VI3 have been adequately designed to withstand the load requirements of a particular environment.

Next: Dynamic Desktop Deployment (D3) Architecture