As you begin your workload delivery journey, it’s important we start it on the right foot. That means touching on a couple non-VDA specific elements that need to be considered first. One of the most important conversations a good Citrix consultant has with a new customer is about the use cases you’re going to be servicing. These conversations (more than one, because customer needs, business climate, and technology evolve over time) typically lead to the definition of reasonably well-defined groups of users and apps - we call them Delivery Groups. Most of the options we’re going to break down in this section are re-evaluated for each Delivery Group and use case. It’s common for customers to have quite a bit of variation and even overlap between Delivery Groups. At the end of the day, however, the most foundational element of each Delivery Group is the mix of applications, data, and services to be provided. Once you have that defined, you can begin to evaluate the decisions laid out in this section.
For each use case/Delivery Group, start by defining the mix of apps, data, and services needed, then work your way through the following considerations to decide what delivery options can best serve each.
VDAs are managed in a resource grouping called machine catalogs. Machine catalogs are groups of virtual machine instances which serve a common use case for a group of users. They’re typically based off the same ‘golden master’ VM instance template, and inherit VM instance properties and a generalized copy of the persistent disk.
VDA Operating Systems
Windows or Linux
Now that you’ve defined the apps, data, and services required for each Delivery Group/use case, you can begin to consider what operating system is best suited for your VDAs. The most basic question: do you need Windows or Linux? This decision is often forced by the requirements of the application or set of applications you’re delivering. If the app only runs on Windows, then Windows it is! The same obviously applies if the app only runs on Linux.
Business applications are often built upon Windows, so a large percentage of Citrix virtualized apps run on Windows based VM instances on GCP. Sometimes Windows is chosen because it’s what the IT team knows, and the cost of spinning up operational competencies on a new OS like Linux is deemed too high, so Windows is used even if the application set can run on Linux. If, however, the app set can be run on Linux, it’s worth considering - much of the complexity and a good portion of the costs (Windows OS and client licenses) can be avoided.
Server or desktop OS
If you deploy Windows, the choice of server vs. desktop OS gets a bit more complicated. Both options share a common GUI, and both can present users with a virtual desktop. In fact, most Windows applications run on both Windows Server and Windows 10 desktop operating systems, though often application vendors won’t call out Windows Server support in their documentation. The most major implication of Windows Server vs. Windows 10 desktop is licensing - and it’s a large one.
Microsoft’s licensing policies are restrictive when running Windows 10 (or any other ‘desktop’ operating system) on public clouds. These policy-based restrictions can make it more expensive to run a Windows desktop OS on any public cloud, including GCP. For more information on Microsoft’s licensing policies, consult your Microsoft licensing specialist, but the following gets you started on this complex topic:
- Microsoft Volume Licensing Product Terms (April 1, 2020) - for Windows Client, Windows Server, and Windows Services.
- Microsoft Office Licensing page - get the licensing brief.
If you’re running Windows on GCP, Windows Server serves most use cases and application mixes, and you simply pay for the license usage along with instance usage. It’s often more cost effective than a Windows desktop and ends up being the choice for many virtualization systems on Google Cloud.
Shared OS (multi-user) or single user (“VDI”)
One common misconception is that Windows Server cannot serve desktop use cases, regardless of whether you are sharing the OS between multiple users or have one OS/VM instance per user. This misconception is false! When deployed in Multi-user mode (that is, RDSH role is installed), Windows Server can present users with a ‘hosted shared’ desktop. Windows Server can also be used for “VDI” use cases, and while not as cost effective or scalable as the multi-user/shared OS option, it’s a legitimate option for a single user desktop. We call this delivery model “Server VDI”.
To summarize, the following combinations of options/operating systems can be used depending upon the use case:
|Delivery Model||Single or multi-user||Common OS versions/components||Relative cost to run on Google Cloud|
|Hosted Shared||Multi-user||Windows Server (2016 or 2019), RDSH role and Desktop Experience enabled.||⭐|
|Server VDI||Single user||Windows Server (2016 or 2019), Desktop Experience enabled.||⭐⭐⭐|
|Desktop VDI||Single user||Windows 10 (BYO licensing and STN required)||⭐⭐⭐⭐⭐|
Another common mis-conception is that Google Cloud’s sole-tenant nodes (STN) are required to serve ‘desktop’ use cases. Sole tenant nodes are required to comply with Microsoft’s BYO licensing scenarios such as Windows 10 (desktop) OS. As mentioned above, Windows Server can be used to deliver a single-user desktop (“Server VDI”) in addition to a multi-user desktop (Hosted Shared). Sole tenant nodes can also be used for Windows Server instances when you’re bringing your own Windows Server licensing.
Most flavors of Linux are multi-user capable out of the box. As such, they can be deployed in either Hosted Shared or “Server VDI” models, with similar relative cost implications.
To help with the decision making process, the following decision tree compares Hosted Shared Desktops (Server OS multi-user desktops) to VDI Desktops. The tree doesn’t explicitly differentiate between client VDI and server VDI models, but the decisions presented are valid for both. When a use case suggests VDI is the appropriate delivery model for your workload, Server VDI ought to be considered wherever possible for running on Google Cloud.
Published desktops or published apps
At the end of the day, the virtualized apps you deliver to users in a Citrix virtualization system run on VDAs. You have options for how you present them, which determines how users interact with them. You can present the user with, or “publish” individual applications and files. You can also present them with a desktop on which they interact with applications and data.
Example: a hosted shared desktop, being presented as a windowed app in Citrix Workspace app for Windows.
There’s more to this choice (and many customers use both), but here’s an attempt to summarize:
Published desktops (both hosted shared and VDI):
|+||Give users a familiar metaphor for interacting with the apps and data on the system. Can be simpler for users to grasp and get productive using. Great for delivering flexible environments with many applications.|
|-||Users expect things to work like they do on a desktop. You are working harder to balance security with access and functionality, and you are managing a Windows desktop. User profiles, application settings, data storage, and desktop configuration management become critical. Doubly so if users expect settings to roam between regions.|
|-||Require more VM instance resources - the Windows Desktop services consume more resources for each user vs. published apps.|
|+||Published apps are often easier to secure, require less resources to deliver, and can provide users with a simpler user experience. Citrix calls this “seamless windows”.|
|-||User experience can get complicated with larger numbers of published apps.|
|+||Still requires management of user profiles, application settings, and data storage, but often simpler and with more flexibility in execution relative to published desktops.|
|+||Require less VM instance resources vs. Windows Desktop presentation. Multiple published apps usually run inside the same session - a feature Citrix calls session sharing.|
Pooled or persistent
This choice is another property of the machine catalog and is defined upon catalog creation. The hosted shared delivery model usually uses pooled/non-persistent VDAs, but both VDI models can use either pooled or persistent machine catalogs. With the pooled model, OS instances are reset by MCS on logoff or reboot of the VDA. This model ensures that users get a ‘clean’ system image, which is in turn based on your template or ‘golden image’ VM instance(s) and snapshots of it’s persistent disk. They’re referred to as ‘pooled’ as a pool of VDAs are maintained and users are dynamically connected to an available/unused VDA in the pool. User settings and data can be managed several different ways. With pooled VDAs, they’re handled such that the user gets the same configuration and experience regardless of which VDA they’re logged into. See user environment/settings management in this document for more details on this topic.
Persistent machine catalogs contain VDA instances which are assigned to individual users, and they persist between reboots. This model is useful for scenarios where users need to install their own applications (such as developer environments) and use cases where necessary applications are not multi-user compatible.
Pooled instances tend to be the easiest to manage over time since Citrix’s MCS can update the system disks attached to pooled instances with a few clicks. Capacity and cost management also tends to be more effective since an idle pool of instances can serve many users. Pooled instances are a bit less flexible than dedicated since changes to pooled instances don’t usually persist between reboots. Technologies such as Citrix User Personalization Layer can be used to persist user initiated changes across sessions on different pooled VDAs, though it’s only compatible with single user “VDI” use cases.
Persistent instances can be simpler to deploy, but tougher to manage over time since you have to handle OS/application patching, upgrading, and maintenance inside the VM. It can also be more expensive from a cost/capacity perspective as it is often tough to predict when a user will log on. This means that users must wait while their instance is started, or administrators must keep them running during time windows where each user is expected to log on.
Managed or unmanaged
Catalogs created and managed by MCS can contain persistent or non-persistent clones of template (or ‘golden master’) VM instances. Machine catalogs can also be provisioned with another process or technology. Either way, you want to make sure they’re created as power managed:
If you don’t use power managed machine catalogs, key features such as Citrix Autoscale will not work, and you won’t have help managing costs and capacity. Using MCS for VDA fleet provisioning and management brings a host of useful benefits to administrators, but ‘unmanaged’ VDAs - those provisioned outside of Citrix - can also be used. We cover those benefits in Fleet and Image Management later in this guide.
Certain types of applications deployed on VDAs can benefit from GPU resources if they’re available to the VM instance. All three delivery models (hosted shared, server VDI, and desktop VDI, for both Linux and Windows) can use NVIDIA accelerated GPU instances for graphics workloads on Google Cloud. These Virtual Workstation GPUs can be attached to general-purpose N1 machine types for graphics intensive workloads such as 3D visualization, chip design, CAD/CAM, graphics and video editing, and include the required GRID license.
With the appropriate NVIDIA GRID driver installed on the instance, Citrix’s VDA software detects GPU presence and configures itself appropriately.
Citrix’s HDX display protocol stack does lots of auto-detecting and adapting on the fly to provide the best possible user experience. However, it also tries to balance performance, responsiveness, and richness of the UX with bandwidth consumption. As such, graphics intensive workloads often benefit from some fine-tuning to get the balance right. See HDX Graphics Overview for more information. Note that Citrix does provide a policy template called “Very High Definition User Experience” (as outlined in Baseline Policy Design). This template can be used as the starting point for fine-tuning to your specific environment.