Very Nice article about IMA by Brian Madden:

Remember that a Citrix Presentation Server farm is really just a database (called the IMA Data Store), and Presentation Servers are said to be part of the same farm if they’re sharing the same data store. The data store stores all configuration information for all farm servers. When a Presentation Server starts up (or, more correctly, when the IMA service on a Presentation Server starts up), the following process takes place:

1. The IMA service checks the registry to find out what DSN contains the connection information to the data store. This registry location is HLKM\SOFTWARE\Citrix\IMA\DataSourceName(or LHCDatasource)
2. By default, that registry key points to a file called MF20.dsn in the “%ProgramFiles%\Citrix\Independent Management Architecture” folder.
3. The IMA service connects to the database specified in that DSN file. (Database credentials are encrypted and stored in the registry.)
4. The IMA service downloads information that pertains to it from the central database into a local MS Jet (Access) database.
5. Throughout its operation, the IMA service interacts with the locally cached subset of the central data store.
6. Every 30 minutes, the IMA service contacts the central data store to see if anything has changed.

The Local Host Cache

As previously stated, the IMA service running on each Presentation Server downloads the information it needs from the central data store into a local MDB database called the local host cache, or “LHC.” (The location of the local host cache is specified via a DSN referenced in the registry of the Presentation Server, at HKLM\SOFTWARE\Citrix\IMA\LHCDatasource\DataSourceName. By default this is a file called “Imalhc.mdb” and is stored in the same place as MF20.dsn.)

Each Presentation Server is smart enough to only download information from the data store that is relevant to it, meaning that the local host cache is unique for every server. Citrix created the local host cache for two reasons:

• Increased Redundancy. If communication with the central data store is lost, the Presentation Server can continue to function since the information it is available locally.
• Increased Speed. Since the local host cache contains information the Presentation Server refers to often, the server doesn’t have to access the IMA data store across the network every time any bit of information is needed.

The LHC is critical in a CPS environment. In fact, it’s the exclusive interface of the data store to the local server. (In other words, the local server’s IMA service only interacts with the LHC. It never contacts the central data store except when it’s updating the LHC.)

If the server loses its connection to the central data store, there’s no limit to how long it will continue to function. (In the days of MetaFrame XP, this limit was 48 or 96 hours, but that was because the data store also stored license information.) But today, the server can run forever from the LHC and won’t even skip a beat if the central connection is lost. In fact now you can even reboot the server when the central data store is down, and the IMA service will start from the LHC no problem. (Older versions of MetaFrame required a registry modification to start the IMA service from the LHC.)

The LHC file is always in use when IMA is running, so it’s not possible to delete it or anything. In theory it’s possible that this file could become corrupted, and if this happens I guess all sorts of weird things could happen to your server. If you think this is the case in your environment, you can stop the IMA service and run the command “dsmaint recreatelhc” to recreate the local host cache file, although honestly I don’t think this fixes anything very often. (I think it’s more to make people feel better. “Ahhh. I recreated the LHC, so we’ll see if the problem goes away.”)

Data Store Architecture

Now let’s take a closer look at the actual database that’s used to power the IMA data store. If you open this database with SQL Enterprise Manager (or whatever Oracle calls their database management tool), you’ll see it has four tables:

• DATATABLE
• DELETETRACKER
• INDEXTABLE
• KEYTABLE

If you’re at all familiar with databases, you’re probably thinking this is kind of weird. Wouldn’t the central database of a complex product like Citrix Presentation Server have hundreds of tables? Shouldn’t there be tables that list servers, apps, users, and policies, not to mention more tables linking them all together? The reason you don’t see the database structure you’d expect is because the IMA data store is not a real relational database. It’s actually an LDAP database that Citrix sort of hacked to work on top of a relational database like SQL Server.

This is because Citrix first came up with the concept of the IMA data store when they were working on MetaFrame XP in 2000. At that time they had planned to use Active Directory as the data store instead of a database. They developed the entire MetaFrame XP product around an LDAP-based data store instead of a relational database-based data store. Then towards the end of the development process, Citrix (smartly) realized that not too many people would want to extend their AD schemas to just to use Citrix, so they quickly moved to using a regualar database instead. The only problem was that the entire IMA service and data store were all ready to go using LDAP, and Citrix couldn’t just re-write the entire product to use a relational database instead. The solution was that Citrix had to implement their own LDAP-like engine that runs on top of a normal relational database. (On top of all that, Citrix encrypts this whole thing, so the contents really are gobbledygook to the casual observer.)

This is the reason you can’t just access the IMA data store directly through SQL Enterprise Manager. (Well, technically you can, but if you run a query you’ll get meaningless hex results.) If you try to edit any of the contents of the data store directly in the database, you will definitely break it and have to restore from backup.

For those curious to learn more about the LDAP-like structure of the data store, there’s a tool on the Presentation Server installation CD called “dsview.” DSview is fun to play with but not really that useful.

One final word of caution: There is a tool in existence called “dsedit.” As you can probably guess from the name, dsedit is basically a “write-enabled” version of dsview. If you happen to find this tool out on the Internet, DO NOT use it in your environment! This is an internal Citrix tool that is not meant for general use.

Now if you’re thinking, “I know what I’m doing, so I can play with dsedit,” I’ll warn you again: Don’t do it! The problem is that since dsedit is an internal-only tool, it’s not externally version-controlled. Citrix has many different compiled versions of this tool for all different versions of Presentation Server (and in some cases with specifics for certain hotfixes). So if you just happen to find some random hacker site with dsedit for download, you have no idea whether that dsedit version is the version that’s compiled to work with your specific version of the data store. (Chances are it’s not.) And using the wrong version of dsedit with your data store an easily corrupt the entire store (since data store items are maintained in long HEX strings that represent the LDAP-like node items.)

IMA service to data store communication

Let’s take a closer look at how a Presentation Server communicates with the central data store. We initially outlined the process that takes place when the IMA service starts up. In it, we described the IMA service downloading information from the central data store that’s used to create the local host cache. Of course if the local host cache is already on the server (and up-to-date) when IMA starts, there’s no need to download everything again.

So how does the server know whether its local host cache is current? Citrix makes this possible via a series of “sequence numbers.” Every single configuration change made to the data store is assigned a number. The number of the most recent change is stored in the local host cache. Then when the IMA service checks the central data store for changes, it only needs to download the value of the most recent sequence number. If that number is the same as what it was last time (i.e. the same number that’s in the local host cache), then no further action is needed and the server knows its local host cache is up-to-date.

If sequence number of the most recent change in the central data store is newer than what’s in the local host cache, then more data is exchanged to determine what the changes are. If they apply to the specific server requesting the updates, they’re downloaded to that server and the local host cache is updated accordingly. If the changes do not apply to the requesting server, that server still updates the most recent sequence number in its local host cache so it can continue to look for changes in the future.

The IMA service on each Presentation Server looks for changes in the central data store every 30 minutes. You can adjust this value via the registry of the Presentation Server (CTX111914), although there’s typically no reason to do that since this exchange is less than 1k if there’s no change.

IMA Data Store Database Type

Since Citrix’s implementation of the IMA data store runs on top of a regular relational database, you can pretty much use whatever kind of database server you want. Most people end up using SQL Server, although others are supported. (See CTX112591 for a complete list.)

For smaller environments, Citrix used to recommend using a Microsoft Access database running locally on one of your Presentation Servers. Nowadays that’s not really used anymore, having been replaced by SQL Server Express. (SQL Express is free and based on “real” SQL Server technology.)

A big topic of discussion has been what constitutes a “smaller” environment? Or to be more blunt, at what point do you need to switch to using a real database instead of using Access or SQL Express? A lot of people argue about this in the online forums, with the general consensus being in the five-to-ten server range. I don’t agree though. I’ve personally seen farms (even back in the MetaFrame XP days) of 50 servers running their data stores on Access, and that was fine. Since each Presentation Server only really interacts with its local host cache, a 50-server farm using Access still wouldn’t put much strain on the Access database.

To be honest, the real problem with using Access or SQL Express for your data store is that it has to be accessed “indirectly” (to use Citrix’s term). This means that the actual files that make up your data store are physically sitting on one of your Presentation Servers. The IMA service on that server accesses the database locally, and every other server in your farm accesses the data store via the IMA protocol (on port 2512) through the Presentation Server that’s hosting it. This is bad because it’s a single point of failure. If that Presentation Server goes down, your data store won’t be accessible and you won’t be able to manage your environment.

This might not be a problem in a small farm of just a few servers, but you’ll probably want a more redundant database long before your farm outgrows this architecture from a technical capacity standpoint.

IMA Data Store Size

Another question that often comes up when designing Presentation Server environments is, “How big will this IMA data store get?” The answer, very seriously, is “Not very big!”

Of course “very big” is a relative term, but in today’s world of multi-core servers with gigabytes of memory, the data store just isn’t going to grow large enough to really matter. Citrix very roughly estimates 1MB per server. And even if you built a single farm with 1,000 servers, a 1GB database in today’s world just isn’t that big anymore.

If you want more precise numbers as to the size of your data store, the Advanced Concepts Guide for CPS 4 (CTX107159) has a chart that lists exactly how many bytes each object type needs in the data store. (I have not been able to find this info for CPS 4.5, but I’m going to assume it’s pretty close to 4.0.

IMA Data Store replication strategy

If your server farm spans multiple physical locations, you might want to replicate your data store so that a local copy is running at each location. There are two (potential) advantages to this:

• Redundancy. You don’t want a single database server failure to negatively impact your overall environment.
• Performance. If your farm spans multiple WAN locations, you might want to have a local database at each location.

Before we discuss this further, I want to make a few things clear: we’re talking about doing a full replication of the entire data store, so that each replica is 100% identical. Unfortunately due to the binary LDAP structure of the data store, it’s not possible to just replicate a subset of the data store to a remote site.

Second, we’re talking about replicating the data store between physical sites for site-to-site performance and redundancy reasons. If you want to cluster your data store servers, this is entirely possible, but not what we’re talking about now. (For more information about clustering your data store servers, read the High Availability chapter later in this book.)

Figure 3.x [Replicated data store between two physical locations]

Replicating your data store for redundancy

If your farm spans multiple physical locations, you might be concerned about what happens when a WAN link goes down. There’s an entire chapter later in this book dedicated to helping you design a fully-redundant environment based on everything that you’ll read up until that point. But right now we can discuss the mechanics of the data store when it comes to replication for redundancy purposes.

The first and most important thing to know is this: A Citrix Presentation Server will work indefinitely even if it loses connectivity to the central data store. (Again, remember that the local IMA service on a Presentation Server works off of its local host cache, not the central data store.) So really before you can decide whether you want to replicate your database for redundancy purposes, you have to decide understand what the impact is of losing connectivity to the data store.

The main thing is that in order to use either one of the two CPS management consoles, you have to connect to a Citrix server that is communicating with its data store. So if your data store is lost, even though your Presentation Server will run and will accept new connections and otherwise be totally normal, you won’t actually be able to connect to that server with a management console.

What’s interesting is that this doesn’t mean that you can’t manage sessions on that server. If you can connect to a different server in your farm that is connected to the data store, then you can view all activity and all sessions from your farm–even the ones from servers that aren’t connected to the data store. But think about this for a minute. How is it possible that your management console is able to connect to a server that can access the datas store, and it’s able to see servers not connected to the data store? If this is the case, wouldn’t your “down” servers also be able to see the data store?

A more likely scenario is that you have multiple WAN locations each with their own Presentation Servers all in the same farm. If a WAN link goes down and some sites do not have their own replica of the data store, the servers, sessions, and users on that site will be fine. The problem will be that admins and help desk folks won’t be able to connect to any admin consoles at that site. (And people at the site with the data store will be able to connect, but of course they won’t be able to see or manage servers from the site with the down WAN link.)

A solution to this is to replicate your data store so that if a WAN link goes down, there’s a local replica at each location. This means that local admins will be able to connect to the management tools on those local servers and perform their typical routine maintenance tasks. (Resetting sessions, shadowing, etc.)

Of course if any admin from the “down” site makes any configuration change that’s saved to the data store, that change will be lost once the WAN link comes back up and the central data store re-replicates with the local data store. (As you can imagine, “merge” replication is not possible with this binary encrypted LDAP data store format.)

Replicating your data store for performance reasons

Some people also choose to replicate their data stores to multiple locations for performance reasons. The idea is that by doing this, you Presentation Servers can always access the data store via a local network instead of via the WAN. To be honest, this probably isn’t that big of a deal. Remember that each Presentation Server interacts with its own local host cache for standard operational purposes. The central data store is only accessed to download additional configuration changes. Sure, recreating the local host cache will require the download of all the contents to rebuild the MDB cache file, but that too is not typically very large. (A few megabytes maybe?) And if your WAN can’t support the transfer of a few megabytes every once and a while, then you probably shouldn’t have a single farm that spans multiple sites anyway.

All that said, it’s a nice “clean” solution when all the Presentation Servers of a remote location can access everything they need on their own local LAN, and there’s certainly nothing wrong with that scenario.

Advantages of replicating

• You can manage your servers when the WAN is down
• Less WAN traffic (Read the “zones” section of this chapter to understand why.)
• It just “feels” better, especially for a global environment

Disadvantages of replicating

• More complex
• Additional database servers required

Configuring IMA data store replication

If you decide that you’d like to replicate your data store, you’ll need to do two things:

1. Configure the database software for replication
2. Reconfigure your Presentation Servers to point them towards the local replica

Configuring the database for replication

All the real database servers support replication. (i.e. if you want to do this, you can’t use Access or SQL Express.) Configuring the replication of your data store is 100% a function of your database software. In fact, your Citrix servers won’t even know they’re connecting to a database replica versus the real thing.

If you’ve never done this before and you’re in the unfortunate position of making it happen in your environment, CTX112125 has more information and links to step-by-step instructions for configuring replication with SQL Server. The main thing you have to do is make sure that your replicas are “writable” by the local Presentation Servers. There’s a few ways this can be set up, but in a CPS environment you need to ensure that one master copy of the database is in charge of all changes to it. (With that weird binary encrypted LDAP format, you don’t want the database server to try to sort out two changes entered into two different replicas at the same time.)

Pointing your Presentation Servers to a new replica

Once you’ve got your data store replicated to your new location, you need to reconfigure the local Presentation Servers there to use the new replica instead of the old central location. Remember from the beginning of this section that a Presentation Server knows where to find the central data store via a file called MF20.dsn (which is specified in the registry). If you want to point your Presentation Server to another database (i.e. a local replica), all you have to do is to change that DSN and then restart the IMA service. (There are some command-line options for the dsmaint utility that let you change the location of the data store, but I personally find it easier to just edit the MF20.dsn file itself.)

Again, this will only work if you’re pointing a server to a new database that is 100% identical to the old database. You cannot use this technique to “migrate” a server between farms since a new farm wouldn’t know anything about a server that was just randomly pointed to it.

Posted in Brian Madden Blogs