A Citrix Active/Active Deployment – Part 4

  • 0

A Citrix Active/Active Deployment – Part 4

The last couple weeks have been a hoot.  Here’s the progress that’s been made.

  • XenServer hosts have all been setup (running 7.1)
  • Storage (FC) and NAS have been setup
  • All the VMs have been built, joined to the domain, patched, and prepped.
  • The FMA Site has been configured and settings have been replicated (see ‘delivery controller‘ section)
  • PVS Site has been setup
  • Storefront has been setup
  • Netscaler SDX/VPX have been setup

As you can see we pretty much now have the same components/VMs/Roles in each datacenter.  Interesting that a new Citrix blog post was released talking about Site design (Better than Ever, Xenapp/Xendesktop Site Design (v2017).  This post summarizes some pros and cons on 1 site designs and 2 site designs.  We are still moving forward with the 2 site design approach as it is geared up for the best flexibility, high availability, and stability.

the MyCUGC site has an interesting conversation that talks about some different active/active and active/passive scenarios.  This is worth a read. https://www.mycugc.org/p/fo/st/per=10&sort=0&thread=2096&p=1

In this post I’d like to focus on Storefront configuration.  For the initial deployment I created two Storefront VMs, installed Storefront, and joined them to my existing Storefront server group.  This way all the existing settings propagate to these new VMs.  I thought this was an easy option because the Stores need to have identical names and since all the rest of the settings are pretty much the same, it was just easier.  Here’s an article (https://docs.citrix.com/en-us/storefront/3/sf-plan/sf-plan-ha.html) that describes the caveats.  After the propagation, I removed both new VMs from the ‘storefront group’.

We now have a couple things to address:

  1. Aggregation of resources
    1. Export, Edit, and Import of Subscription database file
  2. Multiple Netscaler Gateway per Store
  3. Subscription Synchronization
  4. STA

Aggregation of Resources

The aggregation of resources means Storefront will ‘sort’ through the published apps/desktops in each Site/Farm and present them as a single resource.  For instance in both Sites you have a published Desktop called ‘Administrator Desktop’.  Without aggregating the two Sites/Farms you will see two separate icons, one from each Site.  These icons are usually denoted by the name + (1) or (2) next to it (Ex: ‘Administator Desktop (1)).

What we want to do is aggregate these resources so the user is only presented with one icon, ‘Administrator Desktop’.  In an active/active scenario when User1 clicks on the published resource it launches in Site1.  When User2 clicks on the published resource it launches in Site2, and so on and so forth.

Citrix CTA, George Spiers (@JGSpiers), has a great article on this – http://www.jgspiers.com/storefront-high-availability-optimal-routing/.  He explains what each checkbox does and how it affects the aggregation of resources.  One thing to note is that some default functionality has changed in the ‘Assign Controllers to the User Groups’ area.

Old:

This talks about the order of the Sites to be used in a ‘Failover’ fashion

New:

this talks about the order of the Sites to be used in a ‘random order’.  This 2nd picture is how I have my Stores configured.

I’m using Storefront 7.15 LTSR and from what I can tell George was using Storefront 3.8.  Entering both Sites in this location gives a true balance of resources.

For the aggregation of resources I’m just using the ‘Load balanced’ configuration.  As i still want to be able to publish unique resources at each Datacenter.  I’m guessing this is the more common option and provides more flexibility on on being able to publish specific apps in a specific datacenter, as well as troubleshooting application launches at both datacenters.

XD7.6 is at Datacenter#1 and CTXONE is at Datacenter#2.  Since XA6.5 is being dcommed soon, we will not be configuring it in an HA/GSLB fashion.

           Export, Edit, and Import of Subscription database file

Basically what happens here is, if you enable Storefront aggregation on an existing Storefront server, the subscriptions get tagged with a ‘DefaultAggregationGroup.\’ instead of the ‘Site/Farm’ name.  So what you have to do is

  1. Before you enable aggregation, export the subscription database file – https://support.citrix.com/article/CTX139343?_ga=2.209223634.1931658170.1508160390-868616312.1493145342
    1.  Add-PSSnapin Citrix.DeliveryServices.SubscriptionsManagement.Commands
    2. Export-DSStoreSubscriptions –StoreName StoreName –FilePath DataFile
  2. Edit the file by doing find/replace
    1. Find/Replace entry for the sitename
      1. Find: SITE-NAME.       (this is your XA/XD 7.x Site Name)
      2. Replace: ‘DefaultAggregationGroup.\’
    2. Using Notepad++ do a Find/Replace on all lines for
      1. find: \$[A-Z][0-9]*(-[0-9]*|[0-9]*)
        1. What this does is remove any of the $**** entries that is used.  You mostly see this in 7.x Sites.
      2. replace:
  3. Enable aggregation
  4. Import the new file using the commands from the website above
    1. Import-DSStoreSubscriptions –StoreName StoreName –FilePath FilePath

You’re subscriptions should now be working as normal.

Before:

Notice i also have a 6.5 farm in my storefront group. Since this farm isn’t being aggreated the tags don’t change at all.  So you shouldn’t have to worry about any of those entries.

After:

Multiple Netscaler Gateway per Store

You basically have two different sets of Netscalers trying to access the same store using the same URL.  So how does Storefront known which Netscaler you are coming from to perform the Authentication?  For this you need to configure the ‘VIP’ and Callback on the specific entry in Storefront.  Carl Stalhood has some good documentation on this here – http://www.carlstalhood.com/storefront-config-for-netscaler-gateway/#gslb

Subscription Synchronization

Tips from@CStalhood http://www.carlstalhood.com/storefront-subscriptions/:

  • The store names must be identical in each StoreFront server group.
  • When adding farms (Manage Delivery Controllers) to StoreFront, make sure the farm names are identical in each StoreFront cluster (server group).
  • Load balance TCP 808 for each StoreFront cluster. Use the same VIP you created for SSL Load Balancing of StoreFront. Each datacenter has its own VIP.
  • Run the PowerShell commands detailed at Configure subscription synchronization at Citrix Docs. When adding the remote cluster, enter the TCP 808 Load Balancing VIP in the other datacenter. Run these commands on both StoreFront clusters.
  • Don’t forget to add the StoreFront server computer accounts to the local group CitrixSubscriptionSyncUsers on each StoreFront server.
  1. I basically performed the powershell commands at each side.  I had a start time difference of 5 minutes and the same interval of 10 minutes.  So at Datacenter#1 the synchronization would kick off at 5:00AM, and then run again in 10 minutes.  At Datacenter#2 the synchronization would kick off at 5:05AM and then run again in 10 minutes.  Note: you can added multiple stores to synchronize.  Also, we don’t need to add ‘Store2’ to this list.  Instead of adding multiple stores here, we will be pointing ‘Store2’ to ‘Store1’ Datastore subscription file.
  2. To address having multiple subscription stores per store, we can have each store share a common ‘datastore location’.  This way users that accessing both Stores will share a common subscription location.  We are already addressing the synchronizing between Storefront Groups at each Datacenter.  Follow this article to share a common location – http://docs.citrix.com/en-us/storefront/3-12/configure-manage-stores/configure-two-stores-share-datastore.html

STA Servers

Since Datacenter#1 Netscalers could be up and Datacenter#2  XA Site could be down, you need to make sure to add the STAs on all Gateway VIPs on the Netscaler and all Netscaler Gateway entries on the Storefront stores.  I’ve seen some diagrams where you can create a GSLB or LB VIP for the STA servers.  That is also an option.

For this setup, I simply added 4 STA entries (1 for each delivery controller) to the configuration locations.


Leave a Reply

Twitter