Let’s take the flexibility and simplicity of Workspace Cloud: Applications and Desktops Service even further.
The ability to manage Citrix app and desktop delivery over multiple sites in different geographies is a frequent request. At a recent industry event, I had a number of customers approach me and share how much they value Citrix technology; however, they work for very large, globally distributed companies and they were concerned about how they would be able to deploy and manage Citrix app and desktop delivery over multiple sites in different geographies.
Once, I would have nodded my head and listened. Today, I’m happy to offer a great answer. With the Citrix Workspace Cloud Applications and Desktops Service, global companies can now centrally manage multiple application and desktop resource locations across different geographies. This is a big deal for our customers.
Workspace Cloud provides support for multiple resource locations, which enables Applications and Desktops Service customers to manage application and desktop workloads across multiple datacenters or branch offices, all from a single platform.
Let’s walk through a few examples of this game-changing new feature:
Currently, a business firm with a New York headquarters office and a major California sales office is managing the virtual applications for each site independently. Now with Workspace Cloud, the IT administrator can consolidate the dispersed management of the New York and California sites into one instance through the Applications and Desktops Service, in only a few simple steps.
Let’s take it one step further. What if this company wanted to expand and add a Houston site? As the business grows over time, the firm can now determine if building a new Houston datacenter is the best choice, or decide if hosting those apps and desktops in a public cloud would be faster to deploy and easier to manage. And when I say public cloud, I am saying that Workspace Cloud empowers the firm with choice of public cloud vendors. My colleague Brett Waldman does a great job explaining the changes in business dynamics and need of flexibility in his blog – One Cloud Does NOT Fit All.
Up to this point, we’ve only spoken about the geographical dispersion of physical offices, but let’s look at this in a different way. Instead of dividing employees by location, what if we look at dividing them by job role? For instance, this same firm had an on-premises datacenter for full-time employees, a branch office datacenter for their call center workers (to control access to sensitive corporate data) and a public cloud to meet the scale up/scale down demand for seasonal contract workers. Previously, these different job requirements could lead to independent sites and a significant amount of effort for ongoing maintenance. With the new multiple resource locations feature included in the Applications and Desktops Service, these distributed sites can now be managed centrally through Workspace Cloud.
Let’s take a deeper look in how this functionality works.
In Citrix Workspace Cloud, a resource location is defined by your network topology and controls the communication flow between components. A branch office, a datacenter, a VLAN, or even an availability zone within a datacenter could map to a resource location. There is no hard limit to the number of resource locations that can be managed through the Applications and Desktops Service as there is no location-to-location communication. A resource location can be as large or small as you like, as long as all components within the resource location have good network connectivity and low latency. In the Applications and Desktops Service, resource locations control the communication flow between the connectors, underlying hypervisors, and Virtual Delivery Agents (VDAs) hosted on the virtual application or desktop instances. Because of this, the best practice recommendation is for every resource location to have two or more connectors for high availability.
Let’s create two resource locations for the Applications and Desktops Service.
Step 1: From the Workspace Cloud menu, go to Resource Locations. Create two resource locations using “+ Resource Locations”
Step 2: Select “+ Workspace Cloud Connector” to install two connectors in each resource location. When installing connectors select the correct resource location.
Once you have installed all four connectors, hit refresh and you will see them in the Workspace Cloud console.
Step 3: Go to the Applications and Desktops Service console, select manage and click on Zones
The first time you go to the Zones node, the first zone (the Primary Zone) will be pre-created and contain all of the Cloud Connectors.
Step 4: Rename the Primary Zone to Headquarters. At this point, all the Cloud Connectors are in this zone. Create a second zone for the Call Center and move the Call Center Cloud Connectors into this new zone.
It is important that the Cloud Connector ->Resource Location mapping in Workspace Cloud matches the Cloud Connector->Zone mapping in the Applications and Desktops Service. The mapping of connectors to resource locations also determines the auto-update schedule for the connectors. Two connectors in the same resource location will never be updated simultaneously, ensuring that the upgrade process itself does not create downtime.
The screenshot below shows the final zone configuration in the Applications and Desktops console. You may now create hypervisor connections and catalogs, and associate them with the two zones.
When building an Applications and Desktops environment with multiple resource locations, you must deploy a StoreFront site through NetScaler Gateway in order to route traffic through the closest gateway, and either use multiple URLs or Global Site Load Balancing (GSLB) in order to direct users to the closest gateway. The cloud-hosted StoreFront only supports routing traffic through a single gateway and cannot be used when gateways are deployed in multiple locations.
In addition, resource locations do not enable support for untrusted forests in the Applications and Desktops Service. Any locations that are used by the Applications and Desktops service (i.e. contain VDAs) must consist of objects from the same Active Directory domain, or domains with two-way trusts between them.