You can see this recommendation in few of our recent best practices – most recently in the excellent “XenDesktop and XenApp Best Practices document”:
“The XenDesktop and XenApp servers should be configured to use DNS Aliases when accessinginfrastructure components such as the Citrix License Server and Database Server(s) rather than hostname or IP address. This helps to simplify management during certain maintenance and disaster recovery scenarios.”
But what does it exactly mean and how should it be configured?
I’m following this best practice for many years and I would like to share few information about how to use it and what are the benefits.
Abstraction
One of the very important aspects of consulting is something I like to call an abstraction – in a similar manner as programmers, you should understand the benefits and always keep abstraction in mind. There are many aspects in daily consulting job that are covered under “abstraction” – for example, especially in enterprises, different services are abstracted from you. Often you don’t touch the storage, SQL or Active Directory – there are other teams responsible for this. If you can properly describe different project services and abstract them, your job is going to be much easier.
I’m getting to my point finally – another example of abstraction can be identification of services:
- How can Web Interface know the XML brokers?
- How can XenApp, XenDesktop or XenServer know the license servers?
- How can XenApp, XenDesktop or PVS know the database servers?
- …
Typical answer is by using hostnames or IP addresses – this is definitely the easiest way how to configure it at beginning. But don’t forget – proper design is not focused only on current situation, but should already think ahead and be prepared for whatever happens in the future (typical example of this are disaster recover scenarios).
What if you would like to migrate to new environment? What if you would like to move service to different server?
With host names and IP addresses, this process can be rather complicated – for example you will need to change the address of license server on each and every component that is affected (and then again – what if you forget about one service?).
CNAMEs to the rescue!
In previous example, I was asking about service and ideally I don’t want to get an answer like “Your license server is probably 10.13.102.15, if it didn’t change meanwhile” – instead, I would like to get an answer like “any server that is currently using CTX-LIC alias”. Easiest was how to achieve this is by using CNAMEs – CNAME is like an DNS alias – you can simply have additional names for your server and describe what the server is actually doing.
The beauty of this solution is that it’s very easy to implement and can be very powerful. It also can simplify your management – instead of using CTXLONWS1423, you can use CTX-XA-001, instead of CTXLONWS1452, you can use CTX-LIC.
Typically, I use CNAMEs for following components:
- Primary and backup controllers (both XenApp and XenDesktop)
- SQL server
- License server
- File servers (if DFS-N is not available)
Even if all components (XenApp, XenApp logging, XenDesktop, PVS…) are using the same SQL server, I tend to create separate CNAMEs for each of the connections.
Proper naming convention is extremely important (and would deserve dedicated blog post), so I don’t want to go into more details. Important information is that if your naming convention feels natural, you can use longer names (and please, don’t be afraid of using delimiters). For example use can use CTX-XD-Primary or CTX-XA-Backup (in case of dedicated domains). If I’m building environment within existing domain, I tend to always define unique environment identifier, for example using suffixes. For example if I’ve got project related to off-shoring, I will add suffix “OS-P” or “OS-D” (off-shoring production and off-shoring development). Naming convention in such case would be “CTX-#COMPONENT#-#ROLE#-#ENVIRONMENT#-#DTAP# (where DTAP stands for development, test, acceptance and production). When properly implement, you can remotely connect to the server without knowing the name or the DNS alias, you can simply put all pieces together like Lego.
And the benefits of such solution?
- Easier management – being able to put all the pieces together without actually knowing the correct alias makes it very easy to administer such environment
- Disaster recovery scenarios – if you need to build new license server, all you need to do (after building it and re-allocating licenses) is to simply alter the CNAME record
- Easier migrations – we usually recommend clean installations instead of in-place upgrades. When you are using the CNAMEs, not only are the migrations easier to implement, but you’ve also got very powerful tool for rollback scenarios in case something goes wrong
If you found this article useful, let me know in comments area and I will also write one discussing naming conventions.
