Skip to main content
Key Decision Points
F
Written by Fegeins Louis
Updated over a week ago

Overview

itopia's Cloud Automation Stack makes it easy to deploy a Cloud Desktop environment in just a few minutes. However, it is important to plan your environment before creating your new deployment; while many aspects of a CAS deployment can be updated at any time, certain elements of the environment cannot be changed or are very difficult to change. This article provides key points of the CAS environment that you should consider before creating a deployment; making the right decisions for your organization will ensure a successful deployment.

Decision Checklist

Use the table below to draft an initial design for your Cloud Desktop environment

Category

Decision Point

Your Decision

Active Directory

AD Model: New Domain, Existing Domain, Trusted AD

AD Model (New Domain Only): AD DS or Managed AD

Region

Single-Region or Multi-Region Deployment

Networking

Isolated Network, Connected Network, or Existing Network

Fault Tolerance

Role Redundancy - RD Broker

Role Redundancy - RD Gateway

Role Redundancy - Domain Controllers (New AD DS Domain Only)

Sizing

Initial Number of Concurrent Users

Planned Number of Concurrent Users

Workloads

Number of Distinct Workloads

Amount of Isolation Needed between Workloads

Requirement for Dedicated Collection Pools

End-User Access

Custom Domain Names for Endpoints

Use of MyRDP Portal

End-User Client Software

Active Directory Model

One of the biggest decisions in your Cloud Desktop design is which Active Directory model you will use: use an existing domain, create a new domain, or create a new domain with an AD trust to an existing domain. A detailed explanation of each model is provided in Active Directory in CAS Deployments.

The Active Directory model you choose will primarily depend on the following questions:

  • Do you have an existing Active Directory domain?

    • If so, what level of integration (or isolation) do you require for your Cloud Desktop environment with your existing domain?

    • If so, how strict are your security policies with regards to privileged service accounts and vendor-managed objects in your AD?

  • What level of customization do you require for your Active Directory (i.e. schema extensions, custom hardening policies, custom software on domain controllers, etc.)?

  • How much additional management of AD infrastructure are you comfortable with: none/minimal, some, or not important?

  • Where do you plan to manage your AD users and groups: within CAS, or using native or third-party tools?

The table below provides a comparative view of each supported AD model based on the criteria above.

Decision Point

New AD (AD DS)

New AD (Managed)

Existing AD

Trusted AD

Do you have an existing AD?

Not an option

No an option

(Existing AD) Level of integration / isolation

No integration / Full isolation

No integration / Full isolation

Full integration / No isolation

Medium integration / High isolation

(Existing AD) Security impact

No impact

No impact

Medium impact

Low impact

Ability to customize AD

High

Low

High

High

Additional management required for AD

Medium

Low

Low

Medium

Deployment Regions

Deployments in CAS can be configured as single-region or multi-region. Regions refer to the specific Google Cloud datacenters geographically dispersed around the world. A single-region deployment creates all resources in a single GCP region; users all connect to a single access point in that region to access their Cloud Desktops. A multi-region deployment creates Cloud Desktop infrastructure in two or more GCP regions; users connect to the region that is geographically closest to them.

itopia CAS can be deployed into any region provided by Google Cloud; refer to the Google Cloud Regions and Zones documentation for information on available regions.

When deciding whether to create a single-region or multi-region deployment, consider the following criteria:

  • Do you have users in multiple geographic regions?

    • If so, is their workload sensitive to performance (specifically, latency that may impact the responsiveness of the Cloud Desktop)?

  • Where are the resources that your users will access via Cloud Desktop located? For example, will they access application servers located in a specific GCP region, or an on-premises datacenter in a particular geographic region?

  • How important is cost in your Cloud Desktop environment? Multi-region deployments must deploy infrastructure components in each region, which will incur additional compute costs in your Google Cloud project.

  • How will users access their Cloud Desktops? The MyRDP portal will automatically connect users to their nearest GCP region (using IP address geolocation); however, users connecting via the RD Web Portal or the RD Web Client will need to manually specify the URL for their region; having multiple regions could make this more confusing for users.

It is important to remember that multiple regions also provide additional redundancy in the event of a catastrophic regional failure; however, even within a single-region deployment, GCP and CAS both implement many measures to protect against service disruptions caused by datacenter failures. In other words, a multi-region deployment is not strictly required to provide fault tolerance; however, a multi-region deployment will provide additional fault tolerance in the event of an extreme regional outage of GCP infrastructure.

Also, when choosing between single- and multi-region deployment models, consider that CAS resources are deployed using GCP's "premium" networking tier, which routes inbound traffic to the closest GCP region to the user, and then reaches the destination GCP region using Google's dedicated "dark fiber" backbones. In practice, this means that although geographic distance of a user from their destination GCP region does add some latency, users can still enjoy a satisfactory experience as long as they are connecting from the same continent.

Based on our independent testing, itopia has discovered that latency under 60ms provides an excellent end-user experience for most Cloud Desktop workloads, and under 200ms provides an acceptable experience. You can use a simple utility such as GCP Ping to estimate latency from your location to various GCP regions; for latency-sensitive workloads such as graphic design or 3D modeling, itopia recommends performing more thorough testing.

Networking Requirements

When creating a new CAS deployment, the default option is to create a new VPC network for all resources in the deployment. A VPC network is the primary boundary of network connectivity in Google Cloud; resources assigned to different VPCs cannot communicate with each other unless the networks are manually connected via VPC peering, and cannot communicate with an on-premises (or co-located) network unless a VPN or direct interconnect is configured.

Thus, the default CAS configuration provides the most secure option for network isolation. However, there are instances where this configuration may not be suitable: Cloud Desktops need to access other resources such as existing AD domains or application servers, administrators want to leverage an existing network topology, or compliance requirements restrict the creation of new networks. In these cases, an alternative configuration may be used.

CAS supports several networking options:

  • Isolated VPC - Deploy to a new VPC network with full isolation (default configuration)

  • Connected VPC - Deploy to a new VPC network and use VPC peering or VPNs to connect to existing networks

  • Existing VPC - Deploy to an existing VPC network in the same GCP project

  • Existing Shared VPC - Deploy to an existing VPC network in a different GCP project (via Shared VPC)

The network model you choose will primarily depend on the following questions:

  • Do you need to connect to existing resources on your private network?

    • If so, what level of integration (or isolation) do you require for your Cloud Desktop environment with your existing environment?

  • Is your existing network topology very complex, such that adding a new VPC network would require significant effort?

  • Are you using Shared VPCs?

    • If so, does your security policy allowing delegating management permissions to the CAS service account for the VPC resource?

The table below provides a comparative view of each supported network model based on the criteria above.

Decision Point

Isolated VPC

Connected VPC

Existing VPC

Existing Shared VPC

Your CAS deployment will use an existing AD, or an AD trust

Not an option

Supported

Supported

Supported

Your Cloud Desktops need to access application servers and other resources on your existing VPC networks

Not an option

Supported

Supported

Supported

Your Cloud Desktops need to access application servers and other resources on your existing on-premises/co-located networks

Not an option

Supported

Not an option

Not an option

Level of effort required to configure

Low/None

Medium

Low

High

Additional permissions required for CAS service account

None

None

None

Compute Network User on the project

Compute Network Admin if the administrator wants CAS to configure its prerequisites (otherwise a gcloud script is provided)

Level of default isolation

High

High

Medium

Low

Support for custom firewall rules

Yes

Yes

Yes

Yes

Support for custom routing rules

Yes

Yes

Yes

Yes

For most scenarios, itopia recommends either Isolated VPC or Connected VPC; this minimizes the potential for unintended interference of firewalls, routing rules, or other configuration. Unless there is a specific reason that an existing VPC must be used, allowing CAS to create a new VPC greatly streamlines the deployment process and offers the highest amount of control over the networking configuration.

NOTE: Existing VPC and Existing Shared VPC are only available in Advanced deployments.

Fault Tolerance

CAS offers several options for enabling fault tolerance for your Cloud Desktop infrastructure; fault tolerance refers to the ability for a system to continue operation in the event of a component failure. Depending on the system, fault tolerance can be enabled at multiple layers, such as an application, virtual machine, or bare-metal resource.

Resources deployed in GCP already include a level of fault tolerance at the hardware level; in the event of a disk, host server, or network switch failure, most resources in GCP can continue to operate normally with little or no disruption. However, fault tolerance at higher levels (such as the operating system and application) must be configured manually.

Selecting from a Basic, Standard, or Enterprise deployment automatically configures the fault tolerance for RDS services as described in the CAS Deployment Types and Sizing article. In an Advanced deployment, administrators can choose their fault tolerance configuration for each component of the infrastructure.

