Reference Architecture: Multi-Cloud, Hybrid-Control Plane Deployments

Overview

This guide assists with the architecture and deployment models associated with a hybrid deployment of Citrix Virtual Apps and Desktops (CVAD) and Citrix Desktop as a Service (DaaS) and a multi-cloud deployment across multiple public cloud providers.

With Citrix’s renewed focus on hybrid environments and Universal subscription, this opens up the door for different kinds of environment configurations across both our on-premises Citrix Virtual Apps and Desktops and Citrix Cloud platforms for more customers. Alongside the Citrix platform, hyperscalers such as Azure, AWS, and GCP can deploy Citrix resources with greater agility and scalability than traditional data centers. This document provides guidance on critical architecture design considerations necessary to successfully deploy Citrix virtualization technologies for these scenarios.

Use Cases

Hybrid and multi-cloud environments can help address various needs in a Citrix environment. This section describes some use cases that can benefit from hybrid, multi-cloud deployments.

Why hybrid control planes?

For some customers, hybrid is a step to a full cloud IT environment. For others, hybrid is the intended destination. Hybrid with Citrix Virtual Apps and Desktops and Citrix DaaS offers the control and granularity of on-premises infrastructure and the flexibility and scalability that are associated with cloud offerings. Some major use cases for a hybrid Citrix environment are:

• Control planes for different use cases. Some use cases exist where Citrix Virtual Apps and Desktops is preferable for deployment. Some examples include environments with stringent change controls or that cannot be internet accessible for security reasons. Resources with these requirements can be maintained under IT control while other resources can be migrated to Citrix DaaS.

• Citrix DaaS for easier scalability. Because Citrix manages all the infrastructure associated with Citrix DaaS, it is much easier for customers to scale up in those environments. Customer administrators wouldn’t have to worry about deploying more Delivery Controllers or SQL databases for additional users.

• Access to Citrix Cloud service offerings for on-premises use cases. While Citrix has brought some cloud offerings to the on-premises platform (Web Studio, Autoscale, Secure Private Access), several services are only available via the Citrix Cloud solution. These solutions include Analytics, Global App Configuration Service, and Session Recording service. To use these services, at minimum, a hybrid environment is required.

• Part of a complete transition to Citrix DaaS. Many customers have used Citrix for decades and have mature, complex deployments. When transitioning to Citrix DaaS, it is not feasible to migrate everything simultaneously. A hybrid Citrix Virtual Apps and Desktops/Citrix DaaS environment can help smooth the transition to a full Citrix DaaS environment by enabling administrators to migrate the environment in phases.

Why Hybrid or Multi (Public and/or Private) Cloud?

Public clouds offer ease of scalability and global availability. While many companies primarily host their environment on one public cloud platform, there are some advantages to using multiple public clouds. Some benefits include:

• Disaster Recovery and High Availability. Placing infrastructure in multiple public clouds increases the availability of the environment if any cloud provider has a major outage.

• Cloud feature and location parity. Different cloud platforms have different strengths and different services that they offer. Services needed for IT or application functionality may reside in different public clouds. For example, Citrix Provisioning is currently only available in Azure and GCP. Citrix is actively working on developing feature parity for the public clouds. Also, public cloud providers have different location availability globally, and due to security and compliance regulations (such as GDPR), companies may have to keep data in certain regions.

• Vendor lock-in mitigation. Vendor lock-in refers to when customers are stuck with a vendor because the cost of switching to another vendor is too high or too labor-intensive. This situation puts the customer at risk of declining service quality or a significant cost increase. Using multiple vendors reduces the risk of vendor lock-in.

Questions for Guidance

This section lists some key questions to consider when deciding whether to move to a hybrid or multi-cloud environment.

Hybrid Control Plane

Hybrid or Multi-Cloud Environment

Conceptual Architecture

The conceptual architectures provided in this section show baseline architecture for deploying a hybrid or multi-cloud environment. These architectures show the infrastructure that is needed from a Citrix perspective. The diagrams are not intended to be all-encompassing in terms of required infrastructure.

