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.

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

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:

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

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:

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.

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:

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

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

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.

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:

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.

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

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.

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:

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:

To help answer these questions, consider the following:

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.