The RDS services for which CAS can provide fault tolerance are:

  • RD Broker - The RD Broker is the "coordinator" of a Cloud Desktop deployment, directing users to the correct Cloud Desktop and storing most configuration settings for an environment. Fault tolerance is achieved by deploying two RD Broker servers in each region, as well as configuring a fault-tolerant SQL server instance to host the RD Connection Broker database.

  • RD Gateway and RD Web - The RD Gateway and RD Web roles are the primary connection point for end-users accessing their Cloud desktops. These roles are co-hosted on the same server(s) in a CAS deployment. Fault tolerance is achieved by deploying two RD Gateway / RD Web servers in each region and using a GCP load balancer to direct traffic to both servers.

  • RD Session Hosts - The RD Session Host servers run the actual Cloud Desktop sessions for end users. In a Shared Collection Pool, Session Hosts are automatically fault tolerant as long as sufficient capacity exists for Cloud Desktop sessions (i.e., an N+1 or similar configuration). In a Dedicated Collection Pool, Session Hosts are not fault tolerant; if a user's dedicated host fails, a new host must be provisioned and the user reassigned.

  • Active Directory Domain Controllers - Domain controllers handle user authentication, security enforcement, and other tasks for the RDS environment. Fault tolerance is achieved by deploying two domain controller VM instances in each GCP region; Active Directory natively configures fault tolerance when more than one domain controller exists.

All services listed above are considered critical for a functional Cloud Desktop environment; if any service is unavailable, users will not be able to access their Cloud Desktops. Therefore, itopia recommends that any business-critical workloads leverage full redundancy of RDS infrastructure to ensure the highest availability for Cloud Desktops. However, for non-critical workloads such as business continuity environments or proof-of-concept labs, full fault tolerance may not be required.

However, while all services are critical, some services are easier to rebuild than others. The table below lists the relative impact and recovery effort for a non-recoverable failure of each service.

Component

Recovery Effort

RD Broker

Medium/High - If recent backups of the RD Broker server are available, the server can typically be restored without too much effort within a few hours. However, if backups are unavailable, the RDS environment for the region must be fully rebuilt and reconfigured, which can take considerable time and effort.

RD Gateway and RD Web

Low/Medium - If recent backups of the RD Broker server are available, the server can typically be restored without too much effort within a few hours. If backups are unavailable, a new RD Gateway / RD Web server can be deployed without too much effort and in a similar time frame.

RD Session Hosts

Low - If a single RD Session Host fails, it is recommended to use the Collection Pool scaling to create a new server to replace it, and then contact itopia support to delete the failed server. If the Collection Pool is using a custom image with all apps and settings preconfigured, replacing a failed Session Host should only require about 15-30 minutes. Depending on the number of Session Hosts and your user density, users may be able to continue accessing the Collection Pool while the failed server is replaced.

Active Directory Domain Controllers

High - In any situation where all domain controllers for an Active Directory domain suffer a failure, recovering the domain is a complicated and delicate process. If recent backups of a domain controller are available, the domain can typically be restored within a few hours. However, if backups are not available, it may be necessary to completely delete the deployment and create a new one. For this reason, itopia highly recommends the use of redundant domain controllers for any production CAS deployment.

However, it is important to remember that in some cases, redundant domain controllers may not strictly be necessary:

  • In a multi-region deployment, at least one domain controller is deployed to each region, so some redundancy exists even if each region only has a single domain controller

  • If using an existing AD domain, CAS can use other domain controllers in your environment until its dedicated domain controllers are restored

  • If using Managed Microsoft AD, domain controller redundancy is automatically provided by Google Cloud.

The fault tolerance model you choose will primarily depend on the following questions:

  • Will you be hosting business-critical workloads in this CAS deployment?

  • What is the recovery time objective (RTO) for the workload? In the event of a server/service failure, itopia Professional Services can typically help restore your environment within a business day, depending on the nature of the failure.

  • Will this be a multi-region deployment?

    • If so, can users access a different region if their primary region is unavailable?

  • How impactful is the additional cost associated with redundant infrastructure?

Sizing

Properly sizing your CAS deployment is an important aspect of the environment design. Finding the right size is important for ensuring your users have a good, productive experience while also minimizing cost for compute resources.

Fortunately, resources in CAS can be resized at any time, although some components might require a reboot and could result in a brief service disruption. Therefore, itopia recommends that you perform sizing calculation and validation prior to deploying your production environment.

Refer to itopia's CAS Deployment Types and Sizing documentation for more information on itopia's sizing guidelines for infrastructure servers and our predefined Collection Sizing. You should also review the Sizing Your Workloads article for suggestions on optimizing your session hosts.

Using the information in the two articles above, consider the appropriate sizing based both your initial user count and your ultimate user count. If you plan to gradually increase the number of users over time, or you intend are running a pilot or proof-of-concept, you can start with a smaller size and then increase resources as required.

Workloads

A workload refers to a set of applications and tasks that your end-users commonly perform in their Cloud Desktops. Depending on your environment, you may have: a single workload, where all users perform similar tasks and run a similar set of applications; or multiple workloads, where different sets of users require different applications and perform different tasks as part of their regular duties.

Within the context of a CAS deployment, it is often useful to consider each workload as a separate Collection Pool. A Collection Pool is a set of host servers on which users' Cloud Desktops perform their actual processing. Each Collection Pool can be configured with its own OS image that contains distinct applications and settings; each Collection Pool can also be configured with unique sizing parameters.

Collection Pools can be created, removed, or reconfigured at any time; however, it is useful to consider the distinct workloads required for your environment and plan your Collection Pools accordingly.

The number of Collection Pools you need will primarily depend on the following questions:

  • Do different subsets of your end-users use different sets of applications? If so, you can prepare different OS images with specific applications installed for different groups of users and assign a different image to each Collection Pool.

  • Do different subsets of your end-users have different performance requirements? For example, two groups may use similar applications (such as Google Chrome and Microsoft Excel), but one group may be performing basic data entry while the other group routinely performs complex calculations that can benefit from increased CPU and RAM resources.

  • Do different subsets of your end-users have different requirements for dedicated host servers? Each Collection Pool can be configured as either Shared or Dedicated; if some users require single-session computing while others can enjoy the cost-savings of multi-session computing, different Collection Pools should be used. Learn more about Collection Pool Types.

  • Do different subsets of your end-users have different requirements for their end-user experience (see below)? CAS allows you to configure different values for each Collection Pool for settings such as allowing or blocking clipboard, drive, and printer redirection and enabling non-persistent profiles. Additionally, CAS creates distinct organizational units (OUs) for each Collection Pool in Active Directory, allowing you to configure and link customized group policy objects (GPOs) to each Collection Pool.

  • Do different subsets of your end-users have regulatory or compliance requirements to leverage separate infrastructure or have "firewalls" between them? Within a single CAS deployment, some infrastructure is shared, but each Collection Pool has separate VM instances to run the computational workloads for users, and this satisfies most regulatory requirements. Additionally, custom network firewall rules can be configured to increase the isolation between users in different Collection Pools.

End-User Access

Finally, administrators should consider several factors for how end-users will access their Cloud Desktops. These settings can be changed at any time, but it is useful to understand the implications of each option and determine the best choices for your environment.

Defining your end-user connectivity primarily depends on the following questions:

  • How will end-users connect to their Cloud Desktops: using the Microsoft Remote Desktop client (or RDP-compatible third-party application), via the RD Web Client from any HTML5-compliant web browser, or a combination of both?

  • If using a Remote Desktop client, will end-users use the MyRDP portal to automatically retrieve the settings for their client? The MyRDP portal allows users to enter their Cloud Desktop username to receive a customized RDP file that includes the connectivity information for their Collection Pool and, in a multi-region deployment, automatically picks the nearest geographical region for them.

  • Will the deployment use custom domain names for end-user connectivity? Upon creation, CAS configures each deployment with a unique subdomain of cloudvdi.net and automatically configures SSL certificates to enforce encrypted connectivity. However, administrators can provide their own custom domain names for end-user connectivity (such as vdi.contoso.com). Review the Post-Deployment Tasks article for information and requirements to use custom domains.

To help answer these questions, consider the following:

  • The Microsoft Remote Desktop client is built into every version of Windows (client and server), although very old versions of Windows (Windows 7 and earlier, or Windows Server 2008 R2 and earlier) may require an update to the built-in version for the best experience. The official Microsoft Remote Desktop client is also available from the official app stores for MacOS, iOS and iPadOS, Google Android, and Chrome OS devices that are compatible with the Play Store.

  • The RD Web Client is built on JavaScript and HTML5 and offers a convenient way to connect to Cloud Desktops directly from any modern web browser. However, it has certain limitations compared to the full Remote Desktop client, most notably:

    • Mobile devices are not supported, although the client may provide limited functionality on non-Windows tablet devices

    • Drive redirection and file upload/download is not supported

    • Audio playback (downstream audio) is supported on all browsers except Internet Explorer, but microphone redirection (upstream audio) is not supported by any browser.

    • Webcam and USB device redirection is not supported by the web client.

    • UDP connections are not supported, which may negatively affect the performance of streaming audio/video content from the Cloud Desktop.

  • If users will use the MyRDP portal, they may never encounter the external domain names for their deployment; therefore, configuring a custom domain may not offer much advantage.

  • If users will use the standard RD Web portal and/or the RD Web Client, they must manually navigate to the correct URL for the deployment; in this case, using a custom external domain name might be preferred in order to maintain brand unity for your organization.

  • In a multi-region deployment, each region has its own external domain name. If users will not use the MyRDP portal, they will need to know the specific external domain name for their appropriate region.

Conclusion

itopia CAS is designed to provide a fast, easy way to create and manage a remote computing environment. However, more complex environments might require planning and perhaps an environment design document to ensure the best experience for both end-users and administrators.

Don't hesitate to contact your itopia Customer Success representative or Account Executive with any questions you might have. itopia also offers Professional Services to help with the planning, design, and implementation of your CAS deployment.

Did this answer your question?