A Citrix Active/Active Deployment Part 3

I’m at the point now where the Datacenter#2 has Networking, Storage, and Hosts ready for me to use.  That means it’s VM building time.  You pretty much need the identical components you have for your existing site.  Remember the key focus here is Highly Available and reliability.  So if one datacenter goes down, the other one will be able to take over.  This means we need the same VMs with the same roles.

• 2x – Storefront Servers
• 2x – Delivery Controllers
• 2x – Director Servers
• 2x – SQL ‘Always On’ Servers
• 2x – PVS Servers
• 1x – Licensing Server

Licensing: Usually in Active/Active scenarios you would deploy a Licensing VM and allocate/purchase the same amount of Citrix licenses as the first site.  Since this wasn’t budgeted we will be using a manual failover type of approach when it comes to the licensing server. We’ll be sending both Datacenters to one licensing server.  If that site fails or the primary licensing VM fails, we will manually switch the Citrix Sites to use the backup licensing server.  So technically we will be building a VM, installing the Citrix license role, but not allocating any licenses to it.  This should pass any ‘audit’.  Note:  You technically have 30 days to get the license server up before functionality goes away.  That should be enough time to backup/restore, build new, or whatever.  This backup licensing server will most likely be used in an ‘Ohh SH!…’ moment.

Here is a blurb about ‘Grace Periods’ from Citrix docs – https://docs.citrix.com/en-us/licensing/11-14/technical-overview.html

Grace periods

If product servers lose communication with the License Server, the users and the products are protected by a grace period. The grace period allows the product servers to continue operations as if they were still in communication with the License Server. After the Citrix product checks out a startup license, the product and the License Server exchange “heartbeat” messages every five minutes. The heartbeat indicates to each that they are still up and running. If the product and the License Server don’t send or receive heartbeats, the product lapses into the licensing grace period and licenses itself through cached information.

Citrix sets the grace period. It is typically 30 days but can vary depending upon the product. The Windows Event Log, and other in-product messages, indicate if the product has entered the grace period, the number of hours remaining in the grace period. If the grace period runs out, the product stops accepting connections. After communication is re-established between the product and the License Server, the grace period is reset.

The grace period takes place only if the product has successfully communicated with the License Server at least once.

Grace period example – two sites, both using the same License Server

The connection between Site 1 and the License Server goes down causing Site 1 to go into the grace period, continuing operation and making connections. For concurrent licenses, they can connect up to the maximum concurrent licenses installed. For user/device licenses, they have unlimited connections. When Site 1 reestablishes communication with the License Server, connections are reconciled and no new connections are allowed until they are within normal license limits. Site2 is unaffected and operates as normal.

If the License Server goes down, both sites go into the grace period. Each site allows up to the maximum number of licenses installed. As above, the user/device licenses have no limit.

Storefront:  There are some key considerations when building out the storefront servers with multi-site design in mind.  Please read ‘StoreFront high availability and multi-site configuration’  – https://docs.citrix.com/en-us/storefront/3/sf-plan/sf-plan-ha.html.   Once we get everything setup, I’ll expand upon aggregating sites.  Stay tuned for a future blog post on those specifics.

When you decide whether to set up highly available multi-site configurations for your stores, consider the following requirements and restrictions.

• Desktops and applications must have the same name and path on each server to be aggregated. In addition, the properties of aggregated resources, such as names and icons, must be the same. If this is not the case, users could see the properties of their resources change when Citrix Receiver enumerates the available resources.
• Assigned desktops, both pre-assigned and assigned-on-first-use, should not be aggregated. Ensure that Delivery Groups providing such desktops do not have the same name and path in sites that you configure for aggregation.
• App Controller applications cannot be aggregated.
• Primary deployments in the same equivalent deployment set must be identical. StoreFront only enumerates and displays to users the resources from the first available primary deployment in a set, since it is assumed that each deployment provides exactly the same resources. Configure separate equivalent deployment sets for deployments that differ even slightly in the resources they provide.
• If you configure synchronization of users’ application subscriptions between stores on separate StoreFront deployments, the stores must have the same name in each server group. In addition, both server groups must reside within the Active Directory domain containing your users’ accounts or within a domain that has a trust relationship with the user accounts domain.
• StoreFront only provides access to backup deployments for disaster recovery when all the primary sites in the equivalent deployment set are unavailable. If a backup deployment is shared between multiple equivalent deployment sets, all the primary sites in each of the sets must be unavailable before users can access the disaster recovery resources.

What I did is built my new VMs, installed Storefront, and joined them to my existing ‘Storefront group’.  This way, everything would have the same names, setup, and configurations.  Afterwards, I disjoined the ‘group’ and added only the storefront servers at Datacenter#2 to a ‘storefront group’.

Director Servers:  For director you will need to follow the Multi-Site instructions – https://support.citrix.com/article/CTX136165 . The overall goal for this will be to have Director at each Datacenter be configured for ‘Multi-Site configuration’.  We will use GSLB to send users to a LB VIP at either Datacenter.

Provisioning Services: We will treat PVS as separate entities.  So build out PVS like you would normally from scratch.  Since we use Unidesk/App Layering we will setup a 2nd ‘app layering connector’ that points to Datacenter#2 PVS servers.  Now, I don’t literally have to publish the template at both locations.  ‘Publishing’ compiles all the different layers, which takes time.  So we could setup a powershell sync/transfer script to copy the VHD to the second PVS store.

SQL ‘Always On’:  Since we will be deploying a Site at each Datacenter, technically that site should have it’s own Servers.   Deploy how you would normally deploy in a standard 1 site configuration.

Delivery Controllers: At this point just build your Site as you normally would.  In another post I’ll go through our different options on how both sites will talk to Storefront, and which sets of icons will be available based on settings.  Initially, I’ll be using my homeboy’s, @ryan_c_butler, replication script to export my current Citrix sites information to Datacenter#2 Citrix site.  This is something that can also be used as a scheduled task to keep both environments in sync.

Over the next week or so i’ll be verifying normal functionality of the site, storefront, netscaler, etc…  After that, i’ll be getting into the Storeront and GSLB configurations.

Stay tuned….

Previous Posts:

Part1 – Introduction – https://verticalagetechnologies.com/index.php/2017/04/11/a-citrix-activeactive-deployment-introduction

Part 2 – https://verticalagetechnologies.com/index.php/2017/06/06/a-citrix-activeactive-deployment-part-2