If you missed the other articles in this series please read:
- Designing and Implementing Effective Disaster Recovery Strategies with Citrix Technology Part 1: The Plan
- Designing and Implementing Effective Disaster Recovery Strategies with Citrix Technology Part 2: The Strategy
Introduction
In my last article we looked at recovery strategies for specific components of the Citrix environment. In devising environments for business critical applications it is important to consider both high availability and disaster recovery options in implementing your environments. Once you have identified your concerns and created appropriate recovery strategies for the core components of your server farm, it is critical to make sure that you have also covered the additional requirements for a Citrix farm to function. In this final part of the series we will discuss backup and recovery strategies for your data store.
Data Store Restoration
Honestly, you could write a five part series just on how to backup or restore your data store. As I mentioned in the last article, the criticality of your data store has been significantly decreased since Citrix separated the licensing component into its own service. That’s not to say the data store isn’t important though! After all, if your data store is truly lost you will be forced to completely recreate your farm environment. And trust me that is not a fun way to spend your weekend! So what can you do to minimize your risks?
Well, let’s start by addressing the scenario as it was presented in the last article. The data store is hosted in a SQL2000 environment along with the Resource Manager database. Obviously this is a more complex situation than a simple Access data store. I can’t tell you the importance of your data store to you. It is honestly an individual choice that each organization will have to make in addressing their goals. Let’s look at two common requirements that managers like to give to their poor overworked admins:
The data store must ALWAYS be available
Frankly, you can’t really guarantee this one. You can come darn close though! For starters, you will likely want to cluster your SQL environment. On Windows 2003 Enterprise, installing SQL2000 with SP3 on a clustered environment is actually a fairly painless process. The limitations of Microsoft clustering remain in place however. Because the cluster will be Active/Passive, one server will sit unused unless the primary is brought offline. Additionally failover will only occur under conditions that are recognized as a failure by the cluster service. And because of the requirements for shared Quorum and Data space, it becomes very difficult to locate clustered servers any real distance apart for a true DR situation.
The clustered environment gives you a fault tolerance at a local level. For true Disaster Protection however, you need to have some plan for offsite recovery. This could mean hot hardware at a standby site and SQL replication for the data store databases. Log shipping is also an option with SQL but with some important caveats. If constant uptime is a concern, log shipping can cause a significant recovery time depending on the number of transactions in your database. When you are using log shipping as a means of backup and recovery, the database has to process those logs in recovery mode before it can become operational. If you haven’t refreshed your database in a year and have just been shipping those logs down to your DR site, then be prepared for a LOT of pain when you run that recovery mode.
So you’ve got your cluster, you’ve got your replication or log shipping… you’re safe, right? Well, probably. But what if (and I know I’m going crazy here) your DR server fails? Never happen, right? That’s what I thought. But a funny thing happens when you leave DR servers sitting for a year without really watching them. They tend to fail, and you often don’t realize it until it’s time for you to need them. So what can you do? Well, you cluster your DR environment of course! So you now have your live cluster, your DR cluster, and probably SQL replication between the live and DR database servers. I admit it is a crazy situation. You’ve got 2 live servers, 2 standby servers, and lots of redundancy. All for your Citrix data store!
I can’t say I honestly recommend this situation. In my case, the database server happened to be hosting several other critical databases and my little data store got swept up in the process. I will admit though that I have absolutely no fear about any kind of data store failure now though! It is important to understand however that this environment STILL doesn’t fulfill the requirements of management that the data store be always available. In a replicated environment you are still have to force the replicated SQL server to take over as the live environment. You will also have to modify the DSN on each server to point to the new SQL server unless you utilize some form of DNS aliasing. Setting up SQL replication is an extremely difficult task unless you are an accomplished SQL admin. Citrix has provided VERY thorough documentation on their website for setting up that replication, but it still requires a good understanding of SQL Server to execute. I do not recommend setting up replication without help from your DBAs if you are not a SQL person yourself.
The Data Store isn’t as Important as User Connectivity!
This is the other common attitude managers take, and it is often a valid one. You can run for quite some time without it after all. Sure, your options are severely limited in relation to management of your Citrix environment. But as long as your users can carry on all is right with the world! Well, maybe not. User connectivity can and should be the highest priority for any Citrix farm, but that shouldn’t override your ability to manage your own farm. This attitude can be a difficult one to counter however. Generally this is the type of environment where you’re just going to run flat backups of the database and use them to restore once you have the time. This could be to the same hardware, to a DR site, etc; Flat backups of the database can be scheduled and managed through the SQL Server Administrator. You want to make sure you back up all the relevant databases like Master as well as the data store itself. Otherwise you will not be able to successfully restore the database.
Once you have restored the database form the flat files you still are faced with the same requirements as above. You may need to make those same DSN changes or DNS aliasing to make the connection work. You will also likely need to cycle the IMA service on all of your boxes to make sure they can connect to the new data store copy. Although the servers can be run for quite some time without a data store, it really isn’t a good way to leave your environment. Monitoring becomes a logistical nightmare. Performing common tasks like user session manipulation is close to impossible. And if something further goes wrong it might take a very long time to diagnose. While it is understandable that management is concerned with the user base, you have to be concerned with your own ability to work.
Conclusion
Data store redundancy and Disaster Recovery can be a touchy subject. In many cases it’s one of those “we’ll get to it when we can” situations. But sometimes, in high pressure environments, it really does make sense to provide a clustered or replicated environment for your data store. Only you as the administrator can accurately answer the importance of a working data store to your organization. This concludes my series on Disaster Recovery and your Citrix environment. I realize I have only brushed the surface on some issues, but there really is no way to cover all of the facets of a true DR in 3 short articles. Hopefully this has given you some things to consider as you plan your own DR needs, and a few tips to help you implement it successfully.
If you missed the other articles in this series please read:
