Does anyone care about having high-availability for their XenApp farms? I would envision many of you would say yes. But what does HA for XenApp really mean? On the server hosting side, you essentially have HA because you have load balancing at the application level. So if you lose a XenApp server, not too much of a concern as those users can simply restart their application and get load balanced to another server (of course they lose their previous session information, which can be annoying.) But what other areas of critical to providing a more available XenApp environment?
I’ve been thinking about this a lot lately, which is probably because my manager has had a lot of meetings and I tend to space out and watch episodes of The Simpsons on my laptop. Since my DVD player broke, I started to think about HA for XenApp during these meetings (at least I’m now doing work). I was able to come up with the following thoughts:
- Smart Monitors: First, I want to know that something has failed or has gone flakey. I don’t want a bunch of messages telling me everything is ok, I just want to know when something is about to go horribly wrong. For example, the XML Black Hole. I’ve seen the black hole cause too many issues, so how do we detect it? You create a smart monitor that does more than pings. It tries to make requests to the XML service. If the expected data comes back, we are good to go. If the request is never answered or the response is junk, then Homer, we have a problem.
- HA for the Critical Components: Now if we can detect a failure, DO SOMETHING ABOUT IT. As we continue looking at the XML Black Hole, if we see there is an issue, then stop making requests to it. But this requires another XML Brokers to take over the responsibility of the failed one without requiring changes to the environment’s configuration. Sounds a lot like load balancing to me.
- Business Continuity: Essentially what I’m saying is that if my XenApp environment at one site fails, I better have another site already waiting for connections without requiring me to make changes. Many people have 2 data centers: a primary and a backup. Others have 2+ data centers that are all active. For those organizations with 2 data centers (primary and backup), how do you fail users over to the backup in the event of a failure? For those organizations that have 2+ active data centers, how do you tell your users data center is their preferred site? That is really a trick question (Did I get anyone?). You shouldn’t have to tell your users anything about going to a primary, backup, tertiary site. It should happen automatically. Users want their applications in the fastest possible means necessary, which could mean that one day it is from data center 1 and on another day it could be data center 2.
These three items are all part of NetScaler, and it is easy to setup. For those of you who know me will notice that I’ve worked with the integration of NetScaler and XenApp for some time. Well, the NetScaler product group is actually making my job easier because they are making this solution a lot easier. I created and maintained a 40+ page document that showed you how to set all of these goodies up. Now that document is about 14 pages (with pictures for each step) because of the new NetScaler for XenApp wizards. I’m just glad I don’t get paid by the word. Take a look at what I’m talking about. In about 5 minutes you will see me configure and integrate NetScaler with XenApp:
Watch this Video:
Also, take a look at recently released articles that goes into more detail on this integrated solution: http://support.citrix.com/product/nsad/v8.1/consulting/
- Taking XenApp to the Next Level of Availability – Reference Architecture
- Taking XenApp to the Next Level of Availability – Implementation Gudie
I’m curious what other areas concern you when you are focused on HA for XenApp? Let me know. Yes, my manager finally ended the meeting, I am outta here.
(Homer Quote of the Blog “Kids, you’ve tried your best and failed miserably. The lesson is, never try”)