Citrix Virtual Apps and Desktops & Citrix DaaS Hybrid Environment

This section shows the two primary configurations for a Citrix hybrid environment - on-premises vs. Citrix Cloud access tier. Refer to the Reference Architecture on Citrix DaaS for more detailed information about Citrix DaaS architecture.

StoreFront & NetScaler

There are several reasons to maintain an on-premises access tier - such as advanced StoreFront customizations, Local Host Cache, and NetScaler features such as load-balancing. To display both Citrix DaaS and Citrix Virtual Apps and Desktops resources, Delivery Controllers and Cloud Connectors can be added as ‘Delivery Controllers’ within StoreFront stores. StoreFront can also aggregate multiple Citrix Virtual Apps and Desktops sites and Citrix DaaS tenants, which can simplify resource access for end users.

Workspace & Gateway Service

Citrix Workspace and Gateway Service are Citrix DaaS's turn-key cloud access solutions. A Citrix Cloud-hosted access tier can simplify deployments by removing the need to maintain access infrastructure, provide inherent resiliency, and achieve faster deployments. The on-premises site needs to be mapped to display Citrix Virtual Apps and Desktops resources in Workspace.

Multi-Public Cloud Resource Locations

When using multiple public clouds, each public cloud subscription is typically treated as an additional zone or Resource Location in the Citrix Virtual Apps and Desktops/Citrix DaaS architecture. Each public cloud resource location requires at least one set of Cloud Connectors (or Delivery Controllers if connecting to an on-premises Citrix Virtual Apps and Desktops site). This document is designed to cover a partial list of requirements for using Citrix DaaS with public cloud. For further details, reference the Azure, AWS, and GCP reference architectures. This specific architecture uses an on-premises access tier, but this configuration can also be created with a Citrix Cloud based access tier (Citrix Workspace).

Deployment Strategies

When moving resources to Citrix DaaS or public clouds, there are different kinds of strategies that can be used.

Greenfield vs. Extension vs. Cloud Transformation

There are three main deployment scenarios: greenfield, extension, and cloud transformation.

Greenfield deployments involve net-new environments and require development from a clean slate. The benefit of these types of deployments is that they aren’t complicated by legacy software and can be optimized for specific use cases. These projects have higher startup costs and knowledge requirements as everything is being built from the ground up. For this reference architecture, any customer new to Citrix (Citrix Virtual Apps and Desktops and Citrix DaaS) or public cloud would be considered a greenfield deployment.

Extending deployments involves customers with on-premises footprints looking to extend them into the cloud. This approach introduces the scalability and flexibility of cloud products while maintaining the security and control of on-premises control planes and data centers. Extending the environment introduces the complexity of managing two different environments and higher infrastructure costs for both on-premises and cloud control planes and resources. For this reference architecture, this scenario would include a customer with an on-premises Citrix Virtual Apps and Desktops site and resources looking to extend the deployments into Citrix DaaS and public clouds while maintaining some on-premises infrastructure.

Cloud transformation occurs when a company wants to migrate existing workloads (including data) from one IT environment to another - commonly between data centers and public clouds. Cloud platforms allow companies to offload their hardware maintenance and upgrade costs to cloud vendors and introduce the scalability and services of public cloud offerings. When fully migrating to cloud offerings, it’s important to reevaluate the environment architecture to take full advantage of them. In the context of this architecture, cloud transformation deployments include customers looking to migrate fully to the Citrix DaaS platform and public cloud hosting.

Deploying Resources

A significant decision that needs to be made when moving to a hybrid model is where resources will be hosted and brokered.

Regarding hosting, resources can be hosted on-premises and/or in multiple public clouds. The main reasons for hosting the same resources in multiple locations are high availability and disaster recovery. That way, if one resource location were to go down, end users can still access resources from secondary sites. An additional use case is increasing proximity to resources - by making applications available in multiple geographic regions, you can reduce the latency between end users and their resources. When making resources available from multiple regions/data centers, it is essential to understand what user/application data must be replicated for functionality.

For brokering, a VM can only be brokered by one site at a time - either Citrix Virtual Apps and Desktops or Citrix DaaS. If the same resource needs to be available from Citrix DaaS and Citrix Virtual Apps and Desktops, duplicate resources must be deployed for each site. The main use cases for brokering the same resource from multiple sites are DR or migration from Citrix Virtual Apps and Desktops to Citrix DaaS. For scenarios where duplicated resources aren’t required, a decision must be made whether to broker via Citrix Virtual Apps and Desktops or Citrix DaaS. Citrix Virtual Apps and Desktops allows for more granular environment controls. Controls include monitoring the server health of Delivery Controllers/SQL, updating on your own schedule, and locking the environment for no Internet access. Citrix DaaS allows for easier access to the latest features and reduces the infrastructure and management overhead of sites.

High Availability & Disaster Recovery

For a hybrid Citrix strategy, it’s important to know what the HA and DR options are.

For environments using a fully on-premises access tier (StoreFront and NetScaler), Local Host Cache is the HA solution. The Local Host Cache (LHC) feature allows brokering operations in a site to continue when an outage occurs. An outage occurs when the connection between a Delivery Controller and the site database fails in an on-premises Citrix environment. LHC engages when the site database is inaccessible for 90 seconds. LHC allows end users to connect to resources even when the site is down. If using LHC with Citrix DaaS, there’s an additional recommendation to enable StoreFront Advanced Health check. This allows StoreFront to check all Resource Locations in Citrix DaaS for an application during LHC.

Service Continuity is the HA option for environments using a Citrix Cloud-based access tier. Service Continuity allows users to continue to access their resources during a Citrix Cloud outage if the user device maintains a network connection to a resource location and they’ve logged in before and downloaded a connection lease. Service Continuity uses Workspace connection leases to allow users to access apps and desktops during outages. Workspace connection leases are long-lived authorization tokens securely cached on the user’s device. Service Continuity is disabled by default but can be enabled within the Workspace Configuration tab in Citrix Cloud. It’s important that the environment meets the Service Continuity requirements. Service Continuity does not support all environment configurations. For example, it does not support kiosks, NetScaler Gateway as an ICA Proxy, or thin clients. When choosing an access tier option, evaluating whether Service Continuity supports your intended use cases is critical.

For DR, it’s necessary to have resources available from multiple locations. For Citrix Virtual Apps and Desktops, DR design requires separate Sites. In Citrix DaaS, DR requires separate additional, Resource Locations. Failover can vary by environment but is often managed at the access tier level. For on-premises access tiers, failover at the NetScaler level is handled via manual failover or GSLB. At the StoreFront level, multiple sites (such as primary and DR) can be mapped into each Store, and user mappings can be used to assign failover order. For a cloud-based access tier, Gateway Service is a highly available service with multiple points of presence (PoPs) around the globe. You can configure the failover between the different zones by configuring zone preferences for resources. Whether you’re using Citrix Cloud or Citrix Virtual Apps and Desktops, you can enable seamless failover of users. Depending on DR requirements, app or user data may need to be replicated for failover functionality. For more extensive information regarding Disaster Recovery design, reference the Design Decision documentation. This documentation includes considerations for Citrix Virtual Apps and Desktops, Citrix DaaS, and public cloud.

Automation & Infrastructure as Code

Infrastructure as Code is an IT methodology of managing and deploying infrastructure through code instead of manually. This code helps teams automate repetitive tasks and streamline deployments. Citrix has both PowerShell SDKs and REST APIs available for Citrix DaaS and Citrix Virtual Apps and Desktops to automate your deployments. These tools can be used to automate infrastructure deployments and image management. It’s important to note that the Remote PowerShell SDK for Citrix DaaS differs slightly from the SDK for Citrix Virtual Apps and Desktops. Visit Developer Docs for more information and examples of how to use our APIs.

Supporting Infrastructure Decisions

When evaluating different environment configurations, it’s critical to understand how the architecture impacts the environment's infrastructure. This section discusses some important considerations when deploying a hybrid or multi-cloud environment. This isn't an exhaustive list of all decisions to be considered.

Virtual Delivery Agents

Designing the VDA environment correctly is essential for a good user experience. This section details multiple factors that must be considered for a successful VDA deployment.

Hosting Connections

Hosting connections allow Citrix Virtual Apps and Desktops and Citrix DaaS to communicate to hypervisors and/or public cloud platforms to deploy and power manage machines. When deploying connections to on-premises hypervisors, using an administrative account with appropriate permissions is necessary. Refer to the product documentation for detailed permissions for your specific hypervisor. When creating these connections, it’s required to specify the storage to be used by VMs and the network segments. If you deploy different types of machines on different storage devices or networks, you can create separate hosting connections for that resource location.

When creating hosting connections to public cloud, it’s important to be aware of the subscription limits for the public cloud providers. These limits are the Citrix recommended maximums for a single public cloud provider subscription. For more details on public cloud limitations and recommended subscription/account configurations, review the information in the Azure, GCP, and AWS reference architectures. Citrix recommends a hub-and-spoke model for larger-scale deployments, where VDAs are distributed across multiple subscriptions and hosting connections. Each subscription needs its own hosting connection. When creating a public cloud hosting connection, the connection needs the appropriate permissions on the public cloud side to power manage the environment. If you allow Citrix DaaS/Citrix Virtual Apps and Desktops to create the Service Principal, it creates a Service Principal with the Contributor role. If you want to have a principal with fewer permissions, you can pre-create one with the minimum required permissions (AWS, Azure, GCP) before creating the hosting connection.

Citrix DaaS Limits

When building out deployments with Citrix DaaS, it’s important to design per Citrix DaaS limits (such as hosting connection limits mentioned in the previous section). There are limits to the total number of VDAs brokered by Citrix DaaS (in total and by Resource Location) and limits on other configurations like domains, Catalogs, Applications, and groups. If your planned deployment exceeds these limits, the environment must be rearchitected to be supported by Citrix DaaS. You can also contact your Citrix representative for assistance.

Storage

Many public cloud vendors offer the ability to stand up your own file server, storage as a service, and third party storage offerings (for instance, NetApp). Choosing appropriate storage options for both VM and user data storage is important.

Public cloud providers offer different storage tiers for VM disks, which usually include standard/premium SSD and HDD offerings. The tier of storage needed is driven by user/application needs in the environment. Testing is always recommended to evaluate the needs of the environment. If using MCS, the MCSIO cache can improve performance when using standard SSD storage. When migrating VDA images to a public cloud (or even between public clouds), the Citrix Image Portability Service can move the images to cloud storage.

When storing user and application data, this data can be stored on either self-managed file shares or service offerings by the public cloud vendor. See the public cloud reference architectures (Azure, AWS, GCP) for more specific information about the options on each cloud. If you plan to use multiple cloud resource locations in either active/passive or active/active configurations, it’s essential to have cross-cloud data replication in place to replicate user data. When replicating data, it’s important to note the Microsoft-supported DFS configurations.

Sizing

Sizing VDAs and infrastructure servers correctly is essential for a good user experience and to optimize costs. There are several factors to consider when sizing infrastructure servers, such as hardware, system requirements, and the number of users. Regarding VDAs, factors include hardware, expected workload, and application resource requirements. Sizing is not a one-size-fits-all recommendation, and it’s recommended to monitor your environment performance on an ongoing basis to adjust sizing as needed.

For on-premise deployments, see product documentation for minimum system requirements for Citrix infrastructure servers. For optimal Local Host Cache functionality, Citrix recommends that the Delivery Controllers use multiple cores per socket due to LocalDB. For information on sizing VDAs, refer to our Design Decision on scalability. If you oversubscribe CPU resources for VDAs, it is highly recommended to test any desired configuration and monitor CPU contention. CPU contention is a measure of how long VMs have to wait to use CPU resources, and high CPU contention can cause performance degradation. For more information on VDA sizing, reference this blog.

