This post has already been read 20633 times!
Once upon a time….
A customer I was dealing with decided on an active/active solution.
Shortly after implementation users started complaining of slowness with a specific application. Investigations identified the DB backend for this application was only in one site.
To cut a long story short the backend location was not going to change. Other applications had backend DB’s in the other locations to add complication.
Now you may have heard of Application Groups introduced in Xenapp 7.9. I just read about it and never put it in to practice but in this case, it certainly came to the rescue especially combined with Tagging which was introduced in 7.8 version.
With these new features, I could configure the Xenapp solution to either load balance applications between different locations within the same Xenapp site or set a preferred site for session connection.
In addition, because of Tagging I could control what machines users could connect to and use Tagging to aid in troubleshooting support issues.
Let me walk you through the solution.
The below diagram shows the principal design of this solution.
- You have your individual applications.
- You create application groups.
- You assign applications of likeness in to the Application Group.
- You connect the Application Group to a Delivery Group or Delivery Groups.
- Create Tags for individual Xenapp servers, groups of servers that you can add within your Delivery Groups
Advantages
The following all happens at the Application Group level:
- Using the above method, you only set permissions at the Application Group level, not the Delivery Group or individual application.
- You can set priority of assigned Delivery Groups. Having the same priority will load balance applications between the assigned Delivery Groups.
- Setting different priorities will result in one of the Delivery Groups being favored for application connections.
- You can control which servers the applications in your Application Group go to by restricting launch to a specific Tag.
So now I have a controlled solution for application site launches and server session launches which will greatly help in troubleshooting techniques.
Plus, if you have Xenapp 7.9 and above you can do this!
Now to show you what this looks like in the real world:
Within the individual application you assign the Application Group
Permissions are not set at the individual application
Within the Application Group is where you set the permission restrictions
Within the Application Group you assign the Delivery Groups. The below picture shows a priority setting favoring the London Delivery Group. If this was 0, 0 the applications in the group would be evenly load balanced.
At the Delivery Group level in the “edit Delivery Group” settings we see that no permissions are set.
Now the thing to remember is you can set permissions at 3 levels. Application, Application Group and Delivery Group. Best practice when using Application Groups is to set the permissions at this level. However, if for one reason or other your apps in the application group require different users then just set the permissions at the application level and not at the Application Group level or Delivery Group level.
Basically, try to set them only in one location!
Conclusion
I find this a very overlooked feature that is incredibly useful. It is very simple to change your solution from active/active to active/passive per app level or target specific servers when launching applications, all from within the core XenApp software without the addition of more kit.
So, if you have an issue where various apps perform better in certain site locations this solution will become handy. If you have profiles only in one location and they are causing problems loading in one site a simple change using Application Groups will be your knight in shining armour!
I hope you enjoyed this tale from the land of Citrix…and just so you know, they all lived happily ever after.