Search
  • benjamincrill

SQL AlwaysOn lessons learned


So I've seen this in a number of different scenarios now with additional colleagues and customers so figured I would pass it along. The issue causes various odd behavior to happen in a Citrix XenDesktop environment if you are using a SQL AlwaysOn cluster. If you setup the XenDesktop site using the installation GUI it creates the database and broker logins in SQL on the active node of the AlwaysOn availability group. The database gets synced to the non-active node, however the logins for the broker accounts does not sync properly.

The first time I came across the issue it was relatively easy to detect. Failover of the availability group happened and immediately the brokers reported errors about connecting to the database. User functionality was impacted as expected. A colleague had an odd issue where one broker was exhibiting odd management behavior, however the others appeared to be working normally. In that case some of the broker accounts had not gotten synced to both nodes of the SQL availability group.

This illustrates two important points in deployment particularly when fault tolerance is of importance. First, trust but verify. Yes it should work but I've now seem a number of times where it doesn't. It only takes a little more time to verify settings. Two, test your setup. There is only one way to know for sure that the environment you configured will act as expected, and that is to test it out. If you invest resources in various levels of fault tolerance, you need to ensure you are getting the value out of your investment.


0 views
  • LinkedIn Social Icon
  • Twitter Social Icon