In public cloud environments, you pay for all the resources consumed by the environment. Therefore, the smallest instance sizes are recommended to meet environment requirements. Citrix has various articles available that discuss recommended sizing on Azure, AWS, and GCP. Cost management for public cloud VMs will be discussed in the next section.

Cost Management

Cost is one of the largest considerations when moving to a public cloud. In an on-premises data center the costs are upfront in obtaining hardware. Public cloud costs are based on how many resources are consumed and thus can vary and are billed over time. There are several tools to implement to reduce cloud costs.

Cloud providers typically have two billing options: on-demand or reserved instances (or committed instances in the case of GCP). On-demand means that you’re paying anytime a machine is online. The benefit of this model is that you’re only paying for exactly what you need. However, if your workloads in the cloud are more predictable (and are online most of the day), then reserved instances provide a cheaper option with guaranteed capacity. Refer to our GCP Cost Optimization article for an example comparison of cost. Reservations have a cost determined in advance and last for 1 or 3 years. Reserved instances work best for workloads with predictable capacity (like infrastructure servers that need to run 24/7), as you pay for the reserved instances regardless of whether they’re consumed. It is important to note that you’re paying only for instance capacity upfront for reserved instances. Other services, such as storage, are separate.

Another way to limit cloud costs is to use a cloud-bursting model. Cloud bursting refers to spinning up public cloud machines only once the on-premises data centers have reached capacity. This approach allows companies the flexibility to spin up more machines quickly without investing in hardware that isn’t needed for normal operations. It also allows administrators to limit cloud usage to what is needed to support workloads without constantly having to run cloud instances. If you plan to use cloud bursting, it’s important to note that boot times in public clouds can vary based on multiple factors such as available hardware and reserved capacity. It is recommended to contact your public cloud provider if you have questions about boot times.

Citrix also has a tool to manage public cloud costs known as Citrix Autoscale, which can proactively power manage your machines to balance costs and user experience. Autoscale is available in Citrix DaaS and Citrix Virtual Apps and Desktops 2305 and later. Autoscale allows for configuring machine schedules at a delivery group level and capacity buffer settings to increase VMs as demand increases. Dynamic session timeout allows for more aggressive draining of sessions and cost reduction. Visit the product documentation and Tech Brief on Autoscale for more detailed scenarios and advanced configurations. For further reading on cost optimization with Citrix, reference our cost optimization article on GCP, design decision, and blog.

Because Citrix has extensive support for resource locations across multiple hypervisors and hyperscalers, customers can spin up and use resources wherever it is cheapest for them without impacting the end users.

Identity & Authentication

Identity and authentication management (IAM) is crucial to ensure that the right users get access to the right resources. Regarding hybrid and multi-cloud deployments, there are some additional topics to consider when determining your IAM strategy.

StoreFront vs. Workspace Authentication

This article previously discussed other considerations when choosing between StoreFront and Workspace. There are also differences in authentication between the two access methods. Both StoreFront and Workspace support LDAP, SAML 2.0, and Gateway as authentication methods. StoreFront also supports smartcards (like Imprivata) and domain-passthrough authentication. You need to evaluate which solution supports your authentication requirements.

Another key difference is that StoreFront allows for multiple authentication options within one Store and different authentication options for different Stores. With the release of the Adaptive Authentication service, you can now configure advanced nFactor flows for Workspace and enable multiple authentication options for the Workspace Store. However, this configuration applies to the singular Workspace store, as multi-store functionality isn't currently available in Workspace.

Cloud Identity

Domain-Based Identity

The traditional method to handle identity management in IT environments includes using domain services. All public cloud providers provide the ability to spin up a Microsoft Active Directory Domain Controller server and extend your domain into the cloud via replication. Having a locally accessible domain service in the cloud is crucial for fast and reliable authentication of cloud resources. Public cloud providers provide guidelines on how best to deploy AD DS on their platforms, Refer to documentation from Microsoft, Google, and Amazon for their leading practices.

In addition to self-managed AD DS, public cloud providers offer a managed version of AD DS. These versions offer the traditional benefits of managed services - less maintenance work and management on the customer’s end. There are some limitations. For example, with AWS and GCP Managed AD, you lose super-user accounts like domain administrator and enterprise administrator - the latter of which is needed for FAS deployments. Refer to documentation from Microsoft, Google, and Amazon for their leading practices and recommendations. You can also refer to our other reference architectures for more in-depth analyses of domain considerations.

Non-Domain-Based Identity

Alongside traditional AD, Citrix DaaS also supports other identity options. Entra ID (formerly known as Azure AD) is an Azure cloud-based identity and access management service. Azure AD enables access to external resources, such as Microsoft 365 and other SaaS applications. Citrix DaaS supports Entra ID joined VDAs and hybrid (AD and Entra ID) joined VDAs. Citrix DaaS also supports non-domain joined VDAs. These services are not supported by Citrix Virtual Apps and Desktops.

See our product documentation and blog for more information.

Networking

Well-configured networking is essential to allow seamless end-user and machine connectivity, in addition to ensuring that the security posture is maintained. When moving to a cloud-based architecture, there are some additional considerations from a networking perspective.

Data Center to Cloud Connectivity

When deploying in a hybrid model, your public cloud resources need to be able to communicate with on-premises infrastructure. Whether for AD replication or application traffic, on-premises resources need to be able to route into the cloud. The primary customer connectivity considerations are bandwidth, latency, security, and cost. In a hybrid cloud deployment, there may be scenarios where internal users require their ICA traffic to go through this connection to get to their Citrix apps in the public cloud. Therefore monitoring its bandwidth is critical. Cloud providers offer multiple tiers of options to meet these needs.

The main options are usually VPN or direct fiber connections between the data center and the cloud provider’s access point (such as ExpressRoute for Azure or DirectConnect for AWS). VPNs are cheaper and faster to configure but are sent over the internet with less bandwidth and, therefore, more unpredictable performance. Direct fiber connections are more expensive and take longer to set up but are private with the lowest latency possible. Fiber connections are recommended for production environments. VPN connections can be sufficient for test or POC use cases.

Inter-Cloud Connectivity

There are several reasons why you might need connectivity between two or more public cloud providers, such as syncing user and application data. There are three main options for connecting your cloud providers: VPN, customer-managed direct routing, or third party-managed direct routing.

VPN is a simple and fast way to connect to your public clouds. However, they have limited throughput compared to direct connections and are subject to the public cloud vendors’ data transfer fees. The traffic is also routed over the public internet, which may not be desirable for certain workloads because of security and performance reasons.

An alternative option is to create direct connections to your public cloud providers directly from your data center. This connection allows for fast, high-throughput, private connections directly from the data centers to the public cloud. It also allows you to control the routing and security configurations. However, traffic that needs to go between the public clouds is routed through the data center, which is inefficient and adds latency to all inter-cloud communication. It also requires time for the direct connections to be configured to the data center.

The third option is to use a cloud exchange to bridge the routing between two public clouds. In this option, the direct connections are routed directly to a third-party vendor instead of through the customer data center. This option reduces the time to configure, as the vendor already has direct connections to the public clouds. However, this requires interfacing with an additional vendor and having more limited control over the network.

Intra-Cloud Connectivity

When connecting resources inside a single public cloud, public cloud vendors have similar options. Within one subscription, network groupings such as Virtual Networks (in Azure) or Virtual Private Networks (in AWS) are equivalent to network segments on-premises with the ability to create and assign subnets and IP addresses. Other ACLs can be created using security groups to control ingress and egress. Reference the documentation from your public cloud provider for more specifics about their networking options.

Often, public cloud deployments span multiple subscriptions and multiple regions. By default, these subscriptions are not routable to each other. Connecting subscriptions requires peering your virtual networks together to allow those networks to be routable to each other.

Summary

As you can tell, there are many options for where to take your Citrix deployments. From Citrix Virtual Apps and Desktops to Citrix DaaS, and public cloud to data centers, our products can meet your environment where it’s at and where you want to go. It just takes a little planning and design to ensure that the right architecture is in place to support your end users and IT teams to do their